DESIGN DE INTERAÇÃO

Prévia do material em texto

DESIGN DE 
INTERAÇÃO
Professor Esp. Ricardo Francisco de Pierre Satin
GRADUAÇÃO
Unicesumar
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a 
Distância; SATIN, Ricardo Francisco de Pierre.
 
 Design de Interação. Ricardo Francisco de Pierre Satin. 
 (Reimpressão revista e atualizada)
 Maringá-Pr.: UniCesumar, 2016.
 157 p.
“Graduação - EaD”.
 
 1. Design. 2. Usabilidade. 3. EaD. I. Título.
ISBN 978-85-8084-560-0
CDD - 22 ed. 005.3 
CIP - NBR 12899 - AACR/2
Ficha catalográfica elaborada pelo bibliotecário 
João Vivaldo de Souza - CRB-8 - 6828
Reitor
Wilson de Matos Silva
Vice-Reitor
Wilson de Matos Silva Filho
Pró-Reitor de Administração
Wilson de Matos Silva Filho
Pró-Reitor de EAD
Willian Victor Kendrick de Matos Silva
Presidente da Mantenedora
Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância
Direção Operacional de Ensino
Kátia Coelho
Direção de Planejamento de Ensino
Fabrício Lazilha
Direção de Operações
Chrystiano Mincoff
Direção de Mercado
Hilton Pereira
Direção de Polos Próprios
James Prestes
Direção de Desenvolvimento
Dayane Almeida 
Direção de Relacionamento
Alessandra Baron
Gerência de Produção de Conteúdo
Juliano de Souza
Supervisão do Núcleo de Produção de 
Materiais
Nádila de Almeida Toledo
Coordenador de Conteúdo
Danillo Xavier Saes
Design Educacional
Fernando Henrique Mendes 
Rossana Costa Giani 
Iconografia
Amanda Peçanha dos Santos
Ana Carolina Martins Prado
Projeto Gráfico
Jaime de Marchi Junior
José Jhonny Coelho
Arte Capa
André Morais de Freitas
Editoração
Thayla Daiany Guimarães Cripaldi
Revisão Textual
Jaquelina Kutsunugi, Keren Pardini, Maria 
Fernanda Canova Vasconcelos, Nayara 
Valenciano, Rhaysa Ricci Correa e Susana Inácio
Ilustração
Thayla Daiany Guimarães Cripaldi
Viver e trabalhar em uma sociedade global é um 
grande desafio para todos os cidadãos. A busca 
por tecnologia, informação, conhecimento de 
qualidade, novas habilidades para liderança e so-
lução de problemas com eficiência tornou-se uma 
questão de sobrevivência no mundo do trabalho.
Cada um de nós tem uma grande responsabilida-
de: as escolhas que fizermos por nós e pelos nos-
sos fará grande diferença no futuro.
Com essa visão, o Centro Universitário Cesumar – 
assume o compromisso de democratizar o conhe-
cimento por meio de alta tecnologia e contribuir 
para o futuro dos brasileiros.
No cumprimento de sua missão – “promover a 
educação de qualidade nas diferentes áreas do 
conhecimento, formando profissionais cidadãos 
que contribuam para o desenvolvimento de uma 
sociedade justa e solidária” –, o Centro Universi-
tário Cesumar busca a integração do ensino-pes-
quisa-extensão com as demandas institucionais 
e sociais; a realização de uma prática acadêmica 
que contribua para o desenvolvimento da consci-
ência social e política e, por fim, a democratização 
do conhecimento acadêmico com a articulação e 
a integração com a sociedade.
Diante disso, o Centro Universitário Cesumar al-
meja ser reconhecida como uma instituição uni-
versitária de referência regional e nacional pela 
qualidade e compromisso do corpo docente; 
aquisição de competências institucionais para 
o desenvolvimento de linhas de pesquisa; con-
solidação da extensão universitária; qualidade 
da oferta dos ensinos presencial e a distância; 
bem-estar e satisfação da comunidade interna; 
qualidade da gestão acadêmica e administrati-
va; compromisso social de inclusão; processos de 
cooperação e parceria com o mundo do trabalho, 
como também pelo compromisso e relaciona-
mento permanente com os egressos, incentivan-
do a educação continuada.
Seja bem-vindo(a), caro(a) acadêmico(a)! Você está 
iniciando um processo de transformação, pois quan-
do investimos em nossa formação, seja ela pessoal 
ou profissional, nos transformamos e, consequente-
mente, transformamos também a sociedade na qual 
estamos inseridos. De que forma o fazemos? Criando 
oportunidades e/ou estabelecendo mudanças capa-
zes de alcançar um nível de desenvolvimento compa-
tível com os desafios que surgem no mundo contem-
porâneo. 
O Centro Universitário Cesumar mediante o Núcleo de 
Educação a Distância, o(a) acompanhará durante todo 
este processo, pois conforme Freire (1996): “Os homens 
se educam juntos, na transformação do mundo”.
Os materiais produzidos oferecem linguagem dialó-
gica e encontram-se integrados à proposta pedagó-
gica, contribuindo no processo educacional, comple-
mentando sua formação profissional, desenvolvendo 
competências e habilidades, e aplicando conceitos 
teóricos em situação de realidade, de maneira a inse-
ri-lo no mercado de trabalho. Ou seja, estes materiais 
têm como principal objetivo “provocar uma aproxi-
mação entre você e o conteúdo”, desta forma possi-
bilita o desenvolvimento da autonomia em busca dos 
conhecimentos necessários para a sua formação pes-
soal e profissional.
Portanto, nossa distância nesse processo de cres-
cimento e construção do conhecimento deve ser 
apenas geográfica. Utilize os diversos recursos peda-
gógicos que o Centro Universitário Cesumar lhe possi-
bilita. Ou seja, acesse regularmente o AVA – Ambiente 
Virtual de Aprendizagem, interaja nos fóruns e en-
quetes, assista às aulas ao vivo e participe das discus-
sões. Além disso, lembre-se que existe uma equipe de 
professores e tutores que se encontra disponível para 
sanar suas dúvidas e auxiliá-lo(a) em seu processo de 
aprendizagem, possibilitando-lhe trilhar com tranqui-
lidade e segurança sua trajetória acadêmica.
Professor Esp. Ricardo Francisco de Pierre Satin
Graduado em Computação pela Universidade Estadual de Maringá (UEM) 
e MBA em Gerenciamento de Projetos pela FCV. Profissional certificado 
em gerenciamento de serviços de T.I. (ITIL) e, profissional certificado em 
gerenciamento de projeto pelo P.M.I. (profissional PMP). Trabalha com 
desenvolvimento de sistemas desde 1998 e, desde 2005, atua como gerente 
de projetos e possui ainda certificado PMP (Project Management Professional)..
A
U
TO
R
SEJA BEM VINDO!
Olá, caro(a) aluno(a)! É com prazer que apresento a você o livro que fará parte da discipli-
na de Design de Interação. Sou o professor Ricardo Francisco de Pierre Satin e preparei 
com muita dedicação este material para que você possa adquirir os conhecimentos ne-
cessários sobre esta matéria tão relevante.
Asseguro-lhe que um dos itens de maior relevância no desenvolvimento de um novo 
produto é como se dará seu processo de interação.
Meu objetivo ao escrever este livro foi trazer maior clareza a esta difícil tarefa de produzir 
sistemas que sejam realmente utilizados por nossos caros usuários. Neste tempo que 
tenho trabalhado na área de tecnologia da informação, posso assegurar-lhe que vi vá-
rios projetos interessantes, sistemas que se propunham a solucionar problemas graves, 
nunca “saírem da gaveta” por negligenciarem este aspecto tão importante que é tratado 
nesta disciplina.
Comprometo-me a trazer para você informações que avalio ser transformadoras à sua 
forma de desenvolver sistemas, itens que tenho observado ao longo dos anos no desen-
volvimento dos sistemas e os quais tenho levado aos meus clientes. Sendo assim, uma 
coisa quero pedir em troca: o seu empenho para este intenso trabalho. 
No decorrer das suas leituras, procure interagir com os textos, fazer anotações, estabe-
lecer correlações com suas atividades diárias, responder às atividades de autoestudo, 
anotar suas dúvidas, complementar seus estudos com as indicações de leitura e realizar 
novas pesquisas sobre o assunto. Tenho certeza de que não será possível esgotar este 
tema apenas com este livro e por isso conto com sua pesquisa. 
Tendo a certeza de que terei sua dedicação, quero começar questionando-o(a): qual o 
segredo do sucesso no desenvolvimento de sistemas?
O segredo é fazer algo de qualidade que seja útil, simples e usual. Espere encontrar nes-
ta disciplina informações que vão lhe ajudar nos seguintes quesitos: como tornar sua 
aplicação mais usual e mais interativa, garantindosimplicidade e proporcionando uma 
visão de maior qualidade aos seus produtos.
E para isso, começaremos na unidade I a entender mais sobre o que é design e intera-
ção, vamos estudar como ele pode contribuir para o sucesso da solução que você está 
propondo, vamos entender alguns tipos de design e para isso vamos navegar um pouco 
sobre a história da computação. Vamos começar a ver quais os critérios que devem ser 
observados para a criação de um bom design, vamos entender que estes critérios envol-
vem uma equipe competente e multidisciplinar, ou seja, não espere fazer tudo sozinho! 
Um bom design é trabalho de equipe.
Caminhando para a unidade II, vamos entender mais um pouco sobre um dos com-
ponentes de maior relevância dentro do processo de design e interação, que é a in-
teração humano-computador, vamos dar uma passada pelo processo de construção 
de interfaces e vamos entender um pouco sobre seu processo de evolução até sua 
chegada aos dias atuais. Não ficará de fora a compreensão sobre como as pessoas 
APRESENTAÇÃO
DESIGN DE INTERAÇÃO
interagem com tais objetos, este é um critério importantíssimo ao qual você deve 
estar atento para que possa produzir sistemas com boa usabilidade, seja no de-
senvolvimento de soluções desktop, baseadas na web, ou móveis.
Já na unidade III, vamos nos aprofundar nos fatores humanos envolvidos no proces-
so de interação, quais os elementos psicológicos, qual a importância da memória (e 
seu funcionamento) no processo de construção de um bom design. Vamos também 
avaliar se é possível predizer se nosso padrão de design e interação está atingindo 
seus objetivos ou não, sendo a adoção de padrões de análise uma forma de ava-
liar este quesito. Assim, nesta unidade, iremos estudar o modelo GOMS juntamente 
com os modelos mentais.
Entrando na unidade IV, vamos conhecer um pouco mais sobre o mundo da coleta 
e definição dos requisitos. Tão importante quanto entender mais sobre o funciona-
mento do ser humano em sua interação com o computador é conseguir mapear 
as necessidades de forma assertiva. Vamos avaliar algumas técnicas e ferramentas 
importantes, e você verá como poderão lhe apoiar em seu trabalho diário.
E, por último, mas não menos importante, temos a unidade V, nela vamos entender 
um pouco mais sobre como podemos assegurar que estes requisitos se transfor-
mem em um sistema que seja útil, usual, simples e que agreguem valor ao seu usuá-
rio. Vamos relembrar um pouco sobre os modelos de desenvolvimento de software, 
desde os mais clássicos aos mais recentes e entender como o processo de design 
está inserido em cada um deles. É compromisso meu apontar alguns riscos que você 
possa estar correndo na escolha de um modelo ou outro para desenvolvimento, 
então, esteja atento! 
Uma vez que você tenha escolhido o melhor modelo de desenvolvimento de sis-
temas para sua necessidade, que possa contribuir para que um bom design seja 
construído, vamos entender como tudo isto pode ser mais bem controlado e, para 
isso, vamos ter uma breve visão de como o gerenciamento de projetos pode apoiar-
lhe a “blindar” o desenvolvimento da solução. Vamos entrar com um pouco mais 
de detalhes, validando como as metodologias ágeis podem apoiar o processo de 
design e, para isso, vamos entender como o processo de desenvolvimento proposto 
pelo Scrum nos auxiliará.
Este material tem por objetivo principal expor assuntos pertinentes ao processo de 
design e interação, espero que sua leitura seja agradável e que, de alguma maneira, 
os tópicos abordados no decorrer dos seus estudos contribuam com sua vida pes-
soal e profissional.
Antes de iniciar a leitura da primeira unidade, grave e reflita sobre o que Dale Car-
negie nos tem a dizer.
“Mantenha a mente aberta à mudança o tempo todo. Dê boas-vindas a ela. Corteje-a”. 
Tenha uma ótima e agradável leitura!
Professor Ricardo
APRESENTAÇÃO
SUMÁRIO
9
UNIDADE I
CONCEITUANDO DESIGN E INTERAÇÃO
15 Introdução
17 Um Bom e um Mau Design 
21 Histórico do Design de Interação 
34 Equipe Multidisciplinar 
39 Considerações Finais 
UNIDADE II
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
43 Introdução
44 Interface/Interação Humano-Computador (IHC) 
54 Interação Humano-Computador e Interface 
Humano-Computador são Sinônimos?
59 Como as Pessoas Interagem Com Objetos? 
65 Usabilidade 
70 Usabilidade na Web 
75 Considerações Finais 
SUMÁRIO
UNIDADE III
ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS
79 Introdução 
80 A Psicologia da Interface Humano-Computador 
89 Mecanismos da Percepção Humana 
90 O Modelo Goms 
93 Modelos Mentais 
99 Considerações Finais 
UNIDADE IV
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS 
REQUISITOS
103 Introdução 
104 O Quê, Quem, Quando, Onde, Como e Por Quê? 
108 O Que são Requisitos? 
115 Como Coletá-los? 
121 Como Interpretá-los e Analisá-los 
127 Considerações Finais 
SUMÁRIO
11
UNIDADE V
COLOCANDO TUDO ISTO PARA RODAR
131 Introdução
132 Entendendo sua Abordagem Junto aos Modelos de Produção de Software 
138 Entendendo Design como Parte do Escopo de um Projeto 
143 Entendendo seu Benefício no uso Conjunto com Metodologias Ágeis 
152 Considerações Finais 
155 CONCLUSÃO 
157 REFERÊNCIAS 
U
N
ID
A
D
E I
Professor Esp. Ricardo Francisco de Pierre Satin
CONCEITUANDO DESIGN E 
INTERAÇÃO
Objetivos de Aprendizagem
 ■ Compreender o que significa design de interação.
 ■ Entender a importância de um bom design.
 ■ Avaliar o que é um bom ou mau design.
 ■ Entender melhor o histórico da evolução do design de interação e 
quais os elementos envolvidos.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Um bom e um mau design
 ■ Histórico do design de interação
 ■ Equipe multidisciplinar
14 - 15
INTRODUÇÃO
Caro(a) aluno(a), já nesta primeira unidade você estudará um assunto muito 
interessante que contribuirá e muito com sua prática no desenvolvimento de sis-
temas. Para começar, quero refletir contigo sobre com o que em seu cotidiano 
você está envolvido, o que em seu dia a dia exige algum grau de interação? 
Avalie por alguns instantes, o que, em um dia normal, acaba exigindo algum 
grau de interação de sua parte: acredito que facilmente poderá listar elementos 
como telefone celular, computador, agenda eletrônica, ferramenta de e-mail, fer-
ramentas de editoração de textos ou planilha, controle remoto (aqui você pode 
elencar uma infinidade deles, seja da televisão, do som do carro, do ar condicio-
nado, do portão eletrônico...), máquina de refrigerantes, café, caixa eletrônico, 
guichê eletrônico de venda de passagens, um sistema informatizado de biblio-
teca, site de notícia, revista eletrônica ou em formato convencional (impresso), 
fotocopiadora, redes sociais, calculadora, rádio, videogame, ferramentas de loca-
lização, painel de um veículo... É impressionante a quantidade de elementos que 
de alguma forma possuem um grau de interação conosco em um dia qualquer 
de nossas vidas, não é verdade?
Por favor, quero lhe pedir uma segunda avaliação da lista acima: quais são 
realmente fáceis e agradáveis de utilizar? É muito provável que esta grande lista 
seja sintetizada em um restrito grupo. Por que isto acontece?
Caro(a) aluno(a), agora vamos avaliar outra situação, pense em alguma 
ocasião em que algum dos dispositivos acima tenha lhe causado algum tipo de 
transtorno, seja ele qual for, pense naquele dia que chegou atrasado ao traba-
lho devido ao fato de o alarme do despertador não ter disparado no horário que 
você “jurava” que tinha ajustado, pense no tempo que você gastou para fazer o 
programa de gravação de CDs funcionar para copiar aquela música, ou gravar 
aquele filme. Volto à pergunta que fiz no parágrafo anterior, por que isto acon-
tece? Existe algo que está em nosso foco de controle que podemos fazer a respeito 
dos casos mencionados acima?
Muitas vezes, bens de consumo que são objetos de desejo estão ao nosso 
alcance financeiro, ainda mais devidoao momento econômico que vive o nosso 
país. Bens estes que estão tão próximos e tão longe ao mesmo tempo do nosso uso. 
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
14 - 15
CONCEITUANDO DESIGN E INTERAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
16 - 17I
Lembro-me de quando minha mãe comprou seu primeiro multiprocessador 
de alimentos (cerca de 20 anos atrás), era seu sonho aposentar tantos eletrodo-
mésticos que tinha em casa e, em fim, desfrutar da praticidade de ter tudo em 
um só lugar. Também me lembro de sua frustração ao tentar usar este produto 
pela primeira vez e ver que não seria tão prático como imaginava, não seria tão 
simples como aparentava ser e que não substituiria todos os antigos eletrodomés-
ticos como supunha inicialmente. Acredito que até hoje deva estar em alguma 
prateleira acumulando poeira ou talvez tenha sido descartado, fato é que teve 
pouco ou nenhum uso.
Existe uma lacuna muito grande entre o produto e seu efetivo uso. Preece 
(2005, p. 24) afirma:
Muitos produtos que requerem a interação dos usuários para a realiza-
ção de suas tarefas (p.ex.: comprar um ingresso pela Internet, fotocopiar 
um artigo, gravar um programa da TV) não foram necessariamente 
projetados tendo o usuário em mente; foram tipicamente projetados 
como sistemas para realizar determinadas funções. Pode ser que fun-
cionem de maneira eficaz, olhando-se da perspectiva de engenharia, 
mas geralmente os usuários do mundo real é que são sacrificados. O ob-
jetivo de design de interação consiste em redirecionar essa preocupação, 
trazendo a usabilidade para dentro do processo de design. Essencial-
mente isso significa desenvolver produtos interativos que sejam fáceis, 
agradáveis de utilizar e eficazes – sempre na perspectiva do usuário.
Nesta unidade, quero tratar contigo do que é design de interação, vamos ava-
liar as principais diferenças entre um bom e um mau design, e é objetivo meu 
que você possa ter condições de avaliar isto cotidianamente de forma a desenvol-
ver seus sistemas focando sob este aspecto de tamanha relevância para o sucesso 
ou fracasso de um produto. 
 ©shutterstock
UM BOM E UM MAU DESIGN
Há aqueles que dizem que design pode ser uma questão de “gosto”, predileção... 
Vamos ler juntos e ver se temos sua opinião modificada no final deste livro. 
Designs que permitem uma boa interação têm mudado a vida das pessoas, médi-
cos estão podendo fazer diagnósticos mais precisos, crianças estão evoluindo 
cada vez mais em nível de aprendizado, artistas estão conseguindo explorar mais 
seu lado criativo, vemos pilotos terem mais segurança para realizar seu trabalho 
e acompanhamos esta evolução chegar até nós, motoristas. 
Alguns veículos mais modernos já têm saído de fábrica com opcionais que 
permitem muito mais segurança aos motoristas, itens como visão noturna, pro-
jeção de comandos em dispositivos de tela de forma que o motorista não tenha 
que tirar o foco da estrada já está disponível e garantem uma maior segurança.
Em contrapartida, vemos alguns exemplos de experiências perturbadoras e 
desastrosas, interações não planejadas adequadamente gerando frustração, medo, 
falhas que podem colocar a vida de pessoas em risco, gerar prejuízo financeiro, 
prejudicar o aprendizado, entre outras coisas.
©
sh
ut
te
rs
to
ck
Um Bom e um Mau Design
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
16 - 17
Seus produtos acabam por causar uma boa impressão para seus usuários 
quando estão em uso?
18 - 19
TABLETS CAEM NO GOSTO DAS CRIANÇAS; SERÁ A NOVA BABÁ 
ELETRÔNICA?
Por Bruno Romani 
Com pouco mais de dois anos de existência, o tablet caiu no gosto de meninos e me-
ninas e muitas vezes tem uma função conhecida por “babá eletrônica”, antes ocupada 
pela TV.
Em diversos países pesquisas mostram o quanto a criançada gosta do aparelho. Na In-
glaterra, em levantamento da Duracell, 12% dos entrevistados com idades entre cinco 
e 16 anos disseram querer ganhar um tablet de presente. Bonecos e bonecas (7%) e 
bichos de pelúcia (5%) ficaram bem atrás. Só o celular (14%) vem à frente.
Nos Estados Unidos, já no Natal do ano passado, 44% das crianças entre seis e 12 anos 
queriam ganhar um iPad de presente, apontou o instituto Nielsen.
A tela sensível ao toque dos dedos (chamada de “touch screen”) é um convite ao uso. Há 
centenas de vídeos no YouTube com crianças se divertindo com o poder do próprio toque. 
Além disso, o tablet junta tudo o que os outros eletrônicos trazem. Tem vídeos, tchau TV. 
Tem jogos, adeus, videogame. E internet, até mais computador.
MOUSE X CADARÇO
A intimidade com tablets pode ser só mais uma característica da Geração Z, crianças que 
nasceram depois da popularização da internet. Uma pesquisa da empresa AVG feita em 
dez países, como Estados Unidos, França e Japão, mostra que a ligação com tecnologia 
começa cedo.
Entre dois e cinco anos, há mais crianças que sabem jogar games (58%) do que nadar 
(20%) e amarrar cadarço (11%). Nessa idade, sabem usar um mouse (69%), abrir a inter-
net (25%) e utilizar aplicativos (19%). É cedo para tanta tecnologia? A “Folhinha” reflete 
sobre isso neste caderno especial sobre o uso de tablets na infância.
Disponível em: <http://www1.folha.uol.com.br/folhinha/1160206-tablets-caem-no-gosto-
-das-criancas-sera-a-nova-baba-eletronica.shtml>. Acesso em: 15 dez. 2015.
©shutterstock
Um Bom e um Mau Design
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
18 - 19
Baseado nisto, você pode me perguntar: Mas qual a preocupação central do 
design de interação? Segundo Preece (2005, p. 24) temos: “É desenvolver pro-
dutos interativos que sejam utilizáveis, o que genericamente significa produtos 
fáceis de aprender, eficazes no uso, que proporcionem aos usuários uma expe-
riência agradável.
Para evoluirmos mais sobre este assunto, baseando-nos em Preece (2005), 
vamos avaliar dois bons exemplos de produtos sobre o critério design de inte-
ração, um simples controle de mensagem pessoal.
Você já deve ter visto uma secretária eletrônica, tenho por convicção que, se 
você nunca usou uma, ao menos deve ter visto uma em funcionamento, seja no 
trabalho, na casa de algum conhecido ou, com certeza, em algum filme. Apesar 
de “ultrapassada”, quem sabe você ainda tenha uma em sua casa e talvez você a 
mantenha em uso por alguns dos elementos que vamos analisar na sequência.
Como vimos, talvez nem todos tenham uma secretária eletrônica em casa, 
mas com toda certeza a maioria das pessoas, senão 
todas, devem ter um aparelho celular. 
Uma das experiências mais frustrantes que 
tenho é acessar mensagens de voz que são deixa-
das em minha caixa postal quando alguém tenta 
falar comigo e não estou acessível no momento. 
Para escrever este livro, fiz uma experiência bas-
tante simples, que foi deixar uma mensagem em 
minha caixa de entrada e comparar como seria se 
estivesse recebendo a mesma mensagem em uma 
secretaria eletrônica. Estabeleci alguns critérios 
simples que terão a função de comparar como seria 
o processo de obtenção da informação em ambos 
os aparelhos.
CONCEITUANDO DESIGN E INTERAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
20 - 21I
CELULAR (VOICE MAIL) SECRETÁRIA ELE-
TRÔNICA
Saber se 
tenho uma 
mensagem 
pendente 
de avalia-
ção.
Tal informação não é disponibilizada facil-
mente, vai depender do tipo de aparelho 
e até da operadora que estiver contratada. 
No meu caso, ao ligar o aparelho recebi 
um SMS informando que recebi ligações 
enquanto estava inacessível. Também 
recebi um informativo do Voice Mail, cerca 
de um minuto depois, que tinha uma nova 
mensagem.
Após isto, passou a aparecer no meucelu-
lar um sinalizador informando que tenho 
mensagem pendente de avaliação.
Sinal visual verme-
lho piscando. 
No critério acima, julgo mais simples e mais rápido o formato da secretária ele-
trônica, apesar de o modelo apresentado pelo celular ter sido bastante simples.
Saber a 
quanti-
dade de 
mensagens 
pendentes 
de leitura.
Aqui começamos um ponto importante. 
Cerca de um minuto para saber “quantas” 
mensagens pendentes para leitura havia. O 
tempo para “pular” mensagens até chegar à 
desejada foi enorme. Outra opção que ava-
liei foi a de “apagar” mensagens, em que o 
tempo para executar a ação é muito maior 
que na execução na secretária eletrônica 
manual.
A primeira intera-
ção é informar o 
número de mensa-
gens pendentes. O 
Processo de “pular” 
sem ter que ouvir 
toda mensagem é 
muito mais rápido 
e prático.
O tempo de interação é muito maior, e ainda a falta de usabilidade, comparada 
com o formato antigo (secretária eletrônica), é muito grande. Outro ponto para 
a secretária tradicional.
Fonte: Elaborado pelo Autor
Então vamos todos jogar fora nossos modernos aparelhos e voltar ao uso de 
secretárias antigas? Não precisamos ser radicais, apenas vamos procurar apren-
der, com este rico exemplo, como um mau design pode comprometer a satisfação 
dos usuários.
Este é um exemplo simples, vemos que o processo todo pode ser:
 ■ Irritante.
 ■ Confuso.
©shutterstock
Histórico do Design de Interação
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
20 - 21
 ■ Ineficiente, exige muitos passos 
para TAREFAS BÁSICAS.
 ■ É difícil de utilizar.
 ■ Não permite saber rapidamente se 
há mensagens, quantas e como tro-
car a sequência (pular) entre elas.
 ■ Dependendo do aparelho ou ope-
radora, pode ficar mais difícil ainda o uso, pois os procedimentos não 
são tão óbvios.
Se compararmos com nossa velha amiga secretária eletrônica, vemos:
 ■ Utiliza elementos físicos familiares que indicam visualmente, de forma 
rápida, aquilo que precisamos saber.
 ■ É esteticamente fácil e agradável de utilizar.
 ■ Requer ações de apenas um passo para realizar tarefas importantes.
 ■ Design simples, mas elegante.
 ■ Oferece menos funcionalidade e permite a qualquer um ouvir as mensagens.
