# Como testar seu app com usuários de verdade antes de investir mais
Equipe iatize · 2026-08-25 · 9 min de leitura

> **Resumo.** Para testar um app com usuários reais, assista cinco pessoas usando, uma de cada vez, com uma tarefa concreta e você calado: custa uma tarde e nenhuma ferramenta paga. A regra de leitura é uma só — se você precisou explicar, quem falhou foi a tela, não a pessoa. Feito antes de aprovar a próxima funcionalidade, esse teste costuma mudar o que entra na lista.

URL: https://www.iatize.tech/blog/testar-app-com-usuarios-de-verdade

O app está no ar há algumas semanas. Entrou gente, mas o uso não decola. E já chegou a lista do que falta: notificação, um relatório, integração com aquele sistema. A pergunta que quase ninguém faz antes de aprovar essa lista é se as telas que já existem funcionam para quem nunca viu o produto.

Aviso de honestidade: a iatize ganha dinheiro construindo funcionalidade nova. Este artigo existe para você comprar menos e melhor. Tudo o que ele ensina você faz sozinho, sem nos contratar e sem ferramenta paga.

## O que testar depois que o app já está no ar (e não antes)

Antes de construir, a pergunta era se alguém queria — e ela se responde barato, com conversa, página de captura e pré-venda. Isso está em Como validar sua ideia antes de gastar com desenvolvimento, linkado no fim; se você ainda está nesse ponto, comece por lá.

Com o produto no ar a pergunta virou outra: quem entrou consegue usar, e volta? Essa não se responde perguntando. Ninguém sabe descrever o que fez quando travou; a pessoa diz que estava sem tempo, ou que depois olha. Responde-se observando.

## O erro que faz você investir mais antes de saber se serve

A lista de funcionalidades pedidas parece uma lista do que falta. Não é. É a lista do que os sobreviventes querem — e sobrevivente é uma amostra enviesada por definição:

- Quem pede é quem mais usa, ou seja, quem já aprendeu a contornar tudo que é confuso. Ele não reclama da parte quebrada porque já decorou o desvio.
- Quem desistiu não reclama. Some. E some sem responder pesquisa, porque pesquisa de gente que foi embora quase nunca volta preenchida.
- O pedido chega já em forma de solução. Alguém diz que precisa de um botão de exportar quando o que ele quer é mandar aquilo para o contador uma vez por mês.

O resultado é conhecido: você aprova três funcionalidades, gasta, entrega, e o uso continua igual — porque o gargalo estava na terceira tela do cadastro, e ninguém tinha visto ninguém travar nela.

## O teste que custa uma tarde: assista cinco pessoas

Uma pessoa por vez, uns vinte minutos cada. Você dá uma tarefa real — faça o seu primeiro pedido, cadastre um cliente, emita o relatório do mês — e não diz como. Depois cala a boca. É essa a parte difícil: você vai querer ajudar, explicar, defender a tela. Se abrir a boca, perdeu o dado.

O que anotar enquanto assiste:

1. Onde a pessoa parou, e por quantos segundos. Hesitação longa é sempre informação.
2. O que ela leu em voz alta e entendeu diferente do que você quis dizer. Nome de botão é a causa mais barata de conserto e a mais frequente.
3. O que ela procurou e não achou — e onde ela procurou primeiro. O lugar onde ela olhou é onde a coisa deveria estar.
4. Em que momento ela pediu ajuda, ou olhou para você. Esse é o ponto exato da falha.
5. O que ela fez que você não previu. Costuma ser o achado mais valioso do dia.

A regra de leitura é uma só: se você precisou explicar, quem falhou foi a tela, não a pessoa. Vale fixar isso antes de começar, porque o impulso de culpar o usuário é forte quando o produto é seu.

> **Quem convidar — e quem não.** Não chame amigo, sócio nem funcionário: eles conhecem o negócio e vão preencher com a cabeça o que a tela não explicou. E não chame só o usuário antigo, que já aprendeu a contornar os defeitos e por isso não reclama deles. Quem revela o problema é quem entra pela primeira vez — cliente novo, indicado de cliente, alguém do mesmo ramo que nunca viu o produto.

## Os três números que você consegue ler sem ser técnico

Observação mostra o porquê; número mostra o tamanho. Três bastam, e todos dependem de uma decisão que é sua, não de quem programou: qual é a primeira coisa que importa no seu produto — o ato a partir do qual o cliente tirou valor. Primeiro pedido feito, primeiro cliente cadastrado, primeiro relatório emitido. Escolha um.

- Quantos chegaram e criaram conta.
- Quantos fizeram essa primeira coisa que importa.
- Quantos voltaram depois disso.

Não existe número bom universal, e quem te oferecer um valor de referência para o seu caso específico está chutando. O que importa é onde está a maior queda entre uma etapa e a seguinte. Consertar a maior queda quase sempre vale mais do que qualquer funcionalidade nova — e custa menos.

## O que as mensagens de suporte já te dizem sobre o que consertar

Antes de montar qualquer teste, você já tem uma base de pesquisa de graça: as mensagens de suporte. Por um mês, marque o assunto de cada uma com uma palavra só. Ao fim, o assunto que mais repetiu é a próxima coisa a consertar — e você não gastou nada para descobrir.

Tem um segundo uso, e é o que quase ninguém aproveita: a palavra que o cliente usa na mensagem é a palavra que deveria estar na tela. Se ele escreve orçamento e o botão diz proposta comercial, o botão está errado, não o cliente.

