The Ultimate Guide To Design Tokens

The sky is full of talk about design systems and design tokens. But the information presented here is based solely on your own experience.

The reason for writing such a guide was the practice and order of all this information in my head. When I started this path, there was a minimum of information and I had to collect general practices bit by bit.

Today I summarize this topic and summarize the knowledge gained by trying to make an ultimatum guide on the topic. At least for a general understanding of the process and guidance in which direction to dig for the same thirsty knowledge.

My name is Evgeny. I’m the Head of the UX direction at Usetech. I’m a designer myself, but it was important for me to understand what design tokens are, how they work, how they are compiled from JSON, and how they help in work.

Friends from frontend — I’m not a developer and I don’t pretend to be the only correct process. I’ll be very glad if you supplement my article with your comments.

I don’t encourage the use of tokens everywhere and in every project. It’s up to you to enter tokens or not.

Who is the article for?

For designers: who have heard about tokens, but don’t understand how they interact with the code, how they are arranged, and what can be done with them.

For developers: who understand the code, but who are pestered by designers to introduce tokens.

Looking ahead: there are many options and processes through which tokens can be compiled. This can be done not only at the front but also at the back. I will tell you only a few options.

As an example, we have:

• Two Figma plugins;
• SCSS Preprocessor (Sass);
• Zeroheight service;
• Amazon Style Dictionary library.

What are design tokens?

The concept of design tokens was presented by the guys from Salesforce: Gina Bolton and John Levin. They used them in their Lightning design system and talked about it at the presentation. In fact, they were used much earlier, it’s just that these guys were the first people to talk about them.

They talked about their approach to design, how tokens transfer design, and how to support cross-platform. We have even developed our own Theo product that compiles JSON/XML into the desired format.

The mission of token design is to reduce development time and help keep multiple applications in a single form, optimizing cost and time for edits. And they also help the designer and the developer to communicate in the same language.

If we are talking about large applications, their mass number and platforms, then surely these applications are on some kind of foundation. This foundation is a design system.

If you are engaged in landing pages or small websites, then you don’t need a design system, much less design tokens.

The design of the system is based on atomic design, from smaller to larger, the reuse of components and their nesting.

Atomic design

If we follow the concept of atomic design by Brad Frost, then the smallest particle is an atom: an icon, a button, etc., but these atoms also have properties: fill color, text color, font, size, etc.

All these style parameters can be specified in tokens and reused as many times as you want, and the versatility of the solution will allow you to make edits throughout the application with minimal pain. No, in all applications at once, if there are several of them.

Design tokens should become a data carrier with styles.

It turns out that the smallest particles in atomic design are design tokens.

Where to start?

Before you engage in tokenization, you need to take an inventory of the interface in Figma, otherwise, there is a great chance to make a mess.

An example is color styles.

In some projects, I see the name of styles by visual meaning. The designer came up with the idea that his application will be purple, which means it will be like the main color. Creates one primary style and sculpts it on all the elements that should be purple.

I also notice that some styles are named by their meaning. So, for example, the value of the green color in hex #44BE84 is equal to the name of the green style itself.

I see several problems here.

Problem 1. How to explain to the new designer who will take on this project what style and for what element should be used?

Problem 2. If there is no opportunity/time/resource to draw a layout, then the developer collects it from ready-made elements directly in the code — how can he understand which color to use where if a new, but possibly similar element suddenly appears?

Problem 3. Global styles. We use one primary style for everything: buttons, backgrounds, and icons. What if the icons need to be repainted?

And here there are several options: either repaint primary, which will immediately lead to the repainting of other elements, or link the style and come up with something new. And this applies not only to your layouts in Figma but also to the developer’s code — you will have to link variables there as well.

It is worse when styles are called not just primary, but the name of a specific color: green, orange, or red. And sometimes red-1, red-2, light-red. How to understand which style to use where?

Also, if the style needs to be repainted, it will cause even more confusion in understanding. For example, for the green style that is used in notifications, we will have to change the value from green to blue. Then the name of the green style will, to put it mildly, not correspond to the color value.

Since design tokens imply a semantic and understandable description of what they are used for, we need to name styles correctly.

The color can be divided into several groups. This solution is not 100% universal, start from your goals and objectives.

I’ll tell you in one of the examples how you can group colors.

Backgrounds. Here I specify the general background, the background for the substrates or islands, the background for the substrates of the islands (if required), borders (separators, tables, outlines of elements), accent background, background for modal windows with transparency.

