Кейс по разработке мобильного приложения для компании Delivery

Индустрия: транспортные и логистические услуги

Локация: Украина

Статус: опубликован

Сроки: 4+

Команда: UX Designer (1), UI Designer (1), Flutter Developer (3), QA Engineer (1), Product Manager (1), Project Manager (1).

О Клиенте

Delivery Group – транспортно-логистическая компания, которая начала работу в 2001 году и стала № 1 в перевозке сборных грузов для бизнеса, крупногабаритных и объемных грузов по Украине и по миру. Компания специализируется на предоставлении транспортных и логистических услуг для сектора В2В. Более 430 отделений-складов работают по всей стране. В течение месяца Delivery обслуживает около 500 тыс. клиентов, совершая больше тысячи рейсов транспорта.

Знакомство с проблемой Клиента

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

Руководство компании решило отдать разработку, дальнейшее сопровождение и актуализацию на аутсорс. От новой разработки требовалось:

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

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

Со своей стороны, мы подготовили концепт-приложение на 6-7 интерактивных экранов, вместо затребованных 2-3-х. Наша компания всегда оцифровывает запрос клиента, прежде чем начать работу, чтобы визуализировать будущий проект еще на стадии переговоров. Мы заинтересованы в поиске лучшего решения, понятности и доступности предоставляемых материалов.

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

Решение

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

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

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

Основной компонент. В него поместили все, что касалось оформления заказа, создания ТТН (торгово-транспортной накладной), уведомлений и поиска, карта отделений и документы.

Коммерческий компонент. В нем разместили раздел “Акции и новости”. Вся информация, которая касалась скидок, акционных предложений, новинок сервиса и прочее расположилась в данном компоненте.

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

Мобильное приложение Delivery – кроссплатформенное программное обеспечение для автоматизации процесса доставки

На разработку мобильного приложения Delivery было запланировано 4 месяца, так как мы опирались на пожелание Клиента выйти в релиз до конца года. Учитывая сжатые сроки, работу построили следующим образом: проектирование структуры и описание согласованной и утвержденной структуры user-кейсами, готовые сценарии сразу отдавали в дизайн, а дизайн – на программирование. Такую модель утвердили с целью быстрее приступить к работе и повысить лояльность Клиента.

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

Клиент изначально предусматривал наличие интерфейса для зарегистрированных и незарегистрированных пользователей, так как многие клиенты Delivery уже имели личные кабинеты на сайте и были пользователями старого приложения. Поэтому для зарегистрированных пользователей мы персонализировали часть экрана – на “Главном экране” сверху разместили шкалу, которая отображает текущий бизнес-план и тарифную ячейку. Для незарегистрированных вместо шкалы – кнопка-предложение “Зарегистрироваться”, побуждающая к действию.

Основной сегмент клиентов компании – это юридические лица и предприниматели, которые активно пользуются услугами Delivery Group. В месяц компания совершает более 1500 рейсов, доставляя заказы своих клиентов. Но клиенты хотят не только отслеживать отправления, они хотят получать аналитику выполненных заказов. Поэтому для удобства клиентов Delivery Group на главном экране мы разделили организацию ТТН на две части: фильтрация и сортировка. Встроили возможность группировать итоги, чтобы пользователи более точно отслеживали операции.

В разделе “Акции и новости” мы убрали всеми любимый баннер-слайдер, потому что для мобильного приложения, у которого реализован свайп переход между экранами, дополнительный слайдер вверху будет плохой практикой и в реализации, и в отработке. Это будет раздражающий фактор для пользователя. Юзер использует приложение, в первую очередь, для работы, поэтому отвлекающих элементов быть не должно. Тем более в разделе уже предусмотрен поиск, а внутри находится список и дополнительный вход.

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

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

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

Проблемные стороны проекта

Самым сложным был калькулятор ТТН. Большой блок этого приложения. В нем пользователь рассчитывает или оформляет заявку. Сначала он выбирает город отправки и получения, потом – тип доставки. Если пользователь авторизован, то варианты в строке поиска подставляются автоматически. Это касается и истории по типам доставки: адреса, которые чаще всего использовались, подставляются автоматически, но клиент может изменить данные, если необходимо. Дата отправки и прибытия рассчитывается тоже автоматически.

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

