What’s an effective user story, and how do you create one?
For Agile product teams, a user story is the gold standard for communicating product requirements to all team members. They’re brief, specific, and quickly understood.
Every user story includes three main characteristics:
1. It tells the story of the problem or need that the user will solve through a particular piece of product functionality.
2. It’s meant to be a living story that can be updated and modified as a project evolves
3. It provides sufficient information for developers and designers to understand the functional need, but doesn’t go into the details of how these should be addressed from a technical or design perspective.
In this post, we’ll look at how to write a simple user story that focuses the UX design on specific tasks. I’ve based the user story template on what’s worked best in my experience as a product manager and designer.
The User Story Template
As explained in the Guide to UX Design Process & Documentation, a user story has three main components:
The summary is basically a statement that tells the story of what the user would like to achieve. The general format for the summary is:
As a user I can <perform a certain action or achieve a certain goal>
Let’s imagine that we’re building a web platform that allows consumers to search for doctors in their area and schedule an appointment.
Photo credit: Health Grades
Examples of user story summaries that would be needed for this type of platform include:
- As a user I can create an account
- As a user I can login to my account
- As a user I can search for a doctor by specialty
- As a user I can search for a doctor by zipcode
- As a user I can search for a doctor by insurance provider
- As a user I can book an appointment
- As s user I can modify an appointment
- As as user I can cancel an appointment
- As a user I can reset my password
As you can see, each user summary presents the user’s goal – e.g. search by zipcode – and as such, communicates to both the design and dev team that a search functionality is needed here.
The details piece of an Agile user story spells out how particular functionality will work.
Using the example of platform for location doctors, let’s take this user story:
As a user, I can create an account
Photo credit: Health Grades
We can then write out the following details:
i. User clicks on account creation option
ii. User is prompted to fill in the following fields:
- First Name
- Last Name
iii. The following rules will apply to each field
- First and Last Name: text only fields. Limited to 60 characters
- Username: text and numeric field. Limited to 20 characters
- Password: must be at least 9 characters, with at least 1 uppercase letter, 1 number and 1 special character
The priority index helps the product manager ensure that the Agile product team is focusing on the most important features first.
You can present the priority in three differents ways:
- T-shirt sizing: S, M, L (small, medium, large)
- Urgency index: L, M, H (low, medium, high)
- MoSCoW rating: M, S, C, W (Must, Should, Could, Won’t). This method of prioritization is mainly linked to DSDM, another Agile methodology.
The method you choose is often a matter of preference for the product owner, product manager, and wider product team.
Several factors influence the priority index of a user story:
- Business objectives: A user story that directly influences a company’s revenue objectives or another KPI (such as reducing support tickets, customer retention or acquisition rates, churn rate, etc.) will get a higher index than stories that are nice-to-haves
- Functional dependencies: If multiple user stories can only be implemented after a particular story, then the latter becomes critical and gets a higher index value.
- Dev time required: If a user story is evaluated by the dev team as being quick to implement and it’s essential for achieving business objectives, then the story moves up in priority.