Pular navegação

Recomendações de usabilidade de Jordan

Ajuda
Licença do Projeto
Todos os direitos reservados.
A Árvore do Conhecimento funciona como um Wiki. Se você quiser acrescentar ou corrigir uma informação, utilize as abas superiores. É preciso estar logado para participar.
Imagem Principal
Este projeto ainda não tem uma imagem principal definida.
Conhecimento
Prestadores de Serviços
Nenhum ainda...
Nenhum ainda...
Site License
Creative Commons Attribution 3.0 Brazil
Creative Commons Attribution

Recomendações de usabilidade de Jordan

Tradução livre de  Recomendações de usabilidade apresentadas por Jordan (1998)

JORDAN, P. W. An Introduction to Usability. Londres: Taylor & Francis Ltda., 1998.

Apresentação: Princípios para design com usabilidade O objetivo deste capítulo é delinear (traçar em linhas gerais) as características do design associadas à usabilidade. Dez princípios de usabilidade são discutidos abaixo com explicações de porque e como cada um dos princípios afeta a usabilidade.

1. Coerência

Projetar um produto com coerência significa que características similares devem ser realizadas da mesma maneira. Isto significa que, como um usuário ganha experiência com o produto, ele pode generalizar o conhecimento sobre o que aprendeu quando é realizada uma tarefa para ajudar a alcançar a outra tarefa. No contexto de um processador de texto, por exemplo, os passos envolvidos na tarefa para colocar o texto em formato negrito, poderão ser da seguinte forma:

1- Selecione o texto para ser editado 2- Abra o menu ‘Formatar’ 3- Selecione o comando ‘Negrito’ Similarmente, os passos envolvidos para colocar o texto em itálico devem ser da seguinte forma:

1- Selecione o texto para ser editado 2- Abra o menu ‘Formatar’ 3- Selecione o comando ‘Itálico’ Neste caso, o procedimento para formatar o texto em negrito seria consistente para formatar textos em itálico. Isto porque para ser formatado, ambos requerem que o texto seja selecionado e ambos requerem que o usuário selecione o menu ‘Formatar’. Estas são tarefas que os usuários provavelmente vão considerar como similar – talvez o usuário pense nelas como ‘tarefas formatadas’ – então é apropriado que o procedimento seja similar para ambos. Se o comando para colocar o texto em itálico fosse colocado num menu diferente, por exemplo, o menu ‘Fonte’ então estas tarefas estariam inconsistentes umas com as outras.

Incoerências são consideradas como um encaminhamento para os erros. No exemplo acima, se o comando ‘itálico’ não estivesse no menu ‘Formatar’, mas o comando ‘Negrito’ sim, então seria possível esperar que o usuário que tivesse aprendido como colocar textos em negrito, iria ao menu errado quando tentasse procurar o comando

itálico, por exemplo, ele selecionaria o menu ‘Formatar’ para procurar o comando de Itálico e ele não estaria lá. O leiaute de controles em carros é um bom exemplo de benefícios de coerência. Os pedais são sempre colocados com a embreagem à esquerda, o freio ao centro e o acelerador à direita. Este tipo de coerência significa que uma vez que alguém tenha aprendido a dirigir, ele pode transferir sua habilidade de um carro para outro. Se, no entanto, não houvesse coerência – isto é, se os pedais fossem organizados diferentemente de um carro para outro – motoristas teriam que fazer muito esforço em aprender como lidar com cada carro que eles encontrassem.

Coerência – Projetar um produto de maneira que as tarefas similares sejam feitas de maneiras similares.

2. Compatibilidade

