Design Thinking: The 5-Stage Framework That Changes How Teams Solve Problems.

Last Updated July 2026

Most teams are very good at building software quickly. The harder problem is building the right software at all. A team can run flawless sprints, keep its pipeline green, and still ship a product that no one adopts, because speed of execution says nothing about whether the underlying problem was worth solving. Design thinking exists to close that gap. It is a structured way to make sure the effort your engineers spend is pointed at a real user need before the code is written.

This guide covers the design thinking framework as it is actually practiced inside product and engineering organizations, not as an abstract creativity workshop. It walks through the five stages, the evidence for the business value of design, how the framework coexists with agile and lean, where it tends to fail, and a concrete plan for putting it into a team’s routine. If you want the strategy-level view aimed at executives, our companion piece on design thinking as a business strategy takes that angle; this article stays close to the ground where teams do the work.

What Design Thinking Really Is, and What It Is Not

Design thinking is a human-centered approach to problem solving. It starts from the observation that the people who will use a product understand their own problems better than the people building it, and that the most expensive mistakes are made early, when a team commits to solving a problem that was never defined correctly. Instead of jumping from a feature request to a build, design thinking inserts a deliberate period of understanding, framing, and testing cheap versions of a solution before anything expensive is committed.

The approach has deep roots. The economist and cognitive scientist Herbert Simon described design as a science of the artificial in 1969, framing it as the process of devising courses of action to change existing situations into preferred ones. The methodology was later popularized by the design firm IDEO and formalized in teaching by the Hasso Plattner Institute of Design at Stanford, commonly called the d.school, which articulated the five-stage model most teams recognize today.

It is worth being clear about what design thinking is not. It is not a substitute for engineering discipline, and it is not a linear checklist. Although the five stages are usually drawn in sequence, real projects loop backward constantly: a test result sends you back to redefine the problem, a new insight during ideation reopens your understanding of the user. The Nielsen Norman Group describes the process as iterative and non-linear, and treating it as a rigid waterfall is one of the most common ways teams get it wrong. For a fuller definition and history, the Nielsen Norman Group overview of design thinking and the Interaction Design Foundation reference are both reliable starting points.

Core Principles Behind the Stages

Underneath the five stages sit a few principles that matter more than the diagram. The first is empathy: decisions are grounded in observed user behavior rather than internal opinion. The second is bias toward making: ideas are expressed as tangible artifacts that can be reacted to, not slide decks that invite abstract debate. The third is comfort with ambiguity: teams deliberately hold the problem open longer than feels comfortable so they do not converge on the first plausible answer. The fourth is cheap failure: the whole point is to be wrong on paper and in prototypes, where being wrong costs almost nothing, rather than in production, where it costs a great deal.

These principles explain why the framework looks different depending on who is running it. A pure design team leans hard on empathy and divergent ideation. An engineering-led team tends to reach for prototyping first because building is its native language. Neither is wrong, but each carries a characteristic risk. Designers can research a problem indefinitely and never ship; engineers can build a beautiful solution to a problem they never bothered to define. A mature team balances the two by treating the framework as a checklist of questions rather than a fixed sequence of meetings. Have we watched real users? Have we written the problem down in one sentence everyone agrees on? Have we considered more than one solution? Have we tested the cheapest version? Have we let the evidence change the plan? If the answer to any of those is no, the team knows exactly where it is exposed.

The Business Case: What the Evidence Actually Shows

Design thinking is often sold with inflated numbers, so it is worth separating the well-documented evidence from the marketing. A few findings hold up across independent sources and are worth citing carefully. The Harvard Business Review essay Design Thinking Comes of Age is a useful anchor for why the practice moved from design studios into mainstream management.

McKinsey studied the design practices of more than 300 publicly listed companies over five years in its Business Value of Design research. It built a McKinsey Design Index to score how seriously each company treated design, and found that the top-quartile scorers outperformed their industry peers by roughly 32 percentage points in revenue growth and 56 percentage points in total returns to shareholders over the study period. The correlation held across sectors, including ones with no obvious consumer-facing design surface. (McKinsey, The Business Value of Design, 2018.)

The Design Management Institute reached a similar conclusion from a different direction. Its Design Value Index, built with Motiv Strategies, tracked design-driven public companies against the S&P 500 and reported that the design-led group outperformed the index by roughly 211 percent over the ten years from 2004 to 2014. (Design Management Institute, Design Value Index.)

Forrester’s Total Economic Impact study of IBM’s design thinking practice found that teams adopting the method reached decisions faster and reduced the rework caused by building the wrong thing, which shortened time to market for the projects studied. The precise figures are specific to IBM’s environment and should be read as directional rather than universal, but the direction is consistent with the broader research: the earlier a team validates a concept, the less it spends undoing bad decisions later. This tracks a long-standing finding in software engineering that the cost of fixing a defect rises sharply the later it is caught, which is exactly the cost design thinking attacks. We go deeper on connecting this to financial outcomes in our guide to measuring UX return on investment.

