Quais métricas medem a experiência do usuário

A pergunta costuma aparecer depois do investimento. O time redesenhou um fluxo, mudou onboarding, criou uma nova área, simplificou uma operação importante. Alguém pergunta:

Melhorou?

E ninguém consegue responder. Nesse momento acontece algo previsível. O time abre o analytics e procura um número que tenha se movido. Usuários ativos aumentaram, tempo de sessão caiu, chamados diminuíram, conversão subiu. Algum deles talvez seja relevante. Mas existe uma diferença entre ter uma métrica e ter uma métrica que responde à pergunta.

Medir experiência começa antes do dashboard: o que deveria acontecer de diferente para o usuário se essa mudança realmente fosse melhor?

MAU não é uma métrica ruim. Só responde outra pergunta.

Usuários ativos mensais pode ser um número extremamente importante para um SaaS. Ele ajuda a acompanhar tamanho da base ativa e pode indicar crescimento, queda, sazonalidade ou mudança de comportamento. O problema é usá-lo para concluir algo que ele não consegue isolar. Imagine:

Janeiro: 20 mil MAU
Fevereiro: 24 mil MAU

O redesign funcionou? Talvez. Mas vendas também fechou novas contas, uma campanha começou, um cliente grande expandiu a operação, ou houve um evento externo que trouxe usuários de volta.

No paper que apresentou o HEART, os próprios autores discutem essa limitação de métricas de usuários ativos: uma contagem pode aumentar mesmo com mudanças importantes na composição da base e sem explicar se as pessoas estão mais comprometidas com o produto. MAU responde “quantas pessoas classificadas como ativas tivemos?”. Não necessariamente “esta experiência ficou melhor?”. São perguntas diferentes.

Tempo de sessão também não possui direção universal

Imagine que o tempo médio para usar seu produto caiu 30%. Bom? Se você vende streaming, talvez não. Se você vende software para conciliação financeira, talvez seja excelente. Agora imagine que aumentou. Pode significar que as pessoas estão mais engajadas — ou que a tarefa ficou mais difícil.

A métrica não possui significado independente da intenção do usuário. Em software de produtividade, muitas vezes o melhor resultado possível é justamente a pessoa conseguir terminar e ir embora. Por isso uma métrica não deveria ser escolhida porque parece associada a “engajamento”. Ela precisa representar o resultado que aquela experiência pretende produzir.

Chamados de suporte também precisam de contexto

Outro exemplo tentador:

Depois do redesign, os tickets relacionados ao fluxo caíram 25%.

Essa é uma evidência interessante. Não uma conclusão completa. Talvez o produto tenha ficado mais fácil, a documentação tenha melhorado, menos pessoas estejam utilizando aquele fluxo, o suporte tenha mudado a categorização, um problema técnico tenha desaparecido ou os usuários tenham encontrado outro caminho. É possível até haver desistência silenciosa — mas não dá para assumir isso apenas porque os chamados caíram.

O número precisa ser cruzado com o comportamento que você realmente queria mudar. Se conclusão aumentou, erros diminuíram e chamados caíram, a história fica muito mais convincente.

Um teste simples para uma métrica

Pergunte: consigo imaginar um cenário ruim em que este número melhora? Se a resposta for sim, isso não torna a métrica inútil. Mostra que ela provavelmente precisa de contexto ou de outra métrica ao lado.

Exemplo:

Tempo até concluir caiu.

Ótimo. Mas talvez as pessoas estejam abandonando antes e apenas quem encontra facilidade permaneça na amostra. Então olhamos também conclusão. Outro:

Uso da automação aumentou.

Ótimo. Mas talvez ela esteja gerando mais erros. Então existe um guardrail.

Essa lógica é próxima do que os autores do HEART chamam de escolher sinais sensíveis e específicos ao objetivo: os sinais deveriam mudar quando a experiência relevante muda, e não principalmente por razões não relacionadas.

HEART organiza cinco famílias de métricas de experiência

Em 2010, Kerry Rodden, Hilary Hutchinson e Xin Fu, do Google, publicaram no CHI o trabalho Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications. Dali veio o framework HEART: Happiness, Engagement, Adoption, Retention e Task Success.

