Семь приемов написания сценариев тестирования юзабилити

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

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

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

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

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

   Поскольку пользователи могут начать поиск с общей идеи некоего кухонного предмета, такая цель, основанная на общих предположениях о цене, качестве и характере отзывов, позволит им быстро сузить область поиска. В искусственном мире тестирования юзабилити пользователи будут часто сталкиваться с проблемами, если вы задаете слишком расплывчатые цели, и попытаются узнать у модератора (если он есть), что именно им нужно найти. Стремитесь к четкости при постановке задач, не заставляйте пользователей гадать что именно вы от них хотите. Хороший пример: «В бостонском аэропорту вам нужно снять автомобиль среднего размера на период с 10 утра 21 июля до полудня 23 июля».

2. Не говорите, где нажимать и что делать: Хотя пользователю нужно достаточно много информации, не вмешивайтесь в процесс выполнения задания на каждом шаге. Чересчур подробные указания приведут к предвзятым и неточным результатам. Например, вместо того, чтобы говорить «Нажмите на маленькую панель выбора внизу экрана для того, чтобы добавить GPS» просто скажите «Добавьте GPS к выбранной машине».
3. Говорите на языке пользователя, не компании: Существует распространенная ошибка проецировать внутреннюю корпоративную структуру на навигацию вебсайта. Не менее пагубная практика – просить участников тестирования выполнить задачи, сформулированные на внутреннем корпоративном жаргоне или с использованием специфических терминов. Если пользователи их не знают, это может привести к неверной трактовке ими результатов или полному непониманию задания. Используют ли пользователи термин «активы», когда говорят о денежных средствах, выделяемых на учебу ребенка? Знает ли сторонний пользователь о «конфигураторе» продукта или о «мега меню»?
4. Не давайте нерешаемых задач: если вы попросите пользователя найти ближайший к отелю пункт проката машин, таковой действительно должен быть. Это упрощает пользователю задачу и позволяет вам легче определять, было ли задание выполнено успешно. Проблема задания «Найдите продукт, подходящий вам» заключается в том, что участники ориентированы на решение конкретной задачи. Во время выполнения пользователями задания, продукта, подходящего им, может и не быть в наличии, но участники теста гораздо больше заинтересованы в его завершении и получении вознаграждения. Такая заинтересованность может привести к ложному впечатлению, что выбор любого продукта будет верным и несоразмерно увеличить базовые метрики, такие как уровень успешности выполнения задания.
5. По возможности не делайте задачи взаимозависимыми: Важно менять порядок выполнения задач, поскольку пользователь быстро учится выполнять определенные последовательности действий. Если ваши задачи взаимозависимы (например, «создайте файл» в одном задании и «удалите созданный файл» – в другом), то пользователь, провалив одно задание, с большой вероятностью не выполнит и второе. Сделайте все возможное для того, чтобы избежать зависимостей (предложите другой файл для удаления). Это не всегда возможно, в случае, например, если вы тестируете процесс установки ПО, но старайтесь быть в курсе последствий введения зависимых задач: как облегчающих выполнение задания, так и усложняющих его.
6. Давайте сопроводительную информацию, но будьте кратки: Вам нужно дать такую информацию, чтобы пользователь считал себя по-настоящему заинтересованным в выполнении задания. Но не перебарщивайте с деталями. Например, «Вам нужно посетить конференцию в Бостоне в июле и снять на это время машину».
7. Сценарии должны различаться для модерируемого и немодерируемого тестирования: Искусство написания сценариев тестирования оттачивалось годами в основном за счет модерируемых лабораторных тестов. Однако, если вы проводите немодерируемое тестирование юзабилити, это требует повышения уровня точности задания. Вы не можете полагаться на модератора, который будет направлять пользователей и узнавать их ожидания.

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

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