/layers-user-needs

Assumes /layers-intro has been loaded. This skill is a library of techniques, not a script — see “How to use these skills” there.

User needs are what we think users are trying to achieve, and why — an interpretation built on observed behaviour and domain knowledge, not a direct capture of reality. This layer sits between the messy raw material of observation and the deliberate decisions of the solution space.

The outputs here are opportunities: needs (what users want to achieve), pains (what causes friction), and desires (improvements they’d value). All three are valid — elicit all three.

---

The decisions this layer makes

• Who exactly the users are whose needs we’re defining — and in what situation
• What jobs they’re trying to do: functional, emotional, and social
• Which needs are grounded in evidence, and which are assumptions
• Which needs matter most, and why

If the needs are already clear and grounded, don’t re-elicit them for the sake of it — take them to /layers-product-strategy.

---

Disciplines — what keeps needs honest

• Need, not solution. “When I need a report, I want to export to CSV” is a solution. Push to the underlying need.
• Strip the mechanism. If the “When” clause references your specific solution (your dashboard, your CSM, your weekly email), you’re describing the current system, not the need. Re-state it independent of who or what serves it: what’s true about the user at the moment they need this? The need follows from the state, not the mechanism.
• The “When” must be picturable. Specific enough to see the moment it happens — triggered by an event, a feeling, a rhythm, or a threshold crossed. Push until it is.
• Elicit emotional and social jobs, not just functional. They’re chronically under-articulated even when they’re shaping behaviour. Asking explicitly is usually what surfaces them. (Functional → interaction & model; emotional → surface tone/feedback; social → surface, sometimes strategy.)
• Mark confidence: observed / inferred / assumed.
• Workarounds are signal. A need real enough to motivate a spreadsheet or a workaround email is a strong one.

---

Techniques

Job stories are the default; the rest suit particular situations.

Technique	Use it when
Job stories (JTBD)	Default. When [situation], I want to [motivation], so I can [outcome]. Keeps solutions out; the “When” clause forces specificity.
User stories	The team prefers role-based framing or an existing Agile workflow.
Top tasks analysis (Gerry McGovern)	Large existing user base — identify which tasks matter most by frequency. Statistical, survey-based.
Persona + scenario	Communicating to stakeholders who think in archetypes. Good for alignment; less precise for design.
ODI desired outcomes (Ulwick)	Precise, measurable statements — “Minimize [metric] when [context].” Maps directly to opportunity scoring.
Surface hidden needs	Prompts to find what’s ignored: what users do before/after the moment you focus on; what they wish they didn’t have to do; what a workaround currently serves.
Rough prioritisation	Order by importance × how poorly currently served. A need that matters and is badly served is a high-value opportunity. Keep it rough — precise scoring is strategy work.

---

Working with the designer

First settle who the users are and in what situation — not “users” but which type, when. If there’s more than one distinct type with different needs, work them separately. Note the source (research, domain knowledge, or assumption); if it’s assumption, mark it and plan to validate.

Then work the needs the designer raises through the disciplines above, and probe for hidden ones. Offer the technique that fits — job stories by default, ODI when measurability matters, top tasks when there’s a large user base. Don’t run a fixed sequence.

Capture only the residue: the prioritised needs with confidence ratings, the unprioritised-but-surfaced ones (so they aren’t lost), gaps (probably-real needs not yet grounded), and any contradictions between user types. Keep it to what carries a decision.

These needs are the opportunities for /layers-product-strategy. If they’re mostly assumed, consider /layers-observed-behaviour to gather evidence before building strategy on them.