Ces deux dernières années le concept de Design System a énormément fait parler de lui.
En réalité le terme est devenu tendance en 2016 et n'a pas cessé de gagner en intérêt, que ce soit au sein de la communauté UX/UI ou plus largement dans le secteur du numérique, comme tend à le prouver le graphique ci-dessous.
Figure 1 : évolution du nombre de recherches "design system" sur Google trends de novembre 2012 à décembre 2019.
L'idée initiale du Design System, ou plutôt la base sur laquelle ce concept s'est construit, était que les designers devaient commencer à adopter une stratégie de création de guidelines qui soient adaptables à plusieurs produits (ce que beaucoup faisaient déjà) et évolutives.
La norme avant les Design Systems était la sacrosainte charte graphique, c'est à dire un livrable très exhaustif mais :
- figé dans le temps ;
- dont la mise à jour demande un temps non-négligeable ;
- parfois adapté à seulement quelques supports spécifiques ;
- rédigé souvent "par" et "pour" des designers/graphistes.
Encore aujourd'hui il n'est pas rare de rencontrer des départements IT de gros industriels, ou des structures plus modestes, qui au démarrage d'un projet numérique n'ont à nous fournir qu'une charte graphique print qu'il faudra décliner, afin qu’elle s’adapte aux différents devices (ordinateurs, smartphones, tablettes) et technologies numériques (langages de programmation, CMS, etc …). Ce sont même, dans certains cas, les équipes de développement qui doivent effectuer ce travail d'adaptation de règles de design. Et soyons honnêtes, les développeurs ont bien assez de tâches pour lesquels ils sont bien plus compétents et motivés. L'interprétation/déclinaison de règles de design n'est tout simplement pas leur métier.
Le Design System est donc apparu comme une solution aux problèmes que rencontraient les utilisateurs de chartes graphiques face à la multiplication des supports numériques (devices) et des cycles de conception plus rapides -distribués entre les différentes parties prenantes du projet- apportés par l'agilité.
Mais au fait, c'est quoi un Design System ?
Si on devait donner une définition générique, on pourrait dire qu'un Design System c'est :
Un ensemble de ressources servant à concevoir tous produits ou services digitaux d'une entreprise de manière homogène, accessible par tous, sur une plateforme unique.
La définition du Design System s'est précisée et étendue avec le temps pour couvrir d'autres champs que la simple représentation graphique d'éléments d'interface, de couleurs et de logos. On a commencé à y intégrer les notions de design d'interaction, de valeurs et buts de l'entreprise, de langage humain, à y présenter les règles fonctionnelles et techniques régissant le comportement des composants, voire même directement du code !
Le plus souvent, un Design System prend la forme d'un site web à partir duquel on va pouvoir accéder aux différentes ressources.
Mais avant de rentrer dans le détail du contenu, intéressons-nous d'abord aux principes directeur d'un Design System.
Les principes de base d'un bon Design System :
vivant
Le Design System est un produit vivant qui évolue et s’améliore avec le temps. C'est un processus continu et non livrable final. Cela implique qu'il faut considérer un Design System comme un produit en soit, et mettre en place une gouvernance et une roadmap afin d'assurer la maintenance et les évolutions sur le long terme.
agnostique
Un Design System doit pouvoir être compatible avec l’ensemble des technologies, ou a minima adaptable à toutes les technologies utilisées au sein de l'entreprise. Il est possible de créer un "Design System source" très générique et plusieurs "Design Systems enfants" chacun adapté à une technologie précise (web, IOS, Android).
atomique
Un Design System ne se pense pas par pages mais par composants qui vont pouvoir être assemblés pour créer les pages.
universel
Un Design System doit reprendre un ensemble de standards qui permettront aux utilisateurs de ne pas avoir à systématiquement acquérir de nouvelles habitudes en découvrant les produits de l'entreprise. Il doit également pouvoir répondre à des logiques d’internationalisation que ce soit sur les usages ou le langage.
inclusif
Le Design System doit être pensé pour tous, peu importe le contexte d’utilisation, les déterminants sociaux, ou le niveau de maturité des utilisateurs avec le digital. Il se doit d’intégrer les grandes règles d’utilisabilité et d’accessibilité afin de prendre en compte les spécificités physiques, perceptives et cognitives potentielles des utilisateurs.
Quel est le contenu d'un Design System ?
Maintenant que les principes sont posés, intéressons-nous plus précisément au contenu du Design System. Quelles sont ces fameuses ressources auxquelles les acteurs du projet doivent pouvoir accéder ?
Figure 2 : Organisation du contenu d'un design system proposée par Audrey HACQ dans son excellent billet.
identité
La partie identité présente tous les éléments qui vont permettre de rendre la marque reconnaissable. Cette partie doit souvent être crée en collaboration entre marketing, UX et DA.
On y retrouve des éléments souvent présents dans les chartes graphiques et ergonomiques tels que :
- Couleurs
- Typos
- Visuels
- Logos
- Animations
- Sons
- Ton du discours
valeurs de la marque ou de l'entreprise
Intégrer les valeurs de la marque parait souvent superflu, mais cela présente un réel intérêt, surtout lorsque des entreprises externes ou prestataires vont être sollicités pour créer du contenu. Ces valeurs servent de boussole pour aiguiller la conception d'une expérience utilisateur homogène quel que soit le point de contact entre l'utilisateur et la marque. Elles permettent de resituer facilement ce qu'il important de mettre en avant quel que soit le produit.
On retrouve dans les valeurs des éléments comme :
- Idéaux
- Idée(s) fondatrice(s)
- Etat d'esprit
- Précepte(s)à respecter
la librairie de composants
Une des premières idées reçues à oublier quand on parle de Design System, c'est le fait qu'il ne se limite pas à une librairie de composants, mais englobe plusieurs types de contenus. C'est très important de faire cette précision, mais soyons honnête, les composants sont LE contenu principal du Design System. Ils sont le point de contact principal autour duquel vont s'articuler les autres types de contenus. Ce sont également eux qui vont faire la jonction entre l'équipe UX/UI et les équipes techniques.
En règle générale les composants sont créés sur un principe central à maîtriser avant de réaliser un Design System : l'Atomic Design.
Alors, pas de panique, il ne s'agit pas de faire appel à de quelconques compétences en physique nucléaire, mais simplement de repenser la manière dont s'articulent les éléments d'interface !
L'Atomic Design est un principe de décomposition des éléments d'interface proposé par Brad FROST afin de ne plus penser le design d'interface par pages, mais par modules, ou plutôt par composants pouvant être assemblés. Il s'est donc appuyé sur la métaphore des atomes pouvant se combiner en molécules, puis ces molécules en organismes, pour décrire la manière dont les éléments d'interface doivent être pensés.
Ainsi, les plus petits éléments d'interface, ceux qu'on ne peut pas diviser, sont appelés "atomes" (labels, cases à cocher, boutons, icones, etc.). Les composants constitués de plusieurs atomes sont appelés "molécules" (formulaires, barres de recherche, etc.). Les molécules peuvent être agencées dans des "organismes" (Pop-up, header, etc.). Les molécules peuvent servir à construire des "templates" (pages de formulaire, pages d'article, etc.). Et enfin ces templates peuvent faire partie d'un "pattern" (process d'inscription, tunnel d'achat, etc.) étant le plus souvent un cas d'usage.
Ce qui est très puissant avec cette technique, c'est qu'on peut créer une infinité de templates et patterns à partir d'un nombre très restreint d'atomes de départ.
Figure 3 : Exemple de molécules, et organismes créés à partir des mêmes atomes.
Le plus souvent les composants sont créés dans un logiciel de design comme Sketch, Adobe XD ou Figma, permettant la création de "symboles" réunis en un fichier servant de librairie. Aussi, il ne faut pas hésiter à mettre à disposition le fichier servant de librairie de composants dans le Design System et de le garder accessible et à jour afin que tous les designers travaillant sur le projet puissent s'en servir. Le plus simple étant d'avoir un fichier synchronisé sur le cloud grâce à outil comme Abstract pour Sketch ou nativement pour Figma.
Un autre avantage des composants, c'est que selon la technologie utilisée, on peut intégrer directement le code d'un composant dans le Design System.
Cette façon de faire est particulièrement adaptée aux projets développés avec des frameworks basés sur les composants comme Angular et React.
Les composants Angular ou React sont créés sur la base des composant graphiques et de la documentation présente dans le Design System donnant des indications sur leur comportement. Ils sont ensuite mis à disposition dans une librairie insatiable dans plusieurs projets React ou Angular.
Les avantages d'avoir des composants développés dans le design system sont nombreux :
- Les éléments d'interface sont identiques sur toutes les pages d'un produit, voir sur plusieurs produits d'une même entreprise. Leur représentation et la façon d'interagir avec eux est homogène sur toutes les pages. Cela permet à l'utilisateur d'apprendre plus rapidement la logique interne des produits et de mieux prédire le comportement des autres produits de la marque pour ne jamais être perdu. Cela permet également d'éviter de se retrouver avec des composants qui se ressemblent mais s'utilisent différemment d'une page à l'autre, ce qui arrive souvent quand plusieurs équipes travaillent sur des pages différentes d'un même produit et n'ont accès qu'au design de composants.
- Si le design d'un composant est modifié dans le Design System, il suffit de mettre à jour le code du composant de la librairie. Celui-ci sera ainsi mis à niveau dans toutes les pages l'utilisant. Vous minimisez ainsi les régressions au sein de vos projets. Pas besoin de repasser sur toutes les pages utilisant un même composant et modifier toutes ses instances.
- L'économie d'échelle pour la création de nouvelles pages. Une fois les composants développés, le gain de temps sur le développement front lors de la création d'une nouvelle page est considérable. Il suffit aux développeurs de choisir les bons composants, de les câbler et les configurer, plus ou moins comme sur un CMS.
- L'équipe en charge du Design System est consciente de la faisabilité technique des designs, comportement et interactions proposés très en amont. Ces points sont discutés et lorsqu'il faut trancher, toutes les parties sont impliquées.
Certains outils comme storybook permettent de visualiser les composants d'une librairie Angular/React, voir de créer des pages web faisant appel à ces derniers. Il est donc possible de concevoir le Design System directement dans le storybook en joignant la documentation des composants en contexte.
bonnes pratiques UX
Les bonnes pratiques sont très liées aux composants. Il faut les voir comme une notice d'utilisation. Elles permettent de décrire comment ils doivent se comporter, comment interagir avec eux et comment les assembler de la bonne façon. Ces indications sont très importantes car elles permettent de créer des expériences d'utilisation similaires sur des devices totalement différents créés par des équipes différentes. Ainsi un utilisateur pourra retrouver ses habitudes d'utilisation d'un produit à l'autre sans ressentir de différence en commençant une interaction sur un produit de la marque (ex. site web) et en la poursuivant sur d'autres (ex. application mobile, borne interactive).
On y retrouve souvent les éléments suivants :
- Règles d'usage des composants et templates
- Quand et pourquoi utiliser un composant plutôt qu'un autre
- Do et Don't
- Adaptation des composants selon le support/device/resolution
Comment mettre en place un Design System ?
C'est bien sûr la question qui nous vient à l'esprit une fois que l'on est convaincu de la nécessité de mettre en place un Design System dans son organisation.
Il y a de nombreuses choses à considérer pour bien démarrer :
- Qui va l'utiliser (developpeurs, designers, etc.) ?
- Dans combien d'équipes?
- En interne uniquement ou en externe ?
- Quel process et gouvernance mettre en place ?
- Qui va y contribuer et le maintenir à jour ?
- Combien de temps/efforts faut-il y consacrer?
- Pour quels types de supports sera-t-il utilisé ? Sera-t-il utilisé avec des technologies et devices différents ?
- Sur quelle(s) plateforme(s) sera-t-il mis à disposition?
Conclusion
Chacun de ces points mériteraient d'être développés. Toutes les organisations n'ont pas les mêmes besoins et le plus important est de trouver les process, organisations et supports qui remportent le plus l'adhésion des parties prenantes afin d'aboutir à un Design System qui soit utilisé et maintenu dans le temps. C'est pourquoi il est important de co-créer le Design System avec les équipes qui vont l'utiliser et le management stratégique. C'est en tous cas la conviction que j'ai pu me forger lors des missions d'accompagnement à la mise en place de Design Systems que j'ai réalisé pour nos clients.