Naming Is the Architecture

A label is a promise about what happens when you click it. Break that promise and the person is lost, no matter how good the layout looks. The structure of a product, what is grouped with what and what it is all called, is decided before any screen is designed. That is the most leveraged design work there is, and it is nearly invisible, which is exactly why it gets skipped.

A bad label costs more than a bad layout

Move a button and a confused user still reaches the goal, a second later. Mislabel that button and they walk the wrong way with total confidence, and they do not come back to check. A wrong word does not slow people down, it sends them somewhere else. Think of a hospital with clear, beautiful signs that all say the wrong department. The building is not broken. The naming is, and the naming is what people navigate by.

This is why I treat words as the first design layer, not the last. In a lot of teams, copy is the thing that gets poured in at the end, after the boxes are drawn. That is backwards. The label is the interface. Everything else is styling on top of a decision the words already made.

A concrete case from a banking app I looked at. The main action was labelled Transfers. In testing, people who wanted to pay back a friend for dinner did not touch it, because to them a transfer was a formal bank-to-bank event, not settling up with a mate. Renaming it Send money lifted use of the feature with no other change. Same button, same place, same colour. One different word, a different mental model, a different result. The layout was never the variable.

Test the structure before the pixels exist

You can test an information architecture before anyone opens a design tool, which is the cheapest research in the whole process. Two methods do most of the work. Card sorting hands people your content on cards and asks them to group it and name the groups, so you learn how they carve up the space. Tree testing does the reverse: you give them your proposed structure as plain text, no visuals, and ask them to find things, so you learn whether the labels actually lead where people expect. Both run on a spreadsheet's worth of effort and both save months.

There are two flavours of card sort. An open sort lets people name the groups themselves, which surfaces their own vocabulary. A closed sort gives them your category names and asks them to file cards underneath, which tests names you already have. You do not need a cast of thousands. Around fifteen participants stabilises the big patterns in a card sort. Tree testing wants more, closer to fifty, because you are measuring success rates per task and rates need volume to be trustworthy. Either way the cost is a few hours, not a few sprints.

There is a third, sharper test: the first click. You show one screen and one task and record where the person clicks first. It sounds trivial. It is one of the strongest predictors of task success we have. When the first click is down the right path, most people finish. When it is down the wrong path, most do not, and they rarely recover.

Card sorting, tree testing, and the first click are not rivals. They answer different questions at different moments, and a solid process uses all three in turn: sort to shape the structure, tree test to check the labels, first-click test to confirm the choice. Here is how they line up.

Your users already told you the words

The taxonomy you designed and the vocabulary your users speak are almost never the same, and you do not have to guess at the difference. Your search logs are the best free research you own. Every query is a person telling you, in their own words, what they wanted and what they called it. When people keep searching for a word that appears nowhere in your navigation, that is not a search problem. That is a naming problem the search box happened to record.

A concrete case. A shop labels a category Outerwear. The search log fills with coat, jacket, raincoat, anorak. Nobody types outerwear, because nobody says outerwear out loud. The fix is not a synonym ring bolted onto search. The fix is to call the category what people call it. Search logs are a nightly usability test that your users run for free, and most teams never read the results.

The internal words are the sneakiest, because they feel correct to everyone in the building. A team that ships a Platform will name a nav item Platform. A user hunting for one tool inside it has no idea that is where it lives. Every industry has words that mean something precise to insiders and nothing to newcomers, and a product that leads with those words quietly sorts its audience into people who already knew and people who leave. Say the label aloud to someone outside your team. If they ask what it means, it is the wrong label.

One more structural truth: some things belong in more than one place. A red silk dress is both Dresses and Sale and Red. Forcing every item into one true location, a strict single hierarchy, breaks the moment reality gets messy. Polyhierarchy, letting an item live under several parents at once, matches how people actually look. They do not memorise your tree. They approach from whichever branch their task started on, and the structure should meet them on any of them.

The everyday form of this is faceted navigation, the filters down the side of a shop. Colour, size, price, brand, on sale: each is a different way into the same set of products, and a shopper mixes them freely. Trying to force that into one nested tree, where a product has a single home, fights how people narrow a choice. Let items carry tags and let people combine them. The single true location is a filing-cabinet idea. Users are not filing, they are hunting, and hunters come at the same prey from many directions.

The magic number that was never about menus

You have heard that a menu should hold seven items, give or take two, because of Miller's law. That is one of the most misquoted findings in our field. George Miller's 1956 paper measured two specific things: how many distinct points people can tell apart along a single scale, like pitches of a tone, and how many chunks they can hold in immediate memory for a few seconds. Neither of those is a navigation menu, which sits in front of your eyes the whole time and does not need to be memorised at all.

My problem is that I have been persecuted by an integer.

Miller opened his paper half joking that the number seven followed him around, and he would be dismayed to see it used to cap menus. A menu can hold four items or forty. What matters is that the items are scannable, well grouped, and clearly labelled, because reading a visible list is not the same task as holding sounds in your head. Later memory research pushed the real span of working memory down toward a handful of chunks anyway. The lesson is not a number. It is that you should never trim a menu to hit a figure that was measured on a completely different task.

So how deep should structure go? The honest answer is that depth and breadth trade off, and the evidence leans toward broad and shallow over narrow and deep. Every level down is another decision, another chance to guess wrong, another click before feedback. Nielsen Norman Group's testing lands here repeatedly: users do better with a few wide levels than with many narrow ones. Deep trees hide things. But a totally flat wall of fifty links is its own failure, because nothing is grouped and the eye has nowhere to rest. The craft is grouping, not counting.

There is a cost to every extra level, and it is not only the click. Each step down asks the person to hold a guess in mind and wait to see if it paid off. Get it wrong three levels deep and the walk back is long and demoralising, which is when people give up and use search instead. This is also why mega-menus earn their keep: they flatten two or three levels into one glance, so the choice happens once, in the open, rather than as a chain of blind bets. Show the branches instead of making people tunnel through them.

A name in a codebase outlives everything

Naming is not only user-facing. Inside a design system or a codebase, a component name is an interface too, and a bad one propagates for years. Call a component Card when half of them are not cards and every new engineer inherits the confusion. Rename it later and you touch a thousand files, so nobody does, and the wrong word calcifies into the architecture. The cost of a bad name is not paid once. It is paid every time someone reads it, which in a shared system is thousands of times.

The reason bad names persist is that renaming is expensive and invisible, so it never wins a priority meeting. A rename touches every file that imports the thing, risks breaking something, and produces no new feature to demo. So the wrong word survives, and every engineer who joins learns it, uses it, and passes it on. The cheapest moment to name something well is before anyone depends on it. After that the name is load-bearing, and load-bearing names are the ones nobody dares to touch.