Design Thinking

Design Thinking

A practical guide to the Design Thinking methodology for product designers, UX researchers, UI designers, service designers, product managers, entrepreneurs, and business leaders. This skill helps you move through human-centered design work with rigor — from understanding real people to shipping solutions that reach them.

What This Skill Covers

• Running or planning any phase of a Design Thinking process
• Generating and evaluating design artifacts (empathy maps, HMW questions, POV statements, prototype briefs, usability test plans, service blueprints)
• Adapting the methodology to your role and context (new product, existing product, service, startup, innovation workshop)
• Facilitating cross-functional collaboration with shared language
• Avoiding the methodology errors that produce poor — or irrelevant — outcomes

How to Use This Skill

Tell Claude what phase you are in and what you need. Examples:

• "I need to plan empathy interviews for a mobile banking redesign"
• "Here are my research findings — help me synthesize into a problem statement"
• "We're about to ideate — what methods work best for a 90-minute remote session?"
• "I'm a founder — how do I validate my idea before I build anything?"
• "We're running a strategy workshop on service redesign — where do we start?"

If you are unsure which phase you are in, describe your situation and Claude will orient you.

The Design Thinking Framework

Design Thinking is a non-linear, human-centered approach to problem-solving. It is a proven framework for keeping human needs at the center of every decision — from the first user conversation to the final shipped solution. It is not a checklist — it is a flexible scaffold for keeping teams oriented around real human needs at every stage of the work.

The Six Phases

The Three Lenses

Every design decision should balance:

• Desirability — Do people want this? Does it fit their lives and actual needs?
• Feasibility — Can it be built? What does technology currently allow?
• Viability — Is it sustainable? Does it make economic and organizational sense?

❌ Designing only for desirability without feasibility produces beautiful concepts that cannot be built. ❌ Designing only for viability produces business-first solutions users do not want. ✅ Strong design lives at the intersection of all three lenses.

Designer's Mindset

These are not soft aspirations — they are active operating principles:

• Empathy: Suspend your own perspective. Your experience of the problem is not the user's.
• Beginner's mind: Approach each project without assuming you already know the answer. Curiosity before conclusions.
• Optimism: Believe a better solution exists, even when none is obvious yet.
• Comfort with ambiguity: Stay in the problem longer than feels comfortable. Rushing Define leads to solving the wrong thing.
• Bias toward action: Prototypes beat arguments. Build to learn, not to present.
• Willingness to fail early: A failed paper prototype costs an afternoon. A failed shipped product costs far more.

The Non-Linear Process

The phases are not a waterfall. Expect and plan for:

• Looping from Test back to Define when your problem statement was wrong
• Looping from Prototype back to Ideate when a concept is fundamentally flawed
• Running Empathize activities during Test when new behaviors surface
• Returning to Empathize after Define when insights reveal gaps in your research

❌ Treating Design Thinking as a checklist to complete exactly once ✅ Treating it as a shared language that lets the team know where they are at any moment

Stage 1: Empathize

Purpose

Deeply understand the people you are designing for — their behaviors, motivations, pain points, context, and emotional experience. This is not market research about segments. It is observation and conversation with individual humans in real situations.

When You Are Here

• Starting a new product, feature, or service from scratch
• Investigating why an existing feature has low adoption or high abandonment
• Redesigning a system that has friction you do not fully understand
• Your team is making decisions based on assumptions, not direct evidence

Core Activities

User Interviews

One-on-one conversations focused on past behavior, not hypothetical preferences.

Session structure:

1. Warm-up (5 min) — context, rapport, informed consent
2. Grand tour questions (15–20 min) — "Walk me through the last time you..."
3. Probing (15–20 min) — "Why did you do that? What were you hoping would happen? How did that make you feel?"
4. Closing (5 min) — "What would ideal look like? Is there anything I should have asked?"

Good interview questions:

• "Tell me about the last time you [did the thing you're designing for]."
• "What were you trying to accomplish when that happened?"
• "What did you do when [problem] occurred?"
• "What surprised you about that experience?"

Bad interview questions:

• "Would you use a feature that did X?" — hypothetical, not behavioral
• "Do you like [existing product]?" — opinion, not behavior
• "How often do you [behavior]?" — quantitative without context

Field Observation (Ethnographic Research)

