Digital Logistics Platform
Кейс о том, как из фрагментарных материалов была собрана UX-архитектура логистической платформы: роли, заявки, подбор исполнителей, проверки и выполнение рейсов в связанных web- и mobile-сценариях.
Кейс основан на реальной проектной работе. Названия компаний, коммерческий контекст и закрытые документы не раскрываются; визуальный слой публичной версии обновлён.
Операционная модель и результат
Платформа связывала клиентские заявки и внутреннюю работу экспедитора с действиями перевозчиков и водителей. Один процесс охватывал подбор исполнителя, проверку документов, назначение ресурсов, выполнение рейса и передачу закрывающих материалов.
Главный фокус кейса — перевод верхнеуровневой идеи и разрозненных UX-материалов в ролевую модель, связанные жизненные циклы и интерфейсную структуру, которую команда могла использовать при разработке MVP.
Продуктовая задача
Связать работу экспедитора, перевозчиков и водителей в общем процессе — от клиентской заявки и подбора исполнителя до рейса и закрывающих документов.
Моя роль
Product & UX Designer: анализ предметной области, ролевая модель, UX-архитектура web- и mobile-контуров, сценарии, состояния и подготовка материалов для MVP.
Системный подход
Фрагментарные исходные материалы были разложены на роли, сущности и связанные жизненные циклы заявок, рейсов, проверок и документов.
Результат
Команда получила связанную UX-архитектуру web- и mobile-сценариев, экраны, состояния, повторяемые паттерны и пояснения для разработки MVP.
Контекст и задача
Digital Logistics Platform / «Цифровой экспедитор» — операционная логистическая платформа для работы с грузоперевозками. Она связывает клиентские заявки, внутреннюю работу логистов, подбор и проверку исполнителей, выполнение рейсов и обмен документами.
На старте были базовое описание продукта, фрагментарные материалы и несколько UX-набросков в Miro. Нужно было превратить их в связанную модель ролей, сущностей, состояний и пользовательских маршрутов, по которой команда могла разрабатывать MVP.
За одной клиентской заявкой стояли логисты, перевозчики, водители, транспортные компании, проверки документов, распределение рейсов и разные уровни доступа. Эти связи определяли общую операционную модель и границы web- и mobile-интерфейсов.
В работу входили:
- анализ домена, ключевых сущностей и связей между ними;
- проектирование ролевой модели для руководителя, логиста-менеджера и сотрудника службы безопасности;
- проектирование web-интерфейса для экспедиторской стороны и mobile-сценариев для исполнителей;
- проработка жизненного цикла заявок, рейсов, маршрутов, документов и статусов;
- проектирование проверки перевозчиков, водителей и транспортных средств службой безопасности;
- подготовка состояний, повторяемых паттернов и пояснений для MVP-ready handoff.
Ролевая модель и права доступа
Web-интерфейс был разделён по операционным ролям. Одна продуктовая система открывала разные рабочие контуры в зависимости от задач и уровня доступа.
- Руководитель видел общую картину по заявкам, финансам, менеджерам, перевозчикам и проверкам. Ему были доступны управление клиентской базой, перераспределение заявок и административные действия.
- Логист-менеджер создавал и обрабатывал заявки, разделял и объединял их, подбирал исполнителей и следил за статусами рейсов.
- Сотрудник службы безопасности проверял организации, водителей, транспортные средства и документы, назначал группы риска и определял статус допуска.
Mobile-контур поддерживал самостоятельного водителя-ИП, транспортную компанию, водителя внутри компании и руководителя, который управлял ресурсами организации и при необходимости участвовал в рейсе.
Жизненный цикл заявок
Заявка была одной из центральных сущностей продукта. Она связывала клиента, маршрут, груз, требования к транспорту, документы, сроки, стоимость, исполнителя и дальнейший рейс.
Карточка заявки должна была быстро показывать ключевой операционный контекст: откуда и куда едет груз, что нужно перевезти, какие есть требования, сроки и документы, а также какое действие нужно выполнить дальше.
Отдельной сложностью был сценарий разделения и объединения заявок. В логистике одна клиентская заявка может дробиться на несколько рейсов из-за ограничений транспорта, маршрута, груза или стоимости. Для этого был спроектирован интерфейсный механизм, который помогает сохранять связь между исходной заявкой и дочерними рейсами, не теряя документы, номера и условия.
Контекстный поиск исполнителей
Поиск исполнителя начинался из заявки. Сценарий не требовал заново собирать пустой набор фильтров: параметры поиска наследовались из условий перевозки — направления, веса, объема, типа транспорта, температурного режима, радиуса поиска и ограничений по группе риска.
В результате логист получал рабочую поверхность для сравнения: организация или ИП, водитель, транспорт, рейтинг, группа риска, комментарии службы безопасности, последние направления и доступные действия.
Проверка перевозчиков и служба безопасности
Перевозчик, водитель или транспортное средство не попадали в рабочий поток без проверки. Поэтому в продукте был отдельный контур службы безопасности.
Сотрудник СБ работал с очередью проверок, документами, комментариями, группами риска и статусами допуска. Проверка могла относиться к организации, водителю или транспортному средству. Результат влиял на то, может ли исполнитель участвовать в рейсах и как он отображается в поиске.
Этот слой был важен для всей системы. Логист должен был понимать, кому можно отправить запрос, где есть риск, какие документы уже проверены и какие ограничения нужно учитывать.
Mobile-сценарий рейса
Mobile-приложение проектировалось как инструмент участия в рейсе: от допуска и назначения ресурсов до маршрутных статусов, проблем в пути и загрузки документов. Доступные действия зависели от того, работает пользователь самостоятельно или представляет транспортную компанию.
После допуска исполнитель мог открыть доступные заявки, откликнуться, назначить водителя и транспорт, начать рейс, отмечать прохождение маршрута, сообщать о проблемах и завершать выполнение.
Особое внимание требовалось к статусам рейса. Для логистического продукта это не декоративные метки, а рабочие события, которые помогают синхронизировать mobile-приложение исполнителя и web-панель логиста.
Загрузка закрывающих документов также была важной частью сценария. Интерфейс должен был поддерживать фото документов через камеру смартфона, состояния отправки, ошибки и подтверждения.
Интерфейсная система и плотность данных
Продукт требовал двух разных уровней плотности интерфейса, но должен был оставаться одной системой сценариев, статусов и сущностей.
В web-части нужна была высокая информационная плотность: таблицы, списки, фильтры, карточки заявок, правые панели, модальные окна и быстрые действия. Логист или руководитель должен был видеть много заявок, статусов и рисков одновременно, не проваливаясь каждый раз в отдельный экран.
Mobile-часть была построена как более пошаговый сценарий: одно главное действие на экран, крупные интерактивные элементы, нижняя навигация, bottom sheets, статусы рейса и понятные состояния загрузки документов.
Повторяемые элементы собирались вокруг нескольких операционных паттернов:
- статусы заявок, рейсов и проверок;
- группы риска для перевозчиков и ресурсов;
- маршрутные timelines с точками маршрута;
- карточки заявок, исполнителей, организаций, водителей и транспортных средств;
- фильтры, быстрые действия и рабочие панели;
- компоненты загрузки и предпросмотра документов;
- empty, success, warning и error states.
Результат
Команда получила связанную модель продукта и материалы для разработки MVP: ролевые web-интерфейсы, mobile-сценарии исполнителей, жизненные циклы заявок и рейсов, проверки перевозчиков, состояния документов и повторяемые интерфейсные паттерны.