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

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

Несмотря на то что с момента появления книги было написано большое количество гайдов по персонам, отрасль не стояла на месте. Появлялись новые методы проектирования и другие интересные фреймворки. И вроде бы персонажи отошли на второй план, уступив место новым механикам. Например, многие сторонники Jobs-To-Be-Done убеждены в том, что их методология значительно превосходит персоны в плане практического применения. Но так ли это?

Мы считаем, что персоны сейчас более чем актуальны и способны повысить эффективность процесса работы над цифровым продуктом. Далее в статье мы покажем, что данный метод вовсе не противоречит новым подходам, в том числе Jobs-To-Be-Done. Но, наоборот, прекрасно их дополняет, а в некоторых случаях лежит в основе. В общем, обо всем по порядку.

Персонажи помогают всей команде разработки 

Главный плюс метода персонажей заключается в том, что он помогает внести ясность в проект и тем самым сплотить команду проектировщиков и разработчиков. Как следствие, дизайн продукта получается более осмысленным, а пользователям, чьи интересы мы учитывали, результат кажется более понятным и логичным. 

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

Расскажем более подробно о том, какие преимущества мы видим в проработке персонажей при проектировании интерфейсов.

1 — Эмпатия к пользователю и синхронизация команды разработки

1. Знать клиента в лицо

Гораздо проще разрабатывать продукт, зная «в лицо» тех, кто им будет пользоваться. Понимание ключевых потребностей персонажа, его мотивации и ценностей, а не только его конкретных задач в рамках определенной ситуации, значительно снижает риск разработки универсального дизайна «для всех» (а по сути, ни для кого). 

Пример ниже иллюстрирует персону, разработка которой велась в рамках проектирования интернет-магазина детских товаров.

2. Легче понять проблему

Фокус на конкретном персонаже, а также реалистичное описание его проблемы вынуждают нас искренне сочувствовать герою. С одной стороны, это позволяет каждому члену команды отвлечься от своего субъективного видения ситуации. А с другой — синхронизирует дизайнеров и разработчиков, улучшая коммуникацию в рамках процесса разработки продукта. 

3. Проще запомнить характеристики сегмента пользователей

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

Так, при общении с командой мы можем говорить 

не «Как мы улучшим интерфейс, чтобы повысить конверсию сайта при посещении данным сегментом пользователей?», 

а «Как мы поможем Олегу быстрее и проще купить диван?» 

Помните Дашу-путешественницу из одноименного мультфильма? Это вызывает улыбку, но вспоминая ее, мы тут же понимаем контекст.

Так же и в разработке — мы помним, какая проблема была у конкретного клиента, и приступаем к работе без дополнительного обращения к проектной документации. 

Кстати говоря, аналогичный подход описал и Алан Купер в своей книге «Психбольница в руках пациентов», в которой сформулировал метод персон. Правда, изначально цель была немного другой, а именно — убедить разработчиков сделать что-то не для себя, а для кого-то конкретного. 

Отрывок из книги:

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

Программист: «Что если пользователь захочет вывести это на печать?»

Проектировщик взаимодействия: «Розмари печать не нужна».

Программист: «Кому-то может понадобиться печать».

Проектировщик взаимодействия: «Но мы проектируем для Розмари, а не для кого-то».

4. Проще демонстрировать данные и воспринимать их

И наконец, что вам ближе для восприятия — сложный массив данных или описание реального человека? Полагаем, что второе. Потому что при виде фотографии «Михаила», «Ольги» или «Константина» возникает ряд ассоциаций, которые связаны именно с этими конкретными людьми. От списка «job stories», а также цифр и графиков такого эффекта, как правило, не бывает.

2 — Часть маркетинговых коммуникаций, а также основа других методов проектирования цифровых продуктов

1. Разработка ценностного предложения (Value Proposition Canvas, VPC)

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

Чаще всего первым этапом формирования VPC является сегментация пользователей по различным критериям. Каждый сегмент характеризуется своими собственными проблемами и ожиданиями. И для каждого необходимо разработать свое собственное ценностное предложение (пример ниже иллюстрирует ценностное предложение интернет-магазина для парикмахеров).

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

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

2. Интеграция с Jobs-To-Be-Done (JTBD)

Если очень кратко, то идея концепции JTBD заключается в том, что один и тот же продукт разные пользователи приобретают для различных целей, а именно — «нанимают его на работу» с целью закрыть потребности. И эти потребности могут возникнуть у абсолютно разных людей с разными интересами и демографическими характеристиками.

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

Однако здесь мы слышим отголоски неправильной трактовки использования данного фреймворка. Потому что «работа, которая должна быть выполнена» уже лежала в основе описания персоны, когда Алан Купер прорабатывал данный метод. Это было неким ядром, которое обрастало подробным описанием проблем пользователя, ситуации, в которой он оказался, и его жизненных установок. Ибо что же, как не ценности и установки, напрямую влияет на возникновение различных ситуаций и задач, которые необходимо решить?

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

3. Помощь при работе с User Story и User Story Mapping

Метод User Stories часто применяют в своей работе бизнес-аналитики и владельцы продукта. «Пользовательские истории» представляют собой краткое описание функциональности в формате "Как Х, я хочу Y, чтобы Z" (к примеру, "Как маленький ребенок, я хочу посмотреть мультики, чтобы весело провести время") и демонстрируют команде разработки суть и ценность задачи, которую нужно решить. 

Конечно, можно создавать эти истории без привязки к какой-либо персоне. Но тогда получится сухое 

«Как клиент банка «Ромашка» я хочу взять кредит, чтобы сделать ремонт», 

