LIVRO PROPRIETÁRIO - ENGENHARIA DE USABILIDADE E INTERFACES

LIVRO PROPRIETÁRIO - ENGENHARIA DE USABILIDADE E INTERFACES

2. autor
FABIANO GONÇALVES DOS SANTOS
1ª edição
SESES
rio de janeiro  2016
ENGENHARIA
DE USABILIDADE

3. Conselho editorial  regiane burger; roberto paes; gladis linhares; karen bortoloti;
helcimara affonso de souza
Autor do original  fabiano gonçalves
Projeto editorial  roberto paes
Coordenação de produção  gladis linhares
Coordenação de produção EaD  karen fernanda bortoloti
Projeto gráfico  paulo vitor bastos
Diagramação  bfs media
Revisão linguística  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 (eletrônico ou mecânico, incluindo fotocópia e gravação) ou arquivada em
qualquer sistema ou banco de dados sem permissão escrita da Editora. Copyright seses, 2016.
Dados Internacionais de Catalogação na Publicação (cip)
G635e Gonçalves, Fabiano
Engenharia de usabilidade / Fabiano Gonçalves
Rio de Janeiro : SESES, 2016.
136 p. : il.
isbn: 978-85-5548-234-2
1. Interface homem-máquina. 2. Interface humano-computador.
3. Usabilidade. I. SESES. II. Estácio.
cdd 004.6
Diretoria de Ensino — Fábrica de Conhecimento
Rua do Bispo, 83, bloco F, Campus João Uchôa
Rio Comprido — Rio de Janeiro — rj — cep 20261-063

4. Sumário
Prefácio 7
1. Conceituação 9
1.1 Ergonomia
 11
1.1.1  Ergonomia física e cognitiva 12
1.2 Usabilidade e Engenharia de Usabilidade 16
1.3 Interação Humano-Computador 21
1.3.1  A primeira geração (ENIAC) 23
1.3.2  Segunda geração (IBM 7030) 24
1.3.3  Terceira Geração (IBM 360) 25
1.3.4  Quarta Geração 26
1.4 Interfaces e o projeto de interação 28
1.4.1  Futuro da IHC 31
2. Conhecimento 35
2.1 Princípios Ergonômicos para IHC 37
2.2 Critérios Ergonômicos 37
2.2.1 Condução 38
2.2.2  A carga de trabalho 39
2.2.3  O controle explícito 40
2.2.4  Adaptabilidade 40
2.2.5  A gestão de erros 41
2.2.6  A homogeneidade/Consistência (coerência) 41
2.2.7  O significado dos códigos e denominações 42
2.2.8  A compatibilidade 42
2.3 Recomendações Ergonômicas para IHC 43
2.3.1  Objetos de interação 44
2.3.1.1  Painéis de controle 46
2.3.1.2  Controles complexos 49
2.3.2  Atributos de objetos de interação 52

5. 3. Desenvolvimento 55
3.1 Introdução ao projeto de IHC 57
3.2 Um modelo de ciclo de vida simples para o projeto de IHC 60
3.3 Sobre os usuários 61
3.4 Técnicas de concepção 63
3.4.1 Brainstorming 63
3.4.2 CardSorting 64
3.4.3  Diagrama de afinidade 66
3.4.4 Storyboard 67
3.4.5  Maquetes – protótipos em papel 68
3.4.6  Prototipagem rápida 69
3.4.7  Prototipagem de baixa e alta fidelidade 70
3.5 Técnicas de modelagem de interface 71
3.5.1  The Bridge 72
3.5.2  Usercentered design 72
3.6 Considerações finais 76
4. Avaliação 79
4.1 Introdução 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 Técnicas de Avaliação de Usabilidade 85
4.6.1  Técnicas prospectivas 85
4.6.2  Técnicas preditivas 86
4.6.2.1  Avaliação Heurística 86
4.6.2.2  Inspeção por meio de lista de verificação 91
4.6.3  Técnicas objetivas 95
4.6.3.1  Ensaio de Interação 95

6. 5. Acessibilidade à Web 103
5.1 Introdução à acessibilidade 105
5.2 Acessibilidade na web e sua importância 108
5.3 A Web acessível 110
5.4 Componentes essenciais para acessibilidade na Web 111
5.4.1  Interdependência entre componentes 114
5.4.2  O ciclo de implementação 115
5.5 Projeto e desenvolvimento de um site acessível 117
5.5.1  Recomendações do W3C 118
5.5.1.1  Princípio 1 - Percepção 119
5.5.1.2  Princípio 2: Operável 119
5.5.1.3  Princípio 3: Entendível 120
5.5.1.4  Princípio 4: Robusto 120
5.5.2  Métodos e validadores de acessibilidade na web 121

8. 7
Prefácio
Prezados(as) alunos(as),
Desenvolver sistemas é uma tarefa muito interessante e, se bem aproveita-
da, pode te dar um retorno financeiro bem interessante. Porém não basta con-
seguir analisar um problema e saber solucioná-lo usando uma linguagem de
programação. Isto é importante, porém 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, além do framework
passa na cabeça deles que existem detalhes importantes a respeito de algo além
de um programa bonito?
Um dos detalhes é a questão da usabilidade. É importante que ao criar a
parte que interage com o usuário, alguns detalhes sejam observados, como a
questão da acessibilidade.
Esta disciplina tem como objetivo introduzir você em um tópico no qual
muitos desenvolvedores não pensam ou ao qual não dão importância, que é a
questão da usabilidade. Como foi citado, não basta saber um bom framework;
é necessário saber aplicá-lo corretamente. Esta disciplina envolve conhecimen-
tos de diversas áreas, como: psicologia, sociologia, antropologia, sistemas de
informação, ciência da computação, design gráfico e ergonomia. Porém, não
vamos entrar a fundo em cada uma dessas áreas. O que é importante você saber
é que desenvolver interfaces não é apenas uma questão de saber programação e
um determinado framework de apresentação. Vai um pouco mais além.
Nosso objetivo é despertar sua atenção para este conhecimento e colocá-lo
em contato com algumas questões básicas destas áreas mencionadas. É inte-
ressante e, se você se dedicar, saiba em que é uma área que há grande demanda
de bons profissionais.
Bons estudos!

10. Conceituação
1

11. 10 •
capítulo 1
Neste capítulo vamos tratar de um assunto que é encontrado em várias áreas,
comArquitetura, Engenharia de Produção, Engenharia de Segurança e Tecno-
logia da Informação: a ergonomia.
A ergonomia trata basicamente da adequação das pessoas aos locais de tra-
balho e outros tipos de sistemas (não necessariamente computacionais).
Além disso, vamos estudar uma introdução à usabilidade e à engenharia de
usabilidade. A usabilidade é uma área da computação relacionada com outra
grande área chamada Interação (ou Interface) Homem-Máquina (IHM). A IHM
sempre foi um motivo de grande discussão, porque a tecnologia, evoluindo ao
longo dos anos, proporcionou uma grande evolução nas interfaces que ligam
os humanos ao computador e às máquinas em geral. A IHM, por sua vez, é uma
área estudada pela Engenharia de Software, que é uma disciplina que também
será vista no curso.
A usabilidade tem ganhado muito destaque no desenvolvimento de siste-
mas, principalmente no desenvolvimento web. Atualmente, vários frameworks
têm aparecido e ajudado os desenvolvedores a criarem sites mais interativos e
intuitivos, e isso tem um grande relacionamento com usabilidade.
OBJETIVOS
Ao final deste capítulo, você estará apto a:
• Entender e reconhecer questões relacionadas à ergonomia em geral;
• Saber os conceitos básicos de usabilidade e engenharia de usabilidade;
• Conhecer os principais conceitos da área de interface homem-máquina.

12. capítulo 1 • 11
1.1 Ergonomia

A ergonomia pode ser definida como “adaptação ou melhoria na adequação
dos produtos aos indivíduos”. Ela existe desde a Pré-História quando o homem
primitivo sentiu a necessidade de criar objetos e utensílios que o ajudassem
a realizar as mais diversas tarefas, como armazenar água, cozinhar alimentos,
fazer roupas para se proteger do frio e caçar (figura 1.1).

©©HBCS0084 | DREAMSTIME.COM
Figura 1.1  – Primórdios da Ergonomia.
Com a evolução do homem também veio a evolução 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 conotação realmente
relevante na Segunda Guerra Mundial, quando aviões, tanques de guerra e ar-
mas precisavam ser produzidos rapidamente. Entretanto, esses equipamentos
foram produzidos sem a preocupação de adequação às características percepti-
vas e físicas dos usuários, o que levou a diversas mortes de soldados.
É evidente que a perda de vidas implica em sérios problemas; dessa forma,
houve um esforço conjunto de especialistas de diversas áreas para adaptar os
equipamentos, a fim de desenvolver projetos que adaptassem sua interface
de uso (alavanca, botões, pedais e painéis) e campo de visão a soldados que

13. 12 •
capítulo 1
deveriam utilizá-los em situações extremas, quando sua maior preocupação
deveria ser o combate, e não a forma de uso das armas e equipamentos.
Após a Segunda Guerra Mundial a ergonomia ganhou grande avanço por
meio da NASA e seu impressionante avanço tecnológico, atingindo os mais di-
versos setores das indústrias pela América do Norte e Europa.
Atualmente, a ergonomia é uma área extremamente multidisciplinar que
envolve desde engenheiros e físicos até médicos, fisioterapeutas e psicólogos
na tentativa de solucionar a necessidade do ser humano em aplicar menos es-
forço mental e físico em suas tarefas cotidianas. Assim, algumas premissas de-
vem ser “pretendidas" na criação de um sistema ergonômico:
• O usuário deve desempenhar somente as funções absolutamente essen-
ciais, e que não possam ser desempenhadas pelo sistema, transferindo para
o sistema uma função mesmo que ela possa ser desempenhada pelo usuário.
• O usuário deve ter de memorizar o mínimo possível.
• O usuário só deve ter de aprender o essencial para sua tarefa.
• O usuário não deve ter de aprender a terminologia, passos não relaciona-
dos à sua tarefa – instruções ou comunicações do sistema devem ser feitas ao
longo da tarefa.
• Os comandos do usuário devem ter execução natural e simples, não de-
vem ser complexos e compostos.
• O usuário deve ter frustração mínima.
1.1.1  Ergonomia física e cognitiva
Imagine que você está em uma sala de cinema e, após 10 minutos de o filme
ter começado, ocorre um problema, as luzes não se acendem e começa a soar
o alarme de incêndio. As pessoas ao seu redor se desesperam e você começa a
sentir o cheiro de fumaça. Você se mantém 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 à saída de emergência. Você sai em direção à 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 esfumaçada, sentindo um
grande alívio ao respirar ar fresco.

14. capítulo 1 • 13
O ponto-chave para que você pudes-
se se livrar desta situação foi a facilida-
de de achar e abrir a porta da saída de
emergência. Essas saídas foram proje-
tadas para que, em uma situação de pe-
rigo iminente, as pessoas possam ser
encaminhadas para a saída sem pen-
sar, de forma simples e instintiva, sim-
plesmente ao ver um painel com uma
luz vermelha. Da mesma forma, em
relação ao sistema de abertura da por-
ta, em uma situação de risco, a pessoa
não terá tempo ou estará tão apavora-
da que não conseguirá encontrar uma
maçaneta ou identificar uma forma de
abrir a porta. Sendo assim, a porta se
abre quando a pessoa empurra a barra,
o que é uma ação intuitiva, uma vez que
sua principal preocupação é fugir.
Aqui podemos notar elementos claros de ergonomia física e cognitiva: o fato
de a saída de emergência estar posicionada imediatamente ao lado da tela, faz
com que você não precise procurar muito por ela, uma vez que, durante a seção,
a sua atenção estará voltada para a tela; além disso, o fato de a barra horizontal
estar posicionada um pouco acima de sua cintura faz com que você não preci-
se fazer movimentos antinaturais, portanto abrir a portaserá o menor dos seus
problemas.
Temos então dois exemplos de ergonomia física que está relacionada a
adaptação de um sistema a anatomia humana, antropometria, fisiologia e bio-
mecânica. Ou seja, as ações a serem realizadas se aproximam ao máximo de
movimentos naturais aos seres humanos. Podemos notar também elementos
de ergonomia cognitiva, uma vez que a saída de emergência é indicada por uma
luz vermelha, enquanto todas as luzes estão apagadas, sendo assim bastante
visível, e também outro elemento é o fato de a porta se abrir quando a barra é
empurrada, o que é um movimento bastante natural, que não requer grande
carga de raciocínio. Nesse tipo de ergonomia, é levada em consideração a carga
©
©
EDITOR77 | DREAMSTIME.COM
Figura 1.2  – Saída de emergência com a
barra horizontal.

15. 14 •
capítulo 1
mental de uma determinada ação, na tentativa de diminuir raciocínio, estresse
e tomada de decisão.
Este é um exemplo no qual é possível mostrar que a ergonomia não está
relacionada apenas a equipamentos ou máquinas, uma vez que entendemos a
sala de cinema como um sistema, e as pessoas como usuários.
Existem outros exemplos mais diretos também , em que podemos notar ele-
mentos claros de ergonomia física e cognitiva. Por exemplo, a comparação entre
dois controles remotos: um tem um formato quadrado (com uma pegada ruim),
os botões são pequenos, seguindo o mesmo padrão, e os botões mais usados
estão longe um do outro, exigindo que você olhe para o controle para executar
qualquer ação; o outro é anatômico (seu formato encaixa na sua mão) os botões
são grandes e em formatos diferentes de forma que você não precise se preocu-
par em olhar para o controle para executar qualquer ação, você identifica qual
botão apertar apenas com o tato, são poucos botões, e o que diferencia a uma
ação realizada da outra, é a forma como esses botões são manipulados, apertan-
do, deslizando o dedo sobre o botão para um lado ou para o outro.

©©FRANCESCO ALESSI | DREAMSTIME.COM
Figura 1.3  – Controle remoto "ruim".

16. capítulo 1 • 15
©©PANYA CHITMEDHA | DREAMSTIME.COM
Figura 1.4  – Controle remoto "bom".
Podemos identificar também esses elementos na evolução do interior dos
carros. Antigamente os botões e as alavancas eram espalhados pelo painel do
carro e, muitas vezes, para executar uma ação, você precisava desviar a atenção
do trânsito para olhar para o painel e identificar o botão ou alavanca desejado.
Hoje em dia, nos carros mais modernos, grande parte dos controles do carro es-
tão no próprio volante, inclusive controle multimídia, ar-condicionado e trocas
de marchas, fazendo com que o condutor foque sua atenção no trânsito, não
precisando retirar as mãos do volante para quase nada.
E, finalmente, no mundo da informática, podemos comparar os touchpads
de diversos laptops com o touchpad desenvolvido pela Apple, que torna a expe-
riência de uso do computador muito mais simples e intuitiva, uma vez que são
adicionados elementos de percepção 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
ergonômicos, ou seja, que exijam o menor esforço físico e cognitivo do usuário,
evitando, frustrações, grande uso de raciocínio e memória do usuário.

17. 16 •
capítulo 1
1.2 Usabilidade e Engenharia de Usabilidade
Vamos supor outra situação: você está no escritório postergando o que precisa
fazer: o manual formatado do software recém-produzido que havia prometido
ao seu chefe há tempos, mas está tranquilo, pois o texto já está todo escrito e as
figuras já estão todas prontas, a única coisa que falta é a formatação do arquivo.
Já são duas horas da tarde, e, quando abre a caixa de e-mails, surpresa: uma
cobrança do chefe dizendo que precisa desse manual pronto até o fim do dia.
Você percebe que, se abrir mão do cafezinho das quatro horas, consegue
terminar a formatação do arquivo. Porém, quando abre o editor de texto, nota
que ele foi atualizado para a versão mais recente, com novas funcionalidades
e um layout completamente diferente, as ferramentas que você estava acostu-
mado a usar não estão mais onde sempre estiveram. Você procura, passa por
todos os menus, mas a interface está muito diferente, as horas vão passando e
após buscar por informações na internet, consegue encontrar algumas ferra-
mentas e avançar um pouco na formatação, mas já são 16:30 e pensa: “Como
uma empresa tão grande, não faz um interface mais fácil, mais intuitiva? Será
que ninguém 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, não era nem um pouco usual.
Mas, então, 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 também é utilizado em contexto de produtos, como apa-
relhos eletrônicos, em áreas da comunicação e produtos de transferência de
conhecimento, como manuais, documentos e ajudas online.
Podemos definir usabilidade como a facilidade com que as pessoas têm ao
manusear algum determinado objeto, de modo eficiente, intuitivo, sem provo-
car erros operacionais e oferecendo ainda satisfação aos usuários. Ou seja, po-
demos associar usabilidade à facilidade de uso. Se um produto é fácil de usar,
o usuário tem maior produtividade: aprende mais rápido, memoriza o passo a
passo das operações e erra menos.
Veja a figura 1.5: Preciso ir para o primeiro andar. Como faço? Que botão
eu aperto, o 0 ou o 2? Preciso ir por tentativa e erro? E o que seria o andar “-1”?

18. capítulo 1 • 17
Pode ser o subsolo? Mas e se houvesse mais andares abaixo do solo? Seria “-2”,
“-3”, etc? Isto não é um pouco estranho?
©©TATABRADA | DREAMSTIME.COM
Figura 1.5  – 
Uma boa usabilidade costuma andar de mãos dadas com um bom design!
Smartphones em geral tentam fazer com que a experiência de uso seja sim-
ples e fácil, uma vez que é necessária apenas a realização de movimentos na-
turais e intuitivos para a troca de páginas e seleção de operações e aplicativos.
©©DK88888 | DREAMSTIME.COM
Figura 1.6  – O Iphone da Apple.

19. 18 •
capítulo 1
Outro exemplo de usabilidade em produtos são controles remotos. O
Weemote é um controle remoto focado em atender às necessidades de crianças
e idosos com botões grandes e coloridos só com funções básicas. Nesse ponto
podemos fazer uma associação entre usabilidade e interação. Assim, fica claro
que a usabilidade não depende só das características do produto, mas também
das características do usuário, da tarefa e do ambiente ao qual todos esses fa-
tores estão incluídos, ou seja, a interface deve ser desenvolvida levando-se em
consideração a causa e a forma de contato entre usuário e produto.
Segundo (JORDAN, 1998), a usabilidade pode ser avaliada de acordo com
alguns princípios:
• Evidência: Devem ser evidentes o modo de operação e a função do produ-
to, como, por exemplo, maçanetas de portas de carros (figura 1.7):
©©MAKSYM GORPENYUK | DREAMSTIME.COM
Figura 1.7  – Maçaneta de carro.
• Consistência: Operações semelhantes devem ser resolvidas de formas
semelhantes. Um exemplo é a atualização do editor de texto que mantém as
ferramentas mais utilizadas em seus lugares, sem maiores alterações que con-
fundam o usuário.
• Capacidade: As capacidades do usuário para cada função não devem ser
ultrapassadas. Por exemplo, colocar os principais controles do carro no volan-
te, faz com que ele seja capaz de fazer mais operações sem desviar sua atenção
do trânsito.
• Compatibilidade: A experiência de uso deve ser compatível com as expe-
riências socioculturais dos usuários. Para desenroscar uma tampa, é preciso
girá-la no sentido anti-horário.

20. capítulo 1 • 19
• Prevenção de erros: Os produtos devem evitar ao máximo procedimen-
tos errados.
• Realimentação: O sistema deve dar um retorno ao usuário sobre o suces-
so de sua tarefa, para que ações repetitivas sejam evitadas.

