Verifica prima dell'output

1) Cos'è uno script personalizzato

Uno script personalizzato è il percorso descritto dell'utente per il risultato in un contesto specifico, con chiari presupposti, passaggi, alternative e il criterio del successo. Gli script associano «perché» (JTBD/obiettivo) a «come» (flusso UX, interfacce, stati).

• Linguaggio comune tra prodotto, design, sviluppo, dati e compilazione.
• Meno variazioni di requisiti, più veloce di accettazione.
• Apparentemente connesso a effetti aziendali e metriche.

2) Le basi degli script sono personalizzate e Jobs-to-Be-Done

Individui: chi, contesto, abilità, vincoli (inclusa A11y).
JTBD: «Quando [la situazione] voglio [la motivazione] per [il risultato atteso]».
Segmento di contesto: dispositivo, rete, locale/lingua, fuso orario, diritti, limitazioni dell'ambiente.

• Quando un giocatore cerca di ritirare la vincita di notte dal cellulare in 3G, voglio rapidamente confermare l'identità senza chiamare per ottenere i soldi fino a 10 minuti.

3) Formati di descrizione: User/Job Story, Use Case, Acceptance

3. 1 User/Job Story (modello)

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

3. 2 Use Case (semplificato)

4) Mappe del percorso e strutturazione del flusso

4. 1 CJM (Customer Journey Map)

Fasi: Scelta Prima azione Ripetizione Supporto

Per ciascuno: obiettivi, attriti, emozioni, canali, metriche (conversione, tempo, NPS)

4. 2 User Flow и Story Mapping

User Flow: grafico dei nodi (schermate/stati) e delle transizioni (condizioni/eventi).
Story Mapping: spina dorsale (epici/attività) x fette verticali (MVP).

5) Rami: happy, sad, edge case

Happy path: percorso minimo per il valore.
Sad path: errori prevedibili (validità, limiti, timeout).
Edge case: rari ma costosi: rete instabile, duplicati, annullamenti, corse, conflitti di stato, non corrispondenza del fuso orario, disponibilità (tastiera, schermata).

Suggerimento: per ogni passo chiave, almeno un sad e un edge script.

6) Stati interfaccia (UI States)

• `loading` / `empty` / `success` / `error` / `partial` / `disabled`
• suggerimenti e micro-copiating disponibilità (ruoli/aria, fuoco, dimensioni target) locale e formato di numeri/date/valute.

7) Requisiti A11y negli script

Tastiera: tutte le azioni sono raggiungibili senza il mouse; Il trucco visibile, l'ordine di Taib.
Screener: corretti ruoli e legami discografici alternative ai media.
Colore/contrasto: ≥ WCAG AA; Non solo con il colore.
Motion supporta «preferers-reduced-motion».
Input: formato/maschera, voce/tastiera target sufficienti 40-48 px.
Aggiungere criteri A11y separati a Acceptance.

8) Mappatura analitica e metriche di successo

Definire eventi, parametri e KPI per lo script.

8. 1 Diagramma di eventi (esempio 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 e soglie di destinazione

Rate (percentuale che ha completato lo script) X%

Time-to-Value (mediana prima del risultato) ≤ Y minuti

Errore Rate (422/429/5xx e errori utente) ≤ Z%

A11y Pass (solo tastiera) = 100%

CSAT/NPS per passo di livello di destinazione

9) Dati, aspetti internazionali e regole

Formati ISO-8601 (UTC) per il tempo, output localizzato per l'utente.
Denaro: minor units/righe decimali; la valuta è chiara.
Lingue/RTL: testi in risorse, supporto mirroring; lunghezza delle righe e spostamenti.
Limiti: limiti, età, KYC, sanzioni - come prerequisizioni di script.

10) Modello di descrizione script (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) Strumenti di convalida degli script

Test funzionali (Gherkin/E2E): happy/sad/edge.
Controllo A11y - manuale (NVDA/VoiceOver) + linter auto.
Sessioni Usability: 5-8 intervistati per scenario chiave.
Telemetria: bandiere fiffe, dashboard Complition/TTV/Errore.
Dogfooding - Test su foglio di assegno interno al comando.

12) Assegno foglio script (verifica rapida)

• JTBD è formulato e comprensibile al comando
• Persona/contesto/vincoli specificati
• User Flow e Story Map sono pronti; rami contrassegnati
• Acceptance Criteria (A11y) è comprensibile e testabile
• Stati UI documentati
• Eventi analitici e KPI definiti
• Localizzazione/formati/valuta
• I rischi/rami di feeling e le placche per i retrai sono descritti
• Prototipo/macap coerente con lo sviluppo/dati/compilazione
• Piano di test e data di accettazione concordati

13) Anti-pattern

Script = solo happy path (ignora errori/edge).
Acceptance non leggibile («rendi comodo» invece di un criterio misurabile).
Assenza di A11y e locali nei requisiti.
Miscelazione tra obiettivo aziendale e implementazione UX («aggiungi popup» anziché «ridurre TTV»).
Non c'è uno schema di eventi che non possa misurare il successo.

14) Esempi di User Stories concisi

Come nuovo utente, vorrei registrarmi tramite e-mail senza la conferma del telefono per iniziare subito la partita; se i limiti sono stati superati, mostra l'alternativa «ospite».
Come manager, voglio esportare un rapporto in CSV con filtri e un progetto temporale per confrontare i dati con la contabilità.

15) Piano di implementazione (3 iterazioni)

• Modelli Story/Use Case/Acceptance, registro degli script unico, schema di analisi minimo, foglio di assegno.

• User Flow + CJM per gli script chiave, criteri A11y, dashboard Complection/TTV/Errore, set E2E.

• Story Mapping, priorità per Effetto x Effort, ipotesi A/B, metriche di gelosia regolari e CAPE.

16) Mini FAQ

Persone o solo JTBD?
Usate entrambi: le persone forniscono il contesto e i vincoli, JTBD l'intento e il valore.

È necessario descrivere tutto fino al pixel?
No, no. Lo scenario fissa obiettivi, passi, ramificazioni e criteri di successo; pixel: attività di layout e DLS.

Come faccio a capire che il copione è pronto?
Ci sono misure Acceptance, coperture happy/sad/edge, criteri A11y, eventi e target KPI.

Totale

Gli script personalizzati sono lo scheletro del prodotto: obiettivo chiaro (JTBD), flusso coerente (User Flow/Story Mapping), criteri di verifica (Acceptance), misurazione (eventi e KPI) e rispetto della disponibilità/locale. Fissare i modelli in un unico modello, automatizzare la verifica e rivedere regolarmente le metriche effettive, in modo che le interfacce rimangano chiare, veloci e preziose per tutti gli utenti.