Designing for Clarity: Lessons from Shipping a Design System

A design system is never really "done." It's a living agreement between designers and developers — and like any agreement, it works only when everyone trusts it. Here's what I've learned building them for products like Blockera and Ratin LUCID.

Start with constraints, not components

The instinct is to design buttons first. That's backwards. The most valuable thing a system gives you isn't a component library — it's a shared vocabulary of constraints: spacing, color, type scale, motion.

A good design system doesn't make every screen possible. It makes the right screens easy and the wrong ones awkward.

The three layers that matter

When I audit a system, I look at three layers in order:

1. Tokens — the raw decisions (a --space-4 of 16px, a primary of lime)

2. Primitives — buttons, inputs, cards built only from tokens

3. Patterns — composed flows like a checkout or an onboarding step

Skip layer one and you'll spend forever reconciling layers two and three. A few hard rules I now follow:

• Never hardcode a value a token could express

• Every component ships with its empty, loading, and error states

• If two designers solve the same problem differently, the system failed — not the designers

You can see the token approach in practice on the Blockera editor. It exposes fine-grained control over padding and states without letting users break visual consistency — that balance is the whole game.

When to break your own rules

Never break the rules. Actually — break them deliberately, and document why. A one-off marketing page doesn't need the full system. The danger isn't the exception; it's the undocumented exception that quietly becomes a second system.

Here's the token snippet I start almost every project with:

:root {
  --space-4: 16px;
  --radius: 12px;
  --primary: #c6ff3d;
  --ease: cubic-bezier(0.65, 0.05, 0, 1);
}

---

The goal was never consistency for its own sake. It's trust — so the next designer can move fast without asking permission, and the next developer can build without guessing. Get that right and the system disappears into the work, which is exactly where it belongs.