De App Acessório a Banco Digital
Como um olhar holístico para a experiência do usuário gerou impactos para além do produto.
📖 Entendendo o Problema
O Contexto
O Quero-Quero Pag é um aplicativo de serviços financeiros que foi criado como um acessório digital do cartão de crédito das Lojas Quero-Quero. Com o tempo, foram implementadas novas funcionalidades, como Conta Digital, Pix, Seguros e Empréstimo.
Contudo, sem uma equipe de design dedicada ao produto, a interface provisória inicial não acompanhou a adição de novas funcionalidades e produtos, criando entraves na experiência do usuário. A taxa de adesão dos clientes estava baixa, a nota média nas lojas de aplicativos era insatisfatória e a conversão nos serviços oferecidos estava abaixo do esperado.
Estava claro que o aplicativo precisava de melhorias, e foi assim que o "problem statement" chegou até mim. Era evidente que se tratava de um problema mais complexo, exigindo uma investigação mais profunda.
Os Sintomas
Após algumas rodadas de conversas com os times de desenvolvimento, atendimento, negócio e diretoria, chegamos a uma lista mais concisa de gaps:
1. Inconsistência visual: a interface não apresentava padrões visuais consistentes, o que tornava o produto confuso até para os times internos.
2. Demora no lançamento: a implementação de qualquer mudança ou nova funcionalidade era extremamente custoso para o time de desenvolvimento, aumentando drasticamente o time-to-market do produto.
3. Reclamações sobre o produto: havia um grande número de reclamações ligadas a dificuldade de encontrar e até mesmo entender o funcionamento de operações básicas, como a fatura do cartão ou o extrato da conta, dentro do aplicativo.
4. Baixa adesão dos clientes da loja: apesar de agregar um hub de produtos e funcionalidades para os clientes da Loja, poucos deles estavam utilizando.
Fatiando o Problema
Durante as rodadas de conversas com os times, ficou muito claro que os gaps 1 e 2 estavam intrinsecamente ligados. Não havia um repositório com componentes reaproveitáveis, de modo que cada time desenhava isoladamente as features novas para o aplicativo. Isso não só prejudicava o processo de desenvolvimento e lançamento de cada nova funcionalidade em produção, como gerava inconsistências para o usuário final.
Era necessário então, que o projeto contemplasse a criação de uma biblioteca de componentes, com a padronização não só de elementos visuais, mas também de processos mais estruturados de handoff, rumo à criação de um design system. Isso resolveria grande parte, senão todo, do problema de time-to-market, traria mais consistência para o produto e melhoraria a experiência de imediato, contribuindo para resolver outros problemas da lista.
Essa decisão guiaria não só o meu processo de handoff, mas também as escolhas estratégicas que seriam tomadas para abordar o problema (ou o conjunto deles). Por isso, guarde essa informação com você, irei voltar nela daqui a pouco.
Para solucionar o terceiro ponto, optei por começar analisando os tickets de atendimento. Este era o maior repositório de dados qualitativos que a empresa possuía. Com a ajuda do time de SAC, categorizei e subcatecagorizei os chamados, colocando os dados em gráficos posteriormente.
Após fazer uma análise dos tickets, sobretudo das reclamações, entendi que os principais pontos de dor do usuário estavam ligados a: compreensão da fatura, gerenciamento de cartão de crédito, visualização do saldo e recuperação de senha.
Como essas eram funcionalidades básicas do aplicativo, supus que isso explicasse o ponto número 4, a baixa adesão dos clientes da loja. Mas essa era apenas uma suposição e precisava ser validada. Para além disso, surgiram novas perguntas que não eram sanadas com dados recolhidos até aquele momento ou com pesquisas feitas anteriormente.
✦ Quem eram esses clientes?
✦ Os clientes da Loja tinham um perfil diferente dos usuários do aplicativo?
✦ Eles usavam outros aplicativos financeiros? Quais?
✦ O que eles valorizavam em um app de pagamento?
✦ O que poderia torná-los usuários recorrentes?
Perguntas como essas, somadas a necessidade de validação das suposições sobre o ponto 4, me levaram a definir o processo do Triple Track Agile na abordagem desse problema.
O Processo: Triple Track Agile
Iniciei o projeto utilizando a abordagem clássica do Double Diamond, e até aquele momento, estava na fase de exploração, tentando definir o problema. Foi necessário dar um passo atrás, e é o Triple Track Agile que permite esse movimento.
O processo funciona de forma semelhante ao duplo diamante e também possui uma esteira dedicada ao discovery e outra dedicada ao delivery. No entanto, ao contrário do modelo tradicional, a abordagem considera essas etapas como parte da solução e não do problema. Além disso, a grande diferença - e vantagem - do Triple Track Agile é que ele possui uma terceira esteira. Antes do espaço da solução, há uma esteira anterior dedicada inteiramente ao espaço do problema. Nela, procuramos responder perguntas que nem sempre estão relacionadas diretamente ao produto, mas que garantem um discovery e um delivery saudável.
Contudo, ainda era necessário ter um design system ou algo nessa direção. Ficou acordado que eu desenvolveria uma primeira versão mais enxuta da biblioteca de componentes, abrangendo os que eram mais utilizados e de que a interface dependia mais.
Foram necessários 3 meses na construção da solução que sanaria os pontos 1 e 2 do problema, gerando percepção de valor imediata para os usuários e garantindo “tijolinhos” que poderiam ser facilmente customizados a depender das necessidades encontradas posteriormente. Após o handoff, eu teria tempo hábil de fazer a pesquisa exploratória enquanto os desenvolvedores implementavam a biblioteca.
🔍 1ª Esteira: Entendendo o Usuário
Data Personas: o ouro escondido dentro de casa
Iniciei o processo reunindo os dados de pesquisa que a empresa já possuía. Como a equipe de Data Science ainda estava em estruturação, foi necessário trabalhar em conjunto com as áreas de CRM, TI e Marketing.
Após um intenso trabalho de extração e modelagem de dados, foi possível clusterizar a base de usuários do aplicativo e cruzá-la com a base de dados de clientes da loja. A partir dos resultados obtidos, desenvolvi dashboards que possibilitaram uma visão mais clara da base de dados, sendo imprescindíveis para a definição de algumas data personas.
A clusterização dividiu os clientes em: Cluster A, clientes da loja e Cluster B, clientes da loja que também são usuários do app. Um terceiro cluster também foi descoberto, o de usuários do aplicativo que não eram clientes da loja. Por se tratar de um número muito pouco representativo, deixei para trabalhar nesse grupo em um outro momento de discovery.
Os clusters foram ainda divididos em grupos menores, que os separava pelo tipo de produto que utilizavam, como pessoas que possuiam crédito contratado e pessoas que não possuíam, por exemplo.
Pesquisa Exploratória: com quem estamos falando?
A partir das data personas, desenvolvi um questionário que seria aplicado de acordo com os clusters definidos anteriormente.
Os questionários tinham duas perguntas abertas no início, que variavam conforme os grupos gerados a partir dos clusters. A ideia era ter uma riqueza de dados que perderíamos caso oferecessemos alternativas prévias e, depois, agrupar as respostas por similaridade. O restante do roteiro tinha perguntas condicionais e fechadas, que certamente seriam mais fáceis de catalogar.
Como precisávamos de quantidade e de qualidade de resposta ao mesmo tempo, foi contratada uma empresa terceirizada para conversar com os clientes. Fiz o desenvolvimento do roteiro de perguntas e treinei a equipe para dar início ao processo.
Em 15 dias, a empresa terceirizada coletou informações de 1.000 clientes, um bom número. Para atestar a veracidade das respostas, escolhi aleatoriamente 3 pessoas de cada grupo e refiz o contato. Foi possível, inclusive, explorar mais alguns pontos em profundidade, e criar uma pequena - mas poderosa - fonte de dados qualitativa, que utilizei na próxima etapa de cruzamento.
Após catalogar as respostas dos mil clientes, desenvolvi um novo dashboard para visualizar padrões de comportamentos e extrair novos insights.
Insights: insumos para vários times
Os achados da pesquisa acabaram trazendo insumos para diversas áreas da companhia. Esse é o grande trunfo do user discovery, a primeira esteira do Triple Track Agile: os resultados têm uma vida útil maior do que as informações encontradas na fase de product discovery e alimentam não só a esteira de produto, mas toda empresa. É algo que leva mais tempo para ser feito, mas que traz muito mais clareza para evoluir o produto e que, provavelmente, não precisaria ser repetido pelo menos nos próximos dois anos.
Nesta etapa, fiz uso também do Atomic Research para chegar em insights assertivos. Este é um método bastante interessante pois permite quebrar os componentes da análise em pedacinhos e, através do cruzamento de múltiplas fontes de pesquisa, encontrar em padrões.
Após a análise e cruzamento destes padrões, pude chegar em insights que foram facilmente transformados em acionáveis.
Dentre os achados macro da pesquisa, constatei, que:
1. A maior percepção de valor, em todos os grupos, está ligada a funcionalidades básicas da conta (como visualização do saldo/extrato, pagamento de boleto e Pix), e do cartão (como visualização, controle e pagamento da fatura). Esses são pontos que precisavam funcionar bem para aumentar a retenção (principalmente entre os mais bancarizados) e a conversão em demais produtos dentro do aplicativo. O restante é complementar.
2. Existia uma percepção disseminada dentro da empresa de que os usuários não usavam o aplicativo porque eram mais velhos e não adeptos da tecnologia. A pesquisa mostrou que isso não era totalmente verdade. Havia sim, uma parcela de usuários mais velhos, mas esse não era o perfil predominante de usuários.
3. Diferentemente do que se pensava antes, existia abertura em quase todos os grupos, inclusive nos menos bancarizados, para o uso de aplicativos bancários e/ou de pagamento online. Nos grupos mais bancarizados, a tendência era o uso de mais de dois aplicativos ao mesmo tempo.
4. Sendo o principal ponto de contato com os clientes, as lojas da empresa não comunicavam de maneira eficaz a existência do aplicativo. Esse insight foi crucial para derrubar a hipótese de que os clientes não ativavam suas contas digitais porque não viam valor no serviço. Porque, na verdade, eles sequer sabiam dele. Seria necessário melhorar a conscientização sobre a sua oferta e sobre a existência do aplicativo como um todo.
5. Mesmo os usuários que usavam o aplicativo não faziam ideia da quantidade de funcionalidades e serviços que o mesmo oferecia. Seria, então, necessário um esforço não somente para melhorar a experiência dentro do produto, mas também para aumentar a consciência sobre suas funcionalidades.
6. As funcionalidades relacionadas ao principal produto financeiro do portfólio, o cartão de crédito, não ofereciam uma boa experiência ao usuário. Reforçando os dados que a primeira análise de tickets revelou, todos os grupos elegíveis da pesquisa por ligações relataram dificuldade para entender a linha do tempo da fatura, assim como outras informações importantes, como o limite disponível, a data de vencimento e se a fatura já tinha fechado ou não.
Personas
Com a pesquisa, também consegui evoluir as data personas para personas mais robustas. Ter esse artefato ajudou a dar clareza e direção ao processo. Agora, era possível enxergar para quem estávamos construindo, e as diferentes necessidades que cada uma dessas pessoas possuía.
Adicionar algumas sugestões de ações que poderiam ajudar cada persona também foi algo que facilitou os workshops de cocriação posteriores. Elas ajudaram a fomentar debates e ideias entre as partes interessadas.
💡 2ª Esteira: Descobrindo Soluções
Cocriando acionáveis
Apresentei os insights para os times participantes do projeto (negócio, marketing e desenvolvimento) e, através de alguns workshops, fomentei a criação de acionáveis em conjunto, para que pudéssemos cobrir todos os objetivos que precisaríamos alcançar com propostas macro que fossem viáveis.
No fim, tínhamos um quadro que deixava claro de onde cada objetivo estava partindo e quais oportunidades cada proposta endereçava.
Se voltarmos aos nossos pontos iniciais do problema - inconsistência visual, demora no lançamento, reclamações sobre o produto e baixa adesão dos clientes da loja -, podemos notar que já endereçamos os pontos 1, 2 e 4.
A baixa aderência dos clientes da Loja ao app, ponto número 4, revelou-se ser um sintoma de um problema de awareness, e não de experiência. Por esse motivo, foi extremamente importante envolver outras equipes no processo, como, por exemplo, o time de marketing. Algumas iniciativas acabaram virando projetos específicos de cada time e alguns deles eu tive a oportunidade de acompanhar e prestar auxílio, ainda que como facilitadora.
Acionáveis da experiência no produto
Contudo, eu ainda tinha soluções relacionadas a experiência dentro do produto para desenvolver. A adesão a serviços dentro do app, por exemplo, também estava intimamente ligada a awereness, só que nesse caso, dentro do próprio aplicativo.
Muitos usuários relataram não saber que ele oferecia conta digital e seguros, por exemplo. Além disso, o cartão, que possuia apenas a função crédito, passaria a ter a função débito. Isso trouxe a necessidade de dar mais protagonismo à conta digital, deixando-a no mesmo nível de importância do cartão de crédito.
Considerando essas informações e o sintoma inicial número 3, chegamos a uma lista final de acionáveis que a minha solução precisava atender. Em ordem de importância, eram eles:
✦ Comunicar - visual e verbalmente - como uma solução completa de aplicativo bancário para pessoas de todas as faixas etárias a partir de 18 anos, com médio a alto índice de bancarização.
✦ Trazer relevância, clareza e boa experiência para a conta digital.
✦ Melhorar a experiência das funções relacionadas ao cartão de crédito.
✦ Trazer clareza para os outros serviços disponíveis no aplicativo e ter uma arquitetura que os comporte.
✦ Oferecer os serviços certos para os usuários elegíveis.
✦ Trazer relevância ao e-commerce dentro do aplicativo.
✦ Trazer fluidez para o login.
✦ Trazer fluidez para o fluxo de solicitação de empréstimo.
E como o mercado está resolvendo essas demandas?
O fato é que, em relação a experiência do usuário, na maioria das vezes não é necessário inventar a roda. Uma das heurísticas de Nielsen nos confirma isso: o usuário passa a maior parte do tempo em outros sites. Então, a abordagem mais eficiente é aproveitar a curva de aprendizagem que ele já teve com padrões que já são praticados no mercado.
Tendo em vista que algumas funcionalidades core do aplicativo eram descritas como confusas, ter como referência outros players do mercado, principalmente os que foram citados na pesquisa, ajudaria a pensar em uma solução que pudesse ser nova, mas que também fosse inteligível e familiar para os usuários.
O benchmarking teve como foco áreas chave para o produto e para o projeto: o onboarding, arquitetura geral, área de cartões, conta digital, empréstimo, seguros e shopping.
As bases da solução
A solução ia além de um redesign visual e seria necessário alterar não somente os fluxos individuais, mas também a arquitetura do produto. Para isso, precisei trabalhar em um artefato que o produto ainda não tinha: um sitemap.
Com o sitemap montado, ficou mais fácil criar os tasks flows de cada sessão do aplicativo - que não eram poucas. Ficou mais simples também aprovar as soluções com cada time responsável individualmente. Isso economizava o tempo útil em reuniões e evitava que todos tivessem que participar de calls desnecessárias.
Analisando a viabilidade técnica
Junto com a equipe de TI, analisamos a viabilidade técnica das soluções que seriam efetivadas. Essa etapa foi imprescindível para alinharmos expectativas com as pessoas de negócio sobre o que era possível ser feito, mas que levaria mais tempo.
Após essa análise, elaborei uma matriz de priorização impacto x esforço para o processo, onde o eixo de impacto foi preenchido em conjunto com o time de negócios. Dessa maneira, foi possível também priorizar o que estaria dentro do primeiro protótipo já com uma ordem aproximada de desenvolvimento.
🎨 3ª Esteira: Agora Sim, Abra-te Figma
Visual: dando vida ao projeto
O redesign visual era algo que estava incerto no escopo do projeto, mas que foi confirmado como necessidade após a realização da pesquisa. Aliás, um dos seus acionáveis mais importantes passava pela boa comunicação do produto como um hub financeiro completo para pessoas de diferentes idades, sobretudo de 20 a 35 anos.
A possibilidade de um redesign de marca ou da criação de uma marca filha não estava em jogo naquele momento. O desafio então, era manipular os assets de uma marca bastante tradicional já existente para construir um visual dinâmico que dialogasse também com um público mais jovem e que ajudasse a posicionar o produto como uma solução completa de banco digital, e não apenas como um acessório.
Transformando em protótipos
Após o visual geral aprovado, trouxe para as reuniões uma versão mais avançada do task flow: um “wireflow”, só que com telas em alta fidelidade em vez de wireframes. Isso tangibilizou para os times até onde o projeto já tinha avançado até aquele momento e permitiu que modificações fossem sugeridas nesta etapa (e não no final).
Nesse sentido, foi essencial não só ter um projeto bem organizado no Notion, mas uma documentação estruturada no Figma. É natural que para um projeto tão grande - e que envolve o interesse de tantos times na empresa - se tenha várias etapas de aprovação e que, consequentemente, haja modificações a serem feitas.
O resultado foram dois protótipos navegáveis de alta fidelidade e prontos para testes com clientes de todas idades - inclusive com os menos adeptos à tecnologia - como esse:
Um pouco de improviso: testando com usuários
O teste de usabilidade também parecia uma etapa desafiadora. Ainda não havia orçamento aprovado para esse tipo de atividade, portanto os testes deveriam ser feitos de forma remota e sem recompensa para os participantes. Para resolver esses obstáculos, eu recorri a uma informação que a pesquisa também me trouxe.
Nas ligações da pesquisa exploratória, quando falamos diretamente com os clientes da Loja, muitos deles relataram ter um vendedor de confiança, a quem sempre recorriam quando precisavam comprar algum produto. Foi essa carta na manga que usei aqui. Através do contato com os vendedores, eu consegui alcançar clientes que tinham uma certa proximidade com eles e que gentilmente se dispuseram a participar dos testes.
Foram os próprios funcionários da Loja - e aqui fica o meu agradecimento público - que me ajudaram a fazer a ponte entre os clientes e cederam seus computadores para a realização dos testes dentro do espaço do estabelecimento. Eles também atuaram como uma assistência presencial importante para deixar os participantes seguros e confortáveis. E nesse sentido, também foi importante ter protótipos de alta fidelidade e com alta navegabilidade para diminuir qualquer fricção ou estranheza que as pessoas pudessem ter ao não contar com um ajuda especializada presencialmente.
Na grande maioria dos casos, o teste correu como previsto: eu enviava o link do protótipo para o cliente e pedia que ele compartilhasse a tela comigo enquanto eu fazia as perguntas. Mas como alguns computadores não abriam o Figma, eu precisei improvisar e, em alguns casos, abrir o protótipo no meu computador, espelhar a tela e pedir que os participantes me instruíssem sobre onde clicar.
No fim das contas, com um pouco de improviso, deu tudo certo. Eu consegui coletar dados valiosos para iterar os protótipos e chegar em uma solução final. Algumas funcionalidades foram tão bem aceitas que performaram com 100% de completude nas tarefas em todas as rodadas. Outras ainda precisavam de alguns ajustes.
Solução final
Feitas as modificações pós-testes, aprovei mais uma vez o design final com as equipes de negócio e a diretoria. Além de ter ótimos feedbacks, eu fiquei particularmente satisfeita por conseguir endereçar um problema complexo com sintomas diversos, uma lista de acionáveis grandes e pontos bastante doloridos para os usuários.
Acordos de handoff
A passagem de bastão para os desenvolvedores, o handoff, é a nossa linha de chegada (por hora). Como o projeto era grande, ela foi feita por “pacotinhos” e em documentos separados, conforme a priorização que fizemos na etapa de análise de viabilidade.
Adicionei os designs finais no nosso documento para que os stakeholders tivessem fácil acesso ao que foi acordado.
📊 Saldo Final
O processo foi longo, mas o resultado valeu a pena. Conseguimos enxergá-lo não somente nas métricas, mas em uma cadeia de impactos não contábeis que vimos refletir em toda a empresa.
Três meses após o lançamento da versão com a biblioteca de componentes, vimos a nota da Play Store aumentar em 0,3 pontos, indo de 3,9 para 4,2 em uma escala de 1 a 5. Também conseguimos diminuir em uma média de 25% o tempo de desenvolvimento de uma nova feature, reduzindo o time-to-market e economizando horas de trabalho.
Um mês após o lançamento da segunda release, a nota da Play Store aumentou em mais 0,4 pontos, indo para 4,6. Os tickets de reclamação e pedidos de ajuda com funcionalidades do app também começaram a baixar.
Além disso, consegui construir processos mais estruturados de colaboração com diversas equipes, principalmente com a de desenvolvimento, mas não só. Trazer todas essas pessoas comigo durante todo o processo foi essencial para alinhar expectativas, aplacar ansiedades, chegar a melhores ideias e fazer com que elas fossem compradas. Mas é mais que isso. O impacto na cultura também é algo que foi se tornando visível aos pouquinhos.
Ver os times de negócio passando a falar de pesquisa, de usuário e de usabilidade em uma empresa extremamente tradicional e conservadora, por exemplo, elucida bastante um impacto que eu considero tão valioso quanto as métricas de produto.
Participar deste projeto também foi sobre disseminar a cultura de UX por esta empresa e apresentar não somente as propostas de intervenção, mas o porquê de cada decisão e o processo para chegar até elas. Foi, essencialmente, colocar o cliente e “o cliente do cliente” como parte decisiva da solução.
