Houde Hill - What Do Prototypes Prototype? PDF

Handbook of Human-Computer Interaction Second, completely revised edition M. Helander, T.K. Landauer, P. Prabhu (eds.) 9 1997 Elsevier Science B.V. All rights reserved. Chapter 16 What do Prototypes Prototype? Stephanie Houde and Charles Hill...

Handbook of Human-Computer Interaction Second, completely revised edition M. Helander, T.K. Landauer, P. Prabhu (eds.) 9 1997 Elsevier Science B.V. All rights reserved. Chapter 16 What do Prototypes Prototype? Stephanie Houde and Charles Hill types can get in the way of their effective use. Current Apple Computer, Inc. terminology for describing prototypes centers on at- Cupertino, California, USA tributes of prototypes themselves, such as what tool was used to create them, and how refined-looking or 16.1 Introduction.................................................... 367 -behaving they are. Such terms can be distracting. Tools can be used in many different ways, and detail is 16.2 The P r o b l e m with P r o t o t y p e s........................ 367 not a sure indicator of completion. We propose a change in the language used to talk 16.2.1 What is a Prototype?................................ 368 about prototypes, to focus more attention on funda- 16.2.2 Current Terminology................................ 368 mental questions about the interactive system being de- signed: What role will the artifact play in a user's life? 16.3 A M o d e l of W h a t P r o t o t y p e s P r o t o t y p e....... 369 How should it look and feel? How should it be imple- mented? The goal of this chapter is to establish a model 16.3.1 Definitions................................................ 369 that describes any prototype in terms of the artifact being 16.3.2 The Model................................................ 369 designed, rather than the prototype's incidental attrib- 16.3.3 Three Prototypes of One System............. 369 utes. By focusing on the purpose of the prototype--that 16.4 F u r t h e r E x a m p l e s........................................... 371 is, on what it p r o t o t y p e s - - w e can make better decisions about the kinds of prototypes to build. With a clear pur- 16.4.1 Role Prototypes........................................ 372 pose for each prototype, we can better use prototypes to 16.4.2 Look and Feel Prototypes........................ 374 think and communicate about design. 16.4.3 Implementation Prototypes...................... 376 In the first section we describe some current diffi- 16.4.4 Integration Prototypes.............................. 377 culties in communicating about prototypes: the com- plexity of interactive systems; issues of multi-discipli- 16.5 S u m m a r y......................................................... 379 nary teamwork; and the audiences of prototypes. Next, we introduce the model and illustrate it with some initial 16.6 Acknowledgments........................................... 380 examples of prototypes from real projects. In the follow- ing section we present several more examples to illus- 16.7 P r o t o t y p e Credits........................................... 380 trate some further issues. We conclude the chapter with 16.8 References....................................................... 380 a summary of the main implications of the model for prototyping practice. 16.1 Introduction 16.2 The Problem with Prototypes Prototypes are widely recognized to be a core means of exploring and expressing designs for interactive com- Interactive computer systems are complex. Any artifact puter artifacts. It is common practice to build proto- can have a rich variety of software, hardware, auditory, types in order to represent different states of an evolv- visual, and interactive features. For example, a per- ing design and to explore options. However, since in- sonal digital assistant such as the Apple Newton has an teractive systems are complex, it may be difficult or operating system, a hard case with various ports, a impossible to create prototypes of a whole design in graphical user interface and audio feedback. Users ex- the formative stages of a project. Choosing the right perience the combined effect of such interrelated fea- kind of more focused prototype to build is an art in it- tures; and the task of designingmand prototyping--the self, and communicating its limited purposes to its user experience is therefore complex. Every aspect of various audiences is a critical aspect of its use. the system must be designed (or inherited from a pre- The ways that we talk, and even think, about proto- vious system), and many features need to be evaluated 367 368 Chapter 16. What do Prototypes Prototype ? in combination with others. screen appearance and behavior as a prototype. Pro- Prototypes provide the means for examining design grammers call a test program a prototype. A user stud- problems and evaluating solutions. Selecting the focus ies expert may call a storyboard which shows a sce- of a prototype is the art of identifying the most impor- nario of something being used, a prototype. tant open design questions. If the artifact is to provide The organization supporting a design project may new functionality for users--and thus play a new role have an overly narrow expectation of what a prototype in their lives--the most important questions may con- is. Shrage (1996) has shown that organizations develop cern exactly what that role should be and what features their own "prototyping cultures" which may cause are needed to support it. If the role is well understood, them to consider only certain kinds of prototypes to be but the goal of the artifact is to present its functionality valid. In some organizations, only prototypes which act in a novel way, then prototyping must focus on how the as proof that an artifact can be produced are respected. artifact will look and feel. If the artifact's functionality In others, only highly detailed representations of look is to be based on a new technique, questions of how to and feel are well understood. implement the design may be the focus of prototyping Is a brick a prototype? The answer depends on how efforts. it is used. If it is used to represent the weight and scale Once a prototype has been created, there are sev- of some future artifact, then it certainly is: it prototypes eral distinct audiences that designers discuss proto- the weight and scale of the artifact. This example types with. These are: the intended users of the artifact shows that prototypes are not necessarily self- being designed; their design teams; and the supporting explanatory. What is significant is not what media or organizations that they work within (Erickson, 1995). tools were are used to create them, but how they are Designers evaluate their options with their own team used by a designer to explore or demonstrate some as- by critiquing prototypes of alternate design directions. pect of the future artifact.. They show prototypes to users to get feedback on evolving designs. They show prototypes to their sup- 16.2.2 Current Terminology porting organizations (such as project managers, busi- ness clients, or professors) to indicate progress and di- Current ways of talking about prototypes tend to focus rection. on attributes of the prototype itself, such as which tool It is difficult for designers to communicate clearly was used to create it (as in "C", "Director TM'', and about prototypes to such a broad audience. It is chal- "paper" prototypes); and on how finished-looking or lenging to build protoypes which produce feedback -behaving a prototype is (as in "high-fidelity" and from users on the most important design questions. "low-fidelity" prototypes). Such characterizations can Even communication among designers requires effort be misleading because the capabilities and possible due to differing perspectives in a multi-disciplinary de- uses of tools are often misunderstood and the signifi- sign team. Limited understanding of design practice cance of the level of finish is often unclear, particularly on the part of supporting organizations makes it hard to non-designers. for designers to explain their prototypes to them. Fi- Tools can be used in many different ways. Some- nally, prototypes are not self-explanatory: looks can be times tools which have high-level scripting languages deceiving. Clarifying what aspects of a prototype cor- (like HyperCardTM), rather than full programming lan- respond to the eventual artifact--and what don'tRis a guages (like C), are thought to be unsuitable for pro- key part of successful prototyping. ducing user-testable prototypes. However, Ehn and Kyng (1991) have shown that even prototypes made of 16.2.1 What is a Prototype? cardboard are very useful for user testing. In the authors' experience, no one tool supports iterative de- Designing interactive systems demands collaboration sign work in all of the important areas of investigation. between designers of many different disciplines (Kim, To design well, designers must be willing to use differ- 1990). For example, a project might require the skills ent tools for different prototyping tasks; and to team up of a programmer, an interaction designer, an industrial with other people with complementary skills. designer, and a project manager. Even the term "proto- Finished-looking (or-behaving) prototypes are of- type" is likely to be ambiguous on such a team. Every- ten thought to indicate that the design they represent is one has a different expectation of what a prototype is. near completion. Although this may sometimes be the Industrial designers call a molded foam model a proto- case, a finished-looking prototype might be made early type. Interaction designers refer to a simulation of on- in the design process (e.g., a 3D concept model for use Houde and Hill 369 in market research), and a rough one might be made Role later on (e.g., to emphasize overall structure rather than visual details in a user test). Two related terms are used in this context: "resolution" and "fidelity". We interpret resolution to mean "amount of detail", and fi- delity to mean "closeness to the eventual design". It is important to recognize that the degree of visual and behavioral refinement of a prototype does not neces- sarily correspond to the solidity of the design, or to a Implementat particular stage in the process. Look and feel 16.3 A Model of What Prototypes Prototype Figure 1. A model of what prototypes prototype. 16.3.1 Definitions rience to be simulated or actually created; role requires the context of the artifact's use to be established. Being Before proceeding, we define some important terms. explicit about what design questions must be answered We define artifact as the interactive system being de- is therefore an essential aid to deciding what kind of signed. An artifact may be a commercially released prototype to build. The model helps visualize the focus product or any end-result of a design activity such as a of exploration. concept system developed for research purposes. We define prototype as any representation of a design idea, Markers: A prototype may explore questions or design regardless of medium. This includes a pre-existing ob- options in one, two or all three dimensions of the ject when used to answer a design question. We define model. In this chapter, several prototypes from real designer as anyone who creates a prototype in order to design projects are presented as examples. Their rela- design, regardless of job title. tionship to the model is represented by a marker on the triangle. This is a simple way to put the purpose of any 16.3.2 The Model prototype in context for the designer and their audi- The model shown in Figure I represents a three-dimen- ences. It gives a global sense of what the prototype is sional space which corresponds to important aspects of intended to explore; and equally important, what it the design of an interactive artifact. We define the di- does not explore. mensions of the model as role; look and feel; and im- It may be noted that the triangle is a relative and plementation. Each dimension corresponds to a class of subjective representation. A location toward one cor- questions which are salient to the design of any inter- ner of the triangle implies simply that in the designer's active system. "Role" refers to questions about the own judgment, more attention is given to the class of function that an artifact serves in a user' s life--the way questions represented by that comer than to the other in which is it useful to them. "Look and feel" denotes two. questions about the concrete sensory experience of using an artifactmwhat the user looks at, feels, and hears 16.3.3 Three Prototypes of One System while using it. "Implementation" refers to questions about the techniques and components through which an The model is best explained further through an example artifact performs its functionmthe "nuts and bolts" of from a real project. The three prototypes shown in Ex- how it actually works. The triangle is drawn askew to amples I-3 were created during the early stages of de- emphasize that no one dimension is inherently more velopment of a 3D space-planning application (Houde, important than any other. 1992). The goal of the project was to design an example Goal of the Model: Given a design problem (of any of a 3D application which would be accessible to a scope or size), designers can use the model to separate broad range of non-technical users. As such it was de- design issues into three classes of questions which fre- signed to work on a personal computer with an ordi- quently demand different approaches to prototyping. nary mouse. Many prototypes were created by different Implementation usually requires a working system to members of the multi-disciplinary design team during be built; look and feel requires the concrete user expe- the project. 370 Chapter 16. What do Prototypes Prototype? Figure 2. Relationship of three prototypes (Examples 1 - 3) Example 2. Look and feel prototype for 3D space-planning to the model. application [E2: Houde 1990]. most important manipulations of a space-planning task were sliding, lifting, and turning furniture objects. Ex- ample 2 shows a picture of a prototype which was made to test a user interface featuring this constrained set of manipulations. Clicking once on the chair caused its bounding box to appear. This "handle box" offered hand-shaped controls for lifting and turning the box and object chair (as if the chair was frozen inside the box). Clicking and dragging anywhere on the box al- lowed the unit to slide on a 3D floor. The prototype was built using Macromedia Director (a high level animation and scripting tool). It was made to work only with the chair data shown: a set of images pre-drawn Example I. Role prototype for 3D space-planning applica- for many angles of rotation. tion [El: Houde 1990]. The purpose of the Example 2 prototype was to get feedback from users as quickly as possible as to The prototype shown in Example 1 was built to whether the look and feel of the handle-box user inter- show how a user might select furniture from an on-line face was promising. Users of the prototype were given catalog and try it out in an approximation of their own tasks which encouraged them to move the chair around room. It is an interactive slide show which the designer a virtual room. Some exploration of role was supported operated by clicking on key areas of the rough user in- by the fact that the object manipulated was a chair, and terface. The idea that virtual space-planning would be a space-planning tasks were given during the test. Al- helpful task for non-technical users came from user though the prototype was interactive, the programming studies. The purpose of the prototype was to quickly that made it so did not seriously explore how a final convey the proposed role of the artifact to the design artifact with this interface might be implemented. It team and members of the supporting organization. was only done in service of the look and feel test. Since the purpose of the prototype was primarily to Since the designer primarily explored the look and feel explore and visualize an example of the role of the fu- of the user interface, this prototype's marker is placed ture artifact, its marker appears very near the role cor- very near the look and feel comer of the model in Fig- ner of the model in Figure 2. It is placed a little toward ure 2. the look and feel corner because it also explored user A technical challenge of the project was figuring interface elements in a very initial form. out how to render 3D graphics quickly enough on One of the challenges of the project was to define equipment that end-users might have. At the time, it an easy-to-use direct manipulation user interface for was not clear how much real-time 3D interaction could moving 3D objects with an ordinary 2D mouse cursor. be achieved on the Apple Macintosh TM II fx computer User testing with a foam-core model showed that the m the fastest Macintosh then available. Example 3 Houde and Hill 371 Example 3. Implementation prototypes for 3D space- Figure 3. Four principal categories of prototypes on the planning application [E3: Chen 1990]. model. shows a prototype which was built primarily to explore of the role that the artifact could play (guiding how - rendering capability and performance. This was a many furniture objects of what complexity could be working prototype in which multiple 3D objects could shown). It also provided guiding constraints for the di- be manipulated as in Example 2, and the view of the rect manipulation user interface determining how much room could be changed to any perspective. Example 3 detail the handle forms could have). Similarly, issues of was made in a programming environment that best role addressed by Example 1 informed the implementa- supported the display of true 3D perspectives during tion problem by constraining it: only a constrained set of manipulation. It was used by the design team to deter- manipulations was needed for a space-planning applica- mine what complexity of 3D scenes was reasonable to tion. It also simplified the direct manipulation user inter- design for. The user interface elements shown on the face by limiting the necessary actions, and therefore left side of the screen were made by the programmer to controls, which needed to be provided. give himself controls for demonstrating the system: It was more efficient to wait on the results of inde- they were not made to explore the look and feel of the pendent investigations in the key areas of role, look and future artifact. Thus the primary purpose of the proto- feel and implementation than to try to build a monolithic type was to explore how the artifact might be imple- prototype that integrated all features from the start. Af- mented. The marker for this example is placed near the ter sufficient investigation in separate prototypes, the implementation comer (Figure 2). prototype in Example 3 began to evolve into an inte- One might assume that the role prototype (Example grated prototype which could be described by a position 1) was developed first, then the look and feel prototype at the center of our model. A version of the user inter- (Example 2), and finally the implementation prototype face developed in Example 2 was implemented in the (Example 3): that is, in order of increasing detail and prototype in Example 3. Results of other prototypes production difficulty. In fact, these three prototypes were were also integrated. This enabled a more complete user developed almost in parallel. They were built by differ- test of features and user interface to take place. ent design team members during the early stages of the This set of three prototypes from the same project project. No single prototype could have represented the shows how a design problem can be simultaneously design of the future artifact at that time. The evolving approached from multiple points of view. Design design was too fuzzy---existing mainly as a shared con- questions of role, look and feel, and implementation cept in the minds of the designers. There were also too were explored concurrently by the team with the three many open and interdependent questions in every design separate prototypes. The purpose of the model is to dimension: role, look and feel, implementation. make it easier to develop and subsequently communi- Making separate prototypes enabled specific de- cate about this kind of prototyping strategy. sign questions to be addressed with as much clarity as possible. The solutions found became inputs to an inte- 16.4 Further Examples grated design. Answers to the rendering capability questions addressed by Example 3 informed the design In this section we present twelve more examples of 372 Chapter 16. What do Prototypes Prototype? Figure 4. Relationship of role prototypes (Examples 4- 7) Example 4. Storyboard for a portable notebook computer to the model [E4: Vertelney 1990]. prototypes taken from real projects, and discuss them the user interface. Its marker, shown in Figure 4, is in terms of the model. Examples are divided into four therefore positioned near the role comer of the model categories which correspond to the four main regions and a little toward look and feel. of the model, as indicated in Figure 3. The first three Storyboards like this one are considered to be ef- categories correspond to prototypes with a strong bias fective design tools by many designers because they to-ward one of the three comers: role, look and feel, help focus design discussion on the role of an artifact and implementation prototypes, respectively. Integra- very early on. However, giving them status as proto- tion prototypes occupy the middle of the model: they types is not common because the medium is paper and explore a balance of questions in all three dimensions. thus seems very far from the medium of an interactive computer system. We consider this storyboard to be a 16.4.1 Role Prototypes prototype because it makes a concrete representation of a design idea and serves the purpose of asking and an- Role prototypes are those which are built primarily to swering design questions. Of course, if the designer investigate questions of what an artifact could do for a needed to evaluate a user's reaction to seeing the note- user. They describe the functionality that a user might book or to using the pen-and-finger interaction, it benefit from, with little attention to how the artifact would be necessary to build a prototype which sup- would look and feel, or how it could be made to actually ported direct interaction. However, it might be wasteful work. Designers find such prototypes useful to show to do so before considering design options in the faster, their design teams what the target role of the artifact lighter-weight medium of pencil and paper. might be; to communicate that role to their supporting organization; and to evaluate the role in user studies. An Operating System User Interface: Example 5 shows a screen view of a prototype that was used to A Portable Notebook Computer: The paper storyboard explore the design of a new operating system. The shown in Example 4 was an early prototype of a port- prototype was an interactive story: it could only be able notebook computer for.students which would ac- executed through a single, ordered, sequence of inter- cept both pen and finger input. The scenario shows a actions. Clicking with a cursor on the mailbox picture student making notes, annotating a paper, and marking opened a mail window; then clicking on the voice tool pages for later review in a computer notebook. The de- brought up a picture of some sound tools; and so on. signer presented the storyboard to her design team to fo- To demonstrate the prototype, the designer sat in front of cus discussion on the issues of what functionality the a computer and play-acted the role of a user opening her notebook should provide and how it might be controlled mail, replying to it, and so forth. The prototype was used through pen and finger interaction. In terms of the in design team discussions and also demonstrated to model, this prototype primarily explored the role of the project managers to explain the current design direction. notebook by presenting a rough task scenario for it. A According to the model, this prototype primarily ex- secondary consideration was a rough approximation of plored the role that certain features of the operating Houde and Hill 373 Example 5. Interactive story for an operating system inter- Example 6. Knowledge NavigatorTM vision video for a fu- face [E5: Vertelneyand Wong 1990]. ture notebook computer [E6: Dubberly and Mitch 1987]. system could play in a user's daily tasks. It was also The story is told in great detail, and it is clear that used to outline very roughly how its features would be many decisions were made about what to emphasize in portrayed and how a user would interact with it. As in the role. The video also shows specific details of ap- the previous example, the system's implementation pearance, interaction, and performance. However, they was not explored. Its marker is shown in Figure 4. were not intended by the designers to be prototypes of To make the prototype, user interface elements look and feel. They were merely place-holders for the were hand-drawn and scanned in. Transitions between actual design work which would be necessary to make steps in the scenario were made interactive in Mac- the product really work. Thus its marker goes directly romedia Director. This kind of portrayal of on-screen on the role corner (Figure 4). interface elements as rough and hand-drawn was used Thanks to the video's special effects, the scenario in order to focus design discussion on the overall fea- of the professor interacting with the notebook and his tures of a design rather than on specific details of look assistant looks like a demonstration of a real product. and feel or implementation (Wong, 1992). Ironically, Why did Apple make a highly produced prototype while the design team understood the meaning of the when the previous examples show that a rapid paper hand-drawn graphics, other members of the organiza- storyboard or a sketchy interactive prototype were suf- tion became enamored with the sketchy style to the ficient for designing a role and telling a usage story? extent that they considered using it in the final artifact. The answer lies in the kind of audience. The tape was This result was entirely at odds with the original rea- shown publicly and to Apple employees as a vision of sons for making a rough-looking prototype. This ex- the future of computing. Thus the audience of the ample shows how the effectiveness of some kinds of Knowledge Navigator was very broad--including al- prototypes may be limited to a specific kind of audi- most anyone in the world. Each of the two previous ence. role design prototypes was shown to an audience which was well informed about the design project. A rough The Knowledge Navigator: Example 6 shows a scene hand-drawn prototype would not have made the idea from Apple Computer's Knowledge Navigator TM video. seem real to the broad audience the video addressed: The video tape tells a day-in-the-life story of a professor high resolution was necessary to help people con- using a futuristic notebook computer (Dubberly and cretely visualize the design. Again, while team mem- Mitch, 1987). An intelligent agent named "Phil" acts as bers learn to interpret abstract kinds of prototypes ac- his virtual personal assistant, finding information related curately, less expert audiences cannot normally be ex- to a lecture, reminding him of his mother' s birthday, and pected to understand such approximate representations. connecting him with other professors via video-link. The professor interacts with Phil by talking, and Phil appar- The Integrated Communicator: Example 7 shows an ently recognizes everything said as well as a human as- appearance model of an Integrated Communicator cre- sistant would. ated for customer research into alternate presentations Based on the model, the Knowledge Navigator is of new technology (ID Magazine 1995). It was one of identified primarily as a prototype which describes the three presentations of possible mechanical configura- role that the notebook would play in such a user's life. tions and interaction designs, each built to the same 374 Chapter 16. What do Prototypes Prototype ? Example 7. Appearance model for the integrated commu- Figure 5. Relationships of the look and feel prototypes nicator [E7: Udagawa 1995]. (Examples 8-10) to the model high finish and accompanied by a video describing on- and demonstrate options for the concrete experience of screen interactions. In the study, the value of each an artifact. They simulate what it would be like to look presentation was evaluated relative to the others, as at and interact with, without necessarily investigating perceived by study subjects during one-on-one inter- the role it would play in the user's life or how it would views. The prototype was used to help subjects imag- be made to work. Designers make such prototypes to ine such a product in the store and in their homes or visualize different look and feel possibilities for them- offices, and thus to evaluate whether they would pur- selves and their design teams. They ask users to interact chase such a product, how much they would expect it with them to see how the look and feel could be to cost, what features they would expect, etc. improved. They also use them to give members of their The prototype primarily addresses the role of the supporting organization a concrete sense of what the product, by presenting carefully designed cues which future artifact will be like. imply a telephone-like role and look-and-feel. Figure 4 shows its marker near the role comer of the model. As with the Knowledge Navigator, the very high- A Fashion Design Workspace: The prototype shown resolution look and feel was a means of making the in Example 8 was developed to support research into design as concrete as possible to a broad audience. In collaboration tools for fashion designers (Hill et al, this case however it also enabled a basic interaction 1993; Scaife et al, 1994). A twenty-minute animation, design strategy to be worked out and demonstrated. it presented the concept design for a system for moni- The prototype did not address implementation. toring garment design work. It illustrated in consider- The key feature of this kind of prototype is that it able detail the translation of a proven paper-based pro- is a concrete and direct representation, as visually fin- cedure into a computer-based system with a visually rich, direct manipulation, user interface. The proto- ished as actual consumer products. These attributes type's main purposes were to confirm to the design encourage an uncoached person to directly relate the team that an engaging and effective look and feel could design to their own environment, and to the products they own or see in stores. High quality appearance be designed for this application, and to convince man- models are costly to build. There are two common rea- agers of the possibilities of the project. It was pre- sons for investing in one: to get a visceral response by sented to users purely for informal discussion. making the design seem "real" to any audience (design This is an example of a look and feel prototype. team, organization, and potential users); and to verify The virtue of the prototype was that it enabled a novel the intended look and feel of the artifact before com- user interface design to be developed without having first to implement complex underlying technologies. mitting to production tooling. An interesting side- While the role was inherited from existing fashion de- effect of this prototype was that its directness made it a sign practice, the prototype also demonstrated new op- powerful prop for promoting the project within the or- ganization. tions offered by the new computer-based approach. Thus, Figure 5 shows its marker in the look and feel 16.4.2 Look and Feel Prototypes area of the model. One issue with prototypes like this one is that inexp- Look and feel prototypes are built primarily to explore erienced audiences tend to believe them to be more Houde and Hill 375 Example 8. Animation of the look and feel of a fashion Example 10. Pizza-box prototype of an architect's com- design workspace [E8: Hill 1992]. puter [El 0: Apple Design Project, 1992]. role that the toy would play. Neither seriously address- ed implementation. The designers of these very efficient prototypes wanted to know how a child would respond to a toy that appeared to speak and move of its own free will. They managed to convincingly simulate novel and difficult-to-implement technologies such as speech and automotion, for minimal cost and using readily available components. By using a "man behind the curtain" (or "Wizard of Oz") technique, the designers were able to present the prototypes directly to children and to directly evaluate their effect. Example 9. Look and feel simulation prototypes for a child's toy [E9: Bellman et al, 19931. An Architect's Computer: This example concerned the design of a portable computer for architects who need functional than they are just by virtue of being shown on to gather a lot of information during visits to building a computer screen. When this prototype was shown, the sites. One of the first questions the designers explored designers found they needed to take great care to explain was what form would be appropriate for their users. that the design was not implemented. Without much ado they weighted the pizza box shown in Example 10 to the expected weight of the computer, A Learning Toy: The "GloBall" project was a concept and gave it to an architect to carry on a site visit. They for a children's toy: a ball that would interact with chil- watched how he carried the box, what else he carried dren who played with it. Two prototypes from the proj- with him, and what tasks he needed to do during the ect are shown, disassembled, in Example 9. The design visit. They saw that the rectilinear form and weight were team wanted the ball to speak back to kids when they too awkward, given the other materials he carried with spoke to it, and to roll towards or away from them in re- him, and this simple insight led them to consider a softer action to their movements. The two prototypes were form. As shown by its marker, this is an example of a built to simulate these functions separately. The ball on rough look and feel prototype (Figure 5). Role was also the left had a walkie-talkie which was concealed in use. explored in a minor way by seeing the context that the A hidden operator spoke into a linked walkie-talkie to artifact would be used in. simulate the bali's speech while a young child played The pizza box was a very efficient prototype. with it. Similarly, the ball on the right had a radio- Spending virtually no time building it or considering controlled car which was concealed in use. A hidden op- options, the students got useful feedback on a basic erator remotely controlled the car, thus causing the ball design questionmwhat physical form would be best for to roll around in response to the child' s actions. the user. From what they learned in their simple field As indicated by the marker in Figure 5, both pro- test, they knew immediately that they should try to totypes were used to explore the toy's look and feel from think beyond standard rectilinear notebook computer a child's viewpoint, and to a lesser extent to evaluate the forms. They began to consider many different options 376 Chapter 16. What do Prototypes Prototype ? Figure 6. Relationships of implementation prototypes Example 11. Working prototype of a digital movie editor (Examples 11 and 12) to the model [Eli: Degen, 1994]. including designing the computer to feel more like a This prototype received varying responses when soft shoulder bag. demonstrated to a group of designers who were not members of the movie editor design team. When the audience understood that an implementation design was 16.4.3 Implementation Prototypes being demonstrated, discussion was focused produc- tively. At other times it became focused on problems Some prototypes are built primarily to answer technical with the user interface, such as the multiple cascading questions about how a future artifact might actually be menus, which were hard to control and visually confus- made to work. They are used to discover methods by ing. In these cases, discussion was less productive: the which adequate specifications for the final artifact can incidental user interface got in the way of the intentional be achieved--without having to define its look and feel implementation. or the role it will play for a user. (Some specifications The project leader shared some reflections after this may be unstated, and may include externally imposed somewhat frustrating experience. He said that part of his constraints, such as the need to reuse existing compo- goal in pursuing a working prototype alone was to move nents or production machinery.) Designers make im- the project through an organization that respected this plementation prototypes as experiments for themselves kind of prototype more than "smoke and mirrors" proto- and the design team, to demonstrate to their organiza- types---ones which only simulate functionality. He add- tion the technical feasibility of the artifact, and to get ed that one problem might have been that the user inter- feedback from users on performance issues. face was neither good enough nor bad enough to avoid A Digital Movie Editor: Some years ago it was not misunderstandings. The edit list, which allowed points to clear how much interactivity could be added to digital be marked in movies, was a viable look and feel design; movies playing on personal computers. Example 11 while the cascading menus were not. For the audience shows a picture of a prototype that was built to investi- that the prototype was shown to, it might have been gate solutions to this technical challenge. It was an ap- more effective to stress the fact that look and feel were plication, written in the C programming language to run not the focus of the prototype; and perhaps, time permit- on an Apple Macintosh computer. It offered a variety of ting, to have complemented this prototype with a sepa- movie data-processing functionality such as controlling rate look and feel prototype that explained their inten- various attributes of movie play. The main goal of the tions in that dimension. prototype was to allow marking of points in a movie to which scripts (which added interactivity) would be at- A Fluid Dynamics Simulation System: Example 12 tached. As indicated by the marker in Figure 6, this was shows a small part of the C++ program listing for a primarily a carefully planned implementation prototype. system for simulating gas flows and combustion in car Many options were evaluated about the best way to im- engines, part of an engineering research project (Hill, plement its functions. The role that the functions would 1993). One goal of this prototype was to demonstrate play was less well defined. The visible look and feel of the feasibility of object-oriented programming using the prototype was largely incidental: it was created by the C++ language in place of procedural programs the designer almost purely to demonstrate the available written in the older FORTRAN language. Object- functionality, and was not intended to be used by others. oriented programming can in theory lead to increased Houde and Hill 377 Example 12. C++program sample from a fluid dynamics Figure 7. Relationships of integration prototypes simulation system [El2: Hill, 1993]. (Examples 13 - 15) to the model. software reuse, better reliability and easier mainte- prototypes help designers to balance and resolve con- nance. Since an engine simulation may take a week to straints arising in different design dimensions; to verify run on the fastest available computers and is extremely that the design is complete and coherent; and to find memory-intensive, it was important to show that the synergy in the design of the integration itself. In some new approach did not incur excessive performance or cases the integration design may become the unique in- memory overheads. The program listing shown was the novation or feature of the final artifact. Since the user's implementation of the operation to copy one list of experience of an artifact ultimately combines all three numbers to another. When tested, it was shown to be dimensions of the model, integration prototypes are most faster than the existing FORTRAN implementation. able to accurately simulate the final artifact. Since they The prototype was built primarily for the design team' s may need to be as complex as the final artifact, they are own use, and eventually used to create a deployable the most difficult and time consuming kinds of proto- system. The marker in Figure 6 indicates that this pro- types to build. Designers make integration prototypes to totype primarily explored implementation. understand the design as a whole, to show their organi- Other kinds of implementation prototypes include zations a close approximation to the final artifact, and to demonstrations of new algorithms (e.g., a graphical get feedback from users about the overall design. rendering technique or a new search technology), and trial conversions of existing programs to run in new The Sound Browser: The "SoundBrowser" prototype environments (e.g., converting a program written in the shown in Example 13 was built as part of a larger project C language to the Java language). which investigated uses of audio for personal computer Implementation prototypes can be hard to build, users (Degen et al, 1992). The prototype was built in C and since they actually work, it is common for them to to run on a Macintosh. It allowed a user to browse digital find their way directly into the final system. Two audio data recorded on a special personal tape recorder problems arise from this dynamic: firstly, programs equipped with buttons for marking points in the audio. developed mainly to demonstrate feasibility may turn The picture shows the SoundBrowser's visual represen- out in the long term to be difficult to maintain and de- tation of the audio data, showing the markers below the velop; and secondly, their temporary user interfaces sound display. A variety of functions were provided for may never be properly redesigned before the final sys- reviewing sound, such as high-speed playback and play- tem is released. For these reasons it is often desirable back of marked segments of audio. to treat even implementation prototypes as disposable, This prototype earns a position right in the center and to migrate successful implementation designs to a of the model, as shown in Figure 7. All three dimen- new integrated prototype as the project progresses. sions of the model were explored and represented in the prototype. The role of the artifact was well thought- 16.4.4 Integration Prototypes out, being driven initially by observations of what us- ers currently do to mark and play back audio, and then Integration prototypes are built to represent the com- by iteratively designed scenarios of how it might be plete user experience of an artifact. Such prototypes done more efficiently if electronic marking and view- bring together the artifact's intended design in terms of ing functions were offered. The look and feel of the role, look and feel, and implementation. Integrated prototype went through many visual design iterations. 378 Chapter 16. What do Prototypes Prototype? Example 13. Integrated prototype of a sound browser [E13: Degen, 1993]. The implementation was redesigned several times to Example 14. Integration prototype of the "Pile" metaphor meet the performance needs of the desired high-speed for information retrieval [El4: Rose, 1993]. playback function. When the SoundBrowser was near completion it sign in this prototype might have been achieved with was prepared for a user test. One of the features which virtually no user interface: just text input and output. the design team intended to evaluate was the visual However, since the prototype was to be shown to a representation of the sound in the main window. They broad audience, an integrated style of prototype was wanted to show users several alternatives to understand chosen, both to communicate the implementation point their preferences. The programmer who built the and to verify that the piles representation was practi- SoundBrowser had developed most of the alternatives. cally feasible. It helped greatly that the artifact's role In order to refine these and explore others, two other and look and feel could be directly inherited from pre- team members copied screen-shots from the tool into a vious prototypes. Figure 7 shows its marker on the pixel-painting application, where they experimented model. with modifications. This was a quick way to try out different visual options, in temporary isolation from other aspects of the artifact. It was far easier to do this A Garment History Browser: The prototype in Exam- in a visual design tool than by programming in C. ple 15 was a working system which enabled users to When finished, the new options were programmed into enter and retrieve snippets of information about gar- the integrated prototype. This example shows the ment designs via a visually rich user interface (Hill et value of using different tools for different kinds of de- al, 1993; Scaife et al, 1994). The picture shows the sign exploration, and how even at the end of a project query tool which was designed to engage fashion de- simple, low-fidelity prototypes might be built to solve signers and provide memorable visual cues. The proto- specific problems. type was designed for testing in three corporations with a limited set of users' actual data, and presented to us- The Pile Metaphor: The prototype shown in Example ers in interviews. It was briefly demonstrated, then us- 14 was made as part of the development of the "pile" ers were asked to try queries and enter remarks about metaphor--a user interface element for casual organi- design issues they were currently aware of. zation of information (Mander et ai, 1992, Rose et al, This prototype was the end-result of a progression 1993). It represented the integration of designs devel- from an initial focus on role (represented by verbal us- oped in several other prototypes which independently age scenarios), followed by rough look and feel proto- explored the look and feel of piles, "content-aware" types and an initial implementation. Along the way information retrieval, and the role that piles could play various ideas were explored, refined or rejected. The as a part of an operating system. In the pile metaphor, working tool, built in Allegiant SuperCard TM, required each electronic document was represented by a small two months' intensive work by two designers. In retro- icon or "proxy", several of which were stacked to form spect the designers had mixed feelings about it. It a pile. The contents of the pile could be quickly re- was highly motivating to users to be able to manipulate viewed by moving the arrow cursor over it. While the real user data through a novel user interface, and much cursor was over a particular document, the "viewing was learned about the design. However, the design- cone" to the right displayed a short text summary of the ers also felt that they had had to invest a large amount document. of time in making the prototype, yet had only been able This prototype was shown to designers, project to support a very narrow role compared to the breadth managers, and software developers as a proof of con- shown in the animation shown in Example 8. Many cept of the novel technology. The implementation de- broader design questions remained unanswered. Houde and Hill 379 Example 15. Integrated prototype of a garment history 1. 3D space-planning (role) browser [El5: Hill and Kamlish, 1992]. 2. 3D space-planning (look and feel) 3. 3D space-planning (implementation) 4. Storyboard for portable notebook computer 16.5 Summary 5. Interactive story, operating system user interface 6. Vision video, notebook computer In this chapter, we have proposed a change in the lan- 7. Appearance model, integrated communicator guage used by designers to think and talk about proto- 8. Animation, fashion design workspace types of interactive artifacts. Much current terminology 9. Look and feel simulation, child's toy centers on attributes of prototypes themselves: the tools 10. Pizza-box, architect's computer used to create them, or how refined-looking or -behaving 11. Working prototype, digital movie editor they are. Yet tools can be used in many different ways, 12. C++ program listing, fluid dynamics simulation and resolution can be misleading. We have proposed a 13. Integrated prototype, sound browser shift in attention to focus on questions about the design 14. Integrated prototype, pile metaphor of the artifact itself: What role will it play in a users 15. Integrated prototype, garment histor browser life? How should it look and feel? How should it be implemented? The model that we have introduced can Figure 8. Relationships of all examples to the model. be used by designers to divide any design problem into these three classes of questions, each of which may project, as in the 3D space-planning example benefit from a different approach to prototyping. [Examples 1, 2, and 3]. Choosing the fight focused We have described a variety of prototypes from real prototypes to build is an art in itself. Be prepared to projects, and have shown how the model can be used to throw some prototypes away, and to use different communicate about their purposes. Several practical tools for different kinds of prototypes. suggestions for designers have been raised by the ex- amples: 9 Know your audience. The necessary resolution and fidelity of a prototype may depend most on the nature Define "prototype" broadly. Efficient prototypes of its audience. A rough role prototype such as the produce answers to their designers' most important interactive storyboard [Example 4] may work well for questions in the least amount of time. Sometimes a design team but not for members of the supporting very simple representations make highly effective organization. Broader audiences may require higher- prototypes: e.g., the pizza-box prototype of an ar- resolution representations. Some organizations expect chitect's computer [Example 10] and the story- to see certain kinds of prototypes: implementation board notebook [Example 1]. We define a proto- designs are often expected in engineering depart- type as any representation of a design ideam ments, while look-and-feel and role prototypes may regardless of medium; and designers as the people rule in a visual design environment. who create them--regardless of their job titles. 9 Know your prototype; prepare your audience. Be BuiM multiple prototypes. Since interactive artifacts clear about what design questions are being ex- can be very complex, it may be impossible to create plored with a given prototype--and what are not. an integrated prototype in the formative stages of a Communicating the specific purposes of a prototype 380 Chapter 16. Whatdo Prototypes Prototype? to its audience is a critical aspect of its use. It is up [E8] Charles Hill. (1992) 9 Royal College of Art, Lon- to the designer to prepare an audience for viewing a don. Design team: Gillian Crampton Smith, Eleanor prototype. Prototypes themselves do not necessarily Curtis, Charles Hill, Stephen Kamlish, (all of the RCA), communicate their purpose. It is especially impor- Mike Scaife (Sussex University, UK), and Philip Joe tant to clarify what is and what is not addressed by a (IDEO, London). prototype when presenting it to any audience be- yond the immediate design team. [E9] Tom Bellman, Byron Long, Abba Lustgarten. (1993) University of Toronto, 1993 Apple Design Proj- By focusing on the purpose of the prototype--that ect, 9 Apple Computer Inc. is, on what it prototypes--we can make better deci- sions about the kinds of prototypes to build. With a [El0] 1992 Apple Design Project, 9 Apple Computer, clear purpose for each prototype, we can better use Inc. prototypes to think and communicate about design. [El 1] Leo Degen (1994) 9 Apple Computer Inc., Proj- ect team: Leo Degen, Stephanie Houde, Michael Mills 16.6 Acknowledgments (team leader), David Vronay. Special thanks are due to Thomas Erickson for guidance [El2] Charles Hill (1993). Doctoral thesis project, Im- with this chapter, and to our many colleagues whose perial College of Science, Technology and Medicine, prototypes we have cited, for their comments on early London, UK. Project team: Charles Hill, Henry Weller. drafts. We would also like to acknowledge S. Joy Mountford whose leadership of the Human Interface [El3] Leo Degen (1993) 9 Apple Computer Inc., Proj- Group at Apple created an atmosphere in which creative ect team: Leo Degen, Richard Mander, Gitta Salomon prototyping could flourish. Finally, thanks to James (team leader), Yin Yin Wong. Spohrer, Lori Leahy, Dan Russell, and Donald Norman at Apple Research Labs for supporting us in writing this [El4] Daniel Rose. (1993). 9 Apple Computer, Inc. chapter. Project team: Penny Bauersfeld, Leo Degen, Stephanie Houde, Richard Mander, Ian Small, Gitta Salomon 16.7 Prototype Credits (team leader),Yin Yin Wong We credit here the principal designer and design team [El5] Charles Hill and Stephen Kamlish. (1992) 9 of each example prototype shown. Royal College of Art, London. Design team: Gillian Crampton Smith, Eleanor Curtis, Charles Hill, Stephen [El] Stephanie Houde [E2] Stephanie Houde[E3] Mi- Kamlish, (all of the RCA), and Mike Scaife (Sussex chael Chen (1990) 9 Apple Computer, Inc. Project University, UK). team: Penny Bauersfeld, Michael Chen, Lewis Knapp (project leader), Laurie Vertelney and Stephanie Houde. 16.8 References [E4] Laurie Vertelney. (1990), 9 Apple Computer Inc. Degen, L., Mander, R., Salomon, G. (1992). Working Project team: Michael Chen, Thomas Erickson, Frank with Audio: Integrating Personal Tape Recorders and Leahy, Laurie Vertelney (project leader). Desktop Computers. Human Factors in Computing Systems: CHI'92 Conference Proceedings. New York: [E5] Laurie Vertelney and Yin Yin Wong. (1990), ACM, pp. 413-418. 9 Apple Computer Inc. Project team: Richard Man- Dubberly, H. and Mitch, D. (1987). The Knowledge der, Gitta Salomon (project leader), Ian Small, Laurie Navigator. Apple Computer, Inc. videotape. Vertelney, Yin Yin Wong. Ehn, P., Kyng, M., (1991) Cardboard Computers: Mocking-it-up or Hands-on the Future., Design at [E6] Dubberly, H. and Mitch, D. (1987) 9 Apple Work: Cooperative Design of Computer Systems (ed. Computer, Inc. The Knowledge Navigator (videotape.) Greenbaum, J., and Kyng, M.). Hillsdale, NJ: Law- [E7] Masamichi Udagawa. (1995) 9 Apple Computer rence Erlbaum. pp. 169-195. Inc. Project team: Charles Hill, Heiko Sacher, Nancy Erickson, T., (1995) Notes on Design Practice: Stories Silver, Masamichi Udagawa. and Prototypes as Catalysts for Communication. Houde and Hill 381 "Envisioning Technology: The Scenario as a Frame- work for the System Development Life Cycle" (ed. Car- roll, J.). Addison-Wesley. Hill, C. (1993) Software Design for Interactive Engi- neering Simulation. Doctoral Thesis. Imperial College of Science, Technology and Medicine, University of London. Hill, C., Crampton Smith, G., Curtis, E., Kamlish, S., (1993) Designing a Visual Database for Fashion De- signers. Human Factors in Computing Systems: INTERCHI'93 Adjunct Proceedings. New York, ACM, pp. 49-50. Houde, S., (1992). Iterative Design of and Interface for Easy 3-D Direct Manipulation. Human Factors in Computing Systems: CHI'92 Conference Proceedings. New York: ACM, pp. 135-142. I.D.Magazine, (1995) Apple's Shared Conceptual Model, The International Design Magazine: 41's An- nual Design Review, July-August 1995. USA. pp. 206- 207 Kim, S. (1990). Interdisciplinary Collaboration. The Art of Human Computer Interface Design (ed. B. Lau- rel). Reading, MA: Addison-Wesley. pp.31-44. Mander, R., Salomon, G., Wong, Y.Y. (1992). A 'Pile' Metaphor for Supporting Casual Organization of In- formation. Human Factors in Computing Systems: CHI'92 Conference Proceedings. New York: ACM, pp. 627-634. Rose, D.E., Mander, R., Oren, T., Poncele6n, D.B., Salomon, G., Wong, Y. (1993). Content Awareness in a File System Interface: Implementing the 'Pile' Meta- phor for Organizing Information. Research and Devel- opment in Information Retrieval: SIGIR Conference Proceedings. Pittsburgh, PA: ACM, pp. 260-269. Scaife, M., Curtis, E., Hill, C. (1994) Interdisciplinary Collaboration: a Case Study of Software Development for Fashion Designers. Interacting with Computers, Vol 6. no.4, pp. 395-410 Schrage, M. (1996). Cultures of Prototyping. Bringing Design to Software (ed. T. Winograd). USA: ACM Press. pp. 191-205. Wong, Y.Y. (1992). Rough and ready prototypes: Les- sons from graphic design. Human Factors in Comput- ing Systems: CHI'92 Conference, Posters and Short- Talks, New York: ACM, pp.83-84.