1  Presteza
 2  Agrupamento por localização
 3  Agrupamento por formato
 4  Feedback
 5  Legibilidade
 6  Concisão
 7  Ações Mínimas
 8  Densidade Informacional
 9  Ações Explícitas
 10  Controle do Usuário
 11  Flexibilidade
 12  Experiência do Usuário
 13  Proteção contra erros
 14  Mensagens de erro
 15  Correção de erros
 16 Consistência
 17 Significados
 18 Compatibilidade

01/18 Presteza
Verifique se o sistema informa e conduz o usuário durante a interação.

Uma boa presteza guia o usuário e lhe poupa, por exemplo, o aprendizado de uma série de comandos. Ela permite, também, que o usuário saiba em que modo ou em que estado ele está, onde ele se encontra no diálogo e o que ele fez para se encontrar nessa situação. Uma boa presteza facilita a navegação no aplicativo e diminui a ocorrência de erros.

Exemplos de Recomendações:

• Dirigir a entrada de dados indicando o formato adequado e os valores aceitáveis (ex.:__/__/__).
• Exibir as unidades de medidas dos dados a digitar (cm , mm, m)
• Indicar todas as informações sobre o estado da interação.
• Para cada campo de dados, fornecer um rótulo.
• Indicar o tamanho do campo, quando ele é limitado.
• Quando necessário, fornecer no rótulo informações suplementares.
• Dar um título a cada janela.
• Fornecer ajuda on-line e orientação

Presteza vs. Agrupamento/distinção por formato
A Presteza ajuda o usuário de uma forma bastante direta, sugerindo ações possíveis. No caso onde muitas opções ou ações são disponíveis (por exemplo, confirmar, cancelar, copiar, etc.), somente as ações disponíveis poderiam ser mostradas ou indicadas em uma mensagem. Meios menos diretos estão também disponíveis para orientar os usuários. No exemplo acima, se todas as opções são apresentadas, diferentes formatos poderiam ser usados para indicar aquelas que estão d isponíveis. Quando várias opções ou ações são possíveis, a mais provável ou mais lógica pode ser apresentada num formato que a distingue das outras, tal como uma borda circulando um botão (a op&cce dil;ão default). Este é um caso de agrupamento/distinção por formato e não de presteza, já que a opção de apertar para ativá-la não é explícita. A Presteza consiste na apresentação direta de diferentes ações possíveis, enquanto que Agrupamento/Distinção por Formato indicará características particulares das possívei s ações.

Presteza vs. Feedback imediato A distinção entre presteza e feedback imediato é muitas vezes tênue. Na seqüência de uma ação, uma mensagem pode indicar ao usuário que o comando foi executado e também que a& ccedil;ão deve ser tomada para continuar o trabalho. Assim, uma mensagem pode ser ao mesmo tempo um feedback para a(s) ação(ões) prévia(s) e uma condução para as ações subseqüentes . O Feedback imediato diz respeito somente às mensagens que informam ao usuário sobre ações prévias. A Presteza diz respeito a mensagens que ou guiam os usuários para ações futuras, ou sugerem a execução de uma outra ação.

Presteza vs. Legibilidade Os aspectos léxicos que podem influenciar a facilidade da leitura (tamanho ou tipo da fonte, etc.) dos elementos ligados à presteza, dizem respeito à legibilidade.

Presteza vs. ConcisãoUma boa presteza, tal como uma mensagem indicando ao usuário o que ele deve fazer ou ainda uma questão colocada pelo sistema, pode tornar a interação longa demais. Essa característica d a presteza diz respeito ao critério concisão. Da mesma maneira, pode-se indicar corretamente a maneira pela qual os dados devem ser introduzidos, utilizando uma boa presteza. Porém, temos um problema de concisão, se, além dos dados, pede-se ao usuário que indique as unidades de medida. Seria também um problema de concisão se a observação fosse muito longa ou se ela contiv esse termos supérfluos.

Presteza vs. Proteção de erros
A Proteção de erros pode ser alcançada de várias maneiras. Mecanismos automáticos podem ser implementados para controlar as entradas dos usuários. Por exemplo, depois que o usuário digita algo, &eac ute; mostrada uma mensagem avisando que o formato dos dados digitados não é apropriado. Isso diria respeito justamente ao critério Proteção de erros. Uma outra maneira de evitar os erros seria dar aos usuár ios informação sobre o tipo e o formato dos dados a serem digitados. Nesse caso, a presteza estaria envolvida. Essas duas maneiras de evitar erros podem coexistir.

Presteza vs. Qualidade das mensagens de erro
Uma mensagem de erro pode incluir orientação sobre os meios para corrigir erros. Nessas condições, teremos um caso de qualidade das mensagens de erros e não de presteza. Presteza se refere somente &a grave; condução fornecida em situações que não sejam de erro.

