The Design Thinking Process: The 5 Stages, Step by Step

Every diagram of the design thinking process shows the same five boxes with arrows between them: empathize, define, ideate, prototype, test. What no diagram shows is how long you stay in each box and what you must be holding before you're allowed to leave it. Teams rarely fail at this because they got the order wrong. They fail because they gave each stage an afternoon and treated the output as a decision. What follows is the operating version — what each stage is for, what "done" has to look like, and how each one gets faked.

For what design thinking is, and why the arrows matter less than they look, start with the complete guide.

Stage 1 — Empathize: buy yourself a real problem

The point of this stage is to replace your team's theory of the user with contact.

In practice that's five to eight interviews, or three or four sessions watching someone attempt the job in whatever they use today. A survey won't do it — a survey confirms what you already thought to ask about, and this stage exists to surface what you didn't. Run the sessions yourself if you'll be making the calls later; insight doesn't survive being relayed through a summary deck. Our guide to running user interviews has the mechanics.

Done means you can name at least one thing you believed on Monday that you no longer believe. Write it down. That single reversal is the return on the stage.

How it fails: the confirmation round. The team already knows what it wants to build, so it talks to people likely to agree, asks leading questions, and comes back with quotes that support the roadmap. The tell is the absence of surprise. If nothing in the readout contradicted the plan, the stage was a ceremony.

Cost: one to two weeks. Below a week you're mostly talking to whoever was easy to reach.

Stage 2 — Define: write the problem you're actually solving

This is the shortest stage on the calendar and the one that most determines whether the rest was worth doing.

The job is to turn a pile of observations into one problem statement narrow enough to be wrong. Cluster what you heard, throw out most of it, and write a single sentence: [user] needs a way to [do something] because [insight that surprised you]. The "because" has to come from stage one and not from the business case — that's the clause that makes the sentence yours rather than a restatement of the quarterly goal. If you can swap in any user and any product and the sentence still reads fine, it's too vague to steer anything downstream.

Two failure modes live here, and they're easy to tell apart once you know the shapes.

The first is solution smuggling: the statement arrives with the answer already inside it. "Users need a dashboard" is a feature wearing a problem's clothes. Strip the noun out and see whether a problem is left standing.

The second is unfalsifiability. "Users want a better experience" can't be argued with, which means stage five will have nothing to measure against and every test will pass. Hand the sentence to someone on the team and ask them to argue the opposite; if they can't find a foothold, it's not a problem statement yet.

You're done when you have one statement — not five — that a colleague can attack. Budget two to four hours of genuinely difficult argument, usually split across two sessions with a night in between. The overnight gap does real work: the second session is where the smuggled solutions get spotted.

Stage 3 — Ideate: get past the first three ideas

Generate enough options that the obvious one has competition.

Do individual silent generation first, then share. Group brainstorming as usually practiced — everyone riffing out loud in a room — reliably produces fewer and more similar ideas than the same people writing alone and combining afterwards, an effect measured since Diehl and Stroebe's work on brainstorming productivity loss in 1987. Set a quota, because a quota is what pushes you past the three ideas everyone walked in with. The fourth through twentieth are where anything unexpected lives.

Done means three to five approaches that would fail for different reasons. Three variations on one screen layout is a single idea, counted three times.

How it fails: convergence by seniority. The most senior person names a favourite at minute ten and the remaining hour elaborates it. Silent generation before discussion is the countermeasure, which is why it's first rather than optional.

Cost: two ninety-minute sessions with a day between them.

Stage 4 — Prototype: build the cheapest thing that can be wrong

Make the idea concrete enough that someone can react to it instead of imagining it.

Fidelity should track how much you're willing to throw away. Paper, a clickable frame, a fake door, a script you read aloud while someone points — any of these beat a polished build, because high fidelity too early buys sunk cost, and once nobody's willing to discard the artifact it has stopped doing a prototype's job. Two days to a week is the range; three weeks in, you'll defend it instead of testing it.

The bar for moving on is low and absolute: a person can attempt the task without you narrating. Explain it first and you'll end up testing your explanation.

The failure here announces itself late. Someone notices the clickable version is "basically done," the disposable artifact turns into a shipping decision, and the room quietly stops asking what would make it fail.

Stage 5 — Test: try to break your own idea

Find out whether the problem statement from stage two was right. Whether people like the design is a different and much less useful question.

Five or so people attempt the real task while you shut up and watch. Score against the problem statement, not against a satisfaction rating — "did they finish, unaided, and where did they stall" tells you something, and "was that easy?" tells you how polite your participants are. The step-by-step usability testing guide has the protocol; the research methods hub covers when to reach for something other than a task test.

Done means you know which assumptions survived and which stage the failures point back to. Most failures don't point at the prototype. They point at define, or all the way back to empathize.

How it fails: testing for applause. Sessions run by the person who designed the thing, with questions that invite reassurance, produce a green light and no information. Have someone else moderate, and decide in advance what result would send you back a stage.

Cost: three to five days including recruitment, analysis and the readout.

What the arrows actually mean

The five stages are drawn in a line because a line is easy to print. Real projects run the design thinking process backwards more often than forwards: testing sends you to redefine, defining sends you back for more contact, prototyping reveals that two of your ideas were the same idea. That's the process functioning correctly.

The discipline worth building isn't sequence-following. It's noticing which stage a problem belongs to and returning there rather than patching forward. A confusing prototype is usually a define problem. An idea nobody can get excited about usually traces to empathize — you never found anything surprising enough to build from. Fix things at the stage that caused them and each loop gets shorter.

How long a full pass takes

A serious first cycle through the design thinking process is four to six weeks. A one-day workshop isn't a compressed version of that. It's a different activity — good for alignment, and actively risky when its output gets filed as evidence.

If you only have a week, run one stage properly instead of all five badly. A week of real empathy work leaves you knowing something on Friday you didn't know on Monday, which is more than a full lap of sticky notes will give you.

Where to go next

Start from the design thinking hub for the rest of the cluster, or read the complete guide for the mindset the stages are supposed to carry.

FAQ

What are the 5 stages of the design thinking process? Empathize, define, ideate, prototype, test. Empathize gathers first-hand contact with the problem, define narrows it to one falsifiable statement, ideate generates competing approaches, prototype makes one concrete cheaply, and test checks the statement against reality.

How long does the design thinking process take? Four to six weeks for a thorough first cycle. Later loops are far faster, because you're revisiting one stage rather than all five.

Is the design thinking process linear? No. It's drawn as a line for teaching. Real projects loop, most often from test back to define, and that backwards move means a test caught something your problem statement got wrong.

What's the difference between design thinking and the double diamond? Same underlying rhythm, different granularity — the double diamond names two diverge-converge cycles, the five stages break the same territory into named activities. For running the work, prefer the five stages: they name what you do, where the diamond only names which direction you're moving.

Can you skip a stage? Prototype and ideate, yes, when the solution is genuinely known and the risk is low. Skipping empathize or define is what produces well-built answers to the wrong question — the exact failure the process exists to prevent.

Who should be involved in each stage? Whoever will make the decision that stage feeds. Empathize and test need the people who'll design and build it, not only a researcher. Define needs whoever can say no to scope. Ideate wants the widest room you can assemble, engineering and support included.

Sources: NN/g — Design Thinking 101 · IDEO — Design Thinking · NN/g — Why You Only Need to Test with 5 Users.

Running the process and still shipping things users stall on? Apply for a Full UX Audit →