Figura 1.8  – Retorno de uma ação do programa. Fonte: autor.
Mas, então, qual a diferença entre usabilidade e ergonomia, já que, em am-
bos os casos, vários dos mesmos exemplos podem ser utilizados?
Atualmente, a palavra ergonomia se refere à característica de um sistema ou
tarefa que se adapte ao usuário, e não o contrário. É uma área multidisciplinar
que compreende diversos ramos da ciência, como: anatomia, antropometria,
biomecânica fisiologia, psicologia etc. Baseia-se em conhecimentos adquiri-
dos, nas habilidades e capacidades humanas para adaptar as mais diversas,
atividades, ferramentas, máquinas e produtos, com o objetivo a torná-los mais
seguros, eficientes e confortáveis para uso humano.
Já a usabilidade, como mencionado anteriormente, é uma ramificação da
ergonomia, preocupa-se em produzir uma interface que deve ser usada para
se executar uma dada tarefa da forma mais simples possível, de modo a per-
mitir que os usuários foquem apenas no trabalho que eles desejam executar

21. 20 •
capítulo 1
(NORMAN, 1986). Segundo (ISO/IEC 9126), “usabilidade é a capacidade de
uma aplicação ser compreendida, aprendida e utilizada, sendo atraente para
o usuário, em condições específicas de utilização”. Isso significa que aquele
editor de textos do início deste tópico deveria, entre outras coisas, ter as seguin-
tes características:
APRENDIZAGEM
Quão fácil e quanto de treinamento os usuários precisam
para realizarem tarefas básicas no primeiro contato que
têm com a interface do sistema?
EFICIÊNCIA
Os usuários conseguem realizar as tarefas exigidas pelo sis-
tema, de forma eficiente, depois de quanto tempo de uso?
MEMORIZAÇÃO
O usuário deve lembrar-se de como usar o sistema depois
de um longo período sem utilizá-lo?
ROBUSTEZ
Caso erros aconteçam, a interface deve avisar o usuário e
permitir a correção de modo fácil, sem gerar frustrações.
SATISFAÇÃO
Quão agradável, confiável e satisfatória é a utilização do
sistema?
É importante salientar que, nas áreas de Interação Humano-computador e
na Ciência da Computação, muitas empresas têm consciência da importância
da usabilidade. Porém, 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 têm muito mais a perder ao minimizar a usabilidade dessa forma. De acor-
do com CYBYS, BETIOL e FAUST (2007):
Dependendo da frequência com que o software é empregado, os prejuízos para as
empresas podem também ser expressivos, não só em decorrência do absenteísmo e”

22. capítulo 1 • 21
da rotatividade do pessoal, mas também pela baixa produtividade, competitivi-
dade e menor retorno de investimento. Sistemas difíceis de usar implicam em
erros e perda de tempo, fatores que se multiplicam com a frequência das tare-
fas e o número de usuários. A perda de dados e informações pode implicar na
perda de clientes e de oportunidades. Acontecimentos deste tipo causam des-
de uma resistência ao uso do sistema até a sua subutilização e abandono com-
pleto, com o devido consentimento da empresa. O barato terá custado caro.
1.3 Interação Humano-Computador
Vamos usar outra situação cotidiana para exemplificar: imagine um senhor
que vai ao banco sacar o dinheiro de sua aposentadoria e sempre faz o mesmo
“ritual” todo mês, indo até o caixa. Mas desta vez há uma diferença: 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 eletrônico, afinal, não
poderia ser tão 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 eletrônico, olhou
para o lado e viu uma moça a toda pressa tocando no visor. Ele então toca no
visor também, quando uma mensagem aparece: “Insira seu cartão”. Ele pro-
cura e vê um lugar onde colocar o cartão, quando outra mensagem aparece:
“falha na identificação do cartão”. Ele imagina que colocou o cartão na posi-
ção errada, reposiciona e coloca novamente o cartão 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 biométri-
co”. Ele o faz prontamente, mas uma mensagem aparece: leitura não efetuada.
Repita a operação, ele olha para trás e a fila está aumentando, quando ele come-
ça a ficar preocupado, repete a operação e uma série de quadrados aparecem na
tela, com várias possibilidades, dentre elas o saque. Ele escolhe um quadrado
e vários outros quadrados aparecem: conta corrente, poupança, conta salário,
etc. Creio que você consegue imaginar o resto desta situação.

23. 22 •
capítulo 1
Situações como essas ocorrem o tempo todo. Muitas pessoas não sabem
como agir quando se deparam com uma máquina ou um sistema computacio-
nal. Por que essa interação é tão difícil?
Existe uma área na Computação que estuda a interação de forma a dei-
xá-la mas simples, objetiva e satisfatória, chamada de Interação Homem
Computador (IHC).
Essa necessidade surge no cotidiano com as mais diversas tarefas que en-
volvem máquinas que se utilizam de algum tipo de sistema computacional.
Esses sistemas na maioria das vezes são criados e desenvolvidos para facilitar
nossas vidas, mas em vários casos acabam atrapalhando, por não serem bem
planejados, projetados e pensados, daí a necessidade de toda uma ciência mul-
tidisciplinar, envolvendo ciência da computação, psicologia cognitiva, psicolo-
gia organizacional e social, ergonomia e fatores humanos, engenharia, design,
antropologia, sociologia, filosofia, linguística e inteligência artificial, por trás
desse assunto, que estuda como interagimos com os computadores nas mais
diversas situações, para tornar cada vez mais simples e natural a interação ho-
mem computador. Então uma definição para IHC seria: a interação Humano-
Computador (IHC) é uma disciplina que diz respeito ao design, avaliação e
implementação de sistemas de computação interativos para uso humano em
um contexto social e com os estudos dos principais fenômenos que os cercam
(Curricula for Human-Computer Interaction, 2009).
Porém, a interação entre humanos e computadores necessita de um meio de
comunicação que é chamado de interface, por meio da qual o usuário entra em
contato com a máquina de forma física, perceptiva e cognitiva (NORMAN, 1986)
A interface é o lugar onde ocorre contato entre duas partes. Toda forma de
interação onde uma ação do usuário (entrada) leva a uma resposta do sistema
(saída) é intermediada por uma interface. Podemos ter como exemplos, com-
putadores, maçaneta, televisões, rádios, micro-ondas, aparelhos de telefone
e etc.
A interface permite que um agente (humano) faça uma ação por meio de
uma interface (maçaneta) e tenha uma resposta do paciente (porta).
A interface do computador provoca estímulos ao usuário de forma que ele
manipule a interface por meio de dispositivos e tenha as respostas relaciona-
das à sua atividade de interesse. Para cada ação, uma nova resposta é esperada
por ambos os lados: sistema e usuário.

24. capítulo 1 • 23
Mas será que desde o surgimento dos computadores a interação homem
computador é a mesma?
É evidente que não. Desde seu surgimento computadores e interfaces evo-
luíram juntos até chegar ao que conhecemos e convivemos hoje, de uma inter-
face simples e rudimentar passando por apenas linhas de código, até chegar-
mos nas interfaces gráficas e intuitivas de hoje em dia.
Todos sabem que os computadores atuais são fruto de uma intensa evolução
tanto em termos de hardware quanto de software, mas o que poucos sabem é
que, na década de 1950 já existiam computadores. É certo que eles não se pare-
ciam nem um pouco com os computadores que conhecemos hoje, mas já eram
capazes de fazer alguns cálculos de forma bem rápida para determinadas tarefas.
1.3.1  A primeira geração (ENIAC)
©©WIKIPEDIA
Figura 1.9  – O ENIAC (https://en..org/wiki/ENIAC).
A interação com os primeiros computadores, os chamados ENIAC e UNIVAC, era
muito complexa, já que naquela época não existia linguagem de programação,

25. 24 •
capítulo 1
os computadores eram programados para resolver um problema em específi-
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, além de sofrerem com superaqueci-
mento pois, em vez de utilizarem microprocessadores, eles utilizavam válvulas.
Elas funcionavam de maneira parecida com uma placa de circuitos, sendo que
cada válvula acesa ou apagada representava uma instrução à máquina. Cada
um deles necessitava de cerca de 19 mil válvulas por ano, porque as válvulas
queimavam com poucas horas de uso e precisavam ser substituídas.
1.3.2  Segunda geração (IBM 7030)
©©WIKIPEDIA
Figura 1.10  – O IBM7030.
A segunda geração de computadores apresentou uma série de novidades e
avanços em relação à primeira geração. O IBM 7030 foi o modelo de maior su-
cesso dessa geração, sua programação foi bastante simplificada, uma vez que
utilizava a linguagens como Fortran e Cobol em vez de linguagens de máquina
como era usado no ENIAC.
Outros fatores também foram importantes para o sucesso do IBM 7030, ele
era muito menor que o ENIAC, pesava “apenas“ 890 kg o que realmente é pouco

26. capítulo 1 • 25
diante das 30 toneladas do ENIAC. Essa considerável diminuição no tamanho
só foi possível porque o IBM 7030 utilizava transistores em vez de válvulas, os
transistores eram bem menores em relação às válvulas e os computadores fica-
ram mais econômicos com relação ao gasto de energia e também em relação ao
custo das peças.
©©WIKIPEDIA
Figura 1.11  – Réplica do primeiro resistor.
1.3.3  Terceira Geração (IBM 360)
©©WIKIPEDIA
Figura 1.12  – O IBM 360.
No final da década de 1970, o emprego dos semicondutores fez com que os com-
putadores da terceira geração tivessem um aumento significativo na velocidade

27. 26 •
capítulo 1
e na eficiência. Nessa geração foram introduzidos teclados para digitação de
comandos e monitores para visualização de sistemas operacionais primitivos e
a possibilidade de fazer upgrades. Entretanto, os computadores dessa geração
ficaram maiores do que os da geração anterior. O IBM 360 (modelo de maior
expressão dessa geração), claramente pesava mais do que seus antecessores.
Nessa época, os computadores já começaram a ficar mais acessíveis.
1.3.4  Quarta Geração
Na década de 1970 foram lançados os primeiros computadores da forma como
conhecemos hoje, os microcomputadores. Esses computadores ficaram bem
menores (pesando cerca de 20 kg), e a redução foi possível graças ao uso de
componentes chamados microprocessadores. Com isso, os computadores fi-
caram muito mais acessíveis, tanto que era possível 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.

28. capítulo 1 • 27
Nessa mesma época, Steve Jobs e Steve Wozniak criaram o Apple I, que ti-
nha como objetivo ser um computador de fácil acesso para leigos e logo foi
substituído pelo Apple II. O grande diferencial introduzido nesses computa-
dores é que Jobs e Wozniak se basearam no BASIC para criar um sistema com
interface gráfica, incluindo editores de texto, planilhas eletrônicas e bancos de
dados. Isto contribuiu com a popularização dos computadores, saindo do meio
científico e atingindo a população em geral. Posteriormente, a Apple também
foi responsável pela adoção dos mouses, que tornou a experiência de interação
humano computador mais amigável ainda. Pouco tempo depois, a Microsoft
também lançou o seu sistema operacional gráfico, o Windows.
CONEXÃO
BASIC – Beginner’s All-purpose Instruction Code, ou código de instruções de uso geral para
iniciantes, é uma linguagem de programação 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.

29. 28 •
capítulo 1
©©WIKIPEDIA
Figura 1.15  – A primeira versão do MacOS.
Com isso nós temos um breve histórico da evolução dos computadores e da
forma de interação homem computador até chegarmos aos tempos de hoje. É
possível perceber que sempre hove preocupação para tornar a expereiencia de
interação mais agradável, principalmente quando hove a evolução da criação
de sistemas operacionais com interface gráfica.
1.4 Interfaces e o projeto de interação
A comunicação entre usuário e computador deve permitir o diálogo e ela
pode ocorrer de duas formas distintas: interface física ou interface virtual.
INTERFACE FÍSICA
É feita por meio de hardware e por meio físico,
empregando materiais como cabos, fios, placas,
ou dispositivos como mouses, teclado joystic,
scanners, caixas de som etc.

30. capítulo 1 • 29
INTERFACE VIRTUAL OU
LÓGICA
É feita por softwares meio cognitivo que faz uso
de aspectos léxicos (funcionais), sintáticos (es-
truturais) e semânticos (conteúdo). Um aspecto
importante das interfaces virtuais ou lógicas é o
uso de metáforas e modelos mentais, que podem
ser vistas nos principais sistemas operacionais uti-
lizados atualmente. Elas são analogias a elemen-
tos naturais de forma a representar as abstrações
contidas nos sistemas computacionais. A partir do
momento em que começaram a ser utilizados sis-
temas operacionais com interfaces gráficas, foram
feitos usos de metáforas, por um exemplo o desk-
top ou área de trabalho é uma analogia a uma
mesa onde são organizadas todas as tarefas, outra
analogia são as pastas, que representam onde são
guardados os documentos, também podemos no-
tar a lixeira, onde são descartados os documentos
e arquivos que não serão mais utilizados. Todos
esses são esforços para deixar a experiência de
uso o mais natural possível ao usuário.
Figura 1.16  – Exemplo de uma área de trabalho, bem lotada e não organizada.

31. 30 •
capítulo 1
A combinação de interfaces física e gráfica ou lógica em celulares exige um
projeto de interação que leve em conta uma relação compreensível entre o apli-
cativo do aparelho e seus botões e teclado. Em avaliações feitas por alunos da dis-
ciplina de TASI utilizando princípios de projeto, metas de usabilidade, heurísti-
cas, entre outros conceitos, foi possível 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 interação de humanos e computado-
res, falamos de congruência de interfaces, que nada mais é do que a combina-
ção de interfaces físicas e interfaces virtuais. Nesse sentido, é preciso entender
que a combinação entre ambos os elementos precisa ser efetiva, clara e consis-
tente, para que, por meio de dispositivos físicos, a interface gráfica reaja apre-
sentando repostas aos estímulos de acordo com as expectativas dos usuários.
Agora me diga, quem não fica louco de raiva quando o mouse para de funcio-
nar? Entretanto, alguns novos dispositivos já vêm eliminando alguns elemen-
tos de interação física, como é o caso de dispositivos touchscreen.
ATENÇÃO
Tanto interfaces físicas como virtuais devem levar em consideração as capacidades físicas
e culturais dos seres humanos, e aqui um ponto de extrema importância e a acessibilidade
desses sistemas, aos mais diferentes tipos de usuários que irão 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 usuário;
• Estudar a interface mais apropriada para entrada e saída de dados, que
seja apropriada às características do usuário.
• Oferecer funcionalidades complementares como forma de flexibilizar o
processo de interação.
Para o desenvolvimento de uma boa interface o que costuma ser chamado
de uma interface amigável, deve-se levar em consideração:
– Perfil do usuário (Para quem?)
– Dispositivos de interação (Como?)
– Tarefas (O que?/Quando?)

32. capítulo 1 • 31
Mas o que seria uma interface ideal? Amigável?
É o conceito de que a interface de um sistema deve produzir uma experiên-
cia prazerosa, de fácil manuseio e aprendizado. Deve-se tentar agregar ao má-
ximo características com as quais o usuário já esteja acostumado.
Outro ponto a ser evitado são interfaces carregadas com muita informação.
Ao contrário do que se possa imaginar, ao disponibilizar muita informação, a
interface pode ficar tão confusa que o usuário não consiga encontrar o que ele
está procurando.
O sistema deve ter componentes que incentivem o aprendizado autôno-
mo, ou seja, interfaces amigáveis devem ser invisíveis, de forma que o usuá-
rio somente se preocupe com a tarefa a ser realizada Ela não pode tomar mais
atenção do usuário do que a própria tarefa e deve ser fácil de usar, aprender
e memorizar.
1.4.1  Futuro da IHC
É claro que nós ainda não alcançamos os níveis propostos pela ficção científi-
ca, mas podemos dizer que estamos caminhando, mesmo que lentamente para
um novo paradigma na construção de softwares que trabalham segundo uma
nova e diferente perspectiva de interface, uma evolução substancial já foi expe-
rimentada com a popularização de dispositivos touchscreen, como celulares e
tablets, tecnologia que também já atingiu os computadores. Essa mudança de
paradigma mudou drasticamente os tipos de interação, alterando também os
níveis de abstração e os tipos de metáforas utilizadas nos softwares e aplicati-
vos desenvolvidos.
Os movimentos realizados em dispositivos touchscreen (movimentos de
pinça) são mais naturais do que os realizados em desktops com o uso de mou-
ses. Também podemos citar o kinect desenvolvido pela Microsoft que, com cer-
teza, entrega uma experiência completamente nova, se levarmos em considera-
ção o que foi produzido até hoje.
Uma tecnologia que não se popularizou ainda, e é uma quebra de paradig-
ma, é o recém-desenvolvido Google Glass, que permite uma experiência com-
pletamente diferente do que estamos acostumados.

33. 32 •
capítulo 1
©©FALLOSTUPIDO | DREAMSTIME.COM
Figura 1.17  – O Google Glass.
Ou seja, essa área ou ciência de interação humano computador ou humano
máquina é bastante dinâmica e com certeza muitos paradigmas ainda serão
quebrados, mas os profissionais devem estar preparados para as novas tendên-
cias do mercado e, mais do que isso, devem estare preparados para inovar e
ditar as novas tendências 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. Alguém se habilita?
ATIVIDADES
01. Faça uma pesquisa na internet e procure o termo “tecnologia vestível”. O que é isso?
02. O que é engenharia de usabilidade?
03. O que fala a norma técnica ISO/IEC 9126 a respeito de usabilidade?
04. Por que a área de interface humano computador é tão importante?

34. capítulo 1 • 33
05. Faça uma pesquisa e explique como o JQuery e outras bibliotecas colaboram para as
interfaces atualmente.
06. Faça outra pesquisa na internet e descreva resumidamente o que melhorou nas interfa-
ces do Microsoft Windows, desde sua primeira versão até a versão 10.
REFLEXÃO
A área de interface e de usabilidade realmente precisa ser levada a sério, e que bom que as
empresas e a academia estão se preocupando com isso. Porém, é uma área multidisciplinar
o pessoal da área de TI tem de entender que, sem profissionais com formação em design e
comunicação, um novo sistema operacional, um site, ou qualquer outra forma de interação
entre o computador e o homem, não serão adequadamente desenvolvidos. E vice-versa: o
pessoal de design precisa da turma da TI para poder colocar em prática as ideias e conceitos
que eles estão desenvolvendo. Pensando assim, grandes sites e sistemas operacionais foram
desenvolvidos e fazem sucesso até hoje.
LEITURA
Sugerimos os seguintes sites como recomendação e forma de aprimorar o que foi visto
neste capítulo:
O JQuery é uma biblioteca que proporcionou grandes avanços na área de interatividade
na internet. Acesse o site do JQuery para ver o que é possível 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 contém os
padrões que são usados na web para o desenvolvimento de sites e aplicações. Este site
deve ser visitado e estudado por todos aqueles que desenvolvem para a internet: http://
www.w3.org/standards/

35. 34 •
capítulo 1
REFERÊNCIAS BIBLIOGRÁFICAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. 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. São 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.

36. Conhecimento
2

37. 36 •
capítulo 2
Toda vez que alguém precisa usar um programa novo, é aquela mesma história:
Como faço isso? Como altero aquilo? Por que fazer um programa tão difícil?
Será que ninguém pensa que o usuário não 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 específicos – aqueles que não atingem o grande pú-
blico e que não são fabricados pelas gigantes do mercado – não é construída
tendo uma grande preocupação com usabilidade. Para tal, é demandada uma
intensa participação dos usuários, no processo de definição da interface, na
realização de diversos testes e avaliações. Estes passos, além de aumentarem o
prazo de construção do software, aumentam também o seu custo. Mas será que
não existe um conjunto de regras e critérios para a construção de um programa
ergonômico?
OBJETIVOS
Este capítulo tratará dos princípios ergonômicos para IHC e fará com que você possa res-
ponder à seguinte pergunta:
• O que precisa ser feito para que um software seja minimamente agradável e utilizável?

38. capítulo 2 • 37
2.1 Princípios Ergonômicos para IHC
Assim como o conceito de ergonomia visto na unidade 1, em que se mostrou
que os produtos são planejados para atender às necessidades físicas, psicomo-
toras e cognitivas do ser humano, pode-se observar também a necessidade de
construção de softwares ergonômicos que facilitem a vida das pessoas.
A ergonomia em IHC tem como objetivo não só facilitar a vida do usuário, mas
também adaptar os softwares e a forma de interação às capacidades dos usuários,
dando conforto e satisfação. Hoje em dia é quase impossível uma empresa se es-
tabelecer no mercado sem se preocupar com esses temas. Assim, a importância
dessas características sobre como as mais diversas ferramentas serão usadas é
clara. Portanto, foram desenvolvidas diversas técnicas utilizando-se as teorias
existentes para desenvolver parâmetros para gerar softwares ergonômicos.
2.2 Critérios Ergonômicos
Os critérios ergonômicos são parâmetros a serem seguidos que podem tornar
a experiência de uso mais agradável e eficiente. Em 1993, Dominique Scapin e
Christian Bastien propuseram um conjunto de critérios que tem como objetivo
minimizar problemas na interação do usuários com o software baseados em
dados de aplicação musical.
Dois grupos de especialistas avaliaram a interface de uma base de dados
de aplicação musical. Após a exploração da interface, as ações e os comentá-
rios dos avaliadores foram registrados junto ao estado corrente da aplicação.
Posteriormente, uma segunda avaliação foi realizada. Em um grupo a avalia-
ção foi realizada em uma interface utilizando critérios ergonômicos, e o outro
grupo fez a avaliação sem critérios ergonômicos. Os resultados preliminares
mostram que na primeira fase, ambos os grupos apresentaram problemas de
usabilidade realizando avaliações semelhantes. Já na segunda fase a utilização
de critérios ergonômicos fez com que os avaliadores encontrassem um numero
maior de problemas do que o grupo que avaliou a interface sem levar os cri-
térios ergonômicos em consideração. Sendo assim, ficou clara a utilidade dos
critérios ergonômicos na identificação de falhas no projeto. A utilização desses
critérios leva ao aumento da integridade do sistema e à diminuição do número
de especialistas necessários para identificar possíveis falhas. São no total oito
critérios que serão descritos a seguir:

39. 38 •
capítulo 2
2.2.1  Condução
A condução tem como objetivo auxiliar usuários novatos a utilizar o sistema.
A interface deve conduzir o usuário na realização das mais diversas tarefas, no
sentido de aconselhar e informar o usuário na interação com o sistema. Quan-
do o usuário é bem conduzido, pode ser observada uma diminuição significati-
va no número de erros cometidos, uma vez que o aprendizado é facilitado.
Presteza: Permite que o usuário identifique em qual estado de interação ele
se encontra, ferramentas de ajuda e o seu modo de acesso. Uma boa presteza
facilita a navegação no software, diminuindo o erro, como por exemplo:
• Dirigir a entrada de dados indicando o formato adequado e os valo-
res aceitáveis.
• Exibir as unidades de medidas dos dados a digitar.
• Indicar todas as informações sobre estado.
• Para cada campo de dados, fornecer um rótulo.
• Indicar o tamanho do campo quando ele é limitado.
• Quando necessário, fornecer no rótulo informações suplementares.
• Dar um título a cada janela.
• Fornecer ajuda on-line e orientação.
Agrupamentos e distinção entre os itens:
Este item diz respeito à distribuição espacial dos itens na tela. Com isso é possí-
vel que o usuário faça uma rápida compreensão da tela, para identificar os itens
de seu interesse. O critério de distribuição e distinção dos itens se divide em dois:
AGRUPAMENTO E
DISTINÇÃO POR
LOCALIZAÇÃO
Permite ao usuário identificar semelhanças ou di-
ferenças nos itens segundo o padrão de organiza-
ção espacial deles na tela, por exemplo: itens com
conteúdos parecidos estão mais próximos.
• Organizar os itens em listas hierárquicas.
• Organizar as opções de um diálogo por menus,
em função dos objetos aos quais elas se aplicam.

40. capítulo 2 • 39
AGRUPAMENTO E
DISTINÇÃO POR
FORMATO
Permite ao usuário identificar semelhanças ou
diferenças entre diferentes classes de itens de
acordo com características gráficas.
Clareza: Refere-se as características que podem
auxiliar ou atrapalhar na leitura das informações
textuais. Recomenda-se levar em considera-
ção características cognitivas e perceptivas
dos usuários.
Feedback imediato: refere-se às respostas do
computador referentes às ações dos usuários. O
computador deve responder a todas as ações dos
usuários o mais rapidamente possível. Para os
usuários, ausência ou demora no feedback podem
ser consideradas como falhas no sistema.
2.2.2  A carga de trabalho
Este critério se preocupa em fazer com que o usuário diminua a carga cognitiva
e perceptiva, sendo subdividido em brevidade e densidade informacional.
BREVIDADE CONCISÃO AÇÕES MÍNIMAS
Este critério leva em
consideração o respeito
que se deve ter com as
capacidades cognitivas,
perceptivas e motoras
dos usuários.
Diminui a carga de traba-
lho, cognitiva e perceptiva
com relação às entradas
e saídas do software.
Apresenta títulos, rótulos,
denominações curtas.
Fornece o preenchimen-
to automático de vírgulas,
pontos decimais e zeros
à direita da vírgula nos
campos de dados.
Tenta facilitar ao máximo
a carga de trabalho do
usuário, simplificando e
minimizando as ações
necessárias para que
uma tarefa seja rea-
lizada. Presença de
atalhos, com imagens
representativas.

41. 40 •
capítulo 2
2.2.3  O controle explícito
Este critério se refere tanto ao controle que o usuário tem sobre a interface do
sistema quanto ao processamento e respostas dados pelo sistema ao usuário.
AÇÕES
EXPLÍCITAS
Se refere ao processamento e resposta dados pelo siste-
ma a uma ação executada pelo usuário por intermédio da
interface. Deve ficar explicito que o sistema só irá executar
estritamente o que foi solicitado pelo usuário.
CONTROLE DO
USUÁRIO
O usuário deve estar no controle, e o sistema deve
retornar estritamente o que lhe foi solicitado, entretanto
é interessante que o sistema se antecipe e o ofereça op-
ções que lhe auxiliem a executar determinadas ações, mas
sempre deixando o usuário no controle da situação.
2.2.4  Adaptabilidade
Não é possível uma interface atender às necessidades de todos os seus usuários.
Sendo assim, ela deve ser capaz de se adaptar segundo as preferências dos usuários.
FLEXIBILIDADE
Permite que uma tarefa possa ser realizada de diversas
formas, dando ao usuário a possibilidade de escolher a
estratégia com a qual mais se familiarize.
EXPERIÊNCIA DO
USUÁRIO
O sistema deve prever que existem usuários de diferentes
níveis (iniciantes e especialistas) e que esses usuários
têm necessidades diferentes. Muitos diálogos são ente-
diantes e maçantes para usuários experientes, ao passo
que a falta deles torna a experiência de uso inviável para
usuários iniciantes.

42. capítulo 2 • 41
2.2.5  A gestão de erros
Este critério se refere a todos os mecanismos disponíveis no sistema capa-
zes de reduzir a ocorrência de erros, e, caso eles ocorram, que a sua correção
seja facilitada.
PROTEÇÃO
CONTRA OS
ERROS
Refere-se aos mecanismos disponíveis para detectar e
prevenir os erros de entrada de dados.
QUALIDADE DAS
MENSAGENS
Refere-se à qualidade, clareza e legibilidade da mensagem
de erro apresentada ao usuário, qual foi o erro e o que
deveria ter sido feito para que esse erro não ocorresse ou o
que deve ser feito para corrigir o erro?
CORREÇÃO DE
ERROS
Quais são os recursos disponíveis para que o usuário possa
corrigir eventuais erros?
2.2.6  A homogeneidade/Consistência (coerência)
Neste critério, o objeto das interfaces são idênticos para contextos idênticos, e
diferentes para contextos diferentes.
• Localização similar dos títulos das janelas.
• Formatos de telas semelhantes.
• Procedimentos similares de acesso às opções dos menus.
• Na condução, sempre utilizar as mesmas pontuações e as mesmas cons-
truções de frases.
• Apresentar na mesma posição os convites (prompts) para as entradas de
dados ou de comandos.
Os formatos dos campos de entrada de dados devem ser sempre os mesmos.

43. 42 •
capítulo 2
2.2.7  O significado dos códigos e denominações
A significância dos códigos se refere à adequação expressão/objeto dos códigos
empregados na interface com o usuário.
Adequar o vocabulário de rótulos, títulos, cabeçalhos, mensagens, opções
de menu, bem como, definir figuras significativas para os ícones e abreviatu-
ras significativas.
2.2.8  A compatibilidade
A organização das saídas e entradas de uma dada aplicaçãodeve estar de
acordo com as características dos usuários (memória, percepção, hábitos, com-
petências, idade, expectativas, etc.) e da tarefa. Um método de avaliação com
base em critérios constitui uma abordagem analítica. Como tal, os critérios são
não se destinam a substituir outros métodos de avaliação (por exemplo, "basea-
da em modelo" métodos, questionário, entrevista, etc).
ATENÇÃO
A abordagem de utilização de critérios é um meio de garantir a conformidade com as diretri-
zes de design de software. Assim, pode ser usada antes do teste do usuário para descobrir
e corrigir eventuais falhas no projeto inicial. Entretanto, os critérios devem ser vistos como
um suplemento a outros métodos de avaliação, e são usadas somente abordagens analíticas
sem em nenhum momento contar com métodos de avaliação baseados em questionários,
entrevistas e etc.
PROJEÇÕES FUTURAS
– Estender o conteúdo de cada critério, aumentando os níveis de detalhamento,
incluindo um conjunto completo de "regras" específicas para cada um dos critérios.
– Definir um conjunto de prioridades para a avaliação para cada critério. Por exemplo:
Para usuários inexperientes, a orientação deve ser priorizada em relação à flexibilida-
de ou ao desempenho. O foco no desempenho deve ser adicionado aos poucos, de
acordo com a experiência do usuário.

44. capítulo 2 • 43
PROJEÇÕES FUTURAS
– Definir os pré-requisitos para a avaliação, ou seja, definir quais são todas as caracte-
rísticas necessárias aos usuários para aplicação de cada critério.
– Definir formas de avaliar sistematicamente os elementos e estados da interface
(telas, janelas, sequências de tarefas, etc.).
– Utilização de ferramentas de apoio para um completo sistema de avaliação (help).
2.3 Recomendações Ergonômicas para IHC
As recomendações ergonômicas representam a fonte de conhecimentos mais
utilizada pelos ergonomistas em suas intervenções.
A maior parte dos padrões para IHC têm orientações e recomenda-
ções ergonômicas que vêm sendo desenvolvidas pelos órgãos de norma-
lização, International Organização de Normalização (ISO) e Internetional
Electrotechnical Comission (IEC), ao longo dos últimos 20 anos.
Esses padrões são desenvolvidos por grupos de peritos ao longo de vários
anos. Nas fases iniciais, os documentos podem mudar significativamente de
uma versão para outra, até que um consenso seja atingido. A partir do momen-
to em que o padrão se torna mais ”maduro”, uma votação formal ocorre através
da participação de membros de órgãos de normalização.
Uma das funções das normas é impor consistência. 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
padrões definidos pela indústria foram mais influente do que as normas ISO.
Sendo assim, elas não foram amplamente adotadas. As normas podem ser:
• Oficiais, concebidas por organismos de padronização.
• Guias de estilo, concebidos por grandes companhias.
As normas tiveram maior impacto a partir da norma ISO 9241 e ficaram mais
centradas em atividades necessárias para produzir produtos utilizáveis a partir
da norma ergonômica ISO 13407. Estes princípios foram refinados e ampliados
em um modelo de boas práticas de usabilidade que pode ser utilizados para

45. 44 •
capítulo 2
avaliar a capacidade de uma organização em desenvolver um design centrado
no usuário com a norma ISO TR 18529. A norma ISO PAS 18152 estende esses
conceitos para a avaliação da maturidade de uma organização na execução dos
processos que fazem um sistema utilizável, saudável e seguro.
As normas relativas à usabilidade abordam principalmente temas como:
1. Eficácia, eficiência e satisfação na utilização do produto.
2. Interação do usuário com a interface.
3. O processo utilizado no desenvolvimento do produto.
4. Design centrado no usuário.
ATENÇÃO
Um ponto fraco da maioria dos padrões estabelecidos para IHC é que eles são discutidos
e desenvolvidos com base em teorias, e não em processos práticos, ou seja, as normas não
são desenvolvidas om base na resposta dos utilizadores ao interagirem com os sistemas
testando protótipos durante o desenvolvimento.
Outra limitação das normas internacionais é que o processo de desenvolvimento é lento,
e o conteúdo depende do esforço voluntário de especialistas apropriados.
2.3.1  Objetos de interação
Há algum tempo, na história dos computadores, a interação com os usuários
era extremamente difícil. Somente especialistas eram capazes de interagir com
o computador, enviando-lhe comandos e recebendo respostas. Não vamos aqui
traçar uma nova linha do tempo descrevendo novamente a história dos com-
putadores, mas acho que todos já tiveram a oportunidade de ver o que era a
famosa linha de comando.

46. capítulo 2 • 45
Figura 2.1  – O prompt do DOS no MS Windows.
Antigamente toda a interação era assim, escreviam-se comandos específi-
cos, que por vezes mais pareciam códigos, e esperavam-se as repostas na tela
em formato texto.
Contudo, desde o Apple 2, esse conceito foi modificado com o intermédio
da interface gráfica, onde são geradas imagens para interagir com os usuários,
que podem ser manipulados (aumentados, diminuídos, movimentadas), sen-
do organizados por uma estrutura de janelas, menus, barra de ferramentas
etc., utilizando metáforas do mundo real e linguagem natural para tornar a in-
teração dos usuários com o computador mais fluida e intuitiva.
Figura 2.2  – Pasta sendo usada como metáfora do mundo real.

47. 46 •
capítulo 2
Com a evolução da informática foram estabelecidos alguns elementos e ob-
jetos de interação entre usuário e computador que serão explorados a seguir.
2.3.1.1  Painéis de controle
Janelas
As janelas devem ter um layout padronizado para toda aplicação, geralmen-
te tem um título, em sua parte superior, centralizado ou à esquerda, tendo os
principais comandos à vista do usuário. Quando for possível abrir várias janelas
simultaneamente, a janela ativa deverá estar destacada.
Figura 2.3  – Figura 3: Uma janela simples.
Caixas de diálogo
As caixas de diálogo apoiam operações específicas, não contendo menus ou
barras de tarefas. E, assim como nas janelas, os títulos devem ser centralizados
ou deslocados para a esquerda, tendo botões que executem a ação referida ra-
pidamente, além do fechamento rápido da caixa de diálogo.

48. capítulo 2 • 47
• Caixas de diálogo modal: impedem o usuário de realizar qualquer
outro tipo de ação nos sistema, exigindo dele atenção exclusiva.
Figura 2.4  – Figura 4: Caixa de diálogo.
• Caixas de diálogo não modal: Não exige atenção exclusiva do usuá-
rio, permitindo que ele realize outras ações, enquanto a caixa de diálogo
fica em segundo plano.
Figura 2.5  – Figura 5: Caixa de diálogo.
Formulários:
Este tipo de caixa de diálogo está destinado especificamente à entrada de
dados. O layout deve ser autoexplicativo, agrupando de forma lógica e intuitiva
os diferentes tipos de dados. As ações de entrada devem iniciar-se pelo preen-
chimento do primeiro campo, no alto, à esquerda, que deverá estar com o foco
das ações quando da apresentação dele.

49. 48 •
capítulo 2
• Campos de preenchimento obrigatório devem ser diferenciados visual-
mente e, se possível, os campos que contenham dados críticos para o sistema
devem ser identificados e protegidos contra acidentes de operação. Mensagem
que advirta sobre os efeitos da ação e solicite a confirmação do usuário, deve ser
apresentada sempre que o campo for modificado.
Figura 2.6  – Um formulário para ambiente desktop.
Figura 2.7  – Um formulário para web.

50. capítulo 2 • 49
Caixas de Mensagens:
São utilizadas para informar o usuário sobre:
• O que fazer nas interações;
• Em que estado se encontra o sistema;
• A resposta do sistema a uma ação sua;
• Uma situação perigosa, de erro ou de anormalidade;
• Como recuperar a normalidade de um sistema.
Normalmente, essas mensagens são do tipo modal, ou seja, o usuário preci-
sa tomar conhecimento clicando em algum botão (Ok, por exemplo), para con-
tinuar usando o sistema. Quando a mensagem se destina a solicitar a confirma-
ção de uma ação destrutiva, a opção default deve recair sobre a anulação, e não
sobre a confirmação da ação. Caixas de mensagens envolvendo ações perigosas
(formatar disco rígido) devem ser destacadas pelo uso de cor vermelha, pelo
efeito de intermitência (pisca) ou ainda por um som.
Figura 2.8  – Caixa de mensagem.
2.3.1.2  Controles complexos
São objetos com estrutura complexa de navegação interna, que permitem a se-
leção de outros controles e comandos.

51. 50 •
capítulo 2
• Painel de menu
São menus dispostos verticalmente, uns abaixo dos outros.
Figura 2.9  – Menu do Windows 10.
• Barra de menu
Contém as opções do menu principal e leva às opções secundárias relacio-
nadas ao menu selecionado.
Figura 2.10  – Barra de menu.

52. capítulo 2 • 51
• Barra de ferramentas
Menu sem submenus, com opções em forma de ícones associadas a coman-
dos ou ferramentas.
Figura 2.11  – Barra de ferramentas.
• Lista de seleção
É uma lista de valores possíveis predefinidos pelos desenvolvedores, deve
ter de 5 a 9 itens de visualização imediata.
Figura 2.12  – Lista de seleção.

53. 52 •
capítulo 2
• Caixa de combinação (ou Combo Box)
Deve ser ordenada seguindo ordem alfabética numérica ou por ordem
de uso.
Figura 2.13  – Uma caixa de combinação
2.3.2  Atributos de objetos de interação
Os atributos de interação representam símbolos e sinais arbitrários com repre-
sentação concreta, ou seja, são os modificadores dos objetos de interação. Po-
demos exemplificar:
• Ícones
• Denominações
• Abreviaturas
• Cores
• Fontes
• Textura
• Vídeo Reverso
• Intermitência Visual (pisca-pisca)

54. capítulo 2 • 53
ATIVIDADES
01. Os critérios de software apresentados servem para qualquer tipo de plataforma digital?
Tablets, smartphones ...
02. Sobre o critério de controle do usuário. Dê um exemplo de auxílio ao usuário sem tirar o
seu poder de decisão.
03. Qual a relação entre o critério "Agrupamentos e distinção entre os itens” e o conceito
de ergonomia cognitiva?
04. Qual a importância de construir um software seguindo as normas sobre IHC? Qual o
benefício no resultado final?
05. Cite 3 exemplos de novas metáforas com o mundo real que poderiam ser utilizadas
como objetos de interação com o usuário.
REFLEXÃO
Construir um programa voltado para usabilidade levando em consideração critérios ergo-
nômicos não é uma tarefa fácil. Existe a necessidade de uma equipe multidisciplinar, alta-
mente treinada, e a paciência necessária para a interação e participação dos usuários nos
processos de determinação das interfaces do sistema. Apesar de encarecer o produto, a
utilização de elementos ergonômicos no software torna a experiência de uso mais agradável,
colocando o software alguns pontos acima no mercado. Logo essa será uma a exigência
do mercado e softwares que não forem construídos segundo princípios ergonômicos cairão
naturalmente em desuso.
Em contrapartida, novas ferramentas e plataformas vêm cada vez mais ganhando, com
novas propostas e novas formas de interação. Mas será que os princípios ergonômicos para
esses dispositivos devem ser diferentes, uma vez que a forma de interação é diferente? Essa
é uma área em grande ascensão, em que profissionais gabaritados estão em falta. A grande
pergunta que fica é: os critérios ergonômicos mudam conforme a forma de interação com o
dispositivo?

55. 54 •
capítulo 2
LEITURA
As normas podem ser adquiridas (compradas) diretamente da ISO ou por meio de outras or-
ganizações. Para um maior e completo entendimento sobre toda a abrangência das normas,
é recomendada vista ao site www.iso.org/iso/en.
Leia mais sobre os tipos de objetos de interação. No tutorial da linguagem Java existem
vários 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 série de
tutoriais da W3Schools. Este link é excelente:
http://www.w3schools.com/html/html_forms.asp
REFERÊNCIAS BIBLIOGRÁFICAS
BARBOSA, S.; SANTANA, B. Interação 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 interação. Porto Alegre : Bookman, 2013.

56. Desenvolvimento
3

57. 56 •
capítulo 3
Neste capítulo, vamos estudar a parte de desenvolvimento de interfaces ho-
mem-computador, ou IHC, também conhecida por interface homem-máquina
ou IHM.
Esta área é muito abrangente e tem vários desdobramentos, mas, neste ca-
pítulo vamos estudar alguns assuntos que compõem, de maneira geral, a parte
de desenvolvimento de IHC e em especial as técnicas de concepção e de mode-
lagem de interfaces.
A interface de um software é algo bastante determinante para o seu sucesso.
É muito difícil encontrar um software de sucesso cuja interface não esteja de
acordo com sua proposta ou agrade.
Até mesmo em jogos eletrônicos: existem alguns sucessos recentes que,
mesmo não tendo gráficos realísticos e sofisticados, tiveram uma grande acei-
tação pelo mercado, e a interface tem grande parcela de responsabilidade nis-
so. Como exemplo, veja o jogo “FlappyBird”, disponível originalmente para o
iphone. Feito em 2013, ele se destacou principalmente pela sua jogabilidade e
dificuldade. Outros jogos mais “pesados” se destacam pelos efeitos realísticos
de última geração, os quais são verdadeiras produções de Hollywood (literal-
mente, uma vez que alguns estúdios de jogos são em Los Angeles). Enfim, a
interface é um fator que determina o sucesso final de um software.
OBJETIVOS
Ao final deste capítulo, você estará apto a:
•  Entender o fluxo de desenvolvimento de interfaces gráficas, passando pelas técnicas de
concepção e de modelagem de interfaces.

58. capítulo 3 • 57
3.1 Introdução 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 concepção intelectual da experiência do usuário.
Cada usuário temsuas experiências e visões a respeito da forma como gostaria
que um determinado software fosse.
• A partir daí, o design passa a ser uma concretização desta concepção em
uma representação que pode ser implementada.
• A segunda é a parte “de IHC”:
• Neste caso, estamos falando da experiência do usuário, ou seja, como ele
vai interagir com o computador, e isto tem a ver com o projeto do software, po-
rém não é sinônimo de projeto de software.
Experiência do usuário ou também chamada de UsereXperience (UX), compreen-
de vários fatores sobre o que o usuário sente em relação ao uso de um determinado
produto, sistema ou serviço. A ISO 9421-210 define que a experiência do usuário são
“as percepções e reações de uma pessoa que resulta do uso ou utilização prevista de
um produto, sistema ou serviço”. Na prática, a experiência envolve todo o acúmulo de
preferências, respostas, sensações e comportamentos que o usuário 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 básicas como:
1. Identificação das necessidades e estabelecimento dos requisitos. Nesta
atividade, as necessidades dos usuários são levantadas e listadas a fim de serem
analisadas para poder ser contempladas futuramente na interface. Desta for-
ma, os requisitos são estabelecidos e documentados.
2. Desenvolver designs alternativos. Nesta atividade, a exploração de vá-
rios aspectos com relação ao visual e usabilidade do software podem ser inves-
tigados. Novos cenários de interação podem ser criados a fim de avaliá-los e
perceber o quanto contribuem com a experiência do usuário.
3. Construir versões interativas dos designs. Atualmente existem vários
softwares que ajudam nesta tarefa. Ter uma representação “usável” do software

59. 58 •
capítulo 3
é muito importante, porque também é uma forma de esclarecer os requisitos
para a interface.
Entre os softwares mais usados para este tipo de versão estão os softwares
do tipo wireframe, entre eles:

Figura 3.1  – BalsamiqMockup.
Figura 3.2  – Axure.

60. capítulo 3 • 59
Figura 3.3  – Microsoft Visio.
Alguns destes softwares têm versões para estudante e, embora sejam pagos
quando usados em empresas, são gratuitos para estudantes.
4. Avaliar o design. Uma vez que designs alternativos foram testados e mo-
delados em uma ferramenta de simulação como as apresentadas, as alterna-
tivas de design são avaliadas e classificadas por meio de critérios incluindo o
número de erros que os usuários cometem ao usar a alternativa avaliada. Além
disso, outros critérios como aparência, quantidade de requisitos satisfeitos e
outros também são usados.
Mesmo com estas atividades mostradas, qualquer processo de design de
IHC tem algumas características essenciais que devem ser prezadas durante
todo o processo:
1. O foco deve ser mantido sempre no usuário;
2. A experiência que se deseja que o usuário tenha deve ser clara e com os
objetivos bem definidos;
3. Deixar o processo iterativo.

61. 60 •
capítulo 3
3.2 Um modelo de ciclo de vida simples para
o projeto de IHC
Para deixar o processo iterativo, como vimos no final da seção anterior, RO-
GERS, SHARP e PREECE (2013) elaboraram um modelo de ciclo de vida para
representar o modo como as atividades estão relacionadas.
O uso de ciclos de vida é uma atividade bem característica da engenharia de
software, como o modelo em cascata, o modelo espiral e as aplicações de de-
senvolvimento rápido. A área de IHC, também 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
Prototipar
Design de
alternativas
Avaliar
Produto final

Figura 3.4  – Modelo simples de ciclo de vida de design de interação. Fonte: ROGERS,
SHARP, PREECE, 2013.
A figura 3.4 mostra um modelo simples de ciclo de vida de projeto de IHC.
Existem vários 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 vários desenvolvedores e muitos usuários, 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 usuário: o usuário é quem sabe o que é melhor e é o único
guia do projetista. O projetista implementa aquilo que o usuário propôs.

62. capítulo 3 • 61
• Design centrado na atividade: neste caso, as tarefas específicas é que são o
foco do projeto. O usuário 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 usuário define os objetivos do sistema.
• Design genial (genius design): neste caso, é mais informal e está baseado nas
experiências e preferências de um designer. O usuário, neste caso, valida as ideias do
designer.
O modelo apresentado na Figura 4 apresenta as quatro atividades do proje-
to e os três princípios de projeto centrado no usuário. Como já foi comentado,
dependendo do projeto, este modelo pode não 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 são os usuários?
• Quais são 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 usuários
Você deve ter percebido que tratamos várias vezes, neste texto, do sobre o quan-
to o usuário é importante em todo o processo da engenharia de usabilidade. E
não é para menos, ele é o principal elemento que vai absorver todos os concei-
tos que temos tratado aqui.
Mas, quem são os usuários? (Parece ser uma pergunta estranha, mas, antes
de continuar lendo, tente responder à pergunta).
Existem duas principais categorias de usuários:
• Os usuários são as pessoas que usam o sistema. Essa é a resposta mais
natural para a pergunta que foi feita.

63. 62 •
capítulo 3
• Mas também 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 usuários principais como sendo usuários também.
Existem também os usuários primários, secundários e terciários, os quais
devem ser levados em consideração:
USUÁRIOS
PRIMÁRIOS
São aqueles que usam o software com frequência.
USUÁRIOS
SECUNDÁRIOS
São aqueles que usam o software esporadicamente ou que
tem intermediários.
USUÁRIOS
TERCIÁRIOS
São aqueles afetados pela introdução do sistema ou os ge-
rentes que determinam a sua introdução. Também chamados
de stakeholders.
De qualquer forma, todos os tipos de usuários têm necessidades que devem
ser contempladas pelo projeto da IHC. A principal pergunta que é feita é “Do
que você precisa”? Esta pergunta é respondida pelo próprio usuário 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 orientação a objetos, disse uma vez que “a interface é o
programa”. Klay também é conhecido por conceber a arquitetura das atuais
GUI (GraphicsUser Interface – Interface gráfica de usuário).
O projeto de uma IHC não é um trabalho de uma equipe formada de pes-
soas da área de TI exclusivamente. É uma atividade multidisciplinar, que en-
volve informática, ergonomia, psicologia, linguística, design visual, entre ou-
tras. E tradicionalmente não faz parte da formação de profissionais da área
de informática.

64. capítulo 3 • 63
3.4 Técnicas de concepção
Neste tópico vamos apresentar algumas técnicas usadas para a implemen-
tação de especificações para a interface e usabilidade. Concepção significa
“geração” e este tópico vai tratar de algumas técnicas apontadas na literatura a
respeito de como gerar um projeto de interface homem máquina que seja efi-
ciente e adequado.
Dentre as técnicas que vamos apresentar estão:
• Brainstorming
• Cardsorting
• Diagrama de afinidade
• Storyboard
• Maquetes
• Prototipagem rápida
• Protótipos de baixa fidelidade
• Protótipos de alta fidelidade
3.4.1  Brainstorming
Esta técnica tem um nome que deriva de duas palavras da língua inglesa:
“Brain”, que significa cérebro, e “Storm” que significa tempestade. Logo,
“brainstorming” é uma palavra que pode ser traduzida como tempestade ce-
rebral, ou melhor, tempestade de ideias. Na língua “caipirês”, brainstorming
pode ser traduzido como “toró de parpites”.
Ela foi concebida em 1938 por Alex Osborn, que era presidente de uma
agência de propaganda. É uma técnica usada não apenas para a concepção
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 colaboração.
Brincadeiras à parte, o brainstorming é uma técnica muito interessante. Ela
é feita em grupo de no mínimo 2 (obviamente) pessoas e no máximo 12. O ob-
jetivo principal é criar e discutir as ideias surgidas em grupo, de forma partici-
pativa e colaborativa.
Esta técnica reúne várias pessoas para resolver um determinado problema e
também para criar produtos ou, no nosso caso, interfaces e sistemas.

65. 64 •
capítulo 3
Em grupo é mais fácil a compreensão do problema, sua análise e resolução.
As discussões são abertas e deixadas livres para o grupo, porém deve existir um
intermediador para poder comandar e anotar os resultados.
Normalmente tem duas etapas principais:
• A geração das ideias;
• E a crítica das ideias.
Embora seja uma técnica bastante interessante, ela tem algumas desvan-
tagens, entre elas: por ser uma discussão aberta, quando uma crítica ocorre e
não é bem aceita elo grupo, outras pessoas podem ficar inibidas e deixar de dar
uma ideia que seja relevante; além disso, as ideias podem surgir de uma manei-
ra confusa e impedir que exista um detalhamento em cada uma, dificultando
a avaliação.
3.4.2  CardSorting
O cardsorting ou classificação de cartas tem como objetivo descobrir o modelo
mental dos usuários em relação aos itens de informação para uma aplicação.
Ou seja, esta técnica tenta descobrir como o usuário classifica uma determina-
da informação na sua mente.
Normalmente é usada com usuários inexperientes em design os quais são
guiados a criar uma árvore de categorias, chamada taxonomia. Esta técnica é
muito útil para a arquitetura de informação, fluxos de trabalho, estruturas de
menu ou caminhos de navegação em um site.
Basicamente é uma técnica que não depende de muita tecnologia. Consiste
em escrever as categorias em papel e espalhá-las em uma área para visualmente
fazer a classificação.

66. capítulo 3 • 65
Figura 3.5  – CardSorting.
Veja na figura 3.5 um exemplo dos cartões. Neste caso, são cartões autoade-
sivos, espalhados na área de estudo. Normalmente um usuário é escolhido para
fazer a classificação em grupos.
Resumindo, a técnica funciona de acordo com o seguinte método:
1. Um usuário recebe um grupo de cartões previamente nomeados por
um analista. Neles está escrita a funcionalidade que se deseja da interface;
2. Esta pessoa classifica os termos em grupos lógicos (o que foi chamado
de taxonomia) e acha uma categoria para cada grupo;
3. O processo é repetido entre um conjunto de situações ;
4. O resultado depois é analisado para que os padrões sejam identificados
e definidos.
Enquanto as sessões são realizadas, o analista pode conversar com o usuá-
rio sobre a classificação que foi feita e registrá-la. Após as sessões, as escolhas
feitas pelos usuários que participaram das sessões são analisadas conjunta-
mente, e os termos comuns são numerados com uma porcentagem de concor-
dância. Quanto maior o número, maior é sua indicação para ser usado.

67. 66 •
capítulo 3
No final do processo, o analista terá uma quantificação dos dados e tem
condições de criar um relatório resumindo e cruzando o que foi anotado e tam-
bém terá a taxonomia sugerida pela média dos usuários.
3.4.3  Diagrama de afinidade
O diagrama de afinidade foi criado em 1960 por JiroKawakita com a finalida-
de de organizar um grande número de ideias de acordo com seus relaciona-
mentos naturais. Basicamente esta técnica é usada quando existe um grande
número de ideias, opiniões ou preocupações sobre um determinado assunto.
Normalmente é usada na fase de planejamento e, assim como as outras técni-
cas apresentadas até agora, são usadas para a criação e organização das ideias
sobre IHC.
A técnica possui o objetivo de estimular a criatividade e a participação to-
tal do grupo, que deve ser de um tamanho limitado a no máximo 8 pessoas
que trabalham juntas se possível. Esta técnica é muito relacionada com o
Brainstorming, pois pode ajudar com a organização das ideias.
Existe um pequeno roteiro de construção do diagrama:
1. Após o brainstorm, gerar os dados para a construção do diagrama.
2. Espalhar os dados em uma área que seja visível a todos.
3. Agrupe os dados, contendo no máximo 5 com alguma característica
em comum.
4. Nomeie o grupo de acordo com a característica comum de agrupamen-
to e coloque como um cartão título, diferenciando-o dos demais.
5. Cada grupo é preso ao seu cartão título correspondente. O cartão título
deve permanecer visível dos demais.
6. Repetir os passos 3, 4 e 5 usando os cartões título como cartões de dados
7. Repetir os passos 3, 4 e 5 para cada conjunto novo de cartões título que
foram criados até que se tenha apenas um grupo com 5 cartões título.
8. O diagrama será construído a partir dos pequenos grupos iniciais. Fazer
um retângulo envolvendo cada grupo.
9. No lado superior do retângulo, coloque o cartão título do grupo.
10. Faça outro retângulo sobre os retângulos cujo título forma um grupo.

68. capítulo 3 • 67
Veja um exemplo de um diagrama de afinidades na figura 3.6.
Informações
Desenvolver estratégias para
aumentar o nível de
qualidade dos produtos
oferecidos
Tema
Título
do
Grupo
Perseguir uma
imagem de qualidade
superior
à dos concorrentes
Alcançar “nível zero”
de reclamações
dos clientes
Aprimorar o
Sistema de Garantia
da Qualidade
Elevar o nível de
controle da
empresa
Aprimorar o
controle da
lucratividade
Melhorar o nível
dos profissionais
de controle
Incentivar o espírito
de busca por desafios
Elevar a motivação do
pessoal de vendas
Elevar o grau de
entusiasmo dos
funcionários
Certificar know-how
técnico de
empresas afiliadas
Aprimorar as
habilidades técnicas
da empresa
Alcançar liderança em
tecnologia na indústria
Elevar o número de
patentes obtidas
anualmente
Bordas
Figura 3.6  – Diagrama de afinidades.
3.4.4  Storyboard
Esta é uma técnica mais relacionada com a concepção do que as anteriores. Se
você percebeu com atenção, as técnicas anteriores são úteis para organizar e
criar novas ideias. A partir desta vamos ver técnicas relacionadas com a concep-
ção especificamente.
O storyboard é uma forma de representar as interações entre os usuários e o
sistema em seu ambiente de trabalho. O storyboard é muito usado em outras si-
tuações como por exemplo na pré-visualização de um filme, de uma animação e
outras semelhantes. Na verdade o grande criador e difusor desta técnica foi nin-
guém menos que Walt Disney! É claro que para ele a finalidade é outra, mas para
nós, o storyboard é usado na melhoria da documentação dos requisitos de IHC.
CONEXÃO
Para quem gosta de música dos anos 1980, o grupo musical A-Ha lançou um videoclipe que
é baseado em um storyboard. Assista ao vídeo em https://www.youtube.com/watch?v=dj-
V11Xbc914 para relaxar um pouco dos estudos!

69. 68 •
capítulo 3
O storyboard é feito para detalhar um cenário do sistema por meio de uma
sequência de desenhos. Os softwares indicados anteriormente podem ajudar
nesta situação.
Os desenhos também podem ser feitos em papel e colocados em uma área
visível aos outros membros das sessões de discussão. Por meio desta exposição,
os desenhos podem ser avaliados e discutidos entre os usuários e designers e
devem estar baseados em princípios de usabilidade.
Figura 3.7  – Exemplo de um storyboard para software.
3.4.5  Maquetes – protótipos em papel
As maquetes também são usadas em várias áreas diferentes da área de informá-
tica e IHC, entre elas a arquitetura e a engenharia. Você já deve ter visto na tele-
visão que as maquetes são úteis em filmes, como Star Wars, para a construção
de situações de batalhas no espaço.
As maquetes na IHC contribuem bastante para esclarecimento e desenvol-
vimento de requisitos específicos para a interface do programa e, da mesma
forma como ocorrem nos filmes, elas servem para simular e testar as interações
com o usuário.
Por ela servir como uma forma de simulação, a técnica permite a prévia
identificação de problemas com usabilidade.
A técnica também tem um ciclo de atividades, definido como:
1. Conceito: nesta atividade são elaborados os aspectos conceituais e as
estruturas gráficas das telas.
2. Iteração: nesta atividade as navegações entre as telas são organizadas.

70. capítulo 3 • 69
3. Projeto das telas: é a atividade em que os vários tipos de componentes
são colocados nas telas.
4. Teste das telas: nesta etapa, com os componentes alocados aos seus
lugares, questões como combinação de cores e outros elementos gráficos
são testados.
Figura 3.8  – Exemplo de protótipo de uma tela em papel.
3.4.6  Prototipagem rápida
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 prototipação das telas.
A prototipagem rápida utiliza estes softwares para simular o sistema final
com mais fidelidade do que as telas em papel. As telas em papel são ótimas,
mas não permitem ver como fica a navegação entre as telas realmente. O pro-
blema deste tipo de software é que é necessário passar um tempo para criar
os protótipos e este tempo, se não estiver bem definido durante o planeja-
mento do projeto, pode significar em uma perda valiosa de tempo da parte de
desenvolvimento.
Usando os protótipos em software, é possível obter um feedback mais rá-
pido e fiel sobre a interface e desta forma saber os problemas e vantagens da
interface em desenvolvimento.

71. 70 •
capítulo 3
MULTIMÍDIA
Assista a alguns vídeos do Axure, um software bastante usado para prototipação:
http://www.axure.com/learn. Os vídeos vão ajuda-lo a entender como estes softwares
contribuem para o processo de prototipação.
3.4.7  Prototipagem de baixa e alta fidelidade
As técnicas que foram apresentadas anteriormente são baseadas em protó-
tipos. Um protótipo é uma manifestação de um projeto que permite aos sta-
keholders interagirem com ele e explorarem sua adequação. É na verdade um
modelo, uma representação do que pode ser o produto final.
Um protótipo de baixa fidelidade é aquele que não se parece muito com o
produto final. Por exemplo, podemos usar impressões 3D para representar um
novo modelo de um telefone celular. Os protótipos de baixa fidelidade são úteis
porque são simples e de rápida produção. Mas não é porque são simples sig-
nificam que são baratos e rápidos de serem modificados. O storyboard é um
exemplo de protótipo de baixa fidelidade, assim como o cardsorting.
A prototipação de alta fidelidade, como se espera, utiliza materiais que esta-
rão no produto final. Você já deve ter visto aqueles carros conceito que as mon-
tadoras produzem e expõem nos salões automotivos, certo? É um bom exemplo
de protótipo de alta fidelidade.
Na informática é possível criar protótipos com linguagens rápidas de desen-
volvimento como o Visual Basic por exemplo, para que o usuário tenha noção
de como vai ficar o software final. O protótipo de alta fidelidade é útil para ven-
der ideias para as pessoas e para testar questões técnicas.
TIPO VANTAGENS DESVANTAGENS
Protótipo de
baixa fidelidade
- custo mais baixo de desenvolvimento
- avalia múltiplos conceitos de design
- instrumento de comunicação útil
- aborda questões de layout de tela
- útil para identificação de requisitos
de mercado
- demonstração de que o conceito funciona
- verificação limitada de erros
- especificação pobre em detalhe
do código
- mais facilitado
- utilidade limitada após estabele-
cimento dos requisitos
- utilidade para testes de usabili-
dade limitada
- limitações de fluxo e navegação

72. capítulo 3 • 71
TIPO VANTAGENS DESVANTAGENS
Protótipo de alta
fidelidade
- funcionalidade completa
- totalmente interativo
- dirigido aos usuários
- define claramente o esquema
de navegação
- uso para exploração e teste
- mesma aparência do produto final
- serve como uma especificação viva
- ferramenta de venda e marketing
- desenvolvimento mais caro
- sua criação demanda tempo
- ineficiente para demonstrações
que o conceito funciona
- não serve para coleta
de requisitos
Tabela 3.1  – Eficácia relativa dos protótipos de baixa vs alta fidelidade (ROGERS, SHARP
e PREECE, 2013).
Alguns autores concordam com o fato de que mais projetos deveriam usar
a prototipação de baixa fidelidade porque os problemas existentes na proto-
tipação de alta fidelidade, podem prejudicar o andamento do projeto. Alguns
problemas dos protótipos de alta fidelidade são:
• Levam muito tempo para serem desenvolvidos;
• A equipe de teste tem a tendência de comentar mais sobre aspectos super-
ficiais do que o de conteúdo;
• Como os desenvolvedores levam tempo para criar o protótipo, eles aca-
bam sendo relutantes de mudar alguma coisa depois;
• Um protótipo em software pode criar expectativas muito altas;
• Um bug em um protótipo de alta fidelidade já pode parar os testes.
Outras vantagens e desvantagens encontradas nos protótipos estão mostra-
das na tabela3.1.
3.5 Técnicas de modelagem de interface
Uma vez que vimos as técnicas para a concepção de interface, vamos agora
apresentar algumas técnicas relacionadas com a modelagem de interface. Es-
tas técnicas são um conjunto de etapas e atividades para a definição de elemen-
tos concretos partindo de elementos abstratos.
Vamos analisar duas técnicas:
• The bridge, criada por Tom Dayton em 1996
• Design centrado no usuário, criada por LaryConstantinee Lucy Lockwood
em 1999

73. 72 •
capítulo 3
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
usuário gráficas orientadas a objeto e multiplataforma. A metodologia lida em
grande parte com a questão da criação da tarefa de modelos de interação e os
processos que são necessários para que isso aconteça (WARREN, 1997).
Esta técnica se baseia em uma sequência de sessões de projeto envolvendo
várias pessoas (usuários, programadores e analistas) que criam uma “ponte”
entre os requisitos dos usuários e da organização e o projeto de uma interface
que apoie estes requisitos.
As atividades principais deste método são:
• Expressar os requisitos de usuários por meio de um fluxo de tarefas: nessa
etapa, os envolvidos definem um fluxograma de trabalho para o sistema a ser
executado pelo usuário.
• Mapear os fluxos de tarefa em objetos da tarefa: uma vez que os fluxogra-
mas de tarefas estão definidos, eles são analisados e transformados em obje-
tos de tarefa. Estes objetos correspondem a janelas, caixas de diálogo e caixas
de mensagens.
• Mapear objetos da tarefa em objetos de interface: os protótipos dos obje-
tos de interface definidos nesta etapa devem ter sua usabilidade testada pelos
usuários que participaram das sessões de projeto.
Início
Hóspede solicita
vefirificação de
reserva
Atendente
solicita nome do
hóspede
Atendente
encontra a
reserva
Atendente
escolhe um
quarto
Rsultado
Hóspede oculpa
um quarto
Figura 3.9  – Exemplo de fluxograma de trabalho.
3.5.2  Usercentered design
O usercentered design (UCD) ou design centrado no usuário também é conhe-
cido por processo de design centrado no usuário e, devido a isto, é utilizado em
várias áreas da manufatura, arquitetura e outras. Existem exemplos na internet
do uso desta técnica no design de automóveis (WORLD WIDE WEB CONSOR-
TIUM (W3C), 2004).

74. capítulo 3 • 73
A norma 9241-210:2010 também estabelece que “o design centrado no usuá-
rio é uma abordagem para o desenvolvimento de sistemas interativos que focam
especificamente em fazer sistemas usáveis. É uma atividade multidisciplinar.
No design centrado no usuário, todos os processos de desenvolvimento
têm o usuário como foco. O design centrado no usuário, de acordo com Rubin
(1984), pode ser representado como dois círculos:
• Os usuários estão no centro;
• O círculo interno contém: Contexto, objetivos, ambiente e metas;
• O círculo externo contém: Detalhe das tarefas, conteúdo das tarefas, or-
ganização de tarefas e Fluxo de Tarefas.
Organização de tarefas
Objetivos
Ambiente
Fluxo das tarefas
Detalhes das tarefas
Conteúdo das tarefas
Contexto
Metas
Figura 3.10  – Design centrado no usuário (RUBIN, 1984).
O design centrado no usuário possui os seguintes princípios:
• Foco inicial em usuários e tarefas
o Reunião sistemática de informação estruturada: é importante que
toda informação estruturada seja juntada e analisada pela equipe.
o Designers treinados por especialistas antes de conduzir as ses-
sões de coleta de dados: antes de os dados serem coletados pelos

75. 74 •
capítulo 3
designers, é importante que os especialistas passem sua experiência
para os designers.
• Medidas empíricas e teste de uso do produto
o Foco na facilidade de aprendizagem e facilidade de uso.
o Teste de protótipos com usuários atuais.
• Design iterativo
o Produto projetado, modificado e testado repetidamente.
o Permite uma revisão completa e revisão do design por testes preli-
minares de modelos conceituais e ideias de design.
O objetivo do design centrado no usuário é criar um processo de design que
aumenta a usabilidade do produto.
Design centrado no usuário:
O usuário é envolvido aqui
Modelo clácissico:
O usuário é envolvido aqui
Iniciação Requisitos Especificação Projeto TestesImplementação
Tabela 3.2  – Diferença do estágio onde o usuário é envolvido.
O design centrado no usuário é uma forma de abordagem que pressupõe
que os designers irão prever como os usuários usarão o produto e também vão
testar a validade do que foi levantado com os usuários reais.
Segundo Woodson (1981), o design centrado no usuário pode ser entendido
como uma prática de criar produtos de forma que os usuários sejam capazes de
usá-los com o mínimo de stresse e o máximo de eficiência.
A participação dos usuários, como estamos percebendo, é fundamental
neste tipo de abordagem. Eles são 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 inúteis e o excesso
de informação.

76. capítulo 3 • 75
Existem algumas técnicas que podem ajudar nesta abordagem:
ENTREVISTAS
COM USUÁRIOS E
STAKEHOLDERS
Já vimos que envolver quem vai usar o produto é
fundamental. Se eles são os maiores interessados no
resultado, envolvê-los juntamente com quem patroci-
na o produto é importante.
OBSERVAÇÃO EM
CAMPO
É outra técnica bastante interessante. Por meio da
observação do comportamento no seu ambiente de
trabalho, é possível perceber como ele poderá usar o
produto.
QUESTIONÁRIOS
O uso de questionários é muito incentivado. Se forem
anônimos, pode ser ainda melhor, pois muitas vezes
os usuários podem se sentir acanhados ou incomo-
dados de alguma forma quando estão em sessões
diretas e pessoais. Um questionário pode afastar a ini-
bição e recolher requisitos preciosos para o produto.
CARDSORTING
Já vimos esta técnica antes e estudamos que ela
classifica os requisitos de maneira bastante eficiente.
PERSONAS
Outra ideia interessante é a incorporação de papéis
pelos usuários, ou personificação. Por meio das
personas criadas, o usuário pode dar sinais do que
é necessário no produto final. O papel de usuário
é definido como um tipo de usuário que apresenta
necessidades, interesses, expectativas, comportamen-
tos ou responsabilidades específicas em relação ao
produto ou sistema.
PROTOTIPAÇÃOOutra técnica que já foi vista anteriormente.

77. 76 •
capítulo 3
TESTES COM
USUÁRIOS
Os protótipos são muito usados e a utilização de
testes certamente é outra forma de colocar o usuário
como validador do que foi prototipado.
CASOS DE TAREFAS
São semelhantes aos casos de uso da UML. São
definidos como narrativas estruturadas e simplificadas
de interação realizada pelo usuário desempenhando
seu papel por meio do sistema.
3.6 Considerações finais
Vimos várias técnicas para obter os requisitos dos usuários e stakeholders
para construir melhores produtos.
Quando tratamos dos projetos relacionados com IHC, podemos resumir as
várias características favoráveis das técnicas para o bom projeto:
• Envolver as soluções relacionadas aos aspectos essenciais da interface
no início;
• Prever a descrição de soluções em termos abstratos inicialmente, e deta-
lhar progressivamente conforme o projeto avança;
• Prever transformações, representando com mapeamento os aspectos de
uma representação e outra;
• Prever diversas oportunidades para que tais definições sejam repartidas e
validadas pelos usuários.
Portanto, quando consideramos o usuário, a abordagem de projeto centra-
do ao usuário, leva em conta o ser humano em cada etapa do desenvolvimento
de um produto ou serviço. E tudo que o usuário experimenta deve ser resultado
de uma decisão consciente da parte do projetista.

78. capítulo 3 • 77
ATIVIDADES
01. Quem você acha que pode ser os stakeholders de um sistema para caixa de um gran-
de supermercado?
02. Quais são os principais tópicos do design centrado no usuário?
03. Faça um storyboard para a reserva de um quarto de hotel pela web.
04. Por que o uso de protótipo em algumas situações pode não ser uma boa ideia como
forma de obter requisitos do usuário?
05. Falamos algumas vezes sobre Bootstrap. O que é isso? Pesquise no site www.getboots-
trap.com e liste suas principais características.
REFLEXÃO
Criar interfaces gráficas não é uma tarefa tão fácil quanto parece. Vemos em muitas empresas
uma certa despreocupação com esta parte tão importante do software. Atualmente existem
várias facilidades técnicas para criação de interfaces como o Bootstrap, o AngularJS, o JQuery
e não basta ser um craque nestas tecnologias, o que vimos aqui neste capítulo é fundamental.
Tente aplicar estes ensinamentos nos projetos que você participar. Certamente eles serão um
belo diferencial entre você e outros que não se preocupam com isso e só com a parte técnica.
LEITURA
Abaixo estão listados alguns links que podem ser úteis no seu estudo sobre design de interfaces:
Informações sobre IHC no Brasil: http://www.sbc.org.br/ihc
Este link é legal porque contém várias referências sobre IHC. Vale a pena dar uma boa
olhada: http://www.usernomics.com/hci.html
A ACM (AssociationofComputingmachinery) é uma entidade que dita vários padrões
para a computação em geral. Eles têm um grupo de estudos específicos na área de IHC:
http://www.acm.org/sigchi/
Este é um link de um livro online a respeito de IHC. Bastante interessante também:
http://brazil.joelonsoftware.com/uibook/chapters/1.html

79. 78 •
capítulo 3
REFERÊNCIAS BIBLIOGRÁFICAS
BARBOSA, S.; SANTANA, B. Interação 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. Publicações. Unidade Acesso, 2013. Disponivel em: <http://www.
acessibilidade.gov.pt/publicacoes#manuais>. Acesso em: 1 jul. 2015.
POPLADE, T. Como tornar seu site acessível. Tableless, 2010. Disponivel em: <http://tableless.
com.br/como-tornar-seu-website-acessivel/>. Acesso em: 01 jul. 2015.
QUEIROZ, M. A. D. Métodos 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 interação . 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).

80. Avaliação
4

81. 80 •
capítulo 4
Imagine uma situação na qual você desenvolveu um site, após 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 usuários-alvo: um grupo
de adolescentes (por exemplo, um site para vestibular). Como é possível saber
se eles se interessarão pelo site e vão de fato usá-lo? É necessária de uma avalia-
ção. Mas como avaliar?
Assim como qualquer outra parte do design, a avaliação é integrante do pro-
cesso de desenvolvimento. Quem vai fazer a avaliação precisa pegar as infor-
mações sobre a experiência do usuário ou possíveis experiências quando estão
interagindo com um protótipo, um sistema de computador, um componente
de um sistema, etc.
Isto é feito para melhorar o design, e a avaliação tem como foco melhorar a
usabilidade e a experiência do usuário ao interagir com o sistema.
Neste capítulo vamos estudar alguns assuntos relacionados com a avaliação
e te dar elementos que podem ser expandidos em uma situação real por você ou
pela sua equipe. Nunca se esqueça de avaliar o produto que está sendo entregue
e nunca se esqueça de que a avaliação deve fazer parte do projeto da interface.
Vamos lá? Bons estudos e bom trabalho!
OBJETIVOS
Após ler e estudar este capítulo, você estará apto a:
• Entender os principais conceitos e termos na avaliação;
• Conhecer alguns tipos de avaliação, entre elas:
o Avaliação analítica
o Avaliação heurística
o As listas de verificação
o O percurso cognitivo
o A inspeção preventiva de erros

82. capítulo 4 • 81
4.1 Introdução
Atualmente vemos o mercado receber vários tipos de produtos diferentes em
relação aos dispositivos móveis, não é?
Principalmente os grandes players do mercado, como Apple, Samsung,
Motorola, Asus, Sony e outros a cada dia lançam produtos semelhantes, mas
com alguma característica que os tornam diferentes. O iPod, iPad, os e-readers
(como o Kindle, o Lev, o Kobo, por exemplo) aumentaram muito a percepção dos
usuários quanto à usabilidade, porém há um detalhe: será que o que os desig-
ners acham que vai ser usado por todos, que é tão 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 estão discutindo sobre o Lisa, um computador pessoal
que poderia revolucionar o mercado com sua interface gráfica e uso do mouse,
porém, foi um fracasso comercial para a Apple.
Portanto, a avaliação é importante. Temos certeza, que a Apple fez as de-
vidas avaliações, afinal, estamos falando da Apple! Porém trabalhar com uma
hipótese de que os usuários aceitarão o produto baseado nas preferências dos
designers é um risco alto.
Existem vários métodos de avaliação diferentes. Decidir qual usar é uma ta-
refa difícil e que de uma certa forma está relacionada com a cultura da equipe
de desenvolvimento. As avaliações normalmente abrangem a observação do
usuário ao usar o produto e medir o seu desempenho por meio de testes de
usabilidade, experimentos ou estudos de campo. Existem outros métodos que
não envolvem diretamente a participação do usuário, como a modelagem do
comportamento do usuário.
Estes últimos aproximam-se de previsões do que os usuários podem fazer
na interação com a interface.
Vamos estudar a importância da avaliação 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. Porém, os usuários certamente esperam mais do que isso: esperam

83. 82 •
capítulo 4
também que ele tenha uma experiência agradável no uso e que seja envolvente.
Portanto, a avaliação é mais do que justificável.
Se formos considerar a parte de negócios, um produto com bom design ven-
de. E isto torna mais um bom motivo para que a avaliação seja importante. A
avaliação é uma atividade que permite corrigir erros no produto antes que este
seja colocado em produção e seja vendido.
Vamos pegar um exemplo para ilustrar:
Chame um jovem adolescente e um adulto para conversar a respeito do
Facebook e faça 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 alguém da sua lista de amigos?
Estas perguntas feitas a dois tipos de usuários diferentes vão nos levar a
uma avaliação 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? (Não precisa responder, apenas pense que estamos avaliando
o produto). O produto contém 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 avaliação 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 avaliação vai depender do “tamanho da encrenca”, ou seja, pode
ser avaliar protótipos de baixa tecnologia a sistemas completos e mais complexos,
com apenas uma tela de interação ou que possui vários módulos interligados.

84. capítulo 4 • 83
Por exemplo, os desenvolvedores de um novo navegador para a web podem
querer saber se os itens que eles desenvolveram nas telas são encontrados mais
rapidamente na nova versão, enquanto também podem querer saber se as no-
vas telas alteram o comportamento do usuário. Uma empresa que desenvolve
media players (tipo o Winamp) pode querer saber se usuários diferentes, de
países diferentes, gostam da mesma aparência da tela, etc.
Ou seja, devemos avaliar os aspectos cognitivos e funcionais relacionados à
realização das tarefas apoiados pelo sistema, como:
• É rápido?
• É de fácil aprendizado?
• É confiável?
• Permite reverter erros realizados com facilidade?
• Permite ser lembrado depois de algum tempo sem usar?
Além disso, aspectos socioculturais do uso da solução e dos contextos pre-
vistos também devem ser avaliados.
E aspectos afetivos do sistema, como se as pessoas vão gostar, se é bonito e
agradável, etc.
4.4 Onde avaliar?
Novamente, a localização da avaliação vai ocorrer dependendo do projeto e do
que está sendo avaliado. Quando vamos avaliar acessibilidade na web, é melhor
avaliar dentro de um laboratório, a fim de verificar e controlar se todos os requi-
sitos necessários estão sendo cumpridos.
Isso ocorre também com as escolhas de design, como o layout e o tamanho
das teclas de um telefone celular. Outros aspectos como a experiência do usuá-
rio, como crianças experimentando um novo brinquedo também podem ser
avaliadas. Neste caso, o tempo em que a criança 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 usuário, chamados também
de estudos na natureza (ROGERS, SHARP e PREECE, 2013).
Em outras situações, como redes sociais, a avaliação pode ser feita nas pró-
prias casas dos usuários, podendo ser realizadas para avaliar as interações na-
turais de um grande número de usuários.

85. 84 •
capítulo 4
4.5 Quando avaliar?
A fase de avaliação do produto ocorre em uma determinada parte do ciclo de
vida do seu desenvolvimento e também depende do tipo de produto. Como
exemplo, vamos supor que um produto totalmente novo está sendo desenvolvi-
do ou sendo atualizado para uma nova versão. Neste caso, quando o produto é
novo, haverá um tempo para a criação de protótipos, levantamento de requisi-
tos e pesquisa de mercado. Quando os requisitos forem obtidos, a criação dos
protótipos, esboços, storyboards levará um tempo para o desenvolvimento.
Logo, a avaliação neste caso é feita durante o design.
Quando a avaliação é feita durante o design, ela é chamada de avaliação for-
mativa (RUBIN, 1984). As avaliações deste tipo abrangem uma grande parte de
processos de design, desde o desenvolvimento de esboços iniciais e protótipos
até a fase final do design.
Existem também as chamadas avaliações somativas. Estas são usadas para
medir o sucesso de um produto acabado. Se o produto está em atualização, en-
tão a avaliação 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, é possível que problemas
de usabilidade ocorram.
De qualquer maneira, algumas agências reguladoras, como o National
Institute of Standards and Technology (NIST), nos EUA, e a International
Standards Organization (ISO), e a sociedade britânica, têm padrões nos quais a
avaliação do produto é determinada em uma parte do ciclo de vida do produto.
MULTIMÍDIA
Momento Vintage: Assista a estes vídeos a respeito do Apple Lisa e como era a ideia de
interface com o usuário 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

86. capítulo 4 • 85
4.6 Técnicas de Avaliação de Usabilidade
Possíveis problemas de usabilidade podem ocorrer durante o processo de cons-
trução de um software; isto é natural e aceitável. O objetivo do uso de técnicas
de avaliação é evitar que esses problemas passem desapercebidos e venham
causar algum tipo de desconforto ou descontentamento ao usuário. Serão
avaliadas as funcionalidades do sistema e a usabilidade da interface, levan-
do em consideração aspectos como: interatividade e comunicabilidade, bem
como desempenho, aprendizado, memorização, planejamento e satisfação
dos usuários.
Basicamente existem três tipos de técnicas de avaliação que são geralmen-
te utilizadas:
TÉCNICAS
PROSPECTIVAS
neste tipo de técnica, busca-se a opinião do usuá-
rio sobre a experiência de uso e interação com o
sistema.
TÉCNICAS
PREDITIVAS/ANALÍTICAS
Neste tipo, a busca de prevenção de erros na
interface é feita sem a participação direta de
usuários.
TÉCNICAS
OBJETIVAS/EMPÍRICAS
As informações sobre problemas na interface são
obtidas enquanto o usuário é observado interagin-
do com o sistema.
4.6.1  Técnicas prospectivas
Este tipo de técnica se baseia em saber a opinião do usuário com relação à sua
interação com o sistema, avaliando o seu nível de satisfação em relação à expe-
riência de uso. Geralmente esses métodos são realizados por meio de entrevis-
tas e questionários.
Quando se tem um número reduzido de usuários, as entrevistas são indica-
das, pois é possível identificar o nível de ansiedade do usuário ao interagir com

87. 86 •
capítulo 4
o sistema, entretanto, por parecer um método mais informal, por vezes pode
ser mais difícil obter resultados confiáveis e válidos. Já os questionários são in-
dicados quando o número de usuários é muito grande, tendo perfis diferentes.
4.6.2  Técnicas preditivas
Estão baseadas em conhecimento heurístico ou teórico de um avaliador que é
especialista. Neste caso, não é preciso envolver os usuários, porque os especia-
listas usam o seu conhecimento sobre os usuários e as situações típicas de uso.
É uma alternativa interessante em relação a custo.
Vamos ver algumas destas técnicas.
4.6.2.1  Avaliação Heurística
A avaliação heurística identifica possíveis problemas ou barreiras que possam
ser encontradas pelos usuários ao interagirem com o sistema permitindo uma
avaliação contínua a um baixo custo. Ela pode ser aplicada tanto no desenvolvi-
mento do projeto, quanto após a sua implementação
Ela foi proposta por Jakob Nielsen (NIELSEN, 1994) e, segundo ele, “o ob-
jetivo da avaliação heurística é encontrar os problemas de utilização na con-
cepção, de modo que eles possam ser atendidos como parte de um processo
iterativo de design. ”
Nielsen chamou de heurística porque são regras no âmbito geral e não dire-
trizes específicas de usabilidade.
Neste tipo de técnica é considerado que somente uma pessoa não é capaz
de encontrar todas as possíveis falhas do sistema; por isso, para a avaliação, é
proposta a seleção de um pequeno grupo avaliadores que submetem o sistema
aos princípios heurísticos. Com isso eles podem estabelecer o que realmente é
importante e necessário para a construção de um modelo consistente. Eles se
baseiam em regras gerais que descrevem propriedades comuns à construção
de interfaces. O design é examinado em busca de elementos que violem essas
regras.
São atribuídos valores de gravidade para cada problema encontrado em
cada passo, segundo uma escala proposta por Nielsen e Mack (1994):
0. Não é considerado em sua totalidade um problema de usabilidade.

88. capítulo 4 • 87
1. Problema apenas estético: não é necessário 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, não é tão importante consertá-lo.
3. Problema maior de usabilidade: deverá ser dada alta prioridade ao con-
serto deste problema, é importante consertá-lo.
4. Catástrofe de usabilidade: É obrigatório consertá-lo, antes de o produto
ser divulgado.
A motivação principal do método é facilitar e acelerar o processo de avalia-
ção de interfaces, maximizando o papel da experiência do avaliador, para en-
frentar a cada vez mais crescente demanda de boas interfaces.
As etapas principais são:
1. Preparação
2. Sessões curtas de avaliação individual
3. Consolidação das avaliações individuais
4. Priorização dos problemas encontrados
5. Relatório conclusivo final
Preparação
Sessões
curtas
Consolidação Priorização Relatório final
Diversos autores de maior influência na área de IHC propuseram méto-
dos que avaliam sites e interfaces em todos os casos, sendo possível encon-
trar algumas semelhanças nos métodos propostos por eles. Entretanto, den-
tre esses autores, o que tem maior relevância em relação aos demais por ter
proposto o termo e ter criado uma lista de dez heurísticas que são imprescin-
díveis para a melhora na usabilidade das interfaces, é Jakob Nielsen.

89. 88 •
capítulo 4
VISIBILIDADE DO
ESTADO DO SISTEMA
Mantenha os usuários informados sobre o que está
acontecendo por meio de feedback adequado e no
tempo certo.
CORRESPONDÊNCIA
ENTRE O SISTEMA E
O MUNDO REAL
Utilize conceitos, vocabulário e processos familiares
aos usuários.
CONTROLE E
LIBERDADE DO
USUÁRIO
Forneça alternativas e “saídas de emergência” e pos-
sibilidades de voltar e refazer (undo e redo).
CONSISTÊNCIA E
PADRONIZAÇÃO
Palavras, situações e ações semelhantes devem
significar conceitos ou operações semelhantes. Caso
haja convenções para o ambiente ou plataforma
escolhidos, estas devem ser obedecidas.
PREVENÇÃO DE
ERRO
Tente evitar que o erro aconteça informando o usuário
sobre as consequências de suas ações ou, se possí-
vel, impedindo ações que levariam a uma situação de
erro.
AJUDA AOS
USUÁRIOS PARA
RECONHECEREM,
DIAGNOSTICAREM E
SE RECUPERAREM
DE ERROS
Mensagens de erro em linguagem simples, sem códi-
gos, indicando precisamente o problema e sugerindo
de forma construtiva um caminho de recuperação.
RECONHECIMENTO
Em vez de memorização, torne os objetos, ações e
opções visíveis e compreensíveis.

90. capítulo 4 • 89
FLEXIBILIDADE E
EFICIÊNCIA DE USO
Ofereça aceleradores e caminhos alternativos para
uma mesma tarefa e permita que os usuários custo-
mizem ações frequentes.
DESIGN ESTÉTICO E
MINIMALISTA
Evite porções de informação irrelevantes. Cada unida-
de extra de informação em um diálogo compete com
as unidades de informação relevantes e reduz sua
visibilidade relativa.
AJUDA E
DOCUMENTAÇÃO
Devem ser fáceis de buscar, focadas no domínio e na
tarefa do usuário, e devem listar passos concretos a
serem efetuados para atingir seus objetivos.
O procedimento de execução desta técnica é feito da seguinte maneira, por
meio de etapas:
DETERMINAÇÃO
DA PROPOSTA DE
DESIGN
A apresentação deve ser decidida entre papel, ou por
meio de um protótipo ou por produto acabado. É feita
uma verificação das condições gerais da inspeção, a
fim de verificar se o material completo e inspecionável
está a contento.
NAVEGAÇÃO
GERAL PELO
SISTEMA (OU SUA
REPRESENTAÇÃO)
Determinação de qual o sentido geral o avaliador vai
dar ao sistema que vai analisar em detalhes.
DETERMINAÇÃO
DO PERFIL DOS
USUÁRIOS
Quem são os usuários e suas características e con-
textos individuais, sociais e culturais. E o que desejam
como objetivo com o produto.

91. 90 •
capítulo 4
DETERMINAÇÃO DE
CENÁRIOS DE USO
Em quais as situações prováveis, mas plausíveis, os
usuários poderiam encontrar-se? Ou seja, no que os ava-
liadores estão pensando quando fazem sua inspeção?
Algumas vezes os avaliadores fazem inspeções de uma maneira mais geral,
sem instanciar usuários específicos ou cenários de uso.
Todos os avaliadores juntos discutem as avaliações individuais e examinam
as divergências encontradas. Em seguida elaboram uma lista consensual de
violação das heurísticas, cada qual com o respectivo grau de severidade estabe-
lecido em comum acordo.
Eles também atribuem prioridades de correção para todas as violações lista-
das e geram um relatório final do grupo com as suas conclusões e comentários.
Portanto, para se aplicar o método, existem as seguintes maneiras:
1. Criar um conjunto de tarefas para ser aplicado pelos avaliadores;
2. Fornecer aos avaliadores os objetivos da aplicação e deixar que eles
criem suas próprias tarefas;
3. Pedir para os avaliadores testarem os elementos de diálogo.
A escolha do método de aplicação a ser usado vai depender do tempo dis-
ponível para teste e dos avaliadores. Por exemplo, se o grupo de avaliadores é
formado por crianças, 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 heurísticas para ques-
tões de web design.
• Clareza: torne o sistema o mais claro, conciso e significativo possível para os usuários finais.
o Escreva de forma clara e concisa.
o Somente utilize linguagem técnica quando houver um público técnico específico.
o Escreva textos que sejam claros e significativos.
o E use ícones que realmente representam o que eles se propõem.
• Diminua a complexidade desnecessária e a carga cognitiva: torne o sistema o mais simples
possível para os usuários concluírem suas tarefas.
o Tire as funcionalidades, as etapas de processo e poluições visuais que não se-
jam necessárias.

92. capítulo 4 • 91
o Use a comunicação progressiva para esconder recursos avançados.
o Divida processos complicados em várias etapas.
o Priorize o uso de tamanho, forma, cor, alinhamento e proximidade.
• Forneça um contexto aos usuários: as interfaces devem dar aos usuários um contexto em
relação ao tempo e espaço.
o Dê um nome claro e um objetivo para o site.
o Destaque a seção atual na navegação.
o Forneça um caminho de navegação.
o Use mensagens de feedback apropriadas.
o Mostre um número de etapas em um processo.
o Reduza a percepção de latência, dando pistas visuais (um indicador de progresso
por exemplo), ou deixe que os usuários completem outras tarefas enquanto estão es-
perando.
• Faça com que o usuário tenha uma experiência agradável e positiva: o usuário deve ser
tratado com respeito, e o design deve ser esteticamente agradável e promover uma expe-
riência gratificante.
o Crie um design agradável e atraente.
o Crie objetivos facilmente atingíveis.
o Recompense o uso e a progressão.
4.6.2.2  Inspeção por meio de lista de verificação
A lista de verificação é um checklist, ou seja, são vistorias baseadas em uma
lista em que existem itens a serem verificados por meio de profissionais, não
necessariamente especialistas em ergonomia, como por exemplo, programa-
dores e analistas, que diagnosticam os problemas gerais e repetitivos das inter-
faces rapidamente.
Ao contrário das avaliações heurísticas, são as qualidades da ferramen-
ta (checklist), e não dos avaliadores, que determinam as possibilidades para
a avaliação.
Checklists bem elaborados devem produzir resultados mais uniformes e
abrangentes, em termos de identificação de problemas de usabilidade, pois os
inspetores são conduzidos no exame de interface por meio de uma mesma lista
de questões a responder sobre a usabilidade do projeto.

93. 92 •
capítulo 4
As inspeções por listas de verificação não precisam necessariamente ser
realizadas por profissionais especialistas em ergonomia.Podem ser realizadas
por programadores e analistas, isto porque quem determina a qualidade da
avaliação são as questões contidas na lista, e não os avaliadores. Se o questio-
nário for bem elaborado, a inspeção por lista de verificação tende a produzir
resultados mais consistentes, uma vez que todos os avaliadores são conduzi-
dos por uma lista questões para realizar a avaliação de usabilidade do sistema.
Portanto, este tipo de avaliação apresenta uma série de vantagens:
• O conhecimento ergonômico está contido na própria lista de verificação,
sendo assim, não são necessários profissionais especializados em IHC, que são
mais escassos no mercado.
• Existe a garantia de que os resultados serão mais estáveis mesmo que fo-
rem aplicados separadamente por diferentes avaliadores, isso porque as ques-
tões da lista sempre serão verificadas.
• As especificidades das questões da lista fazem com que problemas de usa-
bilidade sejam facilmente encontrados.
• Redução da subjetividade dos processos de avaliação.
• Reduzir os custos da avaliação, pois é um método de rápida aplicação, não
necessita de pessoal especializado.
Entretanto, para que essas listas sejam realmente efetivas, é necessário re-
duzir ao máximo o número de questões subjetivas que possam colocar o ava-
liador em dúvida, ou exigir dele competências a níveis de usabilidade ou ergo-
nomia que ele não possui. Outros fatores que podem interferir na economia da
inspeção são conteúdos incompletos ou mal organizados ou muito extensos,
que podem não ser aplicáveis ao sistema.
Podemos ver, no exemplo de uma lista de verificação desenvolvida pelo
LabUtil chamada Ergolist (http://www.labiutil.inf.ufsc.br/ergolist/check.htm),
que existem diversos tópicos que são abordados e para cada um dos tópicos
existe uma série de questões que serão respondidas pelos avaliadores.

94. capítulo 4 • 93
Figura 4.1 – 
Exemplo de

checklist.

95. 94 •
capítulo 4
Figura 4.2 – 
Continuação do

checklist.

96. capítulo 4 • 95
4.6.3  Técnicas objetivas
As técnicas objetivas também são chamadas de técnicas empíricas e são basea-
das na participação direta dos usuários.
Apesar de existirem outras técnicas, vamos estudar com mais destaque a
técnica “Ensaio de Interação”.
©© ALPHASPIRIT | DREAMSTIME.COM
4.6.3.1  Ensaio de Interação
Como o próprio nome da técnica sugere, um ensaio de interação consiste em
“ensaiar” o uso de um sistema, quase que literalmente, como se fosse um en-
saio de uma peça de teatro ou de uma banda.
No nosso caso, um ensaio de interação é o uso simulado de um sistema em
que as pessoas que vão utilizá-lo participam das sessões e tentam fazer tarefas
usuais típicas que fariam com um protótipo do sistema.
A preparação para o ensaio necessita de um trabalho detalhado de reconhe-
cimento do usuário final e de sua tarefa típica para a composição dos cenários e
procedimentos que vão ser aplicados durante a realização das sessões de testes.

97. 96 •
capítulo 4
Os ensaios de interação têm o objetivo de identificar problemas na interfa-
ces e pontos que atrapalhem a facilidade de uso. Dele participam pessoas inte-
grantes do seu público-alvo (usuários), realizando as mais diversas tarefas de
interação com o sistema.
Esse tipo de ensaio é importante, pois mostra que nem todos pensam da
mesma forma. É possível comparar a forma de interação dos diferentes usuá-
rios com o sistema e ver que eles interagem com o sistema de diferentes for-
mas. Esse tipo de observação permite que os analistas observem os pontos de
falha do sistema, o que pode fornecer novas ideias ao projeto.
Montagem de ensaio de interação
Análise preliminar
Definição dos cenários e da amostra
Realização dos ensaios
Obtenção das amostras de usuário
Ajustes nos scripts e cenários
Preparação dos ensaios
Realização dos ensaios
Coleta e análise dos dados
Diagnóstico e relatório final
Coleta de informações sobre o usuário e sua tarefa
Definição de tarefas para o usuário
Reconhecimento do usuário
Pré-diagnóstico ergonômico
Reconhecimento do software
Figura 4.3  – Montagem do ensaio de interação.

98. capítulo 4 • 97
A figura 4.3 mostra um diagrama geral da montagem do teste de interação
de acordo com uma situação de responsabilidade. Percebemos que está dividi-
da em 3 partes:
• Análise preliminar;
• Definição dos scripts, cenários e da amostra;
• Realização dos ensaios.
Análise Preliminar
No processo de preparação do teste, é necessário determinar o escopo do
teste, ou seja, o que se quer descobrir ao observar os usuários. Para tal, é pre-
ciso conhecer cada usuário e saber quais são as tarefas que eles mais utilizam.
Instruções são dadas aos usuários no momento da aplicação do teste; são dis-
tribuídos também blocos para anotações. Ao realizar as tarefas, os usuários são
observados e avaliados, são verificadas todas as suas ações e reações durante
todo o processo de interação.
Todas essas tarefas são observadas pelos avaliadores com auxílio de dispo-
sitivos de áudio e vídeo, marcação de tempo, espelhos falsos, tudo isso para sa-
ber quais são as ações e as reações dos usuários ao interagirem com a interface
do sistema. Os ensaios também podem ser gravados, para que a avaliação seja
realizada posteriormente.
A fase de análise preliminar é aquela em que os analistas entram em con-
tato com o software e o seu contexto de desenvolvimento e fazem um pré-diag-
nóstico dos problemas de ergonomia de sua interface com o usuário.
Reconhecimento do software
Naturalmente, para o software ser reconhecido, são feitas algumas sessões
de entrevistas com as pessoas que projetaram e desenvolveram para trazer in-
formações sobre o que foi projetado e desenvolvido.
As questões que são feitas a essa equipe são de várias naturezas, como o
tempo de desenvolvimento, para quem o software foi desenvolvido, dados so-
bre o sistema, situação no mercado e etc.
Esse levantamento é feito para comprender o ciclo de desenvolvimento do
software e dar fundamentos para o pré-diagnóstico.

99. 98 •
capítulo 4
Pré-diagnóstico
Com base nas informações obtidas pelos analistas, o software é examinado
primeiro para que as funcionalidades sejam conhecidas e depois para identifi-
car as funções mais problemáticas.
O pré-diagnóstico pode ser obtido por meio de uma avaliação do tipo heurís-
tica ou ainda por meio de um checklist para inspeção ergonômica. Os critérios,
recomendações e normas ergonômicas servem como ferramenta de apoio.
O resultado é apresentado como um conjunto de hipóteses sobre proble-
mas de usabilidade do software que serão testadas posteriormente durante os
ensaios de interação.
Definição dos scripts, cenários e da amostra de usuários
Os scripts se referem ao conjunto de tarefas que uma amostra de usuários finais
deverá realizar durante os ensaios. O cenário se refere ao ambiente de execu-
ção, envolvendo questões organizacionais. Os scripts e cenários são montados
de acordo com as informações obtidas no reconhecimento do software e de seu
pré-diagnóstico ergonômico e das informações obtidas pelo reconhecimento
do perfil do usuário e de sua tarefa.
Reconhecimento do perfil do usuário
A primeira tarefa desta parte é contatar os usuários finais e verificar se eles
têm o mesmo perfil imaginado pelos projetistas. Nesta etapa já é possível esti-
mar o grupo que participará dos ensaios.
Coleta de informações sobre o usuário e sua tarefa
Dependendo do público-alvo, pode ser que seja necessário um detalha-
mento da coleta de informações sobre os usuários e suas tarefas. Por meio de
questionários, os projetistas podem buscar mais dados dos usuários em uma
amostra maior de pessoas. Estes questionários podem servir como roteiros de
entrevistas presenciais ou a distância.
Os questionários podem coletar vários tipos de dados, como:
• recursos disponíveis (tanto técnicos como físicos) para a realização de
uma tarefa;
• do contexto da tarefa;
• do nível dos usuários;
• da utilização do sistemas.

100. capítulo 4 • 99
Definição dos scripts de tarefas para os ensaios
Algumas tarefas são selecionadas para definir os scripts dos ensaios:
• tarefas relacionadas com os objetivos principais do software, do ponto de
vista dos projetistas;
• as hipóteses dos projetistas de ergonomia, feitas no pré-diagnóstico;
• as amostras de tarefas dos usuários que foram obtidas com os questionários;
• as funcionalidades do sistema consideradas mais e menos importantes
pelo usuário;
• as funcionalidades mais acionadas pelos usuário no uso do software.
Combinando estes parâmetros, é possível criar um script, sempre conside-
rando a questão custo-benefício dos ensaios. O importante é saber avaliar criti-
camente sob o ponto de vista do usuário e de sua tarefa.
Os testes podem ocorrer em ambientes naturais, tendo como vantagem
ser o ambiente real de utilização do software pelo usuário, mas com algu-
mas desvantagens:
• Possível descontrole sob as condições do teste;
• Problemas técnicos;
• Interferências durante o teste.
Ou podem ser realizados em laboratórios, que dão condições melhores aos
avaliadores, mas podem gerar certos desconfortos aos usuários:
• Condições artificiais;
• Fora de contexto;
• Inibição.
Após a aplicação do teste, a satisfação dos usuários é avaliada por meio de
questionários e entrevistas.
ATIVIDADES
01. Informe as características você gostaria de avaliar para os seguintes sistemas:
a) Um tocador de música pessoal, como o iPod;
b) Um site para vender roupas.

