Information Architecture

Early websites and software tended to publish the org chart. Pages written by the sales team lived under a sales heading, documents written by engineers lived under a technical one. From the inside this felt natural. Every team owned a shelf, put its own material on that shelf, and never had to negotiate with anyone about where something belonged.

The cost landed on the other side. Someone trying to extend a warranty had no way of knowing whether that page was filed under product information, customer support, or purchasing. The boundary being used was internal. Customers do not know how a company divides its departments, and there is no reason they should.

So the support queue filled with a particular kind of exchange. A customer would say they could not find a screen, and the agent would read out the address for them to type in. That is handing over coordinates instead of giving directions. It resolves the one case and leaves everyone else searching for the same thing exactly where they were. None of it registers as a failure in the numbers, either. The page loads, the servers are healthy, the error log stays empty, and people simply never arrive at the place they wanted.

Part of why this lasted so long is that nobody owned it. Making a screen look right belonged to designers and making it work belonged to engineers, but deciding which bucket a thing goes in and what that bucket is called belonged to no one. It got settled ad hoc, screen by screen, by whoever happened to be building at the time. The predictable result was one product calling the same object a folder in one place, a project in another, and a space in a third.

Without a name for the problem, the same issue kept getting reported as different problems. One quarter the complaint was that the menu felt cluttered. The next it was that search never returned the right thing. The quarter after that, a report said nobody was using a newly shipped feature. Those were three symptoms of one cause, but they arrived through separate channels and were handled separately. The menu got trimmed, search got patched, a tooltip got added — and people still could not find what they came for.

The term information architecture filled that gap. Much like deciding how many floors a building has and what each floor is called before drawing any rooms, it carved out a step that happens before screens get designed. Naming the step brought three things with it. Someone became responsible for the decision, the decision got written down somewhere, and disagreement gained a basis. "This menu feels wrong" ends as a matter of taste. "Nine of twelve participants looked for this item somewhere else" points at something to fix.

The terms under information architecture fall into three groups: the classification that divides content and names it, the representation that turns those divisions into a drawing, and the findability layer that gets a person to their destination inside it.

Classification holds two entries. It decides the backbone itself, so everything else rests on what happens here.

1. Taxonomy — the hierarchy that sorts items into categories. Pagedeck's documents could be grouped by team or by type of work. Group by team and every internal transfer raises the question of where that person's documents go. Group by type and the meeting notes and the spec for one project end up on opposite sides of the tree. Which is right depends on what people have in mind when they come back looking for something, not on which tree is tidier.
2. Labeling — the names given to those categories. Whether one area is called a workspace, a team space, or an organization gets settled here. Vocabulary carried over from internal meetings reads instantly to the people who built the thing and means nothing to someone opening the product for the first time. A correct division with the wrong name still fails: the user walks past the right category without recognizing it.

Representation holds one entry. A sitemap draws the whole structure as a tree. Structures always look clean in someone's head and rarely survive contact with paper. Drawing it exposes the branch that takes five clicks to reach, the level where nineteen items sit side by side, and the pile of things that fit nowhere and got swept under a heading called Other. The drawing does not make the decisions. It shows which decisions are waiting.

Findability holds three entries, and each one gets a person to their destination a different way.

1. Navigation — the controls that move someone between screens. Top menus, side lists, and the trail showing the current location with the path above it all belong here. This is the form the classification actually takes in front of a user, which is why a well-built tree with only half of it surfaced in the menu behaves as though the other half does not exist.
2. Search UX — the experience running from the moment a query is typed to the moment results are read. It is the bypass used when someone does not know the classification or does not agree with it. What to show for a typo, for a team's internal word that differs from the product's word, and for a query that matches nothing are the questions that live here.
3. Faceted filter — narrowing a set by stacking conditions across attributes. Pick an author, then a date range, then a status, and what remains shrinks. Where a hierarchy allows exactly one path to each item, this allows several criteria at once, which is how products whose items genuinely belong in more than one place work around the limits of a tree.

People reach a destination along two broad routes: stepping down through categories, or typing a query and skipping the tree entirely. Which route dominates varies by product. When there are hundreds of items and people know the exact name of what they want, search leads. When people are still finding out what exists, menus lead. A product like Pagedeck, where the thing being found is usually something the person wrote themselves, mixes both. Yesterday's document gets opened from a recent list; a meeting note from six months ago gets found by typing half a remembered title. Improving only one of the two routes therefore tends to fix only half the problem.

The three groups stack in order. Classification sets the backbone, representation makes it visible, and findability lets people walk on it. Weaken any one and the others lose their effect. When the classification does not match how people think, no amount of menu polish helps and everyone retreats to the search box. When it does match but the menu runs five levels deep, features exist that users never learn about. Leaning entirely on findability has a ceiling too: good search buys time, but as long as things are named inconsistently, queries and item names keep missing each other and results keep coming back empty.

"Let's settle whether this lives in settings or in the documents menu before I draw anything."

The category a feature belongs to has to be decided before its screen can be designed.

"In the card sort, nine of twelve people put templates under documents."

This reports where users expect the thing to be, not where the team filed it.

"There are nineteen items in the sidebar. Adding a twentieth won't make it visible."

One level is carrying so much that adding to it has stopped doing anything.

At Pagedeck the term came up constantly during the quarter when document counts outgrew the original structure. Once the average account passed forty documents, teams started nesting folders deeper, and when Noa drew the sitemap the deepest branches ran five levels. Anything below level five was only ever being opened through search. Nearly all folder-based opens happened in the top two levels, and past the third level the only person who knew what was inside a folder was the person who had created it.

The discussion started as folders versus tags and quickly turned into a permissions question. Pagedeck attaches sharing permissions to a folder and lets the documents inside inherit them. Tags break that, because a document can carry several at once and inheritance no longer has a single source. When Theo pointed this out, it became clear that choosing a classification model and choosing a permission model were the same decision.

The resolution was to split the roles rather than pick a winner. Folders stay as the one place a document lives, and permissions attach only there. Tags become labels that can be applied freely regardless of location. Mia wrote the decision down and required that every new feature state which of the two it hangs off before work starts. Leaving behind a rule for where the next thing goes lasts longer than getting the current structure exactly right.

The most common mistake is reading information architecture as menu design. The visible output is a menu and a sidebar, so the association sets quickly. The real scope runs well past anything a user would call navigation. How search results get grouped, which attributes appear as filters, what words go in a URL, whether notifications are sent per document or per folder, and where permissions attach are all decided on the same backbone. Read narrowly, a team tidies the menu and leaves the rest alone, and then a clean menu sits next to a search index still matching old names and notifications that break every time someone moves a folder. One question separates the cases: if a decision is setting what counts as being in the same group as what, it is an information architecture decision, whether the screen it lands on is a menu, a filter, or a notification setting.

The second mistake is treating it as an up-front task that finishes. It produces a sitemap early in a project, so it looks complete once that drawing is done. Structures rarely break at the start, though. They break as features arrive one at a time. A feature that fits no existing category needs a temporary home, and that home acquires a name like Other or More. Temporary once is fine. Two years later eleven things live there, and by then moving them changes their addresses and breaks every link pointing in from outside. Left alone, restructuring gets more expensive every quarter, and the more expensive it gets the longer it is deferred. Keeping a rule for classifying whatever arrives next is worth more than drawing a perfect tree on day one.