The Double Diamond: The Design Council's Design Process

Created by Design Council - https://www.designcouncil.org.uk/our-resources/the-double-diamond/

Overview

The Double Diamond is a picture of the design process drawn as two diamonds side by side, split into four phases: Discover, Define, Develop and Deliver. It comes from the Design Council, the UK's national strategic advisor for design, which describes the two diamonds as a process of exploring an issue more widely or deeply (divergent thinking) and then taking focused action (convergent thinking) in its Framework for Innovation. The first diamond works on the problem. The second works on the solution. Each diamond opens out and then closes, so a team goes wide twice and narrows twice before anything ships.

The model grew out of a practical question. According to the Design Council's history of the Double Diamond, in 2003 its Director of Design and Innovation, Richard Eisermann, asked his team how to describe design process, because the organisation was promoting design management while lacking a shared description of the work. A group of Design Council staff and independent design strategists produced four phases and chose alliterative names on purpose so people would remember them. The Design Council began sharing the diagram at conferences and in presentations in 2004, its history page says, and its 2007 research report on managing design was structured around it.

That report is where many secondary sources get their dates. The Design Council's Eleven lessons study interviewed the design heads of eleven companies in 2007 and states that the diagram was developed through in-house research in 2005. So the study applied an existing model to what it found; it did not produce the model. The Design Council's own current pages give 2003 for the work and 2004 for the launch, and this page follows them. The diverge-then-converge shape itself is older: the Wikipedia entry traces it to a 1996 divergence-convergence model by Béla H. Bánáthy, whom it describes as a Hungarian-American linguist.

In 2019 the Design Council placed the diagram inside a larger Framework for Innovation. Its 2019 framework diagram keeps the four phases between a challenge and an outcome and adds four design principles, a methods bank organised as explore, shape and build, and two conditions around the process: leadership and engagement. The framework diagram also carries arrows that loop back, and the Design Council says plainly that "this is not a linear process."

The practical value of the model is that it names two failure points a team can check for. The first is converging on a problem too early: building a fix for the problem someone assumed instead of the one research shows. The second is converging on a solution too early: taking the first workable idea into delivery without generating or testing alternatives. The Double Diamond gives each of those decisions its own convergent phase, with an explicit output (a problem definition, then a tested solution) that the team can review before moving on.

The model prescribes no tools. It tells a team which kind of thinking a phase needs, and leaves the choice of methods to the team, which is why it is used in product design, service design, public policy and internal change programmes. That openness is also its main weakness: the four words alone do not tell anyone how much research is enough or who decides when a phase is done, so a team has to agree those things itself. If you keep your team's process and decisions in Hamster, record the problem definition from Define there so later phases and agents work from the same statement.

Core Principles

Diverge before you converge

Each diamond starts by widening the set of options and ends by narrowing it. The Design Council's Framework for Innovation describes the two modes as exploring an issue widely or deeply, then taking focused action. The order matters because convergence can only choose among the options that divergence produced. A team that narrows first ends up choosing from a short list it never questioned.

Separate the problem from the solution

The first diamond ends with a definition of the problem, and only then does solution work begin. The Design Council says the first diamond "helps people understand, rather than simply assume, what the problem is" on its Double Diamond page. Holding the two apart gives the team a stable target to judge ideas against. When ideas are debated before the problem is agreed, people are usually arguing about different problems.

Put people first

The framework's first design principle is to start with an understanding of the people using a service, their needs, strengths and aspirations. In practice this means Discover involves speaking to and spending time with the people affected, as the framework page puts it. Desk research and internal opinion are inputs, but they do not replace contact with users. A phase that produced no new evidence about people has not done its job.

Communicate visually and inclusively

The second principle asks teams to help people gain a shared understanding of the problem and the ideas. Journey maps, sketches, prototypes and the diamond diagram itself are the usual vehicles, because a picture can be checked and corrected by people outside the design team. The 2019 framework diagram lists this principle as "Communicate (Visually & Inclusively)." Visible work also makes it obvious when two stakeholders hold different pictures of the same project.

Collaborate and co-create

The Develop phase in particular asks teams to seek inspiration from elsewhere and co-design with a range of different people. Engineers, operations staff, subject experts and the users themselves each spot problems and possibilities the design team misses. Co-creation also spreads ownership, which makes the Deliver phase easier because fewer people meet the solution for the first time at launch. The cost is facilitation time, so plan for it.

