Building a Design System That Actually Gets Used

Adoption is a trust problem, not a documentation problem

The instinct when a design system isn't being used is to write more documentation. More usage guidelines, more do's-and-don'ts, more Notion pages nobody reads. That almost never fixes it, because the real reason engineers stop using a system isn't that they don't understand it — it's that they don't trust it to have what they need, so it's faster to just build the one-off. Every time an engineer goes looking for a component and it's not there, or it's there but subtly wrong for their case, that's a small withdrawal from a trust account. Enough withdrawals and the system is dead, no matter how well it's documented.

The fix isn't more documentation — it's making sure the system actually covers the real, messy cases your product needs, not just the clean happy-path version of each component. That means design and engineering need to be looking at the same list of edge cases from day one, not passing a finished-looking library over the wall and hoping it holds up.

Tokens and variables are the actual foundation, not the icing

It's tempting to start a design system with the fun part — building out button variants, card components, nice illustrations. But the part that actually determines whether a system survives contact with a real, evolving product is the boring layer underneath: color tokens, spacing scales, typography variables. In Figma specifically, this means setting up variables (not just styles) for color, spacing, and type from the very first file, so that when the brand's accent color needs to shift, or a client asks for a dark mode, you're changing a handful of variable definitions instead of manually updating hundreds of component instances.

This sounds like infrastructure work that founders don't want to pay for, and I understand why — it doesn't produce a visible screen. But the alternative is a design system that looks complete on day one and becomes unmaintainable by month six, right around when the product actually starts to matter.

There's a compounding benefit here too, one that's easy to underrate until you've felt it firsthand: once tokens are the actual source of truth, rebrands and white-label variants stop being terrifying. I've seen a client ask for a full color refresh two weeks before launch — the kind of request that would normally mean panicking through dozens of screens — get resolved in an afternoon because every component was pulling from the same three or four color variables instead of hardcoded hex values scattered across the file.

The over-engineering trap

The opposite failure mode is just as common, and I've been guilty of it early in my career: building an exhaustively flexible component system before the product has enough real screens to know what flexibility it actually needs. A button component with fourteen configurable props, three of which have ever been used, is worse than three separate, purpose-built button components — it's harder for engineering to implement correctly, harder for new team members to understand, and it was built on guesses about future needs instead of observed, current ones.

The right amount of flexibility is usually determined by looking backward at 4-5 real screens you've already designed, finding the actual variation between them, and building a system that covers that — not by imagining every conceivable future use case.

Common mistakes, in order of how often I see them

• Under-documenting edge cases — empty states, error states, loading states, and truncation/overflow behavior — while over-documenting the happy path everyone can already picture.
• Building the visual layer before locking the token/variable foundation, forcing a painful retrofit later.
• Designing components in isolation from real content — lorem ipsum and placeholder avatars hide truncation and spacing problems that only show up with actual, messy user data.
• No clear ownership after the initial build — a system with no one responsible for maintaining it drifts out of sync with the product within a quarter.
• Treating the system as design-only, with engineering only consuming a static export instead of being involved in how components are actually structured and named.

What "scales" actually means in practice

A design system that scales isn't one with the most components. It's one where adding the 40th screen to a product takes proportionally less design and engineering effort than the 4th screen did — because the vocabulary, the tokens, and the patterns are already established and trusted. That compounding effect is the entire point. If your system isn't measurably speeding up new feature work by the time you've shipped a dozen screens with it, something in the foundation needs to be revisited, not just expanded.

One practical way to check whether this is actually happening on your team: ask an engineer how long they estimate a moderately complex new screen will take, then ask what fraction of that estimate is spent hunting for the right component, debating a one-off spacing value, or rebuilding something that should already exist. If that fraction is shrinking release over release, the system is doing its job. If it's flat or growing, the system has stopped scaling regardless of how many components are in the library.

If you're starting a design system from scratch, or trying to figure out why an existing one isn't getting adopted, I've been through this enough times to help you spot the actual root cause quickly. Get in touch and let's take a look at what you've got.