3509 PDF

DESIGN E
INTERAÇÃO
Professor Esp. Ricardo Francisco de Pierre Satin
Graduação
Unicesumar
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 de Operações
Chrystiano Mincoff
Coordenação de Sistemas
Fabrício Ricardo Lazilha
Coordenação de Polos
Reginaldo Carneiro
Coordenação de Pós-Graduação, Extensão e
Produção de Materiais
Renato Dutra
Coordenação de Graduação
Kátia Coelho
Coordenação Administrativa/Serviços
Compartilhados
Evandro Bolsoni
Gerência de Inteligência de Mercado/Digital
Bruno Jorge
Gerência de Marketing
Harrisson Brait
Supervisão do Núcleo de Produção de
Materiais
Nalva Aparecida da Rosa Moura
Supervisão de Materiais
Nádila de Almeida Toledo
Design Educacional
Fernando Henrique Mendes
Rossana Costa Giani
CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a Projeto Gráfico
Distância: Jaime de Marchi Junior
C397
José Jhonny Coelho
Design e interação / Ricardo Francisco de Pierre Satin.
Reimpressão revista e atualizada, Maringá - PR, 2014. Editoração
157 p. Thayla Daiany Guimarães Cripaldi
“Graduação - EaD”.
Revisão Textual
1. Design 2. Usabilidade 4. EaD. I. Título. Jaquelina Kutsunugi, Keren Pardini, Maria
Fernanda Canova Vasconcelos, Nayara
ISBN: 978-85-8084-560-0 Valenciano, Rhaysa Ricci Correa e Susana Inácio
Ilustração
CDD - 22 ed. 005.3
CIP - NBR 12899 - AACR/2 Thayla Daiany Guimarães Cripaldi
Ficha catalográfica elaborada pelo bibliotecário

João Vivaldo de Souza - CRB-8 - 6828
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.
autores

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)..
Apresentação
DESIGN E INTERAÇÃO
Seja bem vindo!

Olá, caro(a) aluno(a)! É com prazer que apresento a você o livro que fará parte da disciplina
de Design e 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 necessá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, para começar quero começar questionan-
do-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, garantindo simplicidade 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 componentes
de maior relevância dentro do processo de design e interação, que é a interaçã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 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 desenvolvimento 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-
Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
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

8-9
sumário
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
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
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

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
155 Conclusão
157 Referências
Conceituando Design e
I
UNIDADE
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 devido ao 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
I
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
CONCEITUANDO DESIGN E INTERAÇÃO

16 - 17
©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.
Seus produtos acabam por causar uma boa impressão para seus usuários
quando estão em uso?

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: 27 out. 2012.
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 apare-
lho celular.
Uma das experiências mais frustrantes que tenho é acessar mensagens de
voz que são deixadas 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 bastante 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.
©shutterstock

I
Celular (Voice Mail) Secretária Ele-

trônica
Saber se Tal informação não é disponibilizada facil- Sinal visual verme-
tenho uma mente, vai depender do tipo de aparelho lho piscando.
mensagem e até da operadora que estiver contratada.
pendente No meu caso, ao ligar o aparelho recebi
de avalia- um SMS informando que recebi ligações
ção. 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 meu celu-
lar um sinalizador informando que tenho
mensagem pendente de avaliação.
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 Aqui começamos um ponto importante. A primeira intera-
quanti- Cerca de um minuto para saber “quantas” ção é informar o
dade de mensagens pendentes para leitura havia. O número de mensa-
mensagens tempo para “pular” mensagens até chegar à gens pendentes. O
pendentes desejada foi enorme. Outra opção que ava- Processo de “pular”
de leitura. liei foi a de “apagar” mensagens, em que o sem ter que ouvir
tempo para executar a ação é muito maior toda mensagem é
que na execução na secretária eletrônica muito mais rápido
manual. 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.

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 trocar a sequência (pular) entre elas.
■■ Dependendo do aparelho ou operadora, pode
ficar mais difícil ainda o uso, pois os procedi-
mentos não são tão óbvios.
Se compararmos com nossa velha amiga secre-

