Como testar a usabilidade de uma aplicação com pessoas reais

A aplicação responde. A pessoa continua sem decidir.

Imagine alguém que marcou uma aula de treino e agora precisa de a passar para quinta-feira. A reserva aparece na aplicação, há um horário disponível e o botão para alterar funciona. Mesmo assim, a pessoa hesita. Já pagou um sinal: esse valor passa para a nova data ou perde-se ao cancelar a anterior?

É um exemplo fictício, não um relato de cliente. Mostra a diferença entre conseguir executar uma operação e perceber o que ela significa. Uma verificação técnica pode confirmar que a nova data fica guardada. Não confirma que alguém se sente à vontade para avançar.

Perguntar se o ecrã agrada talvez produza um simpático «sim». Pedir à pessoa que altere a reserva permite ver a dúvida quando ela acontece. É essa a utilidade de um teste de usabilidade, dentro do processo de desenho da experiência de utilização. Pode começar com uma sessão simples, desde que saiba o que procura.

Escolha a decisão que precisa de esclarecer

«Queremos saber se a aplicação é fácil» parece um bom começo, mas deixa demasiado em aberto. Alguém pode não encontrar a reserva; outra pessoa pode encontrá-la imediatamente e interpretar mal o pagamento. A palavra «difícil» juntaria dois problemas que exigem alterações diferentes.

Uma pergunta mais útil seria: a pessoa consegue mudar uma aula já paga e explicar o que acontece ao sinal? Há um percurso concreto e uma expectativa que pode observar. No fim, terá matéria para decidir se a informação sobre a alteração precisa de ser revista.

Escreva antecipadamente o que considera um resultado correto: encontrar a reserva certa, escolher outra data e compreender o que fica marcado e pago. Guarde essa definição nas suas notas. Não a apresente como instrução, porque já contém parte da resposta.

Tenha também presente o alcance do teste. Saber se existe procura pela ideia pertence à validação do projeto. Falhas de pagamento, perda de dados e encerramentos inesperados precisam de verificações próprias. Uma função pode ser compreensível e falhar na execução, ou funcionar sem que se perceba como utilizá-la.

Use uma versão capaz de responder à pergunta

Não precisa necessariamente de esperar pela aplicação concluída. Um protótipo navegável pode mostrar se a sequência e as palavras fazem sentido. Para estudar o teclado, notificações ou o regresso após uma interrupção, uma versão funcional será mais adequada. A comparação entre protótipo e MVP ajuda a escolher o suporte.

Prepare uma conta de teste com uma reserva plausível. Assim, a sessão começa na questão que interessa, em vez de gastar tempo num registo completo. Utilize dados fictícios e uma forma segura de simular pagamentos. Ninguém deve cancelar uma aula verdadeira nem enviar acidentalmente uma mensagem a um cliente.

Conheça os limites do protótipo antes de começar. Um botão ainda sem destino não demonstra, por si só, um problema de compreensão. Mas também não explique todas as intenções do desenho para compensar o que falta. Os textos que já existem podem ser testados sem ensinar previamente a resposta.

Procure pessoas com experiência da situação

Um colega sabe frequentemente onde está uma opção porque participou nas conversas sobre ela. Um amigo pode evitar críticas para o apoiar. Ambos ajudam a ensaiar a organização da sessão, mas não representam automaticamente quem vai usar a aplicação.

Para uma aplicação de aulas, interessa alguém que tenha feito uma marcação recentemente e precisado de alterar o horário. Pergunte como resolveu a situação, em que dispositivo e com que receios. Esta experiência concreta diz mais do que uma resposta favorável à ideia de uma aplicação de treino.

As recomendações da Nielsen Norman Group sobre participantes enquadram grupos pequenos em estudos qualitativos repetidos. Cinco pessoas adequadas podem constituir uma primeira ronda útil para uma tarefa bem delimitada. Não representam uma garantia estatística sobre todos os utilizadores.

Se juntar alunos, instrutores e pessoal administrativo, terá necessidades diferentes na mesma amostra. Não conte cinco participantes de vários perfis como se tivesse observado cinco pessoas de cada perfil. Uma pergunta limitada, mas bem estudada, vale mais do que uma conclusão abrangente sem apoio suficiente.

Apresente a situação sem ensinar o percurso

«Abra As minhas reservas, carregue em Editar e escolha quinta-feira» deixa pouco por descobrir. A pessoa pode seguir tudo corretamente sem nunca ter encontrado esse caminho sozinha. Nesse caso, testou a sua explicação, não a clareza da aplicação.

Uma boa tarefa dá contexto e objetivo, mas não identifica os comandos a avaliar. O artigo da NN/G sobre cenários de tarefas desenvolve esta distinção. Os exemplos seguintes são próprios e acompanham a nossa marcação de treino:

A pessoa pode parar porque as condições não são claras. Isso não significa que tenha participado mal. Pode estar a mostrar precisamente o motivo pelo qual um cliente real telefonaria para o centro em vez de concluir a operação na aplicação.

