Photo by Eilis Garvey on Unsplash

Series: information architecture in digital products

Concepts, information architecture’s building blocks

It’s time for me to define what I mean by concept. I’ve dreaded this moment as much as you have. 😉

We use the word “concept” in design usually to mean “big idea” or “potential design direction.”

But I’m talking about something else here: the ideas that define a product.

Let’s take a step back for a moment. My premise here is that information architecture is more than navigation. It’s more than categorizing content. There’s utility in applying information architecture to products, apps, and transactional systems. (Yes, these things have content, but they differ from conventional content-driven sites that rely on IA to organize, structure, and facilitate findability.)

Until now, I’ve been talking about how product IA rests on a “structure of concepts”, but I’ve skirted defining concepts. (I should say at this point that there’s a vast body of work in cognitive science that studies concepts.)

A concept is, obviously, an idea. In information architecture for digital products, however, a concept is an idea that’s essential to the product, and that is important to people using the product. A product’s concepts derive from the the product’s purpose, and therefore exist regardless of whether the product does or not.

Some examples:

• In a customer relationship management systems, the essential ideas are “contact” and “relationship”. (Contacts and relationships underpin a CRM, but are also distinct and separate from the product.)
• In a project management system, the essential ideas are “project”, and “person”, and “task”.
• In a content management system, the essential idea is “content” and maybe “template” and “metadata”. I dunno. Content management systems are weird.

Concepts are the elements users should recognize in the product, even if they’re not explicit in the user interface. Absent these essential ideas, the product would be unrecognizable. They are existential, like parts of your own identity. You may not know that being from New York is part of my identity, but you might not recognize me as the same person if it were missing.

The Paradox of Concepts

I interviewed Jeremy Burton for my IA Lenses podcast. He said that every time he talks with a product team having difficulties, the problem stems from a poorly defined set of concepts. This struck me as deeply true, but also puzzling. If concepts are the essential elements of a product, how can there be a problem?

Just because you know what ideas are essential to a product does not mean you know anything about them. Think about the last time you were talking to a teammate about a complex idea only to realize that you each have been working with different definitions. “Wait, what do you mean by ‘customization’?” We don’t always ask existential questions about fundamental or essential concepts because we take them for granted.

If you’re designing a task management system, you might think “everyone knows what a task is”. That may be true, generally speaking. Everyone does know what a task is, at some level. But your product’s goals and your product’s particular area of task management, not to mention the people working on the product and the people meant to use the product all create a unique context. The context flavors our understanding of these essential concepts.

So, a concept is not just (as I defined above) an idea that’s essential to the product, but also an idea that’s been flavored by the context of your product. A product is paradoxically (a) defined by several essential ideas and (b) the context in which those ideas are defined.

Perhaps you’ve experienced this if you’ve tried the same kind of product from several different vendors. Task management in Trello looks different than task management in Jira, which looks different from task management in ToDoist. There are shared elements, sure, and most certainly shared language. But the differences are clear because the underlying essential ideas are defined differently, probably to meet different needs or to serve different purposes.

Another example of this is products that do different things with the same concept. Both calendar apps and event planning apps deal with the concept “Event.” Our brains are quite comfortable shifting between these two different conceptions, but an event from a calendar app can’t perfectly fit into an event planning app. Technology requires us to be far more literal about how these concepts are defined.

Relationships, Too

The concepts alone do not form the entirety of a product’s conceptual skeleton. Concepts are connected to each other. The connections also manifest in the user experience. For example, users need to see that tasks are connected to projects or people or milestones. But, we can’t make any assumptions about which concepts are connected and how they might be connected to each other.

So, we know the concepts and the relationships at a high level, as an abstraction. Doing design, however, means getting specific about these things:

• The specific definitions of a concept
• The nature of the relationships between concepts

How we define the concepts and how they are connected to each other are design decisions, architectural decisions. These decisions reverberate throughout the product. Moreover, the conceptual model you choose today for your product will enable or constrain how that product grows and evolves tomorrow.

Connections between concepts come in many flavors:

