The Double Diamond Is a Map, Not the Terrain

You have seen the diagram. Two diamonds, four neat phases, a smooth line from problem to solution. It looks great on a slide. Then you run a real project and nothing lines up. Discovery bleeds into ideation. You loop back three times. Someone asks where the strategy work went, and the diagram has no answer.

The problem is not the model. The model is useful. The problem is that leaders treat the picture as the process. They believe the tidy version and then feel like they are failing when their team's work looks messy. It always looks messy. Your job is to know what the diagram hides, and to pick a process that fits the project in front of you.

The deep cut

• The diagram is a shared language, not a schedule. The British Design Council built the Double Diamond to explain design, not to time it.
• Believing the tidy line breaks your team's confidence. When work loops and overlaps, teams following the clean diagram feel broken, which is why Eduardo Hernandez calls for an emergent mindset instead.
• Match the process to the project before you start. Dan Ramsden lays out other models for when the diamond stops fitting the work.

What the diamond actually gives you

The real value is one idea: the problem matters as much as the solution. Jeff Humble puts it plainly, the model shows two distinct jobs, problem-finding and problem-solving. Before the diamond got popular, people thought design was only the second job, the making part. The first diamond names the research work out loud so non-designers can see it exists.

The other gift is a rhythm. You alternate between opening up and narrowing down. Dana Mitroff Silvers calls trying to do both at once "driving with the brakes on." That line alone is worth keeping. When someone kills an idea the second it lands, they are converging in a room that should be diverging. Naming the mode ends that fight fast.

Where the model hides the hard parts

The clean line lies about three things. First, the loops. The diamond looks like a one-way trip, but real work sends you back. Yuri Teodorowych argues the diagram is too clean and pushes for an honest, messier version where feedback loops live everywhere, not just at the end.

Second, the setup. The diagram starts at Discover, as if a clear problem drops in your lap. It does not. Someone framed that brief, fought for budget, and picked which problem was worth solving. That work is invisible on the slide.

Third, the overlap. Maciej Lipiec offers a Three Triangles model where Discovery, Ideation, and Delivery run in parallel, not in sequence. That is closer to how teams actually operate. You are testing a prototype while still learning about the problem. The diamond cannot show that. The triangles can.

Skip a phase when the answer is obvious

Here is where leaders overspend. They run the full process on problems that do not need it. Victory Brown gives a sharp example: a checkout field labeled "Address" confuses users about billing versus shipping. The fix is clear. You skip Develop and go straight to a UX writing change. No workshop, no ideation sprint.

The model is flexible if you let it be. You can start anywhere. You can blend phases. You can revisit Discover after a failed test. Define a success metric before you begin, so you know when you are done. Without that number, you cannot tell if the work landed.

Treat the four phases as a checklist of questions, not a set of gates. Do we understand the problem? Have we framed it? Have we explored options? Have we picked and tested one? If you can answer yes already, move on.

Pick the tool that fits the work

The diamond is one option, not the only one. Sakshi Bhardwaj lists several that fit different jobs. A Design Sprint compresses the whole arc into five days when you need a fast answer on a big bet. Lean UX pairs design with agile when you are shipping and learning in real markets. Systems Thinking fits when the parts of your product tangle into each other.

Changing process has a cost, and it is fair to weigh it. Dan Ramsden frames the real question as whether the diamond still fits your work, and what switching would take. A team that knows one shared model moves fast together. Swap it every quarter and you spend more time arguing about process than doing the work.

So keep the diamond as your common language. Use it to name modes and mark handoffs. But do not force every project into two neat shapes. The map is not the terrain. Read the ground first.

Three questions for your team

• Look at our current project. Is the process actually linear, or are discovery and delivery running at the same time? If they overlap, stop pretending the diagram fits and share milestones across the tracks instead.
• For this specific problem, is the answer already clear from research? If yes, name which phase we can skip and move straight to delivery.
• Does the Double Diamond still match how we work, and if not, which alternative fits, and what would switching cost the team in speed and shared understanding?