Information Architecture for the World Wide Web

Content preview·Buy reprint rights for this chapter

We shape our buildings: thereafter they shape us.

—Winston Churchill

What is it about buildings that stir us? Whether we're architectural connoisseurs or just plain folks, we are all emotionally engaged by the physical structures we experience throughout our lives.

Each building serves a different purpose. A bustling café with hardwood floors and large windows onto Main Street provides the ideal place for a quick breakfast meeting. A steel-and-glass high rise with its mix of cubes and offices envelops inhabitants in a collaborative, high-energy work environment. A dark, smoky bar with tin ceilings and exposed brick walls becomes a sanctuary from the whirl of modern life. And a medieval Gothic cathedral adorned with granite sculptures, stained glass windows, and towers that reach for the heavens provides an experience both humbling and inspirational.

Each building serves its purpose uniquely. Architecture, design, construction, furnishings, inhabitants, and location all play major roles in shaping the overall experience. All elements must work together. In successful buildings, the whole is greater than the sum of its parts.

Why begin a book about web sites by writing about buildings? Because the architectural analogy is a powerful tool for introducing the complex, multidimensional nature of information spaces. Like buildings, web sites have architectures that cause us to react.

Some web sites provide logical structures that help us find answers and complete tasks. Others lack any intelligible organization and frustrate our attempts to navigate through them. We can't find the product we need; we can't locate the report we found last week; we're lost inside an online shopping cart. These web sites may remind us of buildings that fail: houses with flat roofs that leak, kitchens with no counter space, office towers with windows you can't open, and maze-like airports with misleading signs.

Bad buildings and bad web sites share similar architectural roots. First, many architects don't inhabit the structures they design. They don't fully understand the needs of their customers, and they're not around to suffer the long-term consequences of poor decisions. Second, creating structures to stand the test of time is really difficult. Needs change. Surprises are the rule. The desire for stability must be balanced against the value of flexibility and scalability. Architects are often faced with complex requirements, competing goals, and high levels of ambiguity. Transforming this chaos into order is extremely hard work that requires rare vision and perspective.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If you're new to the field, you may still be wondering: what exactly is information architecture? This section is for you.

in·for·ma·tion ar·chi·tec·ture n.

1. The combination of organization, labeling, and navigation schemes within an information system.

2. The structural design of an information space to facilitate task completion and intuitive access to content.

3. The art and science of structuring and classifying web sites and intranets to help people find and manage information.

4. An emerging discipline and community of practice focused on bringing principles of design and architecture to the digital landscape.

Were you expecting a single definition? Something short and sweet? A few words that succinctly capture the essence and expanse of the field of information architecture? Keep dreaming!

The reason we can't serve up a single, all-powerful, all-purpose definition is a clue to understanding why it's so hard to design good web sites. We're talking about the challenges inherent in language and representation. No document fully and accurately represents the intended meaning of its author. No label or definition totally captures the meaning of a document. And no two readers experience or understand a particular document or definition or label in quite the same way. The relationship between words and meaning is tricky at best.

We'll now descend from our philosophical soapbox and get down to basics. Let's expand on our definitions to explore some basic concepts of information architecture.

Information: We use the term information to distinguish information architecture from data and knowledge management. Data is facts and figures. Relational databases are highly structured and produce specific answers to specific questions. Knowledge is the stuff in people's heads. Knowledge managers develop tools, processes, and incentives to encourage people to share that stuff. Information exists in the messy middle. With information systems, there's often no single "right" answer to a given question. We're concerned with information of all shapes and sizes: web sites, documents, software applications, images, and more. We're also concerned with

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Humans have been structuring, organizing, and labeling information for centuries. Back in 660 B.C., an Assyrian king had his clay tablets organized by subject. In 330 B.C., the Alexandria Library housed a 120-scroll bibliography. In 1873, Melvil Dewey conceived the Dewey Decimal System as a tool to organize and provide access to the growing number of books.

In modern times, most of us become familiar with the basics of information organization through our experiences with books and libraries. Table 1-1 shows how the concepts of information architecture (IA) apply to the world of print and the World Wide Web.

Table 1-1: Differences between books and web sites
IA concept	Books	Web sites
Components	Cover, title, author, chapters, sections, pages, page numbers, table of contents, index.	Main page, navigation bar, links, content pages, sitemap, site index, search.
Dimensions	Two-dimensional pages presented in a linear, sequential order.	Multidimensional information space with hypertextual navigation.
Boundaries	Tangible and finite with a clear beginning and ending.	Fairly intangible with fuzzy borders that "bleed" information into other sites.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

