Mise en place du Design System chez Agicap — part.2
Lors d’un précédent article, Luc vous avait parlé de son arrivée chez Agicap et de la mise en place du Design System. Et bien aujourd’hui c’est à moi de vous parler de mon arrivée chez Agicap et plus particulièrement de ce que nous avons mis en place afin d’améliorer notre Design System.
Limites de l’organisation actuelle
Lorsque vous êtes la seule personne à travailler sur un Design System, vous ne rencontrez pas les mêmes problématiques que lorsque vous êtes 2 ou plus. Au fur et à mesure que l’équipe grandit il faut s’adapter, se structurer etc.
Certains composants pas assez génériques
Très vite, nous nous sommes rendu compte que certains composants n’étaient utilisés que sur une page de notre application, ou alors qu’ils ne pouvaient pas être déclinés pour un usage légèrement différent.
Documentation sur Notion
La documentation du Design System se trouvait sur Notion qui est un outil très pratique pour faire tout un tas de chose mais qui a rapidement montré ses limites : navigation peu pratique, lenteur pour charger les différents frames de Figma etc.
Difficile de suivre ce qui a été implémenté côté dev
Certaines parties de notre application utilisaient le Design System, d’autres utilisaient du code spécifique. Il arrivait donc d’avoir un composant qui respectait le Design System sur une page, et un composant qui ne le respectait pas sur une autre.
Pas vraiment de process entre Design et Front
Tout comme l’équipe design, l’équipe front commençait à grandir mais nous n’avions pas de process clair sur l’implémentation ou la mise à jour de composants du Design System.
Rendre les composants le plus générique possible
Sur certains composants comme les modales, il était compliqué de créer un composant générique réutilisable à travers nos différents projets. Du coup, on se retrouvait avec un composant très basique contenant un header, un content et un footer. A chaque fois que nous avions besoin d’utiliser ce composant, il fallait créer un composant spécifique pour gérer le contenu. Nous avons résolu ce problème à l’aide des variants et des slots.
Variant
Les variants de Figma, permettent de gagner beaucoup de temps mais demandent un peu d’investissement au début.
Comme vous le disait Luc dans son article, chez Agicap nous créons toujours un composant parent, que l’on préfixe par .main dans notre Design System.
Le fait de préfixer le nom d’un composant par un “.” l’empêche d’être publié dans votre librairie. Comme ça vous pouvez “appeler” ce composant dans votre Design System pour l’utiliser dans vos variants par exemple, mais il ne sera pas directement accessible dans vos autres fichiers.
Voilà à quoi ressemble notre composant Button à l'heure actuelle, vous pouvez facilement choisir
- Son type : Primary, Secondary, Link etc.
- Sa taille Small, Regular, Large
- L’affichage d’icônes ou de texte
- Et son état : Default, Active, Hover, Focus, Disabled et Loading
Slots
Depuis la mise en place du Design System, nous avons pris l’habitude de séparer les composants plus complexes en plusieurs parties, c’est le cas notamment des Modals qui sont composées de :
- Header : le titre
- Body : le contenu
- Footer : les actions
Il y a quelques mois, Figma a publié une video sur la méthode des slots. Cette méthode est finalement très proche de ce que l’on faisait déjà avec les sections dont je vous parle ci-dessus mais plus générique et surtout plus flexible.
Nous avons donc décidé de tester le système de slots et aujourd’hui il est utilisé sur les Dropdowns, Modals et Side Panel.
Voilà à quoi ressemble la structure d’une Modal :
Nous avons gardé les 3 sections mais au sein du Body nous avons ajouté des Slots. Ces Slots peuvent être remplacés par un des Slot existant mais aussi par tout autre composant.
Voici un petit exemple, en quelques clics on peut construire une Modal avec un formulaire :
Avantages :
- Très grande flexibilité
- Gain de temps pour la création de composants plus spécifiques
Inconvénients :
- Il faut faire attention avec la flexibilité car ça peut apporter de l’inconsistance et c’est ce que l’on essaie d’éviter au maximum avec le DS.
- Il n’est pas possible de ré-ordonner les slots à l’intérieur d’un composant. Si on reprend l’exemple du dessus et que vous voulez que Catégorie se retrouve au dessus de montant, il va falloir remplacer les slots.
- Attention à ne pas ajouter trop de slots, même s’ils sont cachés ils prennent de la mémoire. Dans de très gros projets ça peut poser un problème de performances voir complètement planter Figma.
La migration de Notion vers ZeroHeight
Notion a rapidement montré ses limites. Bien que ce soit pratique de pouvoir “embed” des frames de Figma, les performances ne sont pas toujours au rendez-vous. Dès que vous commencez à afficher plusieurs “embed” sur une même page, ça peut devenir inutilisable sur des plus petites configurations/connexions.
Nous avons donc fait un petit tour des outils dédiés aux Design System et lorsque nous avons essayé ZeroHeight nous étions rapidement convaincus notamment grâce :
- Au fait de pouvoir importer tout le contenu depuis Figma de façon asynchrone : si l’on effectue des modifications sur le DS, elles ne seront répercutées dans ZeroHeight sans action de notre part
- Les performances
- Les options de mises en forme : possibilité d’extraire automatiquement les tailles de police, les couleurs etc.
Le seul regret que l’on a, c’est d’avoir perdu la gestion des commentaires que nous avions sur Notion. Pour palier à ce problème, nous avons créé un canal Slack dédié au Design System dans lequel chaque membre de l’équipe Front et Design peuvent communiquer.
Le passage à Storybook
La migration du contenu de Notion vers ZeroHeight a été assez rapide, le plus long a été d’homogénéiser la documentation. Chaque composant a sa page, divisée en 3 onglets :
- Usage
- Design
- Code
Usage
Sur cette page, nous affichons une vue d’ensemble du composant, comment il est structuré, à quoi il sert, quand l’utiliser.
Design
Dans la partie Design nous affichons le composant dans tous ses états, par exemple pour un bouton Primary nous avons :
- Default
- Hover
- Focus
- Disabled
- Active
Code
Et enfin dans la partie Code nous affichons un embed de Storybook afin de pouvoir interagir avec le composant.
Mise en place d’un process entre les équipes Design et Front
La base est maintenant posée mais il faut documenter comment on alimente le Design System, quand est-ce qu’il faut documenter, comment on prévient les développeurs de nouveaux composants, comment on les prévient lorsque l’on modifie un composant existant.
Pas d’équipe dédiée au DS, tout le monde est owner etc.
Jusqu’à aujourd’hui, chaque membre de l’équipe Design peut modifier le Design System. Nous souhaitons garder cette flexibilité tant que ça fonctionne car ça nous permet d’être plus rapide et plus autonome.
Création côté design
Quand ajoute t-on un composant au DS ?
L’ajout d’un nouveau composant se fait à partir du moment où l’on a besoin de réutiliser un composant sur plusieurs projets. Lorsqu’un membre de la team Design en ressent le besoin, il peut créer le composant et nous notifier sur Slack, nous en parler lors d’une Design Critique ou encore au cours d’un pairing.
Je ne vais pas revenir sur la façon dont on crée les composants, une partie a été couverte plus haut et vous pouvez lire (ou relire) l’article de Luc à ce sujet.
Lorsque l’on ajoute ou modifie un composant, on s’assure de mettre à jour la documentation sur ZeroHeight.
Collaboration entre design et front
Voilà un point intéressant sur lequel nous devons encore nous améliorer. Lorsque nous avons mis en place le DS et mis à jour la documentation sur ZeroHeight, nous l’avons communiqué à l’équipe front qui est ensuite repassée sur tous les composants.
A ce moment là ça marchait bien, les mises à jours étaient rapides, et on échangeait souvent. Une fois que la base du DS était intégrée dans l’application, ça s’est un peu compliqué. Dans la team design il arrivait que l’on crée de nouveaux composants où que l’on fasse des modifications sur les existants, que l’on mette à jour la documentation mais nous n’avions pas de process en place pour le suivi de leur implémentation.
Lorsque le composant est créé et documenté, nous publions un message dans le canal Slack dont je vous parlais plus haut afin d’avertir les développeurs.
Et lorsque le composant est intégré de leur côté, dans la librairie Angular et dans Storybook ils reviennent vers nous.
Ensuite nous effectuons une dernière vérification pour s’assurer que le composant respecte nos guidelines.
Nous sommes en train de tester ce process depuis quelques semaines et pour l’instant ça se passe très bien. Si vous avez un process similaire ou totalement différent, n’hésitez pas à nous en faire part dans les commentaires.
This is the end
C’est la fin de cet article mais ce n’est pas la fin de notre Design System, nous allons continuer à le faire évoluer et d’adapter les process au fur et à mesure que les équipes grandissent.
Il reste encore plein de choses à faire, comme documenter le “tone of voice” à adopter qui diffère d’un pays à l’autre (par exemple, en France on vouvoie l’utilisateur, mais en Italie on le tutoie).
Chaque nouveau designer apporte un regard neuf sur l’existant et peut le challenger.
Et après ?
Nous aimerions pouvoir partager notre Design System avec les autres équipes afin de mieux communiquer sur le travail de l’équipe Design et Front. Et puis peut-être aussi le publier sur internet pour que tout le monde puisse y accéder et s’en inspirer.
Avec l’équipe qui grandit il va falloir se poser la question de l’ownership, est-ce que l’on pourra continuer à fonctionner comme ça ? Faudra-t-il créer une équipe dédiée au DS ? Nous n’avons pas la réponse aujourd’hui, mais c’est un sujet que l’on devra surement aborder d’ici quelques mois.
Nous serions très intéressé de savoir comment vous avez géré ces points de votre côté, n’hésitez pas à nous dire comment vous avez procédé en commentaire.
J’espère que cet article pourra vous aider dans la mise en place de votre Design System. Si vous avez la moindre question n’hésitez pas à me contacter sur LinkedIn et je me ferais un plaisir d’y répondre.
