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

Рисунок 1.1. Пирамида соответствия продукта рынку

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

Учитывая, что мы имеем дело с пирамидой, давайте начнем ее подробное рассмотрение с основания, то есть той части, которая описывает рынок. В нашем случае рынок включает в себя всех существующих и потенциальных клиентов (покупателей, пользователей), имеющих определенную потребность или набор взаимосвязанных потребностей. Например, все граждане Соединенных Штатов, которые обязаны платить подоходный налог, являются участниками рынка услуг, связанных с заполнением налоговых деклараций. Об объеме рынка можно судить по общему количеству клиентов или по суммарной выручке, которую они генерируют. Для каждого из этих двух показателей можно получить как его текущую, так и прогнозную оценку.

Присутствующие на рынке клиенты выбирают разные решения для удовлетворения своих потребностей. Например, некоторые клиенты на рынке услуг по заполнению налоговых деклараций могут довериться профессиональным консультантам, таким как компания H&R Block. Другие могут заняться этой работой самостоятельно – вручную либо с использованием специализированного программного обеспечения, например, TurboTax.

В рамках конкретного рынка можно определить рыночную долю каждого конкурирующего продукта, то есть понять, какой процент рынка охватывает каждый продукт. Например, вы могли бы сравнить доли рынка смартфонов, принадлежащие компаниям Apple и Samsung. Или же сегментировать рынок смартфонов по операционным системам (iOS, Android и так далее). Интернет-браузеры – еще один сегмент, в котором рыночные доли каждого отдельного продукта внимательно отслеживаются участниками и аналитиками.

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

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

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

Продукт – это специфическое предложение, предназначенное для удовлетворения набора потребностей клиента. Из этого определения следует, что концепция соответствия продукта рынку применима как к товарам, так и к услугам. Различие между товаром и услугой заключается в том, что товар имеет физическое воплощение, в то время как услуга нематериальна. Однако с появлением продуктов, продаваемых через Интернет и мобильные устройства, различия между товаром и услугой оказались размытыми. Достаточно вспомнить хотя бы популярный ныне термин программное обеспечение как услуга (Software as a Service, или SaaS).

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

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

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

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

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

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

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

Если же ваше приложение ориентировано на бизнес, вы должны использовать статистические данные, относящиеся к компаниям. Это будет похоже на демографические атрибуты, применяемые к людям, но включать такие характеристики, как размер компании и ее отраслевая принадлежность. Для идентификации по последнему названному атрибуту используются коды Стандартной промышленной классификации (Standard Industrial Classification, или SIC) и Североамериканской системы отраслевой классификации (North American Industry Classification System, или NAICS).

Психографические атрибуты – это также поддающиеся статистическому учету показатели, которые позволяют классифицировать группу людей в соответствии с их психологическими признаками, такими как установки, мнения, ценности и интересы. Для упомянутого выше приложения вы могли бы описать своих целевых потребителей как мам, которым нравится пользоваться социальными сетями и делиться фотографиями своих малышей с друзьями и родственниками. Если вернуться к демографическому описанию, можно заметить, что в нем ничего не было сказано о желании отбираемых женщин в возрасте от 20 до 40 лет делиться фотографиями своих детей. Для многих продуктов психографические атрибуты более полезны, чем демографические данные, которые часто не являются основными признаками, относящими человека к вашей целевой аудитории. Они играют, скорее, второстепенную роль. Как в рассматриваемом случае, когда тот факт, что вы ориентируетесь на мам с маленькими детьми, отражен в выборе демографической категории «женщины» и статистически обоснованного возрастного диапазона «от 20 до 40 лет».

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

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

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

Несмотря на то что все представители этой группы разделяют общую потребность верхнего уровня, на следующих уровнях у каждой из перечисленных категорий выявляются собственные потребности. Осознавая это, разработчик Dropcam адаптирует свой продукт для каждого сегмента потребителей. На их корпоративном веб-сайте вы найдете вкладку «Применение», внутри которой имеются отдельные страницы для различных видов потребностей: «Домашняя безопасность», «Радио-няня», «Домашние животные» и «Бизнес». При этом Dropcam предлагает различные функции продукта, адаптированные под потребности разных пользователей. Например, запись видеопотока в облачное хранилище для последующего просмотра. Поскольку я использую Dropcam только для мониторинга в режиме реального времени, пока мои дети спят, для меня эта функция бесполезна. Но она крайне важна для клиентов, заботящихся о безопасности. Они готовы платить Dropcam ежемесячную плату за использование облачного сервиса в дополнение к стоимости самой камеры. Данный пример хорошо иллюстрирует то, о чем я собираюсь рассказать в следующей главе, – как связать целевых клиентов с тем, что, по вашему мнению, является их потребностями.

Метод персонажей – это полезный инструмент для описания целевого потребителя. Алан Купер[5] выступал за использование метода персонажей как части разработанного им процесса «целенаправленного проектирования». В своей книге «Психбольница в руках пациентов»[6] он поясняет, что под термином «персонаж» подразумевается «точное определение нашего пользователя и того, чего он хочет достичь». И далее: «персонажи – это не реальные люди», а скорее «гипотетические архетипы реальных пользователей».

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

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

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

• Имя;

• Репрезентативная фотография;

• Фраза (цитата), передающая главные приоритеты персонажа;

• Род занятий;

• Демографические данные;

• Потребности/цели;

• Соответствующие мотивы и установки;

• Связанные с этим задачи и модели поведения;

• Разочарования/проблемы, связанные с текущим решением;

• Уровень экспертных знаний (в соответствующей области, например, уровень компьютерной грамотности);

• Контекст/среда в которых персонаж использует ваш продукт (например, работа за ноутбуком в шумном оживленном офисе или на планшете, развалившись дома на диване);

• Сегмент жизненного цикла принятия технологии (для вашей категории продукта);

• Любые другие важные атрибуты.

Две вещи в этом списке, которые действительно оживляют личность, – это репрезентативное фото и ключевая фраза, отражающая то, что для вашего персонажа наиболее важно. Члены команды обычно лучше всего запоминают имя, фотографию и цитату. Именно эти параметры остаются в их памяти, когда они уже не смотрят на описание персонажа. Примерное описание персонажа представлено на рисунке 3.1. Я адаптировал этот пример, взяв за основу персонаж, созданный талантливым UX-дизайнером Беккой Тецлафф. Вы можете ознакомиться с другими примерами ее работ на сайте: http://beccatetzlaff.com.

Рисунок 3.1. Персонаж

«Главным приоритетом для меня является здоровье моих детей. Поскольку воспитание двоих детей отнимает массу времени, мне нужен простой способ следить за обновлением их медицинских рецептов и назначений».

Лиза – учитель начальной школы. Она живет с мужем, Дейвом, который постоянно занят на работе, 12-летней дочерью по имени Эддисон и 9-летним сыном, Калебом. Поскольку муж Лизы часто работает допоздна, она является главным воспитателем для их детей.

У Эддисон астма, и, выходя из дома, она всегда должна иметь при себе ингалятор. Лиза беспокоится о том, что может забыть вовремя заправить ингалятор и таким образом подвергнуть дочь опасности.

Жизнь бурлит вокруг Лизы, и у нее почти не остается времени на саму себя. Соответственно, ей нужен простой и надежный способ следить за здоровьем детей и выполнять медицинские предписания.

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

Когда вы используете данные, полученные в ходе опросов, важно не использовать усредненные значения для формирования образа вашего персонажа. Вам нужно, чтобы персонаж представлял реального человека, поскольку вы не собираетесь создавать продукт для некого несуществующего «среднего» потребителя. Как тонко заметил в своей книге Алан Купер: «В среднем каждый человек из моего окружения имеет 2–3 ребенка, но ни у одного из них нет ровно 2–3 ребенка». Очевидно, что при таких вводных данных персонаж должен иметь двоих или троих детей. Вы можете использовать полученные в ходе опросов совокупные данные, чтобы убедиться, что ваш персонаж олицетворяет значительную часть представителей клиентской базы. Индивидуальные ответы тех людей, которые соответствуют профилю целевого потребителя, могут оказаться весьма ценным источником информации.

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

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

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

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

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

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

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

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

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

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

Давайте обсудим хорошо известный пример обсуждаемого явления: иерархию человеческих потребностей Маслоу[8], показанную на Рисунке 4.1.

Рисунок 4.1. Иерархия человеческих потребностей Маслоу

Абрахам Маслоу был известным американским психологом XX века. В его пятиуровневой иерархической пирамиде основу образуют физиологические потребности, такие как еда, питье и сон. Второй уровень составляют потребности в безопасности. Третий уровень – это потребности в любви и принадлежности к какой-либо социальной группе (семья, друзья, близкие отношения). Четвертый уровень – это потребности в признании и уважении. И наконец, верхний уровень пирамиды представлен потребностями в реализации своего внутреннего потенциала.

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

Когда я руководил отделом продуктового менеджмента в компании-разработчике социальной сети Friendster, мне пришлось столкнуться с существованием иерархии потребностей на собственном горьком опыте. Friendster была первой популярной социальной сетью. Для сайтов социальных сетей (как и социальных проектов в целом) характерен взрывной рост популярности. Сеть Friendster столкнулась с настолько стремительным ростом числа пользователей, что количество интернет-запросов в определенный момент стало превышать пропускную способность серверов. Многим пользователям наш продукт понравился; однако они были недовольны тем, что сайт стал слишком медленно загружаться либо был и вовсе недоступен из-за технических проблем с производительностью. Чтобы помочь команде правильно расставить приоритеты в своей работе, я – со всем уважением к Маслоу – рискнул создать свой вариант иерархии потребностей наших онлайн-пользователей, представленный на Рисунке 4.2.

Рисунок 4.2. Иерархия потребностей онлайн-пользователей по Олсену

В левой части Рисунка 4.2 показана пятиуровневая иерархия потребностей с точки зрения пользователя. Справа от каждого уровня – что это означает для разработчика. Как предпринимателям, руководителям проектов, разработчикам и дизайнерам нам нравится тратить свое время на разработку новых интересных функций и создание отличного пользовательского опыта. Однако эти элементы находятся на двух верхних уровнях пирамиды потребностей пользователей. Прежде всего, продукт должен быть доступен тогда, когда пользователь захочет им воспользоваться. Затем время отклика должно быть достаточно быстрым, чтобы не раздражать пользователя ожиданием загрузки. Следующий уровень относится к качеству продукта: работает ли он так, как должен? Затем мы переходим на уровень функционала. На первом месте здесь находится качество разработки пользовательского опыта (UX), которое определяет, насколько простым и комфортным для пользователя будет ваш продукт. Как и в случае с иерархией Маслоу, потребности более высокого уровня обретут свое значение лишь после того, как будут удовлетворены потребности более низкого уровня.

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

После того как вы изучили проблемное пространство и определили различные потребности потенциальных клиентов, необходимо решить, какие из них вы хотите удовлетворить. Иными словами, вам нужен хороший способ расставить приоритеты внутри набора потребностей. Лучше всего делать это, опираясь на степень потребительской ценности. Напрашивается вопрос: как определить степень важности той или иной потребности для клиента? Я столкнулся с этим вопросом, когда руководил проектом по разработке приложения Quicken. Мы ежегодно выпускали новую версию Quicken, и мне нужно было составить перспективный план для подготовки следующей версии продукта. В компании Intuit исследование потребителей всегда было на высоте, поэтому у меня была возможность получать результаты как количественных, так и качественных исследований. На основе этих данных я создал систему оценки, основанную на важности и удовлетворенности. Я обнаружил, что получившаяся система предлагает прекрасный способ проектирования потребительских ценностей, опираясь исключительно на аналитические методы. Мой фреймворк хорошо зарекомендовал себя в расстановке приоритетов потребностей при создании очередной версии Quicken, которая установила рекорды по объему продаж, выручке и прибыли. Воодушевленный этим успехом, я позднее разработал еще несколько подобных систем, также основанных на важности и удовлетворенности (о них я расскажу позже).

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

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

Преимущество представленного далее фреймворка заключается в том, что с его помощью вы можете оценить показатели важности и удовлетворенности не по отдельности, а в их соотношении, как показано на Рисунке 4.3. Важность изменяется по вертикальной оси (от низкой к высокой), а удовлетворенность – по горизонтальной (также от низкой к высокой). Давайте разделим этот график на четыре квадранта. Вы можете использовать данный фреймворк для оценки потенциальных возможностей продукта, вне зависимости от того, исследуете ли абсолютно новый объект или усовершенствованную версию уже существующего.

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

Рисунок 4.3. Соотношение потребительской важности и удовлетворенности

Для верхнего правого квадранта характерна и высокая важность, и высокая удовлетворенность. Это относится к продуктам, которые занимают ведущее место на своем рынке и хорошо справляются с удовлетворением потребностей клиентов. В качестве подходящего примера на ум приходит Microsoft Excel, поскольку этот программный продукт дает пользователям практически все, что они могут ожидать от приложения для работы с электронными таблицами. Недаром в «Википедии» именно этот программный продукт назван «отраслевым стандартом для электронных таблиц». Набор функций и пользовательский интерфейс в нем были отшлифованы настолько, что не требовали внесения каких-либо серьезных нововведений и на долгое время избавили Excel от конкуренции со стороны других настольных приложений для работы с электронными таблицами. Главная конкурентная угроза для этого продукта сейчас исходит от поставщиков облачных приложений, некоторые из которых бесплатно предоставляют часть функциональных возможностей Excel.

Важно отметить, что далеко не в каждой рыночной нише в верхнем правом квадранте присутствует только один доминирующий продукт. Может быть и несколько похожих продуктов. Например, многофункциональные принтеры отвечают требованиям высокой важности и удовлетворенности клиентов; однако на рынке успешно сосуществуют сопоставимые модели сразу от многих производителей, включая Hewlett Packard, Epson, Canon, Brother и Lexmark.

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

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

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

У многих людей есть важная потребность, заключающаяся в том, чтобы их перевозили из одного места в другое, как при спонтанно возникшей надобности, так и по заранее намеченному плану. Такси является традиционным и весьма распространенным решением для удовлетворения этой потребности. Но было бы большим преувеличением сказать, что удовлетворенность пользователей услугами такси находится на высоком уровне. Перечень распространенных причин для жалоб включает в себя грязные автомобили, грубость водителей, небезопасное вождение, неопределенность в отношении стоимости поездок и чаевых, а также неудобства, связанные с оплатой. Пользователи жалуются на случаи, когда заказ выполняется с опозданием или вообще отменяется по непонятным причинам. В то время как услуга такси (в общем и целом) удовлетворяет основную потребность в доставке людей из пункта А в пункт Б, количество жалоб на исполнение свидетельствует о наличии многих важных неудовлетворенных потребностей, которые явно находятся в верхнем левом квадранте представленной выше диаграммы. Сочетание высокой важности данного набора потребностей, низкой удовлетворенности существовавшими решениями (традиционное такси) и большого числа людей, имеющих такие потребности, указывало на наличие весьма перспективной рыночной возможности, которую компания Uber вовремя увидела и поспешила ей воспользоваться.

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

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

Очевидно, что Uber закрыла множество недостаточно удовлетворенных потребностей, которые находились в верхнем левом квадранте диаграммы – с высоким показателем важности и низкой удовлетворенностью. В результате компания добилась невероятного рыночного успеха с момента своего появления в 2009 году. Компания не является публичной, но утечка финансовых данных в декабре 2013 года показала, что у Uber более 400 тыс. активных клиентов, совершающих более 800 тыс. поездок в неделю. Валовый объем годовой выручки на тот момент превышал 1 млрд $, из которых Uber удерживает 20 %. В декабре 2014 года компания привлекла инвестиции в размере 1,2 млрд $, при том что оценка ее стоимости составила 40 млрд $. Возможно, вы не достигнете такого же успеха, как Uber, но если все же решите попробовать, то сектор диаграммы, указывающий на наличие высокой степени важности и низкой удовлетворенности – лучшее место для поиска самых перспективных рыночных возможностей.

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

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

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

Давайте обсудим ряд инноваций, которые привели к необратимым изменениям на рынке портативных устройств для прослушивания музыки. Клиентскую потребность верхнего уровня в этом случае можно сформулировать следующим образом: «Дайте мне возможность слушать музыку, находясь в движении». Первым продуктом, в котором было реализовано это пожелание, стал транзисторный радиоприемник, появившийся в 1950-х годах. До этого при производстве радиоприемников использовались лампы и требовали для своей работы электрической энергии. Лампы к тому же были хрупкими, что исключало возможность создания приемлемой мобильной версии. Однако даже с появлением первых портативных радиоприемников, позволяющих слушать музыку на ходу, люди все еще не имели возможности выбирать, какие именно композиции они желают слушать. Ситуация изменилась в 1979 году, когда Sony представила первый портативный кассетный аудиоплеер Walkman. Теперь пользователи могли выбирать для прослушивания любую музыку, просто вставляя нужную кассету. Walkman, безусловно, был прорывной инновацией, которая изменила шкалу удовлетворенности, вытеснив портативные радиоприемники из верхнего правого квадранта в верхний левый.

Несколько лет спустя Sony выпустила первый портативный проигрыватель компакт-дисков Discman, который предлагал дополнительные преимущества: более высокое качество звука и возможность легко и быстро переключаться с одной композиции на другую без необходимости перемотки кассеты. Одним из недостатков ранних моделей Discman (устраненным в более поздних моделях) было то, что при встряске (например, на бегу) происходило частичное «проглатывание» звука. Портативный CD-плеер добавил некоторые преимущества по сравнению с «кассетником». И хотя для некоторых целевых клиентов портативный проигрыватель компакт-дисков располагался на моей диаграмме заметно правее, чем Walkman, его появление не привело к кардинальному изменению шкалы удовлетворенности.

Следующей инновацией на рынке портативных музыкальных устройств стал MP3-плеер, выпущенный в 1998 году. Первые модели не обладали большой памятью для хранения записей, но со временем ситуация изменилась. Компания Apple вышла на рынок MP3-плееров со своим iPod в 2001 году. Поначалу их устройство не имело ошеломляющего успеха, но компании удалось внести значительные улучшения в последующие модели. Сочетание большого объема памяти, интуитивно понятного пользовательского интерфейса и интеграции с программным обеспечением iTunes, Jukebox и Digital music store позволило детищу Apple стать ведущим MP3-плеером, захватившим более 70 % рынка. В результате iPod стал прорывной инновацией, которая в очередной раз переопределила шкалу удовлетворенности любителей прослушивания музыки с использованием портативных устройств.

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

Тем не менее, на сегодняшний день iPod и другие MP3-плееры утратили свою популярность. Что же привело к вытеснению этих устройств с рынка? Появление iPhone и других смартфонов, которые включили в свой набор функций все, что умел делать MP3-плеер (и даже больше). Интересно, что одновременно с этим потребность слушать музыку на ходу превратилась из самостоятельного преимущества в составную часть целого комплекса потребностей, возникающих у людей, находящихся в пути: совершение телефонных звонков, отправка текстовых сообщений, просмотр веб-страниц, игры, использование приложений и многое другое. Все эти потребности теперь покрываются при помощи одного продукта – смартфона.

Когда я выступаю на семинарах и рассказываю о своей диаграмме соотношения важности и удовлетворенности, одним из самых часто задаваемых вопросов является следующий: «Как можно измерить степень важности и удовлетворенности?» Самый простой способ сделать это – задать вопрос своим потенциальным клиентам. Вы можете сделать это в личном интервью или путем анкетирования. Давайте представим, что мы с вами являемся членами команды разработчиков Uber. И опрашиваем тысячу наших целевых клиентов, задавая им следующий вопрос: «Когда вы пользуетесь услугой такси, насколько для вас важно, чтобы водитель был вежлив?» При этом мы будем использовать 5-балльную шкалу из следующих вариантов ответа:

