Кратко и по задаче

1) Зачем это нужно

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

2) Базовые определения

UX-персона — проверенный данными портрет сегмента пользователей с целями, привычками, триггерами и барьерами.
Анти-персона — кому продукт не предназначен (важно для отсечения конфликтных требований).
Сценарий — описание того, как персона достигает цели в конкретном контексте (основной поток + альтернативы + обработка ошибок).
Job Story (JTBD-формат): «Когда [ситуация], хочу [мотивация], чтобы [ожидаемый исход]».
Сценарии “as-is / to-be” — текущий и целевой путь.

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

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

4) Процесс: от данных к сценариям (8 шагов)

1. Сбор данных: качественные интервью, контекстные наблюдения, анализ логов/кликов, поиск паттернов ошибок, тикеты поддержки.
2. Кластеризация поведения: группируем по задачам, частоте, рискам, устройствам, каналам.
3. Черновики персон: для каждого кластера — цели, триггеры, барьеры, ограничения (доступность/правила/устройства).
4. Анти-персоны: фиксируем, кого не обслуживаем и почему.
5. Приоритизация персон: по влиянию на метрики (конверсия, retention, LTV, cost-to-serve).
6. Карта задач (Jobs): для топ-персон формулируем job stories; выявляем критичные состояния (ошибки сети, верификация, лимиты).
7. Сценарии “as-is / to-be”: основной поток + ветвления + крайние случаи; визуализируем CJM/Blueprint.
8. Валидация и метрики: прототипы, юзабилити-тесты, A/B, телеметрия по сценариям, обновление персон.

5) Шаблон UX-персоны (копируйте в вашу wiki)

Идентификатор & цитата: «Как можно быстрее решить [задачу], не тратя время на [барьер].»

Цели: (3–5 кратких формулировок)

Контекст: устройства, каналы, ограничения (время, внимание, среда)

Триггеры/мотивации: что запускает поведение

Барьеры/риски: что мешает (процедуры, непонятные термины, ошибки)

Поведенческие признаки: частота, характер сессий, предпочтения навигации

Информационные потребности: что нужно видеть/понимать, чтобы двигаться дальше

Доступность: требования по шрифтам, контрасту, локали, языку

KPI персона-фита: какие продуктовые метрики улучшаются, когда мы ей помогаем

Не является: (границы ожиданий; mini анти-персона)

• Идентификатор: «Мобильный спринтер»
• Цели: быстро завершать ключевую операцию в 1–2 минуты между делами
• Контекст: смартфон, нестабильная сеть, часто одной рукой
• Барьеры: длинные формы, скрытые требования, внезапные редиректы
• KPI: time-to-complete, error rate на мобильном, CR первого шага

6) Шаблон сценария (as-is / to-be)

7) Визуальные артефакты, которые ускоряют согласование

Empathy Map: «Говорит/Думает/Делает/Чувствует» — быстро выделяет триггеры.
CJM (Customer Journey Map): стадии × эмоции × точки контакта × боли × возможности.
Service Blueprint: фронт-стейдж/бэк-стейдж/поддерживающие процессы; показывает, где “рвется” сценарий.
User Flow/State Diagram: переходы экрана-к-экрану, состояния загрузки/ошибок.
Storyboard: 6–8 кадров на ключевой сценарий (особенно полезно для мобильных контекстов).

8) Метрики качества персон и сценариев

Покрытие: доля трафика/выручки, описанная top-N персонами и их сценариями.
Task Success Rate: % пользователей, дошедших до целевого шага для каждой персоны.
Time on Task / TTV: время выполнения; время до ценности.
Error Rate/Recovery: частота ошибок и доля авто-восстановлений.
CR по веткам: конверсия основного потока vs альтернатив.
SUS/CSAT по сегментам: восприятие удобства именно целевыми персонами.
Cost-to-Serve: снижение обращений в поддержку по сценариям.
A/B uplift: эффект внедрения «to-be» на целевые метрики.

9) Типичные ошибки

Фиктивные “маркетинговые аватары”. Персоны без поведенческих данных уводят дизайн в сторону вкусов.
Слияние крайних случаев в основной поток. Редкий кейс ломает всем остальным путь.
Игнорирование ошибок и пустых состояний. Нет «лестниц спасения» — высокие отказы.
Универсальный тон/паттерн для всех. Разным персонам — разная глубина подсказок и контроль шагов.
Редкие апдейты. Персоны «стареют» — обновляйте по данным как минимум ежеквартально или при крупных релизах.

10) Практикум: воркшоп на 90 минут

1. 10 мин: цель и метрики (какой сценарий улучшаем, какие KPI целим).
2. 20 мин: разметка данных/инсайтов → 2–3 черновые персоны + 1 анти-персона.
3. 20 мин: формулируем 3–5 job stories для топ-персоны.
4. 25 мин: рисуем «as-is» и «to-be» поток (основной + 2 альтернативы + 2 ошибки).
5. 15 мин: определяем события аналитики/телеметрии, пустые/ошибочные состояния, A/B-гипотезы.

11) Чек-лист внедрения

• Есть данные (качественные + количественные) и источники их обновления
• Для каждой ключевой метрики есть связанная персона и сценарий
• Описаны альтернативы, ошибки, пустые состояния, офлайн/медленная сеть
• Есть план тестирования: прототипы, сценарные юзабилити-сессии, A/B
• Схема событий аналитики покрывает шаги и ветки сценария
• Регулярный цикл ревизии персон (например, раз в квартал)

12) Мини-пример связывания (упрощенно)

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

1. Экран «Шаги процесса» с прогресс-баром и оценочным временем.

2. Формы с валидацией «на лету», понятными примерами.

3. Пустые/ошибочные состояния имеют явную помощь и безопасный возврат.

4. Телеметрия: `start`, `field_error`, `help_opened`, `retry`, `complete`.

5. Метрики: TTF ≤ 90 сек, Error Rate < 3%, CSAT ≥ 4.2 у сегмента.

13) Форматы для вашей wiki (быстрые вставки)

[Person ID]
Quote:... ""
Goals:...
Context:...
Triggers/motivations:...
Barriers/risks:...
Behavioral signs:...
Information needs:...
Availability:...
KPI person-fit:...
Not:...

Scenario: [Title]
Persona:...
Context:...
Background:...
Trigger:...
Main flow:
1) …
2) …
Alternatives: A1 .../A2...
Errors/Exceptions:...
Data and privacy:...
Time and states:...
Success metrics:...
Artifacts:...

14) Роли и ответственность

Продукт-менеджер: цели, метрики, приоритизация персон/сценариев.
UX/Research: данные, формализация персон, тестирование сценариев.
UI/Content: визуальная иерархия, копирайтинг подсказок/ошибок.
Инженерия: состояния, надежность, телеметрия, доступность.
Риск/Комплаенс/Саппорт: правила, edge cases, база макросов помощи.

15) Итог

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