Series: information architecture in digital products
Enterprise products, an information architect’s perspective
In the realm of digital products, some cater specifically to the enterprise. As I continue my exploration of Product IA, I’ll focus on these kinds of products because of their acute information architecture challenges.
Let’s first define what we mean by “enterprise products.” There are at least three features of enterprise products that distinguish them from other flavors of digital product:
- Targeted Purpose: Enterprise products serve a specific business function, usually to support or enhance an existing process.
- Multiple Tenants: Enterprise products are “software as a service,” so one client of the product uses an instance of the product that is the same as (or very similar to) other instances.
- Striated Users: Enterprise products rely on providing interrelated functions for different users across the enterprise.
This isn’t to say that all enterprise products are good at these three things — only that they’re the distinguishing features of them.
A SaaS ticketing system offers a good example:
- Targeted Purpose: It manages incoming requests.
- Multiple Tenants: Different organizations use the same ticketing system to deal with different kinds of requests; Each organization’s instance of the ticketing system relies on shared infrastructure, but is walled off from other instances.
- Striated Users: Some users submit requests, some handle requests, some oversee, etc.; there are multiple types of user, and they all relate to the process differently.
Compare this to a consumer digital product, like an exercise tracker:
- ✅ Targeted purpose: It captures and aggregates data about exercise.
- ❌ Multiple tenants: Everyone uses the same instance of the product.
- ❌ Striated users: Despite tiers of access (paid vs. free), everyone is using the product in largely the same way.
Yes, there could be a white label exercise tracker app that different hardware companies use. (Multiple tenants)
Yes, there could be an exercise tracker where some users are trainers or health professionals and others are patients. (Striated users)
But, most consumer products don’t do all three of these things.
These three features of enterprise products exert pressure on the product’s design, and specifically the information architecture.
Targeted Purpose
A product’s purpose establishes the essential components of the product. If I say “time tracking” you know the product is going to be able to capture number of hours I spend on a task on a project. That understanding gives us three concepts — hours, tasks, and projects — the product will need to incorporate.
Understanding the purpose gives us a starting point. Usually this purpose is related to a business process, like invoicing clients based on hours accrued. A defined purpose, driven by a named business process, exerts pressure on the information architecture because these things come with expectations. You can’t do a time-tracking product without capturing time. Beyond the fundamental types of information, a process comes with expectations about how people will interact with the data. As product designers, we cannot escape those assumptions.
Multiple Tenants
Even if the targeted purpose gives us a sketch of how the product needs to work, every organization implements the process a bit differently. One organization may track time in terms of fractional days and another in terms of decimal hours and another in terms of minutes. One may assign a rate based on the individual and another by a person’s role and another by the task.
Determining an appropriate information architecture for these kinds of products means defining an underlying structure that has sufficient “give” to accommodate these variations. It means working with the product manager to define a vision for the product that establishes the scope of that flexibility — what aspects different clients will be forced to share and which will be unique.
Having multiple tenants exerts pressure on the information architecture because we have to design a one-size-fits-all structure. You can be rigid, sure. One way products thrive is that they are opinionated and assertive about the structure of their user experience. But being too restrictive risks limiting the range of use cases the product can support. On the other hand, creating a structure with a lot of flexibility produces its own set of challenges. The product loses coherence when it prioritizes flexibility to accommodate a wide range of use cases. It puts the onus on users to configure and customize the product for their context.
Striated Users
Processes supported by enterprise products almost always have at least two roles: the people who supply the data and the people who use the data. Enterprise products support processes, and there are people who participate in the process and people who benefit from the process. Contributor and receiver. Both expect the product to accommodate their individual perspectives.
To truly understand the underlying information model, we need to appreciate the distinct needs of each of these users, and their relationship to the data. We can’t look at the data coming into the product the same way we imagine it going out. Each type of users interacts with the data differently. In the user experience, this means providing access to the same underlying structure but in different ways.
Building access for different types of users means, yes, discovering how each type needs to use the information to design their screens most effectively. But it also means creating structures that govern access privileges (who gets to see what) and collaboration (how people work together on the data). Business processes may impose strong requirements on how these different user groups make use of the information and interact with each other.
Designing enterprise products means doing information architecture with at least three constraints out of the gate:
- The product’s purpose defines expectations. The expectations establish the core concepts and interactions the product must support. Moreover, they describe how users are most likely to engage with the product.
- The product’s multiple tenants requires focus on flexibility — neither too much nor too little. The flexibility defines the range of contexts the product can support. Even the simplest process may be implemented differently in different organizations.
- And the product’s variety of user types demands looking at the data from different perspectives. The perspectives determine the various ways in which the product will need to collect and present data. Moreover, the structure needs to support the ways in which users have access to, and collaborate on, the data.
Beyond all these pressures is something my friend Irena reminded me of. The data and information inside an enterprise product is (generally speaking) an order of magnitude more complex than your average consumer product. Dealing with financial information or logistics or technical performance data puts tremendous pressure on the product’s underlying structure.
And now we have multiple vectors: expectations, flexibility, perspectives, and complexity. The combination demands a structure, a way of organizing product’s underlying concepts to deal with these pressures productively. A productive structure isn’t self-evident. Nor is it easy to determine whether it’s “right” or “wrong.” Instead, it’s the work of the product team to design the structure, acknowledging the pressures applied to it. They must be deliberate about their product’s structural decisions because they are aware of these pressures, and many others, and how they manifest in the context of their particular product.
