ZooLab

2 July 2026 · 8 min

Design systems that survive contact with product

Most design systems die the same way: built for the design team, not for the people shipping features on a Friday.

Most design systems die the same way. Someone builds a beautiful, comprehensive artefact for the design team, and it sits just far enough from how features actually get built that everyone routes around it the moment a deadline appears.

The system is the code

If the real version of a component lives somewhere the engineers do not work, it will drift. Quietly at first, then all at once, until the design file is a museum of a past state. Treat the implemented component as the system and the design file as a window onto it.

Fewer components, more tokens

Forty components and no token layer is a liability with a nice thumbnail. Twelve components and a well-argued token layer covers more ground and survives a rebrand without anyone crying. Tokens compose. Components multiply.

Make the easy path the right one

Adoption is not a communication problem, and no amount of documentation fixes it. If using the system is slower than not using it, people will not use it. That is not stubbornness, it is arithmetic. Optimise the first five minutes and the rest tends to follow.