Вдохновленные - Марти Каган

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

Вы также скоро обнаружите, что очень многое можно узнать по жестам и тону участников тестирования. Обычно бывает очевидно, нравятся или не нравятся людям ваши идеи. Если пользователям по душе то, с чем они столкнулись, они почти всегда просят вас им сообщить, как только продукт выйдет на рынок. А если ваше детище им очень понравилось, то постараются заполучить его и раньше.

ВЫВОДЫ ИЗ РЕЗУЛЬТАТОВ ТЕСТИРОВАНИЯ

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

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

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

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

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

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

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

ТЕСТИРОВАНИЕ СПРОСА

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

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

КАЧЕСТВЕННОЕ ТЕСТИРОВАНИЕ ЦЕННОСТИ

Самый распространенный тип качественного тестирования ценности сосредоточен на отзывах. Нравится ли идея клиентам? Готовы ли они за нее платить? Решат ли ее использовать? И главное, почему нет?

КОЛИЧЕСТВЕННОЕ ТЕСТИРОВАНИЕ ЦЕННОСТИ

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

К непродуктивным тратам сил и времени относятся случаи, когда команда разрабатывает и создает продукт (тестирует юзабилити, надежность, производительность; делает все, что, по ее мнению, нужно сделать), а после его выхода на рынок обнаруживает, что люди его не покупают. По этой причине стартапы часто терпят крах. Хуже всего не те случаи, когда пользователи, массово подписавшись на пробную версию, потом вдруг решают не покупать продукт. Тут-то еще все можно исправить. Но ведь иногда они не хотят даже подписываться на пробную версию. И вот это действительно огромная, часто роковая проблема.

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

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

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

Такой метод тестирования спроса называют тестом с поддельными дверями (Fake-door demand test). Мы помещаем кнопку или пункт меню в том месте пользовательского интерфейса, где, по нашему мнению, они должны быть. Но когда пользователь на нем кликает, то он, вместо того чтобы привести к новой опции, переводит его на специальную страницу, где человеку объясняют, что вы исследуете возможность добавления новой опции и очень хотели бы с ним это обсудить. На этой странице пользователю также предлагают стать волонтером в тестировании спроса — например, указав свой адрес электронной почты или номер телефона.