• Aspect: A is an aspect of B
• Affect: A has an effect on B
• Belonging: A is a part of B
• Capability: A is something B can do
• Causality: A produces B
• Describing: A describes B
• Sequence: A comes after B
• Transaction: A gives to B
• Version: A is a flavor of B

It may be difficult to free yourself from a hierarchical way of thinking, especially if you’re used to information architecture that focuses on categorization and navigation.

By freeing yourself to think about the variety of relationships between concepts, you can also see how your choices here need to be deliberate, and may not be self-evident. They need to be relevant to the product you’re designing: Your version of that thing.

More than Data

It’s tempting to turn every concept in the model into a data object — a bundle of data fields with predefined functions and points of interaction. Many concepts do become data objects, but you do your process a disservice by treating every concept as one. To say this differently, a map of concepts helps you understand the important ideas behind a product, but it’s up to you to interpret that map.

The design process entails interpreting the concepts into a tangible product, making decisions about how and to what extent a concept is manifest in the product. Like every design decision, deciding how the concept appears in the product is a trade-off:

• Very abstract ↔︎ Very concrete
• Lightweight ↔︎ Data rich
• Flexible ↔︎ Constrained

That is, in a task management system a concept like “task” can be very loosely defined — perhaps it’s just a name. In this way, it’s very abstract, and your team might say things like “anything can be a task.” That sounds appealing — fewer dependencies means it’s easier to build. But less structured implementations of a concept puts the burden on the people using the product — customers who have shelled out good money — to define what they mean when they say “task.”

At the other extreme, a task can be very formally defined, with metadata elements like category, due date, status, and others. The system is very opinionated about what a task is. Every element in the definition creates a new need for rules governing that field. I wish it could tell you that stricter definitions alleviates the burden on your customers. Instead what I’ve observed is that customers have to figure out how to map their own process to the product’s conception of the process.

Most systems end up somewhere in the middle, a bit of looseness and a bit of structure, especially for a product’s core concepts.

My hypothesis is that the trade-off between formal and loose is straightforward, but the implications of the decision hold infinite complexity.

Hard Questions, or What Does This Have to Do with Design?

By mapping out the product’s concepts and relationships between them, we are compelled to ask these existential questions. Answers to these questions — which requires debate among team members and a deep understanding of the business and the input of user research — further shape the model.

Ultimately, clarifying the concepts and their relationships helps visualize the overall map of the product, and then translate that map into an interface.

If design is a series of decisions that involve trade-offs, the map reveals the kinds of trade-offs we might need to make. Here are a few:

• Context: If you expose a concept, you must expose another one to provide context.

Example: in task management, you can’t show a list of tasks without showing what project they belong to.

• Definition: Exposing a concept requires you to expose others, which provide clarity.

Example: in task management, you can’t show a task without showing who it is assigned to (or that it is not yet assigned)

• Dependency: Making a change to the product related to one concept implies making a change related to another concept.

Example: in task management, if you change how the assignments are displayed, you may need to change how you display the task itself

• Constraint: You can’t make a change to a concept because it’s constrained by another concept.

Example: in task management, you may not be able to change the meaning of being “assigned to” a task because that would change the definition of tasks

Another way of thinking about this is that the product establishes a framework for engaging in a business process — invoicing, planning, contracting, whatever. Processes involve information and actors and rules, and those need to be translated to the product. In the old days, we would gather requirements, a painstaking approach to capturing all these moving parts. But mapping the concepts gives us something more: how everything fits together, what aspects are most central to the product, and where the product could grow in the future.

Eight Principles about Concepts

Here are the eight key points I hope you take away from this:

1. Products are made of concepts — big and small, formal and informal — that all capture the essence of the product’s purpose.
2. Modeling concepts compels you to ask existential questions, aligning with your team about what these words really mean.
3. Mapping relationships between concepts does not opens up new ways of thinking about how two ideas relate to each other.
4. Thinking about the concepts lets you think about how essential parts of the process will manifest (or not) in the product.
5. The main decision you must make is how strictly you define the concept’s implementation in the product.
6. Strict definitions likely require additional rules for governance.
7. Informal definitions of concepts likely require further planning to cover a wide range of use cases.
8. Not every concept becomes a data object. Look to the relationships to illuminate possible roles a concept plays in the user experience.