Рабочий процесс
Знакомство с бизнесом
Исследование аудитории
Изучение предметной области
Составление CJM
Формирование HMW's
Выявление сущностей продукта
Составление Sitemap
Составление BPMN
Определение требований к страницам
Создание мудборда
Поиск референсов
Разработка концептов
Разработка интерфейса
Cоздание компонентов дизайн-системы
Отработка технических нужд и краевых ситуаций
Создание адаптивов
LogistIQ — 3PL-провайдер. Является посредником между производителем и его партнёрами. Выстраивает всю логистическую цепь предприятия.
Помогает производителям доставлять автозапчасти, электронные компоненты и инструменты (оптом и в розницу) в магазины, автосервисы и частным лицам.
Контекст
У компании есть продукт — основной сервис доставки, но менеджеры вынуждены управлять большими объёмами данных вручную:
нет единого интерфейса, где менеджер может увидеть информацию по заказам: статусы нужно проверять вручную и невозможно быстро понять, какие заказы выполняются с задержками;
нет возможности удобно отслеживать движение водителей в режиме реального времени (только через звонки и сторонние ПО);
при возникновении проблем информацию приходится искать по разным системам, чтобы выяснить, что случилось;
отчёты собираются вручную из разных источников → аналитика медленная, проблемы выявляются постфактум.
Проблема
1.
Менеджеры погрязли в ручном хаосе и теряют 70‑80% времени на рутину (от 6 до 10 часов в день), при этом страдает качество выполнения основных обязанностей;
2.
Клиенты не задерживаются, переходя к конкурентам.
Задача
Разработать специализированное ПО для менеджеров по логистике сервиса.
Метрика успеха
Сокращение времени менеджера на рутинные процессы на 50% (с 6–10 часов до 3–5 часов в день);
Повышение cNPS (Candidate Net Promoter Score) с +10 до +40 — как индикатора привлекательности компании на рынке труда.
Боли
Потери клиентов, конфликты с поставщиками.
Эмоции
Стресс из-за высокой нагрузки, выгорание от рутины.
Трудности
Коммуникация с водителями, сложности в поиске и обработке информации.
Самостоятельные решения трудностей
Создают чаты в WhatsApp / Telegram для коммуникации с водителями;
Ведут Excel-таблицы с собственными кодами статусов для поиска информации;
Создают файлы Word с шаблонами часто используемых документов;
Используют заметки в телефоне и цветные стикеры для фиксации информации по заказам.
Я составила два вида CJM: для старого процесса — как менеджеры работали до появления централизованного сервиса и для текущего продукта — чтобы увидеть моменты, которые могут потенциально блокировать пользователей и подобрать подходящие решения.
Старый процесс
Отследила, на каких этапах работы у менеджеров возникают трудности и определила их мысли и эмоции в моменте.


Текущий процесс
Для составления использовала сценарии взаимодействия пользователя с системой.
Благодаря CJM удалось отследить блокеры, возникающие у пользователей в процессе прохождения сценариев и подобрать к ним решения — драйверы.
В процессе выявила несколько решений для удовлетворения потребностей бизнеса на соответствующих этапах.

На основании карт CJM составила HMW's для генерации решений и творческих идей.
Разделила их на три приоритета, взяв первый и второй для реализации на MVP-1.

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

Разработала карту страниц и разделов сервиса для наглядного отображения информации, которая должна в нём находиться и логики перехода между разделами.
Sitemap так же показал, как информация будет иерархически вложена и сгруппирована.

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

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

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

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

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

Сначала я отрисовала первичные сценарии, указанные на BPMN-схеме, затем вторичные — ответвления от основного пути.

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

Благодаря технике «А что, если…» я отыскивала краевые ситуации, которые могут возникать у пользователей при взаимодействии с системой и отрисовывала под них интерфейс.
Также я учла технические нужды разработчиков и предусмотрела все возможные состояния элементов, которые могут быть отображены.

Продумала логику поведения интерфейсов на разных экранах — десктопах 1920×1080, десктопах 1440×1024, планшетах 1024×1366 и мобильных устройствах 375×812 для всех страниц.

Заключение
Если бы у меня была возможность собрать метрики по реализованному проекту, я бы ориентировалась в первую очередь на данные показатели для определения успешности продукта:
Сокращение времени менеджера на рутинные процессы на 50% (с 6–10 часов до 3–5 часов в день);
Повышение cNPS (Candidate Net Promoter Score) с +10 до +40 — как индикатора привлекательности компании на рынке труда.
Второстепенные метрики, которые не критичны на старте, но важны для оценки роста и улучшения продукта в будущем:
Снижение оттока клиентов на 40%;
Увеличение NPS (уровня удовлетворённости клиентов) с 20 до 60;
Сокращение скорости обнаружения водителей на карте и понимания маршрута на 80% (с 5–10 минут до 1 минуты);
Ускорение реакции на задержки на 60% (10–15 минут вместо 30);
Ускорение решения проблем на 50% (с 10–30 минут на поиск информации до 5–15 минут);
Уменьшение времени на формирование отчётов на 70% (с 1‑3 часов до 10–30 минут);
Выводы
До работы над данным проектом я предполагала, что есть определённый свод методик, которые всегда нужно использовать для успешной реализации продукта. Но в процессе я поняла, что в первую очередь следует отталкиваться от задач самого проекта и подбирать точечно именно те подходы, которые помогут их решить (или генерировать на их основе свои).
Ещё одним важным инсайтом для меня стало понимание, что невозможно реализовать весь задуманный функционал, каким бы прекрасным и полезным для пользователей он ни был, потому что помимо временных ограничений существуют ограничения бизнеса и технические со стороны разработки. Главная цель для MVP-1 — сделать рабочий продукт, который будет решать поставленную задачу удобно для его пользователей. А «причёсывать» и доводить до идеала можно уже на дальнейших версиях продукта.













