Design as Storytelling*

Thomas Erickson

Apple Computer, Inc.

(now at) snowfall@acm.org

 

 


Consider the following description of an architect beginning work (Wong , 1992):

He placed the site plan on the table and rolled out the tracing paper over the plan. In order to become familiar with the site, he started by sketching 'bubble diagrams' and making annotations on the tracing paper. He was able to see through the translucent tracing paper to the site plan underneath The design built progressively with each new layer of tracing paper, amorphous forms transformed into partitions of space.


I like this description. Just roll out the tracing paper and start sketching. Get familiar with the site. Play around. Explore alternatives. And over time, a design gradually comes into being. This feels like such an natural, easy, enjoyable way to begin.

Pity the poor interaction designer whose terrain is less tangible. Rather than an easily mapped site, our terrain is a situation, a set of tasks embedded in an environment that is as much cultural and social as it is physical. How does one come to grips with something that is so fluid and ephemeral? Beginning does not seem so easy.

Yet, I claim that beginning is not so difficult. The difficulty is that interaction designers have not said much about how they begin the process of design. Little is said about what to do before you know what to do. Because interaction design has strong roots in the social sciences with their positivist approaches to studying and analyzing behavior, little has been written about non-formal methods, approaches which might serve as an analog to the architect's playful, exploratory sketching described above.

In this article, I want to discuss one of the non-formal methods I use: storytelling. Storytelling is an integral part of my approach to design, both at the earliest stages, as well as later on in the process.

I have a repertoire of stories that I've built up over my years of design practice. I collect them. I write them. I tell them. I piece together new stories out of bits of old ones. I make up stories about my own observations and experiences. I use these stories to generate discussion, to inform, to persuade. I notice that other designers have their own collections of stories as well, and often use them in similar ways. Stories are very powerful tools.

I suspect stories, in particular, haven't been discussed much because they aren't... well, stories aren't very respectable. Stories are subjective. Stories are ambiguous. Stories are particular. They are at odds with the scientific drive towards objective, generalizable, repeatable findings. In spite of this -- or, I will suggest, in part because of this -- stories are of great value to the interaction designer.

So what I want to do is talk about how I use stories in the design process, and consider some of the properties that make stories such useful tools. However, before getting to stories, let's step back, and talk a bit about design.

Design as Communication


In my view, design is not just about making things. Design is a social, collaborative activity. The day when one person conceived, developed, produced, and sold a designed object is largely gone. Much design -- particularly interaction design -- occurs in the context of a large organization, or is distributed among a number of smaller organizations. Design is a distributed social process, and, as such, communication plays a vital role.

Consider some examples. A key part of interaction design involves communicating effectively with the intended users. The more effectively the design team can elicit needs from users, get feedback on various prototypes, etc., the better the final design. Similarly, there is a requirement for effective communication within the design team. Team members must reflect on the state of the design, develop critiques of problems, suggest alternative solutions, and so forth. Particularly in interaction design, where team members may be drawn from a variety of backgrounds, good communication is vital. Finally, the design team must communicate effectively with the larger organization of which it is a part. No design can really be said to be successful if it doesn't make it out the door. The team must succeed in convincing upper management of the design project's validity (a process which may be repeated throughout the life cycle of the design), and, if successful, the team must be able to communicate the key aspects of the design to those who will implement, manufacture, market, and distribute it.

This view of design as communication highlights a number of important questions: Who are the audiences for a particular design? How do those audiences change as the design progresses through its life cycle? What sort of communication needs to occur among and within these audiences? How can that communication best be facilitated? Reflecting on these questions, and how they apply to a particular design project, usage domain, and organizational context, can be a valuable exercise for a design team. While I discuss these questions more generally elsewhere (Erickson, 1995), here I simply wish to suggest that stories have particularly strong powers as communications catalysts, and discuss the roles they play in my design process.

Stories as Design Tools


I almost always begin design by talking with users. Initially, my goal is simply to collect people's stories. I believe that the stories people tell about what they do and how they do it contain information vital to designing good interfaces. Stories reveal what people like about their work, what they hate about it, what works well, what sorts of things are real problems. But although stories can contain a lot of valuable information, I believe that it is the process of collecting stories, rather than the content they contain, that is their most valuable contribution to design.

Stories are a natural way of beginning dialog with users. Consider the following story:

One of Apple Computer's R&D buildings had an intelligent energy management system. The system conserved energy by automatically turning off lights during hours when employees were not expected to be present. One weekend, an employee, accompanied by his six year old daughter, stopped by to finish up some work. Suddenly, the lights go out.

