When you create a story, you must consider the distance between the audience and the context of the story. How far will the audience have to travel in their imaginations to understand the details of the story and the motivations of the characters? Think of the story as a bridge between the audience as they are now and the audience as you want them to be.

The shorter your story, the more important it is to gauge this distance properly. In a novel or a three-act play, you have plenty of time to gradually introduce your audience to all the quirks of the world of your story. In the brief format of most UX stories, you have to rely on the audience to fill in the gaps. If the story is based on an experience that is familiar to them, it is easier for them to do this, and you can spend less time laying the groundwork. Once you know the distance between your audience and your context, you will be able to choose the details worth including and the ones that can be tacitly implied.

Steve Denning makes this point about what he calls springboard stories. The example story he uses in many of his workshops is about a healthcare worker in Zambia who finds the answer to a medical question on the Web. Here is an excerpt:

The story as he told it at the World Bank went on to draw a connection between the health care worker and the work of that organization. There are many versions of the story; it is altered each time Denning tells it, as he adds and subtracts details to suit his audience. For example, if he tells the story to healthcare workers, he might include the specific information that the health worker in Zambia actually looked up. People interested in knowledge management or Web design might want details about how the health worker knew about the U.S. Center for Disease Control and Prevention or how he located the information on its site. These changes to the basic story help the audience connect to it and, more importantly, give them a context in which they can make the story their own.

Now, imagine that you are working on designing an electronic medical records system and want to create a story that would help explain the daily routine of hospital nurses as they check in on patients and keep records of their medical conditions. Table 12-1 shows just some of the relationships you might have to consider and the information they might need to connect with your story.

For example, you might include details such as how many patients the nurse visits each hour, or a memory of an incident where these medical records were critical. These story fragments are written from three different perspectives.

User experience designers often have to work with different groups of people with different perspectives and even different technical languages. In Isobel Frean’s story (in Chapter 8) about writing stories as part of the process of creating a new standard, the scenarios explained the context and activities for each function in a way that the nurses and other medical staff could understand them and review them for accuracy. The stories were connected to technical data models, so that the designers and engineers working on the standard could also understand how the computer function fit into that context.

Translating Tasks Into “Medical Speak”

One of the most difficult challenges I’ve faced in usability testing is coming up with good stories to start off tasks for nurses and doctors. I want the scenarios to be compelling, creating a realistic interaction with the site or database we are testing, but I don’t have the medical training that will let me speak comfortably using their terminology.

At first, I tried creating broad, general scenarios: “A patient with breast cancer is not responding to the normal standard of care, so you want to see if there is a treatment clinical trial that might be effective for her.”

These scenarios didn’t work. The doctors would fire questions at me like I was a new medical student on a television show. “What has already been tried? Is there metastasis?” In other words, questions I couldn’t begin to answer and that steered the discussion away from its purpose.

Since I didn’t have enough clinical details to make a compelling case for a healthcare professional to respond to, I tried adding more medical details. That didn’t work because inevitably I stumbled over a word, and the façade that I actually knew something about medicine came tumbling down.

The solution was to let them create their own tasks. I would start a story, using the same sort of general language. But then I would ask them to finish telling it for me. “Have you ever had a similar situation?” They could usually come up with something appropriate. I’d get them to tell me a little bit about it, and then send them off to find the answer.

Over time, I’m getting better at it. The medical professionals I work with are less likely to stare blankly, trying to imagine what I’m getting at, and more likely to come up with a good story of their own.

In user experience design, the work is often done by people who have little to no direct experience with the context or the people in the context. User research bridges this gap. Stories are an effective way to bring the details from that research back to the project team in a meaningful way.

A good example of this is a project that Adaptive Path, a UX design group, took on after reading an open letter to Apple CEO Steve Jobs asking why the company that invented the iPod couldn’t create a better portable medical device for people with diabetes. The story of this project is told in a series of blog entries at www.adaptivepath.com/blog. In one, Dan Saffer writes, “I read this plea and thought, wait, it’s not just Steve [Jobs] and Jonny [chief Apple designer Jonathan Ive] who can do this stuff. Don’t I work at a design firm? Don’t we have the experience design tools to tackle this challenge? Why, yes. Yes, we did.”

One striking aspect of this project is that they started by listening—meeting diabetics and diabetes educators—for the first three weeks. They came back with many story fragments to use in their presentation to help people understand some of what they learned:

Notice that the Adaptive Path designers didn’t sit down with a list of facts and technical details about diabetes and insulin. They started by listening to people with diabetes and learning what their lives were like. These stories had a clear influence on their design process. Instead of focusing on the medical processes and data, they focused on the experience of using the device. Sharing those stories helps anyone reading about the project also have those moments of insight.

