Дизайн-система ломается не из-за кнопок, а из-за разметки и правил

Дизайн-система ломается не из-за кнопок, а из-за разметки и правил

Если в системе есть библиотека компонентов, но нет общих принципов, она быстро превращается в склад одноразовых паттернов. Команда начинает собирать интерфейсы из похожих, но несовместимых кусочков, а рост продукта делает это только заметнее.

Что обычно проверяют в первую очередь:
— единые токены для отступов, цветов, типографики и состояний;
— понятные правила композиции: где используется сетка, где — автолэйаут, где допустимы исключения;
— описание поведения, а не только внешний вид: загрузка, ошибки, disabled, empty state.

Отдельно смотрите на границы компонента. Если в него можно передать слишком много вариаций, он становится дорогим в поддержке. Если вариантов мало — дизайнеры начинают обходить систему вручную. Здоровый компонент решает одну задачу и имеет предсказуемые входы и выходы.

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

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