Верифікація перед виводом

1) Що таке користувацький сценарій

Користувацький сценарій - це описаний шлях користувача до результату в конкретному контексті, з чіткими передумовами, кроками, альтернативами і критерієм «що вважається успіхом». Сценарії пов'язують «навіщо» (JTBD/мета) і «як» (UX-потік, інтерфейси, стани).

• Спільна мова між продуктом, дизайном, розробкою, даними та комплаєнсом.
• Менше різночитань у вимогах, швидше приймання.
• Явний зв'язок фіч з бізнес-ефектом і метриками.

2) Підстави сценаріїв: персони та Jobs-to-Be-Done

Персони: хто, контекст, навички, обмеження (включаючи A11y).
JTBD: «Коли [ситуація], я хочу [мотивація], щоб [очікуваний результат]».
Сегмент контексту: пристрій, мережа, локаль/мова, часовий пояс, права, обмеження середовища.

• Коли гравець намагається вивести виграш вночі з мобільного в 3G, я хочу швидко підтвердити особу без дзвінка, щоб отримати гроші до 10 хвилин.

3) Формати опису: User/Job Story, Use Case, Acceptance

3. 1 User/Job Story (шаблон)

Как <роль/персона>, я хочу <действие/результат>, чтобы <ценность>.
Контекст: <устройство, сеть, язык, права>
Ограничения: <регуляторика, лимиты, A11y>
Гипотеза ценности: <какой KPI улучшится и на сколько>

3. 2 Use Case (спрощений)

4) Карти шляху і структурування потоку

4. 1 CJM (Customer Journey Map)

Етапи: Усвідомлення → Вибір → Перша дія → Повтор → Підтримка → Утримання

Для кожного: цілі, тертя, емоції, канали, метрики (конверсія, час, NPS)

4. 2 User Flow и Story Mapping

User Flow: граф вузлів (екрани/стани) і переходів (умови/події).
Story Mapping: «хребет» (епіки/активності) × «вертикальні скибочки» (MVP → розширення).

5) Розгалуження: happy, sad, edge cases

Happy path: Мінімальний шлях до цінності.
Sad path: передбачувані помилки (валідність, ліміти, таймаути).
Edge cases: рідкісні, але дорогі: нестабільна мережа, дублікати, відміни, гонки, конфлікт станів, невідповідність локалі/часового поясу, доступність (клавіатура замість миші, скрінрідер).

Порада: на кожен ключовий крок - мінімум по одному sad і одному edge-сценарію.

6) Стани інтерфейсів (UI States)

• `loading` / `empty` / `success` / `error` / `partial` / `disabled`
• підказки та мікро-копірайтинг; доступність (ролей/aria, фокус, розміри таргетів); локаль і формат чисел/дат/валют.

7) A11y-вимоги в сценаріях

Клавіатура: всі дії досяжні без миші; видимий фокус, порядок Tab.
Скрінрідер: правильні ролі та зв'язки лейблів; альтернативи медіа.
Колір/контраст: ≥ WCAG AA; не тільки кольором.
Motion: підтримка'prefers-reduced-motion'.
Введення: формат/маски, голос/екранна клавіатура; достатні таргети 40-48 px.
Додайте в Acceptance окремі критерії A11y.

8) Аналітична розмітка і метрики успіху

Визначте події, параметри та KPI для сценарію.

8. 1 Подійна схема (приклад JSON)

json
{
"event": "withdrawal_kyc_step",
"props": {
"step": "face_capture",
"device": "mobile",
"net": "3g",
"locale": "ru-RU",
"result": "success    fail    timeout",
"duration_ms": 74200
},
"user": { "seg": "new    returning", "a11y": "sr    kb    none" }
}

8. 2 KPI і цільові пороги

Completion Rate (частка, що завершили сценарій) ≥ X%

Time-to-Value (медіана до результату) ≤ Y хвилин

Error Rate (422/429/5xx і призначені для користувача помилки) ≤ Z%

A11y Pass (сценарій тільки клавіатурою) = 100%

CSAT/NPS по кроку ≥ цільового рівня

9) Дані, міжнародні аспекти та правила

Формати: ISO-8601 (UTC) для часу, локалізований вивід для користувача.
Гроші: minor units/десяткові рядки; валюта явно.
Мови/RTL: тексти в ресурсах, підтримка дзеркалювання; довжина рядків і переноси.
Обмеження: ліміти, вік, KYC, санкції - як передумови сценаріїв.

10) Шаблон опису сценарію (YAML)

