Design thinking gets thrown around constantly, but few teams run the full process end to end. Here's what the five phases look like, how they compare to Agile, where the method gets criticized, and how AI is reshaping the workflow.
The design thinking process explained through real phases, models, and examples.
TL;DR
Design thinking is a human-centered problem-solving methodology built around empathy, experimentation, and iteration.
The most widely used model has 5 phases: Empathize, Define, Ideate, Prototype, and Test.
It is not a business strategy framework. It is a working process designers use to move from a vague problem to a tested solution.
We use it daily on client work, and we'll show you where it shows up in real product decisions.
You'll also find the core principles, common mistakes, tools, and resources to learn it properly.
Most people have heard the term thrown around in workshops, LinkedIn posts, and product meetings. Far fewer have actually used it on a real project with real constraints and a real deadline.
We use this approach on nearly every engagement at Groto, not as a slide in a pitch deck, but as the actual way we get from "we don't know what's wrong" to "here's a solution that works." This guide breaks down what the methodology is, how the process works step by step, and where it shows up in real design work.
What Is Design Thinking?
In simple words, within UI/UX design it is a way of solving problems that starts with people, not solutions. Instead of guessing what users want and building toward that guess, you observe real behavior, define the actual problem, and test ideas cheaply before committing resources to them.
It is often credited to IDEO's David Kelley and Tim Brown, who helped formalize it into a repeatable process in the 1990s. But the underlying instinct, watch people, understand their friction, build something to address it, has been part of good design practice for far longer than the label has existed.
At its core, the approach rests on three questions:
Is it desirable? Does this actually solve something people care about?
Is it feasible? Can we realistically build it with the resources we have?
Is it viable? Does it make sense as a sustainable product or business decision?
A solution that fails any one of these three tests usually fails in the market too.
Where the Process Came From
The intellectual roots go back further than most guides mention. Herbert Simon's 1969 book "The Sciences of the Artificial" was one of the first serious attempts to treat design as a discipline with its own logic, separate from pure science or art. Stanford and IDEO built on that foundation decades later, turning it into something teams could actually run.
Design has always involved understanding users before building for them. What changed in the last few decades is that this instinct got documented, taught, and scaled. Stanford's d.school and IDEO turned an informal creative habit into a structured design thinking process that non-designers could also learn and apply.
That's part of why it spread so quickly beyond product design into fields like healthcare, education, and even government services. The process gave teams a shared vocabulary for a way of working that experienced designers were already doing intuitively.
The Design Thinking Process: 5 Phases
The version taught most often, and the one we default to within our broader UX design process, breaks into five phases. They are rarely linear in practice. You loop back, repeat steps, and sometimes run two phases in parallel.
1. Empathize
You start by understanding the people you're designing for, not by assuming you already know their problems. This means interviews, observation, and a handful of core research methods, or sometimes just sitting with users while they attempt a task and watching where they get stuck.
The goal isn't to collect opinions. It's to notice patterns in behavior that users themselves might not be able to articulate.
2. Define
Once you have research, you synthesize it into a clear problem statement. This is where a pile of interview notes turns into a specific, actionable challenge, often framed as "How might we help [user] achieve [goal] despite [constraint]?"
A weak define phase leads teams to solve the wrong problem well. A strong one keeps everyone downstream aligned.
3. Ideate
This is the divergent phase. Teams generate as many possible solutions as they can before narrowing down. Quantity matters more than polish here, since the best ideas rarely show up first.
Good ideation sessions defer judgment, build on other people's ideas instead of competing with them, and stay anchored to the problem statement from the define phase.
4. Prototype
Ideas get built into something tangible, even if it's just a paper sketch, a clickable wireframe, or a rough interaction flow.The point of a prototype is to learn, not to impress.
Low-fidelity prototypes are often more useful early on because they're fast to change and don't create false confidence in a direction that hasn't been tested yet.
5. Test
Prototypes go directly through usability testing. You watch what happens, gather feedback, and figure out what to keep, cut, or rework. Testing frequently sends teams back to Empathize or Define with sharper questions than they started with.
This is the step teams most often skip under deadline pressure, and it's usually the one that would have caught the biggest problems.
Design Thinking Models Beyond the 5 Stages
The 5-stage model is the most commonly taught version, but it's one convention among several. Knowing the others helps you recognize the same underlying pattern across different vocabularies.
The Double Diamond. Formalized by the UK's Design Council in 2005, this model breaks the work into four phases: Discover, Define, Develop, and Deliver. It groups the same divergent-convergent thinking into two diamonds, one for understanding the problem and one for building the solution.
IDEO's 3 I's. Inspire, Ideate, Implement. A simpler three-part lens used when a full 5-stage breakdown feels too granular for a client conversation.
The 6-stage variant. Some practitioners add a sixth phase, Implement, after Test, to make the step from validated prototype to a shipped product explicit rather than assumed.
Different labels, same DNA: understand the problem deeply, diverge before you converge, and keep testing until reality agrees with you.
There's also a compressed version worth knowing: Google Ventures' 5-Day Design Sprint (Unpack, Sketch, Decide, Prototype, Test), created by Jake Knapp. It squeezes the same empathize-to-test arc into a single week for teams that need a fast answer rather than a multi-week research cycle. It's a format, not a replacement for the deeper process.
How This Compares to Agile, Lean UX, and UCD
Teams often use these terms interchangeably, alongside other UX design methodologies, which causes real confusion in planning conversations.
Vs. Agile. Agile is about how you build once direction is set: short cycles, working software, regular check-ins. This process is about how you find that direction in the first place. They are not competing, most mature teams run this upstream of an agile sprint cadence.
Vs. Lean UX. Lean UX borrows heavily from this methodology's testing discipline but focuses more tightly on validating specific product hypotheses inside a build-measure-learn loop.
Vs. user-centered design (UCD). UCD is the broader philosophy that users should shape decisions at every stage. This process is an implementation framework for UCD, one of several UX disciplines, not a separate competing idea.
The short version: frame the right problem here, connect it to your wider UX strategy, build it in agile sprints, and keep both grounded in real user contact throughout.
Why This Matters for Design Teams
A lot of design is execution without structure or a clear design strategy behind it. Teams jump from a stakeholder request straight to high-fidelity mockups, skipping the research and testing that would have caught problems early.
The financial case isn't just theoretical. A 2018 McKinsey study found that top-quartile design performers grew revenue 32 percentage points faster than their industry peers over a five-year period, tracked through the McKinsey Design Index.
Working this way changes a few things in practice:
It reduces the number of expensive late-stage redesigns, since problems surface in cheap prototypes instead of finished builds.
It gives designers a defensible answer to "why did you make this choice" that isn't just aesthetic preference.
It keeps the team anchored to actual user behavior instead of internal assumptions about what users want.
It creates a shared process that developers, PMs, and designers can all follow, even if they weren't trained as designers.
None of this replaces the need for craft or the core principles of design. It just makes sure that craft is aimed at the right problem.
Core Principles Every Design Thinker Should Know
The five phases are the process. These are the mindsets that make the process work and underpin solid digital product design.
Human-centered, always. Every decision traces back to a real user need, not an internal opinion about what looks good.
Bias toward action. Build something rough and test it rather than debating in a conference room for weeks.
Embrace ambiguity. The right problem isn't always obvious at the start, and that's expected, not a failure.
Collaborate across disciplines. The best insights often come from people outside the design team entirely.
Fail fast, cheaply. A failed prototype costs a few hours. A failed launch costs a lot more.
Design Thinking Examples in Real Products
Theory is easier to grasp with real cases attached to it.
Gini
When we redesigned Gini, a health platform combining DNA insights with AI-powered food logging, the empathize phase surfaced something unexpected: users didn't struggle with logging food, they struggled with trusting recommendations that felt generic. That insight reframed the entire define phase, and the resulting prototypes focused on making recommendations feel personalized rather than just adding more logging features.
Barista
With Barista, a PR-first AI platform, testing early prototypes with actual PR teams revealed that the biggest friction wasn't the AI itself, it was how much the interface still felt like a generic dashboard instead of a collaborative teammate. That single testing round reshaped the interaction model before a single line of production code was written.
Airbnb
Outside of our own work, Airbnb's early recovery is a well-documented case. The founders personally visited hosts, photographed listings, and observed exactly where trust broke down for guests. That direct empathy work, not a marketing campaign, is often cited as the turning point that saved the company.
GE Healthcare
GE Healthcare's MRI redesign is another widely cited case. Engineer Doug Dietz noticed how frightened children were before scans and traced the real problem to the experience, not the machine. His team empathized with pediatric patients directly, visiting daycare centers and consulting child life specialists, then rebuilt the scanning room into a themed adventure. Reported outcomes included far less need for sedation and noticeably calmer patients, a case now used across healthcare design training.
Tools Designers Use in the Design Thinking Process
The process doesn't require expensive software, though the right tools speed it up considerably.
Empathize: user interview guides, empathy maps, journey maps, storyboards
Define: affinity diagrams, problem statements, persona documents
Ideate: Figma or FigJam boards, Miro, whiteboard sketching, the 6-3-5 method
Prototype: Figma, paper prototyping, clickable wireframes
Test: usability testing platforms like Maze or UserTesting, moderated interviews, or a heuristic evaluation for expert review
Most teams don't need all of these at once. The right tool depends on which phase is slowing you down.
How to Learn the Design Thinking Process
If you want to build this skill properly rather than picking it up piecemeal, a few paths work well.
Take a structured design thinking course. Programs from IDEO U, Stanford d.school, and Coursera walk through the process with real project work, not just theory.
Read a foundational design thinking book. "Change by Design" by Tim Brown and "The Design of Everyday Things" by Don Norman are the two most commonly recommended starting points.
Practice on a real problem, not a hypothetical one. The process only really clicks once you've run through empathize-to-test on something with actual stakes.
Study a design thinking model or framework diagram until you can sketch it from memory. This forces you to internalize the sequence instead of just recognizing it.
Shadow a design thinking project inside your own company, even in a junior or observer capacity, before running one solo.
Reading about the process only gets you halfway. The rest comes from doing it under real constraints.
Common Mistakes in the Design Thinking Process
A few patterns cause this process to fail even when teams know the steps by heart.
Skipping empathize and going straight to solutions. This is the most common failure, and it defeats the entire point of the methodology.
Treating it as a one-time workshop instead of an ongoing habit. A single two-day sprint doesn't replace continuous user contact.
Confusing a lot of ideas with good ideas. Ideation without a strong define phase just produces noise.
Testing too late, when a redesign is expensive. The cheapest time to catch a bad idea is at the prototype stage, not after launch.
Applying it rigidly as seven fixed steps instead of treating it as a flexible loop you can revisit.
Where the Criticisms Are Fair
Not every take on this process is positive, and some of the pushback is worth taking seriously. Design consultant Natasha Jen's widely shared talk, bluntly titled "Design Thinking is Bullshit," argues that it often gets reduced to sticky notes and workshop theater with no real rigor behind it. Harvard Business Review and MIT have raised similar concerns: teams run the steps as a checklist without building the judgment the process is supposed to develop.
We think the criticism lands when the process becomes a template instead of a discipline. Running an empathize workshop once a quarter isn't the same as staying in continuous contact with users. The method works when it's a habit a team actually practices, not a two-day offsite people talk about afterward.
Design Thinking in an AI-Heavy Workflow
AI has made generation cheap. Tools can produce dozens of layout variations, copy options, or code scaffolds in seconds. That actually raises the value of the empathize and define phases, since the bottleneck is no longer producing options, it's knowing which problem is worth solving and judging which output actually fits a real user's need. Teams that skip straight to generation without doing that groundwork end up with a lot of polished output solving the wrong thing.
Conclusion
This methodology is not a buzzword or a slide template. It is a working method for making better decisions faster, with less guesswork.
It centers on five phases: Empathize, Define, Ideate, Prototype, and Test.
It works because it forces contact with real users before resources get committed to a direction.
It fails when teams treat it as a one-off workshop instead of a repeatable habit.
The tools matter less than the discipline of actually running each phase, especially testing.
Teams that skip the research and testing steps usually pay for it later, in redesign costs or in users who quietly churn.
We build this process into how we approach every project at Groto, from the first user interview to the final prototype test. If your team is stuck between a business goal and a product that doesn't quite work for users, we're happy to talk it through. Book a call with us.
