Skip to content

Design Thinking

Start with the people, not the solution.

What design thinking is, the models people use, and how our practice has changed now that building is cheap.

Design thinking is a way of working on problems that aren’t well defined yet. Instead of starting with a solution and defending it, you start with the people involved, question the problem as it was handed to you, explore many possible answers, make some of them real, and learn from how people respond. Then you go around again.

It works best on the problems most organizations bring to us: the new product nobody has built before, the service that has outgrown how it was designed, the idea that’s clear in someone’s head and fuzzy everywhere else.

Where it came from

The ideas go back to the 1960s, when Herbert Simon described design as a discipline of its own and Horst Rittel named “wicked problems.” IDEO turned them into a practice businesses could adopt, and Stanford’s d.school and the UK Design Council gave us the models most people use today. In digital work, the UX field (Jakob Nielsen, Jesse James Garrett) carried the same thinking into software and the web.

The three lenses

Most design thinking frameworks judge an idea against three questions:

  • Desirable. Do people actually want this? Does it meet a real need?
  • Feasible. Can it be built with the technology, time, and team available?
  • Viable. Can the organization sustain it, commercially or otherwise?

The good ideas sit where all three overlap. The method’s point is the order: start with what people need, then bring in feasibility and viability. Starting from the technology or the business model tends to produce things that work and that nobody wants.

Adapted from IDEO’s three lenses of human-centred design.

The five stages

The d.school model is the version most people know:

  1. Empathize. Learn about the people you’re designing for by observing, interviewing, and spending time where the work or the problem actually happens.
  2. Define. Turn what you learned into a clear statement of the problem worth solving. This is often not the problem you started with.
  3. Ideate. Generate many possible answers before choosing any. Quantity first, judgment second.
  4. Prototype. Make ideas tangible enough to react to.
  5. Test. Put prototypes in front of real people and watch what happens.

The numbering is misleading. These are modes, not steps. A test can reveal that the problem was defined wrong. A prototype can spark a better idea. Testing teaches you more about the people than the first round of research did. In practice the work loops back constantly, and teams that treat the stages as a checklist miss most of the value.

Based on the five modes of design thinking from the Hasso Plattner Institute of Design at Stanford (d.school).

The Double Diamond

The Design Council’s Double Diamond shows the other core habit of design thinking: alternating between opening up and narrowing down.

  • Discover (open up). Explore the problem broadly. Research, observe, question assumptions.
  • Define (narrow down). Decide which problem you’re actually solving.
  • Develop (open up). Explore many possible solutions.
  • Deliver (narrow down). Test, refine, and ship the ones that work.

The first diamond is about getting the problem right. The second is about getting the solution right. The most common failure it guards against is skipping the first diamond entirely and racing to a solution for a problem nobody examined.

The Design Council later expanded the model into its Framework for Innovation, which adds the principles around it (put people first, communicate visually, collaborate, iterate) and acknowledges that teams often loop back across the diamonds as they learn.

Adapted from the Double Diamond by the Design Council, licensed under CC BY 4.0.

Other frameworks worth knowing

There’s no single official version of design thinking. A few others come up often:

  • IDEO’s Inspiration, Ideation, Implementation. Three overlapping spaces rather than a sequence.
  • AIGA’s Head, Heart and Hand. Less a process than a description of what designers bring: strategic thinking, empathy, and craft.
  • The Design Sprint. Developed at Google Ventures, it compresses the cycle into five days, from mapping the problem on Monday to testing a prototype with users on Friday.

They share the same core: start with people, reframe the problem, diverge before you converge, make things tangible, and iterate.

Design thinking and agile

The two get confused because they share values: iteration, focus on users, collaboration, and adapting as you learn. The difference is what they’re for. Design thinking is for working out what should exist and why. Agile is for building and shipping it well. Traditionally design thinking came first and handed a direction to the build team. As we describe below, that handoff is blurring.

Jesse James Garrett’s planes of user experience are a useful way to see the split. Every digital product is built in five layers, from the most abstract to the most concrete: strategy (why it exists and who it’s for), scope (what it includes), structure (how it fits together), skeleton (how it’s laid out), and surface (what people see). People only ever touch the surface, but it’s only as good as the layers beneath it. Design thinking does its most important work at the bottom, in strategy and scope. Agile delivery has usually owned the top three. The layers still matter as much as ever. What’s changed is how quickly we can move between them.

Based on The Elements of User Experience by Jesse James Garrett.

Where we stand

We learned this discipline formally and have practised it for a long time, through dozens of workshops and a lot of work guiding organizations from a fuzzy idea to something real. It still shapes how we think. Starting with people, questioning the brief, exploring widely before committing: none of that has gone away.

What has changed is the economics underneath it.

Much of the classic design thinking process was built to manage the cost of being wrong. Paper prototypes, wireframes, long definition phases, and sprints all exist partly because building the real thing was slow and expensive, and rework was the thing you couldn’t afford. The process was designed to make sure that by the time you built something, you were fairly sure it was right.

That constraint has largely moved. With AI in the build, rework costs a fraction of what it used to. That changes the shape of the work:

  • Prototypes are real. Where we used to test a clickable mockup, we can often test working software. The first thing real users touch today is better than the minimum viable product we would have launched a few years ago, and the iteration starts from there.
  • Exploration is cheaper. The “diverge” half of the diamond used to mean sketches and sticky notes. Now it can mean several working directions side by side, so a client reacts to something built rather than something described.
  • The stages overlap. Ideate, prototype, and test happen almost together. The neat handoff from design thinking to agile delivery mostly disappears.

Some parts don’t get cheaper, and they now make up most of a project: understanding how an organization works, making sense of what we learn, and the judgment to know which direction is worth pursuing. If anything, starting in the right place matters more than ever. You can test a lot of things quickly, but testing dozens of weak ideas only finds you the best of a weak set. Understanding comes first.

We don’t claim to know what a client’s users want before we’ve done the work. What we’ve built is the method: the habits, systems, and experience to understand a business, its people, and its users quickly and deeply, and then to build our way toward the answer instead of only describing it.

So we still ask why. We also ask why our own process looks the way it does, and we change it when the reasons no longer hold.

Sources

Related

Where this fits