Notes on Design Practice: Stories and Prototypes as Catalysts for Communication*

Thomas Erickson
User Experience Architect's Office
Apple Computer, Inc.

(now at) snowfall@acm.org

Donald Schön (1987) has argued eloquently that professional practices like design are more of an art than a science. In much of their daily work designers are not grappling with well-formed problems but with, as Schön puts it, "messy, indeterminate situations." Schön's investigations have been principally directed at design by one or two individuals, with an emphasis on education and the master-apprentice relationship. I want to discuss the design of products that incorporate new technologies. This means that the design process usually involves a team of designers from different disciplines, and that the team must interact with the prospective users of its product and with the much larger organization of which it is a part. In short, the design of technology-based products is inextricably entwined with social and organizational dynamics. This expands the realm of messy, indeterminate situations considerably.

My goal is to talk about some of the informal, practical methods that designers use to grapple with the messy, ill-defined issues that pervade their daily practice. The issues I am concerned with are the following:

Problem setting. Before designers can solve a problem, they first must define what it is. How do designers of new technologies begin when they are unsure of what they are making, what it should do, or who will use it?

Team building. Technology design is carried out by interdisciplinary teams. Members of the team may not necessarily understand the skills or priorities of others. How can a diverse group of people evolve into a smoothly functioning design team?

Involving users. Designers know too much, and they know too little. Designers who know enough to incorporate a technology into a product know too much to understand how users will perceive it. At the same time, designers know too little about the users' lives to understand how the product will mesh with their work practices. How can users be effectively involved in the design process, particularly in the beginning when there is nothing to show them?

Collaborative design. The heart of design is the iterative process of creating a prototype that embodies the design, evaluating it, and then using the feedback to create a new prototype. In the course of this, the members of the design team must work closely with one another, even though they have different working techniques, methods of analysis, evaluation criteria, and different languages for describing what they do. How can the collective activity of the team be supported? What properties make a prototype useful?

Design transfer. In large organizations, those who design a product are often not the same as those who implement it. A product concept may be developed in a research division and then transferred to a product division. Even when the designers and implementors are the same, many new people -- in marketing, manufacturing, documentation -- will become involved as the design makes its way from concept to reality. It is important that knowledge about the rationale behind the design be shared with those involved in preparing it for the marketplace. How can that be done?

Design evangelism. Much design occurs in the context of large organizations. Buy in of people -- executives, managers, potential collaborators -- is a necessity if the designed product is to be implemented, manufactured, and marketed. How can those not involved in the design process be convinced of its validity and worth?

An underlying assumption of this chapter is that design is a distributed social process, and that, as such, communication plays a vital role in design. In holding this view, I share common ground with others in this volume who discuss on the social and communicative aspects of design. Karat discusses the use of scenarios as devices for facilitating communication among members of the design team. The chapters by Kyng and by Mueller and his colleagues focus on ways of enabling users to participate as first class contributors to the design process, and pay special attention to the use of concrete representations for this purpose. Carey and Rusli go beyond the scope of a single design project, and look at ways of re-using design knowledge in the education of new designers and the development of different but related products.

This chapter extends these ideas in two ways. First, it discusses communication within the organization in which design takes place, as well as communication within the design team and between the design team and the users. Second, it examines two concrete artifacts -- stories and prototypes -- and discusses the properties which make them effective communications catalysts.


Design as Communication

To begin, I will sketch a simple, communication-oriented model of design. It is useful to think about design as a process of communication among various audiences. Central to this discussion is the notion of design artifacts, material or informational objects that are constructed during the design process.

Let's examine this perspective in more detail.


Communication

I am using "communication" its broadest sense. Talking, telephoning, sending email, writing reports, giving presentations, and showing videos all fall under communication. Thus communication can be one-to-one or one-to-many, and a 'conversation' may occur in real time, or may be spread out over hours, days, weeks, or longer. Also note that many of these types of conversations occur through, or are facilitated by, the use of some kind of persistent, physical representation. What we will focus on is the role played by design artifacts in supporting communication.

In a sense, even the design activities of a single individual can be classified as a communications activity. For example, note taking can be viewed as an act of communicating with one's self over time. Schön (1987) characterizes design practice as a protracted "conversation with the situation," in which designers embody their ideas in some representational medium, reflect on them, and the modify them. Similarly, Thimbley (1990) suggests that work by an individual is a special case of cooperative work -- reflexive cooperative work -- in which various concrete artifacts support individuals in collaborating with themselves over time. Whether or not one finds the notion of reflexive communication palatable, physical artifacts clearly play a role in both sorts of activity.

