Design System
Collaboration
How to Accelerate your Design System and Collaboration with Design Tokens
Liam Tanis
13 min.
May 3, 2023
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.
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.
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.
Design tokens can have different layers of depth. Adobe’s Spectrum describes this holistically. Common design tokens are as follows.
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 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 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.
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.
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.
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.
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.
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.
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:
I increase customer retention and loyalty — by visualising solutions. Therefore, I bring people, business and tech together through strategic design.
