Digital Logistics Platform

Обзор и контекст продукта

Digital Logistics Platform / «Цифровой экспедитор» — операционная логистическая платформа для работы с грузоперевозками. Продукт связывает клиентские заявки, логистов, перевозчиков, водителей, транспортные компании, маршруты, документы, проверки и статусы рейса.

Проект начинался в условиях высокой неопределённости. На старте не было зрелой продуктовой логики, готовой дизайн-системы или полной документации. Были базовое описание, фрагментарные материалы и несколько UX-набросков в Miro. Задача состояла в том, чтобы превратить этот контекст в понятную структуру продукта и подготовить интерфейсные материалы для разработки MVP.

Главная сложность заключалась в том, что продукт не работал как открытая marketplace-биржа, где все участники видят друг друга напрямую. Для клиентов существовал только «Цифровой экспедитор», а внутренняя операционная логика — логисты, перевозчики, водители, транспортные компании, проверки документов и распределение рейсов — оставалась внутри платформы.

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

Зона ответственности и объём работ

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

В работу входили:

• анализ домена, ключевых сущностей и связей между ними;
• проектирование ролевой модели для руководителя, логиста-менеджера и сотрудника службы безопасности;
• проектирование web-интерфейса для экспедиторской стороны;
• проектирование mobile-сценариев для водителей, ИП и транспортных компаний;
• проработка жизненного цикла заявок, рейсов, маршрутов, документов и статусов;
• проектирование проверки перевозчиков, водителей и транспортных средств службой безопасности;
• подготовка компонентов, состояний и повторяемых интерфейсных паттернов для MVP;
• handoff для разработки и сопровождение уточнений по поведению интерфейса.

Ролевая модель и права доступа

Web-интерфейс был разделён по операционным ролям.

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

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

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

Mobile-контур был сложнее обычного driver app. Он должен был поддерживать несколько сценариев: самостоятельного водителя-ИП, транспортную компанию, водителя внутри компании и руководителя транспортной компании, который управляет собственными ресурсами и может участвовать в рейсах.

Жизненный цикл заявок

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

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

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

Контекстный поиск исполнителей

Поиск исполнителя начинался из заявки. Вместо того чтобы заставлять логиста вручную собирать фильтры заново, система должна была подставлять параметры из самой заявки: направление, вес, объём, тип транспорта, температурный режим, радиус поиска и ограничения по группе риска.

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

Такой сценарий снижает риск ошибки: поиск строится не с нуля, а от условий конкретной заявки.

Проверка перевозчиков и служба безопасности

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

Сотрудник СБ работал с очередью проверок, документами, комментариями, группами риска и статусами допуска. Проверка могла относиться к организации, водителю или транспортному средству. Результат влиял на то, может ли исполнитель участвовать в рейсах и как он отображается в поиске.

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

Mobile-сценарии исполнителей

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

Пользователь мог быть самостоятельным водителем-ИП, транспортной компанией, водителем внутри компании или руководителем транспортной компании. Поэтому onboarding, проверка документов, добавление ресурсов и участие в заявках зависели от организационного контекста.

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

Маршрутный сценарий

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

Особое внимание требовалось к статусам рейса. Для логистического продукта это не декоративные метки, а рабочие события, которые помогают синхронизировать mobile-приложение исполнителя и web-панель логиста.

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

Интерфейсная система и плотность данных

Продукт требовал двух разных уровней плотности интерфейса.

В web-части нужна была высокая информационная плотность: таблицы, списки, фильтры, карточки заявок, правые панели, модальные окна и быстрые действия. Логист или руководитель должен был видеть много заявок, статусов и рисков одновременно, не проваливаясь каждый раз в отдельный экран.

Mobile-часть, наоборот, была построена как более пошаговый сценарий: одно главное действие на экран, крупные интерактивные элементы, bottom navigation, bottom sheets, статусы рейса и понятные состояния загрузки документов.

В систему вошли:

• статусы заявок, рейсов и проверок;
• risk group labels для перевозчиков и ресурсов;
• route timelines с точками маршрута;
• карточки заявок, исполнителей, организаций, водителей и транспортных средств;
• фильтры и collapsible-фильтры;
• action menus для списков и таблиц;
• компоненты загрузки и предпросмотра документов;
• empty, success, warning и error states.

Handoff и результат

Итогом работы стала MVP-ready дизайн-доставка: набор экранов, сценариев, состояний, компонентов и пояснений по поведению интерфейса. Эти материалы дали команде разработки понятную основу для сборки MVP и помогли снизить количество неоднозначностей на этапе реализации.

Результатом был не только набор макетов, а структура продукта: роли, сущности, статусы, маршруты, проверки, mobile-сценарии и интерфейсные паттерны, которые можно было использовать в разработке.

Public-safe презентация

Текущая версия кейса в портфолио оформлена как public-safe static case. В ней не раскрываются коммерческий контекст, реальные названия компаний, исходный код и конфиденциальные документы.

Публичная версия показывает продуктовую сложность, UX-логику, screen families, интерфейсные паттерны и обновлённый визуальный слой, который помогает представить кейс без раскрытия закрытых материалов.

Важно, что modern redesign здесь не является главным результатом проекта. Главный результат — реальная UX-декомпозиция сложного операционного продукта и MVP-ready handoff. Обновлённый визуальный слой нужен как публичная форма презентации этого опыта.

Что показывает этот кейс

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

Кейс важен как пример того, как из сырого продуктового контекста можно собрать UX-архитектуру, экранные семейства, mobile-сценарии и handoff, по которому команда может двигаться к MVP.