Как создать персоны пользователей: практическое руководство с AI-промптами

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

На какой вопрос отвечает построение персон?

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

Когда использовать

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

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

Что вы получите

3-6 документов персон: имя, фото, демографический контекст, цели, болевые точки, поведение, характерная цитата, сценарий типичного взаимодействия с продуктом
Матрица приоритетов: какие персоны основные (проектируем для них), второстепенные (учитываем) и исключённые (не проектируем для них)
Общий словарь: имена персон как шорткаты в обсуждениях, ревью дизайна и документации
Критерии скрининга для будущих юзабилити-тестов, основанные на атрибутах персон
Принципы дизайна, привязанные к потребностям конкретных персон

Участники и сроки

Входные данные: Персоны требуют предварительного качественного исследования — обычно 5-30 пользовательских интервью, наблюдения в полевых условиях или ответы на опросы. Это исследование может уже существовать; построение персон синтезирует его.

Участники воркшопа: 3-8 человек из команды (дизайнеры, продакт-менеджеры, исследователи, разработчики). Включение не-исследователей формирует принятие результата.

Длительность воркшопа: 2-4 часа для прото-персон (на основе допущений), 1-2 дня для качественных персон (синтез на основе исследования), 2-4 недели для статистических персон (опрос + кластерный анализ).

Общий срок: Если исследование есть: 3-5 дней (синтез + черновики + ревью). Если исследование нужно проводить: 3-6 недель (фаза исследования + синтез + оформление).

Как построить персоны (пошагово)

1. Соберите и изучите существующие данные

Соберите все доступные данные о пользователях: транскрипты интервью, результаты опросов, аналитические сегменты, тикеты поддержки, заметки из звонков отдела продаж. Если предыдущего исследования нет, проведите 5-15 интервью перед созданием персон — без реальных данных персоны становятся хранилищем непроверенных допущений команды. Организуйте данные так, чтобы ответы отдельных пользователей можно было сравнивать по одним и тем же темам.

2. Определите поведенческие паттерны и переменные

Прочитайте данные, выявляя поведенческие различия, значимые для вашего продукта. Это измерения, по которым пользователи варьируются: частота использования, техническая уверенность, мотивация покупки, процесс принятия решений, основная цель при использовании продукта. Составьте список из 5-8 ключевых поведенческих переменных. Избегайте демографических измерений (возраст, пол, местоположение), если они не связаны напрямую с разными потребностями в продукте.

3. Кластеризуйте пользователей в группы

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

4. Напишите черновики персон

Для каждого кластера создайте одностраничную персону. Включите:

Имя и фото: Реалистичное имя и стоковая фотография, соответствующая профилю. Имя делает персону запоминающейся; фото вызывает узнавание на встречах.
Краткое описание: «Менеджер по маркетингу в среднем SaaS, которому нужно доказывать ROI финансовому директору каждый квартал.»
Демография: Только релевантные атрибуты — роль, уровень опыта, техническая грамотность, индустрия.
Цели: Что они пытаются достичь, краткосрочно и долгосрочно.
Болевые точки: Что фрустрирует в текущем подходе или существующем продукте.
Поведение: Как сейчас решают задачу, которую адресует продукт. Какие инструменты, обходные пути, привычки.
Цитата: Реальная или составная цитата из исследования, передающая установку персоны одним предложением.
Сценарий: Краткий нарратив (3-5 предложений), показывающий персону в реалистичной ситуации использования продукта.

5. Расставьте приоритеты

Не все персоны равноценны для дизайн-решений. Обозначьте каждую как:

Основная: Персона, для которой проектируете в первую очередь. Её потребности определяют ядро опыта.
Второстепенная: Важно учитывать, но её крайние случаи не должны компрометировать основной опыт.
Исключённая: Персона, для которой вы осознанно не проектируете, чтобы предотвратить разрастание scope.

Задокументируйте обоснование приоритетов и согласуйте со стейкхолдерами.

6. Валидируйте с командой и стейкхолдерами

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

7. Распространите и интегрируйте в рабочие процессы

Распечатайте персоны, разместите в командном пространстве, добавьте в документацию дизайн-системы, ссылайтесь на них в user stories и тикетах. Персона, живущая только на странице Confluence, которую никто не читает — напрасный труд. Включите имена персон в чек-листы дизайн-ревью: «Мы подумали, как Персона X воспримет этот флоу?» Установите напоминание о пересмотре персон каждые 6-12 месяцев.

Как AI меняет этот метод

