But to date, the IA community hasn’t found an effective, simple technique (or tool) to test site structures. The most common method used — closed card sorting — is neither widespread nor particularly suited to this task.

Some years ago, Donna Spencer pioneered a simple paper-based technique to test trees of topics. Recent refinements to that method, some made possible by online experimentation, have now made “tree testing” more effective and agile.

How it all began

Some time ago, we were working on an information-architecture project for a large government client here in New Zealand. It was a classic IA situation – their current site’s structure (the hierarchical “tree” of topics) was a mess, they knew they had outgrown it, and they wanted to start fresh.

We jumped in and did some research, including card-sorting exercises with various user groups. We’ve always found card sorts (in person or online) to be a great way to generate ideas for a new IA.

Brainstorming sessions followed, and we worked with the client to come up with several possible new site trees. But were they better than the old one? And which new one was best? After a certain amount of debate, it became clear that debate wasn’t the way to decide. We needed some real data – data from users. And, like all projects, we needed it quickly.

What kind of data? At this early stage, we weren’t concerned with visual design or navigation methods; we just wanted to test organisation – specifically, findability and labeling. We wanted to know:
* Could users successfully find particular items in the tree?
* Could they find those items directly, without having to backtrack?
* Could they choose between topics quickly, without having to think too much (the Krug Test)¹?
* Overall, which parts of the tree worked well, and which fell down?

Not only did we want to test each proposed tree, we wanted to test them against each other, so we could pick the best ideas from each.

And finally, we needed to test the proposed trees against the existing tree. After all, we hadn’t just contracted to deliver a different IA – we had promised a better IA, and we needed a quantifiable way to prove it.

The problem

This, then, was our IA challenge:
* getting objective data on the relative effectiveness of several tree structures
* getting it done quickly, without having to build the actual site first.

As mentioned earlier, we had already used open card sorting to generate ideas for the new site structure. We had done in-person sorts (to get some of the “why” behind our users’ mental models) as well as online sorts (to get a larger sample from a wider range of users).

But while open card sorting is a good “detective” technique, it doesn’t yield the final site structure – it just provides clues and ideas. And it certainly doesn’t help in evaluating structures.

For that, information architects have traditionally turned to closed card sorting, where the user is provided with predefined category “buckets” and ask to sort a pile of content cards into those buckets. The thinking goes that if there is general agreement about which cards go in which buckets, then the buckets (the categories) should perform well in the delivered IA.

The problem here is that, while closed card sorting mimics how users may file a particular item of content (e.g. where they might store a new document in a document-management system), it doesn’t necessarily model how users find information in a site. They don’t start with a document — they start with a task, just as they do in a usability test.

What we wanted was a technique that more closely simulates how users browse sites when looking for something specific. Yes, closed card sorting was better than nothing, but it just didn’t feel like the right approach.

Other information architects have grappled with this same problem. We know some who wait until they are far enough along in the wireframing process that they can include some IA testing in the first rounds of usability testing. That piggybacking saves effort, but it also means that we don’t get to evaluate the IA until later in the design process, which means more risk.

We know others who have thrown together quick-and-dirty HTML with a proposed site structure and placeholder content. This lets them run early usability tests that focus on how easily participants can find various sublevels of the site. While that gets results sooner, it also means creating a throw-away set of pages and running an extra round of user testing.

With these needs in mind, we looked for a new technique – one that could:
* Test topic trees for effective organisation
* Provide a way to compare alternative trees
* Be set up and run with minimal time and effort
* Give clear results that could be acted on quickly

The technique — tree testing

Luckily, the technique we were looking for already existed. Even luckier was that we got to hear about it firsthand from its inventor, Donna Spencer, the well-regarded information architect out of Australia, and author of the recently released book “Card Sorting”:http://rosenfeldmedia.com/books/cardsorting/.

During an IA course that Donna was teaching, she was asked how she tested the site structures she created for clients. She mentioned closed card sorting, but like us, she wasn’t satisfied with it.

She then went on to describe a technique she called “card-based classification”:http://www.boxesandarrows.com/view/card_based_classification_evaluation, which she had used on some of her IA projects. Basically, it involved modeling the site structure on index cards, then giving participants a “find-it” task and asking them to navigate through the index cards until they found what they were looking for.

To test a shopping site, for example, she might give them a task like “Your 9-year-old son asks for a new belt with a cowboy buckle”. She would then show them an index card with the top-level categories of the site:

The participant would choose a topic from that card, leading to another index card with the subtopics under that topic.

The participant would continue choosing topics, moving down the tree, until they found their answer. If they didn’t find a topic that satisfied them, they could backtrack (go back up one or more levels). If they still couldn’t find what they were looking for, they could give up and move on to the next task.

During the task, the moderator would record:
* the path taken through the tree (using the reference numbers on the cards)
* whether the participant found the correct topic
* where the participant hesitated or backtracked

By choosing a small number of representative tasks to try on participants, Donna found that she could quickly determine which parts of the tree performed well and which were letting the side down. And she could do this without building the site itself – all that was needed was a textual structure, some tasks, and a bunch of index cards.

Donna was careful to point out that this technique only tests the top-down organisation of a site and the labeling of its topics. It does not try to include other factors that affect findability, such as:
* the visual design and layout of the site
* other navigation routes (e.g. cross links)
* search

While it’s true that this technique does not measure everything that determines a site’s ease of browsing, that can also be a strength. By isolating the site structure – by removing other variables at this early stage of design – we can more clearly see how the tree itself performs, and revise until we have a solid structure. We can then move on in the design process with confidence. It’s like unit-testing a site’s organisation and labeling. Or as my colleague Sam Ng says, “Think of it as analytics for a website you haven’t built yet.”

So we built Treejack

As we started experimenting with “card-based classification” on paper, it became clear that, while the technique was simple, it was tedious to create the cards on paper, recruit participants, record the results manually, and enter the data into a spreadsheet for analysis. The steps were easy enough, but they were time eaters.

It didn’t take too much to imagine all this turned into a web app – both for the information architect running the study and the participant browsing the tree. Card sorting had gone online with good results, so why not card-based classification?

Ah yes, that was the other thing that needed work – the name. During the paper exercises, it got called “tree testing”, and because that seemed to stick with participants and clients, it stuck with us. And it sure is a lot easier to type.

To create a good web app, we knew we had to be absolutely clear about what it was supposed to do. For online tree testing, we aimed for something that was:
* Quick for an information architect to learn and get going on
* Simple for participants to do the test
* Able to handle a large sample of users
* Able to present clear results

We created a rudimentary application as a proof of concept, running a few client pilots to see how well tree testing worked online. After working with the results in Excel, it became very clear which parts of the trees were failing users, and how they were failing. The technique worked.

However, it also became obvious that a wall of spreadsheet data did not qualify as “clear results”. So when we sat down to design the next version of the tool – the version that information architects could use to run their own tree tests – reworking the results was our number-one priority.

Participating in an online tree test

So, what does online tree testing look like? Let’s look at what a participant sees.

Suppose we’ve emailed an invitation to a list of possible participants. (We recommend at least 30 to get reasonable results – more is good, especially if you have different types of users.) Clicking a link in that email takes them to the Treejack site, where they’re welcomed and instructed in what to do.

Once they start the test, they’ll see a task to perform. The tree is presented as a simple list of top-level topics:

They click down the tree one topic at a time. Each click shows them the next level of the tree:

Once they click to the end of a branch, they have 3 choices:
* Choose the current topic as their answer (“I’d find it here”).
* Go back up the tree and try a different path (by clicking a higher-level topic).
* Give up on this task and move to the next one (“Skip this task”).

Once they’ve finished all the tasks, they’re done – that’s it. For a typical test of 10 tasks on a medium-sized tree, most participants take 5-10 minutes. As a bonus, we’ve found that participants usually find tree tests less taxing than card sorts, so we get lower drop-out rates.

Creating a tree test

The heart of a tree test is…um…the tree, modeled as a list of text topics.

One lesson that we learned early was to build the tree based on the content of the site, not simply its page structure. Any implicit in-page content should be turned into explicit topics in the tree, so that participants can “see” and select those topics.

Also, because we want to measure the effectiveness of the site’s topic structure, we typically omit “helper” topics such as Search, Site Map, Help, and Contact Us. If we leave them in, it makes it too easy for users to choose them as alternatives to browsing the tree.

Devising tasks

We test the tree by getting participants to look for specific things – to perform “find it” tasks. Just as in a usability test, a good task is clear, specific, and representative of the tasks that actual users will do on the real site.

How many tasks? You might think that more is better, but we’ve found a sizable learning effect in tree tests. After a participant has browsed through the tree several times looking for various items, they start to remember where things are, and that can skew later tasks. For that reason, we recommend about 10 tasks per test, presented in a random sequence.

Finally, for each task, we select the correct answers – 1 or more tree topics that satisfy that task.

The results

So we’ve run a tree test. How did the tree fare?

At a high level, we look at:
* Success – % of participants who found the correct answer. This is the single most important metric, and is weighted highest in the overall score.
* Speed – how fast participants clicked through the tree. In general, confident choices are made quickly (i.e. a high Speed score), while hesitation suggests that the topics are either not clear enough or not distinguishable enough.
* Directness – how directly participants made it to the answer. Ideally, they reach their destination without wandering or backtracking.

For each task, we see a percentage score on each of these measures, along with an aggregate score (out of 10):

