I’ve previously written about how you can start a design tokens pipeline by building our “raw” tokens in Style Dictionary and formatting them for various platforms. Then, you can build a Tailwind config (for example) off of that.
But, can you change that order?
The theory behind having raw tokens that can be formatted (via Style Dictionary) is that it you can expose primitive tokens that can be consumed by any platform before you develop more sophisticated assets.
In a word, you build raw, platform-agnostic tokens that are programmatically formatted for N amount of platforms instead of starting with formatted tokens.
The impetus is that you ensure that all consumers (even future ones) will have a way to apply official design system specs to their application.
But, couldn’t we still achieve that goal if we started with formatted tokens and just made sure to un-format them in the pipeline?
It feels more organized in a mental model to start with raw tokens and then to format them.
The downside is that starting with raw tokens also means starting off with raw tools/assets. It can be exhausting to manually enter them without the ease of let’s say utility classes.
What if we built tools to compose raw tokens as easily as we can compose formatted tokens (like composing Tailwind classes, for example)?
Idea: Start with the primitive value tokens of your design system (i.e colors, typography, spacing) and create utility classes for them via a config consumed by Tailwind (or similar). Use these classes to compose the tokens for component-level tokens.
Finally, Style Dictionary (or similar) would take the Tailwind config and component-level tokens, formatting the config for different platforms, while also un-formatting the aggregated, component-level utility classes for various platforms.
In summary, the main bottleneck for creating a Style Dictionary pipeline is creating the component-level, raw tokens. Some have turned to Figma plugins, great. But, what other efficient options are there?
Michael Mangialardi
@michaelmangial1
Christian | Frontend Engineer | Design Systems Engineer. 📚 Author of “Design Systems for Developers” and "Rethinking Agile"
