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

Но «набор правил» звучит слишком просто. На практике дизайн-система — это живой продукт: он проектируется, поддерживается и эволюционирует. Разберём, из чего он состоит.

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

Дизайн-система — это три слоя.

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

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

Дизайн-токены: не просто переменные

Токен — это имя для значения. Вместо #1A73E8 вы пишете color.primary.500. Вместо 16px — spacing.md. Звучит как мелочь, но это меняет всё.

Главная сила токенов — в семантике. Есть два уровня:

Примитивные токены — сырые значения палитры:

color.blue.100 = #E8F0FE
color.blue.500 = #1A73E8
color.blue.900 = #174EA6

Семантические токены — смысловые псевдонимы:

color.action.primary = color.blue.500
color.action.primary.hover = color.blue.700

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

То же самое с типографикой:

font.size.body = 16px
font.size.caption = 12px
font.weight.medium = 500
line-height.tight = 1.25

И с отступами. Обычно берут шкалу кратную 4: 4, 8, 12, 16, 24, 32, 48, 64. Называют её spacing.xs, spacing.sm, spacing.md и так далее. Это убирает дискуссии «тут 14px или 16px?» — просто используешь spacing.sm и не думаешь.

Форматы хранения токенов

Токены можно хранить в JSON, YAML, CSS-переменных или в Figma Variables. Популярный стандарт — W3C Design Tokens Format, он позволяет генерировать из одного файла CSS, iOS Swift, Android Kotlin и что угодно ещё через Style Dictionary от Amazon.

Пример JSON-токена по стандарту W3C:

{
  "color": {
    "primary": {
      "500": {
        "$value": "#1A73E8",
        "$type": "color"
      }
    }
  }
}

Style Dictionary берёт это и генерирует:

  • --color-primary-500: #1A73E8 для CSS
  • colorPrimary500 как константу для Swift
  • аналог для Android

Один источник правды — три платформы.

Компоненты: атомы, молекулы, организмы

Атомная методология Брэда Фроста делит интерфейс на уровни:

  • Атомы — кнопка, инпут, иконка, лейбл
  • Молекулы — поле поиска (инпут + кнопка + иконка)
  • Организмы — шапка сайта (логотип + навигация + поле поиска)
  • Шаблоны — страница без реального контента
  • Страницы — шаблон с реальным контентом

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

Как устроен хороший компонент

Возьмём кнопку — самый очевидный пример.

Плохая кнопка в дизайн-системе — это один вариант с фиксированным цветом и размером.

Хорошая кнопка — это:

  • Варианты (variant): primary, secondary, ghost, destructive
  • Размеры (size): sm, md, lg
  • Состояния (state): default, hover, focus, active, disabled, loading
  • Слоты: иконка слева, иконка справа, только иконка

Для разработчика это выглядит так:

<Button
  variant="primary"
  size="md"
  leftIcon={<PlusIcon />}
  isLoading={isSubmitting}
>
  Создать проект
</Button>

Каждое свойство документировано, каждое состояние нарисовано в Figma и покрыто в коде.

Состояния — самое важное, что забывают

Начинающие дизайн-системы часто рисуют только default-состояние. Потом разработчик спрашивает: «А как выглядит кнопка при загрузке?» — и дизайнер говорит «ну сделай что-нибудь». Это конец консистентности.

Для каждого интерактивного компонента нужно прорисовать минимум:

  • default
  • hover
  • focus (отдельно! для клавиатурной навигации и доступности)
  • active (момент нажатия)
  • disabled
  • error/success — если компонент может быть в таком состоянии

Для инпутов добавляется ещё filled (заполнен) и, часто, read-only.

Документация: без неё система не живёт

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

Что должно быть в документации компонента

1. Когда использовать — и когда не использовать. Это важнее всего. Например:

Primary-кнопка — для главного действия на экране. Не используй больше одной primary-кнопки в одном визуальном блоке.

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

3. Живые примеры — не скриншоты, а интерактивные. Storybook решает это идеально: вы видите компонент, можете менять пропсы в реальном времени и копировать код.

4. Доступность (a11y) — какой role у элемента, какие aria-атрибуты нужны, как он ведёт себя при навигации с клавиатуры.

5. Дизайн-решения — почему сделано именно так. Это ценнейшая часть, которую почти никто не пишет. «Мы сделали минимальный тач-таргет 44px, потому что Apple HIG и Google Material требуют этого для мобильных устройств» — такая строчка экономит часы дискуссий.

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

Storybook — стандарт де-факто для компонентных библиотек. Изолирует компоненты, позволяет писать истории (stories) для каждого состояния, генерирует документацию из JSDoc-комментариев.

Zeroheight / Supernova — инструменты, которые связывают Figma с документацией. Токены и компоненты из Figma синхронизируются с сайтом документации автоматически.

Notion / Confluence — для принципов, гайдлайнов по тону голоса, правил именования. Не для технической документации компонентов, но для «философии» системы — самое то.

