De Frustração a Confiança: Redesign do Fluxo de Pagamento PIX
TIM
problema
Clientes inadimplentes queriam pagar suas faturas via PIX, mas a página de pagamento não oferecia contexto nem orientação — gerando frustração, erros repetidos e inadimplência prolongada.
meu papel
Product Designer Senior e único designer na squad. Liderei o discovery completo — da pesquisa inicial ao handoff técnico — e facilitei os workshops cross-funcionais para alinhamento entre áreas.
decisão-chave
Escolhemos a Proposta 2 (Evolução Completa) em vez do Quick Win: redesign integral da jornada com exibição dos detalhes da fatura, código PIX isolado, modal de feedback pós-cópia e FAQ baseado em dados reais.
resultado
CSAT subiu mais de 26 pontos percentuais em 3 meses, superando com folga o benchmark interno de 60%. Savings de inadimplência recuperada na casa de 7 dígitos, calculados pela área financeira. Alinhamento total entre as três áreas envolvidas.
prazo
6 semanas (discovery + delivery)
time
Product Designer (solo), PO, Devs, UX Writer
plataforma
Web Mobile
restrições
Prazo inegociável de 6 semanas. Cultura organizacional resistente a testes com usuários. Rollout 100% sem possibilidade de Teste A/B. Integração com sistema legado de cobrança.
confidencial
Dados sob NDA sinalizados como [—]
Contexto
A Área de Pagamentos da TIM estava sob forte pressão: clientes inadimplentes recebiam um SMS com link para uma página de pagamento web, mas os volumes de reclamação não paravam de crescer. O CSAT da página estava abaixo do benchmark interno aceitável, e a reclamação mais frequente era simples e devastadora: "erro PIX".
O cenário tinha três restrições duras. Prazo inegociável de 6 semanas para discovery e delivery. Cultura organizacional com baixíssima adesão a testes de usabilidade com usuários reais. E eu era o único designer na squad.
O Problema Real
A primeira hipótese era técnica: o código PIX estava quebrado. Os dados diziam o contrário.
A interface não explicava o que o usuário estava pagando, não diferenciava os tipos de chave PIX, e não dava nenhuma instrução sobre o que fazer depois de copiar o código. O cliente copiava, abria o app do banco, escolhia a opção errada — chave de celular em vez de Copia e Cola — e o pagamento falhava.
Diagnóstico: Matriz CSD
Com o corpus de feedbacks mapeado, estruturei uma Matriz CSD para separar o que sabíamos dos gaps de conhecimento antes de propor qualquer solução.
(Validadas nos dados)
- ▸67% dos problemas estão atrelados ao fluxo PIX
- ▸Interface atual não possui nenhuma orientação de processo
- ▸Clientes NÃO entendem as diferenças entre os tipos de chave PIX
(A serem validadas)
- ▸Usuário copia o código mas escolhe a opção errada dentro do app bancário (ex: chave telefone invés de copia e cola)
- ▸A falta de informações sobre a fatura gera desconfiança de fraude
(Gaps de conhecimento)
- ▸Como exatamente eles tentam usar o código copiado?
- ▸Qual foi o impacto real na operação quando a empresa mudou de "Código de Barras" para esta página Web?
Insight crítico:O problema NÃO era técnico (o código PIX funcionava no backend). Era de EXPERIÊNCIA — faltava contexto e orientação clara.
Adaptação de Método
O plano original previa testes de usabilidade moderados com usuários finais. O prazo e a cultura organizacional tornaram isso inviável.
A adaptação: entrevistas em profundidade com especialistas internos das áreas de Pagamentos e Atendimento — profissionais que lidam com a frustração do cliente diariamente e acumulam conhecimento tácito que nenhum survey captura.
01 / 03
4 tipos
de chave PIX distintos. A confusão léxica entre eles — celular, CPF, e-mail, Copia e Cola — era a causa raiz não mapeada pela hipótese técnica.
02 / 03
+34%
de tickets de suporte após a migração de Código de Barras para a página Web. O dado veio de especialistas internos, não de survey.
03 / 03
"Copiar"
confundido com QR Code ou cadastro de chave PIX de celular — três ações completamente diferentes dentro de qualquer app bancário.
Mapa de Decisões
Com o diagnóstico consolidado, ideei duas propostas para debate com a squad e as áreas envolvidas.
A decisão: escolhemos a Proposta 2. O argumento central não era estético — era de risco. A Proposta 1 resolveria o problema de orientação, mas manteria a desconfiança da página. Clientes que não sabem o que estão pagando simplesmente não pagam, independentemente de quantas instruções você adiciona.
O trade-off explícito: ganhamos resolução definitiva dos 67% de problemas e aumento expressiva de confiança. Perdemos sprints adicionais em um prazo que já era apertado.
O Conflito
A Proposta 2 criou um problema inesperado entre áreas.
A Área de Pagamentos queria facilitar o pagamento na Web ao máximo — era sua meta principal reduzir a inadimplência imediatamente. A Área de Atendimento queria o caminho oposto: forçar o usuário para o App Meu TIM para aumentar acessos logados, que era a meta da sua diretoria.
O time de dados levantou um número concreto: a Proposta 2, por ser muito completa, poderia reduzir os cliques no CTA do app em aproximadamente 15% — impactando diretamente a meta da Área de Atendimento.
Com objetivos genuinamente conflitantes e dados que davam razão a ambos os lados, a saída não era técnica. Era política.
Processo: Light Decision Jam
Facilitei um workshop remoto de 90 minutos no FigJam com representantes de Pagamentos, Atendimento e Dados. O formato seguiu quatro etapas: levantar problemas da solução atual, priorizar por Impacto × Urgência, identificar pontos fortes do contexto, e propor soluções híbridas conjuntas.
O breakthrough aconteceu quando o grupo chegou junto à mesma conclusão: garantir a confiabilidade da página era mais urgente do que gerar cliques no CTA do app que não convertiam em pagamento de qualquer forma.
A solução híbrida:
- Priorizamos a clareza do PIX na Web (Proposta 2 completa)
- Recomendamos o App Meu TIM apenas para quem precisasse ver o PDF detalhado da fatura — um caso de uso legítimo que preservava a meta de Atendimento sem sacrificar a experiência de pagamento
100% de alinhamento entre as três áreas. Sem voto de minerva. Sem hierarquia.
A Solução
A página redesenhada atacou as três causas raiz identificadas no diagnóstico:
antes
Sem contexto de fatura ou orientação
depois
Fatura em destaque, PIX sem ambiguidade
Falta de contexto → Detalhes da fatura em destaque. Cliente, número TIM, valor e vencimento visíveis antes de qualquer ação. O usuário sabe exatamente o que está pagando.
Ausência de orientação → Código PIX isolado e modal de feedback. Botão "Copiar código Pix" sem ambiguidade. Após a cópia, modal imediato: "Pix copiado com sucesso — escolha pagar com o Pix Copia e Cola no aplicativo do seu banco."
Baixa confiança → FAQ baseado em dados reais. As 217 reclamações viraram a base do FAQ "Como pagar" — cada pergunta respondendo uma dúvida real documentada no corpus.
Meta de Atendimento → CTA contextual para o App Meu TIM. Presente para quem precisar do PDF detalhado, sem competir com o fluxo principal de pagamento.
Opções alternativas (Boleto) → Visíveis sem scroll.
Quem Fez o Quê
O que Piorou
O tempo médio de conclusão aumentou 8 segundos (de 42s para 50s). A causa é direta: mais conteúdo significa mais tempo de leitura. Não foi um erro de design — foi uma consequência aceita da decisão de priorizar orientação sobre velocidade. Mas é um número que merece monitoramento.
Clientes ainda ligam para o Call Center dizendo "copiei, mas não achei onde colar". A lacuna entre o ambiente web e o app bancário de cada banco persiste — e está fora do nosso raio de controle com a solução atual.
Duas limitações metodológicas que reduzem a precisão dos resultados:
- Sem Teste A/B: o rollout 100% foi decisão de negócio. A causalidade entre o redesign e os resultados não é perfeita — variáveis macro não foram isoladas.
- Viés de CSAT: a pesquisa era exibida apenas após pagamento concluído, o que gera viés positivo intrínseco. Os números são direcionais, não absolutos.
Retrospectiva
lição 01
Testaria a Proposta 1 primeiro
Um Quick Win de 2 semanas teria validado o impacto real do copy antes de gastar recursos na integração de API da fatura. Validação barata vem antes de solução completa.
lição 02
Lutaria mais pelo Teste A/B
Mesmo com resistência cultural, argumentaria com mais força sobre o risco de não ter causalidade comprovada. Dados de impacto sem isolamento de variáveis são vulneráveis em qualquer revisão de resultado.
lição 03
Testaria progressive disclosure
Assumi que mais contexto sobre a dívida seria sempre melhor. Deveria ter testado detalhes colapsados via accordion antes de expor tudo de uma vez — especialmente dado o aumento no tempo de conclusão.
O aprendizado mais honesto: percebi que tenho uma tendência como designer a priorizar a solução sistêmica completa sobre quick wins imperfeitos. Neste projeto, essa tendência gerou um resultado melhor — mas com um custo de prazo que poderia ter sido evitado com mais disciplina de validação incremental.
Resultados
Medidos 3 meses após o lançamento:
+26pp
CSAT
em 3 meses, superando benchmark interno de 60%
7 dígitos
savings
inadimplência recuperada, calculado pela área financeira
100%
alinhamento
Pagamentos, Atendimento e Dados — sem escalada para diretoria
- CSAT: subiu mais de 26 pontos percentuais, superando com folga o benchmark interno de 60%
- Savings: inadimplência recuperada na casa de 7 dígitos, calculada pela área financeira comparando o mês anterior ao lançamento
- Alinhamento: 100% de consenso entre Pagamentos, Atendimento e Dados — sem escalada para diretoria
Metodologia: CSAT medido via modal avaliativo exibido pós-pagamento concluído. Savings calculados pela área financeira; valor é direcional, não auditoria contábil.
fim da linha — por enquanto
Mais cases em breve.