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

Дизайн-система решает именно это. Она описывает, как выглядит интерфейс и как он работает — один раз, для всей команды.

Что такое дизайн-система на самом деле

Часто путают три вещи: UI-кит, стайлгайд и дизайн-систему. Разница принципиальная.

UI-кит — это набор готовых компонентов в Figma. Кнопки, инпуты, карточки. Красиво, но статично.

Стайлгайд — документ с цветами, шрифтами и правилами использования логотипа. Полезно, но недостаточно.

Дизайн-система — это живой продукт. Она включает дизайн-токены, библиотеку компонентов в коде, документацию и процесс поддержки всего этого. Главное слово — живой. Если систему не обновляют, она умирает за три месяца.

Хорошие примеры: Material Design от Google, Ant Design, Atlassian Design System. Они открыты, и на них стоит смотреть не чтобы копировать, а чтобы понять структуру.

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

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

Выглядит примерно так:

--color-primary: #2563EB;
--spacing-md: 16px;
--radius-button: 8px;
--font-size-body: 16px;

Почему это важно? Представьте: у вас 40 экранов, и клиент говорит «поменяйте акцентный цвет с синего на зелёный». Без токенов — это ручная замена в сотнях мест. С токенами — одна строчка.

Токены делят на три уровня:

Примитивные (primitive) — сырые значения. blue-500: #2563EB, space-4: 16px. Никакой семантики, только значения.

Семантические (semantic) — значение с контекстом. color-action-primary: {blue-500}, spacing-component-gap: {space-4}. Вот тут уже понятно, где и зачем.

Компонентные (component) — токены конкретного компонента. button-background: {color-action-primary}, button-padding-horizontal: {spacing-component-gap}.

Такая иерархия позволяет менять тему (например, светлая / тёмная) через один уровень, не трогая компоненты.

Формат хранения токенов — обычно JSON или YAML. Популярный инструмент — Style Dictionary от Amazon: берёт JSON с токенами и генерирует CSS-переменные, SCSS, Swift-константы, Android XML — что угодно.

Компоненты: что включать и как организовать

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

Типичная структура библиотеки компонентов:

  • Базовые: кнопка, инпут, чекбокс, радио, селект, переключатель
  • Типографика: заголовки h1–h6, body, caption, code
  • Навигация: хлебные крошки, табы, пагинация, меню
  • Обратная связь: алерты, тосты, спиннеры, прогресс-бары
  • Контейнеры: карточка, модальное окно, дровер, аккордеон
  • Данные: таблица, список, бейдж, тег

Не нужно строить всё сразу. Начните с того, что используется в каждом проекте: кнопка, инпут, карточка, сетка. Это даст 80% пользы при 20% усилий.

Каждый компонент должен иметь:

  • Чёткое API (пропсы, варианты, состояния)
  • Документацию с примерами
  • Тесты — хотя бы snapshot
  • Accessibility-атрибуты (aria-label, role и т.д.)

По поводу состояний — это часто забывают. Кнопка бывает: default, hover, active, focus, disabled, loading. Инпут: default, focused, filled, error, disabled. Если состояния не описаны — дизайнер нарисует одно, разработчик додумает остальное. Несоответствия гарантированы.

Атомарный дизайн: полезная метафора

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

Суть: интерфейс строится как химия.

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

Практическая польза: когда меняется атом (например, скругление кнопки), изменение автоматически распространяется на все молекулы и организмы. Не нужно бегать по всем экранам.

Документация: живая, а не мёртвая

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

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

  1. Что это? Название, описание, когда использовать
  2. Как это выглядит? Живые примеры, а не скриншоты
  3. Как это использовать? Код, пропсы, ограничения

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

Storybook — стандарт для React, Vue, Angular. Каждый компонент живёт в изоляции, можно крутить пропсы, смотреть состояния. Интегрируется с Figma через плагины.

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

Docusaurus / VitePress — опенсорс, если хочется полного контроля и хостинга на своих серверах.

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

JSDoc-комментарии + TypeScript-типы + Storybook stories = документация, которую не нужно поддерживать вручную.

