Verificação antes da saída

1) O que é um cenário personalizado

Um cenário personalizado é o caminho descrito do usuário para o resultado em um contexto específico, com premissas, passos, alternativas e o critério «o que é considerado um sucesso». Os cenários associam «porquê» (JTBD/alvo) e «como» (fluxo UX, interfaces, estados).

• Linguagem comum entre produto, design, desenvolvimento, dados e complicações.
• Menos discrepâncias nas exigências, mais rápido na recepção.
• Uma ligação clara com o efeito empresarial e as métricas.

2) Base de cenário: indivíduos e Jobs-to-Be-Done

Indivíduos: quem, contexto, habilidades, limitações (incluindo A11y).
JTBD: «Quando [a situação], eu quero [a motivação] para [o resultado esperado]».
Segmento de contexto: dispositivo, rede, local/idioma, fuso horário, permissões, limitações de ambiente.

• Quando um jogador tenta tirar o ganho à noite do celular para 3G, eu quero confirmar rapidamente a identidade sem ligar para obter dinheiro até 10 minutos.

3) Formatos de descrição: User/Job Story, Use Case, Aceitance

3. 1 User/Job Story (modelo)

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

3. 2 Use Case (simplificado)

4) Mapas do caminho e estruturação do fluxo

4. 1 CJM (Customer Journey Map)

Etapas: Conscientização Escolha Primeira ação Repetição Suporte/Retenção

Para cada um: objetivos, atritos, emoções, canais, métricas (conversão, tempo, NPS)

4. 2 User Flow и Story Mapping

User Flow: gráfico de nós (telas/estados) e transições (condições/eventos).
Story Maping: «espinha dorsal» (épicos/atividades) x «fatias verticais» (MVP → expansão).

5) Ramificações: happy, sad, edge cases

Happy path: caminho mínimo para valor.
Sad path: erros previsíveis (validade, limites, temporizações).
Edge cases: raras, mas caras: rede instável, duplicados, cancelamentos, corridas, conflito de estado, discrepância local/fuso horário, disponibilidade (teclado em vez de mouse, ecrã).

Conselho: para cada passo-chave, pelo menos um sad e um edge-cenário.

6) Estados de interface (UI States)

• `loading` / `empty` / `success` / `error` / `partial` / `disabled`
• dicas e micro-copiratamento; disponibilidade (papel/ária, foco, tamanho dos objetivos); local e formato de números/datas/moedas.

7) A11y-requisitos em cenários

Teclado: todas as ações são acessíveis sem o mouse; truque visível, ordem de Tab.
Ecrã: papéis e ligações corretas das editoras; alternativas de mídia.
Cor/contraste: ≥ WCAG AA; não só de cor.
Motion: suporte para 'preferers-reduced-motion'.
Digitar: formato/máscaras, voz/teclado; metas suficientes 40-48 px.
Adicione critérios A11y individuais ao Acceptance.

8) Sinalização analítica e métricas de sucesso

Defina eventos, parâmetros e KPI para o cenário.

8. 1 Esquema de eventos (exemplo 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 liminares de destino

Correspondência Rate ≥ X%

Time-to-Value (mediana antes do resultado) ≤ Y minutos

Error Rate (422/429/5xx e erros personalizados) ≤ Z%

A11y Pass (só teclado) = 100%

CSAT/NPS por etapa ≥ de destino

9) Dados, aspectos internacionais e regras

Formatos: ISO-8601 (UTC) para o tempo, saída localizada para o usuário.
Dinheiro: minor units/linhas decimais; A moeda é clara.
Línguas/RENAULT: textos em recursos, suporte ao espelhamento; comprimento de linhas e transposição.
Limitações: limites, idade, KYC, sanções - como uma opção de cenários.

10) Modelo de descrição de cenário (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) Ferramentas de validação de cenários

Testes funcionais (Gherkin/E2E): happy/sad/edge.
Auditoria A11y: manual (NVDA/VoiceOver) + lentes automáticos.
Sessões Usability: 5 a 8 entrevistados para o cenário-chave.
Telemetria: bandeiras de fiche, dashboards Complition/TTV/Erro.
Dogfooding: verificações internas em folha de cheque.

12) Folha de cheque do cenário (verificação rápida)

• O JTBD é formulado e compreendido pela equipe
• Pessoa/contexto/restrições são definidas
• User Flow e Story Map estão prontos; ramificações marcadas
• Aceitance Criteria (incluindo A11y) são compreensíveis e testáveis
• Estados UI (loading/empty/erro) documentados
• Eventos analíticos e KPI definidos
• Localização/formatos/moeda
• Os riscos/ramais de feel e as placas de retrações são descritas
• O protótipo/macap está alinhado com o desenvolvimento/dados/complens
• O plano de teste e a data de admissão estão alinhados

13) Anti-pattern

«Cenários = apenas happy path» (ignorar erros/edge).
Aceitance não lido («fazer conveniente» em vez de um critério medível).
Não há A11y nem localização nos requisitos.
Mistura de meta empresarial e implementação UX («adicionar pop-up» em vez de «reduzir TTV»).
Não há esquema de evento → nada para medir o sucesso.

14) Exemplos de User Stories concisos

Como um novo usuário, gostaria de se inscrever por e-mail sem confirmar o telefone para começar o jogo imediatamente; se os limites forem ultrapassados, mostrar uma alternativa para «convidado».
Como gerente, quero exportar o relatório para o CSV com filtros e projeto de tempo para verificar os dados com a contabilidade.

15) Plano de implementação (3 iterações)

• Modelos Story/Use Case/Acceptance, registro de cenário único, padrão de análise mínimo, folha de cheque.

• User Flow + CJM para cenários-chave, critérios A11y, dashboard Complition/TTV/Erro, conjunto E2E.

• Story Maping, priorização por Efeito x Effort, hipóteses A/B, métricas regulares e CAPA.

16) Mini-FAQ

Pessoas ou apenas JTBD?
Use ambos: indivíduos fornecem contexto e limitações, JTBD - intenção e valor.

Você precisa descrever tudo antes do pixel?
Não. O cenário fixa metas, passos, ramificações e critérios de sucesso; pixels é tarefa de layout e DLS.

Como sei que o cenário está pronto?
Há Aplictance medíveis, revestimentos por happy/sad/edge, critérios A11y, eventos e KPI alvo.

Resultado

Os cenários personalizados são «esqueleto» do produto: alvo claro (JTBD), fluxo alinhado (User Flow/Story Maping), critérios de verificação (Acceptance), medição (eventos e KPI) e respeito à disponibilidade/localização. Fixe-os em modelos unificados, automatize a verificação e reveja regularmente por métricas reais, de modo que as interfaces fiquem claras, rápidas e valiosas para todos os usuários.