When designing an information environment, you must ensure distinctions between parts of the environment are clear. This means users must be able to look at labels in navigation bars and section headers and understand the differences between them. When distinctions are clear, users don’t have to think about them: they know where to go and what they can expect to find and do there.

That this is obvious doesn’t make it easy. Often distinctions aren’t all that clear. Perhaps designers have tried to group too many things in that part of the environment, leading to labels that try to contain too much. Or maybe folks from the branding team have insisted that labels must include language that is only clear to people already familiar with the organization’s offerings. Whatever the case, to quote an old Martin Gore song, “Finding the right words can be a problem.”

Let me give you an example. I want to take my kids to an amusement park. There are two big parks near where we live: California’s Great America and Six Flags Discovery Kingdom. Both of these parks have websites. Here are their primary navigation bars:

Great America’s navigation bar seems simpler; it’s got five items (whereas Six Flags’s has eight) and it has a “cleaner” visual design. Great America has also surfaced an important piece of information (the park’s opening hours) to the utility navigation bar, which Six Flags has as an item in its primary nav bar. I also question some of Six Flag’s choices regarding granularity. Why are “Groups,” “Passes & Memberships,” and “Tickets” three separate areas? Shouldn’t these all be under “Tickets”?

That said, when navigating both sites, I found Six Flags’s navigation structure easier to use. The main reason is that they’ve used plain language to establish clear distinctions between important parts of the environment. I understand the difference between “Things to Do” and “Plan Visit.” Instead, Great America uses two non-obvious labels: “Explore” and “Play.” This is a curious choice of verbs. What’s the difference between exploring and playing in this context?

I came to these sites to look for the height restrictions for their rides. I know where to find the rides in the Six Flags site (“Things to Do”). But where are they in the Great America site? I’m guessing they’re under “Play,” but they could easily be under “Explore.” (As in, “explore our park.”) It turns out they’re under “Play;” the “Explore” section contains a mix of news, park information, and other important items that don’t seem to fit neatly in other sections:

Note that I was able to determine the contents of the “Explore” section by merely hovering over the nav bar. The use of mega menus such as this one has alleviated some of the confusion caused by ill-defined distinctions. That said, mega menus don’t help in the mobile context (which is where I first experienced this particular site):

If you find yourself struggling with labeling the distinctions in an information environment, consider the possibility that the grouping may have problems; it may be trying to do too much, or be driven by concerns that aren’t user-centered. And of course, test the labeling and grouping to ensure it’s clearly understood by the people who need to use it.

Information architecture is ultimately about establishing and clarifying distinctions; defining sets of things. Grouping items creates a boundary around them: these things are different from those other things in one or more ways. When boundaries are meaningful, people can find (and understand) the items they’re looking for.

Things have different meanings for different people in different contexts. A baseball bat means one thing if you see it alongside a ball in a stadium than if you see it alongside a bloodied glove in a courtroom. We call the first group “equipment” and the latter “evidence.” These labels evoke particular contexts, and thus imbue the items with meaning. If you see a baseball bat in a list titled “evidence,” you know somebody probably got hurt.

That said, a title may not be necessary: sometimes listing the items in the group is enough to convey the context they’re in. Bat, ball, glove, base – the list is enough; I don’t need to place a label above it for you to know what these things mean. (Note I didn’t even have to write “baseball glove”; you got my meaning merely because of the presence of the other items in the list.)

One of the most challenging things about information architecture is that it’s often not clear what groupings (or labelings) will be meaningful to the people who need to use the things we design. Seldom are things as obvious as the baseball example above; you may be called to deal with arcane terminology, novel products, or concepts that are too abstract to relate meaningfully to things people already understand.

To make matters more complicated, the people commissioning the work often have distinctions of their own, groupings that make sense to them. “These products are ‘owned’ by this business unit, ergo they belong together.” If you’re lucky (or if the organization is particularly customer-centric), the groupings may already make sense as an ensemble. In those cases, the work focuses on clarifying labeling. But what if the groupings don’t make sense? Then you must work to establish new groupings and labels. Challenging, especially with organizational gravitational forces pulling towards the established order.

