ECVAix-en-Provence
Two years in a row, I ran a workshop for first-year Master’s students. The goal: build and document a complete design system.
These first-year Master’s students can already design interfaces. But without a method for thinking at scale, consistency between screens is left to chance. My goal: that they can build a real design system the next day, not just recite a method.
Giving the right methods before opening Figma.
Before building anything, I show why Atomic Design works in a real project. This method builds an interface like Lego: atoms, then molecules, then organisms and pages. It isn’t a textbook classification, it’s a way to assemble and maintain.
Next come variables and tokens. I explain the difference between primitive and semantic, and why a good name says what the token is for. Theming acts as a test: light, dark or per brand. If you can’t switch themes easily, the rules aren’t clear enough.
A design system that can’t switch themes easily has rules that are too vague.
Each student builds their own Figma library, from start to finish.
It isn’t a file to fill in. It’s a complete library, from primitive colours to templates. The exercise forces real choices: how to name a token, where a component ends, what to document.
- 01Define a palette and name tokens after their role
- 02Build the atoms: buttons, input fields, labels
- 03Combine them into molecules: form fields, list items
- 04Then into organisms: forms, menus, cards
- 05Document every component: usage, rules, limits
Short one-to-one reviews unblock each student and confirm the names they chose. They also point out the classic traps: a component too broad, a token too specific, documentation too technical.
Taking apart an existing component to see what should be a token, a slot or a property.
We start from a complex component that already exists, like a product card or a multi-step window. We take it apart. We spot what stays fixed, what adapts and what depends on a token.
- 1Slotmedia, free content
- 2Propertyproduct title
- 3Tokencolor.text.muted
- 4Propertybutton variant
A component that tries to do everything becomes impossible to maintain. Small, well-cut pieces last longer.
Each student leaves with a reworked version and a note that explains their choices. It isn’t a correction, it’s a discussion about trade-offs.
Documenting a component so someone who wasn’t there can use it.
Documentation isn’t a formality. It’s what makes a component usable by the whole team. Without it, only its author knows how to use it.
- 01Usage: when to use it, when to avoid it
- 02Best practices with valid and invalid visual examples
- 03Consistency rules: alignment, spacing, content
- 04Variants: only the allowed combinations
- 05Tokens used: to enable theming
Discussion and practice, never more than 10 minutes of slides.
Each cohort gets 5 days of workshop. I alternate short presentations, live demos and immediate practice. Questions and counter-examples are welcome. Students also work on their own projects.
I don’t aim to pass on textbook basics, but basics that work. They must hold up in a real project, with real trade-offs and real deadlines.
2 cohorts, 14 students, 14 documented libraries handed in.
Let’s work together.
Best fit: a Lead Design System role, permanent and remote. Or a targeted freelance mission: auditing what exists, setting up and supporting teams, organising design work.