Writing Meaningful User Stories

News and Events, Software Development
by: IQ Admin

Writing Meaningful User Stories

Welcome to the third article in our user experience series! In our previous post, we discussed how to conduct user research in order to understand the user’s needs, desires, and constraints to better inform your UX designs. Now that you have compiled the results of your research, how can you best feed those into an actionable plan for UX design & development?

In any plan you develop, it is important to keep your users at the forefront of your design decisions. An easy way to maintain user-focus throughout the design process is to distill your research into a series of user stories.

What are user stories? 

A user story is a single-sentence statement that identifies the user, an action they would like to take, and the value that action provides to them. These statements told from the perspective of the user, provide a short, simple look at what the users want to accomplish through the use of a product.

Most user stories are written in the following format:

As a [user/role], I want to [action/task] so that [purpose/goal].

Following this format lessens the learning curve for any stakeholder that wants to participate in writing user stories – including your users. It also provides standardized grammar and wording to ensure a mutual understanding of what the users expect.

What makes user stories effective?

User stories keep the focus on the user. By identifying the user upfront, we are forced to think from their perspective. Even in a scenario where you must start designing a product without user research, writing user stories forces a user-focused approach. While drawing from user research is still a more fool-proof approach, thinking about the design of a product from this perspective is still more effective than thinking about the design from your perspective. In the end, you are not the user.

User stories are simple. They should be written at a level that can be understood by all product stakeholders. Using the As a … , I want to … so that … format makes it simple for any stakeholder to participate in writing user stories. This promotes collaboration between teams and ensures that there is a shared understanding of expectations across all stakeholders.

User stories identify the “why”. Any design will be better informed if the designer understands a user’s motivations for wanting to perform certain actions. In addition, identifying the purpose or goal of a need can help to prevent feature creep. Ensuring that stakeholders have thought about why a feature is important to the users of the product prevents the team from feeding the design with features that are cool and exciting but may not fill any specific needs.

Translating your research into user stories

In order to translate the outcomes of user research into a meaningful list of user stories, first, you need to identify who the users are. Often, you’ll need to split your user-base out into a series of different roles. Users within each role will likely have different goals they want to achieve.

Once you have a list of users and roles you can then begin to split your research outcomes into a user story format. At first, the team should focus on capturing all user needs as user stories. After accomplishing this, you can spend some time breaking down your existing user stories into smaller, more manageable stories.

As a fun example, when IQ was in a much smaller office space, we had just a single microwave. Long lines would form during lunchtime as everyone waited to heat up their food. At some point, it became the focus of one of our hackathons. The proposed solution was an app that would allow users to sign up for a time slot to use the microwave before lunch.

To kickstart the app design process, feedback was collected from the office’s most frequent microwave users. From this feedback, we were able to generate a list of user stories focused on the IQ microwave users’ needs. We also identified that someone would need to maintain the application in some capacity which led us to include user stories for an administrator role as well.

The resulting user stories gave the hackathon team a clear path forward to develop a useful tool to better utilize the one and only microwave in the office. Some of the user stories included:

  • As a user, I want to view the schedule for the microwave so that I know when the kitchen will be empty
  • As a user, I want to schedule the microwave throughout the day with 0.5-minute precision so that I can not worry about having to wait in the kitchen to use the microwave.
  • As an admin, I want to be able to add, modify, and delete resource reservations so that I can resolve issues and enforce my microwave dominance.

While our microwave queue app may not have taken off because we soon moved to a larger office space with more microwaves, writing user stories for this hackathon project allowed everyone to participate in defining how the application would work regardless of their technical background and kept management informed in what the group was working on.

For additional information on writing user stories and why they work to effectively inform UX design, check out the following articles:

Author: Jessica Green

‹ Go Back