Projetar para compatibilidade significa assegurar que a maneira que um produto funciona corresponde às expectativas do usuário, baseada no conhecimento que ele tem do mundo real. Assim como a coerência, a compatibilidade é importante porque as pessoas estão sujeitas a tentar generalizar de uma situação para outra, e desta maneira, um projeto que facilite a generalização possibilita que exista mais usabilidade do que um projeto que não facilite. O conceito de compatibilidade é similar ao de coerência, a diferença é que enquanto a coerência se refere a regularidades no design dentro de uma gama de produtos do mesmo tipo, a compatibilidade se refere às regularidades do design entre um produto e as fontes externas. Estas ‘fontes externas’ podem ser outros tipos de produto ou, certamente, alguma coisa do ‘mundo real’ na qual afeta a maneira que o usuário aproxima o uso de determinado produto. Considere, por exemplo, o comando ‘salvar’ num menu dirigido por planilha eletrônica. Imagine que o usuário de um programa semelhante nunca tenha usado uma planilha eletrônica antes, mas lhe são familiares outros menus como os de processadores de texto e de desenho. Com estas aplicações, o comando ‘Salvar’ está quase sempre colocado num menu de título ‘Arquivo’, ele provavelmente o encontrará imediatamente. Neste caso, então, o projeto do programas estaria compatível com as expectativas do usuário baseadas na experiência com outros tipos de programas. Se, no entanto, o comando fosse colocado em um menu diferente, seria incompatível com o que usuário espera e isso provavelmente causaria problemas. Outra questão que afeta a compatibilidade é o que é conhecido como ‘estereótipo da população’. Estas são preposições e associações na qual tendem a serem feitos por quase todos dentro de uma determinada cultura. Em muitas culturas, por exemplo, a cor vermelha é associada a perigo. Conseqüentemente quando projetando, por exemplo, um painel de segurança, os botões que o operador precisa pressionar em caso de emergência seriam de cor vermelha. Similarmente, o verde é frequentemente associado à permissão para prosseguir (no caso de semáforos de trânsito). Seria, então, sensato colorir os botões de verde se eles estiverem associados com a partida de um processo – por exemplo, um botão para partir uma parte de máquinas de produção. Os exemplos de cores citados acima tendem a ser bastante universal entre as culturas, no entanto, existem alguns estereótipos populacionais os quais tendem a ser mais específicos. Nos Estados Unidos e o continente europeu, por exemplo, um interruptor deve estar pressionado para cima para ligar algo, enquanto que no Reino Unido para ligar algo o interruptor deve ser pressionado para baixo. Onde existir este tipo de divisão, é importante que estas questões estejam envolvidas na criação do produto levando em conta os estereótipos associados com o mercado o qual for vender. De novo, a questão de segurança deve ser de suma importância se os usuários podem reverter seus instintos numa situação de emergência. No caso de interruptores, por exemplo, um usuário americano pode instintivamente tentar encontrar um interruptor para pressionar para baixo para fazer com que a máquina desligue. Compatibilidade – Projetar um produto de maneira que o método para operá-lo

seja compatível com a expectativa do usuário baseado no conhecimento de outros tipos de produtos e do mundo real.

3. Consideração sobre a habilidade do usuário

Ao interagir com um produto um usuário pode usar uma variedade de suas habilidades ou ‘canais’. Por exemplo, quando sintoniza um canal de TV, o usuário irá usar suas mãos para pressionar o botão do controle remoto, seus olhos verificam se a imagem é boa e lêem qualquer informação na tela, e seus ouvidos verificam se o som está apropriadamente sintonizado.

É importante que quando se usa um produto, nenhuma das habilidades do usuário seja sobrecarregada – se isso acontecer, é provável que seja um problema de usabilidade. Este livro está sendo escrito em um programa de processador de texto. O uso do processador de texto é uma tarefa na qual precisa de uma alta demanda do canal visual, com olhar fixo se movendo para frente e para trás entre a tela e o teclado. Também é instalado no computador um programa de e-mail. De tempo em tempo as mensagens entram na caixa de e-mails e faz com que surja um pequeno ícone no topo da tela para indicar a chegada da mensagem. Enquanto se concentra visualmente no que está sendo digitado, este ícone é provavelmente muito pequeno para ser notado. No entanto, quando uma nova mensagem chega, ela é acompanhada de um bip. Este som indica que alguma coisa aconteceu e um breve olhar faz com que o ícone se torne visível. Este, então, é um simples exemplo de como o design pode empregar o canal de áudio quando o canal visual está altamente ocupado.

