Промотрон [Самокат]

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

Моя роль

Я — единственный дизайнер продукта. В продукте веду полный цикл дизайна, от исследований до реализации.

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

Что делаю:

Провожу исследования: пользовательские интервью, юзабилити-тесты, опросы
Проектирую пользовательские сценарии, UJM, пользовательские истории
Постоянно взаимодействую со стейкхолдерами и пользователями: выявляю проблемы и точки роста продукта
Общаюсь с продуктовой командой, обсуждаю технические ограничения, участвую в брейнштормах, поддерживаю решения во время разработки, контролирую фичи перед релизом
Разрабатываю дизайн-макеты в соответствии с дизайн-системой (изначально Ant, сейчас — внутренняя), делаю интерактивные прототипы

Кейс 1. Изменение фильтров

Проблема

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

Цель: ускорить работу пользователей и уменьшить нагрузку на бэк

Процесс

Я провела 11 интервью с пользователями. Мне важно было пообщаться с сотрудниками разных товарных категорий, чтобы учесть все сценарии работы: например, сотрудники, занимающиеся скидками на бытовую химию, загружают скидки 1-2 раза в неделю, а сотрудники категории свежих овощей — несколько раз в день.

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

Оказалось, что все 40+ фильтров так или иначе используются и все нужны
Чаще всего пользователи применяют одновременно 4-7 фильтров, прежде, чем выполнить задачу
Разные группы пользователей чаще используют разные группы фильтров, и даже одни и те же пользователи используют разные группы фильтров для разных задач. Самых «популярных» фильтров оказалось 13

Результат

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

На юзтесте пользователи хорошо справлялись с заданиями с новыми фильтрами.

Послезапусковые исследования и доработки

Через месяц после релиза я провела исследования. Сначала запустила опрос, который прошли 50% всех пользователей. Это был не анонимный опрос с формами свободного ответа — мне нужно было понять, какие есть проблемы и у кого именно, чтобы потом пойти на интервью к конкретным пользователям, которым не удобно.

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

Во-первых, многим было не удобно открывать боковую панель, чтобы посмотреть применённые фильтры. Во-вторых, хотя фильтры и были размещены по популярности, некоторым пользователям было бы удобнее видеть в начале другие фильтры.

Я не стала проводить глубинки, сразу сделала новый прототип и пошла на новые юзтесты — как к пользователям, которые испытывали эти проблемы, так и к тем, кому всё было удобно.

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

А для более удобного расположения фильтров проверила 2 гипотезы — фильтры по алфавиту и ручную настройку расположения фильтров (ненужные фильтры можно скрыть, а оставшиеся перетащить в нужном порядке)

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

Чтобы сделать прототип с живым драг-н-дропом, пришлось сверстать страницу в коде, так как нормально протестить драг-н-дроп в Фигме нереально

Юзтесты доработок фильтров

Кейс 2. Работа с сетью городов

Проблема

Пользователи загружают промоакции либо на конкретные города, либо сразу на сеть городов. Если загрузка идёт на сеть, то одна строка из шаблона в продукте превращается в 40-60 строк в зависимости от количества городов в сети.

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

Цель: ускорить работу пользователей, сократить количество пользовательских ошибок

Процесс

Исследования и интервью с пользователями

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

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

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

Результат

Так как показывать «свёрнутую» сеть возможности нет, то нужно было понять, как решить проблему пользователей по-другому. Развёрнутая сеть создаёт много строк, которые сложно редактировать — поэтому упростили массовое редактирование, добавили кнопки быстрого перевода по статусам (самое популярное действие).

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

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

Кейс 3. Калькулятор товарооборота

Проблема

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

Цель: точно и реалистично прогнозировать эффект промоакций, сократить ручной труд и ускорить работу сотрудников

Процесс

Дискавери по задаче

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

Результат

В калькуляторе от пользователя требует только загрузить эксель шаблон с минимальным набором данных, после этого калькулятор рассчитывает все необходимые параметры.

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

В строке много разных параметров и подсказок, но ничего лишнего

На макетах показаны вымышленные данные, не являющиеся коммерческой тайной