Design thinker
Reusable AI agent skills library (SKILL.md) for Codex/Copilot/Claude-style workflows.
npx -y skills add scikrikci/skills --skill design-thinkerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Apply IDEO-style design thinking methodology to solve complex problems creatively, then present the analysis on canvas and/or as a web artifact.
SKILL.md
9.9 KB, as published. Nobody here has run it
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 and 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):
- First thought — when did it first occur to you this was a problem?
- Passive looking — noticing solutions but not acting
- Event one — something happens that makes it urgent
- Active looking — comparing options, raised hand
- Deciding — what tipped it?
- Buying — the actual moment
The Four Forces (what made the switch happen):
| Force | Direction | Probe |
|---|---|---|
| Push of the situation | Toward switch | "What was happening that made the old way stop working?" |
| Pull of the new solution | Toward switch | "When you imagined having this, what got you excited?" |
| Anxiety of the new | Against switch | "What worried you about switching?" |
| Habit of the present | Against switch | "What was good enough about what you had?" |
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 — Moesta interviews a guy about buying a mattress for 45 min and uncovers it was actually about his marriage.
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
| Shape | Use For | Why |
|---|---|---|
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. |
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. |
geo (arrow-down / arrow-right) | Flow indicators between sections | Shows the progression through the framework. Use fill: "solid". |
text | Small inline labels like "vs" between forces | Auto-sizes, minimal visual weight. |
Layout Rules
-
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.
-
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. -
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).
-
Vertical spacing — 80-100px between rows within a section, 120-150px between sections. This keeps the board breathable and skimmable.
-
Arrow shapes between sections — Place
geoshapes witharrow-downgeo centered horizontally between sections to show flow. Use the section's color. -
Annotation stickies as sidebar — Place
noteshapes 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. -
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
-
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 (
notetype) are always 200px wide — thewparameter 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 withfill: "solid"causes errors — usegreyor a dark supported color instead.- Always call
get_canvas_statebefore 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 artwebFetch("https://www.gv.com/sprint/")for full sprint methodwebSearch("[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