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 !

Design Systems France

June 25, 2019
Tweet

More Decks by Design Systems France

Other Decks in Design

Transcript

  1. Ouvert à tous les profils : Développeurs, Designers, PMs, etc

    Invitez vos collègues, amis, etc. Partage d’expériences et connaissance Meetup
  2. Evénements 1 rendez-vous mensuel : la troisième semaine du mois

    • Rencontre • Workshop • Talk • Conférence
  3. 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
  4. 7 Sommaire #1 - Intro à la documentation #2 -

    En pratique #3 - Le workshop Sommaire
  5. 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
  6. 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
  7. 14 Les functional patterns C’est le résultat tangible d’un comportement

    que l’on souhaite encourager ou permettre via l’interface.
  8. 15 Perceptual patterns • couleurs • formes • typographies •

    espaces • iconographie Liste des perceptual patterns • illustrations • photographies • animations • voice and tone • sons
  9. 19 Les functional patterns C’est le résultat tangible d’un comportement

    que l’on souhaite encourager ou permettre via l’interface.
  10. 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
  11. 21

  12. 22

  13. 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
  14. 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
  15. 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
  16. 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.
  17. 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
  18. 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.
  19. 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”.
  20. 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
  21. 44 Exemple “Level up” pattern L’objectif de ce pattern est

    de promouvoir les contenus qui aident l’utilisateur à monter en compétences.
  22. 46

  23. 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
  24. 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
  25. 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)
  26. 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
  27. 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”
  28. 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
  29. 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”
  30. 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.
  31. 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)
  32. 68 Pour conclure Exprimez-vous ! - Qu'avez-vous avez pensé de

    ce workshop ? - Que retiendrez-vous ? - Par où allez vous commencer votre documentation demain ?