Boxes And Arrows : The Design Behind the Design

Real Wireframes Get Real Results

by Stephen Turbek on 2006/09/19 | [38 Comments]

How many times have you been asked, “So, is the new website going to be black and white too?” after presenting your wireframes to a client or a usability test subject?

This question is almost a traditional part of being an information architect. Wireframes do not clearly define what they mean to convey, leading to confusion. This is most apparent in wireframe usability tests with users who don’t know anything about the project or process. Fortunately, there are a few simple steps that will make wireframes be understood by anyone. They don’t even have to be much more work. It’s simply a matter of choosing to “get real” from the start.

Real people don’t understand wireframes
Usability tests are done to get early feedback on content and functionality decisions from people outside the project team. These participants, unfortunately, are not sure how to respond to a wireframe. It is not intuitively clear what they should be doing, which site they are looking at (public site, intranet, client site)—it may not even be clear that they are looking at a web page. This lack of information and context adds a bit of cognitive friction to each step in the process. This level of confusion results in less confident answers and fewer opinions.

Wireframe tests usually take place with well-meaning, but unsophisticated users. They generously accede to poking and prodding and answer questions as best they can, despite not exactly understanding what is wanted. This realism gap is due to the lack of definition of what should and should not be looked at. “Look at the field names but not body copy.” “You can look at the forms but not images.” “Comment on the page layout but not design, and, yes, the font size but not font.” It’s no wonder that the layperson is confused.

Visual affordances, such as color and underlining links are key to using a site, and these cues make a significant difference in a usability test. Users cannot confidently predict how they would use a page if they don’t recognize links or can’t read what the page expects them to. Information architects, however, tend to shy away from these cues because they don’t want to step on designers’ toes. Wireframes, after all, are not designs.

Or are they?

Avoiding “design” elements removes visual cues that users rely on:

* Color, which identifies hyperlinks and focuses the user’s attention on an element of the page * Branding, which confirms that the user knows where they are * Recognizable web page elements, such as forms and search fields * “Content,” such as account numbers or product names, which allows experienced users to focus on how they would really use the page, instead of interpreting “lorem ipsum”

The boundaries of the role of the information architect shouldn’t be more important than clarity.

Originally the term “wireframe” referred to a quickly rendered 3D model showing the model’s structure used while the model maker was working. They were much faster to work with than the full rendering. Interestingly, they are not currently used as modern tools and techniques are fast enough.

Why wireframes?
Information architects construct wireframes instead of designing final pages, in part, because:

# Wireframes are faster. # Information architecture and design phases can happen in parallel. # Wireframes force viewers to focus on the content, not the visual design.

Notice anything? All these goals are internally focused on the project-team. Wireframes aren’t created for external audiences.

Figures 1,2: Originally the term “wireframe” referred to a quickly rendered 3D model showing the model’s structure used while the model maker was working. They were much faster to work with than the full rendering. Interestingly, they are not currently used as modern tools and techniques are fast enough.

Wireframes are conceptual models of a page that web design teams have become to interpreting. Each wireframe is surrounded by experience in reading them, knowledge about the project scope, knowledge about how the designer will use the document. Liz Danzico writes about this wireframes becoming project memory in the article “The Devil’s in the Wireframes.”

Just because project teams understand the purpose of wireframes, that doesn’t mean everyone will. Similar to listening to someone sing out loud to his iPod: we only hear the singing, while the person hears the whole orchestra. Likewise, the test subject knows only that “the page isn’t going to look like what they see,” but what they see is all they have to react to.

Wireframe makeover
Here is an example of the simple steps to transform a standard wireframe into a realistic wireframe. In this example, let’s say we are designing a registration process for Verizon.com (no special criticism is intended for the site below).

The site we are designing for Verizon.com:

Here is a standard wireframe:

And here is the same wireframe, made more real. (An additional 10 minutes was required to use the standard header and a library of realistic form elements in Visio or InDesign.)

And here is a version re-using Verizon’s standard buttons and clip art. (Additional time: two minutes.)

Which do you think would be easier for test subjects to understand?

Tips to get real
These tips are best for intranets or sites with defined styleguides, and less useful for graphical or marketing pages where the design is the content of the page.

# Make a header bar with the company branding. It should look like the site they are used to, showing the company logo. # Use color. Hyperlink color is a basic requirement. # Put a web browser frame around the image (or at least the first page). # Use real form elements, not drawn replicas of them. # Create a template or library of real form elements (feel free to share yours in the comments below). # Avoid lorem ipsum. Instead, use: “Descriptive text that will explain this product.” to avoid confusion about greeked text. # Use accurately sized fonts (this also keeps you honest about what can fit on the page). # Use real detail such as products names and data. Especially on transactional tools with expert users, users care about what they are reading and recognize and use data like account numbers. It may not be important to us, but they have expectations that need to be met.

Compare the wireframe to the current site, note any changes in functionality that may trip them up.

The page doesn’t have to be perfect, just enough to give the test subject their bearings. A semi-designed page is easier to understand than a non-designed page. This is not wasted work; these decisions need to be figured out at some point. Consider bringing designers into the process earlier, cooperating on file formats and processes. It might even make their jobs easier.

Are traditional roles limiting projects?
Wireframes are in fact the first design iteration, and this overlap with visual design can be uncomfortable for teams. However, denial is not the way to fix this issue. Good collaborative relationships should make this overlap an opportunity to reduce work, not fight over ownership. Concern that wireframe might be mistaken for a visual design, or worse, be criticized for lacking design, may be holding the entire project back. It is much easier to communicate within the project team than the outside audience.

Consider these and other ways to make the transition as smooth as possible, for example, by having the wireframe be designed to import into the designer tool without retyping all the text.