Universidade Federal de Santa Catarina

Programa de Ps-Graduao em Engenharia de Produo

ISO 9241: Uma Proposta de Utilizao da Norma

para Avaliao do Grau de Satisfao de
Usurios de Software

Dissertao submetida Universidade Federal de Santa Catarina como requisito parcial

para obteno do grau de

Mestre em Engenharia de Produo

por
Marco Aurlio Medeiros

Florianpolis, 30 de julho de 1999

ISO 9241: Uma Proposta de Utilizao da Norma para Avaliao

do Grau de Satisfao de Usurios de Software

Marco Aurlio Medeiros

Esta dissertao foi julgada adequada para a obteno do ttulo de Mestre em

Engenharia, especialidade Engenharia de Produo, rea de concentrao
Ergonomia , e aprovada em sua forma final pelo curso de Ps-Graduao da
Universidade Federal de Santa Catarina.

Prof. Walter de Abreu Cybis, Dr.

Orientador

Prof. Ricardo Miranda Barcia, Dr. Ph.D.

Coordenador do Curso de Ps-Graduao

Banca Examinadora

Prof. Neri dos Santos, Dr.

Prof. Vitorio Bruno Mazzola, Dr.

Prof. Walter de Abreu Cybis, Dr.

ii

Dedico este trabalho minha esposa Mrcia e a meus filhos,

Artur e Luiza, motivos da minha existncia e da minha felicidade.

iii

AGRADECIMENTOS

Minha sincera gratido:

minha famlia e de minha esposa, pelo exemplo e apoio;
Diretoria da Softplan, lson, Guto e Marafon, e colaboradores, especialmente Fbio
Miranda, estagirio no DERPR;
Aos Departamentos de Estradas de Rodagem da Bahia, Distrito Federal, Paran e Santa
Catarina;
ao Prof. Dr. Jochen Prmper, BAO Alemanha, pela colaborao fundamental para a
realizao deste trabalho;
ao meu Orientador, Dr. Walter Cybis, pela pacincia e compreenso;
ao Prof. Dr. Wolfgang Gerken, Alemanha, por me fornecer os primeiros artigos sobre o
ISONORM;
ao Prof. Ben Shneiderman, Universidade de Maryland, por destinar parte de seu
precioso tempo para esclarecer algumas das minhas dvidas;
a todos os demais que, de alguma forma, contriburam para a realizao deste trabalho.

iv

S UMRIO
LISTA DE TABELAS.....................................................................................................................IX
LISTA DE ILUSTRAES...........................................................................................................XI
LISTA DE ABREVIATURAS E SIGLAS.....................................................................................XI
RESUMO......................................................................................................................................XII
ABSTRACT..................................................................................................................................XIII
1. INTRODUO............................................................................................................................1
1.1. JUSTIFICATIVAS......................................................................................................................... 2
1.1.1. A Interao Homem-Computador: Quantidade e Qualidade............................................ 3
1.1.2. Desenvolvimento de Software: O Custo da Interface.......................................................5
1.1.3. O Papel Econmico da Produo de Software .................................................................6
1.1.4. Usabilidade e Engenharia de Software .............................................................................7
1.1.5. A Importncia das Normatizao Internacional...............................................................9
1.2. O BJETIVOS ............................................................................................................................... 12
1.3. PREMISSAS.............................................................................................................................. 12
1.4. METODOLOGIA DE TRABALHO ................................................................................................. 13
1.5. ESTRUTURA DO TRABALHO ..................................................................................................... 14
2. CRITRIOS/PRINCPIOS ERGONMICOS PARA SOFTWARE.....................................16
2.1. AS OITO REGRAS DE OURO DE S HNEIDERMAN ......................................................................... 16
2.1.1. Consistncia..................................................................................................................... 17
2.1.2. Habilitao de Atalhos para Usurios Freqentes ......................................................... 18
2.1.3. Feedback Informativo..................................................................................................... 18
2.1.4. Dilogos com Encerramento Evidente............................................................................ 18
2.1.5. Preveno e Tratamento Simplificados de Erros............................................................ 19
2.1.6. Fcil Reverso das Aes................................................................................................ 19
2.1.7. Suporte ao Controle por parte do Usurio ..................................................................... 20
2.1.8. Reduo da Carga da Memria de Curto Termo............................................................ 20
2.2. O S PRINCPIOS HEURSTICOS DE NIELSEN................................................................................. 20
2.2.1. Visibilidade do Estado do Sistema...................................................................................22
2.2.2. Compatibilidade entre Sistema e Mundo Real................................................................. 22
2.2.3. Liberdade e Controle do Usurio.................................................................................... 22
2.2.4. Consistncia e Padres.................................................................................................... 22
2.2.5. Preveno de Erro...........................................................................................................23
2.2.6. nfase no Reconhecimento ..............................................................................................23
2.2.7. Flexibilidade e Eficincia no Uso.................................................................................... 23
2.2.8. Esttica e Projeto Minimalistas.......................................................................................23
2.2.9. Auxlio ao Reconhecimento, Diagnstico e Recuperao de Erros................................. 24
2.2.10. Help e Documentao.................................................................................................... 24
2.3. PRINCPIOS DE P ROJETO CENTRADO NO USURIO MICROSOFT................................................. 24
2.3.1. Usurio no Controle........................................................................................................ 25
v

2.3.2. Objetividade (Directness)................................................................................................ 25

2.3.3. Consistncia..................................................................................................................... 25
2.3.4. Tolerncia (Forgiveness)................................................................................................. 26
2.3.5. Feedback ......................................................................................................................... 27
2.3.6. Esttica............................................................................................................................ 27
2.3.7. Simplicidade..................................................................................................................... 27
2.4. PRINCPIOS IBM ...................................................................................................................... 28
2.4.1. Simplicidade..................................................................................................................... 28
2.4.2. Suporte............................................................................................................................. 29
2.4.3. Familiaridade ..................................................................................................................29
2.4.4. Obviedade........................................................................................................................ 29
2.4.5. Encorajamento................................................................................................................ 30
2.4.6. Satisfao ........................................................................................................................ 30
2.4.7. Acessibilidade ..................................................................................................................30
2.4.8. Segurana........................................................................................................................ 31
2.4.9. Versatilidade.................................................................................................................... 31
2.4.10. Personalizao...............................................................................................................32
2.4.11. Afinidade........................................................................................................................ 32
2.5. C RITRIOS ERGONMICOS DE BASTIEN E S CAPIN..................................................................... 33
2.5.1. Conduo......................................................................................................................... 33
2.5.1.1. Presteza ........................................................................................................................ 33
2.5.1.2. Agrupamento/Distino de Itens ..................................................................................34
2.5.1.2.1. Agrupamento/Distino por Localizao ..................................................................34
2.5.1.2.2. Agrupamento/Distino por Formato .......................................................................35
2.5.1.3. Feedback Imediato.......................................................................................................35
2.5.1.4. Legibilidade ..................................................................................................................35
2.5.2. Carga de Trabalho ..........................................................................................................35
2.5.2.1. Brevidade ......................................................................................................................36
2.5.2.1.1. Conciso.................................................................................................................... 36
2.5.2.1.2. Aes Mnimas ...........................................................................................................37
2.5.2.2. Densidade Informacional..............................................................................................37
2.5.3. Controle Explcito ...........................................................................................................38
2.5.3.1. Aes Explcitas do Usurio......................................................................................... 38
2.5.3.2. Controle do Usurio..................................................................................................... 38
2.5.4. Adaptabilidade................................................................................................................. 39
2.5.4.1. Flexibilidade................................................................................................................. 39
2.5.4.2. Experincia do Usurio................................................................................................ 39
2.5.5. Gesto de Erros ...............................................................................................................40
2.5.5.1. Proteo contra Erros ..................................................................................................40
2.5.5.2. Qualidade das Mensagens de Erros..............................................................................41
2.5.5.2. Correo de Erros........................................................................................................ 41
2.5.6. Consistncia..................................................................................................................... 41
2.5.7. Significado dos Cdigos ..................................................................................................42
2.5.8. Compatibilidade ..............................................................................................................42
2.6. C ONCLUSES ........................................................................................................................... 43
3. MTODOS DE AVALIAO DE USABILIDADE...............................................................44
vi

3.1. REVISES ESPECIALIZADAS ..................................................................................................... 45

3.1.1. Avaliao Heurstica .......................................................................................................46
3.1.2 Reviso usando Guias de Recomendaes .......................................................................47
3.1.3. Inspeo de Consistncia................................................................................................. 47
3.1.4. Navegao Cognitiva......................................................................................................48
3.1.5. Inspees Formais ...........................................................................................................48
3.2. TESTES E ESTUDOS LABORATORIAIS........................................................................................ 49
3.3. PESQUISAS DE O PINIO (S URVEYS) ........................................................................................... 50
3.4. TESTES DE ACEITAO............................................................................................................ 52
3.5. AVALIAO DURANTE O USO ATIVO....................................................................................... 53
3.6. EXPERIMENTAO P SICOLOGICAMENTE O RIENTADA .............................................................. 55
3.7. C ONCLUSES ........................................................................................................................... 55
4. A NORMA ISO 9241..................................................................................................................57
4.1. ISO 9241-10: PRINCPIOS DE DILOGO.................................................................................... 59
4.1.1. Adequao Tarefa......................................................................................................... 60
4.1.2. Auto-descrio................................................................................................................. 62
4.1.3. Controlabilidade ..............................................................................................................64
4.1.4. Conformidade com as Expectativas do Usurio............................................................. 65
4.1.5. Tolerncia a Erros ...........................................................................................................67
4.1.6. Adequao Individualizao ......................................................................................... 68
4.1.7. Adequao ao Aprendizado............................................................................................. 69
4.2. ISO 9241-11: CONDUO DA USABILIDADE .......................................................................... 70
4.3. ISO 9241-12: APRESENTAO DA INFORMAO ................................................................... 71
4.4. ISO 9241-13: CONDUO DO USURIO.................................................................................. 72
4.5. ISO 9241-14: DILOGOS DE MENU ......................................................................................... 72
4.6. ISO 9241-15: DILOGOS DE COMANDO .................................................................................. 73
4.7. ISO 9241-16: DILOGOS DE MANIPULAO DIRETA .............................................................. 74
4.8. ISO 9241-17: DILOGOS DE PREENCHIMENTO DE FORMULRIOS ............................................ 75
4.9. C ONCLUSES ........................................................................................................................... 77
5. O QUESTIONRIO ISONORM 9241/10 ................................................................................ 79
5.1. A ESTRUTURA DO QUESTIONRIO ........................................................................................... 80
5.2. APLICABILIDADE DO QUESTIONRIO ....................................................................................... 82
5.2.1. Comparando Interfaces Grfica e Modo Caracter......................................................... 82
5.3. C ONFIABILIDADE DO QUESTIONRIO ....................................................................................... 84
5.4. C ORRELAO COM O UTROS QUESTIONRIOS ......................................................................... 85
5.4.1. ISONORM X QUIS...........................................................................................................86
5.4.2. ISONORM X EVADIS II...................................................................................................86
5.5. C ONCLUSES ........................................................................................................................... 86
6. INSPEO DE USABILIDADE BASEADA EM INDICADORES DE SATISFAO.....88
6.1. PESQUISA DE SATISFAO E SEUS RESULTADOS...................................................................... 89
6.1.1. As Caractersticas da Amostra Populacional................................................................. 90
6.1.2. ISONORM X Questionrio Softplan: Comparao dos Resultados ................................ 91
6.1.3. Princpios da Norma: Grau de Satisfao dos Usurios ................................................ 94
6.2. REFERNCIA CRUZADA DE RECOMENDAES ......................................................................... 96
vii

6.3. REALIZAO DA INSPEO..................................................................................................... 97

6.3.1. Identificao das Falhas relativas Tolerncia a Erros................................................. 98
6.3.2. Identificao das demais Falhas de Usabilidade ..........................................................102
6.4. CONCLUSES ......................................................................................................................... 102
7. CONCLUSES .........................................................................................................................104
7.1. RECOMENDAES PARA TRABALHOS F UTUROS .................................................................... 106
ANEXO 1 - TRADUO DO QUESTIONRIO ISONORM .................................................108
ANEXO 2 - MODELO DE QUESTIONRIO DA SOFTPLAN...............................................117
ANEXO 3 - MATRIZ DE REFERNCIA QUESTO ISONORM X RECOMENDAO.119
REFERNCIAS BIBLIOGRFICAS ........................................................................................127

viii

L ISTA DE T ABELAS

Tabela 1.1 Percentual de uso do computador pelos trabalhadores dos E.U.A.........................04

Tabela 1.2 Principais mtodos utilizados para a preveno de defeitos no Brasil...................09
Tabela 4.1 Partes da Norma ISO 9241 ......................................................................................57
Tabela 4.2 Assuntos abordados pelas partes da Norma ISO 9241 ..........................................57
Tabela 4.3 Relao entre as partes da ISO 9241 que abordam a Usabilidade ........................ 58
Tabela 5.1 Exemplo de questo do ISONORM 9241/10 ..........................................................81
Tabela 5.2 Tabela de equivalncia entre as notas e os conceitos.............................................83
Tabela 5.3 Tabulao das mdias obtidas pelos produtos com e sem interface grfica..........84
Tabela 5.4 Confiabilidade do Questionrio [PRUMPER 99].................................................... 85
Tabela 6.1 Distribuio geogrfica da amostra .........................................................................90
Tabela 6.2 Distribuio da amostra pelo tempo de experincia na atividade ..........................90
Tabela 6.3 Distribuio da amostra pelo tempo de experincia em informtica......................91
Tabela 6.4 Distribuio da amostra pelo tempo de experincia no produto avaliado..............91
Tabela 6.5 Distribuio da amostra pela freqncia de uso do produto avaliado.................... 91
Tabela 6.6 Frmulas utilizadas ...................................................................................................92
Tabela 6.7 Sumrio da amostra por tempo de experincia na atividade ..................................92
Tabela 6.8 Sumrio da amostra por tempo de experincia em informtica..............................93
Tabela 6.9 Sumrio da amostra por freqncia semanal de us o do programa.........................93
Tabela 6.10 Sumrio da amostra por tempo de experincia no produto...................................93
Tabela 6.11 Mdias das notas obtidas pelas questes relativas Tolerncia a Erros ...........96
Tabela 6.12 Exemplo de referncia das recomendaes relativas s questes ISONORM ..96
Tabela 6.13 Prioridades atribudas s questes relativas gesto de erros............................ 99
Tabela 6.14 Resultados da inspeo a partir das questes relativas Tolerncia a Erros.... 99
Tabela 6.15 Resultados da inspeo usando as questes restantes da matriz .......................100

ix

L ISTA DE ILUSTRAES

Grfico 6.1 Mdias das notas obtidas pelos princpios da norma .............................................95

LISTA DE ABREVIATURAS E S IGLAS

CEN

Organizao de Padronizao Europia

IBM

International Business Machine

ISO

International Organization for Standardization

LabIUtil

- Laboratrio de Utilizabilidade

MCT

- Ministrio da Cincia e Tecnologia

MUSIC

Metrics for Usability Standards in Computing

QUIS

Questionnaire for User Interaction Satisfaction

SEPIN

- Secretaria de Poltica de Informtica e Automao

SOFTEX

- Sociedade Brasileira para Promoo da Exportao de Software

SUMI
UFSC

Software Usability Measurement Inventory

- Universidade Federal de Santa Catarina

xi

R ESUMO

Este trabalho apresenta uma proposta de utilizao da norma ISO 9241/10 Ergonomic Requirements
for Office Work with Visual Display Terminals (VDTs) - para a determinao do grau de satisfao de
usurios com relao a produtos de software.
A principal crena que motiva esta proposta reside na idia de que o usurio de programas de computador
enxerga as qualidades do produto atravs dos recursos de interao. No basta que o produto possua
grande preciso, fundamental que o usurio possa usufruir desta preciso. E, para isso, a facilidade de
utilizao ou o alto grau de usabilidade pr-requisito importantssimo.
Como pde ser comprovado pelos experimentos relatados neste trabalho, mediante a aplicao de
questionrios dirigidos para o usurio final, pode-se obter, com razovel grau de preciso, indicadores do
nvel de satisfao dos clientes. Se o questionrio tiver como base as recomendaes ergonmicas da
norma, poder-se- fazer uso dos princpios de dilogo previstos na norma para classificar indicadores de
satisfao do usurio com relao a sete critrios ergonmicos importantes: Adequao Tarefa, Autodescrio, Controlabilidade, Conformidade com as Expectativas do Usurio, Tolerncia a Erros,
Adequao Individualizao e Adequao ao Aprendizado. Estes indicadores podero auxiliar na
identificao dos aspectos do produto cujas aes de interveno devero ser priorizadas.
Adicionalmente, os prprios indicadores de satisfao podero evidenciar os provveis focos de
problemas ergonmicos, orientando o processo de inspeo de usabilidade e facilitando a identificao e
correo das falhas.
A aplicao freqente do ciclo avaliao de satisfao inspeo correo permite estabelecer um
processo de melhoria contnua do produto, o que reflete em maior qualidade para o usurio final.

xii

ABSTRACT

This work introduces a suggestion for using the ISO 9241/10 standard Ergonomic Requirements
for Office Work with Visual Display Terminals (VDTs) to evaluate user satisfaction related to
software products.
The main belief where this approach is based on is: the software user perceives the product
qualities through the interaction resources. Precision is not enough. For the user, enjoying this
precision is essencial. So, adequate usability is an important requirement.
As this work has proved, applying user-oriented questionnaires, one may obtain satisfaction-level
indicators with good statistical precision. ISO 9241-based questionnaires may offer conditons to
classify satisfaction indicators on seven important ergonomic criteria: Suitability for the task, Self descriptioness, Controllability, Conformity with User Expectations, Error Tolerance, Suitability for
Individualization and Suitability for Learning. These indicatores may help on the identification of
the software aspects whose intervention actions are emergencial.
Besides, the indicators themselves may clarify eventual focus of usability troubles. After identifying
these critical spots, the usability inpection and the fail correction processes may be easier.
The cyclical application of evaluation inspection correction process may be an interesting tool
for continuous improvement of the product, resulting a higher quality software.

xiii

1. INTRODUO

Durante dcadas o desenvolvimento de software tem-se concentrado nos aspectos estruturais

e de funcionamento do produto. A interface de utilizao, ou Interface Homem-Computador, usualmente
tem seu projeto significativamente influenciado pelo funcionamento. Com bastante freqncia, o projeto da
interface de utilizao de produtos prioriza a facilidade de implementao ante facilidade de utilizao
[MEDEIROS 94].
Como este trabalho procura demonstrar, nem mesmo as tcnicas bsicas de estruturao de
projetos de software so seguidas em sua plenitude pelos desenvolvedores. Menor importncia ainda
recebe o projeto de interfaces de utilizao. As tcnicas de projeto centrado no usurio so pouco
adotadas pelos produtores de software, especialmente no Brasil.
O resultado imediato desta abordagem a frustrao dos usurios diante da dificuldade de
obter no software o apoio necessrio para a execuo de suas tarefas, o que, em situaes extremas, leva
ao abandono do produto.
Tcnicas de avaliao e teste da usabilidade podem vir a auxiliar o setor de desenvolvimento de
software a alcanar um grau de satisfao maior dos usurios de programas de computador. A partir da
identificao de falhas nos diversos estgios de desenvolvimento, pode-se aproximar as caractersticas dos
produtos s demandas dos usurios.
A ateno crescente para estas questes tem levado discusso de padres internacionais de
ergonomia, incluindo padres normativos, que permitam ser possvel comunidade de desenvolvedores e
usurios instrumentalizar a avaliao das qualidades operacionais mnimas dos produtos de software. Um
destaque importante nesta rea a norma internacional ISO 9241 Ergonomic Requirements for Office
Work with Visual Display Terminals (VDT), que abrange, em suas 17 partes, questes relativas ao
hardware, ambiente, tarefa e software.
Esta discusso pode vir a auxiliar sobremaneira as empresas desenvolvedoras de software
cujos sistemas da qualidade buscam ou esto em conformidade com as normas ISO srie 9000. A ttulo
de exemplo, pode-se destacar :

o requisito 4.20 Tcnicas Estatsticas que requer das empresas desenvolvedoras de

software, alm da avaliao da capacidade de processo, tambm a avaliao da satisfao
dos clientes com relao ao produto.

O requisito 4.1 Responsabilidade da Administrao solicita uma poltica da qualidades

coerente com as metas organizacionais do fornecedor e com as necessidades de seus
clientes.

A adoo de mtodos regulares de inspeo de usabilidade centrados em quest ionrios pode

vir a auxiliar no atendimento destes requisitos.
O tema central desta dissertao a adoo de questionrios de inspeo normativa da
usabilidade como alternativa para a avaliao da satisfao dos clientes com relao aos produtos de
software.

1.1. JUSTIFICATIVAS

Um estudo abordando questes relativas avaliao normativa da usabilidade de software,

justifica-se, basicamente, pelos seguintes aspectos:
a) a interao homem-computador crescente e inevitvel, mas ainda est longe de ser
considerada satisfatria: grande parte da transformao da sociedade moderna baseia -se
no uso do computador, mas, medida em que o computador dissemina-se nas atividades
profissionais e de lazer, mais evidentes so as necessidades de facilitar a forma de
utilizao;
b) o custo do desenvolvimento de software vem sofrendo alteraes marcantes na sua
composio. O projeto da interface de utilizao absorve cada vez mais tempo e recursos,
sejam eles humanos, financeiros ou fsicos;
c) o desenvolvimento de software hoje um grande negcio, muito importante para a
economia de diversos pases: especialmente a automao de escritrios, foco deste estudo,
aps um longo perodo de crescimento, comea a mostrar sinais de saturao. A facilidade

de utilizao poder ser o diferencial que determinar os sobreviventes deste mercado que
comea a entrar em franca disputa por espaos;
d) embora a Engenharia de Software disponha de tcnicas e metodologias de
desenvolvimento em nmero cada vez maior, pequena a quantidade de empresas que
adotam, de maneira consistente e integral, uma abordagem organizada para a produo de
seus programas, especialmente no que se refere ao projeto centrado no usurio;
e) a globalizao da economia exigir, cada vez mais, que as empresas produtoras de
software busquem padres internacionais de desenvolvimento e certificao de seus
produtos: a norma ISO-9241 tende a se tornar um destes padres, seno de certificao,
pelo menos de recomendaes de projeto e de avaliao. Paralelamente, a adequao dos
sistemas da qualidade das empresas de desenvolvimento de software s normas ISO srie
9000 demanda uma constante preocupao com a avaliao da satisfao dos clientes. Por
exemplo, no requisito 4.20 das normas ISO 9001, 9002 e 9003, requerida a adoo de
tcnicas estatsticas para mensurao da satisfao dos clientes com relao aos produtos e
servios fornecidos. Segundo [SHNEIDERMAN 98], a aplicao de questionrios uma
das mais adequadas tcnicas para mensurao da satisfao subjetiva. A utilizao de
questionrios de avaliao baseados em critrios normativos merece um atencioso estudo
de seus resultados.
Cada um destes aspectos ser discutido de maneira mais aprofundada a seguir.

1.1.1. A Interao Homem-Computador: Quantidade e Qualidade

Na dcada de 50, previa-se que 10 computadores teriam capacidade para atender a todas as
necessidades de processamento de dados dos Estados Unidos. Naquela poca, um sistema de
computador tinha seu custo distribudo em 90% para hardware e o resto para o software. Atualmente
esta diviso exatamente o oposto. Como resultado, os computadores tornam-se cada vez mais presentes
em nossas vidas. Em 1991, uma pesquisa apontava que 15% dos lares americanos possuam
computadores [EBERTS 94]. J em 1996, pesquisa da Dataquest [SCHAUB 96] indicava que 43% dos
lares americanos possuam computadores: um crescimento de quase 200% em 5 anos. Pode-se,
3

equivocadamente, afirmar que, em sua maioria, estes computadores domsticos no sejam objeto de uso
intensivo, destinando-se primordialmente a jogos, pequenos trabalhos escolares e navegao na Internet.
Analisemos ento dados do U.S. Census Bureau, relativos ao uso do computador por parte da
fora de trabalho norte-americana:
Fora de Trabalho (%)
Ocupao

1984

1989

Gerencial, Profissional

39,0

56,2

Vendas, Suporte Administrativo

38,7

55,1

6,2

10,2

10,3

15,3

Servios
Produo, projeto e reparo

Operadores
5,5
9,5
Tabela 1.1 Percentual de uso do computador pelos trabalhadores dos E.U.A
A interao homem-computador inevitvel: est nos quiosques de informao e de
atendimento bancrio, no equipamento de ultra-sonografia do mdico e nos jogos dos adolescentes.
Enquanto os computadores pessoais destinavam-se principalmente a atividades de lazer, de meados da
dcada de 70 a incio da dcada de 80, discusses sobre questes ergonmicas no resultavam em
impacto significativo no dia-a-dia das pessoas.
Hoje, porm, os computadores tornam-se mais e mais importantes no espao de trabalho. To
difundida quanto o prprio computador no dia-a-dia a idia que a informtica agiliza e facilita a execuo
das tarefas originalmente manuais.
No entanto, [EBERTS 94] relata estudos, que concluem que interfaces projetadas de maneira
incorreta fazem com que essa no seja uma verdade absoluta. Por essa razo, algumas vezes a execuo
de uma tarefa informatizada mais difcil e consome mais tempo :

[HANSEN 78] relata que estudantes que fizeram provas informatizadas levaram, em mdia,
o dobro do tempo que levariam para fazer o mesmo teste usando lpis e papel:
questionados quanto razo do tempo extra, os estudantes responderam que o gastaram
4

tentando descobrir como usar o computador. Em ensaios parecidos, [KOZAR 78]

mencionou que os estudantes necessitaram de tempo extra para decidir se uma informao
relevante era apresentada na tela do computador ou no papel;

[GOULD 81] analisando o trabalho de usurios de computador, chegou concluso que

escrever uma carta em um processador de texto requer at 50% a mais de tempo do que
escrever mo.

enganoso acreditar que estes estudos, j bastante antigos, no reflitam a realidade do

software moderno, concebido para ser utilizado com interface grfica e ser suportado por hardware
dotado de maiores recursos. [PRUMPER 93] demonstra que o panorama atual no muito diferente: em
uma pesquisa baseada em um questionrio centrado na norma ISO 9241-10, 350 usurios de software
na Alemanha expressaram suas opinies com relao interface de utilizao de alguns produtos que
possuam interface grfica e outros que possuam interfaces tradicionais. Embora as avaliaes dos
produtos com interface grfica tenham sido mais positivas, os resultados alcanados deixaram muito a
desejar.

1.1.2. D ESENVOLVIMENTO DE SOFTWARE : O C USTO DA INTERFACE

