Design Thinking Process: 5 Stages With Project Examples

What are the five stages of design thinking?

design thinking process is a key topic in modern project management and teamwork. The five stages are Empathize, Define, Ideate, Prototype and Test. Stanford’s d.school popularised the sequence, and each stage maps to an artefact a manager can review.

Prototype and Test run in tandem: you build in order to think.

Do other versions of the model exist?

Yes. Nielsen Norman Group adds a sixth phase, Implement; the UK Design Council’s Double Diamond (2004) uses four; IDEO uses three — Inspiration, Ideation, Implementation. The differences are vocabulary: every version widens understanding, narrows to a problem, widens options, then learns from something real.

Stage 1: Empathize — what does real user research look like?

Empathize means collecting evidence about what people actually do in context, including workarounds they have stopped noticing. It is a data-collection stage with a sample, a method and a record, not a mood.

Three methods earn their cost. Contextual interviews put you beside someone doing the task, so you see the second monitor and the spreadsheet they keep “just in case.” Shadowing for half a day beats five interviews about that shift. Existing evidence — support tickets, call notes, abandonment data — is free research teams ignore because it is not labelled research.

How many interviews are enough?

Enough is when new interviews stop producing new themes, usually 8 to 12 per user segment — saturation, not significance. With two segments, run 8 in each rather than 16 in one.

> Practical tip: Record verbatim quotes, not summaries. “I check the invoice twice because we got billed for a project that closed” is evidence; “user wants clearer billing” is your interpretation in a costume.

Example 1: what a two-week empathy sprint costs

A logistics team wanted to fix “scheduling friction”: 10 sessions, six with dispatchers and four with technicians.

The finding that changed the project: 7 of 10 dispatchers kept a parallel whiteboard because the software could not show two technicians on one site. The team had been scoping a calendar redesign; the real constraint was a data model that could not represent a shared assignment.

Stage 2: Define — why does the problem statement decide the project?

Define converts raw notes into one sentence specific enough to be wrong: if nobody could disagree with it, it is too vague to guide design. The format is \[specific user\] needs \[specific need\] because \[insight that is not obvious\].

• Weak: “Dispatchers need a better scheduling experience.” Nobody can disagree, so nobody learns anything.
• Strong: “A dispatcher managing 14 technicians needs to see who is already assigned to a site before confirming a job, because the current screen shows one technician per job and hides shared visits.”

Ten interviews typically produce 100–180 observations. Cluster them silently, name each cluster with a verb phrase, and rank by frequency and business cost. Write three candidate statements and pick one on evidence strength. Then convert it into a “how might we” question: “How might we show shared site assignments when a dispatcher confirms a job?” is answerable; “How might we make scheduling better?” is not.

> Common mistake: Letting Define produce a solution in disguise. “Users need a dashboard” is a feature request. A problem statement describes the difficulty, not the interface.

Stage 3: Ideate — how do you get options instead of the first idea?

Ideate is a quota exercise before it is a creativity exercise. Separate generation from judgement, set a target the group must hit, then converge on explicit criteria.

A 45-minute session that reliably produces 30+ ideas: restate the question, then eight minutes of silent writing with a target of eight ideas each. Go round-robin, one idea per person, no criticism — only building. Run a second silent burst to reach 40. Cluster without ranking, then give each person three dot votes and score the top five on impact and effort. Silent-first matters: the first speaker anchors the room, and in mixed-seniority groups that is usually the most senior person.

The trade-off: quotas generate filler. Expect 40 ideas to yield three worth prototyping. That ratio is the point — the cost of a bad idea is only the paper it is on.

Stage 4: Prototype — how cheap is cheap enough?

A prototype is cheap enough when discarding it costs nothing emotionally. Fidelity should be the lowest level that answers the current question, not the highest the team can afford.

The expensive mistake here is not building the wrong thing; it is building the right thing at the wrong fidelity, so sunk cost becomes commitment. A three-week coded prototype creates a constituency. A paper sketch does not.

