Гайд: как анализировать результаты глубинных интервью и использовать их для проверки гипотез

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

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

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

Хорошие причины провести интервью

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

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

Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление, а тажке делаем make sense podcast.

Хорошие причины провести интервью:

1. Проверить или валидировать гипотезу, найти проблему. Например, мы предполагаем, что у пользователя есть проблема — кривой или незакрытый сценарий. И тогда с помощью интервью мы пытаемся проверить, действительно ли пользователи сталкиваются с такими проблемами.
2. Узнать и определить основные сценарии в продукте, понять, через какие этапы проходит пользователь и с чем сталкивается на этом пути.
3. Понять причины тех или иных решений пользователей, их внутреннее состояние. Например, человек говорит: «Мне важно закрыть документ в течение дня», — тогда с помощью интервью мы можем выяснить, почему ему важно закрыть документ в такие сроки. Или можно узнать целевой результат действия, то есть почему нужно прийти к такому результату, почему именно такую картинку пользователь считает целевой или конечным шагом в работе.
4. Развивать эмпатию к своему пользователю. Когда продакт никогда не видел свою аудиторию, никогда с ней не соприкасался и не взаимодействовал, это тоже может быть способом почувствовать, понять, кто твой пользователь, на каком языке он говорит. Именно на уровне эмпатии. 

Шаг 1. Фиксируем информацию

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

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

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

Надо ли повторно контактировать с респондентом после интервью?

Чаще всего нет. Обычно мы проводим интервью и на этом ставится точка: прощаемся с респондентом и благодарим его. Однако для этого в процессе интервью важно следить за двумя моментами:

1. Отслеживать скрипт, чтобы задать все нужные вопросы и ничего не упустить. 
2. Чувствовать тему, понимать, куда еще стоит копнуть и какие дополнительные вопросы задать. 

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

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

Читайте также: Гайд: как подготовиться к глубинным интервью и провести их максимально эффективно

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

Бывает и противоположный вариант. Пользователь говорит: «Да я вообще в эту часть системы не хожу и проблем у меня нет». А мы открываем данные техподдержки и видим, что за последний месяц он прислал пятнадцать обращений и вопросов. У такого поведения может быть несколько причин: пользователь просто не видит в этом проблемы, исследователь не смог установить с ним нормальный контакт, пользователь не хочет выносить наружу какие-то чувствительные данные. 

Шаг 2. Расшифровываем запись

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

Если тема знакомая или есть ограничения по времени, можно в расшифровке отмечать ключевые идеи или фиксировать тезисно слова респондента. 

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

Как можно расшифровывать записи интервью:

1. Своими силами или силами коллег — просто включать запись и делать расшифровку.
2. Через фрилансеров — можно размещать заказы на расшифровку на фриланс-биржах или найти каких-то постоянных фрилансеров. Хорошо расшифровывают записи судебные стенографисты. В этом варианте важно задать удобные для вас стандарты оформления.
3. С помощью сервиса zapisano.org — в нем удобный интерфейс, при загрузке записи сервис показывает четкие сроки работ, а документы на выходе оформлены по стандартам и расшифрованы достаточно грамотно.
4. Через субтитры на YouTube — аудио конвертируется в видео со статической картинкой. Это видео вы заливаете на свой YouTube-канал и получаете автоматически сгенерированные субтитры.
5. Через Яндекс Speech.

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

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

Шаг 3. Обрабатываем данные: смотрим на факты

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

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

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

Шаблон таблицы для анализа интервью

Как устроена таблица. 

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

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

Табличка — не единственно возможный способ обработки данных. Табличный формат хорошо подходит для проблемных интервью и JTBD. Например, CJM удобнее сразу раскидывать по доске Miro — размещать ключевые инсайты на карте пользовательского пути. 

Шаг 4. Интерпретируем первичные данные

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

