Топ-5 инсайтов, которые помогут избежать ошибок в разработке мобильного приложения: опыт экспресс-доставки «Перекрёстка»

Привет, vc.ru! На связи Оксана Щирба, директор по продукту мобильного приложения «Перекрёстка». В статье расскажу о том, как внедрять изменения внутри уже работающего сервиса и что поможет усовершенствовать ваши ритейл-продукты.

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

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

Кейс со знаком «минус». Впервые мы столкнулись с этим, когда один из стейкхолдеров (заинтересованный в результатах работы сотрудник или департамент) предложил поднять персональные предложения в топ главного экрана, опустив другие важные блоки. Он считал, что это повысит их охват. Так как мы стараемся прислушиваться к нашим стейкхолдерам и у нас не было контраргументов, мы убрали часть блоков с главного экрана, чтобы освободить место под персональные предложения. Уже после того, как внедрили аналитику и провели A/B-тест, поняли, что гипотеза не подтвердилась, а негативные побочные эффекты проявились для клиентского пути доставки — уменьшился трафик в разделе «Каталог», с которого начинается путь клиента доставки.

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

Сначала у нас не было аналитики по просмотрам историй. Приходилось либо публиковать огромное количество историй, либо бесконечно договариваться с людьми, которые хотели их публиковать. Первое выливалось в существенные затраты на продакшн, второе — в рост временных ресурсов. После внедрения аналитики оказалось, что оптимальное количество историй — всего 11. Этого было достаточно, чтобы закрыть потребность 95% аудитории продукта.

Кейс со знаком «плюс». Обычно, больше 70% продуктовых корзин состоит из товаров, которые пользователь покупал до этого. Не всем удобно каждый раз набирать их заново из каталога. В разговорах с пользователями мы часто получали просьбу добавить раздел «Уже покупали». Но дело в том, что он уже был, но не был заметен пользователям. Задача заключалась в том, чтобы сделать его более явным, не жертвуя позицией основного каталога.

Продуктовая аналитика показала, что в очень заметный раздел «Избранное» заходит меньше 1% аудитории. Количество товаров в нём редко превышало 1-2, конверсия добавления оттуда в корзину стремилась к нулю. Мы решили разместить этот раздел в менее заметном месте, а на его место поставить «Уже покупали» — один из самых конверсионных разделов приложения. Задача была решена в пользу клиента. На текущий момент этот раздел на 4 месте по количеству добавлений в «Корзину». Он уступает только «Каталогу», «Поиску» и разделу «Скидки».

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

Кейс со знаком «минус». Мы практически никогда не внедряем что-то новое для всей аудитории сразу, но бывают исключения. Все они, однако, подтверждают, что тестировать что-то новое массово — плохая идея. Например, в мобильное приложение «Перекрёстка» мы внедряли обновлённую программу лояльности массово. Причём по уважительной причине: очень хотелось вернуть клиентам их баллы. В результате взлетела нагрузка на колл-центр, а нам приходилось в режиме реального времени работать с большим числом обращений и исправлять недоработки. В результате поток обращений в колл-центр вырос в 1,5 раза, из-за чего пришлось увеличить штат операторов на 40% и в оперативном режиме исправлять недоработки. Также потребовалось время на подготовку и адаптацию материалов, обучение сотрудников новым правилам и программе.

Кейс со знаком «плюс». Изабелла Леснова, наш ведущий продакт менеджер по доставке, решила поэтапно внедрять опцию по согласованию замен для отсутствующих товаров по звонку клиенту. Даже несмотря на то, что команда верила в эту опцию и хотела быстрее предоставить сервис нашим клиентам. Это позволило вовремя заметить и исправить проблемы. Например, оказалось, что интерфейс у сборщиков заказов был сформирован не совсем корректно, а работникам требовалось больше времени для обучения новым скриптам звонков на замены. Мы скорректировали эти проблемы, провели серию обучений и постепенно внедрили функцию для всех. На это ушло больше трех месяцев, но в итоге мы добились лучшего пользовательского опыта и повысили количество принятия замен через звонки с 1% до 20%.

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

Если не проводить A/B-тесты, невозможно понять, как конкретная функция влияет на продуктовые и бизнес-метрики, а также пользовательский опыт — тем самым вы рискуете не просто не улучшить, а ухудшить последний.

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

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

Кейс со знаком «плюс». Когда мы внедряли первую версию структуры нашего каталога, то никак её не тестировали. Решение основывалось на розничной ассортиментной матрице «Перекрёстка» и на онлайн-каталогах аналогичных сервисов. На базе поведенческой аналитики удобство такой структуры не проверяли. А то, что она оказалась неоптимальной, поняли только по завершении редизайна каталога — он длился полгода. Мы проверили разную структуру каталога серией A/B-тестов. Выбрали ту, что обеспечила большую конверсию, — она существенно отличалась от изначальной.

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

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

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

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

Существует явная закономерность: чем позже мы обсуждаем фичу или какое-то решение с командой разработки, тем больше time to market — время выхода на рынок. Потому что разработчики могут сразу подсветить технические ограничения и предложить более элегантное решение.

Кейс со знаком «плюс». Сейчас, например, мы работаем над опцией добавления товара в уже сформированный заказ. Когда мы начали думать над решением, в голову приходили только сложные и трудозатратные для разработки UI-варианты. Но наш технический лид по Android как раз предложил легкое элегантное решение — добавление товара будет происходить через отдельный экран с поисковой строкой, а результаты поиска будут адаптированы по релевантности для каждого пользователя. Обновление появится в одном из ближайших релизов мобильного приложения.

***

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

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

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

А пока остаёмся в фокусе, тонусе и на связи! На все вопросы о работе команды и о нашем опыте мы с удовольствием ответим в комментариях!