9.1.1 You Are Here

We begin each process chapter with a “you are here” picture of the chapter topic in the context of the overall Wheel lifecycle template; see Figure 9-1. This chapter is a continuation of the previous one about designing the new work practice and the new system.

In Chapter 7 we did ideation and sketching and in Chapter 8 we conceptualized design alternatives. Now it is time to make sure that we account for all the requirements and envisioned models in those designs. This is especially important for domain-complex systems where it is necessary to maintain connections to contextual data.

The translation from requirements to design is often regarded as the most difficult step in the UX lifecycle process. We should expect it to be difficult because now that we have made the cognitive shift from analysis-mode thinking to synthesis-mode thinking, there are so many possible choices for design to meet any one given requirement and following requirements does not guarantee an integrated overall solution.

Beyer, Holtzblatt, and Wood (2005, p. 218) remind us that “The design isn’t explicit in the data.” “The data guides, constrains, and suggests directions” that design “can respond to.” The requirements, whether in a requirements document or as an interpretation of the work activity affinity diagram (WAAD), offer a large inventory of things to be supported in the design.

9.2.1 Ideation Iteration

At “A” in Figure 9-2, iteration for ideation and sketching (Chapter 7) is a lightning-fast, loosely structured iteration for the purpose of exploring design ideas. The role of prototype is played by sketches, and the role of evaluation is carried out by brainstorming, discussion, and critiquing. Output is possibly multiple alternatives for conceptual designs, mostly in the form of annotated rough sketches.

9.2.2 Conceptual Design Iteration

At “B” in Figure 9-2, iteration for conceptual design is to evaluate and compare possibly multiple design concepts and weigh concept feasibility. The type of prototype evolves with each successive iteration, roughly from paper prototype to low-fidelity wireframes and storyboards. The type of evaluation here is usually in the form of storytelling via storyboards to key stakeholders. The idea is to communicate how the broader design concepts help users in the envisioned work domain.

Depending on the project context, one or more of the design perspectives may be emphasized in the storyboards. This is usually the stage where key stakeholders such as users or their representatives, business, software engineering, and marketing must be heavily involved. You are planting the seeds for what the entire design will be for the system going forward.

9.2.3 Intermediate Design Iteration

At “C” in Figure 9-2, the purpose of intermediate design (coming up soon) iteration is to sort out possible multiple conceptual design candidates and to arrive at one intermediate design for layout and navigation. For example, for the Ticket Kiosk System, there are at least two conceptual design candidates in the interaction perspective. One is a traditional “drill-in” concept where users are shown available categories (e.g., movies, concerts, MU athletics) from which they choose one. Based on the choice on this first screen, the user is shown further options and details, navigating with a back button and/or “bread crumb” trail, if necessary, to come back to the category view. A second conceptual design is the one using the three-panel idea described in the previous chapter.

Intermediate prototypes might evolve from low-fidelity to high-fidelity or wireframes. Fully interactive high-fidelity mockups can be used as a vehicle to demonstrate leading conceptual design candidates to upper management stakeholders if you need this kind of communication at this stage. Using such wireframes or other types of prototypes, the candidate design concepts are validated and a conceptual design forerunner is selected.

9.2.4 Detailed Design Iteration

At “D” in Figure 9-2, iteration for detailed design is to decide screen design and layout details, including “visual comps” (coming up soon) of the “skin” for look and feel appearance. The prototypes might be detailed wireframes and/or high-fidelity interactive mockups. At this stage, the design will be fully specified with complete descriptions of behavior, look and feel, and information on how all workflows, exception cases, and settings will be handled.

9.2.5 Design Refinement Iteration

At “E” in Figure 9-2, a prototype for refinement evaluation and iteration is usually medium to high fidelity and evaluation is either a rapid method (Chapter 13) or a full rigorous evaluation process (Chapters 12 and 14 through 18).

9.3.1 Unpacking the Conceptual Design: Strategies for Realization