Допустим, пользователь выбрал тип «Груз». Следующее действие – указать количество, вес и объем. Если объем просчитан, его вписывают сразу, если нет – пишут параметры груза – и объем просчитывается автоматически. Также существуют дополнительные услуги. К слову, каждый тип груза имеет дополнительные услуги. Пользователь рассчитывает стоимость – на экран вместе со стоимостью выводится дополнительная услуга страхования и оформления. Это первый шаг. Далее пользователь выбирает варианты: продолжить оформление, сохранить как шаблон или черновик.

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

Подключение множественных действий калькулятора ТТН к системе Клиента составило основной объем сложностей, с которыми мы столкнулись в работе. Нам постоянно приходилось учитывать особенности бэкенда, который был на стороне Клиента, и подстраиваться под них. Все потому, что бэкенд был создан давно и за короткое время, плюс специалисты, участвовавшие в разработке, сменились. Это оказало свое влияние на разработку будущего проекта. Не все наши решения, в особенности в дизайне, имели техническую возможность для реализации. Чтобы не провоцировать сбои в работе бэкенда Клиента, а на нём был завязан и сайт, и приложение, и система внутреннего учета, мы вынужденно вносили изменения в утвержденные user-кейсы и дизайн. Стоит отметить, что в данной ситуации между нами и Клиентом было полное понимание и обоюдное желание прийти к общему решению. Совместно мы находили варианты преодоления всех сложностей.

К примеру, была ситуация, когда бэкенд Клиента не мог обработать данные с калькулятора. Чтобы устранить проблему, необходимо было или исправить запросы на сервер, которые уже существовали для сайта, или, в большинстве случаев, изменить запросы самого приложения. Чаще всего мы использовали второй вариант, и для этого приходилось вынужденно делить запросы - с одного экрана на бэкенд поступало по 5-6 запросов, а иногда эта цифра доходила до 11-ти. Естественно, это сказывалось на скорости работы приложения. Тем не менее, мы оптимизировали данные и свели количество запросов к 3-4.

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

Дизайн

Мобильное приложение Delivery – это, в первую очередь, объемный функционал. Создавая его, было важно не отступать от принципов UX/UI. Речь идет о таких принципах, как последовательность, иерархия, доступность и пользовательский опыт. Решением, направленным на упрощение, стала реализация ряда подсказок, которые помогут провести пользователя по цепочке действий – от старта к финишу. Большое количество подсказок мы сделали ситуативными, они появляются в зависимости от сценария. Например, пользователь собирается совершить первое действие – перейти на функционал с картами. Он увидит три цвета маркеров, и не будет знать, что каждый из этих маркеров значит, пока на него не кликнет. Для того чтобы это решение было более осознанно, перед тем как он попадет на карту, у него появится интерактивная подсказка. На ней будут элементы всех трех маркеров, всех цветов, и возле каждого цвета написано, что он означает. Подсказку можно смахнуть – это легкое действие, но при этом пользователь получает краткую инструкцию к тому, что его ожидает впереди.

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

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

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

Результат

На реализацию и тестирование приложения ушло 6 месяцев. Всего в мобильном приложении Delivery вышло более 70 экранов и порядка 50 функций. Предусмотрены сценарии для гостей, новых и постоянных пользователей. Одновременно каждому пользователю при оформлении ТТН присваивается роль: Отправитель, Получатель или Плательщик. Сложная система подкреплена внутренними подсказками и индикаторами, которые помогают пройти весь путь от создания ТТН к завершению заказа, получению квитанций и совершению оплаты. На каждом этапе пользователь может подключить дополнительные услуги. Присутствует обратная связь, представлен полный спектр предложений компании для своих клиентов.

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

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

Сравнивать приложение Delivery с привычными службами малогабаритной доставки – это все равно, что сравнивать перевозки легковыми автомобилями и грузовиками. Тип пользователя, объемы и бизнес-модели разнятся. При этом, учитывая пока то, что целевая аудитория сосредоточена в Украине в категории «Бизнес» приложение уверенно входит в топ-20 в https://play.google.com/ и топ-30 https://apps.apple.com/.

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

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