Dê tempo para pensar, mesmo quando conhece a resposta

Comece por explicar que está a testar a aplicação, não as capacidades da pessoa. Diga se pretende gravar e peça autorização antes de o fazer. Num telemóvel pessoal podem aparecer mensagens privadas; combine como evitá-las e quem poderá aceder à gravação. O guia de testes moderados do GOV.UK aborda estes preparativos.

Depois, resista à vontade de preencher o silêncio. Uns segundos parecem longos quando sabe onde se deve carregar. Se disser logo «está mais abaixo», a pessoa já estará a realizar a tarefa com ajuda. Pode dar uma pista para a sessão continuar, desde que a registe como tal.

Pergunte «o que espera encontrar aqui?» ou «o que acha que aconteceu?». Evite «viu que o sinal se mantém?», porque já fornece a interpretação desejada. Elogiar cada escolha correta também pode levar a pessoa a procurar a sua aprovação, em vez de agir como agiria sozinha.

As notas dos investigadores do GDS sobre moderação são uma leitura útil para preparar a primeira sessão. Quando alguém pergunta o significado de um texto, procure perceber primeiro a interpretação espontânea. A explicação pode vir depois; a expectativa inicial perde-se assim que dá a resposta.

O telemóvel faz parte da tarefa

Uma proposta de ecrã parece confortável num monitor grande. No aparelho habitual, o teclado pode tapar a continuação, uma data extensa ocupar duas linhas ou uma ação ficar difícil de alcançar com uma mão. Não são pormenores irrelevantes se interferirem na decisão principal.

Não transforme a sessão numa sequência artificial de obstáculos. Observe primeiro uma utilização normal e investigue depois condições que façam sentido para o público. Se as marcações costumam ser alteradas durante uma deslocação, veja se a escolha se mantém depois de uma interrupção breve. Se há necessidade de texto ampliado, teste essa opção.

A língua também altera a experiência. Uma sessão em inglês não demonstra que as palavras portuguesas são claras. Use os textos, datas e confirmações da versão destinada ao público. Além disso, um estudo geral não substitui uma avaliação com pessoas que utilizam tecnologias de apoio. O guia de acessibilidade de aplicações ajuda a preparar esse trabalho específico.

*Uma ilustração da abordagem: perceber onde o percurso se interrompe antes de ajudar a pessoa a avançar.*

Registe o que aconteceu antes de propor uma solução

«O botão é pequeno» pode parecer uma conclusão pronta. Muitas vezes, é apenas a primeira hipótese. Uma nota mais útil seria: a pessoa abriu a reserva duas vezes, leu a informação sobre o pagamento e parou. Quando lhe perguntaram o que esperava, disse que perderia o sinal se mudasse a data. Neste exemplo fictício, aumentar o botão talvez não resolvesse nada.

Separe o comportamento observado, a sua explicação e a alteração que quer experimentar. Talvez as condições apareçam demasiado tarde. Uma explicação curta antes de confirmar seria então uma hipótese a verificar, não uma melhoria já comprovada.

Distinga tarefas concluídas sem ajuda, concluídas com indicação e abandonadas. Anote também a consequência: tempo perdido, horário errado ou risco de cancelar a reserva pretendida. «Duas das cinco pessoas desta ronda precisaram de uma pista» descreve a observação. Não significa que 40% de todos os clientes vão falhar.

A gravidade conta tanto como a repetição. Um único risco de cancelamento errado pode exigir mais atenção do que várias preferências sobre uma cor. Os dados ajudam a fundamentar a prioridade, mas a decisão continua a pedir cuidado e contexto.

Volte à dúvida depois de alterar o ecrã

Mudar navegação, texto e disposição ao mesmo tempo pode tornar a sessão seguinte mais fácil sem mostrar o que ajudou. Comece pela causa mais plausível e por uma alteração específica. No nosso exemplo, a informação sobre o sinal deve estar compreensível quando é preciso decidir.

Para estudar a primeira utilização, participantes novos evitam confundir compreensão com memória. Quem já percorreu os ecrãs pode repetir o caminho sem pensar. Os participantes anteriores também podem ajudar, mas noutras perguntas. Peça sempre uma explicação do resultado final: chegar à confirmação não prova que se percebeu qual é a reserva válida.

Depois do lançamento, a análise de utilização da aplicação pode mostrar onde as pessoas saem de um percurso. A observação ajuda a entender porquê, e os testes de uma versão beta alargam os aparelhos e circunstâncias. Estes métodos complementam-se.

Para começar, basta uma página com a pergunta, os participantes, algumas tarefas, a conta preparada, as notas e a decisão seguinte. Se precisar de uma equipa, explique a dificuldade à Appfyl ou inclua-a num breve formulário de projeto. «Os clientes não percebem o que acontece ao sinal» esclarece melhor o trabalho do que pedir mais um ecrã sem explicar a razão.

Perguntas frequentes