Bulletin Issues

Feedback

Bulletin, August/September 2010

Eight Principles of Information Architecture

by Dan Brown

Information architecture, a field in relative infancy and constantly rediscovering itself, does not yet have a well-established theory that drives the design of structures for websites. You can pick up two books on graphic design and see the same topics covered in each. Why is there no such agreement for books on information architecture? Indeed, information architecture has yet to normalize, and the constant new demands on our work make progress toward that goal challenging.

I'd expect such a theoretical framework to have a set of principles – guidelines based in universal truths that provide a sketch of what makes any information architecture good. White space, typography and color theory provide a set of principles for graphic design. Where are the ones for information architecture?

While the industry has yet to settle on a standard theory, there are a handful of principles I keep coming back to – principles that guide my design decisions but don't dictate a particular approach. They help me zero-in or refine a concept by providing a stable and reliable worldview. Fairly general in nature, they apply to most situations and have sufficient room for interpretation so I can fine-tune them for individual projects.

I first codified these principles when a client of mine faced internal pressure to justify the design we presented. She knew the direction was sound and rested on several iterations, validated requirements and existing user research. She worried, however, that her stakeholders wouldn't be convinced. I put together a one-page summary of these principles to establish a theoretical foundation for her internal discussions.

These principles make an assumption: information architecture is the practice of designing structures. These principles help guide the design of structures, but they presume the following:

The information architect's primary focus is the structure itself and secondarily the user interface representing the structure on screen (I make site maps and flow charts)

The information architect has a good understanding of how people want to relate to the content and functionality contained in the structure (I’ve done my research)

The information architect has a good understanding of the range of content and functionality to be supported by the structure (I’ve inventoried the content)

Got those? Good. Let's look at the principles. Here’s a preview:

The principle of objects – Treat content as a living, breathing thing, with a lifecycle, behaviors and attributes.

The principle of choices – Create pages that offer meaningful choices to users, keeping the range of choices available focused on a particular task.

The principle of disclosure – Show only enough information to help people understand what kinds of information they'll find as they dig deeper.

The principle of exemplars – Describe the contents of categories by showing examples of the contents.

The principle of front doors – Assume at least half of the website’s visitors will come through some page other than the home page.

The principle of multiple classification – Offer users several different classification schemes to browse the site’s content.

The principle of growth – Assume the content you have today is a small fraction of the content you will have tomorrow.

The Principle of Objects
Treat content as a living, breathing thing with a lifecycle, behaviors and attributes.

Where it comes from. Thinking of content as objects comes from object-oriented programming, where a computer program is broken up into discrete, logical chunks. Each chunk has methods, behaviors that the chunk of code can perform, and properties, pieces of information attached to the object. Objects are really templates, so the methods and properties provide a framework for thinking about all instances of a particular object.

So, when I say "object," I mean that website content has

a consistent and recognizable internal structure (such as the different ingredients of a recipe) and

a discrete set of behaviors (such as how recipes can have variations or can become more or less important).

How I use it. When starting a new project, I identify all the content types – common structures that will be used throughout the site. For marketing sites, I might identify content types such as products or services or industries. But that's boring.

Let's take a recipe site. I say "recipe" and you already have a model in your head about what kinds of information it will include: ingredients, quantities, process, servings, cuisine, dish type, preparation duration, dietary information and so forth. This structure gives me different ways to sort, expose, classify and connect content of this type together. We can create relationships to recipes that are complementary. Or we can connect this recipe to different versions of the same dish. Recipes, therefore, have a predictable structure that enables building relationships. Got that? There's more.

You can even think of recipes as having behaviors. Recipes can "reproduce" when people comment on them with their own twist. A recipe's importance can recede or intensify in different seasons (strong emphasis on matzoh ball soup in mid-Spring, for example). This kind of content has pretty predictable ways in which it behaves.

The Principle of Choices
Create pages that offer meaningful choices to users, keeping the range of choices available focused on a particular task.

Where it comes from. The Paradox of Choice is a book by Barry Schwartz
[1] that came out in 2005. In brief, the book's message is that a greater number of options can make it more difficult for people to make a decision. More options means more cognitive effort, and more effort can sometimes mean more anxiety. People think they like having a lot of options, but they really do not.

How I use it. Corporate intranets are ripe for long lists of content. The organization publishes policies, all on a particular topic (benefits, say) and rarely makes the editorial effort necessary to keep the lists lean and focused. The cost is obvious: Users spend more time sifting through lists to find what they need. They might therefore avoid looking through the lists altogether, never finding what they need, or they might use alternate channels, like picking up the phone, defeating the purpose of the intranet.

