Hi Fi or Lo Fi?
Over at uxbooth.com, Tyler Tate recently wrote an excellent article on the fidelity problem encountered when prototyping software; how does a designer decide if their prototypes should be high fidelity or low fidelity?
Tate’s conclusion is that “it simply comes down to selecting the level of fidelity that gets the job done in the least amount of time … Laziness is the mother of efficiency”.
I largely agree with Tate’s conclusion, but have to add a caveat for researchers to be wary of.
Tate, inspired by Bill Buxton, correctly argues that there is a continuum of fidelity when designing. We start with low-fi sketches to explore ideas then move onto wireframes, mockups and prototypes as we gradually iterate designs into something ever more high fidelity. This process ends with the final design, created in HTML, CSS, Java ME or whatever else.
By starting low-fi, we can find the right design, and arrive at the right sort of solution cheaply and easily; by moving towards something more high-fidelity, we can get the design right, and refine this solution until it is implemented as effectively as possible.
In this sense, design is seen as a funnel, with the design becoming ever more focused as higher-fidelity representations are created. However, Tate is, I would argue, wrong to see the creation of mockups (of the visual design) as being a stage in the design process that occurs before prototyping.
Properly understood, mockups represent the visual properties of an interface whilst a prototype represents the functional properties. This means that a representation of an interface could be both a low-fidelity mock-up (such as a wireframe) and a high-fidelity prototype (if it has a fully interactive navigation). Therefore, high-fidelity prototype does not necessarily require visual design elements to be present.
This may seem like a trivial point, but it has important implications. When creating prototypes, we need to be aware of which properties are accidental (such as the colouration and material of paper prototypes) and which are essential (such as the positioning of the main navigation).
It is all too easy to start treating accidental properties as essential, or to give our prototype impossible essential properties, something that Holmquist (2005) called Cargo Cult Design.
A cargo cult designer might forget that the size of a mobile application prototype running on a PC is much larger than in reality, or treat downloads as being instantaneous.
As designers, we therefore need to remain acutely aware of which properties of our design representations are accidental and which are essential. We must ensure that we understand how high fidelity our representations are as both mockups (in terms of visual properties) and as prototypes (in terms of functional properties). This is one important way to ensure that we do not become cargo cult designers.
Mark Parnell, Consultant