Series: information architecture in digital products
Product IA is hard to talk about
Theory: The information architecture of products happens at a higher level of abstraction than the IA of web sites, and is therefore harder to recognize, acknowledge, and discuss.
When I was a young philosophy major back in 1991, my social philosophy professor asked, “They say it takes one to know one. Does it?” Our essay was limited to two pages. Mine was terrible. Always define your terms, he wrote in the margin. That lesson has stuck with me these three decades.
- Information Architecture: The design of structures that frame a user’s experience of a digital space
- Structure: The set of concepts and relationships between them that are manifested in the product or site
- Products: Stand-alone device-based digital experiences that enable a discrete set of transactions and information exchange
- Web Sites: A screen-based digital experience largely centered on delivering consumable content (e.g. a marketing site to describe a product)
- Abstraction: The measure of how removed a concept is from its real-world counterpart
In my journey to describe product IA, I feel it’s necessary (though annoying) to distinguish it from content-driven IA, which is information architecture that’s largely concerned with wayfinding and navigation and categorization of content.
Information architecture has become so synonymous with navigation, most of our metaphors to talk about virtual structures use physical space as the comparison. This isn’t wrong, but it’s hopelessly incomplete.
There are decisions that need to be made about the structure of a digital domain that have no parallel to physical space. Here are some other metaphors I’ve relied on:
- Family: To convey the ideas of belonging and inheritance between digital entities
- Lifecycle: To convey the idea that a digital thing isn’t static, but changes over time, and therefore needs a framework for capturing and communicating that change
- Environment: To convey the idea that the same thing can look and act differently in different contexts (I guess this is spatial, but it’s not wayfinding)
- Cooking: To convey the idea that things exist in different states and multiple users may be involved in developing them
- Board Games: To convey the idea that there are designed rules that govern how things may interact with each other
- Super Heroes: To convey the idea that with great power comes great responsibility (but almost no accountability 🤔 )
That said, I’ve tried to strip even these metaphors from my thinking and my collaborations. Again, they tend to highlight some aspects of information architecture while obscuring others. This is perhaps because creating structures in digital domains requires us to think at higher levels of abstraction.
Visible structures
Let’s say you’re looking at a product. How many structures are you looking at? That is, how many parts of the screen represent deliberately designed relationships.
The screen itself has a layout. The elements of the screen are arranged, some getting more space, some further up the page. This is a structure: entities (elements of the user interface) with relationships expressed through space and placement.
The screen includes a navigation menu, a means for users to move to different aspects of the product. This is another very visible structure, the
The screen hopefully shows context, a way for users to discern how what they’re looking at relates to other aspects of the product. We sometimes use a spatial metaphor, saying that the context shows users “where” they are. (I find this increasingly problematic as more use of mobile devices means distinguishing between their virtual context and their physical context.)
Invisible structures
But now it gets weird. I’ll use a calendar as an example, but maybe you can go through the same exercise with your favorite product.
Elements on the screen represent entities. The obvious ones here are events. “Event” is a concept, and there’s a lot of data associated with an event. Some of that metadata is useful for displaying the event on the screen — the size and color and placement of the box, for example. Other metadata determines the behavior of the event, like whether it repeats. Other metadata triggers other actions, like reminders. Still other metadata supports collaborating with others, like who is invited to the event and their relative status (required or optional).
In my example, you can see that there’s a copy of an event (our dog training class on Wednesday) which appears twice. This is a copy, but the events are also connected, so a change to one will potentially make a change to the other. That’s a structure: two distinct entities with a relationship, but one that’s not easily explained with a real-world metaphor.
There are also invitations, kind of an off-shoot of an event. It appears on the calendar in a different state, a sort of subjunctive mood expressed through UI. The invitation may be a distinct entity, or may just be a flavor of event — depends how the product team designed it.
Although this whole product is a calendar, it really is a container for many calendars. You can see my family has taken full advantage of that. The list on the left displays all our calendars, and Calendar is a distinct entity type. It is itself a container of events. A calendar has metadata, like who has access to it. It also has default settings for events that are put in it, so events inherit qualities by virtue of being put on a particular calendar.
We have a convenient real-world analog for a calendar product… an actual paper calendar. But moving it to digital forces us to ask existential and semantic questions like what do we mean by event? and what are the different types of events? and what is a calendar, really?
These questions aren’t the sole domain of information architecture, but information architecture offers a perspective that can inform the answers.
Interlude: More hard questions
As we build a concept model to explain these distinctions, we have to ask even harder questions. What do we call people who do not “own” the calendar but who have access to it? If we call them “subscribers,” what exactly are they subscribing to? If users create an event, then duplicate it, does the duplicate belong to the original in a parent-child relationship? Or are they distinct entities? If users make changes to an event, do we need to keep copies of the original version of the event? If users move an event from one calendar to another, does it change the event if the new calendar has different defaults?
I mean, that’s just me sitting here thinking about it for a couple minutes. There are many many questions like this this. Like the existential questions, their answers aren’t entirely in the domain information architecture, but they are informed by a structural perspective. And the answers have implications for the underlying structure that will resonate in other areas of the product.
Abstract structures
Google Calendar allows me to add other things to a calendar, like focus time, or working location. Are these flavors of event, or are they new entities entirely? I’m hopeful the team spent some time thinking about this. Their addition to the underlying structure no doubt had a ripple effect to the existing entities in the structure — calendar, event, invitation.
The product also offers appointment schedules, a way for users to invite other people to add events to their calendar. In a sense, this is a calendar within a calendar — yet another container, this one of potential events. Those events are authored by other people, but they appear on your calendar. Are you the owner of those events?
These are all questions and considerations that require answers at a higher level of abstraction than layout, navigation, and context. We are making deliberate decisions about the entities that make up the digital domain of “calendaring,” as well as how they relate to each other. We’re creating new types of entities that emulate real-world processes but for which we don’t have a good real-world analogs.
The decisions made for Google Calendar may not be the same decisions made by the team at a competing product.
Toward (but never reaching) a language of Product IA
The field has not developed great language to talk about these higher level considerations. Conversations about the entities in a digital product and the relationships between them are complex and nuanced. These conversations are necessary to tease out dependencies and implications, which are required to ensure the team is aligned in the product vision. The vision may entail more than the structure of the product, but realizing the vision may be compromised if the vision is not also reflected in the structure.
And so, there’s a “back-end IA,” as Nathan Curtis suggested. A deliberate design of the structure underpinning a product. Unlike “front-end IA,” this structure may not be visible. Its lack of visibility makes it difficult to discuss. It requires us thinking about categories beyond categories, about dimensions of time and beyond, and about relationships that border on paradoxical.
I don’t know if my journey into Product IA will yield a meaningful language — perhaps it’s not possible without getting impossibly technical. What I’m curious about is recurring themes — like time and collaboration and rules — that exert pressure on the structure of digital products. Perhaps through these themes, and the exploration of their implied structural elements, I’ll discover a viable language for discussing them. Or perhaps I’ll discover that such a language can never exist, that complexity and specificity and creativity demand that we continue to reinvent as we go.