Допустим, смотрят наименование 5 из 10 респондентов, смотрят количество — 10 из 10 респондентов, а номер партии — только один респондент. Однако на генеральной совокупности эти 5 из 10 могут превратиться в 10%, а 1 из 10 — в 20%. Таким образом мы систематизируем все ответы количественно (напомню, это просто предварительная обработка результатов интервью, которую необходимо будет проверять статистически).

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

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

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

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

Например, мы выяснили (инсайт): пользователи не понимают что делать, когда контрагент не подписал электронные документы. Допустим, только двое из восьми респондентов знают что можно выставить корректировку или исправление. Остальные не знают этого и либо действуют наугад, либо звонят в техподдержку. После этого аналитики, менеджеры продуктов, проектировщики могут подхватить эти выводы и самостоятельно закончить исследование.  

А можно пойти дальше: понять насколько массовая проблема (запросить количественные данные у техподдержки, выгрузки по действиям пользователей с не подписанными документами и т.д.), выяснить причины такого поведения и ожидания пользователей. Все это может повлиять на выбор варианта решения проблемы: изменить интерфейс — например, добавить подсказку; поменять логику работы продукта; автоматизировать процесс и т.п.

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

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

Если мы уже знаем своих пользователей

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

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

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

Если мы почти не знаем своих пользователей

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

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

Ошибки в анализе интервью

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

На интервью мы проверяем, а не подтверждаем. Например, если задать вопрос: «Вам будет удобно здесь создавать и отправлять документы?» — то человеку проще сказать: «Да, конечно». Однако такой ответ легко может оказаться недостоверным, его нельзя использовать, делая выводы.

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

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

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

Шаг 5. Используем результаты в работе над продуктом

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

Тут есть два варианта:

1. Обратиться к эксперту. Когда продукт большой и серьезный, у него уже сложился пул клиентов, в отрасли наверняка будут эксперты. Можно пойти к ним и поговорить: «Вот, смотри, что мы накопали. Что скажешь?» И эксперт ответит: «Настоящая бомба! Надо копать в эту сторону», — или: «Нет, туда можете даже не смотреть». 
2. Посмотреть на конкурентов и понять, есть ли у них решение в рамках вашей гипотезы. Бывает, что у конкурентов уже есть решение и вы опоздали — а значит, вам нужно срочно наверстывать время, потому что это уже какая-то стандартная база, без которой пользователи вас не выберут. А бывает, что у конкурентов ничего подобного нет, и тогда надо попытаться понять — они просто не догадались так сделать или попробовали и не взлетело, проблема оказалась надуманной.
3. Провести новое исследование: количественное (опросы, выгрузки, анализ данных из системы) или юзабилити-тестирование (проверка решения). 

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

Как долго хранятся результаты интервью и когда к ним обращаются

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

Структура примерно такая: проект, тематика, исследование с указанием дат.

• KONTUR UX – EDI – массовые действия – подтверждение заказа (03.20)
• KONTUR UX – EDI – массовые действия – архивирование заказа (03.21)

Читайте также: Где хранить результаты исследований и по каким принципам организовать базу инсайтов?

Для чего нам это нужно:

1. Пока идет работа над гипотезой, продуктом или фичей, регулярно возникает необходимость вернуться к изначальному артефакту и уточнить какие-то детали. Например, мы делаем поиск и вдруг засомневались, нужны ли сразу все фильтры или для MVP достаточно двух ключевых, а остальные можно добавить в следующем релизе. А если из таблички мы не понимаем, для чего пользователю тот или иной фильтр, то можем даже переслушать аудиозапись или внимательно изучить транскрипт и посмотреть, что еще было связано с поиском, почему именно этот фильтр пользователь считает самым важным и не готов без него работать.
2. Когда проводится интервью, пользователь или клиент рассказывает много всего интересного и полезного. Особенно если удается задеть проблемную тему или навести его на какой-то инсайт. Например, мы копали одну тему, а зацепились за другую. Тогда данные исследования будут полезны для формулирования новой гипотезы, и мы можем обратиться к ним снова, чтобы найти дополнительную информацию и запустить новое исследование.
3. Мы храним артефакты по интервью для истории, потому что бывает так: есть продукт, в нем уже что-то реализовано и этим пользуются клиенты, а потом вдруг меняется закон, меняются тренды и подходы к работе. А так как прошло много времени, то мы уже забываем, почему у нас в продукте что-то реализовано именно так, а не иначе: например, почему мы сделали два фильтра, а не пять. В этом случае удобно вернуться к результатам исследований и прояснить логику текущего решения. 
4. Мы смотрим на своих пользователей в динамике. Например, сейчас электронными документами никого не удивишь, а девять лет назад, в 2012 году, когда рынок электронного документооборота еще только раскачивался, мы много общались с бухгалтерами на эту тему. И они говорили: да, это здорово, интересно, что так быстро все будет передаваться — но это какое-то будущее, на нашем веку такое не заработает. И подобные коренные изменения жизни, сценариев, восприятия технологий — интересный источник вдохновения, который может подтолкнуть на то, что прямо сейчас кажется невозможным, года через три станет нормой, а лет через пять — вообще фичей по умолчанию в любом продукте.
5. У нас много продуктов, поэтому какие-то идеи и гипотезы рождаются на их стыке. И чтобы не копать одну и ту же тему и не опрашивать одних и тех же людей по несколько раз, мы можем обращаться к результатам исследований из других продуктов. Например, мы решили привлечь новую аудиторию — автомастерские, но еще никогда не работали с ними. Тогда мы смотрим, были ли исследования автомастерских у других продуктов, и можем взять оттуда определенные сценарии, инсайты. 

Выводы

1. Интервью — хороший способ понять мотивы пользователей и развить эмпатию к ним. 
2. Не стоит проводить интервью «в любой непонятной ситуации» — это не универсальный исследовательский метод и у него есть свои границы применимости.
3. Респондентов для интервью необходимо подбирать осознанно — так, чтобы они представляли все группы пользователей, которые вы хотите изучить.
4. Необходимо избегать типичных ошибок в анализе интервью и помнить, что пользователи — не эксперты, данные интервью — это не статистические выводы, лояльные пользователи — это лишь один из пользовательских сегментов, на интервью мы не спрашиваем о будущем, а расспрашиваем респондента о его личном опыте.
5. Цепочка обработки результатов интервью и принятия решений на их основе состоит из четырех шагов: фиксируем информацию (записываем интервью), расшифровываем запись, обрабатываем данные, интерпретируем первичные данные, принимаем продуктовые решения или запускаем количественные исследования на данных из интервью.
6. Стартапы могут сразу брать гипотезы из интервью в работу, чтобы быстро и дешево проверять их. Крупным продуктам лучше сначала проверить гипотезы количественными методами. 

Дополнительные материалы

• Блог Контура на Medium об исследованиях
• КонтурГайды для проектировщиков и исследователей 
• Подкаст make sense о поиске респондентов для исследований — способы, каналы, инструменты и ошибки рекрутинга
• FISH: простой фреймворк анализа интервью для продакт-менеджера
• Гайд: как подготовиться к глубинным интервью и провести их максимально эффективно
• Как научить разработчиков и продуктовую команду понимать пользователей и проводить интервью
• Как искать контакты топ-менеджеров из энтерпрайза для CustDev и выходить на них
• ЛПР для исследований в малом и микробизнесе: кто они, где их искать и как на них выйти
• Где хранить результаты исследований и по каким принципам организовать базу инсайтов?
• Interviewing Users: How to Uncover Compelling Insights
• Как проверять гипотезы с помощью проблемных интервью: пошаговая инструкция
• Восемь типов ошибок в глубинных интервью
• Интервью. Как провести глубинное исследование и выявить потребности пользователей
• «Распаковка» интервью и юзабилити-тестов: как ускориться, не потеряв в качестве
• Фиксируем результаты UX-тестирования интерфейса на бегу: экономим время и обходимся без объемных документов