Livro-Texto PROJETO DE INTERFACE COM USUÁRIO

Prévia do material em texto

Autor: Prof. Luciano Soares de Souza
Colaborador: Prof. Eduardo de Lima Brito
 
Projeto de Interface 
com o Usuário
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Professor conteudista: Luciano Soares de Souza
Mestre em Engenharia de Produção pela Universidade Paulista (UNIP) e bacharel em Ciência da Computação pela 
mesma universidade. É coordenador do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da 
UNIP, modalidades presencial e EAD, no qual leciona as disciplinas Engenharia de Software, Projeto de Interface com 
o Usuário, Princípios de Sistemas de Informação, dentre outras, e orienta o Projeto Integrado Multidisciplinar – PIM.
Na Universidade Paulista também atua como Gerente de Integração de Sistemas. Possui mais de vinte anos 
de experiência com Tecnologia da Informação, atuando nas áreas de Desenvolvimento de Sistemas, Engenharia de 
Software, Interação Humano-Computador e Automação Industrial.
Possui mais de oito anos de experiência como professor e coordenador.
© Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por qualquer forma e/ou 
quaisquer meios (eletrônico, incluindo fotocópia e gravação) ou arquivada em qualquer sistema ou banco de dados sem 
permissão escrita da Universidade Paulista.
Dados Internacionais de Catalogação na Publicação (CIP)
S729p Souza, Luciano Soares de.
Projeto de interface com o usuário. / Luciano Soares de Souza. 
– São Paulo: Editora Sol, 2015.
128 p., il.
Nota: este volume está publicado nos Cadernos de Estudos e 
Pesquisas da UNIP, Série Didática, ano XXI, n. 2-028/15, ISSN 1517-9230
1. Interação humano-computador. 2. Engenharia de Software. 3. 
Projeto de Interface. I. Título. 
CDU 681.3 
U501.35 – 19
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Prof. Dr. João Carlos Di Genio
Reitor
Prof. Fábio Romeu de Carvalho
Vice-Reitor de Planejamento, Administração e Finanças
Profa. Melânia Dalla Torre
Vice-Reitora de Unidades Universitárias
Prof. Dr. Yugo Okida
Vice-Reitor de Pós-Graduação e Pesquisa
Profa. Dra. Marília Ancona-Lopez
Vice-Reitora de Graduação
Unip Interativa – EaD
Profa. Elisabete Brihy 
Prof. Marcelo Souza
Prof. Dr. Luiz Felipe Scabar
Prof. Ivan Daliberto Frugoli
 Material Didático – EaD
 Comissão editorial: 
 Dra. Angélica L. Carlini (UNIP)
 Dra. Divane Alves da Silva (UNIP)
 Dr. Ivan Dias da Motta (CESUMAR)
 Dra. Kátia Mosorov Alonso (UFMT)
 Dra. Valéria de Carvalho (UNIP)
 Apoio:
 Profa. Cláudia Regina Baptista – EaD
 Profa. Betisa Malaman – Comissão de Qualificação e Avaliação de Cursos
 Projeto gráfico:
 Prof. Alexandre Ponzetto
 Revisão:
 Rose Castilho
 Juliana Mendes
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Sumário
Projeto de Interface com o Usuário 
APRESENTAÇÃO ......................................................................................................................................................7
INTRODUÇÃO ...........................................................................................................................................................7
Unidade I
1 INTERAÇÃO HUMANO-COMPUTADOR (IHC) ...........................................................................................9
1.1 Interface e interação ..............................................................................................................................9
1.2 Usabilidade .............................................................................................................................................. 10
1.3 Comunicabilidade ................................................................................................................................. 13
1.4 Acessibilidade ......................................................................................................................................... 13
1.5 Retorno sobre o investimento em Tecnologia da Informação e Comunicação.......... 15
1.5.1 Retorno sobre o investimento em usabilidade ........................................................................... 16
2 FUNDAMENTOS TEÓRICOS .......................................................................................................................... 18
2.1 Engenharia Cognitiva e Engenharia Semiótica ........................................................................ 18
Unidade II
3 ENGENHARIA DE SOFTWARE E INTERAÇÃO HUMANO-COMPUTADOR .................................... 24
3.1 Visão da Engenharia de Software e visão da Interação Humano-Computador ........ 24
3.2 Modelos de ciclo de vida de software tradicionais da Engenharia de Software ........ 27
3.2.1 Modelo em Cascata ............................................................................................................................... 29
3.2.2 Modelo Incremental .............................................................................................................................. 30
3.2.3 Modelo Espiral .......................................................................................................................................... 30
3.2.4 Prototipagem ............................................................................................................................................ 31
3.3 Modelo de ciclo de vida de design de interface de usuário ............................................... 33
3.3.1 Modelo Estrela ......................................................................................................................................... 33
3.3.2 Engenharia de Usabilidade ................................................................................................................. 34
3.3.3 Projeto centrado no usuário .............................................................................................................. 36
3.3.4 Design Participativo ............................................................................................................................... 36
3.3.5 Customização de um modelo de ciclo de vida destinada a projeto de interface para 
dispositivos móveis ........................................................................................................................................... 37
4 A USABILIDADE E AS NORMAS ................................................................................................................. 38
4.1 A usabilidade e a NBR ISO 9241-11 .............................................................................................. 38
4.2 A usabilidade e a NBR ISO/IEC 9126-1 ........................................................................................ 40
4.3 A norma ISO 13407 (Processo de Projeto Centrado no Usuário para 
Sistemas Interativos) .................................................................................................................................. 42
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade III
5 PROCESSO DE DESIGN DE INTERFACE DE USUÁRIO – IDENTIFICAR E ANALISAR 
O CONTEXTO DE USO ......................................................................................................................................... 49
5.1 Identificar e analisar o contexto de uso ..................................................................................... 49
5.1.1 Definição do escopo do projeto ........................................................................................................ 50
5.1.2 Técnicas de coleta de dados ............................................................................................................... 57
5.1.3 Análise do usuário, tarefas e ambiente de trabalho ................................................................. 60
5.1.4 Reengenharia das práticas de trabalho .........................................................................................69
5.1.5 Requisitos e metas de usabilidade ................................................................................................... 70
6 PROCESSO DE PROJETO DE INTERFACE DE USUÁRIO – PROJETAR E CONSTRUIR ............... 72
6.1 Projeto conceitual ................................................................................................................................ 72
6.2 Construir .................................................................................................................................................. 75
6.2.1 Protótipos................................................................................................................................................... 75
6.2.2 Storyboard ................................................................................................................................................. 83
6.3 Projeto físico .......................................................................................................................................... 87
Unidade IV
7 PROCESSO DE PROJETO DE INTERFACE COM O USUÁRIO – AVALIAR ...................................... 93
7.1 Importância das avaliações .............................................................................................................. 93
7.2 Inspeção de usabilidade ..................................................................................................................... 94
7.2.1 Avaliação heurística ............................................................................................................................... 94
7.3 Teste de usabilidade ............................................................................................................................ 95
7.3.1 Planejamento do teste de usabilidade ........................................................................................... 96
7.4 Escala de Usabilidade do Sistema – System Usability Scale (SUS) .................................. 97
7.5 Integração e implantação final ..................................................................................................... 99
8 DIRETRIZES PARA PROJETOS DE INTERFACE COM O USUÁRIO ..................................................100
8.1 As regras de ouro de Mandel .........................................................................................................100
8.2 As oito regras de ouro de Shneiderman ...................................................................................102
8.3 Dez heurísticas de usabilidade para projeto de interface de usuário ...........................104
8.4 Mais princípios de projeto de interface com o usuário ......................................................105
8.5 Design responsivo ..............................................................................................................................107
7
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
APRESENTAÇÃO
O objetivo da disciplina Projeto de Interface com o Usuário é apresentar ao aluno os conceitos 
básicos da área de Interação Humano-Computador (IHC), as bases teóricas, os modelos e métodos para 
projeto e avaliação de interfaces de usuário, mostrando de que modo os conceitos apresentados neste 
livro-texto podem ser utilizados nos projetos de software, visando à produção de sistemas interativos 
com elevados níveis de usabilidade.
Este material foi desenvolvido em unidades inter-relacionadas contendo exemplos e cenários 
que permitam ao aluno visualizar e compreender aplicações práticas. Portanto, para atingir o 
objetivo esperado, é recomendado que o aluno inicie seus estudos a partir da primeira unidade e, 
sequencialmente, avance até a última, assim poderá acumular o conhecimento necessário para a 
correta compreensão da disciplina.
Inicialmente, são apresentados os conceitos da área de IHC, os quais serão largamente 
utilizados durante todo o livro-texto. Em seguida, a visão da IHC e da Engenharia de Software, 
bem como seus modelos de processos no desenvolvimento de sistemas interativos. Essas visões 
são apresentadas e comparadas com o objetivo de se extrair as melhores práticas de cada 
área. Um estudo sobre as normas NBR e ISO e suas relações com a usabilidade também é 
apresentado neste livro-texto.
Progredindo nos estudos, é apresentado, e largamente discutido, o processo de desenvolvimento 
de interface de usuário, desde o levantamento de requisitos até o projeto físico da interface. Por 
fim, a importância de avaliação e testes de usabilidade durante todo o processo de desenvolvimento 
é discutida, e um conjunto de diretrizes para construção de sistemas interativos com usabilidade 
é apresentado.
Bons estudos!
INTRODUÇÃO
A interface com o usuário tem importância fundamental em sistemas interativos. Ela possibilita 
a comunicação entre o ser humano e a máquina. Portanto, nos projetos de software que envolvam a 
interação do usuário com o sistema, a interface pode ser responsável pela aceitação deste. No entanto, 
não se pode mais pensar em interfaces de usuário sem levar em consideração o ser humano que vai 
utilizá-la.
Muitos autores já defendem que a interface com o usuário é o elemento mais importante de um 
sistema interativo. Uma interface bem-projetada deve ser de uso fácil, dando ao usuário a possibilidade de 
extrair todo o poder computacional de uma aplicação e utilizá-la de forma confortável, proporcionando 
uma interação transparente entre o ser humano e o computador. Em contrapartida, uma interface 
malprojetada pode se transformar em um ponto decisivo na rejeição de um sistema, independentemente 
de qual seja sua funcionalidade, podendo provocar também a falha de uma aplicação que tenha sido 
bem-projetada e bem-desenvolvida (SOUZA; COSTA; SPINOLA, 2006).
8
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Uma boa estética de uma interface e as modernas tecnologias não implicam um sistema de fácil uso. 
Da mesma forma, deixar o projeto da interface para o final do processo de desenvolvimento, como um 
acabamento para o sistema, dificilmente resultará numa interface de usuário com qualidade.
Para se produzir interfaces com qualidade, boas intenções não são o suficiente. Métodos e 
técnicas adequadas, apresentadas neste livro-texto, precisam ser utilizados nos projetos de interface 
com o usuário.
9
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
Unidade I
1 INTERAÇÃO HUMANO-COMPUTADOR (IHC)
Adotado em meados dos anos 1980, o termo Interação Humano-Computador (IHC) abrange 
todos os aspectos relacionados com a interação de usuários e computadores, e não somente design de 
interfaces (ROCHA; BARANAUSKAS, 2003).
Segundo Granollers (2003), IHC é uma disciplina que estuda todos os fatores relacionados à interação 
do ser humano e do computador com o objetivo de desenvolver ou melhorar a segurança, a utilidade, 
a eficácia e a usabilidade de produtos interativos baseados em computador. Portanto, IHC é mais que 
apenas conceitos tradicionais de usabilidade e projeto de interface (ROZANSKI; HAAKE, 2003).
Em 1992, a Association for Computing Machinery (ACM), por meio do Grupo de Interesse 
Especial em Interação Humano-Computador (ACM SIGCHI), definiu IHC como “uma disciplina que 
se preocupa com o design, avaliação e implementação de sistemas computacionais interativos 
para uso humano e com o estudo dos principais fenômenos que os cercam” (ACM SIGCHI, 1992, 
p. 5, tradução nossa).
Segundo Rozanski e Haake (2003), a IHC tem importância fundamental no ambiente de computação. 
Sua compreensão e a aplicação de seus princípios apresentarão impactos positivos na interação dos 
usuários com dispositivos computacionais.
1.1 Interface e interação
A interface é responsável por proporcionar a comunicação entre o ser humano (usuário) e o hardware 
e o software de um sistema computacional(IEEE, 1990).
Entretanto, segundo Rocha e Baranauskas (2003), este conceito evoluiu e levou à inclusão de 
aspectos cognitivos e emocionais do usuário durante a comunicação. Desse modo, não se pode pensar 
em interfaces sem levar em consideração o ser humano que vai utilizá-la, ou seja, interface e interação 
são conceitos que não podem ser estabelecidos ou analisados de forma independente.
Para Marcus (2002), interface com o usuário é o meio para facilitar a comunicação entre humanos 
ou entre um humano e um artefato por meio do uso do computador. A interface, que incorpora aspectos 
físicos e comunicativos de entrada e saída ou atividade interativa, inclui hardware e software, que 
incluem aplicações, sistemas operacionais e redes.
No desenvolvimento de um projeto de software que envolve a interação homem-computador, a 
interface com o usuário é fundamental para o sucesso do sistema (SOMMERVILLE, 2003). Segundo 
10
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade I
Pressman (2006), a interface com o usuário pode ser considerada o elemento mais importante de um 
sistema ou produto baseado em computador.
Usuário
Ação
Interface
Sistema
Aplicação
Interpretação
Figura 1 – Processo de interação humano-computador
Segundo Souza et al. (1999, p. 4), “interação é um processo que engloba as ações do usuário sobre 
a interface de um sistema, e suas interpretações sobre as respostas reveladas por esta interface”. Para 
Leite (1998, p. 30), de forma mais sucinta, interação “é o processo de comunicação que ocorre entre um 
usuário e uma aplicação de software”.
Portanto, neste processo de interação usuário-sistema, a interface é responsável por viabilizar e 
facilitar os processos de comunicação entre o usuário e a aplicação. É por meio dela que os usuários têm 
acesso às funções das aplicações (SOUZA et al., 1999). 
De acordo com Souza, Costa e Spinola (2006, p. 3), ”a interface com o usuário tem importância 
fundamental em sistemas interativos, possibilitando a comunicação entre o usuário e o sistema, de 
modo que, quanto maior for o nível de usabilidade da interface, mais fácil será a comunicação”.
Para Orth (2005), interface é um sistema de comunicação que possui um componente físico, formado 
por hardware e software, no qual o usuário percebe e manipula, e um componente conceitual, no qual 
o usuário interpreta, processa e raciocina.
Deste modo, segundo Souza et al. (1999, p. 3), “a interface é tanto um meio para a interação 
usuário-sistema, quanto uma ferramenta que oferece os instrumentos para este processo comunicativo”, 
ou seja, um sistema de comunicação.
1.2 Usabilidade
Usabilidade é um conceito que se refere à qualidade da interação usuário-computador proporcionada 
pela interface de um sistema computacional.
A norma NBR ISO 9241-11 estabelece que usabilidade é a “medida na qual um produto pode ser 
usado por usuários específicos para alcançar objetivos específicos com eficácia, eficiência e satisfação 
11
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
em um contexto específico de uso” (ABNT, 2002, p. 3). Para a norma NBR ISO/IEC 9126-1, usabilidade é 
um atributo de qualidade de software e é definida como a “capacidade do produto de software de ser 
compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas” 
(ABNT, 2003, p. 7).
A usabilidade de um sistema depende de vários aspectos (SOUZA et al., 1999) e pode ser 
mensurada formalmente e compreendida intuitivamente como sendo o grau de facilidade de 
uso de um produto para um usuário que ainda não esteja familiarizado com o uso deste produto 
(TORRES; MAZZONI, 2004).
 Observação
