Doing Today’s Job with Yesterday’s Tools

by:   |  Posted on

The Problem

Okay, I’ll admit it. I’m hopelessly disorganized in my digital life. My inbox is overflowing with email. My documents are scattered across a half dozen hard drives, none of them backed up. When I recently needed an up-to-date resume, I had to write it from scratch, because I couldn’t find a copy anywhere.

Most people would say that it’s my own fault. It’s true; I should take greater care in organizing my data. But honestly, I’m just too lazy to spend the time to sort all my files into the proper folders. And I’d like to think that I have more important things to worry about than when I ran my last backup.

There’s an old adage in software development that says laziness is a virtue. By laziness, we mean only avoiding unpleasant work. For a programmer, the most tedious work to do is work that could be done by a program. Rather than spend an hour on a repetitive task, a programmer will spend 59 minutes writing a program to complete the task in 30 seconds. As Abraham Lincoln said, “give me six hours to chop down a tree and I will spend the first four sharpening the axe.” In the same spirit, I justify my laziness because I think software should do most of the work of information management for me. Continue reading Doing Today’s Job with Yesterday’s Tools

Four Modes of Seeking Information and How to Design for Them

by:   |  Posted on
“Observe how your users approach information, consider what it means, and design to allow them to achieve what they need.”

I discovered the concepts in this article while preparing material for an introductory information architecture workshop. In the workshop, I thought it important to highlight that one aspect of designing for users was to understand the ways in which they may approach an information task. I was already familiar with the concepts of known-item and exploratory information seeking: they are common in the library and information science literature and are also discussed in Information Architecture for the World Wide Web.

In my work on intranets and complex websites, I noticed a range of situations where people didn’t necessarily know what they needed to know. Additionally, when I opened my browser history to look for examples from recently-visited sites, I noticed that the majority of my own time was spent trying to find things that I had already discovered. These two modes didn’t fit into the concepts of known-item and exploratory information seeking. I call these “don’t know what you need to know” and re-finding.

I spent a while letting this rattle around my head, talking with IAs and designers, and realized that most only thought in terms of known-item searching. When discussing the other types of tasks, they’d ask with a horrified look, “So how do you design for that?”

Let’s look at the modes of seeking information in some depth and their implications for web design.

1. Known-item
Known-item information seeking is the easiest to understand. In a known-item task, the user:

  • Knows what they want
  • Knows what words to use to describe it
  • May have a fairly good understanding of where to start

In addition, the user may be happy with the first answer they find (though not always) and the task may not change significantly during the process of finding the answer.

Some examples include finding out whether Katharine Kerr has a new novel, learning about how the CSS color:transparent attribute works, and getting a copy of the travel form. These are all clearly defined, easy to describe, and the starting point is straightforward.

There are a number of design approaches to help with this type of task:

  • Search. This is a particularly good solution: people can articulate what they need and are able to type it into a search box. As long as the search results show the word in context or show a clear description of results, they are likely to recognise suitable pages from the search results.
  • A-Z indexes. These are great at supporting this mode, as users are able to articulate the word that they are looking for. As long as the A-Z contains the word the user is thinking of, all they need to do is read down the list and spot the right item. One way to make sure that the list of terms in an A-Z index matches the words that users think of is to look at the terms used during user research or in the search logs.
  • Quick links. Links to frequently used items allow easy access to them. Again, the terms in the list must match the users’ terms.
  • Navigation. Browsing via navigation can support this behavior. It is most likely to be effective when the user can clearly identify which navigation heading to choose from.

For this mode, it is important that people are able to answer their question quickly.

2. Exploratory
In an exploratory task, people have some idea of what they need to know. However, they may or may not know how to articulate it and, if they can, may not yet know the right words to use. They may not know where to start to look. They will usually recognise when they have found the right answer, but may not know whether they have found enough information.

In this mode, the information need will almost certainly change as they discover information and learn, and the gap between their current knowledge and their target knowledge narrows.

As an example, a few years ago I was looking for information on the cognitive mechanisms that allow people to navigate the physical world (I was comparing the concept of online and physical navigation). I knew what I was after, but couldn’t describe it (‘navigation’ in a search engine would return results for web navigation). I had no idea where to start. I tried a number of places and didn’t succeed at all. (Six months later I stumbled across some wayfinding papers and realised that was the term I needed).