If we see an overall score of 8/10 for the entire test, we’ve earned ourselves a beer. Often, though, we’ll find ourselves looking at a 5 or 6, and realise that there’s more work to be done.

The good news is that our miserable overall score of 5/10 is often some 8’s and 9’s brought down by a few 2’s and 3’s. This is where tree testing really shines — separating the good parts of the tree from the bad, so we can spend our time and effort fixing the latter.

To do more detailed analysis on the low scores, we can download the data as a spreadsheet, showing destinations for each task, first clicks, full click paths, and so on.

In general, we’ve found that tree-testing results are much easier to analyse than card-sorting results. The high-level results pinpoint where the problems are, and the detailed results usually make the reason plain. In cases where a result has us scratching our heads, we do a few in-person tree tests, prompting the participant to think aloud and asking them about the reasons behind their choices.

Lessons learned

We’ve run several tree tests now for large clients, and we’re very pleased with the technique. Along the way, we’ve learned a few things too:
* Test a few different alternatives. Because tree tests are quick to do, we can take several proposed structures and test them against each other. This is a quick way of resolving opinion-based debates over which is better. For the government web project we discussed earlier, one proposed structure had much lower success rates than the others, so we were able to discard it without regrets or doubts.

* Test new against old. Remember how we promised that government agency that we would deliver a better IA, not just a different one? Tree testing proved to be a great way to demonstrate this. In our baseline test, the original structure notched a 31% success rate. Using the same tasks, the new structure scored 67% – a solid quantitative improvement.

* Do iterations. Everyone talks about developing designs iteratively, but schedules and budgets often quash that ideal. Tree testing, on the other hand, has proved quick enough that we’ve been able to do two or three revision cycles for a given tree, using each set of results to progressively tweak and improve it.

* Identify critical areas to test, and tailor your tasks to exercise them. Normally we try to cover all parts of the tree with our tasks. If, however, there are certain sections that are especially critical, it’s a good idea to run more tasks that involve those sections. That can reveal subtleties that you may have missed with a “vanilla” test. For example, in another study we did, the client was considering renaming an important top-level section, but was worried that the new term (while more accurate) was less clear. Tree testing showed both terms to be equally effective, so the client was free to choose based on other criteria.

* Crack the toughest nuts with “live” testing. Online tree tests suffer from the same basic limitation as most other online studies – they give us loads of useful data, but not always the “why” behind it. Moderated testing (either in person or by remote session) can fill in this gap when it occurs.

Conclusion

Tree testing has given us the IA method we were after – a quick, clear, quantitative way to test site structures. Like user testing, it shows us (and our clients) where we need to focus our efforts, and injects some user-based data into our IA design process. The simplicity of the technique lets us do variations and iterations until we get a really good result.

Tree testing also makes our clients happy. They quickly “get” the concept, the high-level results are easy for them to understand, and they love having data to show their management and to measure their progress against.

You can sign up for a free Treejack account at “Optimal Workshop”:http://www.optimalworkshop.com/treejack.htm.²

References

1. “Don’t Make Me Think”:http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758, Steve Krug
2. Full disclosure: As noted in his “bio”:http://boxesandarrows.com/person/35384-daveobrien, O’Brien works with Optimal Workshop.

Our intranet provides many applications that have a people finder feature to help staff find each other. The goal in using this feature varies depending on the application and situation. For example, people may want to find a staff to book a meeting or add them to a project team. Whatever the goal, a simple text input field and a Find button are enough to provide the sought-after results. But again and again I have heard complaints about not being able to effectively find colleagues using this feature.

The effectiveness of the People Finder feature is challenged in the following ways:

1. People misspell names of staff they are searching. (e.g., ‘Vivek’ is spelled as ‘Vevek’; with over 140 different nationalities this is bound to happen.)
2. Names stored in the database are not in proper format. (e.g., ‘Vivek Deshmukh’ is stored as ‘Vivek D.’)
3. People are known by completely different names than the one stored in the database. (e.g., In some cultures women change their names after marriage.)

Figure 1: A typical example of not finding a person in staff directory

How can you design a better People Finder application than the one that so often says “Staff not found!”?

Building on users efforts

One idea is to look at what users do with the problem at hand and how they solve it, and then use their efforts to build the application. For our People Finder application we can do this by having a “Did you mean …” feature, which gives alternative name suggestions to users. These suggestions are not built by pre-defined logic but are based on the collective input of users.

In our department, when colleagues don’t find someone on a People Finder application, they try various strategies. These include:

1. trying different spellings,
2. asking another colleague for the persons correct name and spelling,
3. calling the person directly (if they have their phone number), and
4. checking previous emails to get the exact spelling.

Whatever activity they choose, they make sure that they have the right information to type in the People Finder text box. We need to make use of this effort (i.e., making an error and then fixing it) from the users to build our application. The following conceptual model is my attempt at designing such a system.

Building the application

There are five essential components to this concept:

1. Build a relation table to store incorrect entries. In other words, store search queries which produced no results.
2. Determine if the user has found the right person.
3. Build a relation between the previous incorrect entries with the last correct entry determined in step 2.
4. Check the strength of relation by observing patterns across all users.
5. Present strong patterns as a “Did you mean …” feature on the search results page.

Let’s look at each step in detail.

STEP 1: Build a relation table to store incorrect entries.

To explain the concept, let’s take the scenario in which a user Sally wants to organize a meeting with Timothy Campbell using People Finder but cannot find him because Timothy Campbell is stored as Tim C. in the application database. (See Figure 1 above.) Let us store this incorrect entry Timothy Campbell in a database table called “Relation Database Table for Sally” (See Figure 2).

Figure 2: Incorrect entry inserted in the Relation table for Sally

STEP 2: Determine if the user has found the right person.

Next, let us say Sally tries a few more names in the People Finder text box, which generate no results. We store all of these incorrect entries in the Relation table. After a few failed attempts, Sally asks her colleague how to find Timothy Campbell in the address book. She is told his name appears in the address book as Tim C. Sally types the name ‘Tim C.’ and gets a result with Tim C.’s details. Sally adds Tim C. to the meeting list. It is this action of Sally clicking the Add button that allows us to identify a correct entry for the Relation table. (See Figure 3.)

Figure 3: Sally now types Tim Campbell’s name as it appears in the database.

STEP 3: Build a relation between the previous incorrect entries with the correct entry.

We then build a relation between the previous incorrect entries with the first following correct entry (i.e., Tim C.) and add it to another table called ‘Alias’ for the staff Tim C. Think of the Alias table as a ‘People also know Tim C. as …’ list. Note that the basis for saying that there exists a relation between the incorrect entries and the correct entry is the real life observation that people do what they must to find the correct name to type in the search text box. Of course you may get mismatches but this will be taken care of in the next steps.

Figure 4: Tim C. is related with the previously typed names

Figure 5: Alias table for Tim C.

STEP 4: Check the strength of relation by observing patterns across all users.

Next we identify the most common aliases used for finding Tim C. We do this by looking at the Alias table for Tim C. Those aliases that appear frequently are strong candidates to be displayed with a “Did you mean …” feature. In our example Timothy Campbell and Tim Campbell show a good pattern across different users as aliases for Tim C., so we conclude that when people search for Tim Campbell they mean Tim C.

Figure 6: Alias table shows that lot of people type Timothy Campbell or Tim Campbell to find Tim C.

STEP 5: Present common patterns as “Did you mean …” feature on the search results page.

The last step is to present the most common pattern to the users as a “Did you mean …” feature. In our example when -users search Timothy Campbell we present them with Tim C. as a “Did you mean …” feature. We can show additional information like the department, title or a photo of Tim Campbell so that the user can confirm that it’s the person he is looking for.

Figure 7: Implementation of the “Did you mean …” feature

Making the system efficient

The secret to making our system more efficient is eliminating -irrelevant relations. Consider this question: Should you build a relation between an incorrect entry which was entered at 08.30 and the next correct entry entered at 09.20? Probably not! It is very unlikely that the user will search for the same person after a gap of 50 minutes. A time frame of 20 minutes may be more realistic.

Advice on how to go about building such a system

1. Build a business case
   Building such a system will take time and resources. You will need to present an argument to management why this is important and perhaps make a business case for the effort. Don’t forget to include key stakeholders like Human Resources while presenting the business case. Here are some key points:
   • Users will save valuable time while searching other staff.
   • Colleagues will not be disturbed – their time will be saved.
   • Companies will save on phone bills and employee time.
   • Systems become robust over time without additional work from users or a massive data cleaning effort.
2. Collaborate and co-ordinate with different IT teams who build applications
   Pepare a list of all applications that use the People Finder feature. Collaborate with the IT teams who are responsible to build these applications and work out a plan to implement the “Did you mean …” feature on the current applications. This task becomes easier if you have a centralized IT team.
3. Prioritize applications for implementation
   Our system becomes robust when many users use the system. Start implementing the feature on the “Frequently used by many” type of applications first. These applications will give maximum value in shortest amount of time.

The risks

There is a risk that few users can work together to build a strong pattern of, say, “Jerk” with Rob Stevenson, thus manipulating the system. This can be kept in check by doing two things. If your company is like ours (formal and very particular about its image) you can:

1. Keep pattern strength high especially if the suggestions to users are going to be automatic without human intervention.
2. In addition to high pattern strength you can include a manual check done by HR admin who can authorize or investigate each strong pattern. To do this you will need to provide an admin interface to HR where they can monitor and dig deeper in to strong aliases.

