Navigating the cross-functional world of naming

Naming is in our nature. As kids, we named our stuffed animals and pet rocks. As adults, we name our cars and robot vacuum cleaners. It’s a way to express ourselves and signal an object’s significance. After all, Meryl Sweep isn’t just an award-winning vacuum, it’s a part of the family.

When it comes to product naming, however, the process is far less creative. Naming products, features, and plans effectively is more about logic than imagination. Names signal a product’s purpose, benefit, or behavior and collectively align user expectations with functionality and value. 

The process of naming is intensely cross-functional because the result touches every part of the consumer journey. But when so many teams come together, we often end up with far-reaching expectations for what a name can do. Marketing wants it to attract attention; Sales wants it to convert a purchase; Brand wants it to uniquely express our identity; Legal wants it to be untrademarked, and so on. 

A name can’t be designed to do everything; it’s simply a signal. Yet creating names can quickly become an overwrought, political process with little focus on user needs. So how can we take some of the stress and emotion out of it? 

At Electrolux, we recently introduced global naming criteria to set the standard for what makes a good name. The project revealed how important it is to have a common language for teams to use, and offered a clear prioritization for any naming process. While our efforts to standardize naming are still underway, here are a few of my takeaways from the project.

Subscribe to the Button newsletter!

Get more valuable content design articles like this one delivered right to your inbox.

What is a name?

There are many different types of names in any product ecosystem. With so many teams taking an interest, it’s important to define each type to clarify roles and responsibilities. Do you mean a brand name? Or perhaps a product or feature name? What about names for subscription plans or tiered offerings? 

At Electrolux, we tried to make naming as simple as possible by dividing our names into three types (Figure 1): 

• Product or series: These names describe the product range or model series. They’re often branded, use title case capitalization, and are rarely translated from English.
• Feature: These names describe key product features, and are reused across multiple appliance types and generations. Much like product or series names, they also use title case capitalization and are rarely translated from English. 
• Descriptive function: These names are more like labels for product functionality and UI elements, such as “favorites” or “child lock.” These names are not branded, use sentence case capitalization, and are almost always translated. 

When we defined these name types, we also agreed on the following workflow: Marketing leads work on product or series names, whereas UX Writing leads work on descriptive functions. We collaborate closely on feature names because they’re highly relevant to both the purchase experience and user experience.

If you’re raising an eyebrow at “descriptive functions,” I don’t blame you. Every organization will have different naming needs based on their product complexity. At Electrolux Group, we needed to distinguish the branded features from the many other functions available on our appliances (ovens, dishwashers, laundry machines, etc.). Feature names often come with added storytelling to attract and explain. We can lean into the brand voice a bit more and aim to trademark, which often results in a more abstract or evocative name. In contrast, descriptive functions come with little to no context, so we need straightforward labels.

Prior to this documentation, content designers would often get random, one-off requests from different markets to change general use terms, like switching “Favorites” to “Saved” for one generation of appliance. This would disrupt our efforts to standardize terminology and translations across product verticals and UIs. But distinguishing “features” from “descriptive functions” eased conversations around the purpose of these names and how we can best serve the user experience.

When names matter

When we add or change a name, we introduce a new concept for users to learn. The more concepts we introduce, the more confusing and time-consuming our user experience can become.

And yet, the instinct to name things comes so easy. Teams often assume a snazzy name will make a feature more desirable. For example, we tack on trendy terms that barely apply (I’m looking at you, “AI”). Or we rename existing features to make a simple update sound more substantive.

It’s important to learn when a name can really make a difference. At Electrolux, we mined keyword research and consumer studies to understand the influence of feature names on different phases of the consumer journey. We learned that despite investments in SEO and promotion, even our most well-known feature names made little difference for discovery and purchase decisions. And while feature names can make a difference for adoption and engagement, consumer studies revealed how convoluted and overabundant names are across our industry. These findings helped drive support for standardizing our naming processes and shifted our thinking about when and how to invest in naming.

With a better understanding of when names matter, we can also test smarter. For example, if we know product names do not heavily influence purchase decisions, then testing won’t teach us much about if a name works for sales. But we know customers need the product name when they contact customer support for help, so we might test the structure or pattern of our product names to ensure they’re easy to spell or use in conversation. User testing is a great way to learn if we’re getting it “right” with names, and we can plan tests better when we know what we’re trying to achieve with that name.

When to make exceptions

Exceptions to your naming standards will always pop up. Often these outliers stem from translation and localization needs; sometimes they arise from legacy brand decisions or strong-willed executives. But the more we deviate from naming standards, the less effective they become. Make sure that dealing with exceptions is a part of your governance model so decisions don’t repeatedly come down to individual opinion.

In our Electrolux naming criteria, we expect all names to prioritize usability, accessibility, and localization. This is easier said than done with hundreds of different products in 120 markets spanning 45+ languages. Names get showcased in retail stores and tradeshows, printed on appliances and in user manuals, and featured in all manner of digital content. Needless to say, managing exceptions can come at a high cost.

All our names go through a sensitivity check to ensure they’re in the best interest of our customers. This involves local market representatives to check for any inappropriate and offensive translations, as well as aligning suggested names with local customs. For example, the oven function known as “Broil” in the US is most commonly called “Grill” elsewhere, so we change that function name depending on the market.

We aim to test our English names in languages with longer text expansion (such as German and Finnish) and different characters (such as Arabic and Hebrew). By doing this early on, we can gauge if a name really does serve customers in all markets and all languages, or if we will need to invest in a well-reasoned exception.

Contrast this approach with Ikea, a brand that resists translating product names at all. Their naming patterns borrow from different Scandinavian languages, so it’s not uncommon for names to be unintelligible (or hilarious) in other markets. For example, in Swedish, fartfull means “speedy” (Figure 2).

Who’s responsible?

As with all content design guidelines, naming standards are only as good as they are used. It takes time to ingrain new standards in an organization—especially if there is a history of bad habits. 

When rolling out naming standards, it’s essential to introduce them to everyone. It doesn’t matter if these teams are a part of the formal naming process or not. Naming can be hard to control: A feature starts off with an abstract project name that lingers. Or engineering teams refer to it by a technical moniker that ends up in prototypes. It takes buy-in from everyone for standards to stick. 

As I said at the start, naming is in our nature. So when it’s time to roadshow naming guidelines, it’s an easy and fun topic to make interactive. Here’s a workshop template (Figure 3) I’ve used for onboarding teams to naming standards—feel free to make a copy and adapt it to your org. If you’re running a workshop with more than 10 people, I’d recommend switching the format to a tool like Mentimeter to collect more answers with ease.

Over the years, I’ve landed in my fair share of back and forths about who “owns” naming in an organization. Rarely does it make sense for this process to live with one team or one decision-maker. In the best cases, I’ve been a part of cross-functional committees that meet regularly to review needs or recommendations from relevant teams. In this governance model, we distinguished stakeholders based on how impacted they are by the outcome—“responsible” or “interested.” 

All in all, naming is a truly collaborative endeavor. The more ways we find to work across teams, the more consistent we can be with quality outcomes.

What’s in a name?

Naming isn’t easy. Even with the most descriptive names, the process often involves a few stakeholder squabbles or translation hiccups or user test surprises. We can clarify name types and know when they matter, and we can consider exceptions and create clear standards. 

But it’s important to remember that names are not magic. If a product or feature depends on a name to make sense, then it’s worth revisiting the feature itself. Are we building the right thing? Have technical limitations or time constraints changed it too much? Naming attracts attention because it’s something we all like to have an opinion about. But at the end of the day, a name is only as good as the product it represents.