bureau

Variations de couleurs

Dans un design system, la palette de couleur est un élément fondamental qui impacte le reste des composants. Trois qualités sont importantes pour qu'elle offre toute son utilité : stabilité, densité et versatilité. La stabilité et la densité offrent un gain de temps et une efficacité sémantique lors de la fabrication des écrans. Elles clarifient la communication entre les collègues et donnent plus d'autonomie aux développeurs. La versatilité permet de s'adapter rapidement à des besoins ou des contextes qui n'avaient pas été identifiés au départ du projet.

Définir cette palette représente un engagement non négligeable pour qu'elle soit stable dans le temps. Il faut se décider en amont du projet sur une liste de références qui suffiront à tout construire dans les mois à venir, et qui seront utilisées par toute une équipe. La tâche peut être intimidante. Deux choix essentiels sont à faire : celui des teintes, et celui des variantes. Le problème des teintes est très lié au contexte du projet, tant du point de vue de l'identité graphique que de la complexité fonctionnelle du produit à concevoir. Cet article n'en parlera pas, et se focalisera sur la production des variantes.

Combien en faut-il ? Comment s'assurer que leur répartition du clair au sombre soit pertinente pour apporter du sens aux interfaces à venir ? Je me suis posé ces questions au cours de trois projets d'échelle importante ces dernières années. Après éprouvé une méthode de choix de variantes ces trois dernières années, il me semblait qu'elle était prête à être partagée ici pour qu'elle puisse être utile à d'autres, et j'espère améliorée par vos suggestions.

Avant de la présenter, parlons rapidement de la première solution qui viendra tout naturellement en tête des développeurs avec qui vous travaillez : automatiser la production de variantes de couleurs à partir d'une référence initiale en suivant une formule mathématique. Une formule de math c'est objectif, stable, automatisable - rassurant. Est ce que ça permet de composer une palette sans y passer trop de temps ? Absolument. Est ce que le résultat obtenu apportera assez d'expressivité et de subtilité aux interfaces à venir ? Certainement pas. Les couleurs sont un phénomène essentiellement physiologique qui ne repose pas sur des règles mathématiques simples. Augmenter la saturation et/ou la luminosité de 10 points pour une teinte A n'a pas la même conséquence visuelle que pour une teinte B. Dans l'exemple ci-dessous, j'ai fait varier la saturation de quatre teintes en préservant la même luminosité. Les valeurs de contrastes calculées montrent bien qu'à saturation équivalente la présence visuelle n'est pas du tout la même d'une teinte à l'autre.

Il n'est donc pas possible de se fier à des interpolations linéaires pour produire des variantes utilisables efficacement au sein d'un design system.

Face à ce constat, l'équipe design de Lyft a proposé en 2018 une approche plus fine avec colorbox.io. Cet outil permet entre autre d'appliquer une formule distincte pour chaque critère définissant une couleur à l'écran (teinte, saturation et luminosité). Quelques fonctions mathématiques sont disponibles pour décrire leur variation : linéaire, sinusoïdale, cubique, quartique ou quadratique. D'un point de vue cartésien, tout va bien, on reste dans une description objective de la couleur.

Mais si j'en crois mon expérience, le nombre de designers sachant décrire les fonctions cubiques ou quadratiques est plutôt réduit - je n'en fais certainement pas partie. Comme il est compliqué voire impossible d'anticiper le résultat de telle ou telle formule sur le rendu des variantes, on utilise cet outil au petit bonheur la chance, et c'est un peu comme lancer des spaghettis sur un mur en attendant que l'un d'eux veuille bien y rester collé. La boucle de feedback entre l'intention, l'outil et le résultat n'existe pas. En revanche, la représentation des échantillons en tranches successives et contigües était intéressante, et m'a mis sur la piste de la méthode que j'ai retenu depuis.

Elle repose sur trois ingrédients : une représentation concentrique des échantillons, les curseurs HSL de votre éditeur graphique, et votre propre perception visuelle.

Le format concentrique offre une meilleure perception visuelle de la progression des échantillons qu'avec les rectangles superposés. Aucun souvenir précis de pourquoi cette mise en forme m'est venue en tête, mais je soupçonne que mon travail sur l'icône de l'application iOS Le Baby (que vous devriez vraiment recommander à tous les parents de nourrissons que vous connaissez) y soit pour quelque chose.

Faire cet exercice donne la sensation de modeler la progression et permet de faire exister le lien entre l'intention et le résultat. L'image mentale que je me suis faite pour m'aider est celle de disques concentriques plus ou moins épais empilés les uns sur les autres, vus par dessus. Le plus petit étant le plus proche de la source de lumière (donc le plus clair), et le plus grand le plus éloigné (donc le plus foncé).

On peut construire une progression linéaire (A), ou décider de de concentrer les variantes dans les tons clairs (B), ou dans les tons foncés (C).

En augmentant le nombre de variantes, il est possible d'affiner le profil de ce volume fictif, et d'assurer un choix de références dans les zones du spectre qui seront pertinentes pour le projet. Par exemple, on peut produire peu de variantes claires qui serviront à des couleurs de fond, et se concentrer sur les valeurs sombres pour avoir plus de nuances assignables aux textes (D). On peut aussi décider d'avoir des écarts très subtils dans les valeurs claires, puis quelques variantes moyennes saturées pour les éléments interactifs, suivies d'autres variantes sombres pour les textes (E), sans que ces trois groupes ne soient reliés entre eux par une progression linéaire.

Les graphes de progression des valeurs de teinte/saturation/luminosité ne sont là que pour montrer qu'il serait bien compliqué de les traduire en équations mathématiques pour atteindre le résultat obtenu à l'œil et à la main.

Sur la question du nombre de valeurs à produire, il n'est vraiment pas gênant d'en produire un peu plus que nécessaire. La dernière palette que j'ai produite comportait entre 10 et 12 variantes pour chaque teinte principale utilisée, mais le gros de l'usage s'est fait sur 4 ou 5 variantes pour chacune de ces teintes. Ce nombre important avait un peu inquiété mes collègues développeurs au départ, mais 3 ans et 6 produits plus tard, l'expérience montre que ça n'a jamais été un problème pour eux. Bien-sûr, le nombre de variantes à produire dépend des usages de ces couleurs. C'est confortable d'avoir un large choix dans les gris qui seront utilisés pour le texte, mais les couleurs d'erreur, d'alerte ou de confirmation peuvent se contenter de trois variantes.

C'est une méthode obtenue de façon très empirique, mais elle m'a rendu un bon service jusqu'à maintenant. Je vous encourage vraiment à en faire l'expérience vous-même avec ce fichier SVG, et modeler votre propre variation de teinte. Vos commentaires et suggestions sont bien entendu les bienvenus, ils pourraient permettre de l'améliorer encore.