A verifiable design system for a luxury maison
Building a PIM design system the way you build software: programmatically, with an AI agent working inside Figma, and proving its quality with automated audits instead of promising it
Case study
A verifiable design system for a luxury maison
The Challenge
Delivery-grade requirements were contractual: reference-only styling with zero hardcoded values, variant properties mapping 1:1 to component props, systematic Auto Layout, hierarchical naming. Missing any of them had a price attached, since the contract allowed the development quote to be reopened.
A PIM (Product Information Management) is where a fashion catalog actually happens: operators take products from the ERP and prepare them for e-commerce by filtering, completing data sheets, managing channel visibility, exporting. It's dense, repetitive work where errors are expensive. My job was to take the approved HTML/CSS prototypes and turn them into a design system in Figma, the library a development team would consume to build the real application in Vue.
This project has two users, and only one of them is the operator. The other is the developer who opens Figma Dev Mode: for them, the product is tokens, variant properties and predictable naming. Every ambiguity in the file becomes a question in Slack or, worse, a silent decision.
What made this engagement unusual is that the contract priced design quality explicitly. If the delivery file didn't meet the defined requirements (Variables everywhere, components whose variants map to Vue props, systematic Auto Layout, clean naming), development time would grow and the quote would be renegotiated. Design quality was, quite literally, an economic condition.
"Catalog operators work for hours in a dense interface where an unnoticed state change costs real money. The developer consuming the library needs every state explicit and every value tokenized. Anything else forces reinterpretation, and reinterpretation is where design systems die."
At this scale, dozens of components each with complete states, sizes and properties, the typical failure isn't bad design. It's inconsistency you can't see: the raw hex visually identical to the token, the one state built differently from the other nineteen. Exactly the class of error human review is worst at catching.
The approved prototypes were HTML/CSS: real, but not a system. Values repeated inline, interactive states inconsistent from screen to screen (focus and active missing almost everywhere), naming improvised. Rebuilding them by hand in Figma would have reproduced the drift, one manual decision at a time.
Research
Prototype archaeology
~40 reusable components
Identified from the prototypes and separated from one-off screen compositions and dead code: the actual surface of the system
190 design tokens
Derived and structured as a DTCG source: color primitives and semantic roles, spacing, radii, typography
Real labels beat invented ones
Every component was grounded in its actual usage: labels, states and contents taken from the approved screens, never invented in the abstract
Focus and active states missing everywhere
The prototypes covered default, hover and disabled at best. The states accessibility depends on were the first casualty of hand-building.
Completeness benchmarking
Five states or it isn't done
Carbon's standard became the bar: default, hover, focus, active and disabled for every interactive control, plus error, warning and read-only anatomy for data entry
Uniform conventions make a system machine-operable
Astryx's lesson: when every component follows the same naming, property and composition rules without exceptions, both developers and AI agents can consume the system without a human interpreter
Key Insights
Delivery-grade is an economic property, not an aesthetic one
When a contract prices hardcoded values and missing states, craft stops being taste and becomes a measurable requirement. This reframes the whole job.
Verification is where manual work breaks
Checking that 40 components by 5 states by N properties are all correctly tokenized is exactly the task human eyes fail at and scripts don't. The bottleneck was proving, not drawing.
Ground everything in real usage
Components are abstractions, but their labels, states and contents must come from the approved screens. Look at the page, not just the spec.
The developer is a first-class user
Dev Mode consumption is a user experience. Predictable variants, semantic tokens and clean naming are its usability heuristics.
Once the system matures, coherence beats source fidelity
Mid-project we inverted the hierarchy: the consolidated Figma system became the base of coherence, and prototype CSS deviations were corrected toward the system, not the other way around.
Goals & Principles
Every variant maps to a prop
Component properties (variant, size, state, disabled) designed to translate 1:1 into Vue props, with no reinterpretation required.
Zero hardcoded values
Every color, space, radius and type style applied by reference to a Variable, and verified by script.
Complete state coverage
Carbon-grade state sets on every interactive component, including the focus and active states hand-built systems always drop.
Machine-verifiable delivery
The contractual requirements expressed as assertions a script can check, turning trust into something you can run.
Guiding Principles
Tokens are the only channel for appearance
Two tiers, primitives and semantic roles, and components bind roles only. When a surface needs its own logic, it gets a dedicated role family, never a borrowed one.
Flat structure, private parts
No atomic design tiers. One flat registry; sub-components used only inside others carry a dot prefix (.Table Row, .Tab), which Figma treats as private.
Conventions without exceptions
Naming, properties and composition follow the same rules on every component. Exceptions are where systems start dying.
Quiet luxury, operationalized
A palette born from Renaissance pigments, no pure white, and one brand rule enforced everywhere: gold is identity, never interaction.
Solution Design
Two-tier token architecture in Figma Variables
The contract required reference-only styling, but a flat list of variables invites misuse: roles that look close enough get borrowed for the wrong job.
A DTCG token source compiled into two Variables collections: primitives (the palette) and semantic roles that alias them. Components bind roles only; primitives never appear in a component.
Semantic roles make intent auditable: a text role used as a background is detectable as a smell. When a surface needed its own logic (sidebar, inverse, avatar), it got a small dedicated role family pointing at the same primitives: zero visual delta, full semantic clarity.
Programmatic construction with an AI agent
Forty components with complete state sets, sizes and properties means thousands of micro-decisions that must be applied identically. Hand-building drifts, one component at a time, invisibly.
Every component set is generated from an explicit recipe (variant by state by size, each mapped to token roles) executed by an AI agent through the Plugin API. After each build: screenshot, visual check, fix, re-verify.
Recipes make consistency structural instead of aspirational. Labels become Text properties automatically, focus rings exist because the recipe says so, and the twentieth variant is built exactly like the first. The agent also absorbed the Plugin API's traps (operation order, slot quirks, nested-instance overrides) into a reusable pattern library.
File-wide automated audits
At this scale, claiming everything is tokenized can't be verified by eye. The raw value visually identical to the token is invisible in canvas.
Audit scripts traverse the entire file, checking every fill and stroke of every node inside every component for paints not bound to a Variable, excluding instances (they mirror their master and generate hundreds of false positives) and filtering by ancestor to skip documentation frames.
The audits earned their keep immediately: they caught a 35-icon library whose master fills were raw near-black, visually indistinguishable from the token and inherited silently by every instance in the file. No human review would have found it. A second pass extended the sweep to container nodes and strokes, catching another class of leftovers.
Flat registry with private sub-components
Atomic design tiers don't survive contact with practice. An atom ends up inside another atom, and the hierarchy becomes a lie the team maintains.
One flat list of components, tagged by function (action, form, data, nav, overlay, layout). Sub-components that only live inside others carry a dot prefix: private in Figma, hidden from the assets panel.
The library's public surface is exactly what a developer should instantiate; internals stay internal. The registry doubles as a machine-readable component inventory, with descriptions on every component.
Outcomes & Impact
~40 reusable components in a flat registry, each with complete interactive states (default, hover, focus, active, disabled)
190 design tokens as Figma Variables: primitives aliased by semantic roles, components bind roles only
13 approved prototype screens systematized
100% of fills and strokes inside components bound to Variables after audits, zero raw values
A 35-icon systemic bug caught by script, invisible to eye-level review
Every visible label exposed as a Text property
Contractual requirements verified as assertions, not promised in a handoff note
State ambiguity eliminated: the failure mode that costs operators real money
Dev Mode consumption without a human interpreter: predictable variants, semantic tokens, clean naming
Knowledge survives handoffs: guidelines, component standard and registry travel with the repo
The method itself became a reusable toolchain: recipes, audit scripts and Plugin API patterns now applicable to any client system
Reflections
What Worked
Grounding in the approved prototypes
Never inventing a label or a state kept the system honest and the client conversations short: every component could point at the screen it came from.
Audits as trust infrastructure
The audit scripts changed the relationship with the requirements: instead of defending the file's quality, I could demonstrate it. Run this beats any handoff deck.
Treating the design system as software
Recipes, assertions, reproducible builds: the disciplines that make code trustworthy make libraries trustworthy too. This is the project where that stopped being an analogy.
Challenges
The Plugin API is a minefield of silent failures
Layout properties that must be set in a precise order, slots born with opaque white fills, overrides that don't reset inside nested instances, stale screenshots in long sessions. Each trap cost one debugging session and became a documented, reusable pattern.
Verification needs its own verification
The first audit pass checked only vectors and text, and missed raw fills on container nodes and strokes. Auditing the auditor (extending node types, checking strokes, excluding instances) was a project in itself.
Key Learnings
A design system is a set of claims; an audited design system is a set of proofs
AI agents don't replace design judgment, they make it enforceable at scale
Owning both sides of the handoff, the design decisions and the code that verifies them, is the highest-leverage skill in design systems work
Contracts that price design quality are a gift: they make craft measurable, and measurable craft is defensible
The rarest bugs are the invisible ones: identical-looking values with different semantics. Only infrastructure catches those