Why is it important to be able to visualize information architecture? There are several answers. One is that the field is new, and many people don’t believe that things exist until they can see them. Another is that the field is abstract, and many who might conceptually understand the basic premise of information architecture won’t really “get it” until they see it and experience it. Finally, a well-designed information architecture is invisible to users (which, paradoxically, is quite an unfair reward for IA success).

IA’s lack of tangible qualities forces all information architects to be salespeople to some degree. Because it’s highly probable that you’ll need to explain information architecture to several important people, including colleagues, managers, prospects, clients, and perhaps your significant other, it’s in your interest to be able to help them visualize what an information architecture actually is.

Let’s start by looking at a site’s main page. Figure 4-1 shows the main page for Gustavus Adolphus College in Saint Peter, Minnesota, USA.

What’s obvious here? Most immediately, you see that the site’s visual design stands out. You can’t help but notice the site’s colors (you’ll have to take our word for it), typeface choices, and images. You also notice aspects of the site’s information design; for example, the number of columns—and their widths—changes throughout the page.

In recent years, increasing attention has been focused on the challenge of organizing information. Yet this challenge is not new. People have struggled with the difficulties of information organization for centuries. The field of librarianship has been largely devoted to the task of organizing and providing access to information. So why all the fuss now?

Navigation systems are composed of several basic elements, or subsystems. First, we have the global, local, and contextual navigation systems that are integrated within the web pages themselves. These

Before we delve into search systems, we need to make a point: think twice before you make your site searchable.

Your site should, of course, support the finding of its information. But as the preceding chapters demonstrate, there are other ways to support finding. And be careful not to assume, as many do, that a search engine alone will satisfy all users’ information needs. While many users want to search a site, some are natural browsers, preferring to forego filling in that little search box and hitting the “search” button. We suggest you consider the following questions before committing to a search system for your site.

When it comes to definitions, metadata is a slippery fish. Describing it as “data about data” isn’t very helpful. The following excerpt from Dictionary.com takes us a little further:

In data processing, meta-data is definitional data that provides information about or documentation of other data managed within an application or environment. For example, meta-data would document data about data elements or attributes (name, size, data type, etc.) and data about records or data structures (length, fields, columns, etc.) and data about data (where it is located, how it is associated, ownership, etc.). Meta-data may include descriptive information about the context, quality and condition, or characteristics of the data.

In the early days of web design, many companies employed a one-step process called “Code HTML.” Everyone wanted to jump right in and build the site. People had no patience for research or strategy. We remember one eager client asking us in the middle of a planning session, “So when are we going to start the real work?” Fortunately, after several years of painful lessons, there’s a growing realization that designing web sites is hard work and requires a phased approach. Figure 10-1 illustrates the process of information architecture.

An information architecture strategy is a high-level conceptual framework for structuring and organizing a web site or intranet. It provides the firm sense of direction and scope necessary to proceed with confidence into the design and implementation phases. It also facilitates discussion and helps get people on the same page before moving into the more expensive design phase. Just as the operating plans of each department should be driven by a unifying business strategy, the design of a detailed information architecture should be driven by a holistic information architecture strategy.

It’s not surprising to see all this confusion. In such a new discipline, all the paths are “less traveled.” Schools are not sure what to teach, and students don’t know what they need to learn.

In the established professions of medicine, law, and business, a vast array of educational programs has been tested by the evolutionary pressures of the market. Only those programs that add value have survived. The independent forces of supply and demand have moved toward equilibrium.

The truth is that ethics is one of the many hidden dimensions of information architecture. As Geoffrey Bowker and Susan Star state in their book Sorting Things Out (MIT Press):

Good, usable systems disappear almost by definition. The easier they are to use, the harder they are to see.

Large information systems such as the Internet or global databases carry with them a politics of voice and value that is often invisible, embedded in layers of infrastructure.

Through the course of the book, Bowker and Star uncover the serious ethical dimensions of organizing and labeling information.

Now, don’t worry. We’re not about to stand on a soapbox and tell you how to save the world. Instead, we present a framework that illuminates six ethical dimensions faced by information architects, so you can make your own decisions. Once again, we humbly seek to make the invisible visible.

