Design thinking

In one line: design thinking is a five-mode loop — empathize, define, ideate, prototype, test — that keeps you solving the right human problem before you fall in love with a solution.

What it is

Design thinking is a way of moving from a vague human problem to something worth building, in five modes you cycle through rather than march past: empathize (learn what it's actually like to be the person with the problem), define (state the one problem worth solving), ideate (generate many possible answers), prototype (make a rough, cheap version), and test (put it in front of real people and learn).

"Mode" is the important word. These are not gates you clear once. A test that goes badly sends you back to ideate, or all the way back to empathize. You are looping until the evidence says you've got it.

Why it matters

Most bad products aren't badly built — they're confidently built for a problem nobody had. Design thinking front-loads the cheap work: talking to people and writing down what's true before you commit engineering time to a guess.

The other half is a rhythm of widening and narrowing. Each mode either diverges (you deliberately make more options — more interviews, more sketches) or converges (you cut down to one — one problem statement, one prototype to test). Mixing the two is where teams stall: you can't fairly judge ideas while you're still inventing them, and you can't invent freely while you're busy killing options. Naming which mode you're in tells everyone whether the job right now is more or fewer — and that single distinction prevents most circular meetings.

See it

How it works

Walk one fuzzy problem — "commuters miss their bus because arrival times are unreliable" — through the loop:

1. Empathize (diverge). Ride along with five commuters. Collect what they did and said, not what they'd want — observation beats opinion. Output: a page of verbatim quotes and moments.
2. Define (converge). Cluster those quotes and write one point of view in the form user + need + insight: "A commuter needs to trust the countdown, because a wrong estimate costs them more than no estimate." Output: a single statement the whole team can repeat.
3. Ideate (diverge). Sketch eight ideas in eight minutes. Quantity first; the weird ones earn their place. Output: a wall of candidates.
4. Prototype (converge). Make the two strongest cheaply — paper, a clickable mock — in an afternoon. Output: something rough but real enough to react to.
5. Test (diverge). Watch five people use it. Note where they hesitate or fail. Output: evidence that points you back to an earlier mode.

Toggle the demo's mode control to see each mode's question, activity, output, and whether it's opening up or narrowing down. The loop ends when testing stops surprising you.

Build it

The "define" mode lives or dies on one artifact: a point-of-view statement, written so a team can read and act on it. Here's an accessible template card — a real form that emits a user + need + insight sentence, with each field labelled and described.

<!-- Three inputs, one sentence. The labels and hints carry the method. -->
<form class="pov" aria-labelledby="pov-title">
  <h2 class="pov__title" id="pov-title">Point-of-view statement</h2>
 
  <label class="pov__label" for="pov-user">User</label>
  <input class="pov__input" id="pov-user" name="user"
         placeholder="a daily bus commuter" aria-describedby="pov-user-hint" />
  <p class="pov__hint" id="pov-user-hint">Who has the problem — be specific.</p>
 
  <label class="pov__label" for="pov-need">Need</label>
  <input class="pov__input" id="pov-need" name="need"
         placeholder="to trust the arrival countdown" aria-describedby="pov-need-hint" />
  <p class="pov__hint" id="pov-need-hint">A verb, not a feature.</p>
 
  <label class="pov__label" for="pov-insight">Insight (because…)</label>
  <input class="pov__input" id="pov-insight" name="insight"
         placeholder="a wrong estimate costs more than none"
         aria-describedby="pov-insight-hint" />
  <p class="pov__hint" id="pov-insight-hint">What you learned that makes the need real.</p>
</form>

.pov {
  display: grid;
  gap: 0.4rem;
  max-width: 26rem;
  padding: 1rem;
  border: 1px solid #c9ccd4;
  border-radius: 0.75rem;
}
.pov__title {
  margin: 0 0 0.5rem;
  font-size: 1rem;
}
.pov__label {
  font-weight: 600;
  font-size: 0.9rem;
}
.pov__input {
  padding: 0.5rem 0.65rem;
  border: 1px solid #c9ccd4;
  border-radius: 0.5rem;
  font: inherit;
  transition: border-color 120ms ease;
}
/* A visible focus ring tells a keyboard user which field they're filling. */
.pov__input:focus-visible {
  outline: 2px solid #5b6cff;
  outline-offset: 2px;
}
.pov__hint {
  margin: 0 0 0.5rem;
  font-size: 0.8rem;
  color: #5b606b;
}
/* Honor users who've asked the system to quiet motion. */
@media (prefers-reduced-motion: reduce) {
  .pov__input {
    transition: none;
  }
}

Make it yours

Reproduce it with an LLM

Pitfalls & accessibility

Related

Further reading

• A primary text on human-centered design, for where the empathize-first stance comes from.
• Any reputable guide to facilitating divergent and convergent workshops, to practice running each mode without mixing them.