Кабинет грузовладельца
b2b · web
NPS 60+
MVP
Спроектировала B2B-продукта внутри существующей логистической экосистемы — от концепции до внедрения
Контекст и проблема
01
Проблема
Владельцы грузов не были интегрированы
в экосистему продуктов. Это ограничивало:
в экосистему продуктов. Это ограничивало:
- рост платформы
- взаимодействие между участниками
- автоматизацию процесса перевозок
Продукт
Компания развивает экосистему для маркетплейса грузоперевозок. В системе уже были:
- кабинет перевозчика
- кабинет покупателя топлива
Задача
02
Основные метрики влияния:
- время создания заявки
- NPS / удовлетворённость пользователей
Запустить кабинет владельца груза и встроить его в экосистему, чтобы сократить ручные операции и увеличить количество исполняемых заявок.
Мой вклад
03
Ключевые действия
- Определила информационную архитектура продукта
- Спроектировала ключевые сценарии и навигацию
- Проработала систему статусов, сделав процессы прозрачными
- Разработала интерфейсы на основе дизайн-системы
- Расширила дизайн-систему новыми компонентами
Основной вызов
Найти баланс между быстрым запуском MVP и удобством продукта, встроив его в существующую экосистему
Исследо-
вания
вания
Исследования
04
Анализ конкурентов
Потребности сегменов различаются: малому и среднему бизнесу важны простой сервис и надёжные перевозчики, крупному — управление и прозрачность.
В малом и среднем бизнесе заявку часто ведёт не логист, а владелец или партнёр.
Всё это задало требование к продукту:
простота для пользователей без узкой экспертизы и поддержка сложных сценариев крупных клиентов.
простота для пользователей без узкой экспертизы и поддержка сложных сценариев крупных клиентов.
Изучила существующие материалы, аналоги и внутреннюю ERP-систему, чтобы понять текущую логику работы с заявками.
Выделила два сегмента:
- крупные компании с выстроенной логистикой
- малый и средний бизнес без настроенных процессов
Решение
05
Спроектировала навигацию и статусы
Ввела статусы и разделила заявки на вкладки:
- активные (размещена, оформляется, исполняется)
- завершённые (отменена, выполнена)
Такое деление убирало часть данных в основном сценарии, что снижало когнитивную нагрузку.
Сфокусировалась на MVP
Со стейкхолдерами определили сценарии для MVP:
- создание заявки
- мониторинг статуса
- отмена заявки
Блок-схема процесса
Упростила создание заявки
В существующей ERP часть полей была необязательной — я убрала их из сценария создания.
Также разбила создание заявки на шаги: груз › маршрут › оплата › проверка. Это упростило восприятие.
Учла технические ограничения
Нельзя было валидировать каждый шаг на сервере, поэтому использовали клиентскую валидацию на каждом шаге и серверную — на финальном.
Компромисс позволил сохранить качество опыта, не изменив техническую архитектуру.
Расширила дизайн-систему
Разработала компонент temperature range для задания температуры перевозки. Он снижал риск ошибок при заполнении.
Это важно для бизнеса: не каждый дальнобойщик знает, при какой температуре везти арбузы, а ответственность за груз остаётся на компании.
Позже компонент переиспользовался в других продуктах.
Экран активных заявок
Что бы сделала иначе
- Провела бы юзабилити-тестирование до разработки, чтобы раньше выявить UX-риски
- Зафиксировала бы продуктовые метрики до старта, чтобы точнее оценивать решения
Итог
Запустили MVP — 200+ клиентов в первый месяц. Достигли NPS 60+, что выше целевого значения
После запуска я инициировала юзабилити-тестирование, выяснила, что:
- пользователи успешно проходят основной сценарий и понимают статусы заявок
- есть точка роста — проблемы при вводе адресов
Результаты
06
Запустили новый B2B-продукт внутри
экосистемы — 200+ клиентов за месяц
экосистемы — 200+ клиентов за месяц
Определила структуру продукта
и ключевые сценарии работы с заявками
и ключевые сценарии работы с заявками
Сделала процессы перевозки прозрачнее
через систему статусов
через систему статусов
Расширила дизайн-систему компонентом,
влияющим на бизнес-риски
влияющим на бизнес-риски
Другие кейсы
