Component-tokens first? Hear me out…
I know…this starts off sounding like it might be click-bait or being deliberately contrary, but let me explain. As a community, we’ve largely accepted that the 3-tier model for design tokens kind of works for many use cases, whether all layers are needed in your particular use case or not.
This assumes that tier 1 (global, base, reference, primitive tokens) hold the actual values of our design decisions, that tier 2 (alias, system, semantic tokens) tend to be the ones that are actually used, that serve as references to tier 1 tokens and that in some cases, tier 3 (component-level tokens) can be useful. These latter tiers serve as wiring up relationships to eventually arrive at the values needed by the system.
Something that became very apparent in my earliest experiences with design systems is that change is hard. Really hard. A successful design system should evolve to continue to meet the needs of those consuming from it to create the end user experiences that we’re ultimately all here for.
Some of this complexity around change management is the impact of change, the blast radius if you like. There’s also the slight paralysis I’ve come across where teams want to get things perfect before releasing anything. That fear is related to the feeling that change is difficult to do. Certainly, when it comes to design systems that have the design and dev aspects tightly bound (so your design and code expressions of components/assets are 1:1), this is really apparent.
Convention dictates that you should approach your design tokens from those base design decisions (stored in tier 1) first, and get this right before moving up the layers. I think we can challenge this with an eye to managing change. I’d preface this by also saying that over-engineering can be an easy trap to fall into!
The notion of component design tokens is that any design decisions used in a component such as button-background, button-text-color, button-border-radius, etc have tokens that then refer to our tier 2 and so those to tier 1 tokens. This ‘wiring’ between these layers gives a load of scope for theming and gives us flexibility beyond most people’s needs — so why consider them at the beginning?
For many new design systems, we’re learning as we go. We’re auditing what we have and attempting to codify what we find, rationalising and structuring as we go. What this actually might imply is that we know what design systems are currently needed at the component level but have less clarity as we go back to the more foundational decisions. As we then name our colours, describe the spacing units we’ve found and make sense of the estate, there’s little value for consumers and we’re a way-off making things better.
Perhaps a pragmatic approach may be that in our designs and code, we start the other way around. We can encode the current thinking in component-level tokens and have them in use right away — focusing on the workflow and method of delivery. This essentially moves values that may exist in CSS (in the case of the web) into design tokens and looks at generating something consumable. It can also be done in a piecemeal fashion as the goal is no visible change.
Why should we bother? What we then have is control over all of these design decisions and move them into the domain of the emergent design system. It sets the foundation for change not only being possible but quite low risk. While these tokens might initially hold the values they represent (ie, button-background actually storing the hex code for the background colour), it means we can change where this value lives — moving it to tier 2 tokens and then to tier 1, almost doing this process in reverse. The end user and the consumers of the design system notice no difference. The structure of tokens might change wildly as more is learned. Names can change with little consequence because, at the point of consumption of these values, there is no change. The token name for a component property remains the same.
Imperfect systems that actually meet the needs of their consumers are often more desirable than ones that are considered more perfect in naming and structure.
If all we needed to focus on was the ‘correct’ ways of doing things, we’d have more successful design systems. The reality is about how we build into the organisations we work within, and the processes and workflows we need to work within or attempt to change. That stuff is hard. Working with the grain of the materials we have to work with (such as these largely unseen aspects) can give a better result, even if in some cases we do things ‘backwards’ like this.
Whether being component-token-first is right for you or not, I guess I want to illustrate that what we as the community gravitate towards as being an ideal might not always be appropriate for you or your organisations. That there are other approaches we need to take to make things work and provide values…and that’s OK.