It can be hard work gathering enough information to bridge gaps in understanding. But that’s still far more preferable than situations where everyone on the project mistakenly thinks they understand the audience. These unacknowledged gaps can be the hardest to fill—both for the storyteller and for the user experience design team in general.

Rahel Baillie’s story in Chapter 6 is about a company that thought it knew its users, but learned by listening that it didn’t have the whole picture. While we were gathering stories for this book, we found several similar situations. All of the people we talked to mentioned how hard it is to get this information across in a constructive way. Depending on how deep the disconnect is, bringing it up can challenge basic beliefs within a company.

One tactic to bridge the gap between the story’s audience and the characters in it is by building a picture that highlights not only the ways in which these situations are different from the audience’s expectations, but also to show why the characters’ attitudes and behaviors made sense for them.

Seeing the Business from their Point of View

Our customers are the sort of folks who run a shop or a small industrial operation. It’s really hard for ambitious product managers in a large company to understand the lives of their customers.

Folks on our side of the screen live and die by email, promotions, and stock options. We have people we report to and colleagues we have to collaborate with. We may worry about meeting our sales targets, but we don’t usually have to agonize over the electric bill or the office rent. The hardest thing for us to understand is that someone running a small company might feel very differently.

When we go out to do site visits, we meet people who really love what they do, and often do it very well. They are printers and photographers and even auto repair companies. Their attitude toward managing payroll and their accounting is that it’s a necessary evil, and the less time they have to spend on it, the better.

It’s so easy for the product team to assume that they are not ambitious or that they aren’t very good at what they do. What else could explain this attitude toward managing their business?

What we see is how good they are at their work and how much they love it—a printer who can do amazing things with color, or a photographer who loves taking the time to really capture a portrait, not just a picture. We try to bring back samples of their work along with the other photographs. They illustrate stories we use to close the gap so that our team can understand who our customers are and why doing the work is more important to them than management chores.

This story is told through the eyes of a user experience research team. It uses their role as a bridge between two worlds—the customers and their colleagues. This explicit use of the researchers’ experience is a style that John Van Mannen calls a “confessional tale” in his book on writing ethnography, Tales of the Field. (See the section in Chapter 15 on Written stories for a more detailed discussion.)

One variation on the problem of simply not understanding the context of the story can be found in a mirror story: stories about ourselves. Kevin coined this phrase for the stories we want to tell when we wake up in the morning, look in the mirror, and think, “I like that guy! He’s who I want to work for. My stories should be about him because he’s a heck of a nice guy.”

There’s nothing wrong with a mirror story in itself. The problem is that one main character cannot represent all people. So, if you see a pattern developing of stories that are all about the same character, or all the stories could apply to the people working on the design, it may be time for an intervention.

Maybe you can address this problem directly, but usually it requires a more subtle approach. One solution is to find another way to put the audience into the story. One way to do this is to make them a helpful companion to the main character. Tell the story through their eyes, even though the point of the story is focused on another character. In The Anatomy of a Screenplay, Dan Decker, a script writing coach, calls this a “window character”—the person through whom we see the real story unfold.

One value of using stories in user experience design is to get the team out of its comfort zone by helping people imagine situations they don’t know much about. Using too many mirror stories defeats that purpose by limiting the number of perspectives and experiences the stories represent.

This problem is not limited to user experience. It’s hard to remember that you are not the center of the universe. As John Andrew Holmes, American physician and writer, put it, “It is well to remember that the entire universe, with one trifling exception, is composed of others.”

The next relationship to consider is the one between you and your audience. You may find yourself:

Each of these relationships brings with it different degrees of shared experience or background and different expectations for how you will communicate. Your relationship to the audience affects not only what stories you choose to tell, but also how you tell them.

And, of course, you will frequently find yourself in a group with several of these relationships, having to bridge them all at once. When that happens, you’ve got to shift modes, for example go from the 50,000-foot view down to the 100-foot view, and do it in short order. One audience may need a high-level perspective to understand the story, but if you stay at that level too long, the story will seem ungrounded and disconnected from real needs. Another may be focused on the details that support the high-level view. Too much low-level can bog down your story. It’s one of the hardest challenges, but if you’re prepared for a heterogeneous audience, you’ll be better able to adjust quickly.

Both the relationship between you and the audience and the one between the audience and the story affect all communication in user experience design, especially the challenges of presenting design concepts or user research reports. In a 2005 workshop on writing usability test reports, the group identified the audience as one of the most important considerations in designing a report, saying that, “The content, presentation or writing style, and level of detail can all be affected by differences in business context, evaluation method, and the relationship of the author to the audience.”