Diante das definições apresentadas, percebe-se que a usabilidade não 
tem uma única definição. Entretanto, está diretamente relacionada aos 
usuários, suas tarefas e ao contexto de uso. Posteriormente, este livro-
texto apresentará o relacionamento entre usabilidade e as normas NBR ISO 
9241-11 e NBR ISO/IEC 9126-1.
Para Nielsen (1993), a usabilidade é um dos aspectos que podem influenciar a 
aceitabilidade de um produto e se aplica a todos os aspectos do sistema com os quais a 
pessoa pode interagir, incluindo os procedimentos de instalação e manutenção, e deve 
ser sempre medida relativamente a determinados usuários executando determinadas 
tarefas.
Para que a usabilidade possa ser avaliada e medida, Nielsen (1993) a define em função 
destes cinco atributos:
a) Aprendizagem: o sistema deve ser de fácil aprendizado para que o usuário possa 
começar a utilizá-lo rapidamente.
b) Eficiência: o sistema deve ser eficiente no sentido de que uma vez que o usuário 
aprenda a utilizá-lo ele o faça com alta produtividade.
c) Memorização: o sistema deve ser de fácil lembrança, ou seja, ao passar um determinado 
período sem utilizar o sistema o usuário pode utilizá-lo novamente sem ter que 
aprender tudo novamente.
d) Erros: a taxa de erros deve ser baixa. Erros de extrema gravidade não devem ocorrer. 
Ao cometer algum erro, o usuário deve ter a possibilidade de recuperar o sistema 
para o estado imediatamente anterior ao erro.
e) Satisfação: os usuários devem gostar do sistema. Ele deve ser agradável de ser utilizado 
para que as pessoas se sintam satisfeitas com o seu uso.
12
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade I
A usabilidade não está relacionada somente à interação, mas também às características 
de ajuda, documentação de usuário e instruções de instalação (FERRÉ et al., 2001).
Fonte: Souza, Costa e Spinola (2006, p. 3-4).
A principal razão de se aplicar técnicas de usabilidade no desenvolvimento de software é 
aumentar a satisfação e a eficiência do usuário, e, consequentemente, sua produtividade. Além 
disso, a usabilidade está ganhando importância em um mundo no qual os usuários são menos 
especialistas em computador e não podem gastar muito tempo aprendendo como os sistemas 
trabalham (FERRÉ et al., 2001).
Em contrapartida, interfaces ruins podem causar diversos problemas aos usuários. Ao utilizar uma 
interface sem usabilidade, o usuário pode:
• diminuir sua produção;
• precisar de mais tempo para a realização de suas tarefas;
• cometer mais erros;
• sentir insatisfação com o sistema;
• precisar de mais tempo para aprender a utilizar o sistema;
• necessitar de diversos treinamentos;
• não se lembrar do funcionamento de recursos pouco utilizados;
• não aprender a usar todas as funcionalidades do sistema.
 Lembrete
