Series: information architecture in digital products

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.

Concepts, information architecture’s building blocks was originally published in EightShapes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Series: information architecture in digital products

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.

Enterprise products, an information architect’s perspective was originally published in EightShapes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Series: information architecture in digital products

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.

Product IA is hard to talk about was originally published in EightShapes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Series: information architecture in digital products

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.

Do digital products have information architecture? was originally published in EightShapes on Medium, where people are continuing the conversation by highlighting and responding to this story.

A new project has me thinking about how digital design has changed over the decades. The shifts I’m thinking about aren’t merely new techniques. They aren’t the occasional yet inevitable calls for eliminating wireframes or personas. Instead they are fundamental changes in how design happens. They are paradigm shifts.

One working definition of design I like to use is that design is a set of perspectives we bring to bear to learn about the world and the people in it. Product teams use a variety of perspectives — like utility and usability and monetization and feasibility, among others — to look at the design problem and its potential solutions. Design needs all those perspectives to produce the best possible solution. Miss a perspective, and risk missing out on an angle that would help you either fully understand the problem or evaluate a solution.

A UI designer and a user researcher serve two different functions on a team, yes, but they also bring two different perspectives. They look at the problem differently. They look at potential solutions differently. The ultimate output of the team is better because it incorporates their different perspectives. Although there are costs to collaboration, insufficient perspectives from diverse team members incurs long-term costs to expand or evolve the product’s capabilities.

Three drivers of change

A paradigm shift happens when an event (or series of events) reveals that a crucial perspective has been missing from design all along. There are three kinds of circumstances I can think of that trigger a paradigm shift.

Harm

One reason a product might cause harm is because no one thought to look at the use of the product from that perspective. Until now, the design process lacked an input that would have highlighted the potential for harm. The safety measures in cars and buildings speak to this. Collision protection and fire suppression measures came about because first there were numerous events and second because there was a push to design for these possibilities.

In the world of digital product design, accessibility is one such paradigm shift. Though one could argue that the shifting is still happening, it became clear in the early days of the web that the technology excluded large swaths of the population. Exclusion is harm. Therefore, the industry took steps to introduce accessibility — really, a new perspective — into the design process.

Accessibility, when done well, isn’t just a checklist of things to fix in your page designs. It’s a new way of looking at problems. It’s not just about color contrast or whatever, but instead making fundamental design decisions about how the product’s content or features can be used by everyone without compromise.

Social Change

Another set of circumstances that triggers a paradigm shift in design is change in society as a whole. The public’s increasing (yet still painfully slow) attention to climate has vehicle manufacturers adapting their design processes to incorporate alternative fuel sources. The increased demand, based on a change in how people view their impact on the ecosystem, compels a new perspective in designing vehicles.

In the digital world, today’s greater emphasis on inclusivity and diversity has the design community (parts of it anyway) thinking about how their processes and techniques have disenfranchised so many people. You can see hints of this: stock photography incorporating greater diversity in its subject matter, for example. But beyond these hints, the user experience design community is being challenged to draw into the process perspectives from a greater diversity of experiences and backgrounds. Today’s heated debate is tomorrow’s paradigm shift.

New Technology

The other thing that triggers a paradigm shift in design is new technology. The most obvious case here is that we need to design products for that technology. The non-digital example that comes to mind is elevators. When I was a kid in lower Manhattan, my dad loved pointing out the Flatiron building to me, New York’s first skyscraper. “What did they need to invent to have tall buildings?” he would ask. With elevators, architects and engineers brought a new perspective to their design process.

In the digital space, the iPhone is a clear example. We went from point and click interfaces to touch interfaces overnight. The paradigm shift, however, was responsive design. Understanding that the digital products and content we designed might occupy vastly different screen sizes forced us to think differently about how we went about designing them.

A more recent technological change is putting design tools in the cloud. Think back even to just a few years ago when you would design in one tool and present in another tool, when people had to comment not on the actual design, but a PDF of your design documentation. Don’t get me started on managing multiple designers working on a file together, or versioning your design files. These concerns have largely evaporated thanks to Figma’s use of the cloud. We think about the design process differently now, thanks to this new technology.

Nothing is a silo

Perhaps it doesn’t need saying, but I’ll say it anyway. These three types of events are not mutually exclusive. Indeed a paradigm shift may only come about after several events have occurred. It’s not lost on me that you can’t talk about the social change of inclusion without also talking about the systemic harm on minority communities. New technologies, while encouraging us to explore new possibilities, often come with new applications that cause harm. Now that we have a better understanding of the psychological harm caused by social media, for example, we’ve got a new perspective to bring to bear in the design process.

Adapting to change

Let’s consider how design communities have embraced change. Or, more accurately, engage with these changes. All paradigm shifts represent injecting new perspectives into the design process — whether that perspective deals with safety or inclusion or something else. Any change to a process brings discomfort. But the circumstances that call attention to the shift seem to have an impact on the community’s willingness to embrace it. How we come aware of the need affects our enthusiasm for addressing it.

Responsive design and Figma were largely met with enthusiasm, even excitement. These technological changes got us revved up about design again, injecting not just new perspectives on how to work, but also new energy about doing design.

Paradigm shifts stemming from harm or social change largely do not produce such enthusiasm. These shifts are generally felt as burdensome. Despite years (decades!) of trying to incorporate accessibility perspectives into our design processes, many teams still treat accessibility as a checklist or afterthought. Compare this to responsive design, a change that happened practically overnight and with nary a complaint. The paradigm shifts initiated by harm and social change are usually met with resistance, even rejection.

It would be easy to chalk this up to new technologies being “cool” and the rest not, but it’s hard to reconcile that with the idea that all these changes come down to the same thing — a new perspective. But rather than relish all new perspectives as valuable and interesting changes to the design process, we characterize some as more of a burden than others.

Recognizing reluctance

If you’ve lived through any of these paradigm shifts, you know the standard array of excuses people use to resist change. Here are four that I hear about accessibility to this day:

Minimizing: Some folks claim that the new perspective can be addressed through a simple fix or small change to the process. They might claim that in some instances it’s not even relevant. Accessibility checklists and the excuse that it’s not necessary for some kinds of web applications persist to this day.

Maximizing: On the flip side, some claim that the perspective reveals a problem that’s too big or too expensive to solve. Accessibility naysayers might say that improving accessibility would require drastic changes that are cost-prohibitive. Systemic harm to minority communities is also frequently painted this way — the problem is too big for one team to solve on its own.

Myths: Some paradigm shifts come with myths that resistant designers use to argue against making a change. One accessibility myth I’ve heard is that making a product accessible will compromise the overall experience.