Establishing meaningful distinctions calls for understanding both the context items will be perceived in and the people we intend to make sense of the information. In other words, it calls for research and testing. Creating distinctions people understand requires that you understand them yourself first. When you do, you must then prototype the new order and stress-test (and refine) it with the people it’s intended to serve. Does it make items easier to find and understand? Does it create the right context? Does it make sense to them?

I’m often hired to effect transactional change: get prospects to convert more, facilitate content discovery, reduce website bounce rates, etc. These are worthwhile goals. However, they tend to focus on short-term change, whereas information architecture deals with underlying structures that change at a slower rate.

When making information easier to find and understand, we’re also creating contexts that affect how people see themselves in relation to the organization. The distinctions we establish in the environment — how we set up each part of the place as different from the others — undoubtedly impacts transactional change. For example, clearer labeling may decrease shopping cart abandonment by making it easier for customers to understand what step of the checkout process they’re in and how many more are left to go. In this scenario, the customers find it easier to complete a transaction they were already mentally committed to.

However, these distinctions can also drive long-term behavioral change. When Amazon sets up parts of its information environments as being available only to “Prime Members,” that labeling changes more than just the content and structure of its website. Whereas formerly the customer saw herself as a loyal Amazon customer, now she knows there’s a tier of people who are somehow more loyal than her, and who get perks for so being. She, too, can join this club, and doing so influences her shopping patterns in the long term.

Changes to an environment’s information architecture must be considered with a longer-term perspective than UX designers normally deal with. Structural distinctions change not just how we think of the information we interact with, but also how we think about ourselves in relation to that information. The impact of changes to an information architecture is felt well beyond the near-term goals that are the usual focus of website or app redesign engagements.

Let’s say you’re in the market for a new dinglehopper. (What? You don’t know what a dinglehopper is? Good…) You know you need a dinglehopper, but don’t know much about them. In fact, the only thing you know about dinglehoppers is that you need one. The process of selecting the one that’s right for you will require some learning.

This is not an uncommon situation; many people need to buy things they’re only casually familiar with. For example, a young dad-to-be may want to buy a “better” camera because he’s read that his smartphone isn’t good enough to capture a baby’s nuanced expressions in low-lit rooms. Which cameras are best for this? He has no idea. He visits a camera store and sees the following options:

DSLR, Mirrorless System, Point & Shoot, Medium Format. “Aha!,” he thinks, “These are different types of cameras!” But what’s the difference between a “mirrorless system” camera and a “medium format” camera? Which is best for photographing a newborn without costing more than $1,000? One of the categories features a camera that seems to have no lens on it. Aren’t those critical for taking photographs? Does that mean he must buy lenses?

He clicks on one of the categories. He sees a list of camera products, with the following options to filter down available choices:

That’s a lot of choices! Some of them map to his existing mental model (e.g., filter by price range, show only those with free shipping) while others may baffle him (e.g. video resolution, sensor size.) He also sees a list of brands that are ostensibly camera market leaders, but he doesn’t yet know which have better reputations than others, or which specialize in particular types of cameras.

Our young friend has two problems before him:

1. he needs to know what options are available, and
2. he needs to know what the differences between them mean and how they affect his decision.

This is what we usually think of when we talk about not having enough information to make a decision. A cursory glance at the camera category in a well-stocked online store can answer (1), but answering (2) is a bit more difficult.

The way the information is organized establishes distinctions in the user’s mind. The fact there are four types of cameras (according to this store) is a good start; our friend starts thinking in terms of the ​differences between them. Then comes the hard part: knowing what those differences mean. The user must build a new mental model; he must gain an understanding of what these differences mean in this context.

Information environments vary on the degree to which they aid us along the journey of building this type of contextual knowledge. Some environments accommodate people who already have some degree of expertise, while others are designed for less experienced people. Often, the distinctions established by the environment must speak to both types of users; both pros and beginners will care about the differences in camera types, but people in the latter group doesn’t yet know it.

