Naming things is design
Menu labels, button copy, file names. The words are the invisible half of information architecture, and when they're right, everything else gets easier.
Watch someone use a website’s navigation sometime. Not where they click; the moment before. The cursor drifts between “Solutions” and “Services” and “What we do,” hovering, deciding, because the site is asking them to guess which drawer their thing lives in.
That pause is a design failure, and not one pixel caused it.
Design reviews almost never catch this. We critique spacing, hierarchy, color, type. The labels ride along from the wireframe, where somebody typed a placeholder in fifteen seconds, and placeholders have a way of shipping. Lorem ipsum gets replaced. The words in the menus and buttons, strangely, often don’t.
Menu labels
A navigation item is a promise about what’s behind the door. “Pricing” is a good promise. “Resources” is a junk drawer with a nicer handle; it usually means “we had four leftover things and a menu slot.” Every vague label transfers work from you to the visitor, and visitors don’t do homework. They leave.
Button copy
“Submit” describes the database’s experience. The human is doing something else entirely: sending a message, booking a call, finishing an order. Name the button after their action and hesitation drops, because now the interface is confirming their intent instead of announcing its own plumbing. When a button says exactly what happens next, you don’t need the reassuring microcopy underneath it, or the tooltip, or the confirmation modal apologizing for the ambiguity. Two right words can retire three interface elements.
Consistency is part of this promise. A name is a small contract with the visitor, and the contract includes not changing the terms mid-journey. If the header says “cart,” the checkout can’t say “bag,” and the confirmation email can’t say “order basket.” Each switch is tiny. Together they teach the visitor that words on this site are decorative, which is a terrible lesson to teach right before asking someone to read a form carefully.
File names and field names
Internal names leak. The CMS field called content_block_4 becomes a training session. The image named final-final-v3.jpg becomes the file nobody dares delete. Naming things clearly inside the build is a kindness to the next person, and there’s always a next person, even when the next person is you in eleven months with no memory of what any of this meant.
Here’s the part we care about most, though, and it runs deeper than tidiness.
The name is a test of the idea.
When a name comes easily, the thing usually deserves to exist. When you can’t label a section of the site without a comma and a slash, that isn’t a writing problem. The design is telling you the section is really two sections, or none, and no amount of layout will rescue a category that shouldn’t be there. We’ve had whole sitemaps fall apart under this test, and every one of them deserved it.
It works in reverse, too. Get the name right and everything downstream gets easier: the honest label shrinks the layout, kills the explanatory paragraph, retires the icon that was trying to rescue a vague word. A page full of things named for what they are barely needs designing at all, which is roughly the highest compliment a page can receive.
So we treat naming as design work, scheduled and argued over like design work. Real labels in the wireframes from day one, because a wireframe with placeholder words is testing a site that will never exist. Someone at the table whose job is to say “what would a stranger call this?” And a standing rule that nothing ships called “Learn more.”
Half of information architecture is invisible. It was never the boxes and arrows; it’s what the boxes are called. Fight about the words the way you’d fight about the homepage.
The cheapest redesign is a rename.
