Just as human-centred approaches as a whole have suffered from being flattened to a superficial layer, information architecture has suffered its own flattening.
Some people compress information architecture down to navigation
Jorge Arango recently noted that information architecture is widely misunderstood. I have felt this frustration myself. I have even recently seen people who proclaim themselves to be user experience experts labouring under the impression that information architecture is only about navigation.
In his article, Jorge Arango suggests this flatting has arisen partly because most people who have come across information architecture have only done so in the context of making website navigation systems.
A legacy of the web-centric era
Jorge Arango was a major contributor to the most recent edition of Information Architecture for the Web and Beyond (colloquially known as the polar bear book). It is widely considered to be the definitive book of the discipline.
By necessity, the book took a web-centric framing. The information architecture needs it sought to address were those that emerged through the rapid development of the web from the mid-1990s to the mid-2010s.
That web-centric framing, alongside the book’s reputation as the canonical information architecture resource, possibly contributed to the navigation-centric view that has developed.
Yet navigation only forms a small part of the polar bear book’s coverage. The book is in fact a broad but shallow introduction to many (though not all) major aspects of information architecture. It covers 13 chapters over around 450 pages.
Each of its topics is covered at introductory level only. For example: thesauruses, controlled vocabularies and metadata are covered in one chapter.
By contrast, Heather Hedden’s book the Accidental Taxonomist covers these topics and more in further depth, as if it was the polar bear book just for taxonomies.
Yet, speak to some people about information architecture these days and it seems to have been squashed right down to: “let’s do a card sort and design the mega menu”. If you’re lucky, Gerry McGovern’s top tasks method gets a mention.
Card sorts and top tasks are worthless if they are meaningless
Top tasks and card sorts are valuable approaches that have their place. But skipping straight to these is the equivalent of thinking user research is about going to a shopping centre and asking people if they like look of the design. Or mistaking content designers for marketing copywriters.
In a top tasks survey, your users select the most important items to them from a long list. But if you jump straight to this without first agreeing with your stakeholders what those items actually mean, you risk wasting the opportunity of getting meaningful insights.
In the past, I have seen badly-designed top tasks surveys come to almost nothing. This happened because stakeholders couldn’t agree on how to interpret the results. That was because they thought the words used in the survey meant different things. They only discovered this after the study had been completed. The same pitfall can mar a card sort.
On one level, this is a classic problem of a multidisciplinary team lacking alignment. But specifically, it is a lack of alignment on what we mean.
That’s where ontology comes in.
The role of ontology
Ontology is a fancy-sounding word that can intimidate some people. Part of this is because many of our colleagues have not yet encountered it.
Jens Jorgenson recently wrote about the ontology layer of design, saying: “ontology might be the most important design term you’ve never heard of.”
Meanwhile, in It’s time to talk about ontology, Adriana Harper said:
Ontology might be the most important practice that content designers and strategists aren’t talking about enough (yet) — and in the age of AI, that’s becoming a real problem.
But you don’t need to be scared of the word. When we talk about ontology in information architecture, we are often simply talking about understanding what our things are and how they relate to each other.
Ontology is about understanding what things are
Information science borrowed ontology from philosophy, where it is the study of being. Modern applications of ontology can be traced back to Aristotle’s attempts to categorise all real-world things.
Astonishingly, ontology doesn’t even come up in the polar bear book. But it does get a few pages in Abby Covert’s accessible introduction to information architecture, How to Make Sense of Any Mess (available for free online). Abby Covert’s description of ontology is:
When we decide that a word or a concept holds a specific meaning in a specific context.
When we talk about a lack of alignment in our teams, we are often really talking about the need to develop a shared understanding of what things we are dealing with, and what we call them.
Going back to Jorge Arango, he describes this lack of alignment as ontological debt. As with technical debt, the longer we put off the work to deal with it, the harder and messier it is to finally sort it out.
More than “just semantics”
Semantics is closely related to ontology. The distinction between ontology and semantics is:
- Ontology is about identifying the things in our world, and how they are related — understanding the things we have.
- Semantics is about what we mean when we use a certain term — understanding what we call things.
Sometimes these activities are dismissed as a waste of time. People will often use the word “semantic” as a pejorative, as in: “That’s just semantics.”
But if we are being user centred, there is a major problem with being dismissive of semantics and ontology. Our incoherent terminology inevitably spills out into our systems, thereby actively making the user experience worse.
Ontological debt pushes our incoherence onto our users
For example, many systems are developed in piecemeal fashion. Even if these parts of the system are coherent within themselves (which is no guarantee), logical inconsistencies can emerge when the components are joined together.
For example, the same thing might be described with different labels.
Or, you might see the same labels being used to describe different things.
Internal project names can get unintentionally exposed to users like a label hanging out of your pants.
All this means that if we don’t untangle our own mess, we push that job onto our users.
If a user has to ask, “what’s the difference between a message, a post, a thread, and a page,” you’ve already lost them.”
Dealing with ontological debt
Adriana Harper, Jens Jorgenson and Allie Ofisher all describe broadly similar approaches to getting started on tackling your ontological debt:
- Gather your things (your objects, your entities, your nouns).
- Agree on what those things are called.
- Define what those terms mean.
- Identify the relationships between those things.
- Outline the actions that can be carried out with those things.
I felt my way through this sort of approach to tackling ontological debt recently at work. I was struck by how natural it was to adopt the building blocks of Sophia Prater’s object-oriented user experience (OOUX) approach to develop our shared understanding.
On this front, Allie Ofisher’s take on alignment is particularly useful given her expertise in OOUX.
We understand things in relation to other things
We tend to naturally define things in relation to other things. An Aristotelian approach is to define something in relation to its parent category, and what differentiates it from its siblings sharing that parent category.
For example:
- triangle
- A shape [parent category] with three sides [differentiating factor].
In our case, people suggested definitions containing phrases like:
Preferences are a type of Settings.
These are relationships between nested objects in OOUX.
Some of the definitions pertained to what people can do with them, such as:
Settings are modified by Users.
These are OOUX’s “calls to action” — the verbs that people can do to the nouns.
And in some cases they even defined things based on the attributes they have:
Account contains Name, Address, Date of birth.
Defining what things mean for real
Before we knew it, we were building a primitive form of a system map. This was effectively the beginnings of an ontology.
It describes our things, what we call them, how they relate to each other, and more. And because it is a collaborative activity, the alignment is getting baked in from the start.
This is a key reason why you cannot hand this job over to an AI tool. This work is not just about the final artefact. It’s about how we gain knowledge by building it together. It’s another example of how the activity of mapping is more important than the map itself.
Over time this can be developed into a more formal ontology if we need one.
This is the essence of information architecture. It is not just about designing a navigation system. The flaw of that thinking is that different channels can have fundamentally different capabilities and constraints.
The navigation system we need for our app might be different to the one we use on our website. The underlying logical structures needed to ensure chatbots and agentic AI to be more deterministic (truthful) is different still.
So our work is about understanding the underlying concepts and structures that will underpin the user experience of all of our channels.
This benefits team alignment. It benefits our users. It helps us efficiently deliver multichannel services. And it future-proofs our thinking.
That’s because we haven’t just designed a navigation system for a screen.
We have defined what each element of our system means for real.
Reposts
Likes