HISTÓRICO DO DESIGN DE INTERAÇÃO
Caro(a) aluno(a), para seu sucesso profissional, é importante que você seja 
conhecedor de diversas áreas ligadas à sua carreira escolhida. Sou defensor de 
que você, para ser um bom (boa) profissional, necessita ser especialista em um 
assunto, mas precisa ter um bom conhecimento (generalista) em diversas áreas 
relacionadas ao assunto que domina. 
©shuterstock
CONCEITUANDO DESIGN E INTERAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
22 - 23I
Fazendo uma analogia com a medicina, é importante que sejamos espe-
cialistas em uma área, que tenhamos total conhecimento em um determinado 
assunto como um médico cardiologista, entretanto, é relevante que tenhamos 
um conhecimento geral de outras áreas da medicina para que possamos exer-
cer com mais segurança nossa profissão.
Desta forma, para que seja um bom desenvolvedor, é importante ter um 
conhecimento “interessante” sobre as regras de negócio que estarão por você sendo 
desenvolvidas, da mesma forma, é importante ter um bom conhecimento sobre 
os elementos de arquitetura que devem ser observados no seu desenvolvimento, 
pois assim poderá prever possíveis impactos de desempenho e disponibilidade 
de sua aplicação. Quando fala-
mos de design de interação não 
é diferente. 
Até este ponto, você já deve 
ter percebido que existem vários 
elementos relacionados ao sucesso 
da satisfação dos nossos usuários 
com nossos produtos. No decor-
rer deste livro, ficará mais claro 
assim como você poderá mapeá-
-los e tratar de forma que não seja 
um problema.
Quantos passos seus usuários precisam dar para utilizar seus produtos? 
Em se tratando de sistemas, quantos passos o usuário precisa dar para ex-
trair uma simples informação? 
Aquilo que é realmente importante para seu usuário está acessível rápida e 
intuitivamente como o sinalizador de mensagem da secretaria eletrônica?
Considere quem irá utilizar seus sistemas, onde farão uso dele. Entenda que 
tipo de atividades as pessoas estarão realizando e em que condições quan-
do estiverem interagindo com seus produtos.
©shutterstock
Histórico do Design de Interação
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
22 - 23
Para o sucesso em design de interação, 
desde o início é conhecido que se trata de 
uma área multidisciplinar. Preece (2005, 
p.28) afi rma: “A importância de se entender 
como os usuários agem e reagem a situações 
e como se comunicam e interagem acarre-
tou o envolvimento de pessoas de disciplinas 
diferentes, como psicólogos e sociólogos, em 
questões referentes ao design de interação”.
Muitas vezes, pessoas diferentes reagem 
de forma distinta a um mesmo estímulo. Ou 
ainda pior, uma mesma pessoa pode reagir 
de forma distinta a um mesmo estímulo em 
situações diferentes! 
Como já trabalhamos neste livro, muitos 
produtos são criados sem avaliar a pessoa que irá 
usar este. Nos primórdios da computação, o mais 
importante era o hardware, o meio pelo qual a inte-
ração se daria com estes equipamentos pouco importava (pois na grande maioria 
das vezes, qualquer tipo de interação só se dava por meio dos próprios enge-
nheiros que projetavam estes equipamentos). Sendo assim, muitas vezes o que 
víamos era algo muito parecido com um painel repleto de chaves e luzes pis-
cando que, para qualquer usuário nos dias de hoje, daria arrepios, mas para eles 
que haviam projetado e interagiam com o “sistema” tinha total sentido, signifi -
cado e atendia à sua necessidade de interação. 
Apenas no fi nal da década de 70 e início da década de 80 é que o design de 
interação foi algo que começou a ser de fato considerado com o advento das esta-
ções de trabalho e com o surgimento dos monitores.
Quando falamos de projetar sistemas que sejam manipulados por pessoas, 
vamos falar fortemente de Design e Interação. O campo interdisciplinar mais 
conhecido e que será tratado nos próximos módulos deste livro é a interação 
humano-computador (IHC). Este campo está bastante focado no design, na 
avaliação e na implementação de sistemas computacionais interativos para uso 
humano e com o estudo de fenômenos que afetam este grupo.
©shutterstock
CONCEITUANDO DESIGN E INTERAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
24 - 25I
Até início dos anos 90, seu foco (IHC) era projetar interfaces para um único 
usuário. A grande maioria dos sistemas produzidos até então tinham foco no 
trabalho centralizado. Com o aumento da necessidade de trabalho em grupo, 
de interação entre elementos, da separação de trabalho, com a descentralização 
das tarefas e das ações surgiu um novo elemento, outro campo interdisciplinar 
que envolve o processo de design e interação, que é o CSCW, em inglês, compu-
ter suported cooperative work.
Outros campos relacionados a design de interação incluem fatores huma-
nos, ergonomia, psicologia, ciência cognitiva... 
E vamos tratar com mais detalhes nos próxi-
mos módulos.
A figura da página a seguir nos dá uma 
visão mais clara do conjunto de elemen-
tos envolvidos no processo de Design e 
Interação.
© Metamorfose Digital
Histórico do Design de Interação
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
24 - 25
Figura 1 – Mapa mental sobre os elementos envolvidos no design de interação 
Fonte: Adaptação de Preece (2005, p. 29)
A seguir, um breve resumo das áreas mais relevantes descritas na figura 1.
ELEMENTO INFLUÊNCIA
Ciência da 
Computação
Quando falamosde ciência da computação, estamos falando 
exatamente da área que estuda todos os avanços tecnológi-
cos. Provê avanços que permitam que novas soluções sejam 
criadas, seja através do desenvolvimento de uma nova lin-
guagem ou novas ferramentas que possam ser utilizadas por 
design para prover melhores soluções ao usuário final.
Psicologia 
Cognitiva
A psicologia é parte importante no processo de Design e Inte-
ração, entender o comportamento humano, os padrões deste 
é parte fundamental para um bom design.
Tem sido muito importante suas pesquisas ligadas à percep-
ção, atenção, memória, aprendizagem, solução de problemas.
Como as pessoas trabalham, se organizam como equipe, 
como utilizam computadores.
Estimular a aprendizagem e aperfeiçoar o desempenho huma-
no.
Psicologia 
Social
Seu principal foco é estudar o comportamento humano 
e como isto pode influenciar em nosso objeto de estudo. 
A tecnologia acaba por gerar um impacto interessante no 
comportamento humano, extrair o melhor é necessário para a 
redução de conflitos e criação de um ambiente colaborativo.
Quantas telas de sistema que desenvolvemos hoje em dia são vistas por 
nossos usuários exatamente iguais aos painéis de manipulação dos grandes 
mainframes dos primórdios da computação?
CONCEITUANDO DESIGN E INTERAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
26 - 27I
ELEMENTO INFLUÊNCIA
Fatores Huma-
nos / Ergono-
mia
Maximizar a segurança, eficiência, confiabilidade e desempe-
nho do usuário, tornando as tarefas mais fáceis e aumentar o 
sentimento de conforto e satisfação. São quesitos de grande 
relevância para um bom design ser considerado.
Tamanho de tela, tamanho de fonte, número de clicks, são 
alguns itens que precisamos pensar quando falamos neste 
assunto... Que podem ser critérios importantes para aceitação 
do usuário ou não frente ao sistema.
Ciências Sociais Não existe envolvimento direto no desenvolvimento do de-
sign, mas sim com a transferência desta tecnologia. Entender 
o que acontece com as pessoas enquanto elas se comunicam 
entre si ou com máquinas. Analisar este processo antes, duran-
te e depois.
É de extrema importância quando existe a necessidade de tra-
balho cooperativo através do uso de sistemas computacionais.
Engenharia de 
Software
A engenharia de software é peça fundamental na construção 
de aplicações que estejam antenadas a um bom design de 
interação. Dará o subsídio para que uma ideia saia do papel e 
vire um sistema.
Fonte: Preece (2005)
26 - 27
A EVOLUÇÃO DOS COMPUTADORES
Por Renan Hamann 
Você sabia que computadores já chegaram a pesar 30 toneladas e custar dois mi-
lhões de dólares? Conheça mais sobre a história da informática.
Não é segredo que o seu computador atual é fruto de uma evolução que levou dé-
cadas para chegar onde está – e ainda está muito longe de chegar ao seu final. Se 
pensarmos que cerca de dez anos atrás os processadores ainda nem conheciam 
os núcleos múltiplos, imaginar as máquinas que inauguraram a informática é uma 
tarefa ainda mais complicada.
Você sabia que no início da década de 1950 já existiam computadores? Logicamen-
te eles não se pareciam nem um pouco com o que temos hoje, mas já realizavam 
alguns cálculos complexos em pouquíssimo tempo. De lá para cá, elementos desa-
pareceram, componentes foram criados e parece até que estamos falando de assun-
tos totalmente desconexos.
Então se prepare para conhecer um pouco mais sobre essa magnífica história. Para 
facilitar a leitura, atendemos às divisões de alguns autores especializados no assun-
to e separamos a história da informática em gerações. Agora aproveite para apren-
der mais ou para conhecer a importante evolução dos computadores.
AS GIGANTES VÁLVULAS DA PRIMEIRA GERAÇÃO
Imagine como seria sua vida se você precisasse de uma enorme sala para conseguir 
armazenar um computador. Logicamente isso seria impossível, pois os primeiros 
computadores, como o ENIAC e o UNIVAC eram destinados apenas a funções de 
cálculos, sendo utilizados para 
resolução de problemas espe-
cíficos.
Por que problemas específicos? 
Os computadores da primeira 
geração não contavam com 
uma linguagem padronizada 
de programação. Ou seja, cada 
máquina possuía seu próprio 
código e, para novas funções, 
era necessário reprogramar 
completamente o computador. 
Quer mudar o problema calcu-
lado? Reprograme o ENIAC.
Esses computadores gigantescos ainda sofriam com o superaquecimento constan-
te. Isso porque em vez de microprocessadores, eles utilizavam grandes válvulas elé-
tricas, que permitiam amplificação e troca de sinais, por meio de pulsos. Elas funcio-
navam de maneira correlata a uma placa de circuitos, sendo que cada válvula acesa 
ou apagada representava uma instrução à máquina.
Com poucas horas de utilização, essas válvulas eram queimadas e demandavam 
substituição. Por isso, a cada ano eram trocadas cerca de 19 mil delas em cada má-
quina. Sim, 19 mil válvulas representavam mais do que o total de componentes uti-
lizados por um computador ENIAC. Como você pode perceber, esses computadores 
não saíam baratos para os proprietários.
TRANSISTORES E A REDUÇÃO DOS COMPUTADORES
As gigantes máquinas não estavam sendo rentáveis, pelos constantes gastos com 
manutenção. A principal necessidade era substituir as válvulas elétricas por uma 
nova tecnologia que permitisse um armazenamento mais discreto e não fosse tão 
responsável pela geração de calor excessivo, evitando superaquecimentos.
Foi então que os transistores (criados em 1947 pela empresa Bell Laboratories) pas-
saram a integrar os painéis das máquinas de computar. Os componentes eram cria-
dos a partir de materiais sólidos conhecidos como “Silício”. Exatamente, os materiais 
utilizados até hoje em placas e outros componentes, extraídos da areia abundante.
Existia uma série de vantagens dos transistores em relação às válvulas. Para come-
çar: as dimensões desses componentes eram bastante reduzidas, tornando os com-
putadores da segunda geração cem vezes menores do que os da primeira. Além dis-
so, os novos computadores também surgiram mais econômicos, tanto em questões 
de consumo energético, quanto em preços de peças.
Para os comandos desses computadores, as 
linguagens de máquina foram substituídas 
por linguagem Assembly. Esse tipo de pro-
gramação é utilizado até hoje, mas em vez 
de ser utilizado para softwares ou sistemas 
operacionais, é mais frequente nas fábricas 
de componentes de hardware, por traba-
lhar com instruções mais diretas.
Em vez das 30 toneladas do ENIAC, o IBM 
7094 (versão de maior sucesso dessa se-
gunda geração de computadores) pesava 
apenas 890 Kg. E por mais que pareça pou-
co, essa mesma máquina ultrapassou a mar-
ca de 10 mil unidades vendidas. 
Curiosidade: os computadores dessa segun-
da geração foram inicialmente desenvolvi-
dos para serem utilizados como mecanis-
mos de controle em usinas nucleares. Um 
modelo similar pode ser visto no desenho 
“Os Simpsons”, mais especificamente no posto de trabalho de Homer, téc-
nico de segurança na Usina Nuclear.
MINIATURIZAÇÃO E CIRCUITOS INTEGRADOS
O emprego de materiais de silício, com condutividade elétrica maior que a de um 
isolante, mas menor que a de um condutor, foi chamado de semicondutor. Esse 
novo componente garantiu aumentos significativos na velocidade e eficiência dos 
computadores, permitindo que mais tarefas fossem desempenhadas em períodos 
de tempo mais curtos.
Com a terceira geração dos computadores, surgiram também os teclados para digi-
tação de comandos. Monitores também permitiam a visualização de sistemas ope-
racionais muito primitivos, ainda completamente distantes dos sistemas gráfi cos 
que conhecemos e utilizamos atualmente.
Apesar das facilidades trazidas pelos semicondutores, os computadores dessa gera-
ção não foram reduzidos, sendo que um dos modelos de mais sucesso (o IBM 360, 
que vendeu mais de 30 mil unidades) chegava a pesar mais do que os antecessores. 
Nessa época (fi nal dadécada de 1970 e início da década de 1980) os computadores 
passaram a ser mais acessíveis.
Outro grande avanço da terceira geração foi a adição da capacidade de upgrade nas 
máquinas. As empresas poderiam comprar computadores com determinadas con-
fi gurações e aumentar as suas capacidades de acordo com a necessidade, pagando 
relativamente pouco por essas facilidades.
MICROPROCESSADORES: O INÍCIO DOS COMPUTADORES PESSOAIS
Enfi m chegamos aos computadores que grande parte dos usuários utiliza até hoje. 
Os computadores da quarta geração foram os primeiros a serem chamados de “mi-
crocomputadores” ou “micros”. Esse nome se deve ao fato de eles pesarem menos 
de 20 kg, o que torna o armazenamento deles muito facilitado.
Você consegue imaginar qual o componente que tornou possível essa redução das 
máquinas? Acertou quem disse que foram os microprocessadores. O surgimento 
dos pequenos chips de controle e processamento tornou a informática muito mais 
acessível, além de oferecer uma enorme gama de novas possibilidades para os usu-
ários.
Em 1971, já eram criados processadores com esse 
novo formato, mas apenas na metade da década co-
meçaram a surgir comercialmente os primeiros com-
putadores pessoais. O Altair 8800 podia ser comprado 
como um kit de montar, vendidos por revistas espe-
cializadas nos Estados Unidos. Foi com base nessa 
máquina que Bill Gates e Paul Allen criaram o “Basic” 
e inauguraram a dinastia Microsoft.
A IMPORTÂNCIA DA APPLE
Na mesma época, os dois Steves da Apple (Jobs e 
Wozniac) criaram a empresa da Maçã para se dedica-
rem a projetos de computação pessoal facilitados para 
usuários leigos. Assim surgiu o Apple I, projeto que foi 
primeiramente apresentado para a HP. Ele foi sucedido pelo Apple II, após uma inje-
ção de 250 mil dólares pela Intel.
Essa segunda versão dos computadores possuía uma versão modificada do sistema 
BASIC, criada também pela Microsoft. O grande avanço apresentado pelo sistema 
era a utilização de interface gráfica para alguns softwares. Também era possível utili-
zar processadores de texto, planilhas eletrônicas e bancos de dados.
Essa mesma Apple foi responsável pela inauguração dos mouses na computação 
pessoal, juntamente com os sistemas operacionais gráficos, como o Macintosh. Pou-
co depois a Microsoft lançou a primeira versão do Windows, bastante parecida com 
o sistema da rival.
E OS CICLOS TORNAM-SE CLOCKS
Até a terceira geração dos computadores, o tempo de resposta das máquinas era 
medido em ciclos. Ou seja, media-se um número de ações em curtos períodos de 
tempo para que fosse possível saber qual fração de segundo era utilizada para elas. 
Com os microprocessadores, já não era viável medir as capacidades dessa forma.
Por isso surgiram as medidas por clocks. Esta definição calcula o número de ciclos 
de processamento que podem ser realizados em apenas um segundo. Por exemplo: 
1 MHz significa que em apenas um segundo é possível que o chip realize 1 milhão 
de ciclos.
Grande parte dos computadores pessoais lançados nessa época eram alimentados 
por processadores da empresa Intel. A mesma Intel que hoje possui alguns dos 
chips mais potentes, como o Intel Core i7. Como você pode saber, estas máquinas 
são muito leves e puderam ser levadas a um novo patamar.
NOTEBOOKS: A QUARTA GERAÇÃO PORTÁTIL
Considerando o progresso da informática como sendo inversamente proporcional 
ao tamanho ocupado pelos componentes, não seria estranho que logo os computa-
dores transformassem-se em peças portáteis. Os notebooks surgiram como objetos 
de luxo (assim como foram os computadores até pouco mais de dez anos), sendo 
caros e de pouca abrangência comercial.
Além dos notebooks, temos também os netbooks disponíveis no mercado. Estes 
funcionam de maneira similar aos outros, mas geralmente possuem dimensões e 
configurações menos atraentes. Ganham pontos pela extrema portabilidade e du-
ração das baterias utilizadas, sendo certamente um degrau a mais na evolução dos 
computadores.
Hoje, o preço para se poder 
levar os documentos, arqui-
vos e programas para todos 
os lugares não é muito supe-
rior ao cobrado por desktops. 
Mesmo assim, o mercado 
ainda está longe de atingir 
o seu ápice. Quem sabe qual 
será o próximo passo da in-
dústria?
MÚLTIPLOS NÚCLEOS: A 
QUINTA GERAÇÃO?
Ainda estamos em transição de uma fase em que os processadores tentavam alcan-
çar clocks cada vez mais altos para uma fase em que o que importa mesmo é como 
podem ser melhor aproveitados esses clocks. Deixou de ser necessário atingir velo-
cidades de processamento superiores aos 2 GHz, mas passou a ser obrigatório que 
cada chip possua mais de um núcleo com essas frequências.
Chegaram ao mercado os processadores que simulavam a existência de dois núcle-
os de processamento, depois os que realmente apresentavam dois deles. Hoje, há 
processadores que apresentam quatro núcleos, e outros, utilizados por servidores, 
que já oferecem oito. Com tanta potência executando tarefas simultâneas, surgiu 
uma nova necessidade.
PROCESSAMENTO VERDE
Sabe-se que, quanto mais tarefas sendo executadas por um computador, mais ener-
gia elétrica seja consumida. Para combater essa máxima, as empresas fabricantes de 
chips passaram a pesquisar formas de reduzir o consumo, sem diminuir as capaci-
dades de seus componentes. Foi então que nasceu o conceito de “Processamento 
Verde”.
Por exemplo: os processadores Intel Core Sandy Bridge são fabricados com a 
microarquitetura reduzida, fazendo com que os clocks sejam mais curtos e menos 
energia elétrica seja gasta. Ao mesmo tempo, esses processos são mais eficazes. 
Logo, a realização de tarefas com esse tipo de componente é boa para o usuário e 
também para o meio ambiente.
Outro elemento envolvido nessas conceituações é o processo de montagem. As fa-
bricantes buscam, incessantemente, formas de reduzir o impacto ambiental de suas 
indústrias. Os notebooks, por exemplo, estão sendo criados com telas de LED, muito 
menos nocivos à natureza do que LCDs comuns.
.....
Não sabemos ainda quando surgirá a sexta geração de computadores. Há quem con-
sidere a inteligência artificial como sendo essa nova geração, mas também há quem 
diga que robôs não fazem parte dessa denominação. Porém, o que importa realmente 
é perceber, que ao longo do tempo, o homem vem trabalhando para melhorar cada 
vez mais suas máquinas.
Quem imaginava, 60 anos atrás, que um dia seria possível carregar um computador 
na mochila? E quem, hoje, imaginaria que 60 anos atrás seria necessário um trem para 
carregar um deles? Hoje, por exemplo, já existem computadores de bolso, como al-
guns smartphones que são mais poderosos que netbooks.
Disponível em: <http://www.tecmundo.com.br/infografico/9421-a-evolucao-dos-
-computadores.htm>. Acesso em: 25 jan. 2016.
©shutterstock
CONCEITUANDO DESIGN E INTERAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
34 - 35I
EQUIPE MULTIDISCIPLINAR
Antes de nos aprofundamos neste tema, vamos voltar um pouco ao tópico ante-
rior. Se pensarmos que os primeiros computadores começaram exigindo uma 
simples e limitada forma de interação em que a única maneira de manipulação 
era um painel de chaveamento com manipulação restrita aos engenheiros, hoje 
exigir um conjunto tão extenso de itens de análise e verificação parece algo exa-
gerado, mas na verdade não é.
Devemos imaginar que a área de software é apenas uma que exige a necessi-
dade de interação (como pudemos ver no início da primeira unidade) e, a partir 
do momento que saio de algo de uso restrito (como eram os computadores no 
seu advento) e trago para algo de uso comum, é mais do que uma expectativa de 
que temas relacionados a design sejam considerados, é uma premissa.
Para tanto, nesta perspectiva, precisamos entender que o desenvolvimento 
de soluções vai exigir uma forte interação entre diversas pessoas em uma equipe.
Ter diversas pessoas pensando no mesmo assunto significa que surgirão 
muito mais ideias, muito mais métodosnovos de se fazer as coisas, designs muito 
mais criativos e originais. 
Bem, nem tudo é um “mar de rosas”, precisamos entender que todo este 
conjunto de criatividade, originalidade e afins tem seus aspectos nem tão posi-
tivos assim, como:
1. Custo: ter uma equipe multidisciplinar como a proposta requer mais 
pessoas para meu projeto, mais pessoas representam maior investi-
mento, maior investimento vai exigir um valor maior na revenda do 
©shutterstock
©shutterstock
Equipe Multidisciplinar
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
34 - 35
meu produto que talvez o torne inviável. Tenho acompanhado várias 
empresas que atuam no desenvolvimento de sistemas e são raras aquelas 
que mantêm uma equipe multidisciplinar, o que tenho visto com mais 
frequência naquelas que estão procurando cuidar destes fatores é ter 
membros da equipe que buscam conhecimento nestas áreas rela-
cionadas (generalistas) e com isso estão mais preparados para 
lidar com estas demandas. Outra opção que tenho verificado 
é empresas que criam comitês de avaliação que são acionados 
durante uma fase do projeto em que o processo de design 
é mais exigido. Por exemplo: uma empresa 
que possui alguém da área de psicologia 
trabalhando no RH pode compartilhar 
esta pessoa durante uma fase do projeto, 
assim há contribuição e redução de custos 
andando de mãos dadas. O grande segredo está em compartilhamento 
de recursos de forma gerenciável.
2. Conflito: é praticamente impossível que duas pessoas pensem da mesma 
forma, ainda mais quando são de áreas diferentes. O que é importante 
para um pode não ser importante para outro... cada ser humano cresce 
e vê o mundo com um filtro que vem sendo formado desde sua cria-
ção, apesar de um grande conjunto de 
fatores que podemos classificar de verda-
des universais, ainda assim, cada um tem 
a liberdade de escolha para decidir o que 
quer de sua vida , assim como para anali-
sar as coisas. Um simples exemplo de como 
duas pessoas podem divergir de opinião 
pode ocorrrer com relação à beleza. 
Quando temos pessoas de áreas dife-
rentes trabalhando em um mesmo 
projeto, é importante ter em mente 
que divergências de opinião vão surgir, 
é natural e extremamente produtivo que isto 
ocorra. Saber gerenciar isto é o segredo para extrair o que cada visão 
tem de melhor e, com isto, construir algo que seja definitivamente satis-
fatório para o usuário final.
Quais recursos de sua empresa poderiam ser melhor aproveitados para 
construir uma equipe multidisciplinar gerenciável!
CONCEITUANDO DESIGN E INTERAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
36 - 37I
3. Comunicação: devemos entender que quanto maior o 
número de pessoas envolvidas no processo maior é o número 
de canais de comunicação que teremos que gerenciar. 
Para poder melhor exemplificar isto, vamos imaginar que a equipe é 
formada por apenas duas pessoas, neste caso existe apenas um canal de 
comunicação que precisa ser gerenciado (justamente entre os dois ele-
mentos). Quando o número de pessoas aumenta, o número de canais 
cresce consideravelmente, veja o exemplo a seguir.
Fonte: Elaborado pelo autor
A fórmula é bastante simples, (n² - n) / 2 , sendo n = número de pessoas que 
fazem parte da minha equipe.
Outro ponto importante para nossa avaliação é o ruído que pode haver na 
comunicação entre as pessoas. 
Equipe Multidisciplinar
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
36 - 37
Toda comunicação se dá de uma maneira formal 
ou informal e ocorre por meio de um canal (e-mail, 
carta, telefone, fala...). Esta forma de comunicação e 
este canal são suscetíveis a ruídos, ou seja, falhas de 
interpretação por uma das partes. Acredito que você 
já tenha participado de uma brincadeira na época 
do colégio chamada “telefone sem fio”, em que um 
grupo de pessoas ficam reunidas em fila e um con-
teúdo (uma pequena história) é contada e passada a 
cada participante que está participando da brinca-
deira. Geralmente, a mensagem que chega até o último 
elemento desta fila é bem diferente da que foi origi-
nalmente mencionada ao primeiro. 
Este é um simples, mas prático, exemplo de como 
a informação se perde no meio de uma comunicação, 
e imagine como isto pode repercutir negativamente 
no processo de design de uma solução!
Cada vez mais as empresas têm se preocupado 
com a maneira como Design tem contribuído, ou não, 
para o bom andamento das vendas de suas empresas.
Recordo-me de um cliente que investiu pesado na criação de um novo pro-
duto. A área de marketing teve um forte envolvimento com a área comercial 
da empresa para a criação de uma campanha de lançamento que despertasse o 
interesse dos atuais consumidores e novos. Posso dizer que o objetivo foi alcan-
çado, no dia do lançamento deste novo produto vários clientes acessaram o site 
da empresa para garantir a compra do produto, contudo, muitos deles ficaram 
frustrados pelo fato de não conseguirem finalizar suas compras.
Novo formato de interação, novo formato de comunicação projetado pela 
Google– Google Glasses.
<https://www.youtube.com/watch?v=JSnB06um5r4>. Acesso em 25 jan. 2016
Visão de futuro da Microsoft para nosso formato de interação – como será o futuro!
<http://www.youtube.com/watch?v=HFERaS8mGTg>. Acesso em 25 jan. 2016
Perceba como a informação pode se perder e como é importante cuidar de 
que todos estejam realmente falando a mesma língua!
Quais são seus cuidados para que a solicitação de seu cliente chegue ao final 
da cadeia de comunicação e não se perca?
CONCEITUANDO DESIGN E INTERAÇÃO
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
38 - 39I
Junto com o lançamento do novo produto, a empresa julgou que seria impor-
tante colocar “no ar” seu novo e-commerce. O que parecia uma boa ideia logo se 
transformou em um pesadelo. O tempo para que novos clientes e atuais conse-
guissem se adaptar ao novo sistema não foi tão rápido assim, fazendo com que 
muitos desistissem de realizar a compra do novo produto pela dificuldade de 
interação com o novo site.
Considerações Finais
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
38 - 39
CONSIDERAÇÕES FINAIS
No decorrer desta primeira unidade, estudamos sobre a importância do design 
de interação e pudemos entender como ele é relevante na vida das pessoas e qual 
sua relação com o sucesso ou fracasso de diversos produtos.
Um dos pontos mais importantes está no fato de que produtos têm que ser 
criados pensando em quem irá realmente usá-los no seu cotidiano. Infelizmente, 
vimos que muitas vezes criamos produtos e esquecemos deste detalhe fundamen-
tal, não é de se admirar que tantos e tantos produtos são criados e não chegam 
a sair da “gaveta”.
Estamos vivendo mais do que a era da internet, estamos vivendo na era da 
comunicação mobile, e isto representa que qualquer pessoa em qualquer lugar é 
um cliente potencial. Significa também que a falha ou a falta de um design ade-
quado/apropriado será um fator preponderante para o sucesso ou fracasso dos 
negócios.
Avaliamos nesta unidade como foi o processo de evolução da computação, 
como inicialmente os critérios de interação eram limitados, pois a necessidade 
de interação homem-máquina era restrita. Com o crescimento da computação 
pessoal, a partir do final da década de 70, vimos um crescimento do interesse 
nesta área.
Começamos a estudar a necessidade de envolvimento de uma equipe mul-
tidisciplinar na construção de produtos e o mesmo se aplica para a criação de 
sistemas. Um dos maiores limitadores é o alto custo da manutenção de uma 
equipe como esta, mas ressaltei também que devemos procurar com criativi-
dade, planejamento e gerenciamentousar os melhores recursos que temos à 
nossa disposição e assim prover para nossos clientes a melhor solução possível.
Na próxima unidade, darei mais detalhes sobre os critérios de usabilidade 
e quais fatores devem ser considerados com maior atenção durante o processo 
de construção de um projeto de interfaces com o usuário, elemento este que é 
componente do processo de design e interação.
1. Na realidade das empresas de sistemas de sua região, quais opções você 
avalia que poderiam ser consideradas para que os elementos relacio-
nados a design de interação fossem considerados no desenvolvimento 
de seus produtos?
2. Quando falamos de uma equipe multidisciplinar para a construção de 
soluções, quais os elementos (pessoas) que você avalia imprescindí-
veis para sua empresa?
3. Descreva como foi o processo de evolução da computação das últi-
mas décadas e como a necessidade de interação evoluiu neste período.
U
N
ID
A
D
E II
Professor Esp. Ricardo Francisco de Pierre Satin
ENTENDENDO MAIS SOBRE 
CRITÉRIOS DE USABILIDADE
Objetivos de Aprendizagem
 ■ Entender a importância do bom desenvolvimento de uma interface 
para propiciar a interação humano-computador.
 ■ Avaliar como as pessoas interagem com objetos e como isto pode 
ser utilizado em meu processo de desenvolvimento de design e 
interação.
 ■ Compreender o que é usabilidade e sua aplicação no 
desenvolvimento de aplicações WEB.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ O que é interface e Interação Humano-Computador (IHC)
 ■ Como as pessoas interagem com objetos
 ■ Usabilidade
 ■ Usabilidade na WEB
