Почему пользователи врут на интервью и что мы увидели, когда начали за ними наблюдать

Пользователи почти никогда не рассказывают, как на самом деле работают с продуктом. Не потому, что не хотят, а потому, что не могут: забывают ^[1] половину действий, упрощают сценарии и автоматически «исправляют» свой опыт ^[2] так, чтобы он выглядел логичнее.

Мы — Кирилл Улитин @ulitin ^[3], руководитель UX-направления и исследований в департаменте дизайна МойОфис, и Стася Кабанова, исследователь пользовательского взаимодействия в МойОфис. В компании есть целая экосистема офисных решений на разных платформах, поэтому пользовательские сценарии здесь исследуют регулярно и обычно опираются на привычные методы: глубинные интервью и usability-тестирования.

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

---

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

Во-первых, у пользователя есть ограничения внимания ^[5]. Многие микровзаимодействия человек просто не замечает. Какие-то действия он пропускает в описании, а какие-то воспроизводит неточно. Нам в целом довольно трудно объяснять, как именно мы что-то делаем, особенно если речь идет о сложном, хорошо автоматизированном навыке.

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

В-третьих, на память ^[6] в таких случаях сложно опираться: неинтересные детали быстро забываются или вытесняются. Если человек вспоминает не один конкретный эпизод, но целую серию похожих событий, то чаще всего он описывает уже не реальный опыт, а его обобщенную версию.

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

Когда становится понятно что интервью и тестирований недостаточно, возникает закономерный вопрос…

…как тогда изучать такой опыт?

Один из очевидных вариантов — наблюдение. Например, наши коллеги из команды десктоп-редакторов выезжают на обучение ^[7] пользователей работе с продуктом и могут вживую увидеть сценарий первого знакомства с системой. С одной стороны, люди проходят обучение, с другой — впервые взаимодействуют с офисными редакторами и почтовыми приложениями. Для исследователя это хорошая возможность посмотреть, как именно разворачивается этот опыт, и зафиксировать возникающие трудности.

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

Еще один вариант — дневниковые исследования, тоже дорогой метод. Он требует длительного вовлечения и со стороны исследователя, и со стороны участников, а значит, быстро масштабировать его трудно. Исследователь регулярно возвращается к респонденту через равные промежутки времени и постепенно собирает большой массив данных о том, как меняется поведение ^[8], отношение и контекст использования. Впервые этот метод в нашей компании мы применили только в прошлом году при тестировании MVP новых продуктов.

Есть и более технологичный подход — цифровая этнография. Например, в исследованиях лаборатории скриномики в Стенфорде ^[9], на смартфоны участников устанавливают приложение, которое записывает пользовательскую активность и отправляет данные на сервер. Затем исследователь может анализировать весь цифровой опыт: как человек перемещается между приложениями, где переключается между задачами, в какой последовательности действует. Если смотреть на отдельную пользовательскую сессию, можно буквально восстановить все, что происходило, и получить богатый материал для анализа.

Но и здесь есть ограничения. Во-первых, нужна техническая возможность собрать такие данные. Во-вторых, этот подход очень чувствителен с точки зрения ^[10] приватности. Для некоторых задач он действительно может быть полезен, но, например, в нашем случае такой уровень вмешательства в пользовательский опыт просто недопустим.

В итоге мы остановились на еще одном варианте — контекстном интервью.

Это авторский метод, разработанный Карен Хольцблатт и описанный в книге Contextual Design ^[11]. О нем также есть хорошие материалы ^[12] у Nielsen Norman Group, а на русском языке — у «Собаки Павлова» ^[13].

Что это за метод и чем он отличается от обычного интервью

Чтобы ответить на этот вопрос, полезно посмотреть на его структуру.

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

Дальше происходит важный переход. Исследователь объясняет, что теперь его задача не только слушать рассказ, но и смотреть, как человек взаимодействует с реальной системой: как именно он выполняет задачи в живом продукте, на что обращает внимание, где замедляется, где действует автоматически, а где сталкивается с трудностями.

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

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

Особенно хорошо этот метод работает для регулярно повторяющихся задач. Например, когда оператор раз за разом обрабатывает однотипные заявки, выполняя последовательность хорошо знакомых действий. В таких сценариях контекстное интервью помогает увидеть не только формальный порядок работы, но и реальные паттерны поведения ^[14]: где человек срезает путь, где перепроверяет себя, где опирается на привычку, а где компенсирует неудобство интерфейса.

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

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

Изучение контекста использования контекстного интервью

