<b>Design system ломается не в Figma — а в момент, когда компоненту дают жить без правил</b>

<b>Design system ломается не в Figma — а в момент, когда компоненту дают жить без правил</b>

Если в системе есть кнопки, карточки и инпуты, но нет договорённости, <i>когда</i> их использовать, это не design system, а библиотека макетов.

Что должно быть у каждого компонента:
— назначение: какую задачу он решает
— состояния: default, hover, focus, disabled, error, loading
— ограничения: где нельзя использовать
— контекст: в каких экранах и сценариях он уместен

Самая частая ошибка — описывать только внешний вид. Тогда дизайнеры начинают собирать интерфейс по интуиции, а разработка получает разные трактовки одного и того же элемента.

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

Что делать на практике:
1) Для каждого компонента добавьте короткое описание “зачем он нужен”.
2) Зафиксируйте запрещённые сценарии.
3) Пропишите поведение для клавиатуры, фокуса и ошибок.
4) Дайте примеры “можно” и “нельзя”.

Хорошая система экономит не пиксели, а обсуждения. Чем меньше у команды поводов гадать, тем стабильнее интерфейс.