Every team that has sat through a design thinking workshop knows the five words on the wall: empathize, define, ideate, prototype, test. Fewer teams know what actually breaks at each of those five steps once a real budget, a real deadline, and a real client are involved. The phases themselves are simple. The constraints that show up inside each one are where most projects actually stall.
The five phases of design thinking, developed and popularized by Stanford’s d.school, form an ordered sequence in which each step feeds the next: understanding a user’s real problem, framing it precisely, generating options, building something tangible, and exposing that thing to feedback. The order matters here in a way it does not for looser creative processes, because skipping a phase (jumping from a vague hunch straight to a finished prototype, for instance) tends to produce confident, expensive answers to the wrong question.
1. Empathize: the phase most teams rush
Empathize means gathering direct evidence of how the actual user experiences a problem, through interviews, observation, or immersion, before assuming what they need. The real constraint here is rarely a lack of research methods. It is time: stakeholders want to see concepts, and research can feel like stalling. Teams that skip this phase tend to design confidently for a user who exists mostly in their own assumptions.
2. Define: turning research into one sharp question
Define means synthesizing everything gathered during empathy work into a single, specific problem statement that the rest of the team can rally around. The constraint at this stage is usually political rather than technical: different stakeholders walk away from the same research with different priorities, and someone has to choose which problem gets solved first. A definition broad enough to please everyone is usually too vague to design against.
3. Ideate: generating options without editing too early
Ideate means generating as many possible solutions as reasonably possible before judging any of them. The constraint that trips teams up here is seniority: a senior voice in the room proposes an idea early, and the group unconsciously stops generating alternatives and starts refining that one option instead. Structured techniques, silent brainstorming, “worst possible idea” exercises, round-robin sketching, exist specifically to counter that dynamic.
4. Prototype: making an idea cheap enough to be wrong
Prototype means building the fastest, cheapest tangible version of an idea that can still answer a specific question. The real constraint is fidelity: a prototype that is too polished takes too long to build and invites feedback on finish rather than substance, while a prototype that is too rough fails to communicate the idea at all. Choosing the right fidelity for the question being asked is its own skill, one we cover in detail in our walkthrough of how rapid prototyping actually works.
5. Test: the phase that sends you backward
Test means putting the prototype in front of real users and observing what breaks, confuses, or delights them. The constraint most teams underestimate is ego: test results often contradict a direction the team has already grown attached to, and the honest response is to go back to an earlier phase, sometimes all the way back to define, rather than defend the prototype. Design thinking is drawn as a straight line on a slide but behaves more like a loop in practice.
| Phase | Main output | Real-world constraint |
|---|---|---|
| Empathize | User research notes | Pressure to skip straight to solutions |
| Define | One problem statement | Competing stakeholder priorities |
| Ideate | A wide option pool | Anchoring on the first idea proposed |
| Prototype | A testable model | Choosing the wrong fidelity level |
| Test | Validated or rejected direction | Attachment to the existing prototype |
Why the order is non-negotiable, even when it feels slow
Teams under deadline pressure often ask whether a phase can simply be skipped this once. In our experience, the phases that get cut are almost always empathize and test, the two that involve real users rather than internal work, precisely because they are the two a team cannot fully control the outcome of. Cutting them does not remove the risk they were meant to catch. It just delays that risk until after launch, when it is far more expensive to fix.
Frequently asked questions
- Do the five phases always happen in order? No. The d.school itself describes the process as iterative rather than strictly linear: teams often loop back to an earlier phase once testing reveals a flawed assumption.
- How long should each phase take? There is no fixed duration. A sprint-style project might compress all five phases into a single week, while a complex product might spend months in empathize alone. The constraint is the question being answered, not a template.
- Can one person run all five phases alone? It is possible on a small project, but the ideate phase in particular benefits from more than one perspective in the room, since a single mind tends to anchor on its own first idea faster than a group does.
If the five phases sound abstract until applied to a specific decision, that is expected. The precise definition of design thinking and the underlying principles that make the method work both fill in the gaps a phase-by-phase breakdown cannot cover on its own.