Дизайн-система — не папка из 200 компонентов, которой никто не пользуется. Это рабочий инструмент, который ускоряет команду и держит визуальное единство продукта. Расскажем, как мы собираем DS для веб-проектов, не превращая её в самостоятельный проект на полгода.
С чего начинать: токены, не компоненты
Первый шаг — не «нарисовать кнопку», а зафиксировать токены: цвета, типографика, отступы, радиусы, тени, длительности анимаций. Токены живут в Figma как Variables, в коде — как CSS custom properties или Tailwind config. Они не должны называться по применению («primary-button-bg») — только по семантике («brand-500», «surface-elevated»).
Минимальный набор для старта: 8–12 цветов (бренд, семантика, нейтрали), 4–5 размеров шрифта, 5–8 отступов по 4-pixel grid, 3 радиуса, 2–3 тени, 2–3 длительности. Этого хватает на 80% сайта. Расширять можно по мере необходимости.
Компоненты по слоям
Делим компоненты на три слоя. Базовые: Button, Input, Checkbox, Badge, Avatar — атомы интерфейса. Композитные: FormField, Card, NavItem — собраны из атомов. Шаблоны: Header, Footer, ProductCard — готовые секции страницы.
Начинаем сверху вниз: сначала собираем 5–7 шаблонов под реальные страницы проекта. Из них выделяем компоненты, которые повторяются. Так в DS попадает только то, что нужно, без преждевременной абстракции.
В нашем стеке базовый слой — shadcn/ui (без npm-пакета, копируем компоненты прямо в репозиторий, дальше правим под бренд). Композитный — собственные компоненты в shared/components/ui и shared/components/sections.
Связь Figma и кода
Figma Variables и Tailwind config должны жить синхронно. Это не ручная работа: либо плагин (Tokens Studio, Variables Connect), либо скрипт, экспортирующий Variables в JSON и собирающий из него tailwind.config.ts. Раз в неделю синхронизация проходит автоматически в CI.
Code Connect — официальный механизм Figma — связывает компонент в Figma с реальным кодом. Дизайнер в правой панели видит сниппет на TypeScript, разработчик одним кликом копирует. Это убивает разрыв «дизайнер нарисовал X, разработчик собрал из Y» — главный источник дизайн-долга.
Документация: Storybook и MDX
Storybook 8 — стандарт для документации компонентов в React-проекте. Каждый компонент сопровождается стори (вариантами), описанием пропсов через TypeScript, контролами для интерактивных проверок. Дизайнер открывает Storybook, видит реальный компонент с реальными пропсами и тестирует крайние случаи.
Поверх Storybook добавляем MDX-страницы с гайдами: «Когда использовать Button vs Link», «Иерархия типографики», «Шаблоны форм». Это не «дизайн-стайлгайд на 50 страниц» — это короткие памятки на 1–2 экрана с примерами.
Кто отвечает за DS
Самая частая ошибка — никто не отвечает. DS превращается в свалку. Решение: один владелец с правом мерджить изменения, регулярная встреча команды раз в неделю на 30 минут, чёткий процесс PR с обсуждением перед добавлением нового компонента.
В команде 3–6 человек владельцем обычно становится тимлид фронта или ведущий дизайнер. На крупных проектах от 10 человек — отдельная роль на 30–50% времени.
Сроки и стоимость
Базовая DS под коммерческий сайт: 2–3 недели работы дизайнера на 50% и фронта на 30%. Это 80–150 часов. После сборки добавление новых компонентов занимает 2–6 часов — против 1–2 дней без DS.
Окупается DS на втором-третьем проекте, использующем те же токены и компоненты. У нас в студии один корневой пакет shared/components/ui обслуживает три фронтенда сразу — экономия на каждом проекте около 20% часов.
Итого
Дизайн-система — это не про красоту, а про скорость и согласованность. Стартуйте с токенов, наращивайте компоненты по фактической потребности, синхронизируйте Figma и код, документируйте в Storybook. Один владелец, регулярные ревью, никакого «давайте добавим про запас» — и DS становится активом, а не очередным заброшенным репозиторием.
Частые вопросы
С чего начать создание дизайн-системы?
Первый шаг — не «нарисовать кнопку», а зафиксировать токены: цвета, типографика, отступы, радиусы, тени, длительности анимаций. Токены живут в Figma как Variables, в коде — как CSS custom properties или Tailwind config. Не должны называться по применению («primary-button-bg») — только по семантике («brand-500», «surface-elevated»). Минимум: 8–12 цветов, 4–5 размеров шрифта, 5–8 отступов по 4-pixel grid, 3 радиуса, 2–3 тени, 2–3 длительности.
Как разделять компоненты в дизайн-системе?
Делим на три слоя. Базовые: Button, Input, Checkbox, Badge, Avatar — атомы интерфейса. Композитные: FormField, Card, NavItem — собраны из атомов. Шаблоны: Header, Footer, ProductCard — готовые секции страницы. Начинаем сверху вниз: сначала собираем 5–7 шаблонов под реальные страницы проекта. Из них выделяем компоненты, которые повторяются. Так в DS попадает только то, что нужно, без преждевременной абстракции. Базовый слой — обычно shadcn/ui, композитный — собственные компоненты.
Как синхронизировать Figma с кодом дизайн-системы?
Figma Variables и Tailwind config должны жить синхронно. Это не ручная работа: либо плагин (Tokens Studio, Variables Connect), либо скрипт, экспортирующий Variables в JSON и собирающий из него tailwind.config.ts. Раз в неделю синхронизация проходит автоматически в CI. Code Connect — официальный механизм Figma — связывает компонент в Figma с реальным кодом. Дизайнер в правой панели видит сниппет на TypeScript, разработчик одним кликом копирует. Это убивает разрыв «дизайнер нарисовал X, разработчик собрал из Y».
Как документировать компоненты дизайн-системы?
Storybook 8 — стандарт для документации компонентов в React-проекте. Каждый компонент сопровождается стори (вариантами), описанием пропсов через TypeScript, контролами для интерактивных проверок. Дизайнер открывает Storybook, видит реальный компонент с реальными пропсами и тестирует крайние случаи. Поверх Storybook добавляем MDX-страницы с гайдами: «Когда использовать Button vs Link», «Иерархия типографики», «Шаблоны форм». Это короткие памятки на 1–2 экрана с примерами, не «дизайн-стайлгайд на 50 страниц».
Кто должен отвечать за дизайн-систему в команде?
Самая частая ошибка — никто не отвечает. DS превращается в свалку. Решение: один владелец с правом мерджить изменения, регулярная встреча команды раз в неделю на 30 минут, чёткий процесс PR с обсуждением перед добавлением нового компонента. В команде 3–6 человек владельцем обычно становится тимлид фронта или ведущий дизайнер. На крупных проектах от 10 человек — отдельная роль на 30–50% времени. Без чёткого владельца DS быстро становится антипаттерном проекта.
Сколько занимает и стоит создание дизайн-системы?
Базовая DS под коммерческий сайт: 2–3 недели работы дизайнера на 50% и фронта на 30%. Это 80–150 часов. После сборки добавление новых компонентов занимает 2–6 часов — против 1–2 дней без DS. Окупается DS на втором-третьем проекте, использующем те же токены и компоненты. Один корневой пакет shared/components/ui может обслуживать несколько фронтендов сразу — экономия на каждом проекте около 20% часов. Не делайте DS «на год вперёд» — стартуйте с минимума и растите по фактической потребности.