Розробка дизайн-системи мобільного додатка
Дизайн-система — це не 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" та "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 або кастомний). Всі іконки — одного стилю, одної сітки (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 + widget-бібліотека. 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% екранів. Решта — в наступних ітераціях. Система, яка будується три місяці до першого використання, не дожива до другої версії.
Вартість розраховується індивідуально після аудиту продуктів, які будуть використовувати систему, та числа команд.