Не строй дизайн-систему годами: как собрать UI-kit, токены и дашборд без боли

Большая ошибка многих продуктовых команд — начинать с экрана.

Открывается Figma, рисуется красивый дашборд, потом подключается Cursor, Figma MCP или другой AI-инструмент, и все ждут магии: «сейчас он сам сверстает как в макете». Но вместо аккуратного интерфейса часто получается набор случайных div, растровые иконки, цвета напрямую в коде, разные отступы, кнопки без системы и UI, который сложно поддерживать уже через неделю.

Проблема не в AI. Проблема в том, что AI дали не систему, а картинку.

Дашборд нужно строить не с экрана. Дашборд нужно строить с архитектуры интерфейса.

Главная мысль

Современный UI-kit — это не просто набор красивых компонентов в Figma. Это контракт между дизайном и кодом.

В этом контракте должны быть:

• токены: цвета, отступы, типографика, радиусы, тени;
• компоненты в Figma;
• компоненты в коде;
• иконная система;
• правила для AI-агентов;
• визуальные тесты;
• понятная схема обновлений.

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

Почему не стоит строить дизайн-систему в одиночку годами

Соло-дизайнер или маленькая команда часто попадают в ловушку: «Сейчас мы сделаем свою идеальную дизайн-систему с нуля».

Звучит красиво. На практике это часто означает месяцы работы над кнопками, полями, таблицами, состояниями, модалками, иконками, темизацией, документацией и edge cases.

А продукт в это время стоит.

Если вы не строите новую операционную систему, банковский интерфейс федерального масштаба или платформу с уникальной визуальной моделью, почти всегда выгоднее взять готовую основу:

• shadcn/ui;
• Ant Design;
• MUI;
• Radix Themes;
• Chakra UI;
• Mantine;
• Untitled UI;
• Tailwind-based UI kits;
• готовый Figma UI-kit с компонентами, токенами и React-реализацией.

Не обязательно брать всё «как есть». Правильный подход — купить или скачать фундамент, адаптировать под бренд и продукт, а не изобретать каждую кнопку с нуля.

Купить готовую систему — не значит потерять индивидуальность

Есть страх: «Если мы возьмём готовый UI-kit, продукт будет выглядеть как шаблон».

Будет — если ничего не менять.

Но нормальная готовая система — это не финальный дизайн. Это строительные леса.

Вы берёте:

• структуру компонентов;
• состояния;
• accessibility-паттерны;
• типовые формы;
• таблицы;
• модалки;
• навигацию;
• токены;
• документацию;
• базовую реализацию в коде.

А дальше настраиваете:

• цветовую систему;
• типографику;
• радиусы;
• плотность интерфейса;
• стиль иконок;
• тональность бренда;
• сложные продуктовые паттерны;
• уникальные сценарии.

Это как купить хороший каркас дома. Обои, мебель и характер всё равно ваши. Главное — не начинать с обжига кирпичей во дворе.

Этап 1. Сначала выбираем технологический фундамент

Перед тем как рисовать дашборд, нужно ответить на несколько вопросов:

1. На чём будет фронтенд? 2. Нужен ли React, Vue, Svelte или другой стек? 3. Используется ли Tailwind? 4. Нужна ли тёмная тема? 5. Будут ли разные бренды или white-label? 6. Будет ли мобильная адаптация? 7. Нужны ли сложные таблицы, фильтры, формы, роли, права? 8. Кто будет поддерживать систему через полгода?

Если это SaaS, AI-продукт, личный кабинет или кастомный дашборд на React/Next.js, хорошая база — shadcn/ui + Tailwind + CSS variables.

Если это enterprise-админка с таблицами, фильтрами, формами и большим количеством стандартных сценариев, можно смотреть в сторону Ant Design или MUI.

Если нужен быстрый красивый SaaS-интерфейс и есть бюджет, можно взять коммерческий UI-kit вроде Untitled UI или другой готовой системы с Figma + React-компонентами.

Главное правило: не покупать просто красивую Figma-библиотеку. Нужна связка Figma + код + токены.

Этап 2. Определяем источники правды

В дизайн-системе важно не только «что нарисовано», но и «кто главный».

Практичная схема такая:

Токены в Git → источник правды для визуальных значений
Figma Variables → зеркало токенов для дизайнеров
Кодовые компоненты → источник правды для поведения
Figma components → дизайн-представление компонентов
AI/MCP → помощник, который использует систему
Visual regression → проверка совпадения

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

Этап 3. Строим foundations

Foundations — это базовый язык интерфейса.

Сюда входят:

• цвета;
• типографика;
• отступы;
• радиусы;
• тени;
• сетка;
• breakpoints;
• z-index;
• motion;
• иконки.

