User stories

Building a software product is complex and involves numerous processes, technologies, and teams (technical and non-technical). All of these moving parts make it easy for the project to get out of hand and lose focus on what really matters: how the product creates value for the user.

So how do you make sure that multiple teams understand the purpose behind what’s being built, and how they fit in? That’s where user stories come in.

What is a user story?

A user story defines:

1. what is being built,
2. why it’s being built,
3. whom it’s being built for,
4. and when it will be built.

By describing the desired outcome of a product feature, a user story reminds everyone involved what the user’s goals are. This allows you, the designer, to visualize the functionality of a product and helps you organize and prioritize the way each function is designed.

User stories were born out of the agile software development process, which emphasizes speedy iterations that encourage collaboration and the constant consideration and implementation of user feedback. They’re a key part of the agile approach because, as the name suggests, they help people on various teams keep the user and their needs in mind while the product is being built.

A well-written user story often has the following traits:

• It defines a user problem/need that they’ll solve using your product.
• It’s brief, providing just enough information so that designers and developers understand the functional need of a product without detailing how they’ll tackle it.
• It can be updated and formatted as the product and project evolve.

People who represent the user’s interests—the product owners—are normally in charge of writing user stories. They write them from the perspective of the user in clear, accessible language so that anyone can understand them, from developers to creatives to stakeholders.

Why are user stories important?

Sometimes it can be easy to forget that certain workplace tools and processes don’t come out of thin air—and actually serve a useful purpose. User stories are no exception. They might seem like a hassle, but they really help simplify and streamline projects.

They encourage collaboration
User stories are a meaningful collaborative tool that allow teams to talk through the desired functionality of a product, and serve as a catalyst for deeper discussions.

When developers, designers, stakeholders, and creatives work on a product solely within their own silos, the result is an inconsistent product that’s mismatched to user needs. User stories encourage teams with different expertise to come together and talk through product functionalities.

User stories keep everyone on the same page. New people can easily catch up and understand what’s going on, especially if they come in halfway through a project. And because they’re documented in places that are easily accessible, they also make it easier for remote team members to collaborate with everyone.

They bring focus to the design process
How many times have you presented your ideas for a product feature or an app only for that meeting to devolve into a useless back-and-forth about whose designs are better? Because user stories already document what a product is and the value it provides to the user, conversations shift from who’s right to how does X or Y align with what the user wants to do.

They help determine the scope and prevent feature creep
Because they contain succinct descriptions of product functionalities, user stories help developers reasonably estimate the effort it would take to implement a product function. In the same vein, they also help designers prioritize ideas that align with the core function of your product—and de-prioritize everything else.

This prevents feature creep from making its way into your design process. Any time a client or team member wants to add a nice but frivolous feature, you can refer them back to the user stories. If the idea isn’t beneficial to the user and doesn’t stick to the original intention of the product, then it’s unnecessary. This makes user stories a godsend for anyone who doesn’t like fruitless add-ons and delayed product releases.

What are different methods for developing user stories?

The “story” in user story is slightly misleading, since it’s normally just one line that’s both succinct and specific. According to the leading Agile Senior Consultant Andrew Fuqua, every sprint should have around 5-15 user stories.

If your user story is too general, then it’s probably an epic. Epics provide a high-level overview of necessary product features and can’t be completed in one sprint; user stories provide specific details about those features, and can be completed in one sprint. Many people write epics before they write user stories because it allows them to sketch out the basic functionality of a product without having to provide too many details.

There are a couple ways to write user stories, including the Role-Feature-Reason method and the Three C’s method.

Role-Feature-Reason
Also known as the Role-Goal-Benefit (RGB) method, R-F-R is a common framework for writing user stories. It has a simple, yet effective structure that’s easy to remember:

As a [type of user], I want [some feature] so that [some reason].

Let’s say your team is about to do a sprint with the goal of creating features for human resources management software. Your group of user stories might look something like this:

User Story 1: As an employee, I want to use direct deposit so I can have access to my paycheck sooner.



User Story 2: As an employee, I want to split my direct deposit paycheck so I can automatically put money into my savings account.



User Story 3: As an employee, I want to split my direct deposit paycheck so I can automatically put money into my 401k.



User Story 4: As an employee, I want to be able to access my direct deposit paycheck digitally so I can see how much taxes are being taken out.



User Story 5: As an employee, I want a direct deposit email alert so I can know when my paycheck has been deposited.

This type of lean, flexible narrative is concise and informative. It clearly outlines the who, what, and why so that designers and developers can find efficient solutions. Writing the story from the user’s perspective puts anyone reading them in their shoes. This effectively closes the gap between team member and user, and encourages user empathy.

The Three C’s
Created by Ron Jeffries, co-founder of the Extreme Programming software development methodology, in 2001, the Three C’s approach builds on the Role-Feature-Reason method. The three c’s stand for 1) card, 2) conversation, and 3) confirmation.

Card
State the problem using the Role-Feature-Reason format on a 3×5 index card. For example: As a teacher, I want to log in so that I can enter my students’ grades.

Conversation
After reading the card, the developer converses with the writer (usually the product owner) to make sure they understand the work that needs to be done. In a comprehensive breakdown of the Three C’s method, Agile Evangelist Bill Devoe explains the importance of this step:

Confirmation
Team members come together to confirm what the feature will do when the user story is done, and that they’ve completed the goal of the user story.

INVEST
INVEST is a pneumonic device created by Agile consultant Bill Wake. It’s not so much a method to create user stories as a handy checklist that helps you remember what you need to include in your user stories as you write them.

I – Independent. User stories shouldn’t overlap and should be able to be implemented separately.
N – Negotiable. User stories should be flexible and have space for negotiation.
V – Valuable. User stories should add value for the user.
E – Estimable. User stories should provide enough information so that people can estimate how much time it will take to implement.
S – Small. User stories should be small in scope and able to be implemented in one sprint (around one week).
T – Testable. User stories should be testable. If you can’t write a test for it, then the user story probably isn’t clear enough.

Where do user stories live?

User stories live wherever you want them to live. What’s most important is that your user stories are visible and accessible to everyone, whether that’s JIRA, Google Drive, or Post-its/index cards on a wall. You can’t experience the full collaborative experience that user stories facilitate if no one can find them.

Making your user stories and epics searchable and easily categorized through the use of meta tags and the like will make it even easier for people on various teams to take advantage of this collaborative tool. And if you’re going to go the analog route, consider having an electronic back-up. This will help you track the evolution of your user stories and will be a useful reference even after the product is released.

In conclusion, user stories give you a bird’s eye view of all the various pieces required to build a product. This makes it easier for you and your team to come up with effective solutions for user problems, resulting in a smooth user experience.

How to maximize your user stories

So after you create your user stories, what’s next? Well, now you build on the information outlined in your user stories, integrating that knowledge throughout the entire product process. And InVision can help.

Use Freehand and Boards to collaborate on work wireframes, empathy maps, and navigation flows. Create responsive screen designs and interactive prototypes with Studio and Prototype. Make it easier for your design and development teams to work together (and build products faster as a result) using Inspect. Complement the collaborative nature of user stories with Design System Manager, which gives your team an agile digital environment to work through problems the user stories helped you identify.