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:
All of the files from this article, including working prototypes, are located here on github.
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
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
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.
additional comps will have an accompanying “redline” or design
specification detailing the fonts, colors and so on:
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
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.
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.
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 :
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
While they do necessitate a larger initial time
investment, producing hi-fidelity prototypes can be more efficient in
the long run.
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.