Самокат (входит в ГК Ecom.tech) — сервис быстрой доставки еды.
Я работаю продуктовым дизайнером коммерческих продуктов для бизнеса — это внутренние продукты для сотрудников компании. Один из моих продуктов — Промотрон, с помощью него сотрудники компании рассчитывают и выставляют скидки, которые потом увидят покупатели в приложении.
Один из самых старых внутренних продуктов компании, когда я пришла, он работал уже 1,5 года. Продукт сложный, и с технической точки зрения — это высоконагруженный сервис, содержащий огромное количество данных и это количество увеличивается каждый день, и с точки зрения пользовательского опыта.
Чтобы понять работу сервиса, пришлось полностью погрузиться в рабочий процесс наших пользователей и разобраться во всех нюансах и действиях, которые выполняют пользователи до, во время и после работы в нашем продукте.
Моя роль
Я единственный дизайнер этого продукта. Вся работа строится по Double Diamond.
Мои обязанности:
Исследования: пользовательские интервью, юзабилити-тесты, опросы
Проектирование пользовательских сценариев, UJM, US
Постоянное взаимодействие со стейкхолдерами и пользователями, выявление проблем и точек роста продукта
Постоянное общение с продуктовой командой, брейнштормы, обсуждение технических ограничений и развитие продукта с их учётом, поддержка и доработка решений во время разработки, контроль фичей перед релизом (фронтчек)
Разработка дизайн-макетов в соответствии с дизайн-системой (изначально была ДС Ant, сейчас провожу перевод на внутреннюю ДС)
Кейс 1. Изменение фильтров
Одной из первых моих задач было привести в порядок фильтры огромной таблицы — каждый столбец был со своим фильтром и применять их можно было только по очереди.
Из-за этого пользователям приходилось очень долго ждать работы каждого фильтра. и на бэк тоже была сильная нагрузка: таблица перестраивалась после каждого применения фильтра через новый запрос.
Цель: ускорить работу пользователей и уменьшить нагрузку на бэк
Фильтров в продукте было более 40, чтобы понять, как они должны выглядеть и работать, я провела 11 интервью с пользователями. Мне важно было пообщаться с сотрудниками разных товарных категорий и их руководителями (тоже пользователями продукта), потому что у разных товарых категорий разные сценарии работы (например, сотрудники, занимающиеся скидками на бытовую химию, загружают скидки 1-2 раза в неделю, а сотрудники категории свежих овощей — несколько раз в день).
У меня была гипотеза, что есть фильтры, которые используются чаще всеми сотрудниками, и есть фильтры, которые вообще не используются и возможно будет от них отказаться.
Оказалось, что все 40+ фильтров так или иначе используются и все нужны
Чаще всего пользователи применяют одновременно 4-7 фильтров, прежде, чем выполнить задачу
Разные группы пользователей чаще используют разные группы фильтров, и даже одни и те же пользователи используют разные группы фильтров для разных задач. Самых «популярных» фильтров оказалось не мало — 13
В итоге я вынесла все фильтры в раскрывающуся боковую панель. Фильтры разместила в порядке популярности у пользователей.
На юзтесте пользователи хорошо справлялись с заданиями с новыми фильтрами.
Через месяц после релиза я провела послезапусковые исследования. Сначала я запустила опрос, который прошли 50% всех пользователей. Это был не анонимный опрос с формами свободного ответа — мне нужно было понять, какие есть проблемы и у кого именно, чтобы потом пойти на интервью к конкретным пользователям, которым не удобно.
В целом пользователи хорошо отзывались о работе с новыми фильтрами, однако даже с помощью этого небольшого опроса стало понятно, что есть две небольшие проблемы. Во-первых, многим было не удобно открывать боковую панель, чтобы посмотреть применённые фильтры. Во-вторых, хотя фильтры и были размещены по популярности, некоторым пользователям было бы удобнее видеть в начале другие фильтры.
Я не стала проводить глубинки, сразу сделала новый прототип и пошла на новые юзтесты — как к пользователям, которые испытывали эти проблемы, так и к тем, кому всё было удобно.
для решения первой проблемы я сделала теги с выбранными фильтрами над таблицей, которые видно всё время, а по наведению показываются значения этих фильтров.
А для более удобного расположения фильтров проверила 2 гипотезы — фильтры по алфавиту и ручную настройку расположения фильтров (ненужные фильтры можно скрыть, а оставшиеся перетащить в нужном порядке; некоторые коллеги меня не поддержали: идея таскать фильтры драгндропом казалась им странной и чужеродной)
Фильтры, расположенные по алфавиту, у всех пользователей вызвали неудобства. а вот с ручной настройкой порядка и видимости все респонденты справились даже не читая подсказок и оценили её, как очень удобную и понятную. Некоторые даже пытались сразу настроить фильтры под себя, забывая, что работают на прототипе.
Чтобы сделать прототип с живым драг-н-дропом, пришлось сверстать страницу в коде, так как нормально протестить драг-н-дроп в Фигме нереально
Юзтесты доработок фильтров
Кейс 2. Работа с сетью городов
Пользователи загружают промоакции либо на конкретные города, либо сразу на сеть городов. Если загрузка идёт на сеть, то одна строка в шаблоне экселя в продукте превращается в 40-60 строк — в зависимости от количества городов в сети.
После загрузки акций пользователи совершают с ними разные операции — редактируют, останавливают, меняют статусы, и чем с большим количеством строк нужно делать эти операции, тем сложнее работать. Поэтому пользователи просили сделать возможность сворачивать разбитую на города сеть в одну строку.
Цель: ускорить работу пользователей, сократить количество пользовательских ошибок
Исследования и интервью с пользователями
Первый вариант решения получился очень быстро. Мы продумали его с бизнес-аналитиком, показали пользователям и понесли к разработке.
Просто в интерфейс добавляется дополнительный переключатель, регулирующий разбиение или не разбиение промоакций по городам сети
Но при обсуждении с разработкой оказалось, что сделать так, как я придумала, технически невозможно. и никакие незначительные изменения этой концепции не подходили — для их реализации пришлось бы переделывать весь продукт. Поэтому пришлось идти и придумывать всё с самого начала.
Так как показывать «свёрнутую» сеть возможности нет, то нужно было понять, как решить проблему пользователей по-другому. Развёрнутая сеть создаёт много строк, которые сложно редактировать — значит, нужно упростить массовое редактирование. Акции, которые были в одной сети, сложно найти — значит, нужно сделать механизм поиска таких акций.
В итоге задача с переключателем превратилась в задачу доработки массовых действий и более удобного поиска.
Кейс 3. Калькулятор товарооборота
Необходимо было создать инструмент прогноза товарооборота в зависимости от запущенных промоакций. До его появления сотрудники считали примерный товарооборот по формулам в Экселе, основываясь на довольно старой аналитике и собственном опыте. Эти прогнозы имели невысокую точность, к тому же требовали большого количества ручной работы. Поэтому нужен был инструмент, который будет автоматически использовать актуальные аналитические данные, точные прогнозные модели и при этом будет быстрый и простой в использовании.
Цель: точно и реалистично прогнозировать эффект промоакций, сократить ручной труд и ускорить работу сотрудников
Дискавери по задаче
В процессе исследований выяснили, что способ расчёта прогнозных значений отличается у каждого конкретного пользователя, а ещё, что разным пользователям важны разные расчётные параметры. и даже терминологию они используют разную, имея ввиду одно и то же (разные виды маржи, например, была жуткая путаница). Поэтому очень много времени до разработки макетов мы с бизнес-аналитиком потратили на выяснение, какие же именно параметры мы должны рассчитать, чтобы удовлетворить потребности всех наших пользователей.
В итоге получился такой калькулятор. От пользователя требует только загрузить эксель шаблон с минимальным набором данных, после этого калькулятор рассчитывает все необходимые параметры.
После расчёта пользователь может изменить некоторые исходные данные прямо в интерфейсе, без дополнительных загрузок. Также пользователь можно добавить комментарии, чтобы сравнивать расчётные параметры для одного товара при разных скидках.
В строке много разных параметров и подсказок, но ничего лишнего
На макетах показаны вымышленные данные, не являющиеся коммерческой тайной