Якщо ви прийшли в мобайл із веб-дизайну, перший інстинкт зрозумілий: взяти все те, що є на десктопі, і стиснути до 390 пікселів. Хедер, бокову панель, три колонки контенту. Зменшити шрифт, прибрати зайве. Ось вам і мобілка.

Тільки так не виходить. Справа не в місці — це взагалі інший спосіб думати про інтерфейс.

Чому мобілка — не маленький сайт

Відкрийте Spotify у браузері. Ліворуч бібліотека, вгорі акаунт і пошук, посередині плейлисти. Три зони, три рівні навігації одночасно: глобальна (де ти взагалі на сайті), локальна (що є поряд) і контекстуальна (що відбувається прямо зараз). Все видно, все доступне.

Тепер відкрийте той самий Spotify на телефоні. Бокова панель зникла. Замість неї TabBar знизу й горизонтальний скрол для категорій. Один фокус за раз. Мобілка не намагається показати все відразу — вона вирішує, що вам потрібно зараз, і показує тільки це.

Revolut — ще чіткіший випадок. Вебверсія і мобільна — майже різні продукти. Одна компанія, один акаунт, але різна структура. Бо в застосунку люди переважно роблять одне й те саме: переказують гроші, перевіряють баланс, платять. Швидко, з телефона, у черзі чи в транспорті. У вебі — зовсім інший сценарій, більш складні операції, більше часу й уваги. Однаковий інтерфейс для обох не спрацює.

Мобілка не відображає сайт. Вона вирішує задачі, які мають сенс із телефона в руці.

Як влаштована навігація в iOS

Основа мобільної навігації — табар (TabBar). Нижня панель із 3–5 розділами. Вона замінює всі три рівні веб-навігації одним компонентом.

Табар знаходиться знизу, і це не завжди було так. У старих версіях Facebook навігація стирчала зверху. Потім дизайнери зрозуміли, що постійно тягнутися пальцем до верхнього краю екрану незручно, великий палець лежить нижче — і перенесли. Так воно і залишилось у всіх нормальних застосунках.

Ось важливе правило, яке новачки часто ламають: якщо є табар — кнопки «Назад» немає, і навпаки. Коли юзер провалюється в розділ глибше, табар зникає, з'являється «Назад» вгорі. Обидва елементи на одному екрані — значить щось пішло не так.

Instagram — виняток. Вони тримають табар видимим навіть усередині поста. Це свідоме продуктове рішення: хочуть, щоб люди якомога швидше перемикалися між розділами. Але це виняток, а не норма. Докладніше про те, як проєктувати user flow у мобільних і вебпродуктах — у нашому матеріалі про побудову шляху користувача.

Сегмент-контрол проти горизонтального списку

Їх часто плутають, бо зовні схожі. Але це різні компоненти з різною поведінкою.

Сегмент-контрол — перемикач, який повністю вміщається на екрані (максимум 5 варіантів). Натиснули «Аудіо» — весь контент під ним замінився. Натиснули «Електронні книги» — знову замінився. Він контролює вміст.

Горизонтальний список — це теж рядок кнопок, але він виходить за межі екрану і свайпається. Фільтри у Spotify — саме такий список, а не сегмент-контрол. Вони нічим не управляють, вони самі є вмістом, який прокручується. Різниця принципова, навіть якщо на скрині не відразу помітна.

Які жести використовує мобайл-юзер

У вебі є мишка. Можна клікати, можна навести курсор, і вже з ховера зрозуміло, чи елемент інтерактивний. На мобілці нічого цього немає.

Тап — базова взаємодія, аналог кліку. Свайп прийшов із реального світу: ми інтуїтивно розуміємо «відсунути убік», «гортати сторінку», і мобілка просто перенесла це. Горизонтальний свайп — перехід між екранами або видалення елемента, вертикальний — скрол. Довгий затиск відкриває контекстне меню або режим редагування.

Pull-to-refresh — ідея, яка зараз здається очевидною: потягнути сторінку вниз, щоб оновити. З'явилась десь в iOS 7. Тоді жестів було мало, а потрібних дій багато — і хтось придумав цей спосіб «видобути» ще одну команду з вертикального руху.

Був ще 3D Touch: тисни сильніше — отримуєш інший результат. Apple прибрала, бо юзери просто не знаходили цю можливість. Красива ідея, але якщо поведінка незрозуміла без підказки — вона не приживеться, неважливо наскільки технічно вона крута. Ця логіка — ключова для розуміння того, яких помилок у UI/UX варто уникати на старті.

Безпечні зони й конфлікти

Системні жести iOS мають пріоритет над жестами вашого застосунку. Завжди, без виключень. Свайп з лівого краю означає «повернення назад». Свайп зверху — центр керування. Якщо ваш застосунок хоче використати ці самі жести для чогось свого, він програє.

