Case study · 8reasons Digital
a design system that fails the build
the company design system, rebuilt on a real token layer in the W3C tokens format, with a 165-assertion contract test suite that fails the moment built output drifts from spec.
the problem
design systems drift. the spec says one thing, the built output slowly becomes another, and the usual defense is a memo asking everyone to please follow the guidelines. memos don’t stop drift, they document it.
who the user actually is
two audiences with opposite failure modes. engineers building against the system, who need it to be precise enough to trust and cheap enough to follow. and designers relying on what ships, who need the built product to actually look like the spec they signed off. both groups are experts, and both notice immediately when the system lies to them.
the hard part
making compliance structural instead of social. a design system is a promise between disciplines, and promises kept by goodwill decay under deadline pressure. the system had to hold even on the weeks nobody had time to care about it.
what i changed
rebuilt the system on a real token layer in the W3C design tokens format, the tokens as the single source both design and build read from. then, with engineering, a contract test suite: 165 assertions that compare the built output against the token spec on every build.
$ npm run test:contract w3c token layer → built output 165 passing · 0 drift · build gate: red on first divergence
reconstructed from the real suite: 165 assertions run against built output on every build.
outcome
the build fails the moment output drifts from spec, so adoption holds without anyone policing it. the interesting part for a design leader is the shape of the solution: the enforcement lives in the pipeline, where it costs nothing to maintain, instead of in meetings, where it costs everyone.