Привет, меня зовут Владислава, я UX-исследователь в Контуре в направлении Недвижимость. Мы создаем решения для застройщиков и риелторов. Например, в портфеле направления есть сервисы для электронной регистрации прав собственности в Росреестре и проверки юридической чистоты сделок.

Как пришли к тому, что нужно проверять успешность решения

Раньше команда разработки жила по простому принципу: ставили задачу, реализовывали ее и запускали. Никто не задумывался, как пользователи используют наше решение после релиза. Мы не могли сказать, пользуются ли фичей, решает ли она задачу пользователя, или есть какие-то проблемы.

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

Тогда мы задумались о внедрении нового подхода:

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

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

Как мы внедряли новый подход

Шаг 1. Обсудили изменения с командой

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

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

Вот, как это выглядело:

Шаг 2. Проанализировали первое выпущенное решение

Примерно через 4-5 месяцев после запуска решения мы с аналитиком попытались проверить гипотезы, которые описали ранее. Я проводила анализ, а аналитик предоставлял данные по запросу.

Тогда выявилась большая проблема. На начальном этапе обсуждения мы многое не учли. Например, не обсудили, по каким критериям будем понимать подтвердилась гипотеза или нет, а также, что мы с этим будем делать. Из-за этого увеличилось количество времени на анализ и потребовалось больше ресурса аналитика.

Сначала мы не понимали, какие выводы сделать. А потом — что делать с полученными выводами. В итоге эта работа не принесла особой пользы.

Шаг 3. Расширили критерии оценки гипотез

Перед обсуждением следующего решения я расширила критерии и добавила описание:

Когда можно считать, что гипотеза проверена
Что делать, если гипотеза подтвердится или нет
Какие метрики собирать

Когда мы проанализировали решение с новыми вводными, поняли, что процесс снова усложнился:

Мы стали тратить больше времени на обсуждение деталей — примерно на 1-2 часа.
Уходило очень много «мыслетоплива», так как для всех участников процесс был новым, и на многие вопросы мы не могли ответить.
В процессе анализа все равно вылезло много моментов, которые мы не учитывали на старте, поэтому приходилось собирать и проверять дополнительные данные.

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

Шаг 4. Упростили сложившийся процесс

Пришла идея, как упростить процесс:

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

Плюсы в упрощении:

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

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

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

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

Чтобы понять, стоит ли смотреть в сторону улучшений или исследований, можно ответить на два вопроса:
Хотим ли мы развивать эту часть сервиса дальше?
Вредит ли решение текущим пользователям при выполнении целевой задачи?

Если в обоих случаях ответ отрицательный, ничего предпринимать не надо. А если ответ положительный — стоит поднять приоритет такой задачи. Если же вы ответили «да» только один раз, задача идет в работу, но с низким приоритетом.

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

Шаг 5. Исправили допущенные ошибки

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

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

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

Начали внедрять приоритезацию с помощью двух вопросов, которые описывала выше. Пока опыта мало, поэтому сказать, решило ли это нашу проблему, не могу.
Проанализировав всю эту работу, я написала для команды «Алгоритм проверки успешности фичи». Что в нем зафиксировано:

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

К написанным целям мы хотели добавить влияние на Star-метрику, но поняли, что это пока невозможно. Чтобы не получить искажения, нужно учитывать слишком много факторов: от запуска лендингов и рекламы до внесения других правок в сервисе.

Что в итоге

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

Про результаты работы и многом другом пишу в телеграм-канал UX-исследователей Контура «Сдоба»

Как проверить успешность фичи