Кабинет продавца в маркетплейсе
Спроектировал кабинет для предпринимателей, которые доставляют товары в удалённые населённые пункты. В интерфейсе можно работать с заказами, поддерживать ассортимент и назначать условия доставки для разных сёл ----
Спроектировал веб-систему для отдела, который управляет коммерческими объектами, арендаторами и размещением организаций. Продукт объединил рабочие данные в одном месте, заменил подготовку вариантов на бумажных планах интерактивным сценарием и автоматизировал формирование отчётов.
Спроектировал веб-систему для отдела, который управляет коммерческими объектами, арендаторами и размещением организаций. Продукт объединил рабочие данные в одном месте, заменил подготовку вариантов на бумажных планах интерактивным сценарием и автоматизировал формирование отчётов.
Проект в нескольких фактах
Роль и моя зона ответственности: Продуктовый дизайнер. Участвовал во встречах с заказчиком и задавал вопросы, разбирал сценарии, изучал аналоги, проектировал интерфейс. Подготовил интерактивный прототип для тестирования, адаптировал кабинет для работы с мобильных устройств, проводил дизайн-ревью
Команда: Проектный менеджер, команда разработки, продуктовый дизайнер
Контекст и исходная ситуация
В части удалённых населённых пунктов Амурской области нет продуктовых магазинов, а доступный ассортимент ограничен. По информации заказчика, жители договариваются о покупках со знакомыми, родственниками и местными предпринимателями. Доставка зависит от того, кто и когда сможет приехать.
Предприниматели принимают заказы по телефону и через личные знакомства. Они собирают заказы для населённого пункта и затем отправляются в поездку. Между заказом и получением товаров могут проходить дни, поэтому привычная модель быстрой доставки здесь не подходит.
Заказчик планировал организовать площадку, на которой житель выбирает свой населённый пункт, доступного предпринимателя и товары из его каталога. Каждый продавец самостоятельно обслуживает заказы и организует доставку. Параллельно прорабатывались пункты выдачи и помощь с оформлением заказов для жителей, которым сложно пользоваться сайтом самостоятельно.
В проект входили покупательская часть и кабинет продавца. В этом кейсе разбираю кабинет: как предпринимателю поддерживать ассортимент, обрабатывать заказы и готовить доставку в несколько населённых пунктов.
Предприниматели принимают заказы по телефону и через личные знакомства. Они собирают заказы для населённого пункта и затем отправляются в поездку. Между заказом и получением товаров могут проходить дни, поэтому привычная модель быстрой доставки здесь не подходит.
Заказчик планировал организовать площадку, на которой житель выбирает свой населённый пункт, доступного предпринимателя и товары из его каталога. Каждый продавец самостоятельно обслуживает заказы и организует доставку. Параллельно прорабатывались пункты выдачи и помощь с оформлением заказов для жителей, которым сложно пользоваться сайтом самостоятельно.
В проект входили покупательская часть и кабинет продавца. В этом кейсе разбираю кабинет: как предпринимателю поддерживать ассортимент, обрабатывать заказы и готовить доставку в несколько населённых пунктов.
Бизнес-проблемы
1. Ограниченный доступ жителей к товарам. Ассортимент и возможность покупки зависят от личных договорённостей и доступности человека, который привезёт заказ. Родственникам из других городов тоже сложно организовать покупку для близких.
2. Зависимость продаж от телефонной коммуникации. Чтобы принять заказ и договориться о доставке, продавцу нужно лично взаимодействовать с покупателем. При обслуживании нескольких населённых пунктов приходится учитывать договорённости по разным заказам и поездкам и держать их либо в голове, либо на бумаге.
3. Ограниченный выход предпринимателей к покупателям. По словам заказчика, часть предпринимателей работает в районе, но не имеет налаженного контакта с жителями удалённых населённых пунктов. Площадка должна была сделать доступных продавцов и их ассортимент видимыми для этих покупателей.
Цель, критерии успеха и ограничения
Цель проекта: Создать площадку для заказа товаров у местных предпринимателей. В кабинете продавца — поддержать основные операции с ассортиментом, заказами и доставкой, чтобы подготовка поездок меньше зависела от отдельных телефонных договорённостей.
Как поймём, что решение работает
Основная работа переносится в цифровой продукт
Сотрудникам не нужно использовать бумажные материалы и разрозненные файлы как основной рабочий инструмент.
Подготовка заказов к поездке становится проще
Можно выделить заказы нужного населённого пункта, посмотреть состав и подготовить выгрузку для дальнейшей работы.
Условия доставки становятся понятнее-
Повторяющиеся операции, которые можно выполнить средствами системы, не требуют постоянного ручного переноса и подготовки данных.
Взаимодействие с недвижимость становится более прозрачным и эффективным
Состояние объектов можно посмотреть в цифровом виде без отдельной подготовки и запроса информации
Ограничения
Сроки: Проектирование и разработка шли в сжатые сроки и частично параллельно. Пока разработчики верстали готовые страницы, я проектировал следующие.
Разработка: Небольшая команда. Объём первой версии и сложные сценарии нужно было обсуждать с разработчиками до детальной отрисовки.
Доступ к пользователям: На старте опирались на встречи с заказчиком и сведения, которые он получил от предпринимателей. Прямых интервью с продавцами и пользовательских тестов на этом этапе не проводили
Разработка: Небольшая команда. Объём первой версии и сложные сценарии нужно было обсуждать с разработчиками до детальной отрисовки.
Доступ к пользователям: На старте опирались на встречи с заказчиком и сведения, которые он получил от предпринимателей. Прямых интервью с продавцами и пользовательских тестов на этом этапе не проводили
Дискавери
Участвовал в первых встречах с заказчиком и задавал вопросы о текущей работе и планируемой модели сервиса. За исходным запросом на сервис нужно было понять, кто принимает заказы, как организует поездки и каким образом покупатель получает товары в планируемой модели и совместно доработать ее исходя их ограничений и потребностей пользователей. ТУТ ОТМЕТИТЬ ЧТО КОМАНДА С КОТОРОЙ МЫ ОБСУЖДАЛИ НА ПЕРВЫХ ВСТРЕЧАХ ЯВЛЯЕТСЯ АГРЕГАТОРОМ БУКВАЛЬНО НЕГАТИВНЫХ ШТУК ПО ЭТОМУ ВОПРОСУ, ЭТО ОТДЕЛ У КОТОРЫХ ЭТО ТО ЧЕМ ОНИ ЗАНИМАЮТСЯ В ТОМ ЧИСЛЕ
Что разбирал?
Как жители сейчас покупают продукты. Как продавцы получают заказы и договариваются о доставке. За какие территории будут отвечать предприниматели. Как покупатель выбирает продавца. Какие варианты получения предполагаются и кто помогает жителям оформлять заказы.
После встреч разложил работу покупателя и продавца на основные этапы и сценарии. Для продавца — вход, наполнение каталога, обработка заказов, организация доставки и контроль магазина.
Под конкретные сценарии изучал аналоги: «Своё родное», Яндекс Маркет и сервисы доставки еды. Смотрел, как устроены отдельные каталоги продавцов, управление товарами и работа с заказами. Сопоставлял эти решения с нашей моделью, в которой доставка зависит от поездки предпринимателя.
После встреч разложил работу покупателя и продавца на основные этапы и сценарии. Для продавца — вход, наполнение каталога, обработка заказов, организация доставки и контроль магазина.
Под конкретные сценарии изучал аналоги: «Своё родное», Яндекс Маркет и сервисы доставки еды. Смотрел, как устроены отдельные каталоги продавцов, управление товарами и работа с заказами. Сопоставлял эти решения с нашей моделью, в которой доставка зависит от поездки предпринимателя.
Что получил на выходе?
Предварительную рабочую модель, список основных сценариев, ограничения и набор референсов для проектирования. На этой основе можно было обсуждать структуру кабинета с командой.
Сведения о повседневной работе продавцов были получены через заказчика. Поэтому карта сценариев включала предположения, которые ещё нужно проверить непосредственно с предпринимателями.
Сведения о повседневной работе продавцов были получены через заказчика. Поэтому карта сценариев включала предположения, которые ещё нужно проверить непосредственно с предпринимателями.
Что стало понятно после Discovery
Пользовательские боли
1. Много времени на отчеты. В отчётный период нужно было собрать данные из разных источников, сверить их, подготовить документы и презентации.
2. Сложная актуализация. Сотрудники не всегда понимали, какие данные свежие, что уже изменилось, а что нужно перепроверить
3. Долга ручная подготовка размещений. Для будущего арендатора нужно было вручную собирать варианты размещения. Сотрудники распечатывали план помещения и вручную зарисовывали возможные варианты размещения в здании. Таких вариантов подготавливалось от 2 до 5-6 на одного арендатора
4. Разрозненность данных. Файлы, бумаги, таблицы, планы помещений находились в разных источниках, а иногда и вообще в знаниях отдельных сотрудников
Инсайты по рабочему процессу
Также отдельно хочется выделить конкретные вещи, связанные с существующим процессом, которые повлияют в дальнейшем на дизайн-решения
Процесс размещения состоит из двух разных состояний
До согласования сотрудник работает с несколькими потенциальными вариантами, и только один из них позже становится фактическим.
Основной рабочий контекст — объект
Большая часть информации связана между собой через конкретный объект: помещения, арендаторы, занятость и площади.
Значительная часть отчётности — повторная сборка уже существующих данных
Сотрудники не создают новую информацию, а повторно сводят и визуализируют то, что уже есть в других источниках.
Правила не всегда работают как жёсткие ограничения
Например, норматив площади важен для контроля, но в отдельных ситуациях сотрудник может сознательно допустить отклонение.
Что система должна была учитывать
- Поддерживать несколько предварительных вариантов размещения будущих арендаторов;
2. Отделять подготовку варианта от изменения фактических данных в системе и базе данных;
3. Связывать информацию вокруг объекта: арендаторы, помещения, нормативы и тд;
4. Использовать существующие данные из базы при подготовке отчётности;
5. Предупреждать об отклонениях, не блокируя допустимые исключения.
Первая итерация дизайна
На старте я разделил работу с размещением на несколько сущностей: планирование, черновики, бронирование и заявки. Такое разделение повторяло терминологию заказчика и помогало технически развести разные состояния интерактивной карты.
Решение покрывало требования, но пользовательский путь получился длинным. Чтобы утвердить один вариант, сотруднику приходилось последовательно переходить между несколькими разделами и частично повторять уже введённые данные.
Решение покрывало требования, но пользовательский путь получился длинным. Чтобы утвердить один вариант, сотруднику приходилось последовательно переходить между несколькими разделами и частично повторять уже введённые данные.
Схема первой версии
Формально этапы отличались, но для пользователя являлись одной задачей — подготовить вариант размещения и зафиксировать его после согласования.
Тестирование первой версии
Я собрал интерактивный прототип и передал его сотрудникам отдела для самостоятельного прохождения основных сценариев. После этого мы провели встречу, разобрали возникшие вопросы и понаблюдали, как заместитель руководителя выполняет задачи в прототипе. Дополнительно я проверил структуру на коллегах внутри команды.
Всего решение прошло два раунда проверки: первоначальной и переработанной версии.
Всего решение прошло два раунда проверки: первоначальной и переработанной версии.
ВИДЕО С ИНТЕРАКТИВНЫМ ПРОТОТИПОМ
ПРУФЫ ТЕСТОВ, ДС ВОПРОСЫ И СКРИПТ ТЕСТОВ
Что обнаружил
Пользователи путали разделы
Не понимали, где заканчивается планирование и начинается бронирование.
Путь требовал лишних переходов
Для одной задачи нужно было проходить через черновики, бронирование и заявки.
Действия были разбросаны
Отчёты, выгрузки и действия с объектами находились в разных частях системы.
Структуру приходилось объяснять
Даже после погружения пользователи сомневались, в каком разделе нужно продолжить сценарий.
Главный вывод
Проблему нельзя было решить подписями и дополнительными инструкциями. Нужно было убрать само разделение, которое заставляло пользователей задумываться о внутренней структуре системы.
Внесение изменений
После первого этапа UX тестов была переработана структура разделов, упростил некоторые сценарии и уменьшил количество действий в рамках одного экрана. Пользователь больше не переносит данные из черновика в бронирование и заявку. Он готовит варианты, согласовывает один из них и утверждает уже заполненный черновик.
Результат второго раунда
На повторной проверке сотрудники перестали путать разделы и сразу понимали, как подготовить и утвердить вариант. После обсуждения переработанная структура была согласована для разработки.
Финальная версия — три ключевых решения
Решение 1. Объект как единый рабочий контекст
В карточке объекта собрал общую информацию, показатели площадей, арендаторов, свободные помещения и интерактивный поэтажный план.
Решение 2. Подготовка нескольких вариантов размещения
Сотрудник выбирает объект, организацию и помещения непосредственно на интерактивном плане. Система рассчитывает площадь на одного сотрудника и предупреждает об отклонении от норматива.
Один запрос может содержать несколько вариантов. Каждый сохраняется отдельным черновиком с комментарием, после чего его можно распечатать и передать на согласование.
Один запрос может содержать несколько вариантов. Каждый сохраняется отдельным черновиком с комментарием, после чего его можно распечатать и передать на согласование.
Решение 3. Автоматизированная отчётность
В системе можно сформировать Excel-отчёт по объекту, арендатору или периоду, а также подготовить PowerPoint-презентацию с планом конкретного объекта и легендой размещённых организаций.
Шаблоны соответствуют существующей форме отчётности, поэтому сотрудникам не нужно заново переносить планы и раскрашивать помещения вручную.
Шаблоны соответствуют существующей форме отчётности, поэтому сотрудникам не нужно заново переносить планы и раскрашивать помещения вручную.
Все стадии оформления заявки
Сценарий одобрения распланированных помещений
Страница с общим списком заявок, которые были заполнены. Черновик можно одобрить (что внесет изменения в БД), либо удалить. Также из модального окна с подробной информацией о Черновике можно распечатать карту и подробную информацию с размещением организации для предоставления этой информации заказчику (арендатору)
Сценарий выгрузки таблиц и презентаций
Модальное окно с донастройкой таблицы для выгрузки. Таблицы формируются по четкому ранее согласованному шаблону, а дополнительные поля позволяют донастроить таблицу и презентацию под необходимый формат и период
Адаптация кабинета под мобилку
Норматив предупреждает, но не блокирует
Сотрудник видит отклонение площади на человека, но может продолжить размещение.
Занятое помещение может участвовать в будущем варианте размещения
Организация иногда готовит размещение заранее, зная, что текущий арендатор скоро освободит помещение.
Историю изменений не включили в MVP версию проекта
История действий могла быть полезна, но сценарий признали редким для небольшой команды пользователей. В рамках доступных сроков приоритет получили ежедневные операции с объектами, размещением и отчётами.
Компромиссы. Система учитывает, что реальный процесс не всегда укладывается в жёсткие правила
Норматив предупреждает, но не блокирует
Сотрудник видит отклонение площади на человека, но может продолжить размещение.
Занятое помещение может участвовать в будущем варианте размещения
Организация иногда готовит размещение заранее, зная, что текущий арендатор скоро освободит помещение.
Историю изменений не включили в MVP версию проекта
История действий могла быть полезна, но сценарий признали редким для небольшой команды пользователей. В рамках доступных сроков приоритет получили ежедневные операции с объектами, размещением и отчётами.
Дизайн-система и подготовка к разработке
Отдельно для ускорения процесса разработки личного кабинета была сделана небольшая дизайн-система с вариантами, токенами и документацией для разработчика.
Помимо этого, на каждом из ключевых этапов я проводил дизайн-ревью, после которого вносил комментарии по доработке в разработаном куске продукта
Помимо этого, на каждом из ключевых этапов я проводил дизайн-ревью, после которого вносил комментарии по доработке в разработаном куске продукта
Фактический результат
Продукт полностью разработан и передан заказчику. Сейчас сотрудники наполняют систему реальными объектами, арендаторами и планами через рабочий интерфейс.
Я проверил работающую реализацию: данные создаются и редактируются, интерактивные карты работают, а основные сценарии соответствуют согласованным макетам.
Я проверил работающую реализацию: данные создаются и редактируются, интерактивные карты работают, а основные сценарии соответствуют согласованным макетам.
Ожидаемый эффект
После полноценного наполнения система должна сократить объём ручной сверки данных, упростить подготовку вариантов размещения и исключить ручное раскрашивание планов при формировании отчётности.
Почему нет метрик?
Проект выполнялся как заказная разработка и после передачи не сопровождался нашей командой. На момент завершения кейса продукт ещё наполнялся данными, поэтому фактические показатели после запуска пока недоступны.
На что бы смотрел, если бы продолжал работу над проектом?
1. Реальная экономия времени и ручной работы. Сколько времени теперь занимают регулярные задачи и насколько сократилось количество ручных операций, сверок и работы во внешних файлах.
2. Удовлетворённость пользователей. Насколько сотрудникам стало удобнее работать после перехода на систему: что действительно упростилось, что продолжает мешать и хотели бы они что-то изменить после регулярного использования.
3. Качество и актуальность данных. Стало ли меньше расхождений и ошибок в информации, насколько проще поддерживать данные актуальными и приходится ли сотрудникам по-прежнему перепроверять их в других источниках.
