Over 20 years ago Dr. James Wilson and I drafted "Rapid Prototyping for User Interface Design," one of many landmark chapters in the first Handbook of Human Computer Interaction . Our approach was based on pioneering work taking place at the human factors laboratory of Eastman Kodak, where we were both staff members. No single individual can claim invention of this approach, as the original chapter bibliography demonstrates. There was much co-invention and simultaneous discovery during these early days in the emergence of HCI as a unique field. What Jim and I did have, in hindsight, was the opportunity to perform a complete survey of the field in the mid-1980s, as well as highlight our own approach to UI prototyping. We also presented workshops on this topic at many conferences for over a decade, including several CHI conferences, HFES, and several mainstream computer science conference series.
Our approach was a natural outgrowth of the human factors labs incorporation within Eastman Kodak's industrial design department. Within this department we were surrounded by physical product models of various scales and fidelity on a daily basis. It seemed natural to carry this design tradition into the world of software as our jobs evolved from designing hard control panels for photocopiers to soft ones implemented on simple CRTs. In addition the notions of iterative design and user testing were also part of the departmental culture. Kodak's Human Factors team was famous for its Christmas tree lab, probably the first usability lab used for testing consumer products. Test participants were brought into this lab to evaluate new camera designs. Each experiment started by selecting a gift-wrapped box from under the tree in a simulated living room environment.
This special edition of <interactions> provides a welcome opportunity to see how far we have come in two decades and also evaluate which of our original goals have not yet been achieved.
The original handbook chapter was introduced with a quote from the architect Robert Graves calling all prototypes and models a form of tangible speculation . After 20 years this remains true. Building prototypes remains the lingua franca of all design professions. While the tools we use have advanced, UI prototyping remains the most effective way to gather requirements, communicate concepts, and evaluate usability in a cost-effective manner.
There were many benefits ascribed to this new approach at the time. They were identified as follows:
provides a means for testing product-specific questions that cannot be answered by generic research or guidelines
provides tangible means of evaluating a given UI concept
provides a common reference point for all members of the design team, users, and marketing
allows the solicitation of meaningful feedback from users
improves the quality and completeness of a product's functional specifications
increases the probability that the product will perform as expected
substantially reduces the total development cost for a product
However the discussion in the original chapter on the "politics" of prototyping contained just a foreshadowing of the difficult relationship that the newly defined profession of "dialog designers" would experience with existing marketing departments. Three drawbacks were also articulated from our experience. These were:
limitations and constraints that apply to the real product can be ignored
a prototype can be oversold, creating false expectations
the prototyping process may be difficult to manage and control
In fact this last point is reflected in the recent <interactions> special issue on "who owns the user experience" . With the tools and technical skill required to create UI prototypes becoming ubiquitous, the process has only become harder to control. It is common these days to see unsolicited user interface prototypes emerge from both marketing and development departments. Technology may change, but organizational politics are immutable.
Two specific macro trends have changed the nature of prototyping and how we apply it within the HCI profession.
The first change is the scale and complexity of the interfaces we are trying to prototype. Examples found in the pioneering movement of the 1980s were relatively small by comparison with today's applications. They were smaller than most eCommerce Web sites. In fact they were more similar in scale to a modern PDA program. This provided the ability to create prototypes that were 100 percent complete. The scope of modern software products and the multitude of use cases a single product must support have changed this. It is no longer practical to create a complete prototype of most enterprise applications. This actually leads to a communications problem where the prototype stops and a different specification process (or not) begins.
The second important change is the emergence of agile or extreme programming models. This trend was also foreshadowed in the original chapter as an "integrated prototyping approach" where the prototype eventually becomes the product. However it was never intended that it would be done without the formal requirements definition, or so rapidly that no time was left for usability testing. In fact, some of the earliest advocates for the introduction of UI prototyping cast it as an extension of the more common serial waterfall or lifecycle models popular in the software development of the late 1970s  and argued that it was economically justified, even though it could lengthen the development process because it increased specification accuracy.
In re-reading Rosenberg and Wilson, one thing stood out. Our tools are still not smart enough. The original chapter contained a final hopeful section on promising research in artificial intelligence as applied to User Interface Management Systems. As has been previously demonstrated, the promise of AI has remained ten years ahead of us for more than half a century.
Twenty years later our UI prototyping tools still do not meaningfully assist us in making the thousands of decisions required in even a simple interface project. The best of them can barely enforce minimal layout standards. The main way they have enhanced our skill is by allowing us to iterate through design variations more quickly. The tools themselves do not yet make a creative contribution and probably will not achieve this goal in the foreseeable future.
Returning again to the final words of the original text, exactly as Jim wrote it: "Only a skilled designer supported by several iterations of design involving user testing is likely to deliver an acceptable and usable interface design." Some things never change.
In memory of Dr. James Wilson, who left us in body but not in spirit several years ago after a long and brave struggle with cancer.
About the Author:
Daniel Rosenberg is currently an executive with SAP. In this capacity he directs UI design and usability activities for the mySAP business suite and Netweaver product lines. Prior to joining SAP, Rosenberg was vice president of research and development for usability and interface design at Oracle Corporation. His accomplishments include his book, Human Factors in Product Design (Elsevier 1991), co-authored with William Cushmanthe first book that formally addressed the ergonomics of consumer products. Rosenberg is one of the founding editors of ACM's netWorker magazine.
©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.