> Important note: A prototype is a question, not a deliverable. If you cannot state its question in one sentence, it is not ready to build.

Stage 5: Test — how do you test without fooling yourself?

Test means putting the artefact in front of people who resemble your users, giving them a task, and recording what happens. Five participants per round is the standard qualitative sample: Jakob Nielsen’s research puts five users at roughly 85% of usability problems found, with two finding about half. For statistics, use at least 20.

Three rules keep sessions honest. Ask for behaviour, not opinion: “show me how you would confirm this job” beats “what do you think of this screen?” Do not explain, because the moment you explain you have learned that your interface needs one. Do not defend; note the objection and move on. Then separate severity from frequency, since one participant who cannot finish the core task outweighs four who find a label odd.

Example 2: the two-round test that paid for itself 27 times

A team planned 11 features for a booking flow: a paper prototype with five users, the top four fixes, then a clickable version with five more.

Three of the eleven features solved problems users did not have, and two screens could be merged. Dropping six development weeks at roughly $9,000 per week is $54,000 not spent against $2,010 of testing — about 27:1. Even at half the saving, the decision pays.

How do design thinking and project management fit together?

Design thinking decides what to build; project management delivers it. The handoff is a validated problem statement plus testable acceptance criteria, not a slide deck.

The two run in parallel more often than a clean handoff suggests: a dual track where discovery validates the next increment while delivery builds the current one. What must not blur is accountability. If the same person is measured on learning and on schedule, schedule wins and research becomes a formality. The cost performance index guide shows how to check whether money is buying the progress you planned.

How long does a cycle take and what does it cost?

A first full cycle takes 4 to 8 weeks for a product or service problem, with the workshop occupying one or two days. A two-day workshop alone is not a cycle; it is a meeting with sticky notes.

Example 3: costing a six-week cycle

Nine people at 20% allocation for six weeks is 432 hours; at $85 fully loaded that is $36,720. Add $3,100 for 12 research sessions, $1,400 of prototyping materials and $2,400 for two facilitation days, and the cycle costs $43,620. Compare that with what it replaces: preventing one quarter of misdirected build — eight developer-weeks at $9,000 — avoids $72,000. The method need not be right every time, only more often than a room of senior people guessing.

The trade-off is real. You spend about $44,000 and six weeks before production code exists. Where being wrong is cheap and speed is the advantage, that premium is a bad trade. Design thinking is insurance, and insurance only pays when the loss is large.

Why do smart teams get poor results from design thinking?

Because the method reduces bias; it does not replace expertise, and it is easy to perform without doing.

• The framing oversells it. Don Norman, who popularised the term, called design thinking “a useful myth” in 2010: useful because it made organisations take design seriously, a myth because designers hold no mystical thought process.
• Artefacts replace thinking. Natasha Jen’s 2017 critique argued that posters, journey maps and workshops often substitute for rigour. If the map is the deliverable, the map gets optimised.
• The evidence is thinner than the marketing. Jeanne Liedtka’s 2018 study of 22 organisations found prototyping alone was not enough; what correlated with innovation outcomes was generating multiple prototypes and iterating between prototyping and testing.
• Company correlations are not workshop effects. McKinsey’s 2018 study of 300 public companies found top-quartile design performers grew revenue 32 percentage points faster over five years. That measures organisation-wide capability, not one offsite.

The honest summary: design thinking reliably improves the quality of the question and lowers the cost of being wrong early. It does not guarantee a good answer, does not replace domain expertise, and does not survive an organisation that punishes being wrong in public.

Skip it when the problem is already specified, for example by a regulator; when the constraint is execution rather than direction; when a wrong answer is cheap and reversible, where an A/B test is more decisive; or when nobody has authority to act on the finding.

How do you run design thinking inside a real project?

Put discovery work on the same board as delivery work, with owners and dates, or it will be treated as optional. Three mechanics make the difference.

