Эффективные Персоны

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

Начнём с правильного выбора инструмента описания. Он будет зависеть от того, откуда вы начинаете свой путь боли и страдания. Если вы стартуете новый продукт, то, возможно, вам стоит оттолкнуться от функции вашего продукта, проблемы, ради которой к вам будут приходить. Здесь лучше подойдёт концепция JTBD (Jobs To Be Done), когда мы задаёмся вопросом «А зачем пользователь использует наш продукт?» или «Какую работу он с помощью него хочет выполнить?».

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

• Related Jobs — задачи связанные с основной,
• Functional Aspects — как именно пользователь хочет это делать,
• Emotional Aspects— как пользователь хочет себя чувствовать.

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

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

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

Персона — это архетип сегмента целевой аудитории, с обеъединяющими характеристиками и целями.

Впервые термин «персона» ввёл в обиход Алан Купер. Он предположил, что повышение эмпатии к пользователю во время проектирования благотворно скажется на результате. В классическом примере Купер говорит об автомобилях. Если мы хотим создать новую модель, нам нужно понимать, для кого мы её делаем: лесорубу подойдёт пикап, семьянину — минивэн, а сердцеедам — спортивный кабриолет. Если мы не выделим доминантного потребителя, то и получится у нас всё и ничего толком. Звучит здраво, но неужели на этом всё? Повышение эмпатии к пользователю и… всё?

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

Виды персон

Алан Купер был далеко не первым человеком, кто начал использовать термин «Персона». Первенство у Карла Юнга (австрийского психолога, ученика Зиги Фрейда), правда подразумевал он под персоной скорее маску или роль, которую мы играем в обществе. Это нас, конечно, сейчас мало волнует, ведь говорим мы про проектирование взаимодействия. Но данный пример наглядно иллюстрирует, что под одним термином может скрываться много определений. Возвращаясь к проектированию, когда кто-то говорит «Персона», нужно разобраться, он имеет ввиду маркетинговые персоны, прото-персоны или персоны конечных пользователей.

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

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

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

Почему персоны не работают?

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

Это пример с сайта Nilsen-Norman Group, из статьи «Почему персоны не работают». Вопрос оставим на сладкое, а пока, давайте препарируем этот экземпляр.

Что мы видим? Какой-то набор визуальных образов, цитата, краткая сводка данных, огромное полотно «О себе», тройка вопросов, тройка целей и какая-то диаграмма приоритетов. Всё это направлено на увеличение эмпатии к Джейд, чтобы создавая продукт, делать это для неё, так? Вроде сходится? Но по мне — это просто бессмысленный кусок бумаги (если она, конечно, распечатана).

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

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

1. Marketing personas VS User personas

Первой и самой банальной причиной будет путаница между этими двумя видами персон. Как не сложно догадаться, если мы составим маркетинговую персону, то в проектировании взаимодействия толку от неё будет немного. Но так как дизайнеры не осведомлены об этой разнице, то и поднимается хайп, мол «Мы составили, и что? Чем это нам помогло?». Хотя это как признаться, что не смогли забить гвоздь надувным молотком.

2. Персоны просто не используют

Ещё одной очень (вы даже не представляете насколько) распространённой причиной провала «персонного» подхода является их игнорирование. То есть, даже если артефакт был составлен с соблюдением методологии, все гипотезы были проверены, потом его просто складывают в папочку «Артефакты» и достанют только, когда нужно оформлять case-study. Кажется странным, что кто-то тратит столько сил на создание пылесборника. Но возможно, проблема-то лежит глубже: люди могут просто не знать, как использовать артефакт. Все знают о повышении эмпатии, потому и мы можем подумать «Составили. Повысили. Всё.» Но нет. Поверьте, персона может сопровождать вас долгое время помогая в принятии решений.

3. Персоны используются, когда они не нужны

Давайте сразу проясним. Персона — это не в каждом проекте затычка. Их использование ограничено. Многие не понимают этого и на каждый «Чих» расчехляют свои шаблоны для заполнения. Не стоит упоминать, насколько потом популярен слух, мол «Ничего нового персоны не дают. Всё и так очевидно». Так если всё очевидно, зачем их было делать? Если у вас есть статистика по вашему проекту, которая даёт вам всё необходимое для принятия решений — не делайте персоны. Если данные говорят «Пользователи отваливаются на третьем шаге регистрации», то не нужно составлять персоны, нужно послушать данные. Первое, что стоит уяснить, если вы не хотите попасть в этот капкан, нужно понять зачем нам персона. На какие вопросы она может помочь нам ответить. Если ответ найти не можете — не делайте персону. Вот когда вас действительно припрёт: данных не будет, продукт новый, а то его и нет, вот тогда и стягивайте покрывало с «Persona_template.pdf», а лучше просто откройте текстовый редактор.

4. Неверно составленные персоны

Мало того, что рабочие пользовательские персоны путают с маркетинговыми, так и еще иногда составляют их не верно. Сейчас сеть пестрит всякого рода красивыми шаблонами, заполняй-не хочу. Но как заполняются такие шаблоны? Как карта на стол ляжет. Никакого исследования или хотя бы разговора с пользователями не делается, всё на основе наших предположений, а это, как мы помним — прото-персона. И неудивительно, что они не работают без проверки, ведь это русская рулетка: угадал или нет?

Эффективный артефакт

Disclaimer: отсюда и далее я буду употреблять термин Персона, но подразумевать своё видение некого гибрида JTBD и персоны.

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

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

Эмпатический булшит (опционально)

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

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

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

Mighty three

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

