ENGENHARIA

DE USABILIDADE

autor
FABIANO GONALVES DOS SANTOS

1 edio
SESES
rio de janeiro 2016
Conselho editorial regiane burger; roberto paes; gladis linhares; karen bortoloti;
helcimara affonso de souza

Autor do original fabiano gonalves

Projeto editorial roberto paes

Coordenao de produo gladis linhares

Coordenao de produo EaD karen fernanda bortoloti

Projeto grfico paulo vitor bastos

Diagramao bfs media

Reviso lingustica amanda carla duarte aguiar

Imagem de capa kran77 | dreamstime.com

todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrnico ou mecnico, incluindo fotocpia e gravao) ou arquivada em
qualquer sistema ou banco de dados sem permisso escrita da Editora. Copyright seses, 2016.

Dados Internacionais de Catalogao na Publicao (cip)

G635e Gonalves, Fabiano

Engenharia de usabilidade / Fabiano Gonalves
Rio de Janeiro : SESES, 2016.
136 p. : il.

isbn: 978-85-5548-234-2

1. Interface homem-mquina. 2. Interface humano-computador.

3. Usabilidade. I. SESES. II. Estcio.
cdd 004.6

Diretoria de Ensino Fbrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus Joo Ucha
Rio Comprido Rio de Janeiro rj cep 20261-063
Sumrio

Prefcio 7

1. Conceituao 9
1.1 Ergonomia 11
1.1.1 Ergonomia fsica e cognitiva 12
1.2 Usabilidade e Engenharia de Usabilidade 16
1.3 Interao Humano-Computador 21
1.3.1 A primeira gerao (ENIAC) 23
1.3.2 Segunda gerao (IBM 7030) 24
1.3.3 Terceira Gerao (IBM 360) 25
1.3.4 Quarta Gerao 26
1.4 Interfaces e o projeto de interao 28
1.4.1 Futuro da IHC 31

2. Conhecimento 35

2.1 Princpios Ergonmicos para IHC 37

2.2 Critrios Ergonmicos 37
2.2.1Conduo 38
2.2.2 A carga de trabalho 39
2.2.3 O controle explcito 40
2.2.4 Adaptabilidade 40
2.2.5 A gesto de erros 41
2.2.6 A homogeneidade/Consistncia (coerncia) 41
2.2.7 O significado dos cdigos e denominaes 42
2.2.8 A compatibilidade 42
2.3 Recomendaes Ergonmicas para IHC 43
2.3.1 Objetos de interao 44
2.3.1.1 Painis de controle 46
2.3.1.2 Controles complexos 49
2.3.2 Atributos de objetos de interao 52
3. Desenvolvimento 55

3.1 Introduo ao projeto de IHC 57

3.2 Um modelo de ciclo de vida simples para o projeto de IHC 60
3.3 Sobre os usurios 61
3.4 Tcnicas de concepo 63
3.4.1Brainstorming 63
3.4.2CardSorting 64
3.4.3 Diagrama de afinidade 66
3.4.4Storyboard 67
3.4.5 Maquetes prottipos em papel 68
3.4.6 Prototipagem rpida 69
3.4.7 Prototipagem de baixa e alta fidelidade 70
3.5 Tcnicas de modelagem de interface 71
3.5.1 The Bridge 72
3.5.2 Usercentered design 72
3.6 Consideraes finais 76

4. Avaliao 79

4.1Introduo 81
4.2 Por que avaliar? 81
4.3 O que avaliar? 82
4.4 Onde avaliar? 83
4.5 Quando avaliar? 84
4.6 Tcnicas de Avaliao de Usabilidade 85
4.6.1 Tcnicas prospectivas 85
4.6.2 Tcnicas preditivas 86
4.6.2.1 Avaliao Heurstica 86
4.6.2.2 Inspeo por meio de lista de verificao 91
4.6.3 Tcnicas objetivas 95
4.6.3.1 Ensaio de Interao 95
5. Acessibilidade Web 103

5.1 Introduo acessibilidade 105

5.2 Acessibilidade na web e sua importncia 108
5.3 A Web acessvel 110
5.4 Componentes essenciais para acessibilidade na Web 111
5.4.1 Interdependncia entre componentes 114
5.4.2 O ciclo de implementao 115
5.5 Projeto e desenvolvimento de um site acessvel 117
5.5.1 Recomendaes do W3C 118
5.5.1.1 Princpio 1 - Percepo 119
5.5.1.2 Princpio 2: Opervel 119
5.5.1.3 Princpio 3: Entendvel 120
5.5.1.4 Princpio 4: Robusto 120
5.5.2 Mtodos e validadores de acessibilidade na web 121
Prefcio
Prezados(as) alunos(as),

Desenvolver sistemas uma tarefa muito interessante e, se bem aproveita-

da, pode te dar um retorno financeiro bem interessante. Porm no basta con-
seguir analisar um problema e saber solucion-lo usando uma linguagem de
programao. Isto importante, porm o desenvolvimento envolve muito mais
detalhes do que se imagina.
muito comum ver programadores super experientes e conhecedores de
frameworks como o Bootstrap, por exemplo. Mas ser que, alm do framework
passa na cabea deles que existem detalhes importantes a respeito de algo alm
de um programa bonito?
Um dos detalhes a questo da usabilidade. importante que ao criar a
parte que interage com o usurio, alguns detalhes sejam observados, como a
questo da acessibilidade.
Esta disciplina tem como objetivo introduzir voc em um tpico no qual
muitos desenvolvedores no pensam ou ao qual no do importncia, que a
questo da usabilidade. Como foi citado, no basta saber um bom framework;
necessrio saber aplic-lo corretamente. Esta disciplina envolve conhecimen-
tos de diversas reas, como: psicologia, sociologia, antropologia, sistemas de
informao, cincia da computao, design grfico e ergonomia. Porm, no
vamos entrar a fundo em cada uma dessas reas. O que importante voc saber
que desenvolver interfaces no apenas uma questo de saber programao e
um determinado framework de apresentao. Vai um pouco mais alm.
Nosso objetivo despertar sua ateno para este conhecimento e coloc-lo
em contato com algumas questes bsicas destas reas mencionadas. inte-
ressante e, se voc se dedicar, saiba em que uma rea que h grande demanda
de bons profissionais.

Bons estudos!

7
 1
Conceituao
Neste captulo vamos tratar de um assunto que encontrado em vrias reas,
comArquitetura, Engenharia de Produo, Engenharia de Segurana e Tecno-
logia da Informao: a ergonomia.
A ergonomia trata basicamente da adequao das pessoas aos locais de tra-
balho e outros tipos de sistemas (no necessariamente computacionais).
Alm disso, vamos estudar uma introduo usabilidade e engenharia de
usabilidade. A usabilidade uma rea da computao relacionada com outra
grande rea chamada Interao (ou Interface) Homem-Mquina (IHM). A IHM
sempre foi um motivo de grande discusso, porque a tecnologia, evoluindo ao
longo dos anos, proporcionou uma grande evoluo nas interfaces que ligam
os humanos ao computador e s mquinas em geral. A IHM, por sua vez, uma
rea estudada pela Engenharia de Software, que uma disciplina que tambm
ser vista no curso.
A usabilidade tem ganhado muito destaque no desenvolvimento de siste-
mas, principalmente no desenvolvimento web. Atualmente, vrios frameworks
tm aparecido e ajudado os desenvolvedores a criarem sites mais interativos e
intuitivos, e isso tem um grande relacionamento com usabilidade.

OBJETIVOS
Ao final deste captulo, voc estar apto a:
Entender e reconhecer questes relacionadas ergonomia em geral;
Saber os conceitos bsicos de usabilidade e engenharia de usabilidade;
Conhecer os principais conceitos da rea de interface homem-mquina.

10 captulo 1
 1.1 Ergonomia
A ergonomia pode ser definida como adaptao ou melhoria na adequao
dos produtos aos indivduos. Ela existe desde a Pr-Histria quando o homem
primitivo sentiu a necessidade de criar objetos e utenslios que o ajudassem
a realizar as mais diversas tarefas, como armazenar gua, cozinhar alimentos,
fazer roupas para se proteger do frio e caar (figura 1.1).
HBCS0084 | DREAMSTIME.COM

Figura 1.1 Primrdios da Ergonomia.

Com a evoluo do homem tambm veio a evoluo da ergonomia, que se

preocupava com a necessidade de melhorar equipamentos de forma a tornar
o uso mais simples e intuitivo. A ergonomia tomou uma conotao realmente
relevante na Segunda Guerra Mundial, quando avies, tanques de guerra e ar-
mas precisavam ser produzidos rapidamente. Entretanto, esses equipamentos
foram produzidos sem a preocupao de adequao s caractersticas percepti-
vas e fsicas dos usurios, o que levou a diversas mortes de soldados.
evidente que a perda de vidas implica em srios problemas; dessa forma,
houve um esforo conjunto de especialistas de diversas reas para adaptar os
equipamentos, a fim de desenvolver projetos que adaptassem sua interface
de uso (alavanca, botes, pedais e painis) e campo de viso a soldados que

captulo 1 11
deveriam utiliz-los em situaes extremas, quando sua maior preocupao
deveria ser o combate, e no a forma de uso das armas e equipamentos.
Aps a Segunda Guerra Mundial a ergonomia ganhou grande avano por
meio da NASA e seu impressionante avano tecnolgico, atingindo os mais di-
versos setores das indstrias pela Amrica do Norte e Europa.
Atualmente, a ergonomia uma rea extremamente multidisciplinar que
envolve desde engenheiros e fsicos at mdicos, fisioterapeutas e psiclogos
na tentativa de solucionar a necessidade do ser humano em aplicar menos es-
foro mental e fsico em suas tarefas cotidianas. Assim, algumas premissas de-
vem ser pretendidas" na criao de um sistema ergonmico:
O usurio deve desempenhar somente as funes absolutamente essen-
ciais, e que no possam ser desempenhadas pelo sistema, transferindo para
o sistema uma funo mesmo que ela possa ser desempenhada pelo usurio.
O usurio deve ter de memorizar o mnimo possvel.
O usurio s deve ter de aprender o essencial para sua tarefa.
O usurio no deve ter de aprender a terminologia, passos no relaciona-
dos sua tarefa instrues ou comunicaes do sistema devem ser feitas ao
longo da tarefa.
Os comandos do usurio devem ter execuo natural e simples, no de-
vem ser complexos e compostos.
O usurio deve ter frustrao mnima.

1.1.1 Ergonomia fsica e cognitiva

Imagine que voc est em uma sala de cinema e, aps 10 minutos de o filme
ter comeado, ocorre um problema, as luzes no se acendem e comea a soar
o alarme de incndio. As pessoas ao seu redor se desesperam e voc comea a
sentir o cheiro de fumaa. Voc se mantm calmo e v que ao lado esquerdo
da tela, um pequeno painel com uma luz vermelha acesa, e logo abaixo v uma
porta e a associa sada de emergncia. Voc sai em direo porta e, em um
nico movimento empurra uma longa barra horizontal pouco acima da altura
da sua cintura, saindo da sala que j est bastante esfumaada, sentindo um
grande alvio ao respirar ar fresco.

12 captulo 1
 EDITOR77 | DREAMSTIME.COM O ponto-chave para que voc pudes-
se se livrar desta situao foi a facilida-
de de achar e abrir a porta da sada de
emergncia. Essas sadas foram proje-
tadas para que, em uma situao de pe-
rigo iminente, as pessoas possam ser
encaminhadas para a sada sem pen-
sar, de forma simples e instintiva, sim-
plesmente ao ver um painel com uma
luz vermelha. Da mesma forma, em
relao ao sistema de abertura da por-
ta, em uma situao de risco, a pessoa
no ter tempo ou estar to apavora-
da que no conseguir encontrar uma
maaneta ou identificar uma forma de
abrir a porta. Sendo assim, a porta se
abre quando a pessoa empurra a barra,
Figura 1.2 Sada de emergncia com a
o que uma ao intuitiva, uma vez que
barra horizontal.
sua principal preocupao fugir.
Aqui podemos notar elementos claros de ergonomia fsica e cognitiva: o fato
de a sada de emergncia estar posicionada imediatamente ao lado da tela, faz
com que voc no precise procurar muito por ela, uma vez que, durante a seo,
a sua ateno estar voltada para a tela; alm disso, o fato de a barra horizontal
estar posicionada um pouco acima de sua cintura faz com que voc no preci-
se fazer movimentos antinaturais, portanto abrir a portaser o menor dos seus
problemas.
Temos ento dois exemplos de ergonomia fsica que est relacionada a
adaptao de um sistema a anatomia humana, antropometria, fisiologia e bio-
mecnica. Ou seja, as aes a serem realizadas se aproximam ao mximo de
movimentos naturais aos seres humanos. Podemos notar tambm elementos
de ergonomia cognitiva, uma vez que a sada de emergncia indicada por uma
luz vermelha, enquanto todas as luzes esto apagadas, sendo assim bastante
visvel, e tambm outro elemento o fato de a porta se abrir quando a barra
empurrada, o que um movimento bastante natural, que no requer grande
carga de raciocnio. Nesse tipo de ergonomia, levada em considerao a carga

captulo 1 13
 mental de uma determinada ao, na tentativa de diminuir raciocnio, estresse
e tomada de deciso.
Este um exemplo no qual possvel mostrar que a ergonomia no est
relacionada apenas a equipamentos ou mquinas, uma vez que entendemos a
sala de cinema como um sistema, e as pessoas como usurios.
Existem outros exemplos mais diretos tambm , em que podemos notar ele-
mentos claros de ergonomia fsica e cognitiva. Por exemplo, a comparao entre
dois controles remotos: um tem um formato quadrado (com uma pegada ruim),
os botes so pequenos, seguindo o mesmo padro, e os botes mais usados
esto longe um do outro, exigindo que voc olhe para o controle para executar
qualquer ao; o outro anatmico (seu formato encaixa na sua mo) os botes
so grandes e em formatos diferentes de forma que voc no precise se preocu-
par em olhar para o controle para executar qualquer ao, voc identifica qual
boto apertar apenas com o tato, so poucos botes, e o que diferencia a uma
ao realizada da outra, a forma como esses botes so manipulados, apertan-
do, deslizando o dedo sobre o boto para um lado ou para o outro.
FRANCESCO ALESSI | DREAMSTIME.COM

Figura 1.3 Controle remoto "ruim".

14 captulo 1
 PANYA CHITMEDHA | DREAMSTIME.COM

Figura 1.4 Controle remoto "bom".

Podemos identificar tambm esses elementos na evoluo do interior dos

carros. Antigamente os botes e as alavancas eram espalhados pelo painel do
carro e, muitas vezes, para executar uma ao, voc precisava desviar a ateno
do trnsito para olhar para o painel e identificar o boto ou alavanca desejado.
Hoje em dia, nos carros mais modernos, grande parte dos controles do carro es-
to no prprio volante, inclusive controle multimdia, ar-condicionado e trocas
de marchas, fazendo com que o condutor foque sua ateno no trnsito, no
precisando retirar as mos do volante para quase nada.
E, finalmente, no mundo da informtica, podemos comparar os touchpads
de diversos laptops com o touchpad desenvolvido pela Apple, que torna a expe-
rincia de uso do computador muito mais simples e intuitiva, uma vez que so
adicionados elementos de percepo naturais multitouch como: para dar zoom
em uma imagem, basta abrir dois dedos; para movimentar a barra de rolagem
basta deslizar dois dedos para cima ou para baixo...
Sendo assim, vistos esses exemplos, o desafio a ser vencido criar softwares
ergonmicos, ou seja, que exijam o menor esforo fsico e cognitivo do usurio,
evitando, frustraes, grande uso de raciocnio e memria do usurio.

captulo 1 15
1.2 Usabilidade e Engenharia de Usabilidade
Vamos supor outra situao: voc est no escritrio postergando o que precisa
fazer: o manual formatado do software recm-produzido que havia prometido
ao seu chefe h tempos, mas est tranquilo, pois o texto j est todo escrito e as
figuras j esto todas prontas, a nica coisa que falta a formatao do arquivo.
J so duas horas da tarde, e, quando abre a caixa de e-mails, surpresa: uma
cobrana do chefe dizendo que precisa desse manual pronto at o fim do dia.
Voc percebe que, se abrir mo do cafezinho das quatro horas, consegue
terminar a formatao do arquivo. Porm, quando abre o editor de texto, nota
que ele foi atualizado para a verso mais recente, com novas funcionalidades
e um layout completamente diferente, as ferramentas que voc estava acostu-
mado a usar no esto mais onde sempre estiveram. Voc procura, passa por
todos os menus, mas a interface est muito diferente, as horas vo passando e
aps buscar por informaes na internet, consegue encontrar algumas ferra-
mentas e avanar um pouco na formatao, mas j so 16:30 e pensa: Como
uma empresa to grande, no faz um interface mais fcil, mais intuitiva? Ser
que ningum pensou na usabilidade deste software?
evidente que, se os construtores do editor de texto realmente tivessem
se preocupado com a usabilidade do software sua tarde teria sido muito mais
tranquila, e voc teria a certeza de que conseguiria entregar o manual pronto ao
seu chefe, mas infelizmente o software, no era nem um pouco usual.
Mas, ento, o que seria a usabilidade?
O termo usabilidade surgiu como uma parte, um ramo da ergonomia volta-
da para s interfaces computacionais, mas acabou se difundindo para outras
reas. Hoje o termo tambm utilizado em contexto de produtos, como apa-
relhos eletrnicos, em reas da comunicao e produtos de transferncia de
conhecimento, como manuais, documentos e ajudas online.
Podemos definir usabilidade como a facilidade com que as pessoas tm ao
manusear algum determinado objeto, de modo eficiente, intuitivo, sem provo-
car erros operacionais e oferecendo ainda satisfao aos usurios. Ou seja, po-
demos associar usabilidade facilidade de uso. Se um produto fcil de usar,
o usurio tem maior produtividade: aprende mais rpido, memoriza o passo a
passo das operaes e erra menos.
Veja a figura 1.5: Preciso ir para o primeiro andar. Como fao? Que boto
eu aperto, o 0 ou o 2? Preciso ir por tentativa e erro? E o que seria o andar -1?

16 captulo 1
Pode ser o subsolo? Mas e se houvesse mais andares abaixo do solo? Seria -2,
-3, etc? Isto no um pouco estranho?

TATABRADA | DREAMSTIME.COM

Figura 1.5

Uma boa usabilidade costuma andar de mos dadas com um bom design!
Smartphones em geral tentam fazer com que a experincia de uso seja sim-
ples e fcil, uma vez que necessria apenas a realizao de movimentos na-
turais e intuitivos para a troca de pginas e seleo de operaes e aplicativos.
DK88888 | DREAMSTIME.COM

Figura 1.6 O Iphone da Apple.

captulo 1 17
 Outro exemplo de usabilidade em produtos so controles remotos. O
Weemote um controle remoto focado em atender s necessidades de crianas
e idosos com botes grandes e coloridos s com funes bsicas. Nesse ponto
podemos fazer uma associao entre usabilidade e interao. Assim, fica claro
que a usabilidade no depende s das caractersticas do produto, mas tambm
das caractersticas do usurio, da tarefa e do ambiente ao qual todos esses fa-
tores esto includos, ou seja, a interface deve ser desenvolvida levando-se em
considerao a causa e a forma de contato entre usurio e produto.
Segundo (JORDAN, 1998), a usabilidade pode ser avaliada de acordo com
alguns princpios:
Evidncia: Devem ser evidentes o modo de operao e a funo do produ-
to, como, por exemplo, maanetas de portas de carros (figura 1.7):
MAKSYM GORPENYUK | DREAMSTIME.COM

Figura 1.7 Maaneta de carro.

Consistncia: Operaes semelhantes devem ser resolvidas de formas

semelhantes. Um exemplo a atualizao do editor de texto que mantm as
ferramentas mais utilizadas em seus lugares, sem maiores alteraes que con-
fundam o usurio.
Capacidade: As capacidades do usurio para cada funo no devem ser
ultrapassadas. Por exemplo, colocar os principais controles do carro no volan-
te, faz com que ele seja capaz de fazer mais operaes sem desviar sua ateno
do trnsito.
Compatibilidade: A experincia de uso deve ser compatvel com as expe-
rincias socioculturais dos usurios. Para desenroscar uma tampa, preciso
gir-la no sentido anti-horrio.

18 captulo 1
 Preveno de erros: Os produtos devem evitar ao mximo procedimen-
tos errados.
Realimentao: O sistema deve dar um retorno ao usurio sobre o suces-
so de sua tarefa, para que aes repetitivas sejam evitadas.

Figura 1.8 Retorno de uma ao do programa. Fonte: autor.

Mas, ento, qual a diferena entre usabilidade e ergonomia, j que, em am-

bos os casos, vrios dos mesmos exemplos podem ser utilizados?
Atualmente, a palavra ergonomia se refere caracterstica de um sistema ou
tarefa que se adapte ao usurio, e no o contrrio. uma rea multidisciplinar
que compreende diversos ramos da cincia, como: anatomia, antropometria,
biomecnica fisiologia, psicologia etc. Baseia-se em conhecimentos adquiri-
dos, nas habilidades e capacidades humanas para adaptar as mais diversas,
atividades, ferramentas, mquinas e produtos, com o objetivo a torn-los mais
seguros, eficientes e confortveis para uso humano.
J a usabilidade, como mencionado anteriormente, uma ramificao da
ergonomia, preocupa-se em produzir uma interface que deve ser usada para
se executar uma dada tarefa da forma mais simples possvel, de modo a per-
mitir que os usurios foquem apenas no trabalho que eles desejam executar

captulo 1 19
(NORMAN, 1986). Segundo (ISO/IEC 9126), usabilidade a capacidade de
uma aplicao ser compreendida, aprendida e utilizada, sendo atraente para
o usurio, em condies especficas de utilizao. Isso significa que aquele
editor de textos do incio deste tpico deveria, entre outras coisas, ter as seguin-
tes caractersticas:

Quo fcil e quanto de treinamento os usurios precisam

APRENDIZAGEM para realizarem tarefas bsicas no primeiro contato que
tm com a interface do sistema?

