Розробка дизайн-системи веб-застосунку: токени, компоненти, процеси

Розробка дизайн-системи веб-застосунку

Ми знаємо, як це: ваш продукт зростає, з'являються нові модулі, кілька команд паралельно пишуть інтерфейси. Через півроку одні й ті самі елементи — кнопки, форми, картки — виглядають по-різному в розділах. Дизайнери малюють варіації, розробники множать CSS-класи, швидкість розробки падає. Це типова проблема масштабування, і вирішує її дизайн-система.

Дизайн-система — це не просто UI-кіт. Це жива інфраструктура: код компонентів, документація, процеси синхронізації між дизайном і розробкою. Вона усуває дрейф інтерфейсів і прискорює виведення нових екранів. За нашими даними, команди з дизайн-системою витрачають на 30–50% менше часу на розробку інтерфейсів. Економія бюджету на інтерфейсах досягає 40%. Наприклад, MVP дизайн-системи починається від $12,000 і окупається протягом 6 місяців.

В одному з наших проєктів на стартапі з 5 розробниками через рік інтерфейси розійшлися настільки, що кожна кнопка мала 4 стилі. Після впровадження дизайн-системи цей же проєкт скоротив час розробки нових екранів на 40% і перестав витрачати ресурси на правки неузгоджених стилів.

З чого складається дизайн-система

Design Tokens — атомарний рівень. Іменовані змінні для всіх візуальних рішень:

{ "color": { "primary": { "50": { "value": "#EFF6FF" }, "500": { "value": "#3B82F6" }, "900": { "value": "#1E3A5F" } }, "semantic": { "background-default": { "value": "{color.neutral.50}" }, "text-primary": { "value": "{color.neutral.900}" }, "border-interactive": { "value": "{color.primary.500}" } } }, "spacing": { "xs": { "value": "4px" }, "sm": { "value": "8px" }, "md": { "value": "{spacing.sm} * 2" } } } 

Семантичні токени — ключова відмінність від просто палітри. color.primary.500 — це конкретний колір. color.semantic.border-interactive — це роль: колір інтерактивного бордера, який зараз дорівнює primary.500, але при зміні теми може стати іншим.

Компонентна бібліотека (code) — React/Vue/Angular компоненти, що реалізують кожен елемент UI-кіта. Для React-стека типовий вибір:

• Headless-компоненти (Radix UI, Headless UI, Ark UI) + власні стилі через CSS Modules або Tailwind
• Готові стилізовані бібліотеки (Shadcn/ui, Mantine, Ant Design) з кастомізацією через токени
• Повністю кастомна реалізація (для унікальних вимог до дизайну)

Документаційний сайт — Storybook як стандарт де-факто. Кожен компонент документується в ізоляції: всі варіанти, всі стани, всі props з типами, приклади коду, accessibility-вимоги.

Figma-бібліотека — Published компоненти в Figma, доступні всім файлам організації через Libraries. Синхронізована з кодовою бібліотекою: однакові імена компонентів і варіантів.

Процеси — contribution guidelines (як запропонувати новий компонент), versioning (semver для бібліотеки), deprecation policy (як виводити застарілі компоненти), review process.

Як дизайн-система прискорює розробку?

Дослідження показують, що команди з дизайн-системою витрачають на нові екрани на 30–50% менше часу. Єдиний візуальна мова підвищує впізнаваність бренду і знижує кількість багів на стику компонентів. Наш досвід — більше 8 років розробки дизайн-систем для продуктових команд — підтверджує: початкові вкладення окупаються протягом півроку. Наші клієнти підтверджують: дизайн-система скорочує час розробки в 1.5–2 рази порівняно з традиційним підходом. Наприклад, один із клієнтів скоротив час розробки нового модуля на 40% після впровадження.

Глибокий розбір: Storybook та інтеграція з тестами

Storybook — де-факто стандарт документування компонентних бібліотек. Кожен компонент описується через stories — іменовані варіанти використання:

// Button.stories.tsx import type { Meta, StoryObj } from '@storybook/react'; import { Button } from './Button'; const meta: Meta<typeof Button> = { title: 'Components/Button', component: Button, argTypes: { variant: { control: 'select', options: ['primary', 'secondary', 'ghost', 'destructive'], }, size: { control: 'radio', options: ['sm', 'md', 'lg'], }, }, }; export default meta; type Story = StoryObj<typeof Button>; export const Primary: Story = { args: { variant: 'primary', children: 'Click me' }, }; export const Disabled: Story = { args: { variant: 'primary', disabled: true, children: 'Disabled' }, }; 

На основі stories автоматично запускаються:

• Chromatic (візуальний регресійний тест) — скріншотить кожну story і порівнює з baseline. Будь-яка візуальна зміна — диффи на review.
• @storybook/addon-a11y — автоматична перевірка accessibility через axe-core прямо в Storybook.
• Interaction tests — @storybook/test дозволяє писати тести поведінки прямо в story-файлах.

Це дозволяє впіймати регресію до деплою: розробник змінив відступи в кнопці — Chromatic одразу показує diff у всіх зачеплених компонентах. Порівняно з ручними перевірками, такий підхід у 10 разів швидше виявляє регресії.

Переваги Chromatic

Chromatic автоматизує візуальне регресійне тестування та вбудовується в CI. Достатньо один раз налаштувати скріншоти — і кожна зміна буде перевірена на відповідність еталону. Це знижує навантаження на QA і спрощує рев'ю дизайну.

Налаштування пайплайну токенів

Синхронізація токенів між Figma та кодом — найболючіша частина дизайн-системи. Ми використовуємо перевірений ланцюжок:

Figma Variables ↓ (експорт через Tokens Studio або Figma Variables API) tokens.json (W3C Design Tokens формат) ↓ (Style Dictionary трансформація) ┌─────────────────────────────────────────┐ │ CSS Custom Properties → tokens.css │ │ JavaScript object → tokens.js │ │ Tailwind config → tailwind.config│ │ iOS Swift → Colors.swift │ │ Android XML → colors.xml │ └─────────────────────────────────────────┘ 

design-system/ ├── packages/ │ ├── tokens/ # Design tokens, Style Dictionary │ ├── icons/ # SVG іконки + React-компоненти │ ├── react/ # React компонентна бібліотека │ └── docs/ # Storybook ├── figma/ # Figma export files └── .changeset/ # Changesets для версіонування