Підготовка дизайну мобільного додатку до будь-яких екранів

Мобільний дизайн, зроблений під один розмір екрану — iPhone 15 Pro 393×852pt — це половина роботи. У реальності додаток запускається на iPhone SE з екраном 375×667pt, на Android-бюджетниках з 360×640dp, на флагманах з 430pt по ширині. Макет, який виглядає ідеально на дизайнерському фреймі, обрізає кнопки на маленьких екранах і залишає пусті поля на великих. Ми стикаємося з цим щодня: клієнт надсилає Figma-файл з одним розміром, а на тестах з'ясовується, що кнопка «Купити» ховається під Tab Bar. Це веде до відхилень на App Store Review та втрати конверсії.

Роздільні здатності екранів смартфонів варіюються від 320×480 до 1440×3040 пікселів, тому адаптація дизайну мобільного додатку є критично важливою.

Процес адаптації дизайну під різні екрани

Адаптація дизайну мобільного додатку починається з аудиту поточних макетів. Ми виявляємо проблемні місця: переповнення контентом, невраховані Safe Area, нечитабельну типографіку. Потім створюємо контрольні фрейми для 3–4 ключових розмірів та коригуємо відступи, масштаби зображень, кількість колонок. Результат — Figma-файл з налаштованим Auto Layout та гайд для розробників.

Що конкретно адаптуємо

Ключові точки розлому — не розміри, а пропорції. Екран iPhone SE з співвідношенням сторін 16:9 проти iPhone 15 Pro Max з 19.5:9 — різниця суттєва. Bottom-anchored елементи (Tab Bar, floating кнопки, sticky footer у формах) повинні коректно працювати на обох. Safe Area — окрема історія. Відповідно до Apple Human Interface Guidelines, Safe Area на iPhone з Dynamic Island становить 59pt зверху. На iPhone без чубчика (SE 3rd gen) — 20pt. На Android — notch буває різним або відсутній. Контент, який «прилипає» до статусбару без врахування Safe Area, гарантовано отримує відхилення на App Store Review.

Типографіка на маленьких екранах: текст 16sp читається нормально на 6-дюймовому екрані, але на 4.7-дюймовому при щільності 326 ppi — вже на межі. Мінімальний розмір для body text на мобільних — 14pt/sp, і це не рекомендація, а практичний мінімум для більшості шрифтів. Ми використовуємо динамічну типографіку: на маленьких екранах заголовки зменшуємо на 2pt, на великих — збільшуємо.

Адаптація для iOS та Android

Підходи різні. iOS використовує Auto Layout з співвідношеннями (Aspect Ratio, Multiplier), Android — ConstraintLayout з percent або Guideline. Ми проектуємо в Figma за допомогою Auto Layout та Constraints, потім для кожної платформи готуємо окремі гайди. На практиці Auto Layout в Figma + SwiftUI Layout в 2 рази швидше за використання Frame-ів з жорсткими константами — різниця у швидкості адаптації до 50%. Для Android використовуємо Jetpack Compose адаптація з Modifier.fillMaxWidth() та Modifier.weight(), але перевіряти потрібно все одно на реальних пристроях.

Оформлення адаптації в Figma

Кожен ключовий екран перевіряємо на крайніх розмірах. Не всі 50 екранів — лише ті, де є переповнення контентом, Bottom Sheet, складні форми, зображення з фіксованою висотою. Додатково готуємо макет для найширшого та найвужчого екрану, щоб розробник бачив межі.

Порівняння підходів: Auto Layout vs адаптивні макети

Використання адаптивних макетів з breakpoint-ами забезпечує кращу якість в 2–3 рази порівняно з використанням лише Auto Layout.

Обмеження Auto Layout

Auto Layout не масштабує зображення, не змінює кількість колонок у сітці. На iPhone SE картки товарів у 2 колонки перетворюються на 1 колонку — це потрібно закладати в дизайн. Ми використовуємо adaptive layout з breakpoint-ами: на ширині до 375pt — одна колонка, до 430pt — дві, вище — три. Це вимагає окремого опрацювання кожного екрану, але зате користувач не бачить «обрубків».

Чому використання тільки Auto Layout не вирішує проблему?

Auto Layout не враховує пропорції екрану та не адаптує контент під різні співвідношення сторін. Наприклад, на вузьких екранах контент може обрізатися, а на широких — залишати порожні поля. Тому потрібні окремі макети під різні пропорції.

Як врахувати Safe Area на різних пристроях?

Safe Area різна на різних пристроях. На iPhone з Dynamic Island вона становить 59pt зверху, на iPhone SE — 20pt, на Android — notch буває різним або відсутній. Важливо не розміщувати критичні елементи всередині Safe Area без необхідності.