The honest summary is this: design thinking does not guarantee returns, and correlation studies cannot prove that design maturity causes outperformance. It is entirely possible that well-run companies both invest in design and perform well for the same underlying reason, namely good management. But the weight of evidence points one way, and the mechanism is intuitive. Teams that understand their users before building make fewer expensive mistakes, and mistakes caught in a paper prototype cost a tiny fraction of the same mistake caught after launch. The financial argument for design thinking is really an argument about the timing of failure. You are going to be wrong about some of your ideas no matter what. The only question is whether you find out while it is cheap to be wrong or after you have spent a release cycle and disappointed customers.

The Five Stages, Reframed for Product and Engineering Teams

The five stages are Empathize, Define, Ideate, Prototype, and Test. Below is what each one looks like when a real product team runs it, the artifact it should produce, and the failure mode to watch for.

1. Empathize: Understand the User Before Anything Else

The first stage is about replacing assumptions with observed reality. Teams conduct user interviews, sit with support tickets, watch people use the current product, and map the journey the user actually takes rather than the one the org chart imagines. The goal is not to ask people what they want, because users are poor at predicting their own behavior, but to observe what they do and where they struggle.

The artifact this stage produces is a set of grounded insights: journey maps, empathy maps, and a short list of the real pain points, expressed in the user’s language. The failure mode is skipping straight to solutions because the team believes it already knows the user. Time spent here is cheap insurance against the far larger cost of building the wrong feature.

Customer-facing teams that already do serious journey work have a head start here; our piece on customer journey optimization covers the mapping techniques in more detail.

2. Define: Frame the Problem in One Sentence

Define is where a team converts raw observation into a single, sharp problem statement. A good problem statement is specific about who has the problem, what they are trying to do, and why the current situation fails them. It is written from the user’s point of view, not the business’s. The classic form is a point-of-view statement: a particular user needs a way to achieve a particular goal because of a particular insight you uncovered.

The artifact is the problem statement itself, ideally short enough to fit on one line and agreed on by the whole team. The failure mode is a problem statement that smuggles the solution inside it. If your problem statement already names the feature you intend to build, you have not defined a problem, you have justified a decision. A well-framed problem opens the door to many possible solutions; a poorly framed one closes it.

A useful test: if two competent teams read your problem statement and would design noticeably different solutions, the statement is doing its job. If it forces everyone to the same predetermined feature, rewrite it.

3. Ideate: Generate Options Before Choosing One

Ideation is where the team deliberately widens the field of possible solutions before narrowing. The discipline is separation: generate quantity first without judging, then converge and select. Techniques range from structured brainstorming and how-might-we prompts to more constrained methods like worst-possible-idea, which loosens teams that are too cautious. The point is to make the obvious first answer compete against alternatives rather than winning by default.

The artifact is a shortlist of distinct concepts worth prototyping, ideally more than one so that testing has something to compare. The failure mode is anchoring: the team latches onto the first idea, usually the one proposed by the most senior person in the room, and spends the rest of the meeting rationalizing it. Guard against this by generating options independently before discussing them together.

4. Prototype: Build the Cheapest Thing That Can Be Tested

A prototype is a scaled-down version of an idea, built only well enough to answer a specific question. It can be a paper sketch, a clickable mockup, a fake landing page, or a hard-coded demo with no real backend. The value of a prototype is proportional to how quickly and cheaply it can be thrown away. The moment a team starts protecting a prototype because it took two weeks to build, the prototype has failed at its job.

The artifact is one or more testable representations of the concept. The failure mode is over-building: engineers, being engineers, are tempted to build the real thing because it feels more honest. Resist it. The distinction between a throwaway prototype and a minimum viable product matters here, and we cover it directly in prototype versus MVP. A prototype is built to learn; an MVP is built to launch.

5. Test: Put It in Front of Real Users and Listen

Testing puts the prototype in front of the people from the empathize stage and observes what happens. The team is not looking for validation; it is looking for the truth, which is often uncomfortable. Good testing is structured to make failure visible: watch where users hesitate, what they misunderstand, and what they ignore entirely. A concept that dies in testing is a success, because it died before it consumed a release cycle.

The artifact is a clear decision: proceed, pivot, or kill, backed by observed evidence. The failure mode is treating testing as a formality to confirm a decision already made. If your test cannot change the plan, it is theater. Because insights from testing routinely send teams back to redefine the problem or generate new ideas, this is where the non-linear nature of the framework becomes obvious in practice.

