In my last post, I discussed high-level factors one should consider when determining the most effective type of prototype for a given product. This is done through an analysis of their organization, workflow, and development process. Here, I will compare the different types of prototypes through illustrating three high-level approaches by example.
To illustrate different prototypes,
let's imagine that you are trying to create a file upload prototype with the following functionality:
- Users can drag and drop images into an upload area
- or, users can select files from their local filesystem through an upload dialog
- The uploaded file will be presented in a carousel below the image upload area
- On click the uploaded image from the carousel will be shown in a larger image preview area
All of the files from this article, including working prototypes, are located here on github.
1. Paper Prototype
Paper prototypes can be effective in getting a general idea across to stakeholders and development teams early in the design process. For example, here the viewer gets a good idea of the design: there is an area where images can be dragged into, afterwards they are shown in an area at the bottom, and on click the images are displayed in a larger image preview area.
The first potential problem with the paper prototype is the lack of refinement. Depending on who your viewers are and their level of familiarity with your work, it may come off as amateur. If your audience is made up of new clients, therefore, you may want to create a low or hi-fidelity prototype to demonstrate more professionalism.
Another problem with the paper prototype is its limited capacity for complexity. This is a relatively simple prototype, so can be represented to a certain degree on paper. However, even some of the elements of this prototype are unclear. For example, what happens when a user has uploaded more images than can fit in the preview area below? Also, do the visual elements change on hover? Furthermore, the visual design system is not represented, leaving the audience to infer the final product.
2. Lo-fidelity Prototype
Some of the problems with the paper prototype are alleviated by the lo-fidelity file upload prototype. Users can interact with the lo-fidelity prototype: dragging and dropping images into the upload area distributes them into the carousel below, or the user can select images from their filesystem. If more than four images are added to the carousel, a right arrow appears so the user can scroll right to see the additional hidden images. After the right arrow is clicked, a left arrow appears to allow scrolling through the carousel.
While many of the conceptual problems with the paper prototype are alleviated in the lo-fidelity prototype, some potential communication problems still remain.
For example, the lo-fidelity prototype may or may not have hover states. Neither is the visual design system represented, meaning that the lo-fidelity design will need to be accompanied by additional comps in order to illustrate the visual elements.
Often, these additional comps will have an accompanying "redline" or design specification detailing the fonts, colors and so on:
Additionally, more comps will most likely be needed in order to further illustrate the various states of the visual elements. So for, example, you would need a separate redline spec for the hover state:
designing in this framework, for each interactive element a designer
needs to deliver multiple representations. This can be problematic, as
designing interactivity statically takes elements out of context, and
one loses sight of the gestalt within which various elements
3. Hi-fidelity Prototype
The hi-fidelity file upload prototype presents the entirety of the design within a single deliverable. Whereas one would need multiple deliverables to illustrate the visual, interface, and interaction design separately when creating paper or lo-fidelity prototypes, the hi-fidelity prototype includes all of these different pieces, creating a more robust, refined, and cognizable end product.
Paper and lo-fidelity prototypes require inference in digesting the product: while the designer can illustrate the hover state for the drop area, for example, it becomes more tricky to communicate whether the hover state should fade out, and how quickly. While it may be quicker to produce the lo-fidelity prototype initially, in the end it would be less efficient if the design ideas are misinterpreted.
Hi-fidelity prototypes require more initial effort, but can provide a variety of benefits later, resulting in the creation of a better product in a more efficient timeframe. For example, developers can use their browser's web inspector (depending on the software used in producing the prototype) to choose the exact CSS values used in the prototype. This is more efficient in implementation, as the dev team can copy and paste values rather than write from scratch. For example, here :
Each prototyping approach has its comparative benefits and costs. A paper prototype can be effective in communicating ideas quickly, but may not fully represent the ideas, resulting in wasted time if the designs are misinterpreted. Lo-fidelity prototypes have similar potential pitfalls, and require supplementary documents to fully represent the final product.
While they do necessitate a larger initial time investment, producing hi-fidelity prototypes can be more efficient in the long run.
- Hi-fidelity prototypes do not need as much documentation, as the ideas are encompassed in the deliverable rather than inferred.
There are a variety of methods one can employ to create hi-fidelity prototypes. For a detailed explanation and working files that illustrate how this hi-fidelity file upload prototype was created, hop over to this article on my website.