42 - 43
INTRODUÇÃO
Caro(a) aluno(a), nesta segunda unidade, vamos evoluir sobre os conceitos de 
design e interação, só que agora vamos nos aprofundar especificamente sobre 
o componente que classifico mais importante, que é a interação humano-com-
putador (IHC). 
Vamos tratar sobre os princípios de usabilidade que tornam as aplicações 
mais fáceis de usar e vamos explorar os conceitos ligados a aplicações tradicio-
nais (desktop) baseadas na internet assim como aplicações móveis. 
Nosso universo competitivo exige que cada vez mais façamos mais com 
menos, ou seja, sejamos mais produtivos, mais ágeis, façamos produtos com maior 
qualidade, tudo isto sem que haja necessidade de incharmos as organizações.
Recordo-me de uma empresa que estava em processo de expansão e que, 
como parte do processo, decidiu pela troca do sistema de gestão que utilizava por 
outro mais atual. Esta empresa, apesar de lucrativa, era bastante ineficiente em 
seu setor administrativo, precisando de uma quantidade relativamente grande 
de funcionários para que todo processo de retaguarda (controle financeiro, esto-
que, fiscal, contábil...) pudesse ser executado. Um dos principais benefícios que 
a empresa teve na troca do sistema foi o ganho de agilidade nas atividades diá-
rias de sua equipe. Este ganho de agilidade estava intimamente relacionado aos 
benefícios que a usabilidade do novo sistema trouxe à empresa. 
Ser mais rápido, mais intuitivo, facilitar o aprendizado são fortes princípios 
de usabilidade que a interação humano-computador deve cuidar.
Recordo-me de outra grande empresa que era obrigada a manter uma equipe 
de treinamento para frequentemente capacitar novos colaboradores da empresa no 
sistema que utilizava. Não vejo nada de errado em uma empresa ter uma equipe 
como esta, na verdade pode até se tornar um diferencial competitivo frente às 
concorrentes se esta estiver focada, por exemplo, na melhoria do conhecimento 
dentro da empresa, otimização de processos, apoiar áreas a reduzir o tempo de 
trabalho em rotinas operacionais, apoiar na extração de informações para tomada 
de decisões estratégicas. O que não poderia ocorrer, contudo, era a manutenção 
de uma equipe como aquela, pois o sistema que possuía era tão complexo que 
dificultava o aprendizado de um colaborador novo.
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
42 - 43
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
44 - 45II
Veja como falhas de design podem custar caro para empresas e pode ser ainda 
pior se avaliarmos o critério cliente. Como vimos na unidade anterior, empre-
sas podem estar deixando de fidelizar clientes e de realizar novas vendas pelo 
simples fato de ser difícil navegar em seu site/sistema.
Recordo-me de uma vez que desisti de comprar um livro no site de uma edi-
tora e optei por comprar em outra, pagando um frete maior, pelo simples fato de 
não aguentar mais começar a fazer o pedido “tudo de novo”, pois frequentemente 
alguma coisa inesperada acontecia e me fazia perder todos os dados já inseridos.
INTERFACE/INTERAÇÃO HUMANO-COMPUTADOR 
(IHC)
Primeiramente precisamos diferenciar uma coisa da outra. Interface humano-
computador não é a mesma coisa que interação humano-computador. Podemos 
resumir que a interface humano-computador é um dos meios pelo qual ocorre 
a interação humano-computador.
De acordo com Rocha (2003), quando o conceito de interface surgiu era 
focado em prover um meio de comunicação de hardware e o software com o qual 
o homem e computador poderiam se comunicar. Com o passar do tempo, este 
conceito evoluiu, vimos que há necessidade de atenção em aspectos como capaci-
dade cognitiva e emocional dos usuários durante este processo de comunicação.
Precisamos prover interfaces que possam dar maior poder ao usuário final, 
mas este poder tem que ser de fácil aplicação. Um bom exemplo são os pacotes 
de edição de texto ou planilhas eletrônicas. 
Quando migrei a versão do meu Office 2003 para o Office 2007, tive um 
pequeno choque com a mudança dos locais dos ícones e funcionalidades, mas 
rapidamente me adaptei. Minha primeira impressão foi de rejeição, já estava acos-
tumado com as teclas de atalho, com o local onde as funcionalidades estavam. 
Exatamente no dia em que atualizei a versão, precisei utilizar o Excel, tra-
tava-se de algo urgente, precisava entregar uma planilha para meu chefe. A 
©shutterstock
Interface/Interação Humano-Computador (IHC)
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
44 - 45
minha primeira impressão foi ruim, em um primeiro acesso não encontrava 
mais nada! Aos poucos me adaptei e consegui tirar proveito dos benefícios que 
a nova interface propiciou. 
Conheço pessoas que até hoje têm dificuldade com a nova interface, pois 
como o uso da ferramenta é básico, as mudanças e evolução não lhe trouxeram 
nenhum proveito, apenas confusão por mudar de lugar “aquilo que já funcio-
nava” perfeitamente.
Quando tratamos de interface, temos que tomar este cuidado, não gerar a per-
cepção ao usuário de que tudo que foi feito foi estragar o que já funcionava antes.
Antes de continuar, precisamos entender um pouco sobre como foi a evo-
lução deste formato de interação até chegar os dias atuais. No início, na época 
dos primeiros computadores, a interface de comunicação entre homem e com-
putador se dava por meio de chaves e mostradores. O uso de cartões perfurados 
foi um avanço neste formato de comunicação até chegar às primeiras formas de 
interface via linha de comando, em que, mediante de instruções digitadas, ope-
rações eram disparadas. 
As primeiras interfaces orientadas por menu eram bem simples, textuais, 
como uma forma de organizar hierarquicamente as operações possíveis. Este foi 
um passo fundamental para o estabelecimento de um conceito de que homem 
e máquina necessitam, para “conversar”, de uma interface de comunicação, esta 
que começa a se estabelecer como sendo uma “tela de sistema”. Hoje, usamos 
formas de interface que evoluíram deste formato. 
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
46 - 47II
Os primeiros computadores Macintosh da Apple estabeleceram um con-
ceito que é quase impossível de desassociar de interface homem-computador, 
que é uma interface baseada em ícones, menus, barras de rolagem, cursores que 
mudam de formato. São, sem dúvida, um avanço no que diz respeito do formato 
de interação, mas IHC é bem mais do que isto.
Este formato de interface utilizado pela Apple é também fortemente difundido 
pela Microsoft em suas versões do sistema operacional Windows, cujo nome é 
uma metáfora que faz alusão à facilitação do trabalho a ser executado pelo usuário. 
Que recursos você tem usado para facilitar a compreensão do usuário para 
usar seu sistema de forma mais eficiente?
©shutterstock
Interface/Interação Humano-Computador (IHC)
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
46 - 47
É evidente que o usuário em uma operação 
em que tem que transferir parte de um texto, 
digitado inicialmente em uma página para 
outra página do documento, fazendo uso do 
comando copiar e colar não vai fazer uso de 
nenhum recurso que venha a “colar” fisica-
mente o texto, mas é uma menção a algo que 
estamos acostumados no dia a dia de que tem 
o objetivo de facilitar o entendimento do que 
se espera que seja feito com tal instrução. 
A HISTÓRIA DA INTERFACE GRÁFICA
Por Felipe Arruda 
A forma como os humanos interagem com os computadores sempre foi uma preocu-
pação da indústria da informática. Durante algumas décadas, essa interação passou da 
linha de comando, em modo texto, para desktops em três dimensões e softwares que 
aceitam comandos por voz ou gestos com o propósito de facilitar e tornar mais intuitiva 
a utilização das máquinas.
Como boa parte das tecnologias existentes, a ideia de uma Interface Gráfica do Usuário 
(GUI) começou muito tempo antes de possuirmos a tecnologia necessária para imple-
mentá-la. Uma das primeiras pessoas a pensar nessa possibilidade foi o engenheiro, in-
ventor e político Vannevar Bush.
O que transformou Bush em um pioneiro da área foi a percepção de que os meios de ar-
mazenamento de informações não estavam mais comportando tantos dados. A máqui-
na imaginada por Bush, chamada de Memex, era capaz não apenas de armazenar tanta 
informação, como também de relacioná-las e oferecer uma maneira fácil de procurá-las 
em meio a tantos dados.
O pai do mouse e da interface gráfica
Inspirado pelo trabalho de Vannevar Bush, o engenheiro elétrico Douglas Engelbart 
visualizou a possibilidade de usar computadores para aumentar o intelecto humano, 
em vez de substituí-lo. Ele acreditava que, com informações dispostas em uma tela, o 
usuário poderia se organizar de maneira gráfica e pular de uma informação para outra, 
sempre que necessário.
Como no caso do Memex, as ideias de Engelbart estavam muito à frente de sua época. 
Em 1962, até mesmo interfaces em modo texto, com comandos sendo executados em 
tempo real, eram consideradas como “de outro mundo”, já que os mainframes da época 
eram operados com cartões perfurados e 
demoravam horas ou dias para entrega-
rem o resultado do processamento.
Em 1968, depois de conseguir um finan-
ciamento para suas pesquisas, Engelbart 
e sua equipe demonstraram o potencial 
dos computadores e de alguns disposi-
tivos de entrada. Entre os “periféricos”, 
estava uma caixa retangular, com três 
botões na parte de cima e conectada ao 
computador por um cabo: era um dos 
primeiros modelos de mouse da história, inventado pelo próprio Engelbart e construído 
por um dos engenheiros da equipe.
Os softwares desenvolvidos para esse computador ainda não trabalhavam com o con-
ceito de janelas, como nas interfaces atuais.
Janelas: cada um no seu quadrado
Com o surgimento da Smalltalk, linguagem de progra-
mação e ambiente de desenvolvimento que possuía 
uma interface gráfica diferenciada, a GUI começou a ga-
nhar aspectos mais modernos, em 1974.
A grande inovação foram as janelas, que possuíam bor-
das e barras de títulos que permitiam a identificação e o 
reposicionamento delas. O conceito de ícones também 
surgiu na mesma época, assim como o menu de contex-
to. No mesmo período, também foram apresentadas as 
barras de rolagem, as caixas de diálogo e os botões de 
opções (radio buttons).
A chegada da Apple
Outro passo importante na história das interfaces grá-
ficas foi dada pela startup criada por Steve Jobs e Steve 
Wozniak, em 1976. Com a contratação de ex-funcioná-
rios da Xerox, a Apple pode iniciar o desenvolvimento 
do computador pessoal Lisa, em 1978.
A equipe de desenvolvedores trabalhou em uma inter-
face baseada em ícones, em que cada um deles indicava 
um documento ou uma aplicação. Além disso, a equipe 
criou a primeira barra de menu desdo-
brável (pull-down), que hospedava 
todos os menus logo nas primeiras 
linhas da tela.
O mouse, que havia se consagrado 
com três botões, passou a ter apenas 
um no Lisa e, como a interface exigia 
pelo menos duas ações para cada 
ícone, uma para selecionar e outra 
para executar o programa ou arqui-
vo, foi criado o conceito de duplo 
clique.
Outras interfaces da época
A VisiCorp era uma das empre-
sas que também estava traba-
lhando em interfaces gráficas 
para computadores pessoais. 
Responsável pela planilha ele-
trônica VisiCalc, a empresa lan-
çou uma interface para PCs, em 
1983, mas que não chegou a fa-
zer muito sucesso. Além do pre-
ço alto e de exigir muito recurso 
de hardware, a VisiOn, como era 
chamada, também teve alguns 
retrocessos, como deixar de 
usar ícones e eliminar o cursor 
do mouse.
Outra interface que surgiu 
na década de 80 foi a Tandy 
DeskMate, da Tandy Compu-
ters, e a GEM, que fornecia uma 
interface gráfica para o DOS e 
era tão parecida com a inter-
face do computador Lisa que 
a Apple chegou a processar os 
fabricantes.
Em 1986, a Berkeley Softworks 
lançou a GEOS, interface para 
computadores Commodore 64 
e Apple, que tinha uma apa-
rência parecida com a da GEM. 
Mais tarde, essa GUI foi porta-
da para PCs e, com isso, acabou 
se tornando uma concorrente 
para a Microsoft, que havia 
anunciado a primeira versão 
do Windows em1983.
Vale a pena lembrar que, no 
começo, a Microsoft trabalhava 
como uma empresa terceiriza-
da para a Apple e, por isso, tes-
tou os modelos em fase Beta dos 
Macs. Isso serviu de inspiração 
para a criação da sua interface 
gráfica e, durante o lançamen-
to do Windows 2.0, a empresa 
chegou até a ser processada 
pela Apple.
Em 1987, também surgiu um 
novo conceito no mundo das 
GUIs: o Dock. A responsável 
pela criação foi a empresa 
Acorn Computers, que desen-
volveu a Arthur, interface que 
também foi a primeira a usar 
fontes com anti-aliasing, mes-
mo em modo de 16 cores.
Já a NeXTSTEP, em 1988, foi a interface que introduziu uma aparência 3D aos seus com-
ponentes, além de ter sido a primeira a usar o botão em forma de “X” para fechar janelas. 
Na mesma época, também surgiu a primeira versão gráfica do OS/2, projeto colabora-
tivo entre Microsoft e IBM para desenvolver um sistema que pudesse substituir o MS-
DOS. A interface da versão 1.1 era muito similar à do Windows 2.0.
No fim dos anos 80, muitas in-
terfaces gráficas começavam 
a surgir para as estações Unix. 
Essas GUIs eram executadas 
sobre um sistema gráfico e 
com suporte à rede, conhecido 
como X. Mais tarde, esse siste-
ma também se tornou a base 
dos ambientes gráficos do 
Linux. Uma das novidades do 
X Window System foi o fato de 
poder habilitar o foco em uma 
janela apenas posicionando 
o mouse sobre ela, sem clicar. 
Atualmente, muitos projetos 
gráficos ainda fazem uso do 
X, com o KDE e o GNOME, que 
teve sua terceira versão lança-
da nesta semana.
As interfaces mais recentes
Durante os anos 90, apenas 
duas empresas resistiram à “pe-
neira” do mercado: a Microsoft 
e a Apple. As demais entraram 
em falência ou foram adquiri-
das por outras companhias.O Windows ganhou muita po-
pularidade com as versões 3.0, 
em 1990, e 3.1, em 1992. Ape-
sar de ainda não ter alguns re-
cursos simples, que já estavam 
implementados no Macintosh, 
foram vendidas milhões de có-
pias dessas versões do sistema 
da Microsoft. Mais tarde, com a 
chegada do Windows 95, a em-
presa de Bill Gates se consoli-
dou como a líder do mercado e 
detentora de um dos softwares 
mais famosos até hoje.
Quando o cenário já parecia ter 
se estabilizado, eis que surge 
uma novidade: o BeOS, siste-
ma operacional da Be Incorpo-
rated, com uma interface em 
que a barra de título lembrava 
a do Smalltalk, ocupando ape-
nas parte de toda a extensão 
das janelas. Um versão open 
source do BeOS continua em 
desenvolvimento, sob o nome 
de Haiku.
A Apple também continuou 
inovando e lançou a interfa-
ce Aqua, para o novo sistema 
operacional da empresa, o Mac 
OS X. Além da aparência nova, 
uma das principais novidades 
da Aqua era o fato de que as 
janelas podiam ser redesenha-
das rapidamente, de maneira imperceptível aos olhos, quando movidas ou redimensio-
nadas.
Outras inovações ficaram por conta dos efeitos de animação executados durante o ato 
de minimizar programas. Em versões mais recentes, a empresa também adicionou o 
conceito de Exposé, que mudou a forma como as pessoas alternavam entre os softwares 
abertos na área de trabalho.
A Microsoft também conti-
nuou inovando. Com o lança-
mento do Windows Vista, pu-
demos ver a estreia do Aero, 
responsável pelos efeitos visu-
ais de sombra e transparência 
da Área de trabalho. Com o 
Windows 7, a interface foi apri-
morada, ganhando suporte a 
telas touchscreen e multitouch, 
além de apresentar uma barra 
de ferramentas totalmente re-
formulada e o Aero Shake, que 
permite interação com as jane-
las ao “sacudilas”.
O Windows 7 também ganhou 
efeitos 3D, semelhantes aos 
proporcionados pelo Compiz, 
no Linux. O próprio Compiz 
acabou se inspirando no Expo-
sé, da Apple, para fornecer um 
efeito semelhante sobre o X 
Window System.
Os recursos 3D parecem ser a 
última cartada das interfaces 
gráficas, que agora começam 
a se adaptar aos novos disposi-
tivos portáteis e operados por 
toques na tela, com os dedos. 
Outro recurso que está ganhando força é o chamado Desktop Semântico, que trabalha-
rá não apenas com os arquivos, mas também com o conteúdo e a informação contextu-
al ao manipular esses arquivos.
Disponível em: <http://www.tecmundo.com.br/historia/9528-a-historia-da-interface-
-grafica.htm>. Acesso em: 25 jan. 2016.
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
54 - 55II
INTERAÇÃO HUMANO-COMPUTADOR E INTERFACE 
HUMANO-COMPUTADOR SÃO SINÔNIMOS?
Por algum tempo interação humano-computador pode até ser considerada como 
um sinônimo de interface humano-computador, especialmente se avaliarmos 
que é por meio de interfaces que ocorre qualquer tipo de troca de informação 
entre homem e máquina. 
Com o passar do tempo, pesquisadores perceberam que existem outros fato-
res que estão intimamente relacionados a esta interação entre homem e máquina. 
É fato que os computadores existem com a finalidade de executar tarefas ou 
apoiar nos processos diários dos serem humanos, eles existem para enrique-
cer nosso trabalho, nos dar mais poder, auxiliar nos processos de decisão e por 
aí vai. É outro fato que nós, seres humanos, temos limitações e capacidades das 
mais diversas, unir o melhor dos dois mundos (homem e máquina) é algo que 
os pesquisadores têm procurado encontrar há um bom tempo.
O termo Interação Humano-Computador (IHC) foi adotado em meados dos 
anos 80 como o meio pelo qual esse estudo está sendo direcionado. Desta forma, 
vemos que os estudos vão mais além que a análise de interface.
Segundo Rocha (2003), uma das melhores definições de IHC é a disciplina 
preocupada com o design, avaliação e implementação de sistemas computacio-
nais interativos para uso humano e com o estudo dos principais fenômenos que 
o rodeiam.
Conforme podemos ver em Rocha (2003, p.15) 
IHC trata do design de sistemas computacionais que auxiliem as pes-
soas de forma a que possam executar suas atividades produtivamente 
e com segurança. IHC tem, portanto, papel no desenvolvimento de 
todo tipo de sistema, variando dos sistemas de controle de tráfego aéreo 
onde segurança é extremamente importante, até sistemas de escritório 
onde produtividade e satisfação são os parâmetros mais relevantes, até 
jogos, onde o envolvimento dos usuários é o requisito básico.
Apesar de não ser uma tarefa fácil, é algo que tem que ser priorizado dentro das 
empresas de sistemas. Vejo muitas empresas gastarem tempo e dinheiro contro-
lando as fases de desenvolvimento de um novo produto, utilizando as melhores 
técnicas de controle de projeto, defendendo o escopo com “unhas e dentes”, 
Entenda que existe uma diferença grande entre seguir uma tendência e pla-
giar o que está sendo lançado, cuidado com isto!
Interação Humano-Computador e Interface Humano-Computador são Sinônimos?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
54 - 55
gerenciando o prazo das entregas, sendo completamente profissionais no desen-
volvimento e comprometimento do que tem que ser entregue ao cliente, contudo, 
esquecem de levantar o escopo de interação necessário para que suas ferramentas 
sejam atrativas aos usuários. Nas próximas unidades, pretendo trazer mais infor-
mações para você de maneira que esteja protegido do problema descrito acima.
Como comecei no parágrafo anterior, não se trata de uma tarefa fácil, outros 
desafios que existem e devem ser considerados são o aumento da capacidade de 
processamento cada vez maior dos equipamentos e a disponibilidade de recur-
sos (som, imagem, textos, realidade virtual...) cada vez mais ilimitados. Projetar 
soluções que considerem estes recursos, as limitações humanas e que forneçam 
feedback de qualidade ao usuário, de forma que este se sinta “empodeirado“ e 
não confuso, é um desafio e tanto.
Seguir padrões já estabelecidos, obedecer as tendências é sempre uma boa 
forma de ajudar nossos usuários a se “sentir em casa” quando precisam utilizar 
nossos sistemas.
Quando o Office 2007 foi lançado, ele ditou a tendência para diversos outros 
sistemas que vieram a seguir. É inegável que muitos usuários de sistemas comer-
ciais passam a maior parte do tempo manipulando suítes como o Office, suas 
tarefas diárias exigem uma forte necessidade de interação com ferramentas de 
edição de texto, planilhas eletrônicas ou clientes de e-mail. É natural que, com 
o uso frequente de aplicações como estas, os usuários se tornem ágeis e, conse-
quentemente, procurem por outras ferramentas que tenham um padrão similar 
de interação.
Recordo-me que nesta época houve um grande “alvoroço” nas empresas de 
sistemas procurando dar formatos de interação que se assemelhassem ao Office 
2007. O que elas estavam fazendo é uma prática muito interessante que tem por 
objetivo tornar o aprendizado dos usuários mais fácil. 
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
56 - 57II
Atualmente vemos o mesmo ocorrendo com o lançamento do Windows 
8 e, na verdade, o próprio Windows 8 seguindo uma tendência que foi criada 
pela Apple, que foi o novo formato de interação disponibilizado para seus apa-
relhos celulares.
Aprendi dirigir carro em um veículo básico, popular, desde lá dirigi vários 
veículos desde mais simples até de maior luxo e todos eles sem grandes proble-
mas. Se pegarmos a indústria automotiva como exemplo, percebemos que temos 
muito a aprender com eles. 
Você não encontrará um veículo que se comporte de forma diferente de outro, 
na verdade o que você vai encontrar é uma gama de funcionalidades que estarão 
disponíveis em um modelo e no outro não, mas dificilmentevocê encontrará uma 
funcionalidade em um veículo que se comporte de forma diferente em outro. 
Vamos pegar um simples exemplo, o controle de marcha ré. Na indústria 
brasileira, me recordo agora de dois formatos de acionamento desta marcha em 
um veículo com câmbio mecânico, agora, quando vamos para câmbio automá-
tico, é praticamente um padrão. Se você usou este tipo de recurso em um veículo 
de uma montadora alemã, americana ou asiática, não terá dificuldades no uso 
de uma outra qualquer.
Vemos que praticamente todos os dispositivos básicos são iguais, o que geral-
mente muda é a disposição no painel, mas sem grandes mudanças também. O 
que muda é o design, o acabamento.... está aí o diferencial. 
Como seria se nossos sistemas se comportassem da mesma forma? Imagine 
você como se tornaria mais fácil a vida de nossos usuários! Como auxiliaríamos 
seu processo de aprendizado, como seria mais simples sua execução de tarefas e, 
com certeza, como ele se sentiria mais satisfeito ao usar um sistema como este.
Suas aplicações estão preparadas para trabalhar com o Windows 8?
E se você concentrar seus esforços buscando o diferencial competitivo em 
outros quesitos...!?
Interação Humano-Computador e Interface Humano-Computador são Sinônimos?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
56 - 57
Afinal de contas, o objetivo da IHC é produzir sistemas que saiam realmente 
da gaveta. Que sejam úteis, utilizáveis, seguros, funcionais, que agreguem poder 
e valor ao usuário.
Podemos dizer que sistemas como este são aceitáveis e, conforme definido 
por Nielsen (1993), podemos ter dois tipos de aceitabilidade: aceitabilidade 
social e prática. Quando ambas são positivas, podemos dizer que um sistema 
apresenta uma aceitabilidade geral e, com isto, há grandes chances deste pro-
duto ter sucesso real.
Vamos entender um pouco mais sobre estes dois itens.
1. Aceitabilidade social. Está intimamente relacionada à forma como a socie-
dade que é afetada pelo sistema vê seu uso. Tenho dois bons exemplos 
que quero compartilhar contigo. 
Acredito que ninguém aceita muito bem chegar em um banco e ficar 
preso em sua porta giratória, não é? Apesar de entendermos o motivo 
de sua aplicação, é constrangedor passar por uma situação como esta. 
Desenvolvi alguns anos atrás um sistema para uma empresa que passaria a 
controlar o acesso às suas dependências. Com a entrada em funcionamento 
deste novo sistema, todas as pessoas que circulavam nas dependências da 
empresa deveriam estar devidamente identificadas e, para alguns seto-
res, haveria necessidade de registro de sua circulação.
Este registro forçava que houvesse uma abordagem a estas pessoas para 
saber onde estavam indo. Como não era algo usual na empresa, houve 
uma grande rejeição no início do uso. Ninguém questionava os motivos 
pelo qual os registros eram gerados, todos entendiam que se tratava da 
própria segurança da empresa e de seus funcionários, mas era algo que 
gerava desconforto nas pessoas.
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
58 - 59II
Está aqui um dos maiores motivos de insucesso nos sistemas, a falta de 
aceitação social. Boas ideias podem fracassar se a sociedade não “com-
prar” a ideia.
2. Aceitabilidade prática: estamos falando da aceitação do custo da ferra-
menta (este é um critério muito importante dentro das organizações), 
confiabilidade no produto, compatibilidade com outros sistemas exis-
tentes ou versões anteriores de seu produto, segurança das informações, 
segurança no fornecedor do produto (credibilidade)... este princípio de 
aceitação leva à definição de outro conceito denominado “usefulness”.
“Usefulness” se refere ao fato de um sistema poder ser utilizado para aten-
der a um objetivo, sanar um problema, atender a uma necessidade. Na 
essência, só existe a necessidade de usar um sistema de informação se há 
um problema que precisa ser resolvido, e é aqui que entra este conceito 
que estamos estudando e que ele nos leva a pensar em duas novas clas-
sificações, que é a Utilidade e a Usabilidade.
Um sistema só vai ter utilidade para quem for fazer uso dele se o mesmo 
for realmente “útil” para resolver o problema que existe, ou “útil” para 
atender a uma necessidade que tenha surgido, podemos dizer que um 
sistema tem utilidade quando este faz o que realmente se propõe a fazer. 
Um sistema antivírus é útil quando este, realmente, protege seu compu-
tador de sistemas maliciosos. 
Um sistema só vai ser usável (ter usabilidade) quando os usuários conse-
guem, realmente, fazer uso das funcionalidades propostas pelo sistema, 
e este é um conceito CHAVE para IHC.
Em resumo, podemos dizer que um sistema, para ter sucesso, precisa ser 
socialmente aceito, precisa ter aceitação prática dentro da empresa, neces-
sita ser útil e realmente utilizável pelos usuários finais. 
A falta de um dos quatro elementos acima pode sacramentar a “morte” 
de sua aplicação! É papel da IHC garantir a boa integração entre os ele-
mentos acima.
©shutterstock
Como as Pessoas Interagem com Objetos?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
58 - 59
COMO AS PESSOAS INTERAGEM COM OBJETOS?
Certamente você já deve ter parado por alguns instantes frente a uma porta e 
pensou: puxo, empurro ou deslizo? 
Os eletrodomésticos têm tantos recursos que difícil é fazer ele ser útil. Outro 
dia estava observando minha sogra utilizar pela primeira vez sua nova máquina 
de lavar roupas, levou cerca de uma hora até conseguir fazer a máquina funcio-
nar e, finalmente, lavar sua roupa.
É fato, como já conversamos no início deste livro, que os produtos não são 
criados pensando exatamente em seu uso pelos compradores, as inovações sur-
gem a cada momento, o número de novos produtos lançados no mercado cresce 
a cada ano, mas o número de frustração frente ao uso também.
É possível evitar isto e, antes de entrar mais detalhadamente em usabilidade, 
quero conversar contigo sobre a forma como as pessoas interagem com os mais 
diversos objetos, e isto inclui sistemas! 
Norman (1998) estabeleceu quatro princípios bastante simples que deve-
mos observar, são eles:
1. Visibilidade
Outro dia um possível cliente que assistia uma apresentação comercial 
soltou uma frase que me chamou atenção, ele disse: “Tudo isso?”.
©shutterstock 
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
60 - 61II
Ele se referia ao número de opções que existiam no menu de um sistema 
que estava sendo apresentado. É óbvio que contornamos informando que 
todas aquelas opções estavam visíveis naquele momento pois precisáva-
mos mostrar tudo o que o sistema tinha para oferecer, mas, na verdade, 
lá no fundo percebi que o sistema tinha uma coisa negativa para ofere-
cer que era a dificuldade de achar a informação.
O conceito de visibilidade fala justamente sobre isto, deixe visível só 
aquilo que é importante e vai ser utilizado.
Outra característica importante da visibilidade é que ela deve fornecer 
ao usuário a maneira como deve ser operado aquilo que está disponí-
vel para ele.
Visibilidade deve ser usada para distinguir as coisas dentro de um sis-
tema. Visibilidade deve dar ao usuário fácil acesso a um conjunto de 
recursos desejado por ele.
A Visibilidade deve dar clareza ao usuário se o resultado que se esperava 
alcançar com a execução de uma tarefa foi alcançado ou não. Como em 
um carro, ao pisar no acelerador para atingir a velocidade de 60 km/hr, 
devo ter a informação clara, por meio do velocímetro, se isto foi atin-
gido ou não.
Um dos maiores inimigos da visibilidade é a estética. Muitas vezes por 
quesitos estéticos, mensagens ou infor-
mações são omitidas dificultando 
assima vida dos usuários. Imagine 
como seria mais fácil se uma “seta” 
estivesse em toda porta para deixar 
mais clara a direção de abertura desta!
Dentro de visibilidade, existe um cri-
tério ao qual temos que estar atentos, 
que é a determinação de como aquele 
objeto deveria ser usado. A isto cha-
mamos Affordance (mostre o caminho 
para o usuário). Quando pensamos 
©
shutterstock
©
sh
ut
te
rs
to
ck
Como as Pessoas Interagem com Objetos?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
60 - 61
em um vidro, logo vem à nossa mente que este deve ser utilizado para tra-
zer visibilidade ao local; quando pensamos em madeira, esta nos remete 
à sustentação; quando pensamos em uma poltrona, somos impelidos a 
lembrar que podemos fazer uso desta para nos sentar.
O mesmo critério tem que ser pensado em um produto quando estamos 
projetando. Cada elemento de uma tela de sistema deve ser avaliado sobre 
o que ele lembra sobre seu uso. Quando colocamos um botão, remete-
mos a ideia de algo que deve ser pressionado, e por aí vai.
2. Bom modelo conceitual 
Quando projetamos sistemas, precisamos levar isto em 
consideração, ele nos permite prever o efeito das ações. 
A ideia por trás disto é que, mesmo que nunca tenha-
mos operado um sistema como este anteriormente, 
possamos prever o que vai acontecer, executar e 
então aprender.
Um bom modelo conceitual faz uso de vários ele-
mentos com forte Affordance é claro, procurando 
torná-los quase óbvio.
Podemos pegar como um bom exemplo um reló-
gio analógico. Mesmo que você nunca tenha 
mexido em um relógio como este antes, com 
certeza você conseguirá fazer uso dele. Geral-
mente, é dotado de um único botão por meio 
da qual você pode ajustar as horas do reló-
gio e também ajustar o calendário. O botão é 
dotado de forte Affordance, pois você já associa 
a ideia de que ele está ali para ser girado, pres-
sionado ou, quando muito, puxado (sua posição, 
muitas vezes ao lado do “quadrado” com o calen-
dário é um outro bom exemplo de indução de que 
“é ali” que você tem que interagir).
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
62 - 63II
Agora, se avaliamos um relógio digital, é desesperador o número de 
opções que este possui, e o número limitado de meios de interação que 
requer uma combinação grande entre estes elementos (“aperte o botão da 
direita e gire o da esquerda” ou ainda “acesse ‘n’ menus para ter acesso à 
opção desejada”). Com certeza, não é um bom exemplo de “bom modelo 
conceitual”.
Já devo ter me deparado com diversas telas de sistema que são piores 
que relógios digitais. Em fevereiro de 2012 estava apoiando um projeto 
e, ao testar o sistema gerado por este projeto, fiquei horrorizado. Com 
certeza, não foi observado nenhum modelo conceitual, nada era óbvio, e 
como resultado disto, este projeto ficou mais quatro meses em processo 
de maturação até ter condições de ser ofertado ao público. Perceba o 
impacto que uma má avaliação de design pode gerar para uma empresa!
3. Bons mapeamentos
Nada mais natural para um bom processo de aprendizado do que ter 
uma boa correlação entre aquilo que acontece no mundo real dentro de 
um sistema.
Um bom mapeamento nada mais é do que isto, mapear as entidades em 
seu correto funcionamento. No caso de sistemas, mapear o funciona-
mento da interface com os controles/execuções que se espera que ela faça.
Uma analogia com veículos, quando estamos dirigindo e queremos virar 
à direita, basta virar o volante para esta direção. Um bom mapeamento 
está em identificar qual objeto devo manipular para ter o resultado espe-
rado e qual deve ser o estímulo/dado que devo aplicar.
Recordo-me que, em 2012, chegou até mim uma nova interface de con-
ciliação bancária produzida por minha equipe. Simplesmente todos os 
princípios de mapeamento foram desconsiderados, novamente, mais 
retrabalho e atraso na entrega.
4. Feedback
O feedback é algo que deve ser dado ao usuário após cada interação 
realizada, este precisa ser informado se o que esperava que fosse feito 
©shutterstock
Como as Pessoas Interagem com Objetos?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
62 - 63
realmente o foi e, caso a resposta seja 
negativa, o que precisa ser feito de 
um modo diferente para ter sucesso 
da próxima vez. 
Este tipo de comunicação é muito 
falho na maioria dos sistemas de 
informação. Quando interagimos 
com sistemas mais complexos, a 
coisa fica ainda pior. Vamos avaliar 
uma situação que já se tornou corri-
queira para a maioria das empresas, 
que é a emissão de uma nota fis-
cal eletrônica. Para poder nivelar o 
conhecimento, a seguir, vou trazer uma breve descrição do seu funcio-
namento e então vamos avaliar como a falta de feedback torna difícil o 
trabalho das pessoas que interagem com sistemas como este.
Desde 2009, o governo brasileiro passou a exigir que as empresas deixem de usar 
papel na impressão de seus documentos fiscais e passe a usar o formato eletrônico 
com autenticação do governo para a emissão de suas notas fiscais. Cada estado 
tem um cronograma próprio até que todos os contribuintes estejam fazendo uso 
apenas desta forma de venda (a chamada nota fiscal eletrônica).
O processo por trás de uma venda com nota eletrônica é relativamente 
simples:
1. A empresa gera o cadastro da nota fiscal e, antes de realizar qualquer 
tipo de impressão que a oficialize, envia para aprovação da receita esta-
dual que valida se:
a. A empresa emissora está autorizada a fazer a emissão daquele tipo de 
documento.
b. O cliente que está realizando a compra não tem algum tipo de bloqueio 
que o impeça de fazer compras.
c. Se o conteúdo das informações estão coerentes.
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
64 - 65II
2. Passando pela validação acima, é retornada uma sinalização da Secreta-
ria da Fazenda do Estado para o Emissor e então:
a. A numeração para este documento é gerada (pois foi autorizada pelo 
fisco à venda).
b. Um documento auxiliar que comprova a autorização é impresso.
c. A transação é finalizada.
Parece algo bastante simples, não é? Na verdade é, entretanto, existe um con-
junto de variáveis que podem comprometer todo este trabalho. Vamos pensar 
em um exemplo: seu cliente está na sua frente, você acaba de fazer uma venda 
e então manda a nota para autorização junto a Secretaria da Fazenda Estadual. 
Permita-me trazer algumas variáveis novas para sua análise:
1. O que acontece se o sistema da receita estadual sair do ar?
2. O que acontece se a empresa que está emitindo a nota ficar com a inter-
net fora do ar?
3. O que acontece se o cliente tiver alguma restrição?
4. O que acontece se o emissor estiver com alguma restrição?
5. O que acontece se o ... Chega, vou parar por aqui! Acredito que seja sufi-
ciente para poder ilustrar nosso exemplo.
Na maioria das vezes, se qualquer problema acontecer nos passos acima, a pes-
soa que está emitindo a nota (geralmente o faturista da empresa) fica em uma 
saia justa. Dificilmente ele terá certeza do que aconteceu. Ele precisa muito de 
feedback da aplicação para saber o que está acontecendo e, se precisar tomar 
alguma outra ação para que a venda seja feita, qual será? Precisamos dar o cami-
nho a seguir para o usuário.
Já ouvi relatos que disseram que se a impressão não saísse em um inter-
valo de até um minuto, eles deveriam ligar para o suporte da empresa. Por que 
faziam isto? Era a única informação que tinham em mãos para poder trabalhar!
Perceba como a falta de feedback pode comprometer o trabalho dentro da 
empresa? É imprescindível que seja possível identificar o que aconteceu com cada 
operação que foi realizada dentro de um sistema. Éde fundamental importância 
©shutterstock
Usabilidade
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
64 - 65
que seja dado ao usuário a possibilidade de aprender com o que errou para que 
assim não passe mais por isso, quando este comete um equívoco. É fundamental 
para o sucesso de uma aplicação que seja possível ter as informações necessárias 
onde quer que ela esteja dentro dos sistemas. 
Segundo Norman (1988), vivemos o chamado paradoxo da tecnologia. A 
tecnologia que tem potencial para tornar nossas vidas mais simples e agradáveis 
acaba, por sua vez, tornando mais complexa e cheia de frustração.
USABILIDADE
Prezado(a) aluno(a), independente de você ter ou preferir um celular da Apple 
ou da Samsung, o fato é que tanto o IPhone quanto ao Galaxy são dois ótimos 
exemplos de usabilidade. São fáceis de usar, são intuitivos, como vimos no tópico 
anterior, eles realmente respeitam a forma como as pessoas interagem com os 
objetos.
O principio é que qualquer pessoa que possa tocar algo possa interagir com 
os dois aparelhos acima. Relatos de crianças com pouca idade se divertindo e 
conseguindo jogar em dispositivos como estes são muitos e estão espalhados pela 
internet. Tenho certeza de que você deve ter relatos de amigos ou familiares nesta 
situação.
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
66 - 67II
O que torna dispositivos como este um sucesso pode fazer com que minha apli-
cação também prospere. Para entendermos como isto é possível, vamos avaliar 
o que Nielsen (1993) fala sobre o assunto:
 ■ Sua melhor tentativa não é boa o suficiente.
