ABC da Usabilidade: Análise Heurística

A análise heurística consiste, basicamente, em submeter a interface de um determinado aplicativo à avaliação de alguns especialistas em usabilidade, conforme um conjunto previamente determinado de “bons princípios de usabilidade”.

por Ezequiel C. Blasco

Bom dia, senhoras e senhores! Conforme prometido no artigo passado, começarei a explicar as técnicas de avaliação de usabilidade, uma por uma. Começarei por aquela que eu acho uma das mais importantes, e certamente a mais fácil, de aplicar: a análise heurística.

A análise heurística consiste, basicamente, em submeter a interface de um determinado aplicativo à avaliação de alguns especialistas em usabilidade, conforme um conjunto previamente determinado de “bons princípios de usabilidade”. Nós denominamos esses princípios de heurísticas, sendo o principal conjunto destas o criado por Jakob Nielsen, que os expôs no livro Usability Engineering (1993). Voltaremos a falar das heurísticas de Nielsen adiante.

Preparação da Análise Heurística

Para fazer uma análise heurística, precisamos dos seguintes “ingredientes”:

· Especialistas em usabilidade (de 3 a 5);

· Um protótipo do aplicativo (seja em papel, wireframe, implementação inicial... qualquer protótipo serve);

· Hipóteses iniciais sobre os usuários (opcional);

· Bateria de atividades (opcional)

Os dois primeiros itens são obrigatórios, afinal, não há avaliação ou teste sem o sujeito (especialistas) e o objeto (protótipo do sistema). Vale lembrar aqui que a análise heurística, por permitir protótipos não-funcionais e funcionais, pode ser utilizada em qualquer estágio do ciclo de desenvolvimento. Assim, a análise heurística serve para eliminar erros conceituais (isto é, vindos de uma interpretação errada dos requisitos) já na fase inicial do desenvolvimento. Isso evita que esses erros sejam detectados depois, quando a implementação já está adiantada, e a correção deles exige uma remodelagem do código (o famoso retrabalho).

As hipóteses iniciais sobre os usuários, mesmo sendo opcionais, são itens interessantes a serem aplicados na análise heurística. Explico o porquê: para uma interface ser fácil e agradável de ser usada, ela deve levar em conta as necessidades dos usuários. Atualmente, são muitos os perfis possíveis, cada um com características próprias de aprendizado, expectativas em relação ao aplicativo, entre outros itens. Logo, é desejável que conheçamos o usuário, para que possamos adaptar a interface às suas necessidades e desejos, a fim de que criemos um produto com boas possibilidades comerciais. Assim, as hipóteses iniciais são instrumentos adequados para serem utilizados durante a análise heurística.

Em relação à bateria de atividades, esta será importante para que o especialista tenha um foco ao realizar a análise heurística. A bateria é composta, preferencialmente, por duas classes de tarefas:

· Tarefas que os usuários-alvo executariam mais frequentemente dentro do aplicativo;

· Tarefas que poderiam apresentar problemas para a compreensão e execução do usuário.

Para que essas tarefas sejam corretamente modeladas, é importante que as hipóteses sobre os usuários tenham sido corretamente estabelecidas. Elas é que irão guiar toda a criação das tarefas, visto que nas hipóteses se estabelecem o perfil de uso e as possíveis limitações do usuário.

Execução da Análise Heurística

Depois da fase de preparação, vem a fase de execução da análise heurística. Essa execução se dá em três fases distintas:

1. Análise individual: nessa fase, cada um dos especialistas analisa individualmente a interface do aplicativo, por um período variável de tempo (usualmente 1-2 horas), segundo o conjunto de heurísticas escolhido. Um relatório é gerado nessa fase, mostrando cada um dos erros encontrados, indicando em cada um a heurística violada, o local do erro e a gravidade do problema, além das possíveis soluções imaginadas pelo especialista.

2. Consolidação da análise: nessa fase, todos os especialistas, juntamente com o líder da equipe, reúnem-se para discutir a respeito dos resultados individuais encontrados. Nessa consolidação, cada especialista tem acesso a todos os relatórios individuais gerados na primeira fase. Ao final desta fase, deve ser gerado um relatório unificado, com todos os erros encontrados (da mesma maneira que na primeira fase).

3. Reunião final: nessa fase, os especialistas se reúnem com o cliente (ou o gerente de projeto) para definir quais serão os erros de interface a ser corrigidos. Claro, em uma situação ideal, deveríamos corrigir todos, mas como temos que lidar com as famosas “limitações de orçamento”, ou com “recursos esgotados”, nem sempre dá para voltar atrás em um erro, principalmente quando estamos falando sobre avaliação somativa.

Heurísticas

