Fresh: pushing the envelope

XII.5 September + October 2005
Page: 10
Digital Citation

If your prototype explodes in the forest, will anyone notice?


Authors:
Fred Sampson

When the scientists and technicians of World War II’s Manhattan Project needed to test their prototype of the atomic bomb, they had to blow it up. The gadget-makers not only had to develop their prototype based on new, untested theories, they had to develop the tools to design, build, and test it on their own. The test succeeded.


prototype, n: an original model on which something is patterned; a standard or typical example; a first full-scale and usually functional form of a new type or design of a construction (as an airplane).—Merriam-Webster’s Online Dictionary (www.m-w.com)

 


Thankfully, most of us do not need to destroy our work to test it, although early iterations often belong in the junk pile. Nor, one would hope, do we have to make up all the tools and techniques for developing prototypes. Not if we share what we already know.

IDEO proclaims that "prototyping is the language of innovation… prototyping lets you fail early and succeed sooner" [3]. Leonardo da Vinci made prototypes. Thomas Alva Edison made prototypes. Edison said: "Just because something doesn’t do what you planned it to do doesn’t mean it’s useless." Do we learn as much from developing the prototype as we do from testing it? Is that how you see prototyping? Do you, the HCI practitioner, develop prototypes as part of your design process? How do you decide on the right approach for your prototype?

Carolyn Snyder, author of Paper Prototyping [4], says that low-fidelity paper prototypes reveal the same problems with software user interfaces as higher-fidelity prototypes [5]. But what if your design depends on more subtlety than the prototype can reveal? Is that a flaw in the prototype, or in the design? Doesn’t it depend on the goal? How do you match the prototype’s characteristics to the goal of making the prototype?

I find no lack of reference material, either research or practical, on prototyping. Much has been written about using a variety of prototyping tools to test designs and perform usability tests. Less is available to the practitioner to guide them in the design and creation of effective prototypes, from choosing the right tool to choosing the right format to building and refining the prototype. But much of the material is several years old, and much of it discusses when and how to use prototyping—for both design and test—without providing guidance on how to design and develop effective prototypes. Do you feel a need for more pragmatic instruction on making prototypes? Are older techniques still valid? We have new tools; are they better?

And how does the audience affect your choice of prototyping tool, style, and fidelity? Hugh Beyer and Karen Holtzblatt say that "most customers have only an unarticulated knowledge of their own work and cannot check a proposed design against their own experience unaided" [1]. Which confirms the observation that users really don’t know (and can’t articulate) what they do, much less how they will respond to a particular situation. Ask them how they will react, it’s one thing; observe them react, it’s another. Do we take this into account when designing and presenting prototypes?

A prototype can be a usability testing tool, or a prototype can be a design tool. As usability professionals move their work closer to product design, do the tools and processes merge? Is there really a distinction between the two? "Prototypes focus detailed requirements gathering" [1]. Don’t we want to gather requirements at the front end instead of letting them emerge at the back end? Should a prototype be an expression of the functional requirements for the project?

How does a prototype’s audience determine the right tool and method? What about audience expectations? Do C-level executives expect a more polished, high-fidelity prototype than designers or users? What about the danger of promoting false expectations with too much information, too much fidelity? Do we run the risk of letting a prototype presentation turn into a demonstration? How does the design affect observer expectations? Fidelity is a measure of how faithful a prototype is, but faithful to what? Faithful to the vision, faithful to the look—and feel—or faithful to the workflow, the interaction, and the results? Do we match prototype style and fidelity to the audience? Have we learned not to include elements that we don’t want the audience to respond to? If they’re distracted by dancing bears, you’ll never get them back on topic. Unless you blow up your prototype—that will get their attention.

The January/February 2006 issue of <interactions> will focus on best practices in creating and designing prototypes, not just in using or testing them. Here’s your chance to contribute to your peers’ knowledge of this useful topic. Contact guest editor Michael Arent with your proposals at michael.arent@sap.com.

References

1. Beyer, H., Holtzblatt, K. Contextual Design. Morgan Kaufmann, 1998.

2. Hackos, J., Redish, J. User and Task Analysis for Interface Design. John Wiley and Sons, 1998.

3. IDEO Web site, www.ideo.com/about/methods/info.asp?x=3

4. Snyder, C. Paper Prototyping. Morgan Kaufmann, 2003.

5. Snyder, C. "Paper Prototyping Grows Up," STC’s 51st Annual Conference, 2004, http://www.stc.org/51stConf/sesMaterials.asp.

Author

Fred Sampson
wfreds@acm.org

About the Author:

Fred Sampson is a co-chair of BayDUX, www.baydux.org, a member of SIGCHI, and a senior member of STC. In his spare time, Fred works as an information developer at IBM’s Silicon Valley Lab in San Jose, California. Contact him at wfreds@acm.org.

©2005 ACM  1072-5220/05/0900  $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 © 2005 ACM, Inc.

 

Post Comment


No Comments Found