The Role of the Information Architect

Chapter 2

Introduction to Information Architecture

The Role of the Information Architect

Now that you know right from wrong from the web consumer's perspective, you're in a much better position to develop a web site. But besides needing a sophisticated knowledge of what works for consumers of the Web, what's actually involved in creating a web site?

Obviously, you need HTML pages. Maybe you'll grab a good HTML book or a decent HTML editing package. Maybe a high school kid can do the trick for peanuts. What about the copy for those pages? It needs to come from somewhere - perhaps existing brochures and documentation; perhaps it needs to be written from scratch. You'll also need some graphic design expertise to make sure that the pages are laid out with effective use of text, white space, and attractive images. Of course you'll need a server that is connected to the Internet; this you can lease, or you can buy one of your own. If you do, just be sure to hire someone sufficiently technically astute to administer that server. Perhaps that person should also write the CGI, Perl, ActiveX, Java, and other scripts that make the site interactive. What's missing? Maybe a project manager to make sure all these folks work together to develop the site without running behind schedule and over budget.

So now you're all set to design your web site, right?

Well, not quite. What's missing from this picture is a definition of what the site will actually be, and how it will work.

This may sound obvious, but for most web sites, it's true: design and production storm ahead without any unifying principle to guide the site's development. A web site essentially can be anything you want it to be and could cost millions of dollars, take years to complete, and cost thousands of lives to develop. To avoid such overkill, it will need to be defined somehow: it will need a definition.

That's the main job of the information architect, who:

•          Clarifies the mission and vision for the site, balancing the needs of its sponsoring organization and the needs of its audiences.

•          Determines what content and functionality the site will contain.

•          Specifies how users will find information in the site by defining its organization, navigation, labeling, and searching systems.

•          Maps out how the site will accommodate change and growth over time.

Although these sound obvious, information architecture is really about what's not obvious. Users don't notice the information architecture of a site unless it isn't working. When they do notice good architectural features within a site, they instead attribute these successes to something else, like high-quality graphic design or a well-configured search engine. Why? When you read or hear about web site design, the language commonly used pertains to pages, graphic elements, technical features, and writing style. However, no terms adequately describe the relationships among the intangible elements that constitute a web site's architecture. The elements of information architecture - navigation systems, labeling systems, organization systems, indexing, searching methods, metaphors - are the glue that holds together a web site and allows it to evolve smoothly. To a novice, this terminology is not very clear. These elements are extremely difficult to measure, and therefore even harder to compare. You really have to spend time using a site and get a feel for it before you can confidently talk about a site's information architecture.

Yet, we know these things are important. How? Well, consider your responses to the Boot Camp exercise in Chapter 1. How many of the likes and dislikes are not related to technical issues, copy editing, or graphic design? Remaining issues are probably tied to information architecture. Although perhaps indirectly, a poorly planned information architecture will adversely affect those other areas.

Well-planned information architectures greatly benefit both consumers and producers. Accessing a site for the first time, consumers can quickly understand it effortlessly. They can quickly find the information they need, thereby reducing the time (and costs) wasted on both finding information and not finding information. Producers of web sites and intranets benefit because they know where and how to place new content without disrupting the existing content and site structure. Perhaps most importantly, producers can use an information architecture to greatly minimize the politics that come to the fore during the development of a web site.

1. The Consumer's Perspective

Consumers, or users as we more commonly refer to them, want to find information quickly and easily. Contrary to what you might conclude from observing the architectures of many large, corporate web sites, users do not like to get lost in chaotic hypertextual webs. Poor information architectures make busy users confused, frustrated, and angry.

Because different users have varying needs, it's important to support multiple modes of finding information. Some users know exactly what they're looking for. They know what it's called (or labeled), and they know it exists. They just want to find it and leave, as quickly and painlessly as possible. This is called known-item searching.

Other users do not know what they're looking for. They come to the site with a vague idea of the information they need. They may not know the right labels to describe what they want or even whether it exists. As they casually explore your site, they may learn about products or services that they'd never even considered.

Iteratively, through serendipity and associative learning, they may leave your site with knowledge (or products) that they hadn't known they needed.

