Name the Thing Before You Build It

Naming gets treated as the last task. The work is built, it functions, and someone opens a document at the end to decide what to call it. By then the name has no leverage left. It is a label on a finished box.

Try it in the other order and it stops being a labelling exercise. It becomes the cheapest design review you will ever run.

A name is a compression test

To name something in plain words you have to know what it does, who it is for, and what it is not. If any of those three are unsettled, the naming conversation stalls immediately, and the stall is the useful part. It is a scope problem surfacing weeks before it would have surfaced in code.

The teams that name late are not saving time. They are deferring an argument until the argument is expensive.

Every feature with a vague name has a vague owner, a vague boundary, and a launch date nobody believes.

Signs the name is telling you something

Watch for these in the naming conversation itself:

• The name needs a conjunction. Anything called Reports and Insights is two features wearing one coat.
• Nobody can say it without a caveat. If every explanation begins with well, it depends, the scope is not agreed.
• The name describes the mechanism, not the outcome. Users do not want a sync engine, they want their work to be there on the other laptop.
• It only makes sense inside your team. Internal metaphors are fine on a whiteboard and disastrous in an interface.

Plain beats clever, almost always

Clever names age badly and travel poorly. They need explaining, they do not survive translation, and they make search results worse. Plain names cost you a moment of imagined excitement and repay it every day afterwards in support tickets that never get written.

The test is simple. Say the name to someone outside the team, in a sentence, with no preamble. If they respond with a question about what it is, the name is not finished. If they respond with a question about how to get it, it is.

Names are cheap now and expensive later

Once a name exists in a URL, an analytics event, a database column, a help article and a customer's vocabulary, changing it is a migration. Before any of that exists, changing it costs one conversation.

So have the conversation while it is still free. Write the name at the top of the brief, before the first screen. If the team cannot fill in that line, the brief is not ready, and no amount of building will make it ready.