Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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 !

Geoffrey Crofte

October 21, 2020
Tweet

More Decks by Geoffrey Crofte

Other Decks in Design

Transcript

  1. 2020 “Construire un Design System” — @geoffreycrofte Geoffrey Crofte @geoffreycrofte

    linkedin.com/in/geoffreycrofte creativejuiz.fr/blog/ Lead (System) Designer / UX Designer @
  2. 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.
  3. 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
  4. 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 ?
  5. 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
  6. 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”
  7. C’est l’idée de découper des composants en plein de petits

    éléments, comme des briques de LEGO. Principe Atomic Design
  8. Le Principe d’Atomic appliqué dans l’univers Foyer Design System. Les

    features inclus une logique d’expérience utilisateur globale. Principe Atomic Design
  9. 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
  10. 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
  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 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
  20. 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.
  21. 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.
  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. 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
  26. 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
  27. 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
  28. Pour les designers, il est super simple d’accéder à des

    éléments graphiques existants. Concrètement À quoi ça ressemble ?
  29. Pour les designers, il est super simple d’accéder à des

    éléments graphiques existants. Concrètement À quoi ça ressemble ?
  30. 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 ?
  31. 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
  32. 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
  33. 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
  34. 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
  35. 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
  36. 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
  37. 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
  38. 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
  39. 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.
  40. 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.
  41. 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.
  42. 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.
  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. 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
  45. A l’époque sous Sketch, nous tentons une première approche de

    nommage qui sera revue plusieurs fois. Une bibliothèque pour les designers
  46. A l’époque sous Sketch, nous tentons une première approche de

    nommage qui sera revue plusieurs fois. Une bibliothèque pour les designers
  47. 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
  48. 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
  49. Après plusieurs tests notamment de nouveaux designers dans l’équipe (hein

    Florentin ;p) nous adoption et organisons notre Figma. Organisation dans Figma
  50. 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
  51. 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
  52. 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
  53. 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
  54. 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
  55. 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
  56. 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
  57. 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
  58. 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
  59. 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
  60. 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
  61. 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
  62. 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
  63. Les composants dans les bibliothèques graphique et technique sont organisés

    et nommés de la même manière. Structure des Composants
  64. Il existe différents modèles de contribution, le nôtre correspondait au

    début à un modèle centralisé. Modèle de contribution
  65. 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
  66. 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
  67. 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
  68. 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
  69. 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
  70. 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
  71. 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
  72. 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
  73. 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
  74. C’est un plaisir de composer des exemples de code interactifs

    et documenté jusqu’au moindre détail. Pour du code interactif Storybook
  75. 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
  76. 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
  77. 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
  78. 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
  79. 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
  80. 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
  81. 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
  82. 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.
  83. 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
  84. 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
  85. 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
  86. 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
  87. 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
  88. Nous avons diffuser une partie de notre Design System en

    ligne, mais elle mériterait davantage de contenu. Améliorer la Comm’ publique
  89. 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é
  90. 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
  91. 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
  92. Questionnez ! En avez-vous vraiment besoin ? Take aways S’il

    fallait résumer Réunissez-vous Regroupez des compétences.
  93. 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 !
  94. 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.
  95. 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.
  96. 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
  97. 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
  98. 2020 “Construire un Design System” — @geoffreycrofte Geoffrey Crofte @geoffreycrofte

    linkedin.com/in/geoffreycrofte creativejuiz.fr/blog/ Lead (System) Designer / UX Designer @