PM Gym

Design Thinking Process

A human-centered recipe for solving the right problem creatively

Design thinking is a five-stage, human-centered process for tackling fuzzy problems: understand people deeply, frame the real problem, generate many ideas, build something cheap to react to, and learn from real users — looping back as you go.

Step-by-step lessons

The Five Stages

One short lesson per stage. The process is iterative — you loop back constantly, not march straight through.

1

Empathize

Stage one: understand the people you're designing for, deeply and without assumptions. You're gathering real human context, not opinions about it.

Everyday example — the good friend vs. the fixer

Imagine a friend who, the moment you mention a problem, jumps in with "just do X!" before you've even finished. Compare them to the friend who actually listens, asks "what's that like for you?", and understands before advising. Empathize is being the second friend. You watch and listen to real users until you genuinely feel their problem — because a solution built on a guess about people is a solution built on sand.

Set your assumptions aside

Watch people in their real setting, ask open questions, and listen for the feelings and struggles beneath what they say. The goal is to see the problem through their eyes, not yours.

You can't solve a problem you don't genuinely understand — so empathy comes first, before any idea.

Quick check

In the Empathize stage, which activity fits best?

2

Define

Stage two: synthesize everything you learned into a single, sharp problem statement. A fuzzy problem produces fuzzy solutions.

Everyday example — the doctor's diagnosis

A patient walks in saying "I just feel awful." That's too vague to treat. A good doctor narrows it to a precise diagnosis — "an iron deficiency causing your fatigue" — and suddenly the treatment is obvious. Define does the same for a product problem: it turns a vague "users are frustrated" into a sharp statement everyone can aim at. The "How Might We…" phrasing keeps it a question (so ideas can flow) rather than jumping straight to one cure.

From findings to a point of view

Turn raw observations into a clear point-of-view: [user] needs [need] because [insight]. Then reframe it as a "How Might We…" question that opens up solutions.

"How might we help a rushed parent get a healthy dinner on the table with zero planning?" — specific enough to act on, open enough to invite many ideas.

Quick check

Which is a well-formed Define output (a "How Might We" question)?

3

Ideate

Stage three: generate a wide range of possible solutions. Quantity first, judgment later — the goal is options, not the one perfect answer yet.

Everyday example — planning a group trip

When friends plan a holiday, the fun version goes: everyone shouts out destinations — beach, mountains, a road trip, Tokyo, camping — and someone writes them all down, no shooting anything down yet. Only after the wild list exists do you weigh cost and dates and pick. If one person kills every idea as it's said ("too expensive," "too far"), nobody suggests anything and you end up back at the same boring place. That's Ideate: get every option out first, judge later.

Diverge before you converge

Push for many ideas, including wild ones. Defer judgment — criticism kills the half-formed idea that could have led somewhere. Build on others' ideas ("yes, and…").

You first diverge (open up lots of options), then converge (narrow to the few worth prototyping).

Quick check

Someone in an ideation session says "that idea is silly, it'll never work" after each suggestion. Why is this a problem?

4

Prototype

Stage four: turn promising ideas into something cheap and tangible that people can react to. A prototype is a question, not a product.

Everyday example — the movie storyboard

Before a film studio spends millions shooting, artists draw the movie as rough sketches — a storyboard — so they can see if the story works for almost no money. If a scene falls flat, they redraw it; nobody's precious about a pencil sketch. A product prototype is that storyboard: a paper sketch or clickable mockup that lets people react to the idea before you build the expensive real thing. Keep it rough on purpose — the fancier it looks, the more attached you get and the less honestly you'll hear "this doesn't work."

Cheap, fast, disposable

A paper sketch, a clickable mockup, a role-play — whatever is fastest to build and fastest to throw away. The point is to learn, not to polish.

The more you spend on a prototype, the more attached you get and the less honestly you hear the feedback. Keep it rough.

Quick check

Your team wants to test a new booking flow. Which is the best prototype for a first learning cycle?

5

Test

Stage five: put the prototype in front of real users, watch what happens, and learn. Testing feeds straight back into the earlier stages.

Everyday example — the chef's taste test

A good chef doesn't cook one giant batch and serve 200 guests untasted. They taste as they go, hand a spoonful to a colleague, watch the reaction, and adjust the salt. Testing is that spoonful: you watch a few real users try the prototype and notice where they wince. And crucially — if the whole dish is wrong, you don't just tweak the garnish; you go back and rethink the recipe. That's the loop: a bad test sends you back to Define or Empathize, not just to a small fix.

The loop, not the finish line

Observe users with the prototype, note where they struggle and what surprises you, then loop back: refine the prototype, re-frame the problem, or even return to empathy if you got the user wrong.

