Pourquoi et comment documenter un Design System ?

En juin 2019, Audrey Hacq est venue présenter pourquoi et comment on documente un Design System lors d'un atelier chez OpenClassrooms.

1. /DesignSystemsFrance /DesignSystemsFr designsystems.fr Meetup #7 Talk + Workshop : Démarrer la documentation de son Design System
2. Hello et merci
3. Ouvert à tous les profils : Développeurs, Designers, PMs, etc Invitez vos collègues, amis, etc. Partage d’expériences et connaissance Meetup
4. Evénements 1 rendez-vous mensuel : la troisième semaine du mois • Rencontre • Workshop • Talk • Conférence
5. 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
6. Audrey HACQ Lead Designer - Idean Medium : @audreyhacq
7. 7 Sommaire #1 - Intro à la documentation #2 - En pratique #3 - Le workshop Sommaire
8. Backelite - Digital Service Design by Capgemini Introduction à la documentation 8
9. Backelite - Digital Service Design by Capgemini Pourquoi documenter ? 9
10. 10 Documenter les patterns “If It Isn't Documented, It Doesn't Exist”
11. Backelite - Digital Service Design by Capgemini Qu’est-ce qu’on documente ? 11
12. 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
13. 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
14. 14 Les functional patterns C’est le résultat tangible d’un comportement que l’on souhaite encourager ou permettre via l’interface.
15. 15 Perceptual patterns • couleurs • formes • typographies • espaces • iconographie Liste des perceptual patterns • illustrations • photographies • animations • voice and tone • sons
16. 16 Perceptual patterns A qui sont ces perceptuals patterns ?
17. 17 Perceptual patterns A qui sont ces perceptuals patterns ?
18. 18 Perceptual patterns A qui sont ces perceptuals patterns ?
19. 19 Les functional patterns C’est le résultat tangible d’un comportement que l’on souhaite encourager ou permettre via l’interface.
20. 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
23. Backelite - Digital Service Design by Capgemini Quand documenter ? 23
24. 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
25. Backelite - Digital Service Design by Capgemini Pour quelle cible ? 25
26. 26 Documenter les patterns Documenting Components - Nathan Curtis
27. 27 Documenter les patterns Uniform Design System
28. Backelite - Digital Service Design by Capgemini Avec quels outils ? 28
29. 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
30. 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
31. 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.
32. 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
33. Backelite - Digital Service Design by Capgemini Et concrètement, ça ressemble à quoi ? 37
34. 38 Exemple de présentation Objectif Nom Variantes/États Exemple Différentes techno
35. 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.
36. Backelite - Digital Service Design by Capgemini #1 - Définir l’objectif 40
37. 41 Functional patterns “Patterns Evolve, Behaviours Remain” Alla Kholmatova
38. 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”.
39. 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
40. 44 Exemple “Level up” pattern L’objectif de ce pattern est de promouvoir les contenus qui aident l’utilisateur à monter en compétences.
42. 47 Functional patterns L’échelle d’impact visuel Confronter le pattern au reste du système Scream Shout Whisper
43. Backelite - Digital Service Design by Capgemini #2 - Nommer 48
44. 49 Nommer les patterns Sans un langage commun partagé, difficile de se comprendre...
45. 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
46. 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
47. 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)
48. Backelite - Digital Service Design by Capgemini #3 - Variantes 53
49. 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
50. 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”
51. Backelite - Digital Service Design by Capgemini #4 - États 56
52. 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
53. 58 Nommer les patterns Différents états sur un pattern Meetic Anticiper les états
54. Backelite - Digital Service Design by Capgemini #5 - Do&Don’t 59
55. 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”
56. 61 Do&Don’t - functional patterns
57. 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.
58. Backelite - Digital Service Design by Capgemini Des questions ? 63
59. Backelite - Digital Service Design by Capgemini Workshop time! 64
60. 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)
61. 66 Exemple
62. Backelite - Digital Service Design by Capgemini Pour conclure 67
63. 68 Pour conclure Exprimez-vous ! - Qu'avez-vous avez pensé de ce workshop ? - Que retiendrez-vous ? - Par où allez vous commencer votre documentation demain ?
64. On se retrouve en septembre pour une nouvelle saison !