Рождение гипотезы

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

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

Мы заметили, что некоторое количество пользователей, которые начинали создавать объявления о продаже квартиры или сдаче в аренду, не всегда доходили до его публикации. Чтобы разместить объявление, нужно заполнить форму с описанием квартиры и добавить фотографии. Звучит просто, но для человека, который делает это первый раз — задача сложнее чем кажется. У нас появилась  гипотеза о том, что если мы упростим путь пользователя и минимизируем риск ошибки при создании объявления, это повысит конверсию в публикацию.

Владимир Кулишин, Team Lead команды «Собственники»: Повышать конверсию можно двумя способами. Первый — реагировать на изменения рынка и своевременно добавлять для пользователя фичи, чтобы у него была высокая мотивация заполнить всю форму и опубликоваться. Второй — убирать барьеры при публикации, то есть добавлять какие-то подсказки, проверку данных. Оба способа предполагают регулярное внесение изменений в форму подачи, которые обходились бы слишком дорого: необходимо нарисовать дизайн и реализовать логику для всех платформ, на которых представлен Циан: обычный сайт, сайт для мобильных устройств, iOS и Android.

Какая проблема была в разработке, как она касалась пользователя и как мы переписали форму подачи объявления под Backend-Driven UI, Владимир Кулишин подробно рассказал на Frontend Conf. Можно послушать доклад и скачать презентацию 👀

Качественное исследование

Наши пользователи делятся на два сегмента: риелторы и собственники недвижимости. Как они подают объявления? Мы решили начать исследование с тех, кому приходится создавать объявления чаще — риелторов.

Мы собирали аналитические данные, фидбек от разработки и команды поддержки о проблемах формы подачи, проводили глубинные интервью. Во время беседы риелторы создавали объявления, а мы спрашивали, что вызывало сложности и почему, чего не хватает, что можно было бы улучшить. Пример проблемы, которая приводила к багам и обращениям: возможность на старой форме вручную ввести название и выбрать жилой комплекс, отдельно ввести адрес и метро. Мы с командой решили, что такой UX перекладывает решение задачи на пользователя и отказались от него. Теперь на новой форме жилой комплекс и метро цепляются к адресу автоматически, пользователь не может их менять, и соответственно не совершает ошибок. Выросло качество данных, связанное с локацией объявления.

Следующий этап – это анализ интервью. Важно не просто описать действия, но проследить паттерны в мышлении и поведении респондентов. А еще понять, почему они мыслят и действуют так. Мы составили список проблем, которые нашли во время тестирования. Затем каждую проблему приоритизировали по тому, насколько она блокирует выполнение главной задачи – выложить объявление. После этого исследователь и команда продукта разрабатывают варианты решения. Часто их может быть несколько на одну проблему: например, если пользователи не замечают важный элемент, его можно сделать ярче, перенести в другое место или вообще поменять пользовательский сценарий. Команда вместе ищет оптимальное решение. Далее начинается вторая итерация работы над прототипом. В первую очередь в работу берутся самые критичные проблемы – из-за таких пользователи не могут выполнить задачу и уходят или обращаются в поддержку. Но мы хотим предотвратить и то, и другое.

Часто на этапе качественного исследования можно выявить неожиданные проблемы. Например, мы заметили, что при создании объявления, люди предпочитают сначала сделать описание в каком-нибудь текстовом редакторе в отдельной вкладке браузера. Когда пользователь возвращался на вкладку с формой подачи и хотел вставить описание в нужное поле, он проводил курсор через шапку сайта, из которой "выпадало" меню и закрывало почти весь экран.

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

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

Прототипирование и количественный анализ

На основе качественных данных мы формируем прототипы нескольких вариантов решений, которые затем тестируется на пользователях. По результатам этого тестирования мы определяем, какой именно вариант мы передадим в разработку. Получив это решение, проводим A/B-тестирование, чтобы посмотреть на поведение пользователей на сайте и найти проблемные места, также провести доработку элементов интерфейса и текста, которые могут повлиять на UX.

Как разработка помогла дискавери команде собирать полезную информацию о проблемах у пользователей?

1. Использовали опыт команды в поддержке формы подачи

Team Lead Володя Кулишин делился с продуктом экспертизой из многолетней поддержки формы подачи. Ещё на этапе прототипа мы убрали ручной ввод адреса и названия ЖК в отдельных полях, т.к. пользователи часто путались и генерировали себе препятствия, например, пытались вручную поменять адрес корпуса ЖК на какой-то свой, хотя мы уже подставляли правильный адрес из нашей базы ЖК.

2. Команда разработки по своей инициативе настроила запись сессий пользователя

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

3. Выгружали из систем мониторинга ошибки публикации, влияющие на конверсию

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

4. Внедрили новые технические подходы под новый дизайн продукта 

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