Design systems live or die by their exceptions

Ask a team what their design system is for and they’ll tell you about consistency — same buttons, same spacing, same colour tokens everywhere. Consistency is the easy half. The system only gets interesting at the edges, when a real product meets a case the documentation didn’t foresee: the destructive action that needs more weight, the dense table on a narrow phone, the brand colour that fails contrast on the surface it’s supposed to sit on.

Those moments are the system’s exam. Done well, the exception becomes a documented pattern and the system grows. Done badly — the team waits three sprints for an answer, then styles it inline and never tells anyone — and the system quietly stops being the source of truth.

Two kinds of exception

In practice I sort them into two buckets. Genuine new cases — a component that doesn’t exist yet, a state the tokens never anticipated — belong back in the system, designed properly. One-off noise — a spacing value that’s slightly off, a colour chosen to match a screenshot — usually means a gap in the tokens, not a gap in the rules.

The useful question is never “can we bend the rule?”. It’s “what does this exception tell us the rule is missing?” The first answer produces an inline style. The second produces a changelog entry.

A small example

Focus rings look like a solved problem until you test one on a dark surface. The token that passes AA on paper is invisible on ink:

/* the rule */
.button:focus-visible {
  outline: 2px solid var(--accent);
  outline-offset: 2px;
}

/* the exception — dark on dark is invisible */
.dark-panel .button:focus-visible {
  outline-color: var(--paper);
  box-shadow: 0 0 0 4px color-mix(in oklch, var(--accent) 55%, transparent);
}
/* focus is a feature, not a checkbox */

Neither line is wrong. The system is wrong only if it pretends the second case doesn’t exist — or if it solves it with a one-off and never writes it down.

That’s the standard I’m holding this site to as I rebuild it: the accessibility bar is a feature, documented and demonstrated, not a compliance afterthought. If the system can’t absorb its own exceptions gracefully, it isn’t finished — it’s just young.