Presteza vs. Consistência
Quando a comparação entre transações, objetos, etc., estiver envolvida, mesmo no caso de elementos com objetivo de presteza, o critério em questão será o de consistência. Por exemplo, fornecer uma identificação única para cada tela, sempre em um mesmo lugar no topo da tela, diz respeito à consistência.

REFERÊNCIA: Bastien & Scapin [1993]

02/18 Agrupamento por localização
Verifique se a distribuição espacial dos itens traduz as relações entre as informações

Justificativa(s):

A compreensão de uma tela pelo usuário depende, entre outras coisas, da ordenação dos objetos (imagens, textos, comandos, etc.) que são apresentados. Os usuários irão detectar os diferentes itens mais facilmente se eles forem apresentados de uma forma organizada (em ordem alfabética, freqüência de uso, etc.). Além disso, a aprendizagem e a recuperação de itens será melhorada. O Agrupamento/distinção por localização leva a uma melhor Condução.

Exemplos de Recomendações:

• Organizar os itens em listas hierárquicas
• Organizar as opções de um diálogo por menus, em função dos objetos aos quais elas se aplicam.
• Quando várias opções são apresentadas, sua organização deve ser lógica, isto é, a organização deve representar uma organização funcional relevante ou significativa (ordem alfabética, freqüência de uso, etc.).

Agrupamento/distinção por localização vs. Agrupamento/distinção por formato
O Agrupamento/distinção de itens pode ser alcançado por formato e/ou por localização. Localização e formato correspondem a diferentes características de exibição (topologia vs. adição de características gráficas). Por exemplo, opções de menu podem ser diferenciadas por localização (opções mais freqüentes no topo, menos freqüentes mais para o fundo, etc.) e formato (por exemplo, um separador entre um conjunto de opções relacionadas ao layout do texto e um conjunto de opções relacionadas com os tipos de letra), ou por ambos.

REFERÊNCIA: Bastien & Scapin [1993]

03/18 Agrupamento por formato
Verifique os formatos dos itens como meio de transmitir associações e diferenças.

Justificativa(s):

Será mais fácil para o usuário perceber relacionamento(s) entre itens ou classes de itens, se diferentes formatos ou diferentes códigos ilustrarem suas similaridades ou diferenças. Tais relacionamentos serão mais fáceis de aprender e de lembrar. Um bom agrupamento/distinção leva a uma boa condução.

Exemplos de Recomendações:

• Fazer uma distinção visual clara de áreas que têm diferentes funções (área de comandos, área de mensagens, etc.).
• Fazer uma distinção visual clara dos campos de dados e seus rótulos.

Agrupamento/distinção por formato vs. Presteza
A Presteza ajuda o usuário de uma forma bastante direta, sugerindo ações possíveis. No caso onde muitas opções ou ações são disponíveis (por exemplo, confirmar, cancelar, copiar, etc.), somente as ações poderiam ser mostradas ou indicadas em uma mensagem. Meios menos diretos estão também disponíveis para orientar os usuários. No exemplo acima, se todas as opções são apresentadas, diferentes formatos poderiam ser usados para indicar aquelas que estão d isponíveis. Quando várias opções ou ações são possíveis, a mais provável ou mais lógica pode ser apresentada num formato que a distingue das outras, tal como uma borda circulando um botão (a op&cce dil;ão default). Este é um caso de Agrupamento/Distinção por Formato e não de Presteza, já que a opção de apertar para ativá-la não é explícit a. A Presteza consiste na apresentação direta de diferentes ações possíveis, enquanto que Agrupamento/Distinção por Formato indicará características particulares das possívei s ações.

Agrupamento/distinção por formato vs. Agrupamento/distinção por localização
O Agrupamento/distinção de itens pode ser alcançado por formato e/ou por localização. Localização e formato correspondem a diferentes características de exibição (topologia vs. adi&cced il;ão de características gráficas). Por exemplo, opções de menu podem ser diferenciadas por localização (isto é, opções mais freqüentes no topo, menos freqüentes mais para o f undo) e formato (por exemplo, um separador entre um conjunto de opções relacionadas ao layout do texto e um conjunto de opções relacionadas com os tipos de letra), ou por ambos.

REFERÊNCIA: Bastien & Scapin [1993]

04/18 Feedback
Avalie a qualidade do feedback imediato às ações do usuário.

Justificativa(s):

A qualidade e a rapidez do feedback são dois fatores importantes para o estabelecimento de satisfação e confiança do usuário, assim como para o entendimento do diálogo. Esses fatores possibilitam que o usuá rio tenha um melhor entendimento do funcionamento do sistema. A ausência de feedback ou sua demora podem ser desconcertantes para o usuário. Os usuários podem suspeitar de uma falha no sistema e podem realizar ações prejudiciais para os processos em andamento.

Exemplos de Recomendações:

• Todas as entradas dos usuários devem ser mostradas, com exceção de dados sigilosos. Mesmo neste caso, cada entrada deve produzir um feedback perceptível (por exemplo, símbolos como *).
• Seguindo a interrupção pelo usuário de um processamento de dados, mostrar um mensagem garantindo ao usuário que o sistema voltou ao seu estado prévio.
• Quando o processamento é longo, informações sobre o estado do processamento devem ser fornecidas.

