Double Diamond

Answer in brief

The Double Diamond is a way to explain design work through four stages: Discover, Define, Develop and Deliver. It alternates broad exploration with focused decisions so that teams examine both the problem and possible responses.

Design Council describes it as iterative, with learning sometimes sending a team back to an earlier question. Treat it as a map for inquiry rather than a promise that work proceeds neatly from left to right. Framework for Innovation

Origin and what the shape means

Design Council dates the launch of its Double Diamond to 2004. Its retrospective history acknowledges earlier work on divergence, convergence and iterative design. The Council’s contribution was to codify and popularize an accessible representation, not to invent every underlying idea. History of the Double Diamond

The first diamond concerns understanding and framing a problem; the second concerns exploring and refining responses. A widening shape represents opening possibilities, while a narrowing shape represents choosing a focus.

That simple distinction is useful in meetings. Are participants adding observations, proposing interpretations, comparing options or deciding? Confusion about the mode can make a discussion frustrating: one person is still questioning the problem while another expects approval of a preferred solution.

The practical instructions in this article are editorial guidance. They apply the model’s broad logic without claiming to be Design Council’s official workshop script.

When to use it

Use the Double Diamond when the problem is only partly understood, when an initial brief may conceal assumptions, or when several plausible responses deserve exploration. It can also help explain to a sponsor why a team needs time to investigate before committing to implementation.

For a routine task with a known answer, a full discovery exercise may add little. Scale the inquiry to the uncertainty and consequences. A small content improvement might need a few focused observations; a service redesign spanning organizations requires more substantial investigation.

The framework does not determine budgets, research quality or decision authority. Agree those separately. In particular, name who can approve a reframed problem. A team cannot meaningfully explore alternatives if nobody has authority to act on what it learns.

Discover: examine the situation

Begin with an open question. “Why are people abandoning this process?” leaves room for investigation. “How do we persuade everyone to use our app?” embeds both the solution and a preferred explanation of the problem.

Gather evidence from people, the environment and available records. Observe the current journey where feasible. Speak with those who perform the work and those who encounter its consequences. Look for workarounds, waiting, repeated explanations and points where responsibility becomes unclear.

Distinguish observation from interpretation in the notes. “A participant asked a colleague to complete the form” is different from “users lack confidence.” The second may be plausible, but it needs examination.

Government Digital Service discovery guidance offers a compatible practical approach: investigate users, wider context and constraints before deciding what to build. It is separate guidance, not a validation study of the Double Diamond. How discovery works

As editorial guidance, end the first investigation with a question log: what is supported, what remains uncertain and whose experience is missing? Do not disguise an incomplete sample with a confident persona or an attractive journey map.

Define: choose a problem worth addressing

Review the evidence with the team. Group observations where the connection is defensible, preserve important exceptions and test competing explanations. A frequent complaint is not necessarily the most consequential problem.

Write a problem statement that identifies the affected group, situation and consequence. Add the boundary and the evidence behind it. For example: “New customers cannot tell which documents are needed before their appointment, leading to avoidable return visits.”

A useful statement leaves room for different responses. “Customers need a chatbot” is a proposed solution. “Customers need to understand the requirements before traveling” permits changes to information, reminders, staff support or the underlying requirement.

Use this editorial checkpoint before moving on:

Check	Evidence to bring	Warning sign
Is the problem real in the investigated setting?	Observations and available records	Only sponsor opinion
Is the interpretation plausible?	Competing explanations considered	One anecdote treated as proof
Is the boundary useful?	Dependencies and excluded groups	Important handoffs ignored
Can the team act?	Decision owner and constraints	Reframing is allowed only on paper
Will improvement be recognizable?	Intended outcome and baseline plan	Success means finishing the project

A checkpoint is a conversation about uncertainty, not a certificate that discovery is complete.

Develop: explore different responses

Generate alternatives against the defined problem. Include operational and policy changes alongside digital products. Where appropriate, combine ideas or test individual parts before building an integrated solution.

Use the 90-minute idea workshop if a group needs a structured session. Bring evidence into the workshop so that ideas respond to the situation. Creative variety is useful only if the team can subsequently examine what each option requires.

For each option, state its most important assumptions. Choose prototypes that answer those assumptions. A sketch can test whether someone understands an arrangement; it cannot establish the reliability of a technical integration.

GDS alpha guidance focuses on trying ideas and testing risky assumptions with prototypes. This provides a useful companion for practical experimentation, while remaining a different delivery framework. How alpha works

Our practice recommendation is to record the question, method, participants or data, observation and next decision for each test. Avoid turning a prototype demonstration into a vote on which design people like most. Observe the task that matters.

Deliver: establish a workable response

Narrow the options based on evidence, refine the selected response and test it in conditions closer to actual use. Check operational ownership, support, accessibility, dependencies and exceptions. The scale of these checks should reflect the consequences of failure.

Design Council includes small-scale testing, rejecting unsuitable solutions and improving promising ones in its description of Deliver. Delivery still involves learning. Framework for Innovation

As editorial guidance, agree who can authorize expansion, what evidence they need and what would trigger a pause. Write down what the next test cannot establish. A limited trial may reveal usability problems while leaving long-term demand uncertain.

Implementation matters when using the word innovation: the Oslo Manual distinguishes implemented change from an idea alone. The Double Diamond does not itself establish whether a result meets a statistical definition or creates worthwhile value. Oslo Manual 2018

Hypothetical example: preparing for an appointment

Imagine a local service office receiving complaints about repeat visits. This is a fictional teaching example.

In Discover, the team observes appointments, interviews residents and staff, and reviews reasons recorded for incomplete applications. Its initial assumption is that people forget documents. Investigation raises another possibility: the instructions do not clearly distinguish different circumstances.

In Define, the team focuses on helping first-time applicants identify the documents relevant to their situation before traveling. It records uncertainty about people who cannot use the online channel.

In Develop, it compares a revised letter, a short decision guide and a staff-assisted preparation call. Each responds to the same problem through a different mechanism. Prototypes test whether people understand which documents apply.

In Deliver, it trials a combined approach in a limited setting. The team checks staff effort and access as well as incomplete applications. If the approach works only when a specialist explains it, that is a design finding requiring attention before expansion.

No improvement rate is claimed. The example illustrates the decisions and evidence a team would need.

Measure and revisit the problem

Set a baseline for the intended outcome and monitor possible side effects. In the example, fewer repeat visits would be valuable only alongside an understanding of staff workload and whether some applicants stopped attending altogether.

GDS benefits guidance recommends comparing observed results with earlier estimates and updating the case for continuing. This is useful for avoiding a celebratory launch that never returns to the original problem. Measuring service benefits

As practice guidance, schedule a review after the new arrangement has experienced ordinary operating conditions. Ask whether the problem statement still fits. New evidence may justify returning to Define or Discover.

Strengths, limits and next steps

The framework offers a shared language for exploration and choice. Its simplicity also omits much of what makes work difficult: politics, conflicting goals, unequal participation, research access and long-term operational responsibility.

The sources establish the model’s identity and offer compatible practice guidance. They do not demonstrate that following four named stages causes superior results in every setting. Avoid using the diagram as a compliance exercise or a substitute for research skill.

Start by locating your current uncertainty: understanding the problem, choosing its boundary, exploring responses or establishing reliable use. Select one concrete activity to answer that uncertainty. Connect the work to innovation management for investment decisions, and use a premortem before a consequential implementation.