In the next chapters, as you examine the different ingredients in a story, plan for different presentation styles, and think about structure, keep the audience in mind. Craft a story that reflects your relationship with them.

Do you have shared references and terminology that you can rely on? These can be shortcuts, but they can also make the story impossible for outsiders to understand, so be sure you aren’t excluding part of your audience. Terminology can be tricky in any world, but you also need to watch out for implicit knowledge of technical concepts and detailed facts.

“But an Elam 251 Had Pale Green Paint!”

My husband, John Chester, is an audio engineer. Worse, he’s an engineer’s engineer, who can tell stories based on electronic part numbers. One year, he led a panel discussion at the Audio Engineering Society on the history of live sound. He brought together some of the leading audio folks from the early days of live concerts—people who did the sound for Woodstock and the Newport festivals—to reminisce about their work and the evolution of concert audio.

I decided that this would be a discussion I might understand. I expected to hear some of the great stories about how those early festivals got their sound. And I was mostly right.

One of the photos was from the Newport Jazz Festival. John suggested that something in the photo was a U-47 and a lively discussion broke out. “No, it’s an ELAM 251.” “Couldn’t be...those had pale green paint, and this doesn’t.” The final consensus was that it was a U-48.

At the time, I wasn’t even sure what they were talking about. It turned out to be a debate about the exact model of the microphone in the picture. Like I said, stories based on electronic part numbers.

The point here is that everyone in the room understood. This wasn’t obscure to them. They all knew these mics. It was just how they talked.

In Adaptive Path’s project to create a diabetes-monitoring device, none of the project team knew much about the disease, so everyone had the same relationship to the people who would use the device. Many of the people who read their account of the project will be in the same situation. The stories on the blog describe their process of discovery and design from this shared perspective.

We can imagine that someone with diabetes would read these stories differently, based on their very different relationship. Their first questions might be, “Do they get it? Does the experience they are designing for match mine?” In this case, you want your stories to show that you do get it.

A similarly imbalanced relationship might exist when you are working on a system for experts such as health professionals, engineers, or people with deep experience in their business. Things that were eye-opening insights to you may be “ho-hum” to them. Your stories can acknowledge that and show how collecting the story helped you understand something the audience already knew. You might even make yourself, as the researcher, the center of the story. This approach is often used in reports from ethnographic fieldwork, as authors share not only the final conclusions, but also the story of how they reached those conclusions.

Another case in which the relationships are not the same would be one in which you have done extensive field research and are bringing your insights back to a team. At the beginning of the project, you and your story audience might have been equally distant from the context, but now you are closer to it and bringing them in to share your new understanding.

Kevin’s story, Parking Technology, in Chapter 10, is an example of this relationship. He brought an understanding of the urban environment in which automated parking made a lot of sense; the other researchers brought an awareness of legal and technical issues.

User experience professionals are often brought into a project to share the perspectives that their skills give them. But other perspectives are also important. Some design challenges require an understanding of several cultural perspectives. For example, if a company wanted to make a low-cost ebook device targeted to third-world markets, it might have to consider several social and legal perspectives:

The key is to share different perspectives with respect. Each story can acknowledge the other contexts and how they overlap. In doing this, you can explore possibilities outside of the audience’s comfort zone of easy ideas. If you are pushing a group to consider a new idea, it is helpful to use examples and stories that are simple or easy to relate to their own experiences. One solution is to look for ways to recast the example. For example, you could talk about power requirements as a mobile issue, not just a local resource issue. An interface for a low-literacy population can also be about breakthrough ease-of-use.

There are many good reasons to keep your stories short: business meetings often have a packed agenda and attention spans are short. But don’t cut your stories so short that you leave out the details that will help your audience understand them. If you skip too much of the middle, they may not be able to follow you to the end.

This next story is a cautionary tale. Sometimes, you need to find the right stories for your audience or the right way to tell them. As we said in Chapter 11, you may need to be willing to try different approaches until you find one that works.

Learning From a Tough Room

Some five years after finishing graduate school and entering industry, I still had some vestiges of academia clinging to my thinking. So when I was asked to help find a way to better express a complex chart of user experience technologies to my department of researchers, my approach was based on a number of wrong assumptions. The chart was a spider chart—a graph where the axes were Intelligence, Connection, and User Interface. Scattered all over the chart were references to general and specific research areas that were colored according to which of three categories they fell in—Capability, Technology, and Realization. I’ll spare you a picture of the chart here—suffice it to say that it was complex. The chart also acted as a collection of various technologies and concepts my department was interested in, and I was asked to help better express it—to help tell it.

