Design Thinking

fall in love with the problem, not the first solution. end with what to learn next, not just ideas.

intent

use this skill when you need to explore a problem through a human-centered lens before jumping to solutions. design thinking works when you have a fuzzy challenge, real or inferred user needs, and permission to question your assumptions. run the five-stage process (empathize, define, ideate, prototype, test plan) in order. skip this skill if the spec is locked, no discovery is wanted, or the work is pure maintenance with zero user problem framing.

inputs

required context:

• design challenge: who is affected and in what situation (one sentence minimum)
• user or stakeholder facts: names, roles, current behaviors, known pain points (can be partial or inferred; flag inferred data as [INFERRED])
• any constraints: budget, timeline, technical limits, organizational policy

optional external inputs:

• existing user research, interviews, or feedback (paste or summarize)
• competitive landscape or analogous products
• success metrics or business goals
• stakeholder assumptions to stress-test

edge cases to note:

• if user data is missing entirely, ask up to 3 clarifying questions in one message, then proceed with stated gaps
• if empathize section has no real user input, acknowledge thinness in define and narrow the POV accordingly
• if ideation is constrained to a single solution, backtrack to widen the ideate stage

procedure

1. setup: state the design challenge and confirm the default pass

   • input: user's raw problem statement
   • output: one-sentence challenge statement + confirmation that you will run empathize → define → ideate → prototype → test plan (in that order)
   • flag any missing context (users, constraints, success signals); ask clarifying questions if needed

2. empathize: surface the primary user or stakeholder, their jobs, pains, gains, and context

   • input: user facts, research, feedback, observations
   • output: explicit section with "who" (fact vs [INFERRED]), "jobs/pains/gains" (what they do, what hurts, what they gain), and "context" (when/where the need surfaces)
   • rule: paraphrase only what the user supplied; do not fabricate quotes or invent research

3. define: extract insight, write the POV, and pose 2, 3 HMW questions

   • input: empathize output
   • output: insight statement (non-obvious tension connecting pains and context), point of view statement using the form "[user] needs [verb] because [insight]", and 2, 3 well-scoped how-might-we questions opened by the POV
   • rule: reflect what empathize actually contains; do not invent field research or broaden the scope if data is thin

4. ideate: generate a substantive list of ideas tagged by hypothesis type

   • input: HMW questions from define
   • output: list of 5+ ideas (or user-specified count) each tagged desirable (user wants it), feasible (can build it), and/or viable (makes money or solves the business problem); treat tags as hypotheses, not proven facts
   • rule: do not collapse into a single solution; aim for quantity and variety

5. prototype: describe low-fidelity artifacts and their purpose

   • input: top 1, 3 ideas from ideate
   • output: for each artifact, state its purpose (what question does this answer?), describe it (paper flow, roleplay script, landing page mock, clickable wireframe), and add a one-line fidelity note placing it on the sketch-only to interactive spectrum (do not use "low/medium/high" labels)
   • rule: artifacts must be testable; vague concepts do not count

6. test plan: define learning goals, participants, signals, and next iteration logic

   • input: prototypes
   • output: learning goals (what would prove the idea wrong?), participant sample or [TBD], behavioral or metric signals to observe, and a decision rule for next iteration (e.g., "if conversion drops below X%, pivot to idea 2")
   • rule: signals must be falsifiable; "does it feel right?" is not a signal

decision points

• if empathize data is thin or entirely inferred: state this plainly in define and narrow the POV scope to match what you know, rather than inventing research or broadening claims
• if the user skips empathize and jumps to ideate: redirect; ask 3 clarifying questions about the user, then do empathize before ideating
• if the spec is fully frozen or no discovery is wanted: acknowledge the request, but note that design thinking is not the right skill; suggest moving to execution or technical spec refinement instead
• if ideation collapses into a single idea: pause and re-run ideate with explicit HMW prompts to generate variety before moving to prototype
• if test plan signals are vague: rewrite them as observable behaviors or metrics (e.g., "time to understand the value prop" instead of "does it feel intuitive?")
• if user reports mixed or negative test results: use the decision rule from test plan to pivot to the next idea or iterate the prototype

output contract

deliver five clearly headed sections in this order: empathize, define, ideate, prototype, test plan. each section includes:

• empathize: who (fact vs inferred), jobs/pains/gains, context
• define: insight statement, POV, 2, 3 HMW questions
• ideate: 5+ tagged ideas (desirable/feasible/viable per idea)
• prototype: 1, 3 artifacts, each with purpose + one-line fidelity note
• test plan: learning goals, participant sample, observable signals, next iteration rule

all inferred data flagged with [INFERRED]. all gaps or working guesses noted in plain language. no bracket tags or jargon in the prose itself, only in metadata fields (who, tags, etc.).

outcome signal

you know the skill worked when:

• each section is grounded in either user facts or explicit inferences, not invention
• the POV statement is tight and defensible (not a vague mission statement)
• ideate generates 5+ distinct options before collapsing to one
• each prototype has a clear purpose and a testable fidelity level
• the test plan includes falsifiable signals that would prove the idea wrong
• you move from empathize to test plan in one coherent thread, with no backtracking to redo empathize mid-stream (unless test results force a pivot)