Fall in love with the problem, not the first solution. End with what to learn next, not just ideas.
When to use
- A product, service or UX problem where the real user need is unclear.
- "How might we" framing, discovery sprints, concept validation before building.
- Reframing a request using what users actually do or say.
Skip: the spec is fully frozen and no discovery is wanted, or the task is code-only maintenance with no user problem to frame.
Before you start
- State in one block: Design challenge (who is affected, in what situation) and Pass (Empathize, Define, Ideate, Prototype, Test plan).
- Gather first. Read tickets, interview notes, support threads, analytics or the product itself before writing Empathize. Ask up to 3 questions only for users, constraints or success signals that tools cannot answer.
- Light path. Small ask: 1-2 lines per stage, 3 ideas, one prototype, 2 signals.
- If Empathize has no real user input, say so in Define and keep the POV narrow. Never invent research.
Stages
1. Empathize
- Who: primary user or stakeholder. Mark facts from the user versus
[INFERRED]. - Jobs, pains, gains: what they are trying to do and what hurts.
- Context: when and where the need shows up.
No fabricated quotes. Paraphrase only what the user supplied.
2. Define
- Insight: a non-obvious tension connecting pains and context.
- POV: "[User] needs [verb] because [insight]."
- How Might We: 2-3 well-scoped questions opened by the POV.
3. Ideate
Quantity and variety, using each HMW as a prompt. Tag each idea desirable, feasible or viable as a hypothesis, not a fact. Default 8-10 ideas unless the user sets a number.
4. Prototype
Describe low-fidelity artifacts: paper flow, roleplay script, landing-page smoke test, clickable sketch. For each: Purpose: the question it answers. Fidelity: one line placing it between sketch-only and interactive.
5. Test plan
- Learning goals: what would convince you the idea is wrong?
- Participants: who and how many, or "to be decided".
- Signals: behaviors or metrics to observe, stated so they can fail.
- Next iteration: what changes if results are mixed.
Pitfalls
- A POV that restates the solution ("users need a dashboard").
- HMW questions that are too broad ("improve the experience") or too narrow (they hide the solution).
- Treating desirable / feasible / viable tags as proven.
- A Test plan with no signal that could show the idea is wrong.
Worked example: references/example.md.
Checklist
- Challenge and Pass stated
- Empathize separates facts from
[INFERRED] - POV and HMW before Ideate
- Ideas tagged desirable, feasible or viable as hypotheses
- Prototype gives purpose and a fidelity line
- Test plan has learning goals and falsifiable signals