One of the most frustrating things about being an information architect is the fact that most of your family members and neighbors will never have a clue what it is that you do. The more you try to explain it, the more confused or bored they become. Their eyes glaze over. They nod politely. Then comes the desperate attempt to change the subject. "Hey, speaking of information architecture, did you hear tomorrow's weather report?"

Friends and relatives aren't the only tough audience. Sometimes you have to sell the concept to colleagues, clients, or managers. Each audience presents its own set of challenges. There's no magic bullet, but it's helpful to be prepared with an "elevator pitch" and an analogy suited to your particular audience.

The elevator pitch explains what you do in a sentence or two of plain language. If you can combine an analogy that resonates with your audience, even better!

Here are a few approaches to try out:

"I'm an information architect. I organize huge amounts of information on big web sites and intranets so that people can actually find what they're looking for. Think of me as an Internet librarian."
"I'm an information architect. I help my company by making it easy for customers to find our products on our web site. I'm a kind of online merchandiser. I apply one-to-one marketing concepts on the Internet."
"I'm an information architect. I'm the one who takes on that information overload problem that everyone's been complaining about lately."

Sometimes we're too close to what we do. That's when it's a good idea to call for help. Ask someone who's familiar with you and your job to describe what you do in one or two sentences. Often you'll be amazed by how well they nail it, and grateful for their clarity and brevity.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

One of the most effective ways to define something is to identify its boundaries. We do this all the time. This is my property. That's your property. This is England. That's Scotland. She's a brain surgeon. He's an ophthalmologist.

Sometimes it's very easy to explain the differences. Mammals breathe with their lungs and give birth to live young. Dogs, cats, dolphins, and humans are all clearly mammals. Fish live in water, breathe with their gills, and lay eggs. Salmon, bass, and guppies are all clearly fish.

But as with many classifications, you quickly run into problems. What about fish with lungs? What about fish that don't look like fish? Are sharks, skates, eels, and sea horses really fish? (Yes, they are.) And where do we put that darned platypus? Biological taxonomists have argued about these classification issues for centuries.

Mapping the boundaries of information architecture is even more slippery. Some things are clearly not information architecture:

Graphic design is NOT information architecture.
Software development is NOT information architecture.
Usability engineering is NOT information architecture.

Makes sense, right? But as soon as you start working within the messy reality of web site design and construction, you find yourself in the gray areas between disciplines. For example, consider the ubiquitous global navigation bars in Figure 1-3.

Figure 1-3: Top and bottom navigation bars on the United Nations web site

The navigation bars feature labels and links that lead to other sections and pages within the web site. These labels are dependent upon the underlying structure and categorization of the site. The creation of categories and choice of labels fall clearly inside the domain of information architecture.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You now understand what information architecture is and what it isn't. So, why is it important? Why should you care? Why should your company or your clients invest time and money in the design of their information architectures? What is the return on investment (ROI)?

We'll tackle these tough questions in detail later in the book, but for now let us hit the highlights without getting bogged down in subtleties. When you calculate the importance of information architecture to your organization, you should consider the following costs and value propositions:

The cost of finding information: What does it cost if every employee in your company spends an extra five minutes per day struggling to find answers on your intranet? What is the cost of frustrating your customers with a poorly organized web site?
The cost of not finding information: How many bad decisions are made every day in your organization because employees didn't find the information they needed? How much duplication of effort results from this disconnect? How many customers do you lose because they couldn't find the product they want on your web site? How much do you spend every day providing telephone support to existing customers because they hate navigating your online technical support database?
The value of education: What is the value of educating your customers about new products and services related to the ones they're actively seeking on your web site?
The cost of construction: What does it cost to design and build a web site? How much does it cost to do it again six months later because it doesn't support findability or doesn't scale?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Information architecture lives beneath the surface. Users rarely look at a web site and exclaim, "Wow, check out this brilliant classification scheme!" In fact, much of our work is intangible; many people who are directly involved in web design have only a superficial understanding of information architecture. They may recognize the need for clear labels in a navigation bar, but have no clue how a controlled vocabulary could improve the search experience. If you can't see it, touch it, taste it, or smell it, it doesn't exist.