Os usurios conseguem realizar as tarefas exigidas pelo sis-

EFICINCIA tema, de forma eficiente, depois de quanto tempo de uso?

O usurio deve lembrar-se de como usar o sistema depois

MEMORIZAO de um longo perodo sem utiliz-lo?

Caso erros aconteam, a interface deve avisar o usurio e

ROBUSTEZ permitir a correo de modo fcil, sem gerar frustraes.

Quo agradvel, confivel e satisfatria a utilizao do

SATISFAO sistema?

importante salientar que, nas reas de Interao Humano-computador e

na Cincia da Computao, muitas empresas tm conscincia da importncia
da usabilidade. Porm, muitas delas ainda veem a usabilidade como um fator
que consome tempo e recurso, como se ela representasse um custo adicional,
fora do que essencia,l que s encareceria seu produto. Entretanto, as empre-
sas tm muito mais a perder ao minimizar a usabilidade dessa forma. De acor-
do com CYBYS, BETIOL e FAUST (2007):

Dependendo da frequncia com que o software empregado, os prejuzos para as

empresas podem tambm ser expressivos, no s em decorrncia do absentesmo e

20 captulo 1
 da rotatividade do pessoal, mas tambm pela baixa produtividade, competitivi-
dade e menor retorno de investimento. Sistemas difceis de usar implicam em
erros e perda de tempo, fatores que se multiplicam com a frequncia das tare-
fas e o nmero de usurios. A perda de dados e informaes pode implicar na
perda de clientes e de oportunidades. Acontecimentos deste tipo causam des-
de uma resistncia ao uso do sistema at a sua subutilizao e abandono com-
pleto, com o devido consentimento da empresa. O barato ter custado caro.

1.3 Interao Humano-Computador

Vamos usar outra situao cotidiana para exemplificar: imagine um senhor
que vai ao banco sacar o dinheiro de sua aposentadoria e sempre faz o mesmo
ritual todo ms, indo at o caixa. Mas desta vez h uma diferena: ao chegar
ao banco, v uma fila enorme de pessoas espera de as portas se abrirem, mas
ainda faltavam 15 minutos para as 10 horas. Em vez de enfrentar a fila, o senhor
pensou na possiblidade de mudar e tentar se atualizar e provar a si mesmo que
conseguiria fazer o saque de sua aposentadoria no caixa eletrnico, afinal, no
poderia ser to complicado assim. Ele via pessoas tocando a tela e recolhendo
seu dinheiro a todo momento. Ele ia tentar.
Assim que a porta se abriu, o senhor correu para o caixa eletrnico, olhou
para o lado e viu uma moa a toda pressa tocando no visor. Ele ento toca no
visor tambm, quando uma mensagem aparece: Insira seu carto. Ele pro-
cura e v um lugar onde colocar o carto, quando outra mensagem aparece:
falha na identificao do carto. Ele imagina que colocou o carto na posi-
o errada, reposiciona e coloca novamente o carto no local indicado, quando
outra mensagem aparece: digite sua senha. Ele digita e, quando pensa estar
dominado o assunto vem, a mensagem: posicione seu dedo no leitor biomtri-
co. Ele o faz prontamente, mas uma mensagem aparece: leitura no efetuada.
Repita a operao, ele olha para trs e a fila est aumentando, quando ele come-
a a ficar preocupado, repete a operao e uma srie de quadrados aparecem na
tela, com vrias possibilidades, dentre elas o saque. Ele escolhe um quadrado
e vrios outros quadrados aparecem: conta corrente, poupana, conta salrio,
etc. Creio que voc consegue imaginar o resto desta situao.

captulo 1 21
 Situaes como essas ocorrem o tempo todo. Muitas pessoas no sabem
como agir quando se deparam com uma mquina ou um sistema computacio-
nal. Por que essa interao to difcil?
Existe uma rea na Computao que estuda a interao de forma a dei-
x-la mas simples, objetiva e satisfatria, chamada de Interao Homem
Computador (IHC).
Essa necessidade surge no cotidiano com as mais diversas tarefas que en-
volvem mquinas que se utilizam de algum tipo de sistema computacional.
Esses sistemas na maioria das vezes so criados e desenvolvidos para facilitar
nossas vidas, mas em vrios casos acabam atrapalhando, por no serem bem
planejados, projetados e pensados, da a necessidade de toda uma cincia mul-
tidisciplinar, envolvendo cincia da computao, psicologia cognitiva, psicolo-
gia organizacional e social, ergonomia e fatores humanos, engenharia, design,
antropologia, sociologia, filosofia, lingustica e inteligncia artificial, por trs
desse assunto, que estuda como interagimos com os computadores nas mais
diversas situaes, para tornar cada vez mais simples e natural a interao ho-
mem computador. Ento uma definio para IHC seria: a interao Humano-
Computador (IHC) e uma disciplina que diz respeito ao design, avaliao e
implementao de sistemas de computao interativos para uso humano em
um contexto social e com os estudos dos principais fenmenos que os cercam
(Curricula for Human-Computer Interaction, 2009).
Porm, a interao entre humanos e computadores necessita de um meio de
comunicao que chamado de interface, por meio da qual o usurio entra em
contato com a mquina de forma fsica, perceptiva e cognitiva (NORMAN, 1986)
A interface o lugar onde ocorre contato entre duas partes. Toda forma de
interao onde uma ao do usurio (entrada) leva a uma resposta do sistema
(sada) intermediada por uma interface. Podemos ter como exemplos, com-
putadores, maaneta, televises, rdios, micro-ondas, aparelhos de telefone
e etc.
A interface permite que um agente (humano) faa uma ao por meio de
uma interface (maaneta) e tenha uma resposta do paciente (porta).
A interface do computador provoca estmulos ao usurio de forma que ele
manipule a interface por meio de dispositivos e tenha as respostas relaciona-
das sua atividade de interesse. Para cada ao, uma nova resposta esperada
por ambos os lados: sistema e usurio.

22 captulo 1
 Mas ser que desde o surgimento dos computadores a interao homem
computador a mesma?
evidente que no. Desde seu surgimento computadores e interfaces evo-
luram juntos at chegar ao que conhecemos e convivemos hoje, de uma inter-
face simples e rudimentar passando por apenas linhas de cdigo, at chegar-
mos nas interfaces grficas e intuitivas de hoje em dia.
Todos sabem que os computadores atuais so fruto de uma intensa evoluo
tanto em termos de hardware quanto de software, mas o que poucos sabem
que, na dcada de 1950 j existiam computadores. certo que eles no se pare-
ciam nem um pouco com os computadores que conhecemos hoje, mas j eram
capazes de fazer alguns clculos de forma bem rpida para determinadas tarefas.

1.3.1 A primeira gerao (ENIAC)

WIKIPEDIA

