agentsclimarketplace

Design thinking

Skill deciqAI/knowledge-skills/design-thinking

Activate when: user asks 'why isn't anyone using our product?', 'how do we understand what customers really want?', 'we know the tech works but the market isn't responding', team is stuck on a single solution and needs divergent ideas, or someone discusses user research / personas / prototyping / iterative design. Do NOT activate when: the problem and solution are both already validated and the challenge is pure execution; or the team cannot access real users at any point. More: deciqai.com/s/design-thinkingFrom its SKILL.md

Install
npx -y skills add deciqAI/knowledge-skills --skill design-thinking

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 3 stars3 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.

SKILL.md

9.2 KB, ~2.0k tokens by cl100k_base, as published. Nobody here has run it

Design Thinking

Overview

Design thinking — formalized by Tim Brown at IDEO and Stanford's d.school, grounded in Simon (1969) and Rittel's "wicked problems" — replaces assumption-driven decisions with evidence from observed human behavior. Its three-lens test: every viable innovation must sit at the intersection of desirability, feasibility, and viability. Most product failures are desirability failures; teams built something technically sound that people did not want.

Composes with neighbors: use jobs-to-be-done alongside the Define stage; use mvp after Prototype; use lean-startup as the execution engine after the full five-stage cycle.

When to Use

Apply when:

  • The real user problem is not yet understood — team has a solution but no observed-behavior evidence
  • User adoption is failing despite a technically sound product (unresolved desirability gap)
  • Team is locked into one solution direction and needs divergent thinking first
  • Problem has multiple conflicting stakeholders and no single correct answer
  • Team states "we already know what users need" without observational evidence
  • An AI/LLM feature demos well but stalls in real use — high AI capex and AI-native competition, yet users won't adopt the generic chatbot (a desirability, not capability, gap)

When NOT to use:

  • Problem and solution both well-understood; challenge is execution only
  • Less than two weeks available for genuine user research (produces assumption-laundering)
  • Regulatory constraints preclude prototyping before specification
  • Team cannot access real users at all

Coaching Novices (Adaptive Front Door)

Engine mode: concrete challenge → run The Process. Coach mode: unfamiliar user → guide step by step. In Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.

  1. Design thinking is a five-step process for building things people actually want: observe first, prototype cheaply, iterate on what you observe (not what you assumed).
  2. Check fit: does the team know — based on observation, not assumption — why users behave as they do? If yes and solution is validated, divergent stages may not be needed.
  3. Elicit their real case: product/service, who are the users, what is the current evidence of user behavior?

[WAIT — do not advance until user responds]

  1. Start with Empathize: "When did someone on the team last directly observe a user — not a survey, not analytics, but watch a person use the product?"

[WAIT — do not advance until user responds]

  1. Close by naming the insight they most need and which stage is most likely to surface it.

[WAIT — do not advance until user responds]

The Process

Run the Design Sprint through five stages (divergent → convergent, checkable output at each).

  1. Empathize: Observe real users in context (30–60 min interviews; contextual observation; extreme users). Stop-rule: survey responses alone = stage incomplete.
  2. Define: Sort observations by theme → find say/do contradictions → write insight statement → reframe as "How Might We" (HMW). Deliverable: 3–5 ranked HMWs. Stop-rule: HMW contains a solution → return to synthesis.
  3. Ideate: Silent writing → share → cluster → dot-vote → select 3–5 for prototyping. Stop-rule: <20 concepts before convergence = ideation was skipped.
  4. Prototype: Minimum artifact to test the core assumption; one explicit learning question per prototype; 4-hour ceiling. Stop-rule: polishing without a new assumption = stop.
  5. Test: Define 3 hypotheses → observe, do not defend → debrief immediately → iterate within 24 h. Run 2–3 full cycles. Stop-rule: "users loved it" = insufficient testing.

Output: Design Sprint Report

# Design Sprint: <challenge>
## Empathize: participants / key observations / say-do contradictions / most surprising finding
## Define HMWs: 1. <HMW> 2. <HMW> 3. <HMW> — Selected: <which and why>
## Ideate: concepts generated <n> — selected for prototyping: <3–5 descriptions>
## Prototype: concept / form / learning question: <assumption tested>
## Test: sessions / H1–H3: confirmed|disconfirmed|inconclusive + behavior / next iteration
## Recommended direction: <concept, evidence, what to build next>

→ Method in Action: GE Healthcare — Pediatric MRI Redesign (2007) → 2026 lens: Designing an AI Product That Finishes the Job, Not the Demo (2024–2026)