Assim, como outro exemplo simples, considere a diferença entre ouvir um rádio enquanto dirige e assistir TV enquanto dirige. Dirigir é uma tarefa que exige uma demanda visual. É óbvio que o motorista deve estar consciente da posição do carro na estrada bem como possíveis obstáculos, como outros automóveis e pedestres. Embora possa ser argumentado que ouvir rádio cause alguma distração, não existem questões de que carregue o canal visual do motorista. Assistir TV, no entanto, com certeza causaria uma ocupação adicional no canal visual e isto então poderia causar uma significante e perigosa distração na tarefa de dirigir.

Um produto tradicional na qual o princípio de consideração das habilidades do usuário tem sido aplicado é o piano. Pelo fato do usuário do piano utilizar as duas mãos para tocar a melodia, pedais são colocados para que um ou outro diminua ou acentue o som. Isto pode ser feito sem qualquer necessidade do pianista remover suas mãos das teclas do piano. Se as alavancas fossem operadas manualmente, então o pianista encontraria sérias dificuldades.

Consideração das habilidades usuário – Projetar um produto de maneira que se leve em conta a demanda das habilidades do usuário requeridas durante a interação.

4. Retorno das ações /feedback

É importante que as interfaces ofereçam reações claras sobre qualquer ação que o usuário tenha realizado. Isto inclui reação para reconhecer a ação que o usuário tenha que cumprir com o produto, e reação como conseqüência de qualquer ação. Um exemplo de problemas que podem ser associados com a falta de feedback vem de um estudo relatado por Jordan e Johnson (1991). Este foi um estudo de adaptabilidade/ adequação de um controle remoto como dispositivo de entrada para a operação de um som automotivo. Motoristas poderiam usar este dispositivo para aumentar o volume do som, escolher um faixa de um cd para tocar, ou alterar o balanço

do som dos alto-falantes. No caso de mudança de faixa de cd, existia um atraso de alguns segundos antes que a faixa selecionada começasse a tocar – isto ocorria simplesmente devido ao tempo necessário para que o laser no aparelho se movesse na posição correta no disco. Este atraso causou problemas para os usuários porque eles não ficavam imediatamente certos de que tinham realmente feito a ação de entrada

necessária para cumprir a tarefa. Isto podia levá-los a pressionar o botão correto novamente ou tentar pressionar outro botão na suposição de que a primeira ação que tinham realizado seria incorreta. Mais seriamente, isto freqüentemente levava os motoristas a tirar a atenção da estrada para checar se o botão que eles tinham pressionado era o correto.

Uma simples solução para este problema seria ter um feedback audível (como um bip) quando o botão fosse pressionado. Desta maneira os usuários saberiam que teriam feito a ação correta e poderiam voltar toda a sua atenção novamente para dirigir enquanto esperariam a música selecionada começar a tocar.

O exemplo acima relata o reconhecimento de feedback que uma ação deve fazer. Também é importante fornecer feedback mostrando os resultados de uma ação que os usuários fazem. O uso de telefone fornece um simples exemplo. Depois de discar um número, o usuário vai ouvir alguns tipos de tons indicando o número discado – normalmente ou um tom indica que o número discado está chamando ou um tom indica que o telefone discado está em uso (ocupado). É importante que o feedback fornecido seja significativo. No caso dos tons do telefone, o feedback que o usuário recebe não é diretamente um espelho do que está acontecendo, mas são simplesmente sons os quais significam que o usuário precisa aprender por meio da experiência. Isto é provavelmente adequado para um produto simples como um telefone, mas para produtos mais complexos – como programas de computador – um feedback mais representativo pode ser útil. Esta é uma vantagem que pode ser oferecida por algumas interfaces gráficas. Por exemplo, considere novamente o caso da formatação de texto com um processador de texto. Em alguns programas a mudança no texto formatado pode ser representada na tela por uma mudança na cor daquele texto. Então, por exemplo, o texto que o usuário coloca em negrito pode aparecer em vermelho na tela, enquanto que o texto colocado em itálico pode aparecer em azul. Isto é, pelo menos, dado ao usuário feedback como resultado de uma ação tomada, no entanto, o significado do feedback depende que o usuário aprenda e se lembre que o texto em vermelho será impresso em negrito, e textos em azuis, em itálico. Em outros programas, no entanto, o formato que o texto é representado diretamente – então aquele texto em negrito, aparece imediatamente em negrito na tela e texto italizado aparece em itálico. É preferível que o usuário não precise aprender nem lembrar nenhum código de cor, mas possa ver o resultado das ações representadas diretamente na tela. Feedback/ Retorno das ações – Projetar um produto de maneira que as ações tomadas pelo usuário sejam reconhecidas e uma indicação significativa seja dada sobre os resultados dessas ações.