Design Artifacts

I use the term "design artifact" to mean any of the physical or informational entities collected or constructed during the design process. Examples of design artifacts include videos of users, snapshots of usage contexts, transcripts of user interviews, scenarios, prototypes, marketing studies, data sets produced by user tests, progress reports, professional publications, and formal documents such as engineering requirements specifications and marketing requirements documents. Design artifacts are produced for a variety of reasons. They may be created as a way of capturing information, or as a way of disseminating information, or simply as a side effect of a process that is occurring. background, knowledge, and experience. Regardless of the explicit reason for their creation, many design artifacts play a role in catalyzing communication among the various audiences involved in the design process.


Audiences

There are different audiences for a design that are associated with one or more stages in the design's life cycle. The actual audiences for a design will vary depending on the nature of the product being designed and the organization within which the design takes place. The different audiences are important because they require different design artifacts, or at least require the same artifact to be used in different ways. For expository purposes, I'll talk about three audiences: the design team itself; the intended end users; and the organization within which the design activity takes place.


The Design Team
Many people are involved in the design of new technologies. They are likely to include technologists, graphic designers, psychologists, and industrial designers. In spite of being grouped as one audience, the differences in working methods, evaluation criteria, skills, and inclinations that arise from training in different disciplines make this an extremely diverse audience. If the members of the team have not worked together before, the gaps between team members may be as large as those between the design team and other audiences. And, in participatory design (see Kyng, and Mueller, et al., this volume), users may also be full fledged members of the design team, thus increasing its diversity. For expository purposes, I will refer to members of the design team as "designers," regardless of their background.

The Users
Users represent the intended users of the final product. They are typically expert in some domain of activity relevant to the product being designed, but are not versed in the technology which will be manifested in the design. For users to provide useful feedback, they must be given a concrete understanding of the nature of the to-be-designed product.

The Organization
An oft-neglected audience for the design is the organization within which it is created and produced. Yet organizations play a fundamental role in shaping the nature of the design process (e.g., Grudin , 1991a; Grudin, 1991b). Design processes will differ radically depending on whether they are being carried out by a group in a large, product development organization, an in-house development group, or a design consultancy on contract to a client.

This paper discusses product development in the context of large, product development organizations. Such organizations are characterized by internal competition for resources as research projects and product investigations struggle to make it onto the product track. Thus, a design team must be prepared to defend the validity of its design throughout the design process, and, if successful, must be able to communicate the rationale behind the design when it is time to implement it. Like the design team, this audience is quite heterogeneous: it includes executives, managers, potential implementors, and designers not on the design team.


The Early Stages of the Design Life Cycle

Like the audiences for a design, the life cycle of a design depends on what is being designed and the organizational context. Because my concern is the design of new product concepts in product development organizations, I will speak of a design life cycle with three stages -- exploration, refinement, and transition. Other more complex models may be advanced, but these three stages will suffice for our purposes. Another caveat is that the use of the word "stage" is primarily a linguistic convenience; these stages aren't cleanly separated: they are likely to have considerable overlap, with the focus shifting gradually from one to another.

Exploration
The exploratory stage of design is where the requirements for the product are gathered and the basic product concept is defined. All designs -- excepting those that are incremental improvements of existing products -- go through an exploratory phase. However, depending on the organization and circumstances, the exploratory phase may be done by a marketing group, by a manager or executive, or by a design team. In my remarks I will assume that the exploratory stage is pursued by the design team.

The exploratory stage of design is characterized by confusion and unease within the design team. Nothing is settled. Although the design team has a set of constraints, many are often no more than accidents of circumstance. Typically, the design team will have a set of new technologies to which it has access, some indications of appropriate directions or application areas which may have been provided by upper management or distilled from the corporate zeitgeist, and probably some sort of deadline for formulating a design proposal. The problems to be solved -- Who is it for? What will it do? What problems and needs will it address? What practices will it support? -- remain to be defined. The main goal of this stage of design is to understand the usage domain, define the problems being addressed, and develop a high level vision of the product being designed.

In addition, some or all of the designers may be new to the team. Thus, the team needs to arrive at a shared understanding of the skills and expertise of fellow team members, and must develop methods for working together effectively. When the team is composed of members from different disciplines, this team building can be a major undertaking in itself (see Kim, 1990).

