Framework ⚡ Medium

Design Thinking

Five stages: empathise, define, ideate, prototype, test. Then repeat. Design Thinking is a structured problem-solving framework that forces teams to understand the people they are designing for before committing to any solution.

Discovery Product Strategy User Research Feature Scoping Workshop Facilitation Cross-Functional Alignment

01 — TL;DR

Two sentences.

Design Thinking is a structured problem-solving framework built around five stages — Empathise, Define, Ideate, Prototype, and Test — that forces teams to understand the people they are designing for before committing to any solution. It moves teams through rapid cycles of making and testing rather than debating in the abstract, with the explicit expectation that insights from testing will send you back upstream to reframe the problem.

The framework was formalised by IDEO and popularised through the d.school at Stanford in the 1990s and 2000s, drawing on decades of human-centred design practice originally developed by designers like Herbert Simon and Rolf Faste. What makes it useful for product designers specifically is the structured separation between problem space and solution space — it gives cross-functional teams a shared process language and a structural reason to go back to users before sunk cost makes pivoting painful.

02 — When to Use

Apply this when…

→ You are starting a new product or feature with no validated problem statement and too many competing hypotheses on the table

→ Your team disagrees on what the core user problem actually is, and the disagreement is stalling execution

→ A previous solution shipped but the original issue persisted — a signal the problem was wrongly defined the first time

→ You need to bring non-designers — engineers, PMs, stakeholders — into the design process with a shared vocabulary and structure

→ You are redesigning an experience with complex, multi-step user journeys where user mental models are unknown

When NOT to apply it

Skip it when you already have a clearly defined, validated problem and just need to execute — Design Thinking on a solved question produces nothing but delay. Also skip it when the timeline rules out even a single user research session (you will fake the Empathise stage), when the problem is purely technical with no meaningful user behaviour dimension, or when you are doing incremental UI polish that does not require problem redefinition.

03 — How It Works

The mechanism

Design Thinking works by deliberately separating the problem space from the solution space. Teams who skip to building tend to build the wrong thing well. The five stages function as forcing functions that prevent premature convergence — each stage is designed to surface and challenge assumptions before the next stage is entered.

Users cannot reliably self-report their own needs

Decades of human-centred design research, particularly work coming out of IDEO in the 1980s and 1990s, established that users consistently struggle to articulate what they actually need when asked directly — but their behaviour reveals it clearly. The Empathise stage is specifically designed to surface implicit needs through observation and immersion rather than surveys and feature request tickets, because what users say and what users do are routinely different things.

Problem statements constrain solution space productively

The Define stage produces a "How Might We" statement that scopes the design challenge without prescribing a solution. Without it, Ideate sessions sprawl and design files fill with features nobody asked for. A tight, user-grounded problem statement — "How might we help Airbnb hosts set competitive prices without manual research?" — generates far more actionable ideas than "improve the pricing flow," which is a solution masquerading as a problem definition.

The stages are not a waterfall

Most teams learn the stages as a linear sequence and treat completion of one as permission to move to the next. This is the most common and most expensive misapplication of the framework. Design Thinking is explicitly iterative — testing should send you back to Define or even Empathise when assumptions fail. The loop is not a bug in the process; it is the core mechanism. Teams that run it once and ship have extracted about 20% of the framework's value.

Prototype fidelity should match assumption maturity

You measure Design Thinking's effectiveness by tracking how many assumptions each prototype test invalidates before engineering time is spent. A paper prototype that kills a wrong assumption on day three is worth more than a polished high-fidelity prototype that confirms what the team already believed. If every test validates the current direction rather than challenging it, your prototypes are too refined and your test questions are not probing hard enough.

The real purpose

Design Thinking is not a creativity exercise — it is a risk-reduction process. The goal is to fail fast and cheaply before development begins. Teams that treat it as a feel-good workshop extract none of its value. Every stage should be asking: what assumption could kill this product, and what is the cheapest way to test it right now?

04 — Real Example

Airbnb's near-death pivot and the Empathise stage

