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.

Automação de resultados

Pra acabar com a palhaçada de ficar baixando planilha tratando dados usando isso aqui pra analisar:

Eu criei uma dashboard automatizada no Lovable que conecta os resultados do Hotjar com as nossas tabelas do Metabase para cruzar os votos e assuntos dos votantes com o MRR de suas respectivas empresas, reduzindo a análise em horas com o uso de filtros rápidos e visualizaçào de evolução do CSAT ao longo do tempo por temas.

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, já no mesmo quarter, iniciar os Discovery dos problemas mais latentes e gerar os outputs para do direcionamentos dos projetos do quarter seguinte.

Conclusão

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.

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!