When To Prototype, When To Wireframe – How Much Fidelity Can You Afford?

when-to-prototype-when-to-wireframe-fidelity
There is a lingering meme that design projects should skip wireframing and go right to prototyping. A good example of this position is Wireframing is out, prototyping is in: here’s why, by Joseph Lawrence.

From my experience I have come to the realization that interactive prototyping is not always the correct deliverable for a design project. Consider an enterprise application that needs a critical design fix because it is inefficient and is burning up money. The enterprise likely needs a solution as soon as possible, and it is probable that a well-designed GUI with traditional WIMP techniques and widgets will deliver big improvements. In such a scenario, the extra cost of creating an interactive prototype would unnecessarily expand the budget and delay the project when a simple, static wireframe would easily communicate the design to stakeholders and developers. In this fairly common scenario, interactive prototyping wastes resources.

The distinction between wireframe and prototype is almost arbitrary—both are mockups of the proposed application that differ in their fidelity to the final application. The lowest fidelity mockup has hand-drawn sketches which are quick, easy to do, and cheap. A set of black and white static layouts linked via hot zones provides a medium level of fidelity. The highest fidelity mockup is a fully-functional prototype, possibly using HTML+CSS+JavaScript, that requires programming skills to create and could almost be used as the final GUI.

Side note: I recommend never using a prototype as the final GUI. This is not prototyping. It is development. A prototype is a mockup that serves to demonstrate some subset of the interactive behavior, contextual layout, and visual design. It is not created by a development team with proper software development practices necessary for the efficient and maintainable code that a project should generate. If a project needs to iterate on fully-developed versions of the GUI, then be sure that the team doing so is not UX designers creating “prototypes”, but a development team building the application.

There are design tools that make it easier to create interactive mockups (e.g., Axure, Justinmind, Basalmiq, or iRise) and programming tools and libraries that simplify creating HTML 5 prototypes (e.g., Bootstrap or Zurb). However, deliverables with these tools, being more complex, require more resources than simple sketching and low-fidelity wireframing. Moreover, they take time to master, which takes time away from design activities. See Wayne Greenwood, Unicorn, Shmunicorn: Be a Pegasus, for some good points about the pitfalls of trying to master both design and programming. Finally, these tools can be costly—Axure and Justinmind will cost hundreds of dollars for a yearly license and iRise can cost thousands of dollars.

Possibly the most accepted maxim about a good design process is to mockup ideas, test them, and repeat, a lot. Some examples in the literature are Bill Moggridge, Designing Interactions, who recommends building a prototype every day; Carol Righi, Building the conceptual model and metaphor: The “3X3″; and the RITE method. Creating mockups in high fidelity mean longer and fewer iterations, but, being more faithful to the proposed application, are better to test on users.

when-to-prototype-when-to-wireframe-fidelity-1

Wireframe sketch of an application that I worked on

when-to-prototype-when-to-wireframe-fidelity-2

The same application – this time prototyped in Silverlight

Therefore, the decision of what level fidelity to use in a project’s design mockups should be based on a cost-benefit analysis. Below is a list of questions to consider for such an analysis.

Budget

How much time and money do you have available?

Nearly all design projects have time and cost limits. Higher fidelity mockups, such as interactive prototypes, take longer to create and are more expensive than static wireframing. Choosing higher-fidelity mockups means taking budget away from other potentially important UX activities such as user research, design iterations, and visual design.

Project Phase

Are you in a project phase that requires detailed communication of a mature design?

When in an exploratory phase of a project – e.g., identifying business requirements, testing the scope, playing with divergent ideas – then mockups are a sandbox in which ideas can be manifested, considered, compared and tested. The quick nature of low-fidelity mockups, such as sketches, allows more design iterations. Design-feedback iterations are essential, providing greater variations and broader exploration.

When in a generative phase of a project – e.g., diving into the details on a design idea or evaluating the full implications of an interaction – then mockups are a communication device with which designers inform the business and engineering teams of their intent for the application. The greater fidelity of interactive mockups, such as HTML prototypes, provides a more informative mechanism with greater nuance.

UI Interaction Complexity

Does the design have a complex interaction that needs to be shown rather than described?

