What are design tokens?

You need to look at design tokens from the perspective of a product team whose job it is to turn ideas into digital products or features. And generally speaking, an effective product team is what you'd call multidisciplinary. This means that every skillset, or discipline, is present within the team to execute the project. In our case, we keep the total number of team members as low as possible as well. All we need is a UX/UI designer, a couple full stack developers, spearheaded by a product manager. The most obvious benefits of this setup are agility and close collaboration.

Now, where do design tokens fit in this story? Well, designers and developers generally work in largely separated environments. A designer takes concept sketches or wireframes and turns them into interfaces. A developer takes those designs as input and turns it into a functional front end. But, our designers spend most of their time in Figma, and developers usually hang out in Visual Studio. This "gap" has to be made as small as possible if you want to make progress quickly and smoothly.

And this gap can be bridged by design tokens. More specifically, tokens create the bridge between design and data. For designer it's the styling they define in their Figma files, for developers it's the theming and variables they use in their codebase. In other words, design tokens represent the small, repeated design decisions that make up a design system's visual style. In practice, they replace the static value, such as hex codes for color, with self-explanatory names. Here's a good video that explains the whole thing very well.

What problems can design tokens fix?

Essentially, design tokens enable a design system to remain the single source of truth, throughout the development process. In case you don't know, a design system is basically a collection of interconnected patterns and shared practices. You can look at a design system like a box of LEGO, little pieces you can put together to create, in this case, a user interface or parts thereof.

Anyway, here are a few pains that come to mind when designing digital products that design tokens can fix.

• It's a struggle for the engineer to implement the correct styling from the design. It can become a mess with bad oversight and control.
• It's time-consuming for the designer to check if the engineers have implemented the right color, font, spacing during internal QA sessions.
• Design will always be subject to sudden changes of heart; clients want to see different colors or fonts, which is generally speaking a bigger pain for the developers.

Now, why are design tokens capable of addressing these issues? Well, when you're using tokens for design implementation, style updates will propagate consistently throughout the entire product. The reason this works is because with design tokens, you're creating a new level of abstraction that expands beyond what they represent.

As a design system evolves over time, these changes need to be reflected in the finished product. Design tokens are there to help you keep track of these changes and ensure they are applied consistently. Broadly speaking, design tokens are used to decrease the styling implementation complexity for developers, so they have more time to build actual features, instead of copy-pasting the styling again and again. Plus it gives both designers and clients a greater level of control, with little extra cost.

Use case at Bothrs

You might be wondering, at what point does all this extra work yield a return that's greater than what you put in? In the case of Bothrs, would it be worth implementing design tokens at all, when you're only spending like 6-8 weeks on a first MVP? I'm a designer myself, and at the start of a new project, I need all the time I can get to validate as many features with end users as possible, so that the developers on my team can start right away.

Well, in the case of Bothrs, there are two main arguments as to why we tend to stick with design tokens:

• For one, we're a digital product studio. This means we're working on multiple projects and products simultaneously. Design and development tracks are happening back to back. We need to streamline our way of working the best we can to maintain our velocity.
• And second, the products we build for our partners are rarely one-off projects. We always advocate for building a first MVP and then begin iterating once feedback comes rolling in. This agile approach requires enough flexibility on our end, to quickly adapt to the needs and wants of our clients and their customers.

The main use case for design tokens at Bothrs is therefore twofold: gaining momentum, and maintaining flexibility. We need to find ways to speed up repetitive and time-consuming parts of the process, so that we can focus our time on the actual challenges the client is trying to solve.

Another benefit, is that you can make design tokens are granular or as abstract as you seem fit. Take a look a this pyramid below, which denotes the different levels of specificity design tokens can represent.

I believe a common level is more than enough enough. If were to get into component-specific levels we'd be spending way too much time defining every little thing, tipping the scale in the other direction. Sticking to a common level of specificity and maybe using some component-level tokens (I.E. for a tab bar, input fields or cards) gets the job done in our opinion.

Each team works differently, of course, so it's good to lay down some groundwork in your team to make sure you're using naming conventions that everybody feels comfortable with using. From my experience, naming your design tokens CamelCased is the best fit for most codebases.

Summary

Overall, implementing design tokens in Bothrs' way of working has definitely yielded some great results:

• Time spent on design implementation is decreased
• Time spent on design QA is decreased
• Time spent on design changes (requested by the client) is decreased
• As a bonus; your project files are clean, structured, and consistent

So it's a definite yes for me. I'd argue this setup is necessary even for our shortest tracks. Because it will net you a massive amount of time savings later on. You'll have more time to focus on the important stuff. And if the client comes back for another track, you'll have a solid and flexible foundation to expand upon.