User stories
User stories describe capabilities from the user's perspective so delivery teams understand what to build and why. Paired with acceptance criteria, they translate hypotheses into concrete, testable requirements without losing sight of user benefit.
Why it matters
NN/g notes that UX work often disappears inside development backlogs unless it is made visible. User stories — with explicit UX tasks and acceptance criteria — keep research-informed intent present through agile delivery.
Key ideas
- Classic form: "As a [role], I want [capability], so that [benefit]."
- Acceptance criteria: Use Given / When / Then for main paths and important edge cases.
- One capability per story. Do not collapse distinct needs into a single vague story.
- Trace to hypotheses. Group stories by epic and cite which hypothesis each epic serves.
- Include non-functional needs. Accessibility, performance, and security belong in the backlog explicitly.
- Make UX visible. Break stories into UX and development subtasks, or use Kanban stages that include research and testing.
How it fits the pipeline
User stories connect validated opportunities to buildable capabilities with clear acceptance criteria.
Common mistakes
- Stories written as technical tasks ("refactor API") without user benefit
- Acceptance criteria that only cover the happy path
- Missing edge cases surfaced in research
- No link back to the hypotheses they implement
Further reading (NN/g)
- — keeping UX visible in agile backlogs
- — planning content work as explicit stories
- — integrating UX into agile product development (NN/g report)
Educational summaries informed by research published by Nielsen Norman Group.