Refinement
The refinement stage is aimed at filling in the details: having determined what the design will do, the design team must determine how it will accomplish those ends, what criteria it will use to evaluate the design, how it will determine tradeoffs between conflicting criteria. It is during this stage that the focus shifts to prototypes; these serve as a medium for team collaboration and as a means for eliciting input from users and from other designers within the organization. The refinement stage concludes with the production of a design specification of sufficient detail that it may be transferred to those who implement it.

Transition
The transition stage is devoted to getting the design adopted and implemented by the organization. One set of activities may be characterized as design evangelism. Basically, the validity and worth of the design concept must be 'sold' to the large number of people who have some say on whether the design becomes a product. If evangelism is successful, attention shifts to transferring the design. Transfer activities may involve handing off the design to a product development team, recruiting people to implement the design, or arguing for additional resources to be allocated to the design team so that it can undertake the product development effort itself. In general, transition activities are aimed at marketing the design within the organization, although key customers may sometimes be included.

The life cycle of the design, of course, continues after the transition stage. A host of new activities arise in conjunction with implementing, marketing, and supporting the product. But the first three stages are sufficient for this discussion.

Summary

In this section, I've laid out a simple model of the design process based on the use of artifacts to mediate communication among various audiences. Depending on the stage of design, the goals of the design team, and the audience being addressed, different artifacts may be used to mediate communication (or the same design artifact may be used for different ends). Table 1 summarizes a few of the typical, communication-oriented activities at each stage of the design life cycle.

Table 1 : Stages of Design and Typical Activities and Audiences

Exploration

• Problem setting. The design team learns about the problems and practices of the users for whom they are designing.
• Team building. Internally, the team develops a shared understanding of their project and of the skills and expertise of each member.

Refinement

• Collaborative design. The team develops the details of the design by embodying it in prototypes, which are used to explore design solutions and evaluate their consequences.
• Involving users. To get useful feedback from users, the team must help the users arrive at an understanding of the design.

Transition

• Design evangelism. Within the organization the design project must be defended so that it can continue to get resources. (Depending on economic conditions, this activity may occur in earlier stages as well.)
• Design transfer. The rationale behind the design must be communicated to those who will implement it, so that crucial features of the design are not lost.

The Guilt Pile

You receive something you feel that you ought to read but, because it's not vitally important, you don't want to do it immediately.

Instead, you toss it on a pile of documents which probably sits on a work surface in a corner of your office. You feel good. Things are under control, and with a minimal investment of time!

Time passes. The pile gets higher and higher. It begins to look like there's literally a mountain of stuff you ought to read. You begin to feel uncomfortable.

Provoked by the pile's height, you sort through it, discarding articles that no longer seem interesting, perhaps selecting one or two to read. The winnowed pile -- now of a much more manageable size -- is put back in its place. You feel good. Things are under control again.

I like this story because it not only explains how people use piles, but why they use piles. It provides the design rationale behind piles. It is able to do this effectively because stories describe not just actions, but feelings and motivations. This story captured something that struck me when interviewing people about how they organized information in their work environments: Almost everyone was embarrassed at how poorly they managed information. They felt bad because they had lost control over their information, and they felt good at the times when they had managed to sort through everything and organize it, no matter how casually. The desire to feel good and on top of things rather than bad and out of control is one with which most people can empathize. People recognize themselves and their desires in the story.


Involving Users -- Story Telling

Stories are a natural way of beginning dialog with users. Consider the following story:

(An office building has an intelligent energy management system that conserves energy on weekends by turning off unneeded lights after an hour has elapsed. An employee, accompanied by his six year old daughter, has stopped by to finish up some work,. Suddenly, the lights go out.)

Daughter: Who turned off the lights?

Father: (matter-of-factly) The computer turned off the lights.

Daughter: (pause) Did you turn off the lights?

Father: No, I told you, the computer turned off the lights.

(Someone manually turns the lights back on)

Daughter: Make the computer turn off the lights again.

Father: (with irony) It will in a few minutes.

As I tell this story, I use my voice to dramatize it. The little girl is incredulous, she doesn't initially believe the computer turned out the lights. Dad, on the other hand, has experienced this before: his first statement is matter-of-fact; his final statement has an undertone of irony.

