<b>Дизайн-система ломается не в UI, а в правилах использования</b>

<b>Дизайн-система ломается не в UI, а в правилах использования</b>

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

Что важно:
— у компонента должен быть <b>смысл</b>, а не только внешний вид;
— у каждого состояния — default, hover, focus, disabled, error — должен быть описан сценарий;
— если паттерн повторяется в 3+ местах, его уже пора вынести в стандарт;
— если правила можно нарушить без последствий, это не правило, а рекомендация.

Частая ошибка — собирать библиотеку как каталог UI-элементов. В результате дизайнеры и разработчики берут один и тот же блок по-разному, а продукт расползается по стилю и поведению.

Что делать на практике:
— описывать не только токены и размеры, но и <b>поведенческие ограничения</b>;
— хранить рядом с компонентом примеры «можно / нельзя»;
— добавлять edge cases: длинный текст, пустое состояние, ошибки ввода, переполнение;
— назначать владельца компонента, который отвечает за его изменения.

Хорошая дизайн-система экономит не пиксели, а решения. Если правила не помогают выбрать вариант быстрее — систему нужно упрощать.