At “C” in Figure 9-2, you are taking the concepts created in conceptual design, decomposing them into logical units, and expanding each unit into different possible design strategies (corresponding to different conceptual design candidates) for concept realization. Eventually you will decide on a design strategy, from which spring an iterated and evaluated intermediate prototype.

9.3.2 Ground Your Design in Application Ontology with Information Objects

Per Johnson and Henderson (2002, p. 27), you should begin by thinking in terms of the ontological structure of the system, which will now be available in analyzed and structured contextual data. This starts with what we call information objects that we identified in modeling (Chapter 6).

As these information objects move within the envisioned flow model, they are accessed and manipulated by people in work roles. In a graphics-drawing application, for example, information objects might be rectangles, circles, and other graphical objects that are created, modified, and combined by users.

Identify relationships among the application objects—sometimes hierarchical, sometimes temporal, sometimes involving user workflow. With the help of your physical model, cast your ontological net broadly enough to identify other kinds of related objects, for example, telephones and train tickets, and their physical manipulation as done in conjunction with system operation.

In design we also have to think about how users access information objects; from the user perspective, accessing usually means getting an object on the screen so that it can be operated on in some way. Then we have to think about what kinds of operations or manipulation will be performed.

For example, in the Ticket Kiosk System, events and tickets are important information objects. Start by thinking about how these can be represented in the design. What are the best design patterns to show an event? What are the design strategies to facilitate ways to manipulate them?

In your modeling you should have already identified information objects, their attributes, and relationships among them. In your conceptual design and later in intermediate design, you should already have decided how information objects will be represented in the user interaction design. Now you can decide how users get at, or access, these information objects.

Typically, because systems are too large and complex to show all information objects on the screen at once initially, how do your users call up a specific information object to operate on it? Think about information seeking, including browsing and searching.

Decide what operations users will carry out on your information objects. For example, a graphics package would have an operation to create a new rectangle object and operations to change its size, location, color, etc. Think about how users will invoke and perform those operations.

Add these new things to your storyboards. The design of information object operations goes hand in hand with design scenarios (Chapter 6), personas (Chapter 7), and storyboards (Chapter 8), which can add life to the static wireframe images of screens.

9.3.3 Illustrated Scenarios for Communicating Designs

One of the best ways to describe parts of your intermediate interaction design in a document is through illustrated scenarios, which combine the visual communication capability of storyboards and screen sketches with the capability of textual scenarios to communicate details. The result is an excellent vehicle for sharing and communicating designs to the rest of the team, and to management, marketing, and all other stakeholders.

Making illustrated scenarios is simple; just intersperse graphical storyboard frames and/or screen sketches as figures in the appropriate places to illustrate the narrative text of a design scenario. The storyboards in initial illustrated scenarios can be sketches or early wireframes (coming up later).

9.3.4 Screen Layout and Navigational Structure

During this phase, all layout and navigation elements are fully fleshed out. Using sequences of wireframes, key workflows are represented while describing what happens when the user interacts with the different user interface objects in the design. It is not uncommon to have wireframe sets represent part of the workflow or each task sequence using click-through prototypes.

9.4.1 Annotated Wireframes

To iterate and evaluate your detailed designs, refine your wireframes more completely by including all user interface objects and data elements, still represented abstractly but annotated with call-out text.

9.4.2 Visual Design and Visual Comps

As a parallel activity, a visual designer who has been involved in ideation, sketching, and conceptual design now produces what we call visual “comps,” meaning variously comprehensive or composite layout (a term originating in the printing industry). All user interface elements are represented, now with a very specific and detailed graphical look and feel.

A visual comp is a pixel-perfect mockup of the graphical “skin,” including objects, colors, sizes, shapes, fonts, spacing, and location, plus visual “assets” for user interface elements. An asset is a visual element along with all of its defining characteristics as expressed in style definitions such as cascading style sheets for a Website. The visual designer casts all of this to be consistent with company branding, style guides, and best practices in visual design.

9.5.1 What Are Wireframes?

Wireframes, a major bread-and-butter tool of interaction designers, are a form of prototype, popular in industry practice. Wireframes comprise lines and outlines (hence the name “wire frame”) of boxes and other shapes to represent emerging interaction designs. They are schematic diagrams and “sketches” that define a Web page or screen content and navigational flow. They are used to illustrate high-level concepts, approximate visual layout, behavior, and sometimes even look and feel for an interaction design. Wireframes are embodiments of maps of screen or other state transitions during usage, depicting envisioned task flows in terms of user actions on user interface objects.

The drawing aspects of wireframes are often simple, offering mainly the use of rectangular objects that can be labeled, moved, and resized. Text and graphics representing content and data in the design is placed in those objects. Drawing templates, or stencils, are used to provide quick means to represent the more common kinds of user interface objects (more on this in the following sections).

Wireframes are often deliberately unfinished looking; during early stages of design they may not even be to scale. They usually do not contain much visual content, such as finished graphics, colors, or font choices. The idea is to create design representations quickly and inexpensively by just drawing boxes, lines, and other shapes.

As an example of using wireframes to illustrate high-level conceptual designs, see Figure 9-4. The design concept depicted in this figure is comprised of a three-column pattern for a photo manipulation application. A primary navigation pane (the “nav bar”) on the left-hand side is intended to show a list of all the user’s photo collections. The center column is the main content display area for details, thumbnail images and individual photos, from the collection selected in the left pane.

The column on the right in Figure 9-4 is envisioned to show related contextual information for the selected collection. Note how a simple wireframe using just boxes, lines, and a little text can be effective in describing a broad interaction conceptual design pattern. Often these kinds of patterns are explored during ideation and sketching, and selected sketches are translated into wireframes.

While wireframes can be used to illustrate high-level ideas, they are used more commonly to illustrate medium-fidelity interaction designs. For example, the idea of Figure 9-4 is elaborated further in Figure 9-5. The navigation bar in the left column now shows several picture collections and a default “work bench” where all uploaded images are collected. The selected item in this column, “Italy trip,” is shown as the active collection using another box with the same label and a fill color of gray, for example, overlaid on the navigation bar. The center content area is also elaborated more using boxes and a few icons to show a scrollable grid of thumbnail images with some controls on the top right. Note how certain details pertaining to the different manipulation options are left incomplete while showing where they are located on the screen.

Wireframes can also be used to show behavior. For example, in Figure 9-6 we show what happens when a user clicks on the vertical “Related information” bar in Figure 9-5: a pane with contextual information for this collection (or individual photo) slides out. In Figure 9-7 we show a different view of the content pane, this time as a result of a user clicking on the “One-up” view switcher button in Figure 9-5 to see a single photo in the context pane. Double-clicking a thumbnail image will also expand that image into a one-up view to fill the content pane.

9.5.2 How Are Wireframes Used?

Wireframes are used as conversational props to discuss designs and design alternatives. They are effective tools to elicit feedback from potential users and other stakeholders. A designer can move through a deck of wireframes one slide at a time, simulating a potential scenario by pretending to click on interaction widgets on the screen. These page sequences can represent the flow of user activity within a scenario, but cannot show all possible navigational paths.

For example, if Figures 9-5, 9-6, and 9-7 are in a deck, a designer can narrate a design scenario where user actions cause the deck to progress through the corresponding images. Such wireframes can be used for rapid and early lab-based evaluation by printing and converting them into low-fidelity paper prototypes (Chapter 11). A rough low- to medium-fidelity prototype, using screens like the ones shown in Figures 9-5, 9-6, and 9-7, can also be used for design walkthroughs and expert evaluations. In the course of such an evaluation, the expert can extrapolate intermediate states between wireframes.

