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.

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.