[WEISE 98] afirma que o conhe cimento necessrio para fazer com que os programas de
computador sejam mais fceis de se utilizar j existe h mais de 15 anos, mas as empresas no investem o
necessrio.
[SMITH 84] estimava, na dcada de 80, que a interface com o usurio requeria de 30 a 35%
do total de linhas de cdigo. [MACINTYRE 90], j na dcada de 90, estimava um crescimento para
nmeros variando entre 47 e 60%. [ROSENBERG 89] afirma que 29% do custo do desenvolvimento de
software dotado de interface grfica destinam-se justamente interface com o usurio.
Outras estatsticas permitem estimar os custos da interface com o usurio: [WEISE 98]
menciona dados relativos avaliao de usabilidade aplicada pela Microsoft no desenvolvimento do MSOffice 97 - foram investidas 25.000 horas de teste de facilidade de uso em trs anos de projeto. Nem
assim, no entanto, o produto est livre das queixas dos usurios, muitas delas registradas em um site
Internet criado especificamente para este fim.
5

1.1.3. O Papel Econmico da Produo de Software

A produo de software tem um papel importantssimo para a economia de diversos pases. O

mercado de informtica brasileiro o maior da Amrica Latina, alcanando 12,7 bilhes de dlares em
1996, distribudos em hardware (50%), servios (32%) e software (18%) [COSTA 97]. Dados recentes
da Fundao SOFTEX - Sociedade Brasileira para Promoo da Exportao de Software - demonstram
um crescimento na exportao de produtos brasileiros de software. O volume de exportao, que era 27
milhes de dlares, em 1997, alcanou 40 milhes em 1998, um crescimento de 48%. Estima -se para
1999 um volume prximo a 60 milhes de dlares.
[EBERTS 94] estima que, na colossal economia americana, a informtica includos software,
hardware e servios - seja um ramo de negcios representando aproximadamente 500 bilhes de dlares.
[WEBER 97] demonstra que o setor de software atinge um faturamento mundial de 250 bilhes de
dlares ao ano.
Nos anos 80, a economia americana registrou um crescimento mdio anual de 20% no setor de
informtica. Desde ento, este crescimento estabilizou-se em 6% ao ano. Obviamente, como em qualquer
ramo industrial, as taxas de crescimento tendem a reduzir medida em que o setor amadurece. Portanto, a
reduo destas taxas de crescimento no pode ser atribuda exclusivamente dificuldade encontrada na
utilizao dos produtos de software.
A nfase na facilidade de utilizao, ainda citando [EBERTS 94], pode dar nova vitalidade
industria de informtica americana.
Paralelamente, investimentos na facilidade de utilizao do software tendem a produzir
elevao dos ndices de produtividade de outros setores da economia. [WEISE 98] menciona estudos que
sugerem que, se todos os programas fossem projetados para facilitar o uso, a produtividade do setor de
servios cresceria entre 4 e 9% ao ano.
Estatsticas americanas indicam que a produtividade nos escritrios cresceu em mdia, desde
1973, 7% ao ano. No mesmo perodo, a produtividade nas fbricas cresceu 51% ao ano[EBERTS 94].
Considerando-se a conhecida migrao da fora de trabalho do setor industrial para o de servios, a
melhoria dos aspectos ergonmicos do software adquire papel econmico de relevncia.
6

1.1.4. Usabilidade e Engenharia de Software

Usado pela primeira vez em 1968, em Garmisch, Alemanha, durante um workshop destinado
aos crescentes problemas da tecnologia de software, o termo Engenharia de Software nomeia a
disciplina tecnolgica preocupada com a produo e manuteno sistemtica de produtos de software,
desenvolvidos e modificados dentro de prazos e custos estimados [FARLEY 85].
Envolvendo a aplicao prtica de conhecimento cientfico no projeto e construo de
programas de computador e a documentao requerida para desenvolver, operar e mant-los [BOEHM
76], so objetivos da Engenharia de Software:
- melhorar a qualidade dos produtos de software;
- aumentar a produtividade e satisfao no trabalho dos engenheiros de software.
Sob o ponto de vista da Engenharia de Software, um produto pode ter sua qualidade avaliada
a partir de um conjunto de requisitos fundamentais [JENSEN 78]:
. Confiabilidade: o produto deve realizar com preciso as funes requeridas pelo usurio sob
condies normais;
. Testabilidade: caracterstica conferida a produtos que esto estruturados e definidos de tal
modo que seu desempenho pode ser avaliado contra a definio de requisitos do usurio numa maneira
quantitativa;
. Manutenibilidade: o produto deve ser facilmente compreendido por programadores de
manuteno, de forma a permitir retificaes, expanses e portes;
. Eficincia: a caracterstica de efetuar as tarefas solicitadas pelo usurio gastando o mnimo de
recursos computacionais;
. Compreensibilidade: o produto deve ser inteligvel a ponto de o usurio facilmente entender o
funcionamento e o relacionamento com outros produtos ou componentes do sistema;

. Adaptabilidade: a caracterstica de permitir que o produto funcione em computadores

diferentes, mas similares, cooperando com outros produtos sem a necessidade de reestruturaes
marcantes.
A natureza do produto determina quais requisitos de qualidade tm maior importncia e quais
tm menor.
Note-se, neste ponto, que entre os requisitos de qualidade de software no h meno clara
que determine uma efetiva preocupao com a facilidade de utilizao [MEDEIROS 98]. O requisito
compreensibilidade, por exemplo, procura garantir ao usurio a possibilidade de entender o funcionamento
do produto, uma forte priorizao da lgica de funcionamento com relao lgica de utilizao.
Entende-se, por esta definio, que o software como produto acabado deva ser um elemento
esttico, mas dotado de funcionamento to compreensvel que o usurio possa se adaptar a forma de
utiliz-lo. Esta viso contraria os preceitos ergonmicos mais elementares, que sugerem que o
funcionamento do software deva ser adaptado forma de utilizao mais satisfatria para o usurio.
Esta abordagem de desenvolvimento, que no evidencia uma preocupao real no que se refere
forma de utilizao do produto, pode ser constatada no dia-a-dia das empresas desenvolvedoras de
software. Estudo feito pelo Ministrio da Cincia e Tecnologia sobre Qualidade no Setor de Software
Brasileiro [MCT 97] demonstra a pouca preocupao com o desenvolvimento de produtos adequados ao
uso. A tabela 1.2, extrada desta pesquisa, mostra a tabulao dos dados de 589 empresas no que se
refere a mtodos utilizados para preveno de defeitos:
Categorias

Nmero de Empresas

Controles de verso

327

55,5

Prototipao

259

44,0

Gerncia de projetos

235

39,9

Mtodos orientados a objetos

216

36,7

Mtodos estruturados

210

35,7

Anlise de requisitos

209

35,5

Projetos da interface com o usurio

207

35,1

Anlise crtica conjunta

194

32,9

Tabela 1.2 Principais mtodos utilizados para a preveno de defeitos no Brasil

Algumas observaes podem ser feitas a partir destes dados:
-

a construo de prottipos uma das tcnicas mais recomendadas para desenvolvimento

de software efetivamente adequado utilizao [EBERTS 94] [BASS 91] [STEWART
95]. No entanto, a quantidade de empresas que a utilizam no chega a 50% das respostas;

a falta de abordagem centrada no usurio evidenciada pela baixa representatividade do

projeto de interface com o usurio entre as respostas obtidas.

1.1.5. A Importncia das Normatizao Internacional

Nos ltimos anos, instituies reguladoras, reconhecendo a importncia da ergonomia no uso e

projeto de equipamentos de terminais de vdeo, tm desenvolvido padres, guias e regulamentaes que
visam proteger a sade, segurana, conforto e eficincia dos usurios de computador.
Os padres ergonmicos exercem um importante papel no aprimoramento da usabilidade dos
sistemas, atravs da melhoria da consistncia da interface com o usurio e da qualidade ergonmica dos
componentes [STEWART 95]. Estes padres ajudam os projetistas a obter sistemas e componentes que
podem ser usados de maneira eficaz, eficiente, segura e confortvel. Tambm auxiliam a reduzir a
desnecessria variedade de software e hardware, assegurando que os benefcios de quaisquer variaes
sejam plenamente justificveis levando em conta critrios como os custos da incompatibilidade, perda de
eficincia do usurio e aumento do tempo de treinamento dos usurios.
A ISO Organizao Internacional de Padronizao desenvolve, atualmente, padres
ergonmicos internacionais para equipamentos dotados de terminais de vdeo. O padro cuja discusso
encontra-se em estado mais adiantado a norma internacional ISO 9241 Ergonomic Requirements for
Office Work with Visual Display Terminals (VDT), que abrange, em suas 17 partes, questes relativas
ao hardware, ambiente, tarefa e software.

10

Paralelamente, outros padres, que focalizam ainda mais os aspectos relativos ao software,
encontram-se em desenvolvimento:
-

ISO 14915 - Multimedia User Interface Design - Ergonomic Requirements for humancentred multimedia interfaces;

ISO 11064 - Ergonomic Design of Control Centres;

ISO 13407 - Human-Centred Design Process for Interactive Systems.

Este trabalho tem impacto direto no setor de desenvolvimento de software, por duas razes
[SYSCON 99]:
-

os maiores fornecedores de software so grandes corporaes que atuam no mercado

internacional. Por isso, as melhores e mais efetivas solues tm que ter aplicabilidade
internacional;

a CEN Organizao de Padronizao Europia optou por adotar as padronizaes da

ISO no mercado interno da Comunidade Econmica Europia. A padronizao da CEN
substitui padres nacionais na Unio Europia e nos pases membros da rea de Livre
Comrcio Europia. Esta diretiva pode tornar-se uma dificuldade adicional no caso de
empresas brasileiras exportadoras de software.

No setor de informtica, como nos demais setores da economia, perceptvel a tendncia de

busca da conformidade dos sistemas da qualidade com as normas da srie ISO 9000. Dados do SEPIN
[SEPIN 99], de fevereiro de 1999, apontam 166 empresas de informtica, das quais aproximadamente 40
atuando no desenvolvimento de software, com seus sistemas da qualidade auditados e em conformidade
com a norma ISO 9001 ou 9002.
No requisito 4.20, demanda-se do fornecedor o estabelecimento de tcnicas estatsticas que
mensurem a capacidade de processo [MARANHO 94] e, mais recentemente, os indicadores de
satisfao dos clientes com relao aos produtos e servios fornecidos. A opo preferencial para suprir
este requisito a adoo de questionrios de avaliao de satisfao ad-hocs que privilegiam critrios
empricos.

10

11

A substituio destes critrios empricos pela avaliao normativa, como a ISO 9241, por
exemplo, tende a permitir:
-

classificar os indicadores de satisfao obtidos: pode-se, alm de obter um indicador geral,

determinar indicadores para cada critrio descrito na norma (Adequao Tarefa, Autodescrio, Controlabilidade, Conformidade com as Expectativas do Usurio,
Tolerncia a Erros, Suporte Individualizao, Adequao ao Aprendizado);

determinar metas para os graus de satisfao globais e de cada critrio;

atuar pontualmente: ao se detectar indicadores com graus de satisfao indesejveis, podese buscar formas de atuao especfica sobre os critrios considerados insatisfatrios, de
forma a reduzir as falhas;

abordagem metdica: a partir da correlao entre as partes da norma, pode-se buscar

mecanismos para elevar os indicadores. Por exemplo, se o indicador de controlabilidade de
um produto que utiliza a metfora de formulrios estiver abaixo dos nveis desejados, podese buscar amparo na parte 17 da norma, que trata de preenchimento de formulrios, para
identificar as falhas apresentadas e alternativas de correo.

1.2. OBJETIVOS

O objetivo deste trabalho propor a adoo de tcnicas de inspeo de usabilidade baseadas

em questionrios dirigidos aos usurios como ferramenta para a avaliao da satisfao de clientes de
produtos de software.
Mais especificamente, pretende-se:
-

sugerir um modelo de questionrio de avaliao de satisfao baseado na norma ISO 9241

(Ergonomic Requirements for Office Work with Visual Display Terminal VDT), parte
10 (Dialogue Principles);

propor uma estrutura de correlao entre os critrios avaliados pelo questionrio e as

partes da norma relativas adequao ergonmica do software;
11

12

elaborar uma metodologia para anlise dos resultados e interveno sobre as falhas.

1.3. PREMISSAS

No faz parte do escopo deste trabalho provar as premissas abaixo. Futuros estudos, ao
analisar os resultados aqui obtidos, devem levar em conta que se assume como verdadeiro que:
-

os princpios ergonmicos propostos pela norma ISO 9241 podem ser to gerais quanto
qualquer conjunto de critrios proposto. Obviamente, o grau de detalhamento de outros
critrios existentes ou que venham a ser propostos ser determinante para obteno de
maior ou menor preciso em uma avaliao de usabilidade. Mas, em termos gerais, os
princpios da norma so passveis de uso efetivo e satisfatrio em inspees ergonmicas
de software;

a parte 10 da norma ISO 9241, que trata dos princpios de dilogos, pode ser considerada
uma generalizao das partes 14, 15, 16 e 17, que abordam modalidades especficas de
dilogo (menu, comando, manipulao direta e preenchimento de formulrios,
respectivamente). Portanto, possvel correlacionar a parte 10 com cada uma das
especficas (14, 15, 16 e 17);

um questionrio de avaliao de satisfao subjetiva direcionado para usurios de software

permite estimar o grau de adequao do produto s expectativas da comunidade de
usurios;

se este questionrio tiver suas questes extradas ou elaboradas tomando por base os itens
da parte 10 da norma, ser possvel conhecer, para cada item da norma, o grau de
satisfao dos usurios;

caso o grau de satisfao de algum item seja baixo, poder-se- buscar apoio na correlao
entre a parte 10 e a parte especfica para identificar falhas que esto influenciando
negativamente no grau de satisfao.

12

13

1.4. METODOLOGIA DE TRABALHO

O trabalho seguir as etapas de estudo descritas abaixo:

-

sero estudadas propostas de critrios ergonmicos de vrios autores. O objetivo deste

estudo evidenciar familiaridades entre estes critrios e os princpios ergonmicos da
norma ISO 9241-10;

sero estudados mtodos de avaliao de usabilidade de software visando conhecer as

vrias modalidades e selecionar uma forma adequada de anlise ergonmica baseada em
pesquisa de opinio dos usurios;

a norma ISO 9241 ser estudada;

ser estudado o trabalho de [PRUMPER 93], referente elaborao e aplicao de um

questionrio de avaliao de usabilidade baseado na parte 10 da norma ISO 9241;

ser efetuado um experimento de avaliao da satisfao de usurios de software. Para

participar do experimento, ser identificada uma empresa desenvolvedora de software que
j pratique avaliaes freqentes de satisfao entre seus usurios. Os dados obtidos pelo
modelo de questionrio atualmente utilizado pela empresa sero comparados aos de uma
nova pesquisa tambm feita entre os usurios da empresa, mas usando uma traduo do
questionrio de [PRUMPER 93];

usando-se uma sugesto de correlao entre as partes da norma, procurar-se- demonstrar

que, a partir da anlise das respostas dos questionrios, possvel orientar e priorizar o
trabalho de investigao das provveis falhas de usabilidade que geram maiores impactos
sobre a satisfao dos usurios com relao ao produto.

1.5. ESTRUTURA DO TRABALHO

Esta dissertao est assim dividida:

13

14

Captulo 2: sero apresentados diversos estudos que tratam de critrios ergonmicos para
software. O objetivo deste captulo evidenciar a similaridade entre as vrias propostas;

Captulo 3: aborda os mtodos de avaliao de usabilidade. Uma breve reviso dos

principais mtodos ser apresentada;

Captulo 4: descreve as partes da ISO 9241, especialmente a que trata de princpios de

dilogos;

Captulo 5: apresenta o trabalho de [PRUMPER 93], que prope a avaliao de

usabilidade adotando um questionrio elaborado a partir da ISO 9241-10;

Captulo 6: relata um caso de aplicao de um questionrio de avaliao da satisfao de

usurios de software. A avaliao teve como populao os usurios de um dos projetos da
Softplan Planejamento e Sistemas Ltda., empresa de desenvolvimento de software de
Florianpolis. O questionrio utilizado uma traduo do modelo proposto e utilizado em
[PRUMPER 93]. A tabulao das respostas obtidas nos questionrios utilizada para
orientar a identificao de falhas que possam estar influenciando no grau de satisfao dos
clientes.

14

15

2. CRITRIOS/PRINCPIOS ERGONMICOS PARA S OFTWARE

Uma interface de utilizao bem projetada construda com base em princpios e processos de
desenvolvimento centralizados nos usurios e suas tarefas [MICROSOFT 95]. No entanto, qualidades
mnimas podem ser identificadas e arranjadas de forma a constituir um conjunto coeso que venha a
orientar as atividades de projeto e avaliao. O desenvolvimento desse conjunto usualmente um
processo heurstico [NIELSEN 94] baseado em experincia, mas que passa por validaes e
refinamentos at alcanar o nvel de detalhamento desejado [SHNEIDERMAN 98].
A esse conjunto de qualidades podemos dar o nome de critrios ou princpios. O emprego de
princpios e critrios bem definidos fundamental para o sucesso da concepo da interface [CYBIS 97]
porque, da mesma forma que permitem orientar de maneira coerente o projeto, podem, posteriormente vir
a servir como quesitos de avaliao de produtos.
O estudo de critrios e princpios ergonmicos para software no se restringe s atividades
acadmicas. Fornecedores de software de portes variados os desenvolvem e utilizam. Mesmo a norma
ISO 9241-10 divide as qualidades requeridas do software em princpios.
Neste captulo sero apresentados alguns conjuntos de critrios desenvolvidos em estudos
acadmicos e comerciais. Pretende-se, aqui, evidenciar a similaridade entre os trabalhos de elaborao de
critrios ergonmicos e a correlao existente entre estes conjuntos. Freqentemente, poder-se- notar a
recorrncia de termos e conceitos entre os vrios trabalhos aqui apresentados.
No captulo 4, que trata especificamente da ISO 9241-10, sero apresentados os princpios
adotados pela norma. A correlao evidenciada neste captulo tambm ser facilmente percebida quando
os princpios da norma vierem a ser detalhados.

2.1. AS OITO REGRAS DE OURO DE SHNEIDERMAN

[SHNEIDERMAN 98] descreve os seguintes princpios de projeto de interfaces de sistemas

interativos, aos quais tambm chama de oito regras de ouro para o projeto de interfaces:
-

Consistncia;
15

16

Habilitao de atalhos para usurios freqentes;

Feedback informativo;

Dilogos com encerramento evidente;

Preveno e tratamento simplificados de erros;

Fcil reverso das aes;

Suporte ao controle por parte do usurio;

Reduo da carga da memria de curto termo.

Cada um destes princpios ser detalhado a seguir.

2.1.1. Consistncia

Segundo Shneiderman, o empenho em manter a consistncia fundamental. , no entanto, o

princpio mais freqentemente violado e mais difcil de ser seguido por causa da variedade de
formas existentes para manter a consistncia:
-

seqncias consistentes de aes devem ser requeridas em situaes similares;

terminologias idnticas devem ser usadas em prompts, menus e telas de help;

a consistncia deve estar presente tambm no uso das cores, nos layouts, nas fontes de
caracteres e na adoo de letras maisculas e minsculas;

excees como a no exibio de senhas e a confirmao ou no de comandos de

remoo devem ser compreensveis e limitadas.

2.1.2. Habilitao de Atalhos para Usurios Freqentes

medida em que a freqncia de utilizao cresce, o usurio passa a desejar a reduo do

nmero de interaes e o aumento da velocidade de interao.
16

17

Geralmente, usurios freqentes apreciam e necessitam de facilidades como:

-

abreviaes;

teclas especiais;

comandos escondidos;

macros;

tempos de resposta pequenos e

rpidas atualizaes de telas.

2.1.3. Feedback Informativo

Para cada ao do usurio deve haver uma resposta do sistema:

-

aes freqentes e menores devem ser sucedidas de respostas discretas;

aes menos corriqueiras e de maior impacto devem receber respostas mais substanciais.

A apresentao visual dos objetos envolvidos na ao proporciona um ambiente conveniente

para explicitamente mostrar as mudanas ocorridas.

2.1.4. Dilogos com Encerramento Evidente

As seqncias de aes devem ser organizadas em grupos com incio, meio e fim. O feedback
informativo indicando trmino de um grupo de aes d ao operador a satisfao de alcanar o objetivo,
um sentido de alvio, o sinal para tirar os planos de contingncia e opes da mente, e uma indicao clara
para preparar o novo grupo de aes.

17

18

2.1.5. Preveno e Tratamento Simplificados de Erros

O projeto da interao deve, tanto quanto possvel, evitar que o usurio possa provocar erros
srios. Alguns cuidados essenciais:
-

quando for necessrio optar entre o preenchimento de formulrios e o menu de selees,

escolher o segundo;

inibir o preenchimento de caracteres alfabticos na entrada de campos numricos;

se o usurio cometer um erro, o sistema deve detect-lo e oferecer instrues de

recuperao especficas, simples e construtivas. Por exemplo: ao invs de redigitar um
comando inteiro, o usurio deve unicamente corrigir a parte errada;

aes erradas no devem provocar mudanas no estado do sistema ou, alternativamente, o

sistema deve fornecer instrues para recuperao do estado.

2.1.6. Fcil Reverso das Aes

Tanto quanto possvel, as aes devem ser reversveis. Esta facilidade:

-

diminui a ansiedade, j que o usurio sabe que os erros podem se desfeitos;

estimula a explorao de opes pouco familiares.

As unidades de reversibilidade podem ser:

-

uma ao simples;

uma tarefa de entrada de dados;

ou um grupo completo de aes como, por exemplo, a entrada de um nome e de um bloco

completo de campos de endereo.

18

19

2.1.7. Suporte ao Controle por parte do Usurio

Operadores experientes usualmente tm o forte desejo de sentir que esto no comando do

sistema, e que o sistema responde s aes deles.
O operador passa a desenvolver sentimentos de ansiedade e insatisfao quando o sistema
apresenta aes inesperadas, seqncias tediosas de entradas de dados, inabilidade ou dificuldade de
fornecer informaes necessrias ou, ainda, incapacidade de produzir as aes desejadas.
Shneiderman cita [GAINES 81], para o qual o sistema deve incentivar os usurios a ser
iniciadores das aes ao invs de unicamente responder s aes.

2.1.8. Reduo da Carga da Memria de Curto Termo

A limitao do processamento de informao humano na memria de curto termo requer:

-

telas simples;

consolidao de telas de mltiplas pginas;

reduo na freqncia de movimentao de tela;

fornecimento de quantidade suficiente de cdigos, mnemnicos e seqncias de aes

durante o tempo de treinamento;

quando apropriado, acesso on-line explicao da sintaxe dos comandos, a abreviaes e

a outras informaes.

2.2. OS PRINCPIOS HEURSTICOS DE NIELSEN

[NIELSEN 90] apresentou um conjunto de dez princpios heursticos de usabilidade inspirados

no que chamou de propriedades comuns s interfaces usveis:
-

dilogos simples e naturais;

19

20

adoo da linguagem do usurio;

minimizao da carga de memria do usurio;

consistncia;

feedback;

sadas claramente marcadas;

atalhos;

mensagens de erros construtivas e precisas;

preveno de erros;

help e documentao.

O conjunto acima foi revisto em [NIELSEN 94], resultando nos princpios abaixo:
-

Visibilidade do Estado do Sistema;

Compatibilidade entre Sistema e Mundo Real;

Liberdade e Controle do Usurio;

Consistncia e Padres;

Preveno de Erro;

nfase no Reconhecimento;

Flexibilidade e Eficincia no Uso;

Esttica e Projeto Minimalistas;

Auxlio ao Reconhecimento, Diagnstico e Recuperao de Erros;

Help e Documentao.

20

21

Cada um destes princpios ser detalhado a seguir.

2.2.1. Visibilidade do Estado do Sistema

O sistema deve sempre manter o usurio informado sobre o que est acontecendo atravs do
fornecimento de feedback apropriado dentro de tempos razoveis.

2.2.2. Compatibilidade entre Sistema e Mundo Real

O sistema, ao invs de termos relacionados com o software, deve utilizar a linguagem do

usurio, com palavras, frases e conceitos familiares a ele. O sistema deve seguir as convenes do mundo
real, fazendo a informao aparecer na ordem lgica e natural.

2.2.3. Liberdade e Controle do Usurio

Os usurios geralmente cometem enganos ao escolher opes do sistema. Neste caso,

precisam de uma sada de emergncia evidente, que lhes permita deixar o estado indesejado sem ter que
passar por dilogos extensos. Recursos recomendveis para estas situaes so, por exemplo, as opes
de desfazer e refazer.

2.2.4. Consistncia e Padres

Os usurios no devem ter que adivinhar se diferentes palavras, situaes ou aes tm o

mesmo significado. Recomenda-se, neste caso, o uso de um conjunto definido de convenes.

2.2.5. Preveno de Erro

O projeto da interao deve privilegiar a preveno de erros. Nielsen afirma que o projeto
cuidadoso que previne o problema de acontecer a primeira vez ainda melhor que o fornecimento boas
mensagens de erros.
21

22

2.2.6. nfase no Reconhecimento

O projeto deve dar nfase no reconhecimento e preterir que o usurio tenha que relembrar
aspectos relativos interao. Isto pode ser conseguido fazendo-se objetos, aes e opes visveis.
Definitivamente, o usurio no deve ser obrigado a relembrar de uma parte do dilogo para poder dar
seqncia interao. Instrues para o uso do sistema devem ser visveis e facilmente recuperveis.

2.2.7. Flexibilidade e Eficincia no Uso

Aceleradores, invisveis aos usurios novatos, podem oferecer maior velocidade de interao
para os usurios mais experimentados. Este recurso permite que o sistema seja igualmente apropriado para
usurios novatos ou mais experientes. Alm deste recurso, deve-se proporcionar ao usurio mecanismos
para criar atalhos para aes freqentes.

2.2.8. Esttica e Projeto Minimalistas

Segundo Nielsen, os dilogos no devem conter informao irrelevante ou raramente

necessria. Qualquer unidade extra de informao em um dilogo compete com unidades relevantes,
diminuindo a visibilidade relativa.

2.2.9. Auxlio ao Reconhecimento, Diagnstico e Recuperao de Erros

As mensagens de erro devem ser expressas em linguagem por extenso, sem cdigos e de
maneira clara. O teor da mensagem deve indicar o problema com preciso e sugerir uma soluo
construtiva.

2.2.10. Help e Documentao

Embora seja melhor que o sistema possa ser usado sem documentao, pode ser necessrio
providenci-la, bem como pode ser necessrio providenciar helps.
22