tária eletrônica, vemos:

■■ Utiliza elementos físicos familiares que
indicam visualmente, de forma rápida,
ock
rst
aquilo que precisamos saber.
tte
hu
©s
■■ É 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.

I
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.
Fazendo uma analogia com a medicina, é importante que sejamos especialistas
em uma área, que tenhamos total conhecimento em um determinado assunto
como um médico cardiologista, entretanto, é relevante que tenhamos um conhe-
cimento geral de outras áreas da medicina para que possamos exercer 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.
Para o sucesso em design de

22 - 23
interação, desde o início é conhecido que se trata de uma área multidisciplinar.

Preece (2005, p.28) afirma: “A importância de se
entender como os usuários agem e reagem
a situações e como se comunicam e intera-
gem acarretou 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
Reprodução proibida. art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
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, mui-
tos produtos são criados sem avaliar a pessoa
que irá usar este. Nos primórdios da compu-
tação, o mais importante era o hardware, o
meio pelo qual a interaçã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 engenheiros que pro-
jetavam estes equipamentos). Sendo assim, muitas ©shutterstock
vezes o que víamos era algo muito parecido com um
painel repleto de chaves e luzes piscando que, para qualquer usuário nos dias de
hoje, daria arrepios, mas para eles que haviam projetado e interagiam com o “sis-
tema” tinha total sentido, significado e atendia à sua necessidade de interação.
Apenas no final 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
Histórico do design de Interação

I
© Metamorfose Digital
avaliação e na implementação de sistemas computacionais interativos para uso

humano e com o estudo de fenômenos que afetam este grupo.
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 humanos, ergo-
nomia, 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.
©shutterstock

Reprodução proibida. Art. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998. 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 Quando falamos de ciência da computação, estamos falando
Computação 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 A psicologia é parte importante no processo de Design e Inte-
Cognitiva 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 Seu principal foco é estudar o comportamento humano
Social 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.

I
Elemento Influência
Fatores Huma- Maximizar a segurança, eficiência, confiabilidade e desempe-
nos / Ergono- nho do usuário, tornando as tarefas mais fáceis e aumentar o
mia 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 A engenharia de software é peça fundamental na construção
Software 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)
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?

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áficos
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 (final da dé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-
figurações e aumentar as suas capacidades de acordo com a necessidade, pagando
relativamente pouco por essas facilidades.
MICROPROCESSADORES: O INíCIO DOS COMPuTADORES PESSOAIS

Enfim 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
considere 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 computa-
dor 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 alguns 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: 11 nov. 2012.
I
©shutterstock
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étodos novos 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

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, ©shutterstock
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 ©shutterstock
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.
I
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.
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
Quais recursos de sua empresa poderiam ser melhor aproveitados para

construir uma equipe multidisciplinar gerenciável!

36 - 37
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 produto. 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 consumi-
dores 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
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?
I
compra do produto, contudo, muitos deles ficaram frustrados pelo fato de não
conseguirem finalizar suas compras.
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.
Novo formato de interação, novo formato de comunicação projetado pela
Google– Google Glasses.
<https://www.youtube.com/watch?v=JSnB06um5r4>.
Visão de futuro da Microsoft para nosso formato de interação – como será o futuro!
<http://www.youtube.com/watch?v=HFERaS8mGTg>.

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 gerenciamento usar 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.
ENTENDENDO MAIS SOBRE
II
UNIDADE
CRITÉRIOS DE USABILIDADE
■■ 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
■■ 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
II
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
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.
Interface/Interação Humano-Computador (IHC)

II
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.

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.

©shutterstock
Que recursos você tem usado para facilitar a compreensão do usuário para
usar seu sistema de forma mais eficiente?
Interface/Interação Humano-Computador (IHC)

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: 11 nov. 2012.
II
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”,

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
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?

II
objetivo tornar o aprendizado dos usuários mais fácil.

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 dificilmente você 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.
Afinal de contas, o objetivo da IHC é produzir sistemas que saiam realmente
Suas aplicações estão preparadas para trabalhar com o Windows 8?

56 - 57
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.
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?

II
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?
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 quanto 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?”.

II
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
assim a 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

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ó-
k c
gio analógico. Mesmo que você nunca tenha

ttersto
©shu
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
©sh
“é ali” que você tem que interagir).

