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 !

1. Construire un
Design System
dans une société d’assurance centenaire.
byAnaliseArtImage

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

3. Comment ça va se passer ?
Un Design System, qu’est-ce que c’est ?
Contexte de travail & Problème initial.
La construction du Design System.
Les outils créés et la notion de service.
Bénéfices, erreur et améliorations.

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

5. C’est une unique source de vérité qui
regroupe tous les éléments permettant
aux équipes de concevoir, réaliser et
développer un produit.
— Audrey Hacq

6. Et bien… ça dépend™
Suivant votre contexte de travail, votre
système ne sera pas le même pour la société A
ou la société B. Cela dépend de :
La maturité de votre/vos équipes,
L’état des projets en cours,
Le temps que vous pouvez y allouer,
La composition de votre/vos équipes,
etc.
Mais en vrai c’est quoi ?

7. Un Design System se compose au moins des
éléments suivants :
D’une bibliothèque d’éléments graphiques
accompagnés de guidelines.
D’une bibliothèque d’éléments techniques
accompagnés d’une documentation.
En règle générale

8. Créer des éléments similaires d’un point de
vue visuel et technique sans jamais réinventer
la roue.
En mutualisant des blocs de code ou
composant web (WebComponents)
En créant des objets de références pour les
designers (Symboles ou Composants.
Maîtres suivant les logiciels)
Le Principe d’un “système”

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

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

11. Le token est l’élément de plus bas niveau dans
la liste des types d’objets définis dans notre
Design System. Voyez cela un peu comme une
constante déclarée en code. Ex: Variable Sass.
Principe
Atomic Design

12. Le token est l’élément de plus bas niveau dans
la liste des types d’objets définis dans notre
Design System. Voyez cela un peu comme une
constante déclarée en code. Ex: Variable Sass.
Principe
Atomic Design

13. Le token est l’élément de plus bas niveau dans
la liste des types d’objets définis dans notre
Design System. Voyez cela un peu comme une
constante déclarée en code. Ex: Variable Sass.
Principe
Atomic Design

14. Le token est l’élément de plus bas niveau dans
la liste des types d’objets définis dans notre
Design System. Voyez cela un peu comme une
constante déclarée en code. Ex: Variable Sass.
Principe
Atomic Design

15. Le token est l’élément de plus bas niveau dans
la liste des types d’objets définis dans notre
Design System. Voyez cela un peu comme une
constante déclarée en code. Ex: Variable Sass.
Principe
Atomic Design

16. Le token est l’élément de plus bas niveau dans
la liste des types d’objets définis dans notre
Design System. Voyez cela un peu comme une
constante déclarée en code. Ex: Variable Sass.
Principe
Atomic Design

17. Le token est l’élément de plus bas niveau dans
la liste des types d’objets définis dans notre
Design System. Voyez cela un peu comme une
constante déclarée en code. Ex: Variable Sass.
Principe
Atomic Design

18. Le token est l’élément de plus bas niveau dans
la liste des types d’objets définis dans notre
Design System. Voyez cela un peu comme une
constante déclarée en code. Ex: Variable Sass.
Principe
Atomic Design

19. Le token est l’élément de plus bas niveau dans
la liste des types d’objets définis dans notre
Design System. Voyez cela un peu comme une
constante déclarée en code. Ex: Variable Sass.
Principe
Atomic Design

20. Le token est l’élément de plus bas niveau dans
la liste des types d’objets définis dans notre
Design System. Voyez cela un peu comme une
constante déclarée en code. Ex: Variable Sass.
Principe
Atomic Design

21. Le composant peut être plus où moins simple,
et a une fonction basique dans le Design
System. Il utilise plusieurs tokens pour être
composé.
Principe
Atomic Design
Barlow

22. Principe
Atomic Design
Logo
White variant
Blue Gradient
L2R variant
Input Search
Rounded variant
Button Icons
Different variants
AppBarTop - Blue Variant
Certains composants sont parfois définis à
l’aide de tokens et d’autres composants, et
sont plus riches. Ils proposent une géométrie
variable.

