The ultimate Design Token setup

Or how to manage design tokens across your company

Before we dive into this, let me tell you that there is no one right or perfect way to do design tokens. If what you are doing works for you — great. No need to change it. However, I do feel that one can learn from others and there are always things to improve.

Goal

Every action has a cost. So, we need to think about the goals for our design token system. Which aspects do we want to optimize for? And what is not so important for us.

Resilience

Design tokens are a core part of your design system and product building toolkit. Because of this a simple mistake can bring down your entire product suit or at least break the products. This is why it is so important to make your tokens as resilient as possible. This can be by using versioning or implementing rigorous testing.

Future proof

The tooling landscape changes constantly. A few years ago, most of us were still using Sketch. You cannot see into the future, but you can try to rely as little on specific tools as possible. This way, you will have a much easier time adjusting, if a tool in your tool chain gets replaced.

Flexibility

Companies grow and change and so do the requirements. Maybe you need to support iOS in the future or React gets replaced by Vue at your company. Design tokens must be set up in a technology agnostic manner. This allows you to adjust to those changes. Changes in output should never be a big change for your design tokens.

Ease of use

Consuming design tokens must be easy, otherwise people don’t do it. Like installing a simple package or enabling a Figma library. Nothing more should be needed to start using design tokens.

Maintainability

Design tokens rarely undergo large changes. But you need to be able to update individual tokens or add new ones with ease. Those changes, as well as keeping dependencies up to date must be simple and straight forward. Otherwise, you risk design tokens becoming a legacy project that nobody dares to touch.