Chat with us, powered by LiveChat Write the summary of the reading (250 words) | Abc Paper

Write the summary of the reading (250 words)
Read the file named – “Houde & Hill Prototypes” 
Summary the reading file within 250 words 

follow the instruction file to do the summary

Follow these instruction to do the summary:

1. First Read the Houde & Hill reading.
2. There are three sections:

· the problem with prototyping
· a model of what prototypes prototype
· further examples
3. Read each section

4. You should be able to answer these questions:
· why prototype?
· what is a prototype?
· what types of prototypes are there?
· Can you give examples of each?



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

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.


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

[email protected], [email protected]

This ar ticle 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.


of 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

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.


Finished-looking (or -behaving) prototypes are of-
ten thought to indicate that the design they repre-
sent is near completion. Although this may some-
times be the case, a finished-looking prototype
might be made early in the design process (e.g., a
3D concept model for use in market research), and
a rough one might be made later on (e.g., to em-
phasize overall structure rather than visual details
in a user test). Two related terms are used in this
context: “resolution” and “fidelity”. We interpret
resolution to mean “amount of detail”, and fidel-
ity to mean “closeness to the eventual design”. It is
important to recognize that the degree of visual and
behavioral refinement of a prototype does not nec-
essarily correspond to the solidity of the design, or
to a particular stage in the process.


3.1 Definitions

Before proceeding, we define some important terms.
We define artifact as the interactive system being
designed. An artifact may be a commercially re-
leased product or any end-result of a design activ-
ity such as a concept system developed for research
purposes. We define prototype as any representa-
tion of a design idea, regardless of medium. This
includes a preexisting object when used to answer
a design question. We define designer as anyone
who creates a prototype in order to design, regard-
less of job title.

3.2 The model

The model shown in Figure 1 represents a three-
dimensional space which corresponds to important
aspects of the design of an interactive artifact. We
define the dimensions of the model as role; look
and feel; and implementation. Each dimension cor-
responds to a class of questions which are salient
to the design of any interactive system. “Role” re-
fers to questions about the function that an artifact
serves in a user’s life—the way in which it is useful
to them. “Look and feel” denotes questions about
the concrete sensory experience of using an arti-
fact—what the user looks at, feels and hears while
using it. “Implementation” refers to questions about
the techniques and components through which an
artifact performs its function—the “nuts and bolts”
of how it actually works. The triangle is drawn
askew to emphasize that no one dimension is

inherently more important than any other.

Goal of the model

Given a design problem (of any scope or size), de-
signers can use the model to separate design issues
into three classes of questions which frequently de-
mand different approaches to prototyping. Imple-
mentation usually requires a working system to be
built; look and feel requires the concrete user ex-
perience to be simulated or actually created; role
requires the context of the artifact’s use to be es-
tablished. Being explicit about what design ques-
tions must be answered is therefore an essential aid
to deciding what kind of prototype to build. The
model helps visualize the focus of exploration.


A prototype may explore questions or design op-
tions in one, two or all three dimensions of the
model. In this chapter, several prototypes from real
design projects are presented as examples. Their
relationship to the model is represented by a marker
on the triangle. This is a simple way to put the
purpose of any prototype in context for the designer
and their audiences. It gives a global sense of what
the prototype is intended to explore; and equally
important, what it does not explore.

It may be noted that the triangle is a relative and
subjective representation. A location toward one
corner of the triangle implies simply that in the
designer’s own judgment, more attention is given
to the class of questions represented by that corner
than to the other two.



Look and feel

Figure 1. A model of what prototypes prototype.


3.3 Three prototypes of one system

The model is best explained further through an ex-
ample from a real project. The three prototypes
shown in Examples 1-3 were created during the
early stages of development of a 3D space-planning
application (Houde, 1992).

The goal of the project was to design an example
of a 3D application which would be accessible to a
broad range of nontechnical users. As such it was
designed to work on a personal computer with an
ordinary mouse. Many prototypes were created
by different members of the multi-disciplinary de-
sign team during the project.

The prototype shown in Example 1 was built to
show how a user might select furniture from an on-
line catalog and try it out in an approximation of
their own room. It is an interactive slide show which
the designer operated by clicking on key areas of
the rough user interface. The idea that virtual space-
planning would be a helpful task for nontechnical
users came from user studies. The purpose of the
prototype was to quickly convey the proposed role
of the artifact to the design team and members of
the supporting organization.

