look-at Writing great user stories

Use scenarios are an important part of usability test design. When writing your own use scenarios, remember these best practices.

When designing a usability test, the first step is to understand the users. Without that solid foundation, you can't create a usability test that accurately reflects how real people use the website to do real work.

Usability test design requires knowing who uses the website, what they do on the website, and how they access the website. Writing usability testing personas defines "who uses the website." To understand the "what" and "how," we need to write user stories. These are also called use scenarios. 

Elements of a user story

A user story or use scenario should provide a brief story or scenario that provides background information about what the persona needs to do, including goals and intended outcomes. Most user stories should also provide some description of how they access the website or system, such as via a laptop or phone, or at home or in the office.

I like to start with the persona. When I write personas, I also write at least one use scenario to go with it.

Use scenario 1: Displaying slides

It can help to look at a few sample use scenarios, so you can write your own. As an example, let's start with one of the personas I described in my earlier article about How to write usability testing personas:

Dan (45, he/him) teaches math and CS at a university.

Dan has been a Linux user since the 1990s and has tried all of the Linux desktop environments: twm, olvwm, WM, fvwm, KDE, and GNOME. His favorite is GNOME, which he's used solidly since GNOME 2.

Dan uses GNOME for everything, including teaching classes.

The persona describes "Dan," a GNOME user, but it doesn't describe what he does with GNOME. That is answered in the use scenario.

Note that "Dan uses GNOME for everything, including teaching classes." That's a good place to start. One use scenario might be using GNOME to teach a class. As an instructor, typical use cases include displaying slides in a presentation and editing source code for a computer science class. Each of these could be separate use scenarios:

Dan is teaching a college-level algebra class. He has a slide deck he created using Google Slides that he will use in today's lecture.

Dan arrives in class five minutes before the class is scheduled to start, turns on his laptop, and plugs it into the classroom electronic display. When the laptop boots into GNOME, Dan logs in and opens his slide presentation using Google Chrome. He is ready for his lecture to start.

That user story describes a common use of GNOME: displaying a slide deck. While this is Dan's user story, this general use case is shared among many people. Google Chrome is the most popular web browser, and Chrome also runs on Linux systems. 

Also note that the use scenario describes how and where Dan uses GNOME. He runs GNOME on a laptop computer in a classroom. This is an important detail that helps inform the project owners about how users use the system. And knowing that the "Dan" persona uses GNOME on a laptop in a classroom will help with the usability test design; the usability test should cover using GNOME to connect to an external display.

Use scenario 2: Writing source code

We could write another use scenario for how Dan uses GNOME to edit source code while teaching his computer science (CS) class:

Dan is teaching a CS course on systems programming. He uses a slide deck to display a few slides, but most of the class time is spent writing code and discussing the implementation.

Dan arrives in class a few minutes before his students. He connects the laptop to the classroom displays system, and turns on his laptop. When class starts, Dan starts the Visual Studio Code application so he is ready to write the first sample program for his students.

Editing source code is a use scenario for the "Dan" persona, but it's a pretty common use case for a lot of people who use GNOME. Visual Studio Code is a popular source code editor, and is available for different platforms including Linux.

In addition to providing the background about why "Dan" uses GNOME and what he does with it, the use scenario also describes how and where Dan uses GNOME. Again, Dan is in the classroom, running GNOME from his laptop connected to an external display.

The basics are very similar to the first use scenario, but they provide a few variations in detail. In the first use scenario, Dan started his laptop and then connected it to a display. In this use scenario, Dan connected the laptop to the display and then booted the laptop. This small variation could indicate a different usability test scenario task: Use scenario 1 asks if a user can select a different display if the video was connected after logging into GNOME. Use scenario 2 examines if the user can select an external display if the video was connected before the computer was turned on and thus recognized at boot-time.

Writing your own use scenarios

Use scenarios are an important part of usability test design. Together, the persona and use scenario provide information about who uses the system, why they use the system, and how they use it. When writing your own use scenarios, remember these best practices:

  1. Write a brief story
  2. Connect the use scenario to a persona
  3. Describe what the persona needs to do
  4. Answer why they need to use it
  5. Describe how they use it