What is the double diamond model?

The double diamond is a design process framework that maps how designers move from understanding a problem to delivering a solution. Developed by the UK Design Council in 2005, it has become one of the most widely referenced models in design thinking, service design, and product development.

The name comes from its visual shape: two diamond forms placed side by side. Each diamond represents a cycle of divergent thinking—expanding outward to explore possibilities—followed by convergent thinking—narrowing inward to reach a decision. The model divides design work into four phases: Discover, Define, Develop, and Deliver.

The four phases

Discover

The first phase is about understanding before acting. Design teams spend time exploring the problem space: conducting user interviews, observing behavior in context, reviewing existing research, and gathering data about the people affected by the challenge they're working on.

The goal of Discover is not to find solutions—it's to build a rich, nuanced understanding of the problem from the perspective of the people experiencing it. This phase is deliberately open-ended. Teams follow threads of curiosity, explore adjacent areas, and resist the temptation to jump to answers.

Common research activities in the Discover phase include ethnographic observation, diary studies, stakeholder interviews, and competitive analysis. The output is typically a collection of raw findings: quotes, observations, photos, and data points that document what was learned.

Define

The second phase converts raw research findings into a clear problem statement. Teams analyze what they gathered in Discover, looking for patterns, contradictions, and underlying needs. The aim is to move from symptoms to root causes—to understand not just what users are doing but why.

The Define phase is where divergence gives way to convergence. Teams use methods like affinity mapping, journey mapping, and synthesis workshops to make sense of their data. The output is a well-articulated problem statement or point-of-view that will guide the next phase of work.

A strong problem statement is specific, grounded in evidence, and focused on user needs rather than predetermined solutions. It should be challenging enough to warrant creative exploration but bounded enough to make ideation productive.

Develop

With a clear problem statement in hand, teams enter the second diamond. The Develop phase is about generating and testing a wide range of potential solutions. This is where ideation techniques—brainstorming, SCAMPER, brainwriting, analogical thinking—are most actively used.

The Develop phase is deliberately expansive. Teams create many concepts, build low-fidelity prototypes, and test them quickly with users. Failure is expected and welcomed here, because early failure is far less costly than discovering a solution doesn't work after full implementation.

Iteration is the defining characteristic of the Develop phase. Teams cycle through rounds of ideation, prototyping, and testing, using what they learn in each round to refine their thinking. The goal is not to produce a polished solution but to generate the evidence needed to select the most promising approach.

Deliver

The final phase focuses on refining the chosen solution and preparing it for implementation. Teams move from many options to one, conducting more rigorous testing, resolving outstanding questions, and ensuring the solution is ready to be built or deployed.

Deliver involves closer collaboration with engineers, operations teams, and other implementation partners. Design decisions must account for technical constraints, business requirements, and organizational context. The output of this phase is a solution that is desirable to users, technically feasible, and commercially viable.

Why the double diamond is useful

The framework's primary contribution is making explicit something that experienced designers already do instinctively: alternating between expansive exploration and focused convergence. By naming this rhythm, the double diamond gives teams a shared language for talking about what phase they are in and what kind of thinking is needed.

This shared language is particularly valuable in organizations where design and non-design stakeholders collaborate. Business leaders often want to converge quickly; designers often want to keep exploring. The double diamond provides a framework for negotiating these tensions by showing that both impulses are necessary—just at different moments.

The model also reinforces a crucial principle: solving the right problem matters more than solving a problem efficiently. The first diamond exists precisely to challenge initial assumptions about what the problem is. Many product failures result not from poor execution but from working on the wrong problem in the first place.

Applying the double diamond in practice

In practice, design work rarely moves through the four phases in a perfectly linear sequence. Teams often revisit earlier phases when new information emerges, or compress phases when time is limited. The double diamond is better understood as a navigational tool than a rigid sequence.

Effective use of the model requires discipline in two areas: resisting the urge to converge too early, and knowing when enough exploration has occurred to make a defensible decision.

Teams that rush through the Discover and Define phases often find themselves solving the wrong problem with great thoroughness. Teams that never exit the Develop phase never ship anything. The double diamond is a reminder that good design requires both rigor and decisiveness—applied in the right order.

The double diamond in relation to other frameworks

The double diamond shares philosophical ground with design thinking as popularized by IDEO and Stanford's d.school, and with agile development methods that emphasize iterative delivery. It is compatible with lean UX practices and can be adapted to work alongside sprint-based product development.

Unlike more prescriptive methodologies, the double diamond does not dictate specific tools or timelines. This flexibility makes it applicable across a wide range of contexts—from redesigning a single product feature to rethinking an entire service experience.