Design Thinking

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.

When to Use

• Ambiguous problem space, no obvious solution
• "Why aren't users adopting X?" / "What should we build next?"
• Stuck and needs structured divergence

When NOT to Use

• Known problem, known solution, just needs execution (skip straight to PRD)
• Visual/UI implementation (use design skill)
• Technical debugging

Three Frameworks — Choose Wisely

1. Double Diamond (UK Design Council, 2004) — for ambiguous problems

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

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.

Use when: problem isn't yet defined, timeline is weeks not days.

2. GV Design Sprint (Jake Knapp, Google Ventures, 2010) — for validation speed

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

designsprintkit.withgoogle.com

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.

Use when: problem is defined, team can commit 5 uninterrupted days, you need a go/no-go decision fast.

"5 users" is not arbitrary: Nielsen Norman Group research shows 5 users find ~85% of usability problems. Diminishing returns after that.

3. JTBD Switch Interview (Bob Moesta / Re-Wired Group) — for understanding why people buy

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.

The Timeline (walk backward through their actual purchase):

1. First thought — when did it first occur to you this was a problem?
2. Passive looking — noticing solutions but not acting
3. Event one — something happens that makes it urgent
4. Active looking — comparing options, raised hand
5. Deciding — what tipped it?
6. Buying — the actual moment

The Four Forces (what made the switch happen):

Switch only happens when Push + Pull > Anxiety + Habit. If someone didn't buy, one of the blocking forces won.

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

Use when: you have customers but don't understand why they chose you, or you're losing deals and don't know why.

Core Tools (Framework-Agnostic)

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?"

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.

Assumption Mapping — plot assumptions on Importance × Evidence 2×2. High-importance + low-evidence = test first. This picks your prototype target.

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.

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.

Output Format

# [Challenge]

## Framework Used
[Double Diamond / GV Sprint / JTBD — and why this one]

## Problem Definition

### HMW Statement

### Key Insights (with evidence — quote or observation, not assumption)

## [If JTBD] Forces Diagram
| Push | Pull | Anxiety | Habit |
|---|---|---|---|

## Solution Concepts
| Concept | Desirable? | Feasible? | Viable? | Riskiest assumption |
|---|---|---|---|---|

## Prototype Plan

- What to build (lowest fidelity that tests the assumption)
- Who to test with (5 users, recruited how)
- What "success" looks like

## Next Steps

Canvas Presentation

When presenting design thinking analysis on the canvas, follow these rules for a clear, skimmable board.

Shape Types & When to Use Each

note

geo

w

h

fill: "solid"

geo

fill: "solid"

text

Layout Rules

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.

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.

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

4. Vertical spacing — 80-100px between rows within a section, 120-150px between sections. This keeps the board breathable and skimmable.

5. Arrow shapes between sections — Place

   geo

   shapes with

   arrow-down

   geo centered horizontally between sections to show flow. Use the section's color.

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.

7. Color coding by section — Be consistent:

   • Violet: title, concepts
   • Blue: discover
   • Green: define
   • Orange: develop / forces
   • Red: deliver
   • Yellow: key callouts (problem statement, switch rule, recommendation)
   • Light-* variants for content cards within each section

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

Canvas Gotchas

• Sticky notes (

  note

  type) are always 200px wide — the

  w

  parameter is ignored. Plan layouts around this constraint.

• labelColor: "white"

  can cause rendering errors — avoid it. Use lighter fill colors where default black text is readable.

• color: "black"

  on geo shapes with

  fill: "solid"

  causes errors — use

  grey

  or a dark supported color instead.
• Always call

  get_canvas_state

  before placing shapes — check for existing content and find empty space.
• Delete before recreate — when updating shapes, delete first then create fresh. Updates to notes can behave unexpectedly.

Example: Placing a Section

1. Header note (big text):
   { type: "note", x: 1400, y: Y, w: 200, h: 200, color: "blue", text: "DISCOVER" }

2. Content cards (3-column):
   { type: "geo", geo: "rectangle", x: 1670, y: Y, w: 500, h: 260, color: "light-blue", fill: "solid", text: "..." }
   { type: "geo", geo: "rectangle", x: 2220, y: Y, w: 500, h: 260, color: "light-violet", fill: "solid", text: "..." }
   { type: "geo", geo: "rectangle", x: 2770, y: Y, w: 500, h: 260, color: "light-green", fill: "solid", text: "..." }

3. Flow arrow to next section:
   { type: "geo", geo: "arrow-down", x: 2300, y: Y+300, w: 80, h: 60, color: "blue", fill: "solid" }

4. Sidebar annotation:
   { type: "note", x: 3350, y: Y, w: 200, h: 200, color: "yellow", text: "$45.5B\nmarket by 2028" }

Research

• webSearch("[user's problem domain] user research")

  for prior art

• webFetch("https://www.gv.com/sprint/")

  for full sprint method

• webSearch("[product category] reviews site:reddit.com")

  — unfiltered user language for push/anxiety forces
• IDEO Design Kit free methods:

  designkit.org/methods

Hard Truths

• Agent cannot run real interviews — can write the discussion guide, analyze transcripts the user pastes in, and build the synthesis
• Personas without research are fiction. Push user for real data (support tickets, reviews, churn interviews) before building empathy maps
• Most "design thinking" fails because teams do ideation theater and skip the uncomfortable research. Bias toward the first diamond