How the design thinking process reveals what users really want

You've been there before.

Users tell you what they want. It sounds clear. You get to work.

Later, you find out the problem was never what they described. They were pointing at a symptom. The real issue was somewhere else entirely.

You should never trust what people say before you watch what they do.

That's what a good design thinking process protects you from.

It's a way of questioning your assumptions until the actual problem comes into focus.

In this article I walk you through the classic phases of the UX Design thinking process, explaining what each one is meant to reveal.

If you want structured practice with feedback as you learn, Zero to Pro is built for this kind of skill building.

Why designers keep building bad products

Most mistakes don't start with bad UI.

They start with a confident story about users that nobody checked against behavior.

Surveys capture what people believe they'll do.

Workshops capture what sounds reasonable in the room.

Feature requests capture the fix someone imagined, not the job they're trying to finish.

Recent research on stated and revealed preferences shows the same pattern across products. People describe the version of themselves they want to be, not the version that shows up under time pressure, unclear labels, or a screen they've never used before.

The fix is a process that treats every early claim as a guess until a later phase proves or kills it.

For method selection without overload, read UX Research methods that inform better design decisions.

The five phases and what each one reveals

UX Design thinking is taught as five phases: Empathize, Define, Ideate, Prototype, and Test.

Treat each phase as one reveal step.

Empathize: What do people actually do?

What happens in real use, not what people say they'll do?

Talk to users. Watch sessions if you can. Note workarounds, pauses, and the words people use when they're stuck.

You're done when you can describe a repeated behavior in plain language, backed by more than one source.

For example, during interviews, six people might say they want "better filters", but in session recordings, most never open the filter panel. They use search and scroll.

The stated want and the revealed behavior don't match yet. That's useful. It's a signal to keep digging.

Define: What problem is worth solving?

What job is the user hiring this product to do?

Turn observations into one clear problem statement. Write it the way a user would recognize it. Cut feature language that slipped in from a request list.

You're done when you can explain the problem in one sentence and name what success looks like.

For example, stakeholders might say users want "faster reports," but your research notes show the same people rebuilding tables elsewhere every week because they never found export.

That's the same product area with a different problem. You need a different design response.

Ideate: Are we solving the real problem or the loud request?

Which ideas address the defined problem, and which only decorate the original ask?

Generate options. Include boring fixes, not just new features. Compare against the problem statement from Define, not against what sounded exciting in a brainstorm.

You're done when you can say why the chosen direction fits the evidence.

For example, the loud request might be an AI summary block, but the defined problem was findability. The idea that fits the evidence might be a clearer export path and a renamed menu item, not a new panel.

That's why you score against the problem from Define, not against what sounded exciting in the room.

Prototype: What breaks when someone tries it?

Where does the flow fail before you spend build time?

Build a prototype and keep it rough enough that feedback targets behavior, not color choices.

You're done when a stranger can attempt the core task without you explaining every step.

For example, you might add a prominent "Export" button, but in early testing people still miss it because it sits below a long preview they think is the whole page.

The prototype revealed layout hierarchy, not button color. That's the kind of friction you want before build time.

For how rough work earns proof before polish, see wireframing and prototyping: where good products start taking shape.

Test: Does behavior match the story you told?

Did users complete the job, and what did they do that nobody predicted?

Run task-based sessions. Watch where people hesitate, backtrack, or invent workarounds. Update Define if the evidence changed.

You're done when critical tasks pass your pre-written success criteria, or you have a written reason to loop back.

For example, after you fix export placement, eight of eight participants might export within two minutes, but two still ask where to change date range.

That's a new Define input, not a failure of the test. Good testing updates the story.

From request to revealed need

Picture a generic work app.

Your survey data might show that users want "smarter reporting."

Empathize: You review five interview transcripts. People describe reporting pain in different words, but four mention rebuilding the same table after export failed.

Define: You write: "Managers can't get the weekly table out of the app without reformatting it elsewhere."

Ideate: You list six options, including an AI summary, a saved view, a clearer export path, and better defaults. You score them against the defined problem, not the survey headline.

Prototype: You mock two flows: one with a new summary panel, one with export moved to the top of the view and a plain label tested with five users.

Test: Summary sounds impressive in demos. Export-first wins on task time and confidence. The revealed need was exit path clarity, not more intelligence on the page.

The AI feature might still ship later. It wasn't the first truth the process uncovered.

When you need a linear map of where this sits in a full UX cycle, read the UX Design process: every step from discovery to launch.

How to use AI for design thinking without skipping proof

AI fits when it speeds work you still verify with real users. It fails when it replaces the reveal steps.

Use AI across all five phases. Keep hard limits at each one.

Empathize with AI

Start with open questions, not a finished brief.

