Tech challenges and solutions for scaling a design system I
How to scale your design system with Design Tokens
In a company like Raet, that has been around for over 50 years, a lot of things have changed, while others have stayed the same. This translates to a tech stack full of shiny modern technology, some tech that was shiny and modern a few years ago, and dinosaur technology that is not shiny or modern at all. As we make the transition to merge with another company (Visma), we’re confronted with a whole new set of modern and not-so-modern technologies.
Even if you are lucky enough in your day-to-day to work with modern front-end technologies, this does not mean that all of our products are or will be written using current technologies. We will always have legacy and no clear idea about what the tech future is going to look like. Also, as a large organization we build for multiple web and native platforms that need design consistency. This leads to a challenge: How do we make sure that our design system covers everything? Well, unfortunately, we can’t pick the convenient parts and ignore the rest. We have to embrace cross-platform and tech sharing.
Our current situation looks like this:
As a front-end engineer, I assume designers are responsible for taking design decisions and that updating hard-coded values in code is a complete waste of time and resources. Updating a color, font size or any “core style” and seeing the result in any platform should be effortless. Unfortunately, this is not currently the case.
Let’s say a color needs to be updated. The current workflow looks like this:
- The designer updates the color in the design tool.
- This design update is shared with the developer.
- The developer updates the value in the library of reusable components.
- The developer updates the library version to have this color change everywhere it is used.
- The developer uses the new color in the product-specific code.
- The designer can see the result in a development environment.
This workflow suffers from a lot of pitfalls and creates a huge delay in the products’ go-to-market. The people working on the design system suffer too.
So, how can we optimize this workflow?
Design Tokens
This concept was created by Salesforce and its name comes from Jina Anne.
Design tokens are the visual design atoms of the design system — specifically, they are named entities that store visual design attributes. We use them in place of hard-coded values (such as hex values for color or pixel values for spacing) in order to maintain a scalable and consistent visual system for UI development. ~ Salesforce, Design Tokens
Design systems always include this set of small, central pieces of UI information that become the basis of everything built. They are part of the “atom” level of a design system and include colors, fonts, spacing, icons, etc. They are at the very core of every part of the user interface in the design system.
All of these tiny pieces must be in a format that works as a single source of truth. In other words, instead of delivering these basic design pieces in a format that can only be used for a web application, for example, they should be in a format that meets the need of any platform — a data format that is language-independent: JSON or YAML. This can then be transformed and formatted to meet the needs of any platform (Android, iOS, Web, etc…) and allows product teams to better collaborate and ensure brand consistency across any platform.
This method means that decisions about colors, fonts and other core styles are made at an atom level of the design system. It guarantees that new technologies do not require anyone to rewrite the styles and eliminate the need for hard-coded values. Decide to change all of your rounded corners from a 3px to 5px border-radius? Change the value once in your tokens file, and it propagates to all of your apps automatically.
Design tokens transformed in a standalone SASS, CSS, typography and icons library
We currently have several web applications and foresee many more to come. The effort required to maintain consistent font sizes, colors, fonts, spacing and icons across all these different applications increases and things can get messy. By adopting centralized design tokens, these tokens can then be transformed into specific formats, creating shared Sass variables using NPM packages. This takes care of the most basic design configuration for the web and provides a layer that is compatible with modern front-end technologies, as well as the not-so-modern legacy we still use. By isolating these pieces (colors, icons, spacing, fonts) from UI components, the library becomes more open to different front-end frameworks, as it is not coupled with a specific framework such as React, Angular or VueJs.
If your goal is to build a design system that promotes productivity, re-usability and visual consistency across a portfolio of products, spending the time required to define this set of properties is time well spent.
To go one step further…
- Is really important to take in account that design tokens are not only colors or animations. They can be anything, from UI components to layouts. The idea behind the design tokens is that you have a single source to maintain and multiple outputs.
- The architecture and implementation of tokens is ever-present. A successful, enduring token architecture depends on straightforward grouping, ordering, classification and decision-making.
- Identify opportunities to extend the system into designer tools, especially design software.
- You can build multi-product themes from design tokens to achieve robust theming capabilities.
- Design tokens can be managed with tools such as Theo developed by the design system team at Salesforce or style-dictionary developed by Danny Banks at Amazon.
