Приложение удаляют после первого запуска: что происходит в первые 60 секунд

Ложное восприятие

Для команды это может выглядеть как проблема привлечения: пользователи приходят, но не остаются. Возникает желание увеличить рекламный бюджет, добавить новые функции или переделать визуальный стиль.

Но причина может быть гораздо ближе. Приложение не запускается, пользователь не понимает его ценность или вынужден проходить длинный онбординг, прежде чем сможет что-либо сделать.

Первый запуск — это не приветствие. Это момент, когда пользователь проверяет обещание продукта на практике.

Разберём, что может пойти не так в первые 60 секунд, как это влияет на бизнес и что проверить, прежде чем вкладывать деньги в привлечение новых пользователей.

У человека, который впервые открыл приложение, ещё нет привычки им пользоваться. Он не знает, насколько продукт удобен, можно ли ему доверять и действительно ли он решает нужную задачу.

Поэтому в начале пользовательского пути возникают три вопроса:

• Что это приложение даст мне? Какую мою задачу оно решает?
• Как здесь получить результат? Куда нажать и что сделать?
• Стоит ли продолжать? Оправдывает ли польза потраченное время и усилия?

Пользователь не обязательно формулирует эти вопросы осознанно. Он смотрит на экран, нажимает на элементы, пытается разобраться и оценивает свой опыт.

Если приложение быстро отвечает на эти вопросы, вероятность продолжения использования выше. Если нет — человек может закрыть его, отложить знакомство на потом или удалить.

Прежде чем пользователь оценит дизайн, он должен получить работающий продукт.

Представим, что человек скачал приложение для планирования питания. Он открывает его, но экран загрузки не исчезает. Или приложение закрывается сразу после запуска. Или вместо главного экрана появляется сообщение об ошибке без объяснения, что делать дальше.

В этот момент уже не имеет значения, насколько хорошо продуманы сценарии и насколько красиво выглядят макеты.
Пользователь не может воспользоваться продуктом.

• Технические проблемы первого запуска бывают разными:
• приложение зависает на заставке или слишком долго загружается;
• возникает сбой при авторизации или создании аккаунта;
• данные не загружаются из-за ошибки сети или обращения к серверу;
• приложение некорректно работает на отдельных устройствах;
• пользователь нажимает кнопку, но не получает обратной связи;
• после ошибки невозможно понять, как продолжить.

Часть проблем проявляется не у всех. Запуск может проходить нормально на одном устройстве, но сопровождаться ошибкой на другом. Поэтому успешный тест на телефоне разработчика ещё не означает, что приложение работает без сбоев у реальных пользователей.

Почему это проблема не только разработки

Предположим, компания потратила деньги на рекламу и привела пользователя в приложение. Он готов попробовать продукт, но сталкивается с ошибкой при входе.

Расходы на привлечение уже понесены, а ценность продукта пользователь так и не увидел. Если он не станет разбираться в причинах, команда потеряет возможность превратить его в активного пользователя или клиента.

Поэтому важно проверять не только наличие технических ошибок, но и то, как приложение ведёт себя при их возникновении.

Если данные не загрузились, можно показать понятное сообщение и кнопку повторной попытки. Если сеть недоступна, объяснить, что произошло. Если операция занимает время, показать состояние загрузки, а не оставлять человека гадать, работает ли приложение.

Хороший интерфейс не исправляет сломанный сервер. Но он помогает не усугублять техническую проблему неопределённостью и беспомощностью пользователя.

Что проверить: успешный и неуспешный запуск, авторизацию, загрузку данных, работу при нестабильном интернете, состояния ожидания и ошибки на разных устройствах.

После запуска пользователь может увидеть несколько экранов с приветствиями:

• «Добро пожаловать!»
• «Мы создали удобный инструмент для вашей продуктивности».
• «Управляйте задачами и достигайте большего».

