Design system ломается не в UI-kit, а в правилах применения

Design system ломается не в UI-kit, а в правилах применения

Если в системе есть только кнопки, цвета и отступы — это не design system, а библиотека компонентов. Рабочая система отвечает на три вопроса: где компонент использовать, когда его не использовать и что делать, если сценарий не укладывается в шаблон.

Что должно быть в базе:
— анатомия компонента и варианты состояний
— правила контента: длина, переносы, пустые состояния, ошибки
— токены для цвета, типографики, сетки, motion
— доступность: фокус, контраст, клавиатура, читабельные подписи

Что ломает внедрение:
— дубли компонентов с разными названиями
— “особые случаи” без owner’а
— макеты, которые нарушают ограничения системы ради красоты
— отсутствие примеров, где компонент нельзя применять

Хороший тест на зрелость простой: дизайнер и разработчик открывают документацию и одинаково понимают, как собрать экран без устных договорённостей.

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