UX Metrics: Usabilidade, Sucesso de Tarefa, Tempo de Conclusão, NPS

A maioria do trabalho de UX não é medida. "Os usuários gostaram do novo fluxo" faz você ser despachado da sala com um aceno. O PM entra com um gráfico de churn. Você entra com um arquivo do Figma. Adivinhe quem vence o argumento de roadmap.

Se você já ficou sentado em uma reunião de revisão trimestral assistindo ao seu escopo encolher enquanto o gerente de engenharia defendia um refactor com números de throughput, você já sabe do que se trata. Design precisa dos seus próprios números. Não dashboards de vaidade. Não "engajamento subiu 4%." Um conjunto curto e defensável que diga a um Head of Product, em menos de sessenta segundos, se o design está funcionando.

Aqui está o conjunto que uso, o diagnóstico que detecta o modo de falha que ninguém fala e o slide de QBR que é encaminhado sem edições.

Por que isso importa agora

Design Leads estão sendo solicitados a defender headcount contra ferramentas de AI. "Entregamos 14 design tokens" não é uma defesa. "A taxa de sucesso de tarefas foi de 71% para 88% no fluxo de cadastro, e os tickets por mil usuários caíram 22%" é.

Não estou exagerando. Nos dois últimos ciclos de performance que acompanhei, todo time de UX que perdeu headcount tinha uma coisa em comum: não conseguia produzir um número que importasse para o negócio. Os times que cresceram tinham um vocabulário compartilhado com produto e um baseline que atualizavam todo trimestre. Essa é toda a diferença.

Números não substituem o craft. Eles o protegem.

As Cinco Métricas

Escolha essas cinco. Não adicione uma sexta até que você tenha reportado essas por dois trimestres seguidos. Mais métricas tornam seu slide mais fraco, não mais forte.

1. Taxa de Sucesso de Tarefas

Defina a tarefa com precisão. Não "usar o dashboard." Diga "criar um novo projeto, convidar um colega e atribuir a primeira tarefa." Depois conte quantos usuários terminam sem ajuda, sem voltar atrás, sem abandonar.

Meta: acima de 85% para qualquer fluxo principal que gere receita ou retenção. Abaixo de 70% em um fluxo entregue a um cliente pagante é um bug, não uma preferência de design.

Como instrumentar: session replay (FullStory, LogRocket, Hotjar) para fluxos de alto tráfego, testes moderados com n=12 ou mais para qualquer coisa nova. Doze é o piso onde você começa a ver o mesmo problema duas vezes. Abaixo de doze você está chutando.

O erro mais comum que vejo: times medem o sucesso de tarefa apenas no caminho feliz. Adicione os dois casos extremos mais comuns (estado vazio e recuperação de erro) e remeça. O número cai, e essa queda é onde seu trabalho real está.

2. Tempo de Conclusão

Use a mediana, não a média. Um cliente enterprise com um fluxo personalizado vai puxar a média para um valor sem sentido. A mediana diz o que o usuário típico realmente experimenta.

Segmente por usuários novos versus recorrentes. Novos usuários em um fluxo acima de 90 segundos para uma ação principal é um alerta. Usuários recorrentes acima de 30 segundos em algo que fazem diariamente também é um alerta. Você está impedindo a memória muscular que eles deveriam ter desenvolvido.

Exemplo real: um redesign da página de faturamento moveu o tempo médio de conclusão de 47 segundos para 31 segundos para usuários recorrentes. Uma redução de 34%. O PM não se importou com o redesign. Ele se importou que os tickets de suporte sobre "onde fica o botão de download de nota fiscal" zeraram no mesmo trimestre. Mesmo resultado, linguagem diferente. Use as duas.

O que o tempo de conclusão não diz: se o usuário gostou, se ele voltou ou se o fluxo é sequer o fluxo certo. É um velocímetro, não uma verificação de destino.

3. Taxa de Erro

Três coisas para rastrear:

• Erros de formulário: campos enviados errados, validação disparada, tentativas antes do sucesso
• Cliques em becos sem saída: toques em elementos não interativos (um rótulo que parece um botão, um ícone sem ação)
• Rage-clicks: três ou mais cliques no mesmo elemento em menos de dois segundos

Por sessão é a unidade certa. "Erros por usuário por semana" esconde incêndios no nível do fluxo.

Regra essencial: estabeleça o baseline antes do redesign. Se você entrega um redesign e reporta "a taxa de erro é 1,2 por sessão," esse número não tem sentido sem o baseline anterior. Vi designers entregarem uma melhora de 30% e não conseguirem reivindicá-la porque nunca mediram o ponto de partida. Defina o baseline na primeira semana. Sempre.

