О задаче

На старте пользователи терялись в приложении, на телефоне элементы экрана мешали оформить заказ, а при задержке курьера или ошибке с блюдом до поддержки было трудно достучаться. Мы изучили аудиторию, построили карту пользовательского пути с негативными сценариями, собрали прототипы, нарисовали экраны под iOS и Android, а до разработки проверили их юзабилити-тестами. Клиент получил макеты с коротким переходом от выбора блюда к заказу.

Сервис доставки еды с мобильным приложением

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

С чем пришел сервис доставки еды

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

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

Задача и цели дизайна приложения

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

Особенности приложений доставки еды

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

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

Как мы проектировали интерфейс приложения от идеи до итога

Бриф и аудит сценариев

Бриф занимает 1 день, на нем фиксируем, что клиент ждет от нового интерфейса. Аудит идет 3-5 дней, за это время смотрим текущие экраны, переход к заказу и ошибки на каждом шаге. Стратегия занимает 5-7 дней. В ней определяем, кто, зачем и в каких условиях открывает приложение, какие задачи нужно решить быстрее.

Исследование аудитории и контекста

После стратегии начинается цикл работ на 4 недели по цепочке исследование, сценарии, прототипы, UX-тесты, UI-дизайн. Исследование начинаем с аудитории и бизнес-задач клиента. Так становится понятно, какие сценарии вести в первую очередь и что можно убрать с главного экрана без потери заказов.

Карта пути и негативные сценарии

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

Прототипы и концепция первого экрана

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

UI-дизайн под iOS и Android

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

Юзабилити-тесты до разработки

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

Что получил сервис доставки и как применяет новый интерфейс

Числовые примеры из материала не являются подтверждёнными результатами клиента.

Пример результата в нише. Так обычно выглядит итог за 3 месяца в таких проектах по открытым кейсам рынка: доля оформленных заказов с 18 до 26% от начатых, возвраты пользователей в течение месяца с 22 до 30%, обращения в поддержку по оформлению заказа с 900 до 500 в месяц. Сравнение идет за равные периоды без сезонных акций.

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

Ограничения проекта

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

Выводы для владельца приложения доставки

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

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