⨳  14 April 2014
User Stories, User Scenarios, and Use Cases can all help you better understand who your users are and ensure that what matters to them makes its way to your project spec.
Do you know how to tell your usersâ story? How do you know? Are you sure youâre not just making it up as you go along?
Last year, I was developing an article about how different streams of expertise are brought together in digital projects. I had in mind to call it, âHow We Work Together.â I was particularly interested in how a clientâs expertise is necessary to customizing the design and technical expertise they need from us. That seed thought was encapsulated in a venn diagram Iâd scribbled into my notebook, among other thoughts I was going to include in my outline. The diagram was a simple one: one circle for âYour Expertiseâ slightly overlapping another one for âOur Expertise.â The idea was to explore the overlap â how the process we follow to develop the right platform is one built around capturing and framing client knowledge with our digital marketing expertise. But something was missing. As the year drew to a close, the idea and those notes were quickly buried in other things, and I didnât think much about them until recently.
As we often do in the new year, weâve been questioning some assumptions, tweaking some language, and making some changes to the processes we follow. In the midst of all of that, I came upon those notes again and immediately realized what was missing in the venn diagram. Itâs true that any project we do is shaped by a sort of knowledge synthesis â an exchange of information and the emergence of something new that is entirely the result of collaboration. But the most critical component of that process is the user â the person for whom this whole platform is intended in the first place. My first venn diagram implied a basic arithmetic: client knowledge + designer knowledge = something useful. But thatâs not quite right. Itâs really best expressed as client knowledge + user knowledge + designer knowledge = something useful. Itâs the userâs knowledge that bridges the gap between our clientâs expertise and our expertise. The venn diagram needed one more circle. Threeâs company, after all!
The obvious question is, how do you capture the userâs knowledge? Itâs easy for designers and clients to get together and collaborate, but adding users into the mix sounds complicated. There are two ways of doing this that ensure you can represent your users accurately without having to make more room at the table:
Neither of these methods is new. If youâre a long-time reader of ours, youâre certainly familiar with them; you may already have put them into practice. But once youâve captured user knowledge, what do you do with it?
Without user knowledge, we tend toward analytical approaches to information architecture planning and user interface design â structures that make sense to us and the way we think about the information we want to convey, but that donât always make sense to our audience. To balance out that analytic thinking, we need to introduce narratives to our planning procedures. Specifically, we need to be thinking through every design decision based upon a need > experience > outcome narrative. What does the user need? What kind of experience does our solution create? Does our solution work?
We need a method for folding user knowledge back into the design process so that we properly understand user needs, create the best user experience, and reliably bring about the right outcomes.
The raw data gathered in persona interviews and usability studies is of course valuable, but there are four specific steps for processing it that, together, form a chain of progressively better understanding that comes to fruition in every design decision you make. Letâs review those steps now.
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. Iâve worked on projects just like this one, where a website â despite being a database of niche manufacturing supplies â needed several user stories for each persona group. In one recent project, we began by identifying six different persona groups, which means that the possible number of user stories could be as many as twenty or more. Good thing theyâre brief!
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:
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.
Finally, user flows are a form of visual documentation that illustrates how users encounter your websiteâs content, as well as the sequence of their interactions once they get there. This is where your stories, scenarios and cases can be mapped out in a way that applies more directly to information architecture and user interface design decisions.
Hereâs an example of a diagram showing all the possible user paths to a planned landing page for a particular campaign. (Note that offsite or campaign traffic sources could also include âsearch.â):
Hereâs an example of a diagram showing the possible paths a user might take once they have arrived at your website:
These flowcharts are a preliminary step toward more detailed wireframing and prototyping. Theyâre more interested in the flow from one decision point to another than in documenting every possible interaction point a page might contain. Once possible flows have been worked out, though, youâre better off moving into a prototyping process rather than lingering too long in choose-your-own-adventure land.
Beginning with user stories, expanding them into user scenarios, then filling in the detail with use cases, and finally contextualizing all this information in user flows is a process that bridges the gap between user research and design. It makes it possible for the information you collect about your users â in persona interviews and usability studies â to be properly processed and integrated into user experience design workflows so that, in the end, you can actually make something useful. Keep in mind, though, that this is a pattern for an ongoing cycle of work. Itâs not one-directional. Once you start, you are going to do it over and over again.
Have you put any of these methods into practice? What have you learned? What are some ways that youâve tweaked these methods to better suit unique situations? Iâd love to hear all about it.