Rage-clicks são subestimados. São o mais próximo que UX tem de um cliente gritando na tela. Qualquer fluxo com rage-clicks acima de 0,5 por sessão está comunicando algo específico: o usuário acha que algo deveria funcionar, e não funciona.

4. SUS Score

O System Usability Scale. Dez perguntas, pontuadas de 0 a 100, conduzido trimestralmente.

Média em todos os softwares: 68. Abaixo de 50 é um incêndio: seus usuários estão ativamente com dificuldades. Acima de 80 é genuinamente bom. Acima de 85 é raro e provavelmente significa uma amostra pequena e auto-selecionada.

Não aplique o SUS em todo o produto. Aplique nos três fluxos que geram receita ou retenção. Escolha-os com seu PM. Caso contrário, você vai acabar calculando a média de um ótimo onboarding com um painel administrativo mediano e reportar um 71 sem sentido.

As dez perguntas (parafrasadas; use a redação padrão quando aplicar):

1. Acho que usaria este sistema frequentemente.
2. Achei o sistema desnecessariamente complexo.
3. Achei o sistema fácil de usar.
4. Precisaria do apoio de uma pessoa técnica para usar este sistema.
5. As diversas funções do sistema estavam bem integradas.
6. Havia muita inconsistência neste sistema.
7. Imagino que a maioria das pessoas aprenderia a usar este sistema rapidamente.
8. Achei o sistema muito complicado de usar.
9. Me senti muito confiante usando o sistema.
10. Precisei aprender muitas coisas antes de conseguir usar este sistema.

Escala de cinco pontos, alternando questões positivas e negativas. O cálculo está bem documentado; não reinvente.

Aplique na mesma semana de cada trimestre, nos mesmos fluxos, com pelo menos n=20 respondentes por fluxo. A tendência importa mais do que o número absoluto.

5. Delta de NPS Pós-Lançamento

O Net Promoter Score é um instrumento grosseiro. Por si só, é uma métrica de vaidade. Segmentado, é um dos sinais mais fortes que você pode mostrar a um Head of Product.

O movimento: nos 30 dias após o lançamento de um redesign, segmente as respostas de NPS entre usuários que de fato passaram pelo fluxo redesenhado e os que não passaram. Compare os dois coortes. Se o coorte do fluxo redesenhado pontua 8 pontos de NPS a mais, você tem uma reivindicação defensável. Se pontuam igual ou menos, você tem um problema que vale investigar.

Esse é o único número de NPS que eu colocaria em um slide de UX. O NPS agregado da empresa pertence ao CEO. O NPS segmentado por coorte pós-lançamento pertence a você.

Cuidado com a armadilha: não compare com o NPS geral do trimestre anterior. Você está medindo um fluxo, não uma empresa. Compare coorte com coorte, na mesma janela.

O Diagnóstico de "Alto Sucesso mas Alto Churn"

Este é o que ninguém avisa.

O fluxo funciona. O SUS está em 76. A taxa de sucesso é 91%. O tempo de conclusão caiu. Você entrega. Você comemora. Três meses depois, o churn não se moveu. Às vezes piora.

O que aconteceu?

Geralmente uma de três coisas:

Você otimizou o job-to-be-done errado. Os usuários completaram a tarefa que você mediu, mas a tarefa não era o que eles queriam de fato realizar. Exemplo clássico: um fluxo de importação redesenhado com 94% de sucesso, mas os usuários importavam CSVs porque não conseguiam fazer a API funcionar. O verdadeiro job era "colocar meus dados rapidamente." Você otimizou a alternativa.

O próximo passo está quebrado. Eles terminaram o onboarding. Então chegaram no estado vazio e saíram. Ou encontraram uma barreira de pricing que não esperavam. Ou foram passados para um representante de vendas que levou quatro dias para responder. O fluxo que você mediu teve sucesso; a jornada falhou.

Você otimizou para novos usuários enquanto quebrava os recorrentes. Taxa de sucesso de novos usuários subiu 22%. Taxa de sucesso de usuários recorrentes caiu 8%. Usuários recorrentes são os que pagam. Eles foram embora.

Como detectar antes do QBR:

1. Agrupe os usuários que cancelaram nos últimos 30 dias.
2. Puxe gravações de sessão desse coorte, 7 dias antes do cancelamento.
3. Procure momentos de hesitação: pausas longas em uma tela, retornar a uma etapa anterior, abrir um artigo de ajuda em uma nova aba.
4. Identifique a tela em que hesitaram, mesmo que as métricas de sessão indiquem que "tiveram sucesso."
5. Essa tela é o seu problema real. Não a que você redesenhou.

Cinco gravações de usuários que cancelaram ensinam mais do que cinquenta testes no caminho feliz. O investimento é duas horas. O resultado é uma lista de três a cinco correções que movem retenção, não métricas de vaidade. Faça isso todo mês.

O Slide de QBR

Um slide. Quatro números. Um destaque de diagnóstico. Não o torne bonito. Torne-o escaneável.

Layout (esquerda para direita, de cima para baixo):

Abaixo da tabela, uma linha:

Diagnóstico: A conclusão do onboarding subiu 17%, mas a retenção na semana 2 está estável. Replay de coorte aponta para o estado de dashboard vazio. Correção planejada para o próximo sprint.

Esse é o slide inteiro. Sem screenshots do redesign. Sem frames de antes/depois no Figma. Sem frases como "os usuários ficaram encantados." O Head of Product não vai ler essas coisas. Vai ler a tabela, a variação e o diagnóstico.

Se quiser ver o Figma, vai pedir. Raramente pede.

Armadilhas de Métricas de Vaidade

Coisas que parecem UX metrics mas não são:

Minutos de engajamento isolados. Sessões mais longas podem significar confusão. Um usuário que passa 12 minutos encontrando o botão de exportar não está engajado. Está perdido. Combine com taxa de sucesso de tarefa ou não reporte.

Design tokens entregues. É uma entrega, não um resultado. Engenheiros não reportam "linhas de código escritas" por um motivo. Não reporte isso tampouco.

NPS sem segmentação. NPS agregado pertence ao CEO. Se você colocar NPS não segmentado em um slide de UX, está ou assumindo crédito por coisas que não fez ou levando culpa por coisas que não quebrou.

CSAT após ticket de suporte. Mede o agente de suporte, não o produto. Útil para a liderança de suporte. Não útil para você.

Taxa de rejeição como métrica de UX. Taxa de rejeição é uma métrica de marketing para landing pages. Em superfícies de produto é quase sempre enganosa.

Número de testes de usabilidade realizados. Atividade, não resultado. O número certo é "testes realizados que mudaram uma decisão de design" e esse é um número difícil de reportar, por isso ninguém faz. Tente mesmo assim.

Checklist de Instrumentação

Antes de se comprometer a reportar qualquer uma dessas métricas, certifique-se de que você consegue de fato medi-las. Percorra esta lista com seu PM e um engenheiro:

• Ferramenta de session replay implantada e com PII removido (FullStory, LogRocket, Hotjar, Heap)
• Rastreamento de eventos em todos os pares início/conclusão de fluxos principais (iniciar onboarding, concluir onboarding, etc.)
• Definições de funil documentadas e compartilhadas com analytics de produto
• Infraestrutura de pesquisa SUS (Typeform, modal no app ou e-mail trimestral) com pelo menos n=20 por fluxo
• Pesquisa de NPS segmentada por exposição a funcionalidade/fluxo, não apenas por data de envio
• Medições de baseline feitas antes de qualquer redesign ser entregue
• Um dashboard compartilhado que o PM consegue abrir sem perguntar para você

Se você não consegue marcar todos os oito, resolva a lacuna antes de se comprometer com a métrica. Reportar um número em que você não pode confiar é pior do que não reportar nada.

Medindo o Seu Próprio Sucesso

Você vai saber que isso está funcionando quando:

• Você consegue responder "o design está funcionando?" em menos de 60 segundos com números, não adjetivos.
• Seu Design Lead encaminha seu slide de QBR ao Head of Product sem edições.
• O PM para de pedir "feedback dos usuários" e começa a perguntar "qual é o último número de sucesso de tarefa."
• Um engenheiro pede o baseline antes de começar um refactor, porque já viu o formato.
• Você detecta um caso de alto sucesso com alto churn antes do QBR, não depois.

O objetivo não é se tornar um analista de dados. É parar de ser a pessoa na sala sem números.

Cinco métricas. Um diagnóstico. Um slide. Aplique por dois trimestres e a conversa sobre UX na sua empresa vai mudar discretamente.

Saiba Mais

• Crítica de Design que Não Degenera
• Teste de Usabilidade com Orçamento Limitado
• Trabalhando com PMs que Não Entendem Design
• Job Description de Product Designer