Reading: Prototyping

The reading for this week focused on defining what prototyping is, and its advantages and limitations.

Definitions

Typically, prototypes are either high-fidelity or low-fidelity. The reading mentioned medium-fidelity prototypes, but suggested that the limited benefits of this type do not outweigh the cost of producing this type of prototype.

Low-Fidelity Prototypes

These are prototypes that roughly represent the layout of an application or physical device, but only describe, not implement, its functionality. The advantage of low-fidelity prototypes is that they are quite cheap to produce, and allow the designers to create many iterations of the prototype. Low-fidelity prototypes can take several forms, most of which are on paper:

Storyboard: These are used to prototype the usage of what’s being built, by telling the story if its usage.

Sketches: Often, paper-based prototypes are drawn by hand. They don’t have to be works of art, and prototype makers can use symbols or icons in place of items that require detailed drawing. This helps get around the inhibition of bad drawing skills.

Wizard of Oz: The prototype is tested by someone who acts as if the paper or 3D prototype is real, while an operator manipulates the prototype as if it was responding to the user’s inputs. For example, a drop-down menu on a website could be created in paper form, and shown when a user “clicks” on it.

High-Fidelity Prototypes

High-fidelity prototypes have at least partial functionality implemented. Often, they involve writing code, which may or may not be incorporated into the final product. The advantage of these is that it’s easier to communicate how the product will work. One disadvantage is that the cost to make these prototypes is rather high. There needs to be a  good reason to invest the effort into making a high-fidelity prototype.

Another problem, one I’ve encountered in my own work, is that, because of the cost to produce a high-fidelity prototype, it is tempting to keep the prototype as the finished product. One team I worked on had us making “prototypes” of the web-base user interface we were building, but all of them ended up being used in the final product. This can be OK when done deliberately, but in this case, the code wasn’t written in such a way to be maintainable as new features are added.