Construire un Design System dans une société d'assurance centenaire

Construire un Design System, c’est répondre à des besoins d’utilisateurs divers en y appliquant un processus de design pour construire un produit et un service en correspondance avec les attentes.

Découvrez comment celui d’une assurance luxembourgeoise centenaire a été construit. Et notamment découvrez la notion de service autour du Design System : ce n'est pas juste une bibliothèque de composants techniques et graphiques !

Transcript

1. Construire un Design System dans une société d’assurance centenaire. by AnaliseArt Image
2. 2020 “Construire un Design System” — @geoffreycrofte Geoffrey Crofte @geoffreycrofte linkedin.com/in/geoffreycrofte creativejuiz.fr/blog/ Lead (System) Designer / UX Designer @
3. Comment ça va se passer ? Un Design System, qu’est-ce que c’est ? Contexte de travail & Problème initial. La construction du Design System. Les outils créés et la notion de service. Bénéfices, erreur et améliorations.
4. Un Design System qu’est-ce que c’est ?
5. C’est une unique source de vérité qui regroupe tous les éléments permettant aux équipes de concevoir, réaliser et développer un produit. — Audrey Hacq
6. Et bien… ça dépend™ Suivant votre contexte de travail, votre système ne sera pas le même pour la société A ou la société B. Cela dépend de : La maturité de votre/vos équipes, L’état des projets en cours, Le temps que vous pouvez y allouer, La composition de votre/vos équipes, etc. Mais en vrai c’est quoi ?
7. Un Design System se compose au moins des éléments suivants : D’une bibliothèque d’éléments graphiques accompagnés de guidelines. D’une bibliothèque d’éléments techniques accompagnés d’une documentation. En règle générale
8. Créer des éléments similaires d’un point de vue visuel et technique sans jamais réinventer la roue. En mutualisant des blocs de code ou composant web (WebComponents) En créant des objets de références pour les designers (Symboles ou Composants. Maîtres suivant les logiciels) Le Principe d’un “système”
9. C’est l’idée de découper des composants en plein de petits éléments, comme des briques de LEGO. Principe Atomic Design
10. Le Principe d’Atomic appliqué dans l’univers Foyer Design System. Les features inclus une logique d’expérience utilisateur globale. Principe Atomic Design
11. Le token est l’élément de plus bas niveau dans la liste des types d’objets définis dans notre Design System. Voyez cela un peu comme une constante déclarée en code. Ex: Variable Sass. Principe Atomic Design
12. Le token est l’élément de plus bas niveau dans la liste des types d’objets définis dans notre Design System. Voyez cela un peu comme une constante déclarée en code. Ex: Variable Sass. Principe Atomic Design
13. Le token est l’élément de plus bas niveau dans la liste des types d’objets définis dans notre Design System. Voyez cela un peu comme une constante déclarée en code. Ex: Variable Sass. Principe Atomic Design
14. Le token est l’élément de plus bas niveau dans la liste des types d’objets définis dans notre Design System. Voyez cela un peu comme une constante déclarée en code. Ex: Variable Sass. Principe Atomic Design
15. Le token est l’élément de plus bas niveau dans la liste des types d’objets définis dans notre Design System. Voyez cela un peu comme une constante déclarée en code. Ex: Variable Sass. Principe Atomic Design
16. Le token est l’élément de plus bas niveau dans la liste des types d’objets définis dans notre Design System. Voyez cela un peu comme une constante déclarée en code. Ex: Variable Sass. Principe Atomic Design
17. Le token est l’élément de plus bas niveau dans la liste des types d’objets définis dans notre Design System. Voyez cela un peu comme une constante déclarée en code. Ex: Variable Sass. Principe Atomic Design
18. Le token est l’élément de plus bas niveau dans la liste des types d’objets définis dans notre Design System. Voyez cela un peu comme une constante déclarée en code. Ex: Variable Sass. Principe Atomic Design
19. Le token est l’élément de plus bas niveau dans la liste des types d’objets définis dans notre Design System. Voyez cela un peu comme une constante déclarée en code. Ex: Variable Sass. Principe Atomic Design
20. Le token est l’élément de plus bas niveau dans la liste des types d’objets définis dans notre Design System. Voyez cela un peu comme une constante déclarée en code. Ex: Variable Sass. Principe Atomic Design
21. Le composant peut être plus où moins simple, et a une fonction basique dans le Design System. Il utilise plusieurs tokens pour être composé. Principe Atomic Design Barlow
22. Principe Atomic Design Logo White variant Blue Gradient L2R variant Input Search Rounded variant Button Icons Different variants AppBarTop - Blue Variant Certains composants sont parfois définis à l’aide de tokens et d’autres composants, et sont plus riches. Ils proposent une géométrie variable.
23. Principe Atomic Design Logo White variant Blue Gradient L2R variant Input Search Rounded variant Button Icons Different variants AppBarTop - Blue Variant Certains composants sont parfois définis à l’aide de tokens et d’autres composants, et sont plus riches. Ils proposent une géométrie variable.
24. Principe Atomic Design Logo White variant Blue Gradient L2R variant Input Search Rounded variant Button Icons Different variants AppBarTop - Blue Variant Certains composants sont parfois définis à l’aide de tokens et d’autres composants, et sont plus riches. Ils proposent une géométrie variable.
25. Principe Atomic Design Logo White variant Blue Gradient L2R variant Input Search Rounded variant Button Icons Different variants AppBarTop - Blue Variant Certains composants sont parfois définis à l’aide de tokens et d’autres composants, et sont plus riches. Ils proposent une géométrie variable.
26. Principe Atomic Design Logo White variant Blue Gradient L2R variant Input Search Rounded variant Button Icons Different variants AppBarTop - Blue Variant Certains composants sont parfois définis à l’aide de tokens et d’autres composants, et sont plus riches. Ils proposent une géométrie variable.
27. Les compositions sont une combinaison des différents éléments précédents, proposant souvent un peu de code custom ou d’ajustement côté design. Principe Atomic Design
28. Les patterns et features sont des mécanismes de navigation ou des processus plus complexes qui permettent de couvrir un gros bout de l’expérience utilisateur. Principe Atomic Design
29. Les patterns et features sont des mécanismes de navigation ou des processus plus complexes qui permettent de couvrir un gros bout de l’expérience utilisateur. Principe Atomic Design
30. Pour les designers, il est super simple d’accéder à des éléments graphiques existants. Concrètement À quoi ça ressemble ?
31. Pour les designers, il est super simple d’accéder à des éléments graphiques existants. Concrètement À quoi ça ressemble ?
32. Pour les développeurs, une variante de code proposant l’ensemble des éléments disponibles pour cette barre est proposé. Concrètement À quoi ça ressemble ?
33. Comment l’avons-nous construit ?
34. L’équipe de Design est à l’origine de l’initiative communiquée à l’intérieur de la société. Toutes ces personnes ne sont pas membres de la Core Team, mais contribuent à leur façon. Construit par Une équipe
35. Les designers et développeurs font chacun à leur sauce, les interfaces et portions de code ne se ressemblent pas. Difficile à maintenir ! Une prise de conscience “Cohérence” Début 2018
36. Une prise de conscience “Temporelle” Les projets sont construits à des instants différents de la vie de la société, et leur code source peut permettre de les dater car ils n’évoluent plus vraiment. Début 2018
37. Une prise de conscience “Communication” Certains projets sont construits par des équipes en parallèle, et ces équipes ne communiquent pas forcément bien, voire pas du tout. Début 2018
38. Une prise de conscience “c’est le bordel” Bref… Il faut trouver un moyen de créer un objet central permettant de rétablir un fonctionnement homogène. Début 2018
39. Tout commence par une prise de conscience et une décision. La construction prend du temps. Il faut une équipe. Il vous faut l’aval de votre supérieur voire du directeur. Une décision
40. L’aventure a commencé grâce à plusieurs aspects importants à considérer : Nous avions un sponsors pour ce projet, Nous avions le DSI pour nous assurer, L’équipe de Design avait le vent en poupe, Un profil Design et Technique a été recruté pour cela. Des gens pour assurer
41. Perdu dans le concept de Design System, je lance la machine “Processus centré utilisateur” : Comprendre : le problème et analyser l’existant. Explorer : des idées et pistes de solution. Matérialiser : implémenter la solution et voir ce que ça donne. (Évaluer) Processus de design
42. Comment nous l’avons construit Comprendre
43. Analyse de l’existant Pour mieux comprendre le problème il faut : Inventorier : l’ensemble des éléments existants. Conserver : les dénominateurs communs pour faciliter l’adoption. Observer : comment fonctionnent les équipes en place.
44. Analyse de l’existant Pour mieux comprendre le problème il faut : Inventorier : l’ensemble des éléments existants. Conserver : les dénominateurs communs pour faciliter l’adoption. Observer : comment fonctionnent les équipes en place.
45. Analyse de l’existant Pour mieux comprendre le problème il faut : Inventorier : l’ensemble des éléments existants. Conserver : les dénominateurs communs pour faciliter l’adoption. Observer : comment fonctionnent les équipes en place.
46. Analyse de l’existant Pour mieux comprendre le problème il faut : Inventorier : l’ensemble des éléments existants. Conserver : les dénominateurs communs pour faciliter l’adoption. Observer : comment fonctionnent les équipes en place.
47. Analyse de l’existant Pour mieux comprendre le problème il faut : Inventorier : l’ensemble des éléments existants. Conserver : les dénominateurs communs pour faciliter l’adoption. Observer : comment fonctionnent les équipes en place.
48. Comment nous l’avons construit Explorer
49. Pour matérialiser rapidement des prototypes de solutions, nous avons utilisé l’existant. Pour la documentation technique nous avons utilisé la documentation en place sur le fameux projet pilote. Utiliser l’existant
50. A l’époque sous Sketch, nous tentons une première approche de nommage qui sera revue plusieurs fois. Une bibliothèque pour les designers
51. A l’époque sous Sketch, nous tentons une première approche de nommage qui sera revue plusieurs fois. Une bibliothèque pour les designers
52. J’avais également proposé un format de règles visuelles graphiques qui n’avait pas nécessairement eu beaucoup d’effet. Des règles plus strictes pour les designers
53. Comment nous l’avons construit Matérialiser
54. Le passage de Sketch à Figma est venu raviver ces éléments de documentation. Nouvel outil, nous avons eu à migrer les composants. Changement d’outils Sketch > Figma
55. Après plusieurs tests notamment de nouveaux designers dans l’équipe (hein Florentin ;p) nous adoption et organisons notre Figma. Organisation dans Figma
56. Mais l’histoire est un peu différente : Comprendre : Ledit projet avait déjà une documentation et un code-base propre. Explorer : quelques adaptations de l’existant ont été proposées. Matérialiser : une documentation mutualiste a été proposée. Appliquer ce processus pour la doc technique
57. Les composants sont sous la forme de packages NPM à intégrer aux projets de développement. 1 version par package 1 version pour le System à part entière 1 forte granularité et responsabilisation des équipes dans leur mise à jour. Package NPM
58. Comment nous l’avons construit Comprendre… encore !
59. En 2 ans nous avons collecté : 2 fois l’avis des équipes de développement. Évalué la satisfaction des consommateurs. Évalué le temps gagné et les pain points Retravaillé beaucoup la documentation Une boucle infinie
60. 2020 “Construire un Design System” — @geoffreycrofte
61. 2020 “Construire un Design System” — @geoffreycrofte
62. Les gens ne lisent pas, c’est la règle numéro 1 de design. Nous sommes donc passés de : 1 code global documenté par composant, À 1 code par exemple visuel affiché. RTFM
63. En parlant de problème : Parfois la documentation embarque du JS Parfois les CSS dépendent d’action en JS (changement d’attributs) Parfois le CSS repose sur des attributs d’accessibilité (ARIA, entre autres) Anecdote
64. Nous avons appris également à revoir notre structure de composants. Suppression des 50 packages Passage à 1 package unique Conservation de la structure par composant. De 50 à 1 paquet
65. Il y a un système de suivi mis en place pour les mises à jour : Une communication e-mail + changelog Une gestion des breaking changes Pas obligatoires mais fortement conseillées Mise à jour
66. Nous proposons depuis 1 an un onboarding systématique des nouvelles équipes : Meeting de kick-off Présentation des concepts aux devs Présentation des avantages aux PO. Onboarding des équipes
68. En explorant et développant une solution, vous cherchez à résoudre un ou plusieurs problèmes. Foule de solutions peuvent être trouvée, il faut savoir prioriser suivant les besoins de votre structure. Priorisation
69. Que ce soit d’un point de vue code, ou d’un point de vue design, nous avons un processus de double validation de l’ensemble des livrables. Un strict processus de Double Validation
70. Construire ensemble
71. Ils sont tous magnifiques, n’est-ce pas ? L’équipe de Designers
72. Seulement une partie de cette équipe est considérée comme Core Team : responsable à leur niveau de la communication, du respect des règles et maintien des guidelines en place. Design System Core Team
73. Pour la construction de votre Design System Entourez-vous d’allié·e·s, Prenez les meilleur·e·s, Apprenez à déléguer, Faites-vous challenger. Ne restez pas seuls
74. Avoir une équipe multidisciplinaire vous permettra d’éviter le Bus Factor (https:// youtu.be/iYxXtlzmq5g - Laurence Vagner) Redondance des compétences, Maintien de l’effort, Permettre le repos des personnes, Partage de l’information. Éviter le bus factor
75. Plusieurs consommateurs vont rentrer en conflit, c’est certain. Designers Développeurs Product Owner Marketers, etc. Confronter les modèles
76. Les composants dans les bibliothèques graphique et technique sont organisés et nommés de la même manière. Structure des Composants
77. 2020 “Construire un Design System” — @geoffreycrofte Hey Sir! C’est demo-time !
78. Il existe différents modèles de contribution, le nôtre correspondait au début à un modèle centralisé. Modèle de contribution
79. Nous aurions aimé nous orienter vers un modèle fédéré, ou tout le monde se sent libre de contribuer ou consommer. Modèle de contribution
80. Mais nous sommes, et je pense resterons, un modèle à cheval entre les deux, ou le contrôle de la Core Team reste indispensable. Modèle de contribution
81. Un service, une direction.
82. Un Design System est bien plus qu’un ensemble de produits et documentations, c’est un service capable d’évoluer, se devant de répondre à des besoins changeants et divers. — Bibi
83. Bien plus qu’une documentation et des bouts de code à copier/coller. Un DS c’est aussi : Des référents techniques qui tabassent, Des designers qui résolvent des problèmes, Une vision de mutualisation et centralisation qui ne s’arrête pas au code et design d’interface. Le “service” Design System
84. Là où il y a répétition, il y a matière à mutualiser. Des mails envoyés aux clients, physiques ou électroniques d’ailleurs. Des photos et illustrations utilisées par la comm’ ou les designers. La manière de communiquer avec nos différents end-users. Oui oui, nous parlons de mots ici. Mutualisation by Design
85. Nous avons déjà commencé à bosser sur AL, notre Assets Library qui permet de regrouper un ensemble d’assets partagés au sein de la société. Assets Library
87. Les outils pour vous aider
88. Nous ne reviendrions jamais en arrière sur cette décision et cet outil je crois. Un des meilleurs choix que nous ayons fait. Pour le design FIGMA
89. Nous l’utilisons pour un mini Design System utilisant Bootstrap comme base technique, c’est très rapide à créer et ça permet de kickstart une documentation en 2 jours. Pour la documentation ZeroHeight
90. Frontify est un outil que j’ai découvert assez tôt mais qui a beaucoup grandi. Il fait presque tout. Pour un assets manager Frontify
91. C’est un plaisir de composer des exemples de code interactifs et documenté jusqu’au moindre détail. Pour du code interactif Storybook
92. Nous l’utilisons dans notre documentation notamment pour documenter les compositions. Pour du code interactif CodePen
94. Erreurs et enseignements
95. Il s’agit d’un produit et d’un service que vous construisez sur le long terme. Partager une vision commune et un objectif commun permet de tacher dès le début des discussions vierges et chronophage en cours de développement. Partager une vision
96. Nous ne l’avons jamais fait, mais nous n’avons jamais eu l’impression que ça manquait pour communiquer dessus. Nous avons nommé un Design System plus petit du groupe, nous n’avons pas vu de différence. Nommer le Design System
97. La base technique semblait saine, nous l’avons récupérée et utilisée ainsi. Notre erreur aura été de construire une première version sur quelques défauts aujourd’hui gênants. Challenger la base
98. La documentation comme notre assets manager sont des outils développés sur mesure. Pensez à regarder du côté des outils existants pour vous faire gagner du temps de maintenance. Dev’ un outil sur-mesure
99. Si le développement d’un Design System est considéré comme side-project les autres projets en cours prendrons le pas rapidement. Cela aura pour effet de vous faire perdre le fil et nuire à la cohérence de vos développements. Le DS comme side-project
100. Il ne s’agit pas du Design System de l’équipe de Design, il s’agit d’un Design System pour l’entreprise, ou le groupe. C’est une responsabilité à partager par l’ensemble des collaborateurs. Responsabilisation
101. Dès le début du projet, réfléchissez aux indicateurs de succès du Design System et mettez en place des moyens de mesurer tout ce beau monde. Mesure et KPIs
103. Quels bénéfices au final ?
104. Le Design System apporte des choses pas forcément évidentes à mesurer. Les bénéfices d’un Design System Cohérence dans le langage visuel. Une source de vérité et un onboarding facilité. Confiance en la marque constatée auprès des utilisateurs. Vitesse de livraison des idées à la mise en prod. Un langage commun entre les collègues, passation aisée. Limite la redondance et améliore le partage interne.
105. Et certaines autres données que nous avons pu évaluer ou calculer grâces aux parties prenantes. Les bénéfices d'un Design System
106. Et certaines autres données que nous avons pu évaluer ou calculer grâces aux parties prenantes. Les bénéfices d'un Design System 57 COMPOSANTS techniques
107. Et certaines autres données que nous avons pu évaluer ou calculer grâces aux parties prenantes. Les bénéfices d'un Design System 57 COMPOSANTS techniques +37 PROJETS consommateurs
108. Et certaines autres données que nous avons pu évaluer ou calculer grâces aux parties prenantes. Les bénéfices d'un Design System 57 COMPOSANTS techniques +37 PROJETS consommateurs 5 BREAKING CHANGES sans accroc
109. Et certaines autres données que nous avons pu évaluer ou calculer grâces aux parties prenantes. Les bénéfices d'un Design System 57 COMPOSANTS techniques +37 PROJETS consommateurs 5 BREAKING CHANGES sans accroc 42 % DE GAIN DE TEMPS estimé en moyenne
110. Estimation en termes pécuniaires. Les bénéfices d'un Design System 346€ économisés 203€ dépensés
112. Les évolutions à venir
113. Nous avons diffuser une partie de notre Design System en ligne, mais elle mériterait davantage de contenu. Améliorer la Comm’ publique
114. Le code embarque déjà des éléments bénéfiques à l’accessibilité numérique. Mais la base technique et graphique peu challengée le sera davantage en 2021. Améliorer L’accessibilité
115. Nous allons tenter de couvrir le Tone of Voice de l’ensemble du Groupe en 2021, c’est un besoin constaté au fil du temps. Nouveaux Outils
116. Notre écoute des collaborateurs nous amènera certainement à découvrir de nouveaux besoins de mutualisation à l’échelle de l’entreprise. Et plein d’autres choses
117. Take aways S’il fallait résumer
118. Questionnez ! En avez-vous vraiment besoin ? Take aways S’il fallait résumer
119. Questionnez ! En avez-vous vraiment besoin ? Take aways S’il fallait résumer Réunissez-vous Regroupez des compétences.
120. Questionnez ! En avez-vous vraiment besoin ? Take aways S’il fallait résumer Réunissez-vous Regroupez des compétences. Définissez les objectifs et n’oubliez pas de mesurer !
121. Questionnez ! En avez-vous vraiment besoin ? Take aways S’il fallait résumer Réunissez-vous Regroupez des compétences. Définissez les objectifs et n’oubliez pas de mesurer ! Communiquez souvent En direction des utilisateurs.
122. Questionnez ! En avez-vous vraiment besoin ? Take aways S’il fallait résumer Réunissez-vous Regroupez des compétences. Définissez les objectifs et n’oubliez pas de mesurer ! Communiquez souvent En direction des utilisateurs. Faites-vous des alliés Pour vous ouvrir plus de portes.
123. Questionnez ! En avez-vous vraiment besoin ? Take aways S’il fallait résumer Réunissez-vous Regroupez des compétences. Définissez les objectifs et n’oubliez pas de mesurer ! Communiquez souvent En direction des utilisateurs. Faites-vous des alliés Pour vous ouvrir plus de portes. Ne restez pas seul·e·s Il y a des communautés en ligne
124. 2020 “Construire un Design System” — @geoffreycrofte Photo - Myriam Jessier Photo - Guillaume de Germain Photo - Hugo Jehanne Photo - Todd Quackenbush Photo - Sharon McCutcheon Photo - Devin Avery Photo - Finn Hackshaw Photo - Matteo Vistocco Photo - Markus Spiske Photo - Scott Graham Article - Team Models for Scaling a Design System Article - Your Sketch Library is not a Design System Article - Outils pour “concevoir accessibles" Website - Foyer Design System Ressources et photos
125. Je vais aller voir sur les commentaires… Des questions ?
126. 2020 “Construire un Design System” — @geoffreycrofte Geoffrey Crofte @geoffreycrofte linkedin.com/in/geoffreycrofte creativejuiz.fr/blog/ Lead (System) Designer / UX Designer @