Design tokens solve product problems, but they also create them. Here’s our experience at GR8 Tech: how we use tokens and why we created the Token Master plugin.
Design tokens store style values, such as colors and fonts, allowing style values to be applied consistently across designs, code, tools, and platforms.
A token is a piece of UI information. You set visual parameters for a specific interface element by naming a token. For example, you can create a token for the title: set the necessary style parameters, and all titles will look the same throughout the product.
Previously, designers named styles were according to the Material guide: Primary100. But such a name only tells us what kind of color it is and how dark it is. On the contrary, the naming of a design token considers the component or situation when you need to apply this color: control-button-regular.
You may ask: why bother with naming? The trouble emerges when you need to create a new color theme. For example, the GR8 Tech brand yellow works great in dark mode. But in the light mode, it needs to be replaced with a darker shade or even solid black. This is a long and inconvenient process without tokens, as all changes must be hardcoded.
We quickly realized that such a system could not be scaled and maintained. So we found a solution — design tokens.
Design tokens solve several problems at once:
- Support for as many color themes as you want
- Rapid design change
- Product consistency
Design tokens are the only convenient solution if your product supports light and dark modes. You create one design and get two results: the dark mode can be recolored to the light mode with one click. Design tokens also can be used to replace fonts globally on a product — mainly if you use different font pairs on iOS and Android.
Tokens help to change the style of a product quickly. For example, if you decide to use a different button shape or even recolor the entire product in new brand colors, with tokens, you can do it in a couple of clicks — and save time for designers and developers.
Tokens work like a ready-made library of solutions. Designers don’t need to think every time which shade of gray to use for regular text and which one for hints — tokens already have all the answers in their names. This automates the design process and prevents mistakes.
Another significant advantage of tokens is the consistency of design and code. How recoloring works for a designer is the same for a developer.
With all the pros, design tokens have their cons, too. At some point, we have had too many tokens. Such a large system is hard to work with and maintain. In addition, we are constantly improving them and creating new ones. How can the frontend understand which tokens have been updated?
The answer is automation. We use CI (Continuous Integration), a continuous release cycle. CI tool checks the styles in Figma and translates them to the code. So everything that the designer does with styles gets to the developer in real-time.
Without automatic delivery of tokens, there is no point in using them, so designers shouldn’t give up on this process. When creating a design system, the design must match what’s going on in the code. And it is the constant checking of tokens that synchronizes the design and the code.
There are various third-party solutions for design implementation. Our scheme is this:
- The developer provides a link to the Figma file for the script that runs on CI.
- This script downloads the file and extracts its contents (tokens and images).
- CI then builds several packages for both web & mobile platforms. Finally, these resources are uploaded to their respective repositories. At this stage, tokens are ready to use in the code.
We also have a channel in Slack: notifications are sent there if the tokens have changed.
Other schemes don’t work equally well for all three platforms. They require a massive add-on for Figma, which is hard to maintain. In addition, a plugin may crash — in this case, the product will crash, too. It would cost us dearly.
Therefore, we use native methods. We have all the styles in Figma. If any plugin crashes, nothing will fall apart — the system won’t be so convenient to use. And if Figma offers its native solution, we can quickly move to it.
In Modulor, GR8 Tech’s design system, token names consist of three levels, different in the hierarchy.
- Global color mode. Light mode, dark mode, or other color modes.
- Component group. At this level, we group the components. For example, a group of backgrounds includes all the backgrounds we use throughout the product. There are also groups with controls, text styles, icons, text fields, dividers, and dynamic colors (this group includes color blocks and content).
- State or unique style property (primary, hover, disable).
This structure makes it easy to navigate the design system and scale it. And for developers, the token’s name is an instruction for use: if they see that the color is called “Title,” it is immediately apparent that the heading should be this color.
Read the full article here