Thomas Erickson
Apple Computer, Inc.
(now at) snowfall@acm.org
Consider the following description of an architect beginning work (Wong
, 1992):
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.
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.
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:
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
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, all participants.
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
[Tom's Home Page]
[Professional] [Life,
Fun, &c] [Tell Me...]