news
October 11, 2024Design Tokens, what the heck!?
Design Tokens are the new hot topic, but is it just a passing trend? Come and see why it's not with Edgar Lechaudel, the Design Lead of the Thales Design System. In this article you'll dive into their fascinating world, discover their purpose, and uncover their compelling powers!
Design Tokens became such a hype topic since Figma announced their Variables feature in 2023.
Since then, everyone talks about it like a revolution in our industry and many definitions of Design Tokens are popping around the internet. But still, it can be very difficult to get his head around it. Design Tokens is a broad concept that is hard to define in a single sentence. That's why I won't start with meaningless definition. No, I decided to take you on a progressive demonstration that details what pains they solve, illustrates how powerful they are and explain why they will change the way we design interfaces forever.
Let's demystify Design Tokens together!
So many and repetitive styling when creating interfaces...
For the purpose of this article, we will use a Twitter-like mockup throughout this demo. This design, recreated using the Quantum Design System (Thales Digital Design System), shows the importance of adhering to specific styling guidelines. In combination to standard design principles, this design uses many different styling values to achieve the following visual outcome. Even in a seemingly simple mockup, numerous values, such as colors, typography, and spacing, are essential for a consistent and cohesive user experience.
In other words, those styling values are the ones you set in your Figma inspector panel for every design layer you combine and assemble to create your designs.
We might not consciously care about it, but a wide range of different values are attached to this single mockup. Style values encompass a large number of attributes, including colors, typographies, spacings, borders and many others.
And faster than we think, we find ourselves repeating the same style values over and over across the interfaces. This quickly leads to a chaotic and difficult-to-maintain Design System, especially when scaled up to multiple features, products, or event projects over an entire organization.
Not just styling values but styling decisions
In their most basic form, Design Tokens provide a solution to the repetitive nature of styling. By applying the fundamental principle of Design Tokens, we store our style values in a reusable collection. This allows changes to be propagated throughout our designs automatically, eliminating the need for manual and time-consuming interventions.
For instance, Figma's Styles feature or Penpot Assets are great examples of this basic concept in action. In fact, without realizing it, you might have already been using one of the fundamental principles of Design Tokens.
But Design Tokens is not just that, they push this elementary concept even more forward!
While creating a collection of reusable style values is a great start, it doesn’t tell the whole story. These reference style values are often not intuitive and lack the meaning and context of when, where, and why they should be applied in our interfaces. As designers, we don’t just apply style values thoughtlessly or randomly; we make intentional decisions in our minds for each application. We make decisions based on the usage, the intent of a style as well as its context of application. Let’s break that down in details:
Usage
First, we make decisions in terms or usage, which means where we apply styles. We have to consider the type of element we want to style when applying a style value. If we take the example of colors, a color style might be suitable for a text element but not for an icon element or a border element. The question that comes up all the time is: “what style value can I use on this design element to comply with accessibility requirements and ultimately keep my screens on brand and consistent?”.
Intent
But it goes beyond that. We also make decisions based on intent, which means the sentiment that must convey the visual rendering. For example, we might choose and stick to a specific color for call-to-action element and draw the user's attention. Or, we might use different font sizes to establish a visual hierarchy. These decisions, along with countless others, add to the complexity of styling our interfaces. But the question always remains the same, which styles, or even which combination of styles, should I use to achieve that visual intent?
Context
And that's not all. We also need to consider the context in which our designs will be experienced. For instance, we have to make decisions based on whether the user is in light or dark mode, or if they're using a large or small screen.
This adds another layer of complexity to an already challenging process. It's difficult to keep track of all the possible variations, and even with the best documentation, designers often find themselves asking the same questions repeatedly.
- “What is the smallest icon size allowed?”
- “What is the neutral color to make a text discrete?”
- “What is the font size of a title 1?”
- “What is a large spacing value on mobile?”
- “What is the default neutral text color on dark?”
- “What this the primary color to highlight text?”
- ...
This leads to chronic waste of time, inconsistent styling habits, frictions and decision fatigue.
Design Tokens are here to help with that. They provide a framework for managing a global stylistic language expressed through design decisions. Design Tokens can be applied universally, regardless of the specific design context, avoiding suppositions and limiting the need for a heavy documentation-dependent design process.
Rather than applying meaningless styling references on our interfaces (blue-500), we use our design decisions (color-text-primary). We don’t need to think about the exact value they reference to, the design decision, on its own, becomes explicit on its usage and intent.
As mentioned before, Design Tokens can be applied regardless of the specific context of a design. Whether it's a theme that affects colors, such as dark mode versus light mode, or a theme that impacts spacing and typography, like desktop versus mobile, the underlying design decisions, usage and intent, remain the same, always. Only the specific values associated with those decisions change depending on the context (theme).
Below is an example with a change of spacing value between a Desktop and a Mobile screen. You can notice that the decision applied on the mockups remains the same across a desktop or mobile screen, a “spacing-medium” for top and bottom padding and a “spacing-xlarge” for left and right padding. Only the values applied to those decisions change depending on the responsive theme, Desktop versus Mobile.
Furthermore, Design Tokens help to bridge the gap between design and code a little more. The language provided by Design Tokens is shared between both environments. It means that the same variable names can be used in your design tool and your programming language of choice which allow better communication and design to dev handoff.
Finally, Design Tokens are distributed from one single and agnostic source of truth which allows their portability between tools* and languages. As a result, they ensure that updates are automatically and consistently propagated across all relevant teams involved in digital product design and development.
(*Distributing Design Tokens from a single and agnostic source of truth across design tools (like Figma, Sketch or Penpot) is not easy and obvious as I write this article in September 2024. But it is proven and facilitated for a relevant number of programming languages thanks to Style Dictionary)
Let’s sum this up
Let’s take some time to sum up and have a behind the scene look on how it works.
Primitive layer
At the very beginning of the article, we talked about our collection of values of reference. This collection gathers all the styles options available and that we might need in designing our interfaces. They are deliberate undescriptive variables covering the different family of styles like color, spacing, typography, size, border, shadow, ... For example blue-500, spacing-1, fontSize-3, radius-2, shadow-1, ...
In the Design Tokens world, we call them “Primitives”. They store the raw styling values that make up our interfaces. But as explained earlier, they are not the variable we will directly use to style our interfaces. Actually, we usually keep them invisible from the Design System users. In design and code we’ll use another set of variables connected to those primitives.
Semantic layer (aliasing)
Right after the values of reference, we shift focus to design decisions: the famous stylistic language. This collection gathers variables that unambiguously describe the usage and intent of a specific primitive value. Those are the variables that make sense to use on our interfaces, they represent the design decision we make to craft our interfaces.
In the Design Tokens world, we call them “Semantics”. While primitives variables store raw values, semantic variables reference other variables, primitives. This is what we call “aliasing” in the Design Tokens” jargon. These variables provide meaningful context and clarity for our interfaces, revealing the underlying design intentions and guiding informed decision-making.
Not all primitive variables have to be used or connected to a semantic variable. The style options available in the primitives will be useful to assign specific values to our semantic variables (design decisions) depending on the context, the themes.
Themes (permutation)
Themes are the different appearances our interface can take depending on the context: dark or light mode, mobile or desktop view, color scheme “x”, “y”, “z”, contrast high or low, density airy or compact, ... Themes can be combined together to represent a specific design context. In the Design Tokens’ jargon this is what we call “Permutation”.
What makes the theming feature really possible at scale is the semantic layer, it abstracts the primitives behind design decisions (why that is is the topic for another article).
The semantic layers allow us to have persistent variables mapped and applied on our interfaces regardless of the context. A theme appears when a semantic variable can be attached to more than one reference value.
For example, if I want to add a dark mode and a mobile version to my light mode desktop project, I would need to adapt some design decisions in regards to those new design contexts. In fact, a dark mode and a mobile version will undoubtedly have an impact on the styling value attached to my design decisions regarding color, typography, and spacing.
This is where the magic really happens!
Rather than having to duplicate my mockups and manually apply new specific design decisions on our interfaces for each new context or theme, the technology of Design Tokens allows us to assign different values of reference to any single semantic variable (design decisions). You can visualize them as mapping tables where each line represent a semantic variable, each column a theme and each cell the corresponding primitive value of reference.
Then, depending on the themes we apply to a page or a section of a page, we can switch between those different values to automatically adapt our interfaces without any intervention on the design mockups or the code.
To illustrate this concept, let's examine the background color of a page.
To apply the color to our main app background we have a semantic variable (design decisions) called “color-background-neutral-base” (our semantics collection include different levels of surfaces to manage backgrounds superposition and chaining in our interfaces). In the dark theme, we've assigned the primitive token “bluegrey-900” to that semantic variable and when switching to the light theme, the value associated with this semantic variable changes to “bluegrey-0”.
What you can notice here is that the design decision applied on our mockups remains the same. Only the value of reference assigned to it changes depending on the chosen theme.
This demonstrates the flexibility and versatility of Design Tokens.
We can use the Design Tokens technology as a configurator to morph the style interface into almost anything we want.
Below is another example, illustrating how spacing can be handled through theming. On this tweet component we applied a semantic variable (design decisions) called “spacing-paddding-medium” to control the space within the tweet main container. In the desktop theme, this semantic variable references the “spacing-5” primitive variable while in the mobile theme it references the “spacing-3” primitive variable. Again, the same spacing design decision applied on the mockup persists across themes, only its assigned value changes depending on the context, the chosen theme.
Design Tokens: The strategic advantage your organization needs
Design Tokens became the backbone of any robust Design System. They are a strategic advantage that elevates the way designers and developers collaborate, creating a seamless bridge between design intent and code implementation.
Design Tokens provide an essential layer of abstraction that goes beyond components by focusing on the core styling variables of an interface—such as typography, size, color, spacing, assets, layout, borders, shadows, grids, animations, opacity, and breakpoints. By defining these foundational design decisions, Design Tokens empower teams to achieve greater control and flexibility, ensuring that every part of the product reflects the intended design language and decisions.
In today’s competitive landscape, adopting Design Tokens is not just an option—it’s a critical move for any product team looking to optimize workflows, enhance collaboration, and maintain consistent libraries and documentation. Here’s why Design Tokens should be at the heart of your strategy:
Save time & Energy
The benefits of reusability and a well-structured system are a game-changer. Design Tokens significantly reduce the time and effort required to implement styling updates, making the process of adapting, maintaining, and documenting styles both streamlined and error-free. By centralizing style values and decisions, Design Tokens allow you to update components or styling references across multiple platforms and mockups with just a few clicks, ensuring that changes are consistently propagated wherever the system is in use.
No more tedious updates across countless screens or worrying about forgotten changes. Design Tokens transform what used to be a laborious and error-prone process into a swift, reliable action. Imagine adjusting a color or spacing value in one place and seeing that change instantly reflected across your entire application. Responsive design becomes so much more manageable as designers can effortlessly adjust Token values to accommodate different screen sizes—saving your team precious time, unlocking new capabilities at scale, and eliminating manual errors. Isn’t that magical?
Be more consistent
Design Tokens create a shared language that bridges the gap between design and development, fostering better collaboration and reducing the risk of misunderstandings. When design decisions are encapsulated in tokens, everyone—designers, developers, and stakeholders—works with a shared dictionary. This not only streamlines the handoff process but also minimizes discrepancies between the design intent and the final implementation, saving time and avoiding costly rework.
I’m sure you’ve experienced the frustration of seeing your carefully crafted design implemented incorrectly due to miscommunication. With Design Tokens, those days are over. They ensure that the final product is not only true to the original vision but also implemented efficiently and consistently, making the entire process from design to deployment smoother and more cohesive. It’s like having a translator that always gets it right!
Embrace versatility
Design Tokens empower teams to effortlessly adapt interfaces to different contexts and scenarios, from screen sizes to user preferences. This versatility is crucial in today’s multi-platform world, where a single design needs to look and perform perfectly across a variety of devices and use cases. By simply adjusting token values, teams can rapidly configure and personalize the appearance of an interface without diving into complex and time consuming redesigns.
Consider scenarios like implementing dark mode or adjusting for mobile displays. With Design Tokens, such changes are as simple as creating a new preset by adapting a few values, enabling rapid iteration and testing. Imagine using this flexibility during experimentation, discovery phases, or even for A/B testing—allowing designers to explore different variations of an interface to identify the most effective approach with just a few clicks.
Design Tokens are more than just a collection of design decisions—they are a strategic asset that allows for infinite customization and adaptability. By embedding these tokens within your Design System, you create a resilient framework that scales effortlessly, supports systemic approaches, and optimizes every aspect of your product development process. Adopting Design Tokens isn’t just a technical upgrade; it’s a new paradigm towards a more efficient, collaborative, and future-proof way of working at scale. It’s time to fully embrace their power and elevate your product design to new heights now!
Quantum Design System core team & Design Tokens, a long love story...
Design Tokens were adopted from the inception of the Quantum Design System in 2021. An initial research phase, aimed at studying the overall implementation method of the Design System, quickly validated the effectiveness of Design Tokens in aligning and coordinating the efforts of the Quantum core team for design and development.
In 2022, we decided to reassess our "design-to-dev" standards and wanted to conduct an audit phase to improve the maintenance and scalability of the Design System. More importantly, we aimed to provide real flexibility to cover the wide variability of products in Thales' portfolio. Therefore, we decided to recruit a Design Lead for the core team to leverage his expertise in "design-to-dev" standards and Design Tokens.
Check out our full retrospective about Design Tokens in The Design Tokens book