The story works on a number of levels. Quite obviously, it illustrates that systems that try to be intelligent can be annoying and perplexing if they're not intelligent enough. The story also raises some deeper issues. As the child indicates, people want to understand why things change, and people want to feel like they are in control. One wonders what kind of mental model she has formed of this capricious, out-of-control computer. And, as the father's responses indicate, people also become accustomed, or at least resigned, to the inconveniences foisted on them by technology.

This story elicits a number of responses from users. People generally laugh at the last line of dialog. The story captures a sense of frustration with technology that many people share. Often those who hear this story will recount their own stories of stupid intelligent technology, or technology which has failed them in some other way. Others will step forward to defend the technology, and argue that the problem is not technology, but badly designed technology. And so on. The important bit here is not the particular conclusion that is reached, if any, but rather that people have been engaged, drawn into discussion of ideas about which -- before the story -- they would have had nothing to say.

This is, in fact, a good metric for stories. I judge the 'goodness' of a story by telling it to other people, and seeing how much they nod or laugh as they listen. When they hear a 'good' story, listeners say, 'oh yeah, something like that happened to me ' and tell me their own version of that story. People who believe they have nothing to say about how technology shapes their lives, or who bridle at possibly exposing their ignorance of technology, are quite happy to tell stories that -- to the attentive designer -- may be far more revealing than a cautiously ventured generality.


Transferring Design Knowledge

The collection and generation of stories happens most during the exploratory stage of design, and serves as a useful precursor to more formal analyses. However, stories are useful even after the initial fuzzy knowledge has been codified into problem definitions, design principles, lists of user needs, information flow diagrams, and other more formal design artifacts. Once the early stage of design is done, stories become important as mechanisms for communicating with the organization.

One role stories play is in assisting in communicating with high level management. Depending on the nature of the organization, and the economic conditions under which it is operating, design teams may need to defend the validity of their design in an effort to maintain their funding, or to make the case for moving the design from a product investigation or research track, to a product development track. In both cases, many of the higher level managers involved in the decision will have neither the time nor the inclination to understand the details of a design. What they need is to quickly understand the gist of the design, why it makes sense, why people will want to buy it. Stories excel at encapsulating this kind of information.

This is not to say that stories are the only source of information considered in making a product decision -- certainly not. But stories play more of a role than most people would expect. Consider Norman's (1993) description of executive decision making based on his wide experience as a design consultant:

I remember just such a meeting of senior executives at a major American company, decision makers inundated with statistics and facts. And then one of the highly placed decision makes spoke up: "You know, my daughter came home the other day and said . . .," and the story poured out. "Hmm," another executive said, "that makes sense, but you know, the other day . . ." and out came a story. A few stories, some discussion of the stories, and the decision.

Stories also support design transfer, by capturing both action and motivation, both the what and the why of the design. For example, the guilt pile story captures a high level view of the design rationale behind piles: it illustrates how piles are used, and the motivation for using them in that way. When describing the design for an electronic analog of piles (Mander, et al., 1992), it is much easier to convince listeners of the design's value by telling them the guilt pile story, than by just describing piles as self-revealing containers which support casual organization and lightweight browsing. The response to the latter is often, 'well, folders could be used to do most of that.' Somehow, when the guilt pile story is told, listeners don't respond that a 'guilt folder' would work as well. The guilt pile story enables them to relate the design to their personal experience, and they realize that the height and volume of the pile plays an important role in inciting action.

Stories are particularly useful for communicating within the organization for two reasons. First, stories are extremely memorable. People will remember the guilt pile story long after they have forgotten the more formal principles behind piles. Second, stories have an informality that is well-suited to the lack of certainty that characterizes much design-related knowledge. Virtually any kind of information uncovered during the exploratory or refinement stage of design will have uncertainty associated with it: it is likely that it will only be true of certain individuals, in certain situations, under certain circumstances. Presentation of such information as "design principles," or "findings," will often elicit arguments about validity and generality from the skeptical. In contrast, stories seem to sidetrack the debates about methodology. People understand that stories are not accurate, that they are likely to bend the truth for rhetorical ends, and so the discussion tends to be of the issues raised by the stories, rather than their obvious shortcomings.


Beyond Stories

As we've just noted, stories are not particularly accurate. Stories are like pearls, layers of gloss accreted around an irritating grain of reality. They exaggerate both the travails and prowess of the teller. Thus, it would be quite unwise to rely on stories as the only source of information.

