# Design Thinking

> 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.

- Skill: `orbweva/design-thinking` (Agent Skill)
- Install (CLI): `npx skillmds@latest add orbweva/design-thinking`
- Raw SKILL.md: https://api.skillmd.com/api/skills/orbweva/design-thinking/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ORBWEVA (https://skillmd.com/u/orbweva)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/orbweva/design-thinking

---


# 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

1. **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)

2. **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)

3. **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?
```

4. **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

1. **Synthesize insights** from Stage 1 into themes. Group related pain points.

2. **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)

3. **Define success criteria.** What does "solved" look like?
   - User behavior change (measurable)
   - Business metric impact
   - Emotional outcome ("feels confident" → measured via NPS/survey)

4. **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

1. **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?"

2. **Challenge assumptions.** List 3-5 assumptions baked into the current thinking. For each, ask: "What if this isn't true?"

3. **Prioritize using Impact/Effort matrix:**

```
HIGH IMPACT
    |
    |  Quick Wins    |  Big Bets
    |  (DO FIRST)    |  (PLAN)
    |________________|________________
    |                |
    |  Fill-ins      |  Money Pits
    |  (MAYBE)       |  (AVOID)
    |
    LOW IMPACT -----------> HIGH EFFORT
```

4. **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

1. **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 |

2. **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)

3. **For system/architecture prototypes**, describe:
   - Data flow diagram
   - API contract (endpoints, request/response shapes)
   - State management approach
   - Integration points with existing systems

4. **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)

5. **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

1. **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]
```

2. **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?)

3. **Create feedback capture framework:**
   - What worked? (Keep)
   - What was confusing? (Fix)
   - What was missing? (Add)
   - What was unnecessary? (Remove)

4. **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:

1. **User alignment** — Is it clear who this is for and what problem it solves?
2. **Problem-solution fit** — Does the solution actually address the stated problem?
3. **Assumption exposure** — What untested assumptions are baked in?
4. **Feedback loops** — Is there a way to know if it's working? (Analytics, user feedback)
5. **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

1. **Users first, technology second.** The question is never "what can we build?" — it's "what should we build?"
2. **Diverge before converging.** Generate many ideas before picking one. Premature convergence kills innovation.
3. **Make it tangible.** Abstract discussions waste time. Prototypes — even rough ones — accelerate decisions.
4. **Test assumptions, not egos.** The goal of testing is to learn, not to prove you were right.
5. **Iterate, don't perfect.** Ship, learn, improve. A shipped 80% solution teaches more than an unshipped 100% solution.