Feedback imediato vs. Presteza
A distinção entre presteza e feedback imediato é, muitas vezes, tênue. Na seqüência de uma ação, uma mensagem pode indicar ao usuário que sua demanda foi executada e também que, para continuar, ele deve fazer determinada ação. Assim, uma mensagem pode ser ao mesmo tempo um feedback para a(s) ação(ões) prévia(s) e uma condução para as ações subseqüentes. O Feedback Imediato diz respeito somente às mensagens que informam ao usuário sobre ações prévias. A Presteza diz respeito a mensagens que ou guiam os usuários para ações futuras ou su gerem a execução de uma dada ação.

Feedback imediato vs. Legibilidade
Quando a qualidade do feedback não é satisfatória, mesmo de um ponto de vista lexical, é uma questão de Feedback Imediato e não de legibilidade. Feedback Imediato diz respeito a todas caracter ísticas das respostas seguindo as ações dos usuários (presença ou ausência de feedback, qualidade do feedback do ponto de vista semântico e lexical).

REFERÊNCIA: Bastien & Scapin [1993]

05/18 Legibilidade
Verifique a legibilidade das informações apresentadas nas telas do sistema.

Justificativa(s):

A performance melhora quando a apresentação da informação leva em conta as características cognitivas e perceptivas dos usuários. Uma boa legibilidade facilita a leitura da informação apresentada. Po r exemplo, letras escuras em um fundo claro são mais fáceis de ler que letras claras em um fundo escuro; texto apresentado com letras maiúsculas e minúsculas é lido mais rapidamente que texto escrito somente com mai&uacu te;sculas.

Exemplos de Recomendações:

• Títulos devem ser centralizados.
• Rótulos devem estar em letras maiúsculas.
• Cursores devem se apresentar distintos dos outros itens.
• Quando o espaço para o texto for limitado, mostrar poucas linhas longas ao invés de muitas linhas curtas.
• Exibir texto contínuo em colunas largas de, ao menos, 50 caracteres por linha.
• A justificação à direita deve ser empregada se puder ser obtida por espaçamento, desde que sejam mantidos espaçamentos proporcionais constantes entre e nas palavras, e espaçamento consistente entre palavras de uma mesma linha.
• Ao exibir um texto, mantenha as palavras intactas, com o mínimo de hifens.

Legibilidade não se aplica a mensagens de feedback ou de erro.
Realmente, todos os aspectos relacionados às dificuldades de leitura das mensagens, ou mais genericamente à qualidade destas mensagens, quando se tratarem de mensagens de feedback ou de erro, deveriam estar relacionados respectivament e aos critérios Feedback Imediato ou Qualidade das Mensagens de Erro.

Legibilidade vs. Feedback imediato
Quando a qualidade do feedback não é satisfatória, mesmo de um ponto de vista lexical, é uma questão de Feedback Imediato e não de legibilidade. O Feedback Imediato diz respeito a todas as características das respostas seguindo as ações dos usuários (presença ou ausência de feedback, qualidade do feedback de um ponto de vista semântico e lexical).

Legibilidade vs. Qualidade das mensagens de erro
Quando mensagens de erro não são satisfatórias, mesmo de um ponto de vista lexical, é uma questão de Qualidade das Mensagens de Erro e não de legibilidade. O critério Qualidade das Mensagen s de Erro diz respeito a todas características das informações relativas aos erros dos usuários.

Legibilidade vs. Presteza
Os aspectos lexicais que podem influenciar a facilidade da leitura (isto é, tamanho da fonte, tipo da fonte, etc.) dos elementos ligados à Presteza, dizem respeito à Legibilidade.

Legibilidade vs. Significância dos Códigos
A Legibilidade não abrange as características semânticas da informação, sua relevância e sua significância. Essas características estarão relacionadas à Significância dos C ódigos.

Legibilidade vs. Compatibilidade
O critério Legibilidade não diz respeito às características semânticas da informação, sua relevância ou sua significância. Quando essas características estão relacionadas &ag rave; tarefa, o critério Compatibilidade deve ser considerado.

REFERÊNCIA: Bastien & Scapin [1993]

06/18 Concisão
Verifique o tamanho dos códigos e termos apresentados e introduzidos no sistema.

Justificativa(s):

A capacidade da memória de curto termo é limitada. Conseqüentemente, quanto menos entradas, menor a probabilidade de cometer erros. Além disso, quanto mais sucintos forem os itens, menor será o t empo de leitura.

Exemplos de Recomendações:

• Para dados numéricos, a entrada de zeros à esquerda não deve ser necessária.
• Se os códigos forem mais longos que 4 ou 5 caracteres, use mnemônicos ou abreviaturas.
• Permitir ao usuário entradas de dados sucintas.
• Quando uma unidade de medida está associada a um campo, inclua a unidade como parte do campo de dados, em vez de fazer o usuário digitá-la.

