In a system design, the color palette is a fundamental element that impacts all other components. Three qualities are important for it to be useful: stability, density and versatility. Stability and density offer time savings and semantic efficiency in the production of screens. They clarify communication between colleagues and give more autonomy to developers. Versatility allows for rapid adaptation to needs or contexts that were not identified at the start of the project.
Specifying this palette represents a significant commitment as it needs to be stable over time. You have to decide early on in the project on a list of references that will be enough to build everything in the months to come, and that will be used by an entire team. This can be a daunting task. Two essential choices have to be made: the choice of tints, and the choice of variants. The problem of tints is very much linked to the context of the project: its graphic identity, and the functional complexity of the product to be designed. This article will focus on the production of variants.
How many do you need? How can we make sure that their distribution in the light to dark spectrum will allow to provide meaning to the future interfaces? I asked myself these questions during three large-scale projects in the last few years. After testing a method for choosing variants over the past three years, I felt it was ready to be shared here so that it could be useful to others, and I hope improved by your suggestions.
Before presenting it, let's cover quickly the first solution that will naturally come to mind for the developers you work with: automating the production of color variants from a given reference by applying a mathematical formula. A formula is objective, stable, and can be automated - reassuring. Does it allow you to compose a palette without spending too much time on it? Absolutely. Will the result obtained bring enough expressiveness and subtlety to future interfaces? Certainly not. Colors are an essentially physiological phenomenon that does not rely on simple mathematical rules. Increasing the saturation and/or luminosity by 10 points for hue A does not have the same visual consequence as for hue B. In the example below, I varied the saturation of four hues while preserving the same brightness. The calculated contrast values show that at equivalent saturation the visual presence is not at all the same from one hue to another.
It is therefore not possible to rely on linear interpolations to produce variants that can be effectively used within a design system.
Faced with this observation, Lyft's design team proposed a more refined approach in 2018 with colorbox.io. Among other things, this tool allows you to apply a separate formula for each screen color attribute (hue, saturation and brightness). A selection of mathematical functions are available to describe their evolution: linear, sinusoidal, cubic, quartic or quadratic. From a cartesian point of view, everything is fine, we're describing color objectively.
The 2018 colorbox interface
But from my experience, the number of designers who know how to describe cubic or quadratic functions is rather small - I am certainly not one of them. Since it is complicated, if not impossible, to anticipate the result of a formula on the rendering of the variants, this tool is used in a random way, and it is a bit like throwing spaghettis on the wall and waiting for one of them to finally stick. The feedback loop between the intent, the tool and the result does not exist. On the other hand, the representation of the samples in successive and contiguous slices was interesting, and put me on the track of the method I have retained since.
It relies on three ingredients: a concentric representation of the variants, the HSB sliders of your graphic editor, and your own visual perception.
The concentric format offers a better visual perception of the variants progression than with the stacked rectangles. No clear memory of why this layout came to mind, but I suspect my work on Le Baby iOS app icon (which you should really recommend to every parent of newborn you know) had something to do with it.
Doing this exercise gives the feeling of shaping the progression and allows the link between intention and result to exist. The mental image I used to help me is that of concentric discs of varying thickness stacked on top of each other, seen from above. The smallest one being the closest to a zenith light source (therefore the lightest), and the largest the farthest away (therefore the darkest).
We can build a linear progression (A), or decide to group the variants in light tones (B), or in dark tones (C).
By increasing the number of variants, it is possible to refine the profile of this fictitious volume, and to ensure a choice of references in the areas of the spectrum that will be relevant to the project. For example, one can produce few light variants that will be used for backgrounds, and produce more dark values for text elements (D). One can also decide to have very subtle variations in the light values for backgrounds, then a few saturated mid-range variants for interactive elements, followed by other dark variants for text (E), without these three groups being linked together by a linear progression.
The graphs showing the progression of hue/saturation/brightness values are only there to show that it would be very complicated to translate them into mathematical equations in order to achieve the result obtained by eye and by hand.
On the question of how many values to produce, it really doesn't matter if you produce a few more than you need. The last palette I produced had between 10 and 12 variants for each of the main tints, but the bulk of the usage was on 4 or 5 variants for each of these tints. This large number had my fellow developers a little worried at first, but 3 years and 6 products later, experience shows that it was never a problem for them. Of course, the number of variants to produce depends on the uses of these colors. It's comfortable to have a wide choice of grays that will be used for text, but error, alert or confirmation colors can be satisfied with three variants.
It is a very empirical method, but it has served me well so far. I encourage you to download this SVG sample file and tweak it to shape variations of your own. Your comments and suggestions are of course welcome, as they could make it better.
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.
La version 2018 de colorbox
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.
