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

Список от руководителя проектов компании-разработчика MobileUp Олега Широкова.

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

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

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

Нужно проверить, как приложение ведёт себя в проблемных ситуациях. Детально это изучают тестировщики, поэтому здесь речь идет о быстром smoke-тесте самых популярных кейсов.

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

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

Как должно быть: показать пользователю сообщение и предложить перейти в настройки, чтобы разрешить доступ.

Как проверить: в настройках запретить приложению доступ к геоданным и запустить приложение.

Вторая ситуация: приложению не удаётся быстро определить координаты пользователя. Например, если он находится в помещении или выключил Wi-Fi и мобильный интернет.

Как должно быть: показать последнее определённое местоположение пользователя, а если его нет — показать какую-то точку по умолчанию или заглушку, но не карту в море.

Как проверять: включить авиарежим и запустить приложение.

Первая ситуация: пользователь совершает действие, для которого нужен доступ к интернету. Например, нажимает на кнопку «Загрузить». А интернета в этот момент нет.

Как должно быть: пользователь остаётся на том же экране и видит сообщение об отсутствии интернета на понятном человеческом языке.

Как проверить: запустить приложение, выключить интернет, нажать на какую-нибудь кнопку действия.

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

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

Как проверить: запустить приложение, зайти в один из разделов, потом перейти в другой, отключить интернет, вернуться в предыдущий раздел.

Третья ситуация: интернет есть, но нестабильный — и он пропал в процессе загрузки экрана.

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

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

Четвёртая ситуация: при открытии экрана не было интернета, он появился уже после.

Обработка такой ситуации нужна не в каждом приложении и не на каждом экране. Но она очень актуальна для чатов, соцсетей и приложений, работающих с картой.

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

Как проверить: запустить приложение, включить авиарежим, выключить авиарежим.

Сервер может возвращать различные виды ошибок. При этом пользователь не должен видеть непонятные сообщения вроде «401 Token is invalid» или неопределенное «Internal server error». Нужно объяснить ему, что делать: попробовать совершить действие ещё раз через некоторое время или обратиться в службу технической поддержки.

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

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

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

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

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

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

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

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

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

В продуманных приложениях на видном месте (например, в боковом меню или в профиле) есть контакты технической поддержки. Это позволяет уменьшить количество гневных отзывов в App Store и Google Play.

Перед релизом в приложения обычно интегрируют один или несколько сервисов по сбору аналитики: Google Analytics, Mixpanel, Fabric.io, Flurry, Appsee. Собранные данные можно удобно просматривать в веб-интерфейсе.

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

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

Часть этой информации можно посмотреть в iTunesConnect или Google Developer Console и без интеграции отдельного сервиса. Полный набор: количество установок, количество активных пользователей, среднее время, проводимое в приложении и прочее, — доступен только в специализированных сервисах аналитики.

Эта информация даст понять, востребовано ли ваше приложение и помог ли бюджет на продвижение.

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

Если в приложении пользователи что-то заказывают или покупают, смотреть количество этих действий и считать конверсию удобно в аналитике. Для этого нужно настроить специальные «кастомные события». В приложении «Туту ЖД» список таких событий занимает четыре полных листа А4.

Если у вас не такой масштабный проект, то вам будет достаточно одного-трёх событий. Например, «Заказ оплачен» или «Лайк новости».

На ранних этапах разработчик обычно настраивает взаимодействие с внешними сервисами через тестовые аккаунты. Например:

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

#Кейсы