Cases 01 — Fintech & Fomento
Como transformei um chatbot com 80% de erro em uma jornada guiada de qualificação — sem persona, sem testes e com uma semana de prazo.
Oito em cada dez pessoas escolhiam a linha de crédito equivocada — ou eram MEIs simulando um produto que não era para elas. Cada erro virava retrabalho manual de um especialista.
A agência é um banco de fomento estadual, que oferece linhas de crédito para empresas e municípios. Meu desafio era estancar o erro reprojetando a jornada de simulação.
O complicador estava nas restrições: uma semana de prazo, nenhuma persona e um cliente que recusava testes de usabilidade. Foi um projeto definido menos pelo que eu tinha e mais pelo que faltava.
A simulação por chatbot não ajudava a pessoa a chegar na linha certa. Ela decidia sem entender as opções — e o vocabulário de crédito (IPCA, IOF, carência, amortização, cobertura) é uma barreira real para quem não é do mercado financeiro.
A experiência prometia autonomia e entregava um resultado inútil.
Cada simulação errada que virava intenção real de contratação tinha que ser refeita à mão por um especialista. Retrabalho operacional puro — tempo de equipe gasto para corrigir algo que a interface deveria ter evitado na origem.
Em escala, isso é custo recorrente e gargalo de atendimento.
Minha hipótese central: o formato chatbot era parte do problema, e o erro precisava ser barrado na origem — não corrigido no fim.
Sem acesso a usuários reais e sem tempo para pesquisa primária, montei a investigação possível.
Busquei evidência pública para sustentar a hipótese de que o chatbot atrapalhava. 90% dos consumidores preferem atendimento humano quando podem escolher (Opinion Box); 44% se frustram quando não conseguem escapar do atendimento automatizado (Forrester). Numa decisão de crédito — alta carga, alto risco percebido — empurrar o usuário para um bot era ampliar a chance de erro e abandono.
Analisei como outras instituições estruturavam a simulação de crédito: onde colocavam os filtros, como apresentavam as linhas, em que momento qualificavam a elegibilidade. Um repertório de padrões consolidados para substituir o chatbot.
A planilha de campos de filtro que recebi virou a espinha dorsal do fluxo. Reorganizei esses campos numa sequência de qualificação progressiva, em que cada etapa estreita o funil antes de deixar o usuário avançar.
Em vez de um chatbot que coletava respostas soltas, desenhei um fluxo linear de qualificação em camadas. Cada etapa filtra antes de liberar a próxima.
Investir no negócio, em inovação ou em sustentabilidade. Já começa educando sobre o tipo de uso e descartando caminhos irrelevantes.
Administrada por mulheres, regiões prioritárias de fomento, produtor rural. Toggles que capturam critérios e destravam linhas específicas.
A etapa-chave. É aqui que o MEI é identificado e redirecionado para a linha de microcrédito adequada — em vez de seguir num fluxo que não era para ele. O erro estrutural deixa de acontecer na origem.
Valor, prazo e CEP com autocomplete. Tratamento de exceção: produtor rural cai numa variação do formulário que pede CPF em vez de CNPJ.
O comparativo de linhas elegíveis — o destaque técnico do projeto, detalhado a seguir.
O resultado foi onde concentrei a maior carga de design — é o momento em que o erro de escolha historicamente acontecia. Em vez de devolver uma única linha, entreguei um comparativo lado a lado, com os mesmos parâmetros em cada card e a elegibilidade visível na própria decisão.
fig. 01 — comparativo de linhas, parâmetros simétricos + selo de elegibilidade
A estrutura ataca a causa raiz de duas formas. Primeiro, só mostra linhas para as quais o usuário já foi qualificado nas etapas anteriores — então a escolha errada fica mecanicamente mais difícil. Segundo, ao tornar elegibilidade e parâmetros comparáveis num formato consistente, transfere para o usuário a capacidade de decidir com critério, em vez de adivinhar.
Validar a jornada com usuários antes de entregar — o passo que transforma hipótese em decisão informada.
O cliente recusou os testes, dizendo que não faziam parte da cultura da empresa, e o prazo era de uma semana. Duas barreiras simultâneas, uma cultural e uma de tempo.
Entreguei a jornada baseada na tríade que eu tinha: os campos da planilha, os padrões da desk research e a evidência de mercado sobre aversão a chatbot e fricção do jargão.
Entregar sem validação direta com o usuário final — risco que, com franqueza, eu absorvi sozinho em vez de torná-lo visível. Volto a isso na reflexão.
A jornada nasceu no Figma, mas vivia dentro do Salesforce — o que significou construir diversos LWC (Lightning Web Components) personalizados. Cada elemento que fugia do componente padrão exigia desenvolvimento sob medida e pesava no cronograma. Decisões que pareciam triviais no Figma tinham custo real de engenharia, e priorizá-las fazia parte do meu trabalho.
O maior atrito, porém, não foi técnico — foi de insumos. O cliente atuava como Product Owner sem experiência na função. Boa parte do meu trabalho não foi desenhar telas, foi preencher os vazios de definição que um P.O. experiente entregaria pronto: fazer as perguntas certas, propor as regras ausentes (o redirecionamento do MEI, o caso do produtor rural) e validar suposições no lugar de receber requisitos.
A entrega substituiu um fluxo conversacional propenso a erro por uma jornada de qualificação que ataca as duas causas raízes: a escolha equivocada de linha (resolvida pelo comparativo) e o acesso indevido do MEI (resolvido pelo redirecionamento na etapa de faturamento).
O valor mais concreto foi a mitigação rápida de um risco operacional recorrente sob restrição severa. Sem persona, sem testes e com uma semana, traduzi um problema mal definido numa solução estruturada e implementável — sustentada por evidência de mercado, padrões do setor e decisões que enfrentavam a causa raiz, não o sintoma. O cliente validou a jornada para desenvolvimento.
Eu faria os testes de usabilidade — mesmo com o prazo curto, mesmo que com cinco pessoas próximas. Sessões de guerrilha custam pouco e teriam coberto os riscos críticos da jornada, sobretudo a etapa de qualificação por faturamento, onde um rótulo mal compreendido pode mandar o usuário para o caminho errado.
Mas o aprendizado mais importante não foi sobre teste — foi sobre comunicação de risco. Eu absorvi sozinho o risco de entregar uma jornada não validada, em vez de torná-lo explícito para o time e o cliente. Deveria tê-lo nomeado em voz alta: registrar que avançávamos sem validação, qual era a exposição disso e como mitigaríamos.
Sob ambiguidade extrema, a expertise de UX se prova menos na tela bonita e mais na capacidade de tomar boas decisões com pouca informação e de atacar a causa raiz. Mas decisão de risco é decisão de time — e tornar o risco visível é parte do trabalho.
Figma · Salesforce (LWC) · desk research · benchmarking · arquitetura de informação · qualificação progressiva · design sob restrição de viabilidade técnica