No BNP Paribas Cardif, o portal de ativação cujo front-end eu desenvolvi substituiu um processo manual de call center e cortou os custos operacionais em 30%. Na Wonderlabs, um fluxo de onboarding redesenhado para um PWA de cartão de crédito aumentou o engajamento dos usuários em 15%. Na Strongest Families, o redesign de uma plataforma de saúde mental que eu liderei melhorou os scores de usabilidade em 25% e apoiou uma rodada de captação de $2M. Não estou compartilhando esses números para impressionar. Estou compartilhando porque números como esses são o que mantém o trabalho de design financiado. Sem uma mudança quantificada, os resultados ficam invisíveis para o negócio e design continua sendo centro de custo em vez de alavanca de crescimento.
A maioria dos times de design perde a discussão de métricas porque leva números de craft para uma conversa de finanças. A tradução entre resultados de UX e linguagem de negócio é o trabalho que garante aos designers um lugar nas decisões de orçamento.
Por Que a Maioria dos Times de UX Mede as Coisas Erradas
As métricas de UX mais comuns que vejo reportadas em sprint reviews são scores de satisfação de testes de usabilidade, números de NPS e time-on-page. Não são inúteis. Mas são frequentemente mal interpretadas. Um score alto de satisfação em um teste de usabilidade significa que os participantes gostaram da experiência em uma sessão controlada com um observador presente. Isso não é a mesma coisa que usuários completando tarefas reais com sucesso em condições reais.
Time-on-page é ainda mais enganoso isoladamente. Para um artigo editorial, alto time-on-page é bom. Usuários estão lendo. Para um fluxo de envio de sinistro de seguro, alto time-on-page é ruim. Usuários estão lutando. A métrica não significa nada sem o contexto do comportamento pretendido.
O framework ao qual sempre retorno é o HEART, desenvolvido no Google por Kerry Rodden, Hilary Hutchinson e Xin Fu. Happiness, Engagement, Adoption, Retention, Task Success. Cada dimensão mapeia para métricas específicas e cada uma pode ser conectada a um sinal (o que observamos?) e uma métrica (como quantificamos?). Nem sempre uso todas as cinco dimensões. Escolho as duas ou três mais relevantes para os objetivos atuais do produto.
As Cinco Métricas Que Realmente Importam
Estas são as métricas que usei mais consistentemente para demonstrar impacto de UX. Não são as únicas métricas. Mas são as mais diretamente rastreáveis ao comportamento do usuário e resultados de negócio.
1. Taxa de Sucesso da Tarefa
Taxa de sucesso da tarefa é a porcentagem de usuários que completam uma tarefa definida com sucesso. É a medida mais direta de se seu design funciona. Para um formulário, sucesso significa envio sem erro. Para um fluxo de onboarding, sucesso significa ativação da conta. Para uma interface de busca, sucesso significa chegar a um resultado relevante.
No BNP Paribas Cardif, o portal de ativação cujo front-end eu desenvolvi substituiu um processo manual de call center. Cada cliente que concluía a ativação no autoatendimento era uma ligação a menos para um agente humano, e é de onde veio a redução de 30% nos custos. Meu papel ali era desenvolvimento front-end, não pesquisa. Mas o número que importava para o negócio não era um score de usabilidade. Era o volume do call center.
2. Tempo na Tarefa
Tempo na tarefa mede quanto tempo os usuários levam para completar um workflow específico. Menor é melhor para tarefas transacionais (checkout, envio de formulário, criação de ticket de suporte). Essa métrica é valiosa porque se traduz diretamente em custo em qualquer workflow onde tempo humano está envolvido, e se traduz em conversão em qualquer fluxo que gera receita.
3. Taxa de Erro
Taxa de erro rastreia com que frequência usuários cometem erros. Entrada incorreta, envios falhados, becos sem saída na navegação. Alta taxa de erro é frequentemente um sinal de rotulagem pouco clara, orientação insuficiente ou um descompasso entre o modelo mental do usuário e o modelo da interface. Reduzir a taxa de erro reduz custos de suporte, reduz abandono de formulários e melhora a confiança.
4. Métricas de Engajamento (Retenção e Profundidade)
Na Wonderlabs, o aumento de 15% no engajamento veio de um fluxo de onboarding redesenhado em um PWA de cartão de crédito com mais de 50.000 usuários. Engajamento é um indicador defasado. Ele responde à experiência acumulada, não a interações individuais. É mais difícil de atribuir a uma única mudança de design, mas é a métrica que a liderança de produto mais se importa.
5. Net Promoter Score e CSAT
NPS e scores de satisfação do cliente são métricas atitudinais. Capturam como os usuários se sentem. São úteis como indicadores de tendência e para benchmarking contra concorrentes, mas são fracas para diagnosticar problemas específicos. Eu as uso como indicadores antecedentes: uma queda no NPS sinaliza que algo está errado antes de você ver nos dados comportamentais.
Instrumentando Designs Para Medição
Medição só funciona se você instrumentar para ela no momento do design, não depois. Isso significa identificar as tarefas-chave no seu fluxo antes de construir, definir como sucesso e falha se parecem para cada tarefa, e garantir que a implementação capture os eventos necessários.
- Defina a tarefa: qual ação específica constitui sucesso? Seja preciso, 'usuário completa checkout' é melhor que 'usuário está satisfeito com o checkout'
- Identifique o evento de início: qual ação do usuário marca o início da tarefa?
- Identifique o evento de sucesso: qual evento de backend ou frontend marca a conclusão?
- Identifique sinais de falha: erros, cliques no botão voltar, timeouts, abandonos
- Especifique as etapas do funil: cada ponto de decisão entre início e conclusão que deve ser rastreado
- Documente requisitos de analytics nas suas specs de design. Isso torna a instrumentação uma tarefa de desenvolvimento, não uma reflexão tardia
// Analytics service in Angular, typed events for a specific flow
import { Injectable } from '@angular/core';
type OnboardingStep = 'personal-info' | 'identity-verification' | 'account-setup' | 'confirmation';
type OnboardingEvent =
| { event: 'onboarding_step_viewed'; step: OnboardingStep }
| { event: 'onboarding_step_completed'; step: OnboardingStep; duration_ms: number }
| { event: 'onboarding_step_error'; step: OnboardingStep; error_code: string }
| { event: 'onboarding_abandoned'; step: OnboardingStep; reason: 'timeout' | 'back' | 'exit' }
| { event: 'onboarding_completed'; total_duration_ms: number };
@Injectable({ providedIn: 'root' })
export class OnboardingAnalyticsService {
private stepStartTime = new Map<OnboardingStep, number>();
track(event: OnboardingEvent): void {
// Send to your analytics platform (Segment, GA4, Amplitude, etc.)
console.log('[Analytics]', event);
// analyticsClient.track(event.event, event);
}
startStep(step: OnboardingStep): void {
this.stepStartTime.set(step, performance.now());
this.track({ event: 'onboarding_step_viewed', step });
}
completeStep(step: OnboardingStep): void {
const start = this.stepStartTime.get(step);
const duration_ms = start ? Math.round(performance.now() - start) : 0;
this.track({ event: 'onboarding_step_completed', step, duration_ms });
}
recordError(step: OnboardingStep, error_code: string): void {
this.track({ event: 'onboarding_step_error', step, error_code });
}
recordAbandon(step: OnboardingStep, reason: 'timeout' | 'back' | 'exit'): void {
this.track({ event: 'onboarding_abandoned', step, reason });
}
completeFlow(flowStartTime: number): void {
const total_duration_ms = Math.round(performance.now() - flowStartTime);
this.track({ event: 'onboarding_completed', total_duration_ms });
}
}Construindo o Business Case Para Investimento em UX
O erro clássico ao apresentar um business case para um investimento significativo em design é começar pela justificativa de experiência do usuário: modelos mentais, carga cognitiva, resposta emocional. A liderança ouve educadamente e o orçamento não sai do lugar. O que funciona é começar com um número: a taxa de conclusão de onboarding está bem abaixo do benchmark do segmento, e cada solicitação abandonada tem um valor em receita que você consegue estimar. Apresentado como receita anualizada em risco, o mesmo investimento em design vira uma aprovação bem mais fácil.
A estrutura que uso para business cases de UX tem quatro componentes: a métrica do estado atual, o benchmark ou meta, o impacto estimado em termos de negócio, e o investimento proposto. Tudo é quantificado. Tudo rastreia para receita, custo ou risco.
- Estado atual: o que os dados mostram agora? Taxa de sucesso da tarefa, taxa de erro, volume de tickets de suporte relacionados ao problema
- Benchmark: como é o bom? Dados do setor, pesquisa de concorrentes ou baseline interno de um produto com melhor desempenho
- Impacto projetado: qual é a mudança esperada? Seja conservador. Executivos desconfiam de projeções otimistas
- Investimento: horas de design, horas de desenvolvimento, tempo de teste, custos de ferramentas
- ROI ou período de payback: mesmo um cálculo aproximado torna o caso concreto
- Risco da inação: qual é o custo de não investir? Útil para casos motivados por compliance
O Problema da Atribuição
Um desafio honesto com métricas de UX é a atribuição. Digamos que a conversão sobe 18% depois de um redesign. Esse número é ilustrativo, não é um dos meus. Foi o redesign, a campanha de marketing que rodou ao mesmo tempo, o preço promocional ou a sazonalidade? Atribuição limpa é rara. As abordagens que funcionam são testes A/B (dividir grupo de mudança e um grupo de controle), rollouts escalonados (lançar para 10% primeiro e medir) e análise pré/pós com um grupo holdout. As três precisam de infraestrutura de release e experimentação por trás.
Essa infraestrutura é o portão, e a maioria dos times não tem. Sem ela você não consegue rodar um split limpo, então o plano B é medição pré/pós com um snapshot claro tirado antes do trabalho começar. Essa é a versão que eu realmente rodei: estabelecer a baseline da métrica primeiro, medir a mesma métrica depois, e ser explícito sobre tudo o mais que mudou naquela janela. O ponto-chave é ter a baseline. Você não pode provar impacto se não mediu antes.
Você não precisa de atribuição perfeita para construir um caso convincente para investimento em design. Você precisa de uma história crível apoiada por dados que se movem na direção certa, no momento certo, em uma magnitude significativa.
Design é mais eficaz quando tratado como uma disciplina com resultados mensuráveis, não uma função de serviço que produz entregáveis. Os times com quem trabalhei que tiveram o maior impacto foram os que eram donos das suas métricas, reportavam em termos de negócio e as usavam para direcionar priorização. Comece com taxa de sucesso da tarefa. Faça a baseline antes de mudar qualquer coisa. Reporte o delta. A conversa com o negócio muda imediatamente.
Referências
- Google HEART Framework (Rodden, Hutchinson, Fu, CHI 2010). https://research.google/pubs/measuring-the-user-experience-on-a-large-scale-user-centered-metrics-for-web-applications/
- Nielsen Norman Group. Success Rate: The Simplest Usability Metric. https://www.nngroup.com/articles/success-rate-the-simplest-usability-metric/
- Amplitude. Product Metrics. https://amplitude.com/blog/product-metrics