Going forward

Just as users learn a new system by using it, possibly by making mistakes on the way, a system can also be ”trained" to learn from the users by continuously “listening” to users inputs, while helping users along the way. Though some development effort and technical know-how is required, more intelligent people-finding features on company intranets are essential. There is a long-term payoff, and companies will be saving a great deal in terms of employee time and costs.

Why most people don’t use advanced search

Despite its name, advanced search has not advanced very far. There is great power to conquer the overwhelming number of search results, but the current standard presents barriers to users. Specifically,

• The link is often small, vague, and does not describe benefits to the user
• Advanced search pages typically have confusing page design for the few who make it there.
• There is generally poor search revision functionality: Once a search is performed, the “advancedness” is lost. For example, the Google advanced search delivers the standard search results page. You have to get the query right the first time; there is no opportunity to adjust your query.

Fig. 2: Google’s advanced search is still complicated.

Who does use advanced search?

Tim Bray wrote, “The people who do use Advanced Search are your most fanatical users, the professional librarians, spooks, and private investigators.”(2) As in many situations, segmenting a population makes it harder to see whether the needs of a subgroup are shared by the majority. Current design is based on the idea that there are two separate audiences with distinct needs. The reality is that there are overlapping needs that are limited by the search pattern.
The essential problem of search — too many irrelevant results — has not gone away.
A typical user has to make a choice between doing a search and clicking a link to do a search. In other words, do you want it now, or want to go somewhere else to look? The immediacy of the search text field and the complexity of advanced search means that users will try the text search first.
Perhaps the old framing is wrong. Rather than being a matter of geeks versus normal people, the question should be whether users see a benefit to advanced search on starting. Unfortunately, there is typically no way to use advanced search at the point users realize they need it — when they haven’t found what they were looking for and have too many search results. They have “missed the exit” to advanced search. Users don’t want to lose the investment in their search; they need a way to use additional techniques to work with what they have. A new model of search can help with this problem.

Other approaches to search
Let’s take a quick look at other search innovations from the last decade. Web data has matured and become more structured. Taxonomies and tagging are now common. There are new opportunities to deal with search results overload by filtering, as long as it is clear and easy for the audience. Despite the truism that users will not go past the first page of search results, they will use obvious tools to refine their searches.

Searching by defined parameters is natural in some circumstances (for example, airline ticket searching) but the majority of sites are not sufficiently data-driven to have an interface designed around the data.

Fig. 3: travelocity.com Flight searches, in a sense, only use advanced search.

Tags can improve search results by better describing what someone is seeking.

Fig. 4: amazon.com’s approach to tagging a product

Faceted searching, or returning browsing categories in the search results (as eBay does) can be effective at prompting the user to select a single category.

Fig. 5: ebay.com’s faceted search

Filtering search results

Amazon and Kayak offer filters to enable users to reduce many results to a few. This can be very effective, but there are obvious constraints due to the limited space available for each filter. Only the first few filters are visible when the page loads.

Fig. 6: Filtering on amazon.com and Kayak

Another approach: Progressive disclosure of functionality
One solution to the essential problems of advanced search discoverability and complexity is to progressively disclose (3) the functionality to the user. Instead of a single, complicated page, break it into understandable units and give each to the user when they ask for it.
In this example, show the ways the user could filter the results (e.g., “Brand” or “Price”) in a highlighted banner above the search results.

Fig. 7: Filters highlighted in a banner (it doesn’t have to be green, it just has to stand out!)

When the user clicks a link, display the filter with enough space to clearly articulate how to use it. Don’t cram it in; the user asked for it. In contrast to the left-hand column filters in the examples above, which are naturally space-constrained, this method can hold many more types of filters and doesn’t show functionality they didn’t request.

Fig. 8: When the user clicks "price" above, give the module enough space to be readable.

Let’s look at an example scenario.

1. The user performs a text search normally.

Fig. 9: Searching for a DVD player using the simple search box

2. On the search results page, show options to filter the search in a prominent location above the results. Communicate the value of filtering. Order them by popularity, using size and font weight to highlight others. If there are many options, consider hiding rarely used options under an expandable section.

Fig. 10: A search results page, with options to filter.

3. When the user clicks an option, display a page module for that search parameter without reloading the page. The user should be able to change the parameters at any time to receive an updated search. If possible, show the number of results for each parameter, so the user can see how exclusive it is, and identify which parameter maybe giving them 0 results.

Fig. 11: The search results, filtered by price.

4. Enable the user to add several modules, stacked in chronological order as the user builds up a complicated query.

Fig. 12: The search results, filtered by price and rating.

Recommendations
Define an implicit method for Boolean rules (AND and OR rules) based on normal search patterns — do not ask users to compose Boolean queries. A system that has worked for me is this: If a user selects several different search parameters, perform an AND search between them (e.g., Sony AND Portable). If they choose multiple values for the same parameter, perform an OR search (e.g., Sony OR Panasonic). However, if parameters (such as product features) are clearly non-exclusive, perform an AND search (e.g., Portable AND “HD ready”).

Recognize that quick searches, text searches, and advanced searches may be built with different technologies (e.g., direct database searches, a Google box, or a content management system). You may need to work closely with the developers to make a seamless transition between technologies.

If there are many parameters (more than 15), consider reducing complexity by hiding less used ones under a “see more…” link below the displayed options. Clicking it should display all the options without a page refresh. Evaluate your search logs to make sure you are exposing the right ones. Consider rotating the exposed ones to discover potential popular features, as exposed options will naturally get more usage.

Conclusions
At its core, advanced search is an under-utilized tool hampered by its own design. By enabling the user to add specificity as they request it, designs such as the one above avoid the lonely fate of the standard advanced search page. Defusing this complexity and locating it where users will naturally find it will help advanced search be truly advanced.

References
(1) Nielsen, J. (1997). Search and You May Find. Alertbox, July 15, 1997.
(2) Bray, T. (2003). On Search: The Users.
(3) Wikipedia. Progressive Disclosure

Unfortunately, the results are too often plagued by problems. You know something’s gone wrong when a perfectly clear query returns results that are not only irrelevant, but seemingly deranged. Pages with a logical relationship to the initial request compete for placement among what Jared Spool fittingly calls “wacko results.”¹ The majority of participants walking into my usability tests report they don’t trust embedded site search to help them find what they’re looking for.

Quality search results only come about through applied effort, requiring in particular the skills of an information architect.² And IAs must be ready to go well beyond their traditional front-end role, digging into the functional backend and source data of the search engine. This article outlines how we can bolster findability and win back users’ confidence.

Conceptualizing the Task

The results of any given search are impossible to predict with precision (short of having tried it before). That’s because five distinct variables combine to determine its outcome (Figure 1):

1. Search engine. The algorithmic gears that parse the query and assign pages relevance.
2. Content. The documents searched.
3. Index. A catalog of the locations of every word in every document. This is what allows Google to miraculously find 5 billion instances of the word “the” in 0.2 seconds.
4. User input. The keywords and other parameters the user submits.
5. Results display. The way the data returned by the search engine is presented.

Figure 1. Five variables that determine the success of a site search.

Critically, the search engine isn’t the only factor that determines the outcome, so search can’t be seen purely as a technology problem. It’s important for organizations to realize that their investment in search doesn’t end with the product’s implementation; the most successful approaches will go further to include strategies addressing all of the outside variables.

Strategies

Several engine products allow you to tweak the search engine’s algorithm itself, but I don’t recommend it. That would be like doing brain surgery to fix a speech impediment—whether or not you solve that problem, you’ll inevitably cause a great many more. Changing the algorithm affects all searches, including the ones that already work just fine. So it’s easiest to keep it stable and modify the factors surrounding it.

Taking the search engine as a constant, then, there are four variables that affect the quality of search. Strategies for improving each of these are proposed below.

Strategy 1: Make the Content Machine-Readable

Search engines can provide better results when they’re given better content. The trick is to provide a basis for inferring the content’s meaning.

Structural Markup

The XHTML structure of pages is relevant to the IA, because content that is more machine-readable will be easier to find using search. Pages should extensively use the correct semantic elements: <h1> through <h6>, <p>aragraph, <q>uotation, <caption>, and so on, as well as semantically named “class” attributes. This will help the search engine compare the usage of terms among pages, to distinguish the central topic of a page from peripheral concepts (Figure 2). While IAs typically don’t mark up individual pages, they can influence the process by specifying template-level semantic elements in their wireframes and participating in periodic content reviews.

Figure 2. Structural markup explains that Jupiter is the central topic of page A, while in page B it’s just one of several subpoints on observing planets.

Standard Meta Tags

Most websites use keywords and descriptions in meta tags, but not often as part of a larger strategy. The first step is to create a controlled vocabulary, a standardized set of keywords.³ If you tag them as “teachers” over here, but “professors” over there, the search engine will have a hard time understanding why they’re the same thing. The keywords should also reflect actual terminology from the page itself (especially headings) and be reinforced in the description tag.

More Metadata

Go beyond keywords. Tags that describe the target audience groups, the sector of a financial service, or the cuisine of a recipe page provide more ways to compare and contrast the content; search engines will read as much meta information as you give them. There is a practical limit to how much you can do, which makes user-defined tags well worth considering.

Ontology