utte
rs
tock

II
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

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- ©shutterstock
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.

II
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

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.
©shutterstock
Usabilidade
II
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 medicamente cujo
gosto não lhe agradava, uma vez que este é o que lhe curaria.

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-
Usabilidade
II
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!

68 - 69
em sua classificação de 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.
Quanto tempo leva para que seus usuários consigam aprender e utilizar seu
sistema?
Usabilidade
II
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
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,
Usabilidade na Web
II
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.

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 o interesse 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.
Usabilidade na Web
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?question=0>. Acesso
em: 28 out. 2012.
74 - 75
Evolução do formato de interação com o Windows, sistema operacional mais

popular.
<https://www.youtube.com/watch?v=8YHQG01Hfts>.
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>.
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.
III
ENTENDENDO MAIS SOBRE
UNIDADE
OS FATORES HUMANOS
ENVOLVIDOS
■■ 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 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
III
©shutterstock
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:

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 Fonte: Baseado em Rocha (2003)
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).
A Psicologia da Interface Humano-Computador

III
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.
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

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

III
de leitura será de 261 palavras

por minuto. Se a cada fixaçã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 ©shutterstock
fator que pode impactar este
tempo de leitura é a complexidade do assunto que está sendo proposto, a dificul-
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?

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.
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

III
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 ©shutterstock

86 - 87
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?
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. ©shutterstock
Podemos dizer 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.

III
Nossos sistemas precisam apresentar opções que auxiliem, rapidamente,

nosso cognitivo a recuperar uma informação já armazenada!
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,
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!

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 significada.
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
Mecanismos da Percepção Humana

III
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
©shutterstock

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étodos que exigem muito tempo de interação estão mais propensos
O Modelo Goms
III
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

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
©shutterstock
Modelos Mentais
III
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!

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 construir um 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
Modelos mentais apoiam nossa antecipação frente a problemas!
Modelos Mentais
III
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.
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: 11
nov. 2012.
98 - 99
Entenda mais sobre modelos mentais:

<https://www.youtube.com/watch?v=PdDOwWBxxuA>.
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.
CONSIDERAÇÕES FINAIS
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?
IV
IDENTIFICANDO AS NECESSIDADES
UNIDADE
E ESTABELECENDO OS REQUISITOS
■■ 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
■■ 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
conseguir extrair 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
IV
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?
©shutterstock
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 “identificação de necessidades”.
A partir daí, nosso segundo objetivo consiste em produzir, a partir das
necessidades identificadas, 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
IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS REQUISITOS

104 - 105
©shutterstock
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.
©shutterstock
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.
O Quê, Quem, Quando, Onde, Como e Por Quê?

IV
©shutterstock
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.
©shutterstock
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.

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-
©shutterstock
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.
Fonte: PMSurvey 2012
O Quê, Quem, Quando, Onde, Como e Por Quê?

IV
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,
©shutterstock

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

IV
©shutterstock
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

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.
©shutterstock
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 simplificar
o processo de desenvolvimento de software.
Outro ponto refere-se ao armazenamento
das informações. Muitas empresas têm um certo
©shutterstock
o Que são Requisitos?

IV
“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
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.

IV
■■ 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 ©shutterstock
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

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.
©shutterstock
■■ 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.
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?
IV
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

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ções que 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
Como Coletá-Los?
IV
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

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, segue o comparativo abaixo
adaptado de Preece (2005).
Como Coletá-Los?
IV
Técnica Boa para Tipo de Vantagens Desvantagens

