Keeping it consistent: Design Tokens

June 21, 2021

Bridging the Gap

An issue I often read about with design systems is the alignment between Design and Engineering. I’m sure someone could go on and on about where to point the fingers in this situation, but that won’t be me. What’s important is that we can bring these two sides together to create a managed system that provides value for both of their workflows.

One of the big players in helping these issues is the use of Design Tokens, or text files containing identifying information about a product’s styles. Colors, font styles, and more can be held in these tokens and provide help to front-end developers that are building out the product. These tokens can then be used across multiple platforms, making it easy to distribute them.

Written in JSON, Design Tokens declare style variables that can then be accessed by developers

The value here is that these tokens can be provided across multiple teams and contain the same values for anyone who accesses them. I think that this is pretty neat stuff and as someone who loves automating the mundane, I had to take a look.

Getting Started

I began by creating a basic color system in Figma. With simplicity in mind for the sake of my test, the system contained a base pallet of usable colors and a brand pallet containing colors nested from the base.

A basic color system consisting of Base and Brand colors.

We won’t just leave this system here for developers to come to look for, we want to put it somewhere more accessible.


Zeroheight is a web-based Design System Manager that I have found very easy to use. It also contains functionality for generating Design Tokens!

Zeroheight can generate design tokens for our colors, as shown on the left.

As you can see in the second image, Zeroheight generates a JSON file with data about our color system. Our “base” color system contains seven groups of colors or neutrals. We see that the “blue” group contains different variants of our default blue ranging from “lighter” to “darker”.

We can then create a second Token file that represents our Brand colors. You’ll notice, however, that our values for these colors will reference the base color pallet instead of the hex values of the colors themselves. These variables will be handled in the next step.

{} is a reference to the base pallet of colors for our product.

Style Dictionary

Style Dictionary is a system created by Amazon that allows you to define styles once to be consumed by all systems and platforms. This allows us to keep styles consistent and synchronized across teams that are using different platforms, languages, and more.

To test the system out, I set up a node server on AWS and installed Style Library. From there I imported the Design Tokens over to the server and tested away! It took me a few tries of messing with files and my config but it ended working nicely with my setup.

Style Dictionary successfully building the style dictionary for SCSS and Android.

I didn’t fully configure the system to send out the styles for iOS and Compose but it got the job done out of the box for SCSS and Android. If we take a look at the SCSS files, we’ll see that our colors from both the base and brand groups are present.

Color variables are set after building the style dictionary.

At the bottom, you can see how our Brand colors have been correctly assigned the values that they reference in the design token.

The Result

At the end of this project, I end up with a color system that is hosted and maintained on Zeroheight. The system then creates tokens for its styles to be sent to the webserver where they are then converted to the required platform. This will create a level of consistency and accessibility for styles between Design and Engineering that may have been more difficult to achieve previously.

Style Dictionary is rich with extra plugins and features that allow for customization of this system. I was easily able to set it up so that any changes to the design tokens would trigger the dictionary to rebuild itself. This system's functionality could help the workflow of organizations that have complicated design systems that may often change during development. I’d like to continue working on this in the future and plan to eventually create a full-size design system that utilizes these techniques.