Nobody Names Anything: Why Your Features, Plans, and Buttons Are Called the Wrong Thing

The reason naming gets neglected is a categorization error. Names get filed under copywriting, copywriting gets filed under marketing, and marketing gets involved after the product is built. By the time anyone whose job is words looks at the product, the names are already in the database, the API, the documentation, and the users' heads.

But a name isn't copy. Copy is persuasive text that sits alongside an interface. A name is the interface. It's the handle by which a user grasps a concept — the only access they have to an abstraction that otherwise has no physical form. You cannot see a Workspace. You cannot point at an Automation. These things exist only as words, and the word is the entire user-facing reality of the concept.

This makes naming closer to information architecture than to copywriting. The names in a product define its conceptual model: what kinds of things exist, how they relate, what you can do to them. A user learning your product is learning your nouns and verbs. If those nouns and verbs are borrowed from your engineering data model rather than derived from how users think about their work, then learning your product means learning your internal architecture — which is a burden you've transferred from your team to every person who uses the product.

The cost is paid at scale, invisibly, forever. Every new user pays it during onboarding. Every existing user pays a smaller version of it every time they have to translate between what they mean and what your product calls it. Every support agent pays it during every conversation where they have to figure out which product concept the customer is describing in their own words.

Bad names aren't the product of bad judgment. They're the product of names being created in contexts where naming isn't the task at hand.

The data model. The largest source of product nouns is the schema. Engineers building a system need to name entities, and they name them for internal coherence — what makes the architecture legible to the people maintaining it. These names are often precise, technically accurate, and completely disconnected from user vocabulary. A concept the user experiences as "the thing I'm working on" becomes an Entity, an Instance, a Record, a Resource. The name is correct from the inside and meaningless from the outside.

The ticket title. Features are frequently named by the ticket that requested them. Someone writes "add bulk tagging support" in a project management tool, the feature gets built, and it ships as Bulk Tagging — a name that describes the implementation rather than the user's goal. The user doesn't want bulk tagging. They want to organize a lot of things quickly. The feature name describes what the code does rather than what the user gets, which means the user has to understand the implementation to recognize the feature as the solution to their problem.

The internal metaphor. Teams develop shorthand. A concept gets an internal nickname during development — often a metaphor that made sense in a specific conversation — and the nickname becomes the name. These names are usually vivid and memorable to the team and opaque to everyone else, because the shared context that made the metaphor land isn't available to users. Every team has at least one feature whose name is an inside joke that shipped.

The competitive borrow. Sometimes a name is chosen because a competitor uses it and the category seems to have standardized. This is occasionally correct — using the category-standard term reduces learning cost when users arrive with existing expectations. But it's often lazy: adopting a competitor's vocabulary for a concept that works differently in your product, which creates a name that primes users to expect behavior your product doesn't have.

The aspiration. Marketing sometimes names features for how impressive they sound rather than what they do. Smart, Intelligent, Advanced, Pro, Studio, Suite. These modifiers carry no information — they tell the user that the company thinks highly of the feature, which the user already assumed. A name that spends its limited characters on self-praise has none left for explanation.

A name in a product has three jobs, and most bad names fail at least two of them.

It has to be comprehensible on first encounter. A user who has never seen the product should be able to form a roughly correct guess about what the thing is from the name alone. This doesn't require the name to be fully self-explanatory — some concepts are genuinely novel and require explanation — but it requires the name to point in the right direction rather than in a wrong one. A name that leads to an incorrect guess is worse than one that leads to no guess, because the user proceeds confidently in the wrong direction and discovers their error later, which costs more than not knowing would have.

It has to be findable. Users look for things by searching, scanning menus, and asking. All three depend on the name matching the words the user would naturally use. A user who wants to change how often they get emailed will search for "notifications" or "emails" — if your product calls it "Communication Preferences" and the search doesn't match on synonyms, the setting is functionally invisible. The findability requirement is why the best product names are usually the plainest ones: the word the user would use, unadorned.

It has to be stable. A name that gets used inside the product, in the documentation, in support conversations, in the sales process, and in customers' internal discussions accumulates enormous inertia. It becomes the shared vocabulary of everyone who touches the product. This is exactly what you want from a good name and exactly what makes a bad name expensive: the wrong word, once established, is very difficult to change, because changing it invalidates everyone's mental model and every document written about it.

