Innovation occurs in a lifecycle. Someone invents an incredible technology, early adopters set the tone, others come along for the ride, then the laggards reinvent the wheel. From dark mode to fluid grids, it often takes years for the most important design advancements to become a household name. So although the Salesforce design team invented design tokens more than half a decade ago, the technology stays in the early adopter phase — just waiting for the legions to join the early majority, push the technology towards ubiquity, and save organizations the time and money they need to start innovating.
To do our part in ushering in this new phase of the adoption lifecycle, we talked to Kaelig Deloumeau-Prigent, co-chair of the Design Tokens W3C Community Group and front-end developer working on development tooling at Shopify. Here, Kaelig shares his thoughts on the opportunity tokens give designers, how to implement them at any scale, and why they can be transformative for a product team.
Design tokens: Your key to unlocking cross-platform collaboration
Join Ehud Halberstam, Senior Product Manager at InVision, for a fireside chat with Jina Anne, the concept-creator of design tokens, and Kaelig Deloumeau-Prigent, founder and co-chair of the Design Tokens W3C community group. They’ll demystify design tokens and give you real-world strategies to start building them into your design systems practice.
Inside Design: What’s most exciting to you about design tokens?
Kaelig: At the industry level, I know that the first version of the design tokens specification won’t necessarily solve all of today’s problems, but it opens up the doors to tomorrow’s tooling and processes. Design work should be about building customer value and great experiences, but with the tools we have right now, there’s a dichotomy between what you design and what you ship. Having a common industry standard will help reduce the amount of “work that’s about work”, as we all start having equal access to tools that make cross-disciplinary collaboration better and faster.
At a company level, I’m excited to see people from all disciplines talk to each other about design using the same language, as we simply can’t implement design tokens in a design or engineering silo.
You talked about the future of tooling, but why should teams adopt design tokens right now?
We were all talking about fluid grids for years before you could have a real browser in your pocket. Then in 2007, the iPhone came out. People started caring about the mobile web and you saw advocacy for responsive design. Dark mode too: Once Apple released dark mode in iOS, people started caring about building dark mode into their apps and websites. It’s not easy to roll out a good dark mode.
Today, we’re designing for so many devices and use-cases. Having tokens will help your team become more agile when shipping all these experiences. For example, Google has a suite of products that will run on both a tiny watch, a phone, a TV, a car, or even devices without a screen. If you plug your phone into the car all of a sudden the dashboard looks incredibly familiar to what you have gotten accustomed to on your phone, but slightly tweaked to fit that use-case. Then you get back home, and turn your phone into a TV remote. You expect everything to work seamlessly across the board—the colors, the icons, the shapes to be the same, while the way to interact with these devices are different (for example: touch sizes, level of attention, distance to the screen…). If you have a single design language rolled out across these devices, you can gain a heightened confidence as a designer that your intent is going to scale seamlessly across all of these products.
The human element is an important piece: You’ve been rolling out design tokens at a few companies now. From your perspective, who should start a design token initiative and how do they go about it? Is it always cross-functional?
I think it depends on the size of the company, the product, and whether it’s part of the product strategy as a whole. For example, Shopify merchants can theme their checkout or customize their shop’s theme to match their brands. There’s a ton of aspects of Shopify itself that incorporate some level of “design tokenization.” So for Shopify, the scale of user needs can justify a big effort, with dedicated teams.
However, for a small company or startup (or even a bigger company that doesn’t necessarily have a strong design ops culture, but perhaps has a small design system), it’s fine to kick off the initiative in your spare time. You shouldn’t have to justify a whole chain of commands if you just want to experiment with them. I would hope to see designers who dabble in code just going at it and creating a proof of concept, then demoing it to the team. At the very least, this will plant the seed of design tokens, and at best, it can turn into a real thing that transforms the way their design and engineering organizations work together!
The people implementing tokens are usually not a design system team. It’s people moonlighting, doing this stuff in their spare time. I think it’s exciting to have people putting together an MVP as a new way of collaborating. What do you think that MVP would look like?
Start with your color palette first, since you probably already have it documented. I’d delay working spacing, typography, etc generally bring their own cross-platform concerns, and may require a bit more “design token architecture” know-how. Put the colors in a JSON or YAML file, or if you’re using a tool such as DSM, export them from there. Then use a build engine to transform it into consumable code. Share it with your engineering team and see what happens.
What if a developer pushes back on adding an abstraction layer on top of their pre-defined variables? How would you respond?
At Shopify, we had a problem where we would deploy a fix, but it wouldn’t evenly populate across all our developer’s code bases. While we had a Single Source of Truth (SSOT) for our design tokens (a centralized data bank for our design system), we had tokens specific to certain code bases. I didn’t understand why, so I went to talk to our developers: I found that while our tokens shared a naming convention, the color values weren’t consistent.
The exercise helped me understand why the developers made those decisions in the first place and confirm which shade was the right one. We took the chance to centralize and codify it in our SSOT and created transforms to adapt it back to our code bases. In the end, our solution was plug-and-play. It didn’t impact the dev workflow at all.
Now, we don’t need to investigate color decisions. In fact, a few months ago, we needed to change our link shade to meet accessibility requirements. Instead of copy and pasting that shade across multiple code bases, we did it in our SSOT. We still had to update the packages across our code bases, but we were assured that we’d implement the right shade.
People don’t stay at companies that long anymore. Designers and developers often help create something and then move onto the next thing, taking their institutional knowledge with them. Documentation seems like an addendum to many peoples’ workstreams. It seems like design tokens help make institutional knowledge actionable for designers. Would you agree?
I agree. Unexplained constraints frustrate and alienate designers, and often, designers spend a lot of their time playing Sherlock Holmes searching for the institutional context around them.
They’d rather spend their time innovating on new solutions and iterating to provide value to customers, rather than being reduced to placing pre-built boxes on the screen. If they can’t find why something is the way it is, they may default to ignoring a constraint completely, and accidentally end up reinventing the wheel or creating an experience incoherent with the rest of the project.
Design tokens aren’t just about adding code to design elements, neither are they setting an arbitrary, unbreakable ceiling for designers. Ideally, each token should be a well thought-out name representing a value, and be augmented with a comment or description of how it’s used and what it means in your design system, codifying your design decisions and explaining the “why” behind any constraints.
This is when governance comes in: It’s important to document your contribution guidelines and provide a space where people can ask questions about a token’s context. When people repeatedly ask questions about a token, it’s a signal to modify or update your documentation (even better if folks can propose improvements themselves). With a centralized source of truth for that documentation, the whole company benefits from these updates at once!
When paired with a design system, tokens help designers sit on the shoulders of giants, documenting the whole spectrum of their work. Essentially, It helps them picture the box they’re tasked with thinking outside of.
How do you build co-ownership around design tokens?
All design tools have committed to a token standard and things will get easier and better over time as more people integrate it into their workflows. However, before we can imagine a more seamless, collaborative future, we need more participation. Despite the technical name, design tokens are for everyone — that’s the mission of the Design Tokens Community Group and Jina Anne’s advocacy efforts. But right now, only the most design-mature companies have hired design token managers. The most work is being done by moonlighting individual designers and developers, documenting contribution guidelines and socializing the idea internally at their companies. VPs and heads of designs are helping impact the culture, too, by advocating that product teams can’t be pressured to deliver all the time and that they need time to take a step back and systematize things.
