52

PROTOTYPING TOOLS AND TECHNIQUES

Michel Beaudouin-Lafon
Universite ParisSud
Wendy Mackay
Institut National de Recherche en
Informatique et en Automatique (INRIA)

Introduction 1007
What Is a Prototype? 1007
Prototypes As Design Artifacts 1007
Representation 1007 Michel Beaudouin-Lafon and Wendy Mackay (2003). Prototyping
Precision 1008 Rapid Prototypes 1014
Interactivity 1008 Offline Rapid Prototyping Techniques 1014
Evolution 1009 Online Rapid Prototyping Techniques 1017
Prototypes and the Design Process 1009 Iterative Prototypes 1021
User-Centered Design 1009 Software Tools 1022
Participatory Design 1010 Software Environments 1025
Exploring the Design Space 1010 Evolutionary Prototypes 1026
Expanding the Design Space: Generating Ideas 1011 Software Architectures 1026
Contracting the Design Space: Selecting Alternatives ... 101 iin
2
Design Patterns 1028
Summary in in 1029
References 1029

1006
 52. Prototyping Tools and Techniques 1007

Human-computer interaction (HCI) is a multidisciplinary

INTRODUCTION field that combines elements of science, engineering, and design
(Dykstra-Erickson, Mackay, & Arnowitz, 2001; Mackay & Fayard,
"A good design is better than you think." 1997). Prototyping is primarily a design activity, although we use
RexHeftman, cited by Raskin, 2000, p. 143.
software engineering to ensure that software prototypes evolve
into technically sound working systems and we use scientific
Design is about making choices. In many fields that require cre-
methods to study the effectiveness of particular designs.
ativity and engineering skill, such as architecture or automobile
design, prototypes both inform the design process and help de-
signers select the best solution. This chapter describes tools and PROTOTYPES AS DESIGN ARTIFACTS
techniques for using prototypes to design interactive systems.
The goal is to illustrate how they can help designers generate We can look at prototypes as both concrete artifacts in their own
and share new ideas, get feedback from users or customers, right or as important components of the design process. When
choose among design alternatives, and articulate reasons for viewed as artifacts, successful prototypes have several charac-
their final choices. teristics: They support creativity, helping the developer to cap-
We begin with our definition of a prototype and then discuss ture and generate ideas, facilitate the exploration of a design
prototypes as design artifacts, introducing four dimensions for space, and uncover relevant information about users and their
analyzing them. We then discuss the role of prototyping within work practices. They encourage communication, helping de-
the design process, in particular, the concept of a design space signers, engineers, managers, software developers, customers,
and how it is expanded and contracted by generating and select- and users to discuss options and interact with each other. They
ing design ideas. The next three sections describe specific pro- also permit early evaluation because they can be tested in var-
totyping approaches: rapid prototyping, both offline and online, ious ways, including traditional usability studies and informal
for early stages of design; iterative prototyping, which uses on- user feedback, throughout the design process.
line development tools; and evolutionary prototyping, which We can analyze prototypes and prototyping techniques along
must be based on a sound software architecture. four dimensions:

Representation describes the form of the prototype (e.g., sets

What Is a Prototype? of paper sketches or computer simulations).
Precision describes the level of detail at which the prototype
We define a prototype as a concrete representation of part or all is to be evaluated (e.g., informal and rough or highly polished).
of an interactive system. A prototype is a tangible artifact, not Interactivity describes the extent to which the user can ac-
an abstract description that requires interpretation. Designers, tually interact with the prototype (e.g., watch only or fully
as well as managers, developers, customers, and end users, can interactive).
use these artifacts to envision and reflect on the final system. Evolution describes the expected life cycle of the prototype
Prototypes may be denned differently in other fields. For ex- (e.g., throw away or iterative).
ample, an architectural prototype is a scaled-down model of
the final building. This is not possible for interactive system
prototypes: The designer may limit the amount of information Representation
the prototype can handle, but the actual interface must be pre-
sented at full scale. Thus, a prototype interface to a database Prototypes serve different purposes and thus take different
may handle only a small pseudo-database but must still present forms. A series of quick sketches on paper can be considered
a full-size display and interaction techniques. Full-scale, one-of-a- a prototype; so can a detailed computer simulation. Both are
kind models, such as a handmade dress sample, are another type useful; both help the designer in different ways. We distinguish
of prototype. These usually require an additional design phase between two basic forms of representation: offline and online.
to mass produce the final design. Some interactive system pro- Offline prototypes (also called paper prototypes) do not
totypes begin as one-of-a-kind models that are then distributed require a computer. They include paper sketches, illustrated
widely (because the cost of duplicating software is so low); storyboards, cardboard mock-ups, and videos. The most salient
however, most successful software prototypes evolve into the characteristics of offline prototypes (of interactive systems) is
final product and then continue to evolve as new versions of that they are created quickly, usually in the early stages of de-
the software are released. sign, and they are usually thrown away when they have served
Hardware and software engineers often create prototypes their purpose.
to study the feasibility of a technical process. They conduct Online prototypes (also called software prototypes) run on
systematic, scientific evaluations with respect to predefined a computer. They include computer animations, interactive
benchmarks and, by systematically varying parameters, fine- video presentations, programs written with scripting languages,
tune the system. Designers in creative fields, such as typography and applications developed with interface builders. The cost
or graphic design, create prototypes to express ideas and reflect of producing online prototypes is usually higher and may re-
on them. This approach is intuitive, oriented more to discovery quire skilled programmers to implement advanced interaction
and generation of new ideas than to evaluation of existing ideas. and/or visualization techniques or to meet tight performance
1 008 BEAUDOUIN-LAFON AND MACKAY

constraints. Software prototypes are usually more effective in nature, prototypes require details. A verbal description such as
the later stages of design, when the basic design strategy has "the user opens the file" or "the system displays the results"
been decided. provides no information about what the user actually does.
In our experience, programmers often argue in favor of soft- Prototypes force designers to show the interaction: Just how
ware prototypes even at the earliest stages of design. Because does the user open the file and what are the specific results that
they already are familiar with a programming language, these appear on the screen?
programmers believe it will be faster and more useful to write Precision refers to the relevance of details with respect to
code than to "waste time" creating paper prototypes. In 20 years the purpose of the prototype.1 For example, when sketching a
of prototyping, in both research and industrial settings, we have dialogue box, the designer specifies its size, the positions of each
yet to find a situation in which this is true. field, and the titles of each label. Not all these details are relevant
First, offline prototypes are inexpensive and quick. This per- to the goal of the prototype, however. It may be necessary to
mits a rapid iteration cycle and helps prevent the designer from show where the labels are, but too early to choose the text. The
becoming overly attached to the first possible solution. Offline designer can convey this by writing nonsense words or drawing
prototypes make it easier to explore the design space (discussed squiggles, which shows the need for labels without specifying
in detail later), examining a variety of design alternatives and their actual content.
choosing the most effective solution. Online prototypes intro- Although it may seem contradictory, a detailed representa-
duce an intermediary between the idea and the implementation, tion need not be precise. This is an important characteristic of
slowing down the design cycle. prototypes: Those parts of the prototype that are not precise
Second, offline prototypes are less likely to constrain the de- are those open for future discussion or for exploration of the
signer's thinking. Every programming language or development design space, yet they need to be incarnated in some form so
environment imposes constraints on the interface, limiting cre- the prototype can be evaluated and iterated.
ativity and restricting the number of ideas considered. If a partic- The level of precision usually increases as successive pro-
ular tool makes it easy to create scroll bars and pull-down menus totypes are developed and more and more details are set. The
and difficult to create a zoomable interface, the designer is likely forms of the prototypes reflect their level of precision; sketches
to limit the interface accordingly Considering a wider range of tend not to be precise, whereas computer simulations are usu-
alternatives, even if the developer ends up using a standard set ally very precise. Graphic designers often prefer using hand
of interface widgets, usually results in a more creative design. sketches for early prototypes because the drawing style can
Finally, and perhaps most important, offline prototypes can directly reflect what is precise and what is notthe wigglely
be created by a wide range of people, not just programmers. shape of an object or a squiggle that represents a label are di-
Thus, all types of designers, technical or otherwise, as well as rectly perceived as imprecise. This is more difficult to achieve
users, managers, and other interested parties, can all contribute with an online drawing tool or a user interface builder.
on an equal basis. Unlike programming software, modifying a The form of the prototype must be adapted to the desired
storyboard or cardboard mock-up requires no particular skill. level of precision. Precision defines the tension between what
Collaborating on paper prototypes not only increases partici- the prototype states (relevant details) and what the prototype
pation in the design process, but also improves communication leaves open (irrelevant details). What the prototype states is
among team members and increases the likelihood that the final subject to evaluation; what the prototype leaves open is subject
design solution will be well accepted. to more discussion and design space exploration.
Although we believe strongly in offline prototypes, they are
not a panacea. In some situations, they are insufficient to fully Interactivity
evaluate a particular design idea. For example, interfaces re-
quiring rapid feedback to users or complex, dynamic visualiza- An important characteristic of HCI systems is that they are
tions usually require software prototypes. However, particularly interactive: users both respond to them and act on them. Unfor-
when using video and "Wizard-of-Oz" techniques, which we de- tunately, designing effective interaction is difficult: Many inter-
scribe later, offline prototypes can be used to create sophisti- active systems (including many Web sites) have a good "look"
cated representations of the system. but a poor "feel." HCI designers can draw from a long tradi-
Prototyping is an iterative process, and all prototypes provide tion in visual design for the former but have relatively little
information about some aspects while ignoring others. The de- experience with how interactive software systems should be
signer must consider the purpose of the prototype (Houde & usedpersonal computers have only been commonplace for
Hill, 1997) at each stage of the design process and choose the about a decade. Another problem is that the quality of interac-
representation that is best suited to the current design question. tion is tightly linked to the end users and a deep understanding
of their work practices. A word processor designed for profes-
Precision sional typographers requires a different interaction design than
one designed for secretaries, even though ostensibly they serve
Prototypes are explicit representations that help designers, en- similar purposes. Designers must take the context of use into
gineers, and users reason about the system being built. By their account when designing the details of the interaction.

1The terms low-fidelity and high-fidelity prototypes are often used in the literature. We prefer the term precision because it refers to the content of
the prototype itself, not its relationship to the final, as-yet-undefined system.
 52. Prototyping Tools and Techniques 1009

