21 small thoughts (and counting?) about information architecture

I don’t know what this is. I know it’s not a complete thought. But it’s also not a draft of some specific larger thing. I think this is just an incomplete list; funny, given the topic.

There are many smarter and more experienced people than me who can and should and have written the books on information architecture — I’m especially fond of Abby Covert’s practical and democratized approach. But it’s still a discipline that’s close to my heart, and one I’ve been lucky enough to learn a lot about.

It’s also one that the designers and writers I teach and coach find very intimidating. I find it very intimidating! I was so terrified of putting my foot in my mouth at the IA Summit in 2012 that I paid out of pocket when I was living off credit cards after a layoff for the pre-conference workshop taught by Donna Spencer so that I would have at least some sense of the landscape.

Over time, I’ve come to feel that information architecture (IA), like many things in design, is best learned through purposeful but ultimately casual long-term study and, when possible, direct immersion in a project that needs IA work. You just kind of have to keep reading about it, and read the definitions of ontology and taxonomy a dozen times a year over several years, and watch lectures you don’t fully understand and read books that seem like they’re making sense but you’re not totally sure. And you’ll find that the more you read and watch and learn, the more you realize that it is, ultimately, just a formalization of all the stuff you’d do anyway if you’re doing a thorough job of designing a digital information space like an app or website, and that the skills and approaches you use to practice information architecture are tools you would have stumbled into anyway. And that’s how you’ll know it’s “true”, too, because … well, how else could it work?

Anyway, I like some of the entries on this list and thought I would share them so that the world has one more little bit of material to make part of individual learning journeys about information architecture. I’d love to hear if anything in this list particularly resonated with you, and/or if you think I’ve gotten anything wrong about IA. Just send me a note.

Information architecture is, primarily, a design discipline and area of professional practice.
Information architecture is not a single specific deliverable for your project any more than the “design” is a single specific deliverable.
It’s often more useful to talk about what information architects do and focus on than to debate what it “is” .
Information architects are primarily concerned with the conceptual integrity of information systems.
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.
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).
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.
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.
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.
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.
Information architects are highly collaborative, but often work as the only information architect on a project, even a very large one.
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.
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.
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.
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.
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.
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.
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”.
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.
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.
‘Information architect’ need not be one’s job title to design or refine an information architecture. It often isn’t.