Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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 !

73f82a90bab5250087193c95ea45585d?s=128

Design Systems France

June 25, 2019
Tweet

Transcript

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

  22. 22

  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.
  41. 46

  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 !