The five steps, and where they break

What is the design thinking process?

The design thinking process is a five-step method for solving problems you do not yet understand: empathize, define, ideate, prototype and test. It is a loop, not a pipeline. Teams re-enter earlier steps as evidence arrives, and the version taught by the Stanford d.school and IDEO has always said so. Most implementations quietly flatten it into a waterfall anyway.

That gap between the model and the practice is where the entire argument about the method sits. The published evidence for design thinking is real. So are the failure modes, and an honest guide has to carry both.

The five design thinking steps, and what each has to produce

Treat a step as unfinished until it has produced an artefact someone outside the room can challenge. Soft exit criteria are the most reliable way to stall a project in step three.

1. Empathize

Direct contact with the people who have the problem: interviews, observation, ride-alongs on the actual work. Many teams use an empathy map, a grid of what a user says, thinks, does and feels, to surface needs that a survey or a requirements document will miss. The output is observed behaviour with quotes attached, not a persona assembled from opinion.

2. Define

Compress the research into one problem statement narrow enough to be wrong. “Nurses cannot find the right form during handover” can be tested. “Improve the handover experience” cannot. If two people on the team would write different statements from the same research, this step is not finished.

3. Ideate

Generate options against that statement, including the ones you expect to reject. The output is a shortlist plus a written record of what was discarded and why, which is the part that survives into the next funding conversation.

4. Prototype

Build the cheapest thing that can fail in front of a user: paper, a clickable flow, a scripted role-play, a spreadsheet standing in for an algorithm. Fidelity buys nothing at this stage except delay.

5. Test

Put it in a user’s hands and record what breaks. The output is a decision plus the next question. Practitioners often draw the same journey as the double diamond, discover, define, develop and deliver, two cycles of widening then narrowing, the first on the problem and the second on the solution.

The step nobody draws is the sixth one: going back. A test that changes nothing about the problem statement is usually a test that ran too late, on a prototype already too polished to abandon. Plan the loop so the first test happens while the team is still willing to lose the work.

Does the design thinking process pay for itself?

In the two published datasets that connect design work to financial outcomes, yes, with a caveat that matters more than the headline. The clearest design thinking example at enterprise scale is IBM, which is also the most heavily measured. Forrester’s commissioned study of IBM’s practice modelled a 301% return over three years, built from $48.4M in benefits against $12M in costs for a composite organization.¹ Forrester also reported that teams using the method were 75% more efficient and shipped products nearly twice as fast.²

McKinsey’s Design Index points the same way from outside a single vendor. Companies in the top quartile of the index posted 32% higher revenue growth³ and 56% higher total returns to shareholders³ than their industry peers.

Read the caveats before quoting either number. The Forrester figure describes a composite organization assembled from interviews, in a study commissioned by the vendor whose method is being measured. The McKinsey result is a correlation across public companies, and firms that score well on design tend to be well run in other ways too. Both share one trait worth copying: the design work was tied to revenue and shareholder metrics from the start, not audited for value afterwards.

That is a practical instruction rather than a philosophical one. Before the first workshop, pick the number the work is meant to move and the baseline it moves from: completion rate on the task being redesigned, support contacts per thousand users, cycle time from request to release, revenue per active account. Then agree who reads it and how often. Teams that cannot name that number at the start rarely produce a defensible case at the end, whatever the method actually delivered.

Design work that was never instrumented cannot be defended later with someone else’s ROI number.

Where the design thinking process earns its critics

The best known challenge came from Natasha Jen of Pentagram, whose 2017 talk at 99U carried the deliberately blunt title “Design Thinking is Bullshit” and became the most cited public critique of the method’s rigour.⁴ Her charge is not that empathy is worthless. It is that the visible output of most design thinking is a wall of sticky notes, produced without an evidence trail or a craft standard, presented as though the workshop itself were the proof.

That criticism lands hard on ritual and barely at all on teams with real user access. Most design thinking criticism follows the same pattern: where the loop touches actual customers and produces testable artefacts, the failure modes Jen describes largely disappear.

Two structural critiques deserve the same honesty. The double diamond makes divergence look symmetrical and cheap, when in practice the second diamond is where budget and political capital run out, and teams converge early for reasons that have nothing to do with evidence. Empathy-first framing also overstates what an outsider can learn quickly. In regulated, clinical or deeply technical domains, a day of shadowing does not substitute for domain knowledge, and treating it as if it does produces confident, wrong problem statements.

The mundane blockers matter as much as the philosophical ones. Nielsen Norman Group names the three most common obstacles to adoption as a team that is not interested, no time, and not knowing where to start.⁵ None of those is solved by a better diagram.

There is a limit the method rarely admits to as well. Design thinking is strong on desirability and quiet on the two constraints that decide whether anything ships: technical feasibility and commercial viability. A loop that produces a well validated concept the platform cannot support, or that no unit economics will carry, has still failed. Engineers and finance belong in the room from the ideate step onward, not at the handover.

The four failure modes worth watching for

1. The one-shot loop. Teams prototype and test once, then stop. That converts a cyclical method into a single deliverable with a research preamble. The return trip from test back to define is the method.
2. The workshop without users. If nobody in the room has spoken to a customer in the past month, the session is opinion laundering. Book the users before you book the room.
3. The waterfall in disguise. Running empathize through to test as five sequential gates with sign-off between them is precisely what critics attack, and it is not what the model describes.
4. No measurement plan. Choosing what the work should move only after the work is done is how ROI claims collapse under finance review.

How is design thinking different from Agile and Lean UX?

They answer different questions and compose well. Design thinking decides what is worth building, Agile governs how it ships, and Lean UX attacks the riskiest assumption inside a product that already exists.

In practice the design thinking process feeds the backlog that Agile burns down. We keep the two visible as separate activities inside a product development consulting engagement rather than merging them into a single ceremony, because the moment discovery becomes a sprint task it gets cut when the sprint runs late.

How do you run the process without the theatre?

Six changes separate a loop that produces decisions from one that produces photographs of sticky notes.

• Name the decision the loop has to produce, in writing, before anyone books a session.
• Confirm user access first. No confirmed users, no workshop.
• Write the problem statement so a colleague could prove it wrong with a week of research.
• Prototype at the lowest fidelity that can still fail honestly.
• Schedule the second loop when you schedule the first, so a failed test has somewhere to go.
• Agree the metric on day one, with the person who owns the number in the room.

Scale changes the shape of this. IBM wrapped the plain five steps in governance, using Hills to state outcomes as user-level goals and Playbacks to force regular evidence reviews, because the vanilla loop stops coordinating once more than a few dozen people work against it.² Small teams do not need that machinery. Enterprise programmes do, and skipping it is a common reason a promising pilot never becomes an operating habit.

One discipline separates the teams that keep the habit from the teams that abandon it after two quarters: write down what the research changed. A one-page record per loop, covering the problem statement, what was tested, what the test killed and what the next loop will attack, is both the evidence trail that answers the sharpest criticism of the method and the only artefact that survives a change of sponsor.

The method has not been replaced. It has been absorbed, which is a different thing: the five steps now sit inside product operating models, service design and AI product discovery rather than standing alone as a branded workshop. If the open question is where the loop belongs in your own delivery model, our product development practice is organised around it, and you can put a specific problem in front of the team.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.