23. Principe
Atomic Design
Logo
White variant
Blue Gradient
L2R variant
Input Search
Rounded variant
Button Icons
Different variants
AppBarTop - Blue Variant
Certains composants sont parfois définis à
l’aide de tokens et d’autres composants, et
sont plus riches. Ils proposent une géométrie
variable.

24. Principe
Atomic Design
Logo
White variant
Blue Gradient
L2R variant
Input Search
Rounded variant
Button Icons
Different variants
AppBarTop - Blue Variant
Certains composants sont parfois définis à
l’aide de tokens et d’autres composants, et
sont plus riches. Ils proposent une géométrie
variable.

25. Principe
Atomic Design
Logo
White variant
Blue Gradient
L2R variant
Input Search
Rounded variant
Button Icons
Different variants
AppBarTop - Blue Variant
Certains composants sont parfois définis à
l’aide de tokens et d’autres composants, et
sont plus riches. Ils proposent une géométrie
variable.

26. Principe
Atomic Design
Logo
White variant
Blue Gradient
L2R variant
Input Search
Rounded variant
Button Icons
Different variants
AppBarTop - Blue Variant
Certains composants sont parfois définis à
l’aide de tokens et d’autres composants, et
sont plus riches. Ils proposent une géométrie
variable.

27. Les compositions sont une combinaison des
différents éléments précédents, proposant
souvent un peu de code custom ou
d’ajustement côté design.
Principe
Atomic Design

28. Les patterns et features sont des mécanismes
de navigation ou des processus plus
complexes qui permettent de couvrir un gros
bout de l’expérience utilisateur.
Principe
Atomic Design

29. Les patterns et features sont des mécanismes
de navigation ou des processus plus
complexes qui permettent de couvrir un gros
bout de l’expérience utilisateur.
Principe
Atomic Design

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

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

32. Pour les développeurs, une variante de code
proposant l’ensemble des éléments
disponibles pour cette barre est proposé.
Concrètement
À quoi ça ressemble ?

33. Comment l’avons-nous construit ?

34. L’équipe de Design est à l’origine de
l’initiative communiquée à l’intérieur
de la société.
Toutes ces personnes ne sont pas
membres de la Core Team, mais
contribuent à leur façon.
Construit par
Une équipe

35. Les designers et développeurs font chacun à leur
sauce, les interfaces et portions de code ne se
ressemblent pas. Difficile à maintenir !
Une prise de conscience
“Cohérence”
Début 2018

36. Une prise de conscience
“Temporelle”
Les projets sont construits à des instants différents de
la vie de la société, et leur code source peut permettre
de les dater car ils n’évoluent plus vraiment.
Début 2018

37. Une prise de conscience
“Communication”
Certains projets sont construits par des équipes en
parallèle, et ces équipes ne communiquent pas
forcément bien, voire pas du tout.
Début 2018

38. Une prise de conscience
“c’est le bordel”
Bref… Il faut trouver un moyen de créer un objet
central permettant de rétablir un fonctionnement
homogène.
Début 2018

39. Tout commence par une prise de conscience et
une décision.
La construction prend du temps.
Il faut une équipe.
Il vous faut l’aval de votre supérieur voire
du directeur.
Une décision

40. L’aventure a commencé grâce à plusieurs
aspects importants à considérer :
Nous avions un sponsors pour ce projet,
Nous avions le DSI pour nous assurer,
L’équipe de Design avait le vent en poupe,
Un profil Design et Technique a été recruté
pour cela.
Des gens pour assurer

41. Perdu dans le concept de Design System, je
lance la machine “Processus centré utilisateur” :
Comprendre : le problème et analyser
l’existant.
Explorer : des idées et pistes de solution.
Matérialiser : implémenter la solution et voir
ce que ça donne. (Évaluer)
Processus de design

42. Comment nous l’avons construit
Comprendre

43. Analyse de l’existant
Pour mieux comprendre le problème il faut :
Inventorier : l’ensemble des éléments
existants.
Conserver : les dénominateurs communs
pour faciliter l’adoption.
Observer : comment fonctionnent les
équipes en place.