Figura 1.9 O ENIAC (https://en..org/wiki/ENIAC).

A interao com os primeiros computadores, os chamados ENIAC e UNIVAC, era

muito complexa, j que naquela poca no existia linguagem de programao,

captulo 1 23
os computadores eram programados para resolver um problema em especfi-
co, se quisesse resolver outro problema todo computador deveria ser reprogra-
mado. Eles eram enormes e tinham literalmente o tamanho de salas inteiras,
pesando aproximadamente 30 toneladas, alm de sofrerem com superaqueci-
mento pois, em vez de utilizarem microprocessadores, eles utilizavam vlvulas.
Elas funcionavam de maneira parecida com uma placa de circuitos, sendo que
cada vlvula acesa ou apagada representava uma instruo mquina. Cada
um deles necessitava de cerca de 19 mil vlvulas por ano, porque as vlvulas
queimavam com poucas horas de uso e precisavam ser substitudas.

1.3.2 Segunda gerao (IBM 7030)

WIKIPEDIA

Figura 1.10 O IBM7030.

A segunda gerao de computadores apresentou uma srie de novidades e

avanos em relao primeira gerao. O IBM 7030 foi o modelo de maior su-
cesso dessa gerao, sua programao foi bastante simplificada, uma vez que
utilizava a linguagens como Fortran e Cobol em vez de linguagens de mquina
como era usado no ENIAC.
Outros fatores tambm foram importantes para o sucesso do IBM 7030, ele
era muito menor que o ENIAC, pesava apenas 890 kg o que realmente pouco

24 captulo 1
diante das 30 toneladas do ENIAC. Essa considervel diminuio no tamanho
s foi possvel porque o IBM 7030 utilizava transistores em vez de vlvulas, os
transistores eram bem menores em relao s vlvulas e os computadores fica-
ram mais econmicos com relao ao gasto de energia e tambm em relao ao
custo das peas.

WIKIPEDIA

Figura 1.11 Rplica do primeiro resistor.

1.3.3 Terceira Gerao (IBM 360)

WIKIPEDIA

Figura 1.12 O IBM 360.

No final da dcada de 1970, o emprego dos semicondutores fez com que os com-
putadores da terceira gerao tivessem um aumento significativo na velocidade

captulo 1 25
e na eficincia. Nessa gerao foram introduzidos teclados para digitao de
comandos e monitores para visualizao de sistemas operacionais primitivos e
a possibilidade de fazer upgrades. Entretanto, os computadores dessa gerao
ficaram maiores do que os da gerao anterior. O IBM 360 (modelo de maior
expresso dessa gerao), claramente pesava mais do que seus antecessores.
Nessa poca, os computadores j comearam a ficar mais acessveis.

1.3.4 Quarta Gerao

Na dcada de 1970 foram lanados os primeiros computadores da forma como

conhecemos hoje, os microcomputadores. Esses computadores ficaram bem
menores (pesando cerca de 20 kg), e a reduo foi possvel graas ao uso de
componentes chamados microprocessadores. Com isso, os computadores fi-
caram muito mais acessveis, tanto que era possvel adquirir um computador
como o Altair 8800 com um kit de montar vendidos por revistas especializadas
nos Estados Unidos.
WIKIPEDIA

Figura 1.13 O Altair 8800.

26 captulo 1
 Nessa mesma poca, Steve Jobs e Steve Wozniak criaram o Apple I, que ti-
nha como objetivo ser um computador de fcil acesso para leigos e logo foi
substitudo pelo Apple II. O grande diferencial introduzido nesses computa-
dores que Jobs e Wozniak se basearam no BASIC para criar um sistema com
interface grfica, incluindo editores de texto, planilhas eletrnicas e bancos de
dados. Isto contribuiu com a popularizao dos computadores, saindo do meio
cientfico e atingindo a populao em geral. Posteriormente, a Apple tambm
foi responsvel pela adoo dos mouses, que tornou a experincia de interao
humano computador mais amigvel ainda. Pouco tempo depois, a Microsoft
tambm lanou o seu sistema operacional grfico, o Windows.

CONEXO
BASIC Beginners All-purpose Instruction Code, ou cdigo de instrues de uso geral para
iniciantes, uma linguagem de programao criada por John George Kemeny e Thomas
Eugene em 1964 para aprendizado dos sistemas computacionais. Veja mais em
http://www.vintage-basic.net/.
WIKIPEDIA

Figura 1.14 O Apple IIe.

captulo 1 27
 WIKIPEDIA

Figura 1.15 A primeira verso do MacOS.

Com isso ns temos um breve histrico da evoluo dos computadores e da

forma de interao homem computador at chegarmos aos tempos de hoje.
possvel perceber que sempre hove preocupao para tornar a expereiencia de
interao mais agradvel, principalmente quando hove a evoluo da criao
de sistemas operacionais com interface grfica.

1.4 Interfaces e o projeto de interao

A comunicao entre usurio e computador deve permitir o dilogo e ela
pode ocorrer de duas formas distintas: interface fsica ou interface virtual.

feita por meio de hardware e por meio fsico,

empregando materiais como cabos, fios, placas,
INTERFACE FSICA ou dispositivos como mouses, teclado joystic,
scanners, caixas de som etc.

28 captulo 1
 feita por softwares meio cognitivo que faz uso
de aspectos lxicos (funcionais), sintticos (es-
truturais) e semnticos (contedo). Um aspecto
importante das interfaces virtuais ou lgicas o
uso de metforas e modelos mentais, que podem
ser vistas nos principais sistemas operacionais uti-
lizados atualmente. Elas so analogias a elemen-
tos naturais de forma a representar as abstraes
contidas nos sistemas computacionais. A partir do
INTERFACE VIRTUAL OU momento em que comearam a ser utilizados sis-
LGICA temas operacionais com interfaces grficas, foram
feitos usos de metforas, por um exemplo o desk-
top ou rea de trabalho uma analogia a uma
mesa onde so organizadas todas as tarefas, outra
analogia so as pastas, que representam onde so
guardados os documentos, tambm podemos no-
tar a lixeira, onde so descartados os documentos
e arquivos que no sero mais utilizados. Todos
esses so esforos para deixar a experincia de
uso o mais natural possvel ao usurio.

Figura 1.16 Exemplo de uma rea de trabalho, bem lotada e no organizada.

captulo 1 29
 A combinao de interfaces fsica e grfica ou lgica em celulares exige um
projeto de interao que leve em conta uma relao compreensvel entre o apli-
cativo do aparelho e seus botes e teclado. Em avaliaes feitas por alunos da dis-
ciplina de TASI utilizando princpios de projeto, metas de usabilidade, heursti-
cas, entre outros conceitos, foi possvel verificar que o parelho Nokia um dos
mais simples de operar, enquanto o Motorola est entre os mais complicados.
Mas, na verdade, quando falamos de interao de humanos e computado-
res, falamos de congruncia de interfaces, que nada mais do que a combina-
o de interfaces fsicas e interfaces virtuais. Nesse sentido, preciso entender
que a combinao entre ambos os elementos precisa ser efetiva, clara e consis-
tente, para que, por meio de dispositivos fsicos, a interface grfica reaja apre-
sentando repostas aos estmulos de acordo com as expectativas dos usurios.
Agora me diga, quem no fica louco de raiva quando o mouse para de funcio-
nar? Entretanto, alguns novos dispositivos j vm eliminando alguns elemen-
tos de interao fsica, como o caso de dispositivos touchscreen.

ATENO
Tanto interfaces fsicas como virtuais devem levar em considerao as capacidades fsicas
e culturais dos seres humanos, e aqui um ponto de extrema importncia e a acessibilidade
desses sistemas, aos mais diferentes tipos de usurios que iro utilizar o sistema.

Sendo assim, independentemente de qualquer tipo de sistema que seja pro-

jetado, preciso considerar os seguintes aspectos:
Atender o tipo de atividade esperada pelo usurio;
Estudar a interface mais apropriada para entrada e sada de dados, que
seja apropriada s caractersticas do usurio.
Oferecer funcionalidades complementares como forma de flexibilizar o
processo de interao.

Para o desenvolvimento de uma boa interface o que costuma ser chamado

de uma interface amigvel, deve-se levar em considerao:
Perfil do usurio (Para quem?)
Dispositivos de interao (Como?)
Tarefas (O que?/Quando?)

30 captulo 1
 Mas o que seria uma interface ideal? Amigvel?
o conceito de que a interface de um sistema deve produzir uma experin-
cia prazerosa, de fcil manuseio e aprendizado. Deve-se tentar agregar ao m-
ximo caractersticas com as quais o usurio j esteja acostumado.
Outro ponto a ser evitado so interfaces carregadas com muita informao.
Ao contrrio do que se possa imaginar, ao disponibilizar muita informao, a
interface pode ficar to confusa que o usurio no consiga encontrar o que ele
est procurando.
O sistema deve ter componentes que incentivem o aprendizado autno-
mo, ou seja, interfaces amigveis devem ser invisveis, de forma que o usu-
rio somente se preocupe com a tarefa a ser realizada Ela no pode tomar mais
ateno do usurio do que a prpria tarefa e deve ser fcil de usar, aprender
e memorizar.

1.4.1 Futuro da IHC

claro que ns ainda no alcanamos os nveis propostos pela fico cientfi-

ca, mas podemos dizer que estamos caminhando, mesmo que lentamente para
um novo paradigma na construo de softwares que trabalham segundo uma
nova e diferente perspectiva de interface, uma evoluo substancial j foi expe-
rimentada com a popularizao de dispositivos touchscreen, como celulares e
tablets, tecnologia que tambm j atingiu os computadores. Essa mudana de
paradigma mudou drasticamente os tipos de interao, alterando tambm os
nveis de abstrao e os tipos de metforas utilizadas nos softwares e aplicati-
vos desenvolvidos.
Os movimentos realizados em dispositivos touchscreen (movimentos de
pina) so mais naturais do que os realizados em desktops com o uso de mou-
ses. Tambm podemos citar o kinect desenvolvido pela Microsoft que, com cer-
teza, entrega uma experincia completamente nova, se levarmos em considera-
o o que foi produzido at hoje.
Uma tecnologia que no se popularizou ainda, e uma quebra de paradig-
ma, o recm-desenvolvido Google Glass, que permite uma experincia com-
pletamente diferente do que estamos acostumados.

captulo 1 31
 FALLOSTUPIDO | DREAMSTIME.COM

Figura 1.17 O Google Glass.

Ou seja, essa rea ou cincia de interao humano computador ou humano

mquina bastante dinmica e com certeza muitos paradigmas ainda sero
quebrados, mas os profissionais devem estar preparados para as novas tendn-
cias do mercado e, mais do que isso, devem estare preparados para inovar e
ditar as novas tendncias do mercado. uma rea que exige criatividade, e re-
compensa muito bem por essa criatividade. Voc pode conquistar o mundo,
s ter uma boa ideia. Algum se habilita?

ATIVIDADES
01. Faa uma pesquisa na internet e procure o termo tecnologia vestvel. O que isso?

02. O que engenharia de usabilidade?

03. O que fala a norma tcnica ISO/IEC 9126 a respeito de usabilidade?

04. Por que a rea de interface humano computador to importante?

32 captulo 1
05. Faa uma pesquisa e explique como o JQuery e outras bibliotecas colaboram para as
interfaces atualmente.

06. Faa outra pesquisa na internet e descreva resumidamente o que melhorou nas interfa-
ces do Microsoft Windows, desde sua primeira verso at a verso 10.

REFLEXO
A rea de interface e de usabilidade realmente precisa ser levada a srio, e que bom que as
empresas e a academia esto se preocupando com isso. Porm, uma rea multidisciplinar
o pessoal da rea de TI tem de entender que, sem profissionais com formao em design e
comunicao, um novo sistema operacional, um site, ou qualquer outra forma de interao
entre o computador e o homem, no sero adequadamente desenvolvidos. E vice-versa: o
pessoal de design precisa da turma da TI para poder colocar em prtica as ideias e conceitos
que eles esto desenvolvendo. Pensando assim, grandes sites e sistemas operacionais foram
desenvolvidos e fazem sucesso at hoje.

LEITURA
Sugerimos os seguintes sites como recomendao e forma de aprimorar o que foi visto
neste captulo:
O JQuery uma biblioteca que proporcionou grandes avanos na rea de interatividade
na internet. Acesse o site do JQuery para ver o que possvel ser feito: https://jquery.com/
Apesar de ser um pouco antigo, o artigo a seguir mostra um estudo de caso envol-
vendo usabilidade: http://www.scielo.br/scielo.php?pid=S1415-65552003000200007&s-
cript=sci_arttext
Ainda vamos falar muito do W3C, o World Wide Web Consortium. O W3C contm os
padres que so usados na web para o desenvolvimento de sites e aplicaes. Este site
deve ser visitado e estudado por todos aqueles que desenvolvem para a internet: http://
www.w3.org/standards/

captulo 1 33
 REFERNCIAS BIBLIOGRFICAS
ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBRISO/IEC9126-1 Engenharia de
software - Qualidade de produto - Parte 1: Modelo de qualidade. 2003.
CURRICULA for Human-Computer Interaction. ACM SIGCHI, 2009. Disponivel em: <http://old.
sigchi.org/cdg/index.html>. Acesso em: 1 jul. 2015.
CYBIS, W.; BETIOL, A. H.; FAUST, R. Ergonomia e usabilidade. So Paulo: Novatec, 2007.
JORDAN, P. W. An introduction to usability. Philadelphia: Taylor & Francis, 1998.
NORMAN, A. D. User centered systems design. New York: Lawrence Earlbaum Associates, 1986.

34 captulo 1
 2
Conhecimento
Toda vez que algum precisa usar um programa novo, aquela mesma histria:
Como fao isso? Como altero aquilo? Por que fazer um programa to difcil?
Ser que ningum pensa que o usurio no tem tempo para aprender a usar os
programas? Ele tem que simplesmente executar uma tarefa sem precisar per-
der horas lendo manual.
A maioria dos softwares especficos aqueles que no atingem o grande p-
blico e que no so fabricados pelas gigantes do mercado no construda
tendo uma grande preocupao com usabilidade. Para tal, demandada uma
intensa participao dos usurios, no processo de definio da interface, na
realizao de diversos testes e avaliaes. Estes passos, alm de aumentarem o
prazo de construo do software, aumentam tambm o seu custo. Mas ser que
no existe um conjunto de regras e critrios para a construo de um programa
ergonmico?

OBJETIVOS
Este captulo tratar dos princpios ergonmicos para IHC e far com que voc possa res-
ponder seguinte pergunta:
O que precisa ser feito para que um software seja minimamente agradvel e utilizvel?

36 captulo 2
2.1 Princpios Ergonmicos para IHC
Assim como o conceito de ergonomia visto na unidade 1, em que se mostrou
que os produtos so planejados para atender s necessidades fsicas, psicomo-
toras e cognitivas do ser humano, pode-se observar tambm a necessidade de
construo de softwares ergonmicos que facilitem a vida das pessoas.
A ergonomia em IHC tem como objetivo no s facilitar a vida do usurio, mas
tambm adaptar os softwares e a forma de interao s capacidades dos usurios,
dando conforto e satisfao. Hoje em dia quase impossvel uma empresa se es-
tabelecer no mercado sem se preocupar com esses temas. Assim, a importncia
dessas caractersticas sobre como as mais diversas ferramentas sero usadas
clara. Portanto, foram desenvolvidas diversas tcnicas utilizando-se as teorias
existentes para desenvolver parmetros para gerar softwares ergonmicos.

2.2 Critrios Ergonmicos

Os critrios ergonmicos so parmetros a serem seguidos que podem tornar
a experincia de uso mais agradvel e eficiente. Em 1993, Dominique Scapin e
Christian Bastien propuseram um conjunto de critrios que tem como objetivo
minimizar problemas na interao do usurios com o software baseados em
dados de aplicao musical.
Dois grupos de especialistas avaliaram a interface de uma base de dados
de aplicao musical. Aps a explorao da interface, as aes e os coment-
rios dos avaliadores foram registrados junto ao estado corrente da aplicao.
Posteriormente, uma segunda avaliao foi realizada. Em um grupo a avalia-
o foi realizada em uma interface utilizando critrios ergonmicos, e o outro
grupo fez a avaliao sem critrios ergonmicos. Os resultados preliminares
mostram que na primeira fase, ambos os grupos apresentaram problemas de
usabilidade realizando avaliaes semelhantes. J na segunda fase a utilizao
de critrios ergonmicos fez com que os avaliadores encontrassem um numero
maior de problemas do que o grupo que avaliou a interface sem levar os cri-
trios ergonmicos em considerao. Sendo assim, ficou clara a utilidade dos
critrios ergonmicos na identificao de falhas no projeto. A utilizao desses
critrios leva ao aumento da integridade do sistema e diminuio do nmero
de especialistas necessrios para identificar possveis falhas. So no total oito
critrios que sero descritos a seguir:

captulo 2 37
2.2.1 Conduo

A conduo tem como objetivo auxiliar usurios novatos a utilizar o sistema.

A interface deve conduzir o usurio na realizao das mais diversas tarefas, no
sentido de aconselhar e informar o usurio na interao com o sistema. Quan-
do o usurio bem conduzido, pode ser observada uma diminuio significati-
va no nmero de erros cometidos, uma vez que o aprendizado facilitado.
Presteza: Permite que o usurio identifique em qual estado de interao ele
se encontra, ferramentas de ajuda e o seu modo de acesso. Uma boa presteza
facilita a navegao no software, diminuindo o erro, como por exemplo:
Dirigir a entrada de dados indicando o formato adequado e os valo-
res aceitveis.
Exibir as unidades de medidas dos dados a digitar.
Indicar todas as informaes sobre estado.
Para cada campo de dados, fornecer um rtulo.
Indicar o tamanho do campo quando ele limitado.
Quando necessrio, fornecer no rtulo informaes suplementares.
Dar um ttulo a cada janela.
Fornecer ajuda on-line e orientao.

Agrupamentos e distino entre os itens:

Este item diz respeito distribuio espacial dos itens na tela. Com isso poss-
vel que o usurio faa uma rpida compreenso da tela, para identificar os itens
de seu interesse. O critrio de distribuio e distino dos itens se divide em dois:

Permite ao usurio identificar semelhanas ou di-

ferenas nos itens segundo o padro de organiza-
AGRUPAMENTO E o espacial deles na tela, por exemplo: itens com
DISTINO POR contedos parecidos esto mais prximos.
LOCALIZAO Organizar os itens em listas hierrquicas.
Organizar as opes de um dilogo por menus,
em funo dos objetos aos quais elas se aplicam.

38 captulo 2
 Permite ao usurio identificar semelhanas ou
diferenas entre diferentes classes de itens de
acordo com caractersticas grficas.
Clareza: Refere-se as caractersticas que podem
auxiliar ou atrapalhar na leitura das informaes
textuais. Recomenda-se levar em considera-
AGRUPAMENTO E o caractersticas cognitivas e perceptivas
DISTINO POR dos usurios.
FORMATO Feedback imediato: refere-se s respostas do
computador referentes s aes dos usurios. O
computador deve responder a todas as aes dos
usurios o mais rapidamente possvel. Para os
usurios, ausncia ou demora no feedback podem
ser consideradas como falhas no sistema.

2.2.2 A carga de trabalho

Este critrio se preocupa em fazer com que o usurio diminua a carga cognitiva
e perceptiva, sendo subdividido em brevidade e densidade informacional.

BREVIDADE CONCISO AES MNIMAS

Este critrio leva em Diminui a carga de traba- Tenta facilitar ao mximo

considerao o respeito lho, cognitiva e perceptiva a carga de trabalho do
que se deve ter com as com relao s entradas usurio, simplificando e
capacidades cognitivas, e sadas do software. minimizando as aes
perceptivas e motoras Apresenta ttulos, rtulos, necessrias para que
dos usurios. denominaes curtas. uma tarefa seja rea-
Fornece o preenchimen- lizada. Presena de
to automtico de vrgulas, atalhos, com imagens
pontos decimais e zeros representativas.
a direita da vrgula nos
campos de dados.

captulo 2 39
2.2.3 O controle explcito

Este critrio se refere tanto ao controle que o usurio tem sobre a interface do
sistema quanto ao processamento e respostas dados pelo sistema ao usurio.

Se refere ao processamento e resposta dados pelo siste-

AES ma a uma ao executada pelo usurio por intermdio da
EXPLCITAS interface. Deve ficar explicito que o sistema s ir executar
estritamente o que foi solicitado pelo usurio.

O usurio deve estar no controle, e o sistema deve

retornar estritamente o que lhe foi solicitado, entretanto
CONTROLE DO interessante que o sistema se antecipe e o oferea op-
USURIO es que lhe auxiliem a executar determinadas aes, mas
sempre deixando o usurio no controle da situao.

2.2.4 Adaptabilidade

No possvel uma interface atender s necessidades de todos os seus usurios.

Sendo assim, ela deve ser capaz de se adaptar segundo as preferncias dos usurios.

Permite que uma tarefa possa ser realizada de diversas

FLEXIBILIDADE formas, dando ao usurio a possibilidade de escolher a
estratgia com a qual mais se familiarize.

O sistema deve prever que existem usurios de diferentes

nveis (iniciantes e especialistas) e que esses usurios
EXPERINCIA DO tm necessidades diferentes. Muitos dilogos so ente-
USURIO diantes e maantes para usurios experientes, ao passo
que a falta deles torna a experincia de uso invivel para
usurios iniciantes.

40 captulo 2
2.2.5 A gesto de erros

Este critrio se refere a todos os mecanismos disponveis no sistema capa-

zes de reduzir a ocorrncia de erros, e, caso eles ocorram, que a sua correo
seja facilitada.

PROTEO Refere-se aos mecanismos disponveis para detectar e

CONTRA OS prevenir os erros de entrada de dados.
ERROS

Refere-se qualidade, clareza e legibilidade da mensagem

QUALIDADE DAS de erro apresentada ao usurio, qual foi o erro e o que
MENSAGENS deveria ter sido feito para que esse erro no ocorresse ou o
que deve ser feito para corrigir o erro?

CORREO DE Quais so os recursos disponveis para que o usurio possa

ERROS corrigir eventuais erros?

2.2.6 A homogeneidade/Consistncia (coerncia)

Neste critrio, o objeto das interfaces so idnticos para contextos idnticos, e

diferentes para contextos diferentes.
Localizao similar dos ttulos das janelas.
Formatos de telas semelhantes.
Procedimentos similares de acesso s opes dos menus.
Na conduo, sempre utilizar as mesmas pontuaes e as mesmas cons-
trues de frases.
Apresentar na mesma posio os convites (prompts) para as entradas de
dados ou de comandos.
Os formatos dos campos de entrada de dados devem ser sempre os mesmos.

captulo 2 41
2.2.7 O significado dos cdigos e denominaes

A significncia dos cdigos se refere a adequao expresso/objeto dos cdigos

empregados na interface com o usurio.
Adequar o vocabulrio de rtulos, ttulos, cabealhos, mensagens, opes
de menu, bem como, definir figuras significativas para os cones e abreviatu-
ras significativas.

2.2.8 A compatibilidade

A organizao das sadas e entradas de uma dada aplicaodeve estar de

acordo com as caractersticas dos usurios (memria, percepo, hbitos, com-
petncias, idade, expectativas, etc.) e da tarefa. Um mtodo de avaliao com
base em critrios constitui uma abordagem analtica. Como tal, os critrios so
no se destinam a substituir outros mtodos de avaliao (por exemplo, "basea-
da em modelo" mtodos, questionrio, entrevista, etc).

ATENO
A abordagem de utilizao de critrios um meio de garantir a conformidade com as diretri-
zes de design de software. Assim, pode ser usada antes do teste do usurio para descobrir
e corrigir eventuais falhas no projeto inicial. Entretanto, os critrios devem ser vistos como
um suplemento a outros mtodos de avaliao, e so usadas somente abordagens analticas
sem em nenhum momento contar com mtodos de avaliao baseados em questionrios,
entrevistas e etc.

PROJEES FUTURAS

Estender o contedo de cada critrio, aumentando os nveis de detalhamento,

incluindo um conjunto completo de "regras" especficas para cada um dos critrios.
Definir um conjunto de prioridades para a avaliao para cada critrio. Por exemplo:
Para usurios inexperientes, a orientao deve ser priorizada em relao flexibilida-
de ou ao desempenho. O foco no desempenho deve ser adicionado aos poucos, de
acordo com a experincia do usurio.

42 captulo 2
 PROJEES FUTURAS

Definir os pr-requisitos para a avaliao, ou seja, definir quais so todas as caracte-

rsticas necessrias aos usurios para aplicao de cada critrio.
Definir formas de avaliar sistematicamente os elementos e estados da interface
(telas, janelas, sequncias de tarefas, etc.).
Utilizao de ferramentas de apoio para um completo sistema de avaliao (help).

2.3 Recomendaes Ergonmicas para IHC

As recomendaes ergonmicas representam a fonte de conhecimentos mais
utilizada pelos ergonomistas em suas intervenes.
A maior parte dos padres para IHC tm orientaes e recomenda-
es ergonmicas que vm sendo desenvolvidas pelos rgos de norma-
lizao, International Organizao de Normalizao (ISO) e Internetional
Electrotechnical Comission (IEC), ao longo dos ltimos 20 anos.
Esses padres so desenvolvidos por grupos de peritos ao longo de vrios
anos. Nas fases iniciais, os documentos podem mudar significativamente de
uma verso para outra, at que um consenso seja atingido. A partir do momen-
to em que o padro se torna mais maduro, uma votao formal ocorre atravs
da participao de membros de rgos de normalizao.
Uma das funes das normas impor consistncia. Houve uma tentativa de
fazer isso por meio das normas ISO / IEC para componentes de interface, tais
como: cones, scripts, controle de cursor, etc. No entanto, para essas reas os
padres definidos pela indstria foram mais influente do que as normas ISO.
Sendo assim, elas no foram amplamente adotadas. As normas podem ser:
Oficiais, concebidas por organismos de padronizao.
Guias de estilo, concebidos por grandes companhias.

As normas tiveram maior impacto a partir da norma ISO 9241 e ficaram mais
centradas em atividades necessrias para produzir produtos utilizveis a partir
da norma ergonmica ISO 13407. Estes princpios foram refinados e ampliados
em um modelo de boas prticas de usabilidade que pode ser utilizados para

captulo 2 43
avaliar a capacidade de uma organizao em desenvolver um design centrado
no usurio com a norma ISO TR 18529. A norma ISO PAS 18152 estende esses
conceitos para a avaliao da maturidade de uma organizao na execuo dos
processos que fazem um sistema utilizvel, saudvel e seguro.
As normas relativas usabilidade abordam principalmente temas como:
1. Eficcia, eficincia e satisfao na utilizao do produto.
2. Interao do usurio com a interface.
3. O processo utilizado no desenvolvimento do produto.
4. Design centrado no usurio.

ATENO
Um ponto fraco da maioria dos padres estabelecidos para IHC que eles so discutidos
e desenvolvidos com base em teorias, e no em processos prticos, ou seja, as normas no
so desenvolvidas om base na resposta dos utilizadores ao interagirem com os sistemas
testando prottipos durante o desenvolvimento.
Outra limitao das normas internacionais que o processo de desenvolvimento lento,
e o contedo depende do esforo voluntrio de especialistas apropriados.

2.3.1 Objetos de interao

H algum tempo, na histria dos computadores, a interao com os usurios

era extremamente difcil. Somente especialistas eram capazes de interagir com
o computador, enviando-lhe comandos e recebendo respostas. No vamos aqui
traar uma nova linha do tempo descrevendo novamente a histria dos com-
putadores, mas acho que todos j tiveram a oportunidade de ver o que era a
famosa linha de comando.

44 captulo 2
Figura 2.1 O prompt do DOS no MS Windows.

Antigamente toda a interao era assim, escreviam-se comandos especfi-

cos, que por vezes mais pareciam cdigos, e esperavam-se as repostas na tela
em formato texto.
Contudo, desde o Apple 2, esse conceito foi modificado com o intermdio
da interface grfica, onde so geradas imagens para interagir com os usurios,
que podem ser manipulados (aumentados, diminudos, movimentadas), sen-
do organizados por uma estrutura de janelas, menus, barra de ferramentas
etc., utilizando metforas do mundo real e linguagem natural para tornar a in-
terao dos usurios com o computador mais fluida e intuitiva.

Figura 2.2 Pasta sendo usada como metfora do mundo real.

captulo 2 45
 Com a evoluo da informtica foram estabelecidos alguns elementos e ob-
jetos de interao entre usurio e computador que sero explorados a seguir.

2.3.1.1 Painis de controle

Janelas
As janelas devem ter um layout padronizado para toda aplicao, geralmen-
te tem um ttulo, em sua parte superior, centralizado ou esquerda, tendo os
principais comandos vista do usurio. Quando for possvel abrir vrias janelas
simultaneamente, a janela ativa dever estar destacada.

Figura 2.3 Figura 3: Uma janela simples.

Caixas de dilogo
As caixas de dilogo apoiam operaes especficas, no contendo menus ou
barras de tarefas. E, assim como nas janelas, os ttulos devem ser centralizados
ou deslocados para a esquerda, tendo botes que executem a ao referida ra-
pidamente, alm do fechamento rpido da caixa de dilogo.

46 captulo 2
 Caixas de dilogo modal: impedem o usurio de realizar qualquer
outro tipo de ao nos sistema, exigindo dele ateno exclusiva.

Figura 2.4 Figura 4: Caixa de dilogo.

Caixas de dilogo no modal: No exige ateno exclusiva do usu-

rio, permitindo que ele realize outras aes, enquanto a caixa de dilogo
fica em segundo plano.

Figura 2.5 Figura 5: Caixa de dilogo.

Formulrios:
Este tipo de caixa de dilogo est destinado especificamente entrada de
dados. O layout deve ser autoexplicativo, agrupando de forma lgica e intuitiva
os diferentes tipos de dados. As aes de entrada devem iniciar-se pelo preen-
chimento do primeiro campo, no alto, esquerda, que dever estar com o foco
das aes quando da apresentao dele.

captulo 2 47
 Campos de preenchimento obrigatrio devem ser diferenciados visual-
mente e, se possvel, os campos que contenham dados crticos para o sistema
devem ser identificados e protegidos contra acidentes de operao. Mensagem
que advirta sobre os efeitos da ao e solicite a confirmao do usurio, deve ser
apresentada sempre que o campo for modificado.

Figura 2.6 Um formulrio para ambiente desktop.

Figura 2.7 Um formulrio para web.

48 captulo 2
 Caixas de Mensagens:
So utilizadas para informar o usurio sobre:
O que fazer nas interaes;
Em que estado se encontra o sistema;
A resposta do sistema a uma ao sua;
Uma situao perigosa, de erro ou de anormalidade;
Como recuperar a normalidade de um sistema.

Normalmente, essas mensagens so do tipo modal, ou seja, o usurio preci-

sa tomar conhecimento clicando em algum boto (Ok, por exemplo), para con-
tinuar usando o sistema. Quando a mensagem se destina a solicitar a confirma-
o de uma ao destrutiva, a opo default deve recair sobre a anulao, e no
sobre a confirmao da ao. Caixas de mensagens envolvendo aes perigosas
(formatar disco rgido) devem ser destacadas pelo uso de cor vermelha, pelo
efeito de intermitncia (pisca) ou ainda por um som.

Figura 2.8 Caixa de mensagem.

2.3.1.2 Controles complexos

So objetos com estrutura complexa de navegao interna, que permitem a se-

leo de outros controles e comandos.

captulo 2 49
 Painel de menu
So menus dispostos verticalmente, uns abaixo dos outros.

Figura 2.9 Menu do Windows 10.

Barra de menu
Contm as opes do menu principal e leva s opes secundrias relacio-
nadas ao menu selecionado.

Figura 2.10 Barra de menu.

50 captulo 2
 Barra de ferramentas
Menu sem submenus, com opes em forma de cones associadas a coman-
dos ou ferramentas.

Figura 2.11 Barra de ferramentas.

Lista de seleo
uma lista de valores possveis predefinidos pelos desenvolvedores, deve
ter de 5 a 9 itens de visualizao imediata.

Figura 2.12 Lista de seleo.

captulo 2 51
 Caixa de combinao (ou Combo Box)
Deve ser ordenada seguindo ordem alfabtica numrica ou por ordem
de uso.

Figura 2.13 Uma caixa de combinao

2.3.2 Atributos de objetos de interao

Os atributos de interao representam smbolos e sinais arbitrrios com repre-

sentao concreta, ou seja, so os modificadores dos objetos de interao. Po-
demos exemplificar:
cones
Denominaes
Abreviaturas
Cores
Fontes
Textura
Vdeo Reverso
Intermitncia Visual (pisca-pisca)

52 captulo 2
 ATIVIDADES
01. Os critrios de software apresentados servem para qualquer tipo de plataforma digital?
Tablets, smartphones ...

02. Sobre o critrio de controle do usurio. D um exemplo de auxlio ao usurio sem tirar o
seu poder de deciso.

03. Qual a relao entre o critrio "Agrupamentos e distino entre os itens e o conceito
de ergonomia cognitiva?

04. Qual a importncia de construir um software seguindo as normas sobre IHC? Qual o
benefcio no resultado final?

05. Cite 3 exemplos de novas metforas com o mundo real que poderiam ser utilizadas
como objetos de interao com o usurio.

REFLEXO
Construir um programa voltado para usabilidade levando em considerao critrios ergo-
nmicos no uma tarefa fcil. Existe a necessidade de uma equipe multidisciplinar, alta-
mente treinada, e a pacincia necessria para a interao e participao dos usurios nos
processos de determinao das interfaces do sistema. Apesar de encarecer o produto, a
utilizao de elementos ergonmicos no software torna a experincia de uso mais agradvel,
colocando o software alguns pontos acima no mercado. Logo essa ser uma a exigncia
do mercado e softwares que no forem construdos segundo princpios ergonmicos cairo
naturalmente em desuso.
Em contrapartida, novas ferramentas e plataformas vm cada vez mais ganhando, com
novas propostas e novas formas de interao. Mas ser que os princpios ergonmicos para
esses dispositivos devem ser diferentes, uma vez que a forma de interao diferente? Essa
uma rea em grande ascenso, em que profissionais gabaritados esto em falta. A grande
pergunta que fica : os critrios ergonmicos mudam conforme a forma de interao com o
dispositivo?

captulo 2 53
 LEITURA
As normas podem ser adquiridas (compradas) diretamente da ISO ou por meio de outras or-
ganizaes. Para um maior e completo entendimento sobre toda a abrangncia das normas,
recomendada vista ao site www.iso.org/iso/en.
Leia mais sobre os tipos de objetos de interao. No tutorial da linguagem Java existem
vrios suportados pela linguagem:
https://docs.oracle.com/javase/tutorial/uiswing/components/index.html
Para a parte de web, veja os principais componentes que podem ser usados na srie de
tutoriais da W3Schools. Este link excelente:
http://www.w3schools.com/html/html_forms.asp

REFERNCIAS BIBLIOGRFICAS
BARBOSA, S.; SANTANA, B. Interao Humano-Computador. Rio de Janeiro: Campus-Elsevier,
2010.
BASTIEN, J. M. C. Ergonomic criteria for the evaluation of human computer interfaces. Research
Gate, Lorraine, maio 1993.
BEVAN, N. International Standards for HCI. International Journal of Human Computer Studies,
Londres, 4, 1 out. 2001. 533-552. Disponivel em: <http://dl.acm.org/citation.cfm?id=565970>.
Acesso em: 1 jul. 2015.
OREN, T.; YILMAZ, L. Quality Principles for the Ergonomics of Human-Computer Interfaces
of Modeling and Simulation Software. Publications - School of Electrical Engineering and
Computer Science, Ottawa, 01 maio 2005. ? Disponivel em: <http://citeseerx.ist.psu.edu/viewdoc/
summary?doi=10.1.1.506.4251>. Acesso em: 1 jul. 2015.
ROGERS, Y.; SHARP, H.; PREECE, J. Design de interao. Porto Alegre : Bookman, 2013.

54 captulo 2
 3
Desenvolvimento
Neste captulo, vamos estudar a parte de desenvolvimento de interfaces ho-
mem-computador, ou IHC, tambm conhecida por interface homem-mquina
ou IHM.
Esta rea muito abrangente e tem vrios desdobramentos, mas, neste ca-
ptulo vamos estudar alguns assuntos que compem, de maneira geral, a parte
de desenvolvimento de IHC e em especial as tcnicas de concepo e de mode-
lagem de interfaces.
A interface de um software algo bastante determinante para o seu sucesso.
muito difcil encontrar um software de sucesso cuja interface no esteja de
acordo com sua proposta ou agrade.
At mesmo em jogos eletrnicos: existem alguns sucessos recentes que,
mesmo no tendo grficos realsticos e sofisticados, tiveram uma grande acei-
tao pelo mercado, e a interface tem grande parcela de responsabilidade nis-
so. Como exemplo, veja o jogo FlappyBird, disponvel originalmente para o
iphone. Feito em 2013, ele se destacou principalmente pela sua jogabilidade e
dificuldade. Outros jogos mais pesados se destacam pelos efeitos realsticos
de ltima gerao, os quais so verdadeiras produes de Hollywood (literal-
mente, uma vez que alguns estdios de jogos so em Los Angeles). Enfim, a
interface um fator que determina o sucesso final de um software.

OBJETIVOS
Ao final deste captulo, voc estar apto a:
Entender o fluxo de desenvolvimento de interfaces grficas, passando pelas tcnicas de
concepo e de modelagem de interfaces.

56 captulo 3
3.1 Introduo ao projeto de IHC
Em primeiro lugar, precisamos definir o que projeto, ou design, de IHC. Se-
gundo BARBOSA e SANTANA (2010), podemos dividir o design de IHC em duas
partes; a primeira o Design:
O Design parte de uma concepo intelectual da experincia do usurio.
Cada usurio temsuas experincias e vises a respeito da forma como gostaria
que um determinado software fosse.
A partir da, o design passa a ser uma concretizao desta concepo em
uma representao que pode ser implementada.
A segunda a parte de IHC:
Neste caso, estamos falando da experincia do usurio, ou seja, como ele
vai interagir com o computador, e isto tem a ver com o projeto do software, po-
rm no sinnimo de projeto de software.

Experincia do usurio ou tambm chamada de UsereXperience (UX), compreen-

de vrios fatores sobre o que o usurio sente em relao ao uso de um determinado
produto, sistema ou servio. A ISO 9421-210 define que a experincia do usurio so
as percepes e reaes de uma pessoa que resulta do uso ou utilizao prevista de
um produto, sistema ou servio. Na prtica, a experincia envolve todo o acmulo de
preferncias, respostas, sensaes e comportamentos que o usurio possui e adquire
com o uso de um software.

De acordo com o trabalho de ROGERS, SHARP e PREECE (2013), o processo

de projeto de IHC possui quatro atividades bsicas como:
1. Identificao das necessidades e estabelecimento dos requisitos. Nesta
atividade, as necessidades dos usurios so levantadas e listadas a fim de serem
analisadas para poder ser contempladas futuramente na interface. Desta for-
ma, os requisitos so estabelecidos e documentados.
2. Desenvolver designs alternativos. Nesta atividade, a explorao de v-
rios aspectos com relao ao visual e usabilidade do software podem ser inves-
tigados. Novos cenrios de interao podem ser criados a fim de avali-los e
perceber o quanto contribuem com a experincia do usurio.
3. Construir verses interativas dos designs. Atualmente existem vrios
softwares que ajudam nesta tarefa. Ter uma representao usvel do software

captulo 3 57
 muito importante, porque tambm uma forma de esclarecer os requisitos
para a interface.
Entre os softwares mais usados para este tipo de verso esto os softwares
do tipo wireframe, entre eles:

Figura 3.1 BalsamiqMockup.

Figura 3.2 Axure.

58 captulo 3
Figura 3.3 Microsoft Visio.

Alguns destes softwares tm verses para estudante e, embora sejam pagos

quando usados em empresas, so gratuitos para estudantes.
4. Avaliar o design. Uma vez que designs alternativos foram testados e mo-
delados em uma ferramenta de simulao como as apresentadas, as alterna-
tivas de design so avaliadas e classificadas por meio de critrios incluindo o
nmero de erros que os usurios cometem ao usar a alternativa avaliada. Alm
disso, outros critrios como aparncia, quantidade de requisitos satisfeitos e
outros tambm so usados.
Mesmo com estas atividades mostradas, qualquer processo de design de
IHC tem algumas caractersticas essenciais que devem ser prezadas durante
todo o processo:
1. O foco deve ser mantido sempre no usurio;
2. A experincia que se deseja que o usurio tenha deve ser clara e com os
objetivos bem definidos;
3. Deixar o processo iterativo.

captulo 3 59
3.2 Um modelo de ciclo de vida simples para
o projeto de IHC

Para deixar o processo iterativo, como vimos no final da seo anterior, RO-
GERS, SHARP e PREECE (2013) elaboraram um modelo de ciclo de vida para
representar o modo como as atividades esto relacionadas.
O uso de ciclos de vida uma atividade bem caracterstica da engenharia de
software, como o modelo em cascata, o modelo espiral e as aplicaes de de-
senvolvimento rpido. A rea de IHC, tambm usa os modelos de ciclo de vida
para a rea de projeto de IHC como o modelo Estrela e o modelo da ISO 13407.

Estabelecer
os requisitos

Design de
Avaliar
alternativas

Prototipar
Produto nal

Figura 3.4 Modelo simples de ciclo de vida de design de interao. Fonte: ROGERS,
SHARP, PREECE, 2013.

A figura 3.4 mostra um modelo simples de ciclo de vida de projeto de IHC.

Existem vrios modelos, e cada um tem a sua complexidade. Podem ser usados
em projetos de diferentes. Em projetos nos quais a equipe pequena, mas ex-
periente, um modelo simples como o da figura pode ser usado. E claro que,
em projetos maiores, envolvendo vrios desenvolvedores e muitos usurios, o
ciclo de vida deve ser adequado (veja o box).

CONCEITO
De acordo com ROGERS, SHARP e PREECE (2013), existem 4 abordagens para o projeto
de IHC:
Design centrado no usurio: o usurio quem sabe o que melhor e o nico
guia do projetista. O projetista implementa aquilo que o usurio props.

60 captulo 3
 Design centrado na atividade: neste caso, as tarefas especficas que so o
foco do projeto. O usurio ainda importante, mas o seu comportamento que influi
neste caso.
Design de sistemas: uma abordagem estruturada e mais rigorosa. Portanto, ela
mais formal e mais adequada para projetos maiores, pois o sistema como um todo
que se torna o foco. O usurio define os objetivos do sistema.
Design genial (genius design): neste caso, mais informal e est baseado nas
experincias e preferncias de um designer. O usurio, neste caso, valida as ideias do
designer.

O modelo apresentado na Figura 4 apresenta as quatro atividades do proje-

to e os trs princpios de projeto centrado no usurio. Como j foi comentado,
dependendo do projeto, este modelo pode no ser usado em todos os aspectos
e podem ser adicionados novos detalhes para adequar o modelo a algum pro-
jeto real.
Para poder tratar o ciclo de vida de maneira mais adequada, precisamos res-
ponder a algumas perguntas:
Quem so os usurios?
Quais so as necessidades?
Como criar designs alternativos?
Como escolher uma alternativa entre as demais?
Como integrar as atividades de projeto com outros modelos de ciclo de vida?

3.3 Sobre os usurios

Voc deve ter percebido que tratamos vrias vezes, neste texto, do sobre o quan-
to o usurio importante em todo o processo da engenharia de usabilidade. E
no para menos, ele o principal elemento que vai absorver todos os concei-
tos que temos tratado aqui.
Mas, quem so os usurios? (Parece ser uma pergunta estranha, mas, antes
de continuar lendo, tente responder pergunta).
Existem duas principais categorias de usurios:
Os usurios so as pessoas que usam o sistema. Essa a resposta mais
natural para a pergunta que foi feita.

captulo 3 61
 Mas tambm podem ser qualquer pessoa que tem algum tipo de rela-
o com quem usa o sistema (superiores, subordinados, terceiros, etc). Esta
a outra parte da resposta pergunta. Nem sempre identificamos aqueles que
dependem dos usurios principais como sendo usurios tambm.

Existem tambm os usurios primrios, secundrios e tercirios, os quais

devem ser levados em considerao:

USURIOS So aqueles que usam o software com frequncia.

PRIMRIOS

USURIOS So aqueles que usam o software esporadicamente ou que

SECUNDRIOS tem intermedirios.

So aqueles afetados pela introduo do sistema ou os ge-

USURIOS rentes que determinam a sua introduo. Tambm chamados
TERCIRIOS de stakeholders.

De qualquer forma, todos os tipos de usurios tm necessidades que devem

ser contempladas pelo projeto da IHC. A principal pergunta que feita Do
que voc precisa? Esta pergunta respondida pelo prprio usurio e/ou por
pessoas envolvidas no atendimento destas necessidades.
Alan Curtis Klay, um dos fundadores da linguagem Smalltalk e um dos cria-
dores do conceito de orientao a objetos, disse uma vez que a interface o
programa. Klay tambm conhecido por conceber a arquitetura das atuais
GUI (GraphicsUser Interface Interface grfica de usurio).
O projeto de uma IHC no um trabalho de uma equipe formada de pes-
soas da rea de TI exclusivamente. uma atividade multidisciplinar, que en-
volve informtica, ergonomia, psicologia, lingustica, design visual, entre ou-
tras. E tradicionalmente no faz parte da formao de profissionais da rea
de informtica.

62 captulo 3
3.4 Tcnicas de concepo
Neste tpico vamos apresentar algumas tcnicas usadas para a implemen-
tao de especificaes para a interface e usabilidade. Concepo significa
gerao e este tpico vai tratar de algumas tcnicas apontadas na literatura a
respeito de como gerar um projeto de interface homem mquina que seja efi-
ciente e adequado.
Dentre as tcnicas que vamos apresentar esto:
Brainstorming
Cardsorting
Diagrama de afinidade
Storyboard
Maquetes
Prototipagem rpida
Prottipos de baixa fidelidade
Prottipos de alta fidelidade

3.4.1 Brainstorming

Esta tcnica tem um nome que deriva de duas palavras da lngua inglesa:
Brain, que significa crebro, e Storm que significa tempestade. Logo,
brainstorming uma palavra que pode ser traduzida como tempestade ce-
rebral, ou melhor, tempestade de ideias. Na lngua caipirs, brainstorming
pode ser traduzido como tor de parpites.
Ela foi concebida em 1938 por Alex Osborn, que era presidente de uma
agncia de propaganda. uma tcnica usada no apenas para a concepo
de interfaces, mas para qualquer rea que exige que uma equipe exponha as
suas ideias para que sejam discutidas em grupo, incentivando a criatividade e
a colaborao.
Brincadeiras parte, o brainstorming uma tcnica muito interessante. Ela
feita em grupo de no mnimo 2 (obviamente) pessoas e no mximo 12. O ob-
jetivo principal criar e discutir as ideias surgidas em grupo, de forma partici-
pativa e colaborativa.
Esta tcnica rene vrias pessoas para resolver um determinado problema e
tambm para criar produtos ou, no nosso caso, interfaces e sistemas.

captulo 3 63
 Em grupo mais fcil a compreenso do problema, sua anlise e resoluo.
As discusses so abertas e deixadas livres para o grupo, porm deve existir um
intermediador para poder comandar e anotar os resultados.
Normalmente tem duas etapas principais:
A gerao das ideias;
E a crtica das ideias.

Embora seja uma tcnica bastante interessante, ela tem algumas desvan-
tagens, entre elas: por ser uma discusso aberta, quando uma crtica ocorre e
no bem aceita elo grupo, outras pessoas podem ficar inibidas e deixar de dar
uma ideia que seja relevante; alm disso, as ideias podem surgir de uma manei-
ra confusa e impedir que exista um detalhamento em cada uma, dificultando
a avaliao.

3.4.2 CardSorting

O cardsorting ou classificao de cartas tem como objetivo descobrir o modelo

mental dos usurios em relao aos itens de informao para uma aplicao.
Ou seja, esta tcnica tenta descobrir como o usurio classifica uma determina-
da informao na sua mente.
Normalmente usada com usurios inexperientes em design os quais so
guiados a criar uma rvore de categorias, chamada taxonomia. Esta tcnica
muito til para a arquitetura de informao, fluxos de trabalho, estruturas de
menu ou caminhos de navegao em um site.
Basicamente uma tcnica que no depende de muita tecnologia. Consiste
em escrever as categorias em papel e espalh-las em uma rea para visualmente
fazer a classificao.

64 captulo 3
Figura 3.5 CardSorting.

Veja na figura 3.5 um exemplo dos cartes. Neste caso, so cartes autoade-
sivos, espalhados na rea de estudo. Normalmente um usurio escolhido para
fazer a classificao em grupos.
Resumindo, a tcnica funciona de acordo com o seguinte mtodo:
1. Um usurio recebe um grupo de cartes previamente nomeados por
um analista. Neles est escrita a funcionalidade que se deseja da interface;
2. Esta pessoa classifica os termos em grupos lgicos (o que foi chamado
de taxonomia) e acha uma categoria para cada grupo;
3. O processo repetido entre um conjunto de situaes ;
4. O resultado depois analisado para que os padres sejam identificados
e definidos.

Enquanto as sesses so realizadas, o analista pode conversar com o usu-

rio sobre a classificao que foi feita e registr-la. Aps as sesses, as escolhas
feitas pelos usurios que participaram das sesses so analisadas conjunta-
mente, e os termos comuns so numerados com uma porcentagem de concor-
dncia. Quanto maior o nmero, maior sua indicao para ser usado.

captulo 3 65
 No final do processo, o analista ter uma quantificao dos dados e tem
condies de criar um relatrio resumindo e cruzando o que foi anotado e tam-
bm ter a taxonomia sugerida pela mdia dos usurios.

3.4.3 Diagrama de afinidade

O diagrama de afinidade foi criado em 1960 por JiroKawakita com a finalida-

de de organizar um grande nmero de ideias de acordo com seus relaciona-
mentos naturais. Basicamente esta tcnica usada quando existe um grande
nmero de ideias, opinies ou preocupaes sobre um determinado assunto.
Normalmente usada na fase de planejamento e, assim como as outras tcni-
cas apresentadas at agora, so usadas para a criao e organizao das ideias
sobre IHC.
A tcnica possui o objetivo de estimular a criatividade e a participao to-
tal do grupo, que deve ser de um tamanho limitado a no mximo 8 pessoas
que trabalham juntas se possvel. Esta tcnica muito relacionada com o
Brainstorming, pois pode ajudar com a organizao das ideias.
Existe um pequeno roteiro de construo do diagrama:
1. Aps o brainstorm, gerar os dados para a construo do diagrama.
2. Espalhar os dados em uma rea que seja visvel a todos.
3. Agrupe os dados, contendo no mximo 5 com alguma caracterstica
em comum.
4. Nomeie o grupo de acordo com a caracterstica comum de agrupamen-
to e coloque como um carto ttulo, diferenciando-o dos demais.
5. Cada grupo preso ao seu carto ttulo correspondente. O carto ttulo
deve permanecer visvel dos demais.
6. Repetir os passos 3, 4 e 5 usando os cartes ttulo como cartes de dados
7. Repetir os passos 3, 4 e 5 para cada conjunto novo de cartes ttulo que
foram criados at que se tenha apenas um grupo com 5 cartes ttulo.
8. O diagrama ser construdo a partir dos pequenos grupos iniciais. Fazer
um retngulo envolvendo cada grupo.
9. No lado superior do retngulo, coloque o carto ttulo do grupo.
10. Faa outro retngulo sobre os retngulos cujo ttulo forma um grupo.

66 captulo 3
 Veja um exemplo de um diagrama de afinidades na figura 3.6.

Desenvolver estratgias para Tema

Informaes
aumentar o nvel de
qualidade dos produtos
oferecidos

Elevar o grau de Elevar o nvel de Aprimorar o

entusiasmo dos controle da Sistema de Garantia
funcionrios empresa da Qualidade
Perseguir uma Ttulo
Aprimorar o
Elevar a motivao do imagem de qualidade do
controle da
pessoal de vendas superior Grupo
lucratividade
dos concorrentes
Melhorar o nvel Alcanar nvel zero
Incentivar o esprito
dos prossionais de reclamaes
de busca por desaos
de controle dos clientes

Aprimorar as
Bordas habilidades tcnicas
da empresa
Certicar know-how Elevar o nmero de
Alcanar liderana em
tcnico de patentes obtidas
tecnologia na indstria
empresas aliadas anualmente

Figura 3.6 Diagrama de afinidades.

3.4.4 Storyboard

Esta uma tcnica mais relacionada com a concepo do que as anteriores. Se

voc percebeu com ateno, as tcnicas anteriores so teis para organizar e
criar novas ideias. A partir desta vamos ver tcnicas relacionadas com a concep-
o especificamente.
O storyboard uma forma de representar as interaes entre os usurios e o
sistema em seu ambiente de trabalho. O storyboard muito usado em outras si-
tuaes como por exemplo na pr-visualizao de um filme, de uma animao e
outras semelhantes. Na verdade o grande criador e difusor desta tcnica foi nin-
gum menos que Walt Disney! claro que para ele a finalidade outra, mas para
ns, o storyboard usado na melhoria da documentao dos requisitos de IHC.

CONEXO
Para quem gosta de msica dos anos 1980, o grupo musical A-Ha lanou um videoclipe que
baseado em um storyboard. Assista ao vdeo em https://www.youtube.com/watch?v=dj-
V11Xbc914 para relaxar um pouco dos estudos!

captulo 3 67
 O storyboard feito para detalhar um cenrio do sistema por meio de uma
sequncia de desenhos. Os softwares indicados anteriormente podem ajudar
nesta situao.
Os desenhos tambm podem ser feitos em papel e colocados em uma rea
visvel aos outros membros das sesses de discusso. Por meio desta exposio,
os desenhos podem ser avaliados e discutidos entre os usurios e designers e
devem estar baseados em princpios de usabilidade.

Figura 3.7 Exemplo de um storyboard para software.

3.4.5 Maquetes prottipos em papel

As maquetes tambm so usadas em vrias reas diferentes da rea de inform-

tica e IHC, entre elas a arquitetura e a engenharia. Voc j deve ter visto na tele-
viso que as maquetes so teis em filmes, como Star Wars, para a construo
de situaes de batalhas no espao.
As maquetes na IHC contribuem bastante para esclarecimento e desenvol-
vimento de requisitos especficos para a interface do programa e, da mesma
forma como ocorrem nos filmes, elas servem para simular e testar as interaes
com o usurio.
Por ela servir como uma forma de simulao, a tcnica permite a prvia
identificao de problemas com usabilidade.
A tcnica tambm tem um ciclo de atividades, definido como:
1. Conceito: nesta atividade so elaborados os aspectos conceituais e as
estruturas grficas das telas.
2. Iterao: nesta atividade as navegaes entre as telas so organizadas.

68 captulo 3
 3. Projeto das telas: a atividade em que os vrios tipos de componentes
so colocados nas telas.
4. Teste das telas: nesta etapa, com os componentes alocados aos seus
lugares, questes como combinao de cores e outros elementos grficos
so testados.

Figura 3.8 Exemplo de prottipo de uma tela em papel.

3.4.6 Prototipagem rpida

Observando novamente a figura 3.1, a figura 3.2 e a figura 3.3, percebemos que
existem softwares que auxiliam bastante o processo de prototipao das telas.
A prototipagem rpida utiliza estes softwares para simular o sistema final
com mais fidelidade do que as telas em papel. As telas em papel so timas,
mas no permitem ver como fica a navegao entre as telas realmente. O pro-
blema deste tipo de software que necessrio passar um tempo para criar
os prottipos e este tempo, se no estiver bem definido durante o planeja-
mento do projeto, pode significar em uma perda valiosa de tempo da parte de
desenvolvimento.
Usando os prottipos em software, possvel obter um feedback mais r-
pido e fiel sobre a interface e desta forma saber os problemas e vantagens da
interface em desenvolvimento.

captulo 3 69
 MULTIMDIA
Assista a alguns vdeos do Axure, um software bastante usado para prototipao:
http://www.axure.com/learn. Os vdeos vo ajuda-lo a entender como estes softwares
contribuem para o processo de prototipao.

3.4.7 Prototipagem de baixa e alta fidelidade

As tcnicas que foram apresentadas anteriormente so baseadas em prot-

tipos. Um prottipo uma manifestao de um projeto que permite aos sta-
keholders interagirem com ele e explorarem sua adequao. na verdade um
modelo, uma representao do que pode ser o produto final.
Um prottipo de baixa fidelidade aquele que no se parece muito com o
produto final. Por exemplo, podemos usar impresses 3D para representar um
novo modelo de um telefone celular. Os prottipos de baixa fidelidade so teis
porque so simples e de rpida produo. Mas no porque so simples sig-
nificam que so baratos e rpidos de serem modificados. O storyboard um
exemplo de prottipo de baixa fidelidade, assim como o cardsorting.
A prototipao de alta fidelidade, como se espera, utiliza materiais que esta-
ro no produto final. Voc j deve ter visto aqueles carros conceito que as mon-
tadoras produzem e expem nos sales automotivos, certo? um bom exemplo
de prottipo de alta fidelidade.
Na informtica possvel criar prottipos com linguagens rpidas de desen-
volvimento como o Visual Basic por exemplo, para que o usurio tenha noo
de como vai ficar o software final. O prottipo de alta fidelidade til para ven-
der ideias para as pessoas e para testar questes tcnicas.

TIPO VANTAGENS DESVANTAGENS

Prottipo de - custo mais baixo de desenvolvimento
baixa fidelidade - avalia mltiplos conceitos de design
- instrumento de comunicao til
- aborda questes de layout de tela
- til para identificao de requisitos
de mercado
- demonstrao de que o conceito funciona
- verificao limitada de erros
- especificao pobre em detalhe
do cdigo
- mais facilitado
- utilidade limitada aps estabele-
cimento dos requisitos
- utilidade para testes de usabili-
dade limitada
- limitaes de fluxo e navegao

70 captulo 3
 TIPO VANTAGENS
Prottipo de alta - funcionalidade completa
fidelidade - totalmente interativo
- dirigido aos usurios
- define claramente o esquema
de navegao
- uso para explorao e teste
- mesma aparncia do produto final
- serve como uma especificao viva
- ferramenta de venda e marketing
DESVANTAGENS
- desenvolvimento mais caro
- sua criao demanda tempo
- ineficiente para demonstraes
que o conceito funciona
- no serve para coleta
de requisitos

Tabela 3.1 Eficcia relativa dos prottipos de baixa vs alta fidelidade (ROGERS, SHARP
e PREECE, 2013).

Alguns autores concordam com o fato de que mais projetos deveriam usar
a prototipao de baixa fidelidade porque os problemas existentes na proto-
tipao de alta fidelidade, podem prejudicar o andamento do projeto. Alguns
problemas dos prottipos de alta fidelidade so:
Levam muito tempo para serem desenvolvidos;
A equipe de teste tem a tendncia de comentar mais sobre aspectos super-
ficiais do que o de contedo;
Como os desenvolvedores levam tempo para criar o prottipo, eles aca-
bam sendo relutantes de mudar alguma coisa depois;
Um prottipo em software pode criar expectativas muito altas;
Um bug em um prottipo de alta fidelidade j pode parar os testes.

Outras vantagens e desvantagens encontradas nos prottipos esto mostra-

das na tabela3.1.

3.5 Tcnicas de modelagem de interface

Uma vez que vimos as tcnicas para a concepo de interface, vamos agora
apresentar algumas tcnicas relacionadas com a modelagem de interface. Es-
tas tcnicas so um conjunto de etapas e atividades para a definio de elemen-
tos concretos partindo de elementos abstratos.
Vamos analisar duas tcnicas:
The bridge, criada por Tom Dayton em 1996
Design centrado no usurio, criada por LaryConstantinee Lucy Lockwood
em 1999

captulo 3 71
3.5.1 The Bridge

A metodologia The Bridge (A Ponte) , de acordo com seus autores, uma

metodologia abrangente e integrada para projetar rapidamente interfaces de
usurio grficas orientadas a objeto e multiplataforma. A metodologia lida em
grande parte com a questo da criao da tarefa de modelos de interao e os
processos que so necessrios para que isso acontea (WARREN, 1997).
Esta tcnica se baseia em uma sequncia de sesses de projeto envolvendo
vrias pessoas (usurios, programadores e analistas) que criam uma ponte
entre os requisitos dos usurios e da organizao e o projeto de uma interface
que apoie estes requisitos.
As atividades principais deste mtodo so:
Expressar os requisitos de usurios por meio de um fluxo de tarefas: nessa
etapa, os envolvidos definem um fluxograma de trabalho para o sistema a ser
executado pelo usurio.
Mapear os fluxos de tarefa em objetos da tarefa: uma vez que os fluxogra-
mas de tarefas esto definidos, eles so analisados e transformados em obje-
tos de tarefa. Estes objetos correspondem a janelas, caixas de dilogo e caixas
de mensagens.
Mapear objetos da tarefa em objetos de interface: os prottipos dos obje-
tos de interface definidos nesta etapa devem ter sua usabilidade testada pelos
usurios que participaram das sesses de projeto.
Incio
Atendente Atendente Atendente Rsultado
Hspede solicita
solicita nome do encontra a escolhe um Hspede oculpa
vericao de
hspede reserva quarto um quarto
reserva

Figura 3.9 Exemplo de fluxograma de trabalho.

3.5.2 Usercentered design

O usercentered design (UCD) ou design centrado no usurio tambm conhe-

cido por processo de design centrado no usurio e, devido a isto, utilizado em
vrias reas da manufatura, arquitetura e outras. Existem exemplos na internet
do uso desta tcnica no design de automveis (WORLD WIDE WEB CONSOR-
TIUM (W3C), 2004).

72 captulo 3
 A norma 9241-210:2010 tambm estabelece que o design centrado no usu-
rio uma abordagem para o desenvolvimento de sistemas interativos que focam
especificamente em fazer sistemas usveis. uma atividade multidisciplinar.
No design centrado no usurio, todos os processos de desenvolvimento
tm o usurio como foco. O design centrado no usurio, de acordo com Rubin
(1984), pode ser representado como dois crculos:
Os usurios esto no centro;
O crculo interno contm: Contexto, objetivos, ambiente e metas;
O crculo externo contm: Detalhe das tarefas, contedo das tarefas, or-
ganizao de tarefas e Fluxo de Tarefas.

Organizao de tarefas

Objetivos
Contedo das tarefas

Detalhes das tarefas

Contexto
Metas

Ambiente

Fluxo das tarefas

Figura 3.10 Design centrado no usurio (RUBIN, 1984).

O design centrado no usurio possui os seguintes princpios:

Foco inicial em usurios e tarefas
o Reunio sistemtica de informao estruturada: importante que
toda informao estruturada seja juntada e analisada pela equipe.
o Designers treinados por especialistas antes de conduzir as ses-
ses de coleta de dados: antes de os dados serem coletados pelos

captulo 3 73
 designers, importante que os especialistas passem sua experincia
para os designers.
Medidas empricas e teste de uso do produto
o Foco na facilidade de aprendizagem e facilidade de uso.
o Teste de prottipos com usurios atuais.
Design iterativo
o Produto projetado, modificado e testado repetidamente.
o Permite uma reviso completa e reviso do design por testes preli-
minares de modelos conceituais e ideias de design.

O objetivo do design centrado no usurio criar um processo de design que

aumenta a usabilidade do produto.

Iniciao Requisitos Especicao Projeto Implementao Testes

Design centrado no usurio: Modelo clcissico:

O usurio envolvido aqui O usurio envolvido aqui

Tabela 3.2 Diferena do estgio onde o usurio envolvido.

O design centrado no usurio uma forma de abordagem que pressupe

que os designers iro prever como os usurios usaro o produto e tambm vo
testar a validade do que foi levantado com os usurios reais.
Segundo Woodson (1981), o design centrado no usurio pode ser entendido
como uma prtica de criar produtos de forma que os usurios sejam capazes de
us-los com o mnimo de stresse e o mximo de eficincia.
A participao dos usurios, como estamos percebendo, fundamental
neste tipo de abordagem. Eles so importantes para que:
1. As ideias sejam validadas;
2. Novas ideias surjam a partir da equipe envolvida;
3. Diminuir custos e retrabalho;
4. Evitar o desenvolvimento de funcionalidades inteis e o excesso
de informao.

74 captulo 3
Existem algumas tcnicas que podem ajudar nesta abordagem:

J vimos que envolver quem vai usar o produto

ENTREVISTAS fundamental. Se eles so os maiores interessados no
COM USURIOS E resultado, envolv-los juntamente com quem patroci-
STAKEHOLDERS na o produto importante.

outra tcnica bastante interessante. Por meio da

OBSERVAO EM observao do comportamento no seu ambiente de
CAMPO trabalho, possvel perceber como ele poder usar o
produto.

O uso de questionrios muito incentivado. Se forem

annimos, pode ser ainda melhor, pois muitas vezes
os usurios podem se sentir acanhados ou incomo-
QUESTIONRIOS dados de alguma forma quando esto em sesses
diretas e pessoais. Um questionrio pode afastar a ini-
bio e recolher requisitos preciosos para o produto.

J vimos esta tcnica antes e estudamos que ela

CARDSORTING classifica os requisitos de maneira bastante eficiente.

Outra ideia interessante a incorporao de papis

pelos usurios, ou personificao. Por meio das
personas criadas, o usurio pode dar sinais do que
necessrio no produto final. O papel de usurio
PERSONAS definido como um tipo de usurio que apresenta
necessidades, interesses, expectativas, comportamen-
tos ou responsabilidades especficas em relao ao
produto ou sistema.

PROTOTIPAO Outra tcnica que j foi vista anteriormente.

captulo 3 75
 Os prottipos so muito usados e a utilizao de
TESTES COM testes certamente outra forma de colocar o usurio
USURIOS como validador do que foi prototipado.

So semelhantes aos casos de uso da UML. So

definidos como narrativas estruturadas e simplificadas
CASOS DE TAREFAS de interao realizada pelo usurio desempenhando
seu papel por meio do sistema.

3.6 Consideraes finais

Vimos vrias tcnicas para obter os requisitos dos usurios e stakeholders
para construir melhores produtos.
Quando tratamos dos projetos relacionados com IHC, podemos resumir as
vrias caractersticas favorveis das tcnicas para o bom projeto:
Envolver as solues relacionadas aos aspectos essenciais da interface
no incio;
Prever a descrio de solues em termos abstratos inicialmente, e deta-
lhar progressivamente conforme o projeto avana;
Prever transformaes, representando com mapeamento os aspectos de
uma representao e outra;
Prever diversas oportunidades para que tais definies sejam repartidas e
validadas pelos usurios.

Portanto, quando consideramos o usurio, a abordagem de projeto centra-

do ao usurio, leva em conta o ser humano em cada etapa do desenvolvimento
de um produto ou servio. E tudo que o usurio experimenta deve ser resultado
de uma deciso consciente da parte do projetista.

76 captulo 3
 ATIVIDADES
01. Quem voc acha que pode ser os stakeholders de um sistema para caixa de um gran-
de supermercado?

02. Quais so os principais tpicos do design centrado no usurio?

03. Faa um storyboard para a reserva de um quarto de hotel pela web.

04. Por que o uso de prottipo em algumas situaes pode no ser uma boa ideia como
forma de obter requisitos do usurio?

05. Falamos algumas vezes sobre Bootstrap. O que isso? Pesquise no site www.getboots-
trap.com e liste suas principais caractersticas.

REFLEXO
Criar interfaces grficas no uma tarefa to fcil quanto parece. Vemos em muitas empresas
uma certa despreocupao com esta parte to importante do software. Atualmente existem
vrias facilidades tcnicas para criao de interfaces como o Bootstrap, o AngularJS, o JQuery
e no basta ser um craque nestas tecnologias, o que vimos aqui neste captulo fundamental.
Tente aplicar estes ensinamentos nos projetos que voc participar. Certamente eles sero um
belo diferencial entre voc e outros que no se preocupam com isso e s com a parte tcnica.

LEITURA
Abaixo esto listados alguns links que podem ser teis no seu estudo sobre design de interfaces:
Informaes sobre IHC no Brasil: http://www.sbc.org.br/ihc
Este link legal porque contm vrias referncias sobre IHC. Vale a pena dar uma boa
olhada: http://www.usernomics.com/hci.html
A ACM (AssociationofComputingmachinery) uma entidade que dita vrios padres
para a computao em geral. Eles tm um grupo de estudos especficos na rea de IHC:
http://www.acm.org/sigchi/
Este um link de um livro online a respeito de IHC. Bastante interessante tambm:
http://brazil.joelonsoftware.com/uibook/chapters/1.html

captulo 3 77
 REFERNCIAS BIBLIOGRFICAS
BARBOSA, S.; SANTANA, B. Interao Humano-Computador. Rio de Janeiro: Campus-Elsevier, 2010.
DIX, A. et al. Human-Computer interaction. [S.l.]: Prentice-Hall International, 2004.
FERNANDES, J.; GODINHO, F. Publicaes. Unidade Acesso, 2013. Disponivel em: <http://www.
acessibilidade.gov.pt/publicacoes#manuais>. Acesso em: 1 jul. 2015.
POPLADE, T. Como tornar seu site acessvel. Tableless, 2010. Disponivel em: <http://tableless.
com.br/como-tornar-seu-website-acessivel/>. Acesso em: 01 jul. 2015.
QUEIROZ, M. A. D. Mtodos e Validadores de Acessibilidade Web. Acessibilidade Legal, 2008.
Disponivel em: <http://www.acessibilidadelegal.com/13-validacao.php>. Acesso em: 1 jul. 2015.
ROGERS, Y.; SHARP, H.; PREECE, J. Design de interao. Porto Alegre : Bookman, 2013.
RUBIN, J. Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests.
New York: John Wiley and Sons, 1984.
TIDWELL, J. Designing interfaces. [S.l.]: O'Reilly Media, 2010.
W3C. Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation, 2008. Disponivel em:
<http://www.w3.org/TR/WCAG20/>. Acesso em: 01 jul. 2015.
W3C. Acessibilidade na Web. W3C, 2011. Disponivel em: <http://www.w3c.br/pub/Materiais/
PublicacoesW3C/cartilha-w3cbr-acessibilidade-web-fasciculo-I.pdf>. Acesso em: 1 jul. 2015.
W3C-WAI. W3C Web Acessibility Iniciative. World Wide Web Consortium, 2013. Disponivel em:
<http://www.w3.org/WAI/intro/wcag.php>. Acesso em: 1 jul. 2015.
WARREN, P. Computer review categories. UML.org, 1997. Disponivel em: <http://www.uml.org.cn/
jiaohu/pdf/undertst.pdf>. Acesso em: 1 jul. 2015.
WOODSON, W. E. Human factors design handbook: information and guidelines for the design of
systems, facilities, equipment and products for human use. New York: Mc Graw Hill, 1981.
WORLD WIDE WEB CONSORTIUM (W3C). Web Acessibility Iniciative (WAI). WAI: Strategies,
guidelines, resources to make the Web accessible to people with disabilities, 2004. Disponivel em:
<http://www.w3.org/WAI/redesign/ucd>. Acesso em: 1 jul. 2015.
WORLD WIDE WEB CONSORTIUM. Acessibility. W3C, 2015. Disponivel em: <http://www.w3.org/
standards/webdesign/accessibility>. Acesso em: 01 jul. 2015.
INTERNATIONAL STANDARDS ORGANIZATION. Ergonomicsofhuman-system interaction: Part 210:
Human-centred design for interactive systems. Vernier, Geneva, 2010. 32 p. (9241-210:2010).

78 captulo 3
 4
Avaliao
Imagine uma situao na qual voc desenvolveu um site, aps ter passado pelas
etapas de desenvolvimento que estamos vendo ao longo deste livro, implantou
o site e ele est pronto para ser mostrado ao grupo de usurios-alvo: um grupo
de adolescentes (por exemplo, um site para vestibular). Como possvel saber
se eles se interessaro pelo site e vo de fato us-lo? necessria de uma avalia-
o. Mas como avaliar?
Assim como qualquer outra parte do design, a avaliao integrante do pro-
cesso de desenvolvimento. Quem vai fazer a avaliao precisa pegar as infor-
maes sobre a experincia do usurio ou possveis experincias quando esto
interagindo com um prottipo, um sistema de computador, um componente
de um sistema, etc.
Isto feito para melhorar o design, e a avaliao tem como foco melhorar a
usabilidade e a experincia do usurio ao interagir com o sistema.
Neste captulo vamos estudar alguns assuntos relacionados com a avaliao
e te dar elementos que podem ser expandidos em uma situao real por voc ou
pela sua equipe. Nunca se esquea de avaliar o produto que est sendo entregue
e nunca se esquea de que a avaliao deve fazer parte do projeto da interface.
Vamos l? Bons estudos e bom trabalho!

OBJETIVOS
Aps ler e estudar este captulo, voc estar apto a:
Entender os principais conceitos e termos na avaliao;
Conhecer alguns tipos de avaliao, entre elas:
o Avaliao analtica
o Avaliao heurstica
o As listas de verificao
o O percurso cognitivo
o A inspeo preventiva de erros

80 captulo 4
4.1 Introduo
Atualmente vemos o mercado receber vrios tipos de produtos diferentes em
relao aos dispositivos mveis, no ?
Principalmente os grandes players do mercado, como Apple, Samsung,
Motorola, Asus, Sony e outros a cada dia lanam produtos semelhantes, mas
com alguma caracterstica que os tornam diferentes. O iPod, iPad, os e-readers
(como o Kindle, o Lev, o Kobo, por exemplo) aumentaram muito a percepo dos
usurios quanto usabilidade, porm h um detalhe: ser que o que os desig-
ners acham que vai ser usado por todos, que to natural, realmente ser usado?
Para ilustrar isso, assista ao filme Jobs da Universal Pictures, produzido em
2015. Ele retrata resumidamente a vida de Steve Jobs, e em uma certa parte do
filme ele e sua equipe esto discutindo sobre o Lisa, um computador pessoal
que poderia revolucionar o mercado com sua interface grfica e uso do mouse,
porm, foi um fracasso comercial para a Apple.
Portanto, a avaliao importante. Temos certeza, que a Apple fez as de-
vidas avaliaes, afinal, estamos falando da Apple! Porm trabalhar com uma
hiptese de que os usurios aceitaro o produto baseado nas preferncias dos
designers um risco alto.
Existem vrios mtodos de avaliao diferentes. Decidir qual usar uma ta-
refa difcil e que de uma certa forma est relacionada com a cultura da equipe
de desenvolvimento. As avaliaes normalmente abrangem a observao do
usurio ao usar o produto e medir o seu desempenho por meio de testes de
usabilidade, experimentos ou estudos de campo. Existem outros mtodos que
no envolvem diretamente a participao do usurio, como a modelagem do
comportamento do usurio.
Estes ltimos aproximam-se de previses do que os usurios podem fazer
na interao com a interface.
Vamos estudar a importncia da avaliao e o que precisa ser avaliado para
podermos entender melhor este assunto.

4.2 Por que avaliar?

claro que importante que um produto, um sistema, no nosso caso, seja us-
vel e bonito. Porm, os usurios certamente esperam mais do que isso: esperam

captulo 4 81
tambm que ele tenha uma experincia agradvel no uso e que seja envolvente.
Portanto, a avaliao mais do que justificvel.
Se formos considerar a parte de negcios, um produto com bom design ven-
de. E isto torna mais um bom motivo para que a avaliao seja importante. A
avaliao uma atividade que permite corrigir erros no produto antes que este
seja colocado em produo e seja vendido.
Vamos pegar um exemplo para ilustrar:
Chame um jovem adolescente e um adulto para conversar a respeito do
Facebook e faa algumas perguntas como:
voc posta fotos frequentemente?
que tipos de fotos voc posta?
qual foto voc tem como imagem do seu perfil?
que aplicativos voc usa no Facebook?
j apagou algum da sua lista de amigos?

Estas perguntas feitas a dois tipos de usurios diferentes vo nos levar a

uma avaliao do produto (o Facebook). Um adolescente provavelmente usa o
Facebook para algumas finalidades do adulto, que na maioria das vezes me-
nos extrovertido os adolescentes. Sendo assim, o produto est preparado para
estes dois perfis? (No precisa responder, apenas pense que estamos avaliando
o produto). O produto contm recursos para estes dois tipos de perfis?
Resumidamente, o motivo de avaliar est relacionado com:
Determinar o valor de algo;
Apreciar;
Julgar;
Ponderar, examinar, considerar;
Calcular, estimar.

Ou seja, a avaliao de IHC tem a finalidade de julgar a qualidade de intera-

o de um sistema ou outro artefato computacional.

4.3 O que avaliar?

Basicamente, a avaliao vai depender do tamanho da encrenca, ou seja, pode
ser avaliar prottipos de baixa tecnologia a sistemas completos e mais complexos,
com apenas uma tela de interao ou que possui vrios mdulos interligados.

82 captulo 4
 Por exemplo, os desenvolvedores de um novo navegador para a web podem
querer saber se os itens que eles desenvolveram nas telas so encontrados mais
rapidamente na nova verso, enquanto tambm podem querer saber se as no-
vas telas alteram o comportamento do usurio. Uma empresa que desenvolve
media players (tipo o Winamp) pode querer saber se usurios diferentes, de
pases diferentes, gostam da mesma aparncia da tela, etc.
Ou seja, devemos avaliar os aspectos cognitivos e funcionais relacionados
realizao das tarefas apoiados pelo sistema, como:
rpido?
de fcil aprendizado?
confivel?
Permite reverter erros realizados com facilidade?
Permite ser lembrado depois de algum tempo sem usar?

Alm disso, aspectos socioculturais do uso da soluo e dos contextos pre-

vistos tambm devem ser avaliados.
E aspectos afetivos do sistema, como se as pessoas vo gostar, se bonito e
agradvel, etc.

4.4 Onde avaliar?

Novamente, a localizao da avaliao vai ocorrer dependendo do projeto e do
que est sendo avaliado. Quando vamos avaliar acessibilidade na web, melhor
avaliar dentro de um laboratrio, a fim de verificar e controlar se todos os requi-
sitos necessrios esto sendo cumpridos.
Isso ocorre tambm com as escolhas de design, como o layout e o tamanho
das teclas de um telefone celular. Outros aspectos como a experincia do usu-
rio, como crianas experimentando um novo brinquedo tambm podem ser
avaliadas. Neste caso, o tempo em que a criana brinca com o brinquedo,
medido at que ela se canse e afaste o brinquedo. Nestes exemplos, o melhor
lugar para avaliar seria em ambientes naturais do usurio, chamados tambm
de estudos na natureza (ROGERS, SHARP e PREECE, 2013).
Em outras situaes, como redes sociais, a avaliao pode ser feita nas pr-
prias casas dos usurios, podendo ser realizadas para avaliar as interaes na-
turais de um grande nmero de usurios.

captulo 4 83
4.5 Quando avaliar?
A fase de avaliao do produto ocorre em uma determinada parte do ciclo de
vida do seu desenvolvimento e tambm depende do tipo de produto. Como
exemplo, vamos supor que um produto totalmente novo est sendo desenvolvi-
do ou sendo atualizado para uma nova verso. Neste caso, quando o produto
novo, haver um tempo para a criao de prottipos, levantamento de requisi-
tos e pesquisa de mercado. Quando os requisitos forem obtidos, a criao dos
prottipos, esboos, storyboards levar um tempo para o desenvolvimento.
Logo, a avaliao neste caso feita durante o design.
Quando a avaliao feita durante o design, ela chamada de avaliao for-
mativa (RUBIN, 1984). As avaliaes deste tipo abrangem uma grande parte de
processos de design, desde o desenvolvimento de esboos iniciais e prottipos
at a fase final do design.
Existem tambm as chamadas avaliaes somativas. Estas so usadas para
medir o sucesso de um produto acabado. Se o produto est em atualizao, en-
to a avaliao vai se concentrar em adicionar (somar) novos requisitos ao pro-
duto, uma vez que os requisitos iniciais j foram obtidos anteriormente. Neste
caso, como novos requisitos podem ser adicionados, possvel que problemas
de usabilidade ocorram.
De qualquer maneira, algumas agncias reguladoras, como o National
Institute of Standards and Technology (NIST), nos EUA, e a International
Standards Organization (ISO), e a sociedade britnica, tm padres nos quais a
avaliao do produto determinada em uma parte do ciclo de vida do produto.

MULTIMDIA
Momento Vintage: Assista a estes vdeos a respeito do Apple Lisa e como era a ideia de
interface com o usurio nos anos 1980.
https://www.youtube.com/watch?v=OKrvMStjbIU
E veja o seu promocional, de 1983:
https://www.youtube.com/watch?v=-G9S-h2w2dU

84 captulo 4
4.6 Tcnicas de Avaliao de Usabilidade
Possveis problemas de usabilidade podem ocorrer durante o processo de cons-
truo de um software; isto natural e aceitvel. O objetivo do uso de tcnicas
de avaliao evitar que esses problemas passem desapercebidos e venham
causar algum tipo de desconforto ou descontentamento ao usurio. Sero
avaliadas as funcionalidades do sistema e a usabilidade da interface, levan-
do em considerao aspectos como: interatividade e comunicabilidade, bem
como desempenho, aprendizado, memorizao, planejamento e satisfao
dos usurios.
Basicamente existem trs tipos de tcnicas de avaliao que so geralmen-
te utilizadas:

neste tipo de tcnica, busca-se a opinio do usu-

TCNICAS rio sobre a experincia de uso e interao com o
PROSPECTIVAS sistema.

Neste tipo, a busca de preveno de erros na

TCNICAS interface feita sem a participao direta de
PREDITIVAS/ANALTICAS usurios.

As informaes sobre problemas na interface so

TCNICAS obtidas enquanto o usurio observado interagin-
OBJETIVAS/EMPRICAS do com o sistema.

4.6.1 Tcnicas prospectivas

Este tipo de tcnica se baseia em saber a opinio do usurio com relao sua
interao com o sistema, avaliando o seu nvel de satisfao em relao expe-
rincia de uso. Geralmente esses mtodos so realizados por meio de entrevis-
tas e questionrios.
Quando se tem um nmero reduzido de usurios, as entrevistas so indica-
das, pois possvel identificar o nvel de ansiedade do usurio ao interagir com

captulo 4 85
o sistema, entretanto, por parecer um mtodo mais informal, por vezes pode
ser mais difcil obter resultados confiveis e vlidos. J os questionrios so in-
dicados quando o nmero de usurios muito grande, tendo perfis diferentes.

4.6.2 Tcnicas preditivas

Esto baseadas em conhecimento heurstico ou terico de um avaliador que

especialista. Neste caso, no preciso envolver os usurios, porque os especia-
listas usam o seu conhecimento sobre os usurios e as situaes tpicas de uso.
uma alternativa interessante em relao a custo.
Vamos ver algumas destas tcnicas.

4.6.2.1 Avaliao Heurstica

A avaliao heurstica identifica possveis problemas ou barreiras que possam

ser encontradas pelos usurios ao interagirem com o sistema permitindo uma
avaliao contnua a um baixo custo. Ela pode ser aplicada tanto no desenvolvi-
mento do projeto, quanto aps a sua implementao
Ela foi proposta por Jakob Nielsen (NIELSEN, 1994) e, segundo ele, o ob-
jetivo da avaliao heurstica encontrar os problemas de utilizao na con-
cepo, de modo que eles possam ser atendidos como parte de um processo
iterativo de design.
Nielsen chamou de heurstica porque so regras no mbito geral e no dire-
trizes especficas de usabilidade.
Neste tipo de tcnica considerado que somente uma pessoa no capaz
de encontrar todas as possveis falhas do sistema; por isso, para a avaliao,
proposta a seleo de um pequeno grupo avaliadores que submetem o sistema
aos princpios heursticos. Com isso eles podem estabelecer o que realmente
importante e necessrio para a construo de um modelo consistente. Eles se
baseiam em regras gerais que descrevem propriedades comuns construo
de interfaces. O design examinado em busca de elementos que violem essas
regras.
So atribudos valores de gravidade para cada problema encontrado em
cada passo, segundo uma escala proposta por Nielsen e Mack (1994):
0. No considerado em sua totalidade um problema de usabilidade.

86 captulo 4
 1. Problema apenas esttico: no necessrio consert-lo, a menos que se
tenho tempo extra no projeto.
2. Problema menor de usabilidade: dever ser dada baixa prioridade ao
conserto desse tipo de problema, no to importante consert-lo.
3. Problema maior de usabilidade: dever ser dada alta prioridade ao con-
serto deste problema, importante consert-lo.
4. Catstrofe de usabilidade: obrigatrio consert-lo, antes de o produto
ser divulgado.

A motivao principal do mtodo facilitar e acelerar o processo de avalia-

o de interfaces, maximizando o papel da experincia do avaliador, para en-
frentar a cada vez mais crescente demanda de boas interfaces.
As etapas principais so:
1. Preparao
2. Sesses curtas de avaliao individual
3. Consolidao das avaliaes individuais
4. Priorizao dos problemas encontrados
5. Relatrio conclusivo final

Sesses
Preparao Consolidao Priorizao Relatrio nal
curtas

Diversos autores de maior influncia na rea de IHC propuseram mto-

dos que avaliam sites e interfaces em todos os casos, sendo possvel encon-
trar algumas semelhanas nos mtodos propostos por eles. Entretanto, den-
tre esses autores, o que tem maior relevncia em relao aos demais por ter
proposto o termo e ter criado uma lista de dez heursticas que so imprescin-
dveis para a melhora na usabilidade das interfaces, Jakob Nielsen.

captulo 4 87
 Mantenha os usurios informados sobre o que est
VISIBILIDADE DO acontecendo por meio de feedback adequado e no
ESTADO DO SISTEMA tempo certo.

CORRESPONDNCIA Utilize conceitos, vocabulrio e processos familiares

ENTRE O SISTEMA E aos usurios.
O MUNDO REAL

CONTROLE E Fornea alternativas e sadas de emergncia e pos-

LIBERDADE DO sibilidades de voltar e refazer (undo e redo).
USURIO

Palavras, situaes e aes semelhantes devem

CONSISTNCIA E significar conceitos ou operaes semelhantes. Caso
PADRONIZAO haja convenes para o ambiente ou plataforma
escolhidos, estas devem ser obedecidas.

Tente evitar que o erro acontea informando o usurio

PREVENO DE sobre as consequncias de suas aes ou, se poss-
ERRO vel, impedindo aes que levariam a uma situao de
erro.

AJUDA AOS
USURIOS PARA Mensagens de erro em linguagem simples, sem cdi-
RECONHECEREM, gos, indicando precisamente o problema e sugerindo
DIAGNOSTICAREM E de forma construtiva um caminho de recuperao.
SE RECUPERAREM
DE ERROS

Em vez de memorizao, torne os objetos, aes e

RECONHECIMENTO opes visveis e compreensveis.

88 captulo 4
 Oferea aceleradores e caminhos alternativos para
FLEXIBILIDADE E uma mesma tarefa e permita que os usurios custo-
EFICINCIA DE USO mizem aes frequentes.

Evite pores de informao irrelevantes. Cada unida-

DESIGN ESTTICO E de extra de informao em um dilogo compete com
MINIMALISTA as unidades de informao relevantes e reduz sua
visibilidade relativa.

Devem ser fceis de buscar, focadas no domnio e na

AJUDA E tarefa do usurio, e devem listar passos concretos a
DOCUMENTAO serem efetuados para atingir seus objetivos.

O procedimento de execuo desta tcnica feito da seguinte maneira, por

meio de etapas:

A apresentao deve ser decidida entre papel, ou por

DETERMINAO meio de um prottipo ou por produto acabado. feita
DA PROPOSTA DE uma verificao das condies gerais da inspeo, a
DESIGN fim de verificar se o material completo e inspecionvel
est a contento.

NAVEGAO
GERAL PELO Determinao de qual o sentido geral o avaliador vai
SISTEMA (OU SUA dar ao sistema que vai analisar em detalhes.
REPRESENTAO)

DETERMINAO Quem so os usurios e suas caractersticas e con-

DO PERFIL DOS textos individuais, sociais e culturais. E o que desejam
USURIOS como objetivo com o produto.

captulo 4 89
 Em quais as situaes provveis, mas plausveis, os
DETERMINAO DE usurios poderiam encontrar-se? Ou seja, no que os ava-
CENRIOS DE USO liadores esto pensando quando fazem sua inspeo?

Algumas vezes os avaliadores fazem inspees de uma maneira mais geral,

sem instanciar usurios especficos ou cenrios de uso.
Todos os avaliadores juntos discutem as avaliaes individuais e examinam
as divergncias encontradas. Em seguida elaboram uma lista consensual de
violao das heursticas, cada qual com o respectivo grau de severidade estabe-
lecido em comum acordo.
Eles tambm atribuem prioridades de correo para todas as violaes lista-
das e geram um relatrio final do grupo com as suas concluses e comentrios.
Portanto, para se aplicar o mtodo, existem as seguintes maneiras:
1. Criar um conjunto de tarefas para ser aplicado pelos avaliadores;
2. Fornecer aos avaliadores os objetivos da aplicao e deixar que eles
criem suas prprias tarefas;
3. Pedir para os avaliadores testarem os elementos de dilogo.

A escolha do mtodo de aplicao a ser usado vai depender do tempo dis-

ponvel para teste e dos avaliadores. Por exemplo, se o grupo de avaliadores
formado por crianas, o mais apropriado usar um conjunto de tarefas criado
e executado pelos avaliadores.

EXEMPLO
Como exemplo, vamos citar o trabalho de Budd (BUDD, 2007) sobre heursticas para ques-
tes de web design.
Clareza: torne o sistema o mais claro, conciso e significativo possvel para os usurios finais.
o Escreva de forma clara e concisa.
o Somente utilize linguagem tcnica quando houver um pblico tcnico especfico.
o Escreva textos que sejam claros e significativos.
o E use cones que realmente representam o que eles se propem.
Diminua a complexidade desnecessria e a carga cognitiva: torne o sistema o mais simples
possvel para os usurios conclurem suas tarefas.
o Tire as funcionalidades, as etapas de processo e poluies visuais que no se-
jam necessrias.

90 captulo 4
 o Use a comunicao progressiva para esconder recursos avanados.
o Divida processos complicados em vrias etapas.
o Priorize o uso de tamanho, forma, cor, alinhamento e proximidade.
Fornea um contexto aos usurios: as interfaces devem dar aos usurios um contexto em
relao ao tempo e espao.
o D um nome claro e um objetivo para o site.
o Destaque a seo atual na navegao.
o Fornea um caminho de navegao.
o Use mensagens de feedback apropriadas.
o Mostre um nmero de etapas em um processo.
o Reduza a percepo de latncia, dando pistas visuais (um indicador de progresso
por exemplo), ou deixe que os usurios completem outras tarefas enquanto esto es-
perando.
Faa com que o usurio tenha uma experincia agradvel e positiva: o usurio deve ser
tratado com respeito, e o design deve ser esteticamente agradvel e promover uma expe-
rincia gratificante.
o Crie um design agradvel e atraente.
o Crie objetivos facilmente atingveis.
o Recompense o uso e a progresso.

4.6.2.2 Inspeo por meio de lista de verificao

A lista de verificao um checklist, ou seja, so vistorias baseadas em uma

lista em que existem itens a serem verificados por meio de profissionais, no
necessariamente especialistas em ergonomia, como por exemplo, programa-
dores e analistas, que diagnosticam os problemas gerais e repetitivos das inter-
faces rapidamente.
Ao contrrio das avaliaes heursticas, so as qualidades da ferramen-
ta (checklist), e no dos avaliadores, que determinam as possibilidades para
a avaliao.
Checklists bem elaborados devem produzir resultados mais uniformes e
abrangentes, em termos de identificao de problemas de usabilidade, pois os
inspetores so conduzidos no exame de interface por meio de uma mesma lista
de questes a responder sobre a usabilidade do projeto.

captulo 4 91
 As inspees por listas de verificao no precisam necessariamente ser
realizadas por profissionais especialistas em ergonomia.Podem ser realizadas
por programadores e analistas, isto porque quem determina a qualidade da
avaliao so as questes contidas na lista, e no os avaliadores. Se o questio-
nrio for bem elaborado, a inspeo por lista de verificao tende a produzir
resultados mais consistentes, uma vez que todos os avaliadores so conduzi-
dos por uma lista questes para realizar a avaliao de usabilidade do sistema.
Portanto, este tipo de avaliao apresenta uma srie de vantagens:
O conhecimento ergonmico est contido na prpria lista de verificao,
sendo assim, no so necessrios profissionais especializados em IHC, que so
mais escassos no mercado.
Existe a garantia de que os resultados sero mais estveis mesmo que fo-
rem aplicados separadamente por diferentes avaliadores, isso porque as ques-
tes da lista sempre sero verificadas.
As especificidades das questes da lista fazem com que problemas de usa-
bilidade sejam facilmente encontrados.
Reduo da subjetividade dos processos de avaliao.
Reduzir os custos da avaliao, pois e um mtodo de rpida aplicao, no
necessita de pessoal especializado.

Entretanto, para que essas listas sejam realmente efetivas, necessrio re-
duzir ao mximo o nmero de questes subjetivas que possam colocar o ava-
liador em dvida, ou exigir dele competncias a nveis de usabilidade ou ergo-
nomia que ele no possui. Outros fatores que podem interferir na economia da
inspeo so contedos incompletos ou mal organizados ou muito extensos,
que podem no ser aplicveis ao sistema.
Podemos ver, no exemplo de uma lista de verificao desenvolvida pelo
LabUtil chamada Ergolist (http://www.labiutil.inf.ufsc.br/ergolist/check.htm),
que existem diversos tpicos que so abordados e para cada um dos tpicos
existe uma srie de questes que sero respondidas pelos avaliadores.

92 captulo 4
captulo 4
Figura 4.1 Exemplo de checklist.

93
94
captulo 4
Figura 4.2 Continuao do checklist.
 4.6.3 Tcnicas objetivas

As tcnicas objetivas tambm so chamadas de tcnicas empricas e so basea-

das na participao direta dos usurios.
Apesar de existirem outras tcnicas, vamos estudar com mais destaque a
tcnica Ensaio de Interao.
ALPHASPIRIT | DREAMSTIME.COM

4.6.3.1 Ensaio de Interao

Como o prprio nome da tcnica sugere, um ensaio de interao consiste em

ensaiar o uso de um sistema, quase que literalmente, como se fosse um en-
saio de uma pea de teatro ou de uma banda.
No nosso caso, um ensaio de interao o uso simulado de um sistema em
que as pessoas que vo utiliz-lo participam das sesses e tentam fazer tarefas
usuais tpicas que fariam com um prottipo do sistema.
A preparao para o ensaio necessita de um trabalho detalhado de reconhe-
cimento do usurio final e de sua tarefa tpica para a composio dos cenrios e
procedimentos que vo ser aplicados durante a realizao das sesses de testes.

captulo 4 95
 Os ensaios de interao tm o objetivo de identificar problemas na interfa-
ces e pontos que atrapalhem a facilidade de uso. Dele participam pessoas inte-
grantes do seu pblico-alvo (usurios), realizando as mais diversas tarefas de
interao com o sistema.
Esse tipo de ensaio importante, pois mostra que nem todos pensam da
mesma forma. possvel comparar a forma de interao dos diferentes usu-
rios com o sistema e ver que eles interagem com o sistema de diferentes for-
mas. Esse tipo de observao permite que os analistas observem os pontos de
falha do sistema, o que pode fornecer novas ideias ao projeto.

Montagem de ensaio de interao

Anlise preliminar

Reconhecimento do software

Pr-diagnstico ergonmico

Denio dos cenrios e da amostra

Reconhecimento do usurio

Coleta de informaes sobre o usurio e sua tarefa

Denio de tarefas para o usurio

Realizao dos ensaios

Obteno das amostras de usurio

Ajustes nos scripts e cenrios

Preparao dos ensaios

Realizao dos ensaios

Coleta e anlise dos dados

Diagnstico e relatrio nal

Figura 4.3 Montagem do ensaio de interao.

96 captulo 4
 A figura 4.3 mostra um diagrama geral da montagem do teste de interao
de acordo com uma situao de responsabilidade. Percebemos que est dividi-
da em 3 partes:
Anlise preliminar;
Definio dos scripts, cenrios e da amostra;
Realizao dos ensaios.

Anlise Preliminar
No processo de preparao do teste, necessrio determinar o escopo do
teste, ou seja, o que se quer descobrir ao observar os usurios. Para tal, pre-
ciso conhecer cada usurio e saber quais so as tarefas que eles mais utilizam.
Instrues so dadas aos usurios no momento da aplicao do teste; so dis-
tribudos tambm blocos para anotaes. Ao realizar as tarefas, os usurios so
observados e avaliados, so verificadas todas as suas aes e reaes durante
todo o processo de interao.
Todas essas tarefas so observadas pelos avaliadores com auxlio de dispo-
sitivos de udio e vdeo, marcao de tempo, espelhos falsos, tudo isso para sa-
ber quais so as aes e as reaes dos usurios ao interagirem com a interface
do sistema. Os ensaios tambm podem ser gravados, para que a avaliao seja
realizada posteriormente.
A fase de anlise preliminar aquela em que os analistas entram em con-
tato com o software e o seu contexto de desenvolvimento e fazem um pr-diag-
nstico dos problemas de ergonomia de sua interface com o usurio.

Reconhecimento do software
Naturalmente, para o software ser reconhecido, so feitas algumas sesses
de entrevistas com as pessoas que projetaram e desenvolveram para trazer in-
formaes sobre o que foi projetado e desenvolvido.
As questes que so feitas a essa equipe so de vrias naturezas, como o
tempo de desenvolvimento, para quem o software foi desenvolvido, dados so-
bre o sistema, situao no mercado e etc.
Esse levantamento feito para comprender o ciclo de desenvolvimento do
software e dar fundamentos para o pr-diagnstico.

captulo 4 97
 Pr-diagnstico
Com base nas informaes obtidas pelos analistas, o software examinado
primeiro para que as funcionalidades sejam conhecidas e depois para identifi-
car as funes mais problemticas.
O pr-diagnstico pode ser obtido por meio de uma avaliao do tipo heurs-
tica ou ainda por meio de um checklist para inspeo ergonmica. Os critrios,
recomendaes e normas ergonmicas servem como ferramenta de apoio.
O resultado apresentado como um conjunto de hipteses sobre proble-
mas de usabilidade do software que sero testadas posteriormente durante os
ensaios de interao.

Definio dos scripts, cenrios e da amostra de usurios

Os scripts se referem ao conjunto de tarefas que uma amostra de usurios finais

dever realizar durante os ensaios. O cenrio se refere ao ambiente de execu-
o, envolvendo questes organizacionais. Os scripts e cenrios so montados
de acordo com as informaes obtidas no reconhecimento do software e de seu
pr-diagnstico ergonmico e das informaes obtidas pelo reconhecimento
do perfil do usurio e de sua tarefa.

Reconhecimento do perfil do usurio

A primeira tarefa desta parte contatar os usurios finais e verificar se eles
tm o mesmo perfil imaginado pelos projetistas. Nesta etapa j possvel esti-
mar o grupo que participar dos ensaios.

Coleta de informaes sobre o usurio e sua tarefa

Dependendo do pblico-alvo, pode ser que seja necessrio um detalha-
mento da coleta de informaes sobre os usurios e suas tarefas. Por meio de
questionrios, os projetistas podem buscar mais dados dos usurios em uma
amostra maior de pessoas. Estes questionrios podem servir como roteiros de
entrevistas presenciais ou a distncia.
Os questionrios podem coletar vrios tipos de dados, como:
recursos disponveis (tanto tcnicos como fsicos) para a realizao de
uma tarefa;
do contexto da tarefa;
do nvel dos usurios;
da utilizao do sistemas.

98 captulo 4
 Definio dos scripts de tarefas para os ensaios
Algumas tarefas so selecionadas para definir os scripts dos ensaios:
tarefas relacionadas com os objetivos principais do software, do ponto de
vista dos projetistas;
as hipteses dos projetistas de ergonomia, feitas no pr-diagnstico;
as amostras de tarefas dos usurios que foram obtidas com os questionrios;
as funcionalidades do sistema consideradas mais e menos importantes
pelo usurio;
as funcionalidades mais acionadas pelos usurio no uso do software.

Combinando estes parmetros, possvel criar um script, sempre conside-

rando a questo custo-benefcio dos ensaios. O importante saber avaliar criti-
camente sob o ponto de vista do usurio e de sua tarefa.
Os testes podem ocorrer em ambientes naturais, tendo como vantagem
ser o ambiente real de utilizao do software pelo usurio, mas com algu-
mas desvantagens:
Possvel descontrole sob as condies do teste;
Problemas tcnicos;
Interferncias durante o teste.

Ou podem ser realizados em laboratrios, que do condies melhores aos

avaliadores, mas podem gerar certos desconfortos aos usurios:
Condies artificiais;
Fora de contexto;
Inibio.

Aps a aplicao do teste, a satisfao dos usurios avaliada por meio de

questionrios e entrevistas.

ATIVIDADES
01. Informe as caractersticas voc gostaria de avaliar para os seguintes sistemas:
a) Um tocador de msica pessoal, como o iPod;
b) Um site para vender roupas.

captulo 4 99
02. Veja o Box sobre as heursticas para web design no texto. Selecione um site que voc
conhece bem e o avalie segundo as heursticas do Box.
a) Essas heursticas o ajudam a identificar questes importantes de usabilidade e expe-
rincia do usurio?
b) Saber das heursticas influencia de alguma forma o modo como voc interage com
o site?

