Canonical Design tokens
- Year
- 2024-2025
- Type
- Work Project
When I joined Vanilla, Canonical’s design system could probably be described more as a CSS library. It lacked features that modern design systems have, including a systematic approach to visual foundations. Visual foundations existed most often as SCSS variables but sometimes they were also hard-coded directly into the components. At the same time, other teams had started implementing their own interpretations of Vanilla in Flutter, and there was a Figma library which was supposed to mirror Vanilla components. This situation made it quite manual and error-prone to ensure that these other platforms visually matched our source of truth as there was no way for them to interface with the visual foundations of the CSS library directly.
Canonical also recently changed its logo and its official typeface (from Ubuntu to Ubuntu Sans), and the fact that the old logo and typeface can still be found in various places across Canonical’s presence shows that Canonical lacks the infrastructure to efficiently implement these branding and visual changes across Canonical’s portfolio.
Modernizing the design system
It was clear that what was needed was a centralized and systematic approach to visual foundations. In essence, Canonical needed Design tokens and I pushed for and led this effort to create these Design tokens.
I started by creating an inventory of existing variables and their flows from variables to actual usage in components. This approach, suggested by Nathan Curtis in his writing on the topic, made sense for understanding the current needs of our design system and its users. I had a head start on this task since I had recently built new Figma libraries for Canonical, which required, amongst other things, extracting all visual information from the source code. I was able to use this as a foundation for the inventory and flows and so I quickly gained an understanding of the existing needs.
Research and Specification
While conducting this inventory, I performed extensive research on design tokens. Despite their seemingly straightforward nature, implementing design tokens properly is surprisingly complex. A significant portion of the challenge lies in establishing naming conventions, a notoriously difficult and often contentious process in larger organizations.
Since design tokens are fundamentally about creating a shared language for visual properties, getting the naming right is critical to their success. Working with another designer, we began drafting a specification for how to structure and name design tokens at Canonical.
Design tokens specification
I had seen great success with a collaborative format when creating the Figma libraries, where I created an initial specification and then held several discussion meetings with the wider team and stakeholders. I applied the same approach to design tokens. After creating an initial specification draft, I invited the team to several discussion meetings where we went through all sections of the specification until we had something everyone was happy with.
Through this collaborative process, we reached agreement on the taxonomy for design tokens at Canonical, covering naming conventions, token organization, and processes for storing and updating them.
Implementation
With the inventory, research, and taxonomy complete, it was time to actually create the tokens. This involved understanding current needs from the inventory while also being forward looking about future requirements for the design system as we were looking to generally modernize the design system and make it more scaleable. So while working on design tokens I was not only looking to translate our current visual foundations into a Design token framework but take the opportunity and adopt a more systematic approach to visual foundations.
For colors for example, we previously didn’t have a proper UI palette. Colors were added on an as needed basis. I wanted to use the color token work as an opportunity to move to a more systematic approach. I created a palette based on Matthew Ström’s article about how to create color palettes for design systems where he describes an approach where you do not create shades based on lightness but based on contrast between shades (which makes creating accessible color combinations easier).
At the time of writing, I had created primitive dimension tokens, primitive and semantic typography tokens, and was almost finished with the color tokens. With plans to work on semantic dimension tokens and smaller token categories such as asset tokens next.
Result
Engineering had not yet moved to implementing design tokens, but I was curious about what the implementation would actually look like in real world scenarios. I’m always interested in understanding how things work, and I was particularly drawn to the work the W3C Design Tokens Working Group was doing. I wanted to get hands-on experience with Style Dictionary to understand its capabilities and limitations, and how different tooling choices would affect our token authoring process. This exploration turned out to be valuable. I discovered several implementation limitations that I was able to feed back into the token authoring process before engineering began their full implementation.
Below is the code of my prototype with a Style dictionary build system in the
/build folder, CSS and Figma
(tokens.studio for Figma)
output in the /dist folder and some of the tokens we had created to this point
in the /tokens folder.
Once engineering moves to full implementation and adoption across platforms, Canonical’s visual foundations will be more systematic and platforms more aligned, creating a scalable foundation that will support the design system as it continues to mature.