Not My Problem: Paradigm shifts often come with people who have thought deeply about the new perspective. While these experts help evangelize and elevate the shift, they also provide a convenient excuse for teams who say, “We can’t do this ourselves, we need an expert.” Consulting with an expert is but one strategy among many for bringing an accessibility perspective to your process.

Baby steps

I use the term paradigm shift on purpose. In design, the shifts may not seem quite as revolutionary as they are in science, but in fact injecting a new perspective into the design process is revolutionary. It is a big change: a new way of doing the work. Responsive design isn’t just designing for smaller screens: it completely upended our approach to designing digital products and web sites.

And yet, at the individual level change is hard. The inertia may come from many different places — ignorance, fear, frustration, exhaustion, apathy — but ultimately designers who do not adapt will find themselves left behind. Even accessibility — a perspective that isn’t yet perfectly embedded in our processes — is widely known and understood outside design. Our clients and stakeholders ask about it, and increasingly understand its relevance and importance.

One way to make change is to start small. Do one small thing differently than you’ve done before to incorporate this new perspective. Perhaps in presenting design concepts you highlight how you considered this perspective. Perhaps in doing user research, you include an extra question or two. If you’ve got the time and a willing team, perhaps you do a 1-hour workshop to help others take on the new perspective, at least for a moment. A small change, you might not need to justify to the powers that be. They won’t ask you to justify an additional question on a user research script. You can get away with a one-hour meeting. And who knows? One small step can create an appetite for additional small steps.

You won’t become an accessibility or inclusivity powerhouse overnight. But you’re also playing a long game. When it comes to change, you can’t make a complete change on your current project. Every project is a chance for incremental change, an opportunity to learn a little bit more about what it takes to bring a new perspective to bear in the design process. And small incremental changes, small bits of accumulated experience, all add up to a big change.

The Structure of Digital Design Revolutions was originally published in EightShapes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Scott Kubie wrote 21 thoughts on information architecture, perhaps because he’s too modest to call them truths about information architecture. Scott’s methodical approach to understanding and explaining information architecture appeals to me as a mentor, educator, consultant, and of course information architect.

But I’m also a philosopher, and I believe the best learning happens in dialog, a give and take, expanding and expounding on these thoughts. So I’ve added some of my own… let’s call them annotations. I’ll leave it up to you to decide whether they are true or not.

You can find his original piece on his blog. Scott’s thoughts are repeated here in boldface, with permission, and my thoughts follow in plain text.

SK: Information architecture is, primarily, a design discipline and area of professional practice.

DB: Like its namesake architecture, information architecture deals with the design of structures. In digital spaces, however, those structures can be abstract, and are often not user-facing. I appreciate starting with the foundation of design. Design is intentional and evidence-based and thrives on multiple perspectives, as does information architecture.

Information architecture is not a single specific deliverable for your project any more than the “design” is a single specific deliverable.

Increasingly, there are few formal deliverables for information architecture. My work as an information architect takes place largely in spreadsheets and collaboration boards like Miro or FigJam. Artifacts created during the information architecture process frequently help designers think through abstract problems and draw other team members into the design process.

It’s often more useful to talk about what information architects do and focus on than to debate what it “is” .

Let’s take that a step further and talk about what aspects of the user experience information architects think about — their scope or focus. Doing information architecture means paying attention to the structure of the user experience, making deliberate decisions about the virtual spaces users will occupy and interact with in using the product. In complex information spaces, we pay attention to helping users know where they are within that virtual space and signaling where they can go. We think about how the system provides “safe” options if they find themselves confused due to being “lost”. In transactional flows, we pay attention to how we set their expectations about the journey they’re about to undertake, and how we signal how much further they have to go. We think about how to collect information necessary to make a transaction, and how to structure the information collected in a way that will be most useful to the people on the other end.

Information architects are primarily concerned with the conceptual integrity of information systems.

Yes, and… information architecture in practice means recognizing that reality is messy. If our analysis is learning about a domain to understand its underlying concepts, our synthesis is translating those underlying concepts into a structure that’s meaningful for the people using it. Usually that means relaxing the conceptual integrity of information systems, but in a deliberate way such that you have a rationale for where you were strict and where you were less strict.

The conceptual integrity of the system is necessary for navigating the system, for understanding what the system is or does, for imagining how to use or experience the system, and being able to apply it.

Yes, and… Remember that people don’t experience the structure of a product in isolation from the other parts of the system. Therefore, the user interface and interaction design — not to mention the content and visual design — offer clues about how everything fits together. At the same time, users don’t have a holistic view of the system: they experience the system from a single vantage. They don’t have the benefit of the 10,000-foot view that we designers have. So, information architects need to conceive of the system as a whole, but also understand what it means to experience the system one element at a time.

Information architects talk a lot about navigation and landmarks, as the user’s navigation of a digital information system is one of the most mission-critical ways in which information architecture is applied. You could think of all of the road signs along an interstate highway system as part of its information architecture. But the road itself is also part of that architecture, and the fact that the road continues being a road and connects to other roads, and does not suddenly terminate in a parking lot or the ocean or get replaced with an enormous ball pit (fun as that might be).

Another way of thinking about this is that information architecture is inherently fractal. The signs directing traffic are a structure, but the concepts of “roads” and “signs” and “intersections” themselves describe another structure. There are relationships between these ideas. Information architecture often implies thinking about different levels of abstraction — different “zoom levels”. Some levels are closer to what the user experiences — like the navigation menus — and others are much further removed from the tangible aspects of the user experience. One underlying assumption is that all these levels are related to each other, such that a change at a more abstract level implies changes at the more tangible levels. If for some reason we decide that signs and roads and intersections isn’t a helpful structure, but tracks and stations and train lines is more relevant, then we’re going to have to make changes to the road signs themselves.

The work of information architecture, especially on the web, is a bit more like designing deep space habitats than it is like designing individual houses or office buildings. The information architect is imagining what a space needs to be and what it could be, where it will be located, who will be using it, what needs and knowledge the people who will be using it have, and how to simultaneously accommodate the needs of the moment and all the possibilities of the future. You have to make sure that the way to travel from the outer rings to the inner rings of the habitat is intuitively understandable, even to alien visitors, and even if the specific things happening in each of the rings changes a dozen times over from year to year.

I like this metaphor, but as I get further into my practice I’m striving to avoid spatial metaphors altogether. The main reason is that the dimensions of space and time are limited, and in building virtual spaces we’re often dealing with several more dimensions. Information spaces can be so complex that individual nodes in that space are infinitely smaller than a room in a building (or cabin in a space station). I don’t know what the biggest information space is, but consider the realm of books. There are nearly an infinite number of books out there, and a single book sits at the intersection of perhaps dozens of dimensions.

