By Bogo Vatovec
Bob Dylan once sang, “Man gave names to all the animals, in the beginning, long time ago.” Although it's debatable whether this song is the most influential that Bob Dylan wrote, it certainly comes up in my mind quite often in professional meetings and conferences. The fact that we can give names to objects, events, and abstract concepts is a gift. At the same time, this gift is a source of much confusion and sometimes funny (but more often very frustrating) situations.
Ever tried to use the phrase technical communication in a European country? In most countries, the phrase either doesn't mean anything or makes people think of mobile phones. And how does technical communication relate to the term information architecture?
This article will not discuss terminology; rather, it will explore how misunderstandings around the name of our discipline can cause significant irritation and limit professional effectiveness. In response, this article proposes a way to avoid these issues in specific situations by introducing a layered model for information architecture. This layered model can also be used for other purposes: structuring information architecture deliverables, checking team skills and competencies, assigning responsibilities, and verifying that communication among team members is effective.
A universally accepted term
Information architecture is a universally accepted term—perhaps even too broadly accepted. From a European point of view, this term has established itself in parallel with the North American trend. Since there was no appropriate term in other languages, “information architecture” suited Europeans just fine. We all jumped on a professional title that added more clarity and weight to what we were doing (instead of the “wire-framer,” the “concept-designer,” or the “usability guy,” for example).
This doesn't mean, however, that everyone has the same understanding of what information architecture is. On the contrary, the definition leaves much room for interpretation (as any definition of an abstract concept does)—especially when working with a business client. In a business context, the term information architecture doesn't necessarily reflect the definition that we as information architects (IAs) have more or less accepted in our own community.
In one of my recent projects as an e-business strategist, I participated in a planning workshop where the client's e-business, marketing, and IT teams met with a creative agency selected to redesign the client's international Web presence. In my role, I had to make sure that the agency understood the client's e-business vision and properly incorporated that vision into the planning and design of the new Web presence. The discussion became heated when we got to information architecture concepts. Here's a simplified and condensed version of the exchange:
Client: We want you to immediately start working on the information architecture; it's critical for the success of the site.
Creative agency: Sure! We need to understand the product structure first.
Client: Exactly. Start working on the information architecture for the products. It's the most complex part.
Creative agency (defensive): Agree. We need to understand the product structure before we can work on the information architecture.
Client (confused): Isn't the product structure the information architecture?
Creative agency: We think we should start by understanding the product structure before we decide which information about the projects we show.
Client (visibly irritated and confused): Agree. You are repeating yourself. I never said you should start with product descriptions and photos, but rather the information architecture.
Me: Perhaps it would help if you both briefly explain what you mean when you say “information architecture.” I think you are not quite talking about the same thing.
The client and the creative agency tried to describe information architecture using more abstract words like visualization, model, structure, and organization. Everyone agreed with everyone but did not make any progress. This example illustrates common irritation and confusion when people inadvertently use the same term to describe different things.
Since the abstract explanations didn't help my client or the creative agency, I proposed a more “architectural” approach to the conversation by looking at the information architecture at various layers. A layered approach to information architecture includes the following:
- Visual and interaction layer. This layer involves information visualization and interaction. This was the layer the agency was talking about and included deliverables such as wireframes, visual sketches, visual design, and later specifications for text, photos, and other elements on the site. In my example, both parties called this “the information architecture.”
- Structural layer. This is the layer with which the agency was particularly concerned and includes site maps, linking structures, logical taxonomy, and content sources. In my example, both parties agreed that this layer is “the information architecture.”
- Business logic or mapping layer. The mapping layer is where the taxonomy (which came up frequently in my example), customization and personalization, content reusability (or single sourcing), and delivery channel specifics play a significant role. In my example, both parties touched on these concepts every now and then, but never explicitly. The information source systems already play a significant role in how information will be logically organized and dispersed. This layer and its functions were never mentioned explicitly by either party in my example.
- Data layer. This layer was what the product experts and IT staffers in my scenario were talking about—that is, which data and how and where the data gets stored. They were not concerned with databases, but rather how the data is organized. This includes dynamic data, content management system, static data, and data sources.
In my example, this explanation of information architecture and, more specifically, what we are all doing and how things relate to each other, removed the confusion and allowed us to proceed. This layered model is not meant to be a definition nor the “absolute truth” about information architecture; rather, it provides guidance to help IAs clarify their work. It is structured from the outside-in (think of sushi), from the user- or client-visible parts to more information system-oriented technical parts. The model doesn't explicitly define the order in which deliverables should be produced, but it helps set the focus and thus helps identify the order specific to the project. Typically, the work must be done iteratively and in parallel.
I have used this layered approach to information architecture several times in situations like the one described above, and it always helped to identify exactly to which facet of information architecture a person is referring. Let's look at each of these layers in more detail.
Visual and interaction layer (information visualization)
This layer is about information visualization; clearly, this is the visible layer of the product and the one about which everyone has an opinion.
Using the term information architecture at this layer is misleading because we are actually talking about information and interaction design and layout. Some decisions made in this layer do have an impact on deeper information architecture, but more often it's the other way around. In addition, interaction-design skills are specific and different when compared with information architecture. The deliverables in this layer are various conceptual sketches: rough paper sketches, wireframes, interactive prototypes and first working interface drafts, and sometimes visual design elements.
Depending on a depth of the discussion, it's sometimes necessary to split this layer into two: visual design and interaction design. Some creative agencies are fine with the visual design, but struggle with interaction design. At the same time, most IAs don't work on the visual, but more on the interaction layer, thus becoming part interaction designer.
In business contexts, a wide variety of people and roles can be involved in the discussions around this layer. Assume that you will need to moderate many different opinions. In addition, many topics addressed here might actually be a better fit with other layers, so it is helpful to illustrate these layers at the beginning to achieve a shared understanding of the layers. As you do so, place the topics or questions to be discussed immediately next to the right layer in order to steer the discussion.
Structural layer
This layer is what we typically think of as the information architecture. It is the “third dimension” cutting through the user interface to information sources and presenting the right information in the right place. It brings the individual bits and pieces of information (and user interface pages) together through relationships. For an IA, it is important to consider two things:
- The interrelations between user interface pages
- The interrelations between the information objects (blocks)
Information architects with a more “user interface focus” work primarily on the relationships between user interface pages or elements; IAs with a more technical background focus more on the relationships between information objects. This difference is subtle but crucial: although a user interface page is an information object, an information object can be something concrete (such as text, multimedia, labels, metadata, and so on) or an abstract object like a “product” or “article.” An abstract information object, like a “product,” may consist of other information objects and be displayed on a user interface page (together with other information objects).
This concept is (and should be) reflected in the following deliverables of an information architect:
The user interface sitemap
This is the most common and known deliverable. Sitemaps rank in complexity from several boxes outlining the hierarchy to highly complex visualizations showing various dimensions, such as country-specific pages and customer profile–specific pages. Some sitemaps also show dynamic linking between pages. As visualizing dynamic linking typically reduces readability, this detail may be depicted in other deliverables.
The user interface interaction map (interface flows)
Contrary to the sitemap—which is usually purely hierarchical—the interaction map doesn't focus on hierarchies but rather on all other relationships between pages (such as static and dynamic links). Unfortunately, many IAs use the interaction maps (or flows) only to depict parts of the interface with explicit flows (for example, registration, account changes, and so on) but not for the complete product. I strongly recommend creating a full interaction map for the product: it represents all possible ways the user can move from one page to another. Going through such a map with a team and reviewing the possibilities results in an excellent mental model of the product design. At the same time, it gives hints on where the design's mental model can contradict a user's mental model, which in turn helps IAs improve the interface until both models match.
Both the sitemap and the interaction map can be intensively discussed in client workshops. There are easily understood, add tremendous transparency, and increase client understanding of the final product. Very often these flows open critical discussions about business processes, such as what is needed in order to support a certain workflow, what is done by the system, and what must be done manually by an operator. These are critical conversations that you should initiate and moderate as needed.
Business logic layer
The business logic or mapping layer is where concepts like taxonomy, customization and personalization, content reusability (or single sourcing), and delivery-channel details become important.
Information objects model
This shows the information structure of each information object, including visible and invisible information elements. For example, a news article consists of:
- Visible elements: a heading, author, date, summary, and the full article, as well as optional elements such as user tags, sound, video, and a photo gallery.
- Invisible elements: structural tags, additional metadata, expiry date, and archiving tags.
- Object actions: what can be done with the object and with each information element. For example, create new, delete, modify, move, duplicate, and so forth.
Often, IAs don't create models like this; instead, they add elements to the user interface and leave it up to the “data layer” to handle them. I strongly recommend creating these models, as this is the actual information architecture. In particular, the invisible elements are crucial for the proper management of the information, as they define dynamic behavior of information and define the requirements for the business and data layer. If the IA covers these aspects, he simplifies the design of these two layers significantly. Note that the IA in the information object model doesn't cover the technical data needed to make the desired functionality and information object work in a specific technical environment—that is a part of the data layer.
For all who are new to these concepts, I recommend reading some introductory chapters in any book on object-oriented modeling—information architecture is, in a way, an application of a user-centered design and object-oriented modeling on information delivery.
Taxonomy and ontology classifications
Taxonomic and ontological classification involves identifying dependencies and relationships among information objects. If the IA has created information objects models, creating and organizing classification schemes will be easy. If not, then something similar to the information objects map will have to be done in this layer. This work will also result in a definition of metadata used to describe the information objects and usage for this metadata.
Most commercial websites don't have or need an overly complex taxonomy and ontology. Typically their classification schemes concentrate on one of the two areas, including products and their classification or articles and their classification.
Conducting client workshops around the information objects model and taxonomy is often a challenge. It requires a multidisciplinary team that includes product experts (marketing, product managers, and the like) and IT professionals (who typically have a deeper understanding of the product model) who can each participate in the abstraction and modeling. I often split the model and discussion into visible elements (which are easier to understand and discuss) and invisible elements for which you need to find people at the client side able to understand them.
Personalization and customization
If the final information product allows or requires personalization and customization, this feature must be addressed in the business-logic layer. Details about personalization are beyond the scope of this article, but some of the typical deliverables here include:
- A user personalization profile model that describes various user profiles in relation to their personalization characteristics
- A mapping of user personalization profile models and information objects models
- Implications for the visual and interaction layer
- Implications and requirements for the technical infrastructure
The topic of personalization can lead to endless discussion; everybody has a different idea of what it is or should be. The role of an IA (or business architect) in this case is to clearly outline the potential levels of personalization and focus the discussion in the right strategic direction.
Implications for the technical infrastructure
Once the information has been modeled and you have a clear picture of relationships and the way they must be managed, requirements on the information-delivery systems become clear and can be further detailed. If the content delivery system is predefined, then its characteristics should be outlined as a model and considered in the information object model. Typically, this would include the technical limitations for what can be done with information objects—for example, only static tagging with no differentiation between end user and the editorial content. If the content delivery system is not defined, then the information object model defines clear requirements to help the team choose the content delivery system. Note that it is almost always necessary to revise the information object model to match the capabilities, information model, and actual implementation of the chosen system.
Data layer
The data layer covers all the layers defined above and mapped to the technical infrastructure. In this layer, all deliverables from the other layers are enriched with the specifics of the chosen technical infrastructure in order to be able to realize the desired behavior.
Although IAs are typically involved only in the deliverables for this layer, it is crucial to differentiate this layer from the others above and make sure the difference is understood by the team. At the same time, the specifics of the technical infrastructure from this layer do need to be understood by the whole team, and especially IAs, in order to come up with working and acceptable solutions.
Summary
Information architects have a variety of backgrounds and experience levels, all driven by the user-centered approach and a passion to ensure that user needs are incorporated in the information structure and design. This is also absolutely necessary; however, more is needed to make client project setup and strategy successful. I advocate expanding the IA's toolset by borrowing the concept of a layered approach to system architecture from the IT world. In conclusion:
- Don't assume that everyone on a team has the same understanding of information architecture that you do.
- Use the proposed layered approach to information architecture to bring clarity to your focus areas, the deliverables you produce, and the requirements you have on the extended team.
- Use the proposed layers to verify that your team has the necessary skills.
- Have a copy of Bob Dylan's “Man Gave Names to All the Animals” on your laptop and play it when appropriate.
Bogo Vatovec is known as a provocative speaker who gets straight to the point. He works as a no-nonsense consultant in change and transition management, user experience, and lean and agile methodologies.