IHC é uma disciplina que estuda todos os fatores relacionados à 
interação do ser humano e do computador. Seu objetivo é desenvolver 
ou melhorar a segurança, utilidade, eficácia e usabilidade de produtos 
interativos baseados em computador.
Segundo Nielsen (1992), boas intenções não são o bastante para assegurar a usabilidade de produtos 
interativos de computador. Desenvolvedores e projetistas devem incluir técnicas de usabilidade no 
processo de desenvolvimento de software.
13
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
1.3 Comunicabilidade
Um sistema interativo é – ou deveria ser – resultado de um processo de projeto no qual um projetista 
estabelece uma visão (interpretação) sobre os usuários, seus objetivos, o domínio e o contexto de uso e 
toma diversas decisões sobre como apoiá-los no desenvolvimento de suas tarefas. Para o usuário usufruir 
melhor de todo o apoio computacional, o projetista precisa remover as “barreiras” da interface que 
impedem o usuário de interagir, bem como tornar o uso fácil e comunicar corretamente ao usuário as suas 
concepções, sua lógica e suas intenções ao conceber o sistema interativo (BARBOSA; SILVA, 2011).
A comunicabilidade de uma interface é a sua propriedade de transmitir a visão (as intenções e 
os princípios de interação que guiaram o projeto)do projetista sobre a lógica (o funcionamento) da 
interface ao usuário. Se o usuário conseguir uma boa compreensão da lógica do projetista contida na 
aplicação, aumentarão as possibilidades de se construir interfaces mais eficientes e eficazes. Uma boa 
comunicabilidade permite que o usuário tenha um modelo mental compatível com o do projetista e 
significa que o usuário pode tirar melhor proveito do sistema.
 Observação
O modelo mental do usuário é formado pelas representações e 
expectativas que ele cria sobre o funcionamento do sistema.
Portanto, se o usuário entender corretamente a lógica adotada pelo projetista ao construir a 
interface, ou seja, se o usuário entender para que serve, como funciona e qual a vantagem de se utilizar 
o sistema, aumentarão suas chances de fazer um bom uso dele.
1.4 Acessibilidade
Durante a interação com a interface de um sistema computacional, o usuário emprega sua habilidade 
motora para agir sobre os dispositivos de entrada e seus sentidos de visão, audição e tato, além de sua 
capacidade de percepção, para identificar as respostas do sistema emitidas pelos dispositivos de saída. 
Além disso, ele utiliza sua capacidade cognitiva, de interpretação e de raciocínio para compreender as 
respostas do sistema (BARBOSA; SILVA, 2011).
As interfaces dos sistemas computacionais ainda são dependentes do bom funcionamento de 
nossos sistemas perceptual, cognitivo e motor. Por isso, as pessoas portadoras de necessidades 
especiais podem encontrar muitas dificuldades para ter acesso à informação nesses sistemas. 
Algumas pessoas podem não ser capazes de ver, ouvir, mover-se ou processar certos tipos de 
informação e, consequentemente, podem não ser capazes de operar o teclado ou o mouse¸ por 
exemplo (ROCHA; BARANAUSKAS, 2003).
Portanto, a interface dos sistemas computacionais não pode impor barreiras ao usuário durante o 
processo de interação. Os desenvolvedores precisam garantir que o projeto abranja mecanismos que 
permitam o fácil acesso pelos usuários portadores de necessidades especiais.
14
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade I
 Saiba mais
O World Wide Web Consortium (W3C) conta com o Web Accessibility 
Initiative (WAI), grupo responsável por estratégias, diretrizes e recursos para 
tornar a web acessível a pessoas com deficiência. Acesse a página inicial do 
grupo em:
<http://www.w3.org/WAI/>.
Além disso, o W3C apresenta um conjunto de diretrizes que têm como 
objetivo tornar o conteúdo da rede mais acessível.
W3C (WORLD WIDE WEB CONSORTIUM). Diretrizes de acessibilidade 
para conteúdo web (WCAG) 2.0. Tradução: Everaldo Bechara. São Paulo: 
W3C, 2014. Disponível em: <http://www.w3.org/Translations/WCAG20-pt-
br/>. Acesso em: 24 fev. 2015.
No Brasil, a acessibilidade em sites da administração pública passou a ser obrigatória a partir do 
Decreto n° 5.296, de 2 de dezembro de 2004. Este decreto torna obrigatória a acessibilidade em portais 
e sítios eletrônicos da administração pública brasileira na rede mundial de computadores para o uso das 
pessoas com deficiência, fornecendo-lhes pleno acesso às informações disponíveis (BRASIL, 2004).
Para garantir que sites ofereçam conteúdo de forma clara e acessível a todos, o governo elaborou o 
Modelo de Acessibilidade em Governo Eletrônico (e-MAG). Ele reúne um conjunto de recomendações a 
serem consideradas pelos desenvolvedores de conteúdo para que o processo de acessibilidade dos sites 
e portais do governo brasileiro seja conduzido de forma padronizada e de fácil implementação.
 Saiba mais
O Modelo de Acessibilidade em Governo Eletrônico (e-MAG) pode ser 
encontrado em:
<http://emag.governoeletronico.gov.br/>.
O governo eletrônico disponibiliza, de forma gratuita, para toda a sociedade, software e 
documentos que auxiliam e orientam profissionais na construção, adequação, avaliação e correção de 
páginas, sítios e portais da internet, garantindo o controle da navegação e o pleno acesso dos usuários 
aos conteúdos e serviços do governo, independentemente das suas capacidades físico-motoras e 
perceptivas, culturais e sociais.
15
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
 Saiba mais
Orientações para o desenvolvimento de software acessível também 
podem ser encontradas no website da IBM Human Ability and Accessibility 
Center:
IBM. Understanding acessibility. [s.d.]. Disponível em: <http://www-03.
ibm.com/able/access_ibm/disability.html>. Acesso em: 24 fev. 2015.
1.5 Retorno sobre o investimento em Tecnologia da Informação e 
Comunicação
Embora a avaliação da relação custo-benefício dos investimentos em Tecnologia da Informação e 
Comunicação (TIC) tenha grande importância no momento de decisão dos investimentos nas empresas, 
segundo Foina (2013), a maioria dos gestores da área de Tecnologia da informação (TI) tem pouca 
formação financeira e não dá muita atenção a essa questão. Consequentemente, muitas vezes eles 
recebem várias negativas para seus pedidos de recursos. 
Normalmente, a maior parte dos investimentos em TIC traz benefícios para outras áreas da empresa, 
e não para a própria área. Portanto, ao tentar fazer uma relação de custo-benefício, o gestor de TI deve 
mostrar os benefícios que sua área apresenta para as outras áreas da organização.
Como exemplo, Foina (2013) cita o projeto de implantação de um sistema de gestão integrada 
(ERP – Enterprise Resource Planning), que pode custar mais de 1 milhão de reais e durar vários 
anos. Usualmente, o orçamento para a realização desse projeto sai da área de TI, no entanto a 
empresa terá diversos benefícios, como a redução do quadro de pessoal em diversas áreas, a 
redução do tempo de compras, de pagamento e de aprovação de despesas, a redução dos riscos 
financeiros e trabalhistas, o aumento do valor das ações da empresa na Bolsa de Valores pela 
adoção de normas internacionais de controle interno (implementadas nos modernos sistemas de 
ERP comerciais), dentre outros. Entretanto, depois da implantação do sistema, a conta fica para 
a área de TI, que passou a ter um aumento de custos com a manutenção das licenças envolvidas 
com o novo sistema (licenças de software, banco de dados, servidores e demais aplicativos), com 
taxas públicas decorrentes do aumento de atividades da área (energia elétrica, comunicação etc.) 
e com o aumento do quadro de pessoal para manter o novo sistema.
Os recursos financeiros destinados à TIC devem ser tratados como investimentos, e não como 
gastos. Os ganhos desses investimentos são para a organização em sua totalidade, seja na forma de 
melhorias dos produtos ou serviços prestados aos seus clientes, seja na forma de redução de pessoal 
e outros custos. O gestor de TI deve ter conhecimento e habilidades para mostrar à alta administração 
da empresa que seus altos custos de operação são decorrentes dos sistemas que dão suporte às 
diversas áreas da organização e que seus custos próprios são uma pequena parcela do total.
16
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade I
Ao solicitar um investimento, o gestor de TI deve apresentar detalhes financeiros mensuráveis do 
projeto. A explicitação da relação custo-benefício para os projetos e as demandas de TIC é um poderoso 
e essencial indicador para a tomada de decisão de investimento.
O Retorno do Investimento (ROI – Return on Investment), utilizado para medir o resultado financeiro 
de um investimento, é um importante indicador utilizado pelas empresas para tomada de decisões sobre 
investimentos financeiros e pode ser utilizado pelos gestores de TI na justificativa para a solicitação de 
recursos financeiros.
 Saiba mais
