Почему результаты UX-исследований не идут в работу

Почему результаты исследований могут не пойти в работу, а, как часто говорят, могут пойти «в стол»? Чтобы было проще разобраться в вопросе, рассмотрим распространённые проблемы на примере исследователя, который вышел на работу в сервис для покупки авиабилетов. 

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

Контекст нашего героя

Представим, что мы с вами со стороны наблюдаем за исследователем, который вышел на работу в сервис для покупки авиабилетов. Важно отметить, что в этой ситуации может оказаться не только исследователь, но и любой сотрудник, который может проводить исследования: продакт-менеджер, дизайнер или любой другой член команды. В Америке сокращённо говорят PwDRs — People Who Do Research — люди, которые не являются исследователями, но тратят 10% или более своего времени на исследования пользователей. Для простоты мы будем далее чаще говорить «исследователь», подразумевая любого сотрудника. 

Выйдя на работу, наш исследователь провёл исследование, в котором нашёл массу инсайтов. Два из них мы будем рассматривать в последующих кейсах:

1. Покупатели авиабилетов хотят посмотреть подборку крутых мест в стране, куда они собираются лететь. Чтобы знать, что стоит посетить и посмотреть в путешествии. Либо до покупки авиабилетов, либо после.

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

Вместе с исследователем мы узнали о двух наблюдениях: одной потребности и одной сложности. Конечно, были и другие, но для простоты мы будем рассматривать эти два.

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

1. Подготовку к исследованию. 

2. Проведение исследования.

3. Анализ результатов.

4. Непосредственную работу с результатами, то есть перевод результатов в решения для клиентов.

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

Содержание статьи

Проблемы на этапе подготовки к исследованию:

• Непонимание задачи исследования

• Пренебрежение существующими данными

• Отсутствие ресурсов на изменения

• Безграничный аппетит на данные

• Агентская работа

• Низкое качество методологии

• Отсутствие ценности исследования

• Готовые решения у команды

Проблемы на этапе проведения исследования:

• Низкое качество исследования

• Незафиксированная информация

• Долгий сбор данных

Проблемы с анализом результатов: 

• Плохая структура результатов

• Отсутствие главных инсайтов

• Анализ результатов без участия команды

• Ожидание окончания сбора данных

• Несохранённые инсайты

Проблемы в работе с результатами: 

• Результаты в отдельном отчёте

• Отсутствие конкретных шагов для команды

• Создание одного решения

• Запуск решения без проверки

Подготовка к исследованию

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

Непонимание задачи исследования

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

Задачи исследования вытекают из целей команды, а те, в свою очередь, вытекают из целей компании. Начинать исследование и выбирать его метод без понимания этих вводных очень опасно: результаты пойдут «в стол», ведь они не помогут команде в достижении результатов. 

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

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

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

Причиной может быть и вина «заказчика» продакт-менеджера, который начинает исследование по причинам «вроде бы все исследуют, и нам тоже нужно», «давайте пойдём общаться с пользователем, неважно, для чего». Бывает и так, что менеджеры заказывают исследование, потому что оно создаёт видимость, будто что-то происходит. Проводить исследования для них проще, чем делать решения.

Совет. Никогда не начинайте исследование без понимания:

• целей команды; 

• задач исследования; 

• вопросов и гипотез команды;

• целевой аудитории;

• что команда хочет получить на выходе;

• кто и как будет работать с результатами; 

• какие данные уже есть.

Исследователю также стоит узнать, кто ещё заинтересован в задаче, и поговорить с ними про эту задачу тоже, чтобы избежать «глухого телефона».

Пренебрежение существующими данными

Следующая по популярности проблема на этапе подготовки к исследованию — это пренебрежение имеющимися данными. 

Предположим, наш исследователь пошёл проводить интервью и тесты с пользователями, но не посмотрел, какие данные уже есть в компании. Он возвращается с найденными идеями к команде, а команда говорит: «Ой, дружище, а мы это уже знаем. Мы знаем о проблеме, что клиенты не могут выбрать билет с багажом или без багажа. Мы знаем, что они хотят подборку крутых мест. Спасибо, но для нас это не новости». И опять результаты работы в каком-то смысле уходят «в стол». То есть эти проблемы «на радарах», и не нужно было проводить исследование, чтобы их найти.

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

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

Совет. Всегда используйте на старте имеющуюся информацию. Чаще всего у исследователя есть такие каналы пассивного сбора опыта клиентов, как support, sales, социальные сети, магазины приложений. Также перед стартом стоит заглянуть в прошлые исследования. Всегда хорошо собрать команду на небольшой воркшоп, где каждый сможет выложить на общую доску, например в Miro, свои экспертные знания по изучаемой теме. Дополнительно уточнить вопросы и гипотезы исследования помогут анализ рынка и кабинетный research.

