REX : Les Color Tokens au service d’un rebranding orienté accessibilité

Lea Seibel
6 min readSep 11, 2024

--

👉 Access English Version

2024 : L’année qu’a choisit AB Tasty pour faire peau neuve.

Pour l’occasion, les équipes Product & Tech se sont serré les coudes pour agir vite, et pour agir efficacement.

Et pour cause, sans Design System ni Tokens System mis en place antérieurement, l’exercice n’a pas été de tout repos.

Si on demande à Antoine Berthaud, Product Manager au sein de l’équipe PX, il nous répondra tout simplement : “Ce fût douloureux”.

Morgane Ruaud, Lead Product Designer, quant-à-elle, se souvient de ce qu’elle a ressenti à l’idée de mettre à jour les maquettes une-à-unes à la nouvelle charte : “Oh la vache…”.

Bref, on a décidé que c’était l’occasion de mettre en place un Color Tokens System.

Peaufiné, travaillé, structuré. Notre Color Tokens System a été créé non seulement pour améliorer le process de passation et la communication entre développeurs et designers, en alignant leurs techniques de conception, mais surtout comme un outil d’aide à la prise de décision pour les Designers.

Pourkoifèr, me direz-vous ?

Revenons sur la période pré-rebranding. Nous travaillons alors nos composants avec un set de styles structuré ainsi :

Tableau récapitulatif des anciens styles UI chez AB Tasty

Et ça pose quelques soucis.

Nous sommes 7 designers. Ça fait 7 façons de concevoir. Et 14 yeux. À nous 7, on peut décider de faire n’importe quelle alliance de ces couleurs.

Exemples de boutons créés grâce à une palette de style. Cet exemple met en avant les multiples façon de lier ces couleurs, de façon accessible, ou non.
Petit exemple (sans abus évidemment) de possibilités UI avec ce set de styles.

Face à ce constat, l’idée initiale était simple :

En aidant les Designers à prendre des décisions identiques face à des problématiques similaires, on faisait un grand pas en avant vers l’homogénéisation UI de notre plateforme.

Komenkonafé ?

Notre Color Tokens System est entièrement décrit ici, mais récapitulons-en le concept principal en quelques lignes :

En considérant les composants d’une interface comme des surfaces définies par leur couleur de fond, on peut ensuite limiter les choix UI par type de surface.

Illustration représentant une surface (composant), composée d’un autre composant (bouton), d’un texte, d’une ombre portée, d’une bordure et d’un arrière-plan.

Ici, un composant Card de surface Primary, Primary représentant chez nous la couleur blanche, utilisée en majorité dans l’interface (70%). Sur ce composant Card de surface Primary, on a un composant Button de surface Tertiary (rose).

Ainsi, une fois le type de surface définit par le designer, ce dernier se voit proposer une palette limitée d’options pour son choix de couleurs de textes, icônes, bordures,…

Exemple : Pierre prend la décision d’associer son composant Bouton à une surface de type Brand (fond bleu). Il doit définir la couleur du texte de son composant Bouton. Les options de texte, pour les surfaces de type Brand, sont limitées au blanc. Pierre applique cette unique option au texte de son composant Bouton.

En terme de structure, ça donne quoi ?

Coup d’oeil sur la structure — simplifiée pour l’article — de notre système :

On a deux niveaux de Color Tokens. Le premier niveau sert exclusivement à alimenter le second niveau, afin de rendre le système de Tokens flexible et adaptable dans le temps. On s’assure ainsi une meilleure maintenance en cas de modifications.

Tableau explicatif des fonctions des deux types de tokens de notre nouvelle structure : les tokens d’option et les tokens de décision.

Niveau 1 : Les Tokens de type Option

Structure d’un Token d’Option ↓

Structure de nos Tokens d’option

Exemple de Palette pour le variant de type ElectricBlue ↓

Exemple de palette, avec la palette ElectricBlue

Niveau 2 : Les Tokens de type Décision

Structure d’un Token de Décision ↓

Structure de nos tokens de décision

Exemple de Palette pour le variant (la surface) de type Primary-Default ↓