03. Agora use as 10 heursticas comentadas no texto para avaliar um site que vende roupas
(por exemplo).
a) Como voc pode us-las para avaliar o site?
b) As heursticas o ajudam a se concentrar mais no site do que se voc no as estives-
se usando?
c) Usar menos heursticas poderia ser melhor? O que poderia ser combinado e quais so
as suas compensaes?

04. Voc conhece as barras de ferramentas da Microsoft, no ? Elas tm uma forma de

exibir uma pequena descrio abaixo de cada cone. Por que ferramentas com esta descrio
podem ser acessadas mais rapidamente? (Suponha que o usurio conhea a ferramenta e
no necessite da descrio para identific-la).

REFLEXO
Se voc estiver trabalhando no mercado de desenvolvimento, ou vai entrar em breve, voc
notar que ainda existem empresas que no do a devida ateno avaliao de interfaces,
como vimos neste captulo. Voc deve ter lido o box sobre as heursticas para a web. Percebe
que ali so dicas prticas e objetivas e at mesmo intuitivas e bvias, mas a quantidade de
empresas e equipes que nem imaginam que elas existem ainda muito grande. Esperamos
que voc, como futuro profissional, exera o seu papel e use estas tcnicas que foram intro-
duzidas aqui e ajude para melhorar a qualidade do software e das interfaces que geramos
atualmente. E nunca se esquea das questes relacionadas com acessibilidade, que j vimos
em outro captulo.