101. 100 •
capítulo 4
02. Veja o Box sobre as heurísticas para web design no texto. Selecione um site que você
conhece bem e o avalie segundo as heurísticas do Box.
a) Essas heurísticas o ajudam a identificar questões importantes de usabilidade e expe-
riência do usuário?
b) Saber das heurísticas influencia de alguma forma o modo como você interage com
o site?
03. Agora use as 10 heurísticas comentadas no texto para avaliar um site que vende roupas
(por exemplo).
a) Como você pode usá-las para avaliar o site?
b) As heurísticas o ajudam a se concentrar mais no site do que se você não as estives-
se usando?
c) Usar menos heurísticas poderia ser melhor? O que poderia ser combinado e quais são
as suas compensações?
04. Você conhece as barras de ferramentas da Microsoft, não é? Elas têm uma forma de
exibir uma pequena descrição abaixo de cada ícone. Por que ferramentas com esta descrição
podem ser acessadas mais rapidamente? (Suponha que o usuário conheça a ferramenta e
não necessite da descrição para identificá-la).
REFLEXÃO
Se você estiver trabalhando no mercado de desenvolvimento, ou vai entrar em breve, você
notará que ainda existem empresas que não dão a devida atenção à avaliação de interfaces,
como vimos neste capítulo. Você deve ter lido o box sobre as heurísticas para a web. Percebe
que ali são dicas práticas 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, exerça o seu papel e use estas técnicas que foram intro-
duzidas aqui e ajude para melhorar a qualidade do software e das interfaces que geramos
atualmente. E nunca se esqueça das questões relacionadas com acessibilidade, que já vimos
em outro capítulo.

