informacao/o-que-e-e-como-fazer-uma-avaliacao-heuristica

 “Heurística” = baseada em um conhecimento prático (sem comprovação científica), que vem da experiência cotidiana continuada.  TRATA-SE DE UM MÉTODO DE INSPEÇÃO SE DE UM MÉTODO DE INSPEÇÃO  Não envolve usuários.  É uma análise realizada por análise realizada por especialistas que especialistas que advogam pelo advogam pelo usuário – ou seja: sabendo os anseios e necessidades dos usuários, e conhecendo as técnicas possíveis de IHC, avaliam se determinado artefato computacional proporciona uma boa experiência para o usuário.

 Método de inspeção utilizado por arquitetos de informação e designer de interação para realizar testes de usabilidade em interfaces de modo rápido, barato e fácil.  “o objetivo da avaliação heurística é encontrar os problemas de utilização na concepção de modo que eles podem ser atendidos como parte de um processo iterativo de design.” (Nielsen, 2005).

 Peter Paolucci (2007 apud, p.4) afirma que:“Análise heurística, nada mais é do que a análise da interação homem computador (HCI). Exatamente por ser o elo entre o Homem e o Computador, as interfaces, pautadas nas heurísticas, definem o eixo que deve ser considerado como primordial para o desenvolvimento de websites e, em seu bojo, é necessário considerar os elementos relacionados à sua adequada estruturação: Arquitetura da Informação, Arquitetura de Design, Navegabilidade, Conteúdo e Interatividade, que relacionados entre si, definem a usabilidade de um websites.”

 Selecionados de 3 a 5 avaliadores que submetem as partes do projeto.  É possível realizar comparativos entre o que foi projetado na interface e o que realmente é necessário para um modelo sólido e consistente. (É o que fazemos em análise)

 A cada etapa realizada é atribuído o valor da gravidade de cada problema encontrado nas interfaces por intermédio da escala proposta em (Nielsen e Mack, 1994a): 0 – Não é considerado, totalmente, um problema de usabilidade 1 – Problema apenas estético: não necessita ser consertado a menos que tenha tempo extra disponível no projeto

2 – Problema menor de usabilidade: o concerto deste problema deverá ser baixa prioridade. 3 – Problema maior de usabilidade: é importante conserta-lo, para isso deverá ser dado alta prioridade. 4 – Catástrofe de usabilidade: é obrigatório conserta-lo, antes do produto ser divulgado

 Dialogo simples e natural - Os diálogos não devem conter informações que sejam irrelevantes ou que sejam raramente necessárias. Cada unidade extra da informação em um diálogo compete com as unidades relevantes da informação e diminui sua visibilidade relativa. (Nielsen, e Molich, 1990)  Linguagem do usuário - O dialogo deve ser expressado claramente em palavras, frases e conceitos familiares ao usuário ao invés dos termos originados do sistema. (Nielsen, e Molich, 1990)

 Mais reconhecimento que recordação - Minimizar a carga da memória do usuário permitindo a visualização de objetos, ações, e opções. O usuário não deve ter que lembrar informações de uma parte do diálogo para outra. As instruções para o uso do sistema devem ser visíveis ou facilmente recuperáveis sempre que apropriado. (Nielsen, e Molich, 1990  Coerência e padrões - Os usuários não devem ter que saber se palavras, situações, ou ações diferentes significam a mesma coisa. O sistema deve seguir as convenções da plataforma. (Nielsen, e Molich, 1990)

 Feedback - O sistema deve sempre manter os usuários informados sobre o que está ocorrendo, com respostas apropriadas e dentro do tempo razoável. (Nielsen, e Molich, 1990)  Saídas claramente marcadas - Usuários normalmente escolhem algumas funções no sistema por engano e precisarão de saída emergências bem demarcadas para sair do estado indesejado sem passar por um longo caminho. (Nielsen, e Molich, 1990)

 Atalhos - Os atalhos, não vistos pelos usuários novatos, podem normalmente acelerar a navegação para usuários experientes, de tal modo que o sistema deve conciliar usuários experientes e inexperientes. (Nielsen, e Molich, 1990)  Boa mensagem de erro - As mensagens de erro devem ser expressas de forma clara (sem códigos), indicar precisamente o problema, e sugerir construtivamente uma solução. (Nielsen, e Molich, 1990)

 Prevenção de erro - Por melhor que seja a mensagem de erro, um cuidadoso projeto de interface é que impede a ocorrência dos problemas em primeiro lugar. Eliminar circunstâncias que sejam propícias aos erros, ou verificá-las e apresentar ao usuário uma opção de confirmação antes que incidam no erro. (Nielsen, e Molich,1990)  Ajuda e documentação - Pode ser necessário que o sistema forneça ajuda e documentação, apesar de ser melhor quando o sistema é usado sem documentação. A informação deve ser fácil de ser encontrada, focada nas tarefas do usuário. Devem ser listados passos concretos a serem seguidos, e não ser muito extenso. (Nielsen, e Molich, 1990)