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

5b6a2bd86ef643786a381a212e0ef2f1?s=47 Geoffrey Crofte
October 21, 2020

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 !

5b6a2bd86ef643786a381a212e0ef2f1?s=128

Geoffrey Crofte

October 21, 2020
Tweet

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
  67. None
  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
  86. None
  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
  93. None
  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
  102. None
  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
  111. None
  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 @