Download a free copy of “The New Design Fundamentals” ebook, a curated collection of chapters from our Design library. Note: this post is an excerpt from “Information Architecture,” 4th Edition, by Louis Rosenfeld, Peter Morville, and Jorge Arango, which is included in the curated collection.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.
Websites, intranets, apps, and other information environments are not lifeless, static constructs. Rather, there is a dynamic, organic nature to both the information systems and the broader contexts 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–6) 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.
In short, we need to understand the business goals behind the project 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 20 years. It’s held up well in all sorts of environments, from global websites 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 practitioners of information architecture 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 bring to the table, 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).
The three circles help with other tough questions, too, such as:
- What research and evaluation methods should information architects be familiar with?
- What kinds of people should be part of the team that designs the information architecture?
- What kinds of books and blogs should I read to keep up with the field and its practice?
- What should go into the IA strategy that I propose to my new prospect?
The answer to each starts with a balance among the three areas: users, content, and context.
Should technology have its own circle? Maybe. But we find that technology usually gets too much attention. Also, we increasingly find that much of what falls under the rubric of technology can be expressed within the “context” circle. After all, what technology brings to the table are new possibilities and constraints that give shape to the final product, and this is squarely within the realm of the context we’re designing for.
Incidentally, we think it’s important for information architects to have a good sense of humor. Perhaps you’ve already figured this out. The work we do involves high levels of abstraction, ambiguity, and occasionally absurdity, and to some degree, we’re all still making it up as we go along.
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 websites are different from intranets or that extranets should vary by industry. We mean that, like fingerprints and snowflakes, every information ecology is unique. The Toyota 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 definitions of industry best practices that have surged throughout the business world in recent years, each of these information systems has emerged as quite distinct.
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 project. Let’s take a look at how each of our three circles contributes to the emergence of a totally unique information ecology.
All digital design projects 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.
Because of this, information architectures must be uniquely matched to their contexts. The vocabulary and structure of your websites and your apps is a major component of the evolving conversation between your business and 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?
The key to success is understanding and alignment. First, you need to understand the business context. What makes it unique? Where is the business today and where does it want to be tomorrow? In many cases, you’re dealing with tacit knowledge. It’s not written down anywhere; it’s in people’s heads and has never been put into words. We’ll discuss a variety of methods for extracting and organizing this understanding of context. Then, you need to find ways to align the information architecture with the goals, strategy, and culture of the business. We’ll discuss the approaches and tools that enable this custom configuration.
You also need to understand the contextual differences imposed by the channels that the user will be using to interact with your organization. Will they be experiencing your services primarily via apps on mobile phones, or via a website on a desktop-based browser? Both platforms have things they can do well, and things they can’t. For example, smaller screens mean less space, which in turn implies shorter labels and navigation menus. If your service will be used via more than one channel, you need to consider how these channels will overlap and interact with each other. All of these factors form part of the context that will shape your information architecture.
We define “content” very broadly to include the documents, applications, services, schema, and metadata that people need to use or find in your systems. To employ a technical term, it’s the “stuff” that makes up your sites and apps. Our library backgrounds will be evident here in our bias toward textual information, and that’s not such a bad thing, given the heavily textual nature of many digital systems. Among other things, the Web is a wonderful communication tool, and communication is built upon words and sentences trying to convey meaning. Of course, we also recognize it as a tool for tasks and transactions, a flexible technology platform that supports buying and selling, calculating and configuring, sorting and simulating. But even the most task-oriented e-commerce website has “content” that customers must be able to find.
As you survey content across a variety of digital systems, the following facets bubble to the surface as distinguishing factors of each information ecology.
- Who creates and owns the content? Is ownership centralized within a content authoring group or distributed among functional departments? How much content is licensed from external information vendors? The answers to these questions play a huge role in influencing the level of control you have over all the other dimensions.
- Websites and intranets are becoming the unifying means of access to all digital formats within the organization. Oracle databases, product catalogs, Lotus Notes discussion archives, technical reports in MS Word, annual reports in PDF, office-supply purchasing applications, and video clips of the CEO are just a few of the types of documents, databases, and applications you’ll find on a given site.
- All documents are not created equal. An important memo may be fewer than 100 words. A technical manual may be more than 1,000 pages. Some information systems are built around the document paradigm, with the fully integrated document as the smallest discrete unit. Other systems take a content component or digital asset approach, leveraging some form of structural markup (XML or JSON, for example) to allow management and access at a finer level of granularity.
- To what extent has metadata that describes the content and objects within your system already been created? Have documents been tagged manually or automatically? What’s the level of quality and consistency? Is there a controlled vocabulary in place? Or have users been allowed to tag the content? These factors determine how much you’re starting from scratch with respect to both information retrieval and content management.
- How much content are we talking about? A hundred applications? A thousand pages? A million documents? How big is your system?
- What is the rate of growth or turnover? How much new content will be added next year? And how quickly will it go stale?
All of these dimensions make for a unique mix of content and applications, which in turn suggests the need for a customized information architecture.
The most important thing to know about users is that when we are talking about “users” we are talking about people. These are human beings with desires, needs, concerns, and foibles — just like you and us. We use the word “users” as shorthand to mean “the people who will use your information environment.”
When we worked on the first corporate website for Borders Books & Music, back in the mid–90s before Amazon became a household name, we learned a lot about how customer research and analysis was applied toward the design and architecture of physical bookstores.
Borders had a clear understanding of how the demographics, aesthetic preferences, and purchasing behaviors of their customers differed from those of Barnes & Noble. It is no mistake that the physical layout and the selection of books differed significantly between these two stores, even within the same town. They were different by design. And that difference was built upon an understanding of their unique customer or market segments.
Differences in customer preferences and behaviors within the physical world translate into different information needs and information-seeking behaviors in the context of websites and apps. For example, senior executives may need to find a few good documents on a particular topic very quickly. Research analysts may need to find all the relevant documents and may be willing to spend several hours on the hunt. Managers may have a high level of industry knowledge but low navigation and searching proficiency. Teenagers may be new to the subject area but really know how to handle a search engine.
Do you know who’s using your system? Do you know how they’re using it? And perhaps most importantly, do you know what information they want from your systems? These are not questions you can answer in brainstorming meetings or focus groups. As our friend and fellow information architect Chris Farnum likes to say, you need to get out there in the real world and study your “users in the mist.”