Most teams are not short of ideas. They are short of agreement on the problem. The double diamond exists for one reason: to stop a team from sprinting toward a clever answer to a question nobody has actually pinned down. It does that by drawing the work as two diamonds, explore wide, then narrow; explore wide again, then narrow, and refusing to let you skip the widening.

The quick version

  • Design thinking is a human-centred way of solving problems: understand real people first, generate many options, prototype cheaply, and test before you commit.
  • The double diamond is the best-known map of that process, four phases in two diamonds: Discover, Define (the problem) and Develop, Deliver (the solution).
  • Each diamond is a diverge-then-converge move: open up to explore, then close down to decide. The discipline is resisting the urge to converge too early.
  • It is a thinking aid, not a guarantee. Treat it as a lens, run it lightly, and judge it by outcomes, not by how many workshops you held.

The idea in depth

The phrase sounds modern, but the root idea is older than the sticky notes. In 1969, the polymath Herbert Simon defined design in a way that has nothing to do with aesthetics: "Everyone designs who devises courses of action aimed at changing existing situations into preferred ones" (The Sciences of the Artificial, p. 55). By that definition, every manager is a designer. The thing being designed is just a course of action, and the question is whether you arrived at it well.

The modern, business-facing version was popularised by Tim Brown, then chief executive of the design firm IDEO, in his 2008 Harvard Business Review article "Design Thinking." Brown's core claim is that design thinking matches "people's needs" with what is "technologically feasible" and "viable as a business strategy", and that empathy, not artistry, is the engine. The designer's habit worth borrowing, he argued, is starting with the human and working back to the solution, rather than starting with the solution and hunting for someone to sell it to.

Borrow that habit for your next initiative: treat it as a design problem. Before the roadmap, before the build, ask who has the problem, what they're actually trying to get done, and how you'd know if you solved it. That single reframe, from "what should we build" to "whose problem are we solving and how do we know", is most of the value, and you get it before running a single workshop.

The two diamonds

The visual that made design thinking legible to executives came from the UK's Design Council, which developed the double diamond in the mid-2000s (commonly cited as 2005) after studying how design actually happened inside firms such as LEGO, Sony and Starbucks. The model splits work into four phases across two diamonds.

