Вывел основную гипотезу
1.3
Если мы сделаем карту стартовым экраном приложения,
то это приведёт к росту MAU и ASL,
потому что многие пользователи интуитивно начинают с географии, и карта даёт им сразу понятный ориентир — где находятся квартиры и что рядом. Это особенно актуально в крупных городах, где район важнее метража или цены.
Раскрыл второстепенные гипотезы
1.3
1
Если мы увеличим количество карточек объявлений на экране за счёт размещения двух элементов в строку,
то это улучшит первое взаимодействие пользователя с интерфейсом и повысит конверсию в углублённый просмотр (CTR карточек),
потому что пользователи вначале принимают решение на уровне визуального “нравится / не нравится”, и больше карточек в поле зрения ускоряют фильтрацию и создают ощущение контроля над выбором.
2
Если встроить в экран карты контент со сравнением районов,
то вырастет удержание в приложении и вовлечение в него новых групп пользователей за счет полезно-развлекательного контента, что отразится в повышении MAU и ASL метрик,
потому что Авито приобретёт в продуктовой ценности для клиентов на ранней стадии воронки покупки недвижимости
3
Если уменьшить количество одновременно отображаемых пинов на карте,
то повысится общее юзабилити приложения и вероятность по клику на пин и прохождению дальше по флоу,
потому что потому что мы избавим юзеров от избыточности выбора (choice overload) и снизим для них усталость от принятия решений
4
Если сделать приоритезацию пинов при появлении,
то можно дополнительно снизить choice overload и подсветить интересные предложения,
потому что с помощью анимации юзеры получат визуальный паттерн, по которому удобнее отсматривать пины по порядку
5
потому что пользователь сможет мэтчить предложения со своими ожиданиями в быстром формате, не тратя время на переходы между страницами
Если сделать некоторые из пинов на карте в расширенном формате с продающими инфо-тегами,
то можно повысить конверсию в переходы на важные для нас объявления, а также тестировать влияние факторов на принятие решений в разрезе каждого конкретного пользователя приложения
6
Если сделать некоторые из пинов на карте в расширенном формате с продающими инфо-тегами,
то можно повысить конверсию в переходы и улучшить общее юзабилити,
потому что ясно разделенные варианты — это снижение мисскликов, снижение когнитивной нагрузки и улучшение восприятия информации
7
Если предложить юзерам визуально сочную форму отображения предложений,
то увеличится MAU предложения за счёт более активного шейринга предложений между юзерами (друзья, семья, родители, коллеги) и использования платформы эмерджентно и как классифайда, и как развлекательного ресурса (близкий пример: Instagram Shopping)
8
Если внедрить функцию «Картиндер»: свайп-влево/вправо по карточкам районов с ключевой статистикой (цены, инфраструктура, отзывы),
то повысится скорость первичного отбора локаций и сократится отток пользователей на этапе «где смотреть дальше»,
потому что формат swipe знаком и комфортен для быстрой дискретизации большого объёма информации
Приоритезация гипотез по RICE
1.3
Чтобы сфокусироваться на самых ценных улучшениях, я использовал фреймворк RICE, который помогает оценивать гипотезы по влиянию на продукт, уверенности в результате и сложности реализации.
RICE расшифровывается как:
Reach — охват пользователей
Impact — влияние на метрики (MAU, ASL, CTR),
Confidence — уверенность в гипотезе,
Effort — ресурсы на реализацию (в данном случае оценивал субъективную сложность для реализации со своей стороны)
Сразу же провел быстрый скоупинг идей, чтобы успеть сделать самое важное к дедлайну. Для этого отметил наилучшие идеи, которые помещались в 8 условных юнитов работы. Несколько интересных идей на этом этапе пришлось отбросить; спойлер — мы вернёмся к ним позже!
Файлик может подгружаться некоторое время
Построение User Flow
Файлик может подгружаться некоторое время
1.3
Чтобы зафиксировать обновлённую логику движения пользователя, я описал ключевые сценарии взаимодействия с сервисом. Этот шаг помог выстроить последовательность действий без лишних ветвлений и зафиксировать, где интерфейс должен помогать, а не мешать.
Коридорное исследование: проверка ранних гипотез в флоу покупки недвижимости
1.3
Чтобы быть уверенным в своих гипотезах, провел коридорное тестирование low-fi прототипов с 5 участниками. Исследовал, как пользователи проходят флоу выбора жилья на покупку при изменённой логике интерфейса.
Что тестировали с юзерами:
Отображение карточек в два столбца, чтобы ускорить этап “первичного отбора”
Старт с карты, как основной инструмент ориентации в городе
Результат: пользовательский опыт по ряду гипотез улучшился недостаточно, либо в отдельных случаях даже ухудшился. Из тревожащего – люди терялись в навигации, пропускали важные детали и некоторые давали сдержанный фидбек по интерфейсу, оценивая его как «сливающийся» и «мелкий»
Что еще нужно исправить: старт с карты
"Ну... карта — это прикольно, но я даже не знаю, где искать. Просто зумить туда-сюда?"
— участница, 29 лет, ищет жильё впервые
"Если бы районы были отмечены как-то, было бы легче. А так всё сливается."
— участник, 35 лет, переезжает в другой город
Что еще нужно исправить: карточки в два столбца
"Раньше хотя бы фото были большие — сразу видно, что за квартира. Сейчас всё в куче."
— участница, 29 лет, ищет жильё впервые
"Пальцем промахиваюсь постоянно, когда кликаю. Слишком мелко."
— участник, 26 лет, ищет студию в центре
Общие выводы:
Хорошо звучит ≠ хорошо работает. Идеи, полученные из интервью, не все подтвердились в реальных сценариях использования
Карта без предварительных фильтров и контекстов чаще запутывала, особенно тех, кто не знал точно, где хочет жить
Карточки в 2 столбца уменьшили визуал и текстовые блоки часто и так не слишком отличающихся предложений. Фактически получили тот же choice overload, что изначально был с пинами на карте
При этом, ряд пользователей положительно отметили интуитивное удобство работы сразу с картой и почти все пользователи отметили, что при работе с меньшим количеством пинов и расширенными пинами им проще воспринимать с нее информацию
Что дальше, если ушли не туда? Итеративность Diamond-фреймворков
1.3
Итак, как это часто бывает, поставленная гипотеза не подтвердила себя. Что дальше?
На этом этапе у меня был выбор: продолжить работу с визуальной оболочкой, сделать “причесанный” концепт и пойти дальше, как это часто бывает на конкурсах и при жёстких сроках.
Но я решил иначе и пошел обратно: к данным, к наблюдению за реальным поведением пользователей. Не хотелось жертвовать качеством ради скорости, вместо этого выбрал итерационность, прозрачную логику и настоящую эмпатию к пользователю.
Такой подход хорошо ложится на структуру Double Diamond и его расширенную версию Triple Diamond. Эти фреймворки не про прямую линию от А к Б, а про циклы, в которых ты возвращаешься назад, чтобы уточнить задачу или проверить гипотезу. Итерации в них не стоит считать сбоем, это вариант нормы. Используя Triple Diamond, избегать необходимой итеративности в нём было бы ошибочно.