Thomas Erickson
User Experience Architect's Office
Apple Computer, Inc.
(now at) snowfall@acm.org
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
design team?
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 be done?
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 worth?
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.
Communication
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 of activity.
Design Artifacts
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.
Audiences
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.
The Users
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.
The Organization
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 team.
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.
Exploration
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).
Refinement
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.
Transition
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 discussion.
Summary
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 Audiences
The Guilt Pile
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:
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 decision.
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.
Beyond Stories
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.
Accessibility
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.
Roughness
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, 1990).
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 to critiques.
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 Don Norman.
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,
video tape.
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, pp 59-69.
Herbert, D. M. Architectural Study Drawings. New York: Van
Nostrand Reinhold, 1993.
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: Jossey-Bass, 1987.
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, pp 127-128.
[Tom's Home Page]
[Professional] [Life,
Fun, &c] [Tell Me...]
© Copyright 1995 by Thomas Erickson. All Rights Reserved.