5. Prevenção de erro e recuperação

Parece inevitável que usuários cometam erros de tempo em tempo quando usam um produto. No entanto, os produtos podem ser projetados com a possibilidade de minimizar a ocorrência de erros e o usuário recuperar, de forma rápida e fácil, qualquer erro que tenha feito.

Um exemplo de projeto para recuperação rápida considera uma planilha eletrônica. Normalmente com esses programas o usuário irá digitar em linhas e colunas de números representando o valor de certas variáveis, e então ativará um comando para que se faça algum cálculo desses números. Imagine que enquanto digita os números nas linhas o usuário digite a letra ‘o’ ao invés do numero 0. Quando o usuário for fazer o cálculo este erro causará problemas já que programa não saberá como tratar com a letra que apareceu na coluna de dados. Presumidamente o programa tentará

retornar algum tipo de mensagem de erro, permitindo ao usuário encontrar o dado incorreto (o qual pode ser extremamente difícil, dado que a letra ‘o’ e o número 0 parecem similares), corrigido o erro voltaria ao trabalho de cálculo novamente. Uma solução melhor seria se o programa marcasse o erro tão logo ele ocorresse e alertasse

o usuário do problema. Então, quando o usuário fizesse o erro descrito, uma caixa de diálogo poderia aparecer imediatamente significando que uma entrada de dado não válida teria sido feita. O usuário poderia então corrigir o erro rapidamente antes de continuar a tarefa.

A facilidade do comando ‘desfazer’ disponíveis em muitos programas também é um bom exemplo de como o projeto pode fazer com que o erro possa ser desfeito rápido e facilmente. Estes também são benefícios que encorajam os usuários a ter atitude exploratória quando usam o programa. Além disso, se o usuário tenta usar um comando e algo inesperado ocorre, existe uma ‘segurança’ de saber que a ação pode ser desfeita rapidamente com o comando de ‘desfazer’. Um exemplo de como os erros podem ser prevenidos em primeiro lugar, considere a seqüência de operações que usuários têm que realizar quando utilizam um vídeo- cassete para gravar. O usuário tem que inserir uma série de parâmetros, incluindo a hora que o programa que ele irá gravar começa e termina, o canal de TV que irá passar, a data e o dia da semana que irá ser transmitido. O usuário então ativará o timer e então o VCR irá gravar. Se acontecer de o usuário esquecer de colocar qualquer uma dessas informações ou se esquecer de ativar o timer, uma de duas coisas pode ocorrer – o VCR pode não gravar nada ou pode gravar conforme os parâmetros de padrão do sistema que o usuário tenha adicionado. Desta maneira, se o usuário inseriu parâmetros para o VCR gravar de 17hs às 18hs na quarta-feira, mas esqueceu de inserir o canal, o VCR pode automaticamente gravar em determinado canal, mas provavelmente este não será o canal que o usuário realmente desejava gravar. Muitos vídeos-cassete são projetados para evitar erros de omissão, solicitando o usuário estágio por estágio durante o processo da programação do VCR. Uma vez que o usuário tenha entrado no modo de programação, ele é solicitado primeiramente a inserir a hora na qual ele deseja que a gravação comece, depois então é solicitada a hora de término, depois o canal e assim por diante até que todas as informações sejam inseridas. É preferível um projeto na qual o usuário costume inserir os parâmetros separadamente, porque este tipo de projeto faz com que o usuário se lembre de todos os parâmetros na qual precisam ser colocados.