23

Ambos, help e documentao, devem:

-

permitir que qualquer informao seja facilmente pesquisada e tenha como foco principal a
tarefa do usurio;

conter listas concretas de passos a executar;

ser concisos.

Um importante desdobramento destes princpios pode ser encontrado em [TOGNAZZINI

99]. Nielsen, particularmente, considera este desdobramento muito extenso para ser utilizado em uma
avaliao heurstica. No entanto, qualifica-o como um checklist til.

2.3. PRINCPIOS DE P ROJETO CENTRADO NO USURIO MICROSOFT

A Microsoft, maior empresa fornecedora de software do mundo, publica em seu guia de

recomendaes os princpios que adota para o desenvolvimento de seus produtos baseados no MSWindows. So chamados princpios de projeto centrado no usurio e sero detalhados a seguir
[MICROSOFT 95].

2.3.1. Usurio no Controle

Um importante princpio para o projeto de interfaces que o usurio deve sempre sentir-se no
controle do software, e nunca o contrrio. Algumas implicaes desse princpio:
-

o usurio deve sempre iniciar as aes, nunca o software. Isto , o papel do usurio deve
ser sempre ativo, jamais reativo;

diante da diversidade de graus de experincia dos usurios, deve-se fornecer recursos para
personalizao da interface;

a interface deve ser to interativa e convidativa quanto possvel.

23

24

2.3.2. Objetividade (Directness)

O software deve ser projetado de forma a permitir que o usurio manipule diretamente
representaes da informao. Seja ao arrastar objetos para reposicion-los, seja ao navegar at uma
determinada posio de um documento, os usurios devem ser capazes de perceber, na tela, os resultados
de suas aes sobre os objetos. Visibilidade das informaes e das opes tambm reduzem a carga
mental do usurio. Para os usurios, reconhecer um comando mais rpido do que lembrar sua sintaxe.
O uso adequado de metforas auxilia significativamente no sucesso da implementao desse
princpio. O uso de metforas proporciona uma interface direta e intuitiva, j que elas permitem transferir o
conhecimento e experincia dos usurios para o software, o que permite ao usurio mais facilidade ao
prever e aprender comportamentos do programa.

2.3.3. Consistncia

A consistncia proporciona um sentimento de estabilidade, tornando a interface mais familiar e

previsvel. Usando conhecimento j adquirido, o usurio pode aprender novas funes mais facilmente e
concentrar a ateno nas tarefas, j que no precisar relembrar as diferenas de interao.
A consistncia deve estar presente em todos os aspectos da interface: nomes de comandos,
apresentao visual da informao e ambiente operacional. O projeto consistente deve considerar vrios
aspectos:
-

consistncia do produto: funes devem ser apresentadas atravs de interfaces e conjuntos

de comandos consistentes. Deve-se sempre usar o mesmo conjunto de comandos para
executar funes que paream similares ao usurio;

consistncia do ambiente operacional: devem ser adotadas convenes de interfaces que

permitam ao usurio interagir com sistema a partir da experincia j adquirida;

consistncia das metforas: o comportamento das metforas utilizadas deve ser consistente
com o comportamento dos objetos equivalentes no mundo real. Um exemplo: caso o
sistema disponha de recursos para recuperar arquivos removidos, inadequada a adoo
24

25

da metfora de um triturador de papel, j que o objeto real no permite recompor um

documento triturado. Por esta razo, usualmente, d-se preferncia metfora da cesta de
lixo.

2.3.4. Tolerncia (Forgiveness)

Mesmo interfaces bem projetadas no conseguem evitar que o usurio cometa erros, sejam
fsicos, como apontar erradamente dados ou funes, sejam mentais, como tomar um deciso errada
sobre a funo a selecionar.
Constantemente, os usurios aprendem novos recursos a partir da explorao da interface, em
um processo de tentativa e erro. Para estes casos, essencial haver recursos que permitam:
-

alertar sobre situaes potenciais causadoras de danos no sistema e nos dados;

reverter aes e recuperar dados e o estado do sistema.

2.3.5. Feedback

toda ao do usurio deve corresponder uma resposta perceptvel por parte do sistema. A
reao do sistema pode ter vrias formas: visual, auditiva ou mista. muito importante que o usurio
receba, cada interao com o sistema, estmulos suficientemente distintos e adequados que permitam
conhecer o estado do sistema e a natureza da ao.
O feedback deve ser proporcionado dentro de tempos aceitveis e to prximos ao local de
interao quanto possvel. Mesmo durante a execuo de alguma tarefa, o sistema deve fornecer ao
usurio feedback sobre o estado do processamento e formas de cancelamento.

25

26

2.3.6. Esttica

O projeto visual representa um parte significativamente importante da interface. As

caractersticas visuais tm por funo proporcionar impresses visuais e, igualmente, comunicar sobre o
estado dos objetos em foco.
Um projeto equilibrado permite garantir a transferncia de informao visual sem criar
elementos que desnecessariamente venham a competir pela ateno do usurio.

2.3.7. Simplicidade

A simplicidade da interface, proporcionando acesso a todas as funcionalidades da aplicao,

facilita a aprendizagem e o uso. Para obter uma interface simples devem ser consideradas algumas
recomendaes:
-

reduo da quantidade de informao apresentada ao mnimo necessrio para obteno de

um comunicao adequada;

adoo de nomes de comandos e mensagens sucintos;

organizao de objetos e elementos, agrupando-os por similaridade ou semntica;

reduo progressiva da quantidade de opes disponveis medida em que o dilogo

avana.

2.4. PRINCPIOS IBM

A IBM mantm um site na Internet, www.ibm.com/ibm/easy/, especializado em questes
relativas ao projeto centrado no usurio e usabilidade, ou, como a prpria empresa chama, facilidade de
uso (Ease of Use).
Em [IBM 99] so descritos os princpios de usabilidade que orientam os projetos da empresa:
-

simplicidade;

suporte;

26

27

familiaridade;

obviedade;

encorajamento;

satisfao;

acessibilidade;

segurana;

versatilidade;

personalizao e

afinidade.

2.4.1. Simplicidade

A premissa bsica deste princpio dita que se deve privilegiar a usabilidade funcionalidade, ou
seja, a lgica de utilizao deve prevalecer lgica de funcionamento.
A interface deve ser simples e direta, evitando-se o que o excesso de informaes possa tirar a
ateno do usurio. Funes bsicas devem estar sempre visveis, e funes avanadas devem ser menos
bvias para usurios novatos.
Essencialmente, devem ser mantidas na tela, exclusivamente, as funes aplicveis tarefa em
execuo.

2.4.2. Suporte

O usurio deve estar no controle das aes e ser assistido de maneira ativa: devem, sempre,
estar disponveis opes suficientes para suportar a sua forma de pensar, alm de mecanismos para
estabelecer e manter um contexto de trabalho, a partir do qual seja possvel conhecer o estado atual do
sistema e, tambm , os estados possveis.
Pode-se proporcionar um sentimento de estabilidade ao usurio a partir de recursos que
permitam ao usurio retomar com facilidade um trabalho interrompido por perodos de horas e at dias.

27

28

bastante provvel que o usurio tenha mais familiaridade com algumas funes e seja novato
em outras. Nestes casos, o sistema deve reconhecer o objetivo da interao e proporcionar, no nvel
adequado experincia do usurio, o conhecimento necessrio para que a tarefa seja executada com
sucesso.

2.4.3. Familiaridade

O projeto deve proporcionar ao usurio condies para aprender a partir do seu prprio
conhecimento e de suas prprias experincias do mundo real. A utilizao desse conhecimento na
concepo da interface amplia a quantidade de tarefas que o usurio pode executar.
O uso de conceitos e tcnicas que o usurio j conhece no mundo real permite obter um
progresso rpido e efetivo no que se refere utilizao do sistema. Um conceito aprendido um vez pode
ser aplicado para favorecer o aprendizado de situaes similares.

2.4.4. Obviedade

Os objetos empregados na interface e seus respectivos controles devem ser visveis e intuitivos.
A utilizao de objetos do mundo real na interface permite ao usurio intuir comportamentos, dando-lhe
mais conforto e segurana.
Uma forte recomendao no que se refere a este princpio a combinao de representaes
do mundo real com mecanismos de ao direta.

2.4.5. Encorajamento

A confiana do usurio com relao ao sistema tanto maior quanto mais as respostas do
sistema corresponderem aos resultados esperados, por isso as aes dever ser igualmente previsveis e
reversveis.
A adequao do sistema s expectativas de respostas requeridas pelos usurios demanda que o
projetista compreenda as tarefas, metas e modelo mental do usurio. Quando o software produz
28

29

resultados previsveis e reversveis, o usurio sente-se mais encorajado a explorar a interface, ativar
funes, ver os resultados e desfazer aes indesejveis.

2.4.6. Satisfao

O usurio deve desenvolver um sentimento de progresso e consecuo de seus objetivos. Para

tanto, algumas recomendaes podem ser seguidas:
-

as aes do sistema devem ser seguidas de feedback imediato. Demoras excessivas

tendem a reduzir a confiana do usurio com relao ao sistema, e respostas imediatas
permitem ao usurio ativar rapidamente os mecanismos de reverso de aes com
resultados indesejveis;

devem ser evitadas situaes nas quais os usurios podem estar trabalhando com dados
desatualizados. Quando isso no for possvel, o usurio deve ser prontamente informado.

2.4.7. Acessibilidade

Os objetos de interao devem estar acessveis todo o tempo, podendo ser usados em
qualquer seqncia.
O uso de modos (estados nos quais as aes normalmente disponve is tornam-se inacessveis
como, por exemplo, os dilogos modais) deve ser evitado porque restringe a habilidade de interao com
o sistema.

2.4.8. Segurana

Este princpio sugere manter os usurios longe de problemas. O projetista tem a funo de
criar mecanismos que impeam os usurios de cometer erros. As estruturas mentais so melhores nas
situaes de reconhecimento do que nas de lembrana, por isso, seja quando solicitado, seja
automaticamente, a interface deve prover respostas visuais, lembretes e outras formas de auxlio.

29

30

A interao nunca deve depender exclusivamente da memria do usurio para ter seqncia,
especialmente quando o sistema requer informaes previamente fornecidas. A comunicao com sistema
- atravs do help ou de indicativos visuais que permitam escolher os objetos de interao necessrios pode ajudar o usurio a alcanar seus objetivos.

2.4.9. Versatilidade

A interface deve ser projetada de forma a suportar tcnicas alternativas de interao. Quanto
mais verstil for a interface, maior ser a quantidade de perfis de usurios que ela poder satisfazer,
especialmente no que se refere ao nvel de experincia.
extremamente conveniente que o usurio possa escolher o tipo de interao adequando
cada situao. Tambm a troca do tipo de interao escolhido deve ser possvel a qualquer momento.
Desenvolver interfaces flexveis reconhecer a diversidade humana, que pode ser influenciada
por incapacidades, ambientes, culturas ou preferncias.

2.4.10. Personalizao

A interface deve ser customizvel, isto , deve ser passvel de adequao s necessidades e
desejos individuais dos usurios. As adequaes desejadas podem ser fundamentadas em interesses,
motivaes, nvel de experincia ou conhecimento.
Obviamente, a possibilidade de se configurar um ambiente adequado s necessidades
particulares d ao usurio um sentimento de conforto e familiaridade, alm de proporcionar condies para
a obteno de maior produtividade e satisfao.
Algumas consideraes para ambientes onde operam mltiplos usurios:
-

usurios que compartilham um mesmo equipamento devem possuir mecanismos que

permitam que cada operador crie sua personalizao. A personalizao efetuada deve ser
facilmente acessvel ao respectivo operador;

30

31

usurios que operam vrios equipamentos devem possuir mecanismos que permitam que a
configurao criada em um equipamento seja acessvel em outro que venha a ser utilizado.

2.4.11. Afinidade

A principal diretriz que rege este princpio trazer vida os objetos de interao atravs de
um bom projeto visual.
A meta do projeto visual apresentar, de uma maneira coesa, todos os aspectos envolvidos
nos princpios de projeto. Por isso, o projeto visual deve suportar, sem ambigidades, o modelo do
usurio e suas respectivas funes. O resultado final deve ser uma representao intuitiva e familiar do
que a segunda natureza para os usurios, ou seja, a funo do projeto visual criar um modelo virtual
que corresponda o mais fielmente possvel forma como o usurio percebe e interage com os objetos
reais.

2.5. CRITRIOS ERGONMICOS DE BASTIEN E S CAPIN

[BASTIEN 93] apresenta um trabalho bastante detalhado e abrangente que sugere oito
princpios ou critrios, organizados em um estrutura de trs nveis: critrios principais, sub-critrios e
critrios elementares. Estes critrios sero descritos a seguir.

2.5.1. Conduo

A interface deve dispor de meios adequados (mensagens, avisos, alarmes e rtulos) para
alertar, orientar, informar, instruir e guiar o usurio na interao com o sistema.
Uma boa conduo facilita a aprendizagem e o uso do sistema, o que resulta em mais
produtividade e menor quantidade de erros. Para tanto deve-se permitir ao usurio:
-

saber, a qualquer momento, em que ponto da interao com o sistema ele se encontra;

conhecer qua is as aes possveis e suas respectivas conseqncias;

31

32

solicitar informao adicional.

Este critrio divide-se em quatro sub-critrios: presteza, feedback imediato, legibilidade e

agrupamento/distino de itens.

2.5.1.1. Presteza

Entende-se por presteza os mecanismos que o software oferece para:

-

guiar o usurio na execuo de tarefas especficas, como a entrada de dados, por exemplo;

permitir ao usurio conhecer as alternativas possveis;

informar o usurio sobre o estado ou contexto atual do sistema;

auxiliar o usurio, como os helps, por exemplo.

O software prestativo facilita a navegao na aplicao, reduzindo a necessidade de o usurio

aprender sries de comandos e, por conseqncia, diminui a quantidade de erros. Alm disso, auxilia na
percepo do estado corrente do sistema, permitindo ao usurio ter conhecimento do ponto em que se
encontra no dilogo e das aes que resultaram naquele contexto.

2.5.1.2. Agrupamento/Distino de Itens

Este critrio trata da organizao visual dos itens de informao levando em conta a relao que
estes itens guardam entre si.
A partir de caractersticas como similaridade, freqncia de uso, contexto podem ser
determinadas classes de itens que permitam agrupar as funes do sistema. Este aspecto particularmente
importante porque influencia diretamente na compreenso da tela por parte do usurio.
A adequada ordenao, posicionamento e distino dos objetos permitem ao usurio perceber
os diferentes itens e grupos de itens e aprender mais facilmente o relacionamento existente entre eles. Este
sub-critrio divide-se em dois critrios elementares: agrupamento/distino por localizao e por formato.
32

33

2.5.1.2.1. Agrupamento/Distino por Localizao

Este critrio aborda o posicionamento dos objetos na interface como forma de diferenciar as
classes de itens e determinar a que classe cada item pertence.

2.5.1.2.2. Agrupamento/Distino por Formato

Este critrio concentra-se no uso de recursos grficos (formato, fonte e cor, por exemplo)
como forma de diferenciar as classes de itens e determinar a que classe cada item pertence.

2.5.1.3. Feedback Imediato

Este critrio trata das respostas fornecidas pelo sistema s aes do usurio. A ausncia de
feedback pode dar ao usurio a impresso de que o sistema tenha falhado.
Por mais simples que seja a ao do usurio, o sistema deve proporcionar uma resposta
adequadamente distinta, breve e consistente. A qualidade e agilidade da resposta so fundamentais para
que o usurio entenda o dilogo e estabelea sentimentos de confiana e satisfao com relao ao
sistema.

2.5.1.4. Legibilidade

A legibilidade trata das caractersticas lxicas das informaes apresentadas e que podem
facilitar ou dificultar a sua leitura: caractersticas dos caracteres como brilho e contraste com o fundo,
tamanho de fonte, espaamento entre palavras, linhas e pargrafos, tamanho da linha e outros.
As caractersticas cognitivas e perceptivas dos usurios devem ser levadas em conta na
apresentao da informao. Uma boa legibilidade facilita a leitura da informao apresentada, o que
resulta em melhor performance do usurio.

33

34

2.5.2. Carga de Trabalho

Esse critrio aborda os elementos de interface que tm papel importante na reduo da carga
cognitiva e perceptiva do usurio e no aumento da eficincia do dilogo.
Quanto maior a carga de trabalho, maior a chance de o usurio cometer erros. Alguns
cuidados no projeto permitem reduzir a carga de trabalho do usurio e obter maior eficincia na execuo
das tarefas:
-

reduo da quantidade de elementos de interface que possam distrair o usurio;

diminuir a extenso das aes requeridas do usurio.

Este critrio divide-se em: brevidade e densidade informacional.

2.5.2.1. Brevidade

Este critrio concernente carga cognitiva e perceptiva do usurio tanto para entradas e
sadas individuais, quanto para conjuntos de entradas (ou seja, conjuntos de aes requeridas para
alcanar algum objetivo ou executar uma tarefa).
A principal preocupao desse critrio a limitao de trabalho de entrada e leitura, e a
diminuio do nmero de passos das aes.
Este critrio divide-se em: conciso e aes mnimas.

2.5.2.1.1. Conciso

Este critrio diz respeito carga de trabalho cognitiva e perceptiva do usurio para entradas e
sadas individuais.
Como a memria de curto termo limitada, quanto mais curtas as entradas, menores sero as
possibilidades de erros. Alm disso, quanto mais sucintos forem os itens de informao, menores sero os
tempos de leitura.
34

35

2.5.2.1.2. Aes Mnimas

Este critrio concernente carga de trabalho relativa ao nmero de aes necessrias para
executar uma tarefa ou alcanar um objetivo. Basicamente, trata da reduo do nmero de passos menor
quantidade necessria para alcanar os resultados desejados.
Quanto mais numerosas e complexas as aes necessrias par a se alcanar um objetivo, maior
ser a carga de trabalho e, conseqentemente maior a possibilidade de o usurio cometer erros.

2.5.2.2. Densidade Informacional

Este critrio trata da carga de trabalho cognitiva e perceptiva do usurio, no no que se refere
especificamente a um elemento individual de informao, mas no que tange ao conjunto de informaes
apresentadas.
Na maioria das tarefas, a performance do usurio prejudicada e, conseqentemente os
erros tornam-se mais freqentes - quando a densidade de informao muito alta ou muito baixa.
Por isso, alguns cuidados devem ser tomados no projeto da interface:
-

itens no relacionados com a tarefa devem ser removidos;

os usurios no devem ser obrigados a memorizar longas listas de dados e procedimentos

complicados;

o usurio no pode ser obrigado a executar complexas atividades cognitivas que no

existiam na tarefa manual.

2.5.3. Controle Explcito

Este critrio enfoca o processamento executado pelo sistema a partir das aes explcitas do
usurio e, tambm, o controle que o usurio tem sobre o processamento e as aes tomadas pelo sistema.

35

36

Quando o usurio define de maneira explcita suas entradas, e essas entradas esto sob seu
controle, as possibilidades de ambigidades so reduzidas. Por isso, o sistema ter melhor aceitao se o
usurio tiver total controle sobre o dilogo.
Este critrio divide-se em: aes explcitas do usurio e controle do usurio.

2.5.3.1. Aes Explcitas do Usurio

Este critrio refere-se s relaes entre o processamento executado pelo computador e as

aes do usurio. Esta relao deve ser explcita, ou seja, o computador deve processar exclusivamente
as aes solicitadas e no momento requerido pelo usurio.
Quando o processamento resulta de aes explcitas, os usurios aprendem e entendem melhor
o funcionamento da aplicao e a quantidade de erros reduzida.

2.5.3.2. Controle do Usurio

Este critrio refere-se necessidade de o usurio estar sempre no controle do processamento

do sistema, podendo, por exemplo, acionar mecanismos de interrupo, cancelamento, suspenso ou
continuao. Cada ao possvel deve ser antecipada e opes apropriadas devem ser proporcionadas.
O controle sobre a interao favorece o aprendizado e diminui a probabilidade de ocorrncias
de erros. Conseqentemente, o sistema torna-se mais previsvel.

2.5.4. Adaptabilidade

Este critrio refere-se capacidade que o sistema apresenta para reagir contextualmente e de
acordo com as necessidades e preferncias do usurio.
Uma nica interface no consegue ser adequada a todos os seus usurios potenciais. Por isso,
para evitar efeitos negativos sobre os usurios, a interface precisa dispor de recursos para se adaptar a
eles.
36

37

Quanto mais variadas as maneiras de se executar uma tarefa, maiores as probabilidades de um

usurio desenvolver uma forma de execuo particular. Portanto, devem ser proporcionados recursos em
quantidade e diversidade suficientes (diferentes procedimentos, opes e comandos) para que o usurio
possa escolher, a partir de seus preferncia s, os mais adequados sua forma de trabalhar. Este critrio
divide-se em: flexibilidade e experincia do usurio.

2.5.4.1. Flexibilidade

O critrio flexibilidade refere-se aos meios disponveis para customizao(personalizao) da

interface visando levar em conta as estratgias e hbitos de trabalho do usurio, e as respectivas
exigncias da tarefa.
A flexibilidade determinada pelo nmero de diferentes maneiras pelas quais o usurio pode
alcanar um determinado objetivo. Ou seja, a capacidade que a interface apresenta para se adaptar s
necessidade peculiares de cada usurio.

2.5.4.2. Experincia do Usurio

Este critrio refere-se aos mecanismos disponveis para que o sistema seja adequado ao nvel
de experincia do usurio.
As necessidades de informao dos usurios experientes so distintas das dos usurios novatos.
Enquanto usurios novatos podem ser auxiliados por dilogos detalhados, e orientaes passo-a-passo,
usurios experientes podem ter atalhos sua disposio.
A interface deve estar preparada para lidar com usurios de diferentes nveis de experincia e
levar em conta que usurios novatos podem tornar-se experientes medida que tenham uma interao
intensa e prolongada com o sistema. Processo inverso pode ocorrer com usurios experientes que passam
por longos perodos sem interagir com o sistema.

37

38

2.5.5. Gesto de Erros

A gesto de erros pertinente aos mecanismos disponveis para preveno, reduo e

correo de erros. So considerados erros: entrada invlida de dados, fornecimento de dados em formato
invlido, sintaxe de comandos errada.
As interrupes causadas pelos erros tm conseqncias negativas sobre as atividades do
usurio. Geralmente, elas prolongam as interaes e desorganizam o planejamento da execuo da tarefa.
A reduo da quantidade de interrupes resultante da limitao do nmero de erros aumenta a
produtividade do usurio.
Este critrio divide-se em: proteo contra erros, qualidade das mensagens de erro e correo
de erros.

2.5.5.1. Proteo contra Erros

A proteo contra erros refere-se aos meios disponveis para deteco e preveno de erros
decorrentes da entradas de dados, ativao equivocada de comandos, e aes com conseqncias
destrutivas.
Deve-se dar preferncia deteco dos erros antes da validao dos dados, j que a
perturbao no dilogo tende a ser menor neste momento.

2.5.5.2. Qualidade das Mensagens de Erros

Este critrio refere-se ao contedo das mensagens de erro: relevncia, severidade, legibilidade,
especificidade sobre a natureza do erro sintaxe, formato, limites e outras - e s aes necessrias
correo.
A qualidade das mensagens favorece o aprendizado do sistema, pois permite que o usurio
conhea os erros e as respectivas causas, aprenda a evit-los, preveni-los e corrigi-los.

38

39

2.5.5.2. Correo de Erros

Os erros causam menos perturbao quando podem ser imediatamente e facilmente corrigidos.
Este critrio diz respeito aos meios proporcionados pelo sistema para que o usurio possa corrigir os erros
cometidos

2.5.6. Consistncia

Este critrio enfoca a regularidade com que conceitos de projeto cdigos, nomes, formatos,
procedimentos, metforas e outros so empregados de maneira idntica em situaes e contextos
similares, e de maneiras distintas em contextos diferentes.
A consistncia d ao usurio a sensao de estabilidade diante da interface. Os objetos da
interface so melhor reconhecidos, localizados e utilizados, quando seu formato, localizao e sintaxe
permanecem estveis de uma tela para outra. Nestas condies o sistema torna-se mais previsvel,
facilitando a aprendizagem e a generalizao, e reduzindo a quantidade de erros.
Um sistema consistente reduz significativamente a aprendizagem e o uso. Por outro lado, uma
das principais razes para a rejeio de sistemas a falta de consistncia.

2.5.7. Significado dos Cdigos

O critrio significado dos cdigo avalia a relao entre um termo ou unidade de informao e a
codificao usada para represent -lo. Cdigos e nomes so significantes para os usurios quando h uma
forte relao semntica entre tais cdigos e os itens ou aes representados.
Cdigos significativos facilitam a recordao e o reconhecimento. Por outro lado, cdigos ou
nomes pouco significativos podem levar os usurios a executar operaes inadequadas e, por
conseqncia, ao erro.

39

40

2.5.8. Compatibilidade

O critrio compatibilidade refere-se adequao entre as caractersticas das tarefas e do

usurio memria, experincia, habilidades, idade, expectativas e outras -, e a organizao da sada,
entrada e do dilogo de uma aplicao. Aborda, tambm, a coerncia entre ambientes e entre aplicaes.
A transferncia de informaes entre contextos distintos mais rpida e eficiente quando o
volume informaes que o usurio precisa recodificar menor.
A eficincia maior quando:
-

os procedimento projetados para execuo da tarefa so compatveis com as

caractersticas psicolgicas do usurio;

os procedimentos e as tarefas so organizadas obedecendo expectativas e prticas do

usurio;

as tradues, interpretaes e referncias documentao so minimizadas;

a informao apresentada de uma forma diretamente utilizvel.

2.6. CONCLUSES

Este captulo apresentou alguns conjuntos de requisitos ergonmicos adotados pela

comunidade de pesquisa e desenvolvimento de software. Uma rpida comparao entre as
recomendaes propostas em cada um dos conjuntos apresentados permite evidenciar algumas
importantes concluses:
-

apesar de cada um destes trabalhos ter sido desenvolvido sob circunstncias diferentes, em
ambientes distintos e ter sofrido a influncia de aspectos organizacionais e socias
particulares, a similaridade das recomendaes apresentadas notadamente alta, havendo
em muitos casos recorrncias significativas de conceitos e critrios;

40

41

um grande fator de distino entre os trabalhos apresentados reside na diferena do grau de

detalhamento de cada abordagem. Assim, enquanto a maioria dos trabalho caracteriza-se
pela conciso de suas recomendaes, outros especialmente [BASTIEN 93]
organizam-se de uma maneira coesa e hierrquica. Esta estrutura tende a facilitar a
utilizao dos requisitos e, por conseqncia, possibilita a obteno de resultados mais
precisos na avaliao e desenvolvimento de interfaces;

