Storytelling for User Experience. Kevin Brooks

with whom you work.

       Determine in advance whether the people you work with want to remain anonymous.

       Ensure that the people you work with are informed of the goals of your work and what you will do with the information, and that you have obtained their informed consent, with a clear understanding of the impact of their participation in your work.

      The Code of Professional Conduct of the Usability Professionals’ Association (UPA) includes similar guidelines, as do those of many other user experience professional organizations. The Code of Ethics of the Human Factors and Engineering Society (HFES) includes another principle relevant to storytelling: “Avoid sensationalism, exaggeration, and superficiality that constitutes deception.” The American Psychological Association (APA) has a detailed code of ethics covering similar aspects of working with people as part of your research.

      All of these ethical considerations come into play when you are collecting, creating, or telling user experience stories.

Acknowledge your own influence

      Think carefully about your own ability to influence user research. This influence, or “reflexivity,” works in both directions: Our presence, attitudes, and behavior can affect the people we work with, and they can affect us.

      For example, there is a narrow line between providing people with an opportunity to tell their story and leading them to perspectives, opinions, or ideas that they might not express without your urging. This sort of influence might include the following:

       Suggesting terminology, especially emotional terminology

       Asking leading questions that hint at a “right” answer

       Going beyond eliciting stories to suggesting issues before the participant brings them up

       Translating concepts from the participant’s frame of reference to your own

      These are, of course, pitfalls of any user research. It’s just good practice to think carefully about how much the situation in which you collected your observations is an accurate reflection of “real life.” It’s especially important in stories because their emotional impact can magnify any distortions or simply convince you (or someone else) of something that may not be exactly true.

Tell the story accurately

      Stories can be a good way to communicate uncomfortable truths or even to shock. For example, when you have learned something in a user research or evaluation session that contradicts the team’s current beliefs, a story can provide the explanation and context to help make the news believable.

      

A story can deliver good news… and bad news

      Ginny Redish, an early advocate of the value of observing users, tells this story about using information collected in the field to share bad news about a product idea.

      This is a story from the days when many companies were first moving from dumb terminals with green screens to graphical user interfaces (GUIs), and object-oriented programming was just becoming popular. One of my clients was very excited about the new possibilities, and the developers decided to redo one of their major applications as a test case.

      They sent business analysts out to the field to gather requirements from the field staff who were the users of this application (and many others that the company had). The business analysts went out all fired up to tell field staff about the new computers they would be getting—after all, GUIs couldn’t run on the old dumb terminals.

      But their enthusiasm was dampened by the users’ realities and the users’ stories. The business analysts brought back photos of the users’ workspaces (incredibly cramped, with not an inch of space for a second monitor), and they told the story of meeting with Jack, a 50-year-old who had been doing the job in one town for more than 20 years. They played their tape of Jack asking, ‘Are you changing all of our applications? No? Then we’ll still need our old terminals for all our other work. Where are we going to put the computer we’ll need to use your new program?’

      Jack’s story was bad—but very important—news for the developers. No one had thought beyond the excitement of picking one application to change.”

      The more difficult the message your story has to communicate, the more careful you must be to ensure that the story reflects reality.

      When stories are presented as part of research, you have an obligation to be sure that they reflect the full picture of the people and context. You need to make sure that the stories are “true,” meaning that they are an accurate representation of the situations involved, whether you are telling the story of a single event from a single participant or creating a composite with material from several different people.

      All of this does not mean that the story should be a verbatim account. For instance, you might change details to protect the anonymity or privacy of the participant. But the story must reflect the real details, not be overstated or idealized beyond what you would present in any other analysis report.

      This is just good practice. If you are using stories to help guide user experience design, you want them to accurately express what you know about users and their context. Another way to think about accuracy is to look at whether the stories you have chosen to tell reflect the big picture. It’s easy to be seduced by an interesting story that is an outlier, an interesting or amusing anecdote that does little to illuminate the user experience (or worse, seems to poke fun at the person). It’s also easy to avoid stories that carry a message you don’t like. Maybe it suggests a design direction you don’t agree with. Or it reinforces an idea that your audience doesn’t want to hear.

      The need to keep stories true is especially important if you work in a domain where there are experts. If you distort details, you risk creating a story that distracts the expert audience from the point of the story with its inaccuracies. And by sticking close to the original story, you can shift easily into a more detailed account when necessary by going back to the original research.

      The common saying, “Never let the facts get in the way of a good story,” presents a fine line that storytellers walk all the time. Performing storytellers have a greater latitude here, as the story is their product, and the audience’s perceived value of their story is something close to instantaneous. The audience doesn’t have to hold it, handle it, click on it, operate its menus, plug it in, or interface it to their PC. They simply have to experience the story.

      Experience designers have a much finer line to walk, but walk it they must. To only relate facts is not storytelling, it’s regurgitation. On the other hand, to play fast and loose with the facts risks distorting the truth, which diminishes the value of the story.

Keep the story authentic

      An audience may not actually comment on your story’s authenticity. But if it isn’t authentic, they will absolutely notice. One of the challenges in using research data as the basis for a story is deciding how much to “clean up” the language or details from the way you originally heard them.

      There are many issues here. For example, if there is a large difference in socioeconomic class or authority between the participant and your audience, you have to decide whether a verbatim transcript will keep a story “true” or whether it might inadvertently make the person you heard it from seem less educated or competent than they are. There is a careful balance between preserving the original form of expression and harming the dignity of your source.

      

Cleaning up spoken language for written presentation

      Caroline Jarrett works with government agencies on their communication with citizens and businesses. In these projects, she is aware of her role as an intermediary between ordinary people and their government.

      I conducted a series of informal visits with small business owners, where they chatted happily