Prevenção de erro e recuperação – Projetar um produto de maneira que a probabilidade de erro deve seja minimizada e, então, se os erros realmente ocorrerem, que sejam recuperados de forma rápida e fácil.

6. Controle do usuário

Os produtos devem ser projetados de forma que ofereça o máximo de controle possível aos usuários sobre as interações que eles terão com o produto. Isto significa, por exemplo, oferecer controle sobre os passos e o tempo de interação. Uma crítica feita a interfaces sobre comando de fala é que elas tiram o controle de passos de interação do usuário. Por exemplo, Jordan (1992b), quando considerava o usuário de interfaces sobre comando de fala para sistemas de automóveis, notou que às vezes os motoristas podiam ser surpreendidos com informações quando eles não estavam esperando por elas. Imagine por exemplo que o motorista esteja encarregado de realizar manobras complexas como se locomover em fluxo de tráfico em uma rotatória, quando surpreendentemente a interface lhe fornece alguma informação – como a de que a pressão do óleo no motor está muito baixa. Provavelmente, ou o motorista perderá a informação porque estava concentrado na manobra, ou estará distraído com a manobra na possibilidade de oferecer risco à segurança. Um mostrador visual seria mais apropriado para informações urgentes dede que o motorista possa checá-las quando se sentir seguro para fazê-lo.

Outro tipo de interface na qual pode tirar controle do usuário são aquelas com a facilidade de time-out. Alguns VCRs, por exemplo, tem facilidade de time-out em seus sistemas. Isto significa que se o usuário não insere nenhum tipo de informação durante um período de tempo (talvez cerca de 30 segundos) então o VCR sairá do sistema. Um

estudo experimental que pesquisou a usabilidade de VCRs identificou que este era um problema de usabilidade (Jordan, 1992b). Freqüentemente, quando programando o VCR, os usuários paravam a tarefa para consultar o manual e quando voltavam seu olhar para o display, o VCR voltava para outro modo no sistema. A facilidade de Time- out pode causar determinados problemas para usuários novatos de um produto porque eles precisam de um tempo maior do que usuários experientes para mudar de um estágio da tarefa para o próximo. Talvez uma solução melhor, seria simplesmente incluir algum tipo de botão ‘home’, caso o usuário se sentisse perdido no sistema, ele poderia retornar num modo mais familiar dentro do sistema, de maneira rápida e fácil – com esta solução o usuário poderia ter a preferência e então estaria no controle.

No caso de programas de computador isto poderia ter implicações com algum padrão incluso no sistema. Os padrões podem fornecer benefícios para os usuários em termos de velocidade com o qual eles conseguem no uso do programa. De novo, considerando processadores de texto, imagine o tempo e esforço que seria envolvido em inserir todas as preferências de tamanho de texto para a largura de margens para cada palavra digitada! No entanto, é importante que os usuários estejam informados quais padrões têm sido usados e que esteja claro como podem alterá-los se desejar isto.

Projetos com ajustes é outro bom exemplo de como usuários podem ter controle. Quando se projeta uma cadeira, por exemplo, o designer deve tentar assegurar que as dimensões estejam apropriadas para os usuários destinados, mas ao mesmo tempo pode ser possível que o usuário ajuste facilmente as dimensões de forma que a altura do assento ao chão e o ângulo do encosto se acomodem às suas preferências particulares. Controle do usuário – Projetar um produto de maneira que o usuário tenha o máximo controle possível sobre as ações tomadas no produto.

7. Clareza visual

É importante que a informação seja apresentada de forma que ela possa ser lida rápida e facilmente sem causar qualquer confusão. Isto também inclui tanto os rótulos e informação quanto feedback. Os envolvidos no projeto do produto devem levar em conta questões como caracteres terem tamanho suficiente para serem lidos, qual quantidade de informação pode ser colocada em determinado espaço sem que se torne muito poluído, como cores podem ser efetivamente usadas na interface (enquanto ainda levem em conta que uma significante proporção da população sofra de daltonismo), e onde as informações podem ser colocadas.

