The Name Game
Developing a framework for what we call things in our products
Think about a time you had to come up to speed quickly in a new environment, such as a new school or workplace. Learning the right words to use as you integrated yourself mattered a lot. By mimicking what others called things — nicknames for campus buildings, company acronyms, industry terms, regionally accepted names (soda, not pop!) — you could reach common understanding faster. Then, you could navigate this new world and start accomplishing your goals more quickly.
This scenario is just as relevant to software. For the businesspeople who use our tools, the names of components, areas, and tools signal where they should go and how they should interact to be successful. Business users should be able to intuit the meaning of a name because it fits with the language system already in place — by using similar terms or structure, for example — but still understand how it’s different from other things.
At Facebook, we heard feedback from our business customers that we weren’t always doing a good job of naming. Marketers were confused by language in our UI that was complicated, unfamiliar, and sometimes conflicting. What’s the difference between insights and analytics? Is a custom audience related to a custom conversion? What’s the difference between a slideshow and a carousel format in an ad?
The language we use can make an experience seamless, or it can trip people up, stop them in their tracks, and even drive them away. If how we name things confuses people about where to go next, what tool to use, or how to accomplish a task, we risk, at best, delaying the work they’re trying to do — and at worst, frustrating them so much they never want to come back.
Bringing order to product naming
To address this problem, we created a naming framework to help manage and scale our system of names. Following one of our core Facebook business design principles, we aimed to bring clarity to complexity by making our names easier for our business users to follow and understand.
Sometimes, the terms we use in our tools emerge organically — they may start, for example, as internal project names that make their way into our UI. Other times, we name things as part of a marketing plan, the way another company might name a cereal or a shampoo. We designed our naming framework to help us think more deliberately about each name and make the name work as part of a larger system.
We also hoped that a framework could help us become more efficient in how we work. In the past, we’d spent weeks or months naming products. Each name required multiple workshops and reviews as well as lengthy negotiation and research. With a framework, we could start the conversation from an agreed-upon point of view and narrow down options faster.
A name architecture to support our leading brands
Big companies with many brands often develop a “brand architecture” to organize their brand portfolios and determine how they name products. These are deliberate, strategic frameworks for deciding if a company wants to go to market like Procter & Gamble or Volkswagen, which manage distinct, unrelated brands, or like GE or Samsung, which manage products that lead with the master company brand.
We built our own name architecture based on this model. It let us formalize our decision to lead with our primary brand offerings, Facebook Ads, and Facebook Pages, rather than creating a portfolio of standalone “brands” that compete for the spotlight. Everything we name supports those leading brands.
The architecture guides us on how we name things in our product ecosystem and how those names fit together. When faced with naming something new, we can determine how that thing compares to other things in the architecture and name it accordingly.
Guiding principles for business naming
The Facebook business naming framework is built on five guiding principles, which help us consider tradeoffs and make decisions when we’re stuck.
1. Use the fewest names necessary.
We work to keep our language system clean, logical, and consistent. The more names we add, the more cognitive load we put onto users as they try to understand those names. The first decision to make in the naming process is whether to actually name the component. We may consider using plain language to describe a function or area, rather than assigning a new noun to it. For example, we “create an ad” instead of sending people to the “ad create flow” in Facebook Ads. We refer to “the older version of Power Editor” rather than branding it “Power Editor Classic.”
2. Name like things alike.
Things that are similar, or that sit alongside each other at the same level in our name architecture, get similar treatment. We also reference terms already in use for similar concepts. Our naming framework asks us to consider: is this thing like other things that already exist? If it is, we should follow that precedent. These questions inform our decisions about the style of the name: capitalized or lowercase, descriptive or suggestive, function- vs. benefit-focused.
3. Be simple, straightforward, and human.
We adhere to the characteristics of the Facebook brand voice. We avoid jargon and hyperbole and aim to be precise, specific, and clear. Internally, we sometimes use language that’s overly technical or doesn’t feel friendly or human. For example, we may talk in our product teams about Facebook pixel “fires” that send signals to our system or “targeting” as a way of reaching people with ads. Our brand voice reminds us to consider external names that are more human-sounding and plainspoken, so everyone can understand and relate to them.
4. Name for the long term.
Our products are always evolving, and our ecosystem is always growing more complex. We name for extensibility so our decisions will work as well a year from now as they do today. In one example, we released the new Canvas ad product with a branded name, because it represented a unique creative platform for Facebook ads. We already knew the product would eventually expand to include many different capabilities and use cases, and we were afraid that would lead to a cacophony of confusing and conflicting branded names. So we established a naming architecture for Canvas that used plain-language extensions to describe variations — Canvas with video, Canvas for travel — rather than trying to brand each product variation.
5. Think globally.
Facebook ads and business products are localized for dozens of different languages. We include our internationalization team early on to be sure the names we choose in English will translate well for all the locales we serve. Localization checks have helped us avoid widespread confusion and even some potential offensiveness. (One cringeworthy example: learning that the name “call-to-action button” might be inadvertently translated into “call the police button” and “call for some action button” in some Asian languages. We opted for simply “button.”)
Since launching the framework last year, our product teams have relied on it for naming initiatives of all sizes, from lightweight UI labels to complex product rebranding. It’s also helped to raise awareness among our teams about how carefully we need to consider the names we choose. Most importantly, it’s helping people use our tools to build stronger connections with people and businesses.
