Your Design System is a Museum, Not a Toolkit

We need to admit that we have a hoarding problem.

We spend six months locking ourselves in a room to build the Ultimate Design System. We follow Atomic Design religiously. We name our tokens. We build components with auto-layout so complex they require a PhD to resize.

It is a beautiful. It is comprehensive. It is a work of art.

And nobody uses it.

The engineers ignore it because the documentation is in a 40-page PDF. The other designers ignore it because it's too rigid to actually solve new problems. So they detach the instance, break the link, and move on.

We built a museum; a place to look at perfect things behind glass. We should have built a toolkit; a messy; durable set of hammers to build actual software.

Here is how to stop curating exhibits and start shipping.

1. The Snowflake rule

Design systems managers treat Detaching an Instance like a moral failing. They act like if your break the link to the master component, you have sinned aganist the purity of the file.

Get over it.

Sometimes, a feature is unique. It's a Snowflake. If you spend three days trying to force a unique marketing modal into your standard Card component just to keep the library pure, you are wasting time.

If you need it once, detach it. It's a snowflake. If you need it three times, then it's a pattern. Systemise it later. Don't pre-optimize for a future that hasn't happened yet.

2. The Variant trap

We have a fixation on variants. We try to predict every possible permutation of a component.

• Card/ImageLeft/ButtonRight/NoBadge

• Card/ImageTop/NoButton/WithBadge

You end up with a single component that has 400 toggle switches. It is unwieldy, slow, and impossible to maintain.

Stop building variants. Start building Slots.

Build a Card Shell with an empty hole in the middle. Let the designer drop whatever they want into that hole. Don't glue the furniture to the floor; just build the room. Flexible containers beat rigid variants every time.

3. Documentation is a graveyard

Designers love writing documentation that nobody reads. We create beautiful Notion pages and Zeroheight sites explaining the philosophical theory of our spacing scale.

Developers do not read philosophy. They read code.

If your documentation lives in a separate tab, it does not exist.

Put the instructions where the work happens.

• In Figma : Use the Description field on the component.

• In Code : Put the usage guidelines in the README or the Storybook.

If I have to leave the tool to learn how to use the tool, the tool is broken.

4. Versioning paralyzes you

We are terrified of updates. We know that if we change the border radius on the Primary Button, it might visually break 500 screens across 40 files.

So what do we do? We stop updating the system. We leave the old button as Legacy and create Button_New. Then Button_New_V2.

Suddenly, your system is a history museum of every bad decision you've made since 2022.

A Design System is software. It has bugs. It needs patches. Break the screens. Communicate the change. If your system is so fragile that you can't improve it without ruining the product, it's not a system; it's a house of cards.

A Design System is never done. It is a living product that serves other products.

If you find yourself shouting at other designers for using it wrong, the problem isn't the user. The problem is that you built a shrine instead of a screwdriver. Stop gluing the bricks together.