Imagine auditing your company’s website, Android app, and iOS app and learning that your “Read more” buttons use seven different shades of your brand’s primary color, varying widths, heights, and border radii across these platforms. These changes could take days or weeks to propagate as you sift through each application, find every variant of a single button, and have development correct each of them, one-by-one.
After a few episodes of “it took three weeks to implement a simple color change,” it’s likely you and your development team have accepted these inconsistencies as “good enough” since the time it would take to achieve consistency feels untenable. Well, we have good news: We don’t have to pretend that inconsistencies are just a fact of life anymore. Design tokens are here to bring you closer to perfection, allowing you to manage all of your common properties from a single source and then distribute them to all of your applications and designs.
But what are tokens, exactly? What do they mean for designers and developers? And, importantly, when and how do you use them?
Who invented design tokens?
Design tokens were created by the Salesforce design system team. They figured out that if you established a new data layer on top of your existing design elements (and implemented a new process with your product team) and managed them from a single place, you could use a system to consistently scale it to all platforms.
Design tokens: Your key to unlocking cross-platform collaboration
Join Ehud Halberstam, Senior Product Manager at InVision, for a fireside chat with Jina Anne, the concept-creator of design tokens, and Kaelig Deloumeau-Prigent, founder and co-chair of the Design Tokens W3C community group. They’ll demystify design tokens and give you real-world strategies to start building them into your design systems practice.
What is a design token?
Essentially, a design token is a design decision: a pairing of the same code and visual properties—design elements you use over and over again in your products—packaged in a format that’s deployable across all platforms.
You can create tokens to store visual properties such as color, spacing, line heights, elevation, animation time, etc. Each token will be given a name that corresponds to a certain design decision/option and the defined value. For example, let’s say your team decided your brand’s primary color is #276EE5. You could create a design token of the following: color.primary = #276EE5 (The token’s name is color.primary, and its value is #276EE5.)
Now, the difference between design tokens and any other design variable is that they are an abstraction layer that makes them platform-agnostic. The naming conventions in this layer creates a common language for design properties that can be deployed across all your platforms and implementation frameworks.
How do design tokens work?
Design tokens are housed in a Single Source of Truth (SSOT) like InVision DSM (which has a GUI to help you easily create and manage your centralized design token repository.) Once you are ready to deploy a change, you generate the platform-specific values for these tokens using a build engine like Amazon’s Style Dictionary or Salesforce’s Theo.
Design token practice
Now, before we dive deeper into design tokens it’s important to note that in order to have your tokens be usable, you have to have a design token practice that everyone involved buys in on—both design and developers. A successful design token practice is a story about creating a shared language and communicating cross-functionally. Before any coding is implemented in DSM or your SSoT, designers and developers must agree on:
- What should be a token
- How those tokens will be used
- How those tokens will be named
The best practice is to start simple: first create tokens for the most common atomic and subatomic properties in your design system—such as colors, and text style properties.
Tip: Does your style guide currently consist of a full color palette, complete with five or more variations of each color? Do you use all of these colors? Probably not. Establishing a design token practice allows you to consolidate your brand properties. While it may look great to consider all colors and text styles for future use, designers and developers will find tokens useless if they can’t use them. And if designers use all variants, you may have inconsistencies across your brands and products.
Design token naming
A major component of a design tokens practice is the hierarchy or family tree of design decisions. For ease of use, it’s recommended to use Category/Type/Item (CTI) naming conventions to define tokens in a hierarchical tree structure of options and decisions. CTI does not limit the number of hierarchical levels, which allows for flexibility within your naming practice and allows you room to scale. Using this method, there are two types of design tokens: Global tokens, which control all instances of a particular design decision, and alias tokens, which control specific uses of tokens.
Our example from above color.primary = #276EE5 is a global token, meaning it controls all uses of the category and sub-item elements. So if you change the color to another value, say #D576FF , you could change all instances where that primary color appears—button, text heading, icons, etc—with a single deployment using your build engine.
But let’s say you want to implement a change but don’t want to affect certain elements, like text headings or icons. Here’s where alias tokens come in. Alias tokens create a hierarchy of options and decisions to control the scope, or intent, of changes. So let’s say you wanted to just change the background color on the buttons. You can create an alias token that reads as an inheritance from the global token as such:
Using the earlier alias example – color.background.button.primary – the ‘category’ would be ‘color’. Moving down the tree the ‘type’ would be ‘background,’ followed by ‘button’ as the ‘item.’
Additional resources
If you’re not yet tired of learning about tokens, here are some additional resources:
- Design tokens: Your single source of truth for scaling webinar with InVision
- Design tokens with DSM – InVision Learn course
- Tokens in Design Systems by Nathan Curtis
- Living Design System by Sönke Rohde
- Design Systems slack channel (visit #topic-design-tokens)
- Design Tokens W3C Community Group
Yana is a solutions consultant at InVision, focused on identifying opportunities within clients existing processes and tool stacks. Formerly a digital producer, she also holds experience working directly with design and development teams to deliver various digital products.
