Магия вне Хогвартса: как провести исследование, если нет исследователя

Illustration by Maria Shukshina from Icons8

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

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

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

Как мы пришли к этому

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

На встрече поняли, что у нас есть несколько вариантов: ждать и получить результаты на полторы недели позже, делать что-то без исследования (ну нет! :)) или найти ресурс на проведение исследования в другом месте. В итоге решили, что команда сама проведет проблемное интервью.

Рассказывает Эмилия (UX-исследователь)

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

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

Но команда как-то легко согласилась, и осталось только выбрать, кто именно будет проводить исследование. Предложила выбрать того, кто:

1. Сам хочет прокачаться в исследованиях. Кому интересно самостоятельно провести проблемное интервью и проанализировать информацию.

2. Кто в теме задачи, кого не нужно будет погружать в контекст.

3. Знает, что нужно узнать и зачем.

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

Рассказывает Настя (проектировщик)

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

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

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

Общий контекст взаимодействия

Illustration by Ivan Haidutski from Icons8

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

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

2. Распределить зоны ответственности:

  • Проектировщик-исследователь проводила всё исследование (скрипт, рекрут, проведение и анализ интервью) и работала с результатами.
  • Исследователь-наставник была ответственна за ревью и обратную связь на каждом этапе, обучение нюансам и особенностям проведения.

3. Договориться о формате и схеме взаимодействия:

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

Рассказывает Эмилия (исследователь-наставник)

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

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

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

Рассказывает Настя (проектировщик-исследователь)

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

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

Подготовка к интервью

Illustration by Ivan Haidutski from Icons8

Состояла из 3 этапов:

  1. Структурировать гипотезы и вопросы. Команда сформулировала гипотезы и вопросы, на которые нет ответов. Чтобы работать с ними дальше, нужно было их сгруппировать и разнести по этапам сценария пользователя.
  2. Составить скрипт для интервью. Берем наши гипотезы и продумываем вопросы к пользователям. Нормально, если несколько гипотез закрывает всего один вопрос. Вопросы должны быть открытыми и понятными для пользователей, помогать проверить, а не подтвердить гипотезу.
  3. Составить скрипт для рекрута. В нем важно рассказать цель общения и мотивацию для пользователя.

Рассказывает Настя (проектировщик-исследователь)

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

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

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

Скрипт нашего исследования →

Проведение интервью

Illustration by Ivan Haidutski from Icons8

Рассказывает Настя (проектировщик-исследователь)

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

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

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

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

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

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

Обработка и презентация результатов

Illustration by Ivan Haidutski from Icons8

Состояла из 5 этапов:

  1. Транскрипт интервью. Заполнение подробной таблицы с информацией, полученной в интервью.
  2. Анализ результатов. Выделить факты для каждого этапа сценария.
  3. Выделение сложностей в сценарии и формулировка рекомендаций. Выделить проблемы, на которые нужно обратить внимание. На этом этапе еще не оперируем решениями.
  4. Презентация результатов команде.
  5. Обозначить следующие шаги. Например, варианты решения. Выносится за рамки исследования, помогает команде понять, как применить результаты исследования.

Рассказывает Настя (проектировщик-исследователь)

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

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

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

Исследование занимало много времени и ресурса. В конце уже немного устаешь, взгляд замыливается. Мне помогала сфокусироваться мысль, что цель всего исследования — получить результат и донести его пользу до команды.

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

Выводы

  1. Это был очень классный опыт. Время мы не особо сэкономили, но точно сэкономим его в будущем. Теперь проектировщик может смотреть на задачу как исследователь. Задавать «правильные» вопросы себе и команде, формулировать более грамотные запросы на исследования и проверять небольшие гипотезы самим. Это особенно полезно для команд с ограниченным ресурсом UX-исследователя.
  2. Проектировщику нужно быть готовым к самостоятельной работе и погружению в исследование в новой роли. Здесь не сработает подход «Дайте мне скрипт, я сам попробую позвонить» — важно быть исследователем на всех этапах.
  3. Перед началом исследования проектировщику важно спланировать время так, чтобы были ресурсы на проведение исследования. Предупредить команду, оставить только небольшие задачи на проектирование.

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

Illustration by Maria Shukshina from Icons8

--

--