In designing information hierarchies, I tend to spread things out. That is, I tend to make shorter lists of choices, at least at the upper levels of the hierarchy.

The Principle of Disclosure
Show only enough information to help people understand what kinds of information they'll find as they dig deeper.

Where it comes from. Progressive disclosure is a common design concept that builds on the ideas that we can only process so much information at once, but that we can use what we have to anticipate what’s to come. I like the explanation in
Universal Principles of Design, a book by William Lidwell, Kritina Holden and Jill Butler
[2, p. 154]: “Information presented to a person who is not interested or ready to process it is effectively noise.”

How I use it. The main way progressive disclosure influences thinking about a design is that I have to think about content in terms of layers. A site presents different layers of the same content in different areas of the site.

Let’s go back to the recipes. A cooking site can’t display a recipe in its entirety on every page of the site; that would be ridiculous. Instead, categories of recipes should show much less information about the recipe, but the right information. If I’m looking at a list of seasonal springtime dishes, just showing me the cuisine of each dish won’t give me much useful information. Instead, other pieces of information – a list of recipe names, a picture of the dish and maybe a couple of the key ingredients – help me learn just enough about the recipe to decide if I want to click further ahead.

The Principle of Exemplars
Describe the contents of categories by showing examples of the contents.

Where it comes from. Cognitive science has long studied how people categorize things. The field looks at what it means to hold a concept in your head. Ultimately, psychologists have discovered that our brains represent categories as networks of good examples.

How I use it. Whenever I display a category name, I provide a few examples of the content that lives in that category. This practice is perhaps less relevant on recipe websites and more relevant on corporate intranets. For the last intranet that I designed, I included a list of the main categories on the home page. Adjacent to each category name appeared a list of two or three items that best represent that category:

Forms (W-4, equipment request, expense report)

Policies (vacation, work from home, parental leave)

These links provide quick access to the most commonly used forms, but more importantly offer some insight as to what content lives inside the category.

Netflix has a great example. If you are a regular customer, the Netflix home page reveals a range of esoteric categories. Here are two of the categories on my Netflix home page:

Emotional Dramas

Understated Suspenseful TV Shows

Instead of providing a description of these categories, Netflix does three things for each category:

Shows me movies or shows that I’ve already seen from these categories, providing a rationale for presenting them to me.

Shows me four videos I have NOT seen.

Provides a link to more movies or shows in this category.

By displaying six videos in the category, Netflix does a better job of helping me understand the category’s contents than any straight description.

The Principle of Front Doors
Assume at least half of the website’s visitors will come through some page other than the home page.

Where it comes from. This notion has become commonplace since even the larger sites find that most of their traffic comes through a side door, not the home page. These direct links are the power of search.

How I use it. The principle yields at least two practical pieces of advice. First, a destination page has to help users understand what else they can find on the site. By “destination page” I mean a page where users would land to consume content: a video on YouTube, a photo on Flickr or an article on WashingtonPost.com. Users coming to these pages through an outside search engine may find what they’re looking for, but that page also may have the responsibility to tell visitors where they are and what else they can do while they’re here.

Landing on a recipe for matzoh ball soup, a visitor to our recipe site should see the recipe itself, of course, and additional content for that recipe that adds some value (customer comments or reviews). However, the page also must take users to related recipes (like kugel) and perhaps provide a taste of what other kinds of recipes they can find on the site.

The second piece of advice coming from this principle is that the home page does not have to do everything. Good home pages exemplify the breadth of information on the site, but do not attempt to reveal every last piece of content. They do not try to expose every category and provide a path to every nook and cranny. They instead focus on helping new users understand what the site is all about.

The Principle of Multiple Classification
Offer users several different classification schemes to browse the site’s content.

Where it comes from. Good information architecture acknowledges that people have different ways of looking for information. Even narrow audiences represent a diversity of motivations and mental models (how we imagine information space). A classification scheme attempts to provide simple ways for finding information across this range. A classification scheme describes what labels you will use to categorize the website's content.

How I use it. Corporate intranets offer a ripe opportunity to use multiple classification schemes. Having worked on a few of these, I found a consistent pattern between organizations. People definitely use topics (like, vacations, for example) to find content on an intranet, but they also use content type (like, policy or form). They might also use department (HR, for example) but for some departments that is more meaningful and generally tied to the topic than for others. In short, then, either topic or content type frequently constitutes the starting point for finding information on an intranet. Navigation mechanisms incorporate both of these classification schemes in ways that let users employ them independently but also combine them as necessary.

