Разработка дизайн-системы мобильного приложения
Дизайн-система — это не UI-кит с документацией. Это инфраструктура: набор соглашений, инструментов и процессов, которые обеспечивают консистентность продукта при работе нескольких команд одновременно. Компания с одним приложением и двумя дизайнерами может обойтись хорошим UI-китом. Компания с тремя продуктами, шестью дизайнерами и пятнадцатью разработчиками — нет.
Главная задача дизайн-системы — убрать дизайн-решения из категории «каждый раз заново» и перевести их в категорию «уже решено, берём готовое». Сколько вариантов кнопок должно быть? Какой отступ между секциями? Как выглядит empty state? На эти вопросы система отвечает один раз.
Архитектура дизайн-системы для мобильных
Уровень 1: Дизайн-токены
Токены — фундамент. Не просто именованные цвета, а семантически связанная система:
Primitive tokens:
color-blue-500 = #2563EB
color-blue-600 = #1D4ED8
Semantic tokens:
color-action-primary = {color-blue-500}
color-action-primary-hover = {color-blue-600}
Component tokens:
button-primary-background = {color-action-primary}
button-primary-background-pressed = {color-action-primary-hover}
Трёхуровневая система позволяет менять брендинг (поменял primitive) без правки компонентов. Токены живут в JSON, синхронизируются между Figma (через Tokens Studio) и кодом (через Style Dictionary). На выходе — platform-specific файлы: Colors.swift для iOS, colors.xml + MaterialTheme для Android, theme.ts для React Native.
Для тёмной темы и кастомизации — Mode-based tokens. В Figma Variables: Mode "Light" и Mode "Dark" для каждого семантического токена. Переключение темы меняет весь UI через одну переменную.
Уровень 2: Foundations
Типографика с полной спецификацией: гарнитура, начертание, размер, line-height, letter-spacing, использование — для каждого стиля (Display, Headline, Title, Body, Label, Caption). iOS-специфика: Dynamic Type поддержка — каждый стиль привязан к UIFont.TextStyle или масштабируется относительно него. Android: соответствие Material Type Scale.
Spacing system: сетка на 4pt/8pt с именованными шагами (xs=4, sm=8, md=16, lg=24, xl=32, 2xl=48). Все отступы в компонентах и макетах — кратны базовому шагу.
Иконографика: единый icon set (Phosphor, Lucide, Material Symbols или кастомный). Все иконки — одного стиля, одного grid (24×24 или 20×20), правила использования filled vs. outlined.
Уровень 3: Компоненты
Компоненты в дизайн-системе строже, чем в обычном UI-ките:
- Каждый компонент — задокументирован: назначение, анатомия, варианты, состояния, когда использовать, когда нет
- API компонента в Figma (через Component Properties) соответствует props компонента в коде
- Изменения в компоненте — через changelog, не молчаливым обновлением
Для мобильных приложений — полный набор: навигационные компоненты (Tab Bar, Navigation Bar, Bottom Sheet), формы (Input, Select, Checkbox, Radio, Toggle, Slider, Date Picker), отображение данных (Card, List, Table, Badge), обратная связь (Toast, Dialog, Progress, Skeleton), маркетинговые (Banner, Callout, Illustration placeholders).
Все компоненты — с Auto Layout, с поддержкой минимум двух цветовых схем (light/dark).
Уровень 4: Паттерны
Паттерны — это не компоненты, а повторяющиеся UX-решения: как строится экран авторизации, как работает onboarding, как оформляется пустое состояние раздела. Документируются как best practices с примерами, а не как жёсткие шаблоны.
Governance: кто и как обновляет систему
Без процесса дизайн-система превращается в устаревшую библиотеку, которой никто не пользуется. Нужны:
Contribution process — как команды предлагают новые компоненты. Запрос → дизайн → review → апрув → публикация. Не каждый решает сам.
Versioning — семантическое версионирование (major.minor.patch). Breaking changes — major версия, новые компоненты — minor, фиксы — patch. Синхронно в Figma (через Library updates) и в npm-пакете/Swift Package.
Deprecation policy — компоненты не удаляются молча. Deprecated → migration guide → удаление через два-три minor версии.
Связь с кодовой базой
Дизайн-система без кодовой реализации — это красивый Figma-файл, не больше. Реализация зависит от стека:
React Native — компонент-библиотека в отдельном пакете (monorepo, Nx или Turborepo). Storybook for React Native для документации и визуальное регрессионное тестирование через Chromatic или аналог.
Flutter — пакет с кастомным ThemeData extension + виджет-библиотека. Widgetbook для документации компонентов.
Native iOS — Swift Package с UIKit/SwiftUI компонентами, цветовыми расширениями (UIColor.primary, Color.primary), кастомными UIFont helpers для Dynamic Type.
Native Android — Maven-артефакт с Material Components расширениями, кастомной темой через Theme.AppCompat наследование, Compose-компонентами в отдельном модуле.
Синхронизация токенов через CI: при изменении JSON-файлов токенов — автоматическая регенерация platform-specific файлов и PR в репозиторий.
Что реально занимает время
Не сами компоненты. Компоненты — это 30–40% работы. Остальное — токены (особенно dark mode), документация, governance-процесс, согласование с разработчиками API компонентов, миграция существующих экранов на систему.
Поэтому честный таймлайн для дизайн-системы с нуля — 1–2 недели только на дизайн-часть (без кодовой реализации). С кодовой реализацией — месяц и больше, зависит от охвата платформ.
Типичные ошибки запуска
Делать всё сразу. Первая версия дизайн-системы должна покрывать 20% компонентов, которые используются в 80% экранов. Остальное — в следующих итерациях. Система, которая строится три месяца до первого использования, не доживает до второй версии.
Стоимость рассчитывается индивидуально после аудита продуктов, которые будут использовать систему, и числа команд.