Usability testing показывает, могут ли люди из целевой аудитории выполнить свои задачи в продукте и что им мешает. Рабочая кнопка и корректный ответ API подтверждают функциональность. Но человек может не найти кнопку, неверно понять итоговую цену или уйти до завершения формы. Это отдельные наблюдаемые проблемы качества.
QA полезен здесь знанием сценариев, состояний и ошибок. Он помогает подготовить воспроизводимые условия, заметить технические причины затруднений и проверить исправления. При этом мнение опытного тестировщика не заменяет наблюдение за реальными или вероятными пользователями продукта.
С какого вопроса начать
Исследование должно отвечать на конкретный вопрос: понимает ли новый клиент условия доставки, способен ли оператор исправить ошибку, удаётся ли человеку найти нужный документ? Слишком широкое «удобен ли сайт» превращает сессию в сбор общих впечатлений.
Опишите аудиторию и контекст: опыт, устройство, ограничения времени, язык и вспомогательные технологии. Человек, ежедневно работающий в системе, решает задачу иначе, чем новичок. Их результаты полезно рассматривать отдельно, иначе среднее значение скроет разные причины трудностей.
Задача без подсказки
Формулируйте цель пользователя, а не последовательность кликов. Вместо «откройте раздел Доставка и выберите курьера» предложите «нужно получить заказ дома после работы; найдите подходящий вариант». Такая задача проверяет понятность интерфейса и доступность нужной информации.
Подготовьте реалистичные данные и определите границу завершения. Для покупки это может быть экран подтверждения тестового заказа, а не фактическая оплата. Ожидаемый результат описывает достигнутую цель; допустимые пути заранее не ограничивают единственным маршрутом автора интерфейса.
Участники и условия
Подбирайте людей, соответствующих исследуемому сегменту, а не только свободных коллег. Перед сессией проверьте устройство, стенд, учётную запись и ограничения прототипа. Неработающий переход в прототипе может выглядеть как проблема понимания, если наблюдатели не знают о нём.
Для записи получите информированное согласие и договоритесь о хранении материалов. Используйте тестовые данные, когда реальные не нужны для вопроса исследования. Объясните участнику, что оценивается продукт: напряжение и желание «правильно пройти тест» меняют поведение и качество наблюдений.
Что делает модератор
Модератор задаёт нейтральную задачу, наблюдает и уточняет смысл действий открытыми вопросами. Просьба проговаривать мысли помогает понять ожидания, но сама влияет на скорость. Поэтому время таких сессий нельзя напрямую сравнивать с обычной работой без учёта метода.
Не подсказывайте местонахождение кнопки при первой паузе. Если помощь необходима для продолжения, зафиксируйте момент и содержание подсказки. Завершение после помощи отличается от самостоятельного успеха. Вопрос «почему вы не нажали сюда?» хуже нейтрального «что вы ожидали увидеть на этом шаге?».
Какие данные собирать
До начала определите правила измерений и одинаково применяйте их ко всем участникам. Иначе спор о результатах окажется спором о том, что команда называла успехом.
- →Завершение: самостоятельно, с помощью, частично или без результата.
- →Время: от предъявления понятой задачи до оговорённой точки завершения.
- →Ошибки и восстановление: неверные действия, возвраты, потерянные данные, необходимость поддержки.
- →Понимание: что человек считает результатом и какие условия способен объяснить.
Универсальной нормы «нужно уложиться в три клика» нет. Критерии зависят от задачи, риска и исходного уровня продукта. Для сложной операции дополнительное подтверждение может предотвращать дорогую ошибку.
Практический пример: перенос записи
Сервис позволяет перенести визит без звонка. Исследовательский вопрос: понимают ли новые пользователи, что изменение времени заменяет прежнюю запись? Подготовьте тестовый профиль с визитом и несколько свободных интервалов.
- 1.Предложите перенести визит на следующий доступный вечер. Не называйте раздел и действие. Ожидается самостоятельное обнаружение подходящего пути.
- 2.Наблюдайте выбор времени и финальное подтверждение. Фиксируйте, видит ли человек старое и новое время и может ли объяснить последствие операции.
- 3.После завершения попросите показать актуальную запись. Ожидается одна действующая запись с выбранным временем и понятным подтверждением изменения.
- 4.В отдельной попытке верните контролируемую ошибку сохранения. Ожидается понятное состояние: прежняя запись сохранена, пользователь может повторить действие и понимает результат.
Если человек завершил цепочку, но уверен, что у него теперь две записи, формальный успех скрывает проблему понимания. Поэтому проверка смысла дополняет наблюдение кликов.
Как отличить причины
При затруднении сопоставьте поведение с техническими данными. Кнопка может быть незаметной, недоступной из-за ошибки валидации или визуально активной при незагруженном API. Это разные проблемы, хотя участник описывает каждую словом «непонятно».
Запись экрана и таймлайн запросов помогают установить причину, но не следует превращать сессию в отладку на глазах участника. Сохраните контекст и исследуйте техническую часть после сессии. В отчёте отделяйте наблюдение от предположения о причине.
Как оценивать находки
Запишите цель, действие, затруднение, последствия и доказательство. «Трое участников не заметили итоговую комиссию до подтверждения» полезнее «плохой дизайн». Добавьте частоту в наблюдаемой группе и возможный ущерб, не выдавая небольшую выборку за точную оценку всей аудитории.
Приоритет зависит не только от числа случаев. Редкое необратимое действие может требовать исправления раньше частого лишнего перехода. Для количественного сравнения версий нужны сопоставимые группы, одинаковые задания и достаточный план измерений; качественное исследование само по себе этого не обеспечивает.
Ошибки и проверка улучшений
Частые ошибки — тестировать коллег вместо аудитории, обучать интерфейсу в задании, спорить с участником и собирать только оценки удовлетворённости. Положительный отзыв после неуспешной попытки не отменяет наблюдаемую проблему. Accessibility тоже нельзя объявлять проверенной лишь потому, что сценарий удобен одному человеку.
После изменения повторите проблемный сценарий и проверьте соседние пути. Критерием улучшения служит более уверенное достижение цели при согласованных условиях. Итог работы — подтверждённые затруднения, их последствия и данные, позволяющие команде выбрать и проверить конкретное исправление.