Design tokens
strategy
Digital Publishing
Optimising a design system with a multi-brand design tokens strategy
To unite 17 websites under one design system, I helped develop a multi-brand design tokens strategy from the ground up. The result: 200+ scalable tokens per site, built for consistency, accessibility, and cross-brand support.
Client
GAMURS Group
Timeline
On and off over 6 months in 2023
Team
Creative Director
2x UX/UI Designers
3x Developers
What I did
After diving into research, I audited UI components for shared properties, defined a flexible taxonomy structure, and led our accessible colour approach.
Context
Embarking on a quest to unite 17 disparate sites into one cohesive network with a new design system.
GAMURS Group is a digital publisher that produces written, video, and social content for 46M monthly readers across its network of 17 gaming, esports, and entertainment websites. Each site had its own codebase and component library making it difficult to manage the network at scale.
To address this, a design system initiative was launched in late-2022 to unify the network. It had three key objectives: streamline processes, ensure design and experience consistency across sites, and enable scalability of the network.
Five examples of how the original sites felt too disparate.
Project Summary
As part of this initiative, I contributed to a multi-brand design tokens strategy, leading the development of our accessible colour approach and playing a key role in defining our token taxonomy.
1-Token Taxonomy
• Reviewed the UI component library to identify the common styles and properties used.
• Created a scalable taxonomy structure for the design tokens.
2-Accessible Colour Strategy
• Researched colour accessibility approaches.
• Devised a method of creating accessible colour palettes and tokens in Leonardo Color with minimal upfront effort.
3-Token Implementation
• Set up a colour palette template in Leonardo Color and design tokens in Tokens Studio.
• Implemented a colour emphasis range to ensure flexible colour application.
However!
Before I could start anything, I needed to figure out what the heck design tokens even were. So, off I went down a rabbit hole of videos & articles to make sense of it all. 😵💫
Token Taxonomy
Armed with my new design tokens knowledge, I audited UI components to identify common properties used.
Creating a taxonomy was key to streamlining token management, ensuring consistency, and supporting the design system’s scalability and maintenance.
Some of the properties I identified in my UI component audit.
With these properties in mind, I explored different taxonomy structures to find the most effective one.
What I wanted was a structure that would achieve 3 things:
Align with different use cases;
Scale with the design system; and
Be intuitive for both designers and developers
One of the initial structures I came up with.
While these were a good starting point, something was off—I hadn’t considered how the components were structured.
Many components were designed with child containers inside the main container.
To give us flexibility within the design system, the styling of these child containers needed to be managed using tokens.
UI component audit highlighting container and child container properties.
I also hadn’t fully accounted for the different pieces of text in components that might need their own token.
Or other elements that might need their own tokens—e.g., elements that each have their own foreground colour in one component.
Breaking down the different types of text in the UI components.
With these new details, I revised and proposed 2 new structures—the second option won the team vote.
This structure also ensured that tokens were grouped appropriately in Tokens Studio, our chosen tokens management software.
The final token taxonomy and examples of how tokens were grouped in Tokens Studio.
Accessible Colour Strategy
With the taxonomy structure in place, I then researched and devised a method for crafting accessible colour palettes and tokens that adhere to AA standards when implemented.
I wanted to ensure consistency across sites.
Since each site needed multiple colour families and grades, a consistent approach was crucial instead of choosing colours and values arbitrarily.
I wanted a process that wouldn’t slow down our design work.
To avoid the need for frequent contrast checks, I wanted a systematic method that was easy-to-remember and that would meet AA standards at a minimum.
I didn’t want to have to reinvent the wheel.
Instead, leveraging an existing process, framework, and/or platform for our own needs was the ideal outcome.
In my research, I came across the US Web Design System (USWDS) and its approach to accessible colour, which uses relative luminance ranges.
Since the WCAG uses relative luminance to calculate colour contrast, the USWDS decided to use it to establish ranges for each colour grade, with grades ranging from 5-90 (0 is always white and 100 is black).
This forms the basis of their "magic number" system—the difference between colour grades is the magic number, and specific magic numbers have specific contrast implications.
A magic number of 40-45 results in WCAG 2.0 AA Large Text contrast. While a magic number of 50-65 results in AA contrast and AAA Large Text contrast, and 70+ results in AAA contrast.
Turning the USWDS' luminance ranges into contrast ratio ranges, I used Leonardo Color to test set ratios for each colour grade in our palette.
Leonardo had several features that met our needs. Specifically, the ability to:
Set fixed contrast ratios (i.e., “lightness stops”) per grade;
Create light and dark mode palettes;
Set up the required colour families;
Output colours to tokens; and
Share palettes with others
A set ratio (right) also minimised the effort required to create palettes and tokens per site.
Once set ratios were defined, I set up a palette template in Leonardo Color that could be duplicated for each site with minimal upfront effort.
(1) With the colour families already set up, we only needed to change the hex value of the base colour per site. (2) The colour grades would then update accordingly.
Token Implementation
Having established the foundation of our tokens system, it was time to create the tokens in Tokens Studio, organising them into “sets” or folders.
Tokens were organised according to this structure:
A Global set for tokens that would be applied universally across components, as well as tokens that would be referenced in semantic and component tokens.
And specific to each site:
A Base set to house all non-colour, semantic, and component tokens.
Color-Light and Color-Dark sets to house the light and dark mode reference colour tokens.
Light and Dark sets to house semantic and component colour tokens per mode.
The Tokens Studio interface with tokens organised into sets/folders (where "Default" is the unbranded design system).
However, after I began applying these tokens to components and initial page templates, I realised that the setup of colour tokens lacked flexibility.
Page templates began to look very bland and near-identical.
This was because components only had one colour token for a specific attribute (e.g., background colour). It was most apparent with article tiles & groups, which were two of the most prominent components used across the websites.
It wasn’t possible to differentiate between pieces of content.
We also couldn’t use colour to create visual hierarchy or interest. For example, giving 1-2 sections on the home page different background colours.
To address this, I researched various design systems, focusing on their approach to colour application.
Some of the design systems I researched. Note: Goldman Sachs’ system is no longer publicly available.
Inspired by these systems—Goldman Sachs’ in particular—I implemented a colour emphasis range that would work with our design system and existing taxonomy structure.
Expanding Goldman Sachs’ Minimal, Subtle, Bold range to encompass Strong and Sponsored (to differentiate sponsored advertising content).
Outcomes & lessons
All of this work led to the creation of 200+ design tokens for each site. But it wasn’t without its challenges and some things could have been done differently.
1-I would have added design tokens to the design system at a later stage.
Developing the system’s UI component library and tokens at the same time led to inefficiencies. It caused repeated changes and updates, resulting in several rounds of token reapplication.
2-I would have involved developers from the start.
Their late involvement meant we had to revisit some token applications and create additional tokens. Their input on token use cases would also have been helpful in the beginning.
3-I would have explored more ways to apply tokens.
Managing over 200 tokens per site (across 17 sites) is complex. We could have considered using fewer component-specific tokens, applying styles more generally, and limiting variety to just colour.
Key Takeaway