Não faz parte do escopo deste livro apresentar informações 
mais detalhadas sobre o ROI. Um estudo mais aprofundado pode ser 
encontrado em:
WERNKE, R. Gestão financeira: ênfase em aplicações e casos nacionais. 
São Paulo:Saraiva, 2008.
1.5.1 Retorno sobre o investimento em usabilidade
Boa parte dos gerentes de desenvolvimento de software enxerga os custos com usabilidade como 
gastos adicionais e acredita que empregar práticas de usabilidade nos projetos demande muito tempo. 
Esse cenário dificulta ainda mais convencer a alta administração da empresa a investir em usabilidade, 
uma vez que os investimentos em TIC já são vistos como gastos.
Segundo Smith e Reinersten (1991), sabendo que os primeiros 10% do processo de desenvolvimento 
de software, quando as principais decisões de design são tomadas, podem determinar 90% do custo e 
do desempenho de um produto, o emprego de técnicas de usabilidade nesse estágio inicial pode ajudar 
a manter o produto alinhado com os objetivos da empresa.
Usabilidade se obtém da realização de atividades sistemáticas de engenharia de usabilidade ao longo 
do ciclo de desenvolvimento do projeto e, segundo Bias e Mayhew (1994), o retorno sobre o investimento 
gera muitos benefícios para produtos desenvolvidos tanto para venda quanto para uso interno:
• Retorno sobre o investimento – Interno:
— aumento da produtividade do usuário;
— redução de erros do usuário;
— redução dos custos de treinamento;
17
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
— economia obtida em fazer alterações no início do ciclo de vida do projeto;
— redução de suporte ao usuário;
• Retorno sobre o investimento – Externo:
— aumento de vendas;
— redução dos custos de suporte/atendimento ao cliente;
— economia obtida em fazer alterações no início do ciclo de vida do projeto;
— redução dos custos de prestação de treinamento (em caso de treinamento oferecido pelo 
vendedor da empresa).
Para Pressman (2009), dentre os muitos benefícios mensuráveis derivados de um sistema usável 
estão também o aumento da satisfação do cliente, vantagem competitiva, melhores críticas na mídia, 
melhor propaganda boca a boca, custos de documentação reduzidos e menor probabilidade de litígio 
com clientes insatisfeitos.
Para tentar avaliar o custo total com usabilidade, Nielsen (2003) fez um levantamento em mais 
de 860 projetos que adotaram práticas de usabilidade. O estudo mostrou que os custos com práticas 
de usabilidade ficaram entre 8% e 13% dos orçamentos dos projetos. Com base nessas constatações 
e informações de outras pesquisas, Nielsen (2003) concluiu que para aplicar as melhores práticas em 
usabilidade o custo seria em torno de 10% do orçamento destinado ao projeto. No entanto, ressalta que 
o custo com usabilidade não aumenta linearmente conforme o tamanho do projeto. Um determinado 
projeto que seja dez vezes maior que outro, por exemplo, normalmente requer apenas quatro vezes mais 
investimento em práticas de usabilidade.
Infelizmente, o investimento de 10% do orçamento do projeto em atividades de usabilidade 
nem sempre garante ter um ROI mensurável financeiramente. Diferentemente do que acontece em 
e-commerce, no qual depois de algumas melhorias de usabilidade as vendas dobraram, por exemplo, a 
usabilidade trará satisfação do usuário, uso mais eficiente etc. Neste caso, é mais difícil converter o ROI 
em algo mensurável. No entanto, qual é o valor do aumento da satisfação do cliente?
Exemplo de retorno de investimento em usabilidade
Uma determinada empresa possui cem operadores em call center trabalhando seis horas por 
dia, com tempo médio de atendimento de três minutos. O diretor da empresa, com o objetivo de 
aumentar o número de atendimentos, contrata uma empresa especializada em usabilidade para 
analisar o processo de atendimento dos atendentes. Depois de analisar o processo por alguns 
dias, a empresa especializada propõe uma alteração na interface do software que registra os 
dados dos atendimentos.
18
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade I
Durante o desenvolvimento da nova interface, a empresa responsável envolveu alguns atendentes para 
conhecer o modo pelo qual eles trabalham, ouvir suas opiniões e avaliar os protótipos da nova interface.
Depois de implantada a nova interface do software responsável por registrar os atendimentos, o 
resultando foi de uma economia média de 20 segundos no tempo de um atendimento.
Mensurando o ganho
• Situação antes das alterações na interface:
Cem operadores em call center trabalhando seis horas por dia, com tempo médio de atendimento 
de três minutos.
= 100 x (6 x 60 / 3) = 100 x 160 = 12.000 atendimentos por dia.
• Situação depois das alterações na interface:
Modificação na interface gerando economia de 20 s no tempo de atendimento.
= 100 x (6 x 3600 / 160) = 100 x 135 = 13.500 atendimentos por dia.
Portanto, com uma economia de 20 segundos em média para cada atendimento, a empresa passou 
de 12.000 para 13.500 atendimentos por dia. 
2 FUNDAMENTOS TEÓRICOS
A interface de usuário deve ser projetada para evitar erros de comunicação entre os seres humanos e 
os sistemas. Portanto, o ser humano precisa se considerado no processo de desenvolvimento de interface, 
e isso é muito importante.
2.1 Engenharia Cognitiva e Engenharia Semiótica
O processo de projeto de interfaces com o usuário tem seus fundamentos teóricos advindos da 
Engenharia Cognitiva e da Engenharia Semiótica, é centrado no usuário e tem grande influência dos 
processos adotados pela Engenharia de Software.
Rocha e Baranauskas (2003, p. 107) apresentam a relação da Engenharia Cognitiva com o processo 
de projeto de interface:
A Engenharia Cognitiva conceitua interface pelos seus “dois lados”: o do sistema 
e o do ser humano. Estágios de execução e percepção (humanos) mediam entre 
representações físicas (do sistema) e psicológicas (do ser humano). Mecanismos 
de entrada/saída (do sistema) mediam entre representações psicológicas e 
físicas. Mudamos a interface, pelo lado do sistema, através de design apropriado. 
19
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
Muda-se a interface pelo lado humano, através de aprendizado e experiência. [...] 
Design de interface no paradigma da Engenharia Cognitiva, portanto, relaciona 
três tipos de conhecimento: de design, programação e tecnologia; de pessoas, 
princípios do funcionamento mental, comunicação e interação e conhecimento 
da tarefa. Somente o módulo da interface deve estar em comunicação com o 
usuário: do ponto de vista do usuário a interface “é” o sistema.
As autoras também apresentam a relação da Engenharia Semiótica com o processo de projeto 
de interface:
Na Engenharia Semiótica, a interface é entendida como um artefato de 
metacomunicação, isto é, a interface é composta por mensagens enviadas 
do designer para o usuário, e cada mensagem, por sua vez, pode enviar 
e receber mensagens do usuário. Nesse sentido, a interface cumpre dois 
papéis: (1) comunicar a funcionalidade da aplicação (o que a interface 
representa, que tipos de problemas está preparada para resolver) e o modelo 
de interação (como se pode resolver um problema); (2) possibilitar a troca 
de mensagens entre o usuário e a aplicação. Na Engenharia Semiótica o 
foco está na comunicação unidirecional e indireta do designer para com os 
usuários. O designer cumpre um papel comunicativo explícito ao utilizar a 
interface para dizer algo ao usuário. Por sua vez, o usuário cumpre os papéis 
de agente da interação e de receptor da comunicação indireta do designer. 
(ROCHA; BARANAUSKAS, 2003, p. 152).
Para se projetar interfaces com qualidade, é fundamental a correta compreensão das bases teóricas 
envolvidas na interação humano-computador. A usabilidade (proveniente das teorias de base cognitiva) 
e a comunicabilidade (um postulado da Engenharia Semiótica), segundo Agner (2011), são conceitos 
diretamente ligados à qualidade das interfaces de usuário.
 Lembrete
O ser humano precisa ser considerado no processo de desenvolvimentode interface de usuário.
 Saiba mais
Um estudo mais aprofundado sobre Engenharia Cognitiva e Engenharia 
Semiótica pode ser encontrado em: 
ROCHA, H. V.; BARANAUSKAS, M. C. C. Design e avaliação de interfaces 
humano-computador. Campinas: Nied/Unicamp, 2003.
20
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade I
 Resumo
