Неудачный прототип: как понять, что изменить в следующей версии

Неудачный прототип помогает определить, где именно продукт не совпал с ожиданиями: в гипотезе, пользовательском сценарии, интерфейсе или технологии. Зафиксируйте наблюдения теста, сопоставьте намерения с действиями и меняйте только проверяемые элементы. Такой подход делает разработку прототипа продукта последовательной, а следующую версию — пригодной для предметной проверки.

Что неудачная сборка уже сообщила о продукте

• Сбой прототипа — повод проверить конкретные предположения, а не оценка всей идеи.
• Сначала отделите проблемы сценария и интерфейса от технических ограничений тестовой сборки.
• Записывайте, что участник делал и говорил; не подменяйте наблюдения догадками о его мотивах.
• Не переделывайте всё сразу: выберите одно узкое место и сформулируйте, как проверить изменение.
• Следующая версия должна проверять понятную гипотезу по заранее заданным критериям.

Отделите провал гипотезы от ошибок исполнения

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

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

Соберите наблюдения, пока детали теста не забылись

Подготовьте материалы, которые позволяют восстановить ход проверки, не полагаясь на память:

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

Храните материалы с учётом конфиденциальности: ограничьте доступ к записям и удалите лишние персональные данные. Если собираетесь записывать экран или голос, заранее объясните это участникам и получите их согласие.

Сопоставьте ожидания пользователей с их реальными действиями

Перед разбором подготовьте короткий чек-лист:

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

Затем разберите материал по шагам:

1. Восстановите исходное ожидание. Запишите, какого действия вы ждали от пользователя и почему считали его вероятным. Так гипотеза не изменится задним числом после просмотра результатов.
2. Опишите фактический путь. Перечислите действия участника в порядке выполнения: куда он нажал, где остановился, что попытался найти. Отделяйте наблюдаемые действия от объяснений вроде «пользователь не понял».
3. Сопоставьте слова и действия. Отметьте, совпадали ли комментарии участника с его поведением. Например, он мог назвать кнопку понятной, но при этом искать нужную функцию в другом месте.
4. Отметьте точки затруднения. Зафиксируйте, где участник замедлился, вернулся назад, попросил подсказку или не смог завершить задачу. Укажите, что происходило непосредственно перед этим.
5. Проверьте альтернативные причины. Уточните, не повлияли ли на результат инструкция, устройство, технический сбой или вмешательство наблюдателя. Не приписывайте интерфейсу проблему, вызванную неработающей сборкой.
6. Сформулируйте вывод как проверяемую гипотезу. Например: «Пользователи не замечают переход, потому что его обозначение не объясняет следующий шаг». Добавьте, какое наблюдение подтвердит или опровергнет это предположение.

Найдите узкое место: сценарий, интерфейс или технология

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

Симптом	Возможная причина	Следующий шаг
Пользователь не понимает, зачем начинать сценарий	Задача или ценность следующего действия сформулированы недостаточно ясно	Проверьте формулировку задачи и начало сценария на новой проверке
Пользователь выбирает не тот раздел или элемент	Названия, расположение или визуальная иерархия не соответствуют его ожиданиям	Измените один элемент навигации или обозначения и проверьте выбор повторно
Участник понял следующий шаг, но прототип не реагирует	Возможен дефект сборки или ограничение интерактивности	Проверьте переход отдельно от пользовательского сценария
Пользователь проходит шаги, но не достигает нужного результата	Сценарий может не покрывать задачу целиком или пропускать необходимую информацию	Уточните задачу и проверьте, каких шагов или данных не хватает

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

Решите, что сохранить, переработать и проверить заново

Частые ошибки при доработке:

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

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

Подготовьте следующую версию к проверке по чётким критериям

Выберите подход, соответствующий типу неопределённости:

• Точечная правка интерфейса. Уместна, когда сценарий работает, но отдельное обозначение или элемент затрудняет действие. Меняйте ограниченный участок и проверяйте, стало ли нужное действие понятнее.
• Пересборка пользовательского сценария. Подходит, если участники теряют цель, пропускают необходимый шаг или не достигают результата даже при понятном интерфейсе.
• Техническая проверка. Нужна, если переходы, загрузка или доступность функций работают нестабильно. Сначала устраните дефект сборки, затем отдельно оценивайте сценарий.
• Новая проверка гипотезы. Выбирайте её, если данных недостаточно или наблюдения допускают несколько причин. Уточните задачу, критерий успеха и условия проведения до следующего теста.

Перед проверкой запишите, что именно изменено, какую гипотезу это проверяет и по какому наблюдаемому признаку команда примет результат. Услуги UX-дизайна могут быть уместны, если внутри команды не хватает навыков исследования или проектирования; состав работ и критерии результата стоит согласовать заранее. Тестирование прототипа продукта проводите на версии, где известные технические сбои устранены или явно отмечены.

Разбор сложных ситуаций при доработке прототипа

Нужно ли менять прототип после одного неудачного теста?

Не обязательно. Сначала выясните, был ли результат связан с повторяющейся проблемой, технической помехой или особенностью одной попытки; крупные изменения принимайте только при достаточном основании.

Как понять, что не сработала гипотеза, а не интерфейс?

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

Что делать, если участник просил подсказку?

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

Можно ли одновременно изменить несколько экранов?

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

Как поступить, если проблема была вызвана сбоем прототипа?

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

Когда стоит снова проверять прототип?

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

Автор: Анна Смирнова