Vérification avant la sortie

1) Qu'est-ce qu'un script personnalisé

Un script utilisateur est le chemin décrit par l'utilisateur vers un résultat dans un contexte particulier, avec des conditions préalables, des étapes, des alternatives et un critère « ce qui est considéré comme un succès ». Les scripts lient « pourquoi » (JTBD/cible) et « comment » (flux UX, interfaces, états).

• Un langage commun entre le produit, la conception, le développement, les données et la conformité.
• Moins de différences dans les exigences, plus rapide à accepter.
• Un lien évident entre la fiction et l'effet d'entreprise et les métriques.

2) Bases de scénarios : Personnes et Jobs-to-Be-Done

Personnes : qui, le contexte, les compétences, les limites (y compris A11y).
JTBD : « Quand [la situation], je veux [la motivation] pour [le résultat attendu] ».
Segment de contexte : périphérique, réseau, local/langue, fuseau horaire, droits, restrictions d'environnement.

• Quand un joueur essaie de retirer un gain la nuit d'un mobile en 3G, je veux rapidement confirmer mon identité sans appel pour obtenir de l'argent jusqu'à 10 minutes.

3) Formats de description : User/Job Story, Cas d'utilisation, Acceptation

3. 1 User/Job Story (modèle)

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 Cas d'utilisation (simplifié)

4) Cartes de chemin et structuration du flux

4. 1 CJM (Customer Journey Map)

Étapes : Prise de conscience → Sélection → Première action → Répétition → Support → Rétention

Pour chacun : cibles, frictions, émotions, canaux, métriques (conversion, temps, NPS)

4. 2 User Flow и Story Mapping

User Flow : graphique des nœuds (écrans/états) et des transitions (conditions/événements).
Story Mapping : « crête » (épiques/activités) × « tranches verticales » (MVP → extensions).

5) Branches : happy, sad, edge cases

Happy path : chemin minimum vers la valeur.
Sad path : erreurs prévisibles (validation, limites, délais).
Edge cases : rare mais onéreux : réseau instable, doublons, annulations, courses, conflit d'états, décalage local/fuseau horaire, disponibilité (clavier au lieu de la souris, lecteur d'écran).

Conseil : pour chaque étape clé - au moins un script sad et un script edge.

6) États des interfaces (états UI)

• `loading` / `empty` / `success` / `error` / `partial` / `disabled`
• conseils et micro-rédaction ; accessibilité (rôles/aria, focus, tailles de ciblage) ; local et format des nombres/dates/monnaies.

7) Exigences A11y dans les scénarios

Clavier : toutes les actions sont réalisables sans souris ; Focus visible, ordre de Tabulation.
Lecteur d'écran : rôles et liens corrects des labels ; alternatives aux médias.
Couleur/contraste : ≥ WCAG AA ; pas seulement la couleur.
Motion : support de 'prefers-reduced-motion'.
Entrée : format/masque, voix/clavier d'écran ; targets suffisants 40-48 px.
Ajoutez des critères de A11y distincts à l'acceptation.

8) Marquages analytiques et métriques de succès

Définissez les événements, les paramètres et les KPI du scénario.

8. 1 Schéma des événements (exemple 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 et seuils cibles

Taux de complétion (proportion ayant terminé le script) ≥ X %

Time-to-Value (médiane avant le résultat) ≤ Y minutes

Taux d'erreur (422/429/5xx et erreurs personnalisées) ≤ Z %

A11y Pass (script clavier uniquement) = 100 %

CSAT/NPS par étape de niveau cible ≥

9) Données, aspects internationaux et règles

Formats : ISO-8601 (UTC) pour le temps, sortie localisée pour l'utilisateur.
Argent : unités mineures/lignes décimales ; la monnaie est clairement.
Langues/RTL : textes dans les ressources, support de la mise en miroir ; longueur des lignes et des translations.
Restrictions : limites, âge, KYC, sanctions - comme condition préalable aux scénarios.

10) Modèle de description de scénario (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) Outils de validation de scénarios

Tests fonctionnels (Gherkin/E2E) : happy/sad/edge.
A11y-audit : manuel (NVDA/VoiceOver) + auto-linters.
Séances d'utilisation : 5 à 8 répondants au scénario clé.
Télémétrie : ficelles, dashboards Completion/TTV/Error.
Dogfooding : des courses intra-équipe sur les checklists.

12) Chèque script (vérification rapide)

• JTBD est formulé et compris par l'équipe
• Persona/contexte/restrictions prescrites
• User Flow et Story Map sont prêts ; les branches sont marquées
• Acceptance Critique (y compris les A11y) sont compréhensibles et testables
• États UI (loading/empty/error) documentés
• Evénements analytiques et KPI définis
• Localisation/formats/devises comptabilisés
• Les risques/branches de feutre et les plaques de retraite sont décrits
• Prototype/macap harmonisé avec développement/données/conformité
• Le plan d'essai et la date d'acceptation sont convenus

13) Anti-modèles

Scripts = happy path uniquement (ignorer les erreurs/edge).
L'acceptation illisible (« faire pratique » au lieu d'un critère mesurable).
L'absence de A11y et de localisation dans les exigences.
Mélange de l'objectif commercial et de l'implémentation UX (« ajouter du pop » au lieu de « réduire la TVN »).
Il n'y a pas de schéma d'événement → rien pour mesurer le succès.

14) Exemples d'histoires d'utilisateurs concises

En tant que nouvel utilisateur, je veux m'inscrire par e-mail sans confirmation de téléphone pour commencer le jeu immédiatement ; si les limites sont dépassées, montrer une alternative à « invité ».
En tant que gestionnaire, je veux exporter le rapport au CSV avec les filtres et le projet de temporisation pour vérifier les données avec la comptabilité.

15) Plan de mise en oeuvre (3 itérations)

• Modèles Story/Use Case/Acceptation, registre de script unique, schéma d'analyse minimum, chèque.

• User Flow + CJM pour les scénarios clés, critères A11y, dashboards Completion/TTV/Error, E2E.

• Story Mapping, priorité par Impact × Effort, hypothèses A/B, métriques de rhumatisme régulières et CAPA.

16) Mini-FAQ

Personnes ou seulement JTBD ?
Utilisez les deux : les personnes donnent le contexte et les limites, la JTBD - l'intention et la valeur.

Dois-je tout décrire jusqu'au pixel ?
Non. Le scénario fixe l'objectif, les étapes, les branches et les critères de succès ; pixels est un problème de mise en page et DLS.

Comment comprendre que le scénario est « prêt » ?
Il existe des acceptations mesurables, des revêtements par happy/sad/edge, des critères A11y, des événements et des KPI cibles.

Résultat

Les scripts personnalisés sont le « squelette » du produit : objectif clair (JTBD), flux cohérent (User Flow/Story Mapping), critères vérifiables (Acceptation), mesurabilité (événements et KPI) et respect de la disponibilité/localisation. Enregistrez-les dans des modèles uniques, automatisez la vérification et révisez-les régulièrement sur des mesures réelles, de sorte que les interfaces restent compréhensibles, rapides et précieuses pour tous les utilisateurs.