User stories are short, plain-language descriptions of a feature or function from the perspective of the user who will benefit from it. Originating in agile software development, they have become a bridge between design research and product development, expressing user needs in a format that both designers and engineers can work with directly. A good user story keeps the focus on outcomes rather than implementation details, preventing teams from building solutions in search of a problem.
What It Is
The standard user story format is: 'As a [type of user], I want to [do something], so that [I achieve a goal].' This three-part structure ensures that every story names who benefits, what capability is needed, and why it matters. Stories are deliberately small in scope, representing a single unit of user value rather than a feature set. They are typically organised into a backlog and prioritised based on their relative impact on user goals. Acceptance criteria are added to each story to define when it has been successfully delivered.
How to Run It
Derive user stories directly from research findings and personas rather than writing them from technical or business requirements. Run a story-writing workshop with the design and development team, using persona goals and journey map pain points as inputs. Write stories on index cards or in a project management tool such as Jira or Linear. Review each story for clarity: if someone reading it cannot immediately understand who benefits and why, rewrite it. Prioritise stories collaboratively using impact-versus-effort mapping or a similar framework. Review and refine the backlog regularly as new research updates your understanding of user needs.
When to Use It
User stories are most useful during the transition from research and design into development, when the team needs to communicate user requirements in a format that engineering can act on. They work best in iterative, sprint-based development processes where small units of work can be planned, built, and evaluated in cycles. They are less suited to early-stage discovery work, where the goal is to explore and understand rather than to specify and build.
Tips for Success
Write stories in the user's voice, not the product team's voice. The 'as a' part of the story should reflect a real persona or user segment from your research, not a made-up role like 'power user' that has no research basis. Keep stories small enough to be completed within a single sprint. If a story is too large, split it into smaller stories that can be independently delivered and evaluated. Review stories with actual users when possible to confirm that the framing reflects their real experience.