O mais importante é entender que essas não são cinco métricas específicas. São cinco categorias a partir das quais cada produto pode definir métricas adequadas aos próprios objetivos.

Happiness: o que a pessoa percebe

Happiness trata de atitudes: satisfação, facilidade percebida, percepção de qualidade, confiança, disposição para recomendar. Esse tipo de informação normalmente precisa ser perguntado. Pode vir de survey dentro do produto, pesquisa periódica, questionário após uma tarefa ou estudo específico.

Nenhum evento de analytics consegue observar diretamente:

esta pessoa sentiu que o processo era fácil.

É possível inferir comportamento. Percepção precisa ser medida como percepção. O paper original cita satisfação, apelo visual, intenção de recomendação e facilidade percebida como exemplos dessa categoria.

Engagement: quão intensamente a pessoa interage

Engagement tenta representar o nível de envolvimento por meio de comportamentos como frequência, intensidade e profundidade de interação. Exemplos poderiam ser dias ativos por semana, quantidade de ações importantes, volume de conteúdo produzido, frequência de determinado comportamento.

Existe uma ressalva particularmente importante para SaaS B2B. Os próprios autores do HEART observam que Engagement pode não ser uma métrica significativa em alguns produtos enterprise, porque o usuário é obrigado a utilizar o sistema como parte do trabalho. “Operador entrou todos os dias” pode significar enorme valor — ou simplesmente que esse é o sistema que a empresa obriga a usar. Nesse contexto, completar a tarefa com menos esforço pode ser muito mais importante que aumentar frequência.

Adoption: quem começou a usar

Adoption acompanha novos usuários começando a utilizar um produto ou funcionalidade dentro de determinado período. Só que existe uma pergunta escondida: o que significa “adotar”? Abrir a tela? Clicar? Configurar? Executar a primeira ação de valor?

A definição muda conforme o produto. O próprio paper dá esse cuidado: em um caso, visitar pode contar como adoção; em outro, só faz sentido considerar que alguém adotou depois de completar uma tarefa relevante. Por isso “70% abriram a página” não é necessariamente “70% adotaram a funcionalidade”.

Retention: quem continua usando quando faz sentido continuar

Retention acompanha se usuários presentes em um período continuam presentes em períodos posteriores. De novo, a janela precisa conversar com o produto. Uma funcionalidade diária pode exigir leitura semanal. Uma rotina de fechamento financeiro talvez faça mais sentido mês contra mês. Algo relacionado a renovação pode exigir meses. Não existe D7 ou D30 universal.

E, como discutimos em Como medir o sucesso de uma funcionalidade, repetição também só é uma boa medida quando a própria tarefa deveria se repetir. Uma configuração feita uma vez pode gerar enorme valor sem qualquer “retenção da feature”.

Task Success: a pessoa consegue realizar a tarefa?

Aqui entram algumas das métricas clássicas de usabilidade. Efetividade: conseguiu concluir? Eficiência: quanto esforço ou tempo foi necessário? Erros: quantos ocorreram durante a tarefa? O paper cita exemplos como tempo para completar, percentual de tarefas concluídas e taxa de erro.

Para fluxos com início e fim claros, essa categoria costuma ser extremamente útil. Imagine: criar primeira cobrança, cadastrar beneficiário, enviar transferência, configurar integração, adicionar usuário. Agora conseguimos observar o que aconteceu durante uma tarefa concreta.

Task Success não precisa sair apenas do analytics

Esse é um detalhe importante. Alguns fluxos são muito fáceis de instrumentar:

começou aqui → passou por estas etapas → concluiu aqui.

Outros não. Imagine um dashboard aberto em que a pessoa pode comparar, investigar, filtrar, navegar, tomar uma decisão e sair. Só o log talvez não revele qual tarefa ela estava tentando realizar. O próprio trabalho original menciona estudos remotos de usabilidade e benchmarking como formas de medir Task Success, justamente porque logs nem sempre permitem reconstruir a intenção do usuário. Então a fonte da métrica depende da pergunta. Analytics é uma delas. Não a única.

