Are design tokens the superpower of design systems?
On the issues they solve and how we leverage them effectively at NN
One of the goals of multi-national companies like NN is ensuring brand consistency, so that their customers recognise and trust their brand no matter what country they are in or what device they are using.
This goal comes with its challenges, often with multiple roots. The Design System team at NN went on a quest to find the root causes of this issue and what would be a feasible solution.
After a lot of research and testing, and with proven results on the table, we’ve found a system that has the potential to not only help build consistent and scalable products with ease, but improve efficiency and collaboration between design and development.
And it’s not just us: other large companies are onto the same solution.
The situation
NN is a large organisation with a range of products and platforms for both app and web users. Before a design system was in place, product teams developed their own component libraries over time, using different frameworks and shared across teams.
This resulted in multiple component libraries within the company, some of them following a newer design that we call Matter, and others using an older design that we call NENA.
We found the way of managing these libraries inefficient and faced several problems:
Problem 1: Styling is defined per component library, hard-coded, causing inconsistencies
Because every aspect of each component was managed per library, every time a colour, font or logo needed to be changed we had to ask every team to apply the changes in their codebase.
When it came to transitioning from the old NENA style to the newer Matter style, manually updating each of the components in sync deemed impossible and eventually resulted in inconsistencies across products.
Solution: Centralised source of truth for all design decisions. Edit once,update everywhere
Instead of using hard-coded values in the first place, design tokens are used to manage all design decisions within a single source, which can then be distributed to different component libraries.
To make it clear, a design token is nothing more than a key-value pair. In simple terms, it is a design decision represented by a human-readable name.
This key-value pair can represent a variety of design decisions from typography to colour, border sizes, assets, shadow and opacity values.
They come in all forms and shapes — from strings to numbers and Bezier coordinates.
And they can look as simple as this:
backgroundColor.button.primary: #EA650D;
In the example above, the key (or token) is backgroundColor.button.primary and the value it holds is a reference to the HEX colour code #EA650D which is a dark orange colour.
Instead of having to change a value in all designs and codebases where it has been implemented, we’d only need to change the relevant design tokens within a single file.
This tech-agnostic approach significantly saves time and makes for a straightforward solution to evolving styles and re-branding.
Problem 2: Difficult to manage and slow-paced
Having to manually update all instances of design per codebase is neither efficient, nor scalable.
If it were a single library that approach might be good enough, but in our case this proves to be inefficient and highly error prone.
One of the problems is that elements can share the same values for different purposes, but they don’t necessarily need to update at the same time.
Solution: Human-readable names, same in Figma and code
Following naming conventions eliminates confusion and makes for seamless collaboration between designers and developers.
In the example of the token `backgroundColor.button.primary` it is more than clear that this key holds the value of the background colour of a primary button, which might be orange and might be red.
The fact that the colour value is undisclosed in the token name itself is one of the reasons why wherever it is applied can remain untouched for years, but its appearance can change as often as the value does.
This design decision is self-explanatory and can now be changed in one place, and updated everywhere, in seconds.
Just like in the James Bond movies, where there’s been six different actors playing the protagonist, yet we know them all as James Bond. And when we think of James Bond, we don’t necessarily think of Daniel Craig or Pierce Brosnan, we just think of James Bond.
Beyond rebranding: Theming for accessibility
Not only do design tokens tackle the aforementioned problems, but when implemented correctly, they truly shine their power in theming and scalability.
Having a single source of truth gives the flexibility to easily manage themes within the same space, such as having a light and dark mode.
Different colour modes can be implemented for accessibility, such as a high-contrast colour mode for improved visibility and font scaling modes, so that small text will be legible on bigger screens and vice versa.
What’s next
We are on a mission to make Design Tokens a standard for both designers and developers across the company.
Having created a single source of truth in the face of a npm package, we are now equipped to leverage the power of design tokens by incorporating them into the development flow.
Both of our React and React Native component libraries are fully implemented with Design Tokens with value transformations happening under the hood, ensuring full consistency.
While we decided to not support older styles with design tokens, our library will keep expanding, with dark mode and theming soon to be implemented.
The availability of tools that support Design Tokens is increasing and the W3C together with the Design Token community is working on standardising the design token format which promises a bright future.
