What Is Design Thinking: Stages and Examples
Basics4 minInnovialabs editorial team
In short
Design thinking is a problem-solving approach that starts with understanding people, then moves through five stages: empathize, define, ideate, prototype and test. Its value is in checking assumptions with real users cheaply before building, not in workshops and sticky notes.
Design thinking in one paragraph
Design thinking is a way of solving problems by starting from the people who have them. Instead of jumping to a solution, a team first learns how users actually behave, formulates the real problem, generates several ideas, builds quick prototypes and tests them. The stages are commonly described as empathize, define, ideate, prototype and test, and they repeat in cycles rather than run once in a straight line.
The five stages
| Stage | Goal | Typical activities | Result |
|---|---|---|---|
| Empathize | Understand users and their context | Interviews, observation, support tickets, analytics | Notes, quotes, observed behaviour |
| Define | Formulate the right problem | Grouping findings, problem statement | One clear problem to solve |
| Ideate | Generate many possible solutions | Brainstorming, sketching, "how might we" questions | A shortlist of ideas |
| Prototype | Make ideas tangible cheaply | Paper sketches, clickable mockups in Figma | Something users can try |
| Test | Learn what works | Usability sessions with real users | Evidence to iterate or move forward |
A realistic example: booking at a clinic
Imagine a private clinic whose online booking form gets visits but few completed bookings. The first instinct is "redesign the form".
Empathize. The team talks to several patients and to the reception staff, and watches people try to book. They notice that many users do not know which doctor they need; they know only their symptom. Others drop off when asked to create an account.
Define. The problem is reframed from "the form is ugly" to: patients who know their symptom but not the specialist cannot choose a doctor and leave before booking. A good problem statement names the user, the need and the obstacle, without dictating the solution.
Ideate. The team turns this into the question "How might we help patients reach the right doctor without medical knowledge?" Ideas include: choosing by symptom, a short guided questionnaire, booking a general consultation first, a callback request, guest booking without registration.
Prototype. Two ideas are mocked up as clickable screens: a symptom-based picker and a guest booking flow. No code, only enough fidelity to test.
Test. A handful of people from the target audience try both prototypes with a realistic task: "Book a visit for back pain this week." The team watches where they hesitate. Perhaps the symptom picker works but its wording confuses people, and guest booking removes a major barrier. The next iteration refines both.
The final solution may look nothing like the "prettier form" the team started with — that is the point.
Common ways teams misapply it
- Workshop theatre. A day of sticky notes with no real users involved. Without research, empathize becomes guessing.
- Skipping define. Teams jump from interviews straight to ideas and solve a symptom instead of the problem.
- Falling in love with the first idea. Ideation exists to compare options; one idea is not a choice.
- Over-polished prototypes. Spending weeks on a high-fidelity mockup makes it emotionally hard to throw away and slows learning.
- Testing with colleagues. Teammates know the product too well. Test with people who match your audience.
- Treating it as linear. Tests often send you back to define or ideate. That is a success, not a failure.
- Stopping at insights. Design thinking must end in decisions and changes in the product, not just a presentation.
When it is worth using
Design thinking pays off when the problem is unclear, users' behaviour is poorly understood, or the cost of building the wrong thing is high: new products, new features, redesigns of key flows. For a small, well-understood change, a lighter process is usually enough.
A practical minimum for most teams: talk to real users, write one problem statement, sketch several options, test the cheapest prototype that answers your question.