IntHumCom-CRC-200x280.indd - TamiresBotta

INTERFACE HUMANO-COMPUTADOR
CURSOS DE GRADUAÇÃO – EAD

Interface Humano-Computador – Prof. Ms. Marcos Alexandre Rose Silva
Olá, meu nome é Marcos Alexandre Rose Silva. Sou graduado em Ciência da Computação pela
Universidade de Franca – UniFran e mestre em Ciência da Computação (área de concentração:
Engenharia de So ware com ênfase em Interação Humano-Computador – IHC) pela Universidade
Federal de São Carlos – UFSCar. Atualmente, sou aluno de doutorado da UFSCar e uma das áreas
que pesquiso está relacionada com o uso do conhecimento cultural para aprimorar a Interação
Humano-Computador.
Fazemos parte do Claretiano - Rede de Educação

Marcos Alexandre Rose Silva
INTERFACE HUMANO-COMPUTADOR
Batatais
Claretiano
2013
© Ação Educacional Clare ana, 2008 – Batatais (SP)
Versão: dez./2013
004.019 S578i
Silva, Marcos Alexandre Rose

Interface humano-computador / Marcos Alexandre Rose Silva – Batatais,
SP : Claretiano, 2013.
166 p.
ISBN: 978-85-8377-118-0
1. Breve histórico sobre Interface Humano-Computador (IHC). 2. Interfaces

avançadas. 3. Prototipação. 4. Métodos para avaliação da interface. 5. IHC
na web. I. Interface humano-computador.
CDD 004.019
Corpo Técnico Editorial do Material DidáƟco Mediacional

Coordenador de Material DidáƟco Mediacional: J. Alves
Preparação Revisão
Aline de Fátima Guedes Cecília Beatriz Alves Teixeira
Camila Maria Nardi Matos Felipe Aleixo
Carolina de Andrade Baviera Filipi Andrade de Deus Silveira
Cá a Aparecida Ribeiro Paulo Roberto F. M. Sposati Ortiz
Dandara Louise Vieira Matavelli Rodrigo Ferreira Daverni
Elaine Aparecida de Lima Moraes Sônia Galindo Melo
Josiane Marchiori Mar ns Talita Cristina Bartolomeu
Lidiane Maria Magalini Vanessa Vergani Machado
Luciana A. Mani Adami
Luciana dos Santos Sançana de Melo Projeto gráfico, diagramação e capa
Luis Henrique de Souza Eduardo de Oliveira Azevedo
Patrícia Alves Veronez Montera Joice Cristina Micai
Rosemeire Cristina Astolphi Buzzelli Lúcia Maria de Sousa Ferrão
Simone Rodrigues de Oliveira Luis Antônio Guimarães Toloi
Raphael Fantacini de Oliveira
Bibliotecária Tamires Botta Murakami de Souza
Ana Carolina Guimarães – CRB7: 64/11 Wagner Segato dos Santos
Todos os direitos reservados. É proibida a reprodução, a transmissão total ou parcial por qualquer forma
e/ou qualquer meio (eletrônico ou mecânico, incluindo fotocópia, gravação e distribuição na web), ou o
arquivamento em qualquer sistema de banco de dados sem a permissão por escrito do autor e da Ação
Educacional Claretiana.
Centro Universitário Claretiano

Rua Dom Bosco, 466 - Bairro: Castelo – Batatais SP – CEP 14.300-000
cead@claretiano.edu.br
Fone: (16) 3660-1777 – Fax: (16) 3660-1780 – 0800 941 0006
www.claretiano.edu.br
Fazemos parte do Claretiano - Rede de Educação

SUMÁRIO
CADERNO DE REFERÊNCIA DE CONTEÚDO

1 INTRODUÇÃO ..............................................................................................................................................7
2 ORIENTAÇÕES PARA ESTUDO .....................................................................................................................8
UNIDADE 1 INTERFACE HUMANO COMPUTADOR E FATORES HUMANOS

1 OBJETIVOS ...................................................................................................................................................17
2 CONTEÚDOS ................................................................................................................................................17
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE .........................................................................................17
4 INTRODUÇÃO À UNIDADE ..........................................................................................................................18
5 INTERFACE HUMANO COMPUTADOR .......................................................................................................19
6 EXEMPLOS DE INTERFACES ........................................................................................................................21
7 FATORES HUMANOS....................................................................................................................................24
8 CULTURA ......................................................................................................................................................29
9 A MULTIDISCIPLINARIDADE DE IHC ...........................................................................................................31
10 QUESTÕES AUTOAVALIATIVAS ...................................................................................................................32
11 CONSIDERAÇÕES.........................................................................................................................................33
12 E REFERÊNCIAS ...........................................................................................................................................34
13 REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................................................34
UNIDADE 2 BREVE HISTÓRICO SOBRE IHC E INTERFACES AVANÇADAS

1 OBJETIVOS ...................................................................................................................................................35
2 CONTEÚDOS ................................................................................................................................................35
5 PRIMEIRA FASE ............................................................................................................................................36
6 SEGUNDA FASE ............................................................................................................................................38
7 TERCEIRA FASE ............................................................................................................................................39
8 INTERFACES AVANÇADAS ...........................................................................................................................42
9 REALIDADE VIRTUAL ...................................................................................................................................42
10 INTERFACES TANGÍVEIS .............................................................................................................................44
11 WEARABEL COMPUTING ..........................................................................................................................44
12 INTERFACES ORGÂNICAS QUARTA FASE ................................................................................................45
13 INTERFACES HUMANO COMPUTADOR ....................................................................................................47
14 INTERFACES E FILMES ............................................................................................................................... 49
16 CONSIDERAÇÕES ........................................................................................................................................52
17 E REFERÊNCIAS.........................................................................................................................................52
UNIDADE 3 QUALIDADE NO DESENVOLVIMENTO DO SOFTWARE

1 OBJETIVOS ...................................................................................................................................................55
2 CONTEÚDOS ................................................................................................................................................55
5 QUALIDADE E SEUS FATORES .....................................................................................................................56
6 FRAMEWORK E AS QUALIDADES EXISTENTES EM UM SOFTWARE .......................................................58
7 BARREIRAS PARA A FALTA DE QUALIDADE NO USO .................................................................................61
9 CONSIDERAÇÕES .........................................................................................................................................65
10 E REFERÊNCIAS ..........................................................................................................................................65
11 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................65
UNIDADE 4 MODELOS DE PROCESSO DE SOFTWARE E PROTOTIPAÇÃO
1 OBJETIVOS ...................................................................................................................................................67
2 CONTEÚDOS ................................................................................................................................................67
5 MODELOS DE PROCESSO DE SOFTWARE ..................................................................................................69
6 PROJETO CENTRADO NO USUÁRIO UCD USERͳCENTERED DESIGN .................................................74
7 PROTOTIPAÇÃO ..........................................................................................................................................79
9 CONSIDERAÇÕES .........................................................................................................................................85
10 E REFERÊNCIAS ...........................................................................................................................................85
UNIDADE 5 MÉTODOS PARA AVALIAÇÃO DA INTERFACE

1 OBJETIVOS ...................................................................................................................................................87
2 CONTEÚDOS ................................................................................................................................................87
3 ORIENTAÇÕES PARA O ESTUDO DA UNIDADE ..........................................................................................88
5 AVALIAÇÃO HEURÍSTICA .............................................................................................................................91
6 AS DEZ HEURÍSTICAS ..................................................................................................................................92
7 ESCALA DE SEVERIDADE .............................................................................................................................102
8 EXEMPLO DE APLICAÇÃO DA AVALIAÇÃO HEURÍSTICA ...........................................................................103
9 CHECKLIST ....................................................................................................................................................107
10 PERCURSO COGNITIVO ..............................................................................................................................114
11 EXEMPLO DE APLICAÇÃO PERCURSO COGNITIVO ................................................................................122
13 CONSIDERAÇÕES.........................................................................................................................................134
14 E REFERÊNCIAS ...........................................................................................................................................134
15 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................................135
UNIDADE 6 IHC NA WEB

1 OBJETIVOS ...................................................................................................................................................137
2 CONTEÚDOS ................................................................................................................................................137
5 HISTÓRIA DO PADRÃO ................................................................................................................................139
6 PADRÕES DE MONTERO .............................................................................................................................140
7 PADRÕES DE WEB SITES..............................................................................................................................140
8 PADRÕES DE PÁGINA WEB .........................................................................................................................145
9 PADRÕES ORNAMENTAIS ...........................................................................................................................150
11 CONSIDERAÇÕES.........................................................................................................................................163
12 E REFERÊNCIAS ...........................................................................................................................................164
14 CONSIDERAÇÕES FINAIS ............................................................................................................................165
EAD
Caderno de
Referência de
Conteúdo
CRC
Conteúdo ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Fatores Humanos. Breve histórico sobre IHC. Interfaces Avançadas. Modelos de Processo de Software. Prototipa-
ção. Métodos para avaliação da interface. IHC na web.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
1. INTRODUÇÃO
O que é a interface humano-computador? Qual é a sua importância durante e após o de-
senvolvimento de um software? Qual é a sua influência nos custos de desenvolvimento? Qual
é a vantagem competitiva no mercado e no uso de sistemas computacionais ao se considerar a
interface humano-computador? Estes serão alguns dos questionamentos que você deverá en-
tender no decorrer do estudo deste Caderno de Referência de Conteúdo.
A interface humano-computador é uma área relativamente nova se comparada com as
outras áreas da computação, mas, desde o início, tem mostrado-se de extrema importância
para desenvolver softwares adequados para os usuários. No entanto, pensar, planejar, utilizar e
testar estratégias dessa área não são práticas triviais. É necessário um bom conhecimento delas,
pois, ao se deparar com situações complicadas em qualquer fase de desenvolvimento do sof-
tware, é fundamental saber qual é a melhor estratégia, bem como em qual momento ela deve
ser utilizada e como ela deve ser aplicada.
Apenas com esse conhecimento será possível garantir a qualidade no uso dos conceitos
existentes nessa área e ter como resultado um software de qualidade. Neste Caderno de Re-
ferência de Conteúdo (CRC), o objetivo será justamente este: possibilitar um estudo criterioso
acerca dos conceitos da interface humano-computador, descrevendo, também, como aplicar
esses conceitos em situações práticas. O intuito de unir a teoria à prática é permitir sedimentar
8 © Interface Humano-Computador
o conhecimento e aproximar a teoria do dia a dia dos profissionais nas empresas, universidades,
entre outras instituições.
Após esta introdução aos conceitos principais do Caderno de Referência de Conteúdo,
apresentaremos, a seguir, no tópico Orientações para estudo, algumas orientações de caráter
motivacional, bem como dicas e estratégias de aprendizagem que poderão facilitar o seu estudo.
2. ORIENTAÇÕES PARA ESTUDO

Abordagem Geral
Neste tópico, apresenta-se uma visão geral do que será estudado neste Caderno de Refe-
rência de Conteúdo. Aqui, você entrará em contato com os assuntos principais deste conteúdo
de forma breve e geral e terá a oportunidade de aprofundar essas questões no estudo de cada
unidade. No entanto, esta Abordagem Geral visa fornecer-lhe o conhecimento básico necessário
para que você possa construir um referencial teórico com base sólida – científica e cultural –,
para que, no futuro exercício de sua profissão, você a exerça com competência cognitiva, ética
e responsabilidade social.
Neste Caderno de Referência de Conteúdo, estudaremos questões relacionadas aos siste-
mas interativos, que são os sistemas computacionais que proporcionam algum tipo de interação
com o usuário.
Quando falamos de interação entre o homem e a máquina, estamos falando de sistemas
que possuem, de um lado, uma máquina, um equipamento, e de outro, uma pessoa.
Assim, é importante compreendermos como o usuário percebe a aplicação computacional
e como a área de IHC estuda as melhores maneiras de proporcionar interfaces que sejam fáceis
de entender, fáceis de usar e, realmente, úteis.
Considerando que a maioria dos sistemas computacionais atuais são interativos, há um
trabalho muito grande nos estudos que envolvem a área de IHC.
Além disso, você terá a oportunidade de conhecer os métodos e as técnicas para conce-
ber bons sistemas interativos, e daremos um enfoque especial aos sistemas produzidos para a
internet. Isto significa dizer que os sistemas devem ser concebidos com foco no usuário e no
humano, pois só quando consideramos a questão das "pessoas" que vão usar os equipamentos,
os softwares e as suas funcionalidades é que podemos desenvolver sistemas que efetivamente
sejam úteis e que apoiem o trabalho do usuário.
A área de IHC preocupa-se com duas questões principais:
1) a primeira delas é a funcionalidade, ou seja, os sistemas têm de funcionar da forma
como se espera que eles funcionem;
2) a segunda é a questão da usabilidade, ou seja, a forma como as funcionalidades do
sistema estarão disponíveis para os usuários ou, ainda, como essas funcionalidades
serão apresentadas visual e interativamente.
A seguir, descrevemos essas duas grandes questões da IHC, que são a funcionalidade e a
usabilidade.
A funcionalidade pode ser considerada a mais clara de compreender, pois se relaciona
com o conjunto de tarefas desempenhadas pelo sistema e que serão utilizadas pelo usuário para
maximizar suas funções de forma mais eficiente.
© Caderno de Referência de Conteúdo 9
A usabilidade é a facilidade com que a interface pode garantir a sua utilização.

Considerando esse conceito de usabilidade, você já deve ter percebido que ela pode estar
presente em qualquer coisa do dia a dia, e não somente nos sistemas computacionais, certo?
Vamos fazer uma reflexão sobre esse assunto da usabilidade empregada em nosso coti-
diano.
Você já deve ter utilizado os serviços de 0800 de alguma empresa e já deve ter passado
por uma situação semelhante, em que você fica na linha aguardando por "horas" para conseguir
ser atendido.
Quando alguém atende, logo você pensa, antes de dizer qualquer coisa: "Ufa, finalmente!".
Só que a voz do outro lado da linha é de uma máquina, e não de um ser humano. Pois é.
Então, os seus "nervos" começam a ficar mais "agitados" ainda.
O pior é quando você tem uma infinidade de opções a escolher para falar com um aten-
dente, mas nenhuma daquelas opções pode resolver o seu problema!
Dessa forma, podemos relacionar, também, os produtos com boa usabilidade e os outros
não tão bons assim. Igualmente, há os sistemas que apresentam boa usabilidade ou não. Vamos
estudar algumas técnicas que vão auxiliar você no desenvolvimento de sistemas que tenham
boa usabilidade e boa interação com o usuário.
Para contextualizar, faremos uma introdução à evolução histórica dos sistemas e, con-
sequentemente, das interfaces. Vamos recapitular como se deu a evolução tecnológica, que
proporcionou o grande avanço das técnicas e dos padrões de IHC que conhecemos hoje e que
estudaremos no decorrer deste Caderno de Referência de Conteúdo.
Provavelmente, você já deve ter estudado em algumas disciplinas do seu curso ou tal-
vez conheça por outros meios a evolução histórica dos computadores, mas, normalmente, pelo
enfoque do hardware. No entanto, ao estudar cada fase da evolução dos computadores, você
chegou a observar como aconteceu a evolução da interface de interação da máquina com as
pessoas?
Observe que os primeiros computadores possuíam uma estrutura tão grande que, para
utilizá-los, os usuários tinham que praticamente "entrar dentro" deles, como, por exemplo, o
ENIAC, que exemplifica bem a primeira fase dos computadores. Nesta fase, quase não havia
nenhuma interface, e toda manipulação das funcionalidades era diretamente realizada no har-
dware, sem uma interface amigável.
Já na segunda fase dos computadores, é possível visualizar um computador mais próximo
daquele que estamos acostumados hoje em dia, que foram os monitores monocromáticos, ba-
seados em prompt e que funcionam por meio de comandos parametrizados. Mas uma questão
importante que marcou essa fase foi a introdução do conceito de timesharing, que é a divisão do
tempo do uso do computador compartilhado entre vários usuários, dividindo o uso da CPU entre
todos eles, mas oferecendo a sensação de computador dedicado. Veja só que grande avanço!
A terceira fase da evolução é esta que conhecemos e vivenciamos atualmente, em que as
interfaces são baseadas em janelas – como as famosas janelas do Windows, que muitas pessoas
utilizam, as quais têm como base menus, mouse e, até mesmo, telas touch screen, que apresen-
tam botões clicados nas telas. Foi daí que surgiu o termo "Winp Guis" (Window, Icons, Menus,
Pointing Devices – Graphical User Interface), que traduz todas essas funcionalidades da terceira
geração, que é a era que estamos vivenciando da Interface Humano-Computador.
Claretiano - Centro Universitário

Poderíamos parar nesta terceira fase, mas as pesquisas apontam para uma quarta fase das
interfaces, que, talvez, não esteja tão longe de ser alcançada. Essa quarta fase estuda uma nova
forma de interagir com os computadores, uma forma ainda mais natural e intuitiva.
Nesse contexto, surgem algumas tecnologias que envolvem essa quarta fase da evolução
das interfaces de interação entre humanos e computadores, que são:
1) a realidade aumentada;
2) as interfaces tangíveis;
3) as tecnologias usáveis;
4) as interfaces orgânicas.
A realidade aumentada é uma área que proporciona uma interface mais avançada com o
usuário por meio do uso de um hardware mais poderoso, tal como luvas, óculos estereoscópi-
cos, capacete e outros equipamentos que permitem ao usuário uma interação com poder com-
putacional mais elevado do que aquilo com que estamos acostumados no cotidiano de trabalho.
Essa área ainda enfrenta alguns problemas com o custo de equipamentos e a própria precisão
de proximidade com o que é real e o que é virtual.
Interfaces tangíveis são aquelas que possibilitam que as informações digitais tenham for-
mas físicas e que permitem ser tocadas e manipuladas com as mãos, como você pode ver ou
rever no filme Minority Report.
Outro tipo de tecnologia que se classifica na quarta fase das interfaces são as tecnologias
usáveis ou wearabel computing. Isso mesmo é a computação usável, que permite a você poder
carregar algum tipo de processamento armazenado em uma roupa, em um pingente ou, até
mesmo, em seus óculos.
Por fim, para fechar esse conjunto de tecnologias que podem introduzir e classificar a
quarta fase, há as interfaces orgânicas. Essa tecnologia recebeu esse nome porque permite
um tipo de interface baseada nas coisas observadas na natureza, que se transformam e que se
adaptam à forma com que as pessoas vivem e se comunicam e à sua cultura, e que podem ser
maleáveis.
Observe, com essa breve evolução apresentada sobre as interfaces, que a IHC e as tecno-
logias que facilitam a vida do ser humano no contato com a máquina por meio do software e
suas funcionalidades caminham a passos largos.
Mas o que é realmente importante para o usuário é aquilo que ele percebe do sistema, e
isto que "ele percebe" é a interface. Dessa forma, há uma frase muito usada em computação,
que diz o seguinte: "para o usuário, a interface é o sistema".
Assim, podemos ainda dizer que a interface ideal é a "não interface", ou seja, é quando a
interface é transparente para o usuário, quando ele pode usar as funcionalidades do sistema de
forma natural.
Pensando nisto, qual seria a interface ideal para você?
E aí, conseguiu imaginar como ela seria?
Será que a interface ideal é aquela que obedece aos seus comandos de voz e executa o
que você pede?
Ou seria aquela interface que reconhecesse seus gestos?
Talvez uma que reconheça seus pensamentos e execute o que você quer sem ter qualquer
ação física. O que acha?
O filme Surrogates (ou Os Substitutos, como pode ser traduzido) ilustra um mundo em
que pessoas podem controlar robôs; estes representam a própria pessoa no mundo real, con-
trolada por seus pensamentos e que caminha livremente e executa suas tarefas cotidianas, tare-
fas essas que, em vez de serem executadas pela pessoa, seriam, nesse caso, executadas por seu
robô substituto, que estaria ligado ao seu cérebro e que obedeceria às suas ordens.
Nesse contexto, podemos dizer que a interface ideal para uma pessoa é aquela que é in-
tuitiva, transparente e que executa suas funcionalidades da forma mais natural possível. É claro
que estamos um pouco distantes de termos à nossa disposição, no nosso cotidiano, interfaces
tão naturais assim, não é mesmo? Mas, como você pode ver, a evolução é grande e está cada vez
mais presente em nossas vidas.
Considerando tudo isso, você já parou para pensar qual é o custo de interface em um
projeto?
Não? Pois deveria! Sabe por quê?
Porque, atualmente, as interfaces chegam a custar 50% do valor total dos projetos de de-
senvolvimento de software, e isto tende a aumentar à medida que as tecnologias usáveis, as in-
terfaces tangíveis e orgânicas e os recursos audiovisuais estão sendo introduzidos e explorados
cada vez mais, o que encarece o projeto das interfaces. Entretanto, essas tecnologias são cada
vez mais utilizadas e adotadas pelas pessoas, e é claro que seria dessa forma, pois elas facilitam
a vida e o uso dos sistemas.
Quando você for desenvolver seu sistema, especialmente os sistemas para web, tenha
alguns cuidados básicos que podem ajudar os usuários a navegarem e encontrarem as informa-
ções que precisam. É importante que você deixe os usuários à vontade ao usar o seu sistema.
Por exemplo, a questão cultural é algo a ser levado em consideração. As cores têm sig-
nificados diferentes para as diversas culturas. Uma noiva ocidental, por exemplo, normalmen-
te prefere usar branco. Já uma noiva oriental tem preferência para cores mais fortes, como o
vermelho. Isto envolve uma questão da cultura e do significado das cores para as pessoas, e,
ainda considerando a ocasião, o branco para uma brasileira representaria a pureza, a castidade,
a virgindade, e essas questões são importantes. Nessa ocasião, dado o seu significado, é mais
importante o branco ser destacado para uma brasileira do que o vermelho.
Este foi apenas um exemplo, mas você deve considerar os diversos fatores de cromatolo-
gia (estudo das cores), que poderão estar envolvidos no projeto da interface do seu sistema.
Outro exemplo que podemos citar seria o público-alvo para o qual seu sistema se destina.
Você precisa conhecer as pessoas que usarão o seu sistema, saber de suas necessidades e suas
limitações.
Imagine que você esteja projetando um sistema para pessoas acima de 60 anos. Você teria
de pensar na forma adequada da disposição dos objetos gráficos na interface, no tipo de lin-
guagem que poderia utilizar nos textos e no tamanho da fonte, pois uma pessoa idosa pode ter
dificuldades de visão mais comumente do que uma pessoa jovem; você também teria de pensar
nas facilidades de navegação e nos recursos audiovisuais que seriam empregados. Certamente,
um sistema, com as mesmas funcionalidades para pessoas com idade entre 20 e 40 anos teria
uma interface bem diferente; talvez com mais opções, mais cores vibrantes e ícones chamando
a atenção para assuntos diversos, além de fontes menores, pois, com isso, é possível disponibi-
lizar mais informações, e as pessoas poderão ter maior facilidade de assimilação dos conteúdos
e, também, mais facilidade para a leitura.

Enfim, a interface deve considerar o público para o qual se destina, ou seja, as pessoas que
utilizarão o sistema, para, assim, proporcionar que as funcionalidades estejam à disposição dos
usuários da forma adequada.
Para dar continuidade à nossa abordagem geral, vamos retomar o conceito de "funciona-
lidade".
A funcionalidade do sistema é definida pelo conjunto de tarefas desempenhadas pelo
computador que facilitam o trabalho das pessoas, ou seja, os usuários do computador.
Caso você já tenha estudado em Engenharia de Software como são trabalhadas as ques-
tões do desenvolvimento das funcionalidades do sistema, já deve ter se perguntado como essas
áreas, a Engenharia de Software e a Interface Humano-Computador, se relacionam e se diferen-
ciam, não é mesmo?
Realmente, elas têm muitas características em comum. Vejamos:
a) o planejamento do projeto e de todo o sistema;
b) o orçamento financeiro envolvido em cada fase – desde o planejamento até a sua
implementação, seus testes e sua manutenção;
c) as questões de confiabilidade;
d) a disponibilidade do sistema;
e) a integridade dos dados;
f) a segurança dos dados e das pessoas que utilizam o sistema;
g) a padronização;
h) a consistência dos dados;
i) a portabilidade dos dados de acordo com os dispositivos que serão acessados;
Existem outras características que não foram listadas, mas que podem ser preocupações
comuns das áreas de Engenharia de Software e IHC.
No entanto, há uma diferença importante entre essas duas subáreas da computação. A
Engenharia de Software preocupa-se, especialmente, com as funcionalidades do sistema, ou
seja, em fazer que o sistema funcione da forma como foi proposto e atenda as necessidades
do usuário em termos de funcionalidades que deve prover. Já a IHC tem como foco o usuário,
e, por isso, essas áreas se complementam para prover interfaces e sistemas que sejam úteis e
funcionais e que atendam o que as pessoas realmente precisam.
Para que um sistema seja centrado no usuário, é necessário estudar os comportamentos do
usuário, a sua forma de comunicação, as questões de psicologia, a antropologia, a linguística e assim
por diante. Isto significa que a IHC envolve profissionais de todas essas áreas e, também, alguns para-
digmas importantes que precisam ser considerados no projeto de interfaces, que são três:
1) modelo cognitivo;
2) modelo de design participativo;
3) modelo de design centrado no usuário.
O modelo cognitivo é mais próximo da área da Psicologia e da Semiótica, que estudam os
modelos mentais das pessoas, para entender as tarefas que serão executadas no computador,
ou seja, qual é a lógica de pensamento que uma pessoa possui e como ela pode ser traduzida
para o modelo computacional. A Semiótica é o estudo dos símbolos para trabalhar, por exem-
plo, os ícones que vão compor a interface de um sistema e, também, outros símbolos que farão
parte da interface.
O modelo de design participativo é uma técnica que usa a participação do usuário para
auxiliar no processo de desenvolvimento. O usuário passa a fazer parte da equipe – é claro que
ele não vai ajudar a desenvolver o sistema, programando em uma linguagem de computador,
mas vai auxiliar na tomada de decisões, para que os programadores e projetistas de sistemas
possam compreender melhor as necessidades do usuário e para que elas sejam atendidas e
estejam incorporadas nas funcionalidades que o sistema provê.
Já no modelo de design centrado no usuário não há a participação do usuário presente
na equipe, mas, sim, pessoas das diferentes áreas, que deverão compor a equipe para estudar
e compreender as necessidades do usuário e traduzi-las para que o sistema funcione como se
espera, atendendo, de forma eficiente, o que o usuário precisa.
Desejamos um bom trabalho e sucesso nos estudos!
Glossário de Conceitos
O Glossário de Conceitos permite a você uma consulta rápida e precisa das definições con-
ceituais, possibilitando-lhe um bom domínio dos termos técnico-científicos utilizados na área de
conhecimento dos temas tratados em Interface Humano-Computador. Veja, a seguir, a definição
dos principais conceitos:
1) Computador: refere-se a todas as características computacionais importantes e ne-
cessárias para o desenvolvimento de um software com qualidade, como processa-
mento, capacidade de armazenamento, funcionalidades etc.
2) Métodos de avaliação: no contexto deste material, são estratégias para avaliar a in-
terface com o intuito de observá-la e adequá-la de acordo com as características e
necessidades do usuário.
3) Modelos de processo: são conjuntos de atividades para a produção de sistema com-
putacional.
4) Padrão: pode ser definido como uma solução de sucesso a um problema recorrente.
5) Projeto centrado no usuário: estratégia que tem como principal característica pensar
no usuário e em todo o processo de desenvolvimento do software.
6) Prototipação: tem como finalidade demonstrar as ideias e as características de funcio-
namento do sistema por meio de desenhos.
7) Software com qualidade: software capaz de satisfazer as necessidades explícitas e
implícitas do usuário.
8) Usuário: refere-se à pessoa ou ao público-alvo a quem se destina o software, ou seja,
o usuário representa o indivíduo que utilizará o sistema desenvolvido.
Esquema dos Conceitos-chave

Para que você tenha uma visão geral dos conceitos mais importantes deste estudo, apre-
sentamos, a seguir (Figura 1), um Esquema dos Conceitos-chave. O mais aconselhável é que
você mesmo faça o seu esquema de conceitos-chave ou até mesmo o seu mapa mental. Esse
exercício é uma forma de você construir o seu conhecimento, ressignificando as informações a
partir de suas próprias percepções.
É importante ressaltar que o propósito desse Esquema dos Conceitos-chave é representar,
de maneira gráfica, as relações entre os conceitos por meio de palavras-chave, partindo dos
mais complexos para os mais simples. Esse recurso pode auxiliar você na ordenação e na se-
quenciação hierarquizada dos conteúdos de ensino.
Com base na teoria de aprendizagem significativa, entende-se que, por meio da organiza-
ção das ideias e dos princípios em esquemas e mapas mentais, o indivíduo pode construir o seu
conhecimento de maneira mais produtiva e obter, assim, ganhos pedagógicos significativos no
seu processo de ensino e aprendizagem.

Aplicado a diversas áreas do ensino e da aprendizagem escolar (tais como planejamentos de

currículo, sistemas e pesquisas em Educação), o Esquema dos Conceitos-chave baseia-se, ainda,
na ideia fundamental da Psicologia Cognitiva de Ausubel, que estabelece que a aprendizagem
ocorre pela assimilação de novos conceitos e de proposições na estrutura cognitiva do aluno. As-
sim, novas ideias e informações são aprendidas, uma vez que existem pontos de ancoragem.
Tem-se de destacar que "aprendizagem" não significa, apenas, realizar acréscimos na es-
trutura cognitiva do aluno; é preciso, sobretudo, estabelecer modificações para que ela se con-
figure como uma aprendizagem significativa. Para isso, é importante considerar as entradas de
conhecimento e organizar bem os materiais de aprendizagem. Além disso, as novas ideias e os
novos conceitos devem ser potencialmente significativos para o aluno, uma vez que, ao fixar
esses conceitos nas suas já existentes estruturas cognitivas, outros serão também relembrados.
Nessa perspectiva, partindo-se do pressuposto de que é você o principal agente da cons-
trução do próprio conhecimento, por meio de sua predisposição afetiva e de suas motivações
internas e externas, o Esquema dos Conceitos-chave tem por objetivo tornar significativa a sua
aprendizagem, transformando o seu conhecimento sistematizado em conteúdo curricular, ou
seja, estabelecendo uma relação entre aquilo que você acabou de conhecer com o que já fazia
parte do seu conhecimento de mundo (adaptado do site disponível em: <http://penta2.ufrgs.
br/edutools/mapasconceituais/utilizamapasconceituais.html>. Acesso em: 11 mar. 2010).
Figura 1 Esquema dos Conceitos-chave do Caderno de Referência de Conteúdo de Interface Humano-Computador.
Como você pode observar, esse Esquema dá a você, como dissemos anteriormente, uma
visão geral dos conceitos mais importantes deste estudo. Ao segui-lo, você poderá transitar en-
tre um e outro conceito e descobrir o caminho para construir o seu processo de ensino-aprendi-
zagem. Por exemplo, para atingir um nível de qualidade desejável ao software, é importante que
desde o seu planejamento haja a preocupação com dois fatores que influenciam, diretamente,
para que essa qualidade ocorra: um relacionado com o usuário e o outro, com o computador.
Como o enfoque principal deste Caderno de Referência de Conteúdo está na interface humano-
-computador, a maioria dos conteúdos estão direcionados aos conceitos relacionados a investi-
gar, compreender e avaliar a forma com que o usuário utilizará o software.
O Esquema dos Conceitos-chave é mais um dos recursos de aprendizagem que vem se
somar àqueles disponíveis no ambiente virtual, por meio de suas ferramentas interativas, bem
como àqueles relacionados às atividades didático-pedagógicas realizadas presencialmente no
polo. Lembre-se de que você, aluno EaD, deve valer-se da sua autonomia na construção de seu
próprio conhecimento.
Questões Autoavaliativas
No final de cada unidade, você encontrará algumas questões autoavaliativas sobre os con-
teúdos ali tratados, as quais podem ser de múltipla escolha ou abertas com respostas objetivas
ou dissertativas. Vale ressaltar que se entendem as respostas objetivas como as que se referem
aos conteúdos matemáticos ou àqueles que exigem uma resposta determinada, inalterada.
Responder, discutir e comentar essas questões, bem como relacioná-las à prática do ensino
de Interface Humano-Computador pode ser uma forma de você avaliar o seu conhecimento. As-
sim, mediante a resolução de questões pertinentes ao assunto tratado, você estará se preparando
para a avaliação final, que será dissertativa. Além disso, essa é uma maneira privilegiada de você
testar seus conhecimentos e adquirir uma formação sólida para a sua prática profissional.
Você encontrará, ainda, no final de cada unidade, um gabarito, que lhe permitirá conferir
as suas respostas sobre as questões autoavaliativas de múltipla escolha.
As questões de múltipla escolha são as que têm como resposta apenas uma alternativa correta. Por
sua vez, entendem-se por questões abertas objetivas as que se referem aos conteúdos matemáticos
ou àqueles que exigem uma resposta determinada, inalterada. Já as questões abertas dissertativas
obtêm por resposta uma interpretação pessoal sobre o tema tratado; por isso, normalmente, não há
nada relacionado a elas no item Gabarito. Você pode comentar suas respostas com o seu tutor ou com
seus colegas de turma.
Bibliografia Básica
É fundamental que você use a Bibliografia Básica em seus estudos, mas não se prenda só
a ela. Consulte, também, as bibliografias complementares.
Figuras (ilustrações, quadros...)

Neste material instrucional, as ilustrações fazem parte integrante dos conteúdos, ou seja, elas
não são meramente ilustrativas, pois esquematizam e resumem conteúdos explicitados no texto.
Não deixe de observar a relação dessas figuras com os conteúdos, pois relacionar aquilo que está no
campo visual com o conceitual faz parte de uma boa formação intelectual.
Dicas (motivacionais)
Este estudo convida você a olhar, de forma mais apurada, a Educação como processo de
emancipação do ser humano. É importante que você se atente às explicações teóricas, práticas e

científicas que estão presentes nos meios de comunicação, bem como partilhe suas descobertas
com seus colegas, pois, ao compartilhar com outras pessoas aquilo que você observa, permite-
-se descobrir algo que ainda não se conhece, aprendendo a ver e a notar o que não havia sido
percebido antes. Observar é, portanto, uma capacidade que nos impele à maturidade.
Você, como aluno dos Cursos de Graduação na modalidade EaD e futuro profissional da
educação, necessita de uma formação conceitual sólida e consistente. Para isso, você contará com
a ajuda do tutor a distância, do tutor presencial e, sobretudo, da interação com seus colegas. Suge-
rimos, pois, que organize bem o seu tempo e realize as atividades nas datas estipuladas.
É importante, ainda, que você anote as suas reflexões em seu caderno ou no Bloco de
Anotações, pois, no futuro, elas poderão ser utilizadas na elaboração de sua monografia ou de
produções científicas.
Leia os livros da bibliografia indicada, para que você amplie seus horizontes teóricos. Coteje-
os com o material didático, discuta a unidade com seus colegas e com o tutor e assista às video-
aulas.
No final de cada unidade, você encontrará algumas questões autoavaliativas, que são im-
portantes para a sua análise sobre os conteúdos desenvolvidos e para saber se estes foram
significativos para sua formação. Indague, reflita, conteste e construa resenhas, pois esses pro-
cedimentos serão importantes para o seu amadurecimento intelectual.
Lembre-se de que o segredo do sucesso em um curso na modalidade a distância é partici-
par, ou seja, interagir, procurando sempre cooperar e colaborar com seus colegas e tutores.
Caso precise de auxílio sobre algum assunto relacionado a este Caderno de Referência de
Conteúdo, entre em contato com seu tutor. Ele estará pronto para ajudar você.
EAD
Interface Humano-Computador
e Fatores Humanos
1. OBJETIVOS
• Entender os conceitos de Interface Humano-Computador.
• Compreender a importância de conhecer os fatores humanos para desenvolver siste-
mas.
• Conhecer os princípios de uma boa interface.
2. CONTEÚDOS
• Interface Humano-Computador.
• Exemplos de Interface.
• Fatores Humanos.
• Cultura.
• A multidisciplinaridade de IHC.
3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE

Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a seguir:
1) Tenha sempre à mão o significado dos conceitos explicitados no Glossário de Con-
ceitos e suas ligações pelo Esquema de Conceitos-chave para o estudo de todas
as unidades deste Caderno de Referência de Conteúdo. Isto poderá facilitar sua
aprendizagem e seu desempenho.
2) Nesta unidade, você iniciará os estudos sobre software partindo de um olhar mais
amplo. A ideia é permitir que você entenda que há outras informações que devem
ser consideradas em todo o processo de desenvolvimento do software, além das
funcionalidades, da capacidade computacional como processamento, do espaço
para armazenamento, da linguagem de programação, entre outros dados de extre-
ma importância.
3) Concentre toda a sua atenção nesta primeira unidade, pois ela servirá como base
para que você compreenda as próximas unidades.
4) Para aprofundar os seus conhecimentos, pesquise em livros e, também, na inter-
net sobre a importância da interface e da interação humano-computador no de-
senvolvimento de software, bem como o seu uso pelos usuários.
5) Leia os livros e acesse os sites da bibliografia indicada para que você amplie seu co-
nhecimento sobre a área de interação humano-computador, que é relativamente
nova quando comparada às outras áreas da computação.
4. INTRODUÇÃO À UNIDADE
Nesta primeira unidade, você terá a oportunidade de estudar sobre a Interface Humano-
Computador e conhecer a importância de entender os fatores humanos, ou seja, a forma com
que as pessoas realizam as suas atividades, pensam e agem para desenvolver sistemas compu-
tacionais eficientes e usáveis.
Entretanto, antes de iniciar a explicação de todos os conceitos que esta área envolve, ve-
remos um exemplo prático sobre algo muito comum nos dias de hoje, para ilustrar, mesmo que
não completamente, o quanto esta área é útil e como é válido aprender e se preocupar com
todos os conceitos que serão apresentados posteriormente.
Observe que a Figura 1 ilustra um objeto muito comum atualmente, algo que vemos dia-
riamente em muitos lugares, especialmente dentro dos carros.
Figura 1 Foto meramente ilustrativa.
Depois de observar e analisar a foto, foi fácil identificar o que é esse objeto e para que ele
é utilizado. Agora, você saberia responder como você identificou o que é esse objeto e para que
ele é utilizado?
É incrível a capacidade humana, pois apesar de parecer algo muito simples, em segundos,
você observou o formato, o tamanho, as cores, os botões e todas as outras características exis-
tentes nesse objeto para identificar que ele se trata de um rádio, muito comum em carros, e
que, por meio dele, podemos escutar qualquer tipo de música.
© U1 – Interface Humano-Computador e Fatores Humanos 19
Dependendo do seu conhecimento e da sua experiência com esse tipo de rádio, você po-
deria até listar algumas funcionalidades existentes nele, mesmo não o conhecendo exatamente,
considerando, apenas, sua marca e seu modelo.
Agora, analise novamente a Figura 1, observe o visor que há nela, os seus botões e tente
identificar suas funcionalidades. Em seguida, você saberia responder como se faz para ajustar o
relógio desse rádio?
Observe que há uma dificuldade maior para se encontrar em qual local ou botão é possível
ajustar o relógio, do que para identificar o que a figura representa, pois foi fácil perceber que se
trata de um rádio, mas não foi tão simples identificar a funcionalidade desejada. Considerando,
com base na quantidade de botões, que a Figura 1 ilustra um rádio simples e que, mesmo assim,
há uma certa dificuldade em encontrar o que se deseja, imagine o tamanho da dificuldade em
se utilizar um rádio mais complexo.
Até aqui, falamos apenas de um equipamento comum, um rádio, que é facilmente encon-
trado e que, possivelmente, a maioria das pessoas conhece. Mas há uma incontável quantidade
de equipamentos eletrônicos, comuns ou não, que precisamos identificar para que servem, e
saber como utilizá-los.
Você já vivenciou uma situação parecida com esta de ajustar a hora do rádio, em que teve
de utilizar um equipamento eletrônico, mas teve dificuldades ou, simplesmente, desistiu porque
percebeu a complexidade de se entender e trabalhar com ele e decidiu não tentar mais com
receio de estragar o equipamento?
Se isso aconteceu com você, não se preocupe, pois a maioria das pessoas já passou por
situações semelhantes. Contudo, é necessário entender que a dificuldade em utilizar algum
equipamento, ou não entender a sua funcionalidade não é sua culpa. Os projetistas, pessoas
responsáveis por planejar a construção de um equipamento, são responsáveis por desenvolver
equipamentos que você consiga usar, da mesma maneira que você, que vai planejar, imple-
mentar ou avaliar um software, é responsável por permitir que o seu cliente entenda e use o
programa.
Essa responsabilidade não é algo tão simples, existem várias empresas, universidades
e outros tipos de instituições pesquisando a necessidade de permitir que as pessoas utilizem
qualquer tipo de equipamento ou software de maneira útil e fácil. Uma grande quantidade de
dinheiro também está sendo aplicada nessa área de pesquisa, afinal, quando alguém cria um
equipamento ou desenvolve algum programa, tem como principal objetivo a sua utilização.
Nesse contexto, você vai conhecer a Interface Humano-Computador, uma área que está
em plena expansão e que é diretamente relacionada não apenas com o desenvolvimento de
novas tecnologias, mas, especialmente, com o entendimento e a preocupação acerca de como
as pessoas podem utilizá-las.
5. INTERFACE HUMANOͳCOMPUTADOR
A Interface Humano-Computador é uma subárea da computação que busca entender
como as pessoas utilizam os computadores, bem como investigar outras formas de interação,
para que o uso do computador seja cada vez mais fácil e natural.
Quando se fala em interação com o computador, podemos pensar, em primeiro lugar, na
interface, pois é por meio dela que temos acesso às opções, às informações e a outras carac-
terísticas que nos permitem utilizar o computador, ou seja, o que se vê na tela do computador

influencia diretamente na forma que interagimos com ele. Se entendermos o que vemos na tela
e identificarmos as suas funcionalidades, o seu uso será eficaz; entretanto, se houver dificuldade
para compreender as informações existentes na tela e precisarmos procurar todas as suas fun-
cionalidades, a interação com o computador não será tão fácil e útil.
Os pesquisadores Nielsen (2000), Rocha e Baranauskas (2003) e Norman (2006), relatam
que uma boa interface é a não interface, ou seja, o ideal seria ter uma interface tão simples e
fácil de utilizar, que as pessoas iriam, naturalmente, interagir com ela, sem se preocupar em
entender toda a complexidade das funcionalidades e com o que teriam que fazer depois de ter
realizado algo no sistema, pois a própria interface conduziria as pessoas para o próximo passo.
É necessário entender a importância da interface, pois, para muitas pessoas, todo o siste-
ma (hardware + software) é a interface. Podemos comparar essa situação com a de um piloto
de avião, em que o sistema é o visor ou a tela que lhe permite ver as funcionalidades e os outros
controles, ou seja, muitas vezes, não é necessário entender tudo o que existe por trás disso,
como os dispositivos, fios e outros equipamentos. O mesmo acontece com o usuário do compu-
tador, pois ele não precisa entender de processador, de memória RAM e ROM ou de placa mãe
etc. para utilizá-lo.
Com base na explicação anterior, fica mais fácil entender o porquê de algumas pessoas
considerarem um sistema ruim depois de não conseguirem utilizá-lo, pois, não raras vezes, elas
desconsideram a velocidade de processamento, a quantidade de funcionalidade, a forma que as
informações são armazenadas etc., porque elas percebem todas essas características por meio
da interface. Assim, se as pessoas não conseguem utilizar o sistema, elas tendem a desvalorizar
todo o seu potencial.
É interessante observar que, mesmo indiretamente, outras áreas também se preocupam
com a forma com que as pessoas utilizam o sistema. Por exemplo, processamento – relaciona-
do com a área de engenharia, informações armazenadas – relacionadas com banco de dados,
a área de redes, que investiga maneiras de aumentar o trafego de informações e melhorar a
segurança dos dados. Entretanto, no final das contas, a preocupação está em permitir que as
pessoas utilizem o sistema de maneira satisfatória, de forma que possam enviar e receber infor-
mações rapidamente, sentindo-se seguras para trocar informações, com a certeza de que todos
os dados estão protegidos.
A área de banco de dados que investiga as melhores maneiras de coletar, armazenar e
processar os dados também está preocupada em permitir que os dados coletados sejam proces-
sados para que possam ser exibidos de uma forma compreensível e útil para as pessoas, ou seja,
há a preocupação com as informações a que as pessoas vão ter acesso por meio da interface.
Essa é uma importante característica que influencia no uso do computador, afinal, como dito
anteriormente, o que vemos na interface influencia diretamente na maneira como alguém utili-
za o computador. O mesmo acontece nas outras áreas, que, direta ou indiretamente, ajudam a
aprimorar o uso dos computadores pelas pessoas.
Lembre-se de que não estamos discutindo que se um sistema tiver uma boa interface
não será necessário que ele seja rápido no processamento ou seguro no armazenamento das
informações, afinal, não adianta uma interface ser perfeita se, na hora em que for utilizada, o
sistema travar ou as informações ficarem expostas. Apenas estamos ressaltando a importância
da interface na aceitação do sistema e no seu uso efetivo.
Esse está sendo um diferencial atualmente, por isso há um grande investimento das uni-
versidades e, especialmente, das empresas para conseguir uma boa interface. Hoje em dia, há
uma enorme quantidade de sistemas. Por exemplo, se você pesquisar, na web, sistemas para lo-
cadoras, encontrará infinitos, no entanto, o que vai diferenciar esses sistemas? Como as pessoas
escolherão o melhor sistema?
Com certeza, a escolha será influenciada pela interface. Podemos citar algumas questões
que estão diretamente relacionadas ao que as pessoas encontram nela, tais como: quais são as
funcionalidades que existem nesse sistema? É possível entender o que há nele? Ele atende às
minhas necessidades?
Vale ressaltar que o diferencial não está na quantidade de funcionalidades, mas, sim, em
como elas podem ser utilizadas, afinal, pouco útil será um sistema com todas as opções deseja-
das e todas as características necessárias, se essas não forem encontradas ou se forem difíceis
de serem utilizadas. Nesse contexto, é possível afirmar que a interface está diretamente rela-
cionada com a qualidade do sistema, ou seja, se a interface é boa, consequentemente, todo o
sistema (hardware + software) é bom.
Outro aspecto importante para discutirmos é o de que a preocupação e o desenvolvimen-
to na área de Interface Humano-Computador têm proporcionado não somente uma melhor
utilização do computador, mas, também, têm permitido que as pessoas, por meio da interação
com o computador, trabalhem, aprendam e divirtam-se.
6. EXEMPLOS DE INTERFACES
A seguir, apresentaremos alguns exemplos de programas que auxiliam as pessoas, diaria-
mente, em seu ambiente profissional, educacional, em seu lar, ou em qualquer outro lugar.
Educação
A área educacional foi contemplada com os avanços da interface humano-computador,
pois, por meio desse contato com o computador, é possível fazer com que os alunos aprendam
de uma maneira lúdica. Um exemplo disso é o Contexteller, representado pela Figura 2, um
jogo narrativo (de contar histórias) que possui características de RPG, Role-Playing Game (SILVA,
2009).
Por meio desse jogo, o professor pode ensinar aos alunos algumas habilidades que fazem
parte do processo de aprendizagem e da vida, tais como o trabalho colaborativo e a expressão.
Essas, porém, são apenas algumas das habilidades que são cobradas dos adultos no ambiente
profissional, afinal, é essencial que eles saibam conviver e trabalhar uns com os outros, colabo-
rando para realizar as atividades e/ou alcançarem um objetivo comum (GADOTTI, 2000).
No entanto, essas habilidades, muitas vezes, não são desenvolvidas na escola, pois, os
professores têm dificuldades para encontrar ferramentas e/ou atividades que norteiem o seu
trabalho. Assim, esse jogo auxilia o professor, por meio do contar histórias e dos elementos da
interface, a estimular e a explorar essas habilidades nos alunos.

Fonte: SILVA, 2009, p.

Figura 2 Interface do Contexteller.
Coorporativo
O exemplo representado pela Figura 3, Microsotf Word, representa a interface de um pro-
grama muito conhecido e utilizado, não somente nos escritórios e nas escolas, mas, também, em
muitos outros lugares. Esse processador de texto permite que as pessoas criem e editem qualquer
tipo de documento que contenha textos, figuras, gráficos, entre outros elementos, possibilitando,
dessa forma, que elas façam documentos cada vez mais elaborados.
O uso de processadores de textos trouxe grande avanço e mais facilidade para todos, pois,
antigamente, com a máquina de escrever, qualquer erro cometido era sinônimo de recomeçar a
escrever o texto, uma vez que não havia a possibilidade de corrigi-lo.
Figura 3 Microsoft© Word 20

Saúde
Na área da saúde também houve grandes avanços, pois vários sistemas foram desenvolvidos
com o objetivo de auxiliar os médicos no diagnóstico de doenças.
Um exemplo desse avanço é o ultrassom 3D, demonstrado na Figura 4, que, ultimamente, tem
sido aperfeiçoado, e que pode, agora, reconstruir a imagen do bebê em três dimensões, apresentando
os detalhes das mãos, dos pés, da cabeça e de outras partes do corpo. Esse equipamento permite aos
médicos ir além de somente ver o sexo do bebê, pois, por meio dele, é possível verificar se há alguma
alteração estrutural do indivíduo, assim como a presença de doenças cromossômicas, especialmente a
Síndrome de Down (MINHA VIDA, 2009).
É importante ressaltar que, por meio da interface, além dos médicos, outras pessoas, mes-
mo que não sejam especializadas na área da saúde, têm acesso ao conhecimento e também têm
a oportunidade de conhecer e de estudar o corpo humano, as doenças etc.
Como exemplo, temos o programa Re-Mission, apresentado pela Figura 5, um jogo desen-
volvido para que os pacientes com câncer entendam essa doença e sintam um domínio maior
sobre ela, pois, por meio do Re-Mission, o jogador reconhece os sintomas da doença e inicia uma
batalha, destruindo as células cancerosas e controlando os efeitos colaterais (BEALE et al., 2007).
Figura 4 Ultra-Som 3D. Figura 5 Re-Mission.
Entretenimento
Um dos primeiros jogos, conhecido internacionalmente, que apresentou uma realidade
muito próxima da natural, foi o The Sims, demonstrado pela Figura Um jogo de simulação de
vida, em que é possível criar e controlar as vidas de pessoas virtuais. O objetivo do jogo, nesse
mundo virtual, é semelhante ao nosso objetivo do mundo real, ou seja, proporcionar às pessoas
o sustento, o conhecimento, além da diversão, entre outras coisas.
Foi com base nos jogos com essas características que surgiu o assunto sobre a segunda
vida, pois, por meio deles, podemos ter outra vida, porém, virtual; já que é possível comer, dor-
mir, trabalhar, brincar e se relacionar com as pessoas.

Figura 6 The Sims.
Até este momento, discutimos sobre a Interface Humano-Computador e os avanços que

esta área trouxe para as nossas vidas, porém, como dito no início desta unidade, ao falar em
interface, as pessoas lembram-se logo das telas e dos monitores.
Entretanto, essa área preocupa-se não somente com as telas, mas, também, com todos
os dispositivos e equipamentos que estão entre as pessoas e o computador. Assim, há a preo-
cupação com a tela e com o dispositivo que a pessoa vai precisar para utilizar o sistema, com os
botões que precisam ser pressionados em determinados momentos, com os controles etc.
Dessa forma, percebemos que o sentido é mais amplo, pois esta área envolve toda a In-
teração Humano-Computador (IHC). Por isso, a partir de agora, sempre que você ver a sigla IHC
lembre-se de toda a interação, ou seja, não só da interface, mas de tudo o que uma pessoa pre-
cisa para interagir com o computador.
Nesse contexto, é importante compreender o que é a IHC. Segundo ACM SIGCHI (1999),
a IHC preocupa-se com o design, a avaliação e a implementação de sistemas computacionais
interativos para uso humano e com o estudo dos principais fenômenos ao redor deles. Sendo
assim, a IHC preocupa-se com a parte de hardwares (dispositivos e equipamentos), softwares
(programas), e, também, com as características do ser humano, ou seja, com os fatores huma-
nos, considerando os seus aspectos cognitivos e emocionais.
7. FATORES HUMANOS
Os fatores humanos, que são as capacidades físicas e cognitivas, influenciam na forma de
desenvolver sistemas computacionais, pois investigar esses fatores é buscar uma melhor quali-
dade na interação entre pessoas e computadores. Há vários pesquisadores, como Johnson-Laird
(1989), Carrol e Olson (1988) e Rocha e Baranauskas (2003), que descrevem o funcionamento
do cérebro, a capacidade motora e outras características que são importantes de ser compre-
endidas, com o intuito de desenvolver sistemas que respeitem as capacidades e as dificuldades
dos seres humanos, porque, uma vez que se entende e se aplicam todos esses fatores, há uma
possibilidade maior de seu sistema ser utilizado de uma maneira eficaz e natural.
No entanto, nesta unidade, ao invés de descrevermos estudos sobre as capacidades físicas
e cognitivas, serão apresentados alguns conceitos pensando nesses fatores humanos, tendo
em vista que, para estudar as capacidades físicas e cognitivas, precisamos de muitos meses de
estudo para poder compreender, de fato, a ligação entre os neurônios, a memória etc.
Norman (2006) descreveu quatro princípios com base na sua experiência de vivenciar e de
observar as frustrações que as pessoas experimentam com objetos do cotidiano. Quando algo
é desenvolvido sem pensar nos fatores humanos ou sem considerar a maneira que as pessoas
pensam e agem, muitas vezes, torna-se impossível de ser utilizado de modo satisfatório.
Assim como demonstramos anteriormente, na Figura 1, em que a funcionalidade "ajustar
o relógio" está praticamente imperceptível, muitos outros exemplos de equipamentos, que pa-
recem armadilhas, podem ser citados. Veja na Figura 7(a) que a máquina de lavar também está
cada vez mais poderosa e confusa, sem contar os celulares, conforme demonstrado na Figura
7(b), que, atualmente, possuem tantas opções que, ou a função menos utilizada é a de fazer
uma ligação, ou, devido a essa complexidade, muitas pessoas desconhecem toda a capacidade
do aparelho, utilizando somente as funções básicas e fáceis de serem entendidas.
a) b)
Figura 7(a) Máquina de lavar. Figura 7(b) Celular.
Nesse contexto, Norman (2006) identificou os quatro princípios de um bom design (visibi-
lidade e affordances; bom modelo conceitual; bons mapeamentos e feedback).
Informação: ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Lembre-se de que, apesar dos quatro princípios serem estudados e discutidos separadamente, eles estão inter-
relacionados.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Visibilidade e Affordances
O primeiro princípio, o da visibilidade de affordances, defende que as pessoas precisam
visualizar somente as funcionalidades que, realmente, são importantes. Assim, tudo o que é ne-
cessário tem de estar visível, ou seja, quando as pessoas olham uma determinada interface ou
um objeto têm de identificar quais são as partes e como elas podem ser operadas.
É comum, por exemplo, encontrarmos sistemas em que as opções (menus) possuem diver-
sas funcionalidades e qualquer pessoa, mesmo que não possa ter acesso a essas funcionalida-
des, as continua vendo na interface, isso acontece com frequência em sistemas coorporativos,
em que uma pessoa tem de realizar o login, informando nome e senha, para entrar no sistema.
O sistema, por meio do login, identifica se a pessoa é a administradora, a secretária etc.
e limita ou disponibiliza algumas funcionalidades, porém, o que acontece é que mesmo se a
pessoa efetua o login como secretária ela continua vendo as opções de como se fosse a adminis-
tradora, mas essas opções estão bloqueadas, ou seja, não há como serem clicadas. Entretanto,
isso não deveria acontecer, pois quando algo é bloqueado para uma pessoa, ele não deve ser
exibido; isso ajuda, também, a manter uma interface mais limpa e, consequentemente, mais
fácil de ser entendida.
A visibilidade também está relacionada com a forma como as pessoas percebem que algo
foi realizado com sucesso ou não, por exemplo, se conseguiu ligar a televisão, se conseguiu a
linha para realizar uma chamada no telefone, se a temperatura de um forno foi ajustada corre-
tamente etc. Segundo Rocha e Baranauskas (2003), a falta de visibilidade é o que deixa muitos
dispositivos controlados por computadores tão difíceis de serem operados.
Um exemplo simples discutido por Norman (2006) é com relação à porta, um objeto co-
mum utilizado para entrar e sair dos estabelecimentos. Quantas vezes já empurrarmos uma por-
ta quando, na verdade, ela deveria ser puxada ou deslizada para alguma direção; ou tentamos
abri-la para a direita, quando deveria ser aberta para a esquerda?
Os projetistas deveriam prever essas possíveis dificuldades e evitá-las, criando sinais cla-
ros que indicassem como uma porta deveria ser aberta. Nesse caso, para indicar que a porta tem
de ser puxada, seria preciso, apenas, colocar a barra de puxar em um dos lados da porta e nada
do outro, uma vez que se não vemos, em uma porta, algo para puxar, naturalmente, tentamos
empurrá-la.
Segundo Rocha e Baranauskas (2003), os objetos que possuem um bom design são fáceis
de serem interpretados e entendidos, pois eles contêm "dicas" de como devem ser utilizados, já
os objetos com o design ruim são difíceis e frustrantes de serem usados e, na maioria das vezes,
possuem "dicas" falsas. Esse conceito está relacionado com a Affordance, que se preocupa com
as propriedades percebidas e propriedades reais de um objeto, ou seja, aquilo que eu vejo em
um objeto me auxilia e é utilizado realmente da maneira que eu imaginei?
Um objeto deveria determinar a maneira com que ele pode ser usado. Por exemplo, uma
cadeira é utilizada para sentarmos e, também, pode ser carregada. O vidro serve para dar trans-
parência e aparenta fragilidade. Botões são para girar, tesouras para cortar etc. Quando se pre-
ocupa com a affordance, o usuário sabe o que deve ser feito somente olhando, ou seja, não é
necessário apresentar figuras, rótulos ou instruções.
O próximo exemplo é de um objeto não muito comum atualmente, mas que foi um dos dis-
positivos de armazenamento mais usados, esse objeto é o disquete, ilustrado na Figura O disquete
não é um bom exemplo de visibilidade, pois quando você o vê pode encontrar dificuldade em sa-
ber como ele deve ser inserido no computador, mas é interessante perceber e discutir que, apesar
desse problema, o disquete foi desenvolvido para ser inserido de uma única maneira.
Isso é algo muito interessante, pois o disquete possui quatro lados, ou seja, a pessoa que
não conhece o disquete poderia inserir ele de qualquer lado; sem contarmos que a pessoa tam-
bém poderia colocar o disquete de "cabeça para baixo" somando, assim, quatro possibilidades,
ou seja, para quem não o conhece, teria oito possibilidades.
Agora, imagine inserir o disquete uma, duas ou três vezes e nada acontecer, com certeza,
uma pessoa leiga pensaria que o problema está no computador e não na maneira com que foi
colocado o disquete. Isso acontece, também, com os CDs, as pessoas inserem ele de maneira
errada, acham que o problema está no leitor de CD e levam-no para o conserto.
Assim, podemos pensar que, nessa parte da interação, o disquete foi bem planejado, pois
se há apenas uma forma de inserir o disquete para ele funcionar corretamente, para que per-
mitir que outras formas sejam possíveis? Então, se a pessoa tentasse colocar o disquete de
qualquer forma que não fosse a correta, ele não entraria no computador completamente, ou
seja, a pessoa já saberia que o problema não está no computador, mas sim na sua maneira de
inserir o disquete.
Figura 8 Disquete.
Esse exemplo ilustra que uma alternativa para ajudar as pessoas a usar um determinado
dispositivo e/ou sistema é permitir que elas percebam, facilmente, isto é, que fique visível para
elas, qual a maneira correta de utilizá-los.
Bom modelo conceitual

O bom modelo conceitual permite prever o que vai acontecer se realizarmos uma deter-
minada ação, ou seja, é possível perceber, naturalmente, o como fazer e o que vai acontecer
depois que algo for feito. Quando não há um bom modelo conceitual, as ações são feitas alea-
toriamente, sem saber se o resultado será satisfatório ou não, ou seja, enquanto tudo estiver
ocorrendo corretamente, não há problema, e, caso ocorra algum problema, as pessoas não
saberão o que fazer.
Um exemplo clássico é a tesoura. Mesmo que você nunca tenha visto uma, é fácil perce-
ber qual a sua função e como utilizá-la. Os "buracos" deixam claro que algo deve ser colocado
neles, e a única coisa lógica de se colocar e que pode se encaixar são os dedos. Os tamanhos
dos "buracos" proveem restrições que limitam quais dedos podem ser usados: o "buraco" maior
sugere diversos dedos e o menor apenas um. Entretanto, a operação não é limitada à colocação
dos dedos corretos, ou seja, a tesoura irá funcionar com qualquer dedo. Contudo, consegue-se
entender a tesoura e seu funcionamento porque suas partes são visíveis e as implicações são
claras.
Um segundo exemplo claro do bom modelo conceitual está relacionado com a tampa de
uma máquina de lavar, perceba a forma como ela deve ser aberta: há um puxador apenas de um
lado, o que, intuitivamente, faz você imaginar que é nesse lugar que a tampa deve ser puxada e,
naturalmente, o resultado da ação é percebido; e, a partir do momento em que ela está aberta,
não há dificuldade para fechá-la.
Bons Mapeamentos
Bons mapeamentos são aqueles naturais que aproveitam analogias físicas e padrões cul-
turais e, por isso, levam ao entendimento imediato. Por exemplo, o mapeamento em dirigir um

carro. Mesmo quem nunca dirigiu um sabe que o volante pode ser girado para a direita e para
a esquerda, porque outros movimentos não são possíveis. Quando qualquer movimento é re-
alizado o resultado é imediato, ou seja, se você virar o volante para a direita o carro irá para a
direita, o mesmo acontecerá para esquerda, por isso esse mapeamento é facilmente aprendido
e sempre lembrado.
O mapeamento pode ser utilizado por projetistas no desenvolvimento de sistemas; por
exemplo, para se mover um objeto para cima, move-se, também, o controle para cima, se for
preciso virar o objeto para algum lado, de forma semelhante será feito com o controle ou botão,
com isso fica mais fácil para a pessoa perceber qual ação ela está realizando.
Um exemplo ruim de mapeamento são os telefones coorporativos, que, geralmente, são
divididos em ramais. Imagine a seguinte situação: para você transferir uma ligação de um tele-
fone para outro é preciso discar *#9Perceba que nesta operação há vários problemas, pois não
se sabe o que esses números significam, o porquê de pressionar o * depois o # e assim suces-
sivamente. Se algum problema ocorrer, como ele deverá ser resolvido? Como saberemos se a
operação está sendo feita de maneira bem sucedida ou não?
Feedback
Feedback é a resposta que o usuário recebe do sistema depois que alguma ação foi rea-
lizada. Esse conceito assemelha-se ao feedback que recebemos ao escrevermos com um lápis
em um papel, pois podemos ver o que está acontecendo naquele exato momento, assim como
acontece, também, ao ouvirmos a voz da outra pessoa enquanto conversamos com ela, porque,
dessa forma, ela nos informa se está compreendendo ou não a conversa.
Contudo, há sistemas que, simplesmente, não exibem feedbacks, deixando as pessoas
perdidas, sem saber se uma determinada ação foi realizada ou não com sucesso. Como exemplo
disso, temos o caso das impressoras coorporativas, em que, muitas vezes, um funcionário soli-
cita a impressão de uma determinada sala, mas a impressora está em outra sala, ou seja, não
é possível saber se a impressão foi concluída, se houve algum problema, se há papel suficiente
etc. Um outro problema muito comum nas impressoras é quando pedimos para cancelar a im-
pressão e o feedback não é imediato, ou seja, apenas depois de alguns minutos de solicitação
do cancelamento é que a impressão é, realmente, cancelada.
O exemplo de uma interface está ilustrado na Figura Essa figura apresenta vários proble-
mas que não podem ocorrer em sistemas. Nessa interface, há sete botões e o primeiro proble-
ma está relacionado ao formato desses botões, pois, como você pode perceber, não há padro-
nização.
Os três botões da parte de baixo (Ok, Apply e Cancel) possuem um formato comum, mas
os quatros localizados ao lado direito não possuem aparência de botões. Lembre-se de que se
deve ter um padrão do início ao fim, já que seguir um mesmo formato para todos os botões faz
com que as pessoas percebam facilmente quando é um botão ou não.
Outro problema é que, inicialmente, deve ser inserido um texto no campo (caminho do
arquivo) antes de se pressionar qualquer um dos botões que se encontram ao lado. Caso esses
botões sejam pressionados antes de se inserir qualquer texto, não haverá nenhum feedback,
ou seja, a pessoa terá a certeza de que esses dois símbolos não são botões, tanto pelo formato
quanto por não terem exibido nenhum feedback ao serem pressionados. O não feedback, nesse
caso, é um grande problema, pois em nenhum momento o usuário é informado de que deve ser
inserido um texto no campo antes de pressionar os botões ao lado.
Fonte: ROCHA ; BARANAUSKAS, 2003, p. 65.

Figura 9 Parte da interface do software Time & Chãos.
Uma possível solução para esse caso é fazer com que essas duplas de botões fiquem no
formato de botão "padrão", porém desativados, assim, a pessoa entenderá que são botões que,
por enquanto, não devem ser utilizados e, somente quando algum texto for inserido em um dos
campos, os botões correspondentes ficarão ativados.
A maneira de exibir o feedback também é um assunto complexo, pois não adianta exibir
a mensagem "você realizou uma operação ilegal", que as pessoas vão se assustar e pensar que
fizeram algo muito errado ou, até, que fizeram algo fora da lei. Então, qual é a melhor forma de
exibir um feedback? O feedback deve ser sucinto e mostrar que algo foi realizado com suces-
so ou informar qual foi o erro e em que local aconteceu, apresentando, também, a forma de
solucioná-lo.
Apenas para aumentar a complexidade, podemos dizer que, dependendo do nível de co-
nhecimento do usuário no sistema, o feedback pode ser diferente, uma vez que para o usuário
experiente é necessário apenas falar qual é o problema, e para o usuário iniciante é necessário
informar o erro, em que lugar ele está e como solucioná-lo.
8. CULTURA
Outro fator que deve ser levado em consideração, para compreender a forma como as
pessoas pensam, agem e interagem, é a cultura. A cultura representa uma rede de significados
que dão sentido ao mundo que cerca o individuo, ou seja, a cultura é tudo aquilo que uma de-
terminada pessoa aprendeu por meio de leitura, arte, história, música, experiência, enfim, todas
as coisas que ela teve acesso durante a sua vida influenciaram, diretamente, na formação da sua
cultura.
Segundo Ramalho (2005), a cultura possui um papel significativo na vida social do indiví-
duo, pois ela está contida em cada gesto, atitude e pensamento, tornando-se elemento-chave
no modo como o cotidiano é configurado e modificado por cada um. Assim, a cultura deve ser
vista como algo fundamental, que determina a forma, o caráter e a vida do indivíduo.
Portanto, considerar a experiência, a linguagem, as crenças e os valores dos indivíduos no
desenvolvimento de sistemas, sejam eles para os negócios e/ou entretenimento e/ou educação,
é considerar a cultura desses indivíduos, de modo a permiti-los maior identificação e, conse-
quentemente, maior interesse e facilidade na interação com o computador.

A utilização da cultura para permitir que as pessoas se identifiquem e se sintam mais enga-
jadas para aprender ou interagir já foi investigada por alguns pesquisadores, dentre eles, Paulo
Freire, que identificou que, na educação, quando o professor elabora atividades considerando
o contexto social e a cultura dos alunos, eles percebem que há uma relação entre o que estão
aprendendo e a realidade e, com isso, sentem-se mais interessados por essas atividades. De
maneira semelhante, podemos compreender que quando utilizamos a cultura das pessoas no
desenvolvimento de sistemas permitimos que elas estejam de acordo com o que é comum para
elas, ou seja, que os sistemas sejam familiares e mais fáceis de serem utilizados.
Uma maneira melhor de entender a importância da cultura no desenvolvimento de siste-
mas é comparar a interação humano-computador com a interação humano-humano. Observe
que quando conhecemos uma pessoa e temos certa intimidade com ela, a interação se torna
algo natural, amigável e simples, muito diferente de quando conversarmos com uma pessoa que
não conhecemos, nesse caso, nos preocupamos com a forma com que temos de falar e a inte-
ração não será tão amigável. A mesma coisa acontece com sistemas computacionais. Quando
interagimos e percebemos que na interface há algumas características conhecidas, que fazem
parte da nossa cultura, a interação torna-se mais amigável do que quando interagimos com um
sistema que possui linguagem e aspectos bem diferentes daqueles com que estamos acostuma-
do.
Um exemplo interessante que expressa a utilização da cultura na interface é com relação
a um sinal que simboliza a seleção. Em algumas culturas, o sinal do X representa que uma opção
foi selecionada, ou seja, por meio do X você seleciona as opções que concorda ou que quer man-
ter, no entanto, em outra cultura, como no Japão, por exemplo, o X representa a exclusão, assim,
os japoneses apenas colocam X nas opções que querem remover. Com base nesse exemplo, já
é possível perceber a dificuldade que os japoneses tiveram em interagir com sistemas que uti-
lizam o X para selecionar algo, por isso esse sinal teve de ser substituído pelo V (sinal de visto),
que, para eles, representa a seleção (ROCHA; BARANAUSKAS, 2003).
Muitos outros aspectos da cultura podem ser citados. Um outro exemplo está relacionado
à sequência da leitura. Em alguns países, como no Brasil, as pessoas leem de cima para baixo e
da esquerda para a direita, ou seja, tudo aquilo que é importante ser destacado ou as opções
dos sistemas, tendem a ser mais à esquerda superior. No entanto, há outros países em que a
sequência de leitura é bem diferente, de forma que o que se quer destacar não deverá ficar no
mesmo local que ficaria na cultura do Brasil.
A cor também é algo que se difere entre as culturas. Aqui no ocidente, por exemplo, esta-
mos acostumados com as cores claras em casamentos, especialmente o branco para as noivas,
como você pode observar na Figura 10(a), assim, quando vamos desenvolver um sistema ou
uma página web para casamentos, tendemos a utilizar tons claros, que representam a pureza, a
delicadeza, entre todas as outras características. Contudo, para alguns lugares do oriente a cor
branca representa a tristeza, ou seja, já não é mais uma cor adequada para desenvolver páginas
web para casamentos. Os orientais preferem as cores fortes para esta ocasião, como o verme-
lho, por exemplo, conforme demonstrado na Figura 10 (b). Consequentemente, as páginas web,
para esee tema tendem a ser, na cultura oriental, nas tonalidades fortes.
Observe, a seguir, as Figuras 10 (a) e 10 (b):
Figura 10 (a) Vestido de noiva do ocidente. Figura 10 (b) Vestido de

noiva do oriente.
Perceba que foram descritos alguns exemplos mostrando a diferença cultural entre os
países, mas, aqui no Brasil, dependendo do estado, da região, e, às vezes, até de cidade, a forma
de falar, os gostos etc. são bem diferentes. Respeitar essas características para desenvolver sis-
temas, é respeitar a cultura e, consequentemente, a forma natural com que as pessoas veem as
coisas e interagem com o mundo.
9. A MULTIDISCIPLINARIDADE DE IHC
Você deve ter observado, durante a sua leitura até aqui, que a área de IHC não envolve
somente a computação, mas, sim, várias áreas, afinal, não estamos discutindo, por enquanto,
de programação, da capacidade do computador para rodar o sistema, entre outras caracterís-
ticas que estão diretamente ligadas à tecnologia. A nossa preocupação está relacionada com
as pessoas e com a forma como elas utilizarão o sistema. Todos os esforços estão direcionados
em entender como as pessoas compreendem o mundo ao seu redor para que os sistemas com-
putacionais possam aproveitar esse mapeamento natural, permitindo uma melhor interação
humano-computador.
Portanto, compreender que esta área vai muito além da computação é fundamental, pois,
assim, no próximo programa que você planejar, desenvolver, implementar e/ou avaliar, se pre-
ocupará em ler e em entender os assuntos relacionados à computação, pois, sem eles, não há
como desenvolver sistemas, mas, também, compreenderá que conhecer, ler ou pedir ajuda de
profissionais de outras áreas é importante.
A Figura 11, disposta a seguir, ilustra as várias áreas ligadas à IHC. Cada uma delas contri-
bui significativamente na compreensão dos fatores humanos, no mapeamento natural (do dia a
dia das pessoas) para o mapeamento computacional, assim como todas as outras características
necessárias para que o sistema seja desenvolvido de modo que as pessoas possam utilizá-lo da
melhor forma possível. A valorização de cada área em IHC é chamada de multidisciplinarida-
de, pois esta palavra representa que a IHC não está apenas envolvida com a computação, mas
com várias outras áreas. Vale ressaltar que a Figura 11 ilustra apenas algumas das áreas, pois,

dependendo do sistema que for desenvolver, você terá de investigar outras áreas. Por exemplo,
para desenvolver um sistema médico, será necessário conhecer a área da medicina, ou seja, há
a necessidade de conhecer a área que faz parte do contexto do sistema, por isso há no gráfico
uma área para o Contexto do Sistema.
Fonte: Adaptado de ROCHA; BARANAUSKAS, 2003, p. 20.

Figura 11 Áreas que contribuem em IHC
10. QUESTÕES AUTOAVALIATIVAS

Sugerimos que você procure responder, discutir e comentar as questões a seguir, que tra-
tam da temática desenvolvida nesta unidade, ou seja, da possibilidade do ensino da Interface
Humano-Computador.
A autoavaliação pode ser uma ferramenta importante para testar o seu desempenho. Se
você encontrar dificuldades em responder a essas questões, procure revisar os conteúdos estuda-
dos para sanar as suas dúvidas. Este é o momento ideal para que você faça uma revisão desta uni-
dade. Lembre-se de que, na Educação a Distância, a construção do conhecimento ocorre de forma
cooperativa e colaborativa; compartilhe, portanto, as suas descobertas com os seus colegas.
Confira, a seguir, as questões propostas para verificar o seu desempenho no estudo desta
unidade:
1) Imagine a seguinte situação: uma empresa contratou você para participar do desenvolvimento de um novo dis-
positivo de armazenamento, que teria uma capacidade superior a mil DVDs e cujo tamanho seria menor do que
o de uma moeda de um real. Todavia, ainda não há um formato adequado para a inserção desse dispositivo no
computador, e a preocupação maior da empresa é com as pessoas, ou seja, os usuários – se estes conseguirão
entender a forma com que esse dispositivo deve ser conectado. A princípio, em que você pensaria, consideran-
do os conceitos aprendidos nesta unidade?
a) Em construir um formato semelhante ao de um CD, com a parte superior diferenciada da parte inferior. A
parte superior seria brilhosa; assim, o usuário saberia de que forma inseri-lo no computador.
b) Em diferenciar a forma de inserir tal dispositivo no computador por meio das cores: a parte que deve ser
inserida em primeiro lugar seria a verde, e a outra parte, vermelha.
c) Em desenvolver um dispositivo que tivesse apenas um meio de se conectar com o computador, pois, assim,
não haveria alternativa de uso, e, logo, não haveria possibilidade de erro.
d) Em colocar algumas instruções na parte superior do dispositivo. Assim, o usuário saberia como inseri-lo no
computador e, também, o objetivo do dispositivo.
e) Em diferenciar as partes superior e inferior do dispositivo por meio da textura: a parte superior seria áspe-
ra, e a parte inferior seria lisa; assim, apenas com o toque, o usuário saberia como inserir o dispositivo no
computador.
2) Imagine a seguinte situação: você foi contratado para integrar um grupo de desenvolvedores que tem como
objetivo criar um sistema na área da medicina. Esse sistema teria de ser capaz de simular todas as funções do
coração, bem como simular qualquer tipo de alteração no batimento, na aparência, entre outras características
do coração, dependendo da doença que fosse inserida no sistema.
Por exemplo, o usuário iria inserir uma doença no sistema, e o coração virtual teria de apresentar todos os sinto-
mas e as características decorrentes dessa doença. Considerando os conceitos aprendidos nesta unidade, o que
você faria ou sugeriria para o grupo?
I– Buscar parcerias na área médica, com pessoas que conheçam e que sejam especialistas na área cardíaca, para
conversar e acompanhar todo o desenvolvimento, bem como participar dos testes do software.
II – Pesquisar programas computacionais similares para saber quais são as funcionalidades existentes, como
é a interface, quais são os pontos positivos e os negativos, entre outros fatores que podem influenciar a
forma de interação humano-computador.
III – Separar o grupo em vários subgrupos, e cada subgrupo deveria estudar uma parte do coração, sua aparên-
cia e como é sua reação depois de adquirir uma determinada doença. Após o estudo, todos os subgrupos
se reuniriam e discutiriam sobre o que aprenderam e, assim, desenvolveriam o sistema.
a) A alternativa correta é I.
b) A alternativa correta é II.
c) As alternativas corretas são II e III.
d) As alternativas corretas são I e II.
e) As alternativas corretas são I, II e III.
Gabarito
Confira, a seguir, as respostas corretas para as questões autoavaliativas propostas:
1) c.
2) d.
11. CONSIDERAÇÕES
Chegamos ao final desta primeira unidade. Esperamos que você tenha compreendido a
importância da IHC no desenvolvimento de sistemas e como alguns dos conceitos existentes
nessa área ajudam você a perceber a importância de valorizar as pessoas, afinal, quando vamos
desenvolver algo para que será utilizado por um indivíduo, não há nada mais importante do que
o compreender para que o sistema seja aceitável e útil para ele.
Na IHC, percebemos que as pessoas não devem alterar a sua maneira de pensar e realizar
uma determinada atividade ou quando estiverem utilizando uma tecnologia, mas, sim, ao con-
trário, a tecnologia deve se adaptar às pessoas de acordo com as suas necessidades e caracterís-
ticas, por isso, a importância de conhecer os fatores humanos. Conhecer tais fatores, possibilita
uma maior chance de se desenvolver um sistema com a visibilidade adequada e compreensiva,
respeitando o modelo conceitual do usuário, uma vez que houve o mapeamento do natural para
o virtual, bem como, tendo em vista estes princípios será mais fácil pensar em feedbacks que
estejam de acordo à realidade do usuário.

Entender os conceitos e aplicá-los na prática não é uma tarefa trivial, porém, no decorrer
deste Caderno de Referência de Conteúdo, você conhecerá outros conceitos e estratégias que
o ajudarão a conhecer as pessoas para quem o sistema será desenvolvido, bem como algumas
técnicas que o auxiliarão no desenvolvimento da interface do sistema.
12. EͳREFERÊNCIAS
ACM SIGCHI. Curricula for human-computer interaction chapter 2: human-computer interaction, 19Disponível em: <http://
www.acm.org/sigchi/cdg/cdg2.html>. Acesso em: 10 dez. 20
GADOTTI, M. Perspectivas atuais da educação. São Paulo: Perspectiva, v. 14, nº 2 São Paulo - abr./jun. 20Disponível em: <http://
www.scielo.br/scielo.php?script=sci_arttext&pid=S0102-88392000000200002&lng=en&nrm=iso>. Acesso em: 05 jan. 20
MINHA VIDA. Ultra-som revela muito mais do que o sexo do bebê. Disponível em: <http://www.minhavida.com.br/conteudo/2242-
Ultrasom-revela-muito-mais-do-que-o-sexo-do-bebe.htm>. Acesso em: 24 fev. 2010.
Lista de figuras
Figura 1 – Foto meramente ilustrativa: disponível em: <http://img.alibaba.com/photo/217871296/Car_Radio_with_USB_SD_
MMC_port.jpg>. Acesso em: 24 fev. 2010.
Figura 4 – Ultra-Som 3D: disponível em: <http://www.e-milynet.com/phpbb/album_pic.php?pic_id=241>. Acesso em: 24 fev.
2010.
Figura 5 – Re-Mission: disponível em: <http://www.re-mission.net/site/game/index.php>. Acesso em: 24 fev. 2010.
Figura 6 – The Sims: disponível em: <http://www.thesims3.com/game/screenshots>. Acesso em: 24 fev. 2010.
Figura 7(a) – Máquina de lavar: disponível em: <http://user.img.todaoferta.uol.com.br/
R/Q/EM/PY3WI5/1244433346169_bigPhoto_0.jpg>. Acesso em: 24 fev. 2010.
Figura 7(b) – Celular: disponível em: <http://www.blogzinho.com/img_post
orkut%20celular_www.BloGZinho.com.jpg>. Acesso em: 24 fev. 2010.
Figura 8 – Disquete: disponível em: <http://colunistas.ig.com.br/curioso/files/2009/05/
disquete.jpg>. Acesso em: 24 fev. 2010.
Figura 10 (a) – Vestido de noiva do ocidente: disponível em: <http://images01.olx.pt/ui/1/43/63/14724063_1.jpg>. Acesso em:
24 fev. 2010.
Figura 10 (b) – Vestido de noiva do oriente: disponível em: <http://img.alibaba.com/photo/ 247582846/Chinese_Traditional_
Wedding_Dress_F08122301.jpg>. Acesso em: 24 fev. 2010.
13. REFERÊNCIAS BIBLIOGRÁFICAS

BEALE, I. L. et al. Improvement in cancer-related knowledge following use of a psychoeducational video game for adolescents
and young adults with cancer. In: Journal of Adolescent Health, v. 41, p. 263-270, 2007.
CARROL, J. M.; OLSON, J.M. Interface Metaphors and User Interface Design. In: HELANDER, M. Handbook of human-computer
interaction. Amsterdam:North Holland, 1998.
JOHNSON LAIRD P. N. Mental Models. In: POSNER, M. I. Foun Dations of Cognitive Science. Cambridge, Massachusetts: MIT
Press, 1989.
NIELSEN, J. Projetando Websites. Rio de Janeiro: Campus, 2000.
NORMAN, D. A. O Design do Dia a Dia. Rio de Janeiro: Rocco, 2006.
RAMALHO, B. L. Educação como exercício de diversidade. Brasília: UNESCO, 2005.
ROCHA, H. V.; BARANAUSKAS, M. C. C. Design e avaliação de interfaces humano-computador. Campinas: NIED/UNICAMP,
2003.
SILVA, M. A. R. O uso de Senso Comum no apoio a jogos narrativos para crianças em idade escolar. Dissertação de Mestrado,
Programa de Pós-Graduação em Ciência da Computação, Universidade Federal de São Carlos, 2009.
EAD
Breve Histórico Sobre IHC e
Interfaces Avançadas
1. OBJETIVOS
• Conhecer a história da Interação Humano-Computador (IHC).
• Conhecer e entender os novos tipos de IHC.
2. CONTEÚDOS
• Fases da História do Computador.
• Interfaces Avançadas.

Antes de iniciar o estudo desta unidade, é importante que você leia as orientações a se-
guir:
1) Pesquise em sites confiáveis a história do computador e a influência que o aprimora-
mento da interface teve e tem para permitir aos usuários utilizarem o computador e,
de alguma forma, compreendê-lo.
2) Lembre-se de que a maior vantagem de se utilizar o computador é devida à sua capa-
cidade de facilitar e de agilizar as tarefas do cotidiano, do trabalho, do lazer dos usuá-
rios etc.; por isso, nada mais justo do que pensar neles para que toda essa capacidade
possa ser utilizada de maneira intuitiva e sem complicações.
3) Fundamentado no conteúdo "Interfaces Avançadas", que será abordado nesta unida-
de, imagine qual e como será a interface com que iremos nos deparar em um futuro
próximo. Amplie seus conhecimentos! Consulte livros e sites para obter mais informa-
ções sobre esse tipo de interface e suas características.
© Interface Humano-Computador
36
4) No transcorrer desta unidade, você estudará os tipos de interface, mas, para que com-
preenda melhor esse assunto, será necessário que, antes, tente refletir sobre algumas
questões:
• Qual é o tipo de interface que você mais gostou?
• Você já teve uma experiência com algumas das interfaces avançadas?
• Qual é a sua experiência com a interface da terceira fase?
• Você gosta da forma que a interface é atualmente?
5) Para respondê-las, você poderá usar de sua experiência. Lembre-se de que o hábito
da pesquisa e do questionamento deve ser cultivado e adquirido por você, que optou
por fazer um curso na modalidade a distância.
Na primeira unidade você estudou a importância de entender os fatores humanos para
desenvolver sistemas computacionais que consideram as características, as facilidades e as difi-
culdades das pessoas. Você também pôde observar que não é apenas a interface que influencia
na interação humano-computador, apesar de ser a mais lembrada, por justa causa, também há
a necessidade de se preocupar com todos os dispositivos que estão entre as pessoas e a tecno-
logia.
Nesta unidade, você conhecerá o segundo passo para compreender a importância da IHC
e, também, como esta área influenciou na popularização do computador. Neste passo, você terá
a oportunidade de estudar um pouco mais sobre a história do computador, porém de uma ou-
tra forma. É muito comum apresentar essa história, enfatizando o tamanho do computador no
início e a sua redução significativa para os dias de hoje, como também a evolução da velocidade,
da capacidade de processamento e de armazenamento. No entanto, nesta unidade, a ênfase é
na evolução do computador sobre a ótica da IHC, ou seja, como foi a evolução na interface, nos
dispositivos, entre outras características que estão diretamente relacionadas com a Interação
Humano-Computador.
Vale ressaltar que a popularização do computador não aconteceu apenas devido a uma
melhor interação com a máquina ou somente por causa da redução dos custos e do tamanho,
pois não haveria tantos computadores se ainda continuassem sendo do tamanho de uma sala
ou se fossem tão complexos que somente pessoas especializadas pudessem utilizá-los.
Outro aspecto importante é entender como foi a evolução da IHC, afinal, compreender o
que aconteceu, os exemplos de sucessos e de fracassos e como tudo foi aplicado é o ponto ini-
cial para refletirmos sobre o futuro dessa área, sobre o que podemos esperar e, especialmente,
para não repetirmos "os erros", mas, sim, aprendermos com eles e aproveitarmos o que deu
certo.
5. PRIMEIRA FASE
A primeira fase da história do computador é considerada por muitos pesquisadores como
a fase em que não existia a interface entre o usuário e o computador pois, qualquer interação
era feita de um modo pouco amigável e diretamente no hardware. A Figura 1, apresentada a
seguir, ilustra um dos primeiros computadores.
© U2 – Breve Histórico Sobre IHC e Interfaces Avançadas 37
Figura 1 ENIAC.
Os computadores dessa época eram usados, basicamente, para cálculos, e a interação

era por meio de movimentos de cabos e chaves. As únicas maneiras de ter alguma resposta dos
computadores eram a leitura de luzes que piscavam e os cartões perfurados. Observe que, de-
vido a essa dificuldade, somente os próprios inventores utilizavam tais máquinas, afinal, toda a
complexidade existente era difícil de ser entendida por outras pessoas não especialistas na área
(VAN DAM, 1997).
O feedback, nessa época, também era um fator negativo, pois além de compreender o
porquê das luzes e dos cartões perfurados, o resultado era obtido após algumas horas ou, de-
pendendo da complexidade do cálculo, após alguns dias.
Agora, imagine a dificuldade encontrada na época para resolver um problema atual e co-
mum, por exemplo, na programação. Imagine que você deva fazer um determinado código e
verificar se ele é compilado (executado sem erro) ou não. Antigamente, era preciso utilizar o
cartão perfurado, como demonstra a Figura 2, para inserir o código e, depois, inserir no compu-
tador. Após algumas horas, você receberia o feedback se o programa foi compilado com sucesso
ou não. Dessa forma, se você esquecesse uma "," no código, só saberia depois de algumas horas
e somente após a resposta você poderia corrigir e inserir novamente o cartão para saber se
houve outro tipo de erro ou se o código estava correto. Ou seja, para realizar qualquer tipo de
operação demorava-se dias.

38
Figura 2 Cartão Perfurado.
Além da interação complexa, o tamanho do computador também não ajudava, o ENIAC

pesava 30 toneladas, media 5,50 m de altura, possuía 25 m de comprimento e ocupava 180m2,
por isso era necessária uma sala inteira somente para ficar o computador. Além disso, devido ao
tamanho e à quantidade de válvulas, o computador esquentava muito, o que dificultava ainda
mais a interação e a permanência das pessoas na sala em que ele estava.
Curiosidade:––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Você sabe por que quando ocorre algum erro no computador as pessoas dizem que houve um bug? Essa expressão
surgiu na época do ENIAC, pois, devido às luzes e ao calor das válvulas, os insetos eram atraídos e, dependendo
da maneira que eles entravam na máquina, ocorria um erro, o qual os pesquisadores já sabiam que, possivelmente,
teria sido causado por um inseto, em inglês, bug. Então, atualmente, quando falamos bug, também é no sentido de
defeito, mas bem diferente dos defeitos de antigamente, afinal, hoje em dia, raramente eles ocorrem por causa de
um inseto.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
6. SEGUNDA FASE
A segunda fase é marcada pelos primeiros monitores surgidos no mercado, que, mesmo
sendo monocromáticos, como representado na Figura 3, já facilitavam a interface com o usu-
ário. Além do monitor, outros hardwares surgiram, como, por exemplo, o teclado. Esses novos
equipamentos para interagir com os computadores e os seus tamanhos e custos reduzidos, con-
tribuíram para que eles fossem utilizados por outras pessoas e não somente por cientistas. A
utilização, porém, não era tão simples, pois a interação acontecia por meio de um prompt de
comando, com entradas de comando via teclado e visualização de dados no monitor por ca-
racteres alfanuméricos, ou seja, para este modelo de interação havia a necessidade de saber
comandos textuais utilizando um vocabulário especializado (VAN DAM, 1997).
Para o usuário, essa fase representou um grande avanço, pois não era preciso mais aguar-
dar horas ou dias para saber se um determinando código ou comando seria executado ou não,
pois ele passou a ter a resposta em alguns minutos, e, tão logo a resposta era obtida, ele já podia
fazer as alterações necessárias. Apesar dessa interação mais rápida, a forma de utilizar o compu-
tador não era fácil, pois o usuário precisava decorar vários comandos para executar uma simples
tarefa. Os comandos também não eram memorizados com facilidade, devido à sua quantidade
e complexidade.
Nessa fase, também surgiram os sistemas operacionais, como, por exemplo, o DOS (Disk Ope-
rating System ou Sistema Operacional em Disco), que possuía uma interface de linha de comandos
por meio de seu interpretador de comandos, command.com. Ressalta-se que, apesar dos avanços
na interface, ainda há vestígios dessa fase atualmente, especialmente em ambiente UNIX.
Figura 3 Monitor Monocromático.
7. TERCEIRA FASE
Foi na terceira fase que o computador se popularizou, pois as pessoas puderam comprar o
seu próprio computador. A chamada "era do computador pessoal" permitiu às pessoas adquiri-
rem seus computadores devido à redução de preços e à facilidade de uso.
Nessa fase, surgiram as interfaces WIMP GUI (Window, Icons, Menus, Pointing Devices –
Graphical User Interface), ou seja, interfaces gráficas com janelas, ícones, menus etc., conforme
demonstrado na Figura Uma interface semelhante à que temos hoje, entretanto, com poucos
recursos e não tão bonita. Além das interfaces gráficas, nessa fase surgiram os monitores colori-
dos e um dispositivo apontador para a interação com os botões, os ícones e os menus, chamado
mouse (ASSIS; SILVA, 2000).
Com esses recursos, os computadores tornaram-se ambientes mais familiares, permitindo
um relacionamento usuário-computador mais agradável, e, por esse motivo, ganharam espaço
no mercado. Além de ser uma ferramenta de trabalho, os computadores passaram a ser, tam-
bém, ferramentas que possibilitam a diversão e estudo.
É possível perceber que, nessa fase, houve uma preocupação em permitir ao usuário in-
teragir com o computador de forma semelhante com a que ele interagia em seu ambiente de
trabalho. Observe na Figura 5 que as opções existentes, mesmo atualmente, são semelhantes às
existentes em um escritório. Por exemplo, a área do computador, é chamada área de trabalho,
semelhante ao nome que utilizamos em um ambiente real.
40
Figura 4 Interface Gráfica.
Figura 5 Área de trabalho do computador Microsoft© Windows.

Na área de trabalho real, há, por exemplo, uma lixeira, que serve para descartarmos os
documentos ou qualquer outro tipo de objeto que não queremos mais, as pastas utilizadas para
organizarmos os nossos documentos, as nossas fotos etc., e há, também, um relógio. Esses obje-
tos foram aproveitados na área de trabalho virtual, por isso, no computador, há pastas, lixeiras,
entre tantos outros recursos semelhantes ao que estamos habituados a utilizar no mundo real.
Ao utilizarmos objetos e algumas ações presentes no nosso cotidiano, surgiu, no computa-
dor, um conceito muito discutido e importante atualmente, as metáforas de interface. Segundo
Rocha e Baranauskas (2003), as metáforas são partes integrantes de nosso pensamento e da
nossa linguagem. Elas fazem parte da nossa linguagem cotidiana, como, por exemplo: gastar
dinheiro, trânsito engarrafado etc. As metáforas nos permitem usar o conhecimento familiar de
objetos concretos e experiências para dar estrutura a conceitos mais abstratos.
Algo semelhante ao que ocorre em nossa linguagem, ocorre, também, com o computador.
Quando utilizamos as funções recortar, copiar e colar, por exemplo, conforme a Figura 6, esta-
mos utilizando um raciocínio semelhante ao real e natural. Observe que, ao clicar em recortar,
significa que você quer tirar algo de determinado lugar e colocar em outro; já copiar, você utiliza
para manter uma informação em dois ou mais lugares; e, colar, serve para você fixar (pregar)
algo em um determinado local.
Figura 6 Funções Recortar, Copiar e

Colar do Microsoft© Word 2003.
Como você pôde observar, essa fase, que ocorreu há alguns anos, ainda continua nos dias
de hoje, com as metáforas parecidas e alguns hardwares semelhantes, como, por exemplo, o
teclado e o mouse. Vale ressaltar, porém, que esses dispositivos evoluíram e ficaram mais ergo-
nômicos, confiáveis e precisos, como você pode ver na Figura No entanto, suas formas de inte-
ração e de uso permaneceram inalteradas em relação aos primeiros modelos de 20 anos atrás.
Figura 7 Nova aparência dos antigos dispositivos para interagir com o computador.

42
Apesar de todos esses fatores positivos, essa fase teve algumas críticas, relacionadas ao
tempo que o usuário gastava para realizar uma determinada tarefa, perdendo, muitas vezes, o
foco durante a sua execução, por causa das várias opções gráficas. Surgiu, também, a idéia de
bibliotecas padronizadas e de desenvolvimento automático de interfaces, cujo resultado, na
maioria das vezes, possui uma qualidade questionável.
Após essa fase, várias pesquisas foram feitas com o objetivo de permitir às pessoas inte-
ragirem com o computador, não somente com o teclado, o mouse, o monitor etc. Essas novas
formas de interação serão estudadas a seguir, como interfaces avançadas.
8. INTERFACES AVANÇADAS
As interfaces avançadas permitem ao ser humano interagir com o computador de uma
maneira diferente, ou seja, sem o uso do mouse, do teclado e de outros dispositivos que estão
em uso há alguns anos. Essas interfaces têm como objetivo possibilitar que a interação humano-
-computador seja mais natural, ao ponto das interfaces "deixarem de existir", uma vez que se
tornam tão naturais que os usuários nem as percebem.
A primeira interface a ser descrita e estudada é a utilização da realidade virtual, sua fun-
ção é possibilitar que as pessoas interajam com o computador por meio de todos os sentidos,
utilizando os mais diferentes recursos de hardware e software.
9. REALIDADE VIRTUAL
A realidade virtual é uma nova interface que pretende fazer com que as pessoas interajam
com o computador usando todos os seus sentidos, afinal, antes do ENIAC, as pessoas utilizavam
interfaces naturais para interagir com o mundo, pois não era necessário interagir com as máqui-
nas, apertar botões etc. (KIRNER; SISCOUTTO, 2008Ή.
A Realidade Virtual (RV) é uma "interface avançada do usuário" para acessar aplicações
executadas no computador, pois por meio de alguns equipamentos especiais, tais como capa-
cete, luva, óculos estereoscópicos, mouses 3D etc., o usuário é "transportado" para dentro da
aplicação em que realiza suas interações. Em outras palavras, ele se sente imerso na aplicação
porque, tudo o que acontece nela, ele consegue ver, e todos os movimentos são reproduzidos
na aplicação como se fossem reais.
Essa capacidade do computador de detectar e de reagir às ações do usuário, promovendo
alterações visíveis na aplicação, são aspectos importantes para a interação entre o usuário e o
ambiente virtual. Quando o usuário vê a interface sendo alterada de acordo com os seus movi-
mentos, a interação torna-se mais rica e natural, gerando mais engajamento e eficiência.
O desenvolvimento dessas tecnologias permite grandes avanços em muitas áreas, dentre
elas, a medicina, que, por meio da realidade virtual, chega a lugares de difícil acesso. Como
exemplo disso, a Figura 8 ilustra essa tecnologia sendo utilizada para realizar uma cirurgia a
distância.
Fonte: CARDOSO; LAMOUNIER, 2008, p. 349.

Figura 8 Manipulação de um equipamento com RV.
Como você poderá observar na Figura 9, os movimentos realizados pelo médico, por meio
de uma máquina, são reproduzidos por um robô em um paciente que está a quilômetros de
distância. Observe que esse equipamento com RV possui uma característica semelhante aos
controles remotos de muitos videogames atuais, em que os movimentos feitos com eles são
reproduzidos na TV, porém, logicamente, o equipamento utilizado na medicina possui um grau
de precisão maior, como também um grau de confiabilidade elevado.
O intuito do desenvolvimento dessa tecnologia na área da medicina é permitir, por exem-
plo, que um médico possa "estar" lugares de risco, podendo, por exemplo, operar um soldado
que está em um campo de batalha. Outra possibilidade discutida por muitos pesquisadores é
permitir que os alunos de medicina possam realizar suas cirurgias com os robôs para aprende-
rem, em um primeiro momento, a explorar o corpo humano, entendendo-o. Vale ressaltar que,
para este último exemplo, não é necessário que haja uma pessoa, isto é, um paciente, do outro
lado da máquina, de forma que o ato da operação pode ser apenas uma simulação do real.
Fonte: CARDOSO; LAMOUNIER, 2008, p. 348.

Figura 9 Controle de cirurgia/robô com técnicas de RV

44
Apesar das vantagens da RV, alguns problemas fizeram com que essa tecnologia não fosse
tão popularizada, dentre eles está o alto valor dos equipamentos necessários para a sua utiliza-
ção. Ademais, a utilização de todos os equipamentos, muitas vezes, gerava desconforto, agrega-
do ao fato de que eram difíceis de aprender, precisando de treinamento para essa tarefa.
10. INTERFACES TANGÍVEIS

O objetivo das interfaces tangíveis é dar forma física à informação digital, ou seja, permitir
que o usuário manipule a informação digital com suas mãos e que ela seja perceptível aos seus
sentidos. Por exemplo, você já assistiu ao filme de ficção científica Minority Report, de Steven
Sipelberg? (Figura 10).
Figura 10 Imagens do filme Minority report.
Esse filme exemplifica a utilização de uma interface tangível em que as informações são
acessadas no ar e com gestos intuitivos; a navegação pelo conteúdo é realizada de forma na-
tural. Observe que a informação é representada como algo real no ar e é possível manipulá-la
como se fosse um objeto, sendo assim, a tecnologia é "palpável" ou "tocável", garantido uma
interação muito mais realista entre homem e computador.
11. WEARABEL COMPUTING

A Wearabel Computing é uma tecnologia "usável" bem diferente do que estamos acostu-
mados a ver e utilizar. A ideia se distingue das demais, pois o comum é vermos as tecnologias
fixas em um determinado local, como, por exemplo, em cima de uma mesa e ligada a algum
dispositivo eletrônico como computadores, monitores, celulares etc. Essa tecnologia "usável"
altera o mito de como o computador ou qualquer outra tecnologia deve ser usada. Nesse caso,
uma pessoa pode vestir a tecnologia por meio de uma roupa ou de óculos e utilizá-la da melhor
forma, dependendo do contexto e da situação (MIT, 2010).
A Figura 11 ilustra um projeto desenvolvido pela Apple para se obter, sobre qualquer tipo
de roupa, o controle de um som, ou seja, a pessoa, literalmente, veste o dispositivo ou o contro-
le e tem acesso rápido e fácil às suas funcionalidades.
Figura 11 Controle usável da Apple.
12. INTERFACES ORGÂNICAS ͵ QUARTA FASE

Dentre todas as interfaces avançadas, há uma que se destacou pela inovação e forma de
interação, por isso ela é considerada como a quarta fase da história do computador. Essa interfa-
ce é inspirada por milhões de formas orgânicas observadas na natureza, afinal, há várias formas
transformáveis, flexíveis, adaptáveis etc., por isso a utilização do termo "orgânico" para ilustrar
que a interface e os dispositivos são inspirados nas formas orgânicas que compõem a natureza.
As interfaces orgânicas somam os conceitos vistos na Realidade Virtual, nas Interfaces Tan-
gíveis e na Computação Usável – Wearable. Observe o dispositivo apresentado pela Figura 12
que construído pelos pesquisadores do laboratório Human Media no Canadá. Ele permite que a
interface seja ajustável para qualquer superfície, flexível ou não.
Figura 12 Tela inicial do DisplayObjects.
Na Figura 12, é possível encontrar uma superfície contendo muitas opções de interfaces (re-
tângulo verde) e, ao lado esquerdo, uma superfície retangular na vertical sem nenhuma opção (re-
tângulo vermelho). Ressalta-se que as opções existentes no retângulo verde não estão "realmente
lá", é como se fossem uma projeção, ou seja, apenas a imagem das funcionalidades é que está. No
entanto, ao contrário de uma projeção, a imagem não está sendo gerada por outro dispositivo e
enviada sobre a superfície do objeto, a imagem é gerada e exibida pelo próprio objeto.

46
O interessante é que as opções existentes podem ser "arrastadas" para qualquer superfí-
cie. Por exemplo, na superfície, há uma interface semelhante ao iPod e o usuário, simplesmente,
"pega" essa imagem com os dedos, arrasta para a outra superfície (retângulo vermelho) e, auto-
maticamente, a imagem de um iPod aparece, como apresentado na Figura 13 (AKAOKA, 2010).
Figura 13 Interação com o DisplayObjects.
Essa estratégia pode ser utilizada para qualquer imagem (funcionalidade) existente. Outro
exemplo é com relação aos quadrados apresentados (vermelho, azul e verde). Cada quadra-
do representa um programa, um clipe etc. Assim, quando o usuário quer assistir um clipe, ele
"pega" o quadrado azul, coloca dentro do iPod e o vídeo começa a funcionar, como você pode
observar na Figura 14.
Figura 14 Assistindo um clipe no DisplayObjects.
Como descrito anteriormente, esta interface pode ser exibida em qualquer superfície, fle-
xível ou não, como ilustra a Figura 15, em que existe uma interface em uma lata de refrigerante
e, também, sobre alguns papéis.
É importante pensar que todos esses tipos de interfaces, apresentados até aqui, são apli-
cados de diversas formas, em diversos contextos, dependo da necessidade e do objetivo. Sendo
assim, a tecnologia está se adaptando às necessidades humanas, no entanto, é impressionante
ver a evolução das interfaces que têm como objetivo auxiliar pessoas com alguma deficiência.
Fonte: VERTEGAAL; POUPYREV, 2008, p. 53.

Figura 15 Exemplos de Interfaces Orgânicas.
13. INTERFACES HUMANOͳCOMPUTADOR

Agora, apresentaremos algumas pesquisas que estão sendo desenvolvidas para criar inter-
faces que já apoiam ou que vão apoiar, diretamente, o ser humano em suas limitações físicas.
Mão Artificial
A mão artificial foi desenvolvida pelos pesquisadores da Universidade Biomédica de Roma,
na Itália, com o intuito de projetar uma mão artificial, comandada pelo cérebro. Por intermédio
desta mão artificial, as pessoas que tiveram suas mãos amputadas por acidente, doença etc.,
têm a possibilidade de utilizar novamente as mãos, mesmo que robóticas, para realizar suas
atividades, como você pode observar na Figura
Segundo o site da Globo.com (2010), para a mão artificial, é necessária uma cirurgia em
que se coloca terminais elétricos em dois nervos do braço que controlam os movimentos dos
dedos. Os fios dos eletrodos são, então, ligados a um equipamento computadorizado que inter-
preta os sinais dos cérebros para acionar a mão artificial, feita de titânio e de fibra de carbono.
Figura 16 Usuário brasileiro controlando a mão robótica por meio da mente.

48
Interface controlada pela boca
O exemplo a seguir, apresentado pela Figura 17, é uma interface que possui algumas ca-
racterísticas desenvolvidas, especialmente, para Stephen William Hawking. Stephen foi um pro-
fessor que teve sucesso em sua carreira e em suas atividades acadêmicas, contudo, após muitos
anos de vida, foi diagnosticado com uma doença degenerativa, chamada ELA (esclerose lateral
amiotrófica). Essa doença, gradualmente, faz com que a pessoa perca os seus movimentos, as-
sim como o restante da musculatura, incluindo a força para manter a cabeça erguida, não atin-
gindo, no entanto, as funções cerebrais.
Figura 17 Interface controlada pelo movimento de uma parte corpo.
Devido ao seu prestígio, houve interesse de muitos profissionais de várias áreas para de-
senvolver um sistema de computador que aceitasse os comandos de um controle inserido na
boca de Hawking, possibilitando, assim, a sua comunicação.
Há muitos exemplos de sucesso que poderiam ser citados para ilustrar os vários tipos de
interfaces e como elas auxiliam as pessoas em suas atividades, sejam elas de entretenimento,
profissionais, ou que permitam, ao ser humano, mesmo com alguma deficiência, interagir com o
mundo. Os exemplos descritos até aqui são para mostrar o quanto é útil o computador quando
as pessoas conseguem interagir com ele de uma maneira fácil, ou seja, uma por meio de uma
interação que respeita suas característica e limitações.
É desta forma que precisamos pensar quando formos desenvolver algum sistema: nos
preocupando com quem o irá utilizar e com a maneira como será essa interação.
Evidentemente, muitas das interfaces que foram apresentadas estão longe da realidade
brasileira devido aos seus custos, pois, como os equipamentos não são desenvolvidos no Brasil,
tornam-se caros para serem importados, entre outros fatores. No entanto, é necessário perce-
ber que, mesmo com as nossas limitações financeiras e tecnológicas, há diversas maneiras de
desenvolver interfaces para auxiliar os usuários, seja no tamanho dos botões, para facilitar que
as crianças e as pessoas idosas enxerguem e consigam clicar neles; seja na escolha da apresen-
tação dos menus para que fiquem mais intuitivos; seja no formato das opções para expressarem
as suas funcionalidades etc. Enfim, essas são preocupações que, a princípio, podem parecer
pequenas e, às vezes, insignificantes, mas que fazem toda a diferença para quem está utilizando
o sistema.
Para encerrar esta unidade, apresentaremos, a seguir, algumas interfaces que fazem parte
da ficção, podendo estar longe ou perto de serem aplicadas no nosso mundo real, mas que são
fontes de inspiração para muitos cientistas, assim como muitos projetos científicos são inspira-
ções para a ficção.
14. INTERFACES E FILMES

Uma maneira interessante de observar a evolução de como o ser humano interage com
a máquina é por meio dos filmes. Há vários filmes que ilustram formas inusitadas de controlar
uma máquina, seja por um dispositivo surreal, pelo comando de voz, pelo movimento do corpo
ou pelo pensamento, o que não significa que tudo o que acontece nos filmes, algum dia, se tor-
nará real, mas é bom perceber e, quem sabe, se inspirar nessas ideias que surgem da imagina-
ção, da experiência, ou por tantas outras coisas.
Dentre os vários filmes que poderiam ser citados, há um, em especial, que chama atenção
tanto pela forma de interação com a máquina, quanto pela máquina com que se está intera-
gindo. O filme, chamado Surrogates – tradução de Os Substitutos, ilustra um mundo em que as
pessoas controlam máquinas com aparência de pessoas, conforme demonstrado na Figura Essas
máquinas, ou substitutos, podem ter qualquer aparência, quem faz a escolha são as pessoas
que as irão controlar. Cada pessoa, nesse mundo que o filme ilustra, possui um substituto.
Figura 18 Robôs com aparência humana no filme Os Substitutos.
No início do filme, há uma pequena história de como tudo começou. A princípio, há um

braço mecânico interagindo por meio dos comandos dados por um macaco. O braço está segu-
rando uma banana e o macaco, apenas com o pensamento, faz com que essa banana chegue
até a sua boca. Depois, são mostradas várias outras interações, até chegar ao ponto de soldados,
por causa da guerra, controlarem robôs, com a aparência semelhante a deles, para ir à guerra,

50
pois, assim, qualquer coisa que acontecesse na batalha, até mesmo a "morte" dos substitutos,
não teria nenhuma consequência para os soldados.
Não demorou muito para que essa ideia se tornasse algo comercial, pois todas as pessoas
comuns começaram a adquirir os substitutos, entretanto não com a aparência delas, mas, sim,
com a aparência que elas desejavam ter, algo que, para elas, fosse perfeito. Consequentemente,
o mundo tornou-se de pessoas perfeitas, sem defeito, e isso influenciou diretamente na dimi-
nuição da criminalidade, do preconceito etc., pois as pessoas comuns, com "defeitos", estavam
em suas casas controlando os substitutos por meio do pensamento.
O interessante é que a pessoa conseguia sentir o que o seu substituto sentia, ver o que
ele via. Isso fez com que as pessoas não quisessem mais sair de casa, pois não existia motivação
para tal, se elas podiam fazer tudo por meio de um substituto perfeito e, sobretudo, aproveitar
o que ele fazia.
Nesse filme, há toda uma história, que não cabe discutirmos aqui, mas a forma de in-
teração é algo único. Imagine você poder controlar uma máquina sem o perigo de se ferir e
conseguir sentir tudo o que acontece com ela? Isso é algo tão especial que, muitas empresas,
especialmente de jogos, pensam em controles e formas de permitir que a pessoa se sinta dentro
do jogo, que o movimento que ela vê na tela possa ser sentido em suas mãos, e o movimento
desejado seja feito no controle com a movimentação de seu corpo. Esse, porém, é apenas um
exemplo de como o que vemos em filmes pode ser aplicado na vida real, afinal, o objetivo é
permitir uma interação cada vez mais próxima à natural.
De modo semelhante, ao consideramos o controle das máquinas pelo pensamento, há
como exemplo o filme Avatar, demonstrado na Figura Nesse filme, é possível controlar uma
máquina, considerada avatar, para conhecer outro lugar com seres selvagens, e, por meio desse
avatar, que possui as características semelhantes às desses seres, é possível uma melhor aproxi-
mação deles, com o intuito de conhecer tudo o que há nesse lugar, especialmente suas riquezas
naturais.
Figura 19 Filme Avatar – Máquina que permite ao ser humano controlar um Avatar.
Assim são os filmes, cada vez mais inusitados e com propostas diferentes, até o ponto de
criar máquinas com a forma humana perfeita, que não são mais controladas por seres humanos
(como na Figura 20), mas, sim, capazes de estabelecer suas atitudes, fazer suas escolhas, pensar
e amar. Em outras palavras, capaz de fazer todas as coisas que, até então, apenas o ser humano
era capaz.

Humano-Computador.
você encontrar dificuldades em responder a essas questões, procure revisar os conteúdos estuda-
dos para sanar as suas dúvidas. Este é o momento ideal para que você faça uma revisão desta uni-
dade. Lembre-se de que, na Educação a Distância, a construção do conhecimento ocorre de forma
cooperativa e colaborativa; compartilhe, portanto, as suas descobertas com os seus colegas.
unidade:
1) Em cada fase da história do computador, surgiram várias novas formas de interação com essa máquina, cada
uma delas buscando não apenas aprimorar o hardware em si, mas também possibilitar ao ser humano interagir
de forma adequada, fácil e, em alguns momentos, descontraída. Assim, relacione algumas dessas fases com
suas características a seguir:
( 1 ) Interfaces Tangíveis ( ) Permite que a informação digital possa estar
em objetos e roupas, entre outras coisas que as
pessoas podem utilizar em seu cotidiano ou es-
poradicamente.
( 2 ) Wearabel Computing ( ) Permite que a informação digital seja visua-
lizada, controlada e sentida por meio de equipa-
mentos digitais.
( 3 ) Interfaces Orgânicas] ( ) Permite que a informação digital se adapte
ao dispositivo sem dificuldade, pois a intenção é
permitir uma forma natural, correspondente ao
formato do dispositivo.
( 4 ) Realidade Virtual ( ) Permite que a informação digital possa ser
manipulada como se fosse um objeto concreto.
2) A evolução da interface que aconteceu na terceira fase teve grande influência na aquisição de computadores
por pessoas não especialistas em computação, especialmente pelo surgimento de uma nova forma de interagir
com o computador, pois o que antes era complicado e necessitava da memorização de muitas linhas de coman-
do, passou a ser:
a) mais próximo do cotidiano das pessoas, uma vez que foram utilizados recursos usados no real para o virtual.
b) mais real para as pessoas, especialmente por utilizar recursos que permitiam que as pessoas pudessem ver
um determinado objeto em três dimensões.
c) mais fácil, pois os computadores eram capazes de detectar o movimento e, assim, responder de acordo com
as atitudes das pessoas.
d) mais bonito, especialmente pela forma com que as cores da interface eram projetadas em qualquer dispo-
sitivo, já que a interface era adaptativa.
e) mais usável, pois havia várias opções na interface, que permitiam ao usuário adequar a interface do sistema
de maneira perfeita às suas necessidades e limitações.
Gabarito
1) Veja a sequência das respostas.
(2) (4) (3) (1)
2) a.

52
16. CONSIDERAÇÕES
É possível concluir, por meio da leitura sobre a história da interação humano-computador,
que a evolução da IHC ocorre de forma distinta da evolução do hardware. Afinal, você já per-
cebeu que sempre há novidades nos equipamentos, pois eles estão cada vez menores, mais
finos, mais rápidos etc., mas, a ideia de utilizar a área de trabalho com os ícones ainda persiste?
Lembre-se de que esse tipo de interface surgiu na terceira fase da história da IHC.
Essa característica já foi observada por muitos pesquisadores, e há estudos que apontam
que a evolução do hardware é continua, ou seja, sempre há novidades e inovações, porém, a
evolução da IHC acontece aos saltos, ou seja, quando surge uma novidade, após algum tempo
ela se estabelece e, então, continua a ser utilizada durante muitos anos.
Foi de modo semelhante que tomou-se consciência da importância de se pensar nas pes-
soas no momento de se desenvolver aplicativos, preocupação essa que se deu lentamente.
Vale a pena conhecer a história descrita pelo pesquisador Keinonenm (2008). Nessa histó-
ria, ele descreve quatro momentos importantes do desenvolvimento da interface.
No primeiro momento, nomeado de type-forms, os desenvolvedores não estavam pre-
ocupados com os usuários, ou seja, era um tipo de interface para o uso de todas as pessoas.
Na realidade, nessa época, nem havia uma interface, pois ocorreu na primeira fase, em que,
independentemente da pessoa, era preciso o domínio para manipular cabos, entender todas as
fiações etc., por isso somente as pessoas envolvidas, isto é, os cientistas, conseguiam manipular
a máquina.
No segundo momento, a preocupação estava relacionada ao desenvolvimento das tec-
nologias, porque, nesse período, acontecia a segunda guerra mundial, ou seja, o objetivo era
desenvolver ferramentas úteis e eficientes para combater o inimigo, não para serem eficientes
aos usuários.
Foi somente no terceiro momento que houve uma preocupação com a responsabilidade
social e em desenvolver tecnologias para o mundo real e ideal, contudo, já estavam estipulados
quais eram os problemas que havia nesse "mundo real" para serem solucionados. Eles estavam
relacionados com o desenvolvimento de equipamentos para auxiliar na área da saúde, da pes-
quisa etc., entretanto, o usuário ainda não era a preocupação central.
Finalmente, no quarto momento, passou a existir a preocupação com as pessoas, suas
necessidades e suas características, pois houve a percepção de que toda a evolução não teria
sentido se as pessoas não a soubessem utilizar. É nesse contexto que você deve levar em consi-
deração para o estudo da próxima unidade, que apresentará uma discussão sobre a qualidade
que se deve ter ao planejar, avaliar, enfim, como considerar as pessoas que utilizarão o sistema
durante todas as suas fases de desenvolvimento.
17. E ͵ REFERÊNCIAS
AKAOKA, E.; VERTEGAAL, R. DisplayObjects: Interactive styrofoam gadget design workbench. Disponível em: <http://www.
organicui.org/>. Acesso em: 10 jan. 2010.
GLOBO.COM. Brasileiro é escolhido para testar a mão artificial na Itália. Disponível em: <http://fantastico.globo.com/Jornalismo/
FANT/0,,MUL1405488-15605,00.html>. Acesso em: 21 mar. 2010.
MIT. Wearable computing. Disponível em: <http://www.media.mit.edu/wearables/>. Acesso em: 10 jan. 2010.
Lista de figuras
Figura 1 – ENIAC: disponível em: <http://www.sousampaio.com/Portals/0/eniac.jpg>. Acesso em: 26 fev. 2010.
Figura 2 – Cartão Perfurado: Disponível em: < http:// palazzo. pro.br/hist/images/cartao_perfurado.gif>. Acesso em: 26 fev.
2010.
Figura 3 – Monitor Monocromático: disponível em: <http://www.baixaki.com.br/imagens/materias/27234696/69285.jpg>.
Acesso em: 21 mar. 20
Figura 4 – Interface Gráfica: disponível em: <http://www.kernelthread.com/publications/appleoshistory//images/system1.gif>.
Acesso em: 26 fev. 2010.
Figura 5 – Área de trabalho do computador Microsoft© Windows: disponível em:
<http://olaubuntu.files.wordpress.com/2007/05/desktop_001.jpg>. Acesso em: 26 fev. 20
Figura 7 – Nova aparência dos antigos dispositivos para interagir com o computador: disponível em: < http://www.likecool.
com/Gear/Gaming/Logitech%20New%20G-series%20Peripherals%20for%20PC%20Gaming/big/Logitech-New-G-series-
Peripherals-for-PC-Gaming.jpg >. Acesso em: 21 mar. 2010.
Figura 10 – Imagens do filme Minority Report: disponível em: <http://www.imdb.com/title/tt0181689/>. Acesso em: 01 fev.
2010.
Figura 11 – Controle usável da Apple: disponível em: <http://radio-weblogs.com/0105910/2003/10/13.html>. Acesso em: 01
mar.2010.
Figura 12 Tela inicial do DisplayObjects: disponível em: <http://www.organicui.org/>. Acesso em: 10 jan. 2010.
Figura 13 Interação com o DisplayObjects: disponível em: <http://www.organicui.org/>. Acesso em: 10 jan. 2010.
Figura 14 Assistindo um clipe no DisplayObjects: disponível em: <http://www.organicui.org/>. Acesso em: 10 jan. 2010.
Figura 16 – Usuário brasileiro controlando a mão robótica por meio da mente: disponível em: <http://fantastico.globo.com/
Jornalismo/FANT/0,,MUL1405488-15605,00.html>. Acesso em: 01 mar. 2010.
Figura 17 – Interface controlada pelo movimento de uma parte do corpo: disponível em: <http://standupforamerica.files.
wordpress.com/2009/06/stephen-hawking.jpg>. Acesso em: 01 mar. 20
Figura 18 – Robôs com aparência humana no filme Os Substitutos: disponível em:
<http://www.imdb.com/find?q=Surrogates>. Acesso em: 01 fev. 20
Figura 19 – Filme Avatar – Máquina que permite ao ser humano controlar um Avatar: disponível em: <http://www.avatarmovie.com/
index.html>. Acesso em: 01 mar. 2010.
Figura 20 – Robô com a forma de uma criança no filme Inteligência Artificial: disponível em: <http://www.imdb.com/title/tt0212720/>.
Acesso em: 01 mar. 2010.

ASSIS, A. S. F. R.; SILVA, J. C. A. A Realidade virtual e sua utilização no desenvolvimento de Interfaces. Relatório Técnico. São
Carlos. EdUFSCar, 2000.
CARDOSO, A.; LAMOUNIER, JR. E. Aplicações na Educação e Treinamento. João Pessoa: Symposium on Virtual and Augmented
Reality, 2008.
KEINONENM, T. User-centered design and fundamental need. Lund - Suécia. The 5th Nordi conference on Human-computer
interaction: building bridges , 2008.
KIRNER, C.; SISCOUTTO, R. A. Fundamentos de realidade virtual e aumentada. João Pessoa: Symposium on Virtual and Augmented
Reality, 2008.
ROCHA, H. V.; BARANAUSKAS, M. C. C. Design e avaliação de interfaces humano-computador. Campinas: NIED/UNICAMP, 20
VAN DAM, A. Post-WIMP User Interfaces. Communications of the ACM, v.40, n.2, p.63-67, fev. 19
VERTEGAAL, R. ; POUPYREV, I. Organic user interfaces: Designing Computers In Anyway,Shape, Or Form. Communications of the
ACM. v. 51, n. 6, p. 48-55, jun. 2008.

EAD
Qualidade no
Desenvolvimento do Software
1. OBJETIVOS
• Entender o conceito de qualidade no contexto computacional e a sua influência no de-
senvolvimento e na utilização do software.
• Conhecer e aplicar algumas normas para desenvolver software com qualidade.
• Apresentar um framework que contém algumas normas e indicar quando cada uma
delas deve ser considerada no desenvolvimento do software.
2. CONTEÚDOS
• Qualidade no desenvolvimento do software e seus fatores.
• Framework e as qualidades existentes em um software.
• Barreiras para a falta de qualidade no uso.

guir:
1) Leia os livros da bibliografia indicada para que você amplie seus conhecimentos sobre
formas de desenvolver sistemas com qualidade. Leia o material didático atentamente
e discuta a unidade com seus colegas de curso e com o tutor.
2) Visite o site da ISO – International Organization for Standardization. Disponível em:
<http://www.iso.org/iso/home.html>. Acesso em: 06 jul. 2010 e investigue o que são
normas e algumas das normas existentes para o desenvolvimento de software. Não
se limite apenas a esse site, explore a web e toda a sua riqueza de informação sobre
esse assunto.
3) Antes de iniciar os estudos desta unidade, pode ser interessante conhecer um pouco
das normas de qualidade existentes para o desenvolvimento de software, consideran-
do a usabilidade.
Se preocupar em entender os fatores humanos e a evolução da interação humano-compu-
tador permite ao projetista planejar e desenvolver um software adequado para o usuário, pois
ele pode utilizar esse conhecimento não apenas para adequá-lo às necessidades computacio-
nais de um usuário, mas também para desenvolver o software, considerando sua linguagem e
suas limitações tanto físicas quanto cognitivas, bem como outras características que diretamen-
te influenciam a forma que ele o utiliza.
Dessa forma, podemos dizer que todo o conhecimento adquirido por meio da leitura da
história da IHC possibilita ao projetista entender e evitar os erros já cometidos e, assim, aprovei-
tar as estratégias e os casos de sucesso obtidos anteriormente. Outra vantagem é que, conhe-
cendo o passado, o presente torna-se mais compreensível, e o futuro, menos imprevisível.
Não se preocupe se, ao ler a frase anterior, você estiver se perguntando a respeito da
responsabilidade de pensar sobre o que ainda está por vir, afinal, a área da computação, muitas
vezes, é realmente imprevisível, mas, na maioria das vezes, toda a invenção ou ideia tem um
processo, e entendê-lo é importante. Quanto mais você conhecer esse processo, maior será a
possibilidade de vislumbrar o seu resultado.
Procuramos conhecer cada vez mais não apenas da área computacional, mas também de
todas as outras áreas que a IHC envolve para desenvolver softwares com qualidade. Este é um
grande desafio que temos a partir do momento que estamos envolvidos nessa tarefa.
Se você pensar bem, não é apenas no desenvolvimento do software que a qualidade é
um quesito fundamental. É possível perceber que, em todas as áreas e no desenvolvimento de
todos os produtos, a busca por qualidade é sempre um objetivo. Garantir qualidade em um pro-
duto é ter a certeza de que ele estará adequado, funcional e, possivelmente, nesse caso, haverá
garantia de sucesso com a clientela.
5. QUALIDADE E SEUS FATORES

A qualidade está diretamente relacionada com vários fatores; dentre eles, estão o público-
alvo que se deseja atingir com o produto e com o planejamento que a empresa e/ou projetista
realizou antes de desenvolvê-lo. Por exemplo, imagine duas lojas de confecções de roupas, a
primeira tem como público-alvo pessoas de baixa e média renda e a segunda tem como público-
alvo pessoas de alta renda. Observe que, cada empresa tem um público-alvo diferenciado e,
dessa forma, o planejamento também se difere, embora o objetivo seja o mesmo, ou seja, ven-
der roupas. Existem algumas diferenças, uma delas é o valor que se deseja atribuir ao produto
e, este valor tem de estar de acordo com o público-alvo, afinal, há a necessidade de desenvolver
algo em um valor que seja acessível ao público-alvo desejado.
Nesse contexto, a partir do momento em que se definiu o público-alvo e pensou no valor,
há a necessidade de definir e estabelecer a qualidade do produto a ser vendido. Observe que,
nesse caso, a qualidade é influenciada pelos dois fatores citados anteriormente, pois eles estão
© U3 – Qualidade no Desenvolvimento do Software 57
diretamente relacionados em quais serão os materiais adquiridos, na forma que as roupas serão
fabricadas, entre outros detalhes.
Você pode estar pensando que, com certeza, a empresa que tem o público-alvo de maior
renda possui produtos com mais qualidade. De maneira geral, você está com a razão, pois have-
rá a possibilidade de se investir mais nos materiais etc., mas se pensarmos de forma específica,
considerando o público-alvo, as duas empresas vendem produtos de qualidade.
Cada empresa planejou e desenvolveu algo de acordo com o seu público-alvo e, possivel-
mente, esse público está satisfeito em comprar e usar as suas roupas, pois elas, de alguma for-
ma, estão acessíveis e foram planejadas para atendê-los da melhor forma possível. Vale ressaltar
que, nesse exemplo, foram citadas duas empresas hipotéticas que possuem responsabilidade e
que têm como objetivo produzir produtos de maneira eficiente e eficaz.
Esse exemplo foi utilizado para você perceber o quão difícil é definir e avaliar qualidade,
pois o que pode ser qualidade para um, não é para outro. A qualidade é um quesito um tanto
subjetivo, mas fundamental em todo o processo e, especialmente, no produto final. Devido à
subjetividade e à importância desse assunto em muitas áreas, surgiram tentativas comuns para
de alguma forma garantir e/ou atribuir qualidade.
Uma dessas formas criadas foi a ISO – International Organization for Standardization –,
que é uma entidade que estabelece padrões ou normas mundiais que devem ser seguidas para
garantir qualidade (BEVAN, 1999).
Existem normas para diversos contextos, como saúde, computação, entretenimento etc.,
e em diversos níveis do projeto como planejamento, desenvolvimento, produção, instalação,
serviços associados etc. (ISO_A, 2010).
Devido à rigorosa forma em definir as normas e pelo fato de cada uma ser adaptativa de
modo a atender as necessidades mundiais, a ISO tornou-se um padrão adotado em todo o mun-
do, tanto que, hoje, a adoção da ISO significa que a empresa, produto etc. possui os requisitos
de qualidade ideal.
Por ter sua eficiência e eficácia comprovada e por ser algo conhecido e adotado em todo
o mundo, há, nesta unidade, uma discussão sobre algumas ISOs existentes para o desenvolvi-
mento de software. É fundamental o conhecimento dessas ISOs, pois permitirá a você pensar e
adotar normas que são utilizadas e exigidas em todo o mundo e, uma vez atendidas, há a pos-
sibilidade de você garantir qualidade no que está desenvolvendo. Assim, algo que até então era
subjetivo e difícil de mensurar será mais "palpável" e viável de se avaliar.
Como citado anteriormente, há várias normas, e cada uma é identificada por um número.
Por exemplo, existem ISO 8402 com normas para estabelecer a capacidade de um item desem-
penhar uma função requerida (BEVAN, 1999) ISO 14000 com um conjunto de atributos que têm
impacto na capacidade do software de manter o seu nível de desempenho etc. (ISO_B, 2010). E
cada norma é para algo específico, por isso, para o desenvolvimento de um software, há diver-
sas normas que devem ser consideradas.
A variedade de normas existentes faz que os profissionais envolvidos nesse processo te-
nham dificuldade em conhecer e aplicar essas normas; no entanto, existe uma pesquisa publica-
da por Nigel Bevan que estabelece uma estrutura dividida por parte (BEVAN, 1999). Cada uma
representa uma etapa importante no desenvolvimento do software e, para cada parte, possui
um conjunto de ISOs que deve ser considerado.

Essa estrutura, que Bevan (1999) chama framework, será discutida nesta unidade por ser
algo que enfoca muitos detalhes importantes, os quais estão relacionados com as etapas do
desenvolvimento do software, especialmente na interface. É importante que você compreen-
da que essa unidade não descreve em detalhes todas as normas existentes, pois isto pode ser
encontrado em muitos lugares na literatura. O principal objetivo que temos é apresentar como
garantir qualidade em cada etapa do desenvolvimento do software e a influência que a Intera-
ção Humano-Computador tem para se ter um software de qualidade.
6. FRAMEWORK E AS QUALIDADES EXISTENTES EM UM SOFTWARE

Antes de iniciarmos a discussão sobre como atribuir qualidade ao software, é importante
entendermos esse conceito no contexto computacional. Segundo Bevan (1999), qualidade é um
conjunto de características para satisfazer as necessidades explícitas e implícitas; assim, de algu-
ma forma, quando você se preocupa com a qualidade, está considerando além das necessidades
relatadas pelo usuário.
Bevan (1999), em seu framework, descreve três tipos de qualidade – como ilustrado na
Figura 1 –, que são: Qualidade Interna, Qualidade Externa e Qualidade no Uso. Cada qualidade
está relacionada com uma norma: Qualidade Interna – ISO/IEC 9126-3; Qualidade Externa – ISO
/IEC 9126-2 e; Qualidade no Uso – ISO/IEC 9126-4.
Figura 1 Relação entre a Qualidade Interna, Externa e no Uso (BEVAN, 1999, p. 3).
Agora veremos em que consiste cada qualidade de acordo com Bevan, 19

Qualidade Interna considera a inspeção na especificação ou nos requisitos e no código
fonte. De maneira geral, há a preocupação de avaliar a forma com que o programa foi imple-
mentado (linguagem, organização, documentação etc.) e, se essa implementação foi realizada
considerando os requisitos, ou seja, se o que foi implementado está de acordo com o que foi
planejado, em outras palavras, se está de acordo com as necessidades do usuário.
Qualidade Externa descreve a importância de analisar o comportamento do código quan-
do ele é executado. Dentre as preocupações, estão observar se o software gera resultados pre-
cisos ou dentro do esperado; sua capacidade de interagir com os outros sistemas de acordo com
o especificado; frequência de falhas; capacidade do produto para manter determinados níveis

de desempenho mesmo na presença de problemas; capacidade do software para restabelecer o
nível de desempenho desejado e recuperar dados em caso de ocorrência de falha etc.
Qualidade no Uso envolve o usuário diretamente, pois é necessário observar o efeito do
software em um determinado contexto de uso. É preciso verificar a facilidade que o usuário terá
para reconhecer as funcionalidades existentes no software e a forma com que cada uma delas
será utilizada por ele, bem como observar a facilidade encontrada pelo usuário para aprender a
utilizar o produto com todas as suas características.
É importante que você entenda que, apesar dessas qualidades estarem descritas sepa-
radamente, elas estão relacionadas diretamente, como pode ser observado na Figura Não há
possibilidade de garantir Qualidade no Uso se não há Qualidade Interna e assim por diante, uma
vez que as funcionalidades, a interface e todas as outras características que o usuário tem aces-
so, enquanto está interagindo com o sistema, advém dos requisitos definidos, e todos esses tem
de estar implementados no software (Qualidade Interna). Contudo, de nada adianta se tudo
estiver implementado se não estiver funcionando de maneira adequada (Qualidade Externa);
tudo o que está no software tem que agir de acordo com o esperado e estar visível, para que o
usuário, ao interagir com o sistema, possa identificar suas funcionalidades e conseguir utilizá-las
de forma amigável (Qualidade no Uso).
Figura 2 Relação entre as qualidades (BEVAN, 1999, p. 4).
Ao considerar essas três qualidades em todo o processo de desenvolvimento do software,

você estará agregando a ele algumas características necessárias para garantir o sucesso de sua
aplicação. De acordo com Bevan (1999), algumas dessas características são:
1) Aumento da eficiência – capacidade para atender todas as necessidades do usuário,
ou seja, a garantia de que, no software, existem todas as funcionalidades desejadas
pelo usuário e observadas durante o levantamento de requisitos. E, como um dos
principais objetivos de utilizar um sistema computacional é realizar uma determinada
tarefa de modo mais fácil e automática, espera-se que o software seja capaz de auxi-
liar o usuário em todas as tarefas, permitindo a ele realizá-las de uma maneira mais
eficiente, pois o que antes era trabalhoso e difícil agora tem de ser intuitivo, simples
e rápido.
2) Melhora na produtividade – possibilidade de estender as capacidades do usuário.
Observe que o uso do sistema computacional é como se fosse qualquer outro instru-
mento para apoiar o usuário na realização de suas atividades. Por exemplo, até um
tempo atrás, era muito comum utilizar um prego e um martelo para fazer um furo
na parede. Apesar desses equipamentos ainda serem utilizados atualmente, hoje em
dia há a possibilidade de utilizar uma furadeira para realizar a mesma tarefa. O que
muda com esse novo instrumento? A facilidade de furar a parede, o menor esforço em
executar essa tarefa e o aumento da produtividade, pois o usuário poderá fazer uma
quantidade maior de furos em menos tempo e com menor esforço. A mesma ideia
pode ser aplicada com o uso do computador, afinal, a ideia é que, com a facilidade e
agilidade de realizar uma determinada tarefa, o usuário consiga fazer muito mais, da
melhor forma, em menos tempo. Por isso, é comum dizer que há a possibilidade de
estender a capacidade do usuário, pois ele já é capaz de realizar uma determinada
tarefa; o software apenas irá aprimorar a forma com que ela é realizada.
3) Redução de erros – permite ao usuário realizar uma determinada tarefa de forma cor-
reta. Quando o sistema é intuitivo, fácil de ser compreendido, enfim, quando possui
uma interface de qualidade, o usuário consegue fazer tudo o que precisa sem dificul-
dades. Uma boa interface possui uma linguagem comum e fácil de ser entendida pelo
usuário, e não há alguns erros comuns em interfaces, como inconsistências e ambigui-
dades. Sem esses erros, não haverá vários caminhos para o usuário atingir a sua meta,
e isso permitirá que o usuário não fique perdido, bem como que toda a informação
que for exibida por meio da interface será exata. Assim, não haverá redundâncias ou
palavras de duplo sentido.
4) Redução no treinamento – capacidade de utilizar o sistema sem esforço cognitivo.
Essa é uma característica que, até pouco tempo, não era tão citada quanto deveria,
uma vez que os projetistas e desenvolvedores estavam mais preocupados no tempo
e nos gastos que ocorriam durante todo o processo de desenvolvimento do softwa-
re até a sua entrega ao usuário, e poucos se preocupavam em como o sistema seria
utilizado depois, qual seria a dificuldade do usuário em realizar a tarefa etc.; enfim,
a preocupação era enquanto o software estava nas mãos deles, e não nas mãos dos
usuários. Isto é algo que, hoje em dia, tem de ser levado em consideração, pois, a
partir do momento em que você se responsabilizou por algo, é necessário ter o com-
prometimento e a responsabilidade com ele em qualquer lugar que esteja. Quando
a interface é difícil de ser compreendida mesmo tendo todas as funcionalidades, o
usuário não consegue utilizar o sistema com muita facilidade, e, na maioria das vezes,
isto significa que um dos participantes do desenvolvimento do software terá de se
responsabilizar em explicá-lo para o usuário, algo que, em alguns casos, pode demorar
de horas até dias. Observe que qualquer profissional longe da empresa ou de seu am-
biente de trabalho significa aumento de custos ou diminuição da produtividade, pois o
que ele fazia antes você terá de pagar outro para fazer ou ele terá de fazer menos para
se dedicar mais tempo ao usuário. Podemos perceber que a descrição ilustra alguns
pontos negativos para os profissionais ligados ao desenvolvimento; no entanto, para
o usuário, há muitos outros pontos negativos que podem até ser considerados piores
e que influenciarão o relacionamento entre profissionais e usuário, pois, a partir do
momento em que o usuário contratou profissionais para realizar um desenvolvimen-
to, ele espera que tenha, no final, algo de qualidade, e se os resultados previstos não
forem alcançados, o usuário poderá mudar sua opinião sobre o profissionalismo das
pessoas e suas capacidades relacionadas ao desenvolvimento; o que, com certeza, in-
fluenciará em sua decisão nas futuras contratações e indicações para outras pessoas.
5) Aumento da aceitabilidade – relação de bom uso do software pelo usuário. O usuário
tende a gostar mais do software quando há informações e funcionalidades fáceis de
serem encontradas e utilizadas, bem como se todas as coisas visíveis pelo sistema es-
tiverem em um formato adequado e puderem ser assimiladas com facilidade. Como e
o que o usuário pode fazer no software por meio da interface influencia, diretamente,
em sua aceitabilidade. A ideia, nessa característica, é simples e muito similar ao que
acontece em nosso cotidiano, uma vez que nós aceitamos com mais facilidade aquilo
que nós gostamos, compreendemos e nos identificamos. Com o software, esses pon-
tos também são considerados pelo usuário para definir se ele vai gostar ou não.
Observe que essas cinco características apenas são possíveis se houver as três qualidades
descritas anteriormente. Vale ressaltar que, em cada qualidade, é importante considerar a efi-
ciência, produtividade, satisfação etc., pois é preciso garantir que cada qualidade possua tudo o
que é necessário. Entretanto, a terceira qualidade, Qualidade no Uso, possui fatores adicionais
que devem ser considerados, como as características, os objetivos e o contexto do usuário. É

nessa Qualidade que o usuário terá maior contato, uma vez que tudo estará visível e disponível
por meio da interface; por isso, tem de haver um maior cuidado com ela.
Bevan (1999) comenta algumas pesquisas que mostram que a maioria dos problemas en-
contrados nos softwares está na usabilidade: cerca de 60% dos erros são na usabilidade, e ape-
nas 15% dos erros estão relacionados às funcionalidades. Esses valores mostram que ainda há
uma preocupação e compreensão maior no processo de perceber as necessidades, entende-se
como funcionalidades, desejadas pelo usuário e codificá-las; no entanto, os projetistas não estão
sendo tão eficazes em mostrar essas funcionalidades para o usuário. Por isso, há a importância
de se dedicar e buscar entender todos os conceitos descritos nesse material, pois a dificuldade
da maioria dos profissionais, possivelmente, está na falta de conhecimento. Saber sobre o que
pode influenciar um melhor uso e, consequentemente, a diminuição de erros pode trazer mui-
tas vantagens – dentre elas, a vantagem competitiva.
7. BARREIRAS PARA A FALTA DE QUALIDADE NO USO

A falta de conhecimento é um dos fatores principais para essa quantidade de erros na usa-
bilidade. No entanto, Bevan (1999) descreve mais três barreiras que também influenciam, como
pode ser observado na Figura 3.
Figura 3 Barreiras para a falta de Qualidade no Uso.
Além da falta de conhecimento, podemos observar, na Figura 3, que as demais barreiras

descritas por Bevan (1999) são: cultura, técnica e estratégia.
Cultura
A cultura, nesse caso, não está relacionada com o conhecimento do usuário, mas, sim,
com a forma que todos os envolvidos no desenvolvimento do software trabalham, ou seja, é a
cultura da empresa ou a cultura dos profissionais. Geralmente, o que acontece é que os profis-
sionais não conhecem as atividades e as formas de se desenvolver uma interação centrada no
usuário ou, muitas vezes, essa forma de desenvolvimento não faz parte do dia a dia deles, pois
o que frequentemente ocorre são profissionais mais preocupados com as funcionalidades, e a
questão da interface, da usabilidade etc. ficam em segundo plano caso haja tempo ou nem são
consideradas. Esta é uma cultura que, aos poucos, está sendo mudada, mas ainda hoje existem
profissionais com esse pensamento. Portanto, é importante se preocupar desde o início com es-
ses fatores e, sempre que possível, envolver o usuário nesse processo. Não há ninguém melhor
do que ele para dizer se algo está bom ou não; por isso, há a necessidade de se trabalhar com os
profissionais para que eles possam se atentar e/ou mudar a visão e a forma de trabalho.

A ISO/IEC TR 15504 provê algumas indicações de como a cultura influência na Qualidade

no Uso descrevendo algumas frases de profissionais. A seguir, são descritas algumas afirmações
ou alguns questionamentos e uma discussão de como deve ser a característica desse profissio-
nal ou da empresa em que ele trabalha (BEVAN, 1999).
Tente, antes de ler essas frases, pensar no que você diria com relação à forma que você
trabalha e a sua preocupação ou dúvida com relação à Qualidade no Uso. Se caso alguma das
frases descritas a seguir for de encontro com o seu pensamento, preste ainda mais atenção na
discussão sobre ela. Vejamos!
Muitos profissionais afirmam que "não tem problemas com usabilidade. No entanto, o
que acontece de fato é que este é um assunto não discutido. É simples afirmar que não há pro-
blema com a usabilidade se ela não for observada, avaliada e levada em consideração. A afirma-
ção "nós não sabemos por que temos problemas com usabilidade" remete a alguns profissionais
que podem conhecer o assunto, mas não utilizam de fato um processo para atingir esse objeti-
vo; a questão da usabilidade não é vista e discutida com a seriedade que deve ter.
"É absolutamente necessário ter problemas com usabilidade?". Nesse caso, geralmente
há uma preocupação maior com a usabilidade, e, em alguns casos, esse profissional utiliza um
método para identificar os problemas. No entanto, o método é utilizado de forma inadequada,
pois a preocupação está centrada nos problemas que poderão ocorrer, e não na melhor forma
de apresentar e desenvolver algo para o usuário. Observe que os problemas devem ser identi-
ficados de acordo com a preocupação em adequar o software para o usuário e não tentar ade-
quar o software de acordo com os problemas que podem acontecer.
"Por meio dos processos, nós estamos identificando e resolvendo nossos problemas". Pro-
fissionais que pensam assim conhecem e utilizam de fato algum método que tem como preo-
cupação e objetivo a usabilidade. Eles veem resultados na utilização dos processos, mas nem
sempre os resultados possuem o benefício esperado. "Prevenir erros de usabilidade é uma ro-
tina que faz parte do desenvolvimento do software". Nesse caso, os processos estão integrados
de forma eficaz à rotina de trabalho do profissional, uma vez que ele conhece e se preocupa em
entender todos os fatores que podem influenciar para o não surgimento de erros na usabilida-
de, sendo o principal a preocupação em considerar o usuário.
"Nós sabemos por que nós não temos problemas com usabilidade". Com essa afirmação,
o profissional garante não apenas que conhece sobre o assunto, mas também que se preocupa
e toma todas as atitudes necessárias para evitar esse tipo de erro.
Essas frases são para ilustrar um pouco os diversos profissionais existentes no mercado de
trabalho, e cabe a você, um profissional que conhece e se preocupa com as questões sobre a
interação humano-computador, conversar com esses profissionais e mostrar as vantagens de se
dedicar a uma área de extrema importância; enfim, tentar, de muitas formas, mudar a cultura
desses profissionais.
Técnica
É importante criar e/ou aprimorar e, especialmente, utilizar processos ou frameworks que
incluem métodos e atividades que apoiem os profissionais no desenvolvimento de um software
de forma adequada, ou seja, que também atenda às necessidades da interação humano-compu-
tador. É necessário esclarecer que, algumas vezes, a falha está no próprio processo, pois alguns
deles não possuem, de forma clara, a sua finalidade e os benefícios de serem utilizados; algo que
poderia cativar e chamar a atenção dos profissionais.
Uma forma de permitir um bom processo para os profissionais é a documentação de tudo

o que é feito durante o desenvolvimento. Apesar de ser considerada uma tarefa um pouco te-
diosa para alguns, essa atitude permitirá que sejam registrados todos os processos adotados ou
não, a forma que foi feito o levantamento de requisitos, planejamento, desenvolvimento, testes
etc.; enfim, o que aconteceu e, especialmente, as ações e estratégias certas e erradas. Esse do-
cumento, mesmo como rascunho, começa a ser um processo da própria empresa ou profissio-
nais das lições aprendidas, e, de acordo com a ocorrência de mais projetos, esse processo pode
ser aprimorado e outros profissionais podem ter acesso e, assim permitir a disseminação do
conhecimento. Enfim, você não pode culpar a sua não preocupação em adotar uma técnica por
causa dos processos existentes, pois você, além de utilizá-los, terá condições de aprimorá-los.
A ISO 13407 explica como atingir a Qualidade no Uso incorporando e considerando as
técnicas de IHC como objetivo principal durante todo o clico de vida do desenvolvimento do sof-
tware, ou seja, considerando toda a multidisplinaridade que esta área envolve e incorporando
os fatores humanos, entre outros fatores já discutidos até o presente momento (SOUZA, 2006).
Essa ISO possui quatro tarefas que devem fazer parte do ciclo de vida:
1) Entender e especificar o contexto de uso.
2) Especificar e entender os requisitos da empresa e de seus usuários.
3) Produzir solução de interação (interface e todas as outras características que influen-
ciam a IHC).
4) Avaliar a solução da interação considerando os requisitos.
Observe que essas tarefas podem ser consideradas como um ciclo, pois, além de ser im-
portante manter essa sequência, ela pode ser repetida indefinidamente, uma vez que, a cada
novo requisito a ser implementado, pode ser detalhado em outros e ter de passar novamente
pelas quatro tarefas, de tal forma a obter detalhes suficientes para desenvolver algo de quali-
dade.
Estratégia
Os profissionais devem pensar e considerar a Qualidade no Uso como o principal objetivo
durante o desenvolvimento do software. Quando a estratégia é considerar a qualidade desde o
início, a possibilidade é bem maior de alcançá-la. Essa qualidade deve constar nos requisitos e
ser uma prioridade. Em muitos casos, não há informações precisas sobre a Qualidade no Uso, e,
com isso, há pouco incentivo de ser o objetivo principal. Segundo Bevan (1999), também exis-
tem algumas diferenças no que é qualidade entre o usuário e os profissionais; essas diferenças
têm de ser esclarecidas e compreendidas o quanto antes para que, no planejamento e desen-
volvimento, essas divergências não atrapalhem a qualidade do software.
A ISO 9241-11 (ISO_C, 2010) descreve como a Qualidade no Uso pode ser definida, docu-
mentada e avaliada como parte da qualidade do sistema conforme a ISO 9001 (BEVAN, 1999),
que são:
1) Identificar o contexto de uso: informações sobre as características do usuário, os ob-
jetivos, as tarefas e o ambiente em que o usuário trabalha são algumas das informa-
ções que prove o contexto de uso.
2) Especificar qualidade nos requisitos de uso: especificar quais serão os critérios para
se definir a Qualidade no Uso que o sistema deve atingir e, com isso, serem observa-
dos durante os testes. Para especificar qualidade, é preciso pensar em uma forma de

identificar e medir a eficiência, a produtividade e a satisfação, bem como os critérios

para identificar a aceitabilidade do software.
3) Monitorar a Qualidade no Uso: avaliar a qualidade do software durante as várias
etapas que fazem parte do processo de desenvolvimento. As informações obtidas por
meio das avaliações serão decisivas para identificar quais serão as modificações na
interface e em toda a interação.
4) Avaliar a Qualidade no Uso: estar em um ambiente que faz parte do contexto real é
importante, pois a melhor forma de avaliar essa qualidade é realizar testes no próprio
ambiente em que o software será utilizado, sendo assim, observar a utilização do sof-
tware no local em que o usuário irá utilizá-lo.
Sugerimos que você procure responder, discutir e comentar as questões a seguir que tra-
tam da temática desenvolvida nesta unidade.
A autoavaliação pode ser uma ferramenta importante para você testar o seu desempenho.
Se você encontrar dificuldades em responder a essas questões, procure revisar os conteúdos estu-
dados para sanar as suas dúvidas. Esse é o momento ideal para que você faça uma revisão desta
unidade. Lembre-se de que, na Educação a Distância, a construção do conhecimento ocorre de for-
ma cooperativa e colaborativa; compartilhe, portanto, as suas descobertas com os seus colegas.
unidade:
1) Uma característica que todo software deve ter é a qualidade, pois, garantindo a qualidade, se garante que o que
foi feito é bom, eficiente e eficaz. No entanto, considerar a qualidade em todas as fases de desenvolvimento
nem sempre é uma tarefa trivial. Nesse contexto, existe um framework que permite aos profissionais pensarem
em qualidade considerando cada parte do desenvolvimento. De maneira geral, existem três tipos de qualidades,
que são:
I – Qualidade Externa: observa o funcionamento do código durante a codificação, com o intuito de observar a
organização e a linguagem que foram utilizadas.
II – Qualidade Interna: observa se o que foi implementado está de acordo com os requisitos definidos.
III – Qualidade no Uso: observa o software que está sendo utilizado pelo usuário para identificar possíveis
erros, dificuldades etc.
c) A alternativa correta é I e II.
d) As alternativas corretas são II e III.
e) As alternativas corretas são I, II e III.
2) Ao considerar a qualidade em todo o desenvolvimento do software, você estará agregando a ele algumas carac-
terísticas de suma importância para o seu sucesso. Relacione essas características e seus significados a seguir:
(1) Aumento da eficiência. ( ) Permitir ao usuário realizar suas atividades
em um menor tempo com mais facilidade.
(2) Melhora na produtividade. ( ) Ter todas as funcionalidades e fazer que
elas sejam acessíveis e intuitivas, para que o
usuário possa gostar do sistema e continuar
utilizando.
(3) Redução de erros. ( ) Apoiar o usuário na realização de suas
atividades de tal forma que ele não possa se
confundir com a maneira que ela deve ser feita
utilizando o software.
(4) Redução no treinamento. ( ) Suprir as necessidades do usuário permi-
tindo que ele realize, por meio do software, as
tarefas desejadas.
(5) Aumento da aceitabilidade. ( ) Fazer que o software se torne tão simples e

intuitivo que o usuário conseguirá utilizá-lo sem
problemas.
Gabarito
Depois de responder às questões autoavaliativas, é importante que você confira o seu
desempenho, a fim de que possa saber se é preciso retomar o estudo desta unidade. Assim, con-
fira, a seguir, as respostas corretas para as questões autoavaliativas propostas anteriormente:
1) d) As alternativas corretas são II e III

(2) (5) (3) (1) (4)
9. CONSIDERAÇÕES
É possível perceber que as três qualidades e os três fatores a mais que devem ser consi-
derados na Qualidade no Uso – característica, objetivo e contexto – de alguma forma estão des-
critos nas unidades anteriores. No entanto, eles também serão especificados com mais detalhes
nas próximas unidades. Esse cuidado em descrever as qualidades em detalhes está diretamente
relacionado com suas influências para uma melhor interação humano-computador, uma vez
que a não consideração delas significa, na maioria das vezes, uma interface de má qualidade e,
consecutivamente, uma interação difícil e não proveitosa.
As três qualidades estão diretamente relacionadas com a forma com que se planeja, de-
senvolve e testa o software, e, para que isto seja feito de forma satisfatória, é necessário seguir
um modelo de processo para desenvolver um software, considerando as etapas estrategica-
mente definidas para apoiar todos os profissionais nesse desafio de atingir as qualidades. Nesse
contexto, a próxima unidade possui a descrição de alguns modelos de processos que podem ser
considerados.
10. EͳREFERÊNCIAS
ISO_A – INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. About ISO. Disponível em: < http://www.iso.org/iso/about.
htm>. Acesso em: 29 jun. 2010.
ISO_B – INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 14000 essentials. Disponível em: <http://www.iso.org/
iso/iso_catalogue/management_standards/iso_9000_iso_14000/iso_14000_essentials.htm>. Acesso em: 29 jun. 2010.
ISO_C – INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9241-171:20Disponível em: <http://www.iso.org/iso/
iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39080>. Acesso em: 29 jun. 2010.

BEVAN, N. Quality in Use: meeting user needs for quality. In: Journal of System and Software, 1999.
SOUZA, L. S.; SPINOLA, M. M. Requisitos de usabilidade em projetos de interface centrado no usuário de software de dispositivos
móveis. Fortaleza-Brasil In: Associação Brasileira de Engenharia de Produção. ENEGEP, 2006.

EAD
Modelos de Processo de
Software e Prototipação
1. OBJETIVOS
• Entender os modelos de processo de software.
• Conhecer uma forma de projetar um sistema centrado no usuário.
• Entender a prototipação.
2. CONTEÚDOS
• Modelos de processo de software.
• Modelo em "cascata".
• Desenvolvimento evolucionário.
• Desenvolvimento incremental.
• Desenvolvimento em espiral.
• Projeto Centrado no Usuário.
• Prototipação.

guir:
1) Você iniciará seus estudos sobre os modelos de processo de software. Aqui, terá a
oportunidade de perceber o cuidado que há no desenvolvimento de um software,
pois é preciso levar em consideração os seus futuros usuários e as suas respectivas
habilidades e dificuldades. No entanto, antes de prosseguir esta leitura, é necessário

que você reflita sobre em qual etapa desses modelos se preocuparia com as caracte-
rísticas que envolvem o usuário.
2) Com base no conteúdo "Projeto Centrado no Usuário", que será estudado nesta uni-
dade, pesquise outras formas de desenvolvimento de softwares, considerando as ca-
racterísticas dos usuários e consultando os livros e os sites indicados na bibliografia
deste Caderno de Referência de Conteúdo. Aprofunde seus conhecimentos nesta área!
Pesquise, também, sobre o Design Participativo, um conceito que tem crescido na
área acadêmica no Brasil.
3) Nesta unidade, você irá estudar a prototipação. Seria interessante conhecer mais so-
bre o uso atual dessa estratégia para o desenvolvimento de software tanto nas empre-
sas quanto nas universidades.
4) Você irá perceber que, no decorrer dos seus estudos, sua experiência no desenvolvi-
mento de software será de grande importância. Notará, também, que alguns ques-
tionamentos lhe auxiliarão a entender os conceitos que serão abordados e a como
futuramente utilizá-los:
• Você já desenvolveu algum software?
• Qual é o tipo que foi desenvolvido?
• Quando isto ocorreu, você já conhecia a interface humano-computador ?
• Em que momento se preocupou com as características dos usuários?
A preocupação em desenvolver um software de qualidade e, isso inclui considerar as pes-
soas, as suas características, suas habilidades e suas dificuldades no desenvolvimento de siste-
mas aumentou de maneira significativa nos últimos anos. Como você pôde observar na unidade
2, à medida que a evolução dos computadores acontecia, a forma de interagir com eles se modi-
ficava, embora não no mesmo ritmo, já que o hardware evoluiu em uma velocidade maior.
Atualmente, é perceptível essa preocupação, especialmente por causa da concorrência
entre os sistemas computacionais e as empresas de desenvolvimento de software. As pessoas
que implementam sistemas estão cada vez mais preocupadas com a qualidade e atentas para
essa diferença, que se torna significativa na escolha pelo usuário do melhor sistema e, conse-
quentemente, na sua aquisição. Contudo, apesar de ser importante identificar as características
dos usuários, a maneira com que eles realizam as atividades, pensam e desenvolvem todos os
outros fatores humanos, não é uma tarefa trivial.
É necessário pensar e estar muito atento a essas características desde o início do desenvol-
vimento de software, como descrito na unidade anterior. No entanto, a coleta dessas informações,
dependendo da forma que será feita, poderá causar constrangimento ou alguma insegurança
aos usuários, que, simplesmente, mesmo que inconscientemente, poderão não apoiar essa fase
importante.
A seguir, você conhecerá alguns cuidados que os usuários têm para se expressar e falar o
que pode ser mudado ou não, como também uma estratégia para evitar esse tipo de constrangi-
mento e atitude, afinal, você precisa do usuário para conhecê-lo e desenvolver uma ferramenta
útil e usável.
Como o assunto que estudaremos nesta unidade está diretamente relacionado ao de-
senvolvimento de software, serão apresentados, inicialmente, alguns modelos de processo de
software comuns na literatura e em muitas empresas.
© U4 – Modelos de Processo de Software e Prototipação 69
5. MODELOS DE PROCESSO DE SOFTWARE

O processo de software é um conjunto de atividades para a produção de sistema compu-
tacional. O processo envolve o desenvolvimento de um sistema do início ao fim. Há vários tipos
de modelos de processo de software, porém todos possuem algumas etapas em comum, tais
como (SOMMERVILLE, 2003):
• Especificação de software: é preciso definir a funcionalidade do software e as restri-
ções em sua operação.
• Projeto e implementação de software: o software deve ser produzido de modo que
cumpra sua especificação.
• Validação de software: o software precisa ser validado para garantir que ele faz o que
o cliente deseja.
• Evolução de software: o software precisa evoluir para atender às necessidades mutá-
veis do cliente.
O estudo desses modelos não é algo diretamente relacionado à IHC, pois eles se preo-
cupam mais com os requisitos e com as funcionalidades do sistema do que com o usuário. No
entanto, é necessário conhecer e entender esses modelos, pois eles são importantes para o de-
senvolvimento do sistema. Afinal, há a necessidade de se preocupar com o usuário, assim como
com as funcionalidades e outros aspectos relacionados ao sistema.
O objetivo de apresentar os modelos é para que você possa conhecer as etapas de de-
senvolvimento de software sem a ênfase na IHC, para, depois, entender como a IHC pode ser
aplicada em cada uma das etapas, pois, diferentemente do que muitas pessoas acreditam, não
se deve começar a pensar na IHC no meio ou no final do desenvolvimento do sistema, temos de
pensar na interação desde o início.
Quatro processos de software serão apresentados a seguir, no entanto, não há uma regra
de que é necessário seguir o mesmo processo do início ao fim do sistema, pois, especialmen-
te em grandes sistemas, é natural que processos diferentes sejam utilizados para desenvolver
partes distintas do sistema. Cada processo possui características, vantagens e desvantagens que
devem ser consideradas na escolha de um determinado processo para utilizar durante todo o
desenvolvimento do software ou somente em partes dele.
Modelo em "cascata"
O modelo em "cascata" possui esse nome devido à sequência em cascata de uma fase
para a outra, a qual não pode ser alterada. Esse modelo defende que você só pode passar para
a outra etapa depois que realizou, de maneira satisfatória, a etapa atual. As principais etapas
do modelo, apresentadas na Figura 1, retratam as atividades de desenvolvimento fundamentais
(SOMMERVILLE, 2003):

Fonte: SOMMERVILLE, 2003, p. 38.

Figura 1 Modelo em "cascata".
Agora, descreveremos cada etapa do modelo em "cascata", segundo Sommerville, 2003:
Análise e definição de requisitos

A etapa de análise e definição de requisitos é considerada a principal, pois todas as etapas
posteriores seguem o resultado obtido nela, ou seja, os requisitos e o objetivo do sistema com
as suas restrições e funcionalidades. É possível levantar os requisitos por meio da análise dos
documentos existentes na empresa, do software legado, como também, por meio da consulta
aos usuários.
Projeto de sistemas e de software

Após a análise de todo o resultado obtido na etapa anterior, é elaborada uma arquitetura
do sistema geral agrupando os requisitos em sistemas de hardware ou de software. O objetivo
está em utilizar todas as informações coletadas na etapa anterior para definir uma arquitetura
que defina como será o modelo computacional.
Implementação e teste de unidades

No estágio de implementação e teste de unidades, inicia-se a implementação do sistema
considerando a arquitetura definida. Há a possibilidade de implementar as funcionalidades em
unidades de programa. Portanto, no final, há o teste de unidades em que cada unidade é testada
para validar se atende à sua especificação.
Integração e teste de sistemas

As unidades já testadas e validadas são integradas de modo a compor um sistema com-
pleto. Posteriormente, é realizado um teste em todo o sistema para garantir que os requisitos
de software foram atendidos. Depois dos testes, o software é entregue ao cliente.
Operação e manutenção
O sistema é instalado na máquina do cliente para iniciar a sua operação. Nesse momento,
é comum encontrar erros que não foram identificados anteriormente, por isso, há, nessa fase, a
manutenção que se preocupa em corrigir tais erros. Na manutenção, também há a possibilidade
de melhorar o sistema e/ou agregar novas funcionalidades a ele.
Desenvolvimento evolucionário
O desenvolvimento evolucionário tem como objetivo inicial desenvolver uma implemen-
tação do sistema e apresentá-la para o usuário, caso tenha a necessidade de alterar algo nessa
implementação, é feita a modificação e, novamente, é apresentada ao usuário, ou seja, há vá-
rias versões para se aprimorar o sistema até que ele fique adequado. Tudo o que é feito durante
o processo é documentado, como você pode observar na Figura 2.
A abordagem evolucionária do desenvolvimento de software, muitas vezes, é mais eficaz
do que a abordagem em "cascata", pois o cliente tem contato direto com parte do sistema e
consegue observar e analisar se há algo errado ou que poderia ser mudado.
Outra característica positiva é que a especificação pode ser desenvolvida gradativamente,
pois, à medida que os usuários desenvolvem uma compreensão melhor de seus problemas, isso
pode ser refletido no sistema. Contudo, segundo Sommerville (2003), há três problemas, que
serão descritos a seguir:

Figura 2 Desenvolvimento evolucionário.
1) O processo não é visível: os gerentes necessitam que o desenvolvimento seja regular

para que possam medir o seu progresso. Se os sistemas são desenvolvidos rapidamen-
te, não é viável produzir documentos que reflitam cada versão dele.

2) Os sistemas, frequentemente, são mal estruturados: a mudança constante tende a

corromper a estrutura do software. Incorporar modificações no software é cada vez
mais difícil e oneroso.
3) As ferramentas e técnicas especiais podem ser exigidas: elas possibilitam o rápido
desenvolvimento, mas podem ser incompatíveis com outras ferramentas ou técnicas,
e poucas pessoas podem ter a habilitação necessária para utilizá-las.
Desenvolvimento incremental
Nesse tipo de desenvolvimento, os clientes estabelecem as partes do sistema com priori-
dade e o desenvolvimento inicia-se por essas partes. Após estabelecer as prioridades, é definida
uma série de estágios de entrega, com cada estágio, fornecendo um subconjunto das funciona-
lidades do sistema, conforme demonstrado na Figura 3.
Figura 3 Desenvolvimento incremental.
A alocação de funções aos estágios depende da prioridade da função. Dessa forma, o

cliente tem acesso às partes mais importantes antes. Como é gastado um tempo significativo
para testar, após a conclusão de uma parte do sistema, ele poderá ser colocado em operação.
Isso significa que o cliente recebe com antecedência parte da funcionalidade do sistema, ou
seja, ele pode experimentar o sistema, o que facilita uma melhor compreensão dos requisitos
da parte que está em desenvolvimento e das partes posteriores.
Dentre as vantagens desse tipo de desenvolvimento, duas serão citadas (SOMMERVILLE,
2003):
1) O cliente não precisa receber todo o sistema para poder aproveitá-lo. O primeiro está-
gio satisfaz seus requisitos importantes e, assim, o software pode ser imediatamente
utilizado.
2) Há um risco menor de fracasso completo do sistema, ou seja, mesmo que possam ser
encontrados problemas em algumas partes, é provável que outras sejam entregues
com sucesso ao cliente.
Esse tipo de desenvolvimento também possui algumas desvantagens, as principais estão
relacionadas à definição de um tamanho fixo das partes. Se falarmos de linhas de código, não
podem ser mais do que 20 mil linhas, e cada parte deve produzir alguma funcionalidade. Devido
a esta regra, há a dificuldade de mapear os requisitos dos clientes dentro de partes tão peque-
nas.
Desenvolvimento em espiral
O modelo de desenvolvimento em espiral, como o próprio nome diz, é representado por
um espiral ao invés de representar o processo de software como uma sequência de atividades
com algum retorno de uma atividade para outra, como você pode observar na Figura Cada loop
na espiral representa uma fase do processo de software. Assim, o loop mais interno pode estar
relacionado à viabilidade do sistema; o loop seguinte, à definição de requisitos do sistema; o
próximo loop, ao projeto do sistema e assim por diante.

Figura 4 Desenvolvimento em espiral
Cada loop da espiral é dividido em quatro setores (SOMMERVILLE, 2003):

Definição de objetivos
A principal tarefa desse setor é definir os objetivos para essa fase do projeto. Consideran-
do os objetivos, são identificadas as restrições para o processo e o produto. Com base nessas
informações é preparado um plano de gerenciamento detalhado que inclui todos os possíveis
riscos do projeto.
Avaliação e redução de riscos
Para cada um dos riscos identificado no setor anterior é necessário realizar uma análise
detalhada com o objetivo de identificar estratégias para reduzi-lo ou evitá-lo. Por exemplo, se
houver um risco de os requisitos serem inadequados, poderá ser desenvolvido um protótipo,
afinal, por meio dele o projetista poderá apresentar ao cliente a sua ideia para receber críticas,
sugestões, enfim refinar o que foi coletado.

Desenvolvimento e validação
Após a avaliação dos riscos e estratégias definidas, é escolhido um modelo de desenvolvi-
mento para o sistema. Por exemplo, pode ser utilizado o modelo em cascata, o modelo evolu-
cionário etc. Não há a necessidade de utilizar o mesmo modelo em todos os loops, uma vez que
se deve escolher o melhor modelo para cada objetivo.
Planejamento
No setor de planejamento, o projeto todo é analisado para verificar o que foi realizado
e planejar quais serão os próximos passos para continuar com o loop da espiral ou finalizar o
sistema, caso ele estiver completo. Se a decisão for continuar, serão traçados os planos para a
próxima fase do projeto.
Além da sua representação em espiral, esse modelo distingue-se dos outros por se preo-
cupar com os riscos, ou seja, com algo que pode acontecer de errado.
Como você deve ter observado, todos os modelos apresentados até aqui estão direcio-
nados em investigar os requisitos do sistema, analisar todas as informações obtidas por meio
dessa investigação para projetar, implementar e testar o sistema. No entanto, pouco comenta-se
sobre a maneira com que se deve conversar com o cliente e quais são os passos que devem ser
realizados para facilitar essa comunicação, com o intuito de permitir a obtenção de informações
sobre as características dos usuários, as suas necessidade e outros dados.
É por esse motivo que alguns pesquisadores dizem que a Engenharia de Software (ES),
área em que esses modelos foram desenvolvidos, enfatiza o software e não as pessoas que o
irão utilizar, pois a ênfase é nos requisitos do sistema e não nas características dos usuários.
Contudo, a Interação Humano-Computador tem como principal característica preocupar-se com
os usuários e observar quais são as suas características físicas e cognitivas que poderiam ser
utilizadas no sistema.
Assim, sempre que alguém for desenvolver um sistema, é preciso unir essas duas áreas
importantes para construir um sistema computacional com qualidade. Nesse contexto, a técni-
ca Projeto Centrado no Usuário será descrita em detalhes a seguir, para você ter uma visão de
como é possível conhecer e coletar as informações a respeito do usuário.
Informação! ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Muitas dúvidas estão relacionadas à ordem de aplicação dos modelos (ES) e das técnicas (IHC). Qual deverá ser
aplicado primeiro? Devemos nos preocupar, antes, com o sistema ou com o usuário?
A resposta é que devemos aplicar, ao mesmo tempo, um modelo e uma técnica, pois, unindo essas duas áreas, será
possível investigar os requisitos do software e, ao mesmo tempo, observar as dificuldades e as características dos
usuários. As duas áreas devem ser aplicadas em todo o desenvolvimento, pois, assim, quando chegar ao final, será
possível testar o software de acordo com ES e IHC.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
6. PROJETO CENTRADO NO USUÁRIO ΈUCD ͵ USERͳCENTERED DESIGNΉ

O Projeto Centrado no Usuário tem como principal característica pensar no usuário e em
todo o seu processo de desenvolvimento, ou seja, leva em consideração que o usuário está no
centro das decisões, por isso, na maioria das vezes existe a participação dele em todo o processo
de software.
Vale ressaltar que não podemos confundir ter o usuário participando do desenvolvimento,
com querer que ele saiba todos os problemas e soluções, afinal, como descreve Nielsen (2010a)
"os usuários não são projetistas, e projetistas não são usuários". Nesse contexto, também temos
outra preocupação, por exemplo, quando o usuário está envolvido com suas atividades há mui-
tos anos e, praticamente, realiza suas atividades de modo "automático", ou seja, sem a neces-
sidade de pensar muito devido à sua prática, ele tende a abstrair muito todas as atividades que
ele realiza. Por isso é muito comum ouvirmos "gostaria de automatizar o controle de estoque"
ou "estou com um problema no controle" etc. Informações genéricas que, para os projetistas,
são importantes, mas não tão significativas, pois é preciso entender como é feito o controle de
estoque, quais são os passos, quais são as atividades mais e menos importantes, quais são as
dificuldades, qual processo é mais simples ou complexo etc.
Outro erro é perguntar diretamente aos usuários o que eles querem, observe que, muitas
vezes, eles estão com um problema e percebem, por meio de conversa entre amigos ou por notí-
cias, que a tecnologia pode ajudar em suas atividades, mas eles não são projetistas e, na maioria
das vezes, não conhecem a tecnologia e todo o seu potencial. Por isso, evitar essa pergunta é
importante, afinal, é você que tem o conhecimento da tecnologia, mas, para saber a melhor
maneira de utilizá-la, vai precisar entender o usuário e os seus problemas.
No Projeto Centrado no Usuário, há a preocupação com a colaboração entre o projetista
e o usuário, uma vez que os dois possuem conhecimentos que devem ser compartilhados, en-
tretanto, o projetista não precisa explicar sobre a linguagem de programação. Por meio dessa
colaboração, o projetista pode entender a experiência do usuário em suas atividades, as infor-
mações com que ele trabalha e, com isso, planejar como será o sistema.
Assim como IHC, que estudamos na primeira unidade, o UCD também abrange várias áre-
as, dentre elas a IHC e sua preocupação em entender as características físicas e psicocognitivas
dos usuários, os fatores humanos etc. e outras áreas, como a Engenharia de Usabilidade, que se
preocupa em entender os objetivos dos usuários, desenvolver interfaces para eles etc. (WILLIA-
MS, 2009).
Assim como nos Modelos de Processos de Software, o UCD também possui algumas eta-
pas para auxiliar o projetista nesse contato com o usuário, com o intuito de permitir melhor
entrosamento, compreensão e colaboração entre eles.
O UCD está dividido em três etapas, a primeira, chamada de Design Research, está relacio-
nada a entender os usuários e suas necessidades; a segunda, denominada de Design, tem como
objetivo projetar a interface e todos os outros elementos do software que fazem parte da inte-
ração humano-computador; e a última, Design Evaluation, permite testar o que foi planejado e
desenvolvido com o usuário. Agora, detalharemos cada uma das etapas (WILLIAMS, 2009).
Design Research
Essa primeira etapa é subdividida em alguns passos que serão descritos a seguir:
Planning
Nesse primeiro passo, que é o planejamento, identifica-se o objetivo, as restrições e as
suposições do projeto, bem como, define-se quem são os stakeholders, ou seja, as pessoas en-
volvidas. Observe que esse passo tem importância significativa para a continuidade do proces-
so, pois precisamos conhecer os objetivos, as restrições e as suposições para sabermos o que
vamos planejar. Lembre-se de que essas informações são obtidas e observadas com os usuários,
por isso há necessidade de se definir quem são as pessoas envolvidas.

Em uma empresa, há várias pessoas, com diversos cargos e especialidades, e você precisa
saber quem são as pessoas importantes. Neste caso, as pessoas não são apenas os usuários
finais dos sistemas (empregados), mas, sim, os donos da empresa ou outras pessoas que podem
não usar diretamente o sistema, porém estão totalmente ligadas com o problema a ser solucio-
nado e os objetivos da utilização da tecnologia na empresa.
Definir os stakeholders também é importante para conduzir o projeto até o final, pois, nos
próximos passos, você perceberá que conhecer as pessoas envolvidas permitirá a você conver-
sar e mostrar resultados de acordo com a característica e necessidade de cada um, afinal, uma
pessoa de marketing tem objetivos e um olhar diferente de uma pessoa da área financeira.
Enquanto uma está preocupada em apresentar e vender o produto, a outra está preocupada
em contabilizar tudo o que está acontecendo, sendo assim, a conversa e a forma de exibir os
resultados para cada uma será completamente diferente.
Conducting
O segundo passo está voltado a conduzir a investigação na empresa, conhecer as ativida-
des das pessoas e como elas realizam essas tarefas. Há várias técnicas para se conhecer o usu-
ário, entretanto, para apresentar uma técnica muito comum, é necessário que você saiba que,
antes de conversar diretamente com o usuário, você precisa conhecer um pouco da empresa,
da linguagem que é utilizada entre as pessoas, como também, permitir que elas te conheçam
um pouco, pois isso permitirá que vocês se entrosem, de forma que elas tenham liberdade para
falar dos problemas, do que elas gostam ou não, sem a preocupação de serem avaliadas.
Algo comum que pessoas sentem nas empresas ou em qualquer outro estabelecimento
é o medo de serem avaliadas. A maioria delas pensam que se "falarem mal" de algum processo
ou atividade o chefe ficará sabendo e, consequentemente, ela poderá ser demitida, por isso,
muitas pessoas não gostam de conversar, de falar dos problemas etc. Em contrapartida, se a
pessoas te conhecem e confiam em você, elas saberão que está na empresa para ajudá-las,
para entender o que está acontecendo, quais são as dificuldades e as facilidades do processo, e
que todas essas informações são importantes para aprimorar e facilitar as tarefas que elas estão
realizando.
Assim, antes de tudo, conheça as pessoas, converse com elas, tomem um cafezinho, afi-
nal, um ambiente descontraído pode ajudar muito nesse momento. Essa estratégia é chamada
de background research, ou seja, uma pesquisa para conhecer as pessoas não precisa de forma-
lidade, pode ser algo descontraído, porém sério e com um objetivo definido.
Uma técnica muito comum e que já foi citada anteriormente é a entrevista, pois, por meio
dela, é possível ter contato com as pessoas, perguntar e/ou observar a forma com que elas rea-
lizam alguma atividade etc. Lembre-se de que há vários tipos de pesquisas, cada uma com uma
abordagem diferente, por exemplo:
• Face-to-face interviews:
Com a face-to-face interwiews, ou entrevista presencial, você pode conversar com a pes-
soa, fazer perguntas, ouvir suas respostas "face a face", ou seja, não precisa de outros recursos,
como o papel, por exemplo, para que a pessoa responda nele, sem contar que, há, ainda, a
possibilidade de gravar a entrevista, desde que você tenha a permissão. O interessante dessa
pesquisa é que, ao contrário do que acontece quando respondem no papel, as perguntas podem
sofrer alterações dependendo das respostas, pois, por meio, delas você pode ter interesse em
conhecer mais detalhes de um determinado assunto e/ou atividade, porém, da mesma forma
que acontece quando é no papel, é necessário um planejamento, ou seja, um conjunto de per-
guntas pré-estabelecidas.
• Close–and open-questions:
Close-and open-questions é uma entrevista, que, geralmente, acontece com o auxílio do
papel, por meio de um questionário. Você define algumas perguntas, que podem ser objetivas
ou dissertativas, para que as pessoas respondam, embora haja a limitação de não poder adaptar
as próximas perguntas de acordo com as respostas, essa estratégia é muito utilizada quando
há a necessidade de se entrevistar uma quantidade grande de pessoas, como, por exemplo,
todas as pessoas de um determinado setor. Se você for entrevistar uma por uma, precisará de
tempo e dinheiro, porém, muitas vezes, não se tem esses recursos suficientes. Por isso, quando
é necessário entrevistar várias pessoas, alguns projetistas costumam aplicar esse questionário
para obter uma média das respostas e, com base nelas, fazer um questionário face-to-face com
algumas pessoas, para saber mais detalhes ou esclarecer algo que ficou pendente.
• Remote interviews
Remote interviews, ou entrevista remota, ocorre quando você não tem a possibilidade de
um encontro presencial com a pessoa, então, a entrevista pode ser feita utilizando o telefone, a
internet ou qualquer outro meio que lhe permita ter contato com ela. Essa técnica é utilizada,
por exemplo, quando a pessoa que se deseja entrevistar está viajando para participar de uma
reunião de negócios.
• In-person interview.
Na entrevista do tipo in-person interview, você faz uma pergunta para a pessoa e ela res-
ponde fazendo uma determinada atividade, ao invés de responder com palavras (falando ou
escrevendo), ou seja, se você pergunta como é feito um determinado processo, ela explicará
realizando esse processo. Por meio dessa entrevista pode-se acompanhar todos os detalhes,
desde o comportamento do indivíduo até os objetos que ele utiliza.
Todas essas entrevistas são realizadas com os stakeholders, ou seja, as pessoas envolvidas
no processo e para cada pessoa será direcionada um tipo de pergunta, de acordo com sua fun-
ção e sua especialidade.
É importante descrever que, com a utilização dessa técnica, você conhecerá a pessoa,
suas atividades, a maneira que ela pensa, entre outras características para ajudá-lo a planejar
e a desenvolver o sistema. Contudo, há um problema muito comum entre os projetistas. No
momento em que você conhece as atividades, seu primeiro pensamento será aproveitar todo o
processo manual e aplicar no computacional, mas tome cuidado, não desenvolva o sistema para
ser meramente uma reprodução das atividades que as pessoas realizam manualmente. Toda
essa estratégia ajudará você a conhecer as capacidades e a forma com que as pessoas desempe-
nham uma atividade, porém o computador tem um potencial muito grande para facilitar a vida
das pessoas (KEINONEN, 2008).
Importante: –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Pense sempre na palavra "mapear" e não na palavra "copiar", ou seja, não copie o que o usuário fez no manual para
o computacional, mas mapeie a atividade que ele fez, pois assim, se o computador puder facilitar um determinado
processo, ou mudar a forma com que algo é feito para ajudar o usuário, será ótimo. Não se limite ao que você vê ou
ouve, compreenda e use todas as informações da melhor forma possível.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Analyzing
O terceiro passo, chamado analyzing, consiste em analisar todos os dados coletados nos
passos anteriores, com a utilização de várias técnicas descritas na literatura como análise quan-
titativa e/ou qualitativa (WILLIAMS, 2009). Você deverá organizar todas as informações, decidir

quais são as prioridades, o que deve ser feito, o que precisa ser mudado, suas propostas, enfim,
todas as informações necessárias para, depois, conversar com as pessoas.
Reporting
Esse passo, o reporting, é justamente a conversa com as pessoas sobre tudo o que você co-
letou e sua análise sobre as informações. Você pode fazer uma apresentação e/ou escrever um
relatório com os principais dados. Uma dica para facilitar essa conversa é considerar o stakehol-
der, ou seja, se você for conversar com alguém da administração, planeje e faça algo utilizando
uma linguagem própria e assuntos que vão interessar às pessoas dessa área, e assim por diante.
Você já sabe quais são as necessidades e a linguagem que deve ser utilizada para cada área, por
causa dos passos anteriores, então, utilize essas informações para que as pessoas compreen-
dam e se interessem pelo que você vai falar.
Design
O Design é a segunda etapa do Projeto Centrado no Usuário. Nessa etapa, ocorre a conso-
lidação de todas as informações obtidas até esse momento. Tal consolidação pode ser realizada
por meio dos primeiros desenhos da interface. Esses desenhos são feitos de acordo com as in-
formações obtida e pelas conversas feitas durante esta etapa.
Há várias formas de fazer esse primeiro esboço, uma delas é apresentada no próximo tó-
pico, chamada Prototipação, uma estratégia usada para desenhar a interface, pensar como será
a interação entre o sistema e o usuário, definir a navegação etc.
Design Evaluation
Design evaluation é a terceira e última etapa do Projeto Centrado no Usuário. Essa etapa
será a avaliação de tudo o que foi investigado, feito e representado por meio do Design. Ela
pode ser feita com auxílio do usuário, pois, assim, no final da avaliação, você terá a certeza de
que tudo aquilo que foi planejado e realizado está de acordo com as necessidades e as carac-
terísticas do usuário. Se o indivíduo entender o design e conseguir trabalhar com ele, mesmo
por intermédio de protótipos, a possibilidade de interagir com a ferramenta computacional será
bem maior, ou seja, a certeza de construir um sistema com qualidade é elevada.
Vale a pena ressaltar que há maneiras de avaliar o Design sem a ajuda do usuário, são
estratégias que, ao serem aplicadas, indicam se o usuário conseguirá utilizar o sistema de modo
eficaz ou não.
Algumas estratégias para realizar a avaliação são:
• Heurística.
• Questionário de satisfação.
• Percurso cognitivo.
• Revisão pelos usuários.
Há, também, várias outras estratégias para avaliar o sistema. Na Unidade 4, você conhe-
cerá algumas delas e a forma de aplicá-las para verificar a qualidade do sistema que está sendo
planejado.
Todas as etapas explicadas anteriormente ajudarão você a entender quais são os momen-
tos propícios para conversar com as pessoas, quais são as estratégias que podem ser utilizadas,
tanto para coletar as informações a respeito do usuário, quanto para testar com ele o sistema.
Perceba que, apesar de parecer simples conversar com uma pessoa para explicar o que se
pretende fazer, quais serão as atividades etc., não é trivial, uma vez que você tem conhecimen-
tos e experiências diferentes. É comum acontecer de conversar com o cliente e, aparentemente,
ele entender tudo e dizer que gostou da proposta do sistema, das suas funcionalidades etc.,
mas, no momento em que você apresenta, de fato, o sistema, ele percebe que pensou bem
diferente do que realmente aconteceu.
Isso é algo comum de acontecer, pois, por mais detalhes que tentemos dizer durante al-
guma explicação, é difícil saber o que a outra pessoa está entendendo e imaginando, por isso,
a seguir, estudaremos uma estratégia, chamada de prototipação, que irá auxiliá-lo muito nessa
discussão, pois você terá um recurso concreto, simples e familiar para apresentar ao usuário.
7. PROTOTIPAÇÃO
A prototipação tem como finalidade demonstrar as ideias e as características de funcio-
namento do sistema por meio de desenhos, sejam eles "rabiscos" no papel ou interfaces bem
próximas do real, feitas com ferramentas que permitem esboçar a interface de uma maneira
semelhante ao sistema final.
O uso de protótipos possibilita mostrar a interface, o processo de interação com as fun-
cionalidades e os botões, de uma maneira fácil de se compreender. Por meio dessa informação
concreta o usuário poderá não apenas entender, mas também contribuir com segurança, ex-
pressando o que gostou ou não, quais são as funcionalidades fácies e eficazes de se utilizar etc.
Conforme Pressman (2002), a prototipação é uma estratégia utilizada tanto na área da
Engenharia de Software (ES) quanto na Interação Humano-Computador (IHC), porém para cada
uma há uma finalidade distinta em sua utilização. Na ES, a preocupação está na compreensão
dos requisitos do sistema, como ele será desenvolvido do ponto de vista tecnológico, se há to-
das as funcionalidades necessárias etc. Já na IHC a preocupação está relacionada com o modelo
de interação entre o usuário e o sistema, ou seja, quais tarefas serão realizadas por meio do
sistema, como elas serão apresentadas, se as opções existentes estão relacionadas com o ma-
peamento natural do usuário etc.
Essa estratégia também é muito utilizada no início do processo de desenvolvimento para
conversar com cliente, sendo que há várias formas de utilizá-la, você pode levar um desenho
pronto para ser discutido, ou pode, simplesmente, levar papel e lápis e, durante a conversa,
esboçar um desenho etc.
Classificações de Prototipação
São três os tipos de protótipos: baixa-fidelidade, média-fidelidade e alta-fidelidade. Como
você poderá observar na leitura das classificações que descreveremos a seguir, a principal dife-
rença entre eles, está no nível de fidelidade.
Baixa-Fidelidade
Protótipos que não são semelhantes ao sistema final, na maioria das vezes, são feitos com
auxílio do papel e lápis, como demonstrado na Figura 5, para esboçar as características iniciais
da interface e o seu funcionamento auxiliando na conversa entre o projetista e os usuários sobre
as características desejáveis e as soluções mais adequadas.

Figura 5 Protótipo feito em papel, com canetinha.
Por causa do tipo de material utilizado para elaborar esses protótipos, eles são mais bara-
tos, rápidos e fáceis de fazer e, por meio deles, é possível coletar muitas informações a respeito
dos requisitos da interface. Algumas desvantagens estão relacionadas com a não utilização do
protótipo nas etapas posteriores, a verificação limitada de erros etc. (OLIVEIRA, 2004 .
Média-fidelidade
Como você verá na Figura 6, o resultado desse tipo de prototipação é mais próximo do
sistema final, se comparado com a baixa--fidelidade. Geralmente, são feitos utilizando ferra-
mentas computacionais, embora não precisem ser as mesmas ferramentas que serão utiliza-
das para desenvolver a ferramenta final; permitem simular o comportamento de interação da
interface e não requerem um mesmo conhecimento técnico necessário para implementar a
interface final.
Há algumas ferramentas que podem ser utilizadas para desenvolver protótipos nesse nível
de fidelidade, algumas delas são: Smart Draw (Wireframe, 2010), Axure (Axure, 2010), Microsoft
Office Visio, entre outras.
Alta-fidelidade
Com esse tipo de protótipo é possível elaborar uma interface semelhante ao produto final,
Figura 7, pois, geralmente, são utilizadas as mesmas matérias (software e hardware) que serão
utilizadas no final, uma vez que são desenvolvidos diretamente em linguagem de programação,
permitindo apresentar alguns recursos da interface com a interação. Na prototipação de alta-
fidelidade já existe a implementação de algumas partes do sistema.
Devido a essas características, esse tipo de protótipo é considerado com um alto grau de
interatividade com os usuários e de realismo, pois é possível ver e interagir com uma interface
próxima à final. No entanto, há um custo maior no seu desenvolvimento e já é necessário um
conhecimento técnico semelhante àquele para desenvolver o produto final.
Dentre as três classificações de prototipação, esta unidade abordará detalhadamente a
primeira, a prototipação em papel. A princípio, a escolha dessa classificação pode parecer estra-
nha, pois, aparentemente, ela é a mais simples e quase sem recursos.
Na verdade, essa escolha é um pouco diferente daquilo que algumas pessoas pensam na
hora de apresentar um projeto, afinal, sempre queremos apresentar o melhor, então, porque
apresentar algo no papel feito com lápis ou caneta se podemos fazer um protótipo próximo ao
real com a interface bonita, navegação, entre tantas outras características que poderiam chamar
a atenção das pessoas com que estivéssemos conversando?
A resposta é tão simples quanto um ditado muito conhecido: menos, muitas vezes, é mais.
Observe que, apesar de parecer simples, não é trivial um usuário comum entender o raciocínio
de um programador ou projetista. Nesse caso, o desenho (protótipo) passa a ser uma linguagem
comum entre eles, pois quando se vê algo é muito mais fácil entender do que apenas ouvir e
tentar imaginar o que a outra pessoa está pensando.
Com o desenho a ideia fica mais "palpável" (fácil de entender) e o usuário, abstraindo me-
lhor, poderá contribuir e dizer se está gostando ou não. Nesse caso, o papel é um potencial a
mais, porque é uma ferramenta que todos dominam, tanto projetistas quanto usuários comuns. O
usuário pode manipular o papel, rabiscar e modificar de uma forma simples. Quando o protótipo
é feito com uma ferramenta computacional, mesmo que seja "mais bonito", cria-se uma barreira
entre o usuário e o projetista, pois a computação é algo mais distante dos usuários e eles não têm
tanto controle.
Outro cuidado que devemos ter com os protótipos feitos com auxílio do computador está
na hora de conversar com o usuário, pois, na maioria das vezes, mesmo explicando-lhe que é
apenas um protótipo, ele insiste em acreditar que o sistema está quase pronto, ou seja, que
aquilo que ele está vendo (interface, navegação entre telas etc.) já é o sistema pronto, e, então,
será fácil e rápida a entrega e os custos serão menores. Essa é uma situação muito comum, o
usuário sempre quer tudo muito rápido, pois ele cria uma expectativa ao ver algo pronto, bonito
e no computador.
Quando você for utilizar esses protótipos computacionais, também terá de se preocupar
em conhecer alguma linguagem para desenvolvê-lo, preparar o ambiente para apresentá-lo,
levar o computador etc., o que poderá deixar a conversa mais complicada, pois, antes, seriam
necessários apenas as pessoas, o papel e a caneta.
Com o protótipo em papel, o cliente consegue perceber de uma maneira fácil que tudo é
apenas uma ideia e que está sendo feito um esboço para entender melhor o que ele pensa, per-
mitindo que fique à vontade para expressar-se, dizer suas opiniões, ou seja, rabiscar, também,
o papel.
Prototipação em papel
O conceito de prototipação tornou-se comum na década de 1990, quando começou a ser
utilizado por algumas empresas como a IBM, Digital e a Microsoft como uma parte do processo
de desenvolvimento de produtos (SNYDER, 2003). No entanto, somente em 2002 houve o cres-
cimento do uso da prototipação, tanto nas empresas grandes, quanto nas pequenas.
O uso da prototipação em papel

Se considerarmos o Projeto Centrado no Usuário, estudado anteriormente, um momento
propício de se utilizar a prototipação é na etapa do Design, momento em que você já conhece
quem são os usuários, quais são as possíveis funcionalidades e possui algumas informações para
auxiliá-lo a mapear o que acontece no real para o virtual. Com esses dados é possível esboçar
os primeiros desenhos, no entanto, não há uma etapa definida, pois não terá problema se, na
primeira conversa, alguém pegar um papel e desenhar o que as pessoas estão discutindo.
Snyder (2003) relata alguns passos que podem ser utilizados para criar, apresentar e testar
um protótipo, são eles:
• Definir os stakeholders (pessoas envolvidas) para elaborar as interfaces, conforme
apresentado na Figura
Figura 8 Preparando o laboratório para o teste.
• Escolher algumas das tarefas que o usuário realizará com apoio do sistema a ser proje-
tado.
• Realizar o esboço da interface, que poderá conter menus, páginas, caixas de diálogo,
mensagens e outras características para permitir ao usuário desempenhar as funções
na tarefa, como na Figura
Figura 9 Protótipo em papel com alguns campos.

Realizar testes de usabilidade com o protótipo

• Definir uma pessoa para representar os stakholders.
• Pedir para essa pessoa realizar uma determinada tarefa, utilizando o protótipo em pa-
pel – algo semelhante ao natural, pressionar o papel para simular um clique no botão,
preencher em um retângulo o nome para simular um cadastro etc., conforme o apre-
sentado pela Figura
Figura 10 Um usuário realizando alguns testes no protótipo.
• Um ou dois dos membros da equipe têm de desempenhar as funcionalidades do com-

putador, ou seja, se uma pessoa clica em um botão e a próxima tela está em um pró-
ximo papel, então o membro deve trocar as folhas para o usuário ter acesso à outra
interface do sistema, como se estivesse navegando.
• Um membro (experiente em usabilidade) deve conduzir o teste enquanto os outros
observam se há alguma dificuldade e como o usuário interage com o protótipo. Após a
realização desse teste é possível identificar em quais interfaces o usuário teve dificul-
dade, em quais momentos ele não soube como prosseguir etc.
Algumas empresas com prestígio no desenvolvimento de aplicativos web estão investindo
em protótipos em papel para explicar a todos as funcionalidades de seus sistemas. Um exemplo
de sucesso foi realizado pela empresa Google na explicação do Google Docs. Por meio de um
protótipo em papel, os funcionários da empresa conseguiram explicar, de uma maneira diverti-
da e didática, o funcionamento da ferramenta para todos os usuários da web. Algumas imagens
podem ser observadas nas Figuras 11 e
Figura 11 Protótipo em papel para explicar a ferramenta Google Docs.

Figura 12 Funcionamento do Google Docs.
Humano-Computador.
você encontrar dificuldades em responder a essas questões, procure revisar os conteúdos estu-
dados para sanar as suas dúvidas. Este é o momento ideal para que você faça uma revisão desta
unidade. Lembre-se de que, na Educação a Distância, a construção do conhecimento ocorre
de forma cooperativa e colaborativa; compartilhe, portanto, as suas descobertas com os seus
colegas.
unidade:
1) De maneira geral, há a possibilidade de dizermos que existem três etapas para o desenvolvimento de um sof-
tware: a análise, o desenvolvimento e o teste. Para cada etapa, há um amadurecimento não apenas das funcio-
nalidades e das opções existentes na interface, mas também na compreensão das características dos usuários.
Durante as primeiras etapas, é possível aplicar uma estratégia chamada "prototipação" para facilitar a compre-
ensão tanto das características dos usuários quanto das funcionalidades do sistema. Considerando os conceitos
aprendidos nesta unidade, relacione, a seguir, as opções que indicam em que momento você utilizaria cada tipo
de prototipação.
( 1 ) Baixa-fidelidade ( ) Observar a forma com que o usuário

percebe a interface e refinar os requisitos.
( 2 ) Média-fidelidade ( ) Permitir ao usuário interagir com algo
próximo do sistema real para analisar as
dificuldades que podem ser encontradas.
( 3 ) Alta-fidelidade ( ) Conhecer o usuário e descobrir as fun-
cionalidades requeridas por ele, bem como
a forma com que elas podem ser apresen-
tadas.
2) Ao considerar o usuário o centro do desenvolvimento do sistema, é possível perceber melhor suas caracterís-
ticas e suas necessidades, para que o software seja realmente adequado. No entanto, conseguir a cooperação
do usuário nem sempre é uma tarefa trivial. Se você percebesse alguma resistência por parte do usuário em lhe
ajudar, o que consideraria a melhor opção para convencê-lo?
I) Conversar com o usuário de forma que ele possa entender a importância de sua participação no desenvolvi-
mento do sistema, uma vez que ele é um dos beneficiados com um software de qualidade.
II) Lembrar o usuário de que você é um contratado da empresa e de que uma de suas obrigações é ajudá-la
em todos os projetos nos quais se envolver – o desenvolvimento do software é um deles, portanto, é obrigado a
cooperar.
III) Acompanhar o usuário em seu ambiente de trabalho e tentar, em alguns momentos, abordá-lo de forma
amigável e questioná-lo sobre suas atividades na empresa, com o intuito de identificar algumas funcionalidades
no sistema e a forma com que ele trabalha.
c) A alternativa correta é III.
d) As alternativas corretas são I e II.
e) As alternativas corretas são I e III.
Gabarito
(2) (3) (1)
2) e.
9. CONSIDERAÇÕES
Apesar de não ser uma tarefa fácil preocupar-se com os usuários no desenvolvimento de
sistemas, é fundamental que exista essa preocupação. Há várias razões que justificam esse in-
vestimento de tempo e dinheiro.
Segundo Nielsen (1994), quando os usuários interagem com o sistema de forma satis-
fatória, eles se tornam leais a esse sistema ao ponto de fazer alguns investimentos, tais como
adquiri-lo e, depois, pagando pelas atualizações e modificações necessárias.
Os usuários tendem a valorizar mais os sistemas que possuem uma interface boa e utilizá-
vel, uma vez que a forma de se utilizar o sistema, em muitos casos, é mais importante do que a
quantidade de funcionalidades e recursos existentes nele, ou seja, há uma vantagem competiti-
va se comparado a sistemas em que não se considera a preocupação com o usuário.
Há, também, outra vantagem que, muitas vezes, só é percebida após a finalização e a en-
trega do sistema. Essa vantagem é a minimização dos custos posteriores. Os projetistas preocu-
pam-se mais com os custos que envolvem os processos de software durante o desenvolvimento
e com as características mais voltadas para o sistema, porém, é necessário pensar que se o
usuário não entender ou não o conseguir utilizar haverá um gasto maior com treinamento para
usar o software e até com modificações, mesmo após a entrega.
Pensar no usuário em todo o processo e testar exaustivamente o software para garantir a
qualidade é uma tarefa aparentemente árdua, mas é uma estratégia comprovadamente eficaz
para garantir um sistema aceitável e usável, por isso, na próxima unidade, você conhecerá algu-
mas formas de avaliar o sistema considerando as técnicas de IHC.
10. EͳREFERÊNCIAS
AXURE. Wireframes. Disponível em: <http://www.axure.com/tourWireframe.aspx>. Acesso em: 5 fev. 2010.
NIELSEN, J. Bridging the Designer–User Gap. Disponível em: <http://www.useit.com/alertbox/designer-user-differences.html>.
Acesso em: 23 mar. 2010.

WIREFRAME. SmartDraw – Create a wireframe or site map in minutes. Disponível em: <http://www.smartdraw.com/specials/
ppc/wireframe.htm?id=41822&gclid=COn63cH6z58CFYZx5QodJCj23A>. Acesso em: 5 fev. 2010.
Lista de figuras
Figura 3 – Desenvolvimento incremental: disponível em: <http://inf.unisul.br/~pacheco/princ_eng_sw/02_Artigo.pdf>. Acesso
em: 02 mar. 2010.
Figura 5 – Protótipo feito em papel, com canetinha: disponível em: <http://www.uxbooth.com/blog/tools-for-sketching-user-
experiences/>. Acesso em: 05 mar. 20
Figura 6 – Protótipo de média-fidelidade: disponível em: <http://usabilidoido.com.br/quanto_mais_simples_o_wireframe_
melhor.html>. Acesso em: 05 mar. 2010.
Figura 7 – Protótipo de alta-fidelidade: disponível em: <http://usabilidoido.com.br/quanto_mais_simples_o_wireframe_
melhor.html>. Acesso em: 05 mar. 2010.
Figura 8 – Preparando o laboratório para o teste: disponível em: <http://www.nngroup.com/reports/prototyping/video_stills.
html>. Acesso em: 1 jan. 2010.
Figura 9 – Protótipo em papel com alguns campos: disponível em: <http://www.nngroup.com/reports/prototyping/video_
stills.html>. Acesso em: 1 jan. 2010.
Figura 10 – Um usuário realizando alguns testes no protótipo: disponível em: <http://www.nngroup.com/reports/prototyping/
video_stills.html>. Acesso em: 1 jan. 2010.
Figura 11 – Protótipo em papel para explicar a ferramenta Google Docs: disponível em: <http://www.youtube.com/
watch?v=eRqUE6IHTEA>. Acesso em: 21 mar. 20
Figura 12 – Funcionamento do Google Docs: disponível em: <http://www.youtube.com/watch?v=eRqUE6IHTEA>. Acesso em:
21 mar. 2010.

KEINONENM, T. User-centered design and fundamental need. Lund - Suécia. The 5th Nordi conference on Human-computer
interaction: building bridges, 2008.
NIELSEN, J. Heuristic Evaluation. In: NIELSEN, J; MACK, R. Usability Inspection Methods. John Wiley & Sons, 19p. 25-
OLIVEIRA, N. A. A. IHC: Modelagem e gerência de interfaces com o usuário. Florianópolis: Visual Books, 2004.
PRESSMAN, R. S. Engenharia de Software. USA: McGraw-Hill, ed. 2002.
SNYDER, C. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. San Francisco: Morgan Kaufmann, 20
SOMMERVILLE, I. Engenharia de Software. USA:Prentice-Hall, ed. 20
WILLIAMS, A. User-centered design, activity-centered design, and goal-directed design: A review of three methods for designing
web applications. Bloomington - EUA In: Special Interest Group on Design of Communication (SIGDOC), 2009.
EAD
Métodos para Avaliação da
Interface
1. OBJETIVOS
• Conhecer os conceitos para avaliar a interface.
• Entender a Avaliação Heurística.
• Compreender os Checklists.
• Conhecer e entender o Percurso Cognitivo.
2. CONTEÚDOS
• Introdução aos Métodos:
• Avaliação Heurística.
• Percurso Cognitivo.
• Checklist.
• Teste de Usabilidade.
• Percurso Pluralístico.
• Modelo GOMS.
• Questionários.
• Explicação dos métodos em detalhes:
• Avaliação Heurística.
• Checklist.

guir:
1) Leia, atentamente, todos os métodos apresentados nesta unidade e se preocupe em
compreender as características de cada um e a diferença entre eles. Essas informações
lhe ajudarão a escolher o melhor método para avaliar a interface de seu software.
2) Pesquise em livros e/ou na internet mais informações sobre esses métodos descritos
aqui e tantos outros que existem. Ao pesquisar, preocupe-se, inicialmente, em enten-
der o conceito do método e investigue pesquisadores e/ou empresas que o utilizaram,
bem como o resultado obtido. Lembre-se de que você é protagonista do processo
educativo.
3) Fique atento ao site de um pesquisador muito conhecido na área de IHC: Nielsen
<http://www.useit.com/jakob/>. Frequentemente, há novas postagens sobre novida-
des nessa área, incluindo novos métodos para avaliação de interface e testes para
observar a sua aplicabilidade.
4) Não deixe de comentar com seus colegas de curso e com o tutor o que você aprendeu
nesta unidade e em suas leituras complementares. O ponto de vista de cada um é mui-
to importante para a construção de um conhecimento colaborativo e significativo.
Desenvolver sistemas pensando e considerando o usuário em todo o seu processo é uma
característica importante para se construir um aplicativo que seja útil e atenda às suas necessi-
dades, ou seja, que não tenha somente as funcionalidades desejadas, mas que elas sejam visí-
veis e compreensíveis. Como você pôde perceber na unidade anterior, há a possibilidade de unir
a Engenharia de Software (ES) e a Interação Humano Computador (IHC). Dessa forma, podemos
desenvolver sistemas nos preocupando com as suas funcionalidades, hardware etc., bem como,
com as pessoas que os irão utilizar.
Depois dessa etapa, de pensar e considerar a ES e a IHC para planejar e desenvolver sis-
temas, vem outra, que tem como objetivo validar e verificar se, realmente, o que foi planejado
está sendo feito e, especialmente, analisar se o que está pronto é usável (termo relacionado
à facilidade que o sistema proporciona ao usuário para que esse alcance os seus objetivos na
interação), é útil, qual é a facilidade que o sistema proporciona ao usuário para alcançar os seus
objetivos na tarefa (CYBIS et al., 2003), se é acessível e se tem facilidade de acesso e de uso de
sistemas por qualquer pessoa e em diferentes contextos (GODINHO, 2010).
Nessa etapa, também há estratégias para avaliar o sistema sob a ótica da ES e da IHC.
Nesta unidade, serão apresentados alguns métodos para avaliar o sistema, considerando os
conceitos da IHC. A Figura 1, apresentada a seguir, ilustra alguns dos métodos existentes para
essa avaliação.
• Nielsen (1994) dividiu os métodos em três categorias: métodos analíticos ou de inspe-
ção, que não envolvem a participação dos usuários, ou seja, que os próprios projetistas
ou profissionais na área de IHC aplicam; métodos empíricos ou teste com usuários,
que envolvem a participação direta dos usuários em todo o processo de avaliação; e
Outras formas, métodos que envolvem maior rigor de avaliação no que se diz respeito
a dados quantitativos, como o modelo GOMS ou Questionários, que envolve o usuário,
porém não em todo o processo.
© U5 – Métodos para Avaliação da Interface 89
Figura 1 Métodos para Avaliação.
Avaliação Heurística: esse método tem como objetivo examinar a interface e julgá-la de
acordo com os princípios reconhecidos de usabilidade. Esse método pode ser aplicado por um
pequeno grupo de avaliadores (geralmente cinco), por isso é considerado rápido e barato, logo
no início do ciclo de desenvolvimento, por exemplo, no protótipo em papel.
Alguns métodos, em sua aplicação, já possuem estratégias para identificar os erros e apon-
tar as melhorias, ou seja, explicitam o que poderia ser feito para resolver os erros ou melhorar
a interface. Nesse método, em especial, não está inclusa a proposta de melhorias, embora elas
possam ser feitas como resultado da avaliação ou da discussão entre os avaliadores.
Percurso Cognitivo: esse método também pode ser aplicado no início do desenvolvimen-
to. O profissional precisa simular passo a passo o comportamento de um determinado usuário
em uma tarefa, por isso ele precisa conhecer bem quem é o usuário, as suas características, as
habilidades e as deficiências, pois diante de uma determinada interface, ele tentará executar
uma determinada tarefa como se fosse o usuário. Esse método já possui as propostas de melho-
rias, ou seja, como resultado dessa avaliação, há a necessidade dos problemas identificados e as
possíveis soluções para eles (MANO; CAMPOS, 2004).
Checklist: é um conjunto de itens que devem ser considerados na avaliação da interface
para observar se ela está, ou não, em conformidade com tais itens. Um dos objetivos do Che-
cklist é permitir aos projetistas e/ou profissionais na área da IHC verificarem se o conteúdo e as
opções existentes na interface estão acessíveis aos usuários (CYBIS et al., 2003).
Teste de Usabilidade: tem como finalidade observar o usuário executando alguma(s)
atividade(s) em um determinado sistema. Esse é o principal ponto positivo desse teste, pois
nada melhor do que ver o usuário em ação para perceber quais são as dificuldades, as facili-

dades etc. Entretanto, ele tem que ter um objetivo definido, pois, durante o teste, tudo pode
acontecer, e é necessário, desde o início, saber o que se quer observar para poder prestar mais
atenção ao que interessa. Esse teste é realizado durante ou no final do desenvolvimento, pois,
normalmente, é feito com o protótipo de alta-fidelidade ou com o sistema implementado (NIEL-
SEN, 1994).
Percurso Pluralístico: esse método permite avaliar uma sequência de interfaces (percur-
sos de interação) com várias pessoas (pluralístico), dentre elas a equipe de IHC, o projetista e o
usuário. O método funciona da seguinte maneira: existe uma sequência de telas e, ao observá-
as, os usuários, escrevem ou falam quais seriam as ações necessárias para executar uma deter-
minada tarefa, definida por projetista ou por um profissional em IHC. Em seguida, há uma troca
de informações sobre o que o usuário falou e o que o projetista planejou com aquelas telas. Essa
troca de informações é intermediada pelo profissional de IHC, possibilitando, assim, perceber
quais são os erros, se o que o projetista planejou realmente foi realizado pelo usuário etc. Ao
final de cada tarefa é discutida e apresentada a maneira que era esperada para que ela fosse
realizada e somente depois de todos entenderem como é o procedimento correto ou definirem
uma nova maneira de realizá-la poderá prosseguir para a próxima tarefa.
GOMS – Goals (Objetivos), Operators (Operadores), Methods (Métodos) e Selection ru-
les (Regras de seleção): esse método não envolve a participação do usuário. Ele estipula um
tempo possível para que um usuário possa tomar uma decisão, como, por exemplo, pensar em
clicar num botão, encontrar um botão, arrastar o mouse, clicar em um botão etc. É definido um
operador para cada passo que o usuário precisa fazer para realizar uma ação e a cada operador
é atribuído um valor, assim, o tempo de cada ação pode ser calculado por meio da soma dos
valores atribuídos a cada operador necessário para executar a ação. O tempo definido para o
operador encontra-se na literatura (JOHN; KIERAS, 1996). No final, o resultado são as ações, os
operadores e o total de tempo para realizá-las.
Questionários: trata-se de um conjunto de questões apresentados aos usuários (podem
ser de múltipla escolha). Por meio desse método é possível identificar facilmente as preferên-
cias, as satisfações e as ansiedades dos usuários. Há várias maneiras de aplicar os questionários,
algumas delas foram estudadas na Unidade 3 na seção Projeto Centradas no Usuário.
Cybis et al. (2003) descrevem que foram realizados testes com alguns dos métodos de
avaliação, descritos, anteriormente, com intuito de desenvolver um estudo comparativo dos
desempenhos alcançados por diferentes avaliadores, usando métodos distintos para a avaliação
da usabilidade, da utilidade e da acessibilidade. Todos os métodos realizados tiveram sua aplica-
ção e seus resultados registrados.
A taxa custo x benefício (medida em quantidade e severidade de problemas identificados
por hora de avaliação) foi melhor em dois métodos: Avaliação Heurística e Checklist. Devido a
esses resultados positivos e à comprovação da eficiência desses dois métodos, se comparados
aos outros, nesta unidade descreveremos cada um detalhadamente, explicando a maneira de
aplicá-los, os resultados obtidos etc. Vale ressaltar que, apesar desses resultados positivos, todos
os métodos possuem qualidades que devem ser levadas em consideração na hora de escolher o
melhor para se aplicar, pois, dependendo da situação e da necessidade outro, se sobressairá.
Outro método que será discutido nesta unidade é o Percurso Cognitivo, que, além de
ser uma estratégia muito utilizada pelos pesquisadores, possui características importantes para
que, mesmo sem a presença dos usuários, os profissionais de usabilidade possam perceber a
facilidade ou dificuldade que os usuários teriam para interagir com o software.
5. AVALIAÇÃO HEURÍSTICA
A Avaliação Heurística é um método de inspeção que visa identificar problemas conforme
um conjunto de heurística. Esse método foi proposto por Jacob Nielsen e Rolf Molich em 19Essa
avaliação pode ser aplicada em especificações em papel, protótipos de baixa, média ou alta-
-fidelidade ou em sistema final. É necessário um pequeno número de avaliadores (geralmente,
entre três e cinco) para examinar e julgar a interface (NIELSEN, 1994).
Curiosidade!––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
O grupo de Nielsen e Norman cobra até 35.000 dólares por uma avaliação heurística em um website. Vale lembrar,
como dito anteriormente, que esse método não inclui a proposta de melhoria, por isso, caso essa proposta ocorra, é
preciso deixar bem claro para o cliente que é algo a mais que se está fazendo, ou seja, o custo para se realizar essa
avaliação pode aumentar ainda mais.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Fases para aplicar a Avaliação Heurística

Geralmente, a Avaliação Heurística ocorre em três fases, contudo, como descrito anterior-
mente, há a possibilidade de aumentar uma fase chamada Melhorias, em que haverá algumas
propostas de melhorias, como você pode observar na Tabela 1.
Tabela 1 Fases para aplicar a Avaliação Heurística (NIELSEN, 1994).

FASES CARACTERÍSTICAS
Uniformização da terminologia.
Sessão de Pré-Avaliação Introdução ao domínio da aplicação.
Apresentação do cenário, protótipo ou aplicação.
Avaliação individual e independente.
Avaliação Navegar pelo sistema no mínimo duas vezes.
Relatar quais heurísticas foram violadas
Características principais da interface.
Problemas de usabilidade identificados.
Discussão dos avaliadores
Severidade dos problemas encontrados.
Elaboração de um relatório contendo: problemas e severidade.
Melhorias Sugestão de modificações
1ª Fase – Sessão de Pré-avaliação: nessa fase, os avaliadores devem reunir-se para conhe-
cer o cenário, o protótipo ou a aplicação. Geralmente, um profissional especialista nesse cenário
ou aplicação é quem fica responsável por mostrá-la aos avaliadores. Essa fase é importante para
que os avaliadores esclareçam todas as suas dúvidas em relação ao que será avaliado, afinal,
com um bom entendimento de todas as características, necessidades etc., será possível uma
boa avaliação.
Os avaliadores também devem discutir cada uma das dez heurísticas, que estudaremos
a seguir e que serão utilizadas para avaliar o sistema. Essa etapa é importante, para que todos
cheguem a um consenso do que é cada heurística e como ela deve ser avaliada, isso evita que
um avaliador pense e avalie uma heurística diferentemente dos demais, pois essa diferença na
forma de avaliar, muitas vezes, não gera resultados satisfatórios.
2ª Fase – Avaliação: a avaliação deve ser feita individualmente, ou seja, cada avaliador
deve avaliar a interface sozinho. Essa avaliação é feita com, pelo menos, duas navegações no

sistema, a primeira navegação para conhecer o sistema e a segunda para verificar se alguma das
dez heurísticas está sendo violada. Vale ressaltar que para cada heurística violada o especialista
deve definir uma severidade e a forma de aplicá-la, o que estudaremos adiante. No final, cada
especialista terá uma tabela com as heurísticas violadas e suas respectivas severidades.
3ª Fase – Discussão dos avaliadores: os avaliadores discutem as principais características
da interface as heurísticas violadas encontradas e as suas severidades, ou seja, cada avaliador
apresenta a sua tabela e discute sobre ela com os demais. Nessa discussão, cada avaliador po-
derá dizer se concorda ou não com a heurística e a sua severidade, e, assim, todos juntos criam
uma tabela que possui o consenso de todas as heurísticas e as severidades, ou seja, o resultado
é uma tabela final contendo as heurísticas e severidades que todos concordaram.
Importante: –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
É importante lembrar que isso não significa unir as tabelas de cada avaliador, pois uma heurística encontrada por um
pode não ser pertinente aos demais ou uma severidade definida por um pode não ser a melhor, por isso é importante
a discussão.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
4ª Fase – Melhorias: os avaliadores discutem as heurísticas violadas e as estratégias que
eles pensaram para melhorar a interface e, em um consenso, decidem qual é a melhoria que
pode ser aplicada.
6. AS DEZ HEURÍSTICAS
A seguir, apresentaremos as dez heurísticas refinadas por Nielsen (2002).
1ª Visibilidade do Sistema
Os usuários são informados sobre o progresso do sistema com a resposta apropriada den-
tro de um tempo aceitável?
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
O sistema deve informar aos usuários sobre o que está acontecendo, por meio de mensagens ou de elementos
de interface. Por exemplo, por meio de barra de progressão ou exibindo os passos que se tem para executar uma
tarefa.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
É sempre importante mostrar a quantidade de passos existentes, concomitantemente ao
passo que a pessoa está, por exemplo: Passo 2/Alguns sistemas, como o Contexteller (SILVA,
2009), exibem os passos de uma maneira diferente, como apresentado na Figura 2, pois, além
de exibir a quantidade de passos e em qual a pessoa está, exibem o nome do passo e por meio
dos botões "voltar" e "avançar" é possível saber o nome do passo anterior e do posterior. Assim,
fica fácil o usuário saber em que passo ele está, o que ele fez e o que ele fará.
Fonte: ANACLETO, 2010.

Figura 2 Visibilidade do sistema.
Fonte: SILVA, 2009, p. 59.

Figura 3 Tela Cadastrar Jogador do jogo Contexteller.

2ª Correspondência entre o sistema e o mundo real

O sistema usa conceitos e linguagens familiares aos usuários ao invés de termos técnicos?
Ele usa convenções do mundo real e apresenta as informações de maneira natural e em ordem
lógica?

Figura 4 Correspondência entre o sistema e o mundo real.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
O sistema deve falar a linguagem do usuário, com palavras, frases e conceitos familiares e não termos orientados
ao sistema.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
A linguagem utilizada em todo o sistema deve ser familiar ao usuário, por exemplo, é co-
mum encontrarmos sistemas web para vender produtos, em que a interface exibe o código do
produto no carrinho de compras. Observe que esse código não é algo familiar ao usuário, seria
mais fácil aparecer o nome do produto e/ou a foto dele. Nesse caso, o código é uma informação
desnecessária e que pode até confundir o usuário.
3ª Controle e liberdade do usuário

Os usuários podem fazer o que querem quando desejam?

Figura 5 Controle e liberdade do usuário.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Frequentemente, os usuários escolhem funções do sistema por tentativa-erro, então a interface deve deixar as saí-
das claramente marcadas ou dar suporte a desfazer ou refazer.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
O usuário precisa perceber que está no comando e que, a qualquer momento, ele pode
voltar, avançar, parar etc. Algo importante é ter na interface uma opção para voltar à página
principal (inicial), afinal, muitas vezes, essa é a pagina mais conhecida pelo usuário e, se durante
a navegação se sentir perdido ou um pouco confuso, ele pode voltar à página inicial. Essa ati-
tude é comum, pois, geralmente, os usuários voltam para perceber que continuam no mesmo
sistema e, vendo essa interface familiar novamente, eles se sentem seguros para continuar a
navegar.

4ª Consistência e padronização
Os elementos de design, como os objetos e as ações, têm o mesmo significado ou efeito
em situações diferentes?

Figura 6 Consistência e padronização.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
A interface não deve apresentar palavras, situações ou ações diferentes que possuam um mesmo significado.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Manter a padronização é uma característica fundamental para o sucesso da interface, pois
no momento em que o usuário se familiariza com algo, por exemplo, com um formato de botão,
ele conseguirá navegar no sistema e identificar todos os outros botões. Dessa forma, quando
ele encontrar algo com o formato semelhante terá a certeza de que poderá clicar e ter alguma
ação. Por isso, mantenha o padrão, se você definiu o formato de um botão, siga ele do início
ao fim do sistema. Outra preocupação é manter o padrão nas informações, então, evite ter na
interface botões, links ou palavras diferentes que possuam o mesmo significado ou que vão para
o mesmo lugar.
5ª Prevenção de erros
Os usuários cometem erros que não cometeriam em interfaces melhores?

Figura 7 Prevenção de erros.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Preocupação com o projeto do sistema para que os erros de interação não ocorram. Exemplo: indicação clara do
formato do dado esperado.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Algo muito útil para evitar erros, especialmente em cadastros, é informar ao usuário como
ele deve inserir os dados. Para tanto, podemos utilizar máscaras, como, por exemplo, "( )",
para ilustrar como deve ser inserido o número de telefone ou ". . –", para inserir o CPF etc. É
comum, também, encontrarmos um exemplo ao lado do campo, (99)9999-9999.

6ª Ajuda aos usuários para reconhecerem, diagnosticarem e se recuperarem de erros

As mensagens de erros são expressas em linguagem "plena" (sem códigos)? Elas descre-
vem exatamente o problema e sugerem uma solução?

Figura 8 Ajuda aos usuários.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Mensagens de erros devem ser expressas descrevendo o problema, sugerindo soluções e sem linguagem técnica.
As mensagens "Erro 404" ou "Você realizou uma operação ilegal", não são bons exemplos, ou seja, não descrevem
exatamente o problema.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Ao exibir uma mensagem de erro, informe ao usuário qual foi o erro e como ele deve ser
corrigido em uma linguagem natural. Pouco útil será uma mensagem de erro informando que
um determinado cadastrado foi realizado de maneira errada, por isso indique em qual campo foi
o erro e como ele deve ser preenchido corretamente.
7ª Reconhecimento em vez de memorização

Os elementos do projeto, como objetos, ações e opções, estão visíveis? O usuário é força-
do a lembrar informações de uma parte para outra do sistema?

Figura 9 Reconhecimento em vez de memorização.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
A interface deve ter os seus elementos de interface visíveis. O usuário não tem que se lembrar de informações de
uma parte para outra das interfaces do software.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Não conte com a memória do usuário para visualizar alguma informação em uma tela e
utilizá-la em outra, por exemplo, não é difícil encontrar sistemas que, em uma tela, mostram um
determinado produto (com código, descrição etc.) e seus tamanhos e, em outra tela, existirem
alguns campos para o usuário inserir o código do produto e o tamanho desejado. Observe que
o código não é algo natural para o usuário, ou seja, é difícil de ser memorizado, como também,
para esse caso, há a necessidade de memorizar o tamanho do produto. Evite esse tipo de si-
tuação e permita ao usuário fazer buscas. Assim, apenas com o nome do produto ele poderá
pesquisar e encontrar, automaticamente, o que quer. Após encontrá-lo, será exibido um campo
com todos os seus tamanhos possíveis, para que o usuário somente selecione o desejado.

8ª Flexibilidade e eficiência de uso

Os métodos das tarefas são eficientes e os usuários podem customizar ações frequentes
ou atalhos?

Figura 10 Flexibilidade e eficiência de uso.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Aceleradores ou atalhos devem estar presentes na interface para aumentar a velocidade de execução da tarefa para um usuário
experiente.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Apresentar o passo a passo é importante para os usuários iniciantes e intermediários, mas
os usuários experientes preferem pressionar "ctrl + n" para deixar um texto em negrito ao invés
de levar o mouse no botão N e clicar. De maneira semelhante, podemos pensar em outros siste-
mas que não processadores de texto. Temos de apresentar caminhos mais rápidos de se realizar
algo, pois os usuários, de acordo com a frequência de uso e a familiaridade com o sistema vão
preferir utilizá-los.
Ajude o usuário a preencher um campo. Por exemplo, se existirem os campos país, cidade
e estado para serem preenchidos, uma maneira de facilitar é permitir que o usuário selecione,
de uma lista, um país e, automaticamente, todos os estados daquele país aparecem como op-
ção para serem selecionados e, uma vez selecionado o estado, aparecem as cidades. Assim fica
muito mais fácil e rápido preencher algo.
9ª Design estético e minimalista

Os diálogos contêm informações irrelevantes ou raramente utilizadas?

Figura 11 Design estético e minimalista.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
As informações extras irrelevantes diminuem a visibilidade das informações importantes.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Evite informações desnecessárias, pois elas podem poluir a interface e dificultar a intera-
ção com o sistema. Exiba apenas o essencial e necessário. Evite, por exemplo, colocar muita pro-
paganda ou informações irrelevantes na interface, pois isso ajuda o usuário a desviar a atenção
do que ele realmente estava fazendo ou precisa fazer.

10ª Ajuda e documentação

Uma ajuda apropriada é fornecida? Essa informação é fácil de ser encontrada e enfocada
na tarefa do usuário?

Figura 12 Ajuda e documentação.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
A informação da ajuda deve ser útil e fácil de ser encontrada.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Observe que uma ajuda fácil e útil não é aquela em que há um botão com ponto de inter-
rogação e, ao ser clicado, aparece um texto imenso com as explicações. Afinal, poucos são os
usuários que querem ou que têm tempo de ler algo assim, é preciso uma ajuda sucinta, prática
e clara.
7. ESCALA DE SEVERIDADE
O valor da severidade define a gravidade do problema encontrado. Esse, varia de zero a
quatro, conforme demonstrado na Tabela 2 a seguir:
Tabela 2 Graus de Severidade

SEVERIDADE DESCRIÇÃO
0 Não concordo que o problema encontrado seja um problema de usabilidade.
1 Problema cosmético/superficial – precisa ser corrigido somente se um tempo estiver disponível.
2 Problema de usabilidade pequeno – esse problema possui uma baixa severidade para ser solucionado.
3 Problema de usabilidade grande – importante solucionar o problema, alta prioridade.
Catástrofe de usabilidade – imprescindível solucionar esse problema antes que o produto seja liberado
4
para comercialização.
Tabela Para Avaliação Heurística

A Tabela 3, apresentada a seguir, ilustra o formato da tabela que deve ser feita tanto na
avaliação individual quanto na avaliação final, em que todos os avaliadores se reúnem para ge-
rar uma tabela com o consenso de todas as heurísticas e severidades identificadas.
Tabela 3 Formato da Tabela da Avaliação Heurística.

NÚMERO HEURÍSTICA VIOLADA PROBLEMA SEVERIDADE
... ... ... ...
8. EXEMPLO DE APLICAÇÃO DA AVALIAÇÃO HEURÍSTICA

O exemplo ilustrado a seguir foi realizado no LIA – Laboratório de Interação Avançada da
Universidade Federal de São Carlos (UFSCar). A Avaliação Heurística foi realizada em uma ferra-
menta desenvolvida por pesquisadores do próprio laboratório, chamada Cognitor.
O Cognitor é um editor de material de aprendizagem para web, destinado a professores
com pouca experiência em editar conteúdo para Aprendizagem Eletrônica. Ele foi desenvolvido
tendo em mente os princípios pedagógicos para que o material gerado ofereça condições para
uma aprendizagem efetiva (CARLOS, 2007).
De maneira bem simples, é possível dizer que o Cognitor é um editor gráfico para páginas
web, em que o professor não precisa saber programar em HTML durante a elaboração de seu
material, pois o HTML é gerado automaticamente. No entanto, há outros recursos que ajudam
o professor na elaboração do material, pois o Cognitor apoia o professor para fazer um material
considerando alguns recursos cognitivos, a cultura, entre outras características dos alunos.
A seguir, é apresentada a aplicação da Avaliação Heurística na ferramenta Cognitor consi-
derando as três fases para aplicar a Avaliação Heurística, estudadas anteriormente.
1ª Fase – Sessão de Pré-avaliação

Nessa primeira fase, os pesquisadores que desenvolveram o Cognitor apresentaram e expli-
caram o objetivo do sistema. A apresentação foi feita utilizando a própria ferramenta, que, nesse
caso, foi avaliação no sistema final. A Figura 3 apresenta a interface principal do Cognitor.

Fonte: CARLOS, 2007, p. 18.

Figura 13 Tela inicial do Cognitor – Criando material.
Para se criar algum material é necessário clicar no botão "Cria/Edita" (representado pela
lâmpada) para iniciar. Após clicar no botão "Cria/Edita", é preciso definir os conceitos que serão
abordados no material de aprendizagem e realizar a sua organização. Para essa atividade, foram
definidos e organizados quatro conceitos, demonstrados na Figura Os botões do lado esquerdo
devem ser utilizados para a organização. À direita, é possível ver sugestões de conceitos cultu-
rais vindas de uma base de conhecimento de senso comum.
Fonte: CARLOS, 2007, p. 21.

Figura 14 Tela para definir e organizar conceitos.
Após a explicação do Cognitor, todos os avaliadores conversaram sobre como seria feita
a avaliação, ou seja, quais seriam as telas a serem avaliadas, quais as funcionalidades etc. e,
também, são discutidas cada uma das dez heurísticas e as suas severidades, pois, assim, todos,
durante a avaliação, teriam o mesmo conhecimento sobre elas.
Pode parecer simples, após ler as heurísticas e as suas severidades, pensar que todos os
avaliadores vão avaliar e aplicar as severidades da mesma maneira, mas se isso não for bem con-
versado, as chances de todos aplicarem essa estratégia seguindo um consenso são poucas, uma
vez que o que eu avalio como grave pode não ser tão grave para o outro. Por isso, é importante
que todos conversem sobre o que cada um entendeu das heurísticas e definam como vão aplicar
as severidades, que podem ser aplicadas em termos de:
• Frequência – comum ou raro?
• Impacto – fácil ou difícil para o usuário se recuperar?
• Persistência – ocorre apenas uma vez e os usuários sabem como lidar com ele?
• Impacto no mercado.
2ª Fase – Avaliação
Nessa fase, cada profissional avaliou a ferramenta e elaborou uma tabela, como apresen-
tada na Tabela 4.
Importante: –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
É comum, na primeira vez que alguém faz a avaliação heurística, pensar que deve encontrar em todo o sistema um
problema para cada heurística, ou seja, no final, a tabela contém apenas as dez heurísticas com um problema em
cada. Mas, isso está errado, pois você tem de olhar cada parte da interface e avaliar se essa parte violou alguma(s)
heurística(s), por isso é comum ter um botão violando duas ou três heurísticas, dependendo da forma que ele é
apresentado, o que está escrito nele etc.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Tabela 4 Tabela individual

HEURÍSTICA
NÚMERO PROBLEMA SEVERIDADE
VIOLADA
1 7 Não fica claro que a primeira opção é clicar na lâmpada. 4
O desenho da lâmpada não remete ao seu uso: criar
2 7 2
conceito.
Quando abre a janela "Estruturar Conhecimento", os botões
3 4 Incluir, Buscar e Deletar ficam disponíveis mesmo não tendo 1
nenhuma ação no momento.
Os botões para identar os conceitos, poderia ter alguma
4 7 explicação ao se passar o mouse sobre o desenho, porque 3
nem sempre o usuário vai entender o que eles significam.
Mesmo quando o conceito está em primeiro lugar o botão
de "subir o conceito" fica disponível, permitindo ao usuário
5 5 2
clicar e não ver nenhuma alteração.
(O mesmo ocorre com os outros botões).
Não há nenhum feedback quanto à posição dos elementos.
Por exemplo, quando chega à primeira posição e o usuário
continua clicando para o conceito subir, ele não é informado
6 10 2
que já chegou no "nível máximo" e o botão também não
desabilita.
(O mesmo ocorre com os outros botões).

HEURÍSTICA
NÚMERO PROBLEMA SEVERIDADE
VIOLADA
Quando se insere um conceito que não tem na base de senso
7 1 comum, como, atividade física, não existe nenhum feedback 2
informando que não há conceitos na base.
O usuário, por não ter o feedback, pode pensar que digitou
8 5 2
o conceito errado e tentar novamente.
No botão "lâmpada", aparece a mensagem "criar mapa de
9 4 conceitos" e, ao clicar nele, aparece uma janela chamada 1
"Estruturar conhecimento".
Ao clicar no botão "buscar conceitos relacionados", o usuário
10 5 precisa esperar um bom tempo para obter o retorno da resposta 3
e, enquanto isso, não há nenhum feedback.
Estruturar conhecimento – Passo 3 de 3 – o botão "remover
11 5 relações selecionadas", fica ativo mesmo não tendo 2
nenhuma relação.
Ao inserir a segunda figura, o Cognitor não reconhece em
12 8 que lugar a primeira estava e isso poderia economizar 1
tempo para encontrar a segunda foto.
Valores de altura e largura, ao inserir a figura, muitas vezes,
13 5 2
são desconhecidos dos usuários.
Não se sabe qual é a medida de altura e largura (centímetro,
14 2 2
metro etc.).
Não fica claro ao usuário que para alterar o tamanho da
15 7 4
figura tem de clicar na opção "objetos da página".
É difícil perceber que ao clicar em alguma opção de "objetos
16 7 da página", a alteração será em cima em "propriedades do 3
objeto".
17 3 Não há a possibilidade de alterar a figura com o mouse. 2
18 3 Não há a possibilidade de alterar a tabela com o mouse. 2
Não há a possibilidade de alterar o tamanho da tabela
19 3 4
depois de criada.
Criar tabela – não apresenta exemplos de largura da
20 7 borda, por isso, o usuário precisa memorizar as espessuras 2
disponíveis.
21 2 Termo desconhecido pelo usuário – Botão popUp. 1
22 2 Termo desconhecido pelo usuário – Botão analogia. 1
Quando selecionamos o texto e fazemos alguma modificação,
23 1 2
ele, aparentemente, perde a seleção.
Se o usuário clicar para mudar de cor, a alteração ainda
24 5 é feita, ele pode se confundir onde vai alterar em algum 2
momento.
Ao clicar na opção de cor a interface altera o idioma para
25 4 2
inglês.
O idioma da opção cor é diferente da conhecida pelo
26 2 1
usuário.
As propriedades de texto não seguem o padrão. N (negrito),
27 4 3
I (itálico) e S (sublinhado), por exemplo.
Só há três opções de fonte e as mais conhecidas (arial, times
28 3 1
new romam etc.) não aparecem.
29 3 Depois que se salva uma figura, não é possível alterá-la. 4
Não há nenhum tipo de ajuda para conhecer as opções do
30 10 3
Cognitor, tais como: Mapa de conceito, analogia etc.
A Tabela 4, demonstrada anteriormente, representa somente a tabela de um avaliador,

mas cada um tem que criar a sua tabela, ou seja, no final dessa fase, obtiveram cinco tabelas
com diversas heurísticas e severidades.
3ª Fase – Avaliação
Nessa fase, os avaliadores já conversaram e elaboraram, juntos, uma tabela que represen-
tasse a tabela de todos. É comum encontrarmos uma heurística que um avaliador considerou
como severidade 3 e, depois de uma conversa, chegaram à conclusão de que, na verdade, seria
severidade 1, ou ao contrário, por isso todos devem se entender e criar a tabela final.
É nesse momento, que se percebe melhor o uso da severidade "0", pois quando a ava-
liação é individual não tem sentido escrever um problema se o significado de sua severidade é
"Não concordo que o problema encontrado seja um problema de usabilidade". No entanto, na
tabela final, é comum essa severidade, caso todos entrem em um consenso de que uma heurís-
tica apontada por um avaliador não é de fato um problema de usabilidade.
9. CHECKLIST
Dentre os checklists existentes, citados por Nielsen (2000), Tahir (2002), Shneiderman
(1998), Cybis (2010) etc., esta unidade apresenta um conjunto feito pelo LabIUtil – Laborató-
rio de Utilizabilidade, localizado na Universidade Federal de Santa Catarina. Por meio destes
checklists é possível avaliar, inspecionar a interface e descobrir os seus defeitos, melhorando a
facilidade de uso e a utilidade dos sistemas computacionais.
Os checklists foram inseridos em uma lista chamada ErgoList. Nessa lista, há 18 grupos de reco-
mendações, que são descritos a seguir:
01 Presteza
Projete um sistema que informe e conduza o usuário na interação.
02 Agrupamento por localização
Certifique-se de que a distribuição espacial dos itens nas telas conduz os usuários na interação.
03 Agrupamento/distinção por formato
Use os formatos dos itens como meio de transmitir associações e diferenças.
04 Feedback
Forneça feedback imediato e de qualidade às ações do usuário.
05 Legibilidade
Garanta a legibilidade das informações apresentadas nas telas do sistema.
06 Concisão
Dimensione adequadamente os códigos e termos apresentados e introduzidos no sistema.
07 Ações Mínimas
Dimensione adequadamente os diálogos propostos para a realização dos objetivos do usuário.
08 Densidade Informacional
Garanta uma adequada densidade informacional das telas apresentadas pelo sistema.
09 Ações Explícitas
Certifique-se que é o usuário quem comanda explicitamente as ações do sistema.
10 Controle do Usuário
Forneça possibilidades para o usuário controlar o encadeamento e a realização das ações.

11 Flexibilidade
Permita que o usuário possa personalizar as apresentações e os diálogos.
12 Experiência do Usuário
Projete para usuários com diferentes níveis de experiência.
13 Proteção contra erros
Ofereça as oportunidades para o usuário prevenir eventuais erros.
14 Mensagens de erro
Garanta a qualidade das mensagens de erro enviadas aos usuários em dificuldades.
15 Correção de erros
Ofereça facilidades para que o usuário possa corrigir os erros cometidos.
16 Consistência
Garanta a coerência do projeto de códigos, telas e diálogos com o usuário.
17 Significados
Certifique-se que os códigos e denominações são claros e significativos para os usuários do sistema
18 Compatibilidade
Garanta a compatibilidade do sistema com as expectativas e necessidades do usuário em sua tarefa.
(Disponível em: <http://www.labiutil.inf.ufsc.br/ergolist/rec.htm>. Acesso em: 19 mar. 2010).
Além dos checklists, o LabIUtil teve o cuidado de criar mais dois módulos para auxiliar os
projetistas a entenderem cada item da lista e saberem a melhor maneira de avaliar a interfa-
ce. O primeiro módulo tem como objetivo apresentar de modo informal, as justificativas e as
questões que compõem o checklist. Esse módulo é chamado de Questões, o segundo módulo,
chamado de Recomendações, apresenta exemplos para auxiliar os projetistas nas decisões de
projeto de interfaces com o usuário.
A seguir, são apresentados cada um dos 18 itens da lista, citados anteriormente, junta-
mente com o módulo de Questões e Recomendações (CYBIS, 2010). Ao ler cada item, preste
atenção não apenas em suas características, para depois avaliar uma interface verificando se ela
atende ou não os checklists, mas, também, procure entender todos os itens, pois eles represen-
tam fundamentos básicos que todos os projetistas devem considerar para desenvolver sistemas
usáveis e úteis. Por isso considere esses itens não apenas para a avaliação, mas, especialmente,
quando você for desenvolver um sistema.
01 Presteza
Justificativa(s):
Uma boa presteza guia o usuário e lhe poupa, por exemplo, o aprendizado de uma série de comandos.
Ela permite, também, que o usuário saiba em que modo ou em que estado ele está, onde ele se encon-
tra no diálogo e o que ele fez para se encontrar nessa situação. Uma boa presteza facilita a navegação
no aplicativo e diminui a ocorrência de erros.
Exemplos de Recomendações:
• Dirigir a entrada de dados indicando o formato adequado e os valores aceitáveis (ex.:__/__/__).
• Exibir as unidades de medidas dos dados a digitar (cm , mm, m)
• Indicar todas as informações sobre o estado da interação.
• Para cada campo de dados, fornecer um rótulo.
• Indicar o tamanho do campo, quando ele é limitado.
• Quando necessário, fornecer no rótulo informações suplementares.
• Dar um título a cada janela.
• Fornecer ajuda on-line e orientação.
02 Agrupamento por localização
Justificativa(s):
A compreensão de uma tela pelo usuário depende, entre outras coisas, da ordenação dos objetos (ima-
gens, textos, comandos, etc.) que são apresentados. Os usuários irão detectar os diferentes itens mais
facilmente se eles forem apresentados de uma forma organizada (em ordem alfabética, frequência de
uso, etc). Além disso, a aprendizagem e a recuperação de itens serão melhoradas. O Agrupamento/
distinção por localização leva a uma melhor Condução.
• Organizar os itens em listas hierárquicas
• Organizar as opções de um diálogo por menus, em função dos objetos aos quais elas se aplicam.
• Quando várias opções são apresentadas, sua organização deve ser lógica, isto é, a organização deve
representar uma organização funcional, relevante ou significativa (ordem alfabética, frequência de
uso, etc.).
03 Agrupamento/distinção por formato

Justificativa(s):
Será mais fácil para o usuário perceber relacionamento(s) entre itens ou classes de itens, se diferentes
formatos ou diferentes códigos ilustrarem suas similaridades ou diferenças. Tais relacionamentos serão
mais fáceis de aprender e de lembrar. Um bom agrupamento/distinção leva a uma boa condução.
• Fazer uma distinção visual clara de áreas que têm diferentes funções (área de comandos, área de
mensagens, etc.).
• Fazer uma distinção visual clara dos campos de dados e seus rótulos.
04 Feedback
Justificativa(s):
A qualidade e a rapidez do feedback são dois fatores importantes para o estabelecimento de satisfação
e confiança do usuário, assim como, para o entendimento do diálogo. Esses fatores possibilitam que
o usuário tenha um melhor entendimento do funcionamento do sistema. A ausência de feedback ou
sua demora podem ser desconcertantes para o usuário. Os usuários podem suspeitar de uma falha no
sistema e podem realizar ações prejudiciais para os processos em andamento.
• Todas as entradas dos usuários devem ser mostradas, com exceção de dados sigilosos. Mesmo neste
caso, cada entrada deve produzir um feedback perceptível (por exemplo, símbolos como *).
• Seguindo a interrupção pelo usuário de um processamento de dados, mostrar uma mensagem garan-
tindo ao usuário que o sistema voltou ao seu estado prévio.
• Quando o processamento é longo, informações sobre o estado do processamento devem ser forneci-
das.
05 Legibilidade
Justificativa(s):
A performance melhora quando a apresentação da informação leva em conta as características cogni-
tivas e perceptivas dos usuários. Uma boa legibilidade facilita a leitura da informação apresentada. Por
exemplo, letras escuras em um fundo claro são mais fáceis de ler que letras claras em um fundo escuro;
texto apresentado com letras maiúsculas e minúsculas é lido mais rapidamente que texto escrito so-
mente com maiúsculas.
• Títulos devem ser centralizados.
• Rótulos devem estar em letras maiúsculas.

• Cursores devem se apresentar distintos dos outros itens.

• Quando o espaço para o texto for limitado, mostrar poucas linhas longas ao invés de muitas linhas curtas.
• Exibir texto contínuo em colunas largas de, ao menos, 50 caracteres por linha.
• A justificação à direita deve ser empregada se puder ser obtida por espaçamento, desde que sejam
mantidos espaçamentos proporcionais constantes entre e nas palavras, e espaçamento consistente
entre palavras de uma mesma linha.
• Ao exibir um texto, mantenha as palavras intactas, com o mínimo de hífens.
06 Concisão
Justificativa(s):
A capacidade da memória de curto termo é limitada. Consequentemente, quanto menos entradas,
menor a probabilidade de cometer erros. Além disso, quanto mais sucintos forem os itens, menor será
o tempo de leitura.
• Para dados numéricos, a entrada de zeros à esquerda não deve ser necessária.
• Se os códigos forem mais longos que 4 ou 5 caracteres, use mnemônicos ou abreviaturas.
• Permitir ao usuário entradas de dados sucintas.
• Quando uma unidade de medida está associada a um campo, inclua a unidade como parte do campo
de dados, em vez de fazer o usuário digitá-la.
07 Ações Mínimas
Justificativa(s):
Quanto mais numerosas e complexas forem as ações necessárias para se chegar a uma meta, a carga de
trabalho aumentará e, com ela, a probabilidade de ocorrência de erros.
• Minimize o número de passos necessários para se fazer uma seleção em menu.
• Não faça o usuário entrar com dados que poderiam ser gerados pelo computador.
• Evite entrada de comandos que exijam pontuação
• Para entrada de dados, exiba os valores default atuais nos campos apropriados.
• Quando várias páginas estiverem envolvidas, torne possível ir diretamente para uma página sem ter
que passar pelas intermediárias.
08 Densidade Informacional
Justificativa(s):
Na maioria das tarefas, a performance dos usuários piora quando a densidade de informação é muito
alta ou muito baixa. Nesses casos, é mais provável a ocorrência de erros. Itens que não estão relaciona-
dos à tarefa devem ser removidos.
A carga de memorização dos usuários deve ser minimizada. Eles não devem ter que memorizar listas
de dados ou procedimentos complicados. Eles não devem, também, ter que executar tarefas cognitivas
complexas quando estas não estão relacionadas com a tarefa em questão.
• Em qualquer transação, fornecer somente dados que sejam necessários e diretamente utilizáveis.
• Os dados não devem necessitar de tradução entre unidades.
• A linguagem de consulta deve usar o mínimo de quantificadores na formulação das consultas.
• Não fazer com que os usuários precisem lembrar de dados exatos de uma tela para outra.
• Prover computação automática de dados derivados, para que o usuário não tenha que calcular e
entrar com dados que possam ser derivados de dados já acessíveis ao computador.
09 Ações Explícitas
Justificativa(s):
Quando o processamento pelo computador resulta de ações explícitas dos usuários, estes aprendem e
entendem melhor o funcionamento da aplicação e menos erros são observados.
• Sempre faça necessário que o usuário tecle um ENTER explícito para iniciar o processamento de da-
dos digitados; não inicie um processamento (por exemplo, atualizar um arquivo) como efeito colate-
ral de uma outra ação (por exemplo, imprimir um arquivo).
• Se a seleção do menu é feita através de dispositivo de apontamento, faça a ativação em dois passos:
a primeira ação (posicionar o cursor) deve designar a opção selecionada e uma segunda ação distinta
faz uma entrada de controle explícita.
• Entradas de comandos do usuário devem ser seguidas de um ENTER depois de editadas.
10 Controle do Usuário
Justificativa(s):
O controle sobre as interações favorece a aprendizagem e, assim, diminui a probabilidade de erros.
Como consequência, o computador se torna mais previsível.
• Deixar ao usuário o controle do ritmo de suas entradas de dados e não pelo computador ou por even-
tos externos.
• O cursor não deve ser automaticamente movido sem o controle do usuário (com exceção de procedi-
mentos estáveis e bem conhecidos como o preenchimento de formulários).
• Possibilitar aos usuários interromper ou cancelar a transação ou processo atual.
• Fornecer uma opção CANCELAR com o efeito de apagar qualquer mudança que acabou de ser feita e
trazer a tela para seu estado anterior.
11 Flexibilidade
Justificativa:
Quanto mais formas de efetuar uma tarefa existirem, maiores serão as chances de que o usuário possa
escolher e dominar uma delas no curso de sua aprendizagem.
Exemplos de recomendações:
• Quando as exigências para o usuário forem imprecisas, fornecer meios para que ele controle a confi-
guração das telas.
• Quando, em algum contexto, a validade de certas apresentações não pode ser determinada, fornecer
ao usuário a possibilidade de desativá-las temporariamente.
• Quando os valores por default não são previamente conhecidos, o sistema deve permitir que o usuário defi-
na, mude ou suprima valores.
• A sequencia de entrada de dados deve poder ser modificada para se adaptar à ordem preferida pelo
usuário.
• Quando o formato de um texto não puder ser previsto com antecedência, deve-se proporcionar ao
usuário os meios para definir e salvar os formatos de que ele venha a precisar.
• O usuário deve poder definir os nomes dos campos de dados que ele(a) venha a criar.
12 Experiência do Usuário
Justificativa:
O grau de experiência dos usuários pode variar. Eles tanto podem se tornar especialistas, devido à uti-
lização continuada, como menos hábeis, depois de longos períodos de não utilização. A interface deve
também ser concebida para lidar com as variações de nível de experiência. Usuários experientes não
têm as mesmas necessidades informacionais que os novatos. Todos os comandos ou opções não preci-
sam ser visíveis o tempo todo. Diálogos de iniciativa exclusiva do computador podem entediar e dimi-
nuir o rendimento do usuário experiente. Os atalhos, ao contrário, podem lhes permitir rápido acesso
às funções do sistema. Pode-se fornecer aos usuários inexperientes diálogos fortemente conduzidos,

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

Justificativa:
É preferível detectar os erros no momento da digitação, do que no momento da validação. Isto pode
evitar perturbações na planificação da tarefa.
• Quando o usuário termina uma seção e existe o risco de perda de dados, deve haver uma mensagem
avisando desse fato e pedindo confirmação do final da seção.
• Os rótulos dos campos devem estar protegidos (não devem ser acessíveis ao usuário).
• As apresentações que acompanham as entrada de dados devem estar protegidas. Os usuários não
podem modificar as informações contidas nesses campos.
• Depois de um erro de digitação de um comando ou de dados, dar ao usuário a possibilidade de corri-
gir somente a parte dos dados ou do comando que está errada.
• Todas as ações possíveis sobre uma interface devem ser consideradas e, mais particularmente, as
digitações acidentais, a fim de que entradas não esperadas sejam detectadas.
• Agrupar os atalhos de teclado por funções perigosas e/ou rotineiras.
14 Mensagens de erro
Justificativa:
A qualidade das mensagens favorece o aprendizado do sistema, indicando ao usuário a razão ou a natu-
reza do erro cometido, o que ele fez de errado, o que ele deveria ter feito e o que ele deve fazer.
• Se o usuário pressiona uma tecla de função inválida, nenhuma ação deve ocorrer, a não ser uma
mensagem indicando as funções apropriadas a essa etapa da transação.
• Fornecer mensagens de erro orientadas a tarefas.
• Utilizar termos tão específicos quanto possível para as mensagens de erros.
• Utilizar mensagens de erro tão breves quanto possível.
• Adotar um vocabulário neutro, não personalizado, não repreensivo nas mensagens de erro; evitar o
humor.
15 Correção de erros
Justificativa:
Os erros são bem menos perturbadores quando eles são fáceis de corrigir.
• Fornecer a possibilidade de modificar os comandos no momento de sua digitação.
• Quando se verifica erro na digitação de um ou mais comandos, proporcionar ao usuário a possibilida-
de de refazer a digitação apenas da parte equivocada do(s) comando(s), evitando rejeitar um bloco
todo já digitado.
• Se o usuário não percebe que cometeu um erro de digitação, dar-lhe a possibilidade de efetuar, no
momento da detecção do erro, as correções apropriadas.
16 Consistência
Justificativa(s):
Os procedimentos, rótulos, comandos etc., são melhor reconhecidos, localizados e utilizados, quando
seu formato, localização ou sintaxe são estáveis de uma tela para outra, de uma seção para outra. Nes-
sas condições, o sistema é mais previsível e a aprendizagem mais generalizável; os erros são diminuí-
dos. É necessário escolher opções similares de códigos, procedimentos, denominações para contextos
idênticos, e utilizar os mesmos meios para obter os mesmos resultados. É conveniente padronizar tanto
quanto possível todos os objetos quanto a seu formato e a sua denominação, e padronizar a sintaxe dos
procedimentos. A falta de homogeneidade nos menus, por exemplo, pode aumentar consideravelmen-
te os tempos de procura.
A falta de homogeneidade é também uma razão importante da recusa de utilização.
• Localização similar dos títulos das janelas.
• Formatos de telas semelhantes.
• Procedimentos similares de acesso às opções dos menus.
• Na condução, sempre utilizar as mesmas pontuações e as mesmas construções de frases.
• Apresentar, na mesma posição, os convites (prompts) para as entrada de dados ou de comandos.
• Os formatos dos campos de entrada de dados devem sempre ser os mesmos.
17 Significados
Justificativa (s):
Quando a codificação é significativa, a recordação e o reconhecimento são melhores. Códigos e deno-
minações não significativos para os usuários podem sugerir operações inadequadas para o contexto,
levando a cometer erros.
• O título deve transmitir o que ele representa e ser distinto de outros títulos;
• Explicitar as regras de contração ou de abreviação;
• Utilizar códigos e denominações significativas e familiares em vez de códigos e denominações arbitrá-
rias (ex.: utilizar M para masculino e F para feminino, em vez de 1 e 2).
18 Compatibilidade
Justificativas:
A transferência de informações de um contexto a outro é tanto mais rápida e eficaz quanto menor é o
volume de informação que deve ser recodificada. A eficiência é aumentada quando os procedimentos
necessários ao cumprimento da tarefa são compatíveis com as características psicológicas do usuário;
os procedimentos e as tarefas são organizadas de maneira a respeitar as expectativas ou costumes do
usuário; quando as traduções, as transposições, as interpretações, ou referências a documentação são
minimizadas.
O desempenho é melhor quando a informação é apresentada de uma forma diretamente utilizável (te-
las compatíveis com o suporte tipográfico, denominações de comandos compatíveis com o vocabulário
do usuário etc).

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

Percurso Cognitivo é um método de usabilidade que tem como enfoque principal inspe-
cionar o software pela facilidade de aprendizagem, particularmente por exploração (LEWIS et
al., 1992; WHARTON et al., 1994; SALGADO et al., 2006).
Nesse contexto, a palavra "exploração" está relacionada ao fato de observar se a interface
é intuitiva e fácil de ser compreendida e manuseada sem ter de ensinar a um determinado usu-
ário como utilizá-la, ou seja, a interface naturalmente tem de permitir ao usuário saber como
realizar as tarefas a que ela se propõe por meio de suas funcionalidades. Devido a essas carac-
terísticas, esse método também pode ser entendido como um método analítico que avalia uma
proposta de projeto de Interface Humano-Computador (IHC) no contexto de tarefas específicas
do usuário ( SALGADO et al., 2006).
Para que seja possível identificar a facilidade com que o usuário conseguirá entender e
utilizar um determinado software, esse método está alinhado com a teoria da Engenharia Cog-
nitiva (NORMAN, 1986). Como pode ser observado no próprio nome, a Engenharia Cognitiva
investiga a área cognitiva dos seres vivos, especialmente a dos seres humanos, com o intuito de
explorar e conhecer a forma com que o ser vivo aprende, percebe algo quando lhe é apresenta-
do, explora um determinado objeto etc.
Em nosso contexto atual, a ideia principal é saber como nós, seres humanos, percebemos,
aprendemos e utilizamos um determinado software naturalmente, afinal, quando se conhece
todos esses fatores, é possível desenvolver algo, pois o cérebro naturalmente identificará seu
objetivo e a forma de sua utilização. Em um sonho, ainda longe, seria a interface ideal. Já pensou
em olhar um sistema computacional e, em segundos, saber a sua proposta e como utilizá-lo?
O destaque positivo que esse método possui entre os profissionais de IHC está relaciona-
do, de modo especial, ao fato anteriormente citado, pois dificilmente o usuário lê manuais ou
realiza qualquer tipo de treinamento para utilizar um software; na maioria das vezes, o aprendi-
zado e o uso do software são realizados pela exploração, ou seja, o usuário aprende a manipular
a interface por meio de uma série de tentativas e erros até a chegada do momento em que
consegue entender como se faz e, assim, realiza a tarefa.
Esta é, justamente, a proposta do método: inspecionar a interface de tal forma a avaliar o
quanto ela facilita a exploração e o aprendizado do software por parte do usuário, uma vez que ele
deve poder descobrir, aprender e memorizar sozinho como o software funciona (SALGADO et al.,
2006). Segundo Lewis (et al. 1997), esse método de inspeção analisa os processos mentais que os
usuários formam para executar determinadas tarefas, a fim de avaliar a interface e detectar se ela
é fácil de aprender e memorizar.
Wharton (et al., 1992) relata que esse método investiga, especialmente:
• A correspondência entre o conceito de uma tarefa por parte dos usuários e dos desig-
ners;
• A escolha adequada ou inadequada de termos, como, por exemplo, se o vocabulário
está adequado ao público-alvo;
• O feedback adequado ou inadequado como consequência de uma ação.
A avaliação do Percurso Cognitivo pode ser aplicada pelos próprios desenvolvedores, es-
pecialistas, grupos de designers e representantes de outras áreas, como marketing e treinamen-
to, por exemplo (SALGADO et al., 2006).
O interessante de os próprios desenvolvedores aplicarem o método é que eles podem
fazer isto mesmo durante a especificação do sistema, a fim de que a interface esteja próxima
do ideal antes mesmo de os especialistas ou outros profissionais avaliarem. A possibilidade de
realizar esse método mesmo durante a especificação permite ao Percurso Cognitivo ter uma fle-
xibilidade pertinente, pois ele pode ser utilizado desde as fases iniciais do desenvolvimento do
software, por meio de protótipos em papel, até o software completo. Alguns profissionais em
IHC experientes conseguem aplicá-lo, somente, com o documento de requisitos, já que a expe-
riência os permite imaginar algumas características da interface apenas lendo sobre a descrição
do sistema.
O método consiste em três fases básicas, como pode ser vista na Tabela Cada fase será
descrita, de maneira detalhada, a seguir.
Tabela 5 Fases para realizar o Percurso Cognitivo.

Número da Fase Nome da Fase
1 Preparação
2 Avaliação
3 Interpretação
1 – Fase de Preparação
Preparar todo o material e todas as informações que serão utilizadas na próxima fase. Nes-
ta fase, é definido quem são os usuários-alvo com o intuito de documentar e esclarecer quais
são suas características, seus comportamentos, suas habilidades, entre outras particularidades
que podem influenciar a interação com o software.
Vale ressaltar que essa atividade – definir usuários-alvo – é de extrema importância, pois
os profissionais que irão aplicar o método terão de levar em consideração essas informações,
uma vez que cada perfil de usuário possui características que influenciam, diretamente, na utili-
zação do software. Por exemplo, se o público-alvo for idosos, então, durante a avaliação, terá de
considerar o tamanho das letras, a quantidade de informações apresentadas para não confundi-
-los, entre outras coisas que ajudam esse público; outro exemplo, se o público-alvo for crian-
ças, é preciso se preocupar com a forma com que as informações serão apresentadas e com o
vocabulário para permitir uma melhor compreensão por elas, já que não são completamente
alfabetizadas etc. Enfim, o profissional, antes de realizar o método, tem de saber quem são os
usuários, seus objetivos, suas características e todas as outras informações que os influenciarão
a "advinhar" como manejar o software corretamente (SALGADO et al., 2006).
É fundamental também definir as tarefas que serão inspecionadas e a sequência das ações
corretas para cada tarefa. A escolha das tarefas não é algo simples; por isso, ela pode ser feita
com base em estudos de mercado, análise das necessidades e análise dos requisitos. Não há a
quantidade de tarefas que devem ser analisadas, essa quantidade tem de ir ao encontro das
prioridades, do tempo e das necessidades dos profissionais, bem como da disponibilidade fi-
nanceira.
Para cada tarefa, é preciso definir, minuciosamente, as ações que o usuário terá de fazer
por meio da interface para conseguir realizá-la. Por exemplo, se a tarefa fosse efetuar uma pes-
quisa em um campo de busca, então, as possíveis ações seriam encontrar o campo de busca,
digitar uma palavra ou frase que representa a pesquisa, pressionar o <enter> (tecla existente no
teclado do computador) ou clicar em "Pesquisar" (botão existente na interface).
Como último passo dessa fase, está a definição da(s) interface(s) que será(ão) objeto(s) de
análise. No exemplo anterior, apenas uma interface foi escolhida. Nessa interface, que é a prin-
cipal do software, já contém o campo de busca; assim, não há necessidade do usuário clicar em
algo para mudar para a página que contém esse campo. Caso isto fosse preciso, agregaria mais
algumas ações e interfaces à tarefa.
De maneira geral, podemos resumir essa fase em quatro perguntas, ilustradas na Tabela 6.
Tabela 6 Perguntas da Fase de Preparação (Wharton et al., 1992)

Quem são os usuários do soŌware?
Quais tarefas serão analisadas?
Qual é a sequência correta de ações para cada tarefa?
Qual é a interface definida?
Fonte: WHARTON et al., 1992
2 – Fase de Avaliação
Nesta segunda fase, o avaliador é responsável por descrever em detalhes o que o usuário
faria para realizar uma tarefa. Encontramos a primeira grande dificuldade do método, pois o
profissional terá de conhecer muito bem o usuário-alvo e se comportar como ele ao utilizar o
software para ter a ideia exata do que o usuário faria e, assim, para descobrir os pontos negati-
vos e positivos.
Quando as ações e atitudes do pesquisador vão ao encontro do esperado, o software é
tido por usável; quando este vai de encontro, identifica-se não apenas um problema de usabi-
lidade, mas também a sua causa, ou seja, a razão de não se poder "advinhar" o que fazer (SAL-
GADO et al., 2006).
Durante a avaliação, é preciso registrar todas as informações. Uma forma de registrar é
responder algumas perguntas, que devem ser sistematicamente levantadas e respondidas pelos
avaliadores no decorrer do processo. Não há perguntas obrigatórias, uma vez que elas depen-
dem do contexto, público-alvo, objetivo etc. Entretanto, como estudo e aprendizado do método,
quatro perguntas básicas descritas por Wharton (et al., 1992) são abordadas, como pode ser
observado na Tabela Essas perguntas, além de serem básicas, ou seja, podem ser utilizadas para
avaliar vários tipos de softwares, remetem ao pensamento natural do ser humano e à forma
com que ele tenta atingir uma determinada meta no contexto computacional.
Tabela 7 Perguntas da Fase de Avaliação.

1 O usuário tentará aƟngir a meta correta?
2 O usuário perceberá que a ação correta está disponível?
3 O usuário associará o elemento correto à meta a ser aƟngida?
4 Se a ação correta é tomada, o usuário perceberá que progrediu em direção à solução da tarefa?
Ao ler a primeira pergunta com atenção, você deve ter pensado: mas "o usuário tentará
atingir a meta correta?". Com certeza, pois é este o objetivo dele ao utilizar o sistema; então,
essa pergunta será sempre positiva, independentemente do software e da dificuldade que ele
tiver ao utilizá-lo. No entanto, essa pergunta é bem mais complexa do que aparenta; por meio
dela, é preciso observar se a interface permite ao usuário saber por onde começar. Uma coisa
é ele querer atingir a meta, outra coisa é saber se a interface o possibilita a fazer isto de uma
maneira fácil.
É sempre importante manter o enfoque na interface, pois, assim, fica mais claro saber o
que você irá avaliar. No caso, com base na primeira pergunta, terá de observar, considerando as
características de seu público-alvo, se a opção necessária está disponível ou não na interface;
se o local que a opção está é adequado para o usuário encontrar, clicar ou realizar alguma ação;
se o vocabulário utilizado para apresentá-la é viável e fácil de ser compreendido; se o tamanho
da opção está bom; se as cores estão sendo utilizadas de forma satisfatória; se o contraste das
cores do fundo e da opção o permitem estar visível adequadamente etc.
Essas considerações influenciam, diretamente, a identificação de uma opção pelo usuá-
rio; portanto, elas terão de ser analisadas. É válido mencionar que você terá de escrever qual
é a ação que o usuário tentará fazer nesse momento. Observe que você, ao avaliar, tem a ação
correta, mas a opção para executar essa ação está visível a ponto de o usuário a escolher ou, por
exemplo, ter outra opção que remeta à mesma funcionalidade e que possa confundi-lo.
Ao observar isto, você terá condições de descrever a resposta da primeira pergunta, mas é
preciso descrevê-la com detalhes, como, por exemplo, explicar o porquê de o usuário clicar em
outra opção ao invés de o fazer na correta, quais são as características da outra opção que fazem
que o usuário a visualize primeiro ou clique nela etc. Esses detalhes são de extrema importância
para o momento da correção, afinal, se você sabe quais são as características que possivelmente
farão o usuário clicar na opção errada, às vezes, pode ser uma estratégia utilizar tais caracterís-
ticas para destacar a opção certa.
A primeira pergunta também está relacionada a observar se o usuário saberá qual será
o próximo passo, ou seja, se o usuário, ao ver a primeira opção em que ele terá de clicar, vai
perceber qual é a próxima ação, de modo a não ficar perdido quando essa segunda ação for
necessária. Esta é uma estratégia para permitir ao usuário ter controle e compreender todas as
opções de maneira mais fácil, uma vez que ele estará preparado para a próxima ação desde a
ação anterior.
Na segunda pergunta, "o usuário perceberá que a ação correta está disponível?", há a pre-
ocupação em observar o formato do elemento que a interface disponibiliza a ação. Por exemplo,
se a opção é clicar, o usuário perceberá por meio do formato que é isto que terá de fazer? Se a
opção é visualizar um determinado resultado, o elemento escolhido para ficar na interface ilus-
tra que ali será exibido um resultado? Ao olhar, o usuário saberá, de imediato, o local correto?
Enfim, quais são as opções e seus formatos que a interface possui para o usuário executar a
ação?

Outra questão que deve ser investigada nessa segunda pergunta é o local em que está o
elemento para o próximo passo. Observe que, na pergunta anterior, houve a preocupação em
saber se o elemento está ou não disponível. Nessa pergunta, também é preciso saber o local em
que ela está, bem como investigar se o local escolhido é de fácil visualização e se é intuitivo para
o usuário chegar até ela.
Para a pergunta "o usuário associará o elemento correto a meta a ser atingida?", é preciso
perceber a relação entre a ação e o elemento disponível na interface para o usuário executar a
ação. Por exemplo, pelas perguntas anteriores, é possível saber que a ação é clicar, pois o forma-
to do elemento da interface indica isto, mas é preciso realizar uma comparação para se saber se
todas essas informações ajudarão o usuário. Nesse caso, para permitir ao usuário saber que a
opção tem de ser clicada, o elemento, que poderia ser um botão ou link, com um nome intuitivo
em um local, bem como cor e tamanho adequados.
Observe a particularidade dessa pergunta ao compará-la às anteriores, pois até à segunda
pergunta, é preciso identificar as características, os formatos e outros detalhes, e, por meio da
terceira pergunta, terá de ser feita uma análise detalhada sobre se tudo o que foi apresentado
é viável e/ou útil para o usuário saber o que fazer, uma vez que é preciso saber se o elemento
da interface revela seu propósito e comportamento. Uma dica é você se colocar no lugar do
público-alvo e olhar o elemento para realizar a ação, para pensar no que você faria ao vê-lo.
Seria clicar? Arrastar? Ficar aguardando para ver algo acontecer? etc.
É interessante perceber se o elemento permite ao usuário saber o que ele pode fazer –
observe que, nesse caso, é importante conhecer o significado do elemento. Há um estudo muito
interessante sobre semiótica, um assunto que influencia, diretamente, como o usuário percebe
o que está na interface e o seu significado (SOUZA et al., 2008). De maneira bem simples, é
possível dizer que a preocupação central é permitir que a interface tenha elementos que sejam
intuitivos e fáceis para o usuário saber o que fazer com eles. Enfim, como citado anteriormente,
se o elemento revela o seu propósito e comportamento.
Por exemplo, se o elemento possui o formato de um botão, então, tem de ser possível cli-
car sobre ele, pois qualquer ação possível diferente disto poderá deixar o usuário perdido. Outro
exemplo é ter um elemento que pareça uma lista de opções, mas que sempre e somente apa-
rece uma opção nesse campo, que possui tamanho suficiente para mais. Isto faz que o usuário
fique aguardando para saber se mais informações vão ou não aparecer, afinal o elemento sugere
isto. Esses dois exemplos foram apenas para você perceber a influência e a importância que os
detalhes fazem na interação humano-computador; por isso, tudo tem de ser bem pensado. Há
a necessidade de ter um planejamento, um cuidado e uma estratégia para cada item disponível
por meio da interface.
Sobre a última pergunta, "se a ação correta é tomada, o usuário perceberá que progrediu
em direção à solução da tarefa?", é preciso analisar se a interface apresenta ou não o resulta-
do da ação e a forma com que ela faz isto. A mensagem ou qualquer outra informação que for
apresentada ao usuário uma como forma de mostrar se está certo ou não o que ele fez tem de
ser clara e fácil de ser compreendida. Não adianta exagerar no visual, colocando cores, formas e
letras diferentes, se o principal, que é passar a mensagem para o usuário, não for atingido.
O resultado apresentado tem de ter correspondência com o objetivo do usuário. Por
exemplo, se o objetivo for visualizar uma informação, tem de estar claro o local e a forma do
elemento responsável por exibi-la para que o usuário encontre e visualize a informação deseja-
da facilmente. Se o objetivo foi enviar um e-mail, o usuário tem de perceber, no final, se o este
foi enviado com sucesso ou não. Enfim, são formas para o usuário compreender que aquilo que
ele pretendia foi realizado com sucesso.
Observe que esse passo é importante para cada ação, e não apenas para a tarefa final,
uma vez que, se a tarefa for enviar um e-mail, mas, dentre as ações, tiver "clicar em Escrever
e-mail", então, assim que clicar, o usuário tem de perceber que está no caminho correto e na in-
terface adequada para escrever um e-mail, ou seja, o resultado tem de ser adequado para cada
ação. Nesse caso, não há necessidade de mostrar uma mensagem que represente a conclusão
do objetivo da tarefa "seu e-mail foi enviado com sucesso", pois o usuário está apenas em uma
das ações para executar essa tarefa, e o importante é deixar claro que a ação foi realizada com
sucesso.
Como forma de facilitar a compreensão das quatro perguntas e permitir ao profissional
realizar uma inspeção mais detalhada, Prates (2003) elaborou algumas subperguntas para cada
pergunta descrita por Wharton (et. al., 1992). Por meio dessas novas perguntas, é possível res-
ponder com mais detalhes cada uma das quatro perguntas anteriores. Você pode verificar as
perguntas juntamente com as subperguntas, apresentadas na Tabela 8.
Tabela 8 Perguntas e subperguntas da Fase de Avaliação

1 O usuário tentará a ngir a meta correta?
1a. Dada a decomposição de uma tarefa em subtarefas, o usuário saberá por onde começar? Saberá qual é o próximo
passo?
1b. O que o usuário vai tentar fazer a cada momento?
2 O usuário perceberá que a ação correta está disponível?
2a. Onde está o elemento de interface correspondente ao próximo passo?
2b. Que ações a interface torna disponível?
3 O usuário associará o elemento correto à meta a ser a ngida?
3a. O elemento da interface revela seu propósito e comportamento?
3b. O usuário consegue iden ficar os elementos da interface?
4 Se a ação correta é tomada, o usuário perceberá que progrediu em direção a solução da tarefa?
4a. Como a interface apresenta o resultado de cada ação?
4b. O resultado apresentado tem correspondência com o obje vo do usuário?
Fonte: Prates, 2003.
Se você prestar atenção em cada das perguntas, possivelmente perceberá que elas estão
diretamente relacionadas com o nome do método, Percurso Cognitivo, pois, de alguma forma,
elas se assemelham com a forma com que nós, seres humanos, intuitivamente pensamos ao re-
alizar algo, ou seja, com nossa forma cognitiva (natural) de realizar uma determinada atividade
no computador. Por exemplo, se você quiser "clicar no botão enviar", geralmente, seguirá essa
sequência: encontrar uma opção na interface que lhe remeta à ação enviar, depois perceber o
formato em que está essa opção para saber se ela lhe permite clicar e, ao realizar a ação "clicar
no botão enviar", vai querer saber se o que você fez foi realizado com sucesso ou não.
Apesar de, após a história apresentada, tudo isto parecer um pouco mais simples, é preci-
so ficar claro que realizar essa inspeção com o rigor que ela deve ter não é trivial, pois ela é uma
inspeção subjetiva, o que faz que a avaliação tenha de ser bem descrita, com detalhes suficien-
tes para permitir o rigor necessário para que você ou outro profissional possa ler, entender e
realizar as modificações necessárias na interface.
Finalmente, é importante reforçar que, para cada ação que compõe a tarefa, é preciso
responder às quatro perguntas.
Por meio de todas as perguntas da primeira e da segunda fase, será possível registrar as
seguintes informações, de acordo com Wharton (et al., 1992) e Salgado (et al., 2006): quem é o
público-alvo e qual é o conhecimento esperado desse público, bem como sua experiência, a cla-
reza da disponibilidade da ação no momento apropriado; a facilidade de identificação da ação
disponível; as recomendações para mudanças de design e uma descrição coerente com detalhes
suficientes que explicam e justificam o julgamento do profissional.
Essa descrição deve ser imparcial e deve contar o que é possível visualizar por meio da
interface, relatando os pontos positivos e negativos para avaliar a facilidade de aprendizagem e
memorização da interface.
Agora, veremos a terceira fase.
3 – Fase de Interpretação
Nesta terceira fase, toda a descrição e todas as outras informações discutidas até o momen-
to serão analisadas. Segundo Salgado (et al., 2006), um dos resultados esperados é a descoberta
dos conflitos entre o que o profissional pensou que seria viável para exibir na interface e o que o
usuário realmente enxergará e, de fato, precisará para realizar uma determinada atividade.
No final, é realizado um relatório com o mesmo detalhe e rigor que foi feito até essa fase.
Nesse relatório, tem de conter a interpretação dos resultados e os problemas encontrados, bem
como as soluções observadas que podem sanar o problema. Resumidamente, é possível des-
crever que essa fase conterá todos os problemas identificados na fase de avaliação e a forma de
solucioná-los; por isso, geralmente, esse relatório possui problemas nas escolhas das palavras,
dos menus, da informação exibida pelo botão e respostas inadequadas sobre as consequências
de ações, entre outras informações que influenciaram o julgamento do projetista para dizer que
a ação pode não ser feita de maneira adequada pelo usuário.
Para auxiliar a escrita desse relatório, há uma tabela que permite ao projetista saber quais
são os detalhes que devem ser inseridos e o local adequado para cada informação, de modo que
seja possível manter uma organização. A Tabela 9 possui um exemplo da estrutura desse relató-
rio; no entanto, ressalta-se que o relatório pode conter mais informações e detalhes. O objetivo
dessa tabela é apenas apresentar as informações básicas que devem constar no relatório.
Tabela 9 Interpretação dos resultados e sugestões de melhorias.

Nrº Problema encontrado Local O que ocasionou o problema? Soluções sugeridas
1
2
3
Como pode ser observado na Tabela 9, há cinco informações básicas para um relatório de
Percurso Cognitivo. O primeiro campo representa o "Número" sequencial que deve ser atribuí-
do. Esse número é utilizado, apenas, para facilitar a interpretação de quantos problemas foram
encontrados. No "Problema encontrado", é necessário descrever em detalhes qual foi o proble-
ma, por que ele foi considerado um problema, quais são as características do elemento ou da
interface que influenciaram para isto acontecer; enfim, é necessário ser bem minucioso nessa
descrição, pois o outro avaliador, ao ler esse campo, tem de identificar, de imediato, o problema
que ocorreu e o que aconteceu para ser considerado um problema. Isto o ajudará a refletir sobre
o problema e pensar sobre qual foi a falha e quais são as possíveis soluções para resolvê-lo.
Vale ressaltar que você também pode descrever alguma solução, mas é viável permitir a
outro profissional refletir sobre as soluções que ele poderia propor – isto ajudará em uma solu-
ção ainda mais completa, pois o que você pensar poderá ser um complemento e, dessa forma,
enriquecer a solução, ou será uma forma de discutir qual é a melhor solução a ser aplicada e,
com isso, possivelmente escolher a forma mais adequada.
É necessário também descrever o "Local" em que o problema ocorreu. O nível de detalhe
para esse campo depende da quantidade de interfaces e da complexidade do software. O obje-
tivo é que, ao ler o local, o profissional saiba, de imediato, em que interface e em que elemento
ocorreu o problema, bem como onde encontrar esse elemento. É preciso deixar bem claro esse
local, pois o profissional não pode perder tempo para procurar o problema – o tempo deve ser
utilizado para solucioná-lo.
A quantidade de interfaces e a sua complexidade influenciam o nível de detalhe, porque,
dependendo desses fatores, será necessário descrevê-los, de forma que seja fácil identificar
uma interface dentre as várias, e, se a tarefa for complexa e requerer a utilização de vários ele-
mentos, é preciso relatar em qual desses elementos há um problema.
Para uma melhor organização do conteúdo da tabela e compreensão por outros profissio-
nais, é importante que cada linha da tabela contenha um problema apenas. Não agrupe vários
problemas em um mesmo local, pois, assim, você evita que o nível de atenção de quem for ler a
tabela tenha de ser ainda maior para entender todos os detalhes descritos em um mesmo local,
o que é desnecessário. Esse cuidado também ajudará no preenchimento da tabela, uma vez que
é mais fácil escrever algo por partes ao invés de tentar escrever tudo sem uma ordem.
No campo "o que ocasionou o problema?", é possível escrever quais foram as atitudes
realizadas para se chegar ao erro. Lembre-se de que, além de saber onde está o problema, é
importante que o outro profissional saiba como simular o software, com o intuito de conseguir
ver o mesmo erro. Assim, ficará mais fácil perceber, além do problema e o local, como isto acon-
teceu e entender se houve alguma outra coisa que pode ter ocasionado o problema.
Ao descrever as "soluções sugeridas", é preciso ter certo cuidado, pois, além de expor a sua
opinião sobre algo, você terá a responsabilidade de explicar em detalhes qual foi o seu raciocínio
para chegar a essa solução, por que ela é viável e como aplicá-la. Todas essas informações têm de
estar claras para que o outro profissional, além de entender, possa se interessar por sua solução.
Ao concluir esse relatório, o método Percurso Cognitivo é finalizado, e tudo o que foi re-
gistrado deve ser entregue para as pessoas que são responsáveis pelo desenvolvimento do sof-
tware ou para a pessoa contratante para esse serviço se realizar.
Segundo Salgado (et al., 2006), ao aplicar o método com sucesso, é possível ter como
resultado como será a interação entre o usuário e o software, e as perguntas e a forma de se
avaliar servem como base para um conflito entre algum modelo mental (do usuário) e uma pro-
priedade física ou funcional do sistema. Outra informação pertinente é que, por meio da teoria
cognitiva, o profissional pode trabalhar com dados da cognição do usuário mesmo sem observá-
los diretamente.
Dessa forma, podemos dizer que é possível prever as atitudes do usuário ao ver uma de-
terminada interface mesmo sem ver o usuário utilizando o sistema. Entretanto, é importante
ressaltar que a qualidade dos resultados está relacionada com o profissional e sua experiência.
Por não precisar do usuário para realizar essa avaliação, esse método tende a adquirir uma van-
tagem de todos os métodos de inspeção, que é o custo, pois envolve menor número de pessoas,
já que tudo pode ser feito com os profissionais que já estão envolvidos no desenvolvimento.

11. EXEMPLO DE APLICAÇÃO ͵ PERCURSO COGNITIVO

A inspeção descrita a seguir foi realizada em um webmail que tem conquistado muitos usu-
ários atualmente, especialmente pela quantidade de funcionalidades de adaptação da interface.
Esse webmail permite mudar o tema ou a imagem de fundo de tela, aumentar ou diminuir a quan-
tidade de funcionalidades na interface, bem como mudá-las de posição, entre outros recursos que
facilitam ao usuário ter uma interface adequada e divertida, uma vez que tem a possibilidade de
inserir desenhos, cores, jogos etc.
Esse webmail é chamado Gmail. A empresa responsável por esse webmail é a mesma que
possui, atualmente, um site de busca que é considerado o melhor por muitas pessoas – o Goo-
gle. Por isso, outra vantagem desse e-mail é unir os recursos dos webmails tradicionais com uma
das melhores tecnologias de pesquisa do mundo, o que torna o ato de localizar as mensagens
recebidas, enviadas etc. algo muito fácil.
A ideia de realizar o Percurso Cognitivo no Gmail é para identificar se todos esses recursos
e essas vantagens que a Google diz que oferece não atrapalha os usuários em realizar uma ta-
refa simples e básica para um webmail, que é "Enviar um e-mail". A intenção é saber se o Gmail
não está se parecendo com um celular de última geração, que possui tantas funcionalidades
e botões que se torna difícil saber como realizar uma tarefa que deveria ser trivial, como, por
exemplo, fazer uma ligação.
Para a inspeção, foram selecionadas duas interfaces. A primeira, que pode ser observada
na Figura 15, é a principal do Gmail. Por meio dessa interface, o usuário tem acesso a todas
as funcionalidades. Se você olhar da esquerda para a direita de cima para baixo, vai visualizar
alguns links para os aplicativos da empresa Google, como Orkut, Agenda etc., o e-mail do usu-
ário que realizou o acesso e, ao lado, algumas opções para realizar as adaptações na interface
(símbolo verde) e alterar as configurações, bem como ajuda e o link de sair. Depois há o símbolo
do Gmail, seguido por um campo que permite realizar buscas no e-mail ou em toda a web. Do
lado esquerdo, você pode observar alguns links que funcionam como menus para acessar as
funcionalidades básicas comuns a qualquer webmail. No centro, você verá uns botões utilizados
para realizar algumas ações nos e-mails, que se encontram na parte central, finalmente, do lado
direito, existe o Gtalk, o bate-papo do Google.
Figura 15 Tela principal do Gmail.

A segunda interface, ilustrada na Figura 16, é a que permite ao usuário escrever um e-mail
e enviá-lo. No início da interface, há três botões: "Enviar", "Salvar agora" e "Descartar". Em se-
guida, há alguns campos para ser preenchidos, para criar o e-mail a ser enviado.
Figura 16 Tela do Gmail para enviar e-mails.
Tabela de Avaliação
Antes de ler as perguntas que devem ser respondidas na Fase de Preparação, vale a pena
saber um pouco mais sobre uma pergunta que, apesar de parecer simples, é bem complexa, e
a sua resposta influenciará toda a inspeção. Essa pergunta, inclusive, é a primeira: "quem são
os usuários do sistema?". Observe que o principal objetivo da inspeção é perceber as possíveis
dificuldades que os usuários podem ter; assim, saber quem são os usuários e entender a forma
com que eles pensam, agem, entre tantas outras características descritas em unidades anterio-
res, é essencial.
Devido à importância desses fatores, é imprescindível bem pensar e discutir com todos os
agentes envolvidos no desenvolvimento do software sobre quem serão os usuários. Essa discus-
são deve acontecer desde o levantamento de requisitos, ou seja, tem de ser uma das primeiras
coisas a se pensar.
Apenas para facilitar o entendimento das características que foram inseridas na primeira
pergunta, é válido discutir que, na área da IHC, de maneira geral, o usuário é classificado em três
tipos: iniciante, intermediário e avançado no uso de um determinado software.
Na maioria das vezes, a opção escolhida é a de intermediário. Isto ocorre porque, geral-
mente, o usuário é classificado como iniciante por pouco tempo, e poucos são os usuários que
alcançam o nível avançado. Um usuário é considerado iniciante nas primeiras vezes em que
utiliza o software, pois ele ainda não conhece bem quais são as opões e qual é o objetivo do
software e ainda possui dificuldades muito básicas que, após três ou quatro vezes de uso, se es-
pera que sejam sanadas. Por fim, para o usuário ser considerado avançado, ele tem de conhecer

todas as funcionalidades do software, ou seja, os caminhos necessários para realizar qualquer

tipo de tarefa que o software possa executar. O usuário intermediário é aquele que conhece o
software e sabe utilizar as funcionalidades que realmente precisa e que, eventualmente, memo-
riza outras funcionalidades que utiliza esporadicamente.
Se o usuário precisa e gosta do software, possivelmente passará da classificação de ini-
ciante para a de intermediário muito rápido, ou seja, em apenas alguns dias de uso. Entretanto,
dificilmente um usuário passa a ser classificado como avançado, porque, a maioria dos usuários,
não se interessa em conhecer todas as funcionalidades que o software possui e, na maioria das
vezes, preocupa-se em memorizar, apenas, as funcionalidades de que realmente precisa.
Vale lembrar que, dependendo do software, existe a possibilidade de se pensar em outro
tipo de usuário. Por exemplo, se você for desenvolver um software para ser utilizado por pesso-
as idosas, então, provavelmente, você terá de pensar em usuários iniciantes, devido à capacida-
de cognitiva e de memorização dessas pessoas.
No caso do exemplo citado a seguir, foi considerada a classificação de intermediário para
a experiência com o computador, no uso de webmails etc.
Tabela 10 Tabela Preparação.
Quem são os usuários do sistema?

Algumas características comuns do público-alvo são citadas a seguir:
- entendem textos curtos e são capazes de interpretá-los;
- estão acostumados a utilizar o computador;
- geralmente navegam na internet.
- conhecem outros webmails.
Observação: uma pesquisa de mercado foi realizada para identificar os tipos de usuários que acessam a web.
Dentre os identificados, foi escolhido um tipo que representa a maioria dos usuários, com as características citadas
anteriormente. Foi identifica que, hoje em dia, existe uma grande diversidade de usuários acessando a web, mas
a maioria ainda não está totalmente escolarizada, e a capacidade de esses usuários lerem um texto complexo e
interpretá-los é pouca; por isso, é necessário avaliar a interface considerando textos simples, curtos e fáceis de
serem compreendidos.
Esse tipo de usuário já tem contato com o computador a mais de três anos e conhece as suas funcionalidades bá-
sicas. No entanto, quando é solicitado para fazer alguma tarefa diferente do habitual, ele fica com receio, mas se
arrisca a realizá-la por tentativa e erro. Se a tarefa for muito complexa e ele não conseguir realizar em quatro tenta-
tivas, há uma desistência.
Tem contato com a internet a mais de dois anos geralmente para acessar:
- e-mails;
- notícias;
- rede de relacionamentos, como Orkut;
- sites de buscas, como Google;
- comunicadores instantâneos, como MSN Messenger.
Como o contexto é a inspeção em um webmail, houve o interesse em identificar quais seriam os webmails mais
utilizados pelo público-alvo escolhido. Partindo dessa informação, seria feita uma análise na interface com o intuito
de conhecer quais seriam as funcionalidades, as opções, os símbolos, a linguagem, entre outras características que
os usuários estão acostumados a encontrar no webmail que eles possivelmente gostam, pois acessam com mais
frequência.
Na pesquisa, identificou-se que o webmail mais utilizado é o Hotmail, um produto da Microsoft©. Um fato interessante
abordado é que o uso desse webmail não tem como fatores principais a satisfação e a facilidade de uso. O fator
principal é a ligação entre o Hotmail e o programa MSN Messenger. A maioria dos usuários utiliza o Hotmail porque
se interessaram, inicialmente, pelo MSN, para conversar com as pessoas da família e com os amigos ou para con-
tatos profissionais. E, como era preciso ter um e-mail no Hotmail para entrar no MSN, os usuários faziam a "conta"
e utilizavam-na por comodidade.
Por meio da pesquisa de mercado, foi possível perceber que muitos usuários, mas não a maioria deles, estão insa-
tisfeitos com a forma com que as opções e funcionalidades são apresentadas; por isso, durante a inspeção, é viável
realizar a comparação para saber o que os usuários estão acostumados, mas, se tiver algo diferente, vale a pena
pensar se o "novo" ou "diferente" não é melhor.
O objetivo de descrever essa pesquisa é, apenas, para ilustrar a forma com que se deve pensar. Não é apenas definir
os usuários; é preciso saber o que eles usam, o porquê de usarem, se gostam ou não, entre outros fatores que in-
fluenciam, diretamente, a forma com que eles interagem com o computador. Também há a necessidade de se pensar
na concorrência existente no mercado. Se você deseja desenvolver algo, que ele seja o melhor.
*Pesquisa de mercado hipotética – meramente ilustrativa
ssss
Quais tarefas serão analisadas?

A tarefa é enviar um e-mail com um anexo.
Algumas informações pertinentes para realizar a tarefa são:
1 – O e-mail deve ser enviado para o endereço professor@professor.com.br
2 – O assunto deve ser "Trabalho – Percurso Cognitivo" (sem as aspas)
3 – A mensagem deve conter o seguinte texto:
"Prezado professor,
Segue anexo um arquivo .doc com a inspeção realizada no e-mail Gmail utilizando o método Percurso Cognitivo.
Os nomes completos dos alunos e outras informações pertinentes se encontram no arquivo.
Atenciosamente, " (sem as aspas)
4 – Anexar um arquivo .doc que se encontre na área de trabalho do computador. (o local definido tem de estar de
acordo com o computador em que o profissional irá realizar a inspeção).
Qual é a sequência correta de ações para cada tarefa e como ela é descrita?
A sequência para realizar a tarefa definida é:
1 – Clicar em "Escrever e-mail"
2 – Definir "Para"
3 – Digitar o "Assunto"
4 – Escrever a mensagem
5 – Anexar arquivo
6 – Clicar no botão "Enviar"
Qual é a interface definida?

Duas interfaces foram escolhidas para ser avaliadas:
1 – Interface principal em que o usuário tem acesso aos e-mails na caixa de entrada e outras funcionalidades do
sistema.
2 – Interface que permite ao usuário digitar todas as informações definidas na tarefa e enviar a mensagem com
anexo.
Observação: a interface principal tem de ser avaliada, pois há a necessidade de saber se o usuário encontrará a
opção para enviar uma mensagem, bem como o feedback de mensagem enviada, exibida somente na interface prin-
cipal (essa observação foi feita porque, para a tarefa, é realmente necessário também avaliar a interface principal;
dependendo da tarefa, seria preciso apenas avaliar uma interface se tudo pudesse ser feito e visualizado nela).
Tabela 11 Tabela Avaliação.

AÇÃO CLICAR EM "ESCREVER E-MAIL"
Sim. Embora haja muitas opções na interface, a opção
O usuário tentará atingir a meta correta?
"Escrever e-mail" está em um local de destaque.

AÇÃO CLICAR EM "ESCREVER E-MAIL"

Mesmo tendo alguma dificuldade na primeira vez, devido
à quantidade de opções e por estar em local diferente
de outros e-mail, como o Hotmail, o usuário encontrará e
aprenderá onde está a opção.
Essa afirmação é porque os usuários geralmente leem
1a. Dada a decomposição de uma tarefa em subtarefas,
da esquerda para direita e de cima para baixo, e a op-
o usuário saberá por onde começar? Saberá qual é o
ção "Escrever e-mail" encontra-se nessa posição de
próximo passo?
destaque, logo abaixo de um dos símbolos mais visíveis
– o logotipo do Gmail.
Entretanto, ele não saberá qual é a próxima ação, pois
ela está visível, apenas, na próxima tela, que será exibi-
da após um clique do usuário na opção correta.
Nesse momento, o usuário tentará encontrar uma opção
que indique uma maneira de escrever um novo e-mail.
1b. O que o usuário vai tentar fazer a cada momento? Então, ele encontrará uma opção com uma linguagem
comum – "Escrever e-mail". Por isso, pressupõe-se que
o usuário clicará em "Escrever e-mail".
Sim, pois a opção correta está em um formato que apa-
renta ser um link por ser azul e sublinhado, o que pode
O usuário perceberá que a ação correta está disponí- indicar ao usuário que ali é uma opção que está disponí-
vel? vel para ser clicada, especialmente porque o público-alvo
considerado nessa inspeção tem conhecimento de alguns
símbolos existentes na internet, e o link é um destes.
Não há possibilidade de ver a próxima ação; por isso,
2a. Onde está o elemento de interface correspondente
não há indícios de que a próxima opção correta está
ao próximo passo?
disponível.
Para essa ação, existe a opção "Escrever e-mail" para
2b. Quais ações a interface torna disponível?
ser clicada.
Sim, pois o que está escrito na opção a ser clicada vai
O usuário associará o elemento correto à meta a ser
ao encontro da ação desejada pelo usuário, que é en-
atingida?
viar um e-mail.
Sim, pois o elemento é um link com aparência de um link,
3a. O elemento da interface revela seu propósito e com-
e, quando clicado, executa uma atividade normal de um
portamento?
link – no caso, vai para uma próxima página.
3b. O usuário consegue identificar os elementos da in- Sim. Para essa ação, é possível identificar o link "Es-
terface? crever e-mal".
Se a ação correta é tomada, o usuário perceberá que Sim, a interface é alterada logo que o usuário clica sobre
progrediu em direção à solução da tarefa? o link, mostrando que algo aconteceu.
4a. Como a interface apresenta o resultado de cada Destaca o "Escrever o e-mail" em azul e abre a página/
ação? conteúdo de envio de e-mail.
Sim, pois a próxima página possui alguns campos que
4b. O resultado apresentado tem correspondência com
são para enviar um e-mail. Devido à experiência do usu-
o objetivo do usuário?
ário em mandar e-mail, ele reconhecerá os campos.
AÇÃO DEFINIR "PARA"

Sim, pois a nova página deixa em destaque as opções
O usuário tentará atingir a meta correta? necessárias para enviar um e-mail, incluindo a opção
"Para".
Sim, pois de modo semelhante à escrita de uma carta,
existe a preocupação em definir o remetente e o destina-
tário, e a interface exibe, automaticamente, o remetente,
1a. Dada a decomposição de uma tarefa em subtarefas, que pode ser visualizado no campo "De", fazendo com
o usuário saberá por onde começar? Saberá qual é o que o usuário perceba que falta informar o destinatário,
próximo passo? que se encontra em um campo logo abaixo.
Sim. É possível visualizar a opção "Assunto", que repre-

senta o próximo passo.
AÇÃO DEFINIR "PARA"

O usuário tentará digitar o endereço de um e-mail no
campo "Para".
Sim, pois há um campo em branco logo a direita de
O usuário perceberá que a ação correta está disponí-
"Para", que pode representar ao usuário que ali é o local
vel?
para digitar o e-mail.
O elemento "Assunto" está abaixo da opção "Para", per-
2a. Onde está o elemento de interface correspondente mitindo que o usuário o visualize sem dificuldade, espe-
ao próximo passo? cialmente porque não há muitas informações entre os
dois elementos.
Uma caixa de texto com um cursor intermitente indican-
2b. Que ações a interface torna disponível?
do a primeira opção "Para".
Sim, pois a opção "Para" remete que, nesse campo,
O usuário associará o elemento correto à meta a ser
deve ser digitada alguma informação sobre o destinatá-
atingida?
rio – no caso, o e-mail.
Sim. Com o propósito igual a qualquer caixa de texto,
o campo ao lado de "Para" permite ao usuário digitar
algum texto. Nesse caso, foi observado que o usuário
intuitivamente digitará um e-mail por dois motivos:
3a. O elemento da interface revela seu propósito e com-
1 – Por se tratar de um e-mail, leva a pessoa a digitar um
portamento?
endereço eletrônico.
2 – Porque, no campo logo acima, "De", aparece o e-

-mail do usuário, mostrando a ele até um exemplo de
como deve ser a informação a ser digitada.
Sim. É possível identificar que o e-mail deve ser digitado
3b. O usuário consegue identificar os elementos da in- dentro da caixa de texto, especialmente porque o cursor
terface? está piscando dentro dela, o que pode levar o usuário a
pensar que ali está a primeira opção a ser preenchida.
Se a ação correta é tomada, o usuário perceberá que Sim, pois o usuário consegue perceber uma diferença
progrediu em direção à solução da tarefa? na interface.
4a. Como a interface apresenta o resultado de cada Mantendo visível o e-mail digitado na caixa de texto ao
ação? lado de "Para"
Sim, pois o resultado confirma a ação pretendida pelo
usuário, que foi digitar um e-mail. Quando o usuário vê
o que ele digitou, e essa informação se mantém durante
todos os próximos passos, o usuário tem a certeza de
que realizou algo com sucesso, especialmente quando
essa informação vai ao encontro de seu objetivo. Enfim,
o usuário pode visualizar o e-mail digitado até o fim da
tarefa. Um ponto positivo é que ele tem a liberdade de
alterar o e-mail no campo a qualquer momento.
AÇÃO DIGITAR O "ASSUNTO"

Sim, pois o próximo campo a ser preenchido está re-
lacionado com a ação pretendida. Essa característica
O usuário tentará atingir a meta correta? evita que o usuário fique perdido, pois, se tivesse mui-
tas opções sem sequência, ele poderia não saber o que
fazer.
Sim. A próxima caixa de texto é sobre o assunto.
1a. Dada a decomposição de uma tarefa em subtare-
fas, o usuário saberá por onde começar? Saberá qual Sim. Há outra caixa de texto maior, logo abaixo, que
é o próximo passo? pode permitir ao usuário pensar que ali pode ser digita-
do um texto longo, ou seja, uma mensagem.
Digitar o assunto na caixa de texto localizada ao lado
da opção "Assunto".
O usuário perceberá que a ação correta está disponí- Sim. Existe a caixa de texto em branco indicando que
vel? ali deve ser digitado algo.

AÇÃO DIGITAR O "ASSUNTO"

Em uma caixa de texto com tamanho grande após o
assunto. O tamanho da caixa de texto permite que o
usuário a visualize sem problemas e sem dificuldades,
ao próximo passo?
mesmo tendo algumas opções entre o campo "Assun-
to" e a caixa de texto para digitar a mensagem.
2b. Que ações a interface torna disponível? A caixa de texto para escrever o assunto.
O usuário associará o elemento correto à meta a ser Sim, pois a opção "Assunto" remete que, ali, deve ser
atingida? digitado o título ou o assunto do e-mail.
Sim. É visível que o campo ao lado de "Assunto" é uma
3a. O elemento da interface revela seu propósito e
caixa de texto; por isso, o usuário intuitivamente saberá
comportamento?
que é possível digitar algo.
3b. O usuário consegue identificar os elementos da in- Sim. Para essa ação, é possível identificar a caixa de
terface? texto e a sua finalidade.
Se a ação correta é tomada, o usuário perceberá que Sim, pois o usuário percebe algo diferente na interfa-
progrediu em direção à solução da tarefa? ce.
Mantendo visível o assunto digitado pelo usuário na
4a. Como a interface apresenta o resultado de cada
caixa de texto, permitindo que ele tenha a certeza de
ação?
que executou a ação de maneira satisfatória.
Sim. O objetivo a ser alcançado era digitar o assunto,
e, no final da ação, o usuário visualizará o assunto di-
gitado.
AÇÃO ESCREVER A MENSAGEM

Sim. Há uma caixa de texto com tamanho grande após
O usuário tentará atingir a meta correta?
a caixa de texto referente ao "Assunto".
Sim, pois há a caixa de texto com uma aparência que
também é padrão nos editores de texto de outros e-
-mails. É válido mencionar que, diferentemente das ou-
tras caixas de texto apresentadas até o momento, esta
não possui uma opção clara, por exemplo, em que está
escrito "Mensagem", mas é possível perceber que se
trata de um local para digitar mensagens por dois mo-
tivos:
1 – o tamanho da caixa de texto remete a um lugar em
1a. Dada a decomposição de uma tarefa em subtarefas, que pode ser digitado um texto longo – no caso, a men-
o usuário saberá por onde começar? Saberá qual é o sagem;
próximo passo?
2 – há algumas opções acima dessa caixa de texto se-
melhantes às de outros editores de texto para realizar
alterações no formato do texto. E, geralmente, essas
opções ficam localizadas logo acima da caixa de texto
para digitar a mensagem.
Sim. Há uma grande possibilidade de os olhos do usu-
ário passarem pela opção "Anexar um arquivo" quando
ele estiver vendo a caixa de texto "Assunto" e indo para
a caixa de texto em que se deve digitar a mensagem.
Nessa ação, ele digitará a mensagem desejada na cai-
xa de texto.
O usuário perceberá que a ação correta está disponí- Sim. Há a caixa de texto em branco que remete ao local
vel? em que deve ser digitada a mensagem.
2a. Onde está o elemento de interface correspondente Na mesma interface, um pouco acima da caixa de texto
ao próximo passo? em que o usuário está.
Disponibiliza uma caixa de texto em um tamanho dife-

2b. Que ações a interface torna disponível? rente das demais, o que sugere que deve ser digitado
um texto maior.
AÇÃO ESCREVER A MENSAGEM

Sim. É possível identificar o campo correto para digitar
a mensagem, especialmente porque a caixa de texto é
a última opção para a inserção de um texto. As outras
O usuário associará o elemento correto à meta a ser opções aparentemente já estão preenchidas, o que re-
atingida? mete ao usuário que ali seja o único campo viável para
digitar uma mensagem. Isto já não aconteceria se hou-
vesse vários campos em branco sem uma descrição ao
lado.
3a. O elemento da interface revela seu propósito e com- Sim. É possível identificar o que se pode fazer em uma
portamento? caixa de texto.
3b. O usuário consegue identificar os elementos da in- Sim. Dentre as caixas de texto existentes, é possível
terface? saber qual é a correta para digitar a mensagem.
Se a ação correta é tomada, o usuário perceberá que Sim. O usuário visualizará que o conteúdo da interface
progrediu em direção à solução da tarefa? vai se alterando conforme é digitada a mensagem.
Mostra o texto digitado enquanto o usuário está digi-
tando. Esse feedback imediato permite ao usuário ter a
ação?
certeza de que está fazendo a ação correta.
Sim, a ação pretendida era digitar uma mensagem.
4b. O resultado apresentado tem correspondência com Após essa ação, o usuário consegue visualizar toda a
o objetivo do usuário? mensagem digitada, podendo inclusive realizar altera-
ções nela.
AÇÃO ANEXAR ARQUIVO

O usuário tentará atingir a meta correta? Sim, há uma opção visível para "Anexar um arquivo".
Sim, pois, além da opção correta estar com um nome
intuitivo para a ação desejada, "Anexar um arquivo", ela
está localizada entre duas caixas de texto que o usuário
já utilizou. Assim, houve a possibilidade de o usuário ver
1a. Dada a decomposição de uma tarefa em subtarefas, essa opção. Destaque para o clipe localizado ao lado
o usuário saberá por onde começar? Saberá qual é o esquerdo do nome da ação. Esse símbolo é padrão nos
próximo passo? webmails; assim, o usuário poderá identificar o campo
tanto pelo que está escrito quanto pelo símbolo.
Sim. O usuário perceberá que a próxima ação é enviar o
e-mail que ele criou.
1b. O que o usuário vai tentar fazer a cada momento? Clicar sobre a opção "Anexar um arquivo"
Sim, porque a opção está com a aparência de um link,
de cor azul e sublinhado, o que permitirá ao usuário pen-
vel?
sar que a opção deve ser clicada.
2a. Onde está o elemento de interface correspondente A opção está localizada em dois locais distintos da inter-
ao próximo passo? face: acima e abaixo.
2b. Que ações a interface torna disponível? Um link com o nome "Anexar um arquivo".
Sim, pois a opção está em um formato (link) e em uma
O usuário associará o elemento correto à meta a ser linguagem adequada e, também, há um símbolo (clipe)
atingida? que permite ao usuário identificar o propósito do ele-
mento.
3a. O elemento da interface revela seu propósito e com- Sim, pois a opção possui todas as características e fun-
portamento? cionalidades de um link.
3b. O usuário consegue identificar os elementos da in- Sim. É possível perceber o link para realizar a ação e
terface? saber como utilizá-lo.
Se a ação correta é tomada, o usuário perceberá que Sim. Por meio da interface, é perceptível que algo esteja
progrediu em direção à solução da tarefa? acontecendo.

AÇÃO ANEXAR ARQUIVO

A interface exibe de duas formas o progresso da ação
do usuário. Essas formas se diferem quando o usuário
possui ou não o plugin flash. Observe quais são elas a
seguir:
1 – O nome do arquivo aparecerá, com barra de pro-
gressão, caso o usuário tenha instalado o plugin flash.
Por meio da barra de progressão, ele conseguirá per-
ação?
ceber o quanto de tempo ainda falta para o arquivo ser
anexado.
2 – Exibirá uma caixa de texto com o caminho do arqui-
vo. No entanto, nesse caso, não há indicação para o
usuário sobre o tempo que falta para o anexo ser con-
cluído.
4b. O resultado apresentado tem correspondência com Sim. No final da ação, o usuário consegue visualizar os
o objetivo do usuário? anexos inseridos por ele.
AÇÃO CLICAR NO BOTÃO "ENVIAR"

O usuário tentará atingir a meta correta? Sim, pois está visível a opção para realizar essa ação.
1a. Dada a decomposição de uma tarefa em subtarefas, Sim, pois há dois botões com o nome "Enviar", o que re-
o usuário saberá por onde começar? Saberá qual é o mete o usuário ao objetivo desse elemento na interface.
próximo passo? O próximo passo não há, pois este é o último passo.
1b. O que o usuário vai tentar fazer a cada momento? Clicar em um dos botões "Enviar"
Sim, o usuário perceberá que há dois botões para reali-
zar a ação pretendida. É possível afirmar que o usuário
verá, pelo menos, um dos botões, pela forma que eles
se encontram na interface.
O primeiro botão está localizado em um lugar de des-
taque; é a primeira opção a aparecer na nova página
(após o usuário clicar em "Escrever e-mail") do lado es-
vel?
querdo superior.
O segundo botão está localizado logo após a caixa de texto
utilizada para digitar a mensagem, e, como o usuário ficou
visualizando algum tempo a caixa de texto para digitar toda
a mensagem, é bem provável que ele tenha percebido que
também há um botão de enviar logo abaixo.
Não há próximo passo.
ao próximo passo?
2b. Que ações a interface torna disponível? Dois botões com o nome "Enviar".
O usuário associará o elemento correto à meta a ser Sim, pois o nome do botão remete à ação do usuário
atingida? com uma linguagem adequada e compreensível.
Sim, pois possui um formato que aparenta ser um botão.
Quando clicado, o feedback é adequado para o seu for-
3a. O elemento da interface revela seu propósito e com- mato. Especialmente quando o usuário clica sobre ele, a
portamento? animação do botão faz que o usuário tenha a impressão
de que ele realmente está sendo pressionado, uma vez
que a imagem parece "afundar".
Sim É possível perceber que existe, pelo menos, um bo-
tão para realizar a ação pretendida.
Nesse caso, em especial, a opção "Enviar" também po-
deria estar como link, pois o usuário já se acostumou;
ele sabe que, ao ver algo azul e sublinhado, é possível
clicar sobre, ou seja, tem a mesma funcionalidade que
3b. O usuário consegue identificar os elementos da in- o botão. Entretanto, foi considerado o formato de botão
terface? adequado por três motivos:
1 – formato e nome remetem à funcionalidade proposta;
2 – diferenciou essa opção das demais, sem poluir a
interface;
3 – seguiu o padrão dos outros editores de e-mail; por
isso, o usuário não ficará perdido ao ver esse formato.
Se a ação correta é tomada, o usuário perceberá que Sim, pois será exibida uma mensagem de confirmação
progrediu em direção a solução da tarefa? de envio ao usuário.
Caso o e-mail tenha sido enviado corretamente, apare-

4a. Como a interface apresenta o resultado de cada cerá a mensagem "sua mensagem foi enviada". Caso
ação? contrário, outra mensagem aparecerá, ou seja, de qual-
quer forma, o usuário possui um feedback do Gmail.
Sim, pois como o objetivo da tarefa é o envio de um
e-mail, a última mensagem da última ação teria de ir ao
encontro do objetivo para o usuário ter certeza de que
realizou com sucesso todas as ações necessárias para
executar a tarefa desejada.
o objetivo do usuário? Embora a mensagem final seja "sua mensagem foi en-
viada" e esta não seja exatamente a tarefa, no caso "seu
e-mail foi enviado", é possível perceber a relação entre
a mensagem e o e-mail, que são sinônimos para esse
caso. Assim, ambas levariam a compreensão de sua fi-
nalidade ao usuário.
A seguir, apresentaremos a interpretação dos resultados e as sugestões de melhorias.
Tabela 12 Interpretação dos resultados e das sugestões de melhorias.

O que ocasionou o proble-
Nrº Problema encontrado Local Soluções sugeridas
ma?
01 A falta de feedback ao ane- Na página para escre- Após clicar na opção "Anexar Há duas sugestões:
xar o arquivo caso não haja ver um e-mail. um arquivo", não foi visualizada 1 – Algum elemento que
plugin flash. Não há ele- nenhuma indicação de progres- mostre a progressão, como,
mento para indicar ao usu- são de envio do arquivo. por exemplo, a barra de
ário o tempo restante para progressão. Dessa forma,
que um determinado arqui- espera-se que o usuário
vo seja anexado. fique ciente de um tempo
aproximado de demora
para que um determinado
arquivo seja enviado com-
pletamente.
2 – Caso a opção anterior
não seja possível devido à
falta de plugin, recomenda-
se, ao menos, exibir uma
mensagem ao usuário, in-
formando que há um arqui-
vo sendo anexado.
02 Há uma opção utilizada Na página para escre- Existe uma opção na interface Há duas sugestões:
para criar uma janela dis- ver o e-mail. , do lado direito superior. 1 – Colocar um texto infor-
tinta para visualizar toda a mando sobre a funcionali-
Dois problemas foram encon-
interface existente na janela dade da opção mesmo que
trados nessa opção:
"Escrever um e-mail". Des- seja preciso passar o mou-
sa forma, é possível ver os 1 – Ao clicar nessa opção, é
se sobre ela.
e-mails da caixa de entrada criada, automaticamente, outra
página. No entanto, a partir do 2 – Melhorar o símbolo exis-
em uma janela e digitar o
momento em que essa janela é tente na opção. No lugar da
e-mail em outra. Contudo,
criada, não há possibilidade de flecha, poderia ser uma mi-
após criar essa página, não
voltar ao normal, ou seja, unir niatura da página.
há a possibilidade de voltar
ao normal. as duas páginas novamente.
Isto faz que o usuário perca sua
liberdade de retroceder a uma
ação.
2 - Essa informação precisa ser

melhor ilustrada, pois este sím-
bolo , bem como essa fun-
cionalidade, não são comuns
nos outros e-mails. Por isso, é
importante se preocupar se o
usuário conseguirá entender e
utilizar essa novidade de forma
satisfatória.

Está descrito na tabela anterior os dois problemas identificados durante o Percurso Cogni-
tivo da tarefa especificada, seguindo as ações definidas na Fase de Preparação.
Você pôde observar que, para cada problema, existem algumas sugestões que deverão ser
discutidas com os outros profissionais envolvidos no desenvolvimento do software, de modo a
escolher qual é a melhor forma para solucionar os problemas encontrados.
É válido mencionar que, para a ação "Anexar arquivo", não foi inspecionada a janela que
aparece ao clicar na opção "Anexar um arquivo" para encontrar e escolher o arquivo a ser anexa-
do. A inspeção não foi realizada porque essa janela faz parte do sistema operacional, e, por isso,
cada usuário pode ter um tipo de janela distinto. Espera-se, também, que, como é algo presente
no sistema operacional e padrão para realizar esse tipo de ação em vários outros softwares, o
usuário já tenha alguma familiaridade que permita a ele utilizá-la sem dificuldades.
Durante a aplicação desse método na tarefa especificada, alguns outros problemas foram
identificados. Todavia, apesar de fazerem parte da tarefa, elas não faziam parte das ações defini-
das; então, observa-se que não seria adequado unir problemas de outras ações em uma mesma
tabela, pois isto poderia confundir os outros profissionais, uma vez que eles estão preparados
para saber apenas dos problemas encontrados, seguindo as ações descritas anteriormente.
Entretanto, como objeto de estudo, percebeu-se que seria interessante descrever alguns
dos outros problemas existentes na interface, como uma forma de ilustrar o quão complexo e
detalhado é o método. A próxima tabela possui o relatório de avaliação de dois desses proble-
mas encontrados.
O primeiro problema está relacionado com a área que permite realizar a formatação da
mensagem digitada pelo usuário na caixa de texto. Apesar de a ação "formatar a mensagem"
fazer parte da tarefa "enviar e-mail", uma vez que o usuário pode querer alterar a cor da fonte,
aumentar o tamanho da letra, colocar alguma palavra em negrito, entre tantas outras opções
para destacar ou deixar a mensagem mais bonita para ser enviada, essa ação não foi definida
para ser avaliada.
O segundo problema encontra-se próximo ao botão "Enviar" que foi avaliado – é o outro
botão, com o nome "Descartar". Esse problema, além de ser outra ação, poderia fazer parte de
outra tarefa ao invés de "enviar e-mail", poderia ser "descartar e-mail", mas, mesmo tendo es-
sas diferenças, optou-se por abordar o problema.
É válido lembrar que a não definição dessas ações não foi uma falha, apenas foi reduzido o
número de ações para que o Percurso Cognitivo das ações definidas pudesse ter mais detalhes.
Esta é uma estratégia adotada por muitos profissionais e por muitas empresas que fazem essa
inspeção, pois, devido ao número de detalhes e o tempo para que essa inspeção seja realizada,
na maioria das vezes, são escolhidas as ações principais para realizar uma tarefa. Em nosso caso,
que era para enviar um e-mail, percebeu-se que as ações básicas e realmente necessárias para
concluir a tarefa são as seis descritas na Fase de Preparação.
Ressalta-se que este é um ponto negativo do método, pois ele permite escolher as ações
que se deseja avaliar isto reforça a importância da "Fase de Preparação", pois, ao escolher ações
desnecessárias ou não escolher as ações que serão importantes para o usuário realizar a tarefa,
isto pode prejudicar o resultado da inspeção. No primeiro caso, haverá desperdício de tempo
e dinheiro, uma vez que haverá um ou mais profissionais alocados para realizar a inspeção de
ações que não são importantes e, no segundo caso, não haverá uma inspeção adequada de
todas as ações que influenciam, diretamente, a realização da tarefa, o que pode prejudicar a
afirmação de que a interface está usável.
Tabela 13 Relatório de avaliação de dois problemas encontrados.

Nrº Problema encontrado Local O que ocasionou o problema? Soluções sugeridas
01 Linguagem não co- Na página para escre- Logo acima da caixa de texto Alterar símbolos dos botões. Ao
mum na edição de ver o e-mail. para digitar mensagem, existem invés de "B" e "U", inserir op-
texto. algumas opções com a possi- ções em português, como "N" e
bilidade de formatar o texto. No "S", respectivamente. Informa-
entanto, há opções que podem ções essas comumente encon-
não ser conhecidas pelo usuário, tradas em softwares brasileiros.
e isto pode dificultar a compre- As opções para alterar a fonte
ensão das opções e a sua utili- e o tamanho poderiam ser al-
zação. teradas para símbolos comuns
Por exemplo, as opões " " " nos softwares brasileiros, como
" estão em outra língua, ou para
seja, não estão em português. alterar a fonte e
No caso, o "B" significa bold, em para alterar o seu tamanho.
inglês, que, em português, seria Esses símbolos, além de serem
negrito; e o "U" é de Underline, mais comuns, expressam as
em inglês, e, em português, se- suas funcionalidades.
ria sublinhado. Há outras opções
Sugere-se que os outros sím-
que, embora estejam em outra
bolos sejam comparados aos
língua, se assemelham com a
softwares utilizados no Brasil,
forma com que os brasileiros fa-
como o Microsoft Word©, pois,
lam, no caso " " para alterar
seguindo o padrão, haverá uma
a fonte e a opção e " " para
garantia maior das opções a
alterar o tamanho do texto.
serem compreendidas pelo usu-
Apesar de terem semelhanças ário.
com o português, esses símbo-
los não são intuitivos o que pos-
sibilita que suas funcionalidades
sejam percebidas de imediato.
02 O nome do botão "Des- Na página para escre- O botão "Descartar", que está Substituir a opção "Descartar"
cartar" não é tão co- ver o e-mail. tanto no lado superior direito por "Excluir", pois, além desse
mum em e-mails. quanto inferior direito, possui nome ser mais utilizado em e-
uma linguagem diferente dos -mails, ele também é utilizado
outros e-mails. O que pode "ra- em um sistema operacional
ramente" causar uma falta de utilizado pela maioria dos bra-
compreensão. sileiros.
O "raramente" é porque, apesar
de o botão estar escrito com
nome distinto, é possível identi-
ficar a sua utilização. No entanto,
espera-se que, com nome mais
comum e utilizado com mais
frequência pelo usuário, existe
a possibilidade de ser compre-
endido melhor e de maneira ime-
diata pelo usuário.

tam da temática desenvolvida nesta unidade.
A autoavaliação pode ser uma ferramenta importante para você testar o seu desempenho.
Se você encontrar dificuldades em responder a essas questões, procure revisar os conteúdos
estudados para sanar as suas dúvidas. Esse é o momento ideal para que você faça uma revisão
desta unidade. Lembre-se de que, na Educação a Distância, a construção do conhecimento ocor-
re de forma cooperativa e colaborativa; compartilhe, portanto, as suas descobertas com os seus
colegas.
unidade:

1) Imagine a seguinte situação: uma empresa contratou você para inspecionar uma interface e ela deseja saber se
o público-alvo definido para o software desenvolvido vai conseguir entender e utilizar as opções na interface.
No entanto, a empresa relata que não haverá usuários para a inspeção devido aos custos que isto agregaria.
Qual dos métodos a seguir você escolheria para realizar a inspeção?
a) Checklists.
b) Avaliação Heurística.
c) Percurso Pluralístico.
d) Percurso Cognitivo.
e) Teste de Usabilidade.
2) O Percurso Cognitivo é divido em três fases: Preparação, Avaliação e Interpretação. Em cada fase, existem algu-
mas questões que devem ser respondidas ou, no caso da interpretação, algumas opções que devem ser preen-
chidas em uma tabela. Esta é uma forma de organizar melhor os dados para depois serem compreendidos mais
facilmente por outros profissionais. Na fase de Preparação, existem algumas perguntas que são importantes
para se pensar em como será a inspeção; no total, são quatro perguntas básicas. Das perguntas a seguir, qual
delas não faz parte dessas quatro questões?
a) Qual é a sequência correta de ações para cada tarefa?
b) Quais são as tarefas que serão analisadas?
c) Qual é a linguagem de programação utilizada no desenvolvimento?
d) Qual é a interface definida?
e) Quem são os usuários do software?
Gabarito
Depois de responder às questões autoavaliativas, é importante que você confira o seu
desempenho, a fim de que possa saber se é preciso retomar o estudo desta unidade. Assim, con-
fira, a seguir, as respostas corretas para as questões autoavaliativas propostas anteriormente:
As respostas corretas para cada questão são:
1) d.
2) c.
13. CONSIDERAÇÕES
Avaliar o sistema utilizando e as estratégias descritas nesta unidade é uma forma de ga-
rantir que aquilo que foi feito realmente considerou as características dos usuários, e que todas
as opções e informações, enfim, tudo o que há no sistema, de alguma maneira está acessível,
usável e é útil. No entanto, considere todos os conceitos aprendidos nessa unidade, não somen-
te no momento de avaliação, mas também no momento do planejamento e desenvolvimento
do seu sistema.
Pense que, ao considerar todos esses conceitos, você estará se prevenindo e evitando
muito retrabalho no final. Retrabalho esse que, em muitos casos, seria desnecessário se, duran-
te o planejamento, na conversa com o usuário e em outras etapas anteriores, todo esse cuidado
fosse tomado.
14. EͳREFERÊNCIAS
ANACLETO, J. C. Tópicos em Engenharia de Software. O Projeto de Interação – Questões de Usabilidade – Um Estudo de Caso.
Disponível em: <http://www2.dc.ufscar.br/~junia/index-topicos.htm> Acesso em: 8 jul. 2010.
CYBIS, W. A. ErgoList. Disponível em: <http://www.labiutil.inf.ufsc.br/ergolist/> Acesso em: 10 fev. 2010.
GODINHO, F. Noções de acessibilidade a web. Disponível em: <http://www.acessibilidade.net/web/> Acesso em: 1 fev. 2010.
NIELSEN, J. Heuristic Evaluation. Disponível em: <http://www.useit.com/papers/heuristic/> Acesso em: 21 mar. 2010.

CARLOS, A. J. F. Aplicando senso comum na edição de objetos de aprendizagem. Dissertação de Mestrado. Programa de Pós-
graduação em Ciência da Computação: UFSCar, 2007.
CYBIS, W. A. et al. Abordagem para o desenvolvimento de listas de verificação de usabilidade sistemáticas e produtivas. Tradução
de Latin American Congress on Human-Computer Interaction. Rio de Janeiro, 2003.
JOHN, B. E.; KIERAS, D. E. The GOMS family of user interface analysis techniques: comparison and contrast. ACM Transactions on
Computer-Human Interaction, v. 8, n. 3, p. 320-351, 1996.
LEWIS, C.; RIEMAN, J.; WHARTON, C. Cognitive walkthroughs: a method for theory-based.
LEWIS, C.; WHARTON, C. Cognitive walkthroughs. In: HELANDER, M.; LANDAUER, T. K.; PRABHU, P. (Eds.) Handbook of human-
computer interaction. Elsevier Science, 1997, p. 717-7
MANO, A.; CAMPOS, J. C. Aplicação de um cognitive walkthrough: estudo de caso. Interacção 2004 – Conferência Nacional em
Interacção Pessoa-Máquina, Lisboa, 2004.
NIELSEN, J. Heuristic Evaluation. In: NIELSEN, J; MACK, R. Usability Inspection Methods. John Wiley & Sons, 19p. 25-62.
______. Projetando websites. Rio de Janeiro: Campus, 2000.
NIELSEN, J.; TAHIR, M. Homepage usabilidade: 50 websites descontruídos. Rio de Janeiro: Campus, 2002.
NORMAN, D. A. Cognitive Engineering. In: NORMAN, D. A.; DRAPER, S. W. (Eds.) User Centered System Design. Hillsdale, 19p.
31-61.
PRATES, R. O.; BARBOSA, S. D. J. Avaliação de interfaces de usuário: – conceitos e métodos. Campinas – Brasil. In: XXII Jornada
de atualização em informática em anais do XXIII congresso da sociedade brasileiro de computação, 2003.
SALGADO, L. C. C.; BIM, S. A.; SOUZA, C. S. Comparação entre os métodos de avaliação de base cognitiva e semiótica. Natal –
Brasil In: Simpósio Sobre Fatores Humanos em Sistemas Computacionais (IHC), 2006.
SHNEIDERMAN, B. Designing the user interface: strategies for effective human-computer interaction. Estados Unidos: Addison-
Wesley, 1998.
SILVA, M. A. R. O uso de senso comum no apoio a jogos narrativos para crianças em idade escolar. Dissertação de Mestrado.
Programa de Pós-graduação em Ciência da Computação, Universidade Federal de São Carlos, 2009.
SOUZA, C. S.; LEITÃO, C. F. Contribuições da engenharia semiótica para os métodos científicos de pesquisa em IHC. Porto Alegre
– Brasil In: Simpósio Sobre Fatores Humanos em Sistemas Computacionais (IHC), 2008.
WHARTON, C. et al. Applying Cognitive Walkthroughs to More Complex User Interfaces: experiences, issues, and recommendations.
In: ACM CHI Conference Proceedings. Monterey – USA, 1992.
WHARTON, C.; RIEMAN, J.; LEWIS, C. The cognitive walkthrough method: a practitioner´s guide. In: NIELSEN, J; MACK, R. Usability
Inspection Methods. John Wiley & Sons, 19p. 105-140.

EAD
IHC na Web
1. OBJETIVOS
• Entender a importância da IHC na web.
• Conhecer o uso dos padrões para desenvolver interfaces úteis, usáveis e acessíveis.
2. CONTEÚDOS
• História do Padrão.
• Padrões de Montero.

guir:
1) Recomendamos o acesso ao seguinte endereço eletrônico: <http://noticias.r7.com/
tecnologia-e-ciencia/noticias/acesso-a-internet-no-brasil-cresce-75-3-em-tres-
anos-20091211.html>. Nele, você encontrará estatísticas que comprovam o cresci-
mento dos acessos à web. Poderá também pesquisar em outros sites que possuem
estatísticas de quais são os tipos de usuários que acessam à web, bem como de qual
é o perfil dos usuários que utilizam tal recurso.
2) Com base nos conteúdos estudados até o momento, faça um simples exercício: sele-
cione alguns sites que você gosta ou que costuma acessar e analise as características
que o fazem apreciá-los. Em seguida, identifique quais são as características que as
interfaces desses sites têm em comum. Assim, você terá a noção de um dos conteúdos
que serão abordados no decorrer desta unidade.
3) Sugerimos que você realize uma pesquisa na web, buscando artigos, fotos etc., de
assuntos relacionados às seguintes palavras-chave: "site", "interface", "interação
humano-computador" e "padrão". Com essa pesquisa, você poderá obter resultados
interessantes, que contribuirão para o seu conhecimento sobre a IHC, porém com
ênfase na web.
Preocuparmos-nos com a IHC será essencial para o desenvolvimento de qualquer sistema
computacional, seja ele para computadores do tipo desktop ou móvel (celulares e IPhone) como
também para sistemas embarcados encontrados em forno micro-ondas, em relógio etc., afinal,
todos esses sistemas foram criados para que as pessoas os utilizem.
Nesta unidade, em especial, estudaremos a influência e a importância da IHC para o de-
senvolvimento de sistemas web. Contudo, vale ressaltar que o conteúdo abordado pode ser
utilizado para o desenvolvimento de qualquer tipo de sistema, inclusive para web, ou seja, é
possível pensar nos fatores humanos, utilizar o Projeto Centrado no Usuário, a Prototipação, a
Avaliação Heurística, entre outros conceitos estudados até aqui. Contudo, o estudo específico
da IHC na web é interessante devido às diferentes características que os sistemas web possuem
e ao crescimento do número de pessoas que utilizam esse tipo de sistema.
Segundo o IBGE (Instituto Brasileiro de Geografia e Estatística), o percentual de brasileiros
que acessam a internet chegou a 34,8%, o que representa 56 milhões de usuários. Esse índice,
que se refere a 2008, teve um aumento de 75,3% em relação a 2005, quando 20,9% da popula-
ção usavam a web (NOTÍCIAS R7, 2010).
Outro dado relevante é que a pesquisa registrou que o uso da rede predomina entre as
pessoas com maior grau de escolaridade. Entre aqueles, com pelo menos 15 anos de estudo, o
percentual de pessoas que utilizam a internet é de 80,4% – levando em consideração as pessoas
que estudaram dos 11 aos 14 anos, o índice é de 57,8%. Já entre as pessoas com menos de qua-
tro anos de estudo, o percentual chega a 7,2%. Contudo, segundo o IBGE, entre 2005 e 2008, o
maior crescimento aconteceu na categoria que inclui as pessoas com menos escolaridade.
Percebeu o que esses dados mostram? Por meio dessa pesquisa é possível notar que uso
da internet está em pleno crescimento no Brasil, ou seja, investir no desenvolvimento de siste-
mas para web pode ser um negócio bom e vantajoso. Mas perceba que além do crescimento,
há uma grande diversidade (por grau de instrução, região do Brasil, cultura etc.) de pessoas que
acessam a internet.
Assim, ao contrário de sistemas para desktop, por exemplo, para uma empresa específica,
quando você desenvolve sistemas para web é mais complicado pensar nos fatores humanos de
um grupo de pessoas com uma cultura, pois outras pessoas também terão acesso ao sistema,
por isso é importante que qualquer pessoa consiga acessar e navegar.
Lembre-se de que, mesmo que um sistema web possa ser acessado por qualquer pessoa,
é sempre importante pensar em um público-alvo. Por exemplo, será um site para crianças de
uma determinada faixa etária, com um grau de escolaridade, para mulheres com algumas carac-
terísticas específicas, que recebem uma certa renda etc. Há, porém, estratégias que podem ser
utilizadas para desenvolver o mínimo, para que qualquer pessoa utilize o sistema.
A estratégia que apresentaremos nessa unidade é chamada de "Padrão". Observe que
uma pessoa pode acessar várias paginas web no mesmo dia ou, até no mesmo, minuto. Então,
© U6 – IHC na Web 139
imagine a dificuldade que essa pessoa teria se cada site acessado cobrasse uma forma de inte-
ragir totalmente distinta, com menus, informações, botões e outras características diferentes
uma das outras.
Com certeza, a navegação nesses sites seria muito complicada, pois, naturalmente, as pes-
soas utilizam o que aprenderam e/ou já estão acostumadas para realizar as ações, assim, a
maneira que uma pessoa navega em um determinado site vai influenciar na navegação de outro
site. Por isso há a importância de utilizar o padrão, ou seja, algo conhecido e já assimilado pelas
pessoas no desenvolvimento de sistemas computacionais, especialmente para web, em que a
quantidade e diversidade de pessoas é bem maior.
Curiosidade ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Antes de iniciarmos a explicação de um padrão web, apresentaremos uma descrição da história do padrão. Esse
assunto é interessante e útil para você perceber a evolução e a importância de se utilizar os padrões.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
5. HISTÓRIA DO PADRÃO
A ideia de padrão surgiu de um arquiteto chamado Alexander (ALEXANDER et al., 1977),
que planejava e construía prédios e casas para as pessoas. Depois de anos de experiência, Ale-
xander percebeu que quando falava de um determinado assunto relacionado à construção, o
cliente não o entendida e, portanto, a comunicação tornava-se complicada, pois, às vezes, fala-
va algo e o outro pensava diferente ou vice-versa. Com isso, Alexander descobriu que, ao ilustrar
algo para o cliente, ficava mais fácil a comunicação, porque, se o cliente "visse" o que estava
sendo falado, era mais fácil para ele entender e expor as suas opiniões.
Durante a sua carreira, Alexander também observou que, muitas vezes, os mesmos pro-
blemas sempre se repetiam, mas, devido à sua experiência, já conhecia algumas maneiras de
solucioná-los, por isso teve a ideia de documentar essas soluções para os problemas, conside-
rando um determinado contexto. Por exemplo, se o cliente quisesse uma piscina em sua casa,
poderia ter um padrão que informasse qual a melhor maneira de se construir essa piscina e uma
imagem ilustrando como seria o resultado final. Assim, o arquiteto tinha em mãos algo impor-
tante para ajudá-lo a construir a piscina, juntamente com uma imagem para conversar com o
cliente.
Nesse contexto, surgiu a ideia de padrão, um documento que constava a solução para um
determinado problema. É importante lembrar que algo só é definido como padrão quando a
solução é aplicada várias vezes, em um mesmo problema, e o resultado obtido é satisfatório.
Por isso, quando seguimos um padrão, podemos ter a certeza de estar seguindo algo que já foi
utilizado por muitas pessoas e que, na maioria dos casos, obteve resultado satisfatório.
Outras áreas também começaram a utilizar essa estratégia, inclusive a computação, po-
rém, nesta área, a ênfase foi em utilizar os padrões para transmitir conhecimento entre profis-
sionais, ou seja, se um profissional vai desenvolver um sistema, ele pode utilizar os padrões já
definidos para garantir, também, a qualidade ao sistema, pois ele seguirá algo que foi compro-
vadamente eficaz (BORCHERS; FINCHER; GRIFFITHS; PEMBERTON; SIEMON , 2001).
A seguir, apresentaremos alguns padrões conhecidos e utilizados para desenvolver siste-
mas web, chamados de Padrões de Montero.

6. PADRÕES DE MONTERO
Os padrões propostos por Montero et al. (2002) para projeto de sites web abrangem, sufi-
cientemente, todos os aspectos da interação web. A Figura 1, a seguir, apresenta os 23 Padrões,
que são divididos em três categorias: web site, páginas web e ornamentais.
Os Padrões da categoria web site apresentam características comuns que são encontradas
em vários sites web e podem ser aplicados em diversos domínios. Os Padrões da categoria pági-
nas web estão relacionados ao projeto específico de uma página, apresentando elementos e ca-
racterísticas comuns quando se projetam sites. E os Padrões da categoria ornamentais apresen-
tam características decorativas para o site, preocupando-se, também, com a sua usabilidade.
Fonte: MONTERO et all., 2002, p. 138.

Figura 1 Linguagem de padrões para projeto de sites web.
Observe que nos padrões descritos por Montero há um padrão ligado ao(s) outro(s), isso
é para você saber, que, no momento em que for aplicar um padrão, outros também poderão
ser utilizados para complementá-lo. A seguir, são descritos cada um dos Padrões agrupados por
web sites, páginas web e ornamentais.
7. PADRÕES DE WEB SITES

Os Padrões de web sites são cinco: Welcome, Polyglot, Ready, Indication e Similatity.
Welcome
Contexto:
Quando um usuário acessa um web site, ele necessita saber onde está, o que pode fazer e
o que necessita para visitar o lugar.
Problema:
Como o usuário sabe onde ele está?
Solução:
Forneça um lugar para a recepção, em que as condições de acesso possam ser avaliadas:
• Permita ao usuário entrar na homepage e em outros locais do site (Indications).
• Obtenha informações do usuário (linguagem e resolução) (Ready).
• Informe sobre as melhores condições para visitar o site (Polyglot).
• Informe sobre o conteúdo (About This) e o seu proprietário (Contact Us).
Observação: –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Em muitas ocasiões, Welcome e Homepage são a mesma página.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Como exemplo, observe a Figura 2, representada a seguir:
Figura 2 Exemplo Welcome.
Polyglot
Contexto:
Permitir o acesso a todos.
Problema:
Como o usuário utiliza com sucesso o web site e as informações acessadas em seu próprio
ritmo?

Solução:
Utilizar a linguagem do usuário é "projetar para todos":
• Aplique técnicas de projetos universais.
• Forneça aos usuários informações, para que eles saibam se podem visitar o site sem
problemas (Ready).
• Considere o tamanho do monitor, a resolução da tela do usuário, a velocidade de cone-
xão, o tempo de download, as fontes familiares e seus tamanhos (Danger).
• Forneça as informações de modo apropriado (Polite).
Como exemplo, veja a Figura 3, a seguir:
Figura 3 Exemplo Polyglot.
Ready
Contexto:
Os usuários que desejam visitar seu web site precisam instalar os plug-ins necessários.
Problema:
Como o usuário sabe que poderá visitar um web site sem problemas?
Solução:
Forneça ao usuário as ferramentas ou informações necessárias para que ele possa visitar
o web site de maneira adequada:
• O site poderá detectar se o usuário possui tudo o que é necessário e fornecer links para
download.
• O usuário não necessita saber de aspectos técnicos (Polite).
• Garanta que as páginas sejam usáveis mesmo quando scritps, applets ou objetos pro-
gramáticos estão desligados ou não são suportados.
• Forneça as informações em uma página alternativa acessível (Polyglot).
Como exemplo, observe a Figura 3, representada a seguir:
Figura 4 Exemplo Ready.
Indication
Contexto:
Os usuários necessitam saber em quais lugares podem ir e o que eles podem fazer tendo
como referência o ponto em que estão.
Problema:
Como os usuários sabem onde podem ir e o que eles encontrarão no lugar em que esti-
verem?
Solução:
Forneça o mecanismo necessário (links significantes) que permitam ao usuário mover-se
de um lugar para outros:
• Forneça as informações de feedback sobre sua localização.
• Possibilite o retorno (Second chance) para um lugar seguro (Homepage).
• Coloque links importantes no alto da página.
• Rótulos de links descritivos podem ser utilizados (Polite).
• Se utilizar frames, coloque um título em cada um.
Como exemplo, observe a Figura 5:

Figura 5 Exemplos Indication.
Similarity
Contexto:
Quando o usuário está navegando pela internet, ele precisa saber se está no mesmo web
site ou não.
Problema:
Como o usuário sabe se está visitando o mesmo web site?
Solução:
Projete o site utilizando os mesmos critérios: cores, fontes, localização de navegação e
layout.
• Use uma única folha de estilo para todas as páginas.
• Organize os documentos de modo que sejam lidos sem folhas de estilo (Polyglot).
• Informe o usuário, de maneira adequada (Polite), onde ele está (Location) e onde pode
ir (Indication).
• Ofereça mecanismo de desfazer/refazer (Second chance).
• Evite utilizar componentes que possam confundir o usuário (Danger).
Observe os exemplos apresentados na Figura 6, a seguir:
Figura 6 Exemplos Similarity.
8. PADRÕES DE PÁGINA WEB

Os Padrões de páginas web são seis: Homepage, Second Chance, Form, Busy, Polite e Dan-
ger.
Homepage
Contexto:
Uma página é acessada de várias maneiras, entretanto, deve haver um ponto de referên-
cia, que responda às questões: Com quem? O quê? Quando? Onde?
Problema:
Como o usuário sabe onde ele está?
Solução:
Forneça uma página inicial em que o usuário se sinta à vontade:
• Homepage: local para que o usuário pode retornar se estiver desorientado.
• Layout do site: contém as informações importantes no topo da página (Novelty).
• Incluir logos (Tag line), mecanismos de busca (Search) e informações para contato
(Subscription, Contact us, about this).
Como exemplo, veja a Figura 7, representada a seguir:

Figura 7 Exemplo Homepage.
Second Chance
Contexto:
O usuário quer controlar as suas operações.
Problema:
Como o usuário pode ter certeza de suas ações?
Solução:
Forneça elementos para desfazer/refazer, voltar e limpar:
• Forneça links para as páginas anteriores, os lugares anteriores ou a homepage.
• No formulário (Form), apresente dois botões: submit e reset.
Veja o exemplo representado pela Figura 8, a seguir:
Figura 8 Exemplos Second Chance.

Form
Contexto:
O usuário necessita fornecer as informações.
Problema:
Como o usuário fornece as informações para o proprietário do web site?
Solução:
Apresente "brancos" apropriados para serem preenchidos, com indicativo claro e correto
de qual informação deve ser fornecida:
• Em algumas ocasiões, um formulário pode ocupar uma página inteira (completa).
• O usuário precisa saber se a sua submissão foi corretamente processada (Busy).
Observe, como exemplo, a Figura 9, representada a seguir:
Figura 9 Exemplo Form.

Busy
Contexto:
Fazer downloads pode demorar muito tempo, gerando atrasos significantes ou sendo
completados de modos diferentes.
Problema:
Como o usuário sabe quando suas operações terminaram?
Solução:
Forneça feedback ao usuário:
• Apresente informações sobre o tamanho de qualquer elemento que o usuário pode
fazer download.
• As imagens e os textos podem ser carregados sobre demanda (Size).
Veja o exemplo a seguir:
Figura 10 Exemplo Busy.
Polite
Contexto:
As pessoas utilizam diferentes termos para descrever os conceitos.
Problema:
Como o usuário acessa o conteúdo da página de modo simples e apropriado?
Solução:
Use a linguagem apropriada de maneira simples e clara para o conteúdo do site:

• Use rótulos associados aos seus controles (Indication).
• Expresse uma ideia em cada sentença (Tag Line).
• Use métodos, quando possível (como aqueles do Design participativo e Classificação de
cartões), que envolvam o usuário.
A seguir, observe a Figura 11 como exemplo:
Figura 11 Exemplo Polite.
Danger
Contexto:
Há um excesso de plug-ins disponíveis. Mas não se pode assumir que qualquer um os terá
ou usará uma particular configuração do computador.
Problema:
Como o usuário pode visitar um web site e não ficar confuso, desorientado ou ser inter-
rompido?
Solução:
Seja cuidadoso ao usar componentes desorientadores:
• Use fonte legível e cabeçalhos bem definidos, considere o tamanho do monitor, limite
o número de frames, gifs animados, flash, applets, músicas, rollovers, reduza a carga
de trabalho, não use blink ou elementos marquee e limite o tamanho da página (Size,
Colour).
• Use uma folha de estilo para controlar o layout e a apresentação.

Observe o contraexemplo apresentado pela Figura 12:
Figura 12 Contra-exemplo Tag Line.
9. PADRÕES ORNAMENTAIS
Os Padrões de web sites são 12: Tagline, About This, Search, Novelty, Contact Us, Secret,
Subscription, Recognise You, Location, Colour, Size, Print.
Tagline
Contexto:
É necessário conhecer a proposta do web site.
Problema:
Como o usuário sabe qual é o propósito do web site?
Solução:
Forneça um slogan ou uma imagem que identifique o web site e o seu propósito:
• Resumido, simples e direto.
• Inclua uma descrição do site na janela do navegador.
Observe a Figura 13, como exemplo, a seguir:
Figura 13 Exemplo Tagline.
About This
Contexto:
Todo web site deve apresentar uma maneira fácil de encontrar informação sobre a companhia.
Problema:
Como o usuário pode conseguir informações adicionais sobre o web site?
Solução:
Inclua um link para uma sessão "Sobre o site".
Como exemplo, observe a Figura 14, apresentada a seguir:
Figura 14 Exemplo About This.
Search
Contexto:
A busca é um dos principais elementos da homepage. É essencial que os usuários a utili-
zem de uma maneira fácil e sem esforço.
Problema:
Como o usuário saberá se o web site pode fornecer as informações que ele deseja?
Solução:
Forneça uma ferramenta de busca na homepage ou uma página com visão geral do web site.
A seguir, veja a Figura 15, como exemplo:

Figura 15 Exemplos Search.
Novelty
Contexto:
Os usuários gostam de saber se existem novas funcionalidades, promoções, ofertas e no-
ticias no web site.
Problema:
Como o usuário saberá as novidades e as últimas notícias do web site?
Solução:
Forneça sugestões e novidades do web site de maneira limpa e intuitiva.
Veja a Figura 16, como exemplo:
Figura 16 Exemplo Novelty.
Contact Us
Contexto:
Todo web site deve fornecer um meio de contato.
Problema:
Como o usuário pode pedir informação adicional sobre o conteúdo do web site?
Solução:
Forneça um formulário, um local ou um link no web site em que o usuário possa conseguir
as informações adicionais sobre o proprietário e os produtos do web site.
Observe o exemplo a seguir, na Figura 17:
Figura 17 Exemplo Contact Us.
Secret
Contexto:
Se o usuário oferece informações privadas, ele necessita saber a confiabilidade do sistema.
Problema:
Como o usuário pode ter certeza de que a informação fornecida será protegida?
Solução:
Forneça os mecanismos de segurança (acesso e privacidade) necessários para proteger o
usuário e o web site e informe ao usuário as condições de segurança.
Veja como exemplo, a Figura 18, apresentada a seguir:

Figura 18 Exemplo Secret.
Subscription
Contexto:
Os usuários não desejam visitar o web site a todo o momento, mas, sim, saber quando os
novos produtos ou novidades aparecem.
Problema:
Como o usuário ficará sabendo de informações significativas para ele?
Solução:
Forneça um formulário, no qual o usuário pode conseguir a informação desejada, auto-
maticamente:
• O usuário deve ter certeza de que seu email não será divulgado a todos (Secret).
Observe os exemplos a seguir, representado pela Figura 19:
Figura 19 Exemplos Subscription.
Recognize
Contexto:
Quando o usuário volta a um web site, ele necessita saber sobre as ações executadas na
sua última visita.
Problema:
Como o usuário pode saber em qual lugar ele já esteve?
Solução:
Guarde as informação sobre as ações do usuário, locais visitados, logins, documentos sal-
vos etc.:
• Uso de cookies.
• Links visitados.
Veja como exemplo, a Figura 20, mostrada a seguir:

Figura 20 Exemplo Recognize.
Location
Contexto:
Quando o usuário chega a um web site, ele precisa saber em qual lugar ele está.
Problema:
Como o usuário sabe em qual lugar ou qual é a sessão que ele está?
Solução:
Forneça informações sobre a localização do usuário no web site.
Observe o exemplo, representado pela Figura 21:
Figura 21 Exemplo Location.

Colour
Contexto:
A cor deve ser considerada no início do projeto de um web site.
Problema:
Como o usuário pode acessar as informações de maneira adequada?
Solução:
Forneça a informação usando cores adequadas nas fontes, nos fundos de tela e nas ima-
gens:
• Mudança de cores em links visitados e não visitados.
• Tenha cuidado com o contraste de cores.
• Use cores brilhantes somente para destacar informações.
Veja o exemplo, representado a seguir, pela Figura 22:
Figura 22 Exemplo Colour.
A cor utilizada no web site é um assunto que nem sempre tem a devida atenção, pois não
são todas as pessoas que se preocupam, mas ela pode influenciar diretamente na maneira que o
usuário interage com a ferramenta. O primeiro conceito que você deve ter em mente quando for
aplicar a cor em um web site é que a forma que lemos um site é diferente da forma que lemos
um livro, pois a leitura em web sites não é linear. Veja a Figura 23 a seguir:

Figura 23 Sequência de leitura em web sites.
Nos web sites, os olhos das pessoas procuram, primeiro, os elementos maiores e escuros
e, depois, os elementos menores e claros. Essas informações devem ser consideradas para im-
plementar sites, pois, por meio delas, você pode destacar alguma informação ou deixá-la sem
ênfase.
Outra herança que temos da leitura em papel é utilizar o branco no fundo dos textos e os
sites herdaram dos livros essa característica, afinal, os livros, geralmente, possuem esse padrão
do papel branco com o texto preto. Contudo, atualmente, a maioria dos monitores exibe um
branco brilhante e, por isso, há dificuldade em ler um texto com a cor preta. Uma combinação
interessante e eficaz para os monitores é um fundo pastel com o texto preto.
A escolha das cores no site, também não é algo difícil de fazer. Por isso, uma dica útil é
considerar o Círculo Cromático, conforme a Figura 24, que possui cores distribuídas em um cír-
culo de forma lógica e organizadas de acordo com cada tom. Esse círculo foi definido por Silveira
(2002) e Guimarães (2000) para facilitar a aprendizagem, a utilização e a mistura de cores.
Ciano
Ciano-Violetado Ciano-esverdeado
Azul-Violetado Verde
Magenta-Violetado Verde-amarelado
Magenta Amarelo
Vermelho-amagentado Laranja
Vermelho
Fonte: SILVEIRA, 2002, p. 8.
Figura 24 Círculo cromático.
Várias estratégias podem ser aplicadas por intermédio do Círculo Cromático (SILVEIRA,
2002). Nesta unidade, são apresentadas as combinações de cores, pois podem ser feitas com
cores próximas e cores complementares. Embora existam essas possibilidades, apenas uma des-
sas combinações gera um resultado eficaz. Observe a Figura 24 e veja que há um círculo e várias
cores em uma sequencia lógica.
Observação: ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Quando falamos em cores próximas, significa cores que estão próximas no Círculo Cromático, por exemplo, laranja
e amarelo ou verde e ciano. Já as cores complementares são aquelas que são opostas no Círculo Cromático, por
exemplo, azul e amarelo ou verde e vermelho etc.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Observe, na Figura 25, que o uso dessas cores apresenta um contraste baixo e isso faz
com que o texto seja menos legível e consequentemente haverá a necessidade de aumentar o
tamanho da letra.
Figura 25 Exemplos de cores próximas.
Agora, observe que, na Figura 26, já é possível perceber que o uso das cores complemen-
tares permite um contraste alto e isso faz com que o texto seja mais legível. Por isso esse é o tipo
de combinação que deve ser prioridade no desenvolvimento de páginas web. A utilização desse
Círculo Cromático é uma maneira eficaz de verificar se, por meio das combinações, o resultado
será satisfatório ou não.

Figura 26 Exemplos de cores complementares.
Size
Contexto:
Balanceamento entre gráficos e tempo real.
Problema:
Como o usuário pode acessar informações de maneira adequada?
Solução:
Forneça as informações usando cores adequadas nas fontes, nos fundos de tela e nas
páginas:
• Animações, imagens e arquivos longos devem ser fornecidas sob demanda.
• Tamanho de página, fontes e rolagem são importantes.
Contraexemplo:
Figura 27 Contraexemplo Size.
Nesse padrão, devemos pensar não somente no tamanho da página, como também no
tamanho da fonte a ser utilizada (SEARA, 2007). A Figura 28 ilustra alguns tipos de fontes mais
utilizados e seus respectivos tamanhos para possibilitar uma leitura rápida e eficaz.

Figura 28 Tipos de fontes que podem ser utilizadas em sites web.
Print
Contexto:
A leitura de textos em um web site é diferente da leitura em textos impressos. A maioria
das pessoas lê blocos de texto e não palavra por palavra.
Problema:
Como o usuário pode conseguir uma impressão adequada da informação?
Solução:
Forneça a informação de várias maneiras e formatos e dê a possibilidade de imprimir ou
salvar documentos grandes.
Veja o exemplo a seguir, representado pela Figura 29:
Figura 29 Exemplo Size.


Humano-Computador.
você encontrar dificuldades em responder a essas questões, procure revisar os conteúdos estu-
dados para sanar as suas dúvidas. Este é o momento ideal para que você faça uma revisão desta
unidade. Lembre-se de que, na Educação a Distância, a construção do conhecimento ocorre de
forma cooperativa e colaborativa; compartilhe, portanto, as suas descobertas com os seus co-
legas de curso.
unidade:
1) Imagine a seguinte situação: você é contratado por uma empresa para fazer parte de um grupo de desenvol-
vimento, no qual seria o responsável pela usabilidade do software. Ao ser contratado, a empresa informa-lhe
que, por enquanto, não há um público-alvo definido, e que, inicialmente, seria melhor atender a maioria dos
usuários. O que você faria a princípio, considerando os conceitos aprendidos nesta unidade?
a) Não se preocuparia com a interface a princípio; deixaria o software ser desenvolvido e depois aplicaria o
método Percurso Cognitivo para identificar os problemas de usabilidade.
b) Iria preocupar-se, apenas, com a interface, mas não interferiria no processo para não atrapalhar os desen-
volvedores; depois que tudo estivesse pronto, aplicaria a Avaliação Heurística.
c) Observaria o desenvolvimento da interface utilizando os checklists e, no final do desenvolvimento, apresen-
taria suas observações à empresa para que as devidas correções fossem realizadas.
d) Diria que não poderia trabalhar nesse projeto, uma vez que não faz parte do seu profissionalismo desenvol-
ver um sistema sem pensar no usuário.
e) Iria se preocupar com a utilização de padrões para a interface, por contar com a garantia de que estes aten-
dem a uma grande diversidade de usuários.
2) Considerando os padrões de Montero, que foram vistos nesta unidade, qual é o padrão que você considera
mais adequado para a preocupação com a linguagem e a forma como as informações são apresentadas em um
determinado site?
a) Polite.
b) Welcome.
c) Tagline.
d) Similarity.
e) Danger.
Gabarito
1) e.
2) a.
11. CONSIDERAÇÕES
Como você pode ter percebido, os padrões aqui apresentados têm algumas características
que qualquer sistema computacional pode utilizar (mesmo que não seja para web). É interes-
sante notar, também, que muitos desses padrões são aplicados de maneira intuitiva, por meio
do bom senso, mas, às vezes, essa maneira intuitiva pode não ser a melhor, afinal, são vários
fatores que devem ser considerados; há vários detalhes que podem fazer a diferença. Seguin-

do esses padrões, você tem a certeza de utilizar algo comprovadamente eficaz e que, por isso,
muitas pessoas utilizam, ou seja, já é conhecido e natural para elas navegarem na web, conside-
rando esses padrões.
Curiosidade ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Uma vez me questionaram se o uso de padrões ou checklists para desenvolver sistemas não limita a criatividade do
projetista e a minha reposta foi NÃO, pois a ideia dos padrões surgiu para mostrar aos desenvolvedores, projetistas
etc., alguns exemplos de sucesso. Sendo assim, se você segue um padrão no desenvolvimento, a possibilidade do
software ter qualidade é maior, uma vez que já se comprovou sua eficácia. Contudo, não há como impedir que cada
projetista dê o seu toque pessoal no desenvolvimento; na verdade, isso nem é necessário, pois a criatividade de cada
um é o que permitirá desenvolver um software único.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
De maneira bem simples, podemos comparar os padrões com as dicas. O projetista tem
algumas dicas de como desenvolver um software, em qual lugar ele pode colocar determinadas
opções e funcionalidades, o que uma tela deve ou não conter etc., mas cabe a ele pensar nessas
dicas e aplicá-las da melhor forma. Assim, os padrões são como um "bom senso", servem para
apoiar o desenvolvimento e não limitá-lo.
12. EͳREFERÊNCIAS
NETO, A. T.; SILVA, A. C.; SILVA, J. C. A.; PENTEADO, R. A. V. Desenvolvimento de Sistemas Interativos. Disponível em: <http://
www.dc.ufscar.br/~junia/padroes.zip>. Acesso em: 21 mar. 20
NOTÍCIAS RAcesso à internet no Brasil cresce 75,3% em três anos. Disponível em: <http://noticias.r7.com/tecnologia-e-ciencia/
noticias/acesso-a-internet-no-brasil-cresce-75-3-em-tres-anos-20091211.html>. Acesso em: 15 fev. 2010.
SEARA.COM. Usabilidade e comunicação na internet. Disponível em: < http://www.seara.com/> Acesso em: 18 mai. 2007.
Lista de figuras
Figura 2 – Exemplo Welcome: disponível em: <http://www.skol.com.br/prehome.aspx?gclid=CJeo1JD1haACFaAO5Qod7kTA
nA>. Acesso em: 12 mar. 20
Figura 3 – Exemplo Polyglot: disponível em: <http://www.bradesco.com.br/>. Acesso em: 12 mar. 20
Figura 4 – Exemplo Ready: disponível em: <http://www.dc.ufscar.br/~junia/padroes.zip>. Acesso em: 21 mar. 2010.
Figura 5 – Exemplos Indication: disponível em: <http://www.dc.ufscar.br/~junia/padroes.zip>. Acesso em: 21 mar. 2010.
Figura 6 – Exemplos Similarity: disponível em: <http://www.arquivonacional.gov.br/>. Acesso em: 12 mar. 2010.
Figura 7 – Exemplo Homepage: disponível em: <http://www.americanas.com/>. Acesso em: 12 mar. 2010.
Figura 8 – Exemplos Second Chance: disponível em: <http://www.dc.ufscar.br/~junia/padroes.zip >. Acesso em: 21 mar. 2010.
Figura 9 – Exemplo Form: disponível em: <http://www.mercadolivre.com/>. Acesso em: 12 mar. 2010.
Figura 10 – Exemplo Busy: disponível em: <http://www.baixaki.com.br/>. Acesso em: 12 mar. 20
Figura 11 – Exemplo Polite: Disponível em: <http://www.disney.com.br/>. Acesso em: 12 mar. 2010.
Figura 12 – Contra-Exemplo Tag Line: disponível em: <http://www.amorepaixaomensagens.com.br/>. Acesso em: 12 mar. 20
Figura 13 – Exemplo Tagline: disponível em: <http://www.com4.com.br/>. Acesso em: 12 mar. 2010.
Figura 14 – Exemplo About This: disponível em: <http://www.ufscar.br/>. Acesso em: 12 mar. 20
Figura 15 – Exemplos Search: disponível em: <http://www.dc.ufscar.br/~junia/padroes.zip>. Acesso em: 21 mar. 20
Figura 16 – Exemplo Novelty: disponível em: <http://submarino.com.br>. Acesso em: 12 mar. 2010.
Figura 17 – Exemplo Contact Us: disponível em: <http://www.intel.com.br/>. Acesso em: 12 mar. 2010.
Figura 18 – Exemplo Secret: disponível em: <http://www.bradesco.com.br/>. Acesso em: 12 mar. 2010.
Figura 19 – Exemplos Subscription: disponível em: <http://www.infoexame.com.br/>. Acesso em: 12 mar. 2010.
Figura 20 – Exemplo Recognize: disponível em: <http://www.google.com.br/>. Acesso em: 12 mar. 2010.
Figura 21 – Exemplo Location: disponível em: <http://www.infoexame.com.br/>. Acesso em: mar. 2010.
Figura 22 – Exemplo Colour: disponível em: <http://www.natura.com.br/>. Acesso em: 12 mar. 2010.
Figura 23 – Sequencia de Leitura em Web Sites: disponível em: <http://www.natura.
com.br/>. Acesso em: 12 mar. 2010.
Figura 27 – Contra-Exemplo Size: disponível em: <http://www.info.abril.com.br/>. Acesso em: 12 mar. 2010.

ALEXANDER, C. et. all. A Pattern language: towns, buildings, construction. New York: Oxford University Press, 1977.
BORCHERS, J. O. et. all. Usability pattern language: creating a community. AI & Society, v.15, n.4, p. 377-385, Londres:
Springer London, 20
GUIMARÃES, L. A cor como informação: a construção biofísica, linguística e cultural da simbologia das cores. ed. São Paulo:
Annablume, 20
MONTERO, F.; LOZANO, M.; GONZÁLEZ, P.; RAMOS, I. A First Approach to Design Web Sites By Using Patterns. In: First nordic
conference on pattern languages of programs: VikingPLoP. Hojstrupgard, Dinamarca. September 2002, p. 137-158
NETO, A. T.; SILVA, A. C.; SILVA, J. C. A.; PENTEADO, R. A. V. Workshop de padrões de interação. O Contexto Web. UfsCar – São
Carlos, Julho, 2004.
SILVEIRA, L. M.; BUCHDID, S. B.; SILVA, J. C. A. Metodologia de aplicação de cores no projeto WEB. Poços de Caldas: WebMedia, 2005.
14. CONSIDERAÇÕES FINAIS

Sabemos que estudar na modalidade a distância não é algo fácil, pois requer muita dedica-
ção e cabe a você decidir em qual momento irá ler o material, estudar para a prova, fazer as ativi-
dades. Isso, sem se esquecer de que são várias disciplinas ao mesmo tempo e que, muitas vezes,
você faz tudo isso depois de um dia cansativo de trabalho na empresa, na escola ou em casa.
Entendo que não é fácil chegar em casa com vontade de descansar e ter de estudar e que,
embora haja o cansaço mental, há, também, a necessidade de esforçar-se ao máximo para en-
tender tudo o que é essencial para a sua formação, afinal, toda essa dedicação, na maioria das
vezes, é para conseguir o tão sonhado diploma e, com ele, todas as possibilidades de melhorar
ou mudar de emprego, ter aumento no salário, mais prestígio, enfim, tudo o que é almejado
pelo ser humano.
É importante saber que, durante a sua caminhada, você amadureceu e tudo o que apren-
deu até aqui, de alguma forma, será importante para o seu futuro. Depois dessa longa jornada,
você vai para o mercado de trabalho não apenas com um diploma nas mãos, mas com toda a
experiência, conhecimento, entre tantas outras habilidades que adquiriu ou aperfeiçoou duran-
te o seu curso, e isso, será o seu diferencial diante de muitas outras pessoas que estarão concor-
rendo à mesma vaga de emprego.
Por isso leve esse desafio até o fim, persista, resista às dificuldades e supere os obstáculos, para
que, no fim, você possa dizer "eu consegui" e "valeu a pena". Espero que, em cada disciplina, você
tenha aprendido algo especial que fará a diferença no seu estudo e/ou trabalho e na sua vida.
Em especial, neste Caderno de Referência de Conteúdo, esperamos que tenha percebido
a importância do ser humano para desenvolver sistemas computacionais. Como dito anterior-
mente, algumas vezes, você vai construir algo para as pessoas utilizarem, então, nada mais justo
que se pense nelas e que esse sistema realmente lhes seja útil. Que não seja mais um sistema
desenvolvido e instalado, mas, sim, o sistema, útil, acessível e que, independentemente das
características físicas ou psicológicas das pessoas, elas consigam utilizá-lo.
Você se lembra da frase descrita no Caderno de Referência de Conteúdo, "algumas pessoas
compram celulares simples não pelo preço, mas porque cansaram de ter aparelhos que, pelo
difícil manuseio, se tornaram inúteis"? Essa frase é verdadeira, pois está cada vez mais comum
encontrarmos aparelhos com infinitas quantidades de funções, mas para que serve tudo isso?
Qual a finalidade de comprar um aparelho com infinitas funcionalidades se você só sabe utilizar
as básicas?

Culpa sua? Não, já aprendemos que a responsabilidade de fazer algo útil não é sua, você
apenas vai usar algo que já foi planejado e desenvolvido por alguém, que deveria ter se preo-
cupado com todas as características, para que o produto final ficasse bom. Essa frase é ótima
para isentar a sua culpa de não saber mexer em algo, porém aumenta a sua responsabilidade
de desenvolver algo bom, pois, uma vez que cabe a você fazer, terá de assumir todas as respon-
sabilidades.
Mesmo que a dedicação e o esforço resultem em um produto com custo maior, tenha a cer-
teza de que valerá a pena. Pode ser que você perceba uma resistência inicial por parte dos clientes
ou pelos seus colegas de trabalho, mas, assim como você fez até aqui, persista e resista.
Este Caderno de Referência de Conteúdo apresentou o caminho e permitiu a você dar
alguns passos, e, agora, você tem condições de investigar outras possibilidades e pensar em ou-
tras estratégias que também trarão resultados positivos. Portanto, utilize o que você aprendeu
aqui, pois, à medida que esses conceitos forem se consolidando, novos desafios aparecerão e,
com isso, a curiosidade de aprender cada vez mais.
Abraços!

IntHumCom-CRC-200x280.indd - TamiresBotta

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

IntHumCom-CRC-200x280.indd - TamiresBotta

Enviado por

Direitos autorais:

Formatos disponíveis

INTERFACE HUMANO-COMPUTADOR

CURSOS DE GRADUAÇÃO – EAD

Fazemos parte do Claretiano - Rede de Educação

Silva, Marcos Alexandre Rose

1. Breve histórico sobre Interface Humano-Computador (IHC). 2. Interfaces

Corpo Técnico Editorial do Material DidáƟco Mediacional

Centro Universitário Claretiano

Fazemos parte do Claretiano - Rede de Educação

CADERNO DE REFERÊNCIA DE CONTEÚDO

UNIDADE 1 INTERFACE HUMANO COMPUTADOR E FATORES HUMANOS

UNIDADE 2 BREVE HISTÓRICO SOBRE IHC E INTERFACES AVANÇADAS

UNIDADE 3 QUALIDADE NO DESENVOLVIMENTO DO SOFTWARE

UNIDADE 5 MÉTODOS PARA AVALIAÇÃO DA INTERFACE

UNIDADE 6 IHC NA WEB

2. ORIENTAÇÕES PARA ESTUDO

A usabilidade é a facilidade com que a interface pode garantir a sua utilização.

Claretiano - Centro Universitário

Claretiano - Centro Universitário

Esquema dos Conceitos-chave

Claretiano - Centro Universitário

Aplicado a diversas áreas do ensino e da aprendizagem escolar (tais como planejamentos de

Figura 1 Esquema dos Conceitos-chave do Caderno de Referência de Conteúdo de Interface Humano-Computador.

Figuras (ilustrações, quadros...)

Claretiano - Centro Universitário

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE

Figura 1 Foto meramente ilustrativa.

Claretiano - Centro Universitário

Claretiano - Centro Universitário

Fonte: SILVA, 2009, p.

Figura 3 Microsoft© Word 20

Figura 4 Ultra-Som 3D. Figura 5 Re-Mission.

Claretiano - Centro Universitário

Figura 6 The Sims.

Até este momento, discutimos sobre a Interface Humano-Computador e os avanços que

Figura 7(a) Máquina de lavar. Figura 7(b) Celular.

Bom modelo conceitual

Claretiano - Centro Universitário

Fonte: ROCHA ; BARANAUSKAS, 2003, p. 65.

Claretiano - Centro Universitário

Figura 10 (a) Vestido de noiva do ocidente. Figura 10 (b) Vestido de

Claretiano - Centro Universitário

Fonte: Adaptado de ROCHA; BARANAUSKAS, 2003, p. 20.

10. QUESTÕES AUTOAVALIATIVAS

Claretiano - Centro Universitário

13. REFERÊNCIAS BIBLIOGRÁFICAS

3. ORIENTAÇÕES PARA O ESTUDO DA UNIDADE

Os computadores dessa época eram usados, basicamente, para cálculos, e a interação

Claretiano - Centro Universitário

Figura 2 Cartão Perfurado.

Além da interação complexa, o tamanho do computador também não ajudava, o ENIAC

Figura 3 Monitor Monocromático.

Figura 4 Interface Gráfica.

Figura 5 Área de trabalho do computador Microsoft© Windows.

Figura 6 Funções Recortar, Copiar e

Claretiano - Centro Universitário

Fonte: CARDOSO; LAMOUNIER, 2008, p. 349.

Fonte: CARDOSO; LAMOUNIER, 2008, p. 348.

Claretiano - Centro Universitário

10. INTERFACES TANGÍVEIS

Figura 10 Imagens do filme Minority report.

11. WEARABEL COMPUTING

Figura 11 Controle usável da Apple.

12. INTERFACES ORGÂNICAS ͵ QUARTA FASE

Figura 12 Tela inicial do DisplayObjects.