What is a wireframe?

Depends on who you ask. I like to define a wireframe as equivalent to a keyframe in a storyboard. (The problem is that most websites are not linear, but that’s a topic for another post.) I’ve done thousands of wireframes in my career as an Information Architect/Interaction Designer (have we settled on an appropriate title yet? I guess not). I don’t live for wireframing, even though making them is one of my most marketable skills. I have developed a very pragmatic view of it, having seen how my wireframe “bibles” are clung to by business customers, salespeople and QA, and then unceremoniously forgotten after the first beta launch. The tricky thing about wireframes is that they can mean different things to different people, depending on what stage of the project you’re in.

So now I have developed a Zen-like detachment with wireframes: they are ephemeral. In fact, I make it a habit of suggesting to clients that we schedule into the project plan a wireframe bonfire, usually sometime after launch. Every time, I get a double take and a laugh of disbelief. Why a bonfire? To emphasize the reality of the end goal, the working application itself. Users don’t use wireframes. Also, I want to make the point that wireframes are dead and the application is alive, that decisions that may have looked great on paper may, in reality, not work when put in front of real users.

The Evolution of Wireframes

Wireframes need to evolve over the course of a project. For larger projects (3 to 9 months) I’ve found it useful to clarify both for myself and the business customer what to expect from wireframes at different stages.

Lo-Res

In the nascent stages of a project, when ideas are being thrown about by all stakeholders and everything is in flux, lo-res wireframes may appear on anything from whiteboards, scrawled on the backs of napkins or scrap paper. Think of them as thumbnail sketches.

Lo-Res wireframes should be

• Sketchy
• Loose
• Quick
• General
• Monochromatic

Usually, I will gather these scraps of paper and translate them into digital roughs.

Note the “default” style for everything:

• Labels should be descriptive of the content. Avoid using real copy (except for logo)
• Content areas are grey blocks with the label in the top left corner
• Multimedia or graphics are indicated by a different grey box, with label centered in middle
• Buttons are indicated by rounded corner and centered label text

Not using copy is important at this stage because you don’t necessarily want the client focusing on details yet. It can be distracting from the larger goal, which is that you want to get agreement and sign-off on basic proportional representation of types of content and their general hierarchy. At this stage, you should be able to use this to answer the question: What are the primary, secondary, and tertiary content blocks on the page?

Medium Res

Once you have established what content needs to appear on the page and have a good sense of their general hierarchy, you can start to add more detail, in the form of more realistic headings, navigational copy, and basic indications of functionality.

As you can see, there’s a little more resolution here, like you’re adjusting the focal length so that you can make out more clearly the major elements of the screen. But you’ll notice that not everything is in focus yet, namely the body copy, which I like to represent as grey bars to give an idea of type density without getting bogged down into specifics yet.

I’ve found that once you start introducing dummy copy and dummy data, the viewer’s expectations and reactions start to change, regardless of your frantic entreaties to disregard such characteristics. There is a point at which our attention begins to hone in and we start to notice certain elements, unconsciously or not, and it takes all of your discipline and awareness as creator of these documents to modulate the viewer’s expectations through the blurring and smudging of various elements (at one point I considered applying a “Pencil Sketch” filter in Photoshop to my wireframes). But at some point, you will have to address these things, such as color, highlighting, typography, dimensionality, and data, which will bring your wireframes to to a higher level of resolution and expectation.

Tomorrow: I’ll dig up some Hi-Res wireframes and talk about clickable prototypes, the ultimate in high-resolution wireframes. Stay tuned!

Tweet This Post