Stats
Actions
Tags
From skills-for-humanity
Uses jobs-to-be-done and latent need mapping to distinguish real needs from stated wants. Triggers on phrases like 'what do users actually need' or 'user research'.
How this skill is triggered — by the user, by Claude, or both
Slash command
/skills-for-humanity:s4h-design-user-needsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The most common design failure is building the wrong thing well. People don't articulate needs — they articulate solutions. "I want a faster horse," "I need a bigger inbox," "give me more options." These are requests framed as solutions to problems the user hasn't quite stated. A designer who takes them at face value will build a faster horse, a bigger inbox, more options — and miss the underly...
The most common design failure is building the wrong thing well. People don't articulate needs — they articulate solutions. "I want a faster horse," "I need a bigger inbox," "give me more options." These are requests framed as solutions to problems the user hasn't quite stated. A designer who takes them at face value will build a faster horse, a bigger inbox, more options — and miss the underlying need entirely.
Clayton Christensen's jobs-to-be-done framework makes the shift explicit: people don't buy products, they hire them to do a job. Understanding the job — not the product request — is the designer's actual brief. Don Norman extended this with the distinction between stated needs (what people say), observed needs (what people do), and latent needs (what people don't yet know they need but would recognise immediately if you showed them). All three matter. Only one of them is given to you directly.
This skill works through all three levels, using structured inquiry to separate the real need from the stated proxy and surface the design target that actually matters.
Step 1: State the Request Write down exactly what was asked for, in the words it was stated. Preserve the phrasing — the precise language reveals how the person is framing the problem.
Framing check: Confirm the request and the context in which it arose before continuing. State what you've identified — the stated request and the situation it comes from — in one sentence, then use AskUserQuestion:
Step 2: Decompose the Job Apply jobs-to-be-done decomposition. For the stated request, identify:
All three jobs are real design requirements. Ignoring emotional and social jobs produces functional things people don't use.
Step 3: Trace the Context Map the situation in which this job arises. When does it occur? What triggers it? What has the person tried before? What is the current workaround, and what does that workaround reveal about what they've accepted as good enough? The workaround is a latent needs signal — it shows what people will tolerate, which implies what they'd choose if offered something better.
Step 4: Separate Stated Want from Real Need For each element of the stated request, ask: is this a solution (a specific form) or a need (an outcome)? Solutions can usually be restated as needs. "I want a dashboard" → "I need to see the status of multiple things at once without searching." "I want notifications turned off" → "I need to control when I give attention to requests from others."
Restate every solution-framed element as a need-framed one.
Step 5: Surface Latent Needs Latent needs are not stated because people haven't conceptualised them as possible. They emerge from:
List candidate latent needs. Mark confidence level for each.
Before proceeding, use the AskUserQuestion tool. State your interpretation of the situation in 1–2 sentences — what is the design context and what job category is most important here — then ask:
Proceed based on their selection. If the user reframes, incorporate the correction before running any analysis.
Stated request:
[Exact wording]
Jobs-to-be-done:
| Job type | Description |
|---|---|
| Functional | [What they're trying to accomplish] |
| Emotional | [How they want to feel] |
| Social | [How they want to be perceived] |
Current workaround and what it reveals: [Describe the workaround. What it implies about accepted tolerances and unmet needs.]
Stated want → Real need:
| Stated as (solution) | Restated as (need) |
|---|---|
| [Solution framing] | [Need framing] |
Latent needs:
Design target:
[The core need, stated precisely. One to two sentences. This is what design should solve against.]
The most common mistake here is conflating the emotional job with sentiment — "they want to feel happy." The emotional job is more specific: they want to feel in control, competent, not embarrassed, trusted, efficient. These are designable. Vague emotional goals aren't.
This skill pairs naturally with /s4h-design-constraints — once the real need is stated, the next question is what constraints define the solution space. It also precedes /s4h-design-iteration, which structures the testing loop once a design direction exists. For broader audience analysis — who is this for, and how do different groups differ — see /s4h-communication-audience-modeling.
After delivering this output, use AskUserQuestion to offer the next move:
/s4h-design-constraints — Map the constraints that define what solutions are actually possible/s4h-design-iteration — Structure the cycle of prototyping and testing against these needs/s4h-creativity-brainstorm — Generate solution directions now that the real need is clearnpx claudepluginhub human-avatar/skills-for-humanityMaps user jobs-to-be-done across functional, emotional, social dimensions, stages, outcomes, and solutions to identify product opportunities.
Maps user Jobs to be Done across functional, emotional, and social dimensions using Christensen's theory. Guides interview discovery, opportunity scoring, and YAML output.
Analyzes customer research or product context to uncover functional, social, and emotional jobs to be done. Identifies pains, gains, prioritizes jobs, and suggests product implications.