97.2%
Sucesso de pagamento
De 69.5% com o legado a 97.2% com o MyAccount 2.0
- Legacy69.5%
- MyAccount 2.097.2%
← Voltar aos trabalhos
ESTUDO DE CASO — PROGRESSIVE LEASING
MyAccount 2.0
Fintech B2B2C · App e Web · 2025–2026
Meu papel: design end-to-end — pesquisa, fluxos, UI, design system e QA junto com os devs.
Progressive Leasing é uma fintech dos EUA: permite levar hoje um produto de lojas como a Best Buy e pagá-lo em parcelas (lease-to-own). MyAccount é o app de autoatendimento da empresa — onde milhares de pessoas revisam o lease e pagam suas parcelas todos os dias.
4×
Pagamentos concluídos
De 16.6% a 67.4% — 4× mais pessoas chegam ao final
- Antes16.6%
- Agora67.4%
+13
Confiança do usuário
NPS +13 · 55% de promotores após o rollout
- Passivos + detratores45%
- Promotores55%
O BRIEFING E O DIAGNÓSTICO
Redesenhar o MyAccount. Primeiro, entender.
O briefing
Redesenhar o MyAccount inteiro — a casa toda, da navegação ao pagamento.
O método
Antes de mexer em qualquer coisa, mapeei o app inteiro: 1 mapa Current → New, 6 caminhos de pagamento documentados.
O que encontrei
Quatro problemas de raiz — os cartões abaixo, que são também o índice desta história.
O DIAGNÓSTICO — quatro problemas de raiz (e o índice desta história)
A ORIGEM DO PROJETO
Consultar o saldo, o progresso ou o status de um lease exigia ligar para o call center.
O app não respondia às perguntas básicas do autoatendimento. Esse foi o ponto de partida do redesenho — e os quatro achados a seguir explicam por que ele não conseguia respondê-las.
- 01
ACHADO 01
Arquitetura enterrada
O que era pessoal — leases, pagamentos, métodos — vivia empilhado num menu chamado “Account”.
→ Resposta: 4 territórios
- 02
ACHADO 02
Fluxos labirínticos
Pagar uma parcela exigia de 5 a 7 telas, com 6 variantes de fluxo.
→ Capítulo: Payments
- 03
ACHADO 03
Sem estados reais
Não existiam estados de erro, de espera nem de vazio.
→ Capítulo: estados
- 04
ACHADO 04
Sem design system
Padrões diferentes em cada fluxo; nenhum componente em comum.
→ Capítulo: design system
- 1 mapa Current → New do app inteiro
- 6 caminhos de pagamento documentados
- 4 territórios como resposta
Quatro problemas de raiz. Antes de mexer neles, era preciso medir quanto doíam —
O PROBLEMA, EM NÚMEROS
Medimos o problema. Era mais grave do que parecia.
O dado
De cada 100 tentativas de pagamento, 30 falhavam — e das que começavam, apenas 17 de cada 100 terminavam.
A prova pública
As avaliações na App Store e no ConsumerAffairs repetiam o mesmo padrão: pagamentos que não eram processados.
O custo
Cada pagamento com falha terminava no call center ou no chat: o custo era diário e crescente.
69.5%
de sucesso de pagamento na experiência legada
16.6%
dos pagamentos iniciados chegava ao final
~37K
sessões diárias passavam por essa experiência
O QUE OS USUÁRIOS DIZIAM EM PÚBLICO
Pagamentos enviados que “não foram processados”
Tentativas repetidas sem confirmação — até 3 vezes o mesmo pagamento.
App Store · avaliações 2024–2025
Cobranças com taxa de US$ 29 por recusa
Pagamentos recusados por erros de verificação que o usuário não causou.
ConsumerAffairs · 2024
“Difícil ver quanto eu devo”
A queixa de fundo: o app não deixava ver o status da conta com clareza.
Google Play · 2024–2025
Síntese de avaliações públicas verificáveis — App Store, ConsumerAffairs e Google Play.
Com os números na mão, começou a reconstrução —
A RECONSTRUÇÃO
As perguntas que o app finalmente responde.
Cada uma dessas perguntas, antes, era uma ligação para o call center.
PRIMEIRO, O MAPA
A resposta estrutural veio antes de tudo: a gaveta “Account” se abriu em quatro territórios.
Sobre esse mapa novo vivem as quatro respostas a seguir.
01 — A PERGUNTA
“Quanto ainda falta?”
Antes, o dashboard mostrava só a próxima parcela; o total restante só o call center sabia. Hoje uma tela responde isso.
LEASING DETAILS
O anel responde de uma vez: quanto já paguei, quanto falta e quando vence.
A resposta vive na tela — essa ligação deixou de acontecer
02 — A PERGUNTA
“Como eu pago?”
A pergunta mais cara de todas: pagar exigia atravessar um labirinto. Aqui está completo — e a decisão que o eliminou.
ASSIM SE PAGAVA — seis variantes deste percurso
- Make a payment
- Review payment
- “For your security” — código à parte
- Submit
- Processando…
- Payment pending / complete
A DECISÃO — Valor, método salvo e código de segurança em uma única tela. Uma única confirmação. O trade-off: mais densidade, resolvida com hierarquia e estados.
ASSIM SE PAGA HOJE — um único percurso
- UMA TELA — valor · método salvo · código de segurança
- Confirmação
- Pronto
O RESULTADO — medido com tráfego real
Pagamentos concluídos
16.6%67.4%
Sucesso de pagamento
69.5%97.2%
03 — A PERGUNTA
“Meu pagamento passou?”
As avaliações gritavam isso: pagamentos que ficavam “sem processar” sem avisar. Hoje o histórico responde antes que a dúvida apareça.
PAYMENT HISTORY
O histórico completo, com filtros e exportação — uma tela que antes não existia.
Cada movimentação com estado, cor e comprovante
04 — A PERGUNTA
“O que eu tenho, e com o que pago?”
Antes, “o que era seu” era um menu. Hoje cada coisa tem seu lugar: seus leases em um território, seus métodos de pagamento em outro.
LEASES
De linhas de menu a um território próprio: solicitações, aprovações e leases ativos ou encerrados.
Ativos e encerrados, sempre à vista
PAYMENT METHODS
Os métodos salvos ficam em destaque: pagar com o de sempre leva um toque, e adicionar um novo deixou de atrapalhar.
O método salvo, sempre a um toque
Quatro perguntas que eram ligações telefônicas. Hoje são telas.
A PROVA E O FECHAMENTO
Não pedimos fé: medimos. E o veredito chegou com tráfego real.
O MÉTODO — lançar aos poucos, medindo cada passo
10%
primeiro, um grupo pequeno
as pessoas conseguem pagar? — sim
25%
depois, 1 em cada 4
a nova contra a antiga, ao vivo
100%
só então, todo mundo
os números deram o sinal verde
O VEREDITO
97.2%
Sucesso de pagamento
antes: 69.5%
67.4%
Pagamentos concluídos
antes: 16.6% (4× de melhora)
+13
NPS
com 55% de promotores
À PARTE — O QUE FICOU CONSTRUÍDO NO CAMINHO
★ BridgeUX
Um plugin ponte que conecta Figma com código e IA: mais de 100 operações — edições em massa, tokens, exportações — de horas a minutos.
★ Design system sobre DLS
Com essa ponte foi construído e é mantido o sistema: tokens, variantes e estados vinculados, alinhados com o Storybook.
★ Um designer, alcance de equipe
BridgeUX + Claude Code: design, código e documentação em um único fluxo — o trabalho que antes pedia uma equipe.
NAS MINHAS PALAVRAS
“Este projeto me ensinou que o melhor redesenho não se nota: as pessoas simplesmente param de ligar.”
“E que um designer que orquestra agentes de IA pode mover uma empresa inteira.”