Design Thinking, Agile, and Lean: One Loop, Not Three Religions

Teams often treat design thinking, agile, and lean as competing philosophies to pick between. They are not competitors; they answer different questions and fit together in one loop. Design thinking asks whether you are solving the right problem. Lean asks how to validate the smallest testable version of a solution with the least waste. Agile asks how to build and refine that solution in fast, feedback-driven increments once it is worth building.

In a healthy product organization, design thinking dominates the front of the loop and reappears at every pivot; lean governs how experiments are scoped and measured; and agile carries the validated concept through delivery. The mistake is running agile with no design thinking upstream, which produces teams that build the wrong thing very efficiently. The table below lays out the differences.

Dimension	Design Thinking	Agile and Lean
Core question	Are we solving the right problem?	Are we building the thing right and fast?
Primary output	Validated problem definition and concept	Working software in short increments
Time horizon	Discovery, often weeks before a line of code	Delivery, measured in sprints and flow
Risk it reduces	Building something nobody needs	Slow feedback and large, risky batches
Where it fits	Front of the loop and at every pivot	Continuous execution and refinement

The practical implication is that these methods should share a single backlog and a single conversation, not live in separate teams that hand off to each other. When discovery and delivery are owned by different groups, a predictable pathology appears: the discovery team produces insights that the delivery team quietly ignores because they arrive too late or too abstract to act on. The teams that make the loop work keep engineers involved in the empathize and define stages so that what gets learned is shaped by what is feasible to build, and keep designers and product managers involved through delivery so that the original intent is not lost in implementation. The framework is less a sequence of stages owned by specialists than a shared habit of mind that the whole team carries from problem to release.

If you want to go deeper on the delivery side of this loop, our guides to the benefits of agile methodologies, lean methodology, and the tri-track agile approach show how discovery and delivery run in parallel rather than in sequence.

Where Design Thinking Breaks Down

The framework fails more often from bad implementation than from bad theory. The patterns are predictable, and naming them is the first step to avoiding them.

The most common failure is the workshop trap: a team runs a two-day design sprint, fills a wall with sticky notes, feels energized, and then returns to business as usual without changing a single decision. Design thinking that lives only in offsites is decoration. It has to change what gets built and what gets killed, or it is wasted effort.

The second failure is empathy theater: interviewing a handful of users to confirm what the team already planned, then citing the interviews as validation. Real empathy work is willing to be surprised and willing to abandon a favorite idea. The third failure is skipping straight to prototyping without defining the problem, which produces polished solutions to problems no one has. The fourth is over-investing in prototypes so that sunk cost prevents killing bad ideas.

The single best diagnostic for whether a team is really doing design thinking is simple: how often does it kill an idea after testing? A team that never kills anything is not testing, it is confirming.

There is also a quieter failure worth naming: applying the full framework where it does not belong. Not every piece of work needs discovery. A well-specified bug fix, a compliance-driven change with a fixed requirement, or a performance optimization with a clear target does not benefit from empathy interviews and divergent ideation. Forcing the ceremony onto tasks that do not need it burns credibility and teaches engineers that the method is overhead. The skill is knowing when the problem is genuinely ambiguous, which is when design thinking pays off, and when it is already well defined, which is when the team should simply execute. Reserving the full process for high-uncertainty, high-cost decisions keeps it valuable and keeps engineers willing to run it.

A 90-Day Plan for Engineering Leaders

For a leader introducing design thinking to a team that has never used it, a gradual rollout works better than a mandate. The following four steps move a team from awareness to habit over about a quarter.

1. Start with one real problem, not a training exercise. Pick a genuine upcoming feature and run the full five stages on it, so the team learns the method on work that matters rather than a toy scenario.
2. Timebox the discovery aggressively. Give the empathize and define stages a hard limit, often one to two weeks, so the team learns to reach a sharp problem statement under a deadline rather than researching indefinitely.
3. Make prototyping and testing routine, not special. Build a light standing process where every significant feature gets at least one cheap prototype in front of real users before engineering commits, and record the proceed, pivot, or kill decision.
4. Measure and share the kills. Track how many concepts the process eliminated before they consumed a release cycle, and communicate that as saved capacity. Nothing sells the method to skeptical engineers faster than seeing wasted work avoided.

This works whether the team is in-house or distributed. Organizations that run discovery with an external partner should read our take on outsourced UX design done well and how a broader digital transformation strategy creates the conditions for design work to stick.

Measuring Whether It Is Actually Working

The weakest part of most design thinking programs is measurement. Leaders introduce the method, everyone agrees it feels good, and no one can say whether it changed outcomes. The fix is to pair a leading signal for each stage, something you can observe immediately, with a lagging outcome it should eventually move. The table below gives a starting set.

