Crafting the Elements component library Crafter la bibliothèque de composants Elements

With the Design System Lead, we built the Elements UI Kit in Figma: ~50 components with full variant sets, states, and auto-layout. Colors, spacing, typography: every property goes through a Figma Variable, never a value typed by hand. The library became the single source of truth designers reference daily. Avec le Design System Lead, nous avons construit l'Elements UI Kit dans Figma : ~50 composants avec variant sets complets, états et auto-layout. Couleurs, espacements, typographies : chaque propriété passe par une Variable Figma, jamais une valeur saisie à la main. La bibliothèque est devenue la source de vérité unique que les designers consultent au quotidien.

We shaped a layered token architecture (primitives, semantic, component-level) feeding light and dark theming and a clean handoff to code through CSS token generation pipeline. Changing a brand value propagates everywhere, by design. Nous avons façonné une architecture de tokens en couches (primitives, sémantiques, niveau composant) alimentant le theming light et dark et un handoff propre vers le code via la génération de tokens HTML/CSS. Changer une valeur de marque se propage partout, par design.

We structured versioning and designer-facing release communication: a release backlog per Figma library (Foundations, UI Kit), versioned in X.Y.Z semver following Google's convention (patch for fixes, minor for backward-compatible additions, major for breaking changes). Every release ships with release notes and a changelog so designers know what to update. Contribution was standardized around component templates, a release process, and embedded documentation so the library stays consistent no matter who contributes. The team paired tightly with the 4 developers to guarantee design/code parity: every Figma component maps to a built, production-used counterpart. Nous avons structuré le versioning et la communication des nouveautés aux designers : un backlog de release par librairie Figma (Foundations, UI Kit), versionné en semver X.Y.Z selon la convention Google (patch pour les corrections, minor pour les ajouts compatibles, major pour les breaking changes). Chaque release embarque release notes et changelog pour que les designers sachent quoi mettre à jour. Contribution standardisée : templates de composants, process de release, et documentation embarquée pour que la bibliothèque reste cohérente quel que soit le contributeur. L'équipe a travaillé en binôme étroit avec les 4 développeurs pour garantir la parité design/code : chaque composant Figma correspond à un composant développé et utilisé en production.

Storybook became our shared surface for co-building components with engineering: not just dev documentation, but the place where designers and developers align on states, variants, animations, and micro-interactions before anything merges. Chromatic runs visual regression on every component, 100% coverage, so each release ships with systematic QA instead of ad hoc checks. What gets validated in Storybook is what 100+ products consume. Storybook est devenu notre surface partagée de co-construction avec l'engineering : pas seulement de la doc dev, mais l'endroit où designers et développeurs s'alignent sur les états, variants, animations et micro-interactions avant tout merge. Chromatic exécute la régression visuelle sur chaque composant, 100% de couverture, pour que chaque release parte avec une QA systématique plutôt que des vérifications au cas par cas. Ce qui est validé dans Storybook, c'est ce que 100+ produits consomment.

As my role shifted toward Ops, I kept supporting the craft from the operational side: documentation, contribution flow, and adoption, so the library stayed healthy as it scaled. À mesure que mon rôle glissait vers l'Ops, j'ai continué à soutenir le craft depuis le côté opérationnel : documentation, flow de contribution, et adoption, pour que la bibliothèque reste saine en passant à l'échelle.

One concrete example: Chip, Tag, and Badge. Designers used them interchangeably with no shared logic. I audited existing usage (including Figma Analytics), benchmarked other design systems via Mobbin and reference sites to map logical, technical, and visual choices, then crafted the components in Figma with quick feedback loops and tests in real designer interfaces. Documentation included a decision tree so both humans and AI could consume the library correctly. Un exemple concret : Chip, Tag et Badge. Les designers les utilisaient de façon interchangeable, sans logique d'usage partagée. J'ai audité l'existant (dont Figma Analytics), benchmarké d'autres design systems via Mobbin et des sites de référence pour cartographier les choix logiques, techniques et visuels, puis crafté les composants dans Figma avec des boucles de feedback rapides et des tests dans les interfaces actuelles des designers. La documentation incluait un arbre de décision pour guider humains et IA dans la consommation de la librairie.

The Chip work surfaced a pattern: components only accelerate with AI when the library is structured for machines, not just designers. Specs, decision trees, token bindings, and Storybook states became the context layer for a chained skills pipeline on top of the Elements MCP: spec a need, build in Figma and code, validate against the spec. What used to require a beta phase before development can now ship in a single sprint, with humans still owning governance gates. Le travail sur Chip a révélé un pattern : l'IA n'accélère les composants que si la librairie est structurée pour les machines, pas seulement pour les designers. Specs, arbres de décision, bindings de tokens et états Storybook sont devenus la couche de contexte pour un pipeline de skills chaînés on top du MCP Elements : cadrer un besoin, construire dans Figma et le code, valider contre la spec. Ce qui demandait une phase beta avant le dev peut sortir en un sprint, avec les humains qui gardent les gates de gouvernance.