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)

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

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

Total

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.