Актуален ли метод создания персонажей для реализации UX-стратегии?

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

Ранние дни веб-дизайна

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

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

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

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

Персонажи как инструмент дизайна

Одним из самых ранних методов моделирования, широко использовавшихся в стратегии проектирования веб-дизайна, были персонажи.
Впервые об таком способе разработки сайтов заговорил Алан Купер, а Ким Гудвин так объяснила его на примере сайта самого же Купера:

У меня была возможность провести много проектов с использованием персонажей для крупных компаний США, Европы и Южной Америки.
Мне нравятся такие проекты, потому что они позволяют мне хорошо понять желания и ожидания ключевого сегмента пользователей ещё до того, как я начну создавать для них тот или ной продукт.
В ходе создания персонажей, я исследую такие вопросы, как:

Проекты с использованием персонажей позволили мне проводить много, как мне кажется, интересных, групповых мероприятий:
домашние интервью, видео-дневники, совместные покупки с незнакомыми пользователями (прим. переводчика: shop-alongs) и составление карты пути потребителя
(прим. переводчика: journey mapping, более подробно о методе см. здесь) Мне нравится даже процесс анализа данных в проектах по созданию персонажей: в течение этого этапа мы пересматриваем все видео и интервью,
которые у нас есть, и размечаем их тегами, отражающими темы, возможности и паттерны, которые и выявляют различия между будущими персонажами. Затем мы развешиваем фотографии,
артефакты и цитаты по всем стенам нашей рабочей комнаты, чтобы разобраться и структурировать собранные нами данные, используя методологию «обоснованной теории» (прим. переводчика: grounded theory,
более подробно о методе см. здесь).

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

Веб-аналитика

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

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

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

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

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

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

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

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

A/B и многофакторное тестирование

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

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

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

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

Гибкие (agile) и бережиливые (lean) подходы к разработке

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

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

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

Заключение

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