Concisão vs. Presteza
Uma boa presteza, tal como uma mensagem indicando ao usuário o que ele deve fazer ou ainda uma questão colocada pelo sistema, pode tornar a interação longa demais. Essa característica da presteza diz respeito ao c ritério concisão. Dessa mesma, pode-se indicar corretamente, utilizando uma boa prestabilidade, a maneira pela qual os dados devem ser introduzidos. Porém, temos um problema de concisão se, além de dados, pede-se ao usuário que indique as unidades de medida. É também um problema de concisão se a observação é muito longa ou se ela contém termos supérfluos.

Concisão vs. Ações Mínimas
As Ações Mínimas dizem respeito aos procedimentos ou aos passos. Quando o tamanho dos itens ou das entradas de dados está envolvido, a questão é de Concisão.

Concisão vs. Densidade Informacional
O critério Concisão diz respeito a quão sucinto é uma informação individual, enquanto a Densidade Informacional diz respeito à densidade do(s) conjunto(s) de informação(õe s) apresentada(s) na tela. Assim, um item pode ser relevante mas não apresentado de forma concisa. Nesse caso, teremos o critério Concisão. Se os itens forem supérfluos, será uma questão de Densidade Inf ormacional.

Concisão vs. Qualidade das mensagens de erro
O critério Concisão não se aplica às mensagens de erro. Quando as mensagens de erro não são suficientemente sucintas, é um problema de Qualidade das Mensagens de Erro.

REFERÊNCIA: Bastien & Scapin [1993]

07/18 Ações Mínimas
Verifique a extensão dos diálogos estabelecidos para a realização dos objetivos do usuário.

Justificativa(s):

Quanto mais numerosas e complexas forem as ações necessárias para se chegar a uma meta, a carga de trabalho aumentará e, com ela, a probabilidade de ocorrência de erros.

Exemplos de Recomendações:

• Minimize o número de passos necessários para se fazer uma seleção em menu.
• Não faça o usuário entrar com dados que poderiam ser gerados pelo computador.
• Evite entrada de comandos que exijam pontuação
• Para entrada de dados, exiba os valores default atuais nos campos apropriados.
• Quando várias páginas estiverem envolvidas, torne possível ir diretamente para uma página sem ter que passar pelas intermediárias.

Ações Mínimas vs. Concisão
As Ações Mínimas dizem respeito aos procedimentos ou aos passos; quando o tamanho de itens ou de entradas de dados está envolvido, o problema é de Concisão.

Ações Mínimas vs. Experiência do Usuário
O critério Ações Mínimas diz respeito ao tamanho das transações e procedimentos, qualquer que seja a experiência do usuário. Quando isso for inadequado para um dado grupo de usuários (is to é, quando não existirem atalhos para o usuário experiente), o critério em questão será Experiência do Usuário.

Ações Mínimas vs. Flexibilidade
O critério Flexibilidade diz respeito à possibilidade de executar uma tarefa de diferentes maneiras, isto é, com diferentes procedimentos. Esses procedimentos podem ser mínimos ou não. Esse critério tamb&ea cute;m diz respeito aos meios disponíveis para que o usuário adapte a interface às suas necessidades individuais.

Ações Mínimas vs. Correção de erros
Problemas relacionados ao critério de Ações Mínimas podem resultar de mecanismos inadequados de correção de erros. Quando o número de passos necessários para corrigir um erro pode ser diminu&i acute;do, é uma questão de Correção de Erros. O critério Ações Mínimas diz respeito aos procedimentos, passos ou ações que não estejam relacionados à Corr eção de erros.

Ações Mínimas vs. Compatibilidade
A falta de compatibilidade (isto é, não correspondência dos passos da tarefa com os do diálogo) pode aumentar o número de passos necessários para se executar uma tarefa. Nesse caso o critério Compatibilid ade deve ser invocado, e não Ações Mínimas, sendo este último afetado por conseqüências do problema e não tratando de suas causas.

REFERÊNCIA: Bastien & Scapin [1993]

08/18 Densidade Informacional
Avalie a densidade informacional das telas apresentadas pelo sistema.

Justificativa(s):

Na maioria das tarefas, a performance dos usuários piora quando a densidade de informação é muito alta ou muito baixa. Nesses casos, é mais provável a ocorrência de erros. Itens que não estão r elacionados à tarefa devem ser removidos.
A carga de memorização dos usuários deve ser minimizada. Eles não devem ter que memorizar listas de dados ou procedimentos complicados. Eles não devem, também, ter que executar tarefas cognitivas complexas quando estas não estão relacionadas com a tarefa em questão.

Exemplos de Recomendações:

• Em qualquer transação, fornecer somente dados que sejam necessários e diretamente utilizáveis.
• Os dados não devem necessitar de tradução entre unidades.
• A linguagem de consulta deve usar o mínimo de quantificadores na formulação das consultas.
• Não fazer com que os usuários precisem lembrar de dados exatos de uma tela para outra.
• Prover computação automática de dados derivados, para que o usuário não tenha que calcular e entrar com dados que possam ser derivados de dados já acessíveis ao computador.

Densidade Informacional vs. Concisão
O critério Concisão diz respeito a quão sucinto é uma informação individual, enquanto a Densidade Informacional diz respeito à densidade do(s) conjunto(s) de informação(õe s) apresentada(s) na tela. Assim, um item pode ser relevante mas não apresentado de forma concisa. Nesse caso, teremos o critério Concisão. Se os itens forem supérfluos, será uma questão de Densidade Inf ormacional.

REFERÊNCIA: Bastien & Scapin [1993]

09/18 Ações Explícitas
Verifique se é o usuário quem comanda explicitamente as ações do sistema.

Justificativa(s):

Quando o processamento pelo computador resulta de ações explícitas dos usuários, estes aprendem e entendem melhor o funcionamento da aplicação e menos erros são observados.

Exemplos de Recomendações:

• Sempre faça necessário que o usuário tecle um ENTER explícito para iniciar o processamento de dados digitados; não inicie um processamento (por exemplo, atualizar um arquivo) como efeito colateral de uma outra ação (por exemplo, imprimir um arquivo).
• Se a seleção do menu é feita através de dispositivo de apontamento, faça a ativação em dois passos: a primeira ação (posicionar o cursor) deve designar a opção selecionada e uma segunda ação distinta faz uma entrada de controle explícita.
• Entradas de comandos do usuário devem ser seguidas de um ENTER depois de editadas.

Ações Explícitas do Usuário vs. Controle do Usuário
O critério ações explícitas do usuário deve ser diferenciado de controle do usuário. O primeiro critério se refere ao caráter explícito das ações solicitadas pelos usuários, enquanto que o segundo se refere às capacidades de controle que os usuários devem ter sobre os processamentos em andamento.

REFERÊNCIA: Bastien & Scapin [1993]

10/18 Controle do Usuário
Avalie as possibilidades do usuário controlar o encadeamento e a realização das ações.

Justificativa(s):

O controle sobre as interações favorece a aprendizagem e, assim, diminui a probabilidade de erros. Como conseqüência, o computador se torna mais previsível.

Exemplos de Recomendações:

• Deixar ao usuário o controle do ritmo de suas entradas de dados, e não pelo computador ou por eventos externos.
• O cursor não deve ser automaticamente movido sem o controle do usuário (com exceção de procedimentos estáveis e bem conhecidos como o preenchimento de formulários).
• Possibilitar aos usuários interromper ou cancelar a transação ou processo atual.
• Fornecer uma opção CANCELAR com o efeito de apagar qualquer mudança que acabou de ser feita e trazer a tela para seu estado anterior.

Controle do Usuário vs. Ações Explícitas do Usuário
O critério ações explícitas do usuário deve ser diferenciado de controle do usuário. O primeiro critério se refere ao caráter explícito das ações solicitadas pelos usuários, enquanto que o segundo se refere às capacidades de controle que os usuários devem ter sobre os processamentos em andamento.

REFERÊNCIA: Bastien & Scapin [1993]

11/18 Flexibilidade
Verifique se o sistema permite personalizar as apresentações e os diálogos.

Justificativa:

Quanto mais formas de efetuar uma tarefa existirem, maiores serão as chances de que o usuário possa escolher e dominar uma delas no curso de sua aprendizagem.

Exemplos de recomendações:

• Quando as exigências para o usuário forem imprecisas, fornecer meios para que ele controle a configuração das telas.
• Quando, em algum contexto, a validade de certas apresentações não pode ser determinada, fornecer ao usuário a possibilidade de desativá-las temporariamente.
• Quando os valores por default não são previamente conhecidos, o sistema deve permitir que o usuário defina, mude ou suprima valores.
• A seqüência de entrada de dados deve poder ser modificada para se adaptar à ordem preferida pelo usuário.
• Quando o formato de um texto não puder ser previsto com antecedência, deve-se proporcionar ao usuário os meios para definir e salvar os formatos de que ele venha a precisar.
• O usuário deve poder definir os nomes dos campos de dados que ele(a) venha a criar.

Flexibilidade vs. Ações Mínimas
O critério flexibilidade se refere à existência de procedimentos diferentes, sejam minimizados ou não, permitindo a realização de uma tarefa, ou ainda aos meios que permitem que a interface se adapte à ;s exigências particulares de um usuário.

Flexibilidade vs. Consideração da Experiência do Usuário
A flexibilidade deve fornecer à população geral de usuários os meios para adaptar a interface a suas necessidades particulares. Quando a interface se destina a vários tipos de usuários ou a um tipo particul ar de usuário e permite a realização de uma tarefa de diversas maneiras em função do nível de experiência do usuário, então se trata do critério consideração da experi&e circ;ncia do usuário. Em outros termos, desde que a experiência em relação à interface seja invocada, o critério consideração da experiência do usuário está em jogo.

