Как выстроить взаимодействие в продукте с разными исследователями

Привет! меня зовут Лера, я исследователь в UX-лаборатории Контура.

Не так давно я рассказывала о разных форматах работы UXlab, одним из которых было выстраивание UX-процессов в продукте — то есть постоянная работа в проекте, которому мы можем уделять до 50% своего времени.

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

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

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

Проблемы:

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

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

Инструменты, которые помогли в их решении:

• Создание отдельного пространства на Wiki для каждого из направления исследований.

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

Проблемы:

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

Инструменты, которые помогли в их решении:

• Создание общего бэклога задач

Поскольку продукт находится на стадии стартапа, многие задачи связаны с выявлением потребности пользователя в конкретных фичах. Проверка таких гипотез может быть компетенцией разных исследователей: как CX, так и UX. Чтобы исследования не дублировались, было решено завести общий бэклог задач. Так появилась доска в Youtrack, где, помимо бэклога, мы заводили карточку для каждой задачи, не забывая прикладывать все необходимые артефакты. Это помогало понять, чем занят каждый из исследователей в данный момент, и когда именно он закончит работу.

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

• Общее хранение исследований

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

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

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

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

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

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

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