Flag

We stand with Ukraine and our team members from Ukraine. Here are ways you can help

Home ›› Design ›› Is the Sitemap Losing Its Client-Facing Steam?

Is the Sitemap Losing Its Client-Facing Steam?

by Vincent Au
8 min read
Share this post on
Tweet
Share
Post
Share
Email
Print

Save

Keeping the sitemap useful and relevant as the complexity of sites increases.

Lately, I have found myself questioning the effectiveness of the traditional sitemap as a stakeholder-facing deliverable. The main goal of a site map is to provide a holistic look at a site’s (or application’s) structure—that is, to answer the big question of “What goes where?” These days, however, site structures are not as simple as they were in the early days of the Web, and the “positions” of pages, functions, etc., are not so cut and dry. As the Web has evolved to include larger, more complex sites, it has become increasingly difficult to create sitemaps that stakeholders and clients can interpret with speed and ease.

The Sitemap: A Quick Primer

A sitemap is the first tangible step towards the creation of a site. In conceptualizing a sitemap, one is visualizing a site as a whole. The process requires—and, in many instances, helps improve—knowledge and an understanding of what this site will be, what content it will contain, and what its scale will be. Sitemaps identify site structure and—to an extent—content types, and also help define the building blocks of the user experience. Sitemaps show us what goes where and—again, to an extent—how pages are connected, thus showing what paths users will take to get to their desired destinations.

Building a website of any scale without having any of this documentation is a bad idea. It lets things slip through the cracks that have to be shoe-horned into the site late in the process, making things messy. In addition to all of this, stakeholders rely on sitemaps as a status-checking tool to ensure that their sites will accommodate the content they require, and that the navigation matches their needs.

Using a fictional portfolio site as an example, the traditional sitemap generally looks like this:

Example traditional sitemap diagram

At the very top is the homepage, followed by the main navigation. Beneath each of those items are the pages that fall into those sections. Below that, there are the “floating” footer, header, and modular site-wide elements. It’s easy to get a sense of the site at a glance, with all the pages and elements it contains. It’s also easy to notice any glaring omissions or snafus. If I took a look at my sitemap and decided to shuffle things around and add some additional items, it would only take a few minutes to make the changes.

So, What’s the Problem?

That kind of basic diagram works well for small and simple sites, but things get tricky for larger, more complex sites and applications. Take Facebook, for example. There isn’t a standard primary navigation like there is in my portfolio site example, or in a site like nytimes.com. In complex contexts, the traditional sitemap has a few failings.

Firstly, many sites are too large to be represented in a single diagram. The Web is now the primary destination for written content. Content-heavy sites such as Yahoo! and CNN have seemingly limitless numbers of sections and pages; their homepages act more like portals to several sites that all fall under one umbrella. Representing such enormity in a static sitemap is almost impossible. One trick that works fairly well in this situation is to create a high-level sitemap only showing two levels of depth, followed by more detailed, section-specific sitemaps. This is a simple solution to represent large brochureware (corporate or editorial websites such as ge.com or soccernet.com, for example) while sticking with a familiar model.

But what about sites that aren’t quite so simple? These days, dynamic content is king. Real-time updates from various sources populate webpages that are refreshed automatically. Sometimes these sources are pulled from different areas of the same site, sometimes they’re drawn from external resources, and sometimes they are a mix of both (e.g., Digg). Illustrating the relationships between a site’s various sections and external resources is challenging, to say the least.

My general principle for information architecture and interaction design is to take the complex and make it simple—whether working on data display, interactions, or stakeholder-facing documents. While there’s technically nothing wrong with presenting complex deliverables, it does increase the risk of confusion, and confusion does not usually lead to confidence. Presenting stakeholders with complex deliverables grates against my goal of taking the complex and making it simple, but the ongoing trend of dynamism and interconnectedness of websites is forcing greater complexity in our structural diagrams. But if we are able to take complex user paths and interactions and make them simple and easy for users, surely we should find a way to do the same for our stakeholders and the documents we create.

It’s also a challenge to illustrate a holistic view of a site that has a nontraditional navigational structure. Social websites in particular aren’t organized in ways that conform to ordinary modes of hierarchy and structure. Taking Facebook as an example again, it’s very difficult to determine at what level an “Event” or “Place” resides in relation to a person’s profile or an application.

A Possible Alternative

For these complex cases, diagrams based on the concept map model can be useful. A typical concept map consists of a collection of nodes that represent individual concepts, linked to each other by arrows that represent their relationships. These arrows are typically labeled with relationally relevant phrases like “includes,” “is necessary for,” etc. The concept map is a far more flexible diagram than the typical sitemap, so it can be used as an alternative presentation of structure and interrelationships. Different shapes can be used to differentiate external content sources from internal site pages, functions and elements from actual pages, etc. And, because concept maps don’t follow a tree structure, they can display more fluid structures fairly well.

Example concept map