Fortunately, stories are not the only tool in the designer's repertoire. Stories are well complemented by techniques that provide a direct look at more ordinary aspects of tasks and situations. Techniques such as observations, interviews, ethnographic studies, laboratory studies, and the inclusion of users on the design team can provide different information which, combined with stories, can yield a more comprehensive picture of the situation. And once a good understanding of the situation has been gained, more structured approaches such as task analysis, scenario generation, and prototyping become much easier.


Prototypes as Communications Media

Stories are used most during the exploratory and transition stages of design; prototypes come into play in the refinement stage. After the design team has made sense of the usage domain by identifying the needs and problems of the users, the focus of the design process shifts to the product being designed. Here prototypes, as concrete representations of the to-be-designed product, assume a central role.

There are many types of prototypes. They range from crude and non-interactive, to realistic simulations that cannot, at a glance, be distinguished from the final product. A prototype may be no more than a rough pencil sketch. It may be a mock-up of a device made from foam core or cardboard, intended only to mimic the form of the final product. It may be a simple slide show of images on a computer screen, accompanied, perhaps, by narration. It may be a videotape that shows the simulated behavior of a proposed product. It may be simulated in a software prototyping environment that supports some of the interaction that will characterize the product. Or it may be a partially-implemented version of the product that has most of the properties and behaviors of the real thing.

A number of different prototypes will usually be created during the design process, often for different purposes. It is important to emphasize that even prototypes which are crude, and support no interactivity at all, are essential. Crude, non-interactive prototypes allow designers to quickly capture rough concepts early in the design. Prototypes with a more polished appearance may be used to help communicate about the gist of the design. Prototypes that support interactivity may be used to elicit feedback from users.

Because of the range of forms which prototypes can take on, I will discuss them in terms of the roles they play in the design process. I will distinguish between vision prototypes, which are used in the exploratory stage of design to capture a high level picture of the design, and working prototypes, which are used to represent details of the design and to explore solutions to design problems.

Embodying the Vision

A central activity of the exploratory stage of design is the construction of a vision prototype. A vision prototype is usually some sort of concrete representation with an embedded story or scenario that shows actions at a very high level. The purpose of the vision prototype is to communicate what the gist of the design is, how it helps people with things they care about, how it fits into the flow of activities that characterize a user's day. In a sense, the vision prototype is yet another round of storytelling, but with the story focused on the to-be-designed product. The usual audience for a vision prototype is the organization.

The method we favor is to produce a videotape (Vertelney, 1989), or a partially interactive computer demonstration, featuring line drawings of users in their environment, drawings of the intended product, and a sound track (Wong, 1992). Typically, drawings are made by hand and then scanned into the computer, where small amounts of interactivity, and animation are added, along with a sound track. The result is something that seems realistic but cannot be mistaken for something that is real. On the one hand, it must be convincing in the sense that the audience comes away believing it is a realistic depiction of how and why people may use the product. On the other hand, it should be apparent that what is being shown is a product concept, not a product that will soon be ready to ship. Such a misperception can lead both to unfortunate pressures on the design team, as well as to irritation on the part of members of the organization who may feel that they have been deceived.

As already noted, the exploratory stage of the design process is complicated by the necessity of the design team developing a smooth working relationship. In this respect, the construction of the vision prototype is a good follow on to the collection and generation of stories. Because the creation of the vision prototype involves crafting a story or scenario about the to-be-designed product, everyone can contribute. The process of doing this forces the design team to arrive at a shared understanding of the problems they want to tackle, and at the types of solutions they hope to offer. The vision prototype is particularly appropriate because it focuses the design team on the high level issues about the product being designed and the needs it meets -- details of how the design does things, what it looks like, and other sources of potential discord are deferred until the refinement stage of the design process.

Reaching Beyond the Design Community

In some cases, highly polished vision prototypes may be produced (e.g., Dubberly & Mitch, 1987; Tognazzini, 1994). This tends to occur if the prototype is going to be shown publicly, or to the organization's senior management. For example, as design researcher Michael Schrage comments, "many engineers conceal provocative prototypes from senior management until they have been appropriately polished" (Schrage, 1993). The concern, of course, is that the prototype may be rejected if it has 'rough edges.'

