UX/UI дизайн для мобільних застосунків
Дизайнер надсилає макет — красивий, з градієнтами та кастомними компонентами. Розробник відкриває його і розуміє: кнопка 36pt, тап-зона 20pt. На iPhone SE вона фізично не натискається великим пальцем. Bottom sheet перекриває контент при появі клавіатури. Навігація побудована проти нативної моделі iOS. Apple відхилить програму або користувачі залишать через тиждень — залежить від удачі з ревю.
Мобільний UX/UI — це не адаптація веб-дизайну. Це окрема дисципліна з конкретними обмеженнями платформи.
Human Interface Guidelines та Material Design 3: чому відступ від них дорого коштує
Apple HIG та Google Material Design 3 — не естетичні рекомендації. Це задокументовані очікування користувачів, сформовані роками використання системних програм.
HIG визначає: мінімальна тап-зона 44×44 pt, безпечні відступи для notch і Dynamic Island, стандартні жести (swipe back на iOS, back gesture на Android 10+). Ігнорування safe area — поширена помилка. safeAreaLayoutGuide в UIKit та safeAreaPadding в SwiftUI існують саме для цього. Дизайнер, який не додав відступи від safe area в Figma, гарантує баг при верстці.
Material Design 3 приніс Dynamic Color — колірна схема генерується з шпалер користувача через MaterialTheme.colorScheme в Jetpack Compose. Програма, що ігнорує dynamic colors на Android 12+, виглядає чужорідно. Не критично для нішевих продуктів, але помітно в масових.
Найбільш болючі невідповідності платформенним рекомендаціям, які ми зустрічаємо на проектах:
- Кастомна навігація поверх системної. Користувач iOS очікує swipe back з будь-якої точки лівого краю. Кастомний NavigationController без інтерактивного жесту це ламає. Користувач Android очікує системну back-кнопку — кастомна кнопка в лівому куті не замінює її повністю.
- Модальні вікна замість навігаційних переходів. Bottom sheet доцільний для дій, не для навігації контентом.
- Відсутність haptic feedback. UIImpactFeedbackGenerator на iOS — це не прикраса, це частина відклику інтерфейсу. Кнопки, свайпи, підтвердження без тактильного відклику ощущаются як сломані.
Figma як основний інструмент: як витиснути максимум
Figma Variables API (з'явився в Figma 2023) змінив робочий процес. Design tokens — кольори, типографіка, радіуси, відступи — зберігаються як змінні та експортуються прямо в код через figma-tokens або style-dictionary. Це усуває ручне перекладання значень та рассинхронізацію між дизайном та реалізацією.
Auto Layout з wrap та spacing між елементами дозволяє будувати компоненти, які поводяться як flex-контейнери. Розробники відкривають компоненти та бачать не статичні артефакти, а описи поведінки при різних розмірах контенту.
Component Properties — variants, boolean toggles, instance swaps — дають можливість зібрати повноцінну дизайн-систему прямо в Figma. Кнопка з 4 станами (default, hover, pressed, disabled), 3 розмірами та 2 варіантами іконки — один компонент, не 24 фрейми.
Figma Prototype з Variables дозволяє зробити інтерактивний прототип з реальним станом: показати, як екрани змінюються при різних значеннях змінних. Це вже не просто «кліка́бельний макет», а повнофункціональний інструмент для UX-тестування.
Прототипування та UX-тестування до розробки
Найдорожча помилка в мобільному продукті — розробити фічу, випустити її та виявити, що користувачі не розуміють, як вона працює. Figma-прототип при тестуванні коштує нульових годин розробки. Переробка готового екрана коштує днів.
Для usability-тестування використовуємо Maze (тести задач на прототипі — користувачі проходять сценарії, ми отримуємо heatmaps та mis-click rate) або UserTesting. Ключові метрики — task completion rate та time on task, не «подобається / не подобається».
A/B-тест на мобілці складніший, ніж у вебі: App Store не дозволяє менювати UI без оновлення програми. Тому тестуємо гіпотези на прототипі до релізу, не через production-експерименти.
Анімації: між «живим» інтерфейсом та батареєю
Анімації на мобілці — це зворотний зв'язок. Елемент з'являється не миттєво — він приходить у потрібний стан за 200–350 мс. Це дає мозку контекст для розуміння того, що сталось.
iOS: withAnimation у SwiftUI, UIViewPropertyAnimator у UIKit для інтерактивних анімацій з можливістю переривання. Spring-анімації з dampingRatio — основа більшості системних переходів Apple.
Android: AnimatedVisibility, animateContentSize, Crossfade в Compose. MotionLayout для складних сцен з кількома трансформаціями.
Flutter: AnimationController + Tween, Hero-анімації між екранами, Lottie для After Effects-експортів. Lottie особливо ефективен для onboarding-ілюстрацій та пустих станів.
Ключове обмеження — 16 мс на кадр (60 fps) або 8 мс (120 fps на ProMotion-пристроях). Анімації повинні працювати на GPU через CALayer/RenderThread, не на CPU через layoutSubviews. Профілювання через Core Animation instrument в Xcode — обов'язковий крок перед релізом анімованих екранів.
Доступність: не опціональна функція
VoiceOver на iOS та TalkBack на Android використовують кілька відсотків користувачів — в абсолютних числах для крупної програми це тисячі людей. Крім цього, App Store rejections за accessibility трапляються, хоча рідко.
Мінімальний чеклист:
- Всі інтерактивні елементи мають
accessibilityLabel - Контрастність тексту не менше 4.5:1 (WCAG AA)
- Dynamic Type підтримується — інтерфейс не ламається при максимальному розмірі шрифту
- Фокус VoiceOver проходить по екрану в логічному порядку
SwiftUI автоматично генерує accessibility tree з семантики компонентів. UIKit потребує ручного розставлення accessibilityTraits, accessibilityHint, групування через shouldGroupAccessibilityChildren.
Процес та орієнтири
Проектування UX/UI проходить етапи: дослідження та аналіз конкурентів → user flows та wireframes → дизайн-система → UI-макети → прототип → тестування → передача в розробку.
Орієнтири за тривалістю:
| Обсяг | Період |
|---|---|
| Редизайн 3–5 екранів | 1–2 тижні |
| MVP (10–15 екранів) | 3–5 тижнів |
| Повнофункціональний продукт (30+ екранів) | 6–10 тижнів |
Вартість розраховується після аналізу вимог — кількість екранів, складність компонентів, потреба у дизайн-системі або робота з існуючою.