alguns trabalhos representam anseios, s vezes, muito focados em interesses imediatos, no

sendo suficientemente genricos. Um exemplo disso so as recomendaes de
[MICROSOFT 95] relativas consistncia;

os trabalhos citados no tm representatividade suficiente para ser aceitos por toda a

comunidade que atua no desenvolvimento e avaliao de software.

41

42

3. MTODOS DE AVALIAO DE U SABILIDADE

Diante das diversas abordagens de avaliao de usabilidade, [SHNEIDERMAN 98] sugere

que a adoo de um mtodo adequado depende de vrios fatores:
-

estgio em que se encontra o projeto: indica se os trabalhos encontram-se nas fases mais
elementares, em pleno andamento ou em fase de concluso;

grau de inovao do projeto: aponta se o domnio do assunto ou da soluo em questo

tem natureza bem definida ou se de carter exploratrio;

nmero de usurios potenciais;

criticidade da interface: obviamente, a interface de um sistema de controle de trfego areo

desempenha papel muito mais crtico do que a interface de um quiosque de informaes
tursticas;

custos do produto e dos recursos destinados a testes: h mtodos de inspeo de custos e

preciso bastante variados. A criticidade do produto e o grau de preciso dos resultados
esperados dos testes ser significativo para a busca do equilbrio entre os custos de
desenvolvimento do produto e os custos de inspeo da usabilidade;

disponibilidade de tempo e de especialistas em usabilidade;

experincia da equipe de projeto e avaliao.

[NIELSEN 94] classifica os mtodos de avaliao de usabilidade em quatro categorias:

-

automtica: onde a usabilidade avaliada por programas de computador que comparam a

interface propriamente dita e suas especificaes. O atual estado-da-arte ainda no permite
a efetividade desta forma de avaliao;

emprica: onde a usabilidade avaliada a partir da observao dos testes feitos com
usurios reais. a forma de avaliao mais regularmente utilizada, apresentando algum

42

43

empecilhos: usualmente caro e difcil reunir usurios reais para testar todos os aspectos de
cada nova verso do projeto;
-

formal: a usabilidade medida a partir de modelos e frmulas. Esta forma de avaliao de

difcil aplicao, sendo particularmente problemtica no caso de interfaces altamente
interativas e complexas;

informal: a avaliao da usabilidade d-se a partir de regras heursticas e de experincias,

conhecimentos ou habilidades pessoais ou de grupos.

Apesar de a classificao acima, proposta por Nielsen, contar com razovel aceitao junto
comunidade ligada usabilidade de software, adotar-se-, como orientao para este captulo, a
classificao sugerida por [SHNEIDERMAN 98], que divide os mtodos de avaliao levando em conta,
alm da forma de conduo (assim como o faz Nielsen), o ambiente onde se d a avaliao e os
envolvidos (especialistas, usurios ou ambos):
-

Revises Especializadas;

Testes e Estudos Laboratoriais;

Pesquisas de Opinio;

Testes de Aceitao;

Avaliao Durante o Uso Ativo e

Experimentao Psicologicamente Orientada.

Este captulo apresenta uma breve reviso destes mtodos, abordando aspectos como
aplicabilidade, funcionamento e preciso.

3.1. REVISES ESPECIALIZADAS

As revises especializadas requerem a participao de um especialista com domnio das

questes de usabilidade, do assunto ou da interface em questo quando se trata de interfaces altamente

43

44

especializadas -

[SHNEIDERMAN 98], funo essa nem sempre existente em uma equipe de

desenvolvimento. Obviamente, h a alternativa de participao de consultores especializados, mas

Shneiderman alerta que a reao da equipe de desenvolvimento contra recomendaes externas ao grupo
tende sempre a ser maior. Embora no sejam determinantes exclusivos do sucesso da interveno, estas
preocupaes no devem ser ignoradas. [NIELSEN 94], em particular, denomina este tipo de avaliao
como Inspeo de Usabilidade, e o inclui na categoria das avaliaes informais.
Os principais mtodos de reviso especializada so [SHNEIDERMAN 98]:
-

Avaliao Heurstica;

Reviso usando Guias de Recomendaes;

Inspeo de Consistncia;

Navegao Cognitiva;

Inspees Formais.

Cada um destes mtodos ser detalhado a seguir.

3.1.1. Avaliao Heurstica

A Avaliao Heurstica analisa a usabilidade da interface a partir de uma lista de

recomendaes heursticas, como as discutidas no Captulo 2. A experincia, familiaridade e capacidade
de interpretao do avaliador so fundamentais para o sucesso deste tipo de reviso.
[MATIAS 95] apresenta um interessante trabalho de avaliao de usabilidade de um editor de
textos. Ao invs de efetuar uma avaliao de conformidade com relao a guias de recomendaes (ver
3.1.2), foram utilizadas 173 questes de um checklist elaborado a partir das principais recomendaes
ergonmicas da norma ISO 9241, [BASTIEN 93], [SMITH 86], [RAVDEN 89] e [HORTON 94].
[CYBIS 97] apresenta o ErgoList (www.inf.ufsc.br/ergolist), um checklist automatizado
disponvel na Internet que permite a avaliao da usabilidade de produtos de software.

44

45

3.1.2 Reviso usando Guias de Recomendaes

A reviso executada com o auxlio de guias de recomendaes analisa a usabilidade a partir da

comparao entre a interface e as padronizaes elaboradas pela prpria empresa desenvolvedora do
produto ou por outros guias de estilo.
Usualmente, para que os avaliadores dominem as instrues constantes no guias de estilo,
necessitam de treinamento e um razovel tempo de estudo. Tambm a avaliao do produto demanda
prazos significativos.
[ROSA 99] apresenta um trabalho que aborda preocupaes ergonmicas na confeco de um
guia de estilo de uma empresa desenvolvedora de software. Para facilitar a execuo da reviso, foi
elaborado um checklist que compila as recomendaes em questes cujas respostas podem assumir
valores conforme, no-conforme e no-aplicvel, o que torna a avaliao bastante objetiva.
Fazem parte deste tipo de reviso as avaliaes normativas, onde o processo caracterizado
por buscas de evidncias de conformidade, ou no-conformidade, com os quesitos da norma. [DE
SOUZA 93] sugere cuidados especiais na elaborao de guias de recomendaes no que se refere
norma ISO 9241 os guias devem ser elaborados luz dos critrios da norma, de forma a possibilitar que
a equipe de desenvolvimento seja capaz produzir software com alto grau de conformidade, mesmo no
tendo conhecimento da norma propriamente dita.

3.1.3. Inspeo de Consistncia

Inspeo de Consistncia avalia a usabilidade no mbito de uma famlia de interfaces, sendo

considerados aspectos como terminologia, cores, layouts, formatos de entrada e sada, alm de materiais
de treinamento, documentao para o usurio e help online.
Esta forma de reviso indicada para linhas de produtos, cujas interfaces devem manter
similaridades visando reduo dos custos e prazos de treinamento.
Este o caso, por exemplo, da avaliao de produtos segundo o guia de estilo para interfaces
MS Windows. desejvel que produtos desenvolvidos para este ambiente sejam aderentes s
45

46

recomendaes elementares quanto interface essa consistncia permite que o usurio aprenda os
princpios bsicos de operao uma s vez, e aplique esse conhecimento nos demais produtos disponveis
para o ambiente em questo [MICROSOFT 95].

3.1.4. Navegao Cognitiva

A Navegao Cognitiva requer que os especialistas assumam o papel de usurios e procurem

simular a interao que ocorreria entre os usurios e o sistema quando da execuo de tarefas mais
corriqueiras ou crticas.
Usualmente, este processo deve incluir as situaes potenciais de erro e, por conseqncia, as
de recuperao de falhas. Esta forma de reviso especialmente indicada para interfaces caracterizadas
pela interao exploratria.
Um interessante exemplo dessa forma de reviso pode ser visto em [GONTIJO 93]. Neste
trabalho, foi feita, em duas etapas, a avaliao de um editor de textos. Na primeira etapa, executou-se um
teste de usabilidade, sendo observados os usurios executando tarefas prescritas pelo grupo de avaliao.
Na Segunda, a prpria equipe de avaliao, simulando o papel de usurios, executou as tarefas prescritas.
Foram constatados problemas com relao aos dispositivos de entrada, vocabulrio, mecanismo de ajuda,
sintaxe, lgica de utilizao e de gerenciamento de erros.

3.1.5. Inspees Formais

Nas inspees formais, dois grupos de anlise crtica so formados, a equipe de

desenvolvimento e a equipe de avaliadores especialistas. Os grupos interagem como oponentes, discutindo
os mritos e deficincias da interface. As evidncias apresentadas por um grupo podem ser refutadas pelo
outro, cabendo a um mediador o papel de conduzir a discusso at que as concluses finais possam ser
obtidas. Embora sirva como uma experincia educacional rica, este tipo de reviso , entre todos, o que
demanda mais tempo e pessoal.

46

47

3.2. TESTES E E STUDOS L ABORATORIAIS

O teste de usabilidade, at bem pouco tempo atrs, parecia uma boa idia, mas inviabilizada
pelas tradicionais dificuldades de recursos e cronogramas alocados aos projetos [SHNEIDERMAN
98].
O crescente interesse pelas questes ergonmicas relativas ao software tem levado empresas a
estruturar seus prprios laboratrios de usabilidade [NIELSEN 94a]. Paralelamente, laboratrios
prestadores de servio e vinculados s instituies de pesquisa tambm tm proliferado.
A importncia desses laboratrios reside na abordagem cientfica dos aspectos relacionados
usabilidade. A reunio e combinao de tcnicas de teste e avaliao permite a reviso de conceitos e o
desenvolvimento de novas ferramentas, num ciclo evolutivo que tem muito a oferecer aos fornecedores de
programas e usurios de computador.
Basicamente, o funcionamento deste tipo de laboratrio no difere de outros laboratrios: h
um ambiente propcio para ensaios de interao, onde o usurio pode ser observado, tendo suas reaes
registradas por cmeras, recursos de captura de aes de teclado e mouse, e, algumas vezes, as prprias
expresses faciais e corporais.
Os usurios participantes dos experimentos so informados das condies em que se daro os
ensaios e, explicitamente, consentem que todos os aspectos da interao possam ser registrados.
Autorizam, ainda, que as condies da interao sejam controladas pelo grupo de avaliao: visando
observar as reaes do usurio, erros podem ser propositadamente inseridos na interao, interrupes
constantes podem ser feitas (telefone, rudos, conversao no ambiente de ensaio), tarefas incoerentes
podem ser solicitadas.
O objetivo dos ensaios laboratoriais avaliar, sob condies controladas, a usabilidade
oferecida, seja em situaes normais de interao, seja em situaes extremas.
Alm da observao registrada em vdeo, fazem parte das alternativas laboratoriais:
-

testes de campo: visando obter a viso mais realista possvel da interao, laboratrios
portteis so levados aos locais de trabalho onde o software ser utilizado. Uma nova e
47

48

freqente prtica de teste de campo o fornecimento de verses de teste para que os

usurios finais faam uso efetivo do produto, embora a verso comercial ainda no esteja
disponvel. Shneiderman relata que o maior teste de campo deste tipo foi realizado com o
Microsoft Windows 95 400.000 usurios em todo o mundo receberam a verso beta do
produto e puderam test-la e coment-la;
-

testes competitivos: usualmente aplicado para comparar a nova e a velha interfaces de um

produto. Embora restrita a casos de reformulao de interfaces de produtos, uma
poderosa tcnica que permite que poucos usurios produzam resultados suficientes para
uma boa anlise.

[MATIAS 95] relata a metodologia de trabalho do LabIUtil Laboratrio de Utilizabilidade

da Universidade Federal de Santa Catarina, que combina duas tcnicas de avaliao de interfaces: a
avaliao heurstica e os testes de usabilidade.
[MOO 96] descreve a aplicao de uma tcnica que envolve ensaios laboratoriais de
interao para a avaliao ergonmica de um editor de textos.

3.3. PESQUISAS DE OPINIO (SURVEYS )

As pesquisas de opinio constituem uma tcnica bastante comum de avaliao. So

comparativamente baratas e podem servir como um bom complemento para os testes de usabilidade e
revises especializadas [SHNEIDEMAN 98].
O sucesso das pesquisas de opinio depende da objetividade do instrumento de coleta
adotado. Quanto mais dirigido para os dados que se pretende analisar, e quanto menos ambguo, melhor
ser a eficcia do instrumento.
As entrevistas e os questionrios so instrumentos muito utilizados para este fim.[FIALHO 95]
assim classifica e distingue as entrevistas e os questionrios:
-

entrevista dirigida: em geral, efetuada a partir de um questionrio elaborado

previamente, onde existem questes objetivas a serem respondidas pelo entrevistado.

48

49

Distinguimos esta entrevista do questionrio, pois feita a partir do contato direto

entre entrevistado e entrevistador. O questionrio pode ser aplicado de forma a
dispensar essa relao pessoal. As informaes destas entrevistas podem ser
comparadas e analisadas estatisticamente;
-

entrevista informal: nesta entrevista no existe um protocolo estabelecido com

questes prvias. O entrevistado convidado a discorrer livremente sobre algumas
questes dirigidas pelo entrevistador. O que caracteriza este tipo de entrevista o
fato de no haver obrigao de uma amostra representativa, nem de uma anlise
estatstica das informaes.

Tambm a administrao do instrumento importante para o sucesso da pesquisa. A definio

da amostra tamanho e representatividade, se ser probabilstica (aleatria, estratificada, sistemtica ou
de grupo) ou no-probabilstica - permitir conferir mais ou menos autoridade s concluses
posteriormente obtidas. Ainda segundo Fialho, a deciso de considerar toda a populao para aplicar
os questionrios ou considerar uma amostra da populao depende, exclusivamente, do tamanho
da populao estudada ... a amostra que permite maiores generalizaes a amostra aleatria,
seguidas das amostras estratificadas, sistemticas e de grupo.
Finalmente, a certeza quanto s concluses obtidas , em ltima instncia, determinada pelas
anlises estatsticas efetuadas. [SHNEIDERMAN 98] sugere que se analise outras variveis alm da
mdia e desvio padro. [FIALHO 95] vai alm desta sugesto, indicando as situaes em que se deve
avaliar a possibilidade/necessidade de aplicao de testes paramtricos, estudo de correlaes e
aparelhagem.
Alguns trabalhos importantes relacionados com esta dissertao empregam esta forma de
avaliao:
-

[NORMAN 89] relata o desenvolvimento do QUIS Questionnaire for User

Interaction Satisfaction na Universidade de Maryland;

[OPPERMANN 97] referencia o SUMI Software Usability Measurement Inventory

desenvolvido como parte do Projeto MUSIC Metrics for Usability Standards in
Computing do Programa ESPRIT;
49

50

[PRUMPER 99] descreve brevemente o ISONORM 9241/10, que se baseia na norma

ISO 9241-10. Neste trabalho, Prumper compara os resultados obtidos por um grupo de
31 usurios que efetuaram duas avaliaes de um mesmo produto: uma usando o QUIS e,
depois, usando o ISONORM. O trabalho conclui que o ISONORM, apesar de mais
conciso, obteve resultados similares e uma correlao de 73% com o QUIS;

finalmente, [REITERER 93] apresenta o EVADIS II Evaluation of User Interfaces

uma verso aprimorada do questionrio voltado para especialistas desenvolvido por
Oppermann em 1988.

3.4. TESTES DE ACEITAO

O desenvolvimento tradicional de software determina que j nas etapas mais elementares do

projeto devam ser definidos os requisitos funcionais e operacionais do produto em questo. A estes
requisitos devem ser atribudos valores ou caractersticas que serviro como critrios de aceitao do
produto por parte do cliente.
Usualmente, estes critrios so definidos atravs da determinao de tempos de resposta para a
recuperao ou registro dos dados, para a emisso de relatrios, e outros aspectos afins. A aceitao do
sistema fica condicionada ao cumprimento dos limites estabelecidos. Ensaios com os usurios, antes da
entrega propriamente dita, permitem medir as variveis estabelecidas e compar-las com os valores
definidos. Caso estes limites no sejam adequadamente observados, a equipe de desenvolvimento precisa
fazer os ajustes necessrios at que os limites de aceitao possam ser atingidos.
Freqentemente, a definio de critrios de aceitao relativos interface de utilizao
caracterizada por uma enorme ambigidade. [SHNEIDERMAN 98] sugere a substituio de critrios
como interface amigvel e user friendly por parmetros efetivamente mensurveis, entre os quais:
-

tempo de aprendizagem;

tempo de resposta para determinada funo;

taxa de erros por usurio;

50

51

e grau de satisfao subjetivo do usurio (este critrio, em particular, evidencia a

necessidade de um estudo como o proposto por essa dissertao).

3.5. AVALIAO DURANTE O U SO ATIVO

O apoio ao efetivo uso por parte dos usurios, seja atravs de centrais de atendimento,
programas de treinamento ou, ainda, suporte local ou remoto, permite estreitar os laos de afinidades com
as comunidades que utilizam o sistema.
Dessa forma, impresses fornecidas pelos prprios usurios, a partir da utilizao real do
sistema, em seu ambiente de produo, permitem aprimorar e corrigir aspectos da interface.
[SHNEIDERMAN 98] sugere algumas formas de avaliao do uso ativo:
-

entrevistas e discusses com o grupo de usurios;

log de utilizao contnuo: a interao do usurio com o sistema, ou as situaes de erro,

podem ser registradas em arquivos especficos. A anlise destes dados pode apontar
necessidade de interveno corretiva ou de melhorias na interface. A recorrncia de falhas
de navegao tambm pode indicar a necessidade de reformulao das tcnicas de
treinamento dos usurios;

consultoria online ou por telefone: quando o fornecedor do produto possui centrais

dedicadas a atender aos usurios, os atendentes podem ser treinados para auxiliar a equipe
de desenvolvimento, seja apontando as falhas mais freqentemente registradas, seja
sugerindo alteraes percebidas a partir das dvidas e falhas relatadas pelos usurios;

caixa de sugestes ou relatrio de problemas online: a Internet e o e-mail podem ser

utilizados para permitir que o usurio estabelea um canal de comunicao com o
fornecedor. Este canal ser utilizado para o envio de relatos de falhas e de sugestes de
alteraes. Estes dados serviro para que a equipe de desenvolvimento perceba as
demandas mais freqentes e urgentes, alm de possibilitar a deteco de falhas no processo
de treinamento (geralmente percebido quando o usurio possui dvidas crticas quanto

51

52

utilizao do produto, ou quando solicita a implementao de recursos que j esto

presentes no produto, mas que o operador desconhece);
-

newsgroups: a criao de newsgroups permite que os usurios troquem experincias entre

si, alm de possibilitar que operadores mais experientes solucionem dvidas de usurios
iniciantes. Diante de uma dvida, o operador pode enviar uma mensagem para o grupo de
discusso, e aguardar que algum possa auxili-lo, seja porque j teve problema similar,
seja porque tem mais conhecimento do produto. As solues produzidas pelo grupo ficam
armazenadas e podem servir a outros usurios que venham a enfrentar o mesmo problema
no futuro. Alm disso, a equipe de desenvolvimento pode analisar os problemas e solues
registrados e determinar reformulaes na interface do produto e no processo de
treinamento;

newsletters ou conferncias: as conferncias permitem aos usurios, embora separados

pelas distncias geogrficas, criar um senso de comunidade, o que possibilita a troca de
experincias e fortalece a confiana no produto, alm de permitir um consenso sobre as
melhorias e correes necessrias. Os newsletters permitem que o fornecedor divulgue
informaes de interesse dos usurios como, dicas, estudos de casos bem sucedidos, alm
de antecipar alteraes planejadas. Podem estar disponveis em meio digital (CD-ROM,
downloads ou sites Internet) ou impressos, e permitem elevar o grau de satisfao e
conhecimento do usurio com relao ao produto.

3.6. EXPERIMENTAO PSICOLOGICAMENTE ORIENTADA

A avaliao de usabilidade a partir de experimentos de interao baseados em aspectos

psicolgicos constitui uma importante abordagem cientfica. Levando em conta aspectos cognitivos, so
propostas tarefas de interao aos usurios e observadas reaes e apreciaes do usurio.
[SHNEIDERMAN 98] relaciona algumas preocupaes comuns nestes experimentos:
-

lidar com um problema prtico e considerar a estrutura terica;

estabelecer hipteses lcidas e passveis de teste;

52

53

tomar os devidos cuidados com os fatores que possam influenciar as anlises estatsticas:
identificar e estabelecer os controles sobre as variveis independentes, e as medidas das
dependentes; selecionar e distribuir estatisticamente os participantes; controlar tendncias;
escolher e aplicar mtodos estatsticos adequados;

generalizar as concluses.

3.7. CONCLUSES

As preocupaes com aspectos relativos usabilidade de software devem acompanhar o

projeto desde suas fases iniciais. Para tanto, a seleo do mtodo de avaliao adequado deve levar em
conta custos, quantidade de pessoas a envolver, prazos e preciso esperada.
A abordagem ergonmica sugere a avaliao constante, em todo o ciclo de vida do produto.
Em busca de um alto grau de adequao s necessidades dos usurios, podem ser empregados mtodos
de avaliao em todo o processo de desenvolvimento.
No entanto, medida em que o usurio adquire maior familiaridade com o software, suas
expectativas mudam, e a evoluo do produto faz-se necessria. Usurios com graus de experincia
distintos tendem a requerer recursos de utilizao diferenciados. Portanto, mesmo aps a concluso do
produto, as avaliaes devem seguir. Em particular, nesta etapa, as pesquisas de satisfao podem adquirir
importncia significativa, possibilitando a deteco de melhorias ou correes consideradas necessrias
pelos usurios.

53

54

4. A NORMA ISO 9241

A norma ISO/IEC 9241 - Ergonomic requirements for office work with Visual Display
Terminals (VDTs) - teve seu primeiro draft apresentado em fevereiro de 1993 [PRUMPER 93]. Ainda
em desenvolvimento, a norma elaborada pelo Comit Tcnico ISO/TC 159 (Ergonomia), Sub-comit
SC 4 (Ergonomia de Interao Homem-Sistema) [ISO9241-10 96].
A tabela 4.1 exibe as partes da norma e suas respectivas situaes [SYSCON 99a]:
Parte
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Ttulo
Situao
General Introduction
Norma Internacional
Guidance on task requirements
Norma Internacional
Visual display requirements
Norma Internacional
Keyboard requirements
Norma Internacional
Workstation layout and postural requirements
Norma Internacional
Environmental requirements
Draft Final
Display requirements with reflections
Norma Internacional
Requirements for displayed colours
Norma Internacional
Requirements for non-keyboard input devices
Draft Final
Dialogue principles
Norma Internacional
Guidance on usability specification and measures Norma Internacional
Presentation of information
Norma Internacional a ser publicada
User guidance
Norma Internacional
Menu dialogues
Norma Internacional
Command dialogues
Norma Internacional
Direct manipulation dialogues
Draft Final
Form filling dialogues
Norma Internacional
Tabela 4.1 Partes da Norma ISO 9241
A norma aborda aspectos relativos a requisitos da tarefa, ambiente e estao de trabalho,

hardware e software (mais especificamente a interface de utilizao). A tabela 4.2 apresenta

agrupamento das partes da norma segundo o assunto abordado:

Assunto
Introduo
Recomendaes sobre requisitos da tarefa
Estao de trabalho e ambiente
Ergonomia do hardware
Ergonomia da interface de software

Partes
1
2
5e6
3,4,7,8 e 9
10 a 17

54

55

Tabela 4.2 Assuntos abordados pelas partes da Norma ISO 9241

Esta dissertao concentra-se nos aspectos relacionados ergonomia de software,
restringindo-se, por isso, s partes de 10 a 17.
[OPPERMANN 97] utiliza a estrutura descrita na tabela 4.3 para explicar o relacionamento
entre as partes da norma que abordam as questes de usabilidade. As recomendaes existentes nas
partes 10, 11 e 12 so de nvel mais geral, no havendo referncia a modelos de dilogo ou circunstncias
especficas. As partes 13, 14, 15, 16 e 17 apresentam recomendaes mais especficas, proporcionando
condies para que os objetivos das partes 10, 11 e 12 possam ser implementados.
Parte 11 Conduo da Usabilidade
Conceitos definidos: eficcia, eficincia e satisfao
Parte 12 Apresentao da Informao
Conceitos definidos: clareza, discriminao,
detectabilidade, legibilidade, compreensibilidade

conciso,

consistncia,

Parte 10 Princpios de Dilogos

Parte 17 dilogos de preenchimento de

formulrio

Parte 16 manipulao direta

Parte 15 dilogos de comando

Parte 14 dilogos de menu

Parte 13 - conduo do usurio

Conceitos definidos: adequao tarefa, auto-descrio, controlabilidade,

conformidade com as expectativas do usurio, tolerncia a erros, adequao
individualizao, adequao ao aprendizado

55

56

Tabela 4.3 Relao entre as partes da ISO 9241 que abordam a Usabilidade
As recomendaes da norma ISO 9241 so de natureza emprica, resultando de reviso
bibliogrfica existente [CYBIS 97], e possuem um perfil prioritariamente sugestivo, ou seja, raramente as
recomendaes podem ser entendidas como determinaes prescritas. As recomendaes so, em boa
parte, condicionais, apresentadas em regras do tipo SE-ENTO [ISO9241-14 97].
Os usurios potenciais da norma so [ISO9241-16 97]:
-

desenvolvedores de interfaces de sistemas, para os quais a norma pode servir como uma
boa ferramenta de conduo e de avaliao do projeto;

compradores que precisam definir critrios de avaliao comparativa entre os produtos

pesquisados;

avaliadores de usabilidade em geral;

projetistas de ferramentas de desenvolvimento (toolkits) de interfaces de utilizao.

O objetivo deste captulo apresentar, prioritariamente, uma reviso dos aspectos abordados
pela parte 10 da norma ISO 9241. Esta parte da norma, em particular, a base de toda a sistemtica de
avaliao proposta por esta dissertao. Tambm sero discutidas as demais partes cujas recomendaes
abordam aspectos relativos ao software (partes de 11 a 17), sem, no entanto, o mesmo grau de
detalhamento.

4.1. ISO 9241-10: P RINCPIOS DE DILOGO

Antes de se abordar a norma propriamente dita, dois conceitos sero amplamente utilizados no
decorrer desse e dos prximos captulos. Por isso, sero apresentados a seguir [ISO9241-10 96]:
-

dilogo: interao entre um usurio e um sistema visando alcanar um determinado

objetivo;

usurio: indivduo interagindo com o sistema.

56

57

