Naming colors in design systems

How language brings logic to a subjective topic

Illustration by Aaron Denton

Spectrum is constantly thinking about words. Between the need to name things logically and strategically, to communicate abstract and complex concepts in straightforward and clear ways, and to create detailed documentation, language is at the heart of team conversations. We identify patterns in our system and create a strategy to communicate with it and about it in a readily understandable way.

I'm a content designer, a UX designer with a focus on language and writing. My expertise is design systems and as the lead content designer for Spectrum, I work on content for the design system (documentation, naming, and information architecture) and content in the design system (our in-product style guide, terminology database, and content standards). Because of my arts background, I'm comfortable thinking about things that are conceptual and ambiguous—the hallmarks of building a design system—and transforming abstract ideas into tangible ones.

It's a skillset that's a nice addition to a highly technical and systems-oriented team, because as anyone who works on a design system knows, it requires reconciling two systems: design and code. Each uses specific language, and unique logic and syntax, to make sense of abstract and complex concepts. Components, styles, and behaviors are thought of and communicated about differently, depending on who you ask.

Color naming is an excellent example of how applying a content design practice to a design system works and how language can bring logic to a subtle and often subjective topic.

Naming colors in a design system

Color is the underpinning of a design system. When you’re creating a color system, you’ll need names for all its different facets and uses.

Many design systems have UI color palettes, and additional color palettes for things like illustration and data visualization. UI color palettes generally have very common names, whereas the other palettes are more descriptive or use less common (but still recognizable) names for colors. For example, you could give UI or “core” colors the nomenclature of their color family, like red, blue, or purple, then assign a value on a contrast scale in an incremental state of 100 while names for additional color palettes—collections of colors with specific intentions or usage—could communicate usage with prefixes like vivid blue or subdued green.

The most successful color nomenclature sticks to common language. When names of colors are wacky, reference cultural trends, or are over-branded, it becomes difficult to understand how colors work together as a system. Some examples:

• If your company is named Awesome Company and you named one of your colors Awesome Company Purple, there would be a limited set of people who would readily understand what color purple that’s referring to.
• If you were to name a color Raichu Orange (referencing a specific Pokémon), it assumes your user knows the pop cultural reference. People shouldn’t have to search for the meaning behind a color name—that just adds cognitive load to a design system.
• If you were to name a color Scary Monster, that could provoke all kinds of images since everybody has their own idea of what constitutes a “scary monster.”
• Even colors named with an intention to communicate specificity by using multiple adjectives, like dark blueish green or teal blue, can be unclear. Is the color blue? Or green? Or teal?

How Spectrum names its colors

Spectrum’s colors are mapped to our design tokens, which are all the values needed to construct and maintain a design system—such as spacing, color, typography, object styles, and animation—represented as data. Our naming decisions for Spectrum leverage industry terminology and commonly known terms whenever possible, so we avoid choosing names for colors that wouldn’t be recognizable beyond the design and development community. We also avoid names that are trendy, subjective, or in languages other than U.S. English (Adobe’s source locale for in-product content).

With the needs of our broad and diverse user base in mind, our colors are named with very common words (blue, not oceanic) and paired with an incremental brightness value scale (50–900). For example, gray-50 is lighter than gray-100. This approach has helped us to make steady changes, without major impacts, as Spectrum has evolved over the years to meet the needs of Adobe’s many products.

This wasn’t something that we figured out right away. Like all things within a design system, color changes incrementally, so we’ve had to shift our direction occasionally. It’s also taken us a few iterations to refine our numeric system for colors, which directly affects how we think and talk about them, but we’ve learned that the numeric values assigned alongside the common language color names are equally important for communicating meaning.

Coming up with a color nomenclature system

Like the design of other complex systems, a color system requires logic, focus, and a good amount of taxonomy work.

Use special names sparingly. The biggest mistake I see people make is to name every single color with a one-off name that doesn’t fit with other colors. If every color in a color system is named something wildly unique, that adds up fast to big issues for comprehension and usability. Reserve special names for important brand assets or for color palettes with specific usage.

Know the places for descriptive naming. Colors that aren’t mapped to a specific design component, or that will be used with scales for different visual tones for creating a specific effect or emotional response (such as in-product illustration) could have more descriptive names beyond the standard ROYGBIV colors. This is often where a brand voice or brand principles can come into play. For example, if you were working on naming products for a cosmetic manufacturer, you could call a light-pink nail polish bubblegum to evoke one kind of mood and cherry blossom for another.