Отсутствие ресурсов на изменения

Третья проблема — это отсутствие ресурсов на изменения по результатам исследования. 

Представим, что наш исследователь принёс две проблемы. Команда с ним не спорит, она согласна, что проблемы видны. Но бэклог забит, и в ближайшие полгода реализовать решение не получится: у команды технический долг, нужно доделать продукт до market normal. Взять новые знания в работу нет возможности.

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

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

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

Безграничный аппетит на данные

Следующая проблема, которая сильно влияет на то, что результаты могут пойти «в стол», — это безграничный аппетит на собираемые данные.

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

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

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

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

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

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

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

Во-вторых, обсудив с командой цели и задачи, сфокусироваться. Очень сложно «засунуть» всё в одно исследование, когда чётко выделены его цели и задачи.

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

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

Агентская работа

Если исследователь работает как внешнее или внутреннее агентство, а продакт-менеджер относится к исследованию, как к заказной работе, результаты тоже могут пойти «в стол».

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

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

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

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

Совет. И исследователю и команде обязательно нужно вовлекаться в discovery-процесс и участвовать во встречах с клиентами. 

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

Постепенно получится вовлечь команду в проведение исследования и делать проект вместе. 

Низкое качество методологии 

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

Представим, что наш исследователь принёс команде проблему, что клиентам не хватает фильтра по билетам с багажом. Но во время тестирования он просто задавал клиентам вопрос: «Скажите, вот вы сейчас искали билеты. А хотелось бы вам, чтобы здесь был фильтр с багажом, чтобы вам было проще найти такие билеты?». И получил от всех ответ: «Да, конечно, хотелось бы». 

Неправильно подготовленный вопрос в методологии привёл к ложным выводам. Команде тяжело доверять таким результатам, если она понимает, как правильно формулировать вопросы. 

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

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

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

Из курсов мы рекомендуем фокусные обучения:

• Jobs to be done, Дима Капаев.

• Эмпатия в интервью, Дарья Маткина и Женя Новичихин. 

Отсутствие ценности исследования

Очень быстро вспомним проблему про отсутствие ценности исследования. 

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

Совет. Продакт-менеджеру стоит заказывать исследование, только если есть точное понимание ценности. А исследователю снова вспомнить, что нельзя начинать работу над проектом без понимания:

• целей команды; 

• задач исследования, вопросов и гипотез, которые есть у команды; 

• обязательного обсуждения, кто и как будет работать с результатами исследования, какие ресурсы на это есть.

Готовые решения у команды

И последняя проблема на этапе подготовки — это имеющиеся решения в головах продакт-менеджера или дизайнера. 

Наш исследователь принёс результаты. С одной стороны, они понятны для команды, в них есть проблема и потребность. Но с другой стороны, у команды в головах уже было решение, например они хотели сделать новые фильтры по самым выгодным ценам. Поэтому результаты исследования пошли «в стол», а в работу пошли новые фильтры.

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

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

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

• у каких клиентов есть эта потребность;

• как часто она возникает;

• как клиенты сейчас с ней справляются;

• насколько она важна или критична;

• какие решения используют;

• почему потребность или проблема важнее других.

Проведение исследования

Мы разобрали, почему результаты исследования могут не пойти в работу с этапа подготовки. Перейдём к этапу проведения исследования, когда мы отправляемся в поля и начинаем собирать данные. Здесь тоже есть ряд ошибок и проблем, которые могут пустить все результаты «в стол».

Низкое качество исследования

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

Наш исследователь принес инсайт, что пользователи хотят подборку крутых мест для посещения. Команда задаёт ему вопросы: «А в каких случаях? На каком этапе? Какие пользователи? Как они сейчас решают эту задачу?» А у исследователя этих данных нет, он просто нашёл проблему и не копнул глубже.

Аналогичная история со второй проблемой пользователей, что они не могут выбрать перелёт с багажом. Команда задаёт исследователю вопросы: «На что повлияло то, что клиенты не могут выбрать багаж? Что в итоге со сценарием покупки авиабилетов? Клиент смог его пройти или не смог? Как часто возникала эта проблема? У каких клиентов она встречалась?» и так далее. Если ответов на дополнительные вопросы нет, высока вероятность, что результаты пойдут «в стол», потому что взять задачу в работу без ответа на эти вопросы невозможно — нужно будет проводить еще одно исследование. 

Во время проведения исследования мы иногда не докапываемся до сути проблемы. Узнаём про какую-то потребность, но не раскапываем её детали: как клиент сейчас её закрывает, какими пользуется сервисами, в каком контексте потребность возникает. То есть фактически мы довольствуемся первой полученной информацией, а не собираем подробности и контекст. Поэтому приносим команде поверхностные данные, которые вызывают дополнительные вопросы и требуют доуточнений.