dados
Questionários Responder Dados Pode atingir O design é crucial. O
a questões quanti- várias pessoas Índice de resposta
específi- tativos e com poucos pode ser baixo, as res-
cas. qualita- recursos. postas podem não ser
tivos. o que você deseja.
Entrevista Explorar Alguns O entrevista- Requer tempo.
questões. dados dor pode guiar Ambientes artificiais
quanti- o entrevistado podem intimidar o
tativos, se necessário. entrevistado.
mas Encoraja o
mais contato entre
qualita- desenvolvedo-
tivos. res e usuários.
Grupo de es- Coletar Alguns Ressalta áreas Possibilidade de domi-
tudos específi- vários dados de consenso e narem certos tipos de
cos/oficinas pontos de quanti- conflito. Enco- personalidade.
vista. tativos, raja o contato
mas entre desen-
mais volvedores e
qualita- usuários.
tivos.
Observação Entender Qualita- Observar o Requer muito tempo.
natural o contexto tivo. trabalho real Grandes quantidades
da ativi- oferece perde dados.
dade do cepções que
usuário. outras técnicas
não podem
oferecer.
Estudo de do- Aprender Qualita- Não compro- O trabalho diário será
cumentação sobre tivo. mete o tempo diferente dos proce-
procedi- dos usuários, dimentos documen-
mentos, exceto quando tados.
regula- utilizado recur-
mentações so de catalo-
e padrões. gação.

120 - 121
Técnica Boa para Tipo de Vantagens Desvantagens

dados
Log de dados Enten- Quanti- Não gera Requer desenvolvi-
der os tativo. impacto ao mento.
recursos usuário final.
realmente Identificação
usados dos reais pon-
pelos usu- tos de atenção
ários. na implemen-
tação.
Engenharia Identificar Quanti- Conhecimento Requer grande envol-
reversa os recur- tativo. aprofundado vimento técnico.

sos imple- da estrutura
mentados do sistema
que não atual.
surgiram
em outras
formas de
cataloga-
ção.
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

IV
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 ©shutterstock

122 - 123
O foco da construção de cenários está nas tarefas do usuário!
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

IV
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 de Elaboraçã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
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: 11 nov. 2012.
126 - 127
Entenda sobre engenharia de requisitos.

<https://www.youtube.com/watch?v=t0so6Nagjns>.
Entenda mas sobre análise de requisitos.

<https://www.youtube.com/watch?v=2Lh-JH3SfE4>.
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 preju-
dicar o estabelecimento de um design novo?
3. Quais os passos que precisamos dar para uma boa coleta/identificação
dos requisitos?
V
COLOCANDO TUDO ISTO
UNIDADE
PARA RODAR
■■ 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
■■ 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
V
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-

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.
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.
©shutterstock
Entendendo sua Abordagem Junto aos Modelos de PRodução de Software

V
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.

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 quando o 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.
©shutterstock

V
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.
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.

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.

V
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).
©shutterstock
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

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 modelos que estudamos acima 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 qualquer projeto (inclusive de software),
temos os seguintes itens:
■■ Integração
Esta área cuida para que todas as outras

oito áreas de conhecimento abaixo estejam
sendo realizadas. Um dos maiores cuida-
dos de um gerente de projeto é garantir a
integração, ou seja, garantir que tudo esteja
©shutterstock
acontecendo 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
projeto. Esta é a área de conhecimento que trabalha firme-
mente com os modelos de desenvolvimento de software que
vimos no tópico anterior.
©shutterstock
Entendendo Design como Parte do Escopo de um Projeto

V
■■ Tempo
Está aqui o conjunto de conhecimento

para procurar prover ao projeto ferramentas
que podem ajudar na estimativa e controle
©shutterstock
dos projetos.
■■ Custo
Temos aqui um conjunto de ferramentas e técnicas que
apoiam o controle dos custos do projeto.
■■ Qualidade ©shutterstock
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
©shutterstock
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
os fundamentos ensinados neste
livro!
©shutterstock

140 - 141
Desenvolver sistemas não é só levantar o que o cliente quer e ir programan-

do e validando?
■■ 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 ©shutterstock
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 mui-
tos deles têm impacto direto no design de nossas aplicações.
©shutterstock
■■ 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
©shutterstock
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
tópico deste livro que uma das principais razões para o insucesso de projetos é
um mau gerenciamento do escopo.
Entendendo Design como Parte do Escopo de um Projeto