Other examples of exploratory tasks include looking for history on the technique of card sorting, finding examples of sites with complex forms laid out using CSS, and finding music I like.

The first challenge can be getting the user to a good starting point (this was the main problem in the navigation example). This is less of a problem on an intranet as staff may only have one place to explore. Portal sites, subject-based directories, or sites with a wide range of content (such as Wikipedia) can provide avenues to follow on the open Web.

Design approaches for this mode include:

  • Navigation. The most successful design solution will be browse, via navigation of all types. Browsing allows people to take some chances and follow a path, exploring, discovering, and learning as they go. Users may go deeper or broader in a hierarchy, or to related information.
  • Related information. Related links may be created from a list of related topics, a manually created list of relevant pages, or lists based on items purchased or recommended by other users. Contextual links may also be included in the body of the content.
  • Search. Search can be useful for exploratory tasks, but can be problematic due to the user’s inability to articulate what they are after. An initial search can help the user to learn about the domain and get some ideas for keywords. It can also be useful to provide synonyms for the search term as they may help the user to better articulate their query.
    For this mode, it is critical that there are always avenues for exploration and that the visitor never reaches a dead end.

3. Don’t know what you need to know
The key concept behind this mode is that people often don’t know exactly what they need to know. They may think they need one thing but need another; or, they may be looking at a website without a specific goal in mind.

This mode of seeking information occurs in a number of situations:

  • Complex domains such as legal, policy, or financial. For example, a staff member may want to know how many weeks maternity leave they are entitled to, but may need to know the conditions surrounding that leave. We should read the terms and conditions of new products and services as there maybe important restrictions, but they are too often buried in legal garble that we don’t read.
  • Any time we wish to persuade the user. For example, we would love people to know more about information architecture and usability, but they often don’t know that the concepts even exist. They may think they want to know how to make an accessible nested fly-out menu; we think they need to know more about organising the content properly.
  • Unknown domains. For example, when someone is told by friends that he or she should check out a new service, product or website, but does not yet know why he or she would want to know about it.
  • Keeping up to date. People often want to make sure they keep up to date with what is happening within an industry or topic, but are not looking for a specific answer.

The challenge is providing an answer while exposing people to the necessary information, thus showing what they may need to know. This can be achieved by:

  • Straightforward answers. Simple, concise answers allow people to have their initial information need met. For example, in the four situations above the websites could include a summary of the maternity leave benefit, the key issues of concern in the terms and conditions, an outline of the benefits of the new website or service, and a list of latest releases respectively.
  • More detailed information. Make more detailed information easily available. This may take the form of related links or contextual links in the body of the content.

The solutions allow people the satisfaction of getting an answer and then the opportunity to get additional information.

4. Re-finding
This mode is relatively straightforward—people looking for things they have already seen. They may remember exactly where it is, remember what site it was on, or have little idea about where it was. A lot of my personal information seeking is hunting down information I have already seen. I don’t know how prevalent this is, but discussions with others indicate that I am not alone.

Design solutions can be active (where the user takes explicit action to remember an item) or passive (where the user takes no action but items are remembered).

Active solutions exist on many web sites: wishlists (amazon.com), “save for later” (emusic), and favorites (Pandora). These solutions work well but require a conscious effort from the user, who needs to know they will want to return to an item in the future. Del.icio.us is another example of an active solution for the web as a whole.

A good passive solution allows users to see items they have seen before, order them by frequency of use, easily get to the content, and the information within it persists over time (longer than the current session).

Domains where passive solutions offer value include the following:

  • Shopping sites. Users may look at a number of products and may comparison shop before purchasing (e.g. Target, drugstore.com, Anthropologie, Classy Groundcovers, Expansys).
  • Weblogs. Readers may revisit favorite posts and watch comments on a post.
  • Article sites. Sites like Boxes and Arrows may have readers returning to their favorite articles frequently.
  • Support sites. Readers need to return to the same help topics.
  • Real estate sites. Potential buyers look at their favorite house over and over.
  • Complex search facilities. Users may wish to retain their search, modify it, or rerun it.
“The most important issue is not whether you notice a mode of seeking information that fits into one of these categories, but that a range of modes exist.”

