User research: entenda seu usuário antes de criar

O erro mais caro em produto nem sempre é uma implementação ruim. Às vezes o time entrega exatamente o que planejou, dentro do prazo, com boa qualidade técnica, e ainda assim descobre que resolveu o problema errado.

User research existe para reduzir esse tipo de incerteza. Não para “validar a ideia” depois que ela já foi escolhida, nem para produzir um relatório sobre o usuário. Pesquisa é útil quando muda uma decisão. Se o time termina uma rodada sabendo exatamente a mesma coisa que sabia antes, provavelmente houve conversa, mas pouco aprendizado de produto.

Comece pela decisão, não pelo método

Antes de marcar qualquer entrevista, existe uma pergunta mais importante: o que queremos decidir melhor depois desta pesquisa? Pode ser remover uma etapa do cadastro, entender por que usuários abandonam determinada configuração, escolher qual problema merece entrar no próximo ciclo, decidir se um recurso precisa existir ou se está resolvendo uma exceção, descobrir o que impede determinada empresa de adotar o produto depois da compra.

A decisão vem primeiro porque ela define o tipo de evidência necessária. Se o problema é saber onde existe abandono, analytics provavelmente ajuda mais. Se você já sabe onde as pessoas abandonam, mas não entende o que acontece naquele momento, observação ou entrevista pode abrir o problema. Se precisa estimar quantas pessoas apresentam determinado comportamento, uma amostra qualitativa pequena não resolve. Escolher método antes de formular a dúvida costuma produzir pesquisa interessante e pouco útil.

Analytics mostra comportamento. Pesquisa ajuda a entender contexto

Imagine que 40% dos usuários abandonam uma etapa do fluxo. Esse número já é importante, mas ainda não diz o que deveria mudar. Alguns podem não entender a informação pedida. Outros podem entender perfeitamente e decidir que não vale continuar. Pode existir desconfiança, pode faltar um documento, talvez o usuário precise envolver outra pessoa da empresa. Ou o fluxo pode estar funcionando exatamente como esperado e filtrando quem não deveria avançar. O mesmo evento comportamental aceita explicações diferentes.

É nesse ponto que quantitativo e qualitativo funcionam melhor juntos. O dado ajuda a encontrar onde olhar. A pesquisa explora o que está acontecendo naquele contexto. Depois, os dados voltam a ser importantes para verificar escala e acompanhar o efeito de uma mudança. Um não substitui o outro.

Entrevista boa investiga comportamento, não intenção

Existe uma diferença grande entre perguntar:

Você usaria um recurso que organiza automaticamente seus relatórios?

e:

Como você organizou seus relatórios da última vez que precisou fechar o mês?

Na primeira, a pessoa está imaginando um futuro. Na segunda, está reconstruindo uma situação que realmente aconteceu. Comportamento passado tende a oferecer muito mais material para entender contexto, esforço, alternativa e prioridade.

Perguntas úteis costumam explorar episódios concretos: quando isso aconteceu pela última vez, o que você fez primeiro, quem mais participou, onde estavam as informações, o que aconteceu quando não deu certo, como você resolveu. A entrevista não precisa terminar com uma lista de features desejadas. Muitas vezes o melhor resultado é entender como o problema funciona antes de existir qualquer interface nova.

Teste de usabilidade responde outra pergunta

Entrevista ajuda a entender experiência, contexto e comportamento. Teste de usabilidade observa uma pessoa tentando executar uma tarefa, o que muda completamente a dinâmica. Em vez de perguntar:

Esse fluxo parece claro?

dê uma tarefa.

Você precisa cadastrar um novo fornecedor e liberar o primeiro pagamento. Faça como faria normalmente.

Agora observe. Onde a pessoa hesita? O que interpreta errado? Que informação procura? Que ação tenta primeiro? Em que momento pede ajuda?

Evite transformar a sessão numa demonstração. Se o moderador explica toda vez que surge dúvida, justamente os pontos mais valiosos desaparecem.

