Design Thinking Process: 5 Stages Explained

Most product failures aren't engineering failures. They're empathy failures — teams building the right thing for the wrong user, or the right user's wrong problem.

Design thinking is the discipline that closes that gap. It's a structured, human-centred approach to problem-solving that keeps real user needs at the centre of every product decision, from the first research session to the final prototype test.

The design thinking process has five stages: Empathise, Define, Ideate, Prototype, and Test. But more than a checklist, it's a mindset shift — from "what can we build?" to "what should we build and for whom?"

Here's how it works, why it matters, and how leading product teams apply it in practice.

Key Takeaways

• The design thinking process follows five stages: Empathise, Define, Ideate, Prototype, and Test — each building on the last.
• Teams that centre on user empathy before ideation consistently build products that resonate, not just function.
• Design thinking reduces costly late-stage rework by surfacing real user needs before development begins.
• Cross-functional collaboration is built into the process — researchers, designers, and engineers work from the same user insight, not siloed briefs.
• IBM research found that companies applying design thinking report improvements in customer satisfaction, productivity, time-to-market, and sales.

What Most Teams Misunderstand About Design Thinking

Design thinking isn't brainstorming. And it isn't just about making things look good.

It's often mistaken for a UX process, or worse, a creativity exercise that kicks off a project and then gets forgotten. Neither captures what it actually does.

The design thinking process is about reducing the gap between what teams assume users need and what users actually need. That gap is where most product failures live. You can build a technically excellent product that solves the wrong problem — and teams do it constantly.

What makes design thinking different is that it front-loads the hard work. Empathy and definition happen before a single feature is scoped. That means when you do start building, you're building from a grounded understanding of the problem, not a hypothesis dressed up as certainty.

And it's not a linear march through five stages. Good design thinking is iterative. You'll loop back from testing to ideation, from prototyping to definition. That's not failure — that's the process working.

Why Design Thinking Works in Product Development

The evidence for design thinking in product engineering isn't anecdotal. IBM's research across hundreds of organisations found that teams applying design thinking most consistently cited four outcomes: higher customer satisfaction, faster time-to-market, improved productivity, and increased sales.

Those outcomes have a common root: decisions get made from real user insight rather than internal assumption.

Here's what that looks like in practice.

Users stay engaged longer when products solve real problems rather than assumed ones. Engagement isn't driven by features — it's driven by relevance.

User experience improves because the creative process is informed by observation and feedback, not guesswork. Features that feel intuitive don't happen by accident.

Cross-functional teams move faster because design thinking creates a shared understanding of the user problem. Designers, engineers, and product managers aren't working from different interpretations of the brief — they're all anchored to the same user research.

Innovation happens more reliably because the process creates structured space for divergent thinking. Teams explore widely before converging — which means better ideas surface that wouldn't emerge from a standard requirements session.

Time-to-market compresses because rapid prototyping and early testing catch problems before they become expensive. Catching a fundamental UX issue in a paper prototype costs a fraction of catching it in a coded feature.

The 5 Stages of the Design Thinking Process

Stage 1: Empathise — Understand Before You Assume

The design thinking process starts by setting aside what you think you know about your users.

Empathise means doing real research: observing users in their actual environment, conducting interviews, running surveys, and building empathy maps that capture what users say, think, do, and feel. The goal is to uncover genuine pain points and needs — not validate the ones you assumed going in.

Methods that work here include structured user interviews with open-ended questions, contextual observation (watching how users interact with existing tools or workflows), and empathy mapping workshops that synthesise findings across a team. The output of this stage is deep, specific user understanding — not a persona document that gets filed and forgotten.

Stage 2: Define — Write a Problem Statement Worth Solving

All that empathy research feeds into one deliverable: a clear, well-scoped problem statement.

A good problem statement names three things — the gap (what users currently can't do or don't have), the impact (how that gap affects their time, cost, or experience), and the importance (why solving it creates real value). The 5 Ws framework (who, what, where, when, why) is a useful structure here.

