several different versions, consider the tools you’re using to map the sitesome
may offer features to make this easy. Microsoft Visio, for example, has a layer-
ing function that allows you to hide or show different parts of your drawing.
Regardless of how you make it happen, you can create different versions that
show different aspects, so one version might focus on the technical issues and
another on the editorial issues.
You can also go in the other direction, showing too little information. You
might not show enough detail about the site itself, missing categories of infor-
mation or failing to account for pieces of content. Site maps play a role in this
failure because they hide an underlying chaos of web sites. Seeing sites repre-
sented cleanly as boxes and lines makes it easy to forget the spaghetti-like struc-
ture that’s really there. Your urge to make the site look clean on paper
may overwhelm the need to capture the details accurately.
The best way to avoid oversimplification is to capture the data outside a site
map first. A site map is a visual tool for representing data, nothing more. Before
building a site map, perform a content audit or content inventory, creating a list
of what you need to document. Even if your site map oversimplifies the site,
you can always go back to the raw data to validate the visualization.
At some point youll need to gather the project team together to discuss the site
structure. A site map can be an effective document, but it contains complex
and sometimes controversial information. The only way to work through these
issues is through a meeting. Or two.
With any design deliverable, there are three reasons to gather the troops together.
At one extreme, youre simply providing an introduction to the document,
expecting nothing in return. At the other extreme, you’re expecting stakeholders
or team members to apply their seal of approval. In the middle of the road, you
are working with an incomplete document and seeking feedback.
Regardless of purpose, your meeting should include an account of the project
context—where you are and where youre going. A site map, while providing
some concrete information, can feel very abstract to participants and it can be
easy to lose the thread of your design process. By telling a quick story at the
beginning of the meeting, you can help project participants locate the site map
in the overall project. You might say something like this:
OK, we finished our content inventory—remember we went
through the high points last week—and we’ve been looking at
all the content and have come up with a site structure. We’ll
look at that today. This site structure is just a draft, and
we intend to test it in the next few weeks. We’re working on
devising the test mechanism and we can discuss that at the
end of this meeting or run through it at our status meeting
on Wednesday.
What distinguishes an introduction meeting from the others is that you’re not
digging into the details of the site structure. The purpose of the meeting is to
get the team on board with the document, educating them enough so they can
look at it themselves. There are three key pieces of information you need to
First, you need to help them understand the document itself, especially the
visual conventions you may be using. You dont need to walk them through
the entire document, but you should point out major concepts and explain
the visual system—what each of the shapes mean, how you’ve grouped things
together, and other elements that might contain meaning. You might use a key,
a box off to the side of the page that describes each symbol. Good visual design,
they say, shouldnt require a key. But, frankly, I dont know who “they” are,
and they’re certainly not the ones in the room presenting the site map to your
Once you’ve given the participants an overview of how the document works,
the next information to cover are the major design highlights. The intent of the
meeting is not to run through every detail, but you still want to give meeting
participants a sense of the key design decisions. To decide what counts as “key
or “major,” think about which content areas will be the most surprising to
stakeholders, and which represent important areas for customers. Working on a
site for a major airline a few years ago, my team consolidated disparate customer

Get Communicating Design: Developing Web Site Documentation for Design and Planning now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.