Laptop Covered in Stickers
November 20, 2019

Understanding User Stories

Creating clarity, aligning priorities, and defining done.

A website redesign can be a daunting undertaking. It may feel like you need to learn several different languages to communicate with sales, marketing, IT, leadership, designers, developers, project managers, and more. In addition, competing priorities start to come out of the woodwork, as internal business stakeholders can be challenging to wrangle if they have differing or conflicting opinions.

Marketing and IT teams need to be able to clearly communicate and keep a sharp focus on the needs of their users, the problems they are trying to solve, and the information needed to inspire them to take action. Project Managers, in the meantime, need to balance complex requirements, multiple participants, shifting priorities, and sometimes resourcing changes, in addition to keeping client goals in sight.

If you dream of a solution that can help you focus and align priorities across teams and do it in plain language that everyone can understand, user stories are here to save the day. They have a magical ability to create clarity and provide a shared language. And they are all about keeping user needs front and center in every decision you make, helping you settle stakeholder disputes, and keep the focus where it belongs.

At Kanopi Studios, we value clarity and want to make sure our clients understand the website development process from start to finish. We’re here to demystify the user story process and show you how it can support your goals. 

How are user stories created?

At the beginning of your website project, the Kanopi team focuses on learning everything they can about your organization’s goals and the needs of your users through meetings, interviews, surveys, and review of existing documentation. This process helps us understand the basis for the project and kicks off user story creation. 

Next, your team will start writing stories to define the needs of your project, using a simple structured format, outlined by Mike Cohn in his book User Stories Applied, that goes like this: 

As a [end user], I want [some goal] so that [some reason].

Simple, right? Also powerful. The statement emphasizes what users need to achieve, and what the system needs to do to help them reach their goals. It’s a plain-language way of mapping out our system requirements. All components of a user story are required and of equal importance.

  • End user – Who is this person? A site administrator? An anonymous visitor? A type of persona? 
  • Their goal – What does the user need to be able to do?
  • The reason – Why does the user need to be able to perform this action? This provides context for developers when determining how best to implement the story. It also helps us ask hard questions. If we can’t clearly define how something benefits a user, does this feature or function even need to exist?

How do user stories help create clarity for your website project?

A development team reviews all of the user stories for your project and bundles them into features (also referred to as epics) that need to be designed and built to meet the needs of your project. 

They also outline “acceptance criteria” for each story, which are the conditions that must be met to define successful completion of each story. Weigh these against priorities, and these become the roadmap for your project. Your team will review them in meetings, update them as the project moves forward, and share them with you for review and input as they are created, updated, and completed. 

Here’s an example … 

Imagine you work at a library. Research shows that your primary customers are parents with young children. These parents want to help their kids learn to love reading while doing fun things together as a family. Your user story might look like this: 

As a parent, I want a simple way to find out about events at the library so I can do things with my kids that teach them that reading is fun.

The team would likely conclude that an event calendar feature will be the best way to fulfill this user story. Additional stories could be added to help designers and developers build this feature. For example: 

  • As a parent I want to sign up for event alerts so I know when new events are posted.
  • As a parent I want to be able to add events I have registered for to my calendar so I can remember to attend. 
  • As a parent I want to be able to share events via social media or email so that I can invite other families I know.

You can see how all of these stories ladder up to an event calendar feature. They begin to give shape to how your team will design and build the calendar and how your users will be able to interact with it.

Writing user stories in this way allows everyone involved in your project to understand the plan and work from a single source of truth. It also helps you keep project stakeholders on course. This way, when your executive director steps in and asks why the website even needs an event calendar, you will have an easy place to start. And when Sylvia from HR wants to use the calendar for employee recruiting events, you can gently remind her that the calendar was designed to meet the needs of parents, who are your primary target audience. 

When you look at the event calendar during testing, you should be able to run down the list of user stories and criteria and see that parents can sign up for alerts, add events to their personal calendars, and share via social and email. This means that the feature was developed successfully and can be considered done.

Need help defining your user stories? Start by downloading our user stories template. Have questions? Contact us to discuss how user stories can bring clarity to your website project.