UX-стратегия. Чего хотят пользователи и как им это дать

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

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

Будущим невестам в Лос-Анджелесе трудно найти место для проведения свадьбы, которое было бы им по средствам.

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

Airbnb для поиска места для проведения свадьбы.

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

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

А теперь совет от профессионала:

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

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

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

Шаг 3: Создайте ориентировочных персонажей на основании своих предположений

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

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