Static mockups can show where interaction begins and ends, but must describe what happens in between. Standard interactions like simple links, buttons, or menus can easily be described. However, animation, gestures, or non-standard, unexpected behavior often cannot. A high-fidelity interactive mockup can make such behavior explicit, removing guesswork by viewers.

UI Workflow Complexity

Does the design traverse a complex workflow through which users can get lost?

Even a UI with only simple interactions can be confusing to users when that UI provides users with many navigational choices, or if the workflow that the UI supports is complex. In such cases, the design affordances provided to help users maintain their sense of place within the workflow may best be demonstrated through an interactive mockup.

Responsive design

Does your design need to respond fluidly to changing form factors?

If designing for several form factors, then a single interactive mockup that dynamically reacts to screen size changes may be easier to maintain than multiple static mockups for each form factor. Moreover, if the UI transitions between screen sizes are important to the design, then an interactive mockup may be necessary to demonstrate those transitions. However, responsive design isn’t necessary when a single form factor is to be designed, or the transition is not important to the experience.

Audience sophistication

Will your audience have difficulty understanding your designs?

Design deliverables have two audiences: the business and engineering stakeholders that will turn the designs into an application, and the end-users who will participate in usability studies that evaluate the designs. If either audience will have difficulty imagining from the mockups what the final application, and its relationship to the intended environment, will be, then you may want to consider higher-fidelity mockups.

On the other hand, people can get distracted by details. If your mockup is intended to communicate broader ideas such as the navigational model, page layouts, and task flow, then these concepts may get drowned in the details of a high-fidelity mockup.

In Conclusion

Jared Spool, Five Prevalent Pitfalls when Prototyping, describes working in the wrong fidelity to be a major pitfall to a successful project. The questions above should help clarify what fidelity to use in your mockups. If any of the answers are positive, and you have the budget and time allocation necessary, then it is worth considering using higher-fidelity mockups, such as interactive prototypes. However, keep in mind that higher fidelity comes at a cost that may not be worth paying.

References

UsabilityGeek.com runs on the Genesis Framework

StudioPress Genesis Framework

Genesis empowers you to quickly and easily build incredible websites with WordPress. Whether you're a novice or advanced developer, Genesis provides the secure and search-engine-optimized foundation that takes WordPress to places you never thought it could go. It's that simple!

Start using Genesis Now!

  • Andrew Mottaz

    Hi Garrett – thanks for the article. I firmly agree that fidelity levels should meet your needs. We’ve always said ‘Prototype as much as you need to get your point across.’ I’ve been leaning toward higher fidelity because I actually find users are more confused and pay less attention to anything that looks to sketchy or low fidelity.

    That said, one drawback of the highest fidelity (html, css and js) lock-in — you’ve worked so hard on the prototype that you don’t consider all the alternatives.

    For the shameless plug – you forgot to mention ProtoShare – we build prototypes in a wide range of fidelity with really nice HTML based interactivity. It’s a bit of a hybrid in that you’re using CSS and HTML in an easy to use gui. You can later look at the styles, css transitions and settings when you build your UI from the ground up, which as a developer I’ve found useful.

    We iterate a lot – starting very low fidelity, up to sometimes very high functional and design fidelity in ProtoShare. We’ll even bounce between the dev build and ProtoShare because most of the time its just faster to try out any sort of a layout change in ProtoShare than to monkey with Bootstrap or another responsive framework. You learn a lot during development and QA, and iterating quickly using prototypes to try new ideas has saved us a lot of rework.

  • Craig J Willis

    Indeed, wireframes can be created by anyone which is a great way to get your business stakeholders to think more deeply about the importance of good UX. We bought a bunch of balsamiq licenses and had all sorts of people experiment with it. At first many just enjoyed how easy it was to use but it didn’t take long before design discussions were much more productive.

    We don’t always use wireframes but I know various members of the team use them to try out ideas before they bring them to the table. We also get people to think about the workflow, or the journey, in a simple lo-fidelity process. This helps expose overly complex workflows too, if the process looks messy on the page it most likely is too complicated.

  • Adam Bitner

    For the record, an Axure license is a one-time fee – not yearly. http://www.axure.com/buy