Тестирование юзабилити имеет незаслуженную репутацию быть дорогостоящим и медленным. Когда люди слышат "пользовательские исследования", они представляют себе одностороннее зеркало, модератора с буфером обмена и двухнедельный график. Эта версия тестирования существует и имеет свое применение — но это не версия, которая нужна большинству команд продукта большую часть времени.
Версия, которая нужна большинству команд, проще: пять пользователей, прототип Figma или среда staging, видеозвонок и 45 минут за сеанс. Сделано хорошо, это выявляет большинство серьезных проблем юзабилити перед тем как они будут выпущены. Сделано постоянно — даже один раз за спринт — это производит составное улучшение качества продукта, которое ни какое количество аналитики пост-запуска не может воспроизвести.
Вот как это выполнить с нуля.
Пять участников — это правильное число для большинства тестов юзабилити. Исследование Якоба Нильсена установило что пять пользователей раскрывают около 85% проблем юзабилити с убывающими возвратами после этого. Выполнение трех сеансов пяти пользователей в разных точках процесса дизайна более ценно чем один сеанс с пятнадцатью.
Критерии найма важнее чем число. Тест юзабилити с пятью людьми которые близко соответствуют вашему целевому пользователю выявит реальные проблемы. Тест с пятнадцатью людьми которые не соответствуют создаст шум. Определите два или три критерия скрининга — роль, контекст использования, уровень технического комфорта — и придерживайтесь их.
Самый быстрый путь набора для большинства команд — отправить письмо существующим пользователям которые дали разрешение на контакт. Предложите скромный стимул — подарочная карта на £20 достаточна для 45-минутного сеанса. Старайтесь планировать сеансы в течение той же недели; чем больше промежуток между наймом и тестированием, тем выше коэффициент неявок.
Наиболее распространенная ошибка скриптинга — написание задач как инструкций: "Нажмите на Параметры, затем перейдите к Уведомлениям, и измените свое предпочтение на..." Это говорит пользователю что делать, что означает вы тестируете могут ли они следовать указаниям, не является ли интерфейс интуитивным.
Вместо этого пишите задачи как сценарии: "Представьте вы получаете слишком много уведомлений и хотите получать оповещения только когда кто-то упоминает вас напрямую. Покажите мне что бы вы сделали." Это дает пользователю реалистичную цель и позволяет вам наблюдать как они фактически навигируют — включая где они получают запутанными.
Самая сложная часть модерирования теста юзабилити — противостояние импульсу помочь. Когда пользователь запутан, каждый инстинкт говорит прыгнуть и показать где нажать. Но путаница — это данные. Пользователь который борется говорит вам что-то не так с интерфейсом — и момент вы вмешиваетесь, вы теряете сигнал.
Просите пользователей думать вслух на протяжении сеанса: "Просто скажите мне что вы смотрите и что вы думаете." Это производит постоянный поток данных об их ментальной модели. Заметьте не только ошибки но колебания — пользователь который останавливается на три секунды перед нажатием правильной кнопки все еще раскрыл проблему дизайна, даже если они в конечном счете преуспели.
Шаг синтеза — где создается большинство ценности — и где большинство команд срезают углы. Сырые заметки из пяти сеансов — не выводы. Они становятся выводами когда вы делаете debrief как команда, группируете наблюдения по теме и присваиваете рейтинги тяжести.
Делайте debrief в тот же день что и сеансы пока наблюдения свежи. Группируйте проблемы в три группы: критические (пользователи не могли завершить задачу), умеренные (пользователи завершили задачу но со значительной трудностью или ошибкой) и небольшие (трение которое не помешало завершению). Критические проблемы нужно исправить перед запуском. Умеренные проблемы должны быть приоритизированы в следующем спринте. Небольшие проблемы идут в невыполненные работы.
Запишите выводы на одну страницу: три основные критические проблемы с доказательством из по крайней мере двух участников каждая и предлагаемое изменение дизайна для каждой. Все что нуждается в большем пространстве чем это принадлежит отдельному документу.