<b>Дизайн-система ломается не в Figma, а в согласовании между командами</b>

<b>Дизайн-система ломается не в Figma, а в согласовании между командами</b>

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

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

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

Ещё один важный слой — состояния и edge cases. Disabled, loading, error, empty, success, truncation, overflow — это не «добавим потом». Именно в этих состояниях UX чаще всего и разваливается.

Что делать на практике: начните не с количества компонентов, а с трёх вещей — governance, naming и состояния. Если они не описаны, масштабировать систему нельзя.