Tout savoir sur les Design Systems
On peut dire qu’en ce moment, les Systèmes de Design ou Design Systems sont au cœur de mon travail quotidien ! Et à entendre les discussions autour de moi, j’ai l’impression que je suis loin d’être la seule ;)
L’année dernière, j’ai lu le livre d’Alla Kholmatova et récemment j’ai eu la chance d’assister à la première conférence Européenne sur le sujet. Tout cela n’a fait que renforcer ma conviction que, dans le futur, tous les produits et marques s’appuieront sur un Système de Design, qu’il soit succinct ou exhaustif, strict ou flexible, mono ou multi-plateformes…
Déjà, c’est quoi un Système de Design ?
Contrairement à ce que j’entends régulièrement, un Système de Design n’est pas une librairie de composants sur Sketch, pas plus qu’une Style Guide ou une Pattern Librairie. En fait, il englobe tout cela dans un ensemble beaucoup plus large.
Un Système de Design, c’est un point de contact unique qui regroupe tous les éléments qui vont permettre aux différents acteurs d’un projet de le concevoir, de le réaliser et de le faire évoluer.
Le Design System n’est donc pas un livrable mais une suite de livrables. Il évoluera constamment avec les produits et les technologies émergentes.
Comme Jina Anne l’explique très bien lors de cette conférence (avril 2018), un Système de Design se compose d’éléments tangibles et intangibles :
- des outils pour les designers et pour les développeurs, des patterns, des composants, des guidelines…
- Mais également (et c’est souvent le plus difficile à mettre en place) des éléments beaucoup plus abstraits comme des valeurs de marque, des façons communes de travailler, un état d’esprit, des croyances partagées…
Style Guide ou Pattern Library : quelle différence ?
Vous l’aurez compris, le Style Guide et la Pattern librairie ne sont qu’une partie de tous les éléments qui composent un Système de Design.
Le Style Guide comme son nom l’indique va plutôt référencer les styles graphiques (couleurs, typos, illustrations etc…), ceux qui constitueront l’identité unique de la marque.
La Pattern Library quant à elle intégrera des composants plus complexes et déjà fonctionnels.
La plupart des Systèmes de Design récents intègrent les deux, comme Shopify par exemple qui propose un onglet “Visuals” pour les éléments d’identité et un onglet “Components” pour les composants fonctionnels.
Pourquoi en parler maintenant ?
Vouloir factoriser le design et les composants n’est pas nouveau. Mais la tendance s’est accélérée ces dernières années. Les marques sont de plus en plus présentes sur le digital, voire même parfois n’ont plus de charte print.
Longtemps le digital a été traité comme un “side project” : on faisait la charte graphique et on s’occupait ensuite de la “déclinaison” de cette charte pour le digital. Et franchement, aucun designer n’a envie de lire 300 pages de chartes graphiques pour finalement s’apercevoir qu’il n’y a que 6 pages qui le concernent…
L’enjeu aujourd’hui est donc de réconcilier Print et Digital autour d’un langage visuel commun qui sera amené à évoluer au cours du temps.
Pour moi, le Système de Design est le descendant direct de la charte graphique, mais il a gagné en maturité et tend de plus en plus à s’intégrer dans le workflow des équipes. Les outils sont également de plus en plus adaptés et nous permettent maintenant de concevoir des systèmes de composants et de les partager au plus grand nombre.
Et qu’est-ce qu’on met dedans ?
Le Système de Design a pour objectif premier de faciliter le travail des équipes. La première question qu’on va se poser ne sera donc pas “Qu’est-ce que je vais mettre dedans ?” mais plutôt “Qui va s’en servir et comment ?”.
Une fois que la cible sera définie et qu’on aura une première idée de ce qui est déjà mis en place dans l’entreprise (ce qui marche ou non, le niveau de maturité des collaborateurs sur le sujet, les outils existants…) il sera beaucoup plus simple de savoir par où commencer…
#1. Des objectifs et des valeurs partagés
Où va-t-on ? Pourquoi ? Et comment ?
Définir des objectifs clairs est primordial. C’est ce qui va permettre d’aligner les différents acteurs du projet. Les objectifs peuvent être multiples : objectifs de la marque, objectifs du produit, objectifs du Design System lui-même…
Cela va permettre de construire une vision partagée et d’être sûr que tout le monde regarde dans la même direction.
Ces objectifs seront certainement amenés à évoluer au cours du temps et c’est tout à fait normal. L’aspect le plus important sera que ces changements soient très largement communiqués.
Les valeurs, elles, sont des grands « idéaux » qui vont guider les actions à entreprendre en cohérence avec ces objectifs. Ce sont les grands préceptes à garder en tête dès qu’on entre dans le “comment”.
Parallèlement à ces valeurs de marque ou de produit, on peut également définir des valeurs d’équipe qui regrouperont les collaborateurs autour d’un état d’esprit commun.
#2. Des principes d‘expériences
Chez Backelite, nous parlons de “principes d’expérience” plutôt que de “Principes de design” car malheureusement, la traduction française des Design Principles est trop souvent réduite à des aspects purement graphiques. Or les principes d’expériences dépassent largement l’aspect visuel d’un produit :
Les principes d’expériences aident les équipes à atteindre, grâce au design, les objectifs précédemment définis.
Ils vont être guidants, inspirants et aider à prendre des décisions de design structurantes.
Prenons Medium par exemple. Un de leurs principes d’expérience est “Direction over choice”. Ainsi, plutôt que de proposer un éditeur de texte classique (choix illimité de typographies et de couleurs) ils ont préféré un éditeur de texte simplifié qui permet aux auteurs de se concentrer sur le fond de leur article plutôt que sur la forme.
Avoir des principes d’expériences clairs permettra de valider (ou non) un choix de design sur des critères précis et partagés.
#3. Des éléments d’identité de marque
L’identité de la marque est définie via un travail de Branding et de positionnement stratégique, en cohérence avec les valeurs et objectifs de cette marque.
Alla Kholmatova cite une liste précise et exhaustive de ces éléments qu’elle appelle les “perceptual patterns” :
- Couleurs
- Typographies
- Espaces
- Formes
- Iconographie
- Illustrations
- Photographies
- Animations
- Voice and tone
- Sons
Tout ces éléments constituent l’alphabet du langage de la marque.
C’est une bonne base mais cela ne suffit pas pour communiquer… Pour aller plus loin, il faut pouvoir utiliser cet alphabet pour créer des mots puis associer ces mots pour obtenir des phrases qui ont du sens. Ces éléments d’identité nécessiteront donc des règles d’utilisation qui seront en quelque sorte la grammaire et la conjugaison du système.
Dans le Système, cela se matérialise par des guidelines, des do et des don’t ainsi que par de “bons” exemples d’utilisation…
Documenter et accompagner l’utilisation de ces éléments d’identité permet de systématiser les “bonnes combinaisons”, celles qui font que la marque sera unique et ne ressemblera à aucune autre.
#4. Des composants et des patterns
Les composants et les patterns sont au cœur du système. Tous les éléments cités plus haut servent à les créer pour délivrer au final une expérience unique et cohérente à la fois.
Les composants sont nos blocs de LEGO. Ils vont être utilisables dans Sketch pour les designers et directement en code pour les développeurs.
Leurs comportements fonctionnels doivent être spécifiés.
Les patterns eux, sont le mode d’emploi qui va permettre de réutiliser de manière logique et cohérente ces composants à travers le ou les produits.
Dans l’exemple ci-dessous, on voit bien qu’un composant aura une documentation technique et fonctionnelle alors qu’un pattern donnera plutôt des indications sur les recommandations d’utilisation.
Et comme le dit très justement Nathan Curtis dans son article de janvier 2017, créer des patterns peut s’avérer long et fastidieux. Il n’est pas nécessaire que chacun re-créé sans arrêt ses propres Pattern. C’est à la communauté UX au sens large de créer les patterns les plus génériques. Les entreprises, doivent plutôt concentrer leurs efforts sur des Patterns spécifiques à leurs métiers (par exemple, un pattern de virement pour une banque).
Des bonnes pratiques
En complément de la documentation qui est souvent liée directement au système, les bonnes pratiques vont permettre d’accompagner les designers et les développeurs de manière beaucoup plus large et transverse.
L’idée va être d’aller piocher dans les bonnes pratiques générales et de venir en extraire celles qui font sens par rapport au produit et au niveau de maturité des équipes.
Les bonnes pratiques servent à la formation et à la montée en compétences des équipes.
Les types de systèmes de design
Il existe quasiment autant de Systèmes de Design différents que d’équipes différentes.
L’essentiel va donc être, une fois encore, de se poser les bonnes questions :
- Combien de personnes utiliseront ce Système ?
- Quel est leur profil et leur niveau de maturité sur le sujet ?
- Combien de produits doit-il permettre d’aligner ? Sur combien de plateformes ? Combien de technos ?
- Quel degré de cohérence souhaite-t-on entre les différents produits ?
Les réponses à ces différentes questions permettront de préciser le type de Design System le plus adapté.
Dans son livre, Alla Kholmatova nous donne quelques pistes de réflexions.
Strict ou flexible ?
Vos produits doivent-ils être semblables trait pour trait ou avoir un léger air de famille ?
Un système strict sera ultra documenté, totalement synchronisé entre les designers et les développeurs et aura un fort process de validation pour l’introduction d’un nouveau Pattern. Les produits issus d’un système strict se ressembleront en tous points. Un système strict aura tout intérêt à être très exhaustif pour couvrir la grande majorité des cas rencontrés par les équipes. Cela va particulièrement s’adapter à un même produit porté sur plusieurs plateformes (Ex : Airbnb).
Un système flexible, lui, va permettre plus d’expérimentations. Même si un cadre est donné, il va être là à titre indicatif et laisser beaucoup de libertés aux acteurs du projet. Une marque dont le Système de Design devra supporter des produits très différents aura plutôt intérêt à avoir un système générique flexible quitte à créer ensuite des sous-systèmes plus spécifiques et plus stricts.
D’expérience, je me suis rendue compte qu’il faut souvent trouver un juste équilibre entre cohérence et flexibilité : un système trop strict a de fortes chances de rebuter les équipes qui ne voudront pas l’utiliser. D’un autre côté, peut-on encore parler de Système de Design lorsque celui-ci est trop flexible ?
Modulaire ou intégré ?
Un système modulaire est composé de parties interchangeables et ré-utilisables, idéal pour des projets qui vont devoir évoluer rapidement et s’adapter à des besoins utilisateurs variés. Attention cependant, car cela peut vite devenir plus coûteux à réaliser (difficulté de faire des modules qui vont pouvoir être à la fois indépendants et bien se connecter les uns aux autres).
Ce type de système va particulièrement bien s’adapter aux gros sites d’e-commerce, de finance, aux gouvernements… C’est là qu’il va être intéressant de fonctionner en Atomic Design avec une conception très orientée composants.
Un système intégré est, à contrario, basé sur des composants destinés à un contexte unique. Ce type de système va être plus intéressant pour des produits avec une nécessité de direction artistique très forte, qui sorte régulièrement du système établi et dont peu de parties sont ré-utilisables (sites événementiels, des portfolios, des campagnes marketing)…
Centralisé ou réparti ?
La gouvernance et la répartition des équipes autour d’un Système de Design va être structurante pour son évolution.
Il existe plusieurs modèles détaillés par Nathan Curtis. En voici les deux qui me semblent être les plus courants :
Dans un modèle centralisé, une équipe dédiée gère le système et le fait évoluer. Cette équipe doit être en relation étroite avec les autres équipes afin d’être sûre de couvrir tous les besoins des différentes teams et d’être proches de leurs problématiques quotidiennes. Les autres équipes pourront faire des propositions de nouveaux composants ou de nouveaux patterns, mais le choix final de leur intégration ou non au Système reviendra toujours à l’équipe centrale.
Dans un système réparti, des membres de plusieurs équipes sont en charge du système et y contribuent. L’adoption est souvent plus facile mais il faut des garants qui ont la vision transverse du système afin de garder une cohérence d’ensemble. Il faut également s’assurer que ces garants aient bien du temps dédié à la mise à jour du système.
Dans les deux cas, je conseille fortement de faire en sorte que tout le monde puisse participer au système et proposer des évolutions, via par exemple un formulaire de soumission de nouveau Pattern. Un Système de Design doit être l’affaire de tous !
Savoir se positionner
Afin d’aider une entreprise à se positionner sur le type de système souhaité, il est intéressant d’utiliser ce schéma proposé par Alla Kholmatova (qui pourra bien évidemment évoluer au fil du temps) :
L’exemple d’Airbnb :
“ j’ai besoin de factoriser au maximum l’expérience sur mes différentes plateformes, je veux que tout se ressemble et que mes composants puissent être réutilisés à travers mes différents produits”. Le plus adapté sera un modèle strict et modulaire avec une organisation centralisée.
Quelques exemples
Sans originalité aucune, voici mes petits préférés :
- Material Design pour la clarté, la simplicité et les outils mis à disposition des équipes
- Atlassian pour le côté exhaustif
- Polaris de Shopify, pour l’intégration totale dans le workflow des designers et des développeurs
- IBM pour le superbe travail sur l’identité de marque :
Pour finir
Un Système de Design est donc un produit à part entière qui va aider les acteurs d’un projet à construire d’autres produits.
Comme tous les produits, il aura son propre backlog et devra se construire de manière itérative, en gardant les utilisateurs (designers, développeurs, PO…) au centre de la démarche.
Plus le système sera intégré au workflow des designers et des développeurs, plus il sera efficace.
L’outil le plus intéressant que j’ai vu jusqu’ici est le plugin proposé par Polaris qui permet d’afficher le Système de Design directement dans Sketch et d’avoir du coup la documentation à portée de main durant la phase de conception :
Et tout ça n’est qu’un début !
Je suis sûre que l’avenir nous réserve encore de belles évolutions techniques pour nous faciliter la vie et nous permettre de nous concentrer de plus en plus sur l’expérience de nos produits et de nos utilisateurs ;)
Sources
- Livre d’Alla Kholmatova sur les Design Systems
- Tous les articles du fabuleux Nathan Curtis
- Les conférences et articles de Jina Anne
Et pour aller plus loin :
Atelier “Définir les rôles et process autour du design system”
