BANCO BV

Simulador de
Financiamento Solar

O Simulador de Financiamento Solar é uma ferramenta que o banco BV desenvolveu para que pessoas e empresas interessadas adquirir energia solar possam se auto-servir e solicitar uma proposta de financiamento com o banco, sem precisar acionar mais ninguém para isso. Além disso, ele é o primeiro canal próprio desenvolvido pelo banco, focado no cliente final.

Contexto

Atuando em parceria com integradores e correspondentes bancários (COBANs), o financiamento de energia solar é o segundo produto mais rentável do banco BV, atrás somente do financiamento de veículos. Nele, o banco atua como agente viabilizador da venda entre o cliente e o COBAN, liberando para ele o recurso financeiro que o cliente não tem de imediato.

No início de 2024 a diversificação do portfólio de produtos nesse segmento estava entre as estratégias do banco, junto com a recuperação da produção de renda, impactada em 2023 pela queda do ticket do produto devido ao barateamento dos materiais de geração de energia (placas e inversores) e entrada de novos players no ramo.

Apesar de ser líder do segmento, até então o banco não possuía um canal próprio captação, gerando dois fatores de risco que deveriam ser mitigados pela proposta de solução: a dependência excessiva (acima de 50%) de parcerias para gerar novas propostas de financiamento, e aumento da concorrência, com suas soluções próprias de captação.

Desenho de solução

Com o fluxo de evolução já consolidado e validado pelo time de desenvolvimento, o próximo passo era desenhar a interface da solução. Aqui o objetivo do usuário é consultar as condições de financiamento e enviar, sem ajuda de terceiros, uma proposta para análise do banco. Já o objetivo do banco é aumentar o número de novos financiamentos, agora em uma esteira própria.

Alcançados esses objetivos, o banco terá mais autonomia de gerar ações de marketing agora em um canal próprio de captação e conversão de leads, onde poderá também oferecer outros produtos de seu portfólio.

Dividimos o funil em três etapas principais: dados pessoais, dados do imóvel e simulação de financiamento; e começamos a trabalhar em cada um. Reduzimos ao máximo os campos da primeira coleta de dados para garantir que os leads que avançariam à próxima etapa estivessem aptos à contratação do produto. Além disso, começamos a oferecer, para os leads que por algum motivo, não fossem elegíveis, outros produtos do banco.

No segundo passo, os leads elegíveis informam os dados do imóvel onde querem ter energia solar e quanto gastam atualmente de conta de luz. Esses são dados importantes porque é com base neles que o gasto médio de energia é calculado e também é identificada a concessionária de energia, que varia de acordo com o município.

Dados coletados e processados, o usuário tem a prévia do seu financiamento no terceiro passo, com a recomendação de potência elétrica de acordo com seu gasto atual de energia, o valor total estimado do financiamento, e as opções de pagamento disponíveis, que o usuário pode manipular de acordo com suas necessidades e alterar a proposta em tela.

Quando encontra uma combinação que lhe atenda, ele pode encaminhá-la diretamente para o banco, que vai analisar e retornar com o resultado.

Testes com usuários

Após ciclos de feedback dos times de Negócio e Engenharia, rodadas de críticas de interface com outros designers do time UX e de Conteúdo, chegamos em uma proposta que poderia ser testada pelos usuários.

Nesses testes percebemos alguns problemas na proposta, como a coleta do tipo de imóvel do usuário, que gerou dúvida em quem mora em apartamento entre selecionar imóvel residencial ou condomínio. Outro ponto que apareceu foi que, para visualizar o detalhamento e a composição do valor a pagar, a maioria dos usuários, exibiram o modal do corpo da página de simulação.

Além disso, os usuários não perceberam que o valor total a pagar exibido em tela era alterado à medida que eles combinavam diferentes opções de parcelamento e carência.

Para resolver o problema do valor total de financiamento, redesenhamos o componente que o exibia, integrando-o na página de simulação em tamanho maior, com mais destaque ao lado de um CTA. Esse CTA também foi pensado à partir dos testes, com um texto simples e claro de que com ele o usuário encontra mais detalhes sobre o financiamento, como as taxas inclusas e o Custo Efetivo Total. Já para o tipo de imóvel, decidimos por não pedir a categoria nesse MVP.

