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)

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

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: Верификация перед выводом (мобайл, 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) 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.

Wynik

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.