Редизайн планирования маршрутов в TMS Ubirator

Рефлексия на тему редизайна сложных инструментов и того как к этому процессу мы подошли в команде.

Меня зовут Демидов Никита и я старший дизайнер интерфейсов в компании Ubirator.

С момента моего прихода в команду прошло около года и мы решили собрать некоторые кейсы редизайна наших продуктов в серию статей, которые будут содержать основные причины изменения наших продуктов (или их частей) и результаты в формате до / после.

За моими плечами 4 года продаж железа и услуг в IT, 8 лет менеджмента в IT (2 года из которых дизайн-менеджмента), 2 года проектировщиком интерфейсов и год в роли старшего дизайнера. Работа с крупными международными компаниями, студиями и небольшими стартапами. Разные роли, разное количество пользователей и разное количество денег в продуктах, но всегда одно желание — созидать и делать что то вокруг себя немного лучше. Пусть в большей степени в B2B.

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

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

В этом месте практически заканчивается "Я" и начинается "Мы".

Мы работаем с живым продуктом, а если быть точнее с целой логистической экосистемой Ubirator, состоящей из сайта, TMS (Transport Management System), личного кабинета клиента, приложения для водителей, трейдинговой платформы и еще некоторых сайд-проектов.

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

Мы хотели вносить изменения постепенно, закрывая самые проблемные места, влияющие на удобство пользования, репутацию и деньги (в т. ч. их экономию).

TMS — краеугольный камень нашей экосистемы. С ней работает большинство наших сотрудников и в этой части мы говорим про отдел логистики.

Планирование маршрута — один из основных инструментов логиста. С планирования начинается рабочий день сотрудника. От качественно спланированного маршрута зависит уровень экономии на маршруте (ГСМ, время) и уровень удовлетворенности клиента.

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

• порядковый номер;
• адрес;
• время ожидания;
• время прибытия на точку (план);
• опоздание (факт);
• объем фракций на точке;
• объем фракций в машине;
• время погрузки;
• время и расстояние между точками.

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

Логисту приходится считаться практически с каждым параметром и учитывать их как при планировании, так и при работе с ними в течении дня.

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

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

По итогу, получился список из 32 вопросов, которые затрагивали не только панель планирования, но и в целом работу с заказами и поездками (карта, карточка информации о поездке с набором данных по адресам и фракциям, которые нужно вывести, данные водителя и т. д.). Часть из них.

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

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

Мы описали задачи для работы с макетами и перешли к дизайну.

Наша модель планирования подходила под типичный Waterfall, с некоторыми логистическими особенностями. Взяв за основу диаграмму Ганта, мы выбрали наиболее интересные продукты или UI-шоты, которые пытались адаптировать под наши особенности.

Всю структуру панели поделили на пять условных блоков:

• Таймлайн и бейджи
• Диапазон времени и строки заказа
• Изменение порядка заказов
• Боковое меню и карточки заказа
• Цветовая градация

Область таймлайна позволяла понять количество заказов/ПЗП, их нумерацию в маршруте и в какое время водитель должен приехать на заказ. Расчеты времени погрузки и время до точки считал бэк, поэтому нам необходимо было учесть разные варианты отображения (чего мы как недо-дезигнеры естественно не сделали).

Нам также необходимо было показать, есть ли на заказе опоздание или ранний приезд.

• Мы не стали менять визуальный вид бейджей;
• Объединили время погрузки и время до точки в единую полосу отображающую общее время затрачиваемое на точку;
• Выделили опоздание / ранний приезд.

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

• Сделали толстые строки заказа. В отличии от предыдущего решения, чтобы было удобно навестись на строку и посмотреть данные детально;
• Отобразили подсказки при наведении на диапазон и погрузку/до точки;
• Показали ранний приезд и опоздание;
• ПЗП и заказы визуально отличаются. У ПЗП нет диапазона времени прибытия (пунктирной линии).
• Отобразили иконку, чтобы визуально разделить время погрузки и время до точки.
• Наши логисты живут на Windows, потому вынуждены пользоваться скроллом при горизонтальной прокрутке (в некоторых состояниях интерфейса). Нативный боковой скролл был настолько маленький, что в него было сложно попасть. Переделали на кастомный.
  