Identifying the modes
Once you understand the modes, examples are easy to spot during user research.

Known-items show up in heavy use of search with accurate keywords, when users can easily list what they need from the site and support e-mail will ask for specific content.

Exploratory information seeking shows up in search when vague phrases or repeated searches for similar keywords are used; when users express that they are researching, looking for background information, or “finding out about” something; and when support e-mails ask for general information.

“Don’t know what you need to know” is a little harder to identify. In interviews, users may express that they just want to keep up with things. It may also be clear that users do not have sufficient background knowledge or have not read information they should have. You can identify gaps in content by walking through the content, acting out a scenario from the user perspective, and checking that sufficient information is available.

Re-finding is easy to identify if your site has user registration and the logs show what pages people visit. You can also look at the number of items in wish lists.

Conclusion
The most important issue is not whether you notice a mode of seeking information that fits into one of these categories, but that a range of modes exist. Observe how your users approach information, consider what it means, and design to allow them to achieve what they need.

Note: Thank you to IAI members for suggestions for sites that offer navigation for the re-finding task.

The ABCs of the BBC: A Case Study and Checklist

by:   |  Posted on
“We felt the need to make the A-Z more like a supermarket (comprehensive and well-organized) and less like a junk shop (random and gems buried amidst the clutter).”

It is said that a tenth century Grand Vizier of Persia took his library of 117,000 volumes with him whenever he toured his kingdom. He trained his caravan of camels to walk in alphabetical order so that he could always find what he wanted. Luckily, these days it is somewhat easier to organize and present your content in alphabetical order.

A-Z indexes are sometimes seen as the less desirable counterpart to other navigational elements such as sitemaps and, especially, search. However, A-Z indexes can be a valuable secondary navigation tool, especially for large sites with a lot of granular content.

Because there are already a number of excellent articles online that talk about the value of A-Zs, I’d like to outline instead what we did at bbc.co.uk in the first half of 2005: namely, repositioning the site index as a viable secondary navigation tool. I’ll also offer a checklist of eight areas to consider when thinking about creating an A-Z site index. The list has already proved useful in advising BBC colleagues with no background in indexing or information architecture on how to painlessly create local A-Zs for their particular areas of content.

Project background
The project to overhaul the bbc.co.uk index began in late 2004. There was a push to change the visual design to make the user experience more aesthetically pleasing, and a need to address known usability issues with the existing A-Z index, including a lack of understanding of the multi-page format and lack of awareness of the special page for numeric entries. Unlike many web design challenges, the goal of the pages was to send the user off somewhere else as quickly as possible rather than keep them on the page.

We also needed to tackle the hybridized nature of the index, which was part alphabetic listing, part directory, and did not serve either of those models well. Research had shown that users had confused expectations about and varied success in using the index.

The huge size of bbc.co.uk precluded providing a granular index that could support comprehensively categorized headings. However, a more achievable goal was to enable most pages on the sprawling site to be reached within three clicks of a link in the index. One of the other key goals for the project was to create and communicate editorial guidelines to the rest of BBC New Media. For the first time, we defined a definite level of granularity beyond which content would not be considered for inclusion. Our site has over two million pages; for this reason, we decided not to consider single pages of content for inclusion in the index. This was an easy guideline for stakeholders and content authors to grasp.

“More supermarket, less junk shop:” Defining design objectives
There is more to index development than sorting out words and phrases on a page. The success of the BBC project also hinged on using proven user-centered design techniques. This included developing personas, using a creative brief, and working with a visual designer. The ultimate aim was to create an attractive yet functional page.

Personas
The project team developed two personas for the project. The secondary persona was someone who would never use the A-Z, except as a last resort: Stephen, who is 22 years old, from London, and who most definitely has a search mentality. The priority, however, was our primary persona (based loosely on a real participant from the first round of testing), who would help the team imagine how a real person would use what we were building. We named her Sheila.

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.

Design concepts
A creative brief document cemented the business objectives and ensured that the tone, look and feel, and personality of the index would meet branding needs. As simple as the pages are, with extensive use of white space to aid scannability and legibility, they also look friendlier just from having a little color. The blue also means the A-Z is in sync with the wider bbc.co.uk brand color, as chiefly seen on the homepage.