100 captulo 4
 LEITURA
Na Universidade Federal de Santa Catarina existiu at 2003 o LabIUtil (Laboratrio de Uti-
lizabilidade). Porm, o laboratrio ainda deixa alguns resultados disponveis, entre eles o Er-
golist, que um sistema de checklist bem interessante, desenvolvido em 1997 com apoio
da Softex.
Link: http://www.labiutil.inf.ufsc.br/ergolist/

Obs.: Utilizabilidade um neologismo da palavra francesa utilisabilit. Atualmen-

te a palavra foi substituda por usabilidade. Mas o nome do laboratrio permaneceu com
o neologismo.

Para quem quiser se aprofundar mais sobre design para web, este livro muito bom:
KOYANI, S. J.; BAILEY, R. W.; NALL, J. R. Research-based Web design and usability heu-
ristics. Computer Psycology, 2004

Outro livro bem legal, agora em portugus:

CARRION, W. Design para webdesigners: princpios de design para web. Rio de Janeiro:
Brasport, 2008

Este livro tambm interessante e o autor o Jakob Nielsen, pai das heursticas que
estudamos:
LORANGER, H.; NIELSEN, J. Usabilidade na web: projetando websites com qualidade.
Rio de Janeiro: Campus, 2007

REFERNCIAS BIBLIOGRFICAS
BUDD, A. Heuristics for Modern Web Application Development. Blogography, 2007. Disponivel
em: <http://www.andybudd.com/archives/2007/01/heuristics_for_modern_web_application_
development/>. Acesso em: 01 jul. 2015.
CYBIS, W. A. Engenharia de usabilidade: uma abordagem ergonmica. Florianpolis: Universidade
Federal de Santa Catarina, 2003.
MORAIS, . M. D. UM ESTUDO SOBRE A VALIDADE E FIDEDIGNIDADE DE MTODOS
DE AVALIAO DE INTERFACES. Universidade Estadual de Maring. Maring, p. 116. 2007.
(Dissertao (Mestrado em Cincia da Computao)).