The example concept map above is a high-level representation of a simple game-based social network. The legend indicates that the dotted lines link pages and their content sources—some of them external, some of them internal. Structure isn’t shown as standard parent–child relationships, but rather as a more circular structure. This allows for the easier display of relationships between pages on the same level, and is a more accurate depiction of how the user might experience the site if the traditional concept of the “main navigation” does not apply.

Sadly, like all solutions, concept mapping is not perfect. Displaying all of this information can lead to a diagram that is overwhelming, messy, and difficult to interpret for people who are unfamiliar with concept maps. This particular drawback is actually more significant than one might realize. Information architects (IAs) are hired to not only organize content, but to also develop experiences and interfaces that are satisfying and usable. Providing stakeholders with documents that are difficult to comprehend could easily make them question the IA’s ability to deliver user experiences that are usable and comprehensible.

The risk of overwhelming stakeholders with information is a problem that connects directly to my aforementioned general principle of information design: less is more, so hide (or remove) what people don’t need. While this is simple enough to do when working in an interactive medium, static documents are another story.

Looking Forward

This brings me to my ideal solution: an interactive hybrid site diagram—one that integrates wireframes and site/concept maps into an easy-to-use mini-application.

Example interactive concept map

Above is a low-fi mockup of how this could work. On the surface, it appears to be very similar to the regular concept map. The main difference is that users of the hybrid site diagram can filter out the information they do not want to see. They can also view the map from the perspectives of different personas and scenarios. By clicking on one of the personas, a description of the user and his task-flow is shown while the map adapts to show that user’s path. Clicking on any of the page nodes will display the wireframe of that page. The wireframes, too, could then be interactive (to a point, of course), allowing the stakeholder to get a feel of how the site experience would be for users.

However useful this sort of map would be, though, introducing it as a deliverable in the middle of a project-cycle would likely require more time and resources to create than are typically available. However, if one were to devote time and resources to develop this deliverable as a side project, outside of client-billed hours, it would be a fantastic resource to the project team.

Even more useful would be the development of a framework that is flexible enough for a variety of projects and users. If a small team were to develop an application that allows for the easy creation of interactive maps, it would be a real boon to the information professional. Ideally, this application would be adaptable enough that its users would simply need to input some data (persona info, site content, relationships, and so on) and, presto: an instantly generated interactive concept/site-map hybrid.

For Now, Though, Pick What’s Best for You

Sadly, most of us aren’t able to create such an application. So in the meantime, while we wait for someone to create and license it we should remember this: before deciding on which deliverable or set of deliverables to provide to stakeholders, it is important to think about the context in which they are being delivered. That is, the type of site/application we are creating, the familiarity of the stakeholder with IA diagrams, the stakeholder’s personality, and the stakeholder’s patience level and attention span (the latter two are too often disregarded, I find).

The right deliverable is based on the above factors, and the solutions I have proposed do not comprise an exhaustive list. There are a lot of other potential solutions to this problem, including:

  • Scenario-based sitemaps
  • A series of concept maps, each showing greater levels of detail (first pages, then content sources, and so on)
  • Userflow/sitemap hybrids
  • Highly annotated navigation studies

The sitemap will certainly evolve. I can imagine a future in which all visual deliverables are presented in a single, cohesive interactive digital package that is readily accessible online and can be downloaded and used locally. It will be some time coming, though, so until then the sitemap will endure. It may, however, find itself moving towards an “internal document” status like the many complex UML diagrams created by developers for developers. Or perhaps it will be relegated to “optional” status—always created, but only provided upon request. Whatever the case, just remember to be as flexible as possible and let your context and stakeholder guide decision-making.

post authorVincent Au

Vincent Au, Vincent Au (@mr_lun) is the User Experience Director at Rokkan, a New York-based agency with clients of all shapes, sizes, and verticals. He works collaboratively with clients and coworkers to create pleasing and robust user experiences rooted in solid, scalable information architecture. He enjoys making complex things simple, moshing, listening to Slayer, and eating curry.

Tweet
Share
Post
Share
Email
Print

Related Articles

As consumers’ privacy concerns continue to grow, so should our attention to addressing privacy issues as user experience designers.

Article by Robert Stribley
Designing for Privacy in an Increasingly Public World
  • The article delves into the rising importance of addressing privacy concerns in user experience design, offering insights and best practices for designers and emphasizing the role of client cooperation in safeguarding user privacy.
Share:Designing for Privacy in an Increasingly Public World
9 min read

Navigating the Creative Landscape.

Article by Adri Mukund
Unveiling the Influence of Cognitive Biases on Design Decision-Making
  • The article explores the influence of cognitive biases on design decision-making, outlining various types of biases and offering strategies for mitigating their impact to foster inclusivity and objectivity in design processes.
Share:Unveiling the Influence of Cognitive Biases on Design Decision-Making
6 min read
Article by Chris Kernaghan
Do Founders Even Care About Design?
  • The article emphasizes the importance of design in startup success, highlighting the risks of ignoring user feedback and the necessity of effective communication between founders and designers.
Share:Do Founders Even Care About Design?
6 min read

Did you know UX Magazine hosts the most popular podcast about conversational AI?

Listen to Invisible Machines

This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and