Design thinking has the unusual distinction of being both one of the most widely taught product methods and one of the most widely mocked. Both reactions are earned. Run well, it is the most reliable way to stop a team from confidently solving the wrong problem. Run badly, it is a week of sticky notes that ends with the feature somebody already wanted to build.
The difference is almost never in the workshop technique. It is in whether the team treats the five stages as modes of work they can move between, or as a five-step schedule to march through once.
This guide covers what design thinking actually is, what each stage is supposed to produce, a worked example on a real SaaS problem, the criticisms worth taking seriously, and how it fits alongside the other frameworks product teams use.
Key takeaways
- The defining move is framing the problem before generating solutions — everything else follows from that.
- The five stages are modes, not phases. Testing sends you backwards constantly, and that is the process working.
- Each stage has a concrete deliverable. A stage that produces no artefact did not happen.
- Define is where most cycles are won or lost, and it is the stage teams rush hardest.
- On an existing product, analytics does the narrowing that a blank-page project has to do by hand.
- It is the wrong tool for incremental optimisation — use an experiment there instead.
What design thinking is
Design thinking, defined
Design thinking is a problem-solving approach that starts from a first-hand understanding of the people affected rather than from a proposed solution. It is conventionally described in five stages — empathize, define, ideate, prototype, test — and its distinguishing characteristic is that it treats problem framing as real work rather than as a preamble to building.
The method comes out of design practice and was popularised for general business use through the Stanford d.school and the design consultancy IDEO in the 2000s. Despite the name, it is not about visual design. A team can run a complete design thinking cycle and produce no interface at all — the output might be a change to a pricing unit, a support process, or the order of two steps in a workflow.
What it is really designed to prevent is a specific and expensive failure: a team that agrees quickly on a solution, builds it competently, ships it on time, and discovers that the problem it addressed was not the one users had. Every stage exists to make that failure surface earlier, when it costs a day rather than a quarter.
The forward path is the easy part. The dashed loops backwards are where the method actually earns its cost.
The five stages, and what each one produces
A useful discipline: every stage owes a concrete artefact. If a week of empathize work produced no written observations, or a define session produced no single sentence, that stage did not really happen — the team just talked.
1. Empathize — gather first-hand understanding
The goal is to see the situation as the people in it see it, which means observing rather than surveying. Watch someone attempt the task. Sit with support and listen to the same complaint arrive four different ways. Read the last thirty tickets on a topic without summarising them.
The trap is confirmation. Teams arrive with a hypothesis and run "research" that collects evidence for it — asking leading questions, discounting the participant who behaved unexpectedly. A practical guard is to write down, before starting, what observation would prove the hypothesis wrong.
Which method to use depends on the question; our user research methods guide covers how to choose. On an existing product, start with behaviour rather than conversation — analytics and session replay tell you which twenty seconds are worth asking about.
Deliverable: raw observations, quotes and recordings — not conclusions.
2. Define — turn observations into one problem statement
This is the stage that decides whether the cycle produces anything, and it is the stage teams rush hardest, because it feels like paperwork standing between them and the interesting part.
The output is one sentence naming a specific user, a specific need, and the insight that explains it. Not "users find onboarding confusing" — that is a category, not a problem. Something closer to: a first-time admin who has never used a tool like this needs to see the product working with their own data before they will invite colleagues, because inviting people to something they cannot yet evaluate feels like a risk to their credibility.
That sentence does real work. It rules out solutions (a longer welcome video does not address credibility risk), it suggests others, and it gives the test stage something to falsify. A vague definition is why so many cycles end in an ideation session where every idea seems equally plausible — with no sharp problem, there is no basis to prefer one.
Deliverable: a single problem statement the whole team can recite.
A test for a good problem statement: it should be possible to be wrong about it. If no realistic observation could contradict the sentence you wrote, you have written a description rather than a hypothesis, and the rest of the cycle will have nothing to push against.
3. Ideate — generate options before judging them
The purpose of ideation is not creativity for its own sake. It is to prevent the first plausible idea from becoming the only idea, which is the normal failure mode of a room under deadline pressure.
Two practices do most of the work. First, generate silently before discussing — spoken brainstorming converges fast on whatever the most senior person said first. Second, force variety with constraints: what would we do if we could not change the interface at all, if we had one day, if we had to remove something instead of adding it. Those constraints reliably surface options a free-form session never reaches.
End by narrowing to three genuinely different approaches rather than one favourite — three rival directions give the prototype stage something to compare. If you need to rank a longer list, a prioritization framework does that job better than a show of hands.
Deliverable: three rival approaches, described in a paragraph each.
4. Prototype — build the cheapest thing that tests the risk
A prototype is not a small version of the product. It is an artefact built to answer one question, and it should be exactly as good as that question requires and no better.
Identify the riskiest assumption in the approach, then choose the cheapest artefact that can test it. If the risk is "will anyone understand what this screen is for", a static image is enough. If it is "will people complete a five-step setup", you need something clickable. If it is "will existing users notice a change at all", the cheapest real test is often a piece of in-app guidance on the live product — a tooltip or a short product tour shown to one segment, which produces real behaviour rather than reported opinion.
Fidelity has a cost beyond build time: a polished prototype changes the feedback you get. Participants critique detail rather than concept, and teams become reluctant to discard something that looks finished. That reluctance is the real reason to keep prototypes rough.
A prototype that runs on the live product: an in-app checklist tested on one segment produces real behaviour in a day, rather than opinions about a mockup.
Deliverable: the smallest artefact that can be shown to a stranger.
5. Test — learn what is wrong, not whether people like it
Testing is another observation stage, and the goal is disconfirmation. Give a realistic task, stay quiet, and watch what actually happens. The most valuable moments are hesitations and wrong turns, not compliments.
Two rules keep tests honest. Do not demo before the attempt — explaining the design first tests your explanation rather than the design. And do not let the person who designed it moderate, because it is nearly impossible not to rescue a struggling participant. The usability testing guide covers task writing and session structure in detail.
Then read the result correctly. If participants struggled with the interface, iterate the prototype. If they understood it perfectly and still did not want it, the problem statement was wrong — go back to define. Those look similar in the room and lead to completely different next steps.
Deliverable: evidence about the problem statement, not a verdict on the design.
A worked example: an onboarding step nobody completes
Abstract descriptions of design thinking are the reason people distrust it. Here is a complete cycle on an ordinary problem, at realistic speed.
| Stage | What the team did | Time | What came out |
|---|---|---|---|
| Start | Analytics shows 58% of new accounts abandon at "invite your team", step 4 of setup | — | A located problem, not yet an understood one |
| Empathize | Watched 12 replays of accounts that stalled there; ran 5 short interviews with recent signups | 2 days | Users hovered, opened the field, typed nothing, left. Several said they would invite people "once it's set up properly" |
| Define | Wrote one statement and cut two competing ones | 2 hours | "A first-time admin will not invite colleagues before they can see the product working with their own data, because inviting people to an empty tool costs them credibility" |
| Ideate | Silent generation, then narrowed to three rival directions | 2 hours | (a) move invites after first value, (b) let admins preview what an invitee would see, (c) make the step visibly skippable |
| Prototype | Tested (c) first — cheapest and reversible. Added an explicit "skip for now" and a checklist item that returns later | 1 day | A live change shown to one segment via an in-app checklist |
| Test | Measured step completion and, more importantly, invites sent within 7 days | 1 week | Setup completion rose sharply; invites sent within a week rose too, because admins returned once they had data |
Two things in that example are worth noticing. The step that "failed" was not broken — it was correctly built and badly placed, which no amount of copy iteration on the step itself would have fixed. And the test measured the downstream outcome, invites sent, rather than the local one, step completion. Optimising the local metric alone would have made the step easier to skip without ever establishing whether anybody came back.
Sequencing note: the team started from analytics, not from a workshop. On an existing product that is almost always right — behavioural data does the narrowing for free, and it means the empathize stage begins with a specific twenty seconds to ask about rather than an open-ended conversation about the product in general.
Where design thinking genuinely falls down
The criticisms are not all bad faith, and a team that knows them gets better results than one that treats the method as universally applicable.
-
It becomes theatre
Workshops, wall-sized affinity maps, photographs of people at whiteboards — and nothing in the product changes. The tell is a cycle that ends at a readout rather than at a shipped change. Fix it by committing to the smallest testable change before the workshop starts.
-
It under-weights feasibility and economics
Empathy work surfaces what people need; it says nothing about what is technically possible or commercially sensible. Cycles run without an engineer present reliably produce desirable ideas that cannot be built at a price anyone would pay. Put engineering in the room from ideate onward.
-
It is the wrong tool for optimisation
If you know the problem and just want a better version of a known solution — button placement, form field order, a headline — an experiment answers faster and more reliably. Design thinking is for ambiguity, and running it on a well-defined problem is expensive ceremony.
-
It gets scheduled as five sequential phases
A Gantt chart with one stage per week defeats the point, because it removes the loops that make the method work. If the plan has no room to go back to define in week four, the cycle will produce whatever was decided in week two.
Design thinking, JTBD, and lean — how they fit together
These are frequently presented as competitors. They are not; they operate at different layers and combine well.
| Approach | What it is | What it is best at | Use it when |
|---|---|---|---|
| Design thinking | A process from research to tested solution | Working through an ambiguous problem | You do not yet know what the problem is |
| Jobs-to-be-done | A lens for understanding demand | Explaining why people switch and what progress they want | You need a sharper input to the define stage |
| Lean startup | A validation loop around a business idea | Testing whether a market exists at all | The risk is commercial rather than usability |
| Kano model | A classification of feature types | Separating delighters from table stakes | You are choosing between candidate solutions |
The most useful combination in practice is jobs-to-be-done feeding the define stage. A job statement is a much stronger problem frame than a feature request, because it already names the progress someone is trying to make and the circumstances they are in. Similarly, the Kano model is a good companion at the end of ideation, when you need to know whether a candidate solution would delight or merely stop annoying people. And when the prototype is ready to become a real build, the MVP, MMP and MLP distinction governs how much to ship first.
Prototype your next flow inside the real product
Kompassify lets you build product tours, tooltips and checklists on your live app without code — so a design thinking prototype can be tested on real users, on real data, in a day. Free up to 100 monthly active users, paid plans from $129/month, GDPR-compliant and EU-hosted.
Start for freeRunning a cycle that actually ships something
✓ Do this
- Start from behavioural data on an existing product
- Write one problem statement, not three
- Record in advance what would prove you wrong
- Keep an engineer in the room from ideate onward
- Prototype only the riskiest assumption
- Test the downstream outcome, not the local step
- Timebox a cycle to one or two weeks
✗ Avoid this
- Scheduling the five stages as five sequential weeks
- Defining the problem as a whole product area
- Polishing a prototype past the question it answers
- Letting the designer moderate their own test
- Demoing the design before the participant attempts it
- Using the method for a straightforward optimisation
- Ending the cycle at a readout instead of a change
Frequently asked questions
What is design thinking?
Design thinking is a problem-solving approach that starts from a deep understanding of the people affected rather than from a proposed solution. It is usually described in five stages — empathize, define, ideate, prototype and test — and its defining move is spending real effort on framing the problem before generating answers. It is not a design technique in the visual sense; it is a way of sequencing decisions so that assumptions get tested cheaply and early.
What are the 5 stages of design thinking?
Empathize: gather first-hand understanding of the people involved through research. Define: turn those observations into a single, specific problem statement. Ideate: generate a wide range of possible solutions without evaluating them yet. Prototype: build the cheapest artefact that can test the risky assumption. Test: put it in front of real users and learn what is wrong. The stages are non-linear in practice — testing regularly sends you back to redefine the problem.
Is design thinking linear?
No, and treating it as linear is the most common way teams get poor results from it. The five stages describe modes of work rather than phases on a schedule. A prototype test that confuses every participant is usually telling you the problem statement was wrong, which sends you back to define or even to empathize. Teams that run the stages once, in order, as a five-week plan tend to produce a polished answer to a question nobody checked.
What is the difference between design thinking and jobs-to-be-done?
They operate at different layers. Jobs-to-be-done is a lens for understanding demand — it explains why someone hires a product and what progress they are trying to make. Design thinking is a process for working through a problem from research to tested solution. They combine well: JTBD gives you a sharper input to the define stage, because a job statement is a far better problem frame than a list of feature requests.
What are the main criticisms of design thinking?
Three are worth taking seriously. It can become theatre — workshops, sticky notes and a photogenic process that produces no shipped change. It tends to under-serve technical and business constraints, since empathy work rarely surfaces what is feasible or economic. And it is weak at incremental optimisation, where an experiment answers the question faster than a discovery cycle. The method earns its cost on ambiguous, poorly understood problems, not on well-defined ones.
How long should a design thinking cycle take?
Shorter than most teams assume. A focused cycle on a specific problem — a failing signup step, an unused feature — can run in one to two weeks: two days of research, half a day to define, half a day to ideate, two days to prototype, two days to test. Cycles that stretch across a quarter usually indicate a problem scoped too broadly to test, which is itself a signal to narrow the definition.
Can you use design thinking on an existing product?
Yes, and it is often more productive there than on a blank page, because you already have behavioural data telling you where the problem lives. Analytics narrows the search to a specific step or feature, the empathize stage explains what is happening there, and the prototype can frequently be tested as in-app guidance on the live product rather than as a mockup — which gives you real behaviour instead of reported opinion.