или

 «Как клиент банка «Ромашка» я хочу узнать свой баланс, чтобы понять свои финансовые возможности на сегодня».

Однако, как только мы начинаем упоминать в User Story конкретного персонажа, у нас сразу возникает ряд конкретных ассоциаций, связанных с контекстом. Например,

«Как Мария [получает пенсию на карточку] я хочу узнать свой баланс, чтобы быть уверенной, что меня не провели мошенники»,

или 

«Как Степан [студент второго курса] я хочу получить кредит, чтобы самостоятельно оплачивать дальнейшее обучение и не зависеть от родителей».

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

Так появляется следующий артефакт — User Story Mapping. Данный метод отображает путешествие пользователя по продукту в виде конкретных шагов и рассказывает о том, какие действия он может совершать на каждом из них (User Story — это и есть описание данного действия). Получается некая карта, которая помогает сформировать бэклог развития продукта.

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

Иллюстрация ниже — это пример того, как может выглядеть User Story Mapping для интернет-магазина игрушек.

4. Основа Customer Journey Map (CJM)

CJM по аналогии с User Story Mapping помогает сфокусироваться на реальных потребностях пользователей на разных этапах, только уже не в рамках взаимодействия с интерфейсом, а при общении с компанией или брендом в целом. Предварительная проработка персонажей поможет с более глубоким анализом их интересов, потребностей и мотивов поведения. 

В дальнейшем при демонстрации пользовательского пути всей команде разработки удобнее опираться на конкретные имена. При этом, как правило, всем гораздо проще понять логику данного пути, когда ты говоришь о конкретном человеке. А именно — какие проблемы есть у различных сегментов целевой аудитории, что именно определяет тактику их поведения при поиске решения и на каком этапе необходимо перейти к активным действиям, чтобы сконвертировать конкретного пользователя в клиента. 

3 — Фундамент для проведения качественных исследований 

1. Глубинные интервью и CustDev

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

Подбор респондентов будет занимать гораздо меньше времени в том случае, если мы понимаем, кого конкретно необходимо привлечь к интервью, чтобы получить адекватную обратную связь по проекту.

2. Юзабилити-тестирования

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

4 — Выделение сегментов в данных веб-аналитики 

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

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

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

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

Наш ответ на популярные аргументы против персон

1. Не подходит для массовых сервисов

Да, действительно, крупные сервисы вроде Facebook или Google характеризуются большим количеством разных пользователей в возрасте от 0 до 90 лет, которые могут проживать в различных уголках планеты. 

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

Ниже на примере показано, как может выглядеть пользователь Facebook.

2. Не подходит для разработки стартапов 

Смысл данного контраргумента заключается в том, что при разработке стартапа мы пока еще не до конца понимаем, кто будет пользоваться нашим продуктом. Чаще всего в результате глубинных интервью (если они вообще были) проектировщики и разработчики оперируют списком «работ, которые должны быть выполнены».

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

3. Не подходит для прорывных идей 

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

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

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

4. Аудитория меняется — персонажи остаются  

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

5. Ненужный набор демографических данных

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

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

Например, наличие сына и дочери у Натальи вряд ли повлияет на ее выбор сервиса для проектирования кухни. Однако данный факт точно повлияет на выбор сервиса для отслеживания местоположения детей.

Стоит отметить, что Алан Купер, когда писал книгу «Психбольница в руках пациентов», вовсе не призывал акцентировать внимание на демографических данных. Автор, наоборот, фокусировал внимание на целях и задачах пользователя в рамках определенного контекста. 

Например, вот так в книге был описан один из ключевых клиентов авиакомпании, для которого, в том числе, разрабатывалась развлекательная система для пассажиров от Sony Trans Com (покупка интерактивных игр, фильмов и пр. во время полета): 

«Клевис Мак-Клауд, 65, World Odyssey Class, старичок под семьдесят, с причудами. Стареющий, но еще бойкий техасец, немного стесненный начинающимся артритом рук. Этот персонаж – единственный из четырех, который не имеет компьютера и не умеет компьютером пользоваться. Его девиз: «Старого пса новым штукам не выучишь», он не глуп и не ленив, а просто не любит высокие технологии. Кроме того, артрит не позволяет совершать сложные манипуляции».

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

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

Наша механика создания персонажей

1. Первичный сбор информации о сегменте пользователей

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

Интервью с клиентом, анализ данных веб-аналитики (если они есть), изучение доступных маркетинговых отчетов, конкурентов — все это помогает на стартовом этапе, который предшествует мозговому штурму команды на проекте.

2. Мозговой штурм 

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

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

3. Интервью с реальными или потенциальными пользователями

Благодаря тому, что у нас уже были подготовлены черновые варианты персон, разработаны гипотезы относительно их мотивации и задач, а также подготовлены вопросы относительно контекста, мы быстрее находим респондентов для исследования.

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

Так, всего за несколько дней мы создаем фундамент для дальнейшего проектирования и повышаем вероятность того, что конечный продукт понравится пользователям. 

Резюмируем

Фреймворк «Персоны» — это не просто набор демографических данных, которые в расплывчатой форме описывают целевые группы клиентов. Это вполне конкретное описание целей и мотивации пользователя, которое решает несколько важных задач:

1. Запускает процесс проектирования цифрового продукта — что мы конкретно делаем и для кого.

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

3. Облегчает поиск респондентов для проведения различных UX-исследований.

4. Помогает сгруппировать данные веб-аналитики для более простой их интерпретации.

5. Вызывает эмпатию и синхронизирует команду проектировщиков и разработчиков, повышая эффективность всех процессов работы над продуктом.