Before the holidays, I generated blogosphere fervor when I mentioned I think it’s a potential waste of valuable development resources to construct and maintain site maps and site indexes.

Several people left excellent comments which I never had the chance to address until now, so let me see if I can clarify my thinking:

Eric suggested that maybe site maps do have a use:

I’ve also used site maps and site indexes to teleport to a page I know they have (either saw a link, or actually visited the page), especially if the page I want has next to no relevance to the current page (e.g.. I might have drilled down some category to some product page, and want to jump to their page of press releases, or take a look at the management team). This way I avoid trekking through however many intermediary pages, and even having to sniff the scent.

When users intentionally teleport to another page with no relevance to the first, we can infer that they came to the site with multiple, unrelated missions. However, our research shows that multiple missions are very rare. Even when they do occur, they are usually related. For example, a user might go to the kitchen section of Amazon to buy a Martini Shaker then go to the book section to buy mixed drink recipes.

It’s my opinion that related missions should be supported by the primary navigation on the pages and it’s a design flaw if the only recourse is to use the generic site map/site index facilities. Of course, this puts more burden on the designers, who have to look at each content page and ask, “what missions are likely to go with this content?”

A site map/site index would be much simpler to implement, but, in general, I think the generic nature of those devices push the burden on the user. Plus, if you haven’t done the homework of determining what the alternate missions are (because it’s a lot of work), I think the chances are much less likely that you’ll accidentally create map/index entries that serve the same goals with the right trigger words. It comes down to the choice of explicit design efforts versus serendipitous results.

Heather asked:

On what kinds of sites have you conducted your user research? I agree that on most typical corporate web-presence sites (with the objective of “this is who we are and what we do”) a site index is probably not needed if the navigational structure is well-designed. But for sites rich in informative content, serving repeat visitors (such as intranets, companies with subscriber-users, government agencies, educational institutions, libraries, professional and trade associations, and other membership organizations), a site index can be quite valuable for the users who want to access precise information quickly.

We’ve conducted our research on all different types of sites. But, I was referring to information-rich sites, much like the type Heather described, which is where much of our research is conducted. I agree that users want to access precise information quickly. However, building out a quality index is a real skill and most sites do not have the craftsman available.

In addition, as I mentioned above, to do the research necessary to build out a quality index, you need to find out what users are looking for and why. While organizing that information into an alphabetical index is an option, if you have all the research, you probably will find that it’s the least desirable form. Instead, creating a logical organization of links where related information is clustered together will work better. And making it your primary navigation (aka home page) instead of located on a secondary page (which, itself, has a scentless name such as “A-Z Index”) would probably make the access even faster.

I’m not saying that indexes in themselves are bad, just that you are fixing a symptom, not the root problem, when you’re dedicating resources to them. To this end, Heather seemed to agree with my point:

Another issue specific to site indexes in existence is that they may not be done well. They might be mere alphabetized lists of site page titles (alphabetized site maps) yet labeled as an index. As such, they are not very useful. A book’s index is not a mere alphabetization of the table of contents, but some so-called site indexes get away with this. A good index has multiple access points/entries, each worded differently, which point to the same content, a structure of second-level terms or sub-entries, and cross-references. And on a web site the entries may point to anchors at headings within pages and not just to the top of the page.

All of this takes great skill and care. The efforts may be better dedicated to building out a better home page design, utilizing the same underlying content.

George pointed to a Boxes & Arrows article describing the building of the A-Z Index for the BBC. While the article is well written and informative, George does ponder:

It explains very well how they BBC reworked their index but didn’t get into much detail why they need an index, why they needed to rework it, what efforts were put into accomplishing this task and the what were the results.

So what do you think – could the BBC make better decisions in helping their visitors find content instead of redesigning their site index?

As with many discussions of site maps and site indexes, the article assumes an index is the right way for the site and only needs to be improved. The article goes so far as to mention this persona:

Sheila is 59, retired, and lives in Newcastle. Her web experience is mainly limited to genealogy and browsing kids’ content on bbc.co.uk with her grandchildren. She has used email and has bought online, but without great confidence. She doesn’t really like searching, and prefers to scan a list of links even if it means scrolling.

It then assert an alphabetical list of every topic the BBC covers (which gives serious competition to any well-done encyclopedia) is the best way to find all the content specific to Sheila’s two interests: genealogy and kids. Again, there’s gotta be a better way to solve this problem. I agree completely with George: the BBC could definitely find better ways.

Darrel shared where he’s coming from:

As a .gov entity, we’ve spent the last year discovering that we have no easily identifiable set of personals to target our IA at on a broad level. It’s across the board, pretty much consisting of everyone within the confines of our state. Some user interviews have led us to the conclusion that having more links up front is ultimately what folks are looking for. More scanning, less clicking, increasingly approaching a site map. So, in a way, the more we focus on our ’scent issues’ the more we’re working on our site map at the same time.

This is a brilliant observation. Since you have a constituency that is all over the board, having more links on the home page are going to play in your favor. In essence, your home page will become the site map.

So, the summary is this: site maps and site indexes are just another link library that the site designers have to build and maintain, without adding any real benefit by separating it from the other navigation on the site. Put all your important links in your primary navigation and you’ll make users happy while reducing the workload considerably.

This entry was posted on Thursday, January 12th, 2006 at 3:59 pm and is filed under Design . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.