Transformei uma obrigação regulatória em feature de autonomia — desenhando um controle de tempo que o usuário quer usar, não teme. O desafio: avisar sem interromper, proteger sem punir.
O limite de tempo existia na plataforma. O problema não era ausência de funcionalidade — era a experiência ao redor dela. Um logout abrupto no meio de uma partida não parece proteção. Parece erro. O desafio era comunicar sem interromper e proteger sem punir.
No iGaming, os tickets de suporte costumam tratar de dinheiro. Quando chegaram relatos qualitativos sobre controle de tempo, foi um sinal diferente: usuários que queriam controlar o próprio uso da plataforma e não conseguiam.
O limite de tempo existia. O problema não era ausência de funcionalidade — era a experiência ao redor dela. Usuários não encontravam onde configurar. Quando configuravam, não recebiam nenhum aviso antes do tempo acabar. E quando acabava, o sistema encerrava a sessão sem explicar por quê. Um logout no meio de uma partida não parece proteção. Parece erro.
Em um ambiente regulado pela Lei 14.790/23 — que exige que as plataformas ofereçam mecanismos de autocontrole — isso era também um problema de conformidade. Trabalhei com o time de produto para definir os requisitos antes de qualquer tela. A pergunta que guiou essa conversa: como cumprimos a lei de um jeito que o usuário não sinta que está sendo punido?
O primeiro trabalho foi mapear. E ficou claro que não havia um problema — havia dois, completamente diferentes, que precisavam de soluções distintas.
A jornada de configuração — onde fica essa opção, como é apresentada, qual linguagem é usada, o usuário entende o que está configurando e quais são as consequências.
A jornada de encerramento — o que acontece quando o tempo acaba. O que o usuário vê quando é deslogado? Com quanto tempo de antecedência recebe aviso? O sistema havia simplesmente implementado o logout sem considerar o estado em que o usuário estava quando o tempo acabou — no meio de uma aposta, em plena concentração, sem nenhum contexto sobre o que havia acontecido.
A segunda jornada era o ponto crítico ignorado anteriormente. Um logout sem explicação no meio de uma aposta é o tipo de experiência que vira reclamação, chargeback e baixo NPS.
Com as duas jornadas mapeadas, o problema central ficou claro: como avisar o usuário antes do tempo acabar sem interromper a experiência que ele estava tendo? Avaliei três abordagens.
A progressão não é decorativa — é comunicação. Cada estado tem uma semântica clara que o usuário lê sem precisar ler.
Verde — tempo confortável. O widget existe, mas tem presença mínima. Está ali para o usuário que quer saber quanto tempo tem, não para o usuário que não quer ser incomodado. Nesse estado, o sistema está dizendo: "tudo em ordem, você tem tempo."
Amarelo — 10 minutos. A presença aumenta. O widget fica mais visível, mais legível, com um rótulo explícito do tempo restante. Ainda não é urgência — é uma informação que o usuário precisa ter para decidir se quer continuar, estender ou encerrar por conta própria.
Vermelho pulsante — 5 minutos. Agora é urgência. O widget pulsa suavemente para chamar atenção visual sem ser agressivo. A mensagem mudou: "você pediu para ser avisado, e eu estou avisando. Você ainda tem tempo para agir."
Quando o tempo acaba, a tela não mostra um erro. Mostra: "Seu limite de tempo chegou ao fim" — com o contexto completo de quanto tempo foi usado e um convite para voltar quando quiser.
"Seu limite de tempo chegou ao fim" comunica algo completamente diferente de "sessão expirada". Um é cuidado. O outro é erro. Essa distinção — multiplicada por cada texto de interface — é o que define como o usuário sente a plataforma."
A experiência do jogador é apenas metade do produto. Para que o controle de tempo funcione no nível regulatório, alguém do lado da casa precisa poder configurar como esse fluxo opera — quais limites mínimos e máximos são permitidos, em quanto tempo os alertas disparam, quais restrições se aplicam por tipo de jogo.
O Back Office de configuração foi projetado com princípios diferentes do produto para o jogador. Onde o produto do jogador prioriza leveza e não-intrusividade, o Back Office prioriza clareza técnica — o operador precisa saber exatamente o que cada parâmetro faz antes de salvar.
Consequências visíveis antes da confirmação. Qualquer alteração exibe uma prévia do impacto — quantos usuários ativos serão afetados pela mudança, quais jornadas em curso serão alteradas.
Auditabilidade por padrão. Toda configuração registra quem alterou, quando e o que mudou. Em ambiente regulado, esse log não é opcional — é o que protege a casa em caso de fiscalização.
O fluxo completo — configuração pelo jogador, sistema de alertas progressivos, logout educativo e Back Office — foi implementado na plataforma e aprovado pelo jurídico como aderente à Lei 14.790/23.
A implementação revelou algo que o Figma não mostrava: em alguns jogos com animações e elementos visuais pulsantes, o widget vermelho competia visualmente com o próprio jogo. A hierarquia de atenção ficava confusa. Foi um aprendizado que só o ambiente real consegue entregar — e que seria capturado mais cedo com testes em contexto antes do lançamento.
A progressão verde → amarelo → vermelho comunicou urgência sem criar fricção. O logout educativo transformou um momento de frustração potencial num momento de transparência. O Back Office entregou auditabilidade que protege a casa em caso de fiscalização.
Não há garantia de que o usuário leu o aviso antes do logout. O overlay progressivo confia que comunicação bem feita será notada — essa é uma hipótese, não uma certeza. Em vermelho em ambiente de cassino pode conotar jackpot, não urgência.
Testaria os estados visuais em contexto real de jogo antes de finalizar o design.
A progressão de cores faz sentido fora do contexto de um cassino. Dentro, vermelho pode ter conotação positiva. A semântica de cores que funciona em alertas de sistema pode não funcionar da mesma forma num ambiente onde as cores têm significados próprios — e onde vermelho pulsante pode parecer um jackpot chegando, não um aviso. Essa hipótese não foi testada antes do lançamento.
Mapearia também os estados de falha do sistema de alertas. E se o timer falhar silenciosamente? E se o overlay não aparecer por algum motivo técnico? Em ambiente regulado, falha silenciosa não é só problema de UX — é problema de conformidade. Os estados de falha não receberam atenção de design proporcional à sua criticidade.