11. INTRODUCTION
Prototypes are widely recognized to be a core means
of exploring and expressing designs for interactive
computer artifacts. It is common practice to build
prototypes in order to represent different states of
an evolving design, and to explore options. How-
ever, since interactive systems are complex, it may
be difficult or impossible to create prototypes of a
whole design in the formative stages of a project.
Choosing the right kind of more focused prototype
to build is an art in itself, and communicating its
limited purposes to its various audiences is a criti-
cal aspect of its use.
The ways that we talk, and even think about pro-
totypes, can get in the way of their effective use.
Current terminology for describing prototypes cen-
ters on attributes of prototypes themselves, such as
what tool was used to create them, and how re-
fined-looking or -behaving they are. Such terms
can be distracting. Tools can be used in many dif-
ferent ways, and detail is not a sure indicator of
completeness.
We propose a change in the language used to talk
about prototypes, to focus more attention on fun-
damental questions about the interactive system
being designed: What role will the artifact play in
a user’s life? How should it look and feel? How
should it be implemented? The goal of this chapter
is to establish a model that describes any prototype
in terms of the artifact being designed, rather than
the prototype’s incidental attributes. By focusing
on the purpose of the prototype—that is, on what
it prototypes—we can make better decisions about
the kinds of prototypes to build. With a clear pur-
pose for each prototype, we can better use proto-
types to think and communicate about design.
In the first section we describe some current diffi-
culties in communicating about prototypes: the
complexity of interactive systems; issues of multi-
disciplinary teamwork; and the audiences of pro-
totypes. Next, we introduce the model and illus-
trate it with some initial examples of prototypes
from real projects. In the following section we
present several more examples to illustrate some
further issues. We conclude the chapter with a sum-
mary of the main implications of the model for
prototyping practice.
2. THE PROBLEM WITH PROTOTYPES
Interactive computer systems are complex. Any
artifact can have a rich variety of software, hard-
ware, auditory, visual, and interactive features. For
example, a personal digital assistant such as the
Apple Newton has an operating system, a hard case
with various ports, a graphical user interface and
audio feedback. Users experience the combined
effect of such interrelated features; and the task of
designing—and prototyping—the user experience
is therefore complex. Every aspect of the system
must be designed (or inherited from a previous sys-
tem), and many features need to be evaluated in
combination with others.
Prototypes provide the means for examining de-
sign problems and evaluating solutions. Selecting
the focus of a prototype is the art of identifying the
most important open design questions. If the arti-
fact is to provide new functionality for users—and
thus play a new role in their lives—the most im-
portant questions may concern exactly what that
role should be and what features are needed to sup-
port it. If the role is well understood, but the goal
What do Prototypes Prototype?
Stephanie Houde and Charles Hill
Apple Computer, Inc.
Cupertino, CA, USA
s.houde@ix.netcom.com, hillc@ix.netcom.com
This article is published, in a different format, as Houde, S.,
and Hill, C., What Do Prototypes Prototype?, in Handbook of
Human-Computer Interaction (2nd Ed.), M. Helander,
T.␣ Landauer, and P. Prabhu (eds.): Elsevier Science B. V:
Amsterdam, 1997.

2of the artifact is to present its functionality in a
novel way, then prototyping must focus on how
the artifact will look and feel. If the artifact’s func-
tionality is to be based on a new technique, ques-
tions of how to implement the design may be the
focus of prototyping efforts.
Once a prototype has been created, there are sev-
eral distinct audiences that designers discuss pro-
totypes with. They are: the intended users of the
artifact being designed; their design teams; and the
supporting organizations that they work within
(Erickson, 1995). Designers evaluate their options
with their own team by critiquing prototypes of
alternate design directions. They show prototypes
to users to get feedback on evolving designs. They
show prototypes to their supporting organizations
(such as project managers, business clients, or pro-
fessors) to indicate progress and direction.
It is difficult for designers to communicate clearly
about prototypes to such a broad audience. It is
challenging to build prototypes which produce feed-
back from users on the most important design ques-
tions. Even communication among designers re-
quires effort due to differing perspectives in a multi-
disciplinary design team. Limited understanding
of design practice on the part of supporting orga-
nizations makes it hard for designers to explain their
prototypes to them. Finally, prototypes are not self-
explanatory: looks can be deceiving. Clarifying
what aspects of a prototype correspond to the even-
tual artifact—and what don’t—is a key part of suc-
cessful prototyping.
2.1 What is a prototype?
Designing interactive systems demands collabo-
ration between designers of many different dis-
ciplines (Kim, 1990). For example, a project might
require the skills of a programmer, an interaction
designer, an industrial designer, and a project man-
ager. Even the term “prototype” is likely to be
ambiguous on such a team. Everyone has a
different expectation of what a prototype is.
Industrial designers call a molded foam model a
prototype. Interaction designers refer to a simula-
tion of on-screen appearance and behavior as a pro-
totype. Programmers call a test program a proto-
type. A user studies expert may call a storyboard,
which shows a scenario of something being used, a
prototype.
The organization supporting a design project may
have an overly narrow expectation of what a pro-
totype is. Shrage (1996) has shown that organiza-
tions develop their own “prototyping cultures”
which may cause them to consider only certain kinds
of prototypes to be valid. In some organizations,
only prototypes which act as proof that an artifact
can be produced are respected. In others, only
highly detailed representations of look and feel are
well understood.
Is a brick a prototype? The answer depends on
how it is used. If it is used to represent the weight
and scale of some future artifact, then it certainly
is: it prototypes the weight and scale of the artifact.
This example shows that prototypes are not neces-
sarily self-explanatory. What is significant is not
what media or tools were are used to create them,
but how they are used by a designer to explore or
demonstrate some aspect of the future artifact.
2.2 Current terminology
Current ways of talking about prototypes tend to
focus on attributes of the prototype itself, such as
which tool was used to create it (as in “C”, “Direc-
tor™”, and “paper” prototypes); and on how fin-
ished-looking or -behaving a prototype is (as in
“high-fidelity” and “low-fidelity” prototypes). Such
characterizations can be misleading because the ca-
pabilities and possible uses of tools are often mis-
understood and the significance of the level of fin-
ish is often unclear, particularly to non-designers.
Tools can be used in many different ways. Some-
times tools which have high-level scripting lan-
guages (like HyperCard™), rather than full pro-
gramming languages (like C), are thought to be
unsuitable for producing user-testable prototypes.
However, Ehn and Kyng (1991) have shown that
even prototypes made of cardboard are very useful
for user testing. In the authors’ experience, no one
tool supports iterative design work in all of the im-
portant areas of investigation. To design well, de-
signers must be willing to use different tools for
different prototyping tasks; and to team up with
other people with complementary skills.