We started by reducing the number of items on the chart, picking a choice few, and showing the relevant connections between them. Essentially, we were treating a few technologies as separate story characters and showing how the paths of these characters crossed. This method fell flat with the audience. I assumed that if I showed the audience a loose structure, they would fill in the meaning. They didn’t.

I next created a set of short stories that specifically showed how small sets of the various technologies worked together and even evolved from one to another. For each story, I listed specific technology and cultural assumptions and references to established internal research projects. Again, my effort fell flat. I’d assumed that my audience was interested in reading. Half-page stories were simply too long, I was told.

Next, I kept the same basic structure listing assumptions and research references, but dramatically shortened each story to the bare minimum, typically using only one sentence each for the story setup/character motivation, core of the story, and then story conclusion. I also included an “experience path” for each story that listed a proposed evolution of technologies and experiences. I basically broke it all down for them. But again it fell flat. I assumed that my audience actually wanted what they asked for. I also assumed that if I gave them all the necessary component parts of a full experience, including content, structure, and a way to put it together, they would mentally construct an experience of their own. They didn’t.

Distilling the stories further, I decided that for a final year report I would tell an animated visual story. For a half-hour presentation, I produced 17 short animations with the help of a graphic artist, all based on the previous story work. I finished the presentation with slides that made the case for what our department should be researching going forward, as suggested by the stories. When it was over, it was a very quiet conference room. It was not the response I was hoping for.

Out of 17 stories, one of them sparked their interest enough to say, “Hey, that looks good. Can we do that? Is that possible? Call Bob in here to take a look at this.” I was lucky. One story triggered action. And that was a start.

When a story is rejected, you may have tried to take the audience too far in a single jump. One tactic is to start with a story that illuminates what currently exists before you tell one that reaches for something completely new.

Steve Denning says that stories are a way to leap past logical arguments that have to be won individually, one person at a time. Pioneers in accessibility spend much of their time advocating for good user experiences for people with disabilities. Accessibility advocates have tried many different approaches, from appeals to good will to making the case for a return on development investment to new laws and litigation.

Recently, we’ve been seeing storytelling used as an advocacy tool. This approach is similar to the way Michael Anderson used a simple story to draw an analogy, as seen in Chapter 2.

Stories as a New Approach

Mike Paciello helped start the W3C’s Web Accessibility Initiative (WAI) and has twice served on committees to draft accessibility regulations in the U.S. In 2009, he ran a workshop at the Cal-State Northridge Conference on Technology and People with Disabilities (CSUN). He used some of the exercises from our storytelling workshop (and this book). Here’s how he described the event:

We had eight participants from many different backgrounds: one person with low vision, and one who was blind, two usability engineers, three from either the U.S. or Canadian federal government, four international, two from private industry. Two were familiar with storytelling, but none had much experience with it.

To a person, each individual was motivated to come to this workshop because of years of negative vibes from engineers, developers, and designers when it came to leveraging, prioritizing, and then implementing accessibility in Web and software applications. Two of the individuals had thrown in the proverbial towel and decided that the only tactic left was to resort to litigation.

However, storytelling gave them a new light. Properly structured stories around personas could have a strong impact. They saw how important it was to build empathetic listening skills, and liked experimenting with new ways to use perspective and imagery to make a point.

In the end, they saw storytelling as a positive approach that would help them build relationships.

Sometimes, a simple story can make a point by creating a situation in which the problem is inescapable. Instead of lecturing the audience that they don’t “get it,” the story can create a situation in which they can come to the conclusion on their own.

Accessibility to the Face

