User stories are short statements about features, written from a user’s perspective. A well-defined user story does not spell out the exact feature, but rather what the user aims to achieve, to give teams the freedom to identify the best possible way to implement the feature.
User Stories Help You Plan Sprints
Ideally, the team should draft the stories in collaboration with stakeholders and user researchers. While there is no standard format for creating user stories, teams commonly write them as single-line statements. Some teams may also include design deliverables such as personas, storyboards or short movies and include details about the users’ activities, thoughts and emotions.
User stories are commonly used in agile teams to facilitate planning. Each story should be small enough to fit into one sprint. The most common format for framing the story is:
As a
, I want , so that .
User stories were created as part of the move away from lengthy planning periods in software development in the 90s. Use cases, another type of story of use, were part of this longer process. While user stories effectively replaced use cases in many scenarios, they still draw inspiration from them, and in some cases, you may want to use use cases when more detailed stories are needed.
In this video, William Hudson, User Experience Strategist and Founder of Syntagm Ltd, explains how use cases describe a system’s interactions with users and external events, helping you understand when they may be more suitable than user stories for detailed analysis.
The User
While user stories are mostly written from the end users’ point of view, that’s not always true. Teams can write them from the perspective of business stakeholders, partners, and even employees and team members.
The Goal / Action
User stories are problem- or goal-oriented and do not include specific solutions or features. Instead, they aim to serve as a springboard for teams to ideate and arrive at the most optimal solution to solve the problem for the user. Here’s a hypothetical user story for a mobile application for diners:
“As a diner, I want to quickly locate good restaurants so that I can get good food fast.”
Notice that this user story doesn’t include specific features. These come later, when team members take the user story and work their way towards solutions or features, which, for this user story, could include:
Be able to save favorite restaurants.
Sort restaurants by location, reviews or delivery times.
View recommendations by friends.
While user stories may seem like simple statements, they can be tough to get right. This is where qualitative research techniques, including observations, contextual interviews, and other ethnographic methods, come into the picture. Designers and researchers can also use probe kits to ask users to document their days and capture their context, experiences and perspectives. The team can then collaboratively select the most relevant insights for the design problem and merge them into cohesive user stories.
The Outcome
The best stories are ones that lead to measurable outcomes. Examples of good outcomes are an X% increase in profile completion rates or an N% drop in payment flow errors. Outcomes that are tied to users or business goals free up the team to think about solutions to problems instead of churning out features for the sake of shipping something.
When the team begins work on a user story, they need not always understand the full scope of work since user stories are (intentionally) vague about what features the team should implement. To ensure that all team members are on the same page about what the user story should accomplish, product managers, designers and researchers often include acceptance criteria—what conditions the feature should fulfill to consider it done.
User-Centered Design: User Stories vs Persona Stories
Because user stories focus on simple role labels, they rarely give you enough insight into the real people who will use your product. When a story begins with something like “As a user, I want…”, you learn nothing about who that person is, what they care about, or what might shape their behavior. This makes it harder for you to design with genuine user needs in mind or to understand how someone will actually experience your solution.
Persona stories give you a clearer path. Instead of referring to an anonymous role, you write from the perspective of a specific persona with real goals, motivations, and context. This helps you step into your user’s world and understand not only what they want to do but why. With that clarity, you can make better design decisions, anticipate challenges, and create solutions that feel natural and supportive to the people you are designing for.
In this video, William Hudson explains how persona stories, created collaboratively after user research and early design, help you base your decisions on genuine user needs and avoid the limitations of anonymous “As a user” stories.
