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

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

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

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

Представим, что мы с вами со стороны наблюдаем за исследователем, который вышел на работу в сервис для покупки авиабилетов. Важно отметить, что в этой ситуации может оказаться не только исследователь, но и любой сотрудник, который может проводить исследования: продакт-менеджер, дизайнер или любой другой член команды. В Америке сокращённо говорят 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-исследованиям, мы больше советуем найти хорошего наставника и развиваться с его помощью, если вы единственный исследователь в команде.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• проблема;  

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

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

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

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

  © Habrahabr.ru