Quem deve testar o protótipo de um 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.
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 e em protótipo aprovado: o que falta para virar sistema. No case da 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.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico