Design Thinking is a process for solving problems that starts from the people a solution is for rather than from the solution. The five-stage version taught at Stanford's d.school runs empathize, define, ideate, prototype, test. It is a sequence of activities rather than an analytical framework: it produces no score and no verdict, and what it gives you is a well-framed problem and candidate solutions worth testing.
When the problem is genuinely unclear and the cost of building the wrong thing is high. It is strongest at the front of a project, before anyone has committed to a solution, and weakest as a way to improve something already shipped and measured.
What Design Thinking is
Design Thinking is a process, and that distinction is worth making before anything else. Most of the entries in this collection are frameworks: analytical lenses that take inputs and return a verdict, a score or a range. Design Thinking returns none of those. It is a sequence of activities you run, and what it produces is a well-framed problem and some candidate solutions worth testing.
It starts from the people a solution is for rather than from the solution. It was formalised at the Hasso-Plattner Institute of Design at Stanford, universally called the d.school, and popularised through the design consultancy IDEO from the 1990s onward.
The version most people mean is the five-stage teaching model: empathize, define, ideate, prototype, test. Its distinguishing move is to delay committing to a solution until the problem has been stated in the user’s own terms, which sounds obvious and is almost never what happens in practice.
Because it is a process rather than a framework, judging it is different too. A framework is right or wrong about a market. A process is either run properly or performed, and the performed version is common enough to be the main thing this page warns about.
The stages are explicitly iterative, not sequential. They are drawn in a row because a row fits on a slide, and that diagram is responsible for most of the misuse.
- Five stages, not a pipeline The diagram lies
Empathize, define, ideate, prototype, test. Teams move backwards as often as forwards, and that is the process working.
- The problem statement is the hinge And it must contain no solution
One sentence in the user's terms. If it names your product, every later stage confirms a decision you already made.
- Generating and judging are separate acts Ideation fails otherwise
Evaluating each idea as it appears stops generation after four options and selects the safest one.
- Cheap prototypes get honest reactions Polish buys politeness
Something that looks finished gets compliments. Something provisional gets used.
Why it matters
The default way a product gets built is that somebody has an idea, the team builds it, and the market is consulted at the end. Design Thinking is a structured argument for consulting the market first, and for spending real time on the problem statement before anyone opens an editor.
The cost of not doing it is not usually a bad product. It is a competent product aimed at a problem nobody had, which is much harder to detect because everything about the execution looks fine.
This is the failure that survives a retrospective. The code was clean, the launch went out on time, the design review passed, everyone did their job. The thing works and nobody wants it, and there is no line in the post-mortem template for that.
The five stages
- Empathize
Observe and interview before you have a solution in mind. What people do, not what they say they do.
Produces: Raw observations and quotes
Trap: Shortening it because you already know the answer
- Define
Synthesize into one sentence: [user] needs [need] because [insight].
Produces: A point-of-view statement
Trap: Writing a requirement with your product inside it
- Ideate
Generate many options before judging any.
Produces: A wide set of candidates
Trap: Evaluating each idea as it appears
- Prototype
Build the cheapest thing someone can react to.
Produces: Something testable this week
Trap: Too much fidelity, so feedback turns polite
- Test
Watch real people use it. Resist explaining.
Produces: Observed hesitations and failures
Trap: Defending the design instead of watching
When to run it
- Nobody on the team can state the problem in the user's own words.
- You are at the start of something and the cost of building the wrong thing is high.
- Your team keeps generating the same three solutions and cannot get past them.
- The product does what was asked and people are not using it.
- You are entering a domain where your intuition is untested.
- You could find out by asking ten people this week. Use The Mom Test →
- You have a hypothesis and need evidence for it. Use Lean Startup validation →
- You need to sequence work already agreed to be in scope. Use ICE scoring →
- The question is what to charge. Use Van Westendorp →
Design Thinking in practice: the GE Adventure Series
The most quoted empathy case in the discipline, and it is quoted because the machine was already excellent.
GE Healthcare, the Adventure Series MRI · 2007 onwards
An award-winning machine that terrified its users, fixed without changing the machine.
Doug Dietz had led the design of a new GE MRI scanner and was watching it in use at a hospital when he saw a child crying in the corridor, too frightened to go in. He learned that a large share of paediatric patients had to be sedated to complete a scan, which requires an anaesthetist and turns a diagnostic appointment into a medical event.
He had, by every engineering measure, built an excellent scanner. The failure was not in the machine. It was in the ninety seconds before the machine, which nobody had designed at all.
The response was decoration and a script: the room and scanner painted as a pirate ship or a jungle, with the technician telling the child a story in which holding still is part of the adventure. The hardware was untouched.
- Reported fall in paediatric sedation rate
- large, exact figure varies by source
- Change to the scanner itself
- none
What it shows: Empathy work does not mean being nice about users. It means going to where the product is used, because the failure was invisible from anywhere else. Note that the sedation figures quoted for this case differ between retellings, which is itself a lesson about case studies.
Design Thinking vs the alternatives
What problem are we actually solving, and for whom?
Gives you: A point-of-view statement and candidate solutions
Does this hypothesis survive contact with a real customer?
Gives you: Validated learning. Falsifies what design thinking generates
What progress is the buyer hiring something to make?
Gives you: A job statement. Sharper than a point of view, narrower in scope
How does the team build in increments?
Gives you: Shipping cadence, and no opinion at all about what to build
When it won’t help you
- It is frequently run as a workshop instead of as research
A day of sticky notes with no new information in the room produces a well-facilitated version of what the team already believed. The format is easy to perform; the research is not.
Instead: Judge the empathize stage on whether anybody learned something that surprised them. If nothing surprised anyone, it did not happen.
- The case studies are retrospective
The famous examples are reconstructed after they worked, which makes the process look far more deterministic than it is and hides every team that ran it faithfully and shipped nothing.
Instead: Treat it as a way to reduce the chance of building the wrong thing, not as a method that produces winners.
- It is weak once you have a product and data
The value is in reducing uncertainty. Where uncertainty is low and you can measure, an experiment answers the question faster and more cheaply than a discovery cycle.
Instead: Switch to build-measure-learn once you have users to measure.
- It says nothing about whether the problem is worth money
A genuinely painful, well-framed, correctly-stated problem can belong to people with no budget, or be worth less to solve than it costs to solve.
Instead: Size and price it separately. A good point of view is not a business case.
Further reading
- Tim Brown, Change by Design (2009). The IDEO account.
- The Stanford d.school’s Bootcamp Bootleg, a free short guide to running the five stages.
- The Mom Test. How to run the empathize stage without leading the witness.
- Jobs to be Done. A sharper instrument for the same underlying question.
- Lean Startup validation. What to do with the options design thinking generates.
- Empathy Maps. The standard tool for synthesising the empathize stage.
How to apply Design Thinking
- 1
Empathize: observe before you ask, and ask before you propose
Interviews, and where possible direct observation of the work as it happens. The goal is what people do rather than what they say they do, and the gap between the two is where the useful findings are. This stage produces raw material, not conclusions.
- 2
Define: write a point of view in the user's terms
Synthesize the research into one sentence: [specific user] needs [need] because [surprising insight]. It must contain no solution. If the statement names your product or your technology, the research has been skipped and you have written a requirement.
- 3
Ideate: separate generating from judging
Produce many options before evaluating any. The mechanism matters: in a normal meeting each idea is assessed as it appears, which stops generation after about four ideas and guarantees the safest one wins. Time-box generation, defer criticism, and aim for volume.
- 4
Prototype: build the cheapest thing that can be reacted to
Paper, clickable mock, a script, a role-play. The prototype exists to provoke a reaction, so fidelity should be the minimum that makes a reaction possible. High-fidelity prototypes get polite feedback because they look finished.
- 5
Test: watch people use it and resist explaining
Put the prototype in front of real users and observe. The instinct to explain how it works is the instinct to defend, and every explanation destroys the data you came for. Note where they hesitate rather than what they say afterwards.
- 6
Go backwards
The stages are not a pipeline. Testing routinely sends you back to Define because the problem statement was wrong, which is a success rather than a failure. A team that only ever moves forwards is running a waterfall with new vocabulary.
Common mistakes
- **Treating the five stages as a sequence.** The model is drawn as a line because lines are easy to print. Testing sending you back to Define is the process working, not a setback.
- **Writing a point of view that contains the solution.** If the Define statement names your product, category or technology, everything downstream will confirm a decision you had already made.
- **Ideating in a normal meeting.** Judging each idea as it appears stops generation after a handful of options and reliably selects the safest one. Generation and evaluation have to be separated in time.
- **Prototyping at too high a fidelity.** Something that looks finished gets polite feedback. Something that looks provisional gets honest reactions, which is the entire point of the stage.
- **Explaining the prototype during testing.** Every explanation replaces the data you came for with a defence of a decision you already made.
- **Running it on a problem you already understand.** The process is expensive and its value is in reducing uncertainty. Where the answer is knowable by asking, it is a slow way to find out.
How ShipFit operationalizes this
ShipFit compresses the empathize and define work into Stage 2 (Who Pays?) and Stage 3 (What Hurts?), producing a buyer profile and a scored problem list from market research rather than from a workshop. The resulting problem statement is what Stage 4 (How to Win?) generates solution approaches against, so the ideation is constrained by a defined problem rather than starting from a blank page.
ShipFit runs 55 frameworks across 9 decision stages
Design Thinking is one tool in a bigger toolkit. The full library covers market sizing, buyer discovery, MVP scoping, pricing, and launch.
The Mom Test
Q3Rob Fitzpatrick
Validation question methodology, real interviews, not theater
Jobs-to-be-Done
Q2-Q4Clayton Christensen
Functional, social, and emotional jobs your product fulfills
7 Powers
Q4Hamilton Helmer
Strategic moats: Scale, Network, Counter-positioning, Switching, Brand, Cornered Resource, Process
Van Westendorp PSM
Q6Feature-weighted price sensitivity analysis without guessing
Blue Ocean Strategy
Q4Kim & Mauborgne
ERRC framework: Eliminate, Reduce, Raise, Create
Fake Door Testing
Q7Pre-build behavioral validation with landing pages and apology modals
+ 49 more: TAM/SAM/SOM Analysis, Porter's Five Forces, Market Timing Analysis, Unit Economics (LTV/CAC)...
Frequently asked questions
What are the five stages of design thinking?
Is design thinking linear?
What is a point of view statement?
What are the criticisms of design thinking?
Is design thinking a framework or a process?
How is design thinking different from lean startup?
Keep exploring
The 9-step playbook from market verdict to ship-ready spec.
Adele Revella's Five Rings of Buying Insight, the questions that produce each one, and why a persona built without buyer interviews informs no decision.
Rahul Vohra's method for measuring product-market fit and improving it: the 40% benchmark, the survey mechanics that make it comparable, and the roadmap it produces.
Most product launches fail not because the product was bad, but because the launch was a list of channels nobody mapped to a buyer. Here is the template that fixes that.
Default-prompted AI is a slop machine: agreeable, plausible-sounding, useless for validating an idea. Here's how to use AI for the parts where it actually adds signal, and where to keep it out of the way.
Gross burn lies. Net burn tells you the truth.
Two to four weeks of focused work for a single idea. Stage 1 (market verdict) takes a day. Stages 2-3 (buyer + pain) take a week of interviews. Stage 4 (positioning) takes two days. Stage 5 (V1 scope) takes a day. Stages 6-7 (pricing + behavioral evidence) take 1-2 weeks because you need 20+ buyers and a Fake Door Test running. ShipFit compresses the decision time to 30-60 minutes; the gating work is the human conversations between stages.
Startup validation for first-time founders who don't know what they don't know. ShipFit forces 9 decisions and names the mistakes you can't see. Start free.
AI cofounder tools are great conversation partners for the earliest 'what is this?' phase. ShipFit is the forcing function for when you're tired of talking and need to decide. Different jobs, not direct rivals.
Ready to make your next product a success?
9 decisions between your idea and a product worth building.