44. Analyse de l’existant
Pour mieux comprendre le problème il faut :
Inventorier : l’ensemble des éléments
existants.
Conserver : les dénominateurs communs
pour faciliter l’adoption.
Observer : comment fonctionnent les
équipes en place.

45. Analyse de l’existant
Pour mieux comprendre le problème il faut :
Inventorier : l’ensemble des éléments
existants.
Conserver : les dénominateurs communs
pour faciliter l’adoption.
Observer : comment fonctionnent les
équipes en place.

46. Analyse de l’existant
Pour mieux comprendre le problème il faut :
Inventorier : l’ensemble des éléments
existants.
Conserver : les dénominateurs communs
pour faciliter l’adoption.
Observer : comment fonctionnent les
équipes en place.

47. Analyse de l’existant
Pour mieux comprendre le problème il faut :
Inventorier : l’ensemble des éléments
existants.
Conserver : les dénominateurs communs
pour faciliter l’adoption.
Observer : comment fonctionnent les
équipes en place.

48. Comment nous l’avons construit
Explorer

49. Pour matérialiser rapidement des prototypes
de solutions, nous avons utilisé l’existant.
Pour la documentation technique nous avons
utilisé la documentation en place sur le
fameux projet pilote.
Utiliser l’existant

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

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

52. J’avais également proposé un format de règles
visuelles graphiques qui n’avait pas
nécessairement eu beaucoup d’effet.
Des règles plus strictes
pour les designers

53. Comment nous l’avons construit
Matérialiser

54. Le passage de Sketch à Figma est venu raviver
ces éléments de documentation. Nouvel outil,
nous avons eu à migrer les composants.
Changement d’outils
Sketch > Figma

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

56. Mais l’histoire est un peu différente :
Comprendre : Ledit projet avait déjà une
documentation et un code-base propre.
Explorer : quelques adaptations de
l’existant ont été proposées.
Matérialiser : une documentation
mutualiste a été proposée.
Appliquer ce processus
pour la doc technique

57. Les composants sont sous la forme de
packages NPM à intégrer aux projets de
développement.
1 version par package
1 version pour le System à part entière
1 forte granularité et responsabilisation des
équipes dans leur mise à jour.
Package NPM

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

59. En 2 ans nous avons collecté :
2 fois l’avis des équipes de développement.
Évalué la satisfaction des consommateurs.
Évalué le temps gagné et les pain points
Retravaillé beaucoup la documentation
Une boucle infinie

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

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

62. Les gens ne lisent pas, c’est la règle numéro 1
de design. Nous sommes donc passés de :
1 code global documenté par composant,
À 1 code par exemple visuel affiché.
RTFM

63. En parlant de problème :
Parfois la documentation embarque du JS
Parfois les CSS dépendent d’action en JS
(changement d’attributs)
Parfois le CSS repose sur des attributs
d’accessibilité (ARIA, entre autres)
Anecdote

64. Nous avons appris également à revoir notre
structure de composants.
Suppression des 50 packages
Passage à 1 package unique
Conservation de la structure par composant.
De 50 à 1 paquet

65. Il y a un système de suivi mis en place pour les
mises à jour :
Une communication e-mail + changelog
Une gestion des breaking changes
Pas obligatoires mais fortement conseillées
Mise à jour

66. Nous proposons depuis 1 an un onboarding
systématique des nouvelles équipes :
Meeting de kick-off
Présentation des concepts aux devs
Présentation des avantages aux PO.
Onboarding des équipes

68. En explorant et développant une solution,
vous cherchez à résoudre un ou plusieurs
problèmes.
Foule de solutions peuvent être trouvée, il faut
savoir prioriser suivant les besoins de votre
structure.
Priorisation

69. Que ce soit d’un point de vue code, ou d’un point de
vue design, nous avons un processus de double
validation de l’ensemble des livrables.
Un strict processus de
Double Validation

70. Construire ensemble

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

72. Seulement une partie de cette équipe est considérée comme
Core Team : responsable à leur niveau de la communication,
du respect des règles et maintien des guidelines en place.
Design System
Core Team

