How to Tell the User’s Story

You + Us + Them = Something Useful
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:

Making sure you know who your users are. To do this, you need to talk to them and use the information you gather from those conversations to develop user personas.
Observe use. This means doing in-person usability studies and using the information you gather from them to better understand how to design for true user patterns.

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.

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. 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!

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:

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.

User Flows
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.

Make Something Useful
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.

By the way, this piece pairs well with Three Essential Tools for Content Planning. ;)

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.