Design system: токены, компоненты, governance

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

Зрелая система экономит десятки тысяч часов в год за счёт переиспользования решений, ускоряет вывод новых функций и упрощает поддержку. Незрелая или брошенная система превращается в источник конфликтов между командами и медленно деградирует до состояния «у каждой команды свой набор кнопок». Граница между этими исходами проходит не по качеству Figma-библиотеки, а по выстроенным процессам, governance-модели и инвестициям в поддержку.

Что входит в design system

Design system устроена слоями. Каждый слой опирается на предыдущий и предоставляет более высокий уровень абстракции.

Каждый слой имеет свою аудиторию и свой режим использования. Токены — низкоуровневые переменные, на которые опираются компоненты. Компоненты — переиспользуемые блоки с пропсами. Паттерны — рекомендованные комбинации компонентов для типовых задач. Документация связывает всё вместе и объясняет, когда и как применять.

Design tokens — фундамент системы

Дизайн-токены — это именованные значения, описывающие визуальные свойства интерфейса. Вместо того чтобы прописывать #1A73E8 в десятках мест, дизайнер использует токен color-primary-500, который при необходимости можно переопределить централизованно.

Категории токенов

• Color: палитра, семантические цвета (success, warning, danger), цвета фона, текста, границ
• Typography: семейства шрифтов, размеры, жирность, межстрочный интервал, межбуквенный интервал
• Spacing: шкала отступов и интервалов (обычно на основе 4 или 8 пикселей)
• Sizing: размеры компонентов, контейнеров, иконок
• Border: толщина, радиусы скругления, стили границ
• Shadow: тени с разными уровнями глубины
• Motion: длительность анимаций, кривые easing
• Z-index: уровни наложения слоёв

Уровни абстракции

Профессиональные системы разделяют токены на несколько уровней:

1. Primitive tokens — сырые значения цветов, размеров: blue-500, gray-100, 16
2. Semantic tokens — назначение в системе: color-action-primary, color-text-default, spacing-md
3. Component tokens — специфичные для компонента: button-primary-background, input-border-focused

Семантические токены ссылаются на примитивные, компонентные ссылаются на семантические. Такая структура позволяет менять реализацию (например, всю палитру) без переписывания компонентов.

W3C Design Tokens спецификация

В 2022 году W3C запустила рабочую группу для стандартизации формата токенов. Спецификация описывает JSON-структуру с типами значений, ссылками между токенами, метаданными. Это снимает проблему несовместимости между инструментами: токены, экспортированные из Figma по стандарту, можно импортировать в Style Dictionary, в кодовую базу, в другие инструменты.

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

Component library

Библиотека компонентов — основной артефакт design system, с которым ежедневно работают дизайнеры и разработчики. Цель — предоставить готовые блоки для построения интерфейсов, чтобы каждая команда не изобретала свою кнопку.

Уровни компонентов по Atomic Design

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

• Atoms — базовые элементы: кнопки, поля, иконки, заголовки
• Molecules — простые комбинации: поле поиска с кнопкой, форма входа
• Organisms — сложные блоки: шапка сайта, карточка товара, форма с валидацией
• Templates — макеты страниц без конкретного контента
• Pages — реальные страницы с данными

Atomic Design помогает структурировать библиотеку, но не работает буквально для всех систем. Часто атомы и молекулы сливаются в единый слой «компоненты», организмы становятся «секциями», и общая иерархия упрощается.

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

Документация

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

Структура документации

1. Гайдлайны бренда и принципы дизайна
2. Установка и подключение для разработчиков
3. Каталог токенов с описанием назначения
4. Каталог компонентов с примерами, props, состояниями, кодом
5. Паттерны использования для типовых сценариев
6. Гайдлайны по контенту: тон, терминология, формат
7. Accessibility-стандарты системы
8. Контрибуция: как предложить изменение, добавить компонент
9. Changelog и roadmap

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

Популярные варианты различаются по сложности и интеграции:

• Storybook — стандарт индустрии для документации компонентов с интерактивным просмотром props, поддержкой add-ons для accessibility, design-токенов
• Docusaurus, Nextra, VitePress — генераторы статических сайтов для общей документации с MDX-поддержкой
• Zeroheight, Supernova — специализированные SaaS-платформы для design system с интеграцией Figma
• Кастомные сайты на Next.js или Astro — для крупных систем с уникальными требованиями

Governance — управление развитием

