ENGENHARIA DE USABILIDADE:

UMA ABORDAGEM ERGONMICA

Walter de Abreu Cybis
Laboratrio de Utilizabilidade de Informtica
Florianpolis, Maio de 2003
Engenharia de usabilidade: uma abordagem ergonmica
ii
ENGENHARIA DE USABILIDADE:
UMA ABORDAGEM ERGONMICA
SUMRIO
INTRODUO................................................................................................................................... 1
USABILIDADE E A ERGONOMIA.............................................................................................................. 2
ENGENHARIA DE USABILIDADE ............................................................................................................. 4
INTERFACE COM O USURIO.................................................................................................................. 5
ESTA APOSTILA...................................................................................................................................... 5
PRIMEIRA PARTE : FUNDAMENTOS TERICOS DA ENGENHARIA DA
USABILIDADE................................................................................................................................... 7
1. O TRABALHO E SUAS PERSPECTIVAS ............................................................................. 7
1.1 FUNCIONAMENTO E UTILIZAO............................................................................................... 7
1.2 TAREFA E ATIVIDADE ................................................................................................................ 8
1.3 A DINMICA DO TRABALHO...................................................................................................... 9
1.4 O CONTEDO DO TRABALHO ................................................................................................... 10
2. A PSICOLOGIA COGNITIVA............................................................................................... 13
2.1 OS MODELOS MENTAIS............................................................................................................. 13
2.2 A PERCEPO.......................................................................................................................... 15
2.2.1 A percepo visual ....................................................................................................... 16
2.2.2 A percepo auditiva.................................................................................................... 16
2.2.3 A percepo da fala...................................................................................................... 16
2.2.4 Ateno e Vigilncia .................................................................................................... 17
2.3 A MEMRIA............................................................................................................................. 18
2.3.1 Modelos cognitivos para a memria............................................................................ 19
2.4 O RACIOCNIO E O APRENDIZADO ........................................................................................... 20
2.5 O CURSO DAS AES .............................................................................................................. 21
2.5.1 A anlise de uma situao............................................................................................ 21
2.5.2 A planificao das aes.............................................................................................. 22
2.5.3 O Controle das aes ................................................................................................... 23
3. A COMUNICAO E A SEMITICA................................................................................. 24
3.1 A TEORIA DE COMUNICAO.................................................................................................. 24
3.1.1 Indicao e Significao .............................................................................................. 25
3.2 A SEMITICA........................................................................................................................... 26
3.3 OS COMPONENTES DE UM SINAL .............................................................................................. 26
3.4 A FORMAO DE UM SINAL ..................................................................................................... 27
3.5 A SEMITICA COMPUTACIONAL............................................................................................... 28
3.5.1 Sinais Computacionais................................................................................................. 29
SEGUNDA PARTE: FERRAMENTAS PARA A ENGENHARIA DE USABILIDADE......... 31
4. QUALIDADES ERGONMICAS PARA IHC ..................................................................... 31
4.1 A CONDUO.......................................................................................................................... 31
4.1.1 Presteza........................................................................................................................ 31
4.1.2 Feedback Imediato....................................................................................................... 32
4.1.3 Legibilidade.................................................................................................................. 32
4.1.4 Agrupamento/Distino de Itens .................................................................................. 32
4.1.4.1 Agrupamento/Distino por Localizao ............................................................................. 33
4.1.4.2 Agrupamento/Distino por Formato................................................................................... 33
4.2 A CARGA DE TRABALHO......................................................................................................... 33
Engenharia de usabilidade: uma abordagem ergonmica
iii
4.2.1 Brevidade ..................................................................................................................... 34
4.2.1.1 Conciso............................................................................................................................... 34
4.2.1.2 Aes Mnimas..................................................................................................................... 34
4.2.2 Densidade Informacional ............................................................................................. 34
4.3 O CONTROLE EXPLCITO ......................................................................................................... 35
4.3.1 Aes Explcitas do Usurio ........................................................................................ 35
4.3.2 Controle do Usurio..................................................................................................... 35
4.4 A ADAPTABILIDADE................................................................................................................ 35
4.4.1 Flexibilidade ................................................................................................................ 36
4.4.2 Considerao da experincia do usurio..................................................................... 36
4.5 A GESTO DE ERROS............................................................................................................... 36
4.5.1 Proteo contra os erros.............................................................................................. 37
4.5.2 Qualidade das mensagens de erro ............................................................................... 37
4.5.3 Correo dos erros....................................................................................................... 37
4.6 A HOMOGENEIDADE/COERNCIA............................................................................................ 37
4.7 O SIGNIFICADO DOS CDIGOS E DENOMINAES.................................................................... 38
4.8 A COMPATIBILIDADE............................................................................................................... 38
5. MODELO DE COMPONENTES DE IHC............................................................................. 39
5.1 INTRODUO AO MODELO LINGSTICO................................................................................. 39
5.2 OS COMPONENTES DA INTERAO HUMANO-COMPUTADOR .................................................. 40
5.2.1 Os dilogos................................................................................................................... 43
5.2.1.1 Aes.................................................................................................................................... 43
5.2.1.2 As Tarefas ............................................................................................................................ 43
5.2.1.3 Os Estilos dos Dilogos........................................................................................................ 44
5.2.1.4 Estruturas de interaes........................................................................................................ 45
5.2.2 Os Objetos de Interao............................................................................................... 46
5.2.2.1 Os Painis de Controle ......................................................................................................... 47
5.2.2.2 Os controles compostos........................................................................................................ 51
5.2.2.3 Os grupos de controles ......................................................................................................... 58
5.2.2.4 Os controles simples............................................................................................................. 59
5.2.2.5 Os campos de entrada........................................................................................................... 61
5.2.2.6 Os mostradores estruturados ................................................................................................ 63
5.2.2.7 Os Mostradores Simples....................................................................................................... 68
5.2.2.8 As Orientaes ..................................................................................................................... 68
5.2.3 Os Sistemas de Significado........................................................................................... 71
5.2.4 As Primitivas ................................................................................................................ 76
5.2.4.1 As formas visuais ................................................................................................................. 76
5.2.4.2 Formas sonoras..................................................................................................................... 78
TERCEIRA PARTE: O CICLO DA ENGENHARIA DE USABILIDADE............................... 79
6. ABORDAGEM PARA A ENGENHARIA DE USABILIDADE.......................................... 79
6.1 O ENVOLVIMENTO DO USURIO NO PROJETO........................................................................... 80
6.1.1 As formas de envolvimento........................................................................................... 81
6.1.2 Organizao para o envolvimento do usurio ............................................................. 82
6.2 O CICLO DA ENGENHARIA DA USABILIDADE ........................................................................... 82
7. A PERSPECTIVA DA ANLISE........................................................................................... 85
7.1 DEFINIO DO ESCOPO DO SISTEMA........................................................................................ 85
7.2 ANLISE DO USURIO ............................................................................................................. 85
7.3 ANLISE DO TRABALHO.......................................................................................................... 86
7.3.1 Anlise das Tarefas ...................................................................................................... 87
7.3.1.1 Entrevistas com gerentes...................................................................................................... 87
7.3.1.2 Entrevistas com usurios...................................................................................................... 88
7.3.1.3 Descrio das tarefas............................................................................................................ 88
7.3.2 Anlise do Ambiente..................................................................................................... 88
7.3.3 Anlise das atividades.................................................................................................. 89
7.3.3.1 Anlise de situaes de normalidade.................................................................................... 89
7.3.3.2 Anlise de Situaes Crticas ............................................................................................... 90
7.3.3.3 Anlise de situaes de Erros e Incidentes........................................................................... 90
7.3.4 A elaborao do Relatrio de Anlise.......................................................................... 90
Engenharia de usabilidade: uma abordagem ergonmica
iv
7.4 ANLISE DAS POSSIBILIDADES E RESTRIES TECNOLGICAS ................................................. 91
8. A PERSPECTIVA DA SNTESE............................................................................................ 92
8.1.1 Especificao do Contexto de Uso............................................................................... 92
8.1.2 Definio da nova estrutura do trabalho ..................................................................... 92
8.1.3 Especificao da usabilidade esperada ....................................................................... 93
8.1.4 O Projeto da Interface.................................................................................................. 94
8.1.4.1 The Bridge - Projeto de IHC orientado objetos. ................................................................ 94
8.1.4.2 Usage-Centered Design (Constantine, 1999) ...................................................................... 98
8.2 CONSIDERAES SOBRE O PROJETO DE IHC.......................................................................... 104
9. A PERSPECTIVA DA AVALIAO.................................................................................. 106
9.1 PROBLEMA DE USABILIDADE ................................................................................................. 106
9.1.1 Contexto de um problema de usabilidade .................................................................. 106
9.1.2 Efeitos de um problema de usabilidade...................................................................... 107
9.1.3 A descrio de um problema de usabilidade.............................................................. 107
9.1.4 Tipos de problemas de usabilidade ............................................................................ 108
9.2 OBJETIVOS DE UMA AVALIAO DE USABILIDADE................................................................. 109
9.3 TCNICAS PROSPECTIVAS...................................................................................................... 110
9.4 TCNICAS PREDITIVAS OU DIAGNSTICAS ............................................................................ 111
9.4.1 Avaliaes Analticas ................................................................................................. 111
9.4.2 Avaliaes Heursticas............................................................................................... 112
9.4.2.1 Avaliaes Heursticas de Usabilidade............................................................................... 112
9.4.2.2 Inspeo Cognitiva da Intuitividade................................................................................... 114
9.4.2.3 Inspees preventivas de erros ........................................................................................... 115
9.4.3 Inspees Ergonmicas via Checklists....................................................................... 115
9.5 TCNICAS OBJETIVAS............................................................................................................ 117
9.5.1 Ensaios de interao .................................................................................................. 117
9.5.1.1 As caractersticas dos ensaios............................................................................................. 117
9.5.1.2 Montagem de um ensaio de interao ................................................................................ 121
9.5.2 Os sistemas de monitoramento................................................................................... 126
9.6 COMPROMISSO ENTRE TCNICAS DE AVALIAO................................................................... 127
9.7 PROJETO DE AVALIAO....................................................................................................... 128
9.8 PLANO DE TESTES.................................................................................................................. 129
10. A NORMA ISO 9241 .......................................................................................................... 131
10.1 VERIFICANDO AS QUALIDADES ERGONMICAS ATRAVS DA ISO-9241................................. 134
11. REFERNCIAS BIBLIOGRFICAS.............................................................................. 136
1
ENGENHARIA DE USABILIDADE:
UMA ABORDAGEM ERGONMICA
Introduo
No incio, os usurios de programas de software eram os
seus prprios desenvolvedores. Mais tarde estes programas
passaram a ser destinados a um pequeno pblico de usurios
externos, que recebiam treinamento pesado. At a, tudo ia
relativamente bem com as interfaces humano-computador, mas
quando os programas de computadores passaram a ser
destinados a um pblico mais amplo e menos treinado, e os
sistemas passaram a ser propostos como produtos, destinados
ao mercado consumidor, a coisa comeou a no dar certo. A
falta de interesse pela lgica de utilizao, fazia com que as
interfaces com os usurios fossem sempre deixadas como ltima
coisa no desenvolvimento. Interfaces difceis, feitas as pressas,
contribuiram para a famosa "barreira da informtica", que nos
anos 80, fez com que a disseminao dos computadores e de
produtos de software ficasse s como uma promessa.
Muita coisa evoluiu de l para c, mas mesmo nos nossos
dias, so frequentes casos de interfaces que se colocam como
barreiras. Veja um exemplo de uma interface engessada, pois
inadequada para quem tenha trocado de endereo e ainda no
tenha decorado o novo CEP.
Este exemplo mostra que quando um novo dispositivo,
sistema interativo ou ferramenta informatizada introduzido em
um sistema de trabalho, ele causa um forte impacto na maneira
como os usurios desenvolvem as estratgias que iro utilizar
em suas atividades.
2
As consequncias de experincias negativas variam desde
pequenos aborrecimentos e frustraes. No exemplo
apresentado, o usurio pode sentir-se diminuido perante os
outros e se culpar por no conseguir interagir ou no entender o
que todo mundo usa. Em outras interfaces, de uso mais
frequente e profissional, os aborrecimentos e frustraes podem
levar a ansiedade e ao estresse, devido a sequncia de
experincias negativas, da presso pela obrigao do uso
imposta pela chefia. Em casos mais agudos, o estresse no
liberado pode levar a psicopatologias, em um processo pelo qual
o usurio apresenta-se inicialmente irritado, deprimido, estpido
com os colegas, mais tarde sente-se perseguido, apresenta
dores de cabea constantes, clicas abdominais. Em casos
extremos, ele pode desenvolver ansiedade generalizada,
comportamento compulsivo, crises de pnico...
Pelo lado da empresa, interfaces difceis, que aumentam a
carga de trabalho do usurio, trazem conseqncias negativas
que vo desde a resistncia ao uso, passando pela
subutilizao, chegando ao abandono do sistema. Dependendo
da escala em que o software empregado os prejuzos para a
empresa podem ser expressivos.
As causas de fatos negativos como estes continuam a ser:
o desconhecimento da atividade, o desconhecimento do
cognitivo humano, o desinteresse pela lgica de utilizao e a
falta de ferramentas lgicas para o desenvolvimento da
usabilidade.
O desenvolvimento de sistemas com boa usabilidade ir
impactar a tarefa no sentido da eficincia, eficcia, produtividade
da interao. O usurio ir atingir plenamente seus objetivos com
menos esforo e mais satisfao. Eventualmente, uma interface
poder ter fins teraputicos e contribuir para aliviar as frustraes
e o stress do dia a dia. (Picard, 2002) A usabilidade ir impactar
positivamente o retorno do investimento para a empresa. Ela
ser argumento de vendas, passar uma imagem de qualidade,
evitar prejuzos para os clientes, ligados ao trabalho adicional e
ao retrabalho de correes freqentes, por exemplo. A empresa
desenvolvedora ir certamente economizar custos de
manuteno e de revises nos produtos, como mostra o texto
sobre Engenharia de Usabilidade (Nielsen, 1993).
Usabilidade e a Ergonomia
Usabilidade definida como a capacidade que um sistema
interativo oferece a seu usurio, em um determinado contexto de
operao, para a realizao de tarefas, de maneira eficaz,
eficiente e agradvel (ISO 9241). A intuitividade, a facilidade e a
eficincia de uso em um dispositivo informatizado contribuem
para sua usabilidade, e a Ergonomia tm muito em comum com
isso tudo. Afinal, esta disciplina visa a adaptao do trabalho ao
3
homem, por meio de sistemas e dispositivos que estejam
adaptados a maneira como o usurio pensa e trabalha. Para a
construo de interfaces amigveis ou ergonmicas, o
engenheiro de usabilidade deve, entre outras coisas, conhecer
muito bem o usurio e o seu trabalho.
Primeiro, porque as pessoas tm formas particulares de
pensar e trabalhar, que em geral so muito mais elaboradas do
que as imaginadas por projetistas de interfaces, que no
consideram estratgias de aprendizado, de erros e de economia,
por exemplo. Segundo, porque a maneira de pensar e trabalhar
conseqncia direta das caractersticas do dispositivo que
introduzido no local de trabalho do usurio. A atividade tem que
ser pensada como uma evoluo, na medida em que ao
perceberem completamente o dispositivo, as pessoas passam a
us-lo de forma diferente. Terceiro porque o computador e sua
interface representam uma ferramenta cognitiva, uma extenso
da memria, uma prtese cognitiva que permite tratar melhor a
informao. importante que se conhea como os processos
cognitivos humanos se desenvolvem para a concepo de
prteses cognitivas compatveis com eles.
A usabilidade uma qualidade de uso, ou seja, ela se
define quando do uso do sistema. Isto quer dizer que ela
definida ou medida para um contexto em que um sistema
operado. Assim, um sistema pode proporcionar boa usabilidade
para um usurio experiente, mas pssima para novatos, ou vice
e versa. Pode ser fcil de operar se o sistema for usado
esporadicamente, mas difcil, se for utilizado freqentemente, no
dia a dia. Uma interface bonita pode dar prazer se o site for
acessado por conexes rpidas, mas causar ansiedade
insuportvel se ele for acessado de casa, via modem.
Mas como conceber algo amigvel em tantas situaes
diferentes? A adaptabilidade uma, entre as qualidades de uma
interface com o usurio. Um interface adaptvel permitir que
diferentes usurios, em diferentes estgios de competncia, em
diferentes tarefas e em diferentes ambientes fsicos, tecnolgicos
e organizacionais, possam alcanar seus objetivos com eficcia,
eficincia e satisfao.
evidente, a construo da usabilidade vai deixar o
sistema mais caro. As empresas precisam implementar um
esforo sistemtico para garantir esse desenvolvimento. Jacob
Nielsen, o guru da usabilidade mundial, fala, em seu primeiro
livro sobre o assunto, do retorno extremamente lucrativo de
investimentos no desenvolvimento de boas interfaces com o
usurio (economia de custos, facilidade nas vendas, imagem da
empresa, etc...). Isso pode ser feito a partir de uma perspectiva
de engenharia, ligada a idia da otimizao (maximizar os
resultados e minimizar os recursos necessrios). A Engenharia
de Usabilidade surge como esforo sistemtico das empresas e
4
organizaes para o desenvolvimento da usabilidade dos
sistemas interativo.
Engenharia de Usabilidade
Os sistemas interativos podem ser decompostos segundo
dois subsistemas bsicos:
Ncleo funcional ;
Interface com o usurio
O ncleo funcional formado por programas aplicativos,
algortmos e base de dados, principalmente.
A interface com o usurio formada por apresentaes, de
informaes, de dados, de controles e de comandos. esta
interface tambm que solicita e recepciona as entradas de
dados, de controles e de comandos. Finalmente, ela controla o
dilogo entre as apresentaes e as entradas. Uma interface
tanto define as estratgias para a realizao da tarefa, como
conduz, orienta, recepciona, alerta, ajuda e responde ao usurio
durante as interaes.
At a algum tempo atrs, o desenvolvedor tinha muito mais
chances de sucesso ao construir programas de aplicao, do
que interfaces com o usurio. De fato, ele recebia treinamento
sobre mtodos e tcnicas e possua ferramentas que o
auxiliavam na construo de um cdigo eficaz.
Ele j no possua as mesmas facilidades em relao ao
desenvolvimento de uma interface com o usurio, tarefa que
exige abordagens, mtodos, conhecimentos e treinamento que
os engenheiros de software no recebiam nos bancos da
faculdade. No incio do processo eles desconsideravam o
usurio (que s atrapalhava) e o trabalho que estes
efetivamente realizavam e baseavam-se em informaes
passadas por gerentes e responsveis pelos sistemas. Pela falta
de apoio, deixavam para ltima hora a definio da lgica de
operao e a construo das interfaces com o usurio.
Fundamentalmente, deixavam de envolver o usurio (que s
atrapalhava), na concepo e teste de prottipos.
A partir do final dos anos 80 e sobretudo nos anos 90,
foram desenvolvidos as primeiras abordagens, mtodos, tcnicas
e ferramentas destinadas a apoiar a construo de interfaces
intuitivas, fceis de usar e produtivas. A Engenharia de
Usabilidade, saa dos laboratrios das universidades e institutos
de pesquisa e comeava a ser implementada, como funo nas
empresas desenvolvedoras de software interativo.
Hoje so numerosos os livros, revistas, normas e relatrios
tcnicos que nos apresentam mtodos, tcnicas e ferramentas
para a montagem de uma capacidade em termos de engenharia
de usabilidade nas empresas.
5
Existem publicaes que orientam a como especificar,
construir e testar a usabilidade, como qualidade de uso e
qualidade externa de um sistema de software interativo.
Especialmente as normas ISO da srie 9241. Outras nos
informam de centenas de tcnicas participativas ou documentais,
para o projeto e a avaliao da usabilidade de interfaces. Livros
e normas orientam a montagem de um processo de
desenvolvimento centrado no usurio, como a norma ISO 13407.
No momento atual, trata-se da engenharia de usabilidade como
uma rea de processo (modelo CMMI) no qual as empresas de
software capacitam-se difcil tarefa de produzir interfaces
humano-computador com usabilidade.
Interface com o Usurio
A dificuldade no desenvolvimento de interfaces com
usabilidade se deve ao fato delas constiturem
fundamentalmente, sistemas abertos, probabilsticos, no
determinsticos, sujeitos as influncias do ambiente e as
interpretaes dos usurios. Suas entradas e sadas podem
significar coisas diferentes para pessoas diferentes, em funo
de seu conhecimento, do momento, do ambiente que as cercam.
Se, por um lado, os programas das aplicaes so construdos
por meio de linguagens de programao inequvocas, uma
interface humano-computador, construda por meio de um
conjunto aberto de smbolos ambguos, que devem podem ser
interpretados de diferentes formas pelos usurios, em funo de
seu contexto dinmico. Assim, pode-se afirmar que a experincia
da interao humano-computador individual e nica, no sentido
de que cada pessoa nica em sua bagagem de conhecimento
e experincia. Dificilmente uma mesma interface v significar a
mesma coisa para dois usurios distintos. Menor ainda, a
chance dela ter um significado compartilhado entre usurios o
seus projetistas.
Esta apostila
Esta apostila tem o objetivo de ajudar na mudana de uma
realidade que no Brasil, que coloca o desenvolvimento de
interfaces humano-computador mais prximo da arte do que da
engenharia. Ele vem disponibilizar os conhecimentos e as
ferramentas lgicas que caracterizam a abordagem ergonmica
para Interfaces Humano-Computador desenvolvida pelo LabIUtil
desde sua criao em 1995.
A primeira parte se refere aos fundamentos da abordagem
ergonmica para engenharia de usabilidade de IHC. So assim
apresentadas, nos captulos 1, 2 e 3 suas bases tericas,
advindas das perspectivas sobre o trabalho, a psicologia
cognitiva e da semitica. A segunda parte se refere ao
ferramental da abordagem, apresentando nos captulos 4 e 5
duas ferramentas lgicas para o projeto e avaliao de sistemas
6
interativos: os critrios de qualidade das IHC ergonmicas e um
modelo de componentes de IHC. Os captulos 6, 7 e 8 referem-
se ao ciclo da engenharia de usabilidade, abordado a partir das
perspectivas de anlise, sntese e avaliao.
A abordagem ergonmica para a engenharia da usabilidade
de Interfaces Humano-Computador caracterizada pela
considerao dos conhecimentos disponveis sobre habilidades e
capacidades cognitivas humanas e dos aspectos ligados ao
trabalho como ele , efetivamente realizado. Os dispositivos de
software interativo assim realizados, centrados nos usurios e
sua tarefas, tm chances reais de serem adaptados aos usurios
e adequados a suas tarefas. Seguindo os preceitos da
abordagem ergonmica, estes aplicativos forneceriam conduo
e feedback nas interaes sempre falando a lngua do usurio.
As taxas de erros na realizao da tarefa cairiam em funo
destas qualidades, mas tambm devido a apresentaes e
dilogos consistentes entre si e pela garantia do controle da
interao ao usurio. A carga de trabalho diminuiria por meio de
dilogos e telas compatveis com as necessidades dos usurios
em suas tarefas e por uma maior flexibilidade na interao.
7
Primeira parte :
FUNDAMENTOS TERICOS
DA ENGENHARIA DA USABILIDADE
1. O TRABALHO E SUAS PERSPECTIVAS
A anlise do trabalho inevitvel para uma interveno
ergonmica, seja para a especificao, construo ou avaliao
da usabilidade. Uma interface com o usurio, segundo a
perspectiva ergonmica, deve proporcionar a realizao de
tarefas de modo eficaz, eficiente e agradvel a seu operador. Na
anlise de uma situao de trabalho, o ergonomista ou o
engenheiro de usabilidade, deve considerar os seguintes
aspectos:.
O Contedo do Trabalho: caracterizado por
objetivos, estratgias, informaes, ferramentas, etc que
podem ser analisados segundo as seguintes linhas de
corte:
Linhas de Corte:
Funcionamento e Utilizao : a que separa
lgica de funcionamento e lgica de operao do
sistema;
Tarefa e Atividade : a que distingue o que deve
ser realizado do que efetivamente realizado;
A Dinmica do Trabalho : a que diferencia o
que do que ser...
1.1 Funcionamento e Utilizao
Qualquer sistema ou dispositivo informatizado pode ser
descrito segundo duas lgicas: a de seu funcionamento e a de
sua operao ou utilizao. A lgica de funcionamento descreve
as inter-relaes entre os componentes internos ao sistema, uma
vez que as funes dos sistemas tenham sido acionadas ou
solicitadas pelo usurio. A lgica de operao se refere ao uso
do sistema pelo usurio para realizar suas atividades. Ela
descreve os relacionamentos existentes entre objetivos dos
usurios em suas tarefas e as entradas e sadas do sistema. A
lgica de utilizao a desenvolvida atravs do conhecimento da
interao com o sistema. Essa ltima baseada na chamada
imagem operativa; representao que se tem da realidade do
8
ambiente de trabalho, modificada e simplificada pelo que
funcionalmente significativo. A imagem operativa amplia os
elementos pertinentes e elimina os secundrios.
Enquanto a lgica de funcionamento baseia-se no
conhecimento das funes e de seus mecanismos internos, a de
utilizao baseia-se nas repercusses visveis do sistema. Os
conflitos entre as duas lgicas evidenciam os pontos
problemticos, onde as pessoas desenvolvem mecanismos de
regulao que podem ser custosos, tanto para elas como para a
empresa.
Uma preocupao importante no projeto da interface de um
sistema interativo a mostrar claramente ao usurio os
elementos da lgica de operao definida para o sistema. Por
exemplo, apresentar corretamente na interface, o estado
habilitado e desabilitado de opes de comando ou mostrar a
necessidade do usurio criar pacotes (Zips) para guardar
arquivos antes de compacta-los..
1.2 Tarefa e atividade
Uma outra distino importante a que divide o trabalho
entre tarefa e atividade. Tarefa o trabalho prescrito, e refere-se
quilo que a pessoa deve realizar, segundo sua chefia, seus
colegas ou segundo ela mesmo. A atividade trabalho como
efetivamente realizado e refere-se ao modo como a pessoa
realmente realiza sua tarefa.
O contedo da anlise da tarefa descrito em termos de
metas e objetivos, procedimentos, regras e restries, etc.. A
coleta de informaes feita atravs de entrevistas, anlise da
circulao e tratamento da documentao, anlise da
organizao do trabalho, das ligaes entre os servios, das
caractersticas dos postos de trabalho, etc.. Em suma, busca-se
compreender como o dispositivo funciona e como ele deve ser
operado.
A anlise da atividade visa entender como o sistema
efetivamente operado, e feita atravs das observaes "in loco"
de sesses de trabalho real. As observaes das interaes
estabelecidas entre operadores reais e o sistema podem ser
organizadas de modo a cobrir situaes de normalidade (i), de
aprendizado (ii) e de incidentes (iii). A anlise destas situaes
vai revelar aspectos importantes como
as operaes efetuadas, seu encadeamento, suas
dificuldades, alm dos tipos, freqncias, causas e
condies de aparecimento dos incidentes.
uma viso geral da utilizao da informao, isto ,
conhecer as informaes realmente utilizadas e sua
ordem, as informaes que faltam, as inteis e as que
induzem a erros.
9
as denominaes dadas pelos usurios para as
informaes e operaes por ele realizadas (linguagem
operativa).
As diferenas existentes entre o que previsto e o que se
verifica na prtica, tanto no que se refere ao funcionamento,
como a operao do sistema, est certamente na origem de
erros e incidentes ou de custosas estratgias de acomodao
(jeitinho) desenvolvidas pelos operadores.
1.3 A Dinmica do trabalho
Um dos princpios bsicos da abordagem ergonmica para
o desenvolvimento de sistemas de trabalho, sejam eles
informatizados ou no, o de "conhecer para modificar".
importante salientar que esta mxima se refere tanto aos
usurios como a seu trabalho. Uma nova ferramenta vai implicar
em novas formas de realizar o trabalho e em novas exigncias
sobre o usurio e sobre seu ambiente. As novas exigncias
sobre o usurio se referem em geral a mais formao e mais
experincia na tarefa, na operao do sistema e da informtica
em geral. Elas podem representar tambm a necessidade de
ampliao de suas habilidades motoras (velocidade de digitao,
preciso de movimentos manuais), perceptivas (acuidade visual
e sonora), cognitivas (memorizao e recuperao) e
psicolgicas (sociabilidade e motivao para aprender). Sob o
ponto de vista da tarefa, um novo sistema representa
freqentemente uma nova repartio de trabalho, uma nova
arquitetura de objetivos, novas possibilidades ou limitaes
tcnicas. Sob o ponto de vista do ambiente, a introduo de um
novo sistema representa freqentemente novas instalaes,
nova infra-estrutura, novos equipamentos, novos dispositivos,
etc.
preciso conhecer as exigncias atuais e futuras, de modo
a tornar tranqila a transio entre os contextos de operao do
velho para o novo sistema, e em conseqncia, evitar problemas
de usabilidade.. A introduo de uma nova ferramenta ter um
impacto maior ou menor, dependendo da compatibilidade entre
as novas e as velhas exigncias sobre o usurio e suas formas
de realizar o trabalho.
A anlise e especificao de sistemas inovadores
dificultada pela aparente inexistncia de um quadro de
comparao entre o que e o que ser o contexto de realizao
da tarefa. Freqentemente, este fato citado como justificativa
para a no realizao de uma boa anlise do existente.
Entretanto, e antes de negar a pertinncia da anlise do
trabalho, prope-se que se busque analisar a tarefa com
sistemas relacionados ao sistema pretendido (estado-da-arte),
que na maioria dos casos existem efetivamente. Por traz desta
10
proposta esta a constatao de que em geral a inovao se d
pela evoluo, e no pela revoluo face o existente. Assim
possvel aplicar o princpio de "conhecer para modificar" sobre
uma tarefa futura, apoiada por um sistema ou interface anloga
ao que se pretende desenvolver. De fato, entrevistar, observar e
analisar, usurios de sistemas representando o estado-da-arte
do projeto uma estratgia vlida para conhecer, com uma
aprecivel antecedncia, as vantagens e inconvenientes de
lgicas de operao que poderia ser adotadas no novo sistema.
Esta atividade pode ser vista como o primeiro ciclo de
prototipagem & teste do desenvolvimento de um sistema. Com
efeito, a anlise do estado da arte assume no desenvolvimento
da usabilidade, uma pertinncia bem maior do que a usual em
engenharia de software.
1.4 O contedo do trabalho
Alm de conhecer sobre a natureza das lgicas,
perspectivas e dinmica de um sistema de trabalho,
fundamental conhecer o seu contedo em termos de objetivos,
mtodos, condies, estruturas, etc.. Para sistematizar as
anlises, o engenheiro de usabilidade pode adotar alguma
ferramenta, como o formalismo M.A.D. (Scapin, 1993), que
permitir recolher de forma sistemtica os elementos que
descrevem ou especificam o trabalho em diversas situaes de
anlise, nas quais tanto uma tarefa, como uma atividade, podem
ser descritos por meio dos seguintes elementos :
Objetivo ltimo a alcanar (o que o operador deve
realizar);
Decomposio em sub-tarefas/sub-objetivos;
Relaes entre as sub-tarefas (sequenciais, paralelas,
alternativas, facultativas, etc);
Nomes, denominaes e definies das sub-tarefas;
Objetivos a alcanar nas sub-tarefas;
Mtodos ou a sequncia de aes que o operador
utiliza em cada sub-tarefa para alcanar seus objetivos
(como o operador realiza sua tarefa);
Estados inicial e final do sistema para cada sub-tarefa
(quais informaes so utilizadas e quais as informaes
que so produzidas em cada etapa);
Pr- e ps-condies das sub-tarefas, que se referem
a atributos dos elementos pertencentes aos estados inicial
e final do sistema, que devem ser satisfeitos para
autorizar o incio de determinada ao.
Alm desses elementos, as tarefas individualmente
apresentam atributos:
11
FAC (facultativa) : a tarefa no obrigatoriamente
executada, mas que ela pode ser observada em certas
condies. Ela no indispensvel para a tarefa mas,
assim mesmo, merece ser anotada, sobretudo numa
perspectiva de concepo.
@ (repetitiva) : a tarefa pode-se repetir vrias vezes.
PRIOR (prioritria) : tarefa que pode interromper
outras. Permite atribuir nveis de prioridade entre as
tarefas e saber que tarefas podem interromper a tarefa
em curso.
INTER (interruptvel) : a tarefa ou no interruptvel.
Este atributo permite exprimir que uma tarefa pode ser
interrompida ou no pelos eventos externos. Assim que a
tarefa termina, a tarefa interrompida repetida nas
condies explicitadas pelo valor do atributo.
Por outro lado, as tarefas e as atividades compostas
apresentam componentes inter relacionadas logicamente,
formando uma estrutura hierarquizada. Os construtores das
estruturas de tarefas segundo M.A.D. so os seguintes:
-SEQ (estrutura seqencial): subtarefas so
executadas em seqncia, i.e., uma aps a outra, numa
dada ordem. Enquanto a primeira tarefa no esteja
determinada, fica certo de que a segunda no ser feita.
As subtarefas de uma seqncia no podem interromper
uma s outras.
-PAR (estrutura paralela): exprime que a ordem das
subtarefas no foi imposta priori e que podem existir
tarefas de interrupo. Cada subtarefa tem um nvel de
prioridade. As pr-condies das subtarefas de mais alta
prioridade so testadas. A ordem de execuo de vrias
subtarefas de mesma prioridade determinada ao acaso.
Enquanto uma tarefa interruptvel executada as tarefas
de prioridade superior so ditas de interrupo
-ALT (estrutura alternativa): estrutura que permite
indicar uma tarefa que se pode executar de vrias
maneiras, mas apenas uma das subtarefas efetuada.
Para determinar qual subtarefa se efetua, as pr-
condies detonadoras de cada uma delas sero
testadas.
-SIM (estrutura simultnea): uma estrutura em que
que um ou mais operadores possam executar duas ou
mais tarefas ao mesmo tempo. O funcionamento o
mesmo que o de PAR com a diferena de que vrias
tarefas podem ser executadas ao mesmo tempo. Uma
tarefa SIM termina quando todas as subtarefas no
facultativas foram executadas ao menos uma vez ou
ento quando as ps-condies fim de tarefa esto
verificadas.
12
Um passo importante da anlise do contedo do trabalho
refere-se validao das descries e informaes que foram
coletadas e que compem as representaes sobre o trabalho.
Para tanto esta etapa deve prever a realizao de observaes
in-loco do trabalho do usurio. especialmente recomendado
que seja solicitado aos operadores que verbalizem sobre quais
os objetivos, critrios, diagnsticos e razes das decises
tomadas. Pode-se prever meios de registro em vdeo, audio e um
bloco de anotaes para capturar os aspectos citados em trs
tipos de situaes; situao de normalidade, situaes
consideradas crticas e situaes de erros e incidentes.
Situao de Normalidade: A anlise de atividades
normais feita atravs de observaes contnuas
procurando abranger toda a durao do trabalho.Em
especial deve-se confrontar a descrio da tarefa
realizada na etapa anterior de anlise com o que
realmente realizado pelo usurio em termos de objetivo
ltimo a alcanar, decomposio da atividade em sub-
atividades/sub-objetivos, relaes entre as sub-atividades
(sequenciais, paralelas, alternativas, facultativas, etc).
Deve-se verificar em particular, os graus de dificuldades
na realizao das atividades.
Situaes crticas A partir do que foi levantado na
etapa de anlise da tarefa, algumas situaes podem ser
consideradas problemticas ou crticas e devem ser
observadas com maior ateno. A observao destas
situaes se faz ento por amostragem de perodos
escolhidos.Nelas deve-se confrontar a descrio da tarefa
prescrita com a atividade realizada pelo usurio em
termos de mtodos empregados e do fluxo de informao
nesta parte do sistema.
Situaes de Erros e Incidentes As situaes de erros
e incidentes so de difcil observao, tanto pela
dificuldade de prever sua ocorrncia como pela
dificuldade de seguir seu processo. Recomenda-se ento
que sejam preparadas simulaes, in-loco (no local de
trabalho) ou em laboratrio. Dependendo do sistema, as
do primeiro tipo podem ser dispendiosas para empresa,
operador e analista. Portanto sua realizao deve ser alvo
de uma estudo custo X benefcio cuidadoso. Um outro tipo
de simulao poder ser realizado em um cenrio fora da
situao de trabalho. Uma situao hipottica deve ser
apresentada verbalmente ao usurio que dever
descrever os procedimentos para a recuperao da
situao de normalidade.
Assim, a viso geral da tarefa, complementada por um
levantamento em termos das informaes envolvidas com a sua
realizao efetiva. Desta forma pode-se conhecer quais so;
13
as informaes necessrias e a ordem em que
tornam-se disponveis;
as informaes que so difceis de obter;
as informaes que so inteis (no so utilizadas);
as informaes que so impertinentes (que
atrapalham e induzem a erros de interpretao).
Tambm pode-se obter informao complementar sobre as
tarefas e sub-tarefas;
quais so as mais frequentes
quais so os horrios (durao) e modo de utilizao
quais as deficincias, problemas e incidentes
encontrados. Em particular deve-se identificar suas
causas, condies de aparecimento, frequncia e os
procedimentos para a sua recuperao.
2. A PSICOLOGIA COGNITIVA
Assim como os conhecimentos sobre a fisiologia da mo e
do brao so importantes no projeto de uma ferramenta manual,
tambm os conhecimentos sobre as caractersticas humanas no
tratamento da informao so importantes no projeto de um
software interativo. Considerar o usurio significa conhecer, alm
das informaes provenientes da anlise ergonmica do trabalho
(idade, sexo, formao especfica, conhecimentos, estratgias,
etc...), tambm aquelas ligadas as suas habilidades e
capacidades em termos cognitivos. Na medida em que se
pretende o computador como uma extenso do crebro humano,
fundamental conhecer como se processam os tratamentos
cognitivos na realizao de uma tarefa informatizada.
Nos ltimos anos, vrios estudos tm sido realizados em
psicologia sobre o tratamento da informao. A descrio das
leis gerais sobre o comportamento (behaviorismo)
complementada, no sem controvrsias, pela descrio dos
mecanismos que explicam o seu funcionamento (cognitivismo).
Em suas intervenes para a concepo e avaliao de
interfaces humano-computador, os ergonomistas devem valer-se
dos resultados de ambos os tipos de estudos; os enfocando
comportamentos humanos e os centrados nas estruturas
cognitivas humanas
2.1 Os modelos mentais
O sistema cognitivo humano caracterizado pelo
tratamento de informaes simblicas. Isso significa dizer que as
pessoas elaboram e trabalham sobre a realidade atravs de
modelos mentais ou representaes que montam a partir de uma
realidade. Esses modelos, que condicionam totalmente o
comportamento do indivduo, constituem a sua viso da
14
realidade, que modificada e simplificada pelo que
funcionalmente significativo para ele. O sujeito amplia os
elementos pertinentes e elimina os secundrios estando
apresentao resultante intimamente ligada aos conhecimentos
j adquiridos e a compreenso que o indivduo tem de um
problema. Os modelos mentais relativos a um sistema interativo,
por exemplo, variam de indivduo para indivduo, em funo de
suas experincias passadas, e evoluem no mesmo indivduo, em
funo de sua aprendizagem.
Neste sentido, pode-se distinguir, numa determinada
situao de trabalho informatizada, as seguintes conseqncias
clssicas:
os modelos mentais relativos a uma interface
correspondem a um conjunto de conhecimentos
semnticos (conceitos) e procedurais (procedimentos)
que particular a cada usurio.
os modelos mentais desenvolvidos por projetistas e por
usurios se diferenciam grandemente;
os modelos mentais desenvolvidos por indivduos, que
exercem diferentes funes com o sistema, gesto ou de
operao, por exemplo, se diferenciam grandemente.
Neste caso so evidentes as diferenas nas
representaes mentais de quem opera um sistema
assdua e freqentemente, de quem o faz de maneira
espordica ou intermitente;
os modelos mentais desenvolvidos por usurios novatos
e por experientes se diferenciam grandemente;
A interface humano-computador deste sistema, deve ser
flexvel o suficiente, para adequar-se aos diferentes tipos de
usurios, ao mesmo tempo em que possa adaptar-se evoluo
das caractersticas de um usurio especfico durante seu
processo de aprendizagem com o sistema.
As teorias cognitivas descrevem dois tipos bsicos de
modelos mentais, os que representam procedimentos e os que
representam conceitos. Ambos se organizam em redes
hierrquicas de conhecimentos, semnticos e procedurais sobre,
por exemplo, os significados das funes do sistema interativo e
sobre como se operam estas funes. As lgicas de
funcionamento (conceitos) e de operao (procedimentos) de um
dispositivo esto associadas natureza destes dois tipos de
representaes mentais e contribuem igualmente para o seu
entendimento. Da a necessidade dos textos de ajuda
explorarem estas duas perspectivas de um software interativo;
como funcionam e como se operam suas funes.
Para o projeto de interfaces humano-computador, alm da
variabilidade, nos indivduos e no tempo, importante saber o
que favorece ou limita a elaborao, armazenagem e a
recuperao destas representaes em estruturas de memria e
15
por meio da percepo da realidade. Isto ser tratado nos
tpicos sobre a memria.
2.2 A Percepo
O homem toma conhecimento do mundo atravs do
tratamento da informao sensorial. De fato, o homem, como
todos os seres vivos, coleta no meio ambiente as informaes
necessrias a sua adaptao e a sua sobrevivncia.
A percepo est delimitada pelo conjunto de estruturas e
tratamentos pelos quais o organismo impe um significado as
sensaes produzidas pelos rgos perceptivos.
Gagn (1962) distingue, na atividade de percepo trs
nveis distintos de processos:
processos de deteco ou neuro-fisiolgico: constatar a
existncia de um sinal;
processos de discriminao (de identificao) ou
perceptivo: classificar as informaes em categorias.
Esta funo s possvel se anteriormente houve a
deteco e se j existirem categorias memorizadas;
processos de interpretao (tratamento das
informaes) ou cognitivo: dar um significado s
informaes. Esta funo s possvel se anteriormente
houve a deteco, a discriminao e se j existirem
conhecimentos memorizados.
Inicialmente, pode-se distinguir sensao da percepo
que, nas atuais obras de psicologia, so tratadas como dois
nveis de um mesmo processo cognitivo. Na verdade, sensao
a resposta especfica um estmulo sensorial, enquanto
percepo o conjunto dos mecanismos de codificao e de
coordenao, das diferentes sensaes elementares, visando
lhes dar um significado. O estudo da percepo situa-se num
nvel menos sensorial e mais cognitivo do que o estudo da
sensao. De fato, interessa menos as condies do estmulo
que permitem a percepo, e mais o significado correspondente
um certo estmulo, isto , o conhecimento do objeto, tal como
ele percebido.
A cognio caracteriza-se por um processo ou um caminho
de duas vias : de baixo para cima (botton-up) e de cima para
baixo (Up-down). Com efeito, o percebido no uma fotografia
fiel do ocorrido, pois a informao que resulta do processo de
deteco muitas vezes incompleta, e integrada com uma
informao 'parecida' que desce da memria. Assim, possvel
uma atribuio de significado rapidamente, ainda que de forma
equivocada. De fato, uma informao "parecida" guardada na
memria nem sempre corresponde a realidade. Assim, no
processo da percepo humana, ganha-se em rapidez, mas
perde-se em preciso.
16
Estes processos se verificam, com maior ou menor variao
no conjunto de sistemas autnomos que caracterizam a
percepo, e que so apresentados a seguir.
2.2.1 A percepo visual
O sistema visual humano organizado segundo os nveis
neuro-sensorial, perceptivo e cognitivo.
O nvel neuro-sensorial envolve a transformao dos traos
elementares da estimulao visual em primitivas visuais.
A nvel perceptivo, esta primitivas so estruturadas
seguindo diversos mecanismos conhecidos como Leis da
Gestalt. Estas leis descrevem as condies de aparecimento de
grupamentos e incluem os princpios bsicos de: proximidade,
similaridade, continuidade e conectividade. A percepo de
contornos, a segregao figura-fundo e a ocorrncia de iluses
ptico-geomtricas so fenmenos da estruturao pr-
semntica. Mesmo que possam corresponder aparncia de um
objeto, elas ainda no permitem sua identificao.
Para tanto necessrio montar uma representao
espacial (3D) e recuperar os conhecimentos prvios sobre o
significado do objeto.
2.2.2 A percepo auditiva
O sistema auditivo humano recebe as informaes de
fontes sonoras simultneas de maneira seletiva. As
representaes acusticamente coerentes, denominados objetos
ou "imagens" auditivas, so organizadas em processos
perceptivos (organizadores) paralelos e seqenciais. Os
processos paralelos organizam os eventos sonoros segundo sua
amplitude, freqncia, forma espectral e posio. Os processos
seqenciais lidam com sucesses de eventos acsticos
percebidos na forma de um fluxo. Os componentes de um fluxo
sonoro apresentam continuidade, como em uma melodia, e so
classificados por relaes de freqncia, cadncia, intensidade,
contedo espectrais, etc.
2.2.3 A percepo da fala
A percepo da linguagem falada est organizada na forma
de uma srie de sucessivos processos de codificao.
A nvel neuro-sensorial ocorre a codificao neuronal dos
estmulos fonticos. A informao sobre a estrutura espectral
destes ndices extrada e estocada numa memria sensorial de
curtssimo termo.
Isto permite a anlise dos ndices acsticos pertinentes que
so confrontados com os traos fonticos caractersticos de uma
linguagem especfica. Ocorre ento a filtragem das variaes
17
fonticas que no so caractersticas, de maneira a isolar as
unidades silbicas pertencentes aos idiomas dominados pelos
indivduos.
A nvel lexical se do os tratamentos de acesso ao lxico e
de identificao das palavras. nvel sinttico ocorre a
integrao das informaes lexicais e sintticas com a
interpretao da mensagem recebida, nvel semntico.
2.2.4 Ateno e Vigilncia
Na realidade do trabalho, a deteco responde a um
objetivo, mais ou menos explcito, por parte do sujeito, o qual ir
organizar a coleta das informaes consideradas pertinentes em
relao este objetivo.
A ateno e a vigilncia desempenham um importante
papel de regulao de todas as entradas de informaes, tanto
para as deteces dirigidas pelo sujeito (voluntrias e
conscientes), como para as recepes impostas pelas
estimulaes externas. O meio ambiente analisado e
explorado, de forma seletiva. A explorao dirigida por
esquemas antecipatrios, que determinam a disponibilidade
frente a diferentes tipos de configuraes (ticas, sonoras, etc.) e
a planificao da ao perceptiva. Esses esquemas so
desenvolvidos a partir da histria pessoal e profissional de cada
indivduo. O resultado da explorao perceptiva modifica o
esquema inicial que, por sua vez, modifica a explorao e,
assim, sucessivamente.
A orientao perceptiva se traduz por uma filtragem
considervel dos sinais, sobre os quais a percepo no
focalizada. Ela est ligada ao curso da ao no qual o sujeito
encontra-se engajado, num determinado momento e, em
particular, aos objetivos que ele persegue. Da mesma forma, ela
depende da competncia do sujeito, a qual permite um
conhecimento da probabilidade do aparecimento de certos
sinais, e do significado de uma srie de eventos.
Por exemplo, a representao que um usurio de um
provedor de acesso Internet tem sobre o processo de conexo
por linha telefnica comporta um conhecimento sobre os
objetivos desta fase, uma previso sobre a evoluo esperada
com os rudos produzidos pela linha telefnica e pelo modem, a
antecipao dos sinais e mensagens apresentados na interface e
a preparao para o curso da ao seguinte (efetuar o login, por
exemplo).
Os processos de ateno e vigilncia podem acarretar na
ocorrncia de sinais que, por no serem esperados, no so
percebidos, mesmo que estejam dentro do campo perceptivo.
Por outro lado, pode ocorrer a percepo de sinais esperados,
mesmo que no sejam extamente eles, os dectetados. Para
18
evitar estes fatos, preciso que estes sinais se imponham ao
que est sendo esperado, atravs de caractersticas fsicas
diferenciadas (nvel ou freqncia sonora, luminosidade, cor,
etc.). O projetista de uma interface, consciente deste fato, deve
diferenciar sinais ligados a situaes de anormalidade para que
escapem dos processos antecipatrios da ateno e vigilncia.
2.3 A memria
Os modelos e representaes mentais so armazenados e
recuperados atravs de um conjunto de fenmenos que tm em
comum o fato de restiturem a informao, com maior ou menor
transformao, aps um certo tempo, quando a fonte desta
informao no est mais presente.
A capacidade de memorizao humana pode encadear os
seguintes processos:
Reconhecimento: a capacidade humana de
reencontrar no seu campo perceptivo elementos
anteriormente memorizados (reconhecer o nome de uma
opo de menu aps algum tempo sem v-la).
Reconstruo: a capacidade humana de recolocar
os elementos memorizados na sua organizao anterior
(qual o caminho na estrutura de menus e as aes nas
caixas de dilogo para a configurao de uma tabulao
de pargrafo definida?). Esta capacidade representa um
misto entre reconhecimento, de uma parcela do modelo
metal considerada vlida e a lembrana de novos
elementos para complementar o todo.
Lembrana: a capacidade humana de recuperar, de
forma integral, uma situao anteriormente vivenciada,
sem a presena de nenhum dos elementos dessa
situao (lembrar-se da sintaxe correta de comandos a
serem entrados em uma linha de comando).
Os conhecimentos cientficos atuais no permitem definir,
de forma exata, os custos fisiolgicos associados a estes
processos. Entretanto, no que se refere a uma pessoa que se
vale de um aplicativo de produtividade, como um editor de textos
ou planilha, de forma intermitente, possvel considerar que a
lembrana do nome exato de um comando, para entrada em
uma linha, seja mnemonicamente mais custosa em relao a seu
reconhecimento em um painel de menu.
O armazenamento e a recuperao da informao podem
ser explicados a partir de fenmenos em dois nveis de
atividades: as neuro-fisiolgicos e as cognitivas (tratamento da
informao).
19
2.3.1 Modelos cognitivos para a memria
Os modelos cognitivos descrevem a memria humana a
semelhana da memria de um computador. Este modelo,
distingue trs sistemas de estocagem, que correspondem,
provavelmente a sistemas neuro-fisiolgicos tambm distintos: o
registro sensorial das informaes (RS), a memria de curto
tempo (MCT) e a memria de longo tempo (MLT).
Em sua verso original, a informao que liberada pelo
sistema perceptivo, armazenada em um registro sensorial de
capacidade limitada e altamente voltil. O registro sensorial da
informao conservado apenas por alguns dcimos de
segundos, sem nenhuma possibilidade de prolongamento.
A parte do registro sensorial que pertinente face o curso
das aes dos usurios selecionada para um tratamento mais
elaborado, sendo armazenada em uma estrutura de memria
denominada memria de curto termo -MCT- ou memria de
trabalho MT-.
A capacidade da MCT de 6 a 7 itens e seu esquecimento
ocorre em poucos segundos. Esta declarao define a MCT
como um registro de armazenamento voltil e limitado,
indiferente ao formato da informao e passivo em relao ao
nvel de evocabilidade exigido. J o modelo de memria de
trabalho MT define esta memria intermediria como um
centro de tratamentos, composta de dois sub-sistemas
especializados, um nos tratamentos auditivos e outro nos
tratamentos visuais-espaciais, com capacidade, volatilidade e
acessibilidade diferentes, variando para tipos de indivduos. Para
muitos indivduos a memria de trabalho visual maior e menos
voltil ao contrrio da memria de trabalho sonora, mais voltil e
com menor capacidade. Um executor central capaz de manter
certas informaes em um alto nvel de evocabilidade.
A partir da memria de trabalho, a informao pertinente
armazenada em registros permanentes, os esquemas, que
representam a base de conhecimentos do indivduo. A
permanncia da informao na memria de longo termo MLT
no est sujeita limitaes de ordem temporal, o que no
implica em uma acessibilidade permanente. O esquecimento,
nesta memria descrito como incapacidade de recuperao e
causado pelo aumento em nmero e semelhana dos
conhecimentos declarativos (conceitos), e pela incompatibilidade
entre os contextos de codificao e de recuperao dos
conhecimentos procedurais (procedimentos). Para favorecer
estes processos, os projetistas de IHC devem investir na
organizao, categorizao, diferenciao e discriminao das
informaes apresentadas sobre estas interfaces.
20
Na correlao com os modelos mentais, existem dois tipos
de esquemas de memria (de trabalho e permanente); os
episdicos e os semnticos.
A memria episdica guarda o conhecimento de ordem
procedural, essencialmente dinmico e automatizvel, como
seqncia de dilogo, ou caminhos em uma interface. O efeito
do contexto (intrnseco, interativo, psicolgico) o fator
determinante da recuperao da episdios. Um bom
desempenho depende da compatibilidade entre as situaes no
momento do registro e no momento da recuperao da
informao.
A memria semntica armazena conhecimentos
declarativos organizados, segundo redes de proposies
conceituais. O acesso informao independe do contexto, e
acontece pela ativao de um de seus ns, e pela propagao
desta ativao aos ns vizinhos. Aqui, a organizao,
classificao e diferenciao das informaes apresentadas nas
IHC garantem um bom desempenho humano.
2.4 O Raciocnio e o Aprendizado
O raciocnio definido como uma inferncia ou atividade
mental de produo de novas informaes, a partir das
existentes. Essas atividades possuem duas finalidades no
exclusivas; a de buscar uma coerncia entre as diferentes
informaes, e a de decidir sobre escolhas de aes. A chegada
de novos dados suscitam conceitos e hipteses que estimulam o
tratamento. A produo de conhecimentos pode ser feita partir
de regras gerais, cuja validade definida pela lgica formal ou, a
partir de regras heursticas, que podem produzir resultados nem
sempre eficazes.
A inferncia dedutiva, quando partindo de uma ou
mais premissas verdadeiras, chega-se a uma concluso
seguramente correta. A inferncia dedutiva, como o
tratamento do tipo algortmico dirigido por programas e
corresponde a procedimentos pr-determinados, mais ou
menos automatizados.
A inferncia indutiva quando se parte de premissas
verdadeiras, chegando-se uma concluso mais geral,
no necessariamente verdadeira (generalizao). A
analogia uma forma de raciocnio indutivo que baseia-se
em conhecimentos estocados na memria para
compreenso de uma situao desconhecida. Trata-se de
um tipo de raciocnio que visa a estabelecer uma relao
de similaridade entre dois objetos ou situaes diferentes.
Na repartio homem-mquina, os projetistas de IHC
devem considerar que os humanos tm dificuldades para o
raciocnio algortmico, dedutivo, tendo melhores possibilidades
em analogias e dedues.
21
Segundo uma abordagem cognitivista, a aprendizagem
pode ser entendida como o processo de modificao das
representaes acumuladas nos esquemas declarativos e
procedurais, fruto das inferncias internas ou de atividade
perceptiva. A nvel de conhecimentos, a aprendizagem define a
competncia (saber), e nvel de comportamento, ela define o
desempenho (saber-fazer).
O progresso na aprendizagem no acontece
exclusivamente pela acumulao de conhecimentos (mudanas
quantitativas), mas tambm pela eliminao de hipteses falsas,
de restries inoportunas e pela substituio de procedimentos
(mudanas qualitativas).
De maneira geral, a aprendizagem pode se dar pela ao
ou por um tutorial. A descoberta e a explorao caracterizam a
aprendizagem pela ao. Nestas situaes, os fatores
importantes so o feedback, a identificao dos pontos crticos
da situao, e dos ndices que permitem evocar situaes
anteriores. A aprendizagem por tutorial refere-se s diversas
formas de transmisso do saber de um instrutor. Neste caso,
importante o papel que assumem os conhecimentos anteriores,
como um quadro assimilador do novo conhecimento.
2.5 O Curso das Aes
O curso das aes dos indivduos para a realizao de uma
tarefa encadeia processos ou atividades cognitivas em trs
etapas principais: anlise da situao, planificao e controle das
aes.
2.5.1 A anlise de uma situao
A fase de anlise inicia-se pela percepo orientada, sendo
composta das seguintes etapas:
ativao: um sinal chama a ateno do indivduo,
levando-o orientar seus sentidos na direo da fonte
desta informao, o que provoca um estado de alerta;
observao: a partir do estado de alerta, o indivduo
coleta dados sobre o ambiente, sistema de produo e
meios de trabalho;
categorizao: o indivduo dispe agora de um
conjunto de dados que pode ser decodificado e
coordenado no sentido de elaborar uma representao do
estado do sistema;
interpretao: nesta etapa, o indivduo determina as
causas e as conseqncias do estado do sistema sobre a
evoluo da situao de trabalho.
22
2.5.2 A planificao das aes
Tendo sido montada uma representao da situao, as
prximas etapas de tratamentos cognitivos se referem a
avaliao de quais so as possibilidades de aes, selecionar
uma e planejar a sua realizao:
avaliao das possibilidades: a partir das
caractersticas tcnicas, organizacionais e humanas, o
indivduo avalia as diferentes solues possveis e
escolhe a estratgia tima, aquela que melhor lhe
permite satisfazer um conjunto de critrios
contraditrios, como custo para o sistema de produo e
custo para ele prprio;
definio da tarefa: o indivduo, segundo esta
estratgia, fixa os objetivos e determina os meios
necessrios para ating-los;
definio de procedimentos: consiste na definio de
numa seqncia ordenada de operaes a serem
efetuadas;
A definio ou seleo de uma tarefa a ser realizada
garante a alocao dos recursos cognitivos necessrios para a
sua planificao e para o seu controle. Este processo de seleo
guiado por mecanismos motivacionais (motivao), envolvendo
o produto de trs fatores: a importncia da tarefa do ponto de
vista das motivaes do indivduo, a esperana de sucesso nesta
tarefa e o custo cognitivo para a sua realizao. A importncia
um parmetro que evolui no tempo e depende tambm da
urgncia da tarefa. A esperana de sucesso depende no
somente da freqncia de sucessos anteriores, mas tambm da
crena que tem o indivduo de que o sucesso est sob o seu
controle. A tarefa escolhida a de custo cognitivo mais baixo,
para a qual a fora de inteno a mais forte.
Assim, se pode identificar tarefas e situaes custosas:
quando o nmero de informaes a serem detectadas
e tratadas elevado;
quando a redundncia ou semelhana entre as
informaes a serem memorizadas ou recuperadas for
elevada;
quando o tempo de apresentao das informaes for
reduzido;
quando os prazos para elaborao de respostas
motoras em relao percepo das informaes forem
diminutos, etc..
A planificao das atividades se refere a fixao de
objetivos e elaborao de planos e se baseia em uma
representao hierrquica de espaos abstratos. A estrutura
23
geral do problema representada, mas os detalhes menores so
abstrados. Resolve-se o problema por refinamentos sucessivos,
introduzindo-se os detalhes dos espaos abstratos dos nveis
inferiores. A planificao no passa de uma hiptese de trabalho,
pois ela necessita de avaliaes e de ajustes constantes.
2.5.3 O Controle das aes
A fase de planificao termina com a execuo dos
procedimentos, isto , na realizao da tarefa. Uma vez
executadas, as aes so controladas e avaliadas em termos
dos resultados obtidos.
A partir das entradas e sadas possveis na realizao e
controle das aes Rasmussen (1981) prope uma formalizao
de trs diferentes tipos de comportamentos humanos; os
baseados em habilidades, os baseados em regras; os baseados
em conhecimentos.
Os comportamentos baseados em habilidades (skills) so
essencialmente sensrio-motor, acionados automaticamente por
situaes rotineiras e que se desenvolvem segundo um modelo
interno, no consciente, adquirido anteriormente. As habilidades
so pouco sensveis s condicionantes ambientais e
organizacionais, permitindo reaes muito rpidas e podendo se
desenvolver em paralelo com outras atividades. Um exemplo de
um encadeamento sensrio-motor complexo o digitar. Dentro
de certos limites, as variaes do estado do teclado, ou as
mudanas de velocidade, so tratadas sem interveno da
conscincia para assegurar a continuidade da progresso da
tarefa.
Os comportamentos baseados em regras (rules) so
sequncias de aes controladas por regras memorizadas por
aprendizagem. Ao contrrio das habilidades, estes
comportamentos exigem o disparo de regras e uma coordenao
entre elas, tendo em vista a variabilidade das situaes
encontradas. As atividades conscientes de um usurio
experiente na realizao de tarefas rotineiras com um software
editor de textos pertencem a este tipo de tratamento.
Os comportamentos baseados em conhecimentos
(knowledge) aparecem em situaes novas, de resoluo de
problemas, para os quais no existem regras pr-construdas. De
fato, este tipo de comportamento est mais ligado ao indivduo
do que a prpria tarefa. Uma tarefa pode ser familiar para um
indivduo, mas totalmente nova para outro.
A avaliao dos resultados da ao um componente
fundamental na modificao da representao que se tem do
problema. Ela necessita uma atitude geral de reflexo sobre a
ao, que leva, mais do que ao sucesso, compreender uma
situao, e melhoria do processo de soluo.
24
3. A COMUNICAO E A SEMITICA
" A civilizao humana depende dos sinais e dos sistemas de sinais;
a inteligncia humana inseparvel do funcionamento dos sinais."
Morris, C. -Fundamentals of the theory of signs.
A comunicao interao humano-computador pode ser
vista como um processo de comunicao entre dois sistemas
cognitivos que fazem tratamento de informao simblica. De um
lado, o ser humano, cujas estruturas cognitivas examinadas no
captulo anterior, tratam representaes, portanto simblicas, da
realidade. De outro, o computador, visto como uma mquina
simblica que realiza tratamentos de sinais produzidos pelos
programadores para produzir os sinais que os usurios
interpretam e manipulam em suas interfaces.
Para poder apoiar as decises de projeto da interao
humano-computador, o ergonomista deve conhecer as bases de
funcionamentos destes dois sistemas de tratamentos simblicos
e a forma como eles se comunicam.
Neste tpico so apresentadas as bases da comunicao
humana e das estruturas dos sistemas de sinais, a semitica.
3.1 A Teoria de Comunicao
Os componentes da teoria da comunicao so um
emissor, uma mensagem, um contexto de referncia, um cdigo
e um receptor. Algumas funes se estabelecem a partir das
relaes entre estes componentes. Uma mensagem carrega um
significado, mas tambm a atitude do emissor frente ao objeto.
Assim, uma mensagem muitas vezes ambgua e so as
relaes entre mensagem e seu contexto de referncia que
podem estabelecer uma comunicao lgica e objetiva. Relaes
objetivas e afetivas, so as bases, ao mesmo tempo
complementares e concorrentes da comunicao.
Fig. 3.1 O Modelo de Comunicao de Prieto
25
Um cdigo define convenes entre significantes e
significados. Ele resulta de um acordo entre os usurios de um
sistema de sinais que reconhecem esta relao e a respeitam no
emprego do sinal. Este acordo pode ser mais ou menos explcito,
o que separa dois grandes tipos de relaes: as motivadas
(implcitas) e as arbitrrias (explcitas). Os cdigos motivados se
verificam quando existe uma relao natural entre mensagem e
referncia. o caso das analogias que emprestam aos smbolos
e cones (imagens), de um modo mais ou menos abstrato, a
aparncia dos objetos ou das funcionalidades que eles
representam. Nos formalismos das cincias exatas os cdigos
so geralmente arbitrrios e funcionam por pura conveno
estabelecida que conhecida pelos usurios do sistema de
cdigo. Alm disto sua eficcia garantida por uma
correspondncia unvoca entre mensagem e referncia
(monosemia). Nos chamados cdigos estticos ou poticos
verifica-se em geral uma conveno enfraquecida por uma
polisemia uma expresso ligada diversos contedos. Cabendo
ao receptor escolher um sentido entre os diversos possveis. A
ambigidade do sinal polismico geralmente desaparece quando
se considera o contexto da mensagem.
Uma outra categoria de cdigos, os sensoriais (Ware,
1992), esto ligados s primeiras etapas do processamento
sensorial da informao. Eles tendem a ser estveis frente
indivduos e culturas. Os elementos bsicos da gramtica
sensorial esto baseados em estruturas fisicamente presentes
no mundo. As leis da Gestalt, derivadas dos prprios
mecanismos da percepo de objetos, fornecem exemplos de
sinais cujo significado definido nas primeiras etapas da
cognio. Os fatos dos objetos possurem superfcies, estarem
sujeitos lei da gravidade e da luz se propagar em linha reta
independem de uma cultura especfica. O interesse na
identificao de uma gramtica sensorial envolve a naturalidade
e a facilidade de utilizao de um esquema representacional que
seja vlido em uma grande variedade de contextos.
3.1.1 Indicao e Significao
Os atos simblicos so de dois tipos: notificativos e
significativos. Um ato notificativo simplesmente indica ao
receptor que o emissor se prope a emitir um sinal. Um ato
significativo informa ao receptor que a classe qual pertence a
mensagem que chega uma classe familiar, isto , capaz de ser
tratada. A operao final consiste na seleo de uma entre todas
as mensagens que compem a classe de significados para a sua
interpretao. Para Prieto cada ato comunicativo carrega em si
uma intenso por parte do emissor. Sem intenso no haveria
comunicao. J para Eco, o critrio da intencionalidade
irrelevante.
26
3.2 A semitica
Os sistemas de sinais comearam a ser estudados no
incio do sculo XX, quando Peirce e Saussure lanaram as
bases de duas disciplinas dedicadas aos sinais;
respectivamente, semitica e semiologia. Peirce enfocou a lgica
da funo chamada sinal e Saussure enfocou sua funo social.
Este captulo, dedicado semitica, a cincia que estuda a
lgica dos sistemas de sinais: linguagens, cdigos, sinalizao,
etc.
3.3 Os componentes de um sinal
Fig.3.2 A trade de Pierce
A trade de Peirce mostrada na figura 3.2, uma
representao dos componentes dos sinais e de suas inter-
relaes. Ele envolve um sinal (ou expresso) S, um objeto de
referncia (ou contedo) R, e uma pessoa que o interpreta
(interpretando) I.
Fig. 3.3 - As relaes semiticas
27
Segundo este esquema, um sinal ocorre somente quando
ele for interpretado na mente de uma pessoa. As relaes
envolvendo os trs fatores de um sinal definem as dimenses
pragmtica, semntica e sinttica da semitica (fig. 3.3)
. A relao entre sinais (expresso) define a sintaxe de um
sistema, que descrita por um conjunto de regras do tipo; tal
sinal "determina" ou " determinado" por outro, ou
independente em relao a outro. A semntica associa sinais
(expresses) aos objetos (contedos) que eles representam, e
descrita por um conjunto de regras (arbitrrias ou naturais) do
tipo; um sinal "designa" ou "denota" um objeto. A relao
pragmtica relaciona sinais e objetos com seus interpretandos e
descrita em termos de; um sinal "exprime" ou significa um
objeto para mim. quando uma pessoa conhece as regras que
permitem entender as relaes entre os sinais (sintaxe) e destes
com seus objetos (semntica). Uma palavra pode ter diversos
designaes previstas, mas apenas uma a que se encaixa em
um determinado contexto (ex. Capital cidade sede de um
governo, quantia em dinheiro, algo importante,....)
3.4 A formao de um sinal
Hjelmslev estudou o sinal como uma relao ou uma
funo, que associa um contedo uma expresso na mente da
pessoa que o interpreta (fig. 3.4).
Fig. 3.4 A Semiosis ou formao de um sinal
A expresso a dimenso manifesta de um ato simblico.
Ela pode envolver diversas substncias, por exemplo: gestos,
movimentos, sons, pontos no papel, pixels na tela, etc. O
contedo de um sinal se realiza na mente da pessoa que o
interpreta e corresponde um conhecimento sobre um objeto ou
28
propriedade do mundo. As dimenses contedo e expresso so
interdependentes, o que significa que um sinal no existe sem
uma delas.
Contedo e expresso apresentam forma e substncia. A
substncia representa uma caracterstica do contnuo que
instanciada por uma forma. A forma surge no momento do ato
simblico quando a substncia instanciada passa a ser
diferencivel em relao a uma outra instncia e pertinente em
relao ao contedo ou a expresso. Desta forma, os fatores
decisivos em um sinal so suas formas. O significado de um
sinal denota uma classe formada por todas as mensagens que
um sinal admite. Inversamente, por significante entende-se a
classe formada por todas os sinais que uma mensagem admite.
Mensagem e sinal so instncias de significado e significante
(fig. 2.5). O procedimento de anlise denominado "teste de
comutao" permite a identificao destas duas classes de
variantes.
Por outro lado, as formas de sinais podem ser articuladas.
A primeira articulao se verifica quando existe uma
correspondncia simblica entre os fatores (partes) da forma da
expresso e os fatores (partes) da forma do contedo de um
sinal. Estes fatores so denominados signos. Por exemplo, o
numero 201 indica um apartamento localizado no segundo andar
(2), de frente e direita da fachada (01). A segunda articulao
se verifica em um sinal j articulado cujos signos no so
formados por outros signos. Neste caso estes fatores so
denominados de figuras. As figuras ocorrem quando no existe
uma correspondncia entre os fatores da forma de expresso e
de contedo de um sinal ou de um signo. Os sinais da linguagem
escrita ou falada apresentam dupla articulao, na medida em
que grafemas ou fonemas, os componentes elementares das
palavras, constituem figuras.
3.5 A semitica computacional
A semitica computacional proposta por Andersen (1991)
a utilizao de sinais computacionais na sociedade atual. Suas
propostas so baseadas em duas das interpretaes do
esquema semitico apresentadas no tpico anterior: o esquema
estruturalista elaborado por Hjelmslev e a trade de Peirce. No
centro de sua perspectiva est o indivduo, considerado como o
criador, o intrprete e a referncia dos sinais. Ele usa a produo
semitica de outros para (re)produzir conhecimento comum. Um
sinal uma relao entre formas de expresso e de contedo
que s ocorre quando ele interpretado. Assim, o sistema
informatizado visto como um sistema de expresses "vazias",
pois dependem do usurio para se realizarem como sinais. Os
projetistas podem influenciar fortemente estas interpretaes ao
conceberem seus candidatos sinais computacionais. Assim,
sua atividade possui o carter de criao de proposio de
29
significados. No se pode dizer que um projetista conceba sinais,
ele prope sinais, que em algumas circunstncias se realizam,
mas que em muitas outras nunca atingem a realizao prevista.
Programar, no sentido semitico do termo , segundo Andersen
(Andersen, 1993) usar o computador para tentar dizer algo s
pessoas. Deste modo, os sinais computacionais so definidos
como sinais candidatos. Eles dependem do usurio para se
realizarem como sinais. Entretanto o projetista, e este o seu
papel, deve poder influenciar sua interpretao.
Desta forma, o computador visto essencialmente, como
um meio para a comunicao. Em um sistema informatizado o
projetista quem define os limites da comunicao criando os
sinais que o usurio pode manipular. Para Andersen, o
computador no possui as faculdades de um emissor ou de um
receptor, ao contrrio de pessoas, que articulam uma linguagem
mesmo sem conhecer seu "programa" ou gramtica. As pessoas,
ao contrrio de um computador, possuem a capacidade de
modificar uma linguagem naturalmente, pois as linguagens
humanas no foram construdas por um grupo de projetistas,
mas evoluram naturalmente com o uso.
3.5.1 Sinais Computacionais
A interface humano-computador vista como uma coleo
de sinais computacionais, isto , toda a parte do processo do
sistema que detectada, utilizada e interpretada por uma
comunidade de usurios. Ela deixa de ser vista como
componente e passa a ser entendida como processo de um
sistema. Segundo esta definio pode-se afirmar que um sistema
informatizado possui inmeras interfaces, uma vez que cada
usurio entra em contato com uma coleo diferente de sinais os
quais ele interpreta de uma maneira particular. A relao que se
estabelece entre o usurio e as partes perceptveis do sistema
faz com que uma nova interface emerga do sistema
informatizado cada vez ele utilizado.
Os sinais computacionais so definidos como um tipo
especial de sinais cujo plano de expresso se manifesta no
processo de mudana da substncia dos dispositivos de entrada
e de sada do sistema informatizado. Seu contedo est no
sistema de referncia. Os sinais computacionais formam
estruturas de propriedades manipulveis, permanentes e
transitrias que podem realizar aes sobre os outros sinais do
sistema. As propriedades manipulveis so produzidas pelo
usurio com o objetivo de articular suas aes e incluem o
pressionar de uma tecla, os movimentos do "mouse", etc. As
propriedades permanentes, geradas pelo computador, so
aquelas que permanecem constantes durante o ciclo de vida
ativa do sinal e que servem para diferenci-lo de outros sinais.
As transitrias, tambm geradas pelo computador, so as que se
30
modificam durante a vida do sinal. Elas simbolizam os diferentes
estados que sua referncia pode assumir.
Em um sistema interativo os sinais podem aparecer juntos
ou se seguirem no tempo. O primeiro tipo de situao define uma
cadeia concorrente que representa o ambiente esttico de
trabalho. Este formado pelo elenco de objetos de trabalho,
mquinas, ferramentas, controles, etc. A cadeia seqencial,
definida pelo segundo tipo de relao, representa o aspecto
dinmico do sistema. Elas representam as possibilidades e os
padres em termos de aes.
O principal sinal composto concorrente refere-se a "cena".
As cenas correspondem a noo teatral do termo, que define um
local com os objetos e os atores necessrios para a realizao
de aes. Leia-se o conjunto de objetos e ferramentas
necessrios para a execuo de um grupo de tarefas
concorrentes. Andersen sugere que a descrio de um sistema
interativo baseada em cenas deve ser feita em dois nveis. O
primeiro descreve cenas genricas, como por exemplo aquelas
ligadas ao gerenciamento do sistema de janelas, da manipulao
de arquivos, dos dispositivos de entrada e sada, etc. Num
segundo nvel ocorre a descrio das cenas associadas s
tarefas especficas de um aplicativo. Assim a concepo de um
sistema interativo pode se realizar como um processo de
insero de novas cenas em um livro j escrito e comercializado,
como aquelas definidas nos sistemas MS-Windows, X-Windows,
MacApp, etc.
Os sinais compostos seqenciais so as "aes e tarefas
simblicas que resultam da manipulao de sinais.
31
SEGUNDA PARTE:
FERRAMENTAS PARA A ENGENHARIA DE
USABILIDADE
4. QUALIDADES ERGONMICAS PARA IHC
O sucesso de qualquer atividade de concepo ou de
avaliao depende do emprego de critrios bem definidos. A
abordagem ergonmica proposta neste livro est baseada em
um conjunto de critrios definidos por Scapin e Bastien,
pesquisadores do INRIA (Institut National de Recherche en
Informatique et en Automatique da Frana) em sua verso de
1993. Trata-se de um conjunto de 8 critrios principais que se
subdividem de modo a minimizar a ambigidade na identificao
e classificao das qualidades e problemas ergonmicos do
software interativo.
4.1 A Conduo
O software ergonmico aconselha, orienta, informa, e
conduz o usurio na interao com o computador (mensagens,
alarmes, rtulos, etc.), possibilitando:
- a localizao do usurio, ou seja, que saiba, a
qualquer hora, onde se encontra, numa seqncia de
interaes ou na execuo de uma tarefa;
-conhecimento das aes permitidas, bem como suas
conseqncias;
-obteno de informaes suplementares
(eventualmente por demanda).

