What Is Design Thinking? 5 Stages, Real Examples & Why Most Teams Get It Wrong
Vincent11 min de lecture ·

Design thinking is a human-centered, iterative design workflow for solving problems through five core stages: Empathize, Define, Ideate, Prototype, and Test. Rather than following these stages as a rigid sequence, teams use them to understand users, frame the right problem, test assumptions, and reduce uncertainty before committing to a solution.
The problem is that many teams treat design thinking as a five-step checklist. Research drags on without prototypes, workshops produce ideas without action, and AI generates concepts before the real problem is clear. The challenge is deciding what is worth exploring, testing, and building.
Virse helps teams keep research, ideas, prototypes, and AI-assisted exploration connected. With an infinite canvas, shared project context, multiple AI Agents, and long-term team memory, teams can explore faster without losing the user problem or the decisions guiding the project.

What Is Design Thinking in Simple Terms?
Design thinking means learning what people actually need before deciding what to build.
A practical design thinking process can be reduced to six actions:
- Understand people and context.
- Identify the underlying problem.
- Explore multiple possible solutions.
- Turn important assumptions into prototypes and mockups.
- Test those assumptions through real interaction.
- Revise the problem or solution based on evidence.

A Simple Design Thinking Example
Imagine a university team receives this brief:
Redesign the cafeteria app.
A solution-first team may immediately redesign menus, navigation, or ordering screens. A design-thinking team first investigates why students struggle.
Research may reveal that the real problem is not ordering food. Students cannot predict whether the cafeteria queue will fit between classes.
The challenge changes from:
How should we redesign the cafeteria app?
to:
How might we help students decide whether they have enough time to get lunch?
That reframing could produce a queue estimator, pickup system, capacity indicator, physical display, or another solution entirely.
The key lesson is simple: a stakeholder request often describes a proposed solution, not the underlying product design problem.
What Are the 5 Stages of the Design Thinking Process?
The most familiar model includes Empathize, Define, Ideate, Prototype, and Test. These are better understood as repeatable modes than as five mandatory consecutive steps.

Empathize: Understand Users Before Designing
The Empathize stage investigates what people do, what they need, where they struggle, and why.
Teams may use interviews, observation, contextual inquiry, stakeholder conversations, or behavioral evidence.
In one practitioner case reviewed for this article, the team combined immersion, observation, open-ended interviews, prioritization, and problem decomposition. The practitioner reported involving roughly 8–9 lead, mainstream, or extreme users and stakeholders in each category, eventually generating dozens of product and service ideas.
That number is not a universal research standard. The useful principle is that direct exposure to different behaviors produces stronger inputs than internal assumptions alone.