A parte 10 da norma ISO 9241 descreve sete princpios de dilogos (adequao tarefa, autodescrio, controlabilidade, conformidade com as expectativas dos usurios, tolerncia a erros, adequao
individualizao e adequao ao aprendizado) referentes s interfaces de software. Estes princpios so
genricos e, portanto, podem ser aplicados como recomendaes gerais, independentemente da tcnica
especfica de dilogo que tenha sido adotada no projeto da interface (menu, manipulao direta,
formulrios e linguagens de comando) [ISO9241-10 96].
A aplicabilidade de cada recomendao deve levar em considerao:
-

o perfil dos usurios potenciais (grau de ateno requerido, limites da memria de curto
termo, ambiente de aprendizagem, nvel de experincia na atividade e no sistema, a viso
que o usurio possui do sistema);

a tarefa em questo;

o ambiente de utilizao do sistema;

a tcnica de dilogo empregada;

do peso relativo de cada princpio ao levar em conta os objetivos da organizao,

necessid ades dos usurios, tarefa, tecnologia e recursos disponveis (o que pode determinar
que seja dada a preferncia satisfao de alguns princpio em detrimento de outros).

A seguir, cada um dos princpios ser detalhado e as recomendaes de aplicao sero

descritas.

4.1.1. Adequao Tarefa

O dilogo considerado adequado tarefa se possibilita que o usurio execute a tarefa com
eficincia e eficcia.
As aplicaes deste princpio sugeridas pela norma so enumeradas a seguir:

57

58

a) o dilogo deve apresentar ao usurio somente informaes pertinentes execuo

da tarefa. Ex.: informaes como o nome do usurio que est loggado no sistema s
devem ser exibidas se auxiliarem na concluso da tarefa em andamento;
b) informaes de ajuda (help) devem ser relacionadas com a tarefa. Ex.: quando o
usurio de um editor de textos estiver em dvida sobre como formatar o texto no dilogo
especfico para este fim, ao acionar o help, ao invs do ndice geral de ajuda, devem ser
exibidas imediatamente as informaes relativas aos recursos de formatao;
c) qualquer ao que possa ser apropriadamente assumida pela interface do software
para execuo automtica, dever ser executada sem envolvimento do usurio . Ex.:
ao se criar um novo documento em um editor de textos, o sistema deve abrir um
documento vazio e posicionar o cursor na primeira linha;
d) ao se projetar o dilogo, deve ser considerada a complexidade da tarefa com
relao s habilidades e experincias do usurio . Ex.: em campos cujos valores
possveis so pr-estabelecidos, os usurios devem ter fcil acesso lista de valores
possveis;
e) os formatos de entrada e sada devem ser apropriados tarefa em questo e aos
requisitos do usurio. Ex.: a seqncia de preenchimento e o formato dos campos na tela
devem obedecer seqncia e ao formato dos campos do documento original, caso exista;
f) o dilogo deve apoiar o usurio quando estiver executando tarefas recorrentes. Ex.:
se o usurio precisa elaborar a mesma correspondncia para vrios destinatrios,
conveniente que o editor de textos possua recursos de mala direta;
g) se h possibilidades de entradas default para uma tarefa, no deve ser necessrio
que o usurio informe estes valores. Deve tambm ser possvel substituir os valores
default por outros valores ou outros default apropriados. Ex.: em um sistema de
cadastro de clientes onde h predominncia de pessoas do sexo masculino, o valor default
para o campo sexo pode ser M. Mas, ao operador dever ser possvel trocar este valor
para F se estiver cadastrando um cliente do sexo feminino;

58

59

h) durante a execuo de uma tarefa na qual dados so modificados, os dados originais

devem permanecer acessveis caso a tarefa venha a requerer. Ex.: em um editor de
textos, deve haver recursos para facilmente desfazer modificaes;
i) o dilogo deve evitar forar o usurio a executar passos da tarefa desnecessrios.
Ex.: o usurio deve ser capaz de imprimir um texto diretamente a partir de sua visualizao.

4.1.2. Auto-descrio

O dilogo considerado auto-descritivo se o usurio consegue compreend-lo imediatamente,

seja a partir de feedback automtico do sistema, seja a partir da solicitao de explicaes.
A seguir so enumeradas as aplicaes deste princpio sugeridas pela norma:
a) depois de qualquer ao, o dilogo deve proporcionar feedback quando apropriado.
Se conseqncias severas podem resultar da ao do usurio, o sistema deve
proporcionar explicao e requerer confirmao antes de executar a ao. Ex.: caso
o usurio tenha fornecido dados de um novo cliente na tela de cadastramento e, a seguir,
solicite o fechamento da tela sem salvar os dados informados, o sistema dever alertar que
os dados sero perdidos e perguntar se o usurio realmente no deseja salvar os dados;
b) feedback ou explicaes devem ser apresentados em uma terminologia consistente,
isto , derivada do ambiente da tarefa, e no da tecnologia do sistema de dilogo.
Ex.: ao invs da mensagem Impossvel deletar registro da tabela municpio porque viola a
integridade referencial com a tabela cliente, deve-se informar, por exemplo, No
possvel remover o municpio Florianpolis porque h clientes cadastrados neste
municpio;
c) feedback ou explicaes devem auxiliar o usurio na obteno de um entendimento
geral do sistema de dilogo como um possvel complemento ao treinamento do
usurio. Ex.: durante a execuo de clculos mais prolongados, por exemplo a mensagem
Calculando o valor da medio deve ser exibida;

59

60

d) feedback ou explicaes devem ser baseados no nvel de conhecimento que se espera

de um usurio tpico. Ex.: usurios iniciantes devem receber explicaes com maior grau
de detalhamento, e usurios mais experientes devem receber informaes mais objetivas e
em terminologia mais adequada ao seu vocabulrio;
e) feedback ou explicaes variados em tipo e tamanho, baseados nas necessidades e
caractersticas dos usurios, devem estar disponveis ao usurio . Ex.: os usurios
podero selecionar no help o tipo de auxlio desejado: tutoriais, assistentes, exemplos ou
explicaes com distintos graus de detalhamento;
f) para ampliar seu valor para o usurio, feedback ou explicaes devem estar
estritamente relacionados com a situao para a qual so necessrios. A qualidade do
feedback e das explicaes deve minimizar a necessidade de consulta a manuais do
usurio e outras informaes externas, assim evitando freqentes trocas de mdia.
Ex.: as mensagens de help devem ser sensveis ao contexto a partir do qual foram
solicitadas;
g) se existem defaults para uma determinada tarefa, eles devem ficar disponveis para
o usurio. Ex.: se, em um sistema de cotaes de moeda, a maior parte das operaes de
converso feita para dlar, ento este poder ser o default para o campo Moeda
Destino;
h) o usurio deve ser informado sobre as mudanas no estado do sistema de dilogo
relevantes para a tarefa. Ex.: quando um clculo extenso est sendo executado, pode-se
exibir a mensagem Executando clculo. Ao trmino do clculo, a mensagem Clculo
concludo pode ser exibida;
i) quando uma entrada requerida, o sistema de dilogo deve dar ao usurio
informaes sobre a entrada esperada. Ex.: ao lado do campo CGC pode ser exibida a
mscara de entrada correspondente;
j) mensagens devem ser formuladas e apresentadas em um estilo construtivo, objetivo
e compreensvel, e em uma estrutura consistente. As mensagens no devem conter
qualquer juzo de valor, como Esta entrada no faz sentido . Ex.: no caso de um
60

61

sistema de atendimento bancrio, pode-se fornecer a mensagem Por favor, informe o

nmero da conta sem pontos ou hfens.

4.1.3. Controlabilidade

A controlabilidade atribuda ao dilogo quando o usurio consegue iniciar a interao,

determinar a sua direo e gerenciar o ritmo at a concluso da tarefa.
A norma sugere as seguintes aplicaes para este princpio:
a) a velocidade da interao no deve ser ditada pela operao do sistema. Ela deve
estar sempre sob controle do usurio, de acordo com suas necessidades e
caractersticas. Ex.: nenhum dado deve ser salvo a menos que o usurio o determine ou
consinta;
b) os dilogos devem dar ao usurio o controle sobre como continuar o dilogo. Ex.: a
seqncia de preenchimento de campos na tela pode ser sugerida pelo sistema, mas o
usurio deve ser capaz de adotar uma seqncia de sua preferncia;
c) se o dilogo foi interrompido, o usurio deve ser capaz de determinar o ponto de
reincio quando o dilogo for retomado, desde que a tarefa permita. Ex.: se o usurio
estava executando uma operao de transferncia bancria e o dilogo foi interrompido, ao
ser retomado o dilogo, deve ser possvel ao usurio optar por continuar a operao do
ponto em que se encontrava ou desfazer os passos executados at o momento da
interrupo;
d) se as interaes so reversveis e a tarefa permite, deve ser possvel ao usurio
desfazer, pelo menos, o ltimo passo do dilogo. Ex.: a opo undo, dos editores de
textos e planilhas, eletrnicas permite reverter seqncias de alteraes efetuadas pelo
usurio;
e) diferentes necessidades e caractersticas dos usurios requerem diferentes nveis e
mtodos de interao. Ex.: os usurios mais experimentados devero possuir recursos

61

62

que lhes permitam agilizar a interao com teclas de atalho e macros. Usurios novatos
podem contar com menus e assistentes que auxiliaro na interao com o sistema;
f) as maneiras como entradas e sadas so representadas (formato e tipo) devem estar
sob controle do usurio. Ex.: caso o usurio deseje e a tarefa permita, ao invs de obter
uma lista de municpios que satisfaa a um critrio de consulta, o usurio pode optar por t los plotados em um mapa;
g) se o controle da quantidade de dados apresentados til para uma tarefa particular,
o usurio deve ser capaz de exercitar este controle. Ex.: se, na visualizao de um
relatrio, a pgina que interessa ao usurio for a ltima, ele dever ser capaz de chegar ela
sem visualizar as anteriores;
h) onde houver alternativas de dispositivos de entrada e sada, o usurio dever ter a
opo de escolher qual utilizar. Ex.: ao invs de movimentar o cursor entre os campos
da tela por meio do mouse, o usurio poder faz-lo utilizando as teclas de tabulao.

4.1.4. Conformidade com as Expectativas do Usurio

A conformidade com as expectativas do usurio obtida pelo dilogo atravs da consistncia e

adequao s caractersticas do usurio (experincia, grau de instruo e conhecimento).
As aplicaes da norma para este princpio so:
a) o comportamento e a aparncia do dilogo dentro de um sistema de dilogo devem
ser consistentes. Ex.: uma mesma tecla usada para a funo salvar jamais ser utilizada
no sistema para apagar;
b) aes de mudana de estado devem ser implementadas consistentemente. Ex.: a
tecla Esc sempre cancela a operao corrente;
c) a aplicao deve usar o vocabulrio familiar ao usurio no que se refere execuo
da tarefa. Ex.: os termos usados nas mensagens, bem como nomenclatura de campos e
funes, devem usar o vocabulrio relacionado com a tarefa;
62

63

d) dilogos usados para tarefas similares devem ser similares, de forma que o usurio
possa desenvolver procedimentos comuns de resoluo da tarefa. Ex.: nos browsers,
ao se posicionar o cursor sobre um link a sua representao muda sempre para uma
mesma forma, indicando que se pode clicar naquele tpico para dar seqncia
navegao;
e) feedback imediato sobre a entrada do usurio deve ser apropriado s expectativas
do usurio, devendo ser baseado no nvel de conhecimento do usurio. Ex.: quando o
usurio solicita a execuo de uma tarefa mais prolongada, a ampulheta apresentada,
sugerindo que aguarde a concluso;
f) o cursor deve estar onde a entrada necessria. Ex.: quando apropriado, ao
pressionar a tecla de tabulao, o cursor posicionado no prximo campo cuja entrada
requerida;
g) se o tempo de resposta tende a se desviar consideravelmente do tempo de resposta
esperado, o usurio deve ser informado disso. Ex.: no caso de um download de
arquivos extensos, conveniente fornecer ao usurio uma indicao grfica da progresso
do processo.

4.1.5. Tolerncia a Erros

O dilogo considerado tolerante a erros quando permite ao usurio obter os resultados

desejados e, ao mesmo tempo, minimiza a necessidade de correo dos erros de entrada.
As aplicaes da norma para este princpio so:
a) a aplicao deve apoiar o usurio na deteco e preveno de erros de entrada. O
sistema de dilogo deve prevenir qualquer entrada do usurio de causar estados de
dilogo indefinidos ou estados de falha. Ex.: a interface no permite que um cliente
tenha sua idade cadastrada com valor negativo;

63

64

b) erros devem ser explicados de forma a auxiliar o usurio a corrigi-los. Ex.: diante de
uma valor de idade invlido, o sistema pode emitir a mensagem Idade invlida. Por favor,
informe um valor entre 0 e 150.;
c) dependendo da tarefa, pode ser desejvel aplicar esforo especial nas tcnicas de
apresentao para melhorar o reconhecimento de situaes de erro e respectivas
recuperaes. Ex.: valores invlidos so exibidos com cores diferenciadas de forma a
chamar a ateno do operador;
d) em casos onde o sistema de dilogo capaz de corrigir os erros automaticamente,
ele deve avisar ao usurio sobre as correes e proporcionar a oportunidade de
alterar as correes. Ex.: no caso de editores de textos, caso o corretor ortogrfico
detecte um provvel erro, a correo automtica adotada dever ser passvel de alterao
por parte do usurio;
e) as caractersticas e necessidades do usurio podem requerer que as situaes de
erros sejam adiadas, deixando ao usurio a deciso de quando e como trat-las. Ex.:
em caso de processamento remoto, ao invs de cada campo ser verificado medida em
que fornecido (o que tende a ser mais demorado), pode ser conveniente deixar ao usurio
a opo de enviar os dados para validao somente aps a tela estar completamente
preenchida;
f) desejvel proporcionar explicaes adicionais durante a correo do erro, caso o
usurio solicite. Ex.: a mesma caixa de dilogo que apresenta a mensagem de erro pode
possuir um boto que fornea mais detalhes sobre o erro;
g) a validao e a verificao dos dados devem ser executadas antes do processamento
das entradas. Controles adicionais devem ser proporcionados no caso de comandos
com conseqncias srias. Ex.: quando solicitada a remoo de um arquivo, deve-se
requerer confirmao;
h) quando a tarefa permitir, a correo de erro deve ser possvel, sem que, para isso,
seja necessria a troca de estados do sistema de dilogo. Ex.: quando pertinente, aps

64

65

ser apresentada a mensagem de erro, a entrada invlida dever permanecer na tela, sendo
permitido ao usurio edit-la e corrigi-la.

4.1.6. Adequao Individualizao

O dilogo dito adequado individualizao se a interface de utilizao pode ser modificada

para atender s necessidades da tarefa, preferncias individuais e experincia do usurio.
As aplicaes da norma para este princpio so:
a) mecanismos devem estar disponveis para permitir que o dilogo seja adaptado
cultura e linguagem do usurio, conhecimento individual e experincia de domnio
da tarefa, habilidades cognitivas, senso-motoras e perceptivas. Ex.: usurios com
problemas de viso devem ter a seu alcance recursos para alterao de fontes (tipo e
tamanho) e cores;
b) o sistema de dilogo deve permitir ao usurio escolher formas de representao
alternativas de acordo com preferncias individuais e complexidade da informao a
ser processada . Ex.: usurios podem, por exemplo, ter acessso a recursos para exibir
dados em formato de grfico ou planilhas;
c) a quantidade de explicaes (por exemplo, detalhes nas mensagens de erros e
informao de help) deve ser modificvel de acordo com o nvel individual de
conhecimento do usurio . Ex.: o sistema pode permitir que o usurio configure o nvel de
detalhamento das mensagens apresentadas novato, intermedirio ou avanado;
d) o usurio deve possuir recursos para incorporar seu prprio vocabulrio para
determinar nomes de objetos e aes, caso seja adequado aos contextos ou s tarefas.
Deve ser possvel para o usurio adicionar comandos individualizados. Ex.: o sistema
pode prover recursos de criao de macros, captura de seqncias de teclas e
programao de teclas de funo;

65

66

e) o usurio deve ser capaz de configurar parmetros de tempo operacional de acordo

com suas necessidades individuais. Ex.: o sistema pode, quando cabvel, prover
recursos que permitam ao usurio determinar se algumas caixas de dilogo de confirmao
devero ou no ser exibidas;
f) os usurios devem ser capazes de escolher diferentes tcnicas de dilogo para
diferentes tarefas. Ex.: uma funo pode ser ativada mediante teclas de atalho ou
navegao orientada por menu.

4.1.7. Adequao ao Aprendizado

O dilogo considerado adequado ao aprendizado se suporta e guia o usurio na

aprendizagem do uso do sistema.
As aplicaes da norma para este princpio so:
a) regras e conceitos subjacentes que sejam teis ao aprendizado devem estar
disponveis para o usurio, de forma a permitir que o usurio construa seu prprio
agrupamento de estratgias e regras para atividades de memorizao. Ex.: atalhos
para opes de menu e botes so representados por letras destacadas nos ttulos dos
objetos, permitindo ao usurio traar correspondncias bvias entre os atalhos e os objetos
relacionados;
b) estratgias de aprendizado relevantes (por exemplo, orientadas para a compreenso,
aprendizado pela utilizao e aprendizado por exemplo) devem estar disponveis.
Ex.: o sistema pode proporcionar ao usurio, entre outros recursos, tutoriais interativos,
assistentes (wizards), helps que descrevem e exemplificam as funes;
c) facilidades de reaprendizado devem ser fornecidas. Ex.: o projeto pode privilegiar
atalhos para tarefas mais freqentes e mecanismos de conduo e orientao explicativa
para tarefas menos freqentes. Assistentes ativos podem detectar situaes em que o
mesmo comando repetido pelo usurio com muita freqncia, e fornecer ao usurio
mensagens de ajuda que ensinam como programar um comando para execuo repetitiva;
66

67

d) devem ser proporcionados diferentes meios para auxiliar o usurio a se tornar

familiarizado com os elementos de dilogo. Ex.: a seqncia de botes mantida
idntica em todas as telas do sistema.

4.2. ISO 9241-11: C ONDUO DA USABILIDADE

A parte 11 da norma Conduo da Usabilidade - conceitua a usabilidade [ISO9241-11 98]

(capacidade que o produto apresenta para ser utilizado por usurios especficos para alcanar
metas especficas com eficcia, eficincia e satisfao, em um contexto de uso especfico) e formula
recomendaes para a mensurao das qualidades ergonmicas da interface, levando em conta os
seguintes fatores de qualidade:
-

eficcia: grau de preciso e de abrangncia obtidos pelo usurio na interao com o sistema
visando atingir seus objetivos;

eficincia: proporo de recursos (tempo, mentais, fsicos, operacionais, ambientais,

hardware e software) empregados para que o usurio atinja seus objetivos (eficcia);

a satisfao: entendida pela norma como o grau de conforto e de reao favorvel do

operador no que se refere ao uso do sistema.

So formuladas recomendaes para:

-

especificao e mensurao da usabilidade de produtos de software;

especificao e avaliao da usabilidade durante o projeto;

especificao e avaliao da usabilidade durante o uso.

4.3. ISO 9241-12: A PRESENTAO DA INFORMAO

A parte 12 da norma Apresentao da Informao aborda, principalmente, recomendaes

de projeto referentes s questes visuais da interface [ISO9241-12 98]. As recomendaes so aplicveis
a todas as fases de projeto, alm do teste e avaliao de usabilidade.
67

68

So conceitos definidos e amplamente utilizados nesta parte da norma:

-

clareza: caracterstica de apresentao que permite a compreenso rpida e precisa da

informao;

discriminao: capacidade que uma informao possui de se distinguir das demais;

conciso: capacidade de reduzir a quantidade de informao apresentada poro

necessria e suficiente para que o usurio execute a tarefa;

consistncia: habilidade de exibir uma mesma informao de uma nica maneira por todo o
sistema;

detectabilidade: capacidade que uma informao possui de chamar a ateno do usurio

quando requerida;

legibilidade: facilidade de leitura de uma informao;

compreensibilidade: capacidade que uma informao possui de se fazer reconhecer,

interpretar e entender sem ambigidade.

Esta parte da norma aborda, ainda:

-

as condies de aplicao das recomendaes,

o uso da norma para avaliao de produtos;

as questes especficas de exibio da informao: organizao, preocupaes relativas aos

objetos grficos e tcnicas de codificao.

4.4. ISO 9241-13: C ONDUO DO USURIO

A parte 13 da norma - Conduo do Usurio aborda os requisitos complementares aos

dilogos [ISO9241-13 98]: prompts, feedback, estados do sistema, suporte a erros e facilidades de
helps. So formuladas recomendaes relativas s estratgias de direcionamento do dilogo visando
facilitar a navegao por parte do usurio e evitar estados de interao inconsistentes ou no previstos.
68

69

A maior preocupao desta parte da norma propor mecanismos para reduzir a carga de
trabalho mental, ampliar a gesto de erros e adequar o grau de assistncia do sistema s necessidades e
caractersticas do usurio e da tarefa [CYBIS 97].
A aplicao dos princpios de dilogos (partes 10, 14, 15, 16 e 17) significativamente
facilitada pela adoo das recomendaes constantes da parte 13 [OPPERMANN 97].

4.5. ISO 9241-14: D ILOGOS DE M ENU

A parte 14 Dilogos de Menu sugere que esta modalidade de interao aplicvel quando
[ISO9241-14 97]:
-

a freqncia de uso da aplicao no grande;

o conjunto de opes disponveis para o usurio muito extenso, o que dificulta a

memorizao;

o pblico-alvo inclui, alm de usurios experientes, quantidade razovel de usurios

novatos, que possuem pouco treinamento e precisaro de constante orientao de
navegao;

o usurio tpico tem pouca habilidade de digitao.

So feitas recomendaes relativas:

-

estruturao dos menus: nveis de menu, agrupamento e seqncia das opes;

navegao: dicas e atalhos;

aos mtodos de seleo: opes de seleo e execuo, o uso do teclado (teclado

numrico, alfanumrico, teclas de funo e de movimentao) e dos dispositivos de
apontamento (trackball, mouse e outros).

69

70

4.6. ISO 9241-15: D ILOGOS DE C OMANDO

A parte 15 Dilogos de Comando recomenda esta modalidade de interao quando

[ISO9241-15 97]:
-

a freqncia de uso da aplicao grande;

o pblico-alvo tem razovel habilidade de digitao, estando familiarizado com tecnologia

de informtica e o uso de linguagens de comando, sendo necessrio fornecer-lhe
unicamente o treinamento relativo linguagem de comando em questo;

a tarefa caracterizada pela necessidade de acesso rpido s funes do sistema e pela

impossibilidade de se prever seqncias e opes de aes durante a interao.

So feitas recomendaes relativas:

-

estruturao da linguagem: consistncia interna, estrutura dos argumentos, sintaxe,

separao dos comandos, formatos, quantificadores e outras;

representao dos comandos: entre outras, a distino, orientao do usurio, tamanho

dos comandos, abreviaes, teclas de funo e atalhos;

s consideraes de entrada e sada: reutilizao e enfileiramento de comandos, correo

de erros, edio, defaults, customizao e formatos de sada;

as estratgias de feedback e help: principalmente o processamento de comandos,

feedback de erros e auxlio ao aumento de produtividade.

4.7. ISO 9241-16: D ILOGOS DE M ANIPULAO DIRETA

A parte 16 Dilogos de Manipulao Direta sugere esta modalidade de interao para as

seguintes situaes [ISO9241-16 97]:

70

71

as capacidades senso-motoras do usurio so mais importantes que suas habilidades de

leitura e escrita, permitindo que se obtenha maior produtividade a partir de mecanismos de
representao grfica, em detrimento das descries textuais;

o uso de metforas permite representar significativamente as propriedades dos objetos reais

e as operaes a que esto sujeitos;

as tarefas no possuem freqncia regular, sendo caracterizadas pela imprevisibilidade das

seqncias de aes. A interao, por sua vez, facilitada pela representao visual das
alteraes sofridas pelos objetos da tarefa.

So feitas recomendaes relativas:

-

s metforas: so feitas consideraes sobre a propriedade de se adotar ou no metforas

especficas. A norma sugere que seja cuidadosamente analisada a adequao da metfora e
exemplifica o caso de uma aplicao imprpria: a metfora de um livro eletrnico pode
tornar-se significativamente improdutiva caso, da mesma forma que o livro real, o modelo
eletrnico no possua outro recurso para se chegar a um tpico que no seja folhear cada
pgina at encontrar o assunto desejado;

aparncia dos objetos usados na manipulao direta: so abordadas questes relativas ao

tamanho da rea manipulvel, distino dos objetos, aparncia dos objetos no-disponveis
ao momento da interao, entre outras;

ao feedback: so feitas recomendaes, por exemplo, quanto sinalizao dos cursores no

que se refere disponibilidade dos objetos para o momento da interao, e objetos cuja
interao requerida;

aos dispositivos de entrada: so mencionadas consideraes quanto aos dispositivos

alternativos, tcnicas de atalho e minimizao de trocas de dispositivos;

manipulao dos objetos: so feitas consideraes no que se refere aos mecanismos de

seleo mltipla e simples, manipulao simultnea de vrios objetos, acesso objetos
sobrepostos, mecanismos de eficincia, entre outras.

71

72

4.8. ISO 9241-17: D ILOGOS DE P REENCHIMENTO DE FORMULRIOS

A parte 17 Dilogos de Preenchimento de Formulrios recomenda esta tcnica de dilogo

para os seguintes casos [ISO9241-17 98]:
-

o usurio tpico do sistema tem boas habilidades de digitao e est familiarizado com
formulrios em papel, mas tem pouca experincia no uso de computadores;

os dados fornecidos ao sistema tm origem em formulrios de papel ou so obtidos

mediante conversao entre o operador e um entrevistado. A maior parte das entradas, ao
invs de comandos, constituda de valores, para os quais so convenientes a exibio de
default e a disponibilidade de mecanismos de seleo;

no h a necessidade de exibio de grandes quantidades de alternativas de entrada e as

seqnc ias de interao so menos flexveis, podendo ser previstas com alguma facilidade.

So feitas recomendaes relativas:

-

estrutura de preenchimento de formulrios: so feitas recomendaes sobre os ttulos (os

ttulos dos formulrios devem ser facilmente visualizados, distintos e representativos do seu
propsito no sistema), codificao visual (por exemplo, o sistema deve diferenciar os dados
exibidos no formulrio, distinguindo visualmente os que foram fornecidos pelo usurio, os
defaults e os que foram extrados a partir de passos anteriores da interao), densidade de
informao (sugere-se que o espao ocupado pelas informaes no ultrapasse a 40% do
espao total da tela), layout (por exemplo, recomenda-se que a tela seja consistente - em
tamanho, tipo e seqncia dos campos com formulrio original de papel, caso exista),
entre outras;

