layers-user-needs
Techniques for eliciting and prioritising user needs, pains, and desires — the opportunities that feed product strategy
Security Assessment
About layers-user-needs
This skill is a library of techniques for the user-needs layer of a layered product design framework. It focuses on eliciting and prioritising user needs, pains, and desires, collectively the opportunities that feed product strategy. It solves the problem of turning messy observed behaviour and domain knowledge into clear, grounded statements of what users are trying to achieve and why, while keeping solutions out of the picture.
Its disciplines keep needs honest: express need not solution, strip the mechanism so a need is stated independent of any specific product or system, make the When clause picturable enough to see the moment it happens, elicit emotional and social jobs rather than only functional ones, mark confidence as observed, inferred, or assumed, and treat workarounds as strong signal. Job stories in the JTBD format (When situation, I want to motivation, so I can outcome) are the default technique, alongside user stories, top tasks analysis, persona plus scenario, ODI desired outcomes for measurable statements, prompts to surface hidden needs, and rough prioritisation by importance times how poorly a need is currently served. The intended output is lightweight residue: prioritised needs with confidence ratings, surfaced-but-unprioritised needs, gaps for probably-real needs not yet grounded, and contradictions between user types.
It targets product designers, UX researchers, and product teams using this methodology (it assumes layers-intro is loaded). Typical use cases include articulating job stories for a specific user type and situation, distinguishing grounded needs from assumptions, and prioritising opportunities before moving to product strategy. If needs are mostly assumed, it points back to the observed-behaviour layer to gather evidence first. It is pure design methodology with no code or external tooling.
FAQ
What is the default technique for capturing needs?
Job stories in the Jobs-To-Be-Done format: When [situation], I want to [motivation], so I can [outcome]. The When clause forces specificity and keeps solutions out of the statement.
What does stripping the mechanism mean?
If the When clause references your specific solution (your dashboard, your weekly email), you are describing the current system, not the need. Restate it independent of who or what serves it, so the need follows from the user's state, not the mechanism.
Does it cover more than functional needs?
Yes. It stresses eliciting emotional and social jobs, not just functional ones, because they are chronically under-articulated even when they shape behaviour, and asking explicitly is usually what surfaces them.
What if the needs are mostly assumptions?
It marks confidence (observed, inferred, assumed) and, if needs are mostly assumed, recommends the layers-observed-behaviour skill to gather evidence before building strategy on them. Grounded needs otherwise feed layers-product-strategy.
Install layers-user-needs
Quick Setup:
- Copy the skill folder to
.claude/skills/ - Claude will automatically detect and use the skill
Repository
jamiemill/layers-skills