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

Исследования на каждый чих и просто ради исследований — признак некомпетентности. Не прикрывайте ими незнание базовых паттернов и законов восприятия. 

Если всё же вопрос не решается гуглением и, простигосподи, ChatGPT, а на кону стоит прибыль и количество пользователей (клиентов) — сформулируйте гипотезы. 

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

Неважно, какой метод исследований вы дальше выберете. 

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

Например: Пользователи не хранят версии шаблонов документов. 

Или: Пользователям неочевидно, как оставить комментарий к заявке. 

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

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

Если вы хотите больше узнать об опыте и проблемах, которые уже, по-вашему, существуют — это интервью. 

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

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

Если нужно понять, удобное решение вы спроектировали или нет — юзабилити-тестирование. 

Про выбор метода тоже напишу отдельно. 

Коротко — сначала гипотезы, потом выбор метода. 

Если уместно (то есть практически всегда) — готовьте материалы к исслеованиям. 

Если это опрос — анкету. 

Если интервью — скрипт вопросов. Да, даже если это глубинное интервью. Обязательно. Причём такие вопросы, которые позволят проверить ваши гипотезы. Иначе зачем вы их формулировали? 

Если юзабилити-тест — легенду, сценарий (задания, которые должен будет выполнить респондент) и прототип. На проде / бете / другом стенде лучше не проверять. 

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

Можно параллельно с предыдущим шагом. 

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

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

Если вы хотите провести опрос, зовите только потенциальных клиентов / пользователей (здравствуйте, персоны и портрет ЦА в целом). Не надо звать на приложение для ветеринарной телемедицины тех, у кого никогда не было питомцев. Для этого нужно внимательно квалифицировать респондентов и отсеивать тех, кто всё же попал случайно. 

Если планируете наблюдение — согласуйте все детали, их много. Что вы будете фоткать / записывать видео, что будете сидеть за спиной человека несколько часов, что будете приглашать к беседе, если понадобится. Особенно, если ваши пользователи сидят на режимном объекте.

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

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

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

CJM

User Stories

Job Stories

Персоны 

Не из головы, а точно со слов респондентов. 

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

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

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

Поэтому расставляем приоритеты (о методах в другой раз) и берём в работу. 

Продакт (валидирует приоритет проблемы и даёт добро на реализацию решения)  >

Аналитик (если есть, прорабатывает все требования и корнер-кейсы, декомпозирует задачу, чтобы разработка не утонула в итерациях) >

Дизайнер (прорабатывает решение) >

Разработчики и QA (реализуют и делают так, чтобы на прод не попало г**но?) >

Релиз (если функция важная / крупная — с сопровождением маркетинга). 

Проводятся не всегда. 

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

Но после опроса можно углубиться в тему и провести проблемные интервью. 

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

Всё зависит от конкретной задачи и целей продукта. 

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

Например, конкурентный анализ + интервью 

Или Вебвизор для валидации интерфейсных проблем + юзабилити-тест после доработок 

Потому что в долгосрочной перспективе экономит время разработчиков (как правило, один из самых дорогих ресурсов) и количество попыток заработать на продукте / функции — ведь вы заранее знаете, за решение какой конкретно проблемы вам заплатят.