Design  ·  Innovation

Design
Thinking
Fundamentals

How to solve complex problems by starting with people: the five stages from deep empathy to tested prototypes, and why the process matters more than the output.

Design Thinking Innovation User Research Problem Solving
6 min read

Most problems are solved backwards. Someone identifies a symptom, jumps to a solution, and spends months building it, only to discover it doesn't address what the user actually needed. Design Thinking exists as a corrective to this impulse: a structured approach to problem-solving that starts with a deep understanding of people before any solution is proposed.

Originally developed at Stanford's d.school and popularised by IDEO, Design Thinking has spread well beyond design studios into product teams, management consulting, healthcare, education, and public policy. The reason is simple: it produces better solutions to complex, human problems than approaches that skip the human part.

Foundation

A human-centred approach to complex problems

Design Thinking is a problem-solving methodology that prioritises understanding the people who experience a problem before attempting to solve it. It is human-centred (solutions are designed for real people in real contexts), collaborative (diverse perspectives are used intentionally), and experimental (ideas are tested quickly with real users, not debated in meeting rooms).

Solution-first thinking
Identify a problem → assume you know the cause → design a solution → build → release → discover users don't want it.
Design Thinking
Observe users → understand their reality → define the real problem → explore many solutions → prototype → test → refine.

The critical shift is sequencing. Design Thinking delays solution generation until the problem is deeply understood, because the most elegant solution to the wrong problem is still the wrong solution.

The Process

The five stages of Design Thinking

Design Thinking is typically taught as five stages. These are not strictly sequential; real practice involves constant iteration, moving back and forth as new information emerges. But they provide a clear map of the process.

01
Empathise
Understand the people you're designing for: their behaviour, motivations, and emotions in context. Interviews, observation, shadowing, and immersion. You can't empathise from a desk.
02
Define
Synthesise your empathy research into a clear, human-centred problem statement. What is the real problem? For whom? In what context? A well-defined problem is already halfway solved.
03
Ideate
Generate a wide range of possible solutions without judgement. Quantity over quality. The goal is to explore the full solution space before narrowing: diverge first, converge later.
04
Prototype
Build quick, cheap representations of your best ideas: paper mockups, wireframes, role-play scenarios. Prototypes are hypotheses made tangible, not finished products.
05
Test
Put prototypes in front of real users and observe. You're not presenting. You're learning. What works? What confuses? What did you get wrong? Test results feed back into any earlier stage.
The process is iterative: Test results routinely send the team back to Define or Empathise
Stage 1

Empathise: seeing the world through someone else's eyes

Empathy in Design Thinking isn't sympathy. It's a rigorous effort to understand how someone else experiences their world. It requires setting aside your own assumptions and genuinely entering the user's context. Three methods drive most empathy work.

Observation
Watch people doing the actual thing in their actual context, not in a lab, not described from memory. People are unreliable narrators of their own behaviour. What they do and what they say they do are often different. Observation catches the gap.
Interviews
Conversations focused on stories and experiences, not opinions about hypothetical solutions. "Tell me about the last time you tried to do X" reveals far more than "would you use a product that did Y?" Silence is a valid interview technique. Let people fill it.
Immersion
Where possible, experience the problem yourself. Use the product, go through the process, feel the friction. Short of becoming the user, immersion is the most direct path to genuine understanding, not research slides about the user.
The empathy phase is chronically under-invested. Teams rush through it because they already have a solution in mind. The result is solutions built on assumptions rather than understanding, which is where most innovation failures originate.
Stage 2

Define: the problem statement as a design brief

The Define stage transforms empathy research into a clear, actionable problem statement. This is harder than it sounds: raw research is messy, and finding the real problem beneath the stated one requires synthesis and judgment.

The most common format is the "How Might We" (HMW) question, a frame that's specific enough to give direction, open enough to allow creative solutions:

Too vague
"How might we improve the healthcare experience?" Could generate a million ideas in a million directions. No focus, no constraint, no traction.
Well-framed
"How might we help elderly patients in rural areas remember and correctly take daily medication without relying on family support?" Specific user, specific context, specific problem.

