In Chapter 3 through Chapter 6, we covered the basic principles of information architecture and illustrated those principles with examples and practical advice. Chapter 7 through Chapter 9 explained the role of both information architecture and architect in context of a web site's development and described the architect's tools and deliverables.
This chapter provides you with a case study that illustrates how an information architecture can solve some of the most common and irritating problems faced by web designers and developers. The architecture described here is not a silver bullet; it certainly doesn't work for all possible types of sites. Use this chapter instead to get a sense of the decision making that goes into creating an information architecture that fulfills specific needs.
10.1 Archipelagoes of Information
As do most of his books, James Michener's Hawaii starts at the dawn of time. He describes how the lovely Hawaiian archipelago grows over millions of years from humble, organic beginnings, each island birthing and dying in explosions of lava emanating from beneath the Earth's crust.
Large, complex web sites and intranets have similarly organic beginnings. These sites are loosely connected archipelagoes of information, starting slowly with one island, coming from sources often unseen, exploding with change and growth, out of control. It often goes like this: someone in the MIS department gets a web server, sets it up, builds a small, experimental web site, and starts having fun. Other early adopters check out this unofficial site and get ideas of their own. The MIS boss finds out and, horrified by his or her lack of control over the situation, forces the free-thinker to terminate the maverick site, while enlisting someone from Graphics to help start up the official intranet. The MIS boss later learns (to her dismay) that the pesky Marketing Department has already decided to contract their advertising firm to build an external site, and the Human Resources people aren't far behind. And there are rumors that both the Hong Kong and Hoboken divisions are setting up their own sites....
Sites that grow this way within an organization are really a collection of sub-sites. Their complexity runs deeper than you may think. Indeed, the biggest challenge is often the degree to which organizational politics intrude into the process. This isn't surprising if we consider the differences between the ways modern corporations and the World Wide Web work.
Corporations and other large organizations are traditionally modeled hierarchically, structured as single entities with clear chains of command. The power of a corporation lies in its ability to leverage the sum of its independently working parts while laboring to keep those parts from completely splitting apart. The Web, on the other hand, goes completely against the grain of centralization, serving instead as an agent of
organizational chaos. Because web sites are cheap and easy to create, corporations have a difficult time controlling them.
As some poor souls try to bring all these separate efforts together under the venue of a single corporate web site or intranet, the politics can get especially ugly. Marketing wants links to its news releases to go on the main page. Human Resources is convinced that most of the users are going to be employees, and wants the employee handbook front and center. And MIS's content already blankets the main page. Meanwhile the Information Center has trashed the look and feel of the site because they don't have the budget to pay for professional graphic design. Have we left anyone out?
Oh, yes. The user.
The user, as we know, doesn't care about organizational politics. The user wants information to be made accessible the way he or she thinks, not the way the corporation thinks. Instead, the user is often confronted with corporate jargon and organization schemes based on corporate organization charts, and the site's value to users and to the sponsoring organization plummet.
Unfortunately, this is a common situation. Fortunately, the principles of information architecture can address and solve many of these problems.
10.2 A Case Study: Henry Ford Health System
The Henry Ford Health System (HFHS) is one of the largest health care providers in Michigan, with over 17,000 employees and almost $2 billion in annual revenues. They approached Argus and its strategic partners, Q LTD (which provides graphic design and editorial services) and InterConnect of Ann Arbor (which provides programming and technical design consulting) to create an external corporate web site from scratch. Needless to say, we were delighted to take on the project. We also realized that we would need to avoid the usual problems of main page crowding, political jockeying, poor navigation, and inconsistent look and feel that were abundant in many other health care organizations' sites. Although the HFHS internal Internet committee was very sensitive to these problems, we all faced a huge challenge of creating a useful, user- centered site for such a large corporation.
10.2.1 Org Chart as Default Architecture
We began with the assumption that we could not force the 90 or so HFHS hospitals, medical centers, departments, units, and programs to halt their own web development efforts and comply with the look and feel of the site we were about to create. In fact, it would be better to accept the reality that sites grow organically within an organization, and build a strong umbrella site around these local islands of corporate information. So, we began visualizing an architecture that looked like the one in Figure 10.1.
Figure 10.1. The Org Chart architecture. It obviously won't scale well for most large organizations. Imagine a main page with links to 90 sub-sites... on second thought, we're sure you've seen quite
page 145
Each sub-site represented an organizational entity : a department, unit, division, medical center, hospital, or program sponsored by HFHS. We learned from our initial research that many of these entities did not yet have their own sub-sites, although they would over time. Some entities might never create their own sub- sites. So the reality of their web environment really looked a bit more like Figure 10.2.The organization scheme at this point very closely mirrored the political boundaries of the HFHS org chart. Users might come to the main page of such a site and find prominent links to the Department of Gynecology next to the Office of the President. Also, as HFHS is a large organization, there would be many more links than the five represented here. So how could we leave these default organic partitions of information in place, and yet provide a more usable, user-centered view? We had to find a way to cut across the grain of the org chart, yet leave it in place (see Figure 10.3).
Figure 10.3. Unless we come up with a better solution, the site will be organized like an "org chart" (the horizontal dotted lines). Can we cut "across the grain" of the org chart (the vertical