Interfaces de tela para canais de TV são bons exemplos de produto onde essas questões são importantes. Devido à tela da TV ser usada, existe uma preponderância a usar muitas cores na interface. Isto pode ser beneficamente usado para distinguir modos – por exemplo, controles para alterar a imagem podem ser em azul. Cores podem também ser úteis onde o usuário precisar selecionar um comando de um menu on-screen. Como os usuários rolam através de listas o comando selecionado pode aparecer em vermelho. Aqueles envolvidos no projeto de interfaces on-screen devem também levar em conta a distância que o usuário estará da tela quando interagir. Normalmente estas interfaces podem ser operadas via controle remoto, então os usuários estarão provavelmente sentados numa cadeira a alguma distância. É claro, então, que é importante que os caracteres sejam grandes suficientes para serem lidos de determinada distância. Muitas TVs, especialmente as mais novas no mercado tem uma grande quantidade de diferentes funções. Os profissionais devem considerar quantas funções diferentes podem ser apresentadas de uma vez sem causar confusão. Quanto mais for apresentado de uma vez, menos será solicitado no menu estrutural – uma vantagem é que é menos provável que o usuário se perca no sistema. Por outro lado, apresentando muita informação de uma vez podem ser uma desvantagem porque os usuários terão que procurar entre muitas informações aquilo que desejam. A questão da posição da informação também é importante. Primeiramente, os profissionais devem decidir se a tela inteira deve ser usada como área de apresentação da informação ou se apenas uma parte dela será utilizada. É preferível usar a tela inteira para evitar poluição visual. Também é bom para usar caracteres maiores, melhorando a legibilidade. Por outro lado, quanto mais tela é preenchida com o display, mais imagem da TV é ocultada quando o usuário ajusta as posições. Uma outra questão focada na posição da informação é considerar se deve colocar ou não em opaco a imagem atrás dos menus. Isto provavelmente tornará o display mais fácil de ler com relação a ocultar mais imagem da TV. A alternativa é usar a imagem da TV como fundo dos menus, mas talvez isso cause poluição na tela dependendo do que se passar na TV naquele momento. Claro que a clareza visual não é importante somente para displays de telas. Também é importante, por exemplo, na questão de rotulação em interfaces baseadas em ‘botões e sintonizadores’. Então, é importante que rótulos para botões e teclas sejam claros. Com interfaces que contenham muitos sintonizadores – por exemplo, alguns painéis de controle – estes devem ser claramente distinguidos uns dos outros e devem ser espaçados de forma que eles estejam numa área visível, mas não tão perto que faça com que o display fique poluído. Clareza visual – Projetar um produto de maneira que a informação apresentada seja lida de forma rápida e fácil sem causar confusão.

8. Priorização da funcionalidade e da informação

Quando um produto tem uma vasta variedade de características, pode ser apropriado priorizar algumas características ao projetar a interface do produto. A priorização pode ter como base a freqüência de uso de determinadas características ou a comparação da importância de diferentes funções. Decidas as funções mais importantes, àquelas consideradas com maior prioridades podem, então, ser dadas maior lugar de destaque no projeto.

O projeto de interfaces gráficas para programas de computador é um bom exemplo de onde tais questões podem surgir. Freqüentemente essas aplicações contêm centenas de características as quais podem ser invocadas por meio de seleção de comandos em menus. Enquanto um grupo de comandos adequados e menus significativos trarão benefícios em termos de usabilidade, ainda existe perigo de que o número total de comandos aumentará o tempo necessário para procurar qualquer um deles. Uma solução comum e efetiva para este problema é incluir barras de ferramentas na interface. Uma barra de ferramentas contém ícones que representam certas características do produto. Usando estes ícones o usuário pode ativar certos comandos sem ter que usar os menus. Colocando as funções mais comumente utilizadas na barra de ferramentas podem então poupar o usuário de gastar muito tempo e esforço procurando comandos mais freqüentes em meio a uma grande lista junto de outros comandos não tão usados.