This invisibility is fine with respect to users. We don't want to force users to see our hard work; we want them to complete tasks and find information in blissful ignorance of our labors. But invisibility is a major problem when it comes to justifying our existence to colleagues and making the case for investments to decision makers. We must constantly work to help people see the complexity of the challenges we face and the long-term value of our solutions.

We must find ways to articulate the key concepts of our craft, helping people to understand the sophisticated nature of user needs and behavior. We must show the interconnections between people and content that underpin knowledge networks, and explain how these concepts can be applied to transform static web sites into complex adaptive systems (Figure 1-4 ).

Figure 1-4: Information architecture concepts

We must be prepared to dive into detail, identifying and defining the component systems that support our sites (Figure 1-5). We must show how semantic networks can provide a foundation for fluid navigation. And we must convince our clients and colleagues that an effective searching experience requires not just a good engine or a nice interface, but a carefully integrated system of interdependent parts.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

What is information architecture? Is it an art, a science, or a craft? Who should do this work? What qualifications are required? These are the philosophical questions we grapple with as a community of information architects. We write articles and publish books. We debate on discussion lists and argue passionately at conferences. We pull out our hair. We lose sleep. This is serious stuff.

And yet, independent of our intellectual theories and existential agonies, something very powerful is taking place. We are being surrounded, quite literally, by information architecture.

Have you ever walked through Times Square in New York City at night? It's quite a spectacle. You're on the corner of 42nd and Broadway. The glassy facades of buildings are pulsing with real-time information, courtesy of the latest in flat-panel display and projection technologies. Business news, financial data, corporate logos, and URLs are lit up in neon. Taxicabs sport billboards on their roofs as they honk their way through traffic. Pedestrians (or shall we say "users") hustle past one another, chattering into their cell phones or stopping on the corner to check email or get directions on their wireless PDAs. This is William Gibson's cyberspace turned inside out, physical architecture meets information architecture, a world of content, labels, and metadata all competing for your attention.

And that's nothing compared to the real cyberspace, a new reality where we spend increasing amounts of time. How many hours do you spend staring at a computer monitor each day? How often do you check email or pop open your web browser? When your Internet connection is broken, how do you feel?

The World Wide Web has lived up to its name. It has connected and transformed the world. Want to know what's going on? Check out nytimes.com. Planning a trip? Travelocity.com will meet your every need. Having trouble with your green iguana? No need to leave the house. You'll find the answer at iguana.com.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Since information architecture happens anyway, does the world really need information architects? If you've attended any of the IA conferences in recent years, you know this has been a hot topic. A few speakers in particular have stirred the pot. Andrew Dillon is fond of saying, "I know we need information architecture. I'm not so sure we need information architects." And Peter Merholz suggests that "we need to teach everyone to do information architecture, rather than isolating the practice to a handful of professionals."

We have to give credit to the information architecture community for having the guts to ask these questions in public. But we'd like to respond with a firm assertion that we absolutely do need information architects. We're not too particular about the specific job title; if you prefer to call them findability engineers or structural designers, that's fine with us. What we're focused on is the need for professionals with specialized skills and experience, who know how to create useful, usable information systems within massively complex environments.

Programmers and graphic designers are great at what they do. They're not great at what we do. And information architecture design is not a skill you can pick up by taking a half-day seminar. There's real depth to the discipline. Information architecture resembles the games of chess, Othello, and Go. A minute to learn, a lifetime to master.

Does this mean that all web developers will need a licensed information architect on board before they write their first line of code? Of course not. Information architecture happens, with or without information architects, and that's just fine with us. That's why Peter Merholz is right to emphasize the vital role information architects must play in education. We can have a major positive impact on the world by sharing what we know with all those people who do information architecture in the course of doing something else.

But the most important and complex information environments will call for professional information architects. Large organizations like IBM, Microsoft, and Vanguard already have teams of information architects dedicated to the long-term strategy and design of their web sites and intranets. Smaller organizations tend to involve information architects in a consulting capacity during a site redesign. This allows the information architect to make a major contribution without breaking the bank.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Unlike medicine and law, the field of information architecture has no official certification process. There are no universities or boards or exams that can prevent you from practicing information architecture. As we explain in Chapter 13, a number of university programs are emerging to serve the needs of prospective information architects, but for now very few people have a degree in information architecture.

