The design tokens practice
As digital transformation accelerates, companies face the challenge of scaling design across an increasing number of screens, tech stacks, and product teams. As the product footprint grows, propagating even simple design decisions, such as a color change, can take weeks to accomplish.
To address this challenge, the design system team at Salesforce established a new data layer and a practice that helps scale design across multiple platforms and teams. They named it design tokens. By using design tokens, it can take minutes—instead of weeks—to implement design decisions across platforms.
With DSM, you can build documentation for your design tokens that lives alongside all the other elements of your design system.
Before we see how DSM design tokens work, let's look at the design tokens practice, which can be broken down into a few main steps.
Step 1: Centralize
Manage design tokens in a single place in a platform-agnostic format (e.g., JSON or YAML).
Step 2: Transform
Use a build engine that takes design tokens as input and transforms them into platform-specific or framework-specific style files (e.g., CSS, Sass, iOS, Android, etc.). You can develop your own engine, or you can use existing ones like Style Dictionary and Theo.
Step 3: Distribute
Add the generated platform-specific style files to the code base of your applications. How you do it in practice depends on the platform and your existing process for managing dependencies. One common method is to version and distribute style files as NPM packages.
You can then use the generated platform-specific variables to style your applications.
After set up
Once you've completed the design tokens setup, you can implement a change across any number of platforms with a single update to a token. As tokens change, pass the new token set through the build engine to update the platform-specific style files. After quality assurance (QA), release a new version of your style libraries. Application developers will then update dependencies just as they would for other types of changes and release them to production using your existing QA-production process.