## Antes de gravar tela, um cuidado com a lei

Assistir alguém ao vivo, com a pessoa sabendo, é uma coisa. Gravar a tela ou a sessão de quem usa o app é outra: aí você está coletando dado de uma pessoa, e isso precisa estar avisado e descrito na sua política de privacidade. Consentimento explícito é o caminho mais simples e o mais seguro — existem outras bases legais, mas todas exigem que a gravação esteja avisada. Prefira voluntário que sabe a gravação silenciosa de quem não sabe.

Vale dizer por que insistimos nisso: nos 69 apps brasileiros que escaneamos, todos no ar e com clientes, 20% não tinham política de privacidade acessível e 40% não exibiam banner de cookies. Começar a gravar usuário em cima dessa base é criar um problema jurídico para responder uma pergunta de produto — e a pergunta se responde sem gravar nada.

## Quando testar com usuário é perda de tempo

Nem todo mundo deveria fazer isso agora. Cinco casos em que o teste não paga o tempo que custa:

- Você ainda não tem usuário nenhum. Sem gente usando, não há o que observar — o problema é anterior, e se chama validação.
- Três pessoas já falaram a mesma coisa. Sintoma confirmado dispensa nova pesquisa: conserte e siga, porque pesquisar de novo é procrastinação com aparência de método.
- Você não vai mudar nada com a resposta. Se o próximo passo já está decidido e pago, o teste vira teatro. Ou você aceita mudar de ideia, ou não gasta a tarde.
- O problema que você quer resolver está fora do app: preço, prazo de entrega, público errado. Observar uso não conserta oferta.
- A tarefa que você daria ainda não existe. Se o fluxo está pela metade, termine antes — observar tela inacabada só produz a reclamação que você já conhece.

E um alerta sobre o teste mais popular de todos: pedir nota de 0 a 10. Nota sozinha não diz o que consertar. Se for perguntar, pergunte junto o que quase te fez desistir — a resposta aberta é onde está a informação, e ela cabe na mesma mensagem.

**Continue por aqui**
- [Como cuidar do app depois que ele está no ar](/blog/cuidar-do-app-depois-do-lancamento)
- [Como fazer seu app aparecer no Google](/blog/fazer-app-aparecer-no-google)
- [Como validar sua ideia antes de gastar com desenvolvimento](/blog/validar-ideia-antes-de-desenvolver)

Feita a observação, sobra a decisão: consertar a maior queda ou construir o que foi pedido. Peça os dois orçamentos lado a lado. Construir tem faixa de tabela — um app parte de R$3.000 aqui na casa; ajustar um fluxo que já existe não tem, porque depende de quantas telas mudam, se o banco de dados muda junto e se o app está publicado em loja, o que adiciona uma rodada de revisão. Nosso diagnóstico leva cerca de 1 minuto, é gratuito, e serve para separar os dois casos com quem constrói, não com vendedor.

[Fazer meu diagnóstico gratuito](/quiz)

## Perguntas frequentes

### Como testar um aplicativo com usuários reais?

Convide cinco pessoas, uma de cada vez, por uns vinte minutos. Dê uma tarefa real (fazer o primeiro pedido, cadastrar um cliente, emitir o relatório do mês) sem dizer como se faz, e fique calado enquanto ela tenta. Anote onde parou e por quanto tempo, o que leu e entendeu diferente, o que procurou e não achou, quando pediu ajuda e o que fez que você não previu. Se você precisou explicar, quem falhou foi a tela.

### Quantas pessoas preciso para testar meu app?

Poucas, feitas com atenção, valem mais do que muitas apressadas: cinco sessões individuais já costumam expor os travamentos grandes, porque eles se repetem de pessoa para pessoa. O que muda o resultado não é a quantidade, é a qualidade da amostra — gente que nunca viu o produto e não tem relação pessoal com você.

### Meu app tem usuários mas ninguém usa de verdade. O que fazer?

Antes de construir mais, meça três coisas: quantos criaram conta, quantos completaram a primeira ação que dá valor ao cliente e quantos voltaram depois disso. A maior queda entre duas etapas é o seu gargalo, e consertá-la costuma custar menos e render mais do que qualquer funcionalidade nova. Depois, assista cinco pessoas passando por essa etapa para entender o porquê.

### Posso confiar nos pedidos de funcionalidade que meus clientes fazem?

Em parte. Quem pede é quem mais usa, ou seja, quem já aprendeu a contornar o que é confuso — ele não reclama do que está quebrado porque decorou o desvio. E quem desistiu não pede nada, apenas some. Além disso, o pedido costuma vir em forma de solução e não de problema; vale sempre perguntar o que a pessoa está tentando resolver com aquilo.

### Preciso avisar o usuário se eu gravar a tela dele no app?

Sim. Gravar tela ou sessão de quem usa o produto é coleta de dado pessoal, e toda base legal da LGPD exige que a pessoa seja informada — o que precisa estar descrito na política de privacidade. Pedir consentimento é o caminho mais simples e mais seguro para teste de produto; existem outras bases legais possíveis, e qual se aplica ao seu caso é conversa com quem cuida do jurídico, não com quem desenvolve. Para responder dúvidas de produto, observar ao vivo com voluntários avisados resolve igual e não cria obrigação nova. Nos 69 apps brasileiros que a iatize escaneou, 20% nem tinham política de privacidade acessível.