What we have described so far is easy to do with almost all wireframing tools. Most wireframing tools also provide hyperlinking capabilities to make the deck a click-through prototype. While this takes more effort to create, and even more to maintain as the deck changes, it provides a more realistic representation of the envisioned behavior of the design. However, the use of this kind of prototype in an evaluation might require elaborating all the states of the design in the workflow that is the focus of the evaluation.

Finally, after the design ideas are iterated and agreed upon by relevant stakeholders, wireframes can be used as interaction design specifications. When wireframes are used as inputs to design production, they are annotated with details to describe the different states of the design and widgets, including mouse-over states, keyboard inputs, and active focus states. Edge cases and transition effects are also described. The goal here is completeness, to enable a developer to implement the designs without the need for any interpretation. Such specifications are usually accompanied by high-fidelity visual comps, discussed previously in this chapter.

9.5.3 How to Build Wireframes?

Wireframes can be built using any drawing or word processing software package that supports creating and manipulating shapes, such as iWork Pages, Keynote, Microsoft PowerPoint, or Word. While such applications suffice for simple wireframing, we recommend tools designed specifically for this purpose, such as OmniGraffle (for Mac), Microsoft Visio (for PC), and Adobe InDesign.

Many tools and templates for making wireframes are used in combination—truly an invent-as-you-go approach serving the specific needs of prototyping. For example, some tools are available to combine the generic-looking placeholders in wireframes with more detailed mockups of some screens or parts of screens. In essence they allow you to add color, graphics, and real fonts, as well as representations of real content, to the wireframe scaffolding structure.

In early stages of design, during ideation and sketching, you started with thinking about the high-level conceptual design. It makes sense to start with that here, too, first by wireframing the design concept and then by going top down to address major parts of the concept. Identify the interaction conceptual design using boxes with labels, as shown in Figure 9-4.

Take each box and start fleshing out the design details. What are the different kinds of interaction needed to support each part of the design, and what kinds of widgets work best in each case? What are the best ways to lay them out? Think about relationships among the widgets and any data that need to go with them. Leverage design patterns, metaphors, and other ideas and concepts from the work domain ontology. Do not spend too much time with exact locations of these widgets or on their alignment yet. Such refinement will come in later iterations after all the key elements of the design are represented.

As you flesh out all the major areas in the design, be mindful of the information architecture on the screen. Make sure the wireframes convey that inherent information architecture. For example, do elements on the screen follow a logical information hierarchy? Are related elements on the screen positioned in such a way that those relationships are evident? Are content areas indented appropriately? Are margins and indents communicating the hierarchy of the content in the screen?

Next it is time to think about sequencing. If you are representing a workflow, start with the “wake-up” state for that workflow. Then make a wireframe representing the next state, for example, to show the result of a user action such as clicking on a button. In Figure 9-6 we showed what happens when a user clicks on the “Related information” expander widget. In Figure 9-7 we showed what happens if the user clicks on the “One-up” view switcher button.

Once you create the key screens to depict the workflow, it is time to review and refine each screen. Start by specifying all the options that go on the screen (even those not related to this workflow). For example, if you have a toolbar, what are all the options that go into that toolbar? What are all the buttons, view switchers, window controllers (e.g., scrollbars), and so on that need to go on the screen? At this time you are looking at scalability of your design. Is the design pattern and layout still working after you add all the widgets that need to go on this screen?

Think of cases when the windows or other container elements such as navigation bars in the design are resized or when different data elements that need to be supported are larger than shown in the wireframe. For example, in Figures 9-5 and 9-6, what must happen if the number of photo collections is greater than what fits in the default size of that container? Should the entire page scroll or should new scrollbars appear on the left-hand navigation bar alone? How about situations where the number of people identified in a collection are large? Should we show the first few (perhaps ones with most number of associated photos) with a “more” option, should we use an independent scrollbar for that pane, or should we scroll the entire page? You may want to make wireframes for such edge cases; remember they are less expensive and easier to do using boxes and lines than in code.