Vimos que a Interação Humano-Computador (IHC) é uma disciplina que 
se preocupa tanto com projeto, avaliação e implementação de sistemas 
computacionais interativos para uso do ser humano quanto com o estudo 
dos fatores relacionados à interação do ser humano e do computador. As 
corretas compreensão e aplicação dos princípios de IHC são fundamentais 
para a produção de interfaces de usuário com elevados níveis de usabilidade.
Aprendemos que a interface de usuário tem importância fundamental 
em sistemas interativos. Ela é responsável por proporcionar a comunicação 
entre o ser humano e o computador, e é por meio dela que os usuários têm 
acesso às funções das aplicações. A interação é o processo de comunicação 
que ocorre entre um usuário e o software. Quanto maior for o nível de 
usabilidade da interface, mais fácil será a comunicação. Portanto, os 
projetistas não podem mais pensar em interfaces de usuário sem levar em 
consideração o ser humano que vai utilizá-las.
Aprendemos também que, nos projetos de software que envolvem a 
interação humano-computador, a interface de usuário é fundamental para 
o sucesso do sistema e pode ser considerada o elemento mais importante 
de um sistema ou produto baseado em computador.
A usabilidade é um conceito que se refere à qualidade da interação 
usuário-computador proporcionada pela interface de um sistema 
computacional. Observamos que, embora não tenha uma única definição, 
a usabilidade de um sistema depende de vários fatores, e seu conceito está 
diretamente relacionado aos usuários, às suas tarefas e ao contexto de uso. 
A usabilidade é um dos aspectos que podem influenciar a aceitabilidade 
de um produto. Desenvolvedores e projetistas devem aplicar técnicas de 
usabilidade no desenvolvimento de software para assegurar a usabilidade 
nos sistemas interativos, resultando na satisfação e na eficiência do usuário 
e, consequentemente, numa maior produtividade. 
Vimos também que a comunicabilidade de uma interface é a 
sua propriedade de transmitir a visão do projetista sobre a lógica de 
funcionamento da interface ao usuário. Uma boa comunicabilidade 
possibilita ao usuário ter um modelo mental compatível com o modelo do 
projetista. Portanto, se o usuário entender corretamente a lógica adotada 
pelo projetista ao construir a interface, aumentarão suas chances de fazer 
um bom uso daquele sistema.
21
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
A interface de usuário de um sistema computacional não pode impor 
barreiras, durante o processo de interação, aos usuários portadores de 
necessidades especiais. Desenvolvedores e projetistas precisam garantir 
que o projeto de interface abranja mecanismos que permitam o fácil acesso 
(acessibilidade) desses usuários.
Embora muitas vezes os investimentos em usabilidade sejam vistos 
como gastos, é possível mensurar o ganho desse investimento. Usabilidade 
se obtém da realização de atividades sistemáticas de engenharia de 
usabilidade ao longo do ciclo de desenvolvimento do projeto. Aplicando 
corretamente as técnicas de usabilidade, o retorno sobre o investimento 
em usabilidade gera muitos benefícios para produtos desenvolvidos tanto 
para venda quanto para uso interno da empresa.
O processo de projeto de interfaces com o usuário tem seus fundamentos 
teóricos advindos da Engenharia Cognitiva e da engenharia semiótica, é 
centrado no usuário e tem uma grande influência dos processos adotados 
pela Engenharia de Software. Portanto, para se projetar interfaces com 
qualidade, é fundamental a correta compreensão das bases teóricas 
envolvidas na interação humano-computador. 
Entendemos, portanto, que a interface de usuário deve ser projetada para 
evitar erros de comunicação entre os seres humanos e os sistemas. Para isto, o ser 
humano precisa ser considerado no processo de desenvolvimento de interface. 
 Exercícios
Questão 1. (Enade 2014) Conforme a norma ISO 9241, a usabilidade é definida como a capacidade 
que um sistema interativo de software oferece a seus usuários, em um contexto específico de operação, 
para a realização de tarefas de maneira eficaz, eficiente e agradável. Com fundamento nesse conceito, 
uma empresa deseja medir a satisfação dos consumidores de seus produtos e, para isso, desenvolverá 
um sistema de software. A equipe de desenvolvimento do sistema de software elencou os requisitos 
listados na tabela a seguir.
Código do requisito Descrição do requisito
RQ1 Cada produto da empresa deverá ser avaliado, por um usuário, com um valor numérico inteiro entre -5 e 5.
RQ2 Cada transação do sistema com o banco de dados para registrar uma avaliação de um produto deve ser realizada em um tempo inferior a 20 segundos.
RQ3 Cada operação do usuário deverá ser realizada em até três telas.
RQ4 O sistema deve ter interfaces com sistemas legados.
RQ5 O usuário consumidor irá se identificar pelo código do número de Cadastro de Pessoa Física (CPF).
22
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade I
Entre os requisitos listados na tabela, o código do que se refere à usabilidade é:
A) RQ1.
B) RQ2.
C) RQ3.
D) RQ4.
E) RQ5.
Resposta correta: alternativa C.
Análise das alternativas
A) Alternativa incorreta.
Justificativa: o RQ1 está relacionado a critérios de avaliação definidos com base em requisitos 
funcionais não relacionados à usabilidade.
B) Alternativa incorreta.
Justificativa: o RQ2 endereça performance no acesso ao banco de dados, estando relacionado a 
temas de infraestrutura e gestão de performance.
C) Alternativa correta.
Justificativa: o RQ3 define a forma como o usuário irá interagir com o sistema, referindo-se, portanto, 
à usabilidade.
D) Alternativa incorreta.
Justificativa: o RQ4 é oriundo do contexto no qual o sistema é inserido, o que determina sua dependência 
frente aos demais sistemas integrantes desse contexto. O RQ4 nada tem a ver com a usabilidade.
E) Alternativa incorreta.
Justificativa: o RQ5 é determinado pela forma como as tabelas e as visualizações do banco de dados 
são estruturadas e não está, portanto, relacionado à usabilidade.
Questão 2. (Enade 2008) Além do acesso a páginas html, a internet tem sido usada cada vez mais 
para a cópia e troca de arquivos de músicas, filmes, jogos e programas. Muitos desses arquivos possuem 
direitos autorais e restrições de uso. Considerando o uso das redes ponto-a-ponto para a troca de 
23
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
arquivos de músicas, filmes, jogos e programas na internet, a quem cabe a identificação e o cumprimento 
das restrições de uso associados a esses arquivos?
A) Aos programas de troca de arquivo.
B) Aos usuários.
C) Ao sistema operacional.
D) Aos produtores dos arquivos.
E) Aos equipamentos roteadores da internet.
Resolução desta questão na plataforma.
24
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade II
Unidade II
3 ENGENHARIA DE SOFTWARE E INTERAÇÃO HUMANO-COMPUTADOR
A Engenharia de Software tem o foco voltado para o produto e seu processo de desenvolvimento. A 
Interação Humano-Computador tem o foco voltado à interação do ser humano e da máquina. As duas 
áreas, no entanto, estabelecem métodos e processos de desenvolvimento de sistemas interativos. 
3.1 Visão da Engenharia de Software e visão da Interação Humano-Computador
Existe uma diferença fundamental entre as abordagens adotadas pelos engenheiros desoftware e 
pelos especialistas em Interação Humano-Computador. Segundo Brown (1996), enquanto os engenheiros 
de software têm o foco voltado para o produto e seu processo (centrado em sistema), os especialistas 
em Interação Humano-Computador têm o foco mais direcionado aos aspectos de interação do ser 
humano e da máquina (centrado no usuário). Em sua pesquisa, Brown (1996) relata que as metodologias 
de Engenharia de Software são úteis para especificar e construir os aspectos funcionais de um sistema 
de software. No entanto, especialistas em Interação Humano-Computador mostram uma compreensão 
melhor do usuário, priorizando um entendimento aprofundado das características deste usuário e uma 
consciência das tarefas que um usuário tem de executar. Especialistas de Interação Humano-Computador 
testam ideias de design em usuários reais e usam técnicas de avaliação formais, substituindo o design 
da interface guiado pela intuição.
 Lembrete
A Engenharia de Software surgiu com o objetivo de melhorar o 
processo de desenvolvimento de software, bem como a qualidade do 
produto de software.
Segundo Rozanski e Haake (2003), Interação Humano-Computador (IHC) tornou-se um componente 
essencial para todos os profissionais de computação. Cientistas da computação e engenheiros de 
software também precisam entender os princípios e conceitos de IHC; ainda que não sejam os principais 
profissionais responsáveis pela compreensão do usuário e pelo projeto da interface, trabalharão com os 
profissionais responsáveis. 
 Lembrete