yaml id: SCN-0023-withdrawal-kyc-mobile-3g title: Верификация перед выводом (мобайл, 3G)
persona: "Игрок-новичок"
jtbd: "Когда хочу быстро вывести выигрыш ночью, пройти KYC без звонка, чтобы получить деньги за 10 минут."
context:
device: mobile network: "3g"
locale: "ru-RU"
timezone: "Europe/Kyiv"
preconditions:
- "Пользователь авторизован"
- "Баланс >= минимального порога"
- "Документы готовы"
flow:
- step: "Открыть экран вывода"
ui_state: ["loading","ready","error"]
analytics_event: "withdrawal_open"
- step: "Старт KYC"
alt: ["нет камеры -> перейти на загрузку фото", "ошибка сети -> ретрай"]
analytics_event: "kyc_start"
- step: "Съемка лица"
alt: ["недостаточно света", "таймаут", "отказ разрешений"]
analytics_event: "kyc_face_capture"
- step: "Результат и ETA"
analytics_event: "kyc_result"
acceptance:
- "KYC завершен < 2 минут в 3G"
- "Вся последовательность проходима клавиатурой; фокус не теряется"
- "Тексты локализованы; валюта и формат дат корректны"
- "Ошибки с actionable подсказкой"
metrics:
completion_rate: ">= 0.85"
ttv_median_min: "<= 10"
error_rate: "<= 0.03"
a11y:
keyboard_only: true contrast_wcag: "AA"
reduced_motion_supported: true risks:
- "Нестабильная сеть -> оффлайн режим/ретраи"
- "Ложные отказы KYC -> fallback на ручную проверку"

11) Інструменти валідації сценаріїв

Функціональні тести (Gherkin/E2E): happy/sad/edge.
A11y-аудит: ручний (NVDA/VoiceOver) + авто-лінтери.
Usability-сесії: 5-8 респондентів на ключовий сценарій.
Телеметрія: фіче-прапори, дашборди Completion/TTV/Error.
Dogfooding: внутрішньокомандні прогони по чек-листах.

12) Чек-лист сценарію (швидка перевірка)

• JTBD сформульований і зрозумілий команді
• Персона/контекст/обмеження прописані
• User Flow і Story Map готові; розгалуження позначені
• Acceptance Criteria (в т.ч. A11y) зрозумілі і тестовані
• Стани UI (loading/empty/error) задокументовані
• Аналітичні події та KPI визначені
• Локалізація/формати/валюта враховані
• Ризики/фейлові гілки і плаци для ретраїв описані
• Прототип/макап узгоджений з розробкою/даними/комплаєнсом
• План тестування та дата приймання узгоджені

13) Анти-патерни

«Сценарії = тільки happy path» (ігнор помилок/edge).
Нечитання Acceptance («зробити зручно» замість вимірюваного критерію).
Відсутність A11y і локалі у вимогах.
Змішання бізнес-цілі і UX-реалізації («додати попап» замість «знизити TTV»).
Немає подієвої схеми → нічим вимірювати успіх.

14) Приклади лаконічних User Stories

Як новий користувач, хочу зареєструватися по e-mail без підтвердження телефону, щоб почати гру відразу; якщо ліміти перевищені - показати альтернативу «гість».
Як менеджер, хочу експортувати звіт в CSV з фільтрами і таймзоною проекту, щоб звірити дані з бухгалтерією.

15) План впровадження (3 ітерації)

• Шаблони Story/Use Case/Acceptance, єдиний реєстр сценаріїв, мінімальна аналітична схема, чек-лист.

• User Flow + CJM для ключових сценаріїв, A11y-критерії, дашборди Completion/TTV/Error, E2E-набір.

• Story Mapping, пріоритизація по Impact × Effort, A/B гіпотез, регулярні рев'ю метрик і CAPA.

16) Міні-FAQ

Персони або тільки JTBD?
Використовуйте обидва: персони дають контекст і обмеження, JTBD - намір і цінність.

Чи потрібно описувати все до пікселя?
Ні, ні. Сценарій фіксує мету, кроки, розгалуження та критерії успіху; пікселі - завдання макетів і DLS.

Як зрозуміти, що сценарій «готовий»?
Є вимірювані Acceptance, покриття по happy/sad/edge, A11y-критерії, події та цільові KPI.

Підсумок

Призначені для користувача сценарії - це «скелет» продукту: ясна мета (JTBD), узгоджений потік (User Flow/Story Mapping), перевіряються критерії (Acceptance), вимірюваність (події і KPI) і повага до доступності/локалі. Зафіксуйте їх в єдиних шаблонах, автоматизуйте перевірку і регулярно переглядайте за фактичними метриками - так інтерфейси залишаться зрозумілими, швидкими і цінними для всіх користувачів.