Прежде чем запускать пилот, мы решили посмотреть, как этот метод применяли другие исследователи. В процессе наткнулись на статью ^[15] датского университета, где с помощью контекстного интервью изучали организацию персональной информации на смартфоне. Оттуда мы взяли несколько полезных практических приемов — о них расскажу ниже.

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

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

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

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

При этом именно контекст был для нас главным предметом исследования. Нам было важно уйти от ретроспективного рассказа в духе «сначала я открываю это, потом делаю то». Нас интересовало, как человек реально взаимодействует с программами в моменте: куда нажимает, какими приложениями пользуется, как фиксирует информацию, какие эмоции ^[16] испытывает, с кем общается по ходу задачи и зачем.

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

Именно контекст помогает выводить интервью за пределы ожидаемых сценариев и обнаруживать вещи, о которых исследователь вряд ли догадался бы заранее. Например, один из наших сотрудников, чтобы оформить пропуск, должен был получить фотографию, которая хранилась только в Bitrix. Чтобы скачать ее, он открывал инструменты разработчика и буквально вытаскивал изображение через код. У другого коллеги мы увидели совершенно иной паттерн: он выстраивал окна программ на экране как дашборд, собирая собственную рабочую среду из нескольких приложений сразу. Для нас это были очень показательные примеры нетипичного, но устойчивого пользовательского поведения.

Здесь уже хорошо виден главный эффект метода: он помогает находить не просто «боли» в интерфейсе, а реальные пользовательские практики — в том числе обходные, неочевидные и очень изобретательные.

Практические лайфхаки

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

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

Второе — о формате нужно предупреждать заранее. Наши коллеги часто участвуют в исследованиях, потому что пользуются продуктами МойОфис, и поэтому привыкли к классическим интервью. Многие ожидали обычную беседу, а в реальности оказалось, что нужно не только отвечать на вопросы, но и показывать экран, рассказывать о своем рабочем пространстве и демонстрировать привычные действия. По обратной связи стало понятно, что лучше заранее объяснять формат и ожидания: что именно может понадобиться показать, какие материалы подготовить и что при желании можно скрыть заранее.

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

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

Как вести такое интервью

В литературе эта модель часто описывается как формат «учитель — ученик». Респондент в этом случае выступает в роли учителя, а исследователь в роли ученика. Пользователь показывает, как устроена его работа, а исследователь старается понять логику ^[17] его действий, не притворяясь экспертом там, где он им не является.

В нашем случае это выглядело примерно так: «С чего начался твой день?», «Покажи, чем ты сегодня занимался», «Как ты обычно решаешь такую задачу?». Здесь важны не только заранее заготовленные вопросы, но и живая беседа по ходу наблюдения. Если что-то непонятно, лучше сразу уточнять, а не пытаться достроить смысл самостоятельно.

Следующий важный шаг — проверка собственной интерпретации. После наблюдения исследователь может проговорить, как он понял увиденное: например, «Правильно ли я понял, что ты обычно делаешь это вот так, а потом переходишь сюда?» В ответ можно получить либо подтверждение, либо корректировку. Это важная часть метода: недостаточно просто поговорить, что-то записать и разойтись. Нужно еще убедиться, что исследователь и респондент действительно одинаково понимают происходящее.

Как мы обрабатывали результаты

В результате у нас накопилось много разрозненных наблюдений, поэтому для обработки мы использовали affinity diagram — диаграмму сходства. Она позволяет вынести отдельные наблюдения на стикеры, а затем группировать их по темам, паттернам и повторяющимся мотивам.

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

Что в итоге показал метод

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

При этом лучше всего контекстное интервью работает там, где есть повторяющаяся деятельность. Именно так оно и описывается в литературе. Если же исследовательский фокус слишком широкий и размытый, например, «использование офисного ПО вообще», то возникают сложности. Не все респонденты готовы прямо сейчас показать реальную рабочую задачу, а подбор людей под конкретный сценарий может потребовать слишком много ресурсов.

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

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

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

Когда метод не нужен и в чем его ограничения

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

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

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

На наш взгляд, метод вполне применим и к MVP при одном важном условии: если в системе уже есть реальный пользовательский контент и пользователь действительно может решать в ней свои задачи. Даже если сценарии пока реализованы неидеально, именно в таком формате контекстное интервью позволяет увидеть несовершенства продукта на живых примерах. Более того, пользователь может показать не только саму проблему, но и то, как он ее обходит. Иногда именно такие обходные практики оказываются самым ценным результатом исследования. Так, в одном из наших наблюдений респондент показывал недавнюю рабочую задачу, и в этот момент у него уже были открыты devtools: только так он мог достать фотографию из системы, где интерфейс перекрывал стандартную возможность скачать изображение.

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

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

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

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

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

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

В заключение

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