About Design token in Design system

Kim Dinh Son
8 min readJan 31, 2021

There is not much to discuss regarding design systems today, which is the hottest topic for anyone working on digital products. When embarking on building a Design system, with many efforts to separate and clear each part, we always face abstract and concrete problems. For example, how to distinguish Pattern library, Style guides and Design system, Pattern Libraries Aren’t and Just The Front End. The first step, the most critical step when building a Design System, is designing the product language (Design Language).

A common language of Designer 🧑‍🎨 and Developer 🧑‍💻

For the design to really “work,” the designer must communicate with the front-end developers. But, how to communicate and how effective it is, stories “know but not avoid.”

An eternal story,

Designers want to change and tweak small details to bring the best user experience, so they are always inclined to experiment and update. But with a Developer (front-end developer), it is necessary to be stable and consistent because small changes seem simple but not easy to change and “maintain,” especially the invisible changes— meaningful value for the whole system and organization like the minor tweaks above.

Design is not just what it looks like and feels like. Design is how it works.
Steve Jobs

A process for when the designer makes a small change is as simple as:

  1. Designer changes colors in design tools (Sketch, Figma).
  2. Designer updates and shares with Developer.
  3. Developer updates the value in the source code files.
  4. Designer can review the results in the development environment (test/ alpha versions or the sandbox).

The development team will take time to discuss and persuade small changes and have to wait to review the results. That is also one reason the Design System was born as salvation and a comprehensive solution for product system development.

The design system is a common language system for the team, where the designer can “look-and-feel,” and the developer can know “how it works.”

Once you’ve identified a common language team, now is the time to determine how to describe and convey it. Design tokens are the next step after design language.

Refer to the sequence when building the Design system: https://designsystemchecklist.com

Token definition

Design tokens are a platform that defines agnostic variables used to express the look-and-feel of a company’s brand and products. They form the building blocks of the Design system and are used to define color, typography, size, spacing, and other attributes. It provides the foundation for creating themes and automating the design process.
Example of a design token for color,

Let’s stop for a moment and discuss more tokens, as is well known, in programming languages, keywords, constants, identifiers, strings, numbers, operators, and punctuation marks, symbols are considered tokens.
For example, in C language, with the command to declare the variable below,

int value = 100;

contains the following tokens:

int (keyword), value (identifier), = (operator), 100 (constant) and ; (symbol).

The basic idea here is to use variables (keyword) declarations (to serve many purposes in programming) to assign a specific value (constant). If these constants have nothing to do with or affect logic, only to express external displays such as color, spacing, typography, or size (visual components), developers don’t need to worry about price at all. It’s a specific value but only interested in the variable’s function (agnostic variables — variables with unknown values). See the illustration below:

talking at cross purposes

Instead of arguing the value of that object, developers and designers need to name that object to communicate unanimously. For example, let’s say this is a primary-red-color instead of cherry red 🍒 or # 88011d.

Design Token in a Design System

The main groups of components are usually defined in any Design system, including Color, Layout, Typography, and Iconography. Examples,

Carbon Design System (IBM)

Design Token construction

Let’s go back to the first story above, when the designer decides to change the color of a button, assuming he wants to experiment with something. Developers will want to have a clear understanding of the purpose of this change decision so that they plan for the future in maintenance as well as scale-up, even if the change is small and of little value.

Decisions. Decisions. Decisions. Faced with nearly infinite options, as a designer, you make endless decisions through the design, development, and maintenance of every web site or application.

Source: Design Tokens: Scaling Design with a Single Source of Truth, Jina Anne

To work systematically and consistently, a simple workflow for token design looks like this:

Decision

The designer will define the class to use for the object with specific explanations of what it is (Component-specific), uniformly what the alias code is, and the scope of use (the basis for scale-up design).

Design token types (Spectrum, Adobe)

With the above division, a design token will include three components:

  • Global tokens: blue-40
  • Alias tokens: cta-background-color
  • Component-specific tokens: button-cta-background-color

The question is how to classify objects into groups and name them with the three above components to keep things consistent over time and the explosion of design volume when scaling up the design system. I found an interesting method, "One Big Thing,” aka “1–3–5” by Ryan Neufeld, that helps solve this problem.

We will split the decision frame into three parts, and the first part should contain the biggest and most important item to do or your “big thing.” The second section is divided into three boxes of your three midsize stuff. Finally, the last area is for your little things (usually five or more options).
Component-specific tokens will be the first part, Alias tokens will be the second, and global tokens will be the rest.
I find it possible to combine this method with the BEM — Block Element Modifier method when solving naming for components (one of the very “headache” problems for designers).

More from Style Dictionary

Distinguish property from token, value, and attribute

Organize & Manage

The design system is built to serve and respond to many different platforms and client devices. It will also be used for many projects. Each redesign environment requires different usage definitions for each component.

Manage & read Token Data via YAML

So, developers need to manage & read Token Data quickly and conveniently.

We can see the benefit of using the design token as it saves a lot of code duplication and confusion among multiple groups. It serves as a single source of truth instead of having several codebases with the same requirements designed for various purposes. You can look closer at the Style Dictionary’s architecture to learn how to start building tokens and how it works.

Use

In other words, this is the step in which the Designer will configure and check the results, and for the Developer, it is the step to release the product’s version. That reminds me of WordPress (or something like that), a mighty website-building and content-management platform. We can visually customize the style and layout of UI blocks containing content, themes, and “no-code.”

Customize a WordPress page

Some examples of theming in design systems.

Like the WYSIWYG tools, the benefit of customizing the interface directly on the sandbox helps designers and developers quickly detect visual irrationalities, so it doesn’t take much time to edit the UI and deploy the project again. Even the debate about aesthetics also becomes a lot easier when we already have visual proof.

Generate design token from Figma design tool

A new “level” of token design presented by Pavel Laptev, utilizing the power of the Figma API, allows the generation of design token files directly from the design token files, and the process is completely automated.

That means the JSON (token data) file is no longer the only way to specify the “truths” in the design system. It can be linked directly to the Designer design file 😻.

Summary

Although building a design token is not simple, the benefits of the token design are immense. It will pass through and endure while building and developing the design system. The superficial construction of the design token will result in a waste of time and money in the process of interacting with each other and testing products.

Appendix

--

--