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.
01 — Two kindsSorting the exceptions
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.
02 — A small caseFocus rings on ink
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:
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: the accessibility bar is documented and demonstrated, not a compliance afterthought.