Затем — ещё один слайд, ещё одна иллюстрация и предложение нажать «Продолжить».
Проблема не в самом онбординге. Проблема в том, что онбординг часто превращается в презентацию продукта, а не помогает человеку получить пользу.

Онбординг должен не просто рассказывать, что умеет приложение, а показывать, зачем эти возможности нужны конкретному пользователю.

Сравним два варианта.

Вариант 1. Рассказываем о функции

«В приложении есть персональные рекомендации, статистика и гибкие настройки».

Пользователь узнаёт о возможностях, но не понимает, какую из них ему стоит попробовать и что он получит в результате.

Вариант 2. Объясняем ценность

«Составьте план тренировок под свой график и отслеживайте прогресс, чтобы заниматься регулярно».

Здесь уже видна связь между действием и результатом. Человек понимает, для чего ему приложение.
Но даже второй вариант останется обещанием, если после него пользователь не сможет быстро составить план или увидеть, как работает отслеживание прогресса.

Поэтому лучший способ показать ценность — не обязательно объяснять её словами. Часто полезнее сразу дать человеку попробовать основную функцию.

Например, вместо пяти слайдов о возможностях приложения для бюджета можно предложить добавить первую покупку и показать, как она влияет на расходы. А в приложении для изучения языков — дать пройти короткое упражнение, а не рассказывать о методике обучения.

Когда онбординг становится препятствием

Онбординг может мешать, если:

• пользователь должен просмотреть много экранов до начала работы;
• текст перечисляет функции, но не объясняет пользу;
• все пользователи получают одинаковые инструкции, хотя у них разные задачи;
• приложение просит заполнить подробную анкету до первого полезного действия;
• после прохождения онбординга человек всё равно не понимает, с чего начать.

Длинный онбординг не всегда плох. В фитнес-приложении, медицинском сервисе или инструменте с персональными рекомендациями вопросы могут быть необходимы для настройки продукта. Но каждый дополнительный шаг должен давать понятную пользу или быть действительно необходимым.

Если пользователь отвечает на десять вопросов, а затем получает тот же экран, что и человек, который ничего не заполнял, он закономерно может усомниться в смысле этих усилий.

Регистрация, подтверждение номера телефона, заполнение профиля, согласие на уведомления, доступ к геолокации — каждый из этих шагов может быть оправдан. Но вместе они создают барьер между установкой и первой пользой.

Представим, что пользователь открыл приложение доставки. Вместо выбора ресторана он должен зарегистрироваться, подтвердить номер, заполнить профиль и разрешить уведомления. При этом он ещё не знает, какие рестораны доступны, сколько стоит доставка и подходит ли ему сервис.

Команда просит доверие авансом, не показав, за что пользователь должен его дать.

В другом сценарии приложение может позволить сначала посмотреть каталог, выбрать товар или собрать корзину, а зарегистрироваться — перед оформлением заказа. Если создание аккаунта действительно необходимо раньше, важно объяснить причину и не запрашивать лишние данные. То же касается системных разрешений.

Запрос на доступ к геолокации выглядит логично, когда пользователь хочет найти ближайшие пункты выдачи. Но если приложение спрашивает о местоположении сразу после запуска, не объясняя зачем, человек может отказаться.

С уведомлениями похожая ситуация. Необязательно просить разрешение в первые секунды. Лучше сначала показать пользу: например, объяснить, что уведомление сообщит о готовности заказа или напомнит о запланированном занятии. Вопрос не в том, чтобы убрать все запросы. Вопрос в том, чтобы показывать их в тот момент, когда пользователь понимает их смысл.

Перед переносом регистрации или разрешений стоит проверить технические, юридические и продуктовые ограничения. В некоторых сценариях данные действительно нужны до продолжения работы.

Хороший первый экран отвечает на вопрос: «Что мне сделать, чтобы получить результат?»

Для этого не обязательно упрощать весь интерфейс до одной кнопки. Важно выделить основное действие для нового пользователя и убрать конкуренцию между равнозначными элементами.

