Verification before withdrawal

1) What is a custom script

A user script is a user's described path to a result in a specific context, with clear prerequisites, steps, alternatives, and a "what counts as success" criterion. Scripts associate "why" (JTBD/target) and "how" (UX stream, interfaces, states).

• Common language between product, design, development, data and compliance.
• Less discrepancies in requirements, faster acceptance.
• Explicit connection of features with business effect and metrics.

2) Scenario Grounds: Persons and Jobs-to-Be-Done

Persons: who, context, skills, limitations (including A11y).

JTBD: "When [the situation], I want [motivation] to [the expected result]."

Context segment: device, network, local/language, time zone, rights, environment restrictions.

• When a player tries to withdraw winnings at night from a mobile in 3G, I want to quickly confirm my identity without a call in order to get money up to 10 minutes.

3) Description formats: User/Job Story, Use Case, Acceptance

3. 1 User/Job Story (template)

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

3. 2 Use Case (Simplified)

4) Path maps and flow structuring

4. 1 CJM (Customer Journey Map)

Stages: Awareness → Selection → First Action → Redo → Support → Hold

For each: goals, friction, emotions, channels, metrics (conversion, time, NPS)

4. 2 User Flow и Story Mapping

User Flow: node (screens/states) and transition (conditions/events) graph.
Story Mapping: "ridge" (epics/activities) × "vertical slices" (MVP → extensions).

5) Branching: happy, sad, edge cases

Happy path: a minimal path to value.
Sad path: predictable errors (validity, limits, timeouts).
Edge cases: rare but expensive: unstable network, duplicates, cancellations, races, state conflict, locale/time zone mismatch, availability (keyboard instead of mouse, screen reader).

Tip: for each key step - at least one sad and one edge scenario.

6) UI States

• `loading` / `empty` / `success` / `error` / `partial` / `disabled`
• hints and micro-copywriting; accessibility (roles/aria, focus, target sizes); locale and format of numbers/dates/currencies.

7) A11y requirements in scenarios

Keyboard: all actions are achievable without a mouse; visible focus, Tab order.
Screensaver: proper label roles and connections; media alternatives.
Color/contrast: ≥ WCAG AA; not just color.
Motion: 'prefers-reduced-motion' support.
Input: format/masks, voice/on-screen keyboard; sufficient 40-48 px targets.
Add individual A11y criteria to Acceptance.

8) Analytical markup and success metrics

Define the events, parameters, and KPIs for the scenario.

8. 1 Event scheme (JSON example)

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 KPIs and target thresholds

Completion Rate ≥ X%

Time-to-Value ≤ Y minutes

Error Rate (422/429/5xx and user errors) ≤ Z%

A11y Pass = 100%

CSAT/NPS by Target Step ≥

9) Data, international aspects and rules

Formats: ISO-8601 (UTC) for time, localized output for user.
Money: minor units/decimal strings; currency explicitly.
Languages ​ ​/RTL: texts in resources, support for mirroring; string length and hyphenation.
Restrictions: limits, age, KYC, sanctions - as preconditions for scenarios.

10) Script Description Template (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) Scenario Validation Tools

Functional tests (Gherkin/E2E): happy/sad/edge.
A11y-audit: manual (NVDA/VoiceOver) + auto-linters.
Usability sessions: 5-8 respondents to the key scenario.
Telemetry: feature flags, Completion/TTV/Error dashboards.
Dogfooding: in-team checklist runs.

12) Scenario checklist (quick check)

• JTBD is formulated and understood by the team
• Person/context/restrictions are spelled out
• User Flow and Story Map are ready; branching marked
• Acceptance Criteria (including A11y) are clear and testable
• UI states (loading/empty/error) documented
• Analytical events and KPIs defined
• Localization/formats/currency considered
• Risks/fake branches and retray pads described
• Prototype/Macap aligned with development/data/compliance
• Test plan and acceptance date agreed

13) Anti-patterns

"Scripts = happy path only" (ignore errors/edge).
Unreadable Acceptance ("make it convenient" instead of a measurable criterion).
Lack of A11y and locale in requirements.
Mixing business purpose and UX implementation ("add popup" instead of "lower TTV").
There is no event scheme → nothing to measure success.

14) Examples of concise User Stories

As a new user, I want to register by e-mail without confirming my phone to start the game right away; if the limits are exceeded - show the alternative "guest."

As a manager, I want to export the report to CSV with filters and project timezone in order to verify the data with accounting.

15) Implementation plan (3 iterations)

• Story/Use Case/Acceptance templates, unified scenario register, minimum analytical scheme, checklist.

• User Flow + CJM for key scenarios, A11y criteria, Completion/TTV/Error dashboards, E2E set.

• Story Mapping, Impact × Effort prioritization, A/B hypotheses, regular metric reviews, and CAPAs.

16) Mini-FAQ

Persons or only JTBD?
Use both: persons give context and limitations, JTBD - intent and value.

Do I need to describe everything up to the pixel?
No, it isn't. The script captures the goal, steps, branches, and success criteria; pixels - the task of layouts and DLS.

How to understand that the script is "ready"?
There are measurable Acceptance, happy/sad/edge coverages, A11y criteria, events and target KPIs.

Result

User scenarios are the "skeleton" of a product: clear purpose (JTBD), consistent flow (User Flow/Story Mapping), verifiable criteria (Acceptance), measurability (events and KPIs), and respect for accessibility/locale. Fix them in uniform templates, automate verification and regularly review them according to actual metrics - this way the interfaces will remain clear, fast and valuable for all users.