Trabalhei em fintech e banking por cerca de um terço da minha carreira de mais de uma década, começando na GFT no Brasil com dashboards em tempo real para empresas de investimentos, depois no BNP Paribas Cardif como desenvolvedor Angular, depois na Wonderlabs como desenvolvedor Angular e UX lead em um PWA de cartão de crédito no Canadá, e depois no BMO como desenvolvedor front-end em uma plataforma de solicitação de empréstimos. Fora de finanças, trabalhei em uma plataforma de emprego, uma plataforma de viagens em grupo, uma plataforma de check-up de saúde, meu próprio produto SaaS e uma plataforma de saúde mental. O contraste é nítido o suficiente para que eu queira escrever sobre isso diretamente: projetar para finanças é genuinamente diferente de projetar para outros setores, e as diferenças vão mais fundo do que convenções estéticas ou uma paleta de cores conservadora.
Este não é um post sobre fazer apps bancários parecerem modernos. É sobre as restrições fundamentais de design que fazem do UX financeiro uma disciplina distinta, e como trabalhar efetivamente dentro delas.
Confiança É o Produto
Na maioria das categorias de software, o produto é um conjunto de funcionalidades. Os usuários escolhem o Slack pelo sistema de canais e busca, ou o Notion pelo editor de blocos flexível. Em produtos financeiros, o conjunto de funcionalidades é o mínimo esperado. O produto real é a confiança. Um usuário que não confia que seu dinheiro está seguro, ou que o app está mostrando informações precisas, não vai usá-lo independentemente de quão elegante a interface seja.
Isso significa que cada decisão de design em um produto financeiro precisa passar por um filtro de confiança. Esse padrão de UI comunica confiabilidade e estabilidade? Essa mensagem de erro explica o que aconteceu de forma clara e honesta? Esse estado de carregamento tranquiliza o usuário de que a transação está sendo processada, ou cria ansiedade? Essas são perguntas que não surgem com tanta intensidade em, digamos, um app de reserva de viagens.
Sinais Visuais de Confiança
A confiança é parcialmente comunicada visualmente. A linguagem de design conservadora da maioria dos apps bancários (cores suaves, tipografia limpa, uso limitado de elementos lúdicos) não é uma falha de criatividade, é um sinal deliberado: esta é uma instituição séria e estável. Os usuários foram condicionados a associar calma visual com confiabilidade financeira, e se afastar dessa convenção requer calibração cuidadosa.
Design systems bancários avançam em direção a um design visual moderno e acessível mantendo os sinais de confiança que os usuários esperam. A cor primária fica em uma paleta dominada por azul, associada à segurança financeira. A tipografia é clara e legível, nunca decorativa. Microinterações são intencionais e informativas ao invés de divertidas-mas-distrativas. No BMO eu construí features com o design system do banco, que pertencia a outro time, e da cadeira do desenvolvedor a lição é quão pouco espaço um sistema desses deveria deixar para variação divertida. Um botão que parece tonalmente inconsistente com o contexto de movimentar dinheiro custa confiança, não só cliques.
Conformidade Como Restrição de Design
Cada decisão de design em um produto financeiro regulado tem uma dimensão legal. Na maioria das instituições financeiras, conformidade tem voz antes de o desenvolvimento começar. Isso não é uma inconveniência burocrática: é uma parte fundamental do processo de design, e eu coloco as restrições de conformidade já no primeiro wireframe em vez de tratá-las como uma etapa final de revisão.
As restrições de conformidade em UX financeiro incluem: divulgações obrigatórias que devem aparecer em locais específicos e em tamanhos mínimos de fonte, etapas de confirmação obrigatórias antes de transações irreversíveis, linguagem específica para divulgação de taxas, expiração de sessão baseada em tempo com notificação apropriada ao usuário, e requisitos de trilha de auditoria que afetam como as interações são registradas e exibidas.
No design de fintech, a restrição de conformidade não é inimiga de um bom UX, é um brief de design do regulador. O desafio é atendê-la de uma forma que também seja clara e utilizável.
O problema de posicionamento de divulgações é um bom exemplo. Requisitos regulatórios frequentemente exigem que divulgações de taxas apareçam antes do usuário confirmar uma transação. Uma implementação ingênua coloca isso como um parágrafo de texto jurídico que os usuários imediatamente rolam para passar. Um design melhor integra a divulgação de forma significativa, resumindo a informação-chave (Você será cobrado R$ 4,50 por esta transferência) em linguagem simples, com um link para o texto legal completo para usuários que quiserem.
Tratamento de Erros em Fluxos Financeiros
Estados de erro em aplicações financeiras são genuinamente de alto risco. Uma mensagem de erro vaga durante uma transferência de fundos não apenas cria frustração: cria pânico. O dinheiro saiu da minha conta? Está perdido? Devo tentar de novo? Se o usuário tenta novamente e a primeira transação foi concluída, ele pode ter enviado dinheiro duas vezes. Isso não é um caso extremo teórico; é um cenário que equipes de UX bancário levam muito a sério.
Os princípios que aplico ao tratamento de erros em fluxos financeiros, com movimentação de dinheiro sendo o caso mais difícil:
- Sempre diga ao usuário o estado atual da transação. Se a transferência falhou antes de chegar à rede, diga isso. Se foi enviada mas o tempo de resposta expirou, diga isso e explique o que significa para o saldo.
- Nunca deixe o usuário em ambiguidade sobre se o dinheiro foi movido. Mesmo que você não saiba o resultado, diga 'Estamos confirmando sua transferência. Notificaremos assim que tivermos a confirmação.' Isso é melhor que silêncio.
- Diferencie entre erros do usuário (formato errado do número da conta) e erros do sistema (timeout de rede) na mensagem, porque a ação apropriada é diferente em cada caso.
- Forneça um caminho claro de recuperação. 'Por favor, tente novamente' é inadequado. 'Por favor, tente novamente em alguns minutos. Se o problema persistir, entre em contato pelo 0800-XXX-XXXX' é acionável.
- Para erros irreversíveis, forneça informações de contato imediatamente. Não faça um usuário em pânico procurar um número de telefone.
Divulgação Progressiva para Produtos Complexos
Produtos financeiros são inerentemente complexos. Uma solicitação de hipoteca envolve dezenas de dados, perguntas condicionais, acordos legais e verificação em múltiplas etapas. Uma visualização de carteira de investimentos envolve hierarquias de dados, cálculos de performance, indicadores de risco e benchmarks comparativos. Apresentar tudo isso de uma vez é cognitivamente avassalador. Não apresentar o suficiente viola a necessidade do usuário por informação ao tomar decisões consequentes.
Divulgação progressiva, revelar informações progressivamente conforme o usuário demonstra necessidade ou prontidão, é uma das técnicas mais importantes em UX de fintech. Em um formulário de solicitação longo, isso significa revelar perguntas com base em respostas anteriores (não precisa perguntar a renda do cônjuge se a pessoa indicou que é solteira) e quebrar o formulário em algo que pareça uma conversa. Onboarding é onde o design de fluxo mais claramente rendeu para mim: na Wonderlabs eu redesenhei o fluxo de onboarding da plataforma de cartões de crédito através de ciclos de prototipação e testes, e o engajamento dos usuários subiu 15%.
Arquitetura de Informação em Camadas
A divulgação progressiva se aplica não apenas a formulários, mas à exibição de informações. O padrão se generaliza bem para uma visão de carteira: as métricas essenciais de relance, valor total, variação do dia, retorno geral, e todo o resto a uma expansão de distância. Por classe de ativos, por título individual, por período. Esse empilhamento respeita tanto o usuário que quer uma verificação rápida quanto o que quer uma análise profunda, sem sobrecarregar nenhum dos dois.
Segurança Como Pilar de UX
Requisitos de segurança em aplicações financeiras criam fricção real de UX, e o desafio de design é minimizar essa fricção sem comprometer o modelo de segurança. Expiração de sessão, autenticação de dois fatores, etapas de confirmação de transação, re-autenticação biométrica para ações sensíveis: tudo isso existe por razões legítimas, e tudo isso adiciona fricção à experiência do usuário.
O insight-chave que desenvolvi é que a fricção de segurança parece aceitável para os usuários quando é proporcional ao nível de risco da ação e claramente explicada. Reinserir sua senha para ver o saldo da conta parece absurdo e invasivo. Reinserir sua senha para alterar a conta bancária vinculada parece razoável: os usuários entendem por que essa ação justifica verificação extra.
O modelo para o qual os bancos convergem é a autenticação escalonada por risco, onde o nível de fricção acompanha o valor e o tipo da transação. Transferências rotineiras de baixo valor (pagar uma conta recorrente abaixo de um valor limite) usam só biometria. Transferências de alto valor ou incomuns exigem biometria mais código de confirmação. Novos favorecidos exigem um desafio 2FA completo. Eu não desenhei um desses modelos, mas a disciplina de casar fricção com risco é a parte que vale copiar para qualquer produto com ações de consequência.
Acessibilidade em Indústrias Reguladas
Acessibilidade em serviços financeiros não é apenas uma obrigação ética: em muitas jurisdições é uma obrigação legal. Bancos canadenses são de regulação federal, então caem sob a Accessible Canada Act e a Canadian Human Rights Act, e não sob a AODA de Ontário (Accessibility for Ontarians with Disabilities Act). A AODA cobre organizações de regulação provincial em Ontário, entre elas as cooperativas de crédito, e o seu Integrated Accessibility Standards Regulation (IASR) usa WCAG 2.0 AA como referência técnica (com exceções para os critérios 1.2.4 legendas ao vivo e 1.2.5 audiodescrição). No BMO, as features que eu construía precisavam ser compatíveis com acessibilidade, e eu trato isso como parte do pronto, não como um complemento posterior.
UX financeiro tem desafios específicos de acessibilidade que outros setores encontram com menos frequência:
- Tabelas de dados complexas (históricos de transações, visualizações de carteira) precisam de marcação HTML adequada com cabeçalhos de coluna e linha para usuários de leitores de tela. Uma tabela visualmente elegante que colapsa no mobile e perde o contexto de cabeçalhos falha em acessibilidade.
- Gráficos e charts são padrão em aplicações financeiras, mas inerentemente inacessíveis sem alternativas de texto. Todo gráfico precisa de um resumo textual e uma tabela de dados acessível como alternativa.
- Sessões com tempo limitado criam um desafio real de acessibilidade. Usuários com deficiências cognitivas ou motoras podem precisar de mais tempo para completar transações. O critério WCAG 2.2.1 (Timing Adjustable) normalmente é atendido com um aviso antes da expiração e uma forma simples de estender a sessão, e em um app bancário esse aviso precisa ser anunciado para usuários de leitor de tela, não apenas mostrado como um toast que desaparece.
- Mensagens de erro em formulários financeiros devem ser programaticamente associadas aos seus campos de input para que leitores de tela as anunciem corretamente. Este é um requisito de desenvolvimento que começa na etapa de especificação de design.
O Que Se Transfere de Outros Setores
Nem tudo é diferente em UX de fintech. Os fundamentos de pesquisa com usuários, testes de usabilidade, arquitetura de informação e design de interação se aplicam em todo lugar. O trabalho que fiz na plataforma de saúde mental me ensinou muito sobre projetar para usuários em estados emocionalmente vulneráveis, lições que se transferem diretamente para UX financeiro, onde os usuários frequentemente estão estressados (conta no negativo), ansiosos (volatilidade do mercado) ou sobrecarregados (solicitação de hipoteca).
A mudança ao entrar em design de fintech vindo de outros setores é menos sobre aprender novas técnicas e mais sobre internalizar um modelo de risco diferente. Em fintech, as consequências de uma experiência de usuário ruim não são apenas usuários insatisfeitos: são dano financeiro, não conformidade regulatória e erosão da confiança que é a base de todo o produto. Esse peso muda como você projeta, para melhor.
Referências
- Financial Consumer Agency of Canada, Financial Consumer Protection Framework. https://www.canada.ca/en/financial-consumer-agency/services/banking/rights-new-protections/consumer-protection-framework.html
- WCAG 2.1 Understanding. https://www.w3.org/WAI/WCAG21/Understanding/
- Accessibility for Ontarians with Disabilities Act. https://www.ontario.ca/laws/statute/05a11
- Accessible Canada Act, resumo. https://www.canada.ca/en/employment-social-development/programs/accessible-people-disabilities/act-summary.html