Справочник клиента: СберЛогистика
Контекст: в компании есть внутренний сервис, который используется для B2B-клиентов фуллфилмента (сервис по обработке заказов). Тарифы привязаны к клиентам с помощью иерархии: Клиент → Договор → Тарифная сетка
Ранее не было единого интерфейса для управления этими сущностями.
Пользователям приходилось делать несколько запросов бэкэнд разработке, чтобы отредактировать одно поле – это замедляло рабочий процесс и часто приводило к ошибкам из-за несогласованности действий.
Ранее не было единого интерфейса для управления этими сущностями.
Пользователям приходилось делать несколько запросов бэкэнд разработке, чтобы отредактировать одно поле – это замедляло рабочий процесс и часто приводило к ошибкам из-за несогласованности действий.
01. Исследование
Чтобы разобрать процесс AS IS и найти проблемные точки, я провел глубинные интервью с менеджерами, которые выполняют задачи по управлению клиентскими договорами. В процессе исследования были собраны артефакты
в виде юзер сторей и JTBD, были разобраны все технические и бизнесовые корнер кейсы
в виде юзер сторей и JTBD, были разобраны все технические и бизнесовые корнер кейсы
02. Гипотезы
Исходя из исследования , я сформулировал проблемные и решенческие гипотезы.
Я предположил, что пользователям сложно управлять тарифами из-за отсутствия единого интерфейса и зависимости от команды бэкенд разработки. Предоставление пользователям возможности добавлять данные о клиентах, договорах и тарифных сетках, и управление ими в одном месте — с четкой иерархией и ограничениями — уменьшит количество ошибок и сделает
их полностью автономными.
Я предположил, что пользователям сложно управлять тарифами из-за отсутствия единого интерфейса и зависимости от команды бэкенд разработки. Предоставление пользователям возможности добавлять данные о клиентах, договорах и тарифных сетках, и управление ими в одном месте — с четкой иерархией и ограничениями — уменьшит количество ошибок и сделает
их полностью автономными.
03. Функциональная карта продукта
Основываясь на всех выводах и идеях, собранных на этапе исследования, я определил их в функциональную архитектуру, создав структурированную карту объектов
04. Task flow
После согласования функциональной архитектуры с продуктовой командой я расписал все юз кейсы в формате Task Flow To Be, чтобы проверить качество взаимосвязи сценариев
05. Дизайн и UX тесты
Ключевые действия в интерфейсе включали в себя создание клиентов, привязку договоров, назначение тарифных сеток и управление статусом компании,
что обеспечивало согласованную и безошибочную работу
Для проверки удобства использования я проводил модерируемые UX-тесты
с пользователями
что обеспечивало согласованную и безошибочную работу
Для проверки удобства использования я проводил модерируемые UX-тесты
с пользователями
06. Финальный дизайн
Основываясь на результатах UX-тестов, я доработал интерфейс, подготовил окончательные макеты, описал логику взаимодействия и передал все в разработку
07. Результат
С помощью нового раздела пользователи могут вносить изменения в договоры клиентов за пару кликов вместо нескольких этапов коммуникации
с дорогостоящими разработчиками = понижена стоимость выполнения задачи
с дорогостоящими разработчиками = понижена стоимость выполнения задачи
