Контроль заказов: почему «атавизм» оказался критичным инструментом
Вместо того чтобы убрать раздел при миграции, мы разобрались в сценариях директоров дарксторов и перенесли функциональность в свою платформу, дополнив его под реальные инциденты
Контекст
Внутри продукта раздел считался чем-то вроде наследия. Им давно никто не занимался, владельца не было, и при переезде в новое мобильное приложение его собирались убрать
В старом мобильном приложении у директоров дарксторов был раздел «Контроль / История заказов». Там можно было посмотреть заказы за последние несколько часов: статус, кто собирал или доставлял, состав заказа, SLA, адрес, комментарии клиента.
Экраны из старого мобильного приложения для директоров дарксторов
Проблема
Но у меня была гипотеза, что редкое использование не значит низкую ценность. Возможно, раздел открывают только в особых ситуациях: когда клиент пожаловался, что ему не довезли товары, привезли не тот заказ, перепутали боксы, или когда директору нужно быстро проверить работу курьера.
Если бы раздел просто исчез, директора потеряли бы инструмент для разборов с поддержкой и контроля доставки.
Решение удалить раздел выглядело логичным только на поверхности: им пользовались нечасто, а команда нового мобайла не могла быстро перенести его технически.
Цели и критерии успеха
Было необходимо понять:
- зачем директора реально заходят в «Контроль / Историю заказов»;
- какие сценарии для них критичны;
- какие данные и действия точно нельзя потерять при миграции;
- можно ли перенести функциональность в другой продукт, если в мобайле оставить ее нельзя
Критерий успеха был простой: директор должен быстро найти заказ, понять, что с ним произошло, и продолжить разбор с поддержкой или курьером без поиска данных в нескольких системах
Гипотезы
№1
Раздел используют редко, потому что он нужен не для рутины, а для инцидентов
№2
Для директоров это не просто история заказов, а быстрый способ понять, что происходит на ЦФЗ
№3
Чтобы сценарии работали, список заказов нужно дополнить данными для разбора
Исследование
Сначала я пошла к директорам дарксторов, чтобы понять, в каких ситуациях они открывают «Контроль / Историю заказов» и что пытаются там найти
На глубинных интервью разбирала не абстрактные пожелания, а реальные рабочие кейсы: жалобы клиентов, общение с горячей линией, контроль курьеров, поиск перепутанных заказов, проверку состава, статусов и исполнителей.
Исследование: Сценарии работы с разделами «Контроль / История заказов»
Редко — не значит бесполезно
Раздел открывали в момент инцидента: когда клиент пожаловался, поддержка задала вопрос или нужно было срочно проверить спорный заказ
Раздел помогает разбирать жалобы
Директору нужно быстро понять, что произошло с заказом: кто собирал, кто доставлял, что было в составе и где мог появиться сбой
История заказов — для контроля курьеров
В разделе директора проверяли заказы, исполнителей, перепутанные боксы, негабарит и другие спорные ситуации на доставке
Простого списка заказов недостаточно
Для работы сценариев нужны детали: исполнитель, SLA, состав заказа, комментарии, особенности и быстрые действия для связи
После интервью стало понятно: раздел не был лишним экраном. Он использовался редко, но в ситуациях, где цена ошибки высокая.
Помочь сборщику с большим заказом
Когда сборщику нужна помощь,
я хочу видеть его задачу со списком товаров,
чтобы быстро подключиться и помочь собрать заказ
я хочу видеть его задачу со списком товаров,
чтобы быстро подключиться и помочь собрать заказ
Перекинуть задачу на другого исполнителя
Когда сборщик не справляется или возникает техническая проблема,
я хочу снять задачу с исполнителя,
чтобы переназначить ее и не задерживать заказ
я хочу снять задачу с исполнителя,
чтобы переназначить ее и не задерживать заказ
Связаться с клиентом по спорному заказу
Когда клиент просит связаться с ним или комментарий к заказу непонятен,
я хочу быстро найти контакты и детали заказа,
чтобы уточнить информацию и не портить клиентский опыт
я хочу быстро найти контакты и детали заказа,
чтобы уточнить информацию и не портить клиентский опыт
Отменить заказ, который нельзя выполнить
Когда я понимаю, что заказ не получится выполнить,
я хочу отменить его,
чтобы он не висел в задачах и клиент не ждал зря
я хочу отменить его,
чтобы он не висел в задачах и клиент не ждал зря
Разобраться с перепутанными боксами
Когда есть подозрение, что курьеры перепутали боксы,
я хочу видеть заказы, которые уже везут курьеры,
чтобы понять, где ошибка, и быстро исправить ситуацию
я хочу видеть заказы, которые уже везут курьеры,
чтобы понять, где ошибка, и быстро исправить ситуацию
Помочь курьеру закрыть проблемную доставку
Когда у курьера техническая проблема или он не может связаться с клиентом,
я хочу быстро найти заказ и нужные действия,
чтобы помочь завершить доставку или переназначить задачу
я хочу быстро найти заказ и нужные действия,
чтобы помочь завершить доставку или переназначить задачу
После интервью я описала рабочие ситуации в формате «Когда… я хочу… чтобы…». Это помогло увидеть, что раздел нужен не только для просмотра истории, а для конкретных действий: помочь исполнителю, разобраться с жалобой, проконтролировать курьера или закрыть проблемный заказ
Отдельно поговорила с техподдержкой, чтобы увидеть процесс жалобы с другой стороны: как к ним приходит обращение клиента, какие вопросы они задают дарксторам и какой информации обычно не хватает для быстрого ответа. Так мы рассматривали не сам раздел в отрыве от процесса, а весь путь разбора жалобы: от обращения клиента до проверки заказа на стороне дарксторов
Пример сообщения поддержки по жалобе клиента
Решение
Оставить раздел в новом мобильном приложении на тот момент не получалось. Это было техническое ограничение команды мобильного приложения.
Поэтому мы предложили компромисс: перенести функциональность в Web Dark Store, веб-приложение для директоров дарксторов, которым занималась наша команда.
Это не был перенос «один в один». После исследования стало ясно, что старого набора данных недостаточно. Мы описали флоу, собрали таблицу атрибутов и добавили то, что нужно для реальных сценариев: статусы, исполнителей, SLA, состав заказа, комментарии, особенности заказа, фильтры и быстрые действия.
Функциональные блоки раздела
Атрибутивный состав заказа
В интерфейсе:
- список заказов и групп заказов;
- поиск по номеру заказа или отправления;
- фильтры по статусам, типам доставки и превышению SLA;
- карточку заказа с полной информацией для разбора;
- быстрые действия вроде звонка и копирования информации для коммуникации с поддержкой
Контроль заказов (активные заказы на доставке)
Инфо о заказе (доставляющийся заказ)
История заказов — список завершённых и отменённых заказов
Инфо о заказе — список товаров (завершённый заказ)
Проверка решения
После проектирования провела UX-тесты с 6 респондентами: админами из разных типов ЦФЗ и хабов, из Москвы и регионов.
Проверяла, понимают ли пользователи новый раздел, могут ли сами пройти сценарии, хватает ли им атрибутов и фильтров.
По итогам тестов респонденты прошли сценарии, блокирующих проблем не возникло. Это подтвердило, что компромисс с переносом в веб работает, даже если он не идеален с точки зрения мобильного форм-фактора.
Часть сценария ux-тестирования
Результаты
Мы не дали удалить функциональность, которая казалась устаревшей, но на деле закрывала важные операционные сценарии.
Команда получила:
- доказанную ценность раздела через исследование;
- понятные сценарии использования;
- таблицу нужных атрибутов;
- спроектированный раздел в Web Dark Store;
- подтверждение на UX-тестах, что решение понятно пользователям
Главное: директора не потеряли инструмент для разбора жалоб и контроля курьеров при миграции на новое приложение
Итоги и продуктовые выводы
Исследование помогло не удалить важный для директоров ЦФЗ инструмент «по ощущениям». Мы доказали, что раздел используют редко не потому, что он бесполезен, а потому что он нужен в конкретных проблемных ситуациях: жалобы клиентов, вопросы поддержки, контроль курьеров и спорные доставки
Редкое использование ≠ низкая ценность
«Контроль / Историю заказов» открывали в момент инцидента. Здесь важна не частота заходов, а возможность быстро найти факты по заказу и принять решение
Компромисс с переносом в веб
Идеально было сохранить раздел в мобайле, но технически это было невозможно. Поэтому мы перенесли сценарии в Web Dark Store и усилили их данными, фильтрами и быстрыми действиями
В этом проекте я не просто проектировала интерфейс. Нужно было разобраться, зачем раздел вообще нужен, доказать его ценность, собрать job stories, синхронизировать стейкхолдеров и довести спорный функционал до понятного решения
Роль дизайнера
Что можно улучшать дальше
- вернуть часть сценариев в мобильный формат, если появится техническая возможность;
- смотреть аналитику по поиску, фильтрам, открытиям карточек и быстрым действиям;
- добавить кнопку «скопировать выжимку по заказу» для поддержки;
- дальше расширять карточку только на основе реальных инцидентов, а не «на всякий случай»
