|
1
|
--- |
|
2
|
name: design-thinker |
|
3
|
description: Apply design thinking to validate ideas, define audiences, and prioritize directions. |
|
4
|
--- |
|
5
|
|
|
6
|
# Design Thinking |
|
7
|
|
|
8
|
Apply human-centered problem solving. Three frameworks dominate industry practice — pick based on what the user actually needs, don't default to IDEO's 5 phases. |
|
9
|
|
|
10
|
## When to Use |
|
11
|
|
|
12
|
- Ambiguous problem space, no obvious solution |
|
13
|
- "Why aren't users adopting X?" / "What should we build next?" |
|
14
|
|
|
15
|
- Stuck and needs structured divergence |
|
16
|
- "Who is this for?" / "Who should we target?" — audience definition and user persona synthesis |
|
17
|
|
|
18
|
- "Is this idea worth pursuing?" / "Should we invest in X?" — idea validation before committing resources |
|
19
|
- "We have too many ideas, which one?" / "Help me prioritize" — structured narrowing from many directions to one |
|
20
|
|
|
21
|
- "What problem are we actually solving?" — problem reframing when the real issue might be upstream |
|
22
|
- "Why did this product/feature fail?" — post-mortem through a design thinking lens (wrong problem, wrong audience, or wrong solution) |
|
23
|
|
|
24
|
## When NOT to Use |
|
25
|
|
|
26
|
- Known problem, known solution, just needs execution (skip straight to PRD — use product-manager skill) |
|
27
|
- Visual/UI implementation (use design skill) |
|
28
|
|
|
29
|
- Technical debugging |
|
30
|
- Pure information gathering with no decision needed (use deep-research skill) |
|
31
|
|
|
32
|
- Competitive positioning or feature comparison (use competitive-analysis skill) |
|
33
|
|
|
34
|
## Depth Calibration |
|
35
|
|
|
36
|
Not every problem needs a full board. Before starting, gauge the scope and pick the right depth: |
|
37
|
|
|
38
|
### Quick Mode (10-15 min, 2-3 cards per phase) |
|
39
|
|
|
40
|
Use when: the user has a specific question like "should I build X or Y?", the domain is narrow, or they just want a structured opinion. Research is 1-2 searches. Canvas output is compact — skip sidebar annotations, limit to 2 concepts, use a single assumption card. No forces diagram. |
|
41
|
|
|
42
|
### Standard Mode (30-45 min, full board) |
|
43
|
|
|
44
|
Use when: the problem space is moderately open — "what should we build for market X?" or "why is feature Y underperforming?". Research is 3-5 searches across different angles. Full canvas board with all sections. Forces diagram for top concept only. |
|
45
|
|
|
46
|
### Deep Mode (60+ min, full board + extended research) |
|
47
|
|
|
48
|
Use when: high-stakes strategic decisions, entering new markets, or pivoting a product. Research is exhaustive — 5+ searches, reading full articles via webFetch, cross-referencing data. Full canvas board with forces diagrams for every concept, detailed assumption mapping, and confidence scoring. Consider launching parallel research subagents for different angles. |
|
49
|
|
|
50
|
Default to Standard Mode. Upgrade to Deep if the user's question involves a new market, significant investment, or a pivot. Downgrade to Quick if the question is binary or narrowly scoped. |
|
51
|
|
|
52
|
## Three Frameworks — Choose Wisely |
|
53
|
|
|
54
|
### 1. Double Diamond (UK Design Council, 2004) — for ambiguous problems |
|
55
|
|
|
56
|
Two diamonds = two diverge-then-converge cycles. **Discover**(go wide on problem research) →**Define**(narrow to problem statement) →**Develop**(go wide on solutions) →**Deliver** (narrow to one, ship it). |
|
57
|
|
|
58
|
Critical insight: most teams skip the first diamond and jump straight to solution brainstorming. The first diamond exists to prevent solving the wrong problem beautifully. |
|
59
|
|
|
60
|
**Use when**: problem isn't yet defined, timeline is weeks not days. |
|
61
|
|
|
62
|
### 2. GV Design Sprint (Jake Knapp, Google Ventures, 2010) — for validation speed |
|
63
|
|
|
64
|
5 days, 5 phases, hard time-box. Map (Mon) → Sketch (Tue) → Decide (Wed) → Prototype (Thu) → Test with 5 real users (Fri). Full method free at `gv.com/sprint`and`designsprintkit.withgoogle.com`. |
|
65
|
|
|
66
|
**Known weakness**: users appear on Day 5, not Day 1. The sprint relies on team intuition to frame the problem — you can spend 5 days sprinting toward the wrong target. Fix: run JTBD interviews *before* the sprint to pick the problem. |
|
67
|
|
|
68
|
**Use when**: problem is defined, team can commit 5 uninterrupted days, you need a go/no-go decision fast. |
|
69
|
|
|
70
|
**"5 users" is not arbitrary**: Nielsen Norman Group research shows 5 users find ~85% of usability problems. Diminishing returns after that. |
|
71
|
|
|
72
|
### 3. JTBD Switch Interview (Bob Moesta / Re-Wired Group) — for understanding why people buy |
|
73
|
|
|
74
|
Not a workshop — a forensic interview technique. Interview people who *recently switched* (bought your product, or churned to a competitor). 45-60 minutes. Reconstruct their timeline, don't ask about features. |
|
75
|
|
|
76
|
**The Timeline** (walk backward through their actual purchase): |
|
77
|
|
|
78
|
1. **First thought** — when did it first occur to you this was a problem? |
|
79
|
2. **Passive looking** — noticing solutions but not acting |
|
80
|
|
|
81
|
3. **Event one** — something happens that makes it urgent |
|
82
|
4. **Active looking** — comparing options, raised hand |
|
83
|
|
|
84
|
5. **Deciding** — what tipped it? |
|
85
|
6. **Buying** — the actual moment |
|
86
|
|
|
87
|
**The Four Forces** (what made the switch happen): |
|
88
|
|
|
89
|
| Force | Direction | Probe | |
|
90
|
|
|
91
|
|---|---|---| |
|
92
|
|
|
93
|
| Push of the situation | Toward switch | "What was happening that made the old way stop working?" | |
|
94
|
|
|
95
|
| Pull of the new solution | Toward switch | "When you imagined having this, what got you excited?" | |
|
96
|
|
|
97
|
| Anxiety of the new | Against switch | "What worried you about switching?" | |
|
98
|
|
|
99
|
| Habit of the present | Against switch | "What was good enough about what you had?" | |
|
100
|
|
|
101
|
Switch only happens when Push + Pull > Anxiety + Habit. If someone didn't buy, one of the blocking forces won. |
|
102
|
|
|
103
|
**Key technique**: ask about the *situation*, never the feature. Not "do you like the dashboard?" but "walk me through the last time you opened it — what were you in the middle of?" Reference: the "Mattress Interview" at `jobstobedone.org` — Moesta interviews a guy about buying a mattress for 45 min and uncovers it was actually about his marriage. |
|
104
|
|
|
105
|
**Use when**: you have customers but don't understand why they chose you, or you're losing deals and don't know why. |
|
106
|
|
|
107
|
## Research Synthesis |
|
108
|
|
|
109
|
Research is only useful if it feeds directly into the framework phases. Follow this process to avoid the common failure of doing research and then ignoring it during ideation. |
|
110
|
|
|
111
|
### Step 1: Gather (DISCOVER phase) |
|
112
|
|
|
113
|
Run 3-5 web searches across different angles of the problem space. For each search, extract: |
|
114
|
|
|
115
|
- **Hard numbers** — market size, penetration rates, growth figures, demographic data |
|
116
|
- **Pain signals** — what people complain about, what's broken, what's missing |
|
117
|
|
|
118
|
- **Existing solutions** — who's already solving parts of this, and where are they falling short |
|
119
|
|
|
120
|
### Step 2: Distill (DEFINE phase) |
|
121
|
|
|
122
|
From the raw research, identify 2-3 **key insights** — non-obvious patterns that connect multiple data points. Each insight must be grounded in evidence from Step 1, not invented. Format each as: |
|
123
|
|
|
124
|
> **Insight**: [pattern observed] |
|
125
|
> |
|
126
|
> **Evidence**: [specific data points or sources that support it] |
|
127
|
> |
|
128
|
> **Implication**: [what this means for what we should build] |
|
129
|
|
|
130
|
These insights directly feed the HMW statement. The HMW should address the most important insight, not the most obvious problem. |
|
131
|
|
|
132
|
### Step 3: Ground (DEVELOP phase) |
|
133
|
|
|
134
|
Every solution concept must reference at least one insight from Step 2 and one data point from Step 1. This prevents "idea theater" — generating concepts that sound creative but ignore the research. If a concept can't be traced back to the research, cut it. |
|
135
|
|
|
136
|
### Step 4: Stress-test (DELIVER phase) |
|
137
|
|
|
138
|
For the recommended concept, revisit the research to identify what could invalidate it. Look for counter-evidence, missing data, or assumptions the research didn't cover. These become the riskiest assumptions to test. |
|
139
|
|
|
140
|
## Core Tools (Framework-Agnostic) |
|
141
|
|
|
142
|
**How Might We (HMW)** — reframe problem as opportunity. Scope test: too narrow bakes in the solution ("HMW add a share button"), too broad is unactionable ("HMW make users happy"). Right: "HMW help busy parents find 20-minute recipes without meal-planning guilt?" |
|
143
|
|
|
144
|
**Crazy 8s** (from GV Sprint) — fold paper into 8 panels, sketch 8 distinct ideas in 8 minutes. Forces past the obvious first 3 ideas. Works solo or in groups. |
|
145
|
|
|
146
|
**Assumption Mapping** — plot assumptions on Importance × Evidence 2×2. High-importance + low-evidence = test first. This picks your prototype target. |
|
147
|
|
|
148
|
**Empathy Map** (Dave Gray, XPLANE) — Say / Think / Do / Feel quadrants around a user. "Think" and "Feel" are where insight lives — they're the gap between what users say and what they do. |
|
149
|
|
|
150
|
**5-Act Interview** (GV test-day script): Friendly welcome → context questions → intro the prototype → tasks (watch, don't help) → debrief. One person interviews, team watches on video in another room and takes notes. |
|
151
|
|
|
152
|
**Adoption Forces (applied to every concept)** — The JTBD Four Forces framework is too useful to reserve only for JTBD analyses. For every solution concept in DEVELOP, map these four forces from the *target user's perspective*: |
|
153
|
|
|
154
|
| Force | Direction | Question to answer | |
|
155
|
|
|
156
|
|---|---|---| |
|
157
|
|
|
158
|
| Push | Toward adoption | What's painful enough about the status quo to make them try something new? | |
|
159
|
|
|
160
|
| Pull | Toward adoption | What's exciting about this concept — what do they imagine getting? | |
|
161
|
|
|
162
|
| Anxiety | Against adoption | What scares them about switching — cost, learning curve, risk, trust? | |
|
163
|
|
|
164
|
| Habit | Against adoption | What's good enough about their current way — why haven't they already changed? | |
|
165
|
|
|
166
|
Adoption happens when Push + Pull > Anxiety + Habit. If the forces don't balance toward adoption, the concept needs redesign — either amplify Push/Pull or reduce Anxiety/Habit. In Standard mode, do this for the top recommended concept. In Deep mode, do it for every concept. |
|
167
|
|
|
168
|
## Output Format |
|
169
|
|
|
170
|
```markdown |
|
171
|
|
|
172
|
# [Challenge] |
|
173
|
|
|
174
|
## Framework Used |
|
175
|
|
|
176
|
[Double Diamond / GV Sprint / JTBD — and why this one] |
|
177
|
|
|
178
|
## Problem Definition |
|
179
|
|
|
180
|
### HMW Statement |
|
181
|
|
|
182
|
### Key Insights (with evidence — quote or observation, not assumption) |
|
183
|
|
|
184
|
## [If JTBD] Forces Diagram |
|
185
|
|
|
186
|
| Push | Pull | Anxiety | Habit | |
|
187
|
|
|
188
|
|---|---|---|---| |
|
189
|
|
|
190
|
## Solution Concepts |
|
191
|
|
|
192
|
| Concept | Desirable? | Feasible? | Viable? | Riskiest assumption | |
|
193
|
|
|
194
|
|---|---|---|---|---| |
|
195
|
|
|
196
|
## Adoption Forces (for recommended concept, or all concepts in Deep mode) |
|
197
|
|
|
198
|
| Force | Assessment | |
|
199
|
|
|
200
|
|---|---| |
|
201
|
|
|
202
|
| Push (pain of status quo) | | |
|
203
|
|
|
204
|
| Pull (appeal of new solution) | | |
|
205
|
|
|
206
|
| Anxiety (fears about switching) | | |
|
207
|
|
|
208
|
| Habit (comfort of current way) | | |
|
209
|
|
|
210
|
| **Balance** | Push + Pull [>/<] Anxiety + Habit | |
|
211
|
|
|
212
|
## Recommendation |
|
213
|
|
|
214
|
### Conviction Level |
|
215
|
|
|
216
|
[Low / Medium / High] — State your confidence and what would change it. |
|
217
|
|
|
218
|
- **Current conviction**: [e.g., "Medium — the pain signal is strong but adoption behavior is unproven"] |
|
219
|
- **Would increase to High if**: [e.g., "3/5 merchants in a pilot use the app daily for 2 weeks"] |
|
220
|
|
|
221
|
- **Would decrease if**: [e.g., "merchants report they tried similar apps before and abandoned them"] |
|
222
|
|
|
223
|
## Prototype Plan |
|
224
|
|
|
225
|
- What to build (lowest fidelity that tests the assumption) |
|
226
|
- Who to test with (5 users, recruited how) |
|
227
|
|
|
228
|
- What "success" looks like |
|
229
|
|
|
230
|
## Next Steps |
|
231
|
|
|
232
|
``` |
|
233
|
|
|
234
|
## Canvas Presentation |
|
235
|
|
|
236
|
When presenting design thinking analysis on the canvas, follow these rules for a clear, skimmable board. |
|
237
|
|
|
238
|
### Shape Types & When to Use Each |
|
239
|
|
|
240
|
| Shape | Use For | Why | |
|
241
|
|
|
242
|
|---|---|---| |
|
243
|
|
|
244
|
| `note` (sticky note) | Section headers, sidebar annotations, key stats | Fixed 200px width. Auto-sizes font based on text length — fewer words = bigger text. Perfect for bold single-word headers. | |
|
245
|
|
|
246
|
| `geo`(rectangle) | Content cards, full-width banners, problem statements | Respects`w`and`h`— use for wide content (500px+ cards, 1600px+ banners). Set`fill: "solid"` and pick a color. | |
|
247
|
|
|
248
|
| `geo`(arrow-down / arrow-right) | Flow indicators between sections | Shows the progression through the framework. Use`fill: "solid"`. | |
|
249
|
|
|
250
|
| `text` | Small inline labels like "vs" between forces | Auto-sizes, minimal visual weight. | |
|
251
|
|
|
252
|
### Layout Rules |
|
253
|
|
|
254
|
1. **Headers as sticky notes with minimal text** — Use 1-2 words max (e.g., "DISCOVER", "DEFINE", "FORCES"). The note shape auto-scales font size inversely to text length, so short text = large, skimmable headers. |
|
255
|
2. **Content cards as geo rectangles** — 500px wide for 3-column layouts, 780px for 2-column layouts, 1600px+ for full-width banners. Always set `fill: "solid"` and a color. |
|
256
|
|
|
257
|
3. **Left-column header notes, right-side content** — Place header sticky notes at x=1400, content cards starting at x=1670 (leaving a 70px gap after the 200px-wide header note). |
|
258
|
4. **Vertical spacing** — 80-100px between rows within a section, 120-150px between sections. This keeps the board breathable and skimmable. |
|
259
|
|
|
260
|
5. **Arrow shapes between sections** — Place `geo`shapes with`arrow-down` geo centered horizontally between sections to show flow. Use the section's color. |
|
261
|
6. **Annotation stickies as sidebar** — Place `note` shapes at x=3350 (far right) aligned vertically with their related section. Use for market stats, key quotes, risk callouts — short punchy content that adds context without cluttering the main flow. |
|
262
|
|
|
263
|
7. **Color coding by section** — Be consistent: |
|
264
|
|
|
265
|
- Violet: title, concepts |
|
266
|
- Blue: discover |
|
267
|
|
|
268
|
- Green: define |
|
269
|
- Orange: develop / forces |
|
270
|
|
|
271
|
- Red: deliver |
|
272
|
- Yellow: key callouts (problem statement, switch rule, recommendation) |
|
273
|
|
|
274
|
- Light-* variants for content cards within each section |
|
275
|
|
|
276
|
1. **JTBD Forces layout** — Use 2x2 grid: Push (top-left, light-red) vs Pull (top-right, light-green), Anxiety (bottom-left, orange) vs Habit (bottom-right, grey). Place arrow-right shapes and "vs" text labels between the pairs. |
|
277
|
|
|
278
|
### Canvas Gotchas |
|
279
|
|
|
280
|
- **Sticky notes (`note`type) are always 200px wide** — the`w` parameter is ignored. Plan layouts around this constraint. |
|
281
|
- **`labelColor: "white"` can cause rendering errors** — avoid it. Use lighter fill colors where default black text is readable. |
|
282
|
|
|
283
|
- **`color: "black"`on geo shapes with`fill: "solid"`causes errors** — use`grey` or a dark supported color instead. |
|
284
|
- **Always call `get_canvas_state` before placing shapes** — check for existing content and find empty space. |
|
285
|
|
|
286
|
- **Delete before recreate** — when updating shapes, delete first then create fresh. Updates to notes can behave unexpectedly. |
|
287
|
|
|
288
|
### Example: Placing a Section |
|
289
|
|
|
290
|
```text |
|
291
|
|
|
292
|
1. Header note (big text): |
|
293
|
|
|
294
|
{ type: "note", x: 1400, y: Y, w: 200, h: 200, color: "blue", text: "DISCOVER" } |
|
295
|
|
|
296
|
2. Content cards (3-column): |
|
297
|
|
|
298
|
{ type: "geo", geo: "rectangle", x: 1670, y: Y, w: 500, h: 260, color: "light-blue", fill: "solid", text: "..." } |
|
299
|
|
|
300
|
{ type: "geo", geo: "rectangle", x: 2220, y: Y, w: 500, h: 260, color: "light-violet", fill: "solid", text: "..." } |
|
301
|
|
|
302
|
{ type: "geo", geo: "rectangle", x: 2770, y: Y, w: 500, h: 260, color: "light-green", fill: "solid", text: "..." } |
|
303
|
|
|
304
|
3. Flow arrow to next section: |
|
305
|
|
|
306
|
{ type: "geo", geo: "arrow-down", x: 2300, y: Y+300, w: 80, h: 60, color: "blue", fill: "solid" } |
|
307
|
|
|
308
|
4. Sidebar annotation: |
|
309
|
|
|
310
|
{ type: "note", x: 3350, y: Y, w: 200, h: 200, color: "yellow", text: "$45.5B\nmarket by 2028" } |
|
311
|
|
|
312
|
``` |
|
313
|
|
|
314
|
## Research |
|
315
|
|
|
316
|
- `webSearch("[user's problem domain] user research")` for prior art |
|
317
|
- `webFetch("https://www.gv.com/sprint/")` for full sprint method |
|
318
|
|
|
319
|
- `webSearch("[product category] reviews site:reddit.com")` — unfiltered user language for push/anxiety forces |
|
320
|
- IDEO Design Kit free methods: `designkit.org/methods` |
|
321
|
|
|
322
|
## Hard Truths |
|
323
|
|
|
324
|
- Agent cannot run real interviews — can write the discussion guide, analyze transcripts the user pastes in, and build the synthesis |
|
325
|
- Personas without research are fiction. Push user for real data (support tickets, reviews, churn interviews) before building empathy maps |
|
326
|
|
|
327
|
- Most "design thinking" fails because teams do ideation theater and skip the uncomfortable research. Bias toward the first diamond |