case study
Приложение для проведения инвентаризации торгового зала
Роли: Продуктовый дизайнер, UX-исследователь
Особенности: разработка с нуля, устаревшие мобильные телефоны, отсутствие прямой коммуникации с разработчиками
Введение
Во время ежегодных инвентаризаций сотрудники магазинов Леруа Мерлен подсчитывают имеющиеся в наличии товары в торговом зале и на складах и сравнивают остатки с данными в системе.
Чтобы упростить этот процесс, мы разработали мобильное веб-приложение для корпоративных телефонов. Сотрудники торгового зала и склада используют приложение для ввода данных о количестве товаров и сравнивают их со значениями, хранящимися в базе данных. Так они сразу могут увидеть расхождения с предполагаемым количеством товара и сразу продолжить искать недостачу, либо скорректировать значение в системе.
Результаты инвентаризации проверялись руководителями магазинов. Если общая недостача в рублях была значительной, товарные позиции отправляли на повторный пересчёт. Незначительные расхождения обычно принимались как есть.
Чтобы упростить этот процесс, мы разработали мобильное веб-приложение для корпоративных телефонов. Сотрудники торгового зала и склада используют приложение для ввода данных о количестве товаров и сравнивают их со значениями, хранящимися в базе данных. Так они сразу могут увидеть расхождения с предполагаемым количеством товара и сразу продолжить искать недостачу, либо скорректировать значение в системе.
Результаты инвентаризации проверялись руководителями магазинов. Если общая недостача в рублях была значительной, товарные позиции отправляли на повторный пересчёт. Незначительные расхождения обычно принимались как есть.
Руководители магазинов в основном работали в бэкофисе магазина и пользовались настольными компьютерами. Мы создали для них десктопное веб-приложение для обработки результатов инвентаризации.
Благодаря этому приложению мы сэкономили около 25% рабочего времени, необходимого для ежегодной инвентаризации, и около 30 000 долларов в год как за счет трудозатрат, так и за счет предотвращённых потерь.
Я занималась всей работой по продуктовому дизайну приложения. Вместе с менеджером по продукту мы формализовали все нюансы процесса, которые я затем представила в интерфейсе и протестировала с пользователями в магазинах. Для этого я также выходила на инвентаризацию в ночную смену — и это был интересный опыт.
Благодаря этому приложению мы сэкономили около 25% рабочего времени, необходимого для ежегодной инвентаризации, и около 30 000 долларов в год как за счет трудозатрат, так и за счет предотвращённых потерь.
Я занималась всей работой по продуктовому дизайну приложения. Вместе с менеджером по продукту мы формализовали все нюансы процесса, которые я затем представила в интерфейсе и протестировала с пользователями в магазинах. Для этого я также выходила на инвентаризацию в ночную смену — и это был интересный опыт.
Начало работы
Изначально планировалось интегрировать функционал в Android-приложение для работы с запасами товара в торговом зале и на складах магазинов. Тем не менее, для того, чтобы успеть закончить разработку до проведения ближайшей инвентаризации, мы приняли решение выпустить MVP в виде веб-приложения отдельно, без интеграции.
Для реализации функционала мы прошли две итерации, где первая была черновой, а вторая — корректировочной после более глубокого изучения процесса и переделки некоторых гипотез о представлении данных.
Для реализации функционала мы прошли две итерации, где первая была черновой, а вторая — корректировочной после более глубокого изучения процесса и переделки некоторых гипотез о представлении данных.
Некоторые из начальных экранов
При исследовании было обнаружено несколько проблем:
Учитывая все это, было решено построить первую версию в виде отдельного, автономного веб-приложения, в котором будет только та информация, которая нужна пользователю.
- Сложность запасов. Складские запасы в Leroy Merlin были сложными, с большим разнообразием зон и позиций. Во время инвентаризации сотрудники торгового зала пересчитывали только часть зон, а другие подсчитывались отдельно разными людьми. Инструкции о том, что считать в одном случае и что не считать в другом, были запутанными, а отображение всех запасов было необязательным для повседневной работы, но важным для ежегодной инвентаризации.
- Организация баз данных. При разработке дополнения для инвентаризации мы столкнулись с тем, что для инвентаризации и для повседневной работы существовало две базы данных, организованных по-разному. Перенос данных, установка временных ограничений и включение/отключение функциональности создавали дополнительные трудности. Поэтому мы приняли решение на первом этапе работать с уже существующей базой данных для инвентаризации, а не объединять её с базой данных для повседневной работы.
- Процессы вокруг дизайн-системы. Планировалось внедрить новую систему, и после обсуждения с её лидом было решено, что проект инвентаризации можно использовать в качестве пилотного для новой системы проектирования. Это позволит разработать новые компоненты и облегчить длальнейший процесс перехода.
- Устаревшие устройства. Всем сотрудникам предоставляются рабочие устройства, которые подключаются к внутренним сервисам, но, к сожалению, это устаревшие телефоны, замедляющие рабочие процессы. Это приводит к разочарованию сотрудников и снижает производительность. Чтобы улучшить ситуацию, нужно было найти способы оптимизировать обработку данных и уменьшить нагрузку на обработку на стороне устройств.
Учитывая все это, было решено построить первую версию в виде отдельного, автономного веб-приложения, в котором будет только та информация, которая нужна пользователю.
User flow приложения для инвентаризации.
Впоследствии мы разработали новый набор макетов, одновременно получая новую информацию о специфике предстоящей инвентаризации: временные ограничения для каждого этапа подсчётов, требования к хранению данных.
Сначала мы планировали сохранить отображение структуры запасов, поскольку в определённых сценариях оно могло дать пользователю дополнительную информацию. Однако потом стало понятно, что требуется разное представление данных для инвентаризации и для ежедневной работы. Интегрированная структура данных излишне усложняла их представление. В результате мы решили сократить её, поскольку сохранение структуры для эпизодических случаев использования было не так важно, а упрощение значительно улучшило экраны и user flows.
Сначала мы планировали сохранить отображение структуры запасов, поскольку в определённых сценариях оно могло дать пользователю дополнительную информацию. Однако потом стало понятно, что требуется разное представление данных для инвентаризации и для ежедневной работы. Интегрированная структура данных излишне усложняла их представление. В результате мы решили сократить её, поскольку сохранение структуры для эпизодических случаев использования было не так важно, а упрощение значительно улучшило экраны и user flows.
Финализация макетов
В итоге мы доработали приложение и адаптировали новую версию представления данных, после чего провели краткое пользовательское тестирование с помощью прототипа и подправили отдельные элементы: карточки товаров, адреса подсчёта.
Я подготовила описание состояний для отдельных элементов и добавила подробные комментарии к сценариям, после чего передала проект разработчикам.
Состояния элементов и отдельных экранов
Десктоп-приложение
Мобильное приложение предназначалось для сотрудников торгового зала, которые непосредственно подсчитывали товар. Десктопная версия была сделана для руководителей магазинов, которые должны были просматривать и утверждать первоначальные подсчёты и при необходимости запрашивать повторные.
Сначала мы сформулировали пользовательские сценарии для десктопной версии.
Сначала мы сформулировали пользовательские сценарии для десктопной версии.
Сценарии десктопного приложения
В мобильном приложении мы сосредоточились на разработке user flow, а не сценариев, так как в нем был более сложный флоу, но всего три сценария, которые было довольно легко держать в голове. Однако в десктопном приложении ситуация была обратной: сценариев было много, но каждый из них имел простой флоу, например «при нажатии на кнопку строка перемещается на другую вкладку». Поэтому не было необходимости рисовать сами флоу.
Затем я начала проектировать отдельные экраны для десктопного приложения.
Затем я начала проектировать отдельные экраны для десктопного приложения.
Результаты
Мы смогли завершить выпустить проиложение в установленные сроки, но, к сожалению, не смогли провести дополнительное пользовательское тестирование.
Благодаря мобильному приложению нам удалось сократить количество дальнейший исправлений в период после инвентаризации на 7 %, что очень важно, учитывая, что Леруа Мерлен — крупная сеть гипермаркетов с большим количеством сотрудников и товаров для продажи.
Кроме того, настольное приложение для руководителей позволило им инициировать пересчёт товаров, по которым были крупные расхождения, на ранней стадии, что повысило точность подсчётов, но точных данных у нас нет.
По приблизительным подсчётам, мы сэкономили около 25% рабочего времени сотрудников, уходившего на проведение инвентаризации, что в совокупности с повышением точности подсчётов могло сэкономить Леруа Мерлен около тридцати тысяч долларов в год.
Благодаря мобильному приложению нам удалось сократить количество дальнейший исправлений в период после инвентаризации на 7 %, что очень важно, учитывая, что Леруа Мерлен — крупная сеть гипермаркетов с большим количеством сотрудников и товаров для продажи.
Кроме того, настольное приложение для руководителей позволило им инициировать пересчёт товаров, по которым были крупные расхождения, на ранней стадии, что повысило точность подсчётов, но точных данных у нас нет.
По приблизительным подсчётам, мы сэкономили около 25% рабочего времени сотрудников, уходившего на проведение инвентаризации, что в совокупности с повышением точности подсчётов могло сэкономить Леруа Мерлен около тридцати тысяч долларов в год.
