The Double Diamond Model

The full lesson

Most design failures are not execution failures — they are framing failures. Teams build the wrong thing beautifully, ship it, and then discover that users never had the problem they solved. The Double Diamond model exists to prevent this. It makes two critical moments explicit: first, widening your thinking to find the real problem, and second, widening it again to find the right solution. Understanding how to use this structure — and knowing when each diamond is complete — is what separates teams that ship impact from teams that ship output.

What the Double Diamond Is

The UK Design Council developed the Double Diamond and published it in 2005, based on observations of eleven global companies. It is a process model that maps creative work as two cycles of diverge then converge.

The model has four named phases, arranged as two connected diamond shapes:

1. Discover — diverge to understand the problem space. Explore broadly without judgment.
2. Define — converge to a clear, well-framed problem statement or design brief.
3. Develop — diverge again to generate potential solutions. Explore broadly without attachment.
4. Deliver — converge on a tested, refined solution ready for deployment.

The visual geometry is intentional. The wide part of each diamond means you are expanding, exploring, and suspending judgment. The narrow point means you are making a definitive decision and moving forward with commitment.

The First Diamond: Problem Space

Discover

The Discover phase is pure generative work. The team’s job is to build a rich, accurate picture of the problem space before any solution thinking begins. Methods used here include user interviews, contextual inquiry, diary studies, ethnographic observation, and competitive analysis.

The critical discipline in Discover is tolerating ambiguity. There is no design artifact yet — no wireframe, no prototype, no sketch. The output is qualitative understanding: mental models, workflow maps, pain points, latent needs, and environmental constraints.

A common anti-pattern is entering Discover with a solution already in mind and running research only to confirm it. This collapses the first diamond into a straight line and produces confirmation bias dressed up as research. True Discover work sometimes reveals that the entire project premise is wrong — and that is an enormously valuable finding, not a failure.

What good Discover output looks like:

• Research synthesis with themes, not just raw quotes
• Journey maps or experience maps showing the full end-to-end context
• A clear picture of who the users are, what they are trying to accomplish, and where they currently fail
• A set of “how might we” questions or opportunity areas — not yet design directions

Define

The Define phase is the first convergence. The team takes all the richness from Discover and commits to a specific, well-framed problem statement. This is harder than it sounds. After exploring a problem space thoroughly, teams often find multiple important problems — and Define requires choosing which one to pursue.

The output of Define is typically a design brief, a problem statement, or a “point of view” framing. Here is an example: “Field service technicians need a way to submit expense reports in low-connectivity environments because the current web-only flow fails on-site, causing them to accumulate expenses informally and lose reimbursements.”

That statement is specific, grounded in research, and free of solution language. It defines the scope of the second diamond without prejudging the solution.

Phase	Mode	Key question	Output
Discover	Diverge	What is really going on?	Research synthesis, themes, opportunity areas
Define	Converge	What is the right problem to solve?	Problem statement, design brief, refined HMW
Develop	Diverge	How might we solve it?	Sketches, concepts, prototypes
Deliver	Converge	What is the best solution?	Refined, tested, shipable artefact

The Second Diamond: Solution Space

Develop

With a clear problem statement in hand, the team enters Develop — divergent solution exploration. This is the phase most people associate with “design.” That is part of why the first diamond is so often underinvested. Ideation sessions, sketching, low-fidelity prototyping, concept critiques, and co-design workshops all live here.

Develop is not precious. The goal is to generate many different approaches — including approaches that seem unlikely or unconventional — and then quickly test which ones hold up. Speed and variety matter more than polish. A concept sketched in two minutes and tested in a hallway session beats a fully rendered prototype that has never been in front of a user.

Good Develop practice includes:

• Quantity before quality — generate at least five distinct concepts before converging on any
• Concept critiques grounded in the problem statement — does this concept actually solve the framed problem, or does it solve a different problem?
• Rapid user feedback — paper prototypes, card-based concepts, or scenario walkthroughs with five to eight participants per segment before investing in high fidelity

Deliver

Deliver is the second convergence. The team takes the most promising concept from Develop, refines it through iterative testing, and produces something ready to ship. This phase is iterative rather than linear — test, learn, and refine cycles are normal and expected.

