Онбординг: 60-секундний тест на відтік у перший день

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

Як провести 60-секундний тест онбордингу?

Потрібні телефон, секундомір, запис екрана й людина, яка ще не користувалася застосунком. Перевстановіть його, щоб побачити те, що бачать нові користувачі.

1. Назвіть першу цінність одним реченням: перша внесена витрата, перший зіграний рівень. Якщо не виходить — це перша знахідка. 2. Дайте одну інструкцію: «Скористайся цим за призначенням». Нічого про те, куди натискати. 3. Запускайте секундомір із тапу по іконці. Зупиняйте на першій цінності — або коли людина здається чи просить допомоги. 4. Мовчіть. Кожне бажання щось пояснити — знахідка; запишіть її. 5. Повторіть із двома-трьома людьми, на iPhone і на Android. Троє, що зупинилися на одному екрані, — це вже закономірність.

Шістдесят секунд — не офіційний ліміт, а зручна планка для людини, яка ще вирішує, чи лишати застосунок.

Чому користувачі йдуть із застосунку в першу хвилину?

Бо ще нічого не отримали, а кожен екран до першої цінності — це витрата без винагороди. У рекомендаціях Google щодо запуску прямо попереджають: якщо старт задовгий, користувач може вийти із застосунку ще до того, як той повністю завантажиться (Android Developers: час запуску застосунку). Те саме стосується кожної форми, каруселі й системного запиту, що йдуть далі.

Чи варто вимагати реєстрацію, перш ніж людина спробує застосунок?

Лише якщо без акаунта він нічого не вміє. Інакше просіть зареєструватися тоді, коли вже є що зберегти.

App Review Guidelines від Apple кажуть: якщо в застосунку немає суттєвих функцій, прив’язаних до акаунта, людям слід дозволити користуватися ним без входу, а застосунок зі створенням акаунта мусить давати змогу й видалити акаунт у самому застосунку (правило 5.1.1(v)).

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

Чи просити дозвіл на сповіщення, геолокацію й відстеження під час запуску?

Ні — просіть тоді, коли людина дійшла до функції, якій це потрібно.

• Apple радить чекати, доки людина скористається функцією, що потребує доступу, і не просити дозволів під час запуску, якщо застосунок може працювати без цих даних (HIG: Privacy).
• Android радить просити дозвіл у контексті — коли користувач починає взаємодіяти з функцією — і лишати застосунок робочим, якщо він відмовить (Android Developers: запит дозволів під час виконання).
• Сповіщення на Android 13 і новіших для нових встановлень за замовчуванням вимкнені; Google радить спершу дати людям освоїтися, а потім питати у відповідь на дію — скажімо, тап по дзвіночку (Android Developers: дозвіл на сповіщення).
• Відстеження на iOS потребує дозволу через App Tracking Transparency, і застосунок не може приховувати функції, доки людина його не дасть (правило 5.1.2(i)). Екрани перед системним запитом, що обіцяють винагороду чи імітують сам запит, ведуть до відхилення (HIG: Privacy).

Як виправити: перенесіть кожен запит до його функції, а в поясненні для системного запиту простим реченням скажіть, що застосунок робить із цими даними. Стос системних запитів на першому запуску — найпростіше, що тут можна прибрати.

Чи допомагають каруселі й туторіали в онбордингу?

У звичній формі — рідко: слайди, що пояснюють застосунок, яким ще ніхто не користувався. Подивіться, чи ваш тестувальник їх читає.

Рекомендації Apple: навчати через взаємодію, віддавати перевагу контекстним підказкам замість одного довгого сценарію, робити будь-який туторіал необов’язковим і доступним пізніше, а несуттєве налаштування відкладати й давати розумні значення за замовчуванням (HIG: Onboarding).

Як виправити: замініть карусель однією підказкою там, де відбувається дія. До першої цінності — щонайбільше одне питання для налаштування.

Що показувати на першому екрані, коли даних ще немає?

Щось корисне й один очевидний наступний крок. Перший екран нового користувача часто найпорожніший у застосунку: чистий список і маленький плюс у кутку.

Рекомендації Apple щодо завантаження радять показувати щось якомога швидше, бо відсутність контенту люди можуть сприйняти як проблему застосунку (HIG: Loading). Порожній стан — та сама проблема, тільки без спінера.

Як виправити: проєктуйте порожній стан як окремий екран: один рядок про те, що тут з’явиться, і дія, яка це наповнить, — найбільший елемент на екрані. Приклад контенту допомагає, коли цінність видно лише з даними.

Як швидко має відкриватися застосунок?

Так, щоб очікування ніхто не помітив. Apple зазначає, що люди іноді не хочуть чекати довше за кілька секунд (HIG: Launching). Android vitals у Play Console вважає надмірним холодний старт від 5 секунд, теплий — від 2 секунд і гарячий — від 1,5 секунди (Android vitals: час запуску, дані станом на 27 жовтня 2026).

Перший запуск після встановлення — це холодний старт, і він припадає саме на першу хвилину.

Як виправити: міряйте холодний старт на Android-телефоні середнього класу, а не на найновішому флагмані. Потім приберіть зі шляху до першого кадру все зайве: SDK, ініціалізовані раніше, ніж знадобляться, віддалений конфіг, який вантажиться до того, як щось намальовано. Google радить ліниву ініціалізацію (Android Developers: час запуску застосунку); Apple — екран запуску, майже ідентичний першому екрану, а не брендовану заставку (HIG: Launching).

Чи очевидна головна дія?

Це має бути перше, що новачок натисне без підказки. Якщо палець тестувальника зависає, гортає чи відкриває меню — на екрані немає зрозумілого першого кроку.

Як виправити: одна головна дія на екран, у зоні досяжності великого пальця, названа за результатом («Додати першу витрату»), а не за елементом («Новий»). На практиці наступний крок має бути там, де палець уже є.

Чек-лист на 60 секунд

Першу хвилину наших власних застосунків ми тестуємо так само, на iPhone і на Android: чисте встановлення, холодний старт і тестувальник, який ще не бачив цей білд.

Що робити, якщо ваш застосунок уже втрачає людей у першу хвилину?

DriveCode розробляє застосунки для iOS та Android, Flutter-first. Виправлення зазвичай невеликі й конкретні — перенести запити, прибрати карусель, відкласти роботу під час старту, — а не новий застосунок. Якщо команди, яка його будувала, вже немає, перше завдання — мати змогу випускати такі оновлення зі своїх акаунтів. З цього ми й починаємо, коли підхоплюємо застосунок для iOS чи Android: спершу доступи, потім письмовий висновок і фіксована ціна за кожен модуль. Для нового продукту ми проєктуємо першу хвилину разом з усім застосунком — дивіться, як ми створюємо застосунки для iOS та Android на Flutter і скільки часу займає розробка застосунку.

Що часто питають

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

Чи буває правильно просити дозволи під час онбордингу? Так, коли застосунок не працює без цих даних — як навігатор без геолокації. Рекомендації Apple щодо онбордингу це допускають і радять використати онбординг, щоб пояснити, навіщо потрібен дозвіл.

Може, взагалі прибрати реєстрацію? Не обов’язково. Перенесіть її туди, де акаунт щось дає людині: збереження прогресу чи синхронізацію між пристроями.

Як виміряти це в застосунку, який уже в сторах? Проводьте тест із секундоміром на кожному релізному кандидаті й перевіряйте час запуску в Android vitals. Аналітична воронка від першого відкриття до першої цінності покаже, де зупиняються реальні користувачі.