On Prototypes and Prototyping

January 27, 2022

According to Drexler (1986, p. 220), in engineering, it is the prototyping, and not planning of engineering designs, that brings most advances. Brooks (1995) further states that prototyping is necessary for eliciting the requirements of the computational tool under development, since design problems are in general under-constrained. In other words, using a fixed set of requirements will as a rule lead to incongruities, which can then consequently be dealt with only by further requirement elicitation, i.e., further prototyping.

In HCI, a prototype is a design solution proposal. Not only that, an HCI prototype is “the representation of the interface par excellence, reflecting both its appearance and behavior” (Tetzlaff and Mack, 1991):

Prototypes emulate the intended design as faithfully as the implementation resources and technology permit. Interface design can be very difficult to picture and evaluate in the abstract or from stimulus and behaviorally impoverished representations such as static drawings or verbal description.

If we view the process of eliciting design requirements as a learning process, Argyris and Schön (1974) state that the process of learning generally involves the detection and correction of errors through feedback loops, which in design are afforded through the construction of prototypes. Any ‘problematic’ design situation is by definition uncertain, and an effective approach to deal with its uncertainty is to build a prototype (Schön, 1983).

Shortcomings of Prototyping

Despite their significant advantages, prototypes (especially high-fidelity prototypes) carry some significant potential problems of their own (see Tetzlaff and Mack, 1991; Rettig, 1994):

• Concern shifting (from interface design to programming). The designer’s attention is dangerously shifted away from interface design, to the specifics of the implementation, dealing with a variety of development-related time-consuming tasks. To remedy this, Tetzlaff and Mack (1991) suggest ‘explicit interventions’ and techniques to recover the designer’s attention back towards interface design, such as group design, and using environments for rapid, visual construction of user interfaces.

• Expensive to build (time, costs). Prototypes by definition are supposed to demonstrate a good part of the intended functionality, which requires significant expenditure of total human effort in terms of time and financial cost.

• Having to deal with non-essential aspects of the interface. The implementer of the prototype inevitably deals with many non-essential aspects of interaction design.

• Testers’ comments are superficial. Testers of the prototype frequently comment on its superficial features, instead of on its “deep features”.

• Developers’ inertia. Prototype implementers are frequently unwilling to make changes to the existing code base due to “sunk costs” i.e., total hours spent developing the prototype.

• Unreasonable expectations. A well-executed prototype could incite big appetites and lead to overly optimistic expectations or excessive demands on the final, “release” revision of the application.

In a nutshell, then, prototyping is an immensely useful and effective technique in the context of design, however it must be approached with care.

References

• Drexler K Eric. Engines of Creation. The Coming Era of Nanotechnology. Anchor Books, 1986.

• Frederick P Brooks Jr. The Mythical Man-Month, Anniversary Edition: Essays on Software Engineering. Pearson Education, 1995.

• Linda Tetzlaff and Robert L Mack. Discussion: Perspectives on methodology in HCI research and practice. In John M. Carroll, editor, Designing interaction, pages 286–314. 1991.

• Chris Argyris and Donald A Schön. Theory in practice: Increasing professional effectiveness. Jossey-Bass, 1974.

• Donald A Schön. The reflective practitioner: How professionals think in action, volume 5126. Basic books, 1983.

• Marc Rettig. Prototyping for tiny fingers. Communications of the ACM, 37(4):21–27, 1994.