How to Make Design Tokens

Design tokens are one of the hottest topics in product design right now. As companies race to launch products on the web, mobile, desktop, and more, design tokens help them guarantee consistency and efficiency across all platforms. But what exactly are design tokens, and how do you make ones that actually work? This article will break down the key steps for creating an effective design token system.

As described by Salesforce UX designer Jina Anne, “Design tokens are the visual design atoms of the design system — specifically, they are named entities that store visual design attributes.” In other words, design tokens allow you to centralise commonly used values like colours, spacing, fonts etc. in a “source of truth”, and then reuse them anywhere design lives – whether code, Sketch files or Adobe XD. The end benefit is huge time savings from not having to manually update values everywhere, and perfect consistency across platforms.

In this article we’ll cover:

• Deciding what elements should become design tokens
• Auditing your current design system
• Structuring and naming your tokens
• Setting up a central source of truth
• Implementing a token build pipeline
• Governing the design token process

So let’s get started!

Determine What to Tokenize

When first implementing design tokens, the key is to start simple. Try not to tokenize everything at once, as this can become unmanageable. As Jina Anne advises, “Consider starting with just fonts, breakpoints or space tokens first before adding more properties.“

Focus first on your most atomic elements that are reused often across platforms. Common examples include:

• Colours
• Font families, sizes and weights
• Spacing values
• Border radius defaults
• Shadow defaults
• Animations and transitions

You can always add more token types later as your system matures. But nail down the basics first in order to demonstrate value and get team buy-in.

Audit Current Design System

Before deciding what specifically to tokenise, conduct an audit of your current design system. Document all the various text styles, colours spaces and other attributes currently used across your website, mobile and other platforms.

Then analyse:

• What are the most common attributes that appear on every platform?
• What values or styles vary the most across platforms?
• Which attributes require the most developer time to update everywhere when changed?

Assets with high duplication and frequent update needs should become priority tokens. This helps demonstrate the time savings and consistency benefits to both design and engineering teams.

Get Buy-In from Teams

For a design token approach to succeed, it’s crucial to get buy-in across disciplines. Workshops can align design and development on what specifically should become a token, naming structures, format of the tokens in code, and how they will be used by developers.

Open communication channels are key for a smooth rollout. Ensure both teams are bought into the value this approach will provide – more autonomy for designers to make changes, and less redundant work for developers from centralised data.

Organize Design Tokens

With the basics decided, it’s time to architect your tokens. A common standard is using a hierarchical naming structure like:

Category / Item / Attribute

For example:

color / primary / hex

This allows tokens to be grouped logically, making them easy to navigate as the system scales up.

You can choose to have global tokens that apply a change across all instances. For example, updating “color/primary/hex” would cascade to any element using that primary color value.

Or you may want alias tokens for more specificity:

This allows updating primary buttons separately from other elements using the color. Add aliases when needing to scope changes.

Set Up Source of Truth

Every design token system needs a Single Source of Truth (SSOT) – a central repository where all tokens live. This allows you to manage changes in one place, rather than updating multiple platform codebases individually.

Common SSOT tools include:

• Abstract
• InVision DSM
• Figma Tokens
• Zeroheight

Choose a platform that aligns with your tech stack for easy integrations. The SSOT should connect directly to your design files and codebase to sync changes automatically.

Implement Token Generator

Once the SSOT is capturing tokens, you need a pipeline to transform these into platform-specific code values. This is handled by token transformers like Style Dictionary (Salesforce) and Theo (Amazon).

They take platform-agnostic tokens from the SSOT, and output code variants like:

• CSS custom properties
• SCSS variables
• iOS colors
• Android strings

Set up a build script to run on each code update, pulling the latest tokens automatically. This completes the roundtrip letting design easily update code.

Governance Process

With the system functioning, formally document the governance process for how new tokens are added, modified or deprecated.

Outline each discipline’s role, and the review and approval steps required before token changes are pushed. Include:

• Request forms to submit token changes
• Communication plans on change impacts
• Scheduled reviews for proposed token changes

Conclusion

In summary, implementing a design token infrastructure requires strategic planning of:

• What elements to tokenize
• Sourcing and organizing tokens
• Integrations to sync tokens across platforms
• Governance policies for evolving tokens

The upfront effort pays off tenfold through consistent designs, automated development workflows, and enabling autonomous design decisions. Design tokens are the backbone of mature design systems!

FAQs