القائمة
Techniques for eliciting and prioritising user needs, pains, and desires — the opportunities that feed product strategy
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Techniques for defining the product's objects, relationships, states, and vocabulary independently of any interface — the most load-bearing layer
Framework orientation for Layers of Product Design — load this first; provides the context all other skills depend on
Techniques for mapping a domain's concepts, terminology conflicts, and bounded contexts — the raw material the conceptual model is built from
Techniques for mapping interaction structure and flow — places, affordances, edge cases, and failure paths — without committing to visual form
Techniques for planning user research and synthesising it into grounded, confidence-rated findings about what users actually do
Diagnostic audit across all seven layers — identifies the bottleneck layer and recommends where to focus
| name | layers-user-needs |
| description | Techniques for eliciting and prioritising user needs, pains, and desires — the opportunities that feed product strategy |
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.
If the needs are already clear and grounded, don't re-elicit them for the sake of it — take them to /layers-product-strategy.
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. |
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.
