Почему дизайн-система ломается не в UI, а в правилах её использования

Почему дизайн-система ломается не в UI, а в правилах её использования

Дизайн-система полезна только тогда, когда в ней есть не просто кнопки и сетки, а понятные правила принятия решений. Иначе команда быстро превращает её в склад красивых компонентов, где каждый собирает интерфейс по-своему.

Что должно быть обязательно:
— когда использовать компонент, а когда собирать его вручную;
— какие состояния у элемента считаются обязательными: hover, focus, disabled, error;
— как компонент ведёт себя на длинных текстах, в пустом состоянии и при ошибке;
— кто отвечает за изменения: дизайн, продукт или фронтенд.

Если этого нет, появляются типовые поломки: одинаковые элементы ведут себя по-разному, а документация устаревает быстрее, чем код. Визуальная консистентность держится не на библиотеке, а на договорённости между людьми и командами.

Что делать на практике: для каждого компонента пишите не только внешний вид, но и сценарий использования, ограничения и антипример. Это экономит время сильнее, чем очередной набор новых токенов.

Если в системе нельзя быстро понять «когда и зачем это использовать», это не дизайн-система, а каталог UI.