Тестирование прототипа сайта: как находить ошибки до разработки

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

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

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

Во время сессии просите участника действовать привычным способом. Модератор задаёт нейтральные вопросы и не ведёт курсором. Фиксируйте, где человек ожидал найти информацию, что сделал, где остановился и смог ли завершить задачу без помощи. Слова «мне кажется удобно» полезны как контекст, но не заменяют наблюдение.

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

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

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

Не выдавайте маленькое качественное исследование за статистический прогноз конверсии. Оно помогает увидеть причины затруднений и проверить исправление. Для оценки масштаба проблемы в работающем продукте понадобятся отдельные данные и измерения.