Boxes And Arrows : The Design Behind the Design

The Devil's in the Wireframes

by Liz Danzico on 2003/10/13 | [7 Comments]

Wireframes: At once a singular composition and a collaborative expression, communicating the vision of both an individual and a team. Their visual language must be detailed enough to be widely interpretable, yet particular to different audiences. As a result, wireframes can be stacked with an enormous amount of detail. Are we becoming victims of information pollution in our own wireframes?

Jakob Nielsen recently warned us about information pollution, commenting “excessive word count and worthless details are making it harder for people to extract useful information. The more you say, the more people tune out your message.” This resonated with me (perhaps not in the way Nielsen intended) because of an evolution I’ve seen in my own wireframes.

There seems to be a parallel relationship between level of detail and accepted-ness. As information architecture grows to be a defined step in my company’s process, my wireframes have grown more detailed; more departments must participate in and comment on them.

Once a calculated expression of gray boxes and greeked text, my wireframe has grown heavy with detail, chaotic even, sometimes communicating the desires and requirements of an entire project team. Each layer of detail (and there are many) is intended for a different audience: partial business rules for technologists; a page weight guideline for developers; an idea about a visual system for designers; a justification about “Phase One” features versus “Future Phase” features for stakeholders; even notes to myself sometimes creep into the sidebar.

How did this evolution come to be? And, more importantly, how can I stop it?

In Understanding Comics, Scott McCloud shows how a drawing of an ordinary smiley face can be a more effective representation of a man’s face than a photograph. Abstracting out a smiley face as such allows audiences to focus on the intended detail. Audiences are free to interpret the drawing, projecting their own past experience and meaning upon it. When faced with a photograph of Robert DeNiro’s face instead, the audience immediately makes judgments and assumptions simply because they recognize him.

My wireframes, unfortunately, have become almost photographic.

I’ve realized that it may be impossible to not see the semblance of a design in a wireframe with a lot of detail. A gray bar down the left side may show information grouping to the designer, but is immediately recognized as left navigation to the business owner. Levels of detail intended for audiences of every type are polluting my wireframes, forcing my audience to project their prior knowledge and experience upon them. This, I’ve found, leaves little room for innovation.

• Amplify through simplification.¹
  Ensure that information is presented clearly and plainly. Use wireframes without color, without icons, and without layout recommendations. If there is a danger the audience will be distracted by multiple elements on a page, create separate pages, each illustrating a different point.
• Cut out unnecessary details.
  Is your annotation covered in another document or on another page? Are you communicating something that is outside your area of expertise? Ensure that every item is critical to the wireframe at hand. If the navigation is the same on every page, for example, there is no need to repeat it.
• Annotate thoroughly but relevantly.
  Does your wireframe have to stand on its own? Will you be there to present it? The details you include should match how and where the audience will digest it. If you are presenting to technologists, you might not include all the content strategy recommendations.

The most targeted information—not the most information—allows for an understanding of wireframes that is precise and accurate.