Flexibilidade vs. Compatibilidade
A flexibilidade pode ser um meio de assegurar uma certa compatibilidade. Entretanto, a flexibilidade pode ser satisfeita sem que a compatibilidade o seja. Assim, em um diálogo por formulário, a ordem e o agrupamento dos campos de entr ada de dados pode ser incompatível com o documento físico. Nesse caso, trata-se de um problema de compatibilidade, quer seja possível (então existe uma certa flexibilidade) ou não (então não há ; flexibilidade) modificar a organização dos campos ou a ordem de passagem de um campo a outro. Nesse caso, o problema a resolver e o critério a evidenciar é a compatibilidade e não a flexibilidade, que &ea cute; um meio de alcançá-la.

REFERÊNCIA: Bastien & Scapin [1993

12/18 Experiência do Usuário
Avalie se usuários com diferentes níveis de experiência têm iguais possibilidades de obter sucesso em seus objetivos.

Justificativa:

O grau de experiência dos usuários pode variar. Eles tanto podem se tornar especialistas, devido à utilização continuada, como menos hábeis, depois de longos períodos de não utilização. A interface deve também ser concebida para lidar com as variações de nível de experiência. Usuários experientes não têm as mesmas necessidades informacionais que os novatos. Todos os comandos ou opções não precisam ser visíveis o tempo todo. Diálogos de iniciativa exclusiva do computador podem entediar e diminuir o rendime nto do usuário experiente. Os atalhos, ao contrário, podem lhes permitir rápido acesso às funções do sistema. Pode-se fornecer aos usuários inexperientes diálogos fortemente conduzidos, ou mesmo passo a passo. Em suma, meios diferenciados devem ser previs tos para lidar com diferenças de experiência, permitindo que o usuário delegue ou se aproprie da iniciativa do diálogo.

Exemplo de recomendações:

• Prever atalhos. Permitir que usuários experientes contornem uma série de seleções por menu através da especificação de comandos ou atalhos de teclado.
• Prever a escolha de entradas simples ou múltiplas conforme a experiência do usuário.
• Autorizar diferentes modos de diálogo correspondentes aos diferentes grupos de usuários (ex. prever uma presteza adaptada ao nível de experiência do usuário).
• Permitir a digitação de vários comandos antes de uma confirmação do usuário experiente.
• Fornecer um tutorial passo a passo para os usuários novatos.
• Quando as técnicas de condução atrasam o usuário experiente, fornecer meios de contornar esta condução.
• O usuário deve poder escolher o nível de detalhe das mensagens de erro em função de seu nível de conhecimento.

Consideração da Experiência do Usuário vs. Flexibilidade
Esse critério não deve ser confundido com o critério flexibilidade. A interface pode ter sido elaborada a fim de considerar certos níveis de experiência, sem que possa ser modificada. Uma interface pode então considerar a experiência dos usuários s em, entretanto, ser flexível. Assim, quando a interface se destina a vários tipos de usuários ou a um tipo particular de usuário, se ela permite a realização de uma tarefa de diversas maneiras, em função do nível de experiência do usuário, então se trata do critério consideração da experiência do usuário. Em outros termos, desde que a experiência em relação à interface seja invocada, está em jogo o critério consideração da experiência do usuário.

Consideração da Experiência do Usuário vs. Ações Mínimas
O critério ações mínimas se refere ao extensão das transações e dos procedimentos, independente do nível de experiência do usuário. Quando essa extensão não parece estar adequado a um grupo particular de usuários (ex. se não existem atalhos de tecl ado), trata-se de um problema ligado ao critério consideração da experiência do usuário.

REFERÊNCIA: Bastien & Scapin [1993]

13/18 Proteção contra erros
Verifique se o sistema oferece as oportunidades para o usuário prevenir eventuais erros.

Justificativa:

É preferível detectar os erros no momento da digitação, do que no momento da validação. Isto pode evitar perturbações na planificação da tarefa.

Exemplos de recomendações:

• Quando o usuário termina uma seção e existe o risco de perda de dados, deve haver uma mensagem avisando desse fato e pedindo confirmação do final da seção.
• Os rótulos dos campos devem estar protegidos (não devem ser acessíveis ao usuário).
• As apresentações que acompanham as entrada de dados devem estar protegidas. Os usuários não podem modificar as informações contidas nesses campos.
• Depois de um erro de digitação de um comando ou de dados, dar ao usuário a possibilidade de corrigir somente a parte dos dados ou do comando que está errada.
• Todas as ações possíveis sobre uma interface devem ser consideradas e, mais particularmente, as digitações acidentais, a fim de que entradas não esperadas sejam detectadas.
• Agrupar os atalhos de teclado por funções perigosas e/ou rotineiras.

Proteção contra os erros vs. Condução
Existem diversas maneiras de fornecer proteção contra os erros. Pode-se, por exemplo, definir um mecanismo automático de verificação das entradas. Assim, no momento da validação, uma mensagem de erro aparec e, se o formato da entrada não está em conformidade com o esperado. Trata-se, nesse caso, do critério proteção contra os erros. Uma outra maneira consiste em fornecer uma informação orientando os usu ários sobre o tipo de dado esperado ou ainda sobre o formato da entrada. Trata-se, agora, do critério condução. São dois mecanismos que podem coexistir.

REFERÊNCIA: Bastien & Scapin [1993]

14/18 Mensagens de erro
Avalie a qualidade das mensagens de erro enviadas aos usuários em dificuldades.

Justificativa:

A qualidade das mensagens favorece o aprendizado do sistema, indicando ao usuário a razão ou a natureza do erro cometido, o que ele fez de errado, o que ele deveria ter feito e o que ele deve fazer.

Exemplos de recomendações:

• Se o usuário pressiona uma tecla de função inválida, nenhuma ação deve ocorrer, a não ser uma mensagem indicando as funções apropriadas a essa etapa da transação.
• Fornecer mensagens de erro orientadas a tarefas.
• Utilizar termos tão específicos quanto possível para as mensagens de erros.
• Utilizar mensagens de erro tão breves quanto possível.
• Adotar um vocabulário neutro, não personalizado, não repreensivo nas mensagens de erro; evitar o humor.

Qualidade das mensagens de erro vs. Condução
Uma mensagem de erro pode incluir informações sobre a maneira de corrigir esse erro. Trata-se aqui do critério qualidade das mensagens de erro e não do critério condução. Este último critério se refere à condução em situação normal, não rela cionada à gestão dos erros.

Qualidade das mensagens de erro vs. Legibilidade
Quando uma mensagem de erro é inadequada sob o ponto de vista lexical, trata-se do critério qualidade das mensagens de erro e não do critério legibilidade. O critério qualidade das mensagens de erro diz respeito a todas as característ icas das informações relativas aos erros dos usuários. A legibilidade diz respeito aos aspectos lexicais de informações que não estão relacionados às mensagens de erro.

Qualidade das mensagens de erro vs. Concisão
O critério concisão não se aplica às mensagens de erro. Quando elas não forem suficientemente sucintas, trata-se de um problema de qualidade das mensagens de erro.

REFERÊNCIA: Bastien & Scapin [1993]

15/18 Correção de erros
Verifique as facilidades oferecidas para que o usuário possa corrigir os erros cometidos.

Justificativa:

Os erros são bem menos perturbadores quando eles são fáceis de corrigir.

Exemplos de recomendações:

• Fornecer a possibilidade de modificar os comandos no momento de sua digitação.
• Quando se verifica erro na digitação de um ou mais comandos, proporcionar ao usuário a possibilidade de refazer a digitação apenas da parte equivocada do(s) comando(s), evitando rejeitar um bloco todo já digit ado.
• Se o usuário não percebe que cometeu um erro de digitação, dar-lhe a possibilidade de efetuar, no momento da detecção do erro, as correções apropriadas.

Correção de erros vs. Ações Mínimas
Os problemas ligados ao critério ações mínimas podem resultar de mecanismos inadequados de correção de erros. Se ocorre um erro e o usuário deve efetuar várias etapas para corrigi-lo, est&aacu te; retratado um problema de correção de erros. O critério ações mínimas diz respeito aos procedimentos e etapas inúteis e desnecessárias para atingir um outro objetivo que é a c orreção dos erros.

REFERÊNCIA: Bastien & Scapin [1993]

16/18 Consistência
Avalie se é mantida uma coerência no projeto de códigos, telas e diálogos com o usuário.

Justificativa(s):

Os procedimentos, rótulos, comandos, etc., são melhor reconhecidos, localizados e utilizados, quando seu formato, localização ou sintaxe são estáveis de uma tela para outra, de uma seção para outra. Nessas condições, o sistema é mais previsível e a aprendizagem mais generalizável; os erros são diminuídos. É necessário escolher opções similares de códigos, procedimento s, denominações para contextos idênticos, e utilizar os mesmos meios para obter os mesmos resultados. É conveniente padronizar tanto quanto possível todos os objetos quanto a seu formato e a sua denominação, e padronizar a sintaxe dos procedimentos. A falta de homogeneidade nos menus, por exemplo, pode aumentar consideravelmente os tempos de procura.
A falta de homogeneidade é também uma razão importante da recusa de utilização.

Exemplos de recomendações:

• Localização similar dos títulos das janelas.
• Formatos de telas semelhantes.
• Procedimentos similares de acesso às opções dos menus.
• Na condução, sempre utilizar as mesmas pontuações e as mesmas construções de frases.
• Apresentar, na mesma posição, os convites (prompts) para as entrada de dados ou de comandos.
• Os formatos dos campos de entrada de dados devem sempre ser os mesmos.

Homogeneidade/Coerência vs. Condução
Quando se trata de considerar ou comparar diversas interações, diversos objetos, etc., aí incluídos os objetos de condução, apela-se para o critério homogeneidade/coerência. Por exemplo, a apre sentação de títulos de janelas em posições idênticas refere-se ao critério homogeneidade/coerência.

Homogeneidade/Coerência vs. Compatibilidade
A homogeneidade/coerência se aplica no âmbito de uma determinada interface. Quando a homogeneidade/coerência se refere aos aspectos externos da aplicação (ex. formulários em papel) ou se refere a outras aplicações ou ambientes, fala-se então da Compatibilidade.

REFERÊNCIA: Bastien & Scapin [1993]

17/18 Significados
Avalie se os códigos e denominações são claros e significativos para os usuários do sistema.

Justificativa:

Quando a codificação é significativa, a recordação e o reconhecimento são melhores. Códigos e denominações não significativos para os usuários podem sugerir operações inadequadas para o contexto, levando a cometer erros.

Exemplos de recomendações:

• O título deve transmitir o que ele representa e ser distinto de outros títulos;
• Explicitar as regras de contração ou de abreviação;
• Utilizar códigos e denominações significativas e familiares em vez de códigos e denominações arbitrárias (ex.: utilizar M para masculino e F para feminino, em vez de 1 e 2).

Significado dos códigos e denominações vs. Legibilidade
O critério legibilidade não se refere aos aspectos semânticos das informações, sua pertinência ou sua significação. Essas características estão relacionadas ao critério significado dos códigos e denominações.

REFERÊNCIA: Bastien & Scapin [1993]

18/18 Compatibilidade
Verifique a compatibilidade do sistema com as expectativas e necessidades do usuário em sua tarefa.

Justificativas:

A transferência de informações de um contexto a outro é tanto mais rápida e eficaz quanto menor é o volume de informação que deve ser recodificada. A eficiência é aumentada quando: os procedimento necessários ao cumprimento da tarefa são compatíveis com as características psicológicas do usuário; os procedimentos e as tarefas são organizadas de maneira a respeitar as expectativas ou costumes do usuár io; quando as traduções, as transposições, as interpretações, ou referências a documentação são minimizadas.
O desempenho é melhor quando a informação é apresentada de uma forma diretamente utilizável (telas compatíveis com o suporte tipográfico, denominações de comandos compatíveis com o vocabulário do usuário, etc.).

Exemplos de recomendações:

• A organização das informações apresentadas deve ser conforme à organização dos dados a entrar.
• O formato das telas deve ser compatíveis com os documentos em papel.
• Os procedimentos de diálogo devem ser compatíveis com a ordem, assim como o usuário a imagina ou conforme o seu costume.
• O formato da data deve respeitar o formato do país em que a aplicação será utilizada (ex.: na França, o formato da data é dia/mês/ano e, na Inglaterra, é mês/dia/ano)
• Os termos empregados devem ser familiares aos usuários, conforme a tarefa a realizar.
• As unidades de medida devem ser as que são normalmente utilizadas.
• A apresentação de texto na tela deve ser conforme às convenções utilizadas para a apresentação de texto em papel.

Compatibilidade vs. Condução
Quando os termos utilizados na condução não são os utilizados freqüentemente pelo usuário, trata-se de um problema de compatibilidade.

Compatibilidade vs. Legibilidade
O critério Legibilidade não se refere aos aspectos semânticos da informação, sua pertinência ou significado. Quando esses aspectos são ligados à tarefa, o critério a considerar é a compatibilidade.

Compatibilidade vs. Ações Mínimas
Uma falta de compatibilidade ( exemplo, falta de adequação dos procedimentos com a ordem da tarefa) pode conduzir ao aumento das ações necessárias à realização da tarefa. Nesse caso, é preciso invocar o critério compatibilidade e não ações mínim as, que é sua conseqüência e não sua causa.

Compatibilidade vs. Flexibilidade
A flexibilidade pode ser um meio de assegurar uma certa compatibilidade. Entretanto, a flexibilidade pode ser satisfeita sem que a compatibilidade o seja. Assim, em um diálogo por formulário, a ordem e o agrupamento dos campos de entrada de dados p odem ser incompatíveis com o documento físico. Nesse caso, trata-se de um problema de compatibilidade, quer seja possível (então existe uma certa flexibilidade) ou não (então não há flexibilidade) modificar a organização dos campos ou a ordem de pa ssagem de um campo a outro. Nesse caso, o problema a resolver e o critério a evidenciar é a compatibilidade, e não a flexibilidade, que é um meio de alcançá-la.

Compatibilidade vs. Homogeneidade/Coerência
A homogeneidade/coerência se aplica no âmbito de uma determinada interface. Quando a homogeneidade/coerência se refere aos aspectos externos da aplicação (ex. formulários em papel) ou se refere a outras aplicações ou ambientes, fala-se então da Compatibilidade.

REFERÊNCIA: Bastien & Scapin [1993]