Nommer ses variables sans se piéger
Poser des variables dans Figma prend une heure. Les nommer correctement engage le projet pour des années. Un mauvais nom ne casse rien le premier jour : il se paie plus tard, quand on change une couleur, qu'on ajoute un thème ou qu'un développeur doit deviner ce que le nom voulait dire.
Pourquoi le nom compte plus que la valeur
Une valeur change facilement. On passe un bleu d'une nuance à une autre, et toutes les pages suivent. Un nom, lui, est recopié partout : dans les composants, dans la documentation, dans le code. Le renommer oblige à tout reprendre.
Un bon nom répond à une seule question : quand je dois choisir cette variable, est-ce que je sais tout de suite que c'est la bonne ? Si la réponse demande d'ouvrir la variable pour voir sa valeur, le nom ne fait pas son travail.
Deux façons de nommer : par teinte ou par rôle
Il existe deux grandes familles de noms, et la plupart des erreurs viennent du fait qu'on les mélange sans le décider.
Par teinte. La variable dit ce qu'elle est : bleu, sable, encre, gris clair. C'est lisible, immédiat, et cela correspond à la façon dont on parle des couleurs en réunion.
Par rôle. La variable dit à quoi elle sert : fond, texte principal, texte secondaire, bordure, action, erreur. On ne sait pas quelle couleur se cache derrière, mais on sait où l'utiliser.
Aucune des deux n'est meilleure dans l'absolu. Elles répondent à des besoins différents.
Quand choisir la teinte
Je nomme par teinte quand la palette est courte et que le produit n'a qu'un seul thème. Cinq ou six couleurs, chacune avec un nom clair, suffisent souvent à un site ou à un petit produit.
Dans ce cas, les noms par rôle ajoutent une couche sans rien apporter. Si « fond » vaut toujours « sable » et « texte » toujours « encre », on a deux noms pour une même chose. Tout le monde finit par utiliser l'un ou l'autre au hasard.
Le nommage par teinte a aussi une vertu que j'apprécie : il rend visible le nombre de couleurs. Quand quelqu'un veut en ajouter une, il doit lui trouver un nom, et c'est souvent à ce moment qu'on se rend compte qu'elle n'est pas nécessaire.
Il a une limite nette : il ne survit pas à un changement de thème. Une variable appelée « blanc » qui devient gris foncé en mode sombre ment. À partir de là, il faut passer au rôle.
Quand choisir le rôle
Je nomme par rôle dès qu'une même intention doit prendre plusieurs valeurs :
- un mode clair et un mode sombre ;
- plusieurs marques ou plusieurs clients sur un même produit ;
- un produit assez large pour que les couleurs portent un sens, comme le succès, l'alerte ou l'erreur.
Dans ces cas, le composant ne doit pas savoir de quelle couleur il est. Il sait qu'il affiche un texte principal sur un fond de carte, et c'est le mode qui décide du reste.
Les deux ensemble, sans se perdre
Sur un produit qui grandit, on combine les deux en deux niveaux, et on respecte une règle simple : chaque niveau a son public.
- Le niveau des teintes, qui contient la palette brute : les bleus, les gris, les rouges. Personne ne l'utilise directement dans les maquettes.
- Le niveau des rôles, qui pointe vers les teintes : le texte principal renvoie vers un gris foncé en mode clair, vers un gris très clair en mode sombre. C'est le seul niveau utilisé dans les composants.
Pour que la règle tienne, je masque le niveau des teintes dans Figma, afin qu'il n'apparaisse pas dans le sélecteur de couleurs. Ce qu'on ne voit pas, on ne l'utilise pas par erreur.
Je m'arrête à deux niveaux. Un troisième niveau propre à chaque composant, du type « fond du bouton principal au survol », se justifie pour une bibliothèque partagée par de nombreuses équipes. Pour la plupart des produits, c'est une couche de noms à maintenir pour un bénéfice que personne ne verra.
Les espacements et la typographie
Les couleurs attirent toute l'attention, mais les espacements et les textes posent les mêmes questions.
Pour les espacements, je nomme par échelle, pas par valeur. Un nom comme « espace 16 » paraît clair, mais il devient faux le jour où la valeur passe à 20 en mode ordinateur. Je préfère une suite de tailles, de la plus petite à la plus grande, ou une numérotation par pas. La valeur peut alors changer selon le mode sans que le nom mente.
Pour la typographie, je nomme par usage dans la hiérarchie : titre de page, titre de section, texte courant, légende. Jamais par taille ni par graisse. « Texte 14 gras » ne dit pas quand l'utiliser, et il devient faux dès qu'on ajuste la taille sur mobile.
Dans les deux cas, la règle est la même que pour les couleurs : le nom décrit ce qui ne change pas, la valeur porte ce qui change.
Les pièges que je vois le plus souvent
Mettre la valeur dans le nom. « Bleu 500 », « espace 24 », « texte 16 ». Ces noms sont confortables au départ et faux après la première retouche. Si la valeur est dans le nom, on n'ose plus la changer.
Nommer d'après un écran. « Fond de la page d'accueil », « bordure du formulaire de contact ». Le jour où la même couleur sert ailleurs, soit on la réutilise avec un nom trompeur, soit on crée un doublon.
Nommer d'après une impression. « Bleu joli », « gris doux », « rouge vif ». Ces noms ne permettent pas de choisir entre deux variantes, et chacun les comprend à sa façon.
Mélanger les langues. Une moitié des variables en français, l'autre en anglais, et des abréviations entre les deux. Je choisis une langue au début du projet et je l'écris dans les règles du fichier.
Laisser des synonymes. « Principal », « primaire » et « marque » qui désignent la même couleur. Chaque synonyme est une question que quelqu'un posera plus tard, ou pire, qu'il ne posera pas.
Nommer trop tôt en détail. Créer quarante variables par rôle avant d'avoir dessiné un seul composant. On invente des besoins qui n'existent pas encore. Je commence court et j'ajoute un rôle quand un vrai cas le réclame.
Des noms partagés avec le code
Un nom de variable n'appartient pas au designer. Il sera écrit par un développeur, lu dans une revue de code, cherché dans un moteur de recherche interne. Il doit donc fonctionner dans les deux mondes.
Voici les règles que j'applique pour que ce soit le cas :
- une structure par groupes, du plus général au plus précis : la catégorie, puis le rôle, puis la variante. Figma range les groupes avec une barre oblique, le code les traduit souvent avec un tiret. La structure reste la même ;
- pas d'accents, pas d'espaces, pas de caractères spéciaux dans les noms eux-mêmes, même quand on écrit en français. Ce qui passe dans Figma ne passe pas toujours dans le code ;
- les mêmes mots des deux côtés. Si Figma dit « texte secondaire », le code ne dit pas « texte discret ». Deux vocabulaires finissent toujours par produire deux produits ;
- un choix fait avec les développeurs, pas présenté comme un fait accompli. Ils savent quelles conventions existent déjà dans le code, et ce sont eux qui écriront ces noms tous les jours.
J'ai déjà expliqué pourquoi je fais passer chaque valeur par une variable. Le nommage est ce qui rend ce principe utile : des variables mal nommées créent autant de confusion que des valeurs saisies à la main.
Avant de valider une variable
Je passe chaque nouveau nom par cinq questions :
- Est-ce qu'il dit à quoi sert la variable, ou ce qu'elle est, sans ambiguïté ?
- Est-ce qu'il reste vrai si la valeur change ?
- Est-ce qu'il reste vrai dans tous les modes ?
- Est-ce qu'il existe déjà une variable qui fait la même chose ?
- Est-ce qu'un développeur peut l'écrire tel quel dans le code ?
Si une seule réponse est non, je cherche un autre nom avant d'aller plus loin.
En résumé
Par teinte quand la palette est courte et le thème unique. Par rôle dès qu'une intention doit prendre plusieurs valeurs. Les deux en deux niveaux quand le produit grandit, avec un seul niveau visible dans les maquettes. Et dans tous les cas, des noms qui décrivent ce qui ne change pas, écrits avec les mots du code.