102. capítulo 4 • 101
LEITURA
Na Universidade Federal de Santa Catarina existiu até 2003 o LabIUtil (Laboratório de Uti-
lizabilidade). Porém, o laboratório ainda deixa alguns resultados disponíveis, 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 substituída por “usabilidade”. Mas o nome do laboratório 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 português:
CARRION, W. Design para webdesigners: princípios de design para web. Rio de Janeiro:
Brasport, 2008
Este livro também é interessante e o autor é o Jakob Nielsen, “pai” das heurísticas que
estudamos:
LORANGER, H.; NIELSEN, J. Usabilidade na web: projetando websites com qualidade.
Rio de Janeiro: Campus, 2007
REFERÊNCIAS BIBLIOGRÁFICAS
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 ergonômica. Florianópolis: Universidade
Federal de Santa Catarina, 2003.
MORAIS, É. M. D. UM ESTUDO SOBRE A VALIDADE E FIDEDIGNIDADE DE MÉTODOS
DE AVALIAÇÃO DE INTERFACES. Universidade Estadual de Maringá. Maringá, p. 116. 2007.
(Dissertação (Mestrado em Ciência da Computação)).

103. 102 •
capítulo 4
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 interação. 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.

104. Acessibilidade à
Web
5

105. 104 •
capítulo 5
Acessibilidade é uma palavra composta por duas partes: acessível, 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 acessível 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 acessíveis e também na
internet: se a internet é de todos, como dizem, não se pode deixar de lado as
pessoas portadoras de necessidades especiais. Muito já foi feito e muito ainda
precisa ser feito.
Na verdade, quem não possui deficiência ou até mesmo mobilidade reduzi-
da, ou não está envolvido com pessoas que possuem, não conseguem imaginar
tantas situações que discriminam as pessoas que sofrem com uma situação
inadequada, como um banheiro não adaptado, uma calçada 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 ações a serem feitas em sites para poder
atender às pessoas com necessidades especiais.
Neste capítulo vamos estudar estas recomendações e compreender a
sua importância.
OBJETIVOS
Final deste capítulo, você estará apto a:
• Saber a importância de desenvolver sites acessíveis;
• Projetar sites acessíveis básicos.

