Implementing Design Tokens: Colors

A practical guide to implementing color tokens in sizable products

Slava Karablikov
7 min readAug 4, 2023

The concept of a Design System has been popular in the design community for almost a decade. It offers a range of benefits, including a library of well-tested elements based on high-level design principles. The system is even more effective when all participants in the product process, including top-level executives, understand its value, benefits, and limitations.

Unfortunately, this is not always the case in the real world. When a company enters a new market, it focuses on delivering value to users, testing product hypotheses, and monetizing. This is perfectly normal and necessary for future success. The design can be less than 100% polished at this stage, as time and resources are crucial. However, this approach could slow progress when the product has found its niche in the market.

Inconsistent elements and patterns may emerge, which is a fair price for rapid growth. This was the case with Captiv8, the #1 Influencer Marketing Platform for Enterprises, where I work as a Director of Product Design.

I won't tell about the detailed stages of implementing Design Systems in this article. Starting with Atomic Design by Brad Frost and presenting a design tokens concept by Jina Bolt and Jon Levine is essential for those new to these topics. Instead, I will concentrate on how to replace numerous colors with well-developed color design tokens.

Before we begin, it's essential to understand the concept of design tokens. In atomic design, the minor components of a Design System are known as atoms. These building blocks consist of buttons, inputs, links, and more. Atoms also have background color, stroke, font, and typeface properties.

The design tokens are these fundamental properties. They can be coded and reused inside the application or portfolio of applications as much as you want. They greatly simplify global design changes and foster effective communication between designers and developers since the team starts speaking in one language.

Recently, Figma updated its software with new features that allow for the creation of design tokens through variables in design projects. This presents a tremendous opportunity to implement this concept in your daily work. In the following paragraphs, I will share my team's experience integrating color design tokens into a web application.

About Preparation

It has happened — we have decided to implement a Design System. We had a clear strategy, including KPIs, and recognized the significant work involved and our resource limitations. Therefore, we opted not to build the system from scratch. Instead, we incorporated the design principles of Google Material Design and Shopify Polaris. We also decided to gradually update the system to avoid overwhelming users with too many changes and new patterns simultaneously.

To begin, we gathered a system inventory and established fundamental design elements like colors, shadows, and typography. This step is strictly required because without it is risky to make a bigger mess in your application.

These elements were then compiled into design tokens: color, typography, border, space, shadow, z-index, and layout.

You can find a detailed description of the tokens we developed in my case study on Dribbble.

Tables with tokens and styles

Once the task was completed, we opted to prioritize the implementation of the color token. At the stage of collecting system inventory, we identified this zone as the most problematic on the one hand and easy to fix on the other. Allow me to explain the process behind our color palette briefly. We utilized the CIELAB color model to ensure that our color schemes maintained consistent lightness and predictable contrast ratios across all levels. For those interested in learning more about CIELAB and related tools, we recommend checking out Eugene Fedorenko's informative article.

The primary color palette based on the CIELAB model

Once the primary color palette was established, we created the secondary (functional) level of color design tokens. These tokens are derived from the primary palette, and their meanings are linked to the color attributes of specific elements such as fields, buttons, and cards. Creating an alias for variables in Figma makes converting the basic palette to functional tokens easier.

Functional tokens are named in a way that reflects their intended purpose. However, the challenge lies in selecting appropriate names for these tokens.

We have decided to follow Polaris Design guidelines for naming our color tokens. As a result, our color tokens are constructed in this manner:

[Element] - [Role] - [Variant] - [State]

I will focus on the "Element" parameter because it explains the four main groups of tokens.

Here are the different color designations for various elements in the application:

  • bg: main background for elements such as cards, buttons, inputs, popovers, and modal windows
  • text: designated for light and dark backgrounds, as well as basic and subdued text, and links
  • icon: specific colors for icons on both default and colored backgrounds, as well as interactive icons
  • border: the input fields, secondary buttons, and divider lines in cards and tables need a specific color.
Functional color tokens

For our first stage of implementing color design tokens, we chose to use the primary palette as the design token instead of the second level. Strictly speaking, this may not be the best idea because changing the color of the primary buttons will also change the color of other elements that use the same color in the primary palette. However, we decided to start with this approach because it will allow us to address any severe color inconsistencies quickly. We plan to implement the second level and the specific elements in the future. You can refer to this guideline if you're curious about naming Polaris color tokens.

Implementation

We were fully prepared to begin, as all necessary arrangements had been made. As part of our preparation, we gathered a significant amount of colors that are utilized on our platform. We had a total of approximately 450 colors, which included HEX, RGB, and RGBa styles. In fact, that's why we opted for the primary palette during the initial integration phase. Otherwise, the procedure would be never-ending.

Our initial task was to assign each color a token from our primary palette. To simplify this process, we used a script to sort the colors by HUE and Lightness.

Screenshot of the sorted-out colors

Assigning a color to a specific color token was a straightforward process. We assigned colors to sub-groups of tokens based on their hue, such as gray or blue. The contrast ratio towards the white background was also considered when assigning a color to a specific token. To verify colors, we utilized the Contrast plugin in Figma.

The Contrast plugin in Figma

As a result, we gave front-end developers clear instructions on transitioning to the new color palette. I want to emphasize one aspect: we assigned a color token without knowing its corresponding Element. This was a deliberate decision made in favor of performance over precision.

Tables of converting Hex and RGBa colors to the primary palette

Sacrificing precision, we got some issues after implementation. Mainly issues were connected to decreasing contrasts with some elements. There were some problems related to the incorrect use of colors and the discovery of new color options, but they were only a minor part of the overall issues. The team reviewed over 150 screens, four user roles for the platform, and countless component and widget states to identify all the problems and create a comprehensive plan.

Simple tracker of issues in Google Sheets that we used

After several weeks of making improvements and adjustments, the job was completed successfully, and the team could transition to the new color palette.

Conclusion

Implementing a single color scheme has already yielded several benefits as part of the more considerable effort to establish a Design System. Firstly, we were able to address long-standing accessibility issues on the platform. Additionally, communication within cross-functional teams regarding color-related matters has become more streamlined. Lastly, the new color scheme has been gradually adopted for all members involved in the product process.

The process may differ depending on the company, product, and team. Compared to our situation, your case may be less severe, and you don't have to deal with nearly as many colors. However, you may face more significant challenges if your company has multiple products in its portfolio. I hope our team's experience can assist you in developing your strategy. Sticking to a plan only if it works for you is crucial. Instead, take bits from various models to create a plan that suits your needs best.

If you enjoyed reading my article, please consider giving it as many claps as possible. This will help me to promote my content and create more amazing articles in the future.

In the next chapter of the guide, you will learn how to implement typography tokens:

--

--

Slava Karablikov

I'm an enthusiastic product designer who specializes in the intersection of engineering, design, and business.