Lippellhelen_img01
Top of a page of the A-Z index, showing the use of blue to match the bbc.co.uk brand color

When thinking about personality, we realized that there was nothing different about the A-Z as compared to any other navigation tools on the site. Everything should be “warmly informative” or “approachably organized,” wherever you’re browsing. Specifically, we keenly felt the need to make the A-Z more like a supermarket (comprehensive and well-organized) and less like a junk shop (random and gems buried amidst the clutter). Not all junk shops are like that, of course, but it was hard to see the bbc.co.uk A-Z as one of the good ones before the project!

Two further enhancements are worth mentioning. Statistical analysis had shown that many users of the previous version of the index never visited any page other than “A,” because that was the first one they would come to on clicking the A-Z link from somewhere else on the site. We decided to develop a new front page that had no alphabetic entries (other than Popular Links) but had links to each letter page instead.

Secondly, we introduced new “filters” for certain link types, such as those to web pages about BBC shows, some of which also have video or audio content. These pages are in addition to the 27 main letter and number pages, which show only TV or radio program page links. The special filtered pages are intended to aid browsing for A-Z users coming to the index from virtually anywhere on the site, and also to be the first destination from broadcast-specific areas of the site (most notably, from www.bbc.co.uk/tv).

Lippellhelen_img02
Part of the bbc.co.uk/tv portal page, with ringed link to TV program-only part of the A-Z index

Competitor analysis
The team looked at around 20 other indexes from both elsewhere on bbc.co.uk and on the wider web. As well as recording subjective impressions of how well these indexes worked, we compared the indexes against a set of criteria such as intra-letter navigation, link readability, use of icons, use of color and/or whitespace, quality of link labeling, relevancy of content, and availability of other navigation tools (e.g., sitemaps).

From the set of bbc.co.uk indexes surveyed, BBC Health’s A-Z of illnesses and conditions stood out, particularly for offering different approaches to browsing and for clean, attractive design. Of the non-BBC indexes, the American Association for Artificial Intelligence’s index was strong on cross-referencing (“See” and “See Also” references). It was also very usable due to its mix of scientific and non-scientific terminology to help support the site’s goal of making complex ideas accessible to a general audience.

From this design and research work I realized that some of the nuances of compiling an A-Z could be distilled into a short checklist for non-specialists and specialists alike. The list is illustrated with examples from throughout the bbc.co.uk A-Z index. I hope that the areas covered below are general enough to deal with scenarios from all kinds of knowledge domains.

Eight-point checklist for creating terrific A-Z indexes

1. Know your audience
It’s vital to understand the way that your audience interacts with your website and your index. There are many ways of doing this; three that can be particularly useful are search log analysis, persona development, and user testing.

Search logs have been invaluable throughout the lifecycle of the A-Z to highlight the areas of interest to users. They also shed light on the language used by people trying to find things on the site. Even though the A-Z is a browse tool and search is a search tool, don’t ignore the common goals of their respective users: finding stuff easily.

As outlined earlier in the article, creating personas helped guide the development of both visual design and information design for the project. They’re a fun, powerful design technique that helps provide a framework for a successful project.

More tangibly, do user testing on new designs or newly created indexes, ideally at interim stages and not just at the end of the project. There were two rounds of user testing in the BBC project, one with participants recruited by an external agency, and the second with BBC staff who weren’t involved in the project and weren’t in the wider user experience design team.

2. Show your numbers
Don’t make your users guess: even if there’s only one non-alphabetic entry, show that it exists. Many indexes fudge the challenge of entries that begin with numerals by shoving them, for example, in under ”A” or “Z.” Chances are, the entries will only ever be found by serendipitous browsing or lucky guessing.