Because the field is so new, you can't just post a job description and expect a flock of competent and experienced candidates to show up on your doorstep. Instead, you'll need to actively recruit, outsource, or perhaps become the information architect for your organization. If you are looking for someone else to fill this role, you might consider the following disciplines as sources for information architects. If you're on your own, it might not be a bad thing to learn a little bit about each of these disciplines yourself. In either case, remember that no single discipline is the obvious source for information architects. Each presents its own strengths and weaknesses.

Graphic design and information design: Many of the people who have written about and practice information architecture are graphic designers by training. This is not surprising, as both graphic design and information design involve much more than creating pretty pictures. These professions are geared more toward creating relationships between visual elements and determining how those elements can be integrated as a whole to communicate more effectively.
Information and library science: We've found that our backgrounds in information science and librarianship have proven very useful in dealing with the relationships between pages and other elements that make up a whole site. Librarians have a long history of organizing and providing access to information and are trained to work with searching, browsing, and indexing technologies. Forward-looking librarians (sometimes described as "cybrarians") see that their expertise applies in new arenas far beyond the library walls.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

These general discussions about the role, value, and qualifications of information architects are worthwhile but incomplete. The community of information architects is experiencing what evolutionary biologists call a period of "punctuated equilibrium" marked by rapid change and specialization.

Particularly in large organizations, people who began as all-purpose information architects are gravitating towards specialized niches that match their strengths to their organization's needs. Here are just a few of the titles that already exist today:

Thesaurus Designer
Search Schema Content Editor
Metadata Specialist
Information Architecture Strategist
Vice President, Information Architecture

There are so many possible variations and so many different facets. For example, information architects can specialize by:

Industry lines (e.g., financial services, automotive)
Functional department (e.g., human resources, engineering, marketing)
Type of system (e.g., intranets, web sites, extranets, online magazines, digital libraries, software, online communities)
Audience (e.g., small business owners, elementary school teachers, rocket scientists, teenagers, grandparents)

As our use of networked information environments grows, the possibilities for specialization are unlimited and unpredictable. We're watching evolution in fast-forward. This is part of what makes it so much fun to be part of the information architecture community.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Users. Content. Context. You'll hear these three words again and again throughout this book. They form the basis of our model for practicing effective information architecture design. Underlying this model is a recognition that you can't design useful information architectures in a vacuum. An architect can't huddle in a dark room with a bunch of content, organize it, and emerge with a grand solution. It simply won't hold up against the light of day.

Web sites and intranets are not lifeless, static constructs. Rather, there is a dynamic, organic nature to both the information systems and the broader environments in which they exist. This is not the old world of yellowing cards in a library card catalog. We're talking complex, adaptive systems with emergent qualities. We're talking rich streams of information flowing within and beyond the borders of departments, business units, institutions, and countries. We're talking messiness and mistakes, trial and error, survival of the fittest.

We use the concept of an "information ecology" composed of users, content, and context to address the complex dependencies that exist. And we draw upon our trusty Venn diagram (see Figure 2-2) to help people visualize and understand these relationships. The three circles illustrate the interdependent nature of users, content, and context within a complex, adaptive information ecology.

Figure 2-2: The infamous three circles of information architecture

In short, we need to understand the business goals behind the web site and the resources available for design and implementation. We need to be aware of the nature and volume of content that exists today and how that might change a year from now. And we must learn about the needs and information seeking behaviors of our major audiences. Good information architecture design is informed by all three areas.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If there's one thing that many years of information architecture consulting has taught us, it's that every situation is unique. We don't just mean that web sites are different from intranets or that extranets should vary by industry. We mean that, like fingerprints and snowflakes, every information ecology is unique.

The DaimlerChrysler intranet is vastly different from that of Ford or GM. Fidelity, Vanguard, Schwab, and Etrade have each created unique online financial service experiences. Despite all the copycatting, benchmarking, and definition of industry best practices that have surged throughout the business world in recent years, each of these information systems has emerged as quite distinctive.

That's where our model comes in handy. It's an excellent tool for learning about the specific needs and opportunities presented by a particular web site or intranet. Let's take a look at how each of our three circles contribute to the emergence of a totally unique information ecology.

All web sites and intranets exist within a particular business or organizational context. Whether explicit or implicit, each organization has a mission, goals, strategy, staff, processes and procedures, physical and technology infrastructure, budget and culture. This collective mix of capabilities, aspirations, and resources is unique to each organization.