Поскольку дизайнеры бывает не дружат с реальностью (Dribbble привет), не учёл сразу те данные, которые могут приходить с бэка и время погрузки может быть 1-3 минуты, если на точке 10 кг сырья. Иконка погрузки не влезет. Отказались от нее, разделив подсказки.

В последней итерации объединили подсказки, т. к. из прототипа поняли, что неудобно было наводиться на подсказки, если погрузка и время до точки 1+1 мин.

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

Мы решили подсвечивать заказы с опозданиями или ранним приездом, отображая это как на таймлайне, так и в области строк.

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

В боковое меню мы пытались расположить данные о количестве сырья на точке и в машине, а также заезды на ПЗП. Первые решения получались достаточно "мутантские”. Мы пытались натянуть сову на глобус и ожидали, что будет "ок”. После увиденного, отсутствовало понимание, как с этим будут работать логисты и насколько это очевидно.

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

У нас в системе уже была нумерация и цветовая градация заказов. В рамках редизайна коллегами было предложено отказаться от цветов, оставив только монохромные цвета, но заказы перестали давать нужное визуальное разделение. Было тяжело связать бейдж на таймлайне, строку заказа на шкале времени. Мы быстро отказались от этой задумки.

Еще нужно было учесть несколько особенностей:

• Для ПЗП использовался темно-серый цвет. Тут мы не планировали ничего менять.
• Красным цветом подсвечивались опоздания и ранние приезды. Тут так же ничего не поменялось.
• Мы проанализировали данные за все время работы сервиса и не нашли более 25 заказов в одном маршруте (вероятно, невозможно физически), потому определили, что остановимся на 25 цветах заказов, которые будем рандомно отображать в панели. Нам нужно было отобразить эти цвета, как с ними сочетается красный и показать контрастность шрифтов с темными и светлыми цветами.

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

Создав в прототипе нужные нам кейсы, мы отправились проверять все гипотезы и изменения на логистах.

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

Получилось порядка 12 вопросов, контекста:

• Определите диапазон времени в четвертом заказе;
• Определите время погрузки в восьмом заказе;
• Водитель не успевает в установленный диапазон времени. Определите, в каком заказе;
• Измените порядок заказов, так, чтобы проблема с опозданием водителя решилась и т. д.

По итогу проверки мы получили качественную обратную связь от пользователей и внесли небольшие изменения в макеты.

Нам необходимо было провести дизайн-ревью, протестировать разные баги и состояния (кейсов было предостаточно) и в целом проверить, что ни UI ни UX не поломались и на тесте все работает так, как мы задумали.

В процессе тестирования мы поняли, что бейджи заказа часто располагаются друг под другом, если время заказов рядом и изначально мы не определили логику их отображения. Были мысли сделать двойные бейджи (в примере ниже заказ 2/3), но с ними было много вопросов по механике и отображению времени на шкале. При наведении стали поднимать бейджик и выводить его на первый план, сигнализируя о том, что именно этот заказ может быть изменен или перетянут на другое место.

Также для процесса на последних этапах подошел стикер из стикерпака “CTO IN A RAGE”.

Но, сгладим это так — у нас появилось "небольшое” техническое ограничение по переделке параметров поездки и наш CTO мягко указал нам на эту ошибку, сообщив, что мы излишне много "нафантазировали". Мы не стали спорить и менять время от предыдущей точки на время до следующей точки на бэке (т.к. даже побоялись оценивать сроки и импакт от таких изменений) и просто поменяли местами в дизайне погрузку и время. Хуже от этого не стало.

Нам не удалось полностью отказаться от красного цвета и его оттенков при отображении заказов, потому в реализации мы получили вот такую “красоту”. Фиксили это по мере получения обратной связи от пользователей.

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

Что мы в особенности выделили для себя:

• Информация в панели стала нагляднее;
• Информацию стало проще получить;
• С панелью проще взаимодействовать.

Мы частично закрыли потребность планирования собственными силами, но на текущий момент полностью отказаться от внешних инструментов не смогли. В этом нам помогут следующие итерации, в которые войдут "Автопланирование поездки”, “Автоподбор водителя по параметрам ТС”, а также мелкие доработки UI типа "Zoom” таймлайна, фулскрин окна планирования и др. Об этом мы еще расскажем в будущих статьях.

Протестировать не дадим, метрик не покажем, придется верить на слово.

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