Цифровая трансформация «Леруа Мерлен»: проектирование интерфейса для работы с обращениями покупателей

Коротко

AGIMA спроектировала для «Леруа Мерлен» систему обработки обращений покупателей вместо разрозненных бумажных и цифровых процессов. Команда описала 11 рабочих сценариев, собрала прототипы и проверяла их недельными спринтами. Главный вывод проекта: интервью с конечными пользователями нужно проводить до детальной проработки интерфейса.

Кейс описывает проект 2019 года. Масштаб сети, правила возврата, используемые инструменты и состояние внедрения приведены в историческом контексте.

Контекст и задача

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

Цель проекта

На момент публикации торговая сеть сообщала более чем о 100 гипермаркетах в 60 городах России и штате свыше 35 тысяч сотрудников.

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

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

Сотрудники магазина понимали локальный процесс, но головной офис не видел полной картины по сети. Команда решила создать систему, которая автоматизирует обработку обращений покупателей. Цель проекта — создать пошаговый интерфейс для работы с обращениями в магазинах «Леруа Мерлен». Письменные обращения из книги записей нужно перенести в глобальную систему, обработка должна быть автоматизирована. Нужно было спроектировать интерфейс системы и разработать дизайн.

Сценарии и требования

Данные из брифа и дополнительные вводные перевели в пользовательские истории и бизнес-требования.

Выделили 11 коротких базовых сценариев, которые взяли за основу работы. Каждый сценарий включал от трёх до девяти шагов.

11 базовых сценариев

• Регистрация нового обращения.
• Ответ по обращению.
• Просмотр обращения с перепиской.
• Поиск обращения.
• Передать обращение в CLAIM.
• Печать, экспорт обращения.
• Создание нового клиента в рамках регистрации обращения.
• Создание новой задачи в рамках просмотра обращения.
• Переназначить обращение.
• Просмотр и выполнение задач.
• Выполнение задачи по печати решения по обращению.

Прототипирование

Проект делали в Adobe XD. Начали с концептуального прототипа — это та стадия, когда мы прикидываем основные интерфейсные элементы и навигацию. Сделали несколько ключевых экранов и обсудили их с бизнес-заказчиками перед тем, как начинать более детальную работу.

Критерии качества

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

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

Правила интерфейса

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

Сквозные сценарии вместо отдельных экранов

Мы сконцентрировались не на отдельных страницах, а на связанных цепочках экранов.

Преимущества сценарного подхода:

• Проверка качества работы. Можно поставить себя на место сотрудника, который будет пользоваться системой. Это удобный способ не забыть о важных моментах.
• Обсуждения прототипов с бизнес-заказчиками, привлечение сотрудников различных подразделений к обсуждению.

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

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

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

Представители бизнес-заказчика транслировали требования конечных пользователей, которые считали важными. И все же, несмотря на все попытки быть объективными, их мнение всё равно отражало собственные ожидания от системы.

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

Визуальный дизайн

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

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

Проектировщик не создаёт продукт в одиночку: изменения коллег помогают согласовать интерфейс с бизнесом и техническими ограничениями.

Результат внедрения

Обновленные интерфейсы были внедрены в одном из магазинов заказчика. По результатам тестирования команда сочла базовые задачи решёнными: сотрудники справлялись с основными сценариями без длительного обучения.

Тестирование также выявило дополнительные бизнес-процессы, которым требовалась автоматизация.

Впервые опубликовано: 6 декабря 2019 года.