Как реагировать на скептицизм при тестировании небольших групп пользователей

Подготовка заинтересованных сторон с упреждающим объяснением

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

Подготовьте заинтересованные стороны к неожиданным результатам, объяснив:

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

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

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

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

Слушание — это вера

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

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

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

Рассмотрение возражений о том, что участники не являются представителями

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

Тест с реальными пользователями

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

Получить бай-ин в профилях пользователей перед набором

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

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

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

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

Правда в том, что, по крайней мере, два человека борются с одной и той же проблемой, вселяет большую уверенность в обоснованности этой проблемы. Но это не значит, что вы должны сбрасывать со счетов проблемы, с которыми столкнулся только один участник. (Статистически, нет большой разницы между 1-из-5 и 2-из-5 с точки зрения доверительных интервалов.) Вместо этого соберите больше информации, чтобы лучше объяснить контекст этого единственного экземпляра .

Анализ результатов от одного пользователя

Когда проблема возникает только у одного участника теста, сначала рассмотрите следующее:

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

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

Проверка независимых источников данных для оценки частоты

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

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

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

Сравнение наблюдений за тестами с теорией юзабилити

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

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

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

Кроме того, соотнесение ваших тестовых наблюдений с основами внешне подтвержденных знаний UX может быть полезным способом объяснить свои выводы своей команде. Дайте понять, что проблема заключается не только в вас, но и в том, что многие другие обнаружили аналогичные проблемы при тестировании других проектов. И поставить имя для проблемы. Эта тактика поможет вам возразить против «крошечного образца» возражения.

Провести количественное тестирование юзабилити

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

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

Заключение

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