The design thinking process is a way of solving problems by starting with the people who have the problem, not with the solution you already like. Instead of building what seems obvious and hoping someone uses it, you understand real users first, define the actual problem, explore options, test cheap versions, and only then commit.
It sounds simple, and it is, but most teams still skip it. This guide walks through the five stages, why the process loops instead of running in a straight line, and how it plays out in real product work, including how we run it for clients at Quadiz.
What Is the Design Thinking Process
Design thinking is a problem-solving method built around one idea: understand the humans before designing anything for them. The most widely taught version comes from the Hasso Plattner Institute of Design at Stanford, better known as the d.school, and it breaks the work into five stages: Empathize, Define, Ideate, Prototype, and Test. If you want the canonical breakdown later, the Interaction Design Foundation has a thorough one. Here, we'll focus on what each stage actually feels like in practice.
Two things make it different from a normal project plan. First, it starts further back than most teams do. Before features, before screens, it asks what people actually struggle with and why. Second, it's not a straight line. You move through the stages, learn something that breaks an assumption, and loop back. That looping isn't a flaw in the process. It's the process.
The best way to think about it: every stage is built to catch you being wrong while it's still cheap to be wrong. Research catches you assuming you know what users need. A sharp problem statement catches you solving the wrong thing. Rough prototypes catch you falling in love with an idea that falls apart the moment a real person touches it.
The Five Stages of the Design Thinking Process
The stages are famous, but descriptions of them often float in the abstract. Here's what actually happens in each one.
Empathize. Learn about the people you're designing for before forming any opinions about the solution. Interviews, observations, support tickets, session recordings, whatever gets you close to real behavior. The goal isn't data for a deck. It's understanding what frustrates people, what they ignore, and where the current way of doing things breaks down.
Define. Turn everything you heard into one clear, human-centered problem statement. Not "we need a dashboard" but something closer to "small clinic managers lose two hours a day scheduling appointments over the phone." A good problem statement is specific, grounded in observed behavior, and doesn't smuggle in a solution.
Ideate. Generate a wide range of possible answers to that problem statement. Quantity first, judgment later. The point isn't that idea number thirty-seven will ship. It's that exploring thirty-seven options loosens the grip of the obvious one, and sometimes the obvious one only looks obvious until you've compared it.
Prototype. Build rough, cheap versions of the strongest ideas. Paper sketches, clickable wireframes, fake landing pages. A prototype should be disposable. If it's too polished, people stop critiquing the idea and start critiquing the pixels, which defeats the purpose.
Test. Put the prototype in front of real people and watch what happens. Where do they hesitate? What do they misunderstand? What do they ignore completely? Testing isn't about proving your design works. It's about finding out where it doesn't, early, while changes still cost hours instead of months. Five honest sessions with real users routinely beat fifty internal opinions, because internal opinions already know how the product is supposed to work.
Why It Loops Instead of Running in a Line
Diagrams show the five stages left to right, and almost everyone then assumes you run them once. In practice, the loop back is where the value lives.
A test in stage five frequently reveals that the problem in stage two was framed wrong. A prototype built in stage four makes someone realize a whole category of ideas from stage three never got explored. Every loop feels like going backwards on a Gantt chart and feels completely normal to experienced designers, because each return trip is made with better information than the last one.
The teams that struggle with design thinking are usually the ones treating it like a checklist: empathize done, define done, ship it. The teams that benefit treat each stage as a question with an answer that can change the plan. That mindset shift, more than any workshop template, is what the process actually asks of you.
Design Thinking vs Other Frameworks
You'll run into two other frameworks often, and it helps to know how they relate rather than argue which is right.
IDEO, the design firm that helped popularize the approach, describes it as three phases: Inspiration, Ideation, and Implementation. It's a looser, practice-oriented version of the same philosophy. The Double Diamond, from the British Design Council, uses four stages: Discover, Define, Develop, Deliver. Its strength is how clearly it separates exploring a problem from exploring solutions.
None of these conflict with the five-stage model. They're zoom levels on the same idea: understand first, then build, then check, then repeat. For a product team or a client engagement, the five-stage version is usually enough structure without being a religion.
Common Myths and Honest Limits
Three myths cause most of the disappointment around design thinking.
The first is that it's a creativity workshop. Brainstorms photograph well, but the heart of the process is discipline: talking to real users, defining the right problem, and killing weak ideas cheaply. A team that skips the empathy work but runs the brainstorm has done the fun part and none of the useful part.
The second is that it's linear. Covered above, worth repeating: real projects loop constantly, and a plan with no room to loop isn't running design thinking, it's running a waterfall with better branding.
The third is that it fits everything. Design thinking shines when the problem is fuzzy and the users aren't like you. It's overkill for a tiny, well-understood change, and it doesn't replace engineering rigor or business judgment. It's a way to reduce the risk of building the wrong thing. It doesn't remove the risk of building things.
How a Design Agency Runs This Process for Clients
For our clients, this is where the process stops being theory. At Quadiz, a design and development studio, the five stages are basically how any healthy product engagement runs. We start with design research and user flows rather than visual polish, turn findings into a problem definition clients can actually argue with, explore multiple directions, and prototype before anything expensive gets built. Testing with real users happens before launch, not after.
The looping matters most in client work. Early prototypes regularly send projects back to reframe the problem, and every time that happens, it's a cheaper decision than the same discovery would have been after development. Our case studies show what that looks like across SaaS platforms, websites, and mobile apps.
If you're building a product and want a team that works this way from day one, you can book a free call with us. Bring the fuzzy problem. The process handles the rest.
Tags:#Design Thinking#UX Process#Product Design
Written byFounder & Lead Developer
Nayef
Visit Website ↗Tech enthusiast, lead developer, and founder of Quadiz.