Highly polished prototypes have drawbacks and benefits. On the one hand, the more polished a prototype is, the more likely it is to be used simply as a vehicle for persuasion and public relations. The danger here is that significant energy may be diverted from design to polishing and production. As Schrage notes, "at many large organizations, demonstrating a prototype to senior management assumes all the logistical trappings and investments of a Broadway musical" (Schrage, 1993). A second drawback is that due to the relative expense of producing a polished prototype, and the concern about adverse publicity, there may be internal pressures to avoid pursuing realistic design issues such as what happens when something goes wrong (e.g. Tognazzini, 1994). On the other hand, prototypes that are publicly shown can stimulate public discussion about the appropriateness and value of particular technologies.

One of the best known examples of a highly polished vision prototype is Apple Computer's "Knowledge Navigator" videotape (Dubberly & Mitch, 1987). The Knowledge Navigator is a five minute video that depicts a future computer with capacities such as voice recognition, integrated telecommunications, video conferencing, and a human-like agent that carried out tasks for the user. The video shows a college professor using the Knowledge Navigator to prepare a lecture at the last minute, retrieving research papers, running a simulation, and contacting a colleague who agrees to show up at the class (over video) to answer questions. (It is worth noting that the Knowledge Navigator is presented as a story: the protagonist's character flaw (procrastination) involves him in a last-minute race to pull together a lecture, with technology coming to the rescue and his nagging mother providing a humorous counterpoint.)

The Knowledge Navigator provoked great debate in the interface design community. For example, a year after its release, a panel at a professional conference conducted a rousing debate on various social issues raised by the prototype (O'Conner, 1988). Concerns ranged from the appropriateness of portraying computer programs as human-like, to how such technology might impact the training of graduate students (in the story, the agent carried out many tasks that would normally have been done by a professor's research assistant). The Knowledge Navigator provoked popular interest as well: at the same conference, librarians from two universities reported that it was the most frequently borrowed tape in their video collections (Brower, 1988). As a way of stimulating thought and discussion about the consequences of new technologies, the Knowledge Navigator was an unqualified success.


The Working Prototype as a Design Medium

Working prototypes are generally distinct from vision prototypes. Working prototypes emphasize the form, interactivity, and visual appearance of the product itself, not how the product fits with the user's activities. The working prototype's purpose is to embody the current state of the design, and to serve as a medium for interaction among designers and reflection by individual designers. As various authors have noted (e.g., Schön, 1987; Herbert, 1993), designers proceed by representing a design idea in some medium, reflecting on the representation, and then modifying it. Thus, designers may, in an iterative manner, explore the consequences of various design decisions. A second purpose of the working prototype is to elicit feedback from those not on the design team -- either users or other designers in the organization -- thus providing another means of driving the design process.

To be most effective as a medium for interaction, working prototypes should have two properties: accessibility and roughness.

Accessibility
First, the prototype should be accessible. Any member of the design team -- ideally, anyone who has something to contribute to the design whether on the team or not -- should be able to modify it. In traditional design disciplines, such as architecture and graphic design, this accessibility is a given: all members of the discipline are trained in the basic tools and techniques of the trade. In technology design, accessibility is not a given because of the interdisciplinary nature of the process.

In computer-based prototyping, prototyping environments such as HyperCard and Macromind Director come the closest to being fully accessible. They permit members of an interdisciplinary design team to interact on a first class basis: the graphic designer can directly change the graphics; the interaction designer can adjust dialogs and feedback; the computer scientist can add in functionality and access to realistic data. Unfortunately, there are limitations to the types of interaction that can be implemented in these environments. Environments with enough power to support implementation of any kind of desired interaction are usually accessible primarily to programmers; if interaction and visual designers have to have their ideas implemented by programmers, the ability to quickly and iteratively explore multiple design paths is lost.

An alternative is the creation of physical mockups. This is particularly viable in the early stages of design where the goal is to embody very general ideas very quickly. It is also ideal for participatory design situations, in which ordinary users play an integral role in producing the design (Kyng, this volume; Mueller, this volume). Objects such as small computers can be mocked up with foam core and cardboard, and software interfaces can be simulated with stacks of screen drawings, note cards, and post-it notes. For example, mock ups may be taken into the users' environment and used as a props with which the users can, in a sense, perform. Something as simple as a picture of a screen pasted on a piece of foam core (to represent an electronic newspaper on a small computer), can raise interesting issues: for example, the user may enact reading the electronic newspaper at the breakfast table and discover that there is no way of supporting the device at a desirable reading angle, or become concerned about the perils of spilling orange juice into an electronic device.