В этом случае получается, что мы либо не понимаем причин проблем, либо не понимаем контекста, либо не знаем важных деталей для создания решения. Часто в этом случае команда говорит: «Мы это уже знали». И они правы: зачастую наша задача во время исследования — не подтвердить то, что мы знаем, а поиск того, чего не знаем.

Причины проблемы. В первую очередь проблема возникает из-за отсутствия опыта, знаний, навыков по проведению юзабилити-тестов и интервью с клиентами. Многие дизайнеры и продакты учатся исследованиям по книжке «Спроси маму». Многие исследователи не ходили на курсы и сразу начинают проводить исследования, получая опыт на практике. Они опираются на этот опыт, чуть-чуть его корректируют и продолжают работать дальше.

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

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

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

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

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

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

Незафиксированная информация

Вторая проблема на этапе сбора данных — это незафиксированная информация. 

Представьте, что наш исследователь принёс в команду инсайт: клиенты хотят подборку крутых мест, которые интересно посетить во время путешествия. Команда спрашивает: «Слушай, расскажи поподробнее, что именно он говорил, что именно за подборку он упоминал? Можешь привести какие-то примеры его цитат?» Или: «Расскажи поподробнее, что это за клиент был?» А исследователь не зафиксировал всю информацию. Он делал какие-то заметки по ходу интервью, но ни аудиозаписей, ни транскриптов у него нет. В отличие от прошлой проблемы, во время интервью или теста он получил эту информацию, но не смог её записать. 

Эта проблема чаще встречается, если интервью или юзабилити-тест проводит продакт-менеджер или дизайнер. Проблема влияет на результаты, потому что если мы не сохранили дополнительные факты, то команде тяжело использовать информацию. Доверие к таким результатам исследования у команды сильно снижается, ведь нет подробностей и прямой речи, есть только переваренная информация. 

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

Причины проблемы. По ходу исследования тяжело вести заметки. Далеко не каждый исследователь может это делать. Если заметки и ведутся, то очень-очень короткие, и часто это не прямая речь клиента, а её интерпретация. Если человек, который проводит исследование, пересматривает записи и делает заметки постфактум, то, как правило, это не делается в полном объёме, ведь на такую работу нужно в два раза больше времени. 

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

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

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

Долгий сбор данных

И третья проблема на этапе проведения исследования — это длительный сбор данных. 

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

Почему эта проблема влияет на то, что результаты пойдут «в стол», кажется, понятно. Исследователь не уложился в рамки спринта, поэтому актуальность полученных данных стала ниже. Команда начинает работать над другими задачами, а результаты исследования остаются в подвешенном состоянии до лучших времён.

Причины проблемы. Проведение исследования затягивается в основном на этапах подготовки к интервью, потому что много времени отнимает рекрут. Рекрут — это отдельная большая тема, здесь мы не будем её разбирать. Но здорово, когда с ним помогают внешние агентства, либо внутреннее агентство в компании. Тогда задачи ставятся им заранее, и поиск респондентов не тормозит ваши проекты. 

Но есть и несколько других причин возникновения проблемы. Например, заранее не определены сроки исследования, и поэтому исследователь и команда переносят интервью и сроки отчёта. В итоге сдача проекта сильно затягивается. 

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

Советы. Всегда делегируйте рекрут. Если у вас много задач, старайтесь нанять внутренних рекрутеров или создать внутреннее агентство, чтобы не зависеть от внешних. 

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

Очень здорово, когда есть возможность нанять администратора, такого ReOps-менеджера, который поможет вам с административной частью проведения исследования. Если вы дизайнер или продакт, который проводит исследования, советуем привлекать внутреннего или внешнего исследователя, который тоже поможет проводить проекты быстрее и не затягивать сроки.

Мы закончили с этапом проведения исследования и переходим к этапу анализа.

Анализ результатов

На этом этапе мы анализируем всю собранную информацию, готовим отчёт и обсуждаем его с командой. Что может пойти не так, из-за чего все наши результаты пойдут «в стол»?

Плохая структура результатов

Первая проблема — это ошибка структурирования. Например, наш исследователь принёс два инсайта, но команде тяжело работать с его материалами. Они пришли в сыром виде и плохо структурированы. 

В результатах может быть слишком много информации, и тогда непонятно, на чём фокусироваться. К примеру, отчёт представлен в виде больших кусков текста и большого массива данных, и команде непонятно, что с ними делать дальше. Либо результаты — это огромное количество отдельных заметок, никак не связанных друг с другом. Из большого количества инсайтов тяжело выделить суть и понять, что брать в работу.