V
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.

142 - 143
©shutterstock
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
Entendendo seu Benefício no Uso Conjunto com Metodologias Ágeis

V
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>.

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
Entendendo seu Benefício no Uso Conjunto com Metodologias Ágeis

V
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: 11 nov. 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:
11 nov. 2012.
V
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?
Construindo resultados com gerenciamento de projetos – Ricardo Vargas.

<https://www.youtube.com/watch?v=xtCtKirpKwg&feature=relmfu>.
Metodologias ágeis
<https://www.youtube.com/watch?v=9xqqvwaua7w>.
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ção pode 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.

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
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.
Conclusão
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.
156 - 157
Referências
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.

3509 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

3509 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

DESIGN E

Professor Esp. Ricardo Francisco de Pierre Satin

NEAD - Núcleo de Educação a Distância

Ficha catalográfica elaborada pelo bibliotecário

Professor Esp. Ricardo Francisco de Pierre Satin

Seja bem vindo!

Asseguro-lhe que um dos itens de maior relevância no desenvolvimento de um novo

possa produzir sistemas com boa usabilidade, seja no desenvolvimento de soluções

Conceituando Design e Interação

17 Um Bom e um Mau Design

21 Histórico do Design de Interação

ENTENDENDO MAIS SOBRE CRITÉRIOS DE USABILIDADE

44 Interface/Interação Humano-Computador (IHC)

54 Interação Humano-Computador e Interface 

59 Como as Pessoas Interagem Com Objetos?

ENTENDENDO MAIS SOBRE OS FATORES HUMANOS ENVOLVIDOS

80 A Psicologia da Interface Humano-Computador

89 Mecanismos da Percepção Humana

IDENTIFICANDO AS NECESSIDADES E ESTABELECENDO OS

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

COLOCANDO TUDO ISTO PARA RODAR

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

Caro(a) aluno(a), já nesta primeira unidade você estudará um assunto muito

ramentas de editoração de textos ou planilha, controle remoto (aqui você pode

Lembro-me de quando minha mãe comprou seu primeiro multiprocessador

CONCEITUANDO DESIGN E INTERAÇÃO

Um Bom e um Mau Design

Um Bom e um Mau Design

Por Bruno Romani

Baseado nisto, você pode me perguntar: Mas qual a preocupação central do

Um Bom e um Mau Design

Celular (Voice Mail) Secretária Ele-

CONCEITUANDO DESIGN E INTERAÇÃO

■■ Ineficiente, exige muitos passos para TAREFAS BÁSICAS.

Se compararmos com nossa velha amiga secre-

tária eletrônica, vemos:

Histórico do Design de Interação

Histórico do Design de Interação

CONCEITUANDO DESIGN E INTERAÇÃO

interação, desde o início é conhecido que se trata de uma área multidisciplinar.

de forma distinta a um mesmo estímulo. Ou

Histórico do design de Interação

avaliação e na implementação de sistemas computacionais interativos para uso

CONCEITUANDO DESIGN E INTERAÇÃO

Figura 1 – Mapa mental sobre os elementos envolvidos no design de interação

A seguir, um breve resumo das áreas mais relevantes descritas na figura 1.

Histórico do Design de Interação

CONCEITUANDO DESIGN E INTERAÇÃO

A evolução dos computadores

Por Renan Hamann

As Gigantes Válvulas da Primeira Geração

Transistores e a Redução dos Computadores

Miniaturização e Circuitos Integrados

MICROPROCESSADORES: O INíCIO DOS COMPuTADORES PESSOAIS

E os ciclos tornam-se clocks

Notebooks: a quarta geração portátil

17 Um Bom e um Mau Design

21 Histórico do Design de Interação

44 Interface/Interação Humano-Computador (IHC)

54 Interação Humano-Computador e Interface

59 Como as Pessoas Interagem Com Objetos?

80 A Psicologia da Interface Humano-Computador

89 Mecanismos da Percepção Humana

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

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