Verificación antes de la salida

1) Qué es un script personalizado

El script de usuario es el camino descrito por el usuario hacia el resultado en un contexto específico, con premisas claras, pasos, alternativas y el criterio de «lo que se considera un éxito». Los scripts enlazan «por qué» (JTBD/objetivo) y «cómo» (flujo UX, interfaces, estados).

• Un lenguaje común entre producto, diseño, desarrollo, datos y cumplimiento.
• Menos discrepancias en los requisitos, aceptación más rápida.
• Una clara relación entre el fich y el efecto de negocio y las métricas.

2) Bases de los escenarios: personas y Jobs-to-Be-Done

Personas: quién, contexto, habilidades, limitaciones (incluyendo A11y).
JTBD: «Cuando [la situación], quiero [la motivación] para [el resultado esperado]».
Segmento de contexto: dispositivo, red, local/idioma, zona horaria, derechos, restricciones de entorno.

• Cuando el jugador intenta retirar las ganancias por la noche desde el móvil en 3G, quiero confirmar rápidamente la identidad sin llamar para obtener el dinero hasta 10 minutos.

3) Formatos de descripción: User/Job Story, Use Case, Acceptance

3. 1 User/Job Story (plantilla)

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

3. 2 Caso de uso (simplificado)

4) Mapas de ruta y estructuración de flujo

4. 1 CJM (Customer Journey Map)

Etapas: Conciencia → Selección → Primera Acción → Repetición → Soporte → Retención

Para cada uno: objetivos, fricciones, emociones, canales, métricas (conversión, tiempo, NPS)

4. 2 User Flow и Story Mapping

Flow del usuario: gráfico de nodos (pantallas/estados) y transiciones (condiciones/eventos).
Historia Mapping: «cresta» (épicas/actividades) × «rodajas verticales» (MVP → extensiones).

5) Ramificaciones: happy, sad, edge cases

Happy path: camino mínimo al valor.
Sad path: errores predecibles (validez, límites, tiempos de espera).
Edge cases: raros pero caros: red inestable, duplicados, cancelaciones, carreras, conflicto de estado, no coincidencia de zona horaria/local, disponibilidad (teclado en lugar de ratón, screenrider).

Sugerencia: para cada paso clave, un mínimo de un sad y un escenario edge.

6) Estados de interfaz (UI States)

• `loading` / `empty` / `success` / `error` / `partial` / `disabled`
• pistas y micro-redacción; disponibilidad (roles/aria, enfoque, tamaños de targets); local y formato de números/fechas/monedas.

7) Requisitos A11Y en scripts

Teclado: todas las acciones son alcanzables sin el ratón; el foco visible, el orden de Amb.
Screenrider: roles y conexiones de etiquetas correctas; alternativas a los medios de comunicación.
Color/contraste: ≥ WCAG AA; no sólo por el color.
Motion: soporte para 'prefers-reduced-motion'.
Entrada: formato/máscaras, teclado de voz/pantalla; objetivos suficientes 40-48 px.
Agregue criterios de A11y separados a Acceptance.

8) Marcas analíticas y métricas de éxito

Defina los eventos, parámetros y KPI de la secuencia de comandos.

8. 1 Esquema de eventos (ejemplo 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 y umbrales de destino

Tasa de compleción (porcentaje que completó el script) ≥ X%

Tiempo-a-Valor (mediana hasta el resultado) ≤ Y minutos

Error Rate (422/429/5xx y errores de usuario) ≤ Z%

A11y Pass (script solo por teclado) = 100%

CSAT/NPS para el paso ≥ nivel de destino

9) Datos, aspectos internacionales y normas

Formatos: ISO-8601 (UTC) para el tiempo, salida localizada para el usuario.
Dinero: unidades menores/líneas decimales; la moneda es explícita.
Idiomas/RTL: textos en recursos, soporte de duplicación; longitud de las filas y transferencias.
Restricciones: límites, edad, KYC, sanciones - como condiciones previas de los escenarios.

10) Plantilla de descripción de 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) Herramientas de validación de scripts

Pruebas funcionales (Gherkin/E2E): happy/sad/edge.
A11y-auditoría: manual (NVDA/VoiceOver) + auto-linters.
Usabilidad-sesiones: 5-8 encuestados en un escenario clave.
Telemetría: banderas de fichas, dashboards Completion/TTV/Error.
Dogfooding: corridas dentro del equipo en las listas de cheques.

12) Lista de comprobación de script (verificación rápida)

• JTBD está formulado y entendido por el equipo
• Persona/Contexto/Restricciones especificadas
• User Flow y Story Map están listos; ramificaciones marcadas
• Acceptance Criteria (incluyendo A11y) son comprensibles y probables
• Los estados de UI (loading/empty/error) están documentados
• Eventos analíticos y KPI definidos
• Localización/formatos/moneda contabilizada
• Los riesgos/las ramas falsas y los places para los retraídos se describen
• El prototipo/macap está alineado con el desarrollo/datos/cumplimiento
• Plan de prueba y fecha de aceptación acordada

13) Anti-patrones

«Scripts = sólo happy path» (ignorar errores/edge).
Aceptación ilegible («hacer conveniente» en lugar de criterio medible).
Falta de A11y y localizaciones en los requisitos.
Mezclar el objetivo de negocio y la implementación de UX («añadir popup» en lugar de «bajar TTV»).
No hay un esquema de eventos → no hay nada que medir el éxito.

14) Ejemplos de historias de usuario concisas

Como nuevo usuario, quiero registrarme por correo electrónico sin confirmar el teléfono para comenzar el juego de inmediato; si se superan los límites - mostrar la alternativa «invitado».
Como gestor, quiero exportar el informe al CSV con los filtros y el timesone del proyecto para conciliar los datos con la contabilidad.

15) Plan de implementación (3 iteraciones)

• Plantillas Story/Use Case/Acceptance, registro único de scripts, esquema analítico mínimo, lista de comprobación.

• User Flow + CJM para scripts clave, criterios A11Y, dashboards Completion/TTV/Error, set E2E.

• Historia Mapping, priorización por Impacto × Efecto, hipótesis A/B, métricas regulares de rugido y CAPA.

16) Mini preguntas frecuentes

¿Personas o sólo JTBD?
Use ambos: las personas dan contexto y limitaciones, JTBD es intención y valor.

¿Es necesario describir todo hasta el píxel?
No. El escenario fija el objetivo, los pasos, las ramificaciones y los criterios de éxito; píxeles: tarea de diseño y DLS.

¿Cómo puedo entender que el guión está «listo»?
Hay Acceptance medibles, recubrimientos de happy/sad/edge, criterios A11y, eventos y KPI de destino.

Resultado

Los scripts personalizados son el «esqueleto» del producto: objetivo claro (JTBD), flujo coherente (User Flow/Story Mapping), criterios verificables (Acceptance), medición (eventos y KPI) y respeto por la disponibilidad/local. Colóquelos en plantillas únicas, automatice la validación y revise periódicamente las métricas reales para que las interfaces sigan siendo comprensibles, rápidas y valiosas para todos los usuarios.