Frente 01 · App mobile
Informar e impedir
- Aviso condicional na tela de dados bancários
- Modal com a lista de bancos bloqueados
- Bancos não elegíveis removidos da listagem
Konsí Fintech · Crédito consignado
Bancos não permitidos
Como o design de uma regra de negócio, no app e no backoffice, eliminou um problema operacional na origem.
440 propostas pendenciadas por mês por banco de destino não aceito. Identifiquei o padrão no Metabase e desenhei a solução de ponta a ponta.
PapelProduct Designer · UX/UI
EscopoApp mobile · Backoffice
StatusEm produção
01 · O problema
O erro nascia no app e explodia no backoffice.
Bancos que ofertam empréstimo na Konsí não pagam em certos bancos de destino, principalmente digitais com alto risco de fraude. O app não comunicava essa restrição. A proposta era pendenciada e um operador precisava ligar pedindo outra conta.
440+
Pendenciamentos por mês
Somando CLT e Crédito Pessoal
34,2%
Das pendências no Crédito Pessoal
Primeira causa do produto
12,7%
Das pendências no CLT
200 casos por mês
“O usuário não sabia que havia restrição. O sistema aceitava qualquer banco e empurrava o erro para alguém resolver depois.”
02 · A solução
Duas frentes, um mesmo problema.
Prevenir o erro para quem pede o crédito e dar autonomia para quem opera a regra.
Frente 02 · Konsigleads
Autonomia para a operação
- Criação de regras em três passos
- Edição, exclusão e feedback claros
- Logs de auditoria e acesso por perfil
03 · Jornada no app
Quatro momentos, no lugar exato onde o erro nascia.
01
Aviso condicional
O link “Ver bancos não aceitos” aparece abaixo do campo banco só quando existe regra ativa. Sem restrição, zero ruído.
02
Explicação no momento certo
Um bottom sheet lista os bancos não aptos para aquela operação, antes que o erro aconteça.
03
Lista longa, ação fixa
Com muitos bancos bloqueados, o scroll acontece dentro do elemento e o botão “Entendi” segue visível.
04
Proteção silenciosa
Na seleção, bancos não elegíveis simplesmente não aparecem. O usuário não precisa entender a regra para não errar.
04 · Backoffice
Regras de negócio sem ticket para dev.
No Konsigleads, o time interno cria, ajusta e audita cada regra. Navegue pelas telas.
01 / 07
Visão geral das regras
Todas as regras em uma tabela, com tooltip mostrando os bancos bloqueados de cada uma e ações por linha.
05 · Decisões
Escolhas com trade-off explícito.
Só bloquear ou também informar?
Trade-offRemover os bancos sem explicação era o caminho mais simples, mas gera confusão e impede o usuário de agir.
DecisãoDuas camadas: modal para quem quer entender e filtro na listagem para impedir o erro de qualquer forma.
Aviso sempre visível?
Trade-offMostrar restrição quando ela não existe gera ansiedade desnecessária e pode levar à desistência.
DecisãoComponente condicional, exibido apenas quando há regra ativa para aquela operação.
Quem configura as regras?
Trade-offRegras fixas no código criam dependência de dev, e políticas bancárias mudam com frequência.
DecisãoInterface no Konsigleads com acesso por perfil. Backoffice com autonomia total.
06 · Impacto
O que mudou na operação.
Zero
Erros evitáveis no app
O usuário não consegue submeter banco não aceito. O problema morre antes de chegar ao backoffice.
Menos SLA
Tempo até o pagamento
Sem pendência por banco inválido, a aprovação segue sem interrupção operacional.
Autonomia
Para a operação
Regras criadas e ajustadas pelo time interno, sem ticket para desenvolvimento.
07 · Aprendizados
O que esse problema me ensinou.
Dado operacional é ponto de partida de design
O problema surgiu no Metabase, não em entrevista. 440 casos por mês já eram evidência suficiente para agir.
Design de produto inclui design de operação
A solução para o usuário ficaria incompleta sem a solução para o time interno. Em fintech, as duas pontas andam juntas.
Informar e impedir são complementares
Bloquear sem explicar gera desconfiança. Explicar sem bloquear depende de atenção. Juntos, resolvem.