Stories in HCI
Download as DOC, PDF1 like701 views
1. Stories can be used throughout the human-computer interaction (HCI) development process, including to understand customer needs, drive design, help developers understand users, make testing more realistic, and provide feedback to development. 2. For a story to be effective in HCI, it should have engaging characters, changing values to create drama, an interesting setting, and introduce multiple levels of conflict. It's also important to create empathy with the protagonist and use subtext rather than explicitly stating everything. 3. Stories are better than generic statements at capturing particularities of situations and people, which is important for building systems in different cultural contexts. However, stories are not well-suited for describing universal scientific knowledge.
Stories in HCI
- 1. Tutorial: Using Stories and Narrative Elements in HCI John C. Thomas Abstract: Stories are motivating and memorable. They motivate because they tie in with the structures of our 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 Human Computer Interaction. However, all too often, HCI professionals who use story fail to take full advantage of their power. Stories (as scenarios) are often used only during “storyboarding.” However, the power of stories can be brought to bear throughout the development process. For instance, eliciting stories from potential users can lead to a deeper understanding of unmet needs and contexts of use. Stories can also serve a useful function in helping users understand how and when to use a product or service. In addition, stories of use are an excellent way of communicating issues back to development for future releases or alternative products. Stories are not very suitable for describing universal scientific knowledge; however, often in HCI, it is important to capture the particularities of people, contexts, or systems and here stories can be quite useful The desire to use stories, however, is not sufficient for their effective use. This tutorial therefore offers practical guidelines to make stories more effective. First, I examine the application of stories to the different phases of the development process. Second, I discuss how to make the basic dimensions of a story (character, plot and setting) work. Third, I discuss the power and limitations of story as a form to cumulate 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 you'd 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. 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.2 Change values for dramatic effects. 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; 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 a long, 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, 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 3.4 Introduce multiple conflict levels. Story lives on conflict. A protagonist who is “forced” to choose between good and bad does not capture our interest. We 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/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 (e.g., a conference call). Conflicts can also occur in the inter-personal 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; for instance, in this case, we might add interest by revealing inner dialogue showing the user arguing with himself or herself about what to 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 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). 3.6 Use subtext instead of text. 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. 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’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 actually showing a two-year old correctly using the product.
- 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.