Кейс з розробки мобільного додатка для компанії 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 дійсно зацікавлений у отриманні реального зворотного зв'язку від користувачів та покращенні якості своїх послуг. Паралельно працюємо над удосконаленням особистого кабінету користувача та оптимізуємо всю систему.