A summary of
?? Jina A.
2021 video.
While on the Salesforce design systems team circa 2015, Jina was using design tokens to coordinate with
Jon Levine
on the engineering side.
Don’t have 12 minutes to watch their awesome overview? Here is a quick summary:
- Design tokens are similar to variables. They are names for values. You might see Sass variables or CSS variables in your code, maybe even JavaScript.
- But design tokens are more than variables. They include a lot of thinking and strategy—you wouldn’t call “responsive design” just fancy media queries!
- Design tokens are platform agnostic. Design tokens help scale design to non-web platforms like iOS and Android. The primary format might be JSON or YAML, or even a Figma tokens plugin. Then you can generate Sass variables or Android-friendly XML from it.
- Values of design tokens can be computed per platform. A tool like Style Dictionary (or what we used at
Salesforce
: Theo) allows you to store the main value as RGB(), then render a 6-digit hex code for the web, an 8-digit ARGB code for Android, or hsla() for iOS. Or take a main font size like 1rem and output 16px, 16pt, 16 “units”, etc.
- Almost any value can be stored as design token. Colors, font sizes, media queries, base64 images. You can even test and compare the values!
- Use a single source of truth. Save everyone time by maintaining tokens in one shared place. Imagine updating a color and having to file a Jira ticket on the web team, iOS team, Android team — there might be multiple web teams!
- Overrides, theming, white labeling, dark mode, non-UI values. Because design tokens aren’t just a web theme (e.g. MUI) you can store many different values and programmatically override based on your needs.
Please follow Jina via one of their links: https://linkin.bio/jina. Also, you can follow the
Design Tokens Community Group
(GitHub repo) or dive into older design tokens history. This article originally appeared on Medium.