Information Architecture

The most abstract level on which people experience a Web site is the information architecture. All information that's created by people has some underlying structure, and there is always some organizational idea that defines how all the information in a given work fits together. Often that structure is quite explicit, as in the case of the phone book, the Library of Congress, or the Yahoo! hierarchy. In these cases, there's little question about how information is arranged.

Sometimes, however, the creator's unifying idea is less easy to see; it's implicit. When an architecture is implicit, it's hidden behind an analogy to another organizational structure, a metaphor that maps one kind of information to another. The person trying to navigate it has to navigate the "real" information structure using the metaphor. An implicit architecture sometimes makes things clearer, and sometimes it confuses things further. The desktop metaphor of the Macintosh and Windows clarifies and organizes a lot of concepts about files and their manipulation, whereas the geography metaphor of Yahoo!'s Geocities Web hosting service has little connection to the content found there. With the Macintosh, visually moving file icons from one "folder" to another requires less labor and information about the system than, say, file manipulations in DOS, which require typing and an understanding of the layout of the whole file system. In Geocities, however, the geography metaphor is both dependent on cultural queues ("Silicon Valley" communicates little about the information a section named that contains) and breaks down if taken literally. Santa Clara and Mountain View are both cities in the real Silicon Valley—if Geocities had sections called that in their Silicon Valley, what would they communicate about the kind of content that's in those sections? Very little. Yahoo!, in fact, recognized this and abandoned the geographical metaphor long ago in favor of a more explicit organizational structure; now there's no Silicon Valley; instead, there's Computers & Internet.

Whether it's explicit or implicit, there's always some structure to the information, but often the people making the structure may not even realize that they're building an information architecture. Their way of organizing may be so deeply buried in their knowledge of a certain subject or understanding of a certain task that they can't imagine any other way to think about it. For example, a corporate information site organized using the company's org chart is using an architecture that may seem reasonable and explicit to the creator of the site, but from the users' perspective may be unrelated to how they need to see the company. A user looking for support information in such a site may not care that the technical support staff can be found in the operations unit of the North American subsidiary of a Taiwanese company; he has a question about a product he bought and—from his perspective—all this other information is completely unrelated to either asking or answering his question.

Information Architects

It's the information architect's job to make the implicit architecture explicit so that it matches what the users need, expect, and understand. The architect makes it possible for the users to navigate through the information and comprehend what they see. The ultimate goal is for the audience to be able to predict what's going to happen around the next corner, even if they've never been there, and be able to get from point A to point B without getting lost.

When the underlying model isn't obvious, people create one. Humans are always looking for patterns in data, things that can be used to simplify our interaction with the world, make it more understandable. Even when we don't know what to call it or we can't articulate it, we still create an image or a pattern or a story to understand the information space we're in. People always think they've found a pattern in the stock market or a roulette wheel when the vast majority of the time no pattern exists. Thus, although there may not be a specific information architect position in a development team, there is always someone who is creating a pattern in the information. Someone is playing the role of information architect though he or she may not know it yet.

Information Needs of Information Architects

Information architecture frequently happens (or should happen) at the beginning of the development process, and the kinds of research that inform it are fundamental. Specifically, it's information about who the audience is, how they think about the task, what words they use, and whether the existing information architecture makes sense to them.

Note

Many of these needs overlap with interaction and identity designers, and much of the research described in the next section is equally useful to them. In the interest of presenting the techniques in roughly the order they appear in development, I'm introducing several things as information architecture concerns when they're really concerns that under-lie the whole product, no matter which aspect is being examined or designed.

Knowing exactly who is going to be using the product is often a critical part of creating an information architecture. Different groups of people have different contexts with which to understand information that's being presented to them and different assumptions about how to use that information. The more finely a target audience is described, the more accurately the information architect can make the Web site work as they think. The fundamental way to measure any community is through its demographics, which describe their physical and employment characteristics. Typical demographic characteristics include age, education level, income, job title, and so forth.

For Web sites, it's also important to create a Web use profile that summarizes a community's Web experience. Typical Web use characteristics include how long someone has been using the Web, how much time he or she spends using it, and what kinds of things he or she uses it for.

Note

A complete list of the factors that make up demographic and Web use profiles is available in the Appendix and discussed further in Chapter 11 on surveys.

Appropriate terminology is one of the most important elements in a successful interaction. Most interfaces are largely made out of words, and words can be ambiguous and easily misunderstood, so their comprehension is especially critical. Examining the words that people use to describe a task, and how they organize those words, is one of the keys to creating a product that meets their expectations and needs.

The audience's mental model makes up a third major piece that's used in creating an information architecture. A mental model is how people currently understand the topic, what kind of picture they've built for themselves of how a given task is done or organized, the names and relationship of terms they use. For example, even though food in supermarkets is mostly organized by either food group or storage requirements (all the things that are bottled go together, all the things that need to be cold go together, etc.), research conducted by Indi Young shows that people rarely think of their food in those terms when shopping. People often make up their shopping lists based on meals that they're planning or by which foods go with which other foods. Their mental model is therefore based on meals, not on how something looks or how it's stored. Since a Web site doesn't have to work like a supermarket, it can be organized in a way that's closer to how people plan their meals rather than by food storage constraints.

Mental model research can be done both before a service is created—to see how people perform a certain task in order to emulate it with a software interface—and after an interface has been designed—to see how well users' ideas match the designers'.

Useful Tools and Techniques

For information architecture, the most useful tools are the ones that give insight into both who the target audience is and how they think about information: how they organize it, how they prioritize it, what they call things.

• For a brand-new service, a profile of potential users provides an idea of what kinds of people will use the service, how they will use it, and what they will use it for. Profiles are described in Chapter 7.

• For an existing service, a survey reveals who is already using the service. Surveys are covered in Chapter 11.

• Once the target audience has been established, contextual inquiry and task analysis are the basic tools for creating the mental model. Contextual inquiry sheds light on the kinds of situations in which a typical user uses your product (or doesn't, but should). Task analysis then determines exactly how users think about what they're trying to do, what assumptions they make, what kinds of words they use to describe the tasks, and how the tasks interact with other things they're trying to do. These techniques are covered in Chapter 8.

• Card sorting, a process by which people group ideas into categories that make sense to them, helps reveal how people organize topics, and what they call groups of ideas. Card sorting is also covered in Chapter 8.

• Analyzing diaries kept by users helps reveal how mental models change with time. They provide insight into how users' expectations and understanding change as they become more experienced with the tool. Diaries are discussed in Chapter 12.

The knowledge provided by these tools can be used to determine a good information architecture and to provide context for other fundamental questions about the product. Knowing which features are most attractive can, for example, be immediately used in the marketing of the product. Likewise, studying a site's mental model can uncover unmet needs in the target audience, suggesting additional features for the product in mind, and—occasionally—whole other products. For example, a mental model of how people use search engines showed that people expected to be able to use them to search the latest news. However, this was outside the focus of what the search engine was supposed to do, but it still seemed like a valuable idea, so it was spun off as a wholly separate product.