Причины проблемы. Ошибки структурирования чаще всего возникают потому, что у проводящего исследование либо недостаточно ресурсов на анализ, либо нет понимания, как его делать. В первом случае он просто не успевает проанализировать всю собранную информацию и отдаёт массив, в котором сложно разобраться. Непонимание, как структурировать отчёт же обычно вытекает из неопытности. Например, ты провёл 12 интервью, получил 100 страниц текста и не знаешь, что с ним делать. 

Связанная ошибка — провести из-за аппетита больше интервью, чем реально переварить. Например, не 12, а 20 или 30 встреч с респондентами. В этом случае проблема перетекает в статус «собрали слишком много»: такой объём одному человеку проанализировать практически нереально. 

Советы. Советы для ошибки структуры можно поделить на две части: для отчётов по итогам интервью и для юзабилити-тестов. 

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

Если речь про юзабилити-тестирование, то в отчёте всегда должны быть:

• проблема; 

• причина проблемы; 

• контекст её возникновения; 

• поведение клиента в случае проблемной ситуации: что он стал делать, к чему это привело; 

• частота возникновения проблемы;

• указание критичности как вывода. 

Отдельный совет — на старте подумать о том объёме данных, которые вы соберете.  Если он большой, то, как я уже говорил раньше, стоит делать проект итерациями: собрать первый кусочек, проанализировать и посмотреть, что получилось. Если вы видите, что данных не хватает, то собрать ещё, и так далее.

Отсутствие главных инсайтов

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

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

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

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

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

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

Анализ результатов без участия команды

Результаты исследования могут пойти «в стол» на этапе анализа из-за того, что к нему не привлекли команду. Как и с интервью и подготовкой, у команды значительно меньше доверия результату и эмпатии к собранным данным, если она не участвовала в анализе. 

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

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

Советы. Чтобы подобного не происходило, лучше делить анализ на три этапа: 

1. Человек, который проводил исследование, самостоятельно изучает результаты. 

2. Он отправляет команде результаты отчёта для предварительного ознакомления.  

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

Здорово, если после этого исследователь совместно с командой проводит воркшоп по генерации следующих шагов.

Ожидание окончания сбора данных

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

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

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

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

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

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

Несохранённые инсайты

И ещё одна небольшая проблема, которая больше касается UX-исследователей, — это когда сохраняются не все найденные инсайты или проблемы. 

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

Совет. Если вы работаете в команде исследователей, создайте процесс, который позволит сотрудникам делиться друг с другом знаниями с интервью или тестов, которые не попадают напрямую в их зону ответственности.

Работа с результатами

И мы переходим к последнему этапу — использованию результатов исследований, созданию решений, проверке этих решений и запуску решений для клиентов.

Результаты в отдельном отчёте

Первая проблема, которая очень часто возникает у исследователей, — оставление результатов в виде отдельного отчёта исследования. 

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

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

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

Также здорово определиться с командой, в каком виде лучше вести бэклог. Результаты исследования не всегда комфортно в него переносятся: иногда нужен промежуточный артефакт в виде CJM или big picture команды. Такие артефакты помогают сразу визуализировать собираемую информацию. Это может быть и таблица, например в Airtable, но визуализация лучше. 

Отсутствие конкретных шагов для команды

Связанная с предыдущей ошибка — не перевести главные результаты в actions для команды. 

Представьте, что наш исследователь принёс две важные проблемы. Во время обсуждения команда с ними согласилась, но в конкретные шаги и задачи ничего не перенесла. То, чего нет в задачах в бэклоге, например в Jira, или другом таск-трекере у команды, не поменяется у клиента. С высокой вероятностью такие проблемы не уйдут в работу.  

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

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

И второй момент со стороны команды. Часто исследователь слышит: «Да, мы это уже знаем, спасибо». Но, опять же, если знание есть, но оно не переведено в actions, значит, никто не будет делать решение для клиентов. Даже если команда говорит, что «отлично, мы получили то, что уже знали», нужно перевести результаты в задачи, чтобы улучшения и исправления были внесены в продукт.

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

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

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

3. Мы всё хорошо понимаем и можем на основе наших знаний переходить к созданию решений и ставить задачу. 

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

Создание одного решения

Третья проблема, которая возникает на финальном этапе исследования, связана с поиском решения. 

Казалось бы, мы получили результаты, и команда думает над решением на их основании. Результаты уже не пошли «в стол». Но на деле часто бывает, что команда придумывает какое-то одно решение. Решение проверяется на A/B-тесте или на юзабилити-тесте, и видно, что оно не закрывает найденную проблему или потребность клиента. И команда говорит: «Не сработало. Переходим к следующей проблеме или следующей потребности».

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

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

Запуск решения без проверки

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

Причина проблемы. Иногда мы видим, что команда запускает решение в прод без проверки. Дальше команда смотрит на метрики, а они не такие зелёные, как хотелось бы. И мы говорим, что «нет, решение не сработало» или «нет, не та проблема, не та потребность». 

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

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