HEART não significa colocar cinco KPIs num dashboard

Os próprios criadores dizem explicitamente que nem sempre é apropriado usar métricas de todas as categorias. Isso importa. Não existe obrigação de acompanhar uma métrica de cada letra. Pode ser que um projeto precise principalmente de Task Success + Happiness. Outro, de Adoption + Task Success. Outro, de Retention + Happiness. O framework serve para ampliar a conversa e ajudar a fazer escolhas explícitas. Não para criar cinco gráficos obrigatórios.

Goals, Signals, Metrics é a parte mais importante

O HEART costuma receber mais atenção porque o nome é memorável. Mas o processo que os mesmos autores apresentam junto dele talvez seja ainda mais útil: Goals → Signals → Metrics. A ordem importa.

Goal

O que estamos tentando melhorar para o usuário? Não “aumentar conversão” — ainda é amplo. Algo como:

novos clientes devem conseguir concluir a primeira cobrança sem depender de suporte.

Agora existe experiência.

Signals

Se isso estiver acontecendo, o que conseguiremos observar? Talvez mais pessoas terminem, levem menos tempo, voltem menos etapas, encontrem menos erros, relatem mais confiança, peçam menos ajuda. Aqui ainda não precisamos decidir exatamente qual gráfico será usado. Estamos descrevendo sinais.

Metrics

Agora transformamos os sinais escolhidos em medidas:

percentual de contas elegíveis que concluem a primeira cobrança sem assistência;

mediana do tempo entre início e conclusão;

percentual que encontra erro bloqueante;

facilidade percebida após concluir.

Esse é o momento de abrir o analytics. Não antes.

Começar pelo dashboard inverte a lógica

Um time possui Amplitude, Mixpanel ou GA. Já existem sessões, pageviews, usuários ativos, eventos, tempo médio. Então a conversa começa:

quais desses números podemos usar para provar que o redesign funcionou?

Esse é o caminho inverso. Você está procurando uma pergunta compatível com o dado que possui. Os autores do HEART começam justamente pelo objetivo porque uma métrica user-centered continua sendo pouco útil se não estiver explicitamente relacionada a um objetivo. A pergunta deveria ser: o que precisaríamos saber? Depois: já coletamos isso? Se não, instrumentamos ou usamos outro método.

Nem sempre existe uma métrica única de UX

Existe uma tentação de perguntar:

qual é a métrica de experiência do nosso produto?

Provavelmente não existe uma só. Imagine uma fintech B2B. Uma tarefa importante é:

localizar uma transação e entender por que foi recusada.

Você poderia acompanhar Task Success (percentual que encontra a transação e identifica o motivo correto), eficiência (tempo necessário) e Happiness (facilidade percebida). Agora outra experiência:

configurar uma integração pela primeira vez.

As métricas relevantes mudam. Experiência acontece em tarefas e jornadas específicas. Um KPI único tende a apagar essas diferenças.

Também não existe uma categoria HEART obrigatoriamente superior

Eu evitaria a regra “sempre comece por Task Success”. Ela funciona muito bem em vários fluxos operacionais. Não em todos. Imagine que a principal pergunta seja:

o redesign mudou a confiança que clientes têm na área financeira?

Task Success pode estar igual. A experiência percebida mudou. Happiness talvez seja mais sensível à pergunta. Agora: “clientes estão descobrindo nossa nova automação?” Adoption pode vir primeiro. Ou: “clientes continuam utilizando após três meses?” Retention. O objetivo escolhe a categoria. Não o contrário.

Adoption baixa não é automaticamente problema de descoberta

Outro diagnóstico que parece conveniente:

Adoption baixa, Retention alta. Então é descoberta.

Pode ser. Também pode significar que a funcionalidade é relevante para pouca gente, que o trigger acontece raramente, que o segmento elegível foi definido errado, que existem pré-requisitos, que o valor não está bem comunicado — ou que o produto realmente esconde a feature. A métrica reduz as hipóteses. Não entrega automaticamente a causa.