Text. A separate style for the text is dark for white backgrounds, and light for bright backgrounds. If necessary, I add transparency styles for various signatures and a separate color for the link.

Icons. The icon color is for a normal background and inverted if the icons are used on bright backgrounds.

Buttons. I divide the buttons into subgroups and assign styles to different states. Sometimes I also sew the text color into the style and sign styles according to their purpose.

Statuses. If there shows statuses, I assign separate styles for them.

Don’t be afraid if your primary colors will be repeated several times from style to style. This will help you to manage various controls more flexibly and not get tied up in global variables.

Token Construction

This is a common construction that helps unify your variable tokens. This design easily fits into the styles in Figma.

[Category]-[Type]-[Item]-[SubItem]-[State]

Category — token category (color, font);

Type — token type (text, background, border);

Item — element (button, table, input);

SubItem — element type (primary, secondary);

State — the state of the element (default, hover, active).

This token design isn’t required, sometimes it may look shorter. Everything will depend on your conditions, fantasies, and how much you go to split variables.

Semantic name of tokens

The developer doesn’t need to remember what kind of shadow when hovering over the card. He just needs to enter the first lines of the variable and select the variable in the *-hover state.

In the future, when using the semantic description of a variable, it is easier for the developer to operate with them when assigning properties to elements. In addition, the developer can always directly tell the designer the name of the token, which will allow the parties to better understand each other.

Design token = variable

In the world of frontend development (and backend) tokens are also not a new phenomenon. Variables that contain a value and are reused in components are “thrown” to the elements in the code.

Taking the frontend experience as a basis, the design token is a variable in the code.

Color in the code:

.button {
background-color: #00BFFF;
}

Global color variable in the code:

$frost-sky: #00BFFF;
.button {
background-color: $frost-sky;
}

Design token with color as a variable:

$color-button-primary-default: #00BFFF;
.button {
background-color: $color-button-primary-default;
}

Thus, design tokens give more flexibility, which allows you to control the styles of individual components, rather than influence them globally.

This is useful not only from the point of view of code but also from the point of view of components in your Figma design library, where you flexibly use a palette for different elements, rather than assigning one global property to everything.

The variable is called not just at random but carries a semantic meaning, from which it is easy for both the designer and the developer to understand what this variable is about and what it defines.

JSON

JSON or JavaScript Object Notation is a text data exchange format based on JavaScript. But at the same time, it can be used in any programming language.

Design tokens are stored in a JSON file, in which there is nothing tricky: a plain text file with the extension *.json and special tree markup.

Such a file is generated using plugins in tools (Figma, Adobe XD, Sketch), any third-party services (zeroheigh, Specify), or simply written with pens.

The markup of the JSON file allows you to catalog meta-information into a tree structure, which will later be processed by the compiler. JSON becomes a single repository of all the design styles of your application.

If you are developing an application for the web, and it is one, then perhaps you should not get involved in tokens. It is quite possible to synchronize a designer and a couple of developers.

But what if you have a web app, an iOS app, and an android app? What if you have several applications that perform different functions, but come out under the same brand?

Here it turns out that the cost of even small edits can fly into a penny.

Even if you are making one application today — lay the straw, the market may change, and your company’s applications may become more.

JSON semantics

A JSON object is an unordered set of “key” pairs: the value of enclosed in curly brackets { } and the interaction with it goes like with a dictionary.

The key is the name of the parameter (property) that we pass to the server. It serves to make the server understand which parameter we are passing.

For example:

We pass the value “#ffffff” (white color) with the key “color” (color) and the value “16px” with the key “font-size” (font size):

{
“color”: “#ffffff”,
“font-size”: “16px”
}

The semantics of the design token is slightly complicated by nesting and the key is “value”.

{
“category”: {
“type”: {
“item”: {
“state”: {
“value”:
}
}
}
}
}

Example of a token with a button color in different states:

“buttons”: {
“primary”: {
“fill-border-default”: {
“value”: “rgb(87,89,206)”
},
“fill-border-hover”: {
“value”: “rgb(107,110,243)”
},
“fill-border-active”: {
“value”: “rgb(69,71,168)”
},
“fill-border-disabled”: {
“value”: “rgba(111,112,195,0.5)”
},
“text”: {
“value”: “rgb(255,255,255)”
}
}

After we compile this JSON for the web platform and CSS preprocessor, we will get the following variables:

$color-button-primary-fill-border-default: rgb(87,89,206);
$color-button-primary-fill-border-hover: rgb(107,110,243);
$color-button-primary-fill-border-active: rgb(69,71,168);
$color-button-primary-fill-border-disabled: rgba(111,112,195,0.5);
$color-button-primary-text: rgb(255,255,255);

And further, in the code, you can assign these variables to our elements and manage styles with one change.

It’s noteworthy that some changes can be made directly from design to production, bypassing the development stage.

If everything is set up correctly, then it will be enough for the designer to change the color of the style in Figma and click on the button that will send the JSON to the server. The project will be reassembled, and the changes will roll out without pain.

Components from variables

Variables themselves can exist and be assigned to any element of an HTML page. But I recommend wrapping some styles in so-called mixins (impurities).

Mixins allow you to create groups of CSS declarations that you will have to use several times on the site. You can even pass variables to mixins to make them more flexible.

For example, let’s take the text style of the title that we created in Figma. It contains:

• font family (font-family);
• font size (font-size);
• font thickness (font-weight);
• letter spacing (letter-spacing);
• the height of the line (line-height).

What it looks like in JSON:

{
“font”: {
“header1”: {
“fontFamily”: {
“value”: “Gilroy”,
},
“fontSize”: {
“value”: “48px”
},
“fontWeight”: {
“value”: 500
}
“letterSpacing”: {
“value”: “1%”
},
“lineHeight”: {
“value”: “72px”
}
}
}
}

How it looks in variables:

$font-header1-FontFamily: “Gilroy”;
$font-header1-fontSize: 48px;
$font-header1-fontWeight: 500;
$font-header1-letterSpacing: 1%;
$font-header1-lineHeight: 72px;

What it looks like in a mixin:

@mixin header-1 {
font-family: $font-header1-fontFamily;
font-size: $font-header1-fontSize;
font-weight: $font-header1-fontWeight;
letter-spacing: $font-header1-letterSpacing;
line-height: $font-header1-lineHeight;
}

Usage in SCSS:

h1 {
@include header-1();
}
.banner {
@include header-1();
}
.widget {
@include header-1();
}

What happens in the final CSS:

h1 {
font-family: “Gilroy”;
font-size: 48px;
font-weight: 500;
letter-spacing: 1%;
line-height: 72px;
}
.banner {
font-family: “Gilroy”;
font-size: 48px;
font-weight: 500;
letter-spacing: 1%;
line-height: 72px;
}
.widget {
font-family: “Gilroy”;
font-size: 48px;
font-weight: 500;
letter-spacing: 1%;
line-height: 72px;
}

We have created a design that we can reuse as many times as we need.

If we have applied this construction conditionally 200 times, then when changing the font size (or the entire text style) and a couple of clicks on unloading from Figma, we will painlessly replace all 200 styles.

But you can also use the @extend directive to inherit properties and not load the browser to read the same properties. But about that another time.

Tokens and Designer

Now let’s go back and see what the process of unloading tokens looks like from the designer’s side.

All that the designer sees in the tool (Figma, Sketch, Adobe XD) is a graphic component: squares and circles, color filling through a convenient UI, and customization of typography styles.

But if you dig deeper, then all this also consists of code. Under the hood, the same Figma has certain properties.

There are plugins that help pull all these properties into JSON tokens. They work on the same principle but differ in functionality.

As an example, today we will consider two of the most popular plugins:

• Design Tokens
• Figma Tokens

Design Tokens

The Design Tokens plugin allows you to upload:

• styles: color, text, shadows;
• physical values: dimensions, margins, grids, fillets.

When working with styles, everything is easier — the plugin takes values from the prepared document styles, but the physical values are dancing with tambourines. In short: you need to prepare frames with special names so that the plugin understands that this is a token.

Detailed information is available in the documentation for the plugin. The plugin also has settings.

File name

Here is the general name, as will be the output and the extension. I advise you to choose *.json

*.tokens.json

*.tokens

*.json

JSON format

Here you need to select the desired notation format (what is it?). Here you choose how it is more convenient for you to read the names:

kebab-case (my choice);

camelCase.

I advise you to choose the Original (deprecated) token format. The second W3C format is convenient for grouping properties, but it can become a problem when converting tokens into variables due to compiler settings.

Setting up prefixes

ignoring tokens starting with the characters #, ., @

identifying the name of tokens

I advise you not to touch this section and leave the fields that are filled in by default.

Prefixes for the token type

Type prefixes indicate how the plugin will look for matches by the name of your components/styles/frames.

If the frame is named as size/sizes, then it will automatically substitute the necessary numbers specified in the size of this element, and the token will start with size-*.

Working with Design Tokens plugin tokens. Examples

Now that all the settings are done, let’s move on to the token designation in Figma itself. With color and typography, as I said above, everything is simple. It is enough to create these styles and put the necessary checkboxes when exporting JSON.

And then, in order to unload the values of the sizes/rounding/breakpoints with a magical movement of the hands, we need to create a frame with the name “_token/***” and put in it what we want to get in the token. Below we will consider the example of sizes.

Sizes

To upload a dimensional grid to the token, we need to create a frame with the name “_token/sizes”, and put frames with all the necessary sizes inside. The frames themselves should be called “sizes/value”.

When the token is unloaded, it will receive the following name: [size-**], the value of which will be taken from the dimensional properties.

After unloading, we will get the following JSON code:

{
“size”: {
“80”: {
“value”: 80
},
“120”: {
“value”: 120
},
“160”: {
“value”: 160
}
}
}

The variables in SCSS will look like this:

$size-80: 80px;
$size-120: 120px;
$size-160: 160px;

You can see all the examples of uploading in the plugin documentation and in the Playground file.

Unloading tokens

Uploading a JSON file can occur in two ways:

• manual uploading to a computer;
• uploading to the Github repository.

In the case of Github, there are two ways to go:

• just upload the file and the responsible person will rebuild the project and send the changes to production;
• configure the automatic build of the project by changing the file with tokens.

Figma Tokens

The Figma Tokens plugin is good for everyone. It does not require additional settings, and design tokens can be both unloaded from it and loaded if you have changed something manually.

A big plus is the linking and documentation support. If something has changed in the token: the fill color, border, or description of this token, then it will automatically change the value in your Figma documentation.

Styles can be either imported from a Figma document or created directly in the plugin.

The plugin has two types of work with tokens: in the form of a UI interface and a marked-up JSON file. The values for the color can be in hex, rgb, hsl.

Title and links

The name of the token is separated by a dot and denotes nesting. So, for example, if we need to get the variable $color-button-primary-default, we need to write in the variable name: button.primary.default. The token category will be pulled up from the parent group when unloading.

We can pass not only a direct value to the token parameter but also refer to a previously created token. This is called an alias. You need to refer to the token via {alias}.

For example. We want to count the color through HSL, I only have the saturation and lightness parameters, and leave hue as a separate variable.

Create a token with the name button. base and assign the value 313. Just a number.

Next, we create the button. primary. default token and instead of the direct HSL value, we make it hybrid, refer to the base token, and twist saturation and lightness.

Alias in the plugin is written as {alias}, which means the entry for button.primary.default will look like:

hsl({button.base},71,55)

And after processing, like this:

hsl(313,71,55)

Creating the same tokens for hover, active. Just don’t forget to twist saturation and lightness.

In the example below, variables are made in this way. If we need to recolor the main color and its shades for different states, it will be enough for us to change the base number in button.base.

Updating documentation

The plugin allows you to link style parameters to Figma layers. For example, for a color, you can link the fill, borders, token name, token value, and its description.

It is enough to open the plugin, select the necessary frames and layers, and in the context menu of the token, select which type the layer is linked to.

Loading tokens

As mentioned above, JSON can not only be unloaded but also loaded. If for some reason the developer changed the values in the JSON file and changed several parameters, then it is enough to copy the contents of the entire JSON file and simply paste it into the plugin.

Discharge

The plugin has several ways to upload a JSON file, which are hidden on the Settings tab:

• local file;
• to the server by URL;
• in GitHub or GitLab

The plugin also has a more advanced paid version, which we will talk about another time.

Conversion from JSON

We figured out that design tokens are stored in JSON, and that they can either be unloaded through a plugin or written with pens, but how to get converted variables from JSON in an SCSS file?

There are several converters:

• zeroheight documentation service (color and text only);
• Specify a product, for storing project documentation and tokens;
• Theo library from Salesforce;
• library from npm “JSON to SCSS” (SCSS only);
• Amazon Style Dictionary library.

Today we will look at the service and the library.

Zeroheight

This service is very similar to the storybook, a popular software for code documentation among developers.

But zeroheight is more friendly towards the designer and has a nice bonus: all styles and components can be shipped directly from Figma in a couple of clicks.

Zeroheight supports design tokens, but in a limited form: only typography and color. No dancing with the code and installing additional libraries. If this is enough for you, then feel free to use it.

Where to start?

You need to register in the service, connect your Figma file and add styles to the page.

Uploading a design

Next, you need to select the desired page in the documentation and upload the necessary styles there. For example, color.

Design tokens

The service has formatting and insertion blocks. You can add text, elements from Figma, snippets, live code, tables, and design tokens. Token markup is divided into 2 versions.

The first version immediately collects the necessary formats:

• Sass
• CSS
• JSON
• iOS
• Android

You only need to add prefixes to the tokens if necessary. The file with the converted variables can either be downloaded or connected to your project at the address that zeroheight offers.

The second version gives the JSON file and offers to connect it to your project, where the compiler is the Amazon Style Dictionary library.

Thus, there is a process of changing styles for the application bypassing the developer. The designer changes something in Figma, loads a button to zero height and changes are applied to the project in real-time.

Be careful. This method of free tariffs does not imply any kind of change in history or versioning. If the designer changed something in the layout and updated it in the service, the changes will be applied in the project.

Amazon Style Dictionary

If you follow the path of unloading JSON, then just put it on the server, and you will not be happy. You need to install a special library that recognizes JSON and converts it to the desired format.

In 2017, the Amazon team introduced its own library that helps convert a JSON file into variables for web (CSS, SCSS, less), iOS, and Android formats.

The service has a “sandbox” in which you can play around and look at the changes in the demo card.

Now I will try to explain in simple words how to install and configure this compiler.

Installation.

Next, we will act in the CLI interface (command line interface), in other words from the command line.

For macOS it is a built-in Terminal application, for Windows, it is a Command Prompt (cmd). But it is also possible in any code editor that supports this interface.

Step 1. Installing the npm Software Platform

We need to install the global software platform npm (Node Package Manager) (what is it?) and node.js. This is a repository for various packages with applications. Speaking in the philistine language, there is a store where you can download the application.

Install node.js can be downloaded from the site by selecting the desired operating system.

To check if you have node installed.js and npm can use the following commands in the CLI:

node -v and npm -v.

When we are sure that the platform is installed, we proceed to install the Style Dictionary.

Step 2. Installing Style Dictionary

Type in the command line:

npm install -g style-dictionary

After that, wait for the installation to complete.

Step 3. Creating a project

We need to go to the right folder where you have the project and where the Style Dictionary will be additionally deployed.

cd path to the folder

Now we initiate the basic project, it will create all the necessary directories and files:

style-dictionary init basic

After this command, you should see this:

Copying starter files…
Source style dictionary starter files created!
Running `style-dictionary build` for the first time to generate build artifacts.
scss
✔︎ build/scss/_variables.scss
android
✔︎ build/android/font_dimens.xml
✔︎ build/android/colors.xml
compose
✔︎ build/compose/StyleDictionaryColor.kt
✔︎ build/compose/StyleDictionarySize.kt
ios
✔︎ build/ios/StyleDictionaryColor.h
✔︎ build/ios/StyleDictionaryColor.m
✔︎ build/ios/StyleDictionarySize.h
✔︎ build/ios/StyleDictionarySize.m
ios-swift
✔︎ build/ios-swift/StyleDictionary.swift
ios-swift-separate-enums
✔︎ build/ios-swift/StyleDictionaryColor.swift
✔︎ build/ios-swift/StyleDictionarySize.swift

This message says that files have been created for SCSS, Android, compose, iOS, and iOS-swift.

In the structure you will find folders and files:

• tokens — it contains JSON with demo tokens;
• build — all artifacts compiled from JSON
• config. a JSON file with the settings.

Step 4. Verification

You can run through the files and see how they are generated and whether they correspond to the data in JSON. I suggest that you go to the JSON file here and manually change several values.

After you change it, you need to rebuild the project with the command:

style-dictionary build

This is the main command that needs to be called after you make changes to the JSON.

Step 5. Setup

All the settings that are responsible for compiling your tokens are here.

• source — responsible for which folders and which files need to be converted;
• platforms — an array of settings responsible for the platform to which we compile;
• scss (ios, android, css) — the name of the platform and within it the local settings of this platform;
• transforms — additional settings for converting quantities and values;
• TransformGroup — what file format are we converting to;
• buildPath — the folder where converted files will be stored;
• destinations — file name;
• format — the format to which JSON will be converted.

const StyleDictionary = require(‘style-dictionary’).extend({
source: [‘tokens/**/*.json’],
platforms: {
scss: {
transforms: [“attribute/cti”, “name/cti/kebab”, “color/hex”, “size/rem”],
transformGroup: ‘scss’,
buildPath: ‘build/’,
files: [{
destination: ‘variables.scss’,
format: ‘scss/variables’
}]
}
// …
}
});
StyleDictionary.buildAllPlatforms();

