Некоторое время назад я выступал на конференции ISDEF и рассказывал о том, что бывает, когда программисты вынуждены заниматься проектированием интерфейсов.
В этой статье я озвучу основные мысли этого доклада, а также поделюсь своими соображениями по поводу того, как правильно продакт-менеджер должен смотреть на продукт.
Суть проблемы
Примеры того, как замечательно программисты могут проектировать UX, попадаются сплошь и рядом.
Например, это замечательная форма заполнения истории из трудовой книжки на портале гос. услуг (про неё я уже писал), которая убивает сессию через 15 минут после открытия и заставляет пользователя перегружать страницу с потерей всех данных.
Это чудесные формы по заполнению совершенно непонятной информации, как на рисунке слева.
Это закрывающиеся окошки текстового редактора, которые даже не пытаются предложить сохранить текст, на который несчастный пользователь потратил два часа своей жизни.
Мне очень грустно работать с таким ПО. Я понимаю, что его писали первоклассные специалисты, я допускаю, что код этих систем тоже в полном порядке. Однако я не стану ими пользоваться. В крайнем случае, если у меня не будет выбора, я всё-таки буду «плакать, колоться и жрать кактус», но при этом окончательно испорчу карму разработчикам своими мало литературными комментариями.
Почему?
Конечно же, у нас сразу возникает вопрос: почему? Почему это происходит? Почему даже самые лучшие программисты, проектируя идеальную архитектуру и пишущие совершенный код, делают грубейшие ошибки при проектировании взаимодействия с пользователем?
Понять это достаточно легко. При разработке программного продукта прежде всего необходимы: чёткость, логика, скрупулёзный анализ и умение структурировать имеющуюся информацию. Как утверждают психологи, это функции левого полушария, ответственного за логику, рациональное и анализ.
В свою очередь, при разработке интерфейсов, дизайна, при создании новых требований к продукту, которые уменьшали бы «боль» пользователя, необходимо не только чувство прекрасного, умение мыслить креативно, создавать и выдумывать что-то новое, но и сильно развитое чувство эмпатии – умение сопереживать окружающим, ставить себя на их место, чтобы понять, что им действительно надо. Это, по заверениям всё тех же психологов, функции правого полушария, отвечающего за чувства и эмоции.
Конечно, можно собрать сотни листов статистики и отзывов, полученных от пользователей, проанализировать их и понять, каких функций не хватает большинству из них, и при решении каких задач возникают наибольшие сложности. Но это не позволит создать по-настоящему нужный, удачный и новый продукт.
Пользователи не всегда могут описать, чего конкретно они хотят, иногда они даже сами этого не знают. Они могут чувствовать, что им «не удобно», но очень редко могут объяснить, почему. Более того: они могут превратно истолковать свои неудобства или попытаться самостоятельно придумать «как им было бы удобнее», на деле не понимая того, как им было бы удобно на самом деле.
Как в своё время сказал Генри Форд: «Если бы я спрашивал людей, чего они хотят, они бы попросили более быструю лошадь».
Что делать?
Итак, что же делать, если пользователи сами не знают, чего хотят, а, если и знают, то не могут нормально сформулировать?
Во-первых, забыть слово «пользователь». На мой взгляд, оно крайне вредно при проектировании продукта. Его имеет смысл использовать только при составлении требований в связке «пользователь должен иметь возможность…». Почему? Всё достаточно просто: «пользователь» безлик. У него нет имени, пола, возраста, причёски, детей, которые сидят у него на коленях во время работы. Он не думает о том, что надо отвезти машину в ремонт или сварить ужин. «Пользователь» никогда не воскликнет «как же мне надоело вносить одну и ту же кнопку десять раз!», он никогда не скажет «чёрт возьми, я опять промахнулся мимо этого элемента на экране смартфона, т.к. автобус тряхнуло!».
«Пользователь», он же “The user” или даже «Зэюзер» — самое серое, безвольное, бесправное и угнетаемое существо на планете.
Итак, мы забываем слово «пользователь». Чем его заменить? Для начала, можно воспользоваться замечательным инструментом под названием «персоны». Персонификация позволит безликим «зэюзерам» обрести имя, лицо, профессию и хобби. Так гораздо проще. Но и это ещё не всё.
Полное перевоплощение
На мой взгляд, мы должны не просто использовать персон. Мы должны стать ими. Это очень важный момент, который позволит нам на секунду перевоплотиться в сисадмина Васю или Аню, продавца самодельных поделок из бисера. Мы должны думать как Вася, хотеть того же, что хочет Вася и полностью проникнуться его заботами, проблемами и радостями.
Это требует развитой эмпатии. Это требует долгой и усиленной работы, понимания своего пользователя. Не «зэюзера», а того самого Васи или той самой Ани. Эта работа сродни работе актёра, вживающегося в роль. Но эта работа всегда приносит плоды. Чем глубже вы залезете в шкуру пользователя, тем лучше поймёте, что именно ему надо, почувствуете ту боль, которую будет лечить ваш продукт.
Кстати говоря, стандарты советуют формировать пользовательские истории, примерно в таком виде: «как <роль> я хотел бы…». Таким образом, они прямо ставят того, кто их пишет (а обычно это Product Owner) на место пользователя.
Eat your own dog food
Наверное, самой простой способ вжиться в роль вашего пользователя – начать использовать собственный продукт самому.
«Мы сами едим собачий корм, который производим». Эта фраза впервые появилась в 1970-е годы в рекламе компании Alpo, производящей корм для домашних животных и теперь, с лёгкой руки Microsoft, активно используется при разработке программного обеспечения. Наш продукт настолько хорош, что мы пользуемся им сами.
Наверное, одним из самых ярких примеров такого подхода является популярная система контроля версий Git. Через три дня после старта проекта его исходный код был помещён … в Git, и в дальнейшем разработка этого инструмента велась с помощью него самого.
Один мой знакомый, придя на собеседование в достаточно известную компанию по разработке ПО, увидел, что большинство сотрудников использует софт своих конкурентов. Проводить собеседование не имело смысла. Он уже знал, что в этой компании работать не будет.
Кому нужен ваш продукт, если вы сами им не пользуетесь, предпочитая продукт конкурентов? Какого он качества? Зачем вы вообще его выпускаете и кого пытаетесь обмануть?
Если вы хотите разработать по-настоящему нужный продукт – обязательно пользуйтесь им. Иначе будет очень сложно оценить его качество, надёжность и удобство использования.
С другой стороны, нужно очень чётко отдавать себе отчёт в том, что ваши личные предпочтения могут не совпадать с предпочтением большинства пользователей. Например, я привык вызывать программы, нажав Win+R, после чего набираю имя исполняемого файла запускаемого приложения. Но я прекрасно понимаю, что, с огромной вероятностью, ни один из пользователей нашего продукта так не делает.
Для менеджера продукта очень важно отложить в сторону собственное эго и рассматривать продукт непредвзято. Но это уже совсем другая история.
Выводы
Для того, чтобы сделать хороший продукт надо видеть его глазами пользователей. Нужно знать пользователей в лицо, понимать, что им надо и видеть их проблемы. Причём так, чтобы пользователи стали частью вас, частью вашего продукта, частью каждой фичи и каждого принимаемого решения.
И тогда ваш продукт будет полезным, удобным и востребованным. А значит – успешным.
Удачи в разработке ваших продуктов!
Автор: Tomcat