Da mesma forma, “Adoption alta, Retention baixa” pode apontar problema de valor. Mas também pode ser uma funcionalidade que deveria ser usada apenas uma vez. Sem entender a tarefa, a interpretação continua incompleta.

Métrica mostra comportamento. Pesquisa ajuda a explicar o comportamento.

Imagine:

conclusão caiu de 78% para 61%.

O dado mostra uma mudança importante. Não diz por quê. O time pode inventar: “deve ser esse novo campo”, “provavelmente ficou longo”, “acho que clientes não entenderam”. Todas são hipóteses. Agora você pode observar sessões, fazer teste de usabilidade, entrevistar, analisar erros, cruzar por segmento. A métrica torna a investigação mais precisa. Ela não elimina investigação.

Para saber se um redesign melhorou, você precisa de um “antes”

Esse erro acontece frequentemente. Produto redesenha, lança e depois pergunta:

qual era a taxa anterior?

Ninguém sabe. Agora existe apenas o depois. Você pode comparar com outras evidências, mas perdeu a referência mais direta. Antes de uma mudança importante, registre baseline, segmento, período e definição da métrica. Especialmente se a operação tiver sazonalidade: uma semana aleatória pode ser uma baseline ruim para uma tarefa mensal. O período precisa representar o comportamento que será comparado.

Um grupo não afetado pode ajudar muito

Quando possível, rollout gradual produz uma oportunidade valiosa. Grupo A recebeu o redesign. Grupo B ainda não. Se apenas A melhora, a hipótese de efeito da mudança fica mais forte. Se ambos melhoram igualmente, talvez exista outra explicação.

Ainda existem cuidados: os grupos são comparáveis? Existiu seleção? Houve diferença de volume? Algum outro evento afetou apenas um deles? Mas já é melhor que comparar dois meses e assumir causalidade. Em produtos com volume suficiente, experimentos controlados podem ir ainda mais longe.

Antes e depois não prova causalidade

Imagine:

Antes do redesign: 54% concluíam.
Depois: 68%.

O redesign causou os 14 pontos? É compatível com a hipótese. Não é prova automática. No mesmo período, pode ter mudado a aquisição, entrado outro segmento, havido treinamento, o produto ter ficado mais rápido, uma regra externa ter mudado. Quanto maior o impacto da decisão que será tomada a partir do resultado, mais vale fortalecer a comparação.

Em B2B, média pode esconder mais do que explicar

Você tem dez clientes. Um deles responde por 35% do volume. Ele muda a operação. Sua média dispara. Nada mudou nos outros nove. O dashboard mostra:

experiência melhorou 22%.

Tecnicamente o cálculo pode estar correto. Gerencialmente pode esconder a história. Em produtos B2B com base pequena ou concentração alta, olhe organização por organização, segmento por segmento, coortes, volume, papel do usuário. Às vezes a unidade certa de análise não é usuário. É conta.

Defina corretamente o denominador

Essa é uma fonte enorme de métricas enganosas.

15% usaram a nova funcionalidade.

15% de quê? Todos os cadastrados? Usuários ativos? Administradores? Clientes que tinham acesso? Clientes que possuem aquele problema? A mesma quantidade de usuários pode produzir 2%, 15% ou 80% dependendo do denominador. A métrica precisa representar a população que realmente poderia ter produzido o comportamento. Esse detalhe costuma importar mais que o gráfico.

Use contagens normalizadas quando a base está crescendo

Outra recomendação do próprio paper continua muito prática. Contagens brutas tendem a crescer conforme a base cresce. Por isso porcentagens, proporções ou médias por usuário podem ser mais úteis dependendo do objetivo. Compare:

1.400 erros este mês.

com:

1,8 erro a cada 100 operações.

O primeiro pode subir simplesmente porque houve mais volume. O segundo permite observar se a experiência do fluxo mudou. Nenhum formato é universal. Mas crescimento da base precisa entrar na interpretação.

Happiness também pode ser medida dentro do produto

Dizer que Happiness “não sai do produto” seria impreciso. Ela não é inferida diretamente de comportamento, mas uma pesquisa pode estar dentro da própria experiência. Por exemplo, logo após uma tarefa crítica:

Quão fácil ou difícil foi concluir esta operação?

Isso permite conectar percepção a um momento concreto. Outro formato é acompanhar satisfação periodicamente. O ponto é separar o que a pessoa fez de como ela percebeu o que aconteceu. Às vezes os dois contam histórias diferentes. E isso é justamente o que torna a combinação útil.

Métrica boa precisa levar a alguma decisão

Antes de instrumentar, eu perguntaria: o que faremos se este número melhorar? E se piorar? E se ficar igual? Se ninguém consegue responder, talvez não precisemos daquela métrica agora. Isso evita dashboards cheios de DAU, MAU, tempo, sessões, cliques, NPS, retenção e tickets que são apresentados mensalmente sem alterar nenhuma decisão. O problema não é falta de dado. É falta de vínculo entre dado e escolha.

Quantas métricas acompanhar?

Não existe número mágico. Mas existe um princípio bom: acompanhe poucas métricas o suficiente para que cada uma tenha uma pergunta e um responsável. Para uma mudança específica, uma combinação simples pode bastar. Por exemplo:

• Objetivo: reduzir dificuldade na criação da primeira cobrança.

• Métrica principal: taxa de conclusão sem assistência.

• Métrica de diagnóstico: tempo até conclusão.

• Guardrail: taxa de cobrança criada com informação incorreta.

Talvez ainda exista uma medida de percepção numa pesquisa pontual. Você não precisa de cinco HEARTs. Precisa de evidência suficiente para tomar a decisão.

Comece pela pergunta que alguém fez

Se alguém pergunta:

O redesign melhorou?

não abra o dashboard ainda. Pergunte: melhorou o quê? Velocidade? Compreensão? Confiança? Capacidade de concluir? Descoberta? Retenção? Depois: para quem? E: em qual tarefa? Só então escolha o sinal. E transforme em métrica.

Essa sequência parece mais lenta que abrir o analytics. Na prática, economiza semanas de discussão sobre números que estavam respondendo perguntas diferentes. O HEART é útil porque fornece um vocabulário para pensar nessas possibilidades. O Goals-Signals-Metrics é útil porque impede que o framework vire apenas mais um dashboard.

A pergunta não deveria ser:

qual métrica de UX devemos acompanhar?

Deveria ser:

qual mudança na experiência estamos tentando produzir e que evidência nos convenceria de que ela aconteceu?

Depois disso, a métrica fica muito mais fácil de escolher.

Para uma aplicação mais específica dessa lógica depois de um lançamento, vale continuar por Como medir o sucesso de uma funcionalidade. E, para times que ainda não têm uma rotina de métricas e precisam começar com pouco, o próximo passo é Métricas de produto para time pequeno: o que olhar primeiro.

Fontes

Rodden, Kerry; Hutchinson, Hilary; Fu, Xin. Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications. Proceedings of CHI 2010, ACM.

O trabalho apresenta o HEART como cinco categorias de métricas centradas no usuário: Happiness, Engagement, Adoption, Retention e Task Success. Os autores deixam explícito que essas categorias servem como estrutura para que os times definam métricas específicas e que não é necessário utilizar todas em todo produto ou projeto.

O paper também ressalta que Engagement pode ser pouco significativo em determinados contextos enterprise quando usuários precisam utilizar o sistema como parte do trabalho, enquanto Task Success engloba medidas tradicionais como eficácia, eficiência e taxa de erro.

Rodden, Kerry. The HEART framework for UX metrics. Página da autora que reúne a referência original e materiais posteriores sobre HEART e Goals-Signals-Metrics.

Goals-Signals-Metrics. No processo apresentado junto ao HEART, o time começa articulando o objetivo do produto ou projeto, identifica comportamentos ou atitudes que sinalizariam sucesso ou falha e só depois traduz esses sinais em métricas específicas.

Os autores recomendam que os sinais escolhidos sejam sensíveis e específicos ao objetivo, isto é, que respondam à mudança relevante na experiência e não principalmente a fatores externos. Também recomendam cuidado com contagens brutas quando a base cresce, utilizando proporções, percentuais ou médias por usuário quando apropriado.