How Will Your Website be Used? User Stories & Scenarios

Chris Butler of Newfangled (a web design and marketing firm in NC) writes about creating user stories in the 2014 article “How to Tell the User’s Story (link to full article as at bottom of this post).

From their article:

User Stories

A user story is a brief statement that identifies the user and her need. It makes an incisive abstract that can be associated with your personas. Because personas tend to be pretty general, you might have several user stories associated with one persona group. Here’s an example user story for a hypothetical industrial parts database:

“As an Industrial Facilities Manager, Cathy is responsible for maintaining production systems and sustainability, which includes keeping equipment functional. She needs quick access to maintenance information and parts supply for her facility’s entire inventory.”

Notice that the user story identifies who the user is, what she needs, and why she needs it.

Here’s another example of a user story that might apply to the same website designed to meet our first user’s need:

“Jack owns a small landscaping business. He needs to be able to order replacement parts and have access to resources that will help him safely and properly service his equipment on his own.”

This second example maintains the same structure, but represents a very different user. An industrial parts database is likely to have a wide array of users with different needs, big and small. User stories help to document the practical differences in need among those users.

User Scenarios

A user scenario expands upon your user stories by including details about how a system might be interpreted, experienced, and used. Like user stories, you might imagine several scenarios for each persona group that you anticipate will make up your audience. Your scenarios should anticipate the user’s goal, specify any assumed knowledge, and speculate on the details of the user’s interaction experience.

Here’s an example of a user scenario, again from our hypothetical industrial parts website:

“Jerry has been helping his father manage an all-purpose machine shop in Western Massachusetts since he graduated from high school a decade ago. In the last year, Jerry’s father has retired, leaving Jerry in charge. Their only commercial wood chipper, which Jerry’s father purchased before Jerry began working with him, has broken down. He suspects that the hydraulic pump lever is broken. Jerry manages to locate the operator’s manual for the chipper, and searches the web for the manufacturer’s name and the model number. He finds several listings for his chipper online, and chooses the first one to view. On the chipper’s listing page, he finds a link to a PDF of the owner’s manual. He reads through it and finds a diagram showing the hydraulic pump and the part number for the lever. But there is nowhere on the page he is viewing that indicates he can order this part. He clicks a link to contact the manufacturer, who he hopes can point him in the right direction. One of Jerry’s long-time clients, the local country club, is expecting to pick up the chipper in two weeks.”

Notice how this scenario gives the user some backstory, contextualizes his need, and tries to specify the gaps in his knowledge that might lead to interaction difficulties.

Use Cases

A use case is really just a long list of steps a user might take in trying to get something done. It starts with whatever event serves as a catalyst for their interaction with your system — so, how the user got there — and recounts each and every step they take until they’ve either successfully done what they need to do, or failed to do so.

Here’s an example based upon Jerry’s scenario from earlier:

Jerry’s commercial chipper breaks down. He:

  1. locates user manual and identifies name and model number
  2. enters name and model number in search field at Google.com
  3. hits “Enter”
  4. search results appear; scans page for name and model number
  5. finds no results that look correct
  6. enters chipper name in search field
  7. hits “Enter”
  8. search results appear; scans page
  9. finds listing for chipper
  10. clicks link
  11. detail page for chipper loads from manufacturer website
  12. scans page for model number
  13. identifies link for owner’s manual
  14. clicks to download PDF
  15. opens PDF and scans for model number; finds his among three models covered by manual
  16. scans PDF for part he suspects needs maintenance
  17. finds part number listed in hydraulic pump schematic
  18. tries to copy and paste part number; cannot, text is part of image
  19. writes part number on a sheet of paper
  20. returns to manufacturer website
  21. searches for part number in manufacturer website’s search field
  22. clicks “Go” button
  23. search results page loads with no results
  24. scans navigation for a contact link
  25. clicks “Contact Us”
  26. contact page loads; scans and fills out form
  27. clicks “Submit.”

This detailed case highlights several points at which Jerry’s experience could be improved. With this case as a guide, improvements to the chipper’s detail page can be made, such as prominently displaying model numbers, expanding the resources associated with specific models, including an on-page parts search, and adding a contact form. Cases like these can also be informed and/or verified by actual usability test sessions.

The article goes on to describe User Flows. All of these things (User Stories, Scenarios, Cases, Flows) help us “make something useful.”

Ed Note: Full article is at https://www.newfangled.com/how-to-tell-the-users-story/
All information on this page is directly from Newfangled. The ideas and text are theirs.