Design System

How to Accelerate your Design System and Collaboration with Design Tokens

We'll explore what design tokens are, why they can improve collaboration and why they're so valuable in creating cohesive and flexible design systems.

“Tokens store style values like colors and fonts so the same values can be used across designs, code, tools, and platforms.” - Material Design

In this article, we'll explore what design tokens are and why they're so valuable in creating cohesive and flexible design systems. We go in depth on what types of design tokens are there, and how we can name them effectively, in order to create a shared language within the creative team.

Detail: 'Abstract' CSS values are turned into easy to understand names.

What are design tokens?

You know when you're designing something and you have to make a bunch of design decisions about colors, fonts, and spacing? Those decisions can be captured in what we call design tokens.

Basically, instead of referring to HEX codes, values and other types of code to describe design elements, we give them easy-to-understand names. This way, anyone who looks at the design system can quickly figure out what's what by looking at the name of the token, without having to decipher a bunch of technical jargon and code.

While a design token maintains its name, the value or style associated with the token can be updated. Every element with that token assigned, gets the new value or style applied.

Design tokens are part of a design system in most cases. When you’d like to know more about design systems and how they contribute to businesses, I’d recommend you to read my Design Systems article.

So, are design tokens related to CSS variables?

Design tokens can be based on CSS variables, but they don't have to be. While CSS variables are a popular way to create design tokens, you could also use other approaches such as Sass variables or JavaScript objects. The important thing is to have a token system in place that fits the needs of your team and the related project. Which allows you to efficiently manage your design across your digital ecosystem.

Detail: Differet types of layers are defined to explain the purpose of the design token.

Different types and layers of design tokens

Design tokens can have different layers of depth. Adobe’s Spectrum describes this holistically. Common design tokens are as follows.

Global Tokens

These are the base tokens of a design system. They represent a value which can be globally applied. This is the first layer of specifying tokens. Ideally, global tokens should be used sparingly, as they are not associated with a specific context. When you encounter a use case where there are no alias or component tokens in place, use the global tokens.

Alias Tokens

Alias tokens relate to a specific context. Aliases assist in communicating the intentional purpose of a token. These are effective when a value with a single intent will appear multiple times across the ecosystem.

Since they include both the design decision, and the purpose of the token, this is your best pick. They provide context and are more specific than global tokens. And are less restrictive than component tokens. This minimizes future maintenance for the ecosystem and can evolve alongside the design system.

Component Tokens

Component tokens are an in-depth, detailed representation of every value associated with a component. They regularly derive from alias tokens. Although, they are named in a way that allows teams to be as specific as possible, in applying tokens in component development.

Be cautious about using component tokens interchangeably with other components. When a component is a derivative from the other components, it’s suitable to keep using the component token.

Detail: Design tokens applied to a dark mode button component.

How to Name Design Tokens

Ideally, the purpose needs to be captured in the token name. They need to be specific to the point where everyone on the team understands what the token is utilized for. Remember, create a token system which works for your team.

When we extend the alias token tier to a component token tier, we make it even more specific and restrict ourselves from using the token for use cases other than that component.

It’s natural that, when a design system grows, we tend to go towards the more restricted component token tier, in order for us to create shared understandable token names. Ideally, we want to divide the token name into layers. This adds context to the token.

Since components can be bound to a specific system, with a theme applied, states, variants, and so on, this adds lots of layers and complexity to the token’s name. The purpose of the token becomes crystal clear for everyone, compared to where the code behind it is solely understood by developers.

Layers of Design Token

Token layers can differ for each design system. Their context is dependent on the design system in use. As an example, we can divide the name of a token into the following layers.

  • System – This can be an abbreviation from the design system’s name.
  • Theme – When your system has a light and dark mode in place.
  • Group – Can refer to a section, like ‘header’, ‘footer’, ‘hero’. Or a component that groups multiple smaller components. As with ‘card’, ‘sheet’, or ‘dialog’.
  • Components – Components should already have a clear name. This name can be used as the component layer. For example a ‘button’, ‘text-field’ and ‘modal’.
  • Category – The visual style building blocks of the system. Like ‘color’, ‘typography’, and ‘size’. But also things for responsiveness, ‘media-query’. Or animation, ‘motion’.
  • Property – Basic properties like ‘background’, ‘border’, and ‘text’.
  • Variant – All the variants a component has. Such as ‘primary’, ‘success’, and ‘on-surface’.
  • State – All the states a component has. Common ones being ‘active’, ‘hover’, and ‘focus’.
  • Scale – The white space usage of the design language, ‘4p’, ‘3x-large’, ‘base’.

Nathan Curtis has an exhaustive article on how to name tokens effectively. I’d highly recommend you to read this in depth guide if you tend to start using design tokens.

Detail: Different naming layers of the design token's. In strict systems, they can become quite long...

How we Use Design Tokens in our Team and Projects

With the current project I’m working on with my team, we started introducing themes. These themes need to align with the needs and perception of the different customer segments the platform serves. 

  • One being a budget conscious segment. They love to plan trips and travel to our client’s hotels, for a promotional price. For this segment, we want to communicate a somewhat ‘retail’ look and feel.
  • The other being a customer segment who specifically searches for arrangements. A full package which includes stay, meals and activities. They want a seamless stay where they can enjoy their time with their travel companions. For this segment, a more chic appearance is utilized.
  • Finally, the base look and feel, our default theme. This one is for every other website included in the platform, not bound to a specific customer segment.

We found design tokens to be a valuable solution for the brand’s design language. We use CSS variables to wrap the somewhat abstract CSS value or style, in a more comprehensive name which communicates the purpose of a style. Like I’ve exemplified above.

We configure color, border-radius, borders, and box-shadows per theme. Although the name of the design token (a.k.a. CSS variables in our case) remain the same per theme, the color, border-radius, borders, and box-shadows have a different appearance per theme. Aligning with the expectations of every customer segment.

The Benefits of Utilizing Design Tokens

These are similar to the benefits of why we should use a design system in the first place. The benefits of using design tokens are focused on:

  • Consistency in creation and implementation – Design tokens ensure consistency across various platforms, devices, and products. By defining specific styles for design elements, which have a well named token representative, the entire system looks cohesive and well-designed.
  • Efficiency in cross-functional collaboration – With design tokens, designers and developers can work together more efficiently. Tokens provide a shared language between design and development that eases communication, reduces errors, and speeds up the development process.
  • Improved scalability – As a design system grows and evolves, design tokens make it easier to manage the system. Changes can be made quickly, ensuring that updates are consistent across the entire system. Instead of updating a HEX value 100+ times in the code manually.
Detail: Design tokens used for a card component in dark mode.

Conclusions & Key Takeaways

  • Design tokens are descriptive and self-explanatory bits of text that communicate the purpose of a style.
  • There are many approaches to create design tokens. Such as CSS variables, Sass variables or JavaScript objects.
  • Tokens create a shared language between designers and developers through this practice. They ‘rename’ code in a piece of text which everyone can understand.
  • We can use design tokens to increase the consistency, cross-functional collaboration, and scalability of digital product design.
  • There are multiple types of tokens tiers. The following being the most common ones:
  1. Global tokens – represent a value which can be globally applied.
  2. Alias tokens – are effective when a value with a single intent will appear multiple times across the digital product.
  3. Component tokens – are an in-depth, detailed representation of every value associated with a component
  • Tokens should be named according to their purpose and at what layers the token contains. Like the system where the token lives. Or on a component, property, state, and scale.

Research & Resources

Dive deep into other stories

Get in touch

Do you need a problem visualised?

Portfolio crafted with a lot of love by Liam / Copyright 2024 / All rights reserved.