What Is Design Thinking?

Tim Brown, then president and CEO of IDEO, described it in Harvard Business Review in June 2008 as a method for meeting what people need with what technology allows and a business can sustain. That is one description among several. A systematic review by Micheli and co-authors (Journal of Product Innovation Management, online in August 2018) arrived at 10 attributes and 8 tools, and it describes a term with so many meanings that it risks becoming useless.

Nor is there an established inventor. Peter Rowe gave the title Design Thinking to a book on how architects and urban planners design, and MIT Press dates the hardcover to December 1986. Richard Buchanan published "Wicked Problems in Design Thinking" in the journal Design Issues in 1992. Germany's HPI traces the roots to Herbert Simon in the 1960s and credits the systematic method to David Kelley and the Stanford d.school. These are the dates of each document, and this glossary does not settle on an origin.

The misreading is to take it for a five-step recipe or a workshop with sticky notes. Its own advocates do not agree on the count:

• Tim Brown (IDEO): three spaces, which he calls inspiration, ideation and implementation. He stresses that they are spaces and not an orderly series of steps.
• Design Council: four phases in its Double Diamond, namely discover, define, develop and deliver. The page speaks of design and innovation and does not use the phrase design thinking.
• Stanford d.school: five modes, namely empathize, define, ideate, prototype and test.
• HPI d-school in Potsdam: six phases, namely understand, observe, define a point of view, find ideas, build prototypes and test them.

What they share is the route underneath: understand the people and the problem, open up many solutions and check a few with prototypes, going back when needed. Sticky notes are only a material. The d.school guide lists them as one of many possible forms of prototype.

It is not about how things look either. In the Shimano case Brown recounts, the team first set out to learn why 90% of American adults don't ride bikes, and it deliberately left the look of the bikes until later.

This order follows the five d.school modes and adds the HPI's first step. The choice is this glossary's. You repeat steps whenever a result sends you back.

First, frame the challenge. The HPI poses it as a "how might we…?" question that describes the problem and the search space from the users' point of view. A question that already holds the solution, such as "how do we improve the instructions?", ends the work before it starts.

Second, observe people and talk to them. The d.school guide asks you to see them in context, talk with them and have them show you how they do a task. Some of the strongest realizations, the guide says, come from noticing the gap between what someone says and what they do. You can organize what you see in a customer journey, with its stages before, during and after the purchase.

Third, define the problem. You move from many observations to a single statement, which the d.school calls a point of view. The guide claims that a more narrowly focused problem yields more and better ideas, though it offers no measurement. The HPI creates fictional people here to stand in for users, a device related to the buyer persona, which focuses on whoever buys.

Fourth, generate ideas. Breadth comes first and selection afterwards. Group brainstorming has a measured problem at this point. In four experiments published in 1987, Diehl and Stroebe compared real groups with the same number of people working separately, and they attributed most of the groups' productivity loss to production blocking: only one person can offer an idea at a time, and the others may forget theirs or drop it while they wait. In a further series from 1991, with 400 students, the gap did not close with longer sessions at equal person-hours. The practical consequence, which is this glossary's reading, is to write ideas down separately for a few minutes before pooling them. The HPI also combines silent individual work with teamwork. These studies measure idea output, and they say little about the success of the final product.

Fifth, build prototypes. The d.school guide wants them low-resolution, quick and cheap, and asks you to decide beforehand which variable each one tests. Brown adds that a prototype should take only as much effort as useful feedback requires. A prototype answers a question about use. An MVP goes in front of customers to measure a business assumption.

Sixth, test with users. Do it in their real context where you can, and keep asking why instead of only asking whether they like it. The guide warns that a test can reveal that the problem was framed wrongly, and then you go back to step three.

An invented example: an online furniture shop gets a shelf unit returned and its first idea is better assembly instructions. The team accompanies six customers through delivery and sees that several can't get the box up the stairs. The challenge changes: how does the shelf reach the room? Each person writes ideas alone, and one of those chosen is to split the unit into two lighter boxes. Two weighted cardboard boxes, carried home by four customers, are enough to test it. The example shows what gets checked at each step, and it does not prove the solution works.

The evidence read for this text consists of cases told by people who use or teach the method. Brown reports that Kaiser Permanente, in four hospitals, more than halved the mean interval between a nurse's arrival and first interaction with a patient after redesigning the shift change. IDEO, the firm he ran, worked on that project. Jeanne Liedtka, a professor at Darden, writes in Harvard Business Review (September and October 2018) that she studied 50 projects over seven years, and she concludes that the method counteracts biases in teams. The article presents no comparison group.

There are objections too. Natasha Iskander writes in the same journal (September 5, 2018) that the method gives designers a privileged role over the people they serve and limits those people's participation. Micheli and co-authors speak of apparent advantages and unresolved questions. The sources read contain no independent measurement of how much it improves results, so no figure appears here.

In this glossary's judgment, it fits when it is unclear what the problem is and people's behavior decides the outcome. It fits less well when the problem is already defined and the answer can be measured, for example with an A/B test.

Two nearby terms answer other questions:

• UX is the experience of the person using a product. Design thinking is a way of working, and it also applies to services and processes, such as the shift change at Kaiser.
• Usability says whether something is easy to use. A design thinking test can include that, and it also asks whether this was the right problem at all.

• Frame the challenge as a question that does not contain the solution.
• Observe people in context as well as asking them.
• Compare what they say with what they do.
• Write ideas down separately before pooling them.
• Decide which question a prototype answers before you build it.
• Bring the people affected into the decisions too.
• Go back to the problem definition when a test contradicts it.

• Calling a workshop with no user contact design thinking.
• Replacing users with colleagues from inside the company.
• Generating ideas for a problem nobody has checked.
• Following the phases in order even when a test sends you back.
• Polishing a prototype until you can't bear to drop it.
• Mistaking a prototype for a product that is ready to sell.
• Presenting one success story as proof of the method.