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:
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.
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.
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:
- locates user manual and identifies name and model number
- enters name and model number in search field at Google.com
- hits “Enter”
- search results appear; scans page for name and model number
- finds no results that look correct
- enters chipper name in search field
- hits “Enter”
- search results appear; scans page
- finds listing for chipper
- clicks link
- detail page for chipper loads from manufacturer website
- scans page for model number
- identifies link for owner’s manual
- clicks to download PDF
- opens PDF and scans for model number; finds his among three models covered by manual
- scans PDF for part he suspects needs maintenance
- finds part number listed in hydraulic pump schematic
- tries to copy and paste part number; cannot, text is part of image
- writes part number on a sheet of paper
- returns to manufacturer website
- searches for part number in manufacturer website’s search field
- clicks “Go” button
- search results page loads with no results
- scans navigation for a contact link
- clicks “Contact Us”
- contact page loads; scans and fills out form
- 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.