User Persona и Empathy Map

Общее #

• Назначение: представление целевого пользователя для синхронизации команды и проектирования решений «для кого», а не «вообще».
• Аудитория: PM, UX-дизайнеры, маркетологи, разработчики.
• Статус: устоявшийся (Persona — Cooper, 1999; Empathy Map — Gray, Gamestorming, 2010).
• Не путать с: buyer persona (маркетинговая персона про решение о покупке; user persona — про использование продукта), Jobs-to-be-Done (#19 — рамка мышления о «работе» клиента, а не описание человека), Customer Journey Map (#20 — путь персоны по точкам контакта, а не портрет), Value Proposition Canvas (#22 — канва связи профиля клиента с ценностным предложением).

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

Empathy Map (карта эмпатии) — одностраничная схема, раскладывающая внутренний мир персоны по квадрантам: что человек говорит (Says), думает (Thinks), делает (Does) и чувствует (Feels), плюс два дополнительных блока — боли (Pains) и желаемые результаты (Gains). Карта — быстрая надстройка над персоной: тот же сегмент, но в фокусе не демография, а наблюдаемое поведение и эмоции.

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

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

Происхождение: персоны #

Метод персон ввёл Алан Купер — программист и консультант по проектированию взаимодействия — в книге The Inmates Are Running the Asylum (1999). Работая консультантом, Купер заметил: обсуждения требований вращаются вокруг личных мнений участников, потому что «пользователь» — пустой указатель, который каждый разыменовывает по-своему. Приём оказался прост: описать одного конкретного человека (роль, цели, привычки, раздражители) и обсуждать функции через него — «нужно ли это ему?» вместо «кажется, пользователям это нравится».

Сам Купер в эссе The Origin of Personas (2008) относит появление первой персоны к началу 1980-х: проектируя интерфейс телефонной голосовой почты, он придумал конкретного пользователя — «Чака» — и вёл проектирование в диалоге с этим вымышленным собеседником. Показательно, что персона появилась раньше самого термина: потребность в конкретном адресате проектирования возникла из практики, а не из теории.

В книге About Face (первое издание 1995 с Реверменом, четвёртое — 2014 с Райманом и Кронином) метод был развёрнут в дисциплину: персона — не средний пользователь, а архетип, синтезированный из наблюдений; у продукта несколько персон, но каждая функция проектируется строго под одну из них. Дальнейшую стандартизацию дали UX-сообщество и Nielsen Norman Group (сводные руководства по созданию и применению персон) и книга Мульдера и Яара The User Is Always Right (2006), систематизировавшая качественный и количественный способы построения.

Происхождение: карта эмпатии #

Empathy Map придумал Дэйв Грей, основатель визуально-консалтинговой компании XPLANE, и опубликовал в книге Gamestorming (2010, с Санни Браун и Джеймсом Макануфо) как групповую «игру» для быстрого погружения в клиента. В первоначальной версии вокруг фигуры клиента раскладывались ответы «что он видит / слышит / думает и чувствует / говорит и делает» плюс боли и выигрыши. В обновлённой канве (2017) квадранты приведены к формату Says / Thinks / Does / Feels — именно эта версия стала стандартом: она убирает дублирование «видит/слышит» и фокусирует команду на расхождении слов, мыслей, дел и эмоций.

Персона и смежные рамки #

Персона занимает своё место в ряду артефактов описания клиента:

Артефакты не конкурируют, а образуют лестницу: персона задаёт «кто», JTBD — «зачем», CJM — «как идёт», VPC — «что мы предлагаем». Команда, у которой есть персоны, но нет пути, знает клиента, но не видит его опыта; команда с картой пути, но без персон, рисует путь никого.

Персона в B2C и B2B #

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

В B2B вокруг одной сделки существует несколько ролей: пользователи (менеджеры, аналитики), решающие (руководитель, чья боль оплачивает покупку), влияющие (безопасник, финансист, IT-администратор). Каждой значимой роли соответствует своя user-персона со своими целями и болями, а стороне, принимающей решение о покупке, — отдельная buyer-персона. Практическое следствие: в B2B набор персон растёт с числом ролей, но рабочее ограничение остаётся — одна-две ключевые персоны на роль, остальное — обзорно. Классическая ошибка B2B — единственная персона «директор», которой описываются и пользователь, и покупатель: ни того ни другого портрет не описывает.

User Persona: анатомия #

Рабочая персона собирается из обязательных полей. Пропуск любого из них превращает портрет либо в анкету из фотостока, либо в список пожеланий.

Обязательные поля #

• Имя и фото. Вымышленные, но конкретные: имя человеческое, а не «Пользователь CRM»; фото — нейтральный портрет, а не узнаваемый стоковый «счастливый офисный клерк». Имя даёт команде естественную ссылку в разговоре: «это Марии надо, а это — нет».
• Демография и роль. Возраст, сфера, должность, контекст компании: «руководитель отдела продаж из 5 человек в интернет-магазине». Роль важнее возраста: поведение определяется тем, что человек делает, а не годом рождения.
• Цели (Goals). Чего персона хочет достичь — в терминах её работы и жизни, не в терминах продукта. «Иметь одну проверенную картину сделок», а не «использовать дашборд».
• Боли (Pain Points). Что мешает сегодня: трение, страхи, потери. Формулировки — словами самого клиента из интервью, не языком команды: «неудобный UX» — не боль, «трижды перепроходить регистрацию» — боль.
• Поведение (Behavior). Как решает задачу сейчас: какими инструментами пользуется, какие обходные пути строит, что уже пробовала и бросила. Поведение — самый фактурный блок: его нельзя выдумать, только собрать.
• Мотивация. Почему стремится к целям: карьерные амбиции, признание, страх ошибки, спокойствие. Мотивация объясняет откуда берутся цели и почему одни функции персоне важнее других.
• Контекст использования. Когда, где и на чём пользуется продуктом: ноутбук или телефон, офис или дорога, одна минута между встречами или вечер за сверкой. Контекст определяет требования к интерфейсу, которые не выводятся из роли.
• Цитата. Одна фраза от первого лица, звучащая как реальная речь этого человека. Цитата — «заголовок» персоны: команда запоминает её быстрее, чем весь портрет.
• Уровень технической грамотности. Насколько уверенно персона обращается с техникой: что для неё «просто» (Excel, мессенджеры), что пугает (интеграции, импорт данных). Поле защищает от проекции «все люди как мы».

Шаблон персоны #

Базовый шаблон — таблица с полями. Пример заполнения — сквозная для этой статьи персона «Мария» (та же фигура, для которой в статье о CJM (#20) рисуется карта пути):

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

Признаки хорошей персоны #

Чек-лист качества портрета:

• Цитата узнаётся. Реальные клиенты, читая персону, говорят «это про меня» или «это про моих коллег» — типовая проверка NN/g. Если клиент узнаёт портрет, но не узнаёт себя в деталях, персона описывает карикатуру.
• Утверждения прослеживаются до данных. Каждое утверждение о целях, болях и поведении имеет источник — конкретное интервью, тикет, наблюдение. Персона из «логичных соображений» — та же proto-persona без пометки.
• Персона помогает отказывать. Портрет, который не позволяет сказать «нет» фиче или сегменту, — иллюстрация, а не инструмент. Рабочая персона каждый день участвует в решениях «делаем / не делаем / не для кого».
• Не один респондент и не среднее по всем. Персона — архетип, собранный из повторяющихся паттернов: портрет одного яркого интервьюируемого — anecdote; усреднение всех ответов — «средний пользователь», у которого нет ни одной реальной черты.
• Команда называет персон по именам. «Это для Марии» в бэклог-сессии — главный практический признак: имена вошли в рабочий язык команды.

Виды персон #

Способ создания персоны определяется источником данных — от этого зависит, чем персона является: гипотезой или фактом.

Proto-persona #

Персона-гипотеза, собранная командой без исследований — за часовой воркшоп из представлений о клиенте («наш пользователь — скорее менеджер среднего звена, занятой, с телефона»). Термин закрепила практика Lean UX (Джефф Готхельф): proto-persona честно помечается как допущение и живёт до первой встречи с реальными клиентами. Ценность — стартовая точка: лучше явно зафиксированная гипотеза, чем размытые представления в головах. Риск — гипотеза, забывшая, что она гипотеза: команда начинает проектировать «для Марии», которую придумала, а не нашла.

Qualitative persona #

Персона, синтезированная из качественных исследований — глубинных интервью по методике Customer Development (#18) и UX-исследований: 10–20 интервью на сегмент, поиск повторяющихся целей, болей и паттернов поведения, группировка в архетипы. Это стандартный вид рабочей персоны: глубина интервью даёт и фактуру (цитаты, обходные пути), и уверенность, что портрет собран из реальных людей.

Statistical persona #

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

Anti-persona #

Персона, описывающая, кого продукт не обслуживает: например, «продукт для команд от 3 человек — фрилансер-одиночка не наш пользователь». Anti-persona фиксирует границы: какие запросы вежливо отклоняются, на ком не тратится разработка, каких пользователей поддержка переадресует. Без явной anti-персоны продукт разбухает: каждая просьба «а сделайте и для одиночек» выглядит как рост, хотя на деле — размывание. Анти-персоны особенно важны на ранних стадиях, когда отказ от сегмента даёт ресурс на главный.

Сводная таблица #

Траектория зрелости #

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

Proto-persona      →    Qualitative persona    →    Statistical persona
(гипотеза команды)      (10–20 интервью CustDev)     (аналитика: масштаб, кластеры)

• До интервью существует только proto-persona: она фокусирует первые разговоры с клиентами — команда идёт проверять описанную гипотезу, а не «общаться с пользователями вообще».
• После первой серии интервью прототип заменяется качественной персоной: фактура из интервью перезаписывает представления команды, сегментация фиксирует 2–4 устойчивых архетипа.
• С ростом продуктовой аналитики добавляется статистический слой: масштаб сегментов, поведенческие кластеры, сверка портретов с реальным использованием. Пересборка по данным, а не по интуиции.

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

Empathy Map: карта эмпатии #

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

Квадранты и блоки #

• Says (что говорит). Озвученное: цитаты из интервью, звонков, тикетов — дословно, без редактуры. «Пока нас устраивают таблицы» — так, как прозвучало.
• Thinks (что думает). Неозвученное: соображения, опасения, мечты, которые читаются между строк — по паузам, оговоркам, по тому, что человек рассказывает с жаром. Именно здесь живёт то, что клиент никогда не скажет в лоб: «боюсь выглядеть некомпетентной на созвоне».
• Does (что делает). Наблюдаемое поведение: что человек фактически делает, какими инструментами пользуется, какие обходные пути строит. Из данных интервью и наблюдений — не из предположений «наверное, сначала читает справку».
• Feels (что чувствует). Эмоции по ходу истории: тревога перед отчётом, облегчение после, раздражение на рутину, интерес на демо. Читается по словам о чувствах, а не приписывается фасилитатором.
• Pains (боли). Итог сверху: страхи, препятствия, риски на пути к цели.
• Gains (желаемые результаты). Итог снизу: чего человек хочет достичь и что для него «успех» — включая неожиданные критерии («выйти из Excel в пятницу в шесть»).

Сводка по блокам:

Схема карты — сетка два на три:

                    WHO — персона: Мария, руководитель отдела продаж
┌──────────────────────────┬──────────────────────────┬──────────────────────┐
│          SAYS            │          THINKS          │        PAINS         │
│ что говорит:             │ что думает:              │ боли и страхи:       │
│ дословные цитаты из      │ неозвученные мысли,      │ препятствия и риски  │
│ интервью и разговоров    │ опасения, мотивы         │ на пути к цели       │
├──────────────────────────┼──────────────────────────┼──────────────────────┤
│          DOES            │          FEELS           │        GAINS         │
│ что делает:              │ что чувствует:           │ желаемые результаты: │
│ наблюдаемое поведение,   │ эмоции в ходе            │ что значит для неё   │
│ инструменты, обходные    │ взаимодействия           │ «получилось»         │
│ пути, привычки           │ с задачей и продуктом    │                      │
└──────────────────────────┴──────────────────────────┴──────────────────────┘

Ключ карты — не сами квадранты, а стыки между ними: Says против Does («устраивает таблицы» — но пятница уходит на ручную склейку), Says против Thinks («всё под контролем» — при страхе ошибиться). Расхождения указывают, где клиент недоволен текущим положением, но ещё не формулирует это как запрос.

Как заполнять #

Карта заполняется командой за 60–90 минут по заранее собранному сырью:

1. Подготовить данные. Распечатанные цитаты интервью, тикеты поддержки, записи сессий — по одной персоне/сегменту. Карта без сырья — коллективная фантазия.
2. Зафиксировать WHO. Имя персоны и её ситуация: «Мария выбирает CRM». Одна карта — одна персона в одном контексте.
3. Разложить Says и Does. Сначала фактура: цитаты и наблюдаемое поведение переносятся на стикеры дословно, с пометкой источника («интервью №4»).
4. Вывести Thinks и Feels. Команда помечает выводы, читаемые между строк, другим цветом — чтобы гипотеза не смешивалась с фактом.
5. Собрать Pains и Gains. Итоговые блоки формулируются из квадрантов: повторяющиеся страхи — в Pains, критерии успеха — в Gains.
6. Прочитать стыки. Финальный проход: где Says расходится с Does и Thinks — там первый кандидат на продуктовую гипотезу.
7. Отметить пробелы. Пустой квадрант — не ноль, а задание: какие вопросы добавить в следующее интервью.

Пример #

Карта эмпатии для Марии (сегмент «руководитель отдела продаж, выбирает CRM»):

                    WHO — Мария, 34, руководитель отдела продаж (5 менеджеров)
┌──────────────────────────┬──────────────────────────┬──────────────────────┐
│ SAYS                     │ THINKS                   │ PAINS                │
│ «Пока нас устраивают     │ «Таблицы уже не вывозят, │ Пятница уходит на    │
│ таблицы»                 │ но если CRM не окупится, │ ручной отчёт; страх  │
│ «Мне не нужна ещё одна   │ скажут, что я необосно-  │ потерять крупную     │
│ система — нужна одна     │ ванно потратила бюджет»  │ сделку; авралы при   │
│ правда по сделкам»       │ «С новым инструментом    │ ротации менеджеров   │
│                          │ команда не справится»    │                      │
├──────────────────────────┼──────────────────────────┼──────────────────────┤
│ DOES                     │ FEELS                    │ GAINS                │
│ Ведёт сделки в Excel и   │ Усталость от рутины;     │ Один источник правды │
│ мессенджерах; просит     │ тревога перед отчётом    │ по сделкам; отчёт    │
│ аналитика выгружать      │ руководству; интерес на  │ «собирается сам»;    │
│ цифры; откладывает выбор │ демо нового инструмента; │ спокойная пятница;   │
│ CRM «до отпуска»         │ скепсис к «ещё одной     │ контроль без микроме-│
│                          │ системе»                 │ неджмента            │
└──────────────────────────┴──────────────────────────┴──────────────────────┘

Чтение примера: Says («устраивают таблицы») против Does (просит выгрузки, откладывает выбор) и Pains (пятница на отчёт) показывает классический паттерн — привычка сильнее боли, толчок к переключению ещё не созрел. Продуктовый вывод — не «добавить функций», а снижать цену перехода: миграция данных руками команды, параллельный запуск со старым процессом. Такие выводы карта даёт за полтора часа — дешевле, чем отдельное исследование.

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

Ошибки заполнения #

• Карта на мнениях. Команда заполняет квадранты «как оно наверняка есть» — без распечаток интервью и цитат. Результат — зеркальное отражение собственных представлений, оформленное как исследование.
• Одна карта на все сегменты. Попытка уместить на один лист «наших пользователей вообще» усредняет разные внутренние миры. Правило то же, что у персоны и CJM: одна карта — один сегмент в одном контексте.
• Thinks пишется от себя. Самый частый прокол: квадрант мыслей заполняется тем, что команда само собой думает, — «наверное, боится цены». Каждый вывод в Thinks обязан опираться на маркер из интервью: оговорку, паузу, жар рассказа.
• Цитаты редактируются. «Пока нас устраивают таблицы» превращается в «недоволен текущим решением» — и живая речь клиента подменяется языком команды. Says переносится дословно или не переносится вовсе.
• Карта без выхода. Заполненный лист сфотографирован и забыт. Карта обязана закончиться выводами: противоречия по стыкам, гипотезы для проверки, вопросы в следующее интервью.

Как создавать персоны #

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

Шаг 1. Провести CustDev #

Источник персон — проблемные интервью (#18): 10–20 разговоров на сегмент по правилам «прошлое вместо будущего» — конкретные эпизоды, а не мнения. Техники — из арсенала UX-исследований: глубинные интервью, наблюдение за работой, дневники. Без этого шага существует только proto-persona — честно помеченная гипотеза.

Шаг 2. Сегментировать #

Из интервью выделяются устойчивые группы: люди с одинаковыми целями, болями и поведением. Признак сегмента — не демография, а различие в поведении: «те, кто ведёт сделки в таблицах» и «те, у кого уже есть CRM» — разные сегменты независимо от возраста. Число кандидатов после сегментации обычно 5–8 — больше, чем стоит оставлять.

Шаг 3. Синтезировать #

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

Шаг 4. Собрать драфт персоны #

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

Шаг 5. Валидировать #

Драфт проверяется новыми данными: следующая партия интервью, показ персоны самим клиентам («узнаёте себя?» — типовая проверка NN/g), количественная сверка масштаба по аналитике. Сегмент, который не подтверждается, не «подправляется под ответ», а выбрасывается или помечается как гипотеза. Валидированная персона получает статус факта и дату данных.

Шаг 6. Распространить #

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

Формат: воркшоп по персонам #

Сборка персон — не «исследователь пишет документ неделю», а команда за один-два воркшопа по 2–3 часа. Типовая механика:

1. Подготовка. Фасилитатор приносит сырьё: распечатанные цитаты и эпизоды из интервью, сгруппированные предварительно по кандидатам в сегменты. Без сырья воркшоп превращается в сессию мнений — ту самую, от которой персоны должны избавлять.
2. Кластеризация. Команда раскладывает цитаты по группам «похожих людей»: общие цели, боли, поведение. Группы, состоящие из двух-трёх цитат, распускаются — сегмент должен повторяться.
3. Черновик портрета. По каждому оставшемуся кластеру заполняется шаблон персоны: сначала фактура (поведение, цитаты), затем интерпретация (цели, мотивация).
4. Имя и цитата. Портрету присваиваются имя, роль и главная цитата — то, что команда будет помнить.
5. Проверка источников. Финальный проход: каждое утверждение портрета получает пометку источника; неподтверждённое помечается как гипотеза для шага валидации.

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

Сколько персон держать #

Рабочее правило: не больше 3–5 персон на продукт. Больше — команда не запоминает и не использует: «у какой из двенадцати персон болит?» не задаёт никто. Меньше двух — обычно признак, что сегментация не проводилась. Одной первичной персоне даётся приоритет — под неё проектируется ядро продукта; остальные обслуживаются «по умолчанию». Анти-персоны в лимит не входят: их 1–2.

Частота обновления #

Персона — живой артефакт с датой данных, а не гравюра: рынок, продукт и команда меняются. Ориентиры зрелости: пересмотр при значимых изменениях рынка или продукта (новый сегмент, пивот, крупный релиз); плановая актуализация раз в 6–12 месяцев — сверка с новыми интервью и аналитикой; немедленный вывод из эксплуатации при накоплении противоречий с данными. Дата последней валидации указывается на самом портрете: персона старше двух лет без проверки читается как proto-persona.

Использование в продуктовой работе #

Персоны — не артефакт «для отчёта об исследовании»: портреты встроены в основные продуктовые процессы — от выбора фич до формулировок на лендинге. Ниже — пять типовых точек применения.

Приоритизация #

Персоны дают приоритетам адресата: каждой фиче-кандидату задаётся вопрос «для какой персоны это?» Если ответ — «ну, вообще-то для всех», кандидат получает дополнительную проверку: «для всех» чаще всего означает «ни для кого в частности». В скоринговых фреймворках вроде RICE персона наполняет содержанием блоки охвата и влияния: боль какой персоны, насколько острая, скольких её представителей затрагивает. Фича без персоны — не запрет, а красный флаг для уточнения.

Дизайн #

Персона — отправная точка проектирования: интерфейсы, сценарии и онбординг строятся от контекста, техграмотности и поведения конкретного портрета, а не от «удобства вообще». Для Марии — фрагменты по 10–15 минут и скепсис к «ещё одной системе» — значит онбординг до первой ценности обязан быть коротким, а миграция — незаметной. Решения дизайн-споров проверяются вопросом «что сделает Мария на этом экране?» — предметнее, чем обмен мнениями о вкусах.

Маркетинг #

Месседжинг формулируется от персоны: её цитаты — готовый язык объявлений и лендингов («одна правда по сделкам» — сильнее «универсальной CRM-платформы»), её Pains из карты эмпатии — структура страниц («пятница без ручного отчёта»), её Gains — обещания продукта, которые можно выполнить. Близкая дисциплина — buyer persona: та же техника портрета, но фокус на решении о покупке (кто платит, как выбирает, что мешает купить). User- и buyer-персоны в B2B почти всегда разные люди.

Коммуникация #

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

Связка с CJM и VPC #

Персона — вход для двух следующих артефактов. Customer Journey Map (#20) строится строго для одной персоны и одного сценария: персона отвечает «чей путь рисуем» — у Марии и у её менеджера пути через один продукт разные. Так сквозная Мария этой статьи переходит в сквозную Марию статьи о CJM: карта пути показывает, что персона делает, думает и чувствует на каждом этапе выбора и использования CRM. Value Proposition Canvas (#22) переносит персону в плоскость предложения: блоки pains/gains карты эмпатии напрямую ложатся в профиль клиента канвы, а канва сверяет их с ценностью продукта. Цепочка «персона → карта пути → ценностное предложение» — типовая линия от исследования к стратегическому слою.

Плюсы #

• Эмпатия. Конкретный человек с именем, цитатами и страхами присутствует в каждой продуктовой дискуссии: «что почувствует Мария» заменяет «мне кажется, пользователи так не делают». Команда перестаёт проектировать на саму себя.
• Общий язык. Споры о «пользователе вообще» — каждый имеет в виду своего — сменяются ссылкой на общий портрет; новые участники команды входят в контекст за часы, а не недели.
• Фокус. Явные границы «кого обслуживаем» защищают бэклог от функций для воображаемой аудитории; анти-персона даёт обоснованный отказ сегментам, которые тянут продукт в разные стороны.
• Проектирование «для кого», а не «вообще». Вопрос «для какой персоны эта фича?» дисциплинирует приоритизацию и дизайн: у каждого решения появляется адресат, а значит — критерий проверки.
• Основа для CJM и VPC. Персона — обязательный вход карты пути (чей путь) и профиль клиента ценностной канвы: артефакты стратегии собираются от неё, а не от абстрактного «рынка».

Минусы и риски #

• Персона без данных — гадание. Портрет, придуманный за столом, описывает не клиента, а представления команды о клиенте, и при этом выглядит убедительно: аккуратная выдумка опаснее честного незнания, потому что уверенно направляет решения. Лечение — правило «нет интервью — нет персоны, только proto-persona с явной пометкой».
• Стереотипность. Фотостоковая улыбка, выдуманная цитата, возраст как главное поле — персона вырождается в карикатуру и дискредитирует метод: команда перестаёт ей доверять. Держать фактуру: реальные цитаты, наблюдаемое поведение, роль важнее демографии.
• Устаревание. Персона, которой два года, описывает сегмент, которого уже нет: продукт, рынок и конкуренты ушли вперёд. Портрет без даты данных и цикла обновления — протез, который никто не проверял; со временем тихо превращается в proto-persona без пометки.
• Слишком много персон → не используются. Дюжина портретов превышает рабочую память команды: «для какой персоны?» перестаёт задаваться, персоны остаются в презентации исследования. Правило 3–5 персон — не пожелание, а условие работоспособности.
• Подменяют реальные интервью. Опасный побочный эффект: раз «персона уже есть», встречаться с клиентами перестают — портрет становится прокси-клиентом, решения принимаются без свежих данных. Персона — сжатие интервью, а не их замена.
• Anti-pattern «у нас 20 персон». Предельный случай: сегментация по каждому признаку (роль × отрасль × размер × канал) плодит портреты, каждый из которых кому-то дорог. Ни один не приоритетен, разработка размазывается, команда возвращается к решениям «для всех». Лечение — жёсткий приоритет: одна первичная персона, остальные — вторичные или анти.

Краткий вывод #

User Persona и Empathy Map — парные артефакты представления клиента: персона отвечает «кто это», карта эмпатии — «что этот человек говорит, думает, делает и чувствует». Сила метода — в переводе размытого «пользователя» в конкретную фигуру с именем и цитатой: у решений появляется адресат, у споров — общий референс, у карты пути и ценностной канвы — обязательный вход. Условия качества жёсткие: персоны строятся из данных (без интервью — только честно помеченная proto-persona), их не больше 3–5 на продукт, у портрета есть дата данных и цикл обновления. Тогда персоны — не украшение исследования, а рабочий инструмент приоритизации, дизайна, маркетинга и коммуникации.

Связанные материалы #

• Customer Development (#18) — главный источник данных для персон: проблемные интервью дают фактуру для целей, болей и поведения.
• UX-исследования — дисциплина интервью, наблюдения и тестирования, на которой строятся качественные персоны и карты эмпатии.
• Jobs-to-be-Done (#19) — контрастная линза: персона отвечает «кто», JTBD — «какую работу нанимает продукт выполнять».
• Customer Journey Map (#20) — путь персоны по точкам контакта: персона обязательный вход карты, карта — развитие персоны во времени.
• Value Proposition Canvas (#22) — pains/gains карты эмпатии ложатся в профиль клиента канвы, связывающей персону с ценностным предложением. Статья готовится.
• Discovery-процесс — рамка этапов исследовательской работы: персоны и карты эмпатии — типовой артефакт этапа исследования пользователей.

Первоисточники #

• Cooper A. (1999). The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. SAMS. — первое изложение метода персон: «растягиваемый пользователь», проектирование на конкретного человека.
• Cooper A., Reimann R., Cronin D. (2014). About Face: The Essentials of Interaction Design (4th ed.). Wiley. — развёрнутое применение персон в проектировании взаимодействия: архетипы, несколько персон, связь с требованиями.
• Gray D., Brown S., Macanufo J. (2010). Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers. O’Reilly. — Empathy Map как групповая техника погружения в клиента.
• Nielsen Norman Group. Personas: Definition and Creation (nngroup.com). — сводка правил: построение персон из исследований, валидация показом клиентам, типичные ошибки применения.
• Mulder S., Yaar Z. (2006). The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web. New Riders. — систематизация способов построения: качественные, количественные и смешанные персоны.