# Quem deve testar o protótipo de um sistema interno?

> Quem aprova o orçamento não é quem opera o sistema. Veja por que cinco operadores em tarefas reais acham mais problemas do que a demo para a diretoria.

- Autor: Marlon Trettin
- Publicado: 2026-10-25 · Atualizado: 2026-10-25
- Idioma: pt-BR
- Canonical: https://yowpi.com/blog/quem-deve-testar-o-prototipo-de-sistema-interno

---

Teste o protótipo com quem vai operar o sistema todos os dias, não só com quem aprova o orçamento. A demonstração para a diretoria mede se a ideia convence. Cinco sessões curtas com operadores reais, em tarefas reais, mostram onde o sistema trava, e é isso que sustenta a decisão de investir.

## TL;DR

- Quem aprova o projeto não é quem opera o sistema, e operador e gestor direto são dois grupos de usuários distintos. O [Nielsen Norman Group](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/) recomenda testar cada grupo à parte, com 3 a 4 pessoas por grupo quando são dois.
- No modelo de Nielsen, cinco usuários de um mesmo perfil encontram cerca de 85% dos problemas de usabilidade. No estudo de [Faulkner](https://link.springer.com/article/10.3758/BF03195514), com 60 usuários, conjuntos de cinco acharam entre 55% e 99%. Cinco é um ponto de partida, não uma garantia.
- Uma [revisão sistemática](https://opus.lib.uts.edu.au/handle/10453/27523) de 87 estudos empíricos encontrou 13 sobre envolvimento do usuário em requisitos: 9 confirmaram benefícios e 4 foram inconclusivos. A evidência é favorável, mas limitada: ela não isola o protótipo.
- O desenho é simples: o operador testa, o aprovador observa em silêncio, e cada sessão deixa um registro do ponto em que a pessoa parou.

## Por que a demonstração para a diretoria não basta?

Porque ela testa convencimento, não uso. Numa demonstração, quem conhece o protótipo conduz o clique, usa dados limpos e segue o caminho feliz. A diretoria vê uma tela que funciona. O operador, na terça às quatro da tarde, vai ter um cadastro incompleto, um cliente que não está na lista e uma urgência que não cabe no fluxo desenhado.

Isso não é defeito de quem aprova. Aprovar é um trabalho legítimo, e a diretoria precisa ver o conjunto. O problema é usar a aprovação como se fosse o teste. São duas perguntas diferentes: a diretoria pergunta "isso resolve o problema do negócio?", e o operador pergunta "isso cabe no meu dia sem me atrasar?". Só a segunda decide se o sistema vai ser usado.

Para você, gerente de inovação, existe um agravante. Quem assina costuma ser quem você mais consegue acessar. Quem opera costuma estar numa área que não responde a você. Testar com o grupo que está à mão é o caminho natural, mas é o que menos informa sobre o uso real.

## O que a pesquisa diz sobre quantos usuários testar?

Diz que poucas pessoas, de um mesmo perfil, já mostram boa parte dos problemas, e que o perfil importa mais que o número. Os dados têm limites, e vale dizê-los junto.

Jakob Nielsen, em artigo de 2000 no Nielsen Norman Group, usa a fórmula N(1 - (1 - L)^n), em que L é a parcela de problemas que um único usuário encontra. Nos projetos que ele e Thomas Landauer estudaram, L ficou em média em 31%. Com esse valor, cinco usuários encontram cerca de 85% dos problemas, e depois do quinto os achados começam a se repetir. Nielsen recomenda dividir o orçamento de teste em rodadas: testar com cinco, corrigir, testar de novo com outros cinco, porque uma correção pode não funcionar ou criar problema novo.

O mesmo artigo traz a ressalva que mais importa aqui. A fórmula vale para usuários comparáveis. Quando o sistema serve a grupos muito diferentes, cada grupo precisa ser testado, com 3 a 4 usuários por grupo quando são dois.

Laura Faulkner, em estudo de 2003 na revista Behavior Research Methods, Instruments, & Computers, testou 60 usuários e sorteou conjuntos a partir deles. Alguns conjuntos de cinco encontraram 99% dos problemas, outros só 55%. Com dez usuários, o pior conjunto subiu para 80%, e com vinte, para 95%. A leitura prática: cinco é um ponto de partida barato, mas a variação é grande, e um grupo operacional heterogêneo pede mais gente.

Os dois trabalhos medem problemas de usabilidade encontrados num teste. Não medem se o sistema encaixa no processo nem se o resultado de negócio aparece depois. O número de Nielsen é de 2000 e vem dos projetos que ele estudou, não de sistemas internos brasileiros. Use como ordem de grandeza para planejar a rodada, não como promessa.

## E a evidência sobre envolver o usuário no desenho?

É favorável, mas limitada. Bano e Zowghi publicaram em 2013 uma revisão sistemática com 87 estudos empíricos publicados entre 1980 e 2012. Só 13 deles investigaram especificamente o envolvimento do usuário na engenharia de requisitos. Desses, 9 confirmaram benefícios e 4 foram inconclusivos.

Esse resultado não isola o protótipo, e a revisão trata de requisitos, não de teste. Nossa leitura, que não vem do estudo: o custo de ouvir cinco operadores antes de construir é pequeno perto do custo de descobrir o mesmo problema depois do go-live, com o sistema pago e a equipe voltando para a planilha.

## Quem precisa estar na sala, e em que papel?

Três papéis, com funções diferentes. O operador testa: é quem vai fazer a tarefa todos os dias e quem sabe o que acontece quando o caso foge do padrão. O gestor direto testa a visão de controle, o relatório e a tela que ele usa para cobrar o resultado. O aprovador observa, de preferência sem falar, porque ver o operador travar costuma convencer mais do que um argumento de apresentação.

Há três regras que mudam a qualidade do teste. Use dados reais, anonimizados se for preciso, porque o protótipo com dados de exemplo nunca encontra o cadastro torto. Peça tarefas tiradas da semana real do operador, não um roteiro que o protótipo já sabe cumprir. E não ajude: cada vez que alguém explica o que fazer, o teste perde o ponto em que o sistema, sozinho, não se explica.

Cada sessão deve deixar um registro curto: a tarefa, se foi concluída sem ajuda, onde a pessoa parou e qual caminho antigo ela tentou usar no lugar. Esse registro é o que você leva para a diretoria, e é mais forte que uma opinião sobre o protótipo.

## Um exemplo prático: a recepção da clínica

O cenário a seguir é hipotético. Os números e resultados são premissas ilustrativas, não medição. Uma rede de clínicas com seis unidades prototipa uma agenda com verificação de autorização de convênio. Na demonstração, a diretora vê o paciente agendado, a autorização consultada e a guia anexada em poucos cliques. Aprova.

Agora imagine cinco recepcionistas de unidades diferentes, cada uma com a lista real do dia. Duas param no mesmo ponto: o paciente chega sem o número da guia, e o protótipo exige o campo para salvar. A saída delas é anotar no papel e lançar depois, que é exatamente o caminho que o sistema deveria substituir. Uma terceira percebe que a tela mostra a autorização, mas não o prazo que o convênio deu para usá-la.

Nenhum desses problemas apareceu na demonstração, porque ninguém conduzindo o clique chegou sem a guia. Neste cenário, corrigir o campo obrigatório no protótipo é um ajuste de tela. Descobri-lo com o sistema em produção é um papel na bancada e uma planilha paralela. A decisão de investir passa a se apoiar no que o operador conseguiu fazer, não no que a diretoria achou da tela.

## Como organizar a rodada de testes em uma semana?

Comece pela definição, antes de qualquer sessão. Liste de cinco a oito tarefas reais da semana do operador, escolha o critério de sucesso de cada uma (concluída sem ajuda, tempo até travar, caminho antigo usado) e registre o ponto de partida do processo atual. Sem esse número de referência, o resultado do teste vira opinião.

Depois, convide cinco operadores do mesmo perfil e, se houver mais de um perfil, repita o grupo. Sessões de 45 minutos, uma pessoa por vez, com o aprovador e o gestor direto observando. Essa estimativa de tempo é nossa recomendação de desenho, não um número de pesquisa. Ao fim da semana, corrija o que travou mais de uma pessoa e rode uma segunda rodada com outros operadores, como Nielsen sugere.

O teste responde à pergunta de usabilidade. A pergunta de arquitetura, de onde vem o dado verdadeiro e o que acontece na exceção, continua sendo outra, e está em [prototipagem rápida: como validar antes de investir](/blog/prototipagem-rapida-validar-antes-de-investir) e em [protótipo aprovado: o que falta para virar sistema](/blog/prototipo-aprovado-o-que-falta-para-virar-sistema). No [case da Reatop](/cases/reatop), o app móvel nativo com uso offline foi desenhado para quem opera em campo, ligado a um backoffice integrado, e esse é o tipo de sistema em que o teste com a ponta importa mais.

## Perguntas frequentes

**Minha equipe não aceita mudanças. Colocar operadores no teste não abre espaço para mais resistência?**

Na nossa leitura, o efeito tende a ser o contrário. Quem testa vê o próprio pedido de ajuste virar mudança no sistema, e isso cria posse. A resistência que sobra aparece cedo, na fase em que corrigir é barato, e não depois do go-live. Escolha operadores respeitados pelos colegas, não só os mais entusiasmados.

**A implementação vai exigir tempo demais do time. Dá para testar sem parar a operação?**

Dá, se a rodada for curta. Cinco sessões de 45 minutos, em horários combinados com o gestor direto, ocupam cada operador por menos de uma hora. Esse recorte é uma recomendação nossa de desenho. O tempo que o teste custa é menor que o de manter dois caminhos depois do go-live.

**Não vejo como mensurar o resultado de um teste de protótipo. O que registrar?**

Registre por tarefa: se foi concluída sem ajuda, onde a pessoa parou e qual caminho antigo tentou usar. Meça o processo atual antes, para ter comparação. Esse registro não mede o retorno financeiro do projeto, mas mostra se o sistema cabe na rotina, que é a condição para qualquer retorno aparecer.

## O próximo passo

Se você tem um protótipo aprovado pela diretoria e quer entender o que o operador ainda não viu nele, o Diagnóstico de Arquitetura Operacional, uma conversa de 30 minutos, é um convite para começar: [fale com a Yowpi](/contato).