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

Дизайн-система решает именно эту проблему — не красоту ради красоты, а консистентность и скорость. Когда всё описано один раз и живёт в одном месте, команда перестаёт тратить время на споры «какой отступ правильный» и начинает делать продукт.

Что вообще такое дизайн-система

Дизайн-система — это не файл в Figma и не библиотека компонентов в коде. Это всё вместе: визуальный язык продукта, набор переиспользуемых блоков и документация, которая объясняет, как всем этим пользоваться.

Состоит из трёх слоёв:

Токены — базовые переменные: цвета, шрифты, отступы, радиусы, тени. Это атомы системы.

Компоненты — кнопки, инпуты, карточки, навбары. Строятся из токенов и содержат логику поведения.

Документация — объясняет, когда и как использовать каждый компонент, какие состояния у него есть, что нельзя делать.

Без документации система быстро умирает: люди не понимают правила, нарушают их, потом берут «похожий компонент» и переделывают под себя. Через полгода снова хаос.

Токены — это не просто переменные

Многие путают токены с CSS-переменными. Разница принципиальная: CSS-переменная — техническая деталь, токен — семантическая единица. Токен несёт смысл.

Сравни:

--color-blue-500: #3B82F6;        /* это просто цвет */
--color-action-primary: #3B82F6;  /* это токен — цвет основного действия */

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

Стандартная структура токенов выглядит так:

Примитивы — сырые значения. blue-500, gray-100, spacing-4. Не используются напрямую в интерфейсе.

Семантические токены — привязаны к роли. color-text-primary, color-background-danger, spacing-component-padding. Используются в компонентах.

Компонентные токены — специфичны для конкретного элемента. button-primary-background, input-border-radius. Опциональный слой, нужен в больших системах.

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

Популярный инструмент для работы с токенами — Style Dictionary от Amazon. Он берёт токены из JSON и генерирует переменные для любой платформы: CSS, iOS, Android, Flutter. Один источник правды, разные выходные форматы.

Компоненты: анатомия и состояния

Компонент в дизайн-системе — это не просто нарисованная кнопка. Это объект со свойствами и состояниями.

Возьмём обычную кнопку. Свойства:

  • Вариант: primary, secondary, ghost, danger
  • Размер: small, medium, large
  • Иконка: слева, справа, без иконки
  • Disabled: да/нет
  • Loading: да/нет

Состояния:

  • Default
  • Hover
  • Active (pressed)
  • Focus
  • Disabled
  • Loading

Итого: 3 варианта × 3 размера × 3 позиции иконки × 2 состояния disabled × 2 состояния loading = 108 комбинаций. Нарисовать все — нереально. Но описать логику — обязательно.

В Figma компоненты строятся через Auto Layout и Variables. Variables — это и есть реализация токенов внутри Figma. Если правильно связать компонент с переменными, переключение темы происходит в один клик.

В коде компонент описывается через пропсы. React-пример:

<Button
  variant="primary"
  size="medium"
  iconLeft={<SearchIcon />}
  loading={isSubmitting}
  disabled={!isValid}
  onClick={handleSubmit}
>
  Отправить
</Button>

Компонент в коде и компонент в дизайне должны иметь одинаковые названия пропсов. Если в Figma это называется variant, а в коде type — разработчик теряет время на перевод. Это мелочь, которая за год съедает несколько рабочих дней.

Как организовать библиотеку компонентов

Атомарный дизайн Брэда Фроста — хорошая отправная точка, но не догма. Суть: компоненты делятся по уровню сложности.

Атомы — базовые элементы: кнопка, инпут, текст, иконка, аватар.

Молекулы — комбинации атомов: поле поиска (инпут + кнопка), карточка товара (изображение + заголовок + цена + кнопка).

Организмы — сложные блоки: хедер, форма регистрации, список товаров.

Шаблоны — страничные раскладки без реального контента.

Страницы — шаблоны с реальным контентом.

На практике команды часто упрощают: атомы, компоненты, паттерны. Три уровня достаточно для большинства проектов.

Важный принцип: компонент должен делать одну вещь хорошо. Если кнопка начинает знать о данных из API — это уже не компонент системы, это бизнес-логика. Смешивать не стоит.

Документация: зачем и как писать

Документация — это то, что отличает дизайн-систему от набора компонентов. Без неё система не масштабируется.

Хорошая документация для компонента содержит:

Описание — что это и зачем. Одно-два предложения, без общих слов.

Когда использовать — конкретные сценарии. «Используй primary-кнопку для главного действия на экране. Таких кнопок должна быть одна."

Когда не использовать — anti-patterns. «Не используй disabled-кнопку, если не показываешь причину. Пользователь не понимает, что делать дальше."

Примеры — живые, интерактивные. Storybook стал стандартом де-факто для документирования React-компонентов. Пишешь story, получаешь интерактивный каталог с пропсами.

Доступность — какие ARIA-атрибуты нужны, как работает с клавиатурой.

API — таблица пропсов с типами и значениями по умолчанию.

Популярные инструменты для документации: Storybook (для кода), Zeroheight или Supernova (для связки Figma + код), самописный статический сайт на Astro или Next.js.

Zeroheight стоит от $149/месяц за команду, Supernova — от $199. Если бюджета нет, Storybook бесплатен и покрывает 80% потребностей.

Токены и код: как синхронизировать дизайн и разработку

Главная боль — рассинхронизация. Дизайнер меняет токен в Figma, разработчик не знает. Или наоборот.

Решение — единый источник токенов. Варианты:

Tokens Studio для Figma — плагин, который хранит токены в JSON и синкает с GitHub. Разработчики берут JSON, прогоняют через Style Dictionary, получают переменные для любой платформы. Бесплатная версия покрывает базовые нужды.

Figma Variables + REST API — нативный способ. С 2023 года Figma открыла API для Variables. Можно написать скрипт, который в CI экспортирует переменные из Figma и обновляет токены в репозитории.

Ручной процесс — таблица в Notion или Google Sheets, откуда разработчик берёт значения. Плохо масштабируется, но работает для маленьких команд.

Идеальный флоу: дизайнер меняет токен в Figma → плагин пушит в GitHub → CI прогоняет Style Dictionary → токены обновляются в продакшн-репозитории → разработчик получает PR с изменениями.

С чего начать: минимальная дизайн-система

Не нужно строить Google Material Design с нуля. Минимальная система, которая уже приносит пользу:

Шаг 1. Цветовые токены. Зафиксируй палитру: первичный цвет, вторичный, фоны, тексты, статусные цвета (success, warning, error, info). 20-30 токенов — уже порядок.

Шаг 2. Типографика. Размеры заголовков (h1-h6), размер тела, подписи. Межстрочные интервалы. Шрифтовые начертания. Сохрани как текстовые стили в Figma и CSS-переменные в коде.

Шаг 3. Отступы. Шкала из 8 значений на базе 4px: 4, 8, 12, 16, 24, 32, 48, 64. Этого хватает для 95% случаев.

Шаг 4. Базовые компоненты. Кнопка, инпут, чекбокс, радио, тег, бейдж, аватар. Не больше — остальное добавишь по мере необходимости.

Шаг 5. Документация. Хотя бы Notion-страница с правилами использования. Потом можно перенести в Storybook.

Весь этот минимум реально собрать за 2-3 недели, если есть один дизайнер и один фронтендер с опытом.

Когда дизайн-система нужна, а когда нет

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

  • Над проектом работают 3+ человека
  • У продукта больше 10-15 экранов
  • Продукт будет развиваться дольше года
  • Есть несколько платформ (веб + мобильное приложение)

Для лендинга из пяти секций или сайта-визитки дизайн-система избыточна. Там достаточно аккуратного Figma-файла с общими стилями.

Когда в REEXY делают корпоративный сайт (от 15 000 ₽) или интернет-магазин (от 10 000 ₽), базовые дизайн-токены закладываются в проект по умолчанию — это не усложняет работу, а наоборот, ускоряет внесение правок и будущее масштабирование.

Что идёт не так

Несколько типичных ошибок, которые убивают дизайн-системы:

Документацию пишут последней. Компоненты есть, документации нет. Никто не знает правил. Система не работает. Документацию надо писать параллельно с компонентами.

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

Слишком жёсткие правила. Система должна решать задачи, а не ограничивать. Если правило мешает сделать хороший продукт — правило надо менять, а не ломать продукт.

Разработчики и дизайнеры живут отдельно. Дизайнер строит систему в Figma, разработчик строит свою в коде. Синхронизации нет. Это не дизайн-система, а два параллельных мира.

Готовые системы как отправная точка

Если строить с нуля нет ресурсов, можно взять готовую систему и адаптировать под себя.

Material Design 3 — от Google. Хорошая документация, компоненты для веба и Android, поддержка токенов и темизации.

Ant Design — популярен в B2B и enterprise. React-компоненты, богатая библиотека.

shadcn/ui — не библиотека, а набор компонентов, которые копируешь к себе в проект. Tailwind + Radix UI. Очень гибко, сейчас один из самых популярных подходов.

Radix Primitives — несинованные компоненты с правильной доступностью. Строишь стилизацию сам.

Взять готовую систему — хорошее решение для старта. Но помни: адаптация под бренд всё равно потребует времени.