<b>Дизайн-система ломается не в макетах, а в мелких исключениях</b>

<b>Дизайн-система ломается не в макетах, а в мелких исключениях</b>

Если в системе есть кнопки, поля и типографика, но нет правил для состояния, отступов и контекстов, команда всё равно начнёт рисовать «почти такие же» компоненты.

Что обычно забывают:
— disabled, loading, error, success;
— длинные тексты, пустые экраны, переполнение;
— мобильные сценарии, где компонент ведёт себя иначе;
— правила, когда компонент можно менять, а когда нельзя.

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

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

Если компонент нельзя объяснить одной фразой и проверить на крайних состояниях, он ещё не готов для системы.