Хорошо исследовать недостаточно: чего продуктовая команда ждёт от UX-исследователя

Привет! Меня зовут Полина, и я UX-исследователь в Контур.Фокус.

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

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

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

_____

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

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

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

1. Исследовательская задача и продуктовая задача — не одно и то же

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

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

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

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

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

• Какую задачу сейчас решает команда?

• Какое решение ей предстоит принять?

• Кто именно будет его принимать?

• Какие знания действительно нужны для этого решения?

• Кто ещё должен быть вовлечён из других ролей?

• Что команда собирается делать с результатами?

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

Тогда в таком процессе появляются:

• Брифинги с командой не только для сбора гипотез, но и для совместного прояснения задачи.

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

• Фиксация бизнес-целей.

• Подключение к процессу других ролей.

• Обсуждение того, что именно команда будет делать с результатами.

2. Исследование не заканчивается на презентации результатов

Очень легко поставить мысленную точку после отчёта или презентации результатов. 

Респонденты найдены, данные собраны, анализ проведён, выводы сформулированы, вот и исследование завершено.

Методологически — да. Но с точки зрения продукта после этого начинается ещё один важный этап.

Вместе с командой нужно ответить на вопросы:

• Что мы узнали?

• Что это значит для нашей задачи?

• Что мы делаем дальше?

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

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

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

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

Не все сложности в работе с исследованиями связаны с работой исследователя. Важен и контекст команды.

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

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

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

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

Если команда раньше не работала с исследованиями, она может просто не знать:

• Когда подключать исследователя.

• Какую информацию ему дать.

• Какие вопросы можно решить исследованием.

• Как использовать результаты.

• Где заканчивается роль исследователя и начинается работа других ролей.

Это не повод закрываться внутри своей функции и ждать, когда команда «научится».

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

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

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

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

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

4. Исследователю важно смотреть шире своей функции

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

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

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

Подводя итог

Если вы нанимаете первого исследователя в команду

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

Поэтому:

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

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

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

Если вы приходите исследователем в новую команду

Не спешите брать первую гипотезу и сразу уходить в исследование.

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

А если что-то не получается — не обязательно разбираться в одиночку

Не бойтесь обращаться за помощью к более опытным коллегам или искать наставника.

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

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

И финальное

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

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

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

Больше интересного про UX-исследования в телеграм-канале «Сдоба»🥨