flowchart LR
    A(["Brief / challenge"]) --> B(["Discover
diverge: explore the
problem space"])
    B --> C(["Define
converge: frame the
real problem"])
    C --> D(["Develop
diverge: generate
many solutions"])
    D --> E(["Deliver
converge: test &
ship the best one"])
    E --> F(["Outcome"])
The double diamond: two diverge-then-converge cycles, one for the problem and one for the solution. Leaders Loop

The first diamond is the problem space. In Discover you go wide, research, interviews, watching real users, without rushing to conclusions. In Define you narrow, synthesising what you saw into a sharp problem statement. The second diamond is the solution space: Develop goes wide again, generating and prototyping many possible answers, and Deliver narrows to test, refine and launch the one that works.

The geometry is the whole point. Each diamond is a deliberate sequence of divergent thinking (open up, defer judgement, collect many options) followed by convergent thinking (filter, prioritise, commit). The most common failure in real teams is doing only the second half, converging on the first plausible idea and calling it strategy.

A diamond is just permission to stay open a little longer than feels comfortable, then a forcing function to actually decide.

So say it out loud in the meeting: name which half of which diamond you're in. "We're still diverging, no deciding yet" protects a team from its own impatience during Discover and Develop. "We're converging now, what are we cutting?" gives permission to kill options during Define and Deliver. Most unproductive workshops are people doing both at once and frustrating each other.

What the evidence actually supports, and where it thins out

Be honest about the weight of evidence here. The double diamond is a well-tested practitioner framework, not a finding from controlled trials. The Design Council itself has since softened the tidy four-box picture: its updated Framework for Innovation notes that teams routinely loop back, that early-stage testing happens during discovery, and that "no idea is ever finished." So the linear left-to-right arrow is a simplification of a messier, iterative reality.

There's sharper criticism too. In a 2018 HBR piece, NYU professor Natasha Iskander argued that design thinking is "fundamentally conservative", that by keeping designers in control of framing the problem, it can quietly preserve the status quo and miss the politics surrounding genuinely hard ("wicked") problems. You don't have to fully agree to take the warning: the framework can produce a lot of visible activity (workshops, walls of sticky notes) and very little changed outcome.

Hold the model loosely, then. Use the four phases as a checklist of questions you might otherwise skip, not as a ritual to perform. Judge a design-thinking effort by whether a real user's life got measurably better, not by how photogenic the workshop was. And on a politically loaded problem, put the people who hold the power and the people who hold the pain in the room early, don't let "the designers" frame it alone.

A worked example

Take a mid-sized software firm whose support tickets are climbing. (Figures below are illustrative.) The instinctive response is a solution: "build a chatbot." That's converging inside the second diamond before the first one has even opened.

Run it as a double diamond instead. In Discover, the team listens to 20 support calls and shadows five customers. They go wide: no fixes yet, just patterns. In Define, they converge on a finding, roughly 60% of tickets aren't really questions, they're customers stuck at the same two steps of onboarding. The problem reframes from "we need faster support" to "people can't get started." That sentence is the output of the first diamond, and it kills the chatbot idea on the spot, because a chatbot would answer the same broken questions faster.

Now the second diamond. In Develop, they generate eight options, an inline tooltip, a setup wizard, a default template, a 90-second video, a "skip for now" button, and more, and paper-prototype the cheapest three. In Deliver, they test those with eight new users, ship the setup wizard and the default template, and watch the metric. Say onboarding-related tickets fall by a third over the next quarter. The win didn't come from a smarter solution. It came from spending two extra weeks in the problem space before anyone wrote code.

flowchart TD
    A(["Symptom: support tickets rising"]) --> B(["Discover: shadow users,
listen to 20 calls"])
    B --> C(["Define: ~60% of tickets =
stuck in onboarding"])
    C --> D{"Reframe the
problem?"}
    D -->|"Yes"| E(["Develop: prototype
wizard, template, tooltips"])
    E --> F(["Deliver: ship + measure
ticket volume"])
    D -->|"No"| G(["Build a chatbot,
faster wrong answers"])
Illustrative: the reframe in the first diamond changes which solution you build. Leaders Loop

The same shape applies far outside software. A reframe is the high-leverage moment in almost any improvement effort, see customer needs identification & latent needs for how to surface the problem people can't articulate, and ideation & co-creation techniques for filling the second diamond with options worth testing.

Frequently asked questions

Is the double diamond the same as design thinking?

Not quite. Design thinking is the broad, human-centred philosophy (empathy first, prototype, test). The double diamond is one specific map of that process, the Design Council's four-phase model. You can practise design thinking using other maps (IDEO's "inspiration, ideation, implementation," or Stanford d.school's five modes); the diamonds are just the clearest picture of the diverge-converge rhythm.

Does it have to run in order?

No. The clean left-to-right arrow is a teaching diagram. In practice you loop: a prototype in Develop often sends you back to Define because you misread the problem. The Design Council's own updated framework stresses this. Treat the phases as states you move between, not a one-way conveyor belt.

How is this different from a design sprint?

A design sprint compresses a version of this rhythm into a fixed five days to get a tested prototype fast. The double diamond is the broader, untimed model of the whole problem-to-solution journey. A sprint is one intense way to traverse the second diamond (and part of the first).

Isn't this just common sense dressed up?

Partly, and that's a feature. The value isn't novelty; it's that naming the phases stops smart, busy people from quietly skipping the one they're worst at, which is almost always staying open in the problem space. Common sense that teams routinely ignore is worth making explicit.

How long should each phase take?

There's no fixed rule, but watch the balance. Teams chronically underinvest in the first diamond. If you've spent more than half your time generating and building solutions before you can write your problem in one clear sentence, you've converged too early.

Related in the Toolkit

Where to go next