You read it right. Many large IA projects get completely derailed by this one page among the millions that comprise your site. Granted, there are an increasing number of other ways to reach your site’s content, such as via a web-wide search engine, an RSS feed, and your advertisements. Still, you know that the main page is the single most important page on your site; the problem is that everyone else in your organization knows that, too. The result: design meetings where senior vice presidents joust over dozens of main-page pixels.

Of course, you could try to shepherd such a meeting to a productive end—a place where the main-page design is conceived with the needs of the enterprise as a whole and the users it serves, rather than the setting where interdepartmental strife plays out. But that might take years, and you’ve got other fish to fry. So we advise you to be prepared to step away from your normal urge to care about the main page. Consider it an unfortunate chunk of real estate that could be so nice if only the warring gangs would cease and desist. You’ll have a chance to rehabilitate it later; for now, move on...

...to other pieces of real estate that might be quite useful if only anyone bothered to pay attention to them. For example, your sitemap (aka table of contents, as discussed in Chapter 7) may already be linked to throughout your site. That makes it a property with considerable value. And yet, it’s often something of an orphan; it may not be clear whose responsibility it is, and few people bother to use it. Can you blame them? Most sitemaps simply mirror the site’s main organization system, and in many enterprise sites, that’s the org chart. Not very useful.

Normally, your attention would be focused on improving the organization system, weaning your enterprise from an org-chart-driven self-view. But that’s quite difficult to pull off in an enterprise setting, and requires considerable agreement and coordination.

If you want to get things done in the enterprise, it’s often better to ask forgiveness than to beg permission. So you should consider sneaky, Machiavellian means for improving your organization’s information architecture. One trick is to redesign the sitemap so that it stops mirroring what is, and instead suggests what could be. In other words, use the sitemap as a sandbox to try out a new, more user-centered organization system. Chances are, few will complain, and you may be able to monitor traffic to this page to see how well your changes have gone over. This might help you build a case for eventually revising the site’s organization system; or, when your enterprise is ready to seriously consider improving site-wide navigation, you can point to a readily available model for how to do it. This whole messy undertaking may leave you feeling a little impure, but what the heck: life is short, and besides, no lives will be lost or damaged by your noodling around with your enterprise’s sitemap.

Another prime piece of real estate is the site index (also covered in Chapter 7). Like the sitemap, an index ties together content from silos all over your enterprise, thereby making it a great EIA tool. But indices are expensive to develop and maintain. And, in fact, site indices are often superseded by search systems; both support known-item searching, but search is more automated and comprehensive.^[2]

Does this mean you should throw out your site’s index? Generally, no. Many search systems aren’t well designed, so users might still need to rely upon an index as a backup. What can you do to make that backup effective while cutting back on its maintenance costs?

Consider a specialized site index. Instead of trying to index everything in your site, focus on one critical type of information. For example, the Centers for Disease Control’s index, shown in Figure 19-2, doesn’t include directions to its campus or biographies of its directors. Instead, it provides an A–Z list of health topics and issues—the primary kind of content that users come to the site for.

Figure 19-2. The Centers for Disease Control’s specialized index on health topics

A specialized index is far simpler to maintain than a soups-to-nuts version, and because it’s focused on the important content type, it can provide value to a wide array of your enterprise site’s users.

As an alternative, you might consider another variety of less-than-comprehensive site index. Michigan State University builds its site index, shown in Figure 19-3, automatically, using the same common keywords derived from search-log analysis that have been assigned Best Bet results. Essentially, if the query is good (common) enough to merit a Best Bet, it’s good enough to be included in the site index. Note that each entry links directly to its Best Bet result:

Figure 19-3. MSU’s index is automatically generated from common search keywords; the index is uneven but useful nonetheless

Guides, also covered in Chapter 7, are different from other forms of supplementary navigation. While they can link to content from any silo, guides don’t offer comprehensive coverage of your site’s content like sitemaps and traditional site indices do. Guides, like the one in Figure 19-4, are selective—they’re something of an enterprise FAQ—and for that reason they’re ideal “glue” for your enterprise site.

We recommend developing a handful of guides that address users’ top information needs and tasks. What do users really want and need from your site? Here’s your opportunity to serve those needs in an especially simple and low-tech way; guides are simply single pages of HTML code, and therefore don’t require specialized technical expertise or applications to implement. And you can use a variety of methods to determine common needs, such as search-log analysis (discussed in Chapters 6 and 10), persona development, and even talking to your organization’s switchboard operators.

Figure 19-4. Vanguard introduces its guides front and center on the main page (in the “I want to ” section)

We’re especially enthusiastic about guides in the enterprise context because they scale well. You can develop as many guides as your resources allow. The largest bottleneck typically comes from identifying subject matter experts. But in many cases, the expert—in the example above, the poor person besieged by requests for help processing travel expenses—will often be glad to encapsulate his knowledge so he doesn’t have to answer the same question over and over.

Guides are also a good reminder of how you should think about allocating your EIA resources. Let’s face it: you could spend decades trying to develop the ideal information architecture to serve all of your content to all of your users. No one has that luxury—or patience—as far as we know. Prioritization is the only viable alternative, and guides are an ideal tool to aid in efforts to prioritize your EIA development. Build a few guides to address common tasks and information needs, and you’ll see how a little effort can go a very long way.

To build momentum toward ambitious content-integration projects, you’ve got to start with baby steps. First among them is building a handful of content models (which we’ve introduced in Chapter 12).

Think back to the common information needs and tasks that we discussed earlier. Each might require navigating deep into the guts of your site; strong contextual navigation requires strong content models. Of course, some of the most critical tasks and information needs will require content models that cross departmental silos; set those aside for now and focus on the ones that can be served from within a single business unit’s web site. These will be easier to tackle, because 1) they involve fewer people, and 2) they won’t run into some of the metadata challenges that we’ll describe shortly.

Your goals are to get other people in your enterprise familiar with the idea and execution of content models, which is already a lot to ask of them. So focus on simple tasks and needs that can be addressed by content within a single silo. What useful content model could you build within Human Resources? Marketing? Within your staff directory? Or for each of your products? Your site’s users will benefit from even limited contextual-navigation improvements, and your organization will benefit in the long run from both the experience with content modeling that it gathers, and, ultimately, the ability to connect those content models across silos.

As much as we’d like to build interconnected semantic webs throughout the guts of our enterprise’s content, metadata keeps getting in our way. Figure 19-5 shows a simple illustration, using the BBC content model. Here we want to connect our model with relevant content—let’s say events from a concert calendar and TV listings—from other silos within the BBC.

Figure 19-5. We’d like to connect (along the dotted lines) our content model to other models from other business units; do we have the right metadata to make this happen?

This should work—if we’ve got the same metadata to use to make the connection. Unfortunately, this isn’t always the case. For example, let’s assume that the artist’s name is the metadata that connects “artist descriptions” and “TV listings.” If the people who maintain the TV listings use a different version of an artist’s name—say, an abbreviated or all-caps version, and you list artist names differently, it can be tricky to automate the creation of a link between those two chunks of content.

Usually, software can be taught to understand and deal with simple differences like these. But as metadata becomes more descriptive, even the best artificial intelligence falls flat. For example, if one unit at the BBC classifies Johnny Cash’s music as “country,” while another unit deems it “Americana,” genre metadata wouldn’t be very useful or usable for automating connections between content models. Achieving agreement—such as on a standard usage of controlled vocabulary terms—is quite difficult, often for political reasons. And expensive efforts to retrospectively reclassify content might serve as yet another roadblock to relying on shared metadata across the enterprise.

It’s not all gloom and doom, though. Whenever you create a content model, you’re forced to select the most useful metadata attributes to build from a wide variety of possibilities. The same is true when you connect content models across silo boundaries—this exercise reveals the few types of metadata that you should focus your efforts on across the enterprise. So efforts to build enterprise-wide content models will have a useful byproduct: in the process, you’ll identify the few most important varieties of metadata to invest in.

In the above example from the BBC, you can see that some metadata types are easier to standardize than others. Because EIA is an expensive, long-term undertaking, you’ve got to prioritize whenever possible, taking on the easy wins first while building momentum toward tougher challenges. In the case of metadata, some varieties are indeed easier than others, though nothing’s ever easy.

Use content model exercises to help you choose which types of metadata to develop or acquire. But also keep in mind that, in general, the less ambiguous the metadata, the cheaper and easier you’ll find it to develop or acquire, and maintain. Table 19-1 orders some common (but by no means comprehensive) types of metadata attributes, from least to most difficult.

Similarly, as we know from examining thesauri in Chapter 9, metadata can support a complexity of semantic relationships, ranging from synonyms to broader/narrower terms to related terms (see Table 19-2). Consider beginning your enterprise metadata journey by relying on simpler vocabularies that provide only synonyms, rather than full-blown (and more expensive) thesauri.

Simpler vocabularies mean simpler information architectures. You might be able to assemble the metadata you’ll need for the top few layers of a site-wide navigation system before politics and your own lack of expertise with local content get in the way of going deeper. And your architecture almost certainly won’t be able to take advantage of “see alsos” and other related terms in any substantial way until your organization achieves some measure of “EIA maturity.”

It’s amazing that, after years of kicking around in the backwaters of corporate consciousness, “metadata” has suddenly emerged as a buzzword. Yet many senior decision-makers now see it as a panacea in much the same way they held out hopes for portals, personalization, and search in the past. We should all realize that there’s no such thing as a silver bullet, especially when it comes to information architecture; each interesting approach, new or not, comes with many hidden costs. Understanding the varying degrees of difficulty involved with metadata implementation will help you—and your enterprise—scale up its investment in metadata-driven solutions in a reasonable and ultimately successful manner.

If it’s important anywhere, it’s especially important in the enterprise: a simple search interface—“The Box”—should behave consistently and be consistently located on each page, like the one shown in Figure 19-6, regardless of who owns that page. Thankfully, this is becoming a convention, partly due to the advent of content management systems and their use of standard templates, which can be customized to include a simple search interface.

Figure 19-6. If IBM can pull off a simple search interface on each of its pages, so can you!

Perhaps your enterprise isn’t able or willing to provide a standard interface. Don’t let that stop you; simple search is a good cause around which you can build a campaign for some measure of enterprise centralization. Not only is it everywhere (you don’t have to look far to see how it’s emerged as a convention), but you can find good supporting data; for example, you can always cite a guru like Jakob Nielsen, who makes the point^[3] that roughly 50 percent of all users begin their sessions on any given site by searching. Very few people can muster a strong case against ubiquitous simple search interfaces, and once you succeed with this particular battle, you’ll have momentum to take on bigger challenges that require some measure of coordination across the enterprise.

If search systems are the killer app for enterprise sites, then search-log analysis is the killer enterprise diagnostic tool. You don’t need to spend months analyzing your query data to reveal some critical problems with your search system and content. Common examples: users’ preponderance to misspell and mistype queries (fix it by implementing a spell-checker to your search system), frequent entry of acronyms and jargon (address with a glossary), searches for product codes (make sure your product pages include those codes!), and so on.

Additionally, search-log analysis is a means for revealing which are the most commonly searched queries on your site. You can use this data to prioritize your efforts at developing Best Bet search results (covered in Chapter 8) and in a similar vein, guides, which could be considered Best Bets for main pages.

The numbers are really in your favor here: let’s say you create Best Bet results for the 200 most common queries. These 200 queries account for 25 percent of your all queries executed on your site. If, as Jakob Nielsen suggests, 50 percent of your site’s users start by searching, multiply that 50 percent by 25 percent; the result is an improvement in the user experience for 12.5 percent of all users. These numbers, like all IA-related numbers, can be easily challenged, but the message behind the numbers—improved performance—still rings loud and true.

While you’re at it, look over those top queries, identify which have zero results, and plug those content gaps. Might that bring you another three to five percent improvement in the user experience? Not bad. Add in some percentage for users who’d previously been defeated by spelling errors and typos, and the numbers start to add up.

No matter what you do to improve your enterprise search system, poor content and metadata can conspire to derail your efforts. Garbage in, garbage out. And in a distributed environment, it’s hard to even find authors, much less to convince them to do a better job preparing their content for consumption via the web site or intranet.

When you do have the opportunity to bend an author’s ear, you’ll need a good tool to help convince him to do a better job authoring content, applying metadata tags to it, and titling documents. Whether this comes up in the context of an enterprise style guide or a face-to-face meeting, come prepared with an example of poor search results—which include some of his own documents—to demonstrate just how much his work impacts users down the line.

For example, a search for “financing” on the DaimlerChrysler site returns poorly formatted, poorly titled results, as shown in Figure 19-7.

Figure 19-7. Wouldn’t you be a bit embarrassed if you were the author of one of these documents? (Or, for that matter, responsible for the search system?)

You now have the opportunity to show authors of these documents the importance of well-considered document titles. Conversely, you could show content authors how their documents don’t show up as highly as they should in search results, and explain to them how they might improve their rankings by following the enterprise’s guidelines on writing titles and good copy, and assigning metadata.

Poor search results are an effective way to communicate to authors just what happens when they fail to see their content, and their work, as part of something much larger—namely, an enterprise web site or intranet that serves thousands of users. “Reverse-engineering” search results uncovers opportunities for authors to do better, makes the case for doing so quite clear, and provides you with a way to accomplish “organizational change” in a small but important way: author by author.

Remember the person who knew so much about filing expense reports at our fictional consulting firm? She’s an SME (Subject Matter Expert) whose expertise spans multiple business units’ content. It serves the goal of EIA to enable her knowledge to be captured and shared more broadly within the enterprise. To that end, many companies are providing simple blog tools to their SMEs—sometimes describing them as “klogs,” or knowledge blogs^[4]—to help them share what they know.

Implementing klogs internally is technically fairly simple; however, identifying SMEs—especially ones with valuable cross-departmental knowledge—may be a bit difficult. Even more challenging, your enterprise’s culture may not support its employees sharing their knowledge. It’s an unfortunate fact that many organizations encourage its opposite: knowledge hoarding. Additionally, many SMEs aren’t willing to share what they know simply to protect their job security. So klogs aren’t a slam dunk, especially in settings where there is little incentive to share information. But their technical barrier to entry is low, and they at least merit consideration. Many individuals already do share their knowledge, especially if it raises their personal visibility as an expert within the enterprise (and if it helps them to avoid answering the same questions over and over again).

Just as klogs enable individuals to capture and share their cross-departmental knowledge, wikis and other shared-authoring tools have similar potential for groups. Every enterprise has projects that require collaboration from multiple business units; these are typically tackled by temporarily constituted committees and working groups.

Wikis can make it relatively easy for these committees to capture their work—which, by definition, has cross-departmental value. In many cases, the content these groups develop will eventually receive official blessing and be published in a more traditional format, perhaps as a Word document or a PDF. But even in its relatively fluid and unfinished state, such content can have significant value to enterprise users. Additionally, wiki-based content is more likely to be accessible via search systems than Word or PDF files.

In so many cases, we search intranets for people rather than content. As cross-departmental information systems, staff directories are already excellent demonstrations of the value of EIA. We can extend their value by linking directory entries to corresponding klog and wiki content. The result: users can find out more about coworkers than their email addresses; they can learn about colleagues’ expertise, what projects they’ve served on, and who they served with. Users can also search a topic and ultimately find a person.

Traditional directories can also be expanded to include more relationships between coworkers, such as reporting relationships. For example, it can be useful to know what to expect from the new boss by grilling a few of his past supervisees. Look to social-network services like LinkedIn (shown in Figure 19-8) and Ryze for models of how staff directories can be expanded and enhanced.

Figure 19-8. An entry from LinkedIn; is this your staff directory’s future?

If your enterprise does begin investing in blogs and other means for capturing cross-departmental content, the good news is that most of these new publishing tools generate RSS or Atom feeds for recently posted content (blogs especially, of course). The better news is that there are many tools, both web-based^[5] and standalone, that allow users to aggregate the feeds they’ve subscribed to. Imagine in-house researchers relying on aggregators to easily monitor the findings of their colleagues from research centers throughout the enterprise as soon as they’re published.

The even better news is that, as feeds become common for just about any type of web site, your enterprise’s users could subscribe to feeds from a variety of departmental subsites. The aggregator becomes the means for accessing an enterprise’s new content—regardless of originating silo—in one window. Imagine aggregating news releases from their many sources within your enterprise so you can keep up with what your own employer is actually doing—or enabling a public site’s users to do the same.

Social bookmarking applications like del.icio.us have succeeded at helping users tag and return to visited content from across the Web. And by seeing what others have tagged with the same tags, del.icio.us subscribers also benefit from the wisdom of the hive, learning about other relevant documents (and who shares a similar interest).

Could the same approach work in the enterprise? Although it’s too soon to say, large enterprises like IBM are hoping to find out.^[6] Enterprise environments are obviously smaller than the Web as a whole, but they certainly exhibit web-like characteristics, such as overwhelming growth, frustrating organization, and swirling change. Bookmarking tools could help enterprise users benefit from one another’s tagging efforts, and as an additional benefit, find like-minded colleagues. Collectively, tags also provide excellent fodder for helping improve traditional controlled vocabularies and bring them up-to-date.

The strategists—members of the Advisory Committee and Strategic Board—focus on the role of the EIA unit within the broader enterprise. Their mission is to ensure that the enterprise benefits from a quality information architecture through the efforts of the EIA group. Their goals are to:

In effect, strategists are responsible for the success of EIA operations. That means navigating politics, getting buy-in from management across the enterprise, and acquiring funding and other resources. It also requires the development of metrics to help judge the success of the enterprise information architecture broadly, and EIA operations specifically.

People who would be effective and available in the director’s role exhibit these qualities:

The EIA operations team takes on the tactical work of information architecture: researching and analyzing factors related to content, users, and business context; designing information architectures that address those factors; and implementing that design. Besides delivering the EIA Unit’s services, the operations unit follows (and upholds) policies and procedures for content management and architectural maintenance.

How should this team be staffed? There are many roles that would be nice to have on your team, including:

Of course, staffing each of these areas is a fantasy for most of us, but this ideal gives you something to shoot for. More importantly, it helps you line up outside consulting expertise. Don’t have a usability specialist on staff? Your entrepreneurial business model might allow you to pass a consultant’s costs to your clients.

When you do get around to hiring staff for your interdisciplinary operations team, look for these qualities:

Finally, consider what gaps your EIA unit is filling within the enterprise. You may find that you want to broaden your scope, branching toward conventional IT services such as hosting, or toward visual design, editorial, or other areas under the broader umbrella of experience design. Select your staff and consultants accordingly to fit the needs of the enterprise.