What is design thinking? The approach and its 5 phases

In short

Design thinking is a way of working that asks a team to get to know the person with the problem before jumping to a solution.

According to Tim Brown, IDEO’s former CEO, design thinking is a human-centered approach to innovation that draws from the designer’s toolkit. IDEO says this approach brings three things together: what people need, what is possible with technology and what a business needs to succeed.

Sarah Gibbons of the Nielsen Norman Group, by contrast, defines design thinking as an ideology supported by an accompanying process. I think this distinction matters, because memorizing phases is easy. What’s hard is anchoring the mindset in the team.

According to Gibbons, David Kelley and Tim Brown of IDEO, with Roger Martin, coined the term in the 1990s. Good designers had used a human-centered creative process long before. The term gathered methods that had matured over years into one concept and turned them into a framework for business problems.

The phases of design thinking

The most common version is the Stanford d.school’s five phases. The d.school doesn’t call them phases but “modes”, and its 2018 Design Thinking Bootleg gives method cards for each mode. The deck’s introduction also says you can start wherever you want.

1. Empathize

The d.school sees empathy as the foundation of human-centered design. The problem you’re trying to solve is rarely your own; it belongs to particular users. That’s why you observe users in their environment, talk with them and, for a while, experience what they experience.

2. Define

You turn what you gathered in the empathize phase into needs and insights, and at the end you write a problem statement you can work with. The d.school calls this sentence a Point of View (POV). It describes not a demographic but a specific user.

3. Ideate

This phase is about breadth: the d.school wants many ideas that are as varied as possible. The cards give a clear warning: don’t evaluate while generating ideas. According to the d.school, innovative concepts often come from the most outlandish ideas.

4. Prototype

A prototype gets the idea out of your head and makes it tangible. According to the d.school, it can be a wall of sticky notes, a role-playing activity or an object. In the early stages, it stays cheap and rough; for a digital product, that often means a paper screen or a clickable prototype.

5. Test

You take the prototype into the users’ environment and get feedback. The d.school’s card includes a warning: a test sometimes shows not only that the solution is wrong but that the problem was framed incorrectly. Then you rewrite your POV sentence.

A sixth phase: implement

In NN/g’s framework, there is a sixth phase: implement. Gibbons calls it the most important part and the one most often forgotten. If the idea from the workshop doesn’t make it into the product, all that’s left is a nice day.

According to NN/g, the phases are iterative and cyclical rather than strictly linear. After a prototype has been tested, teams often return to empathize and define.

Phase map: a city hall’s appointment app

Instead of explaining the five phases in the abstract, I show them with a single scenario. In a city hall’s appointment app, nobody shows up for some of the booked appointments. The team doesn’t know why.

Phase map

Phase 1 / 5

Empathize

Goal

Getting to know the person who has the problem. The d.school asks for three things in this phase: observe users in their environment, talk with them, and for a while experience what they experience.

Sample activity

The team talks in pairs with residents waiting at city hall. One person asks, the other takes notes. The question isn’t “How do you usually book an appointment?” but “Tell me about the last time you booked an appointment.” One team member also books an appointment from scratch, as if they had never seen the app.

Output

Quotes, observation notes and photos. A sample note: “My son booked the appointment. Nobody told me the time.”

Phase 2 / 5

Define

Goal

Turning the notes into needs and insights. At the end comes a sentence with a point of view the team agrees on. The d.school calls it the “Point of View” (POV).

Sample activity

The team puts the notes on the wall and groups similar ones. Then it writes this sentence: “We met an older resident who has her son book her appointments. We were surprised that the appointment details never reach her.” Then “How might we …?” questions are derived from this sentence.

Output

A POV sentence and a few “How might we …?” questions. For example: “When someone else books, how might we inform the person who will go?”

Phase 3 / 5

Ideate

Goal

Collecting many ideas that are as varied as possible. Ideas aren’t evaluated along the way. Selection happens only once the collecting is over.

Sample activity

The team writes the “How might we …?” question on the whiteboard and brainstorms for half an hour. Every idea goes on a sticky note. Ideas come up such as a “Who will attend?” field when booking, a phone call instead of a text, or booking in person at the front desk. At the end, everyone votes.

Output

A wall full of notes and two or three ideas chosen by vote.

Phase 4 / 5

Prototype

Goal

Getting the idea out of your head and making it tangible. In the early phase, the prototype is cheap and rough, so you learn fast.

Sample activity

The “Add the person who will attend” step is drawn on paper. No code is written for the reminder: the person thinks the message comes from the system, but a team member sends it by hand. The d.school calls this a Wizard of Oz prototype.

Output

Paper screens and a reminder scenario run by hand. Both are ready in an afternoon.

Phase 5 / 5

Test

Goal

Taking the prototype into the users’ real environment and getting feedback. According to the d.school, you test not only to refine your solution but to better understand the people you’re designing for.

Sample activity

