Part 1. The secret li[v]es of sitemaps

Many thanks to Dan Klyn (@danklyn) and Kat King (@katalogofchaos) for reviewing early drafts and thinking.

If you ask what an information architect does, you’ll hear of navigation. Ask what an information architecture is, you’ll hear of taxonomies. If you ask how IAs communicate navigation and taxonomies, you’ll hear of sitemaps.

Imagine a simple sitemap for a simple site.

You could have a homepage. Below the homepage you might have three sections: About Us, Our Services, and Contact Us. Beneath each of those sections, you could have one or more screens.

Figure 1: A simple sitemap could have a homepage. Below the homepage you might have three sections: About Us, Our Services, and Contact Us. Beneath each of those sections, you would have one or more screens.

Our simple sitemap provides a single picture of a website or application. However, this single picture illustrates three, separate things:

1. How content is organized
2. How content is labeled
3. How content is navigated

We can see these three things on our simple sitemap. Placing screens into groups organizes the content. Naming each screen labels the content. Placing screens in a hierarchy implies how the content is navigated. The sitemap suggests that from the homepage, you can choose a section — like About Us — and then choose a sub-screen.

Figure 2: Although a simple sitemap provides a single picture of a site or application, this single picture illustrates three, separate things. How content is: 1. Organized; 2. Labeled; 3. Navigated.

Although the sitemap illustrates how content is organized, labeled, and navigated, the sitemap hides other things. The sitemap assumes an author will organize and label the content, yet we do not see the author. And the sitemap assumes a user will navigate the content, yet we do not see the user.

When we work with sitemaps, we assume the answers to questions about our author and our user:

1. How will the author interact with the content?
2. How will the user interact with the content?

For each item on the sitemap, we assume a user will view the screen and react in some way.

Figure 3: For each item on the sitemap, we assume a user will view each screen and react in some way.

Likewise, for each item on the sitemap, we assume the author will organize and label the content in that way.

Figure 4: For each item on the sitemap, we assume the author will organize and label the content in that way.

Because sitemaps focus on how content is organized, labeled, and navigated, it hides how users and authors will interact with the content. The user and the author are the lives hidden inside sitemaps.

So, why create sitemaps?

When sitemaps document content organization, labelling, and navigation, they document how your team has framed both the problem and the solution. Sitemaps illustrate what Andy Fitzgerald and Dan Klyn have called the rhetoric for the space, the way the team thinks about the problem. Information architecture, illustrated in a sitemap, defines the team’s strategy for solving the problem.

Yet, the sitemap lies.

The sitemap illustrates how the author will organize and label and provide navigation for the content. And the sitemap illustrates how the user will interact with the content. When the sitemap illustrates how the user and the author interact with content that is common to both of them, the sitemap reassures us that the user and the author share the same understanding of the content. The sitemap provides no reason why the author and the user share this understanding. The sitemap merely says it is so. This is the lie hidden inside the sitemap.

Figure 5: The sitemap assures us that the user and the author share the same understanding of how the content is or should be organized, labelled, and navigated.

Or, perhaps, the sitemap does not lie. Perhaps the sitemap does not suggest the user and the author share an understanding. The sitemap shows how the author and the user hope the future will unfold.

The sitemap captures dreams: the author’s dream of how they will interact with the user; the user’s dream of how they will interact with the author.

The real lie is that sitemaps illustrate how content is organized, labeled, and navigated. A sitemap describes how a system helps people share their dreams.

Figure 6: Sitemaps describe systems that help people share their dreams.

Information architecture lives in the dreams we have for journeys and places and people. To architect systems, we must understand these shared dreams. We must understand the metaphysical attributes that underlie these dreams and bind users and authors and content into a shared understanding. We must understand what whats create shared space.

Unfortunately, many systems today are so complex, we can never understand every attribute for every part of the system. To architect systems of shared dreams and not shared nightmares, we must focus on the attributes that matter most for that system.

Part one of a series on what we really do when we create information architectures and how to do it better. Hit “follow” to read part 2 on April 1.

More writing on information architecture

If you enjoyed this, I write about information architecture on my blog, AGUX.

AGUX