Define: Turn Research Into the Right Problem
Research produces information. Define turns that information into a problem the team can act on.
Compare:
Solution statement: We need a mobile queue-tracking feature.
Problem statement: Students need a reliable way to decide whether they have enough time to get lunch.
The first has already chosen an answer. The second keeps the solution space open.
Strong problem framing looks for repeated behaviors, unmet needs, tensions, constraints, and assumptions before features are selected.
Ideate: Explore Alternatives Before Committing
Ideation deliberately creates alternatives before the team invests heavily in one direction.
Useful techniques include How Might We questions, Crazy 8s, reversal exercises, Worst Idea, and collaborative sketching.
Cross-functional teams face a particular challenge here. Engineers naturally consider APIs, databases, architecture, cost, and implementation complexity. That expertise is essential, but applying every constraint immediately can narrow the solution space too early.
A practical principle is:
Diverge first, converge second.
Explore broadly, then bring feasibility, viability, technical constraints, and responsibility back into the decision.
Prototype: Make Assumptions Testable
A prototype is an experiment, not a miniature finished product.
It can be a paper interface, wireframe, storyboard, service simulation, physical model, or manually operated version of an automated workflow.
The right fidelity depends on the question. If you need to know whether users understand a flow, a wireframe may be enough. If you need to understand trust in a new service, simulating the service may be more useful than building the underlying technology.
The best prototype is usually the lowest-cost artifact capable of answering the current question credibly.
Test: Learn From Real Behavior
Testing replaces internal opinions with observable evidence.
Teams look for hesitation, misunderstanding, unexpected behavior, failed assumptions, and signs that the proposed solution actually helps.
A test may send the team back to Define or Empathize. That is not failure.
Testing exists to create learning, not to prove that the team was right.
Why Is Design Thinking Not a Linear 5-Step Process?
There is no single universal design thinking sequence.
Different organizations structure the same underlying learning process differently.
Framework | Structure | Main Emphasis |
IxDF / d.school model | 5 modes | Empathize, Define, Ideate, Prototype, Test |
HBS | 4 stages | Clarify, Ideate, Develop, Implement |
IDEO U framework reviewed here | 7 stages | Frame, gather, synthesize, generate, make, test, share |
How the 4-, 5-, and 7-Stage Frameworks Fit Together
Despite different terminology, the three models share a common pattern:
Understand → clarify → explore → make → test → learn → repeat
IxDF separates the core design activities into five recognizable modes. HBS compresses them into a business-oriented four-stage model. The IDEO U framework reviewed here separates framing, inspiration, synthesis, idea generation, making, testing, and communication more granularly.
For working teams, the learning loop matters more than the number of boxes.

How Much UX Research Is Enough Before Prototyping?
There is no universal number of interviews, days, or weeks that tells every team when research should stop.
A better question is:
Will another round of research teach us more than making an assumption testable?
What Long Research Cycles Can Reveal
Our review of practitioner cases surfaced projects that reportedly remained in research for 12 to more than 18 weeks without putting a prototype in front of users.
Another practitioner reported that four to six weeks of research and planning was often enough in their projects to begin wireframing.
These are case-level observations, not universal benchmarks. Different projects carry different levels of behavioral, technical, business, and regulatory uncertainty.
The more important pattern is that research loses value when teams keep producing findings but avoid testing important assumptions.

When Should a Team Start Prototyping?
A useful professional rule is:
Prototype when making the idea tangible will teach you more than another round of internal discussion.
Continue research when fundamental behavior is unclear. Start prototyping when an important assumption can be tested cheaply.
This helps teams avoid both premature design and research paralysis.
Why Do Design Thinking Workshops Fail in Real Organizations?
Design thinking workshops fail when organizations copy the visible rituals but remove the learning.
The common failure pattern is:
Workshop → ideas → presentation → no owner → no prototype → no change
What Creates Design Thinking Theater?
Our review of practitioner cases and user questions repeatedly surfaced several causes in design workflows:
- no real user evidence
- no decision owner
- no implementation path
- no prototype
- no follow-up
- workshop participation becoming the deliverable
A workshop should change what happens next. It might clarify a problem, identify assumptions, prioritize concepts, create a prototype or mockup, or establish ownership.
If nothing changes afterward, the team completed an activity, not a design process.
A Workshop Case That Reached Implementation
One professional case involved multi-stakeholder workshops held roughly once per month for four months, with approximately six months from the first workshop to release.
The work continued beyond ideation into a broader service redesign and the development of a design system and component library.
The practitioner described the resulting release as successful across U.S. and international markets, but no revenue, conversion, or retention metrics were provided.
That distinction is important for E-E-A-T: reported success should not be presented as quantified business impact without supporting data.

