Reconstruindo a área de cartão de crédito no Inter
UX Case Study — Todos os passos da reconstrução total da área de cartão de crédito do Inter.
Muito se fala sobre o processo de UX, mas como ele acontece realmente no mercado? Nesse texto conto um pouco das etapas que passei para reconstruir a área de cartão de crédito do Inter, compartilhando as dificuldades, estratégias e resultados.
Para contar essa história, vamos começar pelo contexto. O Inter é uma fintech que, além de ser um banco digital, oferece vários tipos de serviços completamente sem tarifas. Através do app, é possível ter acesso a conta digital, cartão de crédito, investimentos, marketplace, empréstimo, seguros e vários outros produtos.
Porém, oferecer os serviços gratuitos já é comum e vem se mostrando uma tendência no setor. A grande vantagem do Inter sobre os concorrentes é conseguir oferecer uma grande variedade de serviços em um único app, simplificando a vida de quem utiliza.
Após um período focado em ampliar esse leque de serviços oferecidos pelo Inter, era a hora de voltar e evoluir produtos básicos, como por exemplo a experiência de uso de cartão de crédito.
O desafio
O cartão de crédito é um dos produtos que mais atrai clientes para a empresa, sendo uma porta de entrada para o universo de benefícios que o Inter oferece. Apesar da vantagem competitiva de ser um app completo, já sabíamos pelos comentários nas redes sociais e pelos relatórios de atendimento que a nossa experiência de cartão deixava a desejar e precisava de uma revisão. Inclusive, observar os feedbacks de clientes e questões que chegam no atendimento é um bom parâmetro para detectar áreas de um produto que precisam de melhorias.
Assim surgiu a oportunidade de revisitar a experiência do usuário para melhorar as métricas de retorno para o negócio, para atrair novos clientes, reter os existentes e melhorar a satisfação de uso.
O time
Essa evolução no app foi responsabilidade de uma equipe multidisciplinar e contou com a atuação direta de analistas de negócio, UX writer, growth hacker e desenvolvedores backend/mobile. Como designer de produto, atuei de ponta a ponta: ajudei a definir as regras de funcionamento junto com a área de negócios, estruturei os fluxos, mapeei todos os cenários, construi os protótipos de alta fidelidade, validei com testes de usabilidade e acompanhei a implementação junto com os desenvolvedores.
Definindo o problema
O primeiro passo foi trazer os envolvidos no produto para um workshop de alinhamento, entendimento e definição dos principais pontos a serem atacados. Nesse dia discutimos e aprendemos sobre o funcionamento da versão existente, ouvimos as dores principais, trouxemos dúvidas e preocupações acerca dessa evolução.
Juntos, construímos uma proto-persona, montamos uma jornada do cliente, fizemos uma lista de funcionalidades baseadas nos principais pontos de dor e priorizamos as tarefas, cruzando importância pro negócio com esforço de execução.
Nesse encontro, identificamos algumas das principais dores dos usuários:
- Dúvidas e problemas de entrega durante o recebimento do cartão;
- Dificuldade de diferenciar status de fatura (problemas com falta de pagamento e pagamentos duplicados);
- Falta de clareza do entendimento do limite e inconsistência de informações;
- Confusão entre Fatura e Movimentações;
- Demora na identificação de transações/pagamentos.
Discovery & Definition
Após o workshop, dei continuidade no processo de discovery fazendo um benchmarking com 16 concorrentes, avaliando a usabilidade, estrutura, funcionamento e visual. Identificando diferenciais, benefícios e oportunidades existentes em cada um.
Em paralelo a isso, precisei dedicar algumas horas todos os dias para acompanhar, aprender e discutir possibilidades com os analistas de negócio e desenvolvedores. Como tinha acabado de chegar ao Inter, existiam muitas regras, variáveis e funcionamentos para entender e assim conseguir adaptar à nova experiência que seria proposta.
Com essas conversas, descobri como a área de cartões era um produto complexo, por existir vários cenários existentes de uma mesma tela (mais detalhes à frente), limitações técnicas, algumas regras inexploradas ou que os especialistas não sabiam explicar porque funcionava assim.
A partir daí, comecei a criar um wireflow representando algum fluxos dentro dessa área, tais como:
- Recebimento do cartão
- Solicitação de crédito
- Acompanhamento de gastos
- Consulta de limite
- Pagamento de fatura e liberação do limite
- Configurações e bloqueios
O wireflow foi uma forma ágil de mapear a estrutura existente e garantir que tudo estava sendo considerado, além de já servir como uma etapa de validação do que seria viável ou não tecnicamente. Devido a integrações entre diversos sistemas internos e externos (sendo alguns legados), algumas modificações eram limitadas e/ou arriscadas.
Para trabalhar em etapas diferentes da jornada, foi preciso bastante organização e vários alinhamentos para garantir que todos os cenários de uma mesma tela estavam sendo contemplados. Um mesmo cliente geralmente navega entre vários status: com fatura aberta ou fechada; com gastos parcelados ou não; com faturas vencidas (que podem ser revertidas ou não, dependendo do tempo de atraso); com débito automático ativo ou não (que sobrepõe todos os outros cenários); sem cartão de crédito (podendo solicitar a função crédito ou em alguns casos impossibilitado de solicitar); cartão cancelado, cartões adicionais e por aí vai.
Antes desse trabalho, nem todos os cenários estavam mapeados, inclusive algumas dessas possibilidades não eram discriminadas na versão existente do app, sendo um dos motivos de tanta confusão por parte dos usuários.
O maior desafio desse projeto foi entender, mapear e traduzir todos esses cenários e regras de forma consistente, numa experiência simples para quem usa o produto.
Com a versão final do wireflow alinhada, comecei a trabalhar nos protótipos de alta fidelidade.
Por se tratar de uma entrega grande, quebramos em micro entregas internas e fizemos versões intermediárias para testes internos a fim garantir um versionamento mais seguro. Cada entrega foi apresentada e discutida com o time de negócios e T.I., dessa forma as críticas e adaptações foram feitas em paralelo a criação, sem precisar terminar todo o fluxo.
Home — Os itens existentes na tela principal de cartões foram reorganizados de acordo com a importância e necessidade. A área recebeu novas cores para auxiliar no entendimento de cada tipo de despesa representada no limite e na fatura.
A imagem acima mostra três exemplos: próxima fatura (aberta), fatura fechada e fatura atrasada. Além da nova estrutura, as cores se modificam de acordo com o status para diferenciar melhor cada cenário da fatura e indicar para o usuário que uma ação precisa ser efetuada, no caso pagar a fatura.
Fatura — A área de fatura também foi completamente repaginada, passando a funcionar como uma linha do tempo para facilitar comparação de gastos e a navegação entre cada ciclo de cobrança.
O desafio dessa tela foi conseguir cobrir todas as possibilidades (pagamento parcial, pagamento antecipado, atraso de pagamento, quitação após atraso, clareza quanto aos juros em caso de atraso, fatura em débito automático…) mantendo a consistência entre cada cenário e ao mesmo tempo com a tela principal de cartões.
Uma grande evolução na tela de fatura foi passar a exibir as despesas parceladas na visualização de faturas futuras. Anteriormente, os gastos só apareciam quando a parcela era computada na fatura aberta, mesmo que o valor de todas as parcelas já estivesse ocupando o limite. Esse funcionamento era padrão desde a criação do banco e também era visto como inviável pela equipe de desenvolvimento. Porém, conseguimos influenciar essa mudança de paradigma provando o valor dessas informações pros nossos clientes através das evidências de como isso gerava confusão e insegurança com relação aos gastos.
Cada status de fatura tem suas ações primárias e secundárias de acordo com o contexto e as cores dos cards e gráfico se comunicam com a representação de limite, que passou a ser mais detalhada.
Limite — Antes o limite era dividido em ‘Limite total’ e ‘Disponível’, não sendo possível ver quanto do limite seria liberado ao pagar uma fatura fechada, por exemplo.
As cores foram reavaliadas funcionalmente: O vermelho ajuda a chamar atenção para o momento do ciclo que o cliente precisa pagar a fatura. Tons de azul nas faturas aberta/futuras para trazer uma cor mais branda, porém que não fosse confundida com receita (verde, em outros contextos do app) e o cinza para compras que ainda dependiam de uma confirmação no processamento, sendo o mais neutro possível.
Além do detalhamento do limite, essa versão também ganhou a funcionalidade de ajuste de limite dentro do total de crédito aprovado para o cliente, outra função muito demandada pelos correntistas do Inter.
Testes de usabilidade
Na medida que os fluxos iam tomando forma, estruturei testes de usabilidade validando quatro pontos principais da experiência (entendimento do limite, fatura, movimentações e bloqueios) com cinco participantes com diferentes graus de familiaridade com o app. Recrutei colaboradores do Inter sem contexto do projeto e parentes de colaboradores para conseguir rodar esses testes com pouca logística e menos viés.
Além de observar as percepções mais subjetivas dos participantes, construi uma planilha documentando o sucesso na realização das tarefas, classificando cada tarefa como “Concluída sem problemas”, “Concluída parcialmente ou com ajuda” e “Não concluída”. A partir dessa tabulação de resultados ficou evidente que o entendimento de limite ainda não estava claro e que as movimentações precisavam de mais destaque.
A grande vantagem de rodar testes de usabilidade estruturados é que rapidamente conseguimos identificar, não só os principais pontos de dor, mas por que existem, quais as percepções, como seu produto é usado, possíveis barreiras na interface e como poderia ser diferente.
Com esse diagnóstico, pude rapidamente iterar os principais pontos problemáticos e trazer uma primeira versão mais refinada para o desenvolvimento.
Além das melhorias nos fluxos principais, também tive a oportunidade de refazer alguns fluxos dentro da área, como configurações, alteração da data de vencimento, atualização de termos de uso e rastreio de cartão, onde aproveitamos para reavaliar o texto todas as mensagens de status.
Métricas & feedbacks
Todas as métricas estão relacionadas com retorno pro negócio e servem para analisar comportamento, porém gosto de separar nesses dois grupos apenas para me ajudar a ter foco no que estou buscando em cada uma.
Métricas de resultado pro negócio:
- NPS
- Número de clientes ativos no crédito (total & proporcional a base)
- Número de reclamações (total & proporcional a base)
- Número de transações (engajamento com produto)
- Valor das transações (padrão de uso e perfis)
- Total transacionado por período
Métricas de comportamento:
- Tempo médio de cada tela
- Total de pessoas da base que entraram em cada tela (usuários únicos)
- Total de acessos em cada tela
Seis meses após o lançamento, conseguimos alcançar o break even do produto, fruto do trabalho de várias equipes e frentes de atuação. Além desse redesign da área, foram feitas campanhas de marketing, parcerias e oferta de benefícios que foram fundamentais para atingir essa meta.
Aprendizados
Documentar o processo é importante:
Durante a jornada de criação, temos várias ideias relacionadas diretamente e indiretamente com o produto. Muitas ideias vão fugir do escopo do projeto, ou podem ser cortadas devido a limitações técnicas, priorizações, falta de tempo ou falta de recursos para desenvolver.
Tudo que foi cortado deve ser reavaliado algumas sprints à frente. E geralmente, mudanças no cenário fazem com que essas funcionalidades cortadas sejam a prioridade em outro momento.
Por isso, a documentação do processo, dos aprendizados, das descobertas e das possibilidades será um material de ouro para você ou sua equipe no futuro.
Envolva quem está demandando e quem será impactado:
Como designers de produto, somos responsáveis por entender e traduzir um objetivo estratégico, “materializando” tudo em uma experiência de uso. Colocado assim, acho que fica bem claro que parte da nossa função é ter proximidade e confiança com a área que demanda as evoluções. Entender os objetivos, como estão medindo, quais são as prioridades, quais são os prazos, porque está sendo feito assim… Devemos estar tão próximos dessa área a ponto de se misturar a ela e conseguir contribuir ativamente com o que é proposto.
Além da área de negócios que demanda o nosso trabalho, é básico ter um conhecimento mínimo de desenvolvimento e estar alinhado com a equipe que vai desenvolver o output do time de UX. Você precisa entender como os sistemas funcionam atualmente, porque é assim, o que é trivial e o que é complexo de executar. É preciso ter tato para sondar com os desenvolvedores o que você pode fazer para agilizar o trabalho deles. Quando necessário, é preciso saber propor uma nova estrutura ou funcionamento para algo que já existe e é visto como paradigma. Essa boa relação é chave para entregas mais eficientes.
Uma vez que tudo que fazemos é para os usuários, nada melhor do que descobrir o que mais gera dor com as pessoas do atendimento, que ouvem essas dores todos os dias. O grande desafio aqui é conseguir organizar o volume de informações que essa área recebe pra tirar insights. Como entender qual questão é mais latente e precisa ser resolvida primeiro? Esse problema vem da interface, do funcionamento/desempenho dos sistemas ou da regra de funcionamento? Essas reclamações estão aumentando ou diminuindo? É um problema específico desse fluxo ou se repete em outros? Além de ouvir o que o atendimento tem a dizer, é muito útil ter um representante em alguns ritos de construção do produto para receber a visão do cliente durante o processo de concepção.
Por fim, a divulgação é uma parte vital para o sucesso de um produto. É importante ter as equipes de marketing alinhadas com os status e decisões, pois esse time precisa conhecer bem o que foi criado para transmitir para quem precisa usar da melhor forma possível.
Conclusão
Assim que a nova versão foi lançada, gerou um buzz inicial de satisfação (que foi muito gratificante) e, quase que imediatamente, os clientes passaram a solicitar novos recursos, como por exemplo ter um cartão virtual ou integração com carteiras digitais.
Aqui eu reforço sobre como é importante fazer pequenas entregas rápidas para deixar que os próprios usuários indiquem a prioridade do que vem depois.
Após esse lançamento em junho de 2020, algumas evoluções já foram entregues e outros produtos estão sendo desenvolvidos. Agora, com as atualizações de objetivos estratégicos e com os dados de uso dessa nova área (que já foi bem melhor metrificada que a anterior, obrigado Lucas e Dri) já estamos estudando como serão as próximas versões dessa área que sempre estará em evolução, como um produto deve ser. =)
Obrigado por ler até aqui! ❤ Espero que esse caso de estudo tenha trazido algum insight para o seu processo. Vejo um mar de possibilidades e uma lista enorme de melhorias para a área de cartões do Inter, porém adoraria ouvir seu feedback e trocar sobre esses processos. Bora conversar no Linkedin.