s consideraes de entradas: so mencionadas recomendaes para estabelecer

estratgias de movimento do cursor, fornecimento de valores default, alternncia entre
dispositivos de entrada, compatibilidade dos tipos de dados, opes de entradas (exclusiva,
binria e no-exclusiva), controle (correo, localizao de erros, rea de entradas de
dados, salvamento temporrio de dados) e validao de campos (simples e mltipla);

72

73

ao feedback: so recomendadas estratgias para exibio dos caracteres teclados, para

exibio da posio do ponteiro ou cursor, erros, sinalizao de aceitao das aes por
parte do sistema e alteraes em bases de dados;

navegao: so feitas recomendaes sobre o posicionamento inicial do cursor, a

movimentao entre campos, o uso de tabulaes, scroll (horizontal e vertical) e
mecanismos de seleo de formulrios (acesso direto, movimentao entre formulrios,
hierarquia, entre outras).

Esta parte da norma apresenta, em um anexo, uma sugesto de checklist para avaliao da
aplicabilidade e aderncia s recomendaes propostas.

4.9. CONCLUSES

A norma ISO 9241, especialmente nas partes pertinentes Ergonomia de Software, mostra-se
um padro razoavelmente completo que pode ser aplicado, tanto como guia de orientao de projeto,
quanto ferramenta para avaliao de usabilidade.
Especificamente a parte 10, Princpios de Dilogos, refora a importncia e a eficcia da
determinao e uso de critrios ergonmicos no desenvolvimento de interface de software, como foi
demonstrado por [BASTIEN 93].
A comparao entre os critrios descritos no Captulo 2 e os princpios e recomendaes da
norma evidenciam a recorrncia de definies e a estreita correlao entre os trabalhos de levantamentos
de qualidades ergonmicas mnimas desejveis para os produtos de software.
No entanto, o uso da norma como ferramenta de avaliao apresenta algumas vantagens sobre
as demais propostas:
-

a ISO o ponto de convergncia da ateno de todos que buscam amparo em algum tipo
de padro. Portanto, bastante provvel que, ao invs de tomar contato com outros
critrios de projeto e avaliao de usabilidade, eventuais interessados venham a buscar nas
recomendaes da norma o suporte desejado;

73

74

a norma internacional tende a contar com maior aceitao junto aos fornecedores de
software, especialmente se vier a ser adotada como modelo de certificao de produto;

embora a elaborao, votao e aprovao da norma seja um processo moroso, a

negociao entre os votantes permite obter maior consenso sobre as questes ergonmicas
prioritrias para fornecedores, pesquisadores e usurios;

a norma evolutiva, e sua reviso garante a possibilidade de adequao s novas

tecnologias e demandas de mercado. Alm disso, as revises, medida em que incorporam
novas recomendaes e modificam as j existentes, tendem a exigir constante esforo de
adequao e evoluo das empresas fornecedoras de software, o que tem o poder de
impulsionar o nvel de usabilidade dos produtos;

o uso da norma no excludente. Suas recomendaes, tomados alguns cuidados visando

manter a coerncia, podem ser combinadas com outras extradas de trabalhos como os
citados no Captulo 2;

o custo da adoo da norma bastante inferior ao desenvolvimento de uma sistema de

avaliao proprietria. A norma encontra-se quase integralmente aprovada, e o custo de
sua adoo basicamente restringe-se sua aquisio, investimento em leitura, interpretao
e aplicao. O desenvolvimento de uma sistemtica prpria provavelmente demandar um
investimento em pesquisa, contratao de especialistas e anlise da validade dos resultados
obtidos.

74

75

5. O QUESTIONRIO ISONORM 9241/10

A realizao de pesquisas de opinio, especialmente atravs da aplicao de questionrios, est

entre as tcnicas mais utilizadas para avaliao de usabilidade [SHNEIDERMAN 98]. A opo por esta
forma de avaliao tem vrias justificativas:
-

relativamente barata [PRUMPER 93];

permite determinar o grau de severidade das falhas detectadas e, conseqentemente,

estabelecer prioridades para as aes interventivas [NIELSEN 90];

possibilita estimar o impacto mercadolgico das qualidades e falhas encontradas no produto

[NIELSEN 90];

um bom complemento para os testes e inspees de usabilidade [SHNEIDERMAN 98].

Tradicionalmente, um modelo de questionrio baseia-se nas experincias e heursticas

particulares de seus elaboradores. medida em que utilizado em pesquisas reais ou simuladas, o modelo
depara-se com circunstncias e necessidades no previstas inicialmente. Estes fatores determinam os
ajustes e refinamentos, que aplicados sucessivamente, permitiro a evoluo das questes e dos dados de
qualificao da amostra populacional [NIELSEN 94].
Este captulo apresenta um questionrio (Anexo 1) cuja base de elaborao difere da
abordagem tradicional: o ISONORM 9241/10 [PRUMPER 93]. Este modelo de questionrio baseado
na norma ISO 9241, e objetiva avaliar a conformidade dos produtos de software com as recomendaes
constantes da parte 10 da norma.
A traduo deste questionrio foi utilizada nos experimentos relatados no Captulo 6 desta
dissertao.
So ainda apresentados experimentos de [PRUMPER 99], nos quais avaliada a correlao
entre os resultados obtidos pelo ISONORM 9241/10 e dois outros modelos de questionrios com ampla
aceitao junto comunidade relacionada com a avaliao de usabilidade:

75

76

QUIS - Questionnaire for User Interaction Satisfaction da Universidade de Maryland

[NORMAN 89], integralmente disponvel em http://www.lap.umd.edu/QUIS/index.html;

EVADIS II - Evaluation of User Interfaces um questionrio voltado para especialistas

em usabilidade [REITERER 93].

Este estudo comparativo particularmente importante porque permite justificar a escolha do

questionrio ISONORM como ferramenta utilizada por esta dissertao.

5.1. A ESTRUTURA DO QUESTIONRIO

O formulrio divide as questes em sete sees, de acordo com os princpios de dilogo da

parte 10 da norma ISO 9241 (ver Captulo 4):
-

Adequao Tarefa;

Auto-descrio;

Controlabilidade;

Conformidade com as Expectativas do Usurio;

Tolerncia a Erros;

Adequao Individualizao;

Adequao ao Aprendizado.

Embora cada um dos princpios da norma possua quantidade diferente de recomendaes, foi
estabelecido um limite de cinco questes para cada princpio. Segundo [PRUMPER 99], o objetivo desta
limitao reduzir o tempo de preenchimento do formulrio a, no mximo, dez minutos.
O formato das questes segue o exemplo mostrado na tabela 5.1.

76

77

As respostas so separada em dois plos, o esquerdo descreve o extremo negativo, e o direito

descreve o extremo positivo. Os valores possveis para as respostas variam entre --- e +++
(codificados em um intervalo entre 1 e 7), cabendo ao avaliador marcar com um X a sua opo.
O software ...
---

--

+/-

requer muito tempo

para aprender.

+
X

++ +++
requer pouco tempo para
aprender.

Tabela 5.1 Exemplo de questo do ISONORM 9241/10

No exemplo anterior, o hipottico avaliador, quando questionado sobre o tempo de
aprendizagem do software, respondeu que est razovel, mas melhoria significativa necessria.
A linguagem adotada procura ser a mais familiar possvel operao e tarefa,
independentemente do produto ou atividade para a qual se destine.
H, ainda, uma seo adicional destinada a qualificar:
-

o software avaliado: nome do produto, verso, produtor e mdulo ou componente

(omitido na traduo para o portugus);

e o perfil do entrevistado: profisso, idade, sexo, tempo de experincia com relao ao

produto, tempo de experincia em informtica, quantidade de horas semanais reservadas
para uso do produto, quantidade de horas semanais reservadas para o uso de computador,
quantidade de programas usados no dia-a-dia. Foram omitidos na traduo para o
portugus: grau de conhecimento do produto, primeira letra do local de nascimento, ltima
letra do nome da me, primeira letra do nome da me, ltima letra do nome do
entrevistado. Foram includos na verso em portugus: tempo de experincia na atividade e
quantidade de horas semanais reservadas para a atividade;

A conduo da avaliao annima.

5.2. APLICABILIDADE DO QUESTIONRIO

Usualmente, questionrios de avaliao de satisfao so considerados aplicveis s fases finais

do projeto de software. De fato, seu uso mais freqente d-se aps a concluso do produto, servindo
77

78

para calibrar a qualidade do produto (seja pela implementao de novos recursos, seja pela correo de
falhas de todo tipo: interao, preciso ou performance).
[PRUMPER 93] descreve a aplicao do ISONORM 9241/10 em duas fases do projeto
extremamente opostas:
-

a primeira, mais tradicional, para avaliao de produtos j concludos e em fase de

comercializao;

a segunda, muito mais rara no que se refere aplicao de questionrios de avaliao de

satisfao, para mediao entre a equipe de projetistas e os futuros usurios de um novo
mdulo de um produto de software.

O primeiro experimento, que ser brevemente descrito a seguir, evidencia a potencialidade de

aplicao que os questionrios (especialmente os baseados em recomendaes normativas) possuem para
auxiliar na avaliao do produto. Sendo, por isso, uma importante referncia a ratificar os objetivos dessa
dissertao.
O segundo experimento situa-se alm do escopo desse trabalho e, portanto, no ser assunto
desse captulo. No entanto, merece ateno de estudos que enfoquem o uso de pesquisas de satisfao
como ferramentas de apoio ao projeto centrado no usurio.

5.2.1. Comparando Interfaces Grfica e Modo Caracter

O objetivo do experimento era avali ar comparativamente a satisfao obtida pelos usurios de

produtos que possuem interface grfica com a dos usurios de produtos que possuem interface modo
caracter.
Participaram do estudo, 350 usurios (com idade mdia de 35 anos, sendo 64,2% do sexo
feminino e 35,8% do masculino) de 20 empresas alems, avaliando 66 programas diferentes:
-

usando o questionrio constante do Anexo 1, 106 usurios avaliaram 22 programas

dotados de interface grfica (MS-Windows ou Apple Macintosh);

78

79

usando o mesmo questionrio, 244 participantes avaliaram 44 programas dotados de

interface caracter (MS-DOS, IBM AS/400, IBM /36 e Siemens BS 2000);

Os conceitos atribudos pelos avaliadores so transformados em notas de acordo com a

equivalncia apresentada na tabela 5.2.
Conceito
---+/+
++
+++

Nota Equivalente
1
2
3
4
5
6
7

Tabela 5.2 Tabela de equivalncia entre as notas e os conceitos

A tabulao das respostas obtidas para cada um dos princpios da normas apresentada na
tabela 5.3.
[PRUMPER 93] extrai as seguintes concluses destes resultados:
-

o software com interface grfica apresenta grau de satisfao maior que o apresentado por
programas dotados de interface modo caracter, mas essa superioridade no significativa,
sendo sugestiva a necessidade de melhorias;

os resultados da tabela 5.3 evidenciam o sucesso da aplicao da norma como ferramenta

de avaliao da usabilidade, no somente porque mostra-se capaz de distinguir
significativamente as qualidades de tipos diferentes de software, mas porque tambm
permite identificar pontos onde as melhorias so necessrias.

5.3. CONFIABILIDADE DO QUESTIONRIO

[PRUMPER 99] efetuou um importante estudo de confiabilidade dos resultados da aplicao

do ISONORM 9241/10 como ferramenta de avaliao de software.
Mdias Obtidas

79

80

Princpio ISO 9241-10

Produto com Interface

Grfica
5,4

Produto sem Interface

Grfica
5,0

Auto-descrio

5,3

4,5

Controlabilidade

5,9

4,7

Conformidade com as Expectativas do Usurio

5,6

5,0

Tolerncia a Erros

4,9

4,6

Adequao Individualizao

5,2

3,7

Adequao ao Aprendizado

5,1

4,4

Adequao Tarefa

Tabela 5.3 Tabulao das mdias obtidas pelos produtos com e sem interface grfica
Deste estudo, participaram 1.265 usurios avaliando 178 programas diferentes. O perfil dos
participantes descrito a seguir:
-

idade mdia de 34,5 anos;

51,8% dos participantes eram do sexo feminino e 48,2% do sexo masculino;

o tempo mdio de experincia em informtica era de 77 meses;

o tempo mdio de experincia no software avaliado era de 25 meses.

As mdias obtidas pelos princpios da norma variaram entre 4,4 e 5,3 (com desvios-padres
entre 1,0 e 1,6), considerados bastante satisfatrios.
No entanto, a parte mais importante da pesquisa a avaliao de confiana do re-teste: 49
usurios que participaram da avaliao foram convidados a repetir a avaliao aproximadamente 7 meses
depois. A tabela 5.4 exibe a confiabilidade do questionrio para cada princpio da norma.
A confiabilidade total do re-teste (p<0,001 e N = 49) alcana 0,77, o que permite concluir que
as avaliaes baseadas no questionrio so bastante estveis, mesmo com o decorrer do tempo. Esta
concluso particularmente relevante se considerarmos a existncia de fatores humanos que influenciam na
reduo da confiabilidade do re-teste como:
-

o aumento da experincia do usurio no programa;

80

81

a aquisio de experincia do usurio no que se refere prpria sistemtica de avaliao.

Princpio

Alfa de Cronbach

Re-teste

(1208 <= N <= 1251)

(N = 49, p < 0,001)

Adequao Tarefa

0,81

0,67

Auto-descrio

0,86

0,62

Controlabilidade

0,84

0,64

Conformidade com as Expectativas do Usurio

0,84

0,60

Tolerncia a Erros

0,87

0,68

Adequao Individualizao

0,89

0,63

Adequao ao Aprendizado

0,83

0,59

Tabela 5.4 Confiabilidade do Questionrio [PRUMPER 99]

5.4. CORRELAO COM OUTROS QUESTIONRIOS

Finalmente, visando avaliar a correlao entre o ISONORM 9241/10 e outros questionrios,

[PRUMPER 99] formulou dois experimentos:
-

o primeiro correlaciona os resultados do ISONORM como os do QUIS [NORMAN 89],

que tambm um questionrio destinado ao usurio ;

o segundo correlaciona os resultados do ISONORM com os do EVADIS II [REITERER

93], que um questionrio destinado a especialistas em questes de usabilidade.

Os dois experimentos so descritos a seguir.

5.4.1. ISONORM X QUIS

Participaram do experimento, 31 usurios com experincia mdia em informtica de 58 meses e

experincia mdia no software avaliado de 18 meses.
A cada usurio foi solicitado que avaliasse o software de sua preferncia usando os dois
modelos de questionrios (QUIS e ISONORM).
81

82

A correlao entre os resultados obtidos pelos dois questionrios alcanou 0,73 (N = 31, p <
0,001), evidenciando uma significativa correlao entre os dois modelos orientados para o usurio.

5.4.2. ISONORM X E VADIS II

O experimento consistiu da avaliao de 13 programas de software. Cada programa foi

avaliado por dois grupos distintos:
-

o primeiro, composto por um conjunto variando entre 11 e 79 usurios, avaliou os

programas usando o ISONORM;

o segundo, composto por um especialista em ergonomia e um usurio experiente no

produto avaliado, efetuou a anlise usando o questionrio EVADIS II.

A correlao entre os resultados obtidos pelos dois questionrios alcanou 0,59 (N = 13

programas, p < 0,01). Prmper conclui que o questionrio orientado ao usurio obtm resultados similares
sistemtica de avaliao orientada para o especialista. No entanto, requer menos tempo e mais barato.

5.5. CONCLUSES

Os estudos relatados neste Captulo indicam que:

-

o questionrio baseado na norma ISO 9241-10 possui grau de aplicabilidade bastante

satisfatrio, permitindo identificar adequadamente, nos produtos de software, as qualidades
e pontos onde as melhorias so necessrias;

as avaliaes baseadas no questionrio so bastante estveis, mesmo com o decorrer do

tempo, conforme provou a confiabilidade do re-teste;

o questionrio mostra-se uma alternativa que, embora seja equivalente em resultados,

mais concisa que o QUIS, um importante modelo de questionrio orientado para o us urio;

o modelo do ISONORM permite que usurios possam chegar a resultados muito prximos
aos dos especialistas, porm em prazos menores e custos reduzidos.
82

83

Portanto, o uso da norma como modelo de ferramenta de avaliao de satisfao prova-se

bastante promissor, no s por permitir apurar indicadores do grau de aprovao dos usurios, mas por
auxiliar concretamente no fornecimento de informaes que orientem a pesquisa e eliminao das causas
da eventual insatisfao.

83

84

6. INSPEO DE USABILIDADE BASEADA EM INDICADORES DE S ATISFAO

Este captulo relata a realizao de uma inspeo de usabilidade a partir dos indicadores de
satisfao colhidos junto aos clientes de uma empresa desenvolvedora de software, utilizando uma
traduo do questionrio ISONORM 9241/10.
O estudo dividiu-se em 3 etapas:
a) Etapa I - pesquisa de satisfao: foi identificada uma populao para aplicao do
questionrio - os usurios dos programas de uma empresa desenvolvedora de software de
Florianpolis. As respostas dos questionrios - enviados a usurios de vrios Estados
brasileiros foram devidamente tabuladas. Dois tipos de anlise foram feitos:
visando confirmar a validade dos resultados, efetuou-se uma anlise comparativa
entre os graus de satisfao obtidos pelo ISONORM e pelo atual modelo de
questionrio de avaliao da empresa (Anexo 2);
objetivando determinar os pontos fortes e fracos do produto, calculou-se, a partir
das respostas obtidas pelo ISONORM, a mdia das notas segundo cada princpio
de dilogo descrito na parte 10 da no rma;
b) Etapa II - elaborao de uma estrutura para identificao de falhas de usabilidade:
formulou-se uma matriz de referncia cruzada (Anexo 3) entre as recomendaes da parte
10 da norma (representadas pelas perguntas do questionrio) e as das demais partes da
norma (12, 13, 14, 15, 16 e 17). Para cada pergunta do questionrio, foram empiricamente
correlacionadas as recomendaes, existente nas outras partes da norma, que poderiam
auxiliar na identificao das falhas responsveis pelas respectivas insatisfaes dos usurios;
c) Etapa III - as mdias de satisfao obtidas na primeira etapa foram usadas para estabelecer
prioridades na pesquisa das falhas de usabilidade. Estas prioridades determinaram quais
referncias da matriz seriam utilizadas no diagnstico das falhas.
Cada uma destas etapas descrita a seguir.

84

85

6.1. PESQUISA DE SATISFAO E SEUS RESULTADOS

A realizao do estudo requeria a identificao de um fornecedor de software que aceitasse

participar da pesquisa e que atendesse a alguns critrios:
-

preferencialmente, a empresa fornecedora do produto deveria adotar uma abordagem de

desenvolvimento formalizada: metodologia de desenvolvimento definida, utilizao de
toolkit para desenvolvimento de interfaces e uso de algum tipo de guia de recomendaes
ergonmicas para o projeto de interao;

visando obter amostras com ampla diversidade de caractersticas dos operadores,

estabeleceu-se que a populao em questo deveria ser composta por usurios de
software com perfis variados em experincia e freqncia de uso do produto, de uso de
programas de computador e de atuao na atividade automatizada pelo produto;

o grau de satisfao desta populao j deveria ser minimamente conhecido, tendo j sido
efetuada alguma forma de pesquisa sobre estes indicadores. O conhecimento destes
indicadores permitiria determinar se os resultados obtidos pelo ISONORM poderiam ser
considerados vlidos ou no.

Estas condies foram integralmente encontradas na Softplan Planejamento e Sistemas, de

Florianpolis. Um dos projetos da empresa, composto por aproximadamente 20 mdulos voltados para a
informatizao de Departamentos Estaduais e Nacional de Estradas de Rodagem, atende aos critrios
estabelecidos:
-

possui usurios novatos e mais experientes em diversas regies do pas;

adota um modelo padronizado de avaliao de satisfao dos usurios no que se refere ao

produto (ver Anexo 2);

a implementao dos programas adota um toolkit composto por objetos de interao

desenvolvidos pela prpria empresa. Durante a construo destes objetos, diversas aes
de adequao ergonmica foram implementadas. As orientaes ergonmicas para o uso
destes componentes de software constam de um manual, do qual faz uso toda a equipe de
85

86

desenvolvimento da empresa. O processo de construo destes componentes constitui o

ponto central do trabalho de [ROSA 99].

6.1.1. As Caractersticas da Amostra Populacional

Foram enviados questionrios para todos os usurios (em uma quantidade estimada de 300)
situados nos Estados de Santa Catarina, Paran, Rio Grande do Norte, Bahia e Distrito Federal. Foram
respondidos 48 questionrios, representando aproximadamente 16% do total enviado, e distribudos
geograficamente segundo a tabela 6.1. O perfil do entrevistado aponta idade mdia de 35 anos, sendo
52% do sexo masculino.
Estado

Qtde

Distrito Federal

4,2

Santa Catarina

14,6

Bahia

14,6

Paran

32

66,6

Tabela 6.1 Distribuio geogrfica da amostra

Objetivando determinar se e quais caractersticas dos usurios poderiam provocar distores
do grau de satisfao em relao ao total da populao, a amostra foi classificada por:
- experincia na atividade: conforme a tabela 6.2;
Experincia na Atividade

At 12 meses

34

De 12 a 36 meses

16

Mais de 36 meses

50

Tabela 6.2 Distribuio da amostra pelo tempo de experincia na atividade

86

87

- experincia no uso de programas de computador: conforme a tabela 6.3;

Experincia em Informtica

At 12 meses

11

De 12 a 36 meses

13

Mais de 36 meses

76

Tabela 6.3 Distribuio da amostra pelo tempo de experincia em informtica

- experincia no uso do software avaliado: conforme a tabela 6.4;
Experincia no Produto

At 6 meses

40

Mais de 6 meses

60

Tabela 6.4 Distribuio da amostra pelo tempo de experincia no produto avaliado

- freqncia de uso semanal do software avaliado: conforme a tabela 6.5;
Freqncia Semanal de Uso

At 8 horas

46

De 8 a 20 horas

26

Mais de 20 horas

28

Tabela 6.5 Distribuio da amostra pela freqncia de uso do produto avaliado

6.1.2. ISONORM X Questionrio Softplan: Comparao dos Resultados

Visando verificar a validade dos resultados, foi feita uma comparao entre as mdias gerais de
satisfao obtidas pelo ISONORM e pelo modelo usado pela Softplan.

87

88

O ndice geral de satisfao dos usurios (em uma escala que varia entre 0 e 1), obtida a partir
da tabulao das respostas dos questionrios ISONORM, alcana o valor de 0,8088 (desvio-padro de
0,1238, N = 48).
Indicador
Mdia do Questionrio Individual

Frmula
S nota de cada questo respondida
quantidade de questes respondidas
Mdia Geral de Satisfao
S Mdia do Questionrio Individual
quantidade de questionrios respondidos
Mdia Geral do Princpio i da Norma
S nota de cada questo do Princpio i
i: um dos 7 princpios da parte 10
qtde. de questes respondidas do Princpio i
ndice Geral de Satisfao ISONORM
Mdia Geral de Satisfao ISONORM / 7
ndice Geral de Satisfao Softplan
Mdia Geral de Satisfao Softplan / 2
Tabela 6.6 Frmulas utilizadas
Este valor aproxima-se muito do ndice geral de satisfao apurado pelo prprio modelo de
questionrio da Softplan (Anexo 2), que de 0,8073 (desvio-padro de 0,1609, N = 43). Por essa razo,
decidiu-se verificar se esta coincidncia poderia ser atribuda ao acaso, ou se estatisticamente estas mdias
poderiam ser consideradas equivalentes. Feita a comparao das mdias pelo teste t com correo de
Welch (t aproximado de Welch = 0,04997 com 78 graus de liberdade, ndice de confiana de 95%, P =
0,9603), pode-se admitir que as mdias no diferem significativamente entre si.
Avaliou-se a existncia de eventuais distores estatsticas da mdia obtida pelo ISONORM
que pudessem ter sido provocadas pelas caractersticas populacionais. Para a anlise das similaridades das
mdias, aplicou-se o teste de Kruskai-Wallis (ANOVA No-paramtrico) com fator de confiana de 95
%:
-

experincia na atividade: concluiu-se que o perfil amostral (tabela 6.7), dividido em 3

classes no provocou distores significativas nas mdias (P=0,4290,KW=1,692);
Classe

Tamanho da Amostra

Mediana

Mnimo Mximo

At 12 meses

15

5,771

2,943

7,000

De 12 a 36 meses

6,086

4,343

6,657

Mais de 36 meses

22

5,757

4,686

6,688

Tabela 6.7 Sumrio da amostra por tempo de experincia na atividade

88

89

experincia em informtica: concluiu-se que o perfil amostral (tabela 6.8), dividido em 3

classes no provocou distores significativas nas mdias (P = 0,7667, KW = 0,5312);
Classe

Tamanho da Amostra

Mediana

Mnimo Mximo

At 12 meses

5,571

5,286

6,500

De 12 a 36 meses

6,114

4,260

6,714

Mais de 36 meses

36

5,757

2,943

7,000

Tabela 6.8 Sumrio da amostra por tempo de experincia em informtica

-

freqncia de uso do programa: : concluiu-se que o perfil amostral (tabela 6.9), dividido em
3 classes no provocou distores significativas nas mdias (P = 0,4054, KW = 1,806);

Classe

Tamanho da Amostra

Mediana

Mnimo Mximo

At 8 horas

21

5,686

3,677

6,688

De 8 a 20 horas

12

5,424

4,257

6,714

Mais de 20 horas

13

5,857

4,743

7,000

Tabela 6.9 Sumrio da amostra por freqncia semanal de uso do programa

-

experincia no uso do programa: para esta anlise foi utilizado o teste t de Welch com fator
de confiana de 95%, recomendado por s haver duas classes. Concluiu-se que o perfil
amostral (tabela 6.10), no provocou distores significativas nas mdias (P = 0,5852, t
aproximado de Welch = 0,5519 com 29 graus de liberdade).
Classe

Tamanho da Amostra

Mdia

Desvio-padro

Mximo

At 6 meses

19

5,571

1,020

6,500

Mais de 6 meses

29

5,757

0,7193

7,000

Tabela 6.10 Sumrio da amostra por tempo de experincia no produto

Estas anlises confirmam a validade estatstica da mdia geral obtida pelo ISONORM, e, por
conseqncia, confirmam a similaridade com os resultados obtidos pelo modelo de questionrio adotado
pela Softplan.

89

90

Esta similaridade surpreende por duas razes:

-

os questionrios possuem questes distintas;

a escala de valores admissveis para as respostas diferente no dois questionrios.

Enquanto o da Softplan possui uma escala compreendendo 0 (Insatisfeito), 1 (Parcialmente
Satisfeito) e 2 (Satisfeito), a do ISONORM varia entre 1 e 7 (--- a +++).