Iterate, and expect to loop back

The framework's fourth principle is "Iterate, iterate, iterate," to spot errors early, avoid risk and build confidence in ideas. The Design Council also notes that many organisations it supports learn something about the underlying problem that sends them back to the beginning of the diamond. Treat a loop back as information about the problem, and budget time for at least one. A project plan with no room to return to Define is betting that the first framing was right.

Decide with evidence at each convergence

Both convergent phases end in a decision: which problem to solve, and which solution to ship. Base each on what the preceding divergent phase found, and write down the evidence behind it. This protects the decision from the most senior opinion in the room and gives the next phase something concrete to test against. If the evidence is thin, say so and treat the decision as a hypothesis.

Steps

1. Discover: explore the problem space Start from the challenge as it was handed to you and treat it as a starting hypothesis. Talk to and observe the people affected, review existing data such as support logs and analytics, and speak to the staff and partners who deliver the current service. The Design Council describes this phase as helping people understand, rather than assume, what the problem is. Collect findings without ranking them yet, since early filtering removes the surprises that make discovery worth doing. The output is a body of raw evidence and a list of open questions.

2. Define: frame the problem worth solving Sort the evidence into themes, turn the themes into insight statements, and choose which problem to take forward. Affinity mapping, journey maps and "How might we" questions are common tools here. The Design Council's Eleven lessons study describes Define as aligning user needs with business objectives, ending in a project brief. The problem you choose may differ from the one in the original brief, and that is a legitimate outcome. Get explicit agreement on the definition before moving on.

3. Review the definition before opening the second diamond Put the problem definition in front of the people who will fund and build the solution. Check three things: that it is backed by evidence from Discover, that it names who is affected and what they need, and that it does not quietly contain a solution. If a stakeholder cannot accept the definition, resolve that now, because the disagreement will otherwise resurface as a fight about ideas. This checkpoint is short, but skipping it is the most common way the two diamonds blur into one.

4. Develop: generate and explore solutions Open out again, this time on answers to the defined problem. Run ideation sessions, co-design with users and delivery staff, look at how other fields handle similar problems, and sketch several directions instead of refining one. The Design Council says this second diamond encourages people to give different answers to the clearly defined problem. Build cheap prototypes early so ideas can be compared on something tangible. The output is a set of distinct concepts, each testable.

5. Deliver: test, narrow and ship Test the concepts at small scale, reject those that fail, and improve those that work, which is how the framework describes delivery. Raise prototype fidelity as confidence grows and check feasibility and cost alongside user results. When the evidence points to one direction, prepare it for launch with the people who will build and run it. Keep a feedback loop after launch, since the framework notes that in a digital world no idea is ever finished.

6. Loop back when evidence says so At any point a finding may show that the problem was framed wrongly. When that happens, go back to Define (or Discover) deliberately instead of patching the solution. Record what changed and why, so the team and stakeholders understand the move. A loop back caught during Develop costs far less than one discovered after launch.

When to Use

• A problem is ambiguous and the team disagrees about its cause. The first diamond gives a structured way to settle that with evidence before any build work starts.
• You are designing a new service or product where nobody yet knows what users need. Discover and Define create the understanding that later decisions depend on.
• A cross-functional group needs a shared vocabulary for where a project stands. The four phase names give designers, engineers and managers the same words for "we are still exploring" and "we are deciding."
• Your team keeps shipping solutions that miss. A Double Diamond makes the problem definition an explicit, reviewable output, which exposes solutions built on untested assumptions.
• You are redesigning a service across several channels or teams. The framework's emphasis on engagement and co-creation fits work where many groups deliver parts of the experience.

When Not to Use

• The problem is known and validated, such as a reproducible bug or a well-specified compliance change. Running a full Discover phase would spend time confirming what you already know.
• You are responding to an incident or outage. Speed of fix matters more than exploring the problem space, and a post-incident review is the better place for broader learning.
• The difficulty is technical execution with little uncertainty about users, such as a database migration. Engineering methods fit that work better than a design process.
• There is no time or access for real research. A Discover phase with no contact with users produces a problem definition that looks rigorous but rests on the same assumptions as before.

Double Diamond Compared With Related Models

The Double Diamond is the most abstract of these: it describes the shape of the thinking and says little about methods. The d.school presents its modes as a set of tools you can start anywhere in, while the GOV.UK phases add funding and go or stop decisions to a similar arc.