The second year is where design systems die

Nobody abandons a design system in the first three months. It happens quietly in month fourteen, when the fastest way to ship is to write one more special case.

A design system is judged on the day someone is in a hurry. If reaching for it is slower than working around it, it will be worked around, and every workaround makes the next one more reasonable. That is the whole failure mode. It is not a tooling problem.

Unfinished components are the leak

The usual artefact is a component drawn in its happy state only. One button, one size, filled with a two-word label written by a designer who knew what it said. Then reality arrives: the label is translated and runs to three lines, the list is empty on a new account, the request fails, the number is null.

None of those were drawn, so each is solved locally by whoever hit it first, and the system now describes a product that does not exist.

A component is not finished when it looks right. It is finished when it cannot be made to look wrong by ordinary data.

What we require before a component is done

• Empty. What a new account sees, with a sentence that tells them what to do next.
• Loading. Including the case where it takes eight seconds, not just the case where it takes eighty milliseconds.
• Error. With a recovery action. “Something went wrong” is not a state, it is an apology.
• Overflow. The longest realistic string, the largest realistic number, and the narrowest supported screen.
• Disabled and focused. Keyboard users are not an accessibility afterthought; they are the people who use it fastest.

Tokens, or it drifts

Colour, type scale and spacing live as one token set that both the design file and the code read from. The point is not tidiness. The point is that a decision made once can be changed once — a contrast fix that lands everywhere in an afternoon instead of being repainted screen by screen over a quarter.

Documented where the work happens

Documentation that lives in a slide deck is documentation nobody opens at 4pm on a Thursday. Ours lives beside the component, in code, with the states rendered so they can be looked at rather than imagined. If a rule cannot be expressed there, it is not a rule, it is a preference.

The honest test

A year in, ask a developer who joined last month to build a screen you did not plan for. If they can assemble it without asking a designer and without writing a special case, the system is alive. If they quietly copy the nearest screen and edit it, you have a folder of components and a product that is drifting.