Если ты заказчик. Первый шаг перед исследованием.

В СКБ Контур есть UX-лаборатория, которая помогает проектам без своего исследователя внутри продукта. Вместе с командами мы лучше узнаем пользователей и проверяем продуктовые гипотезы. Когда к нам приходит заказчик, он заполняет чек-лист (ссылка на него будет в конце). После этого мы общаемся, разбираемся какие проблемы и задачи стоят перед командой, нужно ли вообще здесь исследование.

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

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

1. Понять, что нужно исследование

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

Чтобы разобраться с этим этапом, надо осознать лишь одну вещь.

Исследование — это инструмент. Не самоцель.

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

Индикаторы, что нужно исследование:

• Если есть вопросы про пользователей, на которые сейчас нет ответа (интуитивное знание не всегда считается). Ну например: «А как наши пользователи работают в системе? Что им удобно? Кто они?», «Кажется, люди не могут разобраться при первом входе, что делать? Как мы можем им помочь?», «Пользователи часто обращаются в техподдержку с этим вопросом. Что нужно починить, чтобы им стало хорошо?»
• Если есть вопросы про продукт или отдельные фичи: «Мы сделали решение, было ощущение, что будет полезно. Но почему-то им никто не пользуется. Почему так?», «Почему пользователи выбирают наш продукт? В каких задачах мы им помогаем, а где не оправдываем ожиданий?»
• На этапе аналитики уже понятно, что очень много вопросов про сценарии и про то, как это происходит в реальности; не уверены, что эта фича вообще нужна людям; понимаете, что это что-то совершенно новое и раньше в сервисе не было такого сценария.

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

2. Сформулировать, зачем нужно исследование

Поняли, что исследованию быть. Теперь важно понять — а зачем?

Есть вопросы-помощники:

• Чем поможет исследование продукту/команде?
• Какие знания нам нужны для дальнейшей работы?
• Какой будет следующий шаг (где хотим полученную информацию использовать)?

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

3. Сфокусироваться на нужной группе пользователей

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

Что поможет в этом:

• Понять, кто более всего задействован в исследуемом вопросе, у кого есть такой сценарий или появится в будущем. Какие пользователи сталкиваются с этим регулярно и могут рассказать про свой реальный опыт? Здесь могут помочь метрики, чтобы посмотреть, кто регулярно выполнял интересующие действия/работал в нужном разделе.
• Если исследуем потенциальных пользователей, то выборка здесь будет отчасти как гипотеза. Но суть остается той же — понять у кого, по нашему мнению, есть такая потребность и задачи.
• Выявить заинтересованных пользователей. Например, они уже обращались в техподдержку с проблемами в этом сценарии или просьбами по доработкам.
• Если это B2B сегмент, понять, какие нужны организации и почему именно они. Узнать их трафик, оборот, стадию жизненного цикла, отрасль, количество сотрудников и т.п. Роль, с которой нужно пообщаться: бухгалтер, директор, кладовщик, водитель.

4. Прописать все-все вопросы и сомнения (гипотезы) по выбранной проблеме

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

• Какие есть вопросы и сомнения про сценарии и работу пользователей в продукте? Сюда пишем все интуитивные знания, на которые опираемся, думая о решении. Все, в чем мы не уверены, а так ли это. Либо уверены, но фактов, подтверждающих это знание — нет.
• Какие есть предположения о проблемах? В интерфейсе, в сценариях пользователей и потенциальных пользователей, в продукте, в пути пользователя на разных его этапах (например: продажа, внедрение, регистрация, первые шаги в сервисе).

Ответы на эти вопросы помогут составить скрипт/гайд для исследования. Что-то из этих утверждений в ходе исследования может и не подтвердиться, быть не такими, как вы думали вначале. Это нормально и надо быть к этому готовым с самого начала. Ценность исследования — узнать новое и реальное, а не подтвердить то, что вы предполагали вначале.

5. Собрать всю имеющуюся информацию по проблеме

Вспомните, что уже знаете по исследуемому вопросу и проанализируйте эту информацию.

Где ее можно взять:

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

После анализа этих данных будет полезно снова посмотреть на свои сомнения и вопросы. Может на что-то вы уже нашли ответ или наоборот решите добавить новых вопросов. Это поможет не дублировать исследованием уже известные данные и позволит лучше погрузиться в контекст задачи.

6. Понять к какому сроку нужны результаты

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

Учитывайте, что скорость исследования зависит от нескольких факторов:

• Когда будет готова выборка для исследования с контактами пользователей.
• Когда будут готовы кликабельные прототипы, если предполагается юзабилити-тестирование.
• Сколько групп пользователей будет в исследовании.

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

Ну и бонус для тех кто дошел до конца. ⭐️

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