Sitemaps are ubiquitous. Users can refer to them in the footers of many larger websites, accessibility experts regard them as essential for navigation, search engines use them to more efficiently spider a website, and web design processes around the world prescribe them as critical early planning documents.
But especially in the last case, sitemaps often make little sense in the context of modern websites, especially when there are clients involved. Sitemaps, in the sense that a typical client will best understand them, are hierarchical diagrams of the pages on a website, showing the core structure into which content falls, providing a reference for all pages that will appear on the site, and showing how those pages are connected.
They Used to Work
This was great in say, 2000, when everyone’s website had a nice and complete hierarchical navigation. Home pages were the main connector of everything on the website. Main navigation items led to section pages, which led to interior pages. Huge websites would have subsection pages, sub-subsection pages, and the like, but it was a fairly tree-like structure. Occasionally, one interior page would link to another, but that was the exception, and not a core intended pathway for navigation. Sitemaps were reasonably straight-forward to build and simple for clients to understand, and everyone was happy.
Today’s websites are often far from tree-like. Pages from one area of the site almost invariably link to other areas of the site, and these relationships are important, rather than the exception. Very different resources share common assets — even on this simple personal website, photos, blog entries, and events all reference common locations, tags, and people/authors. Users are now often able to create new content at any time, and build relationships between themselves as creators and other users as consumers. Sitemaps reflecting this modern approach to web design are difficult to create, and potentially impossible for clients to understand.
Yet, despite all this, a sitemap is a common expectation as part of a web design process. We need better tools for communicating a website’s structure that reflect the modern web and that are client-friendly. Below are two options that can be drop-in replacements for sitemaps in a modern web design process.
The Concept Model
Concept models have relatively few rules, and serve a simple purpose: to relay how different pieces of the site relate to each other. There’s a great amount of flexibility in this definition, and this flexibility is reflected in the wide array of forms you’ll find if you look for examples.
Concept models have a few great advantages:
- They can fit almost any site, since they can take almost any form that makes sense to you and your client.
- They can serve as a rough stock-check for content and functionality, allowing you and your client to make sure that no significant pieces have been forgotten. With a concept model, there aren’t really many excuses for leaving something off.
- The complexity of a concept model has a relationship to the complexity of development. It may not be a 1:1 relationship, but if you’re having trouble keeping lines from crossing every other line, and your model is beginning to look like spaghetti, you’ll likely have a few trickier issues in development. If your client is working within a limited budget, this can be an easy gauge to make adjustments early and to help keep the budget within reach.
- They can scale to almost any budget. If you have an hour, you have time to make a very simple concept model. If you have a large amount of time, you can make a very sophisticated and authoritative concept model.
Of course, there are challenges too. Sometimes, the model can be too abstract for a client, and they can’t get their head around it too easily. Other times, it doesn’t show the structure well enough, displaying primary items at a level similar to that of secondary items. Making things as clear as possible is a necessity with concept models.
The High-Level User Flow
Many architects and designers already use user flows as pieces of the design process, and clients are therefore often familiar with them. Since entire sites often have a manageable number of core user pathways, an extension of the user flow model, showing the site architecture from a high-level perspective, can reflect an accurate account of the site’s structure while using a visual vocabulary accessible to the client.
These high-level user flows are best-suited for sites that function dynamically, but don’t have an enormous number of different pieces, as the connections can get a bit out of control given a certain degree of depth.
This method also allows the high-level flow to serve as a table of contents for the lower-level flows within, showing how each of them can fit into the system as a whole.
What other ways have you used to document/demonstrate/relate to others the structure of a website? How have clients or stakeholders reacted?