Строить. Неортодоксальное руководство по созданию вещей, которые стоит делать - Tony Fadell
* * *
В General Magic мы постоянно говорили о создании продукта для Джо Сикспака, но никто никогда не встречал этого человека.
Мы проводили пользовательское тестирование, когда заканчивали разработку, но я уверен, что до этого мы практически не проводили исследований пользователей. Мы понятия не имели, что может понадобиться Джо Сикспаку, поэтому создавали те функции, которые нравились нам, и просто предполагали, что остальной мир пойдет навстречу.
Тогда я был индивидуальным вкладчиком. Я считал, что руководство знает, что делает.
Затем я перешел в компанию Philips. Теперь я был лидером. И маятник сильно качнулся.
Больше никаких предположений. Никаких больше построений на интуиции. Я привел с собой группу людей из General Magic, и все мы оправлялись от поразительного провала Magic Link. Мы знали, что не можем повторить тех же ошибок. Мы должны были понять нашего целевого покупателя и понять, что именно ему нужно. На этот раз наш продукт должен был основываться на четких, черно-белых данных. А в девяностые годы это означало потребительские панели. Они были в тренде.
Поэтому мы наняли внешнюю консалтинговую фирму и сказали, что ориентируемся на "мобильных профессионалов". Они организовали группы в разных штатах, заплатив тридцати-сорока людям по сто долларов за то, что они в течение нескольких часов посмотрят нашу презентацию.
Потом мы показали им все. Все.
В свое время у нас было десять различных прототипов крошечной клавиатуры на Velo. Какой из них лучше на ощупь? Какой выглядит более удобным? Какой из них надежнее? Смотрели ли вы на клавиатуру или на экран во время набора текста? Набирали ли вы текст всеми пальцами? Только большими пальцами? Вам нравится серый цвет? Черный? Синий? Голубовато-серый?
Мы просматривали видеозаписи сеансов. Наблюдали за их лицами, следили за их пальцами, изучали их ответы на наших маленьких бланках. Затем консультанты делали то же самое - собирали все воедино и через шесть недель предоставляли отчет.
Клиент всегда прав, верно?
Вот только клиентские панели ни хрена не умеют проектировать. Люди просто не могут достаточно четко сформулировать, чего они хотят, чтобы однозначно указать на то или иное направление, особенно если речь идет о чем-то совершенно новом, чем они никогда раньше не пользовались. Клиентам всегда будет удобнее пользоваться тем, что уже существует, даже если это ужасно.
Но мы попали в ту же ловушку, что и все остальные. Консультанты нас заворожили, цифры привели в восторг. И мы быстро стали слишком полагаться на них: всем нужны были данные, чтобы не принимать решения самостоятельно. Вместо того чтобы двигаться вперед с проектом, можно было услышать: "Ну, давайте просто протестируем его". Никто не хотел брать на себя ответственность за то, что он делает.
Таким образом, вы запускаете тест. А затем запустили его снова. В понедельник группа клиентов выбирала вариант X. В пятницу та же группа выбирала вариант Y. А мы в это время платили миллионы долларов консультантам, которые за полтора месяца набрасывали на все свой собственный взгляд.
Данные не были руководством к действию. В лучшем случае это был костыль. В худшем - цементные башмаки. Это был паралич анализа.
И это происходит не только с помощью старых панелей клиентов. Если бы на дворе был 2016 год, а не 1996-й, мы бы уже давно обратились к A/B-тестированию - вездесущему инструменту эпохи Интернета. A/B-тестирование означает проведение цифрового эксперимента, в ходе которого вы тестируете вариант A по сравнению с вариантом B на сайте . То есть одни видят синюю кнопку, другие - оранжевую, и вы видите, какая кнопка набирает большее количество кликов. Это невероятный инструмент - гораздо более быстрый, чем опросы клиентов, и гораздо более простой в интерпретации.
Но даже при A/B-тестировании мы, вероятно, получили бы те же самые неясные результаты, тот же самый убивающий продукт страх принять неправильное решение.
Несмотря на то, что многие компании сегодня неистово тестируют каждый элемент своего продукта и беспрекословно следуют за кликами, A/B и пользовательское тестирование - это не дизайн продукта. Это инструмент. Тест. В лучшем случае - диагноз. Он может сказать вам, что что-то не работает, но не скажет, как это исправить. Или он может показать вам вариант, который решает одну гиперлокальную проблему, но ломает что-то другое.
Поэтому необходимо разрабатывать варианты и тесты, чтобы действительно знать, что вы тестируете. Вы должны продумать, что такое A и B, а не позволить алгоритму произвольно назначить их или бездумно бросить в стену, чтобы посмотреть, что попадется. А это требует понимания и знания всего пути клиента. Вам нужна гипотеза, и эта гипотеза должна быть частью более широкого видения продукта. Так, можно провести A/B-тестирование того, где должна располагаться кнопка "Купить" на веб-странице, должна ли она быть синей или оранжевой, но не стоит тестировать, должен ли клиент покупать в Интернете.
Если вы тестируете ядро своего продукта, если базовая функциональность может меняться в зависимости от прихотей A/B-тестов, то ядра нет. Там, где должно быть ваше видение продукта, есть дыра, и вы просто вытряхиваете данные в пустоту.
В нашем случае, как и в случае с любым другим продуктом первого поколения, мы могли бы разгребать землю вечно. Так и не было получено достаточно данных для уверенного выбора.
Если продукт действительно новый, то его не с чем сравнивать, нечего оптимизировать, нечего тестировать.
Мы были правы, когда четко определили целевого клиента, поговорили с ним и выяснили, какие проблемы у него есть. Но затем мы должны были найти наилучший способ решения этих проблем. Мы были правы, когда спрашивали их мнение и получали отзывы о наших разработках. Но затем мы должны были использовать полученную информацию, чтобы двигаться вперед в том направлении, в котором мы верим.
В конце концов наша команда разобралась, что к чему: мы перестали выбрасывать деньги на консультантов, перестали крутиться по кругу, начали двигаться вперед, доверяя себе и мнению умных людей, которые нас окружают.
Мы принимали решения. Я принял решение. Это - за. Это - нет. Вот как это будет работать.
Не все члены команды согласились со мной. Такое иногда случается, когда один человек должен принять окончательное решение. В такие моменты вы как руководитель или лидер обязаны объяснить, что
