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

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

Представьте: ваш продукт растёт, появляются новые модули, несколько команд параллельно пишут интерфейсы. Через полгода одни и те же элементы — кнопки, формы, карточки — выглядят по-разному в разделах. Дизайнеры рисуют вариации, разработчики множат CSS-классы, скорость разработки падает. Это типичная проблема масштабирования, и решает её дизайн-система.

Дизайн-система — это не просто UI-кит. Это живая инфраструктура: код компонентов, документация, процессы синхронизации между дизайном и разработкой. Она устраняет дрейф интерфейсов и ускоряет вывод новых экранов. По нашим данным, команды с дизайн-системой тратят на 30–50% меньше времени на разработку интерфейсов. Экономия бюджета на интерфейсах достигает 40%.

В одном из наших проектов на стартапе с 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 лет разработки дизайн-систем для продуктовых команд — подтверждает: начальные вложения окупаются в течение полугода. Например, один из клиентов сократил время разработки нового модуля на 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     │
└─────────────────────────────────────────┘

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

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

Версионирование и Governance

Дизайн-система — это shared dependency. Нарушение контракта ломает все подключённые продукты. Поэтому:

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

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

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 месяцев с поддержкой на постоянной основе.

Что входит в нашу работу

• Аудит текущих UI-решений и выявление болевых точек.
• Проектирование системы токенов (цвета, типографика, отступы).
• Разработка компонентной библиотеки на вашем стеке (React, Vue, Angular).
• Настройка Storybook с визуальным регрессионным тестированием через Chromatic.
• Интеграция токенов с Figma через Tokens Studio и автоматический CI/CD.
• Создание документации и гайдлайнов для команды.
• Contribution guide и governance процессы.
• Поддержка после внедрения: обновления, ревью изменений, консультации.

Стоимость рассчитывается индивидуально под ваш проект. Оценим объём работ и предложим оптимальный план. У нас за плечами более 15 успешных проектов по внедрению дизайн-систем для продуктовых команд. Получите консультацию — мы поможем выбрать правильный подход.

Почему дизайн без токенов ломает код, и как мы это чиним

Мы перестраиваем процесс UX/UI так, чтобы дизайн и код не расходились. Наш опыт — 5 лет на рынке, 120+ реализованных проектов в вебе и мобильных приложениях. Работаем по договору с фиксированной гарантией сроков. Часто к нам приходят с макетами, которые разработчики получают за два дня до спринта: 80 фреймов, половина без мобильных состояний, кнопки не компоненты, цвета захардкожены hex-значениями. Вёрстка превращается в угадайку, а поддержка UI через три месяца требует полного рефакторинга. Дизайн, который работает в продакшене, строится на системе токенов и компонентов — и мы это внедряем с первого спринта.

Как Figma превращается в инженерный инструмент

Figma — не просто «место, где рисуют». Это среда, из которой разработчик получает точные значения без звонков дизайнеру. Мы используем Design Tokens — единые переменные для цветов, отступов, радиусов. Они экспортируются напрямую в CSS custom properties или Tailwind config. Например, color/primary/500, spacing/md, radius/button. Без токенов дизайн и код расходятся уже через месяц.

Auto layout — обязательное условие. Компоненты без авто-лейаута ломаются при изменении текста. Кнопка с фиксированной шириной, которая не растягивается под длинный лейбл — классическая ошибка, которую мы не допускаем. С variants в одном component set разработчик видит все состояния (hover, disabled, pressed) сразу, а не переспрашивает перед каждым блоком. Интерактивный прототип дешевле правок после разработки — мы кликаем сложные сценарии (multi-step, wizard, onboarding) до того, как писать код.

Что дают дизайн-системы и когда они избыточны

Design system оправдана, когда над проектом работают 2+ дизайнера или есть несколько связанных продуктов (веб + мобильное приложение + админка). Для сайта-визитки мы ограничиваемся UI kit с базовыми компонентами. Если проект на React, строим систему поверх Radix UI (headless) с Tailwind CSS — как в Shadcn/ui. Компоненты полностью контролируемы, нет lock-in на стороннюю библиотеку. Wikipedia называет такой подход стратегически правильным для масштабирования.

Как мы обеспечиваем адаптивность без сюрпризов

По данным аналитики, планшеты дают 8–12% трафика в зависимости от ниши — игнорировать их нельзя. Но мы не делаем «десктоп + мобильный» с тремя брейкпоинтами. Проектируем под систему значений, совместимую с кодом: если фронтенд на Tailwind CSS, то sm:640, md:768, lg:1024, xl:1280, 2xl:1536. Дизайнер работает с теми же числами в Figma. Fluid typography и spacing через clamp() убирают скачки на нестандартных разрешениях — лендинги и публичные сайты получают плавное поведение без дополнительных усилий.

Что входит в работу (deliverables)

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

Дополнительно: обучение команды работе с дизайн-системой (1–2 часа), доступ к Figma на весь период разработки, поддержка при внедрении.

Как мы гарантируем качество UI

Каждый макет проверяется инженером на реализуемость: нет ли конфликтов между auto layout, корректно ли работают состояния на мобильных, доступен ли контраст (WCAG AA). Мы используем Clarity для анализа текущего юзабилити, и на основе данных переделываем формы, которые теряют конверсию. Типичный результат — inline-валидация вместо submit-and-scroll-to-top увеличивает завершение регистрации на 15–20%. Skeleton screens вместо спиннеров снижают субъективное время загрузки.

Ориентиры по срокам и стоимости

Сроки зависят от количества уникальных экранов и сложности компонентной базы. Стоимость рассчитывается индивидуально — пишите, и мы оценим проект за 1 рабочий день. Получите консультацию по вашему сценарию — расскажем, на каких страницах UX теряет конверсию и как это исправить.