Co-creation в пользовательских исследованиях

Эта статья — совокупный опыт разных продуктовых команд СКБ Контура.

Я работаю UX-исследователем в СКБ Контуре. Недавно моя команда захотела пригласить пользователей, чтобы пообщаться и «‎поштурмить». Перед началом работы я решила узнать, какие еще бывают форматы взаимодействия с пользователями помимо классических UX-методов. Пообщавшись с исследователями из других команд, я познакомилась с подходом co-creation.

Сo-creation — создание фичи, продукта или его ценности разработчиками совместно с пользователями или другими заинтересованными людьми, например, партнерами.

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

Совместное прототипирование на бумаге

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

Команда сервиса Эльба в лице аналитика, проектировщика и UX-исследователя предложила пользователям совместно поработать над прототипом новой фичи.

Эльба — это сервис по формированию отчетности и первичной документации для предпринимателей.

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

Помимо работы с прототипом задавались вопросы про процессы, проблемы и сложности. Всего было 4 встречи длительностью чуть более часа.

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

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

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

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

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

Встречи команды и пользователей

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

UX-исследователь раз в 2 недели приглашал пользователей на встречи с разработкой. Они занимали около часа.

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

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

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

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

Собранные материалы, помимо очевидной ценности, превратились в пользовательские истории — контент для сайта продукта. UX-исследователь написал истории, которые, с согласия пользователей, были опубликованы в справочном разделе Диадока.

Бумажный CJM

Так же как и в бумажном прототипе, CJM на бумаге — лишь форма. Все атрибуты карты пути пользователя написаны или нарисованы от руки и могут редактироваться вместе с пользователем.

Для редизайна сервиса Декларант и поиска новых идей для позиционирования продукта, проектировщик и UX-исследователь пошли к пользователям.

Декларант — онлайн-сервис для таможенного декларирования.

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

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

Обобщим

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

• Это должна быть естественная потребность команды, участники должны быть мотивированы.
• До начала работы стоит изучить свою аудиторию и знать хотя бы основные сценарии (иметь экспертное представление или провести исследование заранее).
• Пользователи должны выполнять обсуждаемые задачи в реальной жизни и иметь опыт, чтобы вместе с командой его описывать.
• В таких активностях важен драйвер — человек, который будет разрабатывать полученные материалы в конкретные задачи.
• Co-creation отлично подходит для масштабных задач с высокой степенью неопределенности.

В процессе вы можете столкнуться с подводными камнями.

• Команда может стесняться или бояться выходить к пользователям. Для первого раза можно предложить роль наблюдателя или дать посмотреть записи с прошлых интервью и тестирований. Обычно первый блок общения с пользователями быстро проходит.
• После встреч остается множество идей, которые сложно обобщить. Пользователь не ограничен видением команды и рисует индивидуальную картину. Можно вместе с командной ранжировать инсайты и постепенно возвращаться к этому списку — для аналитики, «доисследования‎» или разработки.
• Результаты остаются не до конца проработаны, если их не драйвить. Часто поток рабочих задач снижает приоритет внедрения всех полученных идей. После встреч с пользователями остаются единичные пожелания, ведь такая работа более индивидуализирована и затрагивает большие отрезки сценариев. В текущем бэклоге может вообще не быть таких задач — нужно создавать новые и напоминать о них.

При этом совместная работа с пользователем имеет свои преимущества.

• Такой формат не требует масштабной подготовки. Не нужно тратить много времени проектировщика на прототип или детально прописывать список вопросов.
• Сценарий встречи более гибкий и легко подстраивается под пользователя и ход беседы.
• Вы сможете увидеть неочевидные проблемы пользователей.
• Меньше риск запрограммированных прототипом действий пользователя.
• Растет эмпатия и вовлеченность команды в пользовательский контекст.

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