Design Token (noun): Design variables decisions applied to a specific context.
Overview
A design token consists of a label and value. They are used to consolidate repetitive values into a single source of truth. The value may be another design token itself. This is used to form token hierarchies. These tokens are applied to design element properties. When a design token is edited it will impact all design elements using the token.
Design to code
Design tokens make it easy to build, maintain and scale digital products. Aligning Product Design and Engineering teams’ design systems to the same token language is critical for healthy collaboration and output speeds. Workflows between Product Design and Engineering teams can leverage design software tools, like Figma, and their REST APIs that make publishing design token updates a breeze.
Design tokens operate independent of platform and tech-stack, but can be easily translated into a platform-specific language using tools like Style Dictionary, Theo, etc.
Token types
The design token architecture depends on the levels of abstraction needed for the product. This often is directly correlated to the scale of the product itself. I have found 4 layers of tokens to be the sweet spot.
Primitives (raw values)
These are the raw values in code such as color values (HEX, rgba), absolute and relative length units, percentages, numbers, etc. These tokens should not be assigned to design element properties. They are used as the value for Global design tokens.
Global (base)
Global tokens are the base values in a design language, represented by context-agnostic names. These can be directly used, and are inherited by all other token types. An example for a Global token name would be “green-500” and it’s value would come from a Primitive.
Common (Token)
Common tokens relate to a specific context or abstraction. Common tokens help communicate the intended purpose of a token and are effective when a value with a single intent will appear in multiple places. Their values are often Global tokens. An example of a Common token would be “color-action” and it’s value would be the Global token “green-500.”
Component (Token)
Component tokens relate to a specific component using them. Their scope only targets the component they belong to. Component tokens communicate not only the targeted properties but also their states.
Applying tokens
Below is an example of basic token application to design element properties.
Token name anatomy
Viewers should understand the purpose of the token immediately based on it’s name. Using a naming convention that semantically documents how it is used within the design system greatly simplifies token management.
The below example is a template I have found very effective in managing design tokens. The sections used in the token name will depend on it’s use within the design system. Not all name sections are needed for most tokens.
An example of a simplified name would be “color-action-primary” where I am not including the property, surface, or state sections in the token name. This is done strategically so that I can assign this token to all action elements and corresponding properties that need color values. Yes, this would give me less granular control over color styles for different action elements, but it also gives me the ability to manage them all from one design token. The design token name works hand-in-hand with the design token information architecture strategy.