Что такое дизайн-система и зачем она нужна
Представь: у тебя 50 экранов в приложении. На одних кнопках закруглённые углы 4px, на других — 8px. Синий акцент в хедере — #2563EB, а в карточках — #1D4ED8. Отступы между блоками: где-то 16px, где-то 20px, потому что дизайнер «так почувствовал». Разработчики задают вопросы каждый день, а правки в одном месте не попадают в другое.
Вот это — жизнь без дизайн-системы. Дизайн-система — это набор правил, компонентов и инструментов, которые делают продукт визуально согласованным и ускоряют работу команды.
Не надо путать с брендбуком. Брендбук говорит «наши цвета такие, логотип такой». Дизайн-система говорит «вот кнопка primary, вот её состояния hover/disabled/loading, вот как её использовать в коде».
Токены — атомарный уровень
Токен — это именованное значение для любого визуального свойства. Не #2563EB, а color.brand.primary. Не 16px, а spacing.md.
Почему это важно? Когда дизайнер решит поменять основной синий — вы меняете значение в одном месте, и это автоматически применяется везде: в коде, в Figma, в документации.
Цвета. Сначала примитивы: blue.500: #3B82F6, blue.600: #2563EB. Затем семантические токены: color.action.primary: {blue.600}, color.text.link: {blue.500}. Разница критическая: семантический токен описывает назначение, а не конкретный цвет. Если хочешь перекрасить все кнопки — меняешь один токен, а не 30 мест в коде.
Типографика. font.size.sm: 14px, font.weight.bold: 700, font.family.base: Inter, sans-serif. Часто добавляют типографические пресеты — typography.body.md включает в себя размер, межстрочный интервал и начертание сразу.
Отступы. Классическая сетка 4px: spacing.1: 4px, spacing.2: 8px, spacing.4: 16px, spacing.8: 32px. Иногда используют сетку 8px для крупных элементов. Главное — консистентность.
Тени, радиусы, z-index. Тени — это боль, если их не регламентировать. Достаточно 3–4 уровней: shadow.sm, shadow.md, shadow.lg, shadow.xl. Радиусы углов: radius.sm: 4px, radius.md: 8px, radius.full: 9999px.
В CSS токены реализуются как переменные: --color-brand-primary: #2563EB. В JS — как объект или JSON. Современный стандарт — W3C Design Tokens Format, который поддерживают Figma, Style Dictionary и другие инструменты.
Компоненты — строительные блоки
Компонент — это переиспользуемый UI-элемент с чётко описанными вариантами и состояниями. Кнопка — компонент. Input — компонент. Карточка — компонент. Целая страница — нет.
Атомарный дизайн Брэда Фроста — один из самых известных подходов к организации:
- Атомы: Button, Input, Icon, Label
- Молекулы: SearchField (Input + Button), FormField (Label + Input + Error)
- Организмы: Header (Logo + Navigation + SearchField), ProductCard
- Шаблоны: Page layouts
- Страницы: конкретные реализации с реальным контентом
На практике многие команды упрощают до трёх уровней: базовые элементы, составные компоненты и шаблоны. Главное — чтобы все понимали, где что живёт.
Что описывает компонент:
Варианты (variants): кнопка может быть primary, secondary, ghost, destructive. Input — с иконкой и без, с ошибкой и без.
Состояния (states): default, hover, focus, active, disabled, loading. Это критично — без описания состояний разработчики придумывают их сами, и всё расползается.
Размеры (sizes): sm, md, lg — стандартная тройка. Иногда добавляют xs и xl.
Пропы и параметры: что можно настроить снаружи? Для кнопки это может быть иконка слева/справа, ширина (fixed vs stretch), тип (button/submit).
Распространённая ошибка — делать компонент слишком гибким. Кнопка с 20 параметрами, из которых используются 3, — это не компонент, это головная боль. Если видишь, что компонент обрастает специфическими кейсами, подумай: может, это два разных компонента?
Документация — то, без чего система не работает
Можно сделать идеальные токены и компоненты, а потом обнаружить, что никто ими не пользуется — потому что непонятно как. Документация — это не бонус, это обязательная часть.
Хорошая документация компонента включает:
- Описание — что это и когда использовать (одно-два предложения)
- Примеры использования — живые, интерактивные, если возможно
- Правила применения — dos and don'ts
- API компонента — таблица с пропами, их типами и дефолтными значениями
- Код — готовый сниппет для копирования
Пример плохого описания: «Кнопка используется для взаимодействия пользователя с интерфейсом». Пример хорошего: «Primary-кнопка — для главного целевого действия на экране. Не используй больше одной primary-кнопки в одной форме. Для второстепенных действий — secondary».
Инструменты
Figma — стандарт индустрии. Компоненты, автолayout, варианты, Variables — всё это есть. С 2023 года Figma Variables позволяют хранить токены прямо в Figma и синхронизировать с кодом через плагины.
Storybook — незаменим для разработчиков. Компонент изолирован, видны все состояния, можно поиграть с пропами в реальном времени. Плюс — автогенерация документации из кода.
Style Dictionary (Amazon) — превращает JSON с токенами в CSS-переменные, JS-объекты, Swift-константы, Android-ресурсы. Один источник правды, много форматов вывода.
Tokens Studio for Figma — плагин для синхронизации токенов между Figma и GitHub. Удобно, когда дизайнеры и разработчики хотят работать с одним источником токенов.
Radix UI, shadcn/ui — библиотеки примитивов с accessibility из коробки. Не дизайн-системы сами по себе, но отличная основа.
Как строить дизайн-систему: практический путь
Не надо начинать с нуля и тратить три месяца на «правильную» архитектуру.
Шаг 1. Аудит существующего UI. Открой все экраны и выпиши: сколько уникальных цветов используется? Сколько размеров шрифта? Какие компоненты повторяются? Обычно обнаруживаешь 15 оттенков серого вместо 5 и кнопки трёх разных высот.
Шаг 2. Определи токены. Начни с цветов и отступов — это даёт наибольший эффект. Составь таблицу: текущее значение → имя токена → новое значение (если нужно изменить). Не пытайся охватить всё сразу.
Шаг 3. Приоритизируй компоненты. Начни с тех, что используются чаще всего: кнопки, поля ввода, карточки, навигация. Правило 20/80: 20% компонентов покрывают 80% интерфейса.
Шаг 4. Документируй по ходу. Не откладывай документацию «на потом» — напиши хотя бы краткое описание и примеры сразу, когда компонент свежий. Потом не дойдут руки.
Шаг 5. Версионируй. Дизайн-система — живой продукт. Заведи changelog, используй семантическое версионирование. Ломающие изменения — мажорная версия, новые компоненты — минорная, фиксы — патч.
Частые ошибки
Делать систему ради системы. Если у вас один лендинг или небольшой корпоративный сайт — полноценная дизайн-система избыточна. Достаточно набора токенов в CSS-переменных и базовых компонентов. В REEXY при разработке корпоративных сайтов мы всегда фиксируем хотя бы токены цветов и типографику — это занимает несколько часов, но сильно упрощает поддержку в дальнейшем.
Нет владельца системы. Дизайн-система требует ответственного человека или команды. Без него она быстро устаревает и превращается в документ, которому никто не доверяет.
Слишком строгие правила на старте. «Только эти восемь компонентов, никаких отступлений». В реальных проектах всегда появляются исключения. Лучше заложить механизм расширения, чем запрещать всё нестандартное.
Игнорировать accessibility. Цвета должны проходить проверку контрастности WCAG AA — минимум 4.5:1 для основного текста. Компоненты должны быть доступны с клавиатуры. Это не опциональное улучшение, а базовое требование к качеству.
Когда дизайн-система окупается
Честный ответ: не сразу. Первые недели — это инвестиции. Команда тратит время на создание, а не на новые фичи.
Окупаемость приходит, когда:
- Новый дизайнер начинает продуктивно работать за день, а не за неделю
- Правки корпоративного стиля применяются везде за час, а не за спринт
- Разработчики перестают спрашивать «какой отступ здесь?» по 10 раз в день
- QA находит меньше визуальных несоответствий
Дизайн-система начинает давать ощутимый профит при команде от 3–4 человек и продукте, который живёт больше года. Для стартапа из двух человек — возможно, избыточно. Для компании с несколькими продуктами — обязательно.
Material Design от Google, Polaris от Shopify, Carbon от IBM — это многолетние работы десятков людей. Но суть та же, что и в маленькой системе из 20 компонентов: один источник правды для всех визуальных решений. Начни с токенов и пяти компонентов — и система уже работает.