At Blink, we are sometimes hired to create a conceptual prototype for a product that is in the very early requirements stage. Usually, the product does not yet have internal funding for development and one goal of the prototype is to secure that funding. The prototype may also be shown to trusted customers to get their feedback on the concept.
Conceptual prototypes are often very interesting projects because the ideas are leading edge. But they also present some unique challenges compared to more traditional projects where we are designing for actual implementation.
The first challenge is that the idea for the system may only be a glimmer in somebody’s eye. The usual questions we ask up-front in a project to help understand the purpose of the system may not yet have answers. The answers to key questions may be a flat “we don’t know” or “it could be x, but it might be y.”
As a result of this ambiguity, our discovery phase can turn into more of a treasure hunt, assembling and reconciling the scraps of information that are available. The resulting picture of the system is usually incomplete, with conflicts and missing pieces.
To help flesh out a vision of the system, we often put the information we do have into a mind map.
If you’re not familiar with mind mapping, it’s a handy way to visualize ideas and the connections between them for all sorts of contexts. There are a number of good mind-mapping software packages out there.
With the mind map created, we begin drafting one or more key scenarios that the prototype will demonstrate. These are often highly speculative – meaning where there are gaps, we just take an educated guess on how that gap might be filled. Even if it’s a wild guess, we have found that taking a guess gives something for people to shoot holes in and serves as a catalyst for discussion.
Scenario development and refinement for conceptual prototypes can be a lengthy process because it’s coinciding with the process of defining the product. You also need to consider the audience for the conceptual prototype: internal decision-makers may have different questions and concerns than potential customers for the product.
With the scenarios “finalized” we begin to do a black-and-white paper prototype (wireframes) of the demo. I put finalized in quotes because once people see the implications of a scenario illustrated in wireframes, additional problems and questions almost always arise. Any design project is iterative—demo projects are almost always more so.
Assuming a final set of wireframes is complete, the next question is the right format for the final prototype. Here, you need to consider the audience for the product demonstration, who will be giving the demonstration, and the context in which it will be shown. Time and budget of course factor in as well.
The least expensive—and in some ways the lowest risk option—is to simply do an on-screen step through of the black-and-white paper prototype. The risk you mitigate by going with a clearly unfinished-looking prototype is the misperception that the prototype represents a finalized (and possibly fully-functional) interface. However, a black-and-white prototype is not very compelling visually. It may not engage the audience in the product’s potential in the same way as full color and partially interactive prototype.
Particularly when creating a more polished, interactive prototype, we include the text of the scenario so that it can be accessed if necessary. This serves as a script someone can follow if they lose their train of thought or are less familiar with the demo.
The expected outcome for a conceptual prototype project is of course, the finished prototype. The unexpected outcome can include a clearer, more cohesive vision of the product through the process of early-stage scenario development and wireframing.