“The practice of information architecture is the effort of organizing and relating information in a way that simplifies how people navigate and use information on the Web.”—DSIA Research Initiative
Over the past two decades, the volatile evolution of Web applications and services has resulted in organizational uncertainty that has kept our understanding and framing of the information architect in constant flux. In the meantime, the reality of getting things done has resulted in a professional environment where the information architect is less important than the practitioner of information architecture (IA).
While members of the UX community are still debating what we should expect from an information architect—most recently Peter Morville—placing our attention on the practitioner of information architecture appears to be a more attainable goal. Not because information architects don’t exist, as Jesse James Garrett would want you to believe, but because the function of information architecture meets a real need and requires our immediate attention, no matter what a practitioner’s title or disciplinary affiliation might be.
For the growing number of UX design professionals and other traditional participants in the design of user experiences—such as interaction designers, user interface designers, visual designers, and software developers—who help to create Web-based interactive experiences, discerning the essential scope of the practice of information architecture can be a challenge.
It would be nice to say that we can fix this situation through better communication, which would surely be an improvement and is one of the reasons why I have committed to writing this column. However, the name of my new column, Finding Our Way, reflects the main reason most people still struggle with understanding the scope of information architecture. This title is an admission that the field of information architecture is in a dynamic phase of discovery and maturation. While there is a lot that we already know, there is still much that we need to understand.
Most important, this title is imbued with a sense of optimism and a promise on which this column will deliver: helping UXmatters readers to navigate the evolving practice of information architecture by exploring the actionable theories, concepts, and vocabulary that enable us to produce design solutions with greater attention to the details of information architecture. These details will become increasingly important as the domains of information we create grow more complex over time.
The Interests of Information Architecture
You may confront greater IA challenges simply by staying around long enough to see a domain of information that you’ve architected grow in abundance and use. Or, you may end up taking on more projects that force you to view information architecture in a way that’s broader than a single-domain IA strategy. For example, how should you consider the information architecture for a domain of information that spans multiple subject domains, across physical constructs that support multiple modes of interaction with information? This would be equivalent to engineering a single information architecture that supports two separate sites—one on the desktop, using a Web browser, and the other on a mobile phone.
Many of you might be thinking that the practice of information architecture is just the organization of pieces of content in a way that lets people make useful semantic and contextual associations between them and creating navigation schemes that promote findability. You would be right. However, this is equivalent to saying, “an iceberg is an island of ice that floats on water.” Technically, this is right, too. However, if we want to take this viewpoint to the next level of clarity, we’ll need to acknowledge that the floating-island perspective describes only a small part of what an iceberg truly is: less of an island and more of a massive, floating underwater mountain.
In their seminal book, Information Architecture for the World Wide Web, 3rd Edition,  Lou Rosenfeld and Peter Morville were the first to use this more extensive perspective on an iceberg to express information architecture. However, the iceberg of information architecture that I’ll be discussing here is not exactly the one Rosenfeld and Morville depicted.
If you recall, Rosenfeld and Morville proposed an information architecture iceberg in which the user interface is the tangible work product that often becomes the focus of projects. However, if you study the layers of their illustration as a collection, as shown in Figure 1, they appear to describe an iceberg of user experience design more than an iceberg of information architecture.
I’d like to recommend an alternative view of this iceberg in which the user interface does not represent the surface. From this viewpoint, navigation instead represents the surface of information architecture, as shown in Figure 2. A series of hypertext links and search functionality are widely used artifacts of navigation.
Removing the interface and wireframes from Rosenfeld and Morville’s original iceberg makes a clearer delineation between information architecture and user interface (UI) design and interaction design. While information architecture is closely related to UI design and interaction design, information architecture remains a unique concern.
This contemporary IA iceberg also focuses less on communicating tactical methods and places more emphasis on important, high-level areas of interest that provide categorical homes for many of the methods and interests that appear in Rosenfeld and Morville’s original diagram.
Finally, this contemporary iceberg of information architecture is both scalable and flexible. For example, it provides actionable perspectives for Web site information architecture and the more challenging enterprise information architecture. Depending on your need, feel free to choose the most appropriate methods for each layer. In the next section, I’ll demonstrate common methods that we can consider for each layer.
Putting an Iceberg to Good Use
My contemporary IA iceberg illustration is useful because each layer of the iceberg helps communicate the primary areas of interest that define the scope of information architecture for a project or even an entire enterprise. As a result, you can use it to frame questions that consistently produce thoughtful IA recommendations.
In Table 1, I’ve paired each iceberg layer with a single question and a short list of example methods—not a complete listing of methods—that we can consider using to produce effective solutions.
Table 1—The layers of my IA iceberg
What information retrieval methods will people need to find targeted information?
How should we formally group the information?
How can we define the targeted information to offer flexibility and extensibility?
What processes and rules do we need to enforce to preserve the effectiveness of an information architecture?
Does the designed information architecture fit into a pre-existing IA strategy?
Single-domain IA Strategy
Multi-domain IA Strategy
Cross-domain IA Strategy
Single-, multi-, and cross-domain IA strategies are relatively new perspectives I’ve been exploring. For additional thoughts on these, read “From Tsunami to Rising Tide.” PDF Version | HTML Version
What methods should we use to build assumptions and create and assess the performance of a recommended information architecture?
Quantitative Research—such as Path Analysis or Search Analytics
Qualitative Research—such as Observing User Behavior, Contextual Inquiry, or Content Analysis
There’s More to Information Architecture Than We Think
The contemporary information architecture iceberg we’ve just considered encourages a reliable range of questions that we can use to shape and maintain the information architecture for any domain. Our practice and the resulting discipline around these matters will become crucial as our clients continue to support larger and more complex information domains.
Our IA recommendations should address more than a Web site’s navigation and information organization and relationships. While these cover the basic concepts  in the practice of information architecture, they represent only a part of the required effort. Management, strategy, and research are where information architecture goes deep to address the complexity of information domains in a sustainable manner. When your practice encompasses these, you’ll be offering a more comprehensive perspective that adds value to your organization and the businesses you serve.
Overall, the six areas of interest in IA practice I’ve described in this article offer UX professionals many opportunities to refine their skills and expertise in information architecture. If exploring the deeper interests of information architecture doesn’t excite you, at least use the contemporary IA iceberg to help you determine when you need to engage or recommend a practitioner of information architecture who has the necessary competencies to close the gaps in your future IA implementations.
Whether you’re a UX designer or aspire to focus solely on the practice of information architecture, having a clear understanding of the basic areas of interest IA practice comprehends would naturally help you to navigate its challenges. The contemporary information architecture iceberg I’ve discussed in this column offers a useful visualization and frame of reference for doing just that.
 Morville, Peter, and Louis Rosenfeld. Information Architecture for the World Wide Web: Designing Large-Scale Web Sites, 3rd ed. Sebastopol, CA: O’Reilly Media, 2006.
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.