O software prestativo proporciona aprendizado rpido e
fcil utilizao permitindo que o usurio melhore seu
desempenho e diminua o nmero de erros na operao do
sistema. Esta qualidade pode ser analisada a partir de duas
dimenses: a presteza e o feedback imediato.
4.1.1 Presteza
A presteza diz respeito as informaes que permitem ao
usurio identificar o estado ou contexto no qual se encontra,
bem como as ferramentas de ajuda e o modo de acesso,
incluindo todos os mecanismos ou meios que permitam ao
usurio conhecer as alternativas, em termos de aes, conforme
o estado ou contexto no qual ele se encontra. Esta qualidade
elementar engloba os meios utilizados para levar o usurio a
realizar determinadas aes.
32
O software prestativo guia o usurio e poupa, do
aprendizado de uma srie de comandos, permitindo ao usurio
saber o modo ou o estado e onde se encontra no dilogo, bem
como o que fez para se encontrar nessa situao. Uma boa
presteza facilita a navegao no aplicativo e diminui a ocorrncia
de erros.
4.1.2 Feedback Imediato
Feedback imediato diz respeito s respostas do sistema s
aes do usurio. Estas entradas podem ir do simples pressionar
de uma tecla, at uma lista de comandos. As respostas do
computador devem ser fornecidas, de forma rpida, com um
tempo de resposta apropriado e consistente para cada tipo de
transao. Uma resposta rpida deve ser fornecida com
informao sobre a transao solicitada e seu resultado.
A qualidade e rapidez do feedback so dois fatores
importantes para o estabelecimento de satisfao e confiana do
usurio, assim como para o entendimento do dilogo. Estes
fatores possibilitam que o usurio tenha um melhor entendimento
do funcionamento do sistema.
A ausncia de feedback ou sua demora podem ser
desconcertantes para o usurio. Os usurios podem suspeitar de
uma falha no sistema, e podem tomar atitudes prejudiciais para
os processos em andamento.
4.1.3 Legibilidade
A performance melhora quando a apresentao da
informao leva em conta as caractersticas cognitivas e
perceptivas dos usurios. Uma boa legibilidade facilita a leitura
da informao apresentada. Por exemplo, letras escuras em um
fundo claro so mais fceis de ler que letras claras em um fundo
escuro; texto apresentado com letras maisculas e minsculas
lido mais rapidamente do que texto escrito somente com
maisculas.
Legibilidade diz respeito s caractersticas lexicais das
informaes apresentadas na tela que possam dificultar ou
facilitar a leitura desta informao (brilho do caracter, contraste
letra/fundo, tamanho da fonte, espaamento entre palavras,
espaamento entre linhas, espaamento de pargrafos,
comprimento da linha, etc.).
4.1.4 Agrupamento/Distino de Itens
A compreenso de uma tela pelo usurio depende, entre
outras coisas, da ordenao, do posicionamento, e da distino
dos objetos (imagens, textos, comandos, etc.) que so
apresentados. Os usurios vo detectar os diferentes itens ou
grupos de itens, e aprender suas relaes mais facilmente, se,
33
por um lado, eles forem apresentados de uma maneira
organizada (e.g., ordem alfabtica, freqncia de uso, etc.), e por
outro lado, os itens ou grupos de itens forem apresentados em
formatos, ou codificados de maneira a indicar suas similaridades
ou diferenas. Alm disso, a aprendizagem e a recuperao de
itens ou de grupos de itens ser melhorada.
Esta qualidade diz respeito organizao visual dos itens
de informao, relacionados uns com os outros, levando em
conta a topologia (localizao) e algumas caractersticas grficas
(formato) para indicar as relaes entre os vrios itens
mostrados, apontando se pertencem ou no, a uma dada classe,
ou indicando diferenas entre classes. Esta qualidade tambm
diz respeito organizao dos itens de uma classe. O critrio
agrupamento/distino de itens est subdividido em dois critrios
elementares: agrupamento/distino por localizao e
agrupamento/distino por formato.
4.1.4.1 Agrupamento/Distino por Localizao
A qualidade de agrupamento/distino por localizao diz
respeito ao posicionamento relativo dos itens, estabelecido para
indicar se eles pertencem ou no a uma dada classe, ou, ainda,
para indicar diferenas entre classes, e o posicionamento relativo
dos itens dentro de uma classe.
4.1.4.2 Agrupamento/Distino por Formato
Ser mais fcil para o usurio perceber relacionamento(s)
entre itens ou classes de itens, se diferentes formatos ou
diferentes cdigos ilustrarem suas similaridades ou diferenas.
Tais relacionamentos sero mais fceis de aprender e de
lembrar.
A qualidade de agrupamento/distino por formato diz
respeito mais especificamente s caractersticas grficas
(formato, cor, etc.) que indicam se itens pertencem ou no a uma
dada classe, ou que indicam distines entre classes diferentes,
ou ainda distines entre itens de uma dada classe.
4.2 A Carga de Trabalho
Quanto maior for a carga de trabalho cognitivo para o
usurio, maior ser a probabilidade de cometer erros, alm
disso, quanto menos o usurio for distrado por informao
desnecessria, mais ser capaz de desempenhar suas tarefas
eficientemente, pois quanto menos aes so necessrias, mais
rpidas as interaes.
O critrio Carga de Trabalho, que define o software
econmico, diz respeito a todos elementos da interface que tm
um papel importante na reduo da carga cognitiva e perceptiva
do usurio, e no aumento da eficincia do dilogo.
34
O critrio Carga de Trabalho est subdividido em dois
critrios: Brevidade (que inclui Conciso e Aes Mnimas) e
Densidade Informacional.
4.2.1 Brevidade
A capacidade da memria de curto termo limitada.
Conseqentemente, quanto menos entradas, menor a
probabilidade de cometer erros. Alm disso, quanto mais
sucintos forem os itens, menor ser o tempo de leitura, e quanto
mais numerosas e complexas forem as aes necessrias para
se chegar a uma meta, maior ser a carga de trabalho e a
probabilidade de ocorrncia de erros.
O software Breve respeita a capacidade de trabalho
perceptivo e cognitivo do usurio, tanto para entradas e sadas
individuais, quanto para conjuntos de entradas (i.e., conjuntos de
aes necessrias para se alcanar uma meta). Brevidade
corresponde ao objetivo de limitar a carga de trabalho de leitura
e entradas, e o nmero de passos. O critrio Brevidade se divide
em duas qualidades elementares: Conciso e Aes Mnimas.
4.2.1.1 Conciso
O critrio conciso diz respeito carga perceptiva e
cognitiva de sadas e entradas individuais.
4.2.1.2 Aes Mnimas
Quanto mais numerosas e complexas forem as aes
necessrias para se chegar a uma meta, maior ser a carga de
trabalho e a probabilidade de ocorrncia de erros.
A qualidade Aes Mnimas diz respeito carga de trabalho
em relao ao nmero de aes necessrias realizao de
uma tarefa. Trata-se de limitar, tanto quanto possvel, o nmero
de passos pelos quais o usurio deve passar.
4.2.2 Densidade Informacional
A carga de memorizao do usurio deve ser minimizada.
Usurios no devem ter que memorizar listas de dados ou
procedimentos complicados. Eles no devem, tambm, precisar
executar tarefas cognitivas complexas quando estas no esto
relacionadas com a tarefa em questo.
Na maioria das tarefas, a performance dos usurios
diminuda quando a densidade da informao muito alta ou
muito baixa, nestes casos, a ocorrncia de erros mais provvel.
Itens que no esto relacionados tarefa devem ser removidos.
A qualidade Densidade Informacional diz respeito carga
de trabalho do usurio, de um ponto de vista perceptivo e
cognitivo, com relao ao conjunto total de itens de informao
35
apresentados aos usurios, e no a cada elemento ou item
individual.
4.3 O Controle Explcito
Com um software obediente o usurio tem o controle
explcito sobre os processamentos do sistema. Quando os
usurios definem explicitamente suas entradas, e quando estas
entradas esto sob controle, os erros e as ambigidades so
limitados. Alm disso, o sistema ser melhor aceito pelos
usurios se eles tiverem controle sobre o dilogo.
O software obediente se define em dois critrios
elementares: Aes Explcitas do Usurio e Controle do Usurio.
4.3.1 Aes Explcitas do Usurio
O critrio Aes Explcitas do Usurio se refere s relaes
entre o processamento pelo computador e as aes do usurio.
Esta relao deve ser explcita, i.e., o computador deve
processar somente aquelas aes solicitadas pelo usurio e
somente quando solicitado a faz-lo.
Quando o processamento pelo computador resulta de
aes explcitas dos usurios, estes aprendem e entendem
melhor o funcionamento da aplicao, e menos erros so
observados.
4.3.2 Controle do Usurio
O critrio Controle do Usurio se refere ao fato de que os
usurios deveriam estar sempre no controle do processamento
do sistema (e.g., interromper, cancelar, suspender e continuar).
Cada ao possvel do usurio deve ser antecipada e opes
apropriadas devem ser oferecidas.
O controle sobre as interaes favorece a aprendizagem e
assim diminui a probabilidade de erros. Como conseqncia, o
computador se torna mais previsvel.
4.4 A Adaptabilidade
A adaptabilidade de um sistema diz respeito a sua
capacidade de reagir conforme o contexto, e conforme as
necessidades e preferncias do usurio. Dois sub-critrios
participam da adaptabilidade: a flexibilidade e a considerao da
experincia do usurio.
Uma interface no pode atender ao mesmo tempo a todos
os seus usurios em potencial. Para que no tenha efeitos
negativos sobre o usurio, a interface deve, conforme o contexto,
se adaptar a ele. Por outro lado, quanto mais variadas so as
maneiras de realizar uma tarefa, maiores so as chances do
usurio de escolher e dominar uma delas no curso de seu
36
aprendizado. Deve-se portando fornecer ao usurio
procedimentos, opes, comandos diferentes permitindo
alcanar um mesmo objetivo.
4.4.1 Flexibilidade
A flexibilidade se refere aos meios colocados disposio
do usurio que permite personalizar a interface a fim de levar em
conta as exigncias da tarefa, de suas estratgias ou seus
hbitos de trabalho. Corresponde tambm ao nmero de
diferentes maneiras disposio do usurio para alcanar um
certo objetivo, e portanto, da capacidade da interface se adaptar
as variadas aes do usurio.
Quanto mais formas de efetuar uma tarefa existirem,
maiores sero as chances de que o usurio possa escolher e
dominar uma delas no curso de sua aprendizagem.
4.4.2 Considerao da experincia do usurio
A considerao da experincia do usurio diz respeito aos
meios implementados que permitem que o sistema respeite o
nvel de experincia do usurio.
O grau de experincia dos usurios pode variar, pois
podem se tornar especialistas, devido a utilizao continuada,
bem como menos especialistas, depois de longos perodos de
no utilizao. A interface deve tambm ser concebida para lidar
com as variaes dos nveis de experincia. Usurios
experientes no tm as mesmas necessidades informativas que
novatos. Todos os comandos ou opes no precisam ser
visveis o tempo todo. Os dilogos de iniciativa somente do
computador, entediam e diminuem o rendimento do usurio
experiente. Os atalhos, ao contrrio, podem permitir rpido
acesso as funes do sistema. Pode-se fornecer aos usurios
inexperientes dilogos bem conduzidos, ou mesmo passo
passo. Portanto, meios diferenciados devem ser previstos para
lidar com diferenas de experincia, permitindo que o usurio
delegue ou se aproprie da iniciativa do dilogo.
4.5 A Gesto de Erros
A gesto de erros diz respeito a todos os mecanismos que
permitem evitar ou reduzir a ocorrncia de erros, e quando eles
ocorrem, que favoream sua correo. Os erros so aqui
considerados como entrada de dados incorretas, entradas com
formatos inadequados, entradas de comandos com sintaxes
incorretas, etc. Trs sub-critrios participam da manuteno dos
erros: a proteo contra os erros, a qualidade das mensagens de
erro e a correo dos erros.
As interrupes provocadas pelos erros tm conseqncias
negativas sobre a atividade do usurio. Geralmente, elas
37
prolongam as transaes e perturbam o planejamento. Quanto
menor a possibilidade de erros, menos interrupes ocorrem e
melhor o desempenho.
4.5.1 Proteo contra os erros
A proteo contra os erros diz respeito aos mecanismos
empregados para detectar e prevenir os erros de entradas de
dados ou comandos, ou possveis aes de conseqncias
desastrosas e/ou no recuperveis.
prefervel detectar os erros no momento da digitao do
que no momento da validao. Isto pode evitar perturbaes no
planejamento da tarefa.
4.5.2 Qualidade das mensagens de erro
A qualidade das mensagens refere-se a pertinncia, a
legibilidade e a exatido da informao dada ao usurio sobre a
natureza do erro cometido (sintaxe, formato, etc.), e sobre as
aes a executar para corrigi-lo.
A qualidade das mensagens favorece o aprendizado do
sistema indicando ao usurio a razo ou a natureza do erro
cometido, o que ele fez de errado, o que ele deveria ter feito e o
que ele deve fazer.
4.5.3 Correo dos erros
O critrio correo dos erros diz respeito aos meios
colocados a disposio do usurio com o objetivo de permitir a
correo de seus erros.
Os erros so bem menos perturbadores quando eles so
fceis de corrigir.
4.6 A Homogeneidade/Coerncia
O critrio homogeneidade/coerncia refere-se forma na
qual as escolhas na concepo da interface (cdigos,
denominaes, formatos, procedimentos, etc.) so conservadas
idnticas em contextos idnticos, e diferentes para contextos
diferentes.
Os procedimentos, rtulos, comandos, etc., so melhor
reconhecidos, localizados e utilizados, quando seu formato,
localizao, ou sintaxe so estveis de uma tela para outra, de
uma seo para outra. Nestas condies o sistema mais
previsvel e a aprendizagem mais generalizvel; os erros so
diminudos. necessrio escolher opes similares de cdigos,
procedimentos, denominaes para contextos idnticos, e utilizar
os mesmos meios para obter os mesmos resultados.
conveniente padronizar tanto quanto possvel todos os objetos
quanto ao seu formato e sua denominao, e padronizar a
38
sintaxe dos procedimentos. A falta de homogeneidade nos
menus por exemplo, pode aumentar consideravelmente os
tempos de procura.
A falta de homogeneidade tambm uma razo importante
da recusa na utilizao.
4.7 O Significado dos Cdigos e Denominaes
O critrio significado dos cdigos e denominaes diz
respeito a adequao entre o objeto ou a informao
apresentada ou pedida, e sua referncia. Cdigos e
denominaes significativas possuem uma forte relao
semntica com seu referente. Termos pouco expressivos para o
usurio podem ocasionar problemas de conduo onde ele pode
ser levado a selecionar uma opo errada.
Quando a codificao significativa, a recordao e o
reconhecimento so melhores. Cdigos e denominaes no
significativos para os usurios podem lhes sugerir operaes
inadequadas para o contexto, lhes conduzindo a cometer erros.
4.8 A Compatibilidade
O critrio compatibilidade refere-se ao acordo que possa
existir entre as caractersticas do usurio (memria, percepo,
hbitos, competncias, idade, expectativas, etc.) e das tarefas,
de uma parte, e a organizao das sadas, das entradas e do
dilogo de uma dada aplicao, de outra. Diz respeito tambm,
ao grau de similaridade entre diferentes ambientes e aplicaes.
A transferncia de informaes de um contexto outro
mais tanto mais rpida e eficaz quanto menor o volume de
informao que deve ser recodificada.
A eficincia aumentada quando: os procedimentos
necessrios ao cumprimento da tarefa so compatveis com as
caractersticas psicolgicas do usurio; os procedimentos e as
tarefas so organizadas de maneira a respeitar as expectativas
ou costumes do usurio; quando as tradues, as transposies,
as interpretaes, ou referncias a documentao so
minimizadas.
Os desempenhos so melhores quando a informao
apresentada de uma forma diretamente utilizvel (telas
compatveis com o suporte tipogrfico, denominaes de
comandos compatveis com o vocabulrio do usurio, etc.).
39
5. MODELO DE COMPONENTES DE IHC
5.1 Introduo ao Modelo Lingstico
A interface humano-computador entendida como um
subsistema do software interativo que como tal, possui estrutura
e processos. A estrutura representada por seus componentes,
e os processos se estabelecem na interao entre estes
componentes e os usurios do sistema. Assim um nico sistema
de interface humano-computador permite inmeras interaes
humano-computador, cada uma associada aos diferentes
percursos (processos) realizados pelos diferentes usurios.
Sob outro ponto de vista, a interface humano-computador
vista como uma linguagem (sistema de sinais) cuja estrutura
lexical e sinttica conhecida pelo usurio e pelo sistema
informatizado. Durante o dilogo, esses agentes articulam os
elementos do lxico atravs de regras de sintaxe para montar e
interpretar as mensagens trocadas.
A analogia entre interfaces com o usurio e um sistema de
linguagem detalhada no modelo de camadas de abstrao
proposto por Nielsen (Nielsen, 1984 - citado em Bodart &
Vaderdonck, 1993 )
Nvel de Objetivos: refere-se aos objetivos dos usurios
independentemente do sistema informatizado;
Nvel Pragmtico: refere-se as funes e estruturas de
dados, associados aos conceitos do mundo real, como
implementados no sistema;
Nvel Semntico: refere-se aos significados que o
usurio desenvolve sobre a operao das funes e
estruturas de dados do sistema em associao com o
mundo real;
Nvel Sintxico: refere-se tanto aos dilogos como as
telas, janelas e caixas de dilogo individuais. Trata das
relaes entre os objetos de interao apresentados
numa seqncia de telas, e de modo concorrente, em
uma nica tela;
Nvel Lexical: refere-se aos nomes dos comandos e
desenhos de cones. Trata dos significados das
unidades veiculando os itens de informaes;
Nvel de Primitivas: refere-se as fontes, linhas, texturas,
cores e sons, que representam o conjunto de unidades
construtivas dos itens de informao;
Nvel Fsico: trata dos dispositivos de entrada e sada do
sistema.
40
Esse modelo lingstico proporciona a diretriz mais utilizada
para a organizao dos elementos das interfaces humano-
computador e do raciocnio ergonmico para sua seleo,
configurao e avaliao.
5.2 Os Componentes da Interao Humano-
Computador
Os Critrios Ergonmicos de Scapin e Bastien (1993)
apresentados no captulo anterior referem-se as qualidades de
diferentes tipos de componentes de interfaces humano-
computador como mensagens de erro, cdigos, denominaes,
aes do usurio, itens, localizaes, formatos, etc. O modelo
de componentes das interfaces humano-computador que
apresentado nesse livro, representa uma maneira de organizar a
estrutura dessas interfaces e os conhecimentos para selecionar,
configurar e avaliar/inspecionar os elementos apresentados na
tabela 5.1. Eles foram definidos a partir do exame de
recomendaes ergonmicas1 e se referem aos nveis Sinttico,
Lexical e de Primitivas do modelo lingstico de Nielsen.
O modelo prope classes de elementos organizados a partir
de dilogos (sintaxe seqencial), objetos de interao (sintaxe
concorrente), sistemas de significados (lxico) e primitivas.
Os dilogos, vistos como seqncias de interaes entre o
homem e o sistema podem ser analisados segundo perspectivas
de funo, forma e estrutura. As funes dos dilogos definem
as classes de tarefas, e representam o nvel pragmtico das
interaes homem-sistema. Elas esto associadas s maneiras
de apoiar os objetivos prticos dos usurios nas interaes com
o sistema. Assim por exemplo, para um editor de texto existem
funcionalidades que apiam tarefas especficas do tipo
procurar/substituir cadeias de caracteres ou para realizar a
reviso ortogrfica e gramatical do texto. As aplicaes com
planilhas proporcionam facilidades de definir relaes
matemticas entre as clulas. O modelo de caractersticas de
interfaces humano-computador prope alguns tipos de tarefas
genricas definidas nas relaes com diversos tipos de
programas aplicativos. A componente elementar de classes de
tarefa uma ao.
Os estilos de dilogo representam a sintaxe seqencial do
modelo, que prope as classes de; preenchimento de
formulrios, dilogo por menu, dilogos de manipulao direta e
dilogos de questo x resposta.

