Design thinking is a way of solving problems that starts with people instead of with solutions. Rather than jumping to “let’s build an app”, you first understand who is struggling and why, then try several ideas cheaply, and only then commit to building something. It is used by designers, but also by product managers, teachers, healthcare teams and government departments.
Here is design thinking explained in practical terms: the five commonly taught stages, the methods you can use in each, and a complete worked example. For a shorter lesson version, see the design thinking process in our UI/UX track.
Why design thinking exists
Teams often waste time building the wrong thing. Someone has an idea, everyone agrees it sounds good, and months later users ignore it. Design thinking reduces that risk with three habits:
- Start with real people. Watch and listen before you decide what the problem is.
- Explore widely before narrowing. Generate many options instead of polishing the first one.
- Learn by making. Build rough prototypes and test them early, when changes are cheap.
Design thinking explained: the five stages at a glance
The most widely taught version, popularised by the Stanford d.school, has five stages. The Nielsen Norman Group describes a similar model with six phases, adding Implement at the end. The names differ slightly, but the idea is the same.
| Stage | Key question | Typical methods | Output |
|---|---|---|---|
| 1. Empathise | Who are the users and what do they experience? | Interviews, observation, contextual enquiry, surveys | Raw notes, quotes, photos |
| 2. Define | What exactly is the problem we will solve? | Affinity mapping, personas, journey maps, problem statements | A clear problem statement |
| 3. Ideate | What are many possible ways to solve it? | Brainstorming, Crazy 8s, “How might we” questions | A shortlist of ideas |
| 4. Prototype | What is the cheapest way to make an idea testable? | Paper sketches, wireframes, clickable Figma prototypes | Testable prototypes |
| 5. Test | Does it work for real users? | Usability tests, feedback sessions | Findings and next steps |
Tip: The stages are not a straight line. Testing often sends you back to defining the problem again, and prototyping frequently sparks new ideas. Expect to loop.
Stage 1: Empathise
The goal is to understand people’s goals, context and frustrations, without judging or selling. Good methods include one-to-one interviews, watching people do the task where they normally do it, and reviewing support messages or reviews.
- Ask about past behaviour (“Tell me about the last time you…”) rather than opinions about the future (“Would you use…?”).
- Ask “why” and “can you show me?” often.
- Record exact quotes. They are more persuasive than summaries.
- Talk to a few different kinds of users, not only your friends.
Our lesson on user research basics covers interview planning in more detail.
Stage 2: Define
Now you make sense of what you found. Write each observation on a sticky note (physical or in FigJam), group similar notes together, and name each group. This is called affinity mapping. Patterns emerge: three people mentioned the same workaround, or everyone was confused at the same step.
Turn the strongest pattern into a problem statement. A simple format is:
[User] needs a way to [user need] because [insight].
A good problem statement is specific about the user, focused on a need rather than a feature, and backed by research. You may also create a persona or a journey map to keep the team aligned.
Stage 3: Ideate
Convert the problem statement into “How might we…?” questions. They are open enough to invite many answers but focused enough to be useful. Then generate ideas quickly. Quantity matters more than quality at this stage.
- Crazy 8s: fold a sheet into eight panels and sketch eight ideas in eight minutes.
- Brainstorming with rules: defer judgement, build on others’ ideas, encourage wild ideas, stay on topic.
- Dot voting: each person gets a few votes to mark the ideas worth exploring.
Stage 4: Prototype
A prototype is anything that lets users react to an idea. It can be a paper sketch, a set of wireframes or a clickable prototype in Figma. Make it just detailed enough to answer the question you have. If you want to test whether people understand a flow, grey boxes are fine. If you want to test whether a price is noticed, you need more realistic visuals.
To understand fidelity levels, read wireframe vs mockup vs prototype. For building interactive flows, see prototyping in Figma.
Stage 5: Test
Give real users realistic tasks and watch what happens. Do not explain the design first; let them try. Note where they hesitate, misclick or say “hmm”. Five participants per round usually reveal the main problems in a simple flow. Fix them, then test again.
See usability testing for scripts and tips.
A worked example: clinic appointment booking
Let’s apply the process to a realistic, local problem: a small multi-doctor clinic in Madurai wants to reduce crowding in its waiting room.
Empathise
The team interviews six patients, two receptionists and one doctor, and spends a morning observing the waiting room. They notice that patients arrive early “to be safe”, the receptionist answers many phone calls asking “how long is the wait?”, and elderly patients often come with a family member who has taken time off work.
Define
Affinity mapping shows two big themes: uncertainty about waiting time, and difficulty reaching the clinic by phone. The team writes:
Working family members who accompany elderly patients need a reliable way to know when to arrive, because the current uncertainty makes them wait for hours and lose a day’s work.
Notice that the statement does not say “build an app”. It describes a need.
Ideate
How might we tell patients when to leave home? How might we reduce calls to reception? Ideas include an SMS with the live token number, a WhatsApp message when three patients are ahead, a screen outside the clinic, a simple web page showing the current token, and staggered appointment slots. The team votes and picks two to prototype: the live token web page and a “you are next-but-three” message.
Prototype
The team creates a phone-sized prototype in Figma: one screen showing “Now serving token 14, your token is 19, estimated wait about 40 minutes”. They also mock up the message text on paper. Neither needs real code yet.
Test
Five patients and family members try the prototype. Findings: people trust the token number more than the time estimate; elderly users prefer messages over opening a link; several want the clinic’s phone number on the same screen. The team removes the time estimate from the main display, makes the message the primary channel and adds a call button. Then they test again.
The final solution is simpler and cheaper than the “full appointment app” someone suggested at the start, and it addresses the real problem. That is design thinking explained in one example: understand the people, frame the real problem, and test before you build.
Common mistakes to avoid
| Mistake | Why it hurts | Better approach |
|---|---|---|
| Skipping research | You solve the problem you imagined, not the real one | Talk to at least a handful of real users first |
| Problem statement that names a solution | It closes off better ideas | Describe the need and the insight, not the feature |
| Falling in love with the first idea | Alternatives never get explored | Generate many ideas before choosing |
| Over-polished prototypes | Users comment on colours instead of the flow | Match fidelity to the question you are testing |
| Testing with teammates | They know too much to be real users | Recruit people who match the target users |
| Treating it as a one-time workshop | Ideas never reach real users | Keep looping and carry ideas through to implementation |
How design thinking fits with Agile and Scrum
Most Indian software teams work in sprints. Design thinking does not replace that; it feeds it. A common pattern is for designers to work one or two sprints ahead: researching, prototyping and testing the next feature while developers build the current one. Small usability tests can then run inside each sprint to check details. The key is to make sure research findings actually reach the backlog, not just a slide deck.
Quick checklist for your next project
- Have I spoken to or observed real users this week?
- Can I state the problem in one sentence without naming a feature?
- Did we generate at least several different ideas before picking one?
- Is my prototype as simple as possible for the question I am testing?
- Have I tested with people who were not involved in designing it?
- Do I know what I will change based on the results?
Frequently asked questions
Is design thinking only for designers?
No. It is a general problem-solving approach. Product managers, developers, teachers, healthcare staff and public-sector teams use it too. Designers simply use it most often.
How long does a design thinking cycle take?
It depends on the problem. A small feature might go through all stages in a few days, while a new service might take several weeks. The important part is keeping each loop short enough to learn quickly.
What is the difference between design thinking and UX design?
Design thinking is a broad problem-solving mindset and process. UX design is a profession that uses that process, along with specific skills such as information architecture, interaction design and usability testing, to design digital products.
Do I need special tools for design thinking?
No. Paper, sticky notes and a whiteboard are enough. Digital tools such as FigJam for affinity mapping and Figma for prototypes are helpful for remote teams.