As you iterate your wireframes, refine them further, increasing the fidelity of the deck. Think about proportions, alignments, spacing, and so on for all the widgets. Refine the wording and language aspects of the design. Get the wireframe as close to the envisioned design as possible within the constraints of using boxes and lines.

9.5.4 Hints and Tips for Wireframing

Because the point of wireframing is to make quick prototypes for exploring design ideas, one of the most important things to remember about wireframing is modularity. Just as in paper prototyping, you want to be able to create multiple design representations quickly.

Being modular means not having too many concepts or details “hard coded” in any one wireframe. Build up concepts and details using “layers.” Most good wireframing tools provide support for layers that can be used to abstract related design elements into reusable groups. Use a separate layer for each repeating set of widgets on the screen. For example, the container “window” of the application with its different controls can be specified once as a layer and this layer can be reused in all subsequent screens that use that window control.

Similarly, if there is a navigation area that is not going to change in this wireframe deck, for example, the left-hand collections pane in Figure 9-5, use one shared layer for that. Layers can be stacked upon one another to construct a slide. This stacking also provides support for ordering in the Z axis to show overlapping widgets. Selection highlights, for example, showing that “Italy trip” is the currently selected collection in Figure 9-5, can also created using a separate “highlight” layer.

Another tip for efficient wireframing is to use stencils, templates, and libraries of widgets. Good wireframing tools often have a strong community following of users who share wireframing stencils and libraries for most popular domains—for example, for interaction design—and platforms—for example, Web, Apple iOS, Google’s Android, Microsoft’s Windows, and Apple’s Macintosh. Using these libraries, wireframing becomes as easy as dragging and dropping different widgets onto layers on a canvas.

Create your own stencil if your design is geared toward a proprietary platform or system. Start with your organization’s style guide and build a library of all common design patterns and elements. Apart from efficiency, stencils and libraries afford consistency in wireframing.

Some advanced wireframing tools even provide support for shared objects in a library. When these objects are modified, it is possible to automatically update all instances of those objects in all linked wireframe decks. This makes maintenance and updates to wireframes easier.

9.6.1 What Is a Custom Style Guide?

A custom style guide is a document that is fashioned and maintained by designers to capture and describe details of visual and other general design decisions that can be applied in multiple places. Its contents can be specific to one project or an umbrella guide across all projects on a given platform or over a whole organization.

A custom style guide is a kind of internal documentation integral to the design process. Every project needs one. Your custom style guide documents all the design decisions you make about style issues in your interaction design, especially your screen designs.

Because your design decisions continue to be made throughout the project and because you sometimes change your mind about design decisions, the custom style guide is a living document that grows and is refined along with the design. Typically this document is private to the project team and is used only internally within the development organization.

Although style guides and design guidelines (Chapter 22) both give guidance for design, they are otherwise almost exact opposites. Guidelines are usually suggestions to be interpreted; compliance with style guides is often required.

Guidelines are very general and broad in their applicability and usually independent of implementation platforms and interaction styles. Style guides are usually very specific to a platform and interaction style and even to a particular device.

9.6.2 Why Use a Custom Style Guide?

Among the reasons for designers to use a custom style guide within a project are:

9.6.3 What to Put in a Custom Style Guide?

Your custom style guide should include all the kinds of user interface objects where your organization cares the most about consistency (Meads, 2010). Most style guides are very detailed, spelling out the parameters of graphic layouts and grids, including the size, location, and spacing of user interface elements. This includes widget (e.g., dialogue boxes, menus, message windows, toolbars) usage, position, and design. Also important are the layouts of forms, including the fields, their formatting, and their location on forms.

Your style guide is the appropriate place to standardize fonts, color schemes, background graphics, and other common design elements. Other elements of a style guide include interaction procedures, interaction styles, message and dialogue fonts, text styles and tone, labeling standards, vocabulary control for terminology and message wording, and schemes for deciding how to use defaults and what defaults to use. It should be worded very specifically, and you should spell out interpretations and conditions of applicability.

