Sitemaps and site indexes are forms of supplemental navigation. They give users a way to navigate a site without having to use the global navigation. By providing a way to visualize and understand the layout and structure of the site, a sitemap can help a lost or confused user find her way. Sitemaps are more widely implemented than site indexes, but both have their place and fulfill a unique information need.
Can you see it? A sitemap is a model of the structure of a website on a single page. At a glance, the user can see the main categories and subcategories on a site. This visualization can be a literal graphical map or be text-based. Text-based sitemaps (really a table of contents) are easier to maintain than graphical ones due to production overhead. Dynamic sitemaps that require users to manipulate the page to see the content (e.g., hyperbolic trees) are not as successful as simple, uncluttered outlines. The most important thing about a sitemap is that it be accurate, easy to scan, and easy to understand.
The L.L. Bean sitemap does a very good job of displaying the different sections of the website. The visual design reinforces the site hierarchy. It is easy to understand that “Men’s” is part of “Shop” and “Log In/Register” is part of “My Account.” It is clean and uncluttered even though it is displaying three levels of hierarchy. The individual links further clarify what the subcategories mean. For example, the categories “Footwear,” “Active Clothing,” and “Casual Clothing” further define what is meant by the term “Women’s.”
The first section of the sitemap, “About Harvard,” is actually an item in the footer of the site. The subcategories in the “About” section do not match the subcategories found on the actual “About Harvard” page. In fact, of the 10 links listed on the sitemap in the “About Harvard” section, half of them lead back to the top of the “About Harvard” page itself rather than to a discrete page.
The Harvard University sitemap does little to help the user understand the Harvard site. It mixes global navigation and footer elements, making it difficult for users to understand the priority of items. The map also makes it difficult for the user to find the elements again once she has left and is deep in the site. Was that link in the global navigation or the footer? The labels vary among the sitemap, the global navigation, and sometimes even the page itself. This makes it difficult for a user to be sure that she is on the correct page. Link names that are similar, but not exact, require the user to have to think about the terms to determine if she is in the correct place. This is added mental processing that the website should not impose upon the user.
It’s as easy as A-B-C Unlike a sitemap whose purpose is to illustrate the structure of the website, a site index provides direct access to specific areas of the site. Site indexes are best suited for known item browsing. As Fred Leise writes, site indexes “provide entry points to content using the users’ own vocabulary and they provide access to concepts discussed, but not named, in the text.” Site indexes also allow for finer granularity than sitemaps since they can point directly to specific mentions of people, places, and things, rather than whole subsections. Site indexes provide a bottom-up, or content-centric, view of the content on the site.
A website index should function in a similar manner as a back-of-the-book index. In fact, modeling your site index on back-of-the-book indexes will help improve the usability and usefulness of your index. If your audience understands how to use one, they will understand how the use the other. Following graphic design standards for book indexes, such as indenting sub-entries under main entries, will also help improve the readability and usability of your index.
This index includes main entries for all of the important topics on the W3C site. Main entries (e.g., “architecture”) are broken down into sub-entries (e.g., “Design Issues”) to help users focus their browsing. See references are included to help users find the items they are looking for. See references “translate” the user’s vocabulary into that of the site. In the W3C example in figure 3, there are no entries for the term “annotations,” but there are three entries for programs related to annotation: “Annotea,” “Amaya,” and “Ruby Annotation.” This tells the user the topic she is interested in is included on the site, but under a different term. The W3C index also includes see also references. These direct the user to additional information related to the item she looked up. In Figure 3, you can see under the entry for “Annotea” there are two see references for the “Semantic Web” and “Amaya.” See and see also references are an important component to include in your index. But they should be used sparingly, so they do not overpower the main entries in the index.
While the W3C site index is well done, there are things within it that could be improved. For example, the page includes a scope note, or explanation of what is included in the index, at the bottom of the page. This note should be moved to the top of the page, so users know from the beginning what is covered by the index. The W3C should also complete their cross-references. Since “Annotea” has a see reference to “Amaya,” “Amaya” should also have a see reference back to “Annotea.” It is only logical that if one is related to the other then the relationship is reciprocal, and users would be interested in both.
Indexes come in a variety of flavors. One type is an index of the entire site that covers all of the topics included, such as in the W3C example. Alternatively, there are product indexes that take the form of alphabetical listings of product names or a numerical listing of part numbers. These are especially helpful for sites with a lot of products or complex product lines. University sites such as Harvard University and Yale University may have indexes of their subsites—the individual department, schools, and club sites that are part of the university.
The corporate PeopleSoft, Inc. website uses both a site index and product index. The site index, which won the Australian Society of Indexers Web Index Award for 2002-2004, covers all of the main topics included on the site, including information about PeopleSoft and contact information.
Because PeopleSoft offers over 200 different enterprise software products, we decided to have a separate product index (see figure 4). A combined site and product index would be too unwieldy. The product index includes the product lines, suites, modules, and solutions the company offers. The current name of the product is listed along with any past names the product may have had listed as see references. This allows customers who knew a product under one name, such as “MarketPlace,” to still find it under its new name “eSettlements.” Note that the scope note clearly states that only product information is included in the product index and references the site index for other site content.
But how do I choose? How do you know if your site needs a sitemap or a site index, or both? On very small sites, it is unlikely that either would be needed. Most likely the global navigation can provide direct access to all areas of the site. Most medium- and larger-sized sites should probably include at least a sitemap. Text-based sitemaps require few resources to create and maintain and can provide big benefits for your users. Unless your site is a directory like Yahoo!, a sitemap is the only place where a user can see all the categories and top subcategories in a single place. This is especially important if your site navigation uses expanding and collapsing menus that hide options until a mouseover. Ecommerce as well as informational sites can be improved with a sitemap.
Most medium- and larger-sized sites can also benefit from an index of some type. For extremely large sites, it would be unrealistic to include absolutely everything in the site index. It would simply be too large to use efficiently. Only the most important and most used information should be included. Informational sites benefit more from a site index than the average ecommerce site because the content is generally richer on an informational site. However, ecommerce sites with complex product lines should consider whether a product index would be appropriate and helpful for their audience.
The decision whether or not to include an index also depends upon the type of content on your site. Does your site make sense in an alphabetical arrangement? For the L.L. Bean site, a site index would not be very helpful for their users. Users tend to look for clothing and outdoor gear via categories (e.g., “Men’s,” “Camping,” “Active wear”), not by browsing an alphabetical listing. Since the content lends itself to categories, a sitemap better serves the users’ needs.
Location matters Whether you include a sitemap, site index, or both on your site, your users should be able to access them no matter where they are on your site. Place the link in a consistent spot such as the footer or with other utility navigation. If your site has a help section, include the link there as well, since lost users may have overlooked the links in the primary location. Consider including a link to the sitemap and site index from the search results page and the no search results found page as well.
The most appropriate name for a sitemap link is simply “Site Map.” In the Nielsen Norman Group study on sitemaps in January 2002, the sitemap “label worked well … and is one used by 63% of the sites with site maps,” included in the study. Don’t call it a “Site Index” unless it is truly an alphabetical index. If you have a product index, be sure to differentiate from the site index in both the label and the scope note.
On the PeopleSoft site, the usage metrics for the site index and product index are consistently higher than those for the sitemap. There are a couple of hypotheses as to why this is the case. First, the site index is a more complete view of the site than the sitemap, and it includes links to more things than just the top-level categories on the site. Items are cross-referenced and double-posted so users can find items by looking up their term, for example “jobs” and the PeopleSoft preferred term “careers.” Second, the customer support team refers users to the site index if they are having trouble locating an item on the site. In this way, the site index acts as a list of shortcuts, since a user doesn’t have to drill down through the hierarchy of the site to find what she is looking for. Lastly, the reason may simply be link placement and visibility. There are links to both the sitemap and the site index in the footer on every page, in the help section, and on the search tips and no results found pages. But there is also a link to the site index next to the search box on the left-hand navigation bar. This often raises the link above the fold, increasing its visibility.
Making it easy on yourself Sitemaps are relatively easy to create and maintain since they generally do not contain any unique content. The terms and items included come straight from the primary and secondary global navigation of the site. Indexes are a bit more complex however, since the entries must be careful chosen. A site index really requires a person trained in indexing to analyze the content to determine the appropriate entries and relationships between terms. A product name index, on the other hand, could be generated automatically using a database, metadata, XML, or other similar technology.
At PeopleSoft, our content management system, Interwoven’s TeamSite, enables us to use the same sitemap, site index, and product index pages on all of our corporate sites. This is important since the information architecture is the same for the corporate website and our customer and partner extranets. All of the information on the public site is available on the customer site, and the partner site includes the customer and public information, plus additional partner program information. We tag each entry in the indexes and map with an audience tag. The system then displays the appropriate entries for each audience, depending on how they log into the site. This allows support information to appear on the customer and partner site index but not on the public site index, which in turn reduces the amount of maintenance required since there are only three pages to update instead of nine.
Conclusions As we have seen, both at PeopleSoft and in examining other real-world examples, effective uses of sitemaps and site indexes can provide a quick and easy way for users to move around a site, and they provide in-depth information about the content and structure of the site. As more sites adopt them, users will become more familiar with their benefits and make use of them as a navigational tool within a site.
- Leise, Fred. “Improving Usability with a Website Index.” Boxes and Arrows. July 15, 2002. [http://www.boxesandarrows.com/archives/improving_usability_with_a_website_index.php]
- Stover, Amy; Coyne, Kara Pernice; Nielsen, Jakob. Designing Usable Site Maps for Websites: Guidelines Based On Usability Studies With People Using Site Maps. Nielsen Norman Group: 2002. [http://www.nngroup.com/reports/sitemaps/]
NOTE: Screen shots captured June 13, 2003.
An excellent article…
In user testing that I have done over the years, very few users look to site maps of site indexes when they get stuck. My current client has been trying to educate the Intranet users to look in these places when they get stuck. This has not been that intuitive, except for the most experienced users.
Is there other research showing users taking advantage of these global site resources? Part of the problem has been very poor site maps and indexes have turned the users off.
I have noticed a change over time in the lab. It seems that fewer and fewer users are using site maps. I attribute that to the woeful state of navigation on early sites. Back then, many users didn’t want to be bothered figuring out the navigation scheme by browsing, and used site maps as a shortcut. As navigation has improved, users seem less and less likely to use site maps. The ones I get who use sitemaps today tend to be old hands at the Internet – perhaps remembering their past successes.
Cliff, interesting comment. I wonder if decreasing reliance is due to better IA on sites in general, as you’re suggesting, or to users being more familiar with the architecture of the specific site you’re testing? Probably a bit of both, but I’m wondering if your data comes from testing usage of multiple sites or just one?
First let me say that I agree with your positive (L.L. Bean) and negative (Harvard University) examples of current site maps. I think you muddle the commentary a bit. What makes L.L. Bean work and Harvard not work is the relationship between the visualization on the site map and the visualization of the combination of the Home Page and global navigation. The former is a coherent visual and verbal system, with each element reinforcing and complimenting the others. The latter is an inconsistent mess, aggravated by the mess of nomenclature (many names for the same thing in different orders).
You say two very important things, but I wish you would say them more clearly.
1. “A sitemap is a model of the structure of a website on a single page… The most important thing about a sitemap is that it be accurate, easy to scan, and easy to understand.” That is the crux of it, but what aspects of site map design contribute to this goal? How does a good site map do a good job? The “easy to scan” is a function of good visual information design — use of position, color, font, and arrangement of space to present information in a single view.
2. “Unlike a sitemap whose purpose is to illustrate the structure of the website, a site index provides direct access to specific areas of the site.” Well, the site map also provides direct access to specific areas of the site, but it does not need to be either inclusive or exhaustive, nor does it need to bridge the gap between the nomenclature used in the site structure (the information architecture) and the terms a user might be more familiar with, such as an obsolete name for a product. That is the task of an index, and it is very useful for you to point out that the two are different and complimentary aspects of a comprehensive web site navigation system.
There is plenty of confusion on this issue in the Real World Wide Web. Many sites try to solve both problems at the same time and succeed in solving neither. The current Apple web site, where Donald Norman used to work, is a great example of this. The “Site Map” is a site index, far too large to grasp visually and without the benefits of good index design which you enumerate in your article. You can find an image of the Pre-Steve-Jobs-Return Apple site map in the Mapping Web Sites book that Kris Lenk and I published two years ago. That is a site map.
There is one other issue that I wanted to discuss: the easy-to-maintain argument. A site map made from text links is easier to maintain than a graphic site map. This is true because most people who work on web sites do not have the graphic sophistication of great information designers, and any great visual solution is more difficult to maintain than a list of text links. But this argument overlooks the fact that any site map is as difficult to maintain the design of the site itself. A good information architecture – visual design system – site map should be flexible. If we plan for things to change, they can be changed more easily than if we overlook this issue.
To bring this back to your discussion of the site index, I would have to assume that the kind of thorough site index – with double postings, see also, and obsolete name references — is difficult to create and difficult to maintain without the attention of an indexer or a comprehensive metadata scheme and content management system. You describe how PeopleSoft applies all three of these tools to create and maintain. This is a serious investment that probably delivers serious benefit to the user.
It is also interesting to note that the Sun Microsystems web site (www.sun.com), where Jacob Nielsen used to work, has neither a site map nor a site index.
As you cite the Site Map Usability study by the Nielsen Norman Group, it would be interesting to know if you agree or disagree with any of their “28 design guidelines” or their conclusions. I haven’t paid the $56 to read it myself, but perhaps you have.
I’d echo the point made by Chris. I don’t see users looking at site maps in user tests (I’m testing multiple sites, Lou).
This makes me sceptical about the need for site maps.
My feeling on site maps is this: when looking for information, users look at the nav first; if they look at the site map, it means the nav isn’t up to the job – so improve the nav.
I’d rather invest my time in some TA and IA.
Repeated exposure constitutes a curriculum. It is very likely that visitors are becoming more familiar with the navigation of websites.
I know my boss came back from a conference where a usability expert said, “Nobody user context-sensitivity in help systems.” I told my boss that we taught users not to use them by not providing any payoff. And, I think we trained them to expect presentation, instead of an index into a subset of the available topics.
The same thing could be happening here. Have we accidentally taught visitors not to use sitemaps.
I think one other reason why a site map is essential to a Web site and I didn’t see mentioned in the article is for search optimization. While users might have grown more savvy in their Internet navigation and current Web site navigation has improved to a point where users don’t feel the need to use site maps anymore, they are great for search engines to gain easy access to deep areas of your site and help those pages to be indexed in engines like Google.
Of course, you do want them to be design consistent but if the target audience is more of search engines than users—although it does need to be helpful for users too—this could influence the idea of the design and organization.
I agree with Randy. I believe the website user is more educated on the general layout of a site. It seems most corporate websites today abide by the same design principles which in turn create a familiar environment for the user. I think also that reliable, drill-down menu systems offer greater access to content without having to search.
I only wish that I could see the images.
It’s a real shame that the images are broken on this article…