The Pitfalls of Prototyping

by Andrew Lopresti

Failure is not an option. It’s a necessity.

If all we ever do is succeed, we have never pushed our own limits. Failure is an important step – and a very liberating one – when interaction designers realize they can miss the mark on something without it being the end of the world. And when they start to realize that it is a stepping stone to future success, that’s when they take off.

The object of a prototype is to learn, and often by failure. That is, it is to test the limits of design, so it can be improved. Thomas Edison, while inventing the light bulb, often opined on the large number of failures we worked through to light up our world. He has been quoted as saying, “I have not failed. I’ve just found 10,000 ways that won’t work.”

Another common example of repeated failure leading to success is Angry Birds. No one ever uses up their birds and says “I quit”. Even experienced players will launch birds at specific targets in an attempt to discover weaknesses in the structure, which is intentional failure with a purpose. In Candy Crush, as we progress through levels of complexity, we will try combinations of moves that lead to repeatable patterns to overcome the challenges. When we fail, we tweak our patterns and try again.

In our world, we are not thwarting pigs or crushing candy. We are building systems, and our prototypes are 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. We can also employ tools like Axure Rapid Prototyping to increase the level of fidelity without increasing time.

Level Up: The Different 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.

Wireframes are, in essence, low-fidelity prototypes. They may have been implemented from a collaborative mass of sticky notes on an office wall, results of a multi-colored JAD sessions on a white-board, or, in most cases, PowerPoint pages that depict navigation and screen layout. They’re easy to create, inexpensive to change, and are good for providing a basic “high-level view” of the overall system structure. Where wireframes typically focus on what can be developed with the total understanding of constraints and resources, prototypes focus on the art of the possible. Typically constraints are ignored in initial ideation in prototyping, and are introduced though refinement and iterative designs.

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. These are mostly effective to get client buy in and to create proof of concept pieces.

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. Rapid changes are more difficult to put in place due to design considerations.

There are available concept visualization tools such, as iRise, which can be employed to streamline the requirements and prototyping process. They are wonderful, yet pricy, and are a viable option on the enterprise level of prototyping.

The middle ground is to 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.

Medium-Fidelity Prototypes: A Win-win Situation

By combining HTML, CSS, and JavaScript (for web applications), or utilizing a tool like Axure, 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. If a picture is worth a thousand words then an interactive tool is much, much more. A prototype demonstrates to a client what functionality the system can 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.
• Get everyone involved. 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. If you include using actual users, these participants form your user pool and might even become your internal advocates for a new application or a redesign.
• 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.

The Pitfalls of Prototypes

Despite their many benefits, using prototypes in an application development setting often require setting expectations among users and client team members. The most important consideration, however, is that prototype code should never be used as production code. It should be considered throw-away code.

Because they lack graphics and dynamic data, prototypes 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, and reminding clients of the benefits of keeping the prototype at a medium-level of fidelity. It is only at this level that you can completely enjoy the benefits outlined above, as well as establish a “finish line” for a prototype.

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 users) are happier for it.

Achievement Unlocked: So what did we learn?

Prototypes are attractive to development teams because they have clear benefits. They facilitate communication by exposing design assumptions, drive ideation, and provide an optimal, realistic setting, for gathering user feedback. But prototypes are complex artifacts: They have many different dimensions and can be created with a variety of tools. Project teams that don’t understand these complexities can waste time and effort–and even thwart project progress. Before they start to develop a prototype, project teams need to consider the business objectives that are driving their efforts–and then manipulate prototype attributes and fidelity to support these needs, and get that high score.