About Design token in Design system
Talking about Design systems, there is not much to discuss the hottest topic today with anyone working on digital products. When embarking on building a Design system, with many efforts to separate and clear each part of it, we always face problems ranging from abstract to concrete. For example, how to distinguish Pattern library, Style guides and Design system, Pattern Libraries Aren’t and Just The Front End. And the first step that is also 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, of course. 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 to be simple but not easy to change and “maintain,” especially the changes that are not found — 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:
- Designer changes colors in design tools (Sketch, Figma).
- Designer update and share with Developer.
- Developer updates the value in the source code files.
- 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 that 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. And Design Tokens is 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 display 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:
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, Iconography. Examples,
Carbon Design System (IBM)
Lightning Design System (Salesforce)
Ant Design
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, the scope of use (the basis for scale-up design).
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. A method I find quite interesting is called “One Big Thing” aka “1–3–5” by Ryan Neufeld to help 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 part, and global tokens will be the rest.
This method, I find it possible to combine with the BEM — Block Element Modifier method when solving naming for components (one of the very “headache” problems for designers).
More from Style Dictionary
Organize & Manage
The design system is built to serve and respond to many different platforms and client devices. Also, It will be used for many projects. Each redesign environment requires different usage definitions for each component.
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 as it serves as a single source of truth instead of having several codebases with the same requirements and designed for a variety of purposes. You can take a closer look 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 that the Designer will configure, 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, layout of UI blocks containing content and themes and “no-code.”
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 UI and deploy the project again. Even when 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 the process to build 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 as well as testing products.
Appendix
- https://css-tricks.com/what-are-design-tokens/
- https://uxdesign.cc/design-tokens-for-dummies-8acebf010d71
- https://medium.com/eightshapes-llc/tokens-in-design-systems-25dd82d58421
- https://spectrum.adobe.com/page/design-tokens/
- https://amzn.github.io/
- https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_intro.htm
- https://blog.prototypr.io/design-tokens-with-figma-aef25c42430f
