It's Time to Leave the Site Map Behind

This is going to shock a lot of people—especially content strategists, UX designers, and information architects.

We need to stop starting our web design projects with site maps.

Sitting in a World IA Day session in 2018, as I watched a brilliant IA draw a hierarchical list of web pages on the whiteboard, I thought this:

What if a site map were actually a map?

Ever since then, I have been steering my clients (and anyone else who will listen) away from the site map as the starting point for defining web content.

The problem with site maps

Site maps are hierarchical lists of web pages. When we start by organizing content this way, we are likely to limit how content is related to other content. We start thinking about how a user might browse the site through the menu structure.

A site map for a ticket seller shows 3 top level items with detail pages as children.

A site map for a ticket seller shows 3 top level items with detail pages as children.

You see, site maps assume a linear path to information. But there are innumerable ways to navigate through a website. Every page is page one!

URLs tend to get the hierarchical structure, which is only one way people will look for and find content. The event I was at might have a URL like this, showing the menu structure that there are locations, DC is one of them, and there is a 2018 event:

/locations/dc/2018

We need to think of site structure and menus, for sure. But we need to stop thinking about site maps as the way to definitively organize information for a website. As Andy Fitzgerald said in Site Maps & Connected Content:

> A site map articulates a set of rules for organizing content without exposing and expressing those rules clearly. ...a site map is one pass at those rules in action. It is the expression of a moment in time.

An alternative to site maps

On the other hand, a content model assumes content is inter-related. If someone ends up in the wrong place, they can go back one step at a time to make a different choice.

Content models are flat. They show all the content types and the relationships between them. They give us about 80%-90% of the content needed for a website and show all the relationships.

A content model for a ticket seller shows all the types of content possible and their relationships. It can be used for an app for an API as well as a website.

A content model for a ticket seller shows all the types of content possible and their relationships. It can be used for an app for an API as well as a website.

That content can be organized into site menus as one way for people to navigate through the content. But the content and the interface also can be designed to be dynamically connected through other means of navigation on any page (local menus, contextual links, and related content, for example).

URLs get defined by what the thing it is and its relationship to like things. That WIAD event would look like this, showing it an instance of an event, no matter how the menus are structured or restructured over time:

/events/2018-dc

Yes, we still need menus. But we must stop thinking about site maps as the only means of organization and navigation. It is far too limiting and not future-friendly. A model-first process helps shift how we think about content and gives websites and other products a better user experience. (And they can all be based on the same source of content instead of reworking for each product. But that's another story.)

We can still create menus and hierarchies based on expected journeys but always provide an escape hatch to get somewhere else. We can no longer afford to build entire websites based on a single set of pathways.


If you want to learn how to create content models and start making digital products for today and tomorrow, join me at The IA Conference 2020 for the Applied Designing Connected Content workshop. Or get in touch to talk about bringing the training to your team.