Governance — это набор правил и процессов, определяющих, как система развивается, кто принимает решения и как разрешаются конфликты. Без явной governance-модели system быстро превращается в свалку компонентов от разных команд без единой логики.

Модели управления

Процесс изменений

Любая зрелая система имеет формализованный процесс предложения изменений:

1. Контрибьютор открывает RFC или design proposal с описанием проблемы и предлагаемого решения
2. Core-команда даёт обратную связь, обсуждение проходит публично
3. Прототипируется решение, проверяется на нескольких сценариях
4. После одобрения решение интегрируется в систему
5. Готовится релиз с changelog, миграционными гайдами при breaking changes

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

Design system — продукт, и как любой продукт нуждается в версионировании. Стандартная практика — Semantic Versioning (MAJOR.MINOR.PATCH).

• MAJOR: breaking changes — переименованный компонент, удалённый props, изменённое поведение, ломающее существующий код
• MINOR: новые компоненты, новые варианты, обратно-совместимые изменения
• PATCH: исправление багов, мелкие визуальные правки без изменения API

Стратегии релизов

Малые системы выпускают релизы по мере готовности изменений. Крупные системы переходят на фиксированный календарь: minor-релизы раз в две недели, major — раз в полгода с предварительным анонсом. Регулярность даёт командам предсказуемость и время на миграцию.

Депрекация

Старые компоненты не удаляются мгновенно. Стандартный цикл — пометить как deprecated в одном major-релизе, оставить с предупреждениями в нескольких minor, окончательно удалить в следующем major. Это даёт командам несколько месяцев на переход.

Инструментальная экосистема

Современная design system опирается на стек инструментов, соединяющих дизайн и код.

Связка Figma и кода

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

1. Ручная синхронизация: дизайнер обновил библиотеку, разработчик внёс изменения в код
2. Tokens-pipeline: токены экспортируются из Figma в JSON, через Style Dictionary конвертируются в CSS-переменные, JS-объекты, iOS/Android-форматы
3. Component-pipeline: автоматическая генерация компонентов из дизайна через инструменты вроде Anima, Builder.io (применима ограниченно)
4. Bidirectional sync: изменения с обеих сторон автоматически приводятся к единому состоянию (теоретический предел, на практике пока редкость)

Известные публичные системы

Изучение зрелых публичных систем — полезный референс при построении собственной.

У каждой системы свой принцип: Material делает акцент на физических метафорах, Carbon — на enterprise-данных, HIG — на платформенной нативности. Подсматривать стоит структуру и подходы к governance, а не визуальное решение.

Этапы построения собственной системы

Этап 1: аудит и фундамент (1–3 месяца)

Команда инвентаризирует существующие интерфейсы, выявляет реально используемые цвета, шрифты, размеры, компоненты. Часто на этом этапе обнаруживается, что в продукте используется 40+ оттенков синего и 15 размеров шрифта без явной системы. Параллельно формулируются принципы дизайна, готовятся базовые токены.

Этап 2: ядро компонентов (2–6 месяцев)

Создаётся базовый набор из 15–30 компонентов: кнопки, поля ввода, чекбоксы, селекты, модалки, тосты, таблицы. Компоненты разрабатываются параллельно в Figma и в коде с синхронизацией токенов. Запускается Storybook, начинается документация.

Этап 3: пилотное внедрение (3–6 месяцев)

Одна продуктовая команда первой переходит на новую систему. Собирается обратная связь, выявляются недостающие компоненты и неудобства. По результатам пилота система дорабатывается перед массовым внедрением.

Этап 4: масштабирование (6–18 месяцев)

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

Этап 5: зрелость и оптимизация

Система используется как стандарт во всех продуктах. Фокус смещается на оптимизацию: уменьшение размера бандла, улучшение accessibility, добавление продвинутых паттернов, поддержка кастомизации брендов в multi-brand системах.

Метрики успеха

Зрелая система измеряет свою эффективность количественно. Типичный набор метрик:

• Adoption rate: процент команд и продуктов, использующих систему
• Component coverage: процент UI, построенного из системных компонентов (vs кастомных)
• Time-to-design: время от идеи до готового макета
• Time-to-implement: время от макета до production-кода
• Defect rate: количество багов, связанных с UI-несогласованностями
• Designer NPS: удовлетворённость дизайнеров работой с системой
• Developer NPS: удовлетворённость разработчиков
• Contribution velocity: количество merged PR из продуктовых команд

