Design Thinking & Process
Design thinking is a process for problems you don't understand well enough to solve yet. Its defining move is delay: it refuses to let a team commit to a solution until the problem has been restated in the user's terms, not the org's. Everything else about it — the five stages, the workshops, the sticky notes — is scaffolding around that one discipline.
This page maps the stages, what each one is supposed to produce, where teams reliably get stuck, and when a lighter method beats running the whole framework.
The five stages, and what each one owes you
Each stage has an output. If a stage ends without its output, it didn't happen.
- Empathize — learn what people actually do, not what they say they do or what the roadmap assumes. Output: observations, in their language.
- Define — compress those observations into one problem statement. Output: a single sentence a stranger could act on.
- Ideate — generate options without judging them yet. Output: more candidate directions than you're comfortable with.
- Prototype — build the cheapest artifact that someone can react to. Output: something testable, not something finished.
- Test — put it in front of real people and watch. Output: evidence that sends you back to an earlier stage.
The loop matters more than the sequence. Testing that never sends anyone back to define is testing performed for the record.
Where teams actually get stuck
Three failure modes account for most of it.
Skipping empathize because "we know our users." Sometimes true, usually true about the users you already have and false about the ones you're losing. The research methods map covers what to run when the assumption is worth checking.
Defining the problem as a solution. "Users need a dashboard" is a solution wearing a problem's clothes. "Users can't tell whether their last upload succeeded" is a problem, and a dashboard is one of several answers to it.
Prototyping past the point of cheapness. A prototype's whole job is to be discarded. Once it costs enough that discarding it hurts, it stopped being a prototype and started being a commitment.
The tools that carry the stages
The stages are abstract; the artifacts are what teams actually hand each other.
- An empathy map organizes raw observations into what people say, think, do, and feel — the standard output of an empathize round.
- A user persona compresses a segment into something a team can argue with, once the research exists to support one.
- A journey map puts the whole flow on one page and makes the gaps between steps visible.
Each of these is a deliverable in its own right, and worth understanding as such — the UX deliverables hub covers what each artifact is for and how to tell a useful one from decoration.
When to skip it
Design thinking is expensive in calendar time and it earns that cost only against genuine ambiguity. Skip it when:
- The problem is already stated in one sentence and everyone agrees on it.
- The constraint is execution — a defect, a performance problem, a broken step.
- You have live traffic and an unexplained drop-off, where an expert review or a targeted usability test gets you a verdict faster than a full divergent round.
For a product that's live and leaking, a UX audit scores what you already have and tells you what to fix first. That's a different question from the one design thinking answers, and usually the more urgent one.
A checklist before you run the process
- Can anyone state the problem in one sentence without naming a solution?
- Do you have observations from outside the team, gathered recently?
- Is there a cheaper method that answers the same question?
- Is the prototype cheap enough that you'd genuinely throw it away?
- Does the test have a result that would send you backward, and would you go?
If the last two are no, you're running a rehearsal rather than a process. For the full walkthrough, start with the complete guide to design thinking; for the beginner's framing of where it sits in UX, see the beginner's guide to UX.
See how we turn a vague problem into a prioritized verdict →
Frequently asked questions
What is design thinking?
Design thinking is a problem-solving process that starts by understanding people rather than by generating solutions. It runs in five stages — empathize, define, ideate, prototype, test — and its defining move is refusing to commit to a solution until the problem has been stated in the user's terms.
What are the five stages of design thinking?
Empathize (learn what people actually do and need), define (state the problem as one sentence), ideate (generate options without judging them), prototype (build the cheapest thing that can be reacted to), and test (put it in front of real people). The stages are a loop, not a queue — testing usually sends you back to define.
Is design thinking still relevant?
The process is, though the branding has aged. Teams that run it as a five-day workshop and then never revisit it get little. Teams that use it as a discipline for staying in the problem before committing to a solution get most of the value, and can skip the sticky notes entirely.
What's the difference between design thinking and the design process?
Design thinking is one named framework for approaching ill-defined problems. A design process is whatever sequence your team actually uses to ship. Most working processes borrow the empathize and test stages and compress the middle three, which is a reasonable adaptation rather than a failure to follow the method.
When should you not use design thinking?
Skip it when the problem is already well defined and the constraint is execution, not understanding. A known accessibility defect, a slow page, or a broken checkout step needs a fix and a test, not a divergent ideation round. Design thinking earns its cost when nobody can yet state the problem in one sentence.
1 article
Explore the map
Related interfaces