Physical mockups have a variety of uses in the design process. For example, Mueller, et al. (this volume) and Wirfs-Brock (this volume), describe the use of index cards to elicit a task analysis from users, and to design an object model, respectively. Both note that physicality of the cards -- the ability for anyone to write on them, turn them over, or rearrange them -- seems to play an important role in their utility. Similarly, as Kyng points out, if a drawing that has been taped to the wall comes unstuck and falls off when a user is pointing to it, it is an unimportant matter; but if a computer-based prototype crashes as a user is interacting with it, the event feels very different: it is likely to evoke fervent apologies from the user, and may inhibit the user's future interactions with the prototype.

Roughness
A second useful property of working prototypes is that they should be rough. One definition of roughness is that the conventions of the prototyping medium are relaxed. For example, rough architectural sketches will often discard scale and continuity, focusing solely on the form of building fragments (Herbert, 1993). An alternate definition of roughness is that the prototype shows implicit evidence of the process through which it was created. It is easy to recognize that a drawing with crooked edges and lines that don't entirely meet has been sketched by hand, perhaps because people understand what is easy and what is difficult when drawing.

This sort of roughness is very valuable in working prototypes. First of all, it creates ambiguity. Different designers -- or even the same designer at a later time -- may resolve the ambiguity differently, thus making roughness a source of ideas (Herbert, 1993).

Secondly, roughness leaves openings for discussion of the design. Salomon (1990) and Wong (1992) have observed that omitting a feature from a user interface prototype tends to produce more discussion and ideas than if the feature is present. For example, omitting a text label on a button, or simply leaving out a control mechanism for invoking some type of functionality, can elicit a wide range of alternatives that would be lost if a default label or control mechanism were provided. And Salomon (1990) describes an example from the design of an information system, where providing too much detail too early in the design (a button on the screen that had a 3-D look) seemed to shift discussions from the desired focus on basic functionality to a debate about whether buttons should have a 3-D appearance. Similarly, art directors have told me that one trick of the trade is to prepare a preliminary layout on the computer, and then to put tracing paper over the computer-generated layout and trace the design by hand, giving it 'that hand-done, this-ain't-final-yet look.' Otherwise, they say, when the preliminary computer-generated design is presented, clients are liable to react angrily because the design looks final and they didn't get to provide any input (and this occurs even though they have been told that the design is preliminary).

It also seems likely that roughness decreases the level of commitment to the design. With a rough working prototype designers are less likely to feel like they have ego invested in the prototype, and more open to considering changes. If someone criticizes an idea, it's easy for the designer to discount its seriousness ('oh, I just threw that in as a place holder'). Users, too, are likely to give feedback more readily because they're criticizing something that is obviously rough. A rough prototype has built-in deniability.

Regardless of the reasons roughness is useful, there is some evidence that beginning the refinement stage of design with a rough prototype leads to more satisfactory results. In a study of graphic designers, working either on paper or the computer, those who produced rough early sketches on paper (rather than neat drawings on the screen) were more likely to be satisfied with the final design (Black, 1990).

It is interesting to note that stories seem to have analogs of these properties of roughness. Stories are ambiguous. The same story can be taken to mean many different things. Stories are full of gaps, which different listeners may fill in differently. Stories, also, do not demand commitment: like a rough drawing which is criticized and backed off from, any individual story can be discounted as an exceptional case.

Summary

Although design is often characterized as a process of creating a product, it is also very much a social process in which communication plays a critical role. Designers must communicate both with users, and with the organization of which they are part. The designers must also communicate with one another, no mean task when the team is composed of members from different disciplines.

Material and informational artifacts collected and generated during the design process play a key role in mediating and catalyzing this communication. In particular, I've described some of the ways stories and prototypes address some of the messier issues that arise in design practice:

Problem setting. Collecting stories is a valuable method for the initial exploration of usage domains. Story collection and story making are useful precursors to more formal analyses.

Team building. Both stories and prototypes serve as mechanisms for catalyzing interaction within the team. The processes of collecting stories, making stories, and constructing vision prototypes is one that all team members can participate in. Such activities are a good way of generating team cohesion, and the shared language and understanding which is its foundation.

Involving users. Both stories and prototypes provide a means for involving users in the design process. People who would balk at giving feedback about a design idea, are often perfectly content to tell stories. Similarly prototypes can be used to elicit comments and reactions, or even as props for role playing.

