Де розривається шлях до замовлення: аудит UX/UI мобільного застосунку
Аудит UX/UI мобільного застосунку ми починаємо не з перемалювання екранів, а з розбору воронки: відновлюємо шлях користувача від першого запуску до підтвердженого замовлення і дивимося, де частка тих, хто дійшов, падає найпомітніше.
Основа — події в аналітиці, записи сесій і розмітка ключових кроків: кошик, спосіб доставки, оплата, повторний вхід.
Так знаходяться точки розриву шляху користувача. Частина видна в цифрах — наприклад, обрив на екрані введення адреси, частина лише в записах: людина десять секунд шукає кнопку, згортає застосунок «подумати» і не повертається.
Відтік на кроці оплати майже завжди складається з дрібниць: обов'язкова реєстрація перед підтвердженням, поля зі строгою перевіркою без пояснень, скидання кошика при згортанні, недоступний для великого пальця основний сценарій на великих екранах.
Низька конверсія в замовлення — це зазвичай не проблема трафіку, а ціна зайвих кроків. Кожен екран між «хочу» і «оплатив» відсікає частину аудиторії, і на довгому сценарії втрати складаються, а не усереднюються.
При цьому платне залучення приводить людей рівно в той самий обрив: охоплення зростає, а кількість замовлень ні.
Розбираємо, як це закривається: де достатньо переставити кроки й прибрати зайві поля, а де потрібен інший сценарій оплати цілком.
Що змінюється після розбору: конверсія, утримання, відмови
Розбір інтерфейсу перетворює «незручно» на вимірювані величини: частку сесій, що доходять до ключової дії, частку повернень на другий-сьомий день і час від гіпотези до релізу. Орієнтир — не загальна оцінка «стало краще», а конкретний крок сценарію, де втрачається найбільше людей.
Клас відмов інтерфейсу визначає, яка правка взагалі допоможе.
Втрата на стартовому екрані лікується перебудовою першого сценарію; обрив у середині — найчастіше втратою стану, коли користувач повернувся в застосунок, а форма обнулилася; зависання і порожні екрани при поганій мережі — кешем і коректними офлайн-станами. Змішувати це в один список завдань не можна: у класів різні причини й різна ціна виправлення.
Утримання користувачів зростає від точкових правок, а не від повного редизайну: зберігаємо прогрес між сесіями, показуємо осмислені порожні стани замість порожнього списку, переносимо обов'язкові поля на момент, коли вони справді потрібні.
Строки випуску правок інтерфейсу залежать від того, наскільки розбір придатний до роботи.
Пріоритезований список із зазначенням екрана, стану й очікуваного ефекту дозволяє брати пункти в розробку без повторного аналізу — правки виходять невеликими регулярними релізами, а не щокварталу.
Результат звіряємо на даних: події воронки збираємо в Firebase, розбиваємо за когортами й порівнюємо поведінку до і після зміни. Так зростання конверсії застосунку видно по кожній правці окремо.
Формати робіт: повний розбір, експрес-перевірка, точкова перевірка
Три режими відрізняються не товщиною звіту, а тим, скільки користувацьких шляхів потрапляє в аналіз.
Повний розбір інтерфейсу покриває всі ключові сценарії, стани екранів і гілки обробки помилок; експрес-перевірка сценарію бере один шлях до цільової дії; точкова перевірка екрана — одну зону, де ймовірно губляться люди. Вибір формату робіт визначається не бюджетом, а тим, чи є у вас гіпотеза про місце втрати.
Якщо гіпотеза сформульована — наприклад, відтік на кроці оплати або на екрані введення даних — достатньо точкової перевірки: розбираємо конкретний екран, його стани завантаження, порожні дані, реакцію на неправильне введення.
Коли показники просідають у кількох місцях одночасно, експрес-перевірка швидше покаже, який шлях дає основну втрату, а який робить до неї менший внесок. Повний розбір потрібен перед переробкою застосунку, зміною платформи або виходом на нову аудиторію.
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Повний розбір інтерфейсу | Перед редизайном, зміною платформи, виходом на новий ринок; коли причини просідання невідомі | Займає більше часу, потребує доступу до аналітики й опитувань користувачів |
| Експрес-перевірка сценарію | Метрики падають на кількох шляхах, потрібно швидко зрозуміти, де зосереджена втрата | Розбирається один шлях, інші екрани залишаються поза аналізом |
| Точкова перевірка екрана | Є гіпотеза про конкретний екран або крок; потрібна швидка правка перед релізом | Не виявить проблеми в пов'язаних екранах і в логіці переходів між ними |
Формат можна змінювати по ходу роботи: якщо експрес-перевірка виявляє системну причину, розгортаємо її в повний розбір без повторного збору даних. Опишіть задачу — підкажемо, який режим дасть відповідь найшвидше.
Як проходить розбір: від збору даних до перевірки правок
Розбір іде не за смаковими відчуттями, а за відтворюваною послідовністю: спочатку дані, потім схема, тільки потім правки. Такий порядок знімає суперечку «подобається — не подобається»: у кожної рекомендації є метрика, до якої вона прив'язана, і спосіб перевірити її до релізу.
- Збір даних продуктової аналітики. Вивантажуємо події, воронки, глибину сесій і розподіл екранів входу-виходу за порівнянний період. Мета — побачити, на якому кроці відтік максимальний, а не де він найпомітніше виглядає.
- Схема користувацьких сценаріїв. Збираємо карту екранів і переходів, накладаємо її на воронку й розмічаємо точки розриву: де користувач згортає застосунок, повертається назад або повторює одну дію.
- Інтерфейсна перевірка. Теплові карти й записи сесій показують, куди реально тягнеться палець і які елементи залишаються в сліпій зоні великих екранів.
- Перевірка гіпотез на прототипі. Спірні місця збираємо в клікабельний прототип і проганяємо на фокус-групі або розділеним тестом на частині трафіку — до того, як правка потрапить у код.
- Пріоритезація. Залишаємо тільки те, що впливає на конверсію кроку; решта йде в окремий список з обґрунтуванням, чому не беремо зараз.
- Передача правок команді. Кожна точка оформлюється як задача: екран, сценарій, очікувана метрика, критерії приймання. Дизайнер і розробник не додумують, що малося на увазі.
- Контроль після релізу. Порівнюємо метрику вибраного кроку до і після випуску, щоб підтвердити ефект або відкотити рішення.
На виході у замовника залишається карта сценаріїв із позначеними точками розриву, пріоритезований список правок і набір метрик для перевірки — документ, за яким робота продовжується без нашої участі.
Карта екранів, прототипи і регламент правок
Аудит закінчується не звітом, а набором артефактів, з якими команда замовника продовжує працювати самостійно. Збираємо їх так, щоб новий дизайнер або розробник входив у проєкт за документами, а не за листуванням у месенджері.
- Карта екранів застосунку — усі стани кожного екрана: завантаження, порожній список, помилка, офлайн, частково заповнені дані. За нею видно, де сценарій обривається, а не тільки де він починається.
- Прототипи ключових сценаріїв — шлях від входу до цільової дії з позначками втрат: кількість кроків, обов'язкові поля, моменти запиту дозволів і авторизації.
- Регламент правок інтерфейсу — що вважається критичною зміною, хто погоджує, у який строк, як правка проходить від заявки до релізу і як відкочується.
- Документація з інтерфейсу — правила сітки, відступів, типографіки й поведінки компонентів, щоб нові екрани не розходилися з уже випущеними.
- Бібліотека компонентів зі станами — кнопки, поля, списки, повідомлення у звичайному, натиснутому й недоступному вигляді: розробник бере готове замість саморобних елементів.
- Журнал замірів — які метрики і на яких екранах знімалися до правок, щоб повторити замір тим самим способом і порівняти результат.
- Список гіпотез з пріоритетом — що перевіряти першим, яким способом і як трактувати підсумок, якщо приріст не підтвердився.
Кожен пункт прив'язаний до екрана й метрики, тому за документацією відновлюється логіка будь-якого рішення. Карту й прототипи оновлюємо разом із релізом — без цього вони розходяться з продуктом за дві ітерації.
Кейс: шлях до замовлення скоротився, відмову на оплаті прибрано
Клієнт — сервіс доставки їжі із застосунком на двох платформах.
Аудит показав, що воронка втрачає замовлення не на вході, а на виході: до оформлення людина проходила дев'ять екранів, чотири з яких були службовими — підтвердження адреси, вибір інтервалу, повторне введення телефону, «перевірте дані».
На екрані оплати втрачалися 38% кошиків: платіжний крок відкривався як окремий сценарій і втрачав кошик при згортанні застосунку.
Що було до
Дев'ять екранів, 4 хвилини 30 секунд від «додати в кошик» до підтвердження, 38% відмов на оплаті, частка повторних замовлень — 21%. Більше половини звернень до підтримки — «оплата не пройшла» і «злетів кошик».
Що змінили
Прототип зібрали в Figma і прогнали на сесіях із реальними користувачами, зафіксувавши три точки розриву: ручне введення адреси, розрив контексту на оплаті та відсутність збереження стану замовлення.
Шлях звузили до чотирьох екранів: адреса підставляється за геолокацією з ручною правкою, інтервал доставки вибирається там само, кошик і оплата живуть в одному шарі, чернетка замовлення зберігається локально і переживає згортання застосунку.
Що стало
Оформлення займає 1 хвилину 40 секунд, відмови на оплаті — 11%, частка повторних замовлень — 34%, звернення про оплату скоротилися майже вчетверо. Метрики знімали на рівних відрізках до і після, без сезонних сплесків і святкових піків, — зсув тримається на обох платформах.
Чим відрізняється розбір за аналітикою від інтерв'ю з користувачами
Методи відповідають на різні питання, і підміняти один одним не можна. Розбір за продуктовою аналітикою показує, де ламається шлях і якою є ціна розриву: частка завершених сценаріїв, відтік на кроці, розподіл часу за екранами. Глибинні інтерв'ю з користувачами пояснюють, чому людина чинить саме так і чого чекала від екрана.
| Метод | Які питання закриває | Обмеження |
|---|---|---|
| Розбір за продуктовою аналітикою | Де ламається сценарій, скільки користувачів зачеплено, що змінилося після релізу | Бачить дію, але не мотив — причину не пояснює |
| Глибинні інтерв'ю з користувачами | Чому йдуть, як формулюють задачу, що вважають незрозумілим | Десяток бесід не дає масштабу, відповіді згладжує бажання виглядати розумно |
| Спільний розбір | Перевірка гіпотез з даних на живих людях | Довше за строками, потрібні обидві компетенції в команді |
Порівняння методів дослідження впирається в їхні обмеження: аналітика безсила там, де сценарій формально проходить, але сенс кроку не зчитується, а інтерв'ю помиляються в частоті — людина пам'ятає яскраве, а не типове.
Вибір методу дослідження диктує питання, а не зручність: Nielsen Norman Group розрізняє якісні та кількісні дані за типом завдань, які вони здатні закрити.
На практиці ідемо послідовно: дані знаходять крок із найбільшою втратою і показують масштаб, інтерв'ю пояснюють причину, після чого правки перевіряються тими самими метриками.
Часті технічні сумніви: доступи, дані, повторні перевірки
Аудит не потребує адмін-прав у продакшені й доступу до вихідного коду. Достатньо ролі «лише читання» в акаунті продуктової аналітики й вивантажень за ключовими сценаріями — вхід, пошук, оформлення замовлення.
Якщо розмітка подій неповна або доступ дати не можна, розбираємо сценарії на записах сесій і тестових прогонах актуальної збірки. Нижче — сумніви, які найчастіше виникають до старту, і те, як ми їх закриваємо.
Які доступи потрібні до аналітики?
Роль із правами перегляду й вивантаження, без зміни налаштувань. Потрібні події за 2–4 тижні й скриншоти дашбордів; якщо політика безпеки не дозволяє дати доступ — приймаємо вивантаження файлами за узгодженим переліком подій.
Який обсяг даних достатній для розбору?
Вибірка за наскрізними сценаріями, а не вся історія продукту. Зазвичай достатньо кількох тисяч сесій на критичних шляхах; якщо трафіку мало, добираємо тестовими проходами й записами сесій на еталонних пристроях.
Що робити, якщо розробка паралельно править застосунок?
Фіксуємо базову версію збірки, на якій іде розбір, і не змішуємо висновки з новими змінами. Після релізу повторна перевірка сценарію на оновленій збірці показує, чи пішла точка розриву, — порівнюємо поведінку до і після.
Де частіше знаходяться точки розриву — в інтерфейсі чи сервісах?
За нашою практикою розривається зазвичай не екран, а зв'язка інтерфейс — сервіси: порожні стани при збої мережі, таймаути, повторні відправлення, втрата прогресу при перезапуску. Тому сценарій дивимося цілком, від входу до підтвердження результату.
Обговоримо задачу: що надіслати для стартової оцінки
Щоб стартова оцінка була предметною, а не «подивимося й скажемо», нам достатньо мінімального набору вхідних даних. Чим повніша картина за сценаріями й метриками, тим точніше ми називаємо обсяг робіт, склад команди й порядок взаємодії — і тим менше уточнювальних кіл до старту.
- Посилання на тестову збірку: внутрішнє розповсюдження, закрита бета або демо-стенд із робочими доступами — проходимо сценарії на реальних пристроях, а не за макетами.
- Перелік цільових сценаріїв: що користувач має зробити в застосунку, які екрани вважаєте ключовими і де, за вашими спостереженнями, губляться люди.
- Вивантаження аналітики за 2-3 місяці: події, воронки за реєстрацією й оплатою, утримання, розподіл за платформами й версіями операційної системи.
- Зворотний зв'язок користувачів: звернення до підтримки, відгуки в магазинах застосунків, записи сесій, результати опитувань та інтерв'ю, якщо вони є.
- Поточні матеріали дизайну: посилання на макети з правами на перегляд, опис дизайн-системи й бібліотеки компонентів.
- Контекст продукту: мета змін, метрики, за якими будете оцінювати результат, обмеження за строками релізу й підтримуваними платформами.
- Гіпотези й відомі проблеми: де, на вашу думку, провал, і що вже пробували змінювати — це заощаджує цілий етап діагностики.
Порядок взаємодії такий: протягом одного робочого дня підтверджуємо отримання матеріалів і говоримо, чого бракує; на другий-третій робочий день повертаємося з оцінкою, планом робіт і пріоритетами за точками розриву.
Далі — коротка зустріч із продуктом і розробкою, 40-60 хвилин, щоб звірити трактування метрик і домовитися про формат звітності. Достатньо однієї людини з боку замовника з правом ухвалювати рішення — решта долучаються точково.
Опишіть задачу й надішліть те, що вже є: навіть частковий набір даних дозволяє назвати строки й склад робіт без попередніх здогадів.
