<b>Design system разваливается не из-за UI, а из-за плохих правил его использования</b>

<b>Design system разваливается не из-за UI, а из-за плохих правил его использования</b>

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

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

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

Что важно: без примеров использования design system быстро превращается в витрину. Команда берёт компонент, потому что он «красивый», а не потому что он решает задачу. Поэтому документация должна показывать не только «как выглядит», но и «когда брать этот вариант».

Что делать на практике: начните не с новых компонентов, а с ревизии 10 самых используемых. Если у них нет правил, именно там и течёт система.

Сильная design system экономит время не дизайна, а согласований.