Slide 1
Slide 1 text
/DesignSystemsFrance
/DesignSystemsFr
designsystems.fr
Meetup #7
Talk + Workshop : Démarrer la
documentation de son Design
System
Slide 2
Slide 2 text
Hello et merci
Slide 3
Slide 3 text
Ouvert à tous les profils : Développeurs, Designers, PMs, etc
Invitez vos collègues, amis, etc.
Partage d’expériences et connaissance
Meetup
Slide 4
Slide 4 text
Evénements
1 rendez-vous mensuel : la troisième semaine du mois
● Rencontre
● Workshop
● Talk
● Conférence
Slide 5
Slide 5 text
19h30 - Introduction
Partie 1
19h35 : Talk
19h55 : Questions / réponses
Partie 2
20h00 : Atelier
20h45 : Fin de l'exercice et retours
21h00 : Apéro
Programme de la soirée
Slide 6
Slide 6 text
Audrey HACQ
Lead Designer - Idean
Medium : @audreyhacq
Slide 7
Slide 7 text
7
Sommaire
#1 - Intro à la documentation
#2 - En pratique
#3 - Le workshop
Sommaire
Slide 8
Slide 8 text
Backelite - Digital Service Design by Capgemini
Introduction à la documentation
8
Slide 9
Slide 9 text
Backelite - Digital Service Design by Capgemini
Pourquoi documenter ?
9
Slide 10
Slide 10 text
10
Documenter les patterns
“If It Isn't Documented, It Doesn't Exist”
Slide 11
Slide 11 text
Backelite - Digital Service Design by Capgemini
Qu’est-ce qu’on documente ?
11
Slide 12
Slide 12 text
12
Qu’est-ce qu’on documente ?
On document tout ce qui
doit être partagé
- Les principes d’expériences, les valeurs et
objectifs
- Les bonnes pratiques (UX/UI/dev)
- Les process de l’équipe et ses convictions
- Les choix structurants qui sont fait
- Les patterns et leurs règles d’utilisations dans
les produits
Slide 13
Slide 13 text
13
Créer des patterns
C’est quoi déjà un pattern ?
Définition Wikipédia :
“Un pattern est un modèle, une structure, un motif que l'on peut
observer de façon répétée lors de l'étude de certains sujets”
En interface, cela va se traduire par un composant ou une série de
composants répétables et/ou ré-utilisables à travers plusieurs produits.
→ On distingue 2 types de patterns : perceptuals et functionals
Slide 14
Slide 14 text
14
Les functional patterns
C’est le résultat tangible d’un comportement que l’on
souhaite encourager ou permettre via l’interface.
Slide 15
Slide 15 text
15
Perceptual patterns
• couleurs
• formes
• typographies
• espaces
• iconographie
Liste des perceptual
patterns
• illustrations
• photographies
• animations
• voice and tone
• sons
Slide 16
Slide 16 text
16
Perceptual patterns
A qui sont ces perceptuals patterns ?
Slide 17
Slide 17 text
17
Perceptual patterns
A qui sont ces perceptuals patterns ?
Slide 18
Slide 18 text
18
Perceptual patterns
A qui sont ces perceptuals patterns ?
Slide 19
Slide 19 text
19
Les functional patterns
C’est le résultat tangible d’un comportement que l’on
souhaite encourager ou permettre via l’interface.
Slide 20
Slide 20 text
20
Functionnal patterns
Ce sont tous les composants qui ont un objectif
fonctionnels (interaction avec l’utilisateur).
Ces composants ne prennent leur valeur réelle
que lorsqu’ils sont codés.
Les functionals patterns
Slide 21
Slide 21 text
21
Slide 22
Slide 22 text
22
Slide 23
Slide 23 text
Backelite - Digital Service Design by Capgemini
Quand documenter ?
23
Slide 24
Slide 24 text
24
Documentation
Documenter au fur et à mesure
La documentation ne se fait pas à la fin d’un projet.
Design Systems Features, step-by-step - Nathan Curtis
Slide 25
Slide 25 text
Backelite - Digital Service Design by Capgemini
Pour quelle cible ?
25
Slide 26
Slide 26 text
26
Documenter les patterns
Documenting Components - Nathan Curtis
Slide 27
Slide 27 text
27
Documenter les patterns
Uniform Design System
Slide 28
Slide 28 text
Backelite - Digital Service Design by Capgemini
Avec quels outils ?
28
Slide 29
Slide 29 text
33
Documentation
DSM Les +
● Groupe Invision derrière (rassure les
clients grands comptes)
● Documentation du système
directement gérable et consultable
depuis sketch (plugin craft)
● Possibilité de gérer plusieurs versions
du système en parallèle (versionning)
Les -
● Pas d’inspection codée des
composants (roadmap)
● Pas encore de live components
● Ui de l’interface peu esthétique et
écriture de la documentation peu
souple
Slide 30
Slide 30 text
34
Documentation
ZeroHeight Les +
● Va plus loin que les autres outils en
proposant une vision par composants
● Rattaché aux librairies partagées
Sketch, Figma et bientôt XD
● Historique des versions pour chaque
composant
● Possibilité d’ajouter des composants
“live” déjà codés (via storybook)
● Possibilité d’afficher directement un
PDF ou Google doc externe dans la
documentation
Les -
● Pas de commentaires possibles
● Pas de plugin pour les dev natifs
Slide 31
Slide 31 text
35
Documentation
Storybook
Les +
● Bibliothèque de composants
générée à partir des composants
React/Angular.
● Intégré au projet de dév, donc
versionné.
● Notion de playground, qui permet
de tester les paramètres d’un
composant “en live”.
Les -
● Très orienté “composants dev”, pas
idéal pour de la documentation
UX/UI
● Styleguide maintenable
uniquement par les développeurs.
Slide 32
Slide 32 text
36
Documentation
Notion
Les +
● Hiérarchie et architecture très
personnalisable
● Multitude de composants : texte,
kanban, calendrier, etc.
● Raccourcis en syntaxe Markdown
● Commentaires, Rappels
● Disponible cross device app mobiles,
app desktop et navigateur
● Journal des changements (Updates)
● Possible d’afficher des iframes
Les -
● Pas d’inspection codée des
composants
● Pas de lien réél avec le wrokflow des
designers/développeurs
Slide 33
Slide 33 text
Backelite - Digital Service Design by Capgemini
Et concrètement,
ça ressemble à quoi ?
37
Slide 34
Slide 34 text
38
Exemple de présentation
Objectif
Nom
Variantes/États
Exemple
Différentes techno
Slide 35
Slide 35 text
39
Documentation
Structure de
documentation
Établir dès le début une structure
type de la documentation va
permettre à l’utilisateur (designer,
développeur…) de rapidement trouver
ce qu’il est venu chercher.
Slide 36
Slide 36 text
Backelite - Digital Service Design by Capgemini
#1 - Définir l’objectif
40
Slide 37
Slide 37 text
41
Functional patterns
“Patterns Evolve, Behaviours Remain”
Alla Kholmatova
Slide 38
Slide 38 text
42
Functional patterns
Avant de le concevoir un pattern, il faut
cibler le besoin utilisateur auquel il
répond.
Il est possible de faire des expériences
map et des Job-to-be-done afin de
définir plus précisément les besoins.
Définir l’objectif
d’un pattern
Ex : Une tondeuse ne répond pas au besoin de
“couper l’herbe”, elle est là pour “avoir une
pelouse où l’herbe est rase et jolie”.
Slide 39
Slide 39 text
43
Exemple
“Our mission is to make commerce
better for everyone, no matter where
they’re located or their level of
experience.”
La mission de shopify
Slide 40
Slide 40 text
44
Exemple
“Level up” pattern
L’objectif de ce pattern est de
promouvoir les contenus qui aident
l’utilisateur à monter en compétences.
Slide 41
Slide 41 text
46
Slide 42
Slide 42 text
47
Functional patterns
L’échelle d’impact visuel
Confronter le pattern au reste du système
Scream Shout Whisper
Slide 43
Slide 43 text
Backelite - Digital Service Design by Capgemini
#2 - Nommer
48
Slide 44
Slide 44 text
49
Nommer les patterns
Sans un langage commun
partagé, difficile de se
comprendre...
Slide 45
Slide 45 text
50
Nommer les patterns
Des noms bien choisis
Le nom d’un pattern doit déjà induire certaines
de ses règles d'utilisation.
Plus un nom est facile à retenir, plus il sera
utilisé et donc efficace.
Spotlight Pattern
Slide 46
Slide 46 text
51
Nommer les patterns
Des noms évolutifs
Un nom doit pouvoir rester, même si le pattern
évolue ou change. On privilégiera donc sa
fonction plutôt que sa forme.
Ex = pour des couleurs, on ne dira pas “rouge”
mais “error”
Ex = pour des boutons on parlera plutôt de
Primaire et de secondaire plutôt que “plein” et
“filaire”.
Couleurs
Boutons
Primary Secondary
Slide 47
Slide 47 text
52
Nommer les patterns
Quelques tips
- Favoriser l’anglais (pour une meilleure intégration dans le code des
développeurs
- Éviter de décrire visuellement le composant (Ex : bannière carré)
- Définir une convention de nommage pour les états et les découpes
pour les développeurs
- Se concentrer sur le nom “racine” (c’est celui-là qui doit être partagé et
commun)
Slide 48
Slide 48 text
Backelite - Digital Service Design by Capgemini
#3 - Variantes
53
Slide 49
Slide 49 text
54
Functional patterns
Les variantes vont être toutes les
différentes déclinaisons de ce pattern,
qui garderont le même objectif mais
s’adapteront à des contextes différents :
Taille : Tiny / Small / Medium / Large / Xlarge
Mode : Light mode / Dark mode
Contexte : importance du pattern par
rapport au reste, mobile/desktop...
Variantes d’un pattern
Slide 50
Slide 50 text
55
Functional patterns
Comment ce pattern se comporte t-il sur
différentes tailles d’écran ? Est-ce que le
contenu doit se centrer ? Grossir ? Se
ré-organiser ?
Que donne le composants avec beaucoup
de texte ? Ou au contraire très peu ?
Cela permettra d’anticiper les cas extrêmes.
Penser “responsive”
Slide 51
Slide 51 text
Backelite - Digital Service Design by Capgemini
#4 - États
56
Slide 52
Slide 52 text
57
Nommer les patterns
Anticiper les états
Certains patterns (inputs, boutons…) peuvent avoir
plusieurs états, liés aux différentes actions de
l’utilisateur :
- Normal
- Hover / Pressed
- Focus
- Disabled
- Error / Valid
- Open / Close
Slide 53
Slide 53 text
58
Nommer les patterns
Différents états sur un pattern Meetic
Anticiper les états
Slide 54
Slide 54 text
Backelite - Digital Service Design by Capgemini
#5 - Do&Don’t
59
Slide 55
Slide 55 text
60
Do&Don’t - perceptuals patterns
Définir les combinaisons de perceptual
patterns qui marchent, qui reflètent la
marque et savoir expliquer pourquoi.
Systématiser les
“bonnes combinaisons”
Slide 56
Slide 56 text
61
Do&Don’t - functional patterns
Slide 57
Slide 57 text
62
À retenir
Une bonne documentation est :
- Synthétique : phrases courtes, efficaces, orientées selon la cible
- Visuelle : do&don’t, exemples…. “Une image vaut 1000 mots”
- Évolutive : Ne pas dupliquer le contenu, faire plutôt des liens pour
renvoyer vers d’autres parties de la documentation.
Slide 58
Slide 58 text
Backelite - Digital Service Design by Capgemini
Des questions ?
63
Slide 59
Slide 59 text
Backelite - Digital Service Design by Capgemini
Workshop time!
64
Slide 60
Slide 60 text
65
Workshop
Objectif de l’exercice
- Définir l’objectif du patterns dans le système :
quel est son rôle ? Quel comportement souhaite
t-on encourager ?
- Le nommer (et expliquer pourquoi ce nom)
- Définir ses variantes (responsive, vide/complet)
- Définir ses états (actif/inactif, pressé…)
- Définir ses Do et Don’t
→ La cible de votre documentation sera très large (pas spécifique
designer ou développeur)
Slide 61
Slide 61 text
66
Exemple
Slide 62
Slide 62 text
Backelite - Digital Service Design by Capgemini
Pour conclure
67
Slide 63
Slide 63 text
68
Pour conclure
Exprimez-vous !
- Qu'avez-vous avez pensé de ce workshop ?
- Que retiendrez-vous ?
- Par où allez vous commencer votre
documentation demain ?
Slide 64
Slide 64 text
On se retrouve en
septembre pour une
nouvelle saison !