Style guide : intérêt et limites
Le concept principal des derniers framework front à la mode (React, Angular) est celui de composant. Une application est découpée en une multitude de composants, comme par exemple le menu, le fil d’Ariane, l’écran de loading, le bouton de validation avec loader intégré, la liste des utilisateurs… Pour Angular par exemple, le comportement de chaque composant est défini par un fichier Typescript, son apparence par un fichier SCSS/CSS et son contenu par un fichier HTML.
Un composant peut être inséré n’importe où dans l’application et son comportement et apparence se basent sur des données en entrée (Input) et l’état de l’application au moment de leur utilisation.
Des tests unitaires permettent de tester toutes les combinaisons réalistes d’entrée et de vérifier le fonctionnement interne, mais on est assez vite amené à vérifier également les différentes variantes du design du composant. Il devient alors intéressant de considérer la création d’un style guide contenant les principaux éléments de design de votre application. Par exemple si votre application contient un composant “timeline” (cf ci-dessous) vous pouvez tester des timelines de différentes longueurs, avec les différents statuts d’étapes possibles. Vous pourriez également aller plus loin en utilisant des longueurs de titres différentes pour tester les limites de l’application.
Une galerie de code source
Pour le développeur qui souhaite utiliser un composant existant, le style guide peut devenir une source intéressante pour comprendre le fonctionnement du composant et y récupérer le code source de configuration. Le style guide devient alors une sorte de guide d’implémentation.
Un bac à sable pour les développeurs
Lors du développement d’un nouveau composant, le style guide apparaît comme le bon endroit pour en implémenter une première version. Libéré de toute contrainte extérieure, le développeur peut concevoir librement sans se soucier de l’état de l’application et sans avoir à réaliser des scénarios complexes pour arriver dans une situation particulière. Une fois tous les états possibles testés et intégrés au style guide, le développeur peut s’atteler à son intégration au coeur de l’application.
Une base de discussion PO-PO et PO-dev
Rappel : un PO est un Product Owner en méthode agile
Lors de la conception d’une user story ou la discussion de sa réalisation, le style guide fournit une bonne base pour s’assurer que tout le monde parle de la même chose. Le bouton doit-il être dans tel ou tel état ? Le style guide donne un contexte non-ambigu. Il fournit également au PO un ensemble de composants de base (et leurs états) dans lesquels il peut piocher facilement sans surcoût de développement. Tout composant absent du style guide doit ainsi faire l’objet d’une demande de développement.
Des tests de non-regression facilités
Un des avantages indéniables du style guide est la possibilité d’y constater des régressions de design. Certains composants ne sont utilisés qu’à des endroits bien précis et parfois difficile à atteindre en terme de scénario. Le style guide permet de détecter plus rapidement les régressions, soit de manière opportuniste, “en passant”, soit via des tests de non-régression. Un composant proposant par exemple de l’auto-complete sera plus facile à tester avec des tests end-to-end directement dans un environnement contraint comme le style guide qu’au coeur de l’application.
Style guide ≠ charte graphique
Les définitions de charte graphique varient d’un développeur et designer à l’autre, on considérera ici que la charte graphique est le document décrivant les règles de design comme la palette de couleurs, les polices, les tailles, les ombres… La charte graphique reste la référence et le style guide en est son implémentation. Le designer pourra ajuster sa charte en fonction de son ressenti, une fois l’implémentation faite dans le style guide.
Un style guide intermédiaire dans Sketch
Si votre équipe design travaille avec Sketch, elle peut tout à fait créer des galleries de symboles dans Sketch, ce qui revient à faire une version intermédiaire du style guide. Ainsi les product owners qui utilisent Sketch peuvent piocher dans les éléments pour créer leurs maquettes. Le style guide “technique” reste selon moi important pour les raisons citées précédemment.
Recette des stories en deux étapes
Lors de la réalisation d’un nouveau composant, l’ajout de celui-ci dans le style guide peut constituer une première étape dans le processus de recette du product owner. Il pourra ainsi valider le comportement et l’aspect général du composant pour ensuite valider son implémentation dans l’application dans un second temps.
Encore un référentiel à maintenir
Il est vrai que le style guide a ce désavantage d’être un nouveau référentiel à maintenir. Dès lors qu’un ou deux composants sont oubliés et n’y sont pas présents, le risque est que l’équipe l’abandonne tout simplement, sachant qu’il n’est pas à jour.
A vos risques et périls
Vous passer de style guide ou de charte en général se fait à vos risques et périls. Il a déjà été vu chez des clients travaillant avec des nombreux développeurs des dérives qui rendent le code difficilement maintenable, avec des boutons tous différents tant en terme de design que de libellés par exemple… Au final, c’est l’expérience utilisateur qui trinque.
Quelques exemples d’éléments d’un style guide
Et vous, utilisez-vous un style guide ? Quels avantages et inconvénients y voyez-vous ?