As anlises estatsticas dos dados permitem duas concluses:

-

confirma-se que o nvel geral de satisfao dos usurios da Softplan situa-se em torno de
80%, j que tcnicas de avaliao diferentes conduziram a resultados similares;

comprova-se que o ISONORM apresenta -se como uma boa opo para auxiliar na
apurao do grau de satisfao de usurios de software.

6.1.3. Princpios da Norma: Grau de Satisfao dos Usurios

A determinao da mdia de satisfao dos usurios com relao a cada um dos princpios da
norma permite auxiliar na determinao das prioridades das aes corretivas necessrias interface de
utilizao. O grfico 6.1 apresenta as mdias gerais obtidas.
De maneira geral, as mdias obtidas mostram-se bem mais positivas do que as conseguidas por
[PRUMPER 93] em um experimento similar, usando o mesmo questionrio. Os princpios Adequao
Tarefa (mdia 5,88 e desvio-padro 1,13) e Conformidade com as Expectativas do Usurios (mdia
5,88 e desvio -padro 1,29) mostram-se bastante adequados.

Estes resultados indicam que, na opinio dos usurios, as tarefas, que eram originalmente manuais, foram
satisfatoriamente informatizadas.
No entanto, um item em particular, Tolerncia a Erros (mdia 5,16 e desvio-padro 1,73)
requer maior ateno. Este princpio tem uma importncia significativa na interao porque interfere
sensivelmente na aceitao do sistema por parte do usurio.
90

91

Falhas na gesto de erros provocam interrupo desnecessria no fluxo de trabalho, reduzindo

a segurana do usurio e, por conseqncia, sua confiana no produto. importante lembrar que a gesto
de erros um novo componente, quase um intruso, adicionado pela informatizao da atividade.
Manualmente, os erros podem ser cometidos em quantidade at maior, mas o usurio pode livremente
desenvolver mecanismos de verificao do trabalho, que lhe do a devida segurana para a execuo da
atividade. Usualmente, a informatizao restringe a liberdade de criao destes mecanismos, cabendo ao
produto absorver boa parte deles e proporcionar ainda outros, relacionados s falhas potenciais de
hardware e software (queda da conexo com o banco de dados, bloqueio de dados em ambiente multiusurio, overflow numrico, problemas de arredondamento, entre outros).

Grfico 6.1 Mdias das notas obtidas pelos princpios da norma

A mdia obtida pelo item Tolerncia a Erros resulta da tabulao das cinco questes que
apuram a satisfao dos usurios com relao a este princpio da norma. A tabela 6.11 apresenta a mdia
obtida por estas questes.
As questes pertinentes Tolerncia a Erros que obtiveram as mdias mais baixas ajuda
concreta correo de erros e facilidade de compreenso das mensagens de erros no s foram as

91

92

de pior nvel de satisfao deste princpio, mas tambm foram as de mais baixo grau de satisfao de toda
a pesquisa. Torna-se evidente a necessidade de identificar as respectivas falhas de interao, priorizandoas.
Questo

Tamanho

Mdia

da Amostra

Desviopadro

D ajuda concreta para a correo de erros.

48

4,79

1,70

projetado de forma que pequenos erros no tm conseqncias

severas.
Informa imediatamente sobre erros na entrada.

47

5,53

1,28

47

5,81

1,53

Proporciona mensagens de erro fceis de entender.

48

4,40

2,05

Requer, geralmente, pouco esforo para corrigir um erro.

48

5,27

1,67

Tabela 6.11 Mdias das notas obtidas pelas questes relativas Tolerncia a Erros

6.2. REFERNCIA CRUZADA DE RECOMENDAES

Visando auxiliar o processo de inspeo e identificao das falhas de usabilidade,

empiricamente elaborou-se uma matriz de referncia que relaciona cada questo do ISONORM com as
recomendaes existentes nas partes 12, 13, 14, 15, 16 e 17.

Para a questo:
Oferece recursos pobres para
automatizar tarefas repetitivas.
projetado de forma que
pequenos erros podem ter
conseqncias severas.

12

Verificar os seguintes itens da parte

13
14
15
16
4.3,6.9,
7.7
9.2.3,
6.6
9.2.5

17

Tabela 6.12 Exemplo de referncia das recomendaes relativas cada questo ISONORM
A tabela 6.12 mostra parte da estrutura da matriz (a estrutura integral da matriz encontra-se no
Anexo 3). Esta estrutura sugere, para cada questo ISONORM, quais recomendaes de cada parte da
norma devem ser utilizadas em uma inspeo que vise determinar eventuais falhas causadoras de
insatisfao. Assim:
-

para identificar as falhas relativas questo que avalia se o software oferece recursos
92

93

pobres para automatizar tarefas repetitivas, a inspeo deve utilizar as recomendaes 4.3,
6.9 e 7.7 da parte 15 da norma;
-

para localizar as falhas que referem-se questo que avalia se o software projetado de
forma que pequenos erros podem ter conseqncias severas, a inspeo deve utilizar as
recomendaes 9.2.3 e 9.2.5 da parte 13, e 6.6 da parte 15.

A elaborao desta matriz resultou da anlise emprica da influncia que cada recomendao,
de cada uma das partes da norma, poderia exercer sobre cada questo ISONORM. Cada questo teve
relacionada a si, exclusivamente as recomendaes consideradas intimamente ligadas aos objetivos de
avaliao da pergunta.
A estrutura final selecionou 183 recomendaes da norma, que combinadas com as questes
ISONORM, resultaram em uma quantidade de relacionamentos questo-recomendao equivalente a um
checklist com 278 itens de inspeo.
Esta estrutura foi aplicada e avaliada na inspeo de usabilidade efetuada na etapa final do
estudo.

6.3. REALIZAO DA INSPEO

A inspeo de usabilidade baseou-se na estrutura existente no Anexo 3. Uma nica pessoa

inspecionou um mdulo do produto da Softplan. A durao total da avaliao foi de 52 horas.
As falhas foram classificadas em dois tipos:
-

de projeto: so falhas estruturais, resultantes de decises de projeto, metodologia de

desenvolvimento, falhas nas recomendaes ergonmicas utilizadas, limitaes da
ferramenta de desenvolvimento ou do toolkit utilizado. As falhas de projeto, normalmente,
difundem-se por todo o produto, sendo de difcil quantificao. Usualmente so graves,
mas nem sempre de difcil correo s vezes, a alterao de um objeto de interao tem
um elevado poder de propagao da correo, especialmente em um ambiente de
desenvolvimento padronizado;

93

94

de desenvolvimento: so inconsistncias de implementao, possivelmente decorrentes de

violao das especificaes ou das recomendaes ergonmicas utilizadas, ou, ainda, da
adoo de objetos de interao cuja utilizao no foi padronizada pela empresa.
Normalmente, so falhas pontuais por isso, muito mais difceis de se localizar mas,
demandam correo especfica e tem pouco poder de propagao. A quantificao
importante porque permite estimar a violao da consistncia da interface.

A inspeo deu-se em duas fases:

-

Fase I identificao de falhas relativas ao princpio Tolerncia a Erros: tendo sido este o
princpio que apresentou menor grau de satisfao juntos aos usurios, e obedecendo s
prioridades estabelecidas na etapa I, foi efetuada uma inspeo para a identificao das
falhas relativas gesto de erros em um dos mdulos do produto;

Fase II identificao das demais falhas de usabilidade do sistema: visando avaliar a

potencialidade da matriz definida na etapa II, efetuou-se uma nova inspeo no mesmo
mdulo em busca de outras falhas de usabilidade, sendo utilizadas, nesta fase, as demais
recomendaes relacionadas na matriz de referncia.

O resultado de cada uma destas fases descrito a seguir.

6.3.1. Identificao das Falhas relativas Tolerncia a Erros

A inspeo em busca das falhas relativas gesto de erros durou 12 horas. Inicialmente,
pretendia-se efetuar a inspeo aplicando-se uma ordem de prioridade s questes relacionadas com o
princpio Tolerncia a Erros. Esta ordem priorizaria as questes em ordem inversa s mdias de
satisfao obtidas, conforme pode ser visto na tabela 6.13.
No entanto, observou-se, j nos primeiros momentos de inspeo, que este tipo de conduo
tornaria o processo moroso e pouco prtico.
Decidiu-se, ento, efetuar a inspeo por partes da norma. Iniciou-se pela parte 12, sendo
verificadas todas as recomendaes desta parte que possuam, na matriz de referncia, relacionamento

94

95

com as questes do princpio Tolerncia a Erros. A inspeo, ento, seguiu num ritmo mais rpido e
produtivo.
Questo
Proporciona mensagens de erro fceis de entender.

Mdia Prioridade
4,40
1

D ajuda concreta para a correo de erros.

4,79

Requer, geralmente, pouco esforo para corrigir um erro.

5,27

projetado de forma que pequenos erros no tm conseqncias severas.

5,53

Informa imediatamente sobre erros na entrada.

5,81

Tabela 6.13 Prioridades atribudas s questes relativas gesto de erros

O mesmo processo foi efetuado para as partes 13,14 e 17. As partes 15 Dilogos de
Comando e 16 Manipulao Direta no foram utilizadas porque o produto inspecionado no utiliza
este modelo de interao.
Questo
Proporciona mensagens de erro fceis de
entender.

D ajuda concreta para a correo de erros.

No-conformidades Encontradas
Parte
13

13

Recomendao
5.2.4
7.2.3
9.4.1
9.4.5
9.5.2
9.5.1

Tipo
Projeto
Projeto
Projeto
Projeto
Projeto
Projeto

Qtde.
2
1
1
1
1
1

Requer, geralmente, pouco esforo para

13
9.4.5
Projeto
1
corrigir um erro.
projetado de forma que pequenos erros no
tm conseqncias severas.
Informa imediatamente sobre erros na entrada.
Tabela 6.14 Resultados da inspeo com base nas questes relativas Tolerncia a Erros

A tabela 6.14 apresenta os resultados da inspeo, que confirmam a concentrao das falhas
justamente nos itens de menor mdia de satisfao. A inspeo indica, ainda, que as falhas relativas
gesto de erros concentram-se na parte 13 da norma Conduo do Usurio -, sendo unanimemente
classificadas como falhas de projeto.

95

96

Estas falhas, embora difundidas por todo o sistema, so, em sua maioria, de fcil soluo, j
que originam-se em particularidades no implementadas, ou insuficiente implementadas, no toolkit
desenvolvido pela empresa.
Parte Recomendao
12
5.3.5

5.7.7

5.7.8
5.9.1
5.10.1
7.2

7.5.2
13

5.2.7
9.2.4

14

10.3.1
10.3.3
5.1

17

7.1.3
5.2.6
5.3.7

No-conformidades Encontradas
Tipo
Qtd
Descrio
Desenv. 12 H sistemas compostos por telas desenvolvidas em Delphi e
em Centura. Os padres e algumas funcionalidades das telas
so diferentes.
Projeto
1 H telas que selecionam conjuntos de registros, mas o
sistema no informa ao operador, nem a quantidade de
registros selecionados, nem qual a posio relativa dentro do
conjunto.
Projeto
1 Idem
Projeto
1 H diversas situaes em que os campos no possuem
labels, especialmente campos com botes de consulta.
Projeto
3 No h distino visual para os valores trazidos tela pelo
sistema, os informados pelo usurio e os defaults
Desenv.
1 O campo que unidade de medida no automaticamente
transformado para maisculas, o que propicia que possa ser
cadastrado o mesmo dado duas vezes. Ex.: Metro poder ser
cadastrado como m ou M.
Desenv.
5 H mdulos que fazem uso indiscriminado de tipos de fontes
e cores no labels de botes e campos.
Projeto
1 No h suporte a diferentes nveis de usurio.
Desenv.
9 Em diversas situaes, o sistema encerrado mesmo quando
o usurio responde que no quer sair.
Projeto
1 F5 no chama o help em aplicaes Centura.
Projeto
1 Aplicaes Centura no possuem help contextual.
Desenv.
1 H menus cuja ordenao das opes absolutamente
aleatria, no tendo sido adotado nenhum critrios para se
organizar as opes dentro do menu.
Projeto
1 No h suporte a diferentes nveis de usurio.
Desenv.
3 H situaes em que o usurio no tem informao dos
valores vlidos para o campo de entrada.
Desenv. 17 Em diversas situaes, no h indicao do formato de
entrada dos dados. Ex.: Data: __/__/___

Tabela 6.15 Resultados da inspeo usando as questes restantes da matriz de referncia

Foram identificadas as seguintes falhas:

96

97

a) mensagens de erro compostas por vocabulrio tcnico de informtica, incompreensveis

para o usurio. Ex.: Impossvel deletar registro da entidade ... porque existem dados
relacionados.. Falha de projeto que viola a recomendao 5.2.4 da parte 13;
b) mensagens de erro imprecisas. Ex.: Impossvel deletar registro da entidade .... Causa
provvel: compartilhamento de dados com outro usurio.. Quando a mensagem foi
emitida no havia outro usurio utilizando o produto. Falha de projeto que viola a
recomendao 5.2.4 da parte 13;
c) falhas no dilogo no permitem que o usurio d seqncia interao. Ex.: SQL
statement ... Halt, Continue ?. A continuao do dilogo leva a novas mensagens
parecidas com a anterior, restando ao usurio interromper a interao. A interrupo da
interao gera salvamento parcial de dados, sem que o usurio tenha conhecimento disso.
Falha de projeto que viola as recomendaes 9.4.1 e 9.5.2 da parte 13;
d) as mensagens de erro do sistema possuem um nico padro, independente do nvel de
experincia do usurio. Falha de projeto que viola a recomendao 7.2.3 da parte 13;
e) o sistema no informa, de uma nica vez, quais so todos os campos que possuem valores
invlidos. Demanda que o usurio corrija um erro, processe, seja informado da outra
entrada invlida, corrija, processe, at no haver mais valores invlidos. Falha de projeto
que viola a recomendao 9.4.5 da parte 13;
f) o sistema no permite que o usurio obtenha maior nvel de detalhamento das mensagens
de erro. Falha de projeto que viola a recomendao 9.5.1 da parte 13.

6.3.2. Identificao das demais Falhas de Usabilidade

Na segunda fase da inspeo, no foram utilizadas as questes ISONORM, mas somente as

recomendaes restantes da matriz de referncia. O mdulo foi novamente avaliado por partes da norma.
Iniciou-se pela parte 12, sendo utilizadas as demais recomendaes da matriz de referncia que no
haviam sido usadas na fase I. A seguir, a parte 13, 14 e 17.

97

98

A durao total foi de 40 horas, e a tabela 6.15 apresenta os resultados dessa forma de
conduo da inspeo.
Tambm nesta inspeo a parte 13 da norma obteve uma quantidade considervel de
violaes, s perdendo para a parte 12 Apresentao da Informao.
Esta forma de inspeo mostrou-se menos eficiente, sendo as falhas encontradas com maior
dificuldade. Como no havia a orientao dos itens cuja insatisfao do usurio era maior, a inspeo
tornou-se quase uma navegao exploratria.

6.4. CONCLUSES

Avaliadas trs modalidades de aplicao do questionrio ISONORM, podem ser extradas

algumas importantes constataes:
-

o questionrio mostrou-se, no experimento de pesquisa de opinio, uma excelente

ferramenta para apurao do grau de satisfao dos usurios. A diviso das questes
segundo os princpios da norma, permite conhecer a satisfao dos us urios com relao
aos aspectos mais tcnicos do produto (Tolerncia a Erros, Controlabilidade, Adequao
Individualizao e Auto-descrio), e igualmente os aspectos mais diretamente relacionados
produtividade da tarefa (Adequao Tarefa, Adequao ao Aprendizado e
Conformidade com as Expectativas do Usurio);

a adoo de checklists que referenciem as recomendaes das partes da norma ISO

9241, pode encontrar no ISONORM um excelente apoio para direcionamento das
prioridades relativas ao processo de inspeo. O ISONORM pode ser utilizado para
apurar o grau de satisfao dos usurios com relao aos princpios da norma e, depois, as
mdias de satisfao podem auxiliar na determinao das recomendaes normativas que
sero utilizadas na inspeo;

a conciso e o nmero reduzido de perguntas fazem do questionrio um ferramenta prtica

e de custo de aplicao baixo. Paradoxalmente, apesar da conciso, o ISONORM

98

99

mostrou, na prtica, ser capaz de auxiliar no levantamento de uma quantidade significativa

de falhas de usabilidade.

99

100

7. CONCLUSES

Os questionrios de avaliao de satisfao podem servir como uma importante ferramenta de

orientao para o processo de inspeo de usabilidade de software.
Conjuntos de critrios e princpios ergonmicos, como os abordados no Captulo 2, podem ser
organizados em forma de questionrios direcionados para o usurio final, permitindo que as suas
demandas e queixas sejam conhecidas, as causas identificadas e corrigidas.
Questionrios de avaliao de usabilidade podem produzir indicadores que permitam definir as
necessidades de manuteno e desenvolvimento de software, devidamente priorizadas segundo ndices de
satisfao qualificados de acordo com critrios como os princpios de dilogos descritos no Captulo 4.
Conhecidos os ndices de satisfao e estabelecidas as prioridades, tcnicas de avaliao de
usabilidade como as descritas no Captulo 3, ou como a matriz de referncia descrita no Captulo 6,
auxiliam na identificao das falhas, cujo desconforto provoca baixos nveis de aprovao do produto.
Diante da importncia da seleo da ferramenta adequada para pesquisa de opinio, a
possibilidade de adoo de um questionrio baseado em normas internacionais, como o descrito no
Captulo 5, acrescenta s vantagens usuais da aplicao de questionrios (custo baixo, agilidade e
representatividade amostral), outras no menos valiosas:
-

evoluo: as normas internacionais encontram-se em constante evoluo, sendo

periodicamente adequadas s transformaes tcnicas, ambientais e tecnolgicas. Um
modelo de questionrio baseada em normas tende a acompanhar essa evoluo de maneira
mais fcil e consistente;

benchmarking: a adoo de modelos baseados em padres internacionais permite aos

fornecedores de software a realizao de comparaes de indicadores de satisfao,
qualidades e fraquezas dos produtos, definio de nveis de variao aceitveis e metas
para estes indicadores;

qualidade intrnseca: como as pesquisas de opinio apuram o grau de satisfao e as

demandas dos usurios, torna-se mais fcil para o fornecedor de software conhecer e
100

101

compreender as necessidades mais imediatas e importantes para seus clientes. O domnio

destes fatores permite a definio de prioridades de investimento, atuao, correo e
implementao de novas funcionalidades possivelmente com um maior grau de adequao
s expectativas dos clientes;
-

melhoria contnua: o devido e constante direcionamento para as principais demandas dos

clientes permite criar condies de obteno de graus de satisfao crescentes. Para tanto,
a sistematizao do ciclo avaliao de satisfao inspeo correo permite o
estabelecimento de um mecanismo de aprimoramento contnuo do produto.

Este estudo comprova, atravs de seus resultados, que o processo descrito acima factvel e
vivel. A partir de uma experincia prtica, que utilizou um questionrio baseado na norma ISO 9241-10,
desenvolvido na Alemanha e devidamente traduzido para o portugus, 48 usurios avaliaram um produto
de software.
Os indicadores de satisfao extrados deste questionrio permitiram:
-

confirmar, com alta preciso estatstica, o grau de satisfao apurado por um outro modelo
de questionrio de avaliao de satisfao, adotado pela empresa desenvolvedora do
produto;

indicar as caractersticas mais fortes e mais fracas do produto avaliado;

estabelecer prioridades de identificao de falhas, que conduziram o processo de inspeo

de usabilidade a identificar uma quantidade significativa de no-conformidades com a
norma;

qualificar as falhas existentes segundo sua origem (projeto ou desenvolvimento);

identificar as partes da norma cujas no-conformidades podem ser encontradas com maior
freqncia.

Uma importante constatao deste estudo a confirmao dos resultados obtidos por [ROSA
99], que comprovou que consideraes ergonmicas aplicadas a checklists e toolkits tendem a influenciar
positivamente a usabilidade dos produtos.
101

102

Como pode ser verificado no Captulo 6, as falhas encontradas no produto possuem duas
caractersticas marcantes:
-

raramente so falhas de consistncia, qualidade mais facilmente implementada em toolkits

como o utilizado pela Softplan. Alm da padronizao do processo de desenvolvimento, a
empresa adota um guia de recomendaes ergonmicas prprio, que permite
complementar eventuais caracte rsticas ausentes no toolkit;

a maioria das falhas de projeto, decorrentes principalmente da ausncia de algumas

funcionalidades no toolkit da empresa. A principal falha est relacionada com o tratamento
das mensagens de erros interceptadas do Sistema Gerenciador de Banco de Dados, cuja
implementao relativamente simples e de alto poder de propagao.

Outra concluso importante a confirmao dos resultados descritos no trabalho de

[PRUMPER 93], no qual, em estudo similar usando o mesmo questionrio, o princpio Tolerncia a
Erros obteve o menor grau de satisfao junto aos usurios, o que parece indicar um problema crnico
relativo forma como as empresas desenvolvedoras de software abordam a gesto de erros.

7.1. RECOMENDAES PARA T RABALHOS FUTUROS

Vrias extenses deste trabalho podem ser consideradas:

-

a matriz de referncia empiricamente elaborada e descrita no Captulo 6 poderia merecer

um estudo especfico. Vrias modalidades de construo da matriz poderiam ser
experimentadas e testadas em casos prticos, visando obter uma proposta mais slida de
correlao entre as recomendaes. Entre as modalidades de elaborao, seria conveniente
verificar: a elaborao por parte de uma equipe de especialistas, testes laboratoriais,
estudos de casos e interao especialista-usurio atravs do estudo de exemplos;

a inspeo de usabilidade descrita no Captulo 6 poderia ser feita por uma ou vrias
equipes, e os resultados poderiam ser correlacionados estatisticamente. Uma correlao
elevada indicaria que a norma especfica o bastante para depender pouco do
conhecimento do avaliador. Caso contrrio, indicaria que a norma pode servir como um
102

103

roteiro, mas o grau de experincia do avaliador ainda decisivo para o sucesso da

inspeo;
-

o questionrio poderia ser aplicado em empresas diferentes, preferencialmente as que

adotam processos de desenvolvimento menos padronizados. Assim, poder-se-ia avaliar
com maior preciso o quanto a formalizao do desenvolvimento contribui para a
usabilidade dos produtos;

outro estudo interessante seria a montagem de um checklist relacionando as questes

ISONORM a outras propostas de critrios ou recomendaes ergonmicos. Poder-se-ia
avaliar o quanto outras propostas podem contribuir para que a norma ISO 9241 alcance
seus objetivos;

um experimento que merece ateno o desenvolvimento de um sistema especialista

baseado em regras de inferncia para auxlio inspeo de usabilidade a partir de
indicadores de satisfao apurados pelo ISONORM.

103

104

ANEXO 1 TRADUO DO QUESTIONRIO ISONORM

104

105

105

106

106

107

107

108

108

109

109

110

110

111

111

112

112

113

ANEXO 2 MODELO DE QUESTIONRIO DA SOFTPLAN

113

114

114

115

ANEXO 3 MATRIZ DE REFERNCIA QUESTO ISONORM X R ECOMENDAO

115

116

116

117

117

118

118

119

119

120

120

121

121

122

122

123

REFERNCIAS B IBLIOGRFICAS

[ANTONIONI 95]

ANTONIONI, J.; ROSA, N. B. .Qualidade em software: manual de aplicao da

iso 9000. So Paulo: McGraw-Hill, 1995.

[BASS 91]

BASS, L.; COUTAZ, J. .Developing software for the user interface.

Massachusets: Addison-Wesley, 1991.

[BASTIEN 93]

BASTIEN, C.; SCAPIN, D. . Ergonomic criteria for the evaluation of humancomputer interfaces.INRIA Rapport technique: programme 3, intelligence
artificielle, systmes cognitifs et interaction homme-machine, n.156, jun, 1993.

[BODART 93]

BODART, F.; VANDERDONCKT, J. .Guide ergonomique de la prsentation

des applications hautement interactives. Presses Universitaires de Namur,
1993.

[BOEHM 76]

BOEHM, B. .Software engineering. IEEE Transactions on computers. v. C-25, n.

12, 1976.

[COSTA 97]

COSTA, E.; WEBER, K.; MOURA, A. . Brazil: excellence in software production

and export. 1997. SOFTEX, http://www.softex.br.

[COSTA NETO 77] COSTA NETO, P. L. O. . Estatstica. So Paulo: Edgar Blcher, 1977.
[CYBIS 97]

CYBIS, W. . Abordagem ergonmica para interfaces de computador .

Florianpolis: LabIUtil, 1997. Apostila de treinamento.

[DE SOUZA 93]

DE SOUZA, F.; BARBER, P. . Linhas-guia, standards e projetos de interfaces

computadoizadas junto ao usurio final. In: Congresso Latino Americano, 2,
Seminrio Brasileiro de Ergonomia,6, Florianpolis: 1993.

[EBERTS 94]

EBERTS, R. . User interface design. New Jersey: Prentice-Hall, 1994.

[FAIRLEY 85]

FAIRLEY, R. . Software engineering concepts. New York: Mc Graw-Hill, 1985.

123

124

[FIALHO 95]

FIALHO, F.; SANTOS, N. . Manual de anlise ergonmica do trabalho. Curitiba:

Genesis, 1995.

[GAINES 81]

GAINES , B. . The techno logy of interaction: dialogue programming rules,

International Journal of Man-Machine Studies, 14, p. 133-150.

[GONTIJO 93]

GONTIJO, L.; DUTRA, A.; GONALVEZ, C. . Anlise ergonmica de

software: o caso redator/pc. In: Congresso Latino Americano, 2, Seminrio
Brasileiro de Ergonomia,6, Florianpolis: 1993. p. 309-311.

[GOULD 81]

GOULD , J. . Composing letters with computer-based text editors. Human

Factors, 23, p. 831-833, 1981.

[HANSEN 78]

HANSEN, W.; DORING, R.; WHITLOCK, L. . Why an examination was slower

on-line than on paper. International Journal of Man-Machine Studies, 10, p.
507-519, 1978.

[HORTON 94]

HORTON, W. . The icon book: visual symbols for computer systems and
documentation. New York: John Wiley & Sons, 1994.

[IBM 99]

PRINCIPLES for well-designed user interfaces. EUA: IBM, 1999.

http://www.ibm.com/ibm/easy/design/lower/f010402.html. Consultado em
12/05/1999.

[ISO9241-1 92]

ISO. ISO 9241-1: ergonomic requirements for office work with visual display
terminals (VDTs) general introduction. Genebra, 1992.

[ISO9241-2 92]