1
A Base de Recomendaes Ergonmicas LabIUtil, foi implementada em
Microsoft Access verso 2.00 e formada por cerca de 200 recomendaes
selecionadas de diversas fontes (Smith & Mosier, 1986; Bodart &
Vanderdonckt, 1993; Brown, 1988; ISO 9241-10,14 e 17, 1995). Cada
recomendao apresenta uma estrutura de informao com enunciados,
justificativas, excees, exemplos positivos e negativos, glossrio e
referncias bibliogrficas.
41
As estruturas dos dilogos determinam as dinmicas
possveis de um dilogo. Entre os exemplares possveis dessas
classes constam as estruturas do dilogo, estrutura do menu,
estrutura da linguagem de comando, estrutura das teclas de
funes.
As classes de objetos de interao representam as relaes
estticas que se estabelecem nas telas, janelas, caixas de
dilogo, etc. Elas foram agrupadas segundo uma perspectiva
funcional-estrutural, definindo as classes de painis de controles,
controles complexos, grupos de controles, controles simples,
campos de entrada, dados complexos, dados simples e as
informaes.
42
TABELA 2 - Modelo de Componentes de Interfaces Humano-computador
Organizao das Componentes Classes de Componentes
Aes Aes de Entrada Entrada de dados e comandos
Interaes Tarefas Tarefa de Diagnstico,
Tarefa Corretiva
Tarefa Destrutiva
Estilos Dilogo por Menu
Dilogo por Preenchimento de Formulrio
Dilogo por Linguagem de Comando
Dilogo por Manipulao Direta
Estruturas Estrutura Seqencial (Passo passo)
Estrutura Paralela
Estrutura Repetitiva
Objetos de
Interao
Painis de Controles Tela, Janela, Caixa de Dilogo, Caixa de
Ao/Tarefa, Tela de Consulta,
Formulrio,
Caixa de Mensagem
Controles
Compostos
Barra de Menu, Painel de Menu,
Pgina de Menu,
Barra de Ferramentas,
Lista de Seleo, Lista de Combinao
Grupos de
Controles
Grupo de Botes de Comando,
Grupo de Botes de Rdio,
Grupo de Caixas de Atribuio
Grupo de campos/mostradores de dados
Controles Simples Boto de Comando, Caixa de Atribuio,
Cursor do Dispositivo de Apontamento,
Escala, Dial
Campos de Entrada Campo de Texto, Campo de Dado, Campo
Grfico, Linha de Comando
Mostradores
Estruturados
Lista de Dados, Tabela de Dados, Texto,
Grfico, Diagrama de figura, Diagrama de
Texto, Mapa
Mostrador simples Mostrador de Dados
Mostrador de
Informaes
Rtulo, Mensagem de Orientao, de
Ajuda, de Alerta, Aviso, Mensagem de
Erro, Indicador de Progresso, Efeito
Sonoro, Motivo Meldico, Locuo, Fala
Sistemas de Motivados Denominao, Abreviatura, cone
Significado Arbitrrios Cdigo Alfanumrico, Cdigo de Cores,
Cdigo de Textura, Cdigo de
Intermitncia, Cdigo de Vdeo-Reverso
Primitivas Visuais Cor, Fonte, Linha, Arranjo
Sonoras Som
O lxico da interface definido pelos sistemas de
significados, sendo ainda possvel definir as primitivas grficas
empregadas na construo das apresentaes dos objetos. O
43
modelo de caractersticas das interfaces humano-computador
poderia ainda abrigar as classes de mdias se estivesse
relacionado com recomendaes ergonmicas sobre os
aspectos fsicos dos dispositivos de entrada e sada.
importante salientar que o modelo proposto no tem a
finalidade de descrever em sua totalidade as caractersticas das
interfaces homem - computador. Ele visa especificamente apoiar
a aplicao do conhecimento ergonmico sobre essas interfaces
nas atividades de projeto e avaliao. Sua abrangncia
limitada ao alcance da base de recomendaes ergonmicas
que est em sua origem, sendo inevitvel que hajam ausncias
de classes. Sobre elas no existem conhecimentos ergonmicos
explicitados na base de conhecimento.
5.2.1 Os dilogos
5.2.1.1 Aes
A ao corresponde uma interao elementar. Ela
compreende a menor entrada significativa do usurio
acompanhada de uma resposta tambm significativa do sistema.
5.2.1.1.1 Ao de entrada de dados ou comandos
Em uma ao o sistema deve sempre aguardar pelo
trmino da entrada e fornecer feedback imediato e significativo
para ela. Se necessrio, o sistema deve considerar como
equivalentes as letras maisculas e minsculas, alm de
preencher automaticamente zeros decimais e vrgulas. O sistema
deve tambm avisar o usurio sobre os erros nas entradas
atravs de um sinal sonoro. No caso de entrada de dados
codificados, o sistema deve sempre fornecer a lista dos cdigos
definidos.
Nas aes de entrada que envolvem tratamento demorado
pelo sistema, deve ser dada ateno redobrada s questes de
feedback, informando ao usurio sobre:
a indisponibilidade do sistema;
o tempo esperado do tratamento;
o estado atual do sistema;
o resultado (sucesso ou fracasso) alcanado.
Uma opo para a interrupo do tratamento deve estar
disponvel ao usurio.
5.2.1.2 As Tarefas
Uma tarefa vista como uma seqncia de aes ou
interaes elementares.
44
5.2.1.2.1 Tarefa de diagnstico
Nesse tipo de interao, o objetivo do usurio de elaborar
um diagnstico visando a recuperao de incidentes a nvel de
sistema de produo. O sistema de controle informatizado deve
apoiar o usurio apresentando-lhe os dados crticos de modo
diferenciado e lhe propondo um tipo de ajuda on-line, de
obteno direta e com orientaes redigidas em linguagem
simples, objetiva e contextualizada.
5.2.1.2.2 Tarefa corretiva
Nas tarefas corretivas, a qualidade das mensagens de erro
um requisito importante. Recomenda-se que as mensagens
tenham um nvel de detalhe configurvel, de modo a que sejam
adaptadas ao tipo de usurio, e que tenham um contedo
dinmico, variando no caso da reincidncia de erros. As
funcionalidades de ajuda, de desfazer e de refazer devem
sempre estar habilitadas. No que se refere a essas ltimas, elas
no devem ser mescladas em uma nica opo.
5.2.1.2.3 Tarefa destrutiva
Na tarefa destrutiva o sistema deve proporcionar uma
adequada proteo aos dados do usurio, atravs:
da definio de opes de comando default no
destrutivas,
da apresentao antecipada de avisos sobre as
repercusses das aes do usurio e
da solicitao de confirmao das aes destrutivas.
5.2.1.3 Os Estilos dos Dilogos
5.2.1.3.1 Dilogo por menu
A estrutura de menu proporciona um estilo de dilogo
adequado para entrada de comandos por usurios intermitentes
com o sistema, que no tenham possibilidades de memorizar um
grande nmero de opes de comando e cujas habilidades de
datilgrafos sejam moderadas. Estas opes de comando podem
ser agrupadas logicamente segundo critrios como ordem
cronolgica da tarefa ou freqncia de uso. Recomenda-se este
estilo tambm quando a tarefa principal for fortemente baseada
no mouse como dispositivo de interao. Este estilo deve
proporcionar a minimizao das aes do usurio atravs do
balano entre a largura (nmero de opes existentes) e a
profundidade (nmero de passos necessrios para disparar as
opes). No dilogo de entrada de comandos a partir de um
menu o usurio deve poder primeiro indicar a opo desejada e,
em um segundo momento, comandar sua ativao. O feedback
dessas aes deve ser adequado.
45
5.2.1.3.2 Dilogo por linguagem de comando
A linguagem de comando proporciona um estilo de dilogo
adequado para entrada de comandos por um usurio que utiliza
o sistema freqentemente e recebe treinamento assduo. Em sua
tarefa, a seqncia lgica dos comandos imprevisvel. Quanto
a suas caractersticas, uma linguagem de comando deve manter
acessvel a lista de comandos de base da linguagem, bem como
o histrico dos comandos entrados pelo usurio. Deve considerar
a experincia do usurio ao permitir processar mltiplas entradas
e interpretar sinnimos de comandos. A estrutura da linguagem
de comandos deve tambm permitir o reaproveitamento de
entradas equivocadas e mais ainda, aceit-las no caso de erros
de digitao mais comuns
5.2.1.3.3 Dilogo por preenchimento de formulrio
Este estilo de dilogo se aplica quando as entradas da
tarefa forem predominantemente de dados, tiverem uma
estrutura rgida e com poucos comandos. Os usurios, por seu
lado, no precisam ter treinamento especfico e suas habilidades
de datilgrafo podem ser moderadas. Para reduzir a carga de
trabalho e conduzir o usurio no dilogo de preenchimento de
formulrio o sistema deve, alm do previsto para entradas de
dados simples, propor uma posio adequada para o incio do
dilogo, propor facilidades de navegao entre os campos (que
no automatizem a tarefa), realar o campo com o foco atual das
aes e propor valores defaults adequados. O tratamento de um
formulrio pelo sistema deve ser comandado explicitamente pelo
usurio.
5.2.1.3.4 Dilogo por manipulao direta
O dilogo por manipulao se aplica quando direta as
entradas so de difcil elaborao e existe a possibilidade de
construir metforas a partir de objetos e entidades do mundo
real, na forma de objetos de uma interface grfica interativa.
Neste estilo de dilogo a questo de feedback assume
importncia particular. Assim, o sistema deve fornecer uma
indicao clara sobre o tipo de ao que est sendo executada e
qual objeto o foco das aes ou o selecionado pelo usurio.
As repercusses dessas aes, sejam em termos de mudana
de atributos do objeto ou de sua movimentao tambm devem
ser claramente indicadas.
5.2.1.4 Estruturas de interaes
5.2.1.4.1 Estruturas seqenciais (passo passo)
Em interaes seqenciais, como as implementadas em
dilogos questo x resposta e passo passo, s tarefas
atribuda uma seqncia rgida de execuo. Um passo s pode
46
ser realizado aps o anterior ter sido concludo. Esta uma
estrutura especialmente indicada no caso em que usurios
novatos na tarefa sejam confrontados a tarefas complicadas.
Nestas situaes, o melhor a fazer conduzi-lo
seqencialmente, porm mantendo-os no controle sobre a
interao. Isto significa que lhe deve ser possvel interromper,
finalizar e retomar a tarefa a qualquer instante.
5.2.1.4.2 Estruturas Paralela
Diferentemente das interaes seqenciais, em interaes
com estrutura paralela as tarefas podem ser realizadas em
qualquer ordem. Neste caso, imprimi-se uma flexibilidade
tarefa, pois supe-se que o usurio saiba a melhor maneira de
realiza-la, em funo dos dados que possui, ou que tenham de
ser informados. Estruturas de menus (no caso de aes de
comando) ou de estruturas de formulrios (no caso de entrada
de dados) devem manter sempre ativas as opes que do
acesso s diversas interaes da estrutura.
5.2.1.4.3 Estruturas Repetitiva
Interaes pertencentes a uma estrutura repetitiva so
aquelas que os usurios realizam repetidas vezes, como para a
entrada de diversos dados de mesmo tipo ou para a edio de
diversos objetos de mesmo tipo, etc. Para apoiar estas
situaes, as interfaces devem oferecer comandos de atalho,
valores default, facilidades de seleo mltipla, entre outros
servios.
5.2.2 Os Objetos de Interao
Um objeto de interao definido como um objeto de
software cujo processamento gera uma imagem que
apresentada ao usurio e com a qual ele pode interagir. Eles
preenchem as telas das interfaces com o usurio e podem se
basear em metforas de objetos do mundo no informatizado,
representando botes, janelas, menus, interruptores, etc. So
construdos a partir dos recursos das caixas de ferramentas ou
toolboxes dos sistemas gerenciadores de janelas, dos quais
herdam um estilo particular de apresentao e de
comportamento imediato. Assim, verifica-se uma padronizao
em termos de lxico e parte da sintaxe das interfaces de
aplicativos construdos sobre uma mesma plataforma de
desenvolvimento (Microsoft Windows, Macintosh Sistema 7,
OS/2, OpenWindows, etc.).
Do ponto de vista ergonmico, o objeto de interao possui
um atributo genrico, que se refere ao tipo de ateno que ele
possa exigir em um determinado momento na tela. Isso porque,
47
o enfoque no projeto de uma determinada tela deve ser centrado
sobre como salientar, agrupar e discriminar objetos de interao.
Alm da demanda de ateno, o projeto de um elemento
prope a configurao dos recursos relativos a noo de partes.
As partes de um objeto elementar variam de ambiente para
ambiente, mas via de regra, so definidos como primeiro plano,
um plano de fundo e bordas. Enquanto o primeiro plano recebe
as palavras e cones, o plano de fundo recebe os motivos e
sombras.
Uma composio de objetos de interao apresenta como
atributo genrico o controle de uma "lista de componentes" e de
um "layout". Os objetos desta classe desempenham o papel de
containers ao garantirem a coeso espacial na apresentao,
deslocamentos e eliminao da tela de componentes. Via de
regra, estes componentes tm os valores default para seus
atributos definidos a nvel da composio. Assim, na ausncia de
uma declarao explcita, todo componente ter as mesmas
caractersticas de estilo definidas para a composio da qual
fazem parte.
5.2.2.1 Os Painis de Controle
Os "Painis de Controle" so objetos compostos que
fornecem ao usurio um cenrio adequado, em termos dos
diferentes tipos de mostradores, de controles e de comandos
necessrios para a realizao de sua ao ou tarefa.
Eles esto divididos em Telas, Janelas e Caixas de Dilogo.
As janelas correspondem a expresso global de aplicativos e de
documentos. As Caixas de dilogo fornecem informao e
apiam as tarefas e aes individuais. As telas representam a
reunio de janelas e caixas de dilogo de diversos programas
aplicativos.
5.2.2.1.1 Janela
Toda a janela deve possuir um ttulo nico, curto e
significativo localizado em sua barra superior, centrado ou
alinhado pela esquerda. A posio do ttulo deve ser mantida
inalterada para todas as janelas do sistema. Seu layout deve ser
padronizado, propondo uma diagramao equilibrada no que se
refere a distribuio das reas livres, evitando ao mximo
problemas de alinhamentos e diferenciando claramente as
diferentes zonais funcionais. Nesse particular, o contedo de
informao deve ser pertinente e oportuno, sendo que os objetos
principais devem estar localizados de maneira que estejam bem
vista do usurio.
48
A janela do aplicativo corresponde a uma rea do terminal
fsico alocada para um programa aplicativo ou para o programa
gerente de janelas (Finder, Presentation Manager, ). Estes
aplicativos podem criar diversas outras janelas de documentos
que vo coexistir na tela. Em vista dessa possibilidade, esse tipo
de janela deve possuir uma opo de menu para o controle da
disposio das janelas secundrias. Aconselha-se estabelecer
um limite para a quantidade de janelas abertas, que no deve
ultrapassar de 7 janelas.
A janela do documento subordinada a janela do aplicativo
com a qual ela reparte o foco das aes do usurio. Este pode
ento agir sobre o documento em questo com as ferramentas
disponibilizadas na janela do aplicativo.
49
5.2.2.1.2 Caixa de dilogo
A caixa de dilogo corresponde a uma janela especialmente
destinada a apresentao de mensagens e/ou de controles para
aes que lhe so especficas.
As caixas de dilogo podem ser modais ou no modais.
So modais quando exigem uma resposta do usurio, que fica
impedido de qualquer outra ao, at que isto acontea. As no
modais permitem que o usurio trabalhe sobre outros objetos de
uma outra janela ou caixa de dilogo, enquanto que aguardam
em segundo plano, uma ao sua.
As dimenses de uma caixa de dilogo devem ser definidas
em funo de seus componentes, de modo que a relao entre o
comprimento e altura se aproxime do chamado nmero de ouro;
1/1,613. Assim como para as janelas, recomenda-se que os
ttulos das caixas devam ser centrados na margem superior ou
alinhados pela esquerda e a distribuio de seus integrantes
deva seguir uma diagramao adequada. A densidade final de
uma caixa de dilogo no pode exceder os 40 %. Sua apario
na tela pode ser padronizada em um mesmo local, determinada
pelo objeto a que se refere ou alinhada com o ttulo da caixa de
dilogo que lhe superior.
5.2.2.1.3 Caixa de Ao/Tarefa
A caixa de ao/tarefa proporciona os controles e
comandos especficos para a introduo de parmetros e para o
acionamento da ao ou da tarefa que a define. Este tipo de
caixa deve abrigar os botes de comando para validar, para
aplicar imediatamente e para cancelar uma ao. Um deles deve
ser definido "por default" e diferenciado apropriadamente. No
caso de aes destrutivas, a opo "por default" deve recair
sobre sua anulao e no sobre a prpria ao. Tambm devem
ser previstos botes de ajuda e de fechamento da caixa. A
definio do layout destes botes deve minimizar os movimentos
do mouse.
5.2.2.1.4 Formulrio e a tela de consulta
A tela de consulta e o formulrio so painis de controle
destinados especificamente s aes de consulta e entrada de
conjunto de dados. Eles devem apresentar um ttulo significativo
e um layout agrupando, diferenciando e ordenando logicamente
as diversas categorias de dados apresentadas. Alm disso, o
layout deve ser compatvel com os documentos fsicos,
manuseados pelo usurio em sua tarefa. O mesmo ocorre em
relao aos formatos dos dados apresentados e introduzidos.
50
O incio das aes de entrada em um formulrio deve se
dar a partir do campo localizado, mais ao alto e a esquerda do
painel. Esta posio inicial deve ser mantida de forma
consistente durante a interao. Os campos devem estar
adequadamente identificados, sendo que seus rtulos devem ser
visualmente diferenciados dos dados e devem conter informao
sobre as unidades, valores aceitveis e os formatos dos dados a
entrar. O alinhamento dos rtulos deve ser feito pela esquerda
ou pela direita, no caso deles apresentem comprimentos muito
diferentes. Deve ser previsto um mecanismo de simples
operao para a navegao entre os campos, geralmente
atravs da tecla TAB. Os campos de preenchimento obrigatrio
devem ser diferenciados visualmente e aqueles contendo dados
crticos para o sistema devem ser identificados e protegidos
contra acidentes de operao. Um efeito sonoro pode ser
empregado para informar sobre a proteo de um campo e/ou,
sobre o seu preenchimento total. Os controles e mostradores de
informaes sobre o estado do sistema devem estar localizados
na parte inferior do formulrio. Esta mesma regio deve ser
reservada para a apresentao caixas de mensagens de erro. O
registro dos dados entrados em um formulrio no deve ser
acionado como efeito colateral da ao de entrada de algum
dado. O usurio deve explicitamente solicitar este registro
atravs de um boto de comando, com uma denominao
coerente. Aconselha-se que o rtulo desse boto contenha a
palavra "Entre". Da mesma forma, deve ser previsto um boto
para cancelar este comando. Aps o registro das entradas, o
sistema deve preencher com traos "----" os campos
desconsiderados pelo usurio.
5.2.2.1.5 Caixa de mensagem
As caixas de mensagem fornecem informaes e instrues
ligadas a conduo, a ajuda, as advertncias, aos alarmes e aos
51
erros na interao. Elas so do tipo modais, exigindo que o
usurio tome seu conhecimento para permitir a seqncia da
interao. O boto "ok" deve ser previsto em toda a caixa de
mensagem como meio de receber a confirmao do usurio.
Quando a situao for de alarme as caixas devem estar
destacadas atravs de uma localizao central da tela, do
emprego da cor vermelho, da intermitncia ou do acionamento
de um efeito sonoro. Numa situao de advertncia elas devem
explorar o estereotipo do amarelo. As caixas de mensagens de
erro devem propor sempre um boto "Ajuda".
5.2.2.2 Os controles compostos
Os controles so objetos de interao sensveis s aes
do usurio, lhe proporcionando facilidades em termos de edio,
seleo e manipulao direta. Tratam-se de campos, botes de
comando, painis de menus, listas de seleo e barras de
ferramentas que possibilitam ao usurio tanto a entrada de
dados, como o comando de acionamento de uma funcionalidade
da aplicao.
Os controles complexos correspondem a objetos de
interao de estrutura composta com algum tipo de navegao
interna e que destinam-se especialmente seleo de controles
e comandos
5.2.2.2.1 Painel de menu
Um painel de menu destina-se a seleo de opes que
acionam os comandos do programa aplicativo. Existe a
possibilidade desse acionamento ser precedido da apresentao
de caixas de dilogo e/ou de outros menus. Em um menu as
escolhas s podem ser simples. Todas as opes de um menu
devem ser apresentadas simultaneamente, no sendo
recomendados a navegao por barra de rolagem.
52
As opes de um menu devem refletir as necessidades do
usurio em sua tarefa, de modo a formar grupos e sub-grupos a
partir de costumes ou convenes dos usurios (carnes, frutas,
legumes, etc.), de categorias lgicas (objetos, aes) ou
arbitrrias. Nesse sentido, apenas as opes pertinentes devem
ser apresentadas e devem ser ordenadas segundo algum critrio
lgico; como seqncia da tarefa, seqncia lgica, freqncia
de uso ou ordem alfabtica. Os menus muito numerosos devem
ser organizados em grupos de at 7 elementos inter-
relacionados logicamente e separados um dos outros por um
trao simples. As opes inativas devem ser apresentadas de
modo dissimulado. De modo a preservar a leveza dos painis e a
legibilidade das opes, as bordas devem ser definidas por
linhas simples suficientemente afastadas dos nomes das opes.
A opo de menu corresponde a uma rea de seleo
preenchida com o nome correto de um comando do sistema, que
enviado para a interpretao do programa aplicativo assim que
a opo seja selecionada pelo usurio.
Os diferentes estados que as opes de menu podem
assumir, "inativo", "ativo", em "foco", e "selecionado", devendo
ser visualmente diferenciados. No estado ativo, a opo se
encontra sensvel a uma ao de seleo. No estado inativo, a
seleo no possvel. O estado "em foco" corresponde ao
momento anterior a uma seleo, quando o usurio posiciona o
cursor sobre a opo e prepara-se para selecion-la. A
desativao pode ser representada atravs da dissimulao do
item (cor cinza dos caracteres). Para os itens em foco de
seleo, o padro o vdeo reverso. O feedback que informa
que uma seleo acaba de ocorrer dado pelo desaparecimento
do painel de menu e pelas repercusses da ao escolhida. Em
painis com mltiplas escolhas, uma opo j selecionada
indicada ao usurio atravs de pequenos smbolos ( , * ou
flechas).
As opes podem ser classificadas como; opo de
comando, opo de dilogo e opo de sub-menu. As opes do
primeiro tipo acionam um comando da aplicao. As de dilogo
acionam a apresentao de uma caixa de dilogo para a entrada
de parmetros de um comando. As opes de sub-menu fazem a
apresentao de outro menu, permitindo ao usurio afinar a sua
53
escolha em termos de opes de comandos. Estes diferentes
tipos de opes devem ser apresentados diferentemente. As
opes que acionam caixas de dilogo devem ser seguidas de
indicadores de continuao de dilogo "...". Aquelas associadas
a sub-menus devem apresentar um marcador em forma de
flecha. Ambos indicadores devem ser adequadamente alinhados
pela margem direita do menu.
A seleo e acionamento de uma opo de um painel pode
ser feita atravs do teclado e de um dispositivo de apontamento
(mouse, caneta tica, ou o dedo em uma tela ttil). Na interao
atravs de dispositivos de apontamento, a reas de seleo
devem ser suficientemente amplas. No caso de menus em telas
tteis ela deve ter uma altura mnima de aproximadamente 2,0
cm. A interao por teclado possibilita dois tipos de atalhos; os
aceleradores e os mnemnicos. Um acelerador um dispositivo
que permite acionar uma opo de menu, a partir de uma tecla
de funo ou de combinaes de teclas. Isto ocorre
independentemente da opo estar ou no visvel na tela. Neste
caso, a indicao das teclas aceleradoras associadas a uma
opo deve aparecer direita de seu nome. J os mnemnicos
s acionam opes de menu que estejam visveis na tela. Eles
so definidos a partir de uma das letras do nome da opo, que
aparece sublinhada. Essa letra pode ser a inicial do nome ou
uma outra que lhe seja associada. Estando o painel de menu
visvel na tela, o acionamento de uma opo atravs de seu
mnemnico ocorre pela simples digitao da letra sublinhada. Os
nomes das opes devem ser concisos, significativos e
familiares aos usurios e no devem ser abreviados. Sua
tipografia deve ser normal, com somente a primeira letra do
nome da opo em maiscula. Se uma enumerao das opes
for necessria ela deve ser numrica.
Sob o ponto de vista da tarefa, os painis de menus podem
ser principais e secundrios. O menu principal representa o
ponto de partida para a tarefa. Suas opes devem cobrir todas
as alternativas em termos de aes bsicas. Os menus
secundrios so acionados atravs de uma opo de menu,
permitindo ao usurio afinar a escolha de um comando.
Quanto a dinmica da apresentao, os painis de menu
podem ser permanentes (sempre visveis em uma posio fixa
da tela) ou transitrios (aparecerem somente quando solicitado
pelo usurio). Esses ltimos caracterizam os menus "de
desdobrar" (pull-down), em cascata" (cascading) e os de "sobre-
apresentao" (pop-up).
O menu de desdobrar apresentado na tela atravs do
acionamento de uma opo de menu principal.
O menu em cascata designa uma estrutura na qual um
painel de menu secundrio apresentado a partir do
54
acionamento de uma opo de um outro painel menu tambm
secundrio.
O surgimento na tela de um menu em sobre-apresentao
(pop-up) se d atravs do acionamento do boto direito do
mouse. As opes de um menu pop-up variam conforme a zona
funcional da tela sobre a qual o cursor do mouse se encontra no
momento em que ocorre o acionamento. O painel de menu pop-
up deve ser apresentado prximo do local onde seu acionamento
ocorreu.
Quanto a sua forma, os painis de menus constituem as
pginas de menu, as barras de menu e os menus imbricados
(hipertexto).
5.2.2.2.2 Pgina de Menu
As pginas de menu so telas nas quais o elemento
principal um painel de menu permanente. As pginas de menu
55
encontram-se encadeadas de modo arborescente. Os aspectos
principais destas estruturas de menus correspondem a largura
(nmero de alternativas por pgina) e a profundidade (nmero de
pginas por busca).
Uma pgina de menu deve possuir um ttulo significativo,
um elemento de convite interao (prompt) e um sistema de
enumerao das opes.
Na seleo por teclado, as opes da pgina de menu
devem ser enumeradas com nmeros e no com letras,
alinhados pela direita e separados do nome da opo atravs de
um ou dois espaos. A numerao de partir sempre do nmero 1
e nunca do zero. No caso das letras serem definidas para a
seleo por teclado, a enumerao deve ser alinhada pela
esquerda.
5.2.2.2.3 Barra de Menu
A barra menu um painel de orientao horizontal. Ela
deve ser posicionada no alto da tela ou da janela do programa
aplicativo, apresentando os comandos de base de um sistema
(no mais de oito opes). As barras no comportam qualquer
tipo de navegao, e sua retirada da tela s se justifica para
sistemas destinados ao grande pblico, ou se expressamente
comandada pelo usurio. Os nomes de suas opes devem ser
palavras curtas e separadas por ao menos trs espaos em
branco. Se a ordem relativa a tarefa ou a freqncia de uso no
podem ser definidas, um ordenamento alfabtico deve ser
empregado.
5.2.2.2.4 Hipertexto (Menu Imbricado)
O menu imbricado em um texto permite a construo de
dilogos do tipo hipertexto, destinado a navegao entre pginas
de textos relacionados. Esse tipo de menu deve respeitar as
recomendaes quanto a uma estrutura equilibrada, organizando
56
as opes de navegao por nvel segundo os limites da
memria de curto termo humana e as categorias lgicas e
conceituais das tarefas. A profundidade da estrutura deve ser
limitada no sentido de evitar dilogos muito compridos.