AI can turn those into interview guides, then transcribe and tag what people actually say. Once sessions pile up, it clusters quotes by theme and flags when someone told you one thing in an interview and something different when you watch them use the product.

That speed only matters if you're still in the room.

You choose who to talk to, how to recruit them, and what follow-up to ask. You decide which behaviors outweigh the loudest complaints.

A persona built from evidence can summarize what you learned. It can't stand in for a session you never ran.

Define with AI

By the time you sit down to Define, you have notes, tags, and a few patterns that keep showing up.

AI can stress-test your problem statement for vague words, spot when a problem is really a solution in disguise, and draft success criteria you can measure later.

You still write the final problem sentence. You still draw the line on what's in scope and what waits. When a stakeholder's ask doesn't match the evidence from Empathize, you're the one who says so plainly.

Ideate with AI

With a clear problem on the page, Ideate is where ideas multiply fast.

AI can run a first burst against your written brief, group options by how they address the defined problem, and document trade-offs so nothing gets lost after the workshop ends.

The filter stays with you.

You kill ideas that only match the original survey ask. You choose what gets prototyped.

When designers brainstorm together, you're still the one keeping the work focused on the problem, not the novelty.

Prototype with AI

Prototype is where rough work earns honest feedback.

AI can generate wireframe variants within written constraints, draft label and empty-state copy, and build quick clickable flows for internal review before anyone writes production code.

Keep fidelity low enough that feedback targets behavior.

Match every prototype to the problem from Define. If structure isn't testable yet, resist the pull to polish.

Test with AI

Test closes the loop.

AI can draft scripts tied to real tasks, summarize session notes by where people failed, and flag accessibility issues in static mocks before live sessions begin.

You design the tasks so they reflect real jobs. You make the severity calls on what blocks release. When behavior breaks the story you told in Define, you're the one who loops back and updates it.

For a week-by-week loop with stop rules at each stage, read how to use AI in design: real process without skipping user research.

Action checklist

• Write what users said they want before you research. You'll compare it to what you find later.
• In Empathize, log behaviors and workarounds.
• In Define, rewrite requests as problem statements a user would recognize.
• In Ideate, score ideas against the defined problem, not the loudest ask.
• In Prototype, test the core task before visual polish.
• In Test, note surprises and send them back to Define.
• Attach one piece of evidence to every priority before you change the design file.
• Use AI for drafts and clustering. Don't skip sessions because the summary reads well.

FAQs

What is the design thinking process?

It's a five-phase approach to solving problems with users at the center: Empathize, Define, Ideate, Prototype, and Test. Each phase is meant to reduce wrong assumptions before you invest in the next step.

What is UX Design thinking?

It applies that same process to digital products. The goal is to learn what users need through research, clear problem framing, rough solutions, and observed behavior, not through internal debate alone.

How does the design thinking process reveal what users really want?

It separates what users say from what they do. Early phases gather and frame evidence. Later phases expose gaps when people try a real flow. The reveal happens when behavior proves or disproves the story you started with.

What's the difference between what users say and what users do?

What users say is often an ideal version of themselves or a quick fix they imagined. What users do shows up under real labels, time pressure, and unfamiliar screens. Design thinking uses both, but it trusts behavior more when they conflict.

How long should each phase take?

There's no fixed calendar. Move on when the phase's reveal question has an answer you can point to. A solo designer might Empathize in three days or two weeks. You shouldn't skip Test because the UI looks finished.

Can I skip straight to prototype if I already know the problem?

Only if you have recent evidence tied to the exact flow you're building. Otherwise you risk prototyping the wrong problem faster. Most designers who skip Empathize or Define rebuild later.

How does design thinking in software and AI projects differ?

The phases stay the same. The stakes change. AI features add trust, clarity, and recovery paths users rarely name in surveys but reveal quickly in tests.

How do I use AI for design thinking without bad data?

Use AI after real input exists: Transcripts, tickets, test notes. Let it cluster, draft, and stress-test language. Don't use synthetic users as proof. Loop back to Define when live tests contradict the model's summary.

How is this different from the product design process?

Design thinking focuses on uncovering the right problem and testing ideas with users. A full product design process adds direction gates, ship criteria, and post-launch learning. They work together. For gate-based shipping, read the product design process: a designer's roadmap to building great products.

Where should I start if I've only used design thinking in theory?

Run one small cycle on a single task in a product you can access. One research round, one problem statement, one rough prototype, five test sessions. Document what changed between what users said and what they did.

Final takeaway

The design thinking process is how designers stop shipping confident guesses.

Each phase has one job.

Empathize shows behavior, Define names the real problem, Ideate checks whether ideas match that problem, Prototype exposes friction, and Test confirms with action.

When those reveals line up, you build what users actually need.

If you're ready to prove the full loop on a live product, including where AI fits without replacing user proof, AI Design Sprint is the next step.