Information architects are curious about how information is organized, and talk about things like the LATCH framework, which suggests that information can only be organized in so many ways: Location, Alphabetically, Time, Category, Hierarchy.

Some people find LATCH helpful, but I do not. The other day I was working on a product that puts volunteers on teams, and then allows other people to evaluate the volunteers’ performance on a team. The product can aggregate data across teams, so that I can see a volunteer’s performance along a single rating like “leadership”. Or I can see how a single reviewer rated a volunteer’s performance over time. To gather that data, the product allows administrators to send out review forms. Teams can have their own forms, but can draw from the same pool of questions. There is a complex web of relationships here that is clearly structural, but I’d be hard pressed to fit it into any one of the LATCH organization schemes. I’m not sure how it would help me anyway. For me a better starting point is gathering all the nouns in a system and, starting with two or three, drawing connections between them. I deliberately, carefully add additional nouns to that model, labeling the connections with

Information architects often have to help and sort whole categories of information. It’s a bit like further organizing bins of LEGO pieces that have already been sorted by size and color — which bins on which shelves, in which rooms? As such, information architects often create “meta” categories that users and customers of a system will never directly see, but are nonetheless useful for doing that major organizing. They might create and help formalize the definition of internal organizational categories like, for instance, “channels”, “systems”, and “tools”. Or perhaps helping an organization determine which things in their universe are “products” and which are “services” — and if the distinction even matters, and how.

Another way to think about this is that we need to devise the language with which the team talks about the system. To have meaningful conversations about the product’s or system’s underlying structure, we need to understand the relationships that comprise the fundamental building blocks of the system. The defined content types within a content management system offer a good example. The person consuming the content doesn’t really care whether the content type is a long-form article or a corporate announcement, for example. Those content type definitions create a common language so that the organization can have productive conversations around governance and business rules. They also allow teams to explore relationships between categories of categories. Perhaps every corporate announcement (which expires after 30 days) must include a link to one or more long-form articles to provide a permanent home for the newly announced policy.

Information architects are often tasked with designing “hidden” systems of information that make websites and apps more usable. For instance, they might create a system of tags to apply to content in a database of technical support articles that makes it easier to recommend content that’s related to other content.

Tagging is a great example of a system within a system. It’s tempting to look at the information architecture for a product as a single monolithic entity, but it’s really a set of interconnected systems. The tags work with the content types, which work with the navigation components, which works with the main menu. All of these things are distinct systems that could not do the job on their own.

Information architects are highly collaborative, but often work as the only information architect on a project, even a very large one.

Given my position, I do not encounter dedicated information architects working at my clients’ organizations. I find people with an interest in information architecture. They recognize that information architecture has been missing from their practice, or their team’s capabilities. Few organizations seem to hire people as information architects. Those who do it in-house are those people who recognize that it needs to get done and just tackle it. More often, they recognize the need but can’t do anything about it. Perhaps they don’t have the experience to do the work that needs to get done, but it’s also often a question of capacity. Information architecture became neglected, and organizations hired UX designers with other strengths and capabilities.

As an outside consultant, I’m lucky that I can (a) focus on information architecture and (b) bring a small team with me to collaborate on IA problems. I work with one person right now who is a stellar UI designer, but brings an IA mindset to their work. I work with another person whose strength is in research and discovery, but has a strong interest in doing more information architecture work. The work product is much better for the collaboration.

Information architects often collaborate with content strategists, especially when those content strategists are concerned with large sets of content that need to be accessed by different audiences with different sets of needs.

Listen to me children: this is all that needs to be said about the relationship between information architecture and content strategy. If a project, for some reason, has both an information architect AND a content strategist on it, do not fret. Do not whinge about who does what. Be thankful. Be thankful that someone somewhere has deemed this project so complex, so important, so nuanced that it needs not one, but two people thinking about how content is structured.

Information architects do their best work when they’ve had an opportunity to get immersed in the world of information they’ve been tasked with organizing, and as such often spend a lot of time early on a project doing lots of reading and exploring without any specific outcomes in mind.

This is perhaps one of the reasons why IA has been neglected. From the outside, what Scott describes here doesn’t appear to be “work”. It appears to be an indulgent — almost academic — pursuit to satisfy curiosity. But, yes, the closer I can get to the domain the better the information architecture will be. By immersing myself in the domain, I’m hoping to see connections that we can exploit for use in the design of the product. This isn’t to say that connections and relationships are hidden from those who live and work in the domain every day. Instead, those connections are so ingrained in how they operate within the domain they barely notice them any more. My most satisfying moments as an information architect are identifying a distinction within a category that everyone took to be singular. As much as we prize the human mind for recognizing distinctions, it is also capable of concealing them when teasing out subtle differences between similar entities is effortful.

Information architects tend to approach their work through a series of increasingly-focused revisions, often starting by sorting things very roughly and broadly, and then more specifically, and then more specifically yet.

My process also entails exploring different ways to sort things. At the beginning of an IA project, even while we’re still doing research, I create a spreadsheet where each column represents a different approach to organizing the product. You might call this a top-down approach. I’m not trying to group items together. Instead I’m answering the question “Based on my understanding of user needs, business goals, and the content domain, how might I present navigation to help users find what they need?” I give myself permission to stretch the bounds of what navigation can and should do. I challenge myself to approach the domain in novel ways. I ask myself questions like, “What story do I want this navigation system to tell?” Then, in early design conversations, we review these different approaches with our clients and stakeholders. Usually I have a favorite, but the intent of that conversation is to see what resonates… and where their areas of discomfort are. Nothing touches an organization’s nerve like a new approach to navigation.

Ultimately, organizing information for use and understanding requires labels and categories to describe the types of information, and information architects will not only need to choose those labels, but also create documentation (such as glossaries and spreadsheets of “controlled vocabularies”) to specify the best words to use to describe things so that everyone working with the information understands each other.

Governance of information architecture is, I think, the most unexplored area of IA. When I’m working on an information architecture, one of the questions I ask is, “After I’ve left the project, how will the product team know where to put a new piece of content or a new feature?” The categorization needs to be clear to the target audience, but also to the people maintaining the system. Growth of information spaces is inevitable, and a good information architecture is resilient to growth, even accommodates it. Decisions you make in creating the information architecture resonate in the organization for years to come. They set a precedent, giving others license to treat information in the same way — how it’s categorized or archived or labeled. Therefore, the decisions we make as part of designing information architecture are consequential not just for how the user navigates the information space, but how that space will change over time.

