Wireframes may be used for a variety of purposes, from communicating struc-
tural decisions to the rest of the design team to serving as paper prototypes in
usability testing. Whatever purpose wireframes serve in your process, make sure
you don’t depart from it. Wireframes fail when they try to do too much.
If you’re using wireframes as prototypes in usability testing, their audience will
be the system’s audience. If your wireframes are intended to document design
and structure decisions, they will be used by the rest of the design team. Avoid
making the stakeholders your primary audience since their expectations may be
higher than appropriate for this stage in the project.
The scale of wireframes may be measured on two dimensions: the level of
detail in each wireframe and the number of screens represented in the set of
wireframes. The level of detail is often referred to as “ﬁdelity,” where “high-
ﬁdelity” means lots of detail, or “low-level,” and “low-ﬁdelity” means less detail,
or “high-level.” Confused? This is just the beginning.
Ideally, wireframe creation begins somewhere between high-level structural
work—like ﬂow charts or site maps—and screen designs.
In the taxonomy of wireframes, there are two main species: paper and elec-
tronic. Of the paper-based wireframes, some are sparse, using only rectangles
and labels to represent different areas of the screen. Some wireframes use more
complex design elements, like color, shading, and typography. For the most
part, wireframes are delivered as a set, with each page of the site described on
one page of the wireframes. The tools to create wireframes for printing range
from high-end illustration programs like Adobe Illustrator and Microsoft Visio
to more mundane applications like Microsoft’s PowerPoint. For electronic
wireframes, some design teams use simple, unformatted HTML to represent
the contents of each screen. Often, the experience of looking at these HTML
screens may feel a lot like looking their paper-based cousins. Whether these
simple HTML documents get integrated into the production system is up to
the team’s process, but anecdotal evidence shows it rarely saves any time.
Even ﬁve paragraphs won’t do justice to the challenges of wireframes, and ulti-
mately you must weigh the beneﬁt of wireframes—as a potentially useful initial
representation of the user experience—with the costs, which I’ll discuss below.
Web design teams see wireframes as a panacea—an opportunity to kill many
birds with one massive boulder. With wireframes, you could legitimately docu-
ment functionality, present initial screen design concepts, conduct user test-
ing, experiment with different interaction models, elicit requirements, validate
requirements, prioritize content, review draft copy in context, and much, much
more! Plus, if you act now, we’ll throw in strained team dynamics, stakeholder
wafﬂing, and scope creep absolutely free. (Make your checks payable to the
author of this book.)
Good documents have singular purpose, and the closer they remain to that
purpose, the more effective they are. With complex projects, the temptation is
to stretch your documents to do more. But the more you try to do with wire-
frames—or any document or tool, for that matter—the less effective they will
be in all those things.
For one government agency, a team created wireframes that attempted to show
content priorities, production copy, links, and navigation—ultimately, the site
itself rendered in Microsoft Visio. The document was a mess because it had to
serve four different audiences: the client, the copywriters, the graphic design
team, and the HTML jockeys. It was difﬁcult to keep the wireframe up-to-date
because there were so many people commenting on it. Although the wireframes
were a central place for capturing all decisions, they did not do a great job, no
doubt owing to the strain of competing priorities combined with the limitations
of the medium.
This chapter on wireframes appears in the “what users see” section of the book
because, based on the assumptions above, wireframes are best suited to captur-
ing a design team’s ideas on how a site should behave. That is, the design team
already has an idea of what the site is supposed to accomplish and the wireframes
offer a ﬁrst stab at how it accomplishes its purpose. The challenge is that wire-
frames can be used for other aspects of the overall process, as well—not just to
show design, but to better understand the problem at hand.
If you take nothing else from this chapter, take this: Decide upon a purpose for
your wireframes and stick to your guns. Once you know what the wireframes