captulo 4 101
NIELSEN, J. Heuristic evaluation. In: NIELSEN, J.; MACK, R. L. Usability inspection methods. New
York: John Wiley & Sons, 1994.
ROGERS, Y.; SHARP, H.; PREECE, J. Design de interao. Porto Alegre : Bookman, 2013.
RUBIN, J. Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. New
York: John Wiley and Sons, 1984.

102 captulo 4
 5
Acessibilidade
Web
Acessibilidade uma palavra composta por duas partes: acessvel, que origi-
nada da palavra acesso, de accedere, que por sua vez formada por ad (a) e
cedere (ir, mover-se). O sufixo dade colocado em adjetivos para formar
substantivos que expressam estado ou quantidade. Portanto, fica mais do que
claro que acessibilidade um estado acessvel e uma possibilidade de ir a al-
gum lugar.
S quem tem alguma necessidade especial ou parentes e amigos portado-
res que sabe o quanto os lugares ainda precisam ser acessveis e tambm na
internet: se a internet de todos, como dizem, no se pode deixar de lado as
pessoas portadoras de necessidades especiais. Muito j foi feito e muito ainda
precisa ser feito.
Na verdade, quem no possui deficincia ou at mesmo mobilidade reduzi-
da, ou no est envolvido com pessoas que possuem, no conseguem imaginar
tantas situaes que discriminam as pessoas que sofrem com uma situao
inadequada, como um banheiro no adaptado, uma calada sem rebaixamen-
to, e at mesmo um site na internet.
Quando se trata de acessibilidade na web, existem muitos pontos que pre-
cisam ser considerados. A W3C (World Wide Web Consortium) tem um grupo
de trabalho que recomenda algumas aes a serem feitas em sites para poder
atender s pessoas com necessidades especiais.
Neste captulo vamos estudar estas recomendaes e compreender a
sua importncia.

