Wireframes: From Bar Napkins To Prototypes
Customer-Centricity | Industry Savvy

Wireframes: From Bar Napkins To Prototypes

on / by Mike Hughes

This is a guest post by our friend Mike Hughes

Some of my best ideas were conceived and communicated using a sharpie and a bar napkin. Unfortunately, some of my best ideas were obliterated by a sweaty beer glass.

I’ve also walked into conceptual reviews with exquisitely detailed, working prototypes only to have the review go something like this:

Me: …and then the user would click Submit–something like that–and the back end system will process the new registration. Is this the kind of user experience we are looking for?
Client 1: Could we move the Submit button about five pixels further to the right? It looks crowded.
Me: Sure, this is just the conceptual mock-up, we’ll do a formal layout design as soon as we agree on the features and general work flow. Did this feel like the right flow to you?
Client 2: When you move the button, could you change the font on it as well? I like Verdana.
Me: Uh, yeah, we’ll get into all that when we do a formal layout. Did we capture the information the back end is going to need in order to process the user’s registration? And did the order feel logical?
Client 1: Does Verdana really represent who we are? I’d like to think we’re a little edgier than that.

A couple of points I would like to extract from the two previous examples:

  • Wireframes (or mock-ups, prototypes, etc.) are tools both for thinking about the user experience and for communicating solutions.
  • Wireframes come in different levels of sophistication or fidelity–each with its relative advantages as well its inappropriate circumstances.

In this article I will examine the different types of wireframes and discuss their benefits and limitations and where in the design and development life cycle they best fit.

The Fidelity Spectrum

It is useful to categorize wireframes along the dimension of fidelity, that is, how accurately or realistically do they convey the user experience? At the low end of the spectrum are crude, hand-drawn sketches–like my medium of inspiration, the bar napkin. On the high end are realistic looking functional prototypes that allow realistic interactions that let the designer fully explore and test the user experience.

When describing the fidelity of a wireframe, three attributes describe how realistic or true-to-life the wireframe is:

Appearance–At the low end, a wireframe looks hand drawn. At the upper end, it looks exactly the way a final user interface would look. In between you might find things like screen blueprints done in Visio, or screen mockups in Powerpoint.

Medium–How realistically a wireframe can convey the user experience will depend a lot on the medium. Wireframes done on paper are less faithful to the user experience than wireframes done and demonstrated on computer.

Interactivity–The true ability of a wireframe to explore and communicate a user’s experience will often depend on its ability to simulate the ways the user and program interact with each other. Low end wireframes are static; high end wireframes cannot be distinguished from a functioning product.

Relative Advantages and Disadvantages

Low fidelity wireframes have some distinct advantages:

  • Quicker, easier, and cheaper to create and modify
  • More encouraging of feedback
  • Easier to modify or throw away

Low fidelity wireframes are great for early exploration of the “big ideas.” They’re cheap, stimulate criticism (people aren’t afraid of hurting the designer’s feelings), and anyone can jump in and drive (no tool knowledge or drawing skills required).

They come with disadvantages, however:

  • Generally not to scale (Hmmm, that column heading called “Undone tasks not yet accounted for by a process deviation request” seems to be causing some horizontal scrolling we hadn’t anticipated.)
  • Limited ability to watch users interact with the system
  • Inability for some to envision the user experience in the real technology

Low fidelity wireframes are risky for getting approvals or building consensus. There’s a good bit of “Oh, that’s not what I thought we were talking about” when the thing everyone agreed on actually gets coded.

For example, everyone might buy into the concept of the home page graphic:

Concept of the home page graphic. What’s not to like?

But not everyone might like the final version that gets released:

Final version of the photo that gets released.

On the other end of the spectrum, high fidelity wireframes come with their own set of advantages and disadvantages.

The following are distinct advantages:

  • Less room for misinterpretations
  • Ability to interact with the design
  • Ability to test for usability issues

On one design team I worked with, we used Axure to do our wireframes. It has the advantage of providing highly interactive HTML outputs that let you simulate some fairly sophisticated interactions. The high fidelity of these wireframes let us conduct valid usability tests before anything had actually gone to coding. It required what I call “scripted” scenarios. For example, you might ask a use to register as John Smith. If the user misspelled John as Jon, the next page would still say “Welcome John” because we weren’t actually connected to anything on the back end. Still, we could run some very realistic tests and get useful information.

Also, the higher the fidelity of the wireframe, the less likely you are to have expectation/reality gaps when the product comes out of Engineering.

But high fidelity has its disadvantages as well:

  • Time consuming and more expensive to create
  • Assumption of a completed interface (pixel pushing occurs a lot!)
  • Less encouraging of feedback (People are less likely to criticize a design they think is “wrapped up.”)
  • Easy for designers to become emotionally attached

The higher the fidelity, the less likely the user is to challenge the overall approach of the design, but, ironically, the more willing they are to focus on cosmetic details. For example, if you are usability testing your user assistance with high fidelity mock ups of the Help System, the user is more likely to wordsmith but less likely to challenge the usefulness of the information.

So high fidelity is not good for “what if” brainstorming, but is good for getting consensus that stays intact when the product is actually built. High fidelity wireframes are also useful for usability testing because they simulate an accurate user experience.

The following figure illustrates a general guideline for choosing the appropriate fidelity of wireframe.

Guideline for choosing the right level of fidelity.

In brief, the lower the usability risk and the earlier in the development life cycle, a low fidelity wireframe is probably preferable over a high fidelity one. But as the design concept matures or if the solution must be very usable, then consider going with a higher fidelity option.


Ideally, you should have several tools at your disposal so you can produce the appropriate level of fidelity. Here are two links to websites that compare different wireframing tools:

I have personally used bar napkins (yes, I really have), Axure, Pencil, Visio, PowerPoint, and Balsamiq Mockups. My tool of choice these days is Balsamiq Mockups because it has a hand-drawn look that works well for where I work the most–doing conceptual designs during requirements refinement. At my previous job, where I designed consumer bill pay software, I used Axure so I could create quick prototypes for usability testing.


Agile has a good point when it says that documentation should only be just barely good enough. What that means is put no more effort into design documents than is needed to make the decisions at hand and drive the needed development.

Wireframes come under this caveat, and wireframes only have to be realistic enough to support the decisions you need to make at a particular stage in the development. Questions like, “What do you want it to do” or “Roughly, how much would it take to build” or “Would this be useful” can be handled with low fidelity wireframes. Questions like “Will it be usable” or “How exactly must it look and work” require higher levels of fidelity.

One last consideration, the more ideas you can “draw up” for the same cost or time frame, the more ideas you have to choose from, so don’t let over investment in fidelity unnecessarily constrain your idea pool.

| |
Article by

Mike Hughes

User Experience Architect. Software designer, fisherman, dobro player. Owner of the blog The Humane Experience.

Share your thoughts

  • I have an imaginary boundary I like to call the “fidelity line” and it’s usually the client that crosses it. However, I find that if I conduct live wireframing sessions—rather than design critique/feedback sessions via email—solutions are reached quickly and often save hours if not weeks of total project time.

    Face it folks, fidelity is funny. Btw, love the cute dog!

  • I like the valuable info you provide for your articles.
    I’ll bookmark your weblog and take a look at once more right here frequently.
    I am somewhat certain I’ll learn plenty of new stuff proper here!

    Best of luck for the following!

Pin It on Pinterest