Product Designer
Fintech
2023
Onboarding: de 30% para 75%+ de conclusão
Uma fintech brasileira atendia pessoas com acesso limitado a serviços financeiros. Sete em cada dez não concluíam o cadastro, e 86% dos cartões emitidos ficavam sem ativação. Conduzi o redesenho do onboarding, negociando a simplificação com engenharia e negócio dentro de um prazo de lançamento restrito.
Product Design · Onboarding · Pesquisa UX · Fintech
Product Designer
Fintech
2023
Onboarding: de 30% para 75%+ de conclusão
Uma fintech brasileira atendia pessoas com acesso limitado a serviços financeiros. Sete em cada dez não concluíam o cadastro, e 86% dos cartões emitidos ficavam sem ativação. Conduzi o redesenho do onboarding, negociando a simplificação com engenharia e negócio dentro de um prazo de lançamento restrito.
Product Design · Onboarding · Pesquisa UX · Fintech
Product Designer
Fintech
2023
Onboarding: de 30% para 75%+ de conclusão
Uma fintech brasileira atendia pessoas com acesso limitado a serviços financeiros. Sete em cada dez não concluíam o cadastro, e 86% dos cartões emitidos ficavam sem ativação. Conduzi o redesenho do onboarding, negociando a simplificação com engenharia e negócio dentro de um prazo de lançamento restrito.
Product Design · Onboarding · Pesquisa UX · Fintech
Contexto e problema
O produto atendia clientes das classes C e D, com conectividade instável, dispositivos compartilhados e diferentes níveis de familiaridade digital. O cadastro seguia a sequência de coleta e validação exigida pelo backend, distribuída em 15 telas. Não havia indicação clara de progresso, orientação contextual nem possibilidade de salvar e continuar depois.
A autenticação por token aparecia no começo e dependia de um sistema de entrega com falhas. As mensagens de erro chegavam após o envio do formulário, sem apontar o campo nem explicar a recuperação. Taxas e planos só ficavam claros depois do cadastro, gerando reclamações. O onboarding também estava visualmente desconectado do rebranding do produto.
A emissão de cartões era acionada ao iniciar a conta, antes da conclusão do cadastro. Com 86% sem ativação, o problema ultrapassava a interface e afetava o custo operacional.
Evidências
Analisei avaliações nas lojas de aplicativos, categorias de chamados de suporte e comentários do NPS interno. Três padrões se repetiam: falhas na autenticação, pouca visibilidade sobre o estado da conta e surpresa com as tarifas.
O benchmarking de seis fintechs voltadas às classes C e D identificou indicadores de progresso, ajuda contextual e recursos de retomada que o produto ainda não oferecia. Usei esses achados para discutir prioridades com o time, sem tratar as reclamações como uma medida precisa da taxa de falha do backend.
Restrições e trade-offs
O prazo de lançamento, a validação em etapas no backend e o rebranding em andamento limitaram o espaço de solução. Construí e facilitei uma matriz de impacto e esforço para tornar as escolhas visíveis entre design, engenharia e negócio.
A redução de telas era uma intervenção viável e de alto impacto. Salvar e continuar, ajuda inline e tooltips contextuais foram para o backlog com justificativa documentada. A decisão final de escopo foi conjunta.
Decisões e solução
1. Consolidar campos relacionados
Os dados pessoais estavam distribuídos em dez telas, com confirmações redundantes. Engenharia precisava preservar etapas de validação. Negociamos sete telas para o fluxo completo no lançamento e seis após a validação pós-lançamento, sem aumento observado nos erros de dados. Na etapa de dados pessoais, dez telas e cerca de dez toques passaram a quatro telas e cerca de quatro toques.
2. Reposicionar a autenticação
O token foi movido para o final, com uma solicitação por sessão. Isso evitava que a primeira ação do cadastro dependesse do mecanismo de entrega instável. A taxa exata de falhas desse serviço não estava disponível para o time de design.
3. Alterar o gatilho da emissão de cartões
Identifiquei e propus vincular a emissão à conclusão do cadastro. A mudança na lógica operacional foi implementada pelo time e está associada à redução de 89% no custo anual de emissão relatada no case.
4. Explicitar progresso e validação
Uma barra persistente de progresso mostrava a posição no fluxo. Os campos validados tinham feedback visual, e erros inline explicavam a recuperação específica. O feedback pós-lançamento descrevia a experiência como mais rápida.
5. Apresentar taxas e planos durante o cadastro
Desenhei uma etapa de seleção com descrições claras, tarifas explícitas e alvos de toque maiores. As vendas de planos passaram a quatro vezes a referência anterior no primeiro mês após o lançamento. Esse é um resultado do produto; não foi isolado por experimento controlado.
6. Dar orientação de recuperação por campo
Mensagens genéricas no fim do formulário deram lugar a erros específicos no ponto da interação. O acompanhamento pós-lançamento registrou 43% menos chamados de suporte relacionados ao onboarding.
Impacto documentado
Conclusão do onboarding: 30% antes; 75%+ após o lançamento.
Conversão de clientes: crescimento relatado de 60% sobre a referência anterior.
Custo anual de emissão de cartões: redução de 89%.
Vendas de planos: 4× no primeiro mês após o lançamento.
Chamados de suporte do onboarding: redução de 43%.
Fluxo completo: 15 telas antes, 7 no lançamento e 6 após a evolução.
O case registra o acompanhamento de seis meses após o lançamento, com a janela específica de um mês para vendas de planos. Os resultados refletem mudanças conjuntas de design, engenharia e operação, e não uma atribuição causal isolada ao design.
Meu papel e colaboração
Conduzi o benchmarking, a síntese dos problemas, a matriz de priorização e o design das interações: progresso, validação, erros, carregamento, confirmação da conta e seleção de planos. Propus a revisão do gatilho de cartões, negociei a consolidação com backend e alinhei componentes ao sistema de design em evolução.
Engenharia tratou validações e implementação; produto e negócio participaram das decisões de prazo, risco e operação. A matriz ajudou essas áreas a compartilhar critérios de priorização e documentar os itens adiados.
Reflexão
O abandono restante se concentrava em sessões mais longas. Interrupções em dispositivos compartilhados eram uma hipótese plausível, sem confirmação direta no material disponível. Hoje eu defenderia uma versão mínima de salvar e continuar no escopo inicial.
Também instrumentaria a autenticação desde o início. Conhecer a taxa de falha na entrega de tokens permitiria priorizar a dependência técnica com dados mais precisos.
Evidências
Analisei avaliações nas lojas de aplicativos, categorias de chamados de suporte e comentários do NPS interno. Três padrões se repetiam: falhas na autenticação, pouca visibilidade sobre o estado da conta e surpresa com as tarifas.
O benchmarking de seis fintechs voltadas às classes C e D identificou indicadores de progresso, ajuda contextual e recursos de retomada que o produto ainda não oferecia. Usei esses achados para discutir prioridades com o time, sem tratar as reclamações como uma medida precisa da taxa de falha do backend.
Restrições e trade-offs
O prazo de lançamento, a validação em etapas no backend e o rebranding em andamento limitaram o espaço de solução. Construí e facilitei uma matriz de impacto e esforço para tornar as escolhas visíveis entre design, engenharia e negócio.
A redução de telas era uma intervenção viável e de alto impacto. Salvar e continuar, ajuda inline e tooltips contextuais foram para o backlog com justificativa documentada. A decisão final de escopo foi conjunta.
Decisões e solução
1. Consolidar campos relacionados
Os dados pessoais estavam distribuídos em dez telas, com confirmações redundantes. Engenharia precisava preservar etapas de validação. Negociamos sete telas para o fluxo completo no lançamento e seis após a validação pós-lançamento, sem aumento observado nos erros de dados. Na etapa de dados pessoais, dez telas e cerca de dez toques passaram a quatro telas e cerca de quatro toques.
2. Reposicionar a autenticação
O token foi movido para o final, com uma solicitação por sessão. Isso evitava que a primeira ação do cadastro dependesse do mecanismo de entrega instável. A taxa exata de falhas desse serviço não estava disponível para o time de design.
3. Alterar o gatilho da emissão de cartões
Identifiquei e propus vincular a emissão à conclusão do cadastro. A mudança na lógica operacional foi implementada pelo time e está associada à redução de 89% no custo anual de emissão relatada no case.
4. Explicitar progresso e validação
Uma barra persistente de progresso mostrava a posição no fluxo. Os campos validados tinham feedback visual, e erros inline explicavam a recuperação específica. O feedback pós-lançamento descrevia a experiência como mais rápida.
5. Apresentar taxas e planos durante o cadastro
Desenhei uma etapa de seleção com descrições claras, tarifas explícitas e alvos de toque maiores. As vendas de planos passaram a quatro vezes a referência anterior no primeiro mês após o lançamento. Esse é um resultado do produto; não foi isolado por experimento controlado.
6. Dar orientação de recuperação por campo
Mensagens genéricas no fim do formulário deram lugar a erros específicos no ponto da interação. O acompanhamento pós-lançamento registrou 43% menos chamados de suporte relacionados ao onboarding.
Impacto documentado
Conclusão do onboarding: 30% antes; 75%+ após o lançamento.
Conversão de clientes: crescimento relatado de 60% sobre a referência anterior.
Custo anual de emissão de cartões: redução de 89%.
Vendas de planos: 4× no primeiro mês após o lançamento.
Chamados de suporte do onboarding: redução de 43%.
Fluxo completo: 15 telas antes, 7 no lançamento e 6 após a evolução.
O case registra o acompanhamento de seis meses após o lançamento, com a janela específica de um mês para vendas de planos. Os resultados refletem mudanças conjuntas de design, engenharia e operação, e não uma atribuição causal isolada ao design.
Meu papel e colaboração
Conduzi o benchmarking, a síntese dos problemas, a matriz de priorização e o design das interações: progresso, validação, erros, carregamento, confirmação da conta e seleção de planos. Propus a revisão do gatilho de cartões, negociei a consolidação com backend e alinhei componentes ao sistema de design em evolução.
Engenharia tratou validações e implementação; produto e negócio participaram das decisões de prazo, risco e operação. A matriz ajudou essas áreas a compartilhar critérios de priorização e documentar os itens adiados.
Reflexão
O abandono restante se concentrava em sessões mais longas. Interrupções em dispositivos compartilhados eram uma hipótese plausível, sem confirmação direta no material disponível. Hoje eu defenderia uma versão mínima de salvar e continuar no escopo inicial.
Também instrumentaria a autenticação desde o início. Conhecer a taxa de falha na entrega de tokens permitiria priorizar a dependência técnica com dados mais precisos.