ECVAix-en-Provence
Deux années de suite, j’ai animé un atelier pour des étudiants de Master 1. Le but : créer et documenter un design system complet.
Ces étudiants de Master 1 savent déjà dessiner des interfaces. Mais sans méthode pour penser à grande échelle, la cohérence entre les écrans tient du hasard. Mon objectif : qu’ils sachent construire un vrai design system dès le lendemain, pas seulement réciter une méthode.
Donner les bonnes méthodes avant d’ouvrir Figma.
Avant de construire quoi que ce soit, je montre pourquoi l’Atomic Design fonctionne dans un vrai projet. Cette méthode construit une interface comme des Lego : atomes, puis molécules, puis organismes et pages. Ce n’est pas un classement scolaire, c’est une façon d’assembler et d’entretenir.
Viennent ensuite les variables et les tokens. J’explique la différence entre primitive et sémantique, et pourquoi un bon nom dit à quoi sert le token. Le theming sert de test : light, dark ou par marque. Si on ne change pas de thème facilement, les règles ne sont pas assez claires.
Un design system qui ne change pas de thème facilement a des règles trop floues.
Chaque étudiant construit sa propre bibliothèque Figma, du début à la fin.
Ce n’est pas un fichier à remplir. C’est une bibliothèque complète, des couleurs primitives jusqu’aux templates. L’exercice oblige à faire de vrais choix : comment nommer un token, où s’arrête un composant, quoi documenter.
- 01Définir une palette et nommer les tokens selon leur rôle
- 02Construire les atomes : boutons, champs de saisie, libellés
- 03Les assembler en molécules : champs de formulaire, éléments de liste
- 04Puis en organismes : formulaires, menus, cartes
- 05Documenter chaque composant : usages, règles, limites
De courtes reviews individuelles débloquent chacun et valident les noms choisis. Elles montrent aussi les pièges classiques : composant trop large, token trop spécifique, documentation trop technique.
Démonter un composant existant pour voir ce qui doit être un token, un slot ou une propriété.
On part d’un composant complexe qui existe déjà, comme une carte produit ou une fenêtre en plusieurs étapes. On le démonte. On repère ce qui reste fixe, ce qui s’adapte et ce qui dépend d’un token.
- 1Slotmédia, contenu libre
- 2Propriététitre du produit
- 3Tokencolor.text.muted
- 4Propriétévariante du bouton
Un composant qui veut tout faire devient impossible à entretenir. De petits éléments bien découpés durent plus longtemps.
Chaque étudiant repart avec une version retravaillée et une note qui justifie ses choix. Ce n’est pas une correction, c’est une discussion sur les compromis.
Documenter un composant pour que quelqu’un qui n’était pas là puisse s’en servir.
La documentation n’est pas une formalité. C’est elle qui rend un composant utilisable par toute l’équipe. Sans elle, seul son auteur sait s’en servir.
- 01Usage : quand utiliser, quand éviter
- 02Bonnes pratiques avec exemples visuels valides et invalides
- 03Règles de cohérence : alignement, espacement, contenu
- 04Variants : seulement les combinaisons autorisées
- 05Tokens utilisés : pour permettre le theming
De l’échange et de la pratique, jamais plus de 10 minutes de diapositives.
Chaque promotion a 5 jours d’atelier. J’alterne présentation courte, démonstration en direct et mise en pratique immédiate. Les questions et les contre-exemples sont les bienvenus. Les étudiants travaillent aussi sur leurs propres projets.
Je ne cherche pas à transmettre des bases scolaires, mais des bases qui servent. Elles doivent tenir dans un vrai projet, avec de vrais compromis et de vrais délais.
2 promotions, 14 étudiants, 14 bibliothèques documentées rendues.
Travaillons ensemble.
Idéal : un poste de Lead Design System en CDI et en télétravail. Ou une mission freelance ciblée : audit de l’existant, mise en place et accompagnement des équipes, organisation du travail de design.