Interação Humano-Computador (IHC) é uma disciplina que se preocupa 
com o design, a avaliação e a implementação de sistemas computacionais 
25
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
interativos para uso humano e com o estudo dos principais fenômenos que 
os cercam (ACM SIGCHI, 1992).
Contudo, as duas áreas propõem o desenvolvimento de sistemas interativos de forma sistemática, 
definindo modelos de ciclo de vida, métodos e técnicas (SILVA et al., 2004).
Paula, Barbosa e Lucena (2005) alertam para a importância da comunicação entre as áreas de IHC 
e Engenharia de Software. Os projetistas de IHC precisam levar suas preocupações e decisões de forma 
clara aos engenheiros de software e vice-versa, para que, juntos, cheguem à solução final. Ainda segundo 
os autores, ambas as áreas tratam da qualidade do produto final, no entanto sob perspectivas e focos 
diferentes. A IHC focaliza interação e design de interface do usuário, levando em conta as necessidades, 
os valores e as expectativas dos usuários, visando à qualidade de uso da solução projetada. A Engenharia 
de Software tem foco no projeto e na especificação da funcionalidade interna do sistema, bem como em 
sua arquitetura, visando à qualidade estrutural do produto de software final.
O quadro a seguir apresenta um resumo das práticas tradicionais da Engenharia de Software e 
as melhores práticas no desenvolvimento centrado no usuário da IHC, para o desenvolvimento de 
sistemas interativos.
Quadro 1 – Práticas em Engenharia de Software e projeto centrado no usuário
Práticas tradicionais no desenvolvimento de software Melhores práticas no desenvolvimento centrado no usuário
Desenvolvimento dirigido à tecnologia. Dirigido ao usuário.
Foco em componentes de sistema. Foco na solução para o usuário.
Contribuição individual. Equipe multidisciplinar, incluindo usuários, clientes, especialistas em fatores humanos etc.
Foco nas características internas da arquitetura. Foco em atributos externos (interação, aparência e funcionamento – look and feel)
Qualidade medida por fatores como defeitos de produto e 
desempenho (qualidade de sistema).
Qualidade definida por satisfação do usuário e 
desempenho (qualidade em uso).
Implementação antes de validação humana. Implementação com base nas avaliações e aprovações dos usuários.
Soluções são produzidas a partir de requisitos funcionais 
(características e recursos do sistema)
Entendimento do contexto de uso (o usuário, a tarefa e o 
ambiente de trabalho).
Adaptado de: Seffah e Metzker (2004, p. 103).
Relevantes autores da área de Engenharia de Software mostraram a importância da interface de 
usuário. Sommerville (2003) relata que a interface de usuário é uma das características que vêm sendo 
priorizadas, com enfoque especial no usuário. Os autores Peters e Pedrycz (2001) afirmam que os fatores 
humanos, bem como a inclusão do usuário no desenvolvimento de interfaces, constituem uma fronteira 
relativamente nova da Engenharia de Software. O fato é que, atualmente, a interface de usuário vem 
ganhando ainda mais importância nos projetos de sistemas interativos. Entretanto, a inclusão do usuário 
no desenvolvimento de interfaces, embora já não seja uma fronteira tão nova assim na Engenharia de 
Software, ainda não acontece consoante sua importância.
26
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade II
Existem vários modelos de ciclo de vida para o desenvolvimento de sistemas interativos apresentados 
na literatura de IHC. Segundo Rocha e Baranauskas (2003), os modelos de ciclo de vida de design em IHC 
“envolvem desde uma discussão crítica dos ciclos de vida clássicos para o desenvolvimento de software, 
originais da Engenharia de Software, até modelos mais específicos do ciclo de vida de design, como, por 
exemplo, o modelo estrela”, que será apresentado posteriormente.
No entanto, os modelos de ciclo de vida apresentados pela IHC não discutem as etapas para o desenvolvimento 
e a implementação do sistema e de suas funcionalidades, diferentemente dos modelos de ciclo de vida da 
Engenharia de Software. Estes modelos enfocam o desenvolvimento da interação com o usuário.
De acordo com Sharp, Rogers e Preece (2005), o termo design não deve ser confundido com o design 
comumente traduzido como projeto e utilizado pela comunidade de Engenharia de Software para uma 
fase do modelo de ciclo de vida de software. Do mesmo modo, Leite (1998), destaca que a atividade de 
design da interface do usuário não deve ser confundida com a atividade de especificação da maneira 
proposta na Engenharia de Software, nem com o processo de construção do software. 
Segundo Souza et al. (1999), o design de interfaces de usuário é uma atividade que requer análise dos 
requisitos dos usuários e suas tarefas, concepção, especificação e prototipação da interface, e avaliação 
da utilização do protótipo pelos usuários.
 Observação
Requisitos de software são características, propriedades e 
comportamentos desejáveis para um produto de software. Eles podem ser 
divididos em (SWEBOK, 2004):
• Requisitos funcionais: estão diretamente ligados à funcionalidade do 
software. Descrevem as funções que o software deve executar.
• Requisitos não funcionais: expressam as restrições a que o software 
deve atender ou as qualidades específicas que o software deve ter. Às 
vezes são conhecidos como restrições ou requisitos de qualidade.
No entanto, para Marcus (2002), o design de interface de usuário ainda não tem uma definição 
consolidada. Para ele, deveria ser chamado de desenvolvimento de interface de usuário, semelhante 
ao desenvolvimento de software, adotado pela Engenharia de Software.
 Observação
O termo design é encontrado na literatura sobre IHC como algo mais 
amplo em relação ao mesmo termo utilizado na Engenharia de Software. 
Entretanto, neste livro-texto, o termo, algumas vezes, aparecerá traduzido 
para projeto, mesmo quando utilizado nas atividades relacionadas à IHC.
27
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
3.2 Modelos de ciclo de vida de software tradicionais da Engenharia de Software
Segundo Pressman (2006), nos últimos cinquenta anos, o software – programas, dados e documentos 
– evoluiu. Passou de um ferramental especializado em solução de problemase análise de informações 
para um produto de indústria. No entanto, ainda há problemas em produzir software de alta qualidade 
e dentro do prazo e do orçamento estabelecido. Desse modo, o intuito da Engenharia de Software é 
fornecer uma estrutura para a construção de software com alta qualidade.
O Institute of Electrical and Electronic Engineers (IEEE) definiu Engenharia de Software como: “(1) A 
aplicação de uma abordagem sistemática, disciplinada e quantificável, para o desenvolvimento, operação 
e manutenção do software; isto é, a aplicação da engenharia ao software. (2) O estudo de abordagens 
como as de (1)” (IEEE, 1990).
Ferramentas
Métodos
Processos
Foco na Qualidade
Figura 2 – Camadas da Engenharia de Software
Segundo Pressman (2006), a Engenharia de Software é uma tecnologia composta por camadas, 
conforme apresentado na figura. É uma disciplina que tem como base de apoio o foco na qualidade. A 
camada de processos assegura a junção das camadas de tecnologia e proporciona o desenvolvimento 
racional e oportuno de software de computador. Os métodos de Engenharia de Software fornecem a 
técnica de como fazer para construir software. As ferramentas de Engenharia de Software fornecem 
apoio automatizado ou semiautomatizado para os processos e para os métodos.
De acordo com estas definições, a Engenharia de Software surgiu com o objetivo de melhorar o 
processo de desenvolvimento de software, bem como a qualidade do produto de software.
A Engenharia de Software propõe vários modelos de ciclo de vida de software (também conhecidos 
como paradigmas de processo ou modelos de processo de software). 
A partir de IEEE (1990), Paula Filho (2008), Pressman (2006), Schmidt (2000), Sommerville (2003) e 
Swebok (2004), podem-se apresentar as fases tipicamente utilizadas nos modelos de ciclo de vida da 
engenharia de software, aplicáveis à maioria dos projetos de software. A seguir, apresenta-se a descrição 
resumida de casa fase:
• Requisitos: esta fase, também chamada de Levantamento de Requisitos, visa obter um 
conjunto de requisitos de um produto acordado entre cliente e fornecedor. Sua finalidade é 
definir o que o sistema deve fazer. A identificação de questões relacionadas a algum atributo 
de qualidade, tais como desempenho, confiabilidade, disponibilidade e segurança, também 
faz parte desta fase.
28
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade II
• Análise: nesta fase o objetivo é detalhar, estruturar e validar os requisitos de software levantados 
durante a fase de Requisitos, de forma que estes possam ser usados como base para planejamento 
e acompanhamento detalhados da construção do produto. Enquanto o Levantamento de Requisitos 
focaliza a visão que os usuários têm dos requisitos do software, a Análise dos Requisitos focaliza a 
visão dos desenvolvedores, ainda considerando apenas o que fazer, sem entrar no espaço das soluções.
• Projeto (Design): sua finalidade principal é decidir como o sistema será implementado. Uma 
arquitetura de software é definida durante esta fase e estabelece a estrutura com que o produto 
de software deverá ser implementado para satisfazer os requisitos. A arquitetura inclui o projeto 
do banco de dados e o desenho interno que modela as partes lógicas e físicas do software, bem 
como suas interconexões e comunicações com softwares externos. Durante a fase de projeto, 
decisões táticas e estratégicas são tomadas para atender aos requisitos funcionais e de qualidade 
de um sistema.
• Implementação: na fase de implementação o projeto é transportado para uma linguagem de 
implementação em forma de código-fonte. O objetivo desta fase é traduzir a solução em código. 
A conclusão desta fase somente ocorre quando todo o código está escrito e documentado, 
compilado, livre de erros e seguindo o padrão do projeto. Além disso, até o final desta fase, um 
plano de testes (descrevendo quando e como testar cada parte do código) deve ser traçado.
• Testes: nesta fase o objetivo é integrar e testar o sistema. Durante a fase de testes, o sistema 
é verificado para certificar-se de que os requisitos especificados anteriormente foram todos 
implementados corretamente. O código gerado deve ser testado rigorosamente baseado nos 
requisitos analisados.
• Implantação: tem a finalidade de assegurar uma transição bem-sucedida do sistema desenvolvido 
para seus usuários. Consiste na instalação do produto de software no ambiente designado e 
a revisão e teste de aceitação por parte do cliente do produto de software (installation of the 
software product in the target environment and the acquirer’s acceptance review and testing 
of the software product). Nesta fase estão incluídos artefatos como material de treinamento e 
procedimentos de instalação.
Essas fases podem se sobrepor ou podem ser executadas iterativamente (IEEE, 1990).
Os principais e mais tradicionais modelos de ciclo de vida de software são:
• cascata;
• incremental;
• espiral;
• prototipagem.
29
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
 Observação
A Engenharia de Software apresenta vários modelos de ciclo de vida 
de software. Os modelos abordados por meio de conceitos básicos neste 
livro-texto são para fazer um paralelo com os modelos da IHC que serão 
apresentados nas próximas páginas. 
 Saiba mais
