An introduction to the engineering side of design tokens
Dan Donald
Much of the conversation around design tokens seems to be around the design side of the equation – how designers might be able to use this format. What happens after design decisions have been captured? How might developers/engineers use them? Let’s take a look…
—
What are design tokens again?
If you’ve not yet had the chance to play with design tokens just yet, you could think of them as collections of ‘spicy variables’ (as I think Luke coined them). The intent behind them is to have something that works across design and development to avoid handover.
Going back to the middle of the last decade, the folks at Salesforce pioneered them to bring their teams closer together and share the actual values rather than duplicating references all over the place. The end goal for design tokens is that interoperability with design tools and code to get to a more seamless workflow for design decisions.
Format and interoperability
While in theory you could use almost anything for tokens (I’ve seen examples in YAML for example), you’ll normally see them stored as one or more JSON objects across any number of files. There’s a balance with how they’re written, in terms of keeping it pretty focused while also providing context. As the values are often well nested, you can infer what a value might be or add in some metadata to the object to say what type of value we’re working with.
In order for this dream of interoperability to become real, a W3C Community Group was formed to look at standardising design tokens. Loads of the big names are involved from the design world so the indications are that this standard, as it emerges could find its way into your team’s design tool of choice in the relatively near future.
Systems thinking and abstractions
This is new ground really. The design-developer handover has been around…forever…so learning how we might all work from the same set of tokens throws up interesting questions.
- Should designers be able to engage more with the tech pipelines to push out token changes?
- Who should be responsible for managing change with tokens?
- How should change sync between designers and developers?
That last one feels very much like what version control has done for developers for years but it’s new when considering bringing designers into the mix. It’s not been a normal part of a designers workflow to sync with a remote source before working on a design, or for your existing designs to change because you’ve pulled down an update. All of that is kind of exciting.
Through tokens, there’s an opportunity to get more convergent thinking and get these disciplines closer together with how we think about structure and systems. That doesn’t mean that design should code as such, but when we think of the architecture of our design systems, we may start to have more in common than we used to.
Whereas a designer might pick a color, maybe add it to a palette for their work and as developers, we’d have to inspect or pick out what the value is and add it to our code as a variable, now we need to work more collaboratively to consider naming and abstractions, so we’re all using the same language.
Output and use cases
While our JSON will at some point be consumed by our design tools and we know it’s usable by JavaScript and loads of other languages, it might not always be what we want for use in our components. Here’s where projects like Style Dictionary came in. Either using their predefined templates and processes or writing your own, it globs together all of the JSON files and loops through your objects to generate your output. They’ve got the ability to easily spit out CSS variables, Sass (as variables or maps), some XML for Android or Swift code for iOS…all sorts of formats! It’s relatively easy to write your own build process with your own templates and transforms to get the output that’s right for your design system too. For example, in the past with a custom build process, I had it generate chunks of HTML I could pull into our documentation. It’s also worth noting Lukas’ post around using the emergent W3C standard with Style Dictionary too.
What this means is that there’s likely a build step you need to factor in: ensuring the tokens are up to date and running the output generation from something like Style Dictionary. It also means that with that step, you’re able to use the same tokens for potentially many different platforms at the same time and adapt the values to the format that works best for them. It’s powerful stuff.
Managing change
Tokenization and using JSON aren’t necessarily the hard bit in this equation. Considering designers as part of what used to’ve been primarily a technical domain means ensuring that managing change works well.
- Who can and can’t do what kinds of changes?
- How do people know that change has been made and what the impact may be?
- Do we need extra build steps on our CI/CD workflows to catch unintentional change more than we did before?
- Will more design tools use branching or be able to work better with version control when working with tokens?
- How might reverting change or deprecation work in the world of design?
From our simple JSON objects, we’ll increasingly have a tool to bring design and development together and generate all kinds of output, which is a really big deal. It’s entirely likely that you’ll already have variables of some kind in CSS, Sass/LESS, or in JavaScript for Styled Components, which means there’s an opportunity for greater alignment and gradually tokenizing all of the visual properties that make sense for you to store in that way.
Conversations around naming and structure should get us to a place where definitions is carried through the process from design to implementation. It doesn’t have to be a huge project to adapt to design tokens; a simple proof of concept working on something foundational, like colors can be a good place to start.
Underlying benefits
If your team uses Figma on the design side, it’s worth looking into Tokens Studio. Their integration with the likes of Github shows the direction of things to come, allowing you to create and consume tokens and sync them with a repo. It’s likely other tools will follow, so spending some time looking at this workflow would be really valuable.
For designers, this might mean a lot of new ground to understand, so our role as developers can be to help with that and look at the flow of how tokens can be decided upon, as forming consensus can be really hard. The workflow from the design tool is very much then up to us. As you get deeper into design tokens, you can alias token references, and there are different techniques and structures you can put them through to describe themes and changes of color palette – essentially any design property. With all the power they represent, it’s ensuring that this change is managed well and clearly communicated, so everyone knows what to expect…and there are clear contingency plans in the event of undesirable change being released.
Tokens aren’t just an opportunity to abstract a bunch of design properties from components, they’re an opportunity to coalesce around a way of us all speaking the same language and a more collaborative way of working!