A good problem statement keeps the team anchored throughout ideation and prototyping. When a proposed solution doesn't address it, you have a principled reason to redirect, not just an opinion.

Stage 3

Ideate: quantity first, quality later

Ideation is the divergent phase: the goal is to generate as many possible solutions as possible before evaluating any of them. The common mistake is to evaluate ideas as they emerge, which kills creative risk-taking before it starts.

Two principles govern good ideation sessions:

Defer judgment
No idea is too wild. No "yes, but." Build on each other's ideas with "yes, and." The ridiculous idea often contains the seed of the breakthrough idea.
Go for volume
Aim for 50 ideas, not 5. The best idea is rarely the first one. Quantity creates the raw material from which quality solutions are selected.

After generating ideas, the team converges: dot voting, impact/effort matrices, and explicit criteria aligned with the problem statement are used to select which ideas are worth prototyping. Two or three ideas typically move forward.

Stages 4 & 5

Prototype and test: make it real, learn fast

Prototyping is the act of making an idea tangible enough to test. The key principle: build to think, not to present. A prototype is a learning tool, not a deliverable. The cheaper and faster it is to build, the more failures you can afford, and failures in prototyping are wins, because they're cheap.

Paper prototypes
Sketched on paper, assembled with scissors and tape. Can be built in 30 minutes. Effective for testing flows, layouts, and concepts before any digital tool is opened. The roughness actually helps. Users give more honest feedback when a prototype doesn't look finished.
Wireframes & mockups
Low-fidelity digital screens (Figma, Balsamiq, or even PowerPoint). Show layout and interaction without visual polish. Good for testing navigation, content hierarchy, and interaction patterns with stakeholders or users.
Role-play & simulation
For service design or process improvements, simulate the experience physically. Two people play customer and service agent. Other team members observe. Powerful for identifying friction that no screen can capture.

Testing is observation, not validation. You're not presenting your idea hoping for approval. You're watching what users do with it and asking neutral questions. "What were you expecting to happen?" and "What would you do next?" reveal more than "Did you like it?"

Context

Design Thinking, Agile, and Lean: how they fit together

These three methodologies are often mentioned in the same breath and sometimes confused. They're complementary, not competing:

Design Thinking
Answers: are we solving the right problem? Used upstream, in discovery, research, and ideation phases. Its outputs (problem statements, prototypes, user insights) feed into Agile or Lean execution. Time horizon: days to weeks of exploratory work.
Agile / Scrum
Answers: are we building it right, iteratively? Used in execution, once there's sufficient clarity on what to build. Sprints, ceremonies, and artifacts organise the work of a cross-functional team delivering working software in short cycles.
Lean Startup
Answers: is our business model assumption valid? Used at the business level, testing the viability of a whole product or business concept through the Build-Measure-Learn loop. Works at a higher level of abstraction than Agile.

In practice, strong product teams use all three: Design Thinking to discover and define, Agile to build and iterate, and Lean thinking to test whether the whole thing makes business sense. The boundaries are blurry by design.

Takeaway

The discipline of staying curious longer

Design Thinking's most important contribution isn't a framework or a set of tools. It's a discipline of staying in the problem space longer than feels comfortable. The natural instinct is to move quickly to solutions. Design Thinking trains teams to resist that instinct until the problem is truly understood.

This pays off compoundingly. Teams that invest in the Empathise and Define stages fail less often in prototyping. Teams that invest in prototyping fail less often in development. Development failures are exponentially more expensive than prototype failures. Every hour in a user interview is worth ten hours of avoided rework.

The core insight
You cannot design a good solution to a problem you don't understand. Understanding takes longer than assuming. It's almost always worth it.
The key skill
Asking questions that reveal behaviour, not questions that confirm hypotheses. The best researchers make people feel heard, not interrogated.
The common mistake
Treating Stage 3 (Ideate) as Stage 1. Starting with a solution and then doing "empathy research" to justify it. That's not Design Thinking. It's confirmation bias with a better name.

More on design & innovation

I write about design thinking, product strategy, and business frameworks. Follow on LinkedIn for more.