Важно не использовать случайные значения.

Плохо:

color: #2563eb;
padding: 17px;
border-radius: 11px;

Хорошо:

color: var(--color-primary);
padding: var(--space-4);
border-radius: var(--radius-md);

Дизайн-система начинается там, где заканчивается «на глаз».

Этап 4. Делим токены на уровни

Хорошая токенная система обычно строится в несколько слоёв.

Primitive tokens

Это сырые значения:

blue.500
gray.100
space.4
radius.md
font.size.sm

Semantic tokens

Это значения с продуктовым смыслом:

color.bg.page
color.bg.card
color.text.primary
color.text.muted
color.border.default
color.action.primary

Component tokens

Это настройки конкретных компонентов:

button.height.md
button.radius
button.primary.bg
badge.success.bg
table.row.height
sidebar.width

Primitive tokens нужны системе. Semantic tokens нужны продукту. Component tokens нужны компонентам.

Если использовать только blue.500, дизайн будет техническим. Если использовать color.action.primary, дизайн становится продуктовым.

Этап 5. Сразу решаем, откуда берутся иконки

Иконки — одна из самых частых проблем при генерации интерфейса из Figma.

AI-агент может увидеть иконку как картинку и вставить её в код как PNG, base64 или мутный asset. В результате шестерёнка превращается в размазанный артефакт, а интерфейс выглядит так, будто его экспортировали через микроволновку.

Правильный подход: иконки должны идти из кодовой библиотеки, а не экспортироваться из макета.

Например:

<Icon name="settings" />
<Icon name="bell" />
<Icon name="trash" />

А не так:

<img src="/figma-assets/settings.png" />

В Figma иконки должны быть компонентами с понятными именами:

Icon / settings
Icon / bell
Icon / moon
Icon / trash
Icon / edit

В коде должен быть icon registry:

const icons = {
  settings: Settings,
  bell: Bell,
  trash: Trash2,
  edit: Pencil,
};

Тогда AI понимает: если в Figma стоит Icon / settings, в коде нужно использовать <Icon name="settings" />, а не вытаскивать картинку.

Этап 6. Создаём primitives

Primitives — это базовые UI-компоненты.

Минимальный набор:

• Button;
• Input;
• Textarea;
• Select;
• Checkbox;
• Radio;
• Switch;
• Badge;
• Avatar;
• Icon;
• Tooltip;
• Dropdown;
• Modal;
• Tabs;
• Table;
• Card;
• Pagination.

Для каждого компонента нужно заранее определить API.

Например Button:

<Button variant="primary" size="md">Создать</Button>
<Button variant="secondary" size="sm">Отмена</Button>
<Button variant="ghost" iconLeft="settings">Настройки</Button>

Badge:

<Badge variant="success">Активно</Badge>
<Badge variant="danger">Заблокировано</Badge>

Input:

<Input placeholder="Search" iconLeft="search" />

Чем лучше продуман API компонентов, тем меньше хаоса будет в проекте.

Этап 7. Создаём product components

После primitives появляются компоненты уровня продукта:

• Sidebar;
• SidebarItem;
• Header;
• UserMenu;
• PageHeader;
• SearchInput;
• StatusBadge;
• DataTable;
• TableActions;
• EmptyState;
• ConfirmDialog;
• FormSection;
• FilterPanel.

На этом уровне UI уже начинает говорить языком продукта.

Например:

<StatusBadge status="active" />
<StatusBadge status="blocked" />

Или:

<SidebarItem icon="briefcase" label="Организации" active />

Это лучше, чем каждый раз вручную собирать пункт меню из div, span, svg и классов.

Этап 8. Создаём шаблоны страниц

Перед конкретным дашбордом стоит сделать несколько page templates:

• List page;
• Detail page;
• Create/Edit form;
• Settings page;
• Dashboard overview;
• Empty state;
• Error state.

Например:

<EntityListPage
  title="Список организаций"
  description="Тут можно добавлять или редактировать организации"
  actions={<Button iconLeft="plus">Создать организацию</Button>}
  table={<OrganizationsTable />}
/>

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

Этап 9. Только теперь собираем дашборд

Когда есть foundations, токены, иконки, primitives, product components и templates — только тогда имеет смысл собирать конкретные экраны.

Например:

• организации;
• сотрудники;
• администраторы;
• документооборот;
• финансы;
• поддержка;
• настройки;
• профиль;
• аналитика.

На этом этапе Figma MCP, Cursor, Copilot или другой AI-инструмент начинают работать намного лучше, потому что у них есть контекст.

AI больше не должен придумывать интерфейс с нуля. Он должен использовать готовую систему.

Правильная задача для AI звучит так:

Собери страницу организаций из существующих компонентов.
Используй Button, Input, Badge, DataTable, Sidebar, Header.
Не создавай новые цвета.
Не экспортируй иконки.
Не используй raw px, если есть токены.
Не создавай новые компоненты без необходимости.

Это принципиально другой уровень результата.

Этап 10. Добавляем правила для AI

Если вы используете Cursor или другой AI-first workflow, правила должны быть записаны явно.

Например:

Все цвета брать только из CSS variables.
Все иконки брать только из Icon component.
Все кнопки делать через Button component.
Не использовать PNG/base64 для UI-иконок.
Не создавать новые variants без согласования.
Если нет подходящего компонента — предложить расширение дизайн-системы.

AI не должен быть свободным художником. Он должен быть быстрым джуном, который строго работает по дизайн-системе.

Этап 11. Подключаем визуальную проверку

Pixel-perfect нельзя гарантировать словами. Его нужно проверять.

Минимальный набор:

• Storybook для компонентов;
• визуальные тесты компонентов;
• Playwright screenshot tests для страниц;
• ревью изменений в токенах;
• запрет raw colors и случайных отступов через линтеры или code review.

Важно понимать: абсолютный pixel-perfect между Figma и браузером невозможен на 100%. Разные браузеры, операционные системы, шрифты, subpixel rendering и antialiasing всё равно дадут отличия.

Но можно добиться инженерно стабильного результата: когда интерфейс не «на глаз похож», а системно совпадает.

Когда покупать готовую дизайн-систему

Готовую систему стоит брать, если:

• вы маленькая команда;
• вы запускаете MVP;
• продукт типовой: SaaS, CRM, админка, маркетплейс, кабинет;
• нет отдельной дизайн-системной команды;
• нужно быстро выйти в production;
• важнее скорость, чем уникальная визуальная философия;
• вы хотите использовать AI для генерации интерфейсов.

В таком случае покупка или скачивание готовой базы почти всегда дешевле, чем месяцы ручной разработки.

Когда строить свою с нуля

Свою систему с нуля стоит делать, если:

• продукт очень большой;
• есть несколько команд;
• есть уникальные UX-паттерны;
• нужен строгий brand differentiation;
• есть особые требования accessibility, compliance или security;
• система будет использоваться годами в десятках продуктов;
• есть люди, которые будут её поддерживать.

Если этих условий нет, кастомная дизайн-система с нуля может стать дорогой игрушкой.

Что проверять перед покупкой UI-kit

Не покупайте UI-kit только потому, что у него красивые превью.

Проверьте:

• есть ли Figma components;
• есть ли variables/tokens;
• есть ли dark mode;
• есть ли React/Vue/components в коде;
• есть ли документация;
• есть ли состояния: hover, active, disabled, loading, error;
• есть ли формы и таблицы;
• есть ли responsive-паттерны;
• есть ли иконная система;
• можно ли менять тему;
• насколько легко подключить к вашему стеку;
• понятная ли лицензия.

Если UI-kit есть только в Figma, это не дизайн-система. Это набор красивых картинок.

Практичный стек для AI-first продукта

Для современного AI-first workflow хорошая схема может выглядеть так:

Figma
+ готовый Figma UI-kit
+ Figma Variables
+ React components
+ CSS variables / tokens
+ Tailwind
+ Icon registry
+ Cursor rules
+ Figma MCP
+ Code Connect
+ Storybook
+ Visual regression

Суть не в одном инструменте. Суть в связке.

Figma даёт дизайн-контекст.

Токены дают визуальный контракт.

Кодовые компоненты дают поведение.

AI ускоряет сборку.

Тесты защищают от хаоса.

Самая короткая формула

Не начинайте с дашборда.

Начинайте с системы.

Сначала foundations.
Потом токены.
Потом иконки.
Потом primitives.
Потом product components.
Потом templates.
Потом экраны.

И если вы работаете один или маленькой командой — не стесняйтесь брать готовую дизайн-систему.

Не нужно героически строить свой UI-kit годами, если рынок уже дал хорошие фундаменты.

Лучше взять готовую основу, адаптировать её под продукт, подключить токены, настроить компоненты и начать делать реальные экраны.

Пользователю всё равно, сколько месяцев вы полировали радиус кнопки.

Ему важно, чтобы продукт работал, выглядел цельно и не разваливался при первом новом экране.

Вывод

Дизайн-система — это не про красоту ради красоты. Это про скорость, качество и управляемость.

Готовая система экономит месяцы. Токены дают порядок. Компоненты дают масштабирование. AI даёт скорость. Визуальные тесты дают уверенность.

А дашборд — это уже не стартовая точка. Это результат правильно собранной системы.

Если строить наоборот, получится хаос.

Если строить в правильном порядке, получится продукт.