Мотив пользователя мы найдём ответив на вопрос «Почему?». Обычно, он всего один, и он настолько глобальный, что выходит за рамки нашей системы. Можно сказать, это основополагающий мотиватор, который заставляет человека заниматься делом, которым он занимается. Это корневая причина, и использовать её напрямую не получится, но как мы убедимся дальше, косвенное задействовать её можно. Примерами мотивов могут выступать «Социальное одобрение» или «Жажда самоутверждения», «Стремление к независимости» и т.д.

Цели пользователя обычно формулируются исходя из ответа на вопрос «Зачем пользователю использовать наше приложение?». Таких целей может быть несколько, но всё они работают внутри нашего опыта пользователя. Цели обычно вытекают из мотивов. То есть, если мотивом для пользователя социальной сети будет социальное одобрение, то целями использования будут получение поддержки или обратной связи, расширение своего социального круга (общение с новыми людьми) и т.д. Цели помогают определить фокус, для чего мы создаём наш сервис, чем он поможет пользователям в реализации их мотивов. А без этого фокуса, мы будем просто пилить функции, ради функций.

Задачи же вытекают из целей и под ними обычно понимают конкретные действия, которые нужно предпринимать, чтобы добиваться своих целей. Отвечают они на вопрос «Как мне эффективнее всего добиться цели?». Это, если вам угодно, некое выражение концепции Jobs to be Done. Например, если целью стоит «расширение своего социального круга», то задачи могут принять следующий вид: «принимать и рассылать приглашения о дружбе», «видеть рекомендации системы», «возможность заблокировать нежелательный контакт» и т.д. Задачи всегда связаны с какой-то целью. Если вы придумали какую-то интересную задачу, но связи с целью нет, то вы либо выделили не все цели, либо ваша задача выходит за рамки необходимого flow, и вам стоит её пересмотреть.

Что мы можем сделать с Mighty Three:

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

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

KPIs

Этот «обвес» я бы обвёл в красный кружок. Когда мы осознали цели и задачи наших пользователей, нам просто жизненно необходимо понять, как хорошо они выполняются. Для этого и стоит определить KPIs — Key Performance Indicators, чтобы знать, куда смотреть, чтобы понять, как хорошо летим.

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

• Количество возвратов на каталог со страницы курса (значит курс не подошёл),
• Количество завершённых курсов (значит они были «подходящими»),
• Время до энроллмента и т.д.

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

Что мы можем делать с KPIs:

• Заложить фундамент грамотной аналитики, вместо коробочных решений,
• Использовать их как индикаторы эффективности во время тестов,
• Получить базовые замеры для A/B/n тестирования.

Success story

(Ментальная модель успешного взаимодействия)

В отличии от постоянно используемого размытого «одного дня из жизни», я бы советовал использовать ментальную модель пользователя.

Важность ментальных моделей можно проследить из работ Дональда Нормана. От себя же хочу подчеркнуть, что правильная ментальная модель строится на основе реальных интервью. От того, что вы просто опишите ваше представление толка будет мало, но стоит вам задать пользователю несколько вопросов о том, каким он представляет себе взаимодействие, вы получите мощный инструмент принятия решений. Вам не придётся придумывать ответ на вопрос «А чтобы сделала Джил?», у вас будет вполне чёткий ответ на этот вопрос.

Более того, ментальную модель можно оформить в виде сторифрейма, что будет первым шагом в прототипировании.

Что мы можем сделать с историей успеха:

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

Motivations and risks

Отличие мотиваторов от мотивов в том, что мотивы пользователя идут изнутри, а мотиваторы возникают во внешней среде. Хоть первые являются корневыми причинами, но вторые, то есть мотиваторы, могут сподвигнуть пользователя к действию в краткосрочной перспективе. Вы можете использовать их чтобы направлять пользователя, подталкивая к совершению целевых действий. Например, мотивом может выступать «общественное признание», а мотиваторы будут частными его проявлениями. Сюда уже отнесутся: получение социального одобрения через лайки, выход в топ на лидерборде, подбадривание системы в стиле «Вашу запись просмотрели Х людей. Так держать», или получение реальных благодарностей от других пользователей.

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

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

Что можно делать с мотиваторами и рисками:

• Проектировать поведение, подталкивая пользователя к нужному поведению (этика за скобками),
• Устранять блоккеры и проблемы ещё до их появления.

Рычаги влияния Чалдини

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

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

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

Что мы можем делать с «рычагами»:

• Более эффективно влиять на людей (этика всё ещё курит за скобками),
• Избегать неэффективных решений.

Эвристики Шнейдермана

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

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

• скорость работы системы (скорость отклика на действия, затупы, подвисания, излишние отвлечения и т.д.),
• количество операторских ошибок (или вероятности совершения ошибки),
• легкость обучения работе с системой (или прозрачность, очевидность),
• индивидуальная удовлетворённость работой (визуальная привлекательность, качество эффекта и субъективное восприятие эффективности),
• … и время остаточного хранения знаний о работе с системой (как долго наши навыки работы сохранятся).

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

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

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

Что мы можем делать с эвристиками Шнейдермана:

• Делать тяжелый выбор легче,
• Принимать более эффективные решения на низком уровне.

Примеры

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

Персона внутреннего приложения по обучению персонала. 2018 год.

А вот более свежий пример, где мы вообще не использовали никакого визуального шаблона — голый текст в Coda. Если хотите посмотреть поближе, то можно зайти сюда.

Персона внутреннего приложения по обучению персонала. 2022 год.

Кто-то вообще этим заморачивается?

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

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

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

На этом у меня всё. Желаю вам успешного проектирования, счастья-здоровья и корабль любви. 🛳❤️

Напомню, что у меня есть канальчик в телеге, на котором я делюсь всякими интересностями и своим мнением о них. Только контент, хоть и не регулярный :)

Буду рад, если похлопаете, поделитесь или выскажите своё мнение в комментах. Ещё раз, спасибо.