Implémenter un design system dans une application existante
Captain Contrat est une application aux nombreuses facettes : avec des interfaces pour les dirigeants d’entreprise, les avocats, les juristes internes et de nombreux types d’offres (allant de la marketplace à l’abonnement). Jusqu’ici, nous avions surtout avancé sur la partie fonctionnelle sans nous soucier de la cohérence de design. Chaque nouvelle page ajoutait une nouvelle couleur pour deux utilisées, les espacements entre les composants étaient désordonnés et les icônes étaient visuellement incohérentes entre celles qui venaient de font-awesome et les nôtres.
Avec la croissance de l’entreprise, la volonté d’avoir quelque chose de plus cohérent s’est renforcée. L’équipe design a décidé de mettre en place un design system pour unifier l’aspect de l’application, nous avons précédemment expliqué pourquoi cette décision a été prise et comment ce design system a été conçu. Nous allons ici nous concentrer sur l’implémentation de ce design system, en expliquant comment nous avons procédé pour le mettre en place de façon progressive, en essayant de ralentir le moins possible le reste des travaux.
Le design system
Nos designers l’ont expliqué mieux que moi dans leur article dédié, mais pour résumer, en terme d’éléments à implémenter, ils ont défini :
- une liste officielle des couleurs, avec leurs cas d’usages
- une police officielle, avec sa taille recommandée
- des tailles et couleurs par défaut pour les titres et les paragraphes
- une librairie d’icônes
- des tailles, couleurs et formes standardisées pour nos formulaires
- de nombreux composants comme les boutons, modales et autre champs de texte à appliquer aux différents espaces de notre application
L’implémentation de tous ces éléments est chronophage et nous ne souhaitions pas ralentir tous les développements.
Afin d’avoir un plan de migration solide, nous avons pris un peu de recul et analysé les différents éléments de ce design system. On peut différencier des éléments qui vont se retrouver sur la quasi totalité des pages, et ceux qui vont être plus épars dans l’application. Pour nous, il s’agit presque de la différence entre variables et composants.
Les variables
Toute règle qui traite de couleur, taille et famille de police est omniprésente dans l’application. Nous nommons ces éléments des variables étant donné que dans notre code, nous stockons ceci dans des variables scss (qui pour l’instant sont désordonnées et sans grande cohérence entre elles, mais ont le mérite d’exister). Pour ces variables, un changement progressif est assez illusoire et compliquerait vraiment notre code. Nous avons donc réalisé un fichier de correspondance entre les anciennes variables et celles du design system avec l’aide de l’équipe design, puis refactoré le code pour ne plus utiliser que les nouvelles variables (réunies dans un seul fichier). Quelques jours en staging nous ont permis de détecter les éventuels ratés (du doré sur fond doré à un endroit, une taille trop grosse à un autre…) mais dans l’ensemble le travail préparatif n’avait pas trop de trous dans la raquette. Une mise en production nous as permis de passer de 5 variations de notre couleur principale à une seule, apportant déjà un semblant d’homogénéité à l’application.
Les composants
Le reste des éléments du design system sont ce qu’on peut nommer des composants : des briques unitaires représentant des éléments réutilisables dans notre application. Ils sont beaucoup trop nombreux pour qu’on s’y attaque d’un coup, donc nous avons décidé d’appliquer une règle proche du boy scout sous stéroïdes.
Dans chaque user story qui traite un peu du front, nous avons un design associé, et dans ce design on retrouve évidemment des composants du design system. La règle est simplement qu’au moment où on implémente ce design, on en profite pour faire un composant réutilisable (si ce n’est pas déjà fait) et on essaie de remplacer toutes les anciennes versions de ce composant par la nouvelle. Les premières user stories qui utilisent des composants très fréquents (barre de navigation, boutons, modales) sont évidemment plus coûteuses, mais c’est rapidement amorti quand on a juste à appeler un composant ou ajouter une classe pour avoir directement le bon design. Comme l’a dit notre équipier le moins enthousiasmé par le front-end :
C’est cool, j’ai plus besoin d’écrire du css, j’ajoute juste une classe et c’est ok pour les designers.
Gérer plusieurs applications
Captain Contrat possède deux applications (une pour le front de notre espace client, une pour le reste comprenant notamment le funnel d’achat), donc nous devons implémenter nos changements sur deux applications différentes. Des questions émergent :
- Que faire quand un composant est ajouté dans une application mais pas dans l’autre ?
- Que faire quand le design system a changé un peu et qu’on intègre ce changement ?
Si un composant est ajouté dans une application, notre approche progressive nous encourage à ne pas l’intégrer dans l’autre application tant qu’on n’en a pas besoin. En revanche, le fait d’implémenter des composants à des moments différents par des personnes différentes peut mener à du code assez différent, ce qui peut provoquer des mauvaises surprises. En effet si le composant modale s’appelle captain-modal sur une application et modal sur l’autre, nous n’allons pas nous en sortir. Pour résoudre ce problème, nous utilisons tout simplement la documentation du design-system fournie par les designers qui, en plus de détailler le css des différents composants, comporte nos propres contributions détaillant quelles applications implémentent le composant et quels sont les noms à utiliser.
Quand un élément du design-système change, on veut rester cohérent, il faut donc apporter les changements dans les deux applications en même temps. C’est obligatoire pour tous les éléments que nous qualifions de variables, nous avons en effet eu à changer des icônes à une occasion. Pour des composants, nous n’avons pas encore eu à le faire et il serait plus sûr de tout changer, mais des contraintes business fortes face à un petit changement nous feront potentiellement prendre le choix de mettre en production un premier changement et de faire attendre la seconde application.
Conclusion
Pour implémenter le design system de façon progressive, nous l’avons divisé entre les parties vitales, à implémenter au plus vite et ce qui pouvait être fait au fur et à mesure. En acceptant de ne pas être dans un état parfait dès le début et avec quelques jours de tests pour repérer les incohérences majeures, nous avons pu nous lancer très vite. Une fois ce lancement fait, il s’agit surtout de bien distinguer les User Stories où il y aura besoin d’implémenter des morceaux du design system de celles où au contraire, beaucoup d’éléments seront réutilisables.
Cette approche nous a assez bien réussi, le site est vite devenu plus cohérent grâce à l’unification des couleurs et polices et une identité visuelle se constitue petit à petit, sans trop gêner le développement de nouvelles fonctionnalités. De plus, délivrer quelque chose qui apporte de la valeur au client tout en augmentant notre productivité a permis de faire adhérer le reste de l’entreprise à ce design system.
