Design thinking process: The 5 stages explained for teams

For engineering leaders already fluent in agile, the payoff is fewer wasted sprints on features nobody wanted. Here's how the five stages actually map onto backlog grooming, prototyping, and usability testing in practice.

What is the design thinking process?

The design thinking process is a human-centered method for validating the problem before committing to a solution. Software teams often run it backward: they build a solution, then test it on users, and skipping the empathize stage is how features nobody asked for get built.

Stanford d.school formalized design thinking as a five-stage, non-linear process built on human-centered design: Empathize, Define, Ideate, Prototype, and Test. IDEO's Tim Brown described it in a 2008 Harvard Business Review article as using a designer's sensibility and methods to match what people need with what is technologically feasible and commercially viable.

Other frameworks use three, four, or six stages (compared below). This guide maps each stage to backlog grooming, sprint planning, and engineering handoff.

The 5 stages of design thinking (Empathize to test)

Stanford d.school's original process documentation names five distinct stages: empathize, define, ideate, prototype, and test, each designed to move a team from open-ended discovery toward a testable answer. Map them onto a sprint cycle and the overlap is closer than most engineering leads expect.

That overlap becomes clearer once you see how these stages fit into a full frontend development workflow, from design handoff through build and deployment.

The empathize stage happens before backlog grooming, not during it, because understanding user needs must precede prioritization decisions. Its output, an empathy map and a validated problem statement, is what should populate your next planning session, not a stakeholder's hunch. Define stage work turns that into an epic-level user story with real constraints attached.

The ideate stage runs as a standalone workshop ahead of sprint planning: divergent thinking widens the idea set, convergent thinking narrows it to what's worth building. Skip the divergent half and you get incremental features, not new ones.

Rapid prototyping is the design-spike equivalent of sprint zero, a low-fidelity build measured in days, not a production feature measured in weeks. Test closes the loop: a user testing feedback loop that runs alongside the next sprint so findings land before the feature ships, not after.

IDEO's Tim Brown frames this as human-centered design in practice: the process works because it forces teams to test ideas against real users before engineering commits sprint capacity to them.

Empathize stage: Understanding real users before you build

The empathize stage means running structured user interviews and UX research before anyone touches a backlog item, not layering research on top of a sprint that's already planned. Skipping it is how teams ship a technically correct feature nobody asked for.

In practice this looks like five to eight one-on-one interviews, contextual inquiry sessions where a researcher watches someone use the current tool, and synthesis into an empathy map that separates what users say from what they actually do.

You don't need a hundred interviews to get a defensible signal: patterns usually repeat within the first handful of conversations.

For engineering leads used to a defined, user-centered process, the adjustment is procedural: empathy work becomes its own short cycle with its own exit criteria, sitting one step ahead of definition and ideation.

Treat it as flexible enough to fit a two-week sprint boundary, and it stops feeling like a design thinking process bolted onto agile and starts reading as the research phase agile always assumed someone was doing.

Define stage: Framing a sharp problem statement

A sharp problem statement translates empathize-stage findings into one sentence a backlog can act on: user, context, unmet need. Stanford d.school calls this synthesis step a "point of view"; Harvard Business School Online's four-phase model folds it into its first phase, Clarify. Either way, the design thinking process should yield a defined, user-centered problem statement, not a stakeholder wishlist dressed up as a spec.

Building one starts with an empathy map: what the user says, thinks, does, and feels, pulled straight from empathize-stage interview notes. Teams then converge each persona's map into a single problem statement, then hand it to developers as backlog grooming input: an epic-level acceptance criterion, not a five-page brief.

Whichever model a team follows, divergent thinking generates raw ideas, convergent thinking narrows them to one testable problem statement before ideate-stage brainstorming makes those ideas tangible through rapid prototyping.

Ideate stage: Divergent thinking techniques that work

The ideate stage is where the defined problem statement turns into a volume of possible solutions before anyone commits to one. Teams run divergent thinking first, generating as many ideas as possible without judging them, then switch to convergent thinking to cluster, vote, and cut that list down to a shortlist a sprint can actually build.

