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

Короткий ответ

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

Рабочая последовательность выглядит так:

1. Аудит интерфейса.
2. Основы (foundations) и токены.
3. Базовые компоненты.
4. Документация.
5. Governance — кто и как принимает изменения.
6. Внедрение в продукт и команду.

Шаг 1. Аудит интерфейса

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

Что зафиксировать по итогам:

• какие элементы повторяются чаще всего — они пойдут в систему первыми;
• где расхождения случайны, а где оправданы контекстом;
• какие компоненты уже есть в коде и на каком фреймворке.

Шаг 2. Основы и токены

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

• примитивы — сырые значения (violet-600, space-4);
• семантические токены — смысл (color-bg-primary, color-text-danger, space-inset-md).

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

{
  "color": {
    "violet": { "600": { "value": "#7C3AED" } },
    "bg": { "primary": { "value": "{color.violet.600}" } }
  }
}

Шаг 3. Базовые компоненты

Начните с 10–15 самых частых элементов из аудита: кнопка, поле ввода, чекбокс, селект, ссылка, бейдж статуса, карточка, модальное окно, уведомление. Для каждого опишите:

• варианты (primary, secondary, ghost) и размеры;
• состояния: default, hover, focus, active, disabled, loading, error;
• поведение с длинным текстом, иконкой, на мобильном;
• требования доступности: контраст, видимый фокус, работа с клавиатуры.

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

Шаг 4. Документация

Документация отвечает на вопрос «когда использовать», а не только «как выглядит». Минимум для каждого компонента: назначение, примеры правильного и неправильного применения, свойства, состояния, требования доступности и ссылка на код. Хорошо работают Storybook для кода и отдельная страница с правилами в Figma или на внутреннем сайте.

Шаг 5. Governance

Система живёт, пока есть понятный процесс изменений. Определите:

• владельца — человека или небольшую команду, отвечающую за систему;
• как предложить новый компонент или правку (шаблон запроса);
• критерии принятия: используется ли паттерн минимум в нескольких местах;
• версионирование и changelog, чтобы продукты обновлялись осознанно.

Шаг 6. Внедрение

Лучший способ внедрения — заменить компоненты на одном реальном экране или в одной новой фиче и показать, что работа пошла быстрее. Дальше переводите продукт постепенно, а не «большим взрывом». Собирайте обратную связь от разработчиков: неудобное API компонента убивает систему быстрее, чем плохой дизайн.

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