Como fomos dos relatórios quantitativos do SAC para insights qualitativos relevantes ao produto
Trabalhar como UX Researcher é representar a voz do usuário dentro da empresa e usar os insights para embasar as decisões de negócios e de design de um produto. No dia-a-dia estabelecemos quais meios de contato com nossos usuários iremos utilizar, testes de usabilidade, entrevistas em profundidade, surveys online… mas existe um meio bem simples que muitas vezes é esquecido, a central de atendimento ao cliente.
Aqui no PagSeguro PagBank os dados levantados pela central de atendimento são puramente quantitativos. São trazidas as principais dificuldades dos usuários em relação a produtos que já existem dentro da empresa em formato de relatórios. Pensamos então como colocar o foco na UX: a partir dos relatórios, definimos critérios para selecionar ligações, ouví-las e analisá-las. Esse processo nos permitiu transformar esses dados frios, com foco quantitativo, em um vasto material qualitativo trazendo empatia e informações mais aprofundadas ao time.
Aplicando esse processo notamos que a análise desses dados por um profissional de UX é muito rica para resgatar as nomenclaturas usadas pelos usuários, as maneiras encontradas de se resolver um problema por eles, os principais pontos de dificuldades dentro da jornada do usuário e as dores que se repetem independente de produto.
Pensando nisso, gostaríamos de compartilhar com vocês o processo que usamos internamente no PagSeguro PagBank para 1) analisarmos os principais motivos de contato dos clientes vindos de relatórios de atendimento 2) descrever como incluímos o time de design e de desenvolvimento nesse processo e 3) como transformamos esses motivos de contato em oportunidades de melhorias para nossos produtos.
São muitas ligações, por onde devo começar?
O primeiro passo foi pensar quais produtos seriam incluídos nessa análise e a partir daí resgatar os top motivos de atendimento de cada produto. No nosso caso, como estamos em uma área cross de uma das áreas de negócio do time, olhamos para todos os produtos dessa área. Selecionamos os top 5 motivos de cada produto e, em cada um dos motivos, usamos a premissa de Nielsen, “5 is the magic number”. Esse princípio afirma que para encontrar 85% dos problemas de usabilidade de uma interface é preciso de uma amostra de 5 usuários. Embora esse projeto não seja um teste de usabilidade assumimos o mesmo princípio para esse cenário. Por isso, selecionamos no mínimo 5 ligações de cada motivo de contato por produto e fomos aumentando o número caso o motivo não se repetisse.
Para seleção dessa amostra definimos:
- Um intervalo de tempo de 3 meses, pensando que sempre temos atualizações nos nossos produtos, um intervalo de tempo maior poderíamos resgatar dados já desatualizados;
- Variamos a região do usuário, pensando que temos produtos com promoções regionais;
- Horário e dia da semana da ligação, como as transações acontecem em horário comercial era preciso se preocupar com os horários para não resgatar apenas um tipo de problema.
Analisando as ligações
Para análise das ligações fizemos uma tabela no Notion, a qual trazia:
- Transcrição da ligação: queríamos resgatar as nomenclaturas utilizadas pelos usuários em relação as dificuldades que eles tinham
- Parecer do atendente: o que o atendente sugeriu para resolução do problema do usuário
- Categoria da dificuldade com viés do atendente: o problema descrito de uma forma mais genérica pelo atendente, como, por exemplo: dificuldade para realizar uma transferência
- Categoria da dificuldade com viés de design: o problema descrito de uma forma mais específica trazendo possíveis motivos do problema relacionado com a interface, como, por exemplo, dificuldade para realizar uma transferência devido a não visualização de adicionar contato.
A partir dessa tabela, fizemos uma jornada do produto trazendo os motivos de contato referentes ao local da jornada onde os usuários tiveram aquela determinada dificuldade. O objetivo aqui foi ilustrar os locais da jornada que tinham mais atrito. Essa jornada foi dividida em 3 momentos principais: o momento antes da utilização do produto, durante e depois de utilizá-lo.
Levando as dores para os times dos produtos
Pensando em compartilhar essas dores com o time, planejamos uma cerimônia mais dinâmica com o intuito de trocar conhecimento entre a área de design, produtos, desenvolvimento e atendimento. O objetivo aqui foi deixar todo mundo na mesma página e trazer tanto o conhecimento de atendimento para produto, quanto das ações realizadas pelo time de desenvolvimento para o atendimento. Assim, preparamos uma dinâmica com duração de 1h30min com o seguinte roteiro:
- Apresentação do contexto: objetivo do projeto, amostra, números de atendimento, frases dos usuários e jornada do produto;
- Discussão das dores: apresentação de cada motivo de contato e o local onde se encontrava na jornada do produto abrindo para discussão com os participantes (explanação da dor, o que já estava sendo feito a respeito, impacto para o usuário, limitações de desenvolvimento… );
- Criação das oportunidades: estipulamos um tempo (por volta de 15 minutos) para que os participantes criassem oportunidades de melhorias para cada uma das dores e posteriormente abrimos para discussão das mesmas;
- Votações das oportunidades: votação pelos participantes nas melhores oportunidades visando a experiência do usuário.
Essa cerimônia foi importante para levar as dores específicas de cada produto ao time, porém, percebemos que a maioria dos motivos de contato se repetiam independente do produto. Tendo em mente que a experiência do usuário é uma só e precisávamos unificá-la, sentimos a necessidade de uma análise secundária visando os motivos que se repetiam independente do produto.
Analisando as dores que se repetiam
Para essa análise reunimos todas as dores que tinham aparecido nos produtos e fizemos um agrupamento por afinidade, ou seja, independente do produto a qual pertenciam unimos as dores parecidas mantendo os momentos da jornada (antes, durante e depois). Dessa forma, tivemos uma visão de quais eram os momentos de maior atrito em uma jornada macro do usuário olhando para um contexto mais amplo.
A partir daí, percebemos que alguns motivos de contato também se repetiam independente do momento da jornada (antes, durante e depois). Pensando, então, em uma segunda dinâmica para gerar oportunidades que se aplicassem a todos os produtos e que fossem focadas em unificar a experiência do usuário, decidimos reunir essas dores por afinidade, independente de jornada.
Dinâmica de unificação de experiência
Para essa dinâmica, convidamos os designers do time de Design System e os designers alocados nos times dos produtos analisados. Uma preocupação aqui foi conduzir os participantes para olharem além dos próprios produtos pensando nos problemas independente do seu contexto.
A dinâmica teve a duração de 1h30min e foi dividida em 3 partes:
- Introdução e contexto: apresentação breve do que já foi feito no projeto e o objetivo da dinâmica;
- Explanação dos motivos de contato;
- Criação das oportunidades: voltado para que os participantes gerassem as oportunidades referentes a cada categoria das dores.
Para que as oportunidades geradas tivessem um melhor direcionamento e já saíssemos com uma priorização, dividimos-as em três classificações:
- Oportunidades: quando o participante observava que era preciso olhar para este caso, mas ainda não sabia muito bem a ação que pretendia fazer (mais genérica);
- Ações Quick Wins: quando o participante observava que era uma ação mais concreta a ser tomada em um curto período de tempo (ação pequena com impacto grande para a experiência do usuário);
- Ações Débito de Experiência: quando o participante observava que seria uma ação importante para o usuário, mas para ser realizada era preciso fazer experimentos e estudos para se aprofundar um pouco mais na ideia, ou seja, demoraria um pouco mais (ação que levaria mais tempo com impacto grande).
Documentação dos resultados
Posteriormente fizemos, então, um relatório endereçando as oportunidades referentes a cada motivo de contato, para que pudéssemos compartilhar com os designers e para que a liderança do time de design pudesse pensar em um plano de ação para que essas oportunidades fossem aplicadas nos produtos.
Considerações finais
Ao realizarmos esse projeto percebemos que através dos relatórios quantitativos de atendimentos podemos explorar e esmiuçar um universo de insights qualitativos. Levar para os times e aproximar as áreas de produto e atendimento nos fez perceber o quão rico é essa aproximação e essa troca de informações dentro de casa.
Pensar em dinâmicas que consigam atender às demandas dos times e já produzir materiais mais palpáveis (oportunidades já endereçadas com uma forma de priorização através da mensuração de esforços — quick wins e débito de experiência), possibilitou um melhor direcionamento das oportunidades e facilitou o processo de endereçamento para realização de ações de melhorias nos produtos.
Ainda estamos no processo de realização dessas melhorias, mas esperamos que com ações como essa consigamos diminuir as chamadas de atendimento e melhorar a experiência dos nossos usuários cada vez mais.
Aproveitamos para agradecer a todes (designers, POs, atendimento, desenvolvedores…) que participaram das etapas desse processo! ❤
