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