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)

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 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: 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) 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 i controlli e rivedere regolarmente le metriche effettive, in modo che le interfacce rimangano chiare, veloci e preziose per tutti gli utenti.