Помогают конкретные решения:

• заметная кнопка главного действия;
• короткая подсказка рядом с ней;
• пример того, что можно сделать;
• пустой экран, который объясняет следующий шаг;
• возможность пропустить необязательную настройку и вернуться к ней позже.

Особенно важно продумать пустые состояния. Если пользователь ещё не добавил ни одной задачи, привычек или документов, экран не должен выглядеть сломанным. Он может объяснить, с чего начать, и предложить выполнить первое действие. Вместо пустого списка задач можно показать: «Здесь появятся ваши задачи. Создайте первую, чтобы начать планировать день».
Это небольшое изменение помогает пользователю двигаться дальше без дополнительных инструкций.

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

Например, он прошёл регистрацию, заполнил профиль и изучил основные разделы. Но не создал первую задачу, не получил рекомендацию, не нашёл нужную информацию и не завершил ни одного полезного сценария. Он потратил время, но не понял, что изменилось к лучшему.

В продуктовом дизайне есть понятие aha-момента — момента, когда человек впервые осознаёт ценность продукта через собственный опыт. Это не обязательно эффектный экран или анимация. В приложении для заметок таким моментом может стать сохранённая и найденная по поиску запись. В финансовом сервисе — наглядный отчёт о расходах. В приложении для обучения — первое выполненное упражнение с понятным результатом.

Aha-момент зависит от задачи продукта. Для одного сервиса это может быть первое целевое действие, для другого — несколько действий, после которых пользователь замечает пользу. Задача команды — определить этот момент и сделать путь к нему как можно короче.
При этом важно не путать быстрое действие с реальной ценностью. Если человек нажал на кнопку, но не получил ожидаемого результата, формально сценарий пройден, а продуктовая задача не решена.

Поэтому полезно спрашивать не только «сколько пользователей нажали кнопку?», но и «сколько из них действительно получили то, ради чего пришли?».

Чтобы найти проблемы первого запуска, не обязательно сразу заказывать масштабное исследование или полностью переделывать интерфейс. Начать можно с простой проверки, которая займёт около 10 минут. Откройте приложение так, как будто вы видите его впервые. Если вы давно работаете над продуктом, лучше дополнительно попросить человека, который с ним не знаком, выполнить тот же сценарий.

Ответьте на пять вопросов.

1. Понятна ли ценность с первого экрана?
Может ли человек своими словами объяснить, какую задачу решает приложение и что он сможет получить?

2. Можно ли начать пользоваться продуктом без лишних препятствий?
Какие шаги стоят между запуском и первым полезным действием? Все ли обязательны именно сейчас?

3. Объясняет ли онбординг, зачем нужны функции?
Он помогает получить результат или просто перечисляет возможности приложения?

4. Что произойдёт, если что-то пойдёт не так?
Проверьте загрузку, нестабильное соединение, ошибки входа и другие проблемные состояния. Понятно ли человеку, что делать дальше?

5. Получит ли пользователь первую пользу в рамках начального сценария?
Есть ли конкретное действие, после которого он увидит результат, а не просто окажется на главном экране?

Если хотя бы на один вопрос сложно ответить, это повод проверить соответствующий сценарий.

Что наблюдать во время проверки

Не подсказывайте участнику, куда нажимать. Попросите его выполнить конкретную задачу, например: «Представьте, что вы хотите спланировать следующую неделю. Попробуйте сделать это с помощью приложения».

Смотрите, где он останавливается, какие элементы игнорирует, что пытается нажать и какие вопросы задаёт. Не объясняйте интерфейс до завершения попытки. Иначе вы проверите не приложение, а свою способность его презентовать.

После прохождения сценария спросите:

• Что вы поняли о приложении?
• Какую задачу оно помогает решить?
• Что было непонятно?
• Захотелось бы вам продолжить пользоваться им? Почему?

