What are design tokens?

It was Jina’s work on this that enabled me to communicate to the team I was in at the time about how I wanted to work on our multi-platform system. I called it a “style guide” at the time—thanks to my background in more traditional print design—but Design System with Design Tokens made much more sense.

Design tokens, explained by me

Let’s say your company has a website, an iPhone app and several printed brochures of information. For everything brand-related you use a style guide—that’s pretty darn standard, but that style guide is often a PDF with loads of information that doesn’t mean much to a developer.

That style guide will contain information such as brand colours, typography and how to use the logo—to name just a few examples—but getting that information to technical people who are not well versed in reading style guides could be very risky.

This is where design tokens become really useful because in essence, they are centralised data—almost like a database of design values—that could be consumed by anything that understands a standard, like JSON.

Here, let me show you how design tokens can look when they are in a standard data format, JSON:

{
  "colors": {
    "dark": "#121111",
    "light": "#f8f8f8",
    "primary": "#fdd110",
    "secondary": "#ea1c5c",
    "secondary-shade": "#da0044",
    "tertiary": "#55dde0"
  },
  "fonts": {
    "base": "Helvetica Neue",
    "serif": "Georgia"
  },
  "sizes": {
    "300": 10,
    "400": 16,
    "500": 20,
    "600": 25,
    "700": 31,
    "800": 39,
    "900": 48
  }
}

Here, the design tokens reference colours, fonts and a size scale. The colours are hex values and the size scale refers to pixel values.

This data would need to be translated per platform. For example: for print, you might need to translate those pixels into points and the hex values to CMYK values. For web, you would probably want to change the pixels to responsive units, like rems or ems, but that’s cool because there’s plenty of tools to do those sorts of translations. The important thing is that we have a centralised structure of definitions that can be used, cross-platform.

Here’s an example of the output if that JSON is converted into Sass:

$colors: (
  'dark': #121111,
  'light': #f8f8f8,
  'primary': #fdd110,
  'secondary': #ea1c5c,
  'secondary-shade': #da0044,
  'tertiary': #55dde0
);

$fonts: (
  'base': '"Helvetica Neue"',
  'serif': 'Georgia'
);

$size-scale: (
  '300': 0.63rem,
  '400': 1rem,
  '500': 1.25rem,
  '600': 1.56rem,
  '700': 1.94rem,
  '800': 2.44rem,
  '900': 3rem
);

Maintaining tokens

We’ve had a look at what the output of design tokens can be, but how are they maintained? As with anything in design and tech: it depends.

Tools such as Figma and Sketch offer a few options when it comes to design tokens. With Figma, there’s plugins such as Figgo which help convert static design tokens into more useful data that developers can use.

With Sketch, you can use plugins such as the handily named, Design Tokens Plugin.

More technical tools include Theo, by the Salesforce team, which is a popular choice amongst large design systems. There’s also tools such as Style Dictionary, which again, suits larger systems. Heck, you can even maintain design tokens with a handy Google Sheet and Theo.

There’s promising looking tools such as Arcade by the fine folks (and design systems experts) at SuperFriendly, too.

It would also be daft of me to not feature my own tools, Gorko and Goron which turn design token data into CSS and/or SCSS.

Wrapping up

I hope this quick explainer of what design tokens are helps you to understand them more.

I’d also urge you to read this article on CSS-Tricks, look through this speaker deck by Stu Robson and finally, watch this video with the creator of design tokens themselves, Jina, and a colleague.

Until next time, Take it easy 👋