5.2.2.2.5 Barra de ferramentas
A barra de ferramentas constituda de um grupo de
controles, campos e de botes de comando, que so
apresentados em um pequeno painel amodal. Esses elementos
permitem a seleo, a parametrizao e o acionamento das
ferramentas de que dispe o usurio para realizar tarefas
diversas no sistema.
5.2.2.2.6 Lista de seleo
Uma lista de seleo um tipo de menu que empregada
para a entrada de dados cujos valores possveis sejam
conhecidos de ante-mo. O comprimento recomendado de uma
lista deve permitir a visualizao imediata de apenas 7 (+- 2)
itens. O projetista deve especificar a ativao de mecanismos de
navegao internos (barras de rolamento) quando o nmero de
escolhas possveis se torne elevado. O limite mximo de algo
como 50 itens que devem ser ordenados logicamente, segundo a
freqncia de uso e/ou uma ordem alfabtica. Separadores
devem ser empregados para marcar a organizao dos itens
segundo grupos lgicos. Se qualquer organizao no for
57
possvel, os separadores (um trao simples) devem ser dispostos
a cada 6 linhas de alternativas.
No caso de restries de espao as listas podem ser
configuradas como desdobrveis. Desta forma somente a
primeira linha da lista apresentada inicialmente. Para visualizar
as outras alternativas o usurio deve acionar o boto de
desdobramento ( direita da primeira linha) que ir apresentar o
restante da lista para baixo ou para acima e no primeiro plano da
tela (tapando outros elementos). A largura da lista pode ser
determinada pelo item mais longo se ele for menor do que 20
caracteres. Caso contrrio ela deve ser definida a partir da mdia
dos comprimentos de cada item.
A lista de seleo composta de itens que, a semelhana
com as opes de um menu, podem assumir os estados
"inativo", "ativo", em "foco" e "selecionado", com representaes
visualmente diferenciadas.
5.2.2.2.7 Caixa de combinao
A caixa de combinao combina em um s objeto uma lista
de seleo de desdobrar associada a um campo de dados. Ela
proporciona mais facilidade ao usurio ao selecionar um item da
lista a partir dos caracteres digitados no campo de dados.
58
5.2.2.3 Os grupos de controles
5.2.2.3.1 Grupo de botes de comando
O grupo de botes de comando deve ser definido nas
situaes em que as opes de comandos possveis forem em
nmero reduzido. Seu arranjo pode seguir duas regras. Eles
podem ser alinhados verticalmente e a direita do objeto a que
fazem referncia, ou horizontalmente e abaixo deste objeto. Um
boto "por default" deve ser definido, visualmente diferenciado e
posicionado ao alto, se a orientao for vertical , ou a esquerda,
no caso de uma orientao horizontal.
5.2.2.3.2 Grupo de botes de rdio
Um grupo de botes utilizado para a entrada de dados deve
prever botes de rdio (radio-button), quando o conjunto de
valores possveis para um dado forem conhecidos, no
excederem sete alternativas, e forem mutuamente exclusivos.
O grupo de botes rdio rene um mximo de sete itens de
seleo que devem estar distribudos eqidistantemente. Grupos
maiores devem ser subdivididos logicamente e visualmente
separados por uma linha simples ou um retngulo de linhas
simples (caixa de grupamento)
59
5.2.2.3.3 Grupo de caixas de atribuio
Se os valores possveis para uma entrada no forem
mutuamente exclusivos, estando envolvidos em uma escolha
mltipla, deve-se prever um grupo de caixas de atribuio
(check-box).
O layout de um grupo de caixas de atribuio (check-box)
est sujeito s mesmas recomendaes propostas para um
grupo de botes de rdio.
5.2.2.3.4 Grupo de campos/mostradores de dados
Os grupamentos de campos e mostradores de dados
devem ser definidos segundo critrios lgicos de formao e de
ordenamento. Assim os dados devem ser reunidos segundo
critrios tradicionalmente empregados pelos usurios ou
segundo as funcionalidades definidas ou ainda segundo critrios
arbitrrios. Em todos os casos a ordem de apresentao deve
seguir critrios de seqencialidade, importncia ou freqncia de
uso. O destaque de um campo de dados pode se dar pelo seu
posicionamento ou pelo emprego das cores.
5.2.2.4 Os controles simples
5.2.2.4.1 Boto de comando
Em relao aos comandos editveis, botes de comando
facilitam consideravelmente a tarefa do usurio, que realiza uma
atividade mental de reconhecimento e no de recuperao.
Nesta ltima o seu rendimento humano superior. Outro aspecto
importante dos comandos selecionveis est ligado a abstrao
dos detalhes da sintaxe dos comandos. O usurio conduzido
na entrada de parmetros de acordo com a opo de comando
selecionada e os parmetros j entrados. Este fato proporciona
uma reduo importante de erros de sintaxe.
60
Os estados possveis para um boto de comando incluem
"ativo", "inativo", "default" e "ativado" que devem ser visualmente
diferenciados. O boto definido por default tem o foco das aes
do usurio. Dessa forma, seu acionamento facilitado ao usurio
que pode tanto usar o dispositivo de apontamento como as
teclas "Enter" ou "Return". Os nomes de botes de comando
devem ser concisos, significativos e familiares e quando eles
acionam caixas de dilogo, devem ser seguidos de indicao de
continuidade "...".
5.2.2.4.2 Boto de seleo
O boto de seleo utilizado quando uma entrada de
dados corresponder a ativao e desativao de um atributo ou
entidade (on-off). Eles correspondem aos check-boxes,
interruptores, radio buttons e outros interadores similares. Em
grupos, os check-boxes e radio-buttons tem um comportamento
estabelecido por conveno. Os primeiros permitem escolhas
mltiplas enquanto que os radio-buttons trabalham com escolhas
simples e mutuamente exclusivas. Segundo essa conveno a
utilizao de botes de rdio isolados no tem sentido e deve ser
evitada.
5.2.2.4.3 Cursor do dispositivo de apontamento
Os cursores representam a classe de controles
verdadeiramente manipulveis pelo usurio. Seu objetivo de
permitir a designao ou a indicao de uma posio na tela.
atravs do cursor do dispositivo de apontamento que o usurio
seleciona e aciona parmetros e funcionalidades dos diferentes
objetos.
Sua forma deve ser diferencivel, ao mesmo tempo em que
no prejudique a visualizao dos objetos que encobre. O cursor
61
do mouse oferece a possibilidade de definio de diversas
formas que se alternam em funo de seu posicionamento ou do
tipo de tarefa. Neste caso elas devem ser significativas e ao
mesmo tempo fornecer um apoio ao usurio. Por exemplo,
quando a tarefa exigir preciso na indicao, a forma definida
pode incluir um crculo. O projetista deve definir valores para a
taxa de deslocamento levando em considerao um
compromisso entre a velocidade e a preciso no posicionamento.
5.2.2.4.4 Escala
A escala um controle que permite ao usurio a introduo
de um valor numrico pelo ajuste de um cursor em uma
determinada posio sobre uma linha graduada. A barra de
rolamento um exemplo deste tipo de objeto.
5.2.2.4.5 Dial
O dial se apresenta como um objeto circular graduado
numericamente entre dois limites a intervalos regulares. Da
mesma forma que na escala, o usurio interage com o dial
atravs do cursor.
5.2.2.5 Os campos de entrada
As possibilidades em termos de controles editveis incluem
os campos para a edio de textos e de objetos grficos.
5.2.2.5.1 Linha e rea de comando
As reas e linhas de comando correspondem a campos de
edio uni e multi-lineares, cujo contedo, introduzido pelo
usurio, enviado ao programa aplicativo visando acionar uma
ou mais de suas funcionalidades. Neste sentido, esses
comandos editveis proporcionam grande flexibilidade ao
usurio, que pode se valer de forma imediata e direta de todas
as opes de comandos previstas na linguagem. A rea de
62
comando em especial fornece recursos de histrico, para que o
usurio possa avaliar e retomar estratgias de interao. Os
comandos deste tipo devem ter sua localizados padronizada, de
preferncia na parte inferior da tela e a rea de comando no
deve ser inferior a quatro linhas.
5.2.2.5.2 Campo de dados
Um campo de dado por definio uni-linear. Eles recebem
dados cujos valores no podem de ante mo, ser previstos pelo
projetista e cujos comprimentos no excedam os 40 ou 50
caracteres. Todo o campo de dado deve apresentar um rtulo
identificativo e convidativo (prompt), para apoiar o usurio na
entrada de um dado. Isso pode ser feito atravs da explicitao
do formato (mm/dd/aa) do dado, de sua unidade (cm, pol) e dos
valores possveis (1 a 10). Um smbolo padronizado, em geral :
deve ser empregado como explicitao do convite entrada. O
rtulo do campo de dado deve ser conciso, significativo e familiar
para o usurio e ser escrito de tipografia normal (somente a
inicial em maisculo). Em geral, o rtulo deve ser
consistentemente colocado ao lado esquerdo do campo ou
acima desse e alinhado pela esquerda.
Com o objetivo de minimizar as aes do usurio o
projetista pode especificar um valor a ser proposto "por default"
ao usurio. Na escolha de um modo de edio "inserir entre"
deve ter a preferncia sobre o modo "escrever sobre". Nesse
particular, seja qual for a definio ela deve ser mantida
consistente durante o projeto da interface. Os mtodos para o
tratamento dos valores entrados podem considerar equivalentes
as letras maisculas e minsculas. O preenchimento dos zeros e
dos pontos decimais desprezados pelo usurio tambm deve ser
considerado.
Em entradas de valores codificados com mais de 10 letras
ou 5 dgitos sem significado para o usurio, um esquema de
pontuao com espaos, vrgulas, hfens ou barras pode ser
63
definido. O objetivo nesse caso de dividir essas entradas em
grupos de 3 a 4 caracteres, para evitar os erros e facilitar a
leitura. Os dados entrados devem ser checados quanto a sua
conformidade de tipo, cabendo ao projetista declarar uma
expresso de destaque como um bip sonoro, para alertar ao
usurio quando os erros acontecerem.
5.2.2.5.3 Campo de Texto
O campo de texto por definio multi-linear. Seu tamanho
em termos do nmero e do comprimento de linhas deve ser
adequado para proporcionar um desempenho eficiente na tarefa
de entrada de textos. Para a facilidade de leitura o comprimento
das linhas no deve exceder os 40 caracteres e a altura do
campo deve proporcionar a apresentao de um mnimo de 4
linhas.
5.2.2.5.4 Campo grfico
O campo grfico se define nos recursos de edio grfica
que proporciona ao usurio. As recomendaes ergonmicas
so econmicas em relao a essa classe de objetos. Elas se
referem as diferentes formas do cursor face aos diferentes tipos
de tarefa.
5.2.2.6 Os mostradores estruturados
Os dados e informaes interligadas a uma srie de
variveis do contexto do sistema devem ser apresentados
atravs de grficos, tabelas ou listas, textos, mapas, diagramas,
etc.. Essas formas de apresentao facilitam o exame de dados
numerosos permitindo, em maior ou menor grau, a identificao
das inter-relaes e tendncias. O critrio de agrupamento dos
dados que participam dessa estruturas deve ser lgico. A
discriminao de um grupo de dados nas telas pode ser feita
atravs de seu posicionamento, pelo emprego de cores ou pela
definio de uma caixa de grupamento.
64
5.2.2.6.1 Lista/Coluna de Dados
Toda lista/coluna de dados deve possuir um cabealho
conciso, e representativo dos dados apresentados, dos quais
deve estar visualmente diferenciado. O alinhamento dos dados
na lista deve dispensar cuidado especial e sua enumerao deve
ser feita a partir de nmeros, evitando as letras e suficientemente
afastada do texto. No caso da lista se estender alm dos limites
de espao de tela, o projetista pode optar entre dois tipos de
navegao possveis: por paginao ou por rolamento. A
paginao se aplica no caso de usurios inexperientes ou
quando a tarefa envolver a busca de uma informao isolada.
Este recurso demanda a definio referente a mensagem de
continuao. Quando o objetivo da tarefa for a busca de relaes
entre dados, a tcnica de rolamento preferencial. O formato da
coluna pode ser normal ou identado, prevendo assim a
possibilidade de hierarquias de itens e sub-itens.
5.2.2.6.2 Tabela de Dados
tabela de dados aplicam-se as recomendaes da lista.
Deve-se ter cuidado especial na definio de cabealhos para
linhas e colunas (se necessrios), que devem ser diferenciados
entre si. Alm disso, uma tabela pode apresentar blocos de
dados e informaes interligadas. Os blocos devem ser definidos
logicamente e separados fisicamente, por uma linha em branco
ou por um trao simples, do resto da tabela.
5.2.2.6.3 Texto
A classe "Texto" apresenta informaes na forma de uma
cadeia de frases e perodos. Sua dimenses devem ser definidas
de modo a apoiar a tarefa de leitura. Nesse particular, o formato
do texto pode ser normal ou em colunas. Em formato normal o
alinhamento deve ser definido pela margem esquerda. Em
formato coluna, ele deve ser justificado. O espaamento entre
colunas pode ser de 3 caracteres se elas forem justificadas pela
direita. Em caso contrrio este valor passa para 8 caracteres. O
comprimento das linhas no pode exceder os 50 a 60 caracteres
em formato normal e os 35, em formato coluna. Os pargrafos
devem, em ambos formatos, ser espaados de
aproximadamente uma linha em branco. Sob hiptese alguma
um texto que deva ser lido pode aparecer piscando (blinking) ao
usurio.
65
O projetista deve explorar adequadamente os recursos de
estilo para realar as informaes importantes de um texto, sem
no entanto, exagerar no negrito ou sublinhado. Ele deve evitar de
apresentar textos exclusivamente em letras maisculas. Para
facilitar a leitura, as fontes para devem ser proporcionais e deve-
se evitar a hifenizao. O enquadramento por bordas pode ser
til para destacar o texto na tela.
5.2.2.6.4 Grfico
Os grficos apresentam espacialmente dados ou variveis
correlacionadas. Seus diferentes formatos se aplicam para;
multi-linha -> anlise de tendncias,
grfico de superfcies -> exame de valores cumulativos,
grficos de barra -> exame de amostras a intervalos
discretos,
grficos de setor -> anlise de valores que representam
partes de um todo.

66
O ttulo de um grfico deve ser descritivo das correlaes
apresentadas. As curvas podem ser diferenciadas atravs do uso
de traos pontilhados, smbolos geomtricos, espessuras e
cores. Na configurao das escalas, merecem ateno as
definies relativas ao rtulo geral, ao tamanho das letras,
marcao inicial (0), ao intervalo de rotulao (a cada 1,2,5 e 10
marcaes), ao nmero de sub-divises (<9) e s progresses
horizontal (esquerda->direita) e vertical (baixo->cima).
5.2.2.6.5 Diagrama de figura
Um diagrama uma representao grfica, que pode ser
um desenho ou uma fotografia de um objeto ou de uma
estrutura, realizados com o objetivo de mostrar as relaes
espaciais entre os componentes de um todo. No caso de
limitao de espao eles podem ser organizados em sees,
devendo ento ser previstos botes de comando para a
visualizao das diversas sees.
Uma lupa mvel ou zoom deve estar disponvel para
auxiliar na visualizao dos detalhes do diagrama, que pode
tambm contar com o apoio de uma funo de rotao. As partes
importantes podem ser destacadas atravs caixas de
enquadramento ou de flechas intermitentes.
5.2.2.6.6 Diagrama de fluxo


