User stories have become a core methodology when it comes to creating a user-centered approach in agile.
It’s easy to understand, no matter if you’re a UX designer, developer, or product manager.
HOWEVER, we will discuss some common pitfalls you’ll want to avoid––pitfalls that make your product design process look user-centered versus being user-centered.
I’ve used the user story method recently in one of my projects, so I felt like it was a perfect time to talk about it.
In this article, we discuss what user stories are, why and when you should use them, and how to create them.
User stories are short, goal-oriented, one-sentence statements framed in the voice of the user to help the creators and stakeholders of a product understand the user’s perspective while in the process of creating the product.
They are based on UX research and break down the process for a user to accomplish a task into small, bite-sized bits.
In other words, when you have a larger task, which, in this case, we call an epic, you break it down into a series of one-sentence statements that each describes a piece of the product that needs to be designed in order for the user to complete that epic.
The user stories take the form:
As a {user/role/person}, I want to {task/action} so that {purpose/objective/value}.
If this all sounds a bit theoretical right now, don’t worry!
We’ll go over an example in the How to Make User Stories section.
There are several reasons why people rave about user stories.
We’ll go into more detail on how to make them in the next section, but they’re very easy to make since they’re mostly consisting of a series of one-sentence statements.
Before you actually design your product, it’s very easy to discuss it at a theoretical level with client and stakeholders.
It’s hard for them to visualize before having any mockups and so they might end up thinking about the product and what it requires differently than you.
User stories bridge this gap by making it clear what features will need to be included and why they need to be included.
If done correctly, user stories will be user-centric.
One of the pitfalls that many product creators fall into is that they make user stories that are framed in the user’s perspective without having actually done any UX research.
And by UX research, I mean talking to users to find their pain points or creating personas.
The reason this is an issue is that you’d still be basing the user stories on your own perspective and what you think users want and need.
In turn, you might end up with a product that doesn’t meet the user’s goals at all.
There is no substitute for user research.
User stories and epics are well-known pieces of the agile process.
We even use user stories at my own workplace.
It’s a common language that gets stakeholders, product managers, developers, designers, etc. onto the same page as to what features will be created and will get everyone to think like the users they’re creating their products for.
Nowadays, many workplaces will expect you to know at least know what user stories are.
The user story-making process is actually pretty simple. Let’s go over the four main steps:
As mentioned in the previous section, your user stories and epics should be based on actual user research.
After having talked to users and created personas that represent your users, write down their goals.
What are the main tasks they’re trying to do that your product solves?
Let’s look at an example.
Let’s say we’re building a product that connects models with brands looking to hire models.
We’ve done our research talking to models and companies hiring models and we’ve come up with a persona for the model user.
Here’s one of our persona’s main goals:
Jessica Channing, our persona, wants to get her modeling work seen by her favorite brands (to ultimately get hired for their modeling shoots and advance her career).
The goals may vary in scale.
For example, Jessica’s goal might simply be to log in to her account after having lost her password.
Now we simply use that goal and turn it into an epic for our user stories.
Epic: Receive modeling contracts from favorite brands.
We have our epic, so let’s break it down into specific features (i.e. user stories).
The user stories take the form:
As a {user/role/person}, I want to {task/action} so that {purpose/objective/value}.
For our example, some of our user stories might look like this:
As you can see, you’ll end up with a long list of features that need to be designed and developed later on.
Keep making stories until your user is able to accomplish their (epic) goal using your product.
With your list complete, you can talk to your team about your user stories.
This will lead to a lot of back and forth.
Iterate and refine with your team before moving on to the next step of the UX process.
