Firelily Designs - Low Tech Prototyping

by Diane Wilson, Thyra Rauch, and Joeann Paige

The following article is drawn from a number of sources at the ACM CHI '92 conference. It is the second in a series. In particular, the authors are indebted to Michael Muller, Danny Wildman, and Ellen White of Bellcore, for their design and presentation of the techniques described in this article.

Imagine yourself in this scene:

You are sitting in a crowded theater. The room is buzzing with talk and laughter, but now the lights dim, and the talk dies away to whispers.

A young man walks onto the stage, holding a banner above his head. As the spotlight plays across the banner, you read the words, "File. Edit. View. Options. Windows." From the audience, the person next to you shouts, "File." A woman holding an arrow enters the stage; she points the arrow at the word "File." Another man walks onto the stage, holding a poster with a list of words: "New. Open. Close. Save. Save as. Print. Exit." Another voice shouts, "Open," and the woman with the arrow points to the word "File." Then a second woman walks onto the stage, holding a large board which shows a directory path, a list of files, and several pushbuttons. Catching the idea, you call out, "Scroll down!"

A nightmare? Has Franz Kafka taken up programming? No. This is interface theater, a low technology tool for user interface evaluation.

Low-technology prototyping is an emerging area in human- computer interface design. It may seem odd to consider low technology alternatives when one side of the human-computer interface equation is one of our highest technological achievements, one capable of simulating its own interface. It may seem like a step backwards from CASE tools, frameworks, and other high-technology design tools, but it's not, for the simple reason that the human brain is also capable of sophisticated simulation. Not only that, but the human brain can visualize complex structures, build on vaguely understood principles, and draw comparisons between things that have not previously been compared.

In short, the human brain is a much better computer than the computer, particularly when it comes to creating new images, understanding relationships, and making inferences. How can we set this wondrous machine to work? By freeing it from its biggest restriction--the electronic computer.

OK, that's an extremist, inflammatory, Luddite statement. High-technology prototyping tools do have their place, later in the design cycle. But low technology tools offer these advantages:

Because no specialized skills are required, anyone can participate. Psychologists, technical writers, testers, graphic artists, market specialists, and prospective end users all can make valuable contributions to product design, even though they may not all have programming or design skills at the beginning of the design cycle.
Because the prototyping tools are as simple as paper, crayons, and scissors, designers can build prototypes quickly.
Because animation is done manually, design teams can test, evaluate, and modify prototypes as they build them, during design meetings.
Because the granularity of detail is low, low-technology prototypes force designers and evaluators to look at the overall picture. Prototyping becomes an exploration of the problem space, rather than a demonstration of a proposed solution.
Because they focus on interactions between people, low-technology prototyping tools encourage group interaction and synergy.

If this low-technology prototyping stuff is so good, then just what is it? Here are two approaches.

PICTIVE

PICTIVE--Plastic Interface for Collaborative Technology Initiatives through Video Exploration--is a participative design approach developed by Michael J. Muller and others at Bellcore. Its goals are:

To empower users to act as full participants in the design of systems that will have impact on their jobs and their work- lives.
To improve knowledge acquisition for design, and the quality of the resulting system, by involving the people with job expertise (the people who do the job) in the design process.
To improve the flow of the software engineering process by bringing representatives from major components of that process into the design phase as co-owners of the design.

The term plastic applies in significant ways. First, many of the physical tools of PICTIVE are made of plastic. Second, participants begin to see the interface concepts as being malleable; they can try many variations quickly and easily. Finally, the results are so obviously artificial that they cannot be confused with a working system. This last point aids both users and developers by promoting a shared understanding of development problems and schedules.

The PICTIVE technique provides a dynamic paper and pencil mock-up with the intent that it will be extensively modified in real- time by the users. Because it uses ordinary office materials, it offers an "equal opportunity" design environment to both users and developers. It is a tool for creation and design of interfaces, rather than for evaluation.

PICTIVE also provides a novel approach to recording the design. Each design session is videotaped, which provides a dynamic presentation of the design, a conversational rationale for that design and for the decisions underlying the design, and a means for communicating concretely the different views of different participants.

Other than the video equipment, PICTIVE requires little set-up: pens, high-lighters, papers, Post-It^(TM) notes of various sizes, stickers and labels, and paper clips--all in bright colors. In addition, participants will bring materials specifically prepared for the PICTIVE session.

Developers provide a set of design objects, both generic (command lines, query fields, menu and dialog box templates, and so on) and specific objects which are relevant to the design. It is important for developers not to put a great deal of effort into these preparations; nor should they develop any sort of ego attachment to these design objects. The intent is to provide a starter set of ideas for the components of the design; these will change rapidly as the PICTIVE session progresses.

Prospective users of the product bring a thorough understanding of their jobs, and they must be prepared to walk through task scenarios. They are the experts in the content of the job; this preparation is vital.