Em estudos qualitativos com público e tarefa bem definidos, algumas poucas sessões já podem revelar padrões recorrentes. Cinco participantes é uma heurística conhecida em testes de usabilidade, não uma regra estatística universal. Se existem segmentos muito diferentes, tarefas críticas ou necessidade de medir prevalência, o desenho da pesquisa precisa mudar.

O suporte já contém pesquisa que talvez ninguém esteja usando

Nem todo aprendizado precisa começar com recrutamento. Tickets de suporte, conversas de vendas, motivos de cancelamento e dúvidas de implementação já carregam sinais importantes. O problema é que normalmente estão organizados para resolver atendimento, não para orientar produto.

Uma classificação simples muda isso. Em vez de apenas:

problema técnico

registre:

área: conciliação
tarefa: identificar pagamento
momento: após processamento
dúvida: status ambíguo

Depois de algumas semanas, padrões começam a aparecer. Uma dúvida isolada pode ser exceção. A mesma dúvida aparecendo repetidamente em uma tarefa importante merece investigação. Esse material também ajuda a escolher quem entrevistar: se várias contas enfrentam o mesmo problema, a pesquisa começa com uma hipótese concreta em vez de uma pauta genérica sobre “experiência do cliente”.

Recrutamento muda o resultado antes mesmo da primeira pergunta

É fácil conduzir uma ótima entrevista com a amostra errada. Se o comercial indicar apenas os clientes mais próximos, a pesquisa provavelmente vai ouvir pessoas satisfeitas e altamente engajadas. Se o time entrevistar apenas administradores, pode nunca descobrir o que acontece com quem opera o produto todos os dias. Se conversar só com quem permanece cliente, perde a perspectiva de quem tentou e desistiu.

A escolha depende da pergunta. Para investigar ativação, talvez faça sentido comparar quem avançou com quem abandonou cedo. Para uma funcionalidade operacional, fale com quem realmente executa aquela tarefa. Para entender churn, clientes que ficaram e clientes que saíram podem revelar diferenças importantes. Em B2B, o cargo também importa: comprador, administrador e usuário final podem estar dentro da mesma conta e viver produtos completamente diferentes.

O insight precisa chegar à decisão sem virar frase de post-it

Depois de cinco ou seis conversas, é tentador resumir tudo em frases como:

Usuários precisam de mais clareza.

Isso é difícil de usar. Um insight melhor preserva contexto. Por exemplo:

Administradores novos não sabem qual permissão atribuir porque os nomes dos papéis descrevem a estrutura interna do produto, não o tipo de acesso que cada pessoa recebe.

Agora existe uma hipótese de produto. Talvez seja nomenclatura, talvez seja modelo de permissões, talvez seja falta de contexto na configuração. A pesquisa não precisa decidir automaticamente qual solução construir. Ela precisa melhorar a qualidade da pergunta que o time vai responder.

Uma estrutura útil é registrar:

• o que observamos;

• em qual contexto;

• qual hipótese isso gera;

• qual decisão pode mudar;

• o que ainda precisamos verificar.

Isso preserva a diferença entre evidência e interpretação.

Uma fala forte ainda é uma fala

Uma das armadilhas de pesquisa qualitativa é se apaixonar pela melhor frase da sessão. Uma pessoa diz algo memorável, o time coloca no slide e, na reunião seguinte, aquela frase já virou “o usuário quer”. Pesquisa qualitativa não funciona assim. Uma observação pode revelar um mecanismo importante sem dizer nada sobre sua prevalência na base inteira.

Se três pessoas travaram na mesma etapa, existe um padrão que merece atenção. Ainda assim, você não pode concluir que 60% dos clientes apresentam o problema porque três de cinco apresentaram.

Para decidir tamanho e prioridade, combine a evidência qualitativa com dados do produto: quantas pessoas passam por esse fluxo, quantas abandonam, qual segmento concentra o comportamento, quanto de receita está envolvido, qual é a frequência da tarefa. A pesquisa mostra onde cavar. Os números ajudam a entender o tamanho do buraco.

