Verificare înainte de retragere

1) Ce este un script personalizat

Un script de utilizator este calea descrisă de utilizator către un rezultat într-un context specific, cu condiții prealabile clare, pași, alternative și un criteriu „ceea ce contează ca succes”. Scripturile asociază „de ce” (JTBD/target) și „cum” (UX stream, interfețe, stări).

• Limbaj comun între produs, design, dezvoltare, date și conformitate.
• Mai puține discrepanțe în ceea ce privește cerințele, acceptarea mai rapidă.
• Conectarea explicită a caracteristicilor cu efect de afaceri și valori.

2) Motive de scenariu: persoane și locuri de muncă de făcut

Persoane: care, context, abilități, limitări (inclusiv A11y).
JTBD: „Când [situația], vreau [motivație] la [rezultatul așteptat]”.
Segmentul contextual: dispozitiv, rețea, local/limbă, fus orar, drepturi, restricții de mediu.

• Când un jucător încearcă să retragă câștigurile pe timp de noapte de pe un mobil în 3G, vreau să-mi confirm rapid identitatea fără un apel pentru a obține bani până la 10 minute.

3) Formate de descriere: User/Job Story, Utilizare Case, Acceptare

3. 1 User/Job Story (șablon)

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

3. 2 Cutie de utilizare (simplificată)

4) Hărți de traseu și structurarea fluxului

4. 1 CJM (Harta călătoriilor clienților)

Etape: Conștientizare selecție prima acțiune Redo Suport Hold

Pentru fiecare: obiective, frecare, emoții, canale, valori (conversie, timp, NPS)

4. 2 User Flow и Story Mapping

Fluxul utilizatorului: nodul (ecrane/stări) și graficul de tranziție (condiții/evenimente).
Cartografiere poveste: „creastă” (epics/activities) × „felii verticale” (extensii → MVP).

5) Ramificare: cazuri fericite, triste, de margine

Calea fericită: o cale minimă către valoare.
Cale tristă: erori previzibile (valabilitate, limite, termene).
Cazuri de margine: rare, dar costisitoare: rețea instabilă, duplicate, anulări, curse, conflict de stat, neconcordanță locală/fus orar, disponibilitate (tastatură în loc de mouse, cititor de ecran).

Sfat: pentru fiecare pas cheie - cel puțin un scenariu trist și o margine.

6) UI State

• „încărcare ”/„ gol ”/„ succes ”/„ eroare ”/„ parțială ”/„ dezactivat”
• sugestii și micro-copywriting; accesibilitate (roluri/arie, focalizare, dimensiuni țintă); locale și formatul numerelor/datelor/valutelor.

7) cerințe de A11y în scenarii

Tastatură: toate acțiunile sunt realizabile fără un mouse; focalizare vizibilă, comandă tab.
Screensaver: roluri și conexiuni adecvate de etichetare; alternative media.
Culoare/contrast: ≥ WCAG AA; nu doar de culoare.
Motion: „preferă-redusă-mișcare” sprijin.
Intrare: format/măști, tastatură vocală/pe ecran; suficiente obiective 40-48 px.
Adăugați criterii individuale de A11y la Acceptare.

8) Indicarea analitică și măsurarea succesului

Definiți evenimentele, parametrii și KPI-urile pentru scenariu.

8. 1 Schema de evenimente (exemplu 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-uri și praguri țintă

Rata de finalizare ≥ X%

Timp-la-valoare ≤ minute Y

Rata de eroare (422/429/5xx și erorile utilizatorului) ≤ Z%

A11y Pass = 100%

CSAT/NPS by Target Pasul ≥

9) Date, aspecte și reguli internaționale

Formate: ISO-8601 (UTC) pentru timp, ieșire localizată pentru utilizator.
Bani: unități minore/șiruri zecimale; valută explicit.
Limbi străine/RTL: texte în resurse, suport pentru oglindire; lungimea șirului și cratima.
Restricții: limite, vârstă, KYC, sancțiuni - ca condiții prealabile pentru scenarii.

10) Script Descriere șablon (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) Instrumente de validare a scenariilor

Teste funcționale (Gherkin/E2E): fericit/trist/margine.
A11y-audit: manual (NVDA/VoiceOver) + auto-lintere.
Sesiuni de utilizare: 5-8 respondenți la scenariul cheie.
Telemetrie: feature flags, Completare/TTV/Eroare tablouri de bord.
Dogfooding: lista de verificare în echipă rulează.

12) Lista de verificare a scenariului (verificare rapidă)

• JTBD este formulată și înțeleasă de echipă
• Persoana/contextul/restricțiile sunt specificate
• Utilizatorul Flow și Story Map sunt gata; ramificare marcată
• Criteriile de acceptare (inclusiv A11y) sunt clare și testabile
• UI state (încărcare/gol/eroare) documentate
• Evenimente analitice și KPI definite
• Localizare/formate/monedă luate în considerare
• Riscuri/ramuri false și tampoane retray descrise
• Prototip/Macap aliniat la dezvoltare/date/conformitate
• Planul de încercare și data acceptării convenite

13) Anti-modele

„Scripts = happy path only” (ignoră erorile/muchie).
Acceptare imposibil de citit („face convenabil” în loc de un criteriu măsurabil).
Lipsa A11y și a cerințelor locale.
Amestecarea scopului de afaceri și implementarea UX („adăugați pop-up” în loc de „TTV inferior”).
Nu există nici o schemă de evenimente → nimic pentru a măsura succesul.

14) Exemple de povești concise ale utilizatorilor

Ca utilizator nou, vreau să mă înregistrez prin e-mail fără a confirma telefonul meu pentru a începe jocul imediat; dacă limitele sunt depășite - arată alternativa „oaspete”.
Ca manager, vreau să export raportul în CSV cu filtre și fusul orar al proiectului pentru a verifica datele cu contabilitate.

15) Planul de implementare (3 iterații)

• Story/Use Case/Acceptance template-uri, registru de scenarii unificate, schema analitică minimă, lista de verificare.

• Utilizator Flow + CJM pentru scenarii cheie, criterii de A11y, Completare/TTV/tablouri de bord eroare, set de E2E.

• Story Mapping, Impact × prioritizarea efortului, ipoteze A/B, recenzii metrice regulate și CAPA.

16) Mini-Întrebări frecvente

Persoane sau numai JTBD?
Utilizați ambele: persoanele dau context și limitări, JTBD - intenție și valoare.

Trebuie să descriu totul până la pixel?
Nu, nu este. Scriptul surprinde scopul, pașii, ramurile și criteriile de succes; pixeli - sarcina de machete și DLS.

Cum să înțelegeți că scenariul este „gata”?
Există acceptare măsurabilă, acoperiri fericite/triste/de margine, criterii de A11y, evenimente și KPI-uri țintă.

Rezultat

Scenariile utilizatorilor sunt „scheletul” unui produs: scop clar (JTBD), flux consistent (User Flow/Story Mapping), criterii verificabile (Acceptare), măsurabilitate (evenimente și KPI) și respect pentru accesibilitate/localizare. Fixați-le în șabloane uniforme, automatizați verificarea și revizuiți-le în mod regulat în funcție de valorile reale - în acest fel interfețele vor rămâne clare, rapide și valoroase pentru toți utilizatorii.