When you start to build your design system, you will probably run into the term design tokens a lot. If configured correctly, these tokens can affect your whole production from design straight to development without much friction with only a few atomic decisions. We will take a quick look at basic concepts in this post.

 

Honest mistakes

Does this sound familiar to you? You are trying to rebrand an app or website. You experiment with a few color HEX values, add elevation to surfaces with a code grabbed from another site you love – an honest mistake – and you piece everything together just to find out later on that the look and feel are different throughout the app. That’s how many people still build software to this day.

Luckily, some creatives who can also code came up with a better solution.

 

Enter design tokens

Design Tokens are the single source of truth for style decisions made across creative tools and coding languages. Almost anything can be a token. Colors, font, shadows, border radius, spacing, borders, animation, and icon sizing are just a few of the things you can do with them. After applying it to your code, it can update even multiple products at once by changing a few global values.

Much like coding an app, it gives semantic meaning to component styles at the early design stages, eliminating the chances of errors during production.

Lately, design tokens are a hot topic within the design community, which is trying to fill the gap between designers and developers by adopting a practice used by developers for a while. Why just now? Well, part because tools used by designers also needed to catch up with the hype.

It was realized that if developers can have access to tokens, designers should also start using them, and then hand them off to production. Or the other way around, grabbing from production and tokenizing components to maintain a nice level of consistency.

 

Example of design tokens

Global Tokens:

These tokens are your starting point, from which other aliases tokens will inherit their values.

 

 

Alias Tokens:

These tokens are a reference to global tokens. They create color variations, spacing calculations, border-radius multiplications – and so on – from just one source token. So, if you change the source, everything gets updated in one atomic decision. That can save an enormous amount of time if you decide to rebrand or build something from scratch using your current system.

 

 

Let’s say you want to create a button token. It would look something like this:

 

 

Those tokens will compose your CTA button’s color styles – there are others for border ratios, spacing, etc – with your brand’s primary color. You don’t even have to know the raw value to understand what’s it for. That’s the idea behind it.

By using the tokens throughout your HTML structure and Sass stylesheets, you can simply change raw values later by updating the styles guides, and you will update your software without much effort.

 

How design tokens are created

There are many ways to go about it. You can create a JSON file and import it into Figma and Sketch to create styles from that file and save it to your design system. You can also use plugins to manage tokens, like Figma Tokens, which will create them from existing styles and let you create new ones.

Another great benefit is that the plugins can sync to GitHub, which will run actions to translate it to styleguides. Later, you can use those styles on multiple platforms, making design tokens technology agnostic.

Some tools can do all the heavy lifting for you. After you apply all the tokens to your designs, they can be translated into styleguides and stylesheets with the correct token names. The one we use here at PHRUTOS that has the best outcome is Zeplin.

 

When should I use it?

Anytime you can! Firstly, though, let’s touch on a few examples of when not to use it.

There are some cases you don’t necessarily need to apply tokens to a project in its initial stage. A very simple example is when you design a webpage in WordPress or Webflow using a theme. Those platforms will come (sometimes) with their own set of tokens. Depending on their respective theme providers, it will be easier to edit the global settings and voilà, you got a few tokens working for you, already. But, that will be limited to what the template is providing.

On the other hand, if you manage multiple customer-facing digital products, and you’re CEO and VP of Marketing just laid down their plan to 3x growth this year, with plans to expand your storefront plus all your apps, I think it’s time to turn some heads to you by suggesting the adoption of a design system with tokens coded to fit your brand needs.

 

Time investment

You don’t have to create your tokens all at once. You can start with the basics, like colors, fonts, and spacing, and expand your token library gradually.

Projects that require a full digital transformation that will affect multiple products on multiple platforms will require more time, sometimes months of planning. That will vary depending on the type of technology you are developing. Once set, though, it will only require minimal maintenance to make a big impact on your front-end.

 

Conclusion

Design tokens can be a tedious task at first. Many times you need multiple teams talking back and forth to configure and educate developers for full adoption. But, it will save you so much time and money in the long run. You will find it silly that you didn’t think of this earlier.

If you need some help setting up a design system with design tokens, please get in touch. Have a blast designing your next product!