By Peter Morville, Louis Rosenfeld
Book Price: $39.99 USD
£28.50 GBP
PDF Price: $31.99

Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Defining Information Architecture

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We shape our buildings: thereafter they shape us.

—Winston Churchill

What we’ll cover:
What is (and isn’t) information architecture
Why information architecture is important
The value of explaining and illustrating IA concepts

What is it about buildings that stirs 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 facing 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 mazelike airports with misleading signs.

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

A Definition

Content preview·Buy PDF of this chapter|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•tionar•chi•tec•ture n.

1. The structural design of shared information environments.

2. The combination of organization, labeling, search, and navigation systems within web sites and intranets.

3. The art and science of shaping information products and experiences to support usability and findability.

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!

Tablets, Scrolls, Books, and Libraries

Content preview·Buy PDF of this chapter|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 : 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

As we go beyond books to collections of books, the comparisons become even more interesting. Imagine a bookstore with no organization scheme. Thousands of books are simply tossed into huge piles on table tops. Such a bookstore does, in fact, exist: Gould’s Book Arcade in Newtown, Australia. It’s shown in Figure 1-1.

Figure 1-1: Gould’s Book Arcade (image courtesy of Seth Gordon)

From a philosophical perspective, you might feel that this casual jumble of books represents a refreshing break from the rigid structures of everyday life. And this bookstore really can provide a wonderful browsing experience filled with adventure and serendipity. But if you arrive seeking a specific book or if you have a particular author or topic in mind, you’re almost guaranteed to have a long and painful needle-in-the-haystack experience.

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

Explaining IA to Others

Content preview·Buy PDF of this chapter|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 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!

What Isn’t Information Architecture?

Content preview·Buy PDF of this chapter|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.

But wait a second. What about the look and feel of the navigation bar? What about the choice of colors, images, font styles, and sizes? Now we enter the realms of graphic design, interaction design, and information design. And what if a designer challenges the labels proposed by an information architect? Perhaps those labels are too long to fit on the navigation bar. What happens then?

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

Why Information Architecture Matters

Content preview·Buy PDF of this chapter|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’s 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 can’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 redo it six months later because it doesn’t support findability or doesn’t scale?

The cost of maintenance

Similarly, what does it cost to ensure that good designs don’t crumble over time? Will the people who maintain your site know where to put new content and when to remove outdated content?

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

Bringing Our Work to Life

Content preview·Buy PDF of this chapter|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.

Figure 1-5: Information architecture systems

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

Chapter 2: Practicing Information Architecture

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Information architecture is everywhere
Whether the world needs information architects
Qualifications and source disciplines for information architects
Information ecologies and their impact on the practice of information architecture

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 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, bbc.co.uk, or your favorite blogs. Planning a trip? orbitz.com and kayak.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!

Do We Need Information Architects?

Content preview·Buy PDF of this chapter|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 Summits 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 user-experience designers, knowledge managers, or findability engineers, 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 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 already rely on 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!

Who’s Qualified to Practice Information Architecture?

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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

As you look over this list, you might not find your home discipline listed. Don’t be daunted: any field focused on information and its use is a good source of information architects. And the field is still young enough that just about anyone will have to rely on experience from the School of Hard Knocks to practice IA effectively and confidently.

If you’re looking for IA talent, keep in mind that, because the field is relatively new and because demand for information architects continues to explode, 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.

Of course, 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.

OK, on to the list:

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.

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

Information Architecture Specialists

Content preview·Buy PDF of this chapter|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:

• Thesaurus Designer
• Search Schema Content Editor
• Metadata Specialist
• Content Manager
• Information Architecture Strategist
• Manager, Information Architecture
• Director, User Experience

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)

Finally, much IA work is centered on making large-scale applications work as advertised. So many information architects find their specializations centered on a variety of tools, most commonly:

• Content management systems
• Search engines
• Portals

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!

Practicing Information Architecture in the Real World

Content preview·Buy PDF of this chapter|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.

Is this an oversimplified view of reality? Yes. Is it still useful? Absolutely. We’ve been using this model for over 10 years. It’s held up well in all sorts of environments, from global web sites of Fortune 100 corporations to standalone intranet applications within small nonprofits. More importantly, we find these three circles incredibly helpful whenever we’re confronted by a difficult question. After mouthing the trusty phrase “It depends”—as all smart information architects do—we develop our answer by deconstructing the question into three parts that coincide with our three circles. For example, when asked what are the most important qualities that an information architect should have, the answer becomes quite simple: some knowledge of users and their needs (which might come from exposure to human–computer interaction and a variety of other fields), content (think technical communication and journalism), and context (read a book on organizational psychology).

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

What Lies Ahead

Content preview·Buy PDF of this chapter|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, risk takers and people who get things done, 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!

Chapter 3: User Needs and Behaviors

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