З позиціюванням елементів те саме. Клікабельні елементи не можна ставити в зону системних. Кнопка, яка потрапляє на зону home indicator, просто не спрацює, система перехопить дотик. Некліка­бельний контент, текст чи картинка, може бути де завгодно, хоч до краю. Але кнопки — подалі від системних зон.

Як працюють нативні компоненти

iOS вирішила більшість задач до того, як ви відкрили Figma.

Human Interface Guidelines (HIG) — документ для всієї команди: дизайнери читають, як виглядає інтерфейс, розробники на Swift беруть нативні компоненти з тієї ж системи. HIG охоплює всю екосистему: iOS, macOS, watchOS, tvOS. Суть не в тому, щоб обмежити — а в тому, що вже є готові відповіді на більшість стандартних задач. Немає сенсу вигадувати дропдаун заново. Якщо вам цікаво, як системно працювати з дизайном через інструменти Figma, — ми розібрали 23 плагіни, які прибирають рутину.

У кожного нативного компонента є вшита логіка. Кнопка — клік, дія. Дропдаун — відкриває список. Сегмент-контрол — перемикає контент. Цю логіку переробляти дорого і безглуздо. А от візуал (колір, шрифт, заокруглення) міняється вільно. Саме тому Revolut виглядає як Revolut, а не як стандартна iOS-апка, але при цьому поводиться передбачувано.

Коли нативний компонент, коли кастомний

Є спостереження, яке зазвичай приписують Нільсену: більшість часу юзер проводить в інших застосунках, не у вашому. Це означає, що поведінку він уже очікує певну — і якщо ваш застосунок поводиться інакше, він витрачає когнітивний ресурс на те, щоб просто зрозуміти, як він працює.

Нативні компоненти закривають це автоматично. Але деяких у iOS просто немає. Floating Action Button (FAB) — плаваюча кнопка над інтерфейсом — нативного аналога не має. Gmail зробив кастомний FAB і живе з ним. iOS-альтернатива: та ж дія у правому верхньому куті навбару. Не те саме функціонально, але рідне для системи. Це саме той тип рішень, про які говорять у повному гіді до UI/UX-професії: розуміти обмеження системи і проєктувати в їх межах.

Практичне питання: розміри компонентів із бібліотеки

Деякі компоненти в iOS Component Library ширші за ваш фрейм. Клавіатура, наприклад, 402px, а ви дизайните на 375px або 390px. Просто скейліть пропорційно: статус-бар і home indicator розтягнуться самостійно, клавіатура скейліться. Підганяти піксель за пікселем не треба.

Як відрізнити iOS від Android

Перепутати можна тільки з першого погляду.

Маркери iOS: системний time picker — барабанчик із цифрами, що прокручуються; ActionSheet — список дій, що виїжджає знизу; AlertDialog — модальне вікно посередині екрану з 1–3 кнопками; заокруглені кути; Liquid Glass у TabBar (iOS 26+).

Маркери Android: Floating Action Button — кругла кнопка, що ширяє над вмістом; time picker у вигляді циферблата; інша клавіатура; Material-стиль bottom sheet із ручками для свайпу.

Shopify є і на iOS, і на Android. Той самий продукт, та сама функціональність, але клавіатури різні, модальні вікна різні, TabBar відрізняється. Перший екран — і вже зрозуміло. Ще є HarmonyOS від Huawei, для ринків де немає Google. Для більшості нерелевантна, але варто знати, що існує.

Не всі застосунки виглядають нативно. Але всі хороші застосунки поводяться за правилами своєї системи. Якщо ви тільки починаєте розбиратися в тому, що таке UI/UX дизайн і як він влаштований, — ця база допоможе зрозуміти контекст.

Як практикувати

Відкрийте Mail, App Store або Maps — застосунки, які Apple зробила сама, без кастомізації. Знайдіть TabBar, кнопку «Назад», сегмент-контрол, AlertDialog, ActionSheet. Подивіться, як вони виглядають і що відбувається, коли з ними взаємодієте.

Потім знайдіть Slack або Spotify на iOS і Android — в скриншотах або на реальних пристроях. Виберіть 3 компоненти, які відрізняються. Запишіть, чому. Цей підхід добре узгоджується з тим, як збирати перші кейси в портфоліо UX/UI дизайнера: брати реальні застосунки, аналізувати рішення, документувати спостереження.

І ще одне: зберіть один екран виключно на нативних компонентах, без жодної кастомізації. Будь-яка тема — погода, нотатки, трекер звичок. Це нудне завдання, але саме воно швидше за все покаже, що вже вирішено системою до вас і де у вас взагалі є простір для рішень.

Нативні компоненти виглядають скромно. Але застосунок, зібраний з них, поводиться правильно — і саме це юзер відчуває, навіть не розуміючи чому. А якщо хочете побачити, як ці принципи застосовуються в реальній кар'єрі, — читайте, як стати Senior Product Designer і що для цього потрібно.