Pesquisa contínua não significa entrevistar usuários toda semana sem motivo

Existe uma diferença entre pesquisa contínua e agenda permanente de entrevistas. Pesquisa contínua significa manter contato frequente com evidências do usuário à medida que decisões importantes surgem. Às vezes isso exige entrevista. Em outro momento, observar cinco sessões resolve. Talvez seja suficiente analisar vinte tickets de suporte, ou acompanhar uma implementação com Customer Success. O método muda.

O que não deveria acontecer é o time passar seis meses tomando decisões importantes sobre comportamento do usuário e só conversar com clientes quando chega um grande redesign. Pesquisa funciona melhor quando entra antes da certeza.

Em fintech, o desenho da pesquisa também precisa respeitar os dados

Quando o produto envolve dinheiro, documentos, biometria ou informações de terceiros, a própria sessão pode criar risco se for mal planejada. Evite pedir que participantes exponham dados reais quando isso não for necessário. Se a tarefa pode ser executada com ambiente de teste e informações fictícias, prefira esse caminho. Grave apenas o que realmente precisa ser registrado, explique a gravação antes da sessão e registre a concordância do participante. Pela LGPD, o tratamento de dados pessoais precisa ter finalidade e base legal definidas. Consentimento pode ser uma dessas bases, mas não é a única.

Também vale pensar no ciclo inteiro do material coletado. Quem consegue acessar a gravação? Por quanto tempo ela será mantida? A transcrição será enviada para uma ferramenta externa? Existem nomes, dados financeiros ou informações sobre terceiros? Quando aplicável, anonimizar notas e estabelecer prazo de retenção reduz exposição desnecessária. Research ops também é parte do desenho da pesquisa.

O melhor research reduz uma incerteza que estava bloqueando o produto

Pesquisa não precisa terminar num grande relatório. Às vezes o melhor resultado cabe em poucas linhas:

Achávamos que usuários abandonavam porque o cadastro era longo. Nas sessões, descobrimos que o bloqueio acontece quando precisam informar um dado financeiro que não sabem onde encontrar. Antes de remover etapas, vamos testar contexto e uma alternativa para buscar essa informação depois.

Isso muda uma decisão. É o suficiente.

Se o problema estiver nos primeiros usos, a descoberta pode virar trabalho de onboarding. Se aparecer numa tarefa recorrente, pode alimentar uma investigação de retenção. Se a mesma solução começar a se repetir em várias áreas, talvez deva virar padrão no design system. Mas nenhuma dessas saídas deveria ser decidida antes da pesquisa. O valor de user research está justamente em permitir que o time mude de ideia enquanto ainda é barato mudar.

Antes de começar, uma pergunta simples ajuda a separar pesquisa de ritual: qual decisão estamos dispostos a tomar diferente dependendo do que encontrarmos? Se não existe resposta, talvez o time ainda não precise entrevistar ninguém. Precisa primeiro descobrir o que está tentando decidir.

Fontes

Nielsen Norman Group. “How Many Test Users in a Usability Study?”, Jakob Nielsen, publicado em 2012. O artigo discute tamanho de amostra em estudos qualitativos de usabilidade e recomenda rodadas pequenas e iterativas em vez de concentrar todo o orçamento em uma única rodada com muitos participantes. A conhecida heurística de aproximadamente cinco participantes deve ser interpretada dentro desse contexto e não como regra universal para qualquer tipo de pesquisa.

Lei nº 13.709/2018, Lei Geral de Proteção de Dados Pessoais (LGPD). Estabelece princípios, bases legais e direitos relacionados ao tratamento de dados pessoais no Brasil. Em atividades de pesquisa com usuários que envolvam dados pessoais, a base legal, a finalidade, a necessidade do tratamento e as condições de conservação precisam ser avaliadas conforme o caso.