New on UXmatters
  • Defining Clear Product Requirements | Viewpoints for Design Reviews
  • Five Best Practices for Becoming a Data-Driven Design Organization, Part 2
  • The User’s Journey: Storymapping Products That People Love
  • The Web and Cuban Technology Limitations
  • Surviving the Dying Career of Technical Writing
  • Excuses, Excuses! Why Companies Don’t Conduct User Research
  • Book Review: $1 Prototype: A Modern Approach to Mobile UX Design and Rapid Innovation
  • Session Expiry and Coke Machines
  • Designing Social Interfaces: Principles, Patterns, and Practices for Improving the User Experience
  • The Interview Survey: Getting the Accuracy of Interviewing Thousands of Users
  • UXnews
Sponsors of UXmatters
Do you create products or organize events for UX professionals or manage a UX team that’s hiring? Sponsor UXmatters and see your ad or logo here! Learn morespacer

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Framing the Practice of Information Architecture

spacer

By Nathaniel Davis

Published: September 7, 2011

“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

“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).”

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 Morvillespacer —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 Garrettspacer would want you to believe, but because the function of information architecturespacer 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 practicespacer 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 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 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.spacer For example, how should you consider the information architecture for a domain of information that spans multiple subject domains,spacer across physical constructsspacer that support multiple modesspacer 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, [1] 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.

Figure 1—Rosenfeld and Morville’s information architecture iceberg

spacer

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.

Figure 2—My contemporary information architecture iceberg

spacer

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….”

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

Questions Example Methods Notes
Navigation
What information retrieval methods will people need to find targeted information?
  • Search
  • Hierarchal Menu
  • User Recommendation
Information Organization
How should we formally group the information?
  • Taxonomy
  • Content Matrix
  • Thesaurus
Information Relationships
How can we define the targeted information to offer flexibility and extensibility?
  • Content Model
  • Metadata
  • Domain Model
IA Management
What processes and rules do we need to enforce to preserve the effectiveness of an information architecture?
  • Metadata Guidelines
  • Page Intention
  • Practice Model
For additional information on my research in practice modeling as it relates
to IA and UX design, visit
DSIA Practice Model Research.spacer
IA Strategy
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 Versionspacer spacer

HTML Versionspacer

IA Research
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

“Our IA recommendations should address more than a site’s navigation and information organization and relationships.”

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

Moving Forward

“Having a clear understanding of the basic areas of interest IA practice comprehends would naturally help you to navigate its challenges.”

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

References

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

[2] Davis, Nathaniel. “Information Architecture As a Practice.” DSIA Portal of Information Architecture,spacer July 2011. Retrieved August 30, 2011.

Topic: Columns | Information Architecture | UX Professions

2 Comments

S H Dwyerspacer wrote:

I’m glad to finally see a framework for IA that differentiates it from UI design. Morville, Rosenfeld, and their counterparts, while highly respected for helping to generate serious awareness of information architecture, have done it a disservice by pruning it down to their own comfort zones of Web UI design. Information architecture, on the surface, is indeed limited to navigation and, behind the scenes, is much more than the few deliverables mentioned in their pyramid. Indeed, research, strategy, and management constitute most of the work I do as an information architect, and this work extends beyond Web sites to document management systems, rich media repositories, an so on. While I’m also a certified usability analyst and fully aware of non-IA UX design principles, I draw a hard line in projects at work and avoid getting involved in graphic design—colors, fonts, and other creative UI work. UI work is better left to UI/UX designers.

November 15, 2011 10:19 AM | Reply

Dominik Buettiker wrote:

Dear All, Great read. I hope the community is still monitored and the discussion can continue. While I like the Iceberg, I think the model underestimates the role of a taxonomy. For me, it’s at the centre of all. How could this work together?

June 15, 2015 9:49 AM | Reply

Join the Discussion

Asterisks (*) indicate required information.

 

gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.