In this file, the settings are combined by platform, and formats and paths are flexibly configured. There are also a number of additional settings.

Of the additional settings that you should pay attention to, these are transforms. In this line, you can set the conversion of values from px to sp/dp/pt/rem, from hex to rgb/hsl, and the formats of the variable names kebab-case and camelCase.

In fact, all the basic setup is done. We just have to put the JSON files in the right folder and assemble the project.

Tokens for components

Basically, tokens store basic styles, such as color, typography, shadows, and some values such as sizes and fillets.

But tokens have a flexible design, and they can be used in the description of specific components. A detailed story was told by Cristiano Rastelli, who made the Cosmos design system for Badoo.

With this approach, we can flexibly manage not only global styles but also specific components.

But remember that the more variables there are, the more difficult it is to maintain them. Be careful and reasonable.

If you have already done this or are going to — write to me, please share your experience.

A few tips

When unloading tokens, I always unload basic values and styles, I rarely use sizes, and indents in Figma itself, and I write JSON with my hands.

I share a few tips, I hope they will be valuable.

Sizes

I have seen several names on the dimensional grid: both in the gradation of hundredths of numbers, and in the so-called “T-shirts”.

$size-100: 4px;
$size-200: 8px;
…
$size-s: 4px;
$size-m: 8px;

