Приложение для курьера

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

  • 4,2 (+28%)
    NPS
  • 32% (+15%)
    SLA
  • 8% (+12%)
    CSAT
Моя роль
Product designer, UX-research
Команда
PM, Аналитик, Разработчики
Платформы
Android
Длительность
8 месяцев

Контекст

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

Цели проекта

Перед началом редизайна мы синхронизировались с бизнесом и зафиксировали ключевые задачи, которые приложение должно было решать в ближайшей перспективе

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

Исследования

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

Обратная связь

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

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

Анализ метрик

Смотрели на ключевые показатели — SLA, CSAT и NPS. Все три были ниже целевых и подтверждали, что UX-проблемы напрямую влияют на качество работы. Конкретные цифры закрыты NDA

UX-Flow

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

Jobs To Be Done

Параллельно сформулировали и сверили JTBD — опирались на боли из интервью

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

Формирование гипотез

На основе находок сформулировали проверяемые предположения по каждой проблемной зоне

Навигация

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

  • Профиль
    Курьер открывает приложение в движении: ему нужно быстро сориентироваться, найти нужный раздел и считать ключевую информацию по заказам
  • Понятное время доставки
    Если явно подписать каждое значение времени, курьеры будут лучше понимать дедлайны и реже ошибаться при планировании

Страница заказа

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

  • Чёткая визуальная иерархия
    Если выстроить иерархию — динамические данные крупнее и заметнее статичных — курьеры будут быстрее считывать изменения в заказе
  • Заметный комментарий клиента
    Если выделить комментарий клиента отдельным блоком с явной подписью, важная информация перестанет теряться

Критические сценарии

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

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

Планирование реализации

????

Проверка гипотез

????

UX тест страницы курса

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

Выводы

Вариант №1 победил по всем показателям: пользователи быстрее ориентировались, точнее находили нужные блоки и выше оценили экран — 8,8 против 7,1. Взяли его за основу без структурных изменений.

Финальная сбора и работа над UI

После тестирования перешёл к финальному экрану. Концептуально ничего не менял — фокус был на точности иерархии и визуальной согласованности

Результаты

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

Выводы

Редизайн сказался не только на цифрах вовлечённости. CSI вырос с 3.2 до 4.6 — студенты стали чаще говорить, что приложение «наконец понятное». Рейтинг в Rustore поднялся с 3.1 до 4.2 без единой маркетинговой акции — только за счёт улучшения опыта


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

Что я узнал

  • Студенты учатся нелинейно — и экран должен это учитывать
    Они прерываются на недели, возвращаются в середину курса, прыгают между модулями. Главный экран должен всегда отвечать на один вопрос: «Где я сейчас?» — и держать в контексте всё, что связано с активным курсом
  • Контекст — это тоже фича
    Скачанные, календарь и уведомления казались холодными разделами. Они стали живыми, когда мы привязали их к активному курсу, а не вынесли отдельно. Никакого онбординга не понадобилось — использование выросло само
  • Синхронизация с вебом — часть UX, не технический вопрос
    Студенты переключаются между устройствами в середине курса. Если состояние не синхронизировано — доверие к приложению падает
  • Масштабируемость начинается со структуры, не с компонентов
    Прежде чем добавлять новые разделы, экран нужно было привести к чёткой иерархии. Модульная раскладка, которую мы выбрали, стала основой для роадмапа следующих двух кварталов.