Watch people in their actual environment. What people do often differs sharply from what they say they do.

Observe: physical space, tools used, workarounds invented, interruptions, social context, the actual sequence of actions taken.

Empathy Maps

A synthesis tool using four quadrants:

Expert Consultation

Interview domain experts — doctors, teachers, customer service agents, field workers — not as a substitute for user research, but as context for interpreting what you observe.

Key Questions

• What do users actually do, not what do they say they do?
• What is the emotional texture of their experience — where do they feel frustrated, confused, or relieved?
• What context shapes their behavior? (Time pressure, environment, device, social setting)
• What workarounds have they invented? (Workarounds signal unmet needs.)
• Who are the extreme users — power users, non-users, people who tried and quit?

Outputs

• Raw research notes with direct quotes (not paraphrased)
• Empathy maps per user archetype
• List of raw observations (do not synthesize yet — that is Define's job)
• Identified tensions and contradictions to explore

Common Mistakes

❌ Interviewing colleagues or friends as proxies for real users — they know too much ❌ Asking leading questions ("Don't you find it frustrating when...?") ❌ Only talking to existing happy customers — you miss the people who gave up ❌ Skipping this phase because "we already know our users" ❌ Summarizing or interpreting notes immediately — wait until you have enough data to see patterns ✅ Recruit a mix: power users, casual users, non-users, people who tried and quit ✅ 5–8 interviews typically surface the major themes in a well-scoped problem

Stage 2: Define

Purpose

Synthesize your research into a clear, specific, human-centered problem statement. Define is consistently the most underinvested phase. Teams rush to ideate before they have agreed on what they are solving. A weak Define produces scattered, off-target ideas that don't hold up to scrutiny.

When You Are Here

• You have completed research and have raw observations
• Your team has competing interpretations of what the research means
• You have a vague brief like "improve the onboarding experience"
• People are jumping straight to solutions before understanding the problem

Core Activities

Affinity Diagramming

Group raw observations into emergent themes. Use sticky notes (physical or digital). Do not pre-define categories — let them emerge from the data.

Process:

1. Write one observation per note (behavioral, not interpreted)
2. Cluster silently — move notes without discussion first
3. Name the clusters using descriptive phrases, not labels
4. Identify tensions: clusters that contradict each other are often your most important insights

Point of View (POV) Statement

Template: [User description] needs [need] because [insight].

Strong example:

"A part-time caregiver for an elderly parent needs to confirm medication was given remotely because they manage care from multiple locations and cannot be physically present at every dose."

Weak patterns to avoid:

• "Users need a better dashboard." — solution-adjacent, not a need
• "Customers need more features." — business framing, not human-centered
• "Young professionals need to save money." — too broad, no insight

Test your POV: Can your team generate ten meaningfully different ideas from it? If not, it is not specific enough yet.

How Might We (HMW) Questions

Transform your POV statement into ideation prompts. Good HMW questions are:

• Broad enough to allow genuinely different solutions
• Specific enough to exclude irrelevant directions
• Human-centered, not solution-prescribing

From the caregiver example:

• "HMW help caregivers confirm that medication was given when they were not present?"
• "HMW reduce the cognitive load of tracking medications across multiple handoffs?"
• "HMW make medication history easy to review at a glance for a non-technical user?"

Not these:

• "HMW build a medication tracking app?" — solution-prescribing
• "HMW improve health outcomes?" — too broad to generate a useful idea

Generate 5–15 HMW questions per POV, then vote or sort by potential impact.

Key Questions

• What is the single most important problem this user faces?
• Is our problem statement human-centered or business-centered?
• What is the insight — not just the observation — behind the need?
• What are we explicitly NOT solving? (Scope matters as much as scope-in.)
• Would our user recognize this problem statement as their own?

Outputs

• Affinity diagram with named clusters
• 1–3 POV statements (one per key user archetype)
• 5–15 HMW questions per POV, prioritized
• Explicit scope boundary: what is in, what is out

Common Mistakes

❌ Writing a problem statement that contains a solution ("users need a notification system") ❌ Writing from the business perspective ("we need to increase retention by 15%") ❌ Skipping affinity diagramming and jumping straight from raw notes to a POV — the synthesis step is where insight happens ❌ Creating too many HMW questions and ideating on all of them — pick 2–3 high-priority ones ✅ A strong POV creates slight team discomfort — it is specific enough to rule out ideas you were excited about ✅ If your HMW question has only one obvious answer, it is too narrow

Stage 3: Ideate

Purpose

Generate a wide range of possible solutions before converging on any. Volume and variety first — judgment later. The goal of ideation is to exhaust the obvious ideas quickly so the team reaches the unexpected ones.

When You Are Here

• You have clear HMW questions to ideate against
• The team has silently converged on one solution and needs to break out of it
• A design direction is stuck and needs fresh input
• You are running a design sprint and need structured divergence

Core Methods

Brainstorming

Ground rules that make it work:

• Defer judgment — no criticism during generation, even "yes, but"
• Build on others' ideas — "yes, and..." not "yes, but..."
• Aim for quantity — set a number target (50 ideas in 20 minutes)
• Encourage wild ideas — outrageous ideas often contain the seed of practical ones
• Stay visual — sketch alongside writing

Worst Possible Idea

Generate deliberately terrible solutions first. This lowers inhibition, creates psychological safety, and often surfaces useful ideas through inversion.

Example HMW: "Help caregivers track medication remotely." Worst ideas: "Put a camera in every pill bottle." "Require a phone call every hour." Inversion: The phone-call idea suggests: what if there was a minimal confirmation mechanism that required no tech setup from the patient?

SCAMPER

Apply six transformations to an existing concept or product:

• Substitute — What could be replaced?
• Combine — What could be merged with something else?
• Adapt — What could be borrowed from a completely different context?
• Modify / Magnify / Minify — What could change in scale, emphasis, or form?
• Put to other uses — What else could this do?
• Eliminate — What could be removed entirely?
• Reverse / Rearrange — What if the order or structure changed?

Brainwrite (6-3-5 Method)

Better than verbal brainstorming for remote teams and introverted participants:

• 6 people each write 3 ideas in 5 minutes
• Pass sheets clockwise — build on ideas you receive
• 6 rounds = theoretically 108 ideas in 30 minutes

Convergence Methods

After generating, use structured selection — not discussion:

• Dot voting: each person gets 3–5 votes, vote silently, tally, then discuss the top ideas
• 2×2 matrix: plot ideas against user impact vs. implementation feasibility
• Rose, Bud, Thorn: for each idea — what is working (rose), what has potential (bud), what is a concern (thorn)

Key Questions

• Are we generating across the full solution space or anchoring on one familiar direction?
• Have we generated enough ideas to be confident we are not missing something?
• Is everyone contributing, or are dominant voices narrowing the range?
• Are we deferring judgment or evaluating during generation?

Outputs

• 30–100+ raw ideas (quantity is the explicit goal)
• Top 3–5 concepts selected through structured convergence, not consensus
• Brief rationale for each selected concept: why it is worth prototyping
• Notes on deprioritized ideas that showed promise (for later reference)

Common Mistakes

❌ Stopping at the first viable idea — familiarity bias makes the first idea feel better than it is ❌ Evaluating ideas during brainstorming — this kills psychological safety and narrows the divergence phase ❌ Only ideating within the current product paradigm — the best solution might look nothing like the existing one ❌ Running ideation without a warm-up activity — 5 minutes of warm-up dramatically improves output quality ✅ Run divergence and convergence as separate sessions — mixing them produces mediocre compromise solutions ✅ The person who generated an idea should not be its sole advocate — separate ideas from identities

Stage 4: Prototype

Purpose

Build the cheapest, fastest version of a concept that lets you learn something real. A prototype is not a final product — it is a question made tangible. Every prototype should be designed to answer one specific question, stated in advance.

When You Are Here

• You have 1–3 concepts worth investigating
• You need to test an assumption before investing in development
• You need to communicate a concept to stakeholders or engineers
• You are iterating on an existing design that is not performing

Prototype Fidelity Table

The fidelity trap: High-fidelity prototypes look finished, which leads users to give feedback on visual polish rather than the concept. Use the lowest fidelity that still tests your hypothesis.

Prototype Principles

State the question before building Before building anything, write: "This prototype is designed to answer: ___." If you cannot fill in that blank, you are not ready to prototype.

Build to learn, not to present A prototype that gets challenged in testing is a success — you learned what doesn't work cheaply. A prototype that confirms your assumptions without surfacing new insight is the real failure.

Make it tangible fast If you spend more than a day deciding how to prototype, start with paper. You can always increase fidelity after you have learned something.

Annotate your assumptions Note which parts of the prototype represent real behavior and which are placeholders. "This content is assumed to be dynamically generated" matters for test interpretation.

Build parallel prototypes When you have competing concepts, prototype both simultaneously rather than investing deeply in one. Let testing decide, not consensus.

Service Design Artifacts

→ See reference/service-design.md for service blueprint, journey map, and ecosystem map templates.

Key Questions

• What specific question or assumption will this prototype test?
• What is the minimum we need to build to answer that question?
• Are we going higher fidelity than necessary — and why?
• Are we building this to learn, or to impress stakeholders?

Outputs

• Prototype artifact (paper, digital, or physical — matched to fidelity needed)
• Prototype brief: the question it answers, assumptions it makes, what it deliberately excludes
• Test script prepared before testing begins

Common Mistakes

❌ Prototyping the solution you hope to build, not the one that tests your riskiest assumption ❌ Over-investing in fidelity before validating the concept ❌ Presenting prototypes to stakeholders as the "answer" before testing them with users ❌ Designing prototypes that can only succeed — include failure states and edge cases ✅ Build multiple parallel low-fidelity prototypes rather than one polished prototype of one concept ✅ If your prototype cannot fail in testing, it is not testing anything real

Stage 5: Test

Purpose

Observe real users interacting with your prototype. Gather behavioral evidence — not opinions. The goal is to validate or invalidate your assumptions, not to confirm that your design is good.

When You Are Here

• You have a prototype and a specific question to answer
• You need behavioral evidence before committing to a design direction
• An existing feature is underperforming and you do not know why
• You have two competing solutions and need to choose between them

Core Methods

Moderated Usability Testing

Session structure:

1. Welcome and informed consent (5 min)
2. Warm-up — context about the participant (5 min)
3. Scenario and tasks (20–40 min)
4. Debrief — what felt easy, what felt hard, open questions (10 min)

Facilitator rules:

• Give tasks as scenarios, not instructions: "You need to change your delivery address" not "Click Settings"
• Do not help — silence is uncomfortable but the discomfort is the data
• Ask "What are you thinking right now?" not "Is this confusing?"
• Take notes on behavior, not interpretation: "paused 8 seconds before clicking" not "seemed confused"

Participant count: 5 participants typically surface 85% of usability issues in a well-scoped test. Test with 5, fix major issues, test again with 5 more.

Think-Aloud Protocol

Ask participants to narrate their thoughts continuously as they interact:

"Please say out loud what you are thinking, even if it seems obvious. There are no wrong answers — we are testing the design, not you."

This surfaces mental model mismatches — where users expect something different from what the design delivers.

Unmoderated Remote Testing

Participants complete tasks independently, recorded via tools. Useful for scale (10–100 participants) and removing facilitator bias. Trade-off: you cannot probe unexpected behavior in the moment.

A/B Testing

Appropriate when:

• You have a clear behavioral success metric
• Traffic volume is sufficient for statistical significance
• The change is isolated enough to attribute differences to the variable

Not appropriate for: early-stage concept validation, or anything requiring qualitative understanding of why behavior occurs.

Synthesizing Test Findings

1. Write one observation per note (behavioral, not interpretive)
2. Group by task or screen
3. For each issue, note: severity, frequency, and direction (not solution)

Severity classification:

• Critical: prevents task completion or causes significant distress
• Moderate: significant difficulty, participant eventually recovers
• Minor: slight friction, participant succeeds without notable difficulty

Iterate vs. Proceed Decision Table

Key Questions

• Are we testing the right thing with the right participants?
• Are we observing behavior or collecting opinions?
• What specific finding would cause us to change direction vs. proceed?
• Are we testing to validate our design, or genuinely to learn?

Outputs

• Session recordings and behavioral notes (not summaries)
• Synthesis of findings organized by severity and frequency
• Explicit decision: iterate on prototype, loop to earlier phase, or proceed to Implement

Common Mistakes

❌ Asking "Do you like this?" — preference is not behavior ❌ Testing with people who are motivated to help you — they will not break your design the way a real user will ❌ Testing with 1–2 people and treating findings as conclusive ❌ Helping participants when they struggle — the struggle is the signal ❌ Gathering feedback and not acting on it — "testing theater" ✅ Invite the broader team to watch live sessions — nothing is more persuasive than watching a user struggle with something you built ✅ Separate observation from interpretation in notes — write what you saw before you write what it means

Stage 6: Implement

Purpose

Ensure the solution actually reaches users. Implementation is the most frequently omitted phase of Design Thinking. A solution that exists only as a file has no impact on anyone. The methodology ends when the solution reaches real people — not when the work is handed off.

When You Are Here

• You have a validated concept ready for development
• You are preparing a design handoff to engineering
• You are tracking whether the shipped product matches the design intent
• You are planning post-launch learning cycles

Core Activities

Design Handoff

Documentation that ensures design intent survives implementation:

• Behavioral annotations: what elements do, not just how they look
• Edge cases: empty states, error states, loading states, long content
• Interaction notes: animation, transitions, feedback timing
• Accessibility requirements: contrast ratios, focus order, ARIA labels
• Responsive behavior: what changes at each breakpoint

Implementation Review

Walk through every user flow in the live build:

• Verify edge cases were implemented, not just happy paths
• Check accessibility requirements are met in the build
• Document deviations and decide: fix now, fix later, or accept

Post-Launch Learning

The shipped product is a new source of research data — the beginning of the next iteration cycle:

• Instrument before launch: analytics, event tracking, error logging
• Define success metrics tied to the original problem statement (not vanity metrics)
• Plan a post-launch usability review at 2–4 weeks
• Use behavioral data to identify where to loop back to Empathize or Define

Key Questions

• Does the built product match the tested prototype in the ways that matter?
• Have we defined what success looks like in behavioral terms?
• How will we know if users are experiencing the problem we designed to solve?
• What is the trigger condition for the next iteration cycle?

Outputs

• Handoff documentation with behavioral annotations and edge cases
• Implementation review findings
• Post-launch success metrics tied to the original POV statement
• Next iteration trigger conditions

Common Mistakes

❌ Treating launch as the end — it is the beginning of the next research cycle ❌ Not instrumenting before launch — you cannot learn from data you didn't collect ❌ Handing off a visual spec without behavioral annotations — engineers implement what they understand, not what they infer ❌ Setting success metrics after launch — define them before, anchored to the problem statement ✅ Schedule a post-launch review date before you ship, not after

Role-Specific Application

Product & Design Teams

Product Designers Your primary challenge is balancing depth of process with sprint velocity. Design Thinking gives you the tools — your judgment determines which tools fit the timeline.

• In early-stage work: invest heavily in Empathize and Define. The cost of a wrong problem statement is enormous.
• In sprint cycles: run abbreviated versions. A 45-minute interview round and a 30-minute synthesis session still beats pure assumption.
• In critiques: use the three lenses (desirability, feasibility, viability) to structure feedback that goes beyond aesthetics.
• Anchor design decisions back to the POV statement. "This solves the caregiver coordination problem" is more persuasive to stakeholders than "this feels right."

UX Researchers Your strength is the Empathize and Define phases. Push for investment there.

• Frame research as risk reduction: "Two days of interviews prevents six months building the wrong thing."
• Make research artifacts visible: post empathy maps and affinity diagrams where PMs and engineers will encounter them.
• During Ideate, bring research artifacts into the room. Anchor idea evaluation to observed behavior, not team preference.
• During Test, prioritize behavioral evidence over stated preference. "Three users abandoned the flow at this step" is more actionable than "users said they liked the concept."

UI Designers Design Thinking gives you a mandate to push back on solutions that arrive before problems are understood.

• Challenge briefs that arrive as solutions: "Before I design this dashboard, what is the problem statement behind it?"
• Match prototype fidelity to the question being tested. Do not go high-fidelity until the concept is validated.
• During Test, note which visual decisions participants do not react to — those may not be solving the right problems.
• Post-launch, connect visual hierarchy decisions to behavioral flow data. Did users navigate the intended path?

Product Managers Design Thinking reframes roadmap decisions as problem-first rather than feature-first.

• Use the POV statement to evaluate feature requests: "Does this address the defined user need, or does it address a different problem?"
• Before committing to a solution in planning, ask: have we run Empathize and Define? If not, add them to the sprint.
• Use HMW questions to open up solution space in planning discussions before committing to specific features.
• Connect OKRs and success metrics to the POV statement — not to the solution.

Service Designers The six-phase model applies to service design with expanded scope and artifact types.

• Empathize with all actors: end users, frontline staff, back-office teams, and partner organizations. Frontline staff experience matters as much as customer experience.
• Define at the system level: HMW questions should address handoffs between actors and channels.
• Prototype using service-specific tools: blueprints, desktop walkthroughs, role-play simulations.
• Implement with change management: service changes require training, process changes, and organizational alignment — not just a product deployment. → See reference/service-design.md for service-specific templates.

Entrepreneurs & Startups

Design Thinking maps directly to lean startup methodology. The process you already know — Build-Measure-Learn — is Prototype → Test → Iterate. Design Thinking adds the critical upstream work that lean startup often skips: Empathize and Define.

Before you build anything (idea stage)

• Run problem interviews (Empathize), not solution interviews. Your job is to confirm the problem exists and is painful, not to pitch your solution.
• A good problem interview question: "Tell me about the last time you experienced [problem]. What did you do?"
• A bad problem interview: "Would you use a product that did X?"
• Target: 20+ problem interviews before writing a line of code or designing a single screen.

Validating before investing (pre-launch)

• Write your POV statement. If you cannot write one that a potential customer would recognize, you have not done enough research.
• Run Ideate and Prototype with paper or a landing page. Measure click-through and sign-up intent before building.
• Wizard of Oz prototypes: simulate the experience manually before automating it. If manual simulation doesn't work, automation won't save it.

Founder bias: the startup-specific failure mode The most dangerous assumption in a startup is: "I am the user." Founders build what they would want, not what the target user needs. The gap between those is where most startups fail.

Protect against this:

• Never count yourself as a research participant
• When you disagree with user feedback, write it down before dismissing it
• Track how often your assumptions are confirmed vs. disconfirmed in testing

Design Thinking by startup stage

Business & Strategy Leaders

Design Thinking is the methodology behind the most successful corporate innovation programs. The same process that product teams use to design features, executives use to redesign services, reimagine business models, and align organizations around customer needs.

Reframing business problems as human-centered problems

Most strategic problems arrive pre-framed as business goals:

"Increase customer retention by 12%." "Reduce service call volume." "Expand into the SMB segment."

Design Thinking reframes these as human-centered problems before generating solutions:

"Customers who don't experience value in the first 30 days cancel before the potential of the product is visible to them." "Customers call because they cannot resolve issues through self-service — the interface creates uncertainty, not confidence."

This reframing is not semantic. It determines the entire solution space.

Using Design Thinking in innovation workshops → See reference/facilitation-methods.md for complete workshop facilitation scripts.

Principles for executive-sponsored innovation work:

• The sponsor should participate in Empathize, not just receive the report. Watching a customer struggle firsthand changes decisions.
• Protect the Ideate phase from premature convergence. Executives have authority that collapses a brainstorm if they signal preference too early.
• Define success metrics before the workshop, tied to the POV statement — not to the number of ideas generated.

Service redesign at enterprise scale

When redesigning a customer-facing service:

• Map the full customer journey across all touchpoints and channels before designing any single touchpoint.
• Backstage matters as much as frontstage. A customer experience that fails is usually a process or organizational failure that becomes visible to the customer.
• Pilot before you scale. A service change that works in one region may fail in another due to local context.

Business model innovation through the three lenses

When using Design Thinking for business model questions:

• Desirability: What do customers actually want that they are not getting from any existing option?
• Feasibility: What capabilities does the organization currently have that could deliver this?
• Viability: What business model makes delivering this sustainable?

Use the three-lens framework as the starting point for any strategy session — the strongest innovation opportunities live at the intersection of all three.

Common executive failure modes

❌ Defining the solution before running Empathize and Define — "We need a mobile app" before "what problem are we solving for whom?" ❌ Treating the innovation workshop as the deliverable — the output of a workshop is a validated direction, not a strategy ❌ Skipping Test — "We know our customers" is the most expensive assumption in business ❌ Not sponsoring implementation — the idea-to-reality gap is where most innovation dies ✅ Treat the first year of a new initiative as a series of prototypes and tests, not a committed roadmap

Project Context Guide

New Product / Venture

Invest disproportionately in Empathize and Define. This is where new products fail most often.

Priority order:

1. Empathize and Define — get the problem right before generating any solutions
2. Ideate broadly — new products have the most design latitude, do not converge early
3. Prototype at low fidelity for the first two rounds
4. Test concept validity before usability — does anyone want this?
5. Treat the first version as a research tool, not a finished product

Warning signs you are shortcutting:

• Your team is debating features before you have written a POV statement
• Your "research" consists only of competitive analysis
• Your first prototype already looks like a finished product

Existing Product Improvement

Start from behavioral evidence — you already have it.

Priority order:

1. Start Empathize from behavioral data: analytics, support tickets, NPS verbatims, session recordings. Use this to scope where to do interviews.
2. Define the specific friction point, not the general area. "Users abandon checkout at the address step when they have a non-standard delivery address" beats "improve checkout."
3. Ideate with constraints — you are designing within an existing system. HMW questions should acknowledge the context.
4. Prototype at the fidelity of the surrounding product — users will notice incongruence.
5. Test against the baseline metric that identified the problem.

Service / Business Redesign

The scope spans more actors, channels, and organizational complexity than product design.

• Empathize with all actors, not just end users. Frontline staff who deliver the service are co-designers, not just implementers.
• Define at the system level — address handoffs, not just touchpoints.
• Prototype includes organizational processes, not just customer-facing interfaces.
• Test with staged pilots, not just usability sessions.
• Implement requires change management — training, incentive alignment, process documentation.

Innovation Workshop (1–3 days)

A compressed version of the full process. The facilitation goal is shared insight and direction, not a finished solution.

Day 1: Empathize (share research, build empathy) + Define (affinity diagram, POV, HMW) Day 2: Ideate (brainstorm against HMW questions, converge to top 3 concepts) Day 3: Prototype (paper or rough digital) + Test (internal critique or hallway testing)

Output: Validated direction with a clear POV statement and a prototype to test further. → See reference/facilitation-methods.md for detailed day-by-day agenda.

Common Mistakes and Anti-Patterns

Phase Skipping

❌ Going directly from a brief to Ideate without Empathize or Define This is the most common failure mode. Teams enter ideation loaded with assumptions. Every hour in Empathize and Define saves days in rework.

❌ Treating Implement as "engineering's problem" Design ends when users have access to the solution, not when the file is handed off. Designers who stay engaged through implementation ship better products.

Research Errors

❌ Interviewing colleagues, friends, or team members as research participants People who know your company, product, or you will not give you unbiased behavior data.

❌ Treating survey data as behavioral evidence Surveys tell you what people say. Observation and interviews tell you what people do. These frequently diverge.

❌ Synthesizing before you have enough data Five interviews are typically sufficient. One or two is pattern-matching on anecdote.

Define Errors

❌ A problem statement that contains a solution "Users need a notification system" is a solution. "Users miss critical updates during high-volume periods" is a problem. Only the second is worth ideating from.

❌ A problem statement framed around business metrics "We need to increase retention" is a business goal. "Users who don't experience value in the first week give up before the product's potential is visible" is a human insight. The second generates better solutions.

Ideation Errors

❌ Converging on the first viable idea The first viable idea is almost never the best. It is the most familiar.

❌ The senior person in the room signals preference during brainstorming Authority collapses divergence. Separate idea generation from evaluation, and ask leaders to contribute ideas without signaling preference.

Prototype and Test Errors

❌ Building a prototype designed to succeed A prototype that cannot fail is not testing anything real.

❌ Testing with people who want to help you Friends, family, and colleagues will not stress-test your design the way a real user will.

❌ Gathering qualitative feedback from 30 people in one round Beyond 5–8 participants, qualitative research yields diminishing returns. Run multiple small test rounds instead.

Mindset Errors

❌ Treating Design Thinking as a rigid sequence The loop-back is not failure — it is the methodology working as intended.

❌ Using the process language without the substance Running a 20-minute "ideation session" without HMW questions, warm-up, or judgment deferral is not ideation. It is a meeting with sticky notes.

❌ Treating the process as the deliverable "We did Design Thinking" produces no value. The insight, the validated concept, and the shipped solution produce value.

Output Format

When this skill is active, Claude will adapt output to what you need:

Phase Planning

A structured plan for the requested phase:

• Goals for thi

…(truncated)