Au secours, je dois faire un design system ! 😱

8 min readOct 14, 2020

Depuis quelques années maintenant, le terme design system apparaît partout ! Que ça soit sur des Slack, Linkedin, Twitter, des conférences… pas un jour sans en entendre parler. Les grandes boîtes sortent jour après jour leurs propres “DS”. À commencer par Material de Google mais également Carbon d’IBM ou même Gov.uk, le design system du gouvernement britannique ! Ils présentent un mélange de composants, spécifications techniques, guidelines et principes d’organisations. Devant cet engouement, comment ne pas avoir envie de se lancer et dire “On doit faire un design system !”

Maintenant qu’on s’est donné comme objectif de faire son propre Design System, comment se lancer ? Par quel bout commencer ?

Les premières questions à se poser

Première question à se poser : Je pars de quoi ? D’un produit déjà existant ou au contraire de 0 ? Ensuite, qui sont les parties prenantes, c’est à dire qui va participer à sa construction et sa mise en place ? Quelles sont les dépendances et restrictions techniques et organisationnelles ? Et finalement la principale question : pourquoi faire un design system ?

Je pars de quoi ?

Si je pars d’un nouveau produit, c’est-à-dire que celui-ci est à construire, alors je suis sencé partir sur de bonnes bases. En effet, si tout est à construire et on n’a pas, ou en tout cas moins, hérité de dette.

Si je pars d’un produit existant, il est peut-être même déjà en “prod” ! Faire un design system veut d’abord dire exporter les différents éléments fonctionnels de notre produit ; prendre le temps de les identifier, se mettre à écrire des “specs” et peut-être même de les re-développer. Car oui, se lancer sur un design system c’est aussi risquer d’ouvrir la Boîte de Pandore.

Il se pose donc la question de pourquoi se lancer dans ce chantier. À quoi ça sert de faire un design system. Son principal intérêt est d’optimiser l’Expérience Utilisateur, qu’il s’agisse des utilisateurs finaux de notre produit mais également des membres de ou des équipes produits.

Pour les utilisateurs finaux, mettre en place et utiliser un design system permet entre autres de garder une cohérence à travers tout le produit, cette cohérence facilite la navigation, la compréhension du contenu et amène à la réduction des erreurs. Cela permet également de revoir l’accessibilité de votre produit à la fois visuellement et techniquement.

Pour les utilisateurs du design system, c’est à dire les membres de l’équipe produit composée de designers, développeurs et Product Owner, quand on met en place un design system, on travaille avant tout sur la méthodologie du quotidien, et son optimisation.

Faire un design system peut très vite s’apparenter à faire une refonte de son produit. Et ce même sans changer à priori le design et les fonctionnalités.

État des lieux et priorisation

Maintenant que l’on s’est bien décidé à créer un design system, il faut se lancer. En faisant un état des lieux de l’organisation et du produit à travers un ou plusieurs ateliers (le nombre et la durée sont à définir selon le produit et les besoins de l’équipe).

Première chose quand on veut faire l’état des lieux, c’est d’inviter les personnes concernées. Et les personnes les plus concernées par un design system, sont celles qui sont directement impactées : l’équipe de réalisation du produit ! C’est à dire les développeurs, designers, product owner (ou chef de projet), et si il y en un, le scrum master ! Et c’est là que tout va se jouer. En effet, ils va falloir être certain qu’ils sont convaincus de l’intérêt de se lancer dans cette aventure.

L’atelier “état des lieux”

La préparation de l’atelier

Comme tout atelier, il demande une certaine préparation. D’autant plus si on veut être efficace ! À titre personnel, je me suis créé un template de préparation d’atelier afin de ne rien oublier.

Première étape donc de cette préparation : faire des captures de chaque écran (et sur les différents devices bien évidemment). Il faut bien faire attention à prendre ce qui est développé et sur le même environnement (prod, preprod, staging…). Si certaines pages ont plusieurs états, il faut pas hésiter à les capturer. Même si une exhaustivité des pages est préférable, oublier de capturer une obscure page, d’une obscure fonctionnalité, que l’on trouve après moulte pérégrinations dans l’application n’est pas un drame. Si les composants s’y trouvant sont uniques et ne se retrouvent nul par ailleurs, on pourra alors se poser la question plus tard de leur pertinence !

Ensuite, les afficher quelque part. Si vous souhaitez le faire en présentiel, vous pouvez les coller au mur, et si vous le faites à distance, utilisez votre outil préféré (MIro ou Mural par exemple). L’idée est surtout d’avoir la vision globale. Pensez bien à regrouper chaque écran par thématique/fonctionnalités et de toujours bien les nommer.

Bien entendu, invitez les bonnes personnes : les membres de l’équipe produit, comme expliqué précédemment. Mais vous pouvez également convier des personnes externes, comme quelqu’un de l’équipe marketing. L’intérêt d’inviter quelqu’un de non technique et qui a plus de recul sur le produit, réside dans les questions qu’il va poser et les questionnements que ça va créer.

L’élément coeur de votre atelier sera le tableau d’identification. Ce tableau que l’équipe va remplir au fur et à mesure sera la visualisation à l’instant T des composants du produit.

Le tableau d’identification

Tableau d’identification (fait sur Miro)

La classification : sémantique ou fonctionnelle, parle-t-on d’un composant apportant avant tout un sens (exemple une couleur) ou de quelque chose avec lequel une action ou une interaction est possible (exemple un bouton)