Information architects often collaborate on or lead the development of website site maps, which describe in a hierarchical fashion the relationship of major topics, sections, and types of content on a given website. The site map is a way of best representing and replicating the conceptual integrity of an information system as a website.

We made it all the way to 16 thoughts before I got cynical! Site maps are great, but they’re simplifications of a (likely) much more complex system. They are a facade built on top of the structure to help people make sense of it. Perhaps they won’t ever understand the underlying structure of a product beyond what the site map tells them, but that’s OK. The role of the site map isn’t to convey the elegance and economy of the structures we design. They are literally a map to explain what you can find on this site or in this product. And like any map, they are abstractions of reality. Like any element of the user experience, a site map should serve a purpose grounded in a user need. If they user’s need to understand a site’s underlying structure, then the map should reflect that. Instead, a site map may only be a tool for educating users about what’s available, or helping them zero-in on the most common tasks.

Information architects know that sitemaps aren’t the same as navigation menus, and that navigation menus aren’t the same as “the” information architecture, and that there are often multiple useful ways of presenting the paths and tools available to navigate a given set of information to end users of the system.

Long gone are the days when a site’s main navigation has to be “comprehensive”. We invented megamenus so that we could show as much of the site as possible in the main navigation, but the truth is that to represent the entire structure is a fool’s errand. Moreover, it flies in the face of doing what’s best for the user. Today, I press my clients to think about what role they want the navigation to play in the user experience. I want them to think about how the navigation speaks to their target audience and how that message dovetails with messaging from other aspects of the product’s experience. In our work on an intranet right now I regularly remind our team we’re not trying to “boil the ocean” (a phrase I feel I should probably retire from my vernacular, if only for my kids’ sake). The purpose of the navigation — especially on a sprawling system like a corporate intranet — must be singular and clear, and can only be successful if it works in concert with other elements of the experience to convey the range of content available.

Information architects tend not to be concerned with which words are “right” so much as they are with which words are useful. While a brand book might tell you that the right word for a particular pocket-sized multi-tool is “Leatherman”, the IA knows that their audience might still call them “Swiss army knives”.

Useful words: so elegantly put! I’ll often put terms together (like “Policies & Procedures”) to help clarify the contents of a category, even if the words themselves aren’t in common usage in the organizations. One aspect of language that Scott hasn’t touched on here is that information architects sometimes distinguish the label for a concept from the labels in use in a navigation menu. That is, the only tools I have to describe a concept are words. So I will sometimes use temporary words to define the concept to make sure we’re all talking about the same underlying category. That label likely evolves in the final product, one that more closely aligns with user expectations or better describes the contents of the category. Policies & Procedures might become Corporate Standards or Guidance, but the first label is the one I use to validate that it is a meaningful and useful concept.

Information architects often help with the design of tools and components that help users navigate an information system, such as the main navigation menu, the search functionality, and the organization of content at critical touchpoints such as home pages and category landing pages.

All of these things — navigation, search, content organization — and other things like page layout and local navigation rely on an underlying structure, how all the elements of the system co-operate. These things are manifestations of the structure — facades exposed from different vantage points. “What does the structure look like when I’m at a destination page deep within the site?” “What does the structure look like when I arrive at the site on a middle-tier category page?” As an information architect, my role here is to decide what aspects of the structure can and should be exposed, and working with UI designers and content designers to determine the best approach for how those aspects are represented.

Information architects often use the design tool of card sorting, wherein the IA or stakeholders in a workshop are asked to sort a list of items into related groups, and then choose a name to describe those groups. Great information architects know that watching and listening to people perform this activity can be even more valuable than the actual choices they make while doing it.

Scott and I could do a whole dialog about IA tools — the ones we use for doing discovery (like a card sort), the ones we do to model different IA concepts, and the ones we use to test our IA concepts (like Optimal Workshop’s TreeJack and Chalkmark). It would be a short dialog (but dense!) because there remains a dearth of dedicated tools for information architects. I’ll tell you my dream tool? Parallel lists. I want to make a series of lists, displayed on the screen at the same time, and in the same “file”, but they can scroll and grow independently of each other. (Do not tell me how I can do this in a spreadsheet. I’m just not interested.)

‘Information architect’ need not be one’s job title to design or refine an information architecture. It often isn’t.

Of course not. Those who call themselves information architects rarely have the title Information Architect. But that’s part of the exquisite irony of our work — or perhaps the perfect encapsulation of it — that we’re compelled to separate labels and concepts while acknowledging that they are also inseparable.

👓 Dan Brown has been practicing user experience design for over 25 years.

In addition to writing the foreword to Scott’s excellent book Writing for Designers, he co-founded EightShapes, a user experience design firm based in Washington, DC 🏛. Dan wrote three books 📗📘📙 on user experience design, most recently Practical Design Discovery. He produces tools and games 🎲 for design teams, including Surviving Design Projects and Information Architecture Lenses 🔍.

Need to run a workshop? Looking for some help with your product’s user experience, user research, or information architecture? Just want to chat? Let’s set up a time to talk! 🗓

21 More Small Thoughts on Information Architecture was originally published in EightShapes on Medium, where people are continuing the conversation by highlighting and responding to this story.

But what happens when the practice of design — or the people who do it — is subjected to critique?

When it comes to hearing critique about ourselves and our practice, we erect defenses. Though long overdue, critiques about the practice of design itself are hard to read and internalize. Sadly, I see designers reject such critique without considering it as dispassionately as they would their own work. Worse, they direct their ire (or fear or anxiety) at the person offering it.

Cultivating a growth mindset and embracing the process of self-reflection takes energy. The work can be rewarding, but there’s no guide on how to do it. It’s taken me years to make my inner dialogue productive, to ask myself useful questions and to provide honest, constructive answers.

Self-reflection usually comes with a trigger, an event or circumstance that leaves you uneasy. Perhaps you can’t let it go, or it raised an emotional response. Perhaps you expected a different outcome.

Self-reflection can also start from reading something critical about a topic near and dear to your heart. Some of these critiques are levels not just at the practice, but at the people engaged in it. Such a thing is not an invitation to defend yourself — after all, you just heard or read one person’s opinion. But it is an invitation to ask yourself: What about this made me react so vehemently? And even more productively: How might I grow in response to this critique?

One recent critique is from Vivianne Castillo. It was hard for me (and, from what I gather, many others) to read. It triggered feelings of anxiety and frustration and even fear. It made me defensive.

Vivianne’s critique also helped me think about how I approach design. I’m going to break it down for you, so you can see my process of self-reflection.

(I shouldn’t have to say this out loud, but I will: This is NOT about what Vivianne got right or wrong. She said what she said. I’ll delete any comments that go after Vivianne’s thread. Save your energy.)

