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

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

Разберём, из чего она состоит и как её построить без лишней бюрократии.

Почему компании приходят к дизайн-системам

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

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

Дизайн-система решает это на уровне инфраструктуры. Раз договорились — и дальше все работают по одним правилам.

Атомарный дизайн: с чего начинается структура

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

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

Молекулы — комбинации атомов. Форма поиска = поле ввода + кнопка. Карточка товара = изображение + заголовок + цена + кнопка.

Организмы — крупные блоки из молекул. Шапка сайта, блок с тарифами, список карточек.

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

Страницы — финальный вариант с настоящим контентом.

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

Почему это важно? Потому что компонент, сделанный правильно на уровне атома, не нужно переделывать, когда он попадает в организм. Вы один раз определили, как выглядит кнопка — и она везде одинаковая.

Дизайн-токены: где живут «правила»

Токены — это переменные для дизайна. Не конкретный цвет #1A73E8, а именованная величина color.primary.500. Не размер шрифта 16px, а font.size.body.default.

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

Типы токенов

Цветовые токены. Обычно делятся на три слоя:

  • Глобальные: gray-100, blue-500, red-300 — просто палитра
  • Семантические: color-background-primary, color-text-secondary, color-border-error — роли цветов
  • Компонентные: button-primary-background, input-border-focus — конкретные элементы

Зачем три слоя? Чтобы переключить тему. Тёмная тема — это просто замена семантических токенов. color-background-primary в светлой теме = #FFFFFF, в тёмной = #121212. Компоненты не меняются.

Типографика. Размеры, начертания, межстрочные интервалы, трекинг. Главное — не плодить сущности. 4–6 размеров шрифта достаточно для 90% интерфейсов. Если у вас 12 разных размеров — это не система, это инвентарь.

Отступы. Лучше работать с множителем. Базовый шаг — 4px или 8px, дальше кратные значения: 4, 8, 12, 16, 24, 32, 48, 64. Когда дизайнер и разработчик говорят «отступ medium» — оба понимают одинаково.

Скругления, тени, анимации. Тоже токены. border-radius.small = 4px, shadow.card = 0 2px 8px rgba(0,0,0,0.12), duration.fast = 150ms.

Как токены попадают в код

Есть несколько способов:

  • CSS-переменные: --color-primary: #1A73E8
  • Sass/Less переменные: $color-primary: #1A73E8
  • JavaScript/TypeScript объекты для React Native или JS-приложений
  • JSON с трансформацией через Style Dictionary от Амазона

Style Dictionary — инструмент, который берёт один источник токенов и генерирует их в любом нужном формате: CSS, Sass, Android XML, iOS Swift. Один источник правды для всех платформ.

Компоненты: что в них должно быть

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

Состояния. Кнопка бывает: default, hover, active, disabled, loading. Поле ввода: empty, focused, filled, error, disabled. Если состояний нет — разработчик придумает их сам, и результат предсказать сложно.

Варианты. Primary, secondary, ghost, danger — для кнопок. Small, medium, large — по размеру. Каждый вариант задокументирован, каждому соответствует код.

Автолейаут и адаптивность. В Figma компонент должен нормально растягиваться при изменении текста. Кнопка с коротким и длинным текстом — оба выглядят правильно.

Слоты для контента. Карточка может содержать или не содержать изображение. Уведомление может быть с иконкой или без. Это не два компонента — это один с опциональными слотами.

Именование

Единая система именования — половина успеха. Если в Figma компонент называется Button/Primary/Large, а в коде — PrimaryLargeButton, команда тратит время на перевод.

Работает правило: имя компонента в дизайне = имя компонента в коде. Это нужно договорить один раз — и держаться.

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

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

Хорошая документация дизайн-системы устроена так:

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

Figma как источник дизайна. Компоненты в Figma должны быть актуальными. Если в коде кнопка обновилась, а в Figma нет — система ломается. Workflow: сначала обновляется токен или компонент в Figma, потом в коде.

Страницы использования. Для каждого компонента — раздел «когда использовать» и «когда не использовать». Звучит банально, но именно это останавливает неправильное применение. Пример: «Используйте danger-button только для необратимых действий (удаление, отмена платежа). Не используйте для обычных предупреждений — для этого есть warning-state».

Changelog. История изменений. Когда что сломали, что добавили, что устарело. Без этого команда не знает, что менялось, и боится обновлять версию системы.

Инструменты

Для небольших команд достаточно:

  • Figma с организованными компонентами и токенами через плагин Tokens Studio
  • Storybook для документации компонентов
  • Style Dictionary для генерации токенов в разные форматы
  • NPM-пакет для публикации библиотеки (если несколько проектов)

Для крупных команд добавляется:

  • Chromatic — визуальное регрессионное тестирование компонентов
  • Zeroheight или Supernova — отдельный портал документации
  • GitHub Actions для автоматической публикации при изменениях

Когда дизайн-система оправдана

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

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

Дизайн-система окупается, когда:

  • Несколько продуктов в одном бренде
  • Команда больше трёх человек (дизайнеры + разработчики)
  • Продукт активно развивается и часто обновляется
  • Есть мобильное приложение и веб-версия одновременно

Для корпоративного сайта или интернет-магазина достаточно компонентного подхода без формальной системы. Для SaaS-платформы с несколькими интерфейсами — дизайн-система становится необходимостью.

С чего начать

Если вы решили строить систему с нуля, вот практичная последовательность:

  1. Аудит существующего. Соберите скриншоты всех экранов. Выпишите все варианты кнопок, отступов, цветов. Поймите, что есть сейчас.

  2. Определите токены. Начните с цвета и типографики. Договоритесь о палитре и семантических ролях. Это два часа работы с дизайнером и тимлидом.

  3. Выделите 5–10 базовых компонентов. Кнопки, поля ввода, типографические стили, иконки, карточки. Это покрывает 70% интерфейса.

  4. Задокументируйте. Не идеально, а достаточно. Название, состояния, примеры использования.

  5. Внедрите в один реальный проект. Посмотрите, что не работает. Система проверяется практикой, а не в вакууме.

  6. Итерируйте. Компонент, который не используется три месяца — кандидат на удаление. Паттерн, который дублируется везде — кандидат на добавление.

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

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

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

Слишком много компонентов. Чем больше библиотека — тем сложнее поддерживать. 80 компонентов, из которых используется 20 — это не система, это кладбище.

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

Документация и реальность расходятся. Самая распространённая проблема. Решается автоматизацией: Storybook генерирует документацию из кода, а не пишется отдельно руками.

Игнорируют accessibility. Цветовой контраст, состояния фокуса, поддержка клавиатурной навигации — это часть компонента, не отдельная задача на потом.

Версионирование

Дизайн-система — живой продукт. Изменения нужно версионировать по semver:

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

Команды, которые пропускают версионирование, однажды обнаруживают, что обновление системы сломало пять экранов в продакшне.

Дизайн-система — это не проект с дедлайном. Это инфраструктура, которая строится постепенно и живёт, пока живёт продукт. Начать можно с малого: договоритесь о цветах и токенах типографики. Уже это сократит количество вопросов «какой синий использовать» до нуля.