Putting IA Theory into Practice
Published: January 21, 2013
In a previous column, “Creating a Web-Site Information Architecture in Six Steps,” I reviewed several categories of assumptions and tactics for creating a Web site’s information architecture. While that column focused on practice, it would also be useful for you to know how IA theory informed that column. Having a little theory in your back pocket is always useful.
Many practitioners of information architecture have come to understand the fundamentals of creating an information architecture through direct training, text books about practical methods, or real-world experience. In fact, you’d be hard pressed to find documentation on the formal theory of information architecture.
So, I’d like to share several theoretical concepts from my research that I used as the foundation for my column “Creating a Web-Site Information Architecture in Six Steps.” I’ll condense these concepts into a simple and, hopefully, memorable diagram.
There are five concepts that drive the six steps for creating a Web site’s information architecture. The controlled vocabulary of accepted terms from the DSIA Research Initiative includes these IA concepts:
- information architecture as work product
- IA common set
Information Architecture as Work Product
Let’s start with a definition. Information architecture is not just the name of a professional practice; it’s also the name that we give to our work product. The DSIA Research Initiative defines information architecture as “the assumptions and governing constructs for assigning properties and attributes to information and the endowment and evolution of information relationships over time within a given domain.” Put simply: “a governing model for information behavior.”
Not everyone may agree with this definition because of its narrowness. That’s completely fine. This is one reason that there are varying schools of thought on the practice of information architecture for the Web.
Ultimately, it’s not the definition that is most relevant; it’s whether the definition is actionable within the context of whatever you do. How a definition helps you—and the people or communities of practice with whom you work—to communicate and work effectively determines the value and utility of that definition. The definition that I use to define my information architecture work product has been pivotal to my success and has proven resilient in practice.
However you choose to define your information architecture work product—whether you create a new definition or adopt an existing one—you need to have a definition because it describes the thing you are creating to provide value to your design and development team and, ultimately, your business or client.
While context is theoretically one of several major forces that influence the requirements for an information architecture, it is a factor that many people generally take for granted.
I’ve defined context as follows: “The temporally interrelated conditions in which something exists or occurs.” This is a slight modification of the Merriam-Webster definition. I’ve added the idea of temporality to the definition because the context of use for user interfaces is rarely static. Rather, context is usually a temporary event or state. But it’s this state that defines the scope and domain of an information architecture.
When we examine context, it helps to establish the subject domains that influence the mental models of our target users, dictate the language they use, and influence their dialogue, as well as a site’s content. These are all crucial inputs for designing an information architecture.
Because context is also about circumstances, a thorough examination of context typically involves the use of interrogatives: who? what? where? when? why? and how? It’s also useful to expand on these by asking how much? how often? and how long?
Finally, for an information architecture to be effective, it must expose and satisfy patterns of shared language, relationships between content, and user expectations. Exploring context aids this discovery, which is why context sits at the epicenter of our approach, as shown in Figure 1. However, while context is a central concern, it is not necessarily the first information that we acquire when we embark on a project. The more complex a domain—typically because of various contexts and audiences—the longer it can take to expose the contextual variables of a domain in full.
Figure 1—Time and interrelated conditions heavily shape context
There are three primary probes that we use to develop the contextual assumptions that eventually influence the structure of an information architecture. When we view users’ engagement with a user interface as a communication exchange between a business and its target users—a typical scenario—our probes uncover and reflect the underlying intents of all participating parties and identify the more structured content objects that enable their communication, as shown in Figure 2.
In most situations, we probe for business intent and user intent. It’s possible for each to produce a segmentation comprising different personas and their respective contexts of use.
Probing user intent lets us record the key qualitative human factors that impact scenarios of information interaction and retrieval that are crucial to consuming content or using it in a flexible and unconstrained manner. Similarly, the act of probing business intent should uncover organizational needs, desires, and expectations through the people that model the business and execute its functions.
When probing business and user intents, we naturally incorporate a third probe: content. A Web site’s content supports the dialogue of any digital communication—from mundane transactions to recreational experiences—and is the capital that drives the information economy. Content includes images, graphics, text, audio, video, and raw data—in structured and unstructured formats. Any data that we can digitize can be content on a Web site. A core concern of information architecture in practice is understanding the essential nature and purpose of the content in any given domain to make it usable by assigning attributes and other properties to it.
Figure 2—Probing shared intent and content reveals IA scope
Constructs are not a new idea. In philosophy, a construct is essentially the result of objectifying something that takes on form, but only in one’s mind. In the context of understanding information architecture better, there are two types of constructs: abstract and physical constructs. However, in contrast to the concept of constructs in philosophy, abstract and physical constructs are not immaterial objects that we conceive of only in our minds. We instead view abstract constructs as tools and physical constructs as materials that enable the creation of an information architecture in a digital medium.
Abstract constructs are conceptual relationships. For example, a taxonomy is an abstract construct. Likewise, domain models and formal ontologies are abstract constructs. For the purposes of information architecture, abstract constructs come in two forms: constructs of information organization and constructs of information relationship.
Constructs of information organization define complex sets, or groupings, of information through content models. A content model can define something as simple as a form object, a component, or a page on which components appear or as complex as an entire domain of subject matter.
Constructs of information relationship define information attributes and behavior. For example, a basic relational construct is metadata, while an RDF (Resource Description Framework) statement is a more sophisticated type of construct.
Through the conscious design of abstract constructs, we can create logically organized sites whose structure users can intuit and endow information with semantic and ontological attributes that drive primary information relationships—as well as the evolution of new and unanticipated ones—within and across disparate domains.
Physical constructs, on the other hand, comprise a site’s navigation, or interactive sequence and dependent nodes, whether for a single path or all directed paths to content within a domain. As I’ve mentioned in previous columns, a site’s navigation system represents its most concrete instance of an information architecture. While certain abstract constructs may or may not be apparent to users, the physical construct of navigation is essential to the human-computer interaction of finding content. As long as the gestural nature of traversing information requires users to touch or click objects in a visual user interface, the importance of designing sound navigational constructs will remain paramount.
Both physical and abstract constructs are crucial to an information architecture, as Figure 3 shows. Creating optimal constructs requires research and strategy, as well as management programs for sustainable information architectures. Each information architecture construct may require different levels of attention and detail, depending on the size and complexity of the domain in question.
Figure 3—The three constructs of information architecture
IA Common Set
Together, contexts, probes, and constructs produce an IA common set. In related research that I’ve been performing in the domain of UX design, I’ve discovered that the concept of an interrelated set is worth formalizing because we see a common pattern of context, probes, and constructs in the creation of any UX design work product, across all UX design practice verticals. The Venn diagram shown in Figure 4 illustrates the IA common set.
Figure 4—Information architecture common set
It’s difficult to write about information architecture without mentioning Lou Rosenfeld and Peter Morville—early pioneers of both classic and contemporary IA perspectives. My IA common set diagram may remind you of Jess McMullin’s popular three circles diagram from 2001, which was inspired by Lou Rosenfeld’s post, “Majors and Minors.” Lou Rosenfeld and Peter Morville eventually used that three circles diagram to explain their model for practicing effective information architecture in their book Information Architecture for the World Wide Web.
According to Rosenfeld and Morville, the basis of an effective information architecture is the consideration of users’ information-seeking behaviors and information needs, the business context—business model, goals, and constraints—and content.
In my view, the IA common set and its supporting conceptual components improve upon the three circles diagram by broadening the meaning of context to represent more than business conditions. The IA common set encompasses the shared intents of both business and users, as well as content—all of which are impacted by context. Further, by bringing into focus the classification of the three information architecture constructs, it is my hope that this diagram of the IA common set will generate more meaningful conversations and results.
The Value of Theory
It’s important that we not ignore the potential role that theory can play in explaining the fundamentals of IA practice.
Theory—as a synthesis of what, how, and why we do what we do—can provide the future models and frameworks that will ultimately reinforce IA discipline and help us to codify what we do, so we can achieve greater efficiency. Sound theory can also provide a rigid approach to critiquing and challenging our observations, assumptions, and predictions, as well as creating hypotheses that we can test to expose new insights.
In this month’s column, I’ve demonstrated how theoretical concepts support my practical approach to creating a Web site’s information architecture in six steps, making it more than just a promise of best practice. The IA common set lets us visually express the theory behind conceptualizing an information architecture as a synthesis of context and a finite set of probes and constructs.
Note—You can download a visual reference guide to the IA common set from the DSIA Portal of Information Architecture.