Series: information architecture in digital products
Do digital products have information architecture?
Information architecture is commonly associated with navigation: how people get from one area to another within a digital space.
But information architecture deals not just with navigation, but also the underlying conceptual structure of a product. Let’s break that down:
- Underlying: The structure may not be visible, but guides how the product looks and feels.
- Conceptual: The structure deals with abstract representations of real-world things — the platonic forms, if that’s your bag.
- Structure: And by structure we mean the nature of the concepts and how they fit together and relate to each other.
Think of a digital product you use every day and ask yourself what the component parts are. Some are easier than others. Some manifest those parts in the navigation, but others don’t reveal them so readily.
Let’s take the time-tracking product Harvest. I use this every day to track my hours, which the company then uses to invoice our customers. It’s also useful to me as a manager to understand how much time my teams spend on their tasks.
To be clear, I don’t work for the company Harvest, so the perspective I offer below is that of a user. My speculation may be way off.
The main navigation for Harvest includes these items:
- Time
- Expenses
- Projects
- Team
- Reports
- Manage
Does this navigation accurately reflect the underlying structure of Harvest?
It does in part.
- There are time entries: the amount of time I spend on a particular task for a particular project.
- Harvest also allows me to capture expenses, again by project.
- The main organizing element for Harvest are projects, which capture the time entries and the expenses.
So far so good. The navigation reflects three core elements of the Harvest underlying conceptual structure. Let’s look at the remaining two nouns: Team and Reports.
There is no element team that I can create and manipulate, like I can with time entries, expenses, and projects. For each of those, I can create an instance, edit and delete it. I can’t create a team. Instead, I can add or invite people to Harvest. All of them are listed under team. Team is a convenient term, but it doesn’t reflect any element of the underlying structure.
Like team, there is no report element that I can create. Instead, through Reports I can use filtering and searching tools to display the underlying data (time entries) in different ways. But I have no means of saving those reports as distinct instances.
So the navigation consists of five nouns (Time, Expenses, Projects, Team, Reports) and only three of them reflect elements in the underlying conceptual structure.
Moreover, there are elements of the underlying conceptual structure that are not reflected in the navigation: clients and tasks. Again, I can create individual instances of these elements. I can assign important metadata to them. Creating a task allows me to set a type for that task, as well as a bill rate just for that task. There is a lot of power in how that concept is realized in the product.
Time tracking is relatively simple (though the Harvest team might disagree with me), so the underlying conceptual structure is also pretty simple. That said, the Harvest team made — and stuck with — clear choices. For example, I can’t create groupings of people independent of the projects they’re assigned to — a team. I can’t apply a bunch of search parameters and save that as a distinct report.
Here are three other choices the team made (again, I’m guessing here, but these seem like deliberate decisions):
- Tasks are shared across projects. If I want to create a task unique to a project, I still add it to the overall library of tasks. That task is available to be added to any project, even if it’s specific to just one of them.
- People are assigned to projects, not clients. If I use the same group of people on a client time and again, I have to add them to each new project for that client.
- Every time entry must have an associated task. I can’t simply bill time to a project irrespective of a task. Even if I created a single tasks and billed everything to it, the integrity of the underlying model is not violated.
These are all structural decisions about whether an element exists, and if it does, how it relates to the other elements.
None of this is reflected in the navigation, but it is reflected in the functionality of the product. I’ve internalized this underlying conceptual structure, so as a user I understand the kinds of information that’s captured, what functionality is available to me, and (of course) where I can go to make changes.
I love Harvest because it is straightforward and simple and, frankly, opinionated about how these things work. I believe the Harvest team was deliberate about these choices.
Many a product team is not deliberate about how they model the underlying conceptual structure. The concepts may appear in the product, but their connections don’t make sense. Or maybe the concepts are not fully realized. Perhaps you’ve experienced a product like this. What I’ve seen on product teams is one of three different situations:
1. They do not pay attention to the information architecture
More often than not, teams focus on designing screens without thinking about how all the pieces fit together. I once coached a team that put everything in a left-column navigation menu. I mean everything. Without a sense of how all the pieces fit together, they simply provided access to it all. In one long, unwieldy, chaotic list.
2. They design the underlying conceptual structure with a single approach in mind
Some products are meant to serve a variety of organizations, each of which has slightly different approaches to how the process works. Imagine if Harvest based their work solely on an organization that didn’t require naming a task to record time. I once consulted with a team that designed a product based on their original need. As they tried to roll it out to other organizations, they found the underlying conceptual structure was too stringent for supporting them.
3. They attempt to connect all the concepts
On the flip side, it’s tempting to figure out all the different ways the concepts in an underlying conceptual structure are connected. Rather than be opinionated about which connections matter, the team errs on the side of incorporating all the possible connections between concepts. The team I mentioned previously sought to fix their skewed model by updating the experience to accommodate all the possible connections. This approach ultimately created more confusion and frustration as we found ourselves having to support every connection on every screen, and anticipate changes echoing across the network of connections.
Not just navigation
Though information architecture is largely equated with navigation, it entails much more of the user experience. The deliberate application of information architecture produces an underlying conceptual structure. This conceptual model can in turn guide the structure of the experience itself — how users interact with the elements in the product, how the elements relate to each other, and how changes to those elements affect those around them.
