30+ ошибок в мобильных приложениях, из-за которых вы теряете заказы

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

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

Мы оформили его в PDF-формат и приправили скриншотами реальных приложений. Получилось около 60 страниц с ошибками и рекомендациями по устранению.

В исследовании участвовали мобильные приложения со средним оборотом 100 млн ₽ в год. Это сегмент среднего рынка. Позиционирование сервисов — доставка фастфуда. Агрегаторы (вроде Delivery Club и Яндекс. Еда) не участвовали, только приложения самих заведений:

Ошибка 1/10. Только в 7% приложений есть онбординг, в остальных его нет

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

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

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

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

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

Ошибка 2/10. В приложении можно авторизоваться только по номеру телефона

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

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

Ошибка 3/10. В 80% приложений нет «мягкой» регистрации

И поэтому пользователь не может сделать заказ, не авторизовавшись. А в некоторых приложениях без авторизации даже нельзя пользоваться основными функциями, и именно в этом кроется ошибка.

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

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

Ошибка 4/10. В 50% приложений нет таббара

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

Он повысит интуитивность, удобство использования и снизит риск потери интереса у пользователей.

Ошибка 5/10. В 50% приложений есть ошибки, причины возникновения которых непонятны

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

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

Ошибка 6/10. В 50% приложений нет инструкции к программе лояльности

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

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

Ошибка 7/10. В 80% приложений нет формы обратной связи

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

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

Ошибка 8/10. 50% приложений при удалении профиля не готовят пользователя к последствиям

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

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

Ошибка 9/10. Только в 26% приложений есть поиск по товарам

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

Либо сделает это в другой раз.

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

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

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

Ошибка 10/10. В 50% приложений нет сортировки блюд по категориям

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

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

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

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

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

У них ограниченный функционал

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

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

Нет индивидуальности в дизайне

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

В них не отразить уникальность, не показать свое УТП. Хорошо, если приложение приносит достаточное количество заказов, тогда дизайн можно отодвинуть на второй план. А если нет? А ведь именно это мы и наблюдаем.

Сложности интеграции со сторонними сервисами

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

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

Низкая производительность

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

В дальнейшем придется переходить на более мощные платформы либо подумать о будущем и сразу создать кастомное решение.

Сложности с техподдержкой

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

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

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

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

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

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

То есть вы получаете все преимущества кастомной разработки, но в 2 раза дешевле и при этом не теряете в качестве, как в случае с конструктором или коробочным решением.

Заказать разработку на MØDUL можно у нас ↴