Does it then follow that the information architecture of each organization must be unique? After all, companies buy generic office furniture. They invest in standard technology platforms. They even outsource important activities to vendors that service their competitors.

Still, the answer is a resounding yes. Information architectures must be uniquely matched to their context. The vocabulary and structure of your web site and your intranet is becoming a major component of the evolving conversation your business has with your customers and employees. It influences how they think about your products and services. It tells them what to expect from you in the future. It invites or limits interaction between customers and employees. Your information architecture provides perhaps the most tangible snapshot of your organization's mission, vision, values, strategy, and culture. Do you really want that snapshot to look like that of your competitor?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

So, information architecture happens. Information architectures are being created every day by generalists and specialists, by innies and outies, and by people who've never heard the term "information architecture." They're being created inside all manner of information ecologies with unique combinations of users, content, and context.

Herein lies the dual challenge to the information architecture discipline. As professionals, we must advance our own understanding and our ability to perform this very difficult work inside massively complex environments. We still have so much to learn! And as a community, we must strive to advance the practice of information architecture by educating those around us who create or influence information architectures while they're focused on doing something else. We still have so much to teach!

In any case, we hope we've done a good job of setting the stage. Now it's time to delve into the guts of information architecture, so roll up your sleeves and dig in.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In the last two chapters, we've defined information architecture and placed it within the broader context of where, when, and by whom it's practiced. But before we jump into the actual "stuff" of information architecture—the components that make up an architecture, the methodologies that drive its design, and so on—let's first take a look at users. Information architecture is not restricted to taxonomies, search engines, and the other things that help users find information on a site. Information architecture starts with users and the reason they come to a site in the first place: they have an information need.

This is a truism, but there's more to it than meets the eye. Information needs can vary widely, and each type of information need causes users to exhibit specific information seeking behaviors. Information architects need to understand those needs and behaviors, and their designs should correspond accordingly. There is no goal more important to designing information architecture than to satisfy users' needs.

For example, if your site is a staff directory, looking up a staff member's phone number is probably a very common information need among your site's users; in fact, this type of need may describe most of your users' finding sessions. When confronted by such a need, users will likely perform a search, and you'd be wise to make sure your information architecture supports searching by name. On the other hand, if your site helps non-savvy investors learn about and select mutual funds for investment, your users may satisfy this need through browsing. They might really benefit from a site wizard that leads them through a tutorial, or they may wish to wander by browsing through categories.

Seeking something you know is there, like your colleague's phone number, is quite a different information need than learning about a topic, like small-cap mutual funds, and your site's information architecture should be designed with those differences in mind. Similarly, searching is a very different behavior than browsing. Distinguishing between these needs and behaviors and determining which are your users' highest priorities is an extremely valuable pursuit—it helps you determine where to invest your efforts, resources, time, and money as you design your architecture.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

There are different models of what happens when users look for information. Modeling users' needs and behaviors forces us to ask useful questions about what kind of information the user wants, how much information is enough, and how the user actually interacts with the architecture.

Unfortunately, "too-simple" is the most common information model, and it's also the most problematic. It looks something like Figure 3-1.

Figure 3-1: The "too-simple" model of information needs

Or, put as a simple algorithm:

User asks a question.
Something happens (i.e., searching or browsing).
User receives the answer.
Fin.

Input, output, end of story. This is a very mechanistic and ultimately dehumanizing model for how users find and use information on web sites. In fact, in this model, the user, like the site itself, is just another system, predictable in behavior, rational in motivation.

Why do we have a problem with this "too-simple" model? Because it rarely happens this way. There are exceptions—for example, when users know what they're looking for, as in the staff directory scenario. Here, users have a question for which there is a right answer, they know where to find the answer, and they know how to use the site to do so.

But users don't always know exactly what they want. Have you ever visited a site just to poke around? By exploring the site, you're trying to find information of a sort; you just don't exactly know what you're looking for. Even when you do, you may not have the language to express it: is it "PDA," "Palm Pilot," or "handheld computer"?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

When a user comes to a web site to find something, what does she really want? In the "too-simple" model, she wants the "right answer" to her question. Indeed, right answers do come from searching databases, which store facts and figures and answer questions that really do have right answers, such as "What is the population of San Marino?" To many of us, database searching is the most familiar model of searching.