Everything in blockquote is from Vivianne’s tweets, used with permission.

I have this theory that one of the many reasons why so many in that 1st wave of UX leaders will become/are becoming irrelevant is because they’re more committed to being heard than learning. The key word here is committed. [source]

First wave. My first thought was, “Is she talking about me? Am I considered a ‘first wave of UX leaders’?” The easy response would be “no,” giving myself permission to opt out of the critique entirely. She couldn’t mean me! But it does me no good to take the easy way out. As someone who started working on the web in 1994, even before we adopted the terms information architecture or user experience or even digital product, it’s hard to deny that I was among the first.

Becoming irrelevant. Moreover, I turned 50 this year. I’ve watched the profession become more obsessed with youth over the last ten years. I’ve also seen my area of expertise and interest — information architecture — come and go and come again. Relevance and irrelevance loom large in my reflections. Vivianne had my attention.

More committed to being heard than learning. Here I also saw an opportunity to excuse myself from the critique. (If you hadn’t guessed, finding a way out is my go-to response.) Listening and learning is something I talk about all the time! She couldn’t mean me! But then I thought about all the times I felt frustrated by the lack of awareness in the design community about What Came Before. The first generation of UX folks wrote countless articles, blog posts, even books! We’ve been producing stuff for decades — how are people not aware that we’ve already had these discussions. And I realized that although I am committed to learning, I’d also really like to be heard. Like, really.

Many of them are more committed to relevancy than maturity. They’re more committed to gatekeeping and elevating their friends, after all “oppressors do not favor promoting the community as a whole, but rather selected leaders.” (Paulo Freire, Pedagogy of the Oppressed) [source]

Committed to relevancy… I’m terrified of becoming irrelevant, of being incapable of making meaningful contributions. I’ve watched others — inside design and outside — fade away into obscurity. Or what looks like obscurity. For me, this could be an existential crisis. I’m the sole breadwinner in my family. We have kids heading off to college. We have elderly parents. When I see the defensiveness in my peers, I feel a pang of sympathy. They are likely as concerned about their prospects as I am. So I ask myself, “What does this work look like when I’m 55 or 60 or 65?” And sometimes I ask myself, “If I can’t make a living doing the work I’m doing today, what could I do instead?”

… than maturity. As much as I would like to rest on the knowledge I’ve accumulated so far, I have to face the uncomfortable reality that it will get me only so far. I also have to understand that my role is changing. What looks like obscurity to some may actually be more of a move behind the scenes, a role less in the limelight. The use of the word maturity here really got me. What do I do today that I didn’t or couldn’t do in my 30s or 40s? How have I matured as a designer? What does it even mean to be a mature designer? I’ll be thinking about that for a while.

And while there was a point in my career where I would get annoyed or mad … I honestly just feel sorry for them. I can’t imagine the kind of angst one feels if an understanding of their value is deeply tied to a community that craves more than what they can even offer. [source]

Craves more than what they can even offer. My interpretation here is that what we older designers can offer loses its value only if we sacrifice learning. Even now I worry that I’ll just be useless at some point, and so I ask myself why it’s so painful to acknowledge two things:

1. My role will continually shift. What I do today is not what I’ll be doing over the next 15 years.
2. I will be able to make contributions so long as I continue learning.

And then I realize that learning is harder for me today than it once was. It’s harder for me to read long articles. It’s harder for me to pick up new software. It’s harder for me to listen for long stretches of time. Even now, when I think of leveling up as a designer, I think of taking on new technical skills. And it’s true that acquiring those is getting harder.

So, as part of the self-reflection I have to ask, “What do I really mean by learning?”

The word “learning” here is doing a ton of work. It means more than acquiring technical skills. For me in this moment it means understanding how a broad range of people experience doing UX work. It means identifying obstacles that I never had to face myself. It means building my capacity to recognize environments and circumstances that are more hostile to some people. It means acknowledging systemic challenges that were easy for me to ignore. I learn when I seek to understand how the things that worked for me in the past can’t and won’t work for everyone.

I’ll be doing this for the rest of my life.

And I have another theory: that their grasping for attention and relevancy will only get worse over the next few years. When the world feels more out of control, we can feel greater desires to be in control. I can only imagine the attention-grabbing tweets from them in 2024. [source]

World feels more out of control. What I love about this tweet is that it reveals a common ground, even implicitly. Vivianne and I — as different as we are — both live in a world that increasingly feels out of control. This tweet points out that people sometimes retreat to toxic behavior because they learned early on it’s the best defense. (Yes, I’ve been to therapy.) I read this tweet as Vivianne offering us a choice, reminding us that even though the world feels out of control, we decide how we face the chaos.

Attention-grabbing tweets. My personality, I definitely don’t want to be seen as someone behaving only for attention’s sake. So, what will I do when the world feels out of control? How will I continue to add value to the field of design when the world is bearing down, when I feel even more irrelevant? How will I act when the field of design looks completely different from when I entered it? These aren’t hopeless questions for me, but opportunities.

They don’t deserve your energy, other people deserve it wayyyyy more. YOU deserve that energy way more than they do. The things and people that give you life deserve that energy more than they do. Your energy & time is too precious — don’t waste it … and drink some water [source]

They don’t deserve your energy. Of course not. So how can I earn it? How can I be the kind of person — regardless of my demographic, not because of it — that deserves the energy of another? How can I be the kind of person who “gives you life”? I think I know. And I think I know the things I do that drain another’s energy. So I know what I need to work on and work toward.

Drink some water. And I do. Every time Vivianne says this. If I need a reminder about this, I’m sure I need a reminder about other things, too.

And that’s what my self-reflection looks like.

The Self-Reflection of a Senior Designer: A Case Study was originally published in Greenonions on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I posted my previous article on Cross-Cutting Topics, Peter Merholz asked, “How is this different from faceted classification?”

Er… I dunno.

My professional aim is to contribute tools and ideas to the practice of information architecture. Make use of them as you see fit. In this follow-up I won’t defend the idea of cross-cutting categories. Instead, my aim is to explain what distinctions I make in my own practice in case they might help you in yours.

Facets and tags are implementation strategies. They are approaches we can use to represent a complex domain in a digital space. Cross-cutting categories are, by contrast, a way of understanding the shape of an information space.

Cross-cutting categories explain a phenomenon I see happen in the structure of a domain. Dan Hon suggested that what I call cross-cutting categories are “themes”. In one sense they are — concepts that appear time and again throughout a domain.

As information architects, our role is to first understand the structure(s) of a domain — what are its essential concepts and how do they relate to each other. After that, our role entails developing strategies for explaining and navigating that domain in a digital space. We design the parts of the screen that make the structure meaningful, accessible, and informative.

