Почему дизайн-система — это не просто библиотека кнопок

Многие думают, что дизайн-система — это набор нарисованных кнопок в Figma. На самом деле это инфраструктура: правила, компоненты и документация, которые позволяют команде создавать продукт без хаоса.

Представь: у тебя сайт на 50 страниц. На одной кнопка #2563EB, на другой — #2664EC, на третьей — ещё чуть светлее. Все думали, что используют один синий. Никто не проверял. Дизайн-система решает именно это.

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

Токены — фундамент всего

Дизайн-токены — это переменные для визуальных свойств. Не просто «синяя кнопка», а color.primary.500 = #2563EB. Токен — это имя плюс значение.

Зачем нужны токены:

  • Меняешь цвет в одном месте — он обновляется везде
  • Легко переключать темы (светлая/тёмная)
  • Дизайн и код синхронизированы

Основные категории токенов:

Цвета. Строятся в палитры: от 50 до 900 для каждого цвета. color.gray.100 — почти белый, color.gray.900 — почти чёрный. Поверх палитры — семантические токены: color.background.primary, color.text.muted, color.border.default. Семантические токены — это не конкретные цвета, а их назначение. Именно они переключаются при смене темы.

Типографика. font.size.sm = 14px, font.size.md = 16px, font.weight.semibold = 600, line-height.normal = 1.5. Если у тебя сейчас 12 разных размеров текста на сайте — типографические токены это исправят.

Отступы. Обычно используют кратные значения: 4, 8, 12, 16, 24, 32, 48, 64. Токены: spacing.2 = 8px, spacing.4 = 16px и так далее. Это и есть шаг сетки.

Скругления, тени, анимации. border.radius.md = 8px, shadow.sm = 0 1px 2px rgba(0,0,0,.05), duration.fast = 150ms.

Токены хранят в JSON, CSS-переменных или SCSS — зависит от стека. Для Figma — Variables, появившиеся в 2023 году. Для кода хорошо работает Style Dictionary от Amazon: пишешь один JSON, он генерирует CSS, SCSS, JS, Android, iOS одновременно.

{
  "color": {
    "primary": {
      "500": { "value": "#2563EB" }
    }
  },
  "spacing": {
    "4": { "value": "16px" }
  }
}

Компоненты: от атомов к страницам

Компоненты строятся по принципу атомарного дизайна. Методологию предложил Брэд Фрост в 2013 году, и она до сих пор актуальна.

Атомы — минимальные элементы: кнопка, текстовое поле, иконка, бейдж, чекбокс. Их нельзя разделить без потери смысла.

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

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

Шаблоны и страницы — конкретные экраны, собранные из организмов.

Чем дальше вниз по иерархии — тем меньше переиспользуется и тем больше зависит от контекста конкретного продукта.

Что должен содержать компонент

Возьмём кнопку — самый базовый компонент.

Варианты:

  • По виду: primary, secondary, ghost, destructive
  • По размеру: sm, md, lg
  • По состоянию: default, hover, active, disabled, loading

Это уже 4 × 3 × 5 = 60 комбинаций. Все они должны быть нарисованы в Figma и реализованы в коде.

Пропсы (для разработчиков):

interface ButtonProps {
  variant: 'primary' | 'secondary' | 'ghost' | 'destructive';
  size: 'sm' | 'md' | 'lg';
  disabled?: boolean;
  loading?: boolean;
  onClick?: () => void;
  children: React.ReactNode;
}

Правила использования:

  • Primary кнопка на экране — только одна
  • Destructive — только для необратимых действий (удалить аккаунт, отменить заказ)
  • Loading-состояние показывает спиннер и блокирует повторный клик

Именно третий пункт — правила использования — и есть документация.

Документация — та часть, которую всегда пропускают

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

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

  1. Описание — что это и зачем
  2. Примеры — живые, интерактивные или хотя бы скриншоты
  3. Пропсы / варианты — таблица с типами и дефолтными значениями
  4. Do / Don't — конкретные примеры правильного и неправильного использования
  5. Доступность — какие ARIA-атрибуты нужны, как работает с клавиатурой

Инструменты для документации:

Storybook — стандарт для frontend. Компонент живёт в коде, документация генерируется из него же. Можно переключать пропсы прямо в браузере. Интегрируется с Figma через плагин.

Notion / Confluence — для высокоуровневой документации: принципы, процессы, гайдлайны по голосу бренда.

Zeroheight / Supernova — специализированные инструменты для дизайн-систем. Тянут компоненты из Figma и код из Storybook, собирают в единый портал. Удобно, но стоит денег.

Для небольшой команды (2-5 человек) обычно хватает Storybook плюс несколько страниц в Notion.

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

Это честный вопрос. Дизайн-система требует времени на создание и поддержку.

Нужна, если:

  • Команда больше трёх человек (хотя бы один дизайнер и двое разработчиков)
  • Продукт будет развиваться больше года
  • Несколько продуктов используют один бренд
  • Регулярно возникают вопросы «а как тут должна выглядеть кнопка?»

Не нужна прямо сейчас, если:

  • Лендинг или сайт-визитка без планов на рост
  • MVP, которое нужно проверить за две недели
  • Команда из одного человека

Для лендинга дизайн-система — overkill. Но даже там стоит определить цвета и типографику в CSS-переменных. Это занимает час и сэкономит время при правках.

Как начать строить дизайн-систему

Частая ошибка — начинать с нуля. Строить систему лучше из того, что уже есть.

Шаг 1: Аудит. Пройдись по всем экранам и выпиши все уникальные значения: сколько разных размеров текста, сколько цветов, сколько вариантов кнопок. Обычно оказывается 15 размеров текста вместо 6 и 30 оттенков серого вместо 5.

Шаг 2: Токены. Определи базовые токены — цвета, типографику, отступы. Не более 8-10 размеров текста, не более 10 оттенков основного цвета. Ограничивать — это нормально.

Шаг 3: Базовые компоненты. Начни с тех, что используются везде: кнопка, input, link, badge, avatar. Потом — карточки, навигация, модальные окна.

Шаг 4: Документация параллельно. Не «сначала сделаем компоненты, потом опишем». Описывать надо сразу, пока ещё помнишь, почему принял именно такое решение.

Шаг 5: Внедрение. Новые экраны делаются только из компонентов системы. Старые переводятся постепенно, по приоритету.

Весь процесс до рабочей v1.0 для продукта среднего размера занимает 4-8 недель при выделенном ресурсе.

Figma Variables и токены в 2025-2026

В 2023 году Figma добавила Variables — полноценную поддержку токенов внутри редактора. До этого дизайнеры пользовались плагином Tokens Studio.

Сейчас схема такая:

  • Токены хранятся в Figma Variables или Tokens Studio
  • Через плагин или CI они экспортируются в JSON
  • Style Dictionary конвертирует их в CSS/JS
  • Разработчики используют в коде

Для тёмной темы в Figma создаёшь два мода переменных — Light и Dark. Каждый семантический токен (color.background.primary) имеет значение для каждого мода. Переключение темы в приложении — это просто смена атрибута data-theme на элементе html. Никаких дублирующих стилей.

Поддержка и версионирование

Дизайн-система — живой продукт. Компоненты меняются, появляются новые, устаревшие помечаются как deprecated.

Несколько правил:

  • Версионируй как библиотеку: semver (1.0.0, 1.1.0, 2.0.0)
  • Breaking changes — только в мажорной версии
  • Держи changelog: что изменилось, что удалили, как мигрировать
  • Не удаляй компоненты сразу — сначала deprecated, потом удаляй в следующей мажорной версии

Если система подключена как npm-пакет (для серьёзных продуктов это норма), команды могут оставаться на старой версии и обновляться в своём темпе.

Что это даёт на практике

Возьмём конкретный кейс. Продуктовая команда без дизайн-системы добавляет новый экран примерно 3-4 дня. Дизайнер рисует с нуля или копирует из старых макетов, разработчик верстает, потом дизайнер замечает, что кнопка не та.

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

Реальная экономия по разным оценкам — от 30% до 60% времени на проектирование и разработку новых фич. Цифры зависят от зрелости продукта и команды.

Когда в REEXY берём в работу корпоративный сайт, первым делом выясняем — есть ли у клиента брендбук или хотя бы базовые гайдлайны. Если есть, на их основе сразу строится мини-система токенов. Это позволяет масштабировать сайт в будущем без переделки с нуля.

Частые ошибки

Слишком много компонентов сразу. Начать с 200 компонентов — значит потратить полгода и так и не выпустить v1. Начни с 20 самых нужных.

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

Документация отдельно от компонентов. Если документация живёт в Confluence, а компоненты — в Storybook, они рассинхронизируются за месяц. Лучше, когда документация генерируется прямо из кода.

Игнорировать доступность. Компоненты должны работать с клавиатурой и скринридерами. Это не опция — это базовое требование для любого продукта.

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

Дизайн-система — инвестиция. В первые месяцы она требует времени, зато потом возвращает его с запасом: быстрее фичи, меньше багов, новые люди в команде быстрее входят в контекст. Главное — не пытаться построить идеальную систему с первого раза. Начни с малого, используй, улучшай по ходу.