WCP

релиз —
апрель 2024

b2b-продукт

проектирование —
2023-2024

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

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

Проблемы и бизнес-задача

WCP — это личный кабинет поставщика, интегрированный с другими системами склада. Он разрабатан для крупнейшей 3PL (Third Party Logistics — доставка, хранение, комплектация заказов, управление запасами, доставка потребителям) компании в России

личный кабинет поставщика

WCP —

>80

экранов

пользователей

>200

заказов обрабатывает в день

>100.000

— Команда и моя роль

Моя роль:

Погружение в записи проведенных экскурсий по складу, изучение подготовленных аналитиком user story и документации. А также изучение системы с которой WCP должна интегрироваться
Создание и согласование информационной архитектуры на основании собранных данных
Создание и согласование визуальной концепции
Сборка и развитие UI-кита, передача его в разработку
Создание макетов
Доработка продукта по обратной связи от бизнеса, а также по обновляющимся техническим требованиям

Менеджеры

Frontend

UX/UI дизайнер

Backend

Бизнес-аналитик

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

Закрытые тестирования
Это b2b-система для клиентов нашего заказчика. В силу внутренннй политики компании-заказчика, прямого доступа к конечным пользователям не предоставили. Однако, заказчик сам проводил закрытые пользовательские тестирования

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

— Процесс работы

Идеи

Выдвижение гипотез
Сборка прототипов

Тестирование

Согласование макетов с аналитиком и менеджером
Закрытое тестирование с пользователями

Разработка

Бриф и передача макетов разработчикам
Дизайн-ревью

... новые циклы тестирования после релиза

Доработка макетов

Погружение

Изучение документации и др. артефактов
Бриф от аналитика
Уточнение техограничений у менеджера и разработки

— Функционал: претензии

Проблемы

— Непрозрачность процесса расследования
Процесс расследования проходит через личные переписки. К собранным данным нет прямого доступа у всех участвующих сторон

— Разные типы претензий
Претензии могут быть как на всю заявку, так и на конкретную «линию» (из них состоит заявка). Т.е. претензию можно не только принять / отклонить, но и частично принять / отклонить

Задачи

— Централизованное управление претензиями
Необходимо создать раздел для управления претензиями для клиента. А также раздел для администратора с заведением новых типов претензий

— Коммуникация участников расследования
Необходим быстрый и централизованный способ общения и сбора нужных данных для участников расследования

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

Каждая претензия требует расследования, вынесения решения по ней и оповещения участников процесса

Решение

В карточке претензии добавлен чат. В нем любой участник может оставить комментарий или ответить на чужой

Результат

Есть централизованное место с историей принятия решений и собранными материалами в одном месте.
Можно запросить нужные документы сразу в чате

Решение

Функционал выборочного принятия решения по каждой линии в заявке, а также массовое подтверждение всей линии (что подтвердит всю заявку сразу)

Результат

Возможно оперативно принять решение по конкретной линии, если есть все нужные данные, а не ждать пока пройдет расследование по всей заявке

— Функционал: заявки на приемку

Проблемы

— Разные флоу для одной задачи
Ручная загрузка и массовая загрузка предполагают разный процесс взаимодействия с заявкой, хоть и выполняют одну и туже задачу

— Когнитивная нагрузка
Состав заявки нагружен множеством данных, часть из которых редактируется, часть нет. Также линии могут включать в себя другие сущности. Все это нужно отобразить на одном экране, без потери информативности (не скрывать большое количество данных), но при этом сохранить доступность восприятия

Задачи

— Массовая загрузка
Поставщик может загружать сразу большое количество артикулов в одной заявке (наиболее часто используемый use case) или вносить вручную небольшое количество артикулов

— Линии заявки
Необходимо отображать все данные из состава заявки, т.е. все линии и все сущности (SSCC), входящие с состав линии

Перед поставкой грузов поставщики отправляют заявки на приемку. Далее заявки обрабатывает склад (принимает или отклоняет).

При этом на определенном этапе поставщик может вносить изменения в заявку

Решение

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

Результат

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

Решение

Загрузка заявки разбита на два сценария — массовая загрузка и ручная

Результат

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

— Пример других разделов системы

Всего 80+ экранов