Collaborative design. Prototypes serve as a medium through which the design team can interact, collectively advancing the design. The most effective prototyping environments seem to be both accessible, and to support roughness. Accessibility is important for supporting true collaborative activity, and roughness seems to increase the generation of design alternatives and to lower the resistance to critiques.

Design evangelism and transfer. Designs must be defended and -- if the defense is successful -- passed on to other people in the organization. Both stories and prototypes can be effective tools for quickly and memorably communicating underlying design rationale.

Just as we can produce better products by adapting them to the needs and practices of users, so we can also make the design process more effective by acknowledging the social nature of design, and developing a better understanding of how concrete artifacts support communication in design.

Acknowledgments

Much of my thinking about roughness and its role in design has been influenced by the prototyping techniques developed by Laurie Vertelney and Yin Yin Wong, and by discussions with Yin Yin Wong, S. Joy Mountford, Gitta Salomon and Stephanie Houde, all of the Apple Advanced Technology Human Interface Group. This paper has benefited from comments by John Carroll, Jonathan Grudin, Morton Kyng, and Don Norman.

References

Black, A. Visible Planning on Paper and on Screen: The Impact of Working Medium on Decision-Making by Novice Graphic Designers. Behavior and Information Technology , 1990, 9:4, 283-296.

Brower, E. Knowledge Navigator Draws Fire. MacWeek, December 6, 1988, p 3.

Dubberly, H. & Mitch, D. The Knowledge Navigator. Apple Computer, 1987, video tape.

Grudin, J. Systematic Sources of Suboptimal interface Design in Large Product Development Organizations. Human-Computer Interaction, Vol. 6, 1991a, pp 147-196.

Grudin, J. Interactive Systems: Bridging the Gaps between Developers and Users. IEEE Computer, , Vol 24. New York: ACM Press, 1991b, pp 59-69.

Herbert, D. M. Architectural Study Drawings. New York: Van Nostrand Reinhold, 1993.

Kim, S. Interdisciplinary Collaboration. The Art of Human-Computer Interface Design (ed. B Laurel). Reading, MA: Addison-Wesley, 1990.

Mander, R., Salomon, G. and Wong, Y. Y. A 'Pile' Metaphor for Supporting Casual Organization of Information. Human Factors in Computing Systems: CHI '92 Conference Proceedings. New York: ACM, 1992, pp 627-634.

Norman, D. A. Things That Make Us Smart: Defending Human Attributes in the Age of the Machine . Reading, MA: Addison-Wesley, 1993.

O'Conner, R. J. Apple's View of the Future is Troubling. The San Jose Mercury News, Sunday, November 27, 1988, p 1F.

Salomon, G. How the Look Affects the Feel: Visual Design and the Creation of an Information Kiosk. Proceedings of the Human Factors Society 34th Annual Meeting (Orlando, Florida, October 8-12, 1990), Human Factors Society, Santa Monica, Ca., pp. 277-281.

Schank, R. C. Tell Me a Story: A New Look at Real and Artificial Memory. New York: Charles Scribner's Sons, 1990.

Schön, D. A. Educating the Reflective Practitioner. San Francisco: Jossey-Bass, 1987.

Schrage, M. The Culture of Prototyping. Design Management Journal, Winter, 1993, pp 55-65.

Thimbley, H., Anderson, S., & Witten, I.H. Reflexive CSCW: Supporting Long-Term Personal Work. Interacting with Computers, Vol. 2, #3, 1990, pages 330-336.

Tognazinni, B. The "Starfire" Video Prototype Project: A Case History. In Human Factors in Computing Systems: CHI '94 Conference Proceedings , Reading, MA: Addison-Wesley, 1994, pp 99-105.

Vertelney, L. Using Video to Prototype User Interfaces. SIGCHI Bulletin 21:2, New York: ACM, 1989, pp 57-61.

Wong, Y. Y. Rough and Ready Prototypes: Lessons from Graphic Design. Human Factors in Computing Systems: CHI '92 Conference, Posters and Short Talks, ACM, 1992, pp 83-84.

Wong, Y. Y. Layer Tool: Support for Progressive Design. Human Factors in Computing Systems: CHI '92 Conference, Adjunct Proceedings, ACM, 1993, pp 127-128.

---

* A version of this paper appeared in Scenario-Based Design: Envisioning Work and Technology in System Development. (ed. J. Carroll). New York: Wiley & Sons, 1995.

---