The Practice: Semantic Colors for Designers

In this post, we’ll cover how the semantic color approach we described in the first post works for designers, in practice.

Setting colors up in the design system

Our team’s design tool of choice is Figma, but most of what we describe here could also be accomplished in Sketch (and perhaps other design tools).

Out of the box, Figma only supports one layer of abstraction for colors. You define a style, and that’s that. Here’s how we set things up to support our additional layer of abstraction:

First, we create a file in our Design System project called Colors.

On one page, we set up our base palette. These base palette colors constitute each and every color that can possibly appear in our apps. We make these colors private to the file by prepending a .to the style name. That way, the base palette colors won’t even appear when we publish the color file as a library.

On a new page, we define our semantic colors.

For each semantic color style, we define one light mode version and one dark mode version. In theory, we could define as many as we’d like (maybe we want a “super dark” mode, etc.)

We name these colors with the following convention:

Group Mode/Specific

Groups are things like “Label” “Background” “Header” etc. Mode corresponds to whether the given color is for light or dark mode. And Specific corresponds to the particular usage of the color within the group. This produces colors like:

• The semantic color for primary actions, Primary Action is defined with the styles Primary Light/Action and Primary Dark/Action
• The semantic color for accents within headers, Header Accent is defined with the styles Header Light/Accent and Header Dark/Accent
• The semantic color for our default labels, Label Default is defined as Label Light/Default and Label Dark/Default

As you can see, the light/dark style variants of each of our semantic colors is where we have to hack our way past Figma’s single-layer concept of color.

We further push Figma’s approach to color by denoting the base palette color that each semantic color references in the style’s description field. In the example below, you can see that Primary Action points to primary600 in light mode and primary500 in dark mode.

This description is what connects the semantic color to the base palette color, via a custom plugin that we wrote. Whenever we change our base palette colors, our plugin will automatically update the semantic colors for us, so that we never have to do anything manually.

This description also comes in handy later when we export these colors from Figma to usable code — more on how that works in part 3, where we discuss how this system works for developers.

Using the colors file as a library in other files

When we publish the color file, designers have access to all of the semantic colors.

Each and every color has a light mode and a dark mode variant that are in the same position and have the same name within the color inspector.

So to get a dark mode version of a screen, you can simply toggle each color to use the dark mode variant. This means we don’t have to maintain different components for different modes — everything happens at the level of individual colors.

To make this even easier for designers to use, we plan to build a plugin that automatically flips colors from light to dark (Brian Lovin at Github already built something that does exactly this, though it isn’t available for public use at this point).

We also plan to make a plugin (or use one that someone else has made!) that allows for type-ahead search to make color selection more ergonomic. But for now, we’ve organized semantic colors alphabetically so that designers can quickly find what they’re looking for.

A flexible and efficient system

That’s all there is to it — we build our semantic color file, include it in other files, and go forth and design!

Questions? Want to try out our plugins?

If you have questions about how to set this system up for designers, please feel free to ask! There’s nothing “secret” about this and we’d love for something here to be useful to other designers.

We plan to publish the “semantic color updater” plugin as well as the Figma integration that outputs code (more on that in the next section) — let us know if your team is interested in trying out early versions of either one of these.

The next post covers how this system works for developers — both in the code and in terms of collaboration with designers.