Design · 18 February 2026 · 6 min read
What a design system engagement under NDA taught me about consistency
I can't name the client or show the work, but the design system project changed how I think about consistency — and what actually breaks it.
One of the engagements I picked up as a freelancer was a design system project I'm not able to show or name — the usual NDA terms that come with product work for an existing brand. I can talk about what I learned, just not what it looked like.
The instinct going in was that a design system is mostly a component library — buttons, inputs, spacing tokens, documented once and reused everywhere. The reality was that the hard part is almost entirely about the exceptions: the one screen where the spacing scale doesn't quite fit, the one team that needs a variant nobody planned for.
What actually breaks consistency isn't a missing component. It's a team under deadline pressure deciding a one-off is faster than a conversation with whoever owns the system. The technical solution — tokens, a documented library, clear ownership — only works if there's also a process for what happens when someone wants to break the rules.
I came out of that engagement more convinced that a design system is a communication tool before it's a code artifact. The Figma file and the component library are just where the agreement gets written down.