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

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

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

Різниця стає очевидна в масштабі: один продукт з однією командою справляється з UI-китом. Кілька продуктів, кілька команд, кілька платформ — без дизайн-системи починається дрейф: кожна команда робить «свою» версію кнопки, та через рік інтерфейс виглядає так, ніби його робили різні компанії.

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

1. 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, але при смені теми може стати іншим.

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

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

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

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

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

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

Storybook (v8 на 2024) — де-факто стандарт документування компонентних бібліотек. Кожен компонент описується через 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 у всіх затронутих компонентах.

Глибокий розбір: Design Token Pipeline

Синхронізація токенів між 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     │
└─────────────────────────────────────────┘

Style Dictionary настроюється через sd.config.json. Кожна платформа отримує свій трансформер: CSS отримує --color-primary-500, JS отримує { color: { primary: { 500: '#3B82F6' } } }, Tailwind отримує extend-конфіг з тими ж значеннями.

При зміні токена в Figma — дизайнер вивантажує новий tokens.json, комітить у репо, CI запускає Style Dictionary, публікує нову версію пакета на npm (якщо monorepo) або просто оновлює файли. Всі продукти, підключені до пакета, оновляються через npm update.

Версіонування та Governance

Дизайн-система — це shared dependency. Порушення контракту ломає всі підключені продукти. Тому:

• Semver: major — breaking changes (переіменування компонентів, зміна API), minor — нові компоненти, patch — bugfixes та візуальні налаштування
• Codeowners у Git: зміни в core-компонентах потребують ревью від maintainer'ів системи
• RFC process для нових компонентів — proposal документ з use-cases, альтернативами, прикладами API

Приклад структури monorepo для дизайн-системи:

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

Коли потрібна дизайн-система, а коли достатньо UI-кита

Строк реалізації

MVP дизайн-системи (токени, 20–30 компонентів у Storybook, базова документація) — 6–10 тижнів. Повнофункціональна дизайн-система з token pipeline, Chromatic, contribution guide, Figma-бібліотекою — 3–6 місяців з підтримкою на постійній основі.