Design thinking, step by step, and where it goes wrong

Design thinking is a way of solving problems that starts with the people who have them. In practice it runs in five steps: understand the people, define the problem, generate ideas, make a rough prototype, and test it with real users, looping back whenever the test teaches you something. The steps are simple; teams go wrong in predictable places, and this article shows you where and how to avoid each one.

The five-step version is the one taught by the Stanford d.school (empathise, define, ideate, prototype, test). The UK Design Council's Double Diamond, created in 2003 and shared publicly from 2004, describes the same journey in four phases: discover, define, develop, deliver. Use whichever vocabulary your organisation already knows. What matters is the order of the questions, not the names on the slides.

If you are deciding whether design thinking is the right approach at all, read design thinking vs lean vs agile vs design sprint first. For the wider map of tools, see which innovation tool should I use?.

Before you start: set up the challenge

Design thinking fails most often before step one. Settle three things before the first interview.

1. A sponsor who owns the decision. Name the person who will act on the result. If nobody can say yes to the outcome, the project produces a report.
2. A brief that names a problem area, not a solution. "Improve how new staff get through their first month" is a brief. "Build an onboarding app" is a solution in disguise and closes the project before it opens.
3. A small, mixed core team and protected time. Four to six people, including someone who delivers the service day to day. Half a day a week for six weeks beats a heroic three-day offsite that nobody follows up.

Step 1: Understand the people (empathise)

What you do. Go to the people who live with the problem. Run stakeholder interviews with eight to twelve people across the range of users, not just the friendly ones. Add contextual observation: watch the task happen where it happens.

What comes out. Notes in people's own words, photos of the real environment, and a first empathy map for each main type of user.

Where it goes wrong.

• The team interviews colleagues or managers about users instead of users themselves.
• Questions ask people to predict their future behaviour ("Would you use…?"), which they do badly.
• The research is outsourced, and the team reads a summary instead of hearing people directly. The shift in thinking happens in the room, not in the report.

Fix. Ask about the last time something happened ("Tell me about the last time you…"), and make sure every core team member attends at least two interviews. More on this in 5 research mistakes that waste your interviews.

Step 2: Define the problem

What you do. Lay out the findings and cluster them with affinity grouping. Look for tensions and surprises, not just frequent complaints. Write a point of view statement: a specific user, a need, and an insight about why it matters. Turn it into two or three how might we questions.

What comes out. One agreed problem statement and a short set of how might we questions, signed off by the sponsor.

Where it goes wrong.

• The team skips this step because "we already know the problem". They usually know the symptom.
• The statement is so broad ("How might we improve the customer experience?") that any idea fits it, or so narrow ("How might we add a chatbot?") that it smuggles in the answer.
• The sponsor isn't shown the statement, then rejects ideas later because they had a different problem in mind.

Fix. Treat sign-off on the problem statement as a gate. A full guide is in your problem statement is the whole project.

Step 3: Generate ideas (ideate)

What you do. Start silent. Use brainwriting or crazy eights so everyone produces ideas alone before the group discusses. Aim for quantity first. Then cluster, build on each other's ideas, and narrow with an impact-effort matrix or a similar tool.

What comes out. Two or three ideas worth prototyping, each linked back to the how might we question it answers.

Where it goes wrong.

• Open discussion from the first minute, so the most senior or loudest person sets the direction.
• The team falls in love with one idea and stops generating.
• Ideas are chosen by a show of hands, without asking which ones best answer the problem statement.

Fix. Separate generating from judging, in time and in rules. For the case against open brainstorming and what to use instead, see brainstorming doesn't work; here is what does.

Step 4: Prototype

What you do. Make the cheapest thing that lets a real person react to the idea. A paper prototype of a screen or form, a storyboard of a service, a mocked-up letter, a role-played counter conversation. Before building, list the riskiest assumptions with assumption mapping and make sure the prototype tests them.

What comes out. One rough prototype per idea, plus a written note of what you expect to learn from it.

Where it goes wrong.

• The prototype is too polished. People are polite to things that look finished and stop giving honest feedback, and the team becomes reluctant to throw away work that took weeks.
• The prototype tests the easy part (the look of the screen) instead of the risky part (whether anyone would bring the right documents).
• IT or a vendor is engaged to build a pilot, and the project quietly becomes an implementation.

Fix. Set a time limit of one or two days for a prototype. If it takes longer, it is too detailed.

Step 5: Test, then loop

What you do. Put the prototype in front of five or so real users. Run a moderated usability test: give them a task, watch, and keep quiet. Capture results with a feedback capture grid: what worked, what didn't, questions raised, new ideas.

What comes out. A clear decision for each idea: refine it, drop it, or take it forward to a pilot. Often you will also learn that the problem was framed slightly wrong, which sends you back to step 2.

Where it goes wrong.

• The team explains the prototype before the test, then measures how well people understood the explanation.
• Testing is treated as a final exam to pass, so negative results are explained away.
• After testing, there is no route into delivery, and the prototype sits in a drawer.

Fix. Agree in advance what result would make you drop the idea. And before you test, agree with the sponsor who will take a successful idea into delivery and with what budget line.

A worked example

Illustrative. A university library in a large city wants more students to use its research support service. Usage is low, and the head of library services assumes the problem is awareness.

Understand. The team of five interviews ten students and observes the help desk for three afternoons. Students know the service exists. What stops them is that booking requires them to describe their research topic in a form, and many feel their topic is not yet "good enough" to show a librarian.

Define. The point of view becomes: "First-year postgraduate students need a low-stakes way to ask for help early, because they feel judged when their research idea is still unclear." The how might we question: "How might we make asking for help feel normal before the topic is clear?"

Ideate. A brainwriting round produces forty ideas. The impact-effort matrix leaves three: drop-in "unclear topic" hours, a booking form with one optional field, and librarians visiting the first seminar of each programme.

Prototype. A printed sign for drop-in hours and a paper version of the shorter form, both made in a morning.

Test. Over two weeks, drop-in hours attract a steady stream of students, while the shorter form makes little difference. The team drops the form, keeps the drop-in hours for a term-long pilot, and agrees with the head of library services which staff hours will cover it.

The original assumption, that students didn't know about the service, would have produced a poster campaign. The process produced a different answer.

Do's and don'ts

Do

• Get a named sponsor and a solution-free brief before step one.
• Have the core team hear users directly.
• Get the problem statement signed off before ideation.
• Prototype in hours, not weeks.
• Plan the route into delivery before you test.

Don't

• Don't treat design thinking as a workshop. A single day can cover ideation; the full process takes weeks.
• Don't skip the define step to save time. It costs more time later.
• Don't polish prototypes or explain them before testing.
• Don't run the process to justify a decision already taken. People notice, and you lose them for the next project.
• Don't think of the steps as strictly linear. Looping back is the method working.

Questions people ask

What are the 5 stages of design thinking? In the Stanford d.school model: empathise, define, ideate, prototype and test. The Design Council's Double Diamond groups the same work into four phases: discover, define, develop and deliver.

How long does a design thinking project take? For a focused service problem, expect four to ten weeks of part-time work by a small core team. A design sprint can compress the later steps into five days, but only once the problem is reasonably well understood.

Why does design thinking fail in organisations? Usually for organisational reasons, not method ones: no sponsor who owns the outcome, a brief that already contains the solution, research skipped or outsourced, and no route from a tested prototype into delivery.

Where to go next

The method guides for each step: stakeholder interviews for step 1, point of view and how might we for step 2, brainwriting for step 3, and paper prototype for steps 4 and 5. For testing in more depth, read how to test an idea before you build it.