Design tokens ease building products by improving the communication around design. They help scale your product by separating design decisions from specific platforms & technologies.
They improve communication with build-in documentation & promoting design decisions out of design files.
What are design tokens
Design tokens are a very “hot” topic at the moment. You may think it’s only a fancy name for a design related variable. While you may find them as variables in your files, this is only part of the truth. Let’s have a look at some common definitions to make sense of this confusion.
Descriptions of design tokens in the field
According to the w3c working group in design tokens, design tokens are:
Design tokens are indivisible pieces of a design system such as colors, spacing, typography scale.
Mozilla defines design tokens like this:
A design token is an abstraction of a visual property such as color, font, width, animation, etc. These raw values are language application agnostic and once transformed and formatted can be used on any platform.
The “inventors” of the design token idea, Salesforce, define them as:
Design tokens are the visual design atoms of the design system — specifically, they are named entities that store visual design attributes. We use them in place of hard-coded values (such as hex values for color or pixel values for spacing) in order to maintain a scalable and consistent visual system for UI development.
Design tokens — a definition
Pulling from the descriptions above, this is my definition of design tokens:
Design tokens are named entities that store raw, indivisible design values like colors or sizes. They are the core pieces of a design system. Stored in a technology agnostic format they can be transformed for use on any platform, replacing hard-coded values.
Choices & decisions
Design tokens come in two varieties,
decisions. The difference is rather conceptual than technical. The idea is that there is a finite amount of defined
choices e.g. all available colors in your design system. With those
choices you can make
decisions, e.g. which color to use for your primary button.
choice is a core design token. It represents a value and is not related to a specific use case. This can be a color, font size or any other primitive.
Some examples are:
decision is a
choice applied to a use case. It references a
choice and its name represents a use case / a
decision, but not the value.
You can change the value (referenced
choice) without renaming the token. By reading the token name and referenced value you understand the
decision that has been made.
Some examples are:
button-background-primary: color-blue-digital(This token represents the decision of “what color to use for primary buttons”. )
Design tokens are a methodology
Design Tokens are a methodology. IMHO, saying “design tokens are just variables” is like saying “responsive design is just media queries”. It’s a technology-agnostic architecture and process for scaling design across multiple platforms and devices, including native, and more.
Variables are just part of that story.
~ Jina @jina Nov 14, 2018
Why is the distinction important?
If we elevate design tokens to a methodology they can change the whole industry. A methodology is an approach to how we do something and not just a new tool. If we change how we build software this can have interesting ripple effects.
We will look at 3 of the more interesting side effects:
- software integration
- development tooling
A methodology may create enough attention to bring open standards. Actually there is already a w3c community group working on one.
A standard may seem boring at first, but look at what it did for markdown:
Hundreds of tools support it, thousands of packages exist to work the format. All this is only possible because of the open markdown standard.
A design token standard can do the same for us:
- interoperability between projects
- integration into software
- more interest, resources & development of the methodology itself
02 Software integration
An established methodology used throughout the industry will become interesting for software manufacturers. The people building Sketch, Figma, Framer and XD will think twice before ignoring it. Especially if standardised, native support in design tools will be a question of when, not if. When one tool implements it, others will soon follow.
Official integration into our design tools will in turn further promote the methodology.
03 Development tooling
Design tools are only the beginning of the product building process. For design tokens to reach their full potential they need to be integrated into the development pipeline.
Developer tooling for design tokens already starts to become easily available. Tools like Amazon Style Dictionary, Theo or Diez make a first attempt at bridging the gap.
Over time tooling will evolve so that developing with design tokens will be easier than without. For developers, design tokens will be a requirement to consider a new job. Just like agile is today.
Fitting design tokens into your existing style guide / design system
Starting with the core
If you work with a style guide or design system you may already be using design tokens. Your “core styles” (colors, sizes, type scale, etc.) are design tokens.
To go all the way there are three more steps:
- Give every style a good name following a logical naming convention
- Store them in a technology agnostic file (e.g. json).
- Make sure everyone in your org can access them (like a dedicated github repo).
Extracting design tokens from your products
To get the most of design tokens you should probably do a design token audit. This means looking at your components and creating design tokens for all values. This can mean one of two things:
- Creating new named references to existing tokens e.g.
- Adding new tokens for unaccounted values (or replacing them with existing ones)
The added side-effect is that you make your product more consistent.
As inspiration you can find a list of common categories for design tokens below. While not exhaustive it should provide a very solid starting point.
- Element / Foreground-colors
Image tints / etc.
- Font families
- Type scale
- Font styles & letter case
- Line height
- Padding / Inset
- Common Sizes for icons, etc.
Elevation / shadow
- Timing / Duration / delay
Benefits of using design tokens
Design tokens benefit the entire organisation:
- They enable products to scale by decoupling design decisions from platforms & languages.
- By centralising design decisions in one place they make products more consistent & maintainable.
- And as named entities they form a self-documenting system.
A main idea of design tokens is moving design decisions to a technology agnostic space. For example a
design-tokens git repository. The tokens are stored in a format like json that can be transformed for any language or platform.
Moving design decisions out of the
xml and into one place has a huge advantage. If you change the file, all platforms can regularly pull it in and get the updated values.
Once you start working with centralised design tokens, creating “one-offs” feels wrong. It nudges you towards sticking with the established design system, ensuring consistent products.
Maintainability in this context refers to two things. Assuring correct implementation and ease of changing.
Assuring correct implementation
By using design tokens we remove two common steps that can lead to mistakes. The use of direct values e.g. copying a hex value from Figma to css. And the use of hand-coded variables e.g. copying a hex value from Figma to a sass variable.
This leaves only one possibility for mistakes: using a wrong variable. Luckily the risk of this is low.
- Mistyping a variable name will be noticed much earlier. Misspelling a design token name gives you an error during compilation.
- Using a wrong variable can be avoided through good naming. When using
color-background-lightfor text, a developer will notice the issue.
Ease of changing
Centralised design tokens make visual updates to your products happen nearly automatically.
The new, simplified update process is:
- Update to the central design token repository
- Product teams pull in the changes
- Recompile and release
You can rest assured that no screen was left with outdated styles. Without manual change no new bugs can be introduced. This also saved time and money that was previously spent changing styles.
When it comes to theming, or more likely, implementing dark mode, design tokens help even more. Since everything is dynamic, all you need to do is load a different set of design tokens.
With your design decisions extracted from a specific code base, scaling becomes easier. Think of it like a micro service. Similar to extracting business logic.
The less you have to rebuild when scaling to new platforms the better. You will have less errors, less work and an easier time doing QA.
Without design tokens designers use values, 5px for the radius, blue for the button. But when following the design token methodology, every value has to be a named entity. This forces designers to think more about components and systems.
Maybe the button color is now
button-color-primary. This helps other people understand what decisions were made.
- This button is a primary button.
- This button is an important element on the screen.
- This blue is the primary blue.
All this information can be derived from reading the name of the design token.
Some tooling around design tokens encourages this even more, by allowing for descriptions. This could be a use case for a token or additional information.
- Design tokens are a methodology to extract design decisions into a separate space. They are stored technology agnostic to be used on any platform.
- The two types of design tokens are choices & decisions.
- Choices are the available primitives like brand colors
- Decisions are choices applied to a context, e.g. what color is used for a primary button
- Continued interest in design tokens will bring better design software integrations and improved development tooling.
- Design tokens help have 4 main benefits
- Design consistency across products
- Improved maintainability
- Help scale products to other platforms
- Improve documentation of design decisions