Stage	Leading signal to watch	Lagging outcome it should move
Empathize	Hours of direct user contact per cycle	Fewer late-stage requirement reversals
Define	A single agreed problem statement	Reduced scope churn during the build
Ideate	Number of distinct options considered	Higher share of shipped features that are used
Prototype	Days from idea to testable artifact	Lower rework cost after release
Test	Percentage of concepts killed early	Better activation and retention on launch

None of these metrics is meaningful in isolation, and any one of them can be gamed. The point is the pairing: a leading signal tells you the practice is happening, and the lagging outcome tells you whether it mattered. Teams that already run outcome-based measurement will recognize this structure from our work on outcome-driven UX metrics, and it applies directly here. Emotional response also belongs in the picture, which is why emotional design is worth reading alongside the harder numbers.

Three Examples of Design Thinking in Practice

Abstract frameworks are easier to trust when they are attached to real outcomes. Three well-documented examples show the method at work in different contexts.

Airbnb: Getting Out of the Building

In its early days, Airbnb was close to failing. The founders eventually traced the problem to the listings themselves: the photos hosts uploaded were poor, so nobody booked. Rather than solve it with more code, they traveled to where the listings were, photographed the properties professionally by hand, and watched bookings rise. It was empathize and prototype in their rawest form: leave the building, observe the real problem, and test the cheapest possible intervention before trying to automate anything. The lesson that stuck was that the most valuable insight came from direct contact with users, not from the dashboard.

IBM: Scaling the Method Across an Enterprise

IBM built an entire practice around design thinking and trained tens of thousands of employees in it, restructuring how large product teams approached problems. The Forrester study of that program, cited earlier, found faster decisions and reduced rework across the projects examined. IBM’s example matters because it shows the method surviving contact with enterprise scale, where the usual objection is that human-centered design cannot work across thousands of engineers. It can, but only when it is embedded in the normal way of working rather than run as occasional workshops.

Bank of America: Keep the Change

When Bank of America worked with IDEO to grow its customer base, research revealed a behavioral insight: many people rounded up their spending and informally saved the difference. The resulting Keep the Change program rounded debit purchases up to the nearest dollar and moved the difference into savings automatically. It attracted millions of new customers and accounts within a few years of launch. The product succeeded because it started from an observed human behavior rather than a feature the bank wanted to sell.

Frequently Asked Questions

1. What are the five stages of the design thinking framework?

The five stages are Empathize, Define, Ideate, Prototype, and Test. They are usually drawn in sequence, but in practice teams loop back and forth between them as new evidence emerges, so the model is iterative rather than strictly linear.

2. Is design thinking the same as agile?

No. Design thinking is a discovery method that asks whether you are solving the right problem, while agile is a delivery method that asks how to build a solution in fast, feedback-driven increments. They complement each other: design thinking sits at the front of the loop and agile carries the validated concept through to release.

3. How is a prototype different from a minimum viable product?

A prototype is built only to learn and is meant to be thrown away, so it can be as rough as a paper sketch. A minimum viable product is a real, shippable version built to be launched and used by customers. Confusing the two leads teams to over-invest in prototypes and under-test their ideas.

4. Where is design thinking most useful?

It is most useful when a problem is poorly understood, the cost of building the wrong thing is high, or a team keeps shipping features that go unused. It adds less value for well-defined, purely technical tasks where the requirement is already unambiguous.

5. How do I introduce design thinking to a skeptical engineering team?

Start with one real, upcoming feature rather than a training exercise, timebox the discovery so it does not drag, and track how many bad ideas the process kills before they consume a release cycle. Demonstrating avoided rework convinces engineers faster than any workshop.

Conclusion

Design thinking is not a creativity ritual and it is not a replacement for engineering rigor. It is a discipline for making sure the rigor is spent on the right problem. The five stages give a team a repeatable way to understand users, frame the real problem, generate real options, build cheap tests, and kill bad ideas before they become expensive. The evidence that design maturity correlates with business performance is strong, the mechanism is intuitive, and the failure modes are well understood and avoidable.

The teams that get the most from the framework are the ones that treat it as part of how they work every week, not as an offsite they attend once a quarter. Start small, run it on one problem that matters, measure the ideas it helps you avoid building, and let the results make the case. If you want help embedding discovery and delivery into a single working loop, that is exactly the kind of engineering partnership Coderio is built to provide.

Related Reading:

• Design Thinking as a Business Strategy
• Does Your Product Need a UX Makeover?
• Prototype vs MVP: The Key Differences
• How to Measure UX ROI with Outcome-Driven Metrics
• The Benefits of Agile Methodologies for Business