Problem solving Design

Design Thinking

Design thinking is empathize, define, ideate, prototype, and test, so a solution is shaped with the people who have to live with it.

The questionWho is this for, what do they actually do today, and what is the cheapest way to find out whether our idea fits?

Overlaps with human-centered design.

Process · Stanford d.school, IDEO, 1969 onward

1
Empathize Watch users where the work happens
2
Define Write the problem as a need
3
Ideate Generate many options
4
Prototype Build the cheapest version
5
Test Watch users react, then decide

Simplified view of the d.school's five modes. Teams loop back, often from test to the problem statement.

When to use it

Users will have to change how they work or live with the result, and nobody on the team has watched them do it.
The sponsor has already named the solution ("customers want an app") and you suspect the framing.
A service crosses several teams and touchpoints, and the failures sit in the handoffs, which only show up when you watch the work.
You want a cheap way to put a rough version in front of users before anyone commits build money.

When to avoid it

The problem is well defined and technical, such as sizing a warehouse or reconciling a ledger. An analytic method will get there faster.
You cannot reach real users in the time you have. What remains is workshop theater: sticky notes, personas written from the team's own assumptions, and no new information.
The decision is already made and the exercise is meant to build buy-in. Participants can tell.
The binding constraint is regulation, unit cost, or physics rather than user need. First principles is the better starting point.

Overview

Design thinking is a way of working out what to build, or what to change, by watching the people who will use it before settling on a solution. It supports one choice: whether the problem as the sponsor stated it is the one worth solving, and if so, what the cheapest credible response looks like.

The stages overlap and repeat. A failed prototype test often sends the team back to the problem statement. Versions differ in their names and number of steps, and the evidence that the approach improves outcomes comes mostly from practitioner case accounts, not controlled comparison. The usual failure is a version that keeps the vocabulary and drops the fieldwork.

What it is not

A fixed five-step sequence. The d.school calls these modes, not stages, and teams loop back. A failed test often sends you to the problem statement, not to a revised prototype.
A workshop. A half day with sticky notes produces ideas. The method depends on days or weeks of contact with the people affected.
Asking users what they want. Users are good witnesses to what they do now and poor designers of the fix. Workarounds tell you more than stated preferences.

The steps

Frame the brief and the people

Agree whose experience is being changed and write down what the sponsor already believes the answer is. You will check that belief later. Arrange access to real users now, because it is the step most likely to slip. What comes out is a named set of user groups, access to them, and a list of assumptions to test.
Watch and listen where the work happens

Spend time in the setting where people do the task. Observe, interview, and collect the artifacts they use, such as spreadsheets, sticky notes on monitors, and forms they have modified. Look for workarounds, delays at handoffs, and places where behavior contradicts what people say. What comes out is field notes with specific observations, not summaries.
Define the problem as a need

Cluster the observations and write the problem as a need of a specific person in a specific situation. Test the statement with the sponsor and with two of the users you met. Expect to write it several times. What comes out is one to three problem statements that differ from the sponsor's first framing, or confirm it with evidence.
Generate options and build rough prototypes

Produce many options, pick a few, and build the cheapest version that someone can react to. Paper, a script, a role-play, or a clickable mock is enough. The aim is a reaction, so do not polish it. What comes out is two or three prototypes aimed at the problem statement.
Test with users and decide

Put the prototype in front of the people from the second step. Watch what they do, and explain as little as you can. Then choose among changing the prototype, going back to the problem statement because the need was wrong, or stopping. What comes out is a revised prototype, a list of what failed, and a decision.

In practice

Complaints about a utility's bills kept rising after the new billing portal launched, and the sponsor wanted the portal redesigned. The team spent a week listening in on call-center calls and visiting six customers at home. Most of the calls were about one situation: customers who had moved house received a final bill and a new-account bill that overlapped, and the portal showed neither one clearly. Nobody had asked the team to look at that, because the portal was the project.

The team restated the problem as "a customer who moves needs to see what they owe, to whom, and by when." They mocked up a one-page move summary on paper. Five of the six customers understood it without help. The sixth did not trust the totals until the page showed the meter-reading date, so the next version added it. The portal redesign was put on hold, and the sponsor funded a change to the billing notice instead.

What you leave with

Field observations from real users, with dates and sources, that someone other than the team can read.
A problem statement framed as the need of a named person, agreed with the sponsor.
A tested prototype and a record of what users did with it.
A decision to build, change, or stop, tied to those observations.

Failure points

Workshop theater

A session of sticky notes replaces fieldwork. Personas are written from what the team already believes, and the output looks like insight but contains nothing the team did not bring into the room. Ask of every finding where it came from and who saw it.

Empathy without a decision

The research is rich and nobody with authority was there to see it. The findings become a deck, and the sponsor reads them as one more opinion. Get a decision maker into at least one field visit and one test session.

Ideas before the problem is defined

The room is energized by ideation, so the team skips the definition work and solves the sponsor's original framing with more creativity. The prototype is well designed for the wrong problem.

A prototype that looks finished

Polished mockups invite approval. Users are polite about work that looks complete and critical about work that looks rough. Keep early versions visibly unfinished.

Convenient users

Testing happens with colleagues, friendly customers, or whoever is easy to reach. The people who are hardest to serve, who matter most, are missing.

The failures above are usually Framing: the wrong problem was chosen before this framework was applied.

Origin

Herbert Simon, in The Sciences of the Artificial (1969), described design broadly as devising courses of action that change existing situations into preferred ones. That is the intellectual root. The practice took shape at the design firm IDEO and at Stanford's Hasso Plattner Institute of Design, the d.school, which began teaching design thinking as a general approach in the early 2000s. Tim Brown, then IDEO's chief executive, published "Design Thinking" in the Harvard Business Review in June 2008, which is where most managers first met it.

There is no single standard version. The d.school teaches five modes: empathize, define, ideate, prototype, and test. The UK Design Council's Double Diamond, which dates from 2003, uses discover, define, develop, and deliver. Neither name is a trademark. The d.school's Bootleg materials are published under a Creative Commons non-commercial, share-alike license, so check the terms before reusing its cards or worksheets.

Design Thinking

When to use it

When to avoid it

Overview

What it is not

The steps

Frame the brief and the people

Watch and listen where the work happens

Define the problem as a need

Generate options and build rough prototypes

Test with users and decide