We used the label “0-9” because there were no entries beginning with a punctuation character. It’s not ideal because, as one participant in testing suggested, users wondered where all the numbers (1, 2, 3, etc.) would be. That said, nobody else questioned the label, so it seemed a good solution. I’ve also seen the hash symbol (“#”) used to encompass both numeric and punctuation character entries, as well as “num” for numeric-only entries.

Whatever it is labeled, make the numbers section or page prominent by placing it in front of the letter “A.” This is a convention in computer books that index technical concepts. In the row of letter blocks that appears at the top of every bbc.co.uk A-Z index page, “0-9” resembles the double door for Christmas Day on an advent calendar. This may seem to give it undue prominence, but doing so gives the page a better chance of being spotted and used, illustrated in image 3:

Lippellhelen_img03
Top of an A-Z index page, showing double size box for the numbers page

The site indexes of technology companies can be good sources of inspiration in dealing with non-standard entries; a good example is http://java.sun.com/a-z/.

3. Acknowledge articles
The question of how to deal with entries that start with “the,” “a,” or “an” became important for bbc.co.uk because of the sheer volume of program titles that needed to be added to the index. Eventually we decided to double-post entries under both the first letter of the article word and whatever letter the next word started with, hence entries for both “The Apprentice” and “Apprentice, The”.

As with the previous tip, why make users stop to think about how the indexer might choose to see the content? The beauty of an A-Z over a directory or a sitemap is that different mental models can be supported and the same thing can appear in more than one place. This gives it an advantage over, say, the Grand Vizier’s camels.

4. Include synonyms
Synonyms, in the form of “See: XX” references, appear throughout the bbc.co.uk index. As in the traditional thesaurus, they are used to show equivalence between a word or phrase and its preferred term. Synonyms in an A-Z add richness to the list of entries–and can often allow you to speak your users’ language without losing the ability to call entries by their correct names. Equally, synonyms play a role in educating users as to what those correct names are.

For bbc.co.uk, many synonyms are used in the A-Z to provide alternative access paths to branded content. For example, the radio station Five Live is always written with a word rather than a number, but a user scrolling through the numbers page will see the pointer:

5 Live:<br />    See: Five Live homepage

Synonyms are often abbreviations or acronyms of phrases, as in this entry for the well-known cricket commentary program:

TMS:<br />        See: Test Match Special

Synonyms can also help users who think in terms of categories or subject areas (rather than those looking for a known item). They may not know exactly what content they want, but can be directed to something appropriate by considerate use of “See:” references. For instance:

Family History<br />    See: Who Do You Think You Are?

5. Properly index proper names
People should be indexed by surname rather than first name, as per book indexing convention. There are of course some exceptions; for example, the names of monarchs (“Charles I”), certain celebrities (“Mel B”), or people from cultures where the surname appears before the first name (“Mao Tse-Tung”).

(The bbc.co.uk A-Z does not contain any entries for people’s names, unless they are part of a site name or program brand. Thus, there are entries for “The Jeremy Vine Show” under both “T” and “J,” but not “V.”)

Much more detailed information about name indexing can be found at Martin Tulic’s site.

6. Consider your cross-references
In general, the bbc.co.uk A-Z avoids excessive cross-referencing, which could make already long pages less usable and less attractive to casual browsers. However, bringing closely-related concepts together can add value to the index and promote content in different places. Cross-references are shown as “See Also:” pointers in entries, as in this example from bbc.co.uk, where a country name is linked to content about the languages that are spoken there:

Sri Lanka

Sri Lanka (Country Profile)

Sri Lanka (Cricket)

See Also: Sinhala (World Service)

See Also: Tamil (World Service)

7. Use qualifiers and extra information
Besides synonyms and cross-references, there are other ways to make your index more user-friendly. Qualifiers are extra bits of information in parentheses, attached to index entries, often for clarifying concepts. For example, the bbc.co.uk A-Z qualifies dance as “(Performing Art)” in order to differentiate it from dance music, which is also covered in depth on the site.

Qualifiers can also be used on large sites where a subject is covered in more than one place, a particular issue for bbc.co.uk. The entry for “Comedy” is:

Comedy<br />     Comedy homepage<br />     Comedy (BBC 7)<br />     Comedy (BBC Two)<br />     Comedy (BBC Film Network)<br />     Comedy (Radio 4)

It is also possible to supply extra information in the form of what would be called scope notes in a thesaurus. These could be useful in a website index where an entry for a new or growing brand, or an unusual concept, might benefit from further detail. For example:

BBCi – Information about interactive TV

8. Take pride in the index
Dealing with everything mentioned in the other seven tips will give your index a fighting chance of being successful. None of it will matter, however, if users cannot find it.

Make the A-Z index available from all parts of your site if you can, preferably linking to it in a consistent, prominent place on every page. This might be in a toolbar or as part of the navigation. Whatever you do, don’t follow the example of some sites that put the link to the A-Z at the bottom of the page, in tiny size 1 font, with other links that very few people (apart from lawyers) ever see, let alone click on.

Take pride in your index, and be like the owners of this second-hand bookshop in London, who clearly wanted customers to know they cared about organizing their stock!

Lippellhelen_img04
Sign from a London bookshop promoting beautifully organized stock

For more information

There is a wealth of information on the web about indexes of all sorts, not just A-Zs.

The following are good places to start:
A-Z Indexes to Enhance Site Searching
A-Z Website Indexes Explained
IA Wiki WebSiteIndexes
Beyond Book Indexing

There are many books, especially from the field of library science, that cover the concepts and practice of indexing. I have found the Art of Indexing, by Larry Bonura, a useful introduction.

Lastly, Indexers and Indexes in Fact & Fiction, edited by Hazel K. Bell, is a reminder that indexing isn’t just about dry, meticulous text analysis. The book contains dozens of idiosyncratic, political, useless, or just plainly wrong-headed indexes.

Card Sorting: A Definitive Guide

by: and   |  Posted on

“Card sorting is a great, reliable, inexpensive method for finding patterns in how users would expect to find content or functionality.”

Introduction

Card sorting is a technique that many information architects (and related professionals.) use as an input to the structure of a site or product. With so many of us using the technique, why would we need to write an article on it?

While card sorting is described in a few texts and a number of sites, most descriptions are brief. There is not a definitive article that describes the technique and its variants and explains the issues to watch out for. Given the number of questions posted to discussion groups, and discussions we have had at conferences, we thought it was time to get all of the issues in one place.

This article provides a detailed description of the basic technique, with some focus on using the technique for more complex sites. This article does not cover some issues such as the use of online tools, which will be covered in a future article.

Continue reading Card Sorting: A Definitive Guide

Sitemaps and Site Indexes: What They Are and Why You Should Have Them

by:   |  Posted on

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.

Sitemaps provide a high-level or top-down view of the site. The items included in the sitemap should correspond to the items in the global navigation. In this example from L.L. Bean (figure 1), the yellow items match the main global navigation categories on the site: “Home,” “Shop,” “Explore the Outdoors,” “My Account,” and “Customer Service.” Not only is the wording identical, but the order of the items match. Each of these categories contains subcategories, indicated in blue on the map (e.g., “Men’s,” “Outdoor Tips & Gear,” “FAQs”). The third level of the site is indicated by the individual text links.

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.”

In contrast, the sitemap on the Harvard University website (figure 2) does not match the site’s structure or navigation. Only two sections in the sitemap (“Campus Life” and “Admissions”) appear exactly as they are in the global navigation. Two other items are variations of the items in the global navigation. “Admissions” appears in the global navigation as “Admissions & Financial Aid” and “Libraries and Museums” is broken into two separate categories in the navigation. The rest of the items use variant names or do not appear in global navigation at all.

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.

The site index by the World Wide Web Consortium (W3C) (figure 3) has all the elements that make up a good index. The visual design facilitates scanning. The alphabet letters at the top let the user skip down to entries beginning with that letter, since the index is all on one page. This is preferable to dividing the index into separate pages as it allows the user to easily scan the entries for multiple letters without having to wait for pages to load.

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. Individual product names are not included in the site index since there is a separate product index. However, the site index does include the names of the main product lines since not all users will see that a separate product index exists.

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.

In December 2002, PeopleSoft expanded its public website to include 21 country sites. These sites are built on the same information architecture as the corporate site, but are translated into the language of the country and include localized content. The product index is localized to only include the products that are offered for sale in that country. We are in the process of updating the templates used to create the product index so we can tag each product name with the country it is appropriate for. This will allow us to go from 22 separate product indexes (one for each site) to just 10 (one for each language). The product index will be updated to include both the English name of the product and the appropriate translated name. This will allow users looking for a product to find it in either language.

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.

NOTE: Screen shots captured June 13, 2003. Chiara Fox is the Senior Information Architect in PeopleSoft’s web department. Before joining PeopleSoft, Chiara was an Information Architect at the pioneering consultancy Argus Associates.