Версионирование и изменения

Дизайн-система — это публичное API для вашей команды. Значит, нужно версионирование.

Семантическое версионирование (semver) здесь работает отлично:

  • Patch (1.0.1) — фикс бага, не ломает ничего
  • Minor (1.1.0) — новый компонент или фича, обратно совместимо
  • Major (2.0.0) — breaking changes, нужна миграция

Перед major-версией пишется migration guide: что изменилось, что устарело (deprecated), как перейти. Без этого команда проигнорирует обновление и будет сидеть на старой версии.

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

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

Большая ошибка — начинать с идеальной архитектуры. Надо начинать с аудита.

Шаг 1. Инвентаризация. Пройдитесь по всем экранам и выпишите повторяющиеся элементы. Сколько видов кнопок? Сколько цветов используется? Какие отступы встречаются чаще всего?

Шаг 2. Нормализация. Выберите один вариант для каждого элемента. Не 7 оттенков синего, а 3. Не 12 размеров шрифта, а 6.

Шаг 3. Токены. Зафиксируйте нормализованные значения в токенах. Пока без кода — можно в таблице.

Шаг 4. Базовые компоненты. Реализуйте 5-7 самых используемых компонентов. Кнопка, инпут, типографика, цвета, сетка.

Шаг 5. Документация первого уровня. Storybook с примерами. Даже без подробных описаний — просто чтобы компоненты были видны.

Шаг 6. Внедрение. Начните использовать систему в новых фичах. Не рефакторьте всё сразу — это провальная стратегия.

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

Figma и код: как не допустить расхождения

Самая частая проблема: дизайнер обновил компонент в Figma, разработчик не знает об этом, в продакшне старая версия.

Решения:

Figma Variables (появились в 2023) — это токены прямо в Figma. Можно экспортировать в JSON и использовать в Style Dictionary. Пока инструментарий сырой, но вектор правильный.

Tokens Studio (плагин для Figma) — зрелый инструмент для работы с токенами. Синхронизируется с GitHub, можно настроить автоматический PR при изменении токена.

Design handoff через Storybook — дизайнер смотрит не на макеты, а на живые компоненты. Если что-то не совпадает, заводится тикет. Это меняет культуру: разработчик и дизайнер смотрят на один источник правды.

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

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

Честный ответ: не всегда.

Если у вас один лендинг или небольшой корпоративный сайт — дизайн-система избыточна. Достаточно базовых переменных в CSS и аккуратного кода.

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

Дизайн-система оправдывает себя при:

  • Нескольких продуктах в одной экосистеме
  • Команде от 3-4 человек (дизайн + фронтенд)
  • Проекте с горизонтом жизни от года
  • Частых обновлениях интерфейса

Поддержка: кто за это отвечает

Дизайн-система — это продукт внутри продукта. Ей нужен владелец.

Модели разные:

Централизованная — выделенная команда (platform team) владеет системой, остальные используют. Работает в крупных компаниях.

Федеративная — каждая команда вносит вклад, кто-то координирует. Подходит для среднего бизнеса.

Соло — один человек отвечает за систему как часть своих обязанностей. Реалистично для небольших студий и стартапов.

Главное — чтобы кто-то это делал. Система без владельца деградирует быстро.

Расходы на поддержку — это инвестиция. Команда из 5 разработчиков, которая тратит 2 часа в неделю на поддержку системы, экономит 20+ часов в месяц на разногласиях, рефакторинге и исправлении визуальных несоответствий. Математика простая.

Что почитать и посмотреть

Если хочется погрузиться глубже:

  • atomicdesign.bradfrost.com — книга Брэда Фроста, бесплатно онлайн
  • storybook.js.org/docs — документация Storybook, там же примеры крупных систем
  • designsystemchecklist.com — чеклист из 74 пунктов для аудита системы
  • superfriendlydesign.com/articles — статьи о процессах построения систем

И да — смотрите на открытые системы: Material, Ant, Carbon (IBM), Primer (GitHub). Там можно подсмотреть не только компоненты, но и то, как они структурируют документацию и принимают решения.