What you're trying to avoid is a problem statement so broad it could describe anything, or so narrow it could only describe one edge case. The Define stage turns raw research into a focused brief that guides every ideation session that follows.

Stage 3: Ideate — Generate Before You Filter

With a clear problem statement in hand, the Ideate stage opens up possibility space.

The rules here are deliberate: generate many ideas before evaluating any of them. Quantity over quality in the first pass. No criticism, no feasibility checks, no "yes but." Sketches, mind maps, wild cards, analogous inspiration from other industries — all of it goes on the board.

Teams that rush to evaluate too early default to the first reasonable solution rather than the best one. Separating divergent and convergent thinking — generating widely, then converging on the strongest ideas — consistently surfaces better solutions than jumping straight to a shortlist.

Stage 4: Prototype — Make Ideas Tangible Quickly

A prototype doesn't need to be polished. It needs to be testable.

Low-fidelity prototypes — paper sketches, clickable wireframes, storyboards — are enough to test whether an idea works in principle. The goal is to make something tangible fast, expose it to feedback, and learn before committing engineering time.

Prototyping also has a clarifying effect on teams. What seems like a simple idea on a whiteboard often reveals complexity the moment someone tries to draw it. Surfacing those gaps at the prototype stage is far cheaper than discovering them mid-sprint.

For SaaS application development teams in particular, design thinking prototypes map naturally to the sprint cycle — each prototype is a hypothesis, each test is a validation loop.

Stage 5: Test — Learn from Real Reactions

Testing brings the process full circle. You put your prototype in front of real users — ideally users who match the personas from your Empathise stage — and observe how they interact with it.

Usability testing, A/B variants, beta cohorts — the format depends on the fidelity of the prototype and the stage of development. What matters is that you're getting real reactions, not internal opinions.

Test results don't always validate. Often they send you back to Ideate, or even back to Define if the problem statement itself turns out to be wrong. That's not failure. That's learning at the cheapest possible point in the process.

Design Thinking in Action: Brands That Got It Right

The most widely studied design thinking examples share a common thread: the breakthrough came from deep user understanding, not technical cleverness.

Apple is the canonical example — every product decision traced back to how real users actually interact with technology, not how engineers expected them to. Packaging, onboarding, the layout of a notification — all tested, all user-centred.

Coca-Cola's Happiness Machine campaign emerged from asking what emotions customers associate with the brand rather than what features they want in a vending machine. The insight produced a campaign that felt personal and human because it was built on personal, human observation.

Airbnb used design thinking to rebuild its entire user experience in the early years — literally walking through the guest and host journey themselves to find the friction points that surveys would never surface.

The pattern isn't coincidence. It's what happens when you solve the right problem.

How to Apply Design Thinking in Your Product Team

You don't need a design studio or a weeks-long sprint to start. Here's how to bring design thinking into MVP development or ongoing product work:

• Run user interviews before every major feature decision. Even three interviews surface patterns you won't get from analytics alone.
• Write a problem statement before opening a design tool. If your team can't agree on the problem in one sentence, you're not ready to solve it.
• Build low-fidelity prototypes of new concepts before committing to a sprint. Clickable Figma frames cost hours, not weeks.
• Test with users who don't work at your company. Internal teams make terrible test subjects — they already understand the context too well.
• Create feedback loops. Design thinking isn't a phase that ends — it's an operating model that keeps informing your roadmap.

Let's Wrap This Up!

The design thinking process — Empathise, Define, Ideate, Prototype, Test — isn't a methodology for design teams. It's a problem-solving discipline for anyone who builds products that need to work for real people.

Teams that apply it consistently build products that resonate faster, iterate more efficiently, and avoid the expensive late-stage rework that comes from building first and understanding users second.

At Classic Informatics, we integrate design thinking into how we approach product engineering — from early discovery through iterative delivery. If you're building a new product, modernising an existing one, or trying to accelerate a roadmap that's lost momentum, we'd be glad to talk through how the process applies to your situation.