Since the purpose of the prototype was primarily
to explore and visualize an example of the role of
the future artifact, its marker appears very near the
role corner of the model in Figure 2. It is placed a
little toward the look and feel corner because it also
explored user interface elements in a very initial

One of challenges of the project was to define an
easy-to-use direct manipulation user interface for
moving 3D objects with an ordinary 2D mouse cur-
sor. User testing with a foam-core model showed
that the most important manipulations of a space-
planning task were sliding, lifting, and turning fur-
niture objects. Example 2 shows a picture of a pro-
totype which was made to test a user interface fea-
turing this constrained set of manipulations. Click-
ing once on the chair object caused its bounding
box to appear. This “handle box” offered hand-
shaped controls for lifting and turning the box and
chair (as if the chair was frozen inside the box).
Clicking and dragging anywhere on the box allowed
the unit to slide on a 3D floor. The prototype was
built using Macromedia Director (a high level ani-
mation and scripting tool.) It was made to work
only with the chair data shown: a set of images pre-
drawn for many angles of rotation.


Look and feel




Figure 2. Relationship of three prototypes (Examples
1-3) to the model. Example 1. Role prototype for 3D space-planning

application [E1 Houde 1990].

Example 2. Look-and-feel prototype for 3D space-
planning application [E2 Houde 1990].


The purpose of Example 2 was to get feedback from
users as quickly as possible as to whether the look
and feel of the handle box user interface was prom-
ising. Users of the prototype were given tasks which
encouraged them to move the chair around a vir-
tual room. Some exploration of role was supported
by the fact that the object manipulated was a chair,
and space-planning tasks were given during the test.
Although the prototype was interactive, the pro-
gramming that made it so did not seriously explore
how a final artifact with this interface might be imple-
mented. It was only done in service of the look and
feel test. Since the designer primarily explored the
look and feel of the user interface, this prototype’s
marker is placed very near the look and feel corner
of the model in Figure 2.

A technical challenge of the project was figuring
out how to render 3D graphics quickly enough on
equipment that end-users might have. At the time,
it was not clear how much real time 3D interaction
could be achieved on the Apple Macintosh™ IIfx
computer—the fastest Macintosh then available.
Example 3 shows a prototype which was built pri-
marily to explore rendering capability and perfor-
mance. This was a working prototype in which
multiple 3D objects could be manipulated as in
Example 2, and the view of the room could be
changed to any perspective. Example 3 was made
in a programming environment that best supported
the display of true 3D perspectives during manipu-
lation. It was used by the design team to determine
what complexity of 3D scenes was reasonable to
design for. The user interface elements shown on

the left side of the screen were made by the pro-
grammer to give himself controls for demonstrat-
ing the system: they were not made to explore the
look and feel of the future artifact. Thus the pri-
mary purpose of the prototype was to explore how
the artifact might be implemented. The marker for
this example is placed near the implementation cor-
ner (Figure 2).

One might assume that the role prototype (Example
1) was developed first, then the look and feel pro-
totype (Example 2), and finally the implementation
prototype (Example 3): that is, in order of increas-
ing detail and production difficulty. In fact, these
three prototypes were developed almost in paral-
lel. They were built by different design team mem-
bers during the early stages of the project. No single
prototype could have represented the design of the
future artifact at that time. The evolving design
was too fuzzy—existing mainly as a shared con-
cept in the minds of the designers. There were also
too many open and interdependent questions in
every design dimension: role, look and feel, imple-

Making separate prototypes enabled specific design
questions to be addressed with as much clarity as
possible. The solutions found became inputs to an
integrated design. Answers to the rendering capa-
bility questions addressed by Example 3 informed
the design of the role that the artifact could play
(guiding how many furniture objects of what com-
plexity could be shown). It also provided guiding
constraints for the direct manipulation user inter-
face (determining how much detail the handle forms
could have). Similarly, issues of role addressed by
Example 1 informed the implementation problem
by constraining it: only a constrained set of ma-
nipulations was needed for a space-planning appli-
cation. It also simplified the direct manipulation
user interface by limiting the necessary actions and
therefore controls which needed to be provided.

