# Avaliação de usabilidade

Avaliação heurística e testes com utilizadores, com métricas e iteração.

Página: https://resumos.rgo.pt/cadeiras/ipc/avaliacao-usabilidade/

Avaliar é confrontar o desenho com a realidade: especialistas percorrem [heurísticas](https://resumos.rgo.pt/cadeiras/ipc/avaliacao-usabilidade/principios-usabilidade/) e utilizadores reais tentam tarefas reais. Os dois métodos apanham problemas diferentes, por isso usam-se os dois, por esta ordem: primeiro a heurística (barata, sem recrutar ninguém), depois os testes com pessoas (caros, decisivos).

## Avaliação heurística

Três a cinco avaliadores percorrem a interface de forma independente, anotando cada violação com a heurística infringida e a gravidade (0 sem importância, 1 cosmético, 2 menor, 3 grave, 4 catastrófico). Depois juntam-se as listas e eliminam-se duplicados. A independência importa: avaliadores juntos influenciam-se e veem os mesmos problemas.

O resultado é uma tabela como a da página de princípios: descrição concreta, heurística, gravidade. Só no fim se discute soluções, e só para os problemas graves. Avaliar e redesenhar na mesma sessão mistura papéis e atrasa ambos.

## Inspeção sem utilizadores: percurso cognitivo

Nem sempre há pessoas disponíveis. O **percurso cognitivo** (_cognitive walkthrough_) é uma inspeção em que a equipa percorre cada passo da tarefa a fingir que é um novato, respondendo sempre às mesmas três perguntas:

1.  O utilizador percebe o que tem de fazer neste passo?
2.  Vê o controlo certo para o fazer?
3.  Percebe pelo feedback que progrediu?

Aplica ao fluxo de combinar sessão: no ecrã de blocos, o utilizador percebe que tem de escolher um (pergunta 1)? O bloco parece selecionável ou parece texto corrido (pergunta 2)? Depois de tocar, a confirmação mostra a escolha feita (pergunta 3)? Cada “não” é um problema registado com a mesma gravidade da heurística. O percurso não substitui pessoas, mas apanha falhas de fluxo antes de gastares recrutamento.

## Testes com utilizadores

Um teste com utilizadores tem guião fixo: boas-vindas e consentimento, tarefas uma de cada vez, sem ajuda nem pistas, e perguntas só no fim. As tarefas vêm dos requisitos (“combina uma sessão para quarta com o teu grupo”). Dás o objetivo, nunca os passos: dizer “carrega em Nova sessão” testa a tua memória, não a interface.

O protocolo durante a tarefa chama-se **pensar em voz alta** (_think aloud_): pedes ao participante que diga tudo o que pensa, lê, procura e decide, sem filtrar. Tu calas e anotas: cada “estou à procura de…” marca uma falha de visibilidade, cada “pensei que isto fazia…” marca um engano. Se ele se calar, lembra “continua a pensar em voz alta” sem sugerir nada. Grava com consentimento, porque a citação literal vale mais do que a tua paráfrase.

Recruta pessoas parecidas com as personas, não colegas do projeto. Cinco participantes apanham a maioria dos problemas de um ciclo; mais do que isso rende pouco até iterares.[1](https://resumos.rgo.pt/cadeiras/ipc/avaliacao-usabilidade/#user-content-fn-nielsen) Três já chegam para um teste de papel em fase inicial.

Mede três coisas por tarefa:

*   **Eficácia:** concluiu sem ajuda, com ajuda ou desistiu.
*   **Eficiência:** tempo e número de passos ou erros.
*   **Satisfação:** o que diz no fim, em questionário curto ou entrevista.

Não ajudes, não expliques

A frase mais difícil de engolir é o silêncio enquanto o participante se debate. Qualquer pista invalida a medida. Se ele desistir, regista a desistência como dado e passa à próxima tarefa. Ajudar no momento rouba a descoberta que o relatório precisa.

Para ver um teste real do início ao fim:

[Vídeo: Usability Testing 101](https://www.youtube.com/watch?v=n8MnoJyl3W4)

A miniatura vem do YouTube. O vídeo só carrega quando clicas. [Abrir no YouTube](https://www.youtube.com/watch?v=n8MnoJyl3W4)

E para ver o que cinco utilizadores apanham em sequência:

[Vídeo: Usability Testing w. 5 Users: Design Process (video 1 of 3)](https://www.youtube.com/watch?v=RhgUirqki50)

A miniatura vem do YouTube. O vídeo só carrega quando clicas. [Abrir no YouTube](https://www.youtube.com/watch?v=RhgUirqki50)

## Exemplo: três participantes no protótipo

Testas o fluxo de combinar sessão com três colegas, um de cada vez:

| Tarefa | P1 | P2 | P3 |
| --- | --- | --- | --- |
| Criar sessão para quarta | concluiu, 2 min, 1 erro | concluiu com ajuda, 4 min | desistiu |
| Escolher sala sugerida | concluiu, 1 min | concluiu, 1 min, 1 erro | concluiu, 2 min |
| Confirmar e notificar | concluiu, 1 min | concluiu, 1 min | concluiu com ajuda, 3 min |

Com os dados anotados, agregas por tarefa: eficácia é a fração que concluiu sem ajuda, erros médios é a média dos erros que registaste.

```javascript
const dados = [
  { tarefa: "Criar sessão", estado: ["ok", "ajuda", "desistiu"], erros: [1, 1, 0] },
  { tarefa: "Escolher sala", estado: ["ok", "ok", "ok"], erros: [0, 1, 0] },
  { tarefa: "Confirmar", estado: ["ok", "ok", "ajuda"], erros: [0, 0, 1] },
];
for (const t of dados) {
  const eficacia = t.estado.filter((e) => e === "ok").length / t.estado.length;
  const media = t.erros.reduce((a, b) => a + b, 0) / t.erros.length;
  console.log(t.tarefa + ": eficácia " + Math.round(eficacia * 100) + "%, erros médios " + media.toFixed(1));
}
```

Isto imprime `Criar sessão: eficácia 33%, erros médios 0.7`, `Escolher sala: eficácia 100%, erros médios 0.3` e `Confirmar: eficácia 67%, erros médios 0.3`.

Leitura: criar a sessão falha em 2 de 3 casos (ajuda e desistência), sempre no passo de escolher o dia: P2 tocou fora da zona ativa à espera de um calendário, P3 não percebeu que os blocos propostos já incluíam sala. Correções, por prioridade: (1) mostrar calendário semanal em vez de lista de blocos; (2) juntar sala e hora na mesma linha com mapa; (3) só depois, polir textos de confirmação. Repara que a segunda tarefa correu bem e não precisa de nada: avaliar também diz o que não mexer.

## Iterar: o ciclo fecha-se

Cada ciclo termina numa lista curta de correções priorizadas, que entram no protótipo antes do próximo ciclo.

![Ciclo de iteração. Prototipar leva a testar, testar a corrigir, e corrigir volta a prototipar para o ciclo seguinte.](https://resumos.rgo.pt/cadeiras/ipc/avaliacao-usabilidade/figura-1.svg)

Um projeto com três ciclos de “prototipar, testar, corrigir” chega muito mais longe do que um com um único teste no fim, quando já não há tempo para mudar nada. É por isto que a avaliação vive no meio do processo, não no fim.

## Para saber mais

*   Nielsen Norman Group, [How to Conduct a Heuristic Evaluation](https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/): como planear, conduzir e reportar uma avaliação heurística.

## Para levar para a próxima página

Heurísticas e testes dizem se a interface funciona. Para perguntas mais fundas (o que precisam, porque abandonam, quanto vale a experiência), precisas de inquéritos desenhados e analisados com método. São os [estudos com utilizadores](https://resumos.rgo.pt/cadeiras/ipc/avaliacao-usabilidade/estudos-utilizadores/).

## Notas de rodapé

1.  Nielsen, J., Why You Only Need to Test with 5 Users, Nielsen Norman Group, 2000. [Voltar](https://resumos.rgo.pt/cadeiras/ipc/avaliacao-usabilidade/#user-content-fnref-nielsen)