Design thinking is iterative. Test isn't the end — it's what sends you round again, smarter each time.

Quick check

During testing, users keep misunderstanding the core concept — not just small UI details. What's the right response?

Review the concepts

Design Thinking Flashcards

6 cards covering the essentials. Click a card to flip it.

Overview Card 1 of 6

Design Thinking

Click to flip

Tip: say the answer out loud before flipping.

Explanation

In practice

1 / 6
Apply what you learned

Practice Scenarios

15 situations that test whether you can spot the right stage, avoid the classic traps, and keep the loop alive. Choose the strongest move, then read why the others miss.

Scenario 1

A stakeholder walks in and says: "Let's build a chatbot." No one has talked to users about their actual problem yet.

Where should a design-thinking team start?

Scenario 2

In an ideation session, the group latches onto the first decent idea after five minutes and starts planning it in detail.

What's the design-thinking concern?

Scenario 3

Your team spent three weeks building a polished, near-final prototype. In testing, users clearly don't understand it — but the team resists changing anything.

What went wrong, in design-thinking terms?

Scenario 4

During user interviews, a PM keeps asking: "Wouldn't you love a feature that does X? You'd use that, right?" Users nod along.

What's wrong with this Empathize technique?

Scenario 5

A team writes its problem statement as: "Users need our new AI dashboard because dashboards are the future."

Why is this a poor Define output?

Scenario 6

Ideation has produced 40 ideas on the wall. The room falls silent — nobody knows what to do next.

What stage-transition is needed?

Scenario 7

Engineering wants a fully functional, backend-connected prototype before showing anything to users, "so the test is realistic."

What's the design-thinking counter-argument?

Scenario 8

In testing, a user struggles with the prototype. The PM immediately jumps in to explain how it's "supposed" to work, and the user then says "oh, that makes sense."

What did the PM do wrong?

Scenario 9

A leader insists the five stages must be done strictly in order, once each, like a checklist — Empathize, then Define, then Ideate, then Prototype, then Test, then done.

What misunderstanding is this?

Scenario 10

Your team is designing a tool for warehouse workers but has only interviewed office managers who supervise them, never the workers themselves.

What's the Empathize flaw?

Scenario 11

A "How Might We" question is phrased: "How might we increase quarterly revenue by 20%?"

Why doesn't this work as a design-thinking HMW?

Scenario 12

Testing five prototypes with users reveals that the whole underlying assumption — that people want to plan meals a week ahead — is wrong. Most decide dinner an hour before.

What's the right loop-back?

Scenario 13

During ideation, the quietest team member sketches a strange, seemingly impractical idea. The group chuckles and moves on.

What does good ideation practice say?

Scenario 14

A PM says: "We already know our users perfectly, so let's skip Empathize and jump straight to Ideate."

What's the risk of skipping Empathize?

Scenario 15

Your prototype tests well with users, but a developer points out it would take two years and a full rewrite to build for real.

How does design thinking handle this tension?

Lock it in

Guess the Term

Read the clues and name the concept. The fewer clues you need, the more points you score.

Round 1 Score 0
Keep it handy

Design Thinking Quick Reference

The whole topic on one screen.

The Five Stages

Human-centered and iterative — loop back constantly.

1

Empathize

Understand real people, assumptions aside.

2

Define

Frame one sharp problem — a "How Might We".

3

Ideate

Diverge — many ideas, judgment deferred.

4

Prototype

Cheap, tangible, disposable.

5

Test

Learn from real users, then loop back.

Principles to Remember

Human-centered

Start from real people's needs, not solutions.

Diverge, then converge

Open up options before narrowing down.

Iterate

Test isn't the end — it loops you back, smarter.

Stay cheap

Rough prototypes keep you honest and open to feedback.

A Method Per Stage

One go-to technique for each stage.

1

Empathize

Non-leading interviews & observation. Ask about real past behavior.

2

Define

Point-of-view statement: [user] needs [need] because [insight].

3

Ideate

Brainstorm to diverge; dot-vote or impact/effort to converge.

4

Prototype

Paper sketch or clickable mockup — cheapest thing that asks the question.

5

Test

Watch ~5 users, stay silent, note the struggles.

Classic Traps

The mistakes beginners make most.

Skipping empathy

"We already know our users" — ideating on stale assumptions.

Leading questions

"You'd love this, right?" gathers polite agreement, not truth.

Converging too early

Grabbing the first decent idea before diverging.

Over-polishing prototypes

Investment breeds attachment and deafness to feedback.

Rescuing users in tests

Explaining away confusion erases the finding.

Notification