Design tokens—the foundation of a scalable design system

Summary

Forte is a Web3 infrastructure company for game developers, using blockchain to enable new kinds of game economies. I joined the company through acquisition in 2022 as the first in-house product designer.

In true Web3 fashion, Forte is structured as a decentralized organization. This has some advantages, but can also result in too little communication between product teams. In our case, the user experience had become inconsistent and disjointed across their consumer-facing products.

As one of my first projects, I worked with a small team of design contractors and front-end engineers establish a design system and roll it out across products. This was an ideal scenario for design tokens.

What are design tokens?

I’ve been creating design systems for years. What was interesting about this system was the newer innovation of design tokens. What are design tokens?

  • Design values stored in a platform agnostic format.

  • Main types—color, typography, layout, styling

  • Token values are integrated into the front-end system.

  • Tokens values can be easily updated by designers, not developers.

  • This makes the system more scalable and less effort to maintain.

“Design Tokens are the visual atoms of the design system–specifically, they are named entities that store visual design attributes. We use them in place of hard-coded values in order to maintain a scalable and consistent visual system.” Jina

“Design Tokens are the visual atoms of the design system–specifically, they are named entities that store visual design attributes. We use them in place of hard-coded values in order to maintain a scalable and consistent visual system.”
Jina

Typography and color tokens are the heart of the system.

Where to start?

When I'm learning something new, I start prototyping right away. This yields specific, actionable questions that lead me toward useful tools and frameworks. While looking for answers, I kept coming across Jan Six and his Figma Tokens plugin. I installed the plugin, joined his Slack channel, and peppered Jan with lots of questions. The plugin also creates and updates Figma Styles beautifully.

Using the plugin, I quickly recreated systems from Adobe, Material Design, and Salesforce. This allowed me to "try them on for size" and see which felt most appropriate for our system.

Global tokens

When building a system, I'm a believer in starting with a small set of essentials and growing incrementally over time. Some future-proofing will ensure you don't paint yourself into a corner. In this case, global tokens (aka reference tokens) provided extensibility. These are our source tokens—the core values that all color and typography tokens reference.

We didn't need to align with brand colors because Forte was still defining their brand and our products would be white-labeled. For our foundational global colors, we chose the Radix Color System. I love this elegant, flexible system. We saved a ton of time by starting with these values, that were already accessible and consistent.

Global tokens contain the color value referenced by each subsequent token tier.

A couple of the Radix color scales.

A glimpse of the Radix color scales—the basis for our global color values.

A couple of the Radix color scales.

Naming conventions

From the reference systems I collected, Adobe and Material naming systems were extremely robust. But, they felt overly cumbersome and unintuitive for our team's needs. We found Asana's semantic naming system had the best balance of consistency and efficiency. The names are driven by these semantic values:

usage-sentiment-prominence-interaction.

This is a powerful, simple, and flexible framework for naming. The names are shortened by removing redundant default values.

And it results in named pairs, like text-default and icon-default. This removes ambiguity about which tokens to use when building components.

Simplified naming by removing redundant default values

Testing the naming convention in a Notion database.

Typography

Our approach to typography was similar. We started by defining a superset of global values. And then cherry-picked a smaller set of essentials to start with. We also simplified by choosing a single font family.

With typography, we had to solve for the different sizing scales based on breakpoint and/or device type. We started simply with two scales—desktop and mobile. We optimized for consistency by using identical values wherever possible to minimize outliers. For our needs, this was the right compromise.

Nerding out on typography scales. Comparing reference systems and my own go-to values.

Only the headline styles required separate values for desktop and mobile

Typography tokens are much more complex than color. Each typography token refers to a set of at least 9 other tokens.

With this typographic token reference system, we could instantly change the typeface across all styles by updating a single global font family token. This made it incredibly easy to test different typefaces and other typographic properties across our early prototypes.

Implementation

We have just begun to experiment with implementation, but we're already seeing positive outcomes in efficiency, consistency, and quality. Designated members of the design team are now empowered to publish token updates to GitHub via the Figma Tokens plugin. And we are using Storybook to document and test components that utilize design tokens.

We still have many mistakes ahead of us. But, I'm sold on the value of design tokens and am excited to continue to experiment and learn.