Nouns get most of the naming attention, but the verbs — the labels on buttons and actions — are where naming failures produce the most immediate damage.

Every button label is a promise about what will happen when it's pressed. The user reads the label, forms an expectation, and acts. If the label and the outcome diverge, the user experiences a small betrayal — they did what they thought they were doing and something else happened. Repeated across a product, these small divergences accumulate into a general sense that the product is unpredictable, which is one of the fastest ways to lose a user's confidence.

The most common verb failures are vagueness and euphemism. "Submit" tells the user nothing about what they're submitting or what happens next; "Send invoice" tells them exactly. "Continue" is a promise that something further exists without saying what; "Review and pay" sets an accurate expectation. Vague verbs feel safe to write because they're hard to be wrong about, but their safety comes from carrying no information, which pushes the interpretive work onto the user.

Euphemism is the more damaging failure. When a destructive action is labeled softly — "Remove" for something that permanently deletes, "Manage subscription" for a page that's the only route to cancellation — the label is protecting the company from the user's decision rather than informing the user about the consequence. Users notice this eventually, and when they do, the discovery costs more trust than the honest label would have cost in conversions.

The test for a verb label is whether a user who reads only the label, and nothing else on the screen, would correctly predict what happens next. Most labels fail this test. Most could pass it with a more specific word.

Names get locked in fast, so the window for testing them is short and worth using deliberately.

The cheapest test is the blank-slate question: show someone unfamiliar with the product only the name and ask what they think it is. Not the interface, not the surrounding context — the word alone. Their guess reveals what the name communicates in isolation, which is close to how it will be encountered in a search result, a navigation menu, or a support conversation. If five people guess five different things, the name isn't carrying meaning.

The reverse test is more useful and less commonly done: describe the concept in plain language and ask people what they would call it. This surfaces the vocabulary users bring to the problem, which is the vocabulary your product should be borrowing. When several people independently reach for the same word, that word has a strong claim to being the right name — it's already in your users' heads, which means adopting it costs them nothing to learn.

The findability test is a search log review. If your product has in-product search or a help center with search, the queries users type are a direct record of the words they use for your concepts. A high volume of searches for a term that doesn't exist in your product is a naming mismatch, stated in your users' own words, sitting in a database that most teams never read for this purpose.

None of these tests are expensive. All of them are cheaper than renaming a concept after it's shipped.

Sometimes a name is wrong enough to be worth changing, and the calculation is harder than it looks.

The cost of renaming is not the design work. It's the invalidation. Every piece of documentation referencing the old name becomes wrong. Every support macro, every help article, every recorded training video, every blog post, every customer's internal wiki. Every user who learned the old name has to learn the new one, and during the transition period both names are in circulation, which is more confusing than either name alone. Search traffic to content optimized for the old term drops. Customers who described the feature to colleagues using the old word now sound out of date.

Against this, the benefit of renaming compounds forward: every future user learns the better name, every future document uses it, and the accumulated confusion of the wrong name stops growing. The calculation therefore depends heavily on where the product is in its life. Renaming a concept in a product with two hundred users is cheap and almost always worth doing if the name is wrong. Renaming the same concept at fifty thousand users is expensive enough that the wrong name often stays wrong permanently.

The practical implication is that naming deserves disproportionate attention early, when the cost of being wrong is still low and the cost of fixing it is still bearable. The moment a name is in the database is not too late to change it. The moment it's in ten thousand customers' vocabulary usually is.

Naming is unusual among design decisions in that it costs almost nothing to do well. It requires no additional engineering, no visual design time, no development cycles. Changing a name before launch is a find-and-replace. The entire cost is attention — someone deciding that the words are worth thinking about, and thinking about them before they harden.

Almost no one does this. Product teams will spend three weeks on the visual design of a feature and eleven seconds on what it's called, then ship a well-designed feature that users can't find because it's named after the ticket that created it. The visual design was expensive and the name was free, and the name is doing more work.

The products that feel effortless to learn are usually the ones whose names were chosen rather than inherited — where someone asked what the user would call this thing, and then called it that. It's not sophisticated work. It's just work that someone has to decide to do, at the moment when doing it is still cheap.