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
7.
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!
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.
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.
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”?
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.
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-
cativodoaparelhoeseusbotõeseteclado.Emavaliaçõesfeitasporalunosdadis-
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.
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.
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.
AergonomiaemIHCtemcomoobjetivonãosófacilitaravidadousuário,mas
tambémadaptarossoftwareseaformadeinteraçãoàscapacidadesdosusuá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.
Sendoassim,eladevesercapazdeseadaptarsegundoaspreferênciasdosusuá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.
AsnormastiverammaiorimpactoapartirdanormaISO9241eficarammais
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.
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?
• Comointegrarasatividadesdeprojetocomoutrosmodelosdeciclodevida?
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
edefinidos.
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
Anorma9241-210:2010tambémestabeleceque“odesigncentradonousuá-
rioéumaabordagemparaodesenvolvimentodesistemasinterativosquefocam
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
Detalhesdastarefas
Conteúdodastarefas
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ÇÃO Outra 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.