The Name of the Practice Is Information Architecture

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. 

Table 1—Popular information-architecture practices
Areas of Interest Questions

including search

What information-retrieval methods will people need to find a targeted set of information?

Information organization,
including labeling

How should experts and non-experts be able to group content?

Table 2—Underutilized information-architecture practices
Areas of Interest Questions

Information relationship

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.


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. 


[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.

Source link

Leave a Reply

Your email address will not be published.