Design as Storytelling*
Apple Computer, Inc.
(now at) firstname.lastname@example.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
Stories are a natural way of beginning dialog with users. Consider the following
- 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
- (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
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
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
- 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.
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,
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
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:
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.