design-thinking · diff
v2026.5.17 to v2026.5.17
7 added, 5 removed. Audit A to A.
---
name: design-thinking
description: >
- Human-centered design flow: empathize with needs, frame the problem, ideate,
- prototype intent, and define learning tests. Use when the user asks for design
- thinking, HCD, problem reframing from user evidence, service or UX concept
- sprints, or "how might we" exploration before build — not for pure code review
- without a user problem.
+ Use this skill when the user asks for design thinking or wants human-centered
+ exploration—empathizing with needs, framing the problem, ideating, prototyping
+ intent, and defining what to learn next. Use for HCD, service or UX concept
+ sprints, how-might-we style discovery before build, or reframing from user
+ evidence, even with messy context. Skip when the spec is fully frozen and they
+ want no discovery, or when the task is code-only maintenance with no user
+ problem framing requested.
license: MIT
metadata:
author: ysskrishna
version: "2026.5.17"
---
# Design Thinking
Fall in love with the problem, not the first solution. End with **what to learn next**, not just ideas.
---
## When to Use
Use for product, service, policy, or experience work where **user/stakeholder needs** should drive the shape of the solution. Skip when the spec is fully frozen and no discovery is wanted.
---
## Setup (run before starting)
In one short block:
1. **Design challenge** — who is affected and in what situation?
2. **Default pass** — Empathize → Define → Ideate → Prototype → Test plan (state this line)
Up to 3 questions on users, constraints, and success signals; otherwise proceed with `[ASSUMED]`.
If **Empathize** is thin (no real user input), say so honestly in **Define** and keep the POV narrow instead of inventing research.
---
## The Stages
### Empathize
**Who** — primary user or stakeholder (facts from user vs `[INFERRED]`). **Jobs / pains / gains** — what they are trying to do and what hurts. **Context** — when/where the need shows up.
No fabricated quotes; paraphrase only what the user supplied.
### Define
**Insight statement** — non-obvious tension connecting pains and context. **Point of View (POV)** — "**[User]** needs **[verb]** because **[insight]**." **How Might We (HMW)** — 2–3 well-scoped questions opened by the POV.
### Ideate
Quantity + variety. Use **HMW** as prompts. Tag ideas `desirable` / `feasible` / `viable` as **hypotheses** (not proven). Aim for **about 10** ideas unless the user specifies otherwise.
### Prototype
Describe **low-fidelity** artifacts: paper flow, roleplay script, landing smoke test, clickable sketch. For each: **Purpose:** what question does this answer? **Fidelity:** low / medium.
### Test plan
**Learning goals** — what would convince you the idea is wrong? **Participants / sample** (or `[TBD]`). **Signals** — behaviors or metrics to observe. **Next iteration** — what changes if results are mixed.
---
## Execution Rules
1. **Define** must reflect whatever **Empathize** actually contains; do not invent field research.
2. Do not collapse **Ideate** into a single solution before **Prototype**.
3. **Test plan** must include falsifiable signals.
---
## Checklist (verify before responding)
- [ ] Setup: design challenge + default pass
- [ ] Empathize distinguishes fact vs `[INFERRED]`
- [ ] POV + HMW before Ideate
- [ ] Ideation volume ~10 unless adjusted; desirable / feasible / viable tags used
- [ ] Prototype states purpose and fidelity
- [ ] Test plan has learning goals and signals