Does Every UX Project Need the Full Design Thinking Process?
No. Design thinking should adapt to uncertainty rather than force every project through the same sequence.
A team improving a well-understood checkout flow does not face the same uncertainty as a team creating a new service.
Protect Learning, Not Process Rituals
Instead of asking:
Did we complete every stage?
ask:
What uncertainty could create the most expensive mistake, and what is the fastest credible way to reduce it?
If strong research already exists, repeating discovery may add little value.
If the problem is clear but user behavior is uncertain, prioritize prototyping.
If users understand the concept but implementation is unrealistic, bring feasibility forward.
The purpose of design thinking is better learning and better decisions, not perfect process compliance.
How Is AI Changing Design Thinking and Prototyping?
AI is lowering the cost of generating possible solutions, but it does not remove the need for problem framing, judgment, prioritization, and testing.
AI Makes Solution Exploration Faster
Practitioner workflows reviewed for this article show AI being used to accelerate visual variation, prototype generation, moodboards, and supporting assets.
Exact productivity gains vary too much by task, tool, and workflow to treat individual numbers as universal benchmarks.
What matters strategically is the direction: creating another visual option is becoming cheaper and faster.
Faster Generation Makes Problem Framing More Valuable
When teams can create many directions quickly, production is no longer always the primary bottleneck.
The harder questions become:
- Which user problem matters?
- Which assumption should be tested first?
- Which constraints matter now?
- Which variation represents a meaningful alternative?
- What did users actually do?
- Which solution should become part of the product or design system?
Generating more variations of the wrong concept does not create more value.
For AI-assisted creative teams, design thinking increasingly becomes a way to direct experimentation intelligently.
What Are the Most Common Design Thinking Mistakes?
Across the cases and user questions reviewed for this article, four mistakes appear repeatedly.
Starting With Figma Before Understanding the Problem
Figma helps express solutions. It does not determine whether the solution addresses the right need.
Screens created too early can turn assumptions into requirements.
Making Prototypes Too Polished
More fidelity requires more investment and often creates more attachment.
Start with the lowest fidelity that can answer the question.
Treating Research Deliverables as Learning
Personas, journey maps, decks, and reports can organize evidence, but they are not outcomes by themselves.
Research should eventually change a decision, prototype, experiment, or implementation.
Testing Only to Validate an Existing Idea
A strong test must make it possible to discover that the team is wrong.
Testing for confirmation produces agreement. Testing for uncertainty produces learning.
FAQ
Is Design Thinking the Same as UX?
No. DT is a broader problem-solving approach, while UX focuses specifically on the experience people have with products, services, and systems. UX teams often use DT methods such as research, problem framing, prototyping, and testing, but UX also includes interaction design, information architecture, usability, and interface work.
How Much UX Research Is Enough Before Prototyping?
There is no universal duration. Practitioner cases in our review ranged from 12–18+ week research cycles without prototypes to experiences where four to six weeks was enough to begin wireframing. The stronger rule is to prototype when interaction can answer an important question more directly than additional discussion or research.
Does Every UX Project Need All Five DT Stages?
No. Teams can combine, repeat, shorten, or skip activities depending on existing evidence and project risk. The objective is not completing five stages; it is reducing the uncertainties that could lead to expensive mistakes.
Is DT Still Relevant With AI?
Yes, but its role is changing. AI can accelerate ideation, visual generation, asset creation, and prototyping. DT remains valuable for deciding which problems matter, which assumptions should be tested, and how evidence should influence the next design decision.
Conclusion
Design thinking is best understood as a human-centered learning system, not a five-step ritual. IxDF, HBS, and the IDEO U framework reviewed here use different structures, but they share the same underlying logic: understand people, clarify the problem, explore alternatives, make assumptions tangible, test them, and learn. Real project cases also show why flexibility matters: research can continue too long without testing, workshops can fail without ownership and implementation, and AI is making solution generation faster. The lasting value of design thinking is therefore not the framework itself, but the discipline of identifying the right problem, reducing uncertainty with evidence, and changing direction when reality contradicts the team's assumptions.
Plus d’articles du blog Virse
Flux de travail

What Is Human-Centered Design? HCD Process, Real Examples & Why Most Teams Get It Wrong
21 septembre 2026 by Vincent
Flux de travail

How to Turn a Design Into a Real Product: What to Do After the Prototype
21 septembre 2026 by Vincent
Flux de travail

What Is Industrial Design? Beyond Sketching, CAD and Pretty Renders
21 septembre 2026 by Vincent