All participants need to approach PICTIVE with certain attitudes:

Each participant is an expert in one aspect of the problem, and a novice in others. Each person is there to learn from other experts. The experts share their knowledge, but each person must be aware of the limits of their knowledge and expertise, and know when to listen to others.
Each participant must be prepared to change any preconceived ideas about the problem.
Although critical examination of ideas is necessary to evaluate the evolving design, critical expression can be deadly. Each participant must respect the knowledge of others, and respect their lack of knowledge as well--no one has the time, talent, or interest to be an expert in all the required subjects.

The PICTIVE session proceeds through the mutual education in one another's perspectives. Each participant contributes his or her expertise to the shared problem. The resulting design should not be "driven" by any single participant, as the objective is to synthesize a solution based on all participants' knowledge and views.

Early assessments of PICTIVE bring out the following points:

It is most appropriate when there is a well-defined set of users, who understand the problem to be solved. It may be less successful with leading-edge technologies until the technology has evolved to the point of application to a practical problem.
Users have been overwhelmingly positive about the process. Software developers have also rated the technique highly, both in classroom and product development environments.
The atmosphere of a PICTIVE session contributes to its popularity and its success. It is deliberately informal, allowing people to interact with the design and with each other. The absence of high technology, abstractions, and software development jargon puts all participants on an equal footing. This atmosphere is not like analysis or engineering or artistry; it is mid-way between work and play, in which people draw pictures, cut out shapes, and design new components on an experimental, exploratory basis. People appear to have an enjoyable time with the apparatus and with each other.
PICTIVE is strongly visual, which enhances communication of the design and ideas about the design. These visual aspects are "non-professional" in that they rely on informal expression, rather than on visual skills, to communicate.
The videotape provides a social record of the design process. Because the camera is out in the open, and not under control of any one participant, it also helps promote equality among all members of the group.
It is essential for key developers to participate in PICTIVE sessions. Participation is necessary for understanding, and the developers above all must understand the design. Developer participation also helps limit the design to features that are technologically feasible, and ensures that other participants are aware of the technological possibilities.
End user participants must be true end users. Domain experts and managers cannot provide the necessary mix of experience, needs, and expectations.

Interface Theater

Interface Theater is an experimental technique designed to solve recurring problems of scale, where a large number of individuals share a stake in a design, and designers want to use a participatory process of interface design and review. Other processes have not met this goal:

Document dissemination and review often fails, because these documents are notoriously poor communication tools, because review and preparation require excessive time commitments, and because it is difficult to integrate review comments of up to 200 people.
Design walkthroughs solve most of the problems of document reviews, but tend to be formal, which discourages questions and alternatives--leaving the design burden on the implementors. Walkthroughs are also poor at communicating pictures and actions, particularly given the highly interactive nature of windowed interfaces.
PICTIVE addresses all of the above concerns, but it is designed for small groups only.
Computer-based prototypes provide concrete visualization and full interaction, but they have their own problems when it comes to review:
- Even with good tools, prototyping is expensive, time- consuming, and requires extensive skills. If a review is to present or consider alternatives, then multiple prototypes must be built, prior to the review.
- Rapid prototyping is still not instantaneous prototyping. It is often not possible or not practical to revise design during a review, nor would most designers be comfortable attempting to prototype during a review.
- Presenting a prototype for review is not easy. Projection devices are expensive and can be temperamental. Arranging for access on individual machines requires inordinate effort and can also be expensive. Videotape often results in poor quality presentation and prevents interaction.

Given the many problems of these alternatives, the task is to find a review technique that is efficient, effective, provides visual clarity and concreteness, and provides an informal, egalitarian environment that promotes discussion of design alternatives. This open discussion must include feedback, design alternatives, and the freedom to explore new ideas on the spot and incorporate them into the design.

Interface Theater attempts nothing less than the simultaneous solution to all these issues. It is a role-playing exercise in which designers play the part of various elements of the interface, and the audience plays the role of the user. Each "actor" performs several roles:

A visible portion of the user interface.
A software object that communicates with the user or with other visible and invisible software and hardware objects.
A person who collaborates with other roles, persons, or objects.
An "audience-centered" listener who asks for advice from the audience of users and who follows that advice during iterative performances.

Sample Interface Theater Elements
Specialized Dialog Box
Generic Dialog Box

The cast is not necessarily restricted to these roles, but this list will be sufficient as an example, and as a complete list for many interface designs.