You should include as many sample design sketches and pictures taken from designs on screens as possible to make it communicate visually. Supplement with clear explanatory text. Incorporate lots of examples of good and bad design, including specific examples of UX problems found in evaluation related to style guide violations.

Your style guide is also an excellent place to catalog design “patterns” (Borchers, 2001), your “standard” ways of constructing menus, icons, dialogue boxes, and so on. Perhaps one of the most important parts of a style guide are rules for organizational signature elements for branding.

9.7.1 What Is an Interaction Design Specification?

Interaction design specifications are descriptions of user interface look and feel and behavior at a level of completeness that will allow a software programmer to implement it precisely.

Discussions of “specifications” often lead to a diversity of strongly felt opinions. By definition, a specification is a complete and correct description of something. Specifications play an indispensable role in software engineering. However, because it is difficult or impossible to construct complete and correct descriptions of large complex systems, it is not uncommon to find incomplete and ambiguous specifications in the software development world. Also, there are no standards for interaction design specifications.

As a result, this connection between the two domains persists as one of the great mysteries in the trade, one of the things people on both sides seem to know the least about. In each organization, people in project roles on both sides figure out their own ways to handle this communication, to varying degrees of effectiveness, but there is no one general or broadly shared approach. See Chapter 23 for a more in-depth discussion about this communication problem.

In human–computer interaction (HCI), some argue that it is not practical to create a design specification because as soon as they invest the effort, the specification is more or less rendered useless by changes in the design due to our iterative lifecycle concept. However, there is no reason that a design specification cannot be just as dynamic as the design itself. In fact, a series of versions of a design specification can be valuable in tracking the trajectory of the evolving design and as a way to reflect on the process. In addition, by maintaining the interaction design specifications as the design progresses, it is possible to give the SE team periodic previews, avoiding surprises at the end.

9.7.2 Why Should We Care about Interaction Design Specifications?

Well, when we have devoted our resources to design and iterative refinement of the interaction part of a system, we would really like to get that design into the software of the system itself. To do that, we have to tell the SE people, the ones who will implement our designs, what to build for the interaction part. The user interaction design on the UX side becomes the user interface software requirements for the user interface software design on the SE side.

In simple terms, we UX folks need a design representation because the SE folks need a requirements specification for the user interface software. You want it to be a very specific specification so there is no room for the SE people to do interaction design on their own.

Without some kind of interaction design specifications, the software result could be almost anything. However, in practice, it is prohibitively expensive to produce specifications that are “complete.” Designers usually infuse enough graphical and textual details for a programmer to understand design intent, and issues that are not clear in the specification are handled on the social back channels. If programmers are part of the process early on, they will have a better understanding on the design as it evolved and therefore have less need for explanations outside of the specification.

9.7.3 What about Using a Prototype as a Design Specification?

The case for prototypes as interaction design representations is built on the fact that prototypes already exist naturally as concrete, living design representations. Abstract textual design specifications do not lend themselves to visualization of the design, whereas a prototype can be “touched” and manipulated to examine the design in action. Plus, prototypes capture all that design detail in a way that no descriptive kind of representation can.

It is especially easy to view an iteratively refined and relatively complete high-fidelity prototype as a wonderfully rich and natural way to represent an interaction design. And it looks even better when compared to the enormous, tedious, and cumbersome additional task of writing a complete specification document describing the same design in text. For example, just one dialogue box in an interaction would typically require voluminous narrative text, including declarative definitions of all objects and their attributes. The resulting long litany of descriptor attributes and values, which when read (or if read), would fail to convey the simple idea conveyed by seeing and “trying” the dialogue box itself.

