Когнитивный обход

Когда использовать

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

От экспертной оценки по эвристикам его отличает фокус. Эвристики проверяют продукт целиком на соответствие принципам, а обход берёт одну задачу и смотрит на неё глазами новичка.

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

Что нужно для старта

• Описание пользователя. Какой у него опыт с похожими продуктами, что он знает о вашей области и что не знает. Хватит двух-трёх предложений
• От одной до четырёх задач, которые будете проходить. У каждой чёткое начало и конец. Хороший источник задач — список главных задач продукта
• Последовательность действий, которая приводит к цели, по шагам и без развилок. Без неё не к чему приложить вопросы
• Прототип, макеты или описание интерфейса с названиями кнопок и текстами. Достаточно того, что есть сейчас
• Ведущий, секретарь и оценщики. В оценке могут участвовать UX-специалисты, владельцы продукта, инженеры и эксперты по предметной области
• Форма записи в виде таблицы, где по строке на шаг

Как провести

1. Пользователь и задача

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

2. Последовательность действий

   Разбейте задачу на отдельные действия. Каждый клик, ввод и выбор — отдельный шаг. Для каждого запишите, что видит человек после правильного действия. Эту работу делает исследователь заранее и согласует с владельцами экранов, потому что на встрече править её нельзя.

3. Правила встречи

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

4. Проход по шагам

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

5. Запись

   Записывайте провалы коротко, как гипотезу о пользователе. «Человек может не заметить, что список можно изменить, потому что не знает, что он редактируется». Шаги без проблем не фиксируйте. Отдельно отмечайте идеи решений, пробелы в дизайне и ошибки в разборе задачи. Идею запишите одной строкой и возвращайтесь к шагам, не раскручивайте её на встрече.

6. Итоги

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

7. Проверка с людьми

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

Результат

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

Типичные ошибки

• Без описания пользователя

  Оценщики подставляют собственное знание продукта и не видят проблем, которые заметил бы новичок.

• Слишком широкая задача

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

• Проектирование на встрече

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

• Защита своего дизайна

  Автор экрана спорит с каждой найденной проблемой. Правила встречи и мягкие формулировки снимают напряжение.

• Правка разбора задачи по ходу

  Если в последовательности действий нашли ошибку, отметьте её и идите дальше. Исправить за несколько минут не получится, лучше собрать встречу заново.

• Ничего не записано

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

• Обход вместо тестирования

  Метод нельзя считать единственной проверкой. Юзабилити-тест остаётся нужным на следующем этапе.

• Обход типовых решений

  Для стандартных сценариев вроде простой корзины метод тратит время команды без заметной пользы.

Кто использует

Рик Спенсер применил сокращённый обход в Microsoft при проверке новой версии среды разработки. Собралась команда из восьми человек. За 1,5 часа прошли 32 последовательности действий и нашли 24 возможные проблемы и 11 идей. Подготовка задачи заняла около 25 часов, потому что описание шло из нескольких спецификаций. Потом результаты сравнили с юзабилити-тестом. Из девяти проблем теста обход нашёл шесть, а из 13 предсказанных проблем две не подтвердились. Подробности в статье с конференции CHI 2000.