Jennifer Sutton found this story for us in a longer blog post by Rob Foster on North Temple’s Web site (http://northtemple.com/2009/03/24/accessibility-to-the-face):

The issues of accessibility are a daily reality for my family. For us, it’s not a political issue at all. Our oldest daughter, Ramona, has cerebral palsy and uses a wheelchair to get around.

Allow me to give you a glimpse of what this aspect of our life is like. Last year, my wife and I took the kids to the Hogle Zoo here in Salt Lake. Before we left, my wife called the information desk to find out if the zoo train was an option for Ramona. Ramona loves to ride on trains.

Anna: Is the train accessible to wheelchairs?

The Girl: Yes.

Anna: So how does that work? How do I actually get the wheelchair on the train?

The Girl: Well, you take the chair to the edge and then you would lift her out and into the train.

Anna: So it’s not wheelchair accessible.

The Girl: No, I guess not.

The girl on the phone had never thought of a real situation. She just had a cursory knowledge of the concept. For her, accessibility was a policy.

A few months ago, Anna called ahead to an Italian restaurant we wanted to visit to find out if we could get inside easily with the wheelchair.

Anna: Is your restaurant accessible?”

Host: Yes.

Anna: So we won’t have any problem getting a wheelchair inside?

Host: Nope.

So we arrived at the restaurant. I walked up a flight of steps and let the host know we had a wheelchair. He had us meet him at the back entrance where we walked through the kitchen and ran into a very tall step.

Host: Oh, I guess there is that one step. Sorry about that.

Now, I’m a pretty big guy, and after 11 years of lifting Ramona and her chair into all kinds of places, one step was not going to keep me from enjoying the evening. I eat steps like that for breakfast. That said, Ramona and her current (non-electric) wheelchair weigh about 170 pounds. We’ve looked at electric (power) wheelchairs for her and the low-end from a weight perspective is about 150 pounds. If she had a power chair, we would not have been eating baked ziti that night.

The movie, Rory O’Shea Was Here (Inside I’m Dancing) makes the same point with a visual image. Two young men in wheelchairs are looking for an apartment. In one scene, they are following a real-estate agent down the street, listening to him describe the glories of an apartment. Suddenly they stop, and we hear the agent keep talking. The camera pulls back to show Rory O’Shea looking up a long set of stairs from his wheelchair. “See a problem?” he asks.

We’ve talked a lot in this chapter about pushing the audience to see a situation in a new light or getting them out of their comfort zone. Your job is to take them on a journey, not abandon them before they have finished it. As Kevin puts it in his performance-oriented storytelling workshops, you have a responsibility to “bring the audience home safely.”

Home Safely

Professional storyteller Laura Packer performs largely to adult audiences with original material. She knows firsthand the importance of bringing the audience home safely. UX stories are not typically this “deep,” but still this is a good lesson on the role and responsibility of the storyteller. All audiences need to feel safe.

One of the great things about storytelling is the way it lets you connect with audiences on a deep level. You can talk about things in stories that you may not be able to address as easily in direct ways. Tough topics, like illness, can be touched on in a story, where the listeners can take in the tale without having to tell you anything personal or worry about you and your horrible experiences.

I do this regularly in a performance; I tell stories that talk about tough subjects with stories that touch on mental illness, abuse, homelessness, cancer, and so on. The audience listens to the story, but by the end there is a resolution, they are back in themselves and know that the experience I’m talking about is not an experience that’s going to haunt them.

When I first started telling these kinds of stories, I didn’t always do a good job of bringing the audience home, making sure they were in a safe place at the end. So my listeners would end up being worried about me or were just unsettled, rather than satisfied listeners. For example, I’d forget to tell them how the illness resolved (even if someone never gets better, the audience needs to know), and they would feel unsettled, some would even ask me what happened. They weren’t in a safe place.

Even stories where characters are injured, die, or have other traumatic experiences can end with safety by using familiar language or tropes. Many fairy tales are quite violent, but at the end “they all lived happily ever after.” Characters may die in myths, but it serves a purpose—the listener understands the symbolic value of the event.

Audience safety is part of the implied contract between teller and listeners. They need to know you won’t leave them out in the woods. As a performing artist, it would be a violation of my audience’s trust if I took them out to the forest and left them, unable to find their way home.

As a storyteller, you are in charge of managing the relationship between the audience and the story, as well as the one between you and the audience. As Laura Packer described, if you leave them feeling too vulnerable, unsettled, or just uncomfortable, they may react badly. This might be as simple as their not liking your story, or it might mean that they reject the whole idea you are trying to communicate.

This doesn’t have to mean always providing a happy ending, but you do have to be sure you provide an ending, either within the story or during the discussion that follows. It’s like taking a college course where the final exam counts for 50% of the grade. In this case, the final images that end the story are at least 50% of what the audience remembers and retells about your story. So bringing them home safely not only refers to the safety of the audience, but also refers to your effectiveness as a storyteller. As we say in End the story well in Chapter 4, this doesn’t have to mean always providing a happy ending.

The Springboard: How Storytelling Ignites Action in Knowledge Era Organizations, Steve Denning

The story of the Adaptive Path’s project to develop the Charmr is told in a series of blog entries: www.adaptivepath.com/blog/2007/08/14/charmr-a-design-concept-for-diabetes-management-devices/

“Towards the Design of Effective Formative Test Reports,” Mary Theofanos and Whitney Quesenbery in the Journal of Usability Studies: www.usabilityprofessionals.org/upa_publications/jus/2005_november/formative.html

Remember that all storytelling is partly about the audience. Each person in the audience hears the story through their own perspective. When you craft your story to take that perspective and their background knowledge into account, the audience can listen to your story without distractions.