The art of prototyping

XIII.1 January + February 2006
Page: 18
Digital Citation

Presumptive design, or cutting the looking-glass cake

Leo Frishberg

back to top 

In the generally accepted approach to User Centered Design (UCD), the designer/investigator researches the needs of the target population, analyzes and transforms the raw data, and then synthesizes a solution ultimately reviewed by users who determine its fitness. Reducing the "gap" between the analysis and synthesis steps is key to improving the outcome of design activities [2].

In Lewis Carroll's Through the Looking Glass Alice faces a puzzling and paradoxical approach to serving cake [1]. A process I call Presumptive Design turns the traditional practice of UCD upside down in a similarly paradoxical way. The designer, with minimum input about the requirements for the project, creates a set of solutions, puts them in front of the target user, collects data about the fitness of the designs, and then performs analysis that feeds into an iterative cycle.


Presumptive Design is based on five principles:

  • Design for failure—expect your solutions to always be off-target
  • Create, discover, analyze—create your ideas first, let users show you your errors, analyze for the next round
  • Make assumptions explicit—embrace your human egocentricism by explicitly exposing your assumptions to your end users and having them react
  • The faster you go, the sooner you know—do all of these things quickly to learn how wrong you are sooner
  • Iterate, iterate, iterate—do this process as long as your stamina and budget provide

Each of these principles establishes a frame of mind about the proposed solutions that keeps the designer open to the needs of the user. The process is especially effective with small cross-functional teams facing limited time frames because it elicits two responses simultaneously: reaction to the specific design solution and expression of user requirements.

Rapid prototyping is fundamental to presumptive design as it provides an effective means of quickly expressing the design team's assumptions and intentions. Users' reaction to artifacts simultaneously uncovers their requirements while exposing the team's biases.

back to top  Risks

The method is not without risks. Listed below are some of the common risks that, while not unique to presumptive design, are more likely to occur because of prioritizing synthesis over analysis.

Believing the solution is correct. Accepting a solution because it "feels right," being blinded by your creation, and/or defending the solution to the customer, sabotages the process. In presumptive design, you always believe you're wrong; remembering this principle reduces this risk.

Focus on the wrong solution. Because this approach is "inductive"—you create an example of an idea—you can't know from the outset whether you are on the right track. Rapid prototyping generally creates unattractive artifacts, creating a natural feedback loop that helps reduce the team's faith in the design.

Lack of solution coverage. Design resources are a precious commodity; using them to develop one solution reduces their availability for investigating alternative solutions. Here, too, rapid prototyping quickly creates widely variant solutions, improving coverage of the "solution space."

Loss of User Focus. Users may react to elements in the solution that were either unintended or not yet developed. An object implies much more than the minimum inputs used to create it. This risk can only be mitigated through experienced facilitation, often requiring a multidisciplinary team. Low-resolution prototypes raise user questions that the designer had not anticipated. Messy prototypes are likely to distract the user from your objectives; they are equally likely to provide opportunities for conversation. Having a cross-functional team with experienced designers and usability professionals is a key component of the presumptive-design process.

back to top  Testing the Process

Twice recently—at the CHI2004|ICSID Forum and SEC05 (see the following article by Nancy Frishberg)—I had the opportunity to explore whether presumptive design was idiosyncratic to my practice or one shared among professionals. In the first event, we presumed that the experience level of the participants would lead some teams to use presumptive design; in the second event, presumptive design was explicitly required.

back to top  Lessons Learned

We learned several lessons from these two events:

• Even designers with more than ten years' experience don't use presumptive design approaches. We were surprised to see that only one individual from one team at the CHI2004|ICSID Forum brought a model for users to react to.

• Industrial designers (IDs) are more likely than interaction designers (IxDs) (and non-designers) to engage in presumptive-design behaviors. During the "analysis" phase, IDs sketched, prototyped, and played around, while IxDs made lists, drew charts, categorized, and analyzed.

• Interaction designers and usability professionals (regardless of years of experience) prefer to present rough prototypes to users rather than allow users to engage directly with the artifact. At SEC05, none of the teams provided users with prototypes, opting instead to present, explain, demo, or defend their designs.

• Inexperienced designers, and those from related disciplines, expressed fear about exposing their assumptions so directly to users.

• Participants (at all levels of experience) were able to rapidly create prototypes that expressed the key assumptions underlying their designs. All teams successfully created prototypes in time for their presentations to the group.

back to top  Conclusions

Presumptive design, or serving the cake before you slice it, is a powerful way for designers to make their assumptions explicit while providing customers opportunities for rich engagement and feedback. The approach can accelerate the data-gathering process at the same time it builds multidisciplinary teams. Some conclusions drawn from the two workshops helped broaden my appreciation for the pros and cons of the approach.

Users respond more intensely to objects than they do to questions. At the CHI2004|ICSID Forum, users demonstrated the advantages and disadvantages of their own artifacts. At SEC05, users surprised the teams with their (generally intensely negative) responses to the prototypes.

Building junk prototypes helps illustrate assumptions quickly. Both groups created objects that revealed their assumptions, whether or not they used the artifacts to elicit user feedback. Teams with less-experienced designers had greater difficulty shifting from analysis to synthesis, suggesting that design experience is a key component in building artifacts.

Facilitating user interaction with junk prototypes is necessary and challenging. Users, especially the active seniors in our case, are comfortable responding negatively to proposed solutions. Low-resolution prototypes challenged teams to elicit constructive user feedback; real products were much easier for users to discuss positively. Teams with experienced usability professionals skilled in eliciting user feedback will be more successful than those without.

Prototypes must be designed. With its reliance on low-cost materials and rapid turn-around, presumptive design requires experienced designers. The presumptive designer must carefully consider the desired attributes of product, the specific characteristics of the prototype object, the objectives of the session, and the anticipated interactions during the feedback sessions.

Presumptive design is not for the faint of heart. Putting your assumptions in front of users can be a frightening prospect. In addition, the presumptive designer must be comfortable synthesizing quickly while simultaneously remaining uninvested in the result.

Presumptive design, by its reliance on rapid prototyping, is a fast way to find out how wrong you are and what users really want. The process permits multidisciplinary teams to work quickly and collaboratively. It exposes designers' assumptions for review by target populations while allowing analysts opportunities to capture users' reactions and implicit requirements.

back to top  References

1. Carroll, Lewis, Through the Looking-Glass and What Alice Found There, The MacMilllan Company, New York, London, 1899, p152

2. Wood, L. A., User Interface Design, Bridging the Gap from User Requirements to Design, CRC Press, 1997.

back to top  Author

Leo Frishberg
Tektronix, Inc.

About the Author:

Leo Frishberg is a user experience architect for Tektronix, Inc.'s Logic Analyzer Advanced Development Group. For over 20 years, Frishberg's professional life has focused on enhancing the user experience with architectural, software, hardware, and Web projects. For the past five years, Frishberg has served as both program chair and executive director for CHIFOO (Computer Human Interaction Forum of Oregon), the Portland-based local chapter of the SIGCHI. Frishberg is a licensed architect, with an M.Arch from SCI-ARC and a BA in Environmental Planning from the University of California, Santa Cruz. Nancy Frishberg is his sister.

back to top  Figures

UF1Figure. "You don't know how to manage Looking-glass cakes," the Unicorn remarked. Hand it round first, and cut it afterwards."

back to top 

©2006 ACM  1072-5220/06/0100  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2006 ACM, Inc.

Post Comment

No Comments Found