The Magazine of the Usability Professionals' Association
By John Thomas
Stories are motivating and memorable. They can help us understand our customers and design for their needs. This article gives practical guidelines to help make good stories.
An alternative or adjunct to surveys and focus groups is to elicit stories from potential users about their current situations, problems, and fantasies. People can be more revealing about their true motives in the context of metaphor and story.
As described by Zaltman in Fast Company in March 1998 and Leiber in Fortune in February 1997, people can be more revealing about their true motives in the context of metaphor and story. “Oh, is your child still in diapers?!” According to Zaltman’s article, this is the "worst thing" for a parent to hear someone ask. "Kimberly-Clark assigned a small team to the task of probing the market....When they sat down in the homes of their customers to hear real-life stories, they discovered a few things… The stress in toilet training came from parents' feelings of failure, and you'd never get people to admit that in a focus group."
Scenarios can help developers gain understanding of users, contexts, and goals. This is well-explored in Carroll’s 1995 edited book on Scenario-Based Design. The authors represent a range of approaches, but the basic idea in all cases is to bring to the design of systems well articulated “what if” stories about users using the system in actual contexts. Such an approach brings to light potential issues and inconsistencies and helps avoid the ambiguities inherent in general statements of functionality.
People are social animals, and if you can arrange for developers to gain an intuitive, story-based understanding of users, they will tend to make better and more consistent decisions. The user’s “real” requirements are often imperfectly reflected in documentation. Important requirements are often too “obvious” to be explicit. Requirements often pull in different directions. A common understanding based on shared stories helps “fill in the gaps” and resolve conflicts.
Creating realistic scenarios depends on a well-developed understanding of users, tasks, and contexts. Thomas and Kellogg, in their 1989 article on “ecological gaps,” point out ways in which laboratory tasks may fail to reflect real world usage. Scenarios may help overcome such issues by putting users into motivational contexts similar to real-world situations.
In the mid-1980s, I worked on an early voice messaging system called the Audio Distribution System. We conducted traditional usability studies to create good mappings from telephone keypad to system functionality. What proved a larger problem, however, was simply having people think to use the voice messaging system instead of writing a memo. What proved effective was to create and disseminate video stories showing how and when to use the system. For instance, in one scene, I was sitting in an office thinking aloud about a memo that I needed to send to a colleague. Then the idea “occurred to me” to send an audio message instead. In my externalized self-talk, I reasoned this would be faster, easier, and more personal.
At a small additional cost, valuable stories can be solicited from users. These can be collected during problem resolution, encouraged on a website, or gathered in specific targeted interviews.
Stories relate to the social nature of people. We have all experienced a million interpersonal interactions, and in our entertainment-rich culture, we have vicariously experienced an even larger variety of social situations than encountered “in real life.” Good stories about people immediately involve us.
Consider how easy it is to remember The Three Bears and how hard it is for a novice to learn the first few chapters of a typical computer language manual. Part of the reason is that people are not novices about The Three Bears. We come to the story with an understanding of families, chairs, porridge being too hot, not wanting our things wrecked, etc. The story also builds by adding to what is already understood. By contrast, computer manuals often present numerous propositions without a tie-in to anything concrete. We have no idea why we should care about these propositions, nor do we have any sense of how we might actually use them to solve a real problem.
In Jaws, we are immediately confronted with life and death; in computer manuals we may not discover until chapter five how to print, “Hello World.” The motivational and memorial aspects of stories work in concert as detailed in Turner’s 1996 book, The Literary Mind and Paulos’ 1998 book Once Upon a Number.
In his 1997 book Story, McKee points out that the overall structure of a story has three basic dimensions: character (users, stakeholders), plot (task, sequence of events), and setting (environment, context). These are separate yet interrelated dimensions. For instance, the environment provides problems and dilemmas for the hero and the hero’s choices change the environment.
Below are some general guidelines for good stories.
Perhaps the most common story-related confusion in the software industry is mistaking “characterization” for “character.” Character, as noted by Aristotle, is revealed by choices under pressure, and therefore reflects deep aspects of a person. For example, in (ital)The Lord of the Rings, Frodo chooses a dangerous quest to destroy the ring over the safety and comfort of the Shire. Characterization only deals with surface features. Many recent video games allow users to choose the body, facial features, and clothing of game avatars. While this customization may have value, it has nothing to do with underlying character. Similarly, usability professionals often try to “flesh out” scenarios by adding superficial details to portrayed users. Instead of talking about “Mary” using an application, we learn that “Mary” is a forty-three-year-old soccer mom with a Master’s Degree in Marine Biology who likes Chinese cooking. Such details typically give us no additional insight into how or why Mary will be using a particular application, and more importantly, they do not make us really (ital)care about Mary.
What readers want in terms of heroes, are people who have a vital goal and must overcome many difficult obstacles to achieve that goal; people who will consider sacrificing anything to reach that goal. The heroes who are most likely to engage us are those who fit this mold. In the case of Mary, it would be much more interesting to learn about Mary’s passionate, but hard to attain goals. For example, perhaps she is having great difficulty meeting her career goals because of the time constraints of her role as a mother. The requirements for a PDA can be contextualized as helping her meet her goals. This can help both to motivate developers and to provide a rational basis for design trade-offs. Soccer, marine biology, and Chinese cooking are particularities that are mere distractions in this context. Such details will not increase motivation or empathy. Time constraints, however, are part of the general human condition, and everyone on the development team can relate in their own way.
In the example story (see sidebar), I finesse the necessity to create an engaging character by making the reader the protagonist. IBMers can all relate to competition and deadlines while adding more detail would simply distract from the core points.
Interesting plots show a protagonist facing a series of problems and surprises. Problems arise when something changes in the physical world (suddenly, a huge stone is rolling down toward Indiana Jones) or when knowledge changes (Luke Skywalker discovers that Darth Vader is his father). During a scene, there is typically some change in value from beginning to end. Various values can change polarity—prosperity versus destitution; physical health versus serious illness; self-assuredness versus self-doubt. In a short story, use only a few values. In a long, complex story, use a larger number of values to provide a more interesting dramatic texture.
In the example story, the implication of values includes life (the car accident), win/lose (the account), and, by implication, money and fame for the reader.
In usability, setting will be constrained by the real contexts of the product or service you are interested in. However, some remaining choices obviously lend themselves to more interesting and engaging plots and characters. Your product may be useful for coordinating ad hoc teams “on the fly.” You could illustrate this functionality by setting the story in terms of kids figuring out where to party on Saturday night, or in terms of international disease control experts trying to limit an outbreak of Ebola virus.
In the example story, the setting is determined by the goals of the experiment but is deemed of interest to the experimental subjects (though not the general public).
Story lives on conflict. A protagonist who is “forced” to choose between good and bad does not capture our interest. We (ital)are interested if they must choose between saving a village and saving their own child. We experience conflicts at different levels. There are conflicts between our goals and physical or social reality—we must meet with someone but have no time to get there. Such conflicts often form the meat of scenarios that illustrate the utility of technology (for example, a conference call).Conflicts can also occur in the interpersonal realm. A scenario about the utility of conference calls can be made more interesting by adding interpersonal conflict; for instance, the user’s manager initially insists that they take a physical trip while the user’s family insists they not take that trip. A further level of conflict can exist within a single person; we might add interest by revealing inner dialogue showing the user thinking about what to do. Stories with all three levels of conflict are typically more interesting and entertaining.
Figure 1: Stories live on conflict (Credit Alan Saunders)
In the example, there are conflicts between IBM and its competitor, and between developing a solution quickly and developing one with quality.
If readers don’t care about your protagonist, all is lost. Typically it works best to let the reader “work their way into” the character from the outside as explicated in Frey’s book, How to Write a Damned Good Novel. For example: “The wind howled and pellets of ice began to slash across John’s face.” (External objective reality). “He pulled his coat tighter and shivered.” (Externally observable action). “Blast it! It’s too cold to be out here.” (Sensation and emotion). “Why do I always let her talk me into these hair-brained schemes?” (Inner voice and conflict).
This is finessed in the example because the reader is the protagonist. This only works because, for these subjects, this situation is similar to one they can imagine actually facing.
Text is what is said explicitly while subtext is the underlying emotional meaning. It is more powerful to let the reader or listener discover for themselves what is happening between two characters. A love scene set at a couple’s own wedding is rather boring. Consider how short the actual wedding scene is in The Sound of Music for example. Interest in the love between the Captain and Maria is generated, not by their blissfully elaborate wedding, but by what remains unspoken in their earlier conversations.
Without stating it boldly, there is an implication in the example that the reader’s raise, rating, and reputation may be on the line. Allowing the reader to infer this is more powerfully engaging than stating it explicitly.
To write sentences that keep interest, put the most important information at the end. Compare: “I’ll kill you if you don’t give me the key to your safe right now,” with “The key. Hand it over now or you die.” As scientists and engineers, we often are trained to use very generic verbs like “has” and “is.” More active and specific verbs, however, are more interesting and vivid. “John went across the room.” How? Did he crawl, sprint, limp, dance, or stride? In general, it is more effective to show rather than tell. Compare the credibility of saying, “Our product is so simple, even a child can use it” with a video showing a two-year old using the product.
Note the value-laden endings of sentences even in the very short example story: “strong competitor,” “serious automobile accident,” “make a decision now,” “solve their problem,” “your boss will be extremely impressed.” Compare the impact with (ital)beginning these sentences with the relevant phrase.
Figure 2: Suspense keeps interest (Credit: Agnieszka Mazur)
Constructing usability-related stories is easier than facing a totally blank page because your users, tasks, and contexts will suggest constraints that should be viewed as spurs rather than limits to creativity. One common method for creating new stories is to take an old story Romeo and Juliet) and put it in a new setting (West Side Story). You may also find inspiration from the “edges” of your own experience. When did new technology tempt you to smash it with a hammer or bring such ecstasy you wanted to share it with everyone? It may be useful to look at some particular aspect of a product or service and ask questions: Why is this here? What is its history? Where did it come from? Who has been involved?
Constructing stories is essentially designing a complex, multi-dimensional communication. It is a skill, or rather a whole interrelated family of skills. Just as you would not expect merely to read a couple books on painting, cooking, or golf to become expert, so too, becoming a proficient storyteller will require practice as well as knowledge.
While we have focused on how storytelling skills may enhance your professional life as a usability expert, such skills are also useful and pleasurable in other areas. An excellent way to answer questions in a job interview is with a three sentence story that recounts a problem, how you solved it, and what the results were. Even more importantly, friends and relatives will appreciate the authenticity of stories about your own personal experiences; stories, after all, are life sharing. Stories allow us to share the union of our experiences, not just the intersection.
Sidebar: Example Story
I created this story to help ensure that the behavior of subjects (all IBM professionals) in an experiment would mirror as closely as possible their behavior in real life.
“IBM is vying for a large software deal with Genysis, although another product is a strong competitor. You’ve been called in at the last minute because the person who was supposed to give a client presentation crashed in a serious automobile accident. The client exec wanted to reschedule the meeting, but Genysis insists that they need to make a decision now. You will meet with the client in about an hour and be asked at that point to provide a preliminary and high level “design” to solve their problem. If you can pull this off, your boss will be extremely impressed.”
John Thomas’ current work at IBM’s T.J. Watson Research Center is in understanding psychological complexity and developing associated measures and tools. Prior work focused on developing tools, techniques, and representations to support the capture, creation, analysis, organization, finding, and use of stories and scenarios. John received a Ph.D. in psychology from Michigan in 1971 and has worked mainly in the field of Human Computer Interaction since 1973.
Usability Professionals' Association
promoting usability concepts and techniques worldwide
User Experience Magazine is by and about usability professionals, featuring significant and unique articles dealing with the broad field of usability and the user experience.
This article was originally printed in User Experience Magazine, Volume 7, Issue 2, 2008.
© Usability Professionals' Association
Contact UPA at http://www.usabilityprofessionals.org/about_upa/contact_upa.html