Os diagramas de fluxo so representaes grficas
elaboradas para a apresentao esquemtica de dados
logicamente relacionados em um processo seqencial. Elas se
aplicam especialmente para tarefas de resoluo de problemas e
de gesto de projetos. Seus elementos devem ser apresentados
segundo uma ordem lgica, respeitando as convenes
estabelecidas em termos de esquerda para a direita, do alto para
baixo e no sentido dos ponteiros dos relgios. As trajetrias mais
provveis devem ser minimizadas, o que pode ser conseguido
67
atravs da antecipao de pontos de decises com o menor
nmero de alternativas. Economizar espao a partir da
combinao de decises, pode confundir o usurio e algo a ser
evitado. A disposio de alternativas em um bloco deve respeitar
algum tipo de lgica e ser coerente. Por exemplo o "sim" deve
sempre estar a esquerda e o "no" a direita ou abaixo.
Finalmente, a escolha dos formatos dos blocos e dos conectores
deve ser consistente com o tipo de ao e de relao
representados.
5.2.2.6.7 Mapa
Um mapa uma representao reduzida de uma regio
que utilizada para a apresentao de dados fsicos e
geogrficos. Sua apresentao pode assumir, segundo as
necessidades do projetista, a forma de um mapa poltico ou de
uma carta geogrfica. Os mapas so apropriados para a
apresentao de dados relativamente estveis como populao,
atividade econmica, etc. As cartas se aplicam especialmente na
apresentao de dados variveis como a progresso de massas
de ar. Mapas e cartas devem apresentar uma orientao
consistente em termos de norte-sul alm de uma escala precisa
e compatvel com os dados a serem apresentados. Um efeito de
curvatura pode ser definido quando da apresentao de
superfcies vastas. Os rtulos descritivos devem ser
posicionados cuidadosamente, de modo que no se afastem de
sua referncia, que no encubram outras informaes e que no
venham a causar um congestionamento visual importante. Uma
legenda deve ser definida para cdigos de textura, cores e de
intensidade de cores.
68
Alguns autores (Norman, 1991) entretanto consideram que
o uso frequente de legendas pode atrapalhar o usurio, podendo
ser uma indicao da falta de adequao nas escolhas feitas em
termos dos tipos de representaes a adotar. As cores podem
representar dados substitutivos como alinhamentos polticos,
tipos de reservas minerais, de florestas, de lavouras, etc. J a
intensidade de cores e texturas, constituem escalas aditivas e se
aplicam na representao de dados numricos como altitudes,
demografias, indicadores econmicos, etc. .
Funes de zoom e de navegao devem estar disponveis
aos usurios. Um cursor de localizao e um indicador de
distncias devem ser previstos nos casos de deslocamentos
possveis. Isto com o objetivo de informar, grfica e
numericamente, a posio do usurio sobre a carta.
5.2.2.7 Os Mostradores Simples
5.2.2.7.1 Mostrador de Dados
Os mostradores de dados devem possuir rtulos
identificativos e descritivos para explicitar a unidade e o formato
dos valores apresentados. Sempre que for possvel o projetista
deve adotar formatos padronizados e coerentes com as
convenes de usurio. Uma forma digital (dgitos) deve ser
definida quando houver uma necessidade de preciso de leitura
do dado. No caso de valores que variem rapidamente, uma
forma grfica analgica deve ser definida.
Se o dado a apresentar for demasiadamente longo ele deve
ser divido em grupos lgicos. No que se refere as formas
auxiliares, as cores, em especial o amarelo, pode ser empregado
para agrupar dados espalhados na tela. Cores mais saturadas
(contraste) ou mais intensas (brilho) podem ser utilizadas para o
destaque de dados crticos. O emprego da intermitncia visual
(pisca-pisca) para destacar um dado deve ser feito com bastante
cuidado. De modo a preservar sua legibilidade, sugere-se a
adoo de um elemento extra, como um indicador ao lado do
dado, ao qual seria atribuda a intermitncia visual. O tamanho
dos caracteres tambm pode ser utilizado como forma de
destacar dados urgentes.
5.2.2.8 As Orientaes
Uma orientao definida como uma mensagem do
projetista ao usurio. Ela desempenha uma funo fundamental
para as manipulaes cognitivas dos usurios envolvendo
dados, controles e comandos. A ausncia de informao
inviabiliza a operao de um sistema por usurios leigos.
As classes de orientao distinguem os rtulos, as
mensagens (de orientao, de ajuda, de alerta, de aviso e de
69
erro), os indicadores de estado e de progresso, e os efeitos e
motivos sonoros.
5.2.2.8.1 Rtulo
Um rtulo pode assumir a forma de um cone, de um sinal
geomtrico, de uma palavra ou de um texto.
Os rtulos textuais devem empregar palavras distintas e
significativas, alm de concisas. Caso demandem uma ateno
particular as formas auxiliares podem ser empregadas como
expresso discriminativa. O tamanho dos caracteres deve estar
definido segundo o critrio da legibilidade. O posicionamento
relativo ideal acima ou a esquerda do objeto a que fazem
referncia. Neste particular eles devem estar suficientemente
isolados ao mesmo tempo em que permanecem prximos do
objeto.
Em suas relaes com outros objetos, esta classe
desempenha diferentes tipos de funes, incluindo: a
identificao, a descrio, a incitao, a indicao e a separao.
Face a estas funes e as relaes com diferentes objetos
possvel definir algumas das instncias de um rtulo.
O ttulo um rtulo identificativo forosamente textual,
empregado como funo de identificao em textos, grficos,
tabelas, janelas, caixas de dilogo, etc.
Um cabealho o rtulo de uma lista ou tabela, devendo
ser destacado ou discriminado atravs do tamanho ou do estilo
de caracteres sublinhados, coloridos, etc..
Da mesma forma que o cabealho se define na relao com
listas, um prompt se define na relao com campos de dados.
Um prompt o rtulo de convite interao que deve ser
destacado ou diferenciado atravs de um posicionamento
adequado na tela.
O marcador tem a forma de um pequeno sinal que
colocado ao lado de objetos como itens de seleo e opes de
menu principalmente, para indicar seu estado j selecionado.
O separador tem a forma de uma linha simples que define
uma separao entre os itens ou opes de um menu ou lista de
seleo.
70
5.2.2.8.2 Mensagem
As mensagens incluem as orientaes, as ajudas, os
alertas, os avisos e os avisos de erro. Dependendo do ambiente
operacional do sistema, elas podem ser apresentadas dentro de
caixas de mensagens ou diretamente nas telas. As mensagens
podem ser permanentes ou transitrias, modais ou amodais, e
sua apresentao pode ser solicitada pelo usurio ou
comandada pelo sistema em resposta a uma ao do usurio ou
de uma mudana do contexto do sistema.
Elas so apresentadas geralmente na forma textual, que
especialmente adequada para lidar com noes abstratas e
expressar dedues lgicas, podendo ser complementadas
atravs de algum elemento grfico (cone ou figura). As frases
devem ser afirmativas e diretas, na voz ativa, evitando
pontuaes desnecessrias e apresentando os argumentos
segundo uma ordem lgica.
Assim como os rtulos, as orientaes so elementos
permanentes das telas. So frases, que colocadas vista do
usurio tentam orient-lo em sua tarefa, atravs de um
vocabulrio simples, significativo e familiar.
As ajudas so solicitadas explicitamente pelo usurio e
podem permanecer na tela enquanto ele completa sua tarefa
(amodais). Seu contedo deve ser contextual, isto , deve se
referir ao contexto da tarefa que o usurio est realizando.
A apresentao de avisos e alertas comandada pelo
sistema em resposta a uma ao do usurio ou a uma mudana
no contexto exterior (rede, dispositivos, etc.) Ambas so modais,
exigindo uma resposta do usurio antes de lhe devolverem o
controle. Avisos e alertas se diferenciam atravs da importncia
que lhes atribuda. Assim sendo, os alertas devem ter uma
apresentao diferenciada e nica.
As mensagens de erro so modais e so apresentadas pelo
sistema em resposta a uma ao equivocada do usurio. Elas
devem ser polidas, neutras e contextuais. Devem ser concisas
evitando porm os cdigos ou abreviaturas. Devem apresentar a
informao principal no incio deixando os elementos a
memorizar para o final. A tipografia deve ser a de uma frase
normal (somente a inicial em maisculo).
5.2.2.8.3 Indicador de Progresso
O indicador de progresso um mostrador especializado
na apresentao da sucesso de estados de um processo linear
e finito. Tipicamente, tm a forma de uma barra, cujo
preenchimento d uma indicao do que j foi feito e do que falta
a ser realizado no processo.
71
5.2.2.8.4 Efeito Sonoro
Os efeitos sonoros so estruturas sonoras simples que
atuam como cones sonoros para chamar a ateno do usurio e
fornecer feedback. Eles devem ser consistentes com a situao
a assinalar, pouco numerosos e suficientemente diferenciveis.
Como cones sonoros, os efeitos sonoros podem apresentar
formas concretas e abstratas. As concretas imitam sons como o
fechamento de uma porta metlica para representar o
fechamento de um arquivo de dados. As abstratas se baseiam
em convenes sociais como aplausos para representar uma
aprovao.
5.2.2.8.5 Motivo Meldico
Motivo meldico denota uma breve sucesso de tons
combinados de maneira a produzir um padro de ritmo
suficientemente distinto para que ele funcione como uma
entidade individual e reconhecvel (Loshe, Walker, Biolsi, &
Rueter, 1991). A seqncia de tom e o ritmo definem a partitura
de um "motivo sonoro". As caractersticas dinmicas de
"crescendo" e "decrescendo" podem ser utilizadas para indicar
aes de iconificao, movimentao e mudanas de tamanho
de janelas, por exemplo. Ritmos e de timbres so bastante
eficazes para efeitos de diferenciao.
5.2.2.8.6 Locuo e Fala
Estas classes representam uma forma alternativa de
transmisso de dados e mensagens ao usurio, aplicando-se
aos ambientes de trabalho silenciosos, onde o operador tenha
necessidades de pequenos deslocamentos e podem ser de
"fonte" sintetizada ou registrada.
A classe "locuo a verbalizao de palavras simples ou
compostas, enquanto que a Fala a verbalizao de textos de
mensagens. A locuo pode ser usada para demonstraes,
simulaes ou instrues e devem envolver somente as
informaes, crticas ou necessrias, que tenham um carter de
domnio pblico. Se o conjunto de frases for em pequeno nmero
elas devem ser registradas. Se elas foram sintetizadas, deve-se
tomar cuidado em definir um ritmo adequado.
O timbre de voz pode ser usado para destacar ou
discriminar a expresso falada que no deve ser muito longa.
Um meio adequado de permitir a interrupo da locuo deve
estar disponvel ao usurio.
5.2.3 Os Sistemas de Significado
Os sistemas de significado referem-se as relaes
simblicas estabelecidas na transmisso de um contedo de
informao por meio de uma expresso perceptvel e tratvel
72
pelo sistema cognitivo humano. Essas relaes referem-se a
entidades como smbolos e sinais.
Considera-se que em um sinal (Chevalier, 1980) a relao
entre a forma de contedo e forma de expresso seja arbitrria,
ou seja depende do conhecimento mtuo das regras de
codificao. Os sinais usados tanto em uma linguagem natural
como na lgebra ou na matemtica tem assim uma capacidade
de transmitir um conhecimento mais ou menos objetivo. Em um
smbolo, a homogeneidade entre expresso e contedo
estabelece uma representao motivada ou concreta, onde o
carter espontneo da interpretao essencial. A citao de
Chevalier (pg. XV) oportuna para concluir este entendimento:
"o smbolo carregado de realidades concretas. A abstrao
esvazia o smbolo e da vida ao sinal".
5.2.3.1.1 cones
Um cone pode corresponder a diferentes tipos de
representaes. Chevalier, em seu Dicionrio dos Smbolos
esclarece sobre variaes simblicas pertinentes ao projeto
representaes grficas:
Smbolo - representaes grficas motivadas ou
concretas; um desenho de uma impressora para designar
o dispositivo fsico. Neste grupo se incluem as miniaturas.
Emblema - uma figura adotada convencionalmente para
representar uma idia, um ser fsico ou moral; bandeiras
nacionais e logomarcas.
Atributo - um acessrio caracterstico para designar o
todo; garfo e da faca para representar um restaurante,
asas para companhias areas, rodas para o transporte
rodovirio, etc.
Arqutipo - exemplares de classe para representar o
conjunto; um exemplar de histograma para representar as
escolhas possveis em termos de grfico de dados.
Analogia - relao entre seres ou noes
essencialmente diferentes, mas semelhantes sob um
determinado aspecto; taa de vinho usada como smbolo
de fragilidade.
Se possvel, use cones prontos respeitando seus
significados (esteritipos para cones). Se for desenh-los siga
as seguintes recomendaes:
Desenhe cones simples, com poucos elementos, mas
com apelo visual.
Use metforas de objetos em vez de abstraes sobre
idias ou conceitos
Amplie os elementos significativos dos cones (que os
distinguem)
73
Evite grossos contornos
Use poucas cores
Empregue um grid para o desenho de cones
Desenhe cones consistentes em seu conjunto
Use efeitos de sombra (fonte luminosa no canto superior
esquerdo) e perspectiva
Respeite a escala dos outros objetos da tela. No os
faa nem muito grandes, nem muito pequenos
Os cones devem ser significativos, apropriados, coerentes,
consistentes, claros, simples e definidos em pequeno nmero
(no mais do que 20). Seu tamanho deve ser econmico em
relao ao espao de tela. Dependendo de sua utilizao
aconselha-se a adoo de bordas bem definidas.
Diversos autores indicam a necessidade de um rtulo
identificativo centrado na margem inferior, ou de bolhas de ajuda
(tool-tips), uma pequena descrio de um objeto que aparece na
tela ao se posicionar o cursor do dispositivo de apontamento
sobre ele.
5.2.3.1.2 Cdigos de formas
Os cdigos de forma envolvem os sinais geomtricos
construdos a partir de primitivas grficas (linha, arco, retngulo,
etc.). Eles correspondem a uma da classe de sinais abstratos
que para o sucesso na comunicao dependem do
conhecimento mtuo das regras de codificao. Os crculos,
quadrados, tringulos e retngulos so utilizados por exemplo,
para codificar classes de eventos em grficos estatsticos.
Aconselha-se no utilizar mais do que 15 opes de sinais
geomtricos.
5.2.3.1.3 Denominaes
As denominaes utilizadas em uma interface humano-
computador constituem cdigos de expresso textual cujos os
termos (sinais arbitrrios) so retirados da linguagem articulada
pela populao de usurios em sua tarefa com o sistema. As
regras de codificao desses termos so definidas, de modo
mais ou menos formal, no ambiente de trabalho dos usurios.
Assim, a linguagem textual da interface deve ser constituda de
termos empregados no contexto de trabalho, portanto
significativos e familiares para o usurio (linguagem operativa),
alm de concisos.
5.2.3.1.4 Abreviaturas
As abreviaturas so diminutivos de denominaes que
devem ser utilizadas somente quando absolutamente necessrio.
Alm de suficientemente distintas entre si, elas devem ser curtas,
claras e significativas.
74
5.2.3.1.5 Cdigos alfanumricos
Os cdigos alfanumricos so cdigos de expresso textual
que constituem sinais arbitrrios cujas possibilidades tanto em
termos de contedo como de expresso so definidas por regras
de codificao. As consideraes sobre os valores a adotar para
cdigos alfanumricos arbitrrios indicam no utilizar valores
maiores do que 4 ou 5 caracteres. Se isto for inevitvel deve-se
recorrer a pontuaes e sub-grupamentos. O limite para cdigos
alfabticos arbitrrios de 7 a 10 letras. No caso de cdigos
alfanumricos deve-se procurar arranjar letras e nmeros em
grupos separados, como forma de evitar combinaes perigosas
entre caracteres semelhantes.
5.2.3.1.6 Cdigos de cores
O emprego das cores na concepo de interfaces humano-
computador tem sido alvo de numerosas recomendaes
ergonmicas. Elas aconselham o uso de cores para transmitir
informaes, chamar a ateno, contrastar e associar objetos de
interao. O uso puramente decorativo desaconselhado. Para
que sua utilizao seja eficaz, deve-se tomar cuidado com trs
aspectos:
(i) a legibilidade final da informao;
(ii) com os efeitos das cores sobre a performance
cognitiva do usurio e;
(iii) com as possibilidades dos dispositivos fsicos.
Estas precaues visam conter a confuso visual resultante
do emprego arbitrrio e exagerado de cores no pertinentes.
O cdigo de cores deve prever na medida do possvel
motivado e composto de um elenco reduzido e equilibrado de
opes (no mais do que 10 ou 11 cores). Estas no devem
estar associadas a mais do que um significado e deve respeitar
os seguintes esteretipos naturais:
o vermelho deve ser utilizado para perigo, alarme,
ateno, alerta, calor e comandos de interrupo.
o amarelo para advertncias, teste e lentido.
o verde para passagem livre, normalidade, vegetao e
segurana.
o laranja para valor limite e radiao.
o azul para frio, gua, cu e calma;
o cinza para inatividade, neutralidade;
o branco uma cor neutra.
Cdigos arbitrrios expressos a partir de cores devem ser
claramente indicados aos usurios atravs de uma legenda.
75
As variaes de cores, definidas a partir da luminosidade e
do contraste no podem ser mais do que trs e devem respeitar
os significados da cor principal. Altos nveis de contraste e de
iluminao podem ser definidos para as cores utilizadas no
destaque de dados importantes.
Devido a coabitao de dispositivos fsicos coloridos e
monocromticos, a cor no deve ser utilizada como nica forma
de uma expresso. Assim, os projetista devem fazer a definio
de uma forma alternativa e redundante para o significado
corrente.
5.2.3.1.7 Cdigos de fontes
O estilo complementa as capacidades em termos de
transmisso de informao das formas textuais. Os recursos
desta classe incluem fontes, estilos e tamanhos. A utilizao do
estilo como cdigo auxilia na compreenso dos elementos de um
texto e deve ser empregado de maneira consistente. Segue
abaixo alguns objetivos definidos para os tipos de fontes:
Arial -> ttulos e cabealhos de documentos
Avant Garde -> grandes ttulos
Courrier -> documentos impressos, cartas
padronizadas, correspondncia
Helvtica -> relatrios, ttulos de captulos, de sees,
cdigo de programas
Letter Gothic -> texto que deve ser simples e claro
Romano -> correio padronizado
Times-> documentos diversos, de mltiplo uso,
comentrios em programas
Ultrablack -> etiquetas de embalagens
Os recursos em termos de estilo devem ser usados com
cautela, para discriminar ou destacar uma informao textual,
incluindo caixa, negrito, itlico e sublinhado. O tamanho dos
caracteres deve ser apropriado (18 a 24 para transparncias e
10 a 12 para trabalho normal) e permanecer inalterado na
mudana de fontes.
5.2.3.1.8 Cdigos de Textura
A textura utilizada como codificao arbitrria na
apresentao de grficos e mapas. As diferentes opes de
textura podem ser empregadas tanto como escalas aditivas
como substitutivas. Se utilizadas juntamente com palavras elas
devem ser escolhidas de modo a no prejudicar a leitura.
5.2.3.1.9 Cdigos de vdeo reverso
O vdeo reverso uma codificao binria utilizada para o
destaque de objetos, itens e opes selecionadas pelo usurio.
Deve ser dada ateno especial na rea total de inverso, que
76
deve incluir os espaos vizinhos ao objeto, principalmente se
tratando de palavras. As de inverses de textos coloridos em
fundo colorido devem ter seu resultado final testado em termos
do contraste entra letra e fundo.
5.2.3.1.10 Cdigos de intermitncia visual (pisca-pisca)
A intermitncia pode ser aplicada para o destaque em
situaes excepcionais, em que o perigo de acidentes imponha
um carter de urgncia. Esta codificao, essencialmente binria
no deve ser aplicada a mais de um elemento de cada vez. A
taxa de intermitncia pode variar entre 2 e 5 Hz. Na configurao
de um objeto intermitente, o projetista deve prever um meio,
associado a uma tecla, que permita ao usurio desativar a
intermitncia.
5.2.4 As Primitivas
As formas para a expresso de um objeto de interao
resultam da articulao de substncias de um contnuo
perceptvel ao sistema cognitivo humano.
5.2.4.1 As formas visuais
As formas de expresses "visuais" incluem as formas
grficas e textuais. A forma grfica envolvida com questes
ergonmicas principalmente a cor, a fonte e o arranjo.
5.2.4.1.1 Cores
A Cor como forma uma forma empregada na expresso
grfica de objetos de interao. Recomenda-se cuidado com o
uso indiscriminado da cor. Primeiro faa o projeto em P&B e
depois o colora com cuidado, usando cores neutras. Assim, use
poucas cores, use cores com mesma luminncia (brilho) e use
cores brilhantes com cautela.
As cores podem causar sensaes sobre as pessoas.
Sabe-se, por exemplo que o verde descansa, o vermelho: atrai a
ateno e pode causar irritao, o azul d sono e o amarelo, ao
contrrio, desperta as pessoas.
Use cores de forma consistente e evite usar cores opostas
no espectro em reas muito prximas
Espectro/Arco ris:
77
5.2.4.1.2 Fontes
As consideraes sobre o emprego de fontes como forma
esto envolvidas com o uso da serifa e o espaamento entre os
caracteres. A serifa caracterizada por uma terminao saliente
dos caracteres conforme ilustrada na primeira letra da figura
abaixo. Fontes sem serifa so de percepo leve, mas de difcil
leitura. Assim, nos ttulo e rtulos curtos deve-se empregar
fontes sem serifa. Emprega-se fontes com serifa nos textos como
forma de facilitar o reconhecimento rpido dos caracteres.
S S
No use serifa para vdeos de baixa resoluo. No use
fontes menores do que 12 pontos para telas e 10 pontos para
impressos. Limite o uso de fontes diferentes para textos (at dois
tipos).
Evite fontes muito grandes, que gritam com o usurio. Evite
textos s com maisculas, e no exagere com o sublinhado,
negrito e itlico
5.2.4.1.3 Bordas
A maior parte dos objetos de interao so delimitados por
bordas, que desempenham papel importante na leveza desses
objetos. Essa caracterstica pode ser assegurada atravs da
natureza simples de seus traos e da distncia segura entre as
bordas e textos em geral (denominaes, ttulos, cabealhos,
rtulos, etc. )
5.2.4.1.4 Arranjo ou Layout
O arranjo a forma pela qual os itens de informao esto
dispostos em uma janela, caixa de dilogo ou de mensagem. As
recomendaes principais para um arranjo adequado so as
seguintes:
Defina um grid para o layout das telas. Defina
alinhamentos para os elementos conforme as linhas e
colunas do grid
78
Defina focos de ateno (zonas de trabalho)
agrupando os elementos interrelacionados. Monte uma
estrutura, a partir das relaes (conexes) entre os
elementos e coloque em evidncia o que for mais
importante no grupo... (mais a esquerda, colorido,...)
Distribua da esquerda para a direita em funo da
importncia, da cronologia,..
D equilbrio as telas distribuindo os elementos de
forma balanceada. Evite reas vazias ou altamente
carregada de componentes
Mantenha consistncia entre os layouts das telas.
5.2.4.1.5 Fundos ou Background
Os fundos de telas, janelas, caixas de dilogo ou de
mensagens devem ser definidos com cores neutras
(acromticas), que garantam um contraste adequado com os
textos e rtulos em primeiro plano. recomendvel no carregar
o fundo da tela com elementos grficos (para reas de trabalho e
leitura).
As cores e padres para os fundos podem ser usados para
diferenciar tipos de telas/reas.
5.2.4.2 Formas sonoras
A classe "Forma Sonora" apresenta os atributos de
expresso "timbre", e "freqncia", utilizados para destaque ou
diferenciao do sinal sonoro. O timbre est ligado a natureza da
entidade fsica que gera um som. A mesma nota musical em um
piano ou em clarinete soam diferente devido a seus timbres
particulares. A freqncia tambm denominada registro de um
som, pode ser alta ou baixa relativamente as oitavas. Aconselha-
se a utilizao de tons da mesma oitava para evitar problemas
de construo de sinais sonoros.
79
TERCEIRA PARTE:
O CICLO DA ENGENHARIA DE USABILIDADE
6. Abordagem para a Engenharia de
Usabilidade
O que ainda se verifica em muitos projetos de
desenvolvimento atuais a adoo do famoso mtodo LIXE-SE
2
o usurio. Os sistemas so simplesmente dotados de todas as
funes e informaes possveis e imaginveis e o usurio que
se adapte a ele para alcanar seus objetivos e satisfazer suas
necessidades e expectativas. Em muitos casos, ele est longe
de encontrar algo rpido de aprender, fcil, eficiente de usar ou
mesmo, til em relao a seus objetivos.
Em conseqncia da abordagem citada, as equipes
primeiro concebem e projetam os aspectos internos do sistema
(ligados a seu funcionamento) para depois conceber e projetar
sua interface com o usurio. O contrrio poderia ocorrer quando
do desenvolvimento de um software interativo. Neste tipo de
sistema seria natural esperar que o projeto das interfaces fosse
prioritrio, ocorrendo antes e condicionando as decises sobre o
funcionamento do sistema.
No s o mtodo mencionado, mas uma srie de outros
mtodos populares em engenharia de software, considera o
projeto da interface com o usurio baseado apenas no trabalho
prescrito. As atividades reais, onde se verificam as diferentes
estratgias de operao, em busca da economia ou da
qualidade, as situaes de aprendizado, de resoluo de erros e
incidentes no so consideradas.
Finalmente, o projeto de IHC pensado independente de
seu usurio, e sem que uma anlise de impacto sobre o seu
trabalho seja realizada. Um novo sistema muitas vezes,
entregue e imposto de forma inapelvel. De fato, a nova IHC
pode e deve ser testada pelo usurio, antes mesmo que
qualquer ato concreto de sntese tenha sido realizado. A analise
de situaes de operao com sistemas que se paream com o
sistema futuro vai revelar boas e ms solues, que podem ser
reproduzidas, pois se tem a garantia de que funcionam. Caso se
constate que no funcionam, estas solues sero descartadas e
no se ter gasto tempo e dinheiro em seu desenvolvimento.
Qualquer abordagem para a engenharia de usabilidade,
deve privilegiar o desempenho do usurio em sua tarefa,