106. capítulo 5 • 105
5.1 Introdução à acessibilidade
Antes de entrarmos com tudo na questão da web, é interessante conceituar
acessibilidade de maneira geral.
Basicamente, todos deveriam ter as mesmas oportunidades e, por incrível
que pareça, esta preocupação começou a tomar mais força nos últimos anos.
Veja por exemplo alguns teatros antigos, suntuosos e famosos: eles não tinham
rampas de acesso e elevadores até há pouco tempo. É interessante observar
que este tipo de construção antiga não tinha referência alguma em relação
à acessibilidade.
Até mesmo nas nossas ruas. É difícil encontrar em algumas cidades calça-
das rebaixadas, sinalização 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 segurança e autonomia, de espaços, imobiliários e equipamentos urba-
nos, edificações, transportes e sistemas e meios de comunicação. Portanto, o
acesso à internet está incluído nesta lei.
Em relação à parte que cuida da comunicação, a lei prevê a eliminação de
barreiras na comunicação e procura estabelecer alternativas técnicas que dei-
xem os sistemas de comunicação e sinalização acessíveis.
A acessibilidade é um assunto não tão recente. No Brasil, a questão tomou
maior discussão em 1981, quando este foi chamado de Ano Internacional dos
Portadores de Deficiência pela ONU. Em 1982, a ONU criou o Programa Ação
Mundial para Pessoas com Deficiência, no qual prevalecia que as pessoas nes-
tas condições têm o mesmo direito que os demais cidadãos às mesmas oportu-
nidades e usarem em condições de igualdade.
Em 1985 o Brasil publicou a primeira norma técnica que trata de questões
relacionadas com o tema, a NBR 9050/1985. Porém trata de adequação das edi-
ficações e do mobiliário urbano à pessoa deficiente. Nesta norma, acessibilida-
de é: “possibilidade e condição de alcance, percepção e entendimento para a
utilização com segurança e autonomia de edificações, espaço, mobiliário, equi-
pamento urbano e elementos”.

