Дизайн-система ломается не в UI — а в решениях, которые в ней не описали

Дизайн-система ломается не в UI — а в решениях, которые в ней не описали

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

Что важно:
— у каждого компонента есть цель, состояние, ограничения и когда его не использовать;
— токены отвечают не за «красиво», а за повторяемость: отступы, цвета, типографика, радиусы;
— у каждого паттерна должен быть владелец: кто меняет, кто согласует, кто отвечает за документацию.

Типовая ошибка — описывать только «как выглядит» и забывать «как работает». В итоге кнопка есть, а сценарий ошибки, загрузки, disabled-состояния и поведение в длинных текстах — каждый продукт решает по-своему. Так и появляется зоопарк интерфейсов внутри одной команды.

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

Если в системе нет правил принятия решений, это не design system, а каталог UI.