Если над проектом работает больше одного человека и он живёт дольше трёх месяцев — рано или поздно начинается хаос. Кнопки в разных местах выглядят по-разному. Один разработчик использует #2563EB, другой — #1D4ED8, хотя оба считают, что это «синий бренда». Отступы везде разные, шрифты плывут. Это не проблема людей — это проблема отсутствия системы.
Дизайн-система — это общий язык между дизайнером и разработчиком. Набор договорённостей, зафиксированных в компонентах, токенах и документации. Она не про красоту, она про предсказуемость.
Что входит в дизайн-систему
Чаще всего люди путают дизайн-систему с библиотекой компонентов. Это не одно и то же.
Библиотека компонентов — это кнопки, инпуты, карточки, модалки. Визуальные кирпичи, из которых собирается интерфейс.
Дизайн-система шире: она включает токены (переменные со значениями), принципы (как и когда использовать компоненты), документацию и процессы обновления.
Можно провести аналогию со строительством. Библиотека — это склад готовых панелей. Токены — это стандарты: какой высоты этаж, какой толщины стены. Документация — это СНиП, где написано, почему именно так.
Токены: откуда начинать
Токен — это именованная переменная с дизайн-значением. Звучит сложно, на практике всё проще.
Вместо того чтобы в каждом месте писать font-size: 16px, вы объявляете:
--font-size-base: 16px;
И используете var(--font-size-base) везде. Поменяли в одном месте — обновилось везде.
Токены делятся на три уровня:
Глобальные (primitive tokens) — сырые значения без контекста:
color-blue-500: #2563EB
spacing-4: 16px
font-size-md: 16px
Семантические (semantic tokens) — значения с контекстом использования:
color-action-primary: {color-blue-500}
spacing-button-horizontal: {spacing-4}
Компонентные — привязанные к конкретному компоненту:
button-primary-background: {color-action-primary}
button-padding-x: {spacing-button-horizontal}
Почему три уровня, а не один? Потому что это даёт гибкость. Если вы захотите сменить основной синий с #2563EB на #1E40AF — меняете один глобальный токен, и все кнопки, ссылки, бейджи обновляются автоматически. Если меняете только цвет кнопок, не трогая ссылки — меняете семантический.
Также токены упрощают тёмную тему. Вы не перекрашиваете каждый компонент вручную — просто переопределяете семантические токены для тёмного режима:
/* светлая тема */
color-surface-primary: #FFFFFF;
/* тёмная тема */
color-surface-primary: #0F172A;
С чего начать токены
Практический порядок: сначала цвета, потом отступы, потом типографика.
Цвета: выпишите все цвета, которые реально используются в проекте. Обычно это 3-5 базовых с оттенками, плюс нейтральные (серые), плюс семантические (успех, ошибка, предупреждение). Если набирается больше 60-70 значений — скорее всего, у вас не система, а хаос, зафиксированный в файле.
Отступы: договоритесь о шаге. Чаще всего это 4px или 8px. То есть все отступы кратны 4 (или 8): 4, 8, 12, 16, 24, 32, 48, 64. Произвольные значения типа 13px или 27px — красный флаг.
Типографика: зафиксируйте размеры шрифтов, высоты строк, начертания. Обычно достаточно 5-7 ступеней: от caption (12px) до display (48-64px).
Компоненты: атомарный подход
Атомарный дизайн — методология Брэда Фроста, и она хорошо работает на практике. Идея: компоненты делятся по уровню сложности.
Атомы — минимальные элементы: кнопка, инпут, иконка, тег, аватар. Их нельзя разбить на части без потери смысла.
Молекулы — сочетания атомов: поле поиска (инпут + кнопка), карточка пользователя (аватар + имя + роль).
Организмы — сложные блоки: шапка сайта, форма регистрации, таблица данных.
Шаблоны — каркасы страниц без реальных данных.
Страницы — шаблоны с реальным контентом.
На практике жёстко следовать иерархии не нужно. Главное — понимать принцип: чем выше уровень, тем больше компонент зависит от контекста. Атомы максимально переиспользуемые, страницы — нет.
Что делает компонент хорошим
Один компонент — одна ответственность. Кнопка отвечает за действие, не за навигацию и не за отображение данных.
Варианты через пропсы, не через копирование. Не нужно делать ButtonPrimary, ButtonSecondary, ButtonDanger как три разных компонента. Одна Button с пропсом variant: primary | secondary | danger.
Состояния задокументированы. Интерактивный компонент должен иметь состояния: default, hover, focus, active, disabled, loading. Если дизайнер не нарисовал — разработчик придумает сам, и результат не предсказуем.
Компонент не знает о своём расположении. Кнопка не должна содержать в себе margin-top: 24px. Отступы — ответственность родителя или layout-компонента.
Документация: почему её игнорируют и почему зря
Документация — самая недооценённая часть дизайн-системы. Команды делают токены, делают компоненты, а документацию откладывают на потом. Потом не наступает.
Через полгода новый разработчик не понимает, когда использовать ButtonGhost, а когда ButtonOutlined. Дизайнер рисует компонент, который уже есть — просто он по-другому называется в Figma и в коде.
Хорошая документация отвечает на три вопроса:
- Что это? Описание компонента в одном предложении.
- Когда использовать? Сценарии применения с примерами. И обязательно — когда не использовать.
- Как использовать? Пример кода, список пропсов с типами и дефолтными значениями.
Форматы документации
Storybook — стандарт для компонентных библиотек на React, Vue, Angular. Каждый компонент живёт в изоляции, можно переключать состояния и варианты. Автоматически генерирует таблицу пропсов из TypeScript-типов. Интегрируется с Figma через плагины.
Notion или Confluence — для принципов, гайдлайнов, решений по дизайну. Сюда пишут не «как использовать кнопку», а «почему мы отказались от тени в карточках» или «как мы подходим к пустым состояниям».
Figma — документация прямо в макетах: аннотации, описания компонентов, ссылки на код. Плагины типа Specify или Supernova умеют синхронизировать токены между Figma и кодом.
Практический совет: не пытайтесь сделать документацию идеальной сразу. Начните с минимума — название, описание, пример использования, список вариантов. Это лучше, чем ничего. Дополняйте по мере вопросов от команды: если один и тот же вопрос задают дважды — это сигнал, что ответ нужно зафиксировать.
Как внедрить дизайн-систему в существующий проект
На гринфилде всё просто: начинаете с токенов, потом строите компоненты. На легаси-проекте сложнее.
Работающая стратегия — «strangler fig» («удушающий фикус»). Новые фичи пишете с использованием компонентов системы, старый код трогаете только когда редактируете его по другим причинам. Параллельно переписывать всё — дорого и опасно.
Пошагово это выглядит так:
- Аудит: выпишите все уникальные цвета, отступы, шрифты в текущем коде. Инструменты типа StyleLint или ручной поиск по css-файлам.
- Договоритесь о токенах: какие значения остаются, какие унифицируются.
- Добавьте CSS-переменные с токенами, не меняя пока визуал.
- Постепенно заменяйте хардкод на переменные.
- Начинайте выделять компоненты — сначала самые частые (кнопки, инпуты).
- Пишите документацию параллельно, не после.
Весь процесс на среднем проекте занимает от трёх месяцев до года. Это не разовая задача, а постоянная работа.
Дизайн-система для малого бизнеса: нужна ли она вообще
Честный ответ: полноценная дизайн-система с токенами, Storybook и Figma-библиотекой нужна не всем.
Если у вас сайт-визитка или лендинг — достаточно простого стайл-гайда: цвета бренда, шрифты, правила использования логотипа. Это занимает несколько часов, но уже спасает от хаоса при следующем обновлении.
Если у вас корпоративный сайт или интернет-магазин с несколькими разделами — уже есть смысл в базовой библиотеке компонентов и CSS-токенах. Это окупается при первой же доработке: разработчик не тратит время на поиск нужного цвета или выравнивание отступов.
В REEXY при разработке корпоративных сайтов и магазинов мы закладываем базовую структуру токенов и компонентов сразу — это упрощает последующую поддержку и дополнения. Потом добавить раздел или поменять цветовую схему становится задачей на часы, а не на дни.
Инструменты, которые стоит знать
Figma — де-факто стандарт для дизайна. Variables (переменные) в Figma — это токены на уровне дизайна. Компонентные библиотеки позволяют шарить компоненты между файлами.
Storybook — документация и разработка компонентов в изоляции. Поддерживает React, Vue, Angular, Svelte и другие.
Style Dictionary (Amazon) — инструмент для трансформации токенов из JSON в CSS-переменные, SCSS, JS-константы, Swift, Kotlin. Один источник правды для всех платформ.
Supernova — синхронизация токенов из Figma в код. Платный, но экономит много ручной работы на больших проектах.
Zeroheight или Storybook Docs — хостинг документации с живыми примерами.
Частые ошибки
Делают библиотеку компонентов, а не систему. Компоненты есть, но нет токенов и документации. Через полгода — снова хаос, просто более аккуратно оформленный.
Слишком рано абстрагируют. Создают компонент на основе одного использования. Правило трёх: делайте компонент, когда одно и то же встретилось трижды в разных контекстах.
Документацию пишут «потом». Потом не наступает. Договоритесь: компонент не считается готовым без документации.
Система живёт отдельно от продукта. Обновляют дизайн-систему, но не синхронизируют с реальным продуктом. Или наоборот — продукт уходит вперёд, система устаревает. Нужен процесс синхронизации.
Один человек владеет системой. Уйдёт — и никто не понимает, как это работает. Система должна принадлежать команде.
Как понять, что система работает
Простой тест: дайте новому разработчику задачу собрать страницу из существующих компонентов. Если он справился за день без вопросов к команде — система работает. Если половина рабочего дня ушла на поиск нужного компонента и выяснение, какой цвет правильный — есть над чем работать.
Другой маркер: как часто вы слышите «а какой у нас синий?» или «какой отступ тут правильный?». Если эти вопросы исчезли — вы на верном пути.