Redesenhando um formulário de reembolso
DURAÇÃO
8 meses (2022)
POSIÇÃO
TIME
1 Product Designer • 1 Product Manager • 1 Tech Lead • 1 Full-stack Developer
Product Designer
Introdução
O EBANX é o processador de pagamentos que facilita a entrada de empresas globais em mercados em ascensão.
Quando um consumidor faz uma compra em um parceiro do EBANX usando um método de pagamento à vista como boleto ou transferência bancária e por algum motivo precisa pedir um reembolso, uma das soluções do EBANX é fazê-lo por meio de um depósito bancário. Isso acontece quando não é possível fazer um estorno, ou seja, reverter a transação usando o método de pagamento escolhido pela pessoa, como é de praxe em compras com cartão.
Para que esse depósito ocorra, é preciso pedir para que a pessoa preencha um formulário com seus dados bancários. Porém, o time de produto recebeu do time de Customer Experience uma análise mostrando que a maior parte dos tickets de atendimento abertos para CX estava relacionado a dúvidas sobre o formulário.
Esse projeto consistia então em redesenhar o formulário de reembolso para melhorar sua usabilidade e diminuir erros de preenchimento, reduzindo assim a carga de tickets para o time de CX.
Objetivo a longo prazo
Reduzir em 50% a quantidade de tickets de atendimento relacionados ao formulário de reembolso.
Processo
Entendendo o contexto
Antes de entender quais problemas estavam ocorrendo, eu precisava entender como é o processo de reembolso do EBANX. Para isso eu tive a ajuda do PM que tocou esse projeto comigo. Ele me apresentou todo o fluxo de reembolso, quais pontos desse fluxo desencadeavam para o formulário, por quais canais comunicávamos ao consumidor que ele precisaria preenchê-lo, entre outras questões.
Depois disso, eu finalmente fui apresentada ao formulário e de cara já deu para detectar alguns problemas, como o fato dele estar totalmente desatualizado com a linguagem visual do EBANX, muitos campos para serem preenchidos, mensagens confusas e até links para funcionalidades que não existiam mais!
É importante frisar que durante esse projeto a empresa estava fazendo diversas melhorias na jornada de reembolso, que é de fato o maior ponto de dor para o usuário final e, consequentemente, para os nossos parceiros. O redesenho do formulário foi uma dessas iniciativas.
Descobrindo os (outros) problemas
Analisando com o PM os dados relativos aos principais motivos de abertura de tickets sobre reembolso, pudemos ver que o tema “formulário de reembolso”, diferentemente dos outros temas, estava tendo uma alta tendência no volume de atendimento, e principalmente com um dos nossos maiores parceiros.
Nós também falamos com agentes de atendimento (CX) para entender quais tipos de reclamações eles mais estavam recebendo dos consumidores.
Mais um pouco de contexto para você
Os usuários do EBANX de fato são os funcionários das empresas que nos contratam para lidar com o processamento dos pagamentos nos seus sites e apps. Mas nós temos também o que chamamos de usuário final, que são os consumidores dessas empresas. Qualquer problema que eles enfrentarem com o seu pagamento, vai prejudicar a experiência deles com os nossos parceiros, e se o EBANX não tiver ferramentas adequadas para lidar com esses problemas e também para ajudar os nossos parceiros a resolvê-los, isso impacta a experiência deles com a gente.
Por questões de compliance, os times de produto não conseguem entrar em contato diretamente com os consumidores para entrevistas, formulários ou testes. O time de Customer Experience era o que se comunicava diretamente com eles, e por isso eles foram uma ajuda essencial para a gente entender os problemas que os consumidores enfrentavam com as nossas soluções de pagamento.
Eu tive acesso ao Zendesk usado pelos agentes de CX, por onde pude ler tickets de atendimento e ter mais a perspectiva do usuário. Um dado interessante que coletamos durante o discovery é que a maioria dos consumidores que entravam em contato com a gente sobre o formulário já tinham passado por esse processo mais de uma vez. Ao analisar os tickets, o sentimento de frustração era muito evidente, da pessoa sempre tentar preencher o formulário, não conseguir enviá-lo e ter que entrar em contato com o EBANX.
Mapeando as dores
Enquanto eu e o PM fazíamos o mapeamento de dores dos usuários, o time de tecnologia envolvido no projeto também precisou fazer um discovery para conhecer as limitações técnicas que existiam no formulário atual.
No fim chegamos a dois grupos de dores:
Dores dos usuários
-
Não entender como completar o formulário;
-
Muitos campos para preencher, principalmente no formulário do Brasil;
-
Também no caso do Brasil, a Caixa Econômica estava mudando o número de algumas contas-poupança. Isso estava confundindo muitos usuários e foi uma das principais causas no aumento do atendimento.
Dores técnicas
-
O formulário era muito complexo e nenhum pouco flexível, tecnicamente falando. Qualquer mudança no código necessitava um intenso discovery técnico;
-
Nem todos os campos tinham limites de caracteres, o que poderia aumentar as chances de erros de preenchimento;
-
Havia um erro na validação do dígito das contas de um banco brasileiro que fazia o formulário exibir uma mensagem de “dígito inválido” mesmo quando o usuário o digitava corretamente.
Benchmarking
Mesmo analisando os materiais que já existiam, eu ainda tinha algumas incertezas sobre a melhor experiência para um usuário preencher dados bancários. Então resolvi fazer um benchmarking para saber como o mercado lida com esse tipo de tarefa.
Eu analisei competidores diretos, mas também pesquisei por jornadas de transferência bancária em bancos tradicionais e digitais.
Algumas das minhas dúvidas eram:
-
Existe alguma diferença de campos dependendo do banco selecionado?
-
Eles passam algum tipo de orientação para o usuário durante o preenchimento?
-
Como funciona a validação dos campos?
Wireframing
Depois desses estudos, desenhei um primeiro wireframe para demonstrar melhorias de usabilidade que poderiam ser feitas. Eu levei o wireframe para PM e tech para levantar pontos como “O formulário atual tem campos separados para conta e dígito. Podemos juntá-los?”
Essa conversa foi muito importante para a gente ter uma definição final do que o novo formulário poderia ou não ter de modificações, e o time de desenvolvimento até saiu dela com tarefas definidas. Inclusive, foi nessa mesma reunião que eu soube de uma informação fundamental para a etapa seguinte (que foi a minha favorita)!
“E se a gente criar um Design System, hein? 👀”
O assunto Design System sempre esteve nas rodas de conversa do time de Product Design e vontade (e necessidade) não faltava para fazer esse plano sair do papel. O que faltava mesmo era tempo de design e a disposição de algum time de desenvolvimento para embarcar com a gente nessa jornada.
Só que quando o tech lead e o dev desse projeto disseram que iriam refazer o formulário de reembolso montando todo o front-end do zero, essa foi a (única) oportunidade que eu vi da gente finalmente poder começar uma primeira versão de um DS, com componentes de formulário que funcionariam para esse projeto e também para vários produtos do EBANX.
Quando eu falei sobre isso na reunião, não houve nenhum tipo de resistência. Pelo contrário, o tech lead já tinha experiência com Design Systems e sempre se mostrou a favor de fazer isso acontecer. Já o dev nunca tinha trabalhado com DS, mas estava super disposto a aprender.
Como muitas coisas aconteceram antes e durante essa fase que levaram à criação de um Design System (inclusive um rebranding do EBANX!), eu achei melhor compartilhar esse processo em um case à parte.
Prototipando
Depois de desenhar os componentes de design que fariam parte do Design System, eu comecei a desenhar o protótipo em alta fidelidade do formulário no Figma.
Uma decisão importante que eu tomei logo no início foi de que o formulário seria divido em etapas, em vez de deixar todos os campos disponíveis de uma vez como no caso antigo. Isso é uma boa prática, mas a minha decisão foi muito pensando no que eu comentei anteriormente de que os usuários que preenchem o formulário já tiveram que passar por esse processo outras vezes, então quanto mais a gente pudesse reduzir a quantidade de campos por tela, menos maçante essa tarefa pareceria para o usuário.
Outro motivo para a divisão em etapas era a suposição de que, tendo menos campos visíveis, o usuário teria uma carga cognitiva menor e poderia se concentrar melhor no preenchimento de dados sensíveis, o que poderia reduzir as chances de erro.
Essa fase também foi compartilhada com o time, eu apresentei uma primeira versão do protótipo explicando todas as decisões de design tomadas e peguei os feedbacks de PM e desenvolvimento.
Testando
Rodar um teste de usabilidade depois de fazer o protótipo foi a etapa mais desafiadora para mim por algumas razões:
-
Não tínhamos autorização para recrutar consumidores dos nossos parceiros;
-
O projeto já estava se arrastando por mais tempo do que o planejado por algumas questões internas que alteraram as prioridades de entrega, então eu não tinha muito tempo disponível para os testes;
-
Testar um formulário no Figma com dados fixos não é a mesma coisa que observar o usuário digitando dados reais, ainda mais quando um dos objetivos do projeto é reduzir erros de preenchimento.
No entanto, o novo formulário era um projeto arriscado por estar sendo totalmente refeito, então eu preferi seguir com os testes mesmo nessas condições para ter dados que comprovassem que de fato estaríamos entregando uma usabilidade melhor do que no formulário anterior.
Os testes foram feitos de forma não moderada usando o Maze. Eu recrutei colaboradores do EBANX via Slack e conseguimos 48 respostas:
-
No geral, a experiência para as pessoas testadoras foi bem agradável, elas se sentiram confortáveis navegando pelo formulário.
-
De dados quantitativos, a taxa de sucesso foi de 90,6%, e a nota média para a facilidade de completar a tarefa foi 6.6 (escala de 1–7, sendo 7 “muito fácil”).
-
Nas respostas qualitativas, foi apontado várias vezes a quantidade de campos que elas precisavam preencher. Por mais que já tenhamos conseguido reduzir a quantidade, ainda há um espaço para melhorias nesse sentido.
Um ponto de atenção do teste foi o viés em algumas respostas qualitativas. Por mais que a tarefa estivesse focada em a pessoa imaginar que estava preenchendo os dados para o reembolso de uma compra que ela fez, por ela ser uma funcionária do EBANX ela acaba levando em consideração a expertise do seu cargo para dar uma opinião. Em algumas respostas qualitativas, eu pude perceber que tinhas pessoas de CX, engenharia e até Product Design.
Um aprendizado para fazer testes de usabilidade com funcionários seria segmentar o público para pessoas que não tivessem contato ou conhecimento sobre o fluxo a ser testado.
(Não) Acompanhando o desenvolvimento
Depois de compartilhar o resultado dos testes com o time e fazer ajustes nos protótipos com base nele, organizei o arquivo do Figma para o handoff. Vale lembrar que além de documentar o layout e os fluxos do formulário, para Brasil e países da América Latina, eu também tinha que especificar os componentes que seriam desenvolvidos, mas essa parte eu detalho mais no case sobre o Design System.
Como já haveria um esforço maior de desenvolvimento para a criação dos componentes, eu tentei ser o mais detalhista possível na documentação das telas e fluxos do formulário, para tentar facilitar a vida do desenvolvedor. Eu demonstrei as etapas do formulário, breakpoints do layout para mobile e desktop, os fluxos para Brasil e Latam com todas as as alternativas, possibilidades de erro e empty states.
 |  |  |