AI-совместимость: partial — AI ускоряет несколько шагов построения персон, особенно синтез данных и написание черновиков, но критическое мышление, определяющее, какие поведенческие паттерны важны и как группировать пользователей в осмысленные кластеры, требует человеческого суждения. Риск полностью AI-сгенерированных персон в том, что они отражают обучающие данные LLM, а не ваших реальных пользователей.

Что может AI

Синтез исследовательских данных: LLM обрабатывает транскрипты интервью и извлекает повторяющиеся темы, цели, болевые точки и поведенческие паттерны — создавая предварительную тематическую карту за минуты вместо часов.
Определение поведенческих переменных: После обзора кодированных данных AI предлагает кандидатные измерения для кластеризации, которые исследователь затем оценивает и отбирает.
Генерация черновика персоны: Получив набор поведенческих кластеров с цитатами и данными, LLM создаёт полный документ персоны в стандартном формате, который исследователь редактирует.
Написание сценариев: AI создаёт реалистичные сценарии использования для каждой персоны, экономя 30-60 минут на персону.
Проверка согласованности: LLM проверяет набор персон и отмечает пересечения, пробелы и внутренние противоречия.

Что требует человека-исследователя

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

AI-усиленный рабочий процесс

Традиционный процесс построения персон предполагает, что исследователь проводит 2-3 дня за обзором транскриптов, кодированием данных, выявлением паттернов и написанием документов. С AI-поддержкой фаза синтеза значительно сжимается. LLM обрабатывает 10-15 транскриптов интервью за минуты и создаёт предварительную тематическую карту с кандидатными поведенческими переменными. Исследователь затем проверяет и корректирует этот результат вместо того, чтобы строить его с нуля — сдвиг от генерации к курированию, экономящий 40-60% времени анализа.

Фаза написания черновиков выигрывает аналогично. Вместо создания каждого документа персоны с чистого листа исследователь передаёт валидированные кластеры в LLM со стандартным шаблоном и получает полные черновики, требующие редактирования, а не написания. Для типичного набора из 4 персон это экономит примерно полный рабочий день.

Где AI вносит риск — в самом шаге кластеризации. Если исследователь передаёт кластеризацию LLM без проверки логики, персоны могут отражать статистические паттерны в тексте (наиболее частотные слова), а не значимые поведенческие различия. Исследователь должен оставаться архитектором сегментации, используя AI как ассистента, который быстрее находит доказательства, а не как того, кто решает, кем являются пользователи.

Ошибки начинающих

1. Создание персон без исследования

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

2. Добавление нерелевантных деталей

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

3. Слишком много персон

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

4. Обращение с персонами как с постоянными артефактами

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

5. Подмена поведенческих персон демографическими сегментами

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

Инструменты

Исследование и сбор данных: Dovetail (репозиторий исследований, тегирование, кодирование), Notion (заметки интервью), Google Sheets (карта поведенческих переменных)
Воркшоп и совместная работа: Miro (шаблоны персон, упражнения на кластеризацию), FigJam (совместная доска), MURAL
Создание персон и шаблоны: UXPressia (специализированный инструмент с шаблонами), Xtensio (шаблоны с шерингом), Smaply (персоны + карты путешествий)
AI-ассистированный анализ: Speak AI (извлечение тем из транскриптов), MindCoder (качественное кодирование), ChatGPT/Claude (синтез и написание черновиков)
Интеграция в дизайн-систему: Figma (карточки персон как компоненты), Confluence (вики для живых документов персон)

Пример из практики

B2B-инструмент управления проектами проигрывал корпоративные сделки конкурентам, несмотря на хорошие отзывы от индивидуальных пользователей. Продуктовая команда провела 12 интервью по трём типам аккаунтов: малые команды на бесплатном плане, средний бизнес на профессиональном плане и корпоративные проспекты, оценившие продукт, но не купившие.

Работа с персонами выявила три отдельных пользователя внутри корпоративных аккаунтов. Персона «Тимлид» заботилась о ежедневной видимости задач и скорости — тех же потребностях, которые продукт уже хорошо удовлетворял. Персона «Вице-президент по операциям» нуждалась в отчётности на уровне портфолио и виджетах распределения ресурсов, которых в продукте не было вовсе. Персона «ИТ-ревьюер безопасности» требовала SSO, аудит-логов и гарантий хранения данных перед одобрением любого инструмента. Продукт был спроектирован для Тимлида, но решение о покупке в корпоративных аккаунтах принимал Вице-президент и блокировал ИТ-безопасность.

Команда использовала приоритизацию персон для перестройки роадмапа: корпоративная отчётность и SSO стали двумя главными приоритетами. За два квартала конверсия корпоративных сделок выросла на 35%, напрямую связанная с функциями, построенными для персон Вице-президента и ИТ-безопасности, которые ранее были невидимы продуктовой команде.