Função UX | UI Designer
Equipe Rafael Ávila (UX | UI Designer), Agustina Cabral (PO) e Débora Figueredo (Diretora de produtos).
Conclusão Versão 1 - 2022 | Versão 2 - 2023
Plataformas iOS, Android e Web
Introdução 🧭
A BaaS2u é uma fintech focada em construir soluções financeiras para diversos mercados, resolvendo as principais dores de grandes redes e ainda gerando novas fontes de receitas com produtos financeiros customizados. Atualmente conta com tecnologia proprietária e disponibiliza seus produtos financeiros para os usuários em aplicativo (app) e internet banking (IB) no modelo white label, o que possibilita ao contratante, ter os produtos financeiros que oferecemos com a identidade visual de seu negócio.
Por ser uma empresa nova no mercado, ainda passamos por um período de desenvolvimento e otimização de vários produtos. Mesmo assim, em menos de 4 anos e com uma equipe de 4 pessoas na área de produtos e 5 na área de tecnologia (devs), conseguimos desenvolver e disponibilizar mais de 10 produtos financeiros aos nossos usuários; produtos dos quais 7 deles tive a oportunidade de colaborar em todos os processos de design.
Esse case específico é referente a um produto desenvolvido para suprir a necessidade de um cliente que tinha um alto volume de pagamentos por mês. Entendendo que essa era uma demanda comum do nosso público de interesse, priorizamos o desenvolvimento da funcionalidade de pagamentos em lote e esse é o projeto que apresentarei a seguir.
O negócio 💼
A BaaS2u é mais que um bank as a service, além de criar toda a estrutura e disponibilizar a tecnologia necessária para um banco, também desbloqueia todo o ecossistema financeiro do cliente, através da centralização de todos os serviços, produtos, tecnologia e pessoas necessários.
Oferece aos seus clientes diretos uma gama de oportunidades de se obter receita com o próprio ecossistema financeiro, através de um modelo de negócio profit share e monetização 360, que envolve take rate sobre as tarifas transacionais; tarifas periódicas; float sob o saldo aplicado; entre outros. Além disso, todo o ecossistema da rede pode ter acesso a benefícios diferenciados, o que ajuda a fomentar toda a cadeia e construir um ecossistema mais sustentável.
A fintech desenvolve soluções financeiras para ecossistemas de qualquer nicho, mas cria produtos pensados para as dores individuais de cada segmento. Dentre seus produtos financeiros estão: Conta digital, maquininhas (POS), cartão de débito e crédito, Pix, pagamento de boleto, transferência interna e emissão de cobrança.
Problemas 🌡️
→ Nosso maior cliente tinha uma dor latente que ainda não conseguíamos sanar, um grande volume de pagamentos por mês que, através de nossa solução, teriam que ser feitos individualmente;
→ Pela ausência de uma solução que sanasse essa dor, nossos usuários utilizavam o produto de um banco concorrente que fornecia uma solução adequada;
→ Os usuários já utilizavam um sistema integrado de gestão empresarial (software ERP) que gerava um arquivo com as especificações correspondentes ao banco concorrente, então, para o nosso usuário, trocar o banco liquidador de seus pagamentos significava também realizar uma nova implementação com seu sistema ERP;
→ No primeiro momento não conseguiríamos desenvolver uma solução que sanasse 100% a necessidade dos usuários pois para o primeiro MVP só seria possível realizar pagamentos em lote via transferência interna, portanto, todas as contas a pagar deveriam estar dentro do nosso ecossistema bancário;
→ A necessidade de nosso cliente contemplava as jornadas de dois tipos diferentes de usuários, um usuário que faria a solicitação de pagamentos (que seria o colaborador da área de recursos humanos da empresa) e um usuário que faria a autorização dos pagamentos (o colaborador da área financeira), o que trouxe um pouco mais de complexidade ao produto.
→ Pela ausência de uma solução que sanasse essa dor, nossos usuários utilizavam o produto de um banco concorrente que fornecia uma solução adequada;
→ Os usuários já utilizavam um sistema integrado de gestão empresarial (software ERP) que gerava um arquivo com as especificações correspondentes ao banco concorrente, então, para o nosso usuário, trocar o banco liquidador de seus pagamentos significava também realizar uma nova implementação com seu sistema ERP;
→ No primeiro momento não conseguiríamos desenvolver uma solução que sanasse 100% a necessidade dos usuários pois para o primeiro MVP só seria possível realizar pagamentos em lote via transferência interna, portanto, todas as contas a pagar deveriam estar dentro do nosso ecossistema bancário;
→ A necessidade de nosso cliente contemplava as jornadas de dois tipos diferentes de usuários, um usuário que faria a solicitação de pagamentos (que seria o colaborador da área de recursos humanos da empresa) e um usuário que faria a autorização dos pagamentos (o colaborador da área financeira), o que trouxe um pouco mais de complexidade ao produto.
Soluções 💊
→ Desenvolvimento do produto de pagamento em lote em duas etapas:
- O MVP1 possibilitou o pagamento em lote de apenas um tipo de transação (transferências internas), criação de perfis de acessos diferenciados (solicitante e autorizante), upload de arquivo remessa, acesso diferenciado à informação de acordo com o perfil de usuário, download de arquivo retorno, download de comprovante de pagamento em lote e download de comprovantes individuais por transação efetuada;
- O MVP1 possibilitou o pagamento em lote de apenas um tipo de transação (transferências internas), criação de perfis de acessos diferenciados (solicitante e autorizante), upload de arquivo remessa, acesso diferenciado à informação de acordo com o perfil de usuário, download de arquivo retorno, download de comprovante de pagamento em lote e download de comprovantes individuais por transação efetuada;
- O MVP2 possibilitou, além das features já liberadas na primeira versão, o pagamento de boletos e pix, análise de erros no processamento do pagamento (referentes ao preenchimento do arquivo remessa), identificação do usuário que autoriza o pagamento nos comprovantes gerais e exclusão de arquivos;
→ Já na primeira versão do produto, nós sanamos quase que por completa a dor principal de nosso cliente, já que todos os funcionários CLT abriram conta no banco e já poderiam receber seus pagamentos via transferência interna;
→ O modelo do arquivo de remessa que utilizamos na configuração e como regra do produto foi o CNAB 240, um padrão determinado pela FEBRABAN (Federação Brasileira de Bancos) com o qual nosso cliente já estava habituado a trabalhar anteriormente.
→ Após o desenvolvimento e testes do produto, elaboramos um manual de implantação para o cliente. Além disso, nossa equipe de tecnologia deu todo o suporte para o cliente, na implantação do produto, junto ao fornecedor do software de gestão contábil. Nós de produtos também acompanhamos de perto a implantação e demos todo o suporte para o cliente durante o processo.
→ O produto conta com dois módulos independentes: solicitação de pagamentos em lote e autorização de pagamentos em lote. Cada módulo pode ser acessado individualmente por um perfil de acesso individual, com informações e ações restritas ao tipo de usuário; mas existe também uma categoria de "usuário master" que acessa os dois módulos do produto e todas as informações e ações.
→ Já na primeira versão do produto, nós sanamos quase que por completa a dor principal de nosso cliente, já que todos os funcionários CLT abriram conta no banco e já poderiam receber seus pagamentos via transferência interna;
→ O modelo do arquivo de remessa que utilizamos na configuração e como regra do produto foi o CNAB 240, um padrão determinado pela FEBRABAN (Federação Brasileira de Bancos) com o qual nosso cliente já estava habituado a trabalhar anteriormente.
→ Após o desenvolvimento e testes do produto, elaboramos um manual de implantação para o cliente. Além disso, nossa equipe de tecnologia deu todo o suporte para o cliente, na implantação do produto, junto ao fornecedor do software de gestão contábil. Nós de produtos também acompanhamos de perto a implantação e demos todo o suporte para o cliente durante o processo.
→ O produto conta com dois módulos independentes: solicitação de pagamentos em lote e autorização de pagamentos em lote. Cada módulo pode ser acessado individualmente por um perfil de acesso individual, com informações e ações restritas ao tipo de usuário; mas existe também uma categoria de "usuário master" que acessa os dois módulos do produto e todas as informações e ações.
Metodologias ⚙️
→ Desk research;
→ Benchmarking;
→ Entrevista com usuários;
→ Mapeamento da jornada dos usuários;
→ Definição de histórias de usuários;
→ Definição dos critérios de aceitação;
→ Wireframes iniciais;
→ Desenho de interface;
→ Prototipação;
→ Testes com usuários;
→ Testes funcionais do produto;
→ Treinamento de uso do produto.
→ Benchmarking;
→ Entrevista com usuários;
→ Mapeamento da jornada dos usuários;
→ Definição de histórias de usuários;
→ Definição dos critérios de aceitação;
→ Wireframes iniciais;
→ Desenho de interface;
→ Prototipação;
→ Testes com usuários;
→ Testes funcionais do produto;
→ Treinamento de uso do produto.
Fluxograma da experiência do usuário solicitante ✏️
Fluxograma da experiência do usuário autorizante ✏️
Desenho da interface 💻
Para a UI do produto de pagamento em lote utilizamos o style guide da plataforma (internet banking) e desenvolvemos alguns componentes e elementos novos para suprir a necessidade do produto.
Resultados obtidos 📊
→ Mais de 300 pagamentos realizados mensalmente com o produto;
Pontos de melhoria ⚠️
→ O produto foi originalmente pensado para suprir uma demanda do cliente citado no case, porém, o objetivo foi desenvolver uma funcionalidade que tivesse relevância e com a possibilidade de uso de outros clientes e tipos de usuários. Entretanto, quanto à acessibilidade, o produto tem uma grande limitação, já que para que se possa usá-lo é necessário utilizar um software externo para a geração dos arquivos remessa;
→ O produto apresenta uma tabela com uma análise superficial dos erros, informando apenas a linha da planilha com erro e o documento do recebedor relacionado ao erro. A tabela não apresenta ao usuário as mensagens de erro específicas, relacionadas a cada erro de processamento de pagamento, dificultando a recuperação do usuário;
→ Após subir o arquivo remessa no sistema, só é possível conferir os dados gerais do lote e não as informações específicas de cada transação contida no lote.
→ O produto apresenta uma tabela com uma análise superficial dos erros, informando apenas a linha da planilha com erro e o documento do recebedor relacionado ao erro. A tabela não apresenta ao usuário as mensagens de erro específicas, relacionadas a cada erro de processamento de pagamento, dificultando a recuperação do usuário;
→ Após subir o arquivo remessa no sistema, só é possível conferir os dados gerais do lote e não as informações específicas de cada transação contida no lote.
Principais aprendizados 💡
→ Nas entrevistas com os usuários e nos treinamentos do produto foi possível compreender melhor o ecossistema que utilizaria a solução. Foi possível perceber comportamentos, preocupações e até foi possível captar uma resistência dos usuários em relação a implantação do produto. Essas observações foram passadas para o time de relacionamento e passamos a tratar essa base de usuários com mais atenção e tato.
→ Esse foi o primeiro produto mais complexo que desenvolvemos em equipe e ao longo do projeto estruturamos alguns processos, entendemos nosso ritmo de trabalho em equipe e criamos uma boa cultura e rotina de trabalho.
→ Esse foi o primeiro produto mais complexo que desenvolvemos em equipe e ao longo do projeto estruturamos alguns processos, entendemos nosso ritmo de trabalho em equipe e criamos uma boa cultura e rotina de trabalho.
