Double Diamond design process: solve the right problem before the right solution

Double diamond design process with two turquoise and yellow diamonds, sticky notes and prototype sketches narrowing to a finished product

Most design failures I hear about did not start with a bad solution. They started with a confident answer to the wrong question. The double diamond design process exists to stop that. Popularised by the British Design Council in 2005, it draws two diamonds side by side: the first for the problem, the second for the solution, each one opening wide before it closes down (Double Diamond).

Simple drawing. Hard discipline.

What the double diamond design process actually shows

The shape is the argument. A diamond widens, then narrows. That widening is research, listening, looking around, refusing the first tidy version of the brief. The narrowing is a decision: this problem, worded this way, is the one we will work on. Then the whole rhythm repeats for solutions. Open up again. Generate more than one answer. Test them. Narrow to the answer that survives contact with real people.

The model was adapted from a divergence-convergence model proposed in 1996 by Béla H. Bánáthy, and the Design Council turned that pattern into a picture non-designers could hold in their heads (Double Diamond). That portability explains its long life. In 2023 the Design Council marked twenty years of it by releasing a visual version under an open licence, with a template others could reuse.

Divergent and convergent thinking in design, twice over

Divergent and convergent thinking in design are not personality types. They are modes, and a project needs both at the right moments.

Divergent work suspends judgement. You interview people whose answers inconvenience the brief. You collect complaints that do not fit the category you were handed. You sketch twelve routes instead of defending one. Convergent work does the opposite, on purpose: it sorts, compares, cuts. It asks which evidence is strong, which idea can actually be built, which problem matters most.

Trouble starts when a team mixes the modes badly. Criticise during divergence and people stop offering the odd idea that might have led somewhere. Keep diverging during delivery and nothing ships. The diamonds give a team a shared language for that switch — we are opening up now, we are closing down now — which sounds small until you have sat in a meeting where half the room is brainstorming and the other half is pricing the funeral.

The double diamond model stages, walked honestly

The double diamond model stages are Discover, Define, Develop and Deliver. Treat the names as verbs, not departments.

Discover means understanding an issue rather than assuming it. Spend time with the people affected, and start from the issue, not the solution you already want to use (Double Diamond). LogRocket’s walk-through lists the practical kit: user interviews, surveys, analytics and competitor analysis, with everything documented rather than filtered early (LogRocket).

Define is where that pile of insight gets distilled. You look for chains of cause and effect, separate one problem from another, and state the challenge clearly enough that an outsider could repeat it back. The Design Council’s own wording allows the definition to change the question: insight from discovery can help you define the challenge in a different way (Framework for Innovation).

Develop opens the second diamond. Different answers to the clearly defined problem, inspiration taken from elsewhere, co-design with people from different specialties. A narrow team tends to produce the solution its own field always produces. A mixed one has a chance of surprising itself.

Deliver narrows again by testing. Try solutions at a small scale, reject the ones that will not work, improve the ones that will. Maze’s summary puts the same point in product language: prototype, test with users, refine, then implement and keep collecting feedback after launch (Maze).

The Design Council Framework for Innovation added the culture

In 2019 the Design Council folded the diamonds into its Framework for Innovation and surrounded the process with principles: put people first, communicate visually and inclusively, collaborate and co-create, and iterate, iterate, iterate (Framework for Innovation). Read those as working conditions, not decoration. A team can run four stages in order and still learn nothing if the people affected were never in the room.

The framework is also blunt about sequence. This is not a linear process. Learning more about an underlying problem can send a team back to the beginning, early prototypes can belong to discovery, and in a changing digital world no idea is ever finished. You keep getting feedback, and you keep improving the thing.

That is the part I use most in my own study and site work. Rebuilding iamarchie.com by hand, the temptation is to jump straight to the second diamond — colours, layout, a page that looks finished. The first diamond asks a slower question: what is this page for, and for whom? Some days the honest answer changes the brief.

Where the diamonds mislead

The drawing lies in one useful way: it makes the work look symmetrical and clean. Real projects are not. One phase eats three months, another an afternoon. A late discovery can blow up a definition everyone signed off, and going back feels like failure even when the model says it is the process working as intended.

Use it as a check, not a ceremony. Before solutions: can we state the problem in one sentence, and show the evidence behind it? Before delivery: did more than one answer get a fair test, or did the first idea win by seniority? If you can answer those two questions plainly, the diamonds did their job — no wall chart required.

Sources

Reddit
X
LinkedIn
Pinterest
Tumblr
[nextend_social_login]

Leave a Reply

Your email address will not be published. Required fields are marked *