Notes on Design Practice: Stories and Prototypes as Catalysts
User Experience Architect's Office
Apple Computer, Inc.
(now at) email@example.com
Donald Schön (1987) has argued eloquently that professional practices like
design are more of an art than a science. In much of their daily work designers
are not grappling with well-formed problems but with, as Schön puts it,
"messy, indeterminate situations." Schön's investigations have
been principally directed at design by one or two individuals, with an emphasis
on education and the master-apprentice relationship. I want to discuss the design
of products that incorporate new technologies. This means that the design process
usually involves a team of designers from different disciplines, and that the
team must interact with the prospective users of its product and with the much
larger organization of which it is a part. In short, the design of technology-based
products is inextricably entwined with social and organizational dynamics. This
expands the realm of messy, indeterminate situations considerably.
My goal is to talk about some of the informal, practical methods that designers
use to grapple with the messy, ill-defined issues that pervade their daily practice.
The issues I am concerned with are the following:
Problem setting. Before designers can solve a problem, they first must define
what it is. How do designers of new technologies begin when they are unsure
of what they are making, what it should do, or who will use it?
Team building. Technology design is carried out by interdisciplinary teams.
Members of the team may not necessarily understand the skills or priorities
of others. How can a diverse group of people evolve into a smoothly functioning
Involving users. Designers know too much, and they know too little. Designers
who know enough to incorporate a technology into a product know too much to
understand how users will perceive it. At the same time, designers know too
little about the users' lives to understand how the product will mesh with their
work practices. How can users be effectively involved in the design process,
particularly in the beginning when there is nothing to show them?
Collaborative design. The heart of design is the iterative process of creating
a prototype that embodies the design, evaluating it, and then using the feedback
to create a new prototype. In the course of this, the members of the design
team must work closely with one another, even though they have different working
techniques, methods of analysis, evaluation criteria, and different languages
for describing what they do. How can the collective activity of the team be
supported? What properties make a prototype useful?
Design transfer. In large organizations, those who design a product are often
not the same as those who implement it. A product concept may be developed in
a research division and then transferred to a product division. Even when the
designers and implementors are the same, many new people -- in marketing, manufacturing,
documentation -- will become involved as the design makes its way from concept
to reality. It is important that knowledge about the rationale behind the design
be shared with those involved in preparing it for the marketplace. How can that
Design evangelism. Much design occurs in the context of large organizations.
Buy in of people -- executives, managers, potential collaborators -- is a necessity
if the designed product is to be implemented, manufactured, and marketed. How
can those not involved in the design process be convinced of its validity and
An underlying assumption of this chapter is that design is a distributed social
process, and that, as such, communication plays a vital role in design. In holding
this view, I share common ground with others in this volume who discuss on the
social and communicative aspects of design. Karat discusses the use of scenarios
as devices for facilitating communication among members of the design team.
The chapters by Kyng and by Mueller and his colleagues focus on ways of enabling
users to participate as first class contributors to the design process, and
pay special attention to the use of concrete representations for this purpose.
Carey and Rusli go beyond the scope of a single design project, and look at
ways of re-using design knowledge in the education of new designers and the
development of different but related products.
This chapter extends these ideas in two ways. First, it discusses communication
within the organization in which design takes place, as well as communication
within the design team and between the design team and the users. Second, it
examines two concrete artifacts -- stories and prototypes -- and discusses the
properties which make them effective communications catalysts.
Design as Communication
To begin, I will sketch a simple, communication-oriented model of design. It
is useful to think about design as a process of communication among various
audiences. Central to this discussion is the notion of design artifacts, material
or informational objects that are constructed during the design process.
Let's examine this perspective in more detail.
I am using "communication" its broadest sense. Talking, telephoning,
sending email, writing reports, giving presentations, and showing videos all
fall under communication. Thus communication can be one-to-one or one-to-many,
and a 'conversation' may occur in real time, or may be spread out over hours,
days, weeks, or longer. Also note that many of these types of conversations
occur through, or are facilitated by, the use of some kind of persistent, physical
representation. What we will focus on is the role played by design artifacts
in supporting communication.
In a sense, even the design activities of a single individual can be classified
as a communications activity. For example, note taking can be viewed as an act
of communicating with one's self over time. Schön (1987) characterizes
design practice as a protracted "conversation with the situation,"
in which designers embody their ideas in some representational medium, reflect
on them, and the modify them. Similarly, Thimbley (1990) suggests that work
by an individual is a special case of cooperative work -- reflexive cooperative
work -- in which various concrete artifacts support individuals in collaborating
with themselves over time. Whether or not one finds the notion of reflexive
communication palatable, physical artifacts clearly play a role in both sorts
I use the term "design artifact" to mean any of the physical
or informational entities collected or constructed during the design process.
Examples of design artifacts include videos of users, snapshots of usage contexts,
transcripts of user interviews, scenarios, prototypes, marketing studies, data
sets produced by user tests, progress reports, professional publications, and
formal documents such as engineering requirements specifications and marketing
requirements documents. Design artifacts are produced for a variety of reasons.
They may be created as a way of capturing information, or as a way of disseminating
information, or simply as a side effect of a process that is occurring. background,
knowledge, and experience. Regardless of the explicit reason for their creation,
many design artifacts play a role in catalyzing communication among the various
audiences involved in the design process.
There are different audiences for a design that are associated with
one or more stages in the design's life cycle. The actual audiences for a design
will vary depending on the nature of the product being designed and the organization
within which the design takes place. The different audiences are important because
they require different design artifacts, or at least require the same artifact
to be used in different ways. For expository purposes, I'll talk about three
audiences: the design team itself; the intended end users; and the organization
within which the design activity takes place.
The Design Team
Many people are involved in the design of new technologies. They are likely
to include technologists, graphic designers, psychologists, and industrial designers.
In spite of being grouped as one audience, the differences in working methods,
evaluation criteria, skills, and inclinations that arise from training in different
disciplines make this an extremely diverse audience. If the members of the team
have not worked together before, the gaps between team members may be as large
as those between the design team and other audiences. And, in participatory
design (see Kyng, and Mueller, et al., this volume), users may also be full
fledged members of the design team, thus increasing its diversity. For expository
purposes, I will refer to members of the design team as "designers,"
regardless of their background.
Users represent the intended users of the final product. They are typically
expert in some domain of activity relevant to the product being designed, but
are not versed in the technology which will be manifested in the design. For
users to provide useful feedback, they must be given a concrete understanding
of the nature of the to-be-designed product.
An oft-neglected audience for the design is the organization within which
it is created and produced. Yet organizations play a fundamental role in shaping
the nature of the design process (e.g., Grudin , 1991a; Grudin, 1991b). Design
processes will differ radically depending on whether they are being carried
out by a group in a large, product development organization, an in-house development
group, or a design consultancy on contract to a client.
This paper discusses product development in the context of large, product development
organizations. Such organizations are characterized by internal competition
for resources as research projects and product investigations struggle to make
it onto the product track. Thus, a design team must be prepared to defend the
validity of its design throughout the design process, and, if successful, must
be able to communicate the rationale behind the design when it is time to implement
it. Like the design team, this audience is quite heterogeneous: it includes
executives, managers, potential implementors, and designers not on the design
The Early Stages of the Design Life Cycle
Like the audiences for a design, the life cycle of a design depends
on what is being designed and the organizational context. Because my concern
is the design of new product concepts in product development organizations,
I will speak of a design life cycle with three stages -- exploration, refinement,
and transition. Other more complex models may be advanced, but these three stages
will suffice for our purposes. Another caveat is that the use of the word "stage"
is primarily a linguistic convenience; these stages aren't cleanly separated:
they are likely to have considerable overlap, with the focus shifting gradually
from one to another.
The exploratory stage of design is where the requirements for the product
are gathered and the basic product concept is defined. All designs -- excepting
those that are incremental improvements of existing products -- go through an
exploratory phase. However, depending on the organization and circumstances,
the exploratory phase may be done by a marketing group, by a manager or executive,
or by a design team. In my remarks I will assume that the exploratory stage
is pursued by the design team.
The exploratory stage of design is characterized by confusion and unease within
the design team. Nothing is settled. Although the design team has a set of constraints,
many are often no more than accidents of circumstance. Typically, the design
team will have a set of new technologies to which it has access, some indications
of appropriate directions or application areas which may have been provided
by upper management or distilled from the corporate zeitgeist, and probably
some sort of deadline for formulating a design proposal. The problems to be
solved -- Who is it for? What will it do? What problems and needs will it address?
What practices will it support? -- remain to be defined. The main goal of this
stage of design is to understand the usage domain, define the problems being
addressed, and develop a high level vision of the product being designed.
In addition, some or all of the designers may be new to the team. Thus, the
team needs to arrive at a shared understanding of the skills and expertise of
fellow team members, and must develop methods for working together effectively.
When the team is composed of members from different disciplines, this team building
can be a major undertaking in itself (see Kim, 1990).
The refinement stage is aimed at filling in the details: having determined what
the design will do, the design team must determine how it will accomplish those
ends, what criteria it will use to evaluate the design, how it will determine
tradeoffs between conflicting criteria. It is during this stage that the focus
shifts to prototypes; these serve as a medium for team collaboration and as
a means for eliciting input from users and from other designers within the organization.
The refinement stage concludes with the production of a design specification
of sufficient detail that it may be transferred to those who implement it.
The transition stage is devoted to getting the design adopted and implemented
by the organization. One set of activities may be characterized as design evangelism.
Basically, the validity and worth of the design concept must be 'sold' to the
large number of people who have some say on whether the design becomes a product.
If evangelism is successful, attention shifts to transferring the design. Transfer
activities may involve handing off the design to a product development team,
recruiting people to implement the design, or arguing for additional resources
to be allocated to the design team so that it can undertake the product development
effort itself. In general, transition activities are aimed at marketing the
design within the organization, although key customers may sometimes be included.
The life cycle of the design, of course, continues after the transition stage.
A host of new activities arise in conjunction with implementing, marketing,
and supporting the product. But the first three stages are sufficient for this
In this section, I've laid out a simple model of the design process
based on the use of artifacts to mediate communication among various audiences.
Depending on the stage of design, the goals of the design team, and the audience
being addressed, different artifacts may be used to mediate communication (or
the same design artifact may be used for different ends). Table 1 summarizes
a few of the typical, communication-oriented activities at each stage of the
design life cycle.
Table 1 : Stages of Design and Typical Activities and
- Problem setting. The design team learns about the problems and practices
of the users for whom they are designing.
- Team building. Internally, the team develops a shared understanding of their
project and of the skills and expertise of each member.
- Collaborative design. The team develops the details of the design by embodying
it in prototypes, which are used to explore design solutions and evaluate
- Involving users. To get useful feedback from users, the team must help the
users arrive at an understanding of the design.
- Design evangelism. Within the organization the design project must be defended
so that it can continue to get resources. (Depending on economic conditions,
this activity may occur in earlier stages as well.)
- Design transfer. The rationale behind the design must be communicated to
those who will implement it, so that crucial features of the design are not
The perspective of design as communication takes on particular importance because
communication is difficult. By and large, the participants in the design process
don't understand one another. Users, designers, engineers, managers, psychologists,
all have different backgrounds, training, experience and inclinations. Users understand
-- at least tacitly -- their own needs and daily experience, but they understand
little about the proposed design. Designers understand the proposed design, but
little about the users' experience. The organization, having little exposure to
either the design or the users, understands neither. Somehow, these gaps must
For the design process to have the best chance of success, the design team must
create a shared understanding amongst the participants in design process. In my
view, this involves the creation of design artifacts which are accessible and
comprehensible to all. In the remainder of the chapter, we will discuss stories
and prototypes, two types of design artifacts which play a crucial role in facilitating
such a shared understanding.
Stories as Design Tools
In this section, I consider some of the ways in which stories are used to catalyze
communication in design, and the properties which make them effective.
First, note that stories differ from scenarios. Stories are concrete accounts
of particular people and events, in particular situations; scenarios are often
more abstract -- they are scripts of events that may leave out details of history,
motivation, and personality. The stories I'll be talking about are 'true' stories,
in the sense that the people, events, and situations to which they refer are real.
In contrast, the reality of scenarios is more tenuous: they rarely refer to particular
events. Stories are personal: the protagonist, and often the audience, care about
the outcome. Scenarios describe events at a greater distance, and there is less
chance for identification with a protagonist, if one even exists. Stories are
often about atypical situations: they are about events which are exceptional in
some way, often events in which the protagonist has triumphed (or foundered) in
the face of great odds. Scenarios are about typical situations; they are intended
to capture the normal chain of events, the prototypical situations.
Story Gathering -- Beginning the Design Process
In an observation of an architect beginning a new design, Wong (1993)
describes the following behavior:
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
I like this description because it feels like such an easy, gradual, enjoyable
way to begin. Roll the tracing paper over the site plan, and start sketching.
Pity the poor interaction designer whose domain is less tangible. Rather than
an easily mapped site, the domain is a set of tasks situated in an environment
that is as much cultural and social as it is physical. Beginning does not seem
Yet, in part, the appearance of difficulty is deceptive. For me, the analog to
the architect's gradual beginning is talking to users and listening to the stories
they tell. The stories people tell say a lot about what they do and how they do
it. Stories reveal what people like about their work, what they hate about it,
what works well, what sorts of things are real problems. As one hears more and
more stories, themes gradually emerge, and the designer can begin to get a feel
for the structure of the interactions that characterize a particular usage domain.
This is not to say that stories are a direct route to knowledge. Indeed stories
are quite ambiguous; most stories can be interpreted in many ways (Schank, 1989).
However, rather than being a drawback, this property makes stories particularly
useful at the beginning of the design process. As the collection of stories grows,
the design team can try out different frameworks for making sense of the usage
domain. A story that fits one framework in one way, may fit a different framework
in a different way. This conceptual ambiguity can help the designer avoid getting
prematurely committed to a particular problem definition.
Story gathering is also an excellent way of promoting team building. Team members
can sit around and swap stories they've heard, noting similarities and differences,
and discussing possible interpretations. Stories often require a lot of domain-specific
knowledge to be understood, and thus the process of story gathering sensitizes
everyone to the usage domain. Talking about stories helps the members of the design
team identify things they don't understand, and raises questions and issues to
probe for when they next talk with users. In addition, as the members of the design
team share and discuss stories, they begin to develop a shared language, a set
of common referents that are grounded in the domain of the user. While this by
no means guarantees agreement, it does provide a common ground on which constructive
argument can occur. Best of all, making up stories is a kind of equalizer. It
seems to be something that any member of a design team can participate in, regardless
of whether they are trained in computer science, psychology, graphic design, or
some other discipline.
Story Making -- Capturing Design Rationale
As I listen to the stories people tell, I begin to recognize common themes
and events, and gradually formulate my own, 'design stories.' Design stories are
a little like scenarios, in that they attempt to capture some of the recurring
characteristics in stories I've been told, but they are still quite story-like,
in that they retain their level of detail, and are grounded in my personal experience.
Design stories often incorporate humorous events, noteworthy quips, and memorable
phrases and concepts drawn from users' stories.
Consider this design story, which emerged from a series of interviews on how office
workers organized their personal information. It 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 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.
I like this story because it not only explains how people use piles, but why
they use piles. It provides the design rationale behind piles. It is able to
do this effectively because stories describe not just actions, but feelings
and motivations. This story captured something that struck me when interviewing
people about how they organized information in their work environments: Almost
everyone was embarrassed at how poorly they managed information. They felt bad
because they had lost control over their information, and they felt good at
the times when they had managed to sort through everything and organize it,
no matter how casually. The desire to feel good and on top of things rather
than bad and out of control is one with which most people can empathize. People
recognize themselves and their desires in the story.
Involving Users -- Story Telling
Stories are a natural way of beginning dialog with users. Consider
the following story:
- (An office building has an intelligent energy management system that conserves
energy on weekends by turning off unneeded lights after an hour has elapsed.
An employee, accompanied by his six year old daughter, has 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 incredulous,
she doesn't initially 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 has an undertone of irony.
The story works on a number of levels. Quite obviously, it illustrates that
systems that try to be intelligent can be annoying and perplexing if they're
not intelligent enough. The story also raises some deeper issues. As the child
indicates, people want to understand why things change, and people want to feel
like they are in control. One wonders what kind of mental model she has formed
of this capricious, out-of-control computer. And, as the father's responses
indicate, people also become accustomed, or at least resigned, to the inconveniences
foisted on them by technology.
This story elicits a number of responses from users. People generally laugh
at the last line of dialog. The story captures a sense of frustration with technology
that many people share. Often those who hear this story will recount their own
stories of stupid intelligent technology, or technology which has failed them
in some other way. Others will step forward to defend the technology, and argue
that the problem is not technology, but badly designed technology. And so on.
The important bit here is not the particular conclusion that is reached, if
any, 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, in fact, 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 yeah, something like
that happened to me ' and tell me their own version of that story. People who
believe they have nothing to say about how technology shapes their lives, or
who bridle at possibly exposing 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.
Transferring Design Knowledge
The collection and generation of stories happens most during the exploratory
stage of design, and serves as a useful 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, and other more formal design artifacts. Once the early stage
of design is done, stories become important as mechanisms for communicating
with the organization.
One role stories play is in assisting in communicating with high level management.
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, or to make the case for moving
the design from a product investigation or research track, to a product development
track. In both cases, many of the higher level managers involved in the decision
will have neither the time nor the inclination to understand the details of
a design. What they need is to quickly understand the gist of the design, why
it makes sense, why people will want to buy it. Stories excel at encapsulating
this kind of information.
This is not to say that stories are the only source of information considered
in making a product decision -- certainly not. But stories play more of a role
than most people would expect. Consider Norman's (1993) description of executive
decision making based on his wide experience as a design consultant:
I remember just such a meeting of senior executives at a major American company,
decision makers inundated with statistics and facts. And then one of the highly
placed decision makes spoke up: "You know, my daughter came home the other
day and said . . .," and the story poured out. "Hmm," another
executive said, "that makes sense, but you know, the other day . . ."
and out came a story. A few stories, some discussion of the stories, and the
Stories also support design transfer, by capturing both action and motivation,
both the what and the why of the design. For example, the guilt pile story captures
a high level view of the design rationale behind piles: it illustrates how piles
are used, and the motivation for using them in that way. When describing the
design for an electronic analog of piles (Mander, et al., 1992), it is much
easier to convince listeners of the design's value by telling them the guilt
pile story, than by just describing piles as self-revealing containers which
support casual organization and lightweight browsing. The response to the latter
is often, 'well, folders could be used to do most of that.' Somehow, when the
guilt pile story is told, listeners don't respond that a 'guilt folder' would
work as well. The guilt pile story enables them to relate the design to their
personal experience, and they realize that the height and volume of the pile
plays an important role in inciting action.
Stories are particularly useful for communicating within the organization for
two reasons. First, stories are extremely memorable. People will remember 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 uncovered during the exploratory or refinement stage of design
will have 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.
As we've just noted, stories are not particularly accurate. Stories are like
pearls, layers of gloss accreted around an irritating grain of reality. They
exaggerate both the travails and prowess of the teller. Thus, it would be quite
unwise to rely on stories as the only source of information.
Fortunately, stories are not the only tool in the designer's repertoire. Stories
are well complemented by techniques that provide a direct look at more ordinary
aspects of tasks and situations. Techniques such as observations, interviews,
ethnographic studies, laboratory studies, and the inclusion of users on the
design team can provide different information which, combined with stories,
can yield a more comprehensive picture of the situation. And once a good understanding
of the situation has been gained, more structured approaches such as task analysis,
scenario generation, and prototyping become much easier.
Prototypes as Communications Media
Stories are used most during the exploratory and transition stages of design;
prototypes come into play in the refinement stage. After the design team has
made sense of the usage domain by identifying the needs and problems of the
users, the focus of the design process shifts to the product being designed.
Here prototypes, as concrete representations of the to-be-designed product,
assume a central role.
There are many types of prototypes. They range from crude and non-interactive,
to realistic simulations that cannot, at a glance, be distinguished from the
final product. A prototype may be no more than a rough pencil sketch. It may
be a mock-up of a device made from foam core or cardboard, intended only to
mimic the form of the final product. It may be a simple slide show of images
on a computer screen, accompanied, perhaps, by narration. It may be a videotape
that shows the simulated behavior of a proposed product. It may be simulated
in a software prototyping environment that supports some of the interaction
that will characterize the product. Or it may be a partially-implemented version
of the product that has most of the properties and behaviors of the real thing.
A number of different prototypes will usually be created during the design process,
often for different purposes. It is important to emphasize that even prototypes
which are crude, and support no interactivity at all, are essential. Crude,
non-interactive prototypes allow designers to quickly capture rough concepts
early in the design. Prototypes with a more polished appearance may be used
to help communicate about the gist of the design. Prototypes that support interactivity
may be used to elicit feedback from users.
Because of the range of forms which prototypes can take on, I will discuss them
in terms of the roles they play in the design process. I will distinguish between
vision prototypes, which are used in the exploratory stage of design to capture
a high level picture of the design, and working prototypes, which are used to
represent details of the design and to explore solutions to design problems.
Embodying the Vision
A central activity of the exploratory stage of design is the construction
of a vision prototype. A vision prototype is usually some sort of concrete representation
with an embedded story or scenario that shows actions at a very high level.
The purpose of the vision prototype is to communicate what the gist of the design
is, how it helps people with things they care about, how it fits into the flow
of activities that characterize a user's day. In a sense, the vision prototype
is yet another round of storytelling, but with the story focused on the to-be-designed
product. The usual audience for a vision prototype is the organization.
The method we favor is to produce a videotape (Vertelney, 1989), or a partially
interactive computer demonstration, featuring line drawings of users in their
environment, drawings of the intended product, and a sound track (Wong, 1992).
Typically, drawings are made by hand and then scanned into the computer, where
small amounts of interactivity, and animation are added, along with a sound
track. The result is something that seems realistic but cannot be mistaken for
something that is real. On the one hand, it must be convincing in the sense
that the audience comes away believing it is a realistic depiction of how and
why people may use the product. On the other hand, it should be apparent that
what is being shown is a product concept, not a product that will soon be ready
to ship. Such a misperception can lead both to unfortunate pressures on the
design team, as well as to irritation on the part of members of the organization
who may feel that they have been deceived.
As already noted, the exploratory stage of the design process is complicated
by the necessity of the design team developing a smooth working relationship.
In this respect, the construction of the vision prototype is a good follow on
to the collection and generation of stories. Because the creation of the vision
prototype involves crafting a story or scenario about the to-be-designed product,
everyone can contribute. The process of doing this forces the design team to
arrive at a shared understanding of the problems they want to tackle, and at
the types of solutions they hope to offer. The vision prototype is particularly
appropriate because it focuses the design team on the high level issues about
the product being designed and the needs it meets -- details of how the design
does things, what it looks like, and other sources of potential discord are
deferred until the refinement stage of the design process.
Reaching Beyond the Design Community
In some cases, highly polished vision prototypes may be produced (e.g.,
Dubberly & Mitch, 1987; Tognazzini, 1994). This tends to occur if the prototype
is going to be shown publicly, or to the organization's senior management. For
example, as design researcher Michael Schrage comments, "many engineers
conceal provocative prototypes from senior management until they have been appropriately
polished" (Schrage, 1993). The concern, of course, is that the prototype
may be rejected if it has 'rough edges.'
Highly polished prototypes have drawbacks and benefits. On the one hand, the
more polished a prototype is, the more likely it is to be used simply as a vehicle
for persuasion and public relations. The danger here is that significant energy
may be diverted from design to polishing and production. As Schrage notes, "at
many large organizations, demonstrating a prototype to senior management assumes
all the logistical trappings and investments of a Broadway musical" (Schrage,
1993). A second drawback is that due to the relative expense of producing a
polished prototype, and the concern about adverse publicity, there may be internal
pressures to avoid pursuing realistic design issues such as what happens when
something goes wrong (e.g. Tognazzini, 1994). On the other hand, prototypes
that are publicly shown can stimulate public discussion about the appropriateness
and value of particular technologies.
One of the best known examples of a highly polished vision prototype is Apple
Computer's "Knowledge Navigator" videotape (Dubberly & Mitch,
1987). The Knowledge Navigator is a five minute video that depicts a future
computer with capacities such as voice recognition, integrated telecommunications,
video conferencing, and a human-like agent that carried out tasks for the user.
The video shows a college professor using the Knowledge Navigator to prepare
a lecture at the last minute, retrieving research papers, running a simulation,
and contacting a colleague who agrees to show up at the class (over video) to
answer questions. (It is worth noting that the Knowledge Navigator is presented
as a story: the protagonist's character flaw (procrastination) involves him
in a last-minute race to pull together a lecture, with technology coming to
the rescue and his nagging mother providing a humorous counterpoint.)
The Knowledge Navigator provoked great debate in the interface design community.
For example, a year after its release, a panel at a professional conference
conducted a rousing debate on various social issues raised by the prototype
(O'Conner, 1988). Concerns ranged from the appropriateness of portraying computer
programs as human-like, to how such technology might impact the training of
graduate students (in the story, the agent carried out many tasks that would
normally have been done by a professor's research assistant). The Knowledge
Navigator provoked popular interest as well: at the same conference, librarians
from two universities reported that it was the most frequently borrowed tape
in their video collections (Brower, 1988). As a way of stimulating thought and
discussion about the consequences of new technologies, the Knowledge Navigator
was an unqualified success.
The Working Prototype as a Design Medium
Working prototypes are generally distinct from vision prototypes. Working
prototypes emphasize the form, interactivity, and visual appearance of the product
itself, not how the product fits with the user's activities. The working prototype's
purpose is to embody the current state of the design, and to serve as a medium
for interaction among designers and reflection by individual designers. As various
authors have noted (e.g., Schön, 1987; Herbert, 1993), designers proceed
by representing a design idea in some medium, reflecting on the representation,
and then modifying it. Thus, designers may, in an iterative manner, explore
the consequences of various design decisions. A second purpose of the working
prototype is to elicit feedback from those not on the design team -- either
users or other designers in the organization -- thus providing another means
of driving the design process.
To be most effective as a medium for interaction, working prototypes should
have two properties: accessibility and roughness.
First, the prototype should be accessible. Any member of the design team --
ideally, anyone who has something to contribute to the design whether on the
team or not -- should be able to modify it. In traditional design disciplines,
such as architecture and graphic design, this accessibility is a given: all
members of the discipline are trained in the basic tools and techniques of the
trade. In technology design, accessibility is not a given because of the interdisciplinary
nature of the process.
In computer-based prototyping, prototyping environments such as HyperCard and
Macromind Director come the closest to being fully accessible. They permit members
of an interdisciplinary design team to interact on a first class basis: the
graphic designer can directly change the graphics; the interaction designer
can adjust dialogs and feedback; the computer scientist can add in functionality
and access to realistic data. Unfortunately, there are limitations to the types
of interaction that can be implemented in these environments. Environments with
enough power to support implementation of any kind of desired interaction are
usually accessible primarily to programmers; if interaction and visual designers
have to have their ideas implemented by programmers, the ability to quickly
and iteratively explore multiple design paths is lost.
An alternative is the creation of physical mockups. This is particularly viable
in the early stages of design where the goal is to embody very general ideas
very quickly. It is also ideal for participatory design situations, in which
ordinary users play an integral role in producing the design (Kyng, this volume;
Mueller, this volume). Objects such as small computers can be mocked up with
foam core and cardboard, and software interfaces can be simulated with stacks
of screen drawings, note cards, and post-it notes. For example, mock ups may
be taken into the users' environment and used as a props with which the users
can, in a sense, perform. Something as simple as a picture of a screen pasted
on a piece of foam core (to represent an electronic newspaper on a small computer),
can raise interesting issues: for example, the user may enact reading the electronic
newspaper at the breakfast table and discover that there is no way of supporting
the device at a desirable reading angle, or become concerned about the perils
of spilling orange juice into an electronic device.
Physical mockups have a variety of uses in the design process. For example,
Mueller, et al. (this volume) and Wirfs-Brock (this volume), describe the use
of index cards to elicit a task analysis from users, and to design an object
model, respectively. Both note that physicality of the cards -- the ability
for anyone to write on them, turn them over, or rearrange them -- seems to play
an important role in their utility. Similarly, as Kyng points out, if a drawing
that has been taped to the wall comes unstuck and falls off when a user is pointing
to it, it is an unimportant matter; but if a computer-based prototype crashes
as a user is interacting with it, the event feels very different: it is likely
to evoke fervent apologies from the user, and may inhibit the user's future
interactions with the prototype.
A second useful property of working prototypes is that they should be rough.
One definition of roughness is that the conventions of the prototyping medium
are relaxed. For example, rough architectural sketches will often discard scale
and continuity, focusing solely on the form of building fragments (Herbert,
1993). An alternate definition of roughness is that the prototype shows implicit
evidence of the process through which it was created. It is easy to recognize
that a drawing with crooked edges and lines that don't entirely meet has been
sketched by hand, perhaps because people understand what is easy and what is
difficult when drawing.
This sort of roughness is very valuable in working prototypes. First of all,
it creates ambiguity. Different designers -- or even the same designer at a
later time -- may resolve the ambiguity differently, thus making roughness a
source of ideas (Herbert, 1993).
Secondly, roughness leaves openings for discussion of the design. Salomon (1990)
and Wong (1992) have observed that omitting a feature from a user interface
prototype tends to produce more discussion and ideas than if the feature is
present. For example, omitting a text label on a button, or simply leaving out
a control mechanism for invoking some type of functionality, can elicit a wide
range of alternatives that would be lost if a default label or control mechanism
were provided. And Salomon (1990) describes an example from the design of an
information system, where providing too much detail too early in the design
(a button on the screen that had a 3-D look) seemed to shift discussions from
the desired focus on basic functionality to a debate about whether buttons should
have a 3-D appearance. Similarly, art directors have told me that one trick
of the trade is to prepare a preliminary layout on the computer, and then to
put tracing paper over the computer-generated layout and trace the design by
hand, giving it 'that hand-done, this-ain't-final-yet look.' Otherwise, they
say, when the preliminary computer-generated design is presented, clients are
liable to react angrily because the design looks final and they didn't get to
provide any input (and this occurs even though they have been told that the
design is preliminary).
It also seems likely that roughness decreases the level of commitment to the
design. With a rough working prototype designers are less likely to feel like
they have ego invested in the prototype, and more open to considering changes.
If someone criticizes an idea, it's easy for the designer to discount its seriousness
('oh, I just threw that in as a place holder'). Users, too, are likely to give
feedback more readily because they're criticizing something that is obviously
rough. A rough prototype has built-in deniability.
Regardless of the reasons roughness is useful, there is some evidence that beginning
the refinement stage of design with a rough prototype leads to more satisfactory
results. In a study of graphic designers, working either on paper or the computer,
those who produced rough early sketches on paper (rather than neat drawings
on the screen) were more likely to be satisfied with the final design (Black,
It is interesting to note that stories seem to have analogs of these properties
of roughness. Stories are ambiguous. The same story can be taken to mean many
different things. Stories are full of gaps, which different listeners may fill
in differently. Stories, also, do not demand commitment: like a rough drawing
which is criticized and backed off from, any individual story can be discounted
as an exceptional case.
Although design is often characterized as a process of creating a product, it
is also very much a social process in which communication plays a critical role.
Designers must communicate both with users, and with the organization of which
they are part. The designers must also communicate with one another, no mean
task when the team is composed of members from different disciplines.
Material and informational artifacts collected and generated during the design
process play a key role in mediating and catalyzing this communication. In particular,
I've described some of the ways stories and prototypes address some of the messier
issues that arise in design practice:
Problem setting. Collecting stories is a valuable method for the initial exploration
of usage domains. Story collection and story making are useful precursors to
more formal analyses.
Team building. Both stories and prototypes serve as mechanisms for catalyzing
interaction within the team. The processes of collecting stories, making stories,
and constructing vision prototypes is one that all team members can participate
in. Such activities are a good way of generating team cohesion, and the shared
language and understanding which is its foundation.
Involving users. Both stories and prototypes provide a means for involving users
in the design process. People who would balk at giving feedback about a design
idea, are often perfectly content to tell stories. Similarly prototypes can
be used to elicit comments and reactions, or even as props for role playing.
Collaborative design. Prototypes serve as a medium through which the design
team can interact, collectively advancing the design. The most effective prototyping
environments seem to be both accessible, and to support roughness. Accessibility
is important for supporting true collaborative activity, and roughness seems
to increase the generation of design alternatives and to lower the resistance
Design evangelism and transfer. Designs must be defended and -- if the defense
is successful -- passed on to other people in the organization. Both stories
and prototypes can be effective tools for quickly and memorably communicating
underlying design rationale.
Just as we can produce better products by adapting them to the needs and practices
of users, so we can also make the design process more effective by acknowledging
the social nature of design, and developing a better understanding of how concrete
artifacts support communication in design.
Much of my thinking about roughness and its role in design has been influenced
by the prototyping techniques developed by Laurie Vertelney and Yin Yin Wong,
and by discussions with Yin Yin Wong, S. Joy Mountford, Gitta Salomon and Stephanie
Houde, all of the Apple Advanced Technology Human Interface Group. This paper
has benefited from comments by John Carroll, Jonathan Grudin, Morton Kyng, and
Black, A. Visible Planning on Paper and on Screen: The Impact of Working Medium
on Decision-Making by Novice Graphic Designers. Behavior and Information
Technology , 1990, 9:4, 283-296.
Brower, E. Knowledge Navigator Draws Fire. MacWeek, December 6, 1988, p 3.
Dubberly, H. & Mitch, D. The Knowledge Navigator. Apple Computer, 1987,
Grudin, J. Systematic Sources of Suboptimal interface Design in Large Product
Development Organizations. Human-Computer Interaction, Vol. 6,
1991a, pp 147-196.
Grudin, J. Interactive Systems: Bridging the Gaps between Developers and Users.
IEEE Computer, , Vol 24. New York: ACM Press, 1991b,
Herbert, D. M. Architectural Study Drawings. New York: Van Nostrand
Kim, S. Interdisciplinary Collaboration. The Art of Human-Computer Interface
Design (ed. B Laurel). Reading, MA: Addison-Wesley, 1990.
Mander, R., Salomon, G. and Wong, Y. Y. A 'Pile' Metaphor for Supporting Casual
Organization of Information. Human Factors in Computing Systems: CHI '92
Conference Proceedings. New York: ACM, 1992, pp 627-634.
Norman, D. A. Things That Make Us Smart: Defending Human Attributes in
the Age of the Machine . Reading, MA: Addison-Wesley, 1993.
O'Conner, R. J. Apple's View of the Future is Troubling. The San Jose Mercury
News, Sunday, November 27, 1988, p 1F.
Salomon, G. How the Look Affects the Feel: Visual Design and the Creation of
an Information Kiosk. Proceedings of the Human Factors Society 34th Annual
Meeting (Orlando, Florida, October 8-12, 1990), Human Factors Society,
Santa Monica, Ca., pp. 277-281.
Schank, R. C. Tell Me a Story: A New Look at Real and Artificial Memory.
New York: Charles Scribner's Sons, 1990.
Schön, D. A. Educating the Reflective Practitioner. San Francisco:
Schrage, M. The Culture of Prototyping. Design Management Journal, Winter,
1993, pp 55-65.
Thimbley, H., Anderson, S., & Witten, I.H. Reflexive CSCW: Supporting Long-Term
Personal Work. Interacting with Computers, Vol. 2, #3, 1990, pages 330-336.
Tognazinni, B. The "Starfire" Video Prototype Project: A Case History.
In Human Factors in Computing Systems: CHI '94 Conference Proceedings
, Reading, MA: Addison-Wesley, 1994, pp 99-105.
Vertelney, L. Using Video to Prototype User Interfaces. SIGCHI Bulletin
21:2, New York: ACM, 1989, pp 57-61.
Wong, Y. Y. Rough and Ready Prototypes: Lessons from Graphic Design. Human
Factors in Computing Systems: CHI '92 Conference, Posters and Short Talks, ACM,
1992, pp 83-84.
Wong, Y. Y. Layer Tool: Support for Progressive Design. Human Factors
in Computing Systems: CHI '92 Conference, Adjunct Proceedings, ACM, 1993,
* A version of this paper appeared in Scenario-Based Design: Envisioning
Work and Technology in System Development. (ed. J. Carroll). New York:
Wiley & Sons, 1995.