Work with combinations of words plus values. Try to keep a name + value pairing system in place (for example, gray-100). That way, if (more like when) you add more tones, there’s more room for them. There’s also an element of predictability for using a numbered scale. In Spectrum, for example, our system is relative to contrast, rather than brightness. Our light color theme is named in a way that someone could readily understand that blue-100 is lighter than blue-400. In our dark color theme, blue-100 is darker than blue-400. In all themes, blue-100 is lower contrast with the background than blue-400.

Get familiar with terminology. Just like each person perceives color differently, there are also differences in how the greater design and development communities communicate about color. Make sure your team is in alignment about what to call the different characteristics of color and clearly define how each word and concept are related. Even better, document them alongside your color charts or lists of design tokens. For example, you could decide to use the terms color family and color group to describe kinds of color classifications in your system. Their definitions could be:

• A color family classifies a color according to the principles of color theory and/or the greater product design industry. For example, cyan could be said to be within the blue color family. By extension, it would also refer to the set of colors that make up a value scale for a particular named color.
• A color group is a set of colors that a subjective entity is designating should be grouped together based on specific usage properties. For example, color groups could be named things like Brand Gray, Illustration, or Data Visualization.

Things to try when naming colors

Use a name + value pairing model as much as possible. It’s much more extensible and will allow for future changes with minimal disruption. A standard method is to use a combination of color family classifiers (like green or gray) paired with a brightness or contrast value scale (10 is lighter and 100 is darker).

Map multiple attributes to each color. If, for example, you use the name blue-10 for a lighter blue color, it signifies the color family (blue) and the value (10), so blue-10 is its UI color name. An alias for this UI color could be something like “primary call to action button,” to describe its usage or purpose. This creates a layer of metadata or color-related synonyms.

It’s important in documentation to communicate color codes alongside color names to help users understand the broader system, but don’t use the hex codes, or references to any other color code values like RGB or HSL in a color’s name. You’ll be changing saturation and other properties frequently, and since color codes change along with them, it would require a lot of renaming.

Strategic naming. Using descriptive—but not overly emotive or specific—naming for colors can be very effective, when used sparingly. For example, Mint (but not Wintry Green) or Coral (but not Tropical Vacation). It’s OK to use more descriptive naming for illustration and data visualization color groups because these colors aim to achieve different things in the UI. Like tone in written language, they’re often used for different approaches to visual tone.

Things to avoid when naming colors

One-off, abstract, or overly metaphorical names. For example, what would Odysseus Blue mean? Names like these are open to personal interpretation, creating opportunities for inconsistencies. Precision is hugely important for colors within a design system, for both the users of the system and the users of the UI, and especially when designing accessible interfaces.

Using project names or code names. Hypothetically, let’s say you’re working on a project with a code name of “Ice Cream,” so you decide to name an accent color Ice Cream in the hopes of making it a differentiator of other colors in your company’s brand palette. Code names are obscure for a reason, and they don’t have a place in a design system where you’re aiming for clarity and ease of comprehension. “Ice Cream” could potentially be any kind of color! And all code names have an eventual expiration date for their meaning, which means you’d have to change the name of this color sooner or later, anyway.

Timestamping or relative time. It’s often tempting to call an updated version of a color “New” and leave it at that. New Blue is only new for so long; what happens when there’s another, newer blue in a few years (or even months)? A name like Heritage Blue to mean “the deprecated version of a specific blue” can lead to the same issue. Naming things in this way sets you up for breaking changes and having to spend time rethinking the whole system again.

Naming along design language updates. Like naming things based on relative time. If you were to name a color Update 5 Blue it sounds like the version of a color, not a version of a design language.

Name colors in the same way you name other things in a design system

To summarize, the best practices for naming colors follow the same principles for naming anything within a design system:

Lean on existing paradigms. Look to established leaders for inspiration about naming and taxonomies. Pantone has led the way with its breadth of color choices and well-managed taxonomies. Operating-level design systems like Google’s Material Design and Apple’s Human Interface Guidelines are backed by intensive research and testing to support their decisions, including naming; and I’d be remiss if I didn’t mention Spectrum as a solid example.

Don’t be cute. A design system ultimately comes down to utility, and people are more likely to use it if it’s easy to understand. People encountering your colors for the first time, whether they’re new to your company or third-party users, aren’t going to be familiar with internal branding jargon or your team’s inside jokes. And many will not recognize names that rely on specific cultural references, or the subtexts with them.

Design strategically. If you make every name within a design system special or overly emotive, it will detract from important brand assets that need to be unique for business reasons.

Communicate meaning. Again, design systems are about utility and scalability. Using a method like a numeric scale to communicate meaning will give you a lot of flexibility as you grow and inevitably change your color system again and again.

Finally, remember that names can, and will, gradually change, just like language and every other part of a design system. So stick to the advice and “evolve complex systems incrementally.”

Special thanks to Nate Baldwin and Shawn Cheris for their collaboration on this post.