107. 106 •
capítulo 5
Portanto, cada definição, seja na lei ou na norma, enfoca que acessibilidade
significa alcançar alguma coisa com autonomia, mesmo que seja assistida.
Em relação à internet, a preocupação com o conteúdo acessível começou
pelo W3C, em 1999, por meio da iniciativa chamada Web Assistive Iniciative
(WAI). Nesta ocasião, foi elaborado o primeiro documento para auxiliar os de-
senvolvedores de páginas a tornarem suas páginas mais acessíveis. Este docu-
mento foi o Web Content Acessibility Guidelines. O WAI foca em três linhas:
Navegadores para web
players de multimídia
tecnologias assistivas
Veja as figuras a seguir com exemplos de lugares e situações acessíveis:

Figura 5.1  – Balanço acessível.

108. capítulo 5 • 107
Figura 5.2  – Piscina acessível.
©©WIKIPEDIA
Figura 5.3  – Piso tátil.

109. 108 •
capítulo 5
5.2 Acessibilidade na web e sua importância
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 várias
empresas membro e uma equipe dedicada integralmente, junto com o público,
desenvolvem padrões para a web. O objetivo principal do W3C é obter todo o
potencial da web.
Sem dúvida, o W3C é a principal referência e detentora das principais dire-
trizes para se estabelecer um padrão de construção de sites e demais elemen-
tos. Portanto, as diretrizes e guias do W3C serão usadas neste capítulo como
referência para a acessibilidade na web.
O W3C possui padrões relacionados com a acessibilidade. Por meio de seu
site (WORLD WIDE WEB CONSORTIUM, 2015), podemos perceber que a aces-
sibilidade é um assunto prioritário para eles. Segundo o site, a web é funda-
mentalmente projetada para ser usada por todas as pessoas, não importando o
hardware, software, língua, cultura, localização ou habilidade física ou mental.
A acessibilidade na web é importante porque nos faz lembrar que grande
parte da população que consome materiais que estão na web tem algum tipo de
deficiência e isto pode significar perda ou limitação de oportunidades da vida
em comunidade em condições de igualdade com as demais pessoas.
Segundo (FERNANDES e GODINHO, 2013), o uso de acessibilidade no de-
senvolvimento de páginas e aplicações na web não se caracteriza uma limita-
ção, mas, ao contrário, os elementos de acessibilidade, com seus padrões e
regras, tornam os documentos mais flexíveis, abrangentes e fáceis de se usar.
MULTIMÍDIA

Este link mostra um vídeo sobre acessibilidade na web para celebrar o Dia Internacional
das Pessoas com Deficiência, que ocorreu em 3 de dezembro de 2012 e encerrou a Virada
Inclusiva na escultura da Mão, no Memorial da América Latina, em São Paulo.
https://goo.gl/saZc1L
O W3C tem escritório no Brasil, o W3C Brasil, o qual desenvolve ações lo-
cais para o desenvolvimento dos padrões web. Eles têmum grupo de trabalho

110. capítulo 5 • 109
exclusivo para os padrões de acessibilidade, o qual lançou uma cartilha com 7
fascículos que serve para orientar as pessoas sobre a importância da acessibi-
lidade na web.
Segundo a cartilha (W3C, 2011), a acessibilidade na web está compatível com
os conceitos que vimos sobre acessibilidade e é uma atividade complexa. E suge-
re a consideração de alguns aspectos para abordar a complexidade do problema:
• A importância, abrangência e a universalidade da web: a web é um ambien-
te multimídia, com várias possibilidades e muito abrangente. Segundo o W3C,
uma pessoa com deficiência deveria acessar a web em melhores condições, pois
já tem dificuldades em acessar as mesmas informações no mundo físico.
• Reciprocidade: a acessibilidade não é apenas uma questão de “mão úni-
ca”, ou seja, podemos ser induzidos a pensar que as pessoas são apenas recep-
toras. Segundo o W3C, a pessoa com deficiência também contribui para a web.
Logo, quanto mais pessoas puderem acessar, mais a web terá contribuições.
• Multiplicidade e diversidade de fatores envolvidos: a acessibilidade na
web é alcançada considerando-se uma série de fatores segundo o W3C:
o Conteúdo;
o Navegadores, ou agente do usuário;
o Tecnologia assistida: é a tecnologia usada por pessoas com deficiên-
cia e mobilidade reduzida;
o Conhecimento do usuário para o uso da web;
o Desenvolvedores e usuários;
o Ferramentas da autoria;
o Ferramentas de avaliação.
Segundo a cartilha, a acessibilidade na web é “permitir que qualquer pes-
soa, usando qualquer tecnologia de navegação, visite qualquer site e obtenha
completo entendimento das informações contidas nele, além de ter total ha-
bilidade de interação”. Ou seja, ter um ambiente que não seja diferente para
qualquer tipo de pessoa.
CURIOSIDADE
Um exemplo de acessibilidade e de que não só a web, mas a tecnologia em geral, é usada
em prol da acessibilidade é a vida do físico Stephen Hawking, um dos mais consagrados
cientistas da atualidade.

111. 110 •
capítulo 5

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

5.3 A Web acessível
A partir de uma web acessível, vários cenários que poderiam ser impossíveis
de ocorrer se tornam viáveis, não só para pessoas com deficiência, mas para
qualquer categoria de usuário. Segundo a cartilha, podem ocorrer esses casos:
• Uma pessoa cega usando um leitor de telas pesquisando o site da
Receita Federal;
• Um usuário cego e sem braços 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;

112. capítulo 5 • 111
• Um usuário com paralisia cerebral e com dificuldades motoras usando o
computador com um dedo só e navegando nas redes sociais;
• Um usuário com deficiência motora usando um mouse adaptado fazendo
compras pela internet;
• Uma pessoa tetraplégica usando um ponteiro na cabeça procurando in-
formações sobre células-tronco em sites especializados;
• Um usuário com deficiência intelectual fazendo exercícios pela web para
melhorar sua comunicação;
• E outros.
Os exemplos anteriores são apenas poucas das situações que podem ocor-
rer envolvendo acessibilidade e web. Portanto, precisamos encontrar mecanis-
mos para ajudar nessas situações.
5.4 Componentes essenciais para acessibilidade
na Web
Segundo o WAI (Web Acessibility Iniciative) (W3C-WAI, 2013), a acessibilidade
na web depende de vários componentes trabalhando conjuntamente e melho-
rias em componentes específicos. Estes componentes incluem:
CONTEÚDO
A informação em uma página da web ou em uma apli-
cação incluindo:
o informação natural como textos, imagens e
sons
o código ou marcação que define estrutura,
apresentação, etc.
NAVEGADORES,
PLAYERS DE MÍDIA
E outros agentes de usuário
TECNOLOGIA
ASSISTIDA
Em alguns casos, leitores de tela, teclados alternativos,
software de rastreamento, etc.

113. 112 •
capítulo 5
CONHECIMENTO DO
USUÁRIO
Experiências e em alguns casos, estratégia adaptativas
usando a web.
DESENVOLVEDORES
Projetistas, programadores, autores, etc., incluindo
desenvolvedores com deficiências e usuários que con-
tribuem com conteúdo.
SOFTWARES DE
AUTORIA
Softwares que criam web sites.
FERRAMENTAS DE
AVALIAÇÃO
Ferramentas de avaliação de acessibilidade na web,
validadores de HTML, validadores de CSS, etc..

Figura 5.5  – Como os componentes estão relacionados.
A figura 5.5 mostra como os componentes citados estão relacionados: os de-
senvolvedores normalmente usam softwares de autoria e ferramentas de ava-
liação para criar conteúdo. Os usuários usam navegadores, players de mídia,
tecnologias assistivas ou outros agentes de usuário para acessar e interagir com
o conteúdo.

114. capítulo 5 • 113
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 conteúdo impresso
da página é 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.

115. 114 •
capítulo 5

Figura 5.8  – Leitor de Braille.
5.4.1  Interdependência entre componentes
Existe uma interdependência significativa entre os componentes, ou seja, os
componentes devem trabalhar conjuntamente, com o objetivo de deixar a web
acessível. Por exemplo, para um texto alternativo nas imagens:
CONCEITO
Texto alternativo nas imagens: em HTML, na tag para imagens existe uma opção 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 não vê a
imagem, o texto alternativo é impresso no leitor de tela.
ESPECIFICAÇÕES TÉCNICAS
Estabelecem textos alternativos (por exemplo,
o HTML define o atributo alt na tag img)
GUIAS DA WAI
A WAI apresenta alguns guias que definem
como implementar os textos alternativos para
acessibilidade nos diferentes componentes.

116. capítulo 5 • 115
DESENVOLVEDORES
Fornecem as palavras apropriadas para se
colocar no texto alternativo.
FERRAMENTAS DE AUTORIA
Possibilitam, facilitam e promovem o texto
alternativo em uma página.
FERRAMENTAS DE
AVALIAÇÃO
São usadas para ajudar a checar quais textos
alternativos existem.
AGENTES DE USUÁRIO
Fornecem interface humana para o texto
alternativo.
TECNOLOGIAS ASSISTIVAS
Fornecem os textos alternativos em várias
modalidades.
USUÁRIOS
Sabem como pegar o texto alternativo do
agente do usuário e/ou tecnologia assistiva.
5.4.2  O ciclo de implementação
Quando as características de acessibilidade são implementadas efetivamente
em um componente, possibilita a implantação nos outros componentes .
Conteúdo
Conteúdo
Ferramentas de autoria
Navegadores, Players de mídia
Tecnologias assistivas

117. 116 •
capítulo 5
• Quando os navegadores, players de mídia, tecnologias assistivas e outros
agentes de usuário suportam uma característica acessível, os usuários ficam
mais propensos a demandar esta característica, e os desenvolvedores ficam
mais propensos a implementá-la no conteúdo.
• Quando os desenvolvedores querem implementar um recurso de acessi-
bilidade em seu conteúdo, eles são mais propensos a exigir que a sua ferramen-
ta de criação torne a implementação mais fácil.
• Quando as ferramentas de criação tornam um recurso fácil de ser im-
plementado, os desenvolvedores ficam mais propensos a implementá-lo em
seu conteúdo.
• Quando um recurso de acessibilidade é implementado no conteúdo, de-
senvolvedores e usuários ficam mais propensos a exigir que os agentes de co-
mecem a apoiá-lo.
Se um componente de acessibilidade não é implementado em um compo-
nente, há uma pequena motivação para o outro componente implementá-lo
quando não resulta em uma experiência do usuário acessível. Por exemplo, de-
senvolvedores não são propensos a implementar uma característica de acessi-
bilidade que as ferramentas de autoria não suportam e que a maioria dos nave-
gadores ou tecnologia assistiva não 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 esforço e não é tão 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.
• Usuários podem ter mais trabalho para compensar alguma falta de su-
porte de acessibilidade nos navegadores, players de mídia e tecnologia as-
sistiva e falta de acessibilidade de conteúdo, por exemplo, usando diferentes
navegadores ou tecnologias assistivas para superar as diferentes questões
de acessibilidade.
No entanto, na maioria dos casos, esses “work-arounds” não são implemen-
tados, e o resultado ainda é uma fraca acessibilidade. Além disso, por vezes, um
suporte ruim de acessibilidade em um componente não pode ser razoavelmen-
te ultrapassado por outros componentes, e o resultado é a inacessibilidade, o

118. capítulo 5 • 117
que torna impossível para algumas pessoas com deficiência a usar um determi-
nado site, página ou recurso.
5.5 Projeto e desenvolvimento de um site
acessível
A elaboração de um site acessível é um assunto bastante amplo. A amplitude
está relacionada com alguns fatores, como se o site vai ser acessível por real-
mente se importar com pessoas portadoras de necessidade especial ou se é por
alguma imposição da empresa ou até mesmo para se atingir um novo público.
Vamos estudar alguns pontos técnicos que podem ajudá-lo a criar um site
acessível 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 são 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 codificação da pá-
gina. No caso do Brasil, a codificação “ISO-8859-1” caracteriza os caracteres em
português e também auxiliam o leitor de tela com a correta leitura das palavras
presentes na página.
Outra tag importante é a <title>. Ela pode gerar uma certa polêmica, pois
também é usada pelo leitor de tela para poder informar o título da página, mas
também é usada pelos indexadores a posicionar melhor a página nos mecanis-
mos de pesquisa. Sendo assim, ocorre uma dúvida. O que é melhor: prezar pela
acessibilidade ou por uma melhor colocação nos mecanismos de pesquisa? O
melhor é escrever um título que seja claro e coerente sem excluir as palavras-
-chave da página.

