MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям - Дэн Олсен Страница 51

Мне нравится позволять пользователю взаимодействовать с теми частями продукта, которые он обнаруживает самостоятельно (опять же без вмешательства модератора). Однако, если вам необходима обратная связь только в отношении определенного артефакта, который пользователь еще не обнаружил, вы можете направить его по нужному вам пути. Опять же, сделав это, вы снова должны «уйти в тень».

Когда пользователь в процессе тестирования продукта делает свои комментарии, вы, при наличии такой необходимости, можете и должны задавать ему уточняющие вопросы. Например, если пользователь после заполнения формы говорит: «Это было довольно сложно», – вам следует развить эту тему, например, спросив: «Не могли бы Вы пояснить, что именно вызвало сложности с заполнением?» или предложив: «Пожалуйста, расскажите об этом подробнее».

Принимайте реальность такой, как она есть

Если у пользователей возникают трудности с пониманием или использованием продукта, важно, как бы это ни было трудно, не приходить им на помощь. Ваша цель – сделать тест максимально приближенным к реальности; вы не сможете «водить за ручку» каждого покупателя продукта после его запуска, поэтому важно сделать продукт таким, чтобы в этом не было никакой необходимости. Во время тестирования вы должны вести себя так, будто вы муха на стене, и не выходить из этого образа во время получения обратной связи. Если пользователь жалуется на продукт или задает вопросы, следует воздержаться от объяснений, почему функция работает так, а не иначе, или что на самом деле имеется в виду в непонятном для пользователя тексте или пользовательском интерфейсе, а также от указаний, куда ему следует нажать. Тем более, не стоит хвататься за мышь и делать все самому (да-да, я видел, как модераторы проделывали такие штуки). Вы можете сообщить пользователям, что ответите на все их вопросы по окончании тестирования. Если качество или пользовательский интерфейс продукта или артефакта является настолько низким, что не позволяет пользователям эффективно взаимодействовать с ним самостоятельно, то вам следует прекратить тестирование и заняться решением этих проблем.

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

Завершение тестирования

Подведение итогов тестирования начинается после завершения работы пользователя с продуктом. Это самый подходящий момент для того, чтобы попросить участников поделиться своим мнением обо всем, что они увидели, а также озвучить свои общие впечатления. Возможно, вы захотите, чтобы пользователи оценили продукт в баллах. Например, вы могли бы спросить: «По шкале от 0 до 10, где 10 – это лучшая оценка, насколько полезным вы считаете это приложение?» или «Исходя из того, что вы сегодня увидели, насколько вероятно, что вы воспользуетесь этим приложением?». Вы также могли бы спросить: «Насколько просто было пользоваться приложением?» Вы можете задать свой вопрос устно или предоставить пользователю краткую форму для заполнения, что, кстати, способствует получению менее предвзятых результатов. По мере прохождения итераций, улучшающих прототип MVP, вы сможете наблюдать, как меняются оценки пользователей при ответах на те же вопросы.

Заключительный этап тестирования наилучшим образом подходит и для ответов на любые вопросы, как возникавшие во время тестирования, так и появившиеся у пользователя по его завершении. Если в процессе тестирования у пользователя возникли проблемы из-за известных разработчикам ошибок или неполадок, вы можете разъяснить ему эти моменты. По окончании сеанса вы также должны будете предоставить участникам подготовленное вознаграждение за потраченное ими время и поблагодарить их. Обычно я прошу пользователей подписать специальную форму, подтверждающую получение платежа. В этой же форме я предлагаю каждому участнику, по желанию, указать свой адрес электронной почты и номер телефона. Я также включаю туда два быстрых вопроса с вариантами ответа «да/нет»: «Хотели бы вы принять участие в будущих исследованиях?» и «Хотели бы вы получить уведомление, когда приложение появится в продаже?». Оба вопроса, на самом деле, являются скрытной проверкой степени заинтересованности. Если пользователь в ходе тестирования давал продукту исключительно положительные отзывы и оценки, но не дает ответ «да» на эти последние два вопроса, значит, в своей обратной связи он просто был излишне вежлив.

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

Как собирать и обобщать отзывы пользователей

В процессе тестирования вы пытаетесь получить сведения, которые подтверждают или опровергают гипотезы, выдвинутые вами на этапе подготовки кандидата в MVP: о целевых потребителях, их недостаточно удовлетворенных потребностях, отличительных особенностях вашего ценностного предложения и так далее. Получаемая от пользователей обратная связь будет касаться трех компонентов продукта: функциональности, пользовательского интерфейса и целевого месседжа. Отзывы о функциональности показывают, обеспечивает ли MVP нужные клиентам преимущества или нет. Пользователи могут пожаловаться на отсутствие какой-либо ключевой функции или сообщить, что какая-то из имеющихся функций, для них не важна. В таких случаях следует сопоставить полученную информацию с преимуществами и ценностным предложением продукта. Возможно, в нем на самом деле имеется нужный функционал, обеспечивающий требуемые преимущества, но плохо прописанный пользовательский интерфейс не позволяет пользователям оценить его в полной мере. Наконец, у продукта могут быть и все необходимые пользователю функции и дружественный интерфейс, но то, как вы подаете свой продукт и рассказываете о его возможностях и преимуществах – ваш целевой месседж – может не найти отклик у потребителя. Когда вы получаете от пользователей критические или положительные отзывы, бывает весьма полезно сопоставить их с тремя перечисленными высокоуровневыми категориями: функциональностью, UX-дизайном и целевым месседжем. Такая группировка обратной связи по результатам тестирования позволяет составить более четкое представление о том, что работает хорошо, а что нет.

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