Sobre o Projeto
O banco digital FinVault identificou uma queda na retenção e aumento na taxa de abandono durante a contratação de empréstimo pessoal no aplicativo. O objetivo deste case foi integrar dados de qualificações externas (lojas de apps e portais de reclamação) a métricas de uso interno para orientar decisões de design baseadas em dados e validar soluções por meio de Testes A/B.
Ferramentas Utilizadas: Notion (Documentação), Jira (Gestão de tarefas), Slack (Comunicação contínua).
Processos e Metodologias: Alinhamento de Stakeholders, Definição de OKRs e North Star Metric, Mapeamento do Desafio de Negócio (Problem Statement) e teste de hipótese (Test Card).
Discovery
Para centralizar e analisar as dores dos usuários, foi estruturado um pipeline automatizado de extração (scraping) e consolidação em um banco de dados PostgreSQL.
Ferramentas Utilizadas: Python (
google-play-scraper,BeautifulSoup,pandas), PostgreSQL, DBeaver, Miro (Diagrama de Afinidade), Metabase (Visualização).Processos e Metodologias: Web Scraping, Pipeline de ETL (Extract, Transform, Load), Categorização e Análise de Sentimento de Feedback Qualitativo, Análise de Pareto (Regra 80/20), Matriz de Impacto vs. Esforço.
| Fonte de Dados | Método de Extração | Frequência | Dados Coletados |
| Google Play Store | API Scraper Python (google-play-scraper) | Diária | Avaliações (1-5★), comentários, versão da aplicação |
| Reclame Aqui | Web Scraping (BeautifulSoup) | Semanal | Título da queixa, categoria, descrição do problema, status |
| Consumidor.gov.br | Exportação CSV / Scraping público | Mensal | Relato do problema, nota de satisfação, índice de solução |
-- Consolidação na tabela unificada (unified_feedback)
CREATE TABLE unified_feedback (
feedback_id UUID PRIMARY KEY,
source VARCHAR(50) NOT NULL,
created_at TIMESTAMP NOT NULL,
rating INT,
category VARCHAR(100) NOT NULL,
raw_text TEXT NOT NULL
);
Após a categorização de 2.500 registros extraídos, construiu-se a Análise de Pareto para mapeamento de causa-raiz:
| Categoria do Problema | Frequência | % Relativo | % Acumulado | Ação Priorizada |
| Opacidade de Taxas e Juros (CET) | 1.200 | 48% | 48% | Foco do Teste A/B |
| Complexidade na Simulação | 800 | 32% | 80% | Foco do Teste A/B |
| Falhas na Biometria / KYC | 300 | 12% | 92% | Backlog Técnico |
| Demora na Aprovação | 125 | 5% | 97% | Otimização Backend |
| Erros Diversos de UI | 75 | 3% | 100% | Ajustes de Bug |
Diagnóstico (Regra 80/20): 80% dos problemas concentraram-se na falta de clareza sobre o Custo Efetivo Total (CET) e na alta fricção no simulador.
O gráfico de Pareto referente às 2.500 reclamações extraídas do Google Play Store, Reclame Aqui e Consumidor.gov.br foi gerado com os dados reais consolidados do projeto.
Explicação e Interpretação do Gráfico de Pareto
Eixo Vertical Esquerdo (Barras Azuis): Representa a frequência absoluta (quantidade) de insatisfações registradas por categoria.
Eixo Vertical Direito (Linha Vermelha): Exibe a porcentagem acumulada do total de problemas registrados.
Linha Tracejada Verde (Corte de 80%): Delimita o limiar da Regra 80/20 de Pareto (princípio de que 80% dos efeitos vêm de 20% das causas).
Principais Insights de Product Design
Identificação do Gargalo Prioritário: As duas primeiras categorias — “Opacidade de Taxas e Juros (48%)” (1.200 queixas) e “Complexidade na Simulação (32%)” (800 queixas) — somam exatamente 80% de todas as insatisfações (2.000 dos 2.500 registros).
Decisão de Design Baseada em Dados: Resolver apenas esses 2 problemas tem um impacto desproporcionalmente maior na experiência do usuário do que atuar nas 3 últimas categorias combinadas (que somam apenas 20% das queixas).
Direcionamento do Teste A/B: Essa análise justificou focar a proposta da Variante B exclusivamente na reformulação da tela de simulação e na transparência do Custo Efetivo Total (CET), eliminando o atrito principal antes de despender esforço nas áreas secundárias.
Ideação e prototipação
Com as causas-raiz identificadas, a etapa de ideação focou em redesenhar o fluxo de transparência financeira no aplicativo.
Ferramentas Utilizadas: Figma (UI Design & Prototipagem), FigJam (User Flow e Brainstorming), Maze (Testes de usabilidade qualitativos pré-A/B), Mixpanel (Mapeamento de eventos de UI).
Processos e Metodologias: Sessões de How Might We (HMW / Como Podemos), Wireframing e Arquitetura de Informação, Prototipagem de Alta Fidelidade, Aplicação de Design System (Tokens e Componentes), Testes de Usabilidade Não-Moderados, Definição Formal de Hipóteses de UX.
Hipótese de UX: Exibir visualmente a decomposição dos custos (juros, IOF, taxas) diretamente na tela de simulação reduzirá a incerteza cognitiva e aumentará a taxa de contratação.
Controle (A): Fluxo original. Exibia apenas o valor final da parcela, mantendo a discriminação de taxas escondida em um menu secundário.
Variante (B): Fluxo redesenhado. Exibe um gráfico visual com a composição das parcelas, simulador dinâmico em tempo real e detalhamento transparente do CET na tela principal.
Resultados e aprendizados
O teste A/B foi executado com 50.000 usuários ativos (divisão 50/50) durante 14 dias.
Ferramentas Utilizadas: Optimizely / LaunchDarkly (Gestão de Feature Flag e Split de Tráfego), Python (
scipy.statspara validação de hipótese), Metabase (Dashboards de acompanhamento em tempo real).Processos e Metodologias: Teste A/B (Abordagem Frequentista), Teste de Significância Estatística (Grau de Confiança e $p$-value), Monitoramento de Métricas de Negócio e UX, Documentação de Aprendizados (Debrief e Handover para Engenharia).
| Métrica Avaliada | Controle (A) | Variante (B) | Impacto (Uplift) | Significância Estatística |
| Taxa de Conversão | 12,4% | 21,8% | +75,8% | $p < 0,01$ (99% de confiança) |
| Abandono na Simulação | 62,0% | 31,5% | -49,2% | $p < 0,01$ |
| Queixas sobre Taxas Ocultas | 240/semana | 38/semana | -84,1% | $p < 0,01$ |
Impacto no Negócio: A Variante B gerou um ganho de receita no produto de crédito e reduziu drasticamente o custo operacional de atendimento nos portais públicos.
Aprendizado Principal: Transparência radical em jornadas financeiras atua diretamente como alavanca de conversão, provando que o abandono não ocorria pelo preço do produto, mas sim pela desconfiança em relação aos custos.