Статья не является гайдом и «как правильно делать исследование». Исключительно мой рабочий кейс проведения интервью в продукте.

Метод использовался в процессе проектирования продукта Fraud Protection. Основное, что необходимо было понять – поведение пользователя.

Подготовка

Определял цель проведения интервью. Чаще всего, как я и писал выше, целью было выявить поведение и с какой болью сталкивается во время выполнения своей задачи пользователь. Необходимо было понять, с каким разделом ведётся работа: с реализованным интерфейсом или прототипом.

Проведение

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

«Как ты работаешь\создаёшь\определяешь <задача>?»

Респондент детально может описать:

• Процесс. Выделяются места, которые являются ведущими по решению задачи.
• Действия. Акцент на выполнение задачи.
• Важные детали. Любые аспекты, влияющие на решение задачи.

«Почему?»

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

Примеры:

• «Почему ты не используешь <функция>?»
  Потому что я не понимаю, как это использовать, и как это вообще может мне помочь.
• «Почему необходимо кликнуть <действие>?»
  Потому что данные необходимо обновлять вручную.

Мои примеры дают понять: добавить подсказки, онбординг, кнопку refresh, lazy-загрузку, падинги и т.д.

Детали

Если необходимо выявить особенности использования или отображение элементы, тогда задавал вопросы «Для чего тебе <элемент>?» (Здесь могло быть про визуализацию данных, периоды и т.д.). Каждый элемент, блок, компонент аргументированно используется, услышав детали, можно улучшить процесс, помочь пользователю ускорить решение задачи.

Ответ на верхний пример:
Мне необходимо в работе видеть сразу цикл или график за 30 дней, поэтому я обновляю, нажимаю фильтрацию по <дата>.

Если большой процент респондентов работает аналогично, есть понимание, что можно сделать: от “переработать функционал с данными” до “добавить какой-нибудь кнопки”. Если малый процент, то добавляешь короткий определённый функционал, который помогает этому незначительному проценту решить задачу. Игнорировать малую выборку = Игнорировать боль пользователя.

Итог

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

Избегать:

1. Риторические
2. Наводящие (Ты согласен, это лучшее решение, чем ранее?)
3. Закрытые вопросы (Нравится такой вид дашборда?)