Design System
Pourquoi un design system ?
Impact =
- plus de valeur créée (cycles de livraisons + rapides)
- Réduction des coûts (une seule source de vérité = moins de lenteurs causées par la dette design et technique)
- Satisfaction client = vision stratégie cohérente de l'UX
Comment initier un design system
Commencer par un audit pour mettre en place un design system :
- Eviter l'audit solo, partager ça avec d'autres partenaires (développeurs, équipes support pour connaître les cas extrêmes dans le produit, équipes marketing pour avoir l'historique du design dans le produit, etc)
- Consolider les redondances / fondations : la palette des couleurs, styles de texte, ombres portées,...
- Définir ce qui est un composant, et s'il est simple/complexe
On peut aborder la création d'un design system de la même manière qu'on créé un produit :
- Définir ses utilisateurs (designers ? développeurs ?)
- Comprendre leurs besoins, difficultés, frustrations, envies
- Déterminer un scope réaliste
- Créer de la valeur
Profiter des moments clés :
- Rebranding
- Changement de plateforme/librairie côté tech
Structurer un design system
Approche Atomic Design :
- créé par Brad Frost
- correspond à : atomes > molécules > organismes > templates > pages
- Méthodo très bien pour commencer, mais un peu vieille (elle a quelques limitations)
- Limitations
- difficile de s'accorder collectivement sur la catégorie des composants
- Approche très design-centric qui n'inclut pas forcément les modèles de développement (ex: design token)
- Brad Frost lui même challenge son propre modèle
Design tokens
- Standardisés par le groupe W3C design tokens community
- Permet de centraliser, hiérarchiser, unifier les choix UI (couleurs, espacements, typos)
- Nommer les décisions design par le code
Structurer ses tokens/variables
- Valeur brute (ex:
#3B37F2) - Primitive :
palette.brand.indigo.500 - Sémantique :
color.background.interactive.primary.default - Composant :
color.button-primary.background.default
Implémenter un design system
- Structurer ses composants de la même manière qu'un dev (props etc)
- As-t'on besoin/les ressources pour créer un design system from scratch ? Ne pas oublier la possibilité de réutiliser un kit UI existant (MUI (Material UI), Primer (Github), Shadcn,...)
Faire adopter / évangélisation d'un design system
- Face cachée d'un design system = promotion interne du design system (communication, pédagogie, communauté,...)
- Donner de la visibilité
- Partager des release notes
- Partager une roadmap
- Où partager ces infos ? Quels canaux seront les plus efficaces ? (slack, teams, confluence, email,...)
- Identifier des porte-paroles/influenceurs internes (utilisateurs du design system qui ne contribuent pas mais utilisent beaucoup le design system et l'ont déjà adopté). Les aider à structurer des actions de sensibilisation. Cela peut être quelqu'un qui est respecté (ex: qui est dans l'entreprise depuis longtemps), qui a un rôle important (manager, operations, etc),...
- Marketer le design system
- Elaborer une stratégie de campagne, et adapter le discours selon la cible
- Comprendre pourquoi certaines personnes pourraient être réticentes à l'idée de l'adopter
- S'assurer que la prise en main soit simple, que les composants soient documentés (UI + dev)
- Organiser des ateliers pratiques
- Côté UI, préfère documenter dans les fonctions natives de Figma (description du composant par ex) plutôt que du texte en dehors. Car quand ces composants sont réutilisés dans d'autres fichiers, cela permet à la documentation d'apparaître
- Documenter le système (zero height, directement dans Figma, Storybook...)
Qui peut nous aider à évangéliser :
- Product Manager ?
- Marketing ?
Exemples de moyens de communication :
- Canaux slacks : #design-system pour les discussions génériques, #design-system-support pour le support, #design-system-updates pour les MAJ automatisées
- "Office hours" : Une heure par semaine pour répondre aux questions, requêtes de support, idées de fonctionnalités,...
- Email pour l'équipe design system
Documenter un composant Figma
Si possible mettre la documentation dans le champ "description" du composant.
Exemple de description de composant :
Nom
Description
✅Do:
🚫Don't:
🔍Keywords: (for search)
Ressources dev : En dev mode on peut ajouter des "dev resources" (par exemple la documentation storybook, le lien github du composant). Ces dev resources restent même quand le composant est détaché dans Figma.
Mettre en place des indicateurs
Pour évaluer l'adoption et l'engagement :
- Combien de personnes/équipes/projets utilisent le design system
- Combien de personnes sont présentes aux formations, ateliers,...
- Métriques d'utilisation du design system sur Figma : composants insérés, détachés, utilisation de la bibliothèque
Pour cela on peut venir utiliser la fonctionnalité "library analytics" de Figma, qui donne des stats d'utilisation de la librairie. La donnée peut être aussi exportée en CSV.
Structure d'un site de documentation
Pages intéressantes à avoir :
- Accueil pour les infos les plus importantes
- Get Started
- Guidelines
- Accessibilité
- Quel format de date/heure/unités
- Layout : formulaires, système de grille
- Design tokens : couleurs, espacement, typo
- Guidelines dev : html, jss, css
- Mission, principes, valeurs
- UX : workflow, où utiliser tel composant vs un autre
- Icônes & illustrations
- Composant
- Exemples ou études de cas
- Support / Aide
- Documenter tous les canaux slack, email,...
- FAQ
- Page "Statut" : documentation, packages,...
- Schéma du process de contribution
- Blog / News
- A propos
- Changelog
Contribution et maintenance
- Mettre à jour sans frictions, sans perturber la branche source de vérité
- Utiliser les branches Figma
- Ne pas hésiter à déprécier un composant en le notant comme "deprecated" (en utilisant des champs du composant Figma)
- Modèles de contribution
- Tout le monde contribue
- Délégués/volontaires qui travaille sur le design system en plus de leur travail = peut être difficile d'obtenir du temps ou des objectifs très précis pour contribuer
- Equipe dédiée au design system = dans les organisations où le design system est un axe stratégique
- Equipe dédiée + participation ouverte (modèle proposé par Nathan Curtis)
Système de commentaires
Comment utiliser le système de commentaires de Figma efficacement ? On peut venir "tagguer" avec des emojis ou des mots un commentaire (en le mettant en titre)
Exemples :
- Chez Hubspot : #fyi #suggestion #recommendation #plea
- Chez Asana : 🔴do (mandatory), 🟠 try (request), 🟢 consider (share ideas)
Au final c'est très proche de la convention Conventional comments qu'on peut mettre en place côté dev dans gitlab/github. On pourrait totalement imaginer la même convention dans Figma !
Personnalités intéressantes autour du design system
- Brad Frost
- Nathan Curtis
- PJ Onori