Depois do lançamento

Como testar seu app com usuários de verdade antes de investir mais

Equipe iatize · 2026-08-25 · 9 min de leitura

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.

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.

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