Weryfikacja przed wycofaniem

1) Co to jest niestandardowy skrypt

Skrypt użytkownika jest opisaną przez użytkownika ścieżką do wyniku w określonym kontekście, z wyraźnymi warunkami wstępnymi, krokami, alternatywami i kryterium „co liczy się jako sukces”. Skrypty kojarzą „why” (JTBD/target) i „how” (strumień UX, interfejsy, stany).

• Wspólny język między produktem, projektem, rozwojem, danymi i zgodność.
• Mniej rozbieżności w wymaganiach, szybsza akceptacja.
• Wyraźne połączenie funkcji z efektem biznesowym i metrykami.

2) Podstawy scenariusza: osoby i miejsca pracy do wykonania

Osoby: kto, kontekst, umiejętności, ograniczenia (w tym A11y).
JTBD: „Kiedy [sytuacja], chcę [motywacji] do [oczekiwanego wyniku]”.
Segment kontekstowy: urządzenie, sieć, lokalny/język, strefa czasowa, prawa, ograniczenia środowiskowe.

• Kiedy gracz próbuje wypłacić wygrane w nocy z telefonu komórkowego w 3G, chcę szybko potwierdzić swoją tożsamość bez połączenia, aby uzyskać pieniądze do 10 minut.

3) Formaty opisu: User/Job Story, Use Case, Acceptance

3. 1 Historia użytkownika/zadania (szablon)

As a <role/person>, I want <action/result> to <value>.
Context: <device, network, language, rights>
Restrictions: <regulations, limits, A11y>
Value hypothesis: <what KPI will improve and by how much>

3. 2 Przypadek użycia (uproszczony)

4) Mapy ścieżki i strukturyzacja przepływu

4. 1 CJM (mapa podróży klienta)

Etapy: Świadomość → Wybór → Pierwsze działanie → Redo → Wsparcie → Wstrzymaj

Dla każdego: cele, tarcie, emocje, kanały, mierniki (konwersja, czas, NPS)

4. 2 Mapowanie opowieści o przepływie użytkownika

Przepływ użytkownika: wykres węzła (ekrany/stany) i przejścia (warunki/zdarzenia).
Mapowanie historii: „ridge” (epiki/działania) × „pionowe plasterki” (MVP → rozszerzenia).

5) Rozgałęzienie: szczęśliwe, smutne, krawędziowe przypadki

Szczęśliwa ścieżka: minimalna ścieżka do wartości.
Smutna ścieżka: przewidywalne błędy (ważność, limity, terminy).
Przypadki krawędzi: rzadkie, ale drogie: niestabilna sieć, duplikaty, anulowanie, wyścigi, konflikt stanu, niedopasowanie strefy lokalnej/czasowej, dostępność (klawiatura zamiast myszy, czytnik ekranu).

Wskazówka: dla każdego kroku klucza - co najmniej jeden smutny i jeden scenariusz krawędzi.

6) Państwa UI

• „załadunek ”/„ pusty ”/„ sukces ”/„ błąd ”/„ częściowy ”/„ wyłączony”
• wskazówki i mikro-copywriting; dostępność (role/aria, ostrość, rozmiary docelowe); lokalny i format numerów/dat/walut.

7) Wymogi A11y w scenariuszach

Klawiatura: wszystkie działania są osiągalne bez myszy; widoczne ostrość, zamówienie Tab.
Screensaver: odpowiednie role i połączenia etykiet; alternatywy dla mediów.
Kolor/kontrast: ≥ WCAG AA; nie tylko kolor.
Ruch: wsparcie „preferuje ograniczony ruch”.
Wejście: format/maski, klawiatura głosowa/ekranowa; wystarczające cele 40-48 px.
Dodaj indywidualne kryteria A11y do Akceptacji.

8) Markup analityczny i wskaźniki sukcesu

Zdefiniuj zdarzenia, parametry i KPI dla scenariusza.

8. 1 Program zdarzeń (przykład 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 i progi docelowe

Wskaźnik ukończenia ≥ X%

Czas do wartości ≤ minuty Y

Wskaźnik błędów (422/429/5xx i błędy użytkownika) ≤ Z%

A11y Pass = 100%

CSAT/NPS według etapu docelowego ≥

9) Dane, aspekty i zasady międzynarodowe

Formaty: ISO-8601 (UTC) dla czasu, zlokalizowane wyjście dla użytkownika.
Pieniądze: niewielkie jednostki/struny dziesiętne; waluta wyraźnie.
Języki/RTL: teksty w zasobach, wsparcie dla lustracji; długość sznurka i hiphenacja.
Ograniczenia: limity, wiek, KYC, sankcje - jako warunki wstępne scenariuszy.

10) Szablon opisu skryptu (YAML)