73. Pour la construction de votre Design System
Entourez-vous d’allié·e·s,
Prenez les meilleur·e·s,
Apprenez à déléguer,
Faites-vous challenger.
Ne restez pas seuls

74. Avoir une équipe multidisciplinaire vous
permettra d’éviter le Bus Factor (https://
youtu.be/iYxXtlzmq5g - Laurence Vagner)
Redondance des compétences,
Maintien de l’effort,
Permettre le repos des personnes,
Partage de l’information.
Éviter le bus factor

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

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

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

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

79. Nous aurions aimé nous orienter vers un modèle
fédéré, ou tout le monde se sent libre de
contribuer ou consommer.
Modèle
de contribution

80. Mais nous sommes, et je pense resterons, un
modèle à cheval entre les deux, ou le contrôle de
la Core Team reste indispensable.
Modèle
de contribution

81. Un service, une direction.

82. Un Design System est bien plus qu’un
ensemble de produits et documentations,
c’est un service capable d’évoluer, se devant de
répondre à des besoins changeants et divers.
— Bibi

83. Bien plus qu’une documentation et des bouts
de code à copier/coller. Un DS c’est aussi :
Des référents techniques qui tabassent,
Des designers qui résolvent des problèmes,
Une vision de mutualisation et
centralisation qui ne s’arrête pas au code et
design d’interface.
Le “service” Design System

84. Là où il y a répétition, il y a matière à
mutualiser.
Des mails envoyés aux clients, physiques
ou électroniques d’ailleurs.
Des photos et illustrations utilisées par la
comm’ ou les designers.
La manière de communiquer avec nos
différents end-users. Oui oui, nous parlons
de mots ici.
Mutualisation by Design

85. Nous avons déjà commencé à bosser sur AL,
notre Assets Library qui permet de regrouper
un ensemble d’assets partagés au sein de la
société.
Assets Library

87. Les outils pour vous aider

88. Nous ne reviendrions jamais en arrière sur cette
décision et cet outil je crois. Un des meilleurs
choix que nous ayons fait.
Pour le design
FIGMA

89. Nous l’utilisons pour un mini Design System
utilisant Bootstrap comme base technique, c’est
très rapide à créer et ça permet de kickstart une
documentation en 2 jours.
Pour la documentation
ZeroHeight

90. Frontify est un outil que j’ai découvert assez tôt
mais qui a beaucoup grandi. Il fait presque tout.
Pour un assets manager
Frontify

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

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

94. Erreurs et enseignements

95. Il s’agit d’un produit et d’un service que vous
construisez sur le long terme.
Partager une vision commune et un objectif
commun permet de tacher dès le début des
discussions vierges et chronophage en cours
de développement.
Partager une vision

96. Nous ne l’avons jamais fait, mais nous n’avons
jamais eu l’impression que ça manquait pour
communiquer dessus.
Nous avons nommé un Design System plus
petit du groupe, nous n’avons pas vu de
différence.
Nommer le Design System

97. La base technique semblait saine, nous l’avons
récupérée et utilisée ainsi.
Notre erreur aura été de construire une
première version sur quelques défauts
aujourd’hui gênants.
Challenger la base

98. La documentation comme notre assets
manager sont des outils développés sur
mesure.
Pensez à regarder du côté des outils existants
pour vous faire gagner du temps de
maintenance.
Dev’ un outil sur-mesure

99. Si le développement d’un Design System est
considéré comme side-project les autres
projets en cours prendrons le pas rapidement.
Cela aura pour effet de vous faire perdre le fil
et nuire à la cohérence de vos développements.
Le DS comme side-project

100. Il ne s’agit pas du Design System de l’équipe de
Design, il s’agit d’un Design System pour
l’entreprise, ou le groupe.
C’est une responsabilité à partager par
l’ensemble des collaborateurs.
Responsabilisation

101. Dès le début du projet, réfléchissez aux
indicateurs de succès du Design System et
mettez en place des moyens de mesurer tout ce
beau monde.
Mesure et KPIs

