design-thinking — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited design-thinking (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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.
prototype briefs, usability test plans, service blueprints)
Tell Claude what phase you are in and what you need. Examples:
If you are unsure which phase you are in, describe your situation and Claude will orient you.
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.
| Phase | Core Question | Primary Output |
|---|---|---|
| Empathize | Who are these people and what do they actually experience? | Research insights, empathy maps |
| Define | What is the real problem worth solving? | POV statement, HMW questions |
| Ideate | What are all possible ways to solve this? | Solution concepts, decision rationale |
| Prototype | What is the cheapest version we can learn from? | Prototype artifact (any fidelity) |
| Test | Does this work for real people? | Validated insights, iteration priorities |
| Implement | How do we get this to users? | Shipped solution, adoption plan |
Every design decision should balance:
❌ 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.
These are not soft aspirations — they are active operating principles:
The phases are not a waterfall. Expect and plan for:
❌ 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
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.
User Interviews
One-on-one conversations focused on past behavior, not hypothetical preferences.
Session structure:
Good interview questions:
Bad interview questions:
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:
| Says | Thinks |
|---|---|
| Direct quotes from research | Beliefs and assumptions they hold (inferred) |
| Does | Feels |
| Observed behaviors and actions | Emotional state throughout the experience |
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.
❌ 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
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.
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:
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:
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:
From the caregiver example:
Not these:
Generate 5–15 HMW questions per POV, then vote or sort by potential impact.
❌ 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
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.
Brainstorming
Ground rules that make it work:
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:
Brainwrite (6-3-5 Method)
Better than verbal brainstorming for remote teams and introverted participants:
Convergence Methods
After generating, use structured selection — not discussion:
❌ 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
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.
| Type | Fidelity | Best For | Time to Build |
|---|---|---|---|
| Paper sketch | Very low | Testing layout, navigation concepts | 30 min |
| Paper prototype | Low | Testing interaction patterns and flows | 2–4 hours |
| Wireframe | Low–medium | Testing information architecture | 4–8 hours |
| Storyboard | Low | Testing a service concept or multi-channel journey | 2–4 hours |
| Clickable prototype | Medium | Testing task flows end-to-end | 1–3 days |
| Visual mockup | High | Testing aesthetics, messaging, first impressions | 1–3 days |
| Interactive prototype | High | Testing micro-interactions and animation | 2–5 days |
| Service blueprint | Low–medium | Mapping frontstage and backstage of a service | 4–8 hours |
| Wizard of Oz | Any | Simulating an experience before it is built | Variable |
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.
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.
→ See [reference/service-design.md](reference/service-design.md) for service blueprint, journey map, and ecosystem map templates.
❌ 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
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.
Moderated Usability Testing
Session structure:
Facilitator rules:
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:
Not appropriate for: early-stage concept validation, or anything requiring qualitative understanding of why behavior occurs.
Severity classification:
| Finding | Response |
|---|---|
| Critical issues in core flow | Return to Prototype — fix before testing again |
| Problem statement was wrong | Return to Define — reframe before ideating |
| Concept is fundamentally flawed | Return to Ideate — explore other directions |
| Moderate issues with clear solutions | Fix in next iteration, then move forward |
| Minor issues only | Document for backlog, proceed to Implement |
❌ 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
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.
Design Handoff
Documentation that ensures design intent survives implementation:
Implementation Review
Walk through every user flow in the live build:
Post-Launch Learning
The shipped product is a new source of research data — the beginning of the next iteration cycle:
❌ 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
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.
UX Researchers Your strength is the Empathize and Define phases. Push for investment there.
UI Designers Design Thinking gives you a mandate to push back on solutions that arrive before problems are understood.
Product Managers Design Thinking reframes roadmap decisions as problem-first rather than feature-first.
Service Designers The six-phase model applies to service design with expanded scope and artifact types.
→ See [reference/service-design.md](reference/service-design.md) for service-specific templates.
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)
Validating before investing (pre-launch)
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:
Design Thinking by startup stage
| Stage | Priority phases | Compressed time | Key output |
|---|---|---|---|
| Idea | Empathize + Define | 1–2 weeks | POV statement backed by 15+ interviews |
| Pre-launch | Ideate + Prototype | 1–2 weeks | Landing page / Wizard of Oz / paper prototype |
| Post-launch | Test + Implement | Ongoing | Behavioral data + iteration cycles |
| Scale | All phases, abbreviated | Per sprint | Validated features, not assumption-driven roadmap |
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](reference/facilitation-methods.md) for complete workshop facilitation scripts.
Principles for executive-sponsored innovation work:
Service redesign at enterprise scale
When redesigning a customer-facing service:
Business model innovation through the three lenses
When using Design Thinking for business model questions:
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
Invest disproportionately in Empathize and Define. This is where new products fail most often.
Priority order:
Warning signs you are shortcutting:
Start from behavioral evidence — you already have it.
Priority order:
The scope spans more actors, channels, and organizational complexity than product design.
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](reference/facilitation-methods.md) for detailed day-by-day agenda.
❌ 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.
❌ 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.
❌ 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.
❌ 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.
❌ 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.
❌ 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.
When this skill is active, Claude will adapt output to what you need:
A structured plan for the requested phase:
The requested artifact (empathy map, POV statement, HMW questions, test script, etc.) as:
Evaluation of your design work against the methodology:
A session plan with:
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.