Ответы полезны, но наблюдаемое поведение не менее важно. Человек может сказать, что всё понятно, и при этом несколько раз ошибиться при выполнении ключевого действия. Проверка на нескольких людях не заменит аналитику и полноценное исследование, но часто помогает обнаружить очевидные препятствия ещё до того, как команда потратит ресурсы на их масштабирование.

Какие метрики покажут, что проблема действительно есть

Впечатлений от тестирования недостаточно, если нужно понять масштаб проблемы на реальных пользователях. Для этого стоит посмотреть на несколько показателей.

Доля пользователей, выполнивших ключевое действие в первой сессии. Например, сколько людей после запуска создали первую задачу, завершили упражнение или добавили товар в корзину. Ключевое действие должно отражать ценность конкретного продукта. Конверсия между этапами первого запуска. Сколько пользователей открыли приложение, завершили регистрацию, прошли онбординг и дошли до целевого действия? Резкое снижение между двумя этапами помогает найти место, которое стоит проверить.

Технические ошибки и сбои. Частота аварийных завершений, ошибки авторизации и загрузки данных, время запуска. Эти показатели помогают отделить проблемы интерфейса от технических препятствий.

Возвращаемость на следующий день. Какая доля пользователей возвращается после первого запуска? Этот показатель помогает оценить раннее удержание, но сам по себе не объясняет, почему люди уходят.

Удаления в первый день. Если платформа и используемые инструменты аналитики позволяют надёжно получать такие данные, их можно сопоставлять с поведением пользователей. Но удаление приложения не всегда можно точно связать с конкретной сессией или причиной ухода.

Не стоит пытаться улучшить все показатели одновременно. Сначала найдите проблемный этап, сформулируйте гипотезу и проверьте её. Например: «Мы предполагаем, что пользователи не доходят до первого полезного действия, потому что обязательная регистрация занимает слишком много времени».

Дальше можно проверить альтернативный сценарий: разрешить просмотр основной функции до регистрации, если это допускает логика продукта. Затем сравнить, как изменились завершение целевого действия и последующее удержание. Важно следить не только за конверсией на одном этапе, но и за качеством результата. Упрощение регистрации может увеличить число первых действий, но не обязательно приведёт к росту числа пользователей, которые возвращаются.

Что делать, если пользователи уходят после запуска

• Не начинайте с редизайна всех экранов. Сначала определите, на каком этапе возникает препятствие.
• Если приложение не запускается или выдаёт ошибки, приоритет — техническая стабильность.
• Если пользователь не понимает, зачем ему продукт, пересмотрите первый экран и формулировку ценности.
• Если онбординг слишком длинный и не помогает начать работу, уберите необязательные шаги или перенесите подсказки в контекст использования.
• Если пользователь не может найти основное действие, упростите главный экран и сделайте следующий шаг очевидным.
• Если человек выполняет сценарий, но не получает ожидаемого результата, проверьте не только интерфейс, но и сам продукт: действительно ли он решает задачу, ради которой его скачивают?

Последний пункт принципиален. Дизайн способен убрать лишние препятствия, сделать сценарии понятнее и помочь человеку быстрее получить пользу. Но он не компенсирует отсутствие реальной ценности.

Пользователь не обязан разбираться в вашем приложении, терпеть ошибки или читать длинные инструкции, чтобы понять его смысл. У него нет причины оставаться, если продукт не выполняет обещание или не помогает получить результат. Поэтому первые секунды использования стоит проектировать так же внимательно, как оплату, поиск или основной рабочий сценарий.

Хороший первый опыт складывается из нескольких условий: приложение стабильно запускается, пользователь понимает его ценность, быстро находит следующее действие и получает результат, ради которого пришёл. Если один из этих элементов не работает, дополнительные функции и рекламные кампании могут не решить проблему.

Начните с простого вопроса: сколько действий нужно новому пользователю, чтобы впервые почувствовать пользу вашего приложения?
Если ответить на него сложно, возможно, стоит начать не с новых экранов, а с разбора текущего пользовательского пути.