Humans know that pugs are dogs, and dogs chase cats, and cats play with yarn, but these relationships are lost on computers. An ontology is a list of concepts linked by the ways they relate to one another (Figure 3), helping the search engine grasp the content’s meaning. If your search product supports ontologies (several do), this can significantly improve the quality of the results.⁴

Figure 3. An ontology explains the relationships between concepts.

Strategy 2: Index All of the Right Data

Indexes have made searching remarkably expedient, but the way they’re built has a lot to do with the quality and reliability of results. Proper indexing requires taking a hands-on approach, and the IA has an interest in working with the development team to influence it.

Ignoring Unnecessary Content

Search engines will automatically index the entire content of a page, regarding everything as equally important. This is a problem because the navigation, for example, will contain terms that are specifically relevant to the siblings, parents, and children of a page, and not to the page itself (Figure 4). There are several methods of excluding this content; the important thing is to make sure that it’s done, because this is one of the most common reasons why searches return bizarre results.

Figure 4. A search for “Neptune” may return results that include this page about Jupiter because the term “Neptune” appears here in the navigation.

Getting All Resources

Users reasonably expect a search to return all of the website’s relevant publicly available documents. Unfortunately, many search products can’t index .pdf, .doc, .xls, .ppt, and similar files, and you can forget about content locked away in audio or video files. The best fix is to convert application files to XHTML and provide transcripts or summaries of multimedia files. This can be a big job, so you may want to initially convert just the most commonly accessed documents.

Strategy 3: Make the Most of User Input

It can be difficult to figure out how to phrase a query. Users have to express what are often complicated concepts in that particular set of words that a given search engine will like. It’s important to make the most of what users submit on their first attempt, because they’re much less likely to make a second.⁵

Query Expansion

All contemporary search vendors offer some type of query expansion, where the search engine automatically looks for words related to the ones the user actually entered (Figure 5). Word stemming, which searches for different forms of the same word, is usually enabled by default. However, the thesaurus, which searches for equivalent and related terms, requires manual work.⁶

Figure 5. Searches shouldn’t only look for the terms as the user entered them, but for related and alternate forms of those terms.

You can go overboard defining synonyms, but the problem is usually too little (by which I mean “none at all”) rather than too much.⁸ Search logs are the best resource for discovering synonyms, related terms, and common misspellings. Set up ongoing reviews to add terms that users actually submit to the thesaurus, drawn from the wealth of data that’s freely available in the logs. The number of successful first attempts will rise dramatically over time.

Syntax Conventions

Users should be able to submit searches in whatever way they learned to write them. Unfortunately, search engines have different syntaxes for the standard operators (And, Or, Not, exact string). You can’t rely on a help file—it’s one of people’s least favorite things to read. The parser should instead be scripted to accept all common syntax conventions, so the user doesn’t have to guess. It should also use “And” as the default operator, which will appropriately limit the results downward as more terms are added to the search.

Assisting Query Formulation

Suggestion functions provide users with a list of similar queries that other people have tried as they type. This makes a lot of sense, since it can be difficult to put a complex idea into words or to recall the precise name of an item. Stellar examples of suggest functions include Google Suggest, AllTheWeb, and Apple’s website.

Strategy 4: Build the Results Page Around the User’s Needs

The results page should be designed to help users find matches for their interests as quickly as possible. This is closer to the IA’s typical interface design role, yet it’s still uncommon to see much more than the vendor’s out-of-the-box functionality on search results pages.

Showing Relevance

Sometimes a search engine will return the right results, but the user will fail to recognize it. Users need to see why results are relevant to their searches. There are two simple ways to do this.

The first is to show a text excerpt from the page that contains the terms from the user’s query, instead of the <meta>description field. The description may vary greatly from the user’s entered query—especially on long pages—and it may not be at all clear why a particular page was retrieved. Instead, an excerpt of the actual content that matches the search will directly explain why a user might want to click through to that page.

The second way to show relevance is to bold the terms in the excerpt that match terms in the user’s original query. That will help the user to quickly scan the page for the results that have the right words in the right context (Figure 6).

Figure 6. Excerpting and term highlighting allow the user to understand how each result relates to the query, and quickly identify the ones that are most relevant.

Best Bets

Despite all optimization efforts, search engines sometimes still miss strong associations that are obvious to people. In cases where particular keywords should be returning specific pages, it can be helpful to include a list of manually specified “Best Bets,” triggered by business rules (Figure 7).⁸ This reintroduces the designer’s influence into search, smoothing out irregularities in the reliability of automated results.

Figure 7. Best bets allow the designer to force particular pages to be returned when the user’s query contains a specific string.

Conditional Content

Taking Best Bets one step further, consider including contextually appropriate content in the search results page when a string in the user’s query indicates the user probably has a particular interest in mind. For example, a user searching for “extrasolar planets” on an astronomy website might appreciate a results page that includes a list comparing the properties of all planets discovered beyond our solar system.

Conclusion

This article introduces just some of the steps that you can take to improve the overall search experience on your site. The reliability of enterprise search needs significant improvement to reestablish user confidence, and IAs should take the lead. To get there, a product’s out-of-the-box functionality must not be seen as the end, but as just the beginning.

REFERENCES

• ¹ Jared Spool: “BBC Reports Users Lose Patience with Poor Search”

• ² Lou Rosenfeld & Peter Morville, Information Architecture for the World Wide Web, pp 136-137.

• ³ Fred Leise, Karl Fast, and Mike Steckel: “Creating a Controlled Vocabulary”

• ⁴ Tim Berners-Lee: “The Semantic Web”

• ⁵ Jared Spool: “People Search Once, Maybe Twice”

• ⁶ Christina Wodtke, Information Architecture: Blueprints for the Web, pp. 137-140.

• ⁷Lou Rosenfeld & Peter Morville, Information Architecture for the World Wide Web, pp. 188-189.

• ⁸ Chris Farnum: “Tuning up Site Search”

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.

iTunes uses formal metadata fields

Flickr prefers freeform “tagging”

There are plenty of great information management tools out there. Certainly, iPhoto has made it easier to organize my digital photos. Flickr and Del.icio.us have popularized tagging—organizing items by simply marking them with keywords—and created a new way to navigate large amounts of data. And iTunes is a definite improvement over manually organizing MP3s into folders.

But as helpful as these applications are, they can be frustrating to use, because each one implements a slightly different set of features, even though they are basically solving the same information management problems. For example, iPhoto allows you to tag a photo with keywords, but iTunes doesn’t allow you to do the same thing for a song. Subtle incompatibilities like this can contribute to a frustrating user experience, because the interface doesn’t behave like you expect it to.

Even worse than slight incompatibilities between applications, is that they often support entirely different data models. In The Design of Everyday Things, Donald Norman explains that when we use a tool—like a drill, a car, or a computer application—we have a mental model in mind of how the tool works, and how it will react to our actions. This mental model guides how we use the tool. With so many different applications to manage our data, we have to keep track of several different data models, and it’s easy to get confused. For instance, when I’m browsing my photos, I might see a photo that I want to send to a friend. In both Picasa and iPhoto, I can click a button that allows me to email the photo to them. But I can’t do the same thing with a song in iTunes, or a bookmark in Firefox. What’s so different about each of those things? In my mental model, they are all just objects that I want to send to my friend. Unfortunately, this data lives in a balkanized world, and what we are allowed to do with the data depends on what form it is in.

This balkanization of our data also makes it more difficult to find things. Before being able to search for something, you have to know what form the data is in, so that you can search in the right application. Did I store it as a Del.icio.us bookmark? Did someone email it to me, or was it in an instant message? Applications like Google Desktop and Apple’s Spotlight help address this problem, but they support a limited number of data formats, and they aren’t able to search across multiple machines.

Another usability problem occurs when trying to share data between applications. A really simple example: my friend Ryan asks me to email him the photos from our last trip to Mt. Washington. I have no problem finding the photos in Picasa, because I’ve got an album called “Mt. Washington Trip 2006”. I can open the album and browse through thumbnails of the photos, looking for that great one that I took from the summit. But when I try to email it to Ryan from my Yahoo! Mail account, I have to browse through the file system to find the file. Even though I have the photo up in Picasa—Right there! That one!!—I can’t communicate that in an intuitive way to the web browser. Luckily, I know how to map from a photo in Picasa to the corresponding file on disk, but many people would not. Picasa provides a great abstraction: instead of thousands of files with unintelligable names like IMG_1792.jpg, it lets us work with the pictures, captions, and albums. But Picasa’s abstraction is like a dialect private to an isolated town: as soon as we leave, we are forced to use the computer equivalent of grunts and hand signals.

All of these problems are caused by the fact that by using many different specialized applications for personal information management, the data is segregated based its form. Using the term segregated isn’t an exaggeration—in some ways, the data is literally not allowed to mix together. For example, I’d like to gather a digital scrapbook of my trip to Europe. It would have emails that I sent and received during the trip, contact information for the people that I met, bookmarks for various places that I stayed, and of course, lots of digital photos. On most systems, this is difficult, if not impossible. It can be done in a crude way by copying some files into a folder and cutting and pasting into text files. But then I would lose all the features of the specialized applications, like captions on the photos.

In short, I believe that there are several usability problems caused by the fact that we use many different specialized applications for managing our data. We can become frustrated and confused by incompatible data models and inconsistent features. It’s harder to find the information we are looking for, because we have to remember what form the data is in. Communication between applications is awkward because they don’t speak the same language. The data is stuck in silos, segregated by its type. This prevents us from using perfectly natural ways of organizing our data.