ISO. ISO 9241-2: ergonomic requirements for office work with visual display
terminals (VDTs) guidance on task requirements. Genebra, 1992.

[ISO9241-3 92]

ISO. ISO 9241-3: ergonomic requirements for office work with visual display
terminals (VDTs) visual display requirements. Genebra, 1992.

[ISO9241-10 96]

ISO. ISO 9241-10: ergonomic requirements for office work with visual display
terminals (VDTs) dialogue principles. Genebra, 1996.

124

125

[ISO9241-11 98]

ISO. ISO 9241-11: ergonomic requirements for office work with visual display
terminals (VDTs) guidance on usability. Genebra, 1998.

[ISO9241-12 98]

ISO. ISO/FDIS 9241-12: ergonomic requirements for office work with visual
display terminals (VDTs) presentation of information. Genebra, 1998.

[ISO9241-13 98]

ISO. ISO 9241-13: ergonomic requirements for office work with visual display
terminals (VDTs) user guidance. Genebra, 1998.

[ISO9241-14 97]

ISO. ISO 9241-14: ergonomic requirements for office work with visualdisplay
terminals (VDTs) menu dialogues. Genebra, 1997.

[ISO9241-15 97]

ISO. ISO 9241-15: ergonomic requirements for office work with visual display
terminals (VDTs) command dialogues. Genebra, 1997.

[ISO9241-16 97]

ISO. ISO/DIS 9241-16: ergonomic requirements for office work with visual
display terminals (VDTs) direct manipulation dialogues. Genebra, 1997.

[ISO9241-17 98]

ISO. ISO 9241-17: ergonomic requirements for office work with visual display
terminals (VDTs) form filling manipulation dialogues. Genebra, 1998.

[JONES 91]

JONES, C. . Produtividade no desenvolvimento de software. So Paulo:

McGraw-Hill, 1991.

[KANHOLM 95]

KANHOLM, J. . ISO 9000 explicada: lista de verificao com 65 requisitos e

guia de conformidade. So Paulo: Pioneira, 1995.

[KARSENTY 91]

KARSENTY, S. . La constrution d'interfaces utilisateurs. Genie Logiciel &

Systmes Experts, 24, p. 18-27, 1991.

[KOZAR 78]

KOZAR, K.; DICKSON, G. . An experimental study of the effects of data display

media on decision effectiveness . International Journal of Man-Machine
Studies, 10, p. 494-505, 1978.

[KUME 93]

KUME, H. . Mtodos estatsticos para melhoria da qualidade. 8. ed. So Paulo:

Gente, 1993.
125

126

[MACINTYRE 90]

MACINTYRE, F.; ESTEP, K.; SIEBURTH,J. . Cost of user-friendly

programming. Journal of Forth Application and Research, v. 6, n. 2, p. 103115, 1990.

[MARANHO 94]

MARANHO, M. . ISO srie 9000: manual de implementao. 2. ed. Rio de

Janeiro: Qualitymark, 1994.

[MARTIN 91]

MARTIN, J.; MCCLURE, C. . Tcnicas estruturadas e case. So Paulo:

McGraw-Hill, 1991.

[MATIAS 95]

MATIAS, M. . Check-list: uma ferramenta de suporte avaliao ergonmica de

interfaces. Florianpolis, 1995. Dissertao de Mestrado apresentada ao
Programa de Ps-graduao em Engenharia de Produo da UFSC.

[MCT 95]

QUALIDADE NO SETOR DE SOFTWARE BRASILEIRO. Braslia: MCT,

Secretaria de Poltica de Informtica e Automao, n. 1, 1995.

[MCT 97]

QUALIDADE NO SETOR DE SOFTWARE BRASILEIRO. Braslia: MCT,

Secretaria de Poltica de Informtica e Automao, n. 2, 1997.

[MEDEIROS 94]

MEDEIROS, M.; VOGT, M.; CALEGARI, M. . Gerador de telas com validao

de dados. In: UNICOMP, 1, Tubaro: 1994. p. 1-9.

[MEDEIROS 98]

MEDEIROS, M. . Ferramentas de Concepo de Interfaces Homem-Mquina.

CTAIRevista, Florianpolis, v. 1, n. 1, ago.1998. http://www.ctai.rctsc.br/revista/anteriores.html. Consultado em 20/05/1999.

[MEDEIROS 98a]

MEDEIROS, M. . Controle de Emprstimo de Livros: Relatrio da Anlise

Ergonmica da Tarefa. CTAIRevista, Florianpolis, v. 1, n. 2, dez.1998.
http://www.ctai.rct-sc.br/revista/artigos.html. Consultado em 26/06/1999.

[MICROSOFT 95]

The windows interface guidelines for software design. EUA: Microsoft, 1995.
126

127

[MOO 96]

MOO, S. . O uso de cenrios como uma tcnica de apoio para avaliaes

ergonmicas de softwares interativos. Florianpolis, 1996. Dissertao de
Mestrado apresentada ao Programa de Ps-graduao em Engenharia de
Produo da UFSC.

[MRABET 91]

MRABET, H. . Outils de generation d'interfaces: etat de l'art et classification.

INRIA Rapport technique: programme 3, intelligence artificielle, systmes
cognitifs et interaction homme-machine, n.126, 1991.

[NIELSEN 90]

NIELSEN, J.; MOLICH, R. . Heuristic evaluation of user interfaces. In:

Proceedings ACM CHI90 Conference. Seattle: 1990. p. 249-256.

[NIELSEN 94]

NIELSEN, J. & MACK, R. . Usability inspection methods. EUA: John Wiley &
Sons, 1994.

[NIELSEN 94a]

NIELSEN, J. . Usability laboratories: a 1994 survey.

http://www.useit.com/papers/uselabs.html. Consultado em 26/06/1999.

[NORMAN 89]

NORMAN, K.; SHNEIDERMAN, B. . Questionnaire for user interaction

satisfaction (quis 5.0). EUA: Universidade de Maryland, HCI-Lab, 1989.

[NORMAN 90]

NORMAN, D. . The design of everyday things. EUA: Doubleday, 1990.

[OPPERMANN 97] OPPERMANN, R.; REITERER, H. . Software evaluation using iso 9241
evaluator. Behaviour & Information Technology, v.16, n. 4/5, p. 232-245,
1997.
[PAGE-JONES 88]

PAGE-JONES, M. . Projeto estruturado de sistemas. So Paulo: McGraw-Hill,

1988.

[PRUMPER 93]

PRUMPER, J. . Software-evaluation based upon iso 9241 part 10. In: Vienna
Conference, VCHCI93. Viena: 1993.

[PRUMPER 99]

PRUMPER, J. . Test it: isonorm 9241/10. In: HCI International 99. 1999. Ainda
no publicado cpia gentilmente cedida pelo Dr. Prumper.

127

128

[RAVDEN 89]

RAVDEN, S.; GRAHAM, J. . Evaluating usability of human-computer interfaces.

New York: John Wiley & Sons, 1989.

[ROSA 99]

ROSA, M. . Consideraes ergonmicas na elaborao de guias de estilo uma

ferramenta de apoio concepo / projeto de formulrios. Florianpolis,
1999. Dissertao de Mestrado apresentada ao Programa de Ps-graduao
em Engenharia de Produo da UFSC.

[ROSENBERG 89]

ROSENBERG, D. . Cost-benefit analysis for corporate user interface standards:

what price to pay for a consistent look-and-feel. Coordinating user interfaces
for consistency. New York, 1989. p. 21-34.

[SCAPIN 97]

SCAPIN, D. & BERNS,T. (1997). Usability evaluation methods. Behaviour &

Information Technology. Londres, v.4, n.4/5, 1997.

[SCHAUB 96]

SCHAUB, W. .US home pc buyers are they really buying ? a study in the
conversion of pc purchase intentions. Dataquest. Stanford, EUA, 1996.

[SEPIN 99]

EMPRESAS do setor de informtica com certificao. Braslia: MCT, Secretaria

de Poltica de Informtica e Automao, 1999.
http://www.mct.gov.br/sepin/dsi/qualidad/ISOinfor.htm. Consultado em
06/06/1999.

[SHNEIDERMAN 98]

SHNEIDERMAN, B. . Designing the user interface: strategies for effective humancomputer-interaction. 3. ed. EUA: Addison-Wesley, 1998.

[SMITH 84]

SMITH, S.; MOSIER, J. . Design guidelines for the user interface for computerbased information systems. Springfield: National Technical Information
Service, 1984.

[SMITH 86]

SMITH, S.; MOSIER, J. . Guidelines for designing user interface software.

Bedford: Mitre, 1986.

[STEWART 95]

STEWART, T. . Display screen ergonomics. Londres: System Concepts, 1995.

128

129

[SYSCON 99]

Standards & Legislation. System Concepts, Londres, v. 5, n. 4, 1999.

[SYSCON 99a]

ISO 9241 Status. System Concepts, Londres, v. 5, n. 5, 1999.

http://www.system-concepts.com/stds/status.html. Consultado em
28/06/1999.

[TOGNAZZINI 99] TOGNAZZINI, B. .Basic principles for interface design. 1999.

http://www.asktog.com/basics/firstPrinciples.html. Consultado em
18/06/1999.
[WEBER 97]

WEBER, K. . Indstria de software no Brasil: estratgias de desenvolvimento.

1997. SOFTEX, http://www.softex.br.

[WEISE 98]

WEISE, E. . Tecnologia complica a vida dos usurios. Folha de So Paulo ,

Caderno de Informtica, 7 jan. 1998.

129

130

Dados do Entrevistado
Qual a sua profisso?
Idade (em anos)?
Sexo (M/F)?

Experincia do Entrevistado
H quantos meses voc executa esta atividade?
Durante quantas horas por semana voc executa esta atividade?
H quanto meses voc trabalha com computadores em geral?
Durante quantas horas por semana voc trabalha com computadores?
Quantos programas voc usa atualmente?
H quantos meses voc trabalha com o software avaliado?
Durante quantas horas por semana voc trabalha com o software avaliado?

Identificao do Software
Nome do Software:
Empresa Desenvolvedora:
Verso:

130

131

QUESTIONRIO DE AVALIAO PARA O USURIO FINAL

PRINCPIO I : ADEQUAO TAREFA
OBJETIVO: Avalia se o software d ao usurio suporte suficiente para que as tarefas
sejam executadas de maneira eficiente e efetiva.
O software ...
-- complicado de
usar.
no oferece todas
as funes
necessrias para
realizar
eficientemente as
tarefas.
oferece recursos
pobres para
automatizar tarefas
repetitivas.
requer entrada de
dados
desnecessrios.
pouco adequado
s necessidades do
trabalho.

--

+/-

++ +++
fcil de usar.
oferece todas as funes
necessrias para realizar
eficientemente as tarefas.

oferece bons recursos

para automatizar tarefas
repetitivas.
no requer entrada de
dados desnecessrios.
apropriado para as
necessidades do
trabalho.

131

132

PRINCPIO II : AUTO-DESCRIO
OBJETIVO: Avalia se cada passo do programa imediatamente compreensvel atravs
de feedback do sistema ou atravs de explicaes quando solicitadas.
O software ...
--proporciona pouca
noo do alcance
de suas funes.
nas mscaras ou
menus, usa
terminologia,
abreviaes ou
smbolos difceis
de entender.
indica de maneira
insuficiente qual
entrada permitida
ou necessria.
no proporciona
explicaes
sensveis ao
contexto quando
solicitadas.
no proporciona
explicaes
sensveis ao
contexto
automaticamente.

--

+/-

++ +++
proporciona boa noo
do alcance de suas
funes.
nas mscaras ou menus,
usa terminologia,
abreviaes ou smbolos
fceis de entender.

indica de maneira
suficiente qual entrada
permitida ou necessria.
proporciona explicaes
sensveis ao contexto
quando solicitadas.

proporciona explicaes
sensveis ao contexto
automaticamente .

132

133

PRINCPIO III : CONTROLABILIDADE

OBJETIVO: Avalia se o software permite que o usurio inicie e controle a direo e o ritmo
da interao.
O software ...
--oferece poucas
possibilidades de
interromper o
trabalho em
qualquer ponto e
continuar mais
tarde do mesmo
ponto sem qualquer
perda de dados.
fora o usurio a
executar uma
seqncia rgida e
desnecessria de
passos.
no suporta
facilmente a troca
de mscaras e
menus individuais.
projetado de
forma que o
usurio no pode
influenciar que tipo
de informao
apresentado na
tela e como a
informao
apresentada.
acarreta
interrupes
desnecessrias do
fluxo de trabalho.

--

+/-

++ +++
oferece boas
possibilidades de
interromper o trabalho em
qualquer ponto e
continuar mais tarde do
mesmo ponto sem
qualquer perda de dados.

no fora o usurio a
executar uma seqncia
rgida e desnecessria
de passos.
suporta facilmente a troca
de mscaras e menus
individuais.
projetado de forma que
o usurio pode influenciar
que tipo de informao
apresentado na tela e
como a informao
apresentada.

no acarreta interrupes
desnecessrias do fluxo
de trabalho.

133

134

PRINCPIO IV : CONFORMIDADE COM AS EXPECTATIVAS DOS USURIOS

OBJETIVO: Avalia se o software consistente e corresponde s caractersticas individuais
do usurio como tarefa, conhecimento, educao, experincia e convenes usualmente
aceitas.
O software ...
--complica a
orientao do
usurio devido a
um projeto de
interface sem
padronizao.
no proporciona
feedback indicando
se uma entrada foi
bem sucedida ou
no.
proporciona retorno
insuficiente sobre o
processamento em
curso.
possui um tempo
de resposta
imprevisvel.
no projetado
segundo um
princpio
consistente e
padronizado.

--

+/-

++ +++
facilita a orientao do
usurio devido a um
projeto de interface
padronizado.
proporciona feedback
indicando se uma entrada
foi bem sucedida ou no.

proporciona retorno
suficiente sobre o
processamento em curso.
possui um tempo de
resposta previsvel.
projetado segundo um
princpio consistente e
padronizado.

134

135

PRINCPIO V : TOLERNCIA A ERROS

OBJETIVO: Avalia se o software atinge os resultados esperados apesar de erros
evidentes na entrada, requerendo nenhuma ou mnima ao corretiva por parte do
usurio.
O software ...
-- projetado de
forma que
pequenos erros
podem ter
conseqncias
severas.
informa muito tarde
sobre erros na
entrada.
proporciona
mensagens de erro
difceis de
entender.
requer, geralmente,
muito esforo para
corrigir um erro.
no d ajuda
concreta para a
correo de erros.

--

+/-

++ +++
projetado de forma que
pequenos erros no tm
conseqncias severas.

informa imediatamente
sobre erros na entrada.
proporciona mensagens
de erro fceis de
entender.
requer, geralmente,
pouco esforo para
corrigir um erro.
d ajuda concreta para a
correo de erros.

135

136

PRINCPIO VI : SUPORTE INDIVIDUALIZAO

OBJETIVO: Avalia se o software facilmente modificado de forma a adequar-se s
necessidades das tarefas do usurio, preferncias e experincia individuais.
O software ...
-- difcil de expandir
se novas tarefas
surgirem.
difcil de adaptar
ao estilo individual
de trabalho do
usurio.
no igualmente
adequado a
usurios iniciantes
e experientes
porque difcil de
adaptar ao nvel de
conhecimento do
usurio.
, dentro de seu
escopo, difcil de
adaptar para
diferentes tarefas.
projetado de tal
forma que a tela
difcil de adaptar s
necessidades
individuais do
usurio.

--

+/-

++ +++
fcil de expandir se
novas tarefas surgirem.
facilmente adaptvel ao
estilo individual de
trabalho do usurio.
igualmente adequado a
usurios iniciantes e
experientes porque
facilmente adaptvel ao
nvel de conhecimento do
usurio.
, dentro de seu escopo,
facilmente adaptvel para
diferentes tarefas.
projetado de tal forma
que a tela adaptvel s
necessidades individuais
do usurio.

136

137

PRINCPIO VII : ADEQUAO AO APRENDIZADO

OBJETIVO: Avalia se o software suporta e guia o usurio no aprendizado do uso do
sistema.
O software ...
--requer muito tempo
para aprender.
no encoraja a
experimentar novas
funes.
requer a
memorizao de
muitos detalhes.
projetado de
forma que o que
aprendido
dificilmente
memorizado.
difcil de
aprender sem
apoio externo ou
um manual.

--

+/-

++ +++
requer pouco tempo para
aprender.
encoraja a experimentar
novas funes.
requer a memorizao de
poucos detalhes.
projetado de forma que
o que aprendido
facilmente memorizado.
fcil de aprender sem
apoio externo ou um
manual.

137

138

S
Sooffttpplla
an
n
AVALIAO DE PRODUTO
Atualizao: 23/02/99

Queremos v-lo satisfeito!

Mas, para isso, precisamos de sua ajuda. Por favor, dedique
5 minutos do seu tempo para preencher este formulrio de avaliao
da qualidade de nosso produto, atribuindo, no quadro abaixo, uma
nota para cada item segundo o critrio a seguir :

N No se aplica;
X Ainda sem opinio formada;
0 No atendeu s suas necessidades;
1 Atendeu parcialmente s suas necessidades;
2 Atendeu plenamente s suas necessidades.

Afinal, a sua viso do nosso trabalho que realmente

importa!
SISTEMA (Sigla):
NOME COMPLETO:
EMPRESA/SETOR:
TPICOS
INTERFACE

COM O
USURIO
INFORMAO

EM
TELA

RELATRIOS

MANUAIS

VERSO:

DATA:

ITENS

NOTA

01 Lay-out: sequncia, alinhamento, espaamento e visualizao dos campos na tela

02 Utilizao: facilidade de navegao, agilidade e praticidade dos comandos
03 Conforto: cores, tamanho dos caracteres, entendimento dos comandos/funes
04 Clareza: das mensagens, nomes de botes, camp os e opes de menu
05 Confiabilidade: confiana nos dados disponibilizados em tela
06 Volume: quantidade de informaes disponibilizadas em tela
07 Tempo de Resposta: tempo dispendido para disponibilizar a informao requerida
08 Segurana de Acesso: bloqueio de acesso a pessoas no autorizadas
09 Utilidade da informao disponibilizada em tela
10 Confiabilidade: confiana nos relatrios emitidos
11 Volume: quantidade de relatrios disponibilizados
12 Tempo de Resposta: tempo dispendido para disponibilizar a informao requerida
13 Segurana de Acesso: bloqueio de acesso a pessoas no autorizadas
14 Utilidade dos relatrios disponibilizados
15 Lay-out: sequncia, alinhamento, espaamento e visualizao dos dados
16 Volume : quantidade de informao disponvel
17 Grau de detalhamento da informao disponvel
18 Lay-out: distribuio do texto e figuras, localizao/visualizao da informao
19 Utilid ade da informao disponibilizada nos manuais
20 Adequao da linguagem utilizada
21 Volume : quantidade de informao disponvel
138

139

HELP

ADEQUAO

22 Grau de detalhamento da informao disponvel

23 Lay-out: distribuio do texto e figuras, localizao/visualizao da informao
24 Utilidade da informao disponibilizada no Help
25 Adequao da linguagem adotada
26 Impacto Organizacional: agilizao da realizao das tarefas do rgo/empresa
27 Impacto Setorial: agilizao da realizao das tarefas do setor/departamento
28 Utilidade do Sistema
29 Expectativas: atendimento s necessidades de informao

139

140

PRINCPIO I : ADEQUAO TAREFA

Para a questo:
12
complicado de usar.
No oferece todas as
funes necessrias para
realizar eficientemente as
tarefas.
Oferece recursos pobres
para automatizar tarefas
repetitivas.
Requer entrada de dados 5.5.1,
desnecessrios. 5.6.2,
5.8.2,
5.10.1

Verificar os seguintes itens da parte

13
14
15
16

17

4.3,6.9,
7.7
6.2,8.2, 5.1,5.2, 5.1.3,
10.1,
5.3
5.3,6.7
10.2,
10.3,
10.3.1,
10.3.3

5.3.2,
5.3.3,
8.2.2,
9.1.3,
9.1.4

5.2.1,
5.2.2,
5.2.3,
5.3.2,
6.1.2,
6.1.3,
6.2,
6.3,
6.4.4

pouco adequado s
necessidades do trabalho.

140

141

PRINCPIO II : AUTO-DESCRIO

Para a questo:
Proporciona pouca noo do
alcance de suas funes.
Nas mscaras ou menus, usa
terminologia, abreviaes ou
smbolos difceis de entender.

Indica de maneira insuficiente

qual entrada permitida ou
necessria.

No proporciona explicaes
sensveis ao contexto quando
solicitadas.
No proporciona explicaes
sensveis ao contexto
automaticamente .

Verificar os seguintes itens da parte

13
14
15
16
10.2, 5.1,5.2,
10.3,
5.3,
10.4.5 6.1.5
5.6.3,
6.1.1,
5.6.4,
8.1.7
5.8.2,
7.1.3,
7.1.4,
7.1.5,
7.2.3,
7.3
5.5.1,
7.1,7.2,
5.3.2,
5.10,
7.3,
5.3.3,
6.1.1,
8.1.4,
5.4.4,
6.2.6,
8.1.6
8.2.2,
7.5.2,
9.1.4
7.5.4
12

17
10
5.2.1,
5.2.2,
8.6.6

5.2.3,
5.2.4,
5.2.5,
5.2.6,
5.2.7,
5.2.8,
5.2.9,
5.2.10,
5.3,6.2,
6.3,
6.4.4

5.2.4,
10.2,
8.2.3
10.3,
10.3.1,
10.3.3,
6.2,
8.2.1,
8.2.2

141

142

PRINCPIO III : CONTROLABILIDADE

Para a questo:
12
Oferece poucas
possibilidades de interromper
o trabalho em qualquer ponto
e continuar mais tarde do
mesmo ponto sem qualquer
perda de dados.
Fora o usurio a executar 5.6.2,
uma seqncia rgida e 5.6.4,
desnecessria de passos. 5.7.1,
5.7.7,
5.7.8,
6.2.4,
6.2.5
No suporta facilmente a troca
de mscaras e menus
individuais.
projetado de forma que o
usurio no pode influenciar
que tipo de informao
apresentado na tela e como a
informao apresentada.
Acarreta interrupes
desnecessrias do fluxo de
trabalho.

Verificar os seguintes itens da parte

13
14
15
16
17

5.1,5.2, 5.3,6.2,
5.3,6.2, 6.3,6.5
7.11,
7.12,
7.13

5.4.1,
5.4.2,
5.4.3,
6.2,
7.1.2,
8.2.2,
8.3.3,
9.1.3

6.1,6.2,
6.4,
6.5.1,
6.5.2,
8.2,8.3,
8.4,8.6

6.9
5.3.10

5.3.1,
5.3.2,
5.3.8,
5.3.9,
5.3.10,
5.5.1,
5.8.2

6.2.2,
6.2.5,
7.2.2

5.2.1,
5.2.2

142

143

PRINCPIO IV : CONFORMIDADE COM AS EXPECTATIVAS DOS USURIOS

Para a questo:
Complica a orientao do
usurio devido a um projeto
de interface sem
padronizao.

12
5.6.1,
5.6.2,
5.6.4,
5.6.5,
6.2.5

No proporciona feedback
indicando se uma entrada foi
bem sucedida ou no.
Proporciona retorno
insuficiente sobre o
processamento em curso.
Possui um tempo de resposta
imprevisvel.
No projetado segundo um 5.3.4,
princpio consistente e 5.3.5,
padronizado. 5.4.1,
5.6.3,
5.8.2,
7.1.2,
7.1.3,
7.3.5

Verificar os seguintes itens da parte

13
14
15
16
17
6.1
5.2.1,
5.2.2

7.2.1,
7.2.9,
8.2
7.2.4,
7.2.6

7.1.4

7.2.8

7.1.6

7.4

7.2

5.1,5.2, 5.3.2,
5.3,
5.3.3,
7.3.4,
5.3.4
7.6.2,
8.2.1

143

144

PRINCPIO V : TOLERNCIA A ERROS

Para a questo:
projetado de forma que
pequenos erros podem ter
conseqncias severas.
Informa muito tarde sobre
erros na entrada.

Proporciona mensagens de
erro difceis de entender.

Requer, geralmente, muito

esforo para corrigir um erro.
No d ajuda concreta para a
correo de erros.

12

Verificar os seguintes itens da parte

13
14
15
16
17
9.2.3,
6.6
9.2.5
9.2.3,
9.2.4,
9.4.4,
9.5.8
5.2.4,
7.2.3,
9.4.1,
9.5.2,
9.5.3,
9.5.6
9.2.6,
9.4.4,
9.4.5
9.4.2,
9.4.3,
9.4.4,
9.5.1,
9.5.9,
10.2.3,
10.4.1,
10.4.2

6.8,7.3

7.3

6.4,7.4

6.4.1,
6.4.2,
6.4.3
7.3

144

145

PRINCPIO VI : SUPORTE INDIVIDUALIZAO

Para a questo:
difcil de expandir se novas
tarefas surgirem.
difcil de adaptar ao estilo
individual de trabalho do
usurio.
No igualmente adequado a
usurios iniciantes e
experientes porque difcil de
adaptar ao nvel de
conhecimento do usurio.
, dentro de seu escopo,
difcil de adaptar para
diferentes tarefas.
projetado de tal forma que a
tela difcil de adaptar s
necessidades individuais do
usurio.

12

Verificar os seguintes itens da parte

13
14
15
16
17

5.2.7

6.2.3,
7.2.3,
7.7.7,
8.2.2,
9.4,
9.5.5
6.2.5,
8.2.3

4.3

6.1,6.2, 5.1.3,
6.2.3, 5.2.2,
7.1.1,
6.2
7.1.3,
7.5.3,
8.2.4
6.9,7.6

5.2.5

6.4.6,
8.6.6

5.4.1,
6.2.9

7.2.3

145

146

PRINCPIO VII : ADEQUAO AO APRENDIZADO

Para a questo:
Requer muito tempo para
aprender.

No encoraja a experimentar
novas funes.

Verificar os seguintes itens da parte

12
13
14
15
16
8.1.7,
5.1,
8.3.1,
5.2.2
8.3.2,
8.3.3
6.9

Requer a memorizao de 5.9.1,

muitos detalhes. 7.1.2,
7.1.3,
7.1.4
projetado de forma que o
que aprendido dificilmente
memorizado.
difcil de aprender sem
apoio externo ou um manual.

7.2.3

5.1,5.3

8.2.3,
8.2.3

6.1

5.2.4,
5.3.1,
6.2,
10.1,
10.2,
10.3

6.1.5

5.1.3,
7.6

17
5.2.1,
5.2.2

6.4.1,
6.4.2,
6.4.3,
7.3
5.1,
5.3.4,
6.3

5.3.7

146