La catégorie : la grande catégorie dans laquelle il va être rangé. Par exemple, bouton, formulaire, navigation… Je conseille lors de la préparation de l’atelier d’inventorier quelques catégories comme base de travail.

Le nom : le plus simple à l’instant T mais le plus complexe ensuite ! Dans tous les cas, pensez au sens purement fonctionnel de votre élément. Posez-vous bien la question de la définition de tel ou tel élément. Par exemple cet élément qui ressemble à un lien, est-il bien un lien ou est-ce plutôt un bouton ?

Les états : Listez si vous avez des états particuliers comme des composants désactivés (disabled) ou par exemple en erreur (error).

Le nombre de récurrences fonctionnelles : comptabilisez le nombre de fois où vous trouvez ce composant sans faire cas de son style.

Le nombre de style : comptabilisez le nombre de styles différents que vous trouvez de ce composant. Vous risquez d’avoir des surprises, et même d’avoir des révélations sur l’utilisabilité de votre produit (pensez aux critères ergonomiques de Bastien et Scapin ou encore à la loi de similitude !)

Les commentaires : prévoyez bien sur une colonne commentaire afin d’ajouter quelques petites choses utiles à ne pas oublier. Par exemple, votre navigation principale peut avoir des styles totalement différents entre la version mobile et la version desktop même si on parle du même composant fonctionnellement !

La présence sur le design system parent : cela dépendra si vous avez un design system déjà en construction ou pas ! Cela peut être intéressant si votre atelier se fait dans le cadre du déploiement d’un design system déjà en construction ou implémenté sur d’autres produits que le vôtre.

Des exemples de composants existants : Mettez des exemples de vos composants ! Un petit rappel visuel c’est toujours utile 😀 !

La matrice de priorisation

L’unique identification de vos composants n’est pas suffisante, il va falloir maintenant faire une priorisation de vos composants afin de les embarquer dans votre produit. Pour cela, l’équipe peut les mettre sur une matrice prenant en compte la complexité et la fréquence.

La complexité

Matrice complexité création/implémentation

Tout d'abord quand on parle de complexité de quoi parle-t-on ? On peut voir deux types de complexité : la création et le déploiement du composant.

La complexité de création du composant va dépendre de ce qu’on entend par création d’un composant. Cela peut par exemple impliquer :

La conception “design” (dans Sketch ou Figma par exemple)
L’écriture des spécifications (la fameuse documentation de notre composant)
Le développement du composant en isolation (avec Storybook)

Ces critères de complexité de création peuvent être évolutifs suivant la temporalité au sein du projet. En effet, parfois quand un design system commence à être implémenté, certains composants ont déjà été documentés, il est tout de même intéressant de se poser la question de cette complexité pour avoir une base de réflexion pour le futur. Par ailleurs, on commence généralement par des composants plutôt “simples” comme un bouton ou un élément de liste.

Le second critère de complexité est celui du déploiement et de l’implémentation du composant au sein du produit. Elle dépendra de son état, de la manière dont les éléments de bases ont été développés ! Cette implémentation peut devenir un casse tête surtout si la fréquence est élevée et qu’ils été développés unitairement !

La fréquence

Le second critère de fréquence peut être assimilé à la valeur. On peut imaginer que plus un composant est récurent, plus celui ci à de la valeur. Par exemple, un bouton d’action est l’élément qui va déclencher l’action de l’utilisateur, il a donc beaucoup de valeur. Et on risque de le retrouver partout. Il a à la fois une forte valeur et une forte fréquence !

À contrario, on peut avoir un composant très spécifique répondant à un besoin métier précis et central. On le retrouve qu’une fois mais il a une importance primordiale ! Il a du coup une forte valeur alors qu’il a une très faible fréquence. Un autre cas est un composant que l’on ne retrouve qu’une fois mais partout ! Typiquement la navigation principale. Sa valeur est importante (il permet de naviguer et de se repérer dans le produit) mais il n'apparaît qu’une fois. Il s’agit d’un composant unique à forte valeur ! Ces cas particuliers sont à identifier et à mettre en exergue afin d’être embarqués.

Ainsi la valeur de notre composant est vu sous deux prismes : sa récurrence (le plus facile à identifier) et sa valeur métier pour l'utilisateur final. C’est en prenant en compte ces facteurs et en les associant avec la complexité de création que l’on pourra établir une roadmap du design system au service du ou des produits qu’il sert ! Et ainsi commencer à l’implémenter !

Il est primordial de bien prioriser la création et l’implémentation des composants afin de trouver un juste équilibre avec l’implémentation et/ou l’évolution de fonctionnalités. Il est également important si la mise en place d’un design system intègre une refonte visuelle de votre produit, d’éviter un Big Bang pouvant créer une friction et un rejet plus ou moins important auprès des utilisateurs finaux.

Conclusion

Créer un design system est quelque chose de complexe, méthodique, pouvant être fastidieux. Il risque de remettre en cause certaines choses déjà établies, de peut être ralentir le delivery de valeur fonctionnelle pour l'utilisateur. Mais il faut avant tout le voir comme un apport à la fois pour l’utilisateur et pour l’équipe. Car créer un design system, c’est avant tout améliorer la communication, l’utilisabilité et l’Expérience d’un produit !