Facets and tags, therefore, are techniques we use to make structures meaningful, accessible, and informative.

So, it’s worth considering the circumstances under which I might use tags and facets relative to cross-cutting categories. First, though, I want to define each of these strategies.

Tags

What it is: Tags are a collection of terms that describe an aspect of the domain — the subject matter, the content format, even the author.

Canonical example: Hot topics on a news site.

Assumptions:

• Tags are generally messy — just a jumbled collection of terms. They might be ordered — that is, classified into groups, in which case they edge dangerously close to facets.
• Tags should be descriptive, helping the reader locate the content in their mental model of the domain. They generally help the user answer the question, “What is this content about?”
• Tags may be used for navigation. That is, clicking on a tag reveals more content tagged with the same term.
• In most implementations, there aren’t strict rules about how something can be tagged. A given piece of content can have one tag, or 10 tags, or zero tags.

Use when:

• Tags are great for unstructured content because they create a sense of order out of chaos.
• Tags are infinitely expandable. You can start with a set and add to them as needed.
• Tags require curation, because if users are permitted to create their own tags things can get out of hand.
• In most implementations, tags aren’t the central navigation mechanism.

Facets

What it is: Facets are aspects of content that can have different values. Each facet is a field (like format) with one or more values associated with it (like long-form content).

Canonical example: Searching for flights.

Assumptions:

• Facets are key-value pairs. They answer the question, “What is aspect X of this content?”
• Implementing facets requires defining both the fields and associated values.
• Unlike tags, facets are generally a closed system. You establish the set of fields that best define the structure of content. Expanding or changing them generally requires substantive technical intervention.

Use when:

• Facets are great for very large collections of highly structured content, because they allow users to do
• Facets work better when the key-value pairs are already well understood by the target users.
• In most implementations, facets are the primary means for navigating the content.

Cross-Cutting Topics

Let’s return to cross-cutting topics. For me, the canonical example of a cross-cutting category is “sustainability”. The story I run into again and again is that a business long lumped sustainability among its core offerings. Over time, however, that “offering” is something that permeates every aspect of what the business does. It no longer makes sense to talk about sustainability as its own thing. Instead, the business wants to say how everything they do takes sustainability into account.

Is it a facet?

You could use facets here, but it would be weird. Remember, facets are key-value pairs. The key could be “theme” and have “sustainability” as a value. That strikes me as heavy-handed. Also, it presumes people want to navigate/filter by “theme” which is possible, but also a little weird.

Moreover, this approach buries the theme. If sustainability is an important concept, having it appear as a possible value in a facet doesn’t bring it to the forefront of the experience.

Is it a tag?

A tag called “sustainability” seems more likely to me. Content for each offering may be tagged “sustainability” as needed. To get specific: if the category is transportation, and each piece of content in transportation is about a different development project, those that have a sustainability angle could be tagged as such.

But that’s only part of what I’m talking about. Yes, individual pieces of content fall into both categories transportation and sustainability. But there’s a higher level concern. The organization wants to talk about sustainability more generally. They want to highlight that this is a central theme. They want to carve out a dedicated space to expand on it as a topic in and of itself. That strikes me as more than a tag.

The organization wants to talk about sustainability across all key offerings including, say, public health and agriculture and sanitation. Individual project pages in these categories may be tagged sustainability, but that doesn’t give the concept the desired gravity in the navigation or content strategy.

Instead, through the idea of cross-cutting categories I’m seeking to identify what concepts need highlighting on the upper level pages, the ones that describe each offering. I’m looking for those themes that need to be elevated, and might serve as navigation categories in and of themselves.

These key themes likely merit a place in the navigation. Every theme should be a tag, but not every tag is a central theme. Moreover, just because cross-cutting categories exist doesn’t mean that the content collection needs tags to facilitate navigation and findability.

In any given domain of information, some topics that cut across every other one. Hence: a cross-cutting topic. In medicine, for example, you have cardiology, gastroenterology, ophthalmology, and pediatrics, among others. Pediatric medicine can also cut across all of them: you can talk about the health of the heart, the gut, or the eye in adults or in children.

But we usually see pediatrics as a topic alongside the others, as if cardiology and pediatrics are both at the same level. And in some contexts, a straight list of topics — no cross-cutters — is most helpful. Physicians must choose to specialize, so they might choose general cardiology or general pediatrics.

This is the state I usually find a set of topics in: a long, straight list that does not acknowledge that some topics have evolved such that they cut across the others. I’ve seen this in medicine, real estate, employment services, digital storage, and many other domains.

In every domain, at least one topic that has been treated the same as any other in fact serves as a lens through which to see the other topics.

What’s remarkable isn’t so much that some topics evolve to become cross-cutting. It’s not even surprising that this happens consistently across different fields and industries. Instead, what I find remarkable is the organization’s dogged adherence to a flat structure. The expectation, I suppose, is that the information has always been categorized in this way, so this is how it will always be categorized.

The Emergence of Cross-Cutting Topics

How does a topic become cross-cutting? I’m doing a bit of reverse-engineering here, looking at the attitude of the domain experts toward the domain’s topics.

Increased Emphasis

Over time, one or two aspects of a domain might become more interesting or relevant, due to changes in circumstances or increased attention on it. I’ve seen this time and again with the concept of “sustainability”. Once thought to be a single plank in the platform, organizations have come to realize that sustainability is a concept that pervades every aspect of their business. Accessibility is not there yet (frustratingly) — organizations treat accessibility as a separate topic next to all the other aspects of their business, but should instead think of it as a lens through which to look at everything else.

Organizations focused on offering a set of services sometimes treat “technology” as a distinct category. You can almost imagine their marketing materials from the 1990s cheerfully offering technology services alongside their other offerings. Three decades later, organizations acknowledge (hopefully) that technology pervades every service they offer.

Emergent Matrix

Sometimes it’s more than one or two topics that become cross-cutting. In these cases, the domain has become so nuanced that topics can be organized into a matrix, and that content is only interesting at the intersections of topics.

An obvious example of this comes from our work with large multilateral organizations. Historically, the content was siloed by topic, by content type, and by geographical region. Analysis showed that although it may be useful to have pages for broad topics like “environment” and “infrastructure”, these became more meaningful when intersected with geographical regions.

Our work in physician training also shows that the industry generally relies on lists of topics treated homogeneously. So, Women’s Health is lumped in with Cardiology. But topics that deal with demographic groups (like “women’s health”) or medically relevant populations (like “immunocompromised”) or new technologies (like “imaging”) have relevance across more traditional medical topics. I predict that as medicine embraces a more holistic view of human health — the body’s systems don’t act in isolation — we’re going to see much more matrixed content.