At the counter, a few people are handed the paper prototype without much explanation. The team watches without stepping in, then asks “Why?”. At the end of the day, the team does an “I like, I wish, what if” round.

Output

A list of what works and what doesn’t. If needed, a rewritten POV sentence and the decision for the next round.

The scenario is made up: a city hall’s appointment app, and appointments that go unused because residents don’t show up. Press a phase, and the card below shows that phase’s goal, sample activity and output. The goals are my summary of the cards in the d.school’s Design Thinking Bootleg.

In the scenario, watch the define phase. If the team had started with “Let’s add a reminder text”, it would never have seen the resident whose appointments are booked for her. The right problem came from the empathy notes.

How to use it in a workshop

Design thinking is most visible in a workshop: people from different departments look at the same question in the same room. The cards in the d.school deck are small tools for exactly this work. These are the ones I use most.

Beginner’s mindset

The d.school advises the team to set aside what it knows and see the problem with fresh eyes. Don’t judge, question everything, be truly curious. In the city hall scenario, this means questioning the assumption “Residents already get a text.”

Empathy interview

The card’s advice is simple but often ignored. Don’t ask about “usually”; ask about a specific moment: “Tell me about the last time you …” Watch for contradictions between what the person says and what they do, and don’t be afraid of silence.

The d.school suggests interviewing in pairs: one person converses, the other captures. Talk to extreme users too, because, according to the cards, their amplified needs bring out what gets lost with average users. After the interviews, a persona helps carry the findings into the team.

“How might we …?” questions

The d.school calls these “How might we” questions. The question must be broad enough to spark ideas and narrow enough to give the team boundaries. In the deck’s example: redesigning dessert is too broad, an ice cream cone that doesn’t drip too narrow.

Brainstorming

The card recommends that the team spend 15 to 30 minutes in front of the whiteboard just generating ideas. During that time, nobody weeds out ideas. Every idea goes on its own sticky note; choosing comes later.

Testing with users

The d.school wants you not to explain the prototype but to put it in users’ hands and not correct them right away. Watch how they use it and how they misuse it. Then ask: “Show me why this would (not) work for you.”

For a more structured round, see the guide to usability testing.

After the test, I like the “I like, I wish, what if” round for the team. Everyone speaks in short points, and not every point needs an answer. The card says this tool is almost too simple to write down, but too useful not to mention.

How I structure a one-day workshop

In the morning, we read the interview notes together and, if there is one, a customer journey map. Before lunch, we write the POV sentence and the “How might we …?” questions. In the afternoon, we generate ideas and draw paper prototypes.

I give the last hour of the day to real users. If there aren’t any, the test moves to the next day, but it never gets dropped. In a workshop that ends without users, the team has only confirmed its own assumptions.

How it differs from UX design and the Double Diamond

These three terms are often confused because the names of the phases are similar. My distinction: design thinking is a mindset and a workshop practice; UX design is the work that moves a product forward over weeks and months. The Double Diamond is a model that describes this work.

I describe the product process step by step in the UX design guide. I cover the Design Council’s model separately on the Double Diamond page. The history on the Design Council’s page starts in 2003, with the search for a shared language for the design process.

Criticism

Design thinking has critics as strong as its supporters. I have read all the positions below in the source.

“A useful myth.” In his 2010 piece on Core77, Don Norman called it a myth that designers possess some mystical, creative thought process that places them above everyone else. According to him, design thinking was a public relations term for good, old-fashioned creative thinking. Still, he found the term useful: it showed that designers do more than make things look pretty.

The reply. Bill Moggridge answered Norman on Core77 the same year. For him, the design thinking label is not a myth, and the iterative structure of the process was always there. People of any background can use the process, and it is especially valuable for deciding what to do in the first place.

Norman’s turnaround. Norman partly changed his view in 2013 in “Rethinking Design Thinking”. He wrote that design thinking really is special, but added that it is not an exclusive property of designers. He put questioning assumptions at the centre.

The designer at the centre. Natasha Iskander of NYU argued in the Harvard Business Review in 2018 that design thinking is fundamentally conservative. According to her, the method preserves the status quo and privileges the designer above the people she serves.

The forgotten implementation. This isn’t criticism from outside but NN/g’s own warning. Gibbons calls the implement phase the most important and the one most often forgotten. A wall full of sticky notes doesn’t replace a single change that goes into the product.

My note

I don’t see design thinking as a method but as a habit. If the team starts talking about solutions in the first meeting, I ask: “Who did we hear that from?” If there’s no answer, we talk to a few users first.

I think Iskander’s criticism is fair. An empathy interview is no substitute for bringing users into the room where decisions are made. That’s why I invite real users to workshops when I can, or the support team that talks to them every day.

Most ideas from a workshop don’t make it into the product, and that’s normal. My yardstick: in the two weeks after the workshop, did at least one idea make it from prototype into code? If not, we didn’t run a workshop; we put on a show. I describe this handover in the design handoff guide.