These modes of finding information are not mutually exclusive. In a well-designed system, many users will switch between known-item searching and casual browsing as they explore the site. If you care about the consumer, make sure your architecture supports both modes. While attractive graphics and reliable technologies are essential to user satisfaction, they are not enough.

2. The Producer's Perspective

Since few organizations are completely altruistic, they usually want to know the return on their investment for information architecture design. In other words, what's in it for them? First, a disclaimer. Buying information architecture services is not like investing in a mutual fund. You can't calculate hard and fast numbers to show the exact benefit of your investment over time.

Nonetheless, you can demonstrate the value to the organization through less scientific means. Depending upon the goals and nature of your site, you may even be able to defend your investment with some not-so-hard numbers.

Consideration of value to the producer takes us back to the consumer. If you're producing an external web site, this involves actual and prospective customers, investors, employees, and business partners, not to mention the media and senior executives within your organization. Do you really want to frustrate any of these people? What is the value of quickly and easily helping them find the information they need?

If you're producing an intranet, the employees of your organization are the consumers. What is the cost of their time spent to find the information they need? What is the cost when employees don't find the information they need?

Finally, we need to consider the actual costs of designing and implementing the architecture. A well-designed, diplomatic architecture can prevent costly political battles that can stop a project in its tracks. The cost of time spent by high-level executives arguing over which department's information belongs on the main page can skyrocket if you're not careful. A well-designed scaleable architecture can prevent doing it all over a year later. Far too many architectures are crushed under the weight of their own content. Redesign of the information architecture impacts all other aspects of the web site, from graphical navigation bars to the content itself, and it can be a very costly adventure.

Let's illustrate with a real-life example. Recently, we met with about ten members of a large client's web site development team. Because we were in the early stages of the planning process, we had just reviewed the client's likes and dislikes, and were determining their web design philosophy. Now we were ready to begin defining what their site would be.

In discussing the site's likely users, around seven or eight audiences were suggested. Five or six major goals of the site were determined. Finally, we talked about the main areas of content and functionality that the site would include. This wish list included thirty or forty items. We now had a lot of useful lists and ideas, but was the web site ready to be designed yet?

At this point, many site designers would happily dive in head first. Their work would be a site headed by a main page that included thirty or forty items and links, tried to please seven or eight different audiences, and ultimately failed at achieving its five or six goals. This is what happens when the big picture of a site is ignored.

Consider what happens to a site with a single designer who sees only the trees, not the forest. Now add an order of magnitude: large organizations, rife with complex goals and messy politics, often have sites designed by ten individuals with their own vision of the site, their own deadlines and goals to meet, and their own politics to play. Is it any wonder that these sites often work so poorly, even when huge investments of time and money are made in them?

Succinctly, information architecture is about understanding and conveying the big picture of a web site.

Back to our client's committee of ten tree-people. They were still struggling over what the site would ultimately be. Which goals are the most important? Should the site be informational, entertaining, or educational? Should there be one main page for all audiences, or one for each audience? Should we design an architecture that organizes the site's information by topic, by function, or in some other way? Who within their organization should own and maintain the information in the site? What kind of navigation and wording would make the most sense?

Our last meeting ended in frustration, as the committee members argued but never resolved these points. They were especially unhappy, as they'd thought that designing a web site was supposed to be fun, without the haggling over audience definitions, dredging up of organizational politics, and dealing with other unpleasantries that had come up in the discussion. Some even expressed concern that we shouldn't even bother wading into this swamp and instead should start doing something, like gathering together the site's content, pushing forward on the graphic design, and so on.

Having exposed so much frustration, we were obviously on the right track. Why?

Because these thorny and confounding issues of information architecture must be resolved during the design process, before the site is built. If we were to avoid answering these questions and the site's development was to proceed, these issues wouldn't go away. Instead, the burden would be on the site's users to understand how to use and find information in a confusing, poorly-designed web site. Of course, we know that a frustrated user will click and leave with a bad memory of the site, likely to never return. Without a clear information architecture, the site's maintainers wouldn't know where to locate the new information that the site would eventually include; they'd likely begin to quarrel over whose content was more important and deserved visibility on the main page, and so on.