Tweet
Tweet

Slide 1

Slide 1 text

Construire un Design System dans une société d’assurance centenaire. by AnaliseArt Image

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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 ?

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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”

Slide 9

Slide 9 text

C’est l’idée de découper des composants en plein de petits éléments, comme des briques de LEGO. Principe Atomic Design

Slide 10

Slide 10 text

Le Principe d’Atomic appliqué dans l’univers Foyer Design System. Les features inclus une logique d’expérience utilisateur globale. Principe Atomic Design

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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.

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

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.

Slide 26

Slide 26 text

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.

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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 ?

Slide 33

Slide 33 text

Comment l’avons-nous construit ?

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

Comment nous l’avons construit Comprendre

Slide 43

Slide 43 text

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.

Slide 44

Slide 44 text

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.

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

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.

Slide 47

Slide 47 text

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.

Slide 48

Slide 48 text

Comment nous l’avons construit Explorer

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Comment nous l’avons construit Matérialiser

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

Comment nous l’avons construit Comprendre… encore !

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

2020 “Construire un Design System” — @geoffreycrofte

Slide 61

Slide 61 text

2020 “Construire un Design System” — @geoffreycrofte

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

Construire ensemble

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

Les composants dans les bibliothèques graphique et technique sont organisés et nommés de la même manière. Structure des Composants

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

Un service, une direction.

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

No content

Slide 87

Slide 87 text

Les outils pour vous aider

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

No content

Slide 94

Slide 94 text

Erreurs et enseignements

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

No content

Slide 103

Slide 103 text

Quels bénéfices au final ?

Slide 104

Slide 104 text

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.

Slide 105

Slide 105 text

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

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

No content

Slide 112

Slide 112 text

Les évolutions à venir

Slide 113

Slide 113 text

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

Slide 114

Slide 114 text

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é

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

Take aways S’il fallait résumer

Slide 118

Slide 118 text

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

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

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 !

Slide 121

Slide 121 text

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.

Slide 122

Slide 122 text

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.

Slide 123

Slide 123 text

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

Slide 124

Slide 124 text

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

Slide 125

Slide 125 text

Je vais aller voir sur les commentaires… Des questions ?

Slide 126

Slide 126 text

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