SCAMPER technique is one of the more reliable divergent tools for engineering-adjacent teams: Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse.

Run it against an existing feature backlog item and it forces the kind of lateral moves backlog grooming rarely produces on its own. A structured prompt list gets more varied ideas out of a room than open discussion, which matters when the next step is convergent narrowing, not more debate.

The test for a good ideate session isn't idea count. It's whether convergent thinking leaves the team with two or three testable concepts, not one, ready for the prototype stage's user testing feedback loop.

Prototype and test: Rapid prototyping and the feedback loop

Rapid prototyping turns the ideate stage's shortlist into something a user can react to, not a finished product. Most teams build a minimum viable prototype in a week or less, clickable wireframes, a paper flow, or a rough front-end shell wired to fake data, because the point is to test the concept, not the execution.

Speed is the point. For Barometa, a recruitment-tech startup, Netguru went from one scoping session to a working prototype in 14 days, fast enough to put the concept in front of users and investors while the idea was still cheap to change.

The user testing feedback loop is where design thinking earns its keep as a process, not a workshop exercise.

A tester works through the prototype, a facilitator observes and asks open questions, and the team logs friction points against the original problem statement from the empathize stage. Most teams run several small rounds of about five users rather than one large study, because the same problems start repeating quickly.

Each round feeds new ideas back into a short convergent pass, then a build-test cycle again. For software teams, this maps cleanly onto existing sprint cadence: prototype and test can sit inside a single two-week sprint alongside backlog grooming, with usability findings entering the backlog as tickets rather than a separate design document handed off cold to developers.

Why design thinking is non-linear, not a waterfall

Design thinking loops back on itself constantly rather than advancing through stages once, and that's the whole point. A failed user testing feedback loop doesn't end the project, it sends the team back to reframe the problem statement or rerun the empathize stage with a sharper question.

Waterfall diagrams with five clean boxes and an arrow are a teaching aid, not how the process works in practice. IDEO's Tim Brown describes it as three overlapping spaces, inspiration, ideation, implementation, precisely because linear stage counts obscure the iteration.

The stage count matters less than how often the team loops. For teams already running agile development, this maps onto backlog grooming directly: a usability test that fails becomes a new backlog item, not a reset. Iterative design is the mechanism itself, not a fallback when the plan goes wrong.

Design thinking in software and product teams

The design thinking process fits inside agile development rather than replacing it.

Empathize and define stages fold into backlog grooming and discovery sprints; ideate and rapid prototyping slot straight into sprint planning; the user testing feedback loop becomes your sprint review, feeding a reframed problem statement back into the next cycle.

Teams looking to compress this cycle into a fixed timebox often turn to running a structured design sprint as a focused execution of the ideate-to-test loop.

Run empathize-stage UX research before backlog grooming starts, not after: it's cheaper to discard a wrong assumption in a sketch than in a merged pull request. That's the total-cost-of-ownership case for design thinking: rework avoided upfront beats rework fixed post-launch.

Developers inherit whatever the prototype tests validated, or invalidated, before a single sprint ticket exists. That's the whole point of running design thinking alongside agile instead of before it.

3, 4, 5, or 6 stages: Comparing design thinking models

No single design thinking process is canonical. The main models describe the same work at different levels of detail:

IDEO's three-phase model folds empathize and define work into a single inspiration phase, while the d.school keeps them separate, which helps teams that need a clear handoff between research and problem framing. The four- and six-phase models add an explicit implementation step at the end.

For engineering teams, the stage count matters less than where the loop closes. A five-stage process maps cleanly onto sprint boundaries; a three-phase process suits smaller teams running looser cycles. Pick the model that fits your existing planning cadence, not the one with the most steps.

Design thinking FAQs

Run design thinking on your next product sprint

Running a human-centered design thinking process on your next sprint means testing ideas with real users before engineering commits sprint capacity to the wrong feature.

Netguru's design teams run this empathize-to-test loop on live product work, turning workshop ideas into tested screens instead of a slide deck. If you want it in a focused, time-boxed format, we can run a structured design sprint with your team. To scope it, talk to our team.