Skip Navigation

When Sitemaps Don’t Work: Two Alternatives

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.

Simple Sitemap

Sitemaps, like the simple one shown above, can be a great and simple way to relate the structure and pages on a hierarchically-structured site. (Credit: Andrew* on Flickr)

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.

Flickr concept model

Perhaps the most famous example of a concept model is that of Flickr. At its highest level, it’s easy to see that Flickr is a site for users to display and catalog photos they’ve taken, but it’s also easy to dig down into many of the details that make Flickr such a great service. (Credit: Soldierant on Flickr)

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.

SpeakerRate high level userflow

I whipped out this user flow of SpeakerRate really quickly to demonstrate how a simple, high-level flow can be created to relay the overall structure and imply a navigational structure at once.

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.

Others?

What other ways have you used to document/demonstrate/relate to others the structure of a website? How have clients or stakeholders reacted?

By the way, since you've made it to the bottom:

  • You should subscribe to my RSS feed here.
  • You should follow me on Twitter here.
Avatar of M. Jackson Wilkinson

I'm M. Jackson Wilkinson, a technologist, designer, speaker, educator, and writer in San Francisco. I'm the Founder of Kinsights. I'm from Philadelphia, went to Bowdoin College in Maine, root for the Phillies, and love to sing.

Recent Entries

Diversifying Your Design Strategy

Smart consumers balance risk in their financial investment portfolios, and smart designers should consider design and product investments the same way.

Consider the Product

The best thing about product design is its inherent contradiction. The best products think of everything, but at the same time, they’re focused on exactly one thing. If you can wrangle that, you’re almost there.

Identifying the Real Issue with Web Fonts

The recent .webfont proposal and TypeKit service don’t seem to get us anywhere closer to terms that type foundries should embrace. So why are they embracing them?

Seeing the Forest for the Trees

The broader the web gets, the more specialized its practitioners are becoming. The role of the generalist is incredibly important, and we can’t keep neglecting it.

The Shackles of Simplicity

Though simplicity is the darling of the web, we’ve now long outgrown it. Life is complex, and tools to conquer life’s complexity need to instead embrace it, rather than ignore it.

View all entries

Comments

  1. The complexity of a concept model has a relationship to the complexity of development.”

    Excellent point. Sitemaps have a bad habit of underestimating difficult areas…a little page marked “photos” can incorporate dozens of behaviors, but if they all happen onpage, it looks ridiculously simple on a sitemap.

  2. I have to disagree with the notion that sitemaps should be replaced by concept models and user flows. If anything, it's best served alongside those two documents.

    • The concept model tells the story.
    • The sitemap serves as page/view inventory organized according to the structure of the site needed to support the concept model.
    • The user flows describe the inherited pathing thru the inventory as spoken to by the concept model.

    From my viewpoint, one flows into the other.

  3. Thanks for the comment, John. I think you're right that often, they probably do flow into one another.

    If you're using a sitemap as an inventory of pages, then neither the concept model nor a high-level user flow can serve this purpose. However, organizing sites by pages like a typical sitemap can be an incredibly challenging job these days, which can end up wasting a substantial portion of the budget if a simple list inventory would do.

    Even then, a sitemap only works when your client can relate to it, and if a client is used to having a sitemap tell the story, it can be a stumbling block.

    I think that any of the three can tell the story, and while only a sitemap (of the three) can play the inventory role, it's sometimes not the best tool to do so.

  4. Great points! Any good tools for putting these together? I've been messing with graphviz for banging these out really quickly. I almost have it so I can go from a small bulleted list to a sitemap pretty toot suite.

    The concept model seems to be a nice next step from a discussion that collects stories on stickie-notes too…

    CG

  5. @CG: For this type of work, OmniGraffle is my typical hammer for any nails I encounter, but certainly there are many tools that could do this kind of thing. Anywhere from InDesign to Fireworks to Visio, and I'm sure GraphVis can do well in this category too, though I haven't really used it much.

  6. I think it's a question of the right tool for the right job.

    In 1999, a hierarchical site map was a Swiss army knife of UI in that it could describe the user flow, the service offerings (usually in their tidy little stacks on the tree), and even a list of all the files that needed to be created.

    Currently, such a site map is (in my opinion) nearly useless. Its only remaining strengths - as a very broad description of the primary navigation tree and as a list of primary files - are better (and more quickly) depicted in a simple indented text outline.

    The concept model works much better to help the team flesh out the site's purpose and promise, and visually determine where the services will fit the goals.

    The site flow becomes a utility to literally walk a user though those services towards their goals, to make sure what we're building is the best possible structure for the concept we've established.

    None of the tools replaces any of the other tools (except for the tree diagram itself being outdated), and each is made stronger by the inclusion of another.

Add a comment


Real names, svp.


Required, but I won't use it for anything, promise.


It'll get checked to make sure it's legit, but it's optional.


Don't be mean, don't be a tool, and make a contribution. Use markdown.