What we’ll cover:
The dangers of an oversimplified view of how we find information
How our information needs vary
How our information-seeking behaviors vary
How and why to learn more about determining users’ information needs and information-seeking behaviors

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 some other means. They might really benefit from a site wizard that leads them through a tutorial, or they may wish to wander by browsing through categories.

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

The “Too-Simple” Information Model

Content preview·Buy PDF of this chapter|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, expressed as a simple algorithm:

1. User asks a question.
2. Something happens (i.e., searching or browsing).
3. User receives the answer.
4. 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, they know how to state the question, 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”?

Users often complete their efforts at finding information in a state of partial satisfaction or outright frustration. Example: “I was able to find information on synchronizing my Palm Pilot, but nothing specific on syncing to a Macintosh.” Or, during the process of finding, they may learn new information that changes what they’re looking for altogether. Example: “I realized that a Keough retirement plan is ideal for me, even though when I started I was trying to learn about IRAs.”

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

Information Needs

Content preview·Buy PDF of this chapter|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. The answer, if there is one, is an ambiguous moving target.

So back to the question: What do users want? Let’s use the metaphor 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 29,251, 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, and if it is, that’s good enough. 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 assemblage 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!

Information-Seeking Behaviors

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

How do web site users 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. So, while you may have begun with a broad quest for “guidelines on traveling abroad,” you might be satisfied to find something as specific as “recommended per diem in Timbuktu” by the time you’re done. Each iteration of searching, browsing, asking, and interacting with content can greatly impact what it is we’re seeking.

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

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

Learning About Information Needs and Information-Seeking Behaviors

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

How does one learn about their users’ information needs and seeking behaviors? There are a variety of user research methods to consider—too many to cover in detail here—so we’ll recommend a pair of our favorites: search analytics and contextual inquiry. Search analytics involves reviewing the most common search queries on your site (usually stored in your search engine’s logfiles) as a way to diagnose problems with search performance, metadata, navigation, and content. Search analytics provides a sense of what users commonly seek, and can help inform your understanding of their information needs and seeking behaviors (and is handy in other ways, too, such as developing task-analysis exercises).

While search analytics is based on a high volume of real user data, it doesn’t provide an opportunity to interact with users and learn more about their needs directly. Contextual inquiry, a user research method with roots in ethnography, is a great complement to search analytics because it allows you to observe how users interact with information in their “natural” settings and, in that context, ask them why they’re doing what they’re doing.

Other user research methods you might look to are task analysis, surveys, and, with great care, focus groups. Ultimately, you should consider any method that might expose you to users’ direct statements of their own needs, and when you can, use a combination of methods to cover as many bases as possible.

Finally, remember that, as an information architect, your goal is to do your best to learn about your users’ major information needs and likely information-seeking behaviors. A better understanding of what users actually want from your site will, naturally, help you determine and prioritize which architectural components to build, which makes your job much simpler, especially considering how many ways a particular information architecture could be designed. You’ll also have great user data to help counterbalance the other drivers that too often influence design, such as budget, time, politics, entrenched technologies, and designers’ personal preferences.

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

Chapter 4: The Anatomy of an Information Architecture

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

What we’ll cover:
Why it’s important (and difficult) to make an information architecture as tangible as possible
Examples that help you visualize an information architecture from both the top down and the bottom up
Ways of categorizing the components of an information architecture so you can better understand and explain IA

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 to help you recognize it 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 Chapters 5–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. 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.

Figure 4-1: Gustavus Adolphus College’s main page

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

Visualizing Information Architecture

Content preview·Buy PDF of this chapter|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. 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.

Figure 4-1: Gustavus Adolphus College’s main page

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.

What else? With a careful eye, you can detect aspects of the site’s interaction design, such as the use of mouseovers (over main menu choices) and pull-down menus for “Go Quickly To” and search options. Although the college’s logo and logotype are prominent, the site relies on textual content (e.g., “Excellence,” “Community,” and so forth) to convey its message and brand. And although this particular site functions well, you’d learn something about its supporting technology (and related expertise) just from the main page—for example, if it didn’t load properly in a common browser, you might guess that the designers weren’t aware of or concerned with standards-compliant design.

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

Information Architecture Components

Content preview·Buy PDF of this chapter|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, while (as we saw above) others 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:

Organization systems

The main ways of categorizing or grouping a site’s content (e.g., by topic, by task, by audiences, or by chronology). Also known as taxonomies and hierarchies. Tag clouds (based on user-generated tags) are also a form of organization 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!

Chapter 5: Organization Systems

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The beginning of all understanding is classification.

—Hayden White

What we’ll cover:
Subjectivity, politics, and other reasons why organizing information is so difficult
Exact and ambiguous organization schemes
Hierarchy, hypertext, and relational database structures
Folksonomies, tagging, and social classification

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 design 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!

Challenges of Organizing Information

Content preview·Buy PDF of this chapter|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 blogs? 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