Towards a Solution

Now that we’ve established what the problem is, the question is: what can we do to fix it? Obviously we can’t expect to have a single application which will support all of our needs. We still need specialized software like iPhoto for managing photos, and GMail for email. I think that the problem is not really with the applications themselves, but with the platform they’re built upon.

In software terms, a platform is a collection of common routines, and a set of interfaces allowing applications to use the routines. Normally, an application is built directly on the routines provided by the operating system. Developers and designers have long understood that an inconsistent user interface is difficult to use, so the UI is built into the platform, resulting in applications that mostly look and feel the same. In order to achieve the same kind of consistency with information management features, we need a platform designed for the manipulation of rich information.

While the amount of information that the average person deals with has increased dramatically in the last 20 years, file systems have hardly changed at all. All modern operating systems do in fact provide a common way to manage information: the file system. Unfortunately, while the amount of information that the average person deals with has increased dramatically in the last 20 years, file systems have hardly changed at all. We are still stuck with the old file and folder model. The problem with this model is that an increasing amount of data just doesn’t fit into it. For example, a single email usually does not correspond directly to a file on the local disk. Another example is bookmarks—many people collect and organize hundreds of bookmarks, but a bookmark is not a first-class object like a file.

In a broad sense, this new information management platform that I am proposing is really just a new kind of file system, based on the needs of today’s users. We need a system that will make it easier to manage and navigate the large amounts of rich and diverse information that people deal with every day.

In the first part of this article, I identified five distinct usability problems, all caused by the fact that we use many different specialized applications for managing our data:

1. Inconsistent features between applications
2. Incompatible data models
3. Difficult to find data, because we have to know where to look based on the type of the data
4. Awkward to share data between applications
5. Inability to mix different types of data together

In the same way the user interfaces are much more consistent because applications all use the same toolkits, then having a common information management framework that other applications can build upon will go a long way towards a more consistent set of interactions. I’d like to outline what I think are the key requirements for such a framework to be successful.

Requirement 0: Be a useful and usable framework

Only if it’s actually used can an information management framework help solve the problems I’ve identified here. The framework must be easy for application developers to build upon, and it must be useful enough to be worth their effort. By building on this framework, application developers would be able to focus on the core functionality of their applications, rather than wasting their time reinventing common information management features.

Requirement 1: Extensible for new kinds of data

By having applications build upon this framework, we eliminate the problem of having incompatible data models. But the platform must be extensible to be able to handle new types of data. The reason that we have to deal with the different data models of specialized applications is because the existing platform (the file system) was not suited for managing the rich data that today’s applications require. If the framework I’m proposing is not built from the ground up to be extensible, we will quickly find ourselves in the same situation we are now: trying to do today’s job with yesterday’s tools.

Requirement 2: Comprehensive search capability

The third problem I identified was that it’s difficult to find data, because you have to know where to look depending on what form the data is in. If it’s in an email, you have to search in one place, but if it’s in a file on your hard drive, you have to search in another place.

While search is not the answer to all our information management problems, it is a very useful feature. Now that Google is a verb, most people are comfortable using search as a primary way to find data. A new platform for information management should provide advanced search capability. Apple has done the right thing by building Spotlight’s sophisticated search functionality into the operating system, and allowing applications to build upon it.

But in order for search to be truly effective, we need to be able to search all of our data at once, instead of having to search in each of the individual silos. Having a single framework for managing rich information means that it will be able to search through all different kinds of data, no matter what form it takes.

Requirement 3: All data on equal footing

One of the problems I identified with current information management systems is that it’s difficult, if not impossible, for different types of data to be mixed together. You can’t create a folder that contains an email, a photo album, and some bookmarks. This problem is also related to the problem of inconsistent features and data models. Things that can be done with one type of data, like a file on the file system, can’t necessarily be done to other kinds of data.

In other words, there is an artificial distinction between different types of data. What a bookmark, an email, and a text file all have in common is that they are distinct, discrete pieces of information. If the purpose of the file system is to allow the user to store and organize information, then it should be able to treat these kinds of items equally. All types of data must be on equal footing. Anything that can be done with a file—like copying, searching, or sorting—should be possible with other pieces of information. If all data is on equal footing, then it would be possible to have a folder containing several different types of data.

Requirement 4: Flexible organization features

The folder (or directory) is the most common organizational metaphor used on computers. Originally, this concept was designed to be analogous to a physical file folder, so a document could only ever be in one folder. But it often makes sense for a document to be in two different folders at the same time. For example, if you had tickets to take a client out to a hockey game, should you put them in the “hockey” folder, or the “work” folder?

In information architecture, it’s good practice to support several paths to a piece of information. This is generally because we need to support many different users, who might have a different mental models. But even with a single user, there are sometimes several different mental models involved. Just today I went looking for my wallet, and couldn’t find it anywhere—although I’m sure I put it somewhere that made sense at the time.

The idea that an object could exist in multiple folders is known as multiple classification, and it has recently become popular in the form of tags. Flickr, Del.icio.us, and many other web services allow you to associate several keywords with your data. By doing so, you are indicating that the data falls into various categories, with the idea that this will help you or someone else more easily find the data later.

Providing support for multiple classification is just one example, but in general, for a new information management platform to be successful, it must be flexible enough to allow you to organize your data however you want.

Conclusion

In the first half of this article, I identified several usability problems with the current state of information management software. We use many different specialized applications for dealing with different kinds of information, and the applications have inconsistent features and incompatible data models. It is harder to find our data, because we need to know what form it is in, so that we can look in the right place. It’s awkward, and sometimes impossible, to share data between applications, and to mix the data together outside of the specialized applications.

To solve these problems, I proposed a platform that could be used to build the next generation of information management applications. Having a common platform for developers to build upon would give us greater consistency between applications—they would have the features we expect, and these features would work in the same way. Integration between applications would be much easier, as they would have a lingua franca for exchanging rich information. Different kinds of data could be mixed together, allowing users to easily organize their data in a way that makes sense to them.

I proposed five requirements for such an information management framework:

1. Be a useful and usable framework. This should go without saying, but it’s important to keep in mind that this framework can only help solve our information management problems if it is useful, and it is attractive for developers to build upon
2. Extensible for new kinds of data. If the system is not built to be extensible, we will soon find ourselves right where we are now: doing today’s job with yesterday’s tools.
3. Comprehensive search capability. This one should speak for itself. With the overwhelming amounts of information that we have to deal with, advanced search capability is an indispensable feature.
4. All data on equal footing. Several of the problems I identified stem from the fact that in current systems, certain types of data are not first-class.
5. Flexible organizational features. You should be able to organize your data in whatever way works best for you.

I believe that these requirements provide a good starting point for an information framework that application developers could build upon, and ultimately give us an easier, more usable set of information management tools.

And then I would have no more excuses for being disorganized.

In “Succeeding at IA in the Enterprise,” James Robertson calls for Enterprise Information Architects to pay attention to the realm of business strategy, and Bob Goodman in “Change Architecture: Bringing IA to the Business Domain” offers the notion of EIAs as change agents or change architects.

Yes, EIAs can be a force for change, but so can anyone. The real question is: should the discipline of Enterprise Information Architecture be defined to include organizational change as one of its essential features. I don’t think it should be.

Whatever it is that information architects learn to become enterprise information architects (EIA), I think it is essential that we not lose our focus. The heart of IA is information and knowledge, and we need to build on that foundation, not try to turn into something else when we add the term “enterprise.”

It is the same for business strategy. Yes, EIAs should better understand their organization’s business strategy and integrate the strategic vision. And, yes, EIAs can contribute to the development of business strategy, but not directly. We should not try to tell business analysts how to do their job. What we can do is provide input into the development of business strategy based on our understanding of and access to information and how those issues are essential to any business strategy.

Integrating business strategy into EIA is only a part of what it means to move from IA to EIA, and I’d like to take a look at the essential issues that IAs bring to the enterprise and what sorts of things IAs need to add and/or learn to develop an enterprise perspective.

The move towards “Enterprise”
To start we should recognize that adding “enterprise” to our titles is part of a broader trend toward enterprise solutions in a variety of fields from technology to management restructuring. For example, content management, knowledge management, and learning management software vendors are all moving toward creating platforms for the entire enterprise that cover the entire life cycle of information and knowledge.

However, the truly essential feature of enterprise solutions — and what we have to recognize if we want to become EIAs — is that moving to an enterprise perspective does not mean simply doing bigger or more varied projects. Rather, it is a move away from a project-centric model toward an infrastructure model.

In order to have an enterprise-wide solution, you must develop an infrastructure that enables projects to be fully integrated, that enables projects to build on a common foundation rather than always starting from scratch, and that enables projects to be accomplished cheaper and faster with a broader impact.

The next step is the most important and the most difficult. It is the creation of a solid, well-articulated semantic infrastructure.

Semantic infrastructure
A semantic infrastructure consists of all the various kinds of information and content in an organization plus the ways that information and content is organized and structured. It includes structured and unstructured documents, tacit knowledge, and other non-document-based content like images and animation. It also includes the policies and procedures around the creation and dissemination of that content, the technologies that support content creation and dissemination (search, CM, portals, etc.), and finally, and most importantly, the ways that content is structured such as metadata, taxonomies, controlled vocabularies, semantic networks, ontologies, social network analysis representations, knowledge and topic maps, and other advanced knowledge representations.

