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
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 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
15 Perceptual patterns • couleurs • formes • typographies • espaces • iconographie Liste des perceptual patterns • illustrations • photographies • animations • voice and tone • sons
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
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
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
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
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.
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
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.
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”.
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
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
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)
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
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”
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
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”
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.
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)
68 Pour conclure Exprimez-vous ! - Qu'avez-vous avez pensé de ce workshop ? - Que retiendrez-vous ? - Par où allez vous commencer votre documentation demain ?
designsystemsfrance
keiko713
s2terminal
k1low
biwashi
palark
iamshunta
yamamuteki
peisuke
dahatake
chiroito
nishiuma
colopl
thoeni
mthomps
addyosmani
shpigford
frogandcode
keavy
erikaheidi
akmur
mongodb
davidbonilla
lara