|---|
Para tornar a situação um pouco mais delicada, eu saí de férias no meio do desenvolvimento! Só que como o arquivo estava bem detalhado, não aconteceu nenhum problema durante essa etapa, bugs só ocorreram no back-end. Quando eu voltei de férias o formulário estava lá, prontinho para me receber!
Conclusão
Nesse momento o formulário para Brasil está na fase de rollout, sendo liberado aos poucos para os consumidores.
Exemplos de algumas métricas que estamos acompanhando:
-
Tickets de atendimento relacionados ao formulário de reembolso (objetivo de negócio: reduzir a quantidade em 50%);
-
Tempo médio de preenchimento;
-
Taxa de erro de preenchimento e seus motivos;
-
Taxa de abandono.
Um dos melhores aprendizados que eu tive com esse projeto foi de como faz diferença se sentir motivado com o que a gente está fazendo e ter alguém que compartilha esse mesmo sentimento. Nós tivemos diversos atrasos durante esse projeto por conta de problemas internos que fizeram a gente parar a iniciativa por um tempo para se dedicar a outras coisas. A entrega que era para Q2 foi para Q3 e acabou chegando mesmo no comecinho de Q4.
Mas veio! O resultado final ficou incrível e eu devo muito isso à parceria que eu tive com o Product Manager e o desenvolvedor. Por incrível que pareça, foi um projeto muito prazeroso para a gente e ainda entregamos um projeto de Design System junto que vai ser muito útil para futuras iniciativas.