Nouvelle vidéo UI Collective sur les design systems et l'IA. Trois idées méritent d'être gardées, et un point mérite un désaccord.
Trois idées à garder
Documenter les règles d'arbitrage entre composants proches et la dette technique assumée, d'abord : ni l'une ni l'autre n'est lisible dans le fichier Figma.
Découper ensuite la documentation par groupe de composants, sinon le modèle suit l'imbrication et oublie la moitié de la bibliothèque.
Et ne pas sur-spécifier la typographie. Des règles trop strictes poussent le modèle à inventer des tailles hors échelle, alors qu'exposer l'échelle sans consignes d'usage donne de meilleurs résultats.
Mon désaccord : la maintenance
Les skills sont produits en one-shot depuis Figma via un prompt Claude, et six semaines plus tard le design system a bougé alors qu'ils décrivent encore un système qui n'existe plus. L'agent ne voit pas la différence : il applique consciencieusement une documentation périmée.
Ce que je mets en place
Deux morceaux. Les données du design system partent dans des fichiers de référence datés, en .md ou en .yaml, et les skills ne stockent plus aucune valeur : ils lisent cette source, ce qui les rend réutilisables sur n'importe quel design system.
Le tout sur un serveur MCP partagé plutôt que sur le poste de chacun, sinon deux designers lancent le même prompt et obtiennent deux écrans différents, sans que personne puisse dire lequel fait foi.