Дизайн-система — это набор дизайн-токенов, компонентов и правил их использования, который собирается за 3–4 месяца. Начинайте с аудита существующих экранов, опишите фундамент (цвета, шрифты, отступы) как токены, соберите 15–20 базовых компонентов и задокументируйте правила. Не стройте «на вырост» — система живёт, пока ей пользуются.
Что такое дизайн-система и зачем она нужна
Дизайн-система — это не UI-кит в Figma. Это три слоя, которые работают вместе:
- Фундамент — дизайн-токены: цвета, типографика, отступы, тени, скругления, анимации. Описаны как переменные, а не как значения.
- Библиотека компонентов — кнопки, поля, карточки, модалки, собранные из токенов. В Figma — как Variants, в коде — как переиспользуемые компоненты.
- Документация — правила: когда какую кнопку использовать, как собирать форму, как компоненты взаимодействуют.
Без третьего слоя система превращается в свалку компонентов, которыми никто не пользуется правильно.
Главная метрика дизайн-системы — доля экранов, собранных из её компонентов. Хороший показатель — 70–80% через полгода после запуска.
Когда система действительно нужна
Не каждой команде нужна полноценная дизайн-система. Три сигнала, что пора:
- Больше одного продукта или платформы — лендинг, личный кабинет, мобильное приложение. Без системы они быстро расходятся в деталях.
- Дизайнеров больше двух — каждый начинает тянуть в свою сторону, появляются «свои» кнопки и отступы.
- Время на новый экран больше 2 дней — это значит, что команда каждый раз переизобретает базовые элементы.
Если у вас один продукт и один дизайнер, достаточно упорядоченной библиотеки символов в Figma. Не строите систему ради системы.
Этапы построения: пошагово
Шаг 1. Аудит существующего (1–2 недели)
Соберите все экраны всех продуктов в один файл. Найдите:
- дубликаты компонентов (кнопка в пяти вариантах с разницей в 2 пикселя);
- расхождения в отступах, цветах, скруглениях;
- компоненты, которые используются чаще всего.
Из аудита получится список из 15–20 компонентов для первой версии. Не пытайтесь описать всё — соберите то, что покрывает 80% экранов.
Шаг 2. Фундамент: дизайн-токены (2–3 недели)
Токены — это именованные сущности вместо хардкода. Не #2563EB, а color-brand-primary. Не 16px, а space-4. Структура токенов обычно трёхуровневая:
| Уровень | Пример | Назначение |
|---|---|---|
| Глобальный (reference) | blue-600, gray-100 | Палитра как таковая |
| Семантический (system) | color-brand-primary, color-text-muted | Роль в интерфейсе |
| Компонентный (component) | button-bg-primary, input-border-default | Точка применения |
Хранить токены удобно через плагин Tokens Studio для Figma — он экспортирует JSON, который потом конвертируется в CSS-переменные или переменные Tailwind. Один источник правды для дизайна и кода.
Шаг 3. Базовые компоненты (3–4 недели)
Из токенов соберите атомы: кнопки, поля ввода, чекбоксы, переключатели, иконки. Каждый компонент описывается через Variants в Figma:
- свойства (состояние, размер, цвет);
- ограничения (auto-layout, resizing);
- документация внутри описания компонента.
Базовых компонентов обычно 15–20: кнопка, поле ввода, textarea, select, checkbox, radio, switch, tooltip, badge, avatar, icon, divider, spinner, progress, alert, modal, dropdown.
Шаг 4. Составные компоненты и паттерны (3–4 недели)
Из атомов соберите молекулы и организмы: формы, карточки товаров, шапки таблиц, навигацию. Здесь появляется главный затык — команда начинает строить абстракции ради абстракций. Правило: выносите в отдельный компонент только то, что встречается на 3+ экранах.
Шаг 5. Документация и внедрение (2 недели и дальше навсегда)
Документация — это не PDF на 80 страниц. Это короткие правила рядом с компонентом:
- когда использовать;
- когда НЕ использовать;
- вариации и их назначение;
- примеры «плохо» с пояснением.
Внедрение — это обучение команды и регулярные ревью. Без них система умирает за квартал.
Как не утонуть в абстракциях
Главная болезнь молодых дизайн-систем — overengineering. Признаки, что вы зашли далеко:
- компонент имеет больше 8 свойств — его невозможно использовать без шпаргалки;
- вы строите универсальный компонент «на будущее» под сценарии, которых ещё нет;
- команда обсуждает названия токенов дольше, чем рисует экраны.
Лечится правилом: компонент должен собираться в один приём. Если для использования кнопки нужно прочитать документацию — компонент переусложнён.
Метрики здоровья системы
| Метрика | Норма | Красный флаг |
|---|---|---|
| Доля экранов из компонентов | 70–80% | Ниже 40% через полгода |
| Время на новый экран | 0,5–1 день | Растёт, а не падает |
| Запросов на новые токены в месяц | 5–15 | Больше 30 — фундамент неполный |
| Расхождений между Figma и кодом | Единицы | Десятки — два источника правды |
Кто поддерживает систему
До 10 продуктов система держится на одном дизайнере с выделенной долей ставки (30–50%). Дальше нужен выделенный team:
- Design system owner — отвечает за направление, приоритизирует задачи.
- 1–2 дизайнера — рисуют новые компоненты, дорабатывают старые.
- Frontend-разработчик — переводит компоненты в код, поддерживает библиотеку в репозитории.
Без frontend-разработчика в команде система остаётся «картинкой в Figma» — дизайнеры рисуют одно, разработчики пишут другое.
Главные ошибки на старте
- Строить систему без продукта. Если нет живого продукта, который использует систему, — вы строите абстракцию в вакууме. Дизайн-система выводится из реальных экранов, а не наоборот.
- Описать сразу всё. Первая версия с 200 компонентами не взлетит — команда утонет до запуска. Начните с 15.
- Игнорировать код. Дизайнеры делают свою библиотеку, разработчики — свою. Через месяц они расходятся, и система бесполезна.
- Нет владельца. «Система общая» = система ничья. Должен быть человек, который отвечает за неё.
Дизайн-система — это не проект с датой завершения, а продукт, который живёт, пока живёт компания. Начните с малого: аудит, токены, 15 компонентов, документация. Дальше — итерации по реальным потребностям продуктов.
Комментарии · 0