OBJETIVOS
Final deste captulo, voc estar apto a:
Saber a importncia de desenvolver sites acessveis;
Projetar sites acessveis bsicos.

104 captulo 5
5.1 Introduo acessibilidade
Antes de entrarmos com tudo na questo da web, interessante conceituar
acessibilidade de maneira geral.
Basicamente, todos deveriam ter as mesmas oportunidades e, por incrvel
que parea, esta preocupao comeou a tomar mais fora nos ltimos anos.
Veja por exemplo alguns teatros antigos, suntuosos e famosos: eles no tinham
rampas de acesso e elevadores at h pouco tempo. interessante observar
que este tipo de construo antiga no tinha referncia alguma em relao
acessibilidade.
At mesmo nas nossas ruas. difcil encontrar em algumas cidades cala-
das rebaixadas, sinalizao para pessoas com necessidades visuais, cadeirantes
e muitas outras melhorias que certamente colaborariam para que todas estas
pessoas tenham as mesmas oportunidades que os outros.
E um dever do estado que isto seja assegurado.
De acordo com a lei n 10.098/2000, a acessibilidade conceituada como
a possibilidade de dar s pessoas com necessidades especiais o alcance e uso,
com segurana e autonomia, de espaos, imobilirios e equipamentos urba-
nos, edificaes, transportes e sistemas e meios de comunicao. Portanto, o
acesso internet est includo nesta lei.
Em relao parte que cuida da comunicao, a lei prev a eliminao de
barreiras na comunicao e procura estabelecer alternativas tcnicas que dei-
xem os sistemas de comunicao e sinalizao acessveis.
A acessibilidade um assunto no to recente. No Brasil, a questo tomou
maior discusso em 1981, quando este foi chamado de Ano Internacional dos
Portadores de Deficincia pela ONU. Em 1982, a ONU criou o Programa Ao
Mundial para Pessoas com Deficincia, no qual prevalecia que as pessoas nes-
tas condies tm o mesmo direito que os demais cidados s mesmas oportu-
nidades e usarem em condies de igualdade.
Em 1985 o Brasil publicou a primeira norma tcnica que trata de questes
relacionadas com o tema, a NBR 9050/1985. Porm trata de adequao das edi-
ficaes e do mobilirio urbano pessoa deficiente. Nesta norma, acessibilida-
de : possibilidade e condio de alcance, percepo e entendimento para a
utilizao com segurana e autonomia de edificaes, espao, mobilirio, equi-
pamento urbano e elementos.

captulo 5 105
 Portanto, cada definio, seja na lei ou na norma, enfoca que acessibilidade
significa alcanar alguma coisa com autonomia, mesmo que seja assistida.
Em relao internet, a preocupao com o contedo acessvel comeou
pelo W3C, em 1999, por meio da iniciativa chamada Web Assistive Iniciative
(WAI). Nesta ocasio, foi elaborado o primeiro documento para auxiliar os de-
senvolvedores de pginas a tornarem suas pginas mais acessveis. Este docu-
mento foi o Web Content Acessibility Guidelines. O WAI foca em trs linhas:

Navegadores para web

players de multimdia

tecnologias assistivas

Veja as figuras a seguir com exemplos de lugares e situaes acessveis:

Figura 5.1 Balano acessvel.

106 captulo 5
 Figura 5.2 Piscina acessvel.
WIKIPEDIA

Figura 5.3 Piso ttil.

captulo 5 107
5.2 Acessibilidade na web e sua importncia
Uma vez que conceituamos acessibilidade, vamos agora tratar da acessibilida-
de na web. Sabemos que a web foi fundada por Tim Barners-Lee e este diretor
do W3C. O W3C, por sua vez, uma comunidade internacional em que vrias
empresas membro e uma equipe dedicada integralmente, junto com o pblico,
desenvolvem padres para a web. O objetivo principal do W3C obter todo o
potencial da web.
Sem dvida, o W3C a principal referncia e detentora das principais dire-
trizes para se estabelecer um padro de construo de sites e demais elemen-
tos. Portanto, as diretrizes e guias do W3C sero usadas neste captulo como
referncia para a acessibilidade na web.
O W3C possui padres relacionados com a acessibilidade. Por meio de seu
site (WORLD WIDE WEB CONSORTIUM, 2015), podemos perceber que a aces-
sibilidade um assunto prioritrio para eles. Segundo o site, a web funda-
mentalmente projetada para ser usada por todas as pessoas, no importando o
hardware, software, lngua, cultura, localizao ou habilidade fsica ou mental.
A acessibilidade na web importante porque nos faz lembrar que grande
parte da populao que consome materiais que esto na web tem algum tipo de
deficincia e isto pode significar perda ou limitao de oportunidades da vida
em comunidade em condies de igualdade com as demais pessoas.
Segundo (FERNANDES e GODINHO, 2013), o uso de acessibilidade no de-
senvolvimento de pginas e aplicaes na web no se caracteriza uma limita-
o, mas, ao contrrio, os elementos de acessibilidade, com seus padres e
regras, tornam os documentos mais flexveis, abrangentes e fceis de se usar.

MULTIMDIA
Este link mostra um vdeo sobre acessibilidade na web para celebrar o Dia Internacional
das Pessoas com Deficincia, que ocorreu em 3 de dezembro de 2012 e encerrou a Virada
Inclusiva na escultura da Mo, no Memorial da Amrica Latina, em So Paulo.
https://goo.gl/saZc1L

O W3C tem escritrio no Brasil, o W3C Brasil, o qual desenvolve aes lo-
cais para o desenvolvimento dos padres web. Eles tmum grupo de trabalho

108 captulo 5
exclusivo para os padres de acessibilidade, o qual lanou uma cartilha com 7
fascculos que serve para orientar as pessoas sobre a importncia da acessibi-
lidade na web.
Segundo a cartilha (W3C, 2011), a acessibilidade na web est compatvel com
os conceitos que vimos sobre acessibilidade e uma atividade complexa. E suge-
re a considerao de alguns aspectos para abordar a complexidade do problema:
A importncia, abrangncia e a universalidade da web: a web um ambien-
te multimdia, com vrias possibilidades e muito abrangente. Segundo o W3C,
uma pessoa com deficincia deveria acessar a web em melhores condies, pois
j tem dificuldades em acessar as mesmas informaes no mundo fsico.
Reciprocidade: a acessibilidade no apenas uma questo de mo ni-
ca, ou seja, podemos ser induzidos a pensar que as pessoas so apenas recep-
toras. Segundo o W3C, a pessoa com deficincia tambm contribui para a web.
Logo, quanto mais pessoas puderem acessar, mais a web ter contribuies.
Multiplicidade e diversidade de fatores envolvidos: a acessibilidade na
web alcanada considerando-se uma srie de fatores segundo o W3C:
o Contedo;
o Navegadores, ou agente do usurio;
o Tecnologia assistida: a tecnologia usada por pessoas com deficin-
cia e mobilidade reduzida;
o Conhecimento do usurio para o uso da web;
o Desenvolvedores e usurios;
o Ferramentas da autoria;
o Ferramentas de avaliao.

Segundo a cartilha, a acessibilidade na web permitir que qualquer pes-

soa, usando qualquer tecnologia de navegao, visite qualquer site e obtenha
completo entendimento das informaes contidas nele, alm de ter total ha-
bilidade de interao. Ou seja, ter um ambiente que no seja diferente para
qualquer tipo de pessoa.

CURIOSIDADE
Um exemplo de acessibilidade e de que no s a web, mas a tecnologia em geral, usada
em prol da acessibilidade a vida do fsico Stephen Hawking, um dos mais consagrados
cientistas da atualidade.

captulo 5 109
 WIKIPIDIA

Figura 5.4 Stephen Hawking.

Stephen usa um aparelho, chamado Equalizer, o qual fala as palavras por Stephen por
meio de suas mos. Com este aparelho, Stephen consegue escrever livros, ensaios e proferir
palestras pelo mundo. Quando ele perdeu o movimento das mos, passou a controlar o apa-
relho por meio de sua bochecha.
Assista ao vdeo a seguir, o qual mostra o funcionamento do aparelho (e aprenda tam-
bm um pouco sobre o que ele acha do universo):
https://www.youtube.com/watch?v=85IzieOYCq0

5.3 A Web acessvel

A partir de uma web acessvel, vrios cenrios que poderiam ser impossveis
de ocorrer se tornam viveis, no s para pessoas com deficincia, mas para
qualquer categoria de usurio. Segundo a cartilha, podem ocorrer esses casos:
Uma pessoa cega usando um leitor de telas pesquisando o site da
Receita Federal;
Um usurio cego e sem braos procurando sua ex-professora em um sis-
tema de busca usando um programa de reconhecimento de voz para entrar co-
mandos e receber a resposta a partir do leitor de telas;

110 captulo 5
 Um usurio com paralisia cerebral e com dificuldades motoras usando o
computador com um dedo s e navegando nas redes sociais;
Um usurio com deficincia motora usando um mouse adaptado fazendo
compras pela internet;
Uma pessoa tetraplgica usando um ponteiro na cabea procurando in-
formaes sobre clulas-tronco em sites especializados;
Um usurio com deficincia intelectual fazendo exerccios pela web para
melhorar sua comunicao;
E outros.
Os exemplos anteriores so apenas poucas das situaes que podem ocor-
rer envolvendo acessibilidade e web. Portanto, precisamos encontrar mecanis-
mos para ajudar nessas situaes.

5.4 Componentes essenciais para acessibilidade

na Web

Segundo o WAI (Web Acessibility Iniciative) (W3C-WAI, 2013), a acessibilidade

na web depende de vrios componentes trabalhando conjuntamente e melho-
rias em componentes especficos. Estes componentes incluem:

A informao em uma pgina da web ou em uma apli-

cao incluindo:
o informao natural como textos, imagens e
CONTEDO sons
o cdigo ou marcao que define estrutura,
apresentao, etc.

NAVEGADORES, E outros agentes de usurio

PLAYERS DE MDIA

TECNOLOGIA Em alguns casos, leitores de tela, teclados alternativos,

ASSISTIDA software de rastreamento, etc.

captulo 5 111
 CONHECIMENTO DO Experincias e em alguns casos, estratgia adaptativas
USURIO usando a web.

Projetistas, programadores, autores, etc., incluindo

DESENVOLVEDORES desenvolvedores com deficincias e usurios que con-
tribuem com contedo.

SOFTWARES DE Softwares que criam web sites.

AUTORIA

FERRAMENTAS DE Ferramentas de avaliao de acessibilidade na web,

AVALIAO validadores de HTML, validadores de CSS, etc..

Figura 5.5 Como os componentes esto relacionados.

A figura 5.5 mostra como os componentes citados esto relacionados: os de-

senvolvedores normalmente usam softwares de autoria e ferramentas de ava-
liao para criar contedo. Os usurios usam navegadores, players de mdia,
tecnologias assistivas ou outros agentes de usurio para acessar e interagir com
o contedo.

112 captulo 5
 As figuras a seguir mostram exemplos de tecnologias assistivas. A figura
5.6 mostra um deficiente visual usando um leitor de tela para poder ler o que
est sendo mostrado. A figura 5.7 mostra um leitor de textos impressos. O leitor
escaneia o texto impresso e o traduz em voz alta para deficientes auditivos. A
Figura 8 um leitor de tela em Braille. Neste dispositivo, o contedo impresso
da pgina transformado em caracteres Braille para os deficientes visuais po-
derem ler.

Figura 5.6 Deficiente visual usando um leitor de tela.

Figura 5.7 Leitor de impressos.

captulo 5 113
Figura 5.8 Leitor de Braille.

5.4.1 Interdependncia entre componentes

Existe uma interdependncia significativa entre os componentes, ou seja, os

componentes devem trabalhar conjuntamente, com o objetivo de deixar a web
acessvel. Por exemplo, para um texto alternativo nas imagens:

CONCEITO
Texto alternativo nas imagens: em HTML, na tag para imagens existe uma opo de
usarmos um texto alternativo, por exemplo:
<img src="smiley.gif" alt="Smiley face">
Esta tag posiciona uma figura na tela e, quando o mouse for colocado sobre a figura, ir
aparecer o texto Smiley face. No caso da acessibilidade, como o deficiente visual no v a
imagem, o texto alternativo impresso no leitor de tela.

Estabelecem textos alternativos (por exemplo,

ESPECIFICAES TCNICAS o HTML define o atributo alt na tag img)

A WAI apresenta alguns guias que definem

GUIAS DA WAI como implementar os textos alternativos para
acessibilidade nos diferentes componentes.

114 captulo 5
 Fornecem as palavras apropriadas para se
DESENVOLVEDORES colocar no texto alternativo.

Possibilitam, facilitam e promovem o texto

FERRAMENTAS DE AUTORIA alternativo em uma pgina.

FERRAMENTAS DE So usadas para ajudar a checar quais textos

AVALIAO alternativos existem.

Fornecem interface humana para o texto

AGENTES DE USURIO alternativo.

Fornecem os textos alternativos em vrias

TECNOLOGIAS ASSISTIVAS modalidades.

Sabem como pegar o texto alternativo do

USURIOS agente do usurio e/ou tecnologia assistiva.

5.4.2 O ciclo de implementao

Quando as caractersticas de acessibilidade so implementadas efetivamente

em um componente, possibilita a implantao nos outros componentes .

Contedo

Navegadores, Players de mdia

Ferramentas de autoria

Tecnologias assistivas

Contedo

captulo 5 115
 Quando os navegadores, players de mdia, tecnologias assistivas e outros
agentes de usurio suportam uma caracterstica acessvel, os usurios ficam
mais propensos a demandar esta caracterstica, e os desenvolvedores ficam
mais propensos a implement-la no contedo.
Quando os desenvolvedores querem implementar um recurso de acessi-
bilidade em seu contedo, eles so mais propensos a exigir que a sua ferramen-
ta de criao torne a implementao mais fcil.
Quando as ferramentas de criao tornam um recurso fcil de ser im-
plementado, os desenvolvedores ficam mais propensos a implement-lo em
seu contedo.
Quando um recurso de acessibilidade implementado no contedo, de-
senvolvedores e usurios ficam mais propensos a exigir que os agentes de co-
mecem a apoi-lo.
Se um componente de acessibilidade no implementado em um compo-
nente, h uma pequena motivao para o outro componente implement-lo
quando no resulta em uma experincia do usurio acessvel. Por exemplo, de-
senvolvedores no so propensos a implementar uma caracterstica de acessi-
bilidade que as ferramentas de autoria no suportam e que a maioria dos nave-
gadores ou tecnologia assistiva no implementa consistentemente.
Se um componente de acessibilidade tem um suporte ruim, algumas ve-
zes outros componentes podem compensar por meio de um work around,
que requer muito mais esforo e no to bom para acessibilidade no geral.
Por exemplo:
Desenvolvedores podem ter mais trabalho para compensar alguma falta
de suporte acessibilidade em ferramentas de autoria, por exemplo, progra-
mando diretamente em HTML em vez de usar uma ferramenta.
Usurios podem ter mais trabalho para compensar alguma falta de su-
porte de acessibilidade nos navegadores, players de mdia e tecnologia as-
sistiva e falta de acessibilidade de contedo, por exemplo, usando diferentes
navegadores ou tecnologias assistivas para superar as diferentes questes
de acessibilidade.

No entanto, na maioria dos casos, esses work-arounds no so implemen-

tados, e o resultado ainda uma fraca acessibilidade. Alm disso, por vezes, um
suporte ruim de acessibilidade em um componente no pode ser razoavelmen-
te ultrapassado por outros componentes, e o resultado a inacessibilidade, o

116 captulo 5
que torna impossvel para algumas pessoas com deficincia a usar um determi-
nado site, pgina ou recurso.

5.5 Projeto e desenvolvimento de um site

acessvel

A elaborao de um site acessvel um assunto bastante amplo. A amplitude

est relacionada com alguns fatores, como se o site vai ser acessvel por real-
mente se importar com pessoas portadoras de necessidade especial ou se por
alguma imposio da empresa ou at mesmo para se atingir um novo pblico.
Vamos estudar alguns pontos tcnicos que podem ajud-lo a criar um site
acessvel e ajud-lo no projeto de um site deste tipo segundo (POPLADE, 2010):
Veja a primeira linha de um site:
1. <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pt-br" lang="pt-br>

Veja que usamos a tag xml: lang e lang. E definimos um idioma para elas.
Estas tags so importantes porque dizem ao leitor de tela qual a lingua-
gem que deve ser falada e instrui corretamente o leitor de tela para usar os
codecs corretos.
Outra tag importante para a acessibilidade a tag meta. Veja o exemplo:

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>

O charset presente na tag informa ao navegador qual a codificao da p-

gina. No caso do Brasil, a codificao ISO-8859-1 caracteriza os caracteres em
portugus e tambm auxiliam o leitor de tela com a correta leitura das palavras
presentes na pgina.
Outra tag importante a <title>. Ela pode gerar uma certa polmica, pois
tambm usada pelo leitor de tela para poder informar o ttulo da pgina, mas
tambm usada pelos indexadores a posicionar melhor a pgina nos mecanis-
mos de pesquisa. Sendo assim, ocorre uma dvida. O que melhor: prezar pela
acessibilidade ou por uma melhor colocao nos mecanismos de pesquisa? O
melhor escrever um ttulo que seja claro e coerente sem excluir as palavras-
-chave da pgina.

captulo 5 117
 O atributo rel da tag <link> tambm usado nos sites acessveis. Quando
arquivos externos so linkados pgina, importante para os leitores de tela
determinarem o tipo de arquivo ou pgina externa que est sendo vinculado.
O normal deste atributo usar o valor stylesheet, utilizado para os arquivos
CSS. Os valores tambm podem ser content, indicando contedo, prev para
pginas anteriores e next para as pginas posteriores.
A tag <body> tambm precisa de alguma ateno. J comentamos que, na
tag <img>, o atributo alt importante para os leitores de tela substiturem as
imagens pelas suas descries. Portanto, usar textos intuitivos nestas descri-
es, inclusive para o caso de a imagem no ser carregada corretamente.
Nos links, recomenda-se usar o atributo title na tag <a> com textos intuiti-
vos e claros que mostram o destino do usurio ao clicar no link, e no somen-
te com a descrio clique aqui, por exemplo. Outros atributos importantes
para a acessibilidade relacionados com essa tag so o tabindex e o accesskey. O
primeiro atributo faz com que uma ordem seja estabelecida nos elementos da
pgina, quando a tecla tab pressionada e a segunda cria uma tecla de atalho
para o elemento.
Outro detalhe para os deficientes visuais usar a tag <noscript> nos scripts.
Desta forma, o deficiente visual no precisar ouvir todas as linhas de cdigo
dos scripts da pgina.
Existem outros fatores tcnicos que podem estar presentes em um site
acessvel. Mostramos alguns; outros podem ser incorporados mediante as re-
comendaes do W3C, como veremos no prximo tpico.

