Eu finalmente tomei vergonha na cara e resolvi escrever o meu case com as minhas próprias "mões" sem ficar pedindo pra IA. A IA aqui só corrigiu minhas burrices de português.

Papel: Product Designer
Impacto: +15 pontos percentuais CSAT (60 → 75) em 1 quarter através de melhor UX na coleta
Escopo: Otimização de coleta de dados via design de experiência e estrutura
Período: Q4 2024

Aqui vou te contar como uma mudança simples na pesquisa de CSAT nos deu um salto de 15p.p. na métrica, e pincelar como a nova estrutura abriu caminho pra resolver um problema latente de design, e como eu automatizei uma análise de planilha chata pra cara*** de fazer.

Contexto

Quando eu entrei na squad do produto de atendimento ao vivo omnichannel da Asksuite, o objetivo era matar a versão legado que já estava no ar desde 2018 e os usuários já estavam acostumados - chegando até a gostar dos seus bugs e seus erros de estimação. Quando você trabalha em um contexto como esse, qualquer melhoria ou correção de fluxo vai ser enxergada como "Mas que porr* é essa que vocês fizeram aqui?" e comentários como estes se tornam bem comuns:

"A versão antiga mais simples e objetiva"

• Spoiler, não era.

"design antigo era melhor"

• kkkk.

"O layout antigo era mais facil e mais limpo de visualizar. Achei essa atualização muito complicada de usar, acho que poderia voltar para a primeira versão"

• ...

Não dá só pra ignorar. Se tão reclamando é porque tá doendo — afinal, é a principal ferramenta de trabalho deles. A dor do novo sempre é uma dor, mesmo que tu mude pra melhor.

"prefiro muito mais o modelo antigo , este nos deixa totalmente perdidos"

Claramente, o título desse projeto é bait, afinal, a gente só sabia que estava ruim - antes de virar um churn - porque já existia a preocupação com o que os usuários pensavam. A pesquisa na tela querendo saber o que eles achavam os faziam se sentir parte do processo de melhoria contínua enraizada na forma de construir produto que a Asksuite já adotava. Mas não tem como trabalhar em cima de "saudades da minha ex" — se fosse bom de verdade não seria ex. A gente precisava de mais informação.

A antiga estrutura da pesquisa

A pesquisa que tava rodando já entregava um bom insumo. A primeira pergunta era recolher a nota, padrão, não tem erro: "O quão satisfeito você está com essa nova versão da plataforma?" - A clássica nota de 1 a 5. O problema era a segunda parte dela, onde o objetivo era identificar a concentração das dores dos usuários. A pergunta um pouco ambígua demais:

"O que te motivou a dar essa nota?"

A resposta se dava através de opções que o usuário poderia selecionar e essas opções não descreviam o assunto nem de forma positiva ou negativa, eram apenas uma palavra ou uma pequena frase para identificar qual era a área de impacto:

• Funcionalidades
• Interface
• Bugs
• Usabilidade
• Tempo para realizar as ações
• Filtros

Com isso, se eu dava uma nota 1 e selecionava "Interface", significava que a interface era ruim e foi isso que me motivou a dar nota 1. Mas se eu dava nota 5, significava que a interface era boa e por isso eu dei nota 5. Existe ainda outro universo onde quem dá nota 5 fica na dúvida — seleciono o que quero que melhore, ou algo que justifica minha nota boa? Isso fechava a porta pra que os próprios promotores apontassem alguma melhoria. Tinha o campo aberto no final, claro, mas a maioria das pessoas não escreve feedback por escrito se puder evitar.

O problema além da ambiguidade

Como os dados vinham de uma planilha e fazíamos o tratamento na mão, filtrar por assunto não era suficiente — era necessário cruzar cada assunto com as notas correspondentes para entender a intenção de quem votou.

O processo era bem demorado e pouco confiável: eram 3 versões de pesquisa, português, inglês e espanhol, tinha que traduzir e filtrar os dados de 3 planilhas diferentes pra só no fim desse processo todo descobrir que dos 165 votos em "Interface", 100 eram de insatisfeitos e 65 de satisfeitos. E aí você olhava pros 65 votos dos satisfeitos e... tá bom. Você acha a interface boa. Que insight isso me dá pra continuar melhorando? Nenhum. Era basicamente um afago no ego, demorado de extrair e pouco confiável.

Com o problema claro, as mudanças foram diretas — e a lógica aqui vai ser simples: cada problema, uma solução.

EBAP - Esforço baixo de alto impacto… (acabei de inventar kk)

