What Are Design Tokens?

The design system revolution of the last decade has brought with it all sorts of tools and strategies to enhance product development workflows.

Design tokens are one of those tools many design systems, including Google’s Material Design 3 and MUI, have adopted to make UI elements easier to implement, manage, and update.

Import your design system’s components or an open-source component library with UXPin Merge to create a single source of truth across your organization. Learn more about Merge and how to request access to this revolutionary design technology.

Reach a new level of prototyping

Design with interactive components coming from your team’s design system.

Discover UXPin Merge

What is a Design Token?

Design tokens contain UI data, like colors, fonts, spacing, animations, assets, etc., for styling and building cross-platform user interfaces. Instead of hard-coding static values for every operating system, a design token contains multiple formats, allowing front-end developers to use the same variable, whether they’re building an iOS or Android, and even web application.

One of the challenges with cross-platform product development is that operating systems use different style properties and formats. For example, UXPin’s website uses yellow for CTAs. The hex code for this yellow is #FCC821, which you can represent in several ways:

• RGB (CSS): rgb(252, 200, 33)
• RGBA: rgba(252, 200, 33, 1)
• Octal (Android/Flutter): 77144041

Instead of using these static properties, designers and engineers reference a token like “uxpin.cta.primary,” representing all four color codes. The color will always be the same regardless of the platform or programming language.

Organizations use these design tokens for many style properties, including color palette, size, spacing, assets, and drop shadows, to name a few.

Where did Design Tokens Come From?

It is said that design tokens were pioneered by Salesforce. In a 2014 article published in Salesforce Designer, Salesforce UX VP Sönke Rohde described how the company uses design tokens to apply the same design principles across multiple platforms and software.

“At Salesforce, we face this very challenge, and we came up with an agnostic solution: we define our design in a single location and use a system to cascade it down to all platforms. We call it our Single Source of Truth. It’s basically a set of JSON files which contain name-value pairs describing our design tokens.” excerpt from Living Design System by Sönke Rohde.

Instead of using static style properties, engineers reference the design token, which pulls the correct value, depending on the platform, from a JSON file. To automate this process, Salesforce developed Theo–“an abstraction for transforming and formatting design tokens.”

Are Design Tokens Right for You?

Google’s Material Design 3 documentation offers a list of scenarios where design tokens are most helpful:

• You use a design system for more than one platform or product
• You want an easy way to maintain and update your product’s styles
• You plan to update your product design or build new products and features

Material Design also lists two instances where design tokens might be “less helpful:”

• You don’t plan to change your product in the next few years
• Your product does not have a design system

Benefits of Using Design Tokens

We’ve identified three key benefits to using design tokens.

1. Having a Single Source of Truth

Design tokens are most beneficial for creating a single source of truth–which is what drove Salesforce to start using them. Everyone must speak the same design language when multiple product teams, engineers, and UX designers work on the same product.

Design tokens allow teams to speak the same language, no matter their role, platform, programming language, or responsibilities.

2. Maintaining UI Consistency

UI consistency is a significant challenge when designing at scale. It’s not uncommon for designers to accidentally use slightly different sizing, brand colors, and spacing for a single product! These inconsistencies cause usability issues, increasing engineering and UX debt with every release.

Design tokens eliminate these inconsistencies so that every designer uses the same styles and properties–another single source of truth benefit!

3. Getting Flexibility to Scale

Design tokens give products and design systems flexibility to make changes and scale. If teams need to add platform-specific properties, they simply update the design token.

For example, Android uses octal color codes instead of HEX or RGB. To adapt a design system to accommodate Android, the DS team can add octal codes to each design token to maintain a single source of truth.

These tokens allow engineers to deliver new projects significantly faster with fewer errors or inconsistencies.

This flexibility is also helpful when making changes. For example, if a product changes its typeface from Montserrat to Roboto, the team only has to update the typography token to implement a product-wide change.

How to Define a Design Token Structure

While there are no rules for defining your design token structure, this example from Amazon’s Style Dictionary makes the most sense. Many organizations use a similar format for their design tokens.

Amazon’s Style Dictionary uses a hierarchical design token structure:

1. Category (color, time, line-height, size, asset, content, etc.)
2. Type
3. Item
4. Sub-Item
5. State

If we wanted to create a design token for a primary active button using this structure, it might look like color_background_button_primary_active or perhaps shortened color-bg-btn-primary-active. This token will contain every type of color code necessary for cross-platform implementation.

The key to a design token structure is consistency. It must use a predictable naming convention so users can easily find tokens and scale the system.

Architecting Tokens with Options and Decisions

UX expert and founder of eightshapes, Nathan Curtis, wrote an excellent article on architecting tokens. Nathan says the first step is to segment your design tokens into Options (or choices) and Decisions.

• Options: Creates the base token values. Tokens define what Style Dictionary describes above as categories–color, time, asset, content, etc.

• Decisions: Decisions use your Options to create properties for components. For example, interactive color, background color, text color, etc.

The benefit of this system is that if you want to change your white to a different shade, replacing the HEX code under the color Option will automatically sync to every design token and associated UI element. 

Nathan’s methodology also makes it easy to scale because you simply use your Options to create more Decisions. You can read Nathan’s full article for detailed instructions on architecting tokens.

How Design Tokens Work in Practice

In an informative article, Design Tokens for Dummies, Louis Chenais outlines a typical design change workflow with vs. without design tokens.

The Traditional Workflow–Without Design Tokens

1. Designer updates a style in a design tool
2. Designer documents the changes for the design handoff
3. Engineer updates the component’s properties (CSS, LESS, SASS, etc.)
4. The design team confirms the changes during quality assurance (QA)

There are several problems with this workflow:

• It creates more work and attention to detail during the design handoff.
• It’s prone to errors and miscommunication.
• Creates more tickets, thus increasing technical debt.
• It costs unnecessary time and money making the changes and fixing any corresponding errors.

The Design Token Way

1. Designer updates a syle in a design tool.
2. A design tokens generator updates a centralized repository creating platform-specific files (JSON/YAML).
3. Engineers pull the new repo, add any new tokens, and automatically update the project’s styles.

Using design tokens reduces documentation for design handoffs and saves programming time for engineers. This automated system significantly reduces human error, streamlining the development and QA process.

A Single Source of Truth With UXPin Merge

As digital products get more complex, designers and engineers must find solutions to integrate workflows–a problem UXPin has solved with our revolutionary Merge technology.

Merge allows you to import a component library from a repository to UXPin’s design editor so designers can use the same UI elements engineers use to develop the final product.

Merge components have the same fidelity and functionality as those in the repository. The design system team can use React props (or Args for our Storybook integration) to restrict changes or provide designers with the flexibility to make design decisions.

Whenever engineers make changes to the repository, they automatically sync to UXPin, notifying designers of the update. Merge comes with version control, allowing designers to switch to an earlier version–helpful for updating older projects.

Merge is available in three options:

• Git Integration: Direct integration for React component libraries
• Storybook Integration: Connect popular front-end frameworks like Angular, Vue, Ember, HTML, Web Components, and more
• NPM Integration: Sync open-source component libraries through an intuitive dashboard

Take your product development to new heights and create a single source of truth with UXPin Merge. Visit our Merge page for more information and details to request access.