Understand the difference between the classic 5-stage and 6-stage design thinking models. What each stage involves, when to use each model, and how they connect.
The design thinking process is most commonly described in five stages, but some practitioners and tools use six. The difference is not academic. It changes how teams start projects, and choosing the wrong model can leave critical alignment gaps.
The five-stage model, popularized by Stanford's d.school, is the most widely taught version. It traces back to the work of David Kelley and Hasso Plattner in the mid-2000s and has become the default framework in university programs, corporate training, and most design thinking literature.
This model works well when the team already shares a common understanding of the problem space. The assumption is that empathy research will naturally surface the project's scope and focus.
The six-stage model adds an explicit Initialize (sometimes called "Understand" or "Frame") stage before Empathize. This stage forces the team to answer foundational questions before spending any time on research:
This stage exists because experienced practitioners noticed a recurring pattern: teams would start empathy research and then realize, several interviews in, that they were not aligned on what they were researching or why. Different team members had different assumptions about the project's scope, target users, and goals. The Initialize stage makes those assumptions explicit before anyone spends time on research.
Consider a healthcare company that wants to "improve the patient experience." In the 5-stage model, the team starts with Empathize by interviewing patients. But which patients? In which context? Emergency room visits? Chronic disease management? Insurance billing? Without an explicit framing step, each researcher might pursue a different thread, producing research that does not converge.
In the 6-stage model, the Initialize stage forces the team to agree: "We are focusing on the experience of patients with chronic conditions who manage multiple medications and see specialists at least quarterly." Now empathy research has a clear target, and every interview contributes to the same understanding.
This is not a trivial difference. In organizations where design thinking projects involve multiple departments, stakeholders, or external partners, the Initialize stage can save weeks of misaligned effort.
Frame the challenge, identify your target users, and set project boundaries. The output of this stage is a shared brief that every team member can reference throughout the project. It answers: What are we doing? For whom? Within what constraints? Read the full Initialize stage guide.
This stage typically takes a few hours to a full day, depending on the project's complexity. For solo practitioners or small teams, it can be as simple as writing a one-page project brief. For large organizations, it might involve stakeholder interviews and a formal kickoff workshop.
Engage directly with the people you are designing for. The goal is to understand their lived experience: what they do, what they feel, what they need but cannot articulate. Methods include user interviews, contextual observation, surveys, and diary studies.
The critical skill here is listening without an agenda. You are not looking for evidence that supports your hypothesis. You are looking for surprises, contradictions, and patterns you did not expect. The most valuable empathy insights are the ones that challenge your assumptions. See the Empathize stage guide for interview techniques and synthesis methods.
Synthesize your empathy research into actionable problem statements and How Might We questions. This is the pivot point of the entire process: everything before it is about understanding the problem; everything after it is about solving it.
A well-crafted problem statement focuses the team's creative energy on the right target. A poorly crafted one sends the team off solving a symptom rather than the root cause. Read the full Define stage guide.
Generate as many potential solutions as possible, then evaluate, combine, and select the most promising ones. The key discipline here is separating generation from evaluation. During divergent ideation, no idea is criticized. During convergent evaluation, every idea is scrutinized against user needs, feasibility, and business viability.
Most teams underinvest in ideation. They generate 5 to 10 ideas and pick the most obvious one. Experienced design thinkers generate 30, 50, or even 100 ideas before converging, because the best solutions often emerge from unexpected combinations. See the Ideate stage guide.
Build the cheapest possible version of your idea that lets you test your core assumption. The prototype's fidelity should match what you are testing. If you are testing whether users understand a concept, a paper sketch is enough. If you are testing whether users can navigate a flow, you need clickable wireframes.
The golden rule of prototyping: if it took more than a few days to build, it is too polished. The purpose of a prototype is learning, not impressing. See the Prototype stage guide and Rapid Prototyping for Beginners.
Put your prototype in front of real users. Observe what they do (not just what they say). Ask open-ended questions. Look for moments of confusion, delight, frustration, and unexpected behavior. Each test session should produce specific, actionable insights about what to change.
Testing is not a one-time event. It feeds back into earlier stages. A test might reveal that you defined the problem too narrowly, sending you back to Define. It might reveal a user need you missed, sending you back to Empathize. This looping is how design thinking converges on genuinely useful solutions. See the Test stage guide and User Testing Methods.
One of the most important things to understand about both models is that the stages are not a linear checklist. Experienced design thinkers move fluidly between stages based on what they learn. A test session might send the team back to empathy research. A prototyping exercise might reveal that the problem statement needs reworking.
This fluidity makes design thinking uncomfortable for people accustomed to linear project plans with clear milestones and deadlines. But it is precisely this willingness to revisit earlier assumptions that makes the methodology effective at tackling complex, human-centered problems.
The stages exist to ensure that you do each type of thinking (understanding, defining, generating, building, testing) deliberately. They do not dictate a fixed sequence.
Use the 6-stage model when:
Use the 5-stage model when:
Design Thinker Labs uses the 6-stage model, starting every project with an Initialize stage that creates a clear, explicit foundation for all subsequent work.
Related guides: design thinking vs agile · design sprint vs design thinking · design thinking examples
Design Thinker Labs Home · All Guides · How It Works · Pricing