It was more efficient to wait on the results of inde-
pendent investigations in the key areas of role, look
and feel and implementation than to try to build a
monolithic prototype that integrated all features
from the start. After sufficient investigation in sepa-
rate prototypes, the prototype in Example 3 began

Example 3. Implementation prototype for 3D space-
planning application [E3 Chen 1990].


to evolve into an integrated prototype which could
be described by a position at the center of our
model. A version of the user interface developed
in Example 2 was implemented in the prototype in
Example 3. Results of other prototypes were also
integrated. This enabled a more complete user test
of features and user interface to take place.

This set of three prototypes from the same project
shows how a design problem can be simultaneously
approached from multiple points of view. Design
questions of role, look and feel, and implementa-
tion were explored concurrently by the team with
the three separate prototypes. The purpose of the
model is to make it easier to develop and subse-
quently communicate about this kind prototyping


In this section we present twelve more examples of
prototypes taken from real projects, and discuss
them in terms of the model. Examples are divided
into four categories which correspond to the four
main regions of the model, as indicated in Figure
3. The first three categories correspond to proto-
types with a strong bias toward one of the three
corners: role, look and feel, and implementation
prototypes, respectively. Integration prototypes
occupy the middle of the model: they explore a
balance of questions in all three dimensions.

4.1 Role prototypes

Role prototypes are those which are built prima-
rily to investigate questions of what an artifact
could do for a user. They describe the functional-

ity that a user might benefit from, with little atten-
tion to how the artifact would look and feel, or
how it could be made to actually work. Designers
find such prototypes useful to show their design
teams what the target role of the artifact might be;
to communicate that role to their supporting orga-
nization; and to evaluate the role in user studies.

A portable notebook computer

The paper storyboard shown in Example 4 was an
early prototype of a portable notebook computer
for students which would accept both pen and fin-
ger input. The scenario shows a student making
notes, annotating a paper, and marking pages for
later review in a computer notebook. The designer
presented the storyboard to her design team to fo-
cus discussion on the issues of what functionality
the notebook should provide and how it might be
controlled through pen and finger interaction. In
terms of the model, this prototype primarily ex-
plored the role of the notebook by presenting a
rough task scenario for it. A secondary consider-
ation was a rough approximation of the user inter-
face. Its marker, shown in Figure 4, is therefore
positioned near the role corner of the model and a
little toward look and feel.

Storyboards like this one are considered to be ef-
fective design tools by many designers because they
help focus design discussion on the role of an arti-
fact very early on. However, giving them status as
prototypes is not common because the medium is
paper and thus seems very far from the medium of

Look and feel




Figure 3. Four principal categories of prototypes on
the model.

Example 4. Storyboard for a portable notebook
computer [E4 Vertelney 1990].


an interactive computer system. We consider this
storyboard to be a prototype because it makes a
concrete representation of a design idea and serves
the purpose of asking and answering design ques-
tions. Of course, if the designer needed to evaluate
a user’s reaction to seeing the notebook or to using
the pen-and-finger interaction, it would be neces-
sary to build a prototype which supported direct
interaction. However, it might be wasteful to do so
before considering design options in the faster,
lighter-weight medium of pencil and paper.

An operating system user inter face

Example 5 shows a screen view of a prototype that
was used to explore the design of a new operating
system. The prototype was an interactive story: it
could only be executed through a single, ordered,
sequence of interactions. Clicking with a cursor
on the mailbox picture opened a mail window; then

clicking on the voice tool brought up a picture of
some sound tools; and so on. To demonstrate the
prototype, the designer sat in front of a computer
and play-acted the role of a user opening her mail,
replying to it, and so forth. The prototype was used
in design team discussions and also demonstrated
to project managers to explain the current design
direction. According to the model, this prototype
primarily explored the role that certain features of
the operating system could play in a user’s daily
tasks. It was also used to outline very roughly how
its features would be portrayed and how a user
would interact with it. As in the previous example,
the system’s implementation was not explored. Its
marker is shown in Figure 4.

To make the prototype, user interface elements were
hand-drawn and scanned in. Transitions between
steps in the scenario were made interactive in Mac-
romedia Director. This kind of portrayal of on-
screen interface elements as rough and hand-drawn
was used in order to focus design discussion on the
overall features of a design rather than on specific
details of look and feel or implementation (Wong,
1992). Ironically, while the design team understood
the meaning of the hand-drawn graphics, other
members of the organization became enamored with
the sketchy style to the extent that they considered
using it in the final artifact. This result was en-
tirely at odds with the original reasons for making
a rough-looking prototype. This example shows
how the effectiveness of some kinds of prototypes
may be limited to a specific kind of audience.