Validating Cross-Cutting Topics

Looking at a domain with fresh eyes reveals that a formerly flat list of topics has some cross-cutting topics. But these are only hypotheses, and they need to be tested. Like any information architecture research, it’s difficult to arrive at a clear direction. Instead of seeking definitive direction through research, I seek feedback on the concept using a few common techniques.

First, I can do some validation without any testing whatsoever. An information architecture is only as good as its ability to successfully frame the content. So, the first thinking tool I use for this is stress-testing. By stress-testing I mean using the categorization scheme to classify real content. I look at various combinations of topics and evaluate whether there’s meaningful content at their intersections. In short, I’m asking myself, “How much content do I have at the intersection of Topic A and Topic B?”

Another way to stress-test the concept is to use a content inventory. Like most of my work product, the content inventory is in a spreadsheet. In this case, each row represents a distinct piece of content. I add a couple columns, one to indicate the main topic and one to capture any cross-cutting topics that might be represented in the content.

Each of these stress-testing approaches addresses different ways in which a cross-cutting topic may manifest relative to a main topic. The first approach asks whether there is stand-alone content that may be classified by both a main topic and a cross-cutting topic. The second approach asks whether some of the content on a given page might be classified with a cross-cutting topic.

To be clear, one or two negative results from stress testing doesn’t invalidate the entire concept. Cross-cutting topics are interesting because they highlight meaningful and important aspects across a domain. Reality is messy, however, and those aspects may not be consistently relevant across the domain.

Tree-testing is a technique that gives participants tasks to locate content in a tree of categories. They navigate through the hierarchy until they find the category they think the content is located in. For domains with cross-cutting topics, I set up the tree to include both the main topics and the cross-cutting topics. This is tricky, because it may not be an accurate representation of how you want to set up the navigation, but it is an accurate model of the underlying information structure.

The success of this approach depends on writing real-world tasks that involve content at the intersection of two topics:

• For medicine, it might be looking for a cardiology case study involving an immunocompromised patient.
• In domains heavily reliant on geography, the task could involve seeking out transportation infrastructure projects in sub-Saharan Africa, for example.
• For a business that focuses on providing services, I like to ask users to find information about technology solutions that support the services offered.

Tasks like these allow you to discern which aspect of the domain users prioritize when seeking information.

The results might show that users favor finding this content with one approach over another. You might observe that most people tackle the “transportation infrastructure projects in sub-Saharan Africa” task by clicking into the region menu. In this case, the geography looms large in your users’ imaginations, an insight that can help you determine how to treat cross-cutting topics in the menu design.

On the other hand, if things are evenly split — some users clicking on the subject matter and some clicking on the region — you can surmise that the mental model isn’t stable across users. The tree-testing tool I use — Optimal Workshop’s Treejack — allows you to dig into the path that participants followed. You might see that users went straight for one category or the other (high directness) or, they bounced between the two before settling on one (low directness). All these hints suggest how you might design the menus to ensure visitors see the keywords that resonate with them.

Designing for Cross-Cutting Topics

With an information architecture involving cross-cutting topics, there are a several important design decisions. The answers to these questions depend entirely on the design principles you establish for yourself. Those principles, ideally, are grounded in a thorough understanding of the domain’s content, the organization’s objectives, and, of course, your understanding of the audience’s expectations.

How does a cross-cutting topic appear on a main topic page?

There’s no particular order to these decisions, but I do like to start with how the cross-cutting topic is integrated into the primary “back bone” of the information architecture. If the spine of the IA deals with a set of subjects, the cross-cutting topic is a lens through which to look at each subject. For example, if Transportation Infrastructure Projects has a page, how are geographical regions (which are cross-cutting topics) represented on the page?

Each region might have a distinct section on the page. The breadth and depth of those sections depend on the purpose of the site and the available content. Maybe the organization just has a couple sentences they want to say about Cardiology and Women’s Health. Maybe they have an entire library of content.

Do cross-cutting topics need dedicated pages?

Whether or not a cross-cutting topic appears on a main topic page, it could have its own stand-alone dedicated page. A page on Women’s Health, for example, might talk about the organization’s overall philosophy and approach, irrespective of how it connects to the main topics.

A cross-cutting topic might deserve its own page if there’s a stand-alone story to tell about it. It might also be the kind of topic that users come looking for, and having a dedicated page gives it some weight. Finally, a cross-cutting topic could offer a good way to navigate the main topics, highlighting those that are further illuminated by the cross-cutting topic.

Do topic intersections need dedicated pages?

A third decision is whether the site needs pages that are dedicated to the combination of a main topic and a cross-cutting topic. For example, instead of (or in addition to) having a sliver of content on the Cardiology page about Women’s Health in Cardiology, there might be a page dedicated to all the content about Cardiology + Women’s Health. I call these “intersection pages,” because they expose content at the intersection of two topics. These pages offer niche content which might differentiate the site from other organizations’ sites. The intersection pages create additional space in the structure in case a blurb on the main topic page doesn’t cut it.

One aspect driving this decision is whether there’s sufficient content and/or interest in these intersection pages. Every new page represents an additional level of effort for managing and curation. The interest or available content for these intersections may be uneven. (Example: Cardiology + Women’s Health may be rich with possibility whereas Ophthalmology + Women’s Health is probably not.)

Finally, given the breadth of content on the site, it may be best to automate the content on these pages. That is, since there may be many possible intersections, it may not be realistic to manage all those pages independently. Instead, the underlying content management system assembles the content by finding everything that’s tagged with both categories. This represents a different kind of effort, designing the rules to populate these pages in various circumstances.

How do cross-cutting topics appear in the navigation?

Save menu design for last. It helps to understand what the structure will be — whether cross-cutting topics have dedicated pages or not, for example — before you design the wayfinding mechanisms. Cross-cutting topics are tricky for menus because they do appear across the main topics. If each main topic + cross-cutting topic intersection had a dedicated page, the menu might appear littered with redundant labels.

Remember that the navigation menu does not need to be comprehensive. It better serves users by depicting the range of things available and highlighting useful starting points. If the cross-cutting topics are good starting points, create a list of them that implies they are orthogonal to the main topics. If it’s instead important to show that your main topics have these cross-cutting aspects, you can point to them in a more oblique way.

See Also…

With analog tech, the best we could do with a cross-cutting category was print “See Also…” and capture other sources. Digital technology offers us a chance to mix and match content, pulling together snippets and links to create more nuanced pictures of the subject matter.

But with great power comes the great potential for messiness.

