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