• Совсем не важно.

• Маловажно.

• Важно.

• Очень важно.

• Чрезвычайно важно.

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

Чтобы получить оценку показателя удовлетворенности, можно использовать такую формулировку вопроса: «Насколько вы удовлетворены вежливостью водителей во время поездок на такси, которые вы совершили за последние шесть месяцев?» В этом случае мы используем 7-балльную шкалу из следующих вариантов ответов:

1. Абсолютно не удовлетворен.

2. Скорее не удовлетворен.

3. Слегка не удовлетворен.

4. Нейтральная оценка.

5. Удовлетворен отчасти.

6. Скорее удовлетворен.

7. Полностью удовлетворен.

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

В дополнение к потенциальным клиентам мы могли бы организовать такой же опрос среди реальных пользователей Uber, задав им те же самые вопросы о важности. Затем задали бы им вопросы об удовлетворенности, но на этот раз они касались бы услуг, предоставляемых именно Uber, а не традиционными такси. Сравнение оценки удовлетворенности вашим продуктом с оценками продуктов конкурентов – это хороший способ понять, насколько лучше (или хуже) потребитель воспринимает ваше решение.

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

При опросе пользователей вы можете использовать разный масштаб шкалы, например от 1 до 10 или от 0 до 10. Использование более 11 вариантов ответов может привести респондентов в замешательство, а менее пяти вариантов не обеспечит достаточной детализации ответов. Для любой биполярной шкалы я рекомендую использовать нечетное количество вариантов ответов, чтобы ровно посередине шкалы оказалась нейтральная оценка. Согласно результатам серьезных исследований надежности и валидности различных шкал, 5-балльная система оценки лучше всего подходят для однополярных шкал, а 7-балльная – для биполярных. Это объясняет, почему я рекомендую именно вышеуказанные варианты.

Как я уже писал, для упрощения последующих расчетов и анализа вы можете сопоставить балльную систему, используемую во время опросов, с другой более удобной для вас шкалой. Например, вы могли бы приравнять оценки, полученные по 5-балльной системе, к следующим значениям 100-балльной шкалы: 0, 25, 50, 75 и 100. Или к таким значениям: 0, 2.5, 5, 7.5 для перевода на 10-балльную шкалу. Аналогично оценки, полученные по 7-балльной системе, можно преобразовать в значения: 0, 16.7, 33.3, 50, 66.7, 83.3 и 100 на 100-балльной шкале. С учетом возможности преобразования баллов при опросах потребителей следует использовать такую шкалу, которая будет для них наиболее понятна и которая не подразумевает большей точности ответов, чем вы реально можете получить.

Для лучшего понимания рассматриваемой концепции давайте применим ее к данным, относящимся к реальному продукту. Работая над одним из проектов, мы периодически проводили опрос наших пользователей с целью получения их оценки предлагаемых ключевых функций. В рамках одного из опросов мы попросили пользователей оценить степень важности 13 ключевых функций продукта, а также уровень удовлетворенности их работой. Мы усреднили оценки, полученные для каждой функции, и нанесли их на график, как показано на Рисунке 4.4. Каждая из 13 точек, которые вы видите, соответствует определенной ключевой функции. Число, указанное рядом с каждой точкой, – это усредненная оценка удовлетворенности пользователей данной функцией. В правом верхнем углу вы можете видеть точку, относящуюся к функции, о которой я упоминал ранее: получившей 100 %-ную оценку по важности и 98 %-ную по удовлетворенности. Как менеджер продукта я был очень доволен таким результатом. Поскольку эта функция уже работала максимально хорошо, я не хотел тратить драгоценные ресурсы нашей команды на дальнейшие попытки ее улучшить. Вместо этого я сосредоточился на улучшении функции, точка которой (с пометкой «55») находится ближе всего к верхнему левому углу, что говорит о ее высокой важности и низком уровне потребительской удовлетворенности. Согласно данным опроса, эта функция имела 82 %-ную важность, но при этом удовлетворяла потребности пользователей лишь на 55 %. Только одна функция имела еще более низкий показатель удовлетворенности (41 %). Однако она была гораздо менее важной (всего 53 %). Стоит отметить, что клиенты способны оценить свою удовлетворенность решением только в том случае, если они им реально пользовались.

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

Рисунок 4.4. Соотношение показателей важности и удовлетворенности на реальных данных

Давайте вернемся к Uber. Предположим, мы проводим индивидуальные интервью с каждым из 25 человек, которые часто пользуются услугами такси, и задаем им вопросы на тему важности и удовлетворенности. Как вы думаете, какой процент опрошенных, будет «полностью удовлетворен» своим опытом потребления данной услуги? Смею предположить, что немногие (если не сказать никто) из 25 опрошенных выбрали бы этот вариант ответа. В ходе интервью мы хотели бы получить больше информации о клиентских потребностях в комфорте, удобстве использования, безопасности, надежности и так далее. Представьте, что мы попросили 25 клиентов оценить важность каждого из перечисленных преимуществ, а также соответствующий уровень удовлетворенности ими, на основе личного опыта. При этом вполне вероятно, что в полученных результатах мы смогли бы увидеть значимые закономерности – даже несмотря на то что опросили далеко не тысячи пользователей. Например, если очень большой процент опрашиваемых оценивает какой-то параметр одинаково высоко или низко, есть неплохой шанс, что похожий результат будет получен и при опросе гораздо большего числа респондентов. Я называю эту технику «восполнением количества за счет качества» – количественный анализ на качественных данных. Однако должен предупредить, что использовать такой подход следует с большой осторожностью. Это редко используемый инструмент. Статистический анализ имеет массу преимуществ, но очень многие продакт-менеджеры убедили себя в том, что они нуждаются исключительно в таких доказательствах, которые не оставляют даже тени сомнения. Вместе с тем случаи бывают разными. Довольно часто, особенно на ранних стадиях работы над продуктом версии v1, применение канонических статистических методов просто невозможно. Значимость статистических показателей велика, но далеко не всегда у вас есть размер выборки, необходимый для обеспечения высокой степени их достоверности. Поэтому принцип «все или ничего» здесь не применим.

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

Ранее я упомянул о том, что уже после создания собственного фреймворка во время работы в Intuit я был рад открыть для себя другие структурные инструменты, также основанные на показателях важности и удовлетворенности. Например, такие методы, как Gap-анализ и Работа для выполнения (Jobs-to-Be-Done, или JTBD) используют показатели важности и удовлетворенности для количественной оценки различных функций продукта и расстановки соответствующих приоритетов.

Если вы поищете описание этого метода в Интернете, то найдете сразу несколько определений. Версия, на которую я ссылаюсь, основана на расчете величины «разрыва»[9] между важностью и удовлетворенностью. То есть вы просто берете усредненное значение показателя важности и вычитаете из него значение показателя удовлетворенности.

Gap = Важность – Удовлетворенность

Чем большей оказывается полученная величина «разрыва», тем в меньшей степени удовлетворяется исследуемая потребность. Согласно этой формуле, в ситуации, когда удовлетворенность превышает важность, «разрыв» будет выражаться отрицательной величиной.

Преимущество Gap-анализа состоит в том, что результатом является единственное число, которое к тому же очень легко вычислить. Однако у этого метода есть существенный недостаток – он не позволяет делать различия между «разрывами», имеющими одинаковую величину. Например, если при использовании шкалы от 0 до 10 баллов, показатель важности потребности равен 10 баллам, а уровень удовлетворенности = 5 баллам, то величина «разрыва» составляет 5 баллов. Если бы важность другой потребности равнялась 6 баллам, а степень удовлетворенности – 1 баллу, то величина «разрыва» также составила бы 5 баллов. В итоге эти цифры не несут в себе необходимой смысловой нагрузки, поскольку разрыв в 5 баллов для потребности, имеющей важность в 10 баллов, должен быть более значимым, чем аналогичный разрыв для потребности с важностью, оцененной только в 6 баллов. Теперь давайте перейдем к другому структурному инструменту, также основанному на показателях важности и удовлетворенности, но не имеющему указанного недостатка.

В свое время мне посчастливилось открыть для себя книгу Энтони Ульвика «Чего хотят потребители»[10]. В ней он описывает свой инновационный подход, ориентированный на конечный результат, в котором также используются показатели важности и удовлетворенности для количественной оценки возможностей. Ульвик использует несколько более сложную формулу для получения своего оценочного показателя, но именно это позволяет решить описанную выше проблему Gap-анализа:

Оценка возможности = Важность + Maximum (Важность – Удовлетворенность, 0)

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

Давайте рассчитаем оценку возможностей, используя те же данные, что и в предыдущем примере. Наша первая потребность с показателем важности 10 баллов и удовлетворенностью в 5 баллов будет иметь оценку возможности, равную: 10 + Maximum (10 – 5, 0) = 10 + 5 = 15 баллов. Для второй потребности с показателем важности 6 баллов и удовлетворенностью в 1 балл оценка возможности будет равна: 6 + Maximum (6–1, 0) = 6 + 5 = 11. Таким образом, используя формулу Ульвика, даже если величина разрыва между важностью и удовлетворенностью для каждой из двух потребностей одинаковая (по 5 баллов), мы можем выяснить, что первая потребность, с более высоким показателем важности, имеет более высокую оценку возможности.

Центральное место в методологии Ульвика занимает идея о том, что клиенты приобретают продукты и услуги, которые помогают им выполнить некоторую задачу или работу. Покупатели решают, какой продукт им следует приобрести, исходя из того, насколько хорошо он обеспечивает «желаемые результаты» для «работы, которую необходимо выполнить». Этого же подхода, ставшего известным под названием Jobs-to-Be-Done («Работа для выполнения»), придерживался Клейтон Кристенсен[11] и некоторые другие исследователи.

Ульвик объясняет превалирование желаемых результатов над потребностями или выгодами клиентов тем, что последние формулируются, как правило, очень неточно. Он утверждал, что недостаток «клиентоориентированного» подхода, который слишком сильно полагается на «мнение клиента», заключается в том, что потребители часто выражают свои мысли неточно или двусмысленно. Я согласен с тем, что клиентские потребности и выгоды должны быть сформулированы максимально точно – но это забота команды разработчиков продукта, а вовсе не самих клиентов. Для создания инновационных решений команде разработчиков необходимо сформировать четкое представление о проблемном пространстве. При этом я разделяю озабоченность Ульвика по поводу того, что цели или требования к продукту очень часто оказываются «размыты» – сформулированы лишь на самом верхнем уровне или слишком расплывчато.

По словам Ульвика, «для большинства выполняемых задач, даже тех, которые могут казаться тривиальными, обычно существует от 50 до 150 и более желаемых результатов, что явно выходит за рамки ожидаемого количества». Это утверждение явно перекликается с моей собственной убежденностью в том, что для команд разработчиков посильно – и фактически необходимо, если они рассчитывают создать успешную инновацию, – формировать подробное и точное описание проблемного пространства своего продукта. То, что Ульвик называет результатами, я бы назвал точно сформулированными потребительскими выгодами (преимуществами). Вместо того чтобы бессистемно скрести поверхность луковицы, хорошие команды разработчиков тщательно, слой за слоем, очищают лук от кожуры, получая при этом все более глубокие знания о предмете своего исследования. Стив Джобс также придерживался аналогичной точки зрения:

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

Если идея количественной оценки возможностей продукта на основе показателей важности и удовлетворенности находит у вас отклик, рекомендую вам прочесть книгу Энтони Ульвика «Чего хотят потребители». Я же, используя свою систему сопоставления важности и удовлетворенности, разработал собственный количественный подход, который, как мне кажется, в некоторой степени более понятен на интуитивном уровне. Этот подход выходит за рамки простой количественной оценки возможностей и обеспечивает более широкое представление, которое наглядно демонстрирует потребительскую ценность, и то, как она создается.

Давайте вернемся к схеме соотношения важности и удовлетворенности, представленной на Рисунке 4.3, но сделаем шкалу значений по осям координат более точной. Вместо диапазона от «низкого» до «высокого» мы будем оценивать важность и удовлетворенность в диапазоне от 0 до 100 %, как показано на Рисунке 4.5. Таким образом, независимо от того, измеряете ли вы эти показатели по 5-балльной, 7-балльной, 10-балльной или 100-балльной шкале, вы всегда сможете оставаться в границах заданного масштаба.

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

Рисунок 4.5. Визуализация потребительской ценности

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

Обеспечиваемая потребительская ценность = Важность * Удовлетворенность

Рассмотрим продукт, обозначенный на графике на Рисунке 4.5. Важность покрываемой потребности составляет 70 %, удовлетворенность продуктом, покрывающим эту потребность, оценивается также в 70 %. Таким образом, потребительская ценность, которую обеспечивает этот продукт, составляет: 0.7 * 0.7 = 0.49.

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

На основе графика, отражающего соотношение важности и удовлетворенности, вы также можете легко оценить возможность повышения потребительской ценности своего продукта. Под такой возможностью понимается максимальная величина потребительской ценности, которая может быть добавлена к текущему значению этого показателя. Потребительскую ценность можно повысить за счет повышения уровня удовлетворенности до его максимального значения в 100 % (в формуле это значение соответствует единице). Количественно это может быть выражено следующим образом:

Возможность повышения ценности = Важность * (1 – Удовлетворенность)

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

На Рисунке 4.6 показаны два продукта с различными возможностями повышения их потребительской ценности. Продукт А (показатели которого мы взяли из предыдущего примера, показанного на Рисунке 4.5) имеет 70 %-ную важность и 70 %-ную удовлетворенность, поэтому оценка возможности повышения его потребительской ценности равна:

Возможность для продукта А = 0.7 * (1–0.7) = 0.7 * 0.3 = 0.21

Рисунок 4.6. Измерение возможности повышения потребительской ценности

Показатель важности для продукта B составляет 90 %, а удовлетворенности – 30 %, поэтому оценка возможности повышения потребительской ценности в этом случае равна:

Возможность для продукта B = 0.9 * (1–0.3) = 0.9 * 0.7 = = 0.63

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

Если вы вернетесь к Рисунку 4.4, на котором представлены реальные данные, относящиеся к существующему продукту, то вспомните, что я присвоил наивысший приоритет разработке той функции, важность которой составляла 82 %, а удовлетворенность – 55 %. Давайте назовем ее «Функция X». Взгляните на все точки, нанесенные на график. Теперь, когда вы знаете, каким образом можно оценить возможности получения добавленной ценности, вы сразу заметите, что наилучшие шансы имеет именно Функция X. Количественная оценка возможности для Функции X равна:

Возможность для Функции X = 0.82 * (1–0.55) = 0.82 * 0.45 = 0.37

Другие 11 функций, отображенные на графике справа от Функции X, имеют показатель возможности, не превышающий 0.25. А возможность для функции с показателем важности 53 % и удовлетворенности – 41 % оценивается в 0.32 балла. Обратите внимание, несмотря на то что точка этой последней функции оказалась в левом нижнем углу графика, представленного на Рисунке 4.4, это произошло исключительно потому, что оси координат здесь не показаны полностью, то есть начинаются не от нулевого значения. При использовании полной шкалы эта точка оказалась бы расположена ближе к центру графика.

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

Возможность = Важность – Текущая достигнутая ценность

Вы также можете визуализировать ту часть потребительской ценности, которая создается за счет произведенных улучшений продукта. Если улучшение изменяет показатель удовлетворенности с текущего уровня (Удовлетворенность_До) до более высокого уровня (Удовлетворенность_После), то создаваемая при этом потребительская ценность равна площади увеличения прямоугольника, которая вычисляется по формуле:

Потребительская ценность улучшения = Важность * (Удовлетворенность_После – Удовлетворенность_До)

Рисунок 4.7 иллюстрирует создание дополнительной потребительской ценности путем улучшения продукта, которое повышает уровень удовлетворенности (на основе данных из примера, приведенного на Рисунке 4.5). Показатель важности потребности составляет 70 %, а уровень удовлетворенности до улучшения продукта – 70 %. После улучшения продукта уровень удовлетворенности возрастает до 90 %. Применив приведенную выше формулу, мы получаем, что дополнительно созданная за счет улучшения продукта потребительская ценность составила 0.14.

Потребительская ценность улучшения = 0.7 * (0.9–0.7) = 0.7 * 0.2 = 0.14

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

Рисунок 4.7. Создание дополнительной потребительской ценности путем улучшения продукта

Сейчас самое подходящее время для того, чтобы представить вам концепцию, основанную на показателе рентабельности инвестиций (return on investment, или ROI). До сих пор мы говорили о расстановке приоритетов исключительно на основании потребительской ценности, которую, по вашему мнению, несет в себе каждая функция. При этом мы совершенно не принимали во внимание тот объем ресурсов, который необходимо затратить на создание этих функций. После того как вы закончите фрагментацию функций, необходимо будет выполнить повторную расстановку приоритетов, уже с учетом не только потребительской ценности функций, но и затрат на их создание.

Приведу простой пример, иллюстрирующий понятие рентабельности инвестиций. Представим, что я покупаю некие акции на сумму 100$. Через несколько месяцев цена акций поднимается до 200$, и я решаю их продать. Доход – или чистая прибыль – от этой операции составляет 100$ (200$ – 100$ = 100$). Объем инвестиций составил 100$. Показатель рентабельности моей инвестиции составляет 100$ ÷ 100$ = 1, или 100 %. Общая формула для расчета рентабельности инвестиций выглядит следующим образом:

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

Аналогичным образом, в контексте разработки нового продукта такая присутствующая в формуле переменная как «доход» зачастую также не измеряется денежной суммой. Это, скорее, некоторая относительная мера потребительской ценности, которую, как вы ожидаете, способна произвести разрабатываемая функция. Таким образом, для расчета рентабельности инвестиций в отношении разработки новых продуктов следует применять числовые оценки потребительской ценности. Для этого подойдет так называемая «шкала коэффициентов», которая просто передает пропорции величин, используемых для оценки. Например, предположим, что вы используете шкалу от 0 до 10 баллов для указания величины потребительской ценности каждого из фрагментов разрабатываемых вами функций. Если один из фрагментов имеет оценку 10 баллов (по вашей шкале коэффициентов), а другой фрагмент – оценку 5 баллов, это должно означать для вас, что первый фрагмент имеет вдвое большую потребительскую ценность, чем второй.

Рисунок 6.1, где по вертикальной оси показана созданная ценность (этот термин здесь используется вместо термина «доход» из приведенной выше формулы для расчета ROI, – прим. пер.), или созданная потребительская ценность (в относительных единицах), а по горизонтальной оси – объем инвестиций, или трудозатраты (в неделях работы в расчете на одного разработчика), иллюстрирует концепцию рентабельности инвестиций применительно к разработке новых продуктов. Давайте начнем с идей функций A и B, каждая из которых, согласно примененной оценочной шкале, создает шесть единиц потребительской ценности. При этом для реализации идеи B требуется четыре недели разработки, в то время как для реализации идеи A потребуется всего две недели. Таким образом, показатель рентабельности инвестиций для идеи A составляет: 6 ÷ 2 = 3, в то время как рентабельность инвестиций для идеи B составляет: 6 ÷ 4 = 1.5. Соответственно, идея функции A является более приоритетной по отношению к идее функции B.