But in my opinion, such naming is inconvenient from the point of view of logical understanding and communication. Imagine that the developer postponed the project for a week.

Returning to it, it is necessary to recall anew which variables are used in the dimensional grid and which values carry. Even worse, if a newcomer came to the project and memorizing all the variables is a bad story.

I propose to introduce a base value that will be multiplied by a certain number, and in naming, and indicate by which number we multiply.

$size-base: 4px;
$size-x1: $size-base;
$size-x2: $size-base*2;
…
$size-x10: $size-base*10;

Thus, team members do not have to keep the entire dimensional grid in mind, but only its basic value in 4px, and looking at the name of the variable, you can understand what value will be at the output. If we want to set the margins to 16px, then we need to use the variable $size-x4.

In addition, if you want to change the base step, say by 2px, then the size grid will be automatically recalculated.

Colour

The color can be read automatically by substituting the necessary variables and using color enhancers in SCSS.

The color can be read in HEX by hammering the base color into the variable, lighten (lighten), or darken (darken). As soon as the base color changes, the palette is automatically recalculated. The important thing is that the opacity remains 100%, and the color value itself changes.

$color-base: #ffcc00;
$color-base-primary: $color-base;
$color-base-hover: darken($color-base,10%);
$color-base-active: lighten($color-base,10%);

Or you can calculate in HSL, taking hue as a basis, changing only saturation and brightness:

$color-accent: 72;
$color-accent-default: hsla($color-accent, 100%, 36%, 1);
$color-accent-hover: hsla($color-accent, 100%, 29%, 1);
$color-accent-active: hsla($color-accent, 53%, 44%, 1);

“A” — in the hsla model, this is the alpha channel of opacity.

Results

As I said before if you make websites and landing pages, you don’t need design tokens.

But they are needed if:

• You are making several applications and services that should be consistent, and have a single look;
• If you are planning a theme, whether it is a light or dark theme of the same application;
• You are designing some kind of white label solution that is customized for each customer.
• Laying a straw for yourself will certainly not be superfluous.

The decision to use design tokens is not a panacea for problems, and I do not urge you to run and implement them right now, it is the same long and sometimes difficult path.

But if you understand that you need to do this, and it will definitely close your problems, then follow the simple rules:

• Enlist development support and find out how much they are willing to invest in it;
• Take inventory of current layouts in Figma;
• Decide on the categories that you will be tokenizing;
• Sort out the styles by semantic groups and put the semantic names in order. And here it is important to agree with the development on how it will be clearer to everyone;
• Choose the necessary tool — a simple zeroheight service or uploading via plugins;
• If through plugins, then decide which library will compile your files;
• Build the most transparent way with development so that you speak the same language;
• And the last, important point — enjoy!