Привет, меня зовут Владислава, я UX-исследователь в Контуре в направлении Недвижимость. Мы создаем решения для застройщиков и риелторов. Например, в портфеле направления есть сервисы для электронной регистрации прав собственности в Росреестре и проверки юридической чистоты сделок.
Как пришли к тому, что нужно проверять успешность решения
Раньше команда разработки жила по простому принципу: ставили задачу, реализовывали ее и запускали. Никто не задумывался, как пользователи используют наше решение после релиза. Мы не могли сказать, пользуются ли фичей, решает ли она задачу пользователя, или есть какие-то проблемы.
Единственным источником знаний была техподдержка: если к нам приходили с обратной связью, мы оценивали ее и решали, вносить ли изменения. Позже появились опросы, система была такая же — получали обратную связь, оценивали и принимали решение. Такой формат помогал отлавливать крупные проблемы, но не давал оценить успех решения в целом. Мне, как исследователю, не хватало этой информации, чтобы улучшать сервис, основываясь на сценариях пользователей.
Тогда мы задумались о внедрении нового подхода:
Для каждого релиза определять целевые показатели и гипотезы, которые будем проверять после запуска.
Добавлять задачу на метрики, которые помогут сделать оценку решения.
Закладывать время на сбор и анализ данных.
На основании полученных данных принимать решение о дальнейших действиях.
Выделять время на доработку или исследование.
Нам хотелось получить прозрачный для всех анализ успешности решения на основе данных, а не интуиции, поэтому я решила пока взять инициативу и показать, что проверять решение после релиза важно.
Как мы внедряли новый подход
Шаг 1. Обсудили изменения с командой
Я организовала несколько встреч с аналитиками и проектировщиками, где объяснила, что хочу обсуждать гипотезы и сомнения по сценарию до релиза, а после — проверять их.
Обсуждение одного решения занимало около двух часов: мы проводили две встречи по часу. Информацию мы фиксировали рядом с аналитикой по задаче, чтобы не забыть посмотреть на нее через определенное время.
Вот, как это выглядело:
Шаг 2. Проанализировали первое выпущенное решение
Примерно через 4-5 месяцев после запуска решения мы с аналитиком попытались проверить гипотезы, которые описали ранее. Я проводила анализ, а аналитик предоставлял данные по запросу.
Тогда выявилась большая проблема. На начальном этапе обсуждения мы многое не учли. Например, не обсудили, по каким критериям будем понимать подтвердилась гипотеза или нет, а также, что мы с этим будем делать. Из-за этого увеличилось количество времени на анализ и потребовалось больше ресурса аналитика.
Сначала мы не понимали, какие выводы сделать. А потом — что делать с полученными выводами. В итоге эта работа не принесла особой пользы.
Шаг 3. Расширили критерии оценки гипотез
Перед обсуждением следующего решения я расширила критерии и добавила описание:
Когда можно считать, что гипотеза проверена
Что делать, если гипотеза подтвердится или нет
Какие метрики собирать
Когда мы проанализировали решение с новыми вводными, поняли, что процесс снова усложнился:
Мы стали тратить больше времени на обсуждение деталей — примерно на 1-2 часа.
Уходило очень много «мыслетоплива», так как для всех участников процесс был новым, и на многие вопросы мы не могли ответить.
В процессе анализа все равно вылезло много моментов, которые мы не учитывали на старте, поэтому приходилось собирать и проверять дополнительные данные.
В итоге немного улучшенный процесс все равно не приносил того результата, который мы хотели.
Шаг 4. Упростили сложившийся процесс
Пришла идея, как упростить процесс:
На старте нужно обсуждать только целевые действия основного сценария, вешать на эти действия метрики и строить воронку. Воронка поможет отследить резкие скачки в поведении пользователей и неравномерности прохождения сценария.
Описание гипотезы нужно проводить, если заметили аномалии в воронке. Только в этом случае мы с аналитиком и проектировщиком описываем гипотезы и то, как будем их проверять.
Плюсы в упрощении:
Стали тратить меньше времени на обсуждения.
Сократили время на анализ и принятие решения.
Получали конкретные показатели, по которым было проще сделать вывод и спланировать действия.
Не обошлось и без новых проблем. Мы не учли некоторые моменты при обсуждении целевых действий в воронке, получили большие искажения и неверно интерпретировали данные:
Не продумали, что сервис автоматически открывается всем, у кого есть другой продукт направления, и в него могут попасть те, кому он не нужен.
Считали целевым действием только клик по кнопке, которая переводит на другую страницу. И не учли действия на шаге до перехода на другую страницу, например, выбор любого элемента или любое заполненное поле.
Делали выводы интуитивно, потому что данные не с чем сравнивать. У нас в основном стартапы, поэтому почти все решения — это новые сценарии, а не улучшение предыдущих. Мы не понимали, какой процент отвала считать нормальным, а какой нет.
Из-за такой неопределенности не было понимания, как расставить приоритеты в задачах по улучшению решения. Но мы выяснили, что мы не единственные, кто делает выводы интуитивно. Многие, если видят неравномерности в прохождении нового сценария, обращаются к команде и совместно решают, что с этим делать.
Чтобы понять, стоит ли смотреть в сторону улучшений или исследований, можно ответить на два вопроса:
Хотим ли мы развивать эту часть сервиса дальше?
Вредит ли решение текущим пользователям при выполнении целевой задачи?
Если в обоих случаях ответ отрицательный, ничего предпринимать не надо. А если ответ положительный — стоит поднять приоритет такой задачи. Если же вы ответили «да» только один раз, задача идет в работу, но с низким приоритетом.
Также я поняла, что для точного анализа стоит определять потенциальную емкость решения, а после смотреть уникальных пользователей и сравнивать. Этот дополнительный критерий будет влиять на успешность решения.
Шаг 5. Исправили допущенные ошибки
Добавили изменения в воронку, чтобы убрать искажения. У нас получилась более показательная воронка, которую стало удобно анализировать:
2. Попробовали добавить в анализ критерий использования решения. Мы вычисляли процент использующих фичу от потенциальных пользователей фичи. Но поняли, что эта метрика нам ни о чем не говорит, так как есть решения, которые создаются не для увеличения числа пользователей.
Поэтому мы решили выделять для каждого нового решения свой целевой показатель, например, уменьшение гуляния или обращений в техподдержку, сокращение ошибок, ну и, конечно же, увеличение использования.
Начали внедрять приоритезацию с помощью двух вопросов, которые описывала выше. Пока опыта мало, поэтому сказать, решило ли это нашу проблему, не могу.
Проанализировав всю эту работу, я написала для команды «Алгоритм проверки успешности фичи». Что в нем зафиксировано:
цель активности
на каком шаге сценария отваливаются пользователи и в каком объеме
как мы достигаем цели
как принимаем решение
как определяем приоритет задач после сделанных выводов
ответственность исследователя и аналитика в этой работе
К написанным целям мы хотели добавить влияние на Star-метрику, но поняли, что это пока невозможно. Чтобы не получить искажения, нужно учитывать слишком много факторов: от запуска лендингов и рекламы до внесения других правок в сервисе.
Что в итоге
Теперь мы обсуждаем не только само решение, но и оценку его успешности.
Уже через месяц после релиза мы видим возможные проблемы с новым решением и можем на них реагировать.
На основе этих данных мы принимаем решение о дальнейших исследованиях или изменениях.
Про результаты работы и многом другом пишу в телеграм-канал UX-исследователей Контура «Сдоба»