Layers User Needs

# /layers-user-needs

*Assumes `/layers-intro` has been loaded for framework context.*

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.

In OST terms, the outputs here are **opportunities**: needs (what users want to achieve), pains (what's causing friction), and desires (improvements they'd value). All three are valid inputs; elicit all three.

**Decisions this layer needs to make:**
- Who exactly are the users whose needs we're defining — and in what situation?
- What jobs are they trying to do — functional, emotional, and social?
- Which needs are grounded in evidence, and which are assumptions?
- Which needs matter most, and why?

**Methods:**

| Method | When |
|---|---|
| **Job stories** (JTBD) | Default. Situation → motivation → outcome. Keeps solutions out; forces specificity through the "When" clause. |
| **User stories** | Team prefers role-based framing, or integrating with 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 decisions. |
| **ODI desired outcomes** (Ulwick) | Precise, measurable statements. Format: "Minimize [metric] when [context]." Maps directly to opportunity scoring. |

Default: **job stories**.

**Three types of need — elicit all three:**
- **Functional** — the practical task. Feeds interaction structure and conceptual model directly.
- **Emotional** — how the user wants to *feel* while doing the job. Feeds surface (tone, copy, feedback).
- **Social** — how the user wants to be *perceived* by others in this context. Also feeds surface; sometimes strategy.

Emotional and social needs are chronically under-articulated in briefs and research reports, even when they're genuinely shaping behaviour. Asking for them explicitly is usually what surfaces them.

**Quality signals — what good looks like:**
- The "When" clause is specific enough to picture the moment it happens
- The motivation is a genuine goal, not a solution sneaking in
- Functional, emotional, and social dimensions all explored
- Confidence marked: observed / inferred / assumed
- Workarounds surfaced — a need real enough to motivate improvisation is a strong signal

---

## Guided session

*Tell me who your users are and what you're working on, or say "guide me" to start a structured session.*

Ask: *"Where should I capture the work from this session?"* (see `/layers-intro` for options)

Ask: *"What's the source of the user needs we're working with — user research, domain knowledge, team assumptions, or a mix?"* If working from assumptions, mark them clearly throughout and plan to validate.

---

**Phase 1 — Frame the users**

1. Who are the users whose needs we're defining? Be specific — not "users" but which type, in which situation.
2. What context are they in when the relevant need arises?
3. Is there more than one distinct user type with meaningfully different needs? Work through them separately.

**Phase 2 — Elicit needs**

Work through the needs the designer raises. Format: *When [situation], I want to [motivation], so I can [expected outcome].*

The "When" clause is the most important part — it must be specific enough to picture the moment. Push until it is.

For each need, ask: *"Is there a functional job here, an emotional job, a social job — or all three?"*

Probe each:
- *On "When":* "Could you picture the moment this happens? Is this triggered by an event, a feeling, a rhythm, or