Five Recurring Themes in Product Information Architecture

Information architecture (IA) is usually explained as an aspect of designing content, but I've been working on a series of articles exploring IA as a crucial aspect of designing products. IA is not just for content-heavy web sites! These articles describe the role of information architecture in designing transactional systems that support the enterprise.

To recap:

• In my first article, I justified applying information architecture to digital products.
• Then, I highlighted what makes it so hard to talk about IA for products.
• After that, I took on defining the most challenging context for doing product IA: enterprise products.
• Most recently, I got theoretical and described a framework for the conceptual underpinning of digital products.

But we're just getting started. After working on many different digital products, and confronting the structural challenges behind them, I've found five recurring themes. Each theme is a need or expectation that arises on enterprise products. Not every theme appears in every product, but every product deals with at least one theme.

I call them "themes" because these are recurring motifs or ideas. Many enterprise products, for example, deal with business rules. While business rules look completely different in different contexts and in different products, there are some patterns we can apply to deal with them.

This is my hypothesis: Enterprise products deal with one or more common themes that have consistent considerations regardless of where or how they appear in the product.

And my aspiration: Naming these themes and revealing their underlying structures moves us toward a theoretical foundation for product information architecture.

And the implication, if these are true: In designing the information architecture of an enterprise product, there are design patterns we can rely on to help address the associated challenges more completely.

Patterns in IA

It's useful to identify recurring patterns in design, because it means that we can develop a systematic approach to common challenges. The pattern becomes part of the vernacular of the practice. The vernacular forms the foundation upon which we can build the practice.

There are patterns in information architecture, but they don't get the same attention that design patterns get. If I said, for example, "task-based navigation," you'd recognize that as a pattern for designing menus. I've always thought of patterns as starting points – stepping stones to a specific solution.

I'd be hard-pressed to say that patterns in IA have evolved much since the advent of the practice in the late 90s. But I keep doing IA for digital products, and I keep running into these five same challenges over and over. I'm hopeful that the field can begin to build a set of common patterns to address them.

• Status
• Containers
• Rules
• Time
• People

Each theme warrants at least a dedicated article, but I wanted to take a moment to introduce them.

Status

Many enterprise products include the idea of "status," a label applied to an important element in the system to indicate its current state. Some examples:

• Timesheets can be submitted or pending or approved
• Expenses can likewise be submitted or pending or approved
• Content in a content management system can be draft or published
• A person in an event management application can be invited or declined or accepted

The "current state" of something depends on the purpose of the product, of course, but also how the team chooses to interpret the concepts in the product.

We sometimes conceive of status as a thing's position along a workflow or process. Sometimes we conceive of it in terms of "**doneness**" or "readiness". Sometimes it describes where a thing ends up in the process, like a college application that's been accepted or rejected or wait-listed.

Moreover, many products rely on status to enforce rules built into the product.

Most products get status wrong, for the simple reason that reality is messy. The defined process doesn't always hold true. The expected order of states is easily foiled by the more-than-occasional exception. The rules built around the status need to be broken more often than they are enforced.

Containers

While information architecture for content sites puts content into categories – a category being a container for content –?I'm thinking of it a bit differently here. Containers in digital products are ways of collecting together entities in the system.

• A contact management system may allow users to group contacts together into lists –?a user-defined container
• The same contact management system may allow users to create a rule (like a filter) to put people into a list that's updated whenever a new contact matches the rule – a dynamic container
• A project management system may treat a project as a container that holds people and tasks – an entity as container

The different ways we allow users to group things together only scratch the surface of the challenges with containers.

• Strictness: Are containers picky or opinionated about what they can contain?
• Containers as entities: Are containers entities in and of themselves with metadata attached?
• Entities as containers: Conversely, are elements within the system meaningful containers themselves?
• Nesting containers: Can containers contain other containers?
• Container vs. label: Do we conceive of the container as holding its contents, or merely a label we apply to some entities?

On the surface, these questions look a little navel-gazey. Surely you don't need to answer them to get a product off the ground...? I say you do because these kinds of decisions will be made implicitly if you don't take the time to answer them explicitly. The team designs the product based on those implicit assumptions. These assumptions reverberate throughout the product for the rest of its life, and you may discover that they aren't appropriate.

Just recently a client indicated that in first developing their product they assumed a crucial element of the product was not a container. With now a better understanding of the underlying model, they have to refactor a lot of the product's codebase to accommodate desired changes.

Rules

Rules are fundamental to enterprise products. Everything we're designing in digital products comes down to rules. Rules establish what users can and cannot do with the data in a product.

Rules come in many flavors. Here are a few typical ones:

• Conditional: Perform a function if a condition is true. Like, if a person's application is approved, set their license status to "active".
• Enforcement: Prevent users from doing certain things. Like, users cannot submit their application if they have specified fewer than three references.
• Ontological: Define what's necessary for something to exist. Like, contacts must have a first name and a last name.

Rules are structural – and therefore relevant to information architecture – because no system is static. Even when we model a system in terms of its entities and relationships, we understand that the elements of the system move with respect to each other. Rules define these movements. They indicate how a concept flexes to accommodate a variety of entities. They indicate how an entity reacts when another undergoes a change.

One way product teams get this wrong is they want to model all the rules from a business process in the product. Perhaps they believe that a product can't be useful or valuable unless it addresses every aspect of the process. As powerful as computers are human brains remain better at recognizing and understanding exceptions and multivariate situations. But in reality, some rule enforcement is best left to the users of the system.

Time

Now things are going to get a little weird.

Status and containers and rules are relatively concrete things we can envision. These next two themes – time and people – are a little harder to wrap our heads around.

Enterprise digital products support processes – collaborative efforts that occur over time. Whether a process is measured in minutes or months, or more abstractly in stages of completion, it is never divorced from time. Every process makes use of the lens of time. People involved in the process want to know when they need to become involved. Stakeholders want to know how long the process takes, or how much time has been spent so far. We measure the outcomes of a process against the time it took. As a process effects change in the world, we understand the scale of the change and the effort it took as a function of time.

For the products that support processes, time can be tricky. As time progresses, the data in the product changes. It either literally changes: a data element is updated by a person or rule. Or its quality changes: good data goes bad when it isn't kept up to date.

Many modern processes depend on participants knowing how a thing evolves over time, or how a thing might look in the future, or recalling how it looked in a previous iteration. Many processes depend on participants having a more holistic view of a thing relative to its lifecycle, where snapshots are insufficient for making decisions.

It's difficult to model time in digital products, and humans are innately great at this. We can look at a thing and understand it as the sum of all its previous iterations and future iterations. We can understand it as a point moving in time.

These lifecycles aren't often reflected in digital products. The lifecycle of an entity may seem irrelevant or unimportant compared to other features. But as the product evolves, users will feel its absence more acutely. Indeed, as product designers we hope our users rely on our products to support the entire lifecycle of their processes. An event management service likely aspires to supporting an event from its initial inception until long after the last person has left the venue. Ignoring time as a crucial structural element today means finding yourself constrained tomorrow. You can't go from still picture to video overnight.

People

No product conception is complete without understanding how people fit in. This theme is not about how people appear as entities in the system –?for example as contacts. Instead I'm referring to how the product mediates interactions between the people participating in the process – how they need to work together through the product. Every enterprise product is by definition "multiplayer," but not every enterprise product is built from the ground up to accommodate this.

Layered on top of the product's basic functionality, then, is functionality that supports collaboration. If multiple people can make changes to underlying data, there must be mechanisms for capturing who did what when. That is, as people use the product, changes they make must be captured – who made it, what they did, and when they did it. Most people involved in a process also hope that the product will ask someone why they made the change they did, a datapoint not easily discerned.

In practice, however, an activity log barely addresses the challenges of collaboration. A product supports decision-making, but most of the important decisions are made outside the product – in conference rooms and on phone calls. They rely on data to inform their decisions, and act on those decisions whether or not they're captured in the product. On most products I work on, the screens for data entry and for displaying data are not optimized for multiple people operating on the data in concert.

Structure under pressure

Designing a structure for an enterprise product means subjecting it to the pressures of reality. These five themes come from the variety of forces applied to an enterprise product. By solving for these forces, we can see some of the realities facing product design.

1. Dealing with status reminds us that reality is messy.
2. Making sense of containers reminds us that assumptions made today reverberate throughout the product forever.
3. Accommodating the rules of a process in a product suggests that a product can't assume responsibility for every aspect of a process.
4. Modeling time and lifecycle reminds us that humans are better at interpreting complexity than computers are.
5. Finally, designing products for people in an enterprise reminds us that making decisions is inherently collaborative.

Toward an information architecture of products

Since the Polar Bear book first came out in 1999, information architecture has largely been concerned with content spaces – classification, tagging, wayfinding, search. This isn't to say that information architects have not been working on products – we have. You can see this in documentation that has been around for decades: concept models and flow charts, among others. These two documents reveal a focus on a level of abstraction beyond navigation categories (in concept models) and on movement that isn't about wayfinding (in flow charts).

But the field's efforts to be relevant in product design seemed to stall out here, perhaps because product IA happens at a higher level of abstraction. That combines with the industry's slow-burning rejection of IA as a relevant practice to form a perfect storm. The destruction is revealed in the products themselves, a wasteland of poorly structured and planned digital experiences. Where there is success –?and I know there are many talented IAs and designers working on enterprise products – they are behind the closed doors of the enterprise. The field as a whole has not benefitted from their efforts.

Building the practice requires developing a library of patterns for dealing with common structural challenges. This in turn requires understanding those challenges – what I think of as the pressures applied to the design of a structure. We have to understand what forces shape the structure, and put stress on it, so that we may design the structures to withstand them. I've characterized these forces as recurring themes, ideas that come up time and again in designing enterprise products. This overview of the themes offers a glimpse of the complexity behind each one but there is more to be said about them. Stay tuned.