Labeling

A product can have its categories divided correctly and still leave users unable to reach what they want. The structure isn't wrong — the names hanging on it are not the words users use.

When Pagedeck was first built it needed a place where a team's documents lived together, and in internal meetings that place was always called the workspace. The word went straight onto the menu, and the same support question kept arriving from first-week users: where do I see my team's documents? The screen they were looking for sat right behind the workspace menu. They read the word and didn't recognize it as the place they wanted, so they wrote in instead of clicking.

A badly named thing may as well not exist. The categories are right, the screens are built, and users walk past the correct door anyway, while the team concludes the feature is missing and starts building a second version of something it already has. Labeling exists to prevent that loss by treating naming as a decision rather than a matter of taste.

Choosing a name runs through five steps, and the point of the sequence is that nothing goes on screen straight from a meeting room.

1. Collect the words users already use. The raw material is the phrasing in support tickets, the queries people actually type into the product's own search box, and interview transcripts. In Pagedeck's query log, "workspace" appeared three times in a month and "team documents" appeared more than two hundred times.
2. Match the form within one level. When items sitting in the same row mix nouns and verbs — Documents, Settings, Share — the reader has to work out what kind of choice this is every time. Make them all nouns or all actions, and keep the same rule across sibling levels so the pattern holds as people move down.
3. Pick narrow words. Manage, Tools, and Other can hold anything, which means they tell you nothing. "Other" is the name that gets attached when nobody decided what belongs there, and from that moment the group only grows. The wider the name, the sooner you have to split what's inside it.
4. Test it. Card sorting has users group items themselves so you can see what basis they divide on; tree testing shows only the menu names, with no screens, and asks where they would look for a given item. The second one measures the name itself. If three people in ten pick the right branch, the name has to change.
5. Record the decision in one place. When the product screen, the welcome email, and the help center each call the same thing something different, users take them for different features. The decision goes into the terminology list kept by whoever owns UX writing, and later screens pull from there.

Menus are not the only place a name gets chosen.

Navigation is the most visible one. The five to seven words in the top bar and the left-hand list are the entire view users get of how the product is organized. Every node drawn on the sitemap — the tree diagram of the whole screen structure — has to be given one of those words, and a branch that gets a vague one is effectively hidden.

Buttons and notices do the same work. Short strings of this kind are microcopy, and whether a delete confirmation reads Confirm or Delete document decides whether people press it knowing what they are doing. When a dialog offers only Cancel and Confirm, you have to reread the message to work out which one destroys something.

Every node in a classification scheme needs a name too. Taxonomy decides what hierarchy items are divided into; labeling decides what each level of that hierarchy is called. Filters work the same way. Listing open and locked documents under Status rather than Visibility changes how many people open that filter at all.

It also interlocks with search UX. When the word a user types differs from the word the product uses, results come back empty, and you can fix that either by improving search or by renaming the thing in the user's words. The second is usually worth considering first, because renaming rescues the people browsing the menu as well as the people searching.

"That menu name is internal jargon. Nobody arriving for the first time will recognize it."

A word that only works inside the team went out onto the screen.

"We're calling the same thing different things on different screens. Let's pick one."

The naming decision was never written down anywhere.

"Let's put three candidates through a tree test instead of deciding here."

Measure which one people pick rather than settling it in the room.

After the workspace tickets piled up, Noa put together three candidates: Workspace, Team space, and Team documents. Twelve people were asked in a tree test where they would find last week's team meeting notes. Four pointed at Workspace and nine pointed at Team documents, and the split was clear enough that nobody argued for keeping the old word.

Changing it cost more than editing one screen. The word was baked into fourteen help articles, two onboarding emails, and the support reply templates. Mia built the list and they changed it in one pass. Over the following month, the "where do I see my team's documents" question dropped from eleven tickets to one.

The most common assumption is that naming is a matter of taste. There's no obvious right answer, so it gets settled by whoever has the most authority or by a show of hands. But a name is measurable: it's the share of users who pick the right branch. Measure it and gaps of more than two to one between candidates are not unusual, which is a larger difference than most redesigns produce. A name chosen on taste quietly loses that difference in users, and nothing anywhere records the loss.

Putting it off is just as common. It looks like a word on a screen, so it looks cheap to change later. But the word spreads outside the product over time. It goes into help articles and onboarding emails, it becomes the word customers use when they write in, and it shows up in integration docs written by other teams. A change that takes an hour right after launch takes several days a year later, which is why most teams end up never making it. Names are cheaper to settle before they set.