Design Systems France Meetup #7 - Démarrer la documentation de son Design System

Nous aborderons un sujet récurrent lorsqu’on parle de design systems : La documentation.
Comment bien démarrer sa documentation ? À quel moment ? Pour qui ? Que doit-on spécifier ?
Si toi aussi tu te poses ces questions, rejoins-nous avec ton équipe, en binôme ou en solo afin de pouvoir dès demain commencer la documentation de ton propre design system !

Transcript

1. /DesignSystemsFrance
   /DesignSystemsFr
   designsystems.fr
   Meetup #7
   Talk + Workshop : Démarrer la
   documentation de son Design
   System
   

   View Slide

2. Hello et merci
   

   View Slide

3. Ouvert à tous les profils : Développeurs, Designers, PMs, etc
   Invitez vos collègues, amis, etc.
   Partage d’expériences et connaissance
   Meetup
   

   View Slide

4. Evénements
   1 rendez-vous mensuel : la troisième semaine du mois
   ● Rencontre
   ● Workshop
   ● Talk
   ● Conférence
   

   View Slide

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
   

   View Slide

6. Audrey HACQ
   Lead Designer - Idean
   Medium : @audreyhacq
   

   View Slide

7. 7
   Sommaire
   #1 - Intro à la documentation
   #2 - En pratique
   #3 - Le workshop
   Sommaire
   

   View Slide

8. Backelite - Digital Service Design by Capgemini
   Introduction à la documentation
   8
   

   View Slide

9. Backelite - Digital Service Design by Capgemini
   Pourquoi documenter ?
   9
   

   View Slide

10. 10
    Documenter les patterns
    “If It Isn't Documented, It Doesn't Exist”
    

    View Slide

11. Backelite - Digital Service Design by Capgemini
    Qu’est-ce qu’on documente ?
    11
    

    View Slide

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
    

    View Slide

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
    

    View Slide

14. 14
    Les functional patterns
    C’est le résultat tangible d’un comportement que l’on
    souhaite encourager ou permettre via l’interface.
    

    View Slide

15. 15
    Perceptual patterns
    • couleurs
    • formes
    • typographies
    • espaces
    • iconographie
    Liste des perceptual
    patterns
    • illustrations
    • photographies
    • animations
    • voice and tone
    • sons
    

    View Slide

16. 16
    Perceptual patterns
    A qui sont ces perceptuals patterns ?
    

    View Slide

17. 17
    Perceptual patterns
    A qui sont ces perceptuals patterns ?
    

    View Slide

18. 18
    Perceptual patterns
    A qui sont ces perceptuals patterns ?
    

    View Slide

19. 19
    Les functional patterns
    C’est le résultat tangible d’un comportement que l’on
    souhaite encourager ou permettre via l’interface.
    

    View Slide

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
    

    View Slide

21. View Slide

22. View Slide

23. Backelite - Digital Service Design by Capgemini
    Quand documenter ?
    23
    

    View Slide

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
    

    View Slide

25. Backelite - Digital Service Design by Capgemini
    Pour quelle cible ?
    25
    

    View Slide

26. 26
    Documenter les patterns
    Documenting Components - Nathan Curtis
    

    View Slide

27. 27
    Documenter les patterns
    Uniform Design System
    

    View Slide

28. Backelite - Digital Service Design by Capgemini
    Avec quels outils ?
    28
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

33. Backelite - Digital Service Design by Capgemini
    Et concrètement,
    ça ressemble à quoi ?
    37
    

    View Slide

34. 38
    Exemple de présentation
    Objectif
    Nom
    Variantes/États
    Exemple
    Différentes techno
    

    View Slide

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.
    

    View Slide

36. Backelite - Digital Service Design by Capgemini
    #1 - Définir l’objectif
    40
    

    View Slide

37. 41
    Functional patterns
    “Patterns Evolve, Behaviours Remain”
    Alla Kholmatova
    

    View Slide

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”.
    

    View Slide

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
    

    View Slide

40. 44
    Exemple
    “Level up” pattern
    L’objectif de ce pattern est de
    promouvoir les contenus qui aident
    l’utilisateur à monter en compétences.
    

    View Slide

41. View Slide

42. 47
    Functional patterns
    L’échelle d’impact visuel
    Confronter le pattern au reste du système
    Scream Shout Whisper
    

    View Slide

43. Backelite - Digital Service Design by Capgemini
    #2 - Nommer
    48
    

    View Slide

44. 49
    Nommer les patterns
    Sans un langage commun
    partagé, difficile de se
    comprendre...
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

48. Backelite - Digital Service Design by Capgemini
    #3 - Variantes
    53
    

    View Slide

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
    

    View Slide

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”
    

    View Slide

51. Backelite - Digital Service Design by Capgemini
    #4 - États
    56
    

    View Slide

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
    

    View Slide

53. 58
    Nommer les patterns
    Différents états sur un pattern Meetic
    Anticiper les états
    

    View Slide

54. Backelite - Digital Service Design by Capgemini
    #5 - Do&Don’t
    59
    

    View Slide

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”
    

    View Slide

56. 61
    Do&Don’t - functional patterns
    

    View Slide

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.
    

    View Slide

58. Backelite - Digital Service Design by Capgemini
    Des questions ?
    63
    

    View Slide

59. Backelite - Digital Service Design by Capgemini
    Workshop time!
    64
    

    View Slide

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)
    

    View Slide

61. 66
    Exemple
    

    View Slide

62. Backelite - Digital Service Design by Capgemini
    Pour conclure
    67
    

    View Slide

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 ?
    

    View Slide

64. On se retrouve en
    septembre pour une
    nouvelle saison !
    

    View Slide