Today, information architecture (IA) is a recognized term in many technology, product, and Web-design organizations. However, in many other organizations, information architecture is still “the pain with no name.” [1] If you ask senior practitioners of information architecture, they’ll tell you that information architecture is central to the creation of human-computer interfaces. But the fact of the matter is that the popular view of information architecture represents just a very small subset of its total value.
In this column, I’ll first summarize the popular conception of the practice of information architecture, then I’ll highlight the broader scope of the practice that still remains to be realized.
Champion Advertisement
Continue Reading…
Understanding the Scope of Information Architecture
For more than two decades, information-architecture pioneers, passionate thought leaders, and pundits have argued the merits of information architecture. The popular conception of the scope of information architecture has derived from the writings of Peter Morville and Lou Rosenfeld, who have defined the core components of information architecture, as follows:
navigation systems—how we browse or move through information
organization systems—how we categorize information
labeling systems—how we represent information
search systems—how we search for information
In defining a simple summary of any complex domain, there is the risk of trivializing what you’re trying to explain. Case in point: There have now been four editions of Morville and Rosenfeld’s book, Information Architecture for the World Wide Web, which explores the scope of these four components in detail. However, senior advocates and practitioners of information architecture still struggle to communicate more than just the first word in each of these component names.
For all intents and purposes, organizations have failed to adopt search as an information-architecture practice. Search platforms and artificial intelligence crowd this space. When a project team limits the definition of information architecture to navigation, content organization, and labeling—and not their respective systems—it’s all too easy for individuals to view the practice of information architecture as a cross-disciplinary effort. Even UX professionals, content strategists, technologists, and business stakeholders with only moderate information-architecture skills seem to be comfortable in rationalizing an information architecture.
As a consequence, we hear phrases like: “Everyone is doing information architecture.” And “Everyone is an information architect.” And these are actually expressions that leading IA practitioners have coined!
If, in theory, it’s true that everyone is doing information architecture and is an information architect, it’s just as true to say we’re all designers, artists, poets, and scientists. The risk with these sorts of statements is that they are abstract generalizations that encompass only the simplest use cases of more complex problem spaces. And they resonate only with those who have a limited conception of those spaces.
Recognizing Information Architecture as a System
It’s actually the second word in each of those component names that embodies the complexity and essence of information-architecture practice. Fortunately, there is just one word we need to consider in making this point: systems. Since 1998, the word system has persisted in the vernacular of information-architecture academics, practitioners, and independent researchers—and always in close relationship with the concepts of navigation systems, organization systems, labeling systems, and search systems.
Words have specific meanings in specific contexts. In relation to information architecture, the word systems does not imply technology systems. Rather, the use of the word system refers to the underlying ecological nature of an information environment, or space. Therefore, while the first word in each component name suggests an output, we should never take those words out of the context of their related information-architecture system. This is where the true scope of information architecture rests.
In theory, every user-interface design has an information architecture that underpins it. In practice, no information architecture exists without a representation of the system in question. This means, unless you have modeled the domain, or system, that an information architecture attempts to reflect, you have not really provided an information architecture.
For example, if someone uses a wireframe or high-fidelity prototype to show navigation, contextual links, and unique content sections, they have merely demonstrated the interactions a user takes to achieve a specific goal. They have not provides an information-architecture solution. The navigation and content groups that a user traverses within a user interface are just extensions of an inherent information architecture.
Thus, an information architecture is more than a collection of tangible user-interface constructs with which users engage—what the first word of each component name represents. More importantly, an information architecture encompasses the models of contextual relationships—the systems—that result in a user’s overarching user experience with a digital user interface.
There are various types of system models for representing information architectures and human-computer interactions in general, including the following:
business models
concept models
content models
controlled vocabularies
flow models
information models
journey maps
ontologies
persona models
site maps
taxonomies
Proceeding with Clarity
When a project team struggles in trying to rationalize the functionality of their user interfaces and the vision behind their experience design strategies, they are likely experiencing the pain of a poor definition of information architecture—which likely means no definition at all. However, project teams can begin improving their project and product outcomes today by adopting a thorough practice of information architecture.
Systematizing information architecture requires a focus on the relational definitions that drive navigation, organization, labeling, and search constructs. And, in all likelihood, this may require your team to invest in a senior-level information architect rather than another UX designer.
To tackle the systems that shape an information environment or an overall digital user experience, it is helpful to adopt a framework for addressing fundamental IA questions. In 2011, my very first column for UXmatters outlined six broad areas of interest that frame information architecture as a professional practice. These practice areas provide an actionable framework that helps IA practitioners to consider questions that are central to devising an effective IA solution. Tables 1 and 2 summarize the framework I’ve defined for information architecture and include both popular and underutilized information-architecture practices. The scope of an information-architecture effort will determine the extent of your analysis for each of these areas of interest.
How should we define targeted information such as entities and objects to ensure flexibility and extensibility for content?
IA management
What processes and rules do we need to enforce and preserve the effectiveness of an information architecture?
IA strategy
What strategies do we need to support static content, dynamic content, and the continuity of information models across multiple domains?
IA research and analytics
What methods should we use to define our assumptions and assess the performance and business value of a recommended information architecture?
All too often, the requirements for a digital user interface are constrained by overly narrow assumptions and short-term prospects, causing design and development teams to be inefficient and churn over iterative design cycles.
As Tables 1 and 2 show, the areas of interest that frame an information-architecture practice provide a solid footing for project definition and team engagement. Without a proper information-architecture process for modeling the contextual environment for human behavior and conceptual information structures, it is inevitable that design teams, enterprise technology groups, and digital product organizations will continue to feel the pain.
Conclusion
Information architecture is not just about navigation, labeling, organization, and search. It’s about the systems of relationships that make these things meaningful to users of digital user interfaces.
When a team models an information architecture properly, the complete system that ultimately results is far greater than the systems that drive navigation, labeling, organization, and search. We inevitably model the contextual system of language, behaviors, and situations that creates the need for the user interface in the first place. This model is powerful because, as Morville and Rosenfeld wrote in 1998, it becomes the “glue that holds [a Web site] together.”
On your next project, if you find your team struggling with clarity, challenge them by asking, “What’s the glue that’s holding all of this together?” When the room grows silent—and it will—be the hero and suggest that they hire an information architect.
Endnote
[1] According to Peter Morville, the editor for the first edition of Information Architecture for the World Wide Web coined the phrase “the pain with no name,” after talking to people who seemed frustrated by a recurring issue in creating Web sites, but didn’t know what it was or what to call it. This convinced Morville and Rosenfeld’s editor that their proposed book on information architecture had a viable audience.
Nathaniel has over 25 years of experience in human-computer interaction and is a leading advocate for the advancement of information architecture as an area of research and practice. He began practicing information architecture in the late ’90s, then focused on information architecture as his primary area of interest in 2006. He has made a study of information-architecture theory and how that theory translates into science, workable software, and methods that improve human interaction in complex information environments. Nathaniel was formerly director of information architecture at Prudential. His information-architecture consultancy Methodbrain specializes in UI structural engineering. Read More
