Case study
ANS × DSFR Design System
Design system AI
Nobody asked me to choose between two design systems. It was the real question all along.
- Role
- UI / Product designer, consulting and systems
- Period
- 2025 → 2026
- Context
- French Digital Health Agency (ANS), via Atos / Eviden
- Tools & stack
- DSFR 1.14.x · JSON design tokens · AI-assisted generation · Open source (ansforge)
The agency historically maintained its own design system. In parallel, the State mandates the DSFR for every public digital service. Two systems, one agency. The brief said “install the DSFR”; the real question was: what do you do with the agency’s identity when the State imposes its own? What was needed was a bridge, not a binary choice.
The decisions
Additive over replacement
Rewriting a full design system on top of the DSFR would have doubled maintenance and broken native accessibility at every upstream release. The position held: never touch the DSFR core; overlay through tokens and a dedicated stylesheet. Conformance still comes for free, updates stay painless, and every themed component must justify itself by a real identity need.
Generate tokens with AI, validate with judgment
AI accelerates the combinatorial part: producing and mapping dozens of DSFR-compatible JSON token variants. It does not replace judgment: every batch goes through human validation on contrast (RGAA thresholds), brand fidelity, cross-component coherence and accessibility non-regression. A generated token can be pretty and non-conformant.
Knowing when not to theme
When the certification e-service arrived, the theming tool existed, and the answer was not to use it: pure DSFR, because a sovereign service must be recognised as a State site, not an agency brand. A tool you don’t know when to use is just a gadget; the mission delivered the criterion.