However, while prototypes make for good demonstrations of the design, they are not effective as reference documents. A prototype cannot be “searched” to find where a specific design point or requirement is addressed. A prototype does not have an “index” with which to look up specific concepts. A prototype cannot be treated as a list of features to be implemented. Some say there is no substitute for having a formal document that spells everything out and that can be used to resolve arguments and answer questions about the requirements.

Also, some prototypes are not complete or even 100% accurate in all details. Taken as a specification, this kind of prototype does not reveal which parts are incomplete or only representative.

A prototype requires interpretation as a specification. There is still a great deal about a dialogue box, for example, not necessarily conveyed by a picture. Is it every detail that you see, including the text on the labels, the font and colors, and so on? For example, is the font size of a particular button label within a complicated dialogue box the exact font style and size that shall be used or just something used because they had to use some font. It does not say. Of course, the more high fidelity it is, the more literally it is to be taken, but the dividing line is not always explicit.

9.7.4 Multiple, Overlapping Representation Techniques as a Possible Solution

Because no single representation technique serves all purposes as a interaction design specification, we must do our best to compile sets of representations to include as much of the interaction design as possible. In the current state of the art this can mean coalescing descriptions in multiple and sometimes overlapping dimensions, each of which requires a different kind of representation technique.

These multiple descriptions come from the many work products that have evolved in parallel as we moved through the formulation of requirements and early design-informing models (Chapter 6), including hierarchical task inventory (HTI) diagrams, usage scenarios, screen designs, user interface object details (graphical user interface objects, not the OO software kind), wireframes, lists of pull-down menu options, commands, dialogue boxes, messages, and behaviors, and of course the prototype.

9.8.1 Basics of Participatory Design

At the very beginning of a design project, you often have the user and customers on one side and system designers on the other. Participatory design is a way to combine the knowledge of work practice of the users and customers with the process skills of system designers.

It is interesting that although participatory design has a lot in common with, including its origins, contextual inquiry and contextual analysis, many applications of participatory design have been in the absence of upfront contextual inquiry or contextual analysis processes. Regardless of how it gets started, many design teams end up realizing that although participatory design is a good way to get at real user needs by involving users in design, it is not a substitute for involving users in defining requirements, the objective of contextual inquiry and contextual analysis.

A participatory design session usually starts with reciprocal learning in which the users and the designers learn about each others’ roles; designers learn about work practices and users learn about technical constraints (Carmel, Whitaker, & George, 1993). The session itself is a democratic process. Rank or job title has no effect; anyone can post a new design idea or change an existing feature. Only positive and supportive attitudes are tolerated. No one can criticize or attack another person or their ideas. This leads to an atmosphere of freedom to express even the farthest out ideas; creativity rules.

In our own experience, we have found participatory design very effective for specific kinds of interaction situations. For example, we think it could be a good approach, especially if used in conjunction with design scenarios, to sketching out the first few levels of screens of the Ticket Kiosk System interaction. These first screens are very important to the user experience, where first impressions formed by users and where we can least afford to have users get lost and customers turn away. However, in our experience, the technique sometimes does not scale up well to complete designs of large and complex systems.

9.8.2 PICTIVE²—An Example of an Approach to Participatory Design

Inspired by the mockup methods of the Scandinavian project called UTOPIA (Bødker et al., 1987), which provided opportunities for workers to give inputs to workplace technology and organizational work practices, PICTIVE (Muller, 1991; Muller, Wildman, & White, 1993) is an example of how participatory design has been operationalized in HCI. PICTIVE supports rapid group prototype design using paper and pencil and other “low technology” materials on a large table top in combination with video recording.

The objective is for the group to work together to find technological design solutions to support work practice and, sometimes, to redesign the work practice in the process. Video recording is used to chronicle and communicate the design process and to record walkthroughs used to summarize the designs.