Иногда две разные функции обеспечивают примерно одинаковую рентабельность инвестиций. Обратите внимание на идеи функций C и D. Идея C способна принести четыре единицы потребительской ценности в ответ на потраченные на ее разработку 4 недели, что соответствует показателю рентабельности инвестиций: 4 ÷ 4 = 1. Идея D предлагает восемь единиц потребительской ценности при затратах, равных восьми неделям разработки, и в этом случае рентабельность инвестиций также составит: 8 ÷ 8 = 1. Когда у вас есть две идеи функций с одинаковой рентабельностью инвестиций, приоритет разумнее отдать идее меньшего масштаба, поскольку ее реализация займет меньше времени. В этом случае вы сможете быстрее донести ценность до потребителей и, соответственно, раньше получите от них обратную связь.

Рисунок 6.1. Рентабельность инвестиций

На рисунке представлены также примеры плохих идей. Например, идея F, которая предполагает получение дохода в размере двух единиц потребительской ценности при затратах восьми недель на разработку, имеет показатель рентабельности инвестиций: 2 ÷ 8 = 0.25. Увеличение затрат на реализацию идеи, приводящее к снижению рентабельности инвестиций, часто становится очевидным уже на ранних этапах разработки; однако низкая потребительская ценность обычно выявляется только после запуска продукта. Google Buzz и Google Wave являются реальными примерами проектов с низкой рентабельностью инвестиций. На реализацию каждого из них разработчик потратил много часов, но оба проекта были закрыты вскоре после запуска, когда по реакции пользователей стало понятно, что они не несут в себе ожидаемой потребительской ценности.

Хорошие продуктовые команды стремятся выдвигать идеи, подобные идее G, представленной на Рисунке 6.1, – то есть такие, которые создают высокую потребительскую ценность при минимальных затратах. Отличные же продуктовые команды способны, помимо этого, разбивать подобные идеи на фрагменты, отсекать наименее ценные из них и находить креативные способы создания высокой потребительской ценности с меньшими усилиями, чем планировалось изначально. Такое достижение отражено на Рисунке 6.1 сдвигом идеи G влево.

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

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

В качестве параметра «доход», участвующего в расчете ROI, может выступать показатель не только потребительской ценности, но ценности для вашего бизнеса. В этом случае вы можете использовать значение, выраженное в реальных деньгах. Оно будет отражать ожидаемый прирост выручки или ожидаемое снижение затрат. Предположим, например, что у вас есть действующий продукт и вы пытаетесь повысить коэффициент конверсии бесплатных пользователей в платных. При заданном уровне повышения коэффициента конверсии вы должны иметь представление об ожидаемом увеличении объема выручки. Это дает вам возможность связать каждую имеющуюся идею функции с ее ценностью, представленной уже в денежном выражении. В главах 13 и 14 обсуждаются способы повышения рентабельности инвестиций по мере улучшения показателей бизнеса и продукта.

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

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

Рисунок 6.2. Приблизительная оценка показателя рентабельности инвестиций

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

Несмотря на то что термин «MVP-тест» обеспечивает удобное обобщение всех различных видов подобных тестов, между ними имеются ключевые различия. Существует два основных способа их классификации.

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

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

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

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

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

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

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

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

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

Ключевым показателем для данного вида тестов является коэффициент конверсии: процент посетителей целевой страницы, которые нажали на соответствующую кнопку, чтобы превратиться из потенциального клиента в покупателя. Например, если вы привлекли на свою лендинговую веб-страницу 1000 посетителей, из которых 250 человек нажали кнопку «Зарегистрироваться», то коэффициент конверсии составит 25 %. На величину данного показателя влияет то, какие преимущества вы выберете для демонстрации и насколько хорошо опишете свой продукт. При этом необходимо учитывать, что даже если вы выбрали для показа действительно важные для пользователей преимущества, коэффициент конверсии может оказаться низким из-за плохой проработки дизайна веб-страницы и текстового описания.

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

