Карта екранів мобільного застосунку: де розходиться логіка
Карта екранів мобільного застосунку — це не перелік сторінок, а контракт між продуктом, дизайном і розробкою: які екрани є, чим вони відкриваються, які стани підтримують і куди користувач повертається після кожного кроку.
Поки схема переходів живе в макеті й описує лише успішний шлях, здається, що структура навігації застосунку узгоджена. Розходження логіки екранів проявляється пізніше і не там, де його чекають.
Перше типове місце — вкладені та модальні гілки: підтвердження оплати, вибір адреси, введення коду з листа. На макеті це окремі шари, а в карті екранів у них немає точки повернення, і після скасування користувач потрапляє не туди, звідки почав.
Друге — зовнішні входи: перехід за посиланням з листа або сповіщення, відкриття застосунку після розриву з’єднання. Схема переходів, побудована від головного екрана, такі сценарії просто не описує.
Третє — вузькі місця навігації всередині самих екранів. Екран-перехрестя починає знати про п’ять сценаріїв одразу й сам вирішує, куди йти далі; після цього правка в одному потоці ламає сусідній, а тестувальник описує дефект як «навігація поводиться дивно».
Ціна розходження вимірюється не красою схеми, а кількістю правок: один перехід доводиться виправляти в трьох місцях, а частина помилок спливає вже після викладки. Розбираємо, як це закривається.
Що дає описана структура переходів до старту розробки
Узгоджена структура переходів показує до першого рядка коду, скільки екранів реально потрібно продукту. Зайві кроки — дублювальні форми, проміжні підтвердження, екрани «на всяк випадок» — відсікаються на схемі, де правка коштує хвилини, а не переробки готового коду.
За нашою практикою список екранів після такої ревізії скорочується на 15–25%, і кожен прибраний екран перестає тягнути за собою стан, обробку помилок і окремий набір перевірок.
Єдина логіка для платформ описується один раз: каркас переходів задається як маршрути з точками входу та виходу, а відмінності зводяться до навігаційних патернів із керівництв платформ, наприклад Material Design.
Команди обох платформ реалізують один сценарій, а не дві поступово розбіжні версії продукту: зміна в структурі застосовується одразу всюди.
Коли маршрут і стани екрана — порожній список, завантаження, помилка мережі, відсутність прав — описані заздалегідь, оцінка перестає залежати від знахідок по ходу роботи. Розробник отримує контракт екрана: що надходить на вхід, що йде далі, які гілки потрібно покрити.
Швидкість розробки зростає, а правки після першого випуску скорочуються приблизно на третину: неузгоджені переходи виявляються до збірки.
Підсумок — передбачуваний графік випуску: кількість екранів і зв’язків відома, оцінка складається зі зрозумілих одиниць, а ризик змінювати навігацію в середині роботи майже зникає. Структуру дешевше переписати на схемі, ніж у зібраному застосунку.
Формати опису структури: таблиця станів, схема, прототип
Формат опису структури визначає, що саме побачить команда: список екранів, зв’язки між ними або сам сценарій у роботі.
Один продукт можна описати таблицею станів екранів, схемою переходів або інтерактивним прототипом — різниця в тому, які помилки кожен формат ловить, а які пропускає.
Обмеження форматів пов’язані не з якістю, а з моментом застосування. Таблиця не показує ритм інтерфейсу, схема не передає поведінку при відмовах, прототип не описує рідкісні гілки й розходиться з реалізацією, якщо оновлюють лише його.
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Таблиця станів екранів | Фіксація логіки: ролі, права, стани завантаження й помилок, умови переходів | Не читається цілком на погодженні; потребує оновлення після кожної правки |
| Схема переходів | Перевірка цілісності: немає глухих кутів, у кожного екрана є вихід і зворотний шлях | Не передає вміст екранів і правила доступу |
| Інтерактивний прототип | Перевірка сценарію з користувачами: зрозумілість кроків, обсяг форми, порядок дій | Не покриває аварійні гілки; швидко розходиться з реалізацією |
| Текстовий опис екранів | Передавання задачі в розробку й підтримку: єдиний словник назв і зон | Застаріває без прив’язки до таблиці та схеми, допускає різні трактування |
На практиці формати не замінюють одне одного: таблиця станів залишається джерелом істини, схема переходів — для перевірки цілісності на погодженні, прототип — для перевірки сценарію. Розходження між ними — перша ознака, що структуру час перезбирати.
Етапи проєктування структури та переходів застосунку
Роботу починаємо з інвентаризації: збираємо всі екрани, модальні вікна, стани завантаження й помилок, які є в застосунку або закладені в макетах. Кожному вузлу присвоюємо ідентифікатор і тип — так схема залишається читабельною, коли екранів стає понад сотня.
Далі описуємо переходи й умови: що відкриває екран, за яких подій він закривається, куди веде системна кнопка «назад» на кожній платформі.
- Аудит наявних екранів. Звіряємо макети, працюючий застосунок і аналітику: знаходимо екрани-дублі, глухі кути без виходу, місця, де користувач втрачає контекст. Фіксуємо розходження між платформами — часто той самий сценарій на різних системах влаштований по-різному без причини.
- Складання чернеткової структури. Розкладаємо екрани за гілками: вхід і реєстрація, основний сценарій, налаштування, платежі, підтримка, службові стани. Перевіряємо, що кожна дія має передбачуваний шлях повернення.
- Погодження схеми з продуктом. Проходимо карту разом із власником продукту та дизайном: де скоротити кроки, які гілки прибрати в наступний реліз, що критично на старті. Спірні місця вирішуємо на схемі, а не в коді.
- Перевірка переходів. Симулюємо сценарії: переривання оплати, втрата зв’язку, повторний вхід, глибокі посилання, повернення з фонового режиму. Кожен такий шлях має приводити до зрозумілого стану, а не до порожнього екрана.
- Передавання структури в розробку. Віддаємо карту з описом екранів, параметрами навігації та пріоритетами — за нею команда оцінює обсяг етапів і не трактує вимоги по-своєму.
- Підтримання актуальності. Домовляємося, хто і коли оновлює схему, щоб вона не розійшлася з продуктом після перших же правок.
Карта екранів живе разом із продуктом: коли додаємо функцію, ми оновлюємо її до початку розробки. Опишіть задачу — повернемося з оцінкою та планом робіт.
Що передаємо команді: артефакти, схеми та регламенти
Карта екранів — робочий документ, а не ілюстрація для презентації. Після завершення робіт вона залишається в замовника у вигляді набору артефактів, за якими нова команда продовжує розробку, не відновлюючи логіку за кодом. Нижче — те, що входить у передавання.
- Схема переходів: усі екрани, гілки навігації, повернення й глухі стани, з позначкою, які переходи блокуються до виконання умови.
- Схеми станів екранів: для кожного екрана — завантаження, порожній список, помилка, часткові дані, відсутність мережі; що саме бачить користувач у кожному випадку.
- Опис переходів і параметрів: які дані передаються між екранами, що обов’язкове, що відбувається за їх відсутності або застарівання.
- Правила іменування екранів: єдиний шаблон, за яким екран, подія й параметр називаються однаково в схемі, аналітиці та коді — розходжень під час звірки не виникає.
- Документація структури застосунку: ієрархія розділів, спільні блоки, повторно використовувані стани та їхні власники.
- Регламент оновлення схеми: хто і на якому етапі править карту, як зміна потрапляє до неї до початку розробки, а не після релізу.
- Матриця зв’язків «екран — вимога — перевірка»: видно, які шляхи покриті автотестами, а які залишаються ручними.
Усе передаємо у вигляді, який версіонується поряд із кодом: правки видно в історії, а не губляться в листуванні.
Кейс: як структура переходів скоротила переробки в застосунку
До: навігація збиралася по ходу розробки
Застосунок на 40 з гаком екранів проєктували від макетів: кожен екран малювали окремо, а переходи між ними додумували вже в коді.
До третьої ітерації спливли три різні варіанти повернення з кошика, два дублювальні потоки реєстрації та модальне вікно, з якого не було виходу на оформлення замовлення.
На момент першої збірки команда накопичила понад 60 правок навігації — частина з них ламала вже протестовані сценарії.
Що змінили: карта екранів до першого рядка коду
Зібрали карту екранів: для кожного екрана — входи, виходи, стани (порожньо / завантаження / помилка / немає прав), модальні гілки та правила повернення.
Окремо описали наскрізні потоки — оформлення замовлення, відновлення доступу, оплата — з точками, де користувач може піти й повернутися. Прототип переходів зібрали у Figma, щоб стан повернення перевірявся кліком, а не читанням опису, і погодили карту до старту розробки.
Після: метрики
Правок навігації після старту розробки — 8 замість 60. Переробили 3 екрани замість 20: переходи були погоджені заздалегідь, і розробникам не довелося перезбирати сценарії на ходу.
Частка переходів з явно описаним станом повернення зросла з 45% до 100%, тому тестувальники перевіряли сценарії за картою, а не здогадувалися про них.
Узгодженість екранів трималася на одному документі: дизайнер, розробник і тестувальник дивилися на одне джерело істини замість трьох трактувань. Терміни випуску застосунку не зсунулися — п’ятитижневого перенесення, яке прогнозували після першої збірки, не знадобилося.
Чим відрізняється структура переходів від інтерактивного прототипу
Карта екранів — це схема з вузлів і переходів: який екран, звідки на нього потрапляють, куди йдуть і за якої умови. Вона задає обсяг продукту: скільки екранів і станів, що показуємо за порожнього списку або обриву зв’язку. Інтерактивний прототип відповідає на інше питання — як сценарій відчувається в роботі.
Різниця в повноті. Прототип збирають за одним, «щасливим» шляхом: вхід, головна дія, результат. Карта покриває гілки — немає прав, офлайн, помилка запиту, порожній стан, підтвердження видалення.
Тому прототип без карти втрачає помітну частку станів, і їх знаходять уже на зібраному застосунку, де правка дорожча.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Текстова карта екранів | Фіксація обсягу, оцінка термінів, постановка задач розробці | Не передає візуальний ритм та ієрархію |
| Інтерактивний прототип | Перевірка спірного сценарію, показ замовнику | Покриває один-два шляхи, решта — білі плями |
| Карта плюс прототип ключових сценаріїв | Звичайна розробка продукту | Потрібні два проходи та синхронізація між ними |
Первинна карта. З неї виводять навігацію, сценарії перевірок та оцінку трудозатрат, а прототип — похідна від погодженої структури. Якщо починати з картинок, структура виростає з макетів і розповзається: два схожі екрани живуть за різними правилами.
Прототип іде першим в одному випадку: коли спір іде про саму механіку, а не про деталі, і гіпотезу треба перевірити на людях. Тоді збираємо два-три сценарії, а карту відновлюємо після. У Figma карта і прототип живуть в одному файлі, але це різні артефакти з різною цінністю.
Сумніви щодо структури: дублі екранів, стани, переходи
Дублі екранів майже ніколи не з’являються через неуважність — їх породжують різні сценарії входу. Той самий список відкривається з пошуку, з обраного та зі сповіщення, і в карті це різні маршрути з різним станом фільтра.
Вирішити заздалегідь, що перевикористовується як компонент, а що живе окремим екраном зі своїм контекстом, дешевше, ніж потім правити розбіжних близнюків окремо.
Друга точка напруження — стани екранів: порожній список, завантаження, помилка мережі, частково застарілі дані. У схемі вони описуються як гілки одного екрана, а зворотні переходи ведуть туди, звідки користувач прийшов, — інакше на етапі випуску навігацію доводиться переробляти. Нижче — сумніви, які найчастіше спливають до старту роботи над структурою.
У нас уже є застосунок. Карту доведеться збирати з нуля?
Ні. Знімаємо поточну структуру за фактом: проходимо екрани, фіксуємо переходи й стани, позначаємо дублі. Далі правимо точково — зазвичай це злиття повторюваних екранів і єдиний контракт параметрів навігації.
Хто відповідає за зворотні переходи та системні жести?
Навігація фіксується в карті як правило, а не як побажання: для кожного екрана зазначено, куди веде повернення і що відбувається зі збереженим станом. Так само описуємо поведінку при перериванні сценарію — дзвінок, згортання, розрив з’єднання.
Що буде зі структурою після релізу?
Карта залишається робочим документом: новий екран або гілка стану спочатку з’являються в ній, потім у коді. Це утримує навігацію від розростання і дає змогу побачити дубль до того, як він потрапив у збірку.
Обговоримо задачу і повернемося з оцінкою та планом
Щоб повернутися з оцінкою та планом робіт, потрібні ввідні: список екранів у будь-якому вигляді — таблиця, скриншоти, начерки, — опис ролей користувачів і доступ до поточного прототипу або репозиторію. Цього достатньо, щоб розібрати поточний стан і не переписувати заново те, що вже працює.
На виході ви отримуєте:
- розбір поточного стану: які екрани дублюють одне одного і де переходи втрачають контекст користувача
- карту екранів із ролями та станами — порожній, завантаження, помилка, відсутність мережі
- схему навігації з точками повернення та виходами з глухих гілок
- перелік екранів під об’єднання і тих, які справді потрібно додати
- оцінку та план робіт за етапами: порядок, залежності між екранами, точки перевірки
- правила підтримки структури застосунку — як новий екран вбудовується, не ламаючи навігацію
- склад команди та формат звітності по ходу робіт
Оцінка будується на вашому обсязі екранів і сценаріїв, а не на середніх показниках: зовні схожі застосунки розходяться за кількістю станів у рази. Якщо частина ввідних відсутня, розберемо продукт разом із вашою командою і зберемо карту екранів за вашими сценаріями.
Опишіть задачу — повернемося з розбором, оцінкою та планом робіт.