Типові помилки адаптації та як їх уникнути

Найпоширеніші типові помилки адаптації: ігнорування пропорцій екрану, неправильний розрахунок Safe Area, нечитабельна типографіка, фіксовані відступи. Їх можна уникнути, використовуючи адаптивні макети, динамічну типографіку та перевірку на реальних пристроях.

Склад робіт (deliverables)

1. Аудит поточних макетів на предмет проблем адаптації (Safe Area, переповнення, типографіка).
2. Створення контрольних фреймів для 3–4 розмірів (iOS + Android).
3. Коригування відступів, вирівнювання, масштабів зображень.
4. Підготовка гайду для розробника з констрейнтами та примітками.
5. Перевірка на реальних пристроях (є парк з 15+ девайсів).
6. Підсумковий Figma-файл з налаштованим Auto Layout та змінними.
7. Консультація команди розробки з верстки.

Ми пропонуємо адаптацію під ключ усього проекту. Наприклад, адаптація 20 ключових екранів коштує від $800, а повний проект — до $2000. При замовленні всього проекту ви економите до 15% у порівнянні з поекранною оплатою. Послуги адаптації дизайну включають всі перелічені етапи.

Ми працюємо з дизайном на всіх етапах: від проектування до передачі в розробку. 5+ років досвіду, понад 20 реалізованих проектів для iOS та Android. Гарантуємо, що після нашої адаптації не буде відхилень за розділом 4.2 App Store Review та Google Play Console.

Процес роботи

• Аналітика: вивчаємо поточні макети та виявляємо проблемні місця.
• Проектування: створюємо контрольні фрейми та адаптивні варіанти.
• Реалізація: коригуємо елементи та готуємо гайд.
• Тест: перевіряємо на реальних пристроях та симуляторах.
• Деплой: передаємо готовий Figma-файл та гайд розробникам.

Орієнтовні терміни

Адаптація існуючого дизайну під 3–4 контрольні розміри (ключові екрани, не повний проект) — від 1 до 3 робочих днів. Повна адаптація всього проекту (до 50 екранів) — від 5 до 10 робочих днів. Вартість розраховується індивідуально, залежить від кількості екранів та складності. Оцінимо ваш проект безкоштовно — просто зв'яжіться з нами.

Отримайте консультацію з адаптації дизайну вашого мобільного додатку. Ми допоможемо уникнути типових помилок адаптації: неправильний розрахунок Safe Area, ігнорування пропорцій екрану, нечитабельна типографіка. Адаптивна верстка для iOS та Android вимагає різних підходів, але наша експертиза охоплює обидві платформи. Замовте адаптацію дизайну — ваш продукт ідеально виглядатиме на будь-якому екрані. Мобільний дизайн під усі екрани — наша спеціалізація.

Дизайн мобільних додатків: чому макет із Figma не гарантує готовий інтерфейс

Дизайнер надсилає макет — гарний, з градієнтами та кастомними компонентами. Розробник відкриває його і розуміє: кнопка 36pt, зона дотику 20pt. На iPhone SE вона фізично не натискається великим пальцем. Bottom sheet перекриває контент при появі клавіатури. Навігація побудована всупереч нативній моделі iOS. Apple відхилить додаток або користувачі підуть через тиждень — залежить від того, наскільки пощастить пройти рев'ю.

Ми проєктуємо мобільні UX/UI більше 5 років і бачили сотню таких ситуацій. За цей час спроектували та допомогли запустити 30+ мобільних додатків — від фінтех-продуктів до соціальних мереж. Вам не потрібно гадати, чи пройде дизайн App Review або Google Play — ми закладаємо платформенні вимоги з першого екрану. Оцінимо ваш проєкт за один день, зв'яжіться з нами.

Мобільний UX/UI — це не адаптація веб-дизайну. Це окрема дисципліна з конкретними обмеженнями платформи: safe area, тач-жести, UIViewController lifecycle, Activity state management.

Чому Human Interface Guidelines та Material Design 3 не можна ігнорувати?

Apple Human Interface Guidelines та Google Material Design 3 — не естетичні рекомендації. Це задокументовані очікування користувачів, сформовані роками використання системних додатків. Очікування, які підтверджуються дослідженнями користувацького досвіду на мобільних платформах.

HIG визначає: мінімальна зона дотику 44×44 pt, safe area insets для нотча та Dynamic Island, стандартні жести (swipe back на iOS, back gesture на Android 10+). Ігнорування safe area — поширена помилка. safeAreaLayoutGuide на UIKit та safeAreaPadding у SwiftUI існують саме для цього. Клієнти, які не проставили відступи від safe area у Figma, гарантовано отримують баг при верстці — виправлення одного такого багу коштує в середньому $200–400 зайвих годин розробника.