Era necessário garantir que todos os votantes, sendo eles detratores ou promotores, tivessem naquele espaço a oportunidade de apontar melhorias. Essa era a prioridade, afinal mesmo que as coisas estejam bem boas, sempre dá pra melhorar. Nesse aspecto, o nosso maior problema eraa própria pergunta. A solução aqui foi simples, trocar a pergunta.

"O que você gostaria que fosse melhorado?"

Na nova pergunta não existe mais ambiguidade, todos os usuários, podem apontar melhorias (a não ser que pulem a pergunta, sempre acontece nas melhores famílias). Ah! E agora a gente só aceitava uma opção como resposta, dessa forma o usuário precisa escolher o que é mais latente (e filtrar célula com mais de uma informação é um inferno!).

Honestamente, se parasse aqui já tava bala.

Brigadeiro com granulados coloridos

Agora que a gente garantia que todos os feedbacks fossem um feedback de melhoria, dava pra dar um tapa nos tópicos dos problemas tornando-os mais granulares. Até porque como é que eu vou adivinhar o que o usuário queria dizer com "interface"? É design? É usabilidade? É cor? É informação excessiva? YOU TELL ME!

Pra resolver isso tive algumas preocupações:

• O usuário não quer ficar respondendo uma survey de 150 perguntas
• É preciso entender os tópicos, nem sempre as pessoas sabem o que usabilidade significa
• Às vezes a gente esquece o que comeu no café da manhã, então os subtópicos precisavam remeter ao tópico anterior, já que não era possível voltar pra etapa anterior.
• Já tínhamos pistas de quais assuntos tratar, mas e se estivéssemos errados? Ou se os problemas fossem mudando? Precisávamos prever isso também.

Na nova estrutura o respondente selecionava apenas um tópico. A partir daí, isolamos cada subtópico em uma etapa separada — se o usuário escolhesse Design, só veria os subtópicos de design.

Olha a boca, rapaz!

Nós também evitamos jargões técnicos, e optamos por palavras que já vinham aparecendo nos feedbacks ou pedidos de suporte. Ninguém relata problema de usabilidade escrevendo "usabilidade", mas a palavra bugs (apesar de um termo técnico) já havia sido adotada pelos usuários.

Sobre usabilidade: "Está muito ruim para visualizar as conversas pendentens. A forma de realizar a cotação está ruim também"

Já sobre bugs: "Ao puxar a conversa para nos buga e temos que atualizar a pagina para voltar ao normal."

Com isso, os tópicos foram escritos da seguinte maneira: "O que você gostaria que fosse melhorado?"

• Correção de bugs
• Novas funcionalidades (antes era só "Funcionalidades" — abria espaço pra interpretar como reclamação de funcionalidades existentes, pedido de novas, ou as duas coisas)
• Velocidade nas ações
• Ser mais fácil de usar (a usabilidade, em palavras de gente)
• Design da tela

Já com os subtópicos a ideia foi reforçar o tópico anterior, para que o usuário não se perdesse e respondesse de forma aleatória.

Pra finalizar

O resultado prático dessa atualização foi sentido antes do fim do primeiro mês. A visibilidade dos assuntos selecionados nos permitiu no mesmo quarto já iniciaram Discovery dos problemas mais latentes gerando os outputs para do direcionamentos dos projetos do quarter seguinte.

Print do compilado dos votos por tópicos e subtópicos nos primeiros 30 dias do CSAT 2.0

A gente tende a achar que o projeto de maior impacto vai ser um daqueles que você vai gerenciar um discovery de 7 meses com 2 focus group diferentes e mais 170 testes de usabilidade etc etc etc… Mas trouxe esse case pra ajudar a refletir que as vezes a mudança de maior impacto pode ser a mais barata. Sem dúvidas esse foi o projeto mais importante até agora, pois foi ele que possibilitou os melhores acertos que fizeram com que o CSAT pulasse de 60 para 75 de um quarter para o outro.

Conclusão

O projeto mais impactante não é sempre o mais complexo. Aqui, uma mudança estrutural simples na pesquisa de satisfação viabilizou a identificação precisa de um problema (cores da tela) que resultou em:

• +11.47pp CSAT geral
• +14.15pp CSAT Enterprise
• Sistema de tokens escalável que beneficia todo o design system
• Economia de >3 horas/semana em análise manual
• Roadmap clara para quarters futuros

No mais, espero que tenha sido uma leitura interessante (já que foi escrita por um humano de verdade) e que de alguma forma te ajude a ter ideias para melhorar os processos aí na sua empresa ou na sua equipe. Valeus!

(Talvez eu atualize isso aqui!)