смысл и делает их более полезными. В итоге мы переработали обе функции и обновили проектные артефакты.
При правильном подходе каждое повторение цикла должно приводить к уменьшению масштаба и количества проблем. В данном случае между первым и вторым раундами тестирования мы успешно решили три проблемы: отсутствия функции Y, плохо видимой ссылки «Зарегистрироваться» и неудачного слогана. Мы попытались, но пока безуспешно, решить проблему с процедурой регистрации. И наконец, мы обнаружили две новые проблемы: функция Y сложна в использовании, и она должна работать совместно с функцией X.
Помимо этого, повторение цикла должно приводить к улучшению общих рейтинговых оценок. В данном случае мы видим, что рейтинг ценности продукта увеличился с 7 до 8 – скорее всего, благодаря добавлению функции Y. А оценка простоты использования повысилась с 5 до 6 баллов, вероятно, в результате переноса ссылки «Зарегистрироваться» и частичного улучшения процесса регистрации.
Раунд третий
После обновления проектных артефактов на основе информации, полученной по результатам второго раунда тестирования, мы готовы к проведению третьего раунда. По его окончании мы получили данные, приведенные в столбце «Раунд 3» в Таблице 10.1. Как видите, в этот раз пользователи уже не жаловались на то, что функции X и Y не работают совместно, поэтому нашу цель на этом направлении можно считать достигнутой. Все участники тестирования справились с процедурой регистрации. Таким образом, пусть и со второй попытки, но нам удалось решить и эту проблему. Несмотря на переработку функции Y, 40 % пользователей по-прежнему считают ее сложной в использовании. Конечно, это меньше, чем предыдущие 80 %, но нам все еще предстоит поработать над этой важной функцией.
В результате всех проделанных усовершенствований продукта рейтинг его полезности повысился до 9, а рейтинг простоты использования – до 7 баллов. Из этого следует, что мы добились значительного прогресса с момента создания своего первого MVP. Мы больше не получаем серьезной критики в отношении недостающего функционала. Наши месседжи стали гораздо более доходчивыми. В основном отзывы пользователей теперь говорят о необходимости улучшения UX-дизайна, как это обычно и происходит на ранних этапах разработки продукта.
Я упростил данный пример, включив в него лишь небольшое количество основных элементов обратной связи. На самом деле при проведении тестирования на пользователях мы получаем большое количество незначительных замечаний. Конечно, мы можем и должны внедрять улучшения, направленные на решение и таких проблем. С каждым прохождением цикла «Гипотеза – Проектирование – Тестирование – Обучение» степень соответствия нашего продукта рынку должна повышаться.
Раунд четвертый
На данном этапе мы продолжаем улучшать функцию Y, чтобы упростить ее использование, после чего проводим четвертый раунд тестирования. В столбце «Раунд 4» Таблицы 10.1 можно увидеть, что на этот раз никто из участников не пожаловался на то, что функцию Y трудно использовать. Кроме того, не было обнаружено никаких новых серьезных проблем. Рейтинг ценности продукта остался на том же высоком уровне, а рейтинг простоты использования повысился до 9 баллов.
Все это говорит о том, что уровень проработки нашего MVP является достаточно хорошим для перехода к следующему шагу процесса разработки продукта. Если в ходе тестирования использовались высокоточные артефакты (например, интерактивные макеты, созданные в InVision), мы бы приступили теперь к непосредственному созданию продукта. Если же тестирование проводилось на низкоточных артефактах (например, на интерактивных вайрфреймах), то следующим шагом стал бы переход к интерактивным макетам. В некоторых случаях, при наличии уверенности в высоком качестве визуального дизайна и отсутствии рисков пропустить какие-либо недочеты, этап высокоточного проектирования может быть опущен. Это возможно, например, в том случае, когда вы добавляете новый функционал в существующий продукт, и у нас уже имеется протестированный и легко применимый визуальный дизайн.
Не существует какого-либо жесткого правила, указывающего, в какой именно момент ваш проект можно будет считать «достаточно протестированным». Безусловно, существует риск продолжения тестирования уже после того, как оно потеряет свою ценность. И наоборот, вы можете запустить кодирование продукта, не доведя его предварительную проверку до нужной степени готовности, что в дальнейшем может привести к необходимости болезненных переделок на уровне проектирования и кодирования. Таким образом, речь идет о необходимости нахождения правильного баланса. Так или иначе, в определенный момент ваш «птенец» должен будет покинуть гнездо; то есть нужно будет прекратить тестирование артефактов проектирования и создать непосредственно MVP. Это захватывающий переход. Он в значительной степени приближает вас к созданию реальной потребительской ценности в виде живого продукта, а также позволяет выйти на следующий уровень тестирования.
Тестирование с использованием артефактов проектирования полезно для проверки гипотез и обеспечения соответствия продукта требованиям рынка. Тестирование с использованием живого продукта является еще более полезным. Когда вы тестируете артефакты, пользователи рассказывают вам, что бы они сделали, если бы имели дело с рабочим продуктом. Но то, что пользователи говорят о своих возможных действиях, может существенно отличаться от того, что они действительно будут делать. Кроме того, живой продукт отличается своей максимально возможной достоверностью. В низкоточных артефактах могут отсутствовать некоторые детали, которые имеются в реальном продукте. Помимо этого, в процессе программного кодирования могут быть допущены некоторые отклонения от проектных артефактов.
После создания реального продукта весьма полезно провести еще один раунд тестирования, чтобы понять, где вы находитесь на этот момент. Результатом должно стать подтверждение или повышение степени соответствия продукта рынку по сравнению с оценками, полученными на последнем этапе тестирования с использованием проектных артефактов. Если этого не происходит, необходимо будет повторять цикл «Гипотеза – Проектирование – Тестирование – Обучение» уже с живым продуктом до достижения требуемых результатов. Многие компании используют на этом этапе закрытое бета-тестирование, когда с продуктом может ознакомиться лишь ограниченное число клиентов. Это происходит до тех пор, пока ваше детище не будет полностью готово к выходу в свет.
Идти напролом или свернуть?
Необходимо отметить, что выше я «нарисовал» довольно радужную картину. Да, там было сказано, что придется проделать большой объем кропотливой работы, пройти через несколько этапов итераций. Но в конце этого пути вас неизбежно будет ожидать главный приз – соответствие продукта рынку. К сожалению, многие команды разработчиков имеют совсем иной опыт. При проведении тестирования своего продукта на пользователях они не получают восторженных отзывов. Они проводят итерации, но не добиваются прогресса. В результате возникает тупиковая ситуация: разработчики чувствуют, что уперлись в глухую стену.
На пути, который я описал, что-то может пойти совсем не так, как ожидалось. Одна или несколько ваших гипотез могут оказаться неверными. Или, даже если гипотезы верны, результаты проектирования, создания или маркетинга продукта могут оказаться недостаточно