PICTIVE is, as are most participatory design approaches, a hands-on design-by-doing technique using low-tech tools, such as those used for paper prototyping: blackboards, large sheets of paper, bulletin boards, push pins, Post-it notes, colored marking pens, index cards, scissors, and tape. PICTIVE deliberately uses these low-tech (noncomputer, nonsoftware) representations to level the playing field between users and technical design team members. Otherwise using even the most primitive programming tools for building prototypes on the fly can cast the users as outsiders and the design practitioners as intermediaries through whom all user ideas must flow. It then is no longer a collaborative storytelling activity.

After the mutual introduction to each others’ backgrounds and perspectives, the group typically discusses the task at hand and the design objectives to get on the same page for doing the design. Then they gather around a table on which there is a large paper representation of a generic computer “window.” Anyone can step forward and “post” a design feature, for example, button, icon, menu, dialogue box, or message, by writing or drawing it on a Post-it note or similar piece of paper, sticking it on the “window” working space, and explaining the rationale. The group can then discuss refinements and improvements. Someone else can edit the text on the object, for example, and change its location in the window.

The group works collaboratively to expand and modify, adding new objects, changing objects, and moving objects to create new layouts and groupings and changing wording of labels and messages, and so on, all the while communicating their thinking and reasons behind each change. The results can be evaluated immediately as low-fidelity prototypes with walkthroughs (usually recorded as video for further sharing and evaluation). In most project environments that use this kind of participatory design, it is often used in the consultative design mode, where users participate in forming parts of the design but the professional design practitioners have the final responsibility for the overall design.

PICTIVE has been evaluated informally in the context of several real product design projects (Muller, 1992). User participants report getting enjoyment from the process and great satisfaction in having a receptive audience for their own design ideas and, especially, in seeing those design ideas included in the group’s output.

9.8.3 History and Origins

Participatory design entails user participation in design for work practice. Participatory design is a democratic process for design (social and technological) of systems involving human work, based on the argument that users should be involved in designs they will be using, and that all stakeholders, including and especially users, have equal inputs into interaction design (Muller & Kuhn, 1993).

The idea of user participation in system design harkens back (as does the work on contextual studies) at least to a body of effort called work activity theory (Bødker, 1991; Ehn, 1990). Originating in Russia and Germany, it flourished in Scandinavia in the 1980s where it was closely related to the workplace democracy movement. These early versions of participatory design embraced a view of design based on work practice situated in a worker’s own complete environment, but also espoused empowerment of workers to “codetermine the development of the information system and of their workplace” (Clement & Besselaar, 1993).

Going back to the 1980s and earlier, probably the most well-known participatory design project was the Scandinavian project called UTOPIA (Bødker et al., 1987). A main goal of Project UTOPIA was to overcome limitations on opportunities for workers to affect workplace technology and organizational work practices. UTOPIA was one of the first such projects intended to produce a commercial product at the end of the day.

Participatory design has been practiced in many different forms with different rules of engagement. In some projects, participatory design limits user power to creating only inputs for the professional designers to consider, an approach called consultative design by Mumford (1981). Other approaches give the users full power to share in the responsibility for the final outcome, in what Mumford calls consensus design.

Also beginning in the 1970s and 1980s, an approach to user involvement in design (but probably developed apart from the participatory design history in Scandinavia) called Joint Application Design was emerging from IBM in the United States and Canada (August 1991). Joint Application Design falls between consultative design and consensus design in the category of representative design (Mumford, 1981), a commonly used approach in industry in which user representatives become official members of the design teams, often for the duration of the project. In comparison with participatory design, Joint Application Design is often a bit more about group dynamics, brainstorming, and organized group meetings.

In the early 1990s, the Scandinavian approach to democratic design was adapted and extended within the HCI community in the form of participatory design. Muller’s (1991) vision of participatory design as embodied in his PICTIVE approach is the most well-known adaptation of the general concept specifically to HCI. The first Participatory Design Conference met in 1990 and it has been held biannually ever since. Participatory design has since been codified for practice (Greenbaum & Kyng, 1991), reviewed (Clement & Besselaar, 1993), and summarized (Muller, 2003a,b).