Certo, você já conhece os passos corretos, sabe como vai efetuar a análise heurística... mas quais são as heurísticas a serem utilizadas (você deve estar pensando a essa hora)? Calma, que eu vou explicar. Existem alguns conjuntos de heurísticas mais conhecidos do pessoal especialista em usabilidade; os dois mais conhecidos são as heurísticas de Bastien e Scapin (1995) e as heurísticas de Nielsen (1993).

As heurísticas de Bastien e Scapin são mais voltadas para a área da Ergonomia, e são as bases teóricas para a criação da famosa Ergolist, uma checklist desenvolvida pelos pesquisadores da UFSC para auxiliar na avaliação de interface. As heurísticas de Nielsen, por sua vez, cobrem todos os aspectos das boas práticas de usabilidade, sendo usadas quase universalmente, na academia e na indústria. São 10 heurísticas, ao total, as quais serão explicadas a partir de agora. Aí vão elas:

Visibilidade do estado do sistema

Um princípio básico de toda a interface é que o usuário deve sempre (eu disse SEMPRE) saber o estado do aplicativo. Imagine o Windows sem a ampulheta para indicar que o sistema está ocupado... Ou um navegador que não indique como está o carregamento da página Web! Irritante e frustrante, para dizer o mínimo.

Correspondência entre o sistema e o mundo real

É mais fácil para o usuário aprender um sistema que use palavras que sejam de seu conhecimento prévio, e que tenha uma interface similar ao ambiente “não-computacional” de trabalho (quando isso é possível). Dando um exemplo: o MS Word utiliza em sua interface o paradigma WYSIWYG (what you see is what you get – em uma tradução livre, “o que você vê é o que você tem”), o que faz com que ele use a metáfora da “folha de papel” e da “régua” para manter uma correspondência com as antigas máquinas de escrever. Dá certo, e por isso o MS Word se tornou o padrão de interface para processadores de texto. Já o LaTeX, por sua vez, utiliza-se de uma linguagem de marcação que para a maioria dos usuários é complicada, difícil de entender.

Controle e liberdade do usuário

O usuário quer ter a liberdade de não ser tolhido pela interface a seguir passos específicos; ele quer ter o controle, quer poder errar e depois voltar na ação cometida. Imagine um aplicativo onde não existam condições de se desfazer uma ação. Ou pior, um aplicativo onde você tenha que seguir um passo-a-passo milimetricamente exato para, por exemplo, formatar uma célula em uma tabela. Chato, tedioso e irritante.

Consistência e padronização

Uma interface deve manter uma consistência gráfica e léxica durante toda a interação. Explico: não deve haver duas palavras ou dois ícones diferentes indicando a mesma funcionalidade, assim como não deve ter uma palavra ou um ícone representando duas funcionalidades diversas. Também, a identidade visual do aplicativo ou site deve permanecer constante em todas as telas de interação. Senão, o nosso amigo usuário vai ficar bem confuso...

Prevenção de Erros

Prevenção nunca fez mal a ninguém, não é? Então, já que a prevenção faz parte da nossa vida, por que não estender isso para os nossos aplicativos? Se o usuário pode colocar algum dado errado naquele formulário, faça com que ele saiba como preencher os campos com dados corretos (máscaras e dicas marginais fazem tão bem nessas horas...). Lembro de uma vez em que eu preenchia um formulário quilométrico; na hora de colocar a data de nascimento, eu coloquei no já decantado formato DD/MM/AAAA (era um site brasileiro, antes que me perguntem). Quando eu confirmei o envio dos dados – surpresa! – os dados deveriam ser postos no formato DD-MM-AAAA. E como, por Deus, eu iria adivinhar que era assim, se não havia a mínima pista no site? Ah, claro, me esqueci de dizer que todos os dados que eu havia inserido haviam sido apagados do formulário – que beleza, não?

Reconhecimento em vez de lembrança

Um usuário não pode ficar raciocinando onde está o acesso a uma funcionalidade, dentro da interface. Pelo contrário, o usuário deve fazer uso do seu conhecimento de interfaces anteriores para ir “direto ao ponto”, sem ficar pensando: “Onde está a função X?”. Em outras palavras, as instruções de uso do sistema devem estar visíveis ou facilmente acessíveis sempre que necessário. Além disso, o usuário não deve ter que se lembrar de informação de uma parte do diálogo para uma outra (como acontece em certos aplicativos Web, que pedem cinco vezes o mesmo dado, em diferentes formulários que fazem parte do mesmo processo – haja paciência!).

Flexibilidade e eficiência de uso

Uma interface deve ter várias maneiras de acionar uma mesma função. Atalhos de teclado, por exemplo, podem tornar a interação do usuário experiente mais rápida e eficiente, enquanto recursos como a barra de ferramentas e o menu servem aos usuários inexperientes. Outro aspecto que deve ser cuidado é a opção de operação manual em casos onde o default é o sistema acionar uma função automaticamente; isso deve ser levado em conta principalmente em aplicativos que lidem com situações de perigo, como softwares médicos e de navegação aérea.

