Nommer les composants d'un design system : faciliter les échanges avec un langage commun.

12 Mai 2020

Dans son article, Kat Allen nous partage des bonnes pratiques autour du nommage de composants au sein d’un design system. Un des premiers sujets sur lequel je suis intervenu dans mon travail avec Accor Hôtel fût d’auditer les noms des composants du design system afin d’en dégager une nomenclature claire et transversale aux différents produits.

La communication entre les différents acteurs d’un projet UI est la clé pour un succès sur le long terme, le design-system étant le point central et commun à tout le monde. Design, développement, management, marketing… 👨‍🎨👩‍💻👩‍💼🦸 ‍Nous parlons alors le même langage et nous pouvons nous concentrer sur l'expérience utilisateur en s’assurant de la bonne cohérence du design dans son ensemble.

S’assurer qu’un langage commun est en place est donc primordial. Cela commence par la mise en place d’une nomenclature partagée entre designers, product owners, développeurs… afin de tous utiliser les mêmes noms de composants, de design tokens et de fonctionnalités au jour le jour. La problématique est d’autant plus importante lorsque vous devez maintenir plusieurs produits avec plusieurs équipes différentes. Comme par exemple une équipe web, une équipe iOS et une équipe Android. Les noms des composants natifs ne sont pas à tous les coups identiques entre les différentes plateformes. Un travail d’alignement est donc nécessaire afin d’avancer dans la même direction.

Ce sont exactement ces enjeux auxquels nous avons dû faire face au sein de l’équipe design-system chez Accor Hôtel. Voici quelques bonnes pratiques puisées de nos réflexions, recherches, et lectures. Notamment quelques tips provenant de l’article de Kat Allen dont je vous recommande la lecture (liste de quelques ressources supplémentaires en bas de page) :

• Nommer les composants du point de vue de l’utilisateur, et non par rapport aux aspects techniques ou de présentation du composant
• Définir des noms qui aient du sens pour les membres de vos équipes
• Un nom solide implique d’être précis et mémorable
• Utiliser des noms intuitifs et communiquer le but du composant : les meilleurs noms de composants guident et inspirent dans leur utilisation. Les membres de votre équipe seront alors plus facilement convaincus d’utiliser et de contribuer au système
• Ne pas hésiter à utiliser des métaphores : emprunter le vocabulaire d’autres industries peuvent inspirer des noms solides et mémorables. Cela permet de créer une association, quelque chose à imaginer lorsque vous pensez à ce composant
• Partager la même approche entre les différentes équipes (design/dev…) afin d’assurer de la cohérence
• Nommer de façon collaborative. Impliquer des points de vue et des compétences différentes dans le processus de nommage permet de mieux comprendre le but d’un composant et son utilisation, et donc de lui trouver le meilleur nom

Le travail d’audit de notre système a ensuite été réalisé afin de comparer et ranger les composants de nos différentes plateformes, mais également de confronter cela avec les développeurs et nous rendre compte des disparités existantes. Nos échanges nous ont permis de dégager de grandes règles qui définissent le socle de notre nomenclature :

• Utiliser seulement des lettres en minuscule
• Utiliser la convention kebab-case pour les mots composés (trait-d’union comme séparateur)
• Utiliser des slashes pour la séparation de la structure
• Ne jamais utiliser de nombres et symboles
• Ne jamais décrire les couleurs ou typographies utilisées
• Ne jamais focus le nom du composant sur son rôle business

Ces règles sont à appliquer à l’ensemble de notre système. Les seules disparités entre l’équipe design et les équipes de développement sont les séparateurs. Nous prônons l’utilisation des bonnes pratiques et des conventions de chaque plateforme, qui ne sont pas les mêmes selon le Web, Android ou iOS. L’important réside dans le fait de s’accorder sur les noms des différentes parties de la nomenclature. Peu importe finalement si les mots composés sont séparés de traits d’union, de points, ou autres notations type camelCase. Nous avons donc opté pour le trait d’union côté design, qui correspond à la notation classique en CSS.

Il est important de bien comprendre comment, côté technique, les composants sont développés, afin de trouver une philosophie commune de découpage de notre nomenclature. Nous sommes donc arrivés à cette proposition :

Exemples :

• button/primary/inverse/default
• button/secondary/large -- icon-right/hover/L

Pour expliquer brièvement cette structure :

• element-name : représente le nom du pattern à nommer, button dans nos exemples
• variation : représente les grandes familles du pattern. Un composant dans un état précis ne peut appartenir qu’à une variation à la fois, ou alors est transversal et s’applique à l’ensemble des variations. Dans nos exemples on parle de primary et secondary button
• modifiers : représente ce qui va modifier légèrement le composant, un aspect de taille ou l’ajout d’un petit élément par exemple. Ces modifiers peuvent s'enchaîner en étant séparé de double traits d’union afin de reprendre la convention utilisée côté CSS. Dans notre deuxième exemple on comprend donc que le button est dans son état large et possède un icône à droite du label
• states : représente l’état d’interaction du composant. En terme technique CSS cela correspond aux styles de nos pseudo-class. Côté design nous prenons le parti de toujours ajouter default pour ne laisser aucun doute. Dans notre deuxième exemple on comprend que nous avons à faire au button au survol de la souris
• breakpoint : représente le composant pour une taille d’écran précise. Nous en utilisons trois principaux S, M et L

Nous remarquons toute l’importance de travailler ensemble dès la phase de design afin de défricher certains aspects techniques que nos composants suivront. Cela facilite grandement l’organisation et le découpage des différents cas que nous avons à designer, en plus d’assurer une cohérence sur l’ensemble des produits.

Ressources supplémentaires :

• Naming design system components - Kat Allen
• Design System - Alla Kholmatova
• Best practices for design system naming conventions - Shayna Hodkin