“What do we call this thing?”
A tactical playbook for user-centered product naming decisions
Just as Abbott and Costello taught us, clear and deliberate naming is critical to effective communication. Without it, we’re still left wondering who’s on first.
Even with a shared understanding of the weight of effective naming, it remains one of the most pesky problems a business faces. After several years of UX research, workshops, and design work at Google, I created a guide to add structure and rigor to the naming process so that practitioners could reach consensus on names more efficiently. The content was gathered through academic publications, learnings from painstaking experiences, and collaboration with partners across product teams, researchers, and writers.
The exercises are largely geared toward product teams, but my hope is that anyone can use these resources to make more efficient, informed naming decisions.
Why is naming so important?
The criticality of naming is difficult to overstate. We often feel the pressure of high stakes, especially for highly visible features or products, because a name is the user’s first impression of the feature. We want it to convey our intended meaning while also aligning to users’ mental model of our products and the context in which they use them.
Naming can also be difficult to change if we get it wrong. Users may have already learned a name and become accustomed to using it in their everyday vernacular. A name change at a late stage could greatly impact metrics like usage or satisfaction, given the potential for change aversion or reduced recognition. Naming is an important decision to get right the first time.
If first impressions weren’t enough pressure, research has also demonstrated that users rely on names to draw conclusions about a system as a whole. Choosing the wrong name can lead users down a path of making errors with dire consequences, or mistakes that are hard to recover from. We observed the potential for critical error in our research on naming an architecture component within Google Cloud, in which multiple definitions of the same word (“service”) could cause users to unintentionally remove or edit the wrong cloud resources.
Why is naming so hard?
“The reason naming is both hard and important is because it is an act of communication; without good names your code might as well be written in, well, code.” — Kevlin Henney
The task of naming is daunting, difficult, and frequently ambiguous. There are a number of reasons it’s difficult; the “best” name may already be taken by another product or organization, or the construct to be named may contain multiple smaller, only loosely (if at all) related constructs. If you’re trying to descriptively name a room of animals that includes a ladybug, a badger, an orca, and a parakeet, what should that room be called? “Things with eyes” doesn’t have a great ring to it.
Much of the difficulty has to do with the task of explaining complicated things simply; we want a name to convey some sort of meaning that’s understandable to users as quickly as possible, which is especially challenging when that feature or product is complex. New users are already learning something for the first time, and new terminology only heightens that learning curve. As a result, we have the intimidating task of distilling what this construct is and what we want users to interpret from it. We have to balance brevity with meaning.
In a pragmatic sense, these decisions can often be contentious and politicized, especially when multiple individuals or groups have a stake in the construct you’re naming. Conflicts like these compounded with the baseline difficulty in naming can cause us to procrastinate or toil on these decisions for longer than we should.
Escaping analysis paralysis
How might we focus our attention on the right naming problems? A user risk analysis is one strategy to prioritize problems with stakeholders. This approach has been useful to decide which naming issues to spend further resources on (e.g., workshops, research), and which ones aren’t worth pursuing further. It’s served this purpose well in the past, but the exercise is certainly not exclusive to naming decisions.
The matrix below answers two questions:
1) The Y axis (likelihood of error) is asking, “What are the chances a user could make a mistake if we pick a bad name?”
2) The X axis (risk for the user) is asking, “And if they do make a mistake, how severe are the consequences for them?”
Low risk might be a scenario where if we choose a bad name, a user clicks a website navigation item and ends up on a page they didn’t expect. They have to go back and find the right page. A high risk could be a user deleting a database full of business-critical information.
To determine where a name falls, it can be helpful to think through who the primary users of this construct are/will be and what their usage journey looks like. For example, my team recently considered renaming a feature for fear of confusion with another similar term. After this user journey exercise, we realized that a user won’t encounter this concept until after visiting documentation that precisely defines it, so the likelihood of making an error was low. We ended up leaving the name as it was.
When you’re confident you can make a risk assessment, target the names that fall in the top right corner first. If none do, consider the bottom right corner as it shows the highest risk for users. If no naming problems fall into the high risk boxes, consider whether the constructs are worth the effort of formally naming. After all, not everything needs to be named.
Do we really need a unique name?
The act of naming itself can actually make a concept appear more complicated because it communicates a distinct concept. When possible, it helps to leverage plain language or industry standards instead, and treat naming as a last resort.
To avoid introducing new concepts where possible, ask:
- Can we use plain language as an identifier instead of a new noun? Related constructs may benefit from not being named uniquely (e.g., “[brand/product name] for travel”)
- Are there current constructs that could be expanded to include the new one?
- Is there context we can provide that would clarify a name? Industry terms alone can be vague.
When a new name is inevitable, it helps to leverage a templated and industry-supported approach that includes a few best practices, brainstorming, and ultimately evaluating candidate names against criteria.
How do we pick a name?
Start with best practices that are consistent with data on brand and product naming. Broadly, a good name tends to be:
- Distinct: Names should be qualified and distinguished from similar names that refer to a different construct.
- Descriptive: Names should reveal information about the purpose or functionality of the feature. Unlike metaphorical (e.g., Nest) or fanciful (e.g., Waymo) names, more literal names emphasize precision and require little explanation.
- Aligned: Take into account industry standards, colloquial uses, and related products or taxonomies. Repetition can build confidence; using the same terms across our products and documentation can help validate users’ assumptions about our naming scheme.
- Persistent: Think long-term and consider how this construct may change with time. Make changes and seek alignment while it’s still early. Don’t assume it’s “just one more name to learn” for the user; new concepts add up quickly and can impact cognitive load and the overall user experience.
It’s often best to avoid names that are:
- Ambiguous: A name that is not sufficiently descriptive and/or could mean many things
- Contradictory: A name that conflicts with colloquial or standard definitions of the same term
- Long: Names greater than 2–3 words can be cumbersome to speak and type
- Abbreviated: Undefined abbreviations can lead to confusion and misunderstanding
With those guidelines in mind, it’s important to call out that the best is the enemy of the good when it comes to naming. Names will almost always have trade-offs and it’s not only likely, but also expected, that not everyone will be equally happy with the name you land on. That is ok. In fact, discomfort or lack of familiarity with a name can even help elicit empathy for users who are learning about this construct for the first time, which can push us to build products that better meet customers where they are.
Acknowledging these best practices upfront can be beneficial in setting expectations and ensuring everyone is prepared to think critically about naming.
Assemble your naming team
If you are a lone namer, this part won’t be as relevant to you. If you work with a team, it’s important to think about the key decision-makers for the construct to be named and any other products, teams, or individuals that will be affected by the outcome. Be sure to include a variety of roles if you can (e.g., PM, engineering, design, research, writing, marketing). Keeping the workshop limited to ~10 people tends to help keep discussions on track and productive; if there is a large group of people that need to contribute, ask for their input prior to the workshop and add their contributions to the discussion as the facilitator.
Align on naming criteria
The criteria a name should meet depends on what we’re naming and should be determined by our goals for the name. If naming a brand instead of a feature, for example, it may be more important that the name is memorable and nostalgic vs. descriptive and literal.
A few criteria that have worked well as starting points for general feature and product naming:
- Avoids conflicts with existing products and industry language
- Describes functionality or purpose
- Scales well with anticipated changes to the product
- Easy to read and say
- Works in all interfaces we expect the name to appear in
- Aligns with known user understanding (if we happen to have this data)
Brainstorm
There are countless brainstorming techniques that will work just as well for naming as any other ideation topic. I’m partial to a sticky note approach, in which quantity is favored over quality. Each participant writes one name per sticky note. I might give teams a few minutes to brainstorm as many names as they can per certain important categories. For example, we may take 5 minutes to brainstorm related industry terms, 5 minutes focusing on differentiators of this product, and 5 minutes on metaphorical terms. Jamboard is a great tool for conducting this exercise remotely.
Take time to discuss the merits of everyone’s ideas, then narrow down the pile to 10 or fewer names through discussion or voting.
Evaluate final candidates against criteria
A criteria matrix can be useful in determining which names are most appropriate given the criteria decided earlier. As a team, rate each item on a numeric scale, add weights to account for relative importance of each criterion if you prefer, or use a simple yes/no/maybe approach to visualize the frontrunners.
If you’re short on time, these ratings can be collected offline in a survey and then tallied to determine the final scores.
You’ve got names! Now what?
The outcome of the above exercises should be 2–3 top candidates, not one single name. This is because there are often still hurdles in the form of localization or trademarking that may be required to publish a name externally. At this stage, it’s possible that your favorite name won’t work because it doesn’t translate to a certain language, it has a connotation in another culture that would misrepresent your intent, or it’s too similar to a product that already exists. It helps to try and anticipate these challenges ahead of time by including ‘avoids existing conflicts’ as a selection criterion and including marketing colleagues early in the process when we can.
Despite our best efforts, we can’t foresee every possibility. To avoid going back to the drawing board, it’s best to stay prepared with 2–3 names in your back pocket, and ideally test the names with your target market to improve perceptions.
This is a lot. Where do I start?
Taking the first step can be intimidating. Check out this decision tree to help light the path that best suits your naming questions.
Stage 1: Make sure a new name is necessary and review best practices
Stage 2: Plan a naming strategy that fits your needs
There is no single right way to solve a naming problem. Introducing structure to the process can greatly aid our ability to generate reliable names that teams can quickly reach consensus on to move forward. It helps to experiment with criteria and brainstorm techniques to figure out what works best, and establish a consistent approach to reduce the toil and impulsivity that can plague naming decisions. Ultimately, aligning on a naming strategy prompts more progress organizationally, which cascades down to the more important outcome: effective communication with our users.
