Tutorial: Using Stories and Narrative Elements in HCIJohn C. ThomasAbstract: Stories are motivating and memorable. They mo...
Creating realistic scenarios depends on a well-developed understanding of users, tasks and     contexts. Thomas and Kellog...
3.2 Change values for dramatic effects.Interesting plots show a protagonist facing a series of problems and surprises. Pro...
3.   What are the strengths and weaknesses of stories as way to cumulate knowledge in HCI?     Interesting stories depend ...
Upcoming SlideShare
Loading in …5

Stories in HCI


Published on

Proposed tutorial on the use of narrative techniques in HCI

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Stories in HCI

  1. 1. Tutorial: Using Stories and Narrative Elements in HCIJohn C. ThomasAbstract: Stories are motivating and memorable. They motivate because they tie in with the structures ofour social life. They tend to be memorable because they fit well with the way human memory works.There is a growing rekindling of interest in the use of stories in many professions, including HumanComputer Interaction. However, all too often, HCI professionals who use story fail to take full advantageof their power. Stories (as scenarios) are often used only during “storyboarding.” However, the power ofstories can be brought to bear throughout the development process. For instance, eliciting stories frompotential users can lead to a deeper understanding of unmet needs and contexts of use. Stories can alsoserve a useful function in helping users understand how and when to use a product or service. Inaddition, stories of use are an excellent way of communicating issues back to development for futurereleases or alternative products. Stories are not very suitable for describing universal scientificknowledge; however, often in HCI, it is important to capture the particularities of people, contexts, orsystems and here stories can be quite usefulThe desire to use stories, however, is not sufficient for their effective use. This tutorial therefore offerspractical guidelines to make stories more effective. First, I examine the application of stories to thedifferent phases of the development process. Second, I discuss how to make the basic dimensions of astory (character, plot and setting) work. Third, I discuss the power and limitations of story as a form tocumulate and communicate knowledge learned about HCI.1. How can one use stories in HCI? 1.1 To help understand customer needs. An alternative or adjunct to surveys and focus groups is to elicit stories from potential users about their current situations, problems and fantasies. As described by Jerry Zaltman in March 1998 Fast Company and Leiber in February 1997, Fortune, 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 youd never get people to admit that in a focus group." 1.2 To drive design. Scenarios can be used to help developers gain understanding of users, contexts and goals. This topic is well-explored in Carroll’s 1995 edited book on Scenario-Based Design. The authors in this book represent a range of approaches from qualitative ethnography to formal modeling 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. 1.3 To help developers understand users. 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 developers “fill in the gaps” and resolve conflicts. 1.4 To make testing more realistic and comprehensive.
  2. 2. 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. 1.5 To help users understand how to use a system. In the mid-1980’s, 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. 1.6 To provide feedback to development. Despite your best efforts, users will sometimes still be confused, need help, offer suggestions, and provide other potentially vital information. Often, companies are so eager to minimize costs associated with “solving” a specific user’s problem they forgo this information. At a small additional cost, valuable stories can be solicited. These can be collected during problem resolution, encouraged on a website or gathered in specific targeted interviews.2. What makes for a good story? McKee, in his 1997 book, Story, 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 inter-related dimensions. For instance, the environment provides problems and dilemmas for the hero and the hero’s choices change the environment. We present general guidelines for good stories, but how they play out in a specific example depends heavily on purpose. 3.1 Create engaging characters. 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. It therefore reflects deep aspects of a person; for example, in The Lord of the Rings, Frodo chooses going on a dangerous quest to destroy the ring of power over the apparent safety and comfort of the Shire. Characterization deals instead with surface features. Video games allow users to choose the body build, 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 “Mark” using an application, we first learn that “Mark” is a 43 year old soccer dad with a Master’s Degree in Marine Biology who likes Chinese cooking. Such details often give us no additional insight into how or why Mark will be using a particular application and they do not make us (or the development team) really care about Mark. Readers want heroes who have a vital goal and who must overcome many difficult obstacles to achieve that goal. In the case of Mark, it would be much more interesting to learn about Mark’s passionate, but hard to attain goals. For example, perhaps he is having great difficulty meeting his career goals because of the time constraints of his role as father. The requirements for a PDA can be contextualized as helping her meet his 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 except for a handful of developers who happen to share those particular interests. Time constraints, however, are part of the general human condition and everyone on the development team can relate in their own way.
  3. 3. 3.2 Change values for dramatic effects.Interesting plots show a protagonist facing a series of problems and surprises. Problems arisewhen something changes in the physical world (suddenly, a huge stone is rolling down towardIndiana Jones) or when knowledge changes (Luke Skywalker discovers that Darth Vader is hisfather). During a scene, there is typically some change in value from beginning to end. Variousvalues can change polarity; e.g., prosperity vs. destitution; physical health vs. serious illness; self-assuredness vs. self-doubt; freedom vs. enslavement. In a short story, use only a few values. In along, complex story, use a larger number of values to provide a more interesting dramatic texture. 3.3 Choose an interesting setting.In usability, setting will be constrained by the real contexts of the product. However, someremaining choices obviously lend themselves to more interesting and engaging plots andcharacters. Your product may be useful for coordinating ad hoc teams “on the fly.” You couldillustrate this functionality by setting the story in terms of kids figuring out where to party on Saturdaynight or in terms of international disease control experts trying to limit an outbreak of Ebola virus 3.4 Introduce multiple conflict levels.Story lives on conflict. A protagonist who is “forced” to choose between good and bad does notcapture our interest. We are interested if they must choose between saving a village and savingtheir own child. We experience conflicts at different levels. There are conflicts between our goalsand physical/social reality. We must meet with someone but have no time to get there. Suchconflicts often form the meat of scenarios that illustrate the utility of technology (e.g., a conferencecall). Conflicts can also occur in the inter-personal realm. A scenario about the utility of conferencecalls can be made more interesting by adding interpersonal conflict; for instance, the user’smanager initially insists that they take a physical trip while the user’s family insists they not take thattrip. A further level of conflict can exist within a single person; for instance, in this case, we mightadd interest by revealing inner dialogue showing the user arguing with himself or herself about whatto do. Stories with all three levels of conflict are typically more interesting and entertaining.3.5 Create empathy with the protagonist.If readers do not “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 aDamned Good Novel. For example: “The wind howled and pellets of ice began to slash acrossJohn’s face (external objective reality). He pulled his coat tighter and shivered (externallyobservable action). Blast it! It’s too cold to be out here (Sensation and emotion). Why do I alwayslet her talk me into these hair-brained schemes?” (Inner voice and conflict).3.6 Use subtext instead of text.Text is what is said explicitly while subtext is the underlying emotional meaning. It is more powerfulto let the reader or listener discover for themselves what is happening between two characters. Alove scene set at a couple’s own wedding is rather boring. Consider how short the actual weddingscene is in The Sound of Music for example. Interest in the love between the Captain and Maria isgenerated, not by their blissfully elaborate wedding, but by what remains unspoken in their earlierconversations. 3.7 Use suspense and vividness when presenting the story.To write sentences that keep interest, put the most important information at the end. Compare: “I’llkill you if you don’t give me the key to your safe right now.” with “The key. Hand it over now or youdie.” 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 theroom.” How? Did he crawl, sprint, limp, dance, or stride? In general, it is more effective to showrather than tell. Compare the credibility of saying: “Our product is so simple, even a child can use it”with a video actually showing a two-year old correctly using the product.
  4. 4. 3. What are the strengths and weaknesses of stories as way to cumulate knowledge in HCI? Interesting stories depend on the particularities of situations and people. In this sense, they are far removed from the kinds of formal and generic statements that we typically associate with natural science. However, in many cases, what actually “works” depends on the particularities of situations and people. For example, in trying to build systems for use in a vastly different cultural context, much of the value in lessons learned is in the specifics. Good learning stories gleaned from such attempts provide one mechanism for cumulating knowledge across various contexts.4. Conclusion Constructing stories is essentially designing a complex, multi-dimensional communication. It requires an inter-related family of skills. Just as you would not expect merely to read a couple books on painting, cooking or golf and then become expert, so too, becoming a proficient storyteller requires practice as well as explicit knowledge.