What is Design Thinking? A Practical Guide for Beginners

If you’ve spent any time around user experience (UX) design, you’ve seen the diagram: five coloured shapes labelled Empathise, Define, Ideate, Prototype, Test, usually accompanied by a wall of sticky notes and someone insisting there are no bad ideas. That’s the public face of design thinking, and it’s done the concept no favours. The workshops and the Post-its are the props. The actual idea underneath is more useful, and much older, than the branding suggests.

Design thinking is a human-centred, iterative approach to problem solving. Instead of jumping straight to solutions, it pushes you to understand the people involved, question whether the problem you’ve been handed is the real problem, and explore ideas through prototyping and testing rather than debate.

Designers have worked this way for decades. What’s changed is where it gets applied: business strategy, public services, healthcare, even global development work. You don’t need “designer” in your job title to use it, because it was never really about designing things. It’s a way of thinking that happens to produce things.

This article covers what design thinking is, the principles underneath it, the five-stage model you’ll meet most often, and the other frameworks you’ll bump into, plus what they all have in common.

The Principles Behind Design Thinking#

Strip away the diagrams and design thinking rests on a handful of commitments.

Human-centred. Start with people: their needs, behaviours, and the context they’re operating in. Not the org chart, not the quarterly target, not the technology you happen to have lying around.

Solve the right problem. Problems usually arrive described by their symptoms. Design thinking treats the first description with suspicion and digs for causes, because a symptom you patch will come back. More on this below, it’s arguably the whole point.

Think in systems. Problems don’t exist in isolation. Speeding up your checkout is pointless if the payment step feels untrustworthy or deliveries keep failing; you’ve optimised one part of an experience that breaks somewhere else. Zoom out, look at the whole, and before you ship a fix, ask: “if we fix this, what else changes?”

Iterate. Don’t build the final answer in one go. Make small interventions, test them, learn, improve.

Work non-linearly. The stages of any design thinking model can run in parallel, repeat, or loop back on each other. They’re modes of work, not a checklist.

Collaborate. Designers don’t have all the answers. Good ideas come from mixed-discipline teams, and frequently from the people you’re designing for.

If some of this sounds like plain good sense, that’s because it is. The value is in actually doing it when a deadline is looming and a stakeholder already “knows” the solution.

Solving the Right Problem#

Here’s where design thinking genuinely differs from how most of us are trained to work. Economists, engineers, and business analysts are excellent problem solvers, but they tend to solve the problem as presented. Design thinking asks an annoying question first: is this actually the problem?

The classic illustration comes from 1854, when cholera tore through the Soho district of London. The prevailing response was to treat the sick, which addressed the symptom and did nothing to stop new cases. A physician named John Snow mapped the outbreak instead and traced the cases to a single contaminated water pump on Broad Street. Remove the pump handle, and the outbreak collapses. The root cause was the water supply, and no amount of treating patients would have fixed it.

Product work repeats this pattern constantly. Support tickets spike, so the team writes better help articles, when the real cause is a confusing flow upstream. Sign-ups drop, so marketing spends more on ads, when the form itself is quietly rejecting valid email addresses. A useful rule of thumb: don’t just treat the headache, ask what’s causing it.

The Five Stages of Design Thinking#

The most widely taught model comes from the Hasso Plattner Institute of Design at Stanford, better known as the d.school, which was co-founded in 2004 by David Kelley, who also founded the design consultancy IDEO. It breaks the work into five stages.

1. Empathise: Research Your Users’ Needs#

Empathise is about building a deep, human-centred understanding of the people you’re designing for. Instead of relying on assumptions, you step into their world. Talk to them. Watch what they do, which is frequently different from what they say they do. Where you can, experience their environment yourself, an approach researchers call contextual inquiry or ethnographic research.

Collecting data is a means here, not the point. You’re after motivations, frustrations, and needs, including the ones people can’t articulate. Consulting domain experts helps too, but nothing replaces direct contact with users. Empathy matters here because it lets you suspend your own assumptions long enough to see the problem through someone else’s eyes, and everything in the later stages is built on that foundation.

2. Define: State Your Users’ Needs and Problems#

Define is where you make sense of what the research told you. You sift the raw observations for pain points and recurring themes, then distil them into a problem statement that frames the challenge around the user’s needs rather than the company’s goals.

The framing matters more than it looks. Compare these two:

• “We need to cut call-centre costs by 15% this year.”
• “Customers need to sort out simple account problems without waiting on hold.”

The first is a business target dressed up as a problem; it points you at staffing cuts and call-deflection tactics. The second is a human problem, and it opens up a much wider field of possible solutions. A good problem statement is human-centred, actionable, and focused enough to give direction while staying broad enough to leave room for creative answers.

Teams often then reframe the statement as “How might we…?” questions to set up ideation: “How might we help customers resolve simple problems themselves, in the moment?” That phrasing has a longer history than you’d guess. Min Basadur introduced it at Procter & Gamble in the 1970s, precisely because “how might we” invites possibilities where “how can we” invites objections.

3. Ideate: Challenge Assumptions and Create Ideas#