Empathy Packs

  • Consumer products: Go where people use the product and watch. Surveys reveal stated preferences; observation reveals actual behavior.
  • B2B / enterprise: Shadow research surfaces workarounds and parallel Excel sheets that interviews never reveal.
  • Public services: Start with extreme users — heaviest users know every workaround; non-users reveal barriers designers never imagined.

Applying It Well

  • Separate divergent/convergent modes — never evaluate during ideation; name the mode at the start of each stage.
  • The say/do gap is where insight lives — contradictions between stated needs and observed behavior are the design opportunity.
  • Prototype fidelity must match the question being asked; never invest fidelity before the concept is validated.
  • Test to learn, not to confirm — all-positive sessions mean you are not challenging the hard parts.
  • Define is the hardest stage — quality of ideation is entirely determined by quality of the HMW.

→ Primary sources: references/sources.md

Common Rationalizations

[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.

Fake moveReality
[D] "We already know our users"Even teams who shipped to millions discover gaps in fresh Empathize research. Knowing users is ongoing practice, not a historical achievement.
[D] "We ran a survey — that counts as user research"Surveys measure what users say; observation reveals what they do. Surveys without observation are assumption laundering.
[D] "The prototype needs to be high quality before testing"High fidelity at concept stage is sunk cost. Use the lowest-fidelity artifact that answers the current question.
[D] "Three of five users liked it"Three positive concept responses is not PMF evidence. Testing must challenge the concept, not sample sentiment.
[D] "Design thinking takes too long"A 4-week Empathize stage pays for itself by preventing one 3-month rebuild after shipping the wrong thing.
[D] "We did a workshop — now we're doing design thinking"A workshop is vocabulary practice; design thinking is a continuous process tied to real user research and actual iteration decisions.
[D] "We'll do user testing after we build the MVP"Highest ROI comes from testing concepts before any code is written — when iteration costs are zero.
[D] "HMW: how might we build a better app?"That is a solution disguised as a problem. A valid HMW describes a human need, not a product form.
→ Add [O] entries here after each real use — paste the actual failure patternWhat went wrong and why

Red Flags

  • No specific user observation (not survey, not analytic) drove the design direction
  • HMW question contains a solution ("how might we build X?")
  • Prototype was built to show stakeholders, not test a hypothesis
  • Testing sessions produced only positive feedback — no confusion moments recorded
  • Define stage skipped: jumped from interviews directly to solutions
  • Direction unchanged after three rounds of testing — the test is not challenging the right assumptions

Verification

  • ≥5 users directly observed (not surveyed) in Empathize
  • ≥1 say/do contradiction identified
  • HMW describes a user need, not a solution form
  • ≥20 concepts generated before any were evaluated
  • Each prototype has one explicit learning question stated before testing
  • ≥2 full test cycles (prototype → test → iterate) completed
  • Sessions recorded behavioral observations, not only user sentiment
  • Final direction traces to observed behavior, not team preference

Part of deciqAI Knowledge Skills — 233 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. See it run → https://www.deciqai.com/s/design-thinking · Built by deciqAI · github.com/deciqAI · Contributions welcome.

Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/design-thinking.json

What ships with it: 3 files

10.4 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most design frontend skills give in ~2.0k tokens

Counted across 1,169 of the 1,878 authors here whose files we hold, read 2026-08-07

  • Use CSS variables for color consistencyin 72 of 1169, across 23 files
  • Commit to one bold aesthetic direction before codingin 72 of 1169, across 27 files
  • Match implementation complexity to the aesthetic visionin 70 of 1169, across 20 files
  • Add atmospheric background effects and texturesin 57 of 1169, across 9 files
  • Use unexpected spatial compositions and layoutsin 56 of 1169, across 8 files
  • Implement real working codein 55 of 1169, across 7 files
  • Vary themes and aesthetics across different designsin 48 of 1169, across 7 files
  • Launch chromium in headless modein 47 of 1169, across 4 files
  • Close the browser when donein 47 of 1169, across 4 files
  • Run provided scripts with help flag firstin 47 of 1169, across 4 files
  • Wait for network idle statein 47 of 1169, across 4 files
  • Use descriptive selectors for elementsin 47 of 1169, across 4 files

Said here and by no other author read

  • observe real users directly in context
  • identify say and do contradictions
  • frame insights as how might we questions
  • generate over twenty concepts before converging
  • build lowest fidelity prototypes that answer current questions
  • state one explicit learning question per prototype

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,736. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.