Design Thinking Skill
A structured, iterative framework for human-centered problem solving. Use this to move from "what should we build?" to "here's why we're building this, for whom, and how we'll validate it" — before writing code.
Commands
| Command |
Stage |
What it does |
/dt |
Full |
Walk through all 5 stages for a feature, system, or product |
/dt empathize |
1 |
User research: personas, pain points, context mapping |
/dt define |
2 |
Synthesize a clear problem statement (HMW format) |
/dt ideate |
3 |
Structured brainstorm with constraint-breaking and prioritization |
/dt prototype |
4 |
Generate specs, wireframes, or code prototypes |
/dt test |
5 |
Create test plans, feedback frameworks, success metrics |
/dt audit |
Review |
Audit an existing feature/page against DT principles |
Stage 1: Empathize
Goal: Understand the real humans who will use this thing.
Process
Identify the user(s). Ask:
- Who are the primary users? (Be specific — "busy professionals learning Korean" not "users")
- What's their context? (Device, time of day, emotional state, environment)
- What are they trying to accomplish? (Job-to-be-done, not feature request)
Map pain points. For each user type, identify:
- Current frustrations (what's broken or missing today?)
- Workarounds they use (reveals unmet needs)
- Emotional friction (confusion, anxiety, boredom, overwhelm)
Build an empathy map. Output as a structured artifact:
EMPATHY MAP: [User Type]
--------------------------
THINKS: What occupies their mind? What matters to them?
FEELS: What emotions drive their behavior? What worries them?
SAYS: What do they tell others about this problem?
DOES: What actions do they take? What workarounds exist?
PAIN: Frustrations, obstacles, risks they face
GAIN: What would success look like for them?
- Contextual factors. Consider:
- Technical literacy level
- Language/cultural context (critical for multilingual projects)
- Accessibility needs
- Frequency of use (daily vs. occasional)
Output
Deliver: 1-3 empathy maps + a pain point priority list ranked by severity and frequency.
Stage 2: Define
Goal: Turn empathy insights into a crisp, actionable problem statement.
Process
Synthesize insights from Stage 1 into themes. Group related pain points.
Write a "How Might We" (HMW) statement:
How might we [action/change]
for [specific user]
so that [desired outcome]
without [key constraint to respect]?
Good example:
How might we help busy professionals maintain daily Korean practice so that they build lasting habits without requiring more than 10 minutes per session?
Bad example:
How might we make the app better? (too vague)
Define success criteria. What does "solved" look like?
- User behavior change (measurable)
- Business metric impact
- Emotional outcome ("feels confident" → measured via NPS/survey)
Scope check. Is this:
- Too broad? → Split into sub-problems
- Too narrow? → Zoom out to the real need
- Already solved elsewhere? → Study existing solutions first
Output
Deliver: HMW statement + 3-5 measurable success criteria + scope assessment.
Stage 3: Ideate
Goal: Generate diverse solutions before converging on the best approach.
Process
Diverge first. Generate 8-12 ideas without judgment. Use these prompts:
- "What if we had unlimited budget?"
- "What if the user could only use this on mobile?"
- "What would the competitor's version look like?"
- "What's the simplest possible version?"
- "What if we removed [core assumption]?"
- "How would [analogous industry] solve this?"
Challenge assumptions. List 3-5 assumptions baked into the current thinking. For each, ask: "What if this isn't true?"
Prioritize using Impact/Effort matrix:
HIGH IMPACT
|
| Quick Wins | Big Bets
| (DO FIRST) | (PLAN)
|________________|________________
| |
| Fill-ins | Money Pits
| (MAYBE) | (AVOID)
|
LOW IMPACT -----------> HIGH EFFORT
- Select 2-3 candidates to prototype. For each, note:
- Why this idea (link back to HMW)
- Key risk/assumption to validate
- Minimum viable version
Output
Deliver: Idea list + assumption challenges + prioritization matrix + 2-3 selected candidates with rationale.
Stage 4: Prototype
Goal: Make ideas tangible enough to test, with minimum effort.
Process
- Choose fidelity level based on what you're validating:
| Fidelity |
When to use |
Format |
| Low |
Validating concept/flow |
Text description, ASCII wireframe, bullet-point spec |
| Medium |
Validating layout/interaction |
Component spec with props, Figma description, HTML mockup |
| High |
Validating feasibility/performance |
Working code prototype, API stub, database schema |
For UI/UX prototypes, describe:
- Page/screen layout (what appears where)
- User flow (step-by-step interaction sequence)
- Key states (empty, loading, error, success, edge cases)
- Content hierarchy (what's most important visually)
For system/architecture prototypes, describe:
- Data flow diagram
- API contract (endpoints, request/response shapes)
- State management approach
- Integration points with existing systems
For dashboard prototypes, describe:
- What questions does this dashboard answer?
- What are the 3-5 most important metrics? (link to user goals from Stage 1)
- What actions can the user take from this view?
- What's the information hierarchy? (glanceable summary → drill-down detail)
Build constraints into the prototype:
- Must be testable in under 30 minutes
- Must reveal whether the key assumption (from Stage 3) is valid
- Must be throwaway — don't over-invest
Output
Deliver: Prototype artifact (spec, wireframe, code, or schema) + what assumption it tests + how to test it.
Stage 5: Test
Goal: Validate with real users (or realistic proxies) and decide next steps.
Process
- Define the test. For each prototype:
TEST PLAN
---------
Hypothesis: [What we believe will happen]
Method: [How we'll test — user session, A/B, analytics, survey]
Audience: [Who we're testing with — be specific]
Duration: [How long the test runs]
Success: [Quantitative threshold — e.g., "70% complete the flow in < 2 min"]
Failure: [What result means we pivot]
Identify what to observe:
- Task completion (can they do it?)
- Time on task (is it efficient?)
- Error rate (where do they get stuck?)
- Emotional response (do they feel confident/frustrated?)
- Unprompted feedback (what do they say without being asked?)
Create feedback capture framework:
- What worked? (Keep)
- What was confusing? (Fix)
- What was missing? (Add)
- What was unnecessary? (Remove)
Decision framework after testing:
| Result |
Action |
| Clear success (meets all criteria) |
Ship it, monitor metrics |
| Partial success (some criteria met) |
Iterate — return to Stage 3 or 4 |
| Clear failure (no criteria met) |
Pivot — return to Stage 2, redefine problem |
| Surprising insight |
Explore — return to Stage 1, dig deeper |
Output
Deliver: Test plan + observation checklist + decision framework + recommended next action.
Audit Mode (/dt audit)
Review an existing feature, page, or system against design thinking principles:
- User alignment — Is it clear who this is for and what problem it solves?
- Problem-solution fit — Does the solution actually address the stated problem?
- Assumption exposure — What untested assumptions are baked in?
- Feedback loops — Is there a way to know if it's working? (Analytics, user feedback)
- Iteration history — Has this been tested and refined, or shipped once and forgotten?
Output a scorecard:
DT AUDIT: [Feature/Page Name]
==============================
User Clarity: [1-5] — Do we know who this is for?
Problem Definition: [1-5] — Is the problem clearly stated?
Solution Fit: [1-5] — Does the solution match the problem?
Validation: [1-5] — Has this been tested with users?
Iteration: [1-5] — Has it been refined based on feedback?
-------------------------------
SCORE: [X/25]
TOP RECOMMENDATION: [One actionable next step]
Integration with Existing Workflow
- Before GSD phases: Run
/dt define to sharpen the problem before creating a roadmap
- Before new features: Run
/dt empathize + /dt define to validate you're solving the right problem
- Dashboard design: Run
/dt empathize to surface what metrics users actually need
- Architecture decisions: Run
/dt full to consider the human impact of technical choices
- Multilingual projects: Empathy maps should be created per-language audience (cultural context matters)
- Post-launch: Run
/dt audit on shipped features to identify iteration opportunities
Principles
- Users first, technology second. The question is never "what can we build?" — it's "what should we build?"
- Diverge before converging. Generate many ideas before picking one. Premature convergence kills innovation.
- Make it tangible. Abstract discussions waste time. Prototypes — even rough ones — accelerate decisions.
- Test assumptions, not egos. The goal of testing is to learn, not to prove you were right.
- Iterate, don't perfect. Ship, learn, improve. A shipped 80% solution teaches more than an unshipped 100% solution.
1---2name: design-thinking3description: Guide users through human-centered design thinking for product features, systems, dashboards, and architecture decisions. Use when user wants to design a new feature, rethink a user flow, plan a dashboard, architect a system from the user's perspective, or explicitly invokes /dt. Triggers on "design thinking", "user needs", "empathize", "how should we design", "what should the UX be", or /dt commands.4---56# Design Thinking Skill78A structured, iterative framework for human-centered problem solving. Use this to move from "what should we build?" to "here's why we're building this, for whom, and how we'll validate it" — before writing code.910## Commands1112| Command | Stage | What it does |13|---------|-------|-------------|14| `/dt` | Full | Walk through all 5 stages for a feature, system, or product |15| `/dt empathize` | 1 | User research: personas, pain points, context mapping |16| `/dt define` | 2 | Synthesize a clear problem statement (HMW format) |17| `/dt ideate` | 3 | Structured brainstorm with constraint-breaking and prioritization |18| `/dt prototype` | 4 | Generate specs, wireframes, or code prototypes |19| `/dt test` | 5 | Create test plans, feedback frameworks, success metrics |20| `/dt audit` | Review | Audit an existing feature/page against DT principles |2122## Stage 1: Empathize2324**Goal:** Understand the real humans who will use this thing.2526### Process27281. **Identify the user(s).** Ask:29 - Who are the primary users? (Be specific — "busy professionals learning Korean" not "users")30 - What's their context? (Device, time of day, emotional state, environment)31 - What are they trying to accomplish? (Job-to-be-done, not feature request)32332. **Map pain points.** For each user type, identify:34 - Current frustrations (what's broken or missing today?)35 - Workarounds they use (reveals unmet needs)36 - Emotional friction (confusion, anxiety, boredom, overwhelm)37383. **Build an empathy map.** Output as a structured artifact:3940```41EMPATHY MAP: [User Type]42--------------------------43THINKS: What occupies their mind? What matters to them?44FEELS: What emotions drive their behavior? What worries them?45SAYS: What do they tell others about this problem?46DOES: What actions do they take? What workarounds exist?47PAIN: Frustrations, obstacles, risks they face48GAIN: What would success look like for them?49```50514. **Contextual factors.** Consider:52 - Technical literacy level53 - Language/cultural context (critical for multilingual projects)54 - Accessibility needs55 - Frequency of use (daily vs. occasional)5657### Output58Deliver: 1-3 empathy maps + a pain point priority list ranked by severity and frequency.5960## Stage 2: Define6162**Goal:** Turn empathy insights into a crisp, actionable problem statement.6364### Process65661. **Synthesize insights** from Stage 1 into themes. Group related pain points.67682. **Write a "How Might We" (HMW) statement:**6970```71How might we [action/change]72for [specific user]73so that [desired outcome]74without [key constraint to respect]?75```7677**Good example:**78> How might we help busy professionals maintain daily Korean practice so that they build lasting habits without requiring more than 10 minutes per session?7980**Bad example:**81> How might we make the app better? (too vague)82833. **Define success criteria.** What does "solved" look like?84 - User behavior change (measurable)85 - Business metric impact86 - Emotional outcome ("feels confident" → measured via NPS/survey)87884. **Scope check.** Is this:89 - Too broad? → Split into sub-problems90 - Too narrow? → Zoom out to the real need91 - Already solved elsewhere? → Study existing solutions first9293### Output94Deliver: HMW statement + 3-5 measurable success criteria + scope assessment.9596## Stage 3: Ideate9798**Goal:** Generate diverse solutions before converging on the best approach.99100### Process1011021. **Diverge first.** Generate 8-12 ideas without judgment. Use these prompts:103 - "What if we had unlimited budget?"104 - "What if the user could only use this on mobile?"105 - "What would the competitor's version look like?"106 - "What's the simplest possible version?"107 - "What if we removed [core assumption]?"108 - "How would [analogous industry] solve this?"1091102. **Challenge assumptions.** List 3-5 assumptions baked into the current thinking. For each, ask: "What if this isn't true?"1111123. **Prioritize using Impact/Effort matrix:**113114```115HIGH IMPACT116 |117 | Quick Wins | Big Bets118 | (DO FIRST) | (PLAN)119 |________________|________________120 | |121 | Fill-ins | Money Pits122 | (MAYBE) | (AVOID)123 |124 LOW IMPACT -----------> HIGH EFFORT125```1261274. **Select 2-3 candidates** to prototype. For each, note:128 - Why this idea (link back to HMW)129 - Key risk/assumption to validate130 - Minimum viable version131132### Output133Deliver: Idea list + assumption challenges + prioritization matrix + 2-3 selected candidates with rationale.134135## Stage 4: Prototype136137**Goal:** Make ideas tangible enough to test, with minimum effort.138139### Process1401411. **Choose fidelity level** based on what you're validating:142143| Fidelity | When to use | Format |144|----------|------------|--------|145| Low | Validating concept/flow | Text description, ASCII wireframe, bullet-point spec |146| Medium | Validating layout/interaction | Component spec with props, Figma description, HTML mockup |147| High | Validating feasibility/performance | Working code prototype, API stub, database schema |1481492. **For UI/UX prototypes**, describe:150 - Page/screen layout (what appears where)151 - User flow (step-by-step interaction sequence)152 - Key states (empty, loading, error, success, edge cases)153 - Content hierarchy (what's most important visually)1541553. **For system/architecture prototypes**, describe:156 - Data flow diagram157 - API contract (endpoints, request/response shapes)158 - State management approach159 - Integration points with existing systems1601614. **For dashboard prototypes**, describe:162 - What questions does this dashboard answer?163 - What are the 3-5 most important metrics? (link to user goals from Stage 1)164 - What actions can the user take from this view?165 - What's the information hierarchy? (glanceable summary → drill-down detail)1661675. **Build constraints into the prototype:**168 - Must be testable in under 30 minutes169 - Must reveal whether the key assumption (from Stage 3) is valid170 - Must be throwaway — don't over-invest171172### Output173Deliver: Prototype artifact (spec, wireframe, code, or schema) + what assumption it tests + how to test it.174175## Stage 5: Test176177**Goal:** Validate with real users (or realistic proxies) and decide next steps.178179### Process1801811. **Define the test.** For each prototype:182183```184TEST PLAN185---------186Hypothesis: [What we believe will happen]187Method: [How we'll test — user session, A/B, analytics, survey]188Audience: [Who we're testing with — be specific]189Duration: [How long the test runs]190Success: [Quantitative threshold — e.g., "70% complete the flow in < 2 min"]191Failure: [What result means we pivot]192```1931942. **Identify what to observe:**195 - Task completion (can they do it?)196 - Time on task (is it efficient?)197 - Error rate (where do they get stuck?)198 - Emotional response (do they feel confident/frustrated?)199 - Unprompted feedback (what do they say without being asked?)2002013. **Create feedback capture framework:**202 - What worked? (Keep)203 - What was confusing? (Fix)204 - What was missing? (Add)205 - What was unnecessary? (Remove)2062074. **Decision framework after testing:**208209| Result | Action |210|--------|--------|211| Clear success (meets all criteria) | Ship it, monitor metrics |212| Partial success (some criteria met) | Iterate — return to Stage 3 or 4 |213| Clear failure (no criteria met) | Pivot — return to Stage 2, redefine problem |214| Surprising insight | Explore — return to Stage 1, dig deeper |215216### Output217Deliver: Test plan + observation checklist + decision framework + recommended next action.218219## Audit Mode (/dt audit)220221Review an existing feature, page, or system against design thinking principles:2222231. **User alignment** — Is it clear who this is for and what problem it solves?2242. **Problem-solution fit** — Does the solution actually address the stated problem?2253. **Assumption exposure** — What untested assumptions are baked in?2264. **Feedback loops** — Is there a way to know if it's working? (Analytics, user feedback)2275. **Iteration history** — Has this been tested and refined, or shipped once and forgotten?228229Output a scorecard:230231```232DT AUDIT: [Feature/Page Name]233==============================234User Clarity: [1-5] — Do we know who this is for?235Problem Definition: [1-5] — Is the problem clearly stated?236Solution Fit: [1-5] — Does the solution match the problem?237Validation: [1-5] — Has this been tested with users?238Iteration: [1-5] — Has it been refined based on feedback?239-------------------------------240SCORE: [X/25]241TOP RECOMMENDATION: [One actionable next step]242```243244## Integration with Existing Workflow245246- **Before GSD phases:** Run `/dt define` to sharpen the problem before creating a roadmap247- **Before new features:** Run `/dt empathize` + `/dt define` to validate you're solving the right problem248- **Dashboard design:** Run `/dt empathize` to surface what metrics users actually need249- **Architecture decisions:** Run `/dt` full to consider the human impact of technical choices250- **Multilingual projects:** Empathy maps should be created per-language audience (cultural context matters)251- **Post-launch:** Run `/dt audit` on shipped features to identify iteration opportunities252253## Principles2542551. **Users first, technology second.** The question is never "what can we build?" — it's "what should we build?"2562. **Diverge before converging.** Generate many ideas before picking one. Premature convergence kills innovation.2573. **Make it tangible.** Abstract discussions waste time. Prototypes — even rough ones — accelerate decisions.2584. **Test assumptions, not egos.** The goal of testing is to learn, not to prove you were right.2595. **Iterate, don't perfect.** Ship, learn, improve. A shipped 80% solution teaches more than an unshipped 100% solution.