Проєктування навігації мобільного застосунку: де ламається структура
Навігація ламається не в момент проєктування, а коли в застосунок додають п’ятий-шостий розділ. Новий блок зручніше причепити до вже наявного екрана, і структура екранів застосунку росте вглиб: до потрібного розділу користувач іде через профіль, вкладений список і ще один рівень.
Глибина переходів переходить поріг у три кроки — і частина людей до мети просто не доходить. На тестах за одним сценарієм цього не видно: кожен шлях окремо виглядає логічним.
В аналітиці поломка проявляється як зростання частки покинутих сценаріїв на проміжних екранах: повернення назад, повторні відкриття того самого пункту, вихід після другого переходу. Одночасно зростає потік однотипних звернень до підтримки — «де знайти», «чому не відкривається».
Розбір кожного такого звернення забирає час команди, який не йде ні на нові функції, ні на прискорення поточних. Показник, за яким це відстежують, — частка доведених до кінця цільових сценаріїв від розпочатих, а не кількість встановлень.
Заплутана навігація майже завжди є наслідком відсутності карти екранів: зв’язки між рівнями тримають у голові, а під час додавання розділу перевіряють лише сам розділ, а не весь маршрут загалом.
Розбираємо, як це закривається — від інвентаризації наявних шляхів до правил, за якими новий екран стає в структуру, не збільшуючи глибину переходів.
Що дає продумана структура екранів і переходів
Перебудову навігації ми вимірюємо двома величинами: скільки кроків економить користувач і скільки часу економить команда на кожній наступній доопрацюванні.
Перед правками фіксуємо базові значення — шлях до частої дії, кількість повторів одного екрана в різних гілках, глибину вкладеності, — і після звіряємо з ними результат.
Скорочення шляху користувача тут головний орієнтир: повтор замовлення, кошик, пошук і налаштування профілю вкладаються у два-три переходи замість п’яти-шести.
Дублі шляхів прибираються — замість трьох копій одного екрана залишається один маршрут із параметрами, і правка поширюється на всі гілки. Зрозумілість інтерфейсу тримається на єдиній логіці повернення та передбачуваній поведінці кнопки «назад».
Швидкість випуску нових розділів
Коли маршрути описані декларативно, а екрани зібрані з багаторазових шаблонів, новий розділ перестає бути окремим проєктом: команда підключає готові блоки й витрачає час на бізнес-логіку, а не на верстку.
Це скорочує випуск розділу з тижнів до днів, а зміна торкається одного шаблону замість п’яти його копій.
Частка покинутих сценаріїв
Довгий шлях і незрозуміле повернення — основна причина, через яку користувач покидає сценарій на середині; скорочення кроків і явні точки виходу знімають частину обривів без нових функцій.
Після перебудови частка покинутих сценаріїв на ключових діях падає помітніше, ніж від косметичних правок: видно, на якому кроці люди зупинялися раніше й куди повернулися після.
Порівняння моделей навігації: вкладки, стек і бічне меню
Навігація — це контракт переходів: що доступно з будь-якого місця, як зберігається стан під час повернення і якою є глибина шляху до мети. Один шаблон рідко закриває і швидкі повторювані дії, і довгі лінійні процеси — звідси перевантажені меню та загублені кроки.
Спираємося на опубліковані посібники з проєктування мобільних інтерфейсів, зокрема Human Interface Guidelines.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Нижні вкладки | 3–5 рівнозначних розділів, доступних з будь-якого екрана | Шоста позиція втрачає читабельність, на планшетах — смуга порожнечі |
| Лінійний стек | Послідовні кроки: оформлення, реєстрація, анкета | Повернення в середину без збереження стану втрачає введене |
| Бічна панель | Рідкісні розділи: налаштування, довідка, архів | Прихований вхід погано виявляється, не годиться як основний |
| Змішана модель | Ядро з вкладок і лінійні сценарії всередині розділів | Потрібні явні правила скидання стеку, інакше стани розходяться |
Вкладки для частих сценаріїв
Нижні вкладки тримають 3–5 точок входу й зберігають розділ під час перемикання: користувач повертається туди, де зупинився, а кожна вкладка веде власний стек. Обмеження шаблону — плоска структура: усе, що не вміщається в п’ять позицій, іде у вкладеність і перестає знаходитися.
Стек для послідовних кроків
Лінійний сценарій — це стек екранів з одним зворотним шляхом і явною точкою виходу. Чернетку й позицію в процесі зберігаємо в стані, інакше повернення в середину втрачає введене, і користувач покидає оформлення.
Глибину стеку обмежуємо: довгий шлях без проміжних орієнтирів збиває й ускладнює відновлення після згортання застосунку.
Порядок робіт: від розбору сценаріїв до передачі команді
Навігація — це не картинка зі стрілками, а специфікація: які екрани є, чим вони пов’язані, що робить системна кнопка «назад» і як відновлюється стан після згортання застосунку.
Без такого артефакту кожен розробник трактує переходи по-своєму, а правки на етапі збірки коштують найдорожче.
Розбір сценаріїв і метрик
Починаємо не з макетів, а з даних: воронка в аналітиці, записи сесій, звернення до підтримки. З них збираємо частотні шляхи до мети й окремо — місця, де люди розвертаються та йдуть.
- Збираємо карту сценаріїв — один шлях на завдання користувача, з точками входу зі сповіщень і глибоких посилань.
- Фіксуємо метрики шляху: скільки екранів до мети, частка повернень назад, відмови на формах.
- Будуємо прототип переходів — граф екранів зі станами: порожній список, завантаження, помилка.
Узгодження карти екранів
Прототип перевіряємо на людях, а структуру описуємо лише після того, як глухі кути прибрано.
- Перевіряємо на користувачах: 5–7 осіб розв’язують типові завдання, рахуємо час до мети та кількість помилок.
- Описуємо структуру: таблиця екранів, вкладеність, правила системної кнопки «назад», відновлення стану.
- Узгоджуємо карту екранів з командою та замовником — що входить у найближчий реліз, а що відкладаємо.
- Передаємо в розробку: граф переходів як специфікація, тести на ключові сценарії, рев’ю навігації в кожному спринті.
Що передаємо на руки: карти екранів, схеми та регламенти
Передача документації — не фінальна презентація, а робочий комплект, за яким ваша команда розвиває навігацію без нас. Віддаємо все в редагованому вигляді: макети й схеми — у Figma, правила — текстом поруч із кодом, щоб опис структури й самі екрани змінювалися однією зміною.
- Карта екранів — перелік з ідентифікаторами, станами (основний, порожній, помилка) і точками входу в застосунок.
- Схема переходів — граф зв’язків між екранами: куди веде системна кнопка «назад», які переходи взаємозамінні.
- Правила іменування розділів — словник термінів і шаблон ідентифікаторів, щоб екран знаходився за назвою, а не за листуванням.
- Регламент змін — хто узгоджує правку структури, у який момент вона потрапляє в збірку і як відкочується невдале рішення.
- Журнал рішень — чому обрано саме цей перехід і які альтернативи відхилено.
- Чек-ліст перевірки навігації — сценарії входу та поведінка структури на різних розмірах екрана.
Регламент розвитку структури
Новий екран рідко з’являється у вакуумі: він або розширює наявну гілку, або ламає її. Правило просте — спочатку фіксуємо точку входу й глибину, потім малюємо екран; правка, що торкається більше двох переходів, оновлює схему окремою зміною з коротким описом.
Так структура залишається читабельною після десятків ітерацій, і новий розробник у команді замовника розуміє логіку переходів без усних пояснень.
Кейс: перебудували структуру сервісу й прибрали дублі шляхів
До нас прийшов сервіс доставки продуктів FreshMarket із застосунком, який кілька років обростав розділами: кожен новий сценарій додавав екран, а не використовував наявний повторно.
Навігація перестала бути передбачуваною — користувач потрапляв до одного результату різними шляхами, і команда не могла однозначно назвати основний.
Ми пройшлися по даних про переходи й зібрали карту фактичних маршрутів замість задуманих. До оформлення замовлення користувач робив сім кроків замість чотирьох можливих, а на ключовому екрані сходилися шість різних точок входу.
| Показник | До | Після |
|---|---|---|
| Кроки до ключової дії | 7 | 4 |
| Дублювальні розділи | 14 | 6 |
| Покинуті сценарії | 38% | 21% |
| Завершені дії за сесію | 1,2 | 1,9 |
Які ризики зняли
Шляхи звели до одного входу на сценарій, тому логіка перестала розходитися між дублями, а правка в одному місці більше не потребує синхронної правки в трьох. Глибину вкладеності обмежили трьома рівнями: новий розділ з’являється лише під уже наявний сценарій, а не поруч із ним.
Структуру описали декларативно, тому перебудова розділів перевіряється на карті маршрутів до релізу, а не після скарг. Ще через два релізи частка завершених дій не відкотилася — утрималася, коли додали другий спосіб оплати.
Що робити, якщо структура вже склалася і змінювати її дорого
Перш ніж щось змінювати, варто заміряти, де саме рветься шлях до цільової дії.
Провал в одній-двох гілках не потребує повної переробки: дивіться частку повернень з другого й третього рівня, середню кількість кроків до ключового екрана і те, як часто користувачі відкривають пошук замість розділів.
Ризики зміни структури лежать не в новому розкладі, а в маршрутах, які вже розійшлися світом: збережені посилання, сповіщення зі старими адресами, зовнішні переходи з пошуку.
Кожен такий маршрут на перехідний період залишається робочим як аліас на новий екран, інакше просідання за входами й сесіями перекриє весь виграш від перебудови.
Ведемо перехідний період групами: одна гілка, окремий шар сумісності, свої метрики до й після, вимкнення без випуску нової збірки.
Продовжуємо або відкочуємо за часткою тих, хто дійшов до мети, кількістю кроків, відмовами та стабільністю сесій — а не за відчуттям «стало сучасніше».
Технічні питання, які ставлять перед стартом
Перед стартом сумніви зазвичай ті самі: де закінчується проблема конкретного екрана й починається вада структури, чи потрібно переписувати застосунок повністю, як потім жити зі старими посиланнями. Нижче — відповіді на п’ять питань, які найчастіше визначають обсяг робіт.
Як зрозуміти, що справа в структурі, а не в окремому екрані?
Дивимося шляхи користувачів: частка повернень на попередній крок, глибина вкладеності, точки виходу й повторні заходи в той самий розділ. Якщо збої повторюються на різних екранах одного сценарію — це діагностика навігації, а не верстки. Локальний дефект живе на одному екрані, структурний — на всьому маршруті.
Чи можна обійтися без переписування застосунку?
У більшості випадків так. Змінюємо граф переходів, а не вміст екранів: додаємо проміжні вузли, частину сценаріїв переводимо на вкладки, логіку й дані не чіпаємо. Переписування виправдане лише тоді, коли структура зрослася з логікою екранів.
Як перевіряєте навігацію до випуску?
Збираємо клікабельний прототип маршрутів і проганяємо сценарії повністю, з поверненнями й перериваннями. Потім — перевірки переходів і відновлення стану екрана після згортання, далі закрите роздавання. Перевірка до випуску ловить глухі кути й зайві кроки до релізу.
Що буде зі старими переходами й посиланнями?
Не ламаємо. Прямі посилання з листів, сповіщень і QR ведемо через шар сумісності на нові маршрути, невикористовувані поступово виводимо з обігу. Користувач за посиланням річної давності потрапляє на потрібний екран.
Як підтримувати структуру далі й наскільки це трудомістко?
Ведемо карту маршрутів і правила додавання екранів: куди кріпиться новий розділ, які переходи він зобов’язаний підтримати, де дублювати наявні. Тоді обсяг доопрацювань передбачуваний, а підтримка структури стає регламентом, а не разовою правкою.
Обговоримо завдання й повернемося з оцінкою та планом робіт
Щоб повернутися з планом робіт, а не із загальними словами, нам достатньо стартового набору матеріалів. Чим конкретніший вхід, тим точніші строки етапів і тим менше правок на етапі проєктування навігації мобільного застосунку.
- Мета застосунку й ключова дія користувача: оформити замовлення, залишити заявку, повторити покупку.
- Ролі та сценарії: як різні групи потрапляють у застосунок, що роблять першим ділом, куди повертаються.
- Що є зараз: макети, прототип, дерево екранів у будь-якій формі — підійде навіть начерк від руки.
- Де губляться користувачі: звіти аналітики, звернення до підтримки, записи тестів із реальними людьми.
- Обмеження: платформи, чинна дизайн-система, обов’язкові інтеграції та зовнішні сервіси.
- Доступи: тестовий контур і облікові записи, якщо частину навігації вже реалізовано в коді.
- Зовнішні строки: запуск, кампанія просування, сезон — під них вибудовуємо графік етапів.
На розборі показуємо схему переходів верхнього рівня й називаємо строки кожного етапу — від інвентаризації екранів до перевірки прототипу на користувачах.
Склад команди озвучуємо відразу: хто відповідає за проєктування, хто за технічну реалізованість переходів, хто веде перевірку. Опишіть завдання у зручній формі — повернемося з оцінкою та планом робіт.