Приложение Buffer представляет собой хороший пример MVP-теста целевой страницы. Buffer – это продукт, который помогает организовывать размещение сообщений в Twitter, публикуя выбранные твиты в заранее запланированное вами время. Генеральный директор и соучредитель Buffer Джоэл Гаскойн описал в своем блоге (https://blog.bufferapp.com/idea-to-paying-customers-in7-weeks-how-we-did-it) процесс MVP-тестирования целевой страницы этого продукта. По его словам, в случае с Buffer он решил применить иной подход, нежели к своему предыдущему стартапу: «Я начал писать код для Buffer еще до того, как проверил степень жизнеспособности проекта. Но я быстро осознал свою ошибку, остановился, глубоко вдохнул и сказал себе: “На этот раз сделай все правильно. Начни с проверки того, нужен ли людям этот продукт”».

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

Как объяснил Гаскойн: «Цель этого двухстраничного MVP состояла в том, чтобы проверить, захочет ли кто-то вообще использовать наше приложение. Я просто разместил ссылку в Twitter и спросил читателей, что они думают об этой идее. После того как несколько человек отправили мне свою электронную почту с лендинговой страницы, а некоторые даже прислали полезные отзывы на e-mail и в Twitter, я счел свою идею протестированной».

Таким образом, Гаскойн получил подтверждение востребованности задуманного им проекта. Далее следовало проверить, готовы ли люди платить за это. Поэтому он сделал дополнительную страницу (перед формой для отправки адреса электронной почты), на которой разместил описание трех тарифных планов с различными уровнями использования продукта: бесплатный, за 5$ в месяц и за 20$ в месяц. Это позволило ему увидеть, сколько кликов собрал каждый тарифный план, в дополнение к тому, сколько пользователей согласились указать свой e-mail. Тестирование прошло успешно. Несмотря на появление необходимости дополнительного перехода между страницами, посетители по-прежнему заходили на форму отправки адреса электронной почты, оставляли свои e-mail и даже выбирали платные условия использования продукта.

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

Демо-ролик на самом деле является всего лишь еще одним вариантом тестирования с использованием целевой страницы, в основе которого лежит видеоролик, рассказывающий о вашем продукте. О его эффективности можно судить опять же по коэффициенту конверсии, рассчитываемому на основе посещений веб-страницы с регистрацией. Данный тип теста хорошо подходит для продуктов, ценность которых трудно описать только словами. Облачный сервис хранения данных Dropbox провел один из самых известных MVP-тестов с использованием демонстрационного видеоролика. Основатель Dropbox Дрю Хьюстон заметил, что люди просто не понимают словесных объяснений, чем Dropbox с его уникальным подходом к синхронизации файлов выгодно отличается от других сервисов хранения файлов, представленных в то время на рынке. Поэтому он создал видеоролик, в котором показал и объяснил, как работает Dropbox. Пользователи увидели в этом ролике действующий способ решения проблем, с которыми они реально сталкивались, пытаясь управлять своими файлами и обмениваться ими между различными устройствами. Это привело к появлению большого количества подписчиков в листе ожидания закрытого бета-тестирования Dropbox.

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

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

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

В тестах могут участвовать более двух альтернатив. Например, вы можете провести A/B/C-тест с тремя версиями материалов. Правила проведения A/B-теста предусматривают, что тестирование всех участвующих в нем версий проводится параллельно, в одно и то же время, в равных условиях. Например, 50 % трафика направляется на версию A и столько же – на версию B. Менее желательно тестировать версии последовательно (100 % трафика на версию A, затем 100 % трафика на версию B). Тестируя альтернативные варианты одновременно, вы избегаете риска, что имевшиеся в разное время различия во внешних факторах приведут к искажению полученных результатов.

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

Список наиболее популярных инструментов для проведения A/B тестирования включает в себя следующие сервисы: Optimizely, Unbounce, KISSmetrics, Visual Website Optimizer и Google Content Experiments (входит в состав Google Analytics). Эти инструменты позволяют выбрать для тестирования несколько альтернативных версий продукта, а затем случайным образом распределить между ними пользовательский трафик. Функционал этих сервисов дает возможность отслеживать интересующие вас действия посетителей, рассчитать коэффициент конверсии и получить результаты для каждого из тестируемых вариантов с указанием уровня статистической достоверности.

Мультивариантное тестирование похоже на A/B-тестирование, но подразумевает проверку разных версий элементов веб-страницы, а не всей страницы целиком. В этом случае каждый тестируемый элемент страницы является переменной. Допустим, при разработке целевой страницы у вас возникло три разных идеи относительно заголовка и три разных идеи основного изображения. При применении мультивариантного теста будут опробованы все девять возможных комбинаций разных заголовков и изображений, чтобы определить, какая из них работает наиболее эффективно.

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

Часы Pebble Watch – это одна из историй успеха, имевших место на платформе Kickstarter. Сначала основатель данного стартапа, Эрик Мигиковский, попытался привлечь финансирование со стороны венчурных компаний через инкубатор Y Combinator. Однако попытка оказалась безуспешной. Тогда он запустил кампанию по сбору средств на Kickstarter с первоначальной целью финансирования в размере 100000$. Подписчики получали право приобрести часы Pebble Watch по цене 115$ сразу после их выпуска, фактически получая за предзаказ скидку от полной цены в 150$. Проект собрал первоначально установленную сумму за два часа, и от желающих сделать взнос не было отбоя. В итоге Pebble прекратила сбор средств на Kickstarter после того, как более 68 тыс. человек внесли в фонд реализации этого проекта более 10 млн $.

Краудфандинговая платформа Kickstarter стала новым привлекательным каналом финансирования стартапов. Проект, предусматривающий производство гарнитур виртуальной реальности Oculus Rift, стартовал с установленной первоначальной целью сбора средств в размере 250000$ в августе 2012 года. За месяц было собрано чуть менее 2,5 млн $, что почти в 10 раз превышало целевую сумму. Менее чем через два года Facebook приобрела Oculus Rift за 2 млрд $.

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

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

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

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

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

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

Рисунок 7.3. Проектные артефакты, распределенные по степени их точности и интерактивности

Обратите внимание на Рисунок 7.4, который иллюстрирует различия между низкой и высокой точностью артефактов проекта. Оба представленных на рисунке результата проектирования относятся к одному и тому же приложению для iOS (источник: https://itunes.apple.com/us/app/pointedlysimple-score-keeper/id933257819). Это приложение, созданное талантливым UX-дизайнером Беном Норрисом, позволяет упростить процесс подсчета очков во время различных настольных игр (например, в Scrabble), заменяя использование для этой цели ручки и бумаги. В левой части рисунка показан вайрфрейм низкой точности. Он не использует каких-либо цветов (сделан в оттенках серого) и показывает только расположение элементов экрана без детализации визуального оформления. Высокоточный макет в правой части рисунка выглядит гораздо более похожим на реальный продукт (несмотря на то что его цветное изображение в печатной версии этой книги также представлено в оттенках серого). Элементам пользовательского интерфейса здесь уже придан близкий к реальному дизайн, использующий определенные цвета, шрифты и графику.

Рисунок 7.4. Вайрфрейм низкой точности в сравнении с высокоточным макетом

В левом нижнем углу Рисунка 7.3 вы можете видеть проектные артефакты, обозначенные как «Эскизы», которые характеризуются наименьшей точностью и наименьшей интерактивностью. Создание эскиза – отличный способ начать визуализировать идеи, особенно если вам нужно обсудить их с товарищами по команде и другими внутренними заинтересованными сторонами. Эскиз на доске или бумаге позволяет вносить в проект быстрые правки. Я активный сторонник использования доски для рисования, особенно на ранней стадии проектирования. На самом деле, данный метод вполне может являться идеальным инструментом бережливого производства, поскольку позволяет участникам команды осуществлять быстрые итерации своих идей. Однако, какими бы полезными ни были эскизы для внутреннего использования, слишком низкая точность не позволяет использовать их для получения обратной связи от пользователей (именно по этой причине они отсутствуют в представленной на Рисунке 7.2 матрице MVP-тестов).

Следующим по степени точности артефактом проектирования является вайрфрейм, который с низкой или средней точностью дает представление о компонентах продукта и об их местоположении. Вайрфреймы – это не «совпадающие до пикселя» отображения; скорее, они показывают относительные размеры и расположение элементов. Обычно они не содержат каких-либо деталей визуального оформления, таких как цвета, картинки и шрифты. При их создании чаще используют оттенки серого и заполнители вместо реальных изображений, чтобы не отвлекать рецензентов элементами визуального дизайна. В некоторых случаях могут также использоваться заполнители вместо реального текста – например, «lorem ipsum»[14], – хотя это становится все менее распространенной практикой. Я рекомендую с самого начала использовать реальные текстовые элементы – даже если по содержанию это будет всего лишь черновик, – чтобы заранее выявить потенциальные проблемы с версткой.

Вайрфреймы могут быть нарисованы вручную, но обычно они представляют собой цифровые артефакты, созданные с помощью программных продуктов, предназначенных для проектирования либо специальных приложений для создания вайрфреймов. Чаще всего для создания графического дизайна используют такие приложения как Illustrator и Sketch. Приложения OmniGraffle и Visio представляют собой инструменты более общего назначения. Некоторые специалисты, не являющиеся профессиональными дизайнерами, создают вайрфреймы в PowerPoint или Keynote. Я рекомендую использовать более эффективные инструменты, специально разработанные для создания вайрфреймов, такие как Balsamiq, Axure и UXPin – для веб-продуктов.

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

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

Вот некоторые признаки, указывающие на то, что вам, вероятно, следует изучить современные инструменты для создания вайрфреймов:

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

• Создаваемые вами вайрфреймы не реагируют на «клики» и нажатия клавиш.

• Ваши вайрфреймы трудно «расшаривать» для использования другими людьми.

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

• Создание вайрфреймов занимает больше времени, чем вам хотелось бы.

• Вы вообще не создаете вайрфреймы.

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

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

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

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

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

Как показано на Рисунке 7.3, следующим по степени точности артефактом проектирования являются макеты, которые гораздо больше похожи на конечный продукт, чем вайрфреймы. Макеты передают такие детали визуального дизайна, как цвета, шрифты и изображения. В некоторых случаях они должны «совпадать до пикселя» с конечным продуктом, однако необходимость в такой степени достоверности присутствует далеко не всегда. Макеты обычно создают с помощью приложений для графического дизайна, таких как Illustrator, Photoshop или Sketch.

Как и в случае с вайрфреймами, макеты могут быть статичными или интерактивными. С помощью приложений для графического дизайна обычно получают статичные файлы формата jpg, gif или png, которые по своей сути не является интерактивными. Чтобы создать набор интерактивных макетов, эти изображения объединяются с помощью другого приложения, которое позволяет создавать «горячие точки», при нажатии на которые происходит переход от одного макета к другому.

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

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

Интерактивные прототипы включают в себя гораздо большее количество функционирующих элементов управления пользовательского интерфейса, нежели интерактивные макеты. Это могут быть выпадающие меню, эффекты наведения курсора, работающие формы ввода и аудио- или видеоплееры. Для создания интерактивных прототипов используются различные инструменты разработчика. Веб-прототипы обычно создаются с использованием HTML, CSS и JavaScript. Для быстрой разработки используются популярные интерфейсные фреймворки, такие как jQuery и Bootstrap. Прототипы также могут быть созданы с использованием Ruby on Rails или других фреймворков быстрой разработки, если вам требуется облегченный функционал на стороне сервера. Мощные инструменты, такие как Axure, которые умеют экспортировать прототип в HTML, CSS и JavaScript, позволяют создавать интерактивные прототипы без использования программного кода. Прототипы под операционные системы мобильных устройств, таких как iOS или Android, могут быть созданы в HTML или в машинном коде.

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

Например, сайт по аренде жилья Airbnb использовал MVP-консьержа для улучшения своего сервиса. В своем выступлении на фестивале South By Southwest (SXSW) директор по продуктам Джо Заде рассказал, как команда Airbnb выдвинула гипотезу о том, что объявления о сдаче недвижимости, которые сопровождаются профессионально сделанными фотографиями, могут принести больше прибыли. Для проверки этой гипотезы они вручную отбирали арендодателей, которым предлагали провести бесплатную профессиональную фотосъемку сдаваемых помещений. Затем компания нанимала фотографов по месту нахождения сдаваемого жилья. Проведя фотосессию, фотографы загружали сделанные снимки в Dropbox, а сотрудники Airbnb – опять же, вручную – подгружали их к соответствующим объявлениям на сайте. В итоге команда Airbnb убедилась в том, что их гипотеза верна: количество бронирований по объявлениям, к которым прилагались профессионально сделанные фотографии, в два-три раза превышало средний уровень.

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

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

Готовый MVP также может быть протестирован на пользователях. В идеале, на пути к готовому продукту вы должны были провести все необходимые качественные тесты его проектных артефактов. Только почувствовав уверенность в том, что в достаточной степени подтвердили соответствие продукта рынку, вы приступаете к созданию реального MVP. В главе 12 я расскажу, как создавать продукт с использованием методов Agile-разработки.

Даже если вы провели все необходимые тесты артефактов на этапах проектирования, хорошей идеей будет протестировать «живой» MVP после его создания. Между этапами проектирования и разработки часто происходят какие-нибудь изменения. Поскольку для «живого» продукта характерна максимально возможная точность, по результатам его тестирования вы можете узнать от пользователей что-то новое, чего не обнаружили во время проведения тестов с более низкой точностью. Например, вы можете проверить, как ваш веб-продукт на самом деле выглядит и ведет себя на экранах разных размеров и в различных браузерах.

Вы можете протестировать свой «живой» продукт как в модерируемом режиме, так и без непосредственного участия модератора. При модерируемом тестировании вы находитесь рядом с пользователем в тот момент, когда он использует продукт. Соответственно, немодерируемый вариант подразумевает, что пользователь остается с продуктом один на один (при этом все его действия фиксируются для последующего анализа). Модерируемое тестирование может проводиться как лично, так и удаленно с применением программного обеспечения, обеспечивающего возможность совместного использования экрана, такого как Skype, WebEx или join.me. Я расскажу об этом подробнее в главе 9.

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

Тесты «Фальшивая дверь» или «Страница 404» являются хорошим способом выяснить уровень спроса на новую функцию, которую вы планируете создать. Идея состоит в том, чтобы предложить пользователям ссылку или кнопку для перехода на страницу новой функции и, таким образом, на основе количества осуществленных переходов оценить ее востребованность (в %). Это позволяет понять, действительно ли клиентам нужна данная функция, прежде чем вы потратите ресурсы на ее создание. Поскольку на момент проведения теста самой функции еще не существует, при переходе по ссылке пользователи обычно попадают на веб-страницу, где размещена благодарность за проявленный интерес и сообщение о том, что функция еще не готова для использования. Вы также можете добавить на эту страницу специальную форму для заполнения, чтобы посетитель мог поделиться своим мнением о том, почему он считает эту функцию полезной.

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

Компания Zynga, являющаяся разработчиком игр и имеющая большой опыт в области количественного тестирования продуктов, часто использует метод «фальшивых дверей». В своем выступлении на конференции Stanford Technology Ventures соучредитель Zynga, Марк Пинкус, рассказал, что его команда. собираясь протестировать новые игровые идеи, придумывает для каждой из них короткий питч из пяти слов. Затем эти питчи используются для создания рекламных ссылок, которые компания на некоторое время встраивает в свои уже существующие игры, чтобы увидеть, насколько большой интерес каждая из них вызвала у геймеров.

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

Аналитика продукта сама по себе не является тестом, но она может помочь в получении представления о том, как клиенты на самом деле используют продукт. Например, вы можете узнать, какие функции используют чаще всего и на каких веб-страницах проводят больше времени. При внедрении в продукт каких-либо усовершенствований вы можете отследить соответствующие изменения ключевых метрик продукта, чтобы проверить свои гипотезы. Аналитика продукта также является основой для A/B тестирования, поскольку аналитические методы используются для расчета метрик и сравнения результатов тестирования. Наиболее востребованными решениями для анализа продуктов являются такие инструменты, как Google Analytics, KISSmetrics, Mixpanel и Flurry.

A/B-тесты продукта или сплит-тесты используются для сравнения производительности двух альтернативных пользовательских интерфейсов (A и B), являющихся составной частью продукта. Например, предположим, что вы разработали новый процесс регистрации для своего веб-приложения, который, по вашему мнению, будет иметь более высокий процент завершений, чем прежний вариант. Вместо того чтобы просто заменить существующий процесс на новый, вы могли бы провести следующий A/B-тест: случайным образом разделить напополам поток пользовательского трафика, отправив одну половину на прежнюю версию страницы регистрации (A), а другую – на новую (B), после чего сравнить количество завершенных регистраций. Существует несколько популярных инструментов для проведения A/B-тестов: Optimizely, KISSmetrics, Visual Website Optimizer и Google Content Experiments (входит в состав Google Analytics).

Для маркетингового A/B-тестирования большинство компаний используют инструменты сторонних разработчиков. Однако, когда дело доходит до A/B-тестирования продукта, многие в конечном итоге предпочитают создавать и использовать собственные решения, чтобы добиться большей гибкости за счет совместимости программного кода. Одна из основных причин такого подхода заключается в том, что большинство инструментов для проведения A/B-тестирования написаны с использованием JavaScript, что позволяет им прекрасно взаимодействовать с клиентской частью продукта. Однако эти инструменты оказываются не столь полезны в тех случаях, когда необходимо протестировать продукт в его серверной части. Стоит отметить, что ведущие инструменты для проведения A/B-тестирования, такие как KISSmetrics, предлагают способы интеграции с вашей внутренней серверной A/B-платформой.

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

Аналитика и A/B-тестирование представляют собой мощные эмпирические инструменты, которые помогают понять поведение клиентов и соответствующим образом оптимизировать ваш продукт. Свободное владение этими инструментами обеспечивает быструю итерацию и отличает успешные команды разработчиков от других. Учитывая важность таких тем, как аналитика и A/B-тестирование, я вернусь к ним для более подробного рассмотрения в главах 13 и 14.

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

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

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

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

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

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

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

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

Чем больше усилий требуется для выполнения того или иного действия, тем ниже доля пользователей, которые будут выполнить это действие.

Чем меньше усилий требуется для выполнения действия, тем выше доля пользователей, выполняющих это действие.

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

В дополнение к объективным поведенческим показателям, о которых я упоминал выше, важно иметь представление о том, насколько простым или сложным в восприятии пользователей является использование вашего продукта. Например, вы можете спросить их: «Насколько прост или сложен продукт в использовании?» – и попросить дать оценку по 7-балльной биполярной шкале:

1. Очень сложен.

2. Сложен.

3. Немного сложен.

4. Не прост и не сложен.

5. Скорее прост.

6. Прост.

7. Очень прост.

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

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

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

Вторым ключевым атрибутом отличного пользовательского опыта является удовольствие от использования продукта. Хорошее юзабилити помогает избежать плохой оценки UX, но его одного недостаточно для обеспечения отличной оценки пользовательского опыта. Если удобство использования дает ответ на вопрос «Могут ли клиенты использовать ваш продукт?», то наличие или отсутствие удовольствия от использования позволяет понять, нравится ли клиентам пользоваться вашим продуктом. Удовольствие, выходящее за рамки просто отсутствия разочарования, говорит о появлении положительных эмоций. Клиентам приятно пользоваться теми продуктами, которые их радуют.

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

Иногда удовольствие от использования достигается за счет простоты пользовательского интерфейса. В UX-дизайне меньше часто означает больше – устранение визуального беспорядка снижает когнитивную нагрузку на пользователя и помогает ему сосредоточиться на том, что действительно важно. Достаточно вспомнить минималистичный дизайн домашней страницы Google, на которой нет ничего, кроме поисковой строки.

Пользовательский опыт, при взаимодействии с которым появляется впечатление, будто он умеет читать ваши мысли, тоже доставляет пользователю удовольствие. Использование разумно выбранных установок по умолчанию или проактивных ответов на популярные вопросы может вызывать ощущение понимания и сопричастности. Google Suggest, описанный в главе 5, является хорошим примером такого подхода.

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

Удовольствие от использования часто достигается за счет ответной реакции продукта на действия пользователя. Отличным примером является эффект «резиновой ленты», которым интерфейс iOS откликается на попытки пользователя прокрутить сверх допустимого предела отображаемый на экране документ или веб-страницу. Это настолько забавный эффект, что многие люди – сознательно или нет – вызывают его на экране своих устройств снова и снова. Анимация и звуковые эффекты тоже могут вызывать восторг. Я знаю, что многим пользователям Quicken нравится слышать звук кассового аппарата «ка-цзинь» после совершения каждой финансовой транзакции. Сигнал запуска Apple Mac – это еще один звук, который вызывает положительные эмоции у многих пользователей.

Удивление – важная составляющая удовольствия. Ваш продукт может вызывать положительные эмоции у пользователей, делая неожиданные для них вещи. В первые дни существования Twitter его платформа испытывала частые перегрузки. Вместо того чтобы показывать пользователям в таких случаях скучную страницу с сообщением об ошибке, разработчики демонстрировали им ставшую широко известной картинку с терпящим бедствие китом – «fail whale»[15].

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

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

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

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

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

Разработать хороший концептуальный дизайн проще, когда у вас есть глубокое понимание целевых клиентов и их потребностей. Важной, но часто упускаемой из виду составляющей UX является «U»: пользователь[16]. Вы наверняка помните, что пирамида соответствия продукта рынку начинается с целевого потребителя; человека, для которого вы разрабатываете свой продукт.

Вы получаете представление о своем целевом клиенте путем проведения исследований пользователей, которые являются специфическим разделом UX-дизайна. В ходе таких исследований применяется целый ряд методов получения информации о клиентах, такие как установочное интервью, юзабилити-тесты и опросы. В главе 4 я поделился своими рекомендациями по поводу проведения интервью для выявления целевых потребителей. В главе 9 описываются методики проведения собеседований с клиентами для получения от них ценных отзывов о ваших проектах. В главе 13 представлен фреймворк для проведения исследования пользовательского опыта и описаны другие методы получения обратной связи (помимо интервью). Исследование пользователей охватывает все уровни UX-айсберга. Когда клиенты оставляют отзывы, относящиеся к пользовательскому опыту вашего продукта, бывает весьма полезно проанализировать полученную информацию и сопоставить ее с соответствующим слоем айсберга UX-дизайна.

При проведении исследования пользователей, очень важно убедиться, что оно не замыкается на самом исследователе. Члены команды разработчиков должны принимать в этом самое непосредственное участие. Личное участие в проводимых исследованиях гораздо более эффективно, чем просто чтение итогового отчета. Это можно сравнить с разницей между просмотром футбольного матча на стадионе в непосредственной близости от происходящих на поле событий и чтением газетной статьи с обзором состоявшегося матча. «Разборы полетов», во время которых члены команды разработчиков обсуждают свои наблюдения, максимально способствуют усвоению собранного материала и должны проводиться сразу после проведения исследования. Документирование кратких результатов и ключевых выводов также важно для закрепления полученной информации и передачи ее всем заинтересованным лицам. Одним из наиболее полезных результатов исследования пользователей является создание персонажей.

Без знания своих целевых потребителей невозможно создать для них превосходный пользовательский опыт. В UX-дизайне для осуществления такого близкого знакомства используется метод персонажей, который был описан ранее в главе 3 в контексте идентификации целевых потребителей (см. Рисунок 3.1). Напомню вкратце, что персонаж – это архетип реальных пользователей вашего продукта. Грамотно составленный профиль персонажа содержит описание потребностей целевого пользователя, а также соответствующие ему психографические, поведенческие и демографические характеристики. Персонажи помогают принимать более обоснованные решения при разработке продукта, который обеспечивает потребительские преимущества в рамках сформированного вами ценностного предложения.

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

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

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

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

Следующим (вторым снизу) слоем айсберга UX-дизайна является информационная архитектура. Этот термин часто используется в сокращении – IA. Это составляющая проектирования, ответственная за определение того, как должны быть структурированы информационная и функциональная части программного продукта. Обычно в состав продукта входят несколько страниц или экранов, поэтому существует множество способов их организации. Клиент получает доступ к различным экранам, используя встроенную в приложение навигационную систему. При поиске определенной страницы пользователь полагается на навигационные метки, чтобы понять, как организован продукт и где находится нужная ему страница. С целью выяснить мнение пользователей о взаимной связанности различных компонентов продукта и определить предпочитаемую ими схему организации часто используется метод, который называется «Сортировка карточек». Хорошо продуманная информационная архитектура организует внутренние компоненты продукта интуитивно понятным пользователям образом, снабжает их легко понятными указателями, что в совокупности обеспечивает высокий уровень юзабилити и результативности поиска.

Под результативностью поиска следует понимать, насколько легко пользователям продукта удается найти предмет своих поисков. Чтобы измерить этот показатель, вы могли бы попросить группу участников тестирования найти внутри вашего продукта определенную страницу или экран, после чего высчитать процент успешных попыток. Вы также можете оценить результативность поиска, просмотрев шаблоны навигации с использованием аналитических инструментов. Это позволит получить ответы на такие вопросы, как «Всегда ли пользователи выбирали кратчайший путь, чтобы попасть на нужную страницу? Или они добирались до цели обходными путями и часто нажимали кнопку “Назад” в своем браузере?»

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

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

Каждый прямоугольник на этой карте обозначает определенную страницу. Соединительные линии показывают пути навигации между страницами. В некоторых случаях навигация предполагается односторонней, что обозначено стрелкой (см. условные обозначения на левой стороне). Элементы глобальной навигации – страницы, на которые пользователь может перейти из любого места, – четко определены. Уровень элементов глобальной навигации, расположенный в верхней части карты, включает в себя основные разделы продукта. Ниже показаны страницы, на которые попадают пользователи, когда переходят по ссылкам с верхнего уровня. Для каждого раздела сайта, входящие в него страницы показаны в иерархическом порядке. Кроме этого, на карте обозначено, какие страницы ведут себя нестандартным образом – открываются во всплывающем окне либо в новой вкладке браузера.

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

Рисунок 8.2. Пример карты сайта

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

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

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

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

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

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

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

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

Основное взаимодействие приложения и пользователя заключается в демонстрации вопросов и получении ответов в интерфейсе пошагового прохождения. Переход к следующему вопросу осуществляется нажатием кнопки «Далее». Пошаговый процесс продолжается до тех пор, пока не будет собран весь объем информации, необходимый для заполнения налоговой декларации. Благодаря тщательно продуманному интерактивному дизайну TurboTax облегчает пользователям выполнение этой сложной задачи. Работа в режиме «Легкий шаг» также позволяет опытным пользователям перепрыгивать с одного этапа заполнения на другой, внося необходимую информацию по своему усмотрению.

«Легкий шаг» является основным режимом работы продукта, установленным по умолчанию. Еще один режим работы приложения, который называется «Формы», предоставляет доступ к реальным налоговым формам и рабочим листам, поля которых предзаполнены в соответствии с ответами, которые были даны пользователем в режиме «Легкий шаг». При этом каждое из внесенных числовых значений может быть отредактировано. Таким образом, пользователи TurboTax могут по своему желанию составить декларацию, пройдя через процедуру вопросов-ответов, без перехода в режим ручного заполнения налоговых форм либо заполняя необходимые поля самостоятельно. При этом приложение позволяет пользователю легко переключаться между режимами. Многие в итоге даже не видят заполняемые формы; режимом непосредственного заполнения пользуются, как правило, только те, кто имеет необходимый для этого опыт. Благодаря использованию двух различных режимов работы интерактивный дизайн TurboTax позволяет с помощью одного и того же продукта эффективно удовлетворять потребности как начинающих, так и опытных пользователей.

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

На Рисунке 8.3 показан пример блок-схемы, разработанной талантливым UX-дизайнером Кристин Лью (источник: http://christineliu.info) для мобильного приложения CarMax. Это приложение помогает пользователю выбрать понравившийся автомобиль, а затем связаться с дилерским центром CarMax. Приложение использует данные, содержащиеся в профиле пользователя на Facebook, чтобы предложить автомобили, которые могут ему понравиться. Пользователи могут просматривать предлагаемые варианты автомобилей, включая их подробные характеристики, пока не найдут тот, что им понравится. На этом этапе они могут связаться с дилером CarMax по электронной почте, через онлайн-чат или по телефону, чтобы запланировать свой визит в дилерский центр. Блок-схема начинается с этапов загрузки и запуска приложения, а затем показывает пути, по которым пользователь может перемещаться между различными экранами вплоть до получения конечного результата. Обратите внимание, что блок-схема описывает верхний уровень пользовательского опыта, не вдаваясь в детали дизайна отдельных экранов (такие как расположение элементов или визуальный дизайн).

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

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

Рисунок 8.3. Пример блок-схемы

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

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

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

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

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

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

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

Применение цвета улучшает эстетическое представление продукта и позволяет при необходимости делать акценты на отдельных элементах, расположенных на его страницах. Вы также можете использовать цвет для передачи определенных атрибутов или эмоций. Теплые цвета, такие как красный, оранжевый и желтый, обычно воспринимаются как более энергичные и страстные, в то время как более приглушенные холодные цвета, такие как зеленый, синий и фиолетовый, выглядят более спокойно и сдержано. Многие приложения и веб-сайты используют синюю цветовую гамму, потому что она вызывает ощущение надежности и спокойствия. Зеленый цвет ассоциируется с природой, ростом и деньгами. Фиолетовый связан с роскошью и креативностью. Красный ассоциируется с агрессией, страстью, властью и опасностью. Оранжевый цвет – энергичный и яркий. Желтый символизирует счастье и солнечный свет. Коричневый ассоциируется с теплом и землей. Черный намекает на утонченность, элегантность и загадочность. Белый цвет ассоциируется с чистотой, непорочностью и простотой. Я перечислил распространенные обобщения, при этом восприятие цветов может существенно различаться в разных странах мира. Поэтому, если ваши целевые пользователи принадлежат к определенной культуре, при разработке дизайна следует обратить внимание на возможные особенности восприятия того или иного цвета.

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

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

Типографика определяет расположение и внешний вид текста и является еще одним важным элементом визуального дизайна продукта. На заре существования интернета браузеры поддерживали лишь небольшое количество шрифтов, таких как Arial, Georgia и Verdana. Но широкое внедрение веб-шрифтов CSS3 обеспечило дизайнерам огромное богатство выбора.

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

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

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

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

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

Иконки – это небольшие символы, используемые для представления объектов или смысловых понятий. Чаще всего они используются для кнопок или других элементов управления пользовательского интерфейса, особенно при нехватке свободного места. Во многих приложениях иконки являются основным способом обозначения кнопок управления. В браузерах иконки используют для таких часто используемых кнопок, как «Назад», «Вперед» и «Обновить». Adobe Photoshop использует панель инструментов, состоящую из иконок, в качестве основного способа обеспечения доступа клиентов к функционалу этого программного продукта. Аналогичным образом продукты Microsoft Office используют «ленту», наполненную иконками. Помимо элементов управления, иконки используются также на маркетинговых страницах как дополняющие и усиливающие приведенный там текст. Иконографика – это особый раздел визуального дизайна; создателям иконок приходится вручную прорисовывать отдельные пиксели, чтобы явить миру свои крошечные шедевры. Важность иконок возросла с расширением использования мобильных устройств. Небольшой размер экрана в еще большей степени заставляет разработчиков мобильных приложений экономить место; поэтому многие элементы управления в таких приложениях представляют собой иконки.

Одна из особенностей применения иконок состоит в том, что пользователи должны с первого взгляда распознавать их значение. Учитывая маленький размер иконки и отсутствие сопроводительного текста, добиться этого далеко не просто. Соответственно, если для обозначения какого-либо элемента дизайна уже существует стандартная иконка, я настоятельно рекомендую вам использовать именно ее вместо попыток изобрести новый символ. Допустим, вы создаете приложение, которое воспроизводит аудиозаписи, и подбираете иконки для кнопок воспроизведения и паузы. В этом случае совершенно неразумно создавать свои собственные обозначения, когда всем пользователям хорошо знакомы: указывающий вправо треугольник, означающий «воспроизведение», и две вертикальные линии, обозначающие кнопку «пауза».

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

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

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

Вы можете подобрать размер сетки, наиболее подходящий для вашего макета. На Рисунке 8.4 представлен пример компоновочной сетки, состоящей из 12 столбцов шириной по 94 пикселя каждый, разделенных желобами шириной в 18 пикселей. Общая ширина сетки составляет в этом случае 1326 пикселей и оптимизирована для экранов шириной в 1366 пикселей, чтобы пользователям не приходилось при просмотре сдвигать страницу по горизонтали. Такая ширина макета позволяет разместить дополнительно вертикальную полосу прокрутки и любые другие визуальные элементы интерфейса браузера или операционной системы, имеющие размер до 40 пикселей.

Рисунок 8.4. Пример компоновочной сетки

Основное преимущество компоновочной сетки состоит в том, что она позволяет выравнивать размещение всех элементов страницы или экрана по мере их добавления. Примерами элементов страницы или экрана могут служить текстовые блоки, изображения или кнопки. Элементы могут занимать более одного столбца. Главное, чтобы левая и правая границы элементов начинались и заканчивались на линиях сетки. Взятая нами для примера сетка, состоящая из 12 столбцов, может быть равномерно поделена по 2, 3, 4 и 6 столбцов, что допускает широкий диапазон возможных размеров элементов. На Рисунке 8.5 представлен пример вайрфрейма, который создан с использованием компоновочной сетки для размещения элементов страницы.

Рисунок 8.5. Вайрфрейм, созданный с использованием компоновочной сетки

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

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

Макеты, которые мы уже рассматривали в главе 7, – это высокоточные результаты проектирования, представляющие визуальный дизайн. Они основаны на предварительно разработанных вайрфреймах и используют цветовую палитру, элементы типографики и графики для создания внешнего вида продукта. Макеты обычно создаются визуальным дизайнером с помощью таких инструментов, как Adobe Illustrator или Sketch, а затем экспортируются в графические файлы (PNG, GIF или JPG). Вы можете использовать такие статичные макеты для получения обратной связи от пользователей, однако тестирование с использованием кликабельных макетов принесет гораздо большую пользу. Они дают пользователям лучшее представление о продукте и о том, как он работает. Такие инструменты, как InVision, позволяют преобразовать набор статичных макетов в пользовательский поток. С помощью этого и ему подобных инструментов вы можете определить область макета, доступную для клика или нажатия (например, разместив там кнопку или ссылку), и указать, к какому следующему макету должен быть осуществлен переход по этой ссылке. В главах 9 и 10 рассказывается, как организовать получение отзывов пользователей о макетах и использовать результаты тестирования для итеративного улучшения ваших проектов. Как только у вас появится набор кликабельных макетов, которые, по оценке целевых потребителей, достаточно просты в использовании и соответствуют ценностному предложению, этап разработки UX-дизайна будет завершен. Следующим шагом станет реализация пользовательского опыта путем создания продукта. В главе 12 обсуждается, как это сделать с использованием принципов Agile-разработки.

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

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

Гештальт-принципы – это совокупность полезных теорий о визуальном восприятии объектов. Само слово «гештальт» означает «целостную структуру, образ, который, хотя и состоит из множества частей, воспринимается как нечто единое целое». Это то, к чему наша мыслительная система визуальной обработки пытается свести все то, что мы видим. Существует несколько принципов гештальта, но я сосредоточусь лишь на двух из них: принципах близости и подобия.

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

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

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

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

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

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

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

В дополнение к принципам гештальта и визуальной иерархии при создании и оценке дизайна необходимо учитывать следующие композиционные принципы:

1. Единство: Воспринимается страница или экран как единое целое или как набор разрозненных элементов?

2. Контраст: Имеется ли достаточно различий в цвете, размере, расположении и так далее, чтобы это вызывало визуальный интерес?

3. Баланс: Равномерно ли распределен визуальный вес (положение, размер, цвет и так далее) элементов в дизайне?

4. Использование пространства: Насколько загроможденным или разреженным выглядит дизайн? Убедитесь, что на странице/экране оставлено достаточное количество свободного места – неиспользуемого пространства, – чтобы дизайн не выглядел перегруженным.

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

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

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

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

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

У вас может возникнуть вопрос: на какой размер экрана (большой или маленький) следует ориентироваться, начиная процесс разработки UX-интерфейса? Если вы изначально разрабатывали свой продукт под экран большего размера, адаптация его к меньшему экрану может оказаться непростой задачей. Созданный объем контента может просто не поместиться на маленьком экране, и вам придется делать трудный выбор – определить элементы, которые придется удалить. Вероятно, вы будете вынуждены изменить и систему навигации. Необходимо будет пересмотреть и переделать контент, размер которого слишком широк для маленького экрана. Поэтому в подобных случаях разработчики часто создают отдельный продукт, переписывая программный код. Однако такое решение не является идеальным. Во-первых, необходимость в дальнейшем каждый раз вносить изменения и дополнения в два отдельных фрагмента кода приводит к снижению эффективности и увеличению вероятности ошибок. Во-вторых, разработанные по отдельности мобильная и немобильная версии продукта часто оказываются настолько непохожими друг на друга, что это приводит к неорганичности пользовательского опыта, вызывая у клиентов непонимание и раздражение.

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

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

Как правило, в дополнение к демографическим поведенческие атрибуты имеют не менее важное значение. Например, если вам для тестирования требуются заядлые любители видеоигр, логично было бы спрашивать респондентов: «Играете ли вы в видеоигры?» – отфильтровывая тех, кто выбрал ответ «нет». Затем вы могли бы спросить ответивших «да»: «Сколько часов в неделю вы обычно играете в видеоигры?» При этом респондентам предлагалось бы сделать выбор из списка возможных вариантов ответов. Например таких: «менее пяти часов в неделю», «от 5 до 10 часов в неделю», «от 10 до 20 часов в неделю», «от 20 до 30 часов в неделю» и, наконец, «более 30 часов в неделю». Вы можете решить для себя, что геймерами вы признаете тех, кто играет не менее 20 часов в неделю. Соответственно, в список участников вашего тестирования попадут только те, кто выбрал какой-то из двух последних вариантов ответа.

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

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

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

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

Один из способов заключается в привлечении местных пользователей вашего продукта путем размещения онлайн-объявлений на Craigslist, TaskRabbit и им подобных веб-сайтах. Рекомендуется включать в объявление ссылку на онлайн-опрос, размещенный на SurveyMonkey, Google Forms или других опросных сайтах, содержащий подготовленные вами вопросы для фильтрации участников. Количество откликов может сильно варьироваться в зависимости от места публикации объявления и размера предлагаемого вознаграждения.

Если количество откликов вас не устраивает, можно прибегнуть к практике дистанционного тестирования, которое позволяет выйти за пределы местного рынка и привлечь любого онлайн-пользователя. Некоторые компании используют Mechanical Turk от Amazon (MTurk) в качестве инструмента для набора участников дистанционного тестирования. Там есть несколько сервисов, которые упрощают эту задачу. Многие приложения для дистанционного тестирования, такие как UserTesting, показывают профили пользователей, доступных для участия в тестировании. При этом объем доступной информации о потенциальных участниках может различаться. Некоторые сервисы предоставляют лишь общие данные, такие как пол, возраст, статус занятости и так далее; в то время как другие позволяют вам задавать пользователям свои собственные вопросы. При выборе приложения для удаленного тестирования убедитесь, что данный сервис предоставляет вам достаточную свободу в выборе задаваемых вопросов. Получение отзывов от клиентов, которые не относятся к целевому рынку – это пустая трата времени и денег, которая к тому же может увести вас в неверном направлении.

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

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

Существуют также компании, постоянно занимающиеся исследованием потребителей. Многие из них имеют постоянную аудиторию, из которой они могут набирать кандидатов для участия в очном тестировании. Такие компании часто предлагают комплексные услуги, которые включают в себя предоставление средств тестирования и модератора, но обычно вы можете просто заплатить им за подбор участников тестирования по указанным критериям. Цена за каждого респондента может варьироваться, но обычно составляет от 75 до 150$. Если ваши целевые клиенты относительно малочисленны и высоко ценят свое время – скажем, кардиохирурги или руководители компаний, – их привлечение может обойтись намного дороже или просто оказаться невозможным. По моему опыту, обращение в исследовательские компании – отличный способ привлечь местных пользователей для участия в очном тестировании. Главным недостатком является стоимость. Но получение ценной обратной связи часто с лихвой компенсирует затраты, особенно если вы хорошо поработали при подготовке скрининга и провели удачное тестирование.

Довольно часто я сталкиваюсь с тем, что многие компании, которые хотят проводить тестирование на пользователях, испытывают трудности с логистикой планирования. Команды, работающие над продуктом, большую часть своего времени трудятся, не поднимая головы, над определением ценностного предложения, написанием пользовательских историй и разработкой вайрфреймов. Когда они оказываются готовы протестировать результат своего труда на пользователях, они, наконец, отрываются от созидательной работы и пытаются на скорую руку собрать пользователей. Однако набрать подходящих пользователей по щелчку пальцев обычно не получается. К этому моменту команда разработчиков, скорее всего, еще даже не задумывалась о скрининге или сценарии для тестирования. Если у команды нет специального сотрудника, занимающегося отбором и привлечением участников тестирования, эти обязанности часто ложатся на плечи продакт-менеджера или дизайнера. При этом у обоих и без того полно работы. Может пройти неделя или две (или больше), прежде чем все будет готово для проведения первого раунда тестирования. За это время команда, которая, скорее всего, находится под жестким прессингом со стороны требующего результатов руководства, поддается давлению и приступает к разработке высокоточного дизайна или даже написанию программного кода. Таким образом, к моменту получения результатов тестирования на пользователях, возможность безболезненного внесения в продукт каких-либо изменений будет упущена. После завершения одного или двух этапов разработки история с запаздывающим тестированием повторяется. Это в итоге ведет к полному разочарованию – сокращению итераций или даже полному отказу от проведения тестов на пользователях.

Как должна поступать команда разработчиков, придерживающаяся принципов бережливого производства?

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

Если вы сторонник партизанской тактики, вам подойдет вариант, который я называю «тестированием на посетителях Starbucks». Суть данного метода заключается в том, что вы проводите тестирование, набирая для него участников прямо в кафе. Его основными преимуществами являются низкая стоимость и оперативность. Главный же недостаток такого тестирования заключается в том, что в этом случае вы не можете контролировать принадлежность его участников к целевой аудитории. Конечно, если ваш продукт так же популярен, как, скажем, Google или Facebook, вполне вероятно, что, даже не выходя из кафе, вы сможете найти достаточное число представителей целевого рынка. Однако такой подход, скорее всего, не сработает, если речь идет о тестировании более специфического продукта. Вы можете лишь попытаться провести визуальный отбор потенциальных потребителей на основании их внешнего вида (например, по полу, примерному возрасту, стилю одежды, и т. п.).

Будьте готовы к изрядному количеству отказов; многим людям не нравится, когда к ним обращаются незнакомцы, или же они могут быть слишком заняты. Лично я считаю хорошей альтернативой кафе торговые центры, поскольку там люди кажутся менее занятыми и более открытыми. При этом решающее значение для получения согласия на участие в тестировании от незнакомого вам человека имеет ваша вступительная фраза. Возьмите за правило быстро информировать людей о том, что вам от них требуется, и какую компенсацию вы можете предложить за потраченное ими время. Например, вы можете использовать следующую фразу: «Здравствуйте, не найдется ли у вас 10 минут, чтобы поделиться своим отзывом о новом веб-сайте в обмен на карточку Starbucks стоимостью 25$?»

Кстати, об оплате. Сколько вы должны заплатить участникам тестирования за потраченное ими время? Обычно диапазон размера вознаграждения составляет от 75 до 125$ за час, но многое зависит от того, кто является вашими целевыми клиентами, и сколько стоит их время. Интервью с кардиохирургом, вероятно, обойдется вам гораздо дороже названных выше сумм, в то время как беседа со старшеклассником стоила бы гораздо дешевле. Многие изобретательные стартапы умудряются нанимать тестировщиков без выплаты какой-либо денежной компенсации, просто находя людей, проявляющих повышенный интерес к их продукту. Я, как и многие другие разработчики, использовал в качестве «заманушного пряника» эксклюзивный доступ к бета-версии продукта. Если у вашей компании есть возможность использовать в качестве вознаграждения свои «мерчи» (например, футболки, толстовки с капюшоном или спортивные куртки с вашей символикой), это тоже может сработать.

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

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

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

Давайте вернемся к примеру, который был представлен в главе 9. Для начала мы обобщим результаты первого раунда тестирования с участием пяти пользователей в одном столбце Таблицы 10.1. Вы можете заметить, что я удалил из результатов положительные отзывы. Это сделано для упрощения. Итак, по результатам первого раунда тестирования мы выявили четыре проблемы:

1. 80 % пользователей пожаловались на отсутствие функции Y;

2. 60 % пользователей не нашли ссылку «Зарегистрироваться»;

3. У 60 % пользователей возникли трудности с регистрацией;.

4. 40 % пользователей не поняли наш слоган.

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

Таблица 10.1 Отслеживание результатов нескольких раундов пользовательского тестирования

Тот факт, что пользователи не нашли ссылку «Зарегистрироваться», является проблемой визуального дизайна. Чтобы ее исправить, наш визуальный дизайнер перенесет ссылку на более видное место, увеличит ее размер и отобразит в виде кнопки, используя при этом цвет, который будет хорошо заметен на экране.

Трудности с регистрацией относятся к проблемам дизайна интерактивности. Для устранения данной проблемы решено изменить процесс регистрации с учетом мнений пользователей.

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

Теперь, когда четыре проблемы, выявленные в первом раунде, устранены, мы можем вновь провести тестирование нашего продукта на пользователях. Полученные результаты фиксируем в столбце «Раунд 2» Таблицы 10.1. Мы видим, что после добавления функции Y никто из новых пользователей не пожаловался на ее отсутствие, что, конечно же, свидетельствует о значительном прогрессе в этом направлении. Еще одним серьезным достижением является тот факт, что все пять участников второго раунда тестирования на этот раз обнаружили ссылку «Зарегистрироваться».

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

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

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

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

При правильном подходе каждое повторение цикла должно приводить к уменьшению масштаба и количества проблем. В данном случае между первым и вторым раундами тестирования мы успешно решили три проблемы: отсутствия функции 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. Это захватывающий переход. Он в значительной степени приближает вас к созданию реальной потребительской ценности в виде живого продукта, а также позволяет выйти на следующий уровень тестирования.

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

После создания реального продукта весьма полезно провести еще один раунд тестирования, чтобы понять, где вы находитесь на этот момент. Результатом должно стать подтверждение или повышение степени соответствия продукта рынку по сравнению с оценками, полученными на последнем этапе тестирования с использованием проектных артефактов. Если этого не происходит, необходимо будет повторять цикл «Гипотеза – Проектирование – Тестирование – Обучение» уже с живым продуктом до достижения требуемых результатов. Многие компании используют на этом этапе закрытое бета-тестирование, когда с продуктом может ознакомиться лишь ограниченное число клиентов. Это происходит до тех пор, пока ваше детище не будет полностью готово к выходу в свет.

После подготовки макетов пришло время перейти к шагу 6: тестированию на пользователях. На этом этапе нам требовалось уточнить идентификацию нашего целевого клиента, прежде чем приступать к подбору участников тестирования. Поскольку у нас было два разных MVP, каждый со своим собственным ценностным предложением, нам, соответственно, пришлось идентифицировать целевых клиентов для каждого из имеющихся вариантов продукта. Целевыми клиентами и в том, и в другом случае мы по-прежнему считали широкий круг потребителей, но с некоторыми уточнениями. Для «Маркетингового щита» это должны были быть люди, которые высоко ценят свою конфиденциальность. Целевые потребители версии «Маркетинговая экономия», по нашему мнению, должны были придавать большое значение экономии денег при покупках и получению выгодных скидочных предложений.

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

Во-первых, я хотел, чтобы участники тестирования были работающими людьми с полной занятостью (не менее 30 часов в неделю). Многие безработные и пенсионеры с удовольствием принимают участие в маркетинговых исследованиях, поскольку располагают достаточным для этого количеством свободного времени, но они не слишком подходят под описание наших целевых клиентов. Вторым критерием был уровень образования – не ниже среднего и, кроме того, я старался соблюсти образовательный баланс, чтобы обеспечить соответствие участников тестирования нашей целевой аудитории. Участники тестирования должны были представлять домохозяйства с доходом не менее 40000$. Они также должны были иметь домашний компьютер и пользоваться интернетом, по крайней мере несколько часов в неделю (поскольку наша услуга должна была предоставляться через интернет). Мы также хотели убедиться, что они недавно совершали какую-либо онлайн-покупку (чтобы у них не было трудностей и предубеждений по поводу оплаты услуг онлайн). На мой взгляд, всем этим критериям мог соответствовать обычный работающий человек, являющийся потребителем веб-сервисов.

Наконец, мне необходимо было решить, к какой именно целевой группе («Щит» или «Экономия») следовало отнести того или иного участника тестирования. В этом случае в качестве критерия я решил использовать прошлое поведение участников. Поскольку несомненным преимуществом версии «Маркетинговая экономия» была экономия денег при покупках, для отбора участников этой группы я предусмотрел вопросы, связанные с различными способами экономии:

• Использовали ли вы три или более скидочных купона за последние три месяца?

• Являетесь ли вы членом клуба Costco[21]?

• Совершали ли вы покупки на eBay за последние шесть месяцев?

• Совершая покупки, вы тратите время на то, чтобы убедиться в том, что нашли самую низкую цену?

За каждый ответ «да» респондент получал один балл. Мы исходили из того, что каждый, кто наберет, как минимум, два балла, относится к целевому рынку версии «Экономия».

Аналогичным образом, основываясь на том, что «Маркетинговый щит» в первую очередь был направлен на обеспечение конфиденциальности и безопасности, кандидаты для включения в эту группу отвечали на следующие тематические вопросы:

• Вы когда-нибудь отправляли запрос на отказ от маркетинговых звонков?

• Используете ли вы блокировку нежелательных звонков в своем телефоне?

• Есть ли у вас дома уничтожитель документов?

• Пользовались ли вы за последние шесть месяцев платными антивирусными приложениями?

Респонденты также получали по одному баллу за каждый ответ «да», и целевым клиентом для версии «Маркетинговый щит» считались те, кто наберет два или более балла.

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

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

Затем мы составили график проведения тестовых сессий. Поскольку мы имели дело с людьми, которые были заняты полный рабочий день, было выбрано вечернее время (6 и 8 часов вечера). Одна из распространенных ошибок, которую совершают компании-разработчики, заключается в том, что для своего удобства они проводят тестовые сессии в рабочее время. Если для ваших целевых клиентов это не является проблемой, тогда это нормально. Но для большинства работающих людей такой график не является удобным. Результатом подобной ошибки может стать искажение типа пользователей, участвующих в тестировании, до такой степени, что они не будут достаточно репрезентативно представлять целевых клиентов.

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

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

1. Знакомство и разминка (5 минут).

2. Общие вопросы для ознакомления (15 минут).

a. Прямая маркетинговая рассылка.

b. Данные о вас, которыми располагают маркетинговые компании.

c. Сравнение своего потребительского поведения с другими людьми.

3. Вопросы, относящиеся к конкретной концепции (версии) (общее время – 45 минут).

d. Ознакомительные вопросы, связанные с основной темой концепции (10 минут).

e. Обратная связь по представленным макетам версии (35 минут).

4. Обзор: Что вам больше всего понравилось/не понравилось в том, что вы увидели? (5 минут).

5. Мозговой штурм: что сделало бы данный продукт более полезным/ценным? (10 минут).

6. Обратная связь по возможным названиям продуктов (10 минут).

7. Благодарности и прощание.

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

В течение трех вечеров я модерировал по две сессии, в каждой из которых должны были принимать участие три пользователя. Первая половина сессий была посвящена версии «Маркетинговый щит», а вторая – версии «Маркетинговая экономия». Таким образом, с каждой из концепций должны были ознакомиться по девять участников тестирования. В итоге из-за двух неявок нам удалось протестировать каждую версию продукта на восьми пользователях. Как я уже упоминал, все данные в используемых макетах были персонализированными под каждого из участников. Поскольку этот этап тестирования проводился до разработки интерактивных макетов, я распечатал каждый макет на бумаге. Страницы макетов были уложены стопками перед каждым из участников в нужном порядке. Я следовал своему скрипту и, по мере того как пользователи просматривали макеты, переворачивал страницы.

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

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

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

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

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

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

Основываясь на собранной информации, мы решили отказаться от нашего изначального ключевого ценностного предложения – «раскрытия известной маркетологам информации о пользователе» – и сосредоточиться на сервисе блокировки нежелательной почты. Предварительно мы назвали его JunkmailFreeze. На тот момент мы определили для себя три варианта дальнейших действий. Первый состоял в том, чтобы разработать новый набор макетов, протестировать их на пользователях и перейти к созданию продукта. Второй вариант предусматривал разработку прототипа с более высокой точностью в HTML и CSS для тестирования на пользователях до создания продукта. Третий вариант подразумевал проектирование и создание продукта, не утруждаясь повторным тестированием на пользователях.

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

Мы выбросили наши старые макеты и приступили к разработке нового продукта, ориентированного на сокращение количества нежелательной почты, с дополнительным преимуществом – сохранением деревьев. Для нового прототипа MVP мы разработали довольно простой пользовательский опыт. Он начинался с электронного письма от друга, рекомендовавшего JunkmailFreeze. В письме была ссылка на домашнюю страницу, на которой объяснялись преимущества продукта и имелась большая кнопка для перехода «Начать». Кроме этого, на странице присутствовала еще одна ссылка: «Узнать больше». Нажатие кнопки «Начать» переносило пользователя на простенькую страницу регистрации, где он вводил свое имя, домашний адрес, адрес электронной почты и пароль. После нажатия кнопки «Зарегистрироваться» пользователь переходил на страницу «Моя учетная запись», где мог указать, какие типы «спама» он больше не желает получать. Мы создали и другие страницы, на которых объяснялись преимущества использования JunkmailFreeze; но данная страница была ключевой, поскольку именно на ней происходило взаимодействие пользователя с продуктом для получения предлагаемых преимуществ. До того как мы провели первый раунд пользовательского тестирования, мы считали, что это преимущество заключается просто в сокращении количества получаемой нежелательной почты.

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

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

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

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

Наконец, мы также узнали, что многие клиенты считают назойливой местную рекламу. Одной из форм «спама» были пачки скидочных купонов от локальных магазинов, которые многие получатели выбрасывали, даже не открывая. Сюда же относились рекламные листовки из местных супермаркетов. Участники тестирования также жаловались на то, что им присылают бесплатные местные газеты, на которые они не подписывались. Это отличный пример того, как общение с целевыми пользователями помогает получить более четкое представление о проблемном пространстве. Мы узнали так много, что наша обновленная страница «Моя учетная запись» предоставляла пользователю возможность выбора для блокировки из списка, содержавшего более 30 различных видов «спама», разделенных на семь категорий. После того как пользователь отмечал, какие виды нежелательной почты он хотел бы заблокировать, оставалось нажать кнопку «Продолжить», чтобы завершить регистрацию.

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

На этой же странице объяснялось, что пользователи могут вернуться в JunkmailFreeze в любое время, чтобы изменить свой выбор типов блокируемого «спама». Это также стало реакцией на пожелания, высказанные участниками первого раунда тестирования. Несколько человек выразили обеспокоенность тем, что, заблокировав нежелательную почту, они могут непреднамеренно отказаться от рассылок, которые на самом деле хотели бы получать. Увидев сообщение о возможности изменения настроек блокировки, большинство пользователей удовлетворенно кивали или говорили: «Звучит неплохо».

Мы также предоставили возможность получения дополнительной информации для тех потенциальных клиентов, которые не были готовы зарегистрироваться сразу. На странице «Узнать больше» мы объяснили, каким образом JunkmailFreeze от имени пользователя связывается с компаниями, осуществляющими прямые почтовые рассылки, и делает запрос на исключение его адреса из списков рассылки. Мы отдельно указали на то, что это никак не повлияет на возможность получения важной корреспонденции. Поскольку, как выяснилось, кража личных данных являлась серьезной проблемой, связанной с получением нежелательной почты, мы добавили страницу, содержащую соответствующее описание и предостережение о такого рода опасности. На ней были размещены фотографии уязвимых почтовых ящиков и объяснялось, как с помощью нашего сервиса можно снизить риск кражи личных данных.

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

После подготовки макетов JunkmailFreeze мы, используя хорошо себя зарекомендовавший скринер для отбора целевых потребителей «Щита», набрали еще одну группу участников тестирования. Для второго раунда мы планировали использовать три группы по два пользователя в каждой. Я обновил сценарий тестирования таким образом, чтобы сосредоточиться на проблеме нежелательной почты. Тестовые сеансы имели продолжительность в 90 минут и начинались в 18:00 и в 20:00 (как и в прошлый раз).

Учитывая, что первый раунд принес нам немало открытий, а также тот факт, что на этот раз мы хотели сфокусироваться на представлении деталей продукта, я отвел больше времени на обсуждение макетов (45 минут вместо 35). Новые участники, к нашей радости. проявили высокую заинтересованность и четко выражали свои мысли.

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

Тем не менее, эти макеты все еще нельзя было считать «финальными». У нас возникло еще более глубокое понимание того, что хотели бы получить пользователи от сервиса блокировки нежелательной почты. Например, мы узнали, что блокировка на уровне категорий рассылки не подходит для случаев, связанных с кредитными картами и каталогами. В отношении этих предложений пользователи хотели бы иметь возможность указывать свои предпочтения на уровне конкретных компаний (например, получать предложения от Chase или Wells Fargo по кредитным картам, каталоги от Nordstrom и L.L. Bean). Мы также получили обратную связь по поводу наших сообщений и пользовательского интерфейса, которая могла помочь в дальнейшем совершенствовании продукта.

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

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

Другой популярной разновидностью Agile-разработки является Канбан – процесс, созданный на основе системы, разработанной автоконцерном Toyota для улучшения сборки автомобилей. Система Toyota ориентирована на производство по принципу «точно в срок» и ликвидацию отходов (издержек). Я изучал оригинальную систему Канбан и принципы бережливого производства во время обучения в аспирантуре Технологического института Вирджинии.

На производстве работники используют бумажные карточки – «канбан» – в качестве сигналов, передаваемых на предыдущий этап процесса, о необходимости пополнения запасов (заготовок). Канбан был адаптирован для целей разработки программного обеспечения с применением виртуальных карточек, каждая из которых представляет находящееся в работе задание, но при этом уже не выполняет сигнальной функции. Основным принципом Канбана является визуализация рабочего процесса. Каждая карточка представляет собой историю пользователя или относящееся к ней задание для разработки. Карточки помещают на специальную канбан-доску, состоящую из набора столбцов, каждый из которых соответствует определенной стадии рабочего процесса. Столбцы расположены слева направо в том порядке, в котором выполняется работа. Пример канбан-доски приведен на Рисунке 12.4. Здесь вы можете видеть следующий набор столбцов (стадий рабочего процесса) слева направо: «Бэклог», «Подготовлено», «В процессе разработки», «Разработка завершена», «В процессе тестирования», «Тестирование завершено» и «Выпуск», которые определяются следующим образом:

• Бэклог: рабочие задания, которые членам команды предстоит взять в работу, отсортированные по приоритетности.

• Подготовлено: задания, которые были взяты из бэклога, и готовы к передаче в разработку.

• В процессе разработки: задания, разработка которых происходит в данный момент.

• Разработка завершена: задания, прошедшие этап разработки, но еще не переданные на тестирование.

• В процессе тестирования: задания, находящиеся в процессе тестирования.

• Тестирование завершено: задания, которые успешно прошли тестирование, но еще не были выпущены.

• Выпуск: задания, которые были выпущены после их разработки и тестирования.

Некоторые столбцы канбан-доски представляют выполняемую работу (например, «В процессе разработки», «В процессе тестирования»), в то время как другие обозначают стадии ожидания обработки (например, «Подготовлено», «Завершено»). Столбцы последнего типа дают представление о состоянии очереди на выполнение работ. Когда член команды завершает работу над одним заданием, он берет верхнюю карточку следующего задания из тех, что находятся в соответствующей очереди, и начинает работать над ним.

Рисунок 12.4. Пример канбан-доски

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

Возможно, вы заметили, что каждый из столбцов «Разработка» и «Тестирование» на Рисунке 12.4 разделен на два подраздела: один из которых обозначает нахождение задания в процессе работы, а другой соответствует завершенному состоянию. Это позволяет составить более четкое представление о текущем рабочем процессе и его узких местах.

В Канбане количество заданий, находящихся в активном состоянии, регулируется путем ограничения объема «незавершенных процессов» или сокращенно – НЗП. Команда определяет максимальное количество карточек, которое может накапливаться в каждом столбце, что представляет собой лимит НЗП. Члены команды последовательно перемещают карточки заданий между этапами работы. Однако они могут перенести карточку в следующий столбец только в том случае, если там имеется свободное место (то есть лимит карточек, находящихся в следующем столбце, еще не исчерпан). Это правило помогает выровнять процессы обработки и добиться стабильного рабочего потока. Командам предписано периодически корректировать установленные лимиты НЗП в целях оптимизации рабочего процесса. На канбан-доске размер лимита НЗП указывается над каждым столбцом. Как показано на Рисунке 12.4, команды часто используют единый лимит НЗП для связанных стадий одного этапа – «В процессе» и «Завершено». Например, общее количество карточек в столбце «Разработка» (включая обе его стадии: «В процессе» и «Завершено») не может быть больше трех. Это помогает стимулировать более быстрое продвижение карточек, находящихся в ожидания обработки.

Возьмем для примера ситуацию, представленную на Рисунке 12.4. Когда разработчик завершит работу над заданием D, он переместит его карточку из столбца «В процессе» в столбец, соответствующий стадии «Завершено». Однако при этом он не сможет перенести задание F из состояния «Подготовлено» в столбец «Разработка», поскольку лимит НЗП для этой стадии, равный трем карточкам, уже исчерпан. Аналогично, когда тестировщик завершит работу с заданием B, он переместит его карточку в столбец «Тестирование завершено», но не сможет взять в работу задание C, поскольку для стадии «Тестирование» исчерпан лимит НЗП, равной двум карточкам. Для продолжения работы необходимо «вытолкнуть» одну из карточек из столбца «Тестирование завершено». Как только это произойдет, задание C может быть переведено в состояние «В процессе тестирования», что, в свою очередь, освободит место в столбце «Разработка» для задания F.

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

Основное внимание в Канбане уделяется рабочему потоку. Здесь нет ограниченных по времени итераций, как это принято в Scrum. Карточки рабочих заданий непрерывно перемещаются слева направо по канбан-доске по мере выполнения работы. В Канбане не применяется обязательная оценка масштаба пользовательских историй, поэтому Scrum-концепция скорости выполнения работы (количество баллов пользовательских историй, отрабатываемых за одну итерацию) в этом случае не работает. Тем не менее, вы можете измерить так называемую пропускную способность команды, просто оценив количество рабочих заданий, выполненных за определенный промежуток времени, например, 10 заданий в неделю. Если вы отслеживаете изменение производительности работы вашей команды во времени, то она должна увеличиваться за счет постепенного совершенствования рабочих процессов и накопления опыта.

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

Вы можете визуализировать ход работы в системе Канбан с помощью диаграммы кумулятивного потока (Рисунок 12.5), которая показывает, сколько карточек заданий находилось в каждом из рабочих состояний в конце каждого дня. Для простоты на Рисунке 12.5 отслеживаются только три вида рабочего состояния: «Бэклог», «В процессе» и «Завершено». Вы можете видеть, что продолжительность цикла измеряется горизонтальной толщиной слоя, относящегося к заданиям, находящимся «В процессе», а показатель времени выполнения равен суммарной горизонтальной толщине слоев, отражающих количество заданий в «Бэклоге» и «В процессе». Количество НЗП равно вертикальной толщине слоя, характеризующего количество заданий, находящихся «В процессе».

Рисунок 12.5. Диаграмма кумулятивного потока

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

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

При существенном различии масштабов выполняемых рабочих заданий можно наблюдать расширение диапазона значений продолжительности цикла, поскольку небольшие задания отрабатываются быстрее, чем более масштабные. Некоторые практикующие Канбан разработчики применяют оценку масштабности заданий, используя описанную выше систему, основанную на размерах футболок (S, M, L и так далее). Это позволяет обеспечить получение более адекватных значений показателя продолжительности цикла; разные значения данного показателя соотносятся с оценками сложности отрабатываемых заданий.

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

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

Однако существует множество цифровых инструментов для управления канбан-процессами. Одним из наиболее популярных приложений для визуализации канбан-доски в ходе разработки программного обеспечения является Trello. На самом деле, многие используют Trello для управления и другими рабочими процессами. Это приложение особенно популярно среди менеджеров по продуктам и дизайнеров. Они используют собственные рабочие панели, которые могут подключаться к канбан-доскам разработчиков. Многие канбан-команды используют такие приложения, как JIRA Agile, SwiftKanban и LeanKit.

Еще одним достойным внимания приложением является Pivotal Tracker, хотя оно и не относится к инструментам, специализированным для Канбана. Я использовал Tracker при создании нового продукта, когда получал полезный опыт работы с Pivotal Labs. Это приложение использует виртуальную доску со столбцами, отведенными для каждого из заранее определенных рабочих состояний. Данный инструмент поддерживает интересное сочетание Канбана и Scrum (существует даже Agile-методология под названием «Scrumban», которую будет полезно изучить, если эта идея выглядит для вас привлекательной).

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

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

Одной из основ Agile является тесное межфункциональное взаимодействие, под которым подразумевается свободное постоянное общение между менеджерами по продуктам, дизайнерами, разработчиками, тестировщиками и любыми другими членами команды. Важно избегать создания изолированных подсистем, в которых каждая функциональная группа живет собственной жизнью и перебрасывает свою часть продукта «через стену» для перехода на следующий этап рабочего процесса. Живые коммуникации в режиме реального времени имеет решающее значение для достижения максимального взаимопонимания и высокой скорости работы команды. Эффективность совместной работы поддерживается также за счет использования таких средств коммуникации, как чаты, инструменты для отслеживания разработки (например, JIRA Agile), а также приложения для совместной работы с базами знаний (например, wiki или Google Docs).

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

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

Вы должны поддерживать актуальность бэклога с учетом приоритетности входящих в него заданий. Важно иметь четкое представление о наборе пользовательских историй, которые планируется отработать в следующем цикле, как только для этого появятся ресурсы. Применение такого подхода позволяет действовать быстро. Команды разработчиков высокотехнологичных продуктов обычно работают в динамичной среде, для которой характерна быстрая смена требований и приоритетов. При этом явно недостаточно присваивать заданиям такие нечеткие приоритеты, как высокий, средний и низкий. Если в бэклоге будет 15 заданий с высоким приоритетом, то как понять, к какому из них разработчик должен приступить в первую очередь? Поэтому необходимо дополнительное ранжирование заданий, входящих в состав бэклога. Я являюсь сторонником жесткой расстановки приоритетов (в противовес расплывчатому ранжированию заданий). Четкая расстановка заданий внутри бэклога дает ясное понимание того, какое из них стоит первым в очереди на отработку. Это также значительно облегчает определение места в бэклоге для вновь поступающих заданий.

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

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

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

Другими словами, к сроку окончания спринта N они должны уже подготовить артефакты проектирования для спринта N+1 или даже N+2. Конечно, для этого проектировщикам потребуются качественно написанные пользовательские истории, поэтому менеджеры по продукту должны в свою очередь опережать дизайнеров также на один или два спринта.

Цель состоит в том, чтобы убедиться, что вы никогда не заставите разработчиков сидеть без дела, и у вас наготове всегда будет бэклог для очередного спринта. Это также требует соблюдения баланса, поскольку делать заранее слишком много заготовок для спринтов может быть неразумно из-за того, что все может измениться. Несмотря на то что я описал ситуацию в терминах Scrum, это также справедливо и для Канбана. Исходя из продолжительности цикла работы дизайнеров, продакт-менеджер должен обеспечить достаточное количество заданий, готовых для проектирования. Аналогично, исходя из продолжительности цикла разработки, дизайнеры должны обеспечить достаточное количество карточек заданий в столбце «Готово для разработки».

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

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

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

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

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

Ранее я уделил опросам гораздо меньше внимания, чем другим типам пользовательских исследований. Это объясняется в первую очередь тем, что я слишком часто сталкивался с примерами злоупотребления данным методом. Хорошо спланированный опрос может принести полезные сведения. Но при этом необходимо четко осознавать, для чего именно вы можете их использовать, и не выходить за очерченные границы. Если вы попросите 1000 человек оценить по шкале от 1 до 10, насколько вероятно, что они воспользуются новым, простым в использовании приложением для обмена фотографиями, которое вы планируете создать, это будет злоупотреблением. Почему? Во-первых, они почти ничего не знают о вашем продукте. Предложенное вами описание: «новое, простое в использовании приложение для обмена фотографиями» содержит всего восемь слов информации. Это не живой продукт, не набор кликабельных вайрфреймов и даже не макет, поэтому у опрашиваемых людей не так много данных, на которые они могли бы опереться, чтобы сформировать объективное суждение. Как в таком случае они могут с точностью предсказать, будут ли они пользоваться вашим приложением или нет? Раз за разом я наблюдаю, как создатели опросов просят респондентов высказать свое мнение о том, о чем у них нет достаточно полного представления.

Во-вторых, поскольку опросы направлены на получение отношенческой информации, вы должны воспринимать полученные результаты соответствующим образом. Люди могут давать положительные или отрицательные ответы на вопрос о том, насколько вероятно, что они будут использовать новый продукт; но эти ответы часто не совпадают с реальным поведением. Я бы предпочел этому проведение «Дымового теста» с использованием целевой страницы, на которой разместил бы кнопку «Купить», или попросил людей указать свой адрес электронной почты для включения в список ожидания бета-тестирования. Затем я бы отследил значение показателя конверсии. Собранные таким образом поведенческие данные дали бы более точный ответ по сравнению с результатами, полученными в ходе опроса.

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

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

Одним из наиболее широко используемых опросных показателей является чистая оценка промоутера («индекс лояльности», – прим. пер.), или сокращенно – NPS. Этот показатель основан на ответах респондентов всего на один вопрос: «Какова вероятность того, что вы порекомендуете [продукт X] другу или коллеге?» Шкала оценки «вероятности рекомендации» имеет диапазон от 0 до 10, где 10 означает «весьма вероятно», а 0 – «очень маловероятно». Респондентов, дающих оценку в 9 или 10 баллов, называют промоутерами; тех, кто ставит 7 или 8 баллов, – пассивными; а тех, кто оценивает такую вероятность от 0 до 6 баллов, – недоброжелателями. Чтобы рассчитать значение NPS, нужно из процента промоутеров вычесть процент недоброжелателей.

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

Шон Эллис – талантливый маркетолог и практик бережливого стартапа – человек, который придумал термин «хакер роста» и управляет сайтом сообщества http://growthhackers.com. Эллис также является генеральным директором компании Qualaroo, занимающейся анализом потребностей клиентов http://qualaroo.com. Многие компании обязаны ему активным ростом числа своих клиентов.

Эллис, как и я, считает, что не следует вкладывать средства в развитие бизнеса до тех пор, пока выпускаемый продукт не добьется соответствия рынку. Для оценки степени соответствия он предлагает использовать опросы, в ходе которых вы должны спросить пользователей продукта: «Как бы вы себя чувствовали, если бы больше не могли пользоваться [продуктом X]?» Респондентам предлагается четыре возможных варианта ответа:

• Весьма разочарован.

• Немного разочарован.

• Не разочарован (без него вполне можно обойтись).

• Нет ответа – Я больше не пользуюсь [продуктом X].

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

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

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

1. Привлечение: Сколько потенциальных клиентов (новых посетителей) привлекают на наш веб-сайт реализуемые маркетинговые программы?

2. Конверсия: Какой процент посетителей нашего сайта регистрируются в качестве клиентов?

3. Удержание: Какой процент наших клиентов остаются активными в течение продолжительного времени?

4. Доход: Сколько денег приносят наши клиенты?

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

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

Два года спустя, присоединившись к разработчикам новаторской социальной сети Friendster, я решил вновь использовать аналитику для отслеживания и улучшения продукта и бизнеса. С этой целью я разработал новый фреймворк. Руководители компании согласились с тем, что ключевым показателем для их продукта является количество пользователей. Социальные продукты выигрывают за счет сетевого эффекта, означающего, что их ценность растет по экспоненте с увеличением числа пользователей. Кроме того, описанные события происходили на заре развития социальных сетей, когда лидерство на этом рынке еще не было однозначным. Лучший способ увеличить клиентскую базу состоял в том, чтобы побудить наших существующих пользователей пригласить как можно больше своих друзей и знакомых присоединиться к Friendster. Если в среднем каждый пользователь сети приводит такое количество новых посетителей, которое впоследствии превращаются в более чем одного реального клиента, это выливается в вирусный рост клиентской базы. Социальные продукты обладают высоким потенциалом вирусного роста (а также высокими темпами невирусного роста). Подробный алгоритм, пошагово описывающий, как существующий пользователь генерирует появление нового клиента, называются вирусной петлей.

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

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

1. Компания хочет, чтобы потенциальные клиенты были осведомлены о ее продукте.

2. Компания хочет превратить потенциальных клиентов в реальных.

3. Компания хочет сохранить как можно больше своих клиентов в течение долгого времени.

4. Компания хочет получать доход от своих клиентов.

5. Компания хочет, чтобы ее клиенты распространяли информацию о продукте, поскольку это способствует привлечению новых клиентов.

В 2007 году мне посчастливилось познакомиться с Дэйвом Макклюром. Скорее всего, вы слышали о Дэйве, но на всякий случай отмечу, что сам он считает себя «гиком, маркетологом, инвестором, блогером и смутьяном». Помимо прочего, этот человек является партнером-основателем стартап-фонда и стартап-акселератора 500 Startups (http://500.co). Мы встретились на конференции, где Дэйв выступал с докладом, в котором презентовал свой фреймворк под названием «Стартап-метрики для пиратов». Я был рад заметить, что этот фреймворк был очень похож на те, которые я разработал для продуктов Intuit и Friendster. Дэйв представил свои идеи настолько простым и эффективным способом, что высокая практическая ценность его фреймворка была очевидна.

Наши аналитические системы имели лишь два незначительных расхождения в терминологии. Во-первых, Дэйв использовал термин «активация» вместо «конверсия». Он вложил в свой термин более широкий смысл, включавший в себя и конверсию – в том виде, как ее определил я, – и иные способы, которыми потенциальный клиент может взаимодействовать с продуктом, не становясь при этом реальным клиентом. Например, потенциальный клиент может не подписываться на предлагаемую ему услугу, но при этом предоставить свой адрес электронной почты для получения уведомлений о новостях, касающихся продукта. Это действие не будет квалифицироваться как конверсия в полноценного клиента, но может быть включено в показатель активации. Во-вторых, Дэйв использовал слово «реферал» – отличный, универсальный термин – для описания концепции, согласно которой существующие клиенты предпринимают действия, приводящие к тому, что о вашем продукте узнают новые потенциальные клиенты. Дэйв назвал свой фреймворк «Стартап-метрики для пиратов». Такое название появилось благодаря акрониму, который образуется из наименований пяти используемых им показателей: Acquisition [привлечение], Activation [активация], Retention [удержание], Referral [рекомендации] и Revenue [доход] – получается «ААRRR!» (с восклицательным знаком, добавленным для пущего сходства)[26].

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

Компания KISSmetrics создала отличную диаграмму для описания фреймворка AARRR, и это неудивительно, если учесть, что генеральный директор и основатель KISSmetrics Хитен Шах является одним из ведущих специалистов в области бережливого стартапа и аналитики. Я немного модифицировал эту диаграмму – полученный результат представлен на Рисунке 13.2.

Рисунок 13.2. Фреймворк показателей AARRR!

В любой момент существования бизнеса какая-то из пяти макро-метрик, входящих в состав модели AARRR, будет более важна, чем остальные. Я называю ее «наиболее значимой метрикой» – или сокращенно НЗМ. Улучшение других показателей тоже имело бы позитивный эффект, но НЗМ – это тот показатель, который говорит, как в текущий момент можно получить наибольшую отдачу от вложений. Уточнение «в текущий момент» является очень важным. В какой-то момент, после того как вы добьетесь значительного улучшения своей НЗМ, она перестанет быть наиболее значимой, поскольку ее место займет другой показатель, обеспечивающий лучшие возможности с точки зрения рентабельности инвестиций. Предположим, что после запуска продукта вы обнаруживаете, что только 10 % посетителей сайта, которые начинают процесс регистрации, доходят до ее завершения. Вы решаете, что коэффициент конверсии, рассчитываемый на основе количества завершенных регистраций, является на текущий момент вашей НЗМ, и поэтому проводите пользовательское тестирование процесса регистрации и в результате обнаруживаете несколько проблем, связанных с юзабилити. Также выясняется, что форма регистрации не работает в одном из браузеров. Вы проверяете журналы своего сервера и понимаете, что в некоторые моменты возникает ошибка, из-за которой форма регистрации работает не так, как было задумано. Усердно потрудившись над устранением всех этих проблем, вы видите, что коэффициент конверсии повысился до 90 %. Таким образом, на текущий момент коэффициент конверсии перестал быть вашей НЗМ. Теперь уже другие метрики указывают на наличие возможности получить большую отдачу на затраченные ресурсы.

Смена НЗМ происходит из-за феномена убывающей отдачи. Когда вы впервые займетесь поиском метрики, оптимизация которой способна привести к существенным улучшениям бизнеса, вы вскоре обнаружите множество «низко висящих плодов»: идей, которые без приложения особых усилий могут привести к значительным улучшениям. Но затем вы замечаете, что с каждым улучшением рентабельность инвестиций при реализации следующей идеи становится все ниже, и это убывание отдачи продолжается по мере того, как вы добиваетесь все большего прогресса.

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

Работая над новым продуктом, вы стремитесь прежде всего добиться его соответствия рынку. Пока вы не будете уверены в том, что пользователи считают ваш продукт ценным, не имеет никакого смысла тратить значительные ресурсы на попытки привлечения клиентов. Аналогично не имеет смысла вкладываться в оптимизацию показателей конверсии. Трата ресурсов в этих направлениях не только окажет меньшее влияние на бизнес, но и отвлечет их от того, что в текущий момент наиболее важно. Если клиенты посчитают ваш продукт достаточно полезным, они продолжат им пользоваться; в противном случае они этого не сделают. Таким образом, удержание – это макрометрика, наиболее тесно связанная с соответствием продукта рынку. По этой причине именно она, как правило, становится первой НЗМ для нового продукта.

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

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

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

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

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

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

Кривые удержания – это интуитивно понятный способ визуализации удержания клиентов. Пример такой диаграммы представлен на Рисунке 13.3. По вертикальной оси здесь измеряется процент возвращающихся пользователей. Горизонтальная ось представляет количество дней (или недель, или месяцев), прошедших с момента первого использования. Значение для каждой точки кривой рассчитано на основе данных о регистрации и о фактах использования продукта для совокупности пользователей. По чисто математической причине кривые удержания всегда начинаются со 100 %-ной отметки в нулевой день (которым является день регистрации каждого пользователя), а затем имеют тенденцию снижаться с течением времени, поскольку доля пользователей, которые не возвращаются, чтобы снова воспользоваться вашим продуктом, постепенно накапливается. Уже на 1-й день (то есть следующий день после регистрации) может наблюдаться значительное снижение показателя удержания. Поэтому нулевой день обычно не отображают на графике, а начинают отсчет с первого дня, чтобы график выглядел более читабельным.

Рисунок 13.3. Кривая удержания

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

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

Три перечисленных выше отличительных параметра кривой удержания – начальный отсев, скорость снижения и терминальное значение – являются непосредственными показателями соответствия продукта рынку. Чем выше степень соответствия, тем ниже процент начального отсева, меньше скорость снижения и выше терминальное значение. Чем ниже степень соответствия продукта рынку, тем выше начальный отсев и скорость снижения, и тем ниже терминальное значение. Последний из этих параметров является наиболее важным, поскольку отвечает на вопрос: «Какой процент клиентов, попробовавших продукт, продолжают им пользоваться в течение долгого времени?» Если бы вы сказали мне, что терминальное значение кривой удержания для продукта А составляет 1 %, а для продукта В – 50 %, я бы мог ответить, какой из этих продуктов в большей степени соответствует рынку (продукт В), не владея никакой дополнительной информацией об этих продуктах.

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

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

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

Группа пользователей, которые имеют общую характеристику – например, месяц, в котором они зарегистрировались, – называется когортой. Мощным инструментом анализа меняющихся во времени показателей для различных когорт является когортный анализ. На Рисунке 13.4 показан график с тремя кривыми удержания для различных когорт. По горизонтальной оси здесь измеряется количество недель, прошедших с момента регистрации (вместо дней, как это было на Рисунке 13.3). Вы можете видеть, что когорта А имеет самый низкий начальный отсев, самую высокую скорость снижения и самое низкое терминальное значение. Когорта С имеет самый высокий начальный отсев, самую низкую скорость снижения и самое высокое терминальное значение. Параметры кривой для когорты B находятся между соответствующими значениями для когорт A и B. Итак, какую из трех кривых удержания вы предпочли бы для своего продукта? Я бы выбрал кривую когорты C, из-за того, что она имеет самое высокое терминальное значение. Начиная с 3-й недели, в когорте C процент активных пользователей выше, чем в двух других когортах. Это приводит к увеличению дохода. В качестве отступления: если у вас на одном графике отображается более пяти кривых, он становится трудночитаемым.

Рисунок 13.4. Кривые удержания для когорт

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

Таблица 13.1 Исходные данные для когорт

Данные, приведенные в Таблице 13.1, используются для расчета значений, приведенных в Таблице 13.2. Процент в каждой ячейке Таблицы 13.2 – это коэффициент удержания для соответствующей когорты (указанной в строке) за определенный временной интервал (указанный в столбце). Каждый коэффициент удержания рассчитывается путем деления количества активных пользователей (для данной когорты и периода времени) на начальное количество пользователей в когорте. Каждая строка Таблицы 13.2 отображается затем на графике в виде отдельной кривой удержания.

Таблица 13.2 Коэффициенты удержания для когорт

Если вы со временем повышаете степень соответствия своего продукта рынку, кривые удержания для ваших когорт будут двигаться вверх, достигая более высоких терминальных значений для новых когорт. На Рисунке 13.5, где представлены кривые удержания для трех когорт, показан пример того, как это могло бы выглядеть при реализации идеального сценария. Пользователи, сгруппированные в когорту А, зарегистрировались 24 месяца назад – сразу после выпуска продукта. Пользователи, вошедшие в когорту B, зарегистрировались 18 месяцев назад, а пользователи из когорты C – 12 месяцев назад. Как вы можете видеть, со временем мы улучшили соответствие нашего продукта рынку, и кривая удержания клиентов пошла вверх. Каждая последующая когорта имеет более низкий начальный отсев, более низкую скорость снижения и более высокое терминальное значение, чем предыдущая.

Рисунок 13.5. Повышение показателя удержания с течением времени

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

Когда я хочу что-то оптимизировать, инженерное и математическое образование побуждает меня первым делом использовать для этого уравнение. В средней школе мы бесчисленное количество раз выражали переменную Y как функцию другой переменной – X. При этом цель состояла в том, чтобы найти такое значение X, которое приводило бы к максимально возможному значению Y. Более продвинутые версии этого упражнения включали применение нескольких переменных. Отправной точкой всегда было уравнение, которое показывало, как Y выражается через X (или через несколько переменных). Таков теоретический мир математики, но аналогичная техника применима и в реальном мире бизнеса.

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

Вот стартовое уравнение, которое применимо к любому бизнесу:

Прибыль = Доходы – Затраты

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

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

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

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

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

Доход = Пользователи * Средний доход на одного пользователя

Это уравнение говорит нам о том, что в принципе есть два основных способа повышения дохода: увеличить количество пользователей и/или увеличить средний доход, генерируемый одним пользователем. Возможно, вам уже приходилось слышать сокращенное название данного показателя (Average Revenue Per User, или ARPU), поскольку он относится к числу ключевых и отслеживается многими компаниями.

Наилучший способ дробления параметров из уравнения для расчета дохода на более подробные показатели зависит от бизнес-модели, применяемой для получения этого дохода. Для примера давайте предположим, что у нас есть бизнес, который приносит доход за счет медийной рекламы. Во многих продуктах, основанных на рекламе, люди, которые видят эту рекламу, не обязательно должны быть зарегистрированными пользователями. Достаточно вспомнить такие популярные сайты, как YouTube или веб-сайт New York Times: для этих и других подобных продуктов, построенных на контенте, вместо термина «пользователи» используется термин «посетители». Учитывая нюансы отслеживания показателей веб-аналитики, термин «уникальные посетители» дает понять, что мы учитываем каждого посетителя сайта только один раз за определенный интервал времени. Итак, доход при применении рекламной бизнес-модели образуется следующим образом:

Доход = Посетители * Средний доход на одного посетителя

Медийная реклама продается рекламодателям исходя из количества показов – термин, который подразумевает, что рекламное сообщение было показано на веб-странице, которую посетил пользователь. Это не обязательно означает, что посетитель увидел рекламное объявление. Допустим, рекламодатель покупает 100 000 показов. Медиасайт, продавший ему эти показы, будет отслеживать их количество и завершит рекламную кампанию, как только рекламное сообщение будет показано 100 000 раз. Стоимость рекламы указывается в единицах «CPM», то есть за тысячу показов (здесь «M» – это римская цифра, обозначающая 1000). При цене в 10$ CPM общая стоимость рекламной кампании из нашего примера составит 1000$ (за 100 000 показов). Выражение цены через CPM представляет собой хороший способ для сравнения стоимости различных видов рекламы. В результате вы можете заметить, как термин «эффективный CPM» часто используется в более широком контексте. Теперь мы можем составить уравнение, раскрывающее, как формируется средний доход на одного посетителя:

Средний доход на одного посетителя = Показы на одного посетителя * Эффективный CPM ÷ 1000

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

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

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

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

Посетители = Новые посетители + Возвращающиеся посетители

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

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

Возвращающиеся посетители_(T) = Количество посетителей_(T-1) * Коэффициент возвращений

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

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

Не вдаваясь в настолько же подробные объяснения, вот как бы я «почистил аналитическую луковицу» для бизнес-модели, основанной на подписках.

Прибыль = Доходы – Затраты

Снова сосредоточимся на увеличении дохода, а не на снижении затрат.

Доход = Платные пользователи * Средний доход на одного платного пользователя

Я использовал термин «платные пользователи» вместо просто «пользователи», чтобы учесть тот факт, что не все пользователи платят за подписку на продукт. Например, есть те, кто использует 30-дневную бесплатную пробную версию. Кроме этого, некоторые продукты предполагают наличие как платной, так и бесплатной версии подписки. Для данного примера будем исходить из того, что все наши сервисы требуют платной подписки, но мы предлагаем, в том числе, бесплатную пробную версию.

Платные пользователи = Новые платные пользователи + Повторные платные пользователи

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

Повторные платные пользователи_(T) = Платные пользователи_(T-1) * (1 – Коэффициент отмены)

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

Новые платные пользователи = Бесплатные пробные пользователи * Коэффициент конверсии пробной версии + Прямая платная регистрация

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

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

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

Ранее я привел уравнения для улучшения вашего бизнеса в том виде, в каком они применимы к определенному интервалу времени. Другой способ состоит в том, чтобы не обращать внимания на временные интервалы и рассматривать бизнес-показатели в расчете на одного клиента.

Прибыль = Количество клиентов * Прибыль на одного клиента

Такой подход не столь актуален до тех пор, пока вы все еще находитесь в поиске соответствия продукта рынку. Но его ценность существенно увеличивается после того, как вы добились высокой степени соответствия и теперь пытаетесь увеличить объем получаемой прибыли. В приведенном выше уравнении показателем, который необходимо улучшить, является прибыль на одного клиента. Давайте приступим к «чистке аналитического лука» и снимем еще один слой.

Прибыль на одного клиента = Доход на одного клиента – Затраты на одного клиента

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

Прибыль на одного клиента = Пожизненная ценность клиента – Затраты на привлечение клиента

Это уравнение является очень полезной альтернативной функцией прибыли, приходящейся на одного клиента. Пожизненная ценность клиента (lifetime value, или LTV) – это выручка, которую генерирует клиент, без учета затрат на его привлечение. Затраты на привлечения клиента – это средняя сумма, в которую обходится привлечение нового клиента. Выделение этих затрат в отдельный показатель позволяет проводить его отслеживание и улучшение. Когда значение LTV превышает величину затрат на привлечение клиента, каждый новый клиент приносит бизнесу прибыль. Чтобы получить контролируемые показатели, которые могут быть улучшены за счет практических действий, следует снять с «аналитической луковицы» еще одним слой.

LTV = ARPU * Средний жизненный цикл клиента * Валовая маржа

В этом уравнении снова появляется показатель ARPU, который упоминался ранее. Напомню, что он представляет собой средний доход на одного пользователя (за интервал времени). Например, если все ваши подписчики платят по 10$ в месяц, значение ARPU составляет 10$ в месяц. Средний жизненный цикл клиента показывает, в течение скольких временных интервалов среднестатистический клиент остается с вами. Если вы умножите ARPU на величину среднего жизненного цикла клиента, то узнаете, какой доход в среднем приносит вам каждый клиент (на протяжении всего времени, пока он является платным клиентом). Допустим, проанализировав данные о своих клиентах, вы обнаружили, что величина среднего жизненного цикла клиента составляет 10 месяцев. Тогда для расчета среднего пожизненного дохода нужно 10$ ежемесячной платы умножить на 10 месяцев. Получится 100$.

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

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

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

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

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

Давайте вернемся к показателю затрат на привлечение одного клиента (Customer Acquisition Cost, сокращенно – CAC), который вы можете рассчитать, если знаете количество новых клиентов, которых вы привлекли за отслеживаемый период, и объем затрат на продажи и маркетинг за тот же интервал времени:

Это уравнение является удобным способом для расчета CAC, но оно не обеспечивает нас показателями, которые мы могли бы реально контролировать. С применением более действенных показателей уравнение будет выглядеть следующим образом:

Стоимость привлечения (часто сокращаемая до CPA, сost per action) – это то, во сколько в среднем обходится привлечение каждого потенциального клиента. Допустим, вы размещаете рекламу через Google AdWords и платите за каждый клик (CPC, cost per click) 1$. Тогда ваш CPA составляет доллар, поскольку каждый человек, который кликнет по ссылке, попадает на ваш сайт (становится потенциальным клиентом). Чтобы увеличить прибыль с одного клиента, вы можете уменьшить CAC путем сокращения стоимости привлечения. Это возможно в том случае, если вам удастся найти более дешевые маркетинговые инструменты и каналы. Как вариант, вы можете подобрать ключевые слова с более низкими ценами за клик. При использовании рекламы, стоимость которой зависит от количества показов, вы можете снизить значение CPA, повысив эффективность рекламных сообщений (то есть добившись увеличения количества переходов по рекламной ссылке).

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

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

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

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

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

Первым шагом в процессе анализа бережливого продукта является определение ключевых метрик для вашего бизнеса, о которых я рассказал в предыдущей главе. Далее вам нужно провести измерение этих показателей, чтобы зафиксировать для каждой метрики ее базовое значение, которое показывает, где вы находитесь сегодня. Этот шаг может показаться относительно простым, но многие компании на нем спотыкаются. Настройка отслеживания – или измерения – показателей продукта требует выполнения определенной работы. После первоначальной настройки обычно требуются дополнительные усилия для обеспечения точности и сопоставления значений отслеживаемых показателей. Аналитические приложения, такие как Google Analytics, KISSmetrics, Mixpanel и Flurry, позволяют упростить эту задачу. Данные, необходимые для расчета ключевых метрик, часто хранятся в базе данных продукта, поэтому многие компании используют комбинацию из приложений сторонних разработчиков и собственного аналитического ПО. Цель всех этих действий состоит в том, чтобы создать набор аналитических панелей, позволяющих видеть, как с течением времени изменяются значения каждой из отслеживаемых метрик.

Рисунок 14.1. Процесс анализа бережливого продукта

Как только у вас появятся точные базовые значения для каждой из ключевых метрик, можно будет перейти к следующему шагу: оценке потенциала роста каждого отслеживаемого показателя. На этом этапе вы оцениваете каждый показатель через призму рентабельности инвестиций (ROI). Я считаю полезным представлять диапазон значений каждого показателя в виде шкалы со стрелкой, подобной той, что вы можете наблюдать на приборной панели автомобиля или на манометре. Цифры, на которые в данный момент указывает стрелка, являются базовым значением для наблюдаемой метрики. Теперь вам нужно оценить, насколько легко или сложно будет сдвинуть стрелку вправо, то есть улучшить каждый показатель. Для этой цели используется кривая рентабельности инвестиций, и на этом шаге мы хотим получить хотя бы примерное представление о том, в каком месте на этой кривой находится исследуемый показатель в настоящий момент времени.

На Рисунке 14.2 показаны кривые рентабельности инвестиций для трех различных метрик. По вертикальной оси каждого графика отложены значения самой метрики (где чем выше, тем лучше). Зная особенности своего бизнеса и существующие взаимосвязи между его ключевыми показателями, вы имеете представление о том, в какой степени увеличение значения каждой метрики приводит к улучшению показателя более высокого уровня, который вы, в конечном счете, пытаетесь повысить за счет вложения соответствующих ресурсов (например, это может быть показатель объема выручки). Горизонтальная ось показывает объем инвестиций (ресурсов), направляемых на улучшение отслеживаемого показателя. Кружком обозначено текущее базовое значение метрики, то есть в каком месте на кривой рентабельности инвестиций каждый показатель находится в данный момент.

Рисунок 14.2. Кривые рентабельности инвестиций для трех различных метрик

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

Кривая рентабельности в том виде, как она показана для метрик A и B, является типичной для большинства показателей. Однако в некоторых обстоятельствах даже небольшие затраты ресурсов на улучшение показателя могут привести к его значительному росту. Я называю такие ситуации эффектом «волшебной пилюли». В таких случаях кривая рентабельности инвестиций будет выглядеть иначе – примерно так, как показано на Рисунке 14.2 для метрики C. Это особые случаи, при которых небольшое, но влиятельное изменение может привести к тому, что какой-то аспект продукта или бизнеса станет работать гораздо лучше, чем это было до вашего вмешательства. Обычно такие возможности обнаруживаются в результате тщательного анализа.

Как только вы оценили потенциал роста каждого показателя, можно переходить к следующему этапу процесса: выбору показателя, который предлагает наиболее многообещающие возможности для улучшения. Это и будет та самая «Наиболее значимая метрика» (НЗМ), которая обсуждалась в предыдущей главе. Если вспомнить Рисунок 14.1, то можно сказать, что вы сейчас осуществляете переход от глобального рассмотрения полного набора метрик к сосредоточению всех усилий только на главной из них.

Далее, в ходе проведения «мозгового штурма» вам необходимо сгенерировать как можно больше идей по улучшению своей наиболее значимой метрики. Затем предстоит оценить, насколько реализация каждой из сгенерированных идей способна улучшить эту НЗМ. В процессе вы формируете гипотезы, такие как «Оптимизация мобильной версии страницы регистрации повысит коэффициент конверсии с 20 до 30 %». Кроме этого, вам необходимо оценить стоимость реализации каждой идеи, чтобы рассчитать значение рентабельности инвестиций – ROI (как обсуждалось в главе 6). Проделав эту работу, вы сможете выбрать для реализации идею с наилучшей оценкой рентабельности инвестиций.

Далее вы разрабатываете и внедряете выбранную идею улучшения главной метрики. Наилучшим вариантом было бы использовать при этом платформу A/B-тестирования, чтобы опробовать улучшение на небольшой части пользователей. Это позволяет получить сравнимые значения метрики для оценки относительной эффективности сделанного улучшения в сравнении с базовым показателем. Если у вас нет платформы для проведения A/B-тестирования, и при этом метрика, которую вы пытаетесь улучшить, имеет относительно стабильное значение, вы можете после реализации идеи улучшения провести простое сравнение показателей «до» и «после». Однако я настаиваю, что применение A/B-тестирования является более предпочтительным вариантом, поскольку оно снижает риск влияния неизвестных факторов, приводящих к возникновению разницы в полученных результатах.

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

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

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

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

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

Например, если у вас есть целевая страница, вы могли бы провести A/B-тестирование разных вариантов цветов для главной кнопки, чтобы определить, какой из них дает наибольший коэффициент конверсии. Разработчик Google протестировал 41 оттенок синего цвета для своей панели инструментов, чтобы понять, какой из них обеспечивает наилучший коэффициент кликабельности. Однако, если вы прекратите итерации после того, как подберете наилучший цвет для своей главной кнопки, вы, вероятно, застрянете на локальном максимуме. Таким же образом необходимо поэкспериментировать с различными вариантами сообщений, изображений, макетов страниц и так далее, чтобы посмотреть, сможете ли вы добиться еще более высокого коэффициента конверсии. Скорость улучшения напрямую зависит от того, насколько быстро вы сможете выявить и реализовать хорошие идеи. A/B-тестирование упрощает проведение экспериментов, но определить гипотезы для проверки должны вы сами. Чтобы не застрять на локальном максимуме, вы должны быть уверены, что используете все имеющиеся возможности для поиска потенциальных идей, направленных на улучшение вашего продукта.

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

Присоединившись к стартапу разработчиков социальной сети Friendster в качестве главного продакт-менеджера, я выяснил, что одним из наиболее важных моментов является вирусное привлечение клиентов. У нас имелась солидная база пользователей, и мы получали некоторый доход от рекламы, но показатель среднего дохода в расчете на одного пользователя был слишком низким, чтобы мы могли позволить себе тратить деньги на привлечение клиентов (как это делают крупные потребительские компании). К счастью, у нас был для этого альтернативный способ – вирусный маркетинг позволял нам привлекать пользователей бесплатно. Благодаря сетевому эффекту ценность таких продуктов, как социальная сеть, к которым относился и Friendster, возрастает по экспоненте с увеличением числа активных пользователей. Мы знали, что быстрый рост нашей пользовательской базы имеет решающее значение для достижения успеха, и лучший способ добиться этого предлагал вирусный маркетинг. Поэтому я определил улучшение показателя вирусного роста в качестве одной из своих главных целей. Другие члены команды разделяли эту точку зрения, но никто на самом деле не имел представления о том, как можно провести измерение нашего вирусного роста. Я начал с первого шага процесса анализа бережливого производства: определения ключевых метрик.

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

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

Рисунок 14.3. Вирусная петля Friendster

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

1. Процент активных пользователей: Этот показатель рассчитывается путем деления количества активных пользователей на общее количество зарегистрированных пользователей.

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

3. Среднее количество приглашений, посылаемых одним пользователем: Пользователи могут отправить приглашения как одному, так и нескольким своим друзьям. Соответственно, данный показатель рассчитывается путем деления общего количества отправленных приглашений на общее количество пользователей, пославших приглашения.

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

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

Рисунок 14.4. Показатели вирусной петли Friendster

Все эти метрики являются действенными и могут быть рассчитаны для любого заданного интервала времени (например, за последние 30 дней). При перемножении всех пяти показателей получается коэффициент вирусной петли. Если значение этого коэффициента больше единицы, то продукт официально является «вирусным». Это означает, что каждый существующий пользователь генерирует более одного нового пользователя, что в итоге приводит к экспоненциальному росту – подобно ядерному реактору, переходящему на сверхкритическую мощность. Продукты не сохраняют свой вирусный статус в течение долгого времени (иначе пользователем нашей социальной сети, в конце концов, стал бы каждый, у кого есть доступ в Интернет). Когда вирусный продукт достигает высокого уровня проникновения на рынок, там уже не остается достаточно большого количества потенциальных пользователей, которых еще можно было привлечь в качестве клиентов. В таком завидном положении находится, например, сеть Facebook. Однако если значение вирусного коэффициента оказывается меньше 1, но все равно является довольно высоким – скажем, 0.4, – у вас нет серьезного повода для беспокойства. Это по-прежнему означает, что в каждом отслеживаемом временном интервале вы с помощью вирусного маркетинга совершенно бесплатно увеличиваете свою клиентскую базу на 40 %.

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

Для простоты в дальнейшем я буду использовать только три из пяти метрик, включая рассчитанные для них базовые значения:

• Процент пользователей, посылающих приглашения = 15 %.

• Среднее количество приглашений, посылаемых одним пользователем = 2.3.

• Коэффициент конверсии = 85 %.

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

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

Рисунок 14.5. Потенциал роста для метрик

Давайте начнем с анализа коэффициента конверсии. Это процентный показатель, поэтому он может варьироваться от минимального значения – 0 %, до максимального – 100 %. Базовое значение составляет 85 %. Таким образом, независимо от того, какие улучшения мы внесем, увеличить значение этой метрики можно не более чем на 15 процентных пунктов (до 100 %). Поскольку потенциал роста нужно оценить в процентах к базовому значению, мы берем 15 пунктов возможного прироста и делим их на 85 (базовое значение), что дает нам 18 %. Таким образом, максимальный потенциал повышения коэффициента конверсии составляет 18 %.

Вторая метрика – процент пользователей, посылающих приглашения, – также может варьироваться в диапазоне от 0 до 100 %. Базовое значение составляет 15 %, так что теоретически мы могли бы улучшить этот показатель на целых 85 процентных пунктов. Опять же, чтобы выразить этот потенциал роста в процентах, мы берем 85 пунктов возможного прироста и делим их на базовое значение – 15 %, получая в итоге 570 %. Таким образом, процент пользователей, посылающих приглашения, имеет значительно больший потенциал роста, чем коэффициент конверсии.

Теперь давайте перейдем к третьей метрике: среднему количеству приглашений, посылаемых одним пользователем. Этот показатель не является процентным. Его минимальное значение равно 0. Базовое значение равно 2.3. Каково же максимально возможное значение для этой метрики? На первый взгляд кажется, что его невозможно определить достаточно точно. Но нам нужна хотя бы приблизительная оценка максимального значения, чтобы рассчитать потенциал роста. Может ли оно быть бесконечным? Нет, поскольку численность населения нашей планеты измеряется конечным числом. Каждый пользователь может пригласить всех своих родственников, друзей и знакомых присоединиться к Friendster. Таким образом, максимальным значением будет среднее количество друзей, которое есть у пользователя Friendster. Что это за число? Я не знал точно, но мне казалось, что разумная оценка составляет от 100 до 200 человек. В 1990-х годах психолог Робин Данбар провел исследование, пытаясь определить максимальное число людей, с которыми человек может поддерживать стабильные социальные отношения. Он пришел к выводу, что этот предел – называемый числом Данбара – равен 150, что соответствует середине моего предполагаемого диапазона. Если мы используем это значение, то увидим, что потенциал роста среднего количества посылаемых приглашений в расчете на одного пользователя составляет 150 ÷ 2.3 = 6 520 %. Даже если отталкиваться от более консервативной оценки максимального значения в 100 приглашений, потенциал роста этой метрики все равно будет значительно превышать аналогичный показатель для двух других метрик.

Когда вы впервые увидели Рисунок 14.5, не возникло ли у вас ощущение дежавю? Взгляните еще раз на кривые рентабельности инвестиций для трех метрик на Рисунке 14.2. Замечаете сходство? Процент пользователей, посылающих приглашения, подобен метрике A с хорошим показателем ROI. Коэффициент конверсии подобен метрике B, для которой характерна низкая рентабельность. Среднее количество приглашений, посылаемых одним пользователем, в наибольшей степени соответствует метрике C. Однако мы не будем знать этого наверняка до тех пор, пока не увидим, насколько значительно можно улучшить значение метрики и каких усилий это потребует.

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

Теперь, когда я выбрал наиболее значимую метрику для улучшения, можно было перейти к следующему шагу в процессе анализа бережливого продукта. На этом этапе происходит запуск цикла оптимизации метрики, показанный в правой части Рисунка 14.1. Вместе с командой мы провели мозговой штурм с целью генерации потенциальных идей по улучшению выбранного целевого показателя. Затем каждую из выдвинутых идей оценили с точки зрения того, насколько она может повлиять на улучшение метрики, и каких ресурсных затрат потребует ее реализация. После этого мы пришли к выводу, что наилучшей по показателю своей рентабельности является идея с импортом адресной книги. Сейчас наличие в приложениях функции импорта адресной книги является привычной, но в то время это было редкостью. Многие из наших пользователей хранили адреса электронной почты своих друзей в адресной книге, которая была привязана к их учетной записи у почтовых провайдеров, таких как Gmail и Yahoo!Mail. Наша новая функция должна была позволить пользователям, введя учетные данные для доступа к своему электронному почтовому ящику, импортировать во Friendster хранящуюся в почтовом сервисе контактную информацию своих друзей. Разработанный нами импортер адресной книги отображал список перенесенных контактов и позволял пользователям выбирать из него тех, кому они хотели бы направить приглашение. Мы предполагали, что реализация данной функции приведет к значительному увеличению среднего количество приглашений, посылаемых одним пользователем.

Что касается технической реализации, несмотря на то что часть функционала была общей для всех почтовых провайдеров, все же требовалось проделать определенный объем работы, чтобы интегрироваться с каждым конкретным почтовым сервисом. На этом этапе я понял, что было бы полезно разбить разрабатываемую функцию на более мелкие части (как это описано в главе 6), выделив в отдельные блоки задачи по интеграции с каждым из провайдеров. Чтобы протестировать нашу гипотезу, затратив на это минимальное количество усилий, я решил использовать MVP, функционал которого позволял импортировать адресную книгу, но работал пока только с одним из почтовых сервисов. Проанализировав профили наших пользователей, я обнаружил, что наибольшей популярностью у них пользуется «почтовик» Yahoo!Mail. Соответственно, разработка именно этого функционального блока должна была обеспечить наиболее высокую рентабельность инвестиций. Следующим шагом в этом направлении стала разработка и внедрение программного решения. На выполнение этой работы менеджеру по продукту и разработчику потребовалось около недели.

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

На графике отчетливо видно, что изначально значение метрики колебалось незначительно, оставалось в узком диапазоне между 2.2 и 2.4. То место, где плавная горизонтальная линия разворачивается и устремляется вверх, соответствует дате запуска функции импорта адресной книги. Поскольку мы использовали 7-дневную среднюю, потребовалось несколько дней на то, чтобы линия графика пришла в полное соответствие с текущими дневными значениями метрики. Новое усредненное значение количества приглашений, посылаемых одним пользователем, продолжало расти с каждым днем и добралось до отметки 5.3. Я был в полном восторге!

Идея сработала как «волшебная пилюля»: всего за неделю работы ключевой показатель удалось улучшить более чем в два раза (5.3 ÷ 2.3 = 2.3x)! Если вспомнить соответствующее уравнение для улучшения бизнеса, то увеличение данной метрики в 2.3 раза означало, что число наших новых клиентов выросло также в 2.3 раза за счет вирусного привлечения. И это притом, что созданная нами функция импорта умела работать пока только с одним из почтовых сервисов. Получив количественные статданные, столь однозначно подтвердившие нашу гипотезу, мы немедленно приступили к разработке усовершенствований, необходимых для интеграции нашего приложения с другими почтовыми провайдерами. В конечном итоге это привело к дополнительному улучшению ключевой метрики.

Рисунок 14.6. Среднее количество приглашений, посылаемых одним пользователем: до и после запуска

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

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

Как уже обсуждалось в главе 7, A/B-тестирование, также известное как сплит-тестирование, представляет собой количественный метод исследования, в ходе которого вы проводите испытание двух (или более) альтернативных варианта одновременно, чтобы затем сравнить их эффективность. В то время, когда я работал с Friendster, специализированное программное обеспечение, которое сейчас используется для проведения A/B-тестирования, было недоступно, а создание собственного инструментария потребовало бы привлечения большого количества ценных инженерных ресурсов. Поэтому я просто провел сравнение значений улучшаемой метрики по состоянию на «до и после», и получил прекрасный результат. Современные технологии позволяют с легкостью проводить A/B-тестирование для каждой из реализуемых идей по улучшению продукта. Запуск обновленной версии одновременно со старой помогает исключить влияние на результат каких-либо посторонних факторов.

Важным понятием в A/B-тестировании является степень статистической достоверности, которая зависит от различий в характеристиках сравниваемых вариантов и от размера выборки. Существуют онлайн-инструменты, которые помогают рассчитать значение показателя статистической достоверности для любого теста. Соответственно, вам не требуется владеть методикой его расчета, но важно понимать, что статистическая достоверность выше при существенных различиях в характеристиках и при больших размерах выборки. Если размер выборки слишком мал, вы не получите статистически значимых результатов. Если объектами тестирования являются два очень схожих по характеристикам варианта, может потребоваться очень большой размер выборки, чтобы выявить хоть какие-то статистически значимые различия показателей.

Арсенал инструментов для проведения A/B-тестирования отличается большим разнообразием и включает в себя такие приложения, как Optimizely, Unbounce, KISSmetrics, Visual Website Optimizer и Google Content Experiments (в составе Google Analytics). Многие компании предпочитают создавать собственные платформы для A/B-тестирования. Все эти инструменты позволяют взять один или несколько подлежащих проверке вариантов (например, целевой страницы) и затем случайным образом распределить между ними пользовательский трафик. Далее происходит отслеживание результатов по интересующему вас показателю, что в итоге обеспечивает понимание того, как работает каждый из протестированных вариантов с указанием степени статистической достоверности, рассчитанной на основании размера выборки.

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

Компания Netflix славится своей приверженностью A/B-тестированию, причем как на маркетинговом, так и на продуктовом направлениях. В ответ на вопрос «Для каких функций, помимо процедуры регистрации, Netflix проводит A/B-тестирование?», заданный на веб-сайте Quora, директор по продуктам Netflix Нил Хант ответил: «Если коротко, то почти для всех». Далее он рассказал, что Netflix проводит сравнительное тестирование различных вариантов пользовательского интерфейса, алгоритмов рекомендаций, расположения и размеров кнопок, времени загрузки страниц и уровней качества кодирования потокового видео. Свой ответ Хант завершил словами:

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

Метод A/B-тестирования – это основной инструмент для формирования решений в отношении продукта, основанных на фактических данных. Эти данные отражают поведение большого числа пользователей, поэтому в данном случае не возникает риска расхождения между тем, что говорят участники тестирования, и тем, что они реально делают. В этот момент вы не сидите с ними рядом, поэтому не должно быть никаких опасений по поводу того, что присутствие модератора может повлиять на результаты теста. Конечно, разработчики не должны полагаться исключительно на количественные исследования – не стоит забывать и об Опре. Во многих случаях количественное тестирование должно быть дополнено качественным исследованием, способным объяснить причины, стоящие за поведением пользователей.

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

Давайте вернемся к пирамиде соответствия продукта рынку, снова показанной на Рисунке 14.7. Гипотезы, которые вы выдвигаете на одном слое, влияют на все слои, находящиеся выше. Гипотезы, относящиеся к уровню пользовательского опыта, являются наименее затратными для внесения изменений. Изменение набора функций продукта также возможно, но потребует уже больших усилий. Что же касается основополагающих элементов соответствия продукта рынку – представление о целевых клиентах, их недостаточно удовлетворенных потребностях, а также ценностное предложение, – то их будет очень сложно изменить после того, как вы создадите свой продукт. Как только вы сформулируете свои гипотезы, соответствующие этим слоям пирамиды, они становятся похожи на взаимосвязанные тектонические плиты. Если вы сдвинете хотя бы одну из них после завершения разработки, созданный вами продукт в значительной мере утратит свою актуальность и устойчивость – эффект будет подобен тому, как землетрясение превращает здание в руины. Когда это происходит, человеческая природа заставляет нас стремиться к сохранению и повторному использованию как можно большей части результатов уже проделанной работы. Но это может добавить обременительные ограничения в пространство решений, что еще больше осложняет ситуацию в условиях, когда изменение гипотез происходит в пространстве проблем. В таких случаях бывает проще начать строительство с нуля, уже на новом фундаменте.

Рисунок 14.7. Пирамида соответствия продукта рынку

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