Design tokens are a foundational technology that supports the present and future. They are platform agnostic; regardless of what tools we use, they can be utilised. It’s a reusable baseline, enabling rapid, focused attention on UX design and development. Should a client’s brand change in future, design tokens facilitate these changes easily. This means a client sees sweeping cost savings, a good dollar-to-output ratio, and an investment for the future.

Why you should care about tokens

Venture studios like UntilNow, work across multiple clients and industries, each with different requirements and objectives. The one constant deliverable each client requires is a great user experience backed by a design system.

We know how important a design system is to bringing digital products to life. They form the building blocks of a scalable solution that supports the present and future.

What happens when you’re tasked with creating many design systems or have a design system that needs to be updated with new branding? Starting from scratch every time only gets you so far before you realise there needs to be a better way of doing things.

Tokens are a step for optimising your workflow when managing design systems that, if set up right, can save weeks of work. Take your components, like buttons, text fields, or menus. With tokens they become akin to runway models, changing their looks from client to client in a snap. Font stack needs adjusting? With tokens and the right setup, you can completely automate the process with a few control levers.

What are tokens?

Tokens are a platform-agnostic representation of a design decision. If you’re familiar with Atomic Design Methodology by Brad Frost, tokens follow a very similar idea. They are the building blocks to your atoms, molecules, and organisms. Tokens store raw values, such as colours, spacing, radius, typography, sizing, even motion. Apply tokens to the final component and each element has been assigned a value with a clear purpose.

Let’s go through an example of what I mean. You have a lovely shade of blue and call it out as ‘brand’. You take ‘brand’ and start applying it to various components such as buttons, checkboxes, and some headings. Things are looking pretty good so far right?

There is a common scenario where this colour won’t fit everything. Say the button in blue isn’t working out. You could create a new colour to separate this but unless its use case is clearly named, you lose definition of how the colour should be used.

So what if we clearly named them? We can duplicate ‘brand’, and name the duplicates appropriately like ‘Button/Background’, ‘Checkbox/Active’ or ‘Text/Primary’. However, there’s no source of truth. What happens when the original colour gets changed? Now you have to go through every colour based on the old value and manually update it. What a kick in the rear!

Tokens help as they allow you to define your base colours, and being able use them as a reference. So start with ‘brand’ as our base token, its value being the hex code of that lovely blue. Then create tokens for those duplicate colour styles i.e ‘Button/Background’, ‘Checkbox/Active’ and ‘Text/Primary’. Their value will reference the ‘brand’ token. The setup here is telling these tokens to inherent whatever value the ‘brand’ token holds. This achieves 3 things:

1. If ‘brand ’ ever changes, the 3 tokens referencing it will automatically update to the new colour.
2. We can point ‘Button/Background’ to reference another colour entirely if we want and it won’t affect the others.
3. We retain the benefit of naming the colour and token with a clear purpose.

Sound interesting? Let’s dive a little deeper.

How do tokens work?

Tokens work on 3 levels:

Foundations

This is where we create tokens for our base values. These tokens don’t have a defined role, but exist as options for the next level. This is similar to using Figma and creating the native styles for colour, elevation, and typography. The main difference is its expansive and granular; you can also define attributes like border radius, auto layout spacing, font size, line heights, letter spacing and more.

Semantic

We can start defining the roles of tokens set out in foundation. This is the bulk of your token structure. We start by creating groups of components and assigning them tokens. Here’s a few examples of groups we use:

• Buttons, button groups, text links fall under ‘Action’
• Text fields, menus, checkboxes fall under ‘Input’
• Avatars, pagination, tabs fall under ‘Navigation’

Each group has their own set of tokens for various attributes. Things like the colour of states, background, corner radius, or typeface for example. Everything here will reference something from the Foundation level. It means we can control what attributes are shared and not shared between components.

Component

The final frontier. This is where we create the output tokens to be applied to the components themselves. While their reference values may change, the name should rarely change. A component with all its tokens applied gives a final product with variable values making it a blank canvas. It gives your components that runway model status, making them swap looks client to client easily.

Benefits of using design tokens

Consistency

Tokens are platform-agnostic. While tokens are not native to Figma (yet), there is an awesome community plugin that assists with this. It’s called Tokens Studio for Figma by Jan Six, Esther Cheran and the team. The plugin lets you set up tokens in a visual way and communicates with Figma’s interface. The output is where tokens become elevated beyond design tools. We can store the tokens in a repository like GitHub as a JSON that can be transformed for any language or platform. This repository acts as the source of truth, meaning no matter where tokens get used, it will always be the correct.

Scalability and ease of change

With the token structures in place, being able to apply it to the design system is what makes it worth it to me. It’s a cathartic release applying a new theme for a client and seeing swathes of components ready to go.

When a client comes in a new theme is created to act as an override to the base token structures. Depending on client look and feel, you can make as little or as much overrides as needed. Once these have been created, it’s a simple case of hitting ‘Update’ in Tokens Studio and you have components unique to each client.

This ease of change extends to development. Once integrated in a codebase, changes made to themes can be pulled by the team and recompiled and everything will update the same. Developers who no longer have to do manual changes managing styles or design tweaks have less likelihood of introducing bugs. No bugs means time and money saved!

Inherent Documentation

Naming conventions are an inherent part of design tokens. Everything is explicitly named for their roles and references, it shows to other designers the decisions made.

Tokens Studio for Figma has a neat feature called the callout. It clearly labels what tokens have been applied to which layer in a component. It helps in communicating to designers and developers alike how to use and apply tokens.

Signing off

Tokens are an ever-growing piece of technology. Their application is complex, taking time and effort to apply alongside your design system. We at UntilNow, (and especially myself) believe that the effort involved in learning and applying this approach is greatly outweighed by the exponential benefits it yields.

‍