The exit criterion for Deliver is not “we like it” but “it works for users and we have evidence.” Moderated usability testing, benchmark studies, and staged rollouts all serve as validation mechanisms. In mature product teams, Deliver bleeds into continuous discovery: the shipped solution generates new behavioral data that feeds the next Discover phase.

Modern Adaptations of the Model

The original 2005 Double Diamond was a descriptive model — it mapped how design work actually happens, not a strict prescriptive process. Since then, teams have adapted it considerably. The UK Design Council released a revised “Framework for Innovation” in 2019 that added leadership, engagement, methods, and principles as surrounding factors, acknowledging that process models alone do not produce good design outcomes.

Several modern adaptations are worth knowing:

Non-linear application: Real projects rarely move cleanly left to right through four phases. It is normal to discover mid-Develop that the problem statement was underspecified and need to loop back to Define. The Double Diamond is a navigation tool, not a Gantt chart.

Nested diamonds: For complex systems, each Deliver phase can spawn a new Discover phase. A feature shipped in Deliver generates usage data that opens a new Discover cycle. Continuous discovery practices — weekly user touchpoints, opportunity solution trees — operationalize this loop.

Integration with Agile: Design’s Double Diamond sits upstream of sprint cycles, not inside them. Discovery work happens in advance of development sprints so that engineering never starts without a validated problem statement and a tested direction. This is the “dual-track agile” or “discovery track” pattern, and it is the dominant model in mature product organizations today.

Common Failure Modes

Rushing Discover to get to the “real” design work. This is the most expensive failure. A week of thorough Discover often prevents months of Deliver work on the wrong solution. Teams under schedule pressure routinely skip or compress Discovery, then wonder why their beautifully executed designs do not move metrics.

Writing a problem statement that contains a solution. “Users need a better notification system” is not a problem statement — it already assumes notifications are the solution. A well-formed problem statement describes the user’s situation and goal, the current gap or failure, and its consequence, without specifying any mechanism for addressing it.

Treating both diamonds as equally important when they are not. The first diamond is load-bearing. A perfect second diamond built on a weak first diamond still produces the wrong outcome. Investment in problem definition and research quality is leverage — it multiplies the value of everything downstream.

Over-indexing on breadth without achieving genuine depth. Divergence in Discover means exploring broadly, but it does not mean collecting many shallow data points. Five well-conducted contextual inquiries are worth more than fifty one-question surveys. Combining behavioral analytics, qualitative interviews, and validated attitudinal instruments like SUS or SEQ produces far stronger insight than any single method alone.

Treating convergence as a committee vote. The Define and Deliver convergence points are not democratic exercises where the most popular option wins. They require a decision-maker with authority and accountability to make a call, informed by evidence from the divergent phases. Undecided teams produce undifferentiated solutions.

The Double Diamond and Research Methods

The model provides a natural guide for method selection. Generative research methods (exploring the problem space) belong in Discover. Evaluative research methods (testing potential solutions) belong in Develop and Deliver. Collapsing this mapping is a primary source of research waste.

Sample size matters equally. Five to eight participants per segment is the right scale for qualitative Discover and early Develop work — enough to reach theme saturation and surface the major issues in a concept. Forty or more participants per condition is required for the quantitative benchmarking that validates a Deliver outcome at statistical confidence. Applying the “five-user rule” to quantitative work produces noise. Applying large quantitative samples to qualitative exploration is wasteful and misses the structural understanding that small-sample depth interviews provide.

Applying the Model on Real Teams

The Double Diamond is as useful as shared vocabulary as it is as a process prescription. When a product manager says “we need to skip research and go straight to wireframes,” the model gives the design team a concrete framing: “We are currently at the start of the first diamond. Moving to wireframes means we are in Develop, which is the start of the second diamond. We would be skipping Define entirely, which means we do not have a validated problem statement. The risk is that we build a solution that does not address the actual problem.”

That is not obstructionism — it is precision. The Double Diamond makes visible a decision that was otherwise being made implicitly. It frames the conversation around risk and evidence rather than process dogma.

In practice, the model is most useful when teams internalize the underlying discipline rather than following the four-phase sequence literally. Separate problem discovery from solution development. Converge only when you have enough to converge on. Treat the problem statement as the most important design decision you will make.