Double Diamond

For a long time the middle of design work was invisible from outside it. A product manager handed over requirements, a designer came back some days later with screens, and what happened in between was known only to the designer. When the work ran late there was no vocabulary for asking which part it had stalled in.

So the same meeting kept repeating. Only after the screens existed did anyone ask whether this was really the problem the team set out to solve, and by then three weeks were gone. Going back felt wasteful, so teams mostly pushed forward.

The UK Design Council drew the process as two diamonds in 2005, and that middle became something you could point at. Widening stretches alternate with narrowing ones, the first pair applied to the problem and the second to the solution.

What the drawing does is show which box a team is standing in and which box it skipped. The skipped box is almost always the same one. Teams drop the first diamond entirely and start generating solutions, which produces a room full of people proposing things while nobody can state what problem those things solve.

You pass through four boxes in order, and each box has something it has to produce before the next one starts.

1. Discover — widen the problem. User research is the engine here: observing and asking until you have evidence rather than opinion. Eight customer interviews, a read through 300 support tickets, a look at where people drop out of the data. Judgment is suspended; you are only collecting material.
2. Define — narrow to one problem. Group what you collected, cluster the similar pieces, and pick the single one most worth solving now. The output is a one-sentence problem statement. At Pagedeck it might read: "people in their first week leave without realizing they can comment on someone else's document." If two sentences survive, the narrowing hasn't happened yet.
3. Develop — widen the solution. Take the one problem and build several genuinely different answers to it. Twelve sketches, three of them turned into a prototype — a rough build made only to get a reaction, which can be a screen drawn on paper. If one option comes out of this box, nothing was chosen; the first idea was simply kept.
4. Deliver — narrow to one solution and ship it. A usability test puts a real task in front of real users, the sticking points get fixed, and the work goes to engineering. Watching the numbers after release belongs to this box too.

Widening boxes and narrowing boxes run on different meeting rules. While widening, hold off on evaluation and just raise the count of options. While narrowing, agree on criteria first and cut against them. Mix the two modes in one meeting and every proposal gets argued down as it appears, leaving whichever idea came up first.

How long each box takes isn't fixed, but giving the two diamonds comparable time is the original intent. On a six-week project that means three weeks on the problem. In practice, four days on the problem and five weeks on the solution is far more common.

It fits work where what to build hasn't been settled. "Drop-off is high and we don't know why" is the shape — you have to find the outline of the problem before anything else. The same goes for a first move into an unfamiliar area, or for complaints arriving from several directions without converging on one cause.

It's too much machinery when the problem is already narrow. If you know the card-number field on the checkout screen is cramped enough to cause typos, spending two weeks on discovery and definition buys nothing that fixing it wouldn't. Work where a regulation dictates the requirement, or where another team has already decided and you are drawing what they decided, behaves the same way.

Three limits are worth knowing.

The first is that the picture flows one way. Real work loops back: a prototype built in box three sends you back to rewrite the problem statement from box two. Treating one clean pass as the standard makes it tempting to ignore what you learned late.

The second is that the boundaries are less crisp in practice than on paper. Solutions occur to you during research, and new problems surface while you build a prototype. The model names what you are mainly doing, not what you are forbidden from doing.

The third is that the drawing does not enforce the time split. A team that skips the first diamond still uses the same diagram, so "we completed all four stages" and "we picked the problem in four days" can sit side by side in the same report.

"Can we move into the second diamond? The problem statement is still three sentences."

Narrow the problem to one before anyone starts widening solutions.

"This week is a widening stretch, so add options instead of cutting them."

Defer evaluation and build up the set of choices first.

"We started without the first diamond, so we're back collecting evidence now."

The team is paying late for the research it skipped.

At Pagedeck, Noa raises this most often in project kickoffs. When Mia proposes improving search, Noa's question is which box the work starts in. If nobody knows why search goes unused, it starts at the first diamond. If everyone already agrees the problem is how results are ordered, it starts at box three.

Fixing the box also fixes what kind of meeting the week needs. Widening stretches call for a design critique, where intent and reasoning get examined together; right after narrowing, you want the session where engineering and product actually conclude something.

The most common misreading is treating it as a procedure you walk through once, in order. The diagram runs left to right, so that reading is a fair guess. In reality what you learn in a later box regularly overturns an earlier conclusion, and going back at that point is the model working, not failing. Teams that believe in the single clean pass discover in box three that the problem statement was wrong and carry on anyway because of the schedule. Features shipped in that state tend to go unused, and six months later the same problem comes back around from the start.

The second is reading the widening stretches as brainstorming sessions. "Widen" sounds like getting everyone in a room to say whatever comes to mind. What the first diamond widens is facts, not ideas — where users actually get stuck, the words complaints arrive in, what the data shows. Fill that box from inside a meeting room and an hour later all you have is the eight opinions the team walked in with.