Nobody calls home stereo components (or anything else) “hi-fi” anymore, thank goodness. Even its more recent cousin, “high-definition,” has fallen out of common use. Thus, the term “high-fidelity” can return to its true meaning: to describe any faithful representation of an artifact, be it sound, video, graphics, or what have you.
In software development, the term “high-fidelity” (and its counterpart, “low-fidelity”) have come to describe approaches to prototyping. In this article we discuss the differences between high-fidelity and low-fidelity prototyping, the pros and cons of each approach, and when you might choose one over the other.
As discussed previously in this blog, a prototype is a mockup of a user interface (UI). UI prototypes are typically used in software development, but hardware prototypes are often built as well. For this article, we focus on software prototypes.
Prototyping is important in software development for many reasons:
The fidelity of a prototype is how close it comes to matching the real thing:
Some in the software development world describe a third, “medium-fidelity” approach, which falls somewhere between the others. For our discussion, we will stick with the two extremes.
Low-fidelity prototypes have certain advantages over their high-fidelity counterparts:
However, low-fidelity prototypes do leave a bit to be desired. It’s difficult to represent the behavior of a complex UI or task with a low-fidelity prototype, and it may be difficult for audiences to envision how the end product will work. Thus, it’s hard for them to give anything more than high-level, general feedback.
By contrast, high-fidelity prototypes overcome those disadvantages:
However, high-fidelity prototypes take some time and expertise to produce. Although many robust tools exist to produce high-fidelity prototypes, each one has some kind of learning curve that must be overcome for users to make effective use of it.
For this reason, these tools are often used by higher-priced UI or user-experience (UX) designers, whereas almost anyone on the team can do a low-fidelity prototype. In addition, some tools are more easily applied than others to rapid prototyping (that is, on-the-spot changes made in immediate response to audience feedback).
As you might expect, each approach has its uses depending on the circumstance.
Low-fidelity prototypes are appropriate for the early stages of prototyping when the development team and customer are throwing ideas around to zero-in on a preliminary design. You don’t want to waste time and high-priced expertise on building a fancy interactive early prototype that the customer ends up rejecting right away.
High-fidelity prototypes are better for the later stages of prototyping after the stakeholders have settled on a general approach from the low-fidelity prototypes. At this stage, it’s worth the effort to build an interactive prototype that the customers can get their hands on and play around with; they can then ask better questions about the functionality and provide more detailed feedback. The result should be a solid UI design that can be implemented without guesswork.
Unless the UI design is almost trivial (in which case low-fidelity prototyping might be sufficient), most app development projects should make use of both low-fidelity and high-fidelity prototyping.
The important thing is that prototyping, regardless of fidelity, should not be overlooked; it is an important component of the development cycle and dramatically improves the chances of a successful product.