After speaking to PM’s and designers over the holidays I was surprised to learn how scarcely prototyping is used in product development. Of my small sample size (+/- 10 people) only 1 designer regularly prototyped before sending a design ‘over the wall’ to engineers.
Note: For scoping this post, ‘prototype’ will simply refer to an artefact that simulates a potential design solution.
Some literature will tell us that prototypes are questions, some will suggest prototypes are answers, so wtf are they? According to What do Prototypes Prototype?, a classic paper published by Apple, they can be both. Prototypes either explore or express. They question or answer.
What prototypes (probably) are
A representation of a proposed design solution.
Distinct from a sketch or a mock-up.
Divergent and convergent.
A method of exposing unknowns early(ish) in the design process. Ryan Singer talks about ‘spiking’ in this post, which roughly translates to building enough of something to expose the unknowns.
A tool for learning. The design thinking and design sprint methodologies lean heavily on prototyping to ‘learn something’ and then loop back to iterate with new knowledge gleaned from prototyping.
A tool for risk mitigation.
A tool for communication. There seems to be a communication element to prototypes that exceeds the power of plain text. It could be argued that a well-written document that outlines the intention of a design approach is a prototype, especially if we are considering ‘implementing’ as the focus of the prototype (more on this term later).
Stages of product development
Understanding the stages of product development can help add context to where prototyping might add value. A simplified timeline of product development, ignoring the loops where iteration takes place:
Each step (from left to right) increases fidelity. As we move through time, two key values also increase:
- the cost of failure
- If our assumptions are wrong, we lose time and effort to revisit and correct them as we move through the design process.
- the cost of change
- At the point of high fidelity, we are already starting to make subconscious commitments to small details.
Warning: Prototypes can often be relegated to the thing you do before handing off a design. This is using prototypes as a usability testing tool rather than as a method of exploration!
Refining our definition of a prototype
We haven’t yet defined who a prototype is for. Although, the natural inclination is to gravitate toward picturing a user as the prototype’s audience.
According to What do Prototypes Prototype? prototypes can be both internal or external:
- external prototypes are typically shared with users/ potential users
- internal prototypes are shared with people inside your organization
- stakeholders to present a direction (suggestive approach)
- engineers to raise implementation questions
Sidenote: Your competitor’s product can act as a cheap prototype for your design ideas. Watching people interact with an existing product can inform the design choices you have to make.
The question remains, why aren’t more designers prototyping? Michael Schrage writes in his paper Prototyping Culture that prototyping culture is developed within an organization and dictates how it approaches the product development process. Organizations can be grouped into two buckets
- prototype-driven (usually small start-ups)
- specification-driven (usually larger organizations)
Prototype-driven approaches are typically observed in startups where the company is intrinsically aware of its lack of knowledge. Spec-driven organizations have therefore lost any sense of a beginner’s mind and rest on prior insight. The danger of top-down spec-driven design is that they are often written upon assumptions that, if invalidated, become painfully misleading.
Prototyping with purpose
Before picking up any materials to prototype, a purpose must be defined.
What questions need to be asked and what questions are we striving to answer? Prototyping in New Product Development stresses the importance of defining a prototype’s purpose and understanding contextual factors within the prototyping process. Context is a wide-reaching term, but covers:
- organizational culture. If the organization has built up sufficient domain-specific knowledge
- predictability of usage context (where will this thing be used? How predictable is the environment?)
To define a purpose, let’s revisit What do Prototypes Prototype? This is an excellent starting point which can form the framework of a prototype strategy. The paper defines two categories (what and who) with three variables each.
What to focus on:
- Role
- how does this fit into our user’s life? Can also be thought of as context
- Look and feel
- is this form an appropriate one? Look and feel covers everything related to the sensory experience of a solution (Walter Teague’s cardboard aeroplane picture above sits in this category)
- How might we implement it?
- the nuts and bolts behind the scenes, how something works. This could also be a value proposition or business model, not just a technical implementation
Who to focus on?
- Users
- feedback, usefulness, fitness, preferences
- Design team
- design crit, internal feedback
- Organization
- buy-in, direction, progress
I’ve added an overlay on top of the figure taken from What do Prototypes Prototype? to clarify the interplay of the ‘what’ and the ‘who’.
- internal use is covered in the blue circle
- external (user) is covered in the orange circle
Seeing as prototypes are an abstraction of the end vision, it is important to analyze a specific element of the proposed product. A complete prototype would technically be 1-1 with production (we could argue that production is just the latest prototype). Therefore, we must address specific design questions with our prototypes and if needed, create multiple prototypes to address separate questions.
If we are designing a novel feature, by definition it has no ‘role’ in the user’s life. With this in mind, it is sensible to focus on a prototype that explores this before any specific interface detail—sequencing matters.
Multiple Prototyping Strategy
Building multiple prototypes allows the designer to expose the unique characteristics of different design solutions. Parallel testing multiple prototypes is also an excellent strategy to improve the quality of feedback as mentioned in Getting the Right Design and the Design Right Testing Many Is Better Than One by Bill Buxton. Users are reluctant to critique a single design solution but more willing to rank a solution out of a pool of options.
Introducing contrast allows people to tell you what they don’t want. Giving users multiple options also affords users the freedom to rank without hurting any feelings.
In this episode of the Circuit Breaker podcast, Bob Moesta also states the benefits of testing multiple prototypes. Giving users multiple prototypes is “…about helping people eliminate what they don’t want and helping us build the criteria of what they want.” This sounds similar to Bill’s finding about the value of comparing and contrasting.
Multiple prototyping can be done during convergence or divergence. Moesta explains the utility of both approaches depending on the current stage of the design process. We naturally associate divergence with early stages in the design process when solution clarity is low.
- divergent prototyping (an exploration of the solution space)
- a car
- a bike
- a plane
- convergent prototyping (an exploration of trade-offs within a narrow solution space)
- a sports car
- a pick-up truck
- a hatchback
Summary and practical implications
The art of prototyping comes in the balancing of building just enough to learn exactly what we need to move forward or pivot to an alternative approach.
A funny quote I encountered during this research was, “Never show fools unfinished work.” Could it be that designers are reluctant to prototype due to trauma from prior experiences? Sharing prototypes early to the wrong audience invites unconstructive feedback.
The audience of a prototype needs to be aware of inherent limitations to avoid being distracted by the obvious abstraction or lack of functionality. Early in the process show low-fidelity prototypes to other experts who will not be blindsided by the scrappiness.
A prototype is worth 1 thousand meetings
What is clear to me is that there is significant value in refining a prototyping strategy. Knowing when to prototype can help us de-risk work, uncover unknowns earlier in the process, and empower users to give us higher-quality feedback.
Some Further Questions
- user data rendered in an interface is often one of the core components of its usefulness. In static design tools how do we bridge that gap?
- experiences usually can only be judged by full workflows, how much value do we use by chunking this into mini flows within an experience?
- how can we more accurately represent context when exploring prototypes with a user?