yaml id: SCN-0023-withdrawal-kyc-mobile-3g title: Verification before output (mobile, 3G)
persona: "Rookie Player"
jtbd: "When I want to quickly take out a win at night, pass KYC without a call to get paid in 10 minutes."
context:
device: mobile network: "3g"
locale: "ru-RU"
timezone: "Europe/Kyiv"
preconditions:
- "User Authorized"
- "Balance> = minimum threshold"
- "Documents ready"
flow:
- step: "Open output screen"
ui_state: ["loading","ready","error"]
analytics_event: "withdrawal_open"
- step: "KYC Start"
alt: ["no camera -> switch to photo upload," "network error -> retray"]
analytics_event: "kyc_start"
- step: "Face shooting"
alt: ["not enough light," "timeout," "permission denied"]
analytics_event: "kyc_face_capture"
- step: "Result and ETA"
analytics_event: "kyc_result"
acceptance:
- "KYC complete <2 minutes in 3G"
- "The entire sequence is passable by the keyboard; focus is not lost"
- "Texts are localized; Currency and date format correct"
- "Errors with actionable hint"
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:
- "Unstable network -> offline mode/retrays"
- "False failures KYC -> fallback for manual check"

11) Narzędzia do zatwierdzania scenariuszy

Testy funkcjonalne (Gherkin/E2E): happy/sad/edge.
A11y-audit: instrukcja obsługi (NVDA/VoاOver) + auto-lintery.
Sesje użyteczności: 5-8 respondentów do kluczowego scenariusza.
Telemetria: flagi funkcyjne, deski rozdzielcze Complete/TTV/Error.
Dogfooding: w zespole prowadzi lista kontrolna.

12) Lista kontrolna scenariusza (szybkie sprawdzenie)

• JTBD jest sformułowane i rozumiane przez zespół
• Osoba/kontekst/ograniczenia są wypisywane
• Mapa przepływu użytkowników i historii są gotowe; odgałęzienie oznaczone
• Kryteria akceptacji (w tym A11y) są jasne i sprawdzalne
• Udokumentowane stany interfejsu użytkownika (załadunek/pusty/błąd)
• Zdefiniowane zdarzenia analityczne i KPI
• Rozważana lokalizacja/formaty/waluta
• Opisane ryzyka/fałszywe gałęzie i przekładki
• Prototyp/Macap dostosowany do rozwoju/danych/zgodności
• Uzgodniony plan badania i data odbioru

13) Anty-wzory

„Skrypty = tylko szczęśliwa ścieżka” (ignoruj błędy/krawędź).
Nieczytelna akceptacja („uczynić to wygodnym” zamiast mierzalnego kryterium).
Brak A11y i lokalizacji w wymaganiach.
Mieszanie celów biznesowych i implementacji UX („add-up” zamiast „lower TTV”).
Nie ma programu wydarzeń → nic do pomiaru sukcesu.

14) Przykłady zwięzłych historii użytkowników

Jako nowy użytkownik, chcę zarejestrować się przez e-mail bez potwierdzenia mojego telefonu, aby rozpocząć grę od razu; jeśli limity są przekroczone - pokaż alternatywny „gość”.
Jako menedżer, chcę wyeksportować raport do CSV z filtrami i projektem timezone, aby zweryfikować dane z księgowości.

15) Plan realizacji (3 iteracje)

• Historia/Użyj Case/Akceptacja szablonów, ujednolicony rejestr scenariuszy, minimalny schemat analityczny, lista kontrolna.

• Przepływ użytkownika + CJM dla kluczowych scenariuszy, kryteria A11y, tablice rozdzielcze Complete/TTV/Error, zestaw E2E.

• Mapowanie historii, priorytety Impact × Effort, hipotezy A/B, regularne recenzje metryczne i CAPA.

16) Mini-FAQ

Osoby czy tylko JTBD?
Użyj obu: osoby dają kontekst i ograniczenia, JTBD - intencja i wartość.

Czy muszę opisać wszystko do piksela?
Nie, nie jest. Scenariusz rejestruje cel, kroki, gałęzie i kryteria sukcesu; pikseli - zadanie układów i DLS.

Jak zrozumieć, że scenariusz jest „gotowy”?
Istnieje wymierna akceptacja, szczęśliwe/smutne/krawędziowe pokrycia, kryteria A11y, zdarzenia i docelowe KPI.

Razem

Scenariusze użytkownika to „szkielet” produktu: jasny cel (JTBD), spójny przepływ (mapowanie przepływu użytkownika/historii), możliwe do zweryfikowania kryteria (akceptacja), wymierność (zdarzenia i KPI) oraz poszanowanie dostępności/lokalizacji. Naprawić je w jednolitych szablonach, zautomatyzować weryfikację i regularnie przeglądać je zgodnie z rzeczywistymi metrykami - dzięki temu interfejsy pozostaną jasne, szybkie i cenne dla wszystkich użytkowników.