Типичные ошибки

Старт без выделенной команды

Design system, построенная как побочный проект энтузиастов, быстро деградирует при первом крупном дедлайне в основной работе. Минимум для устойчивости — выделенный продакт-менеджер и 1–2 человека full-time на ядре системы.

Копирование чужого решения

Material Design подходит Google, потому что отражает их философию и решает их продуктовые задачи. Слепое копирование привносит чужие компромиссы без понимания контекста. Учиться у крупных систем стоит, но финальный набор компонентов и принципов должен соответствовать собственному продукту.

Игнорирование разработчиков

Design system, построенная как набор Figma-файлов без оглядки на реализацию, превращается в источник конфликтов. Разработчики либо пересоздают компоненты по-своему, либо саботируют систему. Кросс-функциональная команда с дизайнерами и разработчиками с первого дня — обязательное условие.

Отсутствие версионирования

Изменения, попадающие сразу в main без релизов, ломают продукты, которые подтянули новую версию. Без changelog команды не понимают, что изменилось и почему сломался их интерфейс. Версионирование и понятные релизные ноты — базовая гигиена.

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

Бюджет на построение системы

Затраты складываются из нескольких компонентов. Для команды из 50 дизайнеров и разработчиков на средней по сложности системе ориентир такой:

• Выделенная core-команда: 3–6 человек на год для построения, далее 2–4 на поддержку
• Инструменты: Figma Organization, Storybook (бесплатный), Chromatic ($150–500 в месяц), документация на собственном сервере или Zeroheight ($300–1500 в месяц)
• Внешние аудиты accessibility: $5 000–20 000 разово или $1 000–3 000 в месяц на регулярной основе
• Обучение и onboarding: внутренние мастер-классы, документация, видеогайды

Окупаемость наступает в перспективе 18–36 месяцев за счёт сокращения времени дизайна и разработки, снижения числа UI-дефектов, ускорения onboarding новых сотрудников.

Часто задаваемые вопросы

С чего начать построение design system

С аудита существующих интерфейсов и фиксации того, что уже есть. Параллельно — с формулировки принципов дизайна и базовых токенов. Первый MVP должен покрывать 10–15 самых используемых компонентов, остальное добавляется итеративно. Запуск большого набора без обкатки на реальных продуктах обычно приводит к переделке.

Стоит ли использовать готовые системы вроде Material UI

Для стартапов и MVP — да, экономия времени огромна. По мере роста продукта и развития бренда обычно возникает потребность в собственной системе либо в кастомизации под бренд. Готовые библиотеки хороши как стартовая точка, но рано или поздно компания упирается в их ограничения.

Кто должен возглавлять команду design system

Продакт-менеджер с пониманием дизайна и разработки, либо сильный дизайнер с продуктовым мышлением. Главное — фокус на сервисной модели: design system обслуживает другие команды, а не диктует им. Без сервисной установки система превращается в башню из слоновой кости.

Как мотивировать команды использовать систему

Сделать использование выгодным: готовые компоненты ускоряют работу, документация снимает 80% вопросов, accessibility «из коробки» избавляет от ручной работы. Принудительное внедрение работает плохо — лучше делать систему настолько удобной, чтобы её хотелось использовать.

Что делать с дизайнерами, которые не хотят следовать системе

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

Как развивать систему при ограниченных ресурсах

Сфокусироваться на узком наборе компонентов, покрывающих 80% интерфейса. Не пытаться сделать всё — лучше 20 отлично спроектированных компонентов, чем 100 поверхностных. Активно использовать opensource-решения как фундамент: Radix UI, Headless UI, React Aria закрывают сложные базовые задачи (доступность, фокус, клавиатура), оставляя место для собственного брендинга.

Заключение

Design system — это инфраструктурный продукт компании, требующий выделенной команды, чёткой governance-модели и постоянных инвестиций в поддержку. Качество системы измеряется не количеством компонентов в Figma, а долей интерфейсов, построенных на её основе, и удовлетворённостью команд-потребителей.

Построение системы — длительный процесс из 5–7 этапов, занимающий годы до достижения зрелости. Успех зависит от трёх факторов: выделенных ресурсов, кросс-функциональной команды дизайнеров и разработчиков, открытой модели контрибуций. Технические инструменты — Figma, Storybook, Style Dictionary — играют поддерживающую роль; основная работа происходит в координации команд, документировании решений и формировании культуры переиспользования.