A critical role for an interactive system prototype is to illus- their precision) or to explore various alternatives. Evolutionary
trate how the user will interact with the system. Although this prototypes are designed to become part of the final system.
may seem more natural with online prototypes, in fact it is of- Rapid prototypes are especially important in the early stages
ten easier to explore different interaction strategies with offline of design. They must be inexpensive and easy to produce be-
prototypes. Note that interactivity and precision are orthogo- cause the goal is to quickly explore a wide variety of possible
nal dimensions. One can create an imprecise prototype that is types of interaction and then throw them away. Note that rapid
highly interactive, such as a series of paper screen images in prototypes may be offline or online. Creating precise software
which one person acts as the user and the other plays the sys- prototypes, even if they must be reimplemented in the final ver-
tem. Or one may create a precise but noninteractive prototype, sion of the system, is important for detecting and fixing inter-
such as a detailed animation that shows feedback from a specific action problems. We present specific prototyping techniques,
action by a user. both offline and online, later in the chapter.
Prototypes can support interaction in various ways. For Iterative prototypes are developed as a reflection of a design
offline prototypes, one person (often with help from others) in progress, with the explicit goal of evolving through several
plays the role of the interactive system, presenting information design iterations. Designing prototypes that support evolution is
and responding to the actions of another person playing the sometimes difficult. There is a tension between evolving toward
role of the user. For online prototypes, parts of the software the final solution and exploring an unexpected design direction,
are implemented, whereas others are "played" by a person (an which may be adopted or thrown away completely. Each itera-
approach called the "Wizard of Oz" after the character in the tion should inform some aspect of the design. Some iterations
1939 movie of the same name). The key is that the prototype explore different variations of the same theme. Others may sys-
feels interactive to the user. tematically increase precision, working out the finer details of
Prototypes can support different levels of interaction. Fixed the interaction. We describe tools and techniques for creating
prototypes, such as video clips or precomputed animations, are iterative prototypes later in the chapter.
noninteractive. The user cannot interact, or pretend to inter- Evolutionary prototypes are a special case of iterative proto-
act, with it. Fixed prototypes are often used to illustrate or test types in which the prototype evolves into part or all of the final
scenarios (see chapter 53 by Rosson and Carroll). Fixed-path system (Fig. 52.1). Obviously this only applies to software pro-
prototypes support limited interaction. The extreme case is a totypes. Extreme Programming (Beck, 2000), advocates this ap-
fixed prototype in which each step is triggered by a prespecified proach, tightly coupling design and implementation and build-
user action. For example, the person controlling the prototype ing the system through constant evolution of its components.
might present the user with a screen containing a menu. When Evolutionary prototypes require more planning and practice
the user points to the desired item, she presents the correspond- than the approaches above because the prototypes are both
ing screen showing a dialogue box. When the user points to the representations of the final system and the final system itself,
word OK, she presents the screen that shows the effect of the making it more difficult to explore alternative designs. We ad-
command. Even though the position of the click is irrelevant (it vocate a combined approach, beginning with rapid prototypes
is used as a trigger), the person in the role of the user can get a and then using iterative or evolutionary prototypes according to
feel for the interaction. Of course, this type of prototype can be the needs of the project. Later in the chapter, we describe how
much more sophisticated, with multiple options at each step. to create evolutionary prototypes by building on software archi-
Fixed-path prototypes are effective with scenarios and can also tectures specifically designed to support interactive systems.
be used for horizontal and task-based prototypes (discussed in
detail in the next section).
Open prototypes support large sets of interactions. Such pro- PROTOTYPES AND THE DESIGN PROCESS
totypes work like the real system, with some limitations. They
usually only cover part of the system (discussed in the next In the previous section, we looked at prototypes as artifacts
section) and often have limited error-handling or reduced per- (i.e., the results of a design process). Prototypes can also be
formance relative to that of the final system. seen as artifacts/or design (i.e., as an integral part of the design
Prototypes may thus illustrate or test different levels of inter- process). Prototyping helps designers think: Prototypes are the
activity. Fixed prototypes simply illustrate what the interaction tools they use to solve design problems. In this section, we focus
might look like. Fixed-path prototypes provide designers and on prototyping as a process and its relationship to the overall
users with the experience of what the interaction might be design process.
like, but only in prespecified situations. Open prototypes allow
designers to test a wide range of examples of how users will
interact with the system. User-Centered Design
The HCI field is both user-centered (Norman & Draper, 1986)
Evolution and iterative. User-centered design places the user at the cen-
ter of the design process, from the initial analysis of user re-
Prototypes have different life spans. Rapid prototypes are cre- quirements (see chapters 48-50 in this volume) to testing and
ated for a specific purpose and then thrown away. Iterative evaluation (see chapters 56-59 in this volume). Prototypes sup-
prototypes evolve, either to work out some details (increasing port this goal by allowing users to see and experience the final
1010 BEAUDOUIN-LAFON AND MACKAY

FIGURE 52.1. Evolutionary prototypes of the Apple Lisa: July 1979

(left), October 1980 (right). Note. From "Inventing the Lisa User Inter-
face" by R. Perkins, D. S. Keller, and F. Ludolph, 1997, ACM Interactions,
4, pp. 43, 47. Copyright 1997 by the Association for Computing Machin-
ery. Reprinted with permission.

system long before it is built. Designers can identify functional A common misconception about participatory design is that
requirements, usability problems, and performance issues early designers are expected to abdicate their responsibilities as
and improve the design accordingly. designers, leaving the design to the end user. In fact, the goal
Iterative design involves multiple design-implement-test is for designers and users to work together, each contributing
loops,2 enabling the designer to generate different ideas and their strengths to clarify the design problem as well as explore
successively improve on them. Prototypes support this goal by design solutions. Designers must understand what users can and
allowing designers to evaluate concrete representations of de- cannot contribute. Usually, users are best at understanding the
sign ideas and select the best. context in which the system will be used and subtle aspects of
Prototypes reveal the strengths as well as the weaknesses the problems that must be solved. Innovative ideas can come
of a design. Unlike pure ideas, abstract models, or other repre- from both users and designers, but the designer is responsible
sentations, they can be contextualized to help understand how for considering a wide range of options that might not be known
the real system would be used in a real setting. Because proto- to the user and balancing the trade-offs among them.
types are concrete and detailed, designers can explore different Because prototypes are shared, concrete artifacts, they serve
real-world scenarios, and users can evaluate them with respect as an effective medium for communication within the design
to their current needs. Prototypes can be compared directly team. We have found that collaborating on prototype design is
with existing systems, and designers can learn about the con- an effective way to involve users in participatory design. Proto-
text of use and the work practices of the end users. Prototypes types help users articulate their needs and reflect on the efficacy
can help designers (re)analyze users' needs during the design of design solutions proposed by designers.
process, not abstractly as with traditional requirements analysis,
but in the context of the system being built. Exploring the Design Space

Participatory Design Design is not a natural science. The goal is not to describe and
understand existing phenomena but to create something new.
Participatory (also called cooperative) design is a form of user- Designers do, of course, benefit from scientific research find-
centered design that actively involves the user in all phases the ings, and they may use scientific methods to evaluate interac-
design process (see Greenbaum & Kyng, 1991, and chapter 54 tive systems. But designers also require specific techniques for
by Muller in this volume). Users are not simply consulted at the generating new ideas and balancing complex sets of trade-offs
beginning and called in to evaluate the system at the end; they to help them develop and refine design ideas.
are treated as partners throughout. This early and active involve- Designers from fields such as architecture and graphic de-
ment of users helps designers avoid unpromising design paths sign have developed the concept of a design space, which con-
and develop a deeper understanding of the actual design prob- strains design possibilities along some dimensions, while leav-
lem. Obtaining user feedback at each phase of the process also ing others open for creative exploration. Ideas for the design
changes the nature of the final evaluation, which is used to fine- space come from many sources: existing systems, other de-
tune the interface rather than discover major usability problems. signs, other designers, external inspiration, and accidents that

2
Software engineers refer to this as the Spiral model (Boehm, 1988).
 52. Prototyping Tools and Techniques 1011

prompt new ideas. Designers are responsible for creating a de- Expanding the Design Space: Generating Ideas
sign space specific to a particular design problem. They explore
this design space, expanding and contracting it as they add and The most well-known idea generation technique is brainstorm-
eliminate ideas. The process is iterative, more cyclic, than re- ing, introduced by Osborn (1957). His goal was to create syn-
ductionist. That is, the designer does not begin with a rough ergy within the members of a group: Ideas suggested by one
idea and successively add more precise details until the final participant would spark ideas in other participants. Subsequent
solution is reached. Instead, she begins with a design prob- studies (Collaros & Anderson, 1969; Diehl & Stroebe, 1987) chal-
lem, which imposes set of constraints, and generates a set of lenged the effectiveness of group brainstorming, finding that ag-
ideas to form the initial design space. She then explores this gregates of individuals could produce the same number of ideas
design space, preferably with the user, and selects a particular as groups. They found certain effects, such as production block-
design direction to pursue. This closes off part of the design ing, free-riding, and evaluation apprehension, were sufficient
space but opens up new dimensions that can be explored. The to outweigh the benefits of synergy in brainstorming groups.
designer generates additional ideas along these dimensions, ex- Since then, many researchers have explored different strategies
plores the expanded design space, and then makes new design for addressing these limitations. For our purposes, the quantity
choices. Design principles (e.g., Beaudouin-Lafon & Mackay, of ideas is not the only important measure: The relationships
2000) help this process by guiding it both in the exploration among members of the group are also important. As de Vreede,
and choice phases. The process continues, in a cyclic expansion Briggs, van Duin, and Enserink (2000) pointed out, one should
and contraction of the design space, until a satisfying solution is also consider elaboration of ideas as group members react to
reached. each other's ideas.
All designers work with constraintsnot just limited bud- We have found that brainstorming, including a variety of vari-
gets and programming resources, but also design constraints. ants, is an important group-building exercise in participatory de-
These are not necessarily bad; one cannot be creative along all sign. Designers may, of course, brainstorm ideas by themselves.
dimensions at once. Some constraints are unnecessary, how- But brainstorming in a group is more enjoyable and, if it is a
ever, derived from poor framing of the original design problem. recurring part of the design process, plays an important role in
If we consider a design space as a set of ideas and a set of con- helping group members share and develop ideas together.
straints, the designer has two options. She can modify ideas The simplest form of brainstorming involves a small group of
within the specified constraints or modify the constraints to en- people. The goal is to generate as many ideas as possible on a pre-
able new sets of ideas. Unlike traditional engineering, which specified topic; quantity not quality, is important. Brainstorming
treats the design problem as a given, designers are encouraged sessions have two phases: The first generates ideas and the sec-
to challenge, and if necessary, change the initial design problem. ond reflects on those ideas. The initial phase should last no more
If she reaches an impasse, the designer can either generate new than an hour. One person should moderate the session, keep-
ideas or redefine the problem (and thus change the constraints). ing time and ensuring that everyone participates and preventing
Some of the most effective design solutions derive from a more people from critiquing each other's ideas. Discussion should be
careful understanding and refraining of the design brief. limited to clarifying the meaning of a particular idea. A second
Note that all members of the design team, including users, person records every idea, usually on a flipchart or transparency
may contribute ideas to the design space and help select design on an overhead projector. After a short break, participants are
directions from within it. However, it is essential that these two asked to reread all the ideas, and each person marks their three
activities are kept separate. Expanding the design space requires favorite ideas.
creativity and openness to new ideas. During this phase, every- One variation is designed to ensure that everyone con-
one should avoid criticizing ideas and concentrate on generating tributes, not just those who are verbally dominant. Participants
as many as possible. Clever ideas, half-finished ideas, silly ideas, write their ideas on individual cards notes for a prespecified pe-
impractical ideas all contribute to the richness of the design riod of time. The moderator then reads each idea aloud. Authors
space and improve the quality of the final solution. In contrast, are encouraged to elaborate (but not justify) their ideas, which
contracting the design space requires critical evaluation of ideas. are then posted on a whiteboard or flipchart. Group members
During this phase, everyone should consider the constraints and may continue to generate new ideas, inspired by the others they
weigh the trade-offs. Each major design decision must eliminate hear.
part of the design space: rejecting ideas is necessary to experi- We use a variant of brainstorming that involves prototypes
ment and refine others and make progress in the design process. called video brainstorming (Mackay, 2000): Participants not
Choosing a particular design direction should spark new sets of only write or draw their ideas, they act them out in front of a
ideas, and those new ideas are likely to pose new design prob- video camera (Fig. 52.2). The goal is the same as other brain-
lems. In summary, exploring a design space is the process of storming exercises: to create as many new ideas as possible,
moving back and forth between creativity and choice. without critiquing them. The use of video, combined with paper
Prototypes aid designers in both aspects of working with or cardboard mock-ups, encourages participants to actively ex-
a design space: generating concrete representations of new perience the details of the interaction and to understand each
ideas and clarifying specific design directions. The next two idea from the perspective of the user.
subsections describe techniques that have proven most useful Each video brainstorming idea takes 2 to 5 minutes to gener-
in our own prototyping work, both for research and product ate and capture, allowing participants to simulate a wide variety
development. of ideas quickly. The resulting video clips provide illustrations
 1012 BEAUDOUIN-LAFON AND MACKAY

good, potentially effective ideas is difficult, but necessary to

make progress.
Prototypes often make it easier to evaluate design ideas from
the user's perspective. They provide concrete representations
that can be compared. Many of the evaluation techniques de-
scribed elsewhere in this handbook can be applied to proto-
types to help focus the design space. The simplest situation
is when the designer must choose among several discrete, in-
dependent options. Running a simple experiment, using tech-
niques borrowed from psychology (see chapter 56 by Dumas)
allows the designer to compare how users respond to each of
the alternatives. The designer builds a prototype, with either
fully implemented or simulated versions of each option. The
next step is to construct tasks or activities that are typical of
how the system would be used, and ask people from the user
population to try each of the options under controlled condi-
tions. It is important to keep everything the same, except for
the options being tested.
FIGURE 52.2. Video brainstorming: One person moves the
Designers should base their evaluations on both quantitative
transparency, projected onto the wall, in response to the ac-
measures, such as speed or error rate, and qualitative measures,
tions of the user, who explores how he might interact with an
such as the user's subjective impressions of each option. Ideally,
online animated character. Each interaction idea is recorded
of course, one design alternative will be clearly faster, prone to
and videotaped.
fewer errors, and preferred by the majority of users. More often,
the results are ambiguous, and the designer must take other fac-
of each idea that are easier to understand (and remember) than tors into account when making the design choice. (Interestingly,
hand-written notes. (We find that raw notes from brainstorming running small experiments often highlights other design prob-
sessions are not very useful after a few weeks because the par- lems and may help the designer reformulate the design problem
ticipants no longer remember the context in which the ideas or change the design space.)
were created.) The more difficult (and common) situation is when the de-
Video brainstorming requires thinking more deeply about signer faces a complex, interacting set of design alternatives
each idea. It is easier to stay abstract when describing an inter- in which each design decision affects a number of others. De-
action in words or even with a sketch, but acting out the interac- signers can use heuristic evaluation techniques, which rely on
tion in front of the camera forces the author of the idea (and the our understanding of human cognition, memory, and sensory-
other participants) to consider seriously how a user would inter- perception (see chapters 1-6). They can also evaluate their de-
act with the idea. It also encourages designers and users to think signs with respect to ergonomic criteria (see chapter 51 by
about new ideas in the context in which they will be used. Video Stewart and Trans) or design principles (Beaudouin-Lafon &
clips from a video brainstorming session, even though rough, Mackay, 2000). (See chapters 56-60 for a more thorough dis-
are much easier for the design team, including developers, to cussion of testing and evaluation methods.)
interpret than ideas from a standard brainstorming session. Another strategy is to create one or more scenarios (see
We generally run a standard brainstorming session, either chapter 53 by Rosson and Carroll) that illustrate how the com-
oral or with cards, before a video brainstorming session to max- bined set of features will be used in a realistic setting. The sce-
imize the number of ideas to be explored. Participants then take nario must identify who is involved, where the activities take
their favorite ideas from the previous session and develop them place, and what the user does over a specified period of time.
further as video brainstorms. Each person is asked to "direct" at Good scenarios involve more than a string of independent tasks;
least two ideas, incorporating the hands or voices of other mem- they should incorporate real-world activities, including com-
bers of the group. We find that, unlike standard brainstorming, mon or repeated tasks, successful activities, and breakdowns
video brainstorming encourages even the quietest team mem- and errors, with both typical and unusual events. The designer
bers to participate. then creates a prototype that simulates or implements the as-
pects of the system necessary to illustrate each set of design
alternatives. Such prototypes can be tested by asking users to
Contracting the Design Space: Selecting Alternatives "walk through" the same scenario several times, once for each
design alternative. As with experiments and usability studies,
After expanding the design space by creating new ideas, de- designers can record both quantitative and qualitative data, de-
signers must stop and reflect on the choices available to them. pending on the level of the prototypes being tested.
After exploring the design space, designers must evaluate their The previous section described an idea-generation technique
options and make concrete design decisionschoosing some called video brainstorming, which allows designers to generate
ideas, specifically rejecting others, and leaving other aspects of a variety of ideas about how to interact with the future system.
the design open to further idea generation activities. Rejecting We call the corresponding technique for focusing in on a design
 52. Prototyping Tools and Techniques 1013

video prototyping. Video prototyping can incorporate any of the notion of magnetic guidelines in the CPN2000 system to
the rapid-prototyping techniques (offline or online) described facilitate the alignment of graphical objects (Beaudouin-Lafon
later. They are quick to build, force designers to consider the & Mackay, 2000), we implemented a vertical prototype to test
details of how users will react to the design in the context in not only the interaction technique but also the layout algorithm
which it will be used, and provide an inexpensive method of and the performance. We knew that we could only include the
comparing complex sets of design decisions. particular interaction technique if the we could implement a
To an outsider, video brainstorming and video prototyp- sufficiently fast response.
ing techniques look very similar. Both involve small design Vertical prototypes are generally high precision, software
groups working together, creating rapid prototypes and inter- prototypes because their goal is to validate an idea at the system
acting with them in front of a video camera. Both result in level. They are often thrown away because they are generally
video illustrations that make abstract ideas concrete and help created early in the project, before the overall architecture has
team members communicate with each other. The critical dif- been decided, and they focus on only one design question. For
ference is that video brainstorming expands the design space example, a vertical prototype of a spelling checker for a text ed-
by creating a number of unconnected collections of individual itor does not require text editing functions to be implemented
ideas, whereas video prototyping contracts the design space and tested. The final version will need to be integrated into the
by showing how a specific collection of design choices work rest of the system, however, which may involve considerable
together. architectural or interface changes.

Task-Oriented Prototypes. Many user interface designers

Prototyping Strategies begin with a task analysis (see chapter 48 by Redish and Wixon)
to identify the individual tasks that the user must accomplish
Designers must decide what role prototypes should play with re- with the system. Each task requires a corresponding set of func-
spect to the final system and in which order to create different tionality from the system. Task-based prototypes are organized
aspects of the prototype. The next subsections presents four as a series of tasks, which allows both designers and users to
strategies: horizontal, vertical, task-oriented, and scenario- test each task independently, systematically working through
based, which focus on different design concerns. These strate- the entire system.
gies can use any of the prototyping techniques covered in the Task-oriented prototypes include only the functions neces-
sections that follow. sary to implement the specified set of tasks. They combine
the breadth of horizontal prototypes, to cover the functions
Horizontal Prototypes. The purpose of a horizontal proto- required by those tasks, with the depth of vertical prototypes,
type is to develop an entire layer of the design at the same time. enabling detailed analysis of how the tasks can be supported.
This type of prototyping is most common with large software Depending on the goal of the prototype, both offline and online
development teams, where designers with different skill sets representations can be used for task-oriented prototypes.
address different layers of the software architecture. Horizontal
prototypes of the user interface are useful to get an overall pic- Scenario-Based Prototypes. Scenario-based prototypes are
ture of the system from the user's perspective and address issues similar to task-oriented ones, except that they do not stress in-
such as consistency (similar functions are accessible through dividual, independent tasks but rather follow a more realistic
similar user commands), coverage (all required functions are scenario of how the system would be used in a real-world set-
supported), and redundancy (the same function is/is not acces- ting. Scenarios are stories that describe a sequence of events
sible through different user commands). and how the user reacts (see chapter 53 by Rosson and Carroll).
User interface horizontal prototypes can begin with rapid A good scenario includes both common and unusual situa-
prototypes and progress through to working code. Software tions and should explore patterns of activity over time. B0dker,
prototypes can be built with an interface builder (discussed later Christiansen, and Thuring (1995) developed checklist, to ensure
in the chapter), without creating any of the underlying function- that no important issues have been left out.
ality, making it possible to test how the user will interact with the We find it useful to begin with use scenarios based on obser-
user interface without worrying about how the rest of the archi- vations of or interviews with real users. Ideally, some of those
tecture works. Some level of scaffolding or simulation of the rest users should participate in the creation of the specific scenar-
of the application is often necessary, however, otherwise the ios, and other users should critique them based on how realistic
prototype cannot be evaluated properly. As a consequence, soft- they are. Use scenarios are then turned into design scenarios, in
ware horizontal prototypes tend to be evolutionary (i.e., they which the same situations are described but with the functional-
are progressively transformed into the final system). ity of the new system. Design scenarios are used, among other
things, to create scenario-based video prototypes or software
Vertical Prototypes. The purpose of a vertical prototype is prototypes. Like task-based prototypes, the developer needs to
to ensure that the designer can implement the full, working write only the software necessary to illustrate the components
system from the user interface layer down to the underlying of the design scenario. The goal is to create a situation in which
system layer. Vertical prototypes are often built to assess the the user can experience what the system would be like in a re-
feasibility of a feature described in a horizontal, task-oriented, alistic situation, even if it addresses only a subset of the planned
or scenario-based prototype. For example, when we developed functionality.
1014 BEAUDOUIN-LAFON AND MACKAY

The following section describes a variety of rapid prototyp-

ing techniques that can be used in any of these four prototyping
strategies. We begin with offline rapid prototyping techniques,
followed by online prototyping techniques.

RAPID PROTOTYPES
The goal of rapid prototyping is to develop prototypes quickly,
in a fraction of the time it would take to develop a working sys-
tem. By shortening the prototype-evaluation cycle, the design
team can evaluate more alternatives and iterate the design sev-
eral times, improving the likelihood of finding a solution that
successfully meets the user's needs.
How rapid is rapid depends on the context of the particular
project and the stage in the design process. Early prototypes
(e.g., sketches) can be created in a few minutes. Later in the
design cycle, a prototype produced in less than a week may
still be considered "rapid" if the final system is expected to take
months or years to build. Precision, interactivity, and evolution
all affect the time it takes to create a prototype. Not surprisingly, FIGURE 52.3. Hand-drawn transparencies can be projected
a precise and interactive prototype takes more time to build than onto a wall, creating an interface a user can respond to.
an imprecise or fixed one.
The techniques presented in this section are organized from
Everyone in the room gets an immediate impression of how the
most rapid to least rapid, according to the representation dimen-
eventual interface might look and feel.
sion introduced earlier. Offline techniques are generally more
Note that most paper prototypes begin with quick sketches
rapid than online ones; however, creating successive iterations
on paper, then progress to more carefully drawn screen images
of an online prototype may end up being faster than creating
made with a computer (Fig. 52.4). In the early stages, the goal is
new offline prototypes.
to generate a wide range of ideas and expand the design space,
not to determine the final solution. Paper-and-pencil prototypes
are an excellent starting point for horizontal, task-based, and
Offline Rapid Prototyping Techniques scenario-based prototyping strategies.

Offline prototyping techniques range from simple to elaborate. Mock-Ups. Architects use mock-ups or scaled prototypes
Because they do not involve software, they are usually consid- to provide three-dimensional illustrations of future buildings.
ered a tool for thinking through the design issues, to be thrown Mock-ups are also useful for interactive system designers,
away when they are no longer needed. This section describes
simple paper-and-pencil sketches, three-dimensional mock-ups,
Wizard-of-Oz simulations, and video prototypes.

Paper and Pencil. The fastest form of prototyping involves

paper, transparencies, and post-it notes to represent aspects of
an interactive system (for an example, see Muller, 1991). By
playing the roles of both the user and the system, designers
can get a quick idea of a wide variety of different layout and
interaction alternatives in a short period of time.
Designers can create a variety of low-cost "special effects."
For example, a tiny triangle drawn at the end of a long strip cut
from an overhead transparency makes a handy mouse pointer,
which can be moved by a colleague in response to the user's
actions. Post-it Notes, with prepared lists, can provide "pop-up
menus." An overhead projector pointed at a whiteboard makes
it easy to project transparencies (hand-drawn or preprinted,
overlaid onto each other as necessary) to create an interactive FIGURE 52.4. Several people work together to simulate in-
display on the wall. The user can interact by pointing (Fig. 52.3) teracting with this paper prototype. One person moves a
or drawing on the whiteboard. One or more people can watch transparency with a mouse pointer, while another moves the
the user and move the transparencies in response to her actions. diagram accordingly.
 52. Prototyping Tools and Techniques 1015

FIGURE 52.6. Scaled mock-up of an air traffic control table,

FIGURE 52.5. Mock-up of a handheld display with carrying connected to a wall display.
handle.

helping them move beyond two-dimensional images drawn on ways, creates the illusion of a working software program. In
paper or transparencies (see B0dker, Ehn, Knudsen, Kyng, & some cases, the user is unaware that a person, rather than a
Madsen, 1988). Generally made of cardboard, foamcore or other computer, is operating the system.
found materials, mock-ups are physical prototypes of the new The Wizard-of-Oz technique lets users interact with partially
system. Figure 52.5 shows an example of a handheld mock-up functional computer systems. Whenever they encounter some-
showing the interface to a new handheld device. The mock-up thing that has not been implemented (or there is a bug), a human
provides a deeper understanding of how the interaction will developer who is watching the interaction overrides the proto-
work in real-world situations than possible with sets of screen type system and plays the role destined to eventually be played
images. by the computer. A combination of video and software can work
Mock-ups allow the designer to concentrate on the physi- well, depending on what needs to be simulated.
cal design of the device, such as the position of buttons or the The Wizard of Oz was initially used to develop natural lan-
screen. The designer can also create several mock-ups and com- guage interfaces (e.g., Chapanis, 1982; Good, Whiteside, Wixon,
pare input or output options, such as buttons versus trackballs. & Jones, 1984). Since then, the technique has been used in a
Designers and users should run through different scenarios, wide variety of situations, particularly those in which rapid re-
identifying potential problems with the interface or generating sponses from users are not critical. Wizard-of-Oz simulations
ideas for new functionality. Mock-ups can also help the designer may consist of paper prototypes, fully implemented systems,
envision how an interactive system will be incorporated into a and everything in between.
physical space (Fig. 52.6).
Video Prototyping. Video prototypes (Mackay, 1988) use
Wizard of Oz. Sometimes it is useful to give users the im- video to illustrate how users will interact with the new system.
pression that they are working with a real system, even before As explained earlier, they differ from video brainstorming in
it exists. Kelley (1983) dubbed this technique the Wizard of Oz, that the goal is to refine a single design, not generate new ideas.
based on a scene in the 1939 movie of the same name. The hero- Video prototypes may build on paper-and-pencil prototypes and
ine, Dorothy, and her companions ask the mysterious Wizard of cardboard mock-ups and can also use existing software and im-
Oz for help. When they enter the room, they see an enormous ages of real-world settings.
green human head, breathing smoke and speaking with a deep, We begin our video prototyping exercises by reviewing rele-
impressive voice. When they return later to see the Wizard, vant data about users and their work practices and then review
Dorothy's small dog pulls back a curtain, revealing a frail old ideas we video brainstormed. The next step is to create a use
man pulling levers and making the mechanical Wizard of Oz scenario, describing the user at work. Once the scenario is de-
speak. They realize that the impressive being before them is not scribed in words, the designer develops a storyboard. Similar
a wizard at all, but simply an interactive illusion created by the to a comic book, the storyboard shows a sequence of rough
old man. sketches of each action or event, with accompanying actions
The software version of the Wizard of Oz operates on the and dialogue (or subtitles), with related annotations that explain
same principle. A user sits a terminal and interacts with a pro- what is happening in the scene or the type of shot (Fig. 52.7).
gram. Hidden elsewhere, the software designer (the wizard) A paragraph of text in a scenario corresponds to about a page
watches what the user does and, by responding in different of a storyboard.
1016 BEAUDOUIN-LAFON AND MACKAY

FIGURE 52.7. This storyboard is based on observations of real Colour-

ed Petri Net (CPN) users in a small company and illustrates how the CPN
developer modifies a particular element of a net, the "Simple Protocol."

Storyboards help designers refine their ideas, generate "what The process of creating a video prototype, based on the story-
if" scenarios for different approaches to a story, and communi- board, provides an even deeper understanding of the design and
cate with the other people who are involved in creating the how a user will interact with it.
production. Storyboards may be informal "sketches" of ideas, The storyboard guides the shooting of the video. We of-
with only partial information. Others follow a predefined for- ten use a technique called "editing-in-the-camera" (see Mackay,
mat and are used to direct the production and editing of a video 2000), which allows us to create the video directly, without
prototype. Designers should jot down notes on Storyboards as editing later. We use title cards, as in a silent movie, to sepa-
they think through the details of the interaction. rate the clips and to make it easier to shoot. A narrator explains
Storyboards can be used like comic books to communi- each event, and several people may be necessary to illustrate
cate with other members of the design team. Designers and the interaction. Team members enjoy playing with special ef-
users can discuss the proposed system and alternative ideas fects, such as "time-lapse photography." For example, we can
for interacting with it (Fig. 52.8). Simple videos of each suc- record a user pressing a button, stop the camera, add a new
cessive frame, with a voiceover to explain what happens, dialogue box, and then restart the camera to create the illusion
can also be effective. We usually use Storyboards to help us of immediate system feedback.
shoot video prototypes, which illustrate how a new system Video is not simply a way to capture events in the real world
will look to a user in a real-world setting. We find that placing or to capture design ideas but can also be a tool for sketch-
the elements of a storyboard on separate cards and arranging ing and visualizing interactions. We use a second live video
them (Mackay & Pagani, 1994) helps the designer experiment camera as a Wizard-of-Oz tool. The wizard should have access
with different linear sequences and insert or delete video clips. to a set of prototyping materials representing screen objects.
 52. Prototyping Tools and Techniques 1017

FIGURE 52.8. Video prototyping: The Coloured Petri Net

(CPN) design team reviews their observations of CPN devel-
opers and then discuss several design alternatives. They work FIGURE 52.9. Complex Wizard-of-Oz simulation, with pro-
out a scenario and storyboard it, then shoot a video prototype jected image from a live video camera and transparencies pro-
that reflects their design. jected from an overhead projector.

Other team members stand by, ready to help move objects as Online Rapid Prototyping Techniques
needed. The live camera is pointed at the wizard's work area,
with either a paper prototype or a partially working software The goal of online rapid prototyping is to create higher preci-
simulation. The resulting image is projected onto a screen or sion prototypes than can be achieved with offline techniques.
monitor in front of the user. One or more people should be Such prototypes may prove useful to better communicate ideas
situated so that they can observe the actions of the user and to clients, managers, developers, and end users. They are also
manipulate the projected video image accordingly. This is most useful for the design team to fine tune the details of a layout
effective if the wizard is well prepared for a variety of events or an interaction. They may exhibit problems in the design that
and can present semiautomated information. The user interacts were not apparent in less precise prototypes. Finally, they may
with the objects on the screen as wizard moves the relevant be used early on in the design process for low precision pro-
materials in direct response to each user action. The other cam- totypes that would be difficult to create offline, such as when
era records the interaction between the user and the simulated dynamic interactions or visualizations are needed.
software system on the screen or monitor, to create either a The techniques presented in this section are sorted by
video brainstorm (for a quick idea) or a fully storyboarded video interactivity. We start with noninteractive simulations (i.e.,
prototype. animations), followed by interactive simulations that provide
Figure 52.9 shows a Wizard-of-Oz simulation with a live video fixed or multiple-paths interactions. We finish with scripting
camera, video projector, whiteboard, overhead projector, and languages that support open interactions.
transparencies. The setup allows two people to experience how
they would communicate via a new interactive communication Noninteractive Simulations, A noninteractive simulation
system. One video camera films the woman at left, who can is a computer-generated animation that represents what a per-
see and talk to the other woman. Her image is projected live son would see of the system if he or she were watching over
onto the left side of the wall. An overhead projector displays the user's shoulder. Noninteractive simulations are usually cre-
hand-drawn transparencies, manipulated by two other people, ated when offline prototypes, including video, fail to capture a
in response to gestures made by the woman at right. The entire particular aspect of the interaction, and it is important to have
interaction is videotaped by a second video camera. a quick prototype to evaluate the idea. It is usually best to start
Combining Wizard-of-Oz and video is a particularly powerful by creating a storyboard to describe the animation, especially if
prototyping technique because it gives the person playing the the developer of the prototype is not a member of the design
user a real sense of what it might actually feel like to interact with team.
the proposed tool, long before it has been implemented. Seeing One of the most widely used tools for noninteractive sim-
a video clip of someone else interacting with a simulated tool is ulations is Macromedia Director. The designer defines graphic
more effective than simply hearing about it, but interacting with objects called sprites and defines paths along which to animate
it directly is more powerful still. Video prototyping may act as them. The succession of events, such as when sprites appear
a form of specification for developers, enabling them to build and disappear, is determined with a time line. Sprites are usually
the precise interface, both visually and interactively, created by created with drawing tools (e.g., Adobe Illustrator or Deneba
the design team. Canvas), painting tools (e.g., Adobe Photoshop), or even
 1018 BEAUDOUIN-LAFON AND MACKAY

which required an order of magnitude more time to implement

than the Photoshop mock-up.

Interactive Simulations. Designers can also use tools such

as Adobe Photoshop to create Wizard-of-Oz simulations. For ex-
ample, the effect of dragging an icon with the mouse can be
obtained by placing the icon of a file in one layer and the icon
of the cursor in another layer and by moving either or both
layers. The visibility of layers, as well as other attributes, can
also create more complex effects. Like Wizard-of-Oz and other
paper prototyping techniques, the behavior of the interface is
generated by the user who is operating the Photoshop interface.
More specialized tools, such as HyperCard and Macromedia
Director, can be used to create simulations that the user can
directly interact with. HyperCard (Goodman, 1987) is one of
the most successful early prototyping tools. It is an authoring
environment based on a stack metaphor: A stack contains a
set of cards that share a background, including fields and but-
FIGURE 52.10. A noninteractive simulation of a desktop inter- tons. Each card can also have its own unique contents, including
face created with Macromedia Flash. The time line (top) dis- fields and buttons (Fig. 52.12). Stacks, cards, fields, and buttons
plays the active sprites and the main window (bottom) shows react to user events (e.g., clicking a button) as well as system
the animation. Reprinted with permission from O. Beaudoux. events (e.g., when a new card is displayed or about to disappear;
Fig. 52.13). HyperCard reacts according to events programmed
scanned images. Director is a powerful tool; experienced de- with a scripting language called Hypertalk. For example, the fol-
velopers can create sophisticated interactive simulations; how- lowing script is assigned to a button, which switches to the next
ever, noninteractive simulations are much faster to create. Other card in the stack whenever the button is clicked. If this button
similar tools exist on the market, including Abvent Katabounga, is included in the stack background, the user will be able to
Adobe AfterEffects, and Macromedia Flash (Fig. 52.10). browse through the entire stack:
Figure 52.11 shows a set of animation movies created by on click
Dave Curbow to explore the notion of accountability in com- goto next card
puter systems (Dourish, 1997). These prototypes explore new end click
ways to inform the user of the progress of a file copy opera-
tion. They were created with Macromind Director by combin- Interfaces can be prototyped quickly with this approach by
ing custom-made sprites with sprites extracted from snapshots drawing different states in successive cards and using buttons
of the Macintosh Finder. The simulation features cursor motion, to switch from one card to the next. Multiple-path interactions
icons being dragged, windows opening and closing, and so on. can be programmed by using several buttons on each card. More
The result is a realistic prototype that shows how the interface open interactions require more advanced use of the scripting
looks and behaves that was created in just a few hours. Note language but are fairly easy to master with a little practice.
that the simulation also features text annotations to explain each Director uses a different metaphor, attaching behaviors to
step, which helps document the prototype. sprites and to frames of the animation. For example, a button
Noninteractive animations can be created with any tool that can be defined by attaching a behavior to the sprite represent-
generates images. For example, many Web designers use Adobe ing that button. When the sprite is clicked, the animation jumps
Photoshop to create simulations of their Web sites. Photoshop to a different sequence. This is usually coupled with a behavior
images are composed of various layers that overlap like trans- attached to the frame containing the button that loops the an-
parencies. The visibility and relative position of each layer can imation on the same frame. As a result, nothing happens until
be controlled independently. Designers can quickly add or the user clicks the button, at which point the animation skips
delete visual elements, simply by changing the characteristics of to a sequence where, for example, a dialogue box opens. The
the relevant layer. This permits quick comparisons of alternative same technique can be used to make the OK and Cancel but-
designs and helps visualize multiple pages that share a common tons of the dialogue box interactive. Typically, the Cancel button
layout or banner. Skilled Photoshop users find this approach would skip to the original frame, whereas the OK button would
much faster than most Web authoring tools. skip to a third sequence. Director comes with a large library of
We used this technique in the CPN2000 project (Mackay, behaviors to describe such interactions so that prototypes can
Ratzer, & Janecek, 2000) to prototype the use of transparency. be created completely interactively. New behaviors can also be
After several prototyping sessions with transparencies and over- defined with a scripting language called Lingo.
head projectors, we moved to the computer to understand Many educational and cultural CD-ROMs are created exclu-
the differences between the physical transparencies and the sively with Director. They often feature original visual displays
transparent effect as it would be rendered on a computer screen. and interaction techniques that would be almost impossible
We later developed an interactive prototype with OpenGL, to create with the traditional user interface development tools
 52. Prototyping Tools and Techniques 1019

FIGURE 52.11. Frames from an animated simulation created with

Macromind Director. Reprinted with permission from D. Curbow.

described in the next section. Designers should consider tools Scripting languages make it easy to quickly develop throw-away
such as HyperCard and Director as user interface builders or prototypes (a few hours to a few days), which may or may not
user interface development environments. In some situations, be used in the final system for performance or other technical
they can even be used for evolutionary prototypes. reasons.
A scripting language is a programming language that is both
Scripting Languages. Scripting languages are the most light weight and easy to learn. Most scripting languages are in-
advanced rapid prototyping tools. As with the interactive- terpreted or semicompiled (i.e., the user does not need to go
simulation tools described above, the distinction between rapid through a compile-link-run cycle each time the script or program
prototyping tools and development tools is not always clear. is changed). Scripting languages can be forbidding: They are not

FIGURE 52.12. A HyperCard card (right) is the combination of a back-

ground (left) and the card's content (middle). Reprinted with permis-
sion from Apple Computer.
 1020 BEAUDOUIN-LAFON AND MACKAY

FIGURE 52.13. The hierarchy of objects in HyperCard deter-

mines the order (from left to right) in which a handler is
looked up for an event. Apple Computer, Inc. Used with FIGURE 52.14. Using the Tk text and canvas widgets to proto-
permission. type a novel search and replace interaction technique. Note.
From "Instrumental interaction: An interaction model for de-
strongly typed, and nonfatal errors are ignored unless explicitly signing post-WIMP user interfaces" by M. Beaudouin-Lafon,
trapped by the programmer. Scripting languages are often used 2000, Proceedings of the Association for Computing Machinery Human
to write small applications for specific purposes and can serve Factors in Computing Systems (CHI'2000), CHI Letters 2(1), 452.
as glue between preexisting applications or software compo- Copyright 2000 by the Association of Computing Machinery.
nents. Tcl (Ousterhout, 1993) was inspired by the syntax of the Reprinted with permission.
Unix shell, it makes it easy to interface existing applications by
that can be dragged will be assigned a tag with three behav-
turning the application programming interface (API) into a set
iors: button-press, mouse-move, and button-up. Because of the
of commands that can be called directly from a Tcl script.
flexibility of the canvas, advanced visualization and interaction
Tcl is particularly suitable for developing user interface pro-
techniques can be implemented more quickly and easily than
totypes (or small- to medium-sized applications) because of its
with other tools. For example, Fig. 52.15 shows a prototype
Tk user interface toolkit. Tk features all the traditional interac-
exploring new ideas to manage overlapping windows on the
tive objects (called widgets) of a user interface toolkit: buttons,
screen (Beaudouin-Lafon, 2001). Windows can be stacked and
menus, scroll bars, lists, dialogue boxes, and so on. A widget is
slightly rotated so that it is easier to recognize them, and they
typically only one line. For example:
can be folded so it is possible to see what is underneath without
having to move the window. Even though the prototype is not
button.dialogbox.ok -text OK -command {destroy.dialogbox} perfect (for example, folding a window that contains text is not
properly supported), it was instrumental in identifying a num-
This command creates a button, called ".dialogbox.ok" with ber of problems with the interaction techniques and finding
the label "OK." It deletes its parent window ".dialogbox" when appropriate solutions through iterative design.
the button is pressed. A traditional programming language and Tcl and Tk can also be used with other programming lan-
toolkit would take 5 to 20 lines to create the same button. guages. For example, Pad++ (Bederson & Meyers, 1998) is im-
Tcl also has two advanced, heavily parameterized widgets: plemented as an extension to Tcl/Tk: the zoomable interface is
the text widget and the canvas widget. The text widget can be implemented in C for performance and accessible from Tk as a
used to prototype text-based interfaces. Any character in the text new widget. This makes it easy to prototype interfaces that use
can react to user input through the use of tags. For example, it zooming. It is also a way to develop evolutionary prototypes:
is possible to turn a string of characters into a hypertext link. In a first prototype is implemented completely in Tcl, then parts of
Beaudouin-Lafon (2000), the text widget was used to prototype it are reimplemented in a compiled language to enhance perfor-
a new method for finding and replacing text. When entering the mance. Ultimately, the complete system may be implemented
search string, all occurrences of the string are highlighted in the in another language, although it is more likely that some parts
text (Fig. 52.14). Once a replace string has been entered, click- will remain in Tcl.
ing an occurrence replaces it (the highlighting changes from Software prototypes can also be used in conjunction with
yellow to red). Clicking a replaced occurrence returns it to its hardware prototypes. Figure 52.16 shows an example of a hard-
original value. This example also uses the canvas widget to cre- ware prototype that captures hand-written text from a paper
ate a custom scroll bar that displays the positions and status of flight strip (using a combination of a graphics tablet and a
the occurrences. custom-designed system for detecting the position of the pa-
The Tk canvas widget is a drawing surface that can contain per strip holder). We used Tk/TCL, in conjunction with C++,
arbitrary objects: lines, rectangles, ovals, polygons, text strings, to present information on a RADAR screen (tied to an existing
and widgets. Tags allow behaviors (i.e., scripts) that are called air traffic control simulator) and to provide feedback on a touch-
when the user acts on these objects. For example, an object sensitive display next to the paper flight strips (Mackay, Fayard,
 52. Prototyping Tools and Techniques 1021

FIGURE 52.15. Using the Tk canvas widget to prototype a novel window

manager. Note. From "Novel interaction techniques for overlapping win-
dows" by M. Beaudouin-Lafon, 2001, Proceedings of the Association for Com-
puling Machinery Symposium on User Interface Software and Technology (UIST
2001). CHI Letters, 3(2), 154. Copyright 2001 by the Association for Com-
puting Machinery. Reprinted with permission.

Frobert, & Medini, 1998). The user can write in the ordinary rapid online prototyping techniques described earlier. Similarly,
way on the paper flight strip, and the system interprets the ges- evolutionary prototypes intended to evolve into the final prod-
tures according to the location of the writing on the strip. For uct require more traditional software development tools. Finally,
example, a change in flight level is automatically sent to another even shipped products are not "final," because subsequent re-
controller for confirmation and a physical tap on the strip's ID leases can be viewed as initial designs for prototyping the next
lights up the corresponding aircraft on the RADAR screen. release.
Development tools for interactive systems have been in use
for more than 20 years and are constantly being refined. Several
ITERATIVE PROTOTYPES studies have shown that the part of the development cost of
an application spent on the user interface is 50% to 80% of the
Prototypes may also be developed with traditional software de- total cost of the project (Myers & Rosson, 1992). The goal of de-
velopment tools. In particular, high-precision prototypes usually velopment tools is to shift this balance by reducing production
require a level of performance that cannot be achieved with the and maintenance costs. Another goal of development tools is to

FIGURE 52.16. Cameleon's augmented stripboard (left) is a working

hardware prototype that identifies and captures hand writing from pa-
per flight strips. Members of the design team test the system (right),
which combines both hardware and software prototypes into a single
interactive simulation.
1022 BEAUDOUIN-LAFON AND MACKAY

anticipate the evolution of the system over successive releases incorporate new interaction techniques, such as bimanual in-
and support iterative design. teraction (Kurtenbach, Fitzmaurice, Baudel, & Buxton, 1997)
Interactive systems are inherently more powerful than non- or zoomable interfaces (Bederson & Hollan, 1994), a user in-
interactive ones (see Wegner, 1997, for a theoretical argument). terface toolkit will hinder rather than help prototype develop-
They do not match the traditional, purely algorithmic, type of ment. Similarly, application frameworks assume a stereotyped
programming: An interactive system must handle user input and application with a menu bar, several toolbars, a set of windows
generate output at almost any time, whereas an algorithmic sys- holding documents, and so on. Such a framework would be
tem reads input at the beginning, processes it, and displays re- inappropriate for developing a game or a multimedia educa-
sults at the end. In addition, interactive systems must process tional CD-ROM that requires a fluid, dynamic, and original user
input and output at rates that are compatible with the human interface.
perception-action loop (i.e., in time frames of 20 to 200 ms). Finally, developers need to truly master these tools, especially
In practice, interactive systems are both reactive and real-time when prototyping in support of a design team. Success depends
systems, two active areas in computer science research. on the programmer's ability to quickly change the details as well
The need to develop interactive systems more efficiently has as the overall structure of the prototype. A developer will be
led to two interrelated streams of work. The first involves cre- more productive when using a familiar tool than if forced to use
ation of software tools, from low-level user interface libraries a more powerful but unknown tool.
and toolkits to high-level user interface development environ-
ments (UIDE). The second addresses software architectures for Graphical Libraries and Window Systems. Graphical li-
interactive systems, or how system functions are mapped onto braries underlie all the other tools presented in this section.
software modules. The rest of this section presents the most Their main purpose is to provide the developer with a hardware-
salient contributions of these two streams of work. independent, and sometimes cross-platform application pro-
gramming interface (API) for drawing on the screen. They can
be separated into two categories: direct drawing and scene-
Software Tools graph based. Direct drawing libraries provide functions to draw
shapes on the screen once their geometry and their graphical
Since the advent of graphical user interfaces in the 1980s, a attributes are specified. This means that every time something
large number of tools have been developed to help with the is to be changed on the display, the programmer has to either
creation of interactive software, most aimed at visual interfaces. redraw the whole screen or figure out exactly which parts have
This section presents a collection of tools, from low-level (i.e., changed. Xlib on Unix systems, Quickdraw on MacOS, Win32
requiring a lot of programming) to high-level tools. GDI on Windows, and OpenGL (Woo, Neider, & Davis, 1997)
The lowest level tools are graphical libraries that provide on all three platforms are all direct drawing libraries. They offer
hardware independence for painting pixels on a screen and the best compromise between performance and flexibility but
handling user input, and window systems that provide an ab- are difficult to program.
straction (the window) to structure the screen into several Scene-graph based libraries explicitly represent the contents
"virtual terminals." User interface toolkits structure an inter- of the display by a structure called a scene graph. It can be a sim-
face as a tree of interactive objects called widgets, whereas user ple list (called display list), a tree (as used by many user interface
interface builders provide an interactive application to create toolkits; see next subsection), or a direct acyclic graph (DAG).
and edit those widget trees. Application frameworks build on Rather than painting on the screen, the developer creates and
toolkits and UI builders to facilitate creation of typical functions updates the scene graph, and the library is responsible for up-
such as cut/copy/paste, undo, help, and interfaces based on dating the screen to reflect the scene graph. Scene graphs are
editing multiple documents in separate windows. Model-based mostly used for three-dimensional graphics (e.g., OpenInven-
tools semiautomatically derive an interface from a specification tor, Strass, 1993), but in recent years they have also been used
of the domain objects and functions to be supported. Finally, for two-dimensional graphics (Beaudouin-Lafon & Lassen, 2000;
user interface development environments or UIDEs provide an Bederson et al., 2000). With the advent of hardware-accelerated
integrated collection of tools for the development of interactive graphics cards, scene-graph based graphics libraries can offer
software. outstanding performance while easing the task of the developer.
Before we describe each of these categories in more detail, Window systems provide an abstraction to allow multiple
it is important to understand how they can be used for pro- client applications to share the same screen. Applications create
totyping. It is not always best to use the highest-level available windows and draw into them. From the application perspective,
tool. High-level tools are most valuable in the long term because windows are independent and behave as separate screens. All
they make it easier to maintain the system, port it to various graphical libraries include or interface with a window system.
platforms, or localize it to different languages. These issues are Window systems also offer a user interface to manipulate win-
irrelevant for vertical and throw-away prototypes, so a high-level dows (move, resize, close, change stacking order, etc.) called
tool may prove less effective than a lower level one. the window manager. The window manager may be a separate
The main disadvantage of higher level tools is that they con- application (as in X-Windows), it may be built into the window
strain or stereotype the types of interfaces they can implement. system (as in Windows), or it may be controlled of each appli-
User interface toolkits usually contain a limited set of "widgets," cation (as in MacOS). Each solution offers a different trade-off
and it is expensive to create new ones. If the design must between flexibility and programming cost.
 52. Prototyping Tools and Techniques 1023

Graphical libraries include or are complemented by an in-

put subsystem. The input subsystem is event driven: Each time
the user interacts with an input device, an event recording the
interaction is added to an input event queue. The input sub-
system API lets the programmer query the input queue and re-
move events from it. This technique is much more flexible than FIGURE 52.17. Callback functions.
polling the input devices repeatedly or waiting until an input
device is activated. To ensure that input events are handled in possible states of a widget. For example, most widgets can be
a timely fashion, the application has to execute an event loop active or inactive, and some can be highlighted. The behavior
that retrieves the first event in the queue and handles it as fast of a widget is usually hardwired and defines its class (menu,
as possible. Every time an event sits in the queue, there is a button, list, etc.). It is sometimes parameterized, however (e.g.,
delay between the user action and the system reaction. As a a list widget may be set to support single or multiple selection).
consequence, the event loop sits at the heart of almost every One limitation of widgets is that their behavior is limited
interactive system. to the widget itself. Interaction techniques that involve multi-
Window systems complement the input subsystem by rout- ple widgets, such as drag-and-drop, cannot be supported by the
ing events to the appropriate client application based on its widgets' behavior alone and require a separate support in the
focus. The focus may be specified explicitly for a device (e.g., user interface toolkit. Some interaction techniques, such as tool-
the keyboard) or implicitly through the cursor position (the glasses or magic lenses (Bier, Stone, Pier, Buxton, & De Rose,
event goes to the window under the cursor). Scene-graph based 1993), break the widget model both with respect to the presen-
libraries usually provide a picking service to identify which ob- tation and the behavior and cannot be supported by traditional
jects in the scene graph are under or in the vicinity of the cursor. toolkits. In general, prototyping new interaction techniques re-
Although graphical libraries and window systems are fairly quires either implementing them within new widget classes,
low level, they must often be used when prototyping novel inter- which is not always possible, or not using a toolkit at all. Imple-
action or visualization techniques. Usually, these prototypes are menting a new widget class is typically more complicated than
developed when performance is key to the success of a design. implementing the new technique outside the toolkit (e.g., with
For example, a zoomable interface that cannot provide contin- a graphical library) and is rarely justified for prototyping. Many
uous zooming at interactive frame rates is unlikely to be usable. toolkits provide a "blank" widget (Canvas in Tk, Drawing Area
The goal of the prototype is then to measure performance to in Motif, JFrame in Java Swing) that can be used by the appli-
validate the feasibility of the design. cation to implement its own presentation and behavior. This is
usually a good alternative to implementing a new widget class,
User Interface Toolkits. User interface toolkits are probably even for production code.
the most widely used tool nowadays to implement applications. The application interface of a widget defines how it commu-
All three major platforms (Unix/Linux, MacOS, and Windows) nicates the results of the user interactions to the rest of the ap-
come with at least one standard user interface toolkit. The main plication. Three main techniques exist. The first and most com-
abstraction provided by a toolkit is the widget, a software ob- mon is called a callback function or callback for short: When
ject that has three facets that closely match the Model-View- the widget is created, the application registers the name of one
Controller (MVC) model described later: a presentation, a be- or more functions with it. When the widget is activated by the
havior, and an application interface. user, it calls the registered functions (Fig. 52.17). The problem
The presentation defines the graphical aspect of the widget. with this approach is that the logic of the application is split
Usually, the presentation can be controlled by the application, among many callback functions (Myers, 1991).
but also externally. For example, under X-Windows, it is possible The second approach is called active variables and consists
to change the appearance of widgets in any application by edit- of associating a widget with a variable of the application pro-
ing a text file specifying the colors, sizes, and labels of buttons, gram (Fig. 52.18). A controller ensures that when the widget
menu entries, and so on. The overall presentation of an interface state changes, the variable is updated with a new value and,
is created by assembling widgets into a tree. Widgets such as but- conversely, when the value of the variable changes, the wid-
tons are the leaves of the tree. Composite widgets constitute the get state reflects the new value. This allows the application to
nodes of the tree: A composite widget contains other widgets change the state of the interface without accessing the wid-
and controls their arrangement. For example, menu widgets in gets directly, therefore decoupling the functional core from the
a menu bar are stacked horizontally, whereas command widgets presentation. In addition, the same active variable can be used
in a menu are stacked vertically. Widgets in a dialogue box are with multiple widgets, providing an easy way to support mul-
laid out at fixed positions or relative to each other so that the tiple views. Finally, it is easier to change the mapping between
layout may be recomputed when the window is resized. Such
constraint-based layout saves time because the interface does
not need to be laid out again when a widget is added or when
its size changes as a result of, for example, changing its label.
The behavior of a widget defines the interaction methods it
supports: a button can be pressed, a scroll bar can be scrolled, a
text field can be edited. The behavior also includes the various
1024 BEAUDOUIN-LAFON AND MACKAY

FIGURE 52.19. Listener objects.

widgets and active variables than it is to change the assignment

of callbacks. This is because active variables are more declara-
tive and callbacks more procedural. Active variables work only
for widgets that represent data (e.g., a list or a text field) but not
FIGURE 52.20. Iterative user interface builder.
for buttons or menus. Therefore, they complement, rather than
replace, callbacks. Few user interface toolkits implement active
variables. Tcl/Tk (Ousterhout, 1994) is a notable exception. User interface builders focus on the presentation of the inter-
The third approach for the application interface is based on face. They also offer some facilities to describe the behavior of
listeners. Rather than registering a callback function with the the interface and to test the interaction. Some systems allow the
widget, the application registers a listener object (Fig. 52.19). interactive specification of common behaviors such as a menu
When the widget is activated, it sends a message to its listener command opening a dialogue box, a button closing a dialogue
describing the change in state. Typically, the listener of a wid- box, a scroll bar controlling a list, or text. The user interface
get would be its model (using the MVC terminology). The first builder can then be switched to a "test" mode in which widgets
advantage of this approach is that it matches true more closely are not passive objects but actually work. This may be enough
the most common architecture models. It is also more true to to test prototypes for simple applications, even though there is
the object-oriented approach that underlies most user interface no functional core nor application data.
toolkits. The second advantage is that it reduces the "spaghetti To create an actual application, the part of the interface gen-
of callbacks" described above: By attaching a single listener to erated by the user interface builder must be assembled with the
several widgets, the code is more centralized. A number of re- missing parts (i.e., the functional core), the application inter-
cent toolkits are based on the listener model, including Java face code that could not be described from within the builder,
Swing (Eckstein, Loy, & Wood, 1998). and the run-time module of the generator. Most generators save
User interface toolkits have been an active area of research the interface into a file that can be loaded at run-time by the
over the past 15 years. Interviews (Linton, Vlissides, & Calder, generator's run-time module (Fig. 52.20). With this method, the
1989) has inspired many modern toolkits and user interface application need only be regenerated when the functional core
builders. A number of toolkits have also been developed for spe- changes, not when the user interface changes. This makes it
cific applications such as groupware (Roseman & Greenberg, easy to test alternative designs or to iteratively create the inter-
1996, 1999) or visualization (Schroeder, Martin, & Lorensen, face: Each time a new version of the interface is created, it can
1997). be readily tested by rerunning the application.
Creating an application or a prototype with a user interface To make it even easier to modify the interface and test the
toolkit requires a solid knowledge of the toolkit and experi- effects with the real functional core, the interface editor can be
ence with programming interactive applications. To control the built into the target application (Fig. 52.21). Changes to the in-
complexity of the interrelations between independent pieces terface can then be made from within the application and tested
of code (creation of widgets, callbacks, global variables, etc.), it without rerunning it. This situation occurs most often with in-
is important to use well-known design patterns. Otherwise the terface builders based on an interpreted language (e.g., Tcl/Tk,
code quickly becomes unmanageable and, in the case of a pro- Visual Basic).
totype, unsuitable for design space exploration. Two categories In either case, a final application can be created by compiling
of tools have been designed to ease the task of developers: user the interface generated by the user interface builder into actual
interface builders and application frameworks. code, linked with the functional core and a minimal run-time

User Interface Builders. A user interface builder allows the

developer of an interactive system to create the presentation of
the user interface (i.e., the tree of widgets) interactively with
a graphical editor. The editor features a palette of widgets that
the user can use to "draw" the interface in the same way as a
graphical editor is used to create diagrams with lines, circles,
and rectangles. The presentation attributes of each widget can
be edited interactively as well as the overall layout. This saves
a lot of time that would otherwise be spent writing and fine-
tuning rather dull code that creates widgets and specifies their
attributes. It also makes it extremely easy to explore and test
design alternatives.
 52. Prototyping Tools and Techniques 1025

supports multiple document windows, multiple views of a doc-

ument, cut/copy/paste, undo, saving documents to files, script-
ing, and more.
With the advent of object-oriented technology, most appli-
cation frameworks are implemented as collections of classes.
Some classes provide services such as help or drag-and-drop
and are used as client classes. Many classes are meant to be de-
rived to add the application functionality through inheritance
rather than by changing the actual code of the framework. This
makes it easy to support successive versions of the framework
and limits the risks of breaking existing code. Some frame-
works are more specialized than MacApp. For example, Unidraw
(Vlissides & Linton, 1990) is a framework for creating graphical
editors in domains such as technical and artistic drawing, music
composition, or circuit design. By addressing a smaller set of
applications, such a framework can provide more support and
FIGURE 52.22. Generation of the final application. significantly reduce implementation time.
Mastering an application framework takes time. It requires
module. In this situation, the interface is not loaded from a file knowledge of the underlying toolkit and the design patterns
but directly created by the compiled code (Fig. 52.22). This used in the framework, and a good understanding of the design
is both faster and eliminates the need for a separate interface philosophy of the framework. A framework is useful because
description file. it provides a number of functions "for free," but at the same
User interface builders are widely used to develop prototypes time it constrains the design space that can be explored. Frame-
as well as final applications. They are easy to use, they make it works can prove effective for prototyping if their limits are well
easy to change the look of the interface, and they hide a lot of understood by the design team.
the complexity of creating user interfaces with toolkits. Despite
their name, however, they do not cover the whole user interface, Model-Based Tools. User interface builders and application
only the presentation. Therefore, they still require a significant frameworks approach the development of interactive applica-
amount of programming, namely, some part of the behavior tions through the presentation side: First the presentation is
and all the application interface. Systems such as NeXT's Inter- built, then behavior (i.e., interaction) is added; finally the in-
face Builder (NeXT, 1991) ease this task by supporting part of terface is connected to the functional core. Model-based tools
the specification of the application objects and their links with take the other approach, starting with the functional core and
the user interface. Still, user interface builders require knowl- domain objects and working their way toward the user inter-
edge of the underlying toolkit and an understanding of their face and the presentation (Szekely, Luo, & Neches, 1992,1993).
limits, especially when prototyping novel visualization and in- The motivation for this approach is that the raison d'etre of a
teraction techniques. user interface is the application data and functions that will be
accessed by the user. Therefore, it is important to start with the
domain objects and related functions and derive the interface
Software Environments from them. The goal of these tools is to provide a semiautomatic
generation of the user interface from the high-level specifica-
Application Frameworks. Application frameworks address tions, including specification of the domain objects and func-
a different problem than user interface builders and are actually tions, specification of user tasks, specification of presentation,
complementary. Many applications have a standard form where and interaction styles.
windows represent documents that can be edited with menu Despite significant efforts, the model-based approach is
commands and tools from palettes. Each document may be still in the realm of research; no commercial tool exists yet.
saved into a disk file; standard functions such as copy/paste, By attempting to define an interface declaratively, model-based
undo, and help are supported. Implementing such stereotyped tools rely on a knowledge base of user interface design to be
applications with a user interface toolkit or builder requires used by the generation tools that transform the specifications
replicating a significant amount of code to implement the into an actual interface. In other words, they attempt to do what
general logic of the application and the basics of the standard designers do when they iteratively and painstakingly create an
functions. interactive system. This approach can probably work for well-
Application frameworks address this issue by providing a defined problems with well-known solutions (i.e., families of
shell that the developer fills with the functional core and the ac- interfaces that address similar problems). For example, it may
tual presentation of the nonstandard parts of the interface. Most be the case that interfaces for management information systems
frameworks have been inspired by MacApp, a framework devel- (MIS) could be created with model-based tools because these
oped in the eighties to develop applications for the Macintosh interfaces are fairly similar and well understood.
(Apple Computer, 1996). Typical base classes of MacApp in- In their current form, model-based tools may be useful to
clude Document, View, Command, and Application. MacApp create early horizontal or task-based prototypes. In particular,
1026 BEAUDOUIN-LAFON AND MACKAY

prototypes are rarely robust or complete, it is often impractical

and sometimes dangerous to evolve them into the final system.
Designers must think carefully about the underlying software
architecture of the prototype, and developers should use
well-documented design patterns to implement them.

Software Architectures
The definition of the software architecture is traditionally done
after the functional specification is written but before coding
starts. The designers design on the structure of the application
and how functions will be implemented by software modules.
The software architecture is the assignment of functions to mod-
ules. Ideally, each function should be implemented by a single
module and modules should have minimal dependencies among
FIGURE 52.23. The Garnet toolkit and tools (Myers et al., them. Poor architectures increase development costs (coding,
1990). testing, and integration), lower maintainability, and reduce per-
formance. An architecture designed to support prototyping and
they can be used to generate a "default" interface that can serve evolution is crucial to ensure that design alternatives can be
as a starting point for iterative design. Future systems may be tested with maximum flexibility and at a reasonable cost.
more flexible and therefore usable for other types of prototypes.
Seeheim and Arch. The first generic architecture for inter-
User Interface Development Environments. Like model- active systems was devised at a workshop in Seeheim (Germany)
based tools, user interface development environments (UIDE) in 1985 and is known as the Seeheim model (Pfaff & ten
attempt to support the development of the whole interactive Hagen, 1985). It separates the interactive application into a user
system. The approach is more pragmatic than the model-based interface and a functional core (then called "application," be-
approach, however. It consists of assembling a number of tools cause the user interface was seen as adding a "coat of paint"
into an environment where different aspects of an interactive on top of an existing application). The user interface is made of
system can be specified and generated separately. three modules: the presentation, the dialogue controller, and the
Garnet (Fig. 52.23) and its successor Amulet (Myers et al., application interface (Fig. 52.25). The presentation deals with
1997) provide a comprehensive set of tools, including a tradi- capturing user's input at a low level (often called lexical level,
tional user interface builder, a semiautomatic tool for generating similar to the lexical, syntactic, and semantic levels of a com-
dialogue boxes, a user interface builder based on a demonstra- piler). The presentation is also responsible for generating output
tion approach, and so on. One particular tool, Silk, is aimed to the user, usually as a visual display. The dialogue controller
explicitly at prototyping user interfaces. assembles the user input into commands (syntactic level), pro-
Silk (Landay & Myers, 2001) is a tool aimed at the early stages vides some immediate feedback for the action being carried out,
of design, when interfaces are sketched rather than prototyped such as an elastic rubber line, and detects errors. Finally, the ap-
in software. Using Silk, a user can sketch a user interface di- plication interface interprets the commands into calls to the
rectly on the screen (Fig. 52.24). Using gesture recognition, Silk functional core (semantic level). It also interprets the results of
interprets the marks as widgets, annotations, and so on. Even in these calls and turns them into output to be presented to the
its sketched form, the user interface is functional; for example, user.
buttons can be pressed and tools can be selected in a toolbar. All architecture models for interactive systems are based on
The sketch can also be turned into an actual interface (e.g., using the Seeheim model. They all recognize that there is a part of the
the Motif toolkit). Finally, storyboards can be created to describe system devoted to capturing user actions and presenting output
and test sequences of interactions. Silk therefore combines some (the presentation) and another part devoted to the functional
aspects of offline and online prototyping techniques, trying to core (the computational part of the application). In between
achieve the best of both worlds. This illustrates a current trend are one or more modules that transform user actions into func-
in research where online tools attempt to support not only the tional calls and application data (including results from func-
development of the final system, but the whole design process. tional calls) into user output.
A modern version of the Seeheim model is the Arch model
(The UIMS Workshop Tool Developers, 1992). The Arch model
EVOLUTIONARY PROTOTYPES is made of five components (Fig. 52.26). The interface toolkit
component is a preexisting library that provides low-level ser-
Evolutionary prototypes are a special case of iterative proto- vices such as buttons and menus. The presentation component
types, and are intended to evolve into the final system. provides a level of abstraction over the user interface toolkit.
Methodologies such as Extreme Programming (Beck, 2000) Typically, it implements interaction and visualization techniques
consist mostly of developing evolutionary prototypes. Because that are not already supported by the interface toolkit. It may
 52. Prototyping Tools and Techniques 1027

FIGURE 52.24. A sketch created with Silk (top left) and its automatic
transformation into a Motif user interface (top right). A storyboard
(bottom) used to test sequences of interactions, here a button that ro-
tates an object. Reprinted with permission from J. Landay.

also provide platform independence by supporting different applications as well as during the life of the software. For ex-
toolkits. The functional core component implements the func- ample, the presentation component may be almost empty if the
tionality of the system. In some cases, it already exists and can- interface toolkit provides all the necessary services and be later
not be changed. The domain adapter component provides ad- expanded to support specific interaction or visualization tech-
ditional services to the dialogue component that are not in the niques or multiple platforms. Similarly, early prototypes may
functional core. For example, if the functional core is a Unix-like have a large domain adapter simulating the functional core of
file system and the user interface is a iconic interface similar to the final system or interfacing to an early version of the func-
the Macintosh Finder, the domain adapter may provide the dia- tional core; the domain adapter may shrink to almost nothing
logue controller with a notification service so the presentation when the final system is put together.
can be updated whenever a file is changed. Finally, the dialogue The separation that Seeheim, Arch, and most other architec-
component is the keystone of the arch. It handles the translation ture models make between user interface and functional core
between the user interface world and the domain world. is a good, pragmatic approach but it may cause problems in
The Arch model is also known as the Slinky model be- some cases. A typical problem is a performance penalty when
cause the relative sizes of the components may vary across the interface components (left leg) have to query the domain
components (right leg) during an interaction such as drag-and-
drop. For example, when dragging the icon of a file over the
desktop, icons of folders and applications that can receive the
file should highlight. Determining which icons to highlight is a
semantic operation that depends on file types and other infor-
mation and must therefore be carried out by the functional core
or domain adapter. If drag-and-drop is implemented in the user
FIGURE 52.25. Seeheim model (Pfaff & ten Hagen, 1985). interface toolkit, this means that each time the cursor goes over
1028 BEAUDOUIN-LAFON AND MACKAY

FIGURE 52.26. The Arch Model (The UIMS Workshop Developers Tool,
1992).

a new icon, up to four modules have to be traversed once by tree. A PAC agent has three facets: The presentation takes care
the query and once by the reply to find out whether or not to of capturing user input and generating output; the abstraction
highlight the icon. This is both complicated and slow. A solution holds the application data, like a Model in MVC; the control man-
to this problem, called semantic delegation, involves shifting ages the communication between the abstraction and presenta-
in the architecture some functions such as matching files for tion facets of the agent, and with subagents and super-agents
drag-and-drop from the domain leg into the dialogue or presen- in the tree. Like MVC, multiple views are easily supported.
tation component. This may solve the efficiency problem, but at Unlike MVC, PAC is an abstract model; there is no reference
the cost of an added complexity especially when maintaining or implementation.
evolving the system, because it creates dependencies between A variant of MVC, called MVP (model-view-presenter), is
modules that should otherwise be independent. close to PAC and is used in ObjectArts' Dolphin Smalltalk. Other
architecture models have been created for specific purposes
Model-View-Controller and Presentation-Abstraction- such as groupware (Dewan, 1999) or graphical applications
Controller Models. Architecture models such as Seeheim (Fekete & Beaudouin-Lafon, 1996).
and Arch are abstract models and are thus rather imprecise.
They deal with categories of modules such as presentation or
dialogue, when in an actual architecture several modules will Design Patterns
deal with presentation and several others with dialogue.
The model-view-controller or MVC model (Krasner & Pope, Architecture models such as Arch or PAC only address the over-
1988) is much more concrete. MVC was created for the im- all design of interactive software. PAC is more fine-grained than
plementation of the Smalltalk-80 environment (Goldberg & Arch, and MVC is more concrete because it is based on an imple-
Robson, 1983) and is implemented as a set of Smalltalk classes. mentation. Still, a user interface developer has to address many
The model describes the interface of an application as a collec- issues to turn an architecture into a working system.
tion of triplets of objects. Each triplet contains a model, a view, Design patterns have emerged in recent years as a way to cap-
and a controller. A model represents information that needs to ture effective solutions to recurrent software design problems.
be represented and interacted with. It is controlled by applica- In their book, Gamma, Helm, Johnson, and Vlissides (1995) pre-
tions objects. A view displays the information in a model in a sented 23 patterns. Many of these patterns come from interac-
certain way. A controller interprets user input on the view and tive software, and most of them can be applied to the design of
transforms it into changes in the model. When a model changes, interactive systems. It is beyond the scope of this chapter to de-
it notifies its view so the display can be updated. scribe these patterns in detail. Nonetheless, it is interesting that
Views and controllers are tightly coupled and sometimes im- most patterns for interactive systems are behavioral patterns,
plemented as a single object. A model is abstract when it has no that is, patterns that describe how to implement the control
view and no controller. It is noninteractive if it has a view but no structure of the system.
controller. The MVC triplets are usually composed into a tree. Indeed, there is a battle for control in interactive software.
For example, an abstract model represents the whole interface, In traditional, algorithmic software, the algorithm is in control
it has several components that are themselves models, such as and decides when to read input and write output. In interactive
the menu bar and the document windows, all the way down software, the user interface needs to be in control because user
to individual interface elements such as buttons and scrollbars. input should drive the system's reactions. Unfortunately, more
MVC supports multiple views fairly easily. The views share a sin- often than not, the functional core also needs to be in control.
gle model; when a controller modifies the model, all the views This is especially common when creating user interfaces for
are notified and update their presentation. legacy applications. In the Seeheim and Arch models, it is often
The presentation-abstraction-control or PAC model (Coutaz, believed that control is located in the dialogue controller when
1987) is close to MVC. Like MVC, an architecture based on PAC in fact these architecture models do not explicitly address the
is made of a set of objects, called PAC agents, organized in a issue of control. In MVC, the three basic classesModel, View,
 52. Prototyping Tools and Techniques 1029

and Controllerimplement a sophisticated protocol to ensure highlight the areas that must be refined or require additional
that user input is taken into account in a timely manner and ideas.
that changes to a model are properly reflected in the view (or We begin by denning prototypes and then discuss them as
views). Some authors actually describe MVC as a design pattern, design artifacts. We introduce four dimensions by which they
not an architecture. In fact, it is both: The inner workings of the can be analyzed: representation, precision, interactivity, and
three basic classes is a pattern, but the decomposition of the evolution. We then discuss the role of prototyping within the
application into a set of MVC triplets is an architectural issue. design process and explain the concepts of creating, exploring,
It is now widely accepted that interactive software is event- and modifying a design space. We briefly describe techniques
driven: The execution is driven by the user's actions, leading for generating new ideas, for expanding the design space, and
to a control localized in the user interface components. Design for choosing among design alternatives to contract the design
patterns such as Command, Chain of Responsibility, Mediator, space.
and Observer (Gamma et al., 1995) are especially useful to im- We describe a variety of rapid prototyping techniques for
plement the transformation of low-level user event into higher exploring ideas quickly and inexpensively in the early stages
level commands, to find out which object in the architecture of design, including offline techniques (from paper-and-pencil
responds to the command, and to propagate the changes pro- to video) and online techniques (from fixed to interactive
duced by a command from internal objects of the functional simulations). We then describe iterative prototyping techniques
core to user interface objects. for working out the details of the online interaction, includ-
Using design patterns to implement an interactive system ing software development tools and software environments. We
not only saves time, it also makes the system more open to conclude with evolutionary prototyping techniques, which are
changes and easier to maintain. Therefore, software prototypes designed to evolve into the final software system, including a
should be implemented by experienced developers who know discussion of the underlying software architectures, design pat-
their pattern language and who understand the need for flexi- terns, and extreme programming.
bility and evolution. This chapter has focused mostly on graphical user inter-
faces that run on traditional workstations. Such applications are
dominant today, but this is changing as new devices are be-
SUMMARY ing introduced, from cellular phones and personal digital assi-
tants to wall-sized displays. New interaction styles are emerging,
Prototyping is an essential component of interactive system such as augmented reality, mixed reality, and ubiquitous com-
design. Prototypes may take many forms, from rough sketches puting. Designing new interactive devices and the interactive
to detailed working prototypes. They provide concrete repre- software that runs on them is becoming ever more challeng-
sentations of design ideas and give designers, users, developers, ing: Whether aimed at a wide audience or a small number of
and managers an early glimpse into how the new system will specialists, the hardware and software systems must be adapted
look and feel. Prototypes increase creativity, allow early evalu- to their contexts of use. The methods, tools, and techniques
ation of design ideas, help designers think through and solve presented in this chapter can easily be applied to these new
design problems, and support communication within multidis- applications.
ciplinary design teams. We view design as an active process of working with a design
Prototypes, because they are concrete and not abstract, pro- space, expanding it by generating new ideas and contracting it
vide a rich medium for exploring a design space. They suggest as design choices are made. Prototypes are flexible tools that
alternate design paths and reveal important details about partic- help designers envision this design space, reflect on it, and test
ular design decisions. They force designers to be creative and their design decisions. Prototypes are diverse and can fit within
to articulate their design decisions. Prototypes embody design any part of the design process, from the earliest ideas to the final
ideas and encourage designers to confront their differences of details of the design. Perhaps most important, prototypes pro-
opinion. The precise aspects of a prototype offer specific design vide one of the most effective means for designers to commu-
solutions: Designers can then decide to generate and compare nicate with each other, as well as with users, developers, and
alternatives. The imprecise or incomplete aspects of a prototype managers, throughout the design process.

References
Apple Computer. (1996). Programmer's guide to MacApp. Cupertino, Beaudouin-Lafon, M., & Lassen, M. (2000). The architecture
CA: Apple (collective). and implementation of a post-WIMP graphical application.
Beaudouin-Lafon, M. (2000). Instrumental interaction: An interaction Proceedings of ACM Symposium on User Interface Soft-
model for designing post-WIMP user interfaces. Proceedings of the ware and Technology (UIST 2000). CHI Letters, 2(2), 181-
ACM Human Factors in Computing Systems (CHI '2000), CHI 190.
Letters, 2(1), 446-453. New York: ACM Press. Beaudouin-Lafon, M., & Mackay, W. (2000, May). Reification, polymor-
Beaudouin-Lafon, M. (2001). Novel interaction techniques for overlap- phism and reuse: Three principles for designing visual interfaces.
ping windows. Proceedings of ACM Symposium on User Interface Proceedings of the Conference on Advanced Visual Interfaces (AVI
Software and Technology (UIST 2001). CHI Letters, 3(2), 153-156. 2000) (pp. 102-109). Palermo, Italy.
1030 BEAUDOUIN-LAFON AND MACKAY

Beck, K. (2000). Extreme programming explained. New York: Addison- Goodman, D. (1987). The complete HyperCard handbook. New York:
Wesley. Bantam Books.
Bederson, B., & Hollan, J. (1994). Pad++: A zooming graphical inter- Good, M., Whiteside, J., Wixon, D., & Jones, S. (1984, October). Building
face for exploring alternate interface physics. Proceedings of ACM a user-derived interface. Communications of the ACM, 27(10),
Symposium on User Interface Software and Technology (UIST '94) 1032-1043.
(pp. 17-26). New York: ACM Press. Greenbaum, J., & Kyng, M. (Eds.). (1991). Design at work: Coopera-
Bederson, B., & Meyer, J. (1998). Implementing a zooming interface: tive design of computer systems. Hillsdale, NJ: Lawrence Erlbaum
Experience Building Pad++. Software Practice and Experience, Associates.
28(10), 1101-1135. Houde, S., & Hill, C. (1997). What do prototypes prototype? In Hand-
Bederson, B. B., Meyer, J., & Good, L. (2000). Jazz: An extensible book of human computer interaction (2nd ed. rev, pp. 367-381).
zoomable user interface graphics toolkit in Java. Proceedings of ACM Amsterdam: North-Holland.
Symposium on User Interface Software and Technology (UIST Kelley, J. F. (1983). An empirical methodology for writing user-friendly
2000). CHI Letters, 2(2), 171-180. natural language computer applications. In Proceedings of CHI '83
Bier, E., Stone, M., Pier, K., Buxton, W., & De Rose, T. (1993). Tool- Conference on Human Factors in Computing Systems. New York:
glass and magic lenses: The see-through interface. Proceedings ACM ACM Press.
SIGGRAPH '93 (pp. 73-80). New York: ACM Press. Krasner, E. G., & Pope, S. T. (1988, August/September). A cookbook
Boehm, B. (1988). A spiral model of software development and enhance- for using the model-view-controller user interface paradigm
ment. IEEE Computer, 2/(5), 61-72. in Smalltalk-80. Journal of Object-Oriented Programming,
B0dker, S., Christiansen, E., & Thuring, M. (1995). A conceptual tool- 27-49.
box for designing CSCW applications. Proceedings of the Interna- Kurtenbach, G., Fitzmaurice, G., Baudel, T, & Buxton, W. (1997). The
tional Workshop on the Design of Cooperative Systems (COOP '95) design of a GUI paradigm based on tablets, two-hands, and trans-
(pp. 266-284). parency. Proceedings of ACM Human Factors in Computing Sys-
B0dker, S., Ehn, P., Knudsen, J., Kyng, M., & Madsen, K. (1988). tems (CHI '97) (pp. 35-42). New York: ACM Press.
Computer support for cooperative design. In Proceedings of the Landay, J., & Myers, B. A. (2001). Sketching interfaces: Toward more
CSCW'88 ACM Conference on Computer-Supported Cooperative human interface design. IEEE Computer, 34, 56-64.
Work (pp. 377-393). Portland, OR: ACM Press. Linton, M. A., Vlissides, J. M., & Calder, P. R. (1989). Composing user
Chapanis, A. (1982). Man/computer research at Johns Hopkins. In R. A. interfaces with Interviews. IEEE Computer, 22, 8-22.
Kasschau, R. Lachman, & K. R. Laughery (Eds.), Information Tech- Mackay, W E. (1988). Video prototyping: A technique for developing hy-
nology and Psychology: Prospects for the Future (pp. 238-249). permedia systems. Demonstration, CHI '88, Conference on Human
New York: Praeger. Factors in Computing Systems. Retrieved from http://www.lri.fr/-
Collaros, P. A., & Anderson, L. R. (1969). Effect of perceived expert- mackay/publications.html
ness upon creativity of members of brainstorming groups. Journal Mackay, W E., & Pagani, D. (1994). Video Mosaic: Laying out time in a
of Applied Psychology, 53, 159-163. physical space. Proceedings of ACM Multimedia '94 (pp. 165-172).
Coutaz, J. (1987). PAC, an object oriented model for dialog design. In New York: ACM Press.
H.J. Bullinger & B. Shackel (Eds.), Proceedings of INTERACT '87 Mackay, W E., & Fayard, A.-L. (1997). HCI, natural science and design: A
(pp. 431-436). Amsterdam: Elsevier Science. framework for triangulation across disciplines. Proceedings of ACM
de Vreede, G.-J., Briggs, R. O., van Duin, R., & Enserink, B. (2000). DIS '97, Designing Interactive Systems (pp. 223-234). New York:
Athletics in electronic brainstorming: Asynchronous brainstorming ACM Press.
in very large groups. Proceedings of HICSS-33. Mackay, W, Fayard, A.-L., Frobert, L., & Medini, L. (1998). Reinventing
Dewan, P (1999). Architectures for collaborative applications. In the familiar: Exploring an augmented reality design space for air
M. Beaudouin-Lafon (Ed.), Computer-supported co-operative work traffic control. Proceedings of ACM Conference on Human Factors
(Trends in Software Series, pp. 169-193). New York: John in Computing Systems (CHI '98) (pp. 558-565). New York: ACM
Wiley. Press.
Diehl, M., & Strobe, W. (1987). Productivity loss in brainstorming Mackay, W. E. (2000). Video techniques for participatory design:
groups: Toward the solution of a riddle. Journal of Personality and Observation, brainstorming & prototyping. Tutorial Notes, CHI
Social Psychology, 53, 497-509. 2000, Human Factors in Computing Systems. Retrieved from
Dykstra-Erickson, E., Mackay, W. E., & Arnowitz, J. (2001, March). http://www.lri.fr/~mackay/publications.html
Trialogue on Design (of). ACM/Interactions, 8(2), 109-117. Mackay, W, Ratzer, A., & Janecek, P. (2000). Video artifacts for design:
Dourish, P. (1997). Accounting for system behaviour: Representation, Bridging the gap between abstraction and detail. Proceedings ACM
reflection and resourceful action. In M. Kyng & L. Mathiassen (Eds.), Conference on Designing Interactive Systems (DIS 2000) (pp. 72-
Computers and design in context (pp. 145-170). Cambridge, MA: 82). New York: ACM Press.
MIT Press. Muller, M. (1991). PICTIVE: An exploration in participatory de-
Eckstein, R., Loy M., & Wood, D. (1998). Java Swing. Cambridge, MA: sign. Proceedings of ACM Conference on Human Factors in
O'Reilly. Computing Systems (CHI '91) (pp. 225-231). New York: ACM
Fekete, J.-D., & Beaudouin-Lafon, M. (1996). Using the multi-layer model Press.
for building interactive graphical applications. In Proceedings of Myers, B. A., Giuse, D. A., Dannenberg, R. B., Vander Zander, B., Kosbie,
ACM Symposium on User Interface Software and Technology (UIST D. S., Pervin, E., Mickish, A., & Marchal, P. (1990). Garnet: Com-
'96) (pp. 109-118). New York: ACM Press. prehensive support for graphical, highly-interactive user interfaces.
Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design IEEE Computer, 23(11), 71-85.
patterns, elements of reusable object-oriented software. Reading, Myers, B. A. (1991). Separating application code from toolkits: Elimi-
MA: Addison Wesley. nating the spaghetti of call-backs. Proceedings of ACM SIGGRAPH
Goldberg, A., & Robson, D. (1983). Smalltalk80: The language and Symposium on User Interface Software and Technology (UIST '91)
its implementation. Reading, MA: Addison Wesley. (pp. 211-220). New York: ACM Press.
 52. Prototyping Tools and Techniques 1031

Myers, B. A., & Rosson, M. B. (1992). Survey on user interface pro- co-operative work (Trends in software series, pp. 135-168). New
gramming. Proceedings of the ACM Conference on Human Factors York: John Wiley.
in Computing Systems (CHI '92) (pp. 195-202). New York: ACM Schroeder, W., Martin, K., & Lorensen, B. (1997). The visualization
Press. toolkit. New York: Prentice Hall.
Myers, B. A., McDaniel, R. G., Miller, R. C., Ferrency, A. S., Faulring, A., Strass, P. (1993). IRIS Inventor, a 3D graphics toolkit. Proceedings ACM
Kyle, B. D., Mickish, A., Klimotivtski, A., & Doane, P. (1997). The Conference on Object-Oriented Programming, Systems, Languages
Amulet environment. IEEE Transactions on Software Engineering, and Applications (OOPSLA '93) (pp. 192-200). New York: ACM
23(6), 347-365. Press.
NeXT Corporation. (1991). NeXT Interface Builder reference manual. Szekely, P., Luo, P., & Neches, R. (1992). Facilitating the exploration of
Redwood City, CA. interface design alternatives: The HUMANOID. Proceedings of ACM
Norman, D. A., & Draper, S. W. (Eds.). (1986). User centered system Conference on Human Factors in Computing Systems (CHI '92)
design. Hillsdale, NJ: Lawrence Erlbaum Associates. (pp. 507-515). New York: ACM Press.
Osborn, A. (1957). Applied imagination: Principles and procedures of Szekely, P., Luo, P., & Neches, R. (1993). Beyond interface builders:
creative thinking (rev. ed.). New York: Scribner's. Model-based interface tools. Proceedings of ACM/IFIP Confer-
Ousterhout, J. K. (1994). Tcl and the Tk Toolkit. Reading, MA: Addison ence on Human Factors in Computing Systems (INTERCHI '93)
Wesley. (pp. 383-390). New York: ACM Press.
Perkins, R., Keller, D. S., & Ludolph, F. (1997). Inventing the Lisa User The UIMS Workshop Tool Developers. (1992). A metamodel for the run-
Interface. ACM Interactions, 4(1), 40-53. time architecture of an interactive system. SIGCHI Bulletin, 24(1),
Pfaff, G. P., & ten Hagen, P. J. W. (Eds.). (1985). User interface manage- 32-37.
ment systems. Berlin: Springer. Vlissides, J. M., & Linton, M. A. (1990). Unidraw: A framework for build-
Raskin, J. (2000). The humane interface. New York: Addison Wesley. ing domain-specific graphical editors. ACM Transactions on Infor-
Roseman, M., & Greenberg, S. (1996). Building real-time groupware with mation Systems, 8(3), 237-268.
GroupKit, a groupware toolkit. ACM Transactions on Computer- Wegner, P. (1997). Why interaction is more powerful than algorithms.
Human Interaction, 3(1), 66-106. Communications of the ACM, 40(5), 80-91.
Roseman, M., & Greenberg, S. (1999). Groupware toolkits for syn- Woo, M., Neider, J., & Davis, T. (1997). OpenGL programming guide.
chronous work. In M. Beaudouin-Lafon (Ed.). Computer-supported Reading, MA: Addison-Wesley.