Prototypes are central to the design process; they’re the means by which designers establish the feedback loops that allow artifacts to evolve. But there’s a pitfall when discussing prototypes: there are different types and uses of prototypes, but only one word (“prototype”) to describe them. This unacknowledged variety can cause confusion and false expectations. Talking about prototype resolution and fidelity is as far as many designers go, but often that’s not far enough.
In a paper (PDF) published in the Handbook of Human-Computer Interaction (2nd Ed) (1997), Apple designers Stephanie Houde and Charles Hill resolve this issue by identifying four categories of prototypes, based on the dimension of the design project they’re meant to illuminate:
- Role prototypes
- Look and feel prototypes
- Implementation prototypes
- Integration prototypes
(Following quotes are from the paper.)
Role prototypes
Role prototypes are those which are built primarily to investigate questions of what an artifact could do for a user. They describe the functionality that a user might benefit from, with little attention to how the artifact would look and feel, or how it could be made to actually work.
In other words, this dimension is meant to cover the “jobs to be done” angle of the product or system. How will people use it? Would it be useful in its intended role? What other purposes could it serve for them?
Look and feel prototypes
Look and feel prototypes are built primarily to explore and demonstrate options for the concrete experience of an artifact. They simulate what it would be like to look at and interact with, without necessarily investigating the role it would play in the user’s life or how it would be made to work.
This dimension doesn’t require much explanation; these are prototypes that are meant to explore UI possibilities and refine possible interaction directions. (I sense that many people focus on this aspect of prototyping above the others; look and feel is perhaps the most natural target for critique.)
Implementation prototypes
Some prototypes are built primarily to answer technical questions about how a future artifact might actually be made to work. They are used to discover methods by which adequate specifications for the final artifact can be achieved — without having to define its look and feel or the role it will play for a user. (Some specifications may be unstated, and may include externally imposed constraints, such as the need to reuse existing components or production machinery.)
These prototypes often seek to answer questions about feasibility: Can we make this? What challenges will we face in producing such a thing? How will a particular technology affect its performance? Etc.
Integration prototypes
Integration prototypes are built to represent the complete user experience of an artifact. Such prototypes bring together the artifact’s intended design in terms of role, look and feel, and implementation.
As its name suggests, this final category includes prototypes that are meant to explore the other three dimensions. Their comprehensive nature makes them more useful in simulating “real” conditions for end users, but it also makes them more difficult and expensive to build.
The authors illustrate all four categories with extensive examples. (Mostly charming 1990s-era software projects, some of them prescient and resonant with today’s world.) A running theme throughout is the importance of being clear on who the audience is for the prototype and what purpose it’s meant to serve. A prototype meant to help the internal design team explore a new code library will have a very different form than one meant to excite the public-at-large about the possibilities afforded by a new technology.
The paper concludes with four suggestions for design teams that acknowledge this empathic angle:
- Define “prototype” broadly.
- Build multiple prototypes.
- Know your audience.
- Know your prototype; prepare your audience.
Twenty-plus years on, this paper remains a useful articulation of the importance of prototypes, and a call to using them more consciously to inform the design process.