2
O nome LIXE-SE uma adaptao bem educada de outra expresso
empregue informalmente pelo professor e pesquisador Silvio Meira (UFPE) ao
provocar uma discusso sobre o projeto de IHC.
80
concebendo sistemas adaptados s suas caractersticas e a
seus objetivos. Para assegurar tais caractersticas necessrio
que o ciclo de desenvolvimento seja centrado no usurio. Isto ,
o envolvimento do usurio deve ser buscado na anlise, na
concepo, no projeto, desenvolvimento, implantao e revises
do sistema.
Alm disso, a abordagem para a engenharia de usabilidade
deve envolver o usurio e equipes multidisciplinares em um
processo iterativo para o desenvolvimento, onde atividades de
projeto e implementao ou prototipagem so seguidas
necessariamente de testes do sistema com o usurio. uma
garantia de que se esteja caminhando no espao aberto do
projeto
De equipes multidisciplinares para o projeto de IHC devem
participar, segundo a norma ISO 13407 (Human-centered design
for interactive system), os seguintes componentes:
Usurios finais
Gerentes/compradores
Especialistas no domnio
Engenheiro de Usabilidade
Engenheiro de software
Pessoal Marketing
Especialistas em ergonomia /fatores humanos
Pessoal de suporte/treinamento
Ainda segundo a ISO 13407 o planejando da funo
Engenharia de Usabilidade envolve as seguintes definies:
Definir as atividades para a funo de Engenharia de
Usabilidade;
Definir as metas e objetivos das atividades da funo
de Engenharia de Usabilidade;
Definir os procedimentos para integrar as atividades
da funo de Engenharia de Usabilidade com as outras
atividades do desenvolvimento do sistema;
Definir os responsveis pelas atividades funo de
Engenharia de Usabilidade, suas competncias,
habilidade e responsabilidades;
Definir as maneiras de fornecer feedback e
documentar as atividades realizadas;
6.1 O envolvimento do usurio no projeto
O envolvimento do usurio pode, se adequadamente
conduzido, trazer importantes benefcios para o projeto, ligados
principalmente a sua qualidade intrnseca e a sua aceitao pelo
pblico-alvo. Esta a forma mais segura de garantir que o
sistema ou produto de software desenvolvido atenda os
requisitos explcitos e implcitos dos usurios, e assim, seja por
eles aceito. Neste tpico so discutidas as formas de
81
envolvimento e a organizao necessria para garantir os bons
resultados da participao do usurio no projeto.
6.1.1 As formas de envolvimento
A equipe de projeto que adota um enfoque centrado no
usurio deve ter em mente os trs tipos bsicos de envolvimento
possveis.
Informativo
Consultivo
Participativo
Assim se pode buscar do usurio as informaes
necessrias para o projeto, atravs de tcnicas de entrevistas,
questionrios ou de sua observao em seu trabalho. Neste tipo
de envolvimento o usurio visto como fonte de informao.
Pode-se tambm levar ao usurio as decises de projeto
para que ele as verifique e emita uma opinio sobre elas. Neste
caso se caracteriza como um envolvimento consultivo; o usurio
consultado sobre decises de projeto. Este envolvimento
tambm pode ser realizado atravs de entrevistas, questionrios
e observao do usurio. Os objetos destas atividades so as
diferentes verses da interface produzidas pela equipe de
projeto. importante salientar que o usurio deve ser consultado
com base no conhecimento que s ele possui sobre sua tarefa.
Ele pode no possuir o conhecimento necessrio para julgar
aspectos tcnicos da usabilidade de objetos de interao, por
exemplo.
O nvel mais elevado de envolvimento ocorre quando o
projetista transfere ao usurio o poder de deciso no projeto.
Aqui so empregadas tcnicas de brainstorming ou de sesses
de arranjo e organizao, nas quais os usurios manifestam a
sua perspectiva sobre determinados aspectos do sistema, como,
por exemplo, a organizao modular ou o vocabulrio da
interface. Cabe ao projetista planejar e realizar estas atividades e
recolher e tratar adequadamente seus resultados. Aplicam-se
aqui as mesmas observaes sobre que tipo de conhecimento
deve amparar as decises do usurio.
importante frisar que o envolvimento com o usurio se d
como uma combinao destes diferentes nveis. Deve-se buscar
informaes junto ao usurio, consulta-lo sobre decises de
projeto e passar a ele o poder de tomar determinadas decises.
Como ser abordado a seguir, esta postura exige uma mudana
organizacional e cultural importante na empresa e na equipe de
projeto.
82
6.1.2 Organizao para o envolvimento do
usurio
O usurio de um sistema informatizado, atravs do qual
realiza suas tarefas cotidianas, alm do proprietrio, a pessoa
que mais conhece o sistema de produo onde ele est inserido.
natural buscar repartir com ele o poder sobre muitas decises
de projeto. Esta abordagem tem sido desenvolvida
principalmente nos pases do norte europeu, onde se tornou
obrigatrio por meio de acordos sindicais.
A palavra de ordem democracia no projeto e para que os
resultados ocorram em toda sua potencialidade, necessrio
que se adote uma postura organizacional diferente. Desde a alta
gerncia, at os membros da equipe de projeto, devem estar
conscientes, preparados e engajados com esta mudana
organizacional. Alm disto, iniciativas importantes devem ser
tomadas para organizar os usurios por meio de uma estrutura
prevendo usurios representantes, especialistas e finais.
O usurio representante a figura central desta
organizao. Ele deve ser escolhido com base no conhecimento
sobre a tarefa e sobre o sistema, mas tambm devido a sua
liderana e comprometimento para com os colegas, usurios
finais do sistema. De modo a poder tomar decises de projeto,
ele deve ser fornecido um treinamento especial para que
compreenda os formalismos e tcnicas de descrio
empregadas no projeto de interfaces. Ele deve assim, poder
avaliar os impactos das alternativas de projeto sobre a tarefa, e
exp-las em uma reunio com os colegas. Para isto, lhe deve
ser assegurada disponibilidade de tempo para consultar colegas
especialistas na tarefa e fornecido o poder de convocar reunies
com os colegas usurios finais do sistema. Estes ltimos em
particular, devem ter o poder de garantir de que as decises
sigam o processo descrito acima. Estes cuidados visam evitar
que o representante dos usurios assuma uma postura
tecnicista, se transformando em mais um projetista, ou ao
contrrio, se tornando seu refm. Neste caso, ele apenas assina
a aprovao de alternativas de projeto que no consegue avaliar
completamente.
As diferentes tcnicas de envolvimento do usurio devem
ser conhecidas e aplicadas da maneira mais adequada etapa
corrente do desenvolvimento da interface humano-computador.
6.2 O ciclo da Engenharia da Usabilidade
A usabilidade desenvolvida atravs de um conjunto de
atividades, que dependendo do paradigma para o ciclo de vida
do produto, podem estar encadeadas de diversas formas: em
cascata, em ciclos de prototipagem e testes, em espirais
evolucionrias ou em diagonais de reutilizao.
83
A pertinncia de um modelo ou outro vai depender do
contexto do desenvolvimento, em particular, do caracter inovador
das propostas, do conhecimento do domnio do sistema, dos
recursos e do tempo disponvel, da experincia de equipe, etc.
Mas seja qual for o modelo escolhido, as atividades necessrias
para o desenvolvimento pertencero a uma das trs categorias
ou perspectivas principais : Anlise, Sntese e Avaliao.
Conforme o paradigma definido, as atividades ligadas a
cada perspectiva estaro mais ou menos entremeadas ou
estanques. Por exemplo, a etapa de anlise pode acontecer uma
84
s vez, para todo o sistema e pemanecer congelada pelo o resto
do ciclo, ou diversas vezes, para cada mdulo ou aplicao e ter
seus resultados revisados a cada ciclo de anlises. O mesmo
ocorre com as atividades do ciclo de testes.
Nos trs captulos que seguem se estar abordando as
atividades pertencentes a cada uma das perspectivas : Anlise,
Sntese e Avaliao.
85
7. A Perspectiva da Anlise
A perspectiva da Anlise se refere ao esforo para
estabelecer uma compreenso de uma realidade ou contexto,
muitas vezes, a partir da sua sub-diviso em sub-sistemas ou
componentes (dividir para simplificar). Para o desenvolvimento
da usabilidade, a anlise no s de uma situao existente, mas
tambm de uma futura, assume importncia maior, uma vez que
por meio destas atividades que se estabelece um foco e um
processo de comunicao e de envolvimento do usurio no
desenvolvimento. Quanto mais frequente e progressivo o
processo de anlise, maior ser a qualidade nas decises de
projeto. Para a usabilidade, a anlise enfoca basicamente os
elementos do contexto de operao de um sistema, envolvendo:
usurio (categorias, perfil, habilidades, necessidades)
tarefa (objetivos, elementos, condicionantes,
estrutura, atributos...)
ambiente fsico, tcnico e organizacional
(equipamento, software, iluminao, rudo, estilo de
chefia, ...)
7.1 Definio do Escopo do Sistema
Todo o trabalho de desenvolvimento de um sistema
informatizado deveria ter origem em uma definio de seu
escopo. Nela so explicitados os principais requisitos funcionais
e no funcionais e as restries sobre seu desempenho,
segurana, equipamentos, etc. O projeto centrado no usurio
deve prever nesta etapa, uma descrio ainda que preliminar do
usurio-alvo ou usurio tpico do sistema e de suas tarefas
principais. Estes descries serviro de baliza para um
aprofundamento no usurio e na tarefa nas etapas subsequentes
do desenvolvimento.
7.2 Anlise do Usurio
Qualquer que seja a abordagem do desenvolvimento, a
primeira coisa a ser realizada a descrio e anlise das
caractersticas da populao-alvo do novo sistema (os atores).
Em um sistema podem existir, e em geral existem, dois tipos de
usurios; as categorias de usurios que so operadores diretos
do sistema, ai incluindo todos os que interagem com ele de
forma mais ou menos assdua, e os indiretos como gerentes,
supervisores, administradores, que so apenas responsveis
pelo sistema. necessrio que as caractersticas das
categorias de usurios diretos do sistema sejam identificadas
com um nvel de detalhamento que permita conhecer:
86
categoria de uso
faixa etria
perfil profissional
freqncia de uso
experincia na tarefa
experincia em tecnologia de informtica
experincia em sistemas similares
motivao
Populaes de usurios jovens vo exigir da interface do
sistema uma aparncia e um comportamento bem diferentes do
que fariam populaes de usurios idosos. O mesmo se verifica
entre pessoas que usam frequentemente ou raramente um
sistema, que tm experincia ou que esto iniciando na tarefa ou
na informtica. Uma interface que serve pessoas que no tm
bons salrios, nem um bom ambiente de trabalho ou perspectiva
de crescimento profissional ser certamente mais solicitada do
que uma que esteja a servio de pessoas motivadas e satisfeitas
em seu trabalho.
O conhecimento destas e outras caractersticas dos
usurios so pertinentes para o processo e devem ser
correlacionados com aspectos de sntese da interface.
7.3 Anlise do Trabalho
A realizao da anlise do trabalho para a especificao de
um novo sistema justificada pela abordagem de conhecer para
modificar. Com a descrio do trabalho atual, o analista pode
avaliar quais so seus problemas efetivos (complexidade,
frequencia, nivel de erros, gargalos) e formas de contorna-los
com funes e operaes do futuro sistema. Esta anlise pode
ser usada tambm para conhecer o trabalho futuro com sistemas
que se assemelham ao novo sistema e testar as novas
propostas, bem antes delas serem sequer projetadas e
implementadas. Isso pode ser conhecido como anlise do
trabalho com o estado-da-arte.
A estrutura do trabalho atual ou do estado-da-arte pode
servir de modelo do novo sistema, podendo ser modificada para
acomodar as novas funcionalidades. Estaria-se assegurando
assim, a compatibilidade entre antigas e novas tarefas e
atividades, fato que sem dvidas, corresponde as expectativas
reais dos usurios. O projeto da interface deve ser derivado de
resultados das anlises realizadas. Por exemplo; as sequncias
identificadas pela decomposio das tarefas atuais podem ser
respeitadas no projeto do dilogo; as classificaes de tarefas
existentes podem ser respeitadas no projeto de menus; a
associao de objetos com aes atuais pode ser respeitada nos
menus pop-up (um painel de menu com as possveis aes para
um objeto); definio de aes e opes default podem ser
87
resultado da anlise da frequncia de uso, sequncia ou
importncia na tarefa.
A estrutura da tarefa pode ser usada tambm para
organizar manuais e tutoriais visando o treinamento inicial do
sistema. Ser uma garantia de que estes recursos estejam
voltados para dar apoio a maneira como as pessoas devem
utilizar o sistema.
O objetivo da Anlise do Trabalho, (AT), segundo uma
viso de usabilidade, de examinar um sistema produtivo a
partir de suas dimenses tarefa e atividade, considerando sua
dinmica e de suas lgicas de utilizao e de funcionamento (ver
captulo 1). Para tanto, a AT prev atividades de coleta de
informao, entrevistas e de observaes em duas etapas de
anlise; anlise das tarefas e anlise das atividades. Uma etapa
de anlise do abiente e de elaborao do relatrio da anlise
encerra estas atividades.
7.3.1 Anlise das Tarefas
Esta etapa realizada por meio da anlise de
documentao e de entevistas com os representantes dos
usurios diretos e indiretos. Estes ltimos tem uma viso
gerencial, muitas vezes terica e abstrata, dos objetivos e dos
mtodos que os operadores devem buscar e empregar em seu
trabalho. Esta viso geralmente formalizada pela empresa
incluindo dados sobre as interligaes e os aspectos econmicos
do sistema. Os operadores, por seu lado, possuem uma
representao prpria de como realizar as tarefas que lhes so
solicitadas. As representaes do trabalho de cada categoria de
usurio, que so o alvo da anlise da tarefa.
7.3.1.1 Entrevistas com gerentes
Nas entrevistas com os gerentes deve-se tentar obter
elementos teis sobre:
representao do sistema; objetivos, procedimentos,
regras de utilizao, restries, etc.;
dados organizacionais: organizao do trabalho,
ligaes entre os servios, quem opera o sistema, quais
os turnos de trabalho;
dados econmicos: custo do sistema, vantagens
proporcionadas (onde e quanto, diretas/indiretas,
prejuzos?).
expecativas de informatizao: vantagens esperadas,
de que ordem? (onde e quanto, diretas/indiretas).
88
7.3.1.2 Entrevistas com usurios
O encontro com o usurio que efetivamente realizam a
operao do sistema ser certamente uma oportunidade de
conhecer mais sobre :
A representao que ele mesmo tem do sistema e de sua
tarefa; objetivos, procedimentos, regras de utilizao,
restries, etc.;
a satisfao e as queixas em relao ao sistema atual;
idias sobre oportunidades para o futuro sistema.
7.3.1.3 Descrio das tarefas
Nesta etapa, parte-se para obter uma descrio sobre a
tarefa a ser realizada nos casos de uso principais, segundo os
pontos de vistas dos atores: usurios e gerentes do sistema.
Com uns e outros, so realizadas entrevistas dirigidas buscando
evidenciar as caractersticas do processo de realizao da tarefa.
Nesta etapa deve-se tentar obter uma descrio detalhando
os elementos do contedo do trabalho, conforme propostos no
tpico 1.4. Sucintamente, descreve-se blocos de tarefas a partir
dos elementos:
Objetivo ltimo a alcanar
Decomposio em sub-tarefas/sub-objetivos;
Relaes entre as sub-tarefas;
Nomes, denominaes e definies das sub-tarefas;
Objetivos a alcanar nas sub-tarefas;
Mtodos que o operador utiliza em cada sub-tarefa
Estados inicial e final do sistema para cada sub-
tarefa;
Pr- e ps-condies das sub-tarefas.
A descrio interna dos blocos deve ser complementada
por uma outra externa, mostrando um estrutura hierrquica de
tarefas em diferentes nveis de abstrao, como a proposta pelo
formalismo M.A.D. (Scapin, 1993). Esta descrio permite que se
tenha uma compreenso geral sobre tarefas que se realizam de
forma simultnea, paralela, seqencial e alternativa. Mostra
tambm tarefas que se desenvolvem de modo repetitivo, as que
so opcionais, as que so prioritrias ou que podem ser
interrompidas. Como visto mais adiante, a descrio destes
elementos ter fundamental importncia para o processo de re-
engenharia do trabalho a ser apoiado pela interface humano-
computador de um futuro sistema.
7.3.2 Anlise do Ambiente
Durante uma visita a realidade do trabalho atual e futura
podem ser coletados dados gerais sobre o contexto de operao
que iro repercutir sobre a sntese de uma interface humano-
computador:
89
layout geral
iluminao
rudo
estado da tecnologia
ferramentas de apoio
A repercuso dos fatores acima mencionados sobre a
sntese da interface se refere, por exemplo, impossibilidade do
emprego de entradas ou sadas sonoras, devido ao nvel de
rudo ambiente.
7.3.3 Anlise das atividades
Nesta etapa so realizadas anlises que visam a validao
das descries e informaes que foram coletadas e que
compem as representaes sobre o trabalho. Para tanto esta
etapa deve prever a realizao de observaes in-loco do
trabalho do usurio. especialmente recomendado que seja
solicitado aos operadores que verbalizem sobre quais os
objetivos, critrios, diagnsticos e razes das decises tomadas.
Pode-se prever meios de registro em vdeo, audio e um bloco de
anotaes para capturar os aspectos citados em trs tipos de
situaes; situao de normalidade, situaes consideradas
crticas e situaes de erros e incidentes. Assim, a viso geral da
tarefa pode ser complementada por um levantamento em termos
das informaes envolvidas com as atividade. Desta forma deve-
se conhecer quais so;
as informaes necessrias e a ordem em que
tornam-se disponveis;
as informaes que so difceis de obter;
as informaes que so inteis (no so utilizadas);
as informaes que so impertinentes (que
atrapalham e induzem a erros de interpretao).
Tambm deve-se obter informao complementar sobre as
atividades;
quais so as mais frequentes
quais so os horrios (durao) e modo de utilizao
quais as deficincias, problemas e incidentes
encontrados. Em particular deve-se identificar suas
causas, condies de aparecimento, frequncia e os
procedimentos para a sua recuperao.
7.3.3.1 Anlise de situaes de normalidade
A anlise de atividades normais feita atravs de
observaes contnuas procurando abranger toda a durao do
trabalho.
Em especial deve-se confrontar a descrio da tarefa
realizada na etapa anterior de anlise com o que realmente
realizado pelo usurio em termos de objetivo ltimo a alcanar,
90
decomposio da atividade em sub-atividades/sub-objetivos,
relaes entre as sub-atividades (sequenciais, paralelas,
alternativas, facultativas, etc).
Deve-se verificar em particular, os graus de dificuldades na
realizao das atividades.
7.3.3.2 Anlise de Situaes Crticas
A partir do que foi levantado na etapa de anlise da tarefa,
algumas situaes podem ser consideradas problemticas ou
crticas e devem ser observadas com maior ateno. A
observao destas situaes se faz ento por amostragem de
perodos escolhidos.
Nelas deve-se confrontar a descrio da tarefa prescrita
com a atividade realizada pelo usurio em termos de mtodos
empregados e do fluxo de informao nesta parte do sistema.
7.3.3.3 Anlise de situaes de Erros e
Incidentes
As situaes de erros e incidentes so de difcil
observao, tanto pela dificuldade de prever sua ocorrncia
como pela dificuldade de seguir seu processo. Recomenda-se
ento que sejam preparadas simulaes, in-loco (no local de
trabalho) ou em laboratrio. Dependendo do sistema, as do
primeiro tipo podem ser dispendiosas para empresa, operador e
analista. Portanto sua realizao deve ser alvo de uma estudo
custo X benefcio cuidadoso. Um outro tipo de simulao poder
ser realizado em um cenrio fora da situao de trabalho. Uma
situao hipottica deve ser apresentada verbalmente ao usurio
que dever descrever os procedimentos para a recuperao da
situao de normalidade.
7.3.4 A elaborao do Relatrio de Anlise
O relatrio de Anlise do Trabalho deve trazer a descrio
detalhada e hierarquizada de tarefa e atividade de seus
operadores. Ele deve prever um diagnstico das situaes
problemticas e as solues possveis baseadas em
recomendaes para a concepo da interface com o usurio do
futuro sistema. Ele pode apresentar a seguinte estrutura:
Identificao de tarefas e usurios;
Descrio/modelagem da estrutura organizacional das
tarefas atuais dos usurios, conforme formalismo
M.A.D.
Anlise das tarefas em termos de: complexidade,
freqncia, nivel de erros, redundncia, gargalos,
mobilidade dos usurios, interrupes
Priorizao dos problemas e gargalos principais
91
7.4 Anlise das possibilidades e restries
tecnolgicas
Esta anlise vai enfocar o ambiente tecnolgico onde a
sntese da interface ser realizada. Em particular so
examinados;
O estilo geral da interface (WIMP, WEB, RV, etc.)
As bibliotecas a serem empregadas na
implementao
As ferramentas de apoio implementao
Uma anlise cuidadosa destes itens pode facilitar em muito
a sntese de interfaces com usabilidade.
92
8. A Perspectiva da Sntese
O processo de sntese de uma interface com o usurio deve
ser fruto de uma sequncia lgica de etapas. Mesmo um
prottipo, a partir do qual a interface evolui, no aparece do
nada, como pretendem os mtodos populares de engenharia de
software. A lgica da perspectiva de sntese (especificao,
projeto e implementao) de uma nova interface com o usurio,
apresenta a seguinte estrutura de atividades:
Especificao do contexto de uso para o qual a
interface estar sendo desenvolvida
Definio da nova estrutura do trabalho com o novo
sistema, resultante da re-engenharia do trabalho atual;
Especificao do desempenho em termos de
usabilidade que a interface deve alcanar (incluindo
especificaes quantitativas e qualitativas);
Elaborao do projeto da interface;
Especificao das regras para o projeto grfico para a
interface;
8.1.1 Especificao do Contexto de Uso
O primeiro passo na perspectiva de sntese tornar
explcito, a todos envolvidos no projeto, para qual contexto de
uso a interface do sistema estar sendo desenvolvida. A norma
ISO 9241:11 fornece um bom apoio a esta tarefa ao definir os
componentes de um contexto de uso os usurios: os usurios,
suas tarefas com o sistema, o equipamento (hardware, software
e documentos) e os aspectos do ambiente fsico, social e
organizacional, suscetveis de influenciar a usabilidade de um
produto dentro de um sistema de trabalho. Esta especificao ir
balizar todo o desenvolvimento e em especial, a montagem das
condies nas quais os testes de usabilidade do sistema sero
realizados. Ao realizar esta especificao, o analista de
usabilidade tem a oportunidade de realizar as primeiras
definies referentes aos estilos, componentes e processos da
futura interface.
8.1.2 Definio da nova estrutura do trabalho
Para poder especificar a estrutura da futura tarefa
(componente do contexto de uso) necessrio um processo de
(re)engenharia do trabalho seja realizado.
A decises sobre quem faz o qu, devem ser baseadas nas
caractersticas cognitivas dos dois agentes envolvidos no
sistema. Em relao ao ser humano, sabe-se que o computador
apresenta enormes vantagens sob o ponto de vista de
velocidade e preciso de tratamentos lgicos formais e
93
algortmicos, alm da capacidade superior de estocar e
sincronizar a informao no tempo. Por outro lado, as pessoas
so melhores para reconhecerem padres de comportamento,
realizar julgamentos, de abstrair e de generalizar no processo de
tomada de deciso.
De qualquer forma, as tarefas que resultem para o usurio
devem ter significado como um todo, e no ser apenas o que
sobrou para ele, depois do que foi alocado para a mquina.
Outro aspecto importante nessa etapa da concepo se
refere ao controle das atividades e ao grau de automatizao
que possa ser conferido execuo da tarefa interativa. Nesse
sentido importante ressaltar a relao inversamente
proporcional entre a alienao do processo e a capacidade do
operador humano de decidir sobre ele. Tambm importante
considerar a necessidade de flexibilidade na realizao da tarefa
de controle.
A atividade de re-engenharia do trabalho tem com ponto de
partida o Relatrio de Anlise do Trabalho, conforme descrito no
tpico 7.3.4, desta apostila. Deste relatrio recupera-se os
seguintes elementos:
Descrio da estrutura do trabalho com o sistema
atual, segundo o formalismo M.A.D ;
Identificao dos problemas e gargalos na estrutura
do trabalho atual;
Priorizao dos problemas e gargalos principais (os
mais freqentes e os mais crticos)
A partir destas informaes, o processo de re-engenharia
se desenvolveria, de forma a envolver o usurio nas seguintes
atividades:
Definir para cada tarefa problemtica, diversas
maneiras diferentes para sua realizao;
Priorizar estas maneiras conforme desejo do usurio
e viabilidade tcnica, definida pelos projetistas
Definir uma nova estrutura da tarefa que represente
maneiras desejadas e viveis para sua realizao;
8.1.3 Especificao da usabilidade esperada
A interface com o usurio comea a ser concebida na
especificao da usabilidade que se pretende alcanar com o
novo sistema. Isto deve ser feito de duas: quantitava e
qualitativamente.
A especificao quantitiva da usabilidade se refere aos
aspectos da qualidade em uso ou de aceitao de um sistema.
Segundo prope a norma ISO 9241:11, para um determinado
contexto de operao, eles so os seguintes:
Eficcia
Eficincia
94
Satisfao
Na medida em que os resultados de testes de aceitao de
usabilidade para diversos sistemas tenham sido registrados, a
especificao do nvel de usabilidade poderia ser feita em termos
relativos. Para o sistema em desenvolvimento, espera-se que o
nvel de usabilidade esteja acima do verificado para o sistema
atual.
A anlise do contexto de operao do novo sistema permite
que se especifique que tipo de usabilidade deve ser construda.
Uma boa ferramenta para esta especificao qualitativa so os
critrios ergonmicos definidos por Bastien & Scapin (1993) e
apresntados no captulo 4 desta apostila. Por exemplo, se os
usurios forem sempre novatos, a conduo uma qualidade
importante para as interfaces. Se eles forem se tornar
especialistas, a diminuio da carga de trabalho pode lhes ajudar
bastante em suas atividades. Se ambos os tipos de usurios
coexistirem, a felxibilidade da interface ser importante. Caso as
tarefas apoiadas sejam de grande responsabilidade, a gesto de
erros ir certamente ajudar em muito aos usurios.
8.1.4 O Projeto da Interface
As atividades de projeto da interface com o usurio visam
definir formas de apoiar a realizao da futura estrutura de
trabalho no contexto de uso definido para o sistema do sistema,
relacionado com os tipos de usurio, as suas tarefas e o seu
ambiente tcnico, organizacional e social. Mais especificamente,
nesta etapa, o projetista realiza um detalhamento da
especificao do contexto de uso, processo no qual so
definidas as diferentes caractersticas das Interfaces Humano-
Computador. Dentre as diversas abordagens para o projeto de
IHC so apresentadas aqui duas bem conhecidas; a abordagem
The Bridge, proposta por Tom Dayton e seus colegas da
Bellcore (1996) e a abordagem Usage-Centered Design
proposta por Cnstantine em seu livro Software for Use (1999).
8.1.4.1 The Bridge - Projeto de IHC orientado
objetos.
Tom Dayton e seus colegas da Bellcore propuseram uma
abordagem para o projeto de IHC, a partir de sua longa
experincia no envolvimento de usurios neste tipo de atividade.
A abordagem, chamada The Bridge (Dayton, McFarland &
Kramer, 1996) est baseada em uma seqncia de sesses de
projeto participativo, envolvendo usurios, engenheiros de
usabilidade, engenheiros de software, programadores, que
trabalham apenas com lpis, papel, cartes colantes e desenhos
pr-impressos de janelas para juntos, construrem uma ponte
(The Bridge) entre os requisitos dos usurios e da organizao e
95
o projeto de uma interface que apoie estes requisitos. A ponte
possui trs passagens principais:
Parte 1 Expressar requisitos do usurio em termos de
um Fluxo de Tarefas
Parte 2 Mapear os Fluxos da Tarefa em Objetos da
Tarefa
Parte 3 Mapear Objetos da Tarefa em Objetos de
Interfaces
8.1.4.1.1 Parte 1 Fluxo de Tarefas
Nesta primeira etapa da abordagem, os projetistas e
usurios realizam a definio de um (novo) fluxo de trabalho a
ser executado pelo usurio com o novo sistema. Este descrito
por um fluxograma apresentando blocos para o incio, para os
processos e decises, assim como para o resultado esperado do
trabalho. As descries nos blocos devem conter nomes,
associados a objetos e atributos manipulados pelos usurios e
verbos, associados as aes realizadas pelos usurios sobre
estes objetos. Na figura a seguir apresentado um exemplo de
fluxo de tarefa para o trabalho de check in em um hotel.
.
Muito frequentemente, nesta etapa se faz a re-engenharia
do fluxo de trabalho dos usurios de um sistema atual, j
existente, conforme os passos apresentados no tpico 8.1.2
desta apostila, sobre a definio de uma nova estrutura do
trabalho:
8.1.4.1.2 Parte 2 Mapear Fluxo da Tarefa em Objetos de Tarefa
Uma vez validados, os fluxos de tarefa so em seguida,
analisados visando a definio de classes de Objetos de Tarefa.
Estes, so definidos como unidades discretas de informao
com as quais os usurios realizam a sua tarefa. Via de regra,
correspondem a janelas, caixas de dilogo e caixas de
mensagens vistas como as entidades de dados e funes de que
os usurios necessitam para realizar suas tarefas. O processo de
Incio
Hspede solicita
a realizao de
Check In
Atendente
Solicita o
sobrenome do
Hspede
Atendente
Encontra a
reserva do
usurio
Atendente faz o
check In
(escolhe um
quarto)
Resultado
Hspede ocupa
um quarto
96
definio de classe de objetos de tarefa est associado ao
contedos das caixas que compem sua representao:
Caixa de identificao da classe. Esta definio se d,
comumente, a partir dos substantivos nas descries dos
fluxos de tarefas;
Caixas de propriedades: seu contedo definido a
partir dos substantivos qualificadores que aparecem nas
descrio de processos do fluxo de tarefas. As
propriedades de uma classe de objetos podem ser de dois
tipos: atributos da classe propriamente ditos, como nome
e endereo de uma classe Hotel por exemplo, e seus
componentes, que so outras classes de objetos que nela
esto contidas, como por exemplo, a classe Quarto.
Atributos e composies sero tratados de diferentes
formas no mapeamento em objetos de interface (etapa
seguinte).;
Caixa das aes: Representam as aes que os
usurios podem realizar sobre estes objetos, usando-os
para realizar suas tarefas. Correspondem comumente aos
verbos que aparecem nas descries dos fluxos de
tarefas.
Caixa das relaes de agregao entre objetos: Esta
definio visa distinguir composies das quais uma
classe faz parte e as classes de componentes que dela
fazem parte. A composio de mais alto nvel o Desktop
no ambientes windows.
Algumas regras aplicveis as definies de classes de
objetos so listadas abaixo:
HOTEL
Coleo de
quartos para
alugar aos
hspede
Atributos Componentes
Nome Quartos
Layout Hspedes
Quartos livres
Ver
Editar
Salvar Imprimir
Estou em Possuo
Desktop Quarto
Hspede
Identificao
Propriedades
Aes
Relaes de Agregao
97
Se o conhecimento do usurio sobre o domnio da
aplicao associa unidades de dados a objetos ento
torne-os objetos. Ex; Catlogo telefnico;
Se um usurio s vezes quer ver apenas poucos dos
atributos de uma unidade, e as vezes quer v-los todos,
ento a unidade pode ser um objeto e ser apresentado na
interface, ora fechado (como um item de uma lista) e
aberto (como uma janela);
Um carto de objetos sem atributos indica que ele se
refere a um atributo de outro objeto;
Se existem diversas instncias de uma unidade de
dado, e especialmente, o nmero de instncias que
possam existir desconhecido, mas pode ser grande,
ento esta unidade de dado pode ser um objeto;
Se os usurios querem criar, excluir, mover e copiar a
unidade de informao, ele esta tratando-a como faria
com um objeto fsico, ento a unidade pode ser um
objeto;
Com o conjunto de classes de objetos de tarefa definidos, j
possvel testar sua utilidade para o usurio, face os fluxos de
tarefa definidos para o projeto.
8.1.4.1.3 Parte 3 Mapear Objetos da Tarefa em Objetos de Interfaces
Na terceira e ltima etapa da abordagem The Bridge, os
projetistas mapeiam as composies de objetos de tarefa e seus
atributos em composies e atributos de objetos grficos de
interfaces com o usurio. Um especialista em estilo de
usabilidade deve participar das sesses de trabalho para ajudar
nas seguintes tomadas de deciso:
Qual objeto de interface associar a um objeto de
tarefa? Na maioria dos casos, os objetos de tarefa so
mapeados como janelas grficas, primrias e
secundrias, recebendo como identificao o contedo da
caixa de identificao do objeto de tarefa.
Como apresentar as propriedades dos objetos de
tarefa (componentes e atributos) nos objetos de interface?
Elas so apresentadas nas reas cliente das janelas de
que fazem parte, de diferentes maneiras (nmeros, textos,
imagens, cones, etc ),.
Quais os comados para os objetos de interface? As
opes de menu e os grupos de botes de comando das
janelas so definidos a partir das caixas de aes dos
objetos de tarefa. Nesta etapa, os projetistas definem e
prototipam a parte principal das janelas que apoia os
comandos mais relevantes face as vistas apresentadas.
Os autores da abordagem The Bridge propem que
detalhamentos maiores, envolvendo opes de menu, teclas
98
aceleradoras, mnemnicos, bolhas de ajuda, etc, sejam deixados
para sesses das quais no participem os usurios. Segundo
eles, estas sesses no so meios eficientes para definies
detalhadas.
Os prottipos dos objetos de interface definidos nesta
etapa, devem ter sua usabilidade testada pelos usurios
participantes das sesses de projeto.
8.1.4.2 Usage-Centered Design (Constantine,
1999)
A abordagem para o projeto de IHC proposta por
Constantine baseada em trs tipos de modelagens:
Usurios e categorias relacionadas
Estruturas de trabalho
Arquitetura da Interface
As arquiteturas de interface so evidentemente projetadas
para satisfazer tipos especficos de usurios e estruturas de
trabalho projetadas.
8.1.4.2.1 Usurios e categorias relacionadas
As categorias a serem consideradas como fonte de
informao visando uma modelagem do usurio incluem:
Usurios finais
Consumidores e gerentes
Especialistas no domnio, pessoal de treinamento,
supervisores
Informantes e interpretes pessoal de marketing,
vendas, apoio tcnico, documentalistas
Outras fontes de requisitos indiretas para a modelagem do
usurio incluem manuais, questionrios, e qualquer outra forma
de informao disponvel nas empresas.
A principal componente do modelo de usurios o Papel de
Usurio, definido como um conjunto abstrato de necessidades,
interesses, expectativas, comportamentos e responsabilidades,
caracterizando um relacionamento entre classes ou tipos de
usurios e o sistema. Trata-se de uma abstrao que
desempenhada por usurios que assumem um relacionamento
com o sistema, como administradores, operadores,
supervisores, alunos, professores, tutores etc..
Fundamentalmente, estas categorias de usurios tem acesso a
diferentes conjuntos de funes e informaes do sistema, o que
deve ser documentado no incio do projeto. Os papis podem ser
desempenhados por mais de um usurio e um nico usurio
pode assumir mais de papel. Um modelo de papis apresenta
uma lista ou um mapa estruturado com todos os papis definidos
99
para um sistema. Um mapa de papis interrelaciona papis
segundo uma hierarquia de classes de papis.
Os papis mais importantes sob o ponto de vista de
quantidade de usurios ou de sua responsabilidade frente a
negcios, por exemplo, devem ser identificados e definidos como
Papis Focais. Sobre eles se concentrar ateno especial no
decorrer do projeto.
8.1.4.2.2 Estruturas de Trabalho
Para entender os componentes da abordagem de
Constantine para modelagem de estruturas de trabalho,
necessrio esclarecer alguns conceitos-chave, em particular
Cenrios, Casos de Uso e Casos de Uso Essenciais
Constantine define cenrio como uma descrio concreta e
detalhada de uma seqncia particular de eventos em uma
situao especfica, que se pretenda representativa de um tipo
mais geral de interao. De maneira similar, Nilesen define
cenrio como descrio auto-contida de um usurio individual
interagindo com um subconjunto especfico de facilidades do
sistema para alcanar resultados especficos sob condies
especficas e dentro de um certo intervalo de tempo.
Para Constantine, um caso de uso uma descrio
narrativa da interao entre um usurio, institudo de algum
papel, e alguma parte do sistema. Em OO, os casos de uso
podem se referir tambm a interaes entre sistemas e
equipamentos, mas para o projeto de IHC s interessem os
envolvendo usurios e o sistema. Eles descrevem vises
externas de alguma funcionalidade fornecida pelo sistema e que
aparece como uma caixa-preta.
Os casos de uso so parte da especificao de requisitos
de um sistema e diferem dos cenrios, no sentido em que so
abstraes de padres gerais, extrados de exemplos
especficos. Um exemplo de caso de uso mostrado a seguir.
Pegando Dinheiro
AES DO USURIO RESPOSTA DO SISTEMA
---------------------------------------------------------------------------------------
insere o carto
l o carto
solicita ID
entra ID
verifica ID
mostra menu de transaes
pressiona tecla
mostra menu da conta
pressiona tecla
solicita montante
entra montante
100
mostra montante
pressiona tecla
devolve o carto
pega o carto
entrega o dinheiro
pega o dinheiro
---------------------------------------------------------------------------------------
Constantine prope modelar o trabalho a partir de Casos de
Uso Essenciais, definidos como uma narrativa estruturada,
expressa em termos de linguagem do domnio da aplicao e do
usurio, compreendendo uma descrio simplificada,
generalizada, abstrada e livre de detalhes de tecnologia e de
implementao, de uma tarefa ou de uma interao bem
definida, do ponto de vista dos usurios em algum papel ou
papis face o sistema, e que incorpora os objetivos ou intenes
subjacentes interao. Um exemplo de caso de uso essencial
mostrado a seguir.
Pegando Dinheiro
INTENES DO USURIO RESPONSABILIDADES DO
SISTEMA
---------------------------------------------------------------------------------------
Identificar-se
Verificar a identificao
Oferecer opes
escolher
fornecer o dinheiro
pegar o dinheiro
---------------------------------------------------------------------------------------
A modelagem do trabalho com o futuro sistema se refere a
identificar e descrever estes casos de uso essenciais e de
elaborar uma viso estruturada dos inter-relacionamentos
observados entre eles, em Mapa de Casos de Uso.
Um Mapa de casos de uso a repartio da funcionalidade
total do sistema em colees de casos de uso ligadas por
relaes de especializao, extenso, composio e afinidade.
Um uma Especializao, os casos de uso so tipos de
outros. Observe o exemplo onde retirarDinheiro ou
DepositarDinheiro so tipos da interao UsarMaquina.
Usando Mquina
Retirando Dinheiro Depositando Dinheiro Verificando Estatus
Especializa
Verificando Saldo
Especializa
101
Por uma relao de Extenso, um caso de uso estende um
outro bsico, que passa a apresentar padres inseridos ou
substitudos. Veja o exemplo no qual Alterando Imagem
estendido pelo caso de uso Browsing Imagem.
Alterando Imagem
INTENES DO USURIO RESPONSABILIDADES DO
SISTEMA
---------------------------------------------------------------------------------------
Solicita Alterao
Mostra imagens apropriadas
Seleciona Imagem
Mostra Preview
Confirma
Fecha
---------------------------------------------------------------------------------------
O caso de uso Browsing Imagens poderia ser til em
situaes onde os arquivos disponveis no sejam os que o
usurio quer. Empregando a extenso de caso de uso Browsing
Imagens, a narrao do caso de uso bsico (Alterando Imagem)
permaneceria simples.
Na relao de Composio uma interao representada
pelo super caso realizada empregando as interaes definidas
dentro de sub casos de uso. No exemplo que segue, o super
caso de uso Iniciando Login formado a partir de Autorizando
Acesso e Entrando Parmetros.
A relao de Afinidade serve para as muitas situaes nas
quais conjuntos de casos de uso mantm relaes, no muito
bem definidas, com outros casos de uso.
Browsing Imagens
Alterando Imagens
estende
Autorizando Acesso
Iniciando Login
emprega
Entrando Parmetros
parece
Retirando dinheiro
Depositando fundos
Verificar Status
Transferindo fundos
102
Afinidade representa relaes evidentes, porm ambguas e
no muito claras, de similaridade entre casos de uso. Elas so
especialmente teis nas fases iniciais de projeto e nos
diagramas, as classe com afinidades aparecem levemente
sobrepostas, ligadas por linhas tracejadas. Em contraposio a
classes que no se assemelham aparecem distanciadas no
diagrama de caso de uso.
Antes de encerrar o diagrama de casos de uso,
necessrio indicar um ou mais casos de uso focais, que so o
foco da ateno ao redor dos quais a interface ou algum parte
sua, ser organizada. Os casos de uso focais para o sistema
como um todo, incorpora os casos de usos mais importantes,
centrais e representativos para seu usurio. Eles so
representados nos diagramas de casos de uso como elipses com
bordas duplas.
8.1.4.2.3 Arquitetura da Interface
A definio de uma arquitetura da interface capaz de apoiar
usurios e os casos de uso definidos at agora no projeto feita
pela elaborao de dois modelos.
Modelo de Contedo da Interface
Mapa de navegao entre contextos
8.1.4.2.3.1 Modelo de Contedo da Interface
As pessoas realizam tarefas em uma srie de contextos
interconectados e especialmente montados com as ferramentas
e materiais necessrios. Boas interfaces so organizadas de
modo a fornecer todos os contextos de interao, de que o
usurio necessita. Os contedos de contextos de interao so
ferramentas, materiais e os espaos necessrios para mante-los,
assim, o modelo de contedo de uma interface uma
apresentao interna, de contedos de vrios contextos de
interao e externa, das interconexes entre os contextos.
O modelo de contexto deriva do modelo de casos de uso,
pela regra geral de que cada caso de uso ser apoiado por um
prprio contexto de interao. Os componentes abstratos dos
modelos de contedo so ferramentas abstratas, que fornecem
as funes e os materiais abstratos, que fornecem os dados, os
componentes de dados, as apresentaes, e as reas de
trabalho sobre as quais as ferramentas devem ser operadas.
O processo de modelagem do contedo inicia-se pela
analise das narrativas validadas de casos de uso, linha por linha,
de modo a identificar quais ferramentas e materiais tero que ser
103
fornecidos de forma a que o usurio seja capaz de realizar a
interao. Neste processo, inicialmente so definidos os
materiais necessrios. Na seqncia, os casos de uso essenciais
so revistos em busca das ferramentas e operaes
necessrias. Os materiais e as ferramentas identificados so
listados no modelo de contedo do espao de interao. Uma
descrio de sua forma e comportamento pode ser adicionada,
como forma de avanar sobre decises do modelo de
implementao. Estes j podem ser agrupados de modo a refletir
o modo como eles devem provavelmente ser usados ou faam
mais sentido ao usurio. As ferramentas devem ser agrupadas
parte, sugerindo uma barra de ferramentas, por exemplo.
Segundo Constantine, no necessrio, nem prtico tentar
definir solues de layout usando o modelo de contedo. Isto
ser feito mais adiante, por meio do modelo de implementao.
Cada espao abstrato de interao ir se tornar uma tela,
janela ou caixa de dilogo que precisa ser entendida pelo usurio
e cada mudana de contexto deve corresponder uma mudana
de pensamento no usurio.
8.1.4.2.3.2 Mapa de navegao entre contextos
Um mapa de navegao na verdade, um diagrama de
transio de estados, onde os espaos de interao so
representados por retngulos e as transies so representadas
por flechas conectando espaos.
Os mapas de navegao explicitam um dos mais
importantes compromissos no projeto da arquitetura da interface
com o usurio, que envolve a deciso entre limitar o contedo de
cada espao de interao mantendo-os pequenos e simples, ou
limitar o nmero deles, aumentando a complexidade de cada um.
A primeira soluo pode ser aparentemente boa para usurios
novatos, mas pode aborrecer usurios experientes impondo-lhes
excessivas transies entre espaos de interao. A segunda
pode favorecer usurios experimentados, mas sobrecarregar
usurios novatos.
Caixa de dilogo ou de mensagem,
ou qualquer contexto de interao
Tela ou Janela
Pginas de informao
104
8.2 Consideraes sobre o Projeto de IHC
At a algum tempo atrs, as abordagens para o
desenvolvimento de IHC eram se baseados em ciclos de
prototipagens rpidas e testes com o usurio. Esta estratgia,
apesar de vlida, no explicitava o processo pelo qual os
prottipos eram gerados. Afinal, como surgem os prottipos?
Vale a pena gastar tempo e recursos fazendo o projeto de uma
interface (como os descritos aqui) antes de prototip-la?
Como ficou registrado em diversos comentrios durante a
descrio do processo de projeto de IHC, ele permite que se
avaliem as alternativas de maneira precoce e isolada. possvel
avaliar a intuitividade e a carga de trabalho de interaes, sem
que qualquer desenho ou implementao tenha sido feita. O
mesmo ocorre com a densidade informacional de telas das quais
se sabe apenas a lista de componentes. Cada verso do projeto
apresenta por outro lado, uma natureza especfica, que pode ser
avaliada isoladamente. O mesmo no ocorre com prottipos, em
cuja avaliao aparecem solues resultantes de diversos
projetos (dos fluxos de tarefas, dos objetos de tarefas e dos
objetos de interao e dos caminhos da interface) reunidas em
uma coisa s.
evidente que o tempo e os recursos necessrios para
realizar este projeto so argumentos a favor de uma
prototipagem pura e simples. Ainda mais se possvel partir da
algo que j exista e que seja parecido com o que se quer para a
futura interface. Mas, a exemplo do ncleo funcional, a interface
com o usurio merece ter seu processo de projetao
documentado, mesmo que este envolva solues reutilizveis. O
gasto de tempo e recursos pode ser bastante diminudo na
medida em que um ambiente informatizado venha a apoiar este
processo, propondo editores, bibliotecas de diversos nveis de
componentes orientadas a objetos e a reutilizao.
Por outro lado, o projeto de interfaces humano-computador
deve ser apoiado por regras de mapeamento e configurao de
objetos de interao compiladas em guias de recomendaes e
de estilo. Enquanto o primeiro refere-se a solues para
componentes e contexto de operao abstratos ou gerais, um
guia de estilo trs propostas de solues mais concretas para
uma interface de um determinado tipo e em um ambiente
tecnolgico definido. O guia de recomendaes abordar
formulrios de diversos tipos, sem se prender a um em particular
ou a uma plataforma especfica. Um guia de estilo mostrar
como construir formulrios combinados com tabelas e mquinas
de busca na plataforma JAVA, por exemplo, uma vez que estes
so o tipo de aplicao e a tecnologia da empresa. O captulo 5,
sobre componentes de interface, representa um guia de
recomendaes til como conhecimento de base para qualquer
projeto. Para apoiar o projeto grfico, especificamente,
105
recomenda-se a leitura dos itens 5.2.4 sobre as primitivas grfica
a serem usadas no projeto de IHC. So elas:
cones
Fontes
Textos
Layout
Cores
Backgrounds
Finalmente, importante salientar que as etapas de
definies dos elementos do projeto de uma interface em
qualquer abordagem, podem ser realizadas segundo duas
sequncias diferentes.
Largura primeiro, pela qual se esgota cada etapa de
definies completamente, antes de passar prxima.
So definidas todos os fluxos de tarefas, depois todos os
objetos de tarefa, depois todos os objetos de interao.
Profundidade primeiro, pela qual so realizadas todas
as etapas de definio dos elementos de uma
determinada tarefa. So definidas os fluxos, objetos de
tarefa e os objetos de interao associados apenas a uma
parte da estrutura de interaes. Depois so definidos os
elementos de uma outra parte da estrutura, e assim por
diante.
106
9. A Perspectiva da Avaliao
A usabilidade definida pela norma ISO 9241 como a
capacidade que apresenta um sistema interativo de ser operado,
de maneira eficaz, eficiente e agradvel, em um determinado
contexto de operao, para a realizao das tarefas de seus
usurios.
Assim, a avaliao de usabilidade de um sistema interativo
tem como objetivos gerais (i) validar a eficcia da interao
humano-computador face a efetiva realizao das tarefas por
parte dos usurios, (ii) verificar a eficincia desta interao, face
os recursos empregados (tempo, quantidade de incidentes,
passos desnecessrios, busca de ajuda, etc.)e (iii) obter indcios
da satisfao ou insatisfao (efeito subjetivo) que ela possa
trazer ao usurio. Estes objetivos devem ser pensados em
relao aos diferentes contextos de operao previstos para o
sistema.
A usabilidade de um sistema est sempre associada as
caractersticas de determinados tipos de usurios, tarefas,
equipamentos e ambientes fsicos e organizacionais. Assim, um
problema de usabilidade pode se fazer sentir fortemente em
determinados contextos de operao e ser menor ou mesmo
imperceptvel, em outros.
9.1 Problema de usabilidade
Um problema de usabilidade ocorre em determinadas
circunstncias, quando determinada caracterstica do sistema
interativo, acaba por retardar, prejudicar ou mesmo inviabilizar a
realizao de uma tarefa, aborrecendo, constrangendo ou at
traumatizando a pessoa que usa o sistema interativo. Deste
modo, um problema de usabilidade se revela durante a
interao, atrapalhando o usurio e a realizao de sua tarefa,
mas tem sua origem em decises de projeto equivocadas.
Conforme os termos da definio acima proposta, um
problema de usabilidade deve ser descrito a partir de
informaes sobre:
o contexto de operao onde o problema pode ser
encontrado,
os efeitos possveis sobre o usurio e sua tarefa, a
incluindo a freqncia com que este problema/contexto se
manifesta.
9.1.1 Contexto de um problema de usabilidade
O contexto de um problema de usabilidade caracterizado
por determinados tipos de usurios, realizando determinadas
tarefas, com determinados equipamentos e em determinados
107
ambientes fsicos ou organizacionais, para os quais a usabilidade
do sistema diminuda.
Para efeito do raciocnio sobre usabilidade, as
caractersticas do sistema devem ser examinadas sem perder a
perspectiva de que usurios mais velhos esto sujeitos a
problemas de acuidade visual e de controle manual e que uma
porcentagem considervel dos homens esto sujeitos a cegueira
s cores (principalmente o verde e o vermelho). importante
tambm considerar as dificuldades que tero na realizao da
tarefa informatizada as pessoas em formao profissional (na
prpria tarefa), as novatas na informtica, ou as que se valem do
sistema de forma eventual. Com o mesmo objetivo interessa
saber que equipamentos em mau estado de conservao,
podem diminuir a legibilidade das apresentaes e induzir
acionamentos involuntrios, por exemplo. Interessa tambm
saber que a presso temporal pode induzir o usurio a erros em
tarefas complexas e mal estruturadas, e que este ser sempre
uma espcie novato na realizao de tarefas espordicas.
9.1.2 Efeitos de um problema de usabilidade
Os efeitos de um problema de usabilidade se fazem sentir
diretamente sobre o usurio e indiretamente sobre sua tarefa.
Assim, por exemplo, efeitos sobre o usurio como uma
sobrecarga perceptiva (dificuldade de leitura), cognitiva
(desorientao ou hesitao) ou fsica, (dificuldade de
acionamento) podem levar a efeitos sobre sua tarefa como perda
de tempo, falhas ou perda de dados.
9.1.3 A descrio de um problema de usabilidade
Com base no que foi exposto acima prope-se um formato
para a descrio de um problema de usabilidade, como o
apresentado no exemplo que segue:
Identificao do problema: cones pequenos;
Descrio: Os cones que rotulam os botes de comando
que participam da barra de ferramentas so muito
pequenos.
Tipo de usurio considerado: pessoas com problemas de
acuidade visual e de coordenao motora
Tipo de equipamento considerado: em mau estado de
conservao
Tipo de tarefa considerado freqente;
Efeito sobre o usurio: dificuldade de leitura /sobrecarga
motora/acionamentos involuntrios
Efeito sobre a tarefa: perda de tempo e sobre-carga de
trabalho do usurio para acionar uma opo devido a
necessidade de maior preciso no movimento com o mouse
108
Sugesto de melhoria: Aumentar a rea de apresentao
dos cones e a rea sensvel dos botes icnicos.
Cabe ressaltar que nesta proposta de formato, os
problemas de usabilidade sero identificados por sua origem no
projeto da interface, e no por suas conseqncias durante a
interao.
9.1.4 Tipos de problemas de usabilidade
Com base em algumas combinaes entre a natureza do
problema, o tipo de usurio que ele prejudica e seus efeitos
sobre a usabilidade das funes do sistema, pode-se propor o
seguinte sistema de classificao:
Uma anlise da natureza de um problema de usabilidade
permite classific-lo como uma barreira, um obstculo ou um
rudo.
Barreira: se refere a um aspecto da interface no qual
o usurio esbarra sucessivas vezes e no aprende a
suplant-lo. Uma barreira voltar a se apresentar ao
usurio na prxima realizao da tarefa, comprometendo
fortemente seu desempenho e fazendo com que ele
desista de usar uma funo do sistema. A presena de
barreiras na interface implica em prejuzos definitivos, que
dependendo da tarefa e usurio, podem inviabilizar
economicamente o sistema.
Obstculo: se refere a um aspecto da interface no
qual o usurio esbarra e aprende a suplant-lo. Em
funo do obstculo, as prximas realizaes da tarefa se
daro custa de uma perda de desempenho. A presena
de um obstculo implica na acumulao de prejuzos para
os que operam e para os que adquiriram o sistema;
Rudo: se refere a um aspecto da interface que, sem
se consistir em barreira ou obstculo ao usurio, causa
uma diminuio de seu desempenho na tarefa. Em funo
de rudos na interao o usurio pode desenvolver uma
m impresso do sistema (aspecto subjetivo);
A partir do tipo de tarefa em que ele se manifesta, o
problema de usabilidade pode ser classificado como principal ou
secundrio.
Principal: um aspecto da interface que compromete a
realizao de tarefas freqentes ou importantes.
Secundrio: um aspecto da interface compromete a
realizao de tarefas pouco freqentes ou pouco
importantes.
109
Com base no tipo de usurio que afeta, um problema de
usabilidade pode ser classificado como geral, inicial, definitivo e
especial.
Geral: um aspecto da interface que atrapalha
qualquer tipo de usurio durante a realizao de sua
tarefa.
De iniciao: um aspecto da interface que atrapalha o
usurio novato ou intermitente durante a realizao de
sua tarefa.
Avanado: um aspecto da interface que atrapalha o
usurio especialista durante a realizao de sua tarefa;
Especial: um aspecto da interface que atrapalha tipos
de usurios especiais (portadores de deficincia) durante
a realizao de sua tarefa, mas que os outros so
capazes de suplantar, sem prejuzos para sua tarefa.
importante citar a existncia de duas categorias de
problemas, ortogonais em relao ao sistema de classificao
proposto, que salientam os possveis efeitos de uma reviso de
projeto equivocada. Elas se referem ao falso e ao novo problema
de usabilidade.
Falso: refere-se a um aspecto da interface que,
apesar de classificado como problema, na realidade no
traz qualquer prejuzo ao usurio, nem a sua tarefa. Trata-
se de um engano provocado pela falta de experincia do
avaliador ou de uma deficincia em sua ferramenta de
avaliao;
Novo: um aspecto da interface que representa um
obstculo, devido a uma reviso de usabilidade
equivocada;
A anlise de causas e efeitos de um problema de
usabilidade permite algumas concluses sobre a severidade
deste tipo de problema. Por exemplo, um problema verificvel
para qualquer tipo de usurio , logicamente, mais prioritrio que
um outro que se verifique somente para alguns tipos de usurios
(usurio novato na operao, novato na tarefa, c/ problemas
visuais, com idade avanada, etc.). Por seu lado, pode-se
considerar tambm prioritrio o problema de usabilidade que
possa causar perda de tempo em tarefas com elevada
freqncia de realizao ou o que cause falhas ou perda de
dados em tarefas de elevada importncia.
9.2 Objetivos de uma avaliao de usabilidade
As atividades ligadas a esta perspecitva do ciclo de
engenharia de usabilidade visam identificar, seja por prospeco,
diagnstico ou observao, os problemas de usabilidade em
interfaces humano-computador e contribuir para a sua
110
eliminao. Assim, no desenvolvimento de sistema interativo, um
engenheiro-avaliador de usabilidade ter como primeira tarefa a
elaborao de um Plano de Testes de Usabilidade, no qual
propor a realizao de uma sequncia estrutrada de avaliaes
de usabilidade, uma para cada verso do sistema. Entre os
objetivos a serem atingidos, constam pelas avaliaes constam:
constatar, observar e registrar, problemas efetivos de
usabilidade durante a interao;
calcular mtricas objetivas para eficcia, eficincia e
produtividade do usurio na interao com o sistema;
diagnosticar as caractersticas do projeto que provavelmente
atrapalhem a interao por estarem em desconformidade
com padres implcitos e explcitos de usabilidade;
prever dificuldades de aprendizado na operao do sistema;
prever os tempos de execuo de tarefas informatizadas;
conhecer a opinio do usurio em relao ao sistema;
sugerir as aes de re-projeto mais evidentes face os
problemas de interao efetivos ou diagnosticados.
Com base nestes resultados podemos distinguir trs tipos
de tcnicas de avaliao ergonmica;
as Tcnicas Prospectivas, que buscam a opinio do usurio
sobre a interao com o sistema,
as Tcnicas Preditivas ou diagnsticas, que buscam prever
os erros de projeto de interfaces sem a participao direta
de usurios e
as Tcnicas Objetivas ou empricas, que buscam constatar
os problemas a partir da observao do usurio interagindo
com o sistema.
9.3 Tcnicas Prospectivas
Este tipo de tcnica est baseada na aplicao de
questionrios/entrevistas com o usurio para avaliar sua
satisfao ou insatisfao em relao ao sistema e sua
operao. Ela mostra-se bastante pertinente na medida em que
o usurio a pessoa que melhor conhece o software, seus
defeitos e qualidades em relao aos objetivos em suas tarefas.
Nada mais natural em buscar suas opinies para orientar
revises de projeto. Muitas empresas de software elaboram e
aplicam regularmente este tipo de questionrio, como parte de
sua estratgia de qualidade. Alguns questionrios de satisfao
encontram-se disponveis na internet como o QUIS -
Questionaire for User Interaction Satisfaction - Univ. Maryland
(Norman, 1989) (http://www.lap.umd.edu/QUIS/index.html)
importante salientar que os questionrios de satisfao
tm uma taxa de devoluo reduzida (mximo 30% retornam), o
que indica a necessidade de elaborao de um pequeno nmero
111
de questes sucintas. Um espao para opinies e sugestes
livres deve sempre ser proposto ao usurio.
Por outro lado, este tipo de tcnica pode ser empregada
para aumentar a efetividade de avaliaes analticas, realizadas
por especialistas que diagnosticam problemas de usabilidade.
Apoiados pelas respostas de questionrio de satisfao estes
podem centrar suas anlises sobre os pontos problemticos no
sistema, apontados pelo usurio. ISONORM (Prumper, 1999)
um questionrio de satisfao que tem o objetivo de direcionar a
aplicao da norma ISO9241-10 somente aos quesitos
apontados como problemticos pelo usurio atravs de
ISONORM.
9.4 Tcnicas Preditivas ou Diagnsticas
As tcnicas diagnsticas dispensam a participao direta de
usurios nas avaliaes, que se baseiam em verificaes e
inspees de verses intermedirias ou acabadas de software
interativo, feitas pelos projetistas ou por especialistas em
usabilidade.
Elas podem ser classificadas como:
Avaliaes Analticas
Avaliaes Heursticas
Inspees por Checklists
As avaliaes analticas envolvem a decomposio
hierrquica da estrutura da tarefa para verificar as interaes
propostas. As tcnicas de verificao conhecidas como
avaliaes heursticas se baseiam nos conhecimentos
ergonmicos e na experincia dos avaliadores que percorrem a
interface ou seu projeto para identificar possveis problemas de
interao humano-computador. As inspees por checklists tm
esse mesmo objetivo, mas dependem do conhecimento
agregado ferramenta de inspeo, uma vez que se destinam a
pessoas sem uma formao especfica em ergonomia.
9.4.1 Avaliaes Analticas
Esse tipo de tcnica empregado nas primeiras etapas da
concepo de interfaces humano-computador, quando ela no
passa de uma descrio da organizao das tarefas interativas.
Mesmo nesse nvel, j possvel verificar questes como a
consistncia, a carga de trabalho e o controle do usurio sobre o
dilogo proposto e de realizar modifica. A especificao da futura
tarefa interativa, pode ser realizada nos termos de um
formalismo apropriado como MAD, GOMS (Goals, Operators,
Methods and Selections rules) e CGL (Command Grammar
Language). Em particular, GOMS prope uma tabela associando
tempos mdios de realizao aos mtodos primitivos, que
correspondem a primitivas de aes fsicas ou cognitivas. Com
112
base nesta tabela e na descrio da tarefa realizada segundo o
formalismo possvel calcular os tempos provveis para a
realizao das tarefas previstas.
9.4.2 Avaliaes Heursticas
Uma avaliao heurstica representa um julgamento de
valor sobre as qualidades ergonmicas das interfaces humano-
computador. Essa avaliao realizada por especialistas em
ergonomia, baseados em sua experincia e competncia no
assunto. Eles examinam o sistema interativo e diagnosticam os
problemas ou as barreiras que os usurios provavelmente
encontraro durante a interao.
As avaliaes heursticas abordadas nesta apostila
enfocam os seguintes aspectos:
Usabilidade em geral
Intuitividade (Inspeo Cognitiva)
Gesto de erros (Inspeo Preventiva)
9.4.2.1 Avaliaes Heursticas de Usabilidade
Neste processo os avaliadores baseiam-se em heursticas
ou ou padres de usabilidade gerais, prprios ou desenvolvidos
por especialistas na rea. No momento atual, podem ser citadas
conjuntos de heursticas como:
Os Critrios Ergonmicos, propostos por Scapin e
Bastien (1993), e apresentados no captulo 4 desta
apostila;
As Heursticas de Usabilidade, propostas por Jacob
Nielsen, em seus livros sobre Engenharia de Usabilidade;
Os Princpios de Dilogo, propostos pela norma ISO
9241:10, apresentados no captulo 10 desta apostila.
As avaliaes heursticas de usabiliade podem produzir
timos resultados, em termos da rapidez de avaliao e da
quantidade e importncia de problemas diagnosticados.
Entretanto, seus resultados dependem da competncia dos
avaliadores e das estratgias de avaliao por eles empregadas.
Acabam sendo subjetivas, exigindo um grupo razovel de
avaliadores de usabilidade, de modo a identificar a maior parte
dos problemas ergonmicos das interfaces (Jeffries et al, 1991).
Pollier (1993) registrou a dinmica da avaliao de um sistema
interativo por especialistas em ergonomia de software, para
analisar seus resultados e principalmente suas estratgias de
ao.
Abordagem por objetivos dos usurios: o avaliador
aborda a interface a partir de um conjunto de tarefas e
sub-tarefas principais dos usurios ou das relacionadas
aos objetivos principais do software;
113
Abordagem pela estrutura de interface; por esta
estratgia, especialmente direcionada para dilogos por
menu, o avaliador aborda a interface como uma rvore
de menu com nveis hierrquicos e das aes que
permitem as transies de um nvel a outro. Dois
encadeamentos so possveis nessa estratgia; exame
por profundidade ou largura da rvore;
Abordagem pelos nveis de abstrao; o avaliador
aborda a interface como um modelo lingstico
estruturado em camadas de abstrao (ver tpico 5.1)
que podem ser examinadas em dois sentidos; top-down
ou bottom-up;
Abordagem pelos objetos das interfaces; o avaliador
aborda a interface como um conjunto de objetos

(cap 5);
Abordagem pelas qualidades das interfaces: o avaliador
aborda a interface a partir das qualidades ou heursticas
de usabilidade que elas deveriam apresentar (cap. 4).
Atravs do estudo, a autora verificou que, embora as
abordagens citadas tenham um carter sistemtico e exaustivo,
os analistas trocam de perspectiva constantemente durante a
avaliao, realizando um encadeamento oportunista, particular a
cada indivduo. Desta forma, a autora pode constatar as grandes
diferenas entre os resultados das avaliaes individuais, o que
evidencia um carter subjetivo em cada avaliao individual.
Nas avaliaes heursticas os resultados dependem
diretamente da carga de conhecimento e experincia que as
pessoas trazem para as avaliaes, e do tipo de estratgia com
que percorrem a interface.
Autros autores apontam para uma particularidade deste tipo
de tcnica : s vezes, as sugestes de re-projeto so mais
consideradas pelos avaliadores do que a caracterizao dos
problemas. Deste modo, as avaliaes heursticas apresentam
um efeito colateral importante : a posssibilidade de introduzirem
novos problemas de usabilidade sobre as interfaces.
Os dados obtidos no estudo de Pollier evidenciam a
necessidade de um mtodo ou tcnica que possa uniformizar as
anlises e garantir uma mdia de desempenho individual
superior para os analistas. Nesta apostila encontram-se descritas
algumas ferramentas importantes para a realizao de
avaliaes heursticas, em particular, o conjunto de critrios e de
recomendaes ergonmicas apresentadas no captulo 4, o
modelo de nveis de abstrao e o modelo de componentes de
interfaces descritos no captulo 5.
Como qualquer atividade de avaliao, este tipo de tcnica
iniciada pela anlise do contexto da avaliao, quando o
responsvel pela avaliao verifica, junto aos responsveis pelo
software, os recursos disponveis e os objetivos da avaliao.
114
Em funo desta anlise podem ser alocados um nmero maior
ou menor de avaliadores trabalhando em paralelo. Em funo de
se ter ou no acesso a usurios reais, questionrios e entrevistas
podem ser preparados, de modo a coletar informaes sobre seu
perfil e sobre o modo como utiliza o software. importante frisar
que o contato com o usurio, mesmo que por fax ou telefone
de bastante til para conduzir as avaliaes. Face a tipos
especiais de interfaces ou aplicaes, algumas vezes o avaliador
deve procurar o conhecimento necessrio para julgar as
qualidades do software. A estratgia para a avaliao como foi
visto varivel e vai depender do avaliador, do tipo de software,
do tipo de interface, etc.. A ltima etapa e a mais crtica, a de
redao do relatrio de avaliao, que deixar registrados os
problemas identificados e as propostas de solues sugeridas.
Sugere-se a adoo de um formato de descrio de problemas,
como o apresentado anteriormente neste captulo. Ele permitir
esclarecer e priorizar os problemas de usabilidade.
9.4.2.2 Inspeo Cognitiva da Intuitividade
Esta um tipo de avaliao heurstica, onde os especilistas
enfocam especificamente os processos cognitivos que se
estabelecem quando o usurio realiza a tarefa interativa pela
primeira vez (Kieras e Polson, 1991). Ela est baseada em um
modelo de como se desenvolvem as aes cognitivas dos
usurios. Assim, ela visa avaliar as condies que o software
oferece para que o usurio faa um rpido aprendizado das telas
e das regras de dilogo. A intuitividade o aspecto central na
aplicao de uma inspeo cognitiva.
A validade desta tcnica est justamente em seu enfoque
nos processos cognitivos. Para realiz-la o avaliador deve
atentar para aquilo que o usurio conhece da tarefa e da
operao de sistemas informatizados. Deve tambm conhecer o
caminho previsto para a realizao das principais tarefas do
usurio. De posse destas informaes ele passa a percorrer os
caminhos previstos aplicando, para cada ao o seguinte
checklit.
o usurio a tentar realizar a tarefa certa? Ao
encontrar-se no passo inicial de determinada tarefa, o
usurio, baseado no que lhe apresentado, se propor a
realizar o objetivo previsto pelo projetista?
ele ver o objeto associado a esta tarefa? Este objeto
est suficientemente vista do usurio?
ele reconhecer o objeto como associado tarefa? As
denominaes ou representaes grficas so
representativas da tarefa e significativas para o usurio?
ele saber operar o objeto? O nvel de competncia
na operao de sistema informatizados compatvel com
a forma de interao proposta?(esta questo foi
115
adicionada tcnica original a partir das pesquisas de
Sears, 1997)
ele compreender o feedback fornecido pelo sistema
como um progresso na tarefa?
A proposta dos autores desta tcnica de que os prprios
projetistas possam aplica-la no desenvolvimento do sistema
interativo.
9.4.2.3 Inspees preventivas de erros
Esta uma tcnica de avaliao heurstica pela qual o
avaliador inspeciona a interface procura de situaes que
possa levar a erros ou incidents. Tem portanto uma pertinncia
especial para sistemas de alta responsabilidade, como os de
controle de processos em tempo real.
Para aplic-la o avaliador levanta as caractesticas do
contexto de operao e inspeciona a interface seguindo um
modelo de tarefas, aplicando aos trs components bsicos da
tarefa (entradas, realizao e resultados) um conjunto de
heursticas ou guidewords especficas para orientar na deteco
de erros.
As avaliaes so organizadas em tabelas para cada tarefa
esplicitando:
Tarefa
Guideword de desvio possivel
Explicaes sobre os desvios
Causas dos desvios
Consequncias dos desvios
Recomendaes de reprojeto
As guidewords aplicveis as tarefas so as seguintes:
E se nada acontecer ?
E se algo diferente acontecer ?
E se algo acontecer a mais
E se algo acontecer a menos
E se algo acontecer a diferente
E se algo acontecer fora de tempo ?
E se algo acontecer antes?
E se algo acontecer depois
9.4.3 Inspees Ergonmicas via Checklists
As inspees de usabilidade por checklists, so vistorias
baseadas em listas de verificao, atravs das quais
116
profissionais, no necessariamente especialistas em ergonomia,
como por exemplo, programadores e analistas, diagnosticam
rapidamente problemas gerais e repetitivos das interfaces
(Jeffries et al, 1991). Neste tipo de tcnica, ao contrrio das
avaliaes heursticas, so as qualidades da ferramenta
(checklists) e no dos avaliadores, que determinam as
possibilidades para a avaliao. Checklists bem elaborados
devem produzir resultados mais uniformes e abrangentes, em
termos de identificao de problemas de usabilidade, pois os
inspetores so conduzidos no exame da interface atravs de
uma mesma lista de questes a responder sobre a usabilidade
do projeto.
Os resultados obtidos atravs dessa tcnica dependem
ento da organizao e do contedo, geral ou especfico, dessas
ferramentas. Verses especializadas de um checklist podem ser
desenvolvidas a partir de um outro, com questes genricas.
As questes do checklist podem vir acompanhadas de
notas explicativas, exemplos e de um glossrio a fim de
esclarecer possveis dvidas associadas as mesmas. O servio
Web ErgoList (http://www.labiutil.inf.ufsc.br/ergolist),
desenvolvido pelo LabIUtil, prope esse tipo apoio de aplicao.
Algumas questes desse checklist encontram-se no anexo 2
desse livro.
A avaliao realizada atravs de checklists apresenta as
seguintes potencialidades:
possibilidade de ser realizada por projetistas, no
exigindo especialistas em interfaces humano-
computador, que so profissionais mais escassos no
mercado. Esta caracterstica deve-se ao fato do
conhecimento ergonmico estar embutido no prprio
checklist;
sistematizao da avaliao, que garante resultados
mais estveis mesmo quando aplicada separadamente
por diferentes avaliadores, pois as
questes/recomendaes constantes no checklist
sempre sero efetivamente verificadas;
facilidade na identificao de problemas de usabilidade,
devido a especificidade das questes do checklist;
aumento da eficcia de uma avaliao, devido a
reduo da subjetividade normalmente associada a
processos de avaliao;
reduo de custo da avaliao, pois um mtodo de
rpida aplicao.
Entretanto, estes tipos de resultado dependem
essencialmente das qualidades das listas de verificao, e nem
sempre so atingidos. Muitas vezes a sistematizao
prejudicada devido a questes subjetivas, que solicitam do
117
inspetor um nvel de competncia em usabilidade ou de
conhecimento sobre o contexto que ele no possui. Outras vezes
a abrangncia das inspees prejudicada devido ao contedo
incompleto e organizao deficiente das listas. A economia na
inspeo fica prejudicada por listas propondo uma grande
quantidade de questes, que em sua maioria no so aplicveis
ao sistema em avaliao. Por outro lado, o trabalho de Jeffries et
ali (1991) mostra que este tipo de tcnica proporciona a
identificao de uma grande quantidade de pequenos problemas
de usabilidade que se repetem nas interfaces dos sistemas. Em
relao sistemtica de classificao proposta neste texto os
problemas identificados por meio de inspees de usabilidade se
referem principalmente a rudos gerais.
Um tipo de instrumento de inspeo ergonmica bastante
bem definido so as normas internacionais de usabilidade. Em
particular, o captulo 10 desta apostila faz uma descrio das
partes da norma ISO 9241 "Ergonomic requirementes for office
work with visual display terminals". O anexo 3 traz os checklists
propostos por esta norma internacional em sua parte 10 sobre
Princpios de Dilogo.
9.5 Tcnicas Objetivas
As tcnicas empricas, que contam com a participao
direta de usurios se referem basicamente aos ensaios de
interao e as sesses com sistemas espies.
9.5.1 Ensaios de interao
Um ensaio de interao consiste de uma simulao de uso
do sistema da qual participam pessoas representativas de sua
populao-alvo, tentando fazer tarefas tpicas de suas atividades,
com uma verso do sistema pretendido. Sua preparao requer
um trabalho detalhado de reconhecimento do usurio-alvo e de
sua tarefa tpica para a composio dos cenrios e scripts que
sero aplicados durante a realizao dos testes.
9.5.1.1 As caractersticas dos ensaios
A complexidade do teste vai depender do nvel de exigncia
requerido para os resultados, da generalidade do produto e da
disponibilidade de recursos e de usurios. Testes simples, para
reconhecer a perspectiva do usurio, para produtos
especializados, onde se tenha acesso rpido aos usurios,
podem ser implementados rapidamente. Situaes mais
exigentes e em um quadro de dificuldades, a elaborao pode se
tornar bem mais custosa e complicada. Para tomar concincia
das dificuldades e facilidades nesta tarefa, importante que se
faa uma anlise das caractersticas dos ensaios de interao,
envolvendo; o nvel de constrangimento aceitvel, o tipo de
118
verbalizao a ser solicitada ao usurio, o local de realizao dos
ensaios e as tcnicas de registro e coleta de dados.
9.5.1.1.1 O Constrangimento
O constrangimento inerente aos ensaios de interao, na
medida em que implicam na observao de uma pessoa
trabalhando com um sistema interativo. Cabe ao analista
procurar tcnicas e mtodos que evitem essa situao,
garantindo a validade dos resultados obtidos.
Os seguintes cuidados podem ser tomados no sentido de
prevenir a integridade psicolgica do usurio:
esclarecer o usurio sobre o teste, enfatizando a
finalidade do ensaio e da sua participao. Essa atitude
deve ser aceita por ambos, observador e observado.
no pression-los a participarem dos ensaios;
no exp-los a comentrios de colegas. Tentar a
realizao de ensaios in loco em horrios de pouco
movimento ou presena de colegas de servio;
caso o participante se sinta cansado ou constrangido
diante de uma determinada situao, prefervel parar a
realizao do ensaio, de forma educada, evitando
transmitir ou encorajar o sentimento de culpa no usurio.
os ensaios devem ser planejados cuidadosamente
quanto a divulgao dos resultados, evitando invadir a
privacidade dos participantes. A melhor maneira de
abordar esta questo evitar a coleta de informaes
que possam ser usadas para identificar algum.
9.5.1.1.2 A Verbalizao
Para obter uma informao correta, o analista precisa saber
o que os usurios esto pensando e no somente o que eles
esto fazendo. Para tanto necessrio solicitar a eles que
verbalizem durante ou aps a interao com o software.
9.5.1.1.2.1 Verbalizao Simultnea
Por essa tcnica, deve-se solicitar aos usurios que alm
de executarem a tarefa, tambm comentem o que esto
pensando enquanto a executam.
Deve se ter o cuidado de aplicar esta tcnica com pessoas
extrovertidas para as quais o ato de falar sobre a tarefa no seja
uma fonte de perturbao. Por outro lado, cabe ao observador
dosar a quantidade de verbalizao demandada de acordo com
as dificuldades na execuo da tarefa. Considere que na
verbalizao simultnea o foco de ateno do usurio, que deve
estar na execuo da tarefa, desviado para raciocinar e
explicar como execut-la.
119
No decorrer da interao, o analista responsvel pelo
ensaio, vai colocando ao usurio questes do tipo:
Conte-me o que voc est pensando?
O que voc est tentando fazer?
O que voc est lendo?
Como o trabalho se apresenta?
Esses comentrios devem ser registrados ou anotados para
que depois possam ser revistos.Por outro lado, o analista deve
ao mesmo tempo controlar os acontecimentos e incentivar o
usurio a falar sobre o que est fazendo.
Os comentrios e os registras da aes tornam evidentes
aos projetistas que algumas funes no so bem
compreendidas, ou que existem rtulos que causam dvidas,
levando o usurio a executar de forma errada a sua tarefa.
9.5.1.1.2.2 Verbalizao Consecutiva
Para determinado tipo de pessoas, o ato de falar, ao
mesmo tempo em que deve pensar em como resolver uma
tarefa, pode levar a uma sobrecarga mental que vai interferir no
seu desempenho enquanto usurio de um sistema. A tcnica de
observao simultnea vai desconcentr-lo constantemente da
tarefa que executa, podendo s vezes, induzir erros de interao.
Uma alternativa para a tcnica de verbalizao simultnea
a de verbalizao consecutiva. Trata-se de uma entrevista com
o usurio, realizada no final do ensaio de interao, onde este
comenta sobre as tarefas que acabou de executar.
Pode ocorrer que o usurio venha a esquecer a origem de
um problema ou de uma situao de erro. Nesse caso, pode-se
fazer uma entrevista valendo-se da fita de vdeo que registrou o
ensaio de interao. Ela deve ser mostrada ao usurio como
forma de favorecer a recuperao das causas e expectativas de
um procedimento.
Esta tcnica pode ainda ser conduzida de forma a pedir ao
usurio que comente certas caractersticas especficas da
interface. Estes comentrios sempre trazem boas sugestes,
como tambm, deixam transparecer as reaes positivas ou
negativas do usurio, sobre determinados pontos da interface.
9.5.1.1.3 O local do teste
Existem, teoricamente, dois tipos de ambientes onde o
ensaio de interao pode ser realizado. O primeiro, o local
usual da tarefa, sendo o observador, um elemento adicional
neste ambiente. O segundo, num laboratrio, o ambiente da
tarefa substancialmente diferente. Usualmente trata-se de uma
forma empobrecida do ambiente normal de trabalho.
9.5.1.1.3.1 Teste em Laboratrio
120
A avaliao feita em laboratrio, equipado com recursos e
aparelhos sofisticados, permite observar a interao
homem/mquina de forma contnua, dando ao analista maior
controle da situao. Assim, o analista pode escolher a melhor
posio da cmera, ter cmeras focalizadas para o teclado,
monitor, mouse, etc.
No caso de um software que ainda esteja na fase de
concepo, a avaliao feita em laboratrio se mostra mais
adequada pois, o analista pode testar uma funo, fazer algumas
correes, e tornar a testar o sistema.
Em alguns laboratrios existem salas especiais, equipadas
com vidros espelhados onde o analista no notado, garantindo
que o usurio no seja interrompido e no fique envergonhado.
Ele normalmente dispe de um telefone como forma de ajuda
instantnea, um canal direto com o projetista.
A principal desvantagem desse processo que nos
laboratrios, onde tudo parece perfeito, no se consegue retratar
a realidade de uma situao de trabalho.
9.5.1.1.3.2 Teste in loco
Um teste realizado no prprio local de trabalho do usurio
pode ser mais trabalhoso e cansativo para a equipe de analistas.
Mas, por outro lado, traz informaes mais ricas em detalhes.
Detalhes estes que tem suas origens em fatores ambientais que
influenciam na execuo da tarefa.
Observar como o usurio atua quando interrompido por
companheiros de trabalho, quando tem que parar para atender o
telefone, quando pressionado pelo chefe ou quando tem prazo
para entregar um trabalho, pode ser uma maneira de se obter
valiosos dados que podero auxiliar na elaborao de
determinadas funes.
A avaliao feita no prprio local de trabalho mostra as
interferncias alheias a tarefa que, muitas vezes, podem induzir
situaes de erro na interao com um determinado sistema.
9.5.1.1.4 O registro e a coleta de dados
Como a interao com um software um processo contnuo
envolvendo imagens e sons do programa, alm de verbalizaes
dos usurios, o mais recomendado utilizar cmaras de vdeo
para o registro de tudo. Para evitar possveis constrangimentos
procure realizar o ensaio da forma mais conveniente para o
usurio (horrio e local). Procure saber se o usurio tem alguma
objeo quanto gravao, ou se isso pode vir a lhe trazer
problemas de qualquer ordem. Em todo o caso, tome o cuidado
de no filmar o rosto dos participantes.
Realizar anotaes com lpis e papel pode ser uma tcnica
simples que pode ser usada em qualquer lugar e com o mnimo
121
de custo. Entretanto, na medida em que a observao torna-se
excessivamente explicita uma tcnica que pode causar certo
desconforto ou constrangimento para a pessoa que est sendo
observada. Alm disso, esta tcnica requer prtica e habilidade
por parte do observador e dificilmente ela pode ser empregada
sem o apoio de uma outra tcnica de registro.
9.5.1.2 Montagem de um ensaio de interao
A montagem de um ensaio de interao pressupe
inicialmente uma etapa de anlise preliminar para conhecer o
software e seus atributos ergonmicos.
9.5.1.2.1 Anlise Preliminar
Nessa etapa os analistas tomam conhecimento dos fatos a
cerca do software e de seu contexto de desenvolvimento e
realizam um pr-diagnstico dos problemas ergonmicos de sua
interface com o usurio.
MONTAGEM DE ENSAIO DE INTERAO
DEFINIO DOS CENRIOS E DA AMOSTRA
Reconhecimento do usurio
Coleta de informaes
sobre o usurio e sua tarefa
Definio de tarefas para o
usurio
REALIZAO DOS ENSAIOS
Coleta e anlise dos dados
Realizao dos ensaios
Diagnstico e relatrio final
Preparao dos ensaios
Ajuste nos scripts e cenrios
ANLISE PRELIMINAR
Reconhecimento do software
Pr-diagnstico Ergonmico
Obteno da amostra de
usurios
122
9.5.1.2.1.1 Reconhecimento do software
Para o reconhecimento do software feita uma sesso de
entrevistas preliminares com as pessoas que o projetaram e
desenvolveram, que trazem informaes de seu projeto e
desenvolvimento.
As questes solicitadas equipe de projeto do software
abrangem:
populao alvo: para que tipo de trabalhador foi destinado
o software?;
tipo de tarefa que o software visa atender: Que tipo de
tarefa o usurio poder desenvolver com este aplicativo?;
funes principais do produto: Quais as funcionalidades
que, na opinio dos projetistas, tm maior impacto na tarefa
e na organizao do trabalho?;
equipe de projetistas: Quantas pessoas foram envolvidas
no projeto, houveram ergonomistas?;
tempo de desenvolvimento: Quanto tempo se gastou no
projeto? Houveram interrupes? Por quais motivos?;
dados sobre o sistema: Qual o ambiente de programao
em que foi desenvolvido o software?;
verses precedentes: Qual a verso atual do produto?
Quais as alteraes no projeto inicial?
situao no mercado: O produto muito comercializado?
Os usurios se mantm fiis no uso?;
suporte: Existe algum tipo de suporte tcnico que dado
aos usurios?;
Este levantamento se destina a compreender o ciclo de
desenvolvimento pelo qual passou o software e embasar o pr-
diagnstico.
9.5.1.2.1.2 Pr-diagnstico
A partir das informaes obtidas dos projetistas do
software, os analistas examinam todo o aplicativo, primeiro para
conhecer bem as funcionalidades do produto, e depois, para
identificar as funes mais problemticas.
O pr-diagnstico pode ser obtido atravs de uma tcnica
de avaliao do tipo heurstica ou ainda a partir de checklists
para inspeo ergonmica. Os critrios, recomendaes e
normas ergonmicas servem como ferramenta de apoio nessa
etapa de avaliao.
O resultado do pr-diagnstico um conjunto de hipteses
sobre problemas de usabilidade do software que sero
posteriormente testadas durante os ensaios de interao.
9.5.1.2.2 Definio dos Scripts, Cenrios e da Amostra de usurios
Os scripts envolvem o conjunto de tarefas que uma amostra
de usurios representativos da populao alvo do sistema
123
dever realizar durante os ensaios. O cenrio se refere as
condies ambientais e organizacionais que sero trazidas para
os teste. Scripts e cenrios so montados a partir das
informaes coletadas no reconhecimento do software e de seu
pr-diagnstico ergonmico e das informaes trazidas do
reconhecimento do perfil do usurio e de sua tarefa.
9.5.1.2.2.1 Reconhecimento do perfil do usurio
A primeira atividade de reconhecimento do usurio consiste
em contactar pessoas do pblico-alvo em seus locais de trabalho
e de verificar se as pessoas contatadas possuem efetivamente o
perfil imaginado pelos projetistas. J nessa etapa possvel pr-
selecionar um grupo de usurios que podero vir a participar dos
ensaios. Tome os cuidados de explicar-lhes qual a finalidade da
anlise, quais os procedimentos que a equipe adotar e de
deix-los livres para participar ou no da atividade proposta.
9.5.1.2.2.2 Coleta de informaes sobre o usurio e sua tarefa
Dependendo da abrangncia da populao-alvo do
software, pode ser necessria a realizao de uma etapa mais
detalhada de coleta de informaes sobre o usurio e sua tarefa,
Nela, o analista deve elaborar questionrios destinados a buscar
os dados de uma grande amostra de usurios. Alm de ser
enviado aos usurios, o questionrio pode, tambm, servir de
roteiro para entrevistas presenciais ou a distncia.
Atravs de questionrios pode-se coletar dados a respeito:
dos recursos disponveis, tanto tcnicos quanto fsicos,
para a realizao da tarefa: Tambm importante saber
qual o tipo de suporte que a empresa oferece aos
empregados quanto a treinamento e apoio tcnico.
do contexto da tarefa: Durante as entrevistas e
observaes, os analistas tomam conhecimento do
vocabulrio utilizado pelos usurios, das diversas
atividades que eles desenvolvem, das presses
organizacionais exercidas sobre ele. Uma amostra do
resultado final do trabalho dos usurios pode ser
bastante til para a montagem dos cenrios;
do nvel dos usurios: Dados como formao geral e
especfica em informtica e no aplicativo em anlise,
tempo de empresa, tempo na atividade desenvolvida e o
conhecimento de outros aplicativos permitem diferenciar
os usurios novatos e os experientes.
da utilizao do sistema; em especial os questionrios
visam obter uma viso geral sobre a utilizao de um
sistema pronto ou em desenvolvimento. As questes
devem estar direcionadas para as funcionalidades,
buscando conhecer aquelas que o usurio considera de
maior impacto positivo e negativo sobre seu trabalho.
124
Deve-se tambm buscar conhecer as freqncias de
utilizao de cada funcionalidade.
9.5.1.2.2.3 Definio dos scripts de tarefas para os ensaios
Para definir os scripts necessrio selecionar as tarefas
envolvidas com:
os objetivos principais do software, sob o ponto de vista
de seus projetistas;
as hipteses dos ergonomistas, formuladas no pr-
diagnstico;
as amostras de tarefas dos usurios, que foram
recolhidas juntamente com os questionrios;
as funcionalidades do sistema consideradas mais e
menos importantes pelo usurio;
as funcionalidades mais freqentemente acionadas
pelos usurios na utilizao do software;
Um script nasce da combinao desses parmetros,
levando-se sempre em considerao o aspecto custo x benefcio
dos ensaios. Uma avaliao perfeita impossvel de ser
elaborada. O importante saber avaliar, e manter nos ensaios
somente os aspectos crticos, sob o ponto de vista do usurio e
de sua tarefa.
9.5.1.2.3 Realizao dos ensaios
A primeira etapa para a realizaro dos ensaios consiste na
obteno da amostra de usurios que deles participaro. As
outras atividades desta etapa incluem a realizao de ajustes
nos cenrios para adapt-los aos usurios participantes da
amostra, o planejamento dos ensaios, a sua realizao, a anlise
e a interpretao dos dados obtidos.
9.5.1.2.3.1 Obteno da amostra de usurios
necessrio verificar agora, quem da amostra de usurios,
realiza efetivamente as tarefas que compem os scripts para a
avaliao. Seleciona-se pessoas voluntrias, certificando-se de
que:
sejam experientes na tarefa;
sejam usurios diretos, isto , pessoas que realmente
exeram suas atividades com o auxlio do software;
sejam metade novatos, metade experientes no
software que ser avaliado;
Os usurios iniciantes daro mais informaes sobre a
facilidade de aprendizagem e a simplicidade de utilizao. J os
experientes daro mais informaes sobre a organizao das
funes e a repartio das informaes.
125
A experincia do usurio no aplicativo pode ser formada por
diversos pontos: participao de cursos de treinamento em
aplicativos; experincia anterior com outros softwares; leitura de
livros e revistas afins e a prpria habilidade desenvolvida com o
aplicativo. Atente para o fato de que o processo de avaliao
iterativo. Os usurios novatos, numa segunda etapa de
avaliao, devero ser considerados como usurios experientes.
O tamanho da amostra deve ser suficiente para cobrir os
diferentes tipos de usurios que possam utilizar o software
dentro das expectativas e objetivos da avaliao. Deve tambm
ser um nmero que permita diferenciar as observaes
generalizveis das que possam ser especficas de uma
determinada pessoa. A literatura sugere uma margem de 6 a 12
pessoas para atuarem nos ensaios de interao.
Finalmente, deve-se deixar bem claro aos participantes dos
ensaios, qual a sua extenso, para que se destina e o que se
espera deles. importante que o usurio se sinta totalmente a
vontade para recusar o convite sem presses da gerncia ou de
qualquer tipo.
9.5.1.2.3.2 Ajustes nos scripts e cenrios
Para cada um dos participantes dos ensaios de interao
deve ser realizada uma nova entrevista para buscar informaes
visando os ajustes nas variveis dos scripts e dos cenrios. Os
scripts, com a descrio das tarefas a serem solicitadas ao
usurio devem trazer termos e objetivos que lhe sejam
familiares. Os cenrios podem reproduzir, em laboratrio, a
familiaridade do ambiente domstico ou profissional de
determinado usurio.
9.5.1.2.3.3 Planejamento dos ensaios
A preparao dos ensaios envolve a tomada de deciso e a
adoo de providncias relativas ao local dos ensaios,
equipamento para registro dos acontecimentos, escolha das
tcnicas de verbalizao (consecutiva/simultnea) e definio
das estratgias de interveno em caso de impasse. Deve-se,
neste particular procurar sempre preservar o anonimato dos
usurios.
As situaes de impasse representam um constrangimento
a mais para o usurio. Para lidar com estas situaes sugere-se
deixar o usurio tentar resolver sozinho qualquer tarefa;
nunca tomar atitudes grosseiras que possam inibir o
usurio na continuao do ensaio de interao;
depois de algum tempo, persistindo a situao de
impasse, propor ao usurio a realizao de uma tarefa
alternativa previamente estipulada no script;
126
caso os usurios participantes dos ensaios de interao
encontrem-se realmente constrangidos ou nervosos, os
ensaios deveriam ser interrompidos totalmente.
9.5.1.2.3.4 Realizao dos Ensaios
Os ensaios de interao, que podem ser realizados no local
de trabalho de cada usurio ou em laboratrio, devem durar no
mximo 1 hora. Deles devem participar alm do usurio, 1 ou 2
ergonomistas observadores e 1 assistente tcnico, responsvel
pelo funcionamento dos equipamentos. O desenrolar dos
ensaios so controlados e dirigidos pelos ergonomistas que
devem planejar como proceder nos casos de interrupes,
retomadas e encerramento precoce do teste. Alm disso, eles
devem realizar anotaes em tempo real, sobre o desempenho
do usurio e dos erros e incidentes verificados. Dessas
anotaes devem constar indicaes sobre o instante dos
eventos perturbadores. Uma boa prtica consiste na realizao
de um ensaio piloto para certificar-se de que tudo foi previsto.
9.5.1.2.3.5 Anlise e interpretao dos dados obtidos
Depois da realizao dos ensaios, a equipe de analistas
deve rever todas as gravaes buscando dados relevantes que
comprovem ou no as hipteses anteriormente estabelecidas.
Alm disto, muitas situaes inesperadas de erros e
recuperao da informao podem aparecer. Da a importncia
dos ensaios, pois estes tipos de erros s tornam-se evidentes em
situao realista de uso.
Os resultados dos ensaios de interao so relatados e
comentados num caderno de encargos que entregue aos
projetistas do sistema. No relatrio so descritos os incidentes
produzidos durante a interao, relacionando-o com um aspecto
do software. Comentrios sobre a prioridade dos problemas
devem fazer parte do relatrio.
9.5.2 Os sistemas de monitoramento
Uma outra forma de realizar uma validao emprica, isto ,
com a observao direta de usurios, se d atravs do emprego
de sistemas de monitoramento ou espies. Estes sistemas so
ferramentas de software que permanecem residentes na
mquina do usurio simultaneamente ao aplicativo em teste (MS
Camcorder ou Lotus ScrenCam). Eles so concebidos de
maneira a capturar e registrar todos os aspectos das interaes
do usurio com seu aplicativo em sua prpria realidade de
trabalho. Nesse sentido, essa tcnica permite contornar dois
inconvenientes dos ensaios de interao. Mesmo que os
usurios estejam cientes dos testes, os sistemas espies no
causam constrangimentos ao usurio e capturam as
interferncias causadas por sua realidade do trabalho. Por outro
127
lado, no h como incentivar ou registrar as verbalizaes dos
usurios. Os sistemas espies apresentam tambm limitaes
do ordem tcnica, relacionadas principalmente, a portabilidade
das ferramentas de espionagem face a diversidade de ambientes
de programao existentes. A quantidade de dados a tratar pode
se tornar muito grande. Dessa forma, a durao dos testes deve
ser bem planejada pelos analistas.
9.6 Compromisso entre tcnicas de avaliao
Para a escolha de uma tcnica de avaliao importante
examinar as suas qualidades no confronto com os recursos
disponveis e as expectativas de resultados da avaliao de
usabilidade.
As diferentes tcnicas de avaliao apresentadas neste
captulo apresentam qualidades diferentes em termos do tipo e
quantidade de problemas que identificam, da sistematizao de
seus resultados, da facilidade de aplicao e das chances que
seus resultados apresentam de poder convencer os projetistas
das necessidades de mudanas nas interfaces humano-
computador.
Efetividade se refere quantidade de problemas srios (recorrentes,
transponveis e assimilveis) identificados. Segundo pesquisas
realizadas (Jeffries, at ali,1993) as tcnicas mais efetivas so as
avaliaes heursticas e os ensaios de interao;
Abrangncia se refere quantidade de problemas reais de todos os
tipos identificados. As inspees por checklists e as avaliaes
heursticas so as mais abrangentes;
Eficincia - a razo da quantidade de problemas srios (recorrentes,
transponveis e assimilveis) identificados face a quantidade de
problemas reais identificados de todos os tipos. A mesma pesquisa
indica os ensaios de interao como a tcnica mais eficiente;
Produtividade - se refere a razo entre a quantidade de problemas
reais de todos os tipos identificados em relao a quantidade de
recursos financeiros (U$) necessrios;
Sistematizao para esta qualidade concorrem dois fatores
igualmente importantes: repetitividade e reproduzibilidade. O primeiro
refere-se medida pela qual os resultados produzidos pela tcnica se
repetem quando o mesmo avaliador examina o mesmo software algum
tempo depois da primeira avaliao. O segundo fator se refere a
medida pela qual dois avaliadores diferentes examinando um mesmo
software produzem os mesmos resultados; As inspees por
checklists so as mais sistemticas
Facilidade de aplicao se refere a qualidade da tcnica de no
exigir formao ou competncias especficas para sua realizao.
Neste sentido, as inspees por checklists so as mais fcil aplicao;
Poder de persuaso se refere a qualidade da tcnica de produzir
resultados capazes de convencer os projetistas da gravidade dos
128
problemas de usabilidade identificados. Os ensaios de interao e as
avaliaes heursticas
Poder de desobstruo A desobstruo se refere qualidade da
tcnica produzir indicaes de melhorias na usabilidade dos sistemas.
O entupimento se refere ao efeito colateral indesejvel de uma
modificao de projeto equivocada que tenha sido sugerida por meio
de uma avaliao de usabilidade.
9.7 Projeto de Avaliao
O sucesso do desenvolvimento, implantao ou compra de
um software interativo est intimamente ligado ao projeto da
atividade de verificao&validao de sua usabilidade. Pode-se
evitar disperdcios, desenvolvendo idias ou solues
equivocadas, ou ao contrrio, concentrar recursos nas idias que
podero satisfazer os usurios. Pode-se liberar um software-
produto para o mercado ou ao contrrio, solicitar alteraes de
ltima hora em sua interface com o usurio. Pode-se suspender
uma transao de compra e venda de software ou abaliz-la,
com base nos resultados de uma avaliao de usabilidade.
Deste modo, a avaliao de usabilidade deve ser
organizada a partir de uma metodologia de projeto. A norma ISO
14 598 prope uma conduo para a montagem de projetos de
avaliao com uma estrutura similar a aqui proposta, prevendo
etapas de:
anlise : identificao dos requisitos da avaliao;
projeto preliminar : seleo das tcnicas aplicveis;
projeto detalhado : configurao das tcnicas;
implementao : realizao da avaliao;
documentao : elaborao do relatrio;
validao : confronto entre os resultados esperados e
obtidos com a avaliao.
Na etapa inicial de anlise de requisitos deve-se verificar o
que se tem como recursos disponveis (dinheiro, pessoal,
especialistas, usurios, tempo, verso do software, ferramentas
e equipamentos) e quais so os resultados esperados da
avaliao (ver tpico 7.2).
Com base nesta anlise, faz-se, na etapa de projeto
preliminar da avaliao, uma definio sobre quais tcnicas so
as mais adequadas. Esta pode se tornar uma tarefa complexa,
na medida em que se trata de uma deciso com mltiplas
variveis e uma soluo, que pode envolver uma combinao de
tcnicas, depende da quantidade de recursos materiais e
humanos disponveis e dos tipos de resultados esperados para a
avaliao.
129
A etapa de projeto detalhado envolve a configurao das
tcnicas selecionadas para a avaliao. Nesta etapa so
detalhados parmetros como, por exemplo, nmero de
especialistas que iro realizar uma avaliao heurstica,
abordagem de varredura, critrios prioritrios, checklists para
inspeo de usabilidade, nmero de usurios a observar, local
de realizao dos ensaios (em laboratrio ou em campo), scripts
de tarefas e cenrios, tempo dos ensaios, etc.
Na implementao, a avaliao realizada. Seguindo as
indicaes de cada tcnica, coletam-se os dados, identificam-se
os problemas, que so categorizados e priorizados.
A etapa de documentao envolve a elaborao do relatrio
da avaliao. Este deve incluir uma apresentao do contexto e
dos requisitos da avaliao realizada, as ferramentas
empregadas e os problemas identificados, categorizados por
critrio, tarefa ou componente de IHC, e priorizados.
Dependendo dos requisitos da avaliao, pode ser necessrio
anexar descrio do problema propostas de melhorias que
sejam evidentes.
Na etapa de validao do processo de avaliao verifica-se
se os requisitos esperados para a atividade foram efetivamente
alcanados. Esta retro-alimentao sobre o que deu, e sobre o
que no deu certo durante a realizao dos testes fundamental
para garantir o sucesso de novos projetos de avaliao.
9.8 Plano de Testes
Um plano de testes refere-se a diversos projetos de
avaliao, um para cada etapa do desenvolvimento ou verso
intermediria do software interativo. Trata-se da combinao de
tcnicas para testar o projeto e a implementao do sistema, da
forma mais abrangente possvel, dentro das limitaes de
recursos disponveis. Ele deve prever, para cada verso
intermediria do sistema, mesmo que no passe de um conjunto
de idias, qual o tipo de teste apropriado, quais as condies
(casos) de teste e quais os resultados admitidos. A figura abaixo
mostra uma estratgia de validao ergonmica possvel.
130
DESENVOLVI
PROJ
IMPLANT
IMPLEMENTAO
PROJETO
IMPLANTAO
PROJ
CONCEPO
PROJ
ANLISE
IMPLANT
REVISES
DESENVOLVI
PROJ
IMPLANT
Checklists
Aval. Heursticas
Ensaios de Interao
PROJ
Inspeo Cognitiva
PROJ
Reunies c/o Usurio
IMPLANT
Quest. de Satisfao
Etapas de Sntese x Tcnica de Avaliao
PLANO DE TESTES DE ERGONOMIA
131
10. A NORMA ISO 9241
A norma ISO 9241 trata do trabalho de escritrio
informatizado atravs do uso de planilhas eletrnicas e de
processadores de textos, entre outros aplicativos. No esto
includos os aplicativos de projeto auxiliado por computador e de
controle de processos (CAD-CAM), bem como as interfaces que
usem estereoscopia ou realidade virtual. No so abordados
aspectos da emisso de radiaes ou segurana eltrica dos
equipamentos, cobertos pelas normas IEC.
Esta norma internacional se destina aos profissionais
encarregados de garantir um trabalho de escritrio seguro e
efetivo com os computadores. Seu objetivo promover a sade
e a segurana de usurios de computadores e garantir que eles
possam operar estes equipamentos com eficincia e conforto.
Isso requer um projeto cuidadoso dos terminais de
computadores, dos locais de trabalho e do ambiente nos quais
eles so usados, assim como da organizao e do
gerenciamento do prprio trabalho. As consideraes da
ergonomia so importantes no projeto de qualquer equipamento
usado por seres humanos, mais especialmente quando este uso
intensivo ou se a preciso e a velocidade forem fatores crticos.
Os computadores e seus terminais de vdeo formam uma parte
significativa do trabalho de escritrio e muito freqentemente
determinam o desempenho do usurio em suas atividades.
De uma maneira geral as recomendaes que constam da
ISO 9241 foram definidas por evidncia emprica e a partir da
reviso da literatura existente, sendo ento generalizadas e
formuladas em termos de requisitos para o uso de projetistas e
avaliadores de interfaces. O comit tcnico TC-159, que se
ocupa de ergonomia, e em particular o sub-comit SC 4, que se
ocupa da ergonomia da interao homem-sistema, organizaram
a ISO 9241 em um conjunto de 17 partes, cada uma lidando com
diferentes aspectos do trabalho em escritrios informatizados.
Parte 1: Introduo geral.
Parte 2: Conduo quanto aos requisitos das tarefas.
Parte 3: Requisitos dos terminais de vdeo.
Parte 4: Requisitos dos teclados.
Parte 5: Requisitos posturais e do posto de trabalho.
Parte 6: Requisitos do ambiente.
Parte 7: Requisitos dos terminais de vdeo quanto as
reflexes.
Parte 8: Requisitos dos terminais de vdeo quanto as
cores.
Parte 9: Requisitos de dispositivos de entrada, que no
sejam os teclados.
Parte 10: Princpios de dilogo.
Parte 11: Orientaes sobre usabilidade.
132
Parte 12: Apresentao da informao.
Parte 13: Orientaes ao usurio.
Parte 14: Dilogos por menu.
Parte 15: Dilogos por linguagem de comandos.
Parte 16: Dilogos por manipulao direta.
Parte 17: Dilogos por preenchimento de formulrio.
No que se refere ao equipamento, as recomendaes
tratam somente dos fatores que afetem o desempenho dos
usurios e estejam menos sujeitos s variaes do estado da
tecnologia. Para medir este desempenho a ISO 9241 fornece
indicaes sobre: as caractersticas do equipamento que so
importantes sob o ponto de vista ergonmico, como medir ou
avaliar estas caractersticas, que equipamento de teste utilizar,
como formar uma amostra de usurios apropriada, que
condies experimentais montar e qual o nvel de desempenho
esperar. Como nem sempre possvel realizar estes testes, a
ISO 9241 traz recomendaes que podem ser utilizadas de
modo prescritivo, simplesmente auxiliando na busca dos nveis
esperados de desempenho humano.
As 8 partes que se referem s interfaces de software j so
normas internacionais e encontram-se em fase de traduo para
compor uma norma brasileira correspondente. De fato, a
Comisso de Estudos da ABNT para ergonomia de software foi
instalada em julho de 1999 e prepara-se para lanar a parte 1 da
norma brasileira.
A parte 10 define os 7 princpios de projeto que segundo o
comit tcnico que elaborou esta norma ISO podem levar a uma
interface humano-computador ergonmica. So eles a
adequao tarefa, a auto-descrio, a controlabilidade, a
compatibilidade com as expectativas do usurio, a tolerncia
erros, a adequao para a individualizao e a adequao para a
aprendizagem. Para cada princpio de projeto so apresentadas
recomendaes gerais com exemplos especficos.
A parte 11 refere-se a especificao da usabilidade dos
sistemas, definida como aquelas caractersticas que permitem
que o usurio alcance seus objetivos e satisfaa suas
necessidades dentro de um contexto de utilizao determinado.
Desempenho e satisfao do usurio so especificados e
medidos a partir do grau de realizao de objetivos perseguidos
na interao (eficcia), pelos recursos alocados para alcanar
estes objetivos (eficincia) e pelo grau de aceitao do produto
pelo usurio (satisfao). Esta parte da norma ISO 9241 refora
a idia de que a usabilidade depende do contexto de utilizao, e
que o nvel de usabilidade atingido ser funo das
circunstncias particulares de utilizao do produto. O contexto
de utilizao compreende os usurios, as tarefas, o equipamento
(hardware, software e documentos) e os ambientes fsicos e
sociais suscetveis de influenciar a usabilidade de um produto
133
dentro de um sistema de trabalho. As medidas de desempenho e
de satisfao dos usurios avaliam a qualidade do sistema de
trabalho com todas as suas interligaes. Qualquer mudana
como treinamento adicional ou melhoria de iluminao foram
uma reavaliao da usabilidade do sistema.
A norma ISO 9241-12 lida com a apresentao visual das
informaes atravs de terminais de vdeo. Ela traz princpios
gerais para a apresentao da informao e se refere tanto a
organizao da informao nas telas quanto ao uso de tcnicas
de codificao individual. Suas recomendaes referem-se :
janelas, reas de entradas e sadas, grupos, listas, tabelas,
rtulos, campos, cursores, aspectos sintticos e semnticos de
cdigos alfanumricos, abreviaturas, codificao grfica, cdigos
de cores e outras tcnicas de codificao visual.
A parte 13 se refere conduo ao usurio, vista como o
conjunto de informaes suplementares, portanto adicionais ao
dilogo habitual entre homem-mquina, que so fornecidas sob
comando do usurio ou automaticamente pelo sistema. Os
elementos do sistema de conduo incluem os convites, o
feedback, as informao sobre o estado do sistema, a gesto de
erros e a ajuda em linha. Eles auxiliam a interao do usurio
com o sistema evitando a carga de trabalho mental intil,
fornecendo aos usurios um meio de gesto de erros, alm de
uma assistncia adequada ao seu nvel de competncia. As
recomendaes contidas nesta norma se referem a situaes
tpicas envolvendo necessidades especficas de informaes e
de aes.
As partes 14 a 17 se referem a estilos de dilogo; por
menu, por linguagem de comandos, por manipulao direta e por
preenchimento de campos. As normas fornecem uma estrutura
de recomendaes referentes a pertinncia destes estilos de
dilogo, sobre como realiz-los em seus diferentes aspectos e
como avali-los.
Assim por exemplo os dilogos por menus, tratados pela
parte 14 so aplicveis quando o uso da aplicao no
freqente e quando o conjunto de opes de comandos muito
grande para confi-lo memria de um usurio com um mnimo
de treinamento, sem prtica de digitao e com pouca ou
nenhuma experincia com o sistema. As recomendaes
ergonmicas que esto includas nesta parte da norma se
referem a estrutura dos menus, a navegao dentro desta
estrutura, a seleo e execuo de opes de menu.
A parte 15, trata dos dilogos por linguagem de comandos,
que se aplicam quando a tarefa requerer um rpido acesso a
funes especficas do sistema, onde impossvel fazer
prognsticos em termos das escolhas das aes que o usurio
v precisar e onde os dados ou opes de comandos possam
ser introduzidos em ordem arbitrria. Por seu lado o usurio
134
precisa receber um treinamento formal, fazer uso freqente do
sistema e mostrar habilidades de datilgrafo. As recomendaes
referem-se a estrutura e sintaxe dos comandos, a suas
representaes e as entradas e sadas com este estilo de
dilogo.
Os dilogos por manipulao direta, assunto tratado pela
parte 16, se aplicam quando as entradas forem de difcil
descrio e onde possa existir a possibilidade de construir
metforas com os objetos do mundo fsico que facilitem a
visualizao do sistema. Os recursos dos equipamentos, em
termos de resoluo e velocidade de tratamentos grficos devem
permitir apresentaes e feedback eficientes. O usurio a quem
se destina este tipo de dilogo no apresenta habilidades de
digitao e prefere as representaes grficas s textuais. As
recomendaes da norma se referem a aparncia e a
manipulao de objetos grficos, de texto, de controle e de
janelas.
A parte 17 trata dos dilogos por preenchimento de
formulrios, aplicveis quando as entradas do sistema forem
predominantemente de dados, com uma estrutura rgida e com
poucos comandos. Os usurios deste tipo de dilogo no
precisam de treinamento especfico e suas habilidades de
datilgrafo podem ser moderadas. As recomendaes se
referem a estrutura dos formulrios, as entradas, ao feedback e a
navegao pelos campos.
10.1 Verificando as qualidades ergonmicas
atravs da ISO-9241
Para realizar uma avaliao segundo as partes desta norma
internacional, os analistas devem, antes de tudo, ler a norma e
suas correlatas, conhecer o produto de software, o usurio, a
tarefa, o ambiente e o sistema de trabalho que o produto
pretenda apoiar. O prximo passo estabelecer uma lista de
tarefas a serem usadas na avaliao (as mais importantes e as
mais freqentes, por exemplo) e aplicar a norma. Para tanto
duas abordagens so examinadas. Na abordagem aconselhada
o avaliador utiliza o produto para escolher uma lista de tarefas e
observa o usurio realizando estas tarefas. Cada elemento do
sistema em anlise ser verificado contra as recomendaes
desta norma (ex. conduo ao usurio: convites, informaes
sobre o estado, feedback, mensagens de erros e ajuda em
linha). Convm que os resultados sejam registrados segundo as
rubricas: requisitos inaplicveis, aplicveis e seguidos, aplicveis
mas no seguidos. Na outra abordagem sugerida, o prprio
avaliador utiliza o produto e estuda os elementos do sistema
durante esta utilizao.
A conformidade norma ISO 9241 definida a partir dos
resultados de duas anlises; a de aplicabilidade do quesito e a
135
de aderncia do sistema ao quesito. Muitos dos quesitos
propostos pelas diversas partes desta norma de ergonomia de
software so condicionais, isto devem ser seguidas somente
dentro de um contexto especfico no qual elas so aplicveis:
tipos particulares de usurios, tarefas, ambientes e tecnologia. A
norma prev uma sistemtica para justificar a definio da
aplicabilidade de um quesito, que pode se dar pela evidncia
documentada sobre a tarefa, ou a partir da descrio do sistema
ou por sua simples observao. A aplicabilidade pode ainda ser
decidida com base na avaliao de um expert (avaliao
analtica) ou a partir de procedimentos de testes com usurios
finais (avaliao emprica). Por seu lado, uma deciso sobre a
aderncia do sistema ao quesito deve ser justificada atravs de
diferentes mtodos: por medio, evidncia documentada,
observao, avaliao analtica, avaliao emprica ou outro
mtodo.
Convm que o relatrio da avaliao contenha as tarefas
avaliadas, as recomendaes aplicveis e as recomendaes
seguidas.
136
11. REFERNCIAS BIBLIOGRFICAS
Barthet, M.-F. (1988). Logiciels interactifs et ergonomie: modles et mthodes de
conception (first ed.). Paris: Bordas.
Bass, L., & Coutaz, J. (1991). Developing software for the user interface (first ed.).
Reading, Massachusetts: Addison-Wesley Publishing Company.
Bastien, C. & Scapin , D. (1993). Human factors criteria, principles, and recommandations
for HCI: methodological and standatdisation issues. (Internal Repport). INRIA
Bastien, C. J. (1991). Validation des critres ergonomiques pour l'valuation d'interfaces
utilisateurs. (Rapport de Recherche No. 1427). INRIA.
Bodart, F., & Vanderdonckt, J. (1993a). Encapsulating Knowledge for Intelligent
Automatic Interaction Objects Selection. In A. Wesley (Ed.), INTERCHI'93 - Human
Factors in Computing Systems, 1 (pp. 424 - 429). Amsterdam: ACM Press.
Bodart, F., & Vanderdonckt, J. (1993b). Guide Ergonomique de la prsentation des
applications hautement interactives. (1 ed.). Namur, Belgique: Presses Universitaires
de Namur.
Brown, C. M. (1988). Human-computer interface design guidelines (first ed.). Norwood,
New Jersey: Ablex Publishing Corporation.
Card, S., Moran, T. & Newell, A. (1983). The psychology of human-computer interaction
(first ed.). Hillsdale: Lawrence Erlbaum Associates.
Chevalier, J. (1980). Dictionnaire des symboles (first ed.). Paris: Robert Laffont.
Coutaz, J. (1990). Interfaces homme-ordinateur: conception et ralisation. (first ed.).
Paris: Bordas.
Damodaran, L. (1966). User involvement in the systems design process - a practical
guide for users. Behavior & Information Technology 15(6): 363-377.
Dix, A., Finlay. J., Abowd, G. & Beale, R. (1993) . Human-Computer Interaction, Prentice
Hall International (UK) Limited
Fernandes, T.(1995). Global Interface Design: a guide to designing international user
interfaces. Academic Press Inc.
Foley, J. D. &. V. D., A. (1984). Fundamentals of interactive computer graphics (first ed.).
Massachusets: Addison-Wesley Publishing Company.
Hix, D. & Hartson, H. R. (1993). Developing User Interfaces: Ensuring usability through
product & process. Wiley Professional Computing.
Horton. W. (1994). The Icon Book; visual symbols for computer systems and
documentation. John Wiley & Sons, Inc.
IBM (1989). Systems Application Architecture, Common User Access: Advanced Interface
Design Guide. In Boca Raton: International Business Machines Corp.
ISO 9241 Part 1(1993). Ergonomic requirements for office work with visual display
terminals, Part 1 General Introduction ; International Standard ISO 9241-1
ISO 9241 Part 2(1993). Ergonomic requirements for office work with visual display
terminals, Part 2 Guidance on task requirements ; International Standard ISO 9241-2
137
ISO 9241 Part 3(1993). Ergonomic requirements for office work with visual display
terminals, Part 3 Visual display requirements ; International Standard ISO 9241-3
ISO 9241 Part 10 (1993). Ergonomic requirements for office work with visual display
terminals, Part 10 Dialogue principles ; Draft International Standard ISO 9241-10
ISO 9241 Part 11 (1993). Ergonomic requirements for office work with visual display
terminals, Part 11 Usability Statements ; Draft International Standard ISO 9241-11
ISO 9241 Part 12 (1993). Ergonomic requirements for office work with visual display
terminals, Part 12 Presentation of information ; Draft International Standard ISO 9241-
12
ISO 9241 Part 13 (1993). Ergonomic requirements for office work with visual display
terminals, Part 13 User guidance ; Draft International Standard ISO 9241-13
ISO 9241 Part 14 (1993). Ergonomic requirements for office work with visual display
terminals, Part 14 Menu dialogues ; Draft International Standard ISO 9241-14
ISO 9241 Part 15 (1993). Ergonomic requirements for office work with visual display
terminals, Part 15 Command dialogues ; Draft International Standard ISO 9241-15
ISO 9241 Part 16 (1993). Ergonomic requirements for office work with visual display
terminals, Part 16 Direct Manipulation dialogues ; Draft International Standard ISO
9241-16
ISO 9241 Part 17 (1993). Ergonomic requirements for office work with visual display
terminals, Part 17 Form filling dialogues ; Draft International Standard ISO 9241-
17Laville, A. (1977). Ergonomia (First ed.). So Paulo: Editora Pedaggica e
Universitria Ltda.
Loshe, G., Walker, N., Biolsi, K., & Rueter, H. (1991). Classifying Graphical
INFORMATION. Behaviour and INFORMATION Technology, 10(5), 419-436.
Martin, J. (1992). Hyper documentos e como cri-los. Editora Campus.
Muller M.J., H. J. H., Dayton T. (1997). Participatory Pratices in the Software Lifecycle.
Handbook of Human-Computer Interaction. M. Helander, Landauer, T.K., Prabhu, P.:
255-297.
Norman, D. A. (1984). Cognitive engineering principles in the design of human-computer
interfaces. In G. Salvendy (Eds.), Human Computer Interaction Amsterdam: Elsevier
Science Publisher.
OSF (1990). Motif Style Guide (1.1 ed.). Cambridge, MA: Open Software Foundation.
Pollier, A. (1991). Evaluation d'une interface par des ergonomes: diagnostiques et
stratgies (Rapport de Recherche No. 1391). INRIA.
Powell, E.J. (1990). Designing User Interfaces, Data Based Advisor Series, Ed. Lance A.
Leventhal, Microtrend Books
Ravden, S., & Johnson, G. (1989). Evaluating usability of human-computer interfaces
(first ed.). Chichester: Ellis Horwood Limited.
Richard, J.-F. (1983). Logique du fonctionnement et logique d'utilisation (Rapport de
Recherche No. 202). INRIA.
Richard, J.-F., Bonnet, C., & Ghiglione, R. (1990). Trait de Psychologie Cognitive :
perception, action, langage(premire ed.). Paris: Bordas.
Rivlin, C., Lewis, R., & Davies-Cooper, R. (1990). Guidelines for Screen Design (first ed.).
Cambridge: Blackwell scientif Publications.
138
Rogers, Y. (1989). Icons at the Interface: Their Usefulness. Interacting with Computers,
1(1), 105-117.
Sacre, B., Sacre-Provot, I., & Vanderdonckt, J. (1992). Une description oriente objet des
objets interactifs abstraits utiliss en interfaces homme-machine. (rapport IHM/Ergo
No. 10). Facults Universitaires Notre-Dame de La Paix - Institut d'Informatique -
Projet Trident.
Scapin, D. L. (1986). Guide ergonomique de conception des interfaces homme-machine.
(Rapport de Recherche No. 77). INRIA - Rocquencourt - France.
Scapin, D.L. et al. (1988) - La concption ergonomique d'interfaces: problmes de
mthodes, Rapports de Recherche , Rocquencourt, France: INRIA.
Scapin, D.L. (1989a) - Guidelines for user-interface design: Konwledge collection and
Organisation, Technical Raport TR.D12.1 Version Date 30/12/1989, Rocquencourt,
France: INRIA.
Scapin, D. L. (1989b) - MAD: Une mthode analytique de description des tches. IN:
Colloque sur l'engenirie des interfaces homme-machine, Sophia-Antipolis, France,
INRIA
Scapin, D. L. (1990d). Organizing human factors knowledge for the evaluation and design
of interfaces. International Journal of Human-Computer Interaction, 2(3), 203-229.
Scapin, D.L. (1990a) - Decyphering human-factors recommendations, IN: Karwoski,W. &
Rahimi, M. (Eds). Ergonomics of hybrid automated Systems II, Amsterdam: Elsevier
Science Publisher.
Scapin, D.L. (1990b) - Des critres ergonomiques pour l'valuation et la concption
d'interfaces. IN: Actes du Congres de la SELF, Montral.
Sebillotte, S. (1991). Decrire des tches selon les objetifs des operateurs: de l'interview
la formalisation (Rapport de Recherche No. 125). INRIA.
Shneiderman, B. (1987). Designing the User Interface: strategies for effective human-
computer interaction (first ed.). Addison-Wesley Publishing Company.
Smith, S. (1986). Standards versus guidelines for designing user interface software.
Hehaviour and Information Technology, 5(1), 47-61.
Smith, S. L., & Mosier, J. N. (1986). Guidelines for designing user interface software No.
ESD-TR-86-278). The MITRE corporation.
Valentin, A., & Lucongsang, R. (1987). L'ergonomie des logiciels (first ed.). Paris: ANACT.
Valentin, A., Vallery, G & Lucongsang, R. (1993). L'valuation ergonomique des logiciels;
une dmarche interative de conception (first ed.). Paris: ANACT.
Winograd, T., & Flores, F. (1986). Understanding computers and cognition: a new
foundation for design (first ed.). Norwwod, New Jersey: Ablex Publishing Corporation.