Projeto estético e minimalista

É interessante que a interface ofereça um visual que não prejudique o usuário, tanto no uso de cores quanto na distribuição de informação. Um aplicativo que ofereça um baixo contraste diminui a legibilidade da interface, enquanto a utilização de cores muito vivas ou de elementos piscantes (prontos para pularem no seu rosto feito aliens famintos) faz com que os olhos se cansem rapidamente. Já em relação à distribuição de informação, é interessante que se restrinja ao necessário para guiar o usuário naquele momento, dentro da interface (a nossa velha concisão). Muitas unidades de informação aparecendo ao mesmo tempo deixam o usuário confuso, e às vezes essa é o motivo principal do abandono de sites de serviços (em relação aos ambientes Web).

Recuperação de Erros

Do que adianta uma interface, ao ocorrer um erro qualquer, jogar no rosto do usuário uma mensagem ininteligível? Todos nós já sofremos com isso, afinal, a Tela Azul da Morte já é nossa velha conhecida: seu aparecimento súbito, além de provocar terror, não ajuda em nada. Afinal, qual de nós, meros mortais, consegue traduzir aqueles erros de sistema malucos que aparecem ali? Às vezes, nem “São” Google ajuda nesses casos! Portanto, o meu recado é: as mensagens de erro devem ser claras, ajudando o usuário a corrigir o que fez de errado com informações simples e concisas.

Ajuda e Documentação

Quem gosta de utilizar o sistema de ajuda de um aplicativo? Nem eu, nem você, nem o Papa Bento gostamos de usar, e sabe por quê? Simplesmente, o sistema de ajuda, em geral, é a ÚLTIMA coisa a ser feita dentro do ciclo de desenvolvimento (nas duas horas restantes, usualmente...)! E aí, meus amigos, o festival de aberrações é evidente: textos muito longos (o pessoal fã do Linux que me perdoe, mas aquelas MAN’s que o sistema oferece, valha-me Deus!), informações fora de contexto e má arquitetura de informação são os vilões da vez. Portanto, meus amigos, a ajuda deve ser fácil de ser encontrada, focada na tarefa do usuário, descrevendo a tarefa passo-a-passo, sem ser muito grande.

Escala de erros

Como eu disse anteriormente, as violações de heurística (ou mais comumente, “erros”) devem ser colocadas em uma escala de gravidade, para que o cliente ou gerente de projeto tenha uma idéia de onde ele deve agir primeiro. Nesse contexto, é sugerida essa (já tradicional) escala:

· Nível 0: Não é encarado necessariamente como um problema de usabilidade.

· Nível 1: Problema estético que não tem necessidade de ser corrigido, a menos que haja tempo e recurso disponível.

· Nível 2: Pequeno problema com baixa prioridade na correção.

· Nível 3: Problema com alta prioridade de correção.

· Nível 4: Catástrofe de usabilidade, ou seja, o produto só será liberado se a correção for feita. Ao final, o relatório das violações de heurística vai ficar similar à tabela abaixo mostrada.

Tabela 1. Exemplo de tabela para relatório de avaliação heurística.

Esse relatório será redigido dessa forma tanto na avaliação individual (1ª fase) quanto na consolidação da análise (2ª fase). O relatório deve ser entregue ao cliente, para que, com base nas informações ali apresentadas, e em suas necessidades de projeto, ele possa decidir quais serão os erros corrigidos.

Conclusões

A análise heurística é uma técnica adequada para ser usada em qualquer fase do desenvolvimento do aplicativo. Fácil, rápida e barata, ela exige apenas um tremendo bom-senso por parte dos avaliadores, que devem ficar atentos ao reporte correto dos erros. Para isso, é interessante adotar a utilização de hipóteses sobre os usuários, bem como de uma bateria de testes escolhida para cobrir as principais funcionalidades e os possíveis erros dos usuários (baseados nas hipóteses sobre os mesmos).

Os resultados conseguidos na análise heurística (principalmente se utilizadas as heurísticas de Nielsen) são abrangentes, estando adequados para a pronta aplicação. Porém, o seu grande problema é que a Análise Heurística não capta os aspectos subjetivos da interface (os quais são dados através dos testes com os usuários). Por isso ela deve, sempre quando possível, ser aplicada em um contexto formativo, onde estejam também previstas avaliações empíricas com os usuários. Aliás, esse é o assunto do qual vamos falar no próximo artigo. Aguardem e confiem.

Bom, é isso! Se precisarem de esclarecimentos, escrevam para ezequiel.blasco.(arroba).testanywhere.com.br.

Até o próximo artigo, meus amigos!