The Knowledge Navigator

Example 6 shows a scene from Apple Computer’s
Knowledge Navigator™ video. The video tape tells
a day-in-the-life story of a professor using a futur-
istic notebook computer (Dubberly and Mitch,
1987). An intelligent agent named “Phil” acts as
his virtual personal assistant, finding information
related to a lecture, reminding him of his mother’s
birthday, and connecting him with other professors
via video-link. The professor interacts with Phil by
talking, and Phil apparently recognizes everything
said as well as a human assistant would.

Based on the model, the Knowledge Navigator is
identified primarily as a prototype which describes

Look and feel







Figure 4. Relationship of role prototypes (Examples
4-7) to the model.

Example 5. Interactive story for an operating system
interface [E5 Vertelney and Wong 1990].


the role that the notebook would play in such a
user’s life. The story is told in great detail, and it is
clear that many decisions were made about what
to emphasize in the role. The video also shows spe-
cific details of appearance, interaction, and perfor-
mance. However, they were not intended by the
designers to be prototypes of look and feel. They
were merely placeholders for the actual design work
which would be necessary to make the product re-
ally work. Thus its marker goes directly on the
role corner (Figure 4).

Thanks to the video’s special effects, the scenario
of the professor interacting with the notebook and
his assistant looks like a demonstration of a real
product. Why did Apple make a highly produced
prototype when the previous examples show that a
rapid paper storyboard or a sketchy interactive pro-
totype were sufficient for designing a role and tell-
ing a usage story? The answer lies in the kind of
audience. The tape was shown publicly and to
Apple employees as a vision of the future of com-
puting. Thus the audience of the Knowledge Navi-
gator was very broad—including almost anyone in
the world. Each of the two previous role design
prototypes was shown to an audience which was
well informed about the design project. A rough
hand-drawn prototype would not have made the
idea seem real to the broad audience the video ad-
dressed: high resolution was necessary to help
people concretely visualize the design. Again, while
team members learn to interpret abstract kinds of
prototypes accurately, less expert audiences cannot

normally be expected to understand such approxi-
mate representations.

The Integrated Communicator

Example 7 shows an appearance model of an Inte-
grated Communicator created for customer research
into alternate presentations of new technology (ID
Magazine 1995). It was one of three presentations
of possible mechanical configurations and interac-
tion designs, each built to the same high finish and
accompanied by a video describing on-screen inter-
actions. In the study, the value of each presenta-
tion was evaluated relative to the others, as per-
ceived by study subjects during one-on-one inter-
views. The prototype was used to help subjects
imagine such a product in the store and in their
homes or offices, and thus to evaluate whether they
would purchase such a product, how much they
would expect it to cost, what features they would
expect, etc.

The prototype primarily addresses the role of the
product, by presenting carefully designed cues which
imply a telephone-like role and look-and-feel. Fig-
ure 4 shows its marker near the role corner of the
model. As with the Knowledge Navigator, the very
high-resolution look and feel was a means of mak-
ing the design as concrete as possible to a broad
audience. In this case however it also enabled a
basic interaction design strategy to be worked out
and demonstrated. The prototype did not address

Example 6. Knowledge Navigator™ vision video for a
future notebook computer [E6 Dubberly and Mitch ’87].

Example 7. Appearance model for the Integrated
Communicator [E7 Udagawa 1995].


The key feature of this kind of prototype is that it
is a concrete and direct representation, as visually
finished as actual consumer products. These at-
tributes encourage an uncoached person to directly
relate the design to their own environment, and to
the products they own or see in stores. High qual-
ity appearance models are costly to build. There
are two common reasons for investing in one: to
get a visceral response by making the design seem
“real” to any audience (design team, organization,
and potential users); and to verify the intended look
and feel of the artifact before committing to pro-
duction tooling. An interesting side-effect of this
prototype was that its directness made it a power-
ful prop for promoting the project within the orga-

4.2 Look and Feel prototypes

Look and feel prototypes are built primarily to ex-
plore and demonstrate options for the concrete ex-
perience of an artifact. …

error: Content is protected !!