Introduction to Design Tokens
Episode 9, in which we discuss the basics of design tokens. Learn what they are and in what scenarios it's worth to implement them.
You probably heard the design tokens term popping up in various design-system-related conversations. In recent years, this has been a really hot topic. Tokens are used by the largest product companies, such as Google, IBM, Adobe, Salesforce, and Atlassian. However, they are rather a hard nut to crack. In this article, we will take a closer look at the topic of design tokens. You’ll get an introduction to their basics and learn when it’s worth using them and when not.
What are design tokens?
Design tokens can be described as design decisions about the visual attributes of a user interface. The goal of design tokens is to move away from using hard-coded values, such as pixels or hex values, in favor of storing them as objects with names that describe the use of the values assigned to them. They are the smallest and basic element of the design system.
What can be tokenized?
As I mentioned earlier, tokens store the visual attributes of our design. Here's a list of attributes that can be stored as tokens:
Spacing and sizing
Typography (font family, size, style, weight, etc.)
Border style
Colors and gradients (text, background, border, etc.)
Opacity
Radius
Animation time
Shadows
Why design tokens are important?
Design tokens are a game-changer for developing and maintaining complex design systems. They ensure consistency across designs, improve team communication, and are platform-agnostic, meaning they can be used regardless of the platform or technology.
By replacing hard-coded values with tokens that reference design decisions, we create a single source of truth that makes it easier to design, code, and build a shared language within the team.
To sum things up, we could list areas where design tokens are most valuable:
Scalability and efficiency
Consistency
Communication
Maintenance.
Scalability and efficiency
They facilitate the scalability and development of products.
They support the creation and maintenance of multi-brand design systems and themes such as light and dark modes.
They streamline the design process and minimize the number of design choices that need to be made.
Design tokens are platform-agnostic, which allows tokens created once to be re-used on various platforms.
Consistency
They allow you to maintain consistency across the entire interface and even across multiple products and platforms because all designers work with the same set of visual attributes.
Communication
They improve communication between teams by using the same language and collecting design decisions in a single source of truth available for designers and developers.
Maintenance
Design tokens allow you to easily manage visual attribute values., enabling them to be changed in one place without the need to change the values in multiple places.
Changes can be implemented directly by designers without involving development teams.
When values are updated, token names remain unchanged. We only edit the value associated with the token.
Are they always necessary?
Design tokens can be incredibly valuable, but they're not always the best choice. Here are some important flaws of design tokens that you should keep in mind any time you consider bringing tokens into your design system:
High implementation cost
Poorly designed tokens at the beginning can lead to costly updates later on.
A huge amount of work is required to think it through and find the right approach that would fit our needs.
Currently, design tokens are not standardized in any way, which may cause problems in understanding and building them.
So the answer is no. Tokens are not always the only suitable solution. As you can see in the cons list, it is quite a complicated and expensive solution at its beginning. Sometimes, it’s not worth considering to implement design tokens, especially in one of these scenarios:
The existing product does not have a design system, and there are no plans to implement it.
The existing product is at a high level of advancement and was not built with the idea of design tokens in mind, so implementing them may be very expensive.
The product is very simple feature-wise, such as a basic landing page, and does not need to be scaled or expanded in the future.
Designers working at Google have come to similar conclusions:
Tokens may be less helpful if:
Your existing app uses hard-coded values that will not change in the next 1-2 years
Your product does not have a design system
Types of design tokens
It is a common practice to build tokens using a three-level structure, with tokens split into the following types:
Global
Alias
Component
Global
Also called core tokens, referring to hard-coded values such as pixels or hex codes. The entire token structure is built on top of them, and they are the starting point for the next levels. Global tokens have no context of use and shouldn't be used on their own, but they can refer to other global tokens.
Alias
Also known as semantic tokens, they refer to global tokens instead of constant values and, unlike global tokens, have a usage context assigned to them.
Component
The third level of tokens contains attributes that define the appearance and functionality of a specific component. Component tokens are linked to semantic tokens.
How to name design tokens
Naming tokens correctly and creating the right structure is an incredibly difficult task, and it takes time to find the best solution that meets your needs. However, there are a few principles that can make this thing a little easier:
Names should be as simple as possible and easy to understand by all team members.
The naming convention should be consistent across the entire design token system.
Aim for short token names, but don't sacrifice clarity.
It's also helpful to explore established approaches to token naming and structure, such as those proposed by Adobe Spectrum or Amazon Style Dictionary. Valuable insights can also be found in Nathan Curtis’ articles.
It's important to remember that tokens are stored in a JSON format, so our token structure must follow this format.
W3C Design Tokens Standard
It's worth noting that W3C is currently working on a common standard for design tokens. More information can be found on the official Design Tokens Community Group.
Figma and Design Tokens
Tokens Studio is an essential tool for any designer working with design tokens. This Figma plugin lets you create, edit, and manage tokens and integrate them with code, for example, through GitLab.
In 2023, Figma introduced Variables, a native solution for handling design tokens that allows creating tokens from scratch or syncing with existing tokens via the Tokens Studio plugin. Variables are currently in beta and do not offer the full functionality yet, but they have already introduced extra possibilities and significantly streamlined the workflow, especially in prototyping. They give more options and speed up the work with tokens. For example, the process of changing the theme is much faster because variables can be connected with styles.
Currently, since Variables are in beta, they are quite limited; for example, typography is not yet supported, but it is worth familiarizing yourself with them already as they have huge potential for the future.
Good to know
Design tokens originated at Salesforce around 2014 during the development of their Lightning Design System. The first mention of the design tokens term can be found in the article Living Design System written by Sönke Rohde.
It is worth familiarizing yourself with the Style Dictionary tool, which is one of the most important tools in the area of design tokens. By default, tokens are stored in the JSON format and Style Dictionary is a translator that transforms data from the JSON format into a format appropriate for the selected platform, e.g. CSS for the web, XML for Android or the JSON version for iOS.
Share this article and help us grow
If you found this post useful or entertaining, consider sharing it with one of your design or product management pals!
Tool of the week
EightShapes Specs
EightShapes Specs is a plugin for Figma that makes it much easier to create documentation of selected components, instances, and frames by automating the creation of design specifications, including anatomy, properties, layout, and spacing. The paid version also supports variables and modes and works with Tokens Studio.
Made by @nathanacurtis of EightShapes LLC.