Контекст

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

Проблемы

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

Цели проекта

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

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

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

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

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

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

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

Что говорили пользователи

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

Katie:
Ok, so what is RSVP?
Support:
In the context of social invitations, RSVP is a request for a response from the invited person or people. It is an initialism derived from the French phrase Répondez s'il vous plaît, literally "Reply if you please" or "Please reply".
Katie:
How do I find out I've been invited?
Support:
A black raven will appear on your windowsill, a paper scroll attached to his leg. You'll need to figure out how to take it off. Everything you'll need to know will be written there. Don't forget to send your raven back.

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

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

UX-Flow

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

Jobs To Be Done

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

Jobs To Be Done

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

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

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

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

Навигация

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

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

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

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

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

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

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

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

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

????

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

????

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

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

Выводы

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

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

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

Результаты

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

Выводы

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


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

Что я узнал

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