103. Quels bénéfices au final ?

104. Le Design System apporte des choses pas
forcément évidentes à mesurer.
Les bénéfices d’un
Design System
Cohérence
dans le langage visuel.
Une source de vérité
et un onboarding facilité.
Confiance en la marque
constatée auprès des utilisateurs.
Vitesse de livraison
des idées à la mise en prod.
Un langage commun
entre les collègues, passation aisée.
Limite la redondance
et améliore le partage interne.

105. Et certaines autres données que nous avons pu
évaluer ou calculer grâces aux parties prenantes.
Les bénéfices d'un
Design System

106. Et certaines autres données que nous avons pu
évaluer ou calculer grâces aux parties prenantes.
Les bénéfices d'un
Design System
57 COMPOSANTS
techniques

107. Et certaines autres données que nous avons pu
évaluer ou calculer grâces aux parties prenantes.
Les bénéfices d'un
Design System
57 COMPOSANTS
techniques +37 PROJETS
consommateurs

108. Et certaines autres données que nous avons pu
évaluer ou calculer grâces aux parties prenantes.
Les bénéfices d'un
Design System
57 COMPOSANTS
techniques +37 PROJETS
consommateurs
5 BREAKING CHANGES
sans accroc

109. Et certaines autres données que nous avons pu
évaluer ou calculer grâces aux parties prenantes.
Les bénéfices d'un
Design System
57 COMPOSANTS
techniques +37 PROJETS
consommateurs
5 BREAKING CHANGES
sans accroc42 % DE GAIN DE TEMPS
estimé en moyenne

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

112. Les évolutions à venir

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

114. Le code embarque déjà des éléments bénéfiques à
l’accessibilité numérique. Mais la base technique et
graphique peu challengée le sera davantage en 2021.
Améliorer
L’accessibilité

115. Nous allons tenter de couvrir le Tone of Voice de
l’ensemble du Groupe en 2021, c’est un besoin
constaté au fil du temps.
Nouveaux
Outils

116. Notre écoute des collaborateurs nous amènera
certainement à découvrir de nouveaux besoins de
mutualisation à l’échelle de l’entreprise.
Et plein
d’autres choses

117. Take aways
S’il fallait résumer

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

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

120. Questionnez !
En avez-vous vraiment besoin ?
Take aways
S’il fallait résumer
Réunissez-vous
Regroupez des compétences.
Définissez les objectifs
et n’oubliez pas de mesurer !

121. Questionnez !
En avez-vous vraiment besoin ?
Take aways
S’il fallait résumer
Réunissez-vous
Regroupez des compétences.
Définissez les objectifs
et n’oubliez pas de mesurer !
Communiquez souvent
En direction des utilisateurs.

122. Questionnez !
En avez-vous vraiment besoin ?
Take aways
S’il fallait résumer
Réunissez-vous
Regroupez des compétences.
Définissez les objectifs
et n’oubliez pas de mesurer !
Communiquez souvent
En direction des utilisateurs.
Faites-vous des alliés
Pour vous ouvrir plus de portes.

123. Questionnez !
En avez-vous vraiment besoin ?
Take aways
S’il fallait résumer
Réunissez-vous
Regroupez des compétences.
Définissez les objectifs
et n’oubliez pas de mesurer !
Communiquez souvent
En direction des utilisateurs.
Faites-vous des alliés
Pour vous ouvrir plus de portes.
Ne restez pas seul·e·s
Il y a des communautés en ligne

124. 2020“Construire un Design System” — @geoffreycrofte
Photo - Myriam Jessier
Photo - Guillaume de Germain
Photo - Hugo Jehanne
Photo - Todd Quackenbush
Photo - Sharon McCutcheon
Photo - Devin Avery
Photo - Finn Hackshaw
Photo - Matteo Vistocco
Photo - Markus Spiske
Photo - Scott Graham
Article - Team Models for Scaling a Design System
Article - Your Sketch Library is not a Design System
Article - Outils pour “concevoir accessibles"
Website - Foyer Design System
Ressources et photos

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

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