Exemple de palette, avec la surface Primary

Traduction de la Palette Primary-Default (toujours avec notre copain Pierre) ↓

Pierre prend la décision d’associer son composant TextField à une surface de type Primary (fond blanc). À partir de cette décision, il aura accès à une liste d’options limitées pour designer son composant à l’état “Default”, parmi lesquelles :

  • Des textes & pictogrammes norm (noir), subbtle (gris foncé), minimal (gris clair) et brand (bleu)
  • Des bordures & séparateurs norm (gris) et minimal (gris très clair)

Ainsi, Pierre gagne du temps de conception et est certain d’être aligné avec ses collègues Designers !

Recherche facilitée des Tokens sur Figma

Et l’Accessibilité dans tout ça ?

D’une pierre deux coups.

En simplifiant le process de prise de décision UI, on s’est non seulement lancé dans l’homogénéisation de notre plateforme, mais on a aussi pu mettre un coup de boost à notre accessibilité.

L’accessibilité — numérique — repose sur un certain nombre de règles de conception destinées à rendre un produit ou service utilisable pour tout le monde, y compris pour les personnes vivant avec une déficience.

Ces règles sont mises à disposition par différentes organisations. L’OPQUAST en dresse une liste non-exhaustive à travers une checklist ludique sous forme de cartes à jouer.

Si ces sujets sont et ont toujours été au cœur des préoccupations d’AB Tasty, la mise en place d’un Color Tokens System a été l’occasion d’assurer des associations de couleur assez contrastées pour être lisibles.

Éviter les associations de couleurs illisibles

Vous vous souvenez de ce bel exemple d’associations de styles ? ↓

Exemples de boutons créés grâce à une palette de style. Cet exemple met en avant les multiples façon de lier ces couleurs, de façon accessible, ou non.

Alors ça y est, vous commencez à voir où je veux en venir…

Si vous pensiez qu’il est du rôle du Designer de savoir parfaitement quelles associations de couleurs sont accessibles, et que jamais au grand jamais un designer n’irait mettre un texte blanc sur un fond jaune, et biiien…

Croyez-le ou non, mais on l’a fait !

Capture d’écran du plugin Stark, montrant un contraste insuffisant sur un de nos anciens boutons de texte blanc sur fond jaune

Ça c’est notre ancien bouton “Pause”. Comme vous pouvez le voir, son contraste est insuffisant. Et en même temps, pourquoi pas ? Rien ne nous indiquait au moment de la création de ce composant que c’était interdit.

Prévenir quand on ne peut pas guérir

La mise en place de notre Color Tokens System nous a permis non seulement d’homogénéiser notre interface, mais aussi (et surtout ?) de vérifier l’accessibilité visuelle de chaque cas d’usage pour ne proposer que des associations respectant la WCAG (Web Content Accessibility Guidelines) de la WAI (Web Accessibility Initiative).

Nous avons passé en revue les contrastes entre couleurs de texte et surfaces, en nous basant sur les résultats du Plugin Figma Stark pour proposer les meilleures palettes à notre équipe.

Et, il faut le dire, nous ne sommes pas peu fiers du résultat 👀

Avant après de notre UI, sous forme de vues en différentes déficiences visuelles
Composant du Reporting avant/après, vu en Achoromatopio & Tritanomaly

Un chiffre, une conclusion.

Selon l’Organisation Mondiale de la Santé (OMS), environ 2,2 milliards de personnes dans le monde souffrent d’une forme de déficience visuelle. Parmi elles, beaucoup dépendent de la conformité aux standards d’accessibilité pour utiliser les interfaces numériques efficacement. Ignorer ces considérations, c’est potentiellement exclure une partie significative de nos utilisateurs.

La mise en place de notre Color Tokens System ne se limite pas à une simple refonte esthétique de l’interface utilisateur. Elle joue un rôle crucial dans l’amélioration de l’accessibilité visuelle de notre plateforme.

Allez, bonne chance !

--

--

Lea Seibel

Je suis Léa Seibel, Product Designer chez AB Tasty. Je me spécialise depuis plusieurs années en Design System et Token System.