User stories are concise and easy-to-understand statements that define a common purpose for creating a successful digital product.
The primary focus when writing a user story is conveying the user’s needs and what they want to accomplish when engaging in a digital experience.
You’ll often read user stories written in the following format: As a ––––––, I need to –––––– so that ––––––.
Since user stories are a way to define the user’s needs, the goal is to provide user-focused solutions. This is why the UX team is often involved with creating user stories. However it’s not just UXers who have a say in things, user stories are the responsibility of all team members and should be easily understood by everyone.
It’s important to understand the users who you’re designing for and in many cases, personas play a key role in the process of writing user stories.
Since personas help you understand your users’ needs, experiences, behaviors and goals, they play an important part in planning and defining product features.
Knowing who the product users are, what they want to achieve, and the common user scenarios will create a streamlined approach to the process of writing user stories. This will help build empathy with your users and any UX research and testing programs will be able to provide solutions for creating a seamless user experience.
Successful projects require collaboration and a shared vision of the end-user, therefore user stories can help build a common goal and vision so that stakeholders and team members can remain focused on the user and what the project is trying to achieve.
Here are a few key benefits of user stories:
What does a good user story look like? There isn’t one ‘right way’ to build a user story, but there are some important guidelines to keep in mind.
Agile is a popular way of working and even though user stories are pretty much the norm on project teams, there isn’t a ‘set’ Agile user story template. There are certain key elements in user stories that should be considered and with some practice, you’ll find what works for you. Also, it’s worth noting that it may take some refining to get your user stories just right.
A user story should focus on these three things:
The three key focuses from above should be top-of-mind when formatting the card of the user story. The template of: As a ––––––, I need to –––––– so that –––––– would translate to: As a business user, I need to save my file to the cloud so that I can access it from multiple devices. This makes it clear what the user’s goal is.
You may hear the word ‘card’ when talking about user stories. User stories do not necessarily have to go on an actual card, most teams work with digital tools nowadays. Keeping things short and clear, the card houses the user story scenario.
Other things to keep in mind are that user stories should be clear and concise, and a good user story uses the active voice. As you practice writing and proofread your user stories, keep clarity and voice in mind.
Once you’ve written a few of these, it becomes apparent that the overall structure of a user story is quite simple. A user story describes the work that needs to be done. How do you know that this work has been done and that the user story is complete? This is where acceptance criteria comes in.
Things can get very complex based upon the type of functionality you’re describing in the story. There needs to be some criteria defined that go along with the user story, which is referred to as the acceptance criteria. Each user story has its own acceptance criteria.
The user story is the most important piece since it describes the high-level goal. Acceptance criteria is typically list form and each item is tested against them, one by one. When each acceptance criteria item has been fully tested and passed, the user story is complete.
Here’s a simple example:
User story: As a credit card holder, I need to view my rewards points, so that I can get cash back.
Hierarchy is important to keep in mind. User stories are typically small and often groups of user stories, known as epics, are required for larger product features.
Epics are used as a high-level overview of the needed features, and are named according to a set of common user stories. The number of user stories can vary, but in many cases there can be quite a few.
For example: Let’s say we’re creating a video game and have an epic for ‘Create my avatar’. It seems simple enough, but there would be many user stories that would be needed to make this a reality. This epic would contain the documented work that can be broken down into a number of user stories.
Keeping in mind the user type, what they want to accomplish and why they want to accomplish the task, user stories provide the team with clarity on the project and what they should build.
By writing clear and concise user stories, this ensures an efficient way to communicate and summarize the work that needs to be done.