Часть IV. Проектирование взаимодействия – дело хорошее

9. Проектируем для удовольствия

Альберт Эйнштейн как-то сказал, что невозможно решить проблему, обладая тем же уровнем мышления, который ее породил. Я посвятил уже достаточное количество страниц описанию устаревшего образа мышления и причин, по которым оно не дает эффекта. Теперь же пришла пора обсудить новый подход, который будет эффективным. Я разрабатывал его с самого 1992 года и дал ему название «целеориентированное проектирование» (Goal-Directed Design). Проектировщики в моей консалтинговой компании применяют этот метод во всех наших проектах. Он базируется на инновационном подходе к решению проблем, а также содержит некоторые мощные направляющие постулаты и невероятно эффективные приемы мышления. Следующие три главы я посвятил обзору трех самых эффективных инструментов, вместе с несколькими кейсами, демонстрирующими их применение и ожидаемые результаты.

Персоны

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

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

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

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

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

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

Проектируйте только для одной персоны

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

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

Если исходить из соображений логики, то решение может выглядеть как на рисунке выше. Это некая комбинация пожеланий каждого из трех наших водителей: фургон с откидным верхом, вместительным салоном для детей и местом для перевозки древесины. Какая несуразная, невообразимая машина получилась! Даже если ее действительно можно сконструировать, никто не захотел бы ее купить. Правильным было бы сконструировать минивэн для мамочки, пикап для плотника Джо и спорткар для управленца Сета.

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

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

Роберт Лутц, председатель правления компании Chrysler, говорил, что порядка 80 % водителей, принимавших участие в фокус-группах, почувствовали крайнюю неприязнь к новому пикапу Dodge Ram. Тем не менее автомобиль был запущен в производство и стал самой продаваемой машиной благодаря тому, что оставшиеся 20 % просто влюбились в нее. Вызвать у людей любовь к вашему продукту, пусть они и в меньшинстве, – вот секрет, который приведет вас к успеху.

Чем больше мишень, тем меньше у вас шансов попасть прямо «в яблочко». Если ваша цель – довести уровень удовлетворенности продуктом до 50 %, вы не сможете сделать это, осчастливив каждого из всей широкой аудитории лишь на 50 %. Этого можно добиться, лишь выделив 50 % пользователей из этого круга, и осчастливить каждого из них на все 100 %. Но это далеко не все. Вы добьетесь еще большего успеха, если сосредоточитесь лишь на 10 % вашего рыночного сегмента, но вызовете у них стопроцентный экстаз. Такой подход кажется парадоксальным, однако проектирование для единственного пользователя – это наиболее эффективный способ сделать широкую аудиторию довольной вашим продуктом.