Débuter un design system : le composant “ambassadeur” 1/2
Vous vous lancez dans la création et donc l’implémentation d’un design system. Cet objectif est un parcours semé d’embûches et comme beaucoup de projets, on ne sait pas trop par quoi commencer. Quand je parle de “quoi”, pour un design system, on ne parle pas de fonctionnalité purement “métier” mais de composant. Une des manières de choisir comment débuter est d’inventorier les composants de son produit puis de les prioriser. Je vous expliquais comment on pouvait faire dans cet article.
Petit rappel, quand on parle design system on ne parle pas d’un UI kit sur Sketch, Figma et consort, mais bien de composants développés et fonctionnels.
Maintenant, on peut commencer. Suite à votre inventaire et priorisation, vous avez identifié le fameux premier composant à déployer. J’ai décidé de le nommer “composant ambassadeur”. Pourquoi ambassadeur ? En tant que premier composant il est le représentant du design system. C’est sur lui, notamment que va reposer la démonstration de la méthodologie auprès de l’équipe entre autres. D’où l’importance de soigner son arrivée.
Créer le composant
Cette méthodologie est bien sûr valable pour tous les composants.
Partons du postulat que votre composant “ambassadeur” est le bouton principal. En tant que designer, vous l’avez imaginé et conçu au sein de votre outil préféré. Il a une forme, une couleur (en respectant les contrastes RGAA), une typographie, vous avez peut-être même réfléchi aux différents états ! Vous avez du coup un élément d’UI kit. C’est très pratique pour vous, pour maquetter notamment, faire des tests utilisateurs, mais tel quel, il n’est pas encore au niveau composant d’un design system.
Que lui manque-t-il ? C’est simple. De la documentation. Vous devez commencer à documenter votre bouton. Dans quel cadre l’utilise-t-on (à quoi sert-il dans d’autres mots) ? Mais aussi quand ne doit-on pas l’utiliser ? Les fameux “do/don’t”. Quelles sont les règles en termes de wording ? J’aurais tendance à favoriser à ce niveau, d’écrire une documentation plus fonctionnelle que technique. Bien sûr, rien n’est gravé dans le marbre. Vous pouvez l’écrire dans un outil spécialisé comme Zeroheight ou Specify. Le plus important dans le choix de votre outil de documentation reste qu’il réponde à vos besoins. Par exemple, pour ma première documentation de composant je l’ai faite en markdown sur le wiki du projet !
Maintenant que vous avez une idée de ce à quoi il va ressembler et de son fonctionnement, vous pouvez le présenter à l’équipe de développement. L’idée est de challenger ce que vous avez établi puis de développer une première version de votre composant. Et ce en direct et ensemble. C’est là que vous allez pouvoir affiner l’aspect technique/esthétique : les différents padding, la largeur minimale de votre bouton, le choix typographique… Et surtout, la gestion des états et les micros interactions !
Ce que vous allez également faire, c’est vous accorder sur le nom qu’il aura afin d’avoir un langage commun. Il est préférable de privilégier un nom qui a un sens fonctionnel et non métier, cela facilitera la réutilisabilité et rendra votre bibliothèque, UI Kit et le code plus lisible. Il est également recommandé d’utiliser des balises HTML qui ont un sens sémantique, ici le <button>. L’accessibilité vous remerciera !
Vous pouvez dès à présent ajuster votre UI kit et compléter la documentation technique de votre composant !
🎉 Félicitations ! Le premier composant a été créé. Il ne reste plus qu’à le déployer”. Cette petite grande étape, j’en parlerai dans un second article 😀
Petite note : la démarche que je vous propose découle d’expériences vécues et de discussions avec des développeurs et des designers. Je serai ravie d’avoir vos retours d’expérience.
