Sitemaps: Essential or Essentially Useless?
Sitemaps developed out of a simpler time in web design and development.
Back when a page was a page, all you had was a big block of text you got to by clicking a menu link in a list. All pages were the same. All layouts were the same. And for a time, it was good. People called the page by a name, grouped it with other similar pages, and put it under another name.
Gee, I wonder where that idea came from?
And it wasn’t a bad idea and worked for a good long while. It still does, to some extent, in certain situations. But "The Sitemap" is no longer the master deliverable it once was. The web is too organic, too intertwined to plan using only menu trees.
What Sitemaps Are Good At
This is not to say sitemaps are completely useless nowadays. To the contrary, they are a good starting point for any web project. They help communicate quantity of content, align stakeholders to organizational concepts and do a decent job at communicating scale, something that is often elusive in big redesign projects. Sitemaps are useful for:
- Identifying places and destinations a user can go
- Defining simple 1:1 relationships (hierarchy)
- Communicating scale of a site to teams and stakeholders
- Clarifying trigger words/nomenclatures of page titles
- Meta/URL info for search
What Sitemaps Suck At
As the web becomes increasingly complex, however, so too are the systems we build. This makes planning and design ever more complex. Sitemaps are tools never designed to handle such complex ideas. They are hammers in a world of 3D printers. So, often get in the way when we’re planning the relationships between content. Yet, people still use them as the end-all-be-all deliverable in the website design process. Sitemaps come up short when we’re:
- Defining the business goal of any page/section
- Defining the user intent that the page exists to solve
- Defining all the various content, parts and functionality on the page
- Defining non-hierarchies (many-to-many) relationships of the content
Now, you might be asking “isn’t all that what the wireframes are for?” Well, sort of. With the increasing density in layouts and content, what constitutes “a page” is changing. Now, you might have a single page that does the work of 10 pages in the olden days. A sitemap only deals with what the user clicks on to get to the page, not with what they see when they get there.
A long form page example from Unbounce which serves the purpose of multiple traditional "pages" in one.
Wireframes are great, but you can’t wireframe every page, at least not with the thousands of pages that make up some companies’ websites.
The problem compounds further when we start to think with a many-to-many mindset. For example, let’s say we have a page like this that we built for Colorado PERA. Some of the content (files, papers, guides) do not live “under” this page in terms of a traditional hierarchy. You won’t find them on a sitemap. They are individual pieces of content, referenced from several other places on the site. A sitemap does little to help map such relationships.
Take another example: The classic IA problem of whether to put products under “Solutions" or “Industry” or duplicate it in both. Google would say it shouldn’t be duplicated, but even if that weren’t the case, who wants to manage duplicate content? Product information belongs both places. It’s the same content, shown in two areas within the right context. Multiply this problem by X pages and X pieces of content and you have a “sitemap” that resembles something akin to the human brain rather than file folders sitting on a desk. At that point, the visualization isn’t helping you see anything other than a big mess.
So What Do We Do?
Unfortunately, there is no magic method to bring all these aspects of planning a website together in one simple deliverable. But when a problem gets too big, we like to break it into more manageable parts.
More like a mindmap, conceptual sitemap describes basic hierarchy and is only used to determine the most basic divisions of content from a user perspective. We often start here. The urge should always to be to condense and collapse when possible, cutting and consolidating to the smallest possible sections. We’ve found that creating a conceptual sitemap on a whiteboard helps to:
- Get teams and stakeholders conceptualizing large areas of interest on the site
- Provide an easy format to test assumptions (ask a user what item in a bulleted list they would click on to find a certain piece of content)
- Identify big “black holes” of content, or areas with deeply dynamic content (knowledge bases, press release archives)
- Align content to user needs to plan what content should be where to help users solve their problems
A sample conceptual sitemap from a real whiteboard.
Sounds fancy, but content prioritization is simply making lists. Lots of lists. But the idea is that once you have a conceptual sitemap in mind, you can start building out lists for each section, specifically around which user needs pertain to that general area. Be careful, though! Resist the urge to make these pages. They are simply ideas at this point.
Then, you ask, “What content do we have that might help a user interested in X (aka the menu item)?”. See if you can get it all on one page, and don’t worry where it’s coming from. Too much to present in a single page, even with a long-form layout? Divide and repeat. Using this method, “pages” become “groups" of content that can then be laid out in a prototype that is content-driven and user-focused. But, once again, many areas might be sharing bits of content. You’ll start to see patterns during this process as well, things you couldn’t see by naming pages in a menu-bubble format.
Layout systems are how we build prototypes for “pages,” which are comprised of blocks of related content that could be coming from all over the site. We assign these layout groupings names like “Modular Overview” and start to flesh out where they will be used, and what content would be pulled into it. In this way, you only need a few “pages” and a good sense of what is coming from where to help build out the site. Taxonomy and content models can help you figure out the details.
Layout system for a collection of websites designed for Comcast.
Your rich, content-driven pages may have things like “related testimonials” or “blogs in X category” as part of their makeup. Now you need to start mapping all the different types of categories to use. In the case of a Drupal website, these terms are what tie content together. This is because the taxonomy on a page can determine the relevant content to pull. All you need to do is understand how you will identify the right content. The CMS will take it from there.
With your rough layouts, taxonomy and priorities, you can get to the meat of the work: a content model. Content models are the new sitemap. It’s pretty simple: a library of every kind of content on the site, regardless of where it might go. Down to the type of field and length of character, every content model defines what makes up each type of content. Using taxonomy mapping and the layout systems, content will populate the right places on the site like magic.
Once you have these other ideas in place, now you can polish up the “sitemap.” I use the term loosely because it still doesn't describe everything. It actually might feel rather empty. In the case of redesigns, sitemaps often end up being much, much smaller. Why? Because all the information is condensed into fewer, more effective pages that are designed to convert. Less is more, as they say.
In this way, by using a suite of tools and deliverables (rather than the good ‘ol sitemap alone) a complete picture of a website can form. It’s difficult to describe organic systems using static tools, but one has to start somewhere. Our approach focuses on organizing ideas to get something real as quickly as possible.