With research insights and a clear problem statement behind you, ideation is where you generate as many solutions as you can. The mindset shift is deliberate: you stop interrogating the problem and start imagining answers, and early on, no idea is too wild. Quantity first, judgement later.

Structured techniques help, because “everyone shout ideas” reliably produces the loudest person’s ideas:

• Brainstorming – fast, free-flowing ideas in a group.
• Brainwriting – the quiet version: everyone writes ideas down individually, then shares. Kinder to people who think before they speak.
• Worst possible idea – deliberately invent terrible solutions to loosen everyone up. Bad ideas are easy to produce and surprisingly good at revealing what a good idea would need.
• SCAMPER – a checklist of prompts (Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse) devised by education writer Bob Eberle in 1971, building on brainstorming pioneer Alex Osborn’s earlier question lists.

Once you’ve cast the net wide, you converge: refine, combine, and select the ideas that most directly address the problem statement or offer something worth building on. The point of all this divergence is to stop the team locking onto the first plausible solution, which is what groups do by default.

4. Prototype: Start Creating Solutions#

Prototyping turns the chosen ideas into cheap, scaled-down versions of the product or feature, so they can be explored and tested rather than argued about. Paper sketches, clickable wireframes, cardboard mock-ups: whatever makes the idea tangible fastest.

Prototypes are questions, not answers. You build one to find out what works, what doesn’t, and why. Testing several in parallel lets you compare approaches and learn faster than polishing a single favourite. Each prototype meets one of three fates: accept it and move forward, improve it based on feedback, or reject it and take the lesson.

This stage is where flawed ideas get exposed while they’re still cheap. A usability problem found in a paper prototype costs you an afternoon. The same problem found after development costs a release cycle and some credibility.

5. Test: Try Your Solutions Out#

Testing is where your ideas meet the real world: the best prototypes, usually at higher fidelity by now, in front of real users in realistic scenarios.

Testing exists to teach you things, and a session that only confirms what you already believed has taught you very little. Watch for more than task completion: emotions, expectations, workarounds, the moments where someone hesitates or uses a feature in a way nobody anticipated. Results tend to sort into three buckets. The solution works as expected (confirm). It mostly works and needs adjusting (refine). Or it reveals a deeper problem, and you loop back to an earlier stage (redirect).

That third outcome feels like failure and isn’t. Discovering that you defined the wrong problem before you’ve built anything expensive is the process working exactly as intended.

A Loop, Not a Line#

The five stages get drawn as a sequence, and that’s the single most misleading thing about them. In practice the stages are modes of work that overlap, repeat, and feed back into each other. Teams prototype while research is still running. A test session sparks new ideas, or reveals that the problem statement was off, sending you back to Define. You cycle through as many times as the problem demands.

None of this is the process going wrong. The flexibility is the point: it’s what lets a team respond to what they learn instead of marching through a plan that the evidence has already contradicted. As David Kelley put it: “Fail faster. Succeed sooner.”

Other Frameworks Worth Knowing#

The d.school model is the one you’ll meet most often, but it has company. Each alternative slices the same underlying process differently.

The Double Diamond#

Developed at the British Design Council in 2004, the Double Diamond builds on systems theorist Béla H. Bánáthy’s divergence-convergence model from the 1990s. Its insight is rhythmic: design alternates between divergent thinking (opening up, exploring widely) and convergent thinking (narrowing down, deciding), and it does so twice. Once around the problem, once around the solution.

The four phases: Discover (gather insights, research user needs), Define (frame the problem in line with user needs and business goals), Develop (generate, test, and refine possible solutions), and Deliver (finalise and launch). If you’ve ever watched a team brainstorm solutions before anyone agreed what the problem was, the Double Diamond is the diagram to draw on the whiteboard.

The LUMA System#

The LUMA Institute distils design thinking into three core skills, each backed by a library of specific methods:

• Looking – observing people and contexts
• Understanding – making sense of what you’ve seen, spotting patterns and themes
• Making – bringing ideas to life through prototyping and testing

Its appeal is flexibility. Rather than prescribing a sequence, LUMA treats the methods as a toolkit you combine to suit the size and messiness of the challenge in front of you.

Head, Heart and Hand#

A simpler framing that maps the work onto three human capacities: the head solves (analytical thinking and problem solving), the heart empathises (understanding human needs and emotions), and the hand creates (making tangible solutions through prototyping).

Its useful reminder is about balance. Design that’s all head produces clever things nobody wants; all heart, sympathetic things that don’t work; all hand, beautifully built answers to the wrong question.

What Every Framework Shares#

Names and stage counts differ, but all of these frameworks share the same DNA. They start with empathy, grounding the work in real user needs. They reframe the problem to get past symptoms and find causes. They diverge before they converge, exploring widely before narrowing down. They make ideas tangible early and test them with real people. And they draw on collaboration across disciplines rather than a lone genius at a whiteboard.

Get those habits right and the choice of framework matters far less than the diagrams imply. Done well, any of them points you toward the same target: solutions that are desirable to users, technically feasible, and viable for the business.

If you take one thing from all of this, take the reflex. When a problem lands on your desk with a solution already attached, pause and ask whether it’s the real problem or just the loudest symptom. Don’t just treat the headache. Ask what’s causing it.