Introduction to Medium-Fidelity Prototypes

Prototypes allow for rapid, iterative design changes and the ability to conduct meaningful user tests to evaluate complex functionality and to help determine system specifics.

We spend a lot of time talking about our User Interface Prototypes. In fact, they're one of our primary deliverables on just about every project we engage in.

But what exactly do we mean when we say we "build medium-fidelity prototypes?" This article provides insight into the process of building Medium-Fidelity Prototypes and describes the benefits they provide to our clients and to application development teams.

A Formal Definition of Sorts

Inovdesigns' prototypes are primarily text-driven interactive tools that communicate the organization and navigation of the application - often called the Information Architecture. They also serve to depict how individual pages should be structured for usability purposes.

A typical prototype contains very few graphical elements, most (if not all) back-end functionality is simulated, and data is static. For web sites and web applications (and even for software applications), we use a combination of HTML, CSS, and Javascript to simulate the actual intended behavior of the system.

Levels of Fidelity

The level of "fidelity" of a prototype refers to how closely it resembles the final product. For simplicity's sake, we'll consider three levels of fidelity used for prototypes: Low, Medium, and High.

Low-Fidelity Prototypes have been implemented as a jumbled mass of sticky notes on an office wall; as multi-colored, cryptic scrawlings on a white-board, or even as a set of BON (Back of Napkin) scribbles. They're easy to create, inexpensive to change, and are good for providing a basic "high-level view" of the overall system structure.

A low-fidelity prototype can be as simple as a sketch on paper.

High-Fidelity Prototypes, on the other hand, are often deployed with an almost-full set of graphics, functionality (such as usernames and passwords, session variables, etc.) and tie-ins to dynamic data sources. They are very detailed systems that are expensive to create, difficult to change quickly, and usually require more rigid software development practices in order to successfully complete. In fact, High-Fidelity Prototypes are sometimes so close to the final product that they actually become the final product (something we disagree with, but that is a topic for another Coffee Talk).

The higher the level of fidelity of a prototype, the more complete and accurate it is at representing the final application. However, that completeness comes at a cost.

Our solution is to therefore create Medium-Fidelity Prototypes. These prototypes are sort of a best-of-both-worlds implementation that allows for a combination of both high-level and detailed views; rapid, iterative changes; and the ability to conduct meaningful user tests to evaluate complex functionality and to help determine system specifics.

Benefits of Medium-Fidelity Prototypes

By combining HTML, CSS, and Javascript (for web applications), we're able to relatively quickly create an interactive example system that is designed to help the client, the development team, and the visual designers better understand the requirements guiding the project. When used as part of an application development project, a prototype can:

• Communicate the design. A picture is worth a thousand words; an interactive tool, much more than that. A prototype demonstrates to a client what functionality the system will deliver and what it will be like for users to interact with that system. With this knowledge, a client and the development team can more easily prioritize the development of features and functions and determine project scope.
• Allow for participatory design. Prototypes are primarily top-level, simple in design, and relatively inexpensive to implement and change. Available to the client team, the development team and a wide variety of users, prototypes lend themselves to a participatory design process where many key roles have to "buy-in" to the nature and behavior of the final product.
• Catch mistakes early. Ideally, prototypes are frequently tested in formal and informal usability sessions throughout their development. This allows design flaws such as ambiguous labels or intolerance for user errors to be caught early and corrected relatively inexpensively. Prototyping reduces risk and helps avoid the possibility that the final product becomes merely a prototype for the next release or a situation in which the prototype itself becomes the final product!
• Support iterative development. Frequent user testing and subsequent prototype revision can also support an iterative development process. In this way, the Web site or application interface can evolve (through the process of either adding, refining, or removing features and functionality) until it reaches a stable state. Once the design is stable, development can begin.
• Facilitate detailed requirements gathering. Because prototypes provide a common ground of understanding between users, client team members, and development team members, they greatly help in establishing business requirements, application requirements, and use cases. Ideas for what the system should include or how it should function can be quickly worked into the prototype, evaluated, and reflected in the formal requirements.
• Guide later development stages. Once a prototype is developed and approved, it becomes a blueprint that can guide many teams involved in the later stages of the development process. Graphic Designers, for example, can use the prototype to understand system behavior and graphical requirements (buttons, navigation, etc.). At the same time, Application Developers can use the prototype as a live representation of the use cases (even to the point of using prototype pages as a test front-end to their code) and to understand how the system is intended to interact with users.

Caveats of Prototyping

Despite their many benefits, using prototypes in an application development setting often require some setting of expectations among users and client team members.

Because they lack graphics and dynamic data, they are generally not considered "final" products. Yet it is easy for both clients and team members to want to see more and more functionality and detail included in the prototype. We recommend avoiding this temptation, however, and reminding your clients of the benefits of keeping the prototype at a medium-level of fidelity. For it is only at this level that you can completely enjoy the benefits outlined above.

Although Medium-Fidelity Prototypes maintain a relatively "unpolished" presentation, they can support highly relevant system interactions, and are easily modified to illustrate alternative designs. Because of this, we find our prototypes are often at the center of many critical discussions involving the members of both the client and the development teams. Ultimately, these discussions result in a better solution, and our clients (and their customers) are happier for it.