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
   

   View Slide

2. 2020
   “Construire un Design System” — @geoffreycrofte
   Geoffrey Crofte
   @geoffreycrofte
   linkedin.com/in/geoffreycrofte
   creativejuiz.fr/blog/
   Lead (System) Designer / UX Designer @
   

   View Slide

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.
   

   View Slide

4. Un Design System
   qu’est-ce que c’est ?
   

   View Slide

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
   

   View Slide

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 ?
   

   View Slide

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
   

   View Slide

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”
   

   View Slide

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
   

   View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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 ?
    

    View Slide

33. Comment l’avons-nous construit ?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

42. Comment nous l’avons construit
    Comprendre
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

48. Comment nous l’avons construit
    Explorer
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

53. Comment nous l’avons construit
    Matérialiser
    

    View Slide

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
    

    View Slide

55. Après plusieurs tests notamment de nouveaux
    designers dans l’équipe (hein Florentin ;p)
    nous adoption et organisons notre Figma.
    Organisation dans
    Figma
    

    View Slide

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
    

    View Slide

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
    

    View Slide

58. Comment nous l’avons construit
    Comprendre… encore !
    

    View Slide

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
    

    View Slide

60. 2020
    “Construire un Design System” — @geoffreycrofte
    

    View Slide

61. 2020
    “Construire un Design System” — @geoffreycrofte
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

67. View Slide

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
    

    View Slide

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
    

    View Slide

70. Construire ensemble
    

    View Slide

71. Ils sont tous magnifiques, n’est-ce pas ?
    L’équipe de
    Designers
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

75. Plusieurs consommateurs vont rentrer en
    conflit, c’est certain.
    Designers
    Développeurs
    Product Owner
    Marketers, etc.
    Confronter les modèles
    

    View Slide

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
    

    View Slide

77. 2020
    “Construire un Design System” — @geoffreycrofte
    Hey Sir!
    C’est demo-time !
    

    View Slide

78. Il existe différents modèles de contribution, le
    nôtre correspondait au début à un modèle
    centralisé.
    Modèle
    de contribution
    

    View Slide

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
    

    View Slide

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
    

    View Slide

81. Un service, une direction.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

86. View Slide

87. Les outils pour vous aider
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

91. C’est un plaisir de composer des exemples de
    code interactifs et documenté jusqu’au moindre
    détail.
    Pour du code interactif
    Storybook
    

    View Slide

92. Nous l’utilisons dans notre documentation
    notamment pour documenter les compositions.
    Pour du code interactif
    CodePen
    

    View Slide

93. View Slide

94. Erreurs et enseignements
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
     

     View Slide

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
     

     View Slide

102. View Slide

103. Quels bénéfices au final ?
     

     View Slide

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.
     

     View Slide

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
     

     View Slide

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
     

     View Slide

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
     

     View Slide

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
     

     View Slide

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
     

     View Slide

110. Estimation en termes pécuniaires.
     Les bénéfices d'un
     Design System
     346€
     économisés
     203€
     dépensés
     

     View Slide

111. View Slide

112. Les évolutions à venir
     

     View Slide

113. Nous avons diffuser une partie de notre Design
     System en ligne, mais elle mériterait davantage
     de contenu.
     Améliorer la
     Comm’ publique
     

     View Slide

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é
     

     View Slide

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
     

     View Slide

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
     

     View Slide

117. Take aways
     S’il fallait résumer
     

     View Slide

118. Questionnez !
     En avez-vous vraiment besoin ?
     Take aways
     S’il fallait résumer
     

     View Slide

119. Questionnez !
     En avez-vous vraiment besoin ?
     Take aways
     S’il fallait résumer
     Réunissez-vous
     Regroupez des compétences.
     

     View Slide

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 !
     

     View Slide

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.
     

     View Slide

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.
     

     View Slide

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
     

     View Slide

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
     

     View Slide

125. Je vais aller voir sur les commentaires…
     Des questions ?
     

     View Slide

126. 2020
     “Construire un Design System” — @geoffreycrofte
     Geoffrey Crofte
     @geoffreycrofte
     linkedin.com/in/geoffreycrofte
     creativejuiz.fr/blog/
     Lead (System) Designer / UX Designer @
     

     View Slide