UX-исследования могут проводиться при участии модератора, который даёт респонденту задания, либо без него — с помощью различных специальных платформ. Исследования второго типа называются немодерируемыми.
Для UX-дизайнера плюсы немодерируемых тестов очевидны. Это быстрый — результаты можно получить за считанные часы, — недорогой и легко масштабируемый способ проверить решения. При этом у него есть существенный минус: невозможность скорректировать что-либо в процессе. К примеру, если мы узнаём об ошибках в ходе модерируемого исследования, то можем поправить гайд и быстро взять правильный курс. Немодерируемые тесты обладают меньшей гибкостью: как правило, если мы ошиблись в начале, то и результат будет некорректным. Именно поэтому к проведению таких тестов стоит относиться с особым вниманием, тщательно прорабатывая их содержание.
Ниже рассказываем о том, как минимизировать проблемы при проведении немодерируемых тестов, на примерах из рабочей практики.
Привет, Хабр! Я Кирилл Улитин, в МойОфис руковожу направлением UX&Research. За 10 лет в профессии я опробовал большинство платформ для проведения немодерируемых исследований. Только в 2023 году мы с коллегами провели порядка 40 тестов, совершенствуя пользовательский опыт в различных продуктах МойОфис.
В сентябре я выступил на конференции ProductSense'23, где рассказал о том, как избежать факапов в немодерируемых тестах. Теперь же по мотивам доклада подготовил хабр-статью.
Вот мои 6 советов для успешного проведения немодерируемых исследований.
1. Формулируйте задания без подсказок
После того, как у нас подготовлен прототип для тестирования, мы начинаем формулировать задание для респондентов. Иногда формулировка сильно влияет на их ответы: например, слишком директивное задание может спровоцировать попытку решить задачу в лоб, респондент будет пытаться найти в интерфейсе слова или образы из задания и пытаться взаимодействовать с ними.
Когда мы работали с прототипом Squadus, продукта для делового общения, то столкнулись с похожей проблемой. Вместе с Артемом Сексяевым (@avsxvii) мы тестировали сценарий создания ссылки, по которой коллеги могут присоединиться к встрече.
Создать нужную сущность в прототипе можно было с помощью большой красной кнопки «Плюс», нашего нового элемента интерфейса. Мы проверяли, насколько такая механика понятна для респондентов. В первом тесте сквозную кнопку участники упорно не замечали, и мы начали экспериментировать с формулировками, пытаясь выяснить, в чём может быть дело.
Ниже на графике показаны результаты для разных формулировок задания:
Результаты показали: определённые слова в задании подталкивают респондента к взаимодействию с тем или иным элементом в интерфейсе. Первые две формулировки включали в себя слова «конференция» и «созвон», и большинство респондентов искали нужную функцию в разделе «Конференции». В третьем же тесте большинство участников искали функцию в блоке чата — надеясь, что одна из иконок верхнего правого меню поможет получить им ссылку.
Вот как выглядела карта кликов:
В нашем кейсе можно было бы и полностью отказаться от использования задания с упоминанием функции. То есть включить задание в сам интерфейс: «Куда бы вы нажали, чтобы дополнить ваше сообщение недостающей информацией».
Есть вероятность, что такая постановка задачи могла бы лучше проявить возможности нашего интерфейса при работе пользователей с прототипом.
Что касается финальной реализации функции, с учётом дополнительных проверок и анализа мы решили оставить несколько точек входа. Помимо красной сквозной кнопки, создавать объекты в Squadus, характерные для раздела конференций, можно в блоке с его названием.
Вывод: при формулировании заданий нужно тщательно подбирать слова, чтобы они не ассоциировались напрямую c элементами интерфейса. Лучше всего ставить пользователя в конкретную ситуацию и акцентировать его внимание на задаче.
2. Никогда не используйте только тест предпочтений
Причина проста: если пользователь выбирает один из вариантов дизайна, исходя из своих предпочтений, нет никаких гарантий, что выбранный вариант окажется эффективным непосредственно в работе.
В случае с продуктом «МойОфис Таблица» нам с коллегой Ильей Сафроновым требовалось определить, где располагать иконку с изображением замка, обозначающую защищённый лист — слева или справа.
Большинство респондентов отдали предпочтение варианту «слева». Хотя вариант «справа» оказался более эффективен по таким показателям, как количество сделанных кликов, временные затраты и оценка заметности. То есть пользователи выбирали привычный для себя вариант, несмотря на то, что альтернатива была удобнее.
Вывод: никогда не стоит использовать тест предпочтений как моно-инструмент. Его важно совмещать с тестами, направленными на определение эффективных метрик.
3. Меняйте варианты местами
При первом прохождении теста пользователи обычно дольше разбираются с тем, как выполнять задание. Это специфика всех немодерируемых тестов: респондентам бывает сложно понять задачу, особенно если мы тестируем не особо ходовые «жизненные» сценарии. Поэтому первое взаимодействие с прототипом обычно занимает больше всего времени. Во второй раз пользователи уже понимают суть задачи; если же вариантов у нас больше, то третья итерация проходит ещё успешнее. Именно поэтому важна случайность или деление выборки на n-подтестов.
Если мы не меняем варианты местами, то фактически нарушаем методологию и получаем некорректные результаты.
Рассмотрим кейс с нашим продуктом «МойОфис Почта»: нам нужно было понять, как реализовать возможность открыть календарь в письме о событии. Потенциальных варианта было три: сделать кнопку с текстом, расположить её слева или расположить её справа. Варианты мы тестировали как по предпочтению, так и по метрикам эффективности.
В результатах мы видим, что когда вариант с расположением кнопки справа показывался в тесте первым, пользователи тратили на выполнение задания внушительные 16 секунд. При этом когда он выводился последним, респонденты тратили на задание столько же времени, как и при других вариантах, поскольку уже запомнили образ иконки и поняли смысл теста. Таким образом, если бы мы не сделали ротацию — например, вариант с кнопкой справа выводился бы только последним, — то не заметили бы проблему.
Интересно, что в результатах иногда можно увидеть респондентов, у которых нет положительной динамики после прохождения задания в первом варианте — то есть они одинаково долго проходят первый, второй и все последующие варианты. Возможно, они пытаются механически брутфорсить прототипы, не читая задание, или впали в «дисфункциональное» состояние, затрудняющее прохождение теста. Тогда для большей достоверности результаты таких респондентов можно отсеять.
Вывод: если в рамках исследования в одном тесте мы тестируем несколько вариантов решений, то должны обеспечить их ротацию. Случайным образом менять варианты местами или делить выборку на несколько подтестов: например, чтобы первый вариант показывался первым и второй вариант вторым, а в другом подтесте — наоборот.
4. Один вариант — одно отличие
Иногда мы хотим протестировать все возможные отличия в вариантах решения — это в корне неверно.
Вернемся к предыдущему примеру с кнопкой «перейти в календарь». После анализа результатов, в тесте предпочтения мы получили двух финалистов: иконку с текстом и иконку справа.
Проблема в том, что по данным исследования эффективности, если кнопка располагается справа, респонденты тратят больше всего времени на её поиск. Почему же люди выбирают этот вариант в тесте предпочтений, учитывая, что тратят на него 16 секунд?
Это мы прояснили с помощью дополнительных вопросов в повторном исследовании. Получилось вот что: первый вариант, иконку с текстом, люди назвали «понятным, заметным, информативным». Вариант с иконкой справа они охарактеризовали так: «симпатично, проще, иконки лучше видно». Получается, что тестировали мы в первую очередь расположение кнопок и их текстовое наполнение, но отличались кнопки еще и дизайном: людям больше нравилась определённая иконка и поэтому они выбирали её. То есть появилась новая переменная, которая обратила на себя внимание и повлияла на предпочтение. Это вдогонку ко второму примеру о том, что предпочтение не стоит рассматривать в отрыве от фактических метрик. В данном случае потребовалось добавить к тесту простой открытый вопрос, чтобы понять, какие факторы повлияли на выбор. В результате кнопки в тестируемых интерфейсах мы сделали одинаковыми, сохранив лишь разницу в их положении, и провели тест заново.
Вывод: для максимально корректных результатов мы должны сравнивать варианты только по одному отличию — иначе будет непонятно, какое именно изменение повлияло на результаты. В случае, если переменных-отличий несколько, их нужно протестировать раздельно.
5. Избавьтесь от броских отвлекающих элементов
При разработке нового редактора презентаций мы хотели понять, как сделать окно с информированием о новой функции — выделении объектов на слайде в режиме демонстрации. Нюанс в том, что функция была абсолютно уникальной, и мой коллега Сергей Кривуля решил сделать анимацию, чтобы лучше объяснить пользователям её работу. Результаты показали следующее: все респонденты кликали не на сам тултип, а на анимацию, которая располагалась в блоке с тултипом. Это было совершенно нерационально. Ведь задача респондентов в этом тесте — скорее закрыть тултип и перейти к презентации; они же кликали непосредственно анимацию.
Мы провели несколько итераций, меняли и дизайн окна, и варианты задания, но люди упорно кликали анимацию. В одном из финальных тестов мы добавили вопрос для респондентов: почему они поступают именно так? Пользователи ответили: анимация их настолько завлекала, что они связывали её непосредственно с заданием и думали, что если с ней взаимодействовать, то «пазл сложится и баннер исчезнет».
Вывод: если в прототипе есть какой-то броский отвлекающий элемент, стоит заменить его, чтобы протестировать то, что нам нужно. В нашем примере — заменить анимацию на статику или вообще её убрать и оставить заглушку. Мы подбираем тестируемые материалы под наши гипотезы. Они не всегда должны соответствовать тому, что увидит пользователь в конечном продукте.
6. Обманите кликеров
Кликеры — это люди, которые вместо того, чтобы вникнуть в задание, начинают брутфорсить прототип: находить любые интерактивные элементы и сразу с ними взаимодействовать.
Такие пользователи могут сильно повлиять на результат. Они не думают, а просто пытаются пройти прототип, как некую игру. В результате их поведения мы видим очень большое количество кликов.
Основная опасность в том, что если в прототипе только один кликабельный элемент, который продолжает путь пользователя, то изменение курсора позволяет решить задачу: даже не совершая клики, а просто водя курсор по прототипу до тех пор, пока курсор не изменит свой вид.
К счастью, в мобильных тестах это не проявляется, поскольку там нет подсказки в виде курсора.
Есть 3 основных способа борьбы с «кликерами»:
Во-первых, можно добавить в прототип больше интерактивных элементов. В Figma, например, есть возможность сделать клик, который ведёт «в никуда».
Во-вторых, если мы используем сервис Pathway, то там по моей просьбе появилась специальная функция, которая позволяет зафиксировать курсор, чтобы он не менялся.
И третий вариант, который мы придумали с Ильей Сафроновым — это добавить переход на промежуточный экран, на элементы, которые не участвуют в тестируемом сценарии. Это позволяет отфильтровать ситуации, когда респондент кликает не туда, и увидеть, какое количество людей не справилось с заданием с первого раза. Решение с промежуточным экраном позволяет затормозить кликеров. Мы снова показываем им задание. У них появляется возможность его осознать и попробовать снова. Также это отучает кликать, не думая.
Вывод: В отличие от модерируемых тестов, где мы присутствуем рядом с респондентом и можем уточнять его поведение, в немодерируемых тестах такой возможности нет. Поэтому стоит предусматривать все ситуации, которые могут происходить в тесте, в том числе, связанные с нерациональным поведением людей.
7. Постскриптум
Как пишут авторы книги «Полный бред» Карл Бэргстром и Джевин Уэст: «Чушь — это слова, статистические данные, графики и другие формы презентации, цель которых — убедить или впечатлить слушателей, отвлекая, ошеломляя или подавляя их откровенным презрением к истине, логической связанности или сути той информации, которая передается в действительности».
Низкий порог входа в проведение тестов и обилие доступных платформ провоцируют поступление всё новой «чуши», которая может повлиять на нас, продукт, и в конечном счёте людей, которые будут им пользоваться.
К сожалению, здесь нет «серебряной пули». В МойОфис мы развиваем центр экспертизы по исследованиям, где в обязательном порядке проводим ревью каждого теста: сначала экспертом, а потом всей командой, отправляя тест на пилотный запуск в общий чат.
Я надеюсь, эта статья поможет вам разобраться с частыми ошибками в немодерируемых тестах, чтобы проводить такие тесты максимально эффективно. Даже если вы не проводите тесты сами, а только работаете с их результатами, теперь вы сможете проверить их корректность — и понять, насколько правильно были проведены исследования.
Все советы из моей статьи доступны в формате шпаргалки:
Вы можете скачать ее в pdf, либо открыть в Telegram в виде карточек.
