В начале этой главы кинопродюсер Пол утверждал, что он понимает проблему клиента, потому что это его собственная проблема: он занятой человек с деньгами, у которого нет времени на покупки. Следовательно, всем занятым людям нужен интернет-магазин, в котором они смогут подобрать высококлассный гардероб. Если бы эта логика работала для каждой предлагаемой ценности, я могла бы посмотреть на предложение и сказать: «Когда я планировала собственную свадьбу, бюджет был сильно ограничен, и труднее всего было найти в Лос-Анджелесе место для проведения свадьбы, которое было бы мне по средствам». И это было действительно так для меня, но будет ли эта проблема актуальна для всех будущих невест?
Наступает момент, когда вам стоит сформулировать и записать гипотезу о клиенте и проблеме. Например, она может выглядеть так:
Будущим невестам в Лос-Анджелесе трудно найти место для проведения свадьбы, которое было бы им по средствам.
Это утверждение, если оно окажется истинным, подтвердит важную необходимость предлагаемой ценности:
Airbnb для поиска места для проведения свадьбы.
И тогда приходит время сделать следующий логичный шаг: начать продумывать функциональность этого востребованного решения, верно? Нет. Еще нет.
Помните программиста из главы 1? Он взялся сразу за построение решения для своего стартапа. Он предположил, что такие клиенты, как он (у которых любимый человек стал наркоманом), будут заинтересованы в онлайн-платформе, где они могли бы получить информацию о ценах в клиниках. Также он предположил, что таких клиентов будет много – или по крайней мере достаточно, чтобы поддерживать бизнес-модель в жизнеспособном состоянии. Да, эти предположения были именно этим: предположениями. Он не мог понять, почему его продукт не пользовался успехом, пока моя группа не провела эксперименты по исследованию пользователей. Эксперименты показали ошибочность этих рассуждений: крайне маловероятно, чтобы клиенты (в том числе и достаточно состоятельные) заказывали место в клинике через Интернет точно так же, как они заказывают номер в гостинице. Он услышал от потенциальных клиентов то, чему сначала не хотел верить: заказ места в клинике был слишком эмоциональным решением, чтобы его можно было осуществить онлайн.
А теперь совет от профессионала:
Не стройте UX своего продукта на предлагаемой ценности, пока у вас не будет веских доказательств того, что продукт действительно нужен людям!
Если вы занимаетесь решением проблем (что свойственно UX-дизайнерам, создателям продуктов и предпринимателям), этот процесс может показаться вам обратным. И правильно! Мы осуществляем инженерный анализ решения, чтобы проверить свои предположения относительно клиентов и их проблемы. Этот метод особенно важен для тех из вас, кто создал десятки продуктов, в том числе и очень успешных. Не верьте собственному пиару. Вместо этого относитесь к каждому новому продукту или проекту как к эксперименту.
Как упоминалось в предисловии, я занимала должность внештатного профессора колледжа более 20 лет. Я всегда проводила занятия по одной схеме. В первую неделю студенты размышляют над проблемами, которые им хотелось бы решить при помощи технологий. Каждую неделю они двигались к итоговой курсовой работе, в которой они должны были оценить реальный продукт, для проверки которого применялись методы, описанные в книге. Весной 2014 года я предложила моим студентам Бите и Эне стажировку по теме образа продукта «Airbnb для проведения свадеб». Я представлю вам их методы и результаты, чтобы показать, как проверить любую предложенную ценность практикой и подтвердить ее жизнеспособность. Первым заданием было создание ориентировочных персонажей.
Шаг 3: Создайте ориентировочных персонажей на основании своих предположений
Персонажи (personas) могут оказаться весьма полезным инструментом: они способны дать ключевым участникам и команде продукта эмоциональное представление о потребностях, целях и мотивах конечного пользователя. В этом отношении они делают продукт более «дружественным для пользователя». Впрочем, концепция ориентировочных персонажей имеет довольно бурную историю; у нее есть как сторонники, так и противники, поэтому я сейчас немного расскажу о персонажах и объясню, почему использую их время от времени.
На заре разработки ПО специалисты, занимавшиеся разработкой и программированием продуктов, также обычно становились проектировщиками интерфейсов. Интерфейсы продуктов редко были по-настоящему удобными, потому что не тестировались на конечных пользователях. Очень часто интерфейсы лепились на скорую руку для соблюдения сроков выпуска.
Алану Куперу, известному проектировщику программных продуктов и программисту, эта проблема была известна лучше, чем хотелось бы. В 1988 году Купер создал визуальный язык программирования, который со временем превратился в Visual Basic – инновационный инструмент, в конечном счете открывший рынок для фирм-разработчиков, которые хотели создавать приложения для Microsoft Windows[26].
В 1995 году он изобрел персонажей и написал книги, которые помогали группам разработчиков освоить его целеориентированную методологию проектирования. Персонажи также стали важным инструментом, с помощью которого можно было убедить ключевых участников проекта в необходимости более удобных интерфейсов[27]. Но чтобы достичь такого уровня в создании персонажей, требовались месяцы качественных «этнографических» исследований для создания адекватных моделей всех категорий конечных пользователей.
К 2002 году персонажи стали популярным инструментом в арсенале проектировщика, но они не так уж часто использовались для достижения первоначальной цели. Вместо этого крупные интерактивные агентства, такие как Razorish или Sapient, использовали персонажей для того, чтобы «впарить» данные фазы исследования своим клиентам. При таком использовании персонажи часто превращались в смехотворные карикатуры, заполненные стереотипными подробностями, которые не были основаны ни на чем, кроме маркетинговых данных. Собственно, именно это произошло с тремя персонажами для переработанной версии сайта Oprah.com, о которой я рассказывала в главе 2. Персонажи, вошедшие в отчет по исследованиям, были представлены как трое людей из разных групп этнических меньшинств, но только потому, что Опра Уинфри весьма популярна в этих группах. В действительности этническая принадлежность не имеет отношения к UX продукта. Потребуется ли афро-американским поклонникам Опры другой интерфейс или другая функциональность, в отличие от белых? При таком подходе персонажи не выполняли свои основные задачи по информированию процесса UX-стратегии. Купер об этом пишет так: «Не путайте архетипы персонажей со стереотипами. Так как персонажи предоставляют ориентир для проектирования, а также служат средством передачи информации группе разработки, проектировщик должен тщательно выбирать конкретные демографические характеристики персонажей».
В третьем издании книги Купера About Face, опубликованном в 2007 году, появился новый раздел, который назывался «Когда полноценные персонажи невозможны: ориентировочные персонажи»[28]. Концепция ориентировочных персонажей была предназначена для производителей продуктов, которые не располагали временем, бюджетом или корпоративной поддержкой для проведения работ, необходимых для сбора подробных качественных данных. Такие персонажи быстро создавались в ходе простой совместной работы как проектировщиков, так и других специалистов. Более того, проектировщик и автор Джефф Готелф ввел персонажей как прием
