Коротко і за завданням

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) Підсумок

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