The environment must allow pros to get to what they’re looking for quickly. On top of this baseline findability function, the environment will also serve a didactic role for beginners. These two objectives are in tension with each other: an environment that assumes lots of contextual know-how will be unusable to beginners, and one that assumes zero knowledge will alienate pros. In designing such a place, you must strive for balance between these two objectives. Solving for (1) is easy; solving for (2) is more difficult. Doing both simultaneously while accommodating users with a broad range of contextual expertise is quite a trick.

My work has been mostly digital for over twenty-five years. As a result, I have a lot of files lying around. Some are things I’m currently working on, while others are older and less relevant to my current needs. But all of it is important to me. And it’s not just files; I also keep archives of my digital communications. This includes email mailboxes going back almost twenty years, chat threads, and (more recently) Slack channels. I also manage several critical long-term databases, including a password manager.

Making this stuff findable is a challenge to those of us who work with computers. A new computer user will soon discover that saving all her files to the desktop doesn’t scale. And while search systems in modern operating systems (such as Spotlight on the Mac and Cortana in Windows) are pretty good, they’re not omniscient — and even if they were, you often wouldn’t know what to search for to find the information you need. As a result, we still create folders to store files for longer-term retrieval.

How do you decide how to group these files? There are many options open to you. For example, if you’re a freelance designer, you could create a folder for each project, a folder for each client, or a folder for each type of file. After a while of doing this, you’ll discover this, too, doesn’t scale. Then you’ll experiment with nesting these folder structures: a folder for each client which contains folders for that client’s projects.

This folder/file structure is an information architecture designed for an audience of one: your future self. You need to be able to retrieve the things you need when you need them, which will probably be many months (or even years) in the future. This requires that you make predictions about how you will expect to look for the things you need at a different time.

This entails articulating your mental model of your digital stuff. For example, if you’re a freelance designer, client projects are most likely central to your work. As a result, projects will be an important factor in how you organize your personal information environment. (I have such a structure on​ my computer: I have a folder called “Projects” where I keep all my project files together.) If you follow this route, you’ll want to establish a consistent naming scheme for these folders, ideally featuring the project name as the label.

One of the advantages of this method is that it allows you to replicate this structure in systems other than your computer’s file/folder structure. For example, you could create a series of folders in your email application where you keep conversation threads related to each project. For sanity’s sake, you should make the naming structure consistent across systems; the project’s folder in the Finder should have the same name as the project’s folder in the mail application.

But of course, not everything you deal with is a project. So you also need to understand what the difference is between a project and not-a-project. You’ll need to store and find many things that are not-a-project. How do you group them? In my case, I have a folder in my computer called “Reference” where I keep the not-a-project stuff that I may need to refer to in the future. Under this folder, I have several sub-folders grouped by subject matter. For example, I one of these folders contains documents for the house where my family and I live.

How granular do you go with the grouping? That depends on several factors, including how many documents you plan to keep in a folder and how frequently you expect to need them. A folder that contains several hundred files probably needs sub-folders. My “House” folder has less than a dozen files in it, so it doesn’t have any sub-folders in it.

Of course, that folder isn’t called “House.” I’ve lived in several houses in the past twenty-five years. When I look for these files, I need to know which house I’m looking at. The labeling of folders is important if you want to make groupings unambiguous. (In my case, the folder’s label is the house’s street address.)

This structure didn’t emerge spontaneously; it evolved over a long period of time. There was a time in my life when I hadn’t lived in more than one house, so I didn’t need a complicated file/folder structure to store my house-related information. Personal information architectures change over time as your information needs change.

As with all information architectures, creating and managing an effective personal IA requires discipline to group and label things consistently, and flexibility to recognize when grouping and labeling schemes require tweaking. Achieving a balance between consistency and flexibility can lead to a structure that feels natural; an extension of your mind.