5.5.1 Recomendaes do W3C

O W3C tem um documento (W3C, 2008) quel contm recomendaes e diretri-

zes para se construir um site acessvel. Ao seguir estas recomendaes, o con-
tedo acessvel poder atingir um maior nmero de pessoas com deficincias,
das mais variadas formas.
O documento est dividido em 4 princpios e cada um contendo uma ou
mais diretrizes. Os princpios so:

118 captulo 5
5.5.1.1 Princpio 1 - Percepo

Os componentes de informao e interface de usurio devem estar presen-

tes para os usurios em modos que eles possam visualiz-los.
As diretrizes deste princpio so:

Fornea alternativas em texto para qualquer contedo no

ALTERNATIVAS textual, de forma que ele possa ser transformado em outros
EM TEXTO formatos necessrios para as pessoas, como letras grandes,
braile, fala e linguagem mais simples.

Fornea alternativas para este tipo de mdia. Esta diretriz refe-

MDIA re-se a mdias que so transmitidas principalmente em tempo
BASEADA NO real. O W3C recomenda que algum tipo de texto acompanhe
TEMPO o udio ou o vdeo transmitido.

Crie contedo que possa ser apresentado em formas diferen-

ADAPTAO tes (por exemplo em um layout mais simples) sem perder a
informao ou estrutura.

Torne mais fcil para o usurio ver e ouvir o contedo, incluin-

DISTINGUVEL do as separaes entre o primeiro e segundo plano. A cor no
usada como o nico recurso visual. Use alternativas.

5.5.1.2 Princpio 2: Opervel

Os componentes de interface do usurio e navegao devem estar operveis.

As diretrizes para este princpio so:

TECLADO Faa toda a funcionalidade do site ser acessada pelo teclado.

ACESSVEL

captulo 5 119
 TEMPO Fornea tempo suficiente para os usurios lerem e usarem o
DISPONVEL contedo.

No criae contedo de uma forma que pode causar convul-

ses. Algumas pessoas com distrbios convulsivos podem ter
CONVULSES uma convulso desencadeada por algum contedo piscando
na tela. Muitas pessoas desconhecem ter este problema at
que elas tenham de fato.

Fornea modos para auxiliar os usurios a navegarem pelo

NAVEGVEL site, procurar contedo, e determinar onde eles esto.

5.5.1.3 Princpio 3: Entendvel

A informao e a interface com o usurio devem ser entendveis.

As diretrizes para este princpio so:

LEGVEL Faa com que o texto seja lido e entendido sem problemas.

Faa com que as pginas apaream e funcionem de maneira

PREVISVEL previsvel.

ASSISTNCIA Ajudar os usurios a evitar e corrigir erros.

DE ENTRADAS

5.5.1.4 Princpio 4: Robusto

O contedo deve ser robusto o suficiente para que ele possa ser interpretado
de forma confivel por uma grande variedade de agentes de usurio, incluindo
tecnologias assistivas.

120 captulo 5
 Este princpio s tem uma diretriz:

Maximizar a compatibilidade com agentes de usurios atuais e

COMPATVEL futuros, incluindo as tecnologias assistivas.

Uma vez que verificamos como podemos criar sites acessveis, interessan-
te tambm testar e validar a acessibilidade do site.

5.5.2 Mtodos e validadores de acessibilidade na web

Existem basicamente duas formas de se verificar a acessibilidade de um site

na internet: automaticamente e pela forma direta. Embora os mtodos auto-
mticos sejam vantajosos no sentido de rapidez, eles no conseguem atender
a todos os requisitos de acessibilidade. A maneira direta quando o prprio
usurio verifica a acessibilidade, e a maneira automtica quando usamos al-
gum software para isso.
A figura 5.9 mostra os selos dos validadores automticos do W3C. O W3C
tem algumas ferramentas que conectam no site-alvo e fazem uma varredura
buscando algum tipo de inconformidade com os padres usados. Caso no
haja inconformidade o site pode colocar o selo especfico no seu contedo e
indicar que o site passou nos padres do W3C.
Na figura 5.9 temos os seguintes selos de validao:

Valida o site de acordo com os padres da linguagem

HTML 4.01 HTML 4.01.

Valida o site de acordo com os padres de XHTML nas

XHTML 1.0 E 1.1 verses 1.0 e 1.1.

Valida o site de acordo com os padres de acessibilida-

WAI-A, WAI-AA, de do W3C, nvel A, duplo A, triplo A respectivamente,
WAI-AAA que compatibilizam com as Prioridades 1, 2 e 3 das
diretrizes do W3C para acessibilidade.

captulo 5 121
 Valida o site de acordo com os padres estabelecidos
RSS VALID para as notificaes RSS.

AAA APROVADO Validador brasileiro do guia Acessibilidade Brasil.

W3C CSS Valida o site de acordo com os padres de CSS do W3C.

Alguns sites podem passar pela validao do cdigo XHTML e no passar

na validao do CSS. E assim por diante. Veja que no caso de acessibilidade,
temos, alm do validador do W3C, o validador brasileiro.

HTML XHTML
4.01 1.0

WAI - A WAI - AA
WCAG 1.0 WCAG 1.0

AAA VALID
APROVADO RSS
ACESSIBILIDADE BRASIL

XML
CSS
1.0

WAI-AAA XHTML
WCAG 1.0 1.0
Figura 5.9 Selos de validadores do W3C.

122 captulo 5
 Quanto validao humana, esta deve ajudar a verificar a clareza da lingua-
gem, o bom uso dos equivalentes em texto e a facilidade de navegao e usabi-
lidade, por exemplo.
Com relao aos mtodos automticos, so eles, segundo (QUEIROZ, 2008):
1. Usar uma ferramenta de acessibilidade automatizada, porm algu-
mas questes de acessibilidade no so possveis de serem verificadas por um
software e necessitam ser verificadas pela forma humana.
2. Validar a sintaxe do cdigo.
3. Validar as folhas de estilo (CSS).
4. Usar um analisador de contraste de cores para assegurar a boa visibili-
dade do site, at mesmo por pessoas com deficincias visuais.
5. Usar um navegador s de texto como o Lynx ou um emulador. Esses na-
vegadores no carregam os scripts em javascript e imagens forando o usurio
a usar principalmente o teclado.
6. Utilizar vrios navegadores como o Internet Explorer, Google Chrome,
Mozilla Firefox, Safari, Opera etc., principalmente para aferir e verificar
o comportamento:
a. Som
b. Desativar as imagens do navegador
c. Sem som
d. Sem mouse
e. Sem carregar frames
7. Usar vrios navegadores, recentes e mais antigos.
8. Usar um leitor de tela e verificar se ele l a pgina corretamente, utilizar
um ampliador de tela, tela de dispositivo mvel.
9. Usar corretores ortogrficos e gramaticais.
10. Rever o documento para verificar sua clareza e simplicidade.
11. Pedir para uma pessoa portadora de necessidades especiais para verifi-
car o site. Estes usurios so muito importantes para a validao geral do site,
tanto na parte de contedo quanto na parte dos recursos de acessibilidade pre-
sentes no site e facilidade de uso.

Lembre-se, que o selo de validao importante. No deixe de validar o seu

site. Muitos programadores e desenvolvedores deixam de fazer esta tarefa e,
quando passam por algum validador, acabam se espantando com o resultado.

captulo 5 123
 Outros, colocam os selos de validao com o site no validado. Se no for va-
lidado, no coloque! No h desculpa para no validar um site. E tenha sempre
um cuidado especial com a validao de acessibilidade.

GLOSSRIO
CSS Cascade Style Sheet
HTML Hypertext Markup Language
RSS Really Simple Syndication
W3C World Wide Web Consortium
WAI Web Acessibility Iniciative
XHTML Extensible Hypertext Markup Language

ATIVIDADES
01. O que tecnologia assistiva?

02. Pesquise e responda: O que a Web Acessibility Iniciative?

03. Qual a importncia do W3C para a web?

04. Acesse o site www.acessibilidadelegal.com. Quais os elementos de acessibilidade en-

contrados no site?

05. Sites acessveis so necessariamente feios, sem cores e imagens?

REFLEXO
Parece que a situao que vivemos nos remete a consumir cada vez mais, e isso se reflete
na internet. Os sites esto cada vez mais interativos e chamativos. Temos tecnologias super
legais, como os bancos de dados no relacionais, novos frameworks na rea de front end,
como AngularJS, NodeJs, Material Design, e vrias outras tecnologias que encantam quem
desenvolve para web. Porm, na questo da acessibilidade em relao a todo esse avan-
o, ser que quem promove todas essas tecnologias, bem como incita outros a usarem e
consumirem, tambm est preocupado com o acesso daqueles que portam algum tipo de
necessidade especial?

124 captulo 5
 LEITURA
Sobre acessibilidade, praticamente obrigatria a leitura dos documentos do W3C sobre
padres de web e acessibilidade:
Grupo de trabalho do W3C e acessibilidade: http://www.w3c.br/GT/GrupoAcessibilidade
Cartilha de acessibilidade na web: http://www.w3c.br/Materiais/PublicacoesW3C
Site excelente sobre acessibilidade com vrios materiais: http://www.acessibilidadelegal.com/
Acessibilidade virtual: http://acessibilidade.bento.ifrs.edu.br/acessibilidade-web.php
Site do Maujor: site do Maurcio Samy Silva, com muitos materiais sobre desenvolvimento
para web e vrios sobre acessibilidade: http://www.maujor.com/w3c/introwac.html

REFERNCIAS BIBLIOGRFICAS
FERNANDES, J.; GODINHO, F. Publicaes. Unidade Acesso, 2013. Disponivel em: <http://www.
acessibilidade.gov.pt/publicacoes#manuais>. Acesso em: 1 jul. 2015.
POPLADE, T. Como tornar seu site acessvel. Tableless, 2010. Disponivel em: <http://tableless.
com.br/como-tornar-seu-website-acessivel/>. Acesso em: 01 jul. 2015.
QUEIROZ, M. A. D. Mtodos e Validadores de Acessibilidade Web. Acessibilidade Legal, 2008.
Disponivel em: <http://www.acessibilidadelegal.com/13-validacao.php>. Acesso em: 1 jul. 2015.
W3C. Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation, 2008. Disponivel em:
<http://www.w3.org/TR/WCAG20/>. Acesso em: 01 jul. 2015.
W3C. Acessibilidade na Web. W3C, 2011. Disponivel em: <http://www.w3c.br/pub/Materiais/
PublicacoesW3C/cartilha-w3cbr-acessibilidade-web-fasciculo-I.pdf>. Acesso em: 1 jul. 2015.
W3C-WAI. W3C Web Acessibility Iniciative. World Wide Web Consortium, 2013. Disponivel em:
<http://www.w3.org/WAI/intro/wcag.php>. Acesso em: 1 jul. 2015.
WORLD WIDE WEB CONSORTIUM. Acessibility. W3C, 2015. Disponivel em: <http://www.w3.org/
standards/webdesign/accessibility>. Acesso em: 01 jul. 2015.
BRASIL. Lei n. 10.098, de 19 de dezembro de 2000. Estabelece normas gerais e critrios bsicos
para a promoo da acessibilidade das pessoas portadoras de deficincia ou com mobilidade reduzida,
e d outras providncias. Disponvel em: <http://www.planalto.gov.br/ccivil_03/leis/L10098.htm>.
Acesso em 29/07/2015.

captulo 5 125
 GABARITO
Captulo1

01. O conceito de tecnologia, ou computao, vestvel no novo. Em 1998, Steve Mann de-
finiu como: Um computador vestvel um computador que est alocado no espao pessoal
do usurio, controlado pelo usurio, e possui constncia de operao e interao, ou seja,
est sempre ligado e sempre acessvel. Mais notavelmente, ele um dispositivo que est
sempre com o usurio, e permite que o usurio digite comandos ou os execute, enquanto
anda ou faz outras atividades (Fonte: https://pt.wikipedia.org/wiki/Computa%C3%A7%-
C3%A3o_vest%C3%ADvel)

02. A engenharia de usabilidade uma rea que estuda principalmente formas de melhorar
a interface com o usurio, principalmente para ser mais fcil, direta e interativa. Existe um
processo de desenvolvimento, que se bem feito, garante uma interface com alta usabilidade.

03. A norma 9126 tem como foco a qualidade do produto por meio de critrios e um deles
a usabilidade. Esta norma a primeira a definir usabilidade e a trata por meio de uma aborda-
gem orientada ao produto e ao usurio. Na norma existem trs mtricas para a usabilidade:
integibilidade, apreensibilidade e operacionabilidade.

04. A rea de interface humano computador importante porque estuda formas e processos
para melhorar a usabilidade dos produtos de software. Conforme a tecnologia avana, assim
como a aproximao do homem com o computador, ocorre uma necessidade de interfaces
com melhor utilizao. Estamos cada vez mais dependentes da tecnologia e, consequente-
mente, mais exigentes com a qualidade dela. Ns no queremos perder tempo quando os
recursos de tecnologia so usados. justamente no estudo da relao homem X mquina,
que se encontra a Interao Humano-Computador (IHC).

05. O JQuery e outras bibliotecas semelhantes so fontes de recursos e facilidades que

permitem que um programador crie interfaces mais interativas com o usurio de uma manei-
ra mais produtiva e eficiente. Por meio de poucas linhas de cdigo em javascript, possvel
criar animaes e efeitos na tela que fazem com que o usurio tenha uma experincia mais
agradvel ao usar os softwares.

126 captulo 5
06. O Windows teve vrias verses: 1.0, 2.0, 3.0, 3.11, Windows NT, 95, 98, 98 Millenium
Edition, Vista, 7, 8, 8.1 e atualmente o Windows 10. Com relao interface, podemos dizer
que ela acompanhou a tecnologia que estava disponvel na poca de cada verso. A primeira
verso, em 1985, j usava mouse e dispunha de cores, porm as janelas no podiam ser
sobrepostas, o que veio a acontecer em 87 na verso 2.0. Nesta verso ocorreu a possibili-
dade de minimizar e maximizar as janelas. Na verso 3, bastante popular, a palavra Windows
comeou a fazer mais sentido, pois as janelas se tornaram mais independentes, inclusive os
programas DOS podiam ser executados dentro de uma janela especfica. Nesta verso era
possvel usar o som e cd-rom. Na verso 3.1, apareceram as fontes true-type, as quais permi-
tiram que o Windows tornasse uma plataforma para editorao eletrnica. No Windows 95,
a barra Iniciar e a barra de ferramentas apareceram, alm de ter o recurso plug and play. Na
verso 98, os botes de avanar e voltar no Internet Explorer apareceram. No Windows XP, a
principal diferena na sua interface foi sua grande melhoria em relao verso anterior. No
Vista, a interface ficou mais bonita e agradvel e tinha os recursos de transparncia e gad-
gets na rea de trabalho. O Windows 7 trouxe poucas mudanas visuais em relao ao Vista.
O Windows 8 foi uma tentativa radical de mudana na interface e suportava as telas sensveis
ao toque e eliminou, assim, o boto iniciar, o que foi bastante criticado. Nesta verso apare-
ceram os tiles. A verso 8.1 foi uma resposta s crticas visuais recebidas na verso anterior.

Captulo2

01. Sim, pois, com a popularizao dos smartphones e tablets, a exigncia por maior usabi-
lidade e interao tem ficado cada vez maior, fazendo com que os critrios sejam usados e
disponveis para todas as plataformas.

02. Quando vamos instalar algum software no Windows, geralmente existe um assistente
que mostra informaes ao usurio sobre a instalao. O usurio tem vrias opes de con-
figuraes e possibilidades de avanar e voltar suas aes.

03. Os termos esto muito relacionados. O agrupamento/distino por itens faz parte de
um critrio ergonmico chamado conduo, que tem como objetivo auxiliar o usurio na
execuo das tarefas, conduzindo-o na interao com o sistema. Por meio do agrupamento
por itens, que atua na disposio espacial dos itens na tela, o usurio tem a sensao e o
conforto de visualizar os itens agrupados e entender como o sistema pode ser compreendido
e usado.

captulo 5 127
04. Um software que segue as normas sobre IHC tem muitas vantagens em relao a ou-
tras que no se preocupam com isso, porque, de certa forma, h uma garantia de que ele foi
desenvolvido pensando na melhor interao e usabilidade do usurio. Sendo assim, seu uso
e compreenso ser mais garantido do que outros que no se preocupam com isso. Quando
um software no tem boa interao com o usurio, o risco de ele no ser usado ou ser mal
aproveitado muito grande.

05. A metfora de interao um conjunto de regras e tcnicas que tm como objetivo fazer
uma comparao entre o mundo real e a interao com um computador. Por exemplo: no
mundo real, temos alavancas que aumentam ou diminuem algum tipo de nvel (ou acelerao
em um avio por exemplo) nas interfaces temos os sliders, muito comuns em aplicativos
grficos.

06. Outro exemplo: em alguns videogames existem plataformas que o jogador usa para
danar ou fazer movimentos que so representados no jogo.
Outro exemplo: o jogo Guitar Hero pode ser jogado com um joystick normal de um vdeo
game ou ser jogado com um controle especial que imita uma guitarra.

Captulo3

01. O maior stakeholder de um sistema de caixa para um supermercado o prprio gerente

do supermercado. De outra forma, o gerente financeiro tambm um stakeholder do sistema.

02. Como foi visto no texto, os seguintes tpicos so os principais no design centrado
no usurio:
a) Foco em usurios e tarefas;
b) Teste de uso do produto e medidas empricas;
c) Design interativo.

03. Veja UM exemplo neste link: http://www.storyboardthat.com/userboards/markpra-

veenk/hotel-room-reservation2
Existem vrios na internet.

04. Porque o usurio pode no querer esperar at o final do desenvolvimento do produto e

achar que o prottipo j suficiente para as suas necessidades.

128 captulo 5
05. O Bootstrap um framework escrito em Javascript muito usado atualmente e utili-
zado principalmente para o desenvolvimento de sites responsivos e aplicativos mveis pela
web. A inteno tornar o desenvolvimento front-end mais rpido e fcil. O Bootstrap tem
o cdigo aberto, o que permite ao programador estender suas funcionalidades e criar no-
vas bibliotecas.

Captulo4

01. Sugestes para o ipod:

a) Facilidade de uso
b) Acesso s msicas
c) Acesso s configuraes
d) Conexo com outros dispositivos

Sugestes para o site de vendas

a) Visualizao do carrinho de compras
b) Visualizao dos detalhes dos produtos
c) Comparao de produtos
d) Rastreamento do pedido
e) Busca de produtos eficiente

02. Respostas:
a) Sem dvida, as heursticas ajudam a avaliar qualquer site com base nos critrios
que elas propem.
b) Sim, uma vez entendida as heursticas, o usurio passar a examinar e avaliar o site
de uma maneira mais crtica, para encontrar elementos que esto de acordo com
as heursticas.

03. Vamos avaliar o site http://pt.aliexpress.com/br_home.htm

a) Apesar de ter muitas opes para o usurio, o excesso de informao pode confun-
dir ou mesmo dificultar a localizao de uma determinada opo.
Apesar de ser um site de compras, pode ser difcil de encontrar um determinado produto
devido grande quantidade de opes presentes na tela inicial.
Alguns produtos so traduzidos literalmente do idioma original, o que pode dificultar a
pesquisa de produtos.

captulo 5 129
 b) Sim. De posse dos conhecimentos das heursticas, a pr-avaliao de um site ser
feita usando as heursticas, at mesmo de uma maneira inconsciente.
c) Usar menos heursticas ter como consequncia uma avaliao mais malevel e
pode deixar o site mais propcio a no conformidades de interface, de acordo com
os padres e heursticas estudados. As heursticas devem ser usadas e combinadas
de acordo com o que ser avaliado e trazer o melhor resultado e avaliao para
o usurio.

04. A descrio abaixo do boto de ferramenta chamada de Hint ou Dica. Estas dicas
ajudam o usurio a guardar a funo daquele boto ou ferramenta; sendo assim, ele acaba
se acostumando com as funes e as localiza de maneira mais rpida.

Captulo5

01. Tecnologia assistiva um termo que engloba vrios conceitos, como produtos, recursos,
metodologias, estratgias, prticas e servios que tm como objetivo promover a funcionali-
dade , relacionada atividade e participao de pessoas com deficincia, incapacidades ou
com mobilidade reduzida, a fim de torn-las autnomas, independentes, com melhor qualida-
de de vida e includas socialmente.

02. A Web Acessibility Iniciative (WAI), uma diviso do W3C (World Wide Web Consortium)
responsvel por criar guias, estratgias e recursos para tornar a web acessvel para pessoas
com deficincia.

03. O W3C uma entidade que cria padres para o desenvolvimento de websites e tem
como objetivo conduzir a web para que atinja todo o seu potencial, desenvolvendo protocolos
e diretrizes que garantam o seu crescimento de longo prazo. Sem o W3C, as questes relati-
vas acessibilidade no so pensadas no desenvolvimento de sites, e assim vrias pessoas
que possuem deficincias e incapacidades ficariam excludas do acesso e uso da web.

04. So encontradas as seguintes caractersticas:

a) Aumento e diminuio do tamanho da fonte;
b) Navegao pelo teclado;
c) H uma descrio da estrutura do site;
d) Impresso somente do contedo das pginas;
e) Uso do atributo alt nas imagens.

130 captulo 5
 f) Design adaptado para diferentes resolues de tela;
g) Uso de vrios navegadores para o acesso.

05. No. O site www.acessibilidadelega.com um exemplo. Possui um design clean, limpo

e agradvel.

captulo 5 131
 ANOTAES

132 captulo 5
ANOTAES

captulo 5 133
 ANOTAES

134 captulo 5
ANOTAES

captulo 5 135
 ANOTAES

136 captulo 5