Para saber mais sobre os modelos de ciclo de vida de software 
apresentados pela Engenharia de Software, consulte também:
PRESSMAN, R. S. Engenharia de software. 7. ed. Porto Alegre: AMGH, 2011.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson, 2007.
3.2.1 Modelo em Cascata
Um dos primeiros modelos propostos foi o Modelo Cascata, também chamado de Ciclo de Vida 
Clássico, apresentado na figura a seguir:
Requisitos
Testes
Projeto
Análise
Implantação
Inplementação
Figura 3 – O Modelo em Cascata
O Modelo em Cascata sugere uma abordagem sistemática e sequencial – fases (ou estágios) 
de desenvolvimento são apresentadas em sequência – para o desenvolvimento de software. O 
processo começa com a especificação dos requisitos pelo cliente e progride ao longo das outras 
30
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade II
atividades fundamentais. O desenvolvimento de uma fase deve terminar antes de a próxima 
começar. Desse modo, só quando todos os requisitos forem enunciados pelo cliente, analisados 
e documentados, é que a equipe de desenvolvimento poderá realizar as atividades de projeto de 
sistema (PFLEEGER, 2004; PRESSMAN, 2006; SOMMERVILLE, 2003).
O problema do Modelo em Cascata é sua divisão rígida do projeto nesses estágios distintos. Estabelecer 
acordos e requisitos bem-definidos no estágio inicial do processo é uma tarefa difícil, pois os requisitos 
do cliente, por natureza, sempre se modificam. Outro problema é a baixa visibilidade para o cliente, que 
somente verá o resultado no final do projeto.
3.2.2 Modelo Incremental
O Modelo Incremental, conforme apresentado na figura a seguir, combina as vantagens do Modelo 
em Cascata com as vantagens do modelo evolucionário (PRESSMAN, 2006; SOMMERVILLE, 2003). Neste 
modelo, que tem o objetivo de apresentar um produto operacional a cada incremento, os requisitos 
e conceitos de software e sistema são, primeiro identificados em um esboço pelos clientes, e, em 
seguida, é definida uma série de estágios de entrega, com cada estágio fornecendo um subconjunto das 
funcionalidades do sistema. Esses estágios são repetidos cada vez que há uma nova versão do software. 
Definir esboço dos 
requisitos
Desenvolver 
incremento do sistema
Atribuir requisitos aos 
incrementos
Validar incremento
Projetar arquitetura 
do sistema
Integrar incremento Validar sistema
Sistema incompleto
Sistema 
final
Figura 4 – Desenvolvimento incremental
Os primeiros incrementos já oferecem aos usuários condições de colocá-los em operação,bem 
como de experimentar o sistema, possibilitando o esclarecimento e a definição de requisitos para os 
próximos incrementos.
3.2.3 Modelo Espiral
O Modelo Espiral, apresentado na figura a seguir, originalmente proposto por Boehm (1988), é 
um modelo evolucionário de processo de software que combina a natureza iterativa da prototipagem 
com os aspectos controlados e sistemáticos do Modelo em Cascata (PRESSMAN, 2006). O processo é 
representado como uma espiral, e não como uma sequência de atividades, com algum retorno de uma 
atividade para outra (SOMMERVILLE, 2003). O produto é desenvolvido em uma série de iterações, de 
forma que cada nova iteração corresponde a uma volta na espiral. Desse modo, é possível construir 
produtos em prazos curtos, com novas características e recursos que são agregados à medida que a 
experiência descobre sua necessidade (PAULA FILHO, 2008).
31
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
Determinar objetivos, 
alternativas e 
restrições
Avaliar alternativas; 
identificar e resolver riscos
Planejar a próxima fase
Análise de risco
Análise de risco
Análise de risco
Análise 
de risco
Protótipo 2
Protótipo1
Protótipo 3 Protótipo 
operacional
Plano de requisistos
Plano de ciclo de vida
Plano de 
desenvolvimento
Projeto 
detalhado
Código
Teste de 
unidadeTeste de 
integraçãoTeste de 
aceitaçãoOperação
Desenvolver, veriificar 
produto do próximo nível
Integração e 
plano de testes
Validação de 
requisitos
Conceito de 
operação
Simulação Modelos Benchmarks
Projeto 
V&V
Requisitos 
S/W Design do 
produto
Revisão
Figura 5 – Modelo Espiral
O modelo abrange de forma clara o gerenciamento de riscos e se aplica ao desenvolvimento de 
sistemas e software de grande porte (BOEHM, 1988).
3.2.4 Prototipagem
A prototipagem (ou prototipação) permite que todo o sistema, ou parte dele, seja construído 
rapidamente para que questões sejam entendidas ou esclarecidas.
De acordo com Sharp, Rogers e Preece (2005), os protótipos são muito úteis quando se está discutindo 
ideias com stakeholders, são dispositivos que facilitam a comunicação entre os membros das equipes e 
que consistem em uma maneira eficaz de testar as ideias para você mesmo.
Os protótipos de software são produzidos com funcionalidade e desempenho limitados (PETERS; 
PEDRYCZ, 2001), cobrindo cada vez mais requisitos, até que se atinja o produto desejado. Pfleeger (2004, 
p. 42) compara o modelo de prototipagem com o protótipo de engenharia. Segundo o autor, o objetivo é 
o mesmo, ou seja, é eficaz “quando os requisitos ou projeto necessitam de investigações repetidas para 
garantir que desenvolvedor, usuário e cliente cheguem a um consenso sobre o que é necessário e o que 
é proposto”. 
Uma vantagem desse modelo é solucionar o problema da espera no Modelo em Cascata, ou seja, não 
é necessário esperar até o final do ciclo de desenvolvimento para poder obter uma versão operacional 
do software (PETERS; PEDRYCZ, 2001). Outra vantagem desse modelo é deixar o usuário mais tranquilo 
ao “ver” o progresso do desenvolvimento do sistema.
32
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade II
Do ponto de vista da Engenharia de Software, a prototipagem é parte fundamental do processo de 
projeto de interface com o usuário (PFLEEGER, 2004; SOMMERVILLE, 2003).
O paradigma de prototipagem pode ser dividido em evolucionário e descartável (throw-away). Na 
prototipagem evolucionária, o planejamento de protótipos é mais cuidadoso, isto porque os protótipos 
não serão descartados. Neste modelo a equipe de desenvolvimento trabalha com os stakeholders os 
aspectos mais visíveis do sistema, normalmente a interface de usuário, sendo especialmente útil quando 
os usuários possuem dificuldade para expressar os requisitos do sistema.
Na prototipagem evolucionária, executam-se simultaneamente as fases de análise, projeto 
e implementação a fim de desenvolver, de forma rápida, uma versão simplificada do sistema 
proposto e apresentá-la aos stakeholders para avaliação e retorno de informações, conforme 
apresentado na figura a seguir (DENNIS; WIXOM; ROTH, 2014). Caso existam requisitos que ainda 
necessitem ser refinados, uma nova iteração será realizada. Neste caso, a equipe de projeto 
novamente analisa, projeta e volta a implementar outro protótipo, com novos recursos e correção 
das deficiências encontradas.
Planejamento
Análise
ImplementaçãoProjeto
Implementação
Protótipo do 
sistema
Sistema
Figura 6 – O Modelo de Prototipagem
A prototipagem descartável (throw-away) consiste na construção de protótipos utilizados para 
explorar as alternativas de projeto, entender melhor os requisitos do sistema e reduzir riscos.
Conforme apresentado na figura a seguir, a prototipagem descartável tem uma fase de análise 
mais minuciosa, usada para analisar os requisitos e desenvolver ideias para a concepção do sistema. 
Entretanto, sugestões e solicitações de novos recursos pelos usuários e questões técnicas complexas 
podem não ter sido bem-compreendidos pela equipe de projeto. Para que se tenha, portanto, o correto 
entendimento, essas questões são examinadas pela análise, concepção e construção de um protótipo de 
design (DENNIS; WIXOM; ROTH, 2014).
33
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
Planejamento
Análise
Análise
ImplementaçãoProjeto
Projeto
Implementação
Protótipo do 
sistema
Sistema
Figura 7 – Modelo de prototipagem descartável
O protótipo gerado nesse modelo não tem o objetivo de ser um sistema funcional. Depois de cumprir 
com seu propósito, ele será descartado. 
3.3 Modelo de ciclo de vida de design de interface de usuário
3.3.1 Modelo Estrela
Proposto por Hix e Hartson em 1989, o Modelo Estrela, apresentado na figura a seguir, emergiu de 
um trabalho empírico realizado por ambos, observando como os projetistas de interface trabalhavam 
(SHARP; ROGERS; PREECE, 2005).
Avaliação
Análise das tarefas/
análise funcional
Projeto conceitual/
representação formal do 
design
Implementação
Prototipação Requisitos/ especificação
Figura 8 – Modelo Estrela
34
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade II
Segundo Costabile (2001), enquanto o modelo em Cascata sugere uma abordagem top-down 
(descendente, partindo da visão do sistema para a do usuário – mais formal), o modelo estrela 
reconhece que esta abordagem precisa ser complementada por uma abordagem bottom-up 
(ascendente, partindo da visão do usuário para a do sistema – mais criativa). Diferentemente dos 
modelos propostos pela Engenharia de Software, o modelo estrela não especifica ordenamento 
algum das atividades.
Um projeto pode começar de qualquer atividade (ponta na estrela) e seguir por qualquer outra, 
no entanto, deve sempre passar pela atividade de avaliação. Ou seja, o modelo possui uma avaliação 
central e, sempre que uma atividade for completada, seu trabalho deverá ser avaliado. Desse modo, os 
requisitos, o projeto e o produto evoluem gradualmente.
No entanto, esse modelo apresenta como desvantagem uma baixa visão gerencial para os gerentes 
e desenvolvedores. Uma explicação pode estar no fato do modelo estrela ser extremamente flexível 
(SHARP; ROGERS; PREECE, 2005).
3.3.2 Engenharia de Usabilidade
Engenharia de Usabilidade, segundo Rocha e Baranauskas (2003), é um termo usado para definir o 
processo de projeto de sistemas computacionais que visam à facilidade de aprendizado e de uso, e que 
sejam agradáveis para as pessoas. Além disso, propõe a aplicação de métodos empíricos ao projeto de 
sistemas baseados em computador.
Segundo Brown (1996), Engenharia de Usabilidade é um modelo com foco principal em 
conhecer o usuário e suas tarefas, bem como testar com os usuários os protótipos de um produto 
em desenvolvimento.O usuário e o projetista de interface são os membros fundamentais nesta metodologia. No 
entanto, esta metodologia não apresenta uma relação definida entre o projetista de interface e o 
engenheiro de software.
Na figura a seguir são ilustradas as fases e o fluxo das atividades no modelo de Engenharia de 
Usabilidade proposto por Nielsen (1992, 1993) e sumarizado por Rocha e Baranauskas (2003). O modelo 
possui três fases: pré-projeto, projeto e pós-projeto. 
35
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
Pré-projeto
Projeto
Pós-Projeto
Desenvolvimento iterativo
Conhecer o usuário
Características individuais
Tarefa atual
Análise competitiva
Metas de usabilidade
Métodos participativos
Guidelines
Projeto coordenado
Padrões – Identidade do produto
Feedback de estudo de campo
Prototipação
Teste
Design rationale
Figura 9 – Modelo de Engenharia de Usabilidade
Na fase de pré-projeto, o objetivo é a busca de informações para compreensão do usuário, das suas 
atividades e do seu contexto de trabalho, além das funcionalidades a serem implementadas no sistema. 
Também nessa fase são realizados estudos para uma análise comparativa de produtos existentes e testes 
com usuários no uso desses produtos. As metas de usabilidade são definidas ainda nesta fase.
A fase do projeto comporta o projeto inicial e o desenvolvimento iterativo. O projeto inicial é 
constituído da especificação inicial da interface. O design participativo é realizado, e o uso de guidelines 
é recomendado. O projeto coordenado (desenvolvimento paralelo da funcionalidade, da interface, do 
help e do material de treinamento) faz parte desta fase. O uso de padrões aumenta o reúso de código 
e facilita a documentação. O desenvolvimento iterativo é alimentado por feedback de testes até que 
os objetivos tenham sido alcançados. Os objetivos dessa fase são produzir um protótipo com princípios 
de usabilidade e verificar empiricamente, com usuários reais, se as metas foram atingidas. O design 
rationale, além de manter a memória do processo de projeto, ajuda a manter a consistência ao longo 
das diferentes versões do produto.
Por fim, a última fase, pós-projeto, tem como objetivo conduzir estudos de campo do produto em 
uso a fim de obter dados para próximas versões e produtos futuros.
Nielsen (1992) reconhece que frequentemente orçamentos ou restrições de tempo não 
permitirão o uso de todas as atividades do Modelo de Engenharia de Usabilidade. No entanto, 
recomenda um mínimo:
• visite os locais de trabalho do cliente antes do início do projeto;
36
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade II
• faça um projeto iterativo com métodos participativos;
• use prototipação e testes empíricos com usuários reais.
3.3.3 Projeto centrado no usuário
A IHC enfatiza a necessidade de uma abordagem centrada no usuário. Segundo Sharp, Rogers 
e Preece (2005), o fio condutor do desenvolvimento de um produto deveria ter como base os 
usuários reais e suas metas, não apenas a tecnologia. Desse modo, para se ter um sistema 
bem-projetado, os projetistas deveriam extrair o máximo da habilidade e dos julgamentos 
humanos mais importantes para o trabalho em questão. Portanto, deveriam apoiar o usuário, e 
não limitar suas ações.
Para Faulkner e Culwin (2000), as necessidades do usuário devem ser consideradas desde as fases 
iniciais do projeto, e o produto (interface do usuário) deve ser construído por meio da abordagem 
centrada no usuário.
Os princípios do projeto centrado no usuário, ou User-Centered Design (UCD), são focalizar 
desde o início os usuários e as tarefas que desenvolvem num determinado ambiente, medir a 
utilização do produto observando a interação do usuário com ele e utilizar um processo de design 
iterativo, no qual o design possa ser modificado após as fases de prototipação ou testes (SOUZA; 
COSTA; SPINOLA, 2006).
Projeto centrado no usuário é uma atividade multidisciplinar que 
incorpora fatores humanos e conhecimento de ergonomia e técnicas 
com o objetivo de aumento da eficácia e eficiência, melhorando as 
condições humanas de trabalho, segurança, desempenho e evitar 
possíveis efeitos contra a saúde do homem (BEVAN, 1999 apud SOUZA; 
COSTA; SPINOLA, 2006, p. 5).
3.3.4 Design Participativo
O Design Participativo (DP) é uma abordagem que envolve ativamente o usuário. Segundo Sharp, 
Rogers e Preece (2005), a ideia dessa abordagem surgiu na Escandinávia, no final dos anos 1960 e início 
dos 1970. Sua intenção consiste em fazer que os usuários se tornem parceiros como os outros na equipe 
de projeto, participando de todas as atividades de desenvolvimento.
A inclusão do usuário final no processo de desenvolvimento se deve ao seu conhecimento das 
rotinas de trabalho, além de servir como fonte de informação. Desta forma, por meio de sua participação 
ativa, o usuário proporciona contribuições efetivas em todas as fases do processo de desenvolvimento, 
que refletem suas perspectivas e necessidades, não somente da etapa de testes e avaliação (ROCHA; 
BARANAUSKAS, 2003).
37
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
PROJETO DE INTERFACE COM O USUÁRIO
De acordo com Brown (1996), o DP não defende uma metodologia em particular. O argumento é 
de que, do ponto de vista dos defensores do DP, para a fabricação de um bom produto de software 
não é necessária uma metodologia como foco, e sim a qualidade da comunicação entre o usuário e 
os projetistas. No DP são definidos os tipos de comunicação desejados e métodos que podem auxiliar 
usuários e projetistas a realizarem um projeto melhor.
Embora uma metodologia não seja enfatizada, no DP existem métodos que são vistos mais como um 
recurso para os projetistas usarem como julgarem mais apropriado (BROWN, 1996). 
Esses métodos se caracterizam pelo uso de técnicas simples e pelo pouco comprometimento 
com recursos. As técnicas mais utilizadas são: brainstorming, storyboarding e workshops (ROCHA; 
BARANAUSKAS, 2003).
3.3.5 Customização de um modelo de ciclo de vida destinada a projeto de interface 
para dispositivos móveis
À medida que as tecnologias móveis começam a fazer parte da infraestrutura de Tecnologia da 
Informação (TI) das organizações e do dia a dia das pessoas, é altamente importante, ao se construir uma 
estratégia de desenvolvimento de aplicações móveis, ter um entendimento aprofundado da interação 
do usuário com os dispositivos móveis (SOUZA; COSTA; SPINOLA, 2006).
Novas plataformas de computação e comunicação criam a possibilidade 
para novos modelos de negócios e novas aplicações que têm influência na 
vida das pessoas. No entanto, novas plataformas também exigem a revisão 
dos métodos e princípios de projetos da atualidade. Os dispositivos móveis 
estão abrindo novas oportunidades de negócios para empresas e usuários 
e novos desafios de projeto de software (HOLTZBLATT, 2005 apud SOUZA; 
COSTA; SPINOLA, 2006, p. 7).
Os desafios tecnológicos em desenvolvimento de sistemas móveis são significativos, e o 
avanço da computação móvel fez surgir novos modelos de interface e exibições de informação. A 
interface com o usuário já tinha grande importância no processo de desenvolvimento de sistemas 
interativos; agora, nos projetos de software para computação móvel, a interface é um desafio 
ainda maior.
Diante desse cenário, verifica-se a grande importância de se facilitar a forma de utilização 
desses dispositivos computacionais móveis, isto é, de disponibilizar uma interface bem-planejada, 
visando facilidade de aprendizagem, simplicidade de uso e satisfação do usuário ao interagir 
com o sistema.
38
AD
S 
- 
Re
vi
sã
o:
 R
os
e 
- 
Di
ag
ra
m
aç
ão
: F
ab
io
 -
 1
6/
03
/2
01
5
Unidade II
Restrições 
intrínsecas dos 
dispositivos 
móveis
ISO/IEC 9126-1
ISO 9241-11 ISO 13407
Contexto 
de uso
Análise da tarefa Análise do usuário móvelAnálise