This principle is a double-edged sword. Providing multiple ways to find content benefits users, but providing too many ways can overwhelm and distract them.

Where it comes from. Lots of design teams use phrases like “global navigation” or “right rail” or “left menu bar” to refer to a menu that lets users browse content, but do so with its location on the page. Where a menu appears should not constitute its definition.

As for where it came from, it’s all me. Working with design teams in organizations that use phrases like “global nav,” I realized that the label makes it difficult for those teams to understand what the navigation menu is for. A navigation menu loses its purpose when its name comes from its location on the template.

How I use it. Designing navigation means establishing a strategy for finding content on the website. That strategy can entail several different navigation mechanisms – menus providing access to the content in different ways. On a content-focused website I designed recently, I incorporated four navigation mechanisms:

Topic navigation: The site’s main navigation, which constituted the six main topic areas.

Timely navigation: A short menu providing links to subtopics that were especially relevant or seasonal.

Signpost navigation: A menu appearing on interior pages to reveal how the article was classified and giving users an opportunity to explore those categories.

Marketing navigation: A short menu appearing adjacent to the topic navigation providing links to services offered by the organization.

The Principle of Growth
Assume the content you have today is a small fraction of the content you will have tomorrow.

Where it comes from. Of all the principles on this list, this one is at once both the most self-evident and the most confounding. We all know where it comes from: the web today has more content than it did last year and the year before and the year before that. The convenience of publishing content combined with inexpensive storage means people put stuff up, but don’t take stuff down.

Designing for the exponential proliferation of content is challenging. Designing a structure that can accommodate twice as much content as it can today is like building an armoire with twice as many drawers. The digital storage of information comes with (apparently) limitless space, but the presentation of and access to that information must conform, on some levels, with the limitations imposed by physical space. Why? The people who browse the stacks at a library are the same people looking for content online: we have the same cognitive and ergonomic requirements.

How I use it. Unfortunately, no hard and fast rules come from this principle. It is at once inevitable (there will be more!) and impossible to predict (how much more? what more?). This is the crux of the challenge: a website can grow in several different directions at once:

It can add more content to existing categories: More articles under a topic.

It can add different types of content to existing categories: Videos in a topic that’s been dominated by text.

It can create new categories: A brand new topic.

The approach I use depends on the previous principle – focused navigation. By assuming that the information space you design requires several different navigation mechanisms, you can accommodate different types of growth within each one. Anticipate various kinds of growth your site might endure and identify how each type of navigation deals with it.

For example, in a navigation mechanism that just deals with topics, the information architect can establish very broad top-level categories, making it easier to accommodate new topics as sub-categories. This menu doesn’t have to deal with any other forms of growth, just the addition of new topics.

To deal with new content types, the information architect can design the topic page anticipating new forms of content – video, presentations, photo galleries, podcasts – and design the page to accommodate them. Again, this page shouldn’t try to deal with any other forms of growth, just the possibility of new content types.

By splitting up the responsibilities of accommodating growth, a website can do so gracefully and hopefully with minimal fuss.

Universal Principles of Information Architecture
As Lidwell, Holden and Butler say in the introduction to their book, “The use of well-established design principles increases the probability that a design will be successful.”
[2, p.13]

The key term here is “well-established.” Information architecture, though perhaps in its infancy compared to other design fields like building architecture and graphic design, can still establish a set of self-evident truths derived from other fields of design, experience and testing. These principles can constitute the foundation of a theory of information architecture, a framework for informing design decisions about the structures of websites (among other things).

What separates these principles from, say, those described in the Lidwell, Holden and Butler book is that, for now, these are my principles. I derived them from my work either organically or as adaptations of principles from other fields validated through experience. They’re the principles I bring with me to every new project, a psychic history of prior challenges, debates and lessons learned. They serve as the starting point for project-specific principles, a fertile ground for growing guidelines geared especially for a particular client, set of design challenges or project objective.

I hope you disagreed with them. At least one of them. A serious theoretical framework establishes a place for interpretation, reconsideration and debate. A theory of information architecture would escalate our conversations, taking us beyond “what do we do” and even “how do we do it” and into something far more interesting: “How do we do it better?”

Resources Mentioned in the Article[1] Schwartz, B. (2005). The paradox of choice: Why more is
less. New York: HarperCollins.