Marty the Menubar manages the menubar and pull- down menus. Marty holds the menubar, and presents menus as needed. The menus can be hand-lettered on posterboard.
Kim the Cursor serves as the user's input focus. (Kerry the Keyboard may also be a necessary role in many designs.) Kim needs a set of large cursor objects (pointers, pencils, and so forth) that match those needed for the design.
Hani the Helper is the help subsystem. Hani carries a large Help Window, with a head-sized hole through which Hani's face and voice present help and messages.
Dana the Dialog Box manages all dialog box interactions with the "user" (the audience).
Pat the Pixelmaster takes care of updating the display, highlighting, and so on. Pat (and the other actors) must ensure that all text and graphics are large enough for the audience to see and understand.
Audie the Audience Agent obtains audience consensus about what to do at each stage of the operation of the user interface, and tells Kim the Cursor where to go and what to click.
Chris the Critic facilitates audience critique, tells the other roles how they ought to behave, and directs the review when it becomes necessary to "freeze frames" to stop the action, go back, and replay the script with changes.
Ariel the Spirit of the Interface hovers near the stage and discusses each proposed change from the points of view of consistency, integrity, and technological feasibility.

Scripts are also necessary; they might take one or more of these forms:

A procedural, narrative script reads like the script of a theatrical play, with openings for audience participation. This kind of script is useful for demonstration, and also for tasks where the user's actions are well-understood and predictable.
A non-procedural, or object-oriented, script provides for open interaction with the audience, in the same way that a graphical user interface provides for interaction with a user. Each interface object (role) has a set of cues that it can respond to, and a script segment that prescribes the appropriate behavior in response to each cue. These behaviors can be:
- Visible behavior in the interface
- Interactions with the user
- Cues or messages to other visible objects
- Interactions with invisible objects or background processes.
Off-stage roles and actors might be necessary to complete the "implementation" of a prototype.
When it becomes necessary to explore new ideas, the cast will have to be prepared to work without scripts. The narrator (perhaps Chris the Critic) begins with a description of a user's goal and the basic "personality" of each role. From then on, the actors perform based on experience with other computer systems, on their knowledge of the real life task, on their understanding of the adopted metaphor (if any), and on their intuitions regarding good user interface behavior.

The interface and objects must appear on stage approximately as they would on screen. Even the backdrop should resemble the background or desktop of a computer presentation. Actors' appearance on stage (and disappearance off stage) must correspond to the visible presence or absence of their objects at any point in the design.

Interface Theater proceeds like a theatrical production with a great deal of audience participation. Audie the Audience Agent and Chris the Critic talk with the audience, asking them to guide players through the drama. It may be useful to provide both actors and audience with a set of task scenarios, so that everyone understands the goal of the play.

Audie filters the audience directions for Kim the Cursor and for Kerry the Keyboard. Kim moves the cursor and clicks on objects, so that other objects receive their cues from Kim, or from Kerry, as appropriate. When the scripted responses end, Audie asks the audience for more direction. If audience opinions are divided, Audie has the option of running each option through the interface.

Chris focuses and filters the audience critique. Chris must encourage audience feedback and push the actors to change behavior or appearance in keeping with audience suggestions. Once the audience and Chris decide on a change, Audie re-runs the action with the changed script or appearance.

Ariel the Spirit of the Interface is the only part of the design that can "talk back" to the audience, disputing their views. Ariel works with Audie and Chris to ensure that changes to the interface are made in a way that leads to an integrated, consistent, implementable design.

The action is played, critiqued, and replayed iteratively until both the actors and the audience are satisfied with the design. It might be helpful to videotape the last enactment as a record of the consensus between actors and audience.

What Makes These Techniques Work?

The fundamental concept underlying these collaborative, low- technology approaches to design is that no one person can embody all the knowledge required to design a successful product. Through reciprocal education, reciprocal preparation, and reciprocal validation, each participant contributes knowledge and in turn is shaped by the contributions of others. Concrete visualization reduces ambiguity and also ensures that the design proceeds to specifics, rather than becoming mired in abstractions.

The designs that emerge from consensus decision-making contain the knowledge and experience not only of the individuals but also of their respective roles and tasks, so that the final design meets all aspects of the users' needs. If you want to define quality at a design level, what better definition could you want?

References:

Muller, Michael J., Wildman, Daniel M., and White, Ellen A., Games and Other Techniques for Group Design of User Interfaces. New York: ACM, 1992. (CHI '92 tutorial)
Muller, Michael J., Wildman, Daniel M., and White, Ellen A., "PICTIVE--An Exploration in Participatory Design," CHI '91 Conference Proceedings. Reading, MA: Addison-Wesley, 1991.
Muller, Michael J., Wildman, Daniel M., and White, Ellen A., "Retrospective on a Year of Participatory Design using the PICTIVE Technique," CHI '92 Conference Proceedings. Reading, MA: Addison-Wesley, 1992.
Muñoz, R., Miller-Jacobs, H. H., Spool, J. M., and Verplank, W., "In Search of the Ideal Prototype," CHI '92 Conference Proceedings. Reading, MA: Addison-Wesley, 1992.