I love working through the implications of cross-cutting topics. I revel in the interconnections between topics. I could positively loll in domain models that attempt to explain the relationships between them. But I have to remind myself that in using a product, someone does not pause to admire the elegant connections. They do not bask in the glow of the intricate links between nodes.

Instead, they want to find what they need and get out.

Your intimacy with the topical connections is a tool to build the most effective and efficient navigation and wayfinding system possible.

👓 Dan Brown has been practicing user experience design for over 25 years. He co-founded EightShapes, a Washington, DC-based user experience design firm. Dan wrote three books on user experience design, most recently Practical Design Discovery. He produces tools and games for design teams, including Information Architecture Lenses.

Need to run a workshop? Looking for some help with your product’s user experience, user research, or information architecture? Just want to chat? Let’s set up a time to talk! 🗓

Cross-Cutting Topics was originally published in EightShapes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Everyone understands it and it’s so straightforward: “Write on post-its, vote on post-its.” But, let’s be honest, it’s a bit over done.

I’m here to tell you that you don’t always have to vote on stickies! It’s not the only recipe in your creative workshop cookbook!

Workshops are just lots of these little templates put together. But when you only know two templates (write on post-its and dot-vote) workshops can become a little stale or — worse — disconnected from the desired outcomes. You’re making the objectives conform to the activities, not the other way around.

So, let’s expand the palette. Three other techniques I use to create workshop activities are:

• Vote on a scale: participants answer a prompt indicating where they fall on a range
• Pick from a list: participants assemble ideas from an array of options
• Use narrow or leading prompts: participants brainstorm ideas within a very confined scope

Vote on a scale

I mean, you already brought the dots. You might as well have your folks use them for something. In this activity participants respond to a prompt you provide on a scale of responses. You can just put two extreme responses at either end of a line and they affix their dot along the line. In this example, I used emojis in a warm-up activity to get participants ready to think about web site navigation.

Alternatively, you can include a series of responses, like I did here:

It’s a great way to surface everyone’s preconceptions about the product’s requirements. It’s also a great way to tease out some nuance in otherwise banal statements like, “The navigation should support both browsing and locating.”

While we’re talking about preconceptions, I’ve also used this approach to ask people about their assumptions about the product’s users:

The intent here isn’t to get an accurate count of users, but instead identify the differing assumptions held by the product team itself.

Preparation tips: The prompts should be pretty narrow and you should have at about 5 options on the scale.

Use when: You want to tease out assumptions or preconceptions; The team has requirements that need clarification; The team sees a choice as a binary, and there’s an opportunity to reveal nuance.

Pick from a list

Another way to throw out the stickies is to frame activities as multiple choice questions: After giving them a prompt, offer participants a range of predefined answers. Rather than asking them to spend effort scraping the bottom of their creative barrel, we’re offering a buffet of interesting possibilities and mixed metaphors.

Since the default approach for so many workshops is “give prompt, await responses” this is actually more radical than it seems. Because people carry preconceptions with them, showing a broad list of options can help them expand their thinking.

Recently, I asked folks to brainstorm new main navigation categories for their marketing web site. Instead of simply writing their own, I gave them 24 different possible top-level categories. The options included a few synonyms, so the participants could see different ways of framing the navigation. The options included terms that were outside the industry standard, but were still reasonable, to encourage them to see the design problem in a new way.

This approach also demands shifting how you frame the prompts. Instead of focusing on what makes a good navigation label, the prompt asks them to pick the concepts that work best.

I’ve also used “Pick from a list” in an activity to quickly create mad-lib-style personas, too. Instead of filling in the blanks from scratch, participants choose from a menu of needs and challenges. As with brainstorming navigation, the value here is showing people a wide range. There’s the added benefit of showing how combining different needs with different challenges produces a wide range of unique but not unrealistic situations.

Preparation tips: Narrow prompts work well here. Create multiple copies of the list so people can grab their options without impinging on others. The number of options depends on the exercise, but keep in mind you need to allow time for participants to review the available options.

Use when: Showing broad range of options will encourage thinking about the problem differently

Use narrow or leading prompts

As design researchers, we’re trained to ask open-ended questions. So much so that even I feel a tinge of shame when I ask anyone a yes-no question. We’re also taught not to lead the conversation. I understand the intent of supposedly “neutral” questions, but I’ve come to learn that such questions then put an enormous burden on the respondent. Without more context, without more direction, without more priming, it can be hard for the human brain to reach a meaningful response. This is especially true when we’re asking folks to brainstorm new ideas, rather than recall their own experiences.

Both previous recipes — Pick from a list and Vote on a scale — clearly lead the conversation. We’re asking participants to select from canned responses. My aspiration in a workshop setting is for participants to think beyond these canned responses, but I understand that people often need to see something to disagree with it, or take it in a different direction.

By the same token, a prompt can be very narrow and still yield valuable information. When asking participants to brainstorm possible topics for a web site, I don’t ask, “What is the most important content?” Instead, I ask 3–5 narrower questions, and we take a few minutes to brainstorm answers to each.

• What three pieces of existing content are the most useful to your users?
• What three pieces of existing content are most important to your company’s business objectives?
• What one piece of content is difficult to find but shouldn’t be?
• What one piece of existing content represents your company’s best storytelling?
• What one piece of content would you add to help underserved customers?
• If you could add just one piece of content to the site to help new users what would it be?

Breaking down a broad question — in this case about content — into narrower questions, we end up with a broader range of responses.

Preparation tips: Start with the large open-ended question and then break it down into smaller requests

Use when: Asking people to brainstorm within a large domain

Putting Activity Templates to Use

An activity template is a recipe for engaging participants with the content of your workshop. None of these templates presume a particular topic: Like dot-voting they’re meant to be used in a wide range of contexts.

As you look for ways to expand your workshop activities, keep these in mind:

1. These are templates, to be applied in whatever way makes sense to achieve the objectives of the workshop.
2. Every activity is an excuse to have a conversation. It is a small shared experience that creates space for everyone to have a voice. As facilitators, our role is to ensure every participant gets the space they need to express themselves, regardless of how they complete the activity.

Ultimately, though, the workshop must serve to move the project forward. Therefore, the most important thing is to keep in mind the objectives for the workshop — its purpose and role in your project. However you choose to make use of these or any other activity templates, start with — and go back to — the workshop’s objectives.

👓 Dan Brown has been practicing user experience design for over 25 years. He co-founded EightShapes, a Washington, DC-based user experience design firm. Dan wrote three books on user experience design, most recently Practical Design Discovery. He produces tools and games for design teams, including Information Architecture Lenses.

Need to run a workshop? Looking for some help with your product’s user experience, user research, or information architecture? Just want to chat? Let’s set up a time to talk! 🗓