Платформа сервисного обслуживания грузового транспорта
Mobile app (iOS/Android) + Web
| Клиент NDA | Таймлайн Январь 2024- Октябрь 2024 |
| Инструменты Figma, FigJam, Jira, Confluence | Моя роль Product Designer |
О проекте:
Международный заказчик из логистики пришёл с задачей: собрать Uber-like платформу для ремонта грузовиков. В отрасли одни и те же боли:
- водители не могут быстро найти механика в дороге, простаивают;
- частные механики и сервисы страдают от «дырявого» потока заказов;
- диспетчеры тонут в звонках, Excel и ручном учёте заявок и денег.
Нужно было объединить всех в одной системе: водителя, механика, сервис и диспетчера — и сделать процесс от заявки до оплаты прозрачным и предсказуемым.
Через мобильное приложение водитель оформляет заявку на ремонт/эвакуатор/шиномонтаж, механик принимает заказ и фиксирует работу, автопарк контролирует заявки и расходы.
Моя роль:
Как Product Designer я отвечал за мобильные части платформы:
- Исследование домена: интервью с представителями автопарков, механиков и водителей, разбор текущих процессов.
- Проектирование user flow и интерфейсов мобильных приложений для водителей и механиков.
- Создание и поддержка дизайн-системы для мобильных и веб-клиентов.
- Подготовка интерактивных прототипов, проведение юзабилити-сессий.
- Описание сценариев, состояний и краевых кейсов в спецификациях для разработки.
- Совместная работа с backend / mobile / web-командой над API и состояниями.
Процесс:
- CJM и IA, согласовали с продуктом и техлидами;
- низкоуровневые прототипы → UX-валидация на стороне заказчика;
- финальный UI, состояния ошибок, крайние кейсы;
- спецификации для разработчиков (описание статусов, событий, переходов);
- участие в ревью, проверка соответствия флоу и UI.
Команда:
Продакт, проджект менеджер, системный аналитик, frontend разработчик , backend разработчик.
Проблема:
В грузоперевозках типичная картина:
- Водитель встаёт на трассе с поломкой → обзванивает знакомых / диспетчера → потерянные часы.
- Частный механик или сервис не видит стабильного потока заказов, много «пустых» смен.
- Диспетчер ведёт всё в Excel и мессенджерах, сложно контролировать статус заявок и деньги.
Решение:
Собрали единую платформу вокруг мобильных приложений:
- App для водителя: быстрый мастер создания заявки, загрузка фото/аудио, трекинг статуса в реальном времени.
- App для механика: лента релевантных заказов, создание предложения (цена/сроки), фиксация этапов работ с фото и чеками.
- Web/мобильный кабинет автопарка: управление заявками, распределение задач, история и финансы.
- Платёжный флоу: интеграция со Stripe, заморозка средств, оплата только после подтверждения работы.
Аналитика
Интервью с представителями автопарков, механиков и водителей; фиксация сценариев и болей.
Гипотезы
H1.
Если дать механику экран «Request» с активными заказами и лентой новых заявок, то он быстрее ориентируется в дне и чаще выходит «в сеть» через приложение.
H2.
Если в карточке заявки показать достаточно информации (тип проблемы, фото, данные ТС, расстояние, примерное время в пути), то доля взятых в работу заявок вырастет, а время на принятие решения сократится.
H3.
Если упростить создание предложения до экрана «цена + ETA + комментарий» и добавить подсказки средних цен, то механики будут чаще отправлять офферы и меньше бояться «промахнуться» по стоимости.
H4.
Если сделать удобный блок фиксации результата (чек-лист, фото, материалы) + прозрачный статус выплат, то уменьшится количество спорных ситуаций и вопросов по оплате.
JTBD
| Роль | Ситуация | Мотивация (я хочу…) | Результат (чтобы…) |
|---|---|---|---|
| Водитель грузовика | Машина ломается в дороге | Быстро найти подходящего механика рядом и описать проблему в пару шагов | Сократить простой, быстрее вернуться в рейс и не обзванивать «всех подряд» |
| Водитель грузовика | Готовлюсь к долгому рейсу / ТО | Заранее записаться в сервис и увидеть подтверждённое время и стоимость | Спланировать маршрут и бюджет, избежать сюрпризов по времени и деньгам |
| Механик / сервис | У меня есть свободные часы в графике | Видеть релевантные заявки поблизости с понятным описанием проблемы и оплатой | Заполнить календарь работой и не тратить время на неподходящие или «пустые» заявки |
| Механик / сервис | Я беру заявку в работу | Получить всю нужную инфу (фото, данные ТС, контакт) в одном экране | Принять решение за минуты и приехать подготовленным |
| Диспетчер автопарка | В рейсе десятки машин, поступают новые заявки | В реальном времени видеть статусы заявок и загруженность механиков | Быстро распределять работы и снижать простой транспорта |
| Диспетчер автопарка | Водитель звонит с проблемой | Оформить заявку за него прямо из кабинета и назначить исполнителя | Не терять заявки в мессенджерах и контролировать выполнение |
| Владелец / менеджер парка | Смотрю итоги работы за месяц | Видеть дешборд по простоям, расходам на ремонт, рейтингу сервисов | Принимать решения о партнёрах, бюджете и обновлении автопарка |
| Финансовый менеджер | Нужно сверить оплаты по ремонтам | Иметь прозрачный журнал платежей и актов по каждой заявке | Быстро проходить сверку и уменьшить спорные ситуации по оплате |
CJM опыт Механика
| Этап | Цель | Действия | Боли / риски | Возможности продукта |
|---|---|---|---|---|
| Старт смены | Понимать план на день | Открывает app, смотрит экран «Сегодня» | Хаос или пусто, непонятная загрузка | Дашборд: активные заказы + лента новых заявок |
| Просмотр ленты заявок | Быстро найти подходящие заказы | Скроллит ленту, фильтрует по типу работ, расстоянию | Много нерелевантных заявок, нет приоритета | Фильтры, сортировка по расстоянию/цене/типу |
| Оценка заявки | Решить, брать или нет | Открывает карточку: детали поломки, фото, ТС, локация | Мало информации, неясный объём/сложность | Полный набор полей + карта, примерное время в пути |
| Отправка предложения | Сформировать понятный оффер | Вводит цену, ETA, комментарий, отправляет | Страх промахнуться с ценой/сроком | Подсказки средних цен, сохранённые шаблоны предложений |
| Выезд и выполнение работ | Организовать выезд и ремонт | Строит маршрут, отмечает статусы «в пути/на месте/в работе» | Путается в адресах, нет связи с водителем | Кнопка «Маршрут», встроенный чат/звонок |
| Фиксация результата | Зафиксировать объём работ и материалы | Добавляет фото, отмечает чек-лист, вносит материалы, закрывает заказ | Теряются чеки, нет доказательств при споре | Структурированная форма, медиа-прикрепления, авто-отчёт |
| Получение оплаты и отзыва | Получить деньги и повысить рейтинг | Ждёт подтверждения, видит зачисление, читает отзыв | Задержки выплат, непонятные статусы | Прозрачный статус выплат, история, влияние рейтинга на выдачу |
UX-флоу и структура
Собрали карту экранов и потоков:
- Водитель: регистрация по номеру → выбор услуги → данные о ТС → описание проблемы (текст/фото/аудио) → ожидание предложений → выбор механика → трекинг → подтверждение и оценка.
- Механик: регистрация → настройка профиля и зоны работы → лента заявок → отправка предложений → чек-лист этапов ремонта → фиксация материалов и завершение.
Особое внимание — минимум шагов на мобиле и чёткая обратная связь: прогресс-бар мастера, статусы «ищем механика», «механик в пути», «ремонт идёт», «ожидаем подтверждение».
Дизайн система
Базировался на мобильных гайдлайнах iOS/Android: понятные таб-бары, крупные CTA, работа с картой и листами снизу.
- Собрал дизайн-систему:
- цветовые токены (состояния: «требует внимания», «в работе», «завершено»);
- типографика, сетка, отступы;
- компоненты: карточки заявок, мастера шагов, блоки с картой, статусы, формы, модалки.
- Для веб-части использовал похожий подход, чтобы водитель/механик не «терялись» между платформами.
Проектирование и прототипирование
В Figma собрал интерактивные прототипы обоих приложений (iOS/Android, но с общей логикой).
Прогнал сценарии с 5–7 респондентами (водители и механики из базы клиента:
- убрали лишние поля на раннем шаге;
- разделили формы по типам услуг, чтобы не перегружать экраны;
- упростили текст ошибок и подсказок.
Ключевые UX / UI-решения
Опыт Механика
Экран «Request» — точка входа в смену
Проблема:
Механик открывает приложение и не понимает, что у него на сегодня: пустота или хаос.
Решение:
- экран «Request»
- активные заказы (то, что уже взято в работу);
- лента свежих заявок рядом
Это снимает ощущение хаоса и даёт точку фокуса.
Создание предложения (оффера)
Проблема:
Механики боятся «не угадать» цену или сроки → не отправляют оффер.
Решение:
Экран с тремя полями:
- цена работы
- ожидаемое время прибытия (ETA);
- комментарий
Плюс:
- подсказка средней цены по таким заявкам в регионе
Это снижает ментальный порог и ускоряет отправку оффера.
Экран активного заказа: статусы и навигация
Проблема:
Путаются в адресах, непонятно, как «правильно» отмечать статусы, связь с водителем — через отдельные мессенджеры.
Решение:
- линейный статус-бар:
«Принят» → «В пути» → «На месте» → «В работе» → «Ожидает подтверждения» → «Оплачено»;
- кнопка «Построить маршрут» (открывает навигацию);
- встроенный чат и звонок, чтобы не выпадать из контекста;
- большие, пальце-дружественные CTA на смену статуса.
Фиксация результата и отчётность
Проблема:
Чеки теряются, споры решаются «на словах».
Решение:
Экран закрытия заказа:
- чек-лист задач (что было сделано)
- блок фото «до/после»
- итоговая стоимость, которая уходит водителю/автопарку на подтверждение.
Система автоматически формирует отчёт, который можно использовать как аргумент при споре.
Результаты
Среднее время от появления заявки до принятия механиком сократилось (по данным пилота) примерно на 30–40 %.
Доля заявок, закрытых с фото и заполненным чек-листом, выросла до 70–80 %.
Механики стали чаще использовать приложение как основную точку входа, а не только телефон/мессенджеры.
Уменьшилось количество спорных ситуаций по оплате и объёму работ — за счёт прозрачной фиксации и статусов.