From variables to tokens — a few tips to get you started
A common challenge when implementing a token-based design language is deciding what values need to be tokenised. Drawing the line between what goes into tokens and what is defined by the component’s own styles can be hard.
The challenge is not entirely new to developers. To solve it we can apply similar heuristics we use when setting traditional (S)CSS variables.
These recommendations are largely based on the insights shared by Zak Brown, a co-creator of Diez, on the Design Systems Slack.
Reusable values
Design tokens are shared between multiple platforms and languages, therefore, you could start with tokenising values that you expect to be reused across applications. Not every design system is created from scratch and starting from an existing implementation and hoisting values up into a shared layer is a common scenario for many teams.
Brand values
A common use case for design tokens is capturing the elements of a brand identity or design language. The use of brand colours and typography usually follows strict guidelines and building a repository of tokens to distribute and enforce these rules is a good starting point.
Of course, there are no hard-and-fast rules and most teams will find themselves using some combination of the above methods.
Leveraging modern design token tooling (Style Dictionary and Diez are both extremely powerful tools) offers a few more use cases.
Calculated values
Consider generating accessible contrast or complementary colours for a given background colour. This is often done as part of an implementation (using colour functions in SCSS, for example). Alternatively, you may choose to ship curated groups of colours that “work together” as part of your token library.
If we look beyond colour, typography, and spacing, we’ll find that images (both raster and vector — think logos, SVG icons, background patterns) can be optimised, converted, resized, and stored using the token infrastructure.
In these scenarios, we are not only abstracting values but also the corresponding processing logic. Moving it away from actual implementations could also make your component codebases leaner and more portable.
Theming values
Colour values could be composed in ways that enable themes, for example, “light” and “dark” modes. If your products require theming support, generating themed colour palettes is best done at the token level.
Design tokens are an emerging concept and best practices are still developing. It might be tempting to go all-in and start making corresponding tokens for each of the component’s properties. However, just like not every component belongs in the system, not every property will benefit from being translated into tokens. In fact, starting with only a sub-set of tokenised values and gradually evolving your library is a perfectly fine strategy. New use cases will always arise as design systems grow and scale.
