design-thinking

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]