Feitas as alterações, partimos para uma nova rodada de teste de usabilidade onde, de modo geral, a proposta teve bons resultados. Houve menções espontâneas sobre a facilidade de uso e autonomia para pessoas que pretendem adquirir energia solar, sem necessidade de contato com terceiros nesse momento da procura.

Os testes também trouxeram sugestões de melhoria que foram adotadas pelo time para os próximos desenvolvimentos, como:

inserir mais opções parcelamento, exibindo a taxa de juros de cada opção na tela de simulação;
inserir mais informações sobre o parceiro do banco que será responsável por contatar o lead e dar seguimento da proposta na tela de conclusão;
coletar de que forma o lead prefere ser contatado.
incluir uma estimativa, em dias, de quando esse contato acontecerá.

Incluídas essas informações, prosseguimos para o handoff da proposta ao time de Engenharia.

Acessibilidade

Tudo desenhado, validado e testado, restava entender com o Núcleo de Acessibilidade e Inclusão (NAI) como a proposta deveria ser documentada para garantir que nossos usuários com dificuldade visual também pudessem interagir com o Simulador. Importante dizer que essa preocupação não apareceu apenas na fase final do desenvolvimento, já que o NAI atua em paralelo com o time de Design System na criação e validação dos componentes usados na interface. Com isso reduzimos o esforço em adequações no protótipo após o desenho completo da solução.

Detalhamos tela a tela os elementos de interação possíveis ao usuário e, para cada um deles definimos 3 informações:

Rótulo do componente: é a definição da natureza daquele elemento de tela (um botão, um campo de texto, uma caixa de seleção, etc)
Rótulo semântico: é a forma como esses elementos repassam informações para leitores de tela. No nosso caso é o que o nosso usuário vai ouvir de seu leitor de tela assim que ele passar por cada elemento. Quanto mais claro e objetivo um rótulo semântico, menor a chance de confusão/dúvida para o usuário, tornando a experiência mais fluida, respeitando suas particularidades e dando-lhe mais autonomia.
Ação após dois toques: é o comportamento do elemento, indo de expandir ou recolher campo de preenchimento, marcar ou desmarcar uma opção até a ir para um determinado endereço).

Impacto

A entrega de design foi feita em JUN/24, e ainda não foi feita uma coleta de dados para comparação com as metas definidas e compartilhamento com o time. Muita coisa ainda pode ser melhorada na solução e seguimos desenvolvendo e lançando pequenas e frequentes iterações a cada trimestre.

Tagueamento

A essa altura, tínhamos um entregável definido e que provavelmente não seria mais alterado até o lançamento, então sentamos com a equipe de dados para alinhar tela a tela quais informações de navegação poderíamos coletar. Essa coleta é importante para dar ao time de Negócios visibilidade do comportamento dos leads ao longo do funil de vendas, permitir segmentação de amostragens (por perfil, documento, localização, etc), identificação dos motivos mais comuns de inelegibilidade, ranqueamento de opções de pagamento mais escolhidas por amostragem, além de também ajudar no mapeamento de pontos mais frequentes de abandono.

Meu papel: Discovery, Benchmark, Desenvolvimento de conceito, Prototipação e validação de solução.

Topo

Definindo o problema

O primeiro passo foi reunir os times de Negócio e Engenharia para entender as necessidades de cada área, os impedimentos técnicos e as expectativas sobre o resultado que a solução traria.

Depois, partimos para analisar como os outros players pensaram suas esteiras e soluções para cenários parecidos com o nosso e entender se haviam elementos em comum entre essas soluções.

Somando isso à como já coletávamos os dados necessários ao nosso motor de crédito, desenhamos a protojornada do usuário, estruturando sua evolução quando interagisse com a solução e mapeando os possíveis atritos e hipóteses de solução. Validamos esse desenho com os times, identificando no fluxo as ações do usuário (entrada de dados), comportamentos do sistema e possíveis prototipáveis.

Aqui, mesmo ainda sem nada visual da solução, o time já começou e ter uma amostra do funil que seria percorrido e da complexidade do seu desenvolvimento, o que é importante para que os times iniciem as adequações necessárias nos sistemas envolvidos também planejem os desenvolvimentos dos próximos trimestres.

Após algumas discussões chegamos em um fluxo mínimo que seria a base do MVP da solução. O passo seguinte foi, ainda junto com o time, estabelecer um cronograma de desenvolvimento, incluindo nele agendas de compartilhamento e validação de solução.