• One decision log. Every cycle ends with a written decision: what we learned, what we will build, what we will not build, and who agreed. Undocumented decisions get relitigated in month three.
• Evidence linked to requirements. Attach the interview or test session behind each requirement, so a scope challenge takes one click.
• A named research owner. Rotate the interviewer role, but keep one accountable person for the evidence base.

Tooling usually breaks this: research in a documents folder, requirements in a tracker, the decision in someone’s inbox. Doitify is built for the opposite arrangement — projects, tasks, checklists, owners and due dates share a workspace with project documents, meeting notes, risks and reports, so a discovery task, its evidence and the scope decision stay connected. We build Doitify, so treat that as a disclosure rather than an impartial review; for a single two-person workshop, a shared document and a whiteboard are enough.

What mistakes should you avoid?

• Recruiting users who already like you. Friendly users give polite findings. Include people who churned or complained.
• Running Empathize as a persona-writing exercise. A persona built from assumptions is fiction with a photo attached.
• Accepting a problem statement nobody could disagree with. If it cannot be wrong, it cannot guide a decision.
• Treating the workshop as the deliverable. Colleagues make poor test users, and the deliverable is a decision with evidence behind it, not a wall of sticky notes.

Conclusion

The design thinking process is five stages with one purpose: replace confident guessing with cheap evidence. Empathize to see what people actually do. Define one problem precisely enough to be wrong. Ideate past the first acceptable answer. Prototype at the lowest fidelity that answers your question. Then test with behaviour and decide.

The teams that get value are not the ones with the best workshops. They keep the evidence, write the decision down, and connect the validated problem to a delivery plan with owners and dates. Run one cycle, measure what it saved, and let that number decide whether you run a second.—

SEO (Final Output)

• SEO Title: Design Thinking Process: 5 Stages With Project Examples
• Meta Description: The five stages of design thinking explained with real costs: empathize, define, ideate, prototype, test — plus worked examples and when the method fails.
• URL Slug: design-thinking-process
• Primary Keyword: design thinking process
• Secondary Keywords: 5 stages of design thinking, design thinking examples, empathize define ideate prototype test, design thinking vs project management, double diamond, design thinking criticism
• Featured Snippet Suggestion: “The design thinking process has five stages: Empathize (research user behaviour), Define (state one specific problem), Ideate (generate many options), Prototype (build the cheapest testable artefact) and Test (observe real users). The stages are iterative, not sequential.”
• Internal Linking Suggestion: Link to /planning/cost-performance-index/ in the design-thinking-vs-project-management section, /planning/budget-vs-forecast/ where cycle cost is discussed, and /planning/design-sprint/ from the Prototype section if that page exists.
• Featured Image Suggestion: Five stage cards arranged in a loop rather than a straight line, with an arrow returning from “Test” to “Define”; muted palette with one accent colour on the loop arrow.
• Alt Text Suggestions: “Five stages of the design thinking process arranged as an iterative loop”; “Prototype fidelity table comparing build time and cost”; “Point-of-view statement formula with user, need and insight”.
• Chart Title Suggestion: “Where a six-week design thinking cycle spends its money: $43,620 total”
• Schema Suggestion: Article + FAQPage + HowTo for the five-stage sequence
• Notes for editor: Tables are native markdown and should stay as tables. The article intentionally names its critiques (Norman, Jen, Lee, MIT Technology Review) to support E-E-A-T; do not soften them out.

Admin Actions (Manual Completion)

• Create and upload the featured image; place the loop diagram directly after the five-stage table.
• Confirm the prototype-fidelity table renders on mobile, or hide the “What it can test” column below 600px.
• Add an internal link to the Doitify project-documents and meeting-notes feature page in the “How do you run design thinking inside a real project?” section.
• Optional: embed a 90-second screen recording of a paper prototype test if a branded asset exists.
• Add a downloadable one-page “Point-of-view statement” worksheet at the end of the Define section if the template library has one.

If this post on design thinking process was helpful, you might also enjoy Project Management Software for Content Teams: 2026 Guide and Best Project Management Software With Resource Management in 2026.