Métodos de inspeção que não envolvem usuários são bastante usados, mesmo que pareça paradoxal. Muitas organizações contratam consultores externos, com experiência em interação, para avaliar um sistema ou seus protótipos antes de serem lançados. A avaliação é feita com base no conhecimento prévio sobre usabilidade, comportamento e limitações cognitivas de usuários, contextos em que o sistema será usado, além dos tipos de atividades que serão desempenhadas. Exemplo mais clássico: avaliação heurística (nosso foco aqui na disciplina). Outro método bastante aplicado: walk-through, ou até análise de uso de aplicações já existentes. Por ora, vamos focar em avaliação heurística. Às vezes, torna-se inviável conseguir usuários para avaliar UI\UX, em casos em que simplesmente não estão disponíveis, ou não há tempo para isso. Nesses casos, outros indíviduos, os experts ou consultores de UX, podem oferecer feedback. Vários métodos de inspeção de usabilidade foram desenvolvidos como alternativa ao teste de usabilidade com usuários, no início dos anos 90 - inspeções para qualidade de software em geral já eram populares na época. Uma vantagem de métodos desse tipo é que eles podem ser utilizados a qualquer momento no processo de desenvolvimento, em complemento, muitas vezes, aos testes de usuário.

Na avaliação heurística, consultores/pesquisadores, guiados por conjunto de princípios de usabilidade conhecidos como heurísticas, avaliam se elementos de UI, tais como caixas de diálogo, menus, estrutura de navegação, ajuda online, etc., estão em conformidade com esses princípios. Subjacentes a esses princípios fazem-se presentes diretrizes como consistência, memória, e clareza, ou seja, princípios básicos de usabilidade.

Diretrizes de avaliação heurística foram propostas por Jakob Nielsen e seus colegas entre 1990 e 1994, e posteriormente estendidas por outros pesquisadores para contextos específicos, como aplicações web. O conjunto de heurísticas original advém do estudo de 249 problemas de usabilidade, mais tarde revisados.

  • Visibilidade de Status: O sistema deve sempre manter os usuários informados sobre o que está acontecendo, fornecendo feedback apropriado e dentro de um tempo razoável.
  • Correspondência entre sistema e mundo real: O sistema deve falar a linguagem dos usuários, com palavras, frases e conceitos familiares ao usuário, em vez de termos orientados pelo sistema. Ele deve seguir convenções do mundo real, fazendo com que as informações apareçam em uma ordem natural e lógica.
  • Controle de usuário e liberdade: Os usuários muitas vezes escolhem funções do sistema por engano e precisarão de uma saída de emergência claramente marcada para sair do estado indesejado sem precisar passar por um diálogo prolongado. O sistema deve suportar desfazer e refazer.
  • Consistência e Padrões: Os usuários não devem se perguntar se diferentes palavras, situações ou ações significam a mesma coisa. O sistema deve seguir as convenções da plataforma.
  • Prevenção de Erros: Em vez de apenas fornecer boas mensagens de erro, o sistema deve incorporar um design cuidadoso que evite que um problema ocorra em primeiro lugar. Elimine as condições propensas a erros ou verifique-as e apresente aos usuários uma opção de confirmação antes que eles se comprometam com a ação.
  • Reconhecimento em Vez de Lembrança: Minimize a carga de memória do usuário tornando objetos, ações e opções visíveis. O usuário não deve precisar lembrar informações de uma parte do diálogo para outra. As instruções para usar o sistema devem ser visíveis ou facilmente recuperáveis sempre que apropriado.
  • Flexibilidade e Eficiência de Uso: Aceleradores, invisíveis para o usuário iniciante, podem frequentemente acelerar a interação para o usuário experiente, de modo que o sistema possa atender tanto aos usuários inexperientes quanto aos experientes. Permita que os usuários personalizem ações frequentes.
  • Design Estético e Minimalista: Os diálogos não devem conter informações irrelevantes ou raramente necessárias. Cada unidade adicional de informação em um diálogo concorre com as unidades relevantes de informação e diminui sua visibilidade relativa.
  • Ajuda aos Usuários: Reconhecer, Diagnosticar e Recuperar de Erros As mensagens de erro devem ser expressas em linguagem clara (não códigos), indicar precisamente o problema e sugerir construtivamente uma solução.
  • Ajuda e Documentação: Embora seja melhor se o sistema puder ser usado sem documentação, pode ser necessário fornecer ajuda e documentação. Qualquer informação desse tipo deve ser fácil de pesquisar, focada na tarefa do usuário, listar etapas concretas a serem realizadas e não ser muito extensa.

Pesquisadores e designers avaliam aspectos da UI em cima dessa checklist acima. Ao realizar a avaliação heurística, o pesquisador passa pela UI várias vezes, inspecionando os vários elementos e comparando-os com a lista. A cada iteração, problemas de usabilidade podem ser identificados, e formas de corrigir são propostas.

Uma avaliação heurística normalmente é quebrada em dois estágios. Primeiro, há uma sessão de briefing, em que os(as) especialistas ouvem explicações de contexto inicial, com os objetivos da avaliação. Depois há o período de avaliação propriamente dito, em que os(as) especialistas passam 1-2 horas inspecionando o produto de forma independente, usando as heurísticas como guia. Normalmente, ele(as) passam duas vezes pela UI: a primeira para dar uma ideia da interação e do escopo do sistema, e a segunda com foco em elementos específicos, para identificar problemas em potencial. Ao final, existe uma sessão de debriefing, na qual consultores se juntam para discutir seus achados com os designers para priorizar os problemas encontrados, dando sugestões de melhoria.