Material Design 3 приніс Dynamic Color — кольорова схема генерується з шпалер користувача через MaterialTheme.colorScheme у Jetpack Compose. Додаток, що ігнорує dynamic colors на Android 12+, виглядає чужорідно і втрачає до 12% залученості в перший тиждень.

Найболючіші невідповідності платформенним гайдам, які зустрічаємо на проєктах:

• Кастомна навігація поверх системної. Користувач iOS очікує swipe back з будь-якої точки лівого краю екрану. Кастомний NavigationController без інтерактивного жесту ламає це. Користувач Android очікує системну кнопку назад — кастомна back-кнопка в лівому куті не замінює її повністю.
• Модальні вікна замість navigation push. Bottom sheet доречний для дій, а не для навігації по контенту.
• Відсутність haptic feedback. UIImpactFeedbackGenerator на iOS — не прикраса, а частина відгуку інтерфейсу. Кнопки, свайпи, confirmation actions без тактильного відгуку відчуваються зламаними.

Таблиця: Порівняння вимог iOS та Android для UX/UI

Замовте аналіз вашого проєкту — ми оцінимо відповідність платформенним вимогам за 1 день.

Як вичавити максимум із Figma?

Figma Variables API змінив робочий процес. Design tokens — кольори, типографіка, радіуси, відступи — зберігаються як змінні та експортуються напряму в код через figma-tokens або style-dictionary. Це прибирає шар ручного перекладання значень і розсинхронізацію між дизайном та реалізацією. Практика показує: Figma Variables прискорює передачу макетів у розробку в 2–3 рази порівняно зі статичними фреймами, а використання design tokens знижує кількість помилок при перенесенні в код на 60%.

Як створити дизайн-систему з Figma Variables (покроково):

1. Налаштуйте колекції змінних для кольорів, типографіки, відступів.
2. Прив'яжіть компоненти до змінних замість статичних значень.
3. Експортуйте токени в JSON через Style Dictionary.
4. Передайте JSON-файл розробникам — вони імпортують його в код без ручного перекладання.

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-прототип на тестуванні коштує нульових годин розробки. Переробка готового екрану коштує днів. Тестування прототипу до початку розробки знижує кількість правок на 80%, а вартість виправлення багу на етапі прототипу в 10 разів менша, ніж після релізу. Клієнти, які тестували прототипи, економлять у середньому $5000–8000 на кожному циклі.

Для usability-тестування використовуємо Maze (тест задач на прототипі — користувач проходить сценарій, ми отримуємо heatmaps та mis-click rate) або прямі сесії через UserTesting. Ключові метрики — task completion rate та time on task, а не «подобається / не подобається».

A/B-тест у мобайлі складніший, ніж у вебі: App Store не дозволяє змінювати UI без оновлення додатку. Тому важливо тестувати гіпотези на прототипі до релізу, а не через production-експерименти. Середній час виконання задачі збільшується на 40% після грамотної UX-оптимізації на етапі прототипування.

Чому анімації критичні для сприйняття інтерфейсу?

Анімації в мобайлі — це зворотний зв'язок. Елемент з'являється не миттєво — він приходить у потрібний стан за 200–350 мс. Це дає мозку контекст для розуміння, що сталося.

• iOS: withAnimation у SwiftUI, UIViewPropertyAnimator у UIKit для інтерактивних анімацій з можливістю переривання. Spring animations з 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 — обов'язковий крок перед релізом анімованих екранів. Додатки з анімаціями, що виконуються на CPU, втрачають до 20% плавності на старих пристроях.

Accessibility: не опціональна функція

VoiceOver на iOS та TalkBack на Android використовують до 15% користувачів — ця статистика підтверджується дослідженнями доступності. В абсолютних числах для великого додатку це тисячі людей. Крім цього, App Store rejections через accessibility трапляються, хоча рідко.

SwiftUI автоматично генерує accessibility tree з семантики компонентів. UIKit вимагає ручного розставлення accessibilityTraits, accessibilityHint, групування через shouldGroupAccessibilityChildren. Дотримання цього чеклісту збільшує час утримання користувачів з обмеженими можливостями в середньому на 35%.

Що входить у роботу

У результат проектування UX/UI входять:

Процес та терміни

Проектування проходить етапи: дослідження та конкурентний аналіз → user flows та wireframes → дизайн-система → UI-макети → прототип → тестування → передача в розробку.

Орієнтири за термінами:

Вартість розраховується після аналізу вимог — кількість екранів, складність компонентів, чи потрібна дизайн-система або працюємо з існуючою. Отримайте комерційну пропозицію — залиште заявку на консультацію. Замовте дизайн мобільного додатку під ключ — оцінимо проєкт за 1 день та запропонуємо оптимальний обсяг робіт.