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. Construire un
    Design System
    dans une société d’assurance centenaire.
    by AnaliseArt
    Image

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide

  33. Comment l’avons-nous construit ?

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

  42. Comment nous l’avons construit
    Comprendre

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

  48. Comment nous l’avons construit
    Explorer

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

  53. Comment nous l’avons construit
    Matérialiser

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

  67. 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 full-size slide

  68. 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 full-size slide

  69. Construire ensemble

    View full-size slide

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

    View full-size slide

  71. 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 full-size slide

  72. 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 full-size slide

  73. 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 full-size slide

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

    View full-size slide

  75. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  78. 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 full-size slide

  79. 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 full-size slide

  80. Un service, une direction.

    View full-size slide

  81. 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 full-size slide

  82. 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 full-size slide

  83. 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 full-size slide

  84. 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 full-size slide

  85. Les outils pour vous aider

    View full-size slide

  86. 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 full-size slide

  87. 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 full-size slide

  88. 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  91. Erreurs et enseignements

    View full-size slide

  92. 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 full-size slide

  93. 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 full-size slide

  94. 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 full-size slide

  95. 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 full-size slide

  96. 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 full-size slide

  97. 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 full-size slide

  98. 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 full-size slide

  99. Quels bénéfices au final ?

    View full-size slide

  100. 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 full-size slide

  101. 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 full-size slide

  102. 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 full-size slide

  103. 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 full-size slide

  104. 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 full-size 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
    57 COMPOSANTS
    techniques
    +37 PROJETS
    consommateurs
    5 BREAKING CHANGES
    sans accroc
    42 % DE GAIN DE TEMPS
    estimé en moyenne

    View full-size slide

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

    View full-size slide

  107. Les évolutions à venir

    View full-size slide

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

    View full-size slide

  109. 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 full-size slide

  110. 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 full-size slide

  111. 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 full-size slide

  112. Take aways
    S’il fallait résumer

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  115. 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 full-size slide

  116. 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 full-size slide

  117. 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 full-size slide

  118. 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 full-size slide

  119. 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 full-size slide

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

    View full-size slide

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

    View full-size slide