Over the past few years I’ve noticed a race towards hi-fi prototyping. In addition to more and more designers picking up HTML, CSS and JavaScript, software companies have been working hard to lower the barrier to entry. With tools like Axure or iRise almost anyone with an eye for design can pull together near-real functional prototypes.
It seems this accessibility has become somewhat intoxicating for designers. First instincts tend to lead designers to blur the line between “show, don’t tell” and “build out a fully functional application”. And why wouldn’t it be? We now have the means, it won’t take that long, and most importantly it’s way easier to demonstrate what is meant by in-line validation than to show screen shots and have to spell out the interaction.
There are a few high-level drawbacks to the over-engineered prototype, a number resulting from positive reactions. While satisfying in the short term for both the producer and the audience they tend to lead to “miscalibrated”expectations and ultimate disappointment in some cases. A common confusion I’ve seen has been the illusion of the prototype as an indicator of state of progress, this link becomes even stronger with the functional prototype. The more functional and polished the prototype appears the harder it seems to be for the viewer to be convinced it does not represent technical completeness. This can lead to an expectation of an unrealistic delivery pace.
Most detrimental to the process is the effect that can be had on feedback. This disruption to feedback quality can come from both ends. Those giving feedback have been less willing to call out issues they feel could result in an overhaul of design due to the perceived effort involved or state of development. Those receiving feedback have become defensive and over justify their decisions due to attachment to the prototype developed through time spent refining look and functionality. Once a prototype gets in the way of conversation and debate it has invalidated itself.
This is not to say that hi-fi prototyping is inherently bad. It is a wonderful tool when trying to immerse users in a perceived reality to evoke gut reactions to an environment or to test tactile interactions. They are also effective in understanding the relationships between multiple interactions. There are equal arguments to be said for and against paper prototypes. The point being that when used in the wrong way for the wrong audience the most beautiful or simple tool can be detrimental to the goal.
If we begin with the idea that prototyping is a tool used to extract useful information we can start working with more intent and stop making the first decision the level of fidelity. Instead, we will understand the information we are looking for and audience from which we are trying to extract that information. For example, a prototype with the goal of understanding emotional feedback to brand and content will differ highly from one looking to understand feasibility of an integration flow. The same also goes for understanding reaction to single functions vs. a function in relation to an environment. It should not be assumed that extracting feedback from a back-end developer and a CMO will be done in the same way. We can present the information in a way that will speak to our audience and allow them to focus on the points we are looking for feedback on without distracting them.
Once the focus of the prototype is shifted from a visual representation of an idea to a tool with the sole purpose of generating the most valuable and useful information we will find ourselves in less conversations around the merits of fidelity and instead spending our time creating the right tool for the job. Your thoughts?
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