A semantic infrastructure also includes modeling and/or mapping people and their activities. This includes formal and informal communities of all kinds, the information behaviors associated with those communities, linguistic and category preferences, and most of all, how information is used within the full range of business and support activities that these communities engage in.

In my opinion, it is this enterprise-wide semantic infrastructure that is the context within which EIA should operate, and it is the essential feature of defining what an enterprise information architect does and understanding how EIAs differ from IAs.

Distinguishing EIA from IA
Two key elements distinguish an enterprise IA from a basic IA. The first is the role an EIA plays in the design, development, and maintenance of an enterprise’s semantic infrastructure. The second is the scope and type of projects an EIA can be involved in as they develop applications that use and build on this semantic infrastructure.

Let’s start by looking at how an EIA might help develop a semantic infrastructure. A complete answer is beyond the scope of this article, but a simple answer is: IA skills and tools can support research that is fundamental to the creation of a well-designed semantic infrastructure. This can include such activities as researching information needs and behaviors of different users, mapping different communities in an organization, and ethnographic studies.

Just as more and more enterprises become convinced of the importance of content structures like taxonomies, however, EIAs should become more aware of and focus more attention on these content structures. EIAs should also be more aware of how different groups categorize the world around them in different ways and what those differences mean for information architecture. For example, as someone’s knowledge of a field increases, they tend to focus on the more precise levels of a taxonomy while novices tend to prefer higher level categories. Mapping these category level preferences into designs is an important component of a semantic architecture. This is a natural extension of the traditional work on metadata and labeling that goes into IA work today.

The type and scope of applications and projects is the second key element that distinguishes an IA from and EIA. For traditional information projects like search and portals, and even individual intranet website projects, it is important to approach them with an enterprise-wide perspective. One of the reasons these types of projects fail to deliver their full value is that they do not take into account the entire enterprise.

In addition, enterprise information architects work on a broader range of projects, not just traditional information projects like search and Content Management. These other projects could include adding an important emphasis on how information organization and presentation impacts all business activities. (But not to tell other groups how to run their business activities.)

EIAs should also be involved in knowledge management projects like collaboration, communities of practice, and innovation programs. Too often the failure of knowledge management programs is blamed on culture, when all it needed was an understanding of and support for the various group’s information behaviors – a really good information architecture.

Finally, EIAs should not just be involved in the enterprise’s information architecture, but also involved in the information architecture of the enterprise. They should apply IA skills to understand, model, and support how information and knowledge flows within the enterprise.

This could include studying and developing new information architectures for how people do everyday jobs, how desktops or webtops are set up, how those designs impede daily information use, and how to improve those designs. It could also use an expanded social network analysis of who gets their information from what people or content repositories and what kinds of information are not reaching critical audiences. In other words, instead of focusing on the design of the intranet, EIA can focus on the people in the organization and support the information seeking strategies and behaviors that are part of their daily routine.

The place of EIA in the enterprise
The last question I want to examine is where EIA fits in within today’s organizations. It is clear that a semantic architecture needs a broad, interdisciplinary team. It should include members from IT, business units, and information professionals like librarians, information architects, and others.

In addition, this interdisciplinary team will need to partner with other departments throughout the enterprise, including business, technology, sales, administration, and research.

The actual makeup of the team and where it is located organizationally will vary from industry to industry, but from experience we know it should not be located in IT. IT should be involved; people from IT should be on the team, but despite the fact that “information” appears in their department description, we should remember that they are not really information professionals.

For example, many enterprise search, content management, and portal projects fail to deliver full benefits because what is needed to make them work goes way beyond traditional “needs assessments.” It is not enough to have people go out and ask users what they need. You need to have information professionals (IAs, librarians, knowledge engineers, etc.) to develop new creative possibilities to offer to users. You need someone who can ask deeper questions about information behaviors.

Having IT, business analysts, and subject matter experts involved is important and necessary, but none of those three groups understands information and knowledge at a sufficiently deep level to offer truly creative and innovative alternatives that make information and knowledge systems work across the whole enterprise.

On the other hand, it has been suggested that EIA should lead this central information/knowledge team. Personally, I don’t think this is a good idea for a number of reasons having to do mostly with the difference between knowledge and information and the background/training that most IAs have. However, EIA might be one candidate to lead this interdisciplinary team, as long as we start with a greatly expanded definition of the role of EIA based on a stronger emphasis on semantic architecture.

The other major candidates for leading this team are knowledge management and learning departments. Learning groups are a good place, but like IA, traditionally, they don’t deal with the depth and breath of knowledge modeling that is needed. Learning is only one type of information and knowledge activity and we need something to cover the full spectrum of activities: searching, using existing information to create new documents, writing reports, and even using information to make a sale.

Personally, I think that knowledge management departments are a very good place to locate this team, but it does require KM to shift focus away from an over-reliance on the idea of tacit knowledge and move towards actually modeling knowledge—in other words, KM with more emphasis on knowledge than management.

Knowledge architecture is a term that I think captures the essential nature of this interdisciplinary team and, at the same time, adds the focus of actually modeling knowledge to KM. However, it is not a widely used term and requires significant explanation.

Whatever term is used will require some redefining (KM), some expansion (EIA), or some explanation and general acceptance (KA). Take your pick or come up with an entirely new one.

However, what is more important than who will lead this team is to pay attention to how all the members of this interdisciplinary team communicate among themselves. The team will need the services of a good IA to help the team communicate and interact with the rest of the organization. Regardless of who leads, the Enterprise Information Architect will always be an essential part.

Conclusion
There is a great deal more that could be said be but in the interests of brevity, let me close with this thought. This vision of enterprise information architecture might not be what you think of or want an EIA to be, but this vision is meant to be a broad one that attempts to locate EIA within an even broader context that ultimately consists of some form of knowledge management. Within this vision of EIA, however, there is room for many different IA roles.

Some EIAs might work closely with the team doing more advanced knowledge representations. Some might work with the semantic specialists like taxonomist and metadata designers. Some might work with business strategy groups, and some might work with business process re-designers. On the other hand, some might work on traditional intranet projects, some with search or portal projects, and some doing traditional IA on new knowledge management projects.

For me, it is not so much that EIA represents a new field, so much as expanding the definition of what information architecture is and, at the same time, locating IA within a new enterprise approach to information and knowledge.

Amanda Spink is one of the smartest people working on user behavior while using web search, yet when I mentioned her name to a friend who’s spent the last year working on the search user experience, he had never heard of her. The design community is woefully undereducated about search, and is often prone to redesigning Google and postulating what Yahoo! is doing wrong, rather than working to understand why search engines have chosen to do what they do. I suppose this shouldn’t be surprising, though, considering Spink’s work is more often seen in scholarly journals, such as New Directions in Human Information Behavior and Journal of the American Society for Information Science and Technology (brought to you by the same folks who bring you the IA Summit, yet rarely cracked by the working folks).

In order to help correct this problem, I shyly contacted my hero by email, and overcame the time difference between sunny California and even sunnier Brisbane, Australia, with a series of email questions.

Christina Wodtke: When I joined Yahoo!, I had never worked on search before. Your article, “From E-Sex to E-Commerce: How Search Changes” was one of the most valuable in beginning to get my mind around the problem of search. Since reading that article, however, I haven’t seen much change from your findings. In your opinion, are users changing their search behavior, or are they still following the same patterns you found when you analyzed Excite’s data?

Amanda Spink: You make a good observation. Since 1997, our findings have come from analyzing large-scale web user data gathered from commercial web companies, including Excite, Ask Jeeves, Alltheweb.com, Alta Vista, Vivisimo, and Dogpile. Our research since 1997 shows some trends and changing patterns in general searching. However, looking at more recent data from Vivisimo and Dogpile, most web queries are still short—2 to 3 terms, and sessions include little query modification and are generally 2-3 queries in length.

Few people use advanced search features, and many queries include spelling and other mistakes that adversely affect the search results. People look at only a few result pages—not beyond the first or second results pages.

A small number of terms are used with high frequency, and many terms are used once. Web queries are very diverse in topic and some, such as people’s names, are unique.

CW: You’re referring to the “long tail” of a Zipf curve? How does this affect search engine’s strategies in providing relevant results?

AS: The long tail makes “relevant” retrieval very difficult, especially if users are only providing the search engine with two to three words on which to base relevance judgments. Despite the inherent “interactive” nature of search, much of search is not very interactive. The talk about personalization is an attempt to obtain more information from the user to help determine relevance.

CW: So are users changing their overall behavior at all?

AS: We are seeing a growth in more complex search behaviors. More people are searching for information using more than one search. This might mean repeat searches of the same query over time or modifying the queries in successive searches over time. Many people are multitasking or searching for information on more than one topic during a search session. People’s information needs are often quite complex in their home and work environments.

CW: How are they handling that?

AS: During multitasking search they may include two or more topics in one window, or open new windows for each topic and run searches concurrently.

CW: Could you talk a bit more about “complex search behaviors”?

AS: Peoples’ information seeking behavior can often be long and complex. Imagine a person is looking for information on cars. He conducts one search on one search engine, looks at the results, and tries another search engine, or goes back to the first search engine, and repeats the same search with the same search terms, or he may add or remove some terms (query reformulation). This is called successive searching.

In addition, research shows that people often search for more than one topic during their interaction with a search engine. They may batch their topics due to time constraints or new topics may evolve during their search session. This is called multitasking search.

Both phenomena are examples of more complex behaviors beyond the one-topic, one-search paradigm that most search engines assume.

CW: If queries are still so short, what are some of the more successful disambiguation tools used by the search engine? Vivisimo and Clusty offer algorithmically generated groupings and present them as narrowing tools. But last time I was testing these tools with users, the narrowing options were essentially invisible to them. And despite Jakob Nielsen’s assurance (admittedly in 1999) that longer search boxes produce longer queries, I’ve never seen it happen. Are there better and worse ways to encourage richer queries from users?

AS: So far no commercial tool seems to be effective at helping users on a large scale. Search engines have not used longer boxes, so no one really knows what would happen on a large scale if text boxes were changed. The best way to encourage richer queries is to train users and expect them to put more effort into their search behavior. Search engines need to put more demands on the users. People don’t understand their own information behaviors, and they don’t really understand much about search or the web, so they will have to learn. It could take generations.

CW: Really? Many folks who revamp search, either by adding Google, Yahoo!, or another vendor, seem to be leaning toward long entry boxes. I’m thinking about CNN, NY Times.com, CNET.

AS: The Google and CNN text boxes may be a little bigger or longer than average, but not substantially longer. How about a structured textbox, like an electronic library catalog interface? How about a textbox that is 3 inches by 3 inches with lots of space for people to express themselves? If you give people a small text box, you’re probably constraining their expression of their information problem.

People need to feel they should play around with search and experiment. All they can really do at present is squeeze in a few words, press search, and look at a list of websites-the list giving little indication of what the websites mean or how they are ranked. One major problem is that [designers of] search engines tend to think that one technique will do it! What they need to do is test combinations of many techniques, such as clustering, relevance feedback, etc. There is no silver bullet here.

CW: When you speak of training users, I’ve found that very challenging, much more with search than any other Internet paradigm. I’ve been in a lab with a fellow who has used Google for five years, and he never realized “cached” was there until I pointed it out. How can train people who have “banner blindness” for most of the page?

AS: I think this is a major problem for the web industry. How to train billions of people? Whoever comes up with the best solution for that question may capture huge market share. The paradigm needs to change. Search is challenging and interactive, and maybe a “game” paradigm would help.

CW: The short-query phenomena is fascinating. In a lab, I have asked people why they typed, say, “sailboats,” and they’ll say, “Oh, I’m interested in taking classes next summer when we’re up at the lake in Michigan,” yet none of the words made it into their query. Any insights?

AS: Our research shows that the most effective search terms are those submitted by the user, from a user’s interaction with another person about their topic, and terms they identify on the screen from the retrieved output. Stimulating users to talk with someone or thing (agent) about their information problem helps generate terms and look at the results for additional terms.

CW: Hey, those sound like classic reference librarian techniques!

AS: One area that some web developers are exploring is classic reference librarian techniques. It’s an obvious area to explore to understand information behavior and how librarians have helped people with their information problems.

CW: “E-sex and E-commerce,” was referring to a topical shift in searches. Are you continuing to see changes in what people are searching for?

AS: I think it’s important not to assume what “people are searching for” means just U.S.-based search engines. There are major differences emerging in search in different global regions. For the more U.S.-based search engines, the topics seem to have stabilized somewhat with business and e-commerce related searches being the largest category, followed by people, places and things, computers, and medical/health. Sex/porn and entertainment is now a smaller proportion of searches. From what I’ve seen about the Chinese search engines (e.g., Baidu), users are looking for entertainment and gaming. One could say that the Chinese search engine users are where the U.S. users were 5-10 years ago. As more Chinese business information is accessible via Baidu, the search topics may change. Also, currently less than 10% of the Chinese population search the web, so as that number increases, topic may change.

CW: There are endless articles these days about search privacy, and Google giving information to the feds. Is the ordinary person on the street worried about that?

AS: This is an important area for everyone. If search engines and the web are becoming the primary tool by which people are expected to access information, then privacy and the practices of the government in regulation or companies is crucial. Much like the way we see telephones and TV in the past, as involving privacy, commercial, and government interests. Also, because search is now ubiquitous, politicians will seek to gain political advantage or grounds for industry regulation. Ordinary people should be concerned about how political and commercial information policies will affect their access the web.

CW: And you are studying the evolution of human information behavior. How far back are you going? Medieval libraries? Cavemen looking for the right painting?

AS: Obviously humans evolved information behaviors before preliterate societies through cave art, etc. Information behaviors evolved to help humans complete and cooperate, as the technologies evolved from cave art to the web. In fact, people may not change their information behaviors, but may have evolved over time to utilize a greater capacity for more complex information behaviors.

The Spink and Currier paper talks about the information behaviors of Darwin, Napoleon, and Casanova-all very effective people at finding and using information. And what we write about Casanova many people have found fascinating!

CW: Now you are being cruel! I’m going to have to renew my library card. Can you predict trends in behavior from your research? What’s next on the horizon?

AS: What’s next on the horizon is developing an understanding of how human information behaviors have evolved over human history, how they evolve over a person’s lifetime, how their search interactions develop over time, and how search in the aggregate is evolving over time. In other words, we need more longitudinal studies.

CW: Any bits of advice to practitioners about to attack the search tools on their sites? Lessons from web search?

AS: A key problem for practitioners is the lack of computer people trained in information and web retrieval, web design, and web usability. There is a lack of good trained people and not many industry consultants who really understand search. Search is much harder than most people think, and the design of effective search tools is even harder. Practitioners need to really test any search engines they consider buying. Many companies claim that their search engines are effective and the best, but provide little real evidence for their claims.

Be careful of the search engine that promises effectiveness and superiority based on a “single” feature, e.g., linking or clustering. There is no silver bullet feature. We don’t yet have Search engines that have adopted a more holistic attitude based on a real understanding of search, people’s information behavior and what is really effective. Whoever takes that path effectively will gain competitive advantage in the marketplace.

For More Information

Spink, A., & Currier, J. (2006). Emerging evolutionary framework for human information behavior. In: A. Spink & C. B. Cole (Eds.), New Directions in Human Information Behavior. Berlin: Springer (pp. 13-31).

Spink, A., & Cole, C. B. (2006). Human information behavior: Integrating diverse approaches and information use. Journal of the American Society for Information Science and Technology, 57(1) 25-35.

Spink, A., & Currier, J. (2006). Toward an evolutionary perspective on human information behavior: An exploratory study. Journal of Documentation, 62(2), 171-193.

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.

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.

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.

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

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:

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!

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.

As site creators, it would be time-consuming, expensive, and contentious to develop and maintain the necessary infrastructure and processes to manage unorganized content. As site users, it would be maddening to try to sift through the links in Yahoo’s directory trees if contributors and reviewers hadn’t organized them ahead of time. By organizing content for presentation according to its metadata, we can “contextualize” for potential users.

In content metadata and hierarchies, however, you will often find a goldmine of implicit and explicit data that you can leverage to creatively contextualize content. Following a brief introduction on taxonomy and metadata (what I call content classification requirements), this article will focus on finding and utilizing such relationships in hierarchies.

Content classification requirements: taxonomy and metadata
“Taxonomy” is a terribly overused term these days. Bob Boiko, in the book Content Management Bible, goes so far as to call it “trendy.” Specifically, taxonomy is a hierarchical structure for the classification or organization of data. Historically used by biologists to classify plants or animals according to a set of natural relationships, in content management and information architecture, we tend to leverage taxonomies as a tool for organizing content (For additional information, see Christina Wodtke’s interview with Samantha Bailey elsewhere on Boxes and Arrows).

Metadata (data about data) describes an asset and provides us with a meaningful set of attributes that we can use to further classify or consume content. While much metadata is flat or one-dimensional in nature (e.g., size or weight), some of it is hierarchical (e.g., taxonomies), making the definition and distinction between metadata and taxonomy vague and fuzzy.

Collectively, I tend to manage taxonomy and metadata needs as simply content classification requirements; taxonomy as a means of organizing content and metadata as method of further describing it.

If your task, for example, is to classify independent musicians for a website and database, you may choose a taxonomy that organizes the artists by musical style and then create metadata to describe the members of the band, the year of inception, record label, discography, and geography.

Figure 1: Sample taxonomy for classifying music and musicians (Click to enlarge).

Geography is particularly interesting as it has the potential to be hierarchical metadata itself. Let’s say your database expands to include musicians from around the world. Your hierarchy of geography could include country, state or providence, region and/or city. That’s a whole new hierarchy, perhaps even a taxonomy. Geography, by itself, has become an effective and alternative means of organizing your content.

Figure 2: Sample geography taxonomy

How to develop content classification requirements
When developing a content classification strategy, it’s important that you know your needs, your application, and the technical limitations of your software infrastructure and content producers. It’s quite possible that your content management and delivery needs will tax the capabilities and APIs of your content management tools. It’s also quite possible that you will severely overtax the abilities and/or patience of your content producers (see sidebar). If there’s development to be done or sacrifices to be made, keep these constraints in mind as you design the application.

There’s a very good chance that you will need to revisit and revise your content classification strategy periodically. Life changes, business changes. It is more important that you plan for and design a mechanism and set of policies for easy adaptation, than waste countless hours fine-tuning your taxonomy here and now.

Therefore, here are my guidelines for development of your content classification requirements:

• Address governance as early as possible in the design cycle.
  How will your content classification get revised and extended? How frequently? What person or team will be responsible for the maintenance of your metadata? How will you settle disputes?
• Identify the scope.
  Are you organizing content for creation? Consumption? Both? A specific department? Some combination of departments? Intranet? Extranet?

  Admittedly, it’s important that you not rule out the eventual integration of this work with other initiatives and parts of your business but consider the value of bounding your project. Scope creep is a serious risk as you begin cataloging and classifying your content. Instead of solving all the organization’s problems right now, invest time and energy in defining how your classification requirements can and will change over time.

• How does the scope of this application relate to your business organization.
  Are you striving for the development of an enterprise taxonomy? Enterprise taxonomies are a popular concept right now, especially in organizations initiating development of 3rd and 4th generation intranets. An enterprise taxonomy is typically perceived as a single, monolithic, corporation-wide, structure for the classification of all things related to your business.

  Unfortunately, development of an enterprise taxonomy requires the careful coordination, and cooperation, of departments within your organization. Will you be able to coordinate the efforts, language and needs of your IT and sales departments? If so, kudos to you. If not, welcome to the real world.

  Disparate divisions within an organization will often use different terms when referring to the same thing. This means, more often than not, the scope of your content classification requirements will be constrained to some subset of the organization or to a particular business process.

• Catalog your content.
  The exercise of cataloging your content can be very informative. A lot of guidance, limitations, and input can be achieved during this process. More often than not, your classification requirements will vary by content class or type.
• Focus on developing good criteria for the definition and extension of your metadata and taxonomy.
  Good rules will enable those tasked with management to respond quickly and with reason to requests for adaptation.

Organizing content for management and delivery
So now we can build a strategy for classifying the content we hope to manage and we have attributes. Now, we need a method for presenting our content. Strategies for getting content from a management infrastructure to the delivery framework (internet, intranet, extranet, client-server application, XML-web services, etc.) vary. Here are two common techniques:

1. Universal Hierarchy
A single hierarchy could be used to store and deliver content. When content contributors utilize the content management system, they add, remove, and manage content in a structure that closely resembles the navigation and hierarchy of the delivery framework (your website or application). The navigation structure is your taxonomy.

Figure 3: Organizing content for delivery by Universal Hierarchy (Click to enlarge)

This method is conceptually simple and makes it quite easy to dynamically build your navigation from knowledge of this hierarchy. However, this model does have drawbacks:

• Every time you reorganize the website, the organization of content in your management application shifts. Admittedly, this isn’t much of a drawback if you’re managing content for one moderately sized site or if your team of contributors is small.
• It is difficult to reuse content in this structure. If you hope to reuse assets throughout your website, where are they organized in this structure?
• In an environment with many contributors and diverse security requirements, organizing content (in the management application) in another way, say by contributor or by department, may be more intuitive.

2. Content Mapping
A more robust, albeit more complex, method of managing content is to maintain structures and metadata in the content management application that is independent of the delivery system’s organization (navigation).

Figure 4: Organizing content for delivery by Content Mapping (Click to enlarge)

Content is organized, at the source, as may be required by your security, workflow, or organizational needs. Perhaps your data lives in a content management system or database where different organizational mechanisms exist. Unfortunately, oftentimes the navigation for your consuming application (the presentation framework) is managed by some other means.

By some rule or algorithm, leveraging your content classification data, material gets “mapped” to the presentation framework. See the example below for an application of this model.

This model is rich with possibilities:

• There may be more than one way to organize content (think: content reuse). Given the same set of content, same set of classification criteria, but multiple algorithms, we can now build a delivery framework that allows for many methods of organization.
• You no longer need to reorganize your content management application to change the delivery application. Just the algorithms (mappings) change.

However:

• If you hope to build your navigation dynamically, often you’ll need to build a tool or alternate hierarchy. You may not find much value in the content’s taxonomy.
• Content, in your management environment, may be orphaned in your presentation framework if there are no rules mapping to an accessible part of the site.
• Parts of the site may only be sparsely populated. It may not be readily obvious that you are creating gaps (with little or no content) in your site.

While powerful, this technique can be difficult to administer without having a fairly comprehensive understanding of the site design and algorithms for “mapping.”

Creative contextualization of content using hierarchical metadata or taxonomy
Assuming there are hierarchical structures within your content classification system, there is a very good chance that valuable information exists in the hierarchy. By taking advantage of relationships within your hierarchical metadata structures, richer algorithms may be developed for your content delivery framework.

Lets identify some of these relationships and how you can leverage them:

• Ancestors
  In the example below, North America is an ancestor of America, which is an ancestor of West (and Washington – WA). Ancestors can be valuable because content classified under an ancestor node may have relevance (albeit with less specificity) to child nodes.

  If you are looking at content classified under America, it’s quite possible that there is relevance in the information classified under North America.

• Descendents
  In the example below, Canada is a descendent of North America. Descendents have value because content classified under a child or descendent node may have greater specificity. This content provides consumers of your delivery framework (users of your website or application) with a means of realizing granularity in the data.

  A website visitor reading about your corporation’s news and events relevant to North America may appreciate that there is new specific to Canada or California.


Figure 5: Nested sets within a geography taxonomy (Click to enlarge)
• Nested Sets
  Nested sets are the union of data classified under a particular node and all of its descendents. The example, above, shows three sets. One of those sets is North America and all the nodes within it. Content classified under nodes within a single set may have relevance because they are related by something inherent in the structure (they’re all part of the same ancestor).

  If you hope to convey, in a single “view” or page, contact information for all of your offices in North America, then you want contact information classified under North America and all its descendent nodes (i.e., within the North America nested set). If the user wants to see a summary list of contact information within a particular region, they navigate to a node of greater specificity (a descendent).

• Peers
  Peer nodes exist within a nested set of the hierarchy. Peers have equal depth within a particular nested set of the hierarchy.

  Borrowing from the example hierarchy, below, if a user has navigated to content classified under Educational Toys (at depth 2 of the Toys nested set), you may find it valuable to provide them visibility into Plush Toys. These topics share context (Toys), but by providing visibility into peer nodes, you convey the breadth of your toy inventory.

Figure 6: Set and depth in a product taxonomy (Click to enlarge)

So what’s the point? If you’re building algorithms that map content, from your database or content management system to a delivery framework (website or application), it may be both necessary and beneficial to consider content by these relationships.

For example, let’s say the assets in your content management application are organized by type (press release, white paper, image, etc.) and corporate division; it’s an easy and logical choice that allows you to manage security in the content management application at the department level, but it doesn’t accurately reflect the organization of your internet site.

It’s your task to map content from the source (content management application) to the presentation system (internet delivery framework). If several parts of your organization are capable of producing press releases, and these press releases are stored in department-specific areas of the content management application, how do you get them on the site?

Example “algorithms” for populating the press release and investor news sections of your internet site may read like this: “All press release type assets, in a “ready” state (leveraging metadata), except those in the investor relations nested set are queried, sorted in descending order by publish date and rendered in the Press Releases section.” Additionally, “All press release type assets, in a “ready” state, in the investor relations nested set are queried, sorted in descending order by publish date and rendered under Investor Relations > News.”

By leveraging the more complex relationships available in hierarchies, we facilitate the presentation (contextualization) of content without impacting it’s organization. Too frequently, contextualization algorithms neglect implicitly derived information available in hierarchies. Narrowly scoped queries are used to relate content to its place in the delivery framework.

It’s up to the information architect to find and realize the value of these relationships when developing a content delivery framework. The opportunity for improved usability and greater content visibility using these relationships is tremendous and oftentimes supports the mission of an IA.

Technical issues
Unfortunately, knowing about these relationships is not enough. Pre-assembled content management and delivery frameworks may not provide the APIs or schema necessary to effectively leverage this knowledge. It’s important to understand what you want, and then to find and understand the limitations of your tools.

Maintaining and consuming hierarchical data in tabular relational database management systems (RDBMS) systems can be difficult, but with creative database administration, the relationships can be assembled in temporary tables and/or discovered by stored procedures.

This is valuable stuff. If it improves content delivery, consider the cost of developing a method for accessing these relationships if it doesn’t already exist.

Summary
When developing your content classification strategies (for both content management and presentation), make a point of evaluating your hierarchical structures for relationships and valuable data hidden within them. Relationships between nodes of a hierarchy are complex, but often mirror the perception of your users.

By leveraging these relationships, you can broaden the scope of your queries. Broaden the scope of data presented to the users, and drive users toward tangential content.

For More Information:

• Boiko, Bob. Content Management Bible. John Wiley & Sons, 2001.
• Aifia Tools http://aifia.org/tools/
• Series on controlled vocabularies and faceted classification by Karl Fast, Fred Leise and Mike Steckel
1. All About Facets & Controlled Vocabularies
2. What is a Controlled Vocabulary?
3. Creating a Controlled Vocabulary

4. Synonym Rings and Authority Files
5. Controlled Vocabularies: A Glosso-Thesaurus

Christian Ricci is a consultant, application developer, web designer, and project manager with over 11 years of experience in software design and development, network and server administration, and software project management and engineering. As a Senior Solutions Architect for Saillant Consulting Group, Chris has lead portal, content, and document management projects for Qualcomm, Intermountain Health Care, J.D. Edwards, EAS, and the Denver Post.

Site: http://www.chiamonkey.com/
Resume: http://www.chiamonkey.com/mealticket