What Is Design Thinking in UX? The Five Stages Explained

Design thinking gets mentioned constantly in UX job descriptions, bootcamp syllabi, and workshop agendas. It has become one of those phrases that sounds important but often goes unexplained. This post cuts through the noise: what design thinking actually is, where it came from, how the five stages work in practice, and - crucially - where it falls short.

What Is Design Thinking?

Design thinking is a human-centred approach to problem solving. Rather than starting with a technology or a business requirement and working outwards, you start with the people who have the problem and work inwards toward a solution.

The approach was popularised by IDEO and the Stanford d.school from the 1990s onwards, building on earlier ideas from engineering and architecture about how designers actually think when they work. The core insight is that the most durable solutions come from deeply understanding what people need - not just what they say they want - and then testing ideas cheaply before committing to them.

In a UX context, design thinking gives you a structured way to avoid building the wrong thing. It is not a rigid process. It is closer to a mindset: stay curious, challenge assumptions, involve real people early, and iterate.

If you are new to the discipline, our post on what UX design is gives useful grounding before you dig into design thinking specifically.

The Five Stages of Design Thinking

The Stanford d.school model describes five stages: Empathise, Define, Ideate, Prototype, and Test. These are often presented as a neat linear sequence. In practice they rarely are - but understanding each stage on its own terms is still the right place to start.

Empathise

Empathise is about developing a genuine understanding of the people you are designing for. This means observing behaviour, conducting interviews, and setting aside your own assumptions about what the problem is.

Practical example: A team is redesigning a GP appointment booking system. Before touching a wireframe, they spend two days at the surgery watching how patients interact with the existing system. They notice that older patients consistently ask the receptionist for help even when the online booking portal is technically available. The assumption that "people just need a cleaner interface" is already under pressure before a single sketch has been made.

Methods at this stage include contextual interviews, observation, diary studies, and empathy mapping. The goal is not data collection for its own sake - it is building a felt sense of what life looks like from your user's perspective.

Define

Define is where you synthesise what you learned during Empathise into a sharp, actionable problem statement. A good problem statement focuses on a user need, not a feature request.

A common format is the "How Might We" question: "How might we help [user] achieve [goal] in [context]?" This keeps the team focused on the person and opens space for creative solutions rather than locking you into a predetermined fix.

Practical example: From the GP booking research, the team identifies a pattern: patients over 60 are not failing to use the portal because the interface is confusing - they do not trust that their appointment has been confirmed without a human acknowledging it. The problem statement becomes: "How might we help patients feel confident their appointment is confirmed without requiring a phone call?"

That reframe changes everything. The solution is no longer about UI polish - it might be a confirmation SMS, a callback option, or a clearer success state in the portal. Define is where you earn the right to ideate.

Ideate

Ideate is structured divergent thinking. The goal is quantity and variety before quality. Teams use techniques like brainstorming, worst possible idea (which surfaces assumptions by inverting them), mind mapping, and "Crazy 8s" - sketching eight rough ideas in eight minutes.

The discipline here is separating generation from evaluation. Judging ideas too early kills the unusual ones, and the unusual ones are often where the best solutions live.

Practical example: The GP booking team runs a 90-minute ideation session. Ideas range from sensible (automated SMS confirmation) to far-fetched (a receptionist avatar that appears on screen after booking). Most ideas will not survive contact with constraints - budget, technical feasibility, NHS governance - but the breadth of the session surfaces three genuinely testable directions that would not have emerged from a standard requirements meeting.

Information architecture - how you organise and label content - is often shaped heavily during ideation. Our post on information architecture in UX design explores that in more depth.

Prototype

Prototype means making your ideas tangible as quickly and cheaply as possible. A prototype is not a finished product - it is a hypothesis made visible. The purpose is to create something you can put in front of a real person and learn from, before you have spent weeks or months building it properly.

Prototypes range from paper sketches to clickable Figma mockups to role-played service scenarios. The fidelity should match the question you are trying to answer. If you want to test navigation logic, a rough wireframe is enough. If you want to test whether a confirmation message feels reassuring, you might need something higher fidelity.

Practical example: The team creates three paper prototypes of different confirmation flows - one with a prominent green tick and a summary, one with a plain text confirmation, and one that includes a "call us to confirm" link as an opt-out. Each takes about an hour to produce. They are testing a feeling, not a finished UI.

Test

Test is where you put your prototype in front of real users and observe what happens. The goal is not to validate your design - it is to learn what is wrong with it so you can improve it.

Good testing at this stage is qualitative. You are watching for moments of hesitation, confusion, or surprise. You are asking "why did you do that?" not "did you like it?" For more structured expert-led evaluation alongside user testing, heuristic evaluation is a method worth knowing - it applies a set of established usability principles to identify problems systematically before or alongside test sessions.

Practical example: Five patients are shown the three confirmation flow prototypes. Four of them respond most positively to the version with the prominent summary and a clear "you will receive a text message" note. The opt-out phone link, which the team thought would reassure anxious users, actually makes two participants more anxious - they wonder whether the booking has worked at all. That insight changes the final design.

Design Thinking Is Non-Linear

One of the most important things to understand about design thinking is that the five stages are not a waterfall. In real projects, you move back and forth constantly.

Testing reveals something you did not understand about users? You go back to Empathise. Prototyping exposes a gap in your problem statement? You return to Define. Ideation uncovers an assumption that was never tested? You commission a few more interviews.

This iterative quality is what makes design thinking useful. It is a structure for staying honest about what you know and what you do not, rather than a checklist to tick off once and move on from.

How Design Thinking Relates to the UX Design Process

Design thinking and UX design are closely related but not the same thing.

Design thinking is a problem-solving philosophy. UX design is a professional practice with specific methods, deliverables, and craft skills - user research, information architecture, wireframing, interaction design, usability testing, accessibility.

In practice, design thinking tends to operate at the upstream end of a project: defining the problem worth solving, generating and testing early-stage ideas, and aligning stakeholders around user needs. UX design then takes those validated directions and turns them into detailed, buildable solutions.

Many UX designers work within a broader design thinking framework and use its language - particularly the five-stage model - as a shared vocabulary with product managers and developers who do not have a design background. If you are moving into UX from another field, understanding design thinking fluently is a genuine advantage in cross-functional teams.

Our beginner UX design course covers how design thinking fits into a full UX workflow, with hands-on practice across each stage.

When Design Thinking Helps - and When It Does Not

Design thinking is most valuable when the problem is genuinely ill-defined, when assumptions about users are untested, and when multiple solutions are plausible. It is particularly useful at the start of a new product, during a significant redesign, or when a product is not performing and the team does not know why.

It is less useful when the problem is already well understood and the constraint is execution rather than discovery. Running a full empathise-define-ideate cycle before fixing a broken form validation is overkill. Design thinking scales to the complexity and uncertainty of the problem.

There are also legitimate criticisms. Design thinking can be used as a theatre of participation - workshops that generate sticky notes without changing anything. It can be treated as a substitute for genuine user research rather than a frame for it. And the five-stage model, in the wrong hands, becomes exactly the rigid linear process it was designed to replace.

The answer is not to abandon design thinking but to use it honestly: stay genuinely curious, test with real people, and let what you learn change what you do.

Getting Started

If you want to practise design thinking rather than just read about it, the fastest way is to work through a structured brief with feedback. Our free UX masterclass is a good first step - it covers how design thinking maps to the practical work of UX design, and gives you a taste of how we teach at UX Academy.

If you are ready to go deeper, take a look at our UX design courses - all taught live online, with small cohorts, real briefs, and experienced instructors.