Uma outra maneira de direcionar esta questão de menus em programas é o uso de estruturas hierárquicas. Quando o usuário abrir um menu, o comando que é mais freqüentemente usado pode ser imediatamente visível, enquanto que este menu hierárquico pode também incluir comandos de ‘passagem’ para submenus onde os comandos menos usados podem ser acessados.

O mesmo princípio é aplicado para apresentação de informação – somente algumas funções são mais comuns que outras, e também é verdade que existam algumas informações que querem ser mais vistas mais freqüentemente que outras. O uso de modos de displays padrões pode trazer estes benefícios.

Considere, por exemplo, a tela de display em um VCR (vídeo cassete recorder). Normalmente, existe apenas uma pequena área disponível para isso, no entanto, potencialmente, muita informação pode ser apresentada. Isto inclui, por exemplo, a hora atual, o canal que está sendo assistido, o modo que o vídeo está (se play, Record, stop, etc.), e a informação sobre as seqüências de gravação que foram programadas para o VCR. É claro que, apresentando todas essas informações no display ao mesmo tempo, causaria uma imensa poluição visual e seria extremamente difícil de ler. Para fazer com que esse problema seja evitado, a maior parte dos VCRs são projetados com um modo de display padrão – normalmente a hora atual – com outras informações acessíveis via botões. O modo de display padrão representa, com efeito, a priorização da informação na qual ela é colocada de tal modo que outras informações também possam ser apresentadas.

Priorização da funcionalidade e da informação – Projetar um produto de maneira que a funcionalidade e a informação mais importantes sejam facilmente acessadas pelo usuário.

9. Transferência adequada de tecnologia

Tecnologias que foram desenvolvidas para um propósito sendo aplicadas para outra área podem trazer grandes benefícios para os usuários. No entanto, se feitas sem cuidado suficiente podem também trazer problemas. Considere o histórico do controle remoto da TV. Este aparelho foi originalmente desenvolvido como ajuda a pessoas deficientes que tivessem dificuldades em se locomover até a TV para mudar o canal, alterar o volume, etc. O aparelho foi então adotado pela indústria como algo para ser usados por todos os usuários e hoje vem como acessório padrão em quase todas as TVs. De fato, hoje é comum que mais funções sejam acessadas via controle remoto do que no próprio painel na TV. Isto é um bom exemplo de como transferir a tecnologia desenvolvida de um determinado grupo de usuários para uma grande população lhes trazendo benefícios. Além disso, as pessoas preferem ficar sentadas confortavelmente em suas cadeiras a se levantando para mudar de canal ou alterar algum parâmetro.

Conseqüentemente, o controle remoto tem também sido implementado a outros produtos, desde aparelhos de som, VCRs e sistemas de iluminação – novamente trazendo benefícios em termos de conveniência para o usuário. Outra área onde se tem implementado controles remotos para entradas são os aparelhos de som automotivos (Jordan, 1992b). No entanto, os benefícios da aplicação neste contexto são duvidosos. Um controle remoto é conveniente para usar quando sentado em frente à TV, assim como todos os usuários têm que fazer, pegar o controle, apontá-lo para o aparelho e pressionar o botão apropriado. Estas simples ações, no entanto, podem se tornar muito mais difíceis quando dirigindo um carro ao mesmo tempo. Em primeiro lugar, localizar o controle remoto pode comprovar a dificuldade. Talvez o motorista tenha que colocá-lo no painel do carro ou na parte de baixo da alavanca de câmbio. Qualquer seja o caso, o motorista pode ter que olhar em volta até que o encontre e então, talvez depois de ter procurado para pegar o controle, terá que colocá-lo corretamente na mão para poder apontá-lo em direção ao rádio. É provável que essa perda de tempo seja mais preocupante, pois desviará a atenção do motorista da estrada. De fato, um estudo relatado por Jordan e Johnson (1991), indicou que o uso de controle remoto para operar um aparelho de som automotivo aumentou o nível de exigência do motorista comparado com a técnica convencional de pressionar os botões no próprio aparelho.