But web sites store much more than highly structured data. Not surprisingly, text is the most common type of data stored, and text itself is made up of ambiguous, messy ideas and concepts. When we go to a web site for advice on retirement investing, to learn about restaurants in Mendocino County, or to find out what's happening with the Manchester United football team, we are essentially looking for ideas and concepts that inform us and help us make decisions. This is very different from simply seeking the "right" answer.

So back to the question: What do users want? Let's use the analogy of fishing to get at the answer.

The Perfect Catch: Sometimes users really are looking for the right answer. Let's think of that as fishing with a pole, hoping to hook that ideal fish. What is the population of San Marino? You go to the CIA Fact Book or some other useful site that's jam-packed with data, and you hook in that number (it's 27,336, by the way). And you're done, just as the too-simple model would have it.
Lobster Trapping: What about the times you're looking for more than just a single answer? Let's say you're hoping to find out about good bed-and-breakfast inns in Stratford, Ontario. Or you want to learn something about Lewis and Clark's journey of exploration. Or you need to get a sense of what sort of financial plans can help you save for retirement. You don't really know much about what you're looking for, and aren't ready to commit to retrieving anything more than just a few useful items, or suggestions of where to learn more. You're not hoping to hook the perfect fish, because you wouldn't know it if you caught it. Instead, you're setting out the equivalent of a lobster trap—you hope that whatever ambles in will be useful. Perhaps it's a few candidate restaurants that you'll investigate further by calling and checking their availability and features. Or maybe it's a motley collection of Lewis and Clark stuff, ranging from book reviews to a digital version of Clark's diary to information about Lewis & Clark college in Oregon. You might be happy with a few of these items, and toss out the rest.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

What do users do to find information? They enter queries in search systems, browse from link to link, and ask humans for help (through email, chat interfaces, and so forth). Searching, browsing, and asking are all methods for finding, and are the basic building blocks of information seeking behavior.

There are two other major aspects to seeking behaviors: integration and iteration. We often integrate searching, browsing, and asking in the same finding session. Figure 3-3 shows how you might search your corporate intranet for guidelines on traveling abroad. You might first browse your way through the intranet portal to the HR site, browse the policies area, and then search for the policy that includes the string "international travel". If you still didn't get your question answered, you might send an email to Biff, the person responsible for that policy, to ask exactly what your per diem will be while spending the week in Timbuktu. Let's hope your intranet's information architecture was designed to support such integration!

Figure 3-3: Integrated browsing, searching, and asking over many iterations

Figure 3-3 also illustrates the iteration you may go through during one finding session. After all, we don't always get things right the first time. And our information needs may change along the way, causing us to try new approaches with each new iteration.

These different components of information seeking behaviors come together in complex models, such as the "berry-picking" model developed by Dr. Marcia Bates of the University of Southern California. In this model (shown in Figure 3-4), users start with an information need, formulate an information request (a query), and then move iteratively through an information system along potentially complex paths, picking bits of information ("berries") along the way. In the process, they modify their information requests as they learn more about what they need and what information is available from the system.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In the preceding chapters, we discussed information architecture from a conceptual perspective. This chapter presents a more concrete view of what information architecture actually is, which should help you to recognize information architecture when you see it. We also introduce the components of an architecture; these are important to understand because they make up the information architect's palette. We'll cover them in greater detail in Chapter 5 through Chapter 9.

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.

All information architects are salespeople to some degree. As it's highly probable that you'll need to explain information architecture to important people, such as colleagues, managers, prospects, and clients, it's in your interests to be able to actually show them what information architecture is.

Let's start by looking at a site's main page. Figure 4-1 shows the main page for Dartmouth College in Hanover, NH, USA.

Figure 4-1: Dartmouth College's main page

What's obvious here? Most immediately, you see that aspects of the site's visual design stand out. You can't help but notice the site's colors (you'll have to take our word for it), font styles, and image selection. You also notice aspects of the site's information design; for example, it is laid out in three columns and uses icons for such main options as "home," "index," "help," and "search."

What else? With a careful eye you can detect aspects of the site's interaction design, such as the use of linked images for such category labels as "About Dartmouth" and "Teaching & Research," and the use of a pull-down menu for "quick links." The site's content is prominent, and communicates something about the organization behind the site—the activities going on there, as well as the resources it makes available via the Web. Finally, you might learn something about the technology (and related expertise) that went into this site from the main page—especially if the page loads very slowly or is full of broken images and links.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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.

All information architects are salespeople to some degree. As it's highly probable that you'll need to explain information architecture to important people, such as colleagues, managers, prospects, and clients, it's in your interests to be able to actually show them what information architecture is.

Let's start by looking at a site's main page. Figure 4-1 shows the main page for Dartmouth College in Hanover, NH, USA.

Figure 4-1: Dartmouth College's main page

What's obvious here? Most immediately, you see that aspects of the site's visual design stand out. You can't help but notice the site's colors (you'll have to take our word for it), font styles, and image selection. You also notice aspects of the site's information design; for example, it is laid out in three columns and uses icons for such main options as "home," "index," "help," and "search."

What else? With a careful eye you can detect aspects of the site's interaction design, such as the use of linked images for such category labels as "About Dartmouth" and "Teaching & Research," and the use of a pull-down menu for "quick links." The site's content is prominent, and communicates something about the organization behind the site—the activities going on there, as well as the resources it makes available via the Web. Finally, you might learn something about the technology (and related expertise) that went into this site from the main page—especially if the page loads very slowly or is full of broken images and links.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

It can be difficult to know exactly what components make up an information architecture. Users interact directly with some components, while other components are so behind the scenes that users are unaware of their existence.

In the next four chapters, we'll present and discuss information architecture components by breaking them up into the following four categories:

Organization Systems: How we categorize information, e.g., by subject or chronology. See Chapter 5.
Labeling Systems: How we represent information, e.g., scientific terminology ("Acer") or lay terminology ("maple"). See Chapter 6.
Navigation Systems: How we browse or move through information, e.g., clicking through a hierarchy. See Chapter 7.
Searching Systems: How we search information, e.g., executing a search query against an index. See Chapter 8.

Like any categorization scheme, this one has its problems. For example, it can be difficult to distinguish organization systems from labeling systems (hint: you organize content into groups, and then label those groups; each group can be labeled in different ways) . In such situations, it can be useful to group objects in new ways. So before we delve into these systems, we'll present an alternative method of categorizing information architecture components. This method is comprised of browsing aids, search aids, content and tasks, and "invisible" components.

These components present users with a predetermined set of paths to help them navigate the site. Users don't articulate their queries, but instead find their way through menus and links. Types of browsing aids include:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The beginning of all understanding is classification.

—Hayden White

Our understanding of the world is largely determined by our ability to organize information. Where do you live? What do you do? Who are you? Our answers reveal the systems of classification that form the very foundations of our understanding. We live in towns within states within countries. We work in departments in companies in industries. We are parents, children, and siblings, each an integral part of a family tree.

We organize to understand, to explain, and to control. Our classification systems inherently reflect social and political perspectives and objectives. We live in the first world. They live in the third world. She is a freedom fighter. He is a terrorist. The way we organize, label, and relate information influences the way people comprehend that information.

As information architects, we organize information so that people can find the right answers to their questions. We strive to support casual browsing and directed searching. Our aim is to apply organization and labeling systems that make sense to users.

The Web provides information architects with a wonderfully flexible environment in which to organize. We can apply multiple organization systems to the same content and escape the physical limitations of the print world. So why are many large web sites so difficult to navigate? Why can't the people who design these sites make it easy to find information? These common questions focus attention on the very real challenge of organizing information.

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?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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?

Believe it or not, we're all becoming librarians. This quiet yet powerful revolution is driven by the decentralizing force of the global Internet. Not long ago, the responsibility for labeling, organizing, and providing access to information fell squarely in the laps of librarians. These librarians spoke in strange languages about Dewey Decimal Classification and the Anglo-American Cataloging Rules. They classified, cataloged, and helped you find the information you needed.

As it grows, the Internet is forcing the responsibility for organizing information on more of us each day. How many corporate web sites exist today? How many personal home pages? What about tomorrow? As the Internet provides users with the freedom to publish information, it quietly burdens them with the responsibility to organize that information. New information technologies open the floodgates for exponential content growth, which creates a need for innovation in content organization (see Figure 5-1).

Figure 5-1: Content growth drives innovation

And if you're not convinced that we're facing severe information-overload challenges, take a look at an excellent study conducted at Berkeley. This study finds that the world produces between 1 and 2 exabytes of unique information per year. Given that an exabyte is a billion gigabytes (we're talking 18 zeros), this growing mountain of information should keep us all busy for a while.

As we struggle to meet these challenges, we unknowingly adopt the language of librarians. How should we

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The organization of information in web sites and intranets is a major factor in determining success, and yet many web development teams lack the understanding necessary to do the job well. Our goal in this chapter is to provide a foundation for tackling even the most challenging information organization projects.

Organization systems are composed of organization schemes and organization structures. An organization scheme defines the shared characteristics of content items and influences the logical grouping of those items. An organization structure defines the types of relationships between content items and groups.

Before diving in, it's important to understand information organization in the context of web site development. Organization is closely related to navigation, labeling, and indexing. The hierarchical organization structures of web sites often play the part of primary navigation system. The labels of categories play a significant role in defining the contents of those categories. Manual indexing or metadata tagging is ultimately a tool for organizing content items into groups at a very detailed level. Despite these closely knit relationships, it is both possible and useful to isolate the design of organization systems, which will form the foundation for navigation and labeling systems. By focusing solely on the logical grouping of information, you avoid the distractions of implementation details and can design a better web site.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

We navigate through organization schemes every day. Telephone books, supermarkets, and television programming guides all use organization schemes to facilitate access. Some schemes are easy to use. We rarely have difficulty finding a friend's phone number in the alphabetical organization scheme of the white pages. Some schemes are intensely frustrating. Trying to find marshmallows or popcorn in a large and unfamiliar supermarket can drive us crazy. Are marshmallows in the snack aisle, the baking ingredients section, both, or neither?

In fact, the organization schemes of the phone book and the supermarket are fundamentally different. The alphabetical organization scheme of the phone book's white pages is exact. The hybrid topical/task-oriented organization scheme of the supermarket is ambiguous.

Let's start with the easy ones. Exact organization schemes divide information into well-defined and mutually exclusive sections. The alphabetical organization of the phone book's white pages is a perfect example. If you know the last name of the person you are looking for, navigating the scheme is easy. "Porter" is in the P's which is after the O's but before the Q's. This is called known-item searching. You know what you're looking for, and it's obvious where to find it. No ambiguity is involved. The problem with exact organization schemes is that they require the user to know the specific name of the resource they are looking for. The white pages don't work very well if you're looking for a plumber.

Exact organization schemes are relatively easy to design and maintain because there is little intellectual work involved in assigning items to categories. They are also easy to use. The following sections explore three frequently used exact organization schemes.

Section 5.3.1.1: Alphabetical

An alphabetical organization scheme is the primary organization scheme for encyclopedias and dictionaries. Almost all nonfiction books, including this one, provide an alphabetical index. Phone books, department store directories, bookstores, and libraries all make use of our 26-letter alphabet for organizing their contents. Alphabetical organization often serves as an umbrella for other organization schemes. We see information organized alphabetically by last name, by product or service, by department, and by format. Figure 5-2 provides an example of a departmental directory organized alphabetically by last name.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Organization structure plays an intangible yet very important role in the design of web sites. While we interact with organization structures every day, we rarely think about them. Movies are linear in their physical structure. We experience them frame by frame from beginning to end. However, the plots themselves may be nonlinear, employing flashbacks and parallel subplots. Maps have a spatial structure. Items are placed according to physical proximity, although the most useful maps cheat, sacrificing accuracy for clarity.

The structure of information defines the primary ways in which users can navigate. Major organization structures that apply to web site and intranet architectures include the hierarchy, the database-oriented model, and hypertext. Each organization structure possesses unique strengths and weaknesses. In some cases, it makes sense to use one or the other. In many cases, it makes sense to use all three in a complementary manner.

The foundation of almost all good information architectures is a well-designed hierarchy or taxonomy. In this hypertextual world of nets and webs, such a statement may seem blasphemous, but it's true. The mutually exclusive subdivisions and parent-child relationships of hierarchies are simple and familiar. We have organized information into hierarchies since the beginning of time. Family trees are hierarchical. Our division of life on earth into kingdoms and classes and species is hierarchical. Organization charts are usually hierarchical. We divide books into chapters into sections into paragraphs into sentences into words into letters. Hierarchy is ubiquitous in our lives and informs our understanding of the world in a profound and meaningful way. Because of this pervasiveness of hierarchy, users can easily and quickly understand web sites that use hierarchical organization models. They are able to develop a mental model of the site's structure and their location within that structure. This provides context that helps users feel comfortable. Figure 5-11 shows an example of a simple hierarchical model.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole th

Table of Contents

Section 5.3.1.1: Alphabetical