Алгоритм проверки успешности решения 

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

В этой статье расскажу, как мы выстроили процесс анализа успешности решения. Если вы из раза в раз задаетесь вопросом: «А не фигню ли мы сделали?», но не знаете, как это можно проверить — эта статья для вас.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

После небольшого перерыва в мою голову пришла идея, как упростить процесс:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что в итоге

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

Написано для телеграм-канала «Сдоба»