In 2009, Airbnb was live and technically functional but failing to grow. The founders identified New York as their strongest market and flew out — not to run interviews or analyse data, but to spend time with hosts in person. What they found was invisible in the metrics: listing photos were dark, low-quality, and shot on phone cameras. Guests could not see what they were booking.

This is a textbook Empathise outcome. The hosts could not have reported "our photos are the blocker" because they did not know that was the problem. The founders rented a professional camera, went door to door reshooting listings, and revenue in New York doubled within a week. No survey, no analytics dashboard, and no feature request would have surfaced this finding. The problem definition changed entirely because the team went to observe rather than to ask.

Airbnb · New York · 2009

Observation surfaces what surveys cannot

Revenue 2× in one week

05 — In the Wild

Test yourself & see real examples

No examples yet — be the first.

Spotted a product team that nailed their Empathise stage — or skipped it and shipped the wrong thing? Submit what the team learned, or what they missed. Every approved example gets attributed to you.

✓ Reviewed before publishing ✓ Your name on every example you submit ✓ Violation or fix — both welcome

Seen Design Thinking violated in a real product? Help grow the evidence base.

06 — Common Mistakes

Where teams go wrong

✗ Treating Empathise as a checkbox. Teams schedule two user interviews, call it research, and move to Define. Two conversations with friendly users is not empathy — it is confirmation bias in a meeting room. You need enough observations to surface patterns that genuinely surprise you. If nothing in your research phase was unexpected, you either did not go deep enough or you only talked to people who already agreed with your hypothesis.

✗ Writing problem statements that describe solutions. "How might we build a better filter system?" is not a problem statement — it is a solution wearing a problem's clothing. A real Define-stage output describes a user, their underlying need, and the insight that makes the problem worth solving, without specifying any mechanism. Teams that skip this end up in Ideate generating variations of the same idea they had before the process started.

✗ Running the stages as a one-way waterfall. Design Thinking is non-linear by design. If your Test stage reveals that users do not understand the core value proposition, you need to go back to Define — or further. Teams that refuse to loop backwards because "we already completed that stage" are using the framework as a project plan rather than a thinking tool. The stages do not have exit doors; they have feedback arrows.

✗ Prototyping at the wrong fidelity for the question being asked. A polished, pixel-accurate prototype answers the wrong question in early rounds. It signals to users that the design is finished, suppresses honest critical feedback, and consumes the design-effort equivalent of engineering time. Early-stage prototypes should be paper sketches, whiteboard flows, or Wizard of Oz simulations. The rule: prototype fidelity should track the maturity of your understanding, not your team's Figma skills.

07 — Variations & Related Principles

Connected ideas

Design Thinking is a container framework — it does not prescribe specific tools within each stage. The principles below either operate inside it, sharpen specific stages of it, or offer an alternative structural lens for the same design challenge.

The most important pairing in this list is Design Thinking with Jobs to Be Done. JTBD sharpens the Empathise and Define stages considerably — it stops teams from accumulating observations without a theory of why users behave the way they do. Together they provide both the research discipline and the interpretive framework needed to write a problem statement worth the cost of solving.

08 — 10-Min Exercise

Run it right now

⏱ 10 minutes · Team · No prep

The Assumption Audit

Pick one feature currently in development or recently shipped.

1. As a group, spend two minutes listing every assumption the team made about the user before building it — one assumption per sticky note or line in a shared doc. Do not filter or debate yet.

2. Mark each assumption with one of three labels: Observed (we saw this in user research), Inferred (we reasoned from usage data or analytics), or Guessed (we assumed without direct evidence). In most sprints, the majority of assumptions will land in the Guessed column.

3. For the top three Guessed assumptions, write one test question each — not a survey question, but an observation prompt: something you could answer by watching a real user interact with the product for five uninterrupted minutes. If you cannot write a watchable test for it, the assumption is too vague to act on.

4. Identify which stage of Design Thinking you would need to re-enter to validate these three assumptions before the next sprint begins. This is your team's minimum viable research plan for the next two weeks.

10 minutes