By identifying the user’s needs, we can be more assertive in our product in a way that the user will really use it.
And User Stories are one of the best ways to map features based on user needs, guiding the whole development process.
A couple months ago, an old client asked for our help. He wanted us to create some User Stories for his development team.
In this case, we wouldn’t develop or code anything, only help them in this process of identifying the user needs and translating them to the developers.
That reminded me of how important User Stories can be, and this is why I’m writing this post.
Introducing User stories and Epics
User stories are basically small stories about tasks the user has to complete - and why
It can be used to map a system or product functionalities or even to expand and improve an existing one.
A user story can actually start as an epic: a sketch of a feature. They allow you to jot down ideas without holding too much to detail.
When it comes to writing epics, you can focus on the main product/service capabilities to create your epics.
Start by the main things your users will be able to do: Search, upload images, edit content.
All of those can be each an epic. But keep them simple, just a phrase specifying the action the user will perform and the aimed goal, then later the specifics can be delimited by the user story.
Now let’s dive in some user stories details below.
When user stories can be used?
Epics can be very helpful to make future sprints: since epics describe the product’s main functionalities, they can lead to achieve the release/sprint goal.
So, after the sprint goal is defined, we can select which epics can contribute to achieve the goal and create User Stories from them.
Problems they can help to solve
Match the user needs
Since epics are built based on user journeys, you’ll be more certain to be building a product matching the users needs
Optimize both development and design phases by having a clear goal known by the whole team, avoiding rework and missed deadlines
Identify opportunities and product requirements
Prioritize critical or risky functionalities
Structure of Epics and User Stories
Before having user stories, we have epics. They’re a bigger piece of functionality that later can be turned into several user stories. A good resource of insights for epics are user journeys, as they can provide rich content for the epics.
The following structure can be used to help writing an epic:
the role that plays some action on the product
to do something on the product
reach some specific result, or that something be done
“As Mary, I want to add favorites to easily find what’s more interesting to me”
Epics need to be short and direct, because they’ll be the foundation to create our more specific and detailed User Stories.
The details for theses stories will appear as soon as we learn more about the product functionalities, talk with our users, show it to stakeholders and discuss it with other team members.
The next step is turning our Epics into User Stories.
Turning Epics into User Stories
User stories are small, detailed stories that can be implemented and tested, and have to be clear but not too big or complex.
They can describe the interface design, performance, operational requirements, expected behaviors, and even criteria that help to improve the user experience.
To better organize all those requisites, we can separate them into:
Basic description, what the user wants to do/achieve
Description of the functionality from the user perception. Here you can consider details such as user interface design, what can or can’t be done within the functionality, where or how the user can find or access what he needs
Nonfunctional requirements such as business restrictions, quality control, flow rules, navigation architecture, error prevention, usability and guidelines to improve the user experience
What makes the functionality ready to be launched
Story consistency check
How do I know if the stories are complex enought to not be missing any critical details?
When gathering requirements and specifications to the user stories, you can verify if the functionality flow is smooth by applying the “given-when-then”:
Given pre conditions, requirements
When I perform some action on my product
Then something must happen, what I want to happen
We can also use “and” to create even more complex scenarios.
Content written by Simone Hoffman, Information Designer at Cluster
Looking for more?
Be the first to know
Get first-hand access to our free Design and Dataviz content directly in your inbox