Rex: Color Tokens for accessibility-oriented rebranding
👉 Accéder à la version française
📕 Translated Blandine Paulet
2024: The year AB Tasty chose for its new look
For the occasion, the Product & Tech teams pulled together to act quickly and efficiently.
And with no previous Design System or Tokens System in place, this was no easy task.
If we ask Antoine Berthaud, Product Manager on the PX team, he’ll tell us quite simply: “It was painful”.
Morgane Ruaud, Lead Product Designer, on the other hand, remembers how she felt at the idea of updating the mock-ups to the new charter one by one: “Oh god!”.
In short: we decided it was time to set up a Color Tokens System
Refined, processed, structured. Our Color Tokens System was created not only to improve the handover process and communication between developers and designers, by aligning their design techniques, but above all as a decision-making tool for Designers.
What for, you might ask?
Let’s go back to the pre-rebranding period. We worked on our components with a style set structured as follows:
And that’s a bit of a problem
We’re 7 designers. That’s 7 ways of designing. And 14 eyes. Between the 7 of us, we can decide to make any combination of these colors.
Faced with this situation, the initial idea was simple:
By helping Designers to make identical decisions when faced with similar issues, we were taking a major step towards the UI homogenization of our platform.
How did we do?
Our Color Tokens System is fully described here, but let’s summarize the main concept in a few lines:
By considering interface components as surfaces defined by their background color, we can then limit UI choices by surface type.
Here we have a Card component with a Primary surface, Primary representing the white color used in the majority of the interface (70%). On top of this Card component with Primary surface, we have a Button component with Tertiary (pink) surface.
So, once the designer has defined the surface type, they are presented with a limited palette of options for their choice of text colors, icons, borders, etc.
Example: Pierre decides to associate his Button component with a Brand surface (blue background). He needs to define the text color of his Button component. Text options for Brand surfaces are limited to white. Pierre applies this single option to the text of his Button component.
In terms of structure, what does it look like?
Let’s take a look at the structure — simplified for the purposes of this article — of our system:
We have two levels of Color Tokens. The first level is used exclusively to feed the second level, to make the Token system flexible and adaptable over time. This ensures better maintenance in case of modifications.
Level 1: Option Tokens
The structure of an Option Token ↓
Example of a palette for the ElectricBlue variant ↓
Level 2: Decision Tokens
Structure of a Decision Token ↓
Example of a Palette for a Primary-Default variant (surface) ↓
Primary-Default Palette translation (again with our friend Pierre) ↓
Pierre decides to associate his TextField component with a Primary surface (white background). Based on this decision, he will have access to a limited list of options for designing his component in the “Default” state, including:
- Text & pictograms norm (black), subtle (dark gray), minimal (light gray) and brand (blue)
- Borders & dividers norm (gray) and minimal (very light gray)Des bordures & séparateurs norm (gris) et minimal (gris très clair)
This way, Pierre saves design time and is sure to be in line with his fellow Designers!
And what about Accessibility?
Two birds with one stone
By simplifying the UI decision-making process, we’ve not only homogenized our platform, we’ve also been able to boost our accessibility.
Digital accessibility is based on a number of design rules designed to make a product or service usable for everyone, including people with disabilities.
These rules are provided by various organizations. OPQUAST provides a non-exhaustive list in the form of a playful checklist.
While these subjects are and always have been at the heart of AB Tasty’s concerns, the implementation of a Color Tokens System was an opportunity to ensure that color associations were contrasting enough to be readable.
Avoid unreadable color combinations
Remember this great example of style combinations? ↓
So now you’re beginning to see what I’m getting at…
If you thought it was the designer’s job to know exactly what color combinations were accessible, and that a designer would never, ever put white text on a yellow background, well…
Believe it or not, we’ve done it!
This is our old “Pause” button. As you can see, it doesn’t have enough contrast. And at the same time, why not? Nothing told us when we created this component that it was forbidden.
Prevent when you can’t cure
Setting up our Color Tokens System not only enabled us to homogenize our interface, but also (and above all?) to check the visual accessibility of each use case to propose only associations that comply with the WCAG (Web Content Accessibility Guidelines) of the WAI (Web Accessibility Initiative).
We reviewed the contrasts between text colors and surfaces, based on the results of the Plugin Figma Stark to propose the best palettes to our team.
And, it has to be said, we’re very proud of the result 👀
One figure, one conclusion
According to the World Health Organization (WHO), some 2.2 billion people worldwide suffer from some form of visual impairment. Many of them depend on compliance with accessibility standards to use digital interfaces effectively. To ignore these considerations is to potentially exclude a significant proportion of our users.
The implementation of our Color Tokens System is more than just an aesthetic redesign of the user interface. It plays a crucial role in improving the visual accessibility of our platform.