119. 118 •
capítulo 5
O atributo rel da tag <link> também é usado nos sites acessíveis. Quando
arquivos externos são linkados à página, é importante para os leitores de tela
determinarem o tipo de arquivo ou página externa que está sendo vinculado.
O normal deste atributo é usar o valor “stylesheet”, utilizado para os arquivos
CSS. Os valores também podem ser “content”, indicando conteúdo, “prev” para
páginas anteriores e “next” para as páginas posteriores.
A tag <body> também precisa de alguma atenção. Já comentamos que, na
tag <img>, o atributo alt é importante para os leitores de tela substituírem as
imagens pelas suas descrições. Portanto, usar textos intuitivos nestas descri-
ções, inclusive para o caso de a imagem não 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 usuário ao clicar no link, e não somen-
te com a descrição “clique aqui”, por exemplo. Outros atributos importantes
para a acessibilidade relacionados com essa tag são o tabindex e o accesskey. O
primeiro atributo faz com que uma ordem seja estabelecida nos elementos da
página, 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 não precisará ouvir todas as linhas de código
dos scripts da página.
Existem outros fatores técnicos que podem estar presentes em um site
acessível. Mostramos alguns; outros podem ser incorporados mediante as re-
comendações do W3C, como veremos no próximo tópico.
5.5.1  Recomendações do W3C
O W3C tem um documento (W3C, 2008) quel contém recomendações e diretri-
zes para se construir um site acessível. Ao seguir estas recomendações, o con-
teúdo acessível poderá atingir um maior número de pessoas com deficiências,
das mais variadas formas.
O documento está dividido em 4 princípios e cada um contendo uma ou
mais diretrizes. Os princípios são:

120. capítulo 5 • 119
5.5.1.1  Princípio 1 - Percepção
Os componentes de informação e interface de usuário devem estar presen-
tes para os usuários em modos que eles possam visualizá-los.
As diretrizes deste princípio são:
ALTERNATIVAS
EM TEXTO
Forneça alternativas em texto para qualquer conteúdo não
textual, de forma que ele possa ser transformado em outros
formatos necessários para as pessoas, como letras grandes,
braile, fala e linguagem mais simples.
MÍDIA
BASEADA NO
TEMPO
Forneça alternativas para este tipo de mídia. Esta diretriz refe-
re-se a mídias que são transmitidas principalmente em tempo
real. O W3C recomenda que algum tipo de texto acompanhe
o áudio ou o vídeo transmitido.
ADAPTAÇÃO
Crie conteúdo que possa ser apresentado em formas diferen-
tes (por exemplo em um layout mais simples) sem perder a
informação ou estrutura.
DISTINGUÍVEL
Torne mais fácil para o usuário ver e ouvir o conteúdo, incluin-
do as separações entre o primeiro e segundo plano. A cor não
é usada como o único recurso visual. Use alternativas.
5.5.1.2  Princípio 2: Operável
Os componentes de interface do usuário e navegação devem estar operáveis.
As diretrizes para este princípio são:
TECLADO
ACESSÍVEL
Faça toda a funcionalidade do site ser acessada pelo teclado.

121. 120 •
capítulo 5
TEMPO
DISPONÍVEL
Forneça tempo suficiente para os usuários lerem e usarem o
conteúdo.
CONVULSÕES
Não criae conteúdo de uma forma que pode causar convul-
sões. Algumas pessoas com distúrbios convulsivos podem ter
uma convulsão desencadeada por algum conteúdo piscando
na tela. Muitas pessoas desconhecem ter este problema até
que elas tenham de fato.
NAVEGÁVEL
Forneça modos para auxiliar os usuários a navegarem pelo
site, procurar conteúdo, e determinar onde eles estão.
5.5.1.3  Princípio 3: Entendível
A informação e a interface com o usuário devem ser entendíveis.
As diretrizes para este princípio são:
LEGÍVEL Faça com que o texto seja lido e entendido sem problemas.
PREVISÍVEL
Faça com que as páginas apareçam e funcionem de maneira
previsível.
ASSISTÊNCIA
DE ENTRADAS
Ajudar os usuários a evitar e corrigir erros.
5.5.1.4  Princípio 4: Robusto
O conteúdo deve ser robusto o suficiente para que ele possa ser interpretado
de forma confiável por uma grande variedade de agentes de usuário, incluindo
tecnologias assistivas.

122. capítulo 5 • 121
Este princípio só tem uma diretriz:
COMPATÍVEL
Maximizar a compatibilidade com agentes de usuários atuais e
futuros, incluindo as tecnologias assistivas.
Uma vez que verificamos como podemos criar sites acessíveis, é interessan-
te também testar e validar a acessibilidade do site.
5.5.2  Métodos 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 métodos auto-
máticos sejam vantajosos no sentido de rapidez, eles não conseguem atender
a todos os requisitos de acessibilidade. A maneira direta é quando o próprio
usuário verifica a acessibilidade, e a maneira automática é quando usamos al-
gum software para isso.
A figura 5.9 mostra os selos dos validadores automáticos do W3C. O W3C
tem algumas ferramentas que conectam no site-alvo e fazem uma varredura
buscando algum tipo de inconformidade com os padrões usados. Caso não
haja inconformidade o site pode colocar o selo específico no seu conteúdo e
indicar que o site passou nos padrões do W3C.
Na figura 5.9 temos os seguintes selos de validação:
HTML 4.01
Valida o site de acordo com os padrões da linguagem
HTML 4.01.
XHTML 1.0 E 1.1
Valida o site de acordo com os padrões de XHTML nas
versões 1.0 e 1.1.
WAI-A, WAI-AA,
WAI-AAA
Valida o site de acordo com os padrões de acessibilida-
de do W3C, nível A, duplo A, triplo A respectivamente,
que compatibilizam com as Prioridades 1, 2 e 3 das
diretrizes do W3C para acessibilidade.

123. 122 •
capítulo 5
RSS VALID
Valida o site de acordo com os padrões estabelecidos
para as notificações RSS.
AAA APROVADOValidador brasileiro do guia Acessibilidade Brasil.
W3C CSS Valida o site de acordo com os padrões de CSS do W3C.
Alguns sites podem passar pela validação do código XHTML e não passar
na validação do CSS. E assim por diante. Veja que no caso de acessibilidade,
temos, além do validador do W3C, o validador brasileiro.
XML
1.0
CSS
XHTML
1.0
XHTML
1.0
HTML
4.01
WAI -A
WCAG 1.0
WAI -AA
WCAG 1.0
WAI-AAA
WCAG 1.0
VALID
RSS
ACESSIBILIDADE BRASIL
AAAAAA
APROVADO
Figura 5.9  – Selos de validadores do W3C.

124. capítulo 5 • 123
Quanto à validação humana, esta deve ajudar a verificar a clareza da lingua-
gem, o bom uso dos equivalentes em texto e a facilidade de navegação e usabi-
lidade, por exemplo.
Com relação aos métodos automáticos, são eles, segundo (QUEIROZ, 2008):
1. Usar uma ferramenta de acessibilidade automatizada, porém algu-
mas questões de acessibilidade não são possíveis de serem verificadas por um
software e necessitam ser verificadas pela forma humana.
2. Validar a sintaxe do código.
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 deficiências visuais.
5. Usar um navegador só de texto como o Lynx ou um emulador. Esses na-
vegadores não carregam os scripts em javascript e imagens forçando o usuário
a usar principalmente o teclado.
6. Utilizar vários 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 vários navegadores, recentes e mais antigos.
8. Usar um leitor de tela e verificar se ele lê a página corretamente, utilizar
um ampliador de tela, tela de dispositivo móvel.
9. Usar corretores ortográficos 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 usuários são muito importantes para a validação geral do site,
tanto na parte de conteúdo quanto na parte dos recursos de acessibilidade pre-
sentes no site e facilidade de uso.
Lembre-se, que o selo de validação é importante. Não 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.

125. 124 •
capítulo 5
Outros, colocam os selos de validação com o site não validado. Se não for va-
lidado, não coloque! Não há desculpa para não validar um site. E tenha sempre
um cuidado especial com a validação de acessibilidade.
GLOSSÁRIO
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 importância do W3C para a web?
04. Acesse o site www.acessibilidadelegal.com. Quais os elementos de acessibilidade en-
contrados no site?
05. Sites acessíveis são necessariamente feios, sem cores e imagens?
REFLEXÃO
Parece que a situação que vivemos nos remete a consumir cada vez mais, e isso se reflete
na internet. Os sites estão cada vez mais interativos e chamativos. Temos tecnologias super
legais, como os bancos de dados não relacionais, novos frameworks na área de front end,
como AngularJS, NodeJs, Material Design, e várias outras tecnologias que encantam quem
desenvolve para web. Porém, na questão da acessibilidade em relação a todo esse avan-
ço, será que quem promove todas essas tecnologias, bem como incita outros a usarem e
consumirem, também está preocupado com o acesso daqueles que portam algum tipo de
necessidade especial?

126. capítulo 5 • 125
LEITURA
Sobre acessibilidade, é praticamente obrigatória a leitura dos documentos do W3C sobre
padrões 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 vários materiais: http://www.acessibilidadelegal.com/
• Acessibilidade virtual: http://acessibilidade.bento.ifrs.edu.br/acessibilidade-web.php
• Site do Maujor: site do Maurício Samy Silva, com muitos materiais sobre desenvolvimento
para web e vários sobre acessibilidade: http://www.maujor.com/w3c/introwac.html
REFERÊNCIAS BIBLIOGRÁFICAS
FERNANDES, J.; GODINHO, F. Publicações. Unidade Acesso, 2013. Disponivel em: <http://www.
acessibilidade.gov.pt/publicacoes#manuais>. Acesso em: 1 jul. 2015.
POPLADE, T. Como tornar seu site acessível. Tableless, 2010. Disponivel em: <http://tableless.
com.br/como-tornar-seu-website-acessivel/>. Acesso em: 01 jul. 2015.
QUEIROZ, M. A. D. Métodos 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 critérios básicos
para a promoção da acessibilidade das pessoas portadoras de deficiência ou com mobilidade reduzida,
e dá outras providências. Disponível em: <http://www.planalto.gov.br/ccivil_03/leis/L10098.htm>.
Acesso em 29/07/2015.

127. 126 •
capítulo 5
GABARITO
Capítulo 1
01. O conceito de tecnologia, ou computação, vestível não é novo. Em 1998, Steve Mann de-
finiu como: “Um computador vestível é um computador que está alocado no espaço pessoal
do usuário, controlado pelo usuário, e possui constância de operação e interação, ou seja,
está sempre ligado e sempre acessível. Mais notavelmente, ele é um dispositivo que está
sempre com o usuário, e permite que o usuário 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 usuário, principalmente para ser mais fácil, 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 critérios 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 usuário. Na norma existem três métricas 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 avança, assim
como a aproximação do homem com o computador, ocorre uma necessidade de interfaces
com melhor utilização. Estamos cada vez mais dependentes da tecnologia e, consequente-
mente, mais exigentes com a qualidade dela. Nós não queremos perder tempo quando os
recursos de tecnologia são usados. É justamente no estudo da relação homem X máquina,
que se encontra a Interação Humano-Computador (IHC).
05. O JQuery e outras bibliotecas semelhantes são fontes de recursos e facilidades que
permitem que um programador crie interfaces mais interativas com o usuário de uma manei-
ra mais produtiva e eficiente. Por meio de poucas linhas de código em javascript, é possível
criar animações e efeitos na tela que fazem com que o usuário tenha uma experiência mais
agradável ao usar os softwares.

128. capítulo 5 • 127
06. O Windows teve várias versões: 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 relação à interface, podemos dizer
que ela acompanhou a tecnologia que estava disponível na época de cada versão. A primeira
versão, em 1985, já usava mouse e dispunha de cores, porém as janelas não podiam ser
sobrepostas, o que veio a acontecer em 87 na versão 2.0. Nesta versão ocorreu a possibili-
dade de minimizar e maximizar as janelas. Na versão 3, bastante popular, a palavra Windows
começou a fazer mais sentido, pois as janelas se tornaram mais independentes, inclusive os
programas DOS podiam ser executados dentro de uma janela específica. Nesta versão era
possível usar o som e cd-rom. Na versão 3.1, apareceram as fontes true-type, as quais permi-
tiram que o Windows tornasse uma plataforma para editoração eletrônica. No Windows 95,
a barra Iniciar e a barra de ferramentas apareceram, além de ter o recurso plug and play. Na
versão 98, os botões de avançar e voltar no Internet Explorer apareceram. No Windows XP, a
principal diferença na sua interface foi sua grande melhoria em relação à versão anterior. No
Vista, a interface ficou mais bonita e agradável e tinha os recursos de transparência e gad-
gets na área de trabalho. O Windows 7 trouxe poucas mudanças visuais em relação ao Vista.
O Windows 8 foi uma tentativa radical de mudança na interface e suportava as telas sensíveis
ao toque e eliminou, assim, o botão iniciar, o que foi bastante criticado. Nesta versão apare-
ceram os tiles. A versão 8.1 foi uma resposta às críticas visuais recebidas na versão anterior.
Capítulo 2
01. Sim, pois, com a popularização dos smartphones e tablets, a exigência por maior usabi-
lidade e interação tem ficado cada vez maior, fazendo com que os critérios sejam usados e
disponíveis para todas as plataformas.
02. Quando vamos instalar algum software no Windows, geralmente existe um assistente
que mostra informações ao usuário sobre a instalação. O usuário tem várias opções de con-
figurações e possibilidades de avançar e voltar suas ações.
03. Os termos estão muito relacionados. O agrupamento/distinção por itens faz parte de
um critério ergonômico chamado condução, que tem como objetivo auxiliar o usuário na
execução das tarefas, conduzindo-o na interação com o sistema. Por meio do agrupamento
por itens, que atua na disposição espacial dos itens na tela, o usuário tem a sensação e o
conforto de visualizar os itens agrupados e entender como o sistema pode ser compreendido
e usado.

129. 128 •
capítulo 5
04. Um software que segue as normas sobre IHC tem muitas vantagens em relação a ou-
tras que não se preocupam com isso, porque, de certa forma, há uma garantia de que ele foi
desenvolvido pensando na melhor interação e usabilidade do usuário. Sendo assim, seu uso
e compreensão será mais garantido do que outros que não se preocupam com isso. Quando
um software não tem boa interação com o usuário, o risco de ele não ser usado ou ser mal
aproveitado é muito grande.
05. A metáfora de interação é um conjunto de regras e técnicas que têm como objetivo fazer
uma comparação entre o mundo real e a interação com um computador. Por exemplo: no
mundo real, temos alavancas que aumentam ou diminuem algum tipo de nível (ou aceleração
em um avião por exemplo) – nas interfaces temos os sliders, muito comuns em aplicativos
gráficos.
06. Outro exemplo: em alguns videogames existem plataformas que o jogador usa para
dançar ou fazer movimentos que são representados no jogo.
Outro exemplo: o jogo Guitar Hero pode ser jogado com um joystick normal de um vídeo
game ou ser jogado com um controle especial que imita uma guitarra.
Capítulo 3
01. O maior stakeholder de um sistema de caixa para um supermercado é o próprio gerente
do supermercado. De outra forma, o gerente financeiro também é um stakeholder do sistema.
02. Como foi visto no texto, os seguintes tópicos são os principais no design centrado
no usuário:
a) Foco em usuários e tarefas;
b) Teste de uso do produto e medidas empíricas;
c) Design interativo.
03. Veja UM exemplo neste link: http://www.storyboardthat.com/userboards/markpra-
veenk/hotel-room-reservation2
Existem vários na internet.
04. Porque o usuário pode não querer esperar até o final do desenvolvimento do produto e
achar que o protótipo já é suficiente para as suas necessidades.

130. capítulo 5 • 129
05. O Bootstrap é um framework escrito em Javascript muito usado atualmente e é utili-
zado principalmente para o desenvolvimento de sites responsivos e aplicativos móveis pela
web. A intenção é tornar o desenvolvimento front-end mais rápido e fácil. O Bootstrap tem
o código aberto, o que permite ao programador estender suas funcionalidades e criar no-
vas bibliotecas.
Capítulo 4
01. Sugestões para o ipod:
a) Facilidade de uso
b) Acesso às músicas
c) Acesso às configurações
d) Conexão com outros dispositivos
Sugestões para o site de vendas
a) Visualização do carrinho de compras
b) Visualização dos detalhes dos produtos
c) Comparação de produtos
d) Rastreamento do pedido
e) Busca de produtos eficiente
02. Respostas:
a) Sem dúvida, as heurísticas ajudam a avaliar qualquer site com base nos critérios
que elas propõem.
b) Sim, uma vez entendida as heurísticas, o usuário passará a examinar e avaliar o site
de uma maneira mais crítica, para encontrar elementos que estão de acordo com
as heurísticas.
03. Vamos avaliar o site http://pt.aliexpress.com/br_home.htm
a) Apesar de ter muitas opções para o usuário, o excesso de informação pode confun-
dir ou mesmo dificultar a localização de uma determinada opção.
Apesar de ser um site de compras, pode ser difícil de encontrar um determinado produto
devido à grande quantidade de opções presentes na tela inicial.
Alguns produtos são traduzidos literalmente do idioma original, o que pode dificultar a
pesquisa de produtos.

131. 130 •
capítulo 5
b) Sim. De posse dos conhecimentos das heurísticas, a pré-avaliação de um site será
feita usando as heurísticas, até mesmo de uma maneira inconsciente.
c) Usar menos heurísticas terá como consequência uma avaliação mais maleável e
pode deixar o site mais propício a não conformidades de interface, de acordo com
os padrões e heurísticas estudados. As heurísticas devem ser usadas e combinadas
de acordo com o que será avaliado e trazer o melhor resultado e avaliação para
o usuário.
04. A descrição abaixo do botão de ferramenta é chamada de Hint ou Dica. Estas dicas
ajudam o usuário a guardar a função daquele botão ou ferramenta; sendo assim, ele acaba
se acostumando com as funções e as localiza de maneira mais rápida.
Capítulo 5
01. Tecnologia assistiva é um termo que engloba vários conceitos, como produtos, recursos,
metodologias, estratégias, práticas e serviços que têm como objetivo promover a funcionali-
dade , relacionada à atividade e participação de pessoas com deficiência, incapacidades ou
com mobilidade reduzida, a fim de torná-las autônomas, independentes, com melhor qualida-
de de vida e incluídas socialmente.
02. A Web Acessibility Iniciative (WAI), é uma divisão do W3C (World Wide Web Consortium)
responsável por criar guias, estratégias e recursos para tornar a web acessível para pessoas
com deficiência.
03. O W3C é uma entidade que cria padrões 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 questões relati-
vas à acessibilidade não são pensadas no desenvolvimento de sites, e assim várias pessoas
que possuem deficiências e incapacidades ficariam excluídas do acesso e uso da web.
04. São encontradas as seguintes características:
a) Aumento e diminuição do tamanho da fonte;
b) Navegação pelo teclado;
c) Há uma descrição da estrutura do site;
d) Impressão somente do conteúdo das páginas;
e) Uso do atributo alt nas imagens.

132. capítulo 5 • 131
f) Design adaptado para diferentes resoluções de tela;
g) Uso de vários navegadores para o acesso.
05. Não. O site www.acessibilidadelega.com é um exemplo. Possui um design clean, limpo
e agradável.

133. 132 •
capítulo 5
ANOTAÇÕES

134. capítulo 5 • 133
ANOTAÇÕES

135. 134 •
capítulo 5
ANOTAÇÕES

136. capítulo 5 • 135
ANOTAÇÕES

137. 136 •
capítulo 5
ANOTAÇÕES