Outro exemplo de ambiente em automóveis na qual transfere a tecnologia, e que pode não trazer os benefícios esperados, é o uso de head-up displays (HUDs). Estes são desenvolvidos originalmente para uso em aeronaves onde tem se comprovado uma interface bem sucedida. Neste caso, a informação é projetada na frente do pára-brisa da aeronave onde a informação pode ser lida sem que o piloto tenha que olhar para baixo no painel de controle. Isto funciona bem porque a cena fora da aeronave, da qual é formado o fundo da informação, é geralmente apresentada por um céu claro.

Se as HUDs fossem usadas em veículos, no entanto, a visão através do pára-brisa seria muito mais poluída – contendo, por exemplo, outros veículos, pedestres, a estrada, árvores, etc. Qualquer informação apresentada ma tela teria que ser lida contra este fundo, o que poderia ser bem difícil. De fato, a informação apresentada na tela poderia ser simplesmente dificultada por qualquer outra informação visual.

Transferência adequada de tecnologia – Projetar um produto de maneira que se faça uso adequado de tecnologias desenvolvidas para outros contextos para aumentar a usabilidade do produto.

10. Explicitação

Produtos devem ser projetados de forma que seja claro a forma como operá-los. Como simples exemplo, considere o projeto de portas em prédios públicos. Quando alguém se dirige a uma porta deve decidir se irá abri-la empurrando ou puxando. Se a porta é bem projetada estará claro qual a forma correta para abri-la. Uma chapa metálica nas portas indica que a porta deve ser empurrada, enquanto que uma barra que pode ser segurada, indica que puxar é a forma adequada. Este exemplo se refere ao que Norman (1988) diz sobre ‘Fornecimento’ (Affordance). Fornecimento são propriedades do projeto os quais fornecem fortes indícios de como o produto funciona – em outras palavras, eles fazem com que o método de operação seja explícito.

Com programas de computadores, a representação de comandos é um exemplo de onde a explicitação pode fazer com que o produto tenha mais usabilidade. Com menu dirigido a sistemas, os comandos que são representados explicitamente são aqueles que o nome do comando significa claramente a sua função. Por exemplo, o comando para enviar o texto num arquivo de texto ou figuras em programa de dados estatísticos para imprimir, normalmente é nomeado de ‘Imprimir’. Para a maioria dos usuários, a função deste comando é provavelmente clara com este nome. Se houver um caso que esta função for apenas ativada pela tecla de nome ‘F1’, então a representação do comando não estaria explícita, pois não existirá razão para que a tecla ‘F1’ represente a impressão.

Onde funções são representadas por ícones, o projeto destes ícones também afetará a explicitação pela qual as funções são representadas. Um estudo feito por Maissel (1990) classificou ícones e o quanto representativos eles eram – quanto mais representativo, mais os usuários associavam o ícone com sua função. Estudos realizados por Moyes e Jordan (Moyes e Jordan, 1993; Jordan e Moyes, 1994), indicaram que a representação tinha efeito acentuado na suposição tomada pelos usuários e algum efeito sobre os estágios de aprendizado de usabilidade. Em outras palavras, durante as suas primeiras interações com o produto, os usuários confiam nas representações dos ícones para identificar as funções que o ícone representa. (A propriedade representativa é menos salientada em termos de efeito no desempenho de usuários experientes, neste estágio, os usuários freqüentemente são capazes de lembrar quais ícones estão associados com quais funções, mesmo se os ícones não são representativos).

Explicitação – Projetar um produto de maneira que sejam dados indícios de como ele funciona e o método para operá-lo.

Precisa de ajuda?

Conhecimento

A Árvore do Conhecimento é um espaço para compartilhar e aprender sobre Design. Funciona como um wiki, ou seja, um texto colaborativo. Qualquer pessoa pode:

  • Adicionar novos Conhecimentos
  • Anexe arquivos em páginas para compartilha-los com outros.
  • Adicionar comentários e revisões
  • Arquivar conhecimentos que estão desatualizados ou incorretos