Что входит
в дизайн-систему

Под фразой «дизайн-система» каждый понимает своё. Один клиент имеет в виду набор макетов в Figma, второй — Storybook с React-компонентами, третий — целую внутреннюю платформу с генерацией кода. В этом гайде разберём, что реально должно быть в дизайн-системе, чтобы она называлась так оправданно — а не была просто «UI-кит с громким названием».

Дизайн-система ≠ UI-кит

Это первое, что путают. UI-кит — это статичный набор компонентов в Figma. Дизайн-система — это связка из трёх слоёв:

• Дизайн-токены (цвета, отступы, типографика, тени, радиусы) — single source of truth в форматах JSON, CSS-переменных или Style Dictionary.
• Компоненты — реализация в Figma (для дизайнеров) И в коде (React/Vue/Web Components — для разработчиков), синхронизированные между собой.
• Документация и принципы — гайдлайны использования, паттерны, do/don't, accessibility-нормы.

UI-кит — это первый слой. Без второго и третьего вы не получите главного эффекта дизайн-системы: единообразие продукта при росте команды.

Слой 1: токены

Токены — это атомы дизайна. Вместо «цвет #c48a28» в коде стоит --color-accent. Вместо «отступ 24px» — --space-md. Если завтра меняете акцентный цвет, меняете его в одном месте — обновляется весь продукт.

Минимальный набор токенов:

• Цвета: primary/secondary/accent палитра + семантические (success, error, warning, info) + neutral (5-7 оттенков серого).
• Типографика: шрифты, размеры (h1-h6, body-lg/md/sm), межстрочные, веса.
• Отступы: 4/8/12/16/24/32/48/64/96 (модульная шкала на основе 4 или 8px).
• Радиусы: 0/4/8/12/16/24/full.
• Тени: sm/md/lg/xl с подписями по контексту (carded, floating, overlaid).
• Длительности анимаций: 150/250/400ms + готовые easing-функции.
• Z-index'ы: dropdown/sticky/fixed/modal/popover/tooltip.

Где хранить:

В Figma как Variables (Local или Library). В коде — CSS custom properties (--color-primary: #c48a28) или Style Dictionary, который генерирует CSS, JS, iOS, Android токены из одного JSON.

Слой 2: компоненты

Компонент — это переиспользуемый UI-элемент с чётким API. Не «вот картинка кнопки», а «Button с props: variant, size, icon, loading, disabled». В коде, в Figma, в документации — одинаковое поведение.

Иерархия:

• Primitives: Box, Stack, Text, Icon — атомарные строительные блоки.
• Inputs: Button, Input, Textarea, Select, Checkbox, Radio, Switch, Slider.
• Display: Card, Tag, Badge, Avatar, Tooltip, Toast, Progress.
• Layout: Container, Grid, Section, Divider, Modal, Sheet, Tabs.
• Patterns: Form, NavBar, Footer, Hero, FeatureGrid — высокоуровневые композиции.

Что обязательно в каждом компоненте:

• Состояния: default, hover, focus, active, disabled, loading.
• Варианты: размеры (sm/md/lg), типы (primary/secondary/ghost/destructive).
• Адаптив: как ведёт себя на мобильном.
• Accessibility: aria-атрибуты, keyboard navigation, focus management, контраст.
• Темизация: light/dark/brand вариант через токены.

Если компонент в Figma и в коде делают разные вещи — это не компонент дизайн-системы, это два разных компонента, которые просто похоже называются.

Слой 3: документация

Самый часто пропускаемый слой. Без документации дизайн-система используется неправильно — каждый дизайнер интерпретирует токены по-своему, разработчик не знает, какой компонент применить в конкретной ситуации.

Что должно быть в документации:

• Принципы: 3-5 строчек о том, как принимать решения о дизайне ("Меньше — лучше", "Контент — главное", и т.д.).
• Use cases: для каждого компонента — когда применять, когда НЕ применять. Примеры do/don't.
• API: список props, событий, slots с описаниями.
• Accessibility-чеклист: что проверить перед коммитом нового компонента.
• Дизайн-decisions: почему мы выбрали именно эти токены, эти размеры.
• Changelog: что менялось и почему. Breaking changes отдельно.

Где документировать:

Лучший инструмент сейчас — Storybook + MDX. Это одновременно живая песочница с компонентами и текст-документация. Дизайнеры могут смотреть как работает компонент в реальном времени, разработчики копируют сниппеты прямо оттуда.

Альтернативы: Zeroheight, Supernova, Backlight — платформы для дизайн-систем, которые синхронизируют Figma и код. Дороже Storybook, но проще для не-технических команд.

Кто и за сколько

Дизайн-система — это серьёзный проект, не отдельные часы. Реальные цифры по моему опыту:

• Минимальная (50 компонентов): ~100 часов на дизайн + 80 часов на разработку = ~350 000 ₽ при моей ставке.
• Полноценная (150+ компонентов с Storybook): 300+ часов суммарно = от 1 000 000 ₽.
• Поддержка: 8-16 часов в месяц на обновления, фиксы багов, новые компоненты.

Это окупается за 6-12 месяцев на проекте с командой от 3 человек. На стартапе с одним разработчиком — может быть избыточно. Используйте готовые: Radix UI, Headless UI, shadcn — для скорости.

Топ-3 ошибки в моих кейсах

За 13 проектов я налажал во всех этих местах, и теперь стараюсь предупреждать клиентов на старте:

1. Делать дизайн-систему вначале

Соблазнительно: «давайте сразу всё правильно». Реальность: без живого продукта вы не знаете, какие компоненты нужны. Делайте сначала продукт, потом извлекайте дизайн-систему из паттернов, которые повторяются.

2. Слишком гибкие компоненты

Компонент с 25 props — это не компонент, это анти-компонент. Если разработчик может сделать с ним всё что угодно — теряется унификация. Лучше 3 чётких варианта Button, чем один с 12 настройками.

3. Дизайнер обновляет Figma, разработчик не знает

Без синхронизации Figma ↔ код — каждый месяц расхождения. Решение: либо Figma как single source of truth с экспортом токенов через CLI (Figma Tokens), либо платформа типа Supernova.