Se tem uma pessoa capacitada para encontrar falhas em sistema, este é 
o usuário. Invista em teste e qualidade de software o quanto você puder, 
mas saiba, ele ainda vai encontrar falhas que sua equipe não foi capaz 
de encontrar.
Esta mesma verdade cabe para usabilidade. Se você acha que sabe de tudo 
que passa pela cabeça do usuário, você se engana. Se você acha que sabe 
realmente a forma como o usuário vai operar o sistema, está mais enga-
nado ainda. Por mais que você se esforce, por mais que você faça o seu 
melhor, esteja preparado para um redesign. 
Vamos entender nas próximas unidades como podemos reduzir este risco 
e tornar este trabalho mais seguro.
 ■ Usuário está sempre certo.
Se quisermos melhorar como profissionais e como pessoas, temos que 
estar abertos a receber feedback a todo momento, ainda mais com rela-
ção aos nossos designs. O que percebo é que muitas vezes, nosso orgulho 
próprio fala mais alto e dificulta nossa capacidade de análise, muitas 
“reclamações” apresentadas pelo usuário são válidas e devem ser consi-
deradas para a construção de um produto melhor.
Erros recorrentes, reclamação recorrente, são sinais de que posso ter 
falhado no design que foi criado para aquela aplicação, ou aquele grupo 
de usuários. Lembre-se, a “jaca não cai longe do pé”, dê ouvidos e ava-
lie sinceramente.
 ■ Usuário não está sempre certo.
O outro extremo também é perigoso, achar que o usuário sabe o que 
realmente precisa pode ser um tiro no pé. Na maioria das vezes o que o 
usuário solicita é o que ele quer e não o que ele realmente precisa, precisa-
mos agir como agem os médicos, acredito que você não tenha conseguido 
trocar a decisão de um médico que lhe receitou um medicamento cujo 
gosto não lhe agradava, uma vez que este é o que lhe curaria. 
Usabilidade
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
66 - 67
Temos que manter o equilíbrio entre as duas partes, nem tanto ao céu, 
nem tanto ao inferno, precisamos usar o melhor das duas experiências, 
o segredo é trabalhar em equipe (design e usuário).
 ■ Usuários não são designers.
Quando comecei a trabalhar em uma empresa que fornecia sistemas de 
gestão empresarial achei genial a forma como as interfaces do sistema 
eram flexíveis. O usuário poderia manipular literalmente todos os campos, 
poderia customizar como quisesse, aos poucos aquela visão de benefício 
se transformou em problema.
Usuários iniciantes não fazem isto, na verdade eles têm até “medo” de 
que, ao mexer em algo, pare de funcionar, então esta prática que é muito 
bem-vinda para usuários mais avançados, para os iniciantes é ruim.
 ■ Designers não são usuários.
Precisamos ter em nossas mentes que aquilo que eu faço rotineiramente 
me leva a achar que é fácil. Certamente um contador experiente não tem 
dificuldades na geração e análise de um balanço contábil, assim como 
um administrador de empresas na avaliação de um fluxo de caixa, entre-
tanto, aquilo que para mim pode ser trivial (pois já adquiri conhecimento 
e prática suficiente) pode não ser trivial para outra pessoa.
Com o design é a mesma coisa, a pessoa que está criando a interface já 
está influenciada sobre sua própria forma de interagir, operar, fato que a 
leva a ter uma avaliação equivocada da complexidade do que está criando.
 ■ Menos é mais.
Quantas pessoas já andaram pelas ruas em época de campanha eleitoral? 
Infelizmente nossa região não possui nenhuma lei que impeça a utiliza-
ção em massa de cartazes de propaganda e por muitas vezes temos ruas 
completamente lotadas de propaganda, tornando até difícil encontrar 
um estabelecimento comercial.
Quantas pessoas já utilizaram as funcionalidades de criação de “macro” 
em editores de texto? Ou então opções de autorresumo, programação, 
mas estas funcionalidades estão lá, muitas vezes, poluindo da mesma 
forma que os cartazes em época eleitoral.
Por vezes vejo relatórios serem criados para alguns clientes que saem com 
quase todos os campos que existem nas tabelas de banco de dados dis-
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
68 - 69II
poníveis para que o usuário possa fazer a configuração de visibilidade de 
campos, e o que ocorre no final é que o que o usuário precisa é somente 
conseguir filtrar por data e empresa, mas eu o presenteio com outros 120 
campos que nunca serão utilizados por ele (mas estão lá, vai que um dia 
ele precisa! Este meu pensamento está errado, o cliente quer simplicidade).
 ■ Help não ajuda.
É melhor o usuário conseguir usar sem ter que usar um help, e o design 
deve usar isto como um requisito básico.
Na grande maioria das vezes, os usuários não acessam ajuda de sistema 
ou, quando acessam, ficam perdidos pela própria dificuldade de utili-
zação deste. Algumas vezes percebo que alguns designs utilizam como 
“desculpa” para a negligência na criação de uma solução o fato de exis-
tir uma boa documentação (manuais, ajudas...) para o usuário, contudo, 
uma coisa não pode influenciar a outra.
Nielsen (1993) agrupou alguns dos principais elementos de usabilidade em cinco 
grupos, são eles:
1. Facilidade de aprendizagem
Quando comecei a trabalhar como designer gráfico, tinha aproximada-
mente dezoito anos, na época devo ter investido cerca de um mês de estudo 
em uma ferramenta que era a mais utilizada na época para esta função.
Esta ferramenta não é exatamente um bom exemplo de facilidade de 
aprendizado! Se os sistemas levassem este quesito em consideração, mui-
tas escolas que fornecem treinamento em ferramentas, como as voltadas 
para engenharia ou arquitetura, teriam que encontrar outras formas de 
ganhar dinheiro!
Segundo Nielsen, é o atributo mais importante que um sistema deve ter 
Ter menos opções torna minha decisão mais rápida, minha interação mais 
precisa e gera maior satisfação!
Quanto tempo leva para que seus usuários consigam aprender e utilizar seu 
sistema?
Usabilidade
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
68 - 69
em sua classificaçãode usabilidade. Inclusive, pode ser um item que leve 
a pessoa a deixar de usar seu sistema e passando a usar outro!
Como o aprendizado vem com o uso, podemos avaliar como sendo o 
tempo que o usuário leva para atingir um certo nível de proficiência na 
execução de suas tarefas.
2. Eficiência
A eficiência é mensurada com usuários já experientes, aqueles que já 
utilizam a ferramenta há um tempo. Pode ser feita uma comparação, 
considerando a mesma tarefa e o tempo gasto e economizado pelos dois 
sistemas. 
3. Facilidade de relembrar
Esta é uma característica de grande importância para usuários casuais, 
ou seja, aqueles que não fazem uso da ferramenta o tempo todo. Um 
bom exemplo é o sistema de declaração de imposto de renda, você faz 
isto uma vez por ano e é importante que quando necessite fazer uso, não 
perca tempo precisando relembrar como usar o sistema.
4. Erros
Quando falamos de erros não estamos falando de falhas catastróficas que 
façam o usuário perder o trabalho executado, isto é inaceitável e nem 
merece tratamento aqui neste livro.
Quando falamos de erros, estamos nos referindo a engano, ou seja, um 
caminho que o usuário acabou pegando errado e que necessita de orien-
tação para proceder.
Deve ser de fácil contorno promover feedback ao usuário, de forma que 
aprenda e não cometa mais este equívoco. Não pode existir muitas ocor-
rências como esta, caso contrário, isso é um sinal de que sua aplicação 
está com problemas de usabilidade.
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
70 - 71II
5. Satisfação subjetiva
Isto é fazer com que o usuário se sinta satisfeito em usar o sistema, deve 
trazer para o usuário prazer em usá-lo. 
Este é um critério muito valorizado para aplicações como jogos. Ninguém 
tem que jogar, joga porque gosta, porque quer. É esta mesma sensação 
que os sistemas convencionais devem provocar em seus usuários.
Um outro ponto que tem total impacto na usabilidade e, consequentemente, na 
satisfação do usuário, é o quanto este se sente familiarizado ao uso. Um novato 
não será um novato para sempre, precisamos preparar nossos produtos para 
quando este se tornar um especialista. Uma boa abordagem é prover meios dis-
tintos de interação onde, na medida que o usuário se sente mais confortável com 
certos meios de interação, possa evoluir para outros.
USABILIDADE NA WEB
No final de 2011 havia cerca de 555 milhões de sites em todo mundo, em 1982, 
tínhamos 315 sites. Segundo a pesquisa de setembro/2012 Ibope NetRatings, 
somos 83,4 milhões de internautas no Brasil, assumimos a 5ª posição mundial 
em conectividade, cerca de 51 milhões de internautas são ativos, ou seja, aces-
sam frequentemente à rede.
Em 2008, 8,2 bilhões foram gerados em operações de compra on-line, em 
2009, mesmo com a crise, esta cifra saltou para 10,6 bilhões e, em 2010, 1/3 de 
toda venda realizada no varejo do Brasil já era feita pela internet (um montante 
de 14,8 bilhões).
Mesmo com todos estes números favoráveis, apenas 20% dos internautas 
brasileiros realizam compra pela internet, aqueles que não realizam esta opera-
ção não o fazem por não considerar uma operação segura (69%) ou porque não 
confiam na qualidade do produto (26%). 
Estes números dão uma ideia do tamanho do potencial que este mercado 
tem e também trazem uma referência sobre a necessidade de qualidade que estas 
©shutterstock
Usabilidade na Web
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
70 - 71
aplicações precisam ter. Segundo Rocha (2003), dados de 1998 apontam para 
uma perda de três bilhões de dólares por causa de um design mau feito. Como 
abocanhar esta enorme fatia do mercado? Um bom design pode ser uma das 
peças deste enorme quebra-cabeça.
Quando falamos de aplicações tradicionais, como sistemas comerciais, o 
usuário muitas vezes não tem acesso ao sistema, quando muito, acaba por pas-
sar por uma experiência de apresentação do produto em que não é ele quem 
opera o sistema. Assim, ele passa por uma situação em que compra primeiro 
(paga) para depois usar. 
No caso de soluções web, como um e-commerce, a equação é invertida, o 
usuário vai acessar ao sistema, vai tentar tirar as dúvidas que tem quanto ao pro-
duto que anseia comprar e depois, só depois disto, vai optar ou não pela compra. 
Assim, claramente vemos que qualquer problema de usabilidade pode fazer com 
que o usuário simplesmente desista de comprar o produto desejado por meio 
de sua ferramenta e opte por comprar de outro. Em um mercado tão competi-
tivo como é o varejo, o preço das mercadorias são muito semelhantes, então não 
podemos correr o menor risco de perder uma venda por uma falha de design.
Segundo Rocha (2003), uma análise realizada pela IBM revelou que as duas 
opções mais utilizadas de seu site era a busca e a opção de ajuda. Isto foi um indí-
cio de que um problema de design estava ocorrendo e foi iniciado um processo de 
redesign que custou milhões de dólares e envolveu centenas de pessoas. Em feve-
reiro de 1999, entrou no ar a nova versão do site, semanas depois foi constatado 
que houve uma queda de 84% na utilização da ajuda do site, em contrapartida, 
ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
72 - 73II
um aumento de 400% no faturamento.
Se avaliarmos o site da Google, veremos que ele é praticamente o mesmo 
desde o seu lançamento. Seu foco esta na simplicidade, e com isto a capacidade 
de manter um bom relacionamento com seus clientes (usuários que utilizam 
seu serviço de busca).
No design para web existem basicamente duas vertentes, uma de aborda-
gem artística e outra de abordagem na solução de um problema do cliente. Se 
pudermos ter uma mistura destas duas coisas, maravilha, caso contrário, o que 
se espera de um site é que os usuários possam realizar rapidamente tarefas que 
sejam úteis.
Segundo Rocha (2003) e Nielsen (1999), alguns princípios básicos devem 
ser seguidos para garantir um bom design web, são eles:
1. Clareza da arquitetura da informação.
A informação deve estar estruturada e equilibrada, é fundamental que o 
usuário possa discernir o que é prioritário e secundário no site. Esta divi-
são de informações é fundamental para que o usuário possa se encontrar 
e ter suas dúvidas sanadas.
2. Facilidade de navegação.
Um ótimo medidor é que este consiga acessar qualquer informação em 
no máximo 3 cliques, esta métrica é uma ótima referência para que tenha-
mos as informações bem arquitetadas dentro do site.
3. Simplicidade.
Se, ao acessar um site, você conseguir responder perguntas como:
Onde estou? 
O que posso ter de benefício com este site? 
Há algum diferencial nele? 
É o que você precisa para garantir que as informações necessárias para 
que o cliente possa navegar estejam disponíveis.
4. A relevância do conteúdo.
Na WEB o que mais cativa seus clientes é a relevância dos conteúdos, não 
necessariamente por imagens.
Usabilidade na Web
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
72 - 73
5. Manter a consistência.
As coisas têm que acontecer sempre do mesmo jeito! Uma tela de cadas-
tro se comporta igual independente do que está sendo cadastrado, este 
é um forte princípio de usabilidade que retira a ansiedade dos clientes.
6. Tempo suportável.
O tempo de resposta que estudos apontam ser aceitável para que uma 
página web esteja disponível está entre 10 e 15 segundos. Perceba a 
importância desta informação e os detalhes que precisam ser cuidados, 
independente:
 ■ Da velocidade da internet do cliente.
 ■ Do equipamento que este esteja usando.
 ■ Do tipo de acesso, se por dispositivo móvel ou não.
Devemos cuidar para que este tempo mínimo não extrapole e, assim, 
percamos ointeresse do usuário em se manter conectado em nosso site.
7. Foco nos usuários.
Nada impede que um usuário altere o curso de sua navegação e vá para 
outro site, o que vai fazer ele se manter fiel a mim é o respeito a itens 
como estes que acabamos de estudar. 
Não imagine que usar uma tecnologia ou outra vai prender atenção dele 
em seu site, isto para ele é pouco ou nada relevante, o que vale para ele é 
ter acesso rápido e fácil à informação que busca.
Conforme Rocha (2003, p. 39), temos:
Pessoas são extremamente dirigidas a um objetivo quando usam a Web. 
Elas têm alguma coisa específica que querem fazer e não toleram nada 
que dificulte atingir esse objetivo. Portanto, o princípio mestre do de-
sign para a Web é “sair do caminho” de forma a que o usuário possa 
fazer o que quer da maneira mais rápida possível.
74 - 75
NÚMERO DE USUÁRIOS DE INTERNET CRESCE 11% EM JANEIRO DE 2012
Por R7 
O número de usuários ativos da internet brasileira voltou a crescer em janeiro, segundo 
levantamento do Ibope Nielsen Online. Das 63,5 milhões de pessoas com acesso em 
casa ou no local de trabalho, 47,5 milhões foram usuários ativos em janeiro. O cresci-
mento foi de 2% em relação ao mês anterior e de 11,2% sobre os 42,7 milhões de janeiro 
de 2011.
A maior parte desse crescimento vem ocorrendo em residências. Entre janeiro de 2011 
e janeiro de 2012, o número de usuários ativos domiciliares passou de 34,2 milhões para 
39 milhões, ou 14% de expansão.
O total de brasileiros com acesso em qualquer ambiente (domicílios, trabalho, escolas, 
lan houses ou outros locais) foi de 78,5 milhões de pessoas no terceiro trimestre de 2011.
A categoria com maior crescimento mensal do número de usuários únicos em janeiro foi 
a de sites do governo. A audiência dos sites governamentais passou de 22,3 milhões de 
usuários únicos em dezembro para 25,3 milhões em janeiro.
A evolução de 13% foi resultado da maior procura em janeiro por informações sobre o 
Enem, o Prouni e as inscrições unificadas em instituições públicas de ensino superior. 
Nos sites de governo, também cresceu a busca por informações sobre tributos.
Outros sites que também registraram forte crescimento da audiência em janeiro foram 
os de carreiras, os mapas e guias locais, as páginas de ofertas de pacotes de viagens, de 
hotéis e de companhias aéreas e os classificados de imóveis.
Na comparação com janeiro de 2011, acumulam o maior crescimento percentual as ca-
tegorias Automóveis, com 27% de evolução no número de usuários únicos, e Viagens, 
com expansão de 22%. Também seguiram em crescimento sites de vídeos, buscadores, 
e-mail, compras coletivas e sites sociais.
A publicidade na internet também começou 2012 em alta. Em janeiro, foram veiculadas 
mais de 6.000 campanhas de 2.124 diferentes anunciantes. Na comparação com janeiro 
de 2011, o crescimento do número de campanhas foi de 39%. O número de peças pu-
blicitárias em formato display passou de 20 mil e representou um aumento de 69% em 
relação ao mesmo período do ano anterior.
Disponível em: <http://noticias.r7.com/tecnologia-e-ciencia/noticias/numero-de-usu-
arios-de-internet-cresce-11-em-janeiro-de-2012-20120227.html>. Acesso em: 26 jan. 
2016.
Evolução do formato de interação com o Windows, sistema operacional mais 
popular.
<https://www.youtube.com/watch?v=8YHQG01Hfts>. Acesso em 26 jan. 2016
Apesar de ser trecho de um filme, é bastante interessante como os modelos 
de interface podem parecer simples dependendo do nível do usuário.
<http://www.youtube.com/watch?v=pY1_HrhwaXU>. Acesso em 26/01/2016
Considerações Finais
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
74 - 75
CONSIDERAÇÕES FINAIS
Caro(a) aluno(a), vimos no decorrer desta segunda unidade o histórico da evo-
lução das interfaces de computador, também vimos que sua história se mistura 
um pouco com os conceitos de interação homem-computador.
Vimos como nós, humanos, interagimos com objetos e como precisamos 
estar atentos a este item para que nossos produtos forneçam uma boa capaci-
dade de interação.
Foi possível notar também como a internet tem se difundido em nosso país 
e que cada vez mais pessoas estão fazendo uso dela cotidianamente. Vimos que 
hoje a rede mundial já é responsável por uma grande parcela das vendas no 
varejo e que um mau design pode ser crucial para o insucesso de uma empresa.
Na próxima unidade, vamos aprender mais sobre os fatores que envolvem a 
interação humana, quais os elementos envolvidos, qual sua importância, como 
podemos tirar proveito disso de maneira a produzir bons designs.
1. Como a criação de helps pode ser uma armadilha para a concepção 
de um bom design de interação?
2. Dentre os aspectos da interação humana com objetos, quais você 
classifica como mais importantes?
3. Dentre os elementos relacionados à usabilidade para sistemas para 
internet, quais os que você avalia como mais importante?
4. Para o desenvolvimento de soluções desktop, como podemos fazer 
uso dos princípios de usabilidade que aprendemos? Foque nos tópi-
cos relacionados à facilidade de aprendizado e tratamento de erros e 
descreva como você pode colocar isto em prática em suas aplicações.
U
N
ID
A
D
E III
Professor Esp. Ricardo Francisco de Pierre Satin
ENTENDENDO MAIS SOBRE 
OS FATORES HUMANOS 
ENVOLVIDOS
Objetivos de Aprendizagem
 ■ Entender quais são os fatores humanos envolvidos no processo de 
design e interação.
 ■ Avaliar como podemos tirar proveito do entendimento do 
funcionamento da memória humana para o processo de design.
 ■ Compreender como podemos avaliar e otimizar o design 
desenvolvido.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ A psicologia da interface humano-computador
 ■ Mecanismos da percepção humana
 ■ O Modelo GOMS
 ■ Modelos mentais
78 - 79
INTRODUÇÃO 
Caro(a) aluno(a), é de fundamental importância que possamos entender mais 
como se dá o processo de interação homem x máquina, como é que um influencia 
ou recebe influência de outro. Precisamos entender como as capacidades físicas 
e cognitivas humanas interferem no design de um novo produto. Hoje, a psico-
logia cognitiva tem sido uma forte aliada na análise de como comportamentos 
humanos e seus processos mentais influenciam no processo de interação com 
qualquer tipo de produto.
Fatores motores, visuais, perceptivos e cognitivos são de fundamental impor-
tância para um bom projeto de design e interação, para isto vamos avaliar um 
modelo bastante aceito que é o GOMS (Goals, Operations, Methods and Selection 
Rules) este é um modelo que tenta caracterizar os vários processos cognitivos 
subjacentes à realização de uma determinada tarefa. Este é um modelo preditivo, 
que permite análise qualitativa e quantitativa a respeito da performance humana 
em interação com computadores.
Não podemos esquecer que muitos dos fatores humanos envolvidos têm 
caráter ergonômico, precisamos pensar muito bem sobre os seguintes aspectos: 
quem irá usar e em que condições se dará seu uso. Pense que sistemas que são 
desenvolvidos para o uso de pilotos de testes ou aeronautas necessitam avaliar 
claramente estes aspectos, caso contrário, vidas serão colocadas em risco. Talvez 
você não desenvolva sistemas que coloque vidas em jogo, mas tenha certeza de 
que, mesmo assim, critérios como este estão intimamente relacionados com a 
satisfação dos usuários, conforme vimos nas unidades anteriores. 
Talvez o item ergonômico mais importante seja o relacionado à ergonomia 
cognitiva, que nada mais é que a adequação das interfaces aos mecanismos e 
modelos mentais humanos. Quando falamos de modelos mentais, precisamos 
trazer à memória metáforas de interface e como isto pode simplificar o uso por 
parte de nossos usuários.
Introdução 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.78 - 79
©shutterstock
ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
80 - 81III
A PSICOLOGIA DA INTERFACE HUMANO-
COMPUTADOR
Existe uma relação dialética entre os conceitos de interface e a natureza humana, 
podemos dizer que as duas disciplinas mais envolvidas neste processo são a 
Ciência da Computação e a Psicologia. 
Segundo Rocha (2003), a facilidade com que palavras da linguagem da inter-
face podem ser lembradas, como o tipo de fontes e caracteres afetam a legibilidade 
e a velocidade com que lemos informações na tela são exemplos simples de como 
nossa interação com o computador pode ser afetada pelo funcionamento de nos-
sos mecanismos perceptuais motores e de memória.
Da mesma forma que um engenheiro da computação cuida para que o 
processamento dos dados ocorram o mais otimizados possíveis em termos de 
memória, processamento, devemos pensar da mesma forma quando criamos 
uma interface de comunicação entre homem e máquina.
Existe um modelo chamado MPIH (Modelo do Processador de Informação 
Humana), de acordo com Card et al. (1983), que tem por objetivo ajudar a prever 
a interação usuário-computador. Este modelo é estabelecido obedecendo a um 
conjunto de memória e processadores e um conjunto de princípios pelo qual se 
dão as operações. Três subsistemas fazem parte e interagem com o MPIH, são eles:
A Psicologia da Interface Humano-Computador
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
80 - 81
1. SP (sistema perceptual).
2. SM (sistema motor).
3. SC (sistema cognitivo).
A figura ao lado nos ajuda a compre-
ender como este modelo funciona. 
O primeiro passo é identificar o 
que está acontecendo à nossa volta, 
isto se dá pela captura, por meio de 
nossos órgãos de sentido, da infor-
mação sensorial. Tanto na imagem 
acima quanto na maioria dos 
sistemas de informação os 
principais órgãos que são 
acionados são da visão e audi-
ção. Sistemas de segurança 
poderiam trabalhar com outros 
sentidos como o olfato, e sistemas especialistas tratariam com certeza de itens 
relacionados ao tato.
A informação captada pelo processador perceptual (PP) vai para nossa memó-
ria de trabalho (MT), também chamada de memória de curta duração (MCD), 
esta parte da memória aciona parte da memória de longa duração (MLD) com 
intenção de detectar se aquele estímulo já é conhecido. O princípio por trás do 
modelo MHIP é o que chamamos de reconhece-age do processador cognitivo 
(PC), existem autores que afirmam a existência de “gatilhos de memória” que 
são acionados nestes momentos em busca de algo já conhecido anteriormente. 
Estes “gatilhos” acionam nosso processo motor (PM) nos colocando em ação.
O sistema perceptual (SP) também é responsável por acionar dentro do nosso 
mecanismo de memória o que chamamos de memória de imagem visual (MIV) 
e também nossa memória de imagem auditiva (MIA). Após um estímulo e o pro-
cessamento feito pela MCD e/ou MLD, uma representação é fixada/demonstrada 
nestes dois dispositivos de saída (MIV ou MIA).
Fonte: Baseado em Rocha (2003)
ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
82 - 83III
Vamos para um exemplo bastante simples que pode nos ajudar a entender melhor 
esta relação. Certamente, você já deve ter colocado a mão em uma panela que 
está quente e sabe o que isto vai lhe causar, uma vez que é provável que já tenha 
passado por uma experiência como esta ou alguma outra que lhe tenha gerado 
algum trauma.
Recordo-me da ocasião em que fui andar de moto pela primeira vez com 
meu tio, quando ainda era criança. Após darmos um longo passeio, desci pelo 
lado errado da moto, encostei minha perna no escapamento e, por estar quente, 
tive uma grande queimadura em minha perna.
No momento que fui descer da moto, meu sistema perceptor (SP), naquele 
momento, não identificou perigo algum em sua pesquisa à memória de curta 
duração (MCD) nem na memória de longa duração (MLD) e como resposta meu 
processador cognitivo (PC) confirmou a ação que deveria descer, logo meu pro-
cesso motor (PM) assim o fez.
Após esta experiência, sempre que precisei andar de moto novamente, e 
foram poucas, ao chegar perto do momento de subir e/ou descer do veículo, meu 
sistema perceptor (SP) imediatamente, ao acionar minha memória de trabalho 
(MT), tem como resposta colocada na memória de imagem visual (MIV) a cena 
do meu ferimento, fato que faz com que meu sistema cognitivo (SC) acione meu 
sistema motor (SM) com a ação de: não faça nada, só depois é que o SC aciona 
meu sistema motor (SM) de forma que minha ação seja descer.
Perceba quantos elementos estão envolvidos em uma simples ação como esta. 
Ainda com relação ao exemplo acima, é provável que tal ocorrência seja uma das 
responsáveis por não ser muito adepto a andar de moto, agora, traga isto para 
nosso desenvolvimento de sistemas. Este mesmo mecanismo de memória será 
acionado e funcionará desta forma para todos os estímulos que forem dados ao 
usuário. Imagine que o usuário tenha tido algum tipo de experiência ruim com 
algum padrão de interface, mensagens transmitidas pelo sistema, cores, volume 
Quantos mais padronizados forem as imagens ou sons emitidos pelo siste-
ma, mais fácil se tornará o processo de interpretação da memória humana.
A Psicologia da Interface Humano-Computador
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
82 - 83
de informações na tela, tudo isto pode disparar uma ação de aversão do cliente.
Agora que entendemos um pouco a relação quanto ao uso da memória, 
vamos entender um pouco mais de cada um dos três subsistemas que fazem 
parte e interagem com o modelo MPIH.
1. O Sistema Perceptual
É o sistema perceptual que é responsável por capturar as sensações do mundo 
físico detectadas pelos sistemas sensoriais do nosso corpo e transformar em 
representações internas.
Dentre os sistemas sensoriais humanos, vamos falar do visual. Parece que a 
ação de ver é algo simples, mas na verdade ela envolve um conjunto enorme de 
subsistemas (visão central, visão periférica, movimento dos olhos, movimento 
da cabeça) que são de grande complexidade. Nosso raio de visão parece grande, 
mas nem tudo é “realmente visto”, ou melhor, interpretado. De nosso raio de 
visão que é relativamente grande, apenas algo em torno de dois graus é realmente 
“visto” (capturado para análise), a isto chamamos de região fóvea.
Nossos olhos estão em contínuo movimento e a fixação da visão ocorre 
quando algo que nos interessa ou é importante é detectado. Esta movimentação 
é frequente e podemos dizer que na média o tempo gasto para que algo que é de 
interesse tenha nossa atenção tomada e visão fixada é de 230 ms. Após esta fixa-
ção, há o tempo médio de análise que varia de pessoa para pessoa, mas podemos 
dizer que pode variar de 70 a 700 ms. Esta variação tão grande se dá pela com-
plexidade da tarefa que está sendo executada, se estamos lendo um conteúdo 
que é de nosso conhecimento, o tempo gasto para que a informação seja inter-
pretada é relativamente menor se comparado com assuntos ao qual não estamos 
tão familiarizados.
O tempo que uma pessoa leva para ler um texto está intimamente relacio-
nado com o quanto uma pessoa é capaz de captar a cada vez que sua visão é 
fixada sob o texto.
Segundo Rocha (203), considerando o tempo de fixação de 230 ms, se uma 
pessoa a cada vez que fixa a visão sobre um texto consegue captar uma letra, a sua 
média de leitura será de 52 palavras por minuto (considerando uma média de 5 
letras por palavra). Se a cada fixação ela conseguir captar uma palavra, sua média 
©shutterstock
ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS
Reprodução proibida. A
rt. 184 do Código Penal eLei 9.610 de 19 de fevereiro de 1998.
84 - 85III
de leitura será de 261 palavras 
por minuto. Se a cada fi xação 
de visão a pessoa conseguir 
captar uma frase, seu tempo 
de leitura será de 652 palavras 
por minuto (uma média de 
2,5 palavras por frase). Um 
fator que pode impactar este 
tempo de leitura é a complexidade do assunto que está sendo proposto, a difi cul-
dade gerada pelo nosso processo cognitivo pode ser uma limitante para a leitura.
Uma vez que há o reconhecimento, captação da palavra, este é analisado 
pela memória de trabalho (MT), e uma representação visual aparecerá na MIV, 
ou na MIA se for auditivo. Segundo Rocha (2003), este elemento é afetado por 
suas propriedades físicas, como intensidade, cor, forma.
Segundo Preece (2005, p. 102), temos:
Talvez a descoberta mais conhecida em psicologia (certamente a de que 
a maioria dos estudantes lembra, mesmo muitos anos após ter termi-
nado seus estudos) é a teoria de George Miller (1956), segundo a qual 
7 +- 2 porções de informações podem ser armazenadas na memória de 
curta duração (MCD) de uma só vez (parafraseando o autor: ou seja, 
informações que foram percebidas pela primeira vez). ...podemos ter 
vários elementos como números, letras, palavras, comandos. De acordo 
com a teoria de Miller, portanto, a capacidade de memória imediata das 
pessoas é muito limitada. Elas conseguem lembrar apenas de algumas 
palavras, números ou símbolos que ouvira ou viram. Se você não está 
familiarizado com este fenômeno, experimente fazer o seguinte exer-
cício: leia a primeira sequência de números apresentada a seguir (ou 
peça que alguém e leia para você), esconda-a e tente lembrar do maior 
número possível de itens, repita o mesmo procedimento com as outras 
sequências.
3,12,6,20,9,4,0,1,19,8,97,13,84
gato, casa, papel, sorriso, pessoa, vermelho, sim, número, sombra, vas-
soura, chuva, planta, lâmpada, chocolate, rápido, um, moeda, jato
t,k,s,y,r,q,x,p,a,z,l,b,m,e
De quantos você lembrou corretamente em cada lista? Entre 5 e 9, 
como sugere a teoria de Miller?
Quanto menos informações estiverem nas telas do sistema, menor o tempo 
de leitura que será necessário ao usuário, o que torna seu processo mais ágil.
Quanto mais simples forem os termos utilizados, mais fácil será o processo 
de interpretação pelo usuário.
Quanto melhor organizada as informações estiverem na tela, reduzindo a 
necessidade de troca entre os subsistemas da visão (visão central, visão pe-
riférica, movimento dos olhos, movimento da cabeça), mais rápido se dará o 
processo de análise do usuário.
Um bom design precisa avaliar as formas de apresentação das informações. 
Por Exemplo: como seria melhor representado um campo de preenchimen-
to obrigatório em um cadastro?
A Psicologia da Interface Humano-Computador
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
84 - 85
...
Você pode agora estar pensando, “Ok, isto é interessante mas o que tem 
haver com design e interação?”. Bem, esta teoria cinquentenária não 
apenas tem seu lugar na psicologia; ela também causou grande impacto 
em IHC. Infelizmente por razões erradas. Muitos designers ouviram 
falar e leram a respeito desse fenômeno e pensaram “Ah, eis aqui algo 
de psicologia que posso aplicar no design de interface”. Você concorda 
com eles? Se sim, como a capacidade das pessoas de lembrar apenas de 
7+-2 porções de informações pode ter alguma utilidade no design de 
interação?
De acordo com pesquisas realizadas por Bob Bailey (2000), vários 
designers foram levados a acreditar nas seguintes recomendações, 
criando até mesmo interfaces com bases nelas:
Tenha somente sete opções em um menu.
Apresente apenas sete ícones em uma barra de menus.
Nunca faça uma lista com mais do que sete marcadores.
Coloque somente sete botões no topo de uma página web.
Coloque somente sete itens nas opções de um menu.
©shutterstock
ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
86 - 87III
Todas estão erradas. Por quê? A razão é que são todos itens que podem 
ser vistos e revistos e que não precisam ser recuperados pela memória 
de curto prazo. Não aparecem na tela e depois desaparecem exigindo 
que o usuário lembre deles antes de decidir qual selecionar. Se você ti-
vesse de encontrar no conjunto de palavras que apresentamos anterior-
mente, um item alimentício que as pessoas desejam, você encontraria 
sem problema? Não, apenas iria olhar a lista até que reconhece aquele 
chocolate que responde a tarefa e o selecionaria – bem como as pessoas 
fazem quando interagem com menus, listas e tabelas – independente 
destas conterem três ou trinta itens. O que se exige dos usuários aqui 
não é lembrar o máximo possível de itens, apenas os vendo ou ouvindo 
uma única vez em sequência mas olhar para um conjunto deles até que 
se reconheça o que se quer, uma tarefa um tanto diferente. Além disto, 
existem pesquisas em psicologia que podem ser mais bem aplicadas ao 
design de interação.
2. O Sistema Motor
Você pode estar imaginando, qual o motivo de me atentar ao sistema motor do 
ser humano quando se fala de design e interação? Bem, a resposta é bem sim-
ples, veja comigo. Acabamos de avaliar no item anterior como é relevante nossa 
atenção com o que exigimos que nossos usuários leiam nos produtos que dispo-
nibilizamos, agora precisamos avaliar o tempo que será exigido de interação do 
usuário com nosso sistema por meio de digitação, cliques, sempre lembrando 
que há envolvimento direto entre o que está sendo produzido pelo nosso sistema 
motor e o que está sendo interpretado pelo nosso sistema perceptor.
Após o processamento perceptual e cognitivo, finalmente temos o pensa-
mento transformado em ação, logo temos nosso sistema motor em movimento.
Uma das principais formas de interação dos usuários com os sistemas infor-
matizados se dá por meio do teclado. Estudos mostram que um 
novato pode levar até 1000 ms enquanto uma pessoa com maior 
experiência pode levar em torno de 60 ms para interagir via 
teclado. Pensando que um processo de digitação envolve 
duas operações (apertar e soltar; clicar e soltar quando via 
mouse), temos em média o tempo de 140 ms para cada 
toque/clique para um usuário avançado.
Nossos sistemas precisam levar em consideração o 
número de informações que precisam ser inseridas pelo 
Quanto tempo leva um usuário iniciante para realizar uma operação corri-
queira em seu sistema?
Você já avaliou que a possível rejeição dele para usar seu sistema pode ser 
esta demora?
Quantas informações precisam ser preenchidas para que um relatório seja 
gerado? 
Quantos cliques precisam ser dados para que uma informação seja extraída? 
©shutterstock
A Psicologia da Interface Humano-Computador
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
86 - 87
usuário final. Além disto, precisamos avaliar qual o tipo de usuário que estará 
interagindo com o sistema. Como verificamos, quanto mais informações, mais 
tempo necessário para que o processo seja finalizado, quanto mais inexperiente o 
usuário ou quanto maior o número de cliques, maior será a demora, e por aí vai.
3. O Sistema Cognitivo
Podemos dizer que nosso sistema cognitivo envolve o processo de aprendizado, 
recuperação de fatos e resolução de problemas. Quando 
falamos de interfaces de interação com sistemas, o ideal 
é que ele funcione meramente como um conector do 
sistema perceptual e gerador de saídas para o sis-
tema motor.
Nosso sistema cognitivo trabalha fortemente 
com nossa memória de curta duração (MCD) e 
nossa memória de longa duração (MLD).
Aquilo que está sendo necessário para a ope-
ração que está sendo trabalhada é armazenado em 
nossa MCD, já aquilo que virou aprendizado, aquilo 
que necessita de armazenamento, será gravado na MLD.
Podemosdizer também que a MCD é formada por peda-
ços de informações, estes que têm como origem a MLD. Na 
memória de longa duração (MLD), podemos ter informações que, uma vez ati-
vada e presente na MCD, podem se transformar no elo que outras informações 
correlacionadas sejam recuperadas. 
ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
88 - 89III
Certamente você já deve ter se deparado com alguma situação em que precisou 
se lembrar de alguma coisa e não conseguiu, até que alguém disse uma palavra 
que lhe fez recuperar todo o conteúdo. Isso acontece quando estamos tentando 
nos lembrar do nome de um filme, uma música e por aí vai.
A memória de longa duração (MLD) armazena toda gama de conhecimento 
que o usuário foi acumulando em sua vida, toda informação pode ser recuperada 
pela memória de curta duração (MCD) e não há como apagar uma informa-
ção que já esteja registrada na MLD, entretanto, a recuperação pode apresentar 
falhas quando associações não são encontradas ou quando houver interferên-
cia entre conteúdos que estejam armazenados.
Quando falamos de processo cognitivo, estamos falando de algo que também 
pode ser medido, assim como o reconhecimento de um caractere ou o tempo 
de digitação deste. O processo como um todo pode variar entre 25 e 170 ms.
Segundo Rocha (2003), há um exercício interessante para compreendermos a 
ação de nossos mecanismos perceptuais, motores e cognitivos: imagine que você 
está dirigindo em direção à determinada localidade e alguém pede para você 
ir explicando cada ação sua durante essa tarefa. A rota é conhecida e o tráfego 
está calmo. A partir de certo ponto, aparece uma interrupção na rota e você tem 
que desviar do caminho usual, buscando um caminho desconhecido. O tráfego 
agora está confuso e nervoso... como fica a sua tarefa? Enquanto você conhece 
a rota não precisa colocar muito esforço cognitivo no que está fazendo e, então, 
Nossos sistemas precisam apresentar opções que auxiliem, rapidamente, 
nosso cognitivo a recuperar uma informação já armazenada! 
Permitir associar tarefas novas com algo que já seja de conhecimento prévio 
do usuário pode permitir que informações importantes de sua MLD sejam 
recuperadas e auxilie na execução do que está por fazer!
©shutterstock
Mecanismos da Percepção Humana
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
88 - 89
“falar sobre” é fácil. Quando a situação muda, você passa a ter que se concentrar 
mais para descobrir para onde ir – mais processamento cognitivo é necessário 
– e você para de falar. Não é muito diferente a problemática de um usuário que 
está realizando uma tarefa e agora precisa mudar rapidamente, estava fazendo 
uma venda e agora precisa passar para uma devolução da venda, mas é algo que 
não está acostumado a fazer!
MECANISMOS DA PERCEPÇÃO HUMANA
Para que haja uma boa utilização do sistema proposto é necessário que o usuá-
rio interaja com ele e, para isto, é necessário que ele “perceba” todos os detalhes 
que fazem parte deste processo. 
Existem várias teorias que tentam explicar o mecanismo da percepção 
humana, duas delas são a construtivista e a ecologista.
Na teoria construtivista, acredita-se que nossa visão do mundo é formada 
ativamente por informações obtidas no ambiente somadas ao conhecimento pre-
viamente armazenado. 
Nesta teoria, a informação é constru-
ída envolvendo o processo cognitivo. Nela, 
ao recebermos uma informação (estímulo), 
iremos recorrer ao processo da memória des-
crito anteriormente nesta unidade para que 
seja signifi cada.
Na teoria ecologista, a percepção é um 
processo direto que envolve a detecção de 
informações do ambiente e não requer qual-
quer processo de construção ou elaboração. 
Esta teoria trabalha com a ideia de que 
objetos carregam certas características que 
dirigem nossa percepção sobre eles. Quando 
©shutterstock
ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
90 - 91III
falamos sobre Affordance no tópico sobre usabilidade nas unidades anteriores, 
estamos falando da utilização prática de elementos da teoria ecologista!
Apesar de diferentes, podemos explorar ambos no desenvolvimento de nos-
sas soluções! 
Conhecendo os mecanismos humanos de memória, principalmente a capa-
cidade de nossa memória de curta duração, podem-se criar recursos na interface 
que nos poupem de ter que lembrar detalhes necessários à interação, ao mesmo 
tempo em que nos liberem para ocupar a memória com informação relevante.
O MODELO GOMS
Segundo Rocha (2003), temos que o modelo GOMS veio fornecer um modelo 
de engenharia para a performance humana, capaz de produzir predições quan-
titativas a priori ou em um estágio anterior ao desenvolvimento de protótipos e 
teste com usuários. Ele prevê o tempo de execução, tempo de aprendizado, erros 
etc, identificando partes da interface associadas a essas previsões, de forma a 
orientar o redesign.
O significado desta sigla GOMS é (G) Meta, (O) Operadores, (M) Métodos, 
(S) Regras de Seleção. Este modelo trabalha com a seguinte premissa: “os usuá-
rios agem racionalmente para conseguirem alcançar 
suas metas”. Os componentes básicos que compõem 
este modelo são:
 ■ Metas: as metas representam o que o usu-
ário deseja fazer com o sistema. 
As metas também servem 
para estabelecer pontos de 
controle, até onde o usu-
ário chegou com sucesso 
caso tenha que voltar e come-
çar o processo novamente. Para 
O Modelo Goms
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
90 - 91
ficar mais claro, vamos usar como exemplo uma situação de venda. A meta 
será realizar a venda do produto “X” para um novo cliente. 
 ■ Quando falamos de uma situação em que o usuário poderá voltar racio-
nalmente a um ponto no passado e recomeçar, imagine que, por restrições 
financeiras, a venda com cheque não possa ser concretizada para o cliente, 
ele pode voltar até o ponto onde se informa a forma de pagamento do 
cliente e escolher uma nova modalidade de pagamento, sem haver perda.
 ■ Para que esta meta seja possível de ser realizada, o usuário utilizará os 
próximos três elementos abaixo.
 ■ Operadores: são elementos perceptíveis, cognitivos e motores, cuja ação 
é estritamente necessária para que a meta seja alcançada. Seguindo o 
mesmo exemplo acima, estamos falando de selecionar no menu a opção 
de lançamento de uma nova venda, de clicar na opção “novo pedido”, 
selecionar o produto “X” da lista de itens disponíveis, são todas as ações 
que o software permite que o usuário faça.
 ■ Métodos: são todos os procedimentos necessários para conseguir realizar 
a tarefa, são sequências bem aprendidas de submetas e operadores que 
permitem realizar a tarefa.
 ■ Seguindo o exemplo acima, para que a meta vendas seja alcançada, pre-
ciso estar apto a incluir itens no meu pedido de venda (método), estar 
apto a adicionar parcelas na minha venda (método), e perceba que para 
cada método destes serão necessárias várias interações com operadores 
de seleção, botões, e por aí vai.
 ■ Regras de seleção: se refere às estruturas de controle utilizadas no pro-
cesso, em geral são regras do tipo “se-então”. Elas se dão pela experiência 
na tarefa ou por treinamento. No nosso caso acima, o usuário poderia 
fazer todo processo de venda usando apenas teclas de atalho para transi-
tar entre os possíveis conjuntos de informações (cliente, itens do pedido, 
vencimentos...) ou fazer uso de interação com o mouse e teclado.
Quantitativamente podemos chegar a um tempo gasto para que cada operação 
seja realizada, assim como ao tempo necessário para que métodos sejam realiza-
dos. Podemos chegar a uma medida da qualidade em que métodos são realizados, 
exemplo, métodosque exigem muito tempo de interação estão mais propensos 
ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
92 - 93III
a gerar dificuldade de aprendizado nos usuários, logo teriam menor qualidade.
Um bom acompanhamento do usuário permitirá avaliar suas reações, seus 
sentimentos expressos nesta fase e, assim, poderia tomar ações mais seguras. 
Existem opções em que o mapeamento das reações/emoções dos usuários 
ao uso da ferramenta pode ser capturado por meio do que é chamado de uso 
de aplicações com apoio de “trekking glasses”. O usuário utiliza uma espécie de 
óculos, este está conectado a um programa de computador que tem o objetivo 
de mapear alterações na pupila do usuário. Geralmente quando nos deparamos 
com algo que nos chateia ou algo que gostamos muito, nossa pupila se dilata 
e, desta forma, podemos medir a relação emocional da pessoa com o produto. 
Outra técnica que pode ser utilizada em conjunto é o mapeamento da dilata-
ção dos poros, quando recebemos algum tipo de estímulo (positivo ou negativo) 
isto pode ser mapeado por esta análise. Para isso, existem aparelhos que podem 
mensurar este tipo de ocorrência, que funcionam semelhante a pequenas luvas 
que serão utilizadas por nossos usuários enquanto estiverem manipulando nos-
sos produtos. 
Perceba que recursos tecnológicos como os apresentados, associados com os 
demais elementos propostos pelo modelo GOMS, podem nos dar maior segu-
rança em nosso processo de análise.
O modelo GOMS está relacionado à abordagem geral de análise das tarefas, 
desta forma, enfatiza os procedimentos que o usuário deve aprender para reali-
zar com eficiência o sistema.
Quando descrevemos estes procedimentos podemos quantificar as eta-
pas assim como seu aprendizado, isto também permite antever possíveis falhas 
de design e também permite uma avaliação da qualidade do produto que está 
sendo desenvolvido.
Outras duas ferramentas bastante simples que podem ser utilizadas no mape-
amento das reações geradas aos nossos usuários no momento da interação são:
1. Mapeamento de palavras: nesta técnica, é apresentado um grupo de pala-
vras que descrevem os mais variados sentimentos e pede-se que o usuário 
relacione quais estavam inseridas na operação que estava fazendo.
2. Mapeamento de sentimentos: de você já deve ter visto imagens contendo 
©shutterstock
Modelos Mentais
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
92 - 93
um rosto sorrindo e a intensidade do sorriso vai diminuindo até que o 
último rosto se parece com o de alguém que está triste. Bem, esta fer-
ramenta de associação é bastante simples e pode ser utilizada para que 
o usuário ligue o sentimento gerado com a operação que foi realizada.
MODELOS MENTAIS
Os modelos mentais são explicados pela Psicologia Cognitiva com respeito a sua 
estrutura e função no raciocínio humano e no entendimento da linguagem. São 
representações analógicas ou combinações de analogias e proposicionais, estão 
muito relacionados a imagens, mas não se limitam a isto.
Segundo Rocha (2003), modelos mentais são acionados quando nos é reque-
rida necessidade de criar inferências ou previsões a respeito de um determinado 
assunto. Acho pouco provável que você “saiba de cabeça” (ou seja, tenha conhe-
cimento específico sobre o assunto armazenado) sobre a quantidade de janelas 
que tem em sua casa. Este é um ótimo exemplo onde podemos fazer uso de um 
modelo mental para recuperação de uma informação. É provável que você se 
imagine caminhando pela casa verificando os cômodos existentes e assim con-
tando as janelas.
Precisamos ter em nossas mentes 
que o entendimento das pessoas sobre 
os elementos que irão demandar inte-
ração é fraco, impreciso e incompleto 
(cheios de buracos), e a habilidade de exe-
cutar modelos mentais é limitada pelo seu sistema 
perceptivo e cognitivo.
Para que as metas (conforme modelo GOMS) 
sejam atingidas, você irá precisar de um conjunto 
de métodos e operações, talvez pela sua falta de habi-
lidade, irá lançar mão de modelos mentais que lhe 
ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
94 - 95III
auxiliarão no processo de obtenção da informação.
Imagine um programador que, baseado em uma lista de elementos infor-
mados, se depara com a necessidade de contar quantos destes elementos têm 
uma característica “x”. Imagine que este programador não conheça bem a lin-
guagem, na verdade seja um novato. Ele não sabe da existência dos comandos 
de interação ainda, ou melhor, ainda não está 100% familiarizado com ela, mas 
sabe que, por meio de um modelo mental, ele pode encontrar a resposta para 
solucionar este problema.
Em um ambiente real, se esta lista de elementos fosse pessoas e se a caracte-
rística desejada fosse aquelas que usam camisa vermelha, acredito que um bom 
modelo partiria da lógica de organizar todas estas pessoas em uma fila e então 
percorrer esta contando o número de ocorrências encontradas.
Agora que meu modelo está pronto, basta buscar na linguagem de progra-
mação qual o recurso disponível que me permite realizar tal operação.
Modelos mentais ajudam nossos usuários de sistema a pensar em operações 
que necessitam fazer. Pode ser que um usuário nunca tenha feito um processo 
de vendas, pode ser que este seja apenas um operador financeiro desta, mas se 
este racionalizar poderá imaginar quais serão os passos necessários que devem 
ser realizados para que a venda seja realizada para um cliente.
Estas situações nos mostram que usuários acabam desenvolvendo dois tipos 
de modelos mentais principais, o estrutural e o funcional.
No modelo mental estrutural, é assumido que o usuário tenha conhecimento 
(informação disponível para uso em memória) sobre como um artefato funciona. 
Nossos sistemas precisam seguir modelos/padrões de interação que aju-
dem o usuário a associar tais interações a modelos mentais de como ele 
deve funcionar.
E então, teremos certeza de que ele poderá realmente fazer uso disto fazen-
do uso de seus modelos funcionais!
Modelos mentais apoiam nossa antecipação frente a problemas!
Modelos Mentais
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
94 - 95
Se eu pedir para que você descreva como um televisor, ou máquina de lavar ou 
um carro funciona, é provável que você não tenha todos os detalhes técnicos, mas 
você conseguirá dar várias informações sobre como é o funcionamento de algum 
dos artefatos acima. Este modelo é formado nas pessoas conforme sua vivência.
O modelo mental funcional tem como base que o usuário tem o conheci-
mento de como usar a máquina. Voltando ao exemplo do carro, você desenvolve 
o modelo estrutural sobre o funcionamento do veículo e agora tem a ideia de 
como usar este para se locomover.
Podemos mensurar se nossos sistemas estão propiciando que nossos usuá-
rios façam uso de modelos mentais, uma boa abordagem é acompanhar testes 
destes usuários. Precisamos ter em nossas mentes que, avaliando os princípios 
de modelos mentais, podemos acompanhar um usuário operando um sistema 
em busca de alcançar suas metas, este acompanhamento pode ser feito solici-
tando que este fale em “voz alta” sobre sua interação com o sistema. Esta avaliação 
pode nos dar pistas sobre se o modelo mental da pessoa que está sendo avaliada 
é um modelo válido e se nosso sistema está propiciando que esta consiga reali-
zar suas operações.
Lembre-se, modelos mentais são ótimos para avaliação quando:
1. Usuário é novato no sistema.
2. Usuário não interage com aquele tipo de operação (um comprador tendo 
que realizar processo de vendas).
Qualquer sistema computacional será mais simples se tiver um bom modelo con-
ceitual, é nossa tarefa construirum modelo que seja adequado ao uso do artefato. 
Não podemos esquecer que nós, como designs, temos também um modelo 
mental sobre como as coisas acontecem, e este modelo geralmente está fortemente 
ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
96 - 97III
contaminado por nossa grande habilidade de utilização de sistemas ou capaci-
dade de abstração. 
Nem sempre, na verdade quase nunca, em se tratando de sistemas, resol-
vemos os problemas da mesma forma que o usuário final. O usuário final irá 
interagir com as funcionalidades criadas, com a forma que o sistema responde, 
ajudas de sistema, tudo isto forma o que chamamos de aparência física do sis-
tema pelo qual o usuário interage. 
Esta imagem física deve ser consistente com o que o usuário tem de modelo 
mental para que tal tarefa seja realizada. Este cuidado mostra a importância de 
um trabalho conjunto para que os sistemas sejam mais atrativos e realmente 
usuais aos nossos usuários.
96 - 97
INTRODUÇÃO DE COMO FUNCIONA A MEMÓRIA HUMANA? 
Por Richard C. Mohs, PHD 
Quanto mais se sabe sobre a memória, melhor se compreende como melhorá-la. Neste 
artigo você terá uma visão geral básica de como sua memória funciona e de que manei-
ra os efeitos do envelhecimento afetam sua capacidade de lembrar. 
O primeiro choro de seu filho, o gosto dos biscoitos de polvilho da sua avó, o cheiro da 
brisa do oceano. São esse tipos de memórias que formam a experiência contínua de sua 
vida - elas oferecem uma percepção de personalidade. São elas que fazem você se sentir 
confortável com pessoas e lugares familiares, conectam seu passado com seu presente e 
oferecem uma estrutura para o futuro. De certa maneira, é nosso conjunto de memórias 
coletivas - nossa “memória” como um todo - que nos torna quem somos.
A maioria das pessoas fala sobre a memória como se ela fosse parte de seu corpo. Mas a 
memória não existe da mesma forma que o corpo - não é algo que se pode tocar. É um 
conceito que se refere a um processo de lembranças.
No passado, muitos especialistas ficavam satisfeitos em descrever a memória como um 
tipo de pequeno gabinete de arquivo para pastas de memórias individuais em que as in-
formações eram armazenadas. Outros relacionavam a memória a um supercomputador 
neural preso ao couro cabeludo humano. Porém, atualmente, os especialistas acreditam 
que a memória é muito mais complexa e difícil de se compreender - e que ela não está 
localizada em um determinado local do cérebro por ser um processo que ocorre em 
todo o cérebro.
Você se lembra do que comeu no café da manhã de hoje? Se a imagem de um grande 
prato de ovos fritos e bacon surgiu na sua mente, você não a pescou de algum corredor 
neural fora de rumo. Em vez disso, essa memória foi o resultado de um poder cons-
trutivo incrivelmente complexo (um poder que cada um de nós possui) que remontou 
impressões de memória dispersas a partir de um padrão de células distribuídas em todo 
o cérebro parecido com uma rede. Sua memória é realmente formada por um grupo de 
sistemas em que cada um tem um papel diferente na criação, no armazenamento e na 
lembrança dessas memórias. Quando o cérebro processa as informações normalmente, 
todos esses sistemas diferentes trabalham perfeitamente em conjunto para fornecer um 
pensamento coeso. 
O que parece ser uma única memória é, na verdade, uma construção complexa. Se pen-
sar em um objeto - digamos, uma caneta - o cérebro lembra do nome do objeto, seu for-
mato, sua função, o som que faz quando desliza sobre o papel. Cada parte da memória 
do que é uma “caneta” vem de uma região diferente do cérebro. A imagem inteira dessa 
uma caneta é ativamente reconstruída pelo cérebro a partir de muitas áreas diferentes. 
Os neurologistas estão apenas começando a entender como as partes são remontadas 
em uma peça coerente.
98 - 99
Se você estiver andando de bicicleta, a memória de como operar a bicicleta surge a 
partir de um conjunto de células cerebrais. A memória de como ir de um lugar a outro 
vem de outro bloco, a memória de regras de segurança ao se andar de bicicleta vêm de 
outro e aquele sentimento de apreensão que se tem quando um carro faz uma curva 
perigosamente perto de você, vem de um outro bloco. Ainda assim, você nunca está 
consciente dessas experiências mentais separadas, nem que elas estão todas vindo de 
partes diferentes de seu cérebro porque elas trabalham harmoniosamente juntas. Na 
verdade, os especialistas nos dizem que não há uma distinção sólida entre como você 
lembra e como você pensa.
Isso não significa que os cientistas descobriram exatamente como o sistema funciona. 
Eles ainda não compreendem exatamente como você se lembra ou o que ocorre duran-
te a lembrança. A pesquisa sobre como o cérebro organiza as memórias e onde essas 
memórias são adquiridas e armazenadas tem sido, por décadas, uma busca interminável 
entre os pesquisadores. Ainda assim, há informações suficientes para fazer algumas su-
posições. O processo da memória começa com a codificação, em seguida, passa para o 
armazenamento e, eventualmente, pela recuperação.
Disponível em: <http://saude.hsw.uol.com.br/memoria-humana.htm>. Acesso em: 26 
jan. 2016.
O que são modelos mentais: Dicas para delegar e liderar.
<https://www.youtube.com/watch?v=FxdwTO4xD34>. Acesso em: 26 jan. 2016.
CONSIDERAÇÕES FINAIS
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
98 - 99
CONSIDERAÇÕES FINAIS
Prezado(a) aluno(a), nesta unidade entendemos um pouco mais sobre como fun-
ciona o processo da memória humana e como isto afeta o processo de interação 
humano-computador. Entendemos também como funciona o processo senso-
rial humano, como os elementos de visão e movimento são tão importantes e 
podem ser trabalhados para a construção de um bom design.
Também vimos como podemos medir se os nossos esforços para a cons-
trução de um bom modelo de interação está sendo alcançado, vimos como o 
modelo GOMS pode nos apoiar na validação com o usuário e se estamos no 
caminho certo.
Outro ponto abordado foi a importância de como a correlação com bons 
modelos mentais pode apoiar o processo de aprendizado do usuário, auxiliando 
na utilização do sistema e reduzindo sua curva de aprendizado.
Na próxima unidade, vamos entender como podemos estabelecer os requisi-
tos necessários para que tudo o que estudamos até aqui possa ser transformado 
em um sistema realmente atrativo para o usuário.
1. Baseado no que vimos nesta unidade, como os fatores de funciona-
mento da memória devem nos influenciar no desenvolvimento de 
designers?
2. Como podemos avaliar se nosso design permite uma boa interação 
com o usuário?
3. Quais recursos podem ser utilizados para que uma boa correlação a 
modelos mentais do usuário possam ser utilizados?
U
N
ID
A
D
E IV
Professor Esp. Ricardo Francisco de Pierre Satin
IDENTIFICANDO AS NECESSIDADES 
E ESTABELECENDO OS REQUISITOS
Objetivos de Aprendizagem
 ■ Entender a importância dos requisitos no processo de design e 
interação.
 ■ Avaliar como podemos coletá-los de forma mais segura.
 ■ Compreender como podemos usá-los na construção de soluções.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ O quê, quem, quando, onde, como e por quê?
 ■ O que são requisitos? 
 ■ Como coletá-los?
 ■ Como interpretá-los e analisá-los?
102 - 103
INTRODUÇÃO 
Caro(a) aluno(a), talvez a tarefa mais complexa que há no processo de design e 
interação seja o processo de identificação de necessidades dos usuários e então 
o estabelecimento de requisitos. Já vimos nas unidades anteriores que designers 
não são usuários e nem usuários são designers, este antagonismo é importante 
para que possamos entender a necessidade de um trabalho conjunto.
Semelhante a uma consulta médica, se o profissional da área da saúde não 
conseguirextrair as informações necessárias de seu paciente, não conseguirá 
avaliar os sinais passados por este e nem conseguirá fazer o uso correto das fer-
ramentas (exames) que tem ao seu dispor, é provável que o tratamento não seja 
eficiente e o paciente continue com o problema.
Você pode me perguntar, como é possível um médico com tantos recursos 
acima não chegar a um diagnóstico conclusivo? Isto é falta de competência? Não 
diria isto de forma direta, mas suponho estar relacionado à ausência de todas as 
competências necessárias em extrair as informações do paciente e, para isto, teria 
que ser um pouco psicólogo, entender um pouco sobre o funcionamento humano.
Nós da área de tecnologia da informação passamos pelo mesmo problema. 
Quando estamos de frente a um cliente para a construção de um novo pro-
duto, que irá demandar um novo design ou estamos avaliando a necessidade 
de um redesign, somos como médicos na frente de um paciente e precisamos 
extrair o máximo de informações para um diagnóstico correto do que precisa 
ser construído. 
Diferente do que muitos podem imaginar, a identificação das necessidades 
não é só uma questão de experiência, e sim um conjunto de técnicas e ferramen-
tas que podem nos apoiar. É inegável que uma das principais ferramentas para 
este processo é sim a experiência, ter vivenciado situações semelhantes anterior-
mente, isto fará com que se vá à raiz do problema mais rapidamente.
Nesta unidade, vamos entender mais como este processo pode ser realizado, 
como as necessidades podem ser identificadas, mapeadas e tratadas se tornando 
fontes de apoio na construção de sistemas.
Vamos estudar o que fazer com estes requisitos que estarão sendo constru-
ídos e, na próxima unidade, vamos avaliar um pouco como este processo está 
envolvido no ciclo de desenvolvimento de software.
Introdução 
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
102 - 103
©shutterstock
©shutterstock
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
104 - 105IV
O QUÊ, QUEM, QUANDO, ONDE, COMO E 
POR QUÊ?
Ao analisar o título, tenha calma, pois não vamos estudar aqui 
nenhuma ferramenta como a 5W2H ou algo do gênero, 
entretanto, são estas algumas das informações relevantes 
as quais precisamos atentar no levantamento das necessi-
dades para nossos sistemas.
Vamos avaliar cada uma destas alternativas:
1. O que estamos tentando alcançar com esta ativi-
dade de design?
Conforme Preece (2005, p. 222):
São dois os motivos, o primeiro consiste em entender o máximo possí-
vel os usuários, seu trabalho e o contexto desse trabalho, de forma que o 
sistema em desenvolvimento possa fornecer-lhes suporte na realização 
de seus objetivos. Chamamos isso de “identifi cação de necessidades”. 
A partir daí, nosso segundo objetivo consiste em produzir, a partir das 
necessidades identifi cadas, um conjunto de requisitos estáveis que for-
mem uma base sadia para se pensar o design. Isso não é necessariamen-
te um documento nem um conjunto de prescrições rígidas, mas você 
precisa estar certo de que os requisitos não se alterarão radicalmente 
durante o tempo de se realizar o design e de se ter o feedback das ideias.
O que estamos procurando fazer é ter um norte, um horizonte para onde ir e 
assim garantir que o trabalho de design não será perdido.
©shutterstock
©shutterstock
O Quê, Quem, Quando, Onde, Como e Por Quê?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
104 - 105
2. Quem são os elementos envolvidos neste processo?
Caro(a) aluno(a), entenda que quanto mais pessoas estiverem envolvi-
das neste processo melhor. 
É fundamental que o usuário se sinta envolvido, lembre que o que será 
criado por você será utilizado por ele, logo, é imprescindível que ele se 
sinta parte da construção desta nova obra.
Outro ponto importante é, como vimos noutras unidades deste livro, nossa 
visão do mundo não é necessariamente a mesma visão que o usuário tem, 
logo, é fundamental o envolvimento da equipe de design e do usuário 
final para que ambos possam conceber os melhores requisitos de design.
3. Quando esta tarefa se torna necessária?
Vamos falar, na próxima unidade, um pouco mais a respeito do ciclo de 
vida de um sistema, lá ficará mais claro onde esta etapa se encaixa, mas 
precisamos entender que o ideal é que esta etapa anteceda o desenvolvi-
mento de qualquer interface de interação com o sistema, evitando assim 
retrabalho.
©shutterstock
©shutterstock
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
106 - 107IV
4. Onde é o melhor lugar para que esta tarefa aconteça?
Esta é uma tarefa de design que não tem um lugar fixo para ocorrer, 
podemos pensar que o melhor lugar para realizar isto é em nosso estú-
dio de desenvolvimento, outros podem pensar que o melhor é “na casa 
do cliente”, sou adepto de que um misto dos dois deve ser observado. 
Quando estamos no colégio, é menos trabalhoso estar com o professor 
ao nosso lado, desta forma podemos ir tirando dúvidas à medida que 
elas surgem enquanto fazemos nossos trabalhos, não é verdade? Tenho 
por convicção que este é um bom formato de trabalho a ser cadenciado 
junto com o cliente.
5. Como é que podemos levantar estas informações?
Esta é a fórmula de um milhão de dólares! Como mencionei na intro-
dução desta unidade, existem várias técnicas e ferramentas que podem 
ser utilizadas com intuito de trazer maior segurança para que as infor-
mações que sejam realmente relevantes tenham sido mapeadas, mas não 
existe uma fórmula que traga 100% de certeza. 
Fonte: PMSurvey 2012
©
sh
ut
te
rs
to
ck
O Quê, Quem, Quando, Onde, Como e Por Quê?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
106 - 107
Uma das ferramentas mais importantes é a 
experiência. Um design experiente é capaz de 
antever possíveis problemas que um design 
menos experiente e, sendo assim, propor solu-
ções de contorno.
Vamos mais a frente nesta unidade tratar de 
um tópico somente ligado a isto, como pode-
mos levantar nossos requisitos! Então, vamos 
esmiuçar este assunto juntos mais a frente.
6. Por que esta é uma tarefa relevante?
Estudos recentes mostram que cerca de 60% dos problemas que acabam 
levando projetos de novos produtos ao fracasso estão relacionados ao con-
trole de escopo, a figura abaixo foi retirada da pesquisa do PMSurvey de 
2012, uma iniciativa de entidades ligadas a gerenciamento de projetos.
©shutterstock
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
108 - 109IV
Esta pesquisa nos mostra como é importante este quesito para o sucesso 
de nossos sistemas, escopo mal identificado torna o projeto mais caro 
(pois na maioria das vezes exige novas implementações, um redesign) e 
com isso, geralmente, alterações de escopo levam o projeto a apresentar 
um grande atraso, tudo isto impacta na aceitação do usuário final e, por 
conseguinte, no sucesso ou não do produto.
O QUE SÃO REQUISITOS?
Requisito é um mapeamento do que é que se espera que um sistema apresente. É 
como se fosse uma espécie de declaração do que ele deve ter ou de como deveria 
operar. Em um requisito também podemos ter a declaração do que não esperar 
que um produto faça. Por exemplo: quando você compra um aparelho de som, 
você terá em sua declaração de requisito quais os formatos de mídia que ele irá 
reproduzir para você (este é o escopo do que seu produto é capaz de fazer). Em 
outro caso, podemos também ter a declaração de quais as mídias que este seu 
aparelho não estaráapto a reproduzir (isto também é uma definição de requisito).
O objetivo do requisito é que seja completo o suficiente para que o desen-
volvimento possa ser realizado e que possamos validar com nosso cliente se o 
que está sendo entregue é realmente o que foi solicitado.
Em contrapartida, devemos ter em mente que nossa definição de requi-
sito não pode ser tão trabalhosa que leve tanto ou mais tempo 
que o próprio desenvolvimento. É necessário 
haver um equilíbrio, pois evitar ambiguidade 
e itens omissos não quer dizer “escrever um 
livro”.
Já vi os dois extremos acontece-
rem, uma vez, em um projeto que 
acompanhei, os requisitos que foram 
desenvolvidos foram tão detalhados, 
O Que são Requisitos?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
108 - 109
tão detalhados que quase o mesmo tempo de desenvolvimento foi gasto para 
que os requisitos fossem feitos. O resultado disto foi a criação de uma enorme 
documentação, trabalhosa de receber manutenção, que foi deixada de lado mui-
tas vezes no desenvolvimento.
O outro você pode imaginar, várias e várias vezes nos deparamos com requi-
sitos que, quando muito, possuem uma linha. Linha esta que tem que ter a difícil 
tarefa de dar ao desenvolvedor a clareza do que necessita ser feito, a tranquilidade 
de que impactos não serão gerados e quais critérios serão usados pelo cliente 
para dar como entregue tal atividade.
O produto gerado por ambos os casos são sistemas mais caros e qualidade 
duvidosa.
Conforme Preece (2005), o processo de identificação de requisitos não é 
tarefa fácil, imagine a construção de um website, este pode ter como requisito 
que o tempo de download de uma página não pode ser superior a 5 segundos, 
este mesmo website pode ter como requisito que seja atrativo para o público ado-
lescente. Esta informação (ser atrativo para o público adolescente) é algo que o 
levará a pesquisar e identificar quais requisitos precisam ser atendidos para que 
isto aconteça.
Agora um ponto que precisamos avaliar é: quais tipos de requisitos preci-
samos levantar? Você pode se perguntar agora... “mais essa?” Justamente para 
que possamos direcionar nossos levantamentos, a engenharia de software faz 
este tipo de divisão. A engenharia divide tradicionalmente naquilo que chama-
mos de requisitos funcionais e requisitos não funcionais.
 ■ Requisitos funcionais
Os requisitos funcionais servem para descrever quais as funcionalidades 
que um sistema deve ter.
Exemplo 01: vamos avaliar um processador de texto. Para este processador 
de texto podemos dizer que deve apresentar várias opções de estilos de forma-
tação. Podemos quebrar ainda mais esta funcionalidade e mencionar que este 
pode apresentar formatação por parágrafo, por caractere e por documento. Ainda 
podemos quebrar ainda mais e mencionar que este deve ter condições de apresen-
tar 40 opções de fonte, estas podem ter a possibilidade de alteração de tamanho 
©shutterstock
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
110 - 111IV
e cor, apresentar a possibilidade de aplicação de negrito, itálico e sublinhado.
Estas seriam algumas das características básicas funcionais que poderíamos 
listar para um produto como este.
Exemplo 02: vamos avaliar um sistema de compras pela web. Este pode 
apresentar a funcionalidade que permite o usuário pesquisar os produtos dese-
jados; uma vez listados os produtos, é interessante que o usuário possa alterar a 
forma de visualização podendo classificar por preço, relevância etc., até que se 
chegue à possibilidade de selecionar o produto desejado de maneira que possa 
obter maiores detalhes sobre ele.
Uma vez selecionado o produto para compra, este pode ser adicionado a um 
carrinho de compras. Um item relevante é que os requisitos funcionais, como 
vimos nos dois exemplos acima, são os itens que exigem maior interação com o 
usuário, logo estes necessitam de atenção especial do design.
 ■ Requisitos não funcionais
Existe na literatura uma quantidade grande de classificações para requisitos não 
funcionais, abaixo vamos tratar os de maior relevância no processo de design 
e interação.
Para os casos abaixo, vamos adotar como exemplo os listados no tópico ante-
rior (sistema processador de texto e vendas pela web).
 ■ Requisitos técnicos
Avaliando a situação de um sistema processador de texto, um critério impor-
tante é avaliação de qual arquitetura é necessária para seu correto funcionamento. 
Há poucos anos, nossas preocupações voltavam-se para a dúvida de se 
©shutterstock
©shutterstock
O Que são Requisitos?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
110 - 111
o produto rodaria na arquitetura PC, Mac, 
Unix; como a explosão de vendas de dispo-
sitivos móveis e com a enorme aceitação dos 
usuários com o uso de Smartphones e Tablets, 
vemos estes dois itens impactando direta-
mente no nosso processo de desenvolvimento.
Podemos dizer que nossas aplicações 
devem ser móveis, ou seja, rodar indepen-
dente da arquitetura e dispositivo que a 
estejam hospedando.
Um outro critério técnico interessante é 
a quantidade de recursos necessários para que aplicação possa operar. É verdade 
que cada vez mais equipamentos poderosos estão nas casas de nossos usuários 
potenciais, mas também é verdade que não existem recursos ilimitados. Atenção 
quanto à necessidade de processamento, memória, armazenamento, link de comu-
nicação, são muito importantes para o projeto de uma nova aplicação.
Nos dias atuais, um quesito técnico dos mais importantes é exigência de que 
as aplicações sejam móveis e que possam rodar tanto em sistemas operacionais 
da Apple (IOS) quanto no Android. 
 ■ Requisitos de dados
Quando falamos de dados, é relevante pensar na necessidade de disponibilidade 
destes. Muitas empresas investem pesado em sistemas de replicação para garantir 
que todos os dados sejam acompanhados em tempo real em suas matrizes. Um 
ponto importante a ser avaliado é: que tipo de informação é estratégico 
ter em tempo real? Que tipo de informação é aceitável trabalhar 
com um atraso? Qual o tamanho deste atraso de forma que não 
comprometa a operação?
Respostas a perguntas como estas podem 
ajudar a empresa a economizar e simplifi car 
o processo de desenvolvimento de soft ware.
Outro ponto refere-se ao armazenamento 
das informações. Muitas empresas têm um certo 
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
112 - 113IV
“apego” natural aos dados que são gerados e, por elas, nunca eles seriam remo-
vidos. Como disse anteriormente, estamos vivendo em uma época em que os 
avanços tecnológicos têm sido significativos, mas não existem recursos ilimita-
dos. Até que ponto ter toda movimentação da empresa por 20 anos é relevante? 
Até que ponto é relevante criar estruturas de resumo e replicação de dados para 
garantir maior agilidade no acesso e gravação dos dados?
Estas questões são relevantes e podem modificar completamente o escopo 
do desenvolvimento de uma solução. Acompanhei o projeto da criação de um 
produto que teria que funcionar “no meio do nada”. A finalidade do produto não 
vem ao caso, mas se destina a um público que literalmente fica em regiões bas-
tante isoladas. Muitas vezes:
 ■ sem acesso à internet;
 ■ sem servidores de banco de dados;
 ■ sem acesso a rede. 
Como garantir que as informações geradas por esta aplicação sejam consis-
tidas em um único ponto de análise, por exemplo, em uma matriz? 
Como garantir que esta aplicação tenha condições de funcionar em ambientes 
tão inóspitos? Como garantir que esta aplicação não tenha perda de funcionalida-
des caso seja utilizada em um ambiente tradicional (com acessoà rede, internet). 
Pois bem, é um bom exemplo de requisito de dado que necessita ser aten-
dido. Pense que tal requisito não seja identificado inicialmente no seu projeto e 
só venha ser diagnosticado após parte do produto estar pronto? Simplesmente 
você corre o risco de ter perdido tudo que fez!
 ■ Requisitos ambientais ou contexto de uso
Quando falamos de requisitos ambientais ou de contexto de uso, estamos 
falando de requisitos relacionados às condições em que se espera que o produto 
interativo funcione. Podemos pensar em quatro aspectos, são eles:
 ■ Ambiente físico:
Como é o ambiente físico onde este produto estará inserido: é um local 
©shutterstock
O Que são Requisitos?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
112 - 113
sujo, é um local com pouco ou muita iluminação? É um local ventilado? 
É um local barulhento? As pessoas que manipularão o sistema necessitam 
usar algum tipo de vestimenta de proteção, luvas... (pois pode dificultar). 
É um local com muitas pessoas? É um local reservado ou público onde 
o sistema estará em uso.
Veja quantas questões importantes podemos avaliar antes que o design 
seja projetado? Perceba como podemos inviabilizar o desenvolvimento 
de uma aplicação se esta não for projetada avaliando critérios como este.
 ■ Ambiente social:
Um dos principais pontos diz respeito à localização física das pessoas 
envolvidas no uso da ferramenta. Elas estarão fisicamente próximas? 
Existe necessidade de colaboração no trabalho que estão executando? 
Em caso positivo, isto necessita ser síncrono ou assíncrono? Como se 
dará o meio de comunicação entre elas?
 ■ Ambiente organizacional:
Quando colocamos um sistema em uma empresa, precisamos pensar 
como esta empresa está organizada hierárquica e tecnicamente. Qual 
a estrutura técnica existente na empresa (funcionários e equipamento), 
esta empresa tem um histórico de apoio organizacional à implantação 
de projetos e a investimentos em tecnologia?
Critérios como estes são importantes para o bom dimensionamento do 
trabalho a ser feito.
©shutterstock
©shutterstock
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
114 - 115IV
 ■ Ambiente técnico:
Quais tecnologias serão utilizadas? Com que tipo de tecnologia ou apli-
cativo há necessidade de manter compatibilidade? Quais limitações 
tecnológicas estão sendo impostas (necessidade de aproveitar parque de 
máquinas da empresa – sem demanda de investimento).
 ■ Requisitos de usuário
Trata-se da identificação de tipos de usuá-
rios com os quais vamos nos deparar para 
uso de nossa aplicação. Estaremos lidando 
com usuários novatos ou especialistas? Esta-
remos lidando com usuários frequentes ou 
ocasionais? Estas duas simples perguntas 
influenciam, e muito, o formato de direcio-
namento do design de nossas aplicações.
Estes usuários irão evoluir no uso da ferra-
menta? Caso a resposta seja positiva, nossa 
aplicação deve ter a possibilidade de ajustar 
os perfis de interação mediante aprendizado 
do usuário.
 ■ Requisitos de usabilidade
Aqui identificamos as metas de usabilidade e as 
medidas associadas para o uso do produto. Quão 
eficiente, eficaz e segura necessita ser a 
forma de interação com o sistema? É 
de extrema importância avaliar este 
quesito em separado para prover 
uma maior aderência frente à 
necessidade do público para 
o qual será disponibilizado o 
produto.
©shutterstock
Não é uma única técnica que você usará em seu processo de coleta, e sim 
um conjunto delas, esteja atento àquelas que melhor se encaixam em sua 
necessidade.
Como Coletá-Los?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
114 - 115
COMO COLETÁ-LOS?
Agora que ficou mais claro o que é um requisito, qual sua importância e os 
diferentes tipos de requisitos que devem estar em nossa mente quando formos 
trabalhar neste assunto? É chegado o momento de colocar a mão na massa e 
começar o processo de coleta de requisitos.
O propósito da fase de coleta de requisitos é estabelecer e reunir informa-
ções suficientes para o bom trabalho do projeto. Entenda que existem situações 
onde você já terá em mãos um conjunto de requisitos de forma macro que 
o cliente já tenha lhe disponibilizado, entretanto, isto não tira de você a 
responsabilidade de realizar esta fase do pro-
jeto mediante a coleta mais detalhada para 
garantir um bom entendimento.
Existe um vasto conjunto de técnicas 
e ferramentas que nos apoiam no processo 
de coleta de requisitos. O que vamos come-
çar a estudar são algumas destas técnicas 
que julgo que podem nos apoiar com mais 
segurança.
 ■ Log de dados
Quando a tarefa é substituir um sistema já em uso, esta é uma ferramenta bas-
tante interessante. Um sistema legado geralmente traz consigo um conjunto 
muito grande de funcionalidades, relatórios e aspectos de usabilidade que pre-
cisam ser considerados.
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
116 - 117IV
Apesar de não ser uma tarefa simples, é uma ferramenta poderosa que consiste 
na habilitação de logs de operação dentro do sistema. A ideia é registrar o que 
está realmente sendo utilizado, com que frequência e qual a performance de uso.
Podemos estabelecer estes logs por meio de programação direta no código-
fonte do sistema antigo ou por meio de ferramentas de monitoramento do 
usuário. Quando esta última é a opção a ser utilizada, uma boa escolha é atre-
lar seu uso a usuários chaves (conforme os perfis identificados) e assim extrair o 
máximo de informação quanto ao uso e formato de interação de cada indivíduo.
 ■ Engenharia reversa
Também é uma ferramenta poderosa que permite avaliar com maiores detalhes 
o que está implementado. Número de relacionamentos, dependências e funcio-
nalidades críticas. Com uma ferramenta como esta, é possível avaliar o número 
de exportações fiscais que uma aplicação possui e, assim, minimizar o impacto 
de que alguma destas rotinas não estejam no escopo mapeado para o desenvol-
vimento e para este cliente.
É uma ferramenta de avaliação bastante técnica, envolve contribuição direta 
da equipe de T.I. do cliente.
 ■ Questionários
Quantas vezes você respondeu algum tipo de questionário? Pois bem, esta fer-
ramenta, apesar de parecer ultrapassada, é muito poderosa e extremamente 
atual. Hoje em dia, com a possibilidade de aplicação de formulários de pesquisa 
on-line, a facilidade de consolidar as informações para análise é ainda maior.
O segredo desta ferramenta é identificar o que você realmente precisa saber.
Algumas informações relevantes que podem ser questionadas são: 
 ■ Quais os recursos mais utilizados no sistema? Qual a frequência de uso?
 ■ Quais informações que julga relevantes não estão presentes nestes recursos? 
Quais estão e não julga relevante?
 ■ Qual o tempo de interação necessário para que estas informações sejam 
levantadas?
 ■ Uma listagem completa de todas as atividades realizadas rotineiramente 
Como Coletá-Los?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
116 - 117
(ter a frequência e tempo exigido).
 ■ Com quais sistemas a pessoa necessita de interação para realizar as tare-
fas? Que funcionalidades são utilizadas?
 ■ Quais as rotinas mais críticas que você executa? Qual atraso tolerado?
Perceba que a lista de informações acima é simples e tem apenas objetivo didá-
tico. Para seu projeto, você precisa avaliar quais informações relevantes precisa 
levantar e então aplicar aos seus usuários.
Esta é uma ferramenta que pode ser muito bem utilizada com outra técnica, a 
de entrevista. Perceba que informaçõesque julgar relevante ou polêmica, podem 
fazer parte de um formulário de pesquisa a ser enviado para um grupo de pessoas.
 ■ Entrevista
Esta técnica é muito importante e apresenta bons resultados quando é utilizada 
no início dos levantamentos de requisito (quando você ainda não tem nada 
identificado com certeza) ou quando você já tem vários itens mapeados e deseja 
checar as informações.
A técnica de entrevista apresenta bons rendimentos quando cadenciada 
mediante um questionário de perguntas, que tem por objetivo facilitar a extra-
ção das informações pertinentes.
Esta técnica deve ser aplicada com bastante cuidado, pois pode trazer a ideia 
de que consome muito tempo e não é interessante, entretanto, desde que com o 
recurso de um questionário descrito acima e com um forte controle de tempo, 
pode ser bastante otimizada.
Um fato inegável é que todo ser humano gosta de se sentir valorizado e 
quanto mais pessoas você puder ouvir em seu processo de coleta de requisitos 
melhor, pois este sentimento de valorização será transmitido a elas, com toda 
certeza, e com isto você ganhará uma cooperação mais fácil.
 ■ Grupo de estudos específicos/oficinas
Muito utilizada quando um requisito é polêmico ou complexo, esta é uma ótima 
ferramenta que também deve ser muito bem cadenciada com relação ao tempo.
Uma boa estratégia é trabalhar em formato de brainstorm, listar as ideias 
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
118 - 119IV
para elucidação dos requisitos e, após isto, um plano de ação pode ser elaborado 
para que os pontos conflituosos sejam esclarecidos.
Um ponto importante é a utilização de oficinas direcionadas ao entendimento 
do requisito. Uma vez acompanhei um caso como este que apresentou bastante 
sucesso. Havia uma certa dificuldade em conseguir encerrar a coleta dos requi-
sitos de um módulo de produção em uma empresa e a técnica adotada foi esta. 
O Analista conduziu de forma que um ambiente semelhante ao caso real fosse 
simulado e, analisando passo a passo (como se o processo de produção esti-
vesse realmente acontecendo), foi possível então a compreensão da necessidade.
 ■ Observação natural
Se trata de um processo relativamente simples, mas muito produtivo, ainda mais 
se já houver algum entendimento do escopo que necessita ser criado por parte 
da equipe de desenvolvimento. Trata-se literalmente de acompanhar e visuali-
zar na prática como é realizado o trabalho com o sistema que será substituído.
Esta é uma experiência muito rica a qual recomendo a todos que incluam 
em seus processos de coleta. Esta é uma ótima experiência que nos auxilia no 
processo de identificação das necessidades de design para o novo sistema.
 ■ Estudo de documentação
Existem duas ótimas alternativas que muitas vezes são negligenciadas no processo 
de coleta de requisitos. Uma delas é a solicitação de um processo de catalogação 
de documentos por parte do usuário. 
Neste processo, ele cataloga para a equipe de projetos todos os documentos 
e interfaces por meio do qual interage com o sistema. É um processo que pode 
parecer moroso, mas na verdade não é, e os benefícios para um bom mapea-
mento do escopo são enormes.
Junto com esta catalogação (que necessita ser estudada pela equipe do projeto), 
há uma segunda alternativa que é o estudo de manuais, documentos operacio-
nais e documentos metodológicos utilizados pela empresa atualmente. 
Documentos de normas e procedimentos internos das empresas geralmente 
são ricas fontes de consulta que precisam ser levadas em consideração no processo 
de coleta de requisitos. Muito do que se espera que os sistemas façam estão lá, e 
Como Coletá-Los?
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
118 - 119
critérios preciosos de performance e usabilidade também podem ser mapeados lá.
Estas técnicas apoiam e muito o processo de coleta de requisitos, o trabalho 
conjunto delas é ainda mais poderoso e como podemos ver em Preece (2005, 
p.231):
Rudman e Engelbeck (1996) descrevem como utilizaram técnicas di-
ferentes a fim de estabelecer os requisitos para uma interface gráfica 
complexa em uma empresa de telefonia e como diferentes métodos 
proporcionaram o entendimento de requisitos diferentes. Cinco técni-
cas distintas foram utilizadas.
1. A observação no local permitiu-lhes entender a natureza dos negó-
cios atuais.
2. A prototipação participativa, isto é, o envolvimento ativo dos stake-
holders no design de um protótipo permitiu-lhes tirar vantagem do 
conhecimento dos empregados.
3. Entrevistas que visavam o entendimento dos negócios anteriores da 
empresa permitiram-lhes entender a natureza complexa do domínio 
mais amplo.
4. Entrevistas que visavam a entender as sequências de decisões dos 
empregados possibilitaram-lhes criar diálogos para oferecer suporte à 
negociação entre as partes.
5. Ensaios com protótipos utilizando cenários simulados também aju-
daram a criar diálogos para oferecer suporte à negociação entre as duas 
partes.
A diferença entre as terceira e quarta técnicas se dá no foco do ques-
tionamento e na notação utilizada para captar dados. Na terceira téc-
nica, os entrevistadores procuraram entender o domínio da aplicação e 
capturaram informações utilizando redes semânticas, especificamente 
projetadas para representar tal informação. Na quarta técnica, as árvo-
res de decisão foram utilizadas para se entenderem as metas, os pontos 
de decisão e as opções que são levantadas em conta pelos empregados 
quando lidam com um cliente.
Conforme podemos ver acima, a utilização das técnicas tende a trazer melhor 
resultado, entretanto, isto não significa que é uma regra nem quem tenha que 
aplicar todas em meu processo de coleta para garantir que tudo ocorra bem. Para 
apoiar no processo de seleção da melhor técnica, na sequência tem-se o compa-
rativo adaptado de Preece (2005).
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
120 - 121IV
TÉCNICA BOA PARA TIPO DE 
DADOS
VANTAGENS DESVANTAGENS
Questionários Responder 
a questões 
específi-
cas.
Dados 
quanti-
tativos e 
qualita-
tivos.
Pode atingir 
várias pessoas 
com poucos 
recursos.
O design é crucial. O 
Índice de resposta 
pode ser baixo, as res-
postas podem não ser 
o que você deseja.
Entrevista Explorar 
questões.
Alguns 
dados 
quanti-
tativos, 
mas 
mais 
qualita-
tivos.
O entrevista-
dor pode guiar 
o entrevistado 
se necessário. 
Encoraja o 
contato entre 
desenvolvedo-
res e usuários.
Requer tempo. 
Ambientes artificiais 
podem intimidar o 
entrevistado.
Grupo de es-
tudos específi-
cos/oficinas
Coletar 
vários 
pontos de 
vista.
Alguns 
dados 
quanti-
tativos, 
mas 
mais 
qualita-
tivos.
Ressalta áreas 
de consenso e 
conflito. Enco-
raja o contato 
entre desen-
volvedores e 
usuários.
Possibilidade de domi-
narem certos tipos de 
personalidade.
Observação 
natural
Entender 
o contexto 
da ativi-
dade do 
usuário.
Qualita-
tivo.
Observar o 
trabalho real 
oferece per-
cepções que 
outras técnicas 
não podem 
oferecer.
Requer muito tempo. 
Grandes quantidades 
de dados.
Estudo de do-
cumentação
Aprender 
sobre 
procedi-
mentos, 
regula-
mentações 
e padrões.
Qualita-
tivo.
Não compro-
mete o tempo 
dos usuários, 
exceto quando 
utilizado recur-
so de catalo-
gação.
O trabalho diário será 
diferente dos proce-
dimentos documen-
tados.
Como Interpretá-Los e Analisá-Los
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
120 - 121
TÉCNICA BOA PARA TIPO DE 
DADOS
VANTAGENS DESVANTAGENS
Log de dados Enten-
der os 
recursos 
realmente 
usados 
pelos usu-
ários.
Quanti-
tativo.
Não gera 
impacto ao 
usuário final. 
Identificaçãodos reais pon-
tos de atenção 
na implemen-
tação.
Requer desenvolvi-
mento.
Engenharia 
reversa
Identificar 
os recur-
sos imple-
mentados 
que não 
surgiram 
em outras 
formas de 
cataloga-
ção.
Quanti-
tativo.
Conhecimento 
aprofundado 
da estrutura 
do sistema 
atual.
Requer grande envol-
vimento técnico.
Fonte: Adaptado de Preece (2005)
Em resumo, conheça o trabalho que você tem a fazer e escolha as melhores armas 
que você pode carregar para poder vencer este combate que é a coleta de requi-
sitos com qualidade!
COMO INTERPRETÁ-LOS E ANALISÁ-LOS
Quanto antes o processo de análise for iniciado melhor, as informações refe-
rentes à catalogação estará mais presente na memória, facilitando o processo 
de interpretação.
A primeira avaliação a ser feita é com os próprios envolvidos no processo 
de catalogação, avaliando os resultados obtidos com a aplicação das ferramen-
tas e identificar as expectativas para o processo de análise.
O próximo passo é iniciar um processo de catalogação de todos os artefatos 
©shutterstock
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
122 - 123IV
relevantes transformando-os em requisitos de sistema (requisitos funcionais e 
não funcionais), em que uma análise de dados mais abrangente irá trazer mais 
detalhes à interpretação inicial dos requisitos. Técnicas diferentes e notações 
existem para a investigação de aspectos diferentes do sistema, os quais, por sua 
vez, farão surgir requisitos distintos. Por exemplo, requisitos funcionais tradi-
cionalmente são analisados e documentados utilizando-se diagrama de fluxo de 
dados, diagramas de estado, diagramas de workflow. Requisitos de dados podem 
ser expressos utilizando-se diagramas de entidade-relacionamento. Se o desen-
volvimento deve apresentar uma abordagem orientada a objetos, então requisitos 
de dados e funcionais são combinados em diagrama de classes, com comporta-
mentos expressos em diagramas de estado e diagramas de sequência entre outros. 
Como você pode ver, existem vários diagramas que podem ser utilizados 
para nos levar a representação do que foi levantado, entretanto não é objetivo 
deste livro descrever o funcionamento deles. O que vamos ver na sequência são 
quatro técnicas que apresentam um foco centrado no usuário e que são utiliza-
das para entender os objetivos e as tarefas de cada usuário. Seu resultado serve 
de apoio para fases seguintes do desenvolvimento, são as seguintes técnicas: 
Cenários, Casos de uso, Casos de uso essenciais e Análise de tarefas.
Para que as tarefas dos usuá-
rios possam ser documentadas de 
forma que seja facilitada a inter-
pretação e análise do que necessita 
ser feito, uma ótima alternativa é a 
construção de cenários.
A construção de cenários 
se dá, inicialmente, por meio da 
apresentação textual que é com-
pilada baseada nos itens coletados 
do cliente, de como os processos 
funcionam. Para facilitar nossa 
compreensão, imagine que estamos 
desenvolvendo um processo de 
e-commerce e, para isto, coletamos 
O foco da construção de cenários está nas tarefas do usuário!
Como Interpretá-Los e Analisá-Los
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
122 - 123
todos os requisitos necessários pelo cliente. Existem vários cenários que podem 
ser gerados como parte da construção desta solução, podemos construir cená-
rios referentes a:
1. Processo de venda com sucesso.
2. Processo de venda com falha.
3. Processo de venda com pagamento com cartão de crédito.
4. Processo de pesquisa de produtos.
Entenda que a ideia por trás da construção de cenários é levantar os macros pro-
cessos que farão nosso sistema operar de forma que possam ser desenvolvidos, 
testados e validados pelo cliente em sua etapa de entrega. 
A construção de cenário pode ser representada graficamente e uma ótima 
ferramenta para isto são os diagramas de sequência.
Outra alternativa é o diagrama de caso de uso, que tem como ênfase a inte-
ração entre usuário e sistema. Casos de uso foram originalmente introduzidos 
na comunidade orientada a objetos, embora seu foco seja especificamente a inte-
ração entre o usuário e o sistema, o peso ainda está bastante concentrado na 
perspectiva do usuário e não no sistema. 
O termo cenário também é utilizado na construção de casos de uso, represen-
tando um caminho a ser seguido no caso de uso, isto é, um conjunto particular 
de condições. 
Um caso de uso é associado a um ator, e é o objetivo deste ator, ao utilizar o 
sistema, que o caso de uso deve retratar. Na retratação deste tipo de técnica, exis-
tem dois principais cursos demonstrados, um é o curso normal (aquele definido 
como sendo o caso corriqueiro que o usuário optaria ao utilizar o sistema), e os 
cursos alternativos, outras formas de interação com o sistema.
No caso de uso, as interações do ator com o sistema são retratadas como 
ações a serem realizadas. No caso de um sistema web, a representação do caso de 
uso teria que o ator (no caso um cliente) pode: consultar um produto, consultar 
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
124 - 125IV
status de sua compra, realizar uma compra.
Esta é uma ótima técnica, mas apresenta suas limitações e é para tratar estas 
limitações, assim como as limitações da construção de cenários, que a técnica 
de casos de uso essenciais foi criada.
Conforme Preece (2005, p. 249), temos:
Os cenários constituem histórias concretas que se concentram em ati-
vidades reais e específicas. Podem, portanto, obscurecer questões mais 
amplas voltadas a uma visão organizacional mais abrangente. Por outro 
lado, os casos de uso tradicionais contêm certas hipóteses, inclusive o 
fato de que há uma tecnologia com a qual se interage, e também su-
posições sobre a interface com o usuário e o tipo de interação a ser 
projetada.
Os casos de uso essenciais representam abstrações de cenários, isto é, 
representam um caso mais geral do que o cenário abrange e tentam 
evitar as suposições de um caso de uso tradicional. Um caso de uso 
essencial é uma narrativa estruturada em três partes: um nome que ex-
pressa intenção geral do usuário, uma descrição em passos das ações dos 
usuários e das responsabilidades do sistema. Essa divisão entre respon-
sabilidades do sistema e do usuário pode ser muito útil durante o de-
sign conceitual, quando se considera a alocação de tarefas e o escopo do 
sistema, é isto, o que está sob responsabilidade do usuário e do sistema.
Esta opção, como dita pelo autor, é interessante sob o aspecto de que deixa bas-
tante claro o que se espera que o sistema faça e o que se espera que o usuário faça.
124 - 125
10 DICAS PARA COLETAR REQUISITOS
Por Diego Nei, MBA, PMP 
Os requisitos do projeto são uma parte de fundamental importância para a definição 
não só do escopo, mas também dos objetivos do projeto. Quando os requisitos não são 
claros, a chance do projeto não ter sucesso ou ter apenas sucesso parcial (por que dei-
xou de atender a necessidade do cliente, por exemplo) é muito maior.
Os requisitos são determinados pelas partes interessadas do projeto, todas elas ou as 
mais importantes e ativas.
1. Use questionários para coletar os requisitos. Gere perguntas sobre os aspectos do 
projeto, de forma a conseguir das partes interessadas a maior quantidade de informa-
ções possíveis. As perguntas devem começar com aspectos gerais e abordar mais e mais 
detalhes ao decorrer do questionário. Esta forma de coleta é muito boa para partes in-
teressadas que não têm muita disponibilidade para reuniões ou estão em ambientes 
virtuais.
2. Colete requisitos para o escopo do projeto. O escopo do projeto é o que o projeto 
precisa/almeja realizar. Alguns exemplos: Projeto A – Otimização do setor financeiro, 
Projeto B – Curso deElaboração de Projetos. Seu patrocinador e partes interessadas in-
ternas são os alvos nesta etapa.
3. Colete requisitos para o escopo do produto. O escopo do produto é o que o projeto 
vai entregar ao cliente ao final da sua duração. Exemplos: Projeto A – Processos Finan-
ceiros otimizados, Projeto B – Planos de Curso, Apostila de Elaboração de Projetos. Seu 
cliente e o usuário final são os alvos desta vez.
4. Elabore uma matriz de rastreabilidade de requisitos. Nesta tabela você deve asso-
ciar os requisitos às partes interessadas, recursos, atividades, entregas, pacotes de tra-
balho e quaisquer outras informações que você achar pertinentes, de forma a facilitar o 
acompanhamento e assegurar que os requisitos estão sendo observados, respeitados e 
cumpridos;
5. Leve em consideração que os requisitos mais importantes podem não vir dos 
stakeholders mais importantes. Em um exemplo bruto, o faxineiro do prédio pode sa-
ber de uma coisa que nenhum dos membros da diretoria sabe. Procure sempre ao me-
nos perguntar aos stakeholders de menor impacto ou não diretamente envolvidos sua 
percepção do projeto (mesmo que de uma forma que não revele que se trata de fato de 
uma coleta de requisitos).
6. Round 1… Fight! Se em algum momento, dois ou mais stakeholders decidirem que 
é um bom momento para brigar sobre requisitos e isso atrapalhar as reuniões, não te-
nha medo de encerrar a reunião e utilizar a técnica Delphi para chegar a uma decisão 
126 - 127
comum sem sacrificar as reuniões de planejamento.
7. Jogos de Poder. Existem situações onde a parte interessada A passa requisitos, mas 
é a parte interessada B quem tem poder de decisão para aprovar se o requisito entra ou 
não no projeto. Defina bem cedo uma matriz de priorização de partes interessadas, de 
forma a identificar quem tem prioridade sobre quem, bem como elabore o mais cedo 
possível um plano de gerenciamento de requisitos onde deve constar o processo a ser 
adotado quando um requisito crítico é identificado por uma parte interessada de menor 
importância. Se valer de opiniões especializadas nessa hora é sempre uma boa idéia.
8. Escreveu não leu… Exercite a técnica da retroalimentação no processo de comuni-
cação para validar os requisitos. Inclua no seu plano de gerenciamento de comunica-
ções o processo de que sempre que um pacote de trabalho estiver para ser iniciado ou 
concluído, o processo de comunicação deve revisar os requisitos com as partes interes-
sadas envolvidas e com o cliente/usuário final. Desta forma, requisitos que não estão 
aderentes com o objetivo e o escopo podem ser identificados a tempo.
9. Informal. Muitos requisitos não podem ser coletados dentro do ambiente formal de 
trabalho. Marque um almoço com algumas partes interessadas e converse sobre o pro-
jeto de maneira aberta e despretensiosa. Muito da visão daquela parte interessada vai 
surgir desta forma e você vai poder conferir se os requisitos estão batendo.
10. Pesquisa! Recorra aos famosos ativos de processos organizacionais! Dependendo 
do nível de maturidade da empresa, lá você pode encontrar não só as lições aprendidas 
geradas para projetos anteriores como uma base de dados de requisitos… Ou um PMO 
que possa lhe informar onde encontrar essa informação… Ou um grupo de gerentes de 
projetos que podem lhe dar uma dica… Ou um punhado de técnicos que trabalharam 
em um projeto parecido… Ou nada. Mas procure lá!
Técnica Delphi: “Um grupo seleto de especialistas responde questionários e fornece co-
mentários a respeito das respostas de cada rodada de coleta de requisitos.” (PMBoK 4ª 
Edição, p. 108). Esta técnica permite que as idéias sejam expostas sem a interferência 
dos outros participantes e que posteriormente, quando reunidos, as mesmas sejam ava-
liadas com mais imparcialidade uma vez que ninguém sabe o certo quem deu cada idéia 
em específico.
Ativos de Processos Organizacionais: Os ativos de processo são todos os documen-
tos, arquivos, processos e conhecimento disponível para uso da instituição. O PMBoK 
diz: “[...] incluem qualquer um ou todos os ativos relacionados a processos, de quaisquer 
ou todas as organizações envolvidas no projeto e que podem ser usados para influenciar o 
sucesso do projeto. Estes ativos incluem planos formais e informais, políticas, procedimentos 
e diretrizes, [...] bases de conhecimento das organizações, como lições aprendidas e informa-
ções históricas.” (PMBoK 4ª Edição, p. 32).
Disponível em: <http://papogp.com/2011/08/03/10-dicas-para-coleta-de-requisitos/>. 
Acesso em: 26 jan. 2016.
Entenda sobre engenharia de requisitos.
<https://www.youtube.com/watch?v=t0so6Nagjns>. Acesso em: 26 jan. 2016.
Entenda mas sobre análise de requisitos.
<https://www.youtube.com/watch?v=2Lh-JH3SfE4>. Acesso em: 26 jan. 2016.
Considerações Finais
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
126 - 127
.
CONSIDERAÇÕES FINAIS
Nesta unidade, entendemos a importância da identificação dos requisitos de um 
sistema a ser desenvolvido, tivemos a oportunidade de avaliar melhor o que é, 
quem são as pessoas envolvidas neste processo, quando devemos estar atento a 
este item, onde este processo deve ser feito, técnicas que nos auxiliam a realizar 
o processo de coleta e detalhamento dos requisitos.
Também tivemos a oportunidade de verificar os diferentes tipos de requi-
sitos que existem, qual a sua importância para um bom processo de design e 
como eles interferem na qualidade do produto final. A identificação dos requi-
sitos de um sistema não é uma tarefa fácil, por isto passamos por várias técnicas 
que têm por objetivo auxiliá-lo neste processo. Vimos como podemos compor 
o trabalho de levantamento (unindo técnicas) para garantir maior aderência à 
necessidade do cliente.
Além disso, estudamos algumas das formas mais comuns de interpretação 
de maneira que a necessidade catalogada do cliente possa ser transformada em 
uma solução que venha agregar valor ao usuário final.
Na última unidade deste livro, vamos entender um pouco mais sobre os 
modelos de desenvolvimento de sistema e como eles podem influenciar no pro-
cesso de design e interação, vamos passar pelos processos mais significativos do 
projeto de um novo sistema e vamos abordar quais cuidados devemos tomar 
nestas etapas.
1. Agora que você aprendeu sobre a importância do processo de coleta 
e detalhamento de requisitos, como você espera colocar isto em prá-
tica no seu trabalho para produzir um design mais adequado?
2. Na sua opinião, como que o processo de coleta de requisitos pode 
prejudicar o estabelecimento de um design novo?
3. Quais os passos que precisamos dar para uma boa coleta/identifica-
ção dos requisitos?
U
N
ID
A
D
E V
Professor Esp. Ricardo Francisco de Pierre Satin
COLOCANDO TUDO ISTO 
PARA RODAR
Objetivos de Aprendizagem
 ■ Entender a importância das abordagens de desenvolvimento de 
sistemas e como podem impactar no processo de design.
 ■ Aproveitar os benefícios da abordagem de desenvolvimento 
selecionada para o processo de design.
 ■ Assegurar maior qualidade ao processo de design ao trabalhar com 
conceitos de projetos.
 ■ Extrair os benefícios para o processo de design ao trabalhar com 
metodologias de projeto ágeis.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Entendendo sua abordagem junto aos modelos de produção de 
software
 ■ Entendendo o design como parte do escopo de um projeto
 ■ Entendendo seu benefício no uso conjunto com metodologias ágeis
130 - 131
INTRODUÇÃO
Caro(a) aluno(a), fico satisfeito de você ter chegado na unidade final deste livro, 
espero que tenha aproveitado bastante e que possamos entender como colo-
car isto tudo em prática. Como disse Franklin Delano Roosevelt: “existe muitos 
modos de ir para frente, mas apenas um de ficar parado”. Espero que sua esco-
lha seja de seguir e com entusiasmo redobrado!
Até aqui nós estudamos a importância,para o sucesso ou para o fracasso, que 
um bom design de interação tem para um produto que está sendo desenvolvido. 
Vimos que design de interação é muito mais do que telas bonitas e teoricamente 
atraentes, vimos que é uma disciplina que envolve elementos de várias áreas, é 
realmente uma disciplina multidisciplinar.
Vimos abordagens que podem ser usadas por empresas para reduzir o alto 
custo que uma estratégia como esta pode nos acarretar. Vimos também um com-
ponente muito importante que é a interação humano-computador, passamos 
pelos conceitos de interface e verificamos sua evolução. 
Estudamos os conceitos relacionados à interpretação humana e também pas-
samos pelos elementos de memória humana e vimos como estes itens podem 
impactar no processo de desenvolvimento de uma nova solução.
Na unidade anterior, vimos a importância da documentação da necessidade 
de nossos clientes, levando em conta todos os fatores humanos descritos nas uni-
dades anteriores, pontuamos algumas das técnicas mais importantes que podem 
auxiliá-lo nesta difícil tarefa e, agora, chega o momento de começar o desenvol-
vimento deste novo produto.
Precisamos entender um pouco mais sobre os modelos de desenvolvimento 
de software e como o processo de design e interação pode/deve se encaixar em 
cada um deles. Precisamos entender que design é um elemento importantís-
simo do escopo a ser mapeado e, para isto, muitos riscos estão envolvidos, e nada 
melhor do que encarar isto como parte de um projeto de desenvolvimento de 
uma nova aplicação.
Nos tempos atuais, uma das metodologias mais difundidas de gerenciamento 
de projetos é o Scrum, uma metodologia ágil que tem recursos fenomenais que 
podem apoiar este processo de design oferecendo maior segurança a nossos 
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
130 - 131
COLOCANDO TUDO ISTO PARA RODAR
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
132 - 133V
clientes, dando maiores garantias de que ele, de fato, vai receber algo que se 
enquadre em suas necessidades.
ENTENDENDO SUA ABORDAGEM JUNTO AOS 
MODELOS DE PRODUÇÃO DE SOFTWARE
Não é objetivo deste livro lhe ensinar os vários modelos de produção de siste-
mas, para isso você tem a disciplina de engenharia de software, que lhe dará toda 
fundamentação para isto, entretanto é importante esta correlação com esta área 
tão relevante devido às necessidades em comum.
Segundo Pressman (2006), alguns dos principais modelos são: Modelos 
Prescritivos, Modelos em Cascata, Modelos Incrementais de Processo, Modelos 
Evolucionários de Processo de Software, Modelos Especializados em Processo 
e o Processo Unificado.
Vamos entender um pouco mais sobre estes modelos e onde se encaixa o 
processo de design em cada um.
 ■ Modelos Prescritivos
Modelos prescritivos tem este nome, pois prescrevem um conjunto de ações 
e tarefas que devem ser levados em consideração para o desenvolvimento de um 
sistema. Temos que entender que não significa que ele seja estático, eles podem 
ser adaptados à pessoa, ao problema e ao projeto. Podemos dizer que todos os 
demais modelos que veremos a seguir são prescritivos.
Se você trabalha em uma empresa que tem um check-list que deve ser seguido 
para o desenvolvimento de uma solução, provavelmente você deve estar traba-
lhando em uma empresa que trabalha com este modelo no desenvolvimento de 
sistemas. 
Segundo Pressman (2006, p. 55) temos:
O modelo prescritivo de software tem sido aplicado durante muitos 
anos em um esforço de trazer ordem e estrutura para o desenvolvimen-
©shutterstock
Entendendo sua Abordagem Junto aos Modelos de PRodução de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
132 - 133
to de software... todos realizam o mesmo conjunto de atividades gené-
ricas de arcabouço: comunicação, planejamento, modelagem, constru-
ção e implantação.
Quando uma empresa trabalha com modelos que se enquadram neste processo, 
certamente o design estará sendo considerado no item comunicação, e só na 
fase de construção é que os trabalhos realmente começam. Cuidados no pla-
nejamento e modelagem precisam ser tomados para garantir que os requisitos 
funcionais e não funcionais tenham sido levantados levando em consideração 
os aspectos retratados neste livro.
 ■ Modelos em Cascata
O modelo em cascata requer um bom entendimento dos requisitos e que estes 
fluam linearmente até a fase de implantação. A construção de sistema que fujam a 
características como esta devem nos levar a pensar na utilização de outro modelo.
Segundo Pressman (2006, p. 55) temos:
O modelo em cascata sugere uma progressão linear das atividades 
de arcabouço que é frequentemente inconsistente com as realidades 
modernas (por exemplo: modificações contínuas, sistemas evolutivos, 
prazos apertados) do mundo de software. No entanto, ele tem aplica-
bilidade em situações onde os requisitos são bem definidos e estáveis.
COLOCANDO TUDO ISTO PARA RODAR
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
134 - 135V
O design deve estar inserido na fase de comunicação, fase esta na qual é feita 
a iniciação do projeto e estabelecidos os requisitos. Como supõe pouca alte-
ração no que se espera que seja desenvolvido, pouca interação ocorre com o 
cliente, onde somente na fase de implantação este volta a ver aquilo que soli-
citou na primeira fase. Isto é um risco enorme, fato que pode colocar em risco 
todo desenvolvimento.
Fonte: Elaborado pelo autor.
 ■ Modelos Incrementais de Processo
Quando falamos de desenvolvimento de sistemas, Pressman (2006, p.39) define 
bem como: “Há muitas situações em que os requisitos iniciais do software são 
razoavelmente bem definidos, mas o escopo global do esforço de desenvolvi-
mento elimina um processo puramente linear”.
Neste cenário, o modelo incremental é uma boa alternativa no desenvolvi-
mento de soluções. Ele combina elementos do modelo em cascata trabalhando 
com iteração. O modelo incremental trabalha com a ideia de entregas parciais, 
com a ideia de que conforme funcionalidades estejam em condições de serem 
usadas, estas podem ser disponibilizadas ao usuário. Pense na criação de um sis-
tema de vendas pela internet. Assim que o cadastro de clientes esteja finalizado, 
este poderia ser entregue para o cliente começar atualizar sua base cadastral.
Uma comparação do modelo incremental com a prototipação, que é uma 
abordagem do modelo evolucionário que estudaremos a seguir, permite verificar 
que no modelo incremental soluções prontas para uso são liberadas ao cliente.
©shutterstock
Entendendo sua Abordagem Junto aos Modelos de PRodução de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
134 - 135
Segundo Pressman (2006, p. 55), “modelos incrementais do processo de 
software produzem o software como uma série de versões de incrementos”. O 
processo de design é muito mais participativo neste modelo de trabalho, perceba 
que como as entregas ocorrem mais rapidamente, o feedback do cliente é muito 
mais rápido, exigindo avaliação se nosso modelo mental aplicado ao desenvol-
vimento da aplicação condiz com o que é o realmente posto em prática. Há um 
risco neste modelo que é o momento da validação do usuário do design criado, 
apesar de iterações serem constantes e o desenvolvimento ser relativamente mais 
curto, há um tempo entre o requisito finalizado e a primeira entrega feita que 
tem que ser cuidado.
 ■ Modelos Evolucionários de Processo de Software
Os modelos evolucionários permitem a produção de versões de software 
cada vez mais completas a cada interação. 
A prototipação é uma ótima ferramenta dentro do modelo evolucionário, ela 
permite que quandoo cliente tem uma necessi-
dade razoável, mas não tem todos os detalhes, 
o desenvolvimento de um protótipo pode ser 
o primeiro passo a ser dado rumo ao desen-
volvimento da solução completa.
Aqui começa o trabalho do design, este 
processo praticamente coloca este profissio-
nal como o primeiro elemento junto com o 
analista de negócios na frente do cliente. Este 
processo de prototipação é uma das melho-
res estratégias que existem para garantir um 
bom design e interação.
Entenda que o protótipo gerado pode ser 
um protótipo que “rode” ou não, não existe 
uma obrigatoriedade quanto a isto, e um cri-
tério interessante é que este protótipo pode 
ser utilizado como parte pela equipe de desen-
volvimento, reduzindo assim seu trabalho.
COLOCANDO TUDO ISTO PARA RODAR
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
136 - 137V
Outra técnica interessante que é preciso validar é o modelo espiral, ele é defi-
nido por Pressman (2006, p. 45) como:
O modelo espiral é uma abordagem realista do desenvolvimento de 
sistemas e softwares de grande porte. Como o software evolui à medida 
que o processo avança, o desenvolvedor e o cliente entendem melhor e 
reagem aos riscos de cada nível evolucionário.
O modelo espiral permite uma melhor iteração entre as fases de desenvol-
vimento, facilitando assim a construção de soluções mais robustas e seguras. O 
Design é parte integrante de qualquer fase do ciclo do projeto e facilita e muito 
a obtenção do feedback do cliente.
Segundo Pressman (2006, p. 55) temos:
Modelos evolucionários de processo reconhecem a natureza iterativa 
da maioria dos projetos de engenharia de software e são projetadas para 
acomodar as modificações. Modelos evolucionários como o modelo es-
piral e de prototipagem, produzem produtos de trabalho incrementais 
(ou versões de software que funcionem) rapidamente. Esses modelos 
podem ser adotados para serem aplicados ao longo de todas as ativida-
des de engenharia de software – desde o desenvolvimento de conceitos 
até a manutenção do sistema no longo prazo.
 ■ Modelos Especializados em Processo
Esta é uma estratégia de desenvolvimento que tem muitas características dos 
modelos estudados até aqui.
Este modelo de desenvolvimento trabalha com conceito de criação de 
pequenos sistemas reutilizáveis, que podemos classificar de componentes. Estes 
componentes são facilmente ligados a outros sistemas, logo, perceba a necessi-
dade de uma boa e clara adequação de design neste aspecto! 
Outra ferramenta, além da baseada em componentes, é a utilização de méto-
dos formais para a definição das regras de utilização provadas matematicamente. 
Esta ferramenta, apesar de dar uma ótima referência sobre o que tem que ser 
feito sistemicamente e de ser uma maravilhosa fonte de checagem, verificando se 
as funcionalidades estão conforme desejadas, deixam muito a desejar quando o 
ponto de avaliação é design. Então, bastante cuidado deve ser tomado em solu-
ções que optem pelo modelo de desenvolvimento baseado em métodos formais, 
pois um risco alto é corrido sobre design e interação.
Entendendo sua Abordagem Junto aos Modelos de PRodução de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
136 - 137
Segundo Pressman (2006, p. 55), temos:
Aqui, o modelo baseado em componentes enfatiza a reutilização e a 
montagem de componentes. O modelo de métodos formais encoraja 
uma abordagem com base na matemática para o desenvolvimento e a 
verificação do sistema. O modelo orientado a aspectos acomoda preo-
cupações transversais que cobrem toda a arquitetura do sistema.
 ■ Processo Unificado
Segundo Pressman (2006, p. 55), temos:
O Processo Unificado é um processo de software “orientado por ca-
sos de uso, centrado na arquitetura, iterativo e incremental”. Projetado 
como um arcabouço para métodos e ferramentas UML. O processo 
unificado é um modelo incremental no qual cinco fases são definidas: 
(1) uma fase de concepção que engloba tanto a comunicação com o 
cliente quanto atividades de planejamento, enfatiza o desenvolvimento 
e refinamento dos casos de uso como modelo principal; (2) uma fase 
de elaboração que engloba atividades de comunicação com o cliente e 
modelagem com foco na criação de modelos e análise de projeto com 
ênfase na definição de classes e representações arquiteturais; (3) uma 
fase de construção que refina e então traduz o modelo de projeto para 
componentes de software implementados; (4) uma fase de transição 
que transfere o software do desenvolvedor para o usuário final para 
testes beta e de aceitação; (5) uma fase de produção em que contínuo 
monitoramento e suporte são conduzidos.
Com certeza é um processo bastante robusto mas que existe uma gama muito 
grande de artefatos e pode não ser aplicável a qualquer tipo de projeto. Como 
se trata de um processo iterativo e incremental o design se encaixa em cada 
etapa, mas o feedback do usuário é relativamente mais longo se comparado com 
outros métodos.
©shutterstock
COLOCANDO TUDO ISTO PARA RODAR
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
138 - 139V
ENTENDENDO DESIGN COMO PARTE DO ESCOPO DE 
UM PROJETO
Prezado(a) aluno(a), vimos no decorrer deste livro a importância do design e 
estudamos várias técnicas ligadas à coleta de requisitos e sua transformação para 
que, como resultado, tenhamos um produto que seja aderente às necessida-
des do cliente.
No tópico anterior, vimos os diferentes modelos de 
desenvolvimento de software, desde os mais clássi-
cos aos mais modernos, e agora, neste penúltimo 
tópico do livro, quero falar a respeito da maneira 
como podemos “blindar” ainda mais nossas apli-
cações de forma que sejam bem-sucedidas.
Dentro da própria engenharia de software, 
um item que é de fundamental importância para 
que um produto seja bem-sucedido é encará-
-lo como um projeto. Um projeto de software 
envolve o planejamento do que necessita ser 
feito, o monitoramento e controle das etapas 
que conduzem o projeto ao seu término, cuida-
dos para que as entregas sejam bem-sucedidas 
(finalização do projeto ou etapa).
Não é objetivo deste livro detalhar todo processo de gerenciamento de um 
projeto, mas sim trazer alguns pontos fundamentais que possam contribuir para 
que, uma vez detectada a necessidade do cliente, esta se transforme em algo real-
mente útil.
Então, a primeira coisa que quero definir contigo é: O que realmente é um 
projeto?.
Conforme o Guia PMBOK em sua 4ª edição, temos a seguinte definição de 
projeto: “Um projeto é um esforço temporário empreendido para criar um pro-
duto, serviço ou resultado exclusivo”.
Perceba que a ideia por trás de um projeto está justamente em dar a você as 
condições necessárias para que um produto seja desenvolvido. Existem várias 
©shutterstock
©shutterstock
Entendendo Design como Parte do Escopo de um Projeto
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
138 - 139
metodologias de gerenciamento de projetos que, assim como as de desenvolvi-
mento de software listadas acima, lhe oferecem um guia para que um sistema 
seja desenvolvido, estas oferecem um guia de boas práticas para que você possa 
fluir por todas as etapas de desenvolvimento cuidando de todos os fatores que 
estão envolvidos nesta difícil tarefa de prover soluções.
Vou apresentar agora alguns pontos que julgo relevantes conforme esta-
belecido pelo Project Management Institute (PMI) e agrupados em seu guia de 
conhecimentos sobre gerenciamento de projetos, o PMBOK, que está em sua 4ª 
edição. No próximo tópico, vou retratar alguns aspectos relevantes sobre uma 
metodologia ágil e como ela pode apoiar também em nosso processo de design.
O desenvolvimento de sistemas é algo que não é só ir programando que 
uma hora sai o que o cliente quer! Nenhum dos modelosque estudamos ante-
riormente se baseia no princípio da tentativa e erro, apesar do ciclo de iteração 
propiciar isto, nenhum modelo sugere um desenvolvimento sem nenhum tipo 
de formalização.
Para apoiar esta formalização é que uma metodologia de gerenciamento 
de projetos se encaixa muito bem. Seguindo o que o PMI considera relevante 
a ser considerado no desenvolvimento de qual-
quer projeto (inclusive de software), temos 
os seguintes itens:
 ■ Integração
Esta área cuida para que todas as outras 
oito áreas de conhecimentos comentadas na 
sequência estejam sendo realizadas. Um dos 
maiores cuidados de um gerente de projeto é 
garantir a integração, ou seja, garantir que tudo esteja acon-
tecendo conforme planejado.
 ■ Escopo
Aqui entra todo processo de coleta, definição e análise do 
escopo do que deve ser feito e do que não deve ser feito no pro-
jeto. Esta é a área de conhecimento que trabalha firmemente 
©shutterstock
©shutterstock
©shutterstock
©shutterstock
COLOCANDO TUDO ISTO PARA RODAR
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
140 - 141V
com os modelos de desenvolvimento de sof-
tware que vimos no tópico anterior. 
 ■ Tempo
Está aqui o conjunto de conhecimento 
para procurar prover ao projeto ferramentas que podem ajudar na 
estimativa e controle dos projetos.
 ■ Custo
Temos aqui um conjunto de ferramentas e téc-
nicas que apoiam o controle dos custos do projeto.
 ■ Qualidade
Como medir? Como assegurar a qualidade? O 
objetivo desta área de conhecimento é apoiar que a 
construção do projeto tenha como saída um sistema 
com os padrões de qualidade acordado entre as partes.
 ■ Recursos Humanos
Envolve o bom gerenciamento 
de todos os recursos envolvidos na 
construção de um projeto. Quem 
são os mais adequados? Que capa-
citações eles precisam? Perceba que 
existe uma relação interessante com 
design e interação, pois poderia estar 
aqui todo processo de capacitação 
necessário à equipe de desenvolvi-
mento para estarem aptos a aplicar 
©shutterstock
©shutterstock
©shutterstock
Entendendo Design como Parte do Escopo de um Projeto
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
140 - 141
os fundamentos ensinados neste livro!
 ■ Comunicação
É como cuidar e garantir uma comunicação assertiva 
entre todos os stakeholders (qualquer pessoa que de alguma 
forma é afetada direta ou indiretamente com o projeto) do 
projeto.
 ■ Riscos
Identificar antecipadamente os riscos envolvidos no pro-
jeto, o cliente deseja que seu aplicativo rode em plataforma 
desktop, web e móvel? Isto pode ser um risco para o projeto 
dependendo de nossa plataforma de desenvolvimento. Quais 
as possíveis respostas que posso dar a este risco? O processo 
de desenvolvimento tem muitos riscos envolvidos e muitos 
deles têm impacto direto no design de nossas aplicações.
 ■ Aquisições
Cuida para que todo processo de aquisição necessária 
ao projeto ocorra de forma ética e transparente, de forma 
que não gere comprometimento às outras atividades e áreas 
envolvidas.
Dentre as nove áreas de conhecimento acima, julgo as mais críticas: Escopo, 
Tempo, Custo e Qualidade e, por isso, vou lhe apresentar alguns detalhes 
complementares.
Devemos pensar nesta área de escopo com muito carinho. Já vimos em outro 
Desenvolver sistemas não é só levantar o que o cliente quer e ir programan-
do e validando?
COLOCANDO TUDO ISTO PARA RODAR
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
142 - 143V
tópico deste livro que uma das principais razões para o insucesso de projetos é 
um mau gerenciamento do escopo. 
Vimos também em outros tópicos a importância da coleta e análise dos requi-
sitos do cliente. Uma boa avaliação dos requisitos funcionais e especialmente dos 
não funcionais traz subsídios para uma boa identificação de qual escopo deve 
ser contemplado na criação da solução. 
A razão do escopo bem definido e controlado é tão importante que impacta 
diretamente nos critérios de custo, tempo e qualidade.
Acompanhei um projeto certa vez cujo escopo funcional foi totalmente con-
cluído no prazo que foi estabelecido em contrato, entretanto os itens de escopo 
relacionados a requisitos não funcionais, dentre eles de usabilidade, não foram 
contemplados com a mesma eficiência. Critérios de ergonomia não foram atendi-
dos, e uma série de fatores fizerem com que a aceitação do produto fosse mínima. 
Tivemos que voltar para a fase de planejamento e realizar os ajustes necessários. 
Perceba que, para que isto tenha chegado a acontecer, houve duas grandes falhas:
1. Mapeamento do escopo e controle – especialmente dos ligados a requi-
sitos não funcionais.
2. Falha de iteração entre as fases no modelo de desenvolvimento escolhido 
para aquele projeto.
Uma certeza existe, falhas quando ocorrem nunca é por um único critério, mas 
tenha certeza de que um bom gerenciamento do escopo pode aumentar em 
muito suas chances de sucesso.
Quando falamos de qualidade, estamos falando diretamente de satisfação 
do cliente, estamos falando de critérios de usabilidade, satisfação e vários outros 
que vimos desde a Unidade I deste livro. Não vou mencioná-los aqui novamente, 
mas você pensar neles e enquadrá-los em um gerenciamento da qualidade pode 
fazer com que seu sistema atenda aos critérios estabelecidos por ambas as partes.
Em resumo, quero que entenda que os princípios de gerenciamento de pro-
jetos associado a um modelo de desenvolvimento de software adequado, com 
atenção redobrada aos quesitos de design e interação abordados neste livro, 
podem trazer a você uma maneira de “blindar” o processo de criação de um 
novo sistema e potenciar aceitação dele frente ao mercado.
©shutterstock
Entendendo seu Benefício no Uso Conjunto com Metodologias Ágeis
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
142 - 143
ENTENDENDO SEU BENEFÍCIO NO USO CONJUNTO 
COM METODOLOGIAS ÁGEIS
Caro(a) aluno(a), uma das metodologias ágeis mais utilizadas no momento é 
Scrum e a escolhi para ser tema deste tópico devido à sua grande aceitação, sua 
ótima implementação de características que os modelos iterativos, incrementais 
e evolucionários oferecem, assim como sua crescente utilização no mercado de 
desenvolvimento de sistemas. Hoje, já é uma das principais metodologias utiliza-
das pelas empresas para gerenciar seus projetos e, dentre as metodologias ágeis, 
é a mais utilizada (conforme pesquisa - PMSurvey de 2012).
Fonte: PMSurvey 2012
O Scrum trabalha fortemente com os conceitos de entrega parcial, desenvolvi-
mento iterativo e agilidade no desenvolvimento que trazem uma percepção de 
valor agregado pelo cliente muito forte.
Quem já passou pelo processo de construir sua casa própria sabe como é um 
processo demorado (geralmente entre 5 a 9 meses) e também bem estressante. 
O processo de construção de casa é um processo que é completamente feito em 
COLOCANDO TUDO ISTO PARA RODAR
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
144 - 145V
cascata (se formos fazer uma analogia aos modelos de desenvolvimento). Você 
paga, vê a obra acontecendo, mas só no final é que poderá receber as chaves e 
efetivamente desfrutar do novo lar.
Você não consegue fazer uso de sua casa até que tudo acabe. Voltando a 
analogia com o modelo cascata, você não consegue usar o sistema até que ele 
seja entregue. Pense que o sistema pode levar os mesmos de 5 a 9 meses como 
o caso da casa, pense na ansiedade que é passada pela parte do contratante. Na 
construção da casa você pode ir e ver as etapas sendo entregue (aterro, funda-
ção, acabamento ...), quando falamos de sistema nem sempre isto é possível de se 
fazer. Você pode chegar com um calhamaço de papel após três meses de trabalho 
para o contratante e dizer: “tome,esta é a fundação de seu sistema, os requisitos 
estão prontos”, dessa forma, dificilmente ele vai ficar feliz... pois não é algo pal-
pável. O que ele quer ver mesmo é uma “telinha”, algo que ele possa “mexer” e 
ver se está conforme ele “imaginava”.
Voltando para o caso da construção, imagine que você pudesse entregar a 
churrasqueira de forma que o dono da casa já possa receber seus parentes para 
uma confraternização antes do término da casa? Ele terá na parte frontal toda uma 
estrutura inacabada, mas, com pouco tempo de construção, valor foi agregado.
É este o propósito que o Scrum tem para oferecer, ao menos é sua promessa, 
que, com pouco tempo de projeto, algo palpável possa ser finalizado e entregue 
para uso, assim como os modelos incrementais o fazem. 
Fonte: <http://pt.wikipedia.org/wiki/Scrum>.
Entendendo seu Benefício no Uso Conjunto com Metodologias Ágeis
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
144 - 145
A imagem acima representa o clico de desenvolvimento com o Scrum, assim 
como os seus principais elementos. Vamos na sequência entender mais de cada 
um deles.
1. Product Backlog
Aqui temos o que é conhecido que deve ser feito. Todo esforço necessá-
rio para que o projeto seja desenvolvido está definido no Product Backlog.
Para que estes itens estejam classificados, há necessidade direta de envol-
vimento no levantamento dos requisitos necessários para o sistema e 
aqui começa o desafio do Design para prover uma solução que em curto 
espaço de tempo já esteja em uso.
O máximo de informações sobre requisitos funcionais e não funcionais 
deve ser levantado de forma bastante dinâmica.
O nível de formalização é definido pela equipe e cliente. É comum que 
requisitos sejam definidos em quadros, desenhos em papel etc., intera-
ções que permitam o bom entendimento do que é necessário fazer e que 
não gastem muito tempo.
Fotos de quadros com o desenho (protótipo) do que se espera ser feito é 
comum (ainda mais se o cliente estiver na foto dando um “OK” de apro-
vação!).
2. Sprint Backlog
Uma vez que o que necessita ser feito está definido, o próximo passo é 
quebrar em Sprints. Sprints são períodos curtos de tempo, suficiente-
mente grandes para que algo de valor seja entregue, mas no contexto 
geral bastante curto. 
Em média, tenho visto a fragmentação dos sprints em uma ou duas sema-
nas, tempo mais que suficiente para que algo seja desenvolvido e entregue 
ao cliente para uso.
O Sprint Backlog serve para fornecer ao cliente uma noção de tempo, 
uma espécie de cronograma de quando aquilo que é conhecido e priori-
zado pelo cliente será entregue.
3. Sprint
Os Sprints são as ações de trabalho em si. É nela que a equipe de desen-
volvimento estará focada, direcionando seus esforços para que, como 
COLOCANDO TUDO ISTO PARA RODAR
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
146 - 147V
resultado de seu trabalho, uma funcionalidade seja liberada.
É aqui que está um bom envolvimento do Design. Para entender melhor 
como isto é possível, vamos analisar como é o ciclo de trabalho dentro 
da Sprint.
A primeira macro atividade a ser realizada dentro da Sprint é o que se 
chama de Sprint Planning um. Nesta reunião, toda equipe está reunida 
com intenção de ter todo entendimento do que deve ser desenvolvido. 
Nesta reunião, a presença do cliente é importante (ou de um seu represen-
tante), e CRITÉRIOS para um bom design devem/podem ser observados.
O próximo passo é a equipe se reunir no que é chamado Sprint Planning dois, em 
que o atendimento das necessidades do cliente será tratado! Perceba que outra 
vez uma boa interação do design é importante, ainda mais que requisitos não 
funcionais são foco desta reunião.
As demais interações que a equipe terá durante o desenvolvimento da Sprint 
não são relevantes para nosso estudo, exceto a entrega da funcionalidade para 
o cliente. Esta entrega ocorre no que é chamado de Review, ou seja, o cliente 
irá verificar (receber) aquilo que pediu que fosse feito. Perceba que neste exato 
momento critérios de usabilidade, validações quanto aos modelos mentais podem 
ser feitas pela simples observação de uso da ferramenta por parte da equipe.
4. Work increment of the software
Como resultado final de nosso desenvolvimento, teremos a liberação 
para uso em escala por parte dos demais usuários, haja vista que este foi 
validado e aprovado.
Perceba que este é um clico de interação rápido e que propicia fácil fee-
dback por parte do cliente, sendo assim, um bom acompanhamento por 
parte do responsável pelo design e interação em todo este ciclo é fun-
damental.
Baseado nisto, classifico que o Scrum é uma ótima ferramenta que, se 
bem usada por parte da equipe, pode auxiliar e muito no processo de 
soluções que tenham uma boa interação por meio da construção de um 
bom design.
146 - 147
MODELO DE DESENVOLVIMENTO DE SOFTWARE
Por Bruno Stain 
Hoje em dia nos deparamos com várias metodologias para o desenvolvimento de um 
projeto, mas temos os modelos de desenvolvimento, que falando em um modo de he-
rança seriam os pais das metodologias. Os modelos de desenvolvimento são divididos 
em três partes principais, o desenvolvimento em Cascata, Iterativo e Incremental. O 
desenvolvimento em cascata é o mais tradicional dos três, por parecer ser mais simples 
e organizado, porém durante o desenvolvimento do projeto podem ocorrer inúmeras 
falhas decorrentes desse modelo Cascata, por isso veio os métodos Iterativo e Incre-
mental, com a ideia de substituir o modelo Cascata e acabar com as suas falhas, mas 
como nada é perfeito eles também têm as suas falhas, mas vamos conhecer um pouco 
de cada e entender qual pode ser a melhor opção na hora de desenvolver um software.
MODELO EM CASCATA
O modelo cascata tornou-se muito conhecido na década de 70 e é comentado na 
maioria dos livros de engenharia de software. Nesse modelo as atividades do processo 
de desenvolvimento são estruturadas em uma cascata onde a saída de uma etapa é a 
entrada para a próxima etapa. As suas principais atividades são:
 ■ Estudo de Viabilidade
 ■ Análise e Especificação de Requisitos
 ■ Design da Arquitetura
 ■ Design Detalhado
 ■ Codificação e Testes de Unidades
 ■ Integração e Testes do Sistema
 ■ Entrega e Instalação
 ■ Manutenção
Existem variações desse modelo apresentando, porém, a principal característica comum 
é um fluxo linear e sequencial de atividades semelhantes a descritas anteriormente.
O modelo Cascata é criticado por ser linear, rígido e monolítico. Inspirados em modelos 
de outras atividades de engenharia, este modelo argumenta que cada atividade apenas 
deve ser iniciada quando a outra estiver terminada e verificada. Ele é considerado mo-
nolítico por não introduzir a participação de clientes e usuário durante as atividades do 
desenvolvimento, mas apenas o software ter sido implementado e entregue. Não existe 
como o cliente verificar antecipadamente qual o produto final para detectar eventuais 
problemas.
Vantagens:
 ■ Torna o processo de desenvolvimento estruturado;
 ■ Tem uma ordem sequencial de fases;
 ■ Cada fase cai em cascata na próxima e cada fase deve estar terminada antes do 
início da seguinte;
 ■ Todas as atividades identificadas nas fases do modelo são fundamentais e estão 
na ordem certa;
 ■ Esta abordagem é atualmente a norma e provavelmente permanecerá por um 
tempo, mas temos o desenvolvimento ágil chegando com muita força na maioria 
das empresas de grande porte;
Desvantagens:
 ■ Não fornece feedback entre as fases e não permite a atualização ou redefinição 
das fases anteriores;
 ■ Não suporta modificações nos requisitos;
 ■ Não prevê a manutenção;
 ■ Não permite a reutilização;
 ■ É excessivamente sincronizado;
 ■ Se ocorrer um atraso todo o processo é afetado;
 ■ Demora muito para ser entregue o software;
MODELO ITERATIVO E INCREMENTAL
Desenvolvimento Incrementalé uma estratégia de planejamento estagiado em que vá-
rias partes do sistema são desenvolvidas em paralelo, e integradas quando completas. 
Não implica, requer ou pressupõe desenvolvimento iterativo ou em cascata – ambos são 
estratégias de retrabalho. A alternativa ao desenvolvimento incremental é desenvolver 
todo o sistema com uma integração única.
Desenvolvimento Iterativo é uma estratégia de planejamento de retrabalho em que o 
tempo de revisão e melhorias de partes do sistema é pré-definido. Isto não pressupõe 
desenvolvimento incremental, mas funciona muito bem com ele. Uma diferença típica 
é que a saída de um incremento não é necessariamente assunto de um refinamento 
futuro, e seu teste ou retorno do usuário não é utilizado como entrada para planos de 
revisão ou especificações para incrementos sucessivos. Ao contrário, a saída de uma ite-
ração é examinada para modificação, e especialmente para revisão dos objetivos das 
iterações sucessivas.
A idéia básica por trás da abordagem iterativa é desenvolver um sistema de software 
incremental, permitindo ao desenvolvedor tirar vantagem daquilo que foi aprendido 
durante a fase inicial de desenvolvimento de uma versão do sistema. O aprendizado 
ocorre simultaneamente tanto para o desenvolvedor, quanto para o usuário do sistema.
VANTAGENS DO MODELO ITERATIVO
 ■ Baseia-se fortemente na participação e uma boa comunicação entre desenvol-
vedores e usuários.
 ■ Há um grande envolvimento do utilizador e do cliente cliente. Isto leva a mal-
-entendimentos por causa das divergências entre os desenvolvedores e usuários 
que rapidamente podem ser superados. Porque há resultados mais rápidos e “tan-
gíveis”, os usuários também serão capazes de dar um melhor feedback;
 ■ Os resultados mostrados permitirá que os usuários tenham confiança em um 
bom resultado;
 ■ A cada ciclo do sistema os usuários e cliente poderão utilizar o sistema dire-
tamente, eles são os “testadores” no processo de desenvolvimento e eles estarão 
iteragindo com o sistema durante o desenvolvimento;
 ■ Os riscos podem ser melhor administrados por pequenos pedaços do sistema a 
serem desenvolvidos em pequenos espaços de tempo;
 ■ Os sistemas complexos são mais claros e menos complexos para implementá-
-los aos poucos, sem a necessidade de começar a implementação do zero;
 ■ Ao fim de cada iteração pode-se ter um feedback para ter noção de como está 
o projeto, mesmo se não estiver de acordo ainda há tempo para mudanças, com o 
modelo Cascata isso não é possível;
 ■ Alterações nos requisitos podem ser rapidamente incorporadas no processo de 
desenvolvimento.
DESVANTAGENS DO MODELO ITERATIVO
Durante o processo de desenvolvimento necessita-se adaptar e refinar o sistema, com 
isso pode ser que no final saia totalmente diferente da ideia original;
Pode acontecer na continuação do trabalho o surgimento de muitos requisitos novos, 
esse sistema nunca irá terminar. Isso é chamado de aumento de escopo;
Gerentes que estão acostumados com a forma linear do desenvolvimento de um sof-
tware pode ter alguns problemas na hora de ir para uma forma mais flexível;
Inexperiência com a forma de trabalhar do modelo Iterativo pode levar a problemas 
posteriores, por isso é necessário certo conhecimento para começar a usar esse modelo;
Vantagens do Modelo Incremental
 ■ As versões são fornecidas após cada iteração do modelo incremental;
 ■ O Modelo Incremental inclui o uso do software pelo usuário para que as mu-
danças sejam feitas de acordo com o mesmo;
 ■ Esse modelo não afeta o lado financeiro, porque ele prove o “core” do software 
que o cliente precisa, o que vai ajudar o cliente a manter o negócio da mesma for-
ma, sem alterações no lado financeiro;
 ■ É flexível e fácil de gerenciar processo mais administráveis e fazer um software 
melhor com uma melhor estrutura;
 ■ Melhor gerenciamento de riscos, porque você pode confirmar o resultado com 
o cliente depois de cada versão do sistem e sempre verificar se estão fazendo o que 
está de acordo com o plano ou não, e corrigi-los na próxima versão do software;
 ■ Os testes são simples;
Desvantagens do Modelo Incremental
 ■ Cada fase de uma iteração é rígida e não se sobrepõem uns aos outros;
 ■ Podem surgir problemas relativos à arquitetura do sistema, porque nem todos 
os requisitos estão reunidos na frente de todo o ciclo de vida do software.
 ■ O modelo Incremental precisa ser relativamente pequeno.
Há uma década, vem se tentando encontrar um processo ou metodologia previsível e 
repetível que melhore a produtividade e qualidade. Alguns tentaram sintetizar e forma-
lizar a tarefa aparentemente incontrolável de escrever um software. Outros aplicaram 
técnicas de gerenciamento de projeto na escrita de software. Sem o gerenciamento de 
projeto, projetos de software podem facilmente sofrer atraso ou estourar o orçamento. 
Como um grande número de projetos de software não atendem suas expectativas em 
termos de funcionalidades, custo, ou cronograma de entrega, ainda não existe um mo-
delo de processo perfeito para todas aplicações.
Disponível em: <http://protocoloti.blogspot.com.br/2012/03/os-modelos-de-desenvol-
vimento-de.html>. Acesso em: 26/01/2012.
PRINCÍPIOS POR TRÁS DO MANIFESTO ÁGIL
Nós seguimos estes princípios: 
Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de 
software com valor agregado. 
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. 
Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o 
cliente. 
Entregar frequentemente software funcionando, de poucas semanas a poucos meses, 
com preferência à menor escala de tempo. 
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por 
todo o projeto. 
Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte 
necessário e confie neles para fazer o trabalho. 
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de 
desenvolvimento é através de conversa face a face. 
Software funcionando é a medida primária de progresso. 
Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desen-
volvedores e usuários devem ser capazes de manter um ritmo constante indefinidamen-
te. 
Contínua atenção à excelência técnica e bom design aumenta a agilidade. 
Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essencial. 
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. 
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina 
e ajusta seu comportamento de acordo.
Disponível em: <http://www.agilemanifesto.org/iso/ptbr/principles.html >. Acesso em: 
26/01/2016.
Construindo resultados com gerenciamento de projetos – Ricardo Vargas.
<https://www.youtube.com/watch?v=xtCtKirpKwg&feature=relmfu>. Acesso em 26/01/2016
Metodologias ágeis
<https://www.youtube.com/watch?v=9xqqvwaua7w>. Acesso em 26/01/2016
COLOCANDO TUDO ISTO PARA RODAR
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
152 - 153V
CONSIDERAÇÕES FINAIS
Caro(a) aluno(a), chegamos ao final da última unidade, aqui estudamos como 
as metodologias de desenvolvimento de sistemas, sejam elas mais tradicionais, 
sejam elas mais contemporâneas (ágeis), podem influenciar o processo de design 
e interação.
Vimos em cada uma delas os principais pontos de atenção que necessita-
mos ter para um bom design, também vimos a importância da interação entre 
as metodologias de desenvolvimento com metodologias de gerenciamento de 
projetos. Quando falamos de metodologia de gerenciamento de projetos, ava-
liamos os principais processos envolvidos onde, os principais estão ligados ao 
escopo, tempo, custo e qualidade.
Estudamos também sobre metodologias de gerenciamento de projetos ágeis, 
onde abordamos o Scrum como referência, vimos seu ciclo de vida e os princi-
pais pontos onde o processo design e interaçãopode ser inserido com maiores 
possibilidades de aproveitamento dos benefícios desta metodologia. 
Espero que o conteúdo trabalhado nesta unidade, assim como os demais 
tratados no decorrer deste livro, possa auxiliá-lo na difícil tarefa de produzir sis-
temas com a melhor usabilidade que seus usuários possam precisar.
Os aspectos retratados nas primeiras unidades deste livro podem ser trata-
dos neste momento!
Como podemos aplicar o Modelo GOMS nesta reunião com o cliente para 
garantir uma melhor usabilidade de nosso sistema?
152 - 153
1. Quais as diferenças entre o modelo de desenvolvimento em cas-
cata e o incremental? Em qual deles o processo de design pode 
se mais prejudicado?
2. Como as metodologias de gerenciamento de projetos ágeis 
podem apoiar no processo de interação da equipe de desenvol-
vimento com o cliente e obter um melhor design?
3. Quais modelos de desenvolvimento de sistema estão presen-
tes no Scrum?
154 - 155
CONCLUSÃO
154 - 155
Neste livro procurei levar a você conhecimentos acerca do processo de design e 
interação que julgo relevantes para seu processo de aprendizado.
Para compreendermos melhor este processo, começamos na Unidade I entendendo 
sobre a importância de um bom design de interação, vimos como podemos classi-
ficar um bom e um mau design. Tivemos a oportunidade de estudar alguns maus 
exemplos e espero que você tenha tirado dicas importantes sobre como não cair 
nestes erros.
Na sequência, entendemos na Unidade II os princípios de interação humano-com-
putador, entendemos sua estreita relação com o projeto de interfaces e pudemos 
avaliar o processo de evolução do sistema de interface desde os primórdios até os 
dias atuais. Estudamos também sobre os critérios de usabilidade e como este que-
sito pode influenciar em uma boa interação com aplicações que desenvolvemos.
Na Unidade III estudamos sobre alguns dos fatores humanos envolvidos neste pro-
cesso de interação, vimos como o ser humano interage com objetos e quais os pon-
tos cruciais desta relação, avaliamos como mensurar uma boa interação e partimos 
para o processo de coleta de requisitos.
Já na unidade IV, estudamos a importância de um bom mapeamento dos requisitos 
de sistema, entre eles os não funcionais (que impactam completamente no trabalho 
de um bom design), estudamos ferramentas e como tirar melhor proveito para um 
bom mapeamento.
Para finalizar, na unidade V, vimos como colocar a mão na massa, como podemos 
transformar estes requisitos em produtos, produtos estes que estarão aderentes às 
necessidades dos usuários e que devem seguir um modelo de desenvolvimento 
que otimize o trabalho de design, para isto estudamos alguns dos principais mode-
los de desenvolvimento e seu relacionamento com gerenciamento de projeto, de 
forma que este trabalho seja melhor controlado. Vimos como último item da nossa 
unidade como as metodologias ágeis, em seu ciclo de vida, podem apoiar sua em-
presa na construção de um design que seja realmente usual, simples e que agregue 
valor ao usuário final.
Prezado(a) aluno(a), vimos que um bom design é processo fundamental para que 
um produto possa ser aceito, independente da finalidade deste produto, seja ele um 
sistema para aplicações web, desktop ou móbile. É claro que, dependendo da plata-
forma, cuidados adicionais devem ser tomados para que seu público-alvo possa ter 
boas experiências ao usar seu produto.
Entenda que a forma como você constrói seu produto, a forma que você permite 
que seus usuários interajam com ele, tudo isto está intimamente relacionado a ex-
periências que você irá proporcionar ao seu usuário ao fazer uso de seu produto. 
É importante falarmos que estas experiências irão gerar uma enormidade de sen-
timentos em seus usuários e, o mais importante, está em suas mãos controlar que 
tipo de sentimento você deseja despertar neles.
156 - 157
CONCLUSÃO
156 - 157
Caso seu produto seja muito complicado, ele pode dificultar o aprendizado e, essa 
experiência pode acabar por gerar um bloqueio, consequentemente uma rejeição e 
até uma não aceitação do produto.
Em contrapartida, caso seu produto gere uma experiência positiva, sentimentos de 
aceitação serão gerados no usuário e, com toda certeza, você terá ganho um parcei-
ro. Enfim, entenda que está em suas mãos desenvolver produtos focados no usuário 
que sejam úteis, simples e que agreguem valor, entenda que produtos com ótima 
usabilidade estarão sempre na frente de outros e isto pode ser fator preponderante 
para seu sucesso.
Finalizando, espero que tenhamos chegado à mesma conclusão, que design não 
é questão de gosto, é na verdade uma necessidade que impacta diretamente no 
sucesso de um produto. 
REFERÊNCIAS
156 - 157156 - 157
KRUG, Steve. Não Me Faça Pensar. 2. ed. Rio de Janeiro: Alta Books, 2006.
NIELSEN, J. Usability Engineering. Cambridge, MA: Academic Press, 1993.
NIELSEN, J. Design Web Usability. Indianapolis, Indiana, USA: New Riders Publish, 
1999.
NIELSEN, J.; ROGERS, Y.; SHARP, H. Design de Interação: Além da Interação Homem- 
-Computador. Porto Alegre, RS: Artmed, 2005.
NORMAN, D. A. The Psychology of Everyday Things. New York: Basic Books, 1988.
NORMAN, Donald. O Design do Dia-a-Dia. 1. ed. Rio de Janeiro: Rocco, 2006.
PREECE, Jennifer. Design de Interação, Além da interação homem-computador. 
Porto Alegre: Bookman, 2005.
PRESSMAN, R. S. Engenharia de Software. São Paulo: Makron Books, 2011.
ROCHA, Eloisa Vieira da; BARANAUSKAS, Maria Cecília Calani. Design e Avaliação 
de Interface Humano-Computador. Campinas, SP: NIED/UNICAMP, 2003.
WILLIAMS, Robin. Design para quem não é Designer. São Paulo: Ed. Calis, 2006.