User flow diagram: де ламається шлях користувача
User flow diagram потрібна не для того, щоб показати щасливий шлях від входу до оплати, а щоб зафіксувати точки відвалу: місця, де користувач закриває застосунок і не повертається.
На схемі вони видно тільки тоді, коли намальовані не лише успішні переходи, а й усі альтернативні гілки — зазвичай бракує саме їх.
Перше місце — неопрацьовані стани екрана. Екран, спроєктований під заповнений список, за порожньої відповіді сервера показує порожнечу без пояснень, за помилки мережі — нескінченний індикатор завантаження, за протермінованої сесії — форму, яка мовчки не надсилається.
Кожен стан потрібно намалювати явно: завантаження, порожньо, помилка, офлайн, немає прав. Інакше користувач вирішує, що застосунок зламався, і йде.
Друге — розрив навігації. Перехід за зовнішнім посиланням не відновлює потрібний стек екранів, кнопка «назад» повертає не туди, звідки прийшов користувач, а спливаюче вікно закриває собою точку повернення. На діаграмі це обрив стрілки на проміжному екрані, а в застосунку — глухий кут.
Третє — втрата контексту під час повернення. Фільтри каталогу, позиція прокрутки, введені, але не надіслані дані: якщо після повернення з детального екрана все це скидається, шлях доводиться проходити заново, і на другому колі частина користувачів уже не залишається.
Окрема група — повторні дії: подвійний тап по кнопці підтвердження, повторне надсилання за поганої мережі. Тут шлях ламається не інтерфейсом, а відсутністю захисту від дублів і зрозумілого повідомлення про те, що операція вже триває. Розбираємо, як такі точки відвалу знаходять і закривають до релізу, а не за скаргами у відгуках.
Що дає опрацьована схема екранів і переходів
Єдина схема екранів і переходів — це не картинка для звіту, а робочий контракт між продуктом, дизайном і розробкою. Поки сценарії використання живуть у листуванні та головах, кожен учасник тримає свою версію, а розбіжності спливають на збірці, коли правка коштує найдорожче.
Схема (user flow diagram) фіксує точки входу, розвилки й глухі кути до того, як написано код, і лежить в одному файлі в Figma — правки бачить уся команда одразу. Що це дає у вимірюваних величинах:
- Кількість кроків до мети скорочується на 1–3: зайві екрани підтвердження, дублювальні входи та проміжні стани прибираються ще на схемі.
- Частка завершених дій зростає: покинуті сесії на розвилках видно до релізу, а не після звітів про встановлення.
- Час на узгодження правок падає в рази: обговорюється одна версія сценарію, а не три суперечливі макети.
- Сценарії використання покриті повністю: для кожного стану екрана — завантаження, порожній список, помилка — описано перехід.
- Приймання йде за готовими маршрутами: той, хто перевіряє, проходить сценарій за схемою і одразу називає розбіжність із реалізацією.
- Новий інженер входить у проєкт швидше: схема відповідає на питання, які інакше задають у чаті по одному.
Підсумок — команда витрачає час на реалізацію, а не на з'ясування того, як має працювати продукт.
Порівняння підходів: діаграма, прототип, карта екранів
Три артефакти вирішують різні завдання і часто йдуть разом, а не замість одне одного. Діаграма сценаріїв відповідає на питання, які гілки поведінки існують; карта екранів — з чого складається застосунок; клікабельний прототип — як це відчувається в руках. Що потрібно саме зараз, залежить від того, яке неясне питання ви закриваєте.
Ціна помилки зростає на кожному кроці: розбіжність гілок у схемі переходів правиться за хвилини, а той самий пропуск, знайдений на збірці, тягне за собою переробку навігації, екранів і логіки станів. Тому логіку ми фіксуємо діаграмою, а спірні місця перевіряємо прототипом.
| Варіант | Коли підходить | Обмеження підходу |
|---|---|---|
| Схема сценаріїв (діаграма) | Кілька ролей, розгалуження, відновлення після збою, статуси замовлення й інтеграції | Не показує компонування екранів і ціну переходу; читається лише з розшифровкою |
| Карта екранів | Застосунок із десятків екранів, потрібна ревізія навігації та пошук дублів | Не описує умови переходів і логіку станів |
| Клікабельний прототип | Перевірка ключового шляху на людях: перший запуск, оплата, спірні жести | Дорожчий у підтримці, швидко застаріває, рідкісні гілки в ньому не перевірити |
На практиці це не вибір одного варіанта, а зв'язка: діаграма залишається джерелом правди щодо логіки й переживає десятки правок, карта екранів слугує реєстром для дизайну та приймання, прототип закриває два-три критичні шляхи.
Гайдлайни платформ — Material Design і Human Interface Guidelines — тримаємо як рамку, але рішення ухвалюємо за вашими сценаріями.
Як ми проєктуємо шлях користувача: етапи робіт
Проєктування шляху користувача йде до першого рядка коду: діаграма (user flow diagram) фіксує, де людина входить у застосунок, що бачить на кожному екрані та в який момент його закриває.
Без неї рішення ухвалюються на смак, а розрив між задумом і реалізацією спливає вже на прийманні, коли переробка коштує найдорожче.
- Розбір поточного шляху. Збираємо дані аналітики, записи сесій і звернення підтримки: знаходимо екрани, з яких ідуть, і кроки, де користувач повертається назад.
- Карта станів. Описуємо кожен екран, умови переходів і повернень, а також порожні, помилкові стани та поведінку без мережі.
- Схема шляху. Зводимо все в діаграму: точки входу, альтернативні гілки, глухі кути, розвилки після авторизації та оформлення замовлення.
- Перевірка переходів. Проганяємо реальні сценарії — перший запуск, повторний вхід, відновлення доступу, скасування дії — і правимо схему там, де логіка рветься.
- Узгодження схеми. Розбираємо діаграму з продуктом, дизайном, розробкою та підтримкою; зауваження знімаємо правками у схемі, а не суперечками на релізі.
- Передача документації. Віддаємо редаговану діаграму, таблицю переходів і перелік подій аналітики, прив'язаних до кроків шляху.
Діаграма залишається живою: нові сценарії спочатку потрапляють у схему і лише потім у код — шлях не розповзається, а свіжі екрани не перетворюються на глухі кути.
Що команда отримує на руки: схеми, правила, документація
На виході команда отримує фіксований набір артефактів, а не усні домовленості в листуванні. Кожен лежить у репозиторії проєкту й версіонується разом із кодом: видно, яка версія схеми була в роботі на момент релізу і що саме в ній змінилося.
- Схема навігації — єдина діаграма користувацьких шляхів (user flow) із переходами, альтернативними гілками, поверненнями та виходами в зовнішні застосунки. За нею одразу видно, чи залишився екран без вхідного переходу.
- Опис сценаріїв — покрокові послідовності дій із точками розгалуження, умовами переходу та очікуваною реакцією інтерфейсу в кожному вузлі.
- Правила станів екранів — для кожного екрана перелічено завантаження, порожній список, помилку мережі, відсутність прав, офлайн і втрату сесії. Це знімає більшу частину суперечок на прийманні.
- Матриця ролей і доступів — який набір екранів і дій бачить кожна роль, зокрема пограничні випадки на кшталт зміни ролі без перезапуску застосунку.
- Карта зовнішніх входів — глибокі посилання, пуші та віджети: на який екран приводить кожен із них за запущеного та за закритого застосунку.
- Регламент правок — хто ініціює зміну схеми, хто погоджує, як позначається версія і як окремо фіксується розбіжність уже написаного коду з оновленою схемою.
- Документація для розробки — специфікація екранів, обов'язкові й необов'язкові поля, формати обміну із сервером і перелік станів, за якими будуються автоматичні перевірки.
Кейс: скоротили відвал на реєстрації майже вдвічі
Сервіс доставки продуктів прийшов із завданням: встановлення зростають, а до першого замовлення доходить менше чверті користувачів.
Ми розібрали шлях за подіями аналітики та записами сесій: сценарій займав дев'ять екранів, і до того, як людина бачила каталог, її просили підтвердити телефон, ввести адресу вручну, вибрати спосіб оплати й дозволити сповіщення.
Кожен зайвий крок до цінності зрізав потік — на підтвердженні телефона відвалювалося близько третини тих, хто почав.
Де втрачали користувачів
Перероблений сценарій назвали «Перше замовлення»: реєстрація стала частиною оформлення, а не вхідним бар'єром. Зрушення за ділянками шляху — у таблиці.
| Ділянка шляху | Було | Стало |
|---|---|---|
| Старт → підтвердження телефона | 71% | 88% |
| Підтвердження → адреса доставки | 54% | 82% |
| Адреса → перше замовлення | 39% | 63% |
| Увесь шлях до замовлення | 22% | 41% |
Що змінили у шляху
Підтвердження телефона перенесли після вибору товарів, адресу підставляли з геолокації з ручною правкою, оплату — після збору кошика, а запит сповіщень винесли на екран очікування доставки.
Додали індикатор прогресу та збереження стану: якщо застосунок закрили або перервав дзвінок, користувач повертається на той самий крок, а не починає заново. Окремо закрили збій із втратою кошика при перезапуску — він давав помітну частку звернень у підтримку.
Підсумок першого циклу: відвал на реєстрації скоротився майже вдвічі, частка тих, хто доходить до першого замовлення, зросла з 22 до 41%, зросла й частка користувачів, що повертаються.
Таку саму карту шляху й набір метрик ми фіксуємо до старту робіт — щоб результат вимірювався, а не обговорювався.
Чим карта екранів відрізняється від прототипу та макета
Карта екранів (user flow diagram) фіксує лише логіку переміщення: які екрани є, що користувач на кожному робить і де маршрут розгалужується — авторизований він чи ні, чи є товар у кошику.
Зовнішній вигляд, кольори, відступи до неї не входять, і це усвідомлено: карту можна переписати повністю, не чіпаючи решту документації.
Прототип — клікабельний каркас, на якому сценарій перевіряють у русі: підтверджують порядок кроків, кількість дій до цільового екрана та точки, де користувач упирається в глухий кут.
Типографіка та бренд-графіка тут принципово не фіксуються, інакше суперечка про сенс сценарію підміняється суперечкою про кнопку.
Макет — візуальний шар: сітка, типографіка, стани елементів — звичайний, натиснутий, порожній, помилка, завантаження. Маршрут він не описує: за макетом не зрозуміти, чи повернеться користувач назад після невдалої оплати. Збирається він лише після того, як карта й прототип перестали змінюватися.
Межі артефактів виводяться з одного питання — що документ принципово не фіксує: карта мовчить про вигляд, прототип про стиль, макет про маршрут. Звідси й порядок створення: спочатку карта екранів, потім прототип, потім макет. Зворотний порядок змушує перемальовувати найдорожчий шар — візуальний — під кожну зміну сценарію.
Часті технічні сумніви перед початком робіт
Перед стартом майже завжди спливають ті самі сумніви: чи не доведеться перемальовувати схему для випущеного застосунку, скільки часу забере наша команда і чи вистачить деталізації, щоб передати роботу далі. Нижче — відповіді, які визначають обсяг робіт і межі відповідальності.
Схема шляхів — не разовий документ, а робоча карта переходів: змінюється логіка екрана — оновлюється гілка, і це фіксується в першоджерелі, а не в листуванні.
Застосунок уже випущено — малювати схему з нуля?
Ні. Актуальну user flow diagram відновлюємо з поведінки продукту: навігація екранами, звернення в підтримку, завершені сценарії. Видно, які гілки реально працюють, а які стали недосяжними після минулих доопрацювань.
Скільки часу потрібно від нашої команди?
Один предметний експерт і дві-три короткі зустрічі: підтвердити логіку станів, пріоритет гілок і правила повернення на крок назад. Далі ми спираємося на документацію та підтримку, не відволікаючи розробників.
Чи вистачить опрацювання, щоб розробка йшла без здогадок?
Кожен вузол отримує стани: порожній екран, завантаження, помилка, немає мережі або прав. Перевіряємо, що зі схеми однозначно виводиться, куди потрапляє користувач після відмови оплати і як повертається в основний маршрут.
Що отримає команда, яка підхопить проєкт після нас?
Першоджерело діаграми, таблицю переходів і опис станів. Нова команда відновлює контекст за дні замість тижнів інтерв'ю, а розбіжності зі схемою видно на етапі оцінки, а не в релізі.
Обговоримо завдання і повернемося з оцінкою та планом
Щоб оцінка термінів спиралася на факти, а не на припущення, починаємо з поточного стану сценаріїв: які екрани вже є, де користувач іде, які кроки дублюються між собою. Достатньо описати завдання у вільній формі — уточнювальні питання по суті поставимо ми. Чим повніші вхідні дані, тим менше припущень у діаграмі й тим реалістичніший план робіт.
Що варто надіслати разом з описом завдання:
- Перелік ключових сценаріїв у порядку пріоритету: вхід і реєстрація, оформлення замовлення, повторне звернення, відновлення доступу.
- Карту екранів і переходів: що вже реалізовано, що живе лише в макетах, де логіка розходиться між платформами.
- Точки виходу: на якому кроці користувачі кидають сценарій і за якими подіями це видно в аналітиці.
- Ролі та стани: гість, авторизований, підписник, заблокований, офлайн-режим.
- Зовнішні залежності: авторизація, платежі, сповіщення, інтеграції із внутрішніми системами.
- Розмітку цільових дій: що вважаємо результатом кроку і які події потрібно фіксувати.
- Референси й обмеження: приклади, які підходять або категорично не підходять, вимоги до поведінки на слабких пристроях.
За цими даними ми збираємо діаграму користувацьких сценаріїв, погоджуємо її з вами і лише після цього фіксуємо межі робіт. Далі ви отримуєте оцінку термінів за етапами, порядок дій і список рішень, які потрібно ухвалити до старту проєкту. Опишіть завдання — повернемося з оцінкою та планом.
