Use Design Tokens to Connect Design System and Code Production
Though the Design-to-code tools are being used widely by devs, the current mainstream design delivery in internet companies still relies on different tech teams (iOS, Android, H5, etc.) to implement in their own coding framework. Within each design iteration, designers need to check the implementation result on each type of client end, and every update of the design component also needs to be updated to the related frontend framework (H5, Weex, Flutter, etc.) and the client (iOS, Android, Harmony OS, etc.)
Devs need to understand the design intention first to make code iteration. During this process, often the frontend developers can misunderstand the design guidelines, and cause communication hassel.
Design Token can solve the preceding problems, help the design delivery connecting with production seamlessly, and make the frontend coding work easier when writing UI.
What Is a Design Token?
Design Token is a design engineering system used to construct parameters with specific values from the design system with progressive namespaces. It stores all the parameterizable UI style values. The token system can help build a consistent and extensible product experience across different tech frameworks, app systems and pages.
A complete design system usually contains the following definitions:
- Color
- Typography
- Space (dimensions, padding, and margins)
- Shape
- Elevation
- Iconography and Illustrations
- Animation
- Sound
- Haptics
All types can be tokenized, including dynamic parameters, sounds, and even interactive interface parameters related to haptics systems. The design system is no longer documents full of descriptions of scenarios and rules. It is translated into keys and values that can be used in frontend projects.
A design guide normally contains sets of rules within generic scenarios that can be used by different business domains designers. It provides solutions to frequently encountered problems in the design work. The Design Token is an engineering method for design guidelines. Any style attribute used by a relatively high frequency can become a token.
It is like a set of coding standards and protocols formulated between designers and frontend developers. In the process of UI style implementation, it is necessary to use defined tokens as much as possible and avoid using non-standard style values. Therefore, it plays a big role in avoiding errors caused by inconsistent working languages between design and UI development, as well as implementation inconsistency between different systems, platforms, domains, and teams.
Why Should I Use a Design Token?
Design Token is a way to connect design system with UI engineering system seamlessly. Developing a complete token system has great help to feature/design iterations and app maintenance.
Scenario 1: As the maintainer of design system, Joe has defined the grid base is 4px. Finn is a newly-joined designer working on page A, who sets the card margin to 16px. Alex as page B designer, has set the card margin to 12px before. Due to the lack of such depth of details in the design system, it caused inconsistency of card design between two pages.
Scenario 2: Alex has received a product requirement to come up with a design version for elders, so he intends to change to larger fonts and larger spacings. So then the frontend dev needs to write new style snippets and Joe needs to update the design system according to this new scenario.
Scenario 3: Company takes branding renewation. The main brand color changes from orange to yellow. It will take a lot of time for each page to update their color usage, including H5, iOS, and Android. It would be nice if everything could be updated with one click.
The Design Token can solve all these problems:
- The semantic naming space naturally describes the usage scenarios, which makes the design decision-making processes simple. We don’t need to dive into those huge design guide documents being stored locally and difficult to keep up-to-date all the time.
- Design token system is built from abstract to concrete hierarchy. It ensures that the change of values at any level will not affect the stability of superiors or subordinates. For example, if the brand color changed to a new color code, all the referenced token will be updated automatically. And we can translate the token files into different style formats using tools like Style Dictionary, which can be used under many different frontend / native frameworks.
- The naming space of design token also ensures the consistency of the production process, as we can use ‘auto-hint’ in coding tools to clarify on the use scenarios, instead of using meaningless actual values.
How to Map and Associate Design Systems with Design Tokens
In my experience, the following token architecture can flexibly update values in different contexts and is easy to understand and use:
- Global token is used to manage the most basic style values without any semantics. For color category, it corresponds to HEX value, rgba, HSV, etc. For typography, it’s font-size values, font weight, etc. For spacing, it’s grid values and so on.
- Alias token contains somewhat abstract semantics, such as ‘color-background-primary’ describes that the color is used for the main background but does not specify which component being applied for.
- Component tokens are for specific components. For example, ‘button-color-background-primary-active’ describes its specific usage scenario.
Usually, we can use different files to store those token levels to well maintain our design system dynamically.
In addition, we can also create token bundles for frequently used combinations, such as background color and text color:
Token Naming Methods
We should spend the majority of time to well design the token naming hierarchy and rules when building a token system. Once the rule is set, all the style attributes in any scenario will be named in this way. In my project, a component token is named as below. It naturally describes the usage scenario. Other developers do not need to check documents to know that this is the background color of the primary button in active state. You can define the token naming levels that suits best for your own case.
Nathan Curtis proposed the naming levels by taxonomy:
- Base: the backbone part, including the category (color, font, spacing), design concept (feedback, action), and property (size, background).
- Modifier includes one or more variants (primary, success), state (hover, disabled), scale (100,200), and mode (dark, light).
- Objects include component (button, tab), element (left-icon and link), and component groups (forms, feeds)
- Namespace includes the system (app, PC), theme (sky-blue), and specific domain (buyer, seller)
No matter which levels are included in your project, it is better to design naming architecture from macro to micro, from relatively stable to easy to change, and from abstract to specific. After all, the main goal is to let other teammates understand immediately when reading it.
Note: Not all tokens need to be named with same levels. Only keep the necessary levels to avoid redundancy.
Design Tools and Tokens
Whether building the design system in Sketch or Figma or applying styles from a design system in design work, we can map tokens with style guide. A Sketch file is essentially a JSON file package that contains object data of all the design elements, so we can obtain style data from the source file.
In addition to style data, Sketch’s Symbol and Figma’s Components enable component-level tokens to be maintained.
Therefore, abstracting design tokens from Sketch/Figma can be automated based on a set of naming methods. In addition, regular review and maintenance of tokens can ensure more accurate and seamless implementation of design system.
Currently, we are still working on how to generate reasonable tokens with ease and apply to the dev and production process automatically and intelligently. We welcome more discussion on the mutual transformation between design and UI engineering.
