Le but de ce document est d'aider à organiser plus efficacement la conception d'interfaces visuelles.
L'adoption d'un design system est l'approche recommandée lorsqu'on travaille sur différents projets partageant un style commun propre à la marque/à l'entreprise.
Ce document passera en revue le concept, les outils, les avantages ainsi que les bonnes pratiques d'un système de conception.
Notes
Gardez un esprit critique constructif
Ce document est une synthèse regroupant des dizaines de sources référencées à la fin de chaque section.
Si cela s'avère nécessaire, n'hésitez pas à adapter les recommandations faites dans ce document en fonction des objectifs à atteindre, de la taille des équipes ou des spécificités de l'entreprise.
Qu'est-ce qu'un design system ?
Un design system, ou système de conception, est un référentiel UX/UI regroupant tout le matériel de conception d'interfaces.
D'un point de vue pratique, le design system peut être assimilé à une boite à outilscommuneaccompagnée d'instructions dédiée à la création de produit numérique.
Incohérences, écarts de design, doublons, problèmes de communication, ... sont des problèmes courants rencontrés lorsque plusieurs équipes (UX engineers, UI designers, intégrateurs, développeurs Frontend) collaborent, souvent à des moments différents, sur des projets avec un style commun.
En effet, plus les intervenants sont nombreux, plus il est complexe de centraliser les informations et d'uniformiser les usages.
Le système de conception est donc une méthode d'organisation qui centralise les éléments d'interfaces en 1 source de vérité.
Tous ces éléments sont alors unifiés, documentés et partagés.
Un système de conception n'est pas une solution miracle.
Commençons d'abord par comprendre quand ne pas utiliser un design system.
Si vous travaillez avec une équipe modeste sur une seule application, il vaut mieux utiliser un répertoire de composants d'interface utilisateur au lieu d'un système de conception.
En effet, pour les petits projets, le coût de la maintenance, de l'intégration et de l'outillage dépasse largement les gains de productivité.
Une étape préalable consiste à faire l'inventaire de vos éléments d'interface .
Vous pourrez ensuite décider si vous avez besoin d'un design system en suivant la règle pragmatique suivante:
Si un modèle d'interface utilisateur est utilisé plus de trois fois, transformez-le en un composant d'interface utilisateur réutilisable.
Si un composant d'interface utilisateur est utilisé dans 3 projets/équipes ou plus, placez-le dans votre système de conception.
Concrètement pour les designers, un élément d'interface réutilisable se matérialise par un symbole sur Sketch ou un composant sur Figma.
Les designers peuvent ensuite réutilisé les composants dans différents projets via une master library par exemple.
Concrètement pour les développeurs, un élément d'interface réutilisable se matérialise par un web component (angular, react, vue, stencil, custom web component, ...) partagé.
Les développeurs peuvent ensuite réutilisé les composants dans différents projets via une librairie ou un package npm partagé.
Un système de conception englobe des éléments déjà connu comme l'identité visuelle, le branding, la palette graphique, un style guide, une librairie de composant, ... dans un tout cohérent.
On y retrouve généralement les éléments suivants :
Note : D'autres outils tel que Styleguidist, Vue Styleguidist, Compodoc sont des outils avec une orientation technique et ne sont pas idéal pour la réalisation d'un design system.
Organisation du design system
Certaines décisions tel que l'organisation des sources (symboles sur sketch, code sources, spécifications, ...), la structure à adopter ou encore les conventions de nommage sont à définir par les membres des équipes impliquées.
Documentez ces décisions directement au sein du système de conception.
Voici une liste non exhaustive des pages qui peuvent être utile lors de la création d'un design system :
Page d'introduction
Commencez par une introduction de haut niveau : ce qui est inclus, qui le maintien et comment signaler les problèmes.
Page de démarrage (Getting started)
Cette page peut inclure une explication globale sur les choix de design/techniques, sur la structure et l'organisation, contenir des instructions d'installation, de prise en main, de configuration, ....
Note : Il est possible de créer 2 pages de démarrage distinctes : une page de démarrage pour les designers et autre pour les développeurs.
Page de contribution
Documentez comment contribuer au projet pour standardiser la manière de travailler.
Vous pouvez également détailler les processus d'ajout ou de modifications d'un nouvel élément ou d'un élément existant.
Changelog (journal de modifications)
Cette page capture toutes les mises à jour en un seul endroit.
Cela offre une meilleure visibilité de l'évolution du projet et des différences entre versions.
Pages de l'identité visuelle
Documentez les éléments visuels tels que les couleurs, la typographie, la taille et les icônes, le logo ou encore le branding.
Cette page peut être répartie en plusieurs sous-page selon la structure choisie.
Ces éléments peuvent être associés à des jetons de conception (design tokens) afin d'utiliser un langage commun entre collaborateurs.
Pages layouts
Cette page regroupe les éléments structurant les vues tel que la grille mais également les points de ruptures (breakpoint), la taille et le type de container (fluide, fix, ...).
Pages composants
Lorsqu'on a de nombreux composants, il est recommandé de les regrouper.
Différentes approches sont possibles.
On peut donc les organiser soit par :
ordre hiérarchique (atomic design, ...)
fonctionnalités (forms controls, nav elements, ...)
par statuts (ready to use, deprecated, expiremental, ...)
Chaque page composant devrait idéalement détailler les aspects suivants :
Un système de conception ne doit pas détailler l'implémentation technique ou les règles métier.
D'autres documents (wiki, documents textes, ...) peuvent détailler ces points en dehors du design système.
Page templates
Des modèles de pages peuvent être définis afin de standardiser les rendus à un niveau plus élevé.
Documentation technique des composants: les stories
Une story est ici un état ou un cas d'utilisation d'un composant.
Structure
Chaque composant devrait avoir les stories suivantes :
Une story par défaut (default story)
La default story affiche le composant avec uniquement ses propriétés requises.
Cela crée une représentation visuelle de base pour tout le monde.
Une story intéractive (playground story)
La playground story est utilisée pour aider les intégrateurs et les QA à essayer différentes combinaisons d'attributs du composant et à voir comment le composant réagit en live.
Une story par état et/ou par variant
Les autres stories doivent refléter un état spécifique du composant.
Par exemple, si nous avons un composant bouton qui a une propriété type qui accepte les valeurs primaire, secondaire, tertiaire et une propriété erreur alors nous aurons 4 stories : Bouton/Primaire, Bouton/Secondaire, Bouton/Tertiaire et Bouton/Erreur.
Il y a plusieurs raisons à suivre cette recommandation :
Partager un lien d'un composant avec un état explicite facilite la communication et l'intégration.
Créer des stories explicites évite de supposer les états valides pour un composant.
Combiné avec des outils de test, chaque story devient un test unitaire et aide à détecter les potentielles régressions.
Il est déconseillé d'avoir une story globale regroupant tous les cas d'utilisations en 1 écran.
Pour rappel, une story doit être la plus petite possible pour augmenter sa clarté, sa lisibilité et sa testabilité.
Organisation
Les fichiers stories devraient être colocalisés avec leur composant pour faciliter l'évolution et la cohérence du composant et de sa documentation.
Le fichier story est destiné au développement uniquement et il ne sera pas inclus dans le bundle de production.
Conventions
Nommez les fichiers stories en suivant ce pattern : [ComponentName].stories.[js|ts|jsx|tsx].
Privilégier le format standard CSF pour écrire vos stories.
Utilisez les exports nommés en Upper Camel case à l'intérieur du fichier CSF pour définir les stories de votre composant.
De manière générale, privilégiez le format TS|JS pour vos stories car il offre un meilleur support au code utile à l'initialisation (et à la configuration) des stories.
Privilégiez le format MDX uniquement si vous souhaitez écrire de la documentation sur mesure.
Note : Vous pouvez référencer vos stories exportées depuis votre fichier MDX.
Best practices
Le code d'intégration associé aux stories devrait impliquer uniquement le minimum de code nécessaire.
Si vous remarquez que vous avez besoin des mêmes données dans des stories différentes, il peut être judicieux de créer une factory pour instancier des mocks réutilisables.
Tout le monde est responsable de contribuer et de suivre les conventions de l'équipe.
Toutefois, il peut être utile d'affecter quelqu'un, ou un groupe de personnes, en tant que responsable du design system pour bénéficier d'un référent garant des conventions et de la qualité.