Daughter: Who turned off the lights?
Father: (matter-of-factly) The computer turned off the lights.
Daughter: (pause) Did you turn off the lights?
Father: No, I told you, the computer turned off the lights.

(Someone manually turns the lights back on)

Daughter: Make the computer turn off the lights again.
Father: (with irony) It will in a few minutes.



As I tell this story, I use my voice to dramatize it. The little girl is doubtful; she doesn't really believe the computer turned out the lights. Dad, on the other hand, has experienced this before: his first statement is matter-of-fact; his final statement is ironic.

The story works on a number of levels. It aptly illustrates that systems that attempt to be intelligent can irritate and bafflel their users, if they're not smart enough. The story also raises some deeper issues. Just like the little girl, people want to understand why things change, and people want to feel that they are in control (one wonders what kind of mental model she has formed of this capricious, uncontrollable computer). And, as the father's responses indicate, people also become accustomed--or at least resigned--to the inconveniences caused by technology.

People respond to this story in several ways. They laugh at the last line of dialog. The story captures a sense of frustration that many people share. Often those who hear this story will tell their own stories of stupid intelligent technology, or technology which has failed in some other way. Others will defend the technology, arguing that the problem is not technology per se , but badly designed technology. Etc. The important thing here is not the conclusion that is drawn, but rather that people have been engaged, drawn into discussion of ideas about which--before the story--they would have had nothing to say.

This is a good metric for stories. I judge the "goodness" of a story by telling it to other people, and seeing how much they nod or laugh as they listen. When they hear a good story, listeners say, 'oh, that reminds me ' and launch into their own stories. People who believe they have nothing to say about how technology shapes their lives, or who hesitate to expose their ignorance of technology, are quite happy to tell stories that -- to the attentive designer -- may be far more revealing than a cautiously ventured generality. The very particularity of stories is, I believe, a reason that people feel comfortable sharing them: they are making no claims to generality, to having some great truth to dispense; they're just telling a story about something that happened to them.

Once a set of stories is amassed, more formal approaches such as observation, structured interviews, and task analyses become easier. Stories provide a good first pass at what is important, from the point of view of the users; they provide the designer with a glimpse of what the user's terrain feels like, and thus provide a starting point for further exploration. At the same time, the process of collecting and telling stories can help users feel more comfortable as participants in the design process. Storytelling can break the ice, and make more formal processes like structured interviews a bit less threatening.

Stories also work well as a way for promoting collaborative work and understanding within the design team. Stories are a sort of equalizer. It doesn't require much expertise or training to listen to and tell stories. Team members from any background can be made part of the process of telling and collecting stories. And once stories have been gathered, team members can discuss the stories, argue about their interpretation, and generate hypotheses about what users' problems, needs, and practices. This process sensitizes everyone to the usage domain, helps people identify questions and issues to probe for when they talk with users, and best of all provides concrete examples which can prove invaluable when team discussions threaten to veer into debates about vaguely defined abstractions.

The collection and generation of stories happens most during the early stages of design, and serves as a precursor to more formal analyses. However, stories are useful even after the initial fuzzy knowledge has been codified into problem definitions, design principles, lists of user needs, information flow diagrams, prototypes and other more formal design representations. Once the early stage of design is done, stories become important as mechanisms for communicating with the organization.

Depending on the nature of the organization, and the economic conditions under which it is operating, design teams may need to defend the validity of their design in an effort to maintain their funding. And if the project is to succeed, the team will need to make the case for moving the design from a product investigation or research track, to a product development track. In both cases, a lot of people from across the organization will be involved. Marketing personnel, engineers who may be involved in implementation or manufacturing, designers not involved in the project, as well as a variety of higher level managers will be called upon to provide input to the decision on whether or not to go forward with the project. Many of these participants will lack the time or inclination to understand the details of the design. What all these people need is to quickly understand the gist of the design, why it makes sense, why people will want to buy it. Stories excel at capturing and communicating this kind of information.

Consider this story, which describes one way in which people use piles of paper to organize information.

The Guilt Pile


You receive something you feel that you ought to read but, because it's not vitally important, you don't want to do it immediately. Instead, you toss it on a pile of documents which probably sits on a work surface in a corner of your office. You feel good. Things are under control, and with a minimal investment of time!

Time passes. The guilt pile gets higher and higher. It begins to look like there's literally a mountain of stuff you ought to read. You begin to feel uncomfortable.

Provoked by the pile's height, you sort through it, discarding articles that no longer seem interesting, perhaps selecting one or two to read. The winnowed pile--now of a much more manageable size--is put back in its place. You feel good. Things are under control again.


This is a story which I made up, after being told particular versions of this story by a number of people. Each of the stories I heard differed in all sorts of ways: the number of piles they had, the reasons they put items on the pile, how often they sorted through the pile. But the commonalities that I captured in my version of the story are quite striking, and capture not only how people use piles, but why they use piles: People felt overwhelmed by information. They tried to maintain control by low overhead organizational efforts such as piles, which still gave them some measure of control, and some ability to find things. But as the pile grew in size, they tended to feel more and more uneasy, until finally they sat down and sorted through the pile, finding -- generally to great delight -- that they could throw a lot of stuff out. And then they felt good, in control of things for a while.

A group in Apple's Advanced Technology Group developed an interface component based on the metaphor of physical piles (Mander, et al., 1992). Extensive efforts were made to evangelize the proposed interface mechanism to the groups that might actually implement it in the Finder. A common objection to the proposed interface component was that folders could be modified to provide most of the functionality: there was no need to provide a visually distinct, pile metaphor. Although I can't document it quantitatively, it seemed much easier to convince listeners that piles needed to be visually distinct from folders when the "guilt pile" story was told. Listeners didn't respond that a 'guilt folder' would work as well; from the story they recognized that the visual impact of a towering pile of documents was critical to its function, rather than just a cute visualization of the metaphor.

Stories are particularly useful for communicating within the organization for two reasons. First, stories are memorable. People will remember -- and re-tell -- the guilt pile story long after they have forgotten the more formal principles behind piles. Second, stories have an informality that is well-suited to the lack of certainty that characterizes much design-related knowledge. Virtually any kind of information has uncertainty associated with it: it is likely that it will only be true of certain individuals, in certain situations, under certain circumstances. Presentation of such information as "design principles," or "findings," will often elicit arguments about validity and generality from the skeptical. In contrast, stories seem to sidetrack the debates about methodology. People understand that stories are not accurate, that they are likely to bend the truth for rhetorical ends, and so the discussion tends to be of the issues raised by the stories, rather than their obvious shortcomings.

Concluding Remarks


Donald Schön (1987) has argued eloquently that professional practitioners--a category within which he includes designers--employ artistry as much as science in their daily practice. He notes that practitioners are not initially presented with well-formed problems, but rather with messy, indeterminate situations. While Schön's investigations have focused on work by one or two designers, often examining the master-apprentice relationship, interaction design often involves many people from widely varying backgrounds: this social dimension expands the scope of messy, indeterminate situations quite considerably.

I suggest that for the interaction designer, stories provide one way to deal with this indeterminacy. When first starting out, stories provide a way of getting a feel for the new terrain. Stories reveal a users-eye view of the landscape, and, provide an extremely effective way for getting people--both users and designers--involved and talking with one another. A key element of the power of stories, I believe, is their informality. Like the first rough sketches of an architect, stories have a sort of discountability. We all know that stories are subjective, exaggerated, and particular, and so we don't take them too seriously. Any story is liable to questioning, reinterpretation, or rejection. At the same time, stories provide concrete examples that people from vastly different backgrounds can relate to. Thus, as a collection of stories accretes around a design project, it provides a common ground, a body of knowledge which can be added to, and questioned by, all participants.

Acknowledgments


Portions of this article have previously appeared in "Notes on Design Practice: Stories and Prototypes as Catalysts for Communication", published in Scenario-Based Design: Envisioning Work and Technology in System Development (ed. J. Carroll). New York: Wiley

References


Erickson, T. Notes on Design Practice: Stories and Prototypes as Catalysts for Communication. In Scenario-Based Design: Envisioning Work and Technology in System Development (ed. J. Carroll). New York: Wiley, 1995, pp 37-58.

Mander, R., Salomon, G., & Wong, Y.Y. A 'Pile' Metaphor for Supporting Casual Organization of Information. Human Factors in Computing Systems: CHI '92 Conference Proceedings . Addison-Wesley, 1992, pp 627-634.

Schön, D. A. Educating the Reflective Practitioner. San Francisco: Jossey-Bass, 1987.

Wong, Y. Y. Layer Tool: Support for Progressive Design. Human Factors in Computing Systems: CHI '92 Conference, Adjunct Proceedings . ACM Press, 1992, pp 127-128.


* A version of this paper appeared in Interactions iii.4, July/August 1996. © Copyright 1996 ACM. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy, otherwise republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.