Prisoner’s dilemma in digital product design.
Collaborating on digital product design with engineers or managers follows the same principles as the prisoner’s dilemma — both of you can either cooperate or defect. In more modern language, suited to the design industry, you can either collaborate by building on each other’s ideas or make the most common beginner’s mistake:
falling in love with your own design.
In real life, the difference isn’t always as clear as in theory when it comes to whether the other party is truly collaborating or subtly competing by pushing their own ideas. From the outside, it might look like people are working together — sharing opinions, discussing pros and cons, using various mind-mapping techniques — but beneath all that, the good old competition gene might still be lurking, even if unconsciously.
So how can this “defecting collaboration” be noticed and mitigated before it derails the work, especially when the defecting party isn’t even aware they’re doing it?
Why can it happen?
Uncovering the blindspots
In any scenario, designing a digital product demands cross-functional collaboration, as all stakeholders have certain knowledge gaps that need to be bridged to achieve a successful outcome. For example, the more technical the product, the larger the designer’s technology gap that must be filled by an engineer. Conversely, if the user experience heavily relies on a graphic user interface, the larger the gap for the product designer to address.
Knowledge gaps create a mutual dependency that can only be resolved through trust.
Moreover, I would argue that designers are often in a less favourable position, as they typically lack both the final decision-making power (like managers) and the responsibility for implementing the agreed-upon solution (like engineers). This dynamic creates the first blind spot.
In addition to knowledge gaps, there are less obvious blind spots. One example is design equifinality — the idea that there can be multiple valid ways to solve a design task. Often, the differences between these approaches are difficult to prove until they are implemented, delivered to customers, and their real-world usage is observed. Which, for some products, can be an extremely costly — if not impossible — endeavour. I’m looking at you, in-house enterprise solutions.
As a result, it often becomes easier to defend a solution whose benefits are visible in the short term but may prove less suitable in the long term.
This focus on short-term solutions aligns well with the belief in agile and continuous delivery — we need to deliver quickly and provide user value. Hard to argue against that, right? Even though in given context it is a plausible but misleading statement.
On the surface, this blind spot may seem like a simple focus on short- versus long-term benefits. However, the actual root lies in the classic debate between analytical thinking (breaking things apart) and systems thinking (focusing on interconnectedness). What we refer to here as a short-term solution is actually an emphasis on isolated parts of the user experience and its implementation, whereas the long-term perspective considers how the solution integrates with the rest of the user flows, accommodates potential future changes and expansions, and accounts for technical complexities. Try explaining that at the office!
Honourable mentions
In addition to these subtle collaboration challenges, there are a few honourable mentions rooted in the more practical side of work — and therefore often more visible to the rest of the team.
Sometimes, colleagues from different functions simply interpret the same process, decision, or description in entirely different ways.
Both parties might be confident that everyone is following the agreed process and that collaboration is on track, only to discover — too late — that the result is completely unexpected. This phenomenon is referred to in Soft Systems Methodology (SSM) as worldviews. (1)
A lack of a clearly defined user problem — one that establishes clear boundaries and evaluation criteria for proposed solutions —is another example that can cause collaboration to slide into competition. Without clear metrics to evaluate the design, the outcome often favours the party with the loudest voice or the greatest influence. Of course, the latter are rarely product designers.
Last but not least, in customer-oriented and agile teams, decision-making criteria are often narrowed down for efficiency to a single question: What business value does this bring to the customer? or Has any customer specifically asked for this? While it would be foolish for a product designer to complain about this approach, it can inadvertently exclude important user experience considerations.
Topics like high-quality UI or streamlined navigation, for instance, may fail to meet these criteria because, unless they are outright terrible, users might simply feel mild frustration, experience a longer learning curve, and eventually complete the task — without recognising the inconvenience as significant enough to report. As a result, efficacy is sacrificed for the sake of efficiency.
Briefly about prisoner’s dilemma
The prisoner’s dilemma is a classic game theory scenario that highlights the tension between cooperation and self-interest. In the dilemma, two individuals must independently decide whether to cooperate or defect, knowing that their choices impact both themselves and the other party. Mutual cooperation leads to the best collective outcome, but individual defection can offer a better short-term result for the defector — at the cost of the other party. However, if both defect, the outcome is worse for everyone. (2)
Some “real life” example
When a designer encounters a suboptimal user experience in the product but lacks full knowledge of the technical limitations or decisions behind it, they may initiate a discussion, expecting the engineering side to take the lead in closing the knowledge gap and working toward a solution that balances both UX and technical needs.
It’s a leap of faith in their engineering counterparts — delegating ownership of a UX decision. In the language of the prisoner’s dilemma, the designer chooses to cooperate.
Now, it’s up to the engineers (or managers) to either cooperate or defect. If the UX’s long-term and holistic considerations are included in the final solution, then it’s cooperation. If the final decision focuses solely on UX’s short-term benefits, then it’s defection. This dynamic can play out on any scale — from a minor UX improvement to a roadmap-level epic discussion.
Before this discussion turns into the age-old question of whether product designers should learn the technical side of the product or become industry experts, I would argue that, in a way, this reflects a lack of trust in cross-functional colleagues to cooperate — essentially, the designer defects. (That said, product designers should still have a moderate level of knowledge about the technical aspects of the product and the industry as a whole.)
When a collaboration is a collaboration
Gaps of ignorance
The key principle of creative collaboration is building upon each other’s ideas. Even when an initial concept isn’t fully developed, the other side remains open to refining it, contributing their own expertise, and sharing it back for further iteration until it matures.
This approach is crucial for productive cross-functional teamwork, where stakeholders come from diverse backgrounds and areas of expertise to solve complex challenges. These gaps are not only about knowledge but also about differing interpretations, experiences, or even missing skills that may not seem directly relevant — such as people management abilities in a role primarily expected to focus on technical expertise.
Renowned conductor Itay Talgam, in his book “The Ignorant Maestro” (3), calls these “gaps of ignorance.” Instead of simply telling people what to do or handing them ready-made answers, people should be encouraged to develop their own solutions, interpretations, and conclusions. Co-creation should emerge through listening and dialogue.
“An ignorant can teach another ignorant what he does not know himself.”
— Jacque Ranciere
For example, when a conductor explains the principles of teamwork in an orchestra to a group of business managers — without knowing the exact details of their organisation, processes, or projects — they expose a gap of ignorance. The managers, instead of dismissing the idea because it comes from a different discipline, explore it, asking themselves how this organisational principle could be applied to their own work by integrating it with their own expertise, situational awareness, and organisational context.
Product design as politics
We can also look at cross-functional collaboration as a political game or standoff. Just like in politics, different stakeholders operate based on distinct principles and beliefs, each with its own rationale.
On one side, we have a party that champions clear, focused, short-term improvements — one that values agile processes, continuous delivery, technical efficiency, and analytical thinking. Their goal is to quickly deliver customer value through technological solutions, breaking complex challenges into manageable parts and iterating rapidly.
On the other side, we have a party that advocates for a long-term, holistic, and systemic approach — prioritizing user research, consistency, interconnectedness, and a broader product vision. They emphasise user experience, seamless flows, and the needs of other stakeholders like sales and marketing, ensuring that the product evolves in a cohesive and sustainable way.
Neither side is entirely right or wrong.
Both have legitimate reasons for their stance and are guided by an earnest belief that their approach is the best way forward. Just like political parties, they can either collaborate to find balanced solutions or contest each other, each pushing for their own “political program” in the hope of shaping the future according to their vision.
“I am great and you’re not”
Often, we see competition disguised as cross-functional collaboration. On the surface, it may look like both parties are working together, but in reality, each side keeps pushing its own idea — the one they’ve already fallen in love with — using the collaboration process to further reinforce it through feedback and alternative thinking from the other party. After all, what could be a better stress test before pushing it forward?
True, to some extent, this tactic brings benefits. The idea may improve, and some feedback may even be incorporated (a glimpse of true collaboration). But on a higher level, these refinements rarely challenge whether the idea is conceptually sound.
As a result, both sides end up incrementally strengthening their own dogmas and beliefs rather than truly exploring new directions.
Collaboration either turns into a competition where the team with more resources wins, or the side that is genuinely open to collaboration ends up merely refining the other team’s initial idea — often leading to a half-measure. And more often than not, it is the designer who surrenders.
This seemingly minor issue can have significant cultural implications, pushing employees who are open to collaboration toward either a more competitive mindset or detachment — why bother suggesting alternative ideas if everyone has already made up their minds?
David Logan, author of Tribal Leadership, shares in his TEDx (4) talk that all people form tribes that evolve through five stages. The first two — “life sucks” and “my life sucks” — are, fortunately, rarely seen in a product designer’s workplace. The next two — “I’m great” and “we’re great” — are far more common. Ideally, we want our organization to reach stage 4, we’re great, where genuine cross-functional collaboration thrives, rather than getting stuck in stage 3, I’m great and you’re not, where competition prevails.
And yes, open collaboration is riskier and harder. But at best, the alternative is doing the wrong thing right instead of the right thing wrong.
How to make it work
More practical tips
As product designers, we are rarely in a position to change a company’s culture, so we have to work with what we have. If you notice signs that a collaboration is not a collaboration, there are still ways to steer it back on track. After all, in most cases, people fall into the blind spots we discussed earlier unintentionally.
One way to mitigate those blind spots is to ask explicit questions that acknowledge an engineer’s or manager’s deeper contextual knowledge — inviting them to share how they would approach the task. In other words, guiding them toward collaborative actions.
This approach is also effective in hierarchical teams, where members often expect the lead to take action in case of ambiguity. Asking direct questions with a clear next step leaves little room for misinterpretation or deviation while also preventing the other team from freezing in uncertainty.
A more radical approach is to bluntly ask people not to fall in love with their own ideas.
While this may feel harsh at times, some appreciate having a flawed approach pointed out early rather than being gently nudged toward realisation. If the latter fails and the final outcome is a weak compromise that hurts the business, the fallout will be even worse.
Come prepared
Write things down before initiating a discussion or attending a stakeholder meeting. In Articulating Design Decisions, Tom Greever (5) advises always documenting the reasoning behind each design choice to defend it later. Here, I suggest going one step further: write down your thoughts, reasoning, and potential pros and cons before the meeting where a decision is expected — especially if you’re a non-native speaker. This way, you won’t be caught by surprise and will already have well-prepared responses to anticipated feedback — or simply avoid forgetting the right word at the crucial moment.
Otherwise, discussions can easily derail into secondary details or short-term wins instead of maintaining a long-term focus.
Dive into some technical details as well — while you don’t need to understand everything, having a basic grasp of what’s technologically possible and what limitations exist can help bridge some of the technical knowledge gap. As the saying goes: trust, but verify.
If you’re part of a design team, dedicate time to defining a product vision.
Work closely with product managers, sales engineers, and other stakeholders to establish a shared user experience vision. This will help maintain focus on long-term goals and make it easier to get buy-in from engineers, who tend to be more receptive to concrete, pre-agreed plans.
If you’re a lone product design generalist, keep track of user experience topics that may soon become relevant on the roadmap. Gather initial high-level expectations and goals from internal stakeholders outside the core product triad. The goal is to anticipate upcoming UX challenges in product development — such as dashboard content or unified navigation — before they become urgent issues.
As mentioned earlier, a well-defined user problem is key to effective cross-functional collaboration.
Even when developing a new product or feature with no prior customer usage — where defining and validating a concrete problem can be difficult — it’s still important to keep the hypothetical one as clear and unambiguous as possible while ensuring alignment across stakeholders.
Last but not least, take the time to understand how communication and decision-making processes work within other teams.
Are decisions made collaboratively or hierarchically? Who holds the final say — the product manager, the tech lead, or senior leadership? What workflows are in place, who creates tasks, and how is readiness determined? Having this insight will help you navigate complex decision-making dynamics and prevent situations where agreements made with one party are later overturned by someone higher up — without your knowledge.
Related stories
References
(1) Peter Checkland and John Poulter (2014), “Learning For Action: A Short Definitive Account of Soft Systems Methodology, and its use for Practitioners, Teachers and Students”, https://www.wiley.com/en-us/Learning+For+Action%3A+A+Short+Definitive+Account+of+Soft+Systems+Methodology%2C+and+its+use+for+Practitioners%2C+Teachers+and+Students-p-9781118393017
(2) Prisoner’s dilemma, https://en.wikipedia.org/wiki/Prisoner%27s_dilemma
(3) Itay Talgam (2015), “The Ignorant Maestro”, https://www.agabajer.com/culture-lab-podcast/the-ignorant-maestro-with-itay-talgam/
(4) David Logan (2009), “Tribal Leadership”, TEDxTalk https://www.ted.com/talks/david_logan_tribal_leadership
(5) Tom Greever (2015), “Articulating Design Decisions”, https://www.oreilly.com/library/view/articulating-design-decisions/9781491921555/
When a collaboration is not a collaboration was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.