GitHub Wiki — если команда маленькая и не хочет платить за Zeroheight. Markdown, версионирование, интеграция с кодом.

Именование: договориться важнее, чем выбрать «правильно»

Единого стандарта именования токенов нет. Есть несколько популярных конвенций:

  • Category-Type-Item-Subitem: color-background-button-primary
  • Namespace: ds-color-primary-500
  • Figma Variables: Colors/Primary/500

Неважно, какую вы выберете. Важно выбрать одну и следовать ей везде. Смешение конвенций — это когда buttonPrimaryBg в одном месте и btn-primary-background в другом. Это убивает поиск и понимаемость.

То же самое с компонентами. Если решили называть InputField — не пишите в другом месте TextInput для того же компонента.

Versioning и изменения: как не сломать всё

Дизайн-система — продукт для других команд. Если вы внезапно меняете интерфейс компонента, вы ломаете чужой код. Поэтому нужна версионность по SemVer:

  • Patch (1.0.1): исправление бага, визуальный фикс без изменения API
  • Minor (1.1.0): новый компонент, новый вариант существующего, обратно совместимо
  • Major (2.0.0): breaking change — изменили пропсы, удалили компонент, переименовали токен

Перед major-версией пишется deprecation notice: «В версии 2.0 prop type будет переименован в variant. Используйте variant уже сейчас.» Даёте командам время адаптироваться.

Changelog — обязателен. Не «фиксы и улучшения», а конкретно: «Кнопка: добавлен вариант ghost. Токен color.action.secondary переименован в color.action.ghost — обновите импорты».

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

Это честный разговор, который редко ведут.

Дизайн-система нужна, если:

  • У вас больше двух продуктов, которые должны выглядеть одинаково
  • Команда дизайнеров больше двух человек
  • Интерфейс активно развивается, компонентов становится больше
  • Есть мобильное приложение и веб, и они должны быть консистентны

Дизайн-система, скорее всего, лишняя, если:

  • Вы делаете один лендинг или сайт-визитку
  • Команда — один дизайнер и один разработчик
  • Продукт не будет сильно меняться после запуска

Для малого бизнеса, которому нужен корпоративный сайт или лендинг, дизайн-система — это оверинжиниринг. Достаточно хорошо продуманных стилей и компонентного подхода в коде. Веб-студия REEXY, например, при разработке сайтов использует компонентный подход и переменные для токенов — без избыточной инфраструктуры, которая увеличила бы стоимость и сроки.

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

Не пытайтесь сразу сделать всё. Это главная ошибка.

Шаг 1. Аудит существующего. Соберите все цвета, шрифты, кнопки, которые уже есть в продукте. Скорее всего обнаружите 12 оттенков серого и 5 вариантов кнопок. Это исходная точка.

Шаг 2. Определите токены. Сначала цвета и типографика. Запишите их — хотя бы в Figma Styles или Variables.

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

Шаг 4. Внедрите в проект. Замените хардкодные значения на токены. Замените «самописные» кнопки на компонент из библиотеки.

Шаг 5. Итерируйте. Добавляйте компоненты по мере необходимости, не заранее. Не нужно рисовать 80 компонентов, из которых используется 20.

По опыту — первые рабочие версии токенов и трёх базовых компонентов с документацией занимают от двух до четырёх недель у команды из одного дизайнера и одного разработчика. После этого скорость разработки новых фич заметно растёт.

Figma и код: синхронизация без боли

Самая частая проблема: в Figma одно, в коде другое. Дизайнер поменял радиус кнопки с 8px до 6px — разработчик не знает. Разработчик добавил новый вариант в код — дизайнер рисует макеты со старой версией.

Решения:

Figma Variables + Style Dictionary. Экспортируете токены из Figma в JSON через плагин (Token Flow, Tokens Studio), Style Dictionary генерирует CSS/JS. Токены всегда синхронизированы.

Storybook + Figma плагин. Плагин «Storybook Connect» показывает прямо в Figma, как компонент выглядит в коде. Дизайнер видит реальный компонент, не скриншот.

Автоматические PR. При изменении токенов в Figma через CI/CD автоматически создаётся pull request с обновлёнными переменными. Разработчик видит, что изменилось, и мёрджит.

Ни одно из этих решений не идеально. Но даже частичная автоматизация лучше ручной синхронизации.

Метрики успеха дизайн-системы

Как понять, что система работает, а не просто существует?

  • Adoption rate: сколько компонентов в продукте используют системные компоненты, а не «самописные». Цель — больше 80%.
  • Time to design / time to build: время на проектирование нового экрана и время на разработку. Должно сокращаться по мере роста библиотеки.
  • Количество визуальных несоответствий в продакшне — находите их через регулярные UI-аудиты.
  • Satisfaction команды: дизайнеры и разработчики должны хотеть использовать систему, а не обходить её.

Если команда постоянно делает исключения и не использует системные компоненты — это сигнал, что система неудобна или не покрывает реальные потребности. Не люди плохие, система плохая.

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