21 More Small Thoughts on Information Architecture
Expositions, Illustrations, and Annotations to Scott Kubie’s 21 Small Thoughts on IA
Scott Kubie wrote 21 thoughts on information architecture, perhaps because he’s too modest to call them truths about information architecture. Scott’s methodical approach to understanding and explaining information architecture appeals to me as a mentor, educator, consultant, and of course information architect.
But I’m also a philosopher, and I believe the best learning happens in dialog, a give and take, expanding and expounding on these thoughts. So I’ve added some of my own… let’s call them annotations. I’ll leave it up to you to decide whether they are true or not.
You can find his original piece on his blog. Scott’s thoughts are repeated here in boldface, with permission, and my thoughts follow in plain text.
SK: Information architecture is, primarily, a design discipline and area of professional practice.
DB: Like its namesake architecture, information architecture deals with the design of structures. In digital spaces, however, those structures can be abstract, and are often not user-facing. I appreciate starting with the foundation of design. Design is intentional and evidence-based and thrives on multiple perspectives, as does information architecture.
Information architecture is not a single specific deliverable for your project any more than the “design” is a single specific deliverable.
Increasingly, there are few formal deliverables for information architecture. My work as an information architect takes place largely in spreadsheets and collaboration boards like Miro or FigJam. Artifacts created during the information architecture process frequently help designers think through abstract problems and draw other team members into the design process.
It’s often more useful to talk about what information architects do and focus on than to debate what it “is” .
Let’s take that a step further and talk about what aspects of the user experience information architects think about — their scope or focus. Doing information architecture means paying attention to the structure of the user experience, making deliberate decisions about the virtual spaces users will occupy and interact with in using the product. In complex information spaces, we pay attention to helping users know where they are within that virtual space and signaling where they can go. We think about how the system provides “safe” options if they find themselves confused due to being “lost”. In transactional flows, we pay attention to how we set their expectations about the journey they’re about to undertake, and how we signal how much further they have to go. We think about how to collect information necessary to make a transaction, and how to structure the information collected in a way that will be most useful to the people on the other end.
Information architects are primarily concerned with the conceptual integrity of information systems.
Yes, and… information architecture in practice means recognizing that reality is messy. If our analysis is learning about a domain to understand its underlying concepts, our synthesis is translating those underlying concepts into a structure that’s meaningful for the people using it. Usually that means relaxing the conceptual integrity of information systems, but in a deliberate way such that you have a rationale for where you were strict and where you were less strict.
The conceptual integrity of the system is necessary for navigating the system, for understanding what the system is or does, for imagining how to use or experience the system, and being able to apply it.
Yes, and… Remember that people don’t experience the structure of a product in isolation from the other parts of the system. Therefore, the user interface and interaction design — not to mention the content and visual design — offer clues about how everything fits together. At the same time, users don’t have a holistic view of the system: they experience the system from a single vantage. They don’t have the benefit of the 10,000-foot view that we designers have. So, information architects need to conceive of the system as a whole, but also understand what it means to experience the system one element at a time.
Information architects talk a lot about navigation and landmarks, as the user’s navigation of a digital information system is one of the most mission-critical ways in which information architecture is applied. You could think of all of the road signs along an interstate highway system as part of its information architecture. But the road itself is also part of that architecture, and the fact that the road continues being a road and connects to other roads, and does not suddenly terminate in a parking lot or the ocean or get replaced with an enormous ball pit (fun as that might be).
Another way of thinking about this is that information architecture is inherently fractal. The signs directing traffic are a structure, but the concepts of “roads” and “signs” and “intersections” themselves describe another structure. There are relationships between these ideas. Information architecture often implies thinking about different levels of abstraction — different “zoom levels”. Some levels are closer to what the user experiences — like the navigation menus — and others are much further removed from the tangible aspects of the user experience. One underlying assumption is that all these levels are related to each other, such that a change at a more abstract level implies changes at the more tangible levels. If for some reason we decide that signs and roads and intersections isn’t a helpful structure, but tracks and stations and train lines is more relevant, then we’re going to have to make changes to the road signs themselves.
The work of information architecture, especially on the web, is a bit more like designing deep space habitats than it is like designing individual houses or office buildings. The information architect is imagining what a space needs to be and what it could be, where it will be located, who will be using it, what needs and knowledge the people who will be using it have, and how to simultaneously accommodate the needs of the moment and all the possibilities of the future. You have to make sure that the way to travel from the outer rings to the inner rings of the habitat is intuitively understandable, even to alien visitors, and even if the specific things happening in each of the rings changes a dozen times over from year to year.
I like this metaphor, but as I get further into my practice I’m striving to avoid spatial metaphors altogether. The main reason is that the dimensions of space and time are limited, and in building virtual spaces we’re often dealing with several more dimensions. Information spaces can be so complex that individual nodes in that space are infinitely smaller than a room in a building (or cabin in a space station). I don’t know what the biggest information space is, but consider the realm of books. There are nearly an infinite number of books out there, and a single book sits at the intersection of perhaps dozens of dimensions.
Information architects are curious about how information is organized, and talk about things like the LATCH framework, which suggests that information can only be organized in so many ways: Location, Alphabetically, Time, Category, Hierarchy.
Some people find LATCH helpful, but I do not. The other day I was working on a product that puts volunteers on teams, and then allows other people to evaluate the volunteers’ performance on a team. The product can aggregate data across teams, so that I can see a volunteer’s performance along a single rating like “leadership”. Or I can see how a single reviewer rated a volunteer’s performance over time. To gather that data, the product allows administrators to send out review forms. Teams can have their own forms, but can draw from the same pool of questions. There is a complex web of relationships here that is clearly structural, but I’d be hard pressed to fit it into any one of the LATCH organization schemes. I’m not sure how it would help me anyway. For me a better starting point is gathering all the nouns in a system and, starting with two or three, drawing connections between them. I deliberately, carefully add additional nouns to that model, labeling the connections with
Information architects often have to help and sort whole categories of information. It’s a bit like further organizing bins of LEGO pieces that have already been sorted by size and color — which bins on which shelves, in which rooms? As such, information architects often create “meta” categories that users and customers of a system will never directly see, but are nonetheless useful for doing that major organizing. They might create and help formalize the definition of internal organizational categories like, for instance, “channels”, “systems”, and “tools”. Or perhaps helping an organization determine which things in their universe are “products” and which are “services” — and if the distinction even matters, and how.
Another way to think about this is that we need to devise the language with which the team talks about the system. To have meaningful conversations about the product’s or system’s underlying structure, we need to understand the relationships that comprise the fundamental building blocks of the system. The defined content types within a content management system offer a good example. The person consuming the content doesn’t really care whether the content type is a long-form article or a corporate announcement, for example. Those content type definitions create a common language so that the organization can have productive conversations around governance and business rules. They also allow teams to explore relationships between categories of categories. Perhaps every corporate announcement (which expires after 30 days) must include a link to one or more long-form articles to provide a permanent home for the newly announced policy.
Information architects are often tasked with designing “hidden” systems of information that make websites and apps more usable. For instance, they might create a system of tags to apply to content in a database of technical support articles that makes it easier to recommend content that’s related to other content.
Tagging is a great example of a system within a system. It’s tempting to look at the information architecture for a product as a single monolithic entity, but it’s really a set of interconnected systems. The tags work with the content types, which work with the navigation components, which works with the main menu. All of these things are distinct systems that could not do the job on their own.
Information architects are highly collaborative, but often work as the only information architect on a project, even a very large one.
Given my position, I do not encounter dedicated information architects working at my clients’ organizations. I find people with an interest in information architecture. They recognize that information architecture has been missing from their practice, or their team’s capabilities. Few organizations seem to hire people as information architects. Those who do it in-house are those people who recognize that it needs to get done and just tackle it. More often, they recognize the need but can’t do anything about it. Perhaps they don’t have the experience to do the work that needs to get done, but it’s also often a question of capacity. Information architecture became neglected, and organizations hired UX designers with other strengths and capabilities.
As an outside consultant, I’m lucky that I can (a) focus on information architecture and (b) bring a small team with me to collaborate on IA problems. I work with one person right now who is a stellar UI designer, but brings an IA mindset to their work. I work with another person whose strength is in research and discovery, but has a strong interest in doing more information architecture work. The work product is much better for the collaboration.
Information architects often collaborate with content strategists, especially when those content strategists are concerned with large sets of content that need to be accessed by different audiences with different sets of needs.
Listen to me children: this is all that needs to be said about the relationship between information architecture and content strategy. If a project, for some reason, has both an information architect AND a content strategist on it, do not fret. Do not whinge about who does what. Be thankful. Be thankful that someone somewhere has deemed this project so complex, so important, so nuanced that it needs not one, but two people thinking about how content is structured.
Information architects do their best work when they’ve had an opportunity to get immersed in the world of information they’ve been tasked with organizing, and as such often spend a lot of time early on a project doing lots of reading and exploring without any specific outcomes in mind.
This is perhaps one of the reasons why IA has been neglected. From the outside, what Scott describes here doesn’t appear to be “work”. It appears to be an indulgent — almost academic — pursuit to satisfy curiosity. But, yes, the closer I can get to the domain the better the information architecture will be. By immersing myself in the domain, I’m hoping to see connections that we can exploit for use in the design of the product. This isn’t to say that connections and relationships are hidden from those who live and work in the domain every day. Instead, those connections are so ingrained in how they operate within the domain they barely notice them any more. My most satisfying moments as an information architect are identifying a distinction within a category that everyone took to be singular. As much as we prize the human mind for recognizing distinctions, it is also capable of concealing them when teasing out subtle differences between similar entities is effortful.
Information architects tend to approach their work through a series of increasingly-focused revisions, often starting by sorting things very roughly and broadly, and then more specifically, and then more specifically yet.
My process also entails exploring different ways to sort things. At the beginning of an IA project, even while we’re still doing research, I create a spreadsheet where each column represents a different approach to organizing the product. You might call this a top-down approach. I’m not trying to group items together. Instead I’m answering the question “Based on my understanding of user needs, business goals, and the content domain, how might I present navigation to help users find what they need?” I give myself permission to stretch the bounds of what navigation can and should do. I challenge myself to approach the domain in novel ways. I ask myself questions like, “What story do I want this navigation system to tell?” Then, in early design conversations, we review these different approaches with our clients and stakeholders. Usually I have a favorite, but the intent of that conversation is to see what resonates… and where their areas of discomfort are. Nothing touches an organization’s nerve like a new approach to navigation.
Ultimately, organizing information for use and understanding requires labels and categories to describe the types of information, and information architects will not only need to choose those labels, but also create documentation (such as glossaries and spreadsheets of “controlled vocabularies”) to specify the best words to use to describe things so that everyone working with the information understands each other.
Governance of information architecture is, I think, the most unexplored area of IA. When I’m working on an information architecture, one of the questions I ask is, “After I’ve left the project, how will the product team know where to put a new piece of content or a new feature?” The categorization needs to be clear to the target audience, but also to the people maintaining the system. Growth of information spaces is inevitable, and a good information architecture is resilient to growth, even accommodates it. Decisions you make in creating the information architecture resonate in the organization for years to come. They set a precedent, giving others license to treat information in the same way — how it’s categorized or archived or labeled. Therefore, the decisions we make as part of designing information architecture are consequential not just for how the user navigates the information space, but how that space will change over time.
Information architects often collaborate on or lead the development of website site maps, which describe in a hierarchical fashion the relationship of major topics, sections, and types of content on a given website. The site map is a way of best representing and replicating the conceptual integrity of an information system as a website.
We made it all the way to 16 thoughts before I got cynical! Site maps are great, but they’re simplifications of a (likely) much more complex system. They are a facade built on top of the structure to help people make sense of it. Perhaps they won’t ever understand the underlying structure of a product beyond what the site map tells them, but that’s OK. The role of the site map isn’t to convey the elegance and economy of the structures we design. They are literally a map to explain what you can find on this site or in this product. And like any map, they are abstractions of reality. Like any element of the user experience, a site map should serve a purpose grounded in a user need. If they user’s need to understand a site’s underlying structure, then the map should reflect that. Instead, a site map may only be a tool for educating users about what’s available, or helping them zero-in on the most common tasks.
Information architects know that sitemaps aren’t the same as navigation menus, and that navigation menus aren’t the same as “the” information architecture, and that there are often multiple useful ways of presenting the paths and tools available to navigate a given set of information to end users of the system.
Long gone are the days when a site’s main navigation has to be “comprehensive”. We invented megamenus so that we could show as much of the site as possible in the main navigation, but the truth is that to represent the entire structure is a fool’s errand. Moreover, it flies in the face of doing what’s best for the user. Today, I press my clients to think about what role they want the navigation to play in the user experience. I want them to think about how the navigation speaks to their target audience and how that message dovetails with messaging from other aspects of the product’s experience. In our work on an intranet right now I regularly remind our team we’re not trying to “boil the ocean” (a phrase I feel I should probably retire from my vernacular, if only for my kids’ sake). The purpose of the navigation — especially on a sprawling system like a corporate intranet — must be singular and clear, and can only be successful if it works in concert with other elements of the experience to convey the range of content available.
Information architects tend not to be concerned with which words are “right” so much as they are with which words are useful. While a brand book might tell you that the right word for a particular pocket-sized multi-tool is “Leatherman”, the IA knows that their audience might still call them “Swiss army knives”.
Useful words: so elegantly put! I’ll often put terms together (like “Policies & Procedures”) to help clarify the contents of a category, even if the words themselves aren’t in common usage in the organizations. One aspect of language that Scott hasn’t touched on here is that information architects sometimes distinguish the label for a concept from the labels in use in a navigation menu. That is, the only tools I have to describe a concept are words. So I will sometimes use temporary words to define the concept to make sure we’re all talking about the same underlying category. That label likely evolves in the final product, one that more closely aligns with user expectations or better describes the contents of the category. Policies & Procedures might become Corporate Standards or Guidance, but the first label is the one I use to validate that it is a meaningful and useful concept.
Information architects often help with the design of tools and components that help users navigate an information system, such as the main navigation menu, the search functionality, and the organization of content at critical touchpoints such as home pages and category landing pages.
All of these things — navigation, search, content organization — and other things like page layout and local navigation rely on an underlying structure, how all the elements of the system co-operate. These things are manifestations of the structure — facades exposed from different vantage points. “What does the structure look like when I’m at a destination page deep within the site?” “What does the structure look like when I arrive at the site on a middle-tier category page?” As an information architect, my role here is to decide what aspects of the structure can and should be exposed, and working with UI designers and content designers to determine the best approach for how those aspects are represented.
Information architects often use the design tool of card sorting, wherein the IA or stakeholders in a workshop are asked to sort a list of items into related groups, and then choose a name to describe those groups. Great information architects know that watching and listening to people perform this activity can be even more valuable than the actual choices they make while doing it.
Scott and I could do a whole dialog about IA tools — the ones we use for doing discovery (like a card sort), the ones we do to model different IA concepts, and the ones we use to test our IA concepts (like Optimal Workshop’s TreeJack and Chalkmark). It would be a short dialog (but dense!) because there remains a dearth of dedicated tools for information architects. I’ll tell you my dream tool? Parallel lists. I want to make a series of lists, displayed on the screen at the same time, and in the same “file”, but they can scroll and grow independently of each other. (Do not tell me how I can do this in a spreadsheet. I’m just not interested.)
‘Information architect’ need not be one’s job title to design or refine an information architecture. It often isn’t.
Of course not. Those who call themselves information architects rarely have the title Information Architect. But that’s part of the exquisite irony of our work — or perhaps the perfect encapsulation of it — that we’re compelled to separate labels and concepts while acknowledging that they are also inseparable.
👓 Dan Brown has been practicing user experience design for over 25 years.
In addition to writing the foreword to Scott’s excellent book Writing for Designers, he co-founded EightShapes, a user experience design firm based in Washington, DC 🏛. Dan wrote three books 📗📘📙 on user experience design, most recently Practical Design Discovery. He produces tools and games 🎲 for design teams, including Surviving Design Projects and Information Architecture Lenses 🔍.
Need to run a workshop? Looking for some help with your product’s user experience, user research, or information architecture? Just want to chat? Let’s set up a time to talk! 🗓