We are living in the stone age when it comes to software for information architects. The products are crude, as is our understanding of what we really need. When people get together to discuss experiences with enterprise-wide applications to support web sites and intranets, pain and suffering are dominant themes. Many organizations become so distracted and discouraged by their first web application that they fail to explore the products in related categories.

This will change. In the coming years, all large web sites and intranets will leverage software applications from a wide variety of categories. We will not choose between automated classification software and a collaborative filtering engine—we will need both, and more. And information architects will play an integral role—working closely with business managers, content managers, and software engineers to select, acquire, integrate, and leverage this sophisticated suite of applications. None of these people can successfully do this work alone.

Perhaps you’ve never found yourself trying to sell information architecture to a client; that’s what the sales folks do, or if you’re an in-house information architect, your boss worries about this. Your job is to just show up and generate those blueprints and wireframes. If this describes your attitude, skip this section. (But don’t be surprised if you suddenly find yourself unemployed.)

When it comes to others’ perceptions of information architecture, be prepared to change negative thinking into positive. Most people still haven’t heard the term “information architecture,” many don’t think it’s real or worth their attention, and many simply don’t understand the value of anything so “fuzzy,” especially when compared to concrete things like, say, the intensively marketed software tools that promise to solve their problems.

Some people do recognize the value of information architecture but don’t know how to convince their colleagues. And others implicitly recognize its value in theory, but simply don’t yet have the practical experience to tell the people in charge just how valuable it is compared with the many other ways they can spend their money.

You need to be ready for all of these situations—not just getting the point across initially, but being able to “sell” what you do on the ground. Because the worst can and often does happen after the sale. In fact, in a May 2002 survey of the information architecture community, we found that the most challenging aspect of promoting information architecture was not getting the opportunity to promote it until it was too late in the design and development process. We’ve sold many large information architecture consulting engagements only to find that as soon as we sent our consultants off, some unanticipated and terrible event happened that jeopardized the entire project. For example, one person who hired us for a Fortune 50 company retired the day before we showed up for work. Worse, despite his assurances to us, he never had the political power within the organization to pave the way for our work. And even worse, he hadn’t prepared his successor in any way; the successor didn’t have a clear vision of the value of information architecture and obviously couldn’t advocate for it to his colleagues. So our own consultants had to sell their expertise on his behalf. This made it difficult for them to actually get any work done, but they were ready to sell themselves, and it made a big difference. If our people couldn’t have made a case for information architecture, the whole project would have been torpedoed.

What’s enterprise information architecture (EIA)? Quite simply, the practice of information in the enterprise setting.

Sorry, that definition was accurate but not too helpful. Let’s back up and make sure we understand what an enterprise is. Most would say that it’s a large, physically distributed organization—usually a corporation or a government agency, but we’d also count substantial academic institutions and nonprofits. Enterprises suffer from problems big and complicated enough to merit serious, expensive solutions. (Hence, software marketers have found that prepending the term “enterprise-class” to their products’ names is a reasonably reliable path to a condo in Aspen.)

But “large” and “physically distributed” aren’t what really defines an enterprise. In fact, the most telling attribute is a place where “one hand doesn’t know what the other one’s doing.” Or, one hand ignores or doesn’t care what the other’s doing. Or that first hand absolutely despises the second hand, and will do anything to undermine it. Interestingly, these attributes can be found in just about any organization, regardless of size or physical distribution. So while you might not work at ExxonMobil, Thomson, or the UN, it’s likely that you’re dealing with enterprise-class IA challenges.

Enterprises have been characterized by a constant tug-of-war between forces of centralization and autonomy. A new management regime comes in, finds wasteful duplication of effort and expense, and discovers a lack of coordination and collaboration among business units. The new managers try to reign things in by centralizing as much as they possibly can. Typically this process fails to have its intended impact and even creates some unintended negative consequences, such as choking off local innovation. Then a new regime enters the picture, sees a new set of problems, and in its hurry to leave its mark, swings the pendulum hard the other way: “let a thousand flowers bloom.” Staff in far-flung units are empowered to take things into their own hands but may do so in a wasteful, duplicative, uncoordinated manner. And we’re back where we started.

Like Microsoft itself, MSWeb is insanely huge and distributed. Let’s use some numbers to paint a picture of the situation. MSWeb contains:

What is evolt.org? That’s simple—it’s explained at the bottom of each page in the site: