/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.
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.
