Você está na página 1de 417

Interao humano-computador

Simone Diniz Junqueira Barbosa

Bruno Santana da Silva


Obrigado por adquirir este e-book
Esta obra acompanhada de contedo complementar. Para acess-lo, encaminhe a
confirmao de compra deste e-book para pin@elsevier.com.br, solicitando seu cdigo de
acesso.
Sumrio

Capa

Folha de rosto

Obrigado por adquirir este e-book

Cadastro

Copyright

Dedicatria

Agradecimentos

Prefcio

1. Introduo
Objetivos Do Captulo

1.1 O Impacto Das Tecnologias De Informao E Comunicao No Cotidiano

1.2 Diferentes Vises Sobre A Construo De Sistemas Interativos

1.3 Objetos De Estudo Em IHC

1.4 IHC Como rea Multidisciplinar

1.5 Benefcios De IHC

Atividades

2. Conceitos bsicos
Objetivos Do Captulo

2.1 Interface, Interao E Affordance

2.2 Qualidade Em IHC


Atividades

3. Abordagens tericas em IHC


Objetivos Do Captulo

3.1 Introduo

3.2 Psicologia Experimental

3.3 Psicologia Cognitiva Aplicada

3.3.3 Percepo De Cores

3.4 Engenharia Cognitiva

3.5 Abordagens Etnometodolgicas

3.6 Teoria Da Atividade

3.7 Cognio Distribuda

3.8 Engenharia Semitica

Atividades

4. Processos de Design de IHC


Objetivos Do Captulo

4.1 O Que Design?

4.2 Perspectivas De Design

4.3 Processos De Processos De Design De IHC

4.4 Integrao Das Atividades De IHC Com Engenharia De Software

4.5 Mtodos geis E IHC

Atividades

5. Identificao de Necessidades dos Usurios e Requisitos de IHC


Objetivos Do Captulo

5.1 Introduo

5.2 Que Dados Coletar?

5.3 De Quem Coletar Dados?

5.4 Aspectos ticos De Pesquisas Envolvendo Pessoas

5.5 Como Coletar Dados Dos Usurios?

Atividades
6. Organizao do Espao de Problema
Objetivos Do Captulo

6.1 Perfil De Usurio

6.2 Personas

6.3 Cenrios

6.4 Anlise De Tarefas

Atividades

7. Design de IHC
Objetivos Do Captulo

7.1 Introduo

7.2 Cenrios De Interao

7.3 Design Centrado Na Comunicao

7.4 Design Da Interface

7.5 Projeto Do Sistema De Ajuda

7.6 Desafios De Design De Sistemas Adaptveis E Adaptativos

Atividades

8. Princpios e Diretrizes para o Design de IHC


Objetivos Do Captulo

8.1 Introduo

8.2 Princpios E Diretrizes Gerais

8.3 Padres De Design De IHC

8.4 Guias De Estilo

Atividades

9. Planejamento da Avaliao de IHC


Objetivos Do Captulo

9.1 Por Que Avaliar?

9.2 O Que Avaliar?

9.3 Quando Avaliar O Uso De Um Sistema?

9.4 Onde Coletar Dados Sobre Experincias De Uso?


9.5 Que Tipos De Dados Coletar E Produzir?

9.6 Qual Tipo De Mtodo De Avaliao Escolher?

9.7 Como Avaliar?

9.8 O Framework DECIDE

Atividades

10. Mtodos de Avaliao de IHC


Objetivos Do Captulo

10.1 Avaliao De IHC Atravs De Inspeo

10.2 Avaliao De IHC Atravs De Observao

10.3 Resumo Comparativo Dos Mtodos De Avaliao

Atividades

Referncias Bibliogrficas

ndice remissivo
Cadastro

Preencha a ficha de cadastro no final deste livro e


receba gratuitamente informaes sobre os lanamentos
e as promoes da Elsevier.

Consulte tambm nosso catlogo completo, ltimos


lanamentos em www.elsevier.com.br
Copyright
2010, Elsevier Editora Ltda.

Todos os direitos reservados e protegidos pela Lei no 9.610, de 19/02/1998.


Nenhuma parte deste livro, sem autorizao prvia por escrito da editora, poder ser
reproduzida ou transmitida sejam quais forem os meios empregados: eletrnicos,
mecnicos, fotogrficos, gravao ou quaisquer outros.

Copidesque: Adriana Arajo Kramer


Reviso: Marco Antnio Corra

Elsevier Editora Ltda.


Conhecimento sem Fronteiras
Rua Sete de Setembro, 111 16o andar
20050-006 Centro Rio de Janeiro RJ Brasil

Rua Quintana, 753 8o andar


04569-011 Brooklin So Paulo SP

Servio de Atendimento ao Cliente


0800-0265340
sac@elsevier.com.br

ISBN 978-85-352-3418-3
ISBN (verso eletrnica): 978-85-352-1120-7

Nota: Muito zelo e tcnica foram empregados na edio desta obra. No entanto, podem
ocorrer erros de digitao, impresso ou dvida conceitual. Em qualquer das hipteses,
solicitamos a comunicao ao nosso Servio de Atendimento ao Cliente, para que
possamos esclarecer ou encaminhar a questo.
Nem a editora nem o autor assumem qualquer responsabilidade por eventuais danos ou
perdas a pessoas ou bens, originados do uso desta publicao.

CIP-BRASIL. CATALOGAO-NA-FONTE
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ

B212i

Barbosa, Simone Diniz Junqueira


Interao humano-computador / Simone Diniz Junqueira Barbosa, Bruno
Santana da Silva. Rio de Janeiro: Elsevier, 2010.
il. - (Srie SBC, Sociedade Brasileira de Computao)

Inclui bibliografia
ISBN 978-85-352-3418-3

1. Interao homem-mquina. 2. Informtica - Aspectos sociais. 3.


Tecnologia - Aspectos sociais. 4. Comunicao e tecnologia. 5. Tecnologia da
informao. I. Barbosa, Simone D. J. (Simone Diniz Junqueira). II.
Sociedade Brasileira de Computao. III. Ttulo. IV. Srie.

10-2633. CDD: 004.019


CDU: 004.5
Dedicatria

Aos meus filhos, Gabriel e Eduardo.


S. D. J. Barbosa

minha famlia.
B. S. Da Silva
Agradecimentos
Muitas pessoas contriburam para tornar este livro uma realidade. Somos afortunados
por termos ao nosso redor pesquisadores e profissionais altamente qualificados, alunos
interessados e motivados, amigos e familiares queridos.
Este livro no existiria se no fosse nossa eterna professora e amiga, Clarisse
Sieckenius de Souza, que nos despertou o interesse pela rea de IHC e sempre nos apoia
e nos motiva a aprender mais e a contribuir mais para a rea. Interao Humano
Computador no Brasil no seria a mesma sem seu pioneirismo e seriedade.
Somos gratos a diversas pessoas com quem colaboramos ao longo de todos os nossos
anos de atuao na rea: a Carla Faria Leito, Elton Jos Silva, Jair Cavalcanti Leite,
Milene Selbach Silveira, Raquel Oliveira Prates, Srgio Roberto Pereira da Silva e todos
aqueles que passaram pelo Semiotic Engineering Research Group (SERG). Alunos que
deveriam aprender conosco muito nos ensinaram. Gostaramos de agradecer aos
egressos do SERG e do Departamento de Informtica da PUC-Rio: Adle, Ana Carolina,
Andr Luiz, Andria, Ariane, Clarissa, Gilda, Gustavo, Hildebrando, Jos Eurico,
Luciana, Mara, Marcus, Otvio, Rafael, Rodrigo, Sandra, Slvia, Thas, Ugo, Vincius e
Viviane.
Agradecemos ao Departamento de Informtica da PUC-Rio, que sempre apoiou a rea
de IHC, firmando seu pioneirismo ao oferecer vrias disciplinas de graduao e ps-
graduao h mais de uma dcada e ao reconhecer IHC como uma rea de pesquisa
legtima, ainda enquanto a rea era pouco difundida no pas.
Nossos pais, Marleny, Carlos, Llia e Oriovaldo, so grandes responsveis pelos nossos
mritos e por tudo o que alcanamos. Durante os longos meses de pesquisa e redao
deste livro, nossos familiares e amigos nos apoiaram incondicionalmente. A todo tempo
sentimos sua carinhosa presena, apesar do isolamento e da privao do convvio que
esse tipo de empreitada exige dos autores. Lus Fernando, Gabriel, Eduardo, Kamila: este
livro tambm de vocs.
Finalmente, gostaramos de agradecer novamente a Clarisse Sieckenius de Souza e a
Vincius Costa Villas Bas Segura pela reviso de partes deste livro, a Antonio Luz
Furtado, pela sua colaborao no design da capa, e equipe editorial da Campus/Elsevier,
pela sua dedicao e apoio ao longo de toda essa jornada.
S.D.J. Barbosa & B.S. da Silva
Rio de Janeiro, junho de 2010
Prefcio
Em 2006, um Grupo de Trabalho se reuniu no Simpsio Brasileiro sobre Fatores
Humanos em Sistemas Computacionais, IHC 2006, em Natal, para discutir o currculo de
Interao HumanoComputador (IHC) nas universidades brasileiras (Silveira e Prates,
2007). Visando apoiar aulas de graduao de IHC em cursos de Cincia da Computao,
Sistemas de Informao e Engenharia de Computao, tomamos como base o currculo
recomendado pelo GT para selecionar o contedo includo neste livro, apoiados pela
nossa prpria experincia em lecionar disciplinas de IHC por diversos semestres.
Sabemos que no vivel abordar todos os aspectos de uma rea de conhecimento
ampla e multidisciplinar como IHC em um nico livro. Alm disso, reconhecemos que
nem todas as universidades incluem mais de uma disciplina de IHC em suas grades
curriculares. Objetivamos ento elaborar um livro-texto como material didtico de apoio
a um curso de introduo IHC com a durao de um semestre.
Alm do apoio a aulas de graduao, inclumos material de cunho prtico, a fim de que
o livro possa ser utilizado tambm por profissionais que precisem incorporar atividades
de IHC em sua prtica de trabalho.
Os autores podem ser contatados pelo e-mail: livroihc@gmail.com.
1

Introduo
Objetivos do Captulo
Discutir a importncia da rea de Interao Humano-Computador (IHC) considerando
o impacto das tecnologias de informao e comunicao no nosso cotidiano.
Apresentar diferentes vises da Computao sobre a construo de sistemas
computacionais interativos.
Descrever os objetos de estudo de IHC.
Discutir a importncia da multidisciplinaridade em IHC.
Apresentar alguns benefcios proporcionados por incorporar prticas de IHC no
desenvolvimento de sistemas computacionais interativos.
As tecnologias de informao e comunicao (TICs) oferecem maneiras eficientes de
processar e trocar informaes com diversos objetivos. Elas permitem criar sistemas
computacionais embutidos nos mais diferentes dispositivos eletrnicos, que combinam
poder computacional e meios de comunicao (telefonia, rdio, TV, Internet etc.). Neste
livro, nos concentramos nos sistemas computacionais interativos que compem as TICs,
isto , sistemas computacionais compostos por hardware, software e meios de
comunicao desenvolvidos para interagirem com pessoas.
1.1 O Impacto das Tecnologias de Informao e
Comunicao no Cotidiano
As TICs esto se desenvolvendo em ritmo acelerado, e cada vez mais fazem parte das
nossas vidas pessoais e profissionais. A evoluo e a disseminao dessas tecnologias
alcanaram um nvel em que difcil encontrar pessoas que ainda no tiveram direta ou
indiretamente contato com elas, independente de classe social, do nvel de escolaridade e
do local onde moram. A mdia tem apresentado vrios exemplos de indgenas brasileiros,
comunidades distantes dos grandes centros e moradores de comunidades de baixa renda
nas grandes cidades com acesso Internet onde moram.
Voc j parou para pensar sobre como as TICs esto presentes na sua vida e na nossa
sociedade? Em que reas elas esto presentes? Em que quantidade? Que importncia elas
adquiriram? O que significa ter tanta tecnologia na vida das pessoas? Quais so as
consequncias disso para as pessoas que utilizam e para as pessoas que desenvolvem
essas tecnologias? Vamos comear analisando algumas reas que empregam essas
tecnologias atualmente.
Faz tempo que somente computadores pessoais ou de grande porte (como mainframes
e servidores) eram capazes de processar informaes. J possvel encontrar vrios
produtos eletrnicos inteligentes, tais como mquinas fotogrficas que se configuram
automaticamente de acordo com a luminosidade do ambiente e que so capazes de
reconhecer faces e expresses humanas como o sorriso; mquinas de lavar louas que
detectam o nvel de sujeira na gua e indicam o melhor programa para a lavagem; ou
ainda condicionadores de ar que regulam automaticamente a temperatura, velocidade e
direo da ventilao de acordo com a temperatura ambiente.
As TICs esto revolucionando a rea de entretenimento. Jogos eletrnicos esto
ficando mais sofisticados, com enredos mais elaborados, melhores grficos e com maior
aplicao de inteligncia artificial. Esto surgindo novos dispositivos de interface com o
jogador: controles sem fio e com sensor de movimento (como os controles do Wii), e
cmeras que detectam os movimentos do jogador (projeto Natal para o Xbox). Alm
disso, jogos em rede permitem a interao entre pessoas como parte do entretenimento.
A TV digital interativa (TVDI) tambm est mudando a forma de produzir e consumir
contedos na TV. Na TV analgica, a emissora era capaz de transmitir apenas um
contedo por vez para todos os telespectadores, e eles normalmente recebiam o
contedo numa atitude passiva, sentados no sof de casa. A tecnologia por trs da TVDI
permite emissora enviar mais de um contedo simultaneamente. Dessa forma, cabe ao
telespectador escolher a qual desses contedos enviados ele ir assistir, no dispositivo e
local desejados. A TVDI tambm permite ao usurio interagir com a emissora numa
atitude mais ativa, por exemplo, emitindo alguma opinio ou realizando alguma votao
(Soares e Barbosa, 2009). E ainda temos a rdio digital, que est comeando a ser
discutida no Brasil.
As TICs tambm transformaram a noo de distncia e tempo na comunicao entre
pessoas. E-mail, programas para troca de mensagens, como MSN e GTalk, e comunidades
virtuais, como Orkut e Facebook, permitem que pessoas espalhadas geograficamente
possam se comunicar usando texto, vdeo e som, de forma sncrona ou assncrona. Essas
tecnologias permitem trocar rapidamente arquivos de diversos formatos, como msica,
fotos, vdeos etc. O prprio telefone celular oferece um canal de comunicao individual
disponvel em praticamente qualquer lugar do mundo. Hoje, um grande nmero de
pessoas carrega consigo um aparelho eletrnico que integra telefonia, cmera digital,
acesso Internet, jogos, reprodutor de msica e de vdeos, GPS e TVDI.
O acesso a informao vem sofrendo grandes transformaes com a evoluo
tecnolgica. Na educao, por exemplo, um professor no pode mais considerar que ele e
os livros so as nicas fontes de conhecimento disponveis aos alunos. A Internet
disponibiliza uma enorme quantidade de informao que os alunos podem acessar
quando e onde desejarem. Diferentemente de outras mdias, como papel e quadronegro,
as TICs permitem criar materiais dinmicos e interativos que podem favorecer o
aprendizado, como vdeos, simulao de fenmenos naturais, explorao de realidades
virtuais, comunicao e colaborao entre alunos e professores com apoio
computacional, e assim por diante. Se unirmos a oferta de contedo didtico em meio
computacional a uma comunidade virtual dispersa geograficamente, podemos explorar o
ensino a distncia utilizando as TICs. J existem diversos cursos a distncia disponveis
no Brasil e no mundo, inclusive cursos de nvel superior. A Organizao das Naes
Unidas (ONU) acaba de criar uma universidade on-line de ensino a distncia em escala
mundial: a University of the People.1
No campo da poltica, as TICs tambm esto mudando a relao entre eleitores e
polticos, sejam ainda candidatos ou aqueles que tenham assumido algum cargo pblico.
Antes, a comunicao em larga escala dos polticos era geralmente restrita propaganda
poltica obrigatria com data marcada e horrio limitado na TV e no rdio, que so canais
de comunicao unidirecionais. A Internet oferece novos canais de comunicao
bidirecionais, como Web sites dos partidos, blogs dos polticos e dos eleitores, vdeos no
YouTube, dentre outros. Agora, um grande nmero de eleitores dispersos
geograficamente pode consultar, opinar e questionar na Internet as propostas e ideias
dos polticos quando e onde desejarem. Vrios polticos no Brasil e no mundo mantm
contato com os eleitores pela Internet, como, por exemplo, alguns prefeitos de grandes
cidades brasileiras. O prprio ato de votar nos representantes brasileiros mudou
drasticamente com a utilizao das urnas eletrnicas. Hoje o resultado de eleies
federais pode ser apurado em horas.
Muitas relaes do Estado com a populao so atualmente mediadas pelas TICs, o que
tem sido chamado de governo eletrnico (e-gov). No Brasil, matrculas em escolas
pblicas j so feitas exclusivamente pela Internet ou por telefone; a maior parte das
declaraes de imposto de renda entregue pela Internet; e j possvel consultar
informaes sobre processos jurdicos tambm pela rede. Algumas prefeituras fazem
uso de sistemas de informaes geogrficas na gesto de seus municpios, como o uso de
imagens de satlites para verificar construes irregulares, para analisar o fluxo de
veculos e reestruturar o trfego nas vias.
As TICs esto afetando o comrcio e a nossa relao com dinheiro e bancos. Boa parte
das transaes financeiras j no manipula mais papel-moeda. Cartes e operaes on-
line esto ganhando cada vez mais espao no nosso cotidiano. Muitas operaes
bancrias podem ser realizadas atravs de praticamente qualquer dispositivo com acesso
Internet, onde e quando desejarmos, sem a necessidade de ir a uma agncia bancria. O
comrcio tambm ganhou verso on-line. Sem sair de casa, as TICs nos permitem
comprar o que desejarmos, comparar preos de produtos em diferentes lojas on-line com
apoio computacional, e obter mais informaes sobre os produtos desejados direto com
os fabricantes, e ter acesso s opinies e experincias de uso de outras pessoas sobre os
produtos desejados.
Grande parte do transporte atual controlada com ajuda das TICs: controle de trfego
areo, metr, trens urbanos, o fluxo de nibus em cada linha, e assim por diante. At o
prprio carro possui muita tecnologia embutida para evitar acidentes, usar o combustvel
de forma eficiente e ajudar a estacionar, por exemplo. As TICs j so capazes de conduzir
veculos sem ajuda do ser humano no modo de piloto automtico, em avies e carros.
Tambm podem ajudar a monitorar a emisso de gases poluentes, contribuindo para a
preservao do meioambiente.
Na rea da sade, as TICs vm se tornando fundamentais para o diagnstico e
tratamento de doenas. Muitos aparelhos utilizados em Medicina so controlados com
ajuda da computao, tais como aparelhos de ressonncia magntica, de tomografia
computadorizada e de radioterapia. Existem robs que realizam cirurgias sendo
manipulados por mdicos muito distantes do paciente. J existe uma cpsula
programada para liberar remdio dentro do corpo humano no local, na quantidade e no
fluxo certos para tratar doenas de forma mais eficiente.2 Alm disso, as TICs permitem
que o histrico de sade de um paciente esteja on-line disposio dos mdicos,
incluindo resultados de exames que acabaram de ficar prontos em um laboratrio
distante. E pesquisas em computao grfica e realidade aumentada vm contribuindo
com novas formas de visualizar os resultados dos exames.
Ao analisarmos esses exemplos de diversas reas, percebemos que as TICs esto
ocupando espao importante nas nossas vidas. Quando as incorporamos no nosso
cotidiano, no estamos apenas trocando de instrumentos, como quem troca de garfo,
caneta ou rgua. As modificaes so mais profundas e significativas, pois modificam
tambm a nossa forma de trabalhar, de prestarmos servios, de nos relacionarmos com
outras pessoas e instituies, de ensinarmos e aprendermos, de participarmos da
poltica, de lidarmos com o dinheiro, de cuidarmos da sade, e assim por diante.
importante reconhecermos que as TICs esto modificando no apenas o que se faz e como
se faz, mas tambm quem as faz, quando, onde e at mesmo por qu.
Tomando como exemplo a transio da votao em cdula de papel para a votao na
urna eletrnica, a mudana foi alm da forma como o eleitor manifesta seu voto. Quantas
pessoas (quem) sabem votar nulo (o que) na urna eletrnica? Ser que a motivao para o
voto nulo (por que votar nulo ou no) foi modificada na transio da cdula de papel para a
urna eletrnica (Figura 1.1)?
FIGURA 1.1 Urna eletrnica.3

Boa parte das pessoas que no sabe votar nulo na urna eletrnica sabia votar nulo na
cdula de papel. No existe um boto exclusivo para votar nulo, semelhante ao que existe
para votar em branco. Para votar nulo, o eleitor precisa digitar um nmero de candidato
invlido e confirmar o seu voto. Observamos que a urna eletrnica foi projetada,
intencionalmente ou no, para desestimular o voto nulo, dificultando uma atitude de
protesto dos eleitores. Na cdula de papel, os eleitores podiam escrever o que quisessem,
at votar no macaco Tio.4
H outros exemplos de como a introduo de TICs afeta o comportamento humano. Os
japoneses no costumam sorrir muito como os brasileiros. Essa caracterstica cultural faz
diferena no atendimento ao pblico. Para se tornarem mais simpticos (por que), os
funcionrios do metr de Tquio (quem) esto sendo convidados a exercitar o sorriso (o
que) diante de um sistema interativo capaz de identificar expresses faciais. O exerccio
realizado antes do expediente (quando) como uma espcie de jogo, no qual quem sorrir
melhor ganha mais pontos (como). Esse um exemplo claro de como as TICs esto sendo
utilizadas para intervir no comportamento das pessoas de forma bastante significativa,
pois atuam sobre seu jeito de ser e sua cultura. Qualquer interveno na cultura, nas
habilidades e nos conhecimentos das pessoas deve ser realizada com cuidado e respeito
s individualidades de cada uma, no importa quanta inovao e tecnologia estejam
sendo utilizadas.
As TICs tambm vm afetando a nossa vida pessoal. Por exemplo, Joo possui um
smartphone que agrega um canal de comunicao de um telefone celular com alguns
recursos computacionais de um notebook, em um dispositivo que cabe no bolso.
Enquanto ele faz sua caminhada matinal (onde e quando), ele est acessvel (por que)
atravs de seu smartphone para receber notcias de casa (o que), como a notcia de que ele
precisa comprar algo antes de voltar ou que seu filho est passando mal. Entretanto, esse
mesmo dispositivo permite receber telefonemas sobre algo do trabalho no meio da
caminhada, trazendo problemas para um momento de exerccio e relaxamento. Nem
sempre o que um sistema interativo permite fazer desejvel e bom. Por isso, tambm
importante pensarmos no mau uso da tecnologia. Por exemplo, se Joo souber quem est
ligando antes de atender a ligao, ele pode escolher atender ou no. Se for um colega de
trabalho que costuma ser inconveniente, ele pode ser ignorado naquele momento. Se for
um colega que s liga antes do expediente caso seja um assunto srio e urgente, Joo
pode escolher atender a ligao. Ali mesmo, ele tambm pode consultar e reajustar a sua
agenda da semana no smartphone e enviar alguns e-mails para comear a resolver o
problema urgente do trabalho.
Diante disso, o desenvolvedor de TICs deve estar ciente de que o resultado do seu
trabalho vai modificar a vida de muitas pessoas (inclusive a sua prpria) de forma
previsvel e imprevisvel. Sempre que possvel, devemos tentar prever essas modificaes
e encaminh-las da melhor forma possvel. Para os casos em que no possvel prever os
efeitos das novas tecnologias, importante que o desenvolvedor tambm crie
salvaguardas para os usurios, por exemplo, fornecendo maneiras fceis de desfazer
aes e maneiras alternativas de realizar as coisas sem depender da tecnologia
desenvolvida. Quem desenvolve tecnologia precisa sempre se perguntar: o que acontece
se o usurio errar, a tecnologia falhar ou permanecer indisponvel por algum tempo? As
salvaguardas sero desenvolvidas de acordo com as respostas a perguntas como essa.
1.2 Diferentes Vises sobre a construo de
sistemas interativos
Existem diversos atores envolvidos no desenvolvimento e uso dos sistemas
computacionais interativos: fabricantes de hardware, de software, vendedores,
profissionais de suporte e manuteno, provedores de acesso Internet, produtores de
contedo, usurios, organizaes, dentre outros. Todas essas partes interessadas
costumam ser denominadas stakeholders. Cada um enxerga a tecnologia sob um ponto de
vista diferente, enfatizando alguns aspectos em detrimento de outros.
Por exemplo, um usurio costuma estar mais interessado no acesso Internet que um
dispositivo possibilita e como isso pode ser til para ele do que interessado nas peas
que compem o dispositivo ou como elas foram montadas. Apesar de as duas
perspectivas serem sobre o mesmo dispositivo, a segunda perspectiva mais comum a
um desenvolvedor de hardware e a um profissional de suporte.
Em outro exemplo, pense em uma organizao que utiliza software como instrumento
de trabalho. Para apoiar os processos de trabalho da organizao, um gerente encomenda
um sistema a uma empresa de desenvolvimento de software. Os desenvolvedores
costumam se concentrar nas funcionalidades do software e em como ele estruturado
internamente. J os funcionrios da organizao geralmente se preocupam em como vo
aprender e utilizar o software para realizar o seu trabalho com eficincia. Existe uma
diferena sutil, porm importante, entre o que um sistema interativo deve permitir fazer
(viso do cliente, responsvel pela aquisio do sistema), o que ele de fato permite fazer
(viso de quem produz, focada nas funcionalidades do software) e a maneira como ele
utilizado (viso dos usurios, focada no impacto do software no seu trabalho ou na sua
vida). A identificao dos diferentes atores envolvidos e a articulao dos seus interesses
e pontos de vista so importantes desafios no desenvolvimento de tecnologia.
Se nas relaes entre pessoas ainda encontramos tantos problemas (mal-entendidos,
discrdias, brigas, guerras etc.) depois de milnios de experincia, imagine quantos
problemas podemos encontrar nas interaes entre pessoas e sistemas computacionais,
considerando que a Computao ainda no completou um sculo. Alm do pouco tempo
de convvio, pessoas so bem diferentes dos sistemas computacionais que sabemos
construir atualmente. Os sistemas computacionais so construdos para sempre
executarem um conjunto predefinido de instrues. Tudo o que um sistema capaz de
fazer foi definido na sua construo. Consequentemente, os sistemas sempre
interpretam as aes do usurio de uma forma predefinida. Isso traz grandes
dificuldades para os sistemas lidarem com a criatividade e a reinterpretao das coisas
pelas pessoas.
As diversas reas de conhecimento possuem perspectivas distintas sobre o problema,
com diferentes experincias, estratgias de soluo e conhecimentos estabelecidos. Cada
rea analisa os sistemas interativos de acordo com critrios de qualidade particulares,
cada qual assumindo diferentes graus de importncia. Grande parte da Computao e,
em particular, a subrea de Engenharia de Software, est interessada na construo de
sistemas interativos mais eficientes, robustos, livres de erros, e de fcil manuteno. Por
outro lado, a rea de Interao Humano-Computador (IHC) est interessada na
qualidade de uso desses sistemas e no seu impacto na vida dos seus usurios. Apesar de
fortemente relacionados, a construo e o uso de um artefato ocorrem em contextos
distintos e seguem lgicas diferentes, envolvendo pessoas diversas. Essas diferenas
permitem que um sistema interativo com alta qualidade de construo possa ter baixa
qualidade de uso, e vice-versa. Por exemplo, possvel que um sistema seja til e
agradvel ao usurio, mas com manuteno bem difcil. Tambm possvel que um
sistema seja robusto e livre de erros, mas difcil de ser compreendido pelo usurio e
pouco til para ele.
Essa dualidade entre construo e uso tambm ocorre em outras atividades
envolvendo diferentes pessoas, como na produo e consumo, na escrita e leitura, e em
outras reas de conhecimento como, por exemplo, entre a Engenharia Civil e a
Arquitetura. A primeira enfatiza a construo de ambientes fsicos, focando aspectos
como custo, durabilidade, estrutura e mtodos de construo, enquanto a segunda
enfatiza o uso destes ambientes, focando as pessoas e suas interaes entre elas e com o
ambiente.
Por ter a qualidade de construo como prioritria, grande parte da Computao
costuma conceber um sistema interativo de dentro para fora, isto , conceber primeiro
(ou pelo menos com nfase bem maior em) representaes de dados, algoritmos que
processam esses dados, arquitetura do sistema e tudo mais que permite um sistema
interativo funcionar (Figura 1.2a). Pouca ou nenhuma ateno de fato dedicada ao que
fica fora do sistema e a como ele ser utilizado. Parece haver um pressuposto de que tudo
o que for externo ao sistema vai, sem esforo, adaptar-se a ele e ser capaz de tirar proveito
dele da melhor forma possvel. Infelizmente, nem sempre o mundo fora de um sistema
interativo se adapta a ele e o aproveita de maneira to fcil, simples e rpida quanto
alguns desenvolvedores gostariam que acontecesse. Se seguirmos uma abordagem de
dentro para fora, corremos um grande risco de concebermos um sistema interativo
inapropriado para o mundo que o cerca, pois a nossa compreenso do mundo pode ser
equivocada.
FIGURA 1.2 Abordagem de desenvolvimento (a) de dentro para fora e (b) de fora para dentro.

Para conceber um sistema interativo mais adequado ao mundo onde ser inserido, a
rea de IHC (e, sob alguns aspectos, tambm a rea de Engenharia de Requisitos) busca
seguir uma abordagem de fora para dentro (Figura 1.2b). Nessa abordagem, o projeto
de um sistema interativo comea investigando os atores envolvidos, seus interesses,
objetivos, atividades, responsabilidades, motivaes, os artefatos utilizados, o domnio, o
contexto de uso, dentre outros, para depois identificar oportunidades de interveno na
situao atual, a forma que a interveno tomar na interface com o usurio e,
finalmente, como o sistema viabiliza essa forma de interveno. Tomando como exemplo
duas reas da Computao, a rea de Engenharia de Requisitos privilegia os critrios de
qualidade da Engenharia de Software, enquanto a rea de IHC privilegia a qualidade de
uso dos sistemas interativos.
Dentro da Computao, outras reas auxiliam a concepo de uma soluo interativa
com alta qualidade de uso, como a Engenharia de Software, Inteligncia Artificial e
Trabalho Cooperativo Apoiado por Computador (Computer-Supported Cooperative Work).
Por exemplo, tcnicas de inteligncia artificial so utilizadas em interfaces em linguagem
natural e tambm em adaptaes da interface ao contexto de uso. Embora IHC utilize
conhecimentos e tcnicas de diferentes reas dentro e fora da Computao, IHC se
distingue delas por focar o uso de sistemas interativos (Sharp et al., 2007).
1.3 Objetos de Estudo em IHC
Afinal, a rea de IHC trata de quais assuntos? Qual o seu escopo? Quais so seus
objetos de estudo? IHC uma disciplina interessada no projeto, implementao e
avaliao de sistemas computacionais interativos para uso humano, juntamente com os
fenmenos relacionados a esse uso (Hewett et al., 1992). De acordo com Hewett e seus
colegas (1992), os objetos de estudo de IHC podem ser agrupados em cinco tpicos inter-
relacionados: a natureza da interao humano-computador; o uso de sistemas interativos
situado em contexto; caractersticas humanas; arquitetura de sistemas computacionais e
da interface com usurios; e processos de desenvolvimento preocupados com uso (Figura
1.3).

FIGURA 1.3 Objetos de estudo em IHC (adaptado de Hewett et al., 1992).

Estudar a natureza da interao envolve investigar o que ocorre enquanto as pessoas


utilizam sistemas interativos em suas atividades. possvel descrever, explicar e prever
esse fenmeno e algumas de suas consequncias na vida das pessoas.
O contexto de uso influencia a interao de pessoas com sistemas interativos, pois elas
esto inseridas em determinada cultura, sociedade e organizao, possuem modo
prprio de realizar suas atividades, possuem conhecimentos e concepes prprios e
utilizam linguagem para interagir com as outras pessoas. importante estarmos cientes
de que o contexto de uso costuma ser diferente do contexto em que os desenvolvedores
esto inseridos e com o qual esto acostumados. Da a importncia de investigarmos o
contexto de uso com foco nos usurios e sob o seu ponto de vista. Isso nos permite
avaliar o impacto dos diferentes aspectos do contexto sobre a interao humano-
computador sendo concebida ou avaliada.
As caractersticas humanas tambm influenciam a participao das pessoas na
interao com sistemas interativos. A interao com qualquer artefato novo,
principalmente os sistemas computacionais interativos, que lidam com informaes,
requer capacidade cognitiva para processar informaes e aprender a utiliz-los. A forma
como as pessoas se comunicam e interagem, entre si e com outros artefatos, tambm
influencia a interao humano-computador, pois elas tendem a continuar utilizando
essas mesmas formas de interao quando lidam com um sistema computacional
interativo (Reeves e Nass, 2003). Alm disso, as caractersticas fsicas dos seres humanos,
como viso, audio, tato e capacidade de movimentar o corpo, so responsveis pela sua
capacidade de percepo do mundo ao seu redor e sua capacidade de atuar sobre ele.
Conhecer as caractersticas humanas dos usurios nos permite aproveitar suas
capacidades e, principalmente, respeitar suas limitaes durante a interao com
sistemas computacionais. O Captulo 3 apresenta algumas teorias e trabalhos empricos
que investigam essas caractersticas humanas.
Existem estudos sobre a arquitetura de sistemas computacionais e interfaces com
usurio buscando construir sistemas que favoream a experincia de uso (John et al.,
2004). Diversas tecnologias e dispositivos tm sido desenvolvidos para permitir e facilitar
a interao com pessoas. Os dispositivos de entrada e sada so os meios fsicos
responsveis por mediar o contato fsico entre pessoas e sistemas computacionais. Esse
contato ocorre de acordo com tcnicas de dilogo, como preenchimento de formulrios
utilizando o teclado e seleo de menus utilizando o mouse, por exemplo. O projeto da
interao costuma aproveitar modelos conceituais j conhecidos pelos usurios para
facilitar a adoo e o aprendizado do sistema. Por fim, existem tcnicas para construir a
interface com usurio, desenvolvidas, por exemplo, na rea de Computao Grfica e em
Inteligncia Artificial. Conhecer essas tecnologias e dispositivos fundamental para
sermos capazes de propor, comparar, avaliar e tomar decises sobre formas alternativas
de interao com sistemas computacionais.
Finalmente, o processo de desenvolvimento de um sistema interativo influencia a
qualidade do produto final. Por isso importante conhecermos abordagens de design de
IHC, mtodos, tcnicas e ferramentas de construo de interface com usurio e de
avaliao de IHC. Tambm importante conhecermos e analisarmos casos de sucesso e
de insucesso de interfaces com usurio, sempre buscando identificar os motivos que
levaram a tal resultado. O Captulo 4 apresenta alguns processos de desenvolvimento
comumente utilizados em IHC.
1.4 IHC como rea Multidisciplinar
IHC se beneficia de conhecimentos e mtodos de outras reas fora da Computao para
conhecer melhor os fenmenos envolvidos no uso de sistemas computacionais
interativos. reas como Psicologia, Sociologia e Antropologia contribuem para aquisio
de conhecimento sobre a cultura e o discurso dos usurios e sobre seus comportamentos
no ambiente onde realizam suas atividades, sejam elas individuais ou em grupo. A
definio da interface com usurio faz uso de conhecimentos e tcnicas de reas como:
Design, Ergonomia, Lingustica e Semitica.
Alguns conhecimentos e tcnicas importados de outras reas alm da Computao so
adaptados s necessidades de IHC. Por exemplo, a Psicologia utiliza extensamente
entrevistas para ter acesso s concepes, emoes e subjetividade das pessoas. Isso
muito mais profundo e complexo que a utilizao mais frequente de entrevistas em IHC,
atravs das quais normalmente investigamos a compreenso sobre um domnio, opinies
sobre certos sistemas interativos e o que ocorreu durante uma experincia de uso para
avaliao da interface com usurio. Algumas tcnicas de apresentao de contedo
esttico, como as utilizadas em jornais, revistas e livros, foram adaptadas em IHC para
lidar com a dinmica da interface, bem como contedos hipermdia.
Conforme discutido at aqui, percebemos que a rea de IHC articula uma grande
quantidade de conhecimentos oriundos de diversas reas. Isso torna muito difcil que um
nico profissional tenha conhecimento profundo de todos os objetos de estudo de IHC.
Se um nico profissional dificilmente conhece em profundidade todos os assuntos
relacionados com a interao entre pessoas e sistemas computacionais, como possvel
cuidarmos das questes relacionadas a IHC de forma adequada? Idealmente, a
responsabilidade de cuidar de IHC deve ser atribuda a uma equipe multidisciplinar.
Dessa forma, profissionais com formaes diferentes podem trabalhar em conjunto,
concebendo e avaliando a interao de pessoas com sistemas computacionais.
Esse ambiente heterogneo de profissionais com diferentes formaes facilita o
surgimento de ideias, a criatividade e a inovao, bem como auxilia a anlise do
problema e de alternativas de solues sob pontos de vista bem variados, enriquecendo,
assim, o resultado do trabalho. Muitos projetos de IHC so realizados por uma equipe
multidisciplinar, contando com engenheiros, designers,5 programadores, psiclogos,
antroplogos, socilogos, artistas, dentre outros (Sharp et al., 2007). A deciso de quais
profissionais devem fazer parte da equipe multidisciplinar de IHC precisa considerar
vrios fatores, como, por exemplo, o domnio e porte do sistema, e o oramento
disponvel.
Entretanto, uma equipe multidisciplinar requer que profissionais com diferentes
formaes superem as dificuldades de trabalhar em conjunto. Cada profissional tem uma
viso de mundo, uma forma particular de pensar e, muitas vezes, um vocabulrio
prprio. Para aproveitar as competncias de cada profissional e evitar conflitos,
necessrio facilitar a comunicao e a compreenso entre os membros da equipe
multidisciplinar. Alm disso, importante criar um ambiente de respeito aos valores e s
contribuies de cada profissional para que as discusses sejam proveitosas e
cooperativas e, no se tornem uma luta entre posies individuais, opostas e
intransigentes.
Se no for possvel compor uma equipe multidisciplinar para cuidar de IHC, o
resultado do trabalho de mais de uma pessoa com a mesma formao tende a ser melhor
do que o resultado do trabalho de apenas uma pessoa. Cada um percebe as questes e
reflete sobre elas de maneira diferente, o que lhes facilita propor um conjunto maior de
ideias e compar-las sob diferentes aspectos.
1.5 Benefcios de IHC
Por que devemos estudar e cuidar da interao entre pessoas e sistemas computacionais?
Quais so os benefcios? Comeamos este captulo analisando como as TICs esto
presentes na vida das pessoas e conclumos que essas tecnologias afetam direta ou
indiretamente o que as pessoas fazem, como, onde, quando e por qu. Estudar
fenmenos de interao entre seres humanos e sistemas computacionais nos permite
compreend-los para melhorarmos a concepo, construo e insero das TICs na vida
das pessoas, sempre buscando uma boa experincia de uso. Nesse sentido, devemos
procurar aproveitar as caractersticas humanas e o poder computacional para
desenvolvermos sistemas interativos que melhorem a vida das pessoas, trazendo bem-
estar, aumentando sua produtividade, satisfazendo suas necessidades e desejos, e
respeitando suas limitaes e valores. Para isso, tambm devemos conhecer as
capacidades e limitaes das tecnologias disponveis.
Aumentar a qualidade de uso de sistemas interativos apresenta vrios benefcios para
a experincia pessoal do usurio em decorrncia do uso e, consequentemente, para a sua
vida (Norman, 1988; Rubin, 1994; Bias e Mayhew, 2005). Esse aumento da qualidade de
uso contribui para:
aumentar a produtividade dos usurios, pois, se a interao for eficiente, os usurios
podem receber apoio computacional para alcanar seus objetivos mais rapidamente;
reduzir o nmero e a gravidade dos erros cometidos pelos usurios, pois eles podero
prever as consequncias de suas aes e compreender melhor as respostas do sistema
e as oportunidades de interao;
reduzir o custo de treinamento, pois os usurios podero aprender durante o prprio
uso e tero melhores condies de se sentirem mais seguros e motivados para
explorar o sistema;
reduzir o custo de suporte tcnico, pois os usurios tero menos dificuldades para
utilizar o sistema e, se cometerem algum erro, o prprio sistema oferecer apoio para
se recuperarem dos erros cometidos; e
aumentar as vendas e a fidelidade do cliente, pois os clientes satisfeitos recomendam o
sistema a seus colegas e amigos e voltam a comprar novas verses.
Alm disso, cuidar desde o incio da qualidade de uso contribui para reduzir o custo de
desenvolvimento, j que as modificaes que favorecem o uso ocorrero mais cedo no
processo de desenvolvimento. Dessa forma, a qualidade de uso est se estabelecendo
como uma vantagem competitiva e adquirindo papel importante na percepo de valor
do produto e da empresa, pois influencia a percepo do usurio sobre a qualidade do
sistema. Bias e Mayhew (2005) apresentam estudos indicando retorno de investimento
em qualidade de uso. importante lembrar que, embora os custos de desenvolvimento
possam aumentar ligeiramente, o investimento nessa rea traz benefcios sempre que o
sistema for utilizado e para todos os envolvidos com seu uso, seja direta ou
indiretamente, ao longo de toda a vida til do sistema.
Atividades
1. Impacto das TICs no cotidiano dos usurios. Analise o cenrio a seguir, identificando qual
o impacto das TICs sobre o que o usurio faz, como, quando, onde e por qu:

Marcos costuma viajar a trabalho entre duas cidades distantes. Durante o trajeto, ele
sempre procurava algo para se entreter. Com um celular capaz de exibir TV digital
interativa, ele pde assistir a seu jogo preferido durante a viagem. De repente acontece uma
jogada polmica contra o seu time. Foi pnalti ou no? Intrigado, ele rev a jogada em
diferentes ngulos para conferir o ocorrido. Antes da TV digital interativa, no era possvel
escolher quais ngulos ele poderia rever a jogada para tirar suas prprias concluses sobre o
lance, muito menos remotamente durante uma viagem.

2. Anlise dos elementos envolvidos no processo de interao. Analise o que muda nas
seguintes situaes de uso:
uma pessoa que paga as suas contas pelo computador pessoal de casa ou em um
caixa eletrnico;
um adolescente com poucos compromissos usando um sistema de agenda no seu
celular, ou um adulto com muitos compromissos administrando sua agenda no
seu computador pessoal.

O que muda nessas situaes em relao ao contexto de uso, aos objetivos dos usurios,
interface e interao? Que consideraes sobre IHC perderiam importncia? Que
outras ganhariam importncia?
1
http://www.uopeople.org/. Exceto quando indicado explicitamente, todos os Web sites mencionados neste livro foram
acessados em junho de 2010.
2
http://uk.reuters.com/article/idUKTRE4AA53S20081111.
3
http://www.tse.gov.br/internet/eleicoes/urna_eletronica/simulacao_votacao/2008/SimUrnaBR.html.
4
Em 1988, o Macaco Tio do zoolgico do Rio de Janeiro recebeu 400 mil votos para prefeito da cidade em sinal de
protesto. http://veja.abril.com.br/200897/p_093b.html.
5
Neste livro, o termo designer de IHC, ou simplesmente designer, utilizado para referenciar a pessoa ou a equipe
responsvel pelo projeto de IHC.
2

Conceitos bsicos
Objetivos do Captulo
Explicar os conceitos de interao, interface e affordance.
Descrever critrios de qualidade de uso utilizados em IHC: usabilidade, experincia do
usurio, acessibilidade e comunicabilidade.
Para aumentarmos a qualidade de uso de sistemas interativos, devemos inicialmente
identificar os elementos envolvidos na interao usuriosistema. Este captulo
apresenta os conceitos de interao usuriosistema, interface com usurio e affordance, e
descreve critrios de qualidade comumente considerados em IHC: usabilidade,
experincia do usurio, acessibilidade e comunicabilidade.
2.1 Interface, Interao e affordance
A Figura 2.1 ilustra uma situao tpica de uso: um usurio engajado num processo de
interao com a interface de um sistema interativo, buscando alcanar um objetivo em
determinado contexto de uso. O contexto de uso caracterizado por toda situao do
usurio relevante para a sua interao com o sistema (Dey, 2001), incluindo o momento
de utilizao do sistema (quando) e o ambiente fsico, social e cultural em que ocorre a
interao (onde).

FIGURA 2.1 Elementos envolvidos no processo de interao.

O exemplo a seguir examina esses elementos atravs de um cenrio de uso de uma


aplicao de produo e apresentao de slides.

Exemplo 2.1
E lementos envolvidos no processo de
interao
Vejamos algumas situaes de uso em que o professor Lucas cria, edita e
visualiza slides. No conforto da sua casa (contexto de uso), Lucas (usurio)
costuma usar o Impress do BrOffice1 (sistema) no seu computador
pessoal de mesa (desktop) para preparar os slides que vai utilizar nas aulas
(objetivo). Em alguns casos, ele comea a preparar sua aula a partir de um
documento em branco (Figura 2.2). Ele escreve o ttulo da aula, cria uma
sequncia de slides de acordo com os tpicos a serem abordados e conclui
o contedo detalhando cada tpico (processo de interao). Depois de
definido o contedo, ele cuida do layout dos slides, tal como cores, fonte
dos textos, figuras etc. Sempre que possvel, ele prefere elaborar as aulas
em casa por dispor de um ambiente mais tranquilo, com menos
interrupo e distraes.
FIGURA 2.2 Tela inicial do Impress do BrOffice.

Durante o processo de interao, Lucas manipula a interface grfica do


Impress usando o teclado e o mouse para alcanar seu objetivo. O
tamanho do monitor permite visualizar vrios slides lado a lado, para
analisar e organizar a estrutura da apresentao (Figura 2.3). O contexto de
uso tambm bastante propcio para ele explorar ideias, seja pelo fato de
haver menos interrupes, por ter livros e materiais didticos sua
disposio ou simplesmente por ser um ambiente mais confortvel para
ele.
FIGURA 2.3 Viso geral dos slides no Impress do BrOffice.

O que mudaria na situao de uso se Lucas, no aeroporto, precisasse


rever os slides da sua prxima aula usando seu smartphone enquanto
espera o avio de volta para sua cidade? Primeiro, trata-se de um
dispositivo bem diferente, que impe restries importantes na entrada e
sada de dados. A digitao e a manipulao do cursor costumam ser
menos eficientes se comparados com as permitidas pelo teclado e mouse
de desktop. A tela limita a quantidade de informao disponvel a cada
instante. O objetivo do usurio tambm mudou. Antes ele tinha interesse
maior em criar e editar slides, agora o interesse maior em visualiz-los.
Alm disso, o contexto de uso mudou significativamente. Passou de um
ambiente confortvel e com poucas interrupes para um ambiente com
vrias interrupes e que dispersa facilmente a ateno do usurio.
Quando Lucas chegar sala de aula, o contexto de uso mudar
novamente, e a relao com os alunos e a forma de apresentar o contedo
vai influenciar a apresentao de slides. Na sala de aula, Lucas continua
com o objetivo de exibir os slides como no aeroporto. Entretanto, o modo
de exibi-los fortemente influenciado pelo novo contexto. Por exemplo, o
tempo gasto em cada slide ser diferente, ou pode ser necessrio voltar a
slides anteriores porque um aluno ficou com alguma dvida. Nesse caso,
os dispositivos de entrada e sada sero os oferecidos por um notebook e
um projetor de tela. Esses dispositivos de entrada e de sada no so muito
diferentes daqueles oferecidos por um desktop, a no ser o projetor de tela,
que nem sempre reproduz as cores conforme o esperado e mais
influenciado pela luminosidade do ambiente.
1 http://www.broffice.org.
Se considerarmos Lucas como um usurio alvo de um novo sistema de edio e
apresentao de slides, as diferenas nas situaes de uso por ele vivenciadas no exemplo
deveriam ser consideradas no design e avaliao desse novo sistema. Se isso no ocorrer,
Lucas e outros usurios que vivenciem situaes semelhantes podero ter dificuldades ao
utilizar o sistema.

2.1.1 Interao
A definio de interao usuriosistema evoluiu ao longo do tempo. A princpio, tratava
essencialmente de uma sequncia de estmulos e respostas, como na interao de corpos
fsicos. Com o surgimento das pesquisas de base cognitiva, passou-se a enfatizar a
interao como a comunicao com mquinas, em vez de a operao de mquinas (Card,
Moran e Newell, 1983). Investigou-se tambm a interao como um processo atravs do
qual o usurio formula uma inteno, planeja suas aes, atua sobre a interface, percebe
e interpreta a resposta do sistema e avalia se seu objetivo foi alcanado (Norman, 1986).
Em geral, a interao usuriosistema pode ser considerada como tudo o que acontece
quando uma pessoa e um sistema computacional se unem para realizar tarefas, visando a
um objetivo (Hix e Hartson, 1993). Mais recentemente, enfatiza-se a interao usurio
sistema como processo de comunicao entre pessoas, mediada por sistemas
computacionais (de Souza, 2005a). Sendo assim, podemos considerar a interao
usuriosistema como sendo um processo de manipulao, comunicao, conversa, troca,
influncia, e assim por diante. As abordagens tericas de IHC privilegiam diferentes
definies do fenmeno de interao usuriosistema.
Kammersgaard (1988) identificou quatro perspectivas de interao usuriosistema:
perspectiva de sistema, de parceiro de discurso, de ferramenta e de mdia. Cada uma
atribui ao usurio e ao sistema determinado papel e caracteriza a interao sob um ponto
de vista diferente, como ilustrado na Figura 2.4.
FIGURA 2.4 Perspectivas de interao humano-computador.

Na perspectiva de sistema, o usurio considerado como um sistema computacional, e


a interao humano-computador aproxima-se da interao entre sistemas
computacionais, ou seja, vista como uma mera transmisso de dados entre pessoas e
sistemas computacionais, anloga transmisso de dados entre sistemas. Desse modo, o
usurio precisa se comportar como uma verdadeira mquina, aprendendo a interagir de
forma bem disciplinada e restrita por formatos de entrada padronizados e rgidos.
comum a utilizao de linguagem de comando ou de programao (como linguagens de
script) nessa transmisso de dados. Quando se trabalha na perspectiva de sistema, o
principal objetivo aumentar a eficincia e a transmisso correta de dados, reduzindo o
tempo de interao e o nmero de erros cometidos pelos usurios.
Um exemplo clssico do emprego dessa perspectiva o terminal de comando de
sistemas operacionais, tais como DOS e Linux (Figura 2.5).

FIGURA 2.5 Ilustrao de um terminal do Linux, exemplificando a perspectiva de sistema.

Outro emprego comum da perspectiva de sistema limitar aquilo que os usurios


podem dizer, atravs de listas fechadas, controles de calendrio e outros elementos de
interface restritivos, como ocorre em sites de empresas areas (Figura 2.6).
FIGURA 2.6 Fragmento de formulrio ilustrando a perspectiva de sistema.

Combinaes de teclas de atalho, tal como Ctrl+C para copiar e Ctrl+V para colar,
tambm so exemplos de emprego da perspectiva de sistema. Elas so muito teis e
eficientes para usurios que possuem habilidade com o teclado e tenham tempo,
disposio e capacidade cognitiva para aprender a sequncia de teclas e os comandos
associados.
A perspectiva de sistema pode ser inadequada para a realizao de algumas atividades
por certas classes de usurios, pois ela pode requerer algum tipo de treinamento e seu
uso pode ser difcil e tedioso no incio. Exemplo disso so os sistemas de linguagem de
comando utilizados intensamente por funcionrios de companhias areas, nos balces
dos aeroportos. Esses funcionrios recebem extenso treinamento, para que consigam
utilizar o sistema. A vantagem que, aps o treinamento, utilizam o sistema com muita
eficincia. Tais sistemas seriam inadequados a passageiros interessados em efetuar suas
reservas ou seu check-in, pois seu uso espordico no justificaria o investimento
necessrio em treinamento.
Em oposio perspectiva de sistema, surgiu na rea de Inteligncia Artificial uma
proposta de transformar o sistema interativo em parceiro do discurso. Nessa perspectiva,
o sistema interativo deve participar da interao assumindo papel altura de um ser
humano, sendo capaz de raciocinar, fazer inferncias, tomar decises, adquirir
informao, enfim, o sistema deve ser capaz de se comportar de forma semelhante aos
seus usurios. Essa perspectiva visa tornar a interao humano-computador mais
prxima de uma interao entre seres humanos. Nesse caso, a interao costuma ser
compreendida como uma conversa. O objetivo do designer nessa perspectiva cuidar da
quantidade, contedo e sequncia das falas durante a conversa usuriosistema que
auxilia o usurio a atingir seu objetivo. Geralmente, a perspectiva de parceiro de discurso
faz uso da linguagem natural como meio de comunicao usuriosistema. Por exemplo,
poderamos encontrar o dilogo do Exemplo 2.2 em um sistema de busca por produtos e
servios.
Exemplo 2.2
I nterao na perspectiva de parceiro de
discurso.
Sistema: Em que posso ajudar?
Usurio: Quero procurar um presente para a minha tia.
Sistema: Do que sua tia gosta?
Usurio: Flores e bombons de chocolate com licor de cereja.
Sistema: Que tal um bouquet de rosas por R$60,00 e uma caixa de
bombons por R$80,00?
Usurio: Acho melhor orqudeas.
Sistema: Que tal uma orqudea da famlia Cattleya Trianae por R$250,00?
Usurio: esta que eu quero.
Sistema: O telefone da floricultura 5555-5555. E da loja de bombons
5555-1234.
Usurio: Obrigado.
Sistema: De nada.

Construir um sistema parceiro de discurso no algo trivial. At hoje existem diversas


pesquisas nessa linha, pois ainda temos grandes desafios no processamento em
linguagem natural. Um bom exemplo desses desafios so os problemas que ocorrem em
tradutores automticos de texto.
Na perspectiva de ferramenta, o sistema interativo considerado um instrumento que
auxilia o usurio a realizar suas tarefas. Nessa perspectiva, a interao representa um
processo de aplicar uma ferramenta a algum material e avaliar o resultado
(Kammersgaard, 1988, p. 353) durante a realizao de uma atividade. O processo de
interao descrito principalmente pelo encadeamento de aes e reaes empregando
tal ferramenta (um sistema interativo). O sucesso da interao depende do conhecimento
do usurio sobre a ferramenta e de sua capacidade de manipul-la com destreza. Durante
a interao, o usurio deve se concentrar no seu trabalho e manipular a ferramenta de
forma automtica, sem precisar pensar sobre essa manipulao; assim como um
carpinteiro manipula um martelo enquanto fabrica mveis, ou um cozinheiro manipula
talheres enquanto cozinha. Essa perspectiva predominante nos sistemas de propsito
geral e famlias de aplicaes de escritrio, como no Microsoft Office e no OpenOffice.
Os fatores de qualidade mais evidentes nessa perspectiva so a relevncia das
funcionalidades oferecidas e a facilidade de uso da ferramenta.
A perspectiva de mdia vem ganhando cada vez mais espao em sistemas interativos
atuais, em particular sistemas que conectam pessoas atravs da Internet. Nessa
perspectiva, o sistema interativo visto como uma mdia (semelhante imprensa,
televiso, rdio e telefone) atravs da qual as pessoas se comunicam umas com as outras.
Assim, a interao significa comunicao por meio da mdia num contexto coletivo. Alm
da comunicao entre usurios mediada por sistemas interativos, como ocorre em
sistemas de e-mail, frum, chats e redes sociais, tambm existe a comunicao unilateral
dos designers do sistema para os usurios, explcita na ajuda on-line, nas instrues na
interface e na documentao do sistema, ou implcita atravs da seleo e disposio dos
elementos de interface em si. Nessa perspectiva, busca-se principalmente zelar pela
qualidade da comunicao entre pessoas mediada por um sistema interativo e o seu
entendimento mtuo.
A perspectiva de mdia e a perspectiva de parceiro de discurso so distintas. Enquanto
a primeira v a interao como uma conversa usuriosistema, a segunda a v como uma
comunicao entre pessoas mediada por tecnologia. Apesar de essas duas perspectivas
considerarem a interao como um processo de comunicao, a diferena entre elas
aparece nos interlocutores. Na perspectiva de discurso, o sistema um dos interlocutores
buscando conversar como um ser humano. J na perspectiva de mdia, o sistema
apenas um meio atravs do qual outros interlocutores (usurios e designer) podem se
comunicar.
A Tabela 2.1 apresenta um resumo comparativo das perspectivas de interao,
destacando os diferentes significados de interao e os principais critrios de qualidade
de cada uma delas. importante observar que mais de uma perspectiva pode coexistir em
um nico sistema interativo. Em sistemas de empresas areas, por exemplo, encontramos
a perspectiva de sistema empregada na escolha dos destinos e origens, e a perspectiva de
mdia empregada em sees do tipo fale conosco. A escolha das perspectivas ser feita
de acordo com o perfil e as necessidades dos usurios, com o contexto de uso e com o
apoio computacional que pretendemos lhes oferecer.

Tabela 2.1
Comparao das perspectivas de interao (Kammersgaard, 1988).

perspectiva significado de interao fatores de qualidade m ais evidentes


sistema transmisso de dados eficincia (tal como indicado pelo tempo de uso e nmero de erros
cometidos)
parceiro de conversa usuriosistema adequao da interpretao e gerao de textos
discurso
ferramenta manipulao de ferramenta funcionalidades relevantes ao usurio, facilidade de uso
mdia comunicao entre usurios e comunicao designer qualidade da comunicao mediada e entendimento mtuo
usurio

2.1.2 Interface
Se a interao um processo que ocorre durante o uso, o que a interface de um sistema
interativo? A interface de um sistema interativo compreende toda a poro do sistema
com a qual o usurio mantm contato fsico (motor ou perceptivo) ou conceitual durante
a interao (Moran, 1981). Ela o nico meio de contato entre o usurio e o sistema. Por
isso, a grande maioria dos usurios acredita que o sistema a interface com a qual
entram em contato (Hix e Hartson, 1993).
O contato fsico na interface ocorre atravs do hardware e do software utilizados
durante a interao. Dispositivos de entrada, como teclado, mouse, joystick, microfone,
caneta (que escreve sobre a tela) e cmera (webcam), permitem ao usurio agir sobre a
interface do sistema e participar ativamente da interao. J os dispositivos de sada,
como monitor, impressora e alto-falante, permitem ao usurio perceber as reaes do
sistema e participar passivamente da interao.
Os dispositivos mecnicos tinham uma relao fsica aparente com seu
comportamento quando eram programados apenas via hardware. Por exemplo, as teclas
numricas de um telefone representavam apenas os nmeros que o usurio poderia
discar. Mais recentemente, as teclas numricas ganharam novas funes, como a de servir
de teclado alfanumrico e para qualquer comportamento possvel de se programar em
software. Com a incorporao, em diversos dispositivos, de teclas de propsito mltiplo
ou configurveis, bem como telas de apresentao de informao, o software tambm
passou a ter grande importncia na definio da interface com usurio. O software
determina os efeitos no comportamento do sistema decorrentes das aes do usurio
sobre os dispositivos de entrada, bem como os efeitos nos dispositivos de sada
decorrentes de um processamento realizado pelo sistema. Em interfaces grficas, por
exemplo, pode-se clicar com o mouse (hardware) em um boto com um [x] e obter como
resultado o trmino da execuo do programa (software).
O contato conceitual com a interface envolve a interpretao do usurio daquilo que ele
percebe atravs do contato fsico com os dispositivos de entrada e de sada durante o uso
do sistema. Essa interpretao permite ao usurio compreender as respostas do sistema e
planejar os prximos caminhos de interao.
A interface com usurio determina os processos de interao possveis, medida que
determina o que ele pode falar ou fazer, de que maneira e em que ordem. Portanto,
quando definimos como a interao deve ocorrer, estamos restringindo ou determinando
algumas caractersticas da interface, e vice-versa. Por exemplo, se projetarmos um
processo de interao para compra on-line em trs passos escolher produtos, informar
endereo de entrega e comunicar forma de pagamento a interface deve permitir que o
usurio percorra esses passos mantendo-o informado sobre a evoluo do processo de
compra. Outro exemplo nesse domnio seria a disposio das informaes sobre
produtos (modelo, preo, fabricante, especificaes tcnicas etc.) na interface, que pode
facilitar ou dificultar a interao do usurio com o sistema para comparao de produtos.
Todos os elementos envolvidos no processo de interao esto fortemente
relacionados. O contexto de uso influencia a forma como os usurios percebem e
interpretam a interface, e tambm seus objetivos. Por exemplo, uma resposta sonora
pouco til em um ambiente de uso barulhento porque pode passar despercebida. Os
objetivos de um professor usando um editor de slides em casa e na sala de aula
costumam ser diferentes. Em casa, o foco costuma ser a criao e edio de slides,
enquanto, em sala de aula, o foco costuma ser a sua apresentao. As caractersticas
fsicas e cognitivas dos usurios tambm influenciam a definio de uma interface
apropriada. Por exemplo, pessoas daltnicas podem no diferenciar informaes
expressas por determinadas cores na interface. Muitas delas no diferenciam o verde do
vermelho. A formao, o conhecimento e as experincias do usurio tambm no podem
ser ignorados na definio da interface. Por exemplo, no podemos esperar que um
analfabeto aprenda a usar a interface lendo instrues na tela.

2.1.3 Affordance
As caractersticas fsicas de um artefato evidenciam o que possvel fazer com ele e as
maneiras de utiliz-lo. O mesmo ocorre com a interface com usurio. O conjunto de
caractersticas do hardware e do software perceptveis pelo usurio aponta para um
conjunto de operaes que podem ser realizadas com o sistema interativo, bem como
para as formas de realiz-las manipulando os elementos da interface. Existe um termo
tcnico para esse conjunto de caractersticas: affordance.
Gibson (1977, 1979) definiu o termo affordance na Psicologia, que mais tarde foi
adaptado para IHC por Norman. Em IHC, a affordance de um objeto corresponde ao
conjunto das caractersticas de um objeto capazes de revelar aos seus usurios as
operaes e manipulaes que eles podem fazer com ele (Norman, 1988). Em uma
interface grfica, por exemplo, a affordance de um boto de comando diz respeito
possibilidade de pression-lo usando o mouse ou o teclado e, assim, acionar uma
operao do sistema.
As affordances da interface de um sistema interativo so importantes para guiar o
usurio sobre o que o sistema capaz de fazer e como ele pode manipular a interface
para faz-lo. Os designers devem tomar cuidado para no criarem falsas affordances, pois
os efeitos colaterais so inconvenientes. As falsas affordances podem dar a impresso de
que a interface funciona de determinada maneira, quando na verdade funciona de outra
forma. Uma falsa affordance pode ser criada, por exemplo, quando um desenvolvedor
utiliza uma caixa de texto ou um boto de comando apenas para apresentar uma
mensagem ou contedo no editvel (Figura 2.7).

FIGURA 2.7 Exemplos de diferentes affordances de alguns elementos de interface (widgets).

Na caixa de texto, o usurio pode acreditar que possvel editar o texto da mensagem.
No boto de comando, ele pode acreditar que existe um comando associado ao evento de
pressionar o boto. Desses elementos, apenas o rtulo apresenta uma affordance
adequada apresentao de dados e mensagens ao usurio.
2.2 Qualidade em IHC
Usar um sistema interativo significa interagir com sua interface para alcanar objetivos
em determinado contexto de uso. A interao e a interface devem ser adequadas para que
os usurios possam aproveitar ao mximo o apoio computacional oferecido pelo sistema.
Que caractersticas a interao e a interface devem ter para serem consideradas
adequadas?
Os critrios de qualidade de uso enfatizam certas caractersticas da interao e da
interface que as tornam adequadas aos efeitos esperados do uso do sistema. Os critrios
de qualidade de uso descritos neste livro so: usabilidade, experincia do usurio,
acessibilidade e comunicabilidade. A usabilidade o critrio de qualidade de uso mais
conhecido e, por conseguinte, o mais frequentemente considerado. Para muitas pessoas,
inclusive, qualidade de uso chega a ser sinnimo de usabilidade.
A usabilidade est relacionada com a facilidade de aprendizado e uso da interface, bem
como a satisfao do usurio em decorrncia desse uso (Nielsen, 1993).
Tradicionalmente, a usabilidade enfoca a maneira como o uso de um sistema interativo
no ambiente de trabalho afetado por caractersticas do usurio (sua cognio, sua
capacidade de agir sobre a interface e sua capacidade de perceber as respostas do
sistema). Com a disseminao dos sistemas computacionais interativos em ambientes
diferentes do trabalho, a usabilidade passou a englobar tambm as emoes e os
sentimentos dos usurios. Por vezes essa qualidade relacionada com os sentimentos e
emoes dos usurios denominada de experincia do usurio (Sharp et al., 2007).
Para um usurio tirar proveito do apoio computacional oferecido pelo sistema, no
podem existir barreiras que o impeam de interagir com sua interface. O critrio de
acessibilidade est relacionado remoo das barreiras que impedem mais usurios de
serem capazes de acessar a interface do sistema e interagirem com ele. Cuidar da
acessibilidade significa permitir que mais pessoas possam interagir com o sistema,
tenham elas alguma deficincia ou no. A inteno incluir, no excluir.
O critrio de comunicabilidade chama ateno para a responsabilidade de o designer
comunicar ao usurio suas intenes de design e a lgica que rege o comportamento da
interface. Esse critrio se pauta no pressuposto de que, se o usurio tiver acesso lgica
de design, ele ter melhor condio de fazer um uso produtivo e criativo do apoio
computacional oferecido pelo sistema.
A seguir, analisamos cada um desses critrios em mais detalhes.

2.2.1 Usabilidade E Experincia De Usurio


Ao definir os critrios de qualidade de software, a norma ISO/IEC 9126 (1991) define
usabilidade como sendo:

Um conjunto de atributos relacionados com o esforo necessrio para o uso de um sistema


interativo, e relacionados com a avaliao individual de tal uso, por um conjunto especfico
de usurios.
E a norma sobre requisitos de ergonomia, ISO 9241-11 (1998), define usabilidade como
sendo:

O grau em que um produto usado por usurios especficos para atingir objetivos especficos
com eficcia, eficincia e satisfao em um contexto de uso especfico.

Segundo essa norma, eficcia est relacionada com a capacidade de os usurios


interagirem com o sistema para alcanar seus objetivos corretamente, conforme o
esperado. A eficincia est relacionada com os recursos necessrios para os usurios
interagirem com o sistema e alcanarem seus objetivos. Normalmente, os recursos
necessrios so tempo, mo de obra e materiais envolvidos. A norma tambm destaca a
importncia de considerarmos o grau de satisfao dos usurios com a experincia de
usar o sistema interativo no contexto de uso para o qual foi projetado.
Nielsen (1993) define o critrio de usabilidade como um conjunto de fatores que
qualificam quo bem uma pessoa pode interagir com um sistema interativo. Esses
critrios esto relacionados com a facilidade e o esforo necessrios para os usurios
aprenderem e utilizarem um sistema. Desse modo, a usabilidade enderea
principalmente a capacidade cognitiva, perceptiva e motora dos usurios empregada
durante a interao. Os fatores de usabilidade por ele considerados so:
facilidade de aprendizado (learnability)
facilidade de recordao (memorability)
eficincia (efficiency)
segurana no uso (safety)
satisfao do usurio (satisfaction)
Cada sistema interativo possui caractersticas e peculiaridades que o tornam nico e
distinto dos demais. Logo, a interao com cada sistema um processo particular que
exige do usurio certo grau de aprendizado. Ele precisa dispor de tempo e interesse para
se empenhar em aprender a utilizar um sistema interativo e ser capaz de usufruir de suas
funcionalidades. possvel estabelecer nveis de aprendizado do uso do sistema. Por
exemplo, podemos definir os conhecimentos e as habilidades necessrias para usufruir
das funcionalidades do sistema num nvel simples, intermedirio e avanado. A
facilidade de aprendizado se refere ao tempo e esforo necessrios para que o usurio
aprenda a utilizar o sistema com determinado nvel de competncia e desempenho.
As pessoas esperam que o apoio computacional oferecido por um sistema interativo
seja to simples, fcil e rpido de aprender quanto possvel. Afinal, empregar tecnologias
de informao e comunicao no nosso cotidiano se justifica para facilitar a realizao
das nossas atividades, e no torn-las mais difceis e complexas. Isso vale tanto para um
sistema de uso cotidiano, como correio eletrnico, quanto para um sistema utilizado
raramente, como o sistema de declarao anual de imposto de renda. Em atividades mais
complexas, temos uma tolerncia maior em relao ao esforo e tempo necessrios para
aprendermos a utilizar um sistema interativo. Portanto, cuidar da facilidade de
aprendizado significa equilibrar (1) a complexidade da atividade sendo apoiada e o
conjunto de funcionalidades oferecido como apoio, e (2) o tempo e o esforo necessrios
para aprender a utilizar o sistema em cada nvel de competncia e desempenho
estabelecidos como meta. possvel avaliar o tempo e o esforo necessrios para a
transio entre diferentes nveis de competncia e desempenho de uso. Por exemplo,
podemos avaliar quanto tempo um usurio leva para aprender a realizar as atividades
principais e quanto tempo ele leva para aprender a realizar um conjunto mais amplo de
atividades.
O ser humano capaz de aprender, mas tambm esquece o que aprendeu. Diante de
um esquecimento, pistas sobre o que foi esquecido so muito teis para resgatarmos da
memria o que aprendemos no passado. Se a interface com usurio possuir elementos
obscuros, mal organizados, sem sentido para o usurio, com passos mal encadeados ou
muito diferentes do que ele espera, muito provavelmente o usurio ter dificuldade para
lembrar como utilizar o sistema (Sharp et al., 2007). A facilidade de recordao diz
respeito ao esforo cognitivo do usurio necessrio para lembrar como interagir com a
interface do sistema interativo, conforme aprendido anteriormente.
Um sistema de fcil recordao auxilia o usurio a se lembrar de como utilizlo,
evitando que ele cometa erros ao utilizar partes do sistema que j tenha utilizado
anteriormente. Por exemplo, o usurio pode no se lembrar do nome de um item de
menu, mas pode lembrar que ele faz parte de uma determinada categoria. Desse modo, a
organizao e descrio dos itens de menu ajudam o usurio a lembrar da opo
desejada. Em outro exemplo, a interface pode revelar pistas sobre a sequncia de
operaes durante a execuo de uma tarefa atravs de cones, nomes de comandos e
opes de menus bem projetados. Sistemas de comrcio eletrnico costumam guiar o
usurio pelos passos necessrios at a concluso da compra, sempre indicando qual o
passo atual em relao sequncia de passos necessrios. A facilidade de recordao
especialmente importante quando existem operaes ou sistemas com baixa frequncia
de uso, como, por exemplo, efetuar a matrcula numa universidade, a cada seis meses.
A maneira como um sistema interativo apoia a realizao das atividades do usurio
influencia o tempo necessrio para realiz-las e, portanto, influencia a produtividade do
usurio. A eficincia de um sistema interativo diz respeito ao tempo necessrio para
concluso de uma atividade com apoio computacional. Esse tempo determinado pela
maneira como o usurio interage com a interface do sistema. A eficincia de um sistema
interativo se torna importante quando desejamos manter alta a produtividade do
usurio, depois de ele ter aprendido a utilizar o sistema.
Errar faz parte do processo de aprendizado. Se uma pessoa se sente segura para tentar
fazer algo sem medo de errar, ela possui melhores condies para experimentar fazer
coisas novas e explorar novos caminhos. Sendo assim, muito interessante que os
sistemas interativos ofeream segurana ao usurio durante o uso para motiv-lo a
aprender a usar o software explorando suas funcionalidades. A segurana no uso se
refere ao grau de proteo de um sistema contra condies desfavorveis ou at mesmo
perigosas para os usurios. Existem duas formas para alcanarmos a segurana no uso:
buscando evitar problemas e auxiliando o usurio a se recuperar de uma situao
problemtica. Uma forma de evitar problemas reduzir a possibilidade de acionar por
engano teclas, botes e comandos indesejados. Um exemplo disso seria no colocar
botes perigosos como remover tudo muito prximos a botes de gravar (Sharp et
al., 2007). Mecanismos para desfazer e refazer facilmente uma ao (undo e redo) e
mecanismos para cancelar ou interromper operaes demoradas so formas eficientes de
recuperao de erros ou equvocos do usurio e, portanto, favorecem a explorao das
funcionalidades do sistema (veja Seo 8.2).
A satisfao do usurio o fator de usabilidade relacionado com uma avaliao
subjetiva que expressa o efeito do uso do sistema sobre as emoes e os sentimentos do
usurio. At pouco tempo, sistemas interativos eram utilizados principalmente em
atividades relacionadas ao trabalho. Por isso a satisfao do usurio costumava receber
menor ateno do que outros critrios mais relevantes a essas atividades, como a
eficincia, por exemplo.
Recentemente, os sistemas interativos deixaram de ser utilizados apenas no trabalho e
passaram a estar presentes em muitas atividades humanas (entretenimento, educao,
sade, poltica etc.) e em diversos locais (no trabalho, em casa, na escola, em trnsito, no
hospital, no museu, no shopping etc.). Essas novas atividades aumentaram a necessidade
de considerarmos a forma como o uso de um sistema interativo afeta os sentimentos e as
emoes do usurio. Alguns interpretam a preocupao com emoes e sentimentos dos
usurios como uma ateno maior satisfao do usurio como parte do critrio de
usabilidade (Bevan, 2009). Outros, no entanto, consideram essa preocupao como um
critrio de qualidade distinto, chamado de experincia do usurio (user experience
Sharp et al., 2007).
Alm da satisfao do usurio, tornou-se importante investigar outros aspectos da sua
subjetividade, caracterizando seus sentimentos, estado de esprito, emoes e sensaes
decorrentes da interao com um sistema interativo em determinado contexto de uso.
Podemos investigar vrios aspectos positivos e negativos dessa subjetividade, como, por
exemplo (Sharp et al., 2007): satisfao, prazer, diverso, entretenimento, interesse,
atrao, motivao, esttica, criatividade, provocao, surpresa, desafio, cansao,
frustrao e ofensa.
claro que no podemos prever completamente nem controlar a experincia de cada
usurio durante a interao. A experincia de uso algo subjetivo, pessoal. Entretanto,
podemos projetar sistemas interativos visando promover uma boa experincia de uso,
incorporando caractersticas que promovam boas emoes nos usurios e que evitem
provocar sensaes desagradveis, sempre respeitando as limitaes dos usurios.
Existem alguns aspectos importantes para experincia do usurio a serem
considerados durante o (re)projeto de um sistema interativo, como, por exemplo,
ateno, ritmo, divertimento, interatividade, controle consciente e inconsciente,
envolvimento e estilo de narrativa (Sharp et al., 2007). Um bom envolvimento emocional
dos usurios durante a interao agrega valor ao sistema interativo. Cabe ao designer
decidir quais aspectos subjetivos devem ser promovidos durante a interao e articular
isso com os demais critrios de qualidade de uso.
Dificilmente um nico sistema ser muito bom em todos os critrios de usabilidade,
porque no fcil articular esses critrios sem que haja perdas em um ou mais deles. Por
exemplo, um sistema pode ser eficiente com muitas teclas de atalho, mas elas podem ser
mais difceis de serem lembradas por usurios ocasionais. J um sistema com muitas
explicaes e tutoriais pode ser de fcil aprendizado, mas pode no satisfazer um usurio
experiente, que privilegie a eficincia. importante conhecermos as necessidades dos
usurios e estabelecermos quais critrios de usabilidade devem ser priorizados no
sistema em questo.

2.2.2 Acessibilidade
Durante a interao, o usurio emprega (1) sua habilidade motora para agir sobre os
dispositivos de entrada, (2) seus sentidos (viso, audio e tato) e capacidade de
percepo para identificar as respostas do sistema emitidas pelos dispositivos de sada, e
(3) sua capacidade cognitiva, de interpretao e de raciocnio para compreender as
respostas do sistema e planejar os prximos passos da interao. Se a interface impuser
alguma barreira ao usurio durante o processo de interao, ele no ser capaz de
aproveitar o apoio computacional oferecido pelo sistema.
O critrio de acessibilidade est relacionado com a capacidade de o usurio acessar o
sistema para interagir com ele, sem que a interface imponha obstculos. Melo e
Baranauskas (2005, p. 1505) definem acessibilidade como sendo a flexibilidade
proporcionada para o acesso informao e interao, de maneira que usurios com
diferentes necessidades possam acessar e usar esses sistemas. Uma interface com
usurio acessvel no pode impor barreiras para interao e para o acesso informao,
nem no hardware e nem no software do sistema interativo.
A acessibilidade atribui igual importncia a pessoas com e sem limitaes na capacidade
de movimento, de percepo, de cognio e de aprendizado. Cuidar da acessibilidade
significa permitir que mais pessoas possam perceber, compreender e utilizar o sistema
para usufruir do apoio computacional oferecido por ele (WAI, online). Isso no significa
que o sistema deve ser desenvolvido para atender exclusivamente a uma classe especial
de usurios. A inteno incluir pessoas com limitaes ou deficincias no grupo de
usurios-alvo, e no excluir desse grupo as pessoas sem limitaes ou deficincias.
Um usurio que possui limitaes fsicas (e.g., deficincia visual, auditiva e motora),
mentais ou de aprendizado (e.g., analfabetos plenos e analfabetos funcionais) tem mais
chances de encontrar barreiras que o dificultam ou impedem de interagir com o sistema.
Essas limitaes podem ser temporrias, como aquelas causadas por acidentes e
superadas algum tempo depois, ou limitaes persistentes por toda a vida, como
cegueira e paralisia causadas por deficincia congnita ou por alguma doena grave. A
idade dos usurios tambm influencia suas capacidades fsicas, mentais e de
aprendizado, seja quando criana, porque seu corpo ainda no amadureceu, ou na
terceira idade, quando algumas de suas capacidades so afetadas pelo envelhecimento.
Vejamos alguns casos em que usurios com limitaes podem encontrar dificuldades
para interagir com sistemas computacionais (Exemplo 2.3).
Exemplo 2.3
C enrios evidenciando a importncia da
acessibilidade
Deficincia Auditiva
Paulo um deficiente auditivo que acessa a Internet frequentemente sem
grandes dificuldades. A sua conexo com a Internet parou de funcionar em
casa e ele precisa entrar em contato com seu provedor de acesso. Como ele
se sentiria ao descobrir que obrigado a utilizar um sistema interativo por
telefone para ter acesso ao suporte do seu provedor de Internet? Todo o
seu esforo para aprender o Portugus, alm da Lngua Brasileira de Sinais
(Libras), no seria til nesse caso.
Deficincia Motora
Joo maneja bem o teclado e o mouse. Entretanto, no ltimo ms ele
descobriu uma tendinite crnica nas mos e sente muitas dores ao
manipular esses dois dispositivos de entrada. Certamente ele ficaria feliz
se pelo menos alguns comandos pudessem ser ativados via voz at que sua
dor diminusse.
Deficincia Visual
Joana uma jovem brasileira deficiente visual interessada em continuar
estudando. Ela ouviu no noticirio da TV que o vestibular de vrias
universidades pblicas levar em conta a nota no Enem (Exame Nacional
do Ensino Mdio). Utilizando um leitor de telas, ela conseguiu acessar o
site de inscrio do Enem (Figura 2.8) para obter informaes a respeito do
exame. No Web site ela descobriu que precisava do nmero de identidade e
CPF, mas no conseguiu encontrar um link para iniciar a inscrio, nem
percebeu que o perodo de inscrio terminou. Por que ela no percebeu
essas informaes? Se analisarmos a figura, vamos perceber que o link para
iniciar a inscrio era uma figura, e a informao de que o perodo de
inscrio terminou se encontrava dentro dessa figura. Nenhuma dessas
informaes pde ser lida pelo leitor de tela, e ela no teve acesso a
informaes sobre um servio que o Estado deveria oferecer para toda a
populao brasileira.
FIGURA 2.8 Site de inscrio no Enem em julho de 2009.2

Nesses exemplos, as limitaes fsicas dos usurios dificultaram ou impossibilitaram o


acesso aos sistemas interativos. A interao tornou-se pouco produtiva ou impossvel
devido a dificuldades para agir sobre o sistema atravs dos dispositivos de entrada, e
para perceber e interpretar os resultados emitidos pelos dispositivos de sada.
Um bom exemplo de adequao s limitaes fsicas e cognitivas do usurio so os
dispositivos GPS (Sistema de Posicionamento Global) para guiar o motorista em trnsito
utilizando mapas digitais. Enquanto dirige, o motorista no pode utilizar as mos para
agir sobre o dispositivo, nem ler instrues na tela. Desse modo, enquanto est parado, o
motorista informa ao navegador GPS onde ele pretende ir. Durante o trajeto, o sistema
vai lhe orientando sobre o caminho que deve seguir, via respostas sonoras. Repare que,
nesse caso, o sistema precisou ser adequado a limitaes temporrias impostas pelo
contexto de uso. Podemos observar que nem sempre a acessibilidade est relacionada
com deficincias persistentes ou com caractersticas de um grupo especfico de usurios.
O governo brasileiro fornece vrios servios aos cidados por meio de sistemas
computacionais, principalmente via Internet. Por exemplo, existem vrios servios do
INSS e da Receita Federal disponveis on-line; em alguns estados as matrculas em
escolas pblicas so realizadas on-line; e em alguns municpios possvel obter segunda
via do IPTU no site da prefeitura. O governo deve servir igualmente a todos os cidados
do pas, sem discriminao e respeitando as limitaes e diferenas de cada um. Por isso
devemos permitir que pessoas com limitaes fsicas, mentais e de aprendizado tenham
acesso aos servios oferecidos via tecnologias de informao e comunicao. Essa
preocupao se manifesta no decreto presidencial nmero 5.296, de 2 de dezembro de
2004, que regulamenta as leis n 10.048, de 8 de novembro de 2000, e n 10.098, de 19 de
dezembro de 2000.3 Esse decreto torna obrigatria a acessibilidade em sites do governo.
No texto do decreto, podemos destacar:

Art. 8 Para os fins de acessibilidade, considera-se:


I - acessibilidade: condio para utilizao, com segurana e autonomia, total ou assistida,
dos espaos, mobilirios e equipamentos urbanos, das edificaes, dos servios de transporte e
dos dispositivos, sistemas e meios de comunicao e informao, por pessoa portadora de
deficincia ou com mobilidade reduzida;

II - barreiras: qualquer entrave ou obstculo que limite ou impea o acesso, a liberdade de


movimento, a circulao com segurana e a possibilidade de as pessoas se comunicarem ou
terem acesso informao, classificadas em:

()

d) barreiras nas comunicaes e informaes: qualquer entrave ou obstculo que dificulte ou


impossibilite a expresso ou o recebimento de mensagens por intermdio dos dispositivos,
meios ou sistemas de comunicao, sejam ou no de massa, bem como aqueles que dificultem
ou impossibilitem o acesso informao;

()

Art. 47. No prazo de at doze meses a contar da data de publicao deste Decreto, ser
obrigatria a acessibilidade nos portais e stios eletrnicos da administrao pblica
na rede mundial de computadores (Internet), para o uso das pessoas portadoras de
deficincia visual, garantindo-lhes o pleno acesso s informaes disponveis.

As limitaes fsicas, mentais e de aprendizado dos usurios no podem ser


desprezadas, sejam elas limitaes permanentes, temporrias ou circunstanciais.
desejvel que um sistema interativo seja acessvel a qualquer pessoa, mas a
acessibilidade depende das caractersticas dos usurios que pretendemos atender e dos
contextos de uso pretendidos. Cada tipo de limitao ou deficincia requer um cuidado
especfico para criarmos interfaces acessveis. Por exemplo, uma deficincia visual requer
cuidados bem diferentes de uma deficincia auditiva. Portanto, o zelo com a
acessibilidade tambm requer conhecimento sobre as capacidades e limitaes dos
usurios e sobre os diferentes contextos de uso (Stephanidis, 2001; Melo e Baranauskas,
2006; Lazar, 2007).

2.2.3 Comunicabilidade
Um sistema interativo resultado de um processo de design no qual um designer
estabelece uma viso (interpretao) sobre os usurios, seus objetivos, o domnio e o
contexto de uso e toma decises sobre como apoi-los. Para o usurio usufruir melhor do
apoio computacional, desejvel que o designer remova as barreiras da interface que
impedem o usurio de interagir (acessibilidade), torne o uso fcil (usabilidade) e
comunique ao usurio as suas concepes e intenes ao conceber o sistema interativo.
Mas por que o usurio precisaria saber disso? Vamos analisar duas situaes bem
simples e comuns no uso de TICs (Exemplo 2.4).

Exemplo 2.4
I mportncia da comunicabilidade
Cpia de Arquivos
Maria gosta de msica e est interessada em utilizar o computador para
organizar e ouvir seus arquivos de msica. Ela comprou seu primeiro
computador recentemente e ainda no sabe utilizar os sistemas interativos
disponveis.
Maria decide colocar alguns arquivos de msica no seu pen drive para
poder ouvir em outro lugar. Depois de algum tempo copiando os arquivos,
mas antes de concluir a cpia, ela decide parar a operao em andamento
porque est atrasada para sair de casa. O que acontece se ela cancelar a
operao no concluda? Os arquivos j copiados permanecem no pen drive
ou sero removidos? Como Maria pode aprender o significado de cancelar
a operao de cpia em andamento? A Figura 2.9 apresenta a interface do
Windows XP, que permite a Maria acompanhar a operao de cpia de
arquivos.

FIGURA 2.9 Copiando arquivos para outro diretrio no Windows XP.

No h nessa interface uma explicao do que significa para o sistema


(conforme concebido pelo designer) cancelar a cpia em andamento. Existe
mais de uma interpretao aceitvel para o comando cancelar: (1) apenas a
operao de cpia interrompida; e (2) a operao de cpia interrompida
e seus resultados parciais so desfeitos (isto , os arquivos j copiados so
apagados do pen drive). Por no conhecer qual o significado do comando
cancelar nessa interface, Maria se sente insegura sobre o comportamento
do sistema. Para compreender o funcionamento do sistema nesse caso, ela
precisa arriscar cancelar a cpia e verificar se alguns arquivos copiados
ainda permanecem no seu pen drive. Infelizmente, nem sempre simples
verificar o funcionamento do sistema. Seria muito mais fcil e adequado o
prprio designer comunicar ao usurio (por exemplo, atravs de dicas,
instrues ou mensagens associadas ao boto cancelar) qual foi o
significado que ele atribuiu a esse comando, ou ainda oferecer diferentes
comandos para os possveis comportamentos identificados, cada qual
indicando o significado correspondente.
Reproduo de Msica
Usando a interface do reprodutor de msica Songbird, Maria tambm fica
insegura sobre seu comportamento. Ela quer ouvir as msicas de um CD,
exceto uma que lembra seu namorado porque brigou com ele h poucos
dias. Ela ento decide remover a msica da lista presente na interface do
Songbird. Conforme apresentado na Figura 2.10, ela ativa o menu pop-up, e
decide clicar em Remover. Qual ser o efeito de clicar nesse item de menu?
A msica ser removida da lista de reproduo, ser removida da
biblioteca do Songbird ou o arquivo da msica ser removido do
computador? Novamente, a interface do sistema no comunica ao usurio
o significado atribudo pelo designer a um comando, e Maria volta a ficar
insegura. Nesse caso, no compreender corretamente o significado do
comando remover pode trazer consequncias indesejadas e difceis ou
impossveis de serem revertidas, pois Maria pode perder o arquivo da
msica que lembra seu namorado. O objetivo dela no momento no
apagar o arquivo, mas ouvir apenas as outras msicas do CD agora. Essa
dvida e insegurana no aconteceriam se o designer deixasse claro o
significado do item Remover.

FIGURA 2.10 Removendo arquivo de msica no Songbird.

Problemas na comunicao das concepes e intenes do designer para o usurio se


tornam mais significativos quando tratamos de estratgias de uso da interface para
alcanar diferentes objetivos. mais difcil o usurio aprender estratgias de uso
concebidas pelo designer sem que elas lhe sejam bem comunicadas. Por exemplo,
difcil os usurios perceberem e aproveitarem as formas mais eficientes de organizar e-
mails em sistemas como Outlook e Thunderbird sem que exista uma comunicao do
designer explcita e eficiente nesse sentido. Para evitar que o sistema seja subutilizado,
de Souza (2005b) prope que o designer, alm de produzir sistemas interativos, tambm
deve apresent-los adequadamente ao usurio durante a interao. Nesse ponto de vista, a
interao humano-computador envolve a comunicao dos passos necessrios para
alcanar um objetivo, e tambm do valor de estratgias inovadoras para realizar
atividades e solucionar problemas com apoio computacional.
O conceito de comunicabilidade foi proposto pela engenharia semitica (de Souza,
2005a), teoria de IHC discutida na Seo 3.8. A comunicabilidade diz respeito
capacidade da interface de comunicar ao usurio a lgica do design: as intenes do
designer e os princpios de interao resultantes das decises tomadas durante todo o
processo de design (Prates et al., 2000a; de Souza, 2005a; de Souza e Leito, 2009).
Acreditamos que, se um usurio for capaz de compreender a lgica utilizada na
concepo do sistema interativo, ter maiores chances de fazer um uso criativo, eficiente
e produtivo dele (Prates e Barbosa, 2007; 2003).
importante observar que compreender a lgica de design no implica adquirir
conhecimentos tcnicos de design de um sistema interativo, mas sim obter uma
compreenso pragmtica e utilitria das relaes de causa e efeito que determinam seu
comportamento (de Souza, comunicao pessoal). O entendimento dessa lgica de
design permite que os usurios tirem melhor proveito da tecnologia e sigam estratgias
adequadas a cada situao de uso. Por exemplo, no precisamos conhecer a mecnica de
um automvel em profundidade para dirigi-lo. Mas fazemos melhor uso do automvel se
entendemos os riscos e as consequncias de utiliz-lo com pouca gasolina, com nvel de
leo inadequado, de dirigir em alta velocidade em pistas escorregadias, de dirigir muito
prximos do carro nossa frente etc. De modo anlogo, no precisamos saber como
funcionam os recursos de estilos de formatao ou numerao automtica de um editor
de texto para utiliz-lo, mas de posse desse conhecimento podemos fazer uso mais
eficiente dele e menos propenso a erros.
A lgica do design comunicada ao usurio deve refletir as decises tomadas sobre: a
quem se destina o sistema, para que ele serve, qual a vantagem de utiliz-lo, como ele
funciona e quais so os princpios gerais de interao com o sistema (Prates et al., 2000a;
de Souza, 2005a; de Souza e Leito, 2009). Essas questes normalmente fazem parte da
atividade de design de um sistema interativo, porm nem sempre o designer se preocupa
em comunic-las adequadamente atravs da interface com usurio. Como vimos nos
exemplos de cpia de arquivos no Windows XP e de remoo de uma msica no
Songbird, se os usurios no compreenderem a lgica de design, a interao
frequentemente se torna um processo de tentativa e erro, tedioso, ineficiente ou at
mesmo arriscado.
A analogia um recurso de comunicao utilizado para facilitar e aumentar a
comunicabilidade. Esse recurso permite ao usurio formular hipteses sobre a interao
com sistemas interativos tendo como base suas experincias de interao anteriores com
artefatos semelhantes. O uso de analogias deve contribuir para que as hipteses do
usurio sobre como interagir sejam compatveis com aquelas pretendidas pelo designer.
Contudo, importante deixar claros os limites das analogias para no induzir o usurio a
criar hipteses erradas (Exemplo 2.5).
Exemplo 2.5
U so de analogias
Analise rapidamente a interface dos dois sistemas na Figura 2.11, sem se
preocupar em ler o contedo de seus elementos textuais. O que esses
sistemas fazem? Eles so reprodutores de msica? Como voc chegou
sua concluso?

FIGURA 2.11 Interfaces do Songbird (em cima) e do Avast (embaixo, cujo texto foi
propositalmente desfocado).

Esses dois sistemas possuem botes, imagens e caractersticas


semelhantes a um CD Player fsico, no qual o usurio deve apertar botes
para controlar a reproduo (play, pause, stop, next e previous), girar um
boto para controlar o volume, pressionar o boto de eject para abrir o
compartimento de CDs, e assim por diante. Sem dvida, o uso dessa
analogia com CD Players favorece a comunicabilidade de sistemas
reprodutores de udio e vdeo. Entretanto, o que podemos dizer sobre a
comunicabilidade quando essa mesma analogia utilizada em um
programa antivrus? O Avast (o programa na parte inferior da Figura 2.11)
um programa antivrus, no um reprodutor de msica, como facilmente
poderamos interpretar analisando a interface. O designer da verso 4.7 do
Avast no foi muito feliz na escolha da analogia da interface com um CD
Player, pois cria expectativas que no pode atender e induz os usurios a
criarem vrias hipteses falsas sobre como interagir com o sistema e o que
ele capaz de fazer. Felizmente essa analogia com o CD Player j foi
abandonada em verses posteriores do Avast.
Outro recurso de comunicao que favorece a comunicabilidade oferecer mais
informaes sobre a lgica de design conforme a demanda dos usurios. Um exemplo
interessante de melhoria na comunicabilidade percebido quando comparamos as dicas
de botes da barra de ferramentas no Microsoft Office, verses XP e 2007. A Figura 2.12
apresenta a dica sobre o boto Pincel nas duas verses.

FIGURA 2.12 Dica da ferramenta de pincel no Microsoft Office (a) XP e no (b) 2007.

Enquanto a verso XP apresenta apenas o nome do comando associado ao boto, a


verso 2007 apresenta tambm o significado do comando, as teclas de atalho a ele
associadas, uma estratgia de uso para aplic-lo em mltiplos locais do documento e
informaes sobre como obter mais ajuda. Observamos uma grande melhoria na
qualidade da informao sobre a lgica de design e, consequentemente, da
comunicabilidade do sistema. Essa melhoria contribui tambm para a usabilidade do
sistema, pois ela facilita o aprendizado sobre a cpia de formato e revela as teclas de
atalho e os efeitos do duplo clique que tornam seu uso mais eficiente. Sendo assim, um
sistema com alta comunicabilidade com frequncia um sistema com alta usabilidade.
Apesar de distintos, os diversos critrios de qualidade de uso esto fortemente
interligados, influenciando uns aos outros. Por exemplo, quando uma pessoa com
deficincia visual consegue navegar sem grandes barreiras (acessibilidade) por sites na
Web e obter as informaes desejadas, sua motivao e satisfao (experincia do usurio
ou usabilidade) tendem a aumentar, porque ela se torna capaz de realizar atividades
sozinha e adquire certa independncia. Em contrapartida, mesmo que uma interface seja
acessvel, se h ambiguidade ou falta de clareza no significado dos elementos de
interface (baixa comunicabilidade), como ocorre no comando Cancelar da cpia de
arquivos no XP e no comando Remover no Songbird, a eficincia do usurio e a facilidade
de aprendizado do sistema tendem a diminuir. Alm disso, a incerteza sobre o efeito de
uma ao pode causar angstia e insatisfao aos usurios.
Em geral, quando um usurio consegue compreender como o sistema funciona porque
o designer se expressou adequadamente atravs da interface (comunicabilidade), torna-
se mais fcil aprender a utiliz-lo (usabilidade).
Ao projetarmos um sistema interativo, nem sempre possvel satisfazer igualmente
todos os critrios e aspectos envolvidos na qualidade de uso, seja por questes de tempo,
oramento ou mesmo incompatibilidade entre critrios. Sendo assim, importante
definir quais so os critrios prioritrios no sistema em questo para poder privilegi-los
no projeto de interao. A prioridade dos critrios de qualidade de uso deve ser definida
com base no conhecimento sobre os usurios (limitaes, necessidades, motivaes etc.),
suas atividades e objetivos, e contextos de uso.
Atividades
1. Fatores de Usabilidade. Identifique quais fatores de usabilidade deveriam ser
privilegiados nos seguintes casos:
um sistema para gesto dos documentos produzidos e consumidos por uma
organizao;
um quiosque de informaes em uma livraria;
um caixa eletrnico;
um sistema Web para fornecer os resultados de exames de sade a pacientes e
seus mdicos;
um jogo educacional de simulao de fenmenos fsicos (e.g., deslocamento,
acelerao e atrito).
2. Acessibilidade. Cite exemplos de sistemas interativos para os quais a acessibilidade
beneficiaria seus usurios em certas situaes. Discuta os benefcios da acessibilidade
nesses sistemas para os usurios e para a organizao responsvel pelo sistema.
3. Comunicabilidade. Na interface do Microsoft Powerpoint 2007 ou posterior, analise os
signos correspondentes ao uso da caneta (ink). Tente identificar a viso do designer
sobre para que serve esse recurso e como ele deve ser utilizado. Compare a edio de
ilustraes utilizando a caneta e utilizando formas geomtricas predefinidas (e.g.,
criao, modificao, seleo, agrupamento e deslocamento das ilustraes).
4. Critrios de qualidade de uso. Escolha alguns sistemas interativos a que voc tenha
acesso e que possa utilizar. Inspecione sua interface para analisar usabilidade,
experincia do usurio, acessibilidade e comunicabilidade, considerando diferentes
perfis de usurio:
um usurio que est utilizando o sistema pela primeira vez;
um usurio que utiliza o sistema diariamente;
um usurio que enxerga com dificuldade;
um usurio com baixo grau de instruo ou analfabeto funcional;
um usurio que tem baixo poder de concentrao;
um usurio que realiza diversas atividades ao mesmo tempo e interrompido com
frequncia;
um usurio que realiza uma tarefa longa, que precisa ser suspendida no final do
dia e retomada no dia seguinte.
2
http://sistemasenem2.inep.gov.br/Enem2009, ltimo acesso em julho de 2009.
3
http://www.planalto.gov.br/CCIVIL/_Ato2004-2006/2004/Decreto/D5296.htm.
3

Abordagens tericas em IHC


Objetivos do Captulo
Apresentar fundamentos tericos de base psicolgica, etnogrfica e semitica: leis de
Hick-Hyman e de Fitts, psicologia aplicada, princpios da Gestalt, engenharia
cognitiva, aes situadas, teoria da atividade e engenharia semitica.
Discutir como os fundamentos tericos influenciam mtodos e modelos utilizados no
projeto e avaliao da interao humano-computador.
Embora IHC seja uma rea de cunho bastante prtico, muitos dos mtodos, modelos e
tcnicas utilizados em IHC se baseiam em teorias, em particular teorias de base
psicolgica (principalmente cognitiva), etnogrfica e semitica. Conhecer essas teorias
fundamental, no apenas para melhor entender os mtodos, modelos e tcnicas
apresentados na literatura de IHC, mas tambm para saber quando utiliz-los e
identificar a necessidade de adapt-los em projetos de design particulares, seja em
domnios complexos ou envolvendo tecnologias inovadoras.
3.1 Introduo
Antes de apresentar os processos, mtodos, tcnicas, modelos e representaes,
importante introduzir seus embasamentos tericos. Este captulo apresenta abordagens
que tm feito grandes contribuies para a rea de IHC: abordagens ancoradas na
psicologia, na etnografia e na semitica.
As primeiras abordagens tericas utilizadas para investigar fenmenos de interao
humano-computador nasceram na psicologia. Nos anos 50, com nfase na psicologia
experimental, diversos modelos de informao dos processos psicolgicos surgiram para
mensurar e modelar o comportamento humano (MacKenzie, 1991). Em IHC, o interesse
nesses modelos se deve ao fato de permitirem modelar e prever o desempenho humano.
Dentre os modelos propostos, os que mais utilizamos em IHC so a lei de Hick-Hyman
para o tempo de reao de escolha (Hick, 1952; Hyman, 1953) e a lei de Fitts, para a
capacidade de processamento de informao do sistema motor humano (Fitts, 1954).
Com base principalmente na psicologia cognitiva, no incio dos anos 80, a ateno
voltou-se para os aspectos cognitivos da interao humano-computador. Dessa poca
destacam-se o modelo de processador humano de informaes (Card et al., 1983) e a
engenharia cognitiva (Norman, 1986).
No final da dcada, Suchman (1987) desafiou as abordagens de base cognitiva e trouxe
para o estudo dos fenmenos de IHC o conceito de ao situada e prticas da
etnometodologia. Dando sequncia investigao da atividade humana em contexto,
surgiram trabalhos ancorados na teoria da atividade (Bdker, 1996) e trabalhos que
ampliam a noo de cognio, como a cognio distribuda (Hollan et al., 2000).
Mais recentemente, e com base na semitica, a engenharia semitica firmou-se como
uma teoria de IHC centrada nos processos de significao e comunicao que envolvem
designers, usurios e sistemas interativos (de Souza, 2005a).
3.2 Psicologia Experimental
3.2.1 Lei De Hick-Hyman
A lei de Hick-Hyman relaciona o tempo que leva para uma pessoa tomar uma deciso
com o nmero de possveis escolhas que ela possui (Hick, 1952; Hyman, 1953). Essa lei
define que o tempo mdio, T, necessrio para escolher dentre N opes pode ser
calculado aproximadamente pelas seguintes frmulas, onde k empiricamente
determinado. Em geral, assumimos que k~150 ms:
T = k log2(N+1), caso as opes tenham igual probabilidade;
ou
T = k pi log2(1 + 1/pi), onde pi a probabilidade da alternativa i, caso as N opes
tenham probabilidades diferentes.
Em linhas gerais, a lei de Hick-Hyman indica que uma pessoa subdivide o conjunto
total de opes em categorias, eliminando aproximadamente metade das opes a cada
passo, em vez de considerar todas as escolhas uma a uma, o que requereria tempo linear.
Essa lei pode ser utilizada para fazer uma estimativa de quanto tempo uma pessoa levar
para encontrar uma dentre diversas opes disponveis numa interface, como, por
exemplo, os itens de uma lista de opes em ordem alfabtica. No entanto, caso no haja
um princpio de organizao das opes que permita ao usurio eliminar metade delas
rapidamente, essa lei no se aplica, pois a busca binria no pode ser realizada.

3.2.2 Lei De Fitts


Originada na psicologia experimental, a lei de Fitts relaciona o tempo (T) que uma pessoa
leva para apontar para algo com o tamanho (S) do objeto-alvo e com a distncia (D) entre
a mo da pessoa e esse objeto-alvo (Fitts, 1954; Figura 3.1).

FIGURA 3.1 Ilustrao da lei de Fitts.

Segundo Fitts, o tempo mdio para apontar para um alvo pode ser calculado atravs de
uma frmula como a seguir:

T = k log2(D/S + 0.5), onde a constante k~100ms determinada empiricamente e pode


variar conforme o tipo de dispositivo utilizado.

Variaes dessa lei1 so utilizadas para modelar o tempo que leva para um mouse ou
outro dispositivo de entrada semelhante atingir um objeto numa tela.
Importante para aplicaes em que o desempenho crtico, a lei de Fitts ajuda os
designers a decidirem sobre o tamanho e a localizao de elementos de interface com os
quais o usurio precisa interagir. Essa lei pode ser considerada em diversas situaes de
design (Tognazzini, 1999).
Um boto de acionamento de operao pode possuir ambos, imagem e rtulo. Quando
o usurio j conhece o boto, o rtulo poderia ser dispensado. Porm, sua presena torna
o boto maior e, portanto, seu acesso mais rpido (Figura 3.2).

FIGURA 3.2 Botes com somente rtulo ou com rtulo e imagem.

Uma palheta de ferramentas deve ser posicionada ao longo de um lado da tela. Tal
posicionamento permite que um deslocamento indefinidamente longo naquela direo
acerte o alvo. Quando h uma palheta com poucas ferramentas, a lei de Fitts indica que
melhor organiz-las em uma nica coluna ou linha, ao longo de um lado da tela, do que
distribu-las em duas ou mais colunas ou linhas (Figura 3.3).

FIGURA 3.3 Posicionamento de palheta de ferramentas num lado da tela.

No sistema operacional Mac OS, o menu de uma aplicao fica sempre no topo da
tela, e no no topo de cada janela, como no Microsoft Windows. O acesso ao menu no
topo da tela , em mdia, em torno de cinco vezes mais rpido do que um menu
semelhante em uma aplicao Windows (Figura 3.4).
FIGURA 3.4 Posicionamento do menu no topo da tela e no topo da janela.

Um menu pop-up circular (pie menu) tem como vantagem sobre um menu pop-up
horizontal o fato de que todas as opes esto equidistantes e prximas do ponto em que
o menu foi acionado (Figura 3.5).

FIGURA 3.5 Menu pop-up circular.


3.3 Psicologia Cognitiva Aplicada
Card, Moran e Newell (1983) propuseram uma psicologia aplicada de processamento de
informao. Segundo eles, a interao humano-computador consiste em o usurio e o
computador se engajarem num dilogo comunicativo com o objetivo de realizar alguma
tarefa. E todos os mecanismos utilizados nesse dilogo constituem a interface: os
dispositivos fsicos, como os teclados e as telas, assim como os programas
computacionais que controlam a interao. Seu objetivo era criar uma psicologia baseada
em anlise de tarefas, clculos e aproximaes, para que o designer do sistema pudesse
alcanar um equilbrio entre parmetros computacionais de desempenho humano e
outras variveis de engenharia.
Para eles, a anlise da estrutura da tarefa oferece grande parte do contedo preditivo
da psicologia. Uma vez que conheamos os objetivos das pessoas, e considerando suas
limitaes de percepo e de processamento de informao, devemos poder fornecer
respostas a perguntas do tipo: aproximadamente quanto tempo leva para uma pessoa
realizar as tarefas fsicas predefinidas que lhe permitem alcanar seus objetivos?

3.3.1 Processador Humano De Informao


Com base na psicologia de processamento de informaes, Card, Moran e Newell (1983)
propuseram o processador humano modelo de informaes (Model Human Processor,
MHP). Segundo eles, o uso de modelos que veem o ser humano como um processador de
informaes fornece um arcabouo comum nos quais modelos de memria, de resoluo
de problemas, de percepo e de comportamento podem ser integrados uns com os
outros. Considerando a mente humana como um sistema de processamento de
informaes, possvel fazer predies aproximadas de parte do comportamento
humano.
O MHP composto de trs subsistemas, cada qual com suas prprias memrias e
processadores, juntamente com alguns princpios de operao (Figura 3.6): o perceptivo,
o motor e o cognitivo.
FIGURA 3.6 Modelo do Processador Humano de Informaes (adaptado de Card et al., 1983).

O sistema perceptivo transmite as sensaes do mundo fsico detectadas pelos


sistemas sensoriais do corpo (viso, audio, tato, olfato, paladar) para representaes
mentais internas. A viso central, a viso perifrica, os movimentos dos olhos e os
movimentos da cabea operam como um sistema integrado para nos fornecer uma
representao contnua da cena visual de interesse. Essas sensaes so armazenadas
temporariamente em reas de memria sensorial (principalmente nas memrias visual e
auditiva), ainda codificadas fisicamente e com um tempo de decaimento (ou
esquecimento) rpido, conforme a intensidade do estmulo. Em seguida, algumas dessas
sensaes so codificadas simbolicamente e armazenadas na memria de trabalho.
O processador cognitivo pode especificar quais contedos das memrias sensoriais
devem ser codificadas simbolicamente e armazenadas na memria de trabalho,
principalmente quando o contedo da memria perceptiva for complexo ou percebido
apenas por um perodo de tempo muito curto. O sistema cognitivo recebe a informao
codificada simbolicamente dos armazenamentos sensoriais na sua memria de trabalho
e utiliza informaes previamente armazenadas na memria de longo prazo para tomar
decises sobre como responder aos estmulos recebidos.
Nosso pensamento traduzido em ao atravs da ativao de padres de msculos
voluntrios, em uma srie de micromovimentos discretos realizados pelo sistema motor.
Com relao s memrias, os parmetros a serem considerados so: a capacidade de
armazenamento em nmero de itens, o tempo de decaimento (no caso, o tempo para o
esquecimento) de um item e o tipo de cdigo principal (fsico, acstico, visual ou
semntico). J com relao aos processadores, o parmetro mais importante o tempo do
ciclo.
Para algumas tarefas, uma pessoa precisa se comportar como um processador serial,
ou seja, realizar uma tarefa de cada vez. Um exemplo desse tipo de tarefa pressionar
uma tecla em resposta a um estmulo visual, tal como o acendimento de uma lmpada.
Para outras tarefas, possvel que haja uma operao integrada e paralela dos trs
subsistemas, com informao fluindo continuamente da entrada sada, em um perodo
de tempo to curto que todos os processadores trabalham simultaneamente. Por
exemplo, digitao, leitura e traduo simultnea so tarefas desse tipo (Card et al., 1983).
Nas tarefas mais simples, o sistema cognitivo serve apenas para conectar as entradas
do sistema perceptual s sadas adequadas do sistema motor. Mas a maioria das tarefas
complexa e envolve aprendizado, recuperao de fatos ou soluo de problemas. A
memria de trabalho retm informaes em uso, e a memria de longo prazo armazena
conhecimento para uso futuro. Os elementos ativados da memria de longo prazo
consistem em smbolos ou grupos de smbolos, chamados de chunks (elementos de
informao). O contedo de um chunk depende da tarefa, da pessoa e do contedo da sua
memria de longo prazo. Quando um chunk na memria de longo prazo ativado, essa
ativao se espalha para chunks relacionados (e.g., de um livro para a livraria onde foi
comprado, para a viagem em que foi comprado, para as fotos que foram tiradas etc.).
Miller (1956) mostrou que a capacidade da memria de trabalho limitada a 7 2 chunks.
Como ela limitada, medida que novos chunks so ativados, outros chunks que se
encontram na memria de trabalho tornam-se menos acessveis. Os itens armazenados
tm uma determinada probabilidade de poderem ser recuperados mais tarde da
memria de longo prazo. Quanto mais associaes um item tiver ao ser armazenado,
maior a probabilidade de ele ser recuperado. Se uma pessoa quer poder se lembrar de
alguma coisa mais tarde, a melhor estratgia tentar associ-la a itens que j esto na
memria de longo prazo.
Card e coautores (1983) calcularam o perodo de tempo aproximado do ciclo t para
diversas tarefas comuns realizadas por pessoas com diferentes nveis de habilidades.
Eles mostraram como sua abordagem permite calcular a taxa de quadros em uma
animao necessria para criar a iluso de movimento, a taxa mxima de recepo de
cdigo Morse para permitir a sua decodificao por uma pessoa, o tempo entre dois
eventos para manter uma iluso de causalidade e o tempo que uma pessoa leva para ler
um texto. Ainda com base no MHP, eles elaboraram um modelo de decomposio de
tarefas chamado GOMS, amplamente utilizado at hoje em anlise e design da interao
humano-computador. O modelo GOMS descrito na Seo 6.4.2.

3.3.2 Princpios De Gestalt


Segundo Ware (2003), muito da nossa inteligncia pode ser caracterizada pela nossa
capacidade de identificar padres, e o sistema visual o nosso mecanismo de
reconhecimento de padres mais sofisticado. Ware destaca que um objetivo primrio do
design de representaes visuais deve ser mapear dados numa forma visual compatvel
com as nossas capacidades perceptivas.
A escola de psicologia gestltica foi fundada em 1912, e dentre seus principais
pesquisadores encontram-se Wesheimer, Koffka e Kohler (Ware, 2003). Eles produziram
um conjunto de leis de percepo de padres, denominadas leis gestlticas ou
simplesmente de Gestalt (Figura 3.7):
proximidade: as entidades visuais que esto prximas umas das outras so percebidas
como um grupo ou unidade;
boa continuidade: traos contnuos so percebidos mais prontamente do que
contornos que mudem de direo rapidamente;
simetria: objetos simtricos so mais prontamente percebidos do que objetos
assimtricos;
similaridade: objetos semelhantes so percebidos como um grupo;
destino comum: objetos com a mesma direo de movimento so percebidos como um
grupo;
fecho: a mente tende a fechar contornos para completar figuras regulares,
completando as falhas e aumentando a regularidade.

FIGURA 3.7 Ilustrao de princpios gestlticos comumente considerados.

De acordo com Ware (2003), podemos considerar como adies recentes s leis de
Gestalt as seguintes (Figura 3.8):
regio comum: objetos dentro de uma regio espacial confinada so percebidos como
um grupo (Palmer, 1992);
conectividade: objetos conectados por traos contnuos so percebidos como
relacionados (Palmer e Rock, 1994).

FIGURA 3.8 Ilustrao dos princpios gestlticos de regio comum e conectividade.


3.3.3 Percepo de Cores
Estudos sobre a percepo de cores e luminncia resultaram em diversas diretrizes de
design que podem ser utilizadas no projeto de interfaces com usurio.
Com relao percepo de luminncia, que, grosso modo, a nossa capacidade de
perceber padres de tons de cinza, aprendemos que o contraste ideal para texto deve
respeitar uma razo de 10:1 entre claro e escuro. O conceito de cores opostas explica por
que as cores vermelho, verde, amarelo, azul, preto e branco so especiais em todas as
sociedades investigadas. Isso significa que, caso seja necessrio utilizar cdigos de cores
para categorizar informaes visuais, essas cores devem ser utilizadas em primeiro lugar.
Entretanto, a semntica atribuda a uma determinada cor varia amplamente. Por
exemplo, vermelho p ode significar um alerta de perigo ou boa sorte (Ware, 2003).
Ware ressalta que algumas caractersticas visuais so prontamente entendidas sem
treinamento prvio. Se pedirmos para diversas pessoas ordenarem um conjunto de
amostras de diferentes tons de cinza, todas utilizaro a mesma ordenao (ou a
ordenao contrria), sem qualquer instruo adicional (Figura 3.9).

FIGURA 3.9 Ordenao de valores caracterizada por diferentes tons de cinza.

Cor, forma, movimentos simples e profundidade estereoscpica so caractersticas pr-


atencionais, ou seja, caractersticas processadas antes que uma pessoa volte sua ateno a
elas, antes que se tornem conscientes. Essas caractersticas so processadas
simultaneamente, fazendo com que alguns elementos visuais se destaquem
imediatamente de sua vizinhana. Como h limitaes sobre o que pode ser percebido de
modo pr-atencional, importante que um smbolo que deva ser destacado tenha algum
atributo bsico distinto dos seus smbolos vizinhos (Ware, 2003). Considerando as leis de
Gestalt, Ware sugere que a apresentao de dados seja elaborada de modo a tornar
padres fceis de se perceber, para facilitar a resoluo de problemas. No entanto, ele
observa que, alm dos mecanismos perceptivos inatos aos seres humanos, existem
fatores culturais que influenciam a percepo de elementos visuais. Alm disso,
diferentes representaes podem enviesar a interpretao das pessoas na direo de
certas solues para um problema, em detrimento a outras. Por exemplo, uma tabela, um
grafo e um mapa enfocam diferentes aspectos de uma regio geogrfica.
3.4 Engenharia Cognitiva
A engenharia cognitiva foi concebida por Donald Norman em 1986 como uma tentativa
de aplicar conhecimentos de cincia cognitiva, psicologia cognitiva e fatores humanos ao
design e construo de sistemas computacionais. Os principais objetivos de Norman
eram:
entender os princpios fundamentais da ao e desempenho humano relevantes para o
desenvolvimento de princpios de design;
elaborar sistemas que sejam agradveis de usar e que engajem os usurios at de
forma prazerosa.
Em outras palavras, Norman visava a entender as questes envolvidas no design de
sistemas computacionais, mostrar como fazer melhores escolhas de design e mostrar
quais so os tradeoffs quando uma melhoria em um aspecto leva a uma piora em outro.
Na base da engenharia cognitiva est a discrepncia entre os objetivos expressos
psicologicamente e os controles e variveis fsicos de uma tarefa. Uma pessoa inicia com
objetivos e intenes, que so variveis psicolgicas, pois existem apenas na mente da
pessoa e se relacionam diretamente s suas necessidades e sua situao atual.
Entretanto, a tarefa deve ser realizada em um sistema fsico, com controles fsicos a serem
manipulados, resultando em mudanas nas variveis fsicas e no estado do sistema.
Assim, uma pessoa precisa interpretar as variveis fsicas em termos relevantes aos
objetivos psicolgicos, e precisa traduzir as suas intenes psicolgicas em aes fsicas
sobre os controles e mecanismos do sistema. Isso significa que deve haver um estgio de
interpretao que relaciona as variveis fsicas e psicolgicas, assim como funes que
relacionem a manipulao das variveis fsicas e a mudana resultante no estado fsico
(Figura 3.10).

FIGURA 3.10 Discrepncia entre o mundo psicolgico e o mundo fsico.

Em muitas situaes, as variveis que podem ser facilmente controladas no so


aquelas pelas quais a pessoa se interessa. Por exemplo, numa torneira convencional, as
variveis fsicas que podem ser manipuladas so: fluxo de gua fria e fluxo de gua
quente. No entanto, o usurio quer controlar duas variveis distintas: o fluxo total de
gua e a temperatura da gua. Nesse caso, podemos levantar as seguintes questes:
problemas de mapeamento (Figura 3.11a): Qual o controle de gua quente e qual o
de gua fria? De que maneira cada controle deve ser girado para aumentar ou reduzir
o fluxo da gua?

FIGURA 3.11 Ilustraes de diferentes torneiras para exemplificar problemas de mapeamento, dificuldade de
controle e dificuldade de avaliao.

dificuldade de controle (Figura 3.11b): Para aumentar a temperatura da gua mantendo


o fluxo constante, necessrio manipular simultaneamente as duas torneiras.
dificuldade de avaliao (Figura 3.11c): Quando h dois bicos de torneira, s vezes se
torna difcil avaliar se o resultado desejado foi alcanado.
Hoje em dia, h torneiras com um controle nico, em que uma dimenso de
movimento controla o fluxo total da gua e outra dimenso (ortogonal) controla a sua
temperatura (Figura 3.12). Apesar de o mapeamento no ser bvio necessrio ainda
aprender qual dimenso controla qual varivel , uma soluo melhor, pois as variveis
sendo manipuladas fisicamente so as mesmas variveis de interesse.

FIGURA 3.12 Ilustrao de uma torneira com monocomando.

Exemplo 3.1
M apeamento, controle e avaliao em dilogos
para seleo de cor.
Em sistemas computacionais, temos problemas semelhantes. Suponha que
queiramos escolher uma cor de fundo para uma ilustrao, e que o dilogo
apresentado seja o da Figura 3.13a. Para definir uma cor de fundo,
necessrio indicar os valores das componentes vermelha (red R), verde
(green G) e azul (blue B). No entanto, a Figura 3.13a no deixa claro qual
controle est associado a qual componente, o que consiste num problema de
mapeamento. Alm disso, geralmente estamos interessados na matiz da cor
(hue H), na sua saturao (saturation S, grau de mesclagem da matiz
com a cor branca, tambm denominado grau de pureza) e na sua
luminosidade (luminance L, frao da cor que vai do completamente
escuro ao completamente claro). Como no podemos definir valores para
essas propriedades, identificamos tambm um problema de dificuldade de
controle. Finalmente, no h uma resposta visual da cor resultante, o que
dificulta a avaliao do resultado.

FIGURA 3.13 Dilogos para escolha de cores ilustrando problemas de mapeamento, controle
e avaliao.

A Figura 3.13b apresenta o dilogo modificado. Nele, observamos


claramente o mapeamento, por proximidade, das componentes R, G e B aos
controles correspondentes, assim como uma indicao visual da cor
resultante, reduzindo ento os problemas de mapeamento e avaliao. A
dificuldade de controle das variveis de interesse (H, S, L), no entanto,
permanece.
A Figura 3.14 apresenta o dilogo padro da ferramenta Microsoft Visual
Studio para a escolha de cores. Podemos observar que esse dilogo
permite a definio de cores utilizando tanto as componentes R, G e B,
quanto as componentes H, S e L, reduzindo o problema de mapeamento.
Alm disso, possvel selecionar diretamente nos quadros de cores as
componentes H (atravs do deslocamento horizontal no quadro maior), S
(atravs do deslocamento vertical no quadro maior) e L (atravs do
deslocamento na barra vertical), reduzindo assim a dificuldade de controle.
FIGURA 3.14 Dilogo padro da ferramenta Microsoft Visual Studio para a escolha de cores.

Para melhor caracterizar o papel das questes de mapeamento, controle e avaliao na


interao humano-computador, Norman elaborou uma teoria da ao, descrita a seguir.

Teoria da Ao
A abordagem de projeto centrado no usurio estuda os fenmenos que ocorrem durante
a interao de um usurio com um artefato cognitivo (Norman, 1991). Um artefato
cognitivo um dispositivo artificial projetado para manter, apresentar ou manipular
informao. Um aspecto importante de um artefato cognitivo se refere ao quanto a
interao direta e envolvente. Todo artefato atua como um mediador entre as pessoas e
o mundo.
Norman props uma teoria da ao que distingue diversos estgios de atividade
ocorridos durante a interao usuriosistema. No mbito da engenharia cognitiva, a
principal questo a discrepncia entre as variveis psicolgicas (objetivos das pessoas)
e os controles e variveis fsicos (mecanismos de interao e estados do sistema).
Norman representa essa discrepncia atravs de dois golfos que precisam ser superados
ou atravessados: o golfo de execuo e o golfo de avaliao, conforme ilustrado pela
Figura 3.15. Em outras palavras, o processo de interao com um artefato pode ser visto
como ciclos de ao envolvendo fases de execuo e de avaliao, alternadamente.
FIGURA 3.15 Golfos de execuo e de avaliao que o usurio precisa atravessar ao interagir com um sistema
fsico.

Segundo Norman, o golfo de execuo se refere dificuldade de atuar sobre o


ambiente e ao grau de sucesso com que o artefato apoia essas aes. O golfo de avaliao,
por sua vez, se refere dificuldade de avaliar o estado do ambiente e ao grau de sucesso
com que o artefato apoia a deteco e interpretao desse estado. Tais golfos podem ser
reduzidos atravs de um projeto adequado do artefato ou atravs de treinamento e
esforo mental por parte de seus usurios. A Figura 3.16 ilustra os processos fsicos e
cognitivos que ocorrem na travessia de cada golfo.

FIGURA 3.16 Estgios de atividade do usurio na travessia dos golfos de execuo e de avaliao (adaptado de
Norman, 1986, p. 42).

Segundo Norman, o ciclo se inicia na fase de execuo, quando o usurio estabelece


um objetivo de alto nvel, ou seja, um estado do mundo que ele deseja alcanar atravs
da interao com o sistema (e.g., produzir um documento esteticamente agradvel). Uma
vez estabelecido um objetivo, o usurio precisa formular sua inteno, que a deciso de
agir em direo ao objetivo, estabelecendo um subobjetivo que ele poder alcanar
diretamente atravs do uso do sistema. Ao formular uma inteno, o usurio escolhe
uma estratgia para alcanar seu objetivo, influenciado no apenas pelo prprio objetivo,
mas tambm pela sua experincia com aquele sistema e com outros sistemas
computacionais em geral (e.g., definir uma cor especfica para uma forma geomtrica, em
vez de selecionar uma das cores padro).
A partir da inteno formulada, o usurio deve especificar as aes a serem realizadas,
ou seja, determinar quais configuraes das variveis do sistema correspondem ao estado
desejado (e.g., cor verde oliva definida pelas variveis H=58, S=99, L=77) e quais
mecanismos de controle levam a esse estado (e.g., qual dilogo acionar, quais campos
preencher, quais controles manipular [e como], em quais botes clicar). Especificar as
aes envolve um exerccio de planejamento do usurio cujo resultado uma
representao mental de quais aes devem ser executadas sobre a interface, e em que
ordem.
De posse dessa especificao, o usurio deve executar as aes planejadas, seguindo a
ordem especificada. Isso significa manipular dispositivos de entrada da interface (e.g.,
levar o cursor do mouse para a forma geomtrica desejada, clicar com o boto da direita
para acionar o menu pop-up, levar o cursor do mouse para o item cor de fundo do
menu pop-up, clicar com o boto esquerdo do mouse sobre esse item, levar o mouse para
a caixa de texto H, clicar sobre essa caixa de texto, digitar 58, pressionar a tecla Tab para
levar o foco da interao para a caixa de texto S, e assim por diante).
Vale observar que a escolha dos dispositivos de entrada a serem utilizados determina
no apenas quais so as aes fsicas necessrias, mas tambm influencia a qualidade de
uso de acordo com a habilidade do usurio em manipular aquele dispositivo para
executar as aes. Por exemplo, uma ao que exija do usurio pressionar duas teclas
enquanto ele move o mouse mantendo simultaneamente o boto direito do mouse
pressionado pode ser difcil para muitos usurios.
A cada ao executada, o sistema modifica seu estado e atualiza sua interface,
apresentada atravs dos dispositivos de sada, para refletir o novo estado. Nesse
momento o usurio comea a fase de avaliao. Ela se inicia pela percepo, por parte do
usurio, da mudana de estado da interface (e.g., a cor da imagem de pr-visualizao
alterada). Caso o sistema no realize nenhuma mudana na interface, faa uma mudana
imperceptvel ao usurio, ou demore muito, o que o usurio percebe uma ausncia de
resposta do sistema, que influenciar negativamente sua interpretao.
Aps perceber o novo estado da interface, o usurio inicia uma atividade de
interpretao, na qual busca atribuir um significado ao novo estado do sistema tal como
percebido atravs dos seus dispositivos de sada (e.g., a nova cor da imagem de pr-
visualizao reflete o novo valor de H informado pelo usurio). Essa interpretao
guiada pelos mapeamentos que o usurio tenha feito entre as variveis (mentais) de
interesse e as variveis (fsicas) do sistema. Uma ausncia de resposta geralmente
interpretada como nada aconteceu, como se as aes no tivessem sido de fato
executadas.
Finalmente, o ciclo se fecha com a avaliao do novo estado do sistema, tal como
interpretado, comparando-o com o estado desejado (correspondente inteno
formulada e ao objetivo almejado). O resultado da avaliao determina se as aes
realizadas contriburam para o usurio se aproximar do seu objetivo ou no. Caso o
resultado da avaliao determine que o estado interpretado corresponde ao estado
desejado, o usurio atingiu seu objetivo. Caso contrrio, o usurio precisaria percorrer
novamente o ciclo, retificando uma ou mais das atividades realizadas, a fim de atingir seu
objetivo original. possvel que, aps percorrer o ciclo uma ou mais vezes, obtendo
avaliaes malsucedidas, o usurio considere que no h como atingir o objetivo original
e passe a considerar um outro objetivo, ou at mesmo desista de atingir seus objetivos
naquele momento.
Nem sempre a travessia dos golfos iniciada pelo golfo de execuo. Um usurio cuja
atividade envolva monitorar alguma operao fica observando a sada do sistema at
perceber que houve uma mudana. Quando alguma mudana ocorrer, o usurio deve
diagnostic-la e tomar as providncias necessrias, percorrendo os golfos de execuo e
avaliao. Nesse caso, a avaliao inclui no apenas verificar se as aes desejadas foram
executadas adequadamente e as intenes satisfeitas, mas se o diagnstico original foi
adequado.

Exemplo 3.2
T ravessia dos golfos de execuo e avaliao
Considerando o dilogo apresentado na Figura 3.14, a travessia dos golfos
de execuo e de avaliao para o exemplo de mudana de cor de fundo de
um objeto selecionado pode ser ilustrada pelos passos a seguir:
estabelecimento do objetivo: mudar a cor de fundo do retngulo
selecionado.
formulao da inteno: definir uma cor verde oliva com os valores
H=58, S=99, L=77.
especificao das aes:
1. acionar o item de menu Formatar > Cor de fundo;
2. informar o valor 58 para a componente H;
3. informar o valor 99 para a componente S;
4. informar o valor 77 para a componente L;
5. confirmar a cor definida pelos valores informados.
execuo (ao n1): aciono o item de menu Formatar > Cor de fundo
utilizando o mouse.
percepo: observei que apareceu uma janela de dilogo.
interpretao: o ttulo da janela de dilogo Selecionar cor , e h
controles de definio de cada componente de cor individual.
avaliao: me aproximei do meu objetivo. A especificao de aes
parece correta e, portanto, posso prosseguir para o prximo passo..
execuo (ao n2): informo o valor 58 para a componente H,
digitando esse valor na caixa de texto correspondente.
percepo: o valor na caixa de texto correspondente componente H
mudou, assim como a cor da imagem de pr-visualizao.
interpretao: o novo valor corresponde ao valor digitado.
avaliao: me aproximei do meu objetivo. A especificao de aes
parece correta e, portanto, posso prosseguir para o prximo passo.
execuo (ao n3): informo o valor 99 para a componente S, digitando
esse valor na caixa de texto correspondente.
percepo: o valor na caixa de texto correspondente componente S
mudou, assim como a cor da imagem de pr-visualizao.
interpretao: o novo valor corresponde ao valor digitado.
avaliao: me aproximei do meu objetivo. A especificao de aes
parece correta e, portanto, posso prosseguir para o prximo passo.
execuo (ao n4): informo o valor 77 para a componente L, digitando
esse valor na caixa de texto correspondente.
percepo: o valor na caixa de texto correspondente componente L
mudou, assim como a cor da imagem de pr-visualizao.
interpretao: o novo valor corresponde ao valor digitado e a cor da
imagem de pr-visualizao corresponde cor desejada.
avaliao: me aproximei do meu objetivo. A especificao de aes
parece correta e, portanto, posso prosseguir para o prximo passo.
execuo (ao n5): confirmo a cor definida pelos valores informados,
clicando em OK.
percepo: a janela de dilogo foi ocultada; a cor do retngulo mudou.
interpretao: a nova cor do retngulo verde oliva.
avaliao: alcancei meu objetivo.

O designer do sistema deve tentar abreviar os golfos de execuo e de avaliao que


precisam ser atravessados pelo usurio a fim de reduzir os problemas que ocorrem
durante a interao. O mapeamento adequado das variveis de interesse envolvidas na
tarefa do usurio para variveis fsicas do sistema contribui para a travessia de ambos os
golfos. Mecanismos e controles de interao (elementos de interface) para manipular
dados de entrada e a representao desses dados contribuem para abreviar o golfo de
execuo. De modo semelhante, a representao dos dados de sada e as mensagens de
resposta do sistema (feedback) contribuem para abreviar o golfo de avaliao. Outra
maneira de auxiliar o usurio a atravessar os golfos fornecer-lhe treinamento e
oportunidades de adquirir experincia no uso de um sistema. Entretanto, cabe ao
designer tentar reduzir essa necessidade de treinamento tanto quanto possvel.
A engenharia cognitiva considera trs modelos, dois mentais e um fsico (Figura 3.17):
o modelo de design, a imagem do sistema, e o modelo do usurio.

FIGURA 3.17 Modelos considerados pela engenharia cognitiva (adaptado de Norman, 1986, p. 46).

O modelo de design o modelo conceitual do sistema tal como concebido pelo


designer. Ele descreve a lgica de funcionamento do sistema que ser construdo. O
modelo de design deve se basear em tarefas, requisitos, capacidades e experincia do
usurio. Deve considerar tambm as capacidades e limitaes dos mecanismos de
processamento de informao do usurio, em particular limitaes nos recursos de
processamento e de memria de curto prazo.
A imagem do sistema corresponde ao sistema executvel, isto , o modelo fsico
construdo com base no modelo conceitual de design, e a partir do qual os usurios
elaboram seus modelos conceituais (modelo do usurio).
O modelo do usurio o modelo conceitual construdo por ele durante sua interao
com o sistema,2 resultando assim da sua interpretao da imagem do sistema. Tudo o que
o designer construir na imagem do sistema pode auxiliar ou prejudicar essa
interpretao, tal como: elementos de interface (widgets) para entrada e sada de dados;
documentao, instrues, ajuda on-line e mensagens de erro.
O objetivo do designer que o usurio seja capaz de elaborar um modelo conceitual
compatvel com o modelo de design atravs da sua interao com a imagem do sistema.
Para isso, o designer dever produzir uma imagem de sistema explcita, inteligvel e
consistente.
Podemos observar que, como o foco da engenharia cognitiva est nos processos
psicolgicos do usurio, o trabalho do designer se torna to mais desafiador quanto mais
heterognea for a populao de usurios-alvo em termos de suas caractersticas,
necessidades e atividades. Por exemplo, um usurio com pouca experincia se beneficia
de uma interface de assistente (wizard), ao passo que um usurio especializado requer
uma interface mais eficiente. Cabe ao designer tentar elaborar uma interface que concilie
essas diferentes necessidades.
3.5 Abordagens Etnometodolgicas
Suchman (1987) foi pioneira ao trazer para a pesquisa em IHC a viso da antropologia
etnogrfica de que o significado e o valor da ao humana so situados, ou seja, tm uma
relao essencial com as suas circunstncias concretas particulares e com suas interaes
dinmicas com o mundo material e social. Ao fazer isso, ela deslocou o foco do usurio
individual para o contexto social do uso do computador e desafiou a viso de aes
intencionais dominante na poca: a de ao planejada.
Para a viso de ao planejada, a ao humana pode ser completamente caracterizada
em termos de seus objetivos, intenes e planos. Para entender como as pessoas agem,
bastaria entender como elas seguem um plano predefinido. Em geral, os trabalhos de
anlise do desempenho dos usurios que enfocam a estrutura de suas tarefas (i.e., a
partir da decomposio de objetivos em tarefas e operaes) se encaixam nessa viso.
Esta favorece o pensamento analtico abstrato, no qual a organizao, o significado e o
valor da ao humana esto nos planos subjacentes, definidos a priori.
Um plano uma sequncia de aes projetada para alcanar algum objetivo. Dado um
objetivo e uma situao inicial, uma pessoa constri um plano e ento realiza as aes
definidas nesse plano. As aes so descritas em detalhes pelas suas precondies ou
pr-requisitos (aquilo que precisa ser verdadeiro para que a ao seja possvel) e
consequncias ou efeitos (o que precisa ser verdadeiro aps a ao ser executada). Nessa
viso, as condies para a execuo de uma ao so definidas a priori, e a atividade
humana considerada uma forma de resoluo de problemas, na qual o ator deve
encontrar um caminho de algum estado inicial para algum estado final desejado, dadas
algumas condies ao longo do caminho (cf. Newell e Simon, 1972). Qualquer condio
imprevista, ou seja, que no esteja de acordo com o plano, requer um replanejamento.
J na viso de ao situada, defendida por Suchman, a cada instante feita uma
avaliao das circunstncias concretas particulares e do valor das aes mediante a essas
contingncias. luz dessas contingncias que as pessoas constroem e se engajam nas
suas aes sociais e em suas interaes umas com as outras. Essas contingncias no
podem ser completamente previstas com antecedncia nem se mantm estveis ao longo
do tempo. Portanto, no possvel projetar em detalhes como um comportamento vai se
desdobrar antes que os participantes se engajem nas suas interaes sociais (Button,
2003).
Em outras palavras, um plano no pode determinar o curso de aes de uma pessoa,
como prope a viso de ao planejada. Todo curso de ao depende das circunstncias
materiais e sociais em que ocorre. Em vez de tentar abstrair a ao das suas
circunstncias e represent-la como um plano racional, a abordagem de aes situadas
consiste em estudar como as pessoas usam suas circunstncias para atingir seus
objetivos.
A etnometodologia foi proposta por Harold Garfinkel na dcada de 1960. Ela considera
que o significado, o valor e a forma de se compreenderem as aes no se encontram de
forma isolada, nem no que estritamente observvel do comportamento, nem num
estado mental prvio do ator, mas sim numa relao construda de forma contingencial
entre o comportamento observvel, as circunstncias em que ele ocorre, as intenes dos
atores presentes nas situaes observadas e os relacionamentos entre esses atores. Em
outras palavras, a etnometodologia examina processos interacionais (de comunicao
entre as pessoas) e circunstanciais (Garfinkel, 1967).
Suchman busca identificar os recursos (cognitivos e de interao) que possibilitam a
comunicao humana bem-sucedida. Para ela, o fato de as pessoas conseguirem se
entender (i.e., alcanar a inteligibilidade mtua) em suas interaes cotidianas sempre
o produto de trabalho colaborativo situado, s vezes sem esforo aparente, outras a partir
de trabalho evidente. Ela destaca que a comunicao face a face inclui naturalmente
recursos para detectar e remediar problemas no entendimento.
A comunicao humana segue a mxima geral de que as falas devem ser projetadas
especificamente para os seus receptores e para a ocasio em que so emitidas. Ela deve
ser sensvel s circunstncias e aos recursos locais para a remediao de problemas no
entendimento que inevitavelmente surgem. Nesse sentido, a comunicao humana difere
de um manual instrucional impresso, no qual h uma desassociao entre a ocasio de
sua produo e a ocasio do seu uso. O manual impresso no voltado a cada receptor
especfico. J um sistema computacional interativo tem potencial de se afastar do design
instrucional do manual impresso e de se aproximar do instrutor humano, que utiliza
recursos possibilitados pela interao presencial (Suchman, 1987).
A etnometodologia explorou a produo situada da ordem social atravs de dois
domnios de interesse: anlise da conversao e estudos etnometodolgicos do trabalho.
As prximas subsees examinam conceitos de anlise da conversao e indicam como
aspectos da comunicao humana podem ser utilizados para descrever e analisar a
comunicao usuriosistema.

3.5.1 Anlise Da Conversao


A anlise da conversao descreve a forma como uma conversa organizada pelos
participantes a cada momento, durante o desdobramento de cada turno de fala
(Schegloff, 1972; Schegloff e Sacks, 1973).
A conversao caracterizada por mecanismos projetados para apoiar o controle local
sobre o desenrolar de tpicos ou atividades, maximizar a acomodao de circunstncias
imprevistas que venham a ocorrer e identificar e remediar eventuais problemas na
comunicao. Dessa forma, a anlise da conversao tambm enfatiza a natureza situada
das trocas conversacionais.
O controle local est relacionado distribuio de turnos de fala e direo do assunto
abordado. Isso significa que durante a conversao os participantes decidem quem fala
sobre o que e quando, construindo colaborativamente a conversa. Sacks, Schegloff e
Jefferson (1974) delinearam um conjunto de convenes ou regras sobre a troca de
turnos que descrevem prticas comuns observadas por analistas da conversao. No
curso de uma conversa, quando uma fala puder ser considerada concluda, ocorre um dos
seguintes eventos:
o falante atual seleciona o prximo falante (e.g., direcionando uma pergunta ou outra
fala a um ouvinte particular);
um outro participante se autosseleciona para comear a falar;
o falante atual continua.
O falante atual deve deixar claro para os ouvintes em que ponto est seu turno: se ele
est no meio do turno, ou se o turno se encerrou. No entanto, o falante no define o
turno unilateralmente. A concluso de um turno representa tanto uma inclinao do
ouvinte em responder quanto a disposio do falante em ceder o turno. As fronteiras de
um turno so mutveis, e a estrutura da conversao elaborada localmente pelos
falantes e ouvintes. Em outras palavras, o turno essencialmente determinado pela
interao entre os participantes ao longo da conversao. Por exemplo, o silncio numa
fala pode ser considerado uma simples pausa no meio de um turno, no qual o falante
quer prosseguir falando, ou uma concluso do turno, quando um ouvinte cr que pode
tomar o turno para si.
Segundo Schegloff (1972), geralmente uma conversa coerente aquela em que cada
coisa dita pode ser tida como relevante, considerando o que veio antes. Isso significa que
a relevncia de um turno condicionada pelo turno que imediatamente o precedeu. Duas
falas numa relao de relevncia condicional constituem um par adjacente (Schegloff e
Sacks, 1973). Uma fala que seja considerada como a primeira parte de um par adjacente
estabelece uma expectativa com relao ao que deve vir em seguida, e orienta a forma
como a fala seguinte ouvida. Tanto a presena como a ausncia de uma segunda parte
esperada so significativas (Exemplo 3.3).

Exemplo 3.3
P ares adjacentes em uma conversa
Considere um dilogo entre um vendedor (V) e um comprador (C), numa
livraria, como a seguir:
V: Bom dia! Como posso ajud-lo?
C: Estou procurando o novo livro da srie Harry Potter .
A fala do vendedor pode ser considerada uma primeira parte de um par
adjacente, que cria a expectativa de que o comprador responder com
alguma informao sobre um produto de seu interesse. Como o comprador
responde com uma fala do tipo esperado, a conversa tida como coerente e
bem-sucedida. J no dilogo a seguir, isso no acontece, e a conversa tida
como incoerente (a incoerncia est marcada por um asterisco):
C: Estou procurando o novo livro da srie Harry Potter .
* V: Semana passada eu fui praia e o mar estava timo!
Em interfaces com usurio, quando o usurio aciona um item de menu Salvar como...,
ele espera que o sistema lhe pergunte com que nome e onde deve salvar o arquivo. Caso
algo diferente ocorra, h uma ruptura na comunicao.
Quando o ouvinte no entende uma fala, ele pode iniciar uma sequncia colateral, uma
troca de falas em que o ouvinte busca esclarecimentos sobre o que foi dito anteriormente.
Essa solicitao explcita de esclarecimentos tambm cria expectativas sobre o que vem a
seguir na conversa, como ocorre com os pares adjacentes.

3.5.2 Comunicao UsurioSistema


Segundo Suchman (1987), a descrio de artefatos computacionais como interativos
apoiada pelas suas propriedades reativas, lingusticas e internamente opacas. Ela prope
ainda que essas propriedades nos levam a enxergar esses artefatos como interativos e a
atribuir explicaes intencionais ao seu comportamento. Na prtica, isso sugere que,
como um ator humano, o computador seja capaz de se expressar, ou expressar a inteno
por trs de suas aes, para o usurio.
Suchman ressalta que a forma de controlar as mquinas computacionais e o
comportamento resultante so cada vez mais lingusticos, em vez de mecnicos. A
operao da mquina se torna menos uma questo de pressionar botes ou puxar
alavancas com algum resultado fsico, e mais uma questo de especificar operaes e
avaliar seus efeitos atravs do uso de linguagem. Isso contribui para a tendncia dos
designers em descreverem o que ocorre entre as pessoas e mquinas utilizando termos
emprestados da descrio da interao humana (e.g., dilogo, conversao). Esses termos
trazem um conjunto de intuies sobre propriedades comuns comunicao humana e
ao uso de artefatos de base computacional. Ela observa ainda que, num sistema
computacional, os momentos de troca de turnos so predeterminados. Ao estabelecer
uma relao determinada entre aes detectveis dos usurios e respostas da mquina, o
designer controla unilateralmente a interao, mas de forma condicional s aes do
usurio.
Para comparar as vises da interao do usurio e do sistema, Suchman (1987) utiliza
um framework analtico simples:
Do ponto de vista do usurio, separa os eventos em aes dos usurios que no esto
disponveis ao sistema (por exemplo, conversas entre os usurios) e que esto
disponveis ao sistema (por exemplo, aes sobre os elementos da interface do
sistema).
Do ponto de vista do sistema, separa os efeitos disponveis ao usurio (por exemplo,
instrues apresentadas na tela) e o design rationale, ou seja, pressuposies e planos
do designer que foram embutidos no sistema.
Suchman observa que o sucesso da interao assume que o usurio interpreta as
instrues e as respostas do sistema da forma como o designer pretendia. Para transmitir
a inteno do design ao usurio, e faz-lo interativamente, o designer se apoia
tacitamente em certas convenes da conversao humana. O problema prtico com o
qual o designer de um sistema interativo precisa lidar como assegurar que o sistema
responda de forma apropriada s aes do usurio. Devemos levar em considerao que a
interao um processo altamente contingente, no qual toda ao envolve no apenas a
inteno do ator, mas tambm o trabalho interpretativo do seu interlocutor. Este, por sua
vez, deve determinar o significado e o valor da ao para ento responder
adequadamente, tomando uma nova ao. De modo geral, o designer e o usurio
compartilham a expectativa de que a relevncia de cada fala est condicionada fala mais
recente e que, dada uma ao por um interlocutor que pede uma resposta, a prxima ao
do outro ser uma resposta. Essa expectativa no assegura que qualquer prxima ao de
fato ser uma resposta ltima, mas significa que, sempre que possvel, o usurio vai
buscar uma interpretao da prxima ao como se fosse essa resposta.
J a expectativa do usurio de que toda resposta do sistema indique, implcita ou
explicitamente, uma avaliao da ltima ao que o usurio tomou e uma recomendao
sobre o que ele pode ou deve fazer em seguida. Mais especificamente, toda vez que age
sobre a interface, o usurio tem as seguintes expectativas com relao resposta do
sistema (Suchman, 1987):
Se o sistema responde com uma nova instruo, a ao anterior do usurio foi
confirmada pelo sistema. Ao realizarmos um procedimento passo a passo, temos uma
expectativa geral de que completar uma ao permite progredir para uma nova
instruo e uma prxima ao. Esse tipo de resposta ocorre, por exemplo, aps
submeter um formulrio de busca, quando o sistema responde com alguns
documentos encontrados e instrues sobre como acess-los.
Se o sistema no responde, a ao anterior do usurio de algum modo estava
incompleta, e deve haver mais alguma ao para o usurio tomar de forma a
complet-la. A falta de resposta do sistema traz informaes sobre a ltima ao do
usurio, indicando que o turno de fato no mudou. Por exemplo, caso o usurio
preencha um formulrio de busca mas no ative a busca de fato, o sistema fica
aguardando uma prxima ao do usurio.
Se a resposta do sistema for repetir a instruo, a repetio implica que (1) a ao
prvia do usurio deve ser repetida (i.e., que o procedimento iterativo); (2) houve
erro na ao prvia e o sistema retorna ao estado anterior instruo, desfazendo a
ao (isso no ocorre na interao humana, e os usurios frequentemente no
reconhecem isso); ou (3) a ao do usurio falhou em satisfazer a inteno da
instruo do sistema e precisa ser remediada. Por exemplo, quando o usurio
submete um formulrio de busca e o sistema lhe reapresenta o mesmo formulrio,
em geral isso indica que houve uma falha na tentativa anterior (e.g., o usurio no
definiu nenhum termo antes de acionar a busca), ou seja, que o usurio no seguiu
um curso de ao esperado e deve tentar remediar o problema naquele ponto.
Assim, a interao entre pessoas e mquinas requer essencialmente o mesmo trabalho
de interpretao que caracteriza a interao entre pessoas, mas com recursos
fundamentalmente diferentes disponveis aos participantes. Em particular, as pessoas
fazem uso de uma gama rica de recursos lingusticos, no verbais e inferenciais ao tentar
compreender aes e eventos, ao tornar suas prprias aes razoveis, e ao gerenciar os
problemas de entendimento que inevitavelmente surgem. Muitos sistemas
computacionais, por outro lado, se apoiam numa gama fixa de entradas sensoriais,
mapeadas a um conjunto predefinido de estados internos e respostas. O resultado uma
assimetria que limita substancialmente o escopo da interao entre pessoas e sistemas
computacionais. Essa assimetria traz ao menos trs desafios para o design de sistemas
computacionais interativos (Suchman, 1987):
como reduzir a assimetria, aumentando o acesso do sistema s aes e circunstncias
do usurio;
como tornar claros ao usurio os limites do acesso do sistema a esses recursos de
interao bsicos;
como encontrar maneiras de compensar a falta de acesso do sistema situao do
usurio com alternativas computacionais disponveis.
Assim como a comunicao humana, a comunicao usuriosistema no livre de
problemas. Concepes erradas do usurio podem lev-lo a encontrar evidncias para
um erro em suas aes onde no h nenhum, ou podem lev-lo a um erro nas suas aes
que no possa ser detectado pelo sistema.
Suchman argumenta que a interao usuriosistema geralmente limitada s
intenes dos designers e sua capacidade de prever e restringir as aes do usurio.
Cabe ao designer entender essas limitaes e tentar estender, atravs de um design
cuidadoso, a gama de comportamentos teis do sistema.

3.5.3 Estudos Etnometodolgicos De IHC


Estudos fundamentados em etnometodologia tm sido aplicados em IHC de diversas
maneiras (Button, 2003):
para analisar o impacto que um sistema teve no trabalho realizado no ambiente em
que o sistema introduzido;
para analisar princpios e mtodos organizacionais subjacentes a um domnio de
trabalho;
para analisar os impactos de um sistema sobre esses mtodos;
para criticar o design do sistema quando entra em conflito com esses mtodos.
Numa abordagem de estudo de campo fundamentada em etnometodologia, a
atividade humana observada enquanto se desdobra nas circunstncias reais em que
ocorre. O observador-participante atua como uma sombra de um indivduo particular e
testemunha muitas circunstncias em que ele est envolvido durante um dia de trabalho.
A relao entre as interpretaes da ao e as circunstncias da ao devem ser
investigadas. O ponto de partida para o estudo a suposio de que no temos uma
descrio a priori da estrutura da ao situada. No queremos pressupor quais so as
condies relevantes ou sua relao com a estrutura da ao. Precisamos capturar tanto
quanto possvel do fenmeno e pressupor to pouco quanto possvel (Suchman, 1987).
Essa atitude se contrape anlise de exemplos artificiais, observaes ou relatos de
entrevistas, que se fiam em circunstncias imaginadas ou lembradas (Button, 2003).
Segundo Button, os estudos sobre a forma como as pessoas tm de trabalhar com um
sistema e frequentemente contorn-lo tm sido utilizados para criticar as metodologias
de projeto que apoiam diversos designs de sistemas baseados em entendimentos
abstratos e formais do trabalho. Sistemas assim projetados podem encontrar
dificuldades quando so implantados em ambientes de trabalho reais por causa da
natureza situada da organizao do trabalho, que costuma ser um fenmeno muito mais
flexvel, envolvendo prticas ad hoc e operaes de contingncia na sua realizao, em vez
de regras ou normas prescritivas.
Em IHC, estudos do trabalho tambm vm sendo utilizados para avaliar designs
tecnolgicos particulares. Ao conduzir estudos sobre o uso real de um sistema no local
de trabalho, torna-se possvel coletar dados detalhados sobre a aplicao de tecnologia
que podem ser utilizados na sua avaliao e no redesign subsequente.
A expresso ao reportvel (accountable action) chama ateno para o fato de que as
aes sociais no so apenas realizadas, mas so feitas de forma que possam ser
reconhecidas como tal, isto , de forma que seja possvel fazer um relato delas.
Utilizando a ideia de que a ao humana reportvel (feita para que possa ser
reconhecida), Dourish e Button (1998) sugerem que abstraes podem ser desenvolvidas
de modo que atuem como uma forma de visualizar os mecanismos operantes quando
alguma tarefa est ocorrendo. Por exemplo, uma operao de cpia no computador feita
para tornar o que est sendo feito reconhecvel. Dessa forma, o sistema consegue
fornecer um relato do que est sendo feito medida que o faz, o que permite aos
usurios determinarem melhor qualquer ao (remediadora) que seja necessria (Button,
2003).
3.6 Teoria da Atividade
A teoria da atividade teve origem no incio do sculo XX como uma psicologia
materialista dialtica elaborada por Vygotsky e seus alunos. Vygotsky argumentava
contra separaes artificiais entre mente e comportamento, e entre mente e sociedade.
Ele advogava pela unidade da percepo, fala e ao. Alm disso, enfatizava a
centralidade dos dispositivos mediadores, como linguagens e outros smbolos ou
ferramentas, no desenvolvimento da mente e do pensamento. A nfase no significado
atravs da ao, a conexo entre o individual e o social, e o papel das ferramentas
mediadoras so o cerne em torno do qual a teoria da atividade se desenvolveu (Gay e
Hembrooke, 2004).
Segundo Vygotsky (1978), a atividade humana possui trs caractersticas fundamentais:
dirigida a um objeto material ou ideal;
mediada por artefatos;
socialmente constituda dentro de uma cultura.
A teoria da atividade rejeita o ser humano isolado como uma unidade de anlise
adequada, e insiste na mediao cultural e tcnica da atividade humana. A unidade de
anlise inclui os artefatos tcnicos e a organizao cultural, que tanto determinam o ser
humano como so criados por ele. Essa teoria entende o comportamento humano como
ancorado em prticas coletivas compartilhadas. No considera um ser humano
genrico, e enderea mais do que o conhecimento, as habilidades e o julgamento
individual. Permite analisar a adequao de uma ferramenta para uma prtica, bem como
estudar de que maneira a introduo de um artefato particular modifica a prtica e como
a prtica pode modificar o uso do artefato. O fato de a atividade humana ser mediada por
artefatos socialmente construdos (e.g., ferramentas, linguagens e representaes)
significa que, na sua relao imediata com seu ambiente, uma pessoa se estende com
artefatos externos a ela (Bertelsen e Bdker, 2003).
Segundo Leontiev (1978), a atividade humana pode ser analisada numa hierarquia de
atividade, ao e operao. A atividade realizada atravs de aes conscientes
direcionadas a objetivos do sujeito. As aes so realizadas atravs de operaes
inconscientes, disparadas pela estrutura da atividade e as condies do ambiente. A
atividade busca satisfazer uma necessidade do sujeito atravs de um objeto material ou
ideal (Bertelsen e Bdker, 2003).
importante observar que os nveis de atividade no so fixos (Figura 3.18). Uma ao
se torna uma operao quando a orientao para um ato transformada da interao
consciente com objetos externos em um plano de ao interno e inconsciente, num
processo de aprendizado. Dizemos ento que ocorreu uma internalizao. As operaes
podem se desenvolver natural, histrica ou culturalmente. Podem resultar de padres
inatos espcie, do uso apropriado de ferramentas e da relao com outras pessoas,
dentre outros fatores. De forma semelhante, em situaes problemticas, uma operao
pode se tornar uma ao. A externalizao ocorre em situaes que precisam de reparo,
que no podem ser resolvidas apenas internamente (e.g., contas com nmeros muito
grandes) ou quando duas ou mais pessoas trabalham juntas.
FIGURA 3.18 Relacionamento dinmico entre nveis de atividade (figura adaptada de Bertelsen e Bdker, 2003).

A teoria da atividade utiliza como unidade de anlise bsica e irredutvel a atividade


motivada. A atividade pode ser entendida como uma estrutura sistmica. o
engajamento de um sujeito (ou coletivo) direcionado a um objeto. Esse engajamento
socialmente mediado pela comunidade em que a atividade se constitui. A noo de
atividade humana de Leontiev pode ser ilustrada atravs de tringulos aninhados (Figura
3.19).

FIGURA 3.19 Teoria de atividade humana de Leontiev (Engestrm, 1987).

Na figura, identificamos o Sujeito e Objeto da atividade, mediados pela Comunidade e


pelo Instrumento, que pode ser tanto um instrumento tcnico (ferramenta) como um
instrumento psicolgico (signo). Da mediao SujeitoComunidade emergem Regras e
rituais, ao passo que da mediao ComunidadeObjeto surge a Diviso de trabalho. E,
quando h diversas atividades interligadas, temos redes de atividade.
Perguntas do tipo por que, o que e como ajudam a entender melhor a atividade (Bertelsen
e Bdker, 2003):
Perguntas por qu? revelam o motivo da atividade, o significado social e pessoal da
atividade e a sua relao com motivos e necessidades.
Perguntas o qu? revelam possveis objetivos, objetivos crticos e subobjetivos
particularmente relevantes.
Perguntas como? revelam operaes, formas concretas de executar uma ao de
acordo com condies especficas em torno do objetivo da atividade.
Por exemplo, numa atividade relacionada ao uso de um dispositivo de reproduo de
msica, o motivo poderia ser identificado como relaxar , um objetivo poderia ser ouvir
msicas preferidas, e a forma concreta de realizar uma ao em direo ao objetivo
poderia ser a sequncia examinar listas de msicas e ativar lista de msicas
denominada favoritas.
3.6.1 Princpios Da Teoria Da Atividade
Os princpios da teoria da atividade comumente citados so: mediao, orientao a
objetos e perturbao (disturbance).
Conforme pode ser visto na Figura 3.19, a relao de um indivduo com um objetivo
mediada por instrumentos que so utilizados para atingir o objetivo, pela comunidade
que participa da atividade e pela diviso de trabalho que existe nessa comunidade.
Kaptelinin (1996) enderea especificamente os efeitos mediadores da atividade
computacional na conscincia, no aprendizado e no desenvolvimento humano. Para ele,
tecnologias computacionais possibilitam e transformam atividades atravs de aes,
objetivos e relaes sociais de agentes individuais. Segundo Bertelsen e Bdker (2003),
tomando a atividade motivada como a unidade bsica de anlise, precisamos estudar o
que acontece quando usurios se concentram no seu trabalho ou qualquer outro ato
intencional enquanto utilizam o artefato computacional. Com base na estrutura
hierrquica da atividade, isso significa que a situao tende a ser rotineira quando o
objeto da ao consciente do usurio o mesmo objeto do trabalho e as operaes
inconscientes do usurio so dirigidas ao artefato mediador. Nesse caso, o artefato
computacional se torna uma ferramenta transparente. Por exemplo, quando uma pessoa
utiliza frequentemente um editor de texto como ferramenta ou instrumento, o objeto da
sua ao consciente se torna o documento que est sendo elaborado, e no mais a
aplicao de editor de texto em si.
O prximo passo olhar para como os prprios objetos (coisas ou pessoas) que so o
foco desse trabalho esto visveis dentro ou fora do computador. Esses objetos reais de
interesse da nossa atividade (tambm denominados objetos do domnio) constituem a
base para a anlise futura. Gay e Hembrooke (2004) enfatizam duas vises sobre
mediao: a bidirecionalidade dos efeitos (das percepes, motivaes, cultura e aes
que moldam a ferramenta e que so moldadas por ela) e a necessidade de estudos
longitudinais sustentados para revelar como essas relaes mediadoras se desenvolvem e
se modificam ao longo do tempo.
Na teoria da atividade, a orientao a objetos se refere ao engajamento das pessoas
com objetos e objetivos (Kaptelinin, 1996). Recebem status de objeto os fenmenos
fsicos, sociais e culturais, incluindo fenmenos no materiais como expectativas e
afinidades. O propsito, a inteno ou a motivao para agir sobre um objeto ou
trabalhar em direo a um objetivo so os fundamentos do sistema de atividade, e atuar
sobre um objeto o espao de orientao da ao. Gay e Hembrooke (2004) identificam
dois aspectos importantes do conceito de orientao a objetos: (1) objetos psicolgicos e
sociais podem ter o mesmo nvel de importncia que objetos fsicos; (2) artefatos
(instrumentos) podem ser transpostos a objetos e vice-versa. Por exemplo, um artefato ou
ferramenta no framework de um sistema de atividade principal pode ao mesmo tempo
ser um objeto num outro sistema. Em contrapartida, quando ocorre um problema na
utilizao de um artefato computacional, ele geralmente se torna o objeto de uma nova
atividade de resoluo de problemas.
A perturbao se refere ao fato de que as relaes entre os diversos elementos do
modelo da teoria da atividade so flexveis e esto sempre mudando. medida que
perturbaes se tornam evidentes dentro de um sistema de atividade ou entre sistemas
de atividade, os participantes podem comear a enderear as questes subjacentes e
modificar suas situaes, atividades, ou a si prprios. Para Gay e Hembrooke (2004), as
perturbaes podem ser informativas no processo de design como sinais para descobrir
por que a perturbao se materializou, por que ela no existia at um certo ponto no
tempo, quais efeitos ela pode ter e como pode ser resolvida.

3.6.2 Contradio E Aprendizado


Sistemas de atividade so fundamentalmente marcados por contradies. Engestrm
(1987) classifica as contradies em um sistema de atividade e entre sistemas de
atividades como as foras motrizes do aprendizado e desenvolvimento humano.
Contradies podem resultar das relaes entre o uso e o valor obtido (e.g., a tenso
entre a melhor soluo possvel e o que pode ser projetado com o tempo e recursos
disponveis), entre a atividade em estudo e as atividades vizinhas, entre a atividade
considerada e a atividade desejada (potencial). Essas contradies podem ser geradas
deliberadamente, atravs da elaborao de exemplos e vises em um processo de
desenvolvimento de uma comunidade de prtica para lan-la a um novo estgio.
O aprendizado no se trata apenas de como o indivduo adapta o artefato ou se adapta
a ele. Tambm trata de como a prtica coletiva se desenvolve. Projetar um artefato no
significa apenas projetar uma coisa ou dispositivo que pode ser utilizado pelas pessoas
como artefatos num tipo especfico de atividade. medida que o uso de artefatos faz
parte da atividade social, projetamos novas condies para essa atividade coletiva, tal
como uma nova diviso do trabalho e novas formas de coordenao e comunicao. No
uso real, artefatos frequentemente mediam diversas atividades de trabalho, e as
contradies e os conflitos resultantes dessa mirade de usos so essenciais para a anlise
e o projeto do artefato no mbito da teoria da atividade (Bertelsen e Bdker, 2003).
A teoria da atividade entende que os seres humanos no esto apenas selecionando
aes dentre as oferecidas pelo ambiente. Segundo a teoria, as pessoas esto ativa e
constantemente recriando seu prprio ambiente, como resultado de contradies,
instabilidades e do surgimento de novas necessidades.

3.6.3 Teoria Da Atividade Em IHC


Em IHC, a teoria da atividade tem se concentrado principalmente em quatro pontos
(Bertelsen e Bdker, 2003):
anlise e design de uma prtica de trabalho especfica, considerando as qualificaes, o
ambiente de trabalho, a diviso de trabalho e assim por diante;
anlise e design com foco no uso real e na complexidade da atividade multiusurio e,
em particular, na noo essencial do artefato como mediador da atividade humana;
o desenvolvimento da experincia e do uso em geral;
a participao ativa do usurio no design, e com foco no uso como parte do design.
Segundo Bertelsen e Bdker (2003), a teoria da atividade permite estudar diversos
nveis de atividade combinados: desde a atividade de uso estrito de um artefato
computacional at o contexto mais amplo de uso e design. Tambm permite modificar a
escala e estudar as conexes em mltiplos nveis de atividades em que artefatos
computacionais so utilizados e projetados, sem estabelecer uma hierarquia permanente
na anlise.
Segundo Gay e Hembrooke (2004), o potencial explicativo da teoria da atividade est na
ateno que ela d a mltiplas dimenses de engajamento humano com o mundo e no
framework que fornece para configurar essas dimenses e processos numa atividade
coerente. Em IHC, o papel mediador exercido por artefatos e ferramentas culturais e seu
poder transformador so essenciais para o entendimento desses processos de
engajamento durante o uso.
Para projetar uma aplicao computacional situada no uso, necessrio (Bdker, 1996):
enquadrar historicamente o trabalho e a aplicao computacional; situar a aplicao
computacional numa rede de atividades em que ela utilizada; caracterizar o uso da
ferramenta; considerar o apoio necessrio s diversas atividades que ocorrem em torno
da aplicao computacional; identificar os objetos que so trabalhados na ou atravs da
aplicao computacional; considerar a rede de atividades e contradies dentro de uma
atividade e entre atividades. Para cada atividade especfica, Bdker prope perguntar:
Qual o objetivo da atividade e das aes para o usurio?
Qual objeto focado pelo usurio? Onde esse objeto se encontra (dentro, fora ou
atravs da aplicao computacional)?
Qual o instrumento? Onde ele se encontra (dentro, fora ou atravs da aplicao
computacional)?
Quando h mais usurios cooperando, devemos perguntar: os objetivos, objetos e
instrumentos esto alinhados ou conflitantes (entre indivduos e entre o grupo e seus
membros)?
Para cada mudana de foco, devemos perguntar: de qual foco/objeto para qual outro? A
mudana foi uma ruptura ou uma mudana deliberada? O que causou a mudana?
Ela se originou dentro ou fora da aplicao?
Focando os principais constituintes de uma atividade considerada como central,
Korpela (1999) levanta uma srie de questes:
resultado: que servios ou produtos so produzidos?
objeto e processo: com que materiais brutos ou pr-requisitos uma atividade se inicia?
Como so produzidos os servios e produtos com as entradas que se tem?
instrumentos: que tipos de ferramenta fsica, conhecimento e habilidade so necessrios
para esse trabalho?
sujeitos: quem so? Que tipos diferentes de pessoas so necessrios para produzir esses
servios e produtos?
relaes e meios sociais: quando se trabalha para produzir esses servios e produtos, que
tipos de regras, diviso de trabalho e comunicao se aplicam entre as pessoas?
J no caso de uma rede de atividades, eles incluem as seguintes questes:
resultado: quem precisa dos servios ou produtos? Por que eles so necessrios para
produzir servios ou produtos para outros?
objeto: de quem se obtm o material bruto? Como se produz aquilo que necessrio?
instrumentos: de quem se obtm as ferramentas e conhecimentos necessrios? Como
eles so produzidos?
sujeitos: de onde eles vm? Quem educa as pessoas envolvidas nas atividades? Como
isso ocorre?
relaes e meios sociais: quem estabelece as regras para as atividades? Como elas so
geradas?
3.7 Cognio Distribuda
A teoria da cognio distribuda, assim como qualquer outra teoria cognitiva, busca
entender a organizao de sistemas cognitivos. Diferente das teorias cognitivas tradicionais,
no entanto, a cognio distribuda amplia a semntica de cognitivo para abranger as
interaes entre pessoas, recursos e materiais no ambiente (Hollan et al., 2000).
Segundo Perry (2003), a cognio distribuda surgiu de uma necessidade de entender o
trabalho que extrapola o indivduo, entender como o processamento de informao e a
resoluo de problemas incorporam o uso de ferramentas e envolvem outras pessoas. Em
outras palavras, os designers precisam entender como os grupos coordenam o
comportamento de seus membros, colaboram e resolvem problemas.
Em cognio distribuda, a unidade de anlise para a cognio o processo cognitivo,
delimitado pelos relacionamentos funcionais dos elementos que dele participam,
independentemente de onde estejam. Os mecanismos que participam dos processos
cognitivos extrapolam a manipulao de smbolos na mente de atores individuais. Eles
incluem o mundo material, que fornece oportunidades para reorganizar o sistema
cognitivo distribudo de modo a fazer uso de um conjunto diferente de processos
internos e externos (Hollan et al., 2000).
A cognio distribuda considera que um sistema pode se configurar dinamicamente
para coordenar subsistemas que realizam diversas funes. Os processos cognitivos
podem ser distribudos entre os membros de um grupo social, envolver a coordenao
entre estruturas internas (smbolos e modelos mentais) e externas (materiais ou do
ambiente) e estar distribudos no tempo, de forma que os produtos de acontecimentos
passados possam transformar a natureza de acontecimentos posteriores. Na cognio
distribuda h trs crenas bsicas (Hollan et al., 2000):
a organizao social uma forma de arquitetura cognitiva. A organizao social,
juntamente com a estrutura fornecida pelo contexto da atividade, determina em
grande parte a forma como a informao flui atravs de um grupo. Padres dessas
trajetrias de informao refletem uma arquitetura cognitiva subjacente. Essa
perspectiva traz trs questes fundamentais sobre interaes sociais: (1) como os
processos cognitivos geralmente associados a uma mente individual so
implementados em um grupo de indivduos; (2) como as propriedades cognitivas de
grupos diferem das propriedades cognitivas das pessoas que atuam nesses grupos; e
(3) como as propriedades cognitivas de mentes individuais so afetadas pela sua
participao em atividades em grupo.
a cognio materializada. As relaes entre processos internos e externos envolvem a
coordenao ao longo do tempo entre recursos internos (memria, ateno e funo)
e externos (objetos, artefatos e materiais disponveis no ambiente que nos cerca).
o estudo da cognio no pode ser separado do estudo da cultura. Por um lado, a
cultura emerge da atividade de agentes humanos em seus contextos histricos
medida que estruturas mentais, materiais e sociais interagem. Por outro, na forma de
uma histria de artefatos materiais e prticas sociais, a cultura molda os processos
cognitivos, atuando como recurso para o aprendizado, a resoluo de problemas e o
raciocnio.
As pessoas estabelecem e coordenam diferentes tipos de estrutura em seu ambiente,
externalizando informaes (i.e., utilizando e criando representaes externas) de modo a
apoiar o seu trabalho individual e coletivo. Representaes externas reduzem a carga
cognitiva das pessoas, incluindo memria (por exemplo, utilizando lembretes) e
processamento (por exemplo, traando um grfico medida que dados se tornam
disponveis, buscando tendncias). A cognio distribuda destaca a importncia de se
investigar como projetar representaes que facilitem seu uso flexvel, assim como
representaes mais ativas que ajudem os usurios a enxergarem o que mais relevante e
decidirem o que fazer a cada momento.
Sob uma perspectiva terica, para resolver problemas, um sistema inteligente percorre
um espao de problema, passando por diversos estados transitrios em direo a um
objetivo. Esses estados de problema so de natureza representacional, e uma anlise
deve focar esses estados e as transformaes entre eles. A resoluo cooperativa de
problemas envolve uma unidade maior que o indivduo, que se torna um componente
dos recursos de resoluo de problemas do grupo (Perry, 2003).
Em termos prticos, Perry afirma que uma anlise de cognio distribuda envolve
(Figura 3.20):
descrever o contexto da atividade, os objetivos do sistema funcional e seus recursos
disponveis;
identificar as entradas e sadas do sistema funcional;
identificar as representaes e os processos disponveis;
identificar as atividades de transformao que ocorrem durante a resoluo de
problemas para atingir o objetivo do sistema funcional.

FIGURA 3.20 Elementos de anlise da cognio distribuda (figura adaptada de Perry, 2003).
3.8 Engenharia Semitica
A engenharia semitica uma teoria de IHC centrada na comunicao. Ela caracteriza a
interao humano-computador como um caso particular de comunicao humana mediada
por sistemas computacionais (de Souza, 2005a). Seu foco de investigao a comunicao
entre designers, usurios e sistemas. Os processos de comunicao investigados so
realizados em dois nveis distintos: a comunicao direta usuriosistema e a
metacomunicao (i.e., comunicao sobre uma comunicao) do designer para o usurio
mediada pelo sistema, atravs da sua interface (Figura 3.21).

FIGURA 3.21 Metacomunicao designerusurio e comunicao usuriosistema.

A engenharia semitica caracteriza aplicaes computacionais como artefatos de


metacomunicao, ou seja, artefatos que comunicam uma mensagem do designer para os
usurios sobre a comunicao usuriosistema, sobre como eles podem e devem utilizar
o sistema, por que e com que efeitos (de Souza, 2005a; de Souza, 2005b; de Souza e Leito,
2009). O contedo dessa mensagem de metacomunicao, ou metamensagem, pode ser
parafraseado no seguinte modelo genrico (de Souza, 2005a, p. 25):

Este o meu entendimento, como designer, de quem voc, usurio, , do que aprendi que voc
quer ou precisa fazer, de que maneiras prefere fazer, e por qu. Este, portanto, o sistema que
projetei para voc, e esta a forma como voc pode ou deve utiliz-lo para alcanar uma
gama de objetivos que se encaixam nesta viso.

Em tempo de design, o designer estuda os usurios, suas atividades e seu ambiente e,


a partir desse estudo, concebe sua viso sobre como contemplar o que os usurios
desejam ou necessitam e sobre como os usurios, suas atividades e seu ambiente podem
ou devem mudar com a introduo do sistema sendo projetado. Ele ento expressa essa
sua viso na forma de tecnologia computacional, elaborando a metamensagem e
codificando-a em palavras, grficos, comportamento, ajuda on-line e explicaes. Com
isso, ele visa atingir a sua inteno comunicativa: que os usurios interpretem
adequadamente, gostem e se beneficiem do produto. Como os designers no estaro
fisicamente presentes durante a interao para que os usurios possam falar com ele,
dizemos que a metamensagem nica e unidirecional (do ingls, one-shot message). Tudo
o que o preposto do designer precisa comunicar deve ser planejado em tempo de design
e implementado na forma de um programa computacional nos estgios seguintes de
desenvolvimento (de Souza, 2005a, p. 24).
Em tempo de interao, os usurios decodificam e interpretam gradualmente a
metamensagem do designer, buscando atribuir sentido aos significados nela codificados
e respondendo de forma apropriada. Assim, designers, sistemas e usurios so
interlocutores igualmente envolvidos nesse processo comunicativo que constitui a
interao humano-computador (de Souza, 2005a; 2005b).
Para que a metacomunicao seja bem-sucedida, o designer deve se tornar um
interlocutor legtimo na interao humanocomputador (...), deve falar atravs do
sistema, que se torna ento o preposto do designer (de Souza, 2005b). O preposto do
designer (designers deputy) responsvel por comunicar ao usurio, durante a interao,
a metamensagem do designer, que contm todos os significados e possibilita todas as
manipulaes de significados que os designers escolheram incorporar no sistema a fim
de que ele fizesse aquilo para o que foi projetado (de Souza, 2005a, p. 24).
Conforme visto na Seo 2.2.3, comunicabilidade um conceito de qualidade dos
sistemas computacionais interativos que comunicam de forma eficiente e efetiva aos
usurios as intenes comunicativas do designer, a lgica e os princpios de interao
subjacentes (Prates et al., 2000a; de Souza, 2005a). A comunicabilidade pode ser definida
tecnicamente como a capacidade do preposto do designer de alcanar a
metacomunicao completa, comunicando aos usurios a essncia da mensagem original
do designer (de Souza, 2005a, p. 114), permitindo, portanto, que os usurios gerem
significados compatveis com aqueles codificados pelo designer.
Como apresentado no Captulo 2, um sistema com alta comunicabilidade auxilia os
usurios a interpretarem e atriburem sentido metamensagem do designer, sentido
esse compatvel com o que o designer pretendia comunicar e, portanto, codificou na
interface. A competncia comunicativa (ou discursiva) do preposto do designer deve ser
analisada em termos de o que ele pode comunicar e como o comunica (de Souza, 2005a, p.
90). Para avaliar a comunicabilidade de um sistema computacional interativo, a
engenharia semitica oferece o mtodo de inspeo semitica e o mtodo de avaliao de
comunicabilidade (Prates et al., 2000a; de Souza, 2005a; de Souza et al., 2006; Prates e
Barbosa, 2007; de Souza e Leito, 2009). Esses mtodos so apresentados nas Sees
10.1.3 e 10.2.2, respectivamente.
A ontologia da engenharia semitica compreende (de Souza, 2005a, p. 95):
processos de significao, que envolvem signos e semiose;
processos de comunicao, que envolvem inteno, contedo e expresso nos dois nveis
de comunicao investigados (a comunicao direta usuriosistema e a
metacomunicao designerusurio mediada pelo sistema, atravs da sua interface);
os interlocutores envolvidos nos processos de significao e comunicao: designers,
sistemas (prepostos dos designers em tempo de interao) e usurios;
o espao de design de IHC, baseado no modelo do espao de comunicao de Jakobson
(1960), que caracteriza a comunicao em termos de emissores, receptores, contextos,
cdigos, canais e mensagens.
A seguir examinamos esses conceitos.

3.8.1 Semitica: Signo, Significao, Comunicao E


Semiose
A Semitica estuda signos, processos de significao e processos de comunicao (Eco,
1976). Peirce define signo como uma coisa que serve para veicular conhecimento de uma
outra coisa (o objeto do signo), que ele representa. A ideia na mente que o signo motiva, e
que um signo mental do mesmo objeto, chamada de interpretante do signo (Peirce,
19921998, vol.2, p. 13). Em outras palavras, o signo algo que representa alguma coisa
para algum. So signos: toda imagem, diagrama, apontar de dedo, piscar de olhos, n
no leno de algum, memria, sonho, desejo, conceito, indicao, token, sintoma, letra,
nmero, palavra, sentena, captulo, livro, biblioteca, (...) (Peirce, 19921998, vol.2, p.
326).
Nem toda representao signo. Para ser um signo, uma representao deve possuir
uma relao tridica com seu objeto e com o seu interpretante, conforme ilustrado pela
Figura 3.22a. A fruta ma (objeto) pode ser representada por uma ilustrao
(representao) e evocar na mente de algum (intrprete) a ideia de ma (interpretante).
Nesse caso, dizemos que a representao (ilustrao) um signo de ma (fruta). E o
interpretante a significao do conceito veiculado pelo signo (Peirce, 19921998, vol.2,
p. 497).

FIGURA 3.22 Exemplos de signos ilustrando a relao tridica do signo com seu objeto e seu interpretante: (a)
signo que representa um objeto fsico e (b) signo de interface.

Segundo Eco, sempre que h convenes sociais ou culturais que nos permitem
interpretar signos, temos um sistema de significao e, portanto, um cdigo (Eco, 1976, p.
4). Segundo de Souza (2005a), em um processo de significao, contedos so
associados sistematicamente a expresses (p. 98), estabelecendo sistemas de signos
com base em convenes sociais e culturais adotadas pelas pessoas que interpretam e
produzem tais signos (p. 26).
J em um processo de comunicao, produtores de signos utilizam sistemas de
significao para escolher formas de representar (expresso) seus significados
pretendidos (contedo) de modo a alcanar uma variedade de objetivos (inteno). Para
isso, os produtores de signos podem utilizar signos conhecidos (culturalmente
convencionados) de formas convencionais, utilizar signos conhecidos de formas criativas
ou at mesmo inventar signos (de Souza, 2005a, p. 98).
Um signo de interface ento codificado pelo designer visando comunicar sua
inteno de design aos usurios. Por exemplo, ao representar a operao de salvar o
documento por um boto com o rtulo Salvar e um cone de um disquete, o designer
espera que os usurios interpretem esse signo como Clicando nesse boto, eu consigo
salvar o documento (Figura 3.22b).
Para Peirce, o interpretante de um signo , ele prprio, outro signo. Sendo assim,
passvel de ser, ele prprio, interpretado, gerando outro interpretante, e assim
sucessivamente. Esse processo interpretativo que nos leva a associar cadeias de
significados (interpretantes) a um signo denominado semiose (Peirce, 19921998; Eco,
1976). Trata-se de um processo potencialmente ilimitado. Segundo Santaella (2000), o
signo, por sua prpria constituio, est fadado a germinar, crescer, desenvolver-se num
interpretante (outro signo) que se desenvolver em outro e assim indefinidamente.
Evidencia-se a a natureza inevitavelmente incompleta de qualquer signo (p. 29). Esse
processo interpretativo humano em constante evoluo, indefinidamente longo e
imprevisvel denominado semiose ilimitada.
Na prtica, a semiose interrompida quando o intrprete fica satisfeito com o
interpretante gerado (i.e., o significado temporariamente atribudo ao signo) ou no tem
mais tempo ou outro recurso necessrio para continuar gerando novos significados.
importante observar que essa interrupo deve ser considerada temporria, pois a
qualquer momento podem surgir novos fatos ou circunstncias que levem o intrprete a
retomar o processo, prosseguindo no mesmo caminho interpretativo ou iniciando um
novo caminho distinto do anterior. A qualquer momento, um significado pode ser revisto
e corrigido, por exemplo, devido ao surgimento de evidncias conflitantes ou contrrias.
A Figura 3.23 ilustra um processo de semiose associado a um signo de interface.
FIGURA 3.23 Um processo de semiose associado a um signo de interface.

A natureza potencialmente ilimitada da semiose humana indica que no podemos falar


em o significado de um signo, mas sim em um significado de um signo. Mas, se no
podemos capturar de modo definitivo o significado de um signo atribudo por uma
pessoa, como conseguimos nos comunicar com sucesso? Voltando nossa ateno para a
comunicao usuriosistema, o que o usurio (como emissor) quer dizer com uma
expresso para o preposto e o que o usurio (como receptor) entende que uma expresso
do preposto quer dizer so contingentes situao comunicativa em que a expresso
surge (de Souza, 2005a, p. 100). Se cada signo significa alguma coisa para os designers,
possivelmente alguma outra coisa para os usurios, e esses significados podem mudar a
qualquer momento, como conseguimos nos comunicar (interagir) com sistemas
computacionais interativos?
Todo processo de semiose fortemente influenciado pelo conhecimento prvio,
hbitos e experincia pessoal do intrprete, pela cultura em que ele se insere e pelo
contexto em que o signo interpretado (de Souza, 2005a). Segundo Danesi e Perron
(1999) a cultura auxilia a comunicao humana, funcionando como um continer de
signos e significados que convergem de formas previsveis em padres de
representao que indivduos e grupos podem utilizar para produzir ou trocar
mensagens (p. 67). Da a importncia de os designers produtores de signos de
interface estudarem os usurios consumidores desses signos , suas atividades e
experincias, seus valores e expectativas, sua cultura e os ambientes em que eles vo
utilizar o sistema computacional interativo sendo projetado. Desse modo, os designers se
capacitam a expressar adequadamente sua inteno comunicativa nos signos de interface
elaborados e codificados no sistema, tendo em vista o que ele aprendeu sobre as
caractersticas e a cultura dos usurios.

3.8.2 Sistema Computacional Interativo Como Artefato


Intelectual
Um artefato algo criado pelo ser humano, geralmente para um propsito prtico; (...)
algo caracterstico ou resultante de uma instituio, perodo, tendncia ou indivduo
particular .3 Trata-se de um produto artificial resultante da engenhosidade humana
atravs de um processo de design, que geralmente envolve atividades de anlise, sntese
e avaliao (veja o Captulo 4).
De Souza (2005a) define um sistema computacional interativo como um artefato
intelectual. Ele resulta de atividades de anlise, codificando um entendimento ou
interpretao particular do seu produtor sobre uma situao-problema, e sntese,
codificando um conjunto particular de solues para a situao-problema analisada. A
natureza intelectual desse artefato se deve principalmente ao fato de que (1) a codificao
da situao-problema e das solues correspondentes fundamentalmente lingustica
(i.e., baseada em um sistema de smbolos verbais, visuais, sonoros e outros que
podem ser interpretados por regras semnticas consistentes) e (2) o propsito final do
artefato s pode ser completamente alcanado por seus usurios se eles conseguem
formul-lo dentro do sistema lingustico no qual o artefato codificado (i.e., os usurios
devem ser capazes de entender e utilizar um sistema de codificao lingustica particular
para explorar e realizar as solues possibilitadas pelo artefato) (de Souza, 2005a, p. 10).
Em outras palavras, designers, preposto e usurios de um sistema computacional
interativo devem utilizar uma mesma linguagem, um sistema de signos composto de
vocabulrio, gramtica e regras semnticas, a fim de se comunicarem atravs do sistema.
Essa linguagem de interface resulta de decises do designer sobre as estratgias de
atuao e de resoluo de problemas dos usurios que pretende apoiar com o sistema
por ele projetado (de Souza, 2005a).
Como visto, o processo de semiose ilimitada no pode ser completamente determinado;
pode ser apenas motivado pela escolha dos sistemas de significao utilizados. Em
contrapartida, sistemas computacionais geram significados atravs processamentos
simblicos determinados causalmente por algoritmos e codificados pelos seus
desenvolvedores utilizando alguma linguagem de programao. Ao contrrio dos
significados humanos, os significados computacionais podem ser previstos e
completamente inspecionados (de Souza, 2005a, p. 98 ; p. 250).
Em interao humano-computador, o que isso significa que o preposto do designer
s pode reproduzir um segmento limitado (e governado por regras) da semiose do
designer. Portanto, no processo de comunicao usuriosistema, o preposto do designer
conta para o usurio apenas uma verso processvel por mquina do que o designer
realmente queria dizer. E diz a mesma coisa repetidas vezes, independentemente de
como a semiose do usurio esteja evoluindo em torno de signos produzidos nessa
comunicao (de Souza, 2005a, p. 98). Da mesma maneira, o usurio s pode dizer
aquilo que o preposto estiver preparado para ouvir e interpretar.
A limitao da semiose computacional pode introduzir rupturas na comunicao
usuriosistema que no existiriam em circunstncias anlogas de comunicao humana
(de Souza e Leito, 2009, p. 21). Torna-se ento primordial avaliar como um significado
do usurio ou do designer, contingente situao em que investigado, se compara a o
significado implementado do signo de interface correspondente (de Souza, 2005a, p. 87),
a fim de projetar signos que motivem no usurio uma semiose produtiva do usurio, ou
seja, compatvel com a inteno comunicativa do designer.

3.8.3 Espao De Design De IHC


A engenharia semitica uma teoria explicativa de IHC. Ela no deve ser utilizada como
uma teoria preditiva, mas sim para explicar fenmenos de IHC observveis. Alm disso,
deve fornecer meios para formular problemas e questes de IHC e para elaborar as
solues e respostas correspondentes (de Souza, 2005a, p. 104).
Para organizar o espao de design de IHC, a engenharia semitica utiliza o modelo de
espao de comunicao proposto por Jakobson (1960), estruturado em termos de:
contexto, emissor, receptor, mensagem, cdigo e canal. Um emissor transmite uma
mensagem a um receptor atravs de um canal. A mensagem expressa em um cdigo e se
refere a um contexto. Na comunicao, os interlocutores exercem alternadamente os
papis de emissor e receptor (de Souza, 2005a, p. 65; Figura 3.24).

FIGURA 3.24 Modelo do espao de comunicao de Jakobson (1960), adotado pela engenharia semitica para
estruturar o espao de design de IHC (de Souza, 2005a).

A comunicao guiada por uma inteno, os efeitos que o emissor quer provocar ao
transmitir o contedo da sua mensagem ao receptor. Para que a comunicao seja bem-
sucedida, o emissor deve escolher cuidadosamente uma expresso para o contedo que
deseja comunicar, utilizando um cdigo que o receptor seja capaz de interpretar e, no
caso de IHC, que o sistema computacional seja capaz de processar.
Sendo assim, ao projetar sua metamensagem, o designer de IHC precisa tomar
decises sobre cada elemento do espao de design de IHC, respondendo as seguintes
perguntas (de Souza, 2005a, p. 87):
quem o emissor (designer)? Que aspectos das limitaes, motivaes, crenas e
preferncias do designer devem ser comunicados ao usurio para o benefcio da
metacomunicao;
quem o receptor (usurios)? Que aspectos das limitaes, motivaes, crenas e
preferncias do usurio, tal como interpretado pelo designer, devem ser comunicados
aos usurios reais para que eles assumam seu papel como interlocutores do sistema;
qual o contexto da comunicao? Que elementos do contexto de interao
psicolgico, sociocultural, tecnolgico, fsico etc. devem ser processados pelo
sistema, e como;
qual o cdigo da comunicao? Que cdigos computveis podem ou devem ser
utilizados para apoiar a metacomunicao eficiente, ou seja, qual deve ser a linguagem
de interface;
qual o canal? Quais canais de comunicao esto disponveis para a
metacomunicao designerusurio, e como eles podem ou devem ser utilizados;
qual a mensagem? O que o designer quer contar aos usurios, e com que efeito, ou
seja, qual a inteno comunicativa do designer.

Sobre o Cdigo Utilizado na Metacomunicao


Com relao ao cdigo da comunicao, mesmo que as interfaces de sistemas
compartilhem diversos padres interativos, cada sistema possui uma linguagem
interativa nica, cuja semntica determinada pelo modelo semntico nico do sistema
(de Souza e Leito, 2009, p. 9; de Souza, 2005a). necessrio que os designers construam
essa linguagem, definindo os cdigos expressivos que os usurios devero utilizar para
se comunicarem com o sistema.
A engenharia semitica classifica os signos utilizados em uma linguagem de interface
em trs tipos (de Souza et al., 2006; de Souza e Leito, 2009, p. 19):
signos estticos: signos que expressam o estado do sistema e cujo significado
interpretado independentemente de relaes causais e temporais da interface. Eles
podem ser interpretados a partir de um retrato da interface num momento do tempo.
So exemplos de signos estticos: o layout geral geral e a disposio de elementos em
uma tela, os itens de menu, os botes de uma barra de ferramentas, os campos e
botes de um formulrio e o contedo expresso em um texto, lista, tabela, rvore ou
outra forma de visualizao que no inclua animaes.
signos dinmicos: signos que expressam o comportamento do sistema, envolvendo
aspectos temporais e causais da interface. Esto vinculados prpria interao e
devem ser interpretados fazendo referncia a ela. So exemplos de signos dinmicos:
a associao causal entre a escolha de um item de menu e a exibio do dilogo, a
possibilidade de arrastar itens de uma rea da tela para outra, o deslocamento do foco
da entrada de dados durante o preenchimento de um formulrio, a ativao e
desativao de um boto de comando e o surgimento de uma dica sobre um elemento
de interface ao ser sobreposto pelo cursor do mouse.
signos metalingusticos: signos principalmente verbais e que se referem a outros
signos de interface, sejam eles estticos, dinmicos ou mesmo metalingusticos. Em
geral, ocorrem na forma de mensagens de ajuda e de erro, alertas, dilogos de
esclarecimento, dicas e assemelhados. Atravs de signos metalingusticos, os
designers podem explicitamente comunicar aos usurios os significados codificados
no sistema e como eles podem ser utilizados.
A Seo 10.1.3 descreve o papel desses tipos de signo no mtodo de inspeo semitica.

Sobre o Papel do Designer na Engenharia Semitica


Ao incluir o designer no modelo do espao de design, a engenharia semitica ressalta a
importncia do seu papel ativo na interao. O designer deve se posicionar como um
interlocutor engajado em ajudar os usurios a entenderem a metamensagem, a sua viso
sobre o que os usurios querem ou precisam fazer utilizando o sistema e por que essa
viso faz sentido para ele, bem como questes de design relevantes para esse
entendimento. Para isso, o designer deve refletir sobre os tipos de estratgias
comunicativas que ele pode utilizar, os tipos de signos que ele pode projetar na
linguagem de interface e as consequncias que as limitaes dos significados
computacionais trazem para a interao (de Souza e Leito, 2009).
Devido natureza evolutiva e imprevisvel da semiose humana, o designer no tem
como determinar de que maneira os usurios interpretaro os signos da interface, nem
mesmo garantir que eles utilizaro o cdigo correto para essa interpretao. Alm disso,
de Souza (2005a, p. 21; 2005b) ressalta que os usos mais sofisticados de sistemas
computacionais interativos com frequncia no so autoevidentes. Por exemplo, no h
uma correspondncia bvia de estilos de formatao em um editor de texto com algum
meio de formatar textos no mundo real, e a mera existncia de elementos de interface
relacionados ao uso desses estilos no suficiente para o usurio interpret-los
adequadamente. Portanto, necessrio que o designer tenha como objetivo introduzir aos
usurios um sistema computacional interativo, e no apenas produzi-lo (de Souza, 2005a,
p. 22; 2005b). Essa mudana de foco visa considerar em primeiro lugar os aspectos
estratgicos da tecnologia (i.e., que valor a tecnologia agrega s suas atividades e como
tirar melhor partido dela, escolhendo qual dos caminhos de interao disponveis seguir
em determinada situao), deixando para um segundo momento seus aspectos
operacionais (i.e., como utiliz-la, incluindo os tipos de aes que os usurios devem
realizar e os recursos de que precisam para isso). Vale ainda observar que boa parte das
diretrizes de design em IHC se referem a aspectos operacionais da tecnologia.
Como visto na Seo 2.2.3, a engenharia semitica considera a comunicabilidade de um
sistema interativo fundamental para que os usurios faam um bom uso da tecnologia. O
conhecimento dos aspectos estratgicos da tecnologia se tornam ainda mais importantes
em circunstncias imprevistas ou infrequentes, em que no basta saber como usar o
sistema, mas tambm necessrio saber por que se pode ou deve utilizar o sistema de uma
determinada maneira em uma determinada situao.
A engenharia semitica pode ser articulada com a perspectiva de reflexo em ao
estabelecida por Schn para caracterizar a prtica profissional (Schn, 1983; de Souza,
2005a; Seo 4.2). Schn v cada problema de design como um problema nico, cuja
definio requer um estudo cuidadoso de situaes mal definidas, caracterizadas pela
sua complexidade, incerteza, instabilidade, unicidade e conflito de valores (Schn,
1983, p. 39). De Souza sumariza a epistemologia da prtica de Schn indicando que
pesquisadores e designers sempre participam de cinco atividades principais:
aproximao do problema, formulao do problema, gerao de solues candidatas,
avaliao de solues candidatas e reorganizao do conhecimento (de Souza, 2005a, p.
106). Para apoiar essas atividades centradas no conhecimento, a engenharia semitica
props um conjunto de ferramentas epistmicas para avaliao e design de IHC.
Uma ferramenta epistmica no gera diretamente uma resposta ou soluo para o
problema. Em vez disso, apoia o designer na explorao do espao e da natureza do
problema, bem como das restries sobre solues candidatas (de Souza, 2005a, p. 33).
Dentre as ferramentas epistmicas propostas pela engenharia semitica, o Captulo 7
apresenta modelos de design da interao e de ajuda, e o Captulo 10 apresenta os
mtodos de inspeo semitica e de avaliao de comunicabilidade (Sees 10.1.3 e 10.2.2,
respectivamente).

3.8.4 Comparao Com O Design Centrado No Usurio


Como visto na Seo 3.4, o objetivo do designer na engenharia cognitiva que o usurio
seja capaz de, atravs da interao com a imagem do sistema, construir um modelo
conceitual compatvel com o modelo de design. Nas abordagens de cunho cognitivo, o
aprendizado dos usurios um importante objeto de investigao. No entanto, o foco na
usabilidade da imagem do sistema promove principalmente a considerao dos aspectos
operacionais da interao usuriosistema, em detrimento a seus aspectos estratgicos.
Dessa maneira, pode alienar os usurios e impedir o alcance do alfabetismo
computacional pleno (de Souza e Leito, 2009, p. 8).
Diferentemente do design centrado no usurio adotado pela engenharia cognitiva, na
engenharia semitica os designers no tentam apenas construir a imagem do sistema, ou
seja, produzir tecnologia, mas tambm introduzir a tecnologia criada (de Souza, 2005a;
2005b). Seu principal objeto de investigao a comunicao, e no o aprendizado. Como
visto, na engenharia semitica, o designer (na forma de seu preposto) um interlocutor
presente no momento da interao, e a sua comunicao com o usurio sobre as
estratgias de comunicao e atuao codificadas no sistema permite que o usurio
utilize o sistema de maneira mais adequada situao em que se encontra. Alm disso,
no caso de ocorrer uma situao inesperada, o usurio com conhecimento estratgico
sobre o sistema ter melhores condies de interagir com ele de forma criativa e
produtiva. A fim de contribuir com o alfabetismo computacional, a engenharia semitica
tem como foco a comunicao no apenas dos aspectos operacionais e tticos da
metacomunicao, mas tambm dos seus aspectos estratgicos.
importante deixar claro que o fato de a engenharia semitica privilegiar a
comunicao da viso e inteno de design no significa que os usurios sejam menos
importantes que os designers. Todo esforo de design de sistemas computacionais
interativos visa melhorar a vida das pessoas que os utilizam, satisfazendo suas
necessidades e expectativas (de Souza e Leito, 2009, p. 16).
Atividades
1. Aplicao da lei de Hick-Hyman. Calcule o tempo mdio necessrio para achar um livro
em uma lista de 25, 50 e 100 livros numa pgina. Assuma que os itens esto em ordem
alfabtica e que no h necessidade de rolagem.
2. Aplicao da lei de Fitts. Considerando estritamente o desempenho humano, que
cuidados podem ser tomados para que os itens de um menu pop-up vertical sejam
igualmente acessveis, sem modificar a orientao vertical do menu?
3. O nmero mgico 7 2. Explique por que o estudo de Miller no corrobora a seguinte
afirmao: O nmero de opes apresentadas para o usurio em cada tela deve ser 7
2.
4. Princpios de Gestalt. Escolha algumas telas complexas de uma aplicao que voc
utilize com frequncia e verifique se os princpios de Gestalt esto sendo bem
utilizados. Caso contrrio, reprojete a tela para fazer melhor uso desses princpios.
5. Planos e aes situadas. Examine manuais de instrues de diferentes dispositivos de
base computacional (e.g., aparelhos de telefone celular, mquinas fotogrficas
digitais) e sistemas interativos (e.g., editores de texto, planilhas eletrnicas). Voc
consegue imaginar uma situao em que seguir as instrues do fabricante no leva
ao resultado desejado? Por que voc acredita que isso acontea? Utilizando as
tecnologias de informao e comunicao disponveis atualmente, como voc
reduziria ou resolveria esse problema?
6. Mapeamento entre variveis psicolgicas e fsicas. Examine alguns aparelhos
eletrodomsticos na sua residncia (fogo, torradeira, geladeira, mquina de lavar
roupa, televisor, telefone) e analise o mapeamento entre as variveis psicolgicas e
fsicas envolvidas no uso desses aparelhos. Faa o mesmo para o editor de texto e para
o editor de planilhas da sua preferncia.
7. Golfos de execuo e avaliao. Escolha um modelo de aparelho de telefone celular e
descreva os passos dos golfos de execuo e avaliao percorridos por um usurio com
o objetivo de inserir um novo nmero de telefone na agenda do aparelho. De que
maneira os passos seriam diferentes para usurios com caractersticas distintas (e.g.,
um adolescente com muita familiaridade com seu aparelho e um senhor de terceira
idade que acaba de adquirir seu primeiro aparelho de telefone celular)?
8. Elementos de uma atividade. Observando um dia tpico de trabalho seu ou de um
colega, defina os elementos envolvidos nas diversas atividades realizadas. Avalie a
forma como os diversos artefatos utilizados mediam essas atividades.
9. Cognio distribuda. Faa uma anlise da cognio distribuda, conforme sugerido por
Perry (2003), de um sistema de publicao eletrnica de um jornal, levando em
considerao pelo menos os papis de jornalista, fotgrafo e editor.
10. Signos de interface. Examine uma aplicao que voc no esteja acostumado a
utilizar e procure identificar e classificar os diversos signos de interface que ela
apresenta.
11. Artefatos de metacomunicao. Examine uma aplicao disponvel em diferentes
dispositivos de base computacional e estilos de interao (e.g., calendrio num
ambiente grfico de janelas, na Web e em telefone celular). Com base nos
elementos do espao de design e nas perguntas propostas pela engenharia
semitica, caracterize a metacomunicao, implcita ou explcita, nesses diferentes
artefatos. A partir dessa caracterizao, analise a facilidade ou dificuldade de um
usurio acostumado com uma dessas aplicaes passar a utilizar uma outra, ou
ainda ficar alternando entre elas.
1
Algumas variaes desta frmula encontradas na literatura so: T = a + b log2(2D/S) e T = a + b log2(D/S + 1), onde a e b
so constantes determinadas empiricamente.
2
A expresso modelo de usurio possui vrios significados. Diversos trabalhos utilizam essa expresso como
significando uma representao do perfil e caractersticas do usurio, utilizadas em tempo de design ou embutidas no
sistema para realizar adaptaes durante a interao.
3
http://www.merriam-webster.com/dictionary/artifact.
4

Processos de Design de IHC


Objetivos do Captulo
Discutir as atividades envolvidas no design em geral e no design de um artefato
computacional interativo em particular.
Descrever os fenmenos de IHC sob diferentes perspectivas.
Apresentar processos de design de IHC propostos na literatura: modelo de ciclo de vida
simplificado, ciclo de vida em estrela, engenharia de usabilidade, design baseado em
cenrios, dirigido por objetivos e centrado na comunicao.
Discutir formas de integrar atividades de IHC e engenharia de software, incluindo
mtodos geis de desenvolvimento de software.
Desde sua concepo e durante todo o seu desenvolvimento, um sistema interativo deve
ter o propsito de apoiar os usurios a alcanarem seus objetivos. O projeto de um
sistema interativo um processo iterativo de anlise, sntese e avaliao, no qual
artefatos so coletados e produzidos visando no apenas construo do sistema, mas
tambm promoo de uma boa experincia de uso desse sistema. Neste captulo,
primeiro discutimos sobre a atividade de design e em seguida descrevemos alguns
processos de design de IHC propostos na literatura.
4.1 O Que Design?
Em nosso cotidiano, com frequncia lidamos com diversos artefatos. Artefatos so
produtos artificiais, fruto da inteligncia e do trabalho humano, construdos com um
determinado propsito em mente. So artefatos, por exemplo: um copo, um pente, um
sof, um carro, uma msica e uma receita de bolo. Um artefato no surge
espontaneamente na natureza. Algum decide sua funo, forma, estrutura e qualidade,
e o constri com seu trabalho (Lwgren e Stolterman, 2004). A insero de um artefato
numa situao do cotidiano representa uma interveno sobre ela, em alguma medida, e
a prpria situao influencia a forma como o artefato utilizado. Por exemplo, ter ou no
uma geladeira em casa modifica significativamente a forma como os alimentos so
conservados. Por sua vez, a conservao de alimentos influencia a escolha e a quantidade
de produtos comprados, bem como a frequncia de compra.
A introduo de um artefato pode trazer consequncias positivas e negativas para a
situao atual. Por exemplo, adquirir uma bicicleta pode significar: mudar o meio de
transporte utilizado para vrias atividades, como ir ao trabalho, padaria ou fazer um
passeio; a economia de dinheiro gasto em outros meios de transporte; a prtica de
esportes para uma vida mais saudvel; e ajuda na preservao do meio ambiente. Nesse
sentido, adquirir uma bicicleta uma interveno positiva. No entanto, o dono da
bicicleta agora precisa reservar um local em sua casa para armazen-la, e comprar um
capacete e outros equipamentos para utilizar a bicicleta com segurana. Essas podem ser
consideradas consequncias negativas da interveno realizada.
Quando analisamos uma situao, considerando as pessoas, artefatos, processos,
demais elementos e relaes entre eles, podemos encontrar problemas, caractersticas
desagradveis ou algo que podemos melhorar.
comum tomarmos atitudes para resolver os problemas, diminuir as caractersticas
desagradveis e melhorar o que mais for possvel. Essas atitudes envolvem atividades de
design, conscientes ou inconscientes, realizadas com um cuidado maior ou menor. Em
termos bem gerais (Lawson, 2006; Lwgren e Stolterman, 2004), podemos caracterizar a
atividade de design como sendo (Figura 4.1):
a anlise da situao atual: estudar e interpretar a situao atual;
a sntese de uma interveno: planejar e executar uma interveno na situao atual;
a avaliao da nova situao: verificar o efeito da interveno, comparando a situao
analisada anteriormente com a nova situao, atingida aps a interveno.
FIGURA 4.1 Atividades de design envolvidas na interveno para transformar a situao atual (situao 1) em
uma situao desejada (situao 2).

Na anlise da situao atual, buscamos conhecer os elementos envolvidos e as relaes


entre eles. Dentre os diversos elementos, geralmente so analisados: pessoas, artefatos, e
processos. Como resultado, obtemos uma interpretao da realidade estudada, atravs
de um enquadramento e um recorte particular dela. A complexidade e a dinmica da
realidade fazem com que alguns (aspectos dos) elementos e suas relaes sejam
enquadrados e outros no. O foco da anlise da situao atual depende de vrios fatores,
como, por exemplo, os assuntos sendo tratados (o domnio), os objetivos das pessoas
envolvidas (usurios e demais stakeholders), tempo, oramento e mo-de-obra
disponveis, e at mesmo a filosofia de trabalho. Diferentes focos de anlise contribuem
para diferentes interpretaes da situao atual. Por exemplo, se o objetivo de uma
organizao for aumentar a produtividade dos seus funcionrios, a anlise da situao
atual pode concentrar esforos na investigao de atividades ineficientes. De outra
forma, se o objetivo da organizao for compreender os motivos pelos quais seus
funcionrios no utilizam como esperado os sistemas computacionais oferecidos, a
anlise da situao atual pode concentrar esforos em compreender a opinio dos
funcionrios sobre esses sistemas.
A anlise da situao atual frequentemente denominada de anlise do problema.
Entretanto, a anlise nem sempre aborda uma situao problemtica. Mesmo que a
situao atual seja satisfatria, pode surgir uma oportunidade, por conta de uma nova
tecnologia, por exemplo, de atingirmos uma situao ainda mais desejvel. Nesse caso, a
anlise da situao atual importante para identificar as condies em que uma nova
tecnologia pode ser empregada para melhorar o que j satisfatrio. O problema a ser
resolvido encontrar uma boa forma de melhorar uma ou mais caractersticas da situao
atual. Em outras palavras, resolver um problema de design significa responder a
pergunta: Como melhorar a situao atual?
Quando se trata de sistemas computacionais, comum investigarmos todos os
elementos envolvidos durante o uso: os usurios com suas caractersticas, necessidades e
preferncias; as atividades e os objetivos em questo, considerando os artefatos e
sistemas computacionais utilizados; e o contexto fsico, social e cultural de uso ao longo
do tempo (Hackos e Redish, 1998; Sharp et al., 2007). Alm desses elementos diretamente
envolvidos no uso atual desses artefatos, tambm preciso conhecer e articular os
interesses das pessoas indiretamente envolvidas, como aquela que paga pelo sistema,
geralmente conhecida como cliente, e aquela que constri o sistema, normalmente
chamada de desenvolvedor.
A anlise da situao atual aponta as necessidades e oportunidades de melhoria para
as quais ser projetada uma interveno. Essas razes para a interveno costumam ser
representadas por metas de design. Em IHC, metas de design referemse no apenas aos
objetivos dos usurios que precisamos ou desejamos apoiar, mas tambm aos critrios de
qualidade de uso descritos na Seo 2.2. Por exemplo, durante a anlise de uma situao
possvel perceber que os usurios gastam muito tempo processando informaes que um
sistema computacional poderia fazer mais rapidamente. Nesse caso, uma meta de design
poderia ser: aumentar a eficincia das atividades (ou tarefas) do usurio, que um dos
fatores de usabilidade. J a anlise de uma outra situao identifica que vrios usurios
encontram dificuldades para usar sistemas semelhantes porque no compreendem como
funcionam. Nesse caso, uma meta de design poderia ser: comunicar adequadamente
atravs da interface a viso do designer sobre as operaes que o usurio pode realizar
com o sistema, ou seja, aumentar a comunicabilidade de um artefato computacional
interativo. Os Captulos 5 e 6 apresentam tcnicas e representaes utilizadas na
atividade de anlise.
A diferena entre a situao atual e uma situao desejada a motivao principal para
projetarmos e sintetizarmos uma interveno. Frequentemente, uma interveno
denominada de soluo, pois responde a pergunta que define um problema a ser
resolvido: Como melhorar esta situao?. Em alguns casos, uma interveno adequada
inserir na situao atual um novo sistema interativo ou uma nova verso de um sistema
existente, com o intuito de transform-la em uma situao desejada. Em outros casos,
pode ser necessria apenas uma mudana em processos, sem alterao dos sistemas
utilizados.
Quando a interveno envolve o desenvolvimento de sistemas interativos, ela deve
articular os interesses dos stakeholders com: (1) o conhecimento adquirido na anlise da
situao atual; (2) o conhecimento sobre intervenes bem e mal avaliadas em casos
semelhantes; e (3) o conhecimento sobre as possibilidades e limitaes das tecnologias
disponveis. Em particular, fundamental tomar o devido cuidado com a experincia que
pretendemos oferecer aos usurios durante o uso do sistema projetado. Dessa forma, o
projeto de um sistema interativo deve definir uma soluo de IHC com alta qualidade de
uso para impactar a situao atual e a vida dos usurios conforme pretendido. Como
visto na Seo 2.1, uma soluo de IHC compreende tanto a interface com usurio como os
processos de interao concebidos para apoiarem-no a alcanar seus objetivos. Os Captulos
7 e 8 discutem a atividade de design (sntese) de uma soluo de IHC, bem como as
representaes, diretrizes e padres utilizados.
Uma vez definida uma interveno, preciso avaliar se ela modifica a situao atual da
forma desejada. A avaliao de uma interveno pode ocorrer em vrios pontos do
processo de desenvolvimento:
durante a concepo e o desenvolvimento da interveno, para tentar prever seus
possveis impactos na situao atual (por exemplo, inspecionando as telas produzidas
durante o projeto da interface com usurio);
logo antes da introduo da interveno, para identificar consequncias negativas ou
problemas que possam ser evitados (por exemplo, fazendo testes com usurios e
produzindo material de treinamento a partir dos seus resultados); ou
depois da interveno ter sido aplicada, para verificar os impactos ocorridos (por
exemplo, avaliando como os usurios se apropriaram do sistema interativo desenvolvido
e quais mudanas ocorreram na sua prtica de trabalho).
Quando a interveno envolve um sistema interativo, existem vrios aspectos a serem
avaliados, alguns relacionados com a construo do sistema, como a facilidade de
manuteno e robustez (Pressman, 2002), outros com o seu uso, como a usabilidade e
acessibilidade. Em IHC, os esforos de avaliao se concentram na experincia vivenciada
pelos usurios durante a interao com a interface de um sistema interativo, ou seja,
durante o uso do sistema. Uma avaliao de IHC deve verificar se a interao e a interface
atendem aos critrios de qualidade de uso definidos como prioritrios pela anlise da
situao atual. A avaliao de IHC pode ser feita ao longo do processo de design ou
depois do produto pronto. Sempre que possvel, devemos avaliar a qualidade de uso
desde o incio do processo de design dos sistemas interativos, pois o custo de correo de
eventuais problemas ser menor. Os Captulos 9 e 10 apresentam conceitos e mtodos de
avaliao de IHC em detalhes.
4.2 Perspectivas de Design
Existem diferentes interpretaes para a atividade de design. Simon (1981) interpreta o
design sob uma perspectiva de racionalismo tcnico (technical rationality). Nessa
perspectiva, o designer pressupe que, para um determinado problema, h solues
conhecidas ou mtodos bem definidos e precisos para ger-las. Isso significa que as
solues esperadas certamente sero produzidas se esses mtodos forem seguidos. Essas
solues e mtodos empregam leis, princpios, normas e valores, geralmente
estabelecidos pela natureza, com base em disciplinas de cincias naturais e exatas, como
a Fsica, a Qumica e a Matemtica. Desse modo, a atividade de design se resume a
enquadrar uma situao num tipo geral de problema cuja forma de soluo seja
conhecida. Nessa perspectiva, no existe espao para o designer questionar ou mudar as
verdades estabelecidas pelas relaes de causa e consequncia (se eu fizer isto vai
acontecer aquilo).
Em oposio perspectiva de racionalismo tcnico, Schn (1983) props uma
perspectiva de reflexo em ao (reflection-in-action) para a atividade de design, como
visto na Seo 3.8.3. Nessa perspectiva, uma situao do cotidiano pode estar associada a
um problema, que considerado nico. Cada caso diferente do outro.
Consequentemente, o processo de design e a soluo encontrada tambm so nicos.
Desse modo, o designer no est procurando descobrir dicas [da situao atual que
apontam] para uma soluo padro. Em vez disso, procura descobrir as caractersticas
particulares de sua situao tida como problemtica, e a partir dessa descoberta gradual,
projeta uma interveno (Schn, 1983; p. 129). Portanto, o processo de concepo de
uma soluo o design semelhante ao processo de pesquisa cientfica, no qual a
construo de uma hiptese (a partir de uma interpretao da situao atual), a
experimentao (proposta de intervenes) e a avaliao so fundamentais.
Na perspectiva de reflexo em ao (Figura 4.2), o designer inicia seu trabalho
identificando e interpretando os elementos envolvidos na situao atual, os interesses
dos envolvidos direta e indiretamente com o sistema (stakeholders) e as possibilidades e
limitaes das tecnologias disponveis. Isso lhe permite formular um problema nico a
ser resolvido. Sendo assim, ele pode resolver tal problema nico explorando livremente
sua criatividade e utilizar ou no solues e mtodos de resoluo de problemas
conhecidos, conforme julgar apropriado.
FIGURA 4.2 Processo de reflexo em ao.

Durante a concepo de uma soluo, muito comum o designer explorar diferentes


ideias para poder compar-las e aproveitar o melhor de cada uma delas (Buxton, 2007).
As alternativas de soluo geradas durante a explorao de ideias costumam ser
representadas por algum desenho, maquete ou modelo. A representao de uma
alternativa de soluo tem um papel de manifestar (parte de) as ideias do designer para
outras pessoas envolvidas no projeto. Dessa forma, o cliente, o usurio e o desenvolvedor
podem compreender e opinar sobre o projeto do sistema, antes mesmo de ele ser
construdo e inserido no cotidiano das pessoas.
Segundo Schn (1983), a manifestao das ideias do designer em alguma representao
possui outro benefcio importante. Enquanto o designer expressa suas ideias, ele acaba
conversando com a representao, um fenmeno por ele denominado conversa com os
materiais (conversation with materials). Ora o designer fala com a representao,
expressando suas ideias para a soluo sendo concebida, como, por exemplo, E se eu
definir isso deste jeito?, Posso utilizar essa mesma ideia em outro lugar ou O que
acontece se eu modificar isso aqui?, ora a representao fala com o designer no
momento em que ele percebe o que concebeu e o avalia, se questionando, por exemplo,
sobre O que isso que eu representei? e descobrindo que Eu no entendi isso
direito, Isso diferente do que eu pensei que seria, mas interessante!, Isso est
desajeitado, isso no, Aquilo no parece bom para mim ou Isso no funciona (Schn
e Bennett, 1996).
Depois de expressar suas ideias em alguma representao, o designer tem uma
condio melhor de avali-las para verificar se a soluo proposta satisfaz seus objetivos.
Caso no encontre uma soluo satisfatria, o designer critica no apenas as solues que
se apresentam, mas tambm sua prpria formulao do problema, e experimenta
reformul-lo. Essa reformulao pode modificar os elementos envolvidos na situao
analisada e seus significados de uma maneira que no havia sido prevista pelo designer.
Dessa forma, o designer precisa continuar descobrindo e refletindo sobre quais so as
consequncias dessa reformulao para a prxima tentativa de resolver o problema. Ele
pode se perguntar, por exemplo: As consequncias dessa reformulao so desejveis?,
Que novos (potenciais) problemas foram criados?, O que melhorou com essa nova
reformulao?, e assim por diante. Nesse processo reflexivo, o esforo do designer para
resolver o problema reformulado produz novas descobertas que estimulam novas
reflexes em ao (Schn, 1983, p. 132), at que uma ao do designer d origem a uma
soluo satisfatria.
Resumindo, a reflexo em ao ocorre enquanto o designer conversa com (age sobre) a
representao, refletindo, avaliando e aprendendo sobre o que est fazendo enquanto o
faz, de forma que essas reflexes influenciem aes futuras em direo concepo da
soluo. Segundo o prprio Schn:

Refletir em ao interagir com o modelo, obter resultados surpreendentes, tentar


interpret-los, e ento inventar novas estratgias de ao com base nas novas
interpretaes (Schn e Bennett, 1996, p. 181).

Algumas pessoas, na tentativa de resolver um problema em IHC, buscam aplicar


diretamente padres de interface no projeto de sistemas interativos, numa perspectiva de
racionalismo tcnico. Entretanto, esses padres no fornecem solues prontas para um
problema genrico, mas sim um repertrio de solues conhecidas para problemas
especficos e contextualizados. Como descrito na Seo 8.3, padres de design de
interface devem ser cuidadosamente analisados e adaptados a cada projeto (Tidwell,
2005; Borchers, 2001). Em outras palavras, devem ser utilizados numa perspectiva
reflexiva alinhada epistemologia da prtica de Schn (1983).
Conceber uma soluo adequada ao problema no uma tarefa simples, e geralmente
requer uma equipe multidisciplinar de design. Ela exige do designer as seguintes
habilidades e conhecimentos (Lwgren e Stolterman, 2004, p. 45):
criatividade e capacidade de anlise para criar e modelar ideias;
capacidade de crtica e julgamento para decidir;
capacidade de comunicao e negociao para trabalhar com clientes, usurios e
desenvolvedores;
conhecimento sobre as tecnologias disponveis para projetar qualidades estruturais e
funcionais;
conhecimento sobre valores e ideais dos envolvidos para projetar qualidades ticas;
capacidade de apreciar e compor coisas agradveis aos sentidos para projetar qualidades
estticas.
4.3 Processos de Processos de Design de IHC
Como visto na seo anterior, o design um processo que envolve as seguintes atividades
bsicas: a anlise da situao atual (identificao do problema), a sntese de uma
interveno e a avaliao dessa interveno projetada ou j aplicada situao atual.
Cada processo de design detalha essas atividades bsicas de uma forma particular,
definindo: como executar cada atividade; a sequncia em que elas devem ser executadas;
quais atividades podem se repetir, e por quais motivos; e os artefatos consumidos e
produzidos em cada uma delas.
Uma caracterstica bsica dos processos de design de IHC a execuo das atividades
de forma iterativa, permitindo refinamentos sucessivos da anlise da situao atual e da
proposta de interveno. Dessa forma, o designer tem boas oportunidades de aprender
mais e melhor tanto sobre o problema a ser resolvido quanto sobre a soluo sendo
concebida.
Geralmente os processos de design de IHC comeam analisando a situao atual.
Quando o designer considera ter adquirido conhecimento suficiente sobre essa situao
e identificado as necessidades e oportunidades de melhoria, ele prossegue seu trabalho
sintetizando (concebendo, modelando e construindo) uma interveno. Enquanto ele
projeta uma interveno, pode sentir necessidade de conhecer mais ou rever uma
interpretao anterior sobre a sua anlise da situao atual. Assim, ele volta atividade
anterior para ampliar, refinar ou reformular sua interpretao, numa nova iterao do
processo de design. Com a reviso da anlise, o designer amplia, refina ou reformula a
sua proposta de interveno.
Tendo uma proposta de interveno em mos, o designer passa a avali-la para julgar
se ela satisfatria. Durante essa avaliao, o designer pode perceber que ainda precisa
rever sua anlise ou sua proposta de interveno. Esse processo iterativo se repete
quantas vezes forem necessrias, at o designer obter uma interveno satisfatria. O
incio do processo de design tende a ter uma iterao maior entre a anlise da situao
atual e a sntese da interveno, enquanto o final do processo tende a ter uma iterao
mais acentuada entre a sntese e a avaliao da interveno.
Mesmo executando essas trs atividades bsicas do processo de design de forma
iterativa, possvel empregar quantidade de tempo e esforo diferente em cada uma
delas. Por exemplo, podemos ter um design dirigido pelo problema ou dirigido pela
soluo. O design dirigido pelo problema despende mais tempo analisando a situao atual,
as necessidades e as oportunidades de melhoria (o problema), e menos tempo
explorando possveis intervenes (as solues). O design dirigido pela soluo faz
exatamente o contrrio, emprega pouco tempo analisando a situao atual, e mais tempo
explorando possveis intervenes. Kruger e Cross (2006) realizaram um experimento
com designers experientes desempenhando a mesma tarefa para comparar as estratgias
de design seguidas por eles (dirigidas pelo problema ou pela soluo) e a qualidade das
solues obtidas. Eles concluram que a qualidade geral das solues no estava
diretamente relacionada com a estratgia seguida. Observaram ainda que os designers
que atuaram dirigidos pela soluo produziram, em mdia, resultados mais criativos,
mas com menos preocupao com os aspectos estticos, ergonmicos, tcnicos e
comerciais. A criatividade parece ter sido favorecida pela explorao de mais ideias para
possveis solues.
Alguns processos de design de IHC prescrevem qual deve ser a primeira atividade a
ser realizada, bem como a sequncia de transies entre elas. Lawson (2006) questiona
essa sequncia estrita de atividades de design. Para ele, possvel iniciar o processo de
design em qualquer atividade e realizar qualquer transio durante o processo quantas
vezes forem necessrias (Figura 4.3). Dessa forma, cabe ao designer decidir qual ser a
primeira atividade a ser executada e as transies entre atividades que ele vai realizar. O
que realmente importa, segundo Lawson, partirmos de um problema (as necessidades
e oportunidades de melhoria na situao atual), realizarmos o processo de design
(atividades de anlise, sntese e avaliao) e no final chegarmos a uma soluo (uma
proposta de interveno).

FIGURA 4.3 Sequncia genrica de atividades durante o processo de design (adaptado de Lawson, 2006).

Os processos de design de IHC buscam atender e servir em primeiro lugar aos


usurios e aos demais envolvidos (stakeholders), e no s tecnologias. Boa parte desses
processos centrada no usurio, isto , seguem estes princpios (Gould e Lewis, 1985, p.
300):
foco no usurio: o designer deve projetar a interao e a interface de um sistema interativo
para atender s necessidades dos usurios e ajud-los a alcanarem seus objetivos.
Sendo assim, o designer deve estudar quem sero os usurios do sistema, seus
objetivos, suas caractersticas fsicas (capacidade de movimentos, viso, audio etc.),
cognitivas e comportamentais, sua formao educacional (capacidade de leitura e
escrita, conhecimentos adquiridos etc.), e o que eles costumam fazer para alcanar seus
objetivos;
mtricas observveis: o processo de design deve permitir a realizao de experimentos
(estudos empricos) em que representantes dos usurios usem simulaes ou prottipos
do sistema para realizarem suas atividades e alcanarem seus objetivos. Durante o
experimento, a performance e as reaes dos usurios devem ser observadas,
registradas e analisadas;
design iterativo: quando problemas forem encontrados durante os experimentos com
usurios, eles devero ser corrigidos. Isso significa que as atividades do processo de
design devem ser iterativas, ou seja, o ciclo de projeto, avaliao com medies
empricas e reprojeto deve se repetir quantas vezes forem necessrias.
Os processos de design de IHC destacam a importncia de envolver os usurios
durante suas atividades para dar-lhes oportunidade de participar, direta ou
indiretamente, nas decises tomadas. Quanto mais cedo os usurios forem envolvidos no
processo de design, mais cedo ser possvel aprender sobre suas necessidades e assim
influenciar positivamente a sntese da soluo, bem como identificar e corrigir eventuais
problemas. Isso nos permite desenvolver um sistema interativo mais interessante para os
usurios e com maior qualidade de uso, porque temos acesso s interpretaes e opinies
dos usurios sobre o resultado do design.
Como discutido no Captulo 1, uma equipe multidisciplinar contribui para o design de
IHC. Cada profissional observa e interpreta a situao atual de um ponto de vista
particular, que contribui para enriquecer a identificao das necessidades e
oportunidades de melhoria (a identificao e anlise do problema). Uma equipe de
pessoas formadas em diferentes reas de conhecimento favorece a sntese (projeto) de
uma interveno, pois facilita o surgimento e a explorao de ideias diversas. Alm disso,
uma equipe multidisciplinar tambm permite uma avaliao mais rica e diferenciada das
intervenes (solues) propostas. Sempre que houver recursos disponveis, devemos
investir em uma equipe multidisciplinar de design de IHC.
Preece, Sharp e Rogers (Preece et al., 2002; Sharp et al., 2007) organizaram as atividades
de design de IHC em um modelo de processo de design simples, ilustrado na Figura 4.4.
Esse processo de design de IHC destaca a importncia do design centrado no usurio, de
avaliaes da proposta de soluo usando verses interativas e da iterao entre as
atividades.

FIGURA 4.4 Modelo simples de processo de design de IHC (adaptado de Sharp et al., 2007).

Considerando a sequncia genrica de atividades de design identificada por Lawson


(2006), observamos que Preece e coautoras segmentam a atividade de sntese em: design
(ou redesign) conceitual e na construo de uma verso interativa.
Durante o (re)design da interao e da interface, o designer explora diferentes ideias
em alternativas de design para elaborar uma soluo adequada s necessidades e aos
requisitos definidos na atividade de anlise. O resultado dessa atividade de design pode
ser registrado em descries textuais da interao (cenrios), esboos de interface
(desenhos de tela) ou em qualquer modelo ou representao da interface e da interao
usuriosistema.
Para melhor avaliar o design resultante, o designer constri verses interativas das
propostas de soluo que simulem o funcionamento da interface e deixem clara a
interao projetada. Isso facilita a participao dos usurios durante a avaliao de IHC.
Assim como a maior parte dos processos de design, esse modelo de processo tambm
bastante iterativo. Cada atividade pode revelar a necessidade de retornar a uma
atividade anterior para ampliar, refinar ou retificar algum entendimento ou artefato
produzido. A iterao entre as atividades ocorre quantas vezes forem necessrias,
limitada apenas pelo oramento, tempo e recursos disponveis. Idealmente o processo de
design concludo com uma avaliao de que a soluo de IHC atende s necessidades e
aos requisitos identificados. O produto final uma especificao da interao e da
interface com usurio que servir de insumo nas fases seguintes de desenvolvimento do
sistema iterativo.
Existem vrias outras propostas de processos de design de IHC. Cada uma privilegia
uma forma de pensar, uma sequncia de atividades ou o emprego de certos artefatos.
Dentre as propostas existentes este livro apresenta brevemente o ciclo de vida em estrela
(Hix e Hartson, 1993), dois ciclos de vida para Engenharia de Usabilidade (Nielsen, 1993;
Mayhew, 1999), o design contextual (Beyer e Holtzblatt, 1998), o design baseado em
cenrios (Rosson e Carroll, 2002), o design dirigido por objetivos (Cooper et al., 2007) e o
design centrado na comunicao (Barbosa et al., 2004).

4.3.1 Ciclo De Vida Em Estrela


O ciclo de vida em estrela foi desenvolvido por Hix e Hartson no incio da dcada de 1990
(Hix e Hartson, 1993) e foi um dos primeiros ciclos de vida voltados para IHC
amplamente difundidos. Esse processo composto por seis atividades, conforme
ilustrado na Figura 4.5.
FIGURA 4.5 Ciclo de vida em estrela.

A anlise de tarefas, de usurio e funes a atividade responsvel pelo aprendizado


da situao atual e pelo levantamento das necessidades e oportunidades de melhoria. A
atividade de especificao de requisitos de IHC consolida uma interpretao da anlise,
definindo os problemas que devem ser resolvidos com o projeto de uma soluo de IHC.
A atividade geral de sntese segmentada em trs atividades: projeto conceitual e
especificao do design, na qual a soluo de IHC concebida; prototipao, na qual
verses interativas das propostas de soluo so elaboradas para serem avaliadas; e
implementao, na qual o sistema interativo final desenvolvido. Essa ltima atividade
est fora do escopo deste livro, pois j abordada extensamente na literatura de
Engenharia de Software.
A atividade de avaliao aparece no modelo como central, e de fato desdobrada na
avaliao dos resultados de cada uma das demais atividades. A avaliao deve verificar se
os dados coletados na atividade de anlise e os requisitos especificados esto de acordo
com a realidade e atendem s necessidades dos usurios. Deve tambm detectar
problemas de usabilidade (e dos demais critrios de qualidade de uso discutidos na
Seo 2.2) nas representaes de design, nos prottipos e no sistema final. Hix e Hartson
ressaltam que importante avaliar o que foi produzido desde o incio, enquanto ainda h
tempo para corrigir os erros com um custo reduzido.
No ciclo de vida em estrela, cabe ao designer decidir qual atividade deve ser realizada
primeiro, dependendo do que estiver disponvel quando iniciar o processo. Por exemplo,
se a inteno for projetar uma nova verso do sistema, o designer pode comear o projeto
da nova verso pela avaliao da verso atual. Em outro caso, pode ser necessrio
implementar o mesmo sistema em outra plataforma semelhante, como outro sistema
operacional, por exemplo. Sendo assim, o designer pode optar por comear pela
implementao do sistema, aproveitando o projeto que havia sido feito para a plataforma
anterior. Para projetar um novo sistema, comum comear pela anlise de tarefas,
usurios e funcional e seguir no sentido horrio pelas atividades na Figura 4.5.
Assim como na sequncia genrica de atividades de design identificada por Lawson
(2006), o ciclo de vida em estrela tambm iterativo e no prescreve a sequncia das
atividades. A nica exigncia aqui que, aps concluir cada atividade, o designer avalie
os resultados obtidos para verificar se ele encontrou ou est no caminho de encontrar
uma soluo satisfatria. Todas as atividades do ciclo de vida em estrela esto
interligadas pela atividade de avaliao, ou seja, sempre preciso passar por uma
avaliao ao concluir uma atividade e antes de iniciar outra.

4.3.2 Engenharia De Usabilidade De Nielsen


Jakob Nielsen (1993) definiu engenharia de usabilidade como um conjunto de atividades
que devem ocorrer durante todo o ciclo de vida do produto, ressaltando que muitas delas
ocorrem nos estgios iniciais do projeto, antes que a interface com usurio em si seja
projetada. Nielsen prope o seguinte conjunto de atividades em seu ciclo de vida:
1. Conhea seu usurio
2. Realize uma anlise competitiva
3. Defina as metas de usabilidade
4. Faa designs paralelos
5. Adote o design participativo
6. Faa o design coordenado da interface como um todo
7. Aplique diretrizes e anlise heurstica
8. Faa prottipos
9. Realize testes empricos
10. Pratique design iterativo
Nesse ciclo de vida, o primeiro passo consiste em estudar os usurios e os usos
pretendidos do produto. Segundo Nielsen, as caractersticas de usurios individuais e a
variabilidade nas tarefas so os fatores de maior impacto na usabilidade. Ele utiliza o
termo usurio de forma ampla, incluindo todos aqueles cujo trabalho afetado de
algum modo pelo produto, isto , usurios diretos e demais stakeholders.
Essa atividade envolve conhecer as caractersticas individuais dos usurios e do seu
ambiente fsico e social de trabalho (veja Seo 5.2), suas atividades (veja Seo 6.4) e as
formas como lidam com circunstncias excepcionais e emergenciais. Nielsen sugere
procurar usurios especialmente eficientes e que desenvolveram suas prprias
estratgias para contornar as limitaes dos sistemas existentes. Durante esse estudo,
fundamental ir alm das atividades dos usurios tal como so realizadas atualmente,
buscando identificar a razo funcional subjacente a cada atividade: o que realmente
precisa ser feito, ou seja, os objetivos finais dos usurios e demais stakeholders.
Nielsen alerta para o fato de que os usurios no sero os mesmos aps a introduo
do sistema. O sistema modifica os usurios, e medida que isso ocorre eles usaro o
sistema de novas formas, num fenmeno denominado por Carroll e Rosson (1991)
coevoluo de tarefas e artefatos. Embora seja impossvel prever todas as mudanas, um
design mais flexvel, adaptvel ou extensvel tem mais chances de apoiar esses novos
usos (de Souza, 2005a; de Souza e Barbosa, 2005).
A anlise competitiva consiste em examinar produtos com funcionalidades
semelhantes ou complementares. Como esses produtos j esto prontos, podem ser
testados com mais facilidade e realismo do que prottipos. Eles podem ser inspecionados
e testados visando avaliar tanto as funcionalidades que apoiam como as questes de IHC
tidas como relevantes para o projeto. Como resultado, o designer pode obter um
conjunto de informaes sobre o que funciona e o que no funciona naquele domnio, o
que pode ser aperfeioado, e por qu. Nielsen ressalta que a anlise competitiva envolve
no apenas sistemas computacionais interativos, mas tambm qualquer outra forma de
atividade de usurios com objetivos semelhantes. Por exemplo, antes de projetar uma
agenda eletrnica, devemos investigar no apenas as agendas eletrnicas disponveis,
mas tambm a forma como as pessoas utilizam agendas em papel.
A definio das metas de usabilidade envolve definir os fatores de qualidade de uso
que devem ser priorizados no projeto, como sero avaliados ao longo do processo de
design, e quais faixas de valores so inaceitveis, aceitveis e ideais para cada indicador
de interesse. Com frequncia, essa priorizao se baseia nos indicadores atuais de
desempenho dos usurios ao utilizarem o sistema. O Exemplo 4.1 ilustra uma definio
de metas de usabilidade para um sistema de busca de um livro num quiosque de livraria.

Exemplo 4.1
M etas de usabilidade para um sistema de
busca de livros em uma livraria
Considere um sistema de quiosque de livraria pouco utilizado, em que 50%
dos usurios desistem de fazer uma busca por um livro antes de conclu-la.
Podemos estabelecer como metas que mais pessoas utilizem o sistema e
que somente 30% dos usurios abandonem a tarefa de busca. As metas de
usabilidade para esse projeto podem ser: aumentar a facilidade de
aprendizado e a eficincia do sistema. Os indicadores correspondentes
poderiam ser: nmero de usurios que acessam o sistema em diferentes
dias da semana; proporo de usurios que completam/abandonam a
tarefa de busca; tempo que cada usurio leva para concluir a tarefa com
sucesso; tempo que cada usurio despende antes de abandonar a tarefa;
nmero de erros cometidos.
Para avaliar melhor essas metas, podemos conduzir um estudo para
avaliar qual o problema principal. Vamos supor que o estudo revele que
os principais problemas enfrentados pelos usurios so a dificuldade de
uso (e.g., o usurio no sabe o que fazer num determinado momento por
falta de instrues e controles claros na interface de usurio) e a
ineficincia no uso do sistema (e.g., o usurio desiste quando descobre que
h passos intermedirios aparentemente desnecessrios no processo de
busca). Com base nesses resultados e nos dados quantitativos coletados,
podemos ento estabelecer as faixas de valores aceitveis e ideais para cada
indicador, conforme ilustrado pela Figura 4.6.
FIGURA 4.6 Faixas de valores para indicadores de usabilidade.

Durante a definio das metas de usabilidade, podemos estabelecer tambm metas de


retorno de investimento, atravs de uma anlise de custo e benefcio envolvendo o
sistema ou a prtica atual, as despesas com o projeto do novo sistema e a economia que o
seu uso deve proporcionar. Bias e Mayhew (2005) discutem diversas formas de avaliar o
retorno de investimento. Podemos, por exemplo, calcular o tempo que um funcionrio
leva para realizar o seu trabalho antes e depois da introduo do novo sistema, e
computar o ganho monetrio com base no salrio desse funcionrio e o tempo
economizado.
Nielsen advoga o design paralelo, que consiste em elaborar diferentes alternativas de
design, de preferncia por trs ou quatro designers trabalhando de forma independente,
para ento selecionar as que vo ser detalhadas nas atividades seguintes do processo.
Nessa etapa, cada designer deve empregar pouco tempo (desde algumas horas at dois
dias) para elaborar seus designs iniciais e, portanto, trata-se de uma forma bastante
barata de explorar o espao de soluo. Para motivar solues bem diferentes, podemos
solicitar a cada designer que explore um aspecto diferente do problema, tais como:
usurios novatos vs. experientes; computador desktop vs. dispositivo mvel; interface
grfica vs. verbal vs. por caneta vs. por toque. Ao final dessa etapa, as solues
alternativas so analisadas e um design consolidado elaborado, geralmente
combinando elementos de mais de uma alternativa.
O design participativo, tambm advogado por Nielsen, consiste em a equipe de design
ter acesso permanente a um conjunto de usurios tidos como representativos da
populao-alvo de usurios. Isso importante porque, mesmo aps as atividades iniciais
de investigao, invariavelmente surgem questes ao longo do processo de design que
requerem novas consultas aos usurios. Nielsen alerta, no entanto, que os usurios no
so designers, ento no podemos esperar que eles produzam designs ou entendam
especificaes produzidas utilizando notaes que eles desconhecem, nem mesmo que
saibam definir com clareza o que querem ou precisam. Em vez disso, ele chama ateno
para a necessidade de produzirmos representaes dos designs propostos que eles
entendam facilmente, como prottipos, maquetes ou esboos de tela, para que eles
possam reagir s propostas, fornecer feedback informativo, levantar novas questes e
participar ativamente das discusses acerca das solues propostas. Alm disso,
devemos envolver diferentes usurios ao longo do projeto, para que as decises de
design no se baseiem em idiossincrasias de uma ou duas pessoas, e para que tenhamos
sempre um olhar novo sobre os designs propostos.
Para evitar inconsistncias na interface com usurio projetada, importante haver um
responsvel pelo design coordenado da interface, ou seja, da interface como um todo.
Isso inclui no apenas os elementos de interface propriamente ditos, mas tambm toda a
documentao, o sistema de ajuda e tutoriais produzidos sobre o sistema. Caso o
produto deva ser introduzido como parte de uma famlia de produtos, devemos
considerar a consistncia entre eles de forma holstica, mas sempre tomando o cuidado
para que a consistncia no adquira uma importncia desmedida a despeito das metas de
usabilidade prioritrias para o projeto.
Nielsen sugere que a equipe de design siga diretrizes, princpios bem conhecidos para
o design da interface com usurio. medida que a interface for projetada, deve ser feita
uma avaliao heurstica para avaliar se as diretrizes no esto sendo violadas (veja Seo
10.1.1). As diretrizes podem ser gerais, aplicveis a todas as interfaces com usurio;
especficas a uma categoria ou plataforma computacional (e.g., interfaces grficas baseadas
em janelas para computadores desktop; interfaces gestuais para grandes monitores;
interfaces verbais para atendimento automtico pelo telefone; interfaces de toque para
dispositivos mveis); ou ainda especficas a um produto individual (e.g., planilha
eletrnica, editor de texto, editor grfico). Por exemplo, fornea feedback uma diretriz
geral, qual podemos relacionar diretrizes especficas a certas categorias (e.g., para uma
interface grfica: certifique-se de que os principais objetos de interesse estejam visveis
na tela e que revelem seus principais atributos; para um sistema Web: certifique-se de
que o usurio sabe onde ele est, de onde veio e para onde pode ir ) e produtos (e.g., o
cone de uma lixeira deve estar visvel e indicar se ela contm ou no algum item). A
Seo 8.2 apresenta algumas diretrizes comumente encontradas na literatura de IHC.
Antes de iniciar os esforos de implementao da interface com usurio, Nielsen
recomenda fazer prottipos dos sistemas finais, que podem ser desenvolvidos
rapidamente e a um custo baixo, para que sejam avaliados junto a usurios e modificados
medida que a equipe de design adquire um melhor entendimento dos problemas,
visando oferecer uma soluo mais adequada. Para que essa atividade possua custo baixo,
apenas parte do sistema prototipada. Podemos desenvolver um prottipo horizontal,
que visa apresentar o sistema em abrangncia mas com pouca profundidade (i.e., a
aparncia da interface e navegao entre telas, mas sem a funcionalidade subjacente,
como algoritmos e acessos a bases de dados), ou um prottipo vertical, no qual pouca
funcionalidade explorada em profundidade para que seja testada em circunstncias
realistas. Nielsen enumera diversas estratgias para produzir prottipos mais
rapidamente:
no se importar muito com a eficincia da implementao (e.g., utilizao de espao em
disco e tempo de processamento), desde que no seja essencial para a avaliao junto ao
usurio;
aceitar cdigo de qualidade mais baixa ou pouco confivel;
utilizar algoritmos simplificados e que no conseguem lidar com todos os casos
especficos;
fazer uma simulao com uma pessoa atuando como o computador por trs da
cortina, numa tcnica denominada Wizard of Oz (mgico de Oz), na qual o usurio, sem
saber, interage com uma pessoa que determina as respostas do prottipo, e no com um
processamento computacional;
utilizar uma plataforma computacional diferente da almejada para facilitar o
desenvolvimento do prottipo (e.g., utilizar uma ferramenta de autoria em vez da
linguagem de programao que ser utilizada para construir o produto final);
utilizar prottipos de baixa fidelidade, mas que representem a essncia da interao;
utilizar dados falsos e contedos fictcios, desde que no atrapalhem a avaliao junto
aos usurios;
utilizar maquetes em papel em vez de um sistema funcional;
utilizar um prottipo verbal, no qual o avaliador descreve oralmente uma interface
possvel e explora uma srie de perguntas to tipo E se?;
utilizar cenrios (veja Seo 4.3.5).
A partir dos prottipos, os designers devem fazer testes empricos, que consistem
principalmente na observao dos usurios ao utilizarem os prottipos para realizar
certas tarefas. A Seo 10.2.1 descreve a avaliao atravs de testes de usabilidade.
Com base nos problemas de usabilidade e nas oportunidades reveladas pelos testes
empricos, os designers produzem uma nova verso da interface, e repassam pelas
atividades do processo, num design iterativo. A cada iterao de design e avaliao,
alguns problemas so corrigidos (e infelizmente outros podem ser introduzidos), e o
processo deve ser repetir at que as metas de usabilidade tenham sido alcanadas. Nesse
processo iterativo, importante tornar as decises de design explcitas e registr-las para
referncia futura, ou seja, capturar o design rationale (Moran e Carroll, 1996).
importante registrar as decises tomadas para que, no futuro, no sejam tomadas
decises que sacrifiquem metas de usabilidade importantes ou que introduzam
inconsistncias por falta de informao sobre o histrico do projeto.
Finalmente, aps a introduo de um produto, devemos coletar dados de uso, no
apenas para avaliar o retorno de investimento, mas tambm para planejar a prxima
verso do produto.

4.3.3 Engenharia De Usabilidade De Mayhew


Deborah Mayhew (1999) props um ciclo de vida para a engenharia de usabilidade. Com
uma viso holstica, esse processo de design rene e organiza diferentes atividades
propostas na rea de IHC para orientar o trabalho do designer em direo a uma boa
soluo interativa. A Figura 4.7 apresenta as trs fases desse processo iterativo: anlise de
requisitos, design/avaliao/desenvolvimento e instalao.
FIGURA 4.7 Ciclo de vida para a engenharia de usabilidade (adaptado de Mayhew, 1999).

Na fase de anlise de requisitos so definidas as metas de usabilidade com base no


perfil dos usurios, anlise de tarefas, possibilidades e limitaes da plataforma em que
o sistema ser executado e princpios gerais de design de IHC. Nesse processo, as metas
de usabilidade costumam ser representadas em guias de estilos para auxiliar sua
verificao durante as demais atividades do processo (veja Seo 8.4).
A fase de design, avaliao e desenvolvimento tem por objetivo conceber uma soluo
de IHC que atenda s metas de usabilidade estabelecidas na fase anterior. Esse processo
prope projetar a soluo de IHC em trs nveis de detalhes. No primeiro nvel, o
designer precisa realizar a reengenharia do trabalho, repensando a execuo das tarefas
para alcanar os objetivos dos usurios, elaborar alternativas de soluo do modelo
conceitual, elaborar prottipos de baixa fidelidade e avaliar tais prottipos. No segundo
nvel, o designer deve estabelecer padres de design de IHC para a soluo sendo
concebida, construir prottipos de mdia fidelidade de acordo com esses padres e
avali-los. No terceiro nvel, o designer realiza o projeto detalhado da interface, com alta
fidelidade, para ser implementado. Durante o desenvolvimento do sistema, a interface
deve ser avaliada com a participao dos usurios.
Na fase de instalao, o designer deve coletar opinies dos usurios depois de algum
tempo de uso. Essas opinies sero teis para melhorar o sistema em verses futuras ou
at mesmo para apontar a necessidade de desenvolver novos sistemas interativos ainda
no previstos.

4.3.4 Design Contextual


O design contextual (contextual design) um processo de design de IHC que orienta o
designer a compreender profundamente as necessidades dos usurios1 atravs de uma
investigao minuciosa do contexto de uso (Beyer e Holtzblatt, 1998; Holtzblatt et al.,
2001). Essa apreciao cuidadosa do que ocorre em contexto fundamental para o
designer elaborar uma soluo de IHC adequada. As atividades do design contextual so:
investigao contextual, modelagem do trabalho, consolidao, reprojeto do trabalho,
projeto do ambiente do usurio, prototipao e teste com usurios.
Na investigao contextual (contextual inquiry), o designer busca conhecer quem so os
usurios, suas necessidades, seus objetivos e a forma como ele trabalha no seu dia a dia.
Essa investigao ocorre diretamente no ambiente de trabalho do usurio para que o
designer possa ter acesso a informaes do contexto. O objetivo da investigao
contextual revelar detalhes e motivaes implcitas no trabalho dos usurios a fim de
informar o designer sobre suas necessidades reais. Essas informaes contextuais so
importantes para apoiar as decises de design. O mtodo de investigao contextual
descrito em detalhes na Seo 5.5.7.
O conhecimento adquirido na investigao contextual permite ao designer modelar o
trabalho de cada usurio investigado separadamente. Existem cinco tipos de modelos de
trabalho utilizados no design contextual: modelo de fluxo, modelo de sequncia, modelo
de artefato, modelo de cultura e modelo fsico. Cada um representa um aspecto do
trabalho sob a perspectiva de um usurio investigado, podendo conter conceitos
complexos e muitos detalhes. Eles so utilizados para registrar e compartilhar com a
equipe de projeto os conhecimentos adquiridos na investigao contextual.
A consolidao dos modelos de trabalho possibilita organizar e atribuir significado ao
trabalho desempenhado por cada papel, perfil ou classe de usurio investigado. Um
diagrama de afinidade deve ser elaborado para estruturar coletivamente a forma como os
usurios trabalham, sem perder as particularidades de cada caso. O diagrama de
afinidade sintetiza grande quantidade de dados qualitativos em um grande mapa. Alm
disso, os modelos de trabalho de todos os usurios investigados devem ser combinados
em cinco modelos de trabalho consolidados, um para cada tipo de modelo. O resultado
dessa consolidao um conjunto de dados corporativos que vai guiar o projeto de IHC e
podem ser reutilizados em projetos futuros. Os diagramas de afinidade so descritos na
Seo 5.5.4, no contexto de sesses de brainstorming.
A consolidao dos modelos de trabalho fornece insumos para o designer reprojetar a
forma como os usurios trabalham. O designer utiliza storyboards para explorar ideias
sobre como melhorar a prtica de trabalho com o suporte oferecido pela tecnologia.
Uma vez concebida uma nova maneira de trabalhar, o designer segue projetando uma
soluo de interao e de interface que apoie essa nova forma de trabalhar. Por fim, o
designer deve construir prottipos do sistema e avali-los junto aos usurios. Isso
permite revisar e refinar o projeto iterativamente at chegar a uma soluo satisfatria.

4.3.5 Design Baseado Em Cenrios


O design baseado em cenrios um processo que utiliza diferentes tipos de cenrios
como representao bsica e fundamental durante todas as atividades envolvidas na
concepo de uma soluo de IHC (Rosson e Carroll, 2002; Carroll, 1995). Um cenrio
simplesmente uma histria sobre pessoas executando uma atividade (Rosson e Carroll,
2002, p. 2). Como os cenrios so geralmente escritos em linguagem natural, o seu uso
motiva todos os interessados no sistema a participarem e contriburem com as decises
de design, direta ou indiretamente.
Ao escrever, ler e revisar cenrios, a equipe de design (incluindo representantes dos
usurios) tem a oportunidade de discutir e analisar como as atividades dos usurios so
afetadas pela tecnologia existente e como elas poderiam ser afetadas pelo sistema sendo
desenvolvido. As histrias dos cenrios estimulam a imaginao da equipe de design e
encorajam a anlise de caminhos alternativos. Por exemplo, perguntas do tipo E se
permitem equipe de design imaginar outros caminhos para a histria descrita no
cenrio, possivelmente contendo alguns elementos diferentes. Desse modo, cenrios so
uma ferramenta til e barata para gerar e avaliar diversas ideias durante as atividades de
design.
A Figura 4.8 ilustra as atividades propostas pelo design baseado em cenrios.
Basicamente, as atividades so: anlise do problema, projeto de uma soluo de IHC,
prototipao e avaliao da soluo proposta. O diferencial desse processo est na forma
como essas atividades so executadas. Esse processo inicia com a elaborao de cenrios
de problema, e continua com sucessivas anlises e transformaes de cenrios de acordo
com a atividade sendo executada. Apesar de as atividades serem apresentadas
sequencialmente, o processo iterativo, ou seja, sempre que necessrio, a equipe de
design pode revisar o que foi feito anteriormente.
FIGURA 4.8 Atividades do design baseado em cenrios.

Na anlise do problema, a equipe de design estuda a situao atual junto aos


interessados no sistema (stakeholders: clientes, usurios etc.). Com o conhecimento
adquirido sobre a situao atual, a equipe de design deve formular cenrios de
problemas que cobrem caractersticas dos usurios, suas atividades tpicas e crticas, os
artefatos que eles utilizam e o contexto de uso (Rosson e Carroll, 2002). Uma vez que a
compreenso da equipe de design sobre a situao atual tenha sido consolidada em
cenrios de problema, o prximo passo elaborar uma soluo de IHC adequada que
resolva os problemas descritos.
Na atividade de projeto, a equipe de design deve explorar ideias para a soluo de IHC
elaborando trs tipos de cenrios: cenrios de atividade, de informao e de interao.
Um cenrio de atividade uma narrativa sobre as tarefas tpicas e crticas que os usurios
vo executar com ajuda do sistema. Eles concentram-se em relatar as funcionalidades do
sistema, sem, no entanto, especificar ainda como os usurios vo utiliz-lo ou como deve
ser a aparncia do sistema. Um cenrio de informao uma elaborao de um cenrio
de atividade que descreve as informaes fornecidas pelo sistema ao usurio durante a
interao. Um cenrio de interao especifica em detalhes as aes do usurio e as
respectivas respostas (feedback) do sistema necessrias para executar as tarefas apoiadas
pelo sistema.
As ideias para a soluo de IHC devem ser avaliadas continuamente durante o
processo de design. Isso normalmente realizado atravs de um prottipo que
implementa ou demonstra partes da soluo de IHC descritas em cenrios. Os cenrios
tambm so responsveis por guiar a avaliao, seja durante a concepo da soluo de
IHC ou depois que ela estiver pronta. Os cenrios descrevem hipteses sobre o uso da
soluo de IHC que permitem prever: os perfis dos usurios, seus objetivos, algumas
tarefas que tentaro realizar para atingirem seus objetivos, algumas sequncias de aes
que tentaro realizar para conclurem as tarefas escolhidas, as respectivas respostas do
sistema e algumas possveis reaes dos usurios. Cenrios so discutidos nas Sees 6.3
e 7.2, no contexto de anlise e design de IHC, respectivamente.
4.3.6 Design Dirigido Por Objetivos
O processo de design dirigido por objetivos orienta o designer a projetar uma soluo de
IHC criativa que apoie os usurios em atingirem seus objetivos (Cooper et al., 2007). O
diferencial desse processo incentivar o designer a explorar as tecnologias disponveis da
melhor forma possvel para oferecer aos usurios maneiras mais criativas, inovadoras e
eficientes de alcanarem seus objetivos. Por exemplo, se a tecnologia permite sacar
dinheiro de contas no banco em um caixa eletrnico que pode funcionar 24 horas durante
toda a semana, por que limitar esse objetivo ao atendimento de um funcionrio que
trabalha seis horas em cinco dias na semana? Se a tecnologia permite enviar fotos em
poucos minutos para familiares em locais bem distantes, como em outros pases, por que
esperar dias para as fotos chegarem ao destinatrio atravs do correio tradicional? claro
que as tecnologias possuem vrias limitaes e no possuem as mesmas capacidades
humanas. Contudo, o importante explorar as possibilidades da tecnologia em favor dos
usurios.
Segundo Cooper e seus colegas, alguns designers podem tentar projetar um sistema
que permita ao usurio realizar as mesmas tarefas ou aes que ele realizava
anteriormente. Dessa forma, a nova soluo ser mediana, pois sempre oferecer o
mesmo tipo de apoio ao usurio, limitado forma como os usurios atingem seus
objetivos atualmente. As novas solues continuaro limitadas ao que as tecnologias
anteriores j permitiam fazer, sem explorar novas possibilidades oferecidas pelas
tecnologias atuais. Essa perspectiva de design abre pouco espao para solues criativas,
capazes de explorar tecnologias antigas e novas de maneira inovadora para apoiar o
usurio. Se por um lado preciso estar ciente do que as pessoas sabem e esto
acostumadas a fazer, por outro a nova soluo no pode estar limitada a isso.
Como ser criativo e inovar sem estar limitado s tarefas executadas anteriormente
pelos usurios? Para responder essa pergunta, primeiro preciso diferenciar objetivos de
tarefas ou aes do usurio. Cooper, Reimann e Cronin (2007, p. 15) definem um objetivo
como sendo uma expectativa de uma condio final, em que aes e tarefas so passos
intermedirios (em diferentes nveis de organizao) que ajudam algum a atingir um
objetivo ou conjunto de objetivos. Segundo essa definio, um objetivo seria o destino
final, alcanado quando um usurio percorre certos caminhos definidos por tarefas e
aes. Por exemplo, um objetivo do usurio pode ser comunicar algo a um colega. Ele
pode fazer isso realizando diferentes tarefas, como, por exemplo, escrevendo uma carta
convencional, enviando um e-mail, fazendo uma ligao telefnica, ou enviando uma
mensagem de texto via telefone celular. Uma tarefa pode ser composta de outras tarefas
mais simples. Por exemplo, a tarefa de escrever um e-mail pode ser composta pelas
tarefas de digitar um texto e format-lo.
Os objetivos representam as motivaes que levam o usurio a realizar suas tarefas.
Conhecer esses objetivos permite compreender o significado das tarefas realizadas
atualmente. Com isso, possvel repensar as tarefas com liberdade para imaginar novas
possibilidades de atingir os objetivos do usurio, aproveitando ao mximo as tecnologias
antigas e novas de forma criativa, inovadora e eficiente. Quando o design de IHC
dirigido pelos objetivos do usurio, possvel explorar a tecnologia para eliminar tarefas
irrelevantes e aperfeioar as demais.
Por exemplo, pense no objetivo de comprar produtos em uma loja. Uma sequncia de
tarefas possvel seria o caixa pegar cada produto, digitar seu valor na caixa registradora
(ou obter a informao atravs da leitura de um cdigo de barras), o cliente pagar e levar
a mercadoria. Outra sequncia possvel de tarefas seria o prprio sistema identificar no
carrinho do cliente o tipo e a quantidade dos produtos escolhidos (por exemplo, atravs
de RFID identificao por rdio frequncia) e o cliente pagar e levar os produtos. Hoje
em dia j comum o prprio cliente informar a um sistema de comrcio eletrnico quais
produtos deseja comprar, como vai pagar, qual meio de transporte deve ser utilizado e
onde os produtos devem ser entregues pela empresa.
Essas so apenas trs formas diferentes de atingir o objetivo de comprar produtos,
cada qual com uma sequncia de tarefas diferente e com vantagens e desvantagens. Ao
enunciar o objetivo do usurio, possvel explorar e comparar diferentes formas de
atingi-lo. Assim, podemos empregar as tecnologias de maneira mais apropriada para
apoiar e satisfazer os objetivos dos usurios.
O design dirigido por objetivos um processo sistemtico proposto para investigar e
atender s necessidades e aos objetivos dos usurios, bem como atender aos requisitos
tcnicos, do negcio e da organizao. Esse processo dividido em seis fases (Figura 4.9):
pesquisar, modelar, definir requisitos, projetar, refinar e manter.

FIGURA 4.9 Processo de design dirigido por objetivos (adaptado de Cooper et al., 2007).

Na fase de pesquisa, o designer est interessado em conhecer o usurio, o domnio do


sistema e o contexto de uso. Ele investiga comportamentos dos usurios que sugerem
seus objetivos e motivaes ao realizar suas atividades enquanto manipulam certos
artefatos. O comportamento dos usurios pode estar associado a um papel ou funo
exercida, ou ainda corresponder a suas preferncias pessoais.
A fase de modelagem tem por objetivo organizar e registrar o conhecimento adquirido
na fase de pesquisa atravs da elaborao de modelos do usurio, domnio e contexto de
uso. Os modelos so teis para representar conceitos e relaes entre eles, facilitando
equipe de design registrar, compreender, visualizar e discutir sobre o conhecimento
adquirido na fase anterior. Sem a organizao proporcionada por modelos, possvel que
dados coletados na fase de pesquisa permaneam inexplorados durante o processo de
design por falta de ateno ou de um trabalho sistemtico.
Na fase de definio de requisitos, o designer interpreta as informaes coletadas e
estruturadas nos modelos para definir os requisitos do usurio, do negcio e tcnicos.
Algumas vezes esses requisitos so conflitantes, e preciso fazer concesses. Por
exemplo, em um sistema de comrcio eletrnico, alguns usurios podem estar
interessados em comprar os produtos mais baratos, enquanto a empresa tambm deseja
vender produtos mais caros. Como equilibrar isso? Uma possvel soluo seria expor
tanto os produtos mais caros quanto os mais baratos em diferentes vitrines do sistema,
e tambm permitir ao usurio consultar os produtos mais baratos de alguma maneira.
Na fase de projeto conceitual (framework definition), o designer concebe uma soluo de
interao e um esboo de interface pouco detalhado. Sua preocupao principal est na
concepo da estrutura e do comportamento da interface. Na fase de refinamento, o foco
detalhar a soluo de interface, definindo todas as caractersticas dos elementos de
interface, tais como tamanho, cores e cones. Nessa fase o designer verifica a coerncia
das tarefas percorrendo a interface. A soluo detalhada pode ser avaliada junto aos
usurios, e, caso seja necessrio, ela revisada. O resultado da fase de refinamento uma
documentao detalhada da soluo de interao e de interface projetada.
Durante a implementao da soluo projetada, podem surgir limitaes tcnicas que
impeam ou atrapalhem sua construo. Por isso, na ltima fase do processo, o designer
tem a responsabilidade de manter a coerncia da soluo proposta enquanto acomoda as
limitaes tcnicas imprevistas. A presena do designer nessa fase ainda de extrema
importncia. Se o designer no estiver mais disponvel durante a construo da soluo, a
equipe de desenvolvimento pode ter de tomar decises de IHC sem o conhecimento
necessrio sobre usurios, objetivos e contexto de uso.
Cada fase do design dirigido por objetivos iterativa. Podemos observar que no existe
atividade exclusiva para avaliao nesse processo. A avaliao deve ser realizada durante
cada atividade, principalmente nas fases de projeto e de refinamento da soluo.

4.3.7 Design Centrado Na Comunicao


O design centrado na comunicao (Barbosa et al., 2004) tem como base terica a
engenharia semitica (de Souza, 2005a), apresentada na Seo 3.8. Essa teoria
compreende a interao humano-computador como um processo de comunicao entre o
usurio e o designer do sistema, atravs da sua interface. Em outras palavras, a interface
revela, durante o uso do sistema, a metacomunicao do designer (ou seja, as intenes
de design e os princpios interativos). Quando o usurio tem acesso a essa
metacomunicao, ele possui melhores condies de aprender e usar o sistema de forma
produtiva, eficiente e criativa. A motivao principal do design centrado na comunicao
elaborar uma soluo de IHC que transmita a metacomunicao do designer de forma
eficiente e eficaz, ou seja, produzir um sistema interativo com alta comunicabilidade
(conceito apresentado na Seo 2.2.3). Para isso, esse processo orienta o designer a se
posicionar como um dos interlocutores das conversas que ocorrem durante a interao.
Para aumentar as chances de projetarmos uma interface que transmita adequadamente
a metacomunicao do designer, a equipe de projeto deve definir o contedo dessa
mensagem e compartilh-la efetivamente entre seus membros. Em outras palavras, se a
equipe de design no possui uma viso de design compartilhada consistente, ela
dificilmente ter sucesso em comunic-la aos usurios atravs da interface. O design
centrado na comunicao parte do pressuposto que, se os designers conseguirem
registrar a metacomunicao em um conjunto de artefatos e comunic-la aos membros
da equipe, eles tero melhores condies de comunic-la aos usurios atravs da
interface (Barbosa et al., 2004).
Desse modo, o design centrado na comunicao busca representar a metacomunicao
e promover uma compreenso compartilhada dela por todos os membros da equipe de
projeto. Essa compreenso deve ser registrada desde o incio do processo de design,
ainda na fase de anlise do problema, e chegar at as atividades de implementao e
testes do sistema. Isso ajuda a evitar e corrigir interpretaes incompletas ou
equivocadas, pois o compartilhamento da metacomunicao representa uma
oportunidade para todos os membros da equipe contriburem e revisarem o que foi
produzido at o momento. Cada membro contribui com a sua perspectiva particular
sobre o assunto em questo.
Mas onde os designers buscam insumos para construir a metacomunicao? Alm do
levantamento e da anlise tradicionais dos objetivos, necessidades e preferncias dos
usurios, o design centrado na comunicao faz uso dos resultados de pesquisa sobre a
construo da ajuda on-line de Silveira e colegas (Silveira et al., 2004; Silveira, 2002).
A ajuda on-line uma forma privilegiada de transmitir a metacomunicao ao usurio,
pois fornece meios de transmitir direta e explicitamente as intenes de design e os
princpios de interao. Silveira explora dvidas comuns dos usurios para construir um
sistema de ajuda on-line (veja Seo 7.5). Ela prope coletar informaes durante todo o
processo de desenvolvimento para responder as perguntas que os usurios costumam
fazer quando encontram problemas durante o uso. Por exemplo, a ajuda on-line deve
buscar responder perguntas como O que isto?, Para que serve isto? e Como fao
isto? quando se referem a conceitos representados na interface. Essas perguntas so
utilizadas para auxiliar na elaborao do contedo da metacomunicao e na sua
comunicao aos usurios atravs da engenharia dos sistemas de signos da interface e da
ajuda on-line.
O design centrado na comunicao leva adiante a proposta de Silveira para apoiar
todas as atividades envolvidas no projeto de uma soluo de IHC com alta
comunicabilidade, e no apenas a construo da ajuda on-line. Desse modo, o design
centrado na comunicao prope a elaborao da metacomunicao orientada por um
conjunto de perguntas derivadas das dvidas comuns dos usurios. Essas perguntas
sero respondidas durante a atividade de anlise da situao atual e o projeto da soluo
de IHC. Por exemplo, durante a atividade de anlise, o designer deve procurar responder
perguntas do tipo: O que o usurio deseja ou desejaria fazer com o sistema?, Quem
pode fazer isso? e O que deve ser feito antes disso?. J durante o projeto da soluo, o
designer deve buscar responder perguntas do tipo: Como o usurio costuma atingir
esse objetivo atualmente?, Como ele gostaria de fazer isso no futuro?, Que
problemas podem ocorrer enquanto o usurio busca atingir esse objetivo?, Como
solucionar tais problemas? e Como desfazer os resultados de uma ao indesejada?.
Em particular, a preocupao com as possveis dvidas dos usurios motiva a equipe de
design a tentar prever possveis problemas durante o uso, a projetar formas de preveno
e recuperao desses problemas, bem como a comunicar sob demanda suas intenes de
design e princpios interativos atravs da interface.
O design centrado na comunicao prope trs atividades: a anlise do usurio,
domnio e contexto de uso, o projeto de interao e interface, e a avaliao do que foi
projetado (Figura 4.10). O diferencial desse processo consiste em nortear os esforos de
design desde o incio do processo pelas dvidas que os usurios costumam ter durante a
interao. Dessa forma, a soluo de IHC projetada para evitar o surgimento das
dvidas dos usurios e comunicar adequadamente informaes necessrias para sanar
dvidas que eventualmente surjam.

FIGURA 4.10 Design centrado na comunicao.

Embora um objetivo importante seja evitar que os usurios tenham dvidas durante a
interao, o design centrado na comunicao reconhece que inevitvel que diferentes
usurios tenham dvidas em alguns momentos, assim como inevitvel que mal-
entendidos ocorram durante a conversao humana. Portanto, ele orienta o designer a
projetar uma soluo de IHC que comunique adequadamente no apenas as situaes
esperadas (que do certo), mas tambm que ajude o usurio a evitar e se recuperar das
rupturas de comunicao durante a interao (veja Seo 7.3.3).
O design centrado na comunicao diferencia a interface e a interao a ponto de
propor o projeto de cada uma separadamente, mantendo a consistncia e coerncia entre
elas. Recomenda que o projeto da interao seja realizado utilizando a MoLIC,
Linguagem para a Modelagem da Interao como Conversa (Barbosa e Paula, 2003; Silva e
Barbosa, 2007). Para o projeto de interfaces grficas, esse processo recomenda o uso de
esboos de tela, mas no faz recomendaes especficas para outros tipos de interface
(via voz, gestos, realidade virtual etc.). O Captulo 7 descreve as atividades de projeto de
interao e interface desse processo de design, bem como os modelos e representaes
utilizados.
Os objetivos do usurio sero atingidos atravs de conversas entre usurio e o
preposto do designer durante a sua interao com o sistema. Segundo essa interpretao,
a interface representa uma linguagem e um meio de comunicao entre usurio e o
preposto do designer, linguagem essa que define a forma e o contedo do que os
interlocutores podem falar, em que ordem as falas podem ocorrer e quem pode falar em
cada momento da conversa. Sendo assim, o designer deve projetar a conversa (a
interao) e a forma de represent-la na interface. Em linha com Hoover, Rinderle e
Fischer (1991), o design centrado na comunicao envolve modelos com diferentes focos
e nveis de abstrao e detalhes. Ele recomenda primeiro projetarmos a conversa
usuriodesigner em um modelo de interao, concentrando-nos nas trocas de turno de
fala e nos tpicos e foco de cada turno de fala, e abstraindo-nos dos detalhes da interface.
Em seguida, devemos projetar estrutura, layout e formatao da interface propriamente
dita (isto , projetar a expresso da conversa usurio-designer na interface).
Como sempre, a proposta de soluo de IHC (interao e interface) deve ser avaliada
para verificarmos se ela atende s necessidades dos usurios. No design centrado na
comunicao, avaliamos se a metacomunicao foi enviada e recebida adequadamente. Se
algum problema for encontrado, devemos rever o projeto de interao, o de interface, ou
ambos. Durante as atividades de projeto e de avaliao, tambm pode ser necessrio
ampliar, refinar ou revisar a anlise realizada anteriormente. Por isso, o design centrado
na comunicao bastante iterativo, com ciclos envolvendo as trs atividades bsicas de
design: anlise, sntese e avaliao, at que uma soluo seja avaliada como satisfatria. O
Captulo 10 apresenta os mtodos de inspeo semitica e de avaliao de
comunicabilidade, utilizados no design centrado na comunicao.
Os objetivos, as necessidades, as preferncias e os pontos de vista dos usurios
ganham importncia em todas as atividades deste processo de design, pois desde o incio
a ateno da equipe est centrada na comunicao com os usurios. A definio
compartilhada da metacomunicao que guia o projeto de IHC facilita construir um
sistema interativo consistente, coerente e com alta comunicabilidade.
Vale observar que, embora os usurios e demais stakeholders participem intensamente
das atividades de anlise e avaliao ao longo de todo o projeto, cabe aos designers
elaborarem a metacomunicao e a soluo de IHC com base no que observaram e
ouviram durante essas atividades. Embora a participao dos usurios seja
imprescindvel para a qualidade e o sucesso da soluo, eles no so diretamente
codesigners da soluo projetada. Em outras palavras, no design centrado na
comunicao, a soluo de IHC projetada envolvendo os usurios e para eles, mas no
por eles.
4.4 Integrao das Atividades de IHC com
Engenharia de Software
As reas de IHC e de Engenharia de Software (ES) possuem diferentes perspectivas sobre
o que importante em um sistema interativo, sobre o que significa utiliz-lo e sobre
como desenvolv-lo. Cada rea vem evoluindo historicamente por um caminho prprio e
independente. Embora a preocupao com a qualidade de uso aparea desde os
primeiros trabalhos sobre qualidade de software no final de dcada de 1970 (McCall et al.,
1977; Cavano e McCall, 1978; Boehm, 1981), a ES tem direcionado seus esforos para
fatores de qualidade mais relacionados com engenharia construo, instalao e
manuteno deixando para segundo plano a forma como os sistemas interativos sero
utilizados.
Na perspectiva de design centrada no sistema, comum na rea de Engenharia de
Software, um sistema interativo um artefato circunscrito e encapsulado por uma
interface que recebe dados de entrada, processa esses dados com algum programa
(codificado em software ou hardware) e retorna dados de sada (Figura 4.11). O que mais
importa nessa perspectiva aquilo que ocorre dentro do sistema. Tudo o que ocorre na
fronteira ou fora dele, inclusive a prpria interface, acaba recebendo pouca ou nenhuma
ateno. O objetivo principal seria construir um sistema fidedigno (dependable) que seja
capaz de processar adequadamente os dados de entrada e sada transmitidos atravs de
uma interface bem definida. Os fatores de qualidade mais valorizados por essa
perspectiva esto relacionados com a construo de um sistema interativo, como, por
exemplo, disponibilidade, integridade, robustez, manutenibilidade e recuperabilidade
(Avizienis et al., 2004). Para atender a esses fatores de qualidade preciso concentrar em
conceitos fundamentais para construo de sistemas, tais como: arquitetura do sistema,
estrutura de dados, mecanismos de persistncia de dados, formas de comunicao entre
sistemas, algoritmos, sistema operacional, linguagem de programao, ambiente de
desenvolvimento, e assim por diante.

FIGURA 4.11 Perspectiva de design centrado no sistema.

A definio de uma interface permite ao engenheiro de software especificar a forma


como um sistema ir interagir com o mundo externo. Tudo o que possvel solicitar ao
sistema e receber dele ser definido pela interface. Dessa maneira, o engenheiro de
software geralmente abstrai o mundo externo ao construir o sistema, pois ele espera que
o mundo se comunique corretamente com o sistema, conforme estabelecido pela
interface. Abstrair o mundo externo pode funcionar bem quando estamos lidando com a
comunicao entre sistemas, porque eles podem ser construdos para se comunicarem
obedecendo a interfaces bem definidas. Contudo, a abstrao do mundo externo costuma
trazer problemas quando igualamos a interface com pessoas interface com outros
sistemas computacionais. A comunicao entre sistemas computacionais possui
caractersticas bem diferentes da comunicao usuriosistema. Quando o usurio entra
em cena, as caractersticas humanas devem ser consideradas e endereadas
adequadamente durante a interao. Alm disso, o contexto e o ambiente em que o
usurio e o sistema esto inseridos tambm influenciam o uso do sistema e devem ser
considerados.
Compreender e enderear os problemas que ocorrem durante a interao usurio
sistema exigem conhecimentos alm daqueles de base Matemtica e Lgica que
fundamentam a Engenharia de Software e a Computao como um todo. Exigem
conhecimentos relacionados com caractersticas particulares das pessoas e das culturas
em que esto inseridas. Um sistema interativo construdo para sempre executar um
conjunto bem definido de instrues, que processam dados de entrada e sada. Diferente
das mquinas, uma pessoa sente, pensa, interpreta, reinterpreta, criativa, compartilha
de uma cultura, vive em sociedade, muda de opinio, gostos, costumes, enfim, uma
pessoa est sempre evoluindo. No possvel prever ou controlar com exatido a
interpretao e o comportamento de algum durante o uso de um sistema. De fato, tratar
adequadamente o uso de sistemas interativos exige conhecimentos e esforos
multidisciplinares muito alm da Computao, incluindo reas como Lingustica,
Psicologia, Sociologia, Ergonomia, Artes, dentre outras (Sharp et al., 2007; Seo 1.4).
Como os conhecimentos matemticos e lgicos que fundamentam a ES no do conta
das questes relacionadas ao uso que uma pessoa faz de sistemas interativos, a rea de
IHC vem se estabelecendo como rea multidisciplinar que prope uma perspectiva
diferente para o desenvolvimento de sistemas interativos. Na perspectiva do design
centrado no uso, comum a profissionais de IHC, conforme discutido no Captulo 1, um
sistema interativo um artefato com o qual o usurio interage durante a realizao de
suas atividades em determinado contexto. O foco dessa perspectiva deixou de ser o que
ocorre dentro do sistema e passou para aquilo que ocorre fora do sistema e atravs da sua
interface. O mais importante nessa perspectiva a forma como o usurio se apropria
daquilo que o sistema pode oferecer em apoio aos seus objetivos em um determinado
contexto. Assim, o objetivo do design centrado no uso conceber (mais no sentido de
projetar e avaliar do que implementar) um sistema interativo que sirva de apoio ao
usurio na realizao de suas atividades e no alcance dos seus objetivos. Para isso,
preciso trabalhar com conceitos relacionados ao uso do sistema, como, por exemplo, o
contexto de uso, os objetivos do usurio, as formas como ele costuma alcan-los, as
caractersticas do usurio (formao, habilidades, prtica na atividade sendo apoiada
pelo sistema, cultura, gostos, preferncias etc.) e possveis formas de interao atravs da
sua interface com usurio.
Desde sua origem, IHC tem sido proposta em contraste com o desenvolvimento
centrado no sistema tipicamente praticado pela ES (Norman e Draper, 1986;
Shneiderman, 1998; Sharp et al., 2007). Para IHC, o uso que as pessoas vo fazer do
sistema o que deve guiar seu desenvolvimento. O usurio no deveria ser obrigado a
adequar ao sistema sua forma de pensar, de realizar suas atividades, de trabalhar, de
interagir com outras pessoas ou com instituies, e assim por diante. Na verdade, o
sistema que deveria ser construdo de forma adequada ao usurio e suas necessidades e
desejos.
As diferentes perspectivas de IHC e ES sobre o desenvolvimento de sistemas
interativos deram origem a mtodos, tcnicas e processos prprios de cada rea.
Recentemente, alguns pesquisadores tm investigado a integrao de mtodos e tcnicas
de IHC em processos de desenvolvimento de software propostos em ES (Seffah et al.,
2005). As principais abordagens de integrao de processos de IHC e ES so:
definio de caractersticas de um processo de desenvolvimento que se preocupa com a
qualidade de uso;
definio de processos de IHC paralelos que devem ser incorporados aos processos
propostos pela ES;
indicao de pontos em processos propostos pela ES em que atividades e mtodos de
IHC podem ser inseridos.
Uma maneira de integrar as reas de IHC e de ES definir as caractersticas que um
processo de desenvolvimento deve ter para tratar adequadamente a qualidade de uso.
Gulliksen e seus colegas (2005) identificaram 12 princpios-chave que um processo de
desenvolvimento deve ter para cuidar adequadamente da qualidade de uso. So eles:
foco no usurio: os objetivos e as necessidades do usurio devem guiar o processo de
desenvolvimento desde o incio, para evitar que o desenvolvimento seja guiado pela
tecnologia;
participao ativa do usurio: representantes dos usurios devem participar ativamente
durante todo o processo de desenvolvimento;
desenvolvimento iterativo e incremental: o desenvolvimento do sistema deve ser iterativo e
incremental para permitir a avaliao e reviso das propostas de soluo, bem como
liberar logo para o usurio partes do sistema que j tenham sido desenvolvidas;
representaes de design simples: o resultado do design deve ser representado de forma
que possa ser facilmente compreendido pelos usurios e demais envolvidos no processo
de desenvolvimento;
prototipao: prottipos em diferentes nveis de detalhes devem ser utilizados para
visualizar e avaliar propostas de soluo junto aos usurios;
avaliar o uso em contexto: avaliar as propostas de soluo considerando os critrios de
qualidade de uso definidos como prioridade para o sistema em questo, sempre atento
s reaes dos usurios no contexto de uso;
atividade de design explcita e consciente: o processo de desenvolvimento deve conter
atividades dedicadas ao design da soluo de interao e de interface com usurio;
atitude profissional: o processo de desenvolvimento deve ser executado por uma equipe
multidisciplinar;
defensor da qualidade de uso: um profissional de IHC deve participar continuamente do
processo de desenvolvimento com a responsabilidade de tomar as decises necessrias
para favorecer a qualidade de uso;
design holstico: todos os aspectos que influenciam o uso devem ser considerados em
conjunto durante o processo de desenvolvimento;
customizao do processo: o processo de desenvolvimento deve ser adaptado a cada
organizao;
atitude centrada no usurio: todos os envolvidos no processo de desenvolvimento devem
estar cientes de e concordar com a importncia da qualidade de uso e da participao
ativa do usurio durante o processo.
Esses princpios-chave so comuns em processos de design de IHC, porm no
costumam ser considerados em processos de desenvolvimento propostos na ES.
Certamente um profissional de IHC est mais bem preparado para colocar em prtica
esses princpios dentro de processos de desenvolvimento, pois so necessrios muitos
conhecimentos de IHC que engenheiros de software geralmente no possuem na
profundidade necessria. Alm disso, importante manter a perspectiva do usurio e do
sistema durante o desenvolvimento para que as qualidades de uso e de construo
recebam a ateno e o cuidado desejados.
Outra forma de integrar IHC e ES atravs da execuo de processos de IHC paralelos
a processos de ES (Seffah et al., 2005). O ciclo de vida em estrela, o design dirigido por
objetivos e o design centrado na comunicao, por exemplo, poderiam ser executados em
paralelo a processos propostos pela ES. Nesse caso, necessrio manter a consistncia
entre os resultados das atividades de cada processo. Se considerssemos a interface com
usurio como algo completamente separado e isolado do restante do sistema, essa
integrao seria fcil de ser resolvida. Entretanto, as decises de design de interao e de
interface tambm afetam as funcionalidades do sistema e o que est por trs da interface
com usurio. Por exemplo, John e seus colegas (2004) mostram como questes de IHC
esto relacionadas com a arquitetura do software e no somente a uma camada ou
casca independente.
O terceiro tipo de abordagem para a integrao de IHC e ES aponta as atividades nos
processos da ES em que mtodos e prticas de IHC podem ser aplicados. Ferre e seus
colegas (Ferre, 2003; Ferre, et al., 2004; 2005) realizaram uma reviso bibliogrfica sobre
os mtodos e as prticas de IHC e definiram onde podem ser utilizados em um processo
genrico de desenvolvimento de software. A Figura 4.12 apresenta o mapeamento das
atividades de IHC em atividades de um processo genrico de desenvolvimento de
software da ES que eles propuseram. Identificar onde os conhecimentos de IHC podem
ser empregados num processo de desenvolvimento representa um passo importante para
a ampla utilizao desses conhecimentos na prtica.
FIGURA 4.12 Mapeamento entre atividades de IHC e de ES adaptado de Ferre, 2003).

Na elicitao de requisitos em um processo de ES, devem ser coletadas informaes


sobre os usurios, seus objetivos, como costumam atingi-los (suas tarefas) e sobre o
contexto de uso. A inteno dessa atividade coletar dados sobre os elementos
envolvidos durante o uso, que vo alm da interface com usurio.
A interpretao desses dados realizada durante a anlise de requisitos em um
processo de ES. Durante essa atividade, o engenheiro de requisitos costuma representar
informaes e tomar decises que influenciam ou dizem respeito interao e interface
com usurio. Por exemplo, quando ele define em um cenrio ou em um caso de uso a
sequncia de aes que deve ser executada no sistema para o usurio atingir um objetivo,
ele toma decises relacionadas com a interao e com a interface com usurio. De forma
mais explcita, ele pode utilizar prottipos (que incluem a interface) para representar
suas ideias sobre o que o sistema deve fazer e como ele vai apoiar o usurio durante a
anlise de requisitos. Essas decises sobre a interao e a interface com usurio deveriam
ser resultado de um projeto cuidadoso sob a responsabilidade de um profissional com
conhecimentos de IHC, e no um subproduto das representaes utilizadas durante a
anlise de requisitos. Os requisitos de IHC e as metas de design devem ser definidos com
os requisitos do sistema durante a atividade de especificao de requisitos em um
processo de ES. Desse modo, idealmente o design de IHC deveria ser iniciado durante a
especificao de requisitos, mas sob a responsabilidade de um profissional de IHC. E
mesmo aps a definio da interao e da interface, e durante o projeto e a
implementao do sistema, pode ser necessrio tambm rever o projeto de IHC quando
surgir alguma dificuldade para construir a soluo projetada ou quando algo no tiver
sido completamente especificado.
A avaliao do sistema deve ir alm da validao de requisitos do sistema e testes do
sistema, e englobar tambm uma avaliao de IHC da soluo proposta, considerando os
critrios de qualidade de uso definidos ao longo do processo de design e
desenvolvimento. Sempre que possvel, representantes dos usurios devem participar da
avaliao de IHC do sistema para que a equipe de desenvolvimento possa perceber os
problemas que ocorrem durante o uso e coletar a opinio dos usurios sobre o sistema.
Como em qualquer equipe multidisciplinar, quando engenheiros de software e
profissionais de IHC trabalham em conjunto, podem surgir problemas de comunicao,
colaborao e coordenao. Parte do trabalho desses profissionais solucionar o mesmo
problema: definir a interao e a interface com usurio do sistema interativo sendo
desenvolvido. Entretanto, eles possuem formaes distintas, diferentes vocabulrios,
objetivos, perspectivas e focos na resoluo desse mesmo problema. Portanto,
importante que os engenheiros de software e os profissionais de IHC reconheam e
valorizem o conhecimento, as preocupaes e o trabalho uns dos outros. As atividades
desses profissionais inevitavelmente influenciam umas as outras e, desse modo, devem
estar bem coordenadas para produzirem um resultado consistente e coerente. A deciso
de como ser a interao e a interface deve ser tomada em conjunto pelos diferentes
profissionais que compem a equipe de design, sempre ponderando os diferentes pontos
de vista e as questes levantadas por todos os membros da equipe de design.
O desenvolvimento de um sistema interativo exige muitos conhecimentos para cuidar
adequadamente da sua construo e do seu uso, e envolve vrias atividades realizadas
em perspectivas diferentes do mesmo problema. Sendo assim, dificilmente um
profissional ser capaz de cuidar sozinho desses dois interesses, seja porque ele no
possui os recursos necessrios para adquirir conhecimento das duas reas na
profundidade e amplitude exigidas, seja porque ele no consegue articular ao mesmo
tempo dois interesses to distintos.
4.5 Mtodos geis e IHC
Os mtodos geis de desenvolvimento de software, como o eXtreme Programming (Beck,
2000) e Scrum (Schwaber e Beedle, 2002), podem ser interessantes para IHC porque
buscam colaborar com o cliente (customer) atravs de pequenos ciclos de
desenvolvimento de forma iterativa e incremental, para obter retorno (feedback) do cliente
e corrigir o rumo do processo de desenvolvimento (Armitage, 2004; Blomkvist, 2005).
Contudo, ainda carecem de cuidado adequado em relao qualidade de uso. Segundo
Armitage (2004, p. 18), a comunidade de mtodos geis raramente menciona os usurios
ou a interface com usurio como um todo, o que significa que ou eles negligenciam a
experincia de uso, ou esto focando projetos com menor necessidade de uma
experincia de uso sofisticada.
Quando se trata de mtodos geis, nem sempre existe uma distino entre clientes e
usurios do sistema sendo desenvolvido. Em IHC, fundamental fazer essa distino. Os
clientes (que no os usurios) possuem apenas uma viso limitada e frequentemente
equivocada das atividades dos usurios propriamente ditos.
Quando clientes ou usurios so envolvidos nos processos de desenvolvimento geis,
existe um grande risco de eles serem os responsveis por especificar os requisitos do
sistema e por projetar a interao e a interface (Jokela e Abrahamsson, 2004). Apesar de
conhecerem bem o domnio, eles podem no ter os conhecimentos necessrios sobre a
tecnologia e sobre design para realizarem essas atividades. Alm disso, podem ter uma
viso restrita do domnio, limitada pela sua atuao em apenas parte do processo que
precisa ser apoiado pelo sistema.
O desenvolvimento incremental proposto pelos mtodos geis exige modificaes na
interface a cada incremento construdo. Isso dificulta a manuteno da consistncia e
coerncia da interao e da interface, afetando direta e significativamente a qualidade de
uso. Quando se trata de qualidades relacionadas com a construo do sistema, os testes
automticos do sistema so uma ferramenta adequada e eficiente para manter a
qualidade do cdigo quando um novo incremento for desenvolvido. Entretanto, esses
tipos de testes no so adequados para avaliar a qualidade de uso (Blomkvist, 2005).
Mesmo em um processo de desenvolvimento gil, ainda se faz necessrio avaliar a
interao e a interface de acordo com os critrios de qualidade de uso, com a participao
de usurios reais.
Blomkvist (2005) faz algumas sugestes concretas para integrar mtodos e prticas de
IHC em processos de desenvolvimento gil:
o objetivo principal entregar ao cliente software que funcione e que seja usvel.
Atividades de IHC so importantes, mas no podem consumir muito tempo. Devemos
equilibrar o tempo necessrio para entregar um sistema que funcione com a qualidade
de uso oferecida;
comum existir a necessidade de priorizar as funcionalidades que o sistema deve possuir
para permanecer dentro do prazo disponvel. Os usurios indicam de quais
funcionalidades precisam, mas o designer de IHC deve auxili-los nessa deciso, para
melhor atender aos seus objetivos e promover uma alta qualidade de uso;
envolver ativamente os usurios e no somente os clientes em todas as fases do
desenvolvimento. O designer deve buscar informaes sobre o contexto de uso, e no
apenas consultar os usurios e clientes no ambiente de desenvolvimento;
o designer de IHC deve ser responsvel pelas decises relacionadas com a qualidade de uso;
necessrio realizar avaliaes de IHC durante diferentes estgios do ciclo de
desenvolvimento. Essas avaliaes no podem ser executadas com a mesma frequncia
que testes automticos de funcionalidades. Entretanto, sempre que possvel, devemos
executar avaliaes de IHC mais simples e rpidas, idealmente com a participao dos
usurios;
devemos realizar uma anlise da situao atual mais abrangente e rica em contexto de uso
do que as histrias de uso (user stories) e os casos de uso (use cases) amplamente
utilizados em mtodos geis.
Vimos neste captulo que o design de IHC um processo iterativo que revisa e refina
interpretaes sobre uma situao para realizar uma interveno na forma de um sistema
computacional interativo. De modo geral, as atividades de um processo de design de IHC
envolvem a anlise da situao atual, a identificao do que deve ou pode ser melhorado,
a elaborao e a avaliao de uma interveno nessa situao. Os processos de design de
IHC organizam essas atividades de diferentes maneiras, sugerem ou prescrevem os
artefatos consumidos e produzidos em cada uma delas, e orientam como cada atividade
deve ser executada.
O restante deste livro apresenta algumas tcnicas e representaes utilizadas ao longo
do processo de design. O Captulo 5 descreve tcnicas de anlise, o Captulo 6 descreve
representaes que organizam o espao de problema, o Captulo 7 descreve a atividade
de design de IHC, o Captulo 8 apresenta diretrizes e padres de IHC, e os Captulos 9 e
10 descrevem a atividade e os mtodos de avaliao de IHC.
Atividades
1. O que design. Escolha uma situao cotidiana em que preciso realizar uma
atividade de design explorando a criatividade. Por exemplo, comprar uma roupa ou
calado, preparar uma refeio ou planejar as frias. Analise a situao escolhida,
identificando o que geralmente feito na:
anlise da situao atual;
definio das necessidades e oportunidades de interveno (i.e., do que possvel
melhorar na situao analisada);
proposta de uma interveno;
avaliao da interveno.

Faa em seguida a mesma anlise, visando construir um sistema que permite aos
usurios atingir os mesmos objetivos.
2. Processo de design de IHC. Investigue um processo de design de IHC de um sistema
interativo. Escolha um sistema a cuja documentao ou equipe de design voc tenha
acesso direto, ou ainda um sistema de software livre que disponibilize na Internet o
material gerado durante seu processo de design de IHC. Por exemplo, investigue o
processo de design do OpenOffice, do Mozilla Thunderbird, do KDE ou do GNOME.
Identifique, descreva e ilustre:
as atividades executadas;
os artefatos consumidos e produzidos em cada atividade;
algumas decises de design tomadas em cada atividade.
3. Processos de design de IHC. Discuta as principais diferenas entre os processos de
design de IHC descritos neste captulo. Identifique caractersticas dos projetos que
ajudam a tomar decises sobre quais processos podem ou devem ser adotados.
4. Conhecimento de IHC envolvido nos processos de design. Identifique quais conhecimentos
de IHC precisam ser adquiridos por equipes de desenvolvimento para desempenhar
atividades de IHC voltadas qualidade de uso do sistema sendo projetado.
5. Integrao das atividades de IHC com engenharia de software. Investigue alguma
experincia de integrar atividades de IHC com atividades de ES, seja em um processo
gil ou no. Voc pode conversar com colegas que tenham participado de iniciativas
desse tipo ou ler relatos de iniciativas do gnero. Analise e discuta os pontos positivos
e negativos da experincia de integrao investigada.
6. Insero de atividades de IHC em processos de desenvolvimento de software. Considerando
um processo de desenvolvimento de software de que voc tenha participado,
identifique os pontos desse processo em que uma ou mais atividades de IHC voltadas
qualidade de uso poderiam ser realizadas.
1
Beyer e Holtzblatt empregam o termo customers (clientes) para referenciar aqueles que usam o sistema. Neste livro,
utilizamos o termo usurio para nos referirmos s pessoas que realizam as atividades que j so ou sero apoiadas pelos
sistemas computacionais interativos investigados ou sendo concebidos. Denominamos stakeholders as demais partes
interessadas no sistema.
5

Identificao de Necessidades dos Usurios e


Requisitos de IHC
Objetivos do Captulo
Caracterizar o espao de anlise no processo de design de IHC.
Descrever o planejamento da coleta de dados de anlise em IHC.
Discutir os aspectos ticos de pesquisas envolvendo pessoas.
Apresentar tcnicas de investigao e anlise comumente utilizadas: entrevistas,
questionrios, grupos de foco, brainstorming, classificao de cartes, estudos de
campo e investigao contextual.
Este captulo descreve os tipos de dados coletados durante a anlise da situao atual, as
fontes de informao que fornecem esses dados e os cuidados ticos envolvidos na
captura dos dados e em pesquisas que envolvem pessoas. Apresenta ainda algumas
tcnicas de investigao e anlise visando entender as necessidades dos usurios e
definir os requisitos de IHC de um sistema interativo (Hackos e Redish, 1998; Courage e
Baxter, 2005; Beyer e Holtzblatt, 1998).
5.1 Introduo
Conforme visto no Captulo 4, a atividade de anlise envolve uma pesquisa inicial da
situao atual para identificar necessidades dos usurios e oportunidades de melhoria, a
fim de determinar as caractersticas do produto de design como proposta de interveno.
Nessa atividade, devemos coletar requisitos de uma variedade de fontes (e.g., usurios
finais, gerentes da empresa, clientes, instrutores, tcnicos de suporte ou atendimento ao
usurio) e utilizar essa informao para determinar que funcionalidades devem ser
includas no produto, que tecnologias devem ser utilizadas, que fatores devem ser
privilegiados, que tarefas devem ser apoiadas e por qu.
O principal objetivo da atividade de anlise identificar os requisitos dos usurios e as
metas de design de IHC. Os requisitos do usurio se referem tanto aos objetivos dos
usurios que o produto deve apoiar, como caractersticas e atributos que um produto
deve ter ou de que maneira deve se comportar, do ponto de vista do usurio (Courage e
Baxter, 2005). Tais requisitos incluem desde as funcionalidades de que os usurios
precisam at critrios de qualidade de IHC que devem ser satisfeitos para que o produto
de design seja considerado bem-sucedido.
O principal erro cometido por uma equipe de design prescindir do estudo ou
pesquisa inicial para a coleta de dados e prosseguir diretamente para realizar a anlise
com dados incompletos, invlidos, corrompidos ou pouco confiveis (Courage e Baxter,
2005). No podemos simplesmente pressupor que os usurios interagem com um
produto de uma certa maneira, e no devemos confiar em dados que no tenham sido
obtidos por pesquisas cuidadosamente conduzidas e documentadas. Mesmo que algum
tenha conversado com os usurios, essa pessoa pode no ter conhecimento e experincia
suficiente sobre levantamento de dados para fazer um relato confivel e sem muitos
erros de interpretao.
Um outro problema se refere ao termo requisitos. Muitas vezes utilizado sem fazer
uma distino entre diferentes tipos de informao, tais como funcionalidades, atributos,
restries e expectativas. E nem sempre discrimina o grau de importncia de cada
informao. Por exemplo, importante fazer uma dinstino entre informaes
obrigatrias oriundas de regras de negcio, definies de processos e normas ou
restries tecnolgicas, e informaes desejveis e, portanto, passveis de negociao,
adaptaes ou at mesmo descarte.
Sharp e coautoras destacam quatro pontos principais envolvidos na coleta de dados
(Sharp et al., 2007): definio dos objetivos da coleta de dados, relacionamento com
participantes, triangulao e estudos-piloto.
A definio dos objetivos envolve identificar as razes para coletarmos dados.
Podemos querer identificar como a tecnologia se encaixa no quotidiano de um grupo de
pessoas; quais dificuldades elas encontram no seu dia a dia que podem ser reduzidas
com a introduo de novas tecnologias; qual dentre duas ou mais alternativas de design
melhor satisfaz os desejos de uma classe de usurios, entre outras questes. Os objetivos
da coleta de dados determinam quais dados devem ser coletados e quais tcnicas de
coleta de dados podem ser utilizadas. Portanto, o primeiro passo para a coleta de dados
definir clara e concisamente os seus objetivos.
Tendo definido os objetivos da coleta de dados, os participantes que fornecero os
dados devem ser informados sobre esses objetivos e consentir com a sua coleta, com as
condies de privacidade e anonimato previstas, com a forma como os dados sero
utilizados, por quem e para qu. Esse esclarecimento ajuda a formar um relacionamento
profissional entre as partes, bem como assegurar aos participantes o uso adequado das
informaes que eles forneam. Em geral, a autorizao dos participantes obtida
atravs da assinatura de um formulrio de consentimento. Vale observar que, quando j
existe um contrato envolvendo os participantes e as pessoas que coletam os dados (por
exemplo, quando os participantes so empregados de uma empresa que contrata
consultores para fazer o levantamento de requisitos), o formulrio de consentimento
pode no ser necessrio. A Seo 5.4 discute os aspectos ticos da pesquisa com seres
humanos e apresenta um exemplo de termo de consentimento.
A triangulao uma estratgia de utilizar mais do que uma tcnica de coleta ou
anlise de dados para obter diferentes perspectivas e confirmar as descobertas,
permitindo obter resultados mais rigorosos e vlidos. Por exemplo, uma estratgia de
triangulao envolve utilizar observao para entender o contexto de realizao das
tarefas, realizar entrevistas para enderear grupos de usurios especficos e distribuir
questionrios para alcanar uma populao mais ampla, alm de realizar grupos de foco
para obter uma viso de consenso.
Um estudo-piloto uma pequena prvia do estudo principal, com o objetivo de
assegurar que o estudo vivel e permitir coletar os dados desejados e realizar as
anlises planejadas. O estudo-piloto permite avaliar o material elaborado, como, por
exemplo, avaliar se as perguntas de uma entrevista ou de um questionrio esto
confusas. Caso o acesso populao-alvo seja limitado, podemos pedir para pessoas de
perfil semelhante ou mesmo colegas participarem do estudo-piloto. importante
observar que qualquer pessoa envolvida num estudo-piloto no deve estar envolvida no
estudo principal, pois essas pessoas sabero mais sobre o estudo e podero distorcer os
resultados.
5.2 Que Dados Coletar?
A atividade mais essencial no desenvolvimento de um produto de qualidade entender
quem so seus usurios (reais ou potenciais) e de que eles precisam, documentando o
que tivermos aprendido (Courage e Baxter, 2005; Hackos e Redish, 1998). Tenha em mente
que no devemos nos concentrar apenas nos usurios melhores ou mais experientes.
Alm disso, mesmo uma pessoa que considerada especialista num sistema pode no
ser especialista em todas as partes desse sistema.
Em geral, so coletados dados sobre o prprio usurio, dados sobre sua relao com
tecnologia, sobre seu conhecimento do domnio do produto e das tarefas que dever
realizar utilizando o produto. Em geral, so coletados os seguintes tipos de dados
(Hackos e Redish, 1998; Courage e Baxter, 2005):
dados demogrficos: idade, sexo, status socioeconmico;
experincia no cargo que ocupa: cargo atual, experincia nesse cargo, tempo na empresa,
responsabilidades, trabalhos e cargos anteriores, plano de carreira;
informaes sobre a empresa: tamanho da empresa, rea de atuao;
educao: grau de instruo, rea de formao, cursos realizados, alfabetismo. O quo
bem o usurio l? Ele tem dificuldade com informao impressa? Tem experincia
com textos complexos? Est disposto a ler texto ao utilizar produtos como o que est
sendo projetado? Prefere aprender com outras pessoas? Prefere aprender fazendo?;
experincia com computadores: alfabetismo computacional, habilidade com
computadores, anos de experincia. Que sistemas computacionais o usurio conhece?
Quais deles costuma utilizar? Que hardware costuma utilizar?;
experincia com um produto especfico ou ferramentas semelhantes: experincia com
produtos concorrentes e outros produtos especficos do domnio, hbitos de uso,
preferncias e descontentamentos;
tecnologia disponvel: hardware (tamanho e resoluo do monitor, velocidade do
processamento etc.), software e outras ferramentas aos quais tem acesso;
treinamento: o quanto o usurio valoriza treinamento? Prefere um estilo de aprendizado
visual, auditivo ou outro? Pode investir tempo aprendendo a utilizar o produto em
questo?;
atitudes e valores: preferncias de produto, medo de tecnologia etc. O usurio costuma
assumir riscos e explorar novas formas de fazer o mesmo trabalho? Ou evita novas
experincias, preferindo caminhos j percorridos e testados? Ou prefere que algum
lhes mostre cada passo de uma nova tarefa sendo aprendida?;
conhecimento do domnio: o que e quanto o usurio conhece sobre o assunto em questo?
especialista? esperado que se torne um especialista?;
objetivos: quais so os principais objetivos dos usurio? Como eles so alcanados
atualmente?;
tarefas: quais so as tarefas do usurio que precisam ser apoiadas? Quais dessas so
consideradas primrias, e quais so secundrias? H quanto tempo realiza essas
tarefas? So tarefas frequentes ou infrequentes? So tarefas inovadoras? Que
experincia ele possui em tarefas semelhantes?;
gravidade dos erros: em geral, as possveis consequncias dos erros de um usurio;
motivao para o trabalho: o usurio se limita a cumprir a carga horria ou trabalha alm
do expediente, por prazer? Gosta da interao social no local de trabalho? Tem
ambio de ser promovido?;
idiomas e jarges: que idiomas o usurio conhece e utiliza fluentemente? Ele possui um
jargo profissional particular, um vocabulrio prprio da empresa, da sua atividade
ou de algum grupo social relevante para o seu projeto?
medida que conduzimos atividades de levantamento de requisitos, coletamos
informaes para (re)alimentar diversos artefatos utilizados na anlise de IHC, tais
como: perfis de usurios, personas, cenrios e modelos de tarefa. Esses artefatos so
apresentados no Captulo 6. A prxima seo enumera diversas fontes de informao que
podem fornecer os dados necessrios ao projeto.
5.3 De Quem Coletar Dados?
Um aspecto importante da coleta de dados definir quem fornecer qual tipo de
informao. Ao coletar dados sobre os usurios do sistema, essencial encontrar fontes
confiveis, relevantes e representativas dos usurios e do seu trabalho. Caso contrrio,
no apenas os dados coletados sero de pouca utilidade, como tambm podem
prejudicar seu produto, sua credibilidade e a credibilidade das atividades de IHC em
geral.
O termo usurio geralmente diz respeito aos usurios finais, aqueles que so ou
sero usurios diretos do seu produto, sejam primrios, que utilizam o produto
regularmente, ou secundrios, que o utilizam ocasionalmente, por exemplo, em
atividades de configurao eventuais. Alm deles, pode ser importante traar o perfil de
outras partes interessadas (stakeholders), que no utilizam o produto diretamente mas
so afetados pelo seu uso, como, por exemplo, pessoas que devem receber informaes
ou artefatos resultantes do uso do produto. Note que o termo stakeholders costuma se
aplicar a todas as partes interessadas, incluindo os prprios usurios. Alm disso, um
nico stakeholder pode exercer diversos papis num sistema ou organizao, os quais
podem ter necessidades contraditrias.
Para identificar as partes interessadas que podem fornecer informaes relevantes ao
projeto de um sistema, devemos descobrir: quem utilizar o sistema? Quem ser afetado
por ele? Quem responsvel por decidir quais objetivos o sistema deve apoiar e quais
funcionalidades ele deve ter? Quem definiu os processos a serem apoiados pelo sistema?
Caso o projeto em questo seja de melhoria ou expanso de um sistema existente,
importante conhecer tambm: quem utiliza o sistema atualmente? Alm desses, quem
passar a utiliz-lo? Quem so os usurios satisfeitos com o sistema? E quem so os
insatisfeitos? Quem concebeu o sistema? Quem preparou a documentao do sistema?
Quem d treinamento aos usurios? Quem d suporte aos usurios? Quem faz a
manuteno do sistema? Quem projetou o sistema?
Para escolher uma tcnica de coleta de dados, necessrio identificar o tipo de acesso a
cada fonte de informao. A disponibilidade e localizao das pessoas restringem o tipo
de tcnica de coleta de dados que pode ser utilizada. Algumas pessoas podem ter sado
da empresa onde o sistema utilizado e se tornado inacessveis; outras podem ter sido
promovidas ou deslocadas para outros setores; e ainda outras podem estar envolvidas em
outras atividades e no ter tempo hbil para participar dessa etapa do projeto. Pessoas
dispersas geograficamente tambm restringem o tipo de tcnica de coleta de dados a ser
utilizada. Por exemplo, muito difcil realizar um grupo de foco distncia, mesmo com
as tecnologias de videoconferncia disponveis hoje em dia.
Antes de comear a trabalhar com um usurio sequer, precisamos entender o domnio
em que estamos trabalhando. Quando o produto j conhecido, Beyer e Holtzblatt (1998)
sugerem identificar necessidades que ainda no foram reconhecidas. Quando se trata de
uma melhoria no produto (upgrade), os desafios so entender as razes das solicitaes
de melhoria e projetar uma soluo que satisfaa a necessidade mantendo a prtica de
trabalho coerente e preservando a integridade do design do sistema. preciso examinar
toda a prtica de trabalho para entender de que maneira a mudana afeta o trabalho
como um todo, e olhar em detalhes o uso de ferramentas para ver quais mecanismos de
interao funcionam, quais atrapalham os usurios e quais podem ser reaproveitados
para outras situaes ou solicitaes de mudana.
J ao enderear um novo domnio de trabalho, importante definir o trabalho que o
novo produto substituir, e estudar esse trabalho para aprender o que importante e
como ele estruturado, de modo a facilitar a transio para o novo produto. Para isso
importante coletar informaes sobre as intenes dos usurios e como so realizadas
utilizando as ferramentas atuais. O resultado de projetar um sistema novo definir
novas formas de trabalhar e os sistemas que as apoiam. Alm disso, quando uma nova
tecnologia est em jogo, importante buscar analogias com as tecnologias existentes e
como elas so utilizadas.
Podemos buscar dados que nos ajudem a aprender sobre o produto atravs de
diferentes fontes, tais como: feedback dos usurios, arquivos de log, anlise competitiva e
pesquisa em geral (Courage e Baxter, 2005).
Se estamos trabalhando com um produto que j possui uma verso em produo e a
empresa possui um grupo de suporte aos usurios, podemos aprender bastante sobre o
produto conversando com esse grupo. Caso tenhamos um registro do feedback dos
usurios, podemos precisar conduzir entrevistas ou estudos de campo junto aos usurios
para entender melhor as questes levantadas.
Embora os arquivos de log indiquem caminhos que os usurios percorreram durante a
interao com a aplicao, eles possuem diversas limitaes quanto ao que pode ser
capturado. Na Web, nem sempre h uma identificao nica de cada usurio. Alm
disso, a funcionalidade de cache no navegador e o uso do boto de voltar podem deixar
lacunas no registro. Examinando apenas o log, no possvel inferir as razes pelas quais
o usurio demorou o tempo registrado numa pgina Web ou num mdulo de um sistema
tradicional. Por exemplo, se um usurio desviar sua ateno do sistema para atender um
telefonema, o tempo de utilizao registrado para o mdulo correspondente no
corresponder ao uso real do sistema. E quase sempre difcil ou at mesmo impossvel
inferir se um usurio atingiu seu objetivo. Sendo assim, a anlise de arquivos de log deve
ser complementada por outras tcnicas. Alm disso, ao analisarmos o tempo despendido
numa parte do sistema, melhor utilizar o valor mediano em vez do valor mdio, pois
este mais suscetvel a situaes extremas incomuns.
A anlise competitiva pode ser uma forma eficiente de obter vantagem sobre seus
competidores. Alm de examinarmos os competidores diretos, devemos tambm analisar
os produtos que os substituem ou complementam.1 Esses produtos podem ou no
competir diretamente com o seu, mas podem ter caractersticas semelhantes a ele e
devem ser estudados para aprender seus pontos fortes e fracos, conhecer o perfil de seus
usurios e clientes, a disponibilidade do produto, suas caractersticas e funcionalidades
nicas, sua reputao e seus requisitos de hardware e software. Uma anlise competitiva
voltada para IHC vai alm da abrangncia das funcionalidades do sistema, e se concentra
em aspectos da experincia do usurio, como estilo e caractersticas da interface com
usurio, estrutura das tarefas, terminologia, satisfao dos usurios e qualidade de uso
em geral. O produto de uma anlise competitiva geralmente uma tabela comparativa do
seu produto com os dos seus competidores, que pode ser consultada e atualizada ao
longo do processo de desenvolvimento.
A documentao de processos e normas tambm um insumo importante para a
anlise, pois define restries sobre o que o usurio poder ou no fazer atravs do
sistema, e s vezes at como ele poder utiliz-lo.
Para conhecermos um produto, tambm devemos utiliz-lo. Em geral, a equipe de
design est cercada por pessoas que conhecem o domnio e o produto. Devemos
encontrar as pessoas que apoiam o produto atual e ler seus relatrios de problemas e
acompanhamento do uso, bem como as pessoas que escrevem o contedo tcnico da
empresa e que elaboram os manuais, a ajuda on-line e o material de treinamento. Tudo o
que for difcil de documentar pode ser resultado de um produto complicado demais para
explicar.
importante definir uma viso inicial do que est em jogo: quem so os usurios,
clientes e demais partes interessadas; quais seus objetivos e quais tarefas realizam para
atingi-los. Essa viso permitir escolher as tcnicas de anlise utilizadas ao longo do
projeto.
5.4 Aspectos ticos de Pesquisas Envolvendo
Pessoas
Muitas profisses possuem cdigos de tica que regulam seu exerccio. Em geral, os
cdigos de tica recebem maior destaque em profisses que atuam diretamente sobre as
pessoas, como na rea de sade, por exemplo. A Computao tambm possui uma forte
preocupao com a tica em suas pesquisas e intervenes (Johnson, 2001). Algumas
associaes de profissionais da Computao, como a ACM e a IEEE, possuem cdigos de
tica que orientam o trabalho dos seus associados. No cdigo de tica da ACM (1992),
podemos destacar os seguintes cuidados ticos (ou deveres morais): evitar causar danos
ou consequncias negativas aos outros, tais como perda de informao, perda de bens,
danos a propriedades, ou impactos ambientais indesejados; respeitar a privacidade dos
outros; e honrar a confidencialidade de informaes a que tivermos acesso. No cdigo de
tica da IEEE (2006), podemos destacar o seguinte cuidado tico: evitar prejudicar ou
causar dano a outras pessoas, seus bens, reputao ou emprego. No Brasil, apesar de a
Sociedade Brasileira de Computao ainda no ter um cdigo de tica, os currculos de
referncia da rea abordam o tema.
de responsabilidade da equipe de design proteger o bem-estar fsico e psicolgico
dos participantes de qualquer estudo, pesquisa ou anlise realizada (Johnson, 2001). No
Brasil, a Resoluo n 196/96 do Conselho Nacional de Sade (1996) regulamenta as
pesquisas cientficas envolvendo pessoas, em qualquer rea do conhecimento. Apesar de
essa resoluo no se aplicar execuo de mtodos de avaliao com objetivos tcnicos,
suas recomendaes so muito teis para orientar os avaliadores no cuidado tico
durante seu trabalho. Segundo essa resoluo, esses cuidados envolvem considerar os
seguintes princpios (p. 2):
princpio da autonomia, que envolve o consentimento livre e esclarecido dos indivduos e a
proteo a grupos vulnerveis e aos legalmente incapazes, tais como: menores de
idade, alunos ou subordinados. Nesse sentido, a pesquisa envolvendo seres humanos
dever sempre trat-los com dignidade, respeit-los em sua autonomia e defend-los
em sua vulnerabilidade;
princpio da beneficncia, que envolve a ponderao entre riscos e benefcios, tanto atuais
como potenciais, individuais ou coletivos, comprometendo-se com o mximo de
benefcios e o mnimo de danos e riscos. Os danos podem ocorrer na dimenso fsica,
psquica, moral, intelectual, social, cultural ou espiritual do ser humano, em qualquer
fase da pesquisa ou depois dela;
princpio da no maleficncia, que envolve a garantia de evitar danos previsveis
relacionados pesquisa, tanto os imediatos quanto os tardios;
princpio da justia e equidade, relacionado relevncia social da pesquisa, com
vantagens significativas para os participantes da pesquisa e minimizao do nus
para os participantes vulnerveis, o que garante a igual considerao dos interesses
envolvidos, no perdendo o sentido de sua destinao scio-humanitria.
Com base nesses princpios ticos da Resoluo n 196/96 e na literatura (Johnson,
2001; Courage e Baxter, 2005; Sharp et al., 2007), podemos sugerir diversas diretrizes para
as pesquisas e avaliaes de IHC, descritas a seguir.
O pesquisador deve explicar os objetivos da pesquisa aos participantes e dizer
exatamente como dever ser a participao deles. Ele deve deixar claro o que vai ocorrer
durante a coleta de dados, o tempo aproximado da coleta, os tipos de dados que sero
coletados, e ainda como eles sero analisados. Qualquer dvida do participante sobre a
pesquisa deve ser esclarecida prontamente pelo avaliador.
O pesquisador deve garantir aos participantes a confidencialidade e a privacidade dos
dados brutos coletados. Com o consentimento dos participantes, os dados brutos so
compartilhados apenas com os pesquisadores. Ningum mais deve ter acesso a esses
dados brutos.
Ao divulgar os resultados da avaliao, o avaliador deve garantir o anonimato dos
participantes, a preservao das suas imagens e a utilizao cuidadosa das informaes
coletadas. Isso significa no divulgar seus nomes ou qualquer outra informao que
possa identific-los. O objetivo principal no prejudicar os participantes, direta ou
indiretamente, seja em termos de autoestima, de prestgio, na profisso, ou de qualquer
outra forma. Esse cuidado tico deve ser tomado em todas as mdias em que as
informaes sero publicadas, seja em veculos impressos ou digitais, em textos,
imagens, udios ou vdeos. comum utilizar nomes fictcios ou nmeros em todo o
material coletado para identific-los apenas assim no relato dos resultados de uma
pesquisa. Por exemplo, um participante pode citar nomes de pessoas com quem ele se
relaciona, como no domnio de correio eletrnico. Nem o nome do participante, nem os
nomes dos seus conhecidos podem ser divulgados, devendo ser substitudos por nomes
fictcios ou por alguma mscara, como [nome]. Alm disso, se o participante utilizar
algum jargo ou expresso particular, devemos evitar divulg-la nos resultados da
avaliao porque seus conhecidos podem identific-lo. A idade, a profisso e o sexo dos
participantes tambm podem identific-los, caso o participante seja diferente dos
demais, como uma mulher dentre vrios homens, ou uma pessoa de mais idade dentre
vrios mais jovens. O anonimato, a princpio, voltado para terceiros. Entretanto,
quando o pesquisador critica os dados obtidos, desejvel que nem o participante que os
forneceu se reconhea nos relatos, pois eventuais crticas podem afetar sua autoestima.
Nesses casos, o pesquisador deve relatar o que ocorreu com um grupo de participantes e
os motivos para isso, em vez de criticar ou apresentar falhas de um participante
especfico. Sempre que possvel, os participantes devem ter acesso aos resultados da
pesquisa antes que eles sejam publicados.
necessrio obter permisso para gravar a voz ou imagem de qualquer pessoa, antes
de comear a gravao. Devemos informar aos participantes logo no recrutamento sobre
os tipos de gravaes que sero realizadas, para evitar mal-entendidos ou desistncias no
momento da atividade.
A participao na pesquisa deve ocorrer apenas com o consentimento livre e
esclarecido dos participantes. Todo participante de qualquer estudo tem o direito de
saber o objetivo do estudo, a durao estimada, os procedimentos de coleta de dados, o
uso que ser feito da informao coletada, os seus direitos enquanto participante do
estudo e quaisquer riscos, desconfortos ou efeitos adversos relacionados sua
participao no estudo. Essas informaes devem ser comunicadas ao participante
durante o processo de recrutamento e depois reiteradas no incio da atividade atravs de
um termo de consentimento. Ao assinar esse termo, o participante atesta que entende as
garantias e os riscos do estudo e concorda com sua participao naquelas condies. Caso
o participante tenha menos de 18 anos, o termo de consentimento deve ser assinado pelo
seu responsvel legal. O termo de consentimento tambm deve ser assinado pelo
responsvel pelo estudo, atestando sua responsabilidade e comprometimento com as
garantias ali asseguradas. Uma das vias assinadas do termo de consentimento permanece
com o pesquisador, enquanto a outra entregue ao participante. O Exemplo 5.1 apresenta
um termo de consentimento para a realizao de uma entrevista.

Exemplo 5.1
T ermo de consentimento
Somos uma equipe de consultoria da empresa, que est participando do
projeto do sistema nome e breve descrio do sistema. Nessa etapa do
projeto, queremos conhecer o que algumas das pessoas que iro usar
o/ser afetadas pelo sistema pensam a respeito do sistema atual/processo
atual e como imaginam que o novo sistema deveria apoiar o seu trabalho.
Estamos realizando uma srie de pesquisas, e solicitamos seu
consentimento para a realizao e gravao de uma entrevista. Para decidir
sobre o seu consentimento, importante que voc conhea as seguintes
informaes sobre a pesquisa:
Os dados coletados durante a entrevista destinam-se estritamente a
atividades de anlise e desenvolvimento do sistema nome do sistema.
Nossa equipe tem o compromisso de divulgar os resultados de nossas
pesquisas para o cliente. A divulgao desses resultados pauta-se no
respeito sua privacidade, e o anonimato dos participantes ser
preservado em quaisquer documentos que elaborarmos.
O consentimento para a entrevista uma escolha livre, feita mediante
a prestao de todos os esclarecimentos necessrios sobre a pesquisa.
A entrevista pode ser interrompida a qualquer momento, segundo a
sua disponibilidade e vontade.
Nossa equipe encontra-se disponvel para contato atravs do e-mail e-
mail.
De posse dessas informaes, gostaramos que voc se pronunciasse
acerca da entrevista:
( ) Dou meu consentimento para a sua realizao.
( ) No consinto com a sua realizao.
local, data
assinatura do entrevistador assinatura do entrevistado
nome do entrevistador nome do entrevistado

O conforto dos participantes deve ser cuidadosamente considerado. Os participantes


de um estudo nunca devem se sentir desconfortveis, seja fsica ou psicologicamente.
Isso inclui coisas simples, como oferecer pausas para beberem gua ou irem ao banheiro,
alm de instalaes confortveis. Eles devem ser tratados com respeito o tempo todo.
Devemos evitar utilizar termos pejorativos ao nos referirmos ao participante, como
cobaia, por exemplo. Alm disso, no caso de observao de uso de um produto, devemos
enfatizar que o produto que ser avaliado, e no o participante.
O participante tem o direito e a liberdade de se recusar a participar ou retirar seu
consentimento e abandonar o estudo em qualquer fase da pesquisa, sem ser penalizado
por isso. Sempre que o pesquisador perceber que o participante est passando por algum
tipo de constrangimento ou incmodo fsico, emocional ou psquico, deve interromper a
pesquisa antes que o participante tenha mais sofrimentos desnecessrios. Uma pesquisa
de IHC no deve deixar os participantes excessivamente exaustos, nervosos, ou lev-los
ao pranto. Ela deve ser interrompida bem antes disso.
Os participantes devem preferencialmente ter autonomia plena para serem capazes de
decidir participar ou no do estudo ou coleta de dados. Devemos evitar a participao de
sujeitos vulnerveis, tais como: menores de idade, alunos ou subordinados, a menos que
este seja explicitamente o perfil dos participantes. Nesses casos, o pesquisador deve
tomar um cuidado ainda maior para no causar constrangimentos ou danos aos
participantes.
Antes de comear a pesquisa, o pesquisador deve combinar com o participante formas
de incentivo participao da avaliao, como, por exemplo, livros, brindes, vale-
presentes, ou pagamento em dinheiro. importante notar que no Brasil no permitido
pagar para as pessoas participarem de uma pesquisa cientfica, como ocorre em outros
pases. Aqui s permitido ressarcir as despesas decorrentes da participao da
pesquisa, basicamente transporte e alimentao nos dias de participao. Essa restrio
no se aplica a pesquisas de cunho tcnico ou prtico, como, por exemplo, uma pesquisa
visando ao reprojeto de um sistema comercial.
Embora os cuidados ao lidar com os participantes sejam sempre prioritrios,
importante tambm considerar os aspectos ticos relacionados aos dados coletados
(Lazar et al., 2010; Cooper, 1999), em particular no que diz respeito validade e
confiabilidade dos dados, e reteno de dados e documentao. Devemos proteger os
dados coletados, para que no sejam mal interpretados ou corrompidos. Se isso ocorrer,
todo o tempo e outros recursos despendidos na coleta dos dados sero desperdiados,
pois os dados tero de ser descartados. Os dados devem ser vlidos e confiveis, seno o
risco de causar mais prejuzo do que benefcios grande, pois dados distorcidos,
corrompidos ou invlidos podem resultar em decises de projeto inadequadas. Alm
disso, os dados devem ser mantidos apenas enquanto forem relevantes. Quando no
precisarem mais ser utilizados, devem ser descartados.
As perguntas feitas aos participantes e as reaes dos designers aos seus comentrios
podem afetar os dados coletados. Devemos assegurar que os dados coletados sejam
livres de tendenciosidades ou inclinaes indevidas (bias), sejam corretos, vlidos e
confiveis. Caso haja suspeita que um dado seja invlido ou no confivel, ele deve ser
descartado. Alm disso, as partes interessadas nos resultados do estudo devem ser
informadas sobre as limitaes dos dados coletados.
Alm dos cuidados com os dados do participante, pode ser necessrio assegurar a
confidencialidade dos dados ou sistemas apresentados aos participantes, principalmente
quando se trata de produtos comerciais. Nesses casos, o participante deve assinar um
acordo de confidencialidade, no qual se compromete a manter todas as informaes
relacionadas ao produto e ao estudo confidenciais por um determinado perodo de
tempo. Em geral, acordos de confidencialidade so elaborados pelo departamento
jurdico da empresa proprietria do produto.
5.5 Como Coletar Dados dos Usurios?
Dentre as tcnicas utilizadas frequentemente para coletar dados e levantar os requisitos
dos usurios, destacamos:
entrevistas;
grupos de foco;
questionrios;
brainstorming de necessidades e desejos dos usurios;
classificao de cartes (card sorting);
estudos de campo;
investigao contextual.
Essas tcnicas podem ser caracterizadas quanto ao seu objetivo, suas vantagens e o
nvel de esforo necessrio para sua aplicao, conforme a Tabela 5.1.

Tabela 5.1
Quadro comparativo de tcnicas de levantamento de requisitos (adaptado de
Courage e Baxter, 2005)
5.5.1 Entrevistas
A entrevista uma das tcnicas mais utilizadas de coleta de dados e levantamento de
requisitos. Trata-se de uma conversa guiada por um roteiro de perguntas ou tpicos, na
qual um entrevistador busca obter informao de um entrevistado (Seidman, 1998).
Quando h mais de um entrevistado, costumamos chamar essa atividade de grupo de
foco, conforme visto na prxima subseo. H diversos tipos de entrevista, dependendo
das suas limitaes e necessidades.
Numa entrevista, as perguntas podem ser abertas ou fechadas (Lazar et al., 2010; Sharp
et al., 2007). As perguntas abertas tm natureza exploratria. Nelas, no h qualquer
restrio sobre o tipo ou tamanho de resposta que o entrevistado poder fornecer. Uma
pergunta aberta bem til quando temos pouco ou nenhum entendimento sobre a
situao e quando queremos obter a opinio e as reaes das pessoas sobre uma nova
ideia de design. Mesmo quando a situao conhecida, as perguntas abertas permitem
revelar opinies ou fatos desconhecidos e inesperados. Um exemplo de pergunta aberta
O que voc acha do mecanismo de busca do Web site CompreMais?
As perguntas fechadas apresentam um conjunto predefinido de respostas dentre as
quais o entrevistado deve selecionar. Perguntas fechadas requerem que o entrevistado
conhea as respostas provveis. Esse tipo de pergunta costuma ser mais utilizado em
questionrios. Uma pergunta fechada pode ser utilizada para coletar feedback rpido
sobre uma opo de design especfica. Por exemplo, a pergunta Num Web site de
comrcio eletrnico, voc prefere navegar pelas sees dos produtos ou fazer
diretamente uma busca pelo produto desejado? restringe o espao de resposta do
usurio s duas opes oferecidas.
Do ponto de vista de anlise dos dados coletados, as perguntas fechadas so analisadas
mais rapidamente do que perguntas abertas, e, em geral, se destinam coleta de dados
quantitativos ou quantificveis, ao passo que as perguntas abertas se destinam
principalmente coleta de dados qualitativos e estudos em profundidade.
As entrevistas podem ser classificadas em estruturadas, no estruturadas e
semiestruturadas. Em uma entrevista estruturada, o entrevistador se mantm fiel a um
roteiro, fazendo as perguntas previamente definidas na ordem especificada. O
entrevistador no possui muita liberdade para explorar tpicos novos que surjam
durante a entrevista. Em geral, essa entrevista composta na sua maioria de respostas
fechadas. Em contrapartida, em uma entrevista no estruturada, o entrevistador realiza
perguntas de modo bastante flexvel, usando perguntas abertas e se aprofundando mais
em alguns tpicos. Nesse tipo de entrevista, o nico comprometimento do entrevistador
com o tpico abordado.
Em geral, buscamos um meio termo, e conduzimos entrevistas semiestruturadas.
Nessas entrevistas, o roteiro composto dos tpicos ou perguntas (geralmente abertas)
que devem ser endereados na entrevista, em uma ordem lgica. O entrevistador tem
liberdade para explorar em maior profundidade as respostas fornecidas pelo
entrevistado e at mesmo modificar a ordem dos tpicos abordados, mas deve manter o
foco nos objetivos da entrevista.
O roteiro de entrevistas pode conter perguntas completas ou apenas os tpicos que
devem ser endereados durante a entrevista. Para manter o tom natural da conversa,
principalmente em entrevistas semiestruturadas, algumas pessoas evitam redigir no
roteiro as perguntas literais que devem ser feitas. Por exemplo, em vez de incluir no
roteiro a pergunta: O que voc acha do mecanismo de busca do site CompreMais?, o
roteiro pode conter algo como mecanismo de busca opinio geral.
Embora perguntas completas assegurem que sero feitas exatamente da mesma forma
para todos os entrevistados, possvel que a conversa se torne menos fluida, com o
entrevistador lendo a pergunta de modo a quebrar o ritmo da conversa. No caso de uma
lista tpicos, a conversa se torna mais natural, pois o entrevistador apenas consulta o
roteiro e tem liberdade de formular a pergunta relacionada a cada tpico de forma mais
adequada ao perfil do entrevistado, buscando manter o tom da conversa at o momento.
No entanto, dependemos mais da experincia do entrevistador em formular as perguntas
de modo a no alterar o contedo das perguntas ou se desviar dos seus objetivos.
Podemos ainda fazer um roteiro hbrido, com tpicos atuando como lembretes para o
entrevistador coletar as informaes necessrias, e com perguntas de exemplo para
auxiliar entrevistadores menos experientes (Exemplo 5.2).

Exemplo 5.2
R oteiro (parcial) de entrevista para um
professor universitrio.
Experincia como professor de curso (tempo rea nvel):
H quantos anos? Que rea(s)?
Que nvel (graduao/ps-graduao/extenso)?
Funo (atividades frequncia satisfao)
Quais as principais atividades? Quais as mais frequentes? E as menos
frequentes?
De quais gosta mais de realizar? E de quais gosta menos? Por qu?
Diviso de responsabilidades (diviso responsvel satisfao
desejos)
[professor, coordenao, suporte, universidade]
Quem faz o qu (definio do programa, critrio de avaliao)?
Satisfao com a diviso atual? Delegaria o qu? Centralizaria o qu?
Utilizao de tecnologias computacionais para apoiar o seu trabalho
(tecnologia/atividade frequncia satisfao desejos)
Usa?
SIM: Quais? Para qu? Com que frequncia?
O que mais gosta? O que menos gosta? O que faria diferente?
NO: J usou? Por que no usa (mais)? O que precisaria ter para voc
usar?
Sistema ideal
Comentrios adicionais

J no caso de entrevistas estruturadas, costumamos formular as questes tal como


sero perguntadas, para assegurar a validade de uma anlise comparativa das respostas
por toda a amostra de entrevistados. Seja qual for o tipo de entrevista, o roteiro deve ser
revisado perante os objetivos da coleta de dados, para evitar incluir perguntas esprias
ou deixar de incluir perguntas que visem coletar dados necessrios ao atingimento dos
objetivos da entrevista.
Uma sesso de entrevista costuma seguir a seguinte estrutura: uma apresentao, na
qual o entrevistador se apresenta e explica o objetivo da entrevista; um perodo de
aquecimento, no qual so feitas perguntas de fcil resposta, como dados demogrficos; a
parte principal da entrevista, na qual o roteiro explorado; um perodo de desaquecimento,
para desfazer alguma tenso que tenha surgido; e a concluso, na qual o entrevistador
agradece ao entrevistado pelo seu tempo, desliga o gravador e guarda suas anotaes,
indicando que a entrevista terminou (Sharp et al., 2007).
O entrevistador deve evitar influenciar as respostas dos entrevistados com a
formulao das perguntas, expresses faciais, gestos ou entonao de voz. Ao perguntar
Por que voc gosta do mecanismo de busca do site CompreMais?, por exemplo, o
entrevistador j est pressupondo que o entrevistado gosta desse mecanismo, o que pode
no corresponder realidade. Esse tipo de pergunta pode desmotivar o entrevistado a
dar sua opinio sincera e fazer com que ele responda o que acredita que o entrevistador
queira ouvir.
Perguntas do tipo sim ou no costumam ser utilizadas para filtrar algumas
perguntas subsequentes e definir o rumo da entrevista. Por exemplo, o entrevistador
pode perguntar Voc j utilizou o mecanismo de busca do site CompreMais?, para
decidir se deve ou no se aprofundar nesse ponto. Para outros propsitos, perguntas
desse tipo devem ser evitadas, pois podem induzir o entrevistado a dar a resposta que ele
acredita que o entrevistador gostaria que ele desse. Por exemplo, ao perguntar Voc
gosta do mecanismo de busca do site CompreMais?, o entrevistado pode querer agradar
o entrevistador e responder rapidamente sim. No apenas essa resposta pode no
refletir corretamente a opinio do entrevistado, como tambm traz pouca informao
entrevista. Se, no entanto, o entrevistador pergunta O que voc acha do mecanismo de
busca do site CompreMais?, o entrevistado motivado a fornecer uma resposta mais
elaborada.
H casos em que o entrevistado fornece uma resposta muito sucinta para uma
pergunta aberta, como Bom, Ruim, Gosto, No gosto. Nessas situaes, cabe ao
entrevistador explorar um pouco mais a resposta fazendo perguntas adicionais, como por
exemplo: O que voc mais gosta nesse mecanismo de busca?; E o que voc menos gosta
nesse mecanismo de busca?; Houve algum momento em que o mecanismo de busca
no trouxe o resultado esperado?; e, em caso de resposta positiva: O que voc estava
buscando nesse momento?
Dependendo do objetivo da entrevista, perguntas fechadas podem prejudicar a coleta
dos dados, por restringirem demais a expresso do entrevistado, que precisa encaixar a
sua resposta naquelas previstas no roteiro. Considere, numa fase preliminar de
levantamento de dados, uma pergunta do tipo A ou B, como, por exemplo, Voc
prefere procurar um apartamento fornecendo o nome da rua ou pelo mapa?. Embora
haja outras formas de buscar um apartamento (e.g., pelo nmero de cmodos e vagas na
garagem, faixa de preo etc.), a pergunta fechada pode fazer com que o entrevistado deixe
de responder o que realmente pensa para fornecer uma resposta que se encaixe nas
opes fornecidas, falseando, assim, o dado coletado.
Como a entrevista se assemelha a uma conversa, devemos evitar perguntas muito
longas ou complexas, que sobrecarreguem a memria do entrevistado e prejudiquem sua
resposta. Perguntas compostas devem ser desdobradas em perguntas menores. Por
exemplo, em vez de perguntarmos O que voc acha da estrutura dos menus e submenus
e da terminologia utilizada, em comparao com outros sites semelhantes?, podemos
perguntar primeiro O que voc acha da estrutura de menus e submenus do site?,
depois O que voc acha dos rtulos dos menus e submenus? e, finalmente, Voc
conhece algum site semelhante? e, em caso positivo: Como voc compara esses menus
com os desse site? Caso contrrio, aumentamos o risco de o entrevistado responder
apenas parte da pergunta.
A terminologia utilizada numa entrevista tambm deve ser cuidadosa. Devemos evitar
utilizar termos tcnicos com os quais os entrevistados no tenham familiaridade.
Quando um jargo desconhecido utilizado numa entrevista, possvel que o
entrevistado no entenda direito a pergunta e, portanto, fornea uma resposta pouco
informativa ou at mesmo incorreta.
As entrevistas costumam ser gravadas em udio. Alm dessa gravao, os
entrevistadores podem fazer algumas anotaes durante a entrevista. Nesse caso, o
roteiro pode ser projetado com espao para anotar as respostas. Alm disso, para
perguntas fechadas, o roteiro impresso pode incluir as respostas predefinidas de modo
que o entrevistador marque rapidamente a que tiver sido selecionada pelo entrevistado,
como, por exemplo:

Voc j fez compras em sites de comrcio eletrnico alguma vez?


sim
no
no se lembra
Alm de entrevistas presenciais ou face a face, possvel conduzir entrevistas pelo
telefone ou on-line, em geral atravs de um sistema de comunicao sncrona (como chat
ou videoconferncia) ou assncrona (como e-mail).
Os entrevistadores devem ser treinados para realizar a entrevista. importante que
eles conheam a fundo o roteiro, tenham segurana sobre os seus objetivos e prestem
ateno ao que os entrevistados dizem para que possam formular perguntas que lhes
permitam se aprofundarem nos tpicos investigados. Essa uma caracterstica
importante e vantajosa da entrevista, principalmente em comparao com questionrios,
e que pode ser prejudicada pela inexperincia ou falta de treinamento do entrevistador.
Por exemplo, um entrevistador que no conhea bem o roteiro pode ficar to preocupado
com a prxima pergunta a ser feita que deixa de prestar ateno ao que o entrevistado
est dizendo, confiando exclusivamente na gravao de udio e perdendo oportunidades
preciosas de fazer perguntas adicionais para se aprofundar nas respostas.
As entrevistas so muito flexveis e podem ser utilizadas de forma independente ou
em conjunto com alguma outra atividade de coleta de dados e levantamento de
requisitos. Como ocorre em toda triangulao de dados, algumas informaes fornecidas
em uma entrevista podem ser contestadas por dados coletados utilizando outras
tcnicas. Por exemplo, aps perguntar quais sites o entrevistado mais visita ou quanto
tempo passa navegando na Web, possvel comparar suas respostas com algum registro
de software que monitore sua navegao real, permitindo triangular a percepo do
entrevistado (dado subjetivo) com os fatos, dados objetivos.
Vale observar que nem sempre o que uma pessoa diz que faz o que ela realmente faz.
Algumas pessoas se esquecem o que exatamente aconteceu numa situao ou quanto
tempo levaram para realizar uma determinada tarefa, enquanto outras podem querer
projetar uma boa imagem de si mesmas e do seu trabalho. Para evitar esse tipo de
problema, algumas entrevistas podem envolver a observao do entrevistado enquanto
ele realiza uma ou mais atividades. A tcnica de investigao contextual uma forma
bem conhecida desse tipo de entrevista com observao, e apresentada na Seo 5.5.7.
O resultado de um conjunto de entrevistas uma integrao de perspectivas de
mltiplos usurios, com base nos comentrios recorrentes dos entrevistados. A anlise
das entrevistas pode ser feita interparticipante e intraparticipante (Nicolaci-da-Costa,
1994; Nicolaci-da-Costa et al., 2004). Na anlise interparticipante, para cada pergunta (ou
item do roteiro) individual, todas as respostas de todos os entrevistados so analisadas
sistemtica e rigorosamente. Essa anlise revela as tendncias centrais das respostas. J
na anlise intraparticipante, para cada entrevistado individual, todas as suas respostas
(para todas as perguntas) so analisadas, buscando identificar possveis conflitos de
opinies, inconsistncias entre respostas, sentimentos contraditrios etc. Essas duas
formas de anlise podem ser feitas alternadamente, visando aprofundar o resultado da
anlise e permitir detectar ausncias notveis, ou seja, o que os entrevistados deixaram
de dizer em certas respostas mas disseram ou sugeriram em outras, bem como detalhes
sobre seus sentimentos e atitudes, incluindo eventuais conflitos internos.
Ao conduzirmos entrevistas com diversos perfis de usurios sobre o mesmo processo,
sistema ou organizao, podemos obter uma viso profunda e abrangente dos tpicos
investigados. Como no costuma ser vivel realizar entrevistas com muitas pessoas,
podemos utilizar o resultado de uma entrevista para elaborar questionrios que
permitam coletar informaes de um nmero maior de pessoas, e assim obter resultados
estatisticamente significativos ou pelo menos mais representativos da populao de
interesse.

5.5.2 Questionrios
O uso de questionrios tambm uma das tcnicas de coleta de dados mais
frequentemente utilizadas. Um questionrio um formulrio impresso ou on-line com
perguntas que os usurios e demais participantes devem responder, a fim de fornecer os
dados necessrios em uma pesquisa, anlise ou avaliao. Diferentemente de entrevistas,
questionrios permitem coletar dados de um grande nmero de pessoas, at mesmo
geograficamente dispersas, compondo amostras muito maiores do que com entrevistas
ou grupos de foco. Assim como entrevistas, questionrios podem conter perguntas
abertas e fechadas, mas costumam privilegiar as perguntas fechadas, de preenchimento
rpido e de fcil anlise.
As pessoas podem responder questionrios no seu prprio tempo e no conforto do seu
lar ou local de trabalho. No entanto, como o respondente no ter como tirar dvidas
sobre as perguntas no momento de responder ao questionrio, a formulao da pergunta
(e das respostas) deve ser ainda mais cuidadosa do que no caso de entrevistas, evitando
ambiguidades e mal-entendidos (Lazar et al., 2010; Sharp et al., 2007). Alm disso, um
questionrio deve conter instrues claras sobre como responder cada pergunta,
indicando explicitamente se uma pergunta admite uma nica resposta ou mltiplas
respostas e utilizando smbolos informativos de forma consistente.
A taxa de respostas de um questionrio muito varivel. Segundo Courage e Baxter
(2005), varia de 1% em questionrios de filantropia a 95% em questionrios de censo. Em
alguns casos, para aumentar o nmero de questionrios respondidos, adotamos uma
estratgia de sortear brindes dentre os respondentes. No entanto, essa estratgia pode
falsear os dados coletados, fornecidos por pessoas interessadas mais nos brindes do que
em contribuir para a pesquisa.
Diferentemente de entrevistas, em questionrios no devemos fazer muitas perguntas
abertas, porque isso reduz a taxa de respostas. Utilizamos questionrios em geral quando
temos uma boa noo das respostas mais provveis e queremos conhecer a proporo de
respostas numa amostra mais ampla da populao de usurios. Embora restrinja os
dados coletados, essa estratgia torna a anlise dos dados mais rpida e fcil. Muitas
vezes os questionrios so utilizados em conjunto com entrevistas. Aps entrevistas
exploratrias, questionrios podem ser utilizados para corroborar os resultados das
entrevistas. Alm disso, caso as estatsticas coletadas atravs de questionrios sejam
inesperadas, novas entrevistas podem ser formuladas para descobrir os motivos por trs
das surpresas encontradas.
Como no h oportunidade de discutir sobre o questionrio ou tirar dvidas no
momento de respond-lo, as perguntas fechadas geralmente incluem respostas neutras
ou alternativas, como no sei, no quero responder ou outros. Muitos
pesquisadores costumam omitir perguntas negativas nos questionrios, para no
confundir os respondentes (Sharp et al., 2007). Outros misturam esses dois tipos de
perguntas justamente para ajudar a verificar a consistncia das respostas dos usurios.
Segundo Sharp e coautoras (2007), um questionrio tpico inicia com a seguinte
estrutura: informaes demogrficas bsicas (e.g., sexo, idade) e detalhes relevantes
sobre sua experincia (e.g., h quanto tempo utiliza computadores e nvel de experincia
com o domnio em questo). Essas perguntas auxiliam os pesquisadores a agruparem
respostas de diferentes usurios. Vale observar, no entanto, que essas informaes
contextuais devem se limitar quelas que forem relevantes aos objetivos do estudo.
Perguntas gerais costumam preceder perguntas especficas. Alis, a ordem das perguntas
deve ser cuidadosamente projetada, pois a resposta a uma pergunta pode ser
influenciada por uma das perguntas anteriores. Quando um questionrio longo, suas
perguntas podem ser agrupadas em tpicos relacionados, formando uma estrutura lgica
e de preenchimento mais fcil. Quando queremos obter informaes de grupos distintos
de usurios (e.g., professores e alunos, gerentes e tcnicos etc.), pode ser necessrio
elaborar um questionrio diferente para cada grupo.
Existem diversos tipos de perguntas e respostas utilizados em questionrios, dentre os
quais destacamos: mltipla escolha, faixas de valores, escalas e perguntas abertas.
Existem perguntas cujas respostas so previsveis, como, por exemplo, sexo (feminino
ou masculino). Nesses casos, podemos oferecer um conjunto de respostas de mltipla
escolha, como no exemplo a seguir:

Sexo:
masculino
feminino
prefiro no informar

Em alguns casos, o usurio pode escolher mais do que uma resposta. Esses casos
devem ser bem marcados, para diferenciar das perguntas de uma nica resposta. Por
exemplo, quando queremos descobrir quais as atividades mais frequentes dentro de um
conjunto de atividades predefinidas, podemos solicitar ao usurio que marque todas as
opes relevantes, ou um nmero mximo de opes, como a seguir:

Quais atividades voc realiza mais frequentemente on-line? (marque at


duas opes)
e-mail
leitura de notcias
transaes bancrias
participao em redes sociais
pesquisas gerais
compra de produtos
contrato de servios
outros

Algumas perguntas se referem a valores especficos, como idade ou renda mensal.


Como alguns respondentes no se sentem vontade em fornecer esses valores exatos, e
como a anlise desses dados costuma ser feita de forma agregada, comum oferecermos
faixas de valores como opes de resposta. Nesse tipo de pergunta, importante evitar a
sobreposio de valores (e.g., 2030 e 3040), para que a ambiguidade no prejudique a
acurcia dos dados coletados. Por exemplo:

Idade:
abaixo de 21
2130
3140
4150
acima de 50

Para facilitar a comparao das respostas dos usurios, com frequncia so utilizadas
escalas, dentre as quais as mais conhecidas so as escalas de Likert (1932) e as escalas de
diferenciais semnticos. A escala de Likert comumente utilizada para medir opinies,
atitudes, crenas e, no caso de IHC, satisfao dos usurios com um produto ou ideia de
design, como no exemplo a seguir:
fcil encontrar o produto desejado navegando pelas sees do site:
concordo plenamente
concordo parcialmente
no concordo nem discordo
discordo parcialmente
discordo totalmente

A escala de diferenciais semnticos, por sua vez, explora atitudes bipolares sobre um
item particular.

Para cada par de adjetivos a seguir, marque o valor correspondente sua


opinio sobre a pgina de um produto do site:
atraente feia
clara confusa
til intil

O nmero de valores de uma escala varivel. Em geral, utilizamos um nmero mpar


de valores, a menos que queiramos evitar que os usurios fiquem em cima do muro
(Sharp et al., 2007). Em escalas Likert, costumamos utilizar 5 pontos, e em escalas de
diferencial semntico utilizamos 5, 7 ou mesmo 9 pontos, este ltimo quando queremos
que os usurios faam julgamentos sutis sobre as caractersticas indicadas.
Perguntas abertas so utilizadas para obter informaes livres e possivelmente mais
detalhadas sobre alguns pontos. importante fornecer espao suficiente para o usurio
se expressar. Em geral, apenas duas ou trs linhas no so suficientes nem motivam uma
resposta extensa. Compare o formato das perguntas a seguir. Qual formato incentiva o
respondente a fornecer uma resposta mais completa?

(a) O que voc acha do mecanismo de busca do site?


____________________________________________________________________
____________________________________________________________________
(b) O que voc acha do mecanismo de busca do site?
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________
____________________________________________________________________

Devemos tomar cuidado para no incluirmos muitas perguntas abertas em um


questionrio, pois isso pode desmotivar os respondentes a complet-los.
Para coletar dados dos usurios atravs de questionrios, atualmente possvel utilizar
formulrios on-line. Existem diversos servios gratuitos ou pagos,2 que permitem no
apenas criar formulrios sofisticados para coletarmos os dados, mas tambm oferecem
diversas ferramentas de anlise dos dados coletados.
Como dito na seo anterior, muitas vezes os questionrios so utilizados aps
entrevistas exploratrias. Isso ocorre principalmente por dois motivos: (1) nessas
entrevistas so coletadas informaes que permitem elaborar melhores perguntas no
questionrio, e (2) os questionrios permitem descobrir o quanto as informaes
fornecidas pelos entrevistados so representativas da populao-alvo. Alm disso, caso
os questionrios forneam resultados surpreendentes, possvel conduzir uma nova
rodada de entrevistas para auxiliar na interpretao desses resultados.

5.5.3 Grupos De Foco


Em um grupo de foco, diversas pessoas (geralmente entre trs e dez) so reunidas por
uma ou duas horas numa espcie de discusso ou entrevista coletiva, guiada por um
moderador experiente. Quando so bem conduzidos, os grupos de foco podem fornecer
uma ampla gama de informaes num curto perodo de tempo.
Grupos de foco permitem coletar informaes sobre um pblico-alvo sobre quem
tenhamos pouca informao. Podem ser realizados para gerar ideias; obter opinies de
pessoas sobre tpicos, conceitos ou demonstraes; obter respostas a uma srie de
questes; identificar conflitos relacionados a terminologias; identificar expectativas de
diferentes grupos de pessoas; e descobrir problemas, desafios, frustraes, atitudes,
preferncias e averses que surgem apenas num contexto social e por isso podem ser
ignoradas por outras tcnicas (Lazar et al., 2010; Sharp et al., 2007; Courage e Baxter,
2005). Os grupos de foco tm como vantagem permitir obter, em pouco tempo, mltiplos
pontos de vista de um grupo de pessoas.
O papel do moderador de um grupo de foco muito importante para assegurar que
pessoas mais quietas ou tmidas participem e evitar que as extrovertidas e agressivas
dominem a discusso.
Courage e Baxter (2005) sugerem evitar pedir para os participantes fazerem previses
sobre algo que eles ainda no experimentaram, como, por exemplo, pedir para avaliar a
utilidade de algo que ainda no utilizaram. Alm disso, devemos evitar enderear tpicos
polmicos, relacionados, por exemplo, com poltica e valores morais. Algumas questes
tpicas exploradas em grupo de foco so (Courage e Baxter, 2005):
um dia tpico de um usurio ou o dia de trabalho mais recente;
as tarefas que os usurios realizam e como eles as realizam;
o domnio em geral (e.g., terminologia, procedimentos normatizados);
preferncias e averses dos usarios;
resultados desejados ou objetivos dos usurios;
reaes, opinies ou atitudes dos usurios sobre um determinado produto ou conceito;
resultados desejados para novos produtos ou funcionalidades.
Alm de perguntas, comum fornecer aos participantes materiais concretos e
prottipos do produto para que eles tenham um foco bem definido sobre o que falar. No
caso de prottipos, podemos tambm pedir para eles realizarem algumas tarefas e
relatarem suas experincias.

5.5.4 Brainstorming De Necessidades E Desejos Dos


Usurios
Essa tcnica fornece informaes sobre os tipos de contedo e caractersticas que os
usurios querem e desejam em um produto (Courage e Baxter, 2005). Essa atividade de
brainstorming funciona para qualquer produto ou servio, e resulta numa lista priorizada
de necessidades e desejos dos usurios. Em geral, essa tcnica utilizada para levantar
requisitos e aprender sobre novas caractersticas que os usurios apreciariam em um
produto, e fornece mais benefcios quando utilizada durante o estgio conceitual do
desenvolvimento do produto. Diferentemente de um grupo de foco, que busca enderear
perguntas especficas, uma sesso de brainstorming busca levantar de forma bastante
livre um conjunto grande e abrangente de opinies dos participantes em torno de um
tema. Os resultados dessa atividade podem alimentar diretamente a especificao
funcional e documentao de design.
Uma sesso de brainstorming pode ser conduzida em aproximadamente uma hora, e
leva menos tempo ainda para analisar os dados de uma sesso, o que torna essa tcnica
leve em termos de recursos, mas poderosa em termos de resultados. Em geral, uma
sesso de brainstorming envolve entre 8 e 12 usurios finais, de preferncia com perfil
semelhante. Caso haja mais do que um perfil, devemos conduzir mais de uma sesso.
Uma sesso eficiente de brainstorming comea com uma pergunta que sumariza o
objetivo de entender o que os usurios querem e precisam no produto. Em vez de pedir
para falarem sobre qualquer coisa que queiram, mais eficiente fazer uma pergunta
visando identificar contedo, tarefas ou caractersticas do produto. Sendo assim, a pergunta
inicial pode ser feita de trs diferentes formas: (1) para identificar as informaes que os
usurios querem ou precisam que o sistema fornea; (2) para identificar os tipos de
atividades ou aes que os usurios esperam realizar com o sistema; e (3) para identificar
caractersticas como, por exemplo, confiabilidade, rapidez, segurana (Courage e Baxter,
2005). A pergunta deve se referir ao sistema ideal, para que os participantes no se
limitem ao que eles acreditam que a tecnologia possa fazer. Alguns exemplos de
pergunta so: Que informaes o sistema ideal deve fornecer?; Que tarefas voc
precisaria ou gostaria de realizar com o sistema ideal?; Que caractersticas o sistema
ideal deve apresentar?. Uma sesso de levantamento de necessidades e desejos dos
usurios tambm pode ser dividida em duas etapas, uma para o levantamento das
informaes e outra para o levantamento das tarefas.
Cada sesso deve ter um moderador, que responsvel por fazer perguntas para
esclarecer o que for dito; manter o foco no objetivo da sesso; manter a atividade em
andamento, mas sem oferecer suas prprias opinies ou influenciar indevidamente as
respostas dos participantes; manter os participantes motivados; no criticar o que eles
disserem; certificar-se de que todos participem, mas que ningum domine a sesso. Alm
do moderador, uma sesso pode envolver um secretrio, um cinegrafista e, caso as
instalaes permitam, outras partes interessadas.
No incio da sesso, os participantes devem ser informados sobre o objetivo e
procedimento da atividade. Courage e Baxter (2005) sugerem uma introduo como a
seguir (p. 382):

Estamos projetando <descrio dos produto> e precisamos entender quais <informaes,


tarefas ou caractersticas> vocs querem e precisam nesse produto. Isso ajudar a nos
certificarmos de que o produto seja projetado para satisfazer seus desejos e necessidades. Esta
sesso ter duas partes. Na primeira, faremos um brainstorming de <informaes, tarefas ou
caractersticas> de um sistema ideal; e na segunda parte da atividade pediremos que vocs
priorizem individualmente os itens que foram levantados.

Eles sugerem definir as seguintes regras para a sesso:


Este um sistema ideal, ento todas as ideias so corretas. Os participantes no devem
censurar a si prprios ou aos outros, mas sim exercitar sua criatividade.
No se trata de uma sesso de design, ento os participantes no devem tentar projetar
ou construir o sistema. Caso os participantes comecem a sugerir solues de design,
eles sero interrompidos e perguntas sero feitas para identificar a motivao por trs
dessas sugestes. A questo inicial tem um papel importante nesse ponto. Em vez de
perguntar Qual o sistema de agenda ideal para o seu dispositivo mvel?, por
exemplo, podemos perguntar Qual o sistema de agenda ideal para quando voc
est fora do escritrio?, a fim de evitar que os participantes se refiram
especificamente aos seus prprios dispositivos.
O moderador pode fazer perguntas sobre sugestes duplicadas. Quando um
participante faz uma sugesto que parece semelhante a uma sugesto anterior,
possvel que ele esteja querendo dizer algo um pouco diferente. Nesse caso, o
moderador deve pedir mais detalhes para descobrir de que maneira as sugestes
diferem.
O secretrio escreve apenas o que o moderador parafrasear. Isso significa que o
moderador precisa entender o que os participantes realmente querem com cada
sugesto, para ento transmitir ao secretrio o que deve ser registrado. O secretrio
ento deve registrar a sugesto, numerando-a para facilitar referncias futuras.
Durante a sesso, caso os participantes desviem dos objetivos, a pergunta inicial e at
mesmo as regras podem ser repetidas. Caso os usurios comecem a sugerir informaes
quando o foco so as tarefas, ou vice-versa, o moderador deve fazer perguntas para que o
participante reformule sua sugesto e assim permita elicitar as tarefas relevantes.
Devemos fornecer papel e lpis a fim de que os participantes possam registrar suas
ideias para que, em momentos de grande atividade, as ideias individuais no se percam
enquanto o moderador estiver tentando entender uma outra ideia fornecida
anteriormente.
Quando os participantes de uma sesso de brainstorming comeam a se calar, pode ser
um sinal de que todas as ideias que tinham j tenham sido registradas e de que est na
hora de passar para a prxima atividade. Segundo Courage e Baxter (2005), isso costuma
acontecer por volta de 40 minutos do incio da atividade.
Na atividade de priorizao dos itens registrados, geralmente solicitamos que cada
participante registre, num formulrio, os cinco itens que considera essenciais para o
produto, indicando, para cada item, seu nmero, sua descrio e por que esse item
importante para ele. Devemos informar aos participantes que todos os cinco itens tm o
mesmo peso, e que, caso um participante tente votar num mesmo item mais de uma
vez, as duplicatas sero descartadas.
Uma alternativa sesso de brainstorming consiste em utilizar diagramas de afinidade
(Beyer e Holtzblatt, 1998). Um diagrama de afinidade construdo da seguinte maneira:
cada pessoa escreve cada item por ela levantado numa pequena folha de papel
autocolante e a afixa num painel ou parede. Em seguida, os participantes examinam as
folhas afixadas por todos, agrupando os itens semelhantes ou fortemente relacionados.
Dependendo do objetivo do diagrama, podemos acrescentar rtulos aos grupos
identificados. Para priorizar os itens, podemos pedir que cada participante marque com
trs asteriscos o item que julgar mais importante, dois asteriscos o segundo mais
importante e um nico asterisco o terceiro item mais importante para ele.
A principal vantagem da utilizao de diagramas de afinidade assegurar a
oportunidade de cada participante em expressar suas ideias, o que pode no ocorrer
numa sesso de brainstorming em que alguns participantes sejam bem mais extrovertidos
ou agressivos do que outros.
Na preparao para a anlise, itens semelhantes devem ser agrupados. Itens repetidos
de um mesmo participante devem ser contabilizados apenas uma vez. Para cada item,
devemos determinar a porcentagem de participantes que o escolheu. Os dados de
mltiplas sesses devem ser analisados em dois momentos: examinando cada sesso
individualmente, e depois combinando os dados de todas as sesses.
Devemos comparar os itens que foram priorizados pelos participantes com os itens
que constem na especificao funcional do produto, caso haja. Em geral, os itens
priorizados pelos participantes devem ser priorizados pela equipe de design do produto.
Caso surjam sugestes inesperadas, podemos voltar ao registro de udio da sesso e
rever a discusso sobre esses itens, para identificar por que os participantes os julgaram
importantes.
importante observar que algumas sugestes podem parecer to bvias aos
participantes que eles no as mencionam. Por exemplo, num sistema de comrcio
eletrnico, possvel que ningum mencione preo do produto como um item de
informao desejado, assumindo que isso seja bvio. Como em qualquer outra tcnica,
importante considerar tambm o conhecimento que a equipe de design j adquiriu sobre
o domnio, os usurios e o resultado de outras atividades de levantamento e anlise ao
interpretar os dados coletados.
O resultado da anlise tambm pode ajudar a reduzir a lista de funcionalidades
especificadas para o produto. Em vez de empregar tempo e recursos para projetar e
desenvolver uma funcionalidade que nunca foi mencionada pelos participantes, devemos
questionar a necessidade dessa funcionalidade ou at mesmo planejar um novo estudo
para esclarecer a discrepncia entre as expectativas da equipe de projeto e as dos
usurios finais.
Em geral, os resultados de uma anlise de desejos e necessidades dos usurios so
sumarizados em uma tabela com: item ou categoria; exemplos do item ou categoria,
obtidos dos exemplos que os prprios participantes forneceram; porcentagem de
participantes que selecionaram o item como um dos cinco itens prioritrios. A tabela
deve ser ordenada por prioridade, da maior para a menor. Alm disso, a lista completa de
ideias deve ser includa num relatrio, para consulta futura sobre funcionalidades
adicionais ou mesmo inspirao.
Finalmente, como toda atividade que envolve pessoas, importante realizar uma
sesso-piloto, para avaliar a questo oferecida, o procedimento, o treinamento e as
habilidades do moderador e do escriba, o tempo estimado para as atividades e todo o
material preparado.

5.5.5 Classificao De Cartes


A tcnica de classificao de cartes (card sorting) utilizada principalmente para
informar ou guiar o projeto da arquitetura de informao de um produto. Por exemplo,
pode ajudar a determinar a estrutura de menus e submenus numa aplicao, de ndices
de navegao em um Web site e de um sistema de ajuda on-line. Pode ajudar tambm a
criar um esquema de classificao para sistemas de gerenciamento de documentos e
identificar categorias potenciais para uma base de conhecimento. Finalmente, pode
ajudar a identificar os passos e subpassos de um processo. Tambm pode fornecer
informaes para decidir como organizar controles numa interface. Spencer (2009) afirma
ainda que, mais do que um mtodo colaborativo para criar estruturas de navegao, a
classificao de cartes uma ferramenta que nos auxilia a entender as pessoas para as
quais estamos projetando um produto.
Essa tcnica pode ser utilizada para levantar diferentes modelos de classificao; para
explorar como as pessoas pensam sobre certos tpicos; para descobrir que categorias
parecem semelhantes ou complementares; para descobrir sobre o que pode ser agrupado
e o que no pode; e para coletar listas de palavras ou expresses que as pessoas utilizam
para descrever grupos de informao (Spencer, 2009).
O mtodo em si relativamente simples. Um conjunto de cartes ou fichas so
preparados com amostras ou descries de contedo e fornecidos a um grupo de pessoas
que devem organiz-los em grupos, de acordo com a similaridade entre os cartes. Note
que o critrio de similaridade definido pelos prprios participantes. No caso da
classificao de cartes aberta, os participantes ento descrevem os grupos de cartes
que eles criaram. J no caso da classificao de cartes fechada, so fornecidos tambm
cartes que representam categorias, e nesse caso os participantes devem classificar os
cartes de contedo nessas categorias predefinidas. Em ambos os casos, os resultados
so registrados, analisados e aplicados no projeto de um produto. A classificao de
cartes nos permite aprender sobre como as pessoas pensam em categorias e conceitos,
como os descrevem e quais informaes pertencem a quais categorias. A Figura 5.1
ilustra os cartes utilizados em uma sesso de card sorting.

FIGURA 5.1 Cartes utilizados em uma sesso de card sorting.

Spencer (2009) enumera os seguintes passos para a conduo de uma classificao de


cartes:
1. decidir o que queremos descobrir;
2. selecionar o mtodo (aberto ou fechado; individual ou em grupo; presencial ou
remoto; manual ou por software);
3. selecionar o contedo;
4. selecionar e convidar os participantes;
5. conduzir a sesso de classificao de cartes e registrar os dados;
6. analisar os resultados;
7. utilizar os resultados no seu projeto.

Definio dos Objetivos


O primeiro passo definir o objetivo do estudo. Spencer (2009) enumera os seguintes
objetivos tpicos:
aprender sobre como as pessoas pensam sobre o contedo e seus principais
agrupamentos e utilizar essa informao para criar categorias de alto nvel e
subcategorias;
aprender se h conceitos de alto nvel nesse contedo e utilizar essa informao para
entender melhor os relacionamentos entre os itens de contedo;
envolver autores de um Web site como forma de mostrar-lhes que as pessoas pensam
de diferentes maneiras, e em particular como elas pensam sobre o seu prprio
contedo;
explorar se h um esquema principal de classificao para o contedo ou se h mais de
um esquema. Utilizar essa informao para definir se as informaes devem ser
oferecidas de mais de uma maneira;
descobrir por que uma pequena seo do Web site no est funcionando ao explorar
diferentes mtodos de categorizao. Utilizar essa informao para decidir se e como
o contedo deve ser reorganizado;
coletar termos e expresses a serem utilizados para rotular grupos e categorias de
contedo.

Seleo do Tipo de Classificao


Para selecionar o tipo de classificao de cartes aberta ou fechada , devemos ter em
mente que a classificao aberta permite aprender mais sobre os esquemas de
classificao dos usurios. Dependendo do nosso objetivo, podemos pedir aos
participantes que considerem alguns critrios particulares, como, por exemplo: principais
grupos de usurios-alvo; principais tarefas que os usurios devem realizar; passos ou
estgios de um processo. Existem casos, no entanto, em que uma classificao fechada
preferencial: quando temos um conjunto de categorias que no pode ser modificado;
quando estamos acrescentando pouco contedo a uma estrutura existente; quando
estamos confiantes de que os grupos atuais so adequados e desejamos explorar detalhes
mais especficos de posicionamento dos itens de contedo (Spencer, 2009).
A classificao de cartes pode ser conduzida com indivduos ou com um grupo de
usurios trabalhando individualmente (Courage e Baxter, 2005; Spencer, 2009). O
principal risco de realizarmos uma classificao de cartes em grupo haver um membro
dominante que force sua opinio sobre as opinies dos outros. Quando isso no
acontece, e os participantes conversam e discutem sobre os diferentes tipos de contedo
e as diferentes formas de classific-lo e utiliz-lo, eles fornecem insumos preciosos para o
estudo, s vezes mais teis do que o resultado final da classificao em si. Spencer
recomenda que, sempre que possvel, essa atividade seja conduzida em grupo.
Seleo de Contedo
Uma das principais causas para o insucesso de uma sesso de classificao de cartes a
seleo de contedo inadequado. O contedo selecionado deve permitir atingir os
objetivos do estudo. No caso de Web sites, o contedo pode ser: tpicos ou assuntos;
pginas de contedo do prprio Web site; produtos de um catlogo; navegao ou
pginas de ndice; pequenas sees do Web site que tenhamos confiana de que deveriam
estar juntas. J no caso de aplicaes, devemos buscar tarefas e funes: itens de menu
da aplicao; funcionalidades-chave da aplicao; passos em um processo; tarefas-chave.
Quando o objetivo principal explorar uma ideia ou tpico, o contedo selecionado pode
ser resultante de brainstorming ou de contedos disponveis no domnio ou em produtos
semelhantes (Spencer, 2009).
Ao selecionarmos o contedo, devemos assegurar que os itens selecionados sejam
representativos e relevantes para os participantes, e que possam ser agrupados, ou seja,
que a amostra no tenha itens completamente diferentes (e.g., informaes ou
funcionalidades, mas no ambos) e no relacionados. Outro cuidado a ser tomado no
incluir itens de contedo que j paream categorias (e.g., Utilidades Domsticas), no
abusar de termos que induzam os participantes a certas classificaes (e.g., diversos
cartes intitulados Manual de possivelmente sero agrupados, mesmo que seu
contedo seja bem diferente) e procurar manter todos os itens num nvel semelhante de
abstrao, para no influenciar indevidamente a sua atividade. Para evitar classificaes
indevidas, no caso de uma classificao fechada, os cartes que representem categorias
devem ser bem diferenciados dos cartes que representam contedos. Para isso,
costumamos utilizar cartes de cores diferentes.

Conduo da Sesso
Como em toda observao de alguma atividade do usurio, importante conduzir um
estudo piloto antes da sesso com os participantes reais. Um estudo-piloto visa avaliar
no apenas as instrues fornecidas aos participantes, mas todo o material gerado.
Devemos avaliar se os textos escritos nos cartes refletem adequadamente o contedo e
se esto claros e corretos ortogrfica e gramaticalmente. No piloto possvel identificar
tambm se possvel formar grupos com a amostra de cartes selecionada.
No incio da sesso, devemos informar aos participantes sobre o objetivo do estudo
(e.g., um Web site, um software) e o contedo que eles vo encontrar nos cartes. Em
seguida, devemos instru-los a agruparem os cartes que recebero, sempre que fizer
sentido que os cartes fiquem juntos no sistema indicado. No caso de uma classificao
fechada, eles devem classificar os cartes nas categorias predefinidas. Perguntas
frequentes devem ser antecipadas: cartes que os participantes no entendam devem ser
separados do restante, e um carto pode ser classificado em mais de uma categoria.
Nesse ltimo caso, o participante deve copiar o contedo do carto para um outro e
colocar cada um nos grupos desejados.
Aps fornecer as instrues, os cartes so espalhados em uma mesa para que os
participantes iniciem a atividade. Caso seja possvel, devemos gravar os comentrios e
discusses que surgem, para registrar as negociaes de significado e a forma de pensar
dos participantes. Alm disso, no caso de uma sesso em grupo, devemos cuidar para
que um participante no domine a atividade. Ao trmino da atividade, caso se trate de
uma classificao aberta, devemos solicitar aos participantes que deem nomes aos
grupos. Finalmente, podemos pedir a opinio dos participantes sobre os grupos
formados, para avaliar o quanto esto satisfeitos e confiantes com o resultado. Podemos
pedir tambm que descrevam os critrios utilizados na classificao e que indiquem os
melhores exemplos de cada grupo.

Anlise dos Resultados


A anlise dos cartes consiste em verificar quais grupos foram formados, qual esquema
de classificao as pessoas utilizaram, quais itens de contedo foram classificados em
cada grupo e quais termos e expresses foram utilizados para descrever os grupos (no
caso de classificao aberta). Essa anlise pode ser feita utilizando uma planilha ou
software especfico para classificao de cartes. Em seguida, costumamos fazer uma
anlise estatstica dos dados, utilizando os algoritmos de agrupamento ou aglomerao
(clustering) de k-mdias (k-means cluster analysis) ou hierrquico (hierarchical cluster
analysis), ou ainda de escalonamento multidimensional (multidimensional scaling, MDS).
Informaes podem ser organizadas utilizando diferentes esquemas, como, por
exemplo: tpico; cronologia; geografia; ordem alfabtica; ordem numrica; tarefa;
pblico-alvo (Spencer, 2009). Ao fornecer indcios sobre como as pessoas organizam um
certo conjunto de informaes, a tcnica de classificao de cartes pode levar a equipe
de design a questionar suas suposies e preconceitos. Pode fornecer uma nova
perspectiva sobre as informaes e seus esquemas organizacionais. Segundo Courage e
Baxter (2005), essa tcnica nos diz como as caractersticas de um produto podem ser
estruturadas para se encaixarem nas expectativas dos usurios sobre de que maneira
essas caractersticas esto relacionadas.
Spencer (2009) alerta que o resultado da classificao de cartes no deve definir
cegamente a arquitetura de informao de um produto. Em outras palavras, ele no
fornece uma resposta direta sobre como organizar as informaes, mas sim ideias para a
elaborao da arquitetura de informao. Segundo ela, o real valor da classificao de
cartes aprender sobre o seu usurio coisas que no saberamos de outro jeito. Por
exemplo, se planejamos organizar um Web site de receitas por mtodo de cozimento e os
usurios pensam em termos de ingredientes, precisamos saber disso. Cabe ao projetista,
no entanto, combinar o que aprendeu sobre a pesquisa com usurios, os objetivos do
produto e a anlise de contedo, sintetizando os dados coletados numa arquitetura de
informao adequada.
Alm disso, os resultados de uma classificao de cartes no indicam se os usurios
sero capazes de encontrar informaes com o esquema de categorias resultante, pois a
atividade envolve partir de um contedo e associ-lo a uma categoria, e no o contrrio
(i.e., encontrar um contedo a partir de um conjunto de categorias).
5.5.6 Estudos De Campo
A expresso estudo de campo inclui uma categoria ampla de atividades relacionadas
com usabilidade que podem incluir investigao contextual, entrevistas no ambiente do
usurio e observaes simples. Durante um estudo de campo, um pesquisador visita
usurios finais no seu prprio ambiente (e.g., lar ou local de trabalho) e os observa
enquanto desempenham uma atividade. Estudos de campo podem durar desde algumas
poucas horas at diversos dias, dependendo dos objetivos do estudo e dos recursos
disponveis.
O principal objetivo de um estudo de campo entender o comportamento natural do
usurio final no contexto do seu prprio ambiente de atuao (Courage e Baxter, 2005).
Ao observarmos os usurios em seu prprio ambiente, podemos capturar informaes
que afetam o uso de um produto incluindo interrupes, distraes e outras
demandas de tarefa e contexto adicional que no podem ser capturados ou replicados
num ambiente de laboratrio. Coletamos dados ricos e detalhados, que nos permitem
obter uma viso holstica do processo ou do domnio. Trata-se de uma investigao da
realidade dos usurios, e no de suposies. O resultado tornar explcitos os aspectos e
processos implcitos do ambiente do usurio.
Estudos de campo podem ser utilizados em qualquer momento durante o ciclo de vida
de desenvolvimento de um produto, mas geralmente so mais proveitosos durante as
atividades iniciais de levantamento. Os estudos de campo permitem alcanar diferentes
objetivos (Courage e Baxter, 2005):
identificar novas funcionalidades e produtos;
desafiar ou verificar suposies que as partes interessadas tenham sobre os usurios,
suas tarefas e seu ambiente;
identificar uma falta de correspondncia entre a forma como o usurio trabalha e
pensa e a forma como as ferramentas e os procedimentos lhes obrigam a trabalhar;
entender os objetivos dos usurios;
identificar os materiais de treinamento necessrios;
criar designs iniciais;
desenvolver um inventrio das tarefas;
definir uma hierarquia de tarefas;
coletar artefatos (i.e., objetos ou itens que os usurios utilizam para completar suas
tarefas, ou que resultam de suas tarefas);
verificar se os usurios correspondem aos perfis de usurios traados inicialmente;
elaborar personas a partir de observaes de usurios reais;
coletar informaes necessrias para outras atividades voltadas qualidade de uso
(e.g., elaborar um questionrio, identificar tarefas para um teste de usabilidade).
Courage e Baxter (2005) alertam para a possibilidade de um investigador sem
familiaridade com o domnio fazer anotaes demasiadamente simplificadas. Para evitar
isso, sugerem que as anotaes sejam revisadas por um especialista no domnio. Os
prprios participantes do estudo podem tentar traduzir o seu trabalho de forma
simplificada demais, com objetivo de ajudar o investigador. Para evitar isso, o
investigador pode solicitar aos participantes que o considerem um aprendiz e lhe
ensinem sobre o trabalho tal como deve ser realizado, sem omitir etapas.
Mesmo no ambiente de atuao do participante, possvel que ele se comporte de
forma diferente apenas porque sabe que est sendo observado (Draper, 2009). Sendo
assim, pode ser necessrio fazer o estudo durante um tempo prolongado, para que as
pessoas se acostumem com a presena do observador e voltem a se comportar
normalmente.
Existem diversas formas de estudo de campo. A forma mais simples a observao
pura, sem interao do observador com os participantes. Uma variao a observao
guiada por um conjunto de tpicos de interesse. Outras formas envolvem entrevistas
estruturadas ou semiestruturadas, possivelmente com o registro de fotos, udio e vdeo
do ambiente de atuao dos participantes, e com a coleta ou cpia dos artefatos
utilizados por eles. Existe ainda a possibilidade de registrar as informaes sem a
presena do observador. Esse o caso de dirios, mantidos pelos prprios participantes, e
de registros de vdeo por cmeras instaladas no ambiente dos participantes (Courage e
Baxter, 2005).
Uma das formas mais comuns de estudo de campo a investigao contextual,
apresentada na prxima seo. Trata-se de um estudo de campo com o envolvimento
intenso do investigador como um participante aprendiz, incluindo entrevistas e
observao.

5.5.7 Investigao Contextual


Como visto na Seo 4.3.4, Beyer e Holtzblatt (1998) elaboraram o ciclo de vida de design
contextual, uma abordagem centrada no cliente na qual a atividade de investigao
contextual exerce um papel central.
O objetivo da investigao contextual revelar todos os aspectos da prtica do
trabalho. A investigao contextual parte da hiptese de que, quando boa parte do
trabalho no pode ser articulada adequadamente por aqueles que o praticam,
necessrio que vejamos o trabalho. Para isso, a investigao contextual advoga ir aonde o
usurio trabalha, observar o usurio enquanto ele trabalha e conversar com ele sobre o
seu trabalho. Mais especificamente, os principais objetivos da investigao contextual
so:
obter dados sobre a estrutura do trabalho na prtica, em vez de uma caracterizao de
marketing abstrata ou dissociada da prtica real;
tornar explcito o conhecimento tcito e no articulado sobre o trabalho, para que os
designers, que no o realizam, possam entend-lo;
conhecer os detalhes do trabalho que se tornaram habituais e invisveis.
Reconhecendo que muitas vezes difcil para uma pessoa articular o seu trabalho de
forma a comunicar suas prticas para uma equipe de design, a investigao contextual
adota um modelo de mestreaprendiz. Nesse modelo, o entrevistador, membro da
equipe de design, exerce o papel de aprendiz do trabalho do usurio. O usurio, no papel
de mestre, ensina o seu trabalho exercendo-o e falando sobre ele com o aprendiz,
enquanto o trabalho realizado. Isso torna o compartilhamento de conhecimento uma
tarefa mais simples e natural. Os usurios nem sempre tm conscincia de tudo o que
fazem ou por que o fazem; eles se tornam conscientes disso ao faz-lo.
O modelo mestreaprendiz eficiente para coletar, do prprio usurio, os dados que a
equipe de design precisa conhecer sobre o trabalho desse usurio. Esse modelo facilita:
tornar os usurios cientes do que fazem, ao faz-lo;
interromper o trabalho para pensar sobre ele;
revelar todos os detalhes de uma prtica de trabalho;
apontar e explicar as diferenas entre o essencial e o irrelevante;
revelar padres ou princpios atuantes, que influenciam ou determinam a forma como
trabalham.
A investigao contextual se baseia nos seguintes princpios: contexto, parceria,
interpretao e foco.
O investigador deve ir ao local de trabalho dos seus usurios e observ-los realizando
seu trabalho, em contexto. Estar presente enquanto o trabalho ocorre torna detalhes
visveis e os dados coletados concretos, permitindo conhecer a experincia em
andamento, em vez de um sumrio sobre uma experincia passada ou idealizada,
envolvendo dados abstratos.
A parceria com os usurios firmada atravs de conversas sobre o trabalho deles, com
o objetivo de nos tornarmos seu colaborador no entendimento da prtica de trabalho.
Durante o trabalho, o usurio est engajado na sua atividade e o entrevistador observa os
detalhes que se desdobram, buscando identificar padres e estruturas, e pensando sobre
as razes subjacentes s aes do usurio. Quando uma estrutura identificada ou
quando algo parece no se encaixar, o entrevistador interrompe o trabalho para conversar
com o usurio sobre o que observou, ou sobre uma ideia de design que possa ter tido.
importante observar que, para que um processo seja verdadeiramente centrado no
cliente, os usurios devem poder modificar o entendimento inicial do trabalho que os
designers possam ter formado. Para isso, devemos evitar os modelos de entrevistador
entrevistado, o do designer como especialista e o do designer como visitante, e adotar o
modelo de mestreaprendiz.
A interpretao consiste em desenvolver um entendimento compartilhado com o
usurio sobre os aspectos relevantes do trabalho. A partir de um fato, de um evento
observvel, o designer levanta uma hiptese, uma interpretao inicial do que o fato
significa ou do que est por trs dele, atribuindo significado a suas observaes. Essa
hiptese tem implicaes para o design, que podem ser concretizadas numa ideia de
design para o sistema. necessrio compartilhar essa interpretao com o usurio para
nos certificarmos de que ela est correta, ou seja, que o trabalho foi entendido
corretamente. Quando um evento contradiz nossas suposies, devemos investig-lo
para corrigirmos o entendimento falho por um melhor. E mesmo quando o usurio j
sugere diretamente uma ideia de design, importante seguirmos a cadeia inversa para
entendermos o contexto do trabalho que gerou aquele desejo.
O princpio de foco afirma que a investigao deve ser guiada por um entendimento
claro do seu objetivo, para atribuir significado ao trabalho. Devemos ter em mente
perguntas sobre aspectos do trabalho (e.g., o que o trabalho que deve ser apoiado?
Como esse trabalho se encaixa nas atividades do usurio? Quais so as principais
tarefas?), sobre as pessoas com quem devemos conversar (e.g., quem est envolvido
nessa atividade? Quem so os ajudantes informais? Quem fornece a informao
necessria para realizar o trabalho? Quem utiliza o resultado do trabalho?) e sobre o
contexto do trabalho (e.g., onde [fisicamente] ocorre o trabalho? Qual o contexto
cultural e social em que ele ocorre?). Devemos buscar metforas para o trabalho tipos
de trabalho que tenham estrutura semelhante quele que queremos apoiar. Podemos
utilizar metforas para estruturar nosso pensamento e conduzir entrevistas explorando-
as, se isso ajudar no nosso entendimento.
Uma investigao contextual geralmente envolve, para cada papel, 6 a 10 entrevistas de
trs horas com pessoas que trabalham de forma bem diferente (Beyer e Holtzblatt, 1998),
e segue a seguinte estrutura: uma entrevista convencional curta (de aproximadamente 15
minutos), uma transio para a entrevista contextual propriamente dita, e uma
concluso.
Durante a entrevista convencional, um membro da equipe de design, assumindo o
papel de entrevistador, se encontra com o usurio no local de trabalho dele, se apresenta
e descreve o foco da entrevista. Explica que o usurio e seu trabalho so primordiais e
que ele depende do usurio para aprender sobre o trabalho e corrigir seus mal-
entendidos. O entrevistador pede opinio sobre as ferramentas que o usurio utiliza e
obtm uma viso geral do trabalho como um todo e do que precisa ser feito naquele dia.
Esses dados so sumarizados, e no contextuais, ento nenhuma questo deve ser
aprofundada neste momento.
Logo aps a entrevista inicial, feita uma rpida transio, na qual o entrevistador
informa que a partir daquele momento o usurio deve realizar o seu trabalho enquanto o
entrevistador o observa, que o entrevistador vai interromp-lo quando vir algo
interessante e que o usurio pode avisar quando no for um bom momento para ser
interrompido.
Durante a entrevista contextual propriamente dita, o usurio comea a fazer o seu
trabalho, enquanto o entrevistador observa e interpreta. O entrevistador deve analisar os
artefatos utilizados e elicitar relatos em retrospectiva. Ele deve tentar manter o usurio
falando concretamente sobre seu trabalho (vs. em geral) e fazer anotaes o tempo
todo, para no depender exclusivamente da gravao, que pode falhar ou deixar de
capturar informaes importantes, como o momento de um gesto ou o uso de um
artefato que no foi comentado verbalmente, como, por exemplo, uma rpida consulta
visual a uma anotao afixada no monitor do usurio. A conversa entre os entrevistadores
e os usurios deve focar principalmente o trabalho, e no aspectos de design do sistema.
Segundo Beyer e Holtzblatt (1998), o entrevistador deve ser curioso e pode ser at um
pouco intrometido.
Durante a observao do trabalho, comum ocorrerem situaes que lembrem o
usurio de eventos passados relevantes para o entendimento do trabalho. Tambm
durante o trabalho, o usurio recorre a artefatos (formulrios, anotaes, manuais etc.)
que disparam conversas sobre como so utilizados, como foram criados e como sua
estrutura apoiou seu uso numa situao particular. O entrevistador observa o usurio
realizando o trabalho em que a equipe est interessada e, sempre que julgar necessrio,
interrompe e discute com o usurio sobre algum aspecto relevante observado. Caso o
usurio pegue um papel, formulrio ou anotao, eles analisam juntos o artefato em
detalhes. Utilizando esses artefatos para apoiar a conversa, o entrevistador descobre
eventos que ocorreram h mais tempo.
Na concluso da entrevista contextual, o entrevistador repassa rapidamente suas
anotaes e sumariza o que aprendeu, tentando no repetir literalmente o que aconteceu,
mas dizendo o que ele identificou que importante sobre o trabalho, para o usurio e
para a organizao. Isso permite que o usurio corrija e refine o entendimento do
entrevistador, e deve ser encorajado a faz-lo. Aps a entrevista, toda a equipe de design
trabalha com o entrevistador para interpretar os resultados da entrevista perante o
problema de design.
Entrevistadores que observem mltiplos eventos e mltiplos usurios aprendem a ver
as estratgias comuns que os usurios adotam ao trabalhar. Uma vez que as estratgias
bsicas so compreendidas, os designers podem comear a imaginar um sistema que
apoie essas estratgias.
Caso o processo a ser observado seja extremamente longo, podemos tentar entrevistar
um conjunto mais amplo de usurios, que assumam diferentes papis em diversos
pontos do processo. Podemos solicitar tambm que eles forneam um relato
aprofundado, em retrospectiva, de situaes exemplares ou excepcionais.
Atividades
1. Definio dos dados a serem coletados. Imagine que voc foi contratado para elaborar um
sistema acadmico de apoio a professores e alunos na Web. Para o professor, o
sistema deve apoiar objetivos relacionados ao planejamento de aulas, divulgao de
material didtico e agendamento de trabalhos, provas e outras atividades, bem como
o clculo e a divulgao de notas. J para o aluno, o sistema deve facilitar a
organizao do material e das atividades que precisa realizar em cada disciplina, a
comunicao com o professor e com os colegas. Enumere os dados que deseja coletar,
indicando por que cada dado relevante para o projeto do sistema.
2. Definio de quem fornecer as informaes. Para o sistema acadmico da atividade
anterior, defina o perfil dos fornecedores de informao e outras possveis fontes de
informao, tais como manuais e normas. Relacione os dados que quer coletar
(definidos na atividade anterior) com cada fonte. Para variar a amostra de pessoas a
serem consultadas, pense em diferentes dimenses, tais como:
tempo de experincia naquele papel (e.g., professor antigo/recente; aluno
calouro/veterano);
rea de atuao (e.g., tecnolgica/humanas);
atitude com relao a tecnologias computacionais (e.g., antenado/resistente a
tecnologias);
experincia com tecnologias computacionais (usa tecnologia simples/avanada;
usa h vrios anos/no usa ainda; uso frequente/ocasional).
3. Elaborao de roteiro de entrevista. Considerando o sistema acadmico descrito
anteriormente, elabore um roteiro de entrevista para o professor e outro para o aluno.
Para isso, responda s seguintes perguntas:
Quais os objetivos da entrevista?
Quem sero os entrevistados?
Que tpicos sero explorados na entrevista, e em que profundidade?
Quais tpicos seriam mais adequados para um questionrio?
O quanto as perguntas elaboradas permitem obter os dados que voc quer coletar?
H perguntas compostas ou complexas, que precisam ser simplificadas ou
segmentadas em mltiplas perguntas?
H perguntas que dificultam o aprofundamento das respostas (por exemplo,
perguntas que pedem respostas do tipo sim/no)?
Que cuidados foram tomados na elaborao das perguntas para que elas no
induzam certas respostas?
Como aumentar a chance para que entrevistados reticentes falem mais sobre cada
tpico?
4. Elaborao de questionrio. Considerando o sistema acadmico descrito anteriormente,
elabore um questionrio para o professor e outro para o aluno. Alm das perguntas
enumeradas no item anterior, responda tambm:
Quais tpicos seriam mais adequados para uma entrevista?
Para cada pergunta fechada, de onde extraio as possveis respostas? Todo
respondente conseguir encaixar sua resposta numa das opes fornecidas?
H perguntas excessivamente fechadas?
H um nmero muito grande de perguntas abertas?
H ambiguidades na enunciao das perguntas?
O questionrio apresenta claramente o seu objetivo e as instrues para
preenchimento (e devoluo, no caso de questionrio impresso)?
Quanto tempo voc estima que o respondente leve para completar o questionrio?
Esse tempo adequado?
5. Brainstorming. Conduza duas pesquisas utilizando a tcnica de brainstorming: uma
para levantar os objetivos dos usurios e outra para levantar os itens de informao
relacionados a esses objetivos.
6. Classificao de cartes. Considerando o resultado de uma pesquisa de levantamento de
objetivos dos usurios e dos itens de informaes relacionados a esses objetivos
(como sugerido na atividade anterior), crie um conjunto de cartes que permitam
avaliar como os usurios organizariam esses itens de informao relacionados aos
objetivos que querem atingir com o sistema.
1
importante observar que algumas empresas de software probem, na sua licena, a conduo de anlise competitiva
com o seu produto. Examine a licena de qualquer produto para se certificar de que ela no ser violada por esse tipo de
anlise.
2
LimeSurvey (www.limesurvey.org) e o SurveyMonkey (www.surveymonkey.com) so exemplos desse tipo de servio.
6

Organizao do Espao de Problema


Objetivos do Captulo
Apresentar representaes utilizadas para organizar o espao de problema: personas e
seus objetivos, cenrios de problema e modelos de tarefas.
Discutir como essas representaes permitem registrar as informaes elicitadas
durante o levantamento e a anlise de objetivos e necessidades dos usurios.
Uma parte importante de qualquer mtodo de anlise ou design so os modelos e as
representaes utilizados para registrar o que foi aprendido ou definido. Eles definem
um recorte no mundo de interesse, sob uma determinada perspectiva, com um
determinado foco e em um determinado nvel de detalhes (Hoover et al., 2001). Como
produto da etapa de anlise, este captulo apresenta diversas representaes e modelos
utilizados para registrar, organizar, refinar e analisar os dados coletados: perfil de
usurio (Courage e Baxter, 2005; Hackos e Redish, 1998), personas e seus objetivos
(Cooper et al., 2007; Pruitt e Adlin, 2006; Cooper, 1999), cenrios de anlise ou de
problema (Carroll, 1995; Carroll, 2000; Rosson e Carroll, 2002) e modelos de tarefas, que
visam organizar e estruturar como os objetivos dos usurios podem ser alcanados
(Diaper e Stanton, 2003; Card et al., 1983; Patern, 2000).
Na engenharia semitica, a atividade de anlise pode ser vista como meio de completar
a primeira parte da metamensagem do designer para o usurio (de Souza, 2005a, p.25;
Seo 3.8):

Este o meu entendimento, como designer, de quem voc, usurio, , do que aprendi
que voc quer ou precisa fazer, de que maneiras prefere fazer, e por qu. Este, portanto,
o sistema que projetei para voc, e esta a forma como voc pode ou deve utiliz-lo para
alcanar uma gama de objetivos que se encaixam nesta viso.

Vemos a seguir diversas representaes que podem auxiliar a registrar esse


conhecimento adquirido dos usurios.
6.1 Perfil de Usurio
O primeiro passo para registrarmos nosso entendimento sobre os usurios traarmos
um perfil deles. Quem so? Quais so seus objetivos? Alm de nos ajudar a entender
para quem estamos construindo o produto, o perfil de usurios tambm auxilia no
recrutamento de participantes para futuras atividades de anlise e avaliao (Courage e
Baxter, 2005; Hackos e Redish, 1998).
Perfil de usurio uma descrio detalhada das caractersticas dos usurios cujos
objetivos devem ser apoiados pelo sistema sendo projetado. Como visto na Seo 5.2,
devemos identificar as caractersticas de interesse (e.g., cargo, funo, experincia, nvel
de instruo, atividades principais, faixa etria etc.) e conduzir um estudo (e.g., atravs
de entrevistas e questionrios) para coletar os dados dos usurios. A partir dos dados
coletados, podemos agregar os valores em grupos e faixas na qual os usurios se
encaixam (e.g., idade 18-25), e assim traar os perfis de usurios com caractersticas
semelhantes e calcular a proporo de usurios que se encaixam em cada perfil. A
elaborao de um perfil de usurio um processo iterativo. Em geral, um designer
comea seu trabalho com uma ideia inicial de quem so seus usurios, mas essa ideia no
costuma ser suficientemente detalhada e pode at ser apenas uma impresso equivocada.
As caractersticas de um perfil de usurio podem ser priorizadas conforme o produto e
projeto em questo. Nesse caso, a maior parte dos recursos para capturar informaes
deve ser destinada a essas caractersticas-chave do seu produto. Em geral, um perfil de
usurio caracterizado por dados sobre o prprio usurio, dados sobre sua relao com
tecnologia, sobre seu conhecimento do domnio do produto e das tarefas que dever
realizar utilizando o produto (Hackos e Redish, 1998; Courage e Baxter, 2005). Esses tipos
de dados foram enumerados na Seo 5.2.
Uma vez que a faixa de respostas para cada uma das caractersticas e a porcentagem de
usurios nessa faixa tiverem sido determinadas, podemos categorizar seus usurios em
grupos, com base em suas semelhanas. Alguns grupos comuns so definidos por: idade
(criana, jovem, adulto, terceira idade etc.); experincia (leigo/novato, especialista); atitudes
(tecnfilos, tecnfobos); e tarefas primrias (compra, venda). O Exemplo 6.1 apresenta um
quadro representando dois perfis de professores universitrios.

Exemplo 6.1
Q uadro para anlise de perl de
coordenadores de curso
Nesse exemplo, observamos que nem todos os professores se encaixam nesses dois perfis. Alguns
(10% do total) no se encaixam em nenhum grupo que possa ser considerado homogneo.

Os perfis de usurios facilitam a criao de personas, descritas na prxima seo.


6.2 Personas
Uma persona um personagem fictcio, arqutipo hipottico de um grupo de usurios
reais, criada para descrever um usurio tpico (Cooper et al., 2007; Pruitt e Adlin, 2006;
Cooper, 1999). utilizada principalmente para representar um grupo de usurios finais
durante discusses de design, mantendo todos focados no mesmo alvo. As personas so
definidas principalmente por seus objetivos, que so determinados num processo de
refinamentos sucessivos durante a investigao inicial do domnio de atividade do
usurio. Em geral, comeamos com uma aproximao razovel e convergimos numa
populao plausvel de personas.
Cooper afirma que, em vez de ampliarmos a funcionalidade do produto para acomodar
a maior parte das pessoas, devemos tentar projetar especificamente para uma nica
persona. Ele argumenta que, a cada vez que estendemos a funcionalidade para incluir
mais um grupo de usurios, colocamos mais um obstculo no caminho de todos os
outros usurios. Em outras palavras, os recursos que agradam alguns usurios interferem
na satisfao e no desempenho de outros. Segundo ele, tentar agradar muitos pontos de
vista diferentes pode arruinar um bom produto.
Segundo ele, o prprio termo usurio problemtico, pois sua impreciso o torna
pouco til. Ele acredita que esse termo genrico denota um usurio elstico, que
precisa se contorcer para se adaptar s necessidades do momento. Por exemplo, alguns
sistemas tratam o usurio ora como um usurio iniciante, forando-o a passar por
diversos assistentes para realizar sua tarefa, ora como um especialista, que precisa
entender e configurar mltiplos parmetros obscuros e interdependentes, muitas vezes
conforme a convenincia dos programadores. No entanto, o objetivo principal projetar
sistemas que se adaptem s necessidades do usurio. E usurios reais no so elsticos.
Sendo assim, os designers nunca devem ser vagos e dizerem que o seu programa
projetado para o usurio ou que ser amigvel. Em vez disso, Cooper advoga falar de
um usurio bem especfico: uma persona.
Para definir uma persona, Courage e Baxter (2005) enumeram os seguintes elementos
caractersticos:
identidade: d a uma persona nome e sobrenome. Fornea uma idade e outros dados
demogrficos que seriam representativos do perfil do usurio. Inclua tambm uma
foto, para tornar a persona ainda mais realista e memorvel;
status: defina se esta persona primria, secundria, outro stakeholder ou representa
um antiusurio do seu sistema. Um antiusurio algum que no vai utilizar o
produto e, portanto, no deve influenciar as decises de projeto;
objetivos: quais so os objetivos desta persona? No se limite a objetivos relacionados
ao seu produto especfico;
habilidades: qual a especialidade da sua persona? Isso inclui educao, treinamento e
competncias especficas. Novamente, no se limite a detalhes relacionados ao seu
produto especfico;
tarefas: em linhas gerais, quais as tarefas bsicas ou crticas que a persona realiza? Qual
a frequncia, importncia e durao dessas tarefas? Deixe as informaes mais
detalhadas sobre como as tarefas so realizadas para os cenrios (veja a Seo 6.3);
relacionamentos: entender com quem a persona se relaciona importante, pois ajuda a
identificar outros stakeholders;
requisitos: de que a persona precisa? Inclua citaes que ajudam a dar mais vida a essas
necessidades;
expectativas: como a persona acredita que o produto funciona? Como ela organiza as
informaes no seu domnio ou trabalho?
Embora personas sejam fictcias (i.e., no correspondem a uma pessoa real), elas so
definidas com rigor e detalhes para representar usurios tpicos. Elas so derivadas de
um processo de investigao que levanta as caractersticas dos usurios e descreve seus
perfis. Apenas seus nomes e detalhes pessoais so inventados. Quanto mais especficas
forem as personas, mais eficientes elas sero como ferramentas de design e comunicao.
O Exemplo 6.2 ilustra duas personas de um sistema de apoio acadmico.

Exemplo 6.2
P ersonas de um sistema de apoio acadmico
Paulo Correa, tcnico de suporte comandos para mxima eficincia
Paulo Correa, de 43 anos, trabalhou durante muitos anos consertando e
configurando computadores. Atualmente, trabalha na universidade
AprendaMais, configurando PCs e as contas dos alunos de cada turma. Ele
fez um curso de administrao de rede, mas prefere aprender fazendo do
que assitindo a cursos ou lendo manuais. Quando tem alguma dvida, ele
faz uma busca na Internet por informaes que lhe ajudem a resolver os
seus problemas. Usurio das antigas, Paulo prefere utilizar linguagem de
comando do que assistentes em interface grfica, pois acredita que assim
seja mais eficiente. Sempre que uma tarefa se repete com frequncia, ele
tenta elaborar um script ou fazer alguma configurao que acelere o seu
trabalho.

Todo incio de perodo, Paulo precisa configurar dezenas de contas para


cada turma, com diferentes perfis, fornecendo acesso diferenciado para
alunos regulares, monitores, instrutores e coordenadores de cada
disciplina. Precisa atender aos pedidos dos professores sobre o que deve
estar disponvel na intranet de cada disciplina (e.g., publicao de material
didtico; frum de discusso; recebimento de trabalhos dos alunos;
cadastramento de notas; pedidos de reviso). Seu maior objetivo atender
aos professores com a maior eficincia possvel. Para isso, importante ele
poder acessar o sistema onde quer que esteja, no horrio que for, para
realizar qualquer tarefa remotamente.
Lcio Marques, professor mais prtico usar apenas o bsico
Lcio Marques professor da universidade AprendaMais h cinco anos e
j lecionou diversas disciplinas diferentes. Ele tenta sempre aproveitar ao
mximo o que j tiver utilizado em outros perodos, mas sempre busca
atualizar seu material com conceitos extras e novos exemplos reais, que ele
l em blogs de profissionais da rea.

Lcio gostaria de poder, ele prprio, configurar o sistema, mas como sua
preocupao principal lecionar uma boa aula, no tem tempo para
decifrar as dezenas de funcionalidades ocultas nos diversos menus do
sistema. Ele costuma sempre solicitar ao suporte a configurao bsica
inicial com mdulos apenas para divulgao de material e frum de
discusso. Dependendo do perfil da turma, ele pede para o suporte
acrescentar mais funcionalidades ao longo do curso, mas isso raramente
ocorre.

Segundo Cooper (1999), um problema com os representantes de usurios reais que


um usurio real pode ter idiossincrasias que interferem com o processo de design e
reduzem sua capacidade de representar o grupo de usurios almejado. Alm disso, os
usurios no podem estar presentes em todas as etapas do projeto. Por outro lado, falar
genericamente de o usurio, que no definido com preciso, dificulta o
estabelecimento de uma viso de design compartilhada. Quando cada designer possui
sua prpria viso de quem o usurio, o usurio se torna um alvo mvel pode
mudar de especialista para novato e dali para a tia do desenvolvedor, numa nica
discusso.
Uma persona assume uma solidez tangvel que coloca os pressupostos de design em
perspectiva. medida que uma persona perde sua elasticidade, podemos identificar suas
habilidades, suas motivaes e o que ela quer alcanar. Munidos desse conhecimento,
podemos ento examin-la luz do domnio do software para ver se ela realmente um
arqutipo de usurio. Dar um nome persona uma parte importante da sua elaborao,
para que ela se torne um indivduo concreto na mente dos designers.
Cooper (1999) considera as personas como a ferramenta de design mais poderosa
utilizada por ele e sua equipe. So a base para todo o design orientado a objetivos
apresentado na Seo 4.3.6. Elas tornam claros os objetivos dos usurios, para que
possamos ver o que o produto deve fazer ou pode deixar de fazer. As personas ajudam
a equipe de design a justificar suas decises de design para os desenvolvedores e
gerentes. Projetar para um conjunto pequeno de personas aumenta as chances de a
equipe de design acertar o alvo. Uma persona pode ser utilizada em reunies como uma
ferramenta de discusso (e.g., Lucia nunca utilizaria essa funcionalidade), em
avaliaes por inspeo (Seo 9.6), storyboarding, encenaes (role-playing) e outras
atividades voltadas qualidade de uso do sistema. Finalmente, personas tambm podem
ajudar novos membros da equipe a aprender rapidamente sobre quem so os usurios.
essencial que todos na equipe de design no apenas conheam o elenco de personas,
mas que cada persona se torne como uma pessoa real, como membro da equipe. Cada
designer deve insistir em expressar todas as questes de design em termos de personas,
atravs de seus nomes. Todos devem evitar falar em o usurio. medida que
comeamos a desenvolver ideias para solues de design, constantemente as avaliamos
perante as personas. Quando conseguimos nos colocar no lugar de uma persona e
examinar um produto ou uma tarefa, conseguimos apreciar melhor se o design foi ou no
bem-sucedido em fazer essa persona feliz (Cooper, 1999).
Segundo Courage e Baxter (2005), devemos criar pelo menos uma persona por papel de
usurio (e.g., ao menos uma para o professor e outra para o aluno, num ambiente
acadmico). Cada projeto possui seu prprio elenco de personas, que consiste de trs a
12 personas distintas. No concebemos o design para todas elas, mas todas so teis em
articular parte da populao de usurios. Algumas so definidas apenas para tornar claro
que no estamos projetando para elas; so as antipersonas.
Cada elenco de personas possui ao menos uma persona primria. Trata-se do indivduo
que o foco principal do design. Para ser primria uma persona algum que tem de ser
satisfeita, mas que no pode ser satisfeita por uma interface projetada para uma outra
persona qualquer. Em geral, cada persona primria requer uma interface distinta e nica
(Cooper, 1999).
Courage e Baxter (2005) apontam um cuidado na escolha do nmero de personas
elaboradas. importante que as personas sejam memorveis e, para isso, o elenco de
personas deve ser reduzido. Se houver muitas personas para representar os grupos de
usurios, elas vo se misturar na mente dos designers e desenvolvedores, e com isso
reduzimos os benefcios dessa tcnica. No entanto, o elenco deve cobrir os principais
grupos de usurios, para ajudar a desenvolver um produto que funciona para todos. Ao
nos limitarmos a uma nica persona, podemos deixar de fora dados valiosos de usurios
finais que no correspondam a um mesmo grupo. Uma recomendao comum que o
elenco de personas inclua trs personas primrias.
Objetivos Das Personas
Um bom design de interao s tem sentido no contexto de uma pessoa utilizando o
sistema com algum objetivo. E no h objetivos sem pessoas. por isso que os
elementos-chave do processo de design dirigido por objetivos so: objetivos e pessoas,
representadas pelas personas.
Objetivos no so a mesma coisa que tarefas. Como visto na Seo 4.3.6, um objetivo
uma condio final, ao passo que uma tarefa um processo intermedirio necessrio
para atingir o objetivo. Existe uma maneira simples de fazer a distino entre tarefas e
objetivos. As tarefas mudam com a tecnologia, mas os objetivos so bem mais estveis.
Para descobrir os objetivos, Cooper (1999) sugere realizar sesses de brainstorming
considerando um computador mgico (Seo 5.5.4), que no possui qualquer restrio.
Ele acredita que esse exerccio ajuda a fazer a distino entre objetivos e tarefas.
Muitos desenvolvedores se aproximam do design perguntando Quais so as tarefas?.
Embora isso possa ajudar a resolver um problema, em geral no ajuda a produzir uma
soluo brilhante e pode at mesmo no satisfazer o usurio. Projetar a partir de tarefas
em vez de objetivos uma das principais causas de interao ineficiente e frustrante.
Perguntar Quais so os objetivos de Marta (uma persona)? nos permite desfazer a
confuso e criar um design mais adequado e satisfatrio. Quando designers analisam
objetivos para resolverem problemas, eles geralmente encontram solues bem
diferentes, e muitas vezes melhores e mais criativas (Cooper, 1999).
Em 1999, Cooper descreveu trs tipos de objetivos: objetivos pessoais, corporativos e
prticos. Objetivos pessoais so simples, universais e pessoais: manter sua dignidade e
no se sentir estpido, no cometer erros, conseguir realizar uma quantidade de trabalho
razovel, se divertir ou ao menos no ficar completamente entediado. Muitas pessoas no
admitem o objetivo de no se sentir estpido, pois so orgulhosas, inteligentes e
costumam gostar de enfrentar desafios e dominar situaes complexas. Mas esse um
dos principais objetivos pessoais.
Objetivos corporativos tpicos so: aumentar lucro, aumentar dominao de mercado,
derrotar a competio, contratar mais pessoas, oferecer mais produtos e servios, abrir a
empresa para o mercado de aes. O designer utiliza esses objetivos para manter o foco
nas questes mais amplas e evitar se distrair com tarefas ou outros objetivos falsos.
Os objetivos prticos fazem a ponte entre os objetivos corporativos e os do usurio
individual. A empresa quer que todos trabalhem bastante para maximizar o retorno. Um
objetivo prtico de processar as requisies do cliente conecta os objetivos corporativos
de maior lucro com o objetivo pessoal do usurio de ser produtivo. Alguns objetivos
prticos tpicos so: evitar reunies, processar as requisies do cliente, registrar um
pedido de um cliente.
Segundo Cooper, os objetivos mais importantes so os objetivos pessoais. Tratase de
uma pessoa real interagindo com o seu produto, e no uma corporao abstrata. Seus
usurios vo se esforar para atingir os objetivos corporativos, mas somente aps seus
prprios objetivos pessoais terem sido atingidos. Embora uma persona no precise
atingir todos seus objetivos prticos de uma vez, ela nunca deve ter um de seus objetivos
pessoais violados.
Norman (2003) props trs nveis de processamento cognitivo: visceral,
comportamental e reflexivo. Com base nesses nveis de processamento, Cooper, Reimann
e Cronin (2007) definiram trs tipos de objetivos do usurio: objetivos de experincia,
finais e de vida, respectivamente.
Os objetivos de experincia (experience goals) dizem respeito a como o usurio deseja se
sentir, por exemplo: sentir-se no controle, se divertir, relaxar, permanecer alerta, manter o
foco ou no se sentir estpido. Eles esto relacionados com o processamento cognitivo
visceral, responsvel por perceber e reagir rapidamente aos estmulos do ambiente
atravs dos cinco sentidos viso, audio, tato, paladar e olfato e o sistema motor
humano. Esse processamento nos auxilia a decidir rapidamente sobre o que bom, ruim,
agradvel, desagradvel, seguro, perigoso etc. Apoiar os objetivos de experincia exige
maior ateno s caractersticas fsicas do sistema interativo para afetar as primeiras
reaes e sentimentos do usurio de forma esperada.
Os objetivos finais (end goals) representam o que o usurio deseja fazer, como, por
exemplo: manter contato com amigos e familiares, concluir sua lista de tarefas no final de
um dia de trabalho, encontrar msicas que ele gosta de ouvir ou ser notificado de
qualquer problema antes que se torne crtico. Eles tm forte relao com o processamento
cognitivo comportamental, que permite gerenciar comportamentos simples e cotidianos.
Atender aos objetivos finais significa projetar um sistema interativo capaz de estar
alinhado com e complementar os comportamentos do usurio.
Os objetivos de vida (life goals) esto relacionados com quem o usurio deseja ser,
como, por exemplo: viver uma boa vida, ter sucesso em suas ambies, se tornar um
especialista em determinado assunto ou atividade ou ser popular e respeitado pelos
colegas. Esses objetivos esto relacionados com o processamento cognitivo reflexivo,
envolvendo consideraes e reflexes conscientes sobre experincias anteriores e
conhecimentos adquiridos. Para dar ateno aos objetivos de vida, o projeto de um
sistema interativo deve integrar os desejos e as expectativas de longo prazo dos usurios
com a experincia proporcionada durante o uso desse sistema. Durante o uso, essa
integrao ocorre atravs de um processo reflexivo do usurio que atribui significado e
valor de longo prazo experincia proporcionada pelo uso.
Cooper (1999) alerta para o perigo de se definir como objetivos o que ele chama de
falsos objetivos. Tratam-se de meios para se atingir um fim, e no objetivos finais. Os
objetivos verdadeiros so sempre um fim. Cooper considera como um exemplo de falso
objetivo rodar num navegador , quando o que o usurio quer mesmo ter acesso ao
sistema em qualquer lugar, o que pode ser realizado de outras formas. Sempre que
suspeitarmos que um objetivo seja falso, devemos investig-lo, perguntando por que a
persona gostaria de atingir aquele objetivo, at chegarmos ao objetivo verdadeiro.
O Exemplo 6.3 descreve uma terceira persona do sistema de apoio acadmico, desta
vez com os seus objetivos destacados no final da descrio.
Exemplo 6.3
O bjetivos de uma persona
Marta Batista, professora cada turma uma turma
Marta Batista professora da universidade AprendaMais h dois anos.
Embora lecione apenas duas disciplinas diferentes, ela gosta de configurar
o sistema sob medida para cada turma, pois sente que isso contribui para a
qualidade do curso.

Ela no se importa em ler instrues sobre como proceder para atingir


um objetivo, mas gostaria que essas instrues estivessem no ponto em
que so necessrias, em vez de ter de buscar num manual separado. Marta
gostaria de agilizar o seu trabalho, com acesso mais rpido s
funcionalidades que utiliza com frequncia, como divulgar material, ver se
h novidades no frum de discusso, descobrir quem j entregou cada
trabalho e quem est devendo, alm de divulgar as correes dos trabalhos
dos alunos.
Objetivos pessoais:
no perder tempo e
trabalhar da melhor maneira possvel
Objetivos prticos:
utilizar um sistema adequado a cada disciplina e a cada turma;
divulgar material didtico;
acompanhar e participar das discusses no frum da disciplina;
acompanhar a entrega dos trabalhos dos alunos; e
divulgar as correes dos trabalhos dos alunos.
6.3 Cenrios
Como visto na Seo 4.3.5, um cenrio basicamente uma histria sobre pessoas
realizando uma atividade (Rosson e Carroll, 2002). uma narrativa, textual ou pictrica,
concreta, rica em detalhes contextuais, de uma situao de uso da aplicao, envolvendo
usurios, processos e dados reais ou potenciais. Os cenrios podem ser utilizados em
diversas etapas do processo, com diferentes objetivos: para descrever uma histria num
domnio de atividade, visando capturar requisitos e auxiliar no entendimento da
atividade, levantar questes sobre a introduo de tecnologia, explorar diferentes
solues de design e avaliar se um produto satisfaz a necessidade dos seus usurios
(Rosson e Carroll, 2002; Cooper, 1999). Alm de poderosos, os cenrios requerem menos
custo e tempo quando comparados com modelos e prottipos complexos, o que os torna
uma ferramenta importante em todo o processo de design de IHC.
Os cenrios descrevem o comportamento e as experincias dos atores. Cada ator
possui objetivos que dirigem as tarefas que ele realiza. Um cenrio possui um enredo,
que inclui sequncias de aes e eventos: o que os usurios fazem, o que acontece com
eles, que mudanas ocorrem no ambiente, e assim por diante. Essas aes e eventos
podem ajudar, atrapalhar ou ser irrelevantes para o atingimento do objetivo.
Em geral, cada cenrio apresenta um ator principal e um objetivo principal. Tal
objetivo pode ser desdobrado em subobjetivos, numa atividade de planejamento que se
passa na cabea dos atores. Quando essa atividade mental for importante para uma
situao, o cenrio pode incluir informaes sobre planejamento e avaliao das aes
realizadas. Cada cenrio costuma ter um ttulo que descreve brevemente a situao, sem
muitos detalhes; os atores que participam do cenrio; uma breve descrio da situao
inicial em que os atores se encontram; e referncias a outros cenrios que permitam aos
atores atingir os mesmos objetivos de diferentes maneiras. Segundo Rosson e Carroll
(2002), os elementos caractersticos de um cenrio so:
ambiente ou contexto: detalhes da situao que motivam ou explicam os objetivos, aes
e reaes dos atores do cenrio;
atores: pessoas interagindo com o computador ou outros elementos do ambiente;
caractersticas pessoais relevantes ao cenrio;
objetivos: efeitos na situao que motivam as aes realizadas pelos atores;
planejamento: atividade mental dirigida para transformar um objetivo em um
comportamento ou conjunto de aes;
aes: comportamento observvel;
eventos: aes externas ou reaes produzidas pelo computador ou outras
caractersticas do ambiente; algumas delas podem ser ocultas ao ator mas
importantes para o cenrio;
avaliao: atividade mental dirigida para interpretar a situao.
A descrio de um ator no cenrio deve incluir as suas caractersticas pessoais que
forem relevantes ao cenrio. Caso os cenrios sejam utilizados em conjunto com
personas, os atores dos cenrios so as personas elaboradas previamente.
Na atividade de anlise, em particular, utilizamos cenrios de anlise (por vezes
denominados cenrios de problema), histrias sobre o domnio de atividade do usurio,
tal como ele existe antes da introduo de tecnologia (Rosson e Carroll, 2002). O Exemplo
6.4 ilustra dois cenrios de anlise relacionados para um sistema de administrao
acadmica.

Exemplo 6.4
C enrios de anlise
Cadastro de projetos finais com coorientador externo no cadastrado
Atores: Joana Marinho (secretria), Fernando Couto (aluno)
Na primeira semana de aula, Joana Marinho, secretria do curso de
Engenharia Ambiental, precisa cadastrar entre vinte e trinta projetos finais
dos alunos no perodo atual. Um projeto final um trabalho individual de
um aluno sob a orientao de um ou dois professores. Cada aluno
preenche um formulrio impresso e o entrega na secretaria. Em vez de
cadastrar os projetos finais medida que so entregues, Joana prefere
juntar vrios para cadastr-los de uma vez, pois acha que assim perde
menos tempo. Joana confere o formulrio, verificando se o aluno definiu
seu(s) orientador(es) e o ttulo e formato de entrega do seu trabalho (e.g.,
relatrio, software), para ento cadastrar os dados no sistema. No caso do
aluno Fernando Couto, aps informar o ttulo do trabalho e o orientador
principal, Joana descobre que o seu coorientador, que no professor
regular do curso, no est cadastrado no sistema. Ela interrompe o
cadastramento, pega o e-mail de Fernando da sua ficha cadastral
(impressa) e lhe envia uma mensagem solicitando os dados do seu
coorientador externo: nome completo, CPF e e-mail para contato. No dia
seguinte, Joana recebe a mensagem de resposta de Fernando com os dados
solicitados. Ela ento reinicia o cadastro do projeto final de Fernando, sem
poder aproveitar o que havia feito na vspera. Ao terminar o cadastro,
Joana entra no seu sistema de correio eletrnico e envia uma mensagem
para todos os envolvidos (aluno e coorientadores), para que eles confiram
os dados cadastrados e confirmem sua participao no projeto.
Confirmao do cadastro de projetos finais
Atores: Marcos Correa (professor)
Marcos Correa, orientador de Fernando, um professor requisitado que
orienta diversos alunos ao mesmo tempo. Todo incio de perodo ele recebe
diversas mensagens informando-lhe sobre os projetos finais cadastrados
sob sua superviso. Infelizmente, as mensagens no apresentam os dados
cadastrados, ento ele precisa entrar no sistema para conferir os dados.
Alm disso, mesmo j estando no sistema e verificando um projeto, ele
no consegue ver os dados dos outros projetos pendentes. Sendo assim,
tem de ficar alternando entre o seu cliente de e-mail e o sistema
acadmico, e s vezes ele acaba visitando os dados de um mesmo projeto
mais de uma vez.
Anlise dos cenrios
No primeiro cenrio, observamos alguns pontos que podem ser
considerados problemticos e devem ser considerados em um reprojeto de
IHC:
a necessidade de transcrio para o sistema de dados preenchidos pelo
aluno em um formulrio impresso;
a falta de integrao do sistema com as informaes dos alunos (o e-
mail de Fernando deve ser buscado em uma ficha impressa);
a incapacidade de enviar uma mensagem atravs do sistema para as
pessoas envolvidas no cadastro de um projeto final (Joana precisa
acessar seu sistema de correio eletrnico para enviar uma mensagem
para o orientador, coorientador e aluno);
a impossibilidade de o professor acessar outros projetos com
pendncias, uma vez que j esteja no sistema.

Os cenrios destacam objetivos sugeridos pela aparncia e o comportamento de um


sistema; o que as pessoas tentam fazer com ele; que procedimentos so adotados, no so
adotados e realizados com sucesso ou falha; e quais interpretaes as pessoas fazem do
que acontece com elas (Rosson e Carroll, 2002). Por serem ricos em contextualizao, os
cenrios permitem explorar com detalhes os impactos do produto nas atividades e nos
processos de trabalho dos usurios.
Cenrios podem incluir excees. Que eventos importantes acontecem raramente? Ao
compreendermos situaes extremas ou infrequentes que os usurios enfrentam,
podemos identificar situaes em que o produto pode se tornar problemtico. Tambm
podemos identificar caractersticas-chave que podem beneficiar seus usurios finais
(Cooper, 1999).
Uma diferena importante entre cenrios e casos de uso utilizados em engenharia de
software que os cenrios podem enfatizar mudanas de objetivos, planos e
entendimentos (Rosson e Carroll, 2002). Trata-se da descrio de um ator especfico
realizando aes especficas. As aes potenciais e os fluxos alternativos que so
descritos num caso de uso s devem ser includos num cenrio caso faam parte do
processo de planejamento ou avaliao dos atores daquele cenrio especfico. Em outras
palavras, cada cenrio descreve apenas um dos caminhos descritos em um caso de uso.
Carroll (2000) acredita que diagramas e especificaes abstraem a riqueza do uso do
sistema em situaes reais, podendo se tornar um obstculo tanto para uma explorao
mais ampla do espao de design quanto para o envolvimento e a participao dos clientes
e futuros usurios do sistema no processo de design.
As tcnicas baseadas em cenrios vm ganhando grande aceitao por parte dos
projetistas e seus clientes. Isso se deve principalmente natureza da atividade de design
de software, que no uma forma fcil ou rotineira de resoluo de problemas.
Problemas de design costumam ser especificados de forma incompleta, as solues no
so conhecidas a priori, envolvem equilibrar tenses entre diversos elementos
interdependentes e requerem uma diversidade de conhecimento e habilidades. Alm
disso, o design de artefatos interativos causa transformaes no mundo que alteram as
possibilidades de atividade e experincia humanas, com frequncia extrapolando as
fronteiras das solues de design originais pretendidas. O design de IHC baseado em
cenrios busca, atravs da concretizao de situaes de uso, explorar a complexidade da
resoluo de problemas de design (Carroll, 2000).
Algumas crticas ao uso de cenrios se referem frequncia com que ficam
incompletos ou ambguos. Com o objetivo de elaborar cenrios mais completos,
descobrindo informaes que tenham sido omitidas, Carroll et al. (1994) propem a
tcnica de questionamento sistemtico. Trata-se de segmentar o cenrio em proposies
e investigar mais profundamente cada proposio a partir de um conjunto geral de
perguntas, cujas respostas, por sua vez, geram novas proposies, repetindo o ciclo at
que o conjunto de proposies seja considerado suficientemente completo. Os tipos
gerais de perguntas que eles sugerem so: Por qu? Como? O que ? X pode ser feito da
forma Y? X faz parte de Y? Associado a cada questo eles indicam o contedo esperado
das respostas questo, conforme ilustrado na Tabela 6.1.
Tabela 6.1
Questes para refinamento de cenrios (Carroll et al., 1994)

Para enriquecer as informaes dos cenrios, elaborar narrativas mais detalhadas e


assim permitir uma anlise mais profunda, o designer pode responder tambm
perguntas mais especficas (adaptadas de Silveira et al., 2004; Aureliano, 2007),
relacionadas com os elementos de um cenrio (Tabela 6.2).
Tabela 6.2
Perguntas utilizadas para refinar cada elemento de um cenrio ou auxiliar a anlise

elem ento perguntas


objetivo Por que os atores querem ou precisam alcanar esse objetivo?
Quais as precondies para esse objetivo?
De que informaes ou conhecimento os atores precisam para realizar esse objetivo?
Quais informaes so (ou deveriam ser) criadas, consumidas, manipuladas ou destrudas pelo alcance do objetivo?
Que outros objetivos (de quais atores) esto relacionados a esse?
ambiente Em que situaes o cenrio ocorre (quando, onde e por qu)?
Que dispositivos e outros recursos (inclusive tempo) esto disponveis para o alcance do objetivo?
Quais presses existem para o alcance do objetivo?
Quais so as tecnologias utilizadas no ambiente de trabalho? Como os usurios as utilizam?
ator(es) Quem pode alcanar o objetivo descrito no cenrio?
Quais caractersticas dos atores lhes auxiliam ou atrapalham em alcanar o objetivo?
De quem depende o alcance do objetivo? Quem fornece as informaes necessrias ao alcance do objetivo?
Quem depende do resultado do objetivo? Quem consome quais informaes geradas pelo alcance do objetivo? Quem precisa ser notificado da
concluso (bem-sucedida ou malsucedida) do objetivo?
planejamento Como os atores alcanam o objetivo atualmente? Como gostariam de faz-lo?
Quais so as estratgias alternativas para realizar o objetivo? Quando e por que cada estratgia (ou deveria ser) seguida? Os atores
conhecem todas as estratgias disponveis?
Que decises os atores precisam tomar a cada momento? De que maneira o ambiente e o sistema auxiliam ou impedem que os atores tomem
decises adequadas? Quais as consequncias de uma deciso errada?
Que aes realizam? Como essas aes esto relacionadas?
Em que ordem os atores precisam realizar as aes? Gostariam de realiz-las em outra ordem?
ao Quais as precondies para essa ao?
Como os atores as realizam?
H diferentes formas de realiz-la? Qual deve ser adotada em que situaes?
Os atores gostariam de fazer isso de outra maneira? Como o fariam?
De que informaes ou conhecimento os atores precisam para realizar essa ao?
Que recursos esto disponveis para realiz-la?
Quais problemas ou dificuldades podem surgir ao realiz-la? Como podem ser resolvidos ou contornados?
Quais erros podem ser cometidos ao realiz-la? Como podem ser desfeitos? Quais suas consequncias?
Quais informaes so (ou deveriam ser) criadas, consumidas, manipuladas ou destrudas pela realizao da ao?
Quais eventos so (ou deveriam ser) disparados pela realizao da ao?
evento Quais eventos disparam a necessidade de alcanar o objetivo?
Quais eventos so (ou deveriam ser) disparados pela concluso desse objetivo?
avaliao [de uma ao] Como os atores conseguem saber se uma ao foi concluda e realizada com sucesso?
[do objetivo] Como os atores conseguem saber se o objetivo foi concludo e alcanado com sucesso?
[do objetivo] Qual o resultado do alcance do objetivo?

Com cenrios bem elaborados, os designers tm melhores condies de investigar


quais atividades dos usurios poderiam ser executadas de forma mais eficiente, o que se
pode modificar nos processos e sistemas atuais e como um sistema computacional
interativo novo ou reprojetado pode melhor apoiar essas atividades, de forma a se
encaixarem adequadamente no ambiente de trabalho.
Para assegurar que os cenrios sejam representativos do produto, Cooper (1999) sugere
que o conjunto de cenrios enderece os cinco tpicos a seguir:
ciclo de vida do processo: um processo em ampla escala deve ser decomposto em diversos
passos, e cada passo pode ser representado por um cenrio diferente;
segmentos de pblico: seus cenrios devem examinar os diferentes tipos de usurio e
suas experincias, objetivos habilidades, padres de uso etc.
funes do produto: um produto pode ter diferentes funcionalidades, que apoiam tarefas
diferentes e no relacionadas. Seu conjunto de cenrios deve cobrir a gama de
funcionalidades que seu produto apoie;
variantes de uma classe de situaes de tarefa: uma simples tarefa (ou objetivo) pode ser
realizada de diferentes formas. Idealmente, o conjunto de cenrios deve examinar
essas variaes para cada tarefa;
mtodos para realizar uma tarefa: uma nica tarefa selecionada e diferentes
funcionalidades e mtodos para realiz-la so examinados.
Cooper (1999) comenta, no entanto, que a elaborao de cenrios pode consumir
bastante tempo. Segundo ele, no necessrio criar cenrios para todas as tarefas e
situaes que os usurios possam enfrentar. Em vez disso, devemos inicialmente elaborar
cenrios para as tarefas principais, e para as tarefas secundrias medida que o tempo
permitir. Ele destaca os cenrios de uso dirio, que envolvem as principais aes que os
usurios vo realizar, e com a maior frequncia. Em geral, a maioria dos usurios possui
poucos cenrios de uso dirio. Esses cenrios so os que precisam de um apoio mais
robusto do sistema sendo projetado. Os novos usurios precisam dominar esses cenrios
rapidamente, e para isso as instrues devem ser claras e didticas, embutidas no
prprio sistema de forma contextualizada. Em contrapartida, como so utilizados com
frequncia, medida que os usurios se tornarem experientes vo requerer atalhos e
possibilidades de customizao para que a interao se torne adequada s suas
preferncias e estilo individual. Esses cenrios so em grande parte responsveis pelo
sucesso do produto.
Algumas tarefas so realizadas periodicamente mas com pouca frequncia como, por
exemplo, gerar um relatrio anual. Elas tambm requerem instrues claras e didticas
embutidas no produto, mas geralmente podem prescindir de atalhos, pois raramente
seriam aprendidos pelos usurios.
Personas e cenrios podem ser utilizados no mbito da engenharia semitica para
ajudar a definir a primeira parte da metamensagem designerusurio: Este o meu
(designer) entendimento de quem voc (usurio) , do que aprendi que voc quer ou precisa fazer,
de que maneiras prefere fazer, e por qu. (de Souza, 2005a, p. 25). Para melhor coletar as
informaes necessrias elaborao da metamensagem, Paula (2003) prope
complementar os cenrios com perguntas que revelem a inteno do designer ao
elaborar os cenrios e identifiquem os pontos que o designer almeja descobrir, explorar
ou ratificar junto aos usurios. O designer pode gerar uma lista nica de perguntas para
um conjunto de cenrios, numeradas para que estes possam se referir a cada pergunta
individualmente, incluindo o nmero da pergunta entre colchetes, logo aps o trecho
correspondente no cenrio, conforme ilustrado pelo Exemplo 6.5.

Exemplo 6.5
P erguntas exploradas nos cenrios
Conjunto de perguntas e parte do cenrio do Exemplo 6.4 anotado com referncias
s perguntas.
1. Quem pode/deve cadastrar os dados dos projetos finais no sistema?
2. Quando so cadastrados os projetos finais?
3. Quem fornece os dados dos projetos finais?
4. Quais dados de projeto final devem ser cadastrados?
5. Quantos projetos so cadastrados a cada perodo?
6. Quem pode orientar um trabalho final?
7. Que dados so necessrios para cadastrar um coorientador externo?
8. Como so obtidos os dados de um coorientador externo?
9. De quem depende a concluso do cadastramento de projeto final?
10. De que informaes os responsveis pelo projeto precisam para
confirmarem o cadastro?
11. Como um envolvido efetua a confirmao do cadastro?
12. Em que pontos a interao pode ser mais eficiente?
13. Como entrar em contato com um aluno?
14. Quem precisa ser notificado da concluso do cadastro?
Cadastro de projetos finais com coorientador externo no cadastrado
Atores: Joana Marinho (secretria), Fernando Couto (aluno)
Na primeira semana de aula [2], Joana Marinho, secretria do curso de
Engenharia Ambiental, precisa cadastrar entre 20 e 30 projetos finais dos
alunos no perodo atual [5]. Um projeto final um trabalho individual de
um aluno sob a orientao de um ou dois professores [6]. Cada aluno
preenche um formulrio impresso e o entrega na secretaria [3]. Em vez de
cadastrar os projetos finais medida que so entregues, Joana prefere
juntar vrios para cadastr-los de uma vez, pois acha que assim perde
menos tempo [2]. Joana confere o formulrio, verificando se o aluno
definiu seu(s) orientador(es) e o ttulo e formato de entrega do seu
trabalho (e.g., relatrio, software [4]), para ento cadastrar os dados no
sistema [1]. No caso do aluno Fernando Couto, aps informar o ttulo do
trabalho e o orientador principal, Joana descobre que o seu coorientador,
que no professor regular do curso [6], no est cadastrado no sistema.
Ela interrompe o cadastramento, pega o e-mail de Fernando da sua ficha
cadastral (impressa) [13] e lhe envia uma mensagem [8] solicitando os
dados do seu coorientador externo: nome completo, CPF e e-mail para
contato [7]. No dia seguinte, Joana recebe a mensagem de resposta de
Fernando com os dados solicitados. Ela ento reinicia o cadastro do projeto
final de Fernando, sem poder aproveitar o que havia feito na vspera [12].
Ao terminar o cadastro, Joana entra no seu sistema de correio eletrnico e
envia uma mensagem para todos os envolvidos (aluno e orientadores) [14],
para que eles confiram os dados cadastrados e confirmem sua participao
no projeto [9].
Naturalmente, nem todas as perguntas so exploradas em todos os cenrios. No
entanto, assim como no questionamento sistemtico proposto por Carroll, pensar na
forma de perguntas pode levar o designer a descobrir lacunas no cenrio. Por exemplo, a
pergunta 10 Quais so as informaes fornecidas para os responsveis pelo projeto
confirmarem o cadastro? revela que o cenrio, embora envolva o envio da mensagem de
confirmao, no define claramente quais so as informaes contidas na mensagem.
possvel que a omisso seja proposital naquele momento, mas importante tornar
explcitas as perguntas que permitem elaborar a metamensagem designerusurio, para
que elas fiquem registradas e sejam respondidas em algum momento do processo de
design. Alm disso, a leitura de um cenrio pode, por sua vez, levantar novas questes a
serem incorporadas ao conjunto de questes e respondidas naquele ou em outros
cenrios.
6.4 Anlise de Tarefas
Uma anlise de tarefas utilizada para se ter um entendimento sobre qual o trabalho
dos usurios, como eles o realizam e por qu. Nesse tipo de anlise, o trabalho definido
em termos dos objetivos que os usurios querem ou precisam atingir. Segundo Diaper
(2003), a anlise de tarefas a expresso utilizada no campo da ergonomia, que inclui
IHC, para representar todos os mtodos de coletar, classificar e interpretar dados sobre o
desempenho de um sistema que possua ao menos uma pessoa como componente (p.
14). A questo crucial passa a ser como definir um desempenho satisfatrio para um
sistema e seus componentes. Trata-se no apenas de listar aes, mas entender como um
sistema de trabalho (composto ao menos de um sistema computacional e uma pessoa)
afeta o domnio de aplicao e como, em contrapartida, o domnio de aplicao afeta o
sistema de trabalho.
Em IHC, a anlise de tarefas pode ser utilizada nas trs atividades habituais: para
anlise da situao atual (apoiada ou no por um sistema computacional), para o
(re)design de um sistema computacional ou para a avaliao do resultado de uma
interveno que inclua a introduo de um (novo) sistema computacional. Quando visa a
avaliar um sistema computacional existente, a anlise de tarefas pode ser bem concreta,
descrevendo o comportamento de forma detalhada. J numa situao de design, a anlise
de tarefas geralmente ser realizada num nvel maior de abstrao, pois diversos pontos
ainda no tero sido definidos no incio da atividade de design.
Um dos primeiros passos numa anlise de tarefas coletarmos um conjunto de
objetivos, definidos em termos psicolgicos, ou seja, objetivos das pessoas. claro que
organizaes tambm podem possuir objetivos, como, por exemplo, aumentar o lucro,
mas estes no costumam ser endereados em anlises de tarefa. Para cada objetivo,
elaboramos uma lista das aes realizadas (no mundo fsico e atravs do sistema
computacional) por um agente para alcanar esse objetivo. Quando h mltiplos agentes,
Diaper recomenda representar as aes de cada agente numa coluna diferente.
Diaper (2003) ressalta que, independentemente da forma como os dados para uma
anlise de tarefas forem coletados, s teremos uma simulao das verdadeiras tarefas de
interesse. Primeiro, h um nmero potencialmente infinito de tarefas realizadas por
diferentes pessoas, mas apenas algumas podem ser selecionadas para a anlise. Segundo,
apenas uma pequena poro do trabalho pode ser observada, e, portanto, os dados das
tarefas so sempre incompletos. Finalmente, o prprio ato de coletar dados costuma
alterar o que est sendo estudado. Embora um insumo importante da anlise de tarefas
seja a observao do desempenho, Diaper afirma que ela envolve tambm dados obtidos
atravs de entrevistas, questionrios, documentao, programas de treinamento e
sistemas existentes. A anlise de tarefas deve buscar identificar dados conflitantes e
disparidades entre o relato oficial e a prtica do trabalho.
Dentre os mtodos de anlise de tarefas mais comuns, podemos destacar a Anlise
Hierrquica de Tarefas (HTA Hierarchical Task Analysis, Annett, 2003; Annett e Duncan,
1967), o GOMS (Goals, Operators, Methods, and Selection Rules, Kieras, 2003) e o
ConcurTaskTrees (CTT; Patern, 2000), descritos a seguir.
6.4.1 Anlise Hierrquica De Tarefas
A Anlise Hierrquica de Tarefas (HTA Hierarchical Task Analysis) foi desenvolvida na
dcada de 1960 para entender as competncias e habilidades exibidas em tarefas
complexas e no repetitivas, bem como para auxiliar na identificao de problemas de
desempenho (Annett, 2003; Annett e Duncan, 1967). Ela ajuda a relacionar o que as
pessoas fazem (ou se recomenda que faam), por que o fazem, e quais as consequncias
caso no o faam corretamente. Ela se baseia em psicologia funcional, e no
comportamental, como eram as abordagens da poca em que foi criada.
Uma tarefa qualquer parte do trabalho que precisa ser realizada. Toda tarefa pode ser
definida em termo de seu(s) objetivo(s). Tarefas complexas so definidas em termos de
objetivos e subobjetivos, num desdobramento hierrquico. Esse desdobramento
chamado de decomposio de tarefas ou redescrio (Diaper, 2003). Observe que essa
definio mais ampla e difere da definio adotada pelo design baseado em objetivos e
considerada nas sees anteriores, segundo a qual uma tarefa um meio para se atingir
um objetivo (Cooper et al., 2007). Em HTA, tarefa se aproxima do conceito de atividade.
Uma anlise funcional de tarefas comea pela definio dos objetivos das pessoas,
antes de considerarmos as aes atravs das quais a tarefa pode ser realizada e o objetivo
ser atingido. Um objetivo um estado especfico de coisas, um estado final. Esse estado
pode ser definido por um ou mais eventos ou por valores fisicamente observveis de uma
ou mais variveis, que atuam como critrio de alcance do objetivo e, em ltima instncia,
do desempenho do sistema. Em vez de identificar uma lista de aes, a HTA inicia com
uma definio dos objetivos das pessoas.
A HTA examina primeiramente os objetivos de alto nvel (por exemplo, marcar uma
reunio), decompondo-os em subobjetivos (por exemplo, decidir a data, decidir o local,
convidar os participantes etc.), buscando identificar quais subobjetivos so mais difceis
de atingir (ou que geram mais erros) e que, portanto, limitam ou mesmo impedem o
atingimento do objetivo maior.
Os subobjetivos de um objetivo e as relaes entre eles denominada de plano. Um
plano define os subobjetivos necessrios para alcanar um outro objetivo maior, e a
ordem em que esses subobjetivos devem ser alcanados. Os planos podem definir
diversas relaes entre os subobjetivos: sequncia fixa (um objetivo deve ser atingido
antes do prximo); regra de seleo ou deciso (quais objetivos que devero ser atingidos
dependem das circunstncias); ou em paralelo (mais de um objetivo deve ser atingido ao
mesmo tempo).
No nvel mais baixo da hierarquia de objetivos, cada subobjetivo alcanado por uma
operao, que a unidade fundamental em HTA. A Figura 6.1 apresenta os elementos de
um diagrama HTA.
FIGURA 6.1 Elementos de um diagrama HTA.

Uma operao especificada pelas circunstncias nas quais o objetivo ativado (input
ou entrada), pelas atividades ou aes (actions) que contribuem para atingi-lo e pelas
condies que indicam o seu atingimento (feedback). Uma ao pode ser entendida como
uma instruo para fazer algo sob certas circunstncias, o input como estados e o
feedback como testes ou avaliao do estado final. A ao pode ser vista formalmente
como uma regra de transformao entre estados. Por exemplo, em um sistema de agenda,
possvel ter a seguinte tupla de <inputs, aes, feedback>: <[data, local, participantes],
[convidar os participantes], [presena dos participantes confirmada]>. Em outras
palavras, as principais caractersticas de uma operao so as diversas aes que devem
ser desempenhadas para atingir um objetivo e as condies que o satisfazem. Dessa
maneira, a anlise visa identificar principalmente como um sistema possibilita ou
impede as pessoas de alcanarem seus objetivos. Essa anlise permite ainda identificar
problemas potenciais de cada ao, bem como elaborar recomendaes para evit-los.
A Figura 6.2 ilustra um diagrama HTA para o cadastro de um projeto final em um
sistema acadmico, e a Tabela 6.3 apresenta a tabela equivalente ao diagrama.

FIGURA 6.2 Diagrama HTA, para o objetivo de cadastrar um projeto final em um sistema acadmico.
Tabela 6.3
Exemplo de representao das tarefas da HTA em tabela

objetivos / operaes problem as e recom endaes


0. Cadastrar projeto final 1>2 input: formulrio de cadastro de projeto final, com ttulo, orientador(es) e formato do trabalho
feedback: novo projeto aparece para a secretria na lista de projetos cadastrados como pendente enquanto os
envolvidos no confirmarem
plano: informar dados do projeto e depois enviar mensagem de confirmao do cadastramento
recomendao: permitir que o aluno efetue o cadastro on-line
1. Informar dados do projeto 1+2 plano: informar aluno, ttulo, formato, orientador principal e informar coorientador
1.1. Informar aluno, ttulo, formato,
orientador principal
1.2 Informar coorientador 1/2 plano: informar coorientador j cadastrado ou informar nome, CPF e e-mail do orientador
1.2.1. Informar coorientador j cadastrado
1.2.2. Informar nome, CPF e e-mail do problema: ao cadastrar novo orientador, perde os dados j cadastrados do projeto, caso haja
coorientador recomendao: incluir o CPF de orientadores externos no formulrio preenchido pelo aluno
2. Enviar mensagem de confirmao do ao: cadastro deve ser confirmado em at sete dias
cadastramento recomendao 1: tornar a confirmao mais eficiente
recomendao 2: alertar sobre o prazo de confirmao

Um mesmo objetivo pode ser atingido de diferentes maneiras, dependendo de


circunstncias peculiares a cada situao. E uma ao pode ser utilizada como parte do
alcance de diferentes objetivos. Por exemplo, consultar os compromissos em uma agenda
pode fazer parte de um objetivo de marcar uma reunio, de um objetivo de saber o que
tem de ser feito em um determinado dia, ou diversos outros. Sendo assim, apenas listar
as aes sem entender para que servem pode causar interpretaes equivocadas (Diaper,
2003).
Uma questo recorrente em decomposio de tarefas diz respeito deciso sobre
quando parar de decompor. Em geral, a decomposio termina quando j se tem todas as
informaes necessrias para atingir os objetivos da anlise. Um critrio de parada o
critrio p c (Annett e Duncan, 1967), que significa parar quando o produto da
probabilidade de falha (p) e o custo da falha (c) for julgado aceitvel. Uma outra razo
para a parada ocorre quando a origem de um erro ou problema j tiver sido identificada
e, portanto, o analista j pode propor uma correo, seja em termos de design de sistema,
procedimentos operacionais ou treinamento.
Segundo Diaper (2003), uma Anlise Hierrquica de Tarefas consiste nos seguintes
passos:
1. Decidir os objetivos da anlise. Em geral, envolvem projetar um sistema novo, modificar
um sistema existente e desenvolver treinamento para os operadores.
2. Obter consenso entre as partes interessadas na definio dos objetivos da tarefa e medidas de
sucesso. Devem ser definidos os resultados de desempenho desejados, tal como
frequncia de erros, e as formas como esses resultados sero aferidos. Para cada
objetivo, as questes-chave so: qual evidncia objetiva indicar que esse objetivo foi
atingido? e quais as consequncias da falha em atingir esse objetivo?.
3. Identificar as fontes de informaes das tarefas e selecionar as formas de aquisio de dados.
Embora a observao direta seja amplamente utilizada como forma de aquisio de
dados, geralmente contribui pouco sobre eventos incomuns que possam ser
essenciais. Entrevistas com especialistas, registros do desempenho real e relatos de
incidentes costumam trazer informaes preciosas para a HTA.
4. Coletar dados e esboar uma tabela ou diagrama de decomposio. Numa decomposio, os
subobjetivos devem ser mutuamente exclusivos e exaustivos, ou seja, devem definir
completamente o objetivo a que esto subordinados, sem que haja sobreposies
entre os subobjetivos. A decomposio esboada em um diagrama hierrquico
(Figura 6.2) e em uma tabela, que contm mais detalhes sobre as circunstncias
(inputs) que disparam o objetivo, aes e feedbacks de cada objetivo (Tabela 6.3).
5. Verificar a validade da decomposio junto s partes interessadas, visando assegurar a
confiabilidade da anlise.
6. Identificar operaes significativas, tendo em vista o objetivo da anlise, geralmente
utilizando o critrio p c.
7. Gerar e, se possvel, testar hipteses relacionadas aos fatores que afetam o aprendizado e o
desempenho. Nessa etapa, pode ser til utilizar as classificaes de erro humano
propostas por Reason (1990): desempenho baseado em habilidades, em regras, ou em
conhecimento.
O desempenho baseado em habilidades envolve padres de instrues pr-
programadas. Erros nesse nvel esto relacionados a variaes de fora e de coordenao
espaotempo das pessoas para operar e atuar sobre os dispositivos. O desempenho
baseado em regras envolve resolver problemas familiares cujas solues so governadas
por regras do tipo ese. Erros nesse nvel esto relacionados com a classificao
equivocada de situaes, levando aplicao de regras ou procedimentos errados.
Finalmente, o desempenho baseado em conhecimento ocorre em situaes novas para as
quais as aes ainda precisam ser planejadas, utilizando processos analticos conscientes.
Erros nesse nvel se devem a limitaes de recursos e conhecimento incompleto ou
incorreto (Reason, 1990).

6.4.2 GOMS (Goals, Operators, Methods, And Selection


Rules)
Card et al. (1983) propuseram um conjunto de modelos chamado de famlia GOMS
(Goals, Operators, Methods, and Selection Rules Objetivos, Operadores, Mtodos e
Regras de Seleo) para analisar o desempenho de usurios competentes de sistemas
computacionais, realizando tarefas dentro da sua competncia e sem cometer erros.
Muitos sistemas so projetados considerando que as pessoas se tornam habilidosas no
seu uso e, portanto, vo querer formas eficientes de realizar tarefas rotineiras. Os
modelos GOMS tm se mostrado teis para prever o desempenho, ou seja, predizer o
impacto de decises de design no desempenho competente (John, 2003).
O GOMS um mtodo para descrever uma tarefa e o conhecimento do usurio sobre
como realiz-la em termos de objetivos (goals), operadores (operators), mtodos (methods)
e regras de seleo (selection rules). Os objetivos representam o que o usurio quer
realizar utilizando o software (e.g., editar um texto). Os operadores so primitivas
internas (cognitivas) ou externas (as aes concretas que o software permite que os
usurios faam, tal como um comando e seus parmetros digitados num teclado; a
seleo de menus; o clique de um boto). Os mtodos so sequncias bem conhecidas de
subobjetivos e operadores que permitem atingir um objetivo maior. Quando h mais do
que um mtodo para atingir um mesmo objetivo, so necessrias regras de seleo, que
representam tomadas de deciso dos usurios sobre qual mtodo utilizar numa
determinada situao. Em suma, o GOMS caracteriza o conhecimento procedimental de
uma pessoa ao realizar tarefas num determinado dispositivo (Kieras, 2003).
A anlise GOMS se aplica principalmente a situaes em que os usurios realizam
tarefas que j dominam. Esses usurios no esto resolvendo problemas ou tentando
identificar o que precisam fazer em seguida. Essa anlise pressupe que eles sabem o
que fazer, e s precisam faz-lo. Em geral, o GOMS utilizado aps uma anlise bsica de
tarefas, com o objetivo de fornecer uma representao formalizada que pode ser utilizada
para prever o desempenho da tarefa, de modo que possa substituir parte dos testes
empricos com usurios. Isso feito atribuindo um tempo estimado de execuo para
cada operador primitivo. Um operador cognitivo toma aproximadamente 50 ms, ao passo
que o tempo associado a operadores externos baseado em dados de observao. Para
efeitos de engenharia, o modelo psicolgico oferecido pelo GOMS fornece resultados
bastante robustos e informativos.
O GOMS pode ser utilizado tanto quantitativamente, de modo a fornecer previses
sobre o tempo necessrio para realizar tarefas, como qualitativamente, no sentido de
auxiliar na elaborao de programas de treinamento, sistemas de ajuda e sistemas
tutores inteligentes, pois um modelo GOMS contm uma descrio detalhada do
conhecimento necessrio para realizar cada tarefa. Tambm pode ser utilizado para
reprojetar um sistema: pode revelar um objetivo frequente apoiado por um mtodo
muito ineficiente; pode mostrar que alguns objetivos no so apoiados por nenhum
mtodo; e pode revelar onde objetivos semelhantes so apoiados por mtodos
inconsistentes, uma situao em que os usurios podem ter problemas para lembrar o
que fazer (John, 2003).
A anlise com GOMS requer que o designer comece com uma lista de objetivos de
usurio (ou tarefas de alto nvel), que pode ser obtida de entrevistas de usurios
potenciais, observaes de usurios de sistemas existentes ou semelhantes. A princpio,
uma anlise GOMS no revela objetivos que o analista tenha deixado de identificar, nem
corrige uma formulao equivocada dos objetivos dos usurios. O GOMS tambm pode
ser utilizado como ferramenta de design numa avaliao formativa, realizada ao longo de
todo processo de design para avaliar as solues alternativas elaboradas a cada iterao.
Dentre os modelos da famlia GOMS, destacamos: KLM (Card et al., 1983), CMN-
GOMS (Card et al., 1983) e CPM-GOMS (John e Gray, 1995), descritos a seguir.

KLM
O KLM a tcnica mais simples de GOMS, limitada a um conjunto predefinido de
operadores primitivos: K para pressionar uma tecla ou boto; P para apontar com o
mouse um alvo num dispositivo visual; H para mover as mos para o teclado ou outro
dispositivo; D para desenhar um segmento de reta em um grid; M para se preparar
mentalmente para realizar uma ao ou uma srie de aes primitivas fortemente
relacionadas entre si; e R para o tempo de resposta do sistema, durante o qual o usurio
precisa esperar (Tabela 6.4).

Tabela 6.4
Algumas operaes do KLM-GOMS e suas duraes mdias (Kieras, 1993)

operao durao m dia


K: pressionar e soltar uma tecla do teclado
exmio digitador (135 ppm) 0,08 s
bom digitador (90 ppm) 0,12 s
digitador mediano (55 ppm) 0,20 s
digitador inexperiente (40 ppm) 0,28 s
digitao de letras aleatrias 0,50 s
digitao de cdigos complexos 0,75 s
digitador no familiarizado com o teclado 1,20 s
P: apontar o cursor do mouse num objeto da tela 1,10 s
B: pressionar ou soltar o boto do mouse 0,10 s
H: levar a mo do teclado ao mouse ou vice-versa 0,40 s
M: preparao mental 1,20 s
T (n): digitao de cadeia de caracteres nx Ks
W(t): espera pela resposta do sistema depende do sistema

O KLM tambm inclui um conjunto de heursticas sobre como posicionar operadores


mentais durante a preparao. A estimativa de tempos de execuo pode ser utilizada
para comparar ideias em tarefas de benchmark, fazer uma avaliao paramtrica para
explorar o espao definido por importantes variveis (e.g., o tamanho de nomes de
arquivos em uma linguagem de comando) e fazer anlises sobre as suposies feitas
(e.g., velocidade de digitao do usurio) (John, 2003).
O Exemplo 6.6 ilustra o tipo de anlise que pode ser feita com o KLM.

Exemplo 6.6
A nlise do desempenho com o K L M
Anlise da Tarefa: Salvar arquivo
Essa anlise evidencia que usar as teclas de atalho quase duas vezes
mais eficiente do que usar o boto correspondente na barra de
ferramentas, e quase trs vezes mais eficiente do que usar o item de menu
correspondente.

CMN-GOMS
O CMN-GOMS se refere proposta original de GOMS, elaborada por Card, Moran e
Newell. No CMN-GOMS, h uma hierarquia estrita de objetivos, os operadores so
executados estritamente em ordem sequencial, e os mtodos so representados numa
notao semelhante a um pseudocdigo, que inclui submtodos e condicionais. O
Exemplo 6.7 apresenta um modelo GOMS parcial representando as tarefas envolvidas em
descobrir a direo de trfego de uma rua utilizando o Google Maps.1 Os objetivos e
mtodos foram numerados para facilitar sua identificao. Algarismos indicam
sequncia, e letras indicam alternativas.
Exemplo 6.7
M odelo G O M S sem detalhes
GOAL 0: descobrir direo de trfego de uma rua
GOAL 1: encontrar a rua
METHOD 1.A: zoom at o nvel de ruas
(SEL. RULE: a regio em que se situa a rua est visvel no mapa e o
usurio conhece o local)
METHOD 1.B: fazer busca pelo nome da rua
(SEL.RULE: o usurio no conhece o local ou o mapa visvel est longe
de l)
GOAL 2: identificar a direo do trfego na rua

Ao elaborar um modelo GOMS, devemos definir cuidadosamente o que representar e o


que no representar. Tarefas mentais podem ser complexas, mas apenas aquelas que
estejam relacionadas ao design do sistema devem ser includas no modelo (Kieras, 2003).
Alm disso, o nvel de detalhes utilizado deve atender aos objetivos da anlise. Em
etapas iniciais, costumamos representar as estratgias alternativas que o usurio poder
seguir para atingir seus objetivos (Exemplo 6.7). J para uma anlise mais precisa do
desempenho, os passos so mais detalhados (Exemplo 6.8).

Exemplo 6.8
M odelo G O M S detalhado
GOAL 0: descobrir direo de trfego de uma rua
GOAL 1: encontrar a rua
METHOD 1.A: zoom at o nvel de ruas
(SEL. RULE: o local est visvel no mapa e o usurio sabe onde fica a
rua)
METHOD 1.A.A: zoom utilizando roda do mouse
(SEL. RULE: rua no centralizada no mapa, cursor distante da escala e
preferncia do usurio)
OP. 1.A.A.1: deslocar o cursor do mouse para a rua desejada
OP. 1.A.A.2: girar a roda do mouse para a frente
OP. 1.A.A.3: verificar enquadramento da rua no mapa
METHOD 1.A.B: zoom utilizando o menu pop-up
(SEL. RULE: rua centralizada no mapa, cursor distante da escala e
pref. do usurio)
OP. 1.A.B.1: clicar com o boto direito do mouse
OP. 1.A.B.2: deslocar o mouse para a opo zoom in
OP. 1.A.B.3: clicar com o boto esquerdo do mouse
OP. 1.A.B.4: verificar enquadramento da rua no mapa
METHOD 1.A.C: zoom utilizando rgua de escala
(SEL. RULE: cursor prximo da escala e preferncia do usurio)
OP. 1.A.C.1: deslocar o cursor do mouse para a rgua de escala na
posio de zoom desejada
OP. 1.A.C.2: clicar com o boto esquerdo do mouse
OP. 1.A.C.3: verificar enquadramento da rua no mapa
METHOD 1.A.D: zoom utilizando boto de zoom in
(SEL. RULE: cursor prximo da escala e preferncia do usurio)
OP. 1.A.D.1: deslocar o cursor do mouse para o boto de zoom in
OP. 1.A.D.2: clicar com o boto esquerdo do mouse
OP. 1.A.D.3: verificar enquadramento da rua no mapa
METHOD 1.B: fazer busca pelo nome da rua
(SEL.RULE: o usurio no conhece o local ou o mapa visvel est longe
de l)
OP. 1.B.1: deslocar o cursor do mouse para o campo de busca
OP. 1.B.2: digitar o nome da rua desejada
OP. 1.B.3: ativar a busca
OP. 1.B.4: verificar resultados de busca
GOAL 1.B.5: localizar a rua
METHOD 1.B.5.A: selecionar a rua da lista de ruas encontradas
(SEL. RULE: mais de uma rua encontrada; rua no est visvel no
mapa; nvel de zoom inadequado)
OP. 1.B.5.A.1: deslocar o cursor do mouse para a lista
OP. 1.B.5.A.2: clicar sobre a rua desejada
OP. 1.B.5.A.3: verificar enquadramento da rua no mapa
METHOD 1.B.5.B: localizar visualmente a rua no mapa
(SEL. RULE: rua est visvel no mapa)
OP. 1.B.5.B.1: examinar marcador que identifica a rua
GOAL 2: identificar a direo do trfego na rua
OP. 2.1: examinar setas desenhadas ao longo da rua desejada

Quantitativamente, os modelos CMN-GOMS permitem prever a sequncia de


operadores e o tempo de execuo. Qualitativamente, eles focam mtodos para alcanar
objetivos: mtodos semelhantes so facilmente identificados, mtodos atipicamente
curtos ou longos se destacam e podem disparar ideias de design, como, por exemplo, a
incluso de teclas de atalho para comandos frequentes e pontos de feedback para o
usurio.
Uma diferena importante entre os modelos KLM e CMN-GOMS que o CMN-GOMS
representado na forma de programa, e, portanto, a anlise geral e executvel.
Qualquer instncia de classe de tarefas descrita pode ser realizada ou simulada seguindo
os passos do modelo que podem passar por caminhos diferentes dependendo da situao
especfica da tarefa (John, 2003).

CPM-GOMS
O CPM-GOMS foi assim designado por dois motivos: por representar operadores
cognitivos, perceptivos e motores, e por seguir a abordagem de Critical Path Method (tcnica
de anlise do caminho crtico). CPM-GOMS uma verso do GOMS baseada diretamente
no processador humano de informaes (MHP, veja Seo 3.3.1) e, portanto, no modelo
de estgios paralelos de processamento do processamento humano de informaes. Isso
significa que o CPM-GOMS no supe que os operadores so executados
sequencialmente. Em outras palavras, operadores cognitivos, perceptivos e motores
podem ser tornar paralelos conforme a tarefa. O CPM-GOMS utiliza um diagrama tipo
PERT para representar os operadores e as dependncias entre eles. Nessa anlise, o
caminho crtico fornece uma previso simples do tempo total da tarefa (Figura 6.3).

FIGURA 6.3 Exemplo de modelo CPM-GOMS.

A construo de um modelo CPM-GOMS inicia com a construo do modelo CMN-


GOMS, cujos operadores so em seguida classificados em operadores cognitivos,
perceptivos e motores do MHP. Atribumos ento uma durao estimada a cada operador
e calculamos o tempo de execuo previsto para a tarefa. possvel ainda efetuar uma
anlise qualitativa da relao entre aspectos do design e o tempo de execuo, bem como
fazer simulaes de designs alternativos e ajudar a identificar por que um ter um
desempenho melhor do que o outro.
Em geral, o CPM-GOMS assume que o usurio extremamente experiente e executa as
tarefas to rpido quanto a arquitetura MHP permite. Isso significa que o usurio sabe
exatamente onde procurar visualmente um determinado item de informao, e que no
h atividades cognitivas substanciais associadas seleo de mtodos ou decises
complexas. Portanto, os modelos CPM-GOMS devem ser utilizados apenas para tarefas
nas quais a seleo do mtodo se baseia em dicas bvias do ambiente ou envolve
decises triviais (John, 2003).

6.4.3 rvores De Tarefas Concorrentes (Concurtasktrees -


CTT)
O modelo de rvores de tarefas concorrentes (ConcurTaskTrees CTT) foi criado para
auxiliar a avaliao e o design e avaliao de IHC (Patern, 2000). Nesse modelo, existem
quatro tipos de tarefas (Figura 6.4a):
tarefas do usurio, realizadas fora do sistema;
tarefas do sistema, em que o sistema realiza um processamento sem interagir com o
usurio;
tarefas interativas, em que ocorrem os dilogos usuriosistema; e
tarefas abstratas, que no so tarefas em si, mas sim uma representao de uma
composio de tarefas que auxilie a decomposio.
Assim como na anlise hierrquica de tarefas, os diferentes nveis hierrquicos devem
ser lidos como para considerar T1 como tendo sido realizada, as tarefas T2 e T3 devem
ter sido realizadas (Figura 6.4b).

FIGURA 6.4 Representaes (a) dos tipos de tarefas e (b) da sua hierarquia no CTT.

Alm da hierarquia, o CTT permite representar diversas relaes entre as tarefas, que
aumentam a expressividade da notao (Figura 6.5). Os significados dssas relaes so os
seguintes:
ativao: T1 T2 significa que a segunda tarefa (T2) s pode iniciar aps a primeira
tarefa (T1) terminar;
ativao com passagem de informao: T1 [] T2 especifica que, alm de T2 s poder ser
iniciada aps T1, a informao produzida por T1 passada para T2;
escolha (tarefas alternativas): T1 [] T2 especifica duas tarefas que estejam habilitadas
num momento, mas que, uma vez que uma delas iniciada, a outra desabilitada;
tarefas concorrentes: T1 ||| T2 especifica que as tarefas podem ser realizadas em
qualquer ordem ou ao mesmo tempo;
tarefas concorrentes e comunicantes: T1 |[]| T2 especifica que, alm de as tarefas poderem
ser realizadas em qualquer ordem ou ao mesmo tempo, elas podem trocar
informaes;
tarefas independentes: T1 |=| T2 especifica que as tarefas podem ser realizadas em
qualquer ordem, mas quando uma delas iniciada, precisa terminar para que a outra
possa ser iniciada;
desativao: T1 [> T2 especifica que T1 completamente interrompida por T2;
suspenso/retomada: T1 |> T2 especifica que T1 pode ser interrompida por T2 e
retomada do ponto em que parou assim que T2 terminar.

FIGURA 6.5 Relaes entre tarefas no CTT.

A Figura 6.6 apresenta um exemplo de modelo de tarefas representado em CTT para


um objetivo de marcar um compromisso em uma agenda.
FIGURA 6.6 Exemplo de modelo de tarefas representado em CTT.

Dentre as vantagens do CTT com relao a outros modelos de tarefas, destacamos a


possibilidade do registro explcito das relaes entre as tarefas. Observamos que, uma
vez que h tarefas interativas, do sistema e do usurio, o CTT vai alm da anlise de
tarefas tradicional para representar uma soluo de design da interao. Uma
desvantagem com relao a modelos especificamente projetados para a interao a
ausncia de elementos destinados representao de mecanismos de preveno e
tratamento de erros na interao usuriosistema (Seo 7.3.3).
Atividades
1. Elaborao de perfil de usurio. Trace os perfis de alunos e professores que devero
utilizar um sistema de apoio ao planejamento de aulas, divulgao de material
didtico e agendamento de trabalhos, provas e outras atividades. Identifique quais
perguntas de uma entrevista ou de um questionrio fornecem as informaes
necessrias para traar esses perfis.
2. Elaborao de personas. Com base nos perfis de alunos e professores traados
anteriormente, crie o elenco de personas que representam os usurios do seu sistema.
Identifique as personas primrias e secundrias, bem como as que representam
demais stakeholders e antiusurios.
3. Elaborao de cenrios. Elabore cenrios de problema para as personas atingirem seus
objetivos. Considere os objetivos mais frequentes e os mais infrequentes de cada
persona. Indique quais perguntas so respondidas ou endereadas pelo cenrio.
4. Anlise Hierrquica de Tarefas. Elabore os diagramas hierrquicos de tarefas e suas
respectivas tabelas, correspondentes aos cenrios de problema criados na atividade
anterior. Identifique, a partir desses modelos, pontos em que a atividade pode ser
mais eficiente.
5. Elaborao de modelo GOMS. Elabore um modelo GOMS detalhado para dois dos
objetivos cenarizados anteriormente. Identifique a necessidade ou oportunidade de
diferentes estratgias para alcanar um mesmo objetivo.
1
http://maps.google.com.
7

Design de IHC
Objetivos do Captulo
Apresentar representaes e modelos utilizados no design da interao e da interface
com usurio.
Discutir como as representaes utilizadas favorecem certos tipos de reflexo sobre o
design de IHC.
Apresentar diferentes estilos de interao que podem ser adotados no design de IHC.
Descrever representaes da interface com usurio em diferentes nveis de abstrao e
enfocando diversos aspectos da soluo.
Este captulo apresenta representaes e modelos utilizados ao longo de diferentes
processos de design de IHC, focando as atividades de concepo da soluo interativa.
Descreve cenrios de interao, que so utilizados em diversos processos de design
apresentados no Captulo 4, em particular nos processos de design baseado em cenrios
(Seo 4.3.5), orientado por objetivos (Seo 4.3.6) e centrado na comunicao (Seo
4.3.7). O captulo se aprofunda nos modelos utilizados pelo design centrado na
comunicao, em particular: mapa de objetivos, esquema conceitual de signos, modelo
de tarefas e modelo de interao (Paula, 2003; Silva, 2005). Esses modelos so utilizados
para motivar a reflexo de designers, durante o design de IHC, sobre estratgias
alternativas de uso do sistema e sobre mecanismos de preveno e recuperao de
rupturas comunicativas que podem causar falhas na interao. Em seguida, so
analisadas algumas decises tomadas ao partir do design da interao para o design da
interface. Finalmente, o captulo descreve brevemente questes relacionadas ao sistema
de ajuda (Silveira et al., 2004) e questes de adaptao e adaptatividade (Schneider-
Hufschmidt et al., 1993; de Souza e Barbosa, 2006) que apresentam desafios adicionais
atividade de design.
7.1 Introduo
Os modelos e as representaes utilizados no Captulo 6 permitem descrever quem usa
ou utilizar o sistema (atravs de perfis de usurio e personas); quais so seus objetivos,
motivaes, e em que contexto ele ser utilizado (cenrios de problema); e como os
usurios alcanam esses objetivos atualmente (cenrios e modelos de tarefa). Essas
informaes e artefatos so utilizados tambm para o design da interao. Naquele
captulo, o foco era a anlise da situao atual. Neste captulo, nos concentramos no
projeto da interveno que ser feita, atravs do design do sistema computacional
interativo visando apoiar melhor os usurios no alcance dos seus objetivos.
O design de IHC visa elaborar um modelo conceitual de entidades e atributos do
domnio e do sistema, estruturar as tarefas e projetar a interao e a interface de um
sistema interativo que apoie os objetivos do usurio. Para isso, podem ser utilizadas
diversas representaes, cada qual endereando uma ou mais questes de IHC, como
pode ser visto na Figura 7.1.

FIGURA 7.1 Representaes utilizadas para explorar diferentes aspectos de IHC.

Personas, cenrios de problema e alguns modelos de tarefas foram descritos no


Captulo 6. As demais representaes so descritas nas prximas sees.
7.2 Cenrios de Interao
Como visto nas Sees 4.3.5 e 6.3, cenrios so narrativas sobre pessoas realizando uma
atividade para alcanar um ou mais objetivos (Rosson e Carroll, 2002). A Seo 4.3.5
descreve diversos tipos de cenrios: de problema, de atividade, de informao e de
interao, e a Seo 6.3 explora cenrios de problemas em detalhes. Os cenrios de
problemas investigados na atividade de anlise descrevem a situao atual, evidenciando
problemas e oportunidades de melhoria. J os cenrios de interao representam
intervenes para enderear esses problemas e oportunidades.
Um cenrio de interao especifica em mais detalhes as aes do usurio e as
respectivas respostas (feedback) do sistema necessrias para alcanar os objetivos
apoiados pelo sistema. Apesar de ricos em detalhes e contextualizados, os cenrios de
interao elaborados em fases iniciais de design no devem conter detalhes da interface
propriamente dita, como textos e rtulos, tipos de elementos de interface (widgets)
utilizados etc. Pretendemos com isso evitar um comprometimento precoce dos designers
com uma soluo de interface a ser adotada, o que dificultaria a explorao de solues
alternativas que emergissem da modelagem de tarefas e do projeto cuidadoso da
interao. Por exemplo, no devemos dizer que Joana seleciona relatrio tcnico da lista
expansvel (dropdown list) denominada Formato de entrega. Tais decises sobre a
escolha dos elementos de interface devem ser postergadas para o momento adequado no
processo de design.
O Exemplo 7.1 define dois cenrios de interao que buscam resolver os problemas
apontados por um dos cenrios do Exemplo 6.4, reproduzido a seguir para facilitar a
anlise das solues propostas.

Exemplo 7.1
C enrios de interao
Cenrio de problema: Cadastro de projetos finais com coorientador externo no
cadastrado
Atores: Joana Marinho (secretria), Fernando Couto (aluno)
Na primeira semana de aula [2], Joana Marinho, secretria do curso de
Engenharia Ambiental, precisa cadastrar entre 20 e 30 projetos finais dos
alunos no perodo atual [5]. Um projeto final um trabalho individual de
um aluno sob a orientao de um ou dois professores [6]. Cada aluno
preenche um formulrio impresso e o entrega na secretaria [3]. Em vez de
cadastrar os projetos finais medida que so entregues, Joana prefere
juntar vrios para cadastr-los de uma vez, pois acha que assim perde
menos tempo [2]. Joana confere o formulrio, verificando se o aluno
definiu seu(s) orientador(es) e o ttulo e formato de entrega do seu
trabalho (e.g., relatrio, software [4]), para ento cadastrar os dados no
sistema [1]. No caso do aluno Fernando Couto, aps informar o ttulo do
trabalho e o orientador principal, Joana descobre que o seu coorientador,
que no professor regular do curso [6], no est cadastrado no sistema.
Ela interrompe o cadastramento, pega o e-mail de Fernando da sua ficha
cadastral (impressa) [13] e lhe envia uma mensagem [8] solicitando os
dados do seu coorientador externo: nome completo, CPF e e-mail para
contato [7]. No dia seguinte, Joana recebe a mensagem de resposta de
Fernando com os dados solicitados. Ela ento reinicia o cadastro do projeto
final de Fernando, sem poder aproveitar o que havia feito na vspera [12].
Ao terminar o cadastro, Joana entra no seu sistema de correio eletrnico e
envia uma mensagem para todos os envolvidos (aluno e orientadores) [14],
para que eles confiram os dados cadastrados e confirmem sua participao
no projeto [9].
Cenrio de interao A: Cadastro de projetos finais pelos professores
Atores: Joana (secretria), Fernando Couto (aluno), Marcos Correa
(professor, orientador principal do projeto final), Pedro Melo (coorientador
externo)
Na primeira semana de aula [2], Joana, secretria do curso de
Engenharia Ambiental, precisa se certificar de que os projetos finais dos
alunos iniciados no perodo atual esto cadastrados. Como costumam ser
entre 20 e 30 projetos [5], e seu cadastramento deve ser efetuado numa
poca em que o pessoal da secretaria est sobrecarregado de trabalho, cada
professor deve cadastrar os projetos dos seus alunos [1]. Para isso, Joana
envia uma mensagem a todos os professores solicitando que cadastrem os
projetos sob sua orientao e informando que eles tm apenas uma
semana para faz-lo, sob risco de os alunos terem suas matrculas em
Projeto Final I canceladas.
Ao receber a mensagem de Joana, Marcos Correa entra no sistema para
cadastrar o projeto final do seu aluno Fernando Couto [1,3]. Ele informa o
nome e a matrcula do aluno, alm do ttulo e do formato de entrega do seu
trabalho (e.g., relatrio ou software) [4]. Ao informar os dados do
coorientador externo (nome completo, e-mail e CPF) [7], percebe que no
possui o CPF do seu colega, Pedro Melo. Marcos ento pede que o prprio
sistema envie uma mensagem a Pedro solicitando essa informao [8] e
confirma o cadastramento [9]. Ao concluir o cadastramento, Marcos
informado de que o sistema enviar uma mensagem de solicitao de
informaes adicionais para seu colega Pedro e uma mensagem de feedback
para o aluno Fernando Couto.
Cenrio de interao B: Cadastro de projetos finais pelos prprios alunos
Atores: Joana (secretria), Fernando Couto (aluno), Marcos Correa
(professor, orientador principal do projeto final), Pedro Melo (coorientador
externo)
Na primeira semana de aula [2], Joana, secretria do curso de
Engenharia Ambiental, precisa se certificar de que os projetos finais dos
alunos iniciados no perodo atual esto cadastrados. Como costumam ser
entre 20 e 30 projetos [5], e seu cadastramento deve ser efetuado numa
poca em que o pessoal da secretaria est sobrecarregado de trabalho, cada
aluno deve cadastrar o seu prprio projeto [1]. Para isso, Joana extrai do
sistema uma lista de alunos matriculados em Projeto Final I, contendo
nmero de matrcula, nome e e-mail de cada aluno, e envia uma mensagem
para esses alunos com instrues sobre como devem cadastrar o seu
projeto e informando que eles tm apenas uma semana para faz-lo, sob
risco de terem suas matrculas em Projeto Final I canceladas.
Ao receber a mensagem de Joana, Fernando Couto entra no sistema para
cadastrar seu projeto final [1,3]. Ele informa seu orientador principal,
verifica que seu coorientador, que no pertence ao quadro de professores
da universidade [6], no est cadastrado e inicia o cadastramento dos seus
dados: nome completo, e-mail e CPF [7]. Percebe que no possui o CPF do
seu coorientador, Pedro Melo. Fernando ento pede que o prprio sistema
envie uma mensagem a Pedro solicitando essa informao [8]. Fernando
ento prossegue informando os demais dados do projeto final: ttulo e
formato de entrega do seu trabalho (e.g., relatrio ou software) [4]. Ao
concluir o cadastramento, Fernando informado de que o sistema enviar
uma mensagem de confirmao para o seu orientador e uma mensagem de
solicitao de informaes adicionais para seu coorientador, e ficar
marcado como pendncia at que a confirmao ocorra [9].
Conjunto de perguntas exploradas nos cenrios:
1. Quem pode/deve cadastrar os dados dos projetos finais no sistema?
2. Quando so cadastrados os projetos finais?
3. Quem fornece os dados dos projetos finais?
4. Quais dados de projeto final devem ser cadastrados?
5. Quantos projetos so cadastrados a cada perodo?
6. Quem pode orientar um trabalho final?
7. Que dados so necessrios para cadastrar um coorientador externo?
8. Como so obtidos os dados de um coorientador externo?
9. De quem depende a concluso do cadastramento de projeto final?
10. De que informaes os responsveis pelo projeto precisam para
confirmarem o cadastro?
11. Como um envolvido efetua a confirmao do cadastro?
12. Em que pontos a interao pode ser mais eficiente?
13. Como entrar em contato com um aluno?
14. Quem precisa ser notificado da concluso do cadastro?

Tambm nos cenrios de interao so feitas referncias s perguntas exploradas na


sua narrativa. Na tentativa de solucionar o problema de cadastramento pela secretria
Joana, foram propostos dois cenrios de interao: cenrio A, no qual o cadastramento
realizado pelo professor orientador; e cenrio B, no qual o cadastramento efetuado pelo
prprio aluno. Durante as discusses sobre qual das solues a mais adequada,
possvel que nenhuma das duas seja escolhida, e que uma nova soluo seja elaborada,
diferente de A e de B, ou uma combinao das duas. Alm disso, num processo de design
reflexivo (em linha com a perpectiva de refleo-em-ao discutida na Seo 4.2),
possvel ainda que o prprio problema seja revisto e que o novo enquadramento do
problema requeira a elaborao de novos cenrios, tanto de problema como de interao.
7.3 Design Centrado na Comunicao
Na engenharia semitica, o objetivo do design da interao completar a segunda parte
da metamensagem do designer para o usurio (de Souza, 2005a, p. 25; Seo 3.8):

Este o meu entendimento, como designer, de quem voc, usurio, , do que aprendi que voc
quer ou precisa fazer, de que maneiras prefere fazer, e por qu. Este, portanto, o sistema
que projetei para voc, e esta a forma como voc pode ou deve utiliz-lo para
alcanar uma gama de objetivos que se encaixam nesta viso.

Em outras palavras, responsabilidade do designer comunicar aos usurios sua viso


de design e darlhes melhores condies de entender e aprender sobre o sistema
projetado e como podem utiliz-lo.
Como visto na Seo 4.3.7, o design centrado na comunicao visa elaborar essa
metacomunicao de modo a evitar rupturas comunicativas durante a interao do
usurio com o preposto do designer. Como essa interao vista como uma conversa,
projetar a interao significa definir as conversas que o usurio poder travar com o
preposto do designer para alcanar seus objetivos. As representaes e o embasamento
terico do design centrado na comunicao tm por objetivo motivar o designer a refletir
sobre o seu papel como interlocutor dessas conversas. Essa reflexo resulta no projeto da
linguagem de interface, atravs da qual o usurio e o preposto do designer, seu
representante durante a interao, sero capazes de travar essas conversas em direo
aos objetivos do usurio, segundo a viso do designer.
O design da interao pode ento ser considerado como a especificao de todas as
conversas que os usurios podero travar com o preposto do designer, incluindo
conversas alternativas representando diferentes estratgias para alcanar um objetivo e
conversas para a recuperao de rupturas comunicativas. Precisamos estabelecer sobre o
que o usurio e o preposto do designer esto conversando a cada momento e de que forma
essa conversa ocorre durante o uso do sistema interativo.
Toda conversa tem um tpico, que o assunto geral por ela endereado. Essa conversa
pode se desdobrar em dilogos, que endeream subtpicos relacionados ao tpico da
conversa. A cada momento, a conversa tem um foco, que pode ser um dos elementos do
modelo de comunicao de Jakobson (1960): contexto, emissor, receptor, mensagem,
cdigo e canal (veja Seo 3.8.3). Para se referir a qualquer um desses elementos, um
interlocutor faz uso de signos, compondo as falas que ele emite.
Os tpicos e o foco da conversa so mantidos ou alterados por trocas de turno, e em
cada turno emitida uma ou mais falas de um dos interlocutores da conversa (usurio ou
preposto do designer). A Tabela 7.1 apresenta um exemplo de interao como uma
conversa, cujo objetivo cadastrar o enunciado de um trabalho. Nela, os signos que
constituem o foco da conversa a cada momento aparecem em negrito.
Tabela 7.1
Exemplo de representao da interao como uma conversa entre usurio (U) e
preposto do designer (D)

tpico > subtpico


falas e signos
(dilogo)
cadastrar trabalho U: Preciso cadastrar um trabalho para os meus alunos de IHC.
> informar dados do trabalho D: Qual o ttulo e a descrio do trabalho? At quando deve ser entregue? Pode ser feito em grupo? Quantos pontos vale
o trabalho?
> consultar datas importantes U: Antes, quero consultar os prazos da universidade e feriados desse semestre.
D: Eilos.
> informar dados do trabalho U: Preciso de uma semana para corrigir os trabalhos, e preciso entregar as notas at dia 2 de junho. Ento vou pedir para os
alunos entregarem os trabalhos at o dia 26 de maio (data de entrega). Eles devem receber um lem brete do prazo de
entrega.
D: OK, o trabalho dever ser entregue at o dia 26 de maio e os alunos sero lembrados no dia 23 de maio (trs dias antes).
> informar dados do trabalho D: E qual o ttulo e a descrio do trabalho? Pode ser feito em grupo? Quantos pontos vale o trabalho?
U: O trabalho pode ser feito em dupla, e vale 20% da nota. O ttulo () e a descrio ().
D: OK, o trabalho j foi cadastrado.
conferir cadastro do trabalho U: Deixa eu conferir os dados do trabalho Esto OK.
> examinar dados do
trabalho
notificar alunos U: Agora quero avisar aos alunos de que o enunciado do trabalho j est disponvel.
D: OK, posso enviar a m ensagem padro?
> informar contedo da U: Sim.
mensagem
conferir mensagem > D: A m ensagem () foi enviada para os alunos ().
contedo e destinatrios
da mensagem

As prximas subsees descrevem as representaes utilizadas para o projeto da


interao como uma conversa.

7.3.1 Mapa De Objetivos Dos Usurios


Como primeiro passo do design da interao, devemos organizar os objetivos dos
usurios que tenham sido identificados na etapa de anlise. Em um primeiro momento,
devemos representar apenas o que o usurio deseja realizar, sem considerar como ele o
far. Esses objetivos correspondem aos objetivos prticos descritos em personas e
cenrios.
Os objetivos podem ser classificados em finais e instrumentais. Os objetivos finais so
aqueles que levam o usurio a utilizar o sistema. J os objetivos instrumentais so
utilizados como facilitadores para os objetivos finais, um meio para o fim desejado. Por
exemplo, considere o objetivo final de cadastrar um projeto. Um projeto final possui um
tipo, cujo valor dever ser indicado dentre um conjunto de tipos vlidos. Caso o usurio
possa definir novos tipos, cadastrar um novo tipo de projeto pode ser considerado como
um objetivo instrumental do primeiro.
Os objetivos instrumentais podem ainda ser subclassificados em instrumentais diretos
ou indiretos. Um objetivo instrumental direto pode ser considerado como facilitador
imediato do objetivo que instrumenta, durante a interao. Um objetivo instrumental
indireto, por sua vez, prepara o terreno para que o objetivo por ele instrumentado seja
atingido em algum momento futuro.
Retomando o exemplo anterior, caso o usurio possa definir novos tipos de projeto
enquanto cadastra um projeto, o objetivo cadastrar um novo tipo de projeto
considerado instrumental direto. J se o usurio precisar planejar quais tipos de projeto
devem ficar disponveis e cadastr-los a priori, o objetivo cadastrar um novo tipo de
projeto considerado instrumental indireto. Podemos observar que a escolha entre
tornar um objetivo instrumental direto ou indireto j envolve tomar decises sobre a
interao usuriosistema. Considerando as estratgias de ao planejada e situada,
descritas na Seo 3.5, podemos dizer que os objetivos instrumentais indiretos favorecem
uma interao mais planejada, ao passo que os objetivos instrumentais diretos favorecem
uma interao mais situada e oportunista.
A Tabela 7.2 fornece modelos comumente utilizados na formulao dos diversos tipos
de objetivos, do ponto de vista do designer.

Tabela 7.2
Formulaes comumente utilizadas para descrever diferentes tipos de objetivos

tipo de objetivo form ulao


final Voc (usurio no papel <Papel>) quer utilizar o sistema para <atingir objetivoFinal>
instrumental Quer <atingir objetivoInstrumental> para <atingir objetivo-Final> [de forma mais eficiente/fcil/flexvel]
instrumental direto Quer <atingir objetivoInstrumental> para <atingir objetivo-Final> [de forma mais eficiente/fcil/flexvel] agora
instrumental indireto Quer <atingir objetivoInstrumental> para <atingir objetivo-Final> [de forma mais eficiente/fcil/flexvel] no futuro

H casos ainda em que um objetivo final pode ser considerado tambm um facilitador
de um outro objetivo, como se fosse, ao mesmo tempo, final e instrumental. Por exemplo,
considere os objetivos finais consultar um projeto e alterar o cadastro de um projeto. O
objetivo consultar um projeto pode ser considerado, alm de objetivo final, objetivo
instrumental direto para alterar o cadastro de um projeto. Dessa maneira, assim que o
usurio tiver atingido o objetivo de consultar um projeto, ele poder imediatamente
passar para o objetivo de alter-lo. A representao desse tipo de relao envolve
decises de design sobre a estruturao da atividade do usurio, que ser representada
em modelos de tarefa e de interao, descritos nas prximas subsees.
Independentemente da representao utilizada para organizar os objetivos dos
usurios, o designer pode relacionar e anotar esses objetivos de acordo com algumas
dimenses de interesse. Essas dimenses variam com o tipo de projeto. Alguns
elementos que podem ser utilizados para organizar os objetivos so:
papis de usurios (i.e., papis que podem ou devem atingir cada objetivo, tais como
aluno/professor, autor/editor);
tipo de objetivo (objetivo final ou instrumental direto ou indireto);
entidade (conceito do domnio ou do sistema) principal relacionada ao objetivo (e.g.,
professor, disciplina, atividade, apresentao, categoria etc.)
O Exemplo 7.2 apresenta um mapa de objetivos de um sistema de apoio a aulas
presenciais em uma universidade.
Exemplo 7.2
M apa de objetivos de usurio
Considere um sistema de apoio divulgao de material, atividades e
notas de uma disciplina em uma universidade. Professores e alunos
utilizam o sistema com diferentes objetivos. Professores podem gerenciar
e consultar suas disciplinas, alunos, avisos, materiais didticos e trabalhos
a serem realizados pelos alunos. J os alunos utilizam o sistema
principalmente para consultas, mas tambm para entregar os trabalhos
realizados. Todos podem se comunicar atravs de um frum de discusso.
No mapa de objetivos da Figura 7.2, os objetivos que manipulam um
mesmo tipo de entidade esto agrupados: aviso, material didtico, trabalho,
frum de discusso e sistema. Esses agrupamentos podem auxiliar a tomar
decises sobre a interface, como, por exemplo, sobre a organizao e a
estrutura de menus e submenus.
FIGURA 7.2 Mapa de objetivos dos usurios.

Nesse exemplo, observamos que o objetivo final alterar trabalho


instrumentado diretamente pelo objetivo (tambm final) consultar trabalho.
A maioria dos objetivos representados na figura so objetivos finais. Os
nicos objetivos instrumentais representados so os objetivos: customizar
tipo de trabalho, que permite alcanar os objetivos cadastrar trabalho e
alterar trabalho de modo mais preciso, qualificando as atividades sendo
cadastradas; e definir permisses, que permite configurar quem pode fazer o
que no sistema.
Os papis que so afetados por algum tipo de configurao de
permisses so sublinhados. No exemplo, observamos que a definio de
permisses afeta apenas os objetivos cadastrar material e criar discusso.
Isso significa que o professor (papel que pode alcanar o objetivo definir
permisses) pode permitir ou no que os alunos (representados pela letra A
sublinhada) alcancem esses objetivos atravs do sistema.

A representao das relaes de instrumentao entre objetivos finais ajuda a tomar


decises sobre consistncia no design da interao e da interface. Considerando os
objetivos Consultar material e Excluir material do exemplo, se a relao entre eles no
estiver representada, pode acontecer de um cenrio para Excluir material definir uma
forma de localizar o material didtico diferente da forma projetada no cenrio Consultar
material. Isso pode causar inconsistncias e rupturas na interao usuriosistema.
Uma situao extrema aconteceria se o usurio consultasse um material e, percebendo
que deveria remov-lo, ele no pudesse faz-lo naquele momento. Em vez disso, teria de
abandonar a atividade de consulta, iniciar a conversaa (caminho de interao) para
remover o material, localiz-lo novamente e s ento remov-lo. Esse exemplo trivial
ilustra uma possvel inconsistncia ou ineficincia que pode passar despercebida quando
utilizamos representaes que tratam objetivos separadamente, como algumas formas de
cenrios e modelos de tarefas.
O Exemplo 7.3 apresenta uma situao semelhante, encontrada em um sistema de
administrao acadmica.

Exemplo 7.3
D ecises de design da interao relacionadas
com o mapa de objetivos
Considere um sistema de administrao acadmica, que permite a
professores buscarem um aluno matriculado na universidade e
consultarem seu histrico escolar. Suponha que o professor Jorge Nunes
queira consultar o histrico escolar do aluno Frederico Barbosa, candidato
a uma bolsa de projeto. Esses objetivos podem ser representados de duas
maneiras, cada qual relacionada com uma conversa usuriosistema
(Figura 7.3). Os elementos destacados indicam a diferena entre as duas
alternativas de design.
FIGURA 7.3 Duas formas alternativas de organizar os objetivos consultar dados de aluno e
consultar histrico escolar de aluno.

A conversa na direo do objetivo buscar um aluno comum s duas solues:


U: Quero procurar o aluno Frederico Barbosa.
S: Existem trs alunos com esse nome: Frederico Arruda Barbosa, aluno
de Direito, matrcula 0720253; Frederico Barbosa Torres, aluno de
Economia, matrcula 0819247; e Frederico Martins Barbosa, aluno de
Comunicao Social, matrcula 0723298.
U: Quero ver detalhes sobre o aluno Frederico Martins Barbosa.
S: Seu nmero de matrcula 0723298. Ele aluno de graduao que
cursa o Programa de Comunicao, habilitao Jornalismo. Segue o
currculo 2006.2.
O objetivo buscar um aluno foi concludo. As conversas em direo ao objetivo
consultar histrico escolar so diferentes para cada soluo.
Soluo a: incio de nova conversa em direo do objetivo novo tpico
e novo foco
U: Quero consultar um histrico escolar.
S: Qual o nmero de matrcula do aluno?
U: 0723298.
S: As disciplinas cursadas at hoje so ()
Soluo b: mudana na direo da conversa novo tpico, mesmo foco
U: Quero consultar o histrico escolar dele.
S: As disciplinas cursadas at hoje so ()
O objetivo consultar histrico escolar foi concludo.
Observamos que, quando a relao entre os objetivos no
representada, aumenta o risco de o foco da conversa se perder quando o
tpico da conversa muda, ou seja, quando o usurio alcana um objetivo e
inicia a conversa em direo a um outro.

7.3.2 Esquema Conceitual De Signos: Contedo (Parte I)


O esquema conceitual de signos define e organiza os conceitos envolvidos no sistema,
em particular aqueles que emergem na interface de usurio. Inclui informaes
envolvidas em cada fala (ao) do usurio, sistema ou interlocutor externo que afete a
interao usuriosistema. A partir das atividades e representaes de anlise (veja
Captulos 5 e 6), podemos identificar os signos que faro parte da conversa entre o
usurio e o preposto do designer. O esquema conceitual de signos definido ao longo do
design da interao. Inicialmente, definimos o contedo dos signos, especificando
restries sobre valores associados ao signo, seus valores default, e os mecanismos de
preveno e tratamento de rupturas associadas aos signos (Seo 7.3.3). medida que o
design da interface avana, definimos tambm a expresso dos signos, especificando
como eles se manifestam na interface e como os usurios podem falar sobre eles. Esta
seo descreve como o contedo dos signos deve ser definido. A expresso dos signos
descrita na Seo 7.4.4.
Alguns signos esto relacionados a conceitos ou entidades do domnio ou do prprio
sistema (denominados signo-entidade, ou simplesmente entidade); outros correspondem
a atributos desses signos-entidade (signo-atributo, ou simplesmente atributo), ou ainda
como valores de um signo-atributo.
A Tabela 7.3 mostra alguns signos extrados e extrapolados da conversa representada
na Tabela 7.1.
Tabela 7.3
Definio parcial dos signos-entidade do sistema de apoio acadmico do exemplo

O signo-entidade Enunciado de trabalho composto dos signos ttulo, descrio, data


de entrega, nmero mximo de alunos (individual/em grupo), peso e lembrete do prazo
de entrega. O signo-entidade Trabalho entregue composto dos signos Aluno(s),
relatrio, data de entrega e nota. Uma letra inicial maiscula indica um signo-entidade,
ao passo que uma letra inicial minscula indica um signo-atributo. Notamos que o signo
Aluno , ele prprio, uma entidade, relacionado com o signo-entidade Trabalho entregue
atravs da relao indicada na coluna de observaes. As letras maisculas identificam as
entidades para indicar a direo do relacionamento (e.g., A realiza T). Alm disso,
podemos indicar quais so os signos-atributo de interesse, utilizando a representao
Entidade.atributo ou Entidade.[atributo1, atributo2, ]. Por exemplo, o aluno
matriculado na disciplina identificado pelo seu nmero de matrcula e nome (A.
[matrcula, nome]), ao passo que o enunciado do trabalho identificado apenas pelo seu
ttulo (T.ttulo).
Essas composies e relacionamentos podem auxiliar a definio de um modelo de
entidades e relacionamentos (ER) ou podem ser extrados, com adaptaes, de um ER
existente. No entanto, as entidades, os atributos e os relacionamentos no modelo de
dados nem sempre coincidem com os signos-entidade e signos-atributo correspondentes.
Por exemplo, podemos ter um signo-atributo Aluno.perodo (perodo em que o aluno se
encontra) relacionado a um trecho da interao, ao passo que no modelo de dados
constaria apenas o perodo em que ele foi admitido na universidade, a partir do qual o
perodo em que ele se encontra seria calculado. Nesse momento do design de IHC, o foco
est na identificao de quais signos esto relacionados aos objetivos dos usurios, e no
como esses signos esto representados no modelo de dados. Em outras palavras, do
ponto de vista do usurio, a forma como os dados esto representados no modelo de
dados no relevante, mas sim a sua conceitualizao e expresso na interface.
Nem todo atributo possui o mesmo status. Alguns so utilizados para identificar
univocamente uma entidade, e no apenas para uma caracterizao (parcial) da entidade.
Eles so indicados por um sinal de mais (+). Essa distino importante para o designer
saber, no momento do projeto da interao e da interface propriamente dita, quais
informaes so necessrias e suficientes para o usurio distinguir duas instncias de
uma mesma entidade. Esses signos nem sempre correspondem a chaves primrias de
tabelas em bases de dados. Por exemplo, um professor pode ser identificado em uma
base de dados pelo seu nmero de matrcula, mas os usurios do sistema identificam-no
pelo seu nome. claro que essa identificao informal precisar ser mapeada para uma
identificao formal que o sistema seja capaz de interpretar . Caso haja uma
ambiguidade (e.g., dois professores com o mesmo nome), a representao informal deve
ser modificada para remov-la (e.g., utilizando um nome de guerra ou apelido, em vez
do nome real ou em complemento a ele).

Origem De Um Signo
Quanto sua origem, os signos podem ser classificados como signos de domnio,
convencionais, transformados ou de aplicao. Signos encontrados no mundo do usurio,
independentemente do sistema, so chamados de signos do domnio (por exemplo,
nome e endereo de uma pessoa). Signos originados no domnio, mas que sofrem alguma
transformao ao serem incorporados ao sistema, como uma transformao resultante de
analogias ou metforas, so representados como signos transformados (por exemplo,
diretrio de arquivos digitais para substituir pastas de arquivos fsicas; login para
identidade e senha para assinatura). J signos que s fazem sentido dentro do sistema, e
que no tm significado prvio para os usurios, so chamados de signos da aplicao
(por exemplo, a porcentagem de download de um arquivo). Signos transformados ou de
aplicao que j tenham sido estabelecidos como convenes na cultura dos usurios so
chamados de signos convencionais (por exemplo, zoom em editores grficos ou
interfaces baseadas em mapas).
Por que classificar os signos dessa forma? Porque tipos de signos diferentes requerem
diversas tomadas de deciso por parte do designer, para aumentar a chance de o usurio
interpretar adequadamente o signo, entender os valores a ele associados e saber como
falar sobre ele (i.e., manipul-lo) utilizando a linguagem de interface.
Signos do domnio e signos convencionados costumam ser facilmente entendidos pelos
usurios. Entretanto, se o sistema impe limitaes na forma como o usurio pode falar
sobre o signo, explicaes se fazem necessrias. Pode haver uma restrio sobre a
expresso do signo (e.g., formato ou unidade esperada do dado de entrada) ou sobre o
seu contedo (valores vlidos). Por exemplo, um signo de data pode requerer explicaes
sobre o formato esperado (dd/mm/aaaa) e sobre as datas permitidas (nos ltimos cinco
anos; somente dias teis). J para os signos transformados, o designer deve fornecer aos
usurios informaes sobre os limites da analogia ou metfora realizada de modo a
transport-los para o sistema. Por exemplo, uma explicao sobre as pastas em um
ambiente de trabalho deveria indicar que o volume de documentos que uma pasta pode
conter no determinado pela pasta em si, mas sim pelo espao disponvel no disco
rgido. Finalmente, os signos de aplicao, que podem ser totalmente desconhecidos pelos
usurios, requerem uma explicao completa sobre o que significam e como so
utilizados. Por exemplo, um signo enquadramento em um editor grfico pode ser
considerado como signo de aplicao.
Com o passar do tempo e aumento da familiaridade dos usurios com certos sistemas
de significao, h uma tendncia de os signos de aplicao e transformados se tornarem
convencionados, ou seja, de serem incorporados cultura dos usurios. Alm disso,
alguns signos podem gerar dvidas no momento de classificao em um dos tipos. Por
exemplo, um signo senha pode ser classificado como convencional ou transformado, se
consideramos que ele uma analogia assinatura, impresso digital ou algo que
identifica uma pessoa. Nesse tipo de situao, cabe ao designer definir o tipo do signo,
com base no conhecimento e na experincia prvia dos usurios, bem como a quantidade
de informao ou instrues a serem fornecidas sobre o signo. Em todo caso, a
classificao auxilia o designer a refletir sobre a explicao a ser associada a cada signo.
Examinando a descrio dos signos, podemos identificar oportunidades de
customizao. No caso do signo lembrete do prazo de entrega, achamos que
interessante permitir que o usurio altere o contedo (valor) associado ao signo. Para
isso, criamos um novo signo prazo para lembrete, que aparece sublinhado no campo de
observaes correspondente ao signo lembrete do prazo de entrega. Os signos de
customizao so definidos separadamente, indicando a qual elemento esto associados:
ao usurio, ao dispositivo, a uma entidade, a um perodo de tempo ou algum outro
elemento de contexto ao qual o sistema tenha acesso (e.g., a rede na qual o dispositivo
est conectado).
Restries Sobre A Manipulao E O Contedo Do Signo
medida que o design avana, possvel definir mais informaes acerca dos signos. A
Tabela 7.4 apresenta informaes sobre os tipos de contedo e restries sobre o
contedo de alguns signos.

Tabela 7.4
Definio do contedo dos signos que compem o signo enunciado de trabalho

Observamos que formato de entrega, nmero mximo de alunos e lembrete do prazo


de entrega so do tipo seleo simples. No entanto, h diferenas entre eles: o formato de
entrega possui um conjunto flexvel de valores. Isso significa, provavelmente, que dever
haver um objetivo instrumental para a manuteno desse conjunto.

7.3.3 Preveno E Recuperao De Rupturas


Comunicativas
Como visto na Seo 3.8, a engenharia semitica ressalta a importncia de tentarmos
prever, durante o design de uma soluo de IHC, rupturas (break-downs) na comunicao
entre o preposto do designer e o usurio que podem ocorrer durante a interao. Para
cada ruptura identificada, o designer deve representar os tipos de apoio preveno e
recuperao da ruptura que pretende oferecer aos usurios. Esses tipos de apoio podem
ser classificados nas seguintes categorias (Barbosa e Paula, 2003):
preveno passiva (PP): o preposto do designer tenta evitar que haja uma ruptura,
fornecendo explicaes sobre a linguagem de interface. Por exemplo, apresenta uma
dica de formato como (dd/mm/aaaa) ao lado de um campo de data; ou uma
instruo explcita como asterisco (*) indica campo obrigatrio;
preveno ativa (PA): o preposto do designer impede que o usurio emita falas invlidas
que causem uma ruptura. Por exemplo, habilita ou desabilita um boto de acordo com
o estado atual do sistema; impede que o usurio digite letras ou smbolos em campos
numricos; apresenta um conjunto fechado de opes em uma lista ou um controle de
calendrio que impede que o usurio indique uma data invlida;
preveno apoiada (ou alerta, AL): o preposto do designer, ao identificar uma situao
como causa potencial de uma ruptura, descreve a situao e solicita que o usurio
tome uma deciso informada sobre os rumos da interao. Um exemplo de causa
potencial de ruptura ocorre quando o usurio expressa a inteno de gravar um
arquivo com um nome diferente (atravs de um item de menu Salvar como), mas
em seguida informa o nome de um arquivo existente. Geralmente esse mecanismo
concretizado na interface por dilogos de confirmao (por exemplo, Arquivo j
existe, deseja sobrescrev-lo?; Foram feitas alteraes no trabalho. Deseja
armazen-las?);
recuperao apoiada (RA): aps uma ruptura ter ocorrido, o preposto do designer
auxilia o usurio a se recuperar da ruptura. Ele descreve a ruptura e oferece ao usurio
a oportunidade de retomar a conversa de forma produtiva. Por exemplo, quando o
usurio preenche um campo incorretamente, o preposto apresenta uma mensagem
descrevendo o erro no preenchimento e destaca o campo a ser corrigido, esperando
que o usurio assim o faa;
captura de erro (CE): aps uma ruptura ter ocorrido, o preposto do designer identifica
que no ser possvel ao usurio se recuperar dela atravs da linguagem de interface
do prprio sistema. Nesse caso, o preposto descreve a ruptura e, se possvel, indica ao
usurio algo que ele possa fazer fora do sistema para retomar uma conversa produtiva
com o sistema no futuro. Por exemplo, no caso de um arquivo corrompido, o preposto
pode apresentar a mensagem O arquivo est corrompido. Tente copi-lo novamente
da sua origem.
Esses mecanismos de preveno e tratamento de rupturas podem ser relacionados a
uma tarefa (veja Seo 7.3.4), a um trecho de interao (veja Seo 7.3.5) ou a um signo. A
Tabela 7.5 define os mecanismos de preveno e recuperao de rupturas comunicativas
associadas aos signos definidos na Tabela 7.3.
Tabela 7.5
Mecanismos de preveno e recuperao dos signos-atributo do signo-entidade
enunciado de trabalho

Nesse exemplo, so utilizados trs tipos de mecanismos de preveno e recuperao de


rupturas. A preveno ativa (PA) associada aos signos data de entrega, formato de
entrega, nmero mximo de alunos e lembrete do prazo de entrega impede o usurio de
deixar campos obrigatrios em branco. Isso poder ser mapeado, na interface, em uma
lista ou grupo de botes de opo (radio buttons), nos quais um valor default vem
selecionado, e no possvel ter uma seleo nula.
A preveno passiva (PP) associada aos signos ttulo e peso indica que a interface
fornecer instrues para evitar uma ruptura comunicativa durante a interao (e.g., uso
de * para indicar os campos obrigatrios, juntamente com uma instruo textual * indica
os campos obrigatrios). No entanto, como no h garantias de que o usurio v
entender ou respeitar essas instrues, sempre que um signo estiver associado a uma
forma de preveno passiva, tambm deve estar associado a alguma forma de
recuperao apoiada (RA) equivalente (RA: campo obrigatrio ou, como a preveno
passiva j indica a natureza ou causa da possvel ruptura, apenas RA).

7.3.4 Modelagem De Tarefas


A partir das atividades e representaes de anlise (veja Captulos 5 e 6), podemos
estruturar cada objetivo do usurio de forma a explorar diferentes estratgias que o
usurio poder seguir para alcan-lo. No design pautado pela engenharia semitica, os
modelos de tarefas representam no apenas a estrutura hierrquica das tarefas do
usurio que compem um objetivo, mas tambm estruturas de sequncia e iterao, alm
de tarefas alternativas, independentes de ordem, opcionais e ubquas. Alm disso, para
cada tarefa so representados os signos associados, os mecanismos de preveno e
tratamento de rupturas de comunicao e as precondies para a tarefa, se houver.
A representao de tarefas utilizada na engenharia semitica (Paula, 2003; de Souza,
2005a; Prates e Barbosa, 2007) tambm segue uma decomposio hierrquica Seo 6.4).
O objetivo de mais alto nvel representado por um retngulo com bordas
arredondadas. Ele composto de tarefas, representadas por retngulos. A decomposio
prossegue at chegarmos a operadores, que representam aes atmicas, ou seja, que
podem ser mapeadas diretamente em aes sobre um elemento de interao na interface
(widget). So exemplos de operadores: Escolher tipo de busca e Efetuar busca. Os
operadores so representados como um retngulo sobre uma linha.
Ao elaborarmos um modelo de tarefa, devemos evitar nos concentrar em um ambiente
ou uma plataforma tecnolgica especfica. A decomposio do objetivo ou de uma tarefa
em tarefas menores e operadores deve parar antes que o modelo inclua detalhes de
interface, tais como Digitar X, Pressionar boto Y etc. Essa considerao no apenas
facilita o reso de modelos de tarefas, como tambm evita que decises sobre a soluo
de interao ou de interface sejam tomadas prematuramente, dificultando a explorao
de solues alternativas por parte dos projetistas. Observamos ainda que tudo o que o
usurio vai realizar diretamente na interface est representado no ltimo nvel da
estrutura hierrquica, em geral por operadores. Uma tarefa realizada apenas
indiretamente, com a realizao dos operadores que a compem. Para fazer a distino
entre tarefa e operador, podemos tentar formular a atividade do usurio da seguinte
maneira: Para realizar/atingir A, preciso fazer X, Y e Z. Caso X, Y e Z sejam
necessariamente descritos em termos de elementos de interao e de interface, A pode
ser considerado um operador.
Considere um sistema que permita ao professor buscar uma apresentao existente,
para ajud-lo a preparar o material didtico da sua disciplina atual. Na Figura 7.4, Buscar
apresentao o objetivo, Definir busca uma tarefa, e Efetuar busca um operador.
FIGURA 7.4 Modelo hierrquico de tarefas adaptado.

As tarefas e os operadores podem ser organizados nos seguintes tipos de estruturas:


sequenciais, independentes de ordem, alternativas, iterativas e ubquas. Alm disso, uma
tarefa pode ser representada como opcional (Figura 7.5).

FIGURA 7.5 Representao de estrutura de tarefa (a) sequencial, (b) independente de ordem, (c) alternativa, (d)
iterativa, (e) ubqua e (f) opcional.

Em uma estrutura sequencial, existe uma ordem em que as tarefas devem


necessariamente ser efetuadas pelo usurio. As tarefas, nessa estrutura, so
representadas por retngulos contendo o nome da tarefa e um nmero indicando sua
posio na sequncia (Figura 7.5a). Vale observar que o nome da tarefa deve ser expresso
do ponto de vista do usurio. Por exemplo, uma tarefa em que o usurio examina os
resultados da busca apresentados pelo sistema deve se chamar Examinar resultados e
no Apresentar resultados.
Algumas tarefas podem ser realizadas em qualquer ordem. Uma estrutura de tarefas
independente de ordem representa um conjunto (e no uma sequncia) de tarefas a
serem efetuadas pelo usurio. Geralmente, o projetista sugere uma ordem de execu-o,
mas o usurio quem determina, de fato, em que ordem as tarefas sero efetuadas.
Nesse tipo de estrutura, as tarefas so representadas como as tarefas sequenciais, mas,
como a ordem apenas sugerida pelo designer, inclumos um ponto de interrogao aps o
nmero que indica a posio sugerida da tarefa na estrutura(Figura 7.5b). No exemplo da
Figura 7.4, identificamos como independentes de ordem os operadores Escolher critrio e
Informar valor para o critrio. Percebemos ainda que o designer sugere que seja essa a
ordem de realizao dessas tarefas, mas no a impe.
Para o alcance de um objetivo, h momentos em que diversos cursos de ao so
possveis. Tais cursos de ao so representados por uma estrutura alternativa, em que o
usurio dever selecionar qual das tarefas da estrutura ser efetuada, conforme a
estratgia que queira adotar. Nessa estrutura, utilizamos pequenos crculos no canto
superior direito do retngulo de cada tarefa alternativa e letras como identificadores em
vez de nmeros (Figura 7.5c). No exemplo da Figura 7.4, identificamos como alternativas
as formas de busca: Busca simples ou Busca avanada.
Quando uma tarefa pode ser realizada diversas vezes, utilizamos uma estrutura
iterativa. Um asterisco (*) no canto superior direito do retngulo usado para indicar a
iterao (Figura 7.5d). No exemplo da Figura 7.4, a tarefa Definir critrios iterativa.
Geralmente, uma tarefa iterativa representa tarefas que podem ser efetuadas uma ou
mais vezes. Caso seja necessrio definir um nmero mnimo ou mximo de repeties,
podemos incluir, acima do retngulo e alinhada direita, uma expresso que indica a
cardinalidade da iterao. A expresso [n+] indica que a tarefa deve ser realizada pelo
menos n vezes; [m..n] indica que a tarefa deve ser realizada no mnimo m e no mximo n
vezes.
Quando o usurio pode realizar uma tarefa a partir de qualquer momento da interao
para atingir o objetivo desejado, ela dita ubqua, e representada por um retngulo
com crculo cheio, ligado aresta que liga o objetivo de mais alto nvel aos seus
descendentes (Figura 7.5e). Finalmente, quando o usurio pode optar por realizar ou no
uma tarefa, ela dita opcional, e representada com uma borda tracejada (Figura 7.5f). No
exemplo da Figura 7.4, o operador Escolher tipo de busca opcional, possivelmente
indicando que deve haver um tipo default de busca (e.g., busca simples).
Podemos representar tambm, associados a cada tarefa, os signos e as rupturas na
conversa entre o preposto do designer e o usurio que possam ocorrer durante a
realizao da tarefa. Por exemplo, na tarefa iterativa Definir critrios da busca avanada,
podemos representar o seguinte conjunto de signos e mecanismos de preveno e
tratamento de rupturas comunicativas:
Nesse caso, a interface fornecer instrues sobre a obrigatoriedade de o usurio
informar pelo menos um critrio e um valor (PP). No entanto, o usurio pode tentar
realizar a busca sem definir um critrio e um valor. Isso causar uma ruptura, que ser
tratada atravs de um mecanismo de recuperao apoiada (RA).
Uma soluo alternativa consiste em impedir que o usurio consiga concluir a tarefa
sem que as restries sejam respeitadas. Nesse caso, existe uma forma de preveno ativa
(PA), associada ao signo que representa a operao propriamente dita, no caso, buscar.
Isso poderia ser representado da seguinte maneira:

Essa preveno ativa pode ser concretizada, por exemplo, desabilitando o boto ou
outro elemento de interface utilizado para acionar a busca. importante destacar que,
quando oferecemos um mecanismo de preveno ativa, devemos deixar muito claro o
motivo de uma determinada ao no estar disponvel, e o que o usurio pode fazer para
torn-la disponvel. Em outras palavras, sempre que houver uma preveno ativa
associada a um signo de operao, deve haver tambm alguma forma de preveno
passiva associada a esse signo, indicado na tabela por PP+PA.
Em geral, no modelamos as tarefas relacionadas a todos os objetivos do sistema. A
modelagem de tarefas se destina principalmente a explorar tarefas com estruturas mais
complexas do que a do exemplo apresentado nesta seo. Para muitos sistemas, os
designers passam diretamente da definio do mapa de objetivos para a modelagem da
interao, descrita a seguir.

7.3.5 Modelagem Da Interao


Paula, Silva e Barbosa propuseram, no mbito da engenharia semitica, uma linguagem
para a modelagem da interao humano-computador como uma conversa, denominada
MoLIC (Modeling Language for Interaction as Conversation Paula, 2003; Barbosa e Paula,
2003; Silva, 2005). A MoLIC foi projetada para apoiar os designers no planejamento da
interao, motivando sua reflexo sobre as estratgias de realizao de atividades e
resoluo de proble-mas dos usurios que deveriam ser apoiadas pelo sistema interativo.
A MoLIC permite representar a interao humano-computador como o conjunto de
conversas que os usurios podem (ou devem) travar com o preposto do designer para
atingir seus objetivos. Nessas conver-sas, o preposto do designer precisa comunicar
adequadamente aos usurios: o que o sistema fez (ou no fez), o que est fazendo (ou
no est fazendo), o que ele permite ou probe os usurios de fazer, como e por qu. Essa
comunicao particularmente importante quando uma situao inesperada ocorre,
como uma ruptura na comunicao. A MoLIC foi projetada de modo a ser no apenas
uma notao para especificar a interao, mas tambm como uma ferramenta epist-
mica, ou seja, para aumentar a compreenso dos designers sobre o problema sendo
resolvido e o artefato sendo projetado. importante observar que a MoLIC foi proposta
para uso humano e, portanto, no representa um mo-delo formal processvel por
computador.
A elaborao de um diagrama MoLIC parte geralmente da definio dos perfis de
usurios ou personas, dos objetivos dos usurios, dos cenrios de anlise e/ou interao e
dos signos mencionados nos cenrios. O diagrama de interao representa como os
objetivos podero ser atingidos durante a interao. Assim como cenrios e modelos de
tarefas, o diagrama de interao MoLIC serve como ponte entre a definio dos objetivos
dos usurios (veja Seo 7.3.1) e o projeto da interface propriamente dita (veja Seo
7.4.3). Diferentemente das outras representaes, a MoLIC foi concebida para motivar os
designers a refletir sobre a metacomunicao, incentivando-lhes a decidir como lidar com
as rupturas de comunicao, a explorar conversas alternativas para o atingimento de um
mesmo objetivo e a analisar o relacionamento e interferncias entre objetivos (e,
portanto, especificar as conversas relativas a objetivos instrumentais diretos). A
representao diagramtica promove uma viso global do sistema tal como o preposto
vai apresent-lo ao usurio. Alm disso, ajuda o designer a verificar a consistncia na
interao sendo projetada e a identificar oportunidades de simplificao da interao.
Deve haver um diagrama MoLIC para cada papel de usurio. Cada diagrama
representa a viso completa que um usurio poder ter do sistema. Para o usurio atingir
um objetivo, ele deve conversar com o preposto do designer sobre o que deseja
realizar (e a forma como o preposto permite/recomenda/requer que ele o faa).
importante observar que essa perspectiva comunicativa no implica que a interface de
usurio concreta ser uma interface no estilo conversacional. Significa apenas que as
questes comunicativas envolvidas na interao usuriosistema so trazidas para o
primeiro plano e tornadas explcitas durante o design da interao.
A construo de diagramas MoLIC realizada em duas etapas. Primeiro, os designers
definem os tpicos de todas as possveis conversas usuriosistema e as trocas de turno
entre o usurio e o preposto do designer que encadearo os tpicos dessas conversas.
Esse nvel de abstrao encoraja reflexes, anlises e discusses sobre a interao por
uma equipe multidisciplinar cedo no processo de design (Paula et al., 2005). Em seguida,
os tpicos so detalhados, e os designers definem os dilogos e signos envolvidos nas
trocas comunicativas que correspondem a cada tpico. O diagrama MoLIC detalhado
um recurso importante para o projeto da interface de usurio concreta nas etapas
posteriores do processo de desenvolvimento.

Definio da Estrutura da Conversa: Tpicos e Mudanas de Tpico


Na primeira etapa da construo de um diagrama MoLIC, os designers refletem sobre as
seguintes questes:
tpicos das conversas (troca de turnos entre usurio e preposto do designer) em
direo a um objetivo;
conversas alternativas em direo a um mesmo objetivo, possivelmente endereando
as necessidades e preferncias de diferentes perfis de usurios;
mudanas de tpico relativas a objetivos instrumentais diretos;
conversas para a recuperao de rupturas, i.e., mecanismos para os usurios se
recuperarem de problemas na comunicao com o preposto do usurio;
a consistncia entre caminhos de interao semelhantes ou anlogos.
Podemos partir de uma viso simplificada, em que cada objetivo de usurio (Figura
7.2) mapeado para um tpico de uma cena, conforme ilustrado pelos diagramas parciais
de interao do professor e do aluno apresentados na Figura 7.6.

FIGURA 7.6 Diagramas parciais de interao do professor e do aluno, cujos tpicos foram extrados do mapa de
objetivos.

As cenas representam conversas sobre um determinado tpico, culminando na vez de


o usurio dizer algo para concluir a conversa, suspend-la, desviar do tpico ou mesmo
abandon-la. Uma cena pode ser vista como uma cena real em uma pea teatral, em que
ocorrem as trocas comunicativas entre usurio e preposto do designer. Uma cena
representada por um retngulo com bordas arredondadas.
O tpico de uma cena pode ser lido, do ponto de vista do preposto, como: Neste
momento, voc (usurio) pode (ou deve) <tpico>. No momento, no h uma
diferenciao, na representao dos tpicos, entre voc pode X, voc deve X ou eu
recomendo que voc X.1
Na MoLIC, as mudanas de tpico so representadas por falas de transio, sejam do
usurio ou do preposto. Uma fala de transio representada por uma linha direcionada,
indicando pelo menos o enunciador da fala (u: para usurio e d: para o preposto do
designer) e o seu contedo. Desse modo, as setas da Figura 7.6 precisam ser rotuladas
para indicar as mudanas de tpico. A Figura 7.7 apresenta apenas o diagrama do aluno,
j com as falas de transio do usurio.

FIGURA 7.7 Diagrama (parcial) de interao do aluno com falas de transio de usurio.

Podemos observar que s faz sentido para um aluno consultar a nota de uma atividade
caso ela j tenha sido lanada pelo professor. Sendo assim, as falas de transio para a
cena Consultar notas possuem, alm do rtulo que identifica a fala, uma expresso
precedida da palavrachave precond. Essa expresso define uma precondio para que o
usurio possa emitir a fala correspondente. Isso significa que, quando um aluno estiver
consultando uma atividade entregue, caso a nota correspondente ainda no tenha sido
lanada pelo professor, ele no poder emitir a fala u: nota. Uma precondio pode ser
concretizada, na interface, por um link ou boto desabilitado, ou at mesmo pela
ausncia de um elemento com essa funo. Isso evita que o aluno siga um link ou
pressione um boto acreditando que sua nota j esteja disponvel, apenas para receber
uma mensagem de que a nota ainda no foi lanada.
A Figura 7.7 representa apenas mudanas de alguns tpicos para outros tpicos
relacionados, atravs das falas de transio entre cenas. Alm disso, o usurio deve ter a
possibilidade de iniciar uma nova conversa em direo a um novo objetivo, seja ele
representado por uma cena com tpico relacionado ao tpico da cena atual, ou no. Para
isso, utilizamos acessos ubquos, que representam o incio de uma conversa em direo a
um objetivo, e cujas falas de transio podem ser emitidas em qualquer momento
durante a interao.
Os acessos ubquos so representados por uma cena annima de fundo cinza mais a
fala de transio do usurio para a cena de destino, conforme ilustrado pela Figura 7.8.
FIGURA 7.8 Diagrama (parcial) de interao do aluno, incluindo os acessos ubquos.

At agora, no definimos quais so os pontos de abertura da conversa usurio


preposto, ou seja, no definimos em quais cenas pode comear a interao quando o
usurio entra no sistema. Em sistemas multiusurios, geralmente a conversa se inicia
com uma cena de login, que, por sua vez, costuma levar o usurio identificado a uma
cena semelhante a uma homepage, com um quadro resumido com informaes
relevantes e recentes, indicando tambm os objetivos que o usurio pode atingir com o
sistema. Analogamente, no definimos o ponto de encerramento, ou seja, o que ocorre
quando o usurio sai do sistema. Pontos de abertura so representados por crculos
preenchidos na cor preta, e pontos de encerramento por um crculo na cor preta
circunscrito a um crculo branco, conforme ilustrado pela Figura 7.9.

FIGURA 7.9 Diagrama (parcial) de interao do aluno, incluindo os pontos de abertura e encerramento da
conversa usuriopreposto.

Na maioria dos ambientes, a conversa se inicia no momento em que o sistema


ativado atravs do sistema operacional. Em um navegador, no momento em que uma
URL vlida digitada ou um link seguido para a aplicao Web. Em sistemas baseados
em documentos, por outro lado, geralmente h dois pontos de abertura: um acessado
ativando-se o sistema, e outro acessado quando um documento produzido por aquele
sistema ativado. Em cada caso, a conversa pode iniciar de forma diferente: abrindo um
documento em branco ou o documento acessado. A Figura 7.10 ilustra dois pontos de
abertura em um editor de apresentaes (slides).
FIGURA 7.10 Pontos de abertura da conversa global usuriopreposto em um editor de apresentaes
(diagrama parcial).

Nessa figura, vemos que o usurio pode iniciar a conversa global do sistema
solicitando ao sistema operacional que abra o editor (atravs da fala de usurio u: editor
de slides) ou que abra uma apresentao especfica (atravs da fala de usurio u:
apresentao A).
Nem sempre uma fala de transio do usurio o leva diretamente para a cena de
destino. Em alguns momentos da interao h uma troca de turno, em que o preposto do
designer deve interpretar (i.e., processar) o que o usurio disse e responder
adequadamente. Dois elementos da MoLIC so utilizados para indicar a troca de turno e
a resposta do preposto: um processo de sistema e uma fala de transio (ou fala de troca
de turnos).
Um processo de sistema representado para indicar a vez de o sistema interpretar o
que o usurio disse e decidir como a conversa ir prosseguir, ou seja, qual ser o prximo
tpico da conversa. Enquanto o sistema est pensando, o usurio no sabe o que est
ocorrendo, a menos que o preposto lhe mantenha informado, durante e/ou aps o
processamento. A representao desse elemento visa motivar os designers a pensarem a
respeito de como melhor comunicar aos usurios sobre o progresso e os resultados do
processamento do sistema, sobre para onde a conversa vai dali e por qu. Um processo
de sistema representado num diagrama MoLIC por uma caixa preta (quadrado com
fundo preto). Essa representao foi escolhida para reforar o fato de que os usurios no
podem olhar para dentro da caixa para saber o que est acontecendo durante o
processamento. Eles realmente precisam aprender isso pelas falas do preposto do
designer, que precisam ser cuidadosamente projetadas como a nica forma de comunicar
ao usurio o que aconteceu (ou est acontecendo durante o processamento), como e por
qu. A Figura 7.11 apresenta um processo do sistema quando a fala do usurio u: iniciar
busca passa o turno para o preposto do designer processar sua solicitao.
FIGURA 7.11 Processo do sistema e comunicao consecutiva e sncrona.

Existem duas formas de comunicao do preposto para o usurio sobre um


processamento: consecutiva, logo aps o processamento, e sncrona, durante o
processamento. Uma comunicao consecutiva representada como uma fala de
transio do preposto para uma cena, e rotulada como d: resposta, conforme ilustrado
na Figura 7.11 para o resultado d: n itens encontrados. Essa comunicao poder ser
concretizada na interface de diferentes maneiras, por exemplo: como uma tela de
mensagem independente, ou como um ou mais signos na tela correspondente cena de
destino (veja Seo 7.4.3). J uma comunicao sncrona projetada para comunicar ao
usurio o progresso do processamento ou seus estados intermedirios. utilizada
geralmente em processos longos, como, por exemplo, durante o download de um
arquivo, um clculo cientfico complexo ou a realizao de uma busca em uma base de
dados muito grande. Nesses casos, o preposto do designer pode emitir diversas falas
durante o processamento. Para representar esse tipo de comunicao, utilizamos uma
cena acoplada caixa preta por um canal de comunicao, que pode apresentar falas do
designer sincronizadas com o processamento do sistema e sobre ele. Esse o caso da
cena Examinar progresso de busca, acoplada ao processo do sistema na figura.
importante assegurar que a comunicao sobre um processamento seja uma
indicao correta do estado ou resultado desse processamento. Isso significa que deve
haver uma relao causal entre o contedo que est sendo comunicado e a semntica do
processamento. Alm disso, ao informar o usurio sobre o progresso de um
processamento em andamento, o designer agora deve ser capaz de oferecer a ele algum
controle sobre esse processamento, tal como suspend-lo, cancel-lo ou ajust-lo.
Portanto, pode haver falas de transio de usurio saindo da cena acoplada ao
processamento, como ilustrado na figura.
Podemos observar, ainda na Figura 7.11, que a fala do usurio u: cancelar est
tracejada. Trata-se de uma fala de recuperao de ruptura comunicativa ou breakdown.
Esse tipo de fala representa uma oportunidade explicitamente projetada pelo designer
para o usurio se recuperar de uma conversa acidental (no intencional) ou de uma
conversa que no tomou o rumo esperado. Quando emitida pelo usurio, a fala de
recuperao de ruptura indica um momento em que o usurio pode mudar de ideia e,
consequentemente, o rumo da conversa. Na figura, u:cancelar indica que o usurio pode
abandonar a busca durante seu processamento, por exemplo, ao perceber que est
demorando mais do que ele esperava.
Quando a fala de recuperao de ruptura emitida pelo preposto do designer, ela
indica que o preposto no conseguiu interpretar uma ou mais falas do usurio
adequadamente e necessrio que o usurio as retifique. Considerando ainda o exemplo
da busca, a Figura 7.11 apresenta uma fala de recuperao de ruptura emitida pelo
preposto: d: nenhum item encontrado com o critrio fornecido. Essa fala representa uma
conversa de recuperao para que o usurio possa retomar uma conversa produtiva em
direo ao seu objetivo, tal como presumido pelo designer. Caso, na interpretao do
designer, um dos possveis objetivos da busca seja justamente se certificar de que um
material didtico no foi cadastrado, observe que essa fala de transio no seria
considerada uma fala para recuperao de ruptura e seria representada por uma linha
slida.
Devemos representar um processo do sistema somente quando seu resultado puder
causar uma mudana no rumo da conversa, ou quando for necessrio que o preposto do
designer notifique o usurio sobre o progresso ou resultado desse processamento. Sendo
assim, desnecessrio representar um processo do sistema aps uma fala de transio
do usurio que sempre resulte na mudana de tpico esperada. Na Figura 7.11, a fala u:
editar material X, a partir da cena Examinar lista de material, sempre muda o tpico da
conversa para a cena Editar material e, portanto, no precisa ser intermediada por um
processo do sistema.
Ao devolver o turno para o usurio, o preposto pode lev-lo a uma nova cena ou de
volta cena da qual foi emitida a fala de transio do usurio. Quando o designer deseja
apenas comunicar o resultado do processamento do sistema, sem introduzir um novo
tpico, ele pode levar o usurio para uma cena cujo tpico representado apenas por
, indicando que a cena corresponde a uma resposta que conclui a conversa sobre o
tpico da cena precedente. A Figura 7.12 ilustra dois designs de interao alternativos
para o processo de inscrio em um Web site.
FIGURA 7.12 Resposta do preposto do designer sobre um processamento, a) sem mudana de tpico; b) com
mudana de tpico.

Na Figura 7.12a, aps solicitar sua inscrio, o usurio levado a uma cena com o
tpico , na qual o preposto lhe comunica que deve aguardar um e-mail do
administrador do sistema confirmando sua inscrio. A partir dessa cena, o usurio pode
ir para a cena de Efetuar login (atravs da fala u:login), se quiser. J na Figura 7.12b, o
preposto comunica ao usurio que ele deve aguardar e-mail do administrador e o leva
diretamente para a cena Efetuar login.
Algumas falas de usurio so rotuladas como u:_. Essa notao indica que a fala
corresponde ao tpico da cena de destino. Por exemplo, a fala que leva o usurio cena
Solicitar inscrio pode ser representada por u: solicitar inscrio ou por u:_. No se trata
apenas de uma convenincia sinttica, mas tambm um lembrete de que deve haver
correspondncia entre as falas do usurio e os tpicos da cena. Por exemplo, em um
mapeamento desse diagrama de interao para uma interface Web, um link solicitar
inscrio (correspondente fala u:_) levaria a uma pgina intitulada Solicitar inscrio ou
Solicitando inscrio (correspondente cena Solicitar inscrio). Essa pgina no deveria
ser intitulada Efetuar cadastro, Abrir conta ou algo semelhante.
Alm disso, algumas falas so marcadas como u: OK. Isso no significa que v haver
um boto com rtulo OK na interface. Trata-se apenas de uma conveno para indicar
que o usurio deseja concluir seu objetivo, tal como indicado pelo tpico da cena de
origem dessa fala. Analogamente, possvel utilizar d: OK para representar que a
interpretao do designer conseguiu produzir o efeito desejado pelo usurio tal como
expresso pela sua fala.
Como visto na Seo 7.3.3, existem situaes que o designer identifica como sendo
rupturas em potencial, mas cujo diagnstico final deve ser feito pelo usurio. Cabe ao
preposto descrever adequadamente a situao e solicitar que o usurio tome uma deciso
informada sobre os rumos da interao, no mecanismo de preveno denominado alerta
(AL). Uma cena de alerta representada com uma linha tracejada, conforme ilustrado na
Figura 7.13. Uma cena de captura de erro tambm representada com uma linha
tracejada, mas no requer que o preposto do designer projete, a partir dela, uma fala de
transio para recuperao da ruptura, pois geralmente o sistema no poder ajudar o
usurio a se recuperar dessa ruptura.

FIGURA 7.13 Alerta de sobreposio de arquivo existente.

Como natural e frequente que malentendidos ocorram numa conversa, a engenharia


semitica destaca a importncia de representar as rupturas comunicativas que podem
ocorrer durante a interao. neces-srio definir a forma como o preposto ir comunicar
ao usurio que uma ruptura ocorreu e apoi-lo na recuperao do problema, i.e., como o
usurio dever prosseguir com a conversa para atingir seus objetivos. No diagrama de
interao, representamos o mecanismo de recuperao apoiada atravs de falas de
transio para recuperao de ruptura, e os mecanismos de alerta e captura de erro como
cenas tracejadas. J os mecanismos de preveno passiva e ativa so representados
apenas no esquema conceitual de signos (veja Seo 7.3.2) e no detalhamento dos
dilogos (visto na prxima seo).
medida que o designer avana na modelagem da interao, podem surgir
inconsistncias na forma como o usurio poder interagir com o sistema para alcanar
objetivos semelhantes. Por exemplo, considere as conversas para postar avisos, cadastrar
um material didtico e cadastrar uma atividade projetadas conforme a Figura 7.14.
FIGURA 7.14 Diferentes tipos de conversa para o cadastramento de aviso, material didtico e atividade.

Podemos observar trs formas de diferentes de cadastrar algo no sistema:


no caso de Postar aviso, o preposto grava os dados sem pedir confirmao e leva o
usurio para a cena em que ele estava antes de postar o aviso. Isso dificulta a
verificao do aviso postado;
no caso de Cadastrar material, o preposto solicita a confirmao do usurio antes de
efetuar o cadastramento propriamente dito. Isso facilita a verificao do material
cadastrado e evita que a base de dados contenha momentaneamente informaes
incorretas. No entanto, possvel que o usurio, dependendo da sua experincia com
sistemas semelhantes, acredite que o cadastro j tenha sido efetuado e acabe no
efetuando a confirmao;
no caso de Cadastrar atividade, o preposto no pede confirmao, grava os dados e leva
o usurio para a cena em que ele pode examinar o que acabou de cadastrar e, se
necessrio, a partir da qual ele pode iniciar uma conversa para alter-los. Diferentes
conversas para alcanar objetivos semelhantes em um mesmo sistema podem
confundir o usurio, que ter dificuldade em se lembrar qual tipo de conversa foi
projetado para o cadastro de qual tipo de informao. Existem casos em que a
diferena intencional, por exemplo, o designer quer solicitar a confirmao prvia
apenas para dados crticos. No entanto, essa deciso deve ser tomada de forma
deliberada, e no incidental. Os diagramas MoLIC ajudam a identificar esse tipo de
inconsistncia e promovem uma reflexo e tomada de deciso de design mais
informada.
Para facilitar o entendimento e aumentar a consistncia da conversa, podemos
padronizar os verbos utilizados nos tpicos das cenas, como, por exemplo: buscar, ver
(lista de), examinar (detalhes de), analisar, comparar, cadastrar (ou criar ou postar),
alterar, remover, confirmar e controlar (Gonzlez-Calleros et al., 2009). Dependendo do
domnio do sistema, um conjunto distinto de verbos pode ser utilizado. Cabe ao designer
manter esse vocabulrio controlado, considerando, naturalmente, o vocabulrio utilizado
pelos usurios, incluindo sinnimos e destacando eventuais diferenas sutis, sempre que
necessrio. Por exemplo, do ponto de vista do sistema, cadastrar e postar podem ser
considerados sinnimos, pois ambos envolvem criar uma nova instncia de uma
entidade. Do ponto de vista do usurio, no entanto, ele no cadastra um aviso, mas sim
posta um aviso. Cabe ao designer decidir o quanto essas semelhanas e diferenas na
terminologia utilizada pelos usurios devem se refletir em consistncia ou quebra de
consistncia na interao e, posteriormente, na interface com o usurio.

Detalhamento dos Dilogos e Falas


Na segunda etapa da construo de um diagrama MoLIC, os designers detalham a
conversa sobre cada tpico, especificando os dilogos, as falas e os signos de cada cena.
Como visto no incio desta seo, a conversa sobre um tpico pode ser composta por
diversos dilogos, que, por sua vez, so compostos por falas sobre signos. Considerando
a cena Entregar trabalho, no diagrama de interao do aluno, podemos identificar os
seguintes dilogos: ver turma (dados de contexto), ver enunciado e informar dados do
trabalho. Alm disso, caso o trabalho deva ser feito em grupo, tambm temos o dilogo
informar integrantes do grupo. Os dilogos so representados num segundo
compartimento da cena (Figura 7.15). Em geral, so enunciados na forma verbo + objeto,
em que o objeto costuma ser um signo-entidade ou signo-atributo do domnio.

FIGURA 7.15 Cena com dilogos.

Podemos observar, na Figura 7.15, o uso da palavra-chave precond, indicando a


precondio que deve ser satisfeita para que preposto e usurio possam travar o dilogo
correspondente.
Assim como ocorre nos tpicos das cenas, para facilitar o entendimento e aumentar a
consistncia dos dilogos, podemos padronizar os verbos utilizados nos dilogos do
sistema, agora com granularidade mais fina. Podemos utilizar, por exemplo, o seguinte
conjunto: ver, comparar, informar, selecionar, filtrar, ordenar, acrescentar, remover, ativar,
desativar, iniciar, pausar, retomar, parar e abortar (Gonzlez-Calleros et al., 2009). Cabe ao
designer estabelecer o conjunto de verbos relevantes ao domnio, e decidir como eles
sero concretizados na interface. Por exemplo, em interfaces que no sejam grficas, no
faz sentido ver algo. Nesse caso, o dilogo ver turma poderia ser substitudo por algo
como conferir dados da turma.
Existem casos em que os dilogos podem ser compostos de outros dilogos, segundo
uma determinada estrutura. Caso haja dependncia entre dilogos, e eles precisem ser
travados em uma determinada ordem, podemos utilizar a palavra-chave SEQ, como a
seguir:
SEQ {
selecionar estado
selecionar cidade
}
J um dilogo para informar os dados de contato de um usurio poderia ser
estruturado da seguinte forma:
informar dados para contato {
d+u: forma de contato (e-mail, telefone ou correspondncia)
XOR {
informar e-mail (se forma de contato = e-mail)
informar telefone (se forma de contato = telefone)
informar endereo (se forma de contato = correspondncia)
}}
Nesse caso, a palavra-chave XOR indica que apenas um dos dilogos da estrutura pode
ser travado pelo usurio e preposto. Caso a palavra-chave utilizada seja OR, um ou mais
dilogos podem ser travados. E, caso a palavra-chave utilizada seja AND, todos os
dilogos devem ser travados. Como a MoLIC uma linguagem para processamento
humano, outros casos podem ser indicados por comentrios, como, por exemplo, a
restrio de que ao menos uma forma de contato precisa ser informada:
informar dados para contato {
d+u: forma de contato preferencial (e-mail, telefone ou correspondncia)
OR (pelo menos uma forma de contato precisa ser informada) {
informar e-mail
informar telefone
informar endereo
}}
A partir da definio dos dilogos, podemos detalhar os signos envolvidos em cada
dilogo (Figura 7.16). Caso um signo seja emitido apenas pelo preposto do designer, ele
precedido por d:. Caso seja emitido por ambos, preposto do designer e usurio (ou seja,
caso o designer d oportunidade para o usurio falar sobre o signo), o signo precedido
por d+u:.
FIGURA 7.16 Cena com dilogos e signos.

Podemos observar que nem tudo o que est representado como dilogo se desdobra,
durante a interao, em uma conversa entre os dois interlocutores (usurio e preposto do
designer) sobre determinado subtpico. No dilogo ver turma, por exemplo, apenas o
designer emite uma ou mais falas sobre os signos disciplina e turma. O mesmo ocorre
com o dilogo ver enunciado. J no dilogo informar dados do trabalho, ambos
interlocutores falam sobre o subtpico: o preposto solicita ao usurio falar sobre um dos
signos (ou ambos), arquivo ou link, e o usurio assim o faz. Finalmente, no dilogo
informar integrantes do grupo, h uma parte em que ocorre um monlogo, na qual o
preposto do designer emite falas sobre os alunos j cadastrados como integrantes do
grupo (assumindo que o grupo j tenha sido definido anteriormente), tal como
identificado pela expresso d: lista(aluno). E h outra parte do dilogo em que o usurio
pode alterar essa lista, acrescentando ou removendo alunos.
Em alguns casos, as falas de transio se referem a algum signo manipulado na cena de
origem. Por exemplo, quando um aluno v uma lista dos enunciados de trabalho da sua
turma, pode selecionar um deles para entregar o trabalho realizado. Isso
representado por uma fala de transio u: entregar trabalho T, em que T representa um
trabalho selecionado ou indicado pelo usurio. A forma como o usurio poder
selecionar ou indicar o trabalho desejado se refere a decises de design da interface
propriamente dita, em uma etapa posterior de design, quando boa parte das decises
sobre o design da interao j tiverem sido tomadas, como ser visto na prxima seo.
Em certos momentos da interao, podem ocorrer alguns dilogos que no so parte
da aplicao sendo projetada, mas sim do sistema operacional. Isso acontece, por
exemplo, quando um usurio manipula uma pgina Web utilizando uma barra de
rolamento. Nesse caso, ele no est conversando com a aplicao projetada, mas sim com
o navegador. Em geral, o designer tem pouco ou nenhum controle sobre essa interao.
Por isso, esses dilogos no costumam ser representados no diagrama de interao.
Somente nos casos em que o designer queira que seu preposto fale sobre esses
interlocutores externos que ele deve representar os dilogos e signos
correspondentes.
7.4 Design da Interface
medida que o design da interao avana, o designer passa a definir a interface
propriamente dita, a parte fsica do sistema com a qual o usurio entrar em contato. A
definio da interface inicia com a escolha dos estilos de interao do sistema, para ento
passar para a representao da interface, em diferentes nveis de abstrao.
As prximas subsees apresentam estilos de interao comumente adotados no
design de sistemas interativos, notaes utilizadas para representar a interface com
usurio e algumas estratgias utilizadas para elaborar a interface com usurio a partir do
design da interao representado atravs de diagramas MoLIC.

7.4.1 Estilos De Interao


Dentre os estilos de interao mais comumente utilizados, encontramos as linguagens de
comando, a linguagem natural e a interao por menus, por formulrios, por
manipulao direta e WIMP (Windows, Icons, Menus, and Pointers).
Em uma interao por linguagem de comando, o usurio deve digitar os comandos que
realizam as aes na aplicao. Para isso, ele precisa memorizar os comandos que precisa
utilizar. Para facilitar esse aprendizado, os comandos devem ser construdos com base no
vocabulrio dos usurios, e a gramtica da linguagem de comandos deve refletir a forma
como eles conceitualizam as operaes (Figura 7.17).

FIGURA 7.17 Exemplo de interao atravs de linguagem de comando.

Segundo Shneiderman (1998), os objetivos bsicos do design de uma linguagem de


comando so: preciso, conciso, facilidade de escrita e leitura, completude, rapidez no
aprendizado, simplicidade para reduzir erros e facilidade de reteno ao longo do tempo.
Ele enumera ainda os seguintes objetivos de alto nvel: corrrespondncia entre a
realidade e a notao, convenincia para realizar manipulaes relevantes s tarefas dos
usurios; compatibilidade com notaes existentes; flexibilidade para acomodar usurios
novatos e experientes; e expressividade para encorajar a criatividade.
Em geral, uma linguagem de comando organizada como um conjunto de comandos
simples (e.g., DIR), comandos mais parmetros (e.g., COPY origem destino) ou comandos
seguidos de opes e argumentos (e.g., COPY /V origem destino). Para facilitar o
aprendizado, os parmetros devem ser ordenados de forma consistente, as opes devem
ser representadas por palavras-chave em vez de smbolos arbitrrios, e os comandos
devem ser hierrquicos (Shneiderman, 1998).
A interao em linguagem natural visa permitir que o usurio se expresse como em
uma conversa com uma outra pessoa, utilizando seu prprio idioma. O objetivo principal
facilitar o uso de um sistema por usurios novatos. Entretanto, existem grandes
desafios para a implementao de uma interface capaz de negociar significados e
resolver ambiguidades e imprecises nas ilocues dos usurios. Em geral, os usurios
tm dificuldade para entenderem os limites do sistema, ou seja, qual o subconjunto da
linguagem natural que o sistema consegue interpretar. Alm disso, esse estilo de
interao se torna ineficiente para usurios experientes, quando comparado com a
interao por linguagem de comando.
Na interao atravs de menus, o sistema oferece um conjunto de opes dentre as
quais o usurio deve selecionar a que lhe interessa (Figura 7.18).

FIGURA 7.18 Exemplo de interao atravs de menu.

Alm de barras de menu (pulldown), barras de navegao e menus contextuais (popup),


Shneiderman tambm considera conjuntos de botes de seleo (checkboxes) e opo
(radio buttons) como formas de interao por menu (Figura 7.19), embora estejam
associados mais frequentemente com dilogos de fornecimento de informao e
formulrios na Web.
FIGURA 7.19 Exemplos de diferentes formas de menu.

Segundo Shneiderman (1998), o objetivo do design de menus criar uma organizao


razovel, inteligvel memorvel e conveniente para as tarefas dos usurios. A estrutura
das tarefas deve guiar a escolha da estrutura de menus: linear, hierrquica ou em rede;
acclica ou cclica. Muitos menus so organizados em uma estrutura hierrquica. Para
projet-los, devemos considerar a profundidade e a largura da estrutura. Shneiderman
recomenda optar por menus largos e rasos, em vez de estreitos e profundos.
Para qualquer tipo de menu, devemos decidir em que ordem as opes devem ser
apresentadas, para refletir a estrutura das tarefas ou o modelo conceitual embutido no
sistema. Alguns exemplos de ordenao so: alfabtica, cronolgica, numrica
(ascendente ou descendente), itens mais frequentes, mais recentes ou mais importantes.
Alm disso, devemos criar grupos de itens logicamente semelhantes, nos certificar de
que no h sobreposies entre os itens e utilizar terminologia familiar aos usurios.
Sobre a redao dos itens de menu, Shneiderman sugere utilizar itens curtos, iniciados
por uma palavra-chave. Como em qualquer estilo de interao, devemos utilizar
gramtica, layout e terminologia consistentes, fornecer atalhos para localizar e selecionar
um item e apresentar instrues inteligveis.
Na interao atravs de formulrio, o sistema solicita dados do usurio atravs de
campos que precisam ser preenchidos. Os formulrios comumente encontrados em Web
sites se encaixam nesse estilo de interao (Figura 7.20).
FIGURA 7.20 Exemplo de interao atravs de formulrio.

Assim como em outros estilos de interao, Shneiderman (1998) recomenda criar


grupos de itens relacionados e orden-los de forma lgica; utilizar terminologia familiar
aos usurios e consistente; fornecer atalhos para localizar e selecionar um item e
apresentar instrues inteligveis. Ele destaca ainda a importncia de fornecer um
movimento de cursor conveniente para navegao entre os campos do formulrio, ou
seja, que corresponda direo natural de leitura dos usurios.
Formulrios apresentam desafios interessantes para preveno e recuperao de erros
de preenchimento. Wroblewski (2008) explora diversos aspectos de formulrios na Web
atravs da comparao entre designs alternativos. Ele destaca tambm a importncia de
considerar o contexto mais amplo do formulrio (pblico-alvo, aplicao, negcio), ou
seja, informaes sobre como o formulrio ser utilizado.
O estilo de interao por manipulao direta foi proposto com o objetivo de aproximar
a interao da manipulao dos objetos no mundo real (Shneiderman, 1998).
necessrio, para isso, que um objeto do mundo real tenha uma representao visual na
interface e que cada manipulao sobre um objeto possa ser mapeada nas operaes do
mouse, como clique, duplo clique e clique-e-arrasto (Figura 7.21).
FIGURA 7.21 Exemplo de interao atravs de manipulao direta.

Em uma interao por manipulao direta, as aes devem ser rpidas, incrementais e
reversveis. Os resultados das aes devem ser imediatamente apresentados. Os
benefcios desse estilo sobre a linguagem de comando so: reduo das taxas de erro;
aprendizado mais rpido; aumento na reteno (memorizao) das operaes; e
engajamento e motivao para explorar o sistema.
Entretanto, uma interface por manipulao direta traz dificuldades para usurios com
deficincia visual ou motora. Alm disso, medida que o nmero de objetos e aes
aumenta, a interao se torna mais complexa e de difcil aprendizado e execuo (e.g.,
pressionamento simultneo de teclas do mouse e do teclado, enquanto um objeto visual
arrastado para seu destino).
Um mesmo sistema com frequncia utiliza vrios estilos em diferentes partes da
interface, como o caso do WIMP (Windows, Icons, Menus, and Pointers Janelas, cones,
Menus e Apontadores/Cursores), adotado nos ambientes baseados em janelas (Figura
7.22). Eles visam aproveitar os benefcios e contornar as limitaes de cada estilo de
interao individual.
FIGURA 7.22 Exemplo de interao WIMP.

Recentemente vm surgindo diversos outros estilos de interao, tais como: interao


em 3D, com realidade virtual e aumentada; e interao com caneta, toque, multitoque e
gestos. Consequentemente, estudos vm sendo realizados para definir novos princpios e
diretrizes especficos para esses estilos.

7.4.2 Representaes Da Interface Com Usurio


Uma interface pode ser representada informalmente atravs de esboos, de forma
estruturada atravs de modelos ou at mesmo atravs de prottipos funcionais. O design
da interface pode ser realizado em diferentes nveis de abstrao: da interface abstrata
at a interface concreta. Na elaborao da interface abstrata, definimos os agrupamentos
e as caractersticas dos elementos de interface, como, por exemplo, um grupo com um
texto editvel e com uma seleo simples dentre dez itens. Na elaborao de interface
concreta, definimos o posicionamento e escolhemos os elementos de interface interativos
(widgets). Nesse nvel, por exemplo, decidimos entre representar uma determinada
entrada de dados como uma caixa de lista ou uma lista do tipo dropdown.
Alguns modelos utilizados para o registro da interface so representados atravs de
linguagens de descrio de interfaces com usurio (UIDL user interface description
languages). Exemplos de UIDL so UIML2, UsiXML3 e XAML.4 Outros modelos so
grficos, como os prottipos cannicos abstratos (Constantine e Lockwood, 1999). Em
uma abordagem informal, o design da interface costuma ser representado em esboos
(Buxton, 2007), wireframes e prottipos, que vo sendo refinados sucessivamente ao longo
do processo.
Essas representaes podem ser classificadas com relao ao seu grau de fidelidade.
Uma representao dita de baixa fidelidade quando se trata de um rascunho ou esboo
da interface, sem muita preocupao com detalhes dos aspectos grficos. Pode ser feita
manualmente (Figura 7.23) ou utilizando ferramentas computacionais, como a Balsamiq
Mockups5 (Figura 7.24). J uma representao de alta fidelidade apresenta o desenho
completo da interface, possivelmente feito em um editor de imagens, em que j esto
incorporadas as decises a respeito de tamanhos, posies, cores, fontes e outros
detalhes visuais de cada elemento (Figura 7.25).

FIGURA 7.23 Representao de uma interface em baixa fidelidade.

FIGURA 7.24 Representao de uma interface em baixa fidelidade elaborada com apoio de ferramenta
computacional.
FIGURA 7.25 Representao de uma interface em alta fidelidade.

Com frequncia, as representaes de design de interface so denominadas prottipos.


Outra classificao comumente utilizada diz respeito ao grau de funcionalidade
embutida nesses prottipos: desde wireframes ou maquetes, que apresentam apenas os
signos estticos e metalingusticos da interface, em diferentes nveis de detalhe, at
prottipos funcionais, que incluem tambm os signos dinmicos.
As atividades realizadas ao longo de todo o processo de design e os artefatos gerados
fornecem insumos para o design da interface. A identificao dos principais objetivos e
cenrios de uso frequente permite decidir quais elementos de interface devem ser
destacados (e.g., atalhos na barra de ferramentas, itens de menu pop-up e posio de
destaque no layout da tela). Permite decidir tambm quais elementos podem ser
deslocados para posies secundrias (e.g., link de volta no canto inferior esquerdo) ou
at mesmo para telas secundrias (e.g., tela de gerenciamento de tipos de trabalho).
A atividade de anlise, as pesquisas com usurios e outras fontes de informao
auxiliam na definio do vocabulrio utilizado na interface. Caso seja usada uma
metfora para comunicar o modelo conceitual, ela tambm contribui para a construo
desse vocabulrio. importante manter um vocabulrio consistente e familiar ao usurio
a fim de tornar a comunicao com o usurio eficiente e clara.
Um desafio de design de interface enfrentado com frequncia est relacionado
experincia e ao conhecimento do usurio. comum projetar assistentes para usurios
iniciantes e telas de configurao com mltiplas opes para especialistas, como se
fossem duas interfaces distintas e muitas vezes isoladas. No entanto, segundo Cooper
(1999), a maioria dos usurios deixa de ser iniciante rapidamente, mas permanece como
usurio intermedirio indefinidamente. Os designers devem avaliar a importncia de
fazer na interface uma ponte entre as diferentes estratgias de uso do sistema, para
apoiar a curva de aprendizado do usurio at ele se tornar um especialista.
7.4.3 Da Interao Como Uma Conversa Para O Design Da
Interface
Esta seo apresenta algumas decises comumente tomadas ao projetar a interface com
usurio a partir da modelagem da interao como uma conversa representada utilizando
a MoLIC (Silva et al., 2005).
Os acessos ubquos so pontos de incio de conversas dirigidas por objetivos e, em
geral, devem estar disponveis em qualquer momento da interao, desde que
respeitadas suas precondies. Sendo assim, em geral, os acessos ubquos costumam ser
mapeados na interface em barras de navegao ou itens de menu (Figura 7.26).

FIGURA 7.26 Acessos ubquos mapeados para uma barra de navegao, considerando duas alternativas: (a)
horizontal e (b) vertical.

A interface composta de diferentes unidades de apresentao. Em uma interface


grfica, uma unidade de apresentao uma tela ou janela. J em interfaces Web, uma
pgina. Embora no haja necessariamente um mapeamento direto entre cena e unidade
de apresentao, essa estratgia bastante comum (Figura 7.27).
FIGURA 7.27 Mapeamento de uma cena para uma unidade de apresentao.

A Figura 7.28 apresenta uma alternativa de design de interface que decompe a mesma
cena em duas unidades de apresentao. Esse tipo de situao acontece com frequncia
no caso de dilogos que manipulam arquivos, como localizar um arquivo para abrilo ou
localizar um diretrio e definir um nome para salvar um arquivo. Tambm comum em
alguns dispositivos mveis com telas de tamanho reduzido.

FIGURA 7.28 Mapeamento de uma cena para duas unidades de apresentao.

Grupos de dilogos costumam ser refletidos na interface com usurio em quadros ou


contineres de outros elementos de interface, marcados visivelmente ou definidos
apenas por um grid. Cada signo, por sua vez, costuma ser representado como um
elemento de interface (widget). E, caso haja alguma preveno passiva prevista associada
a um signo, ela geralmente concretizada em uma instruo ou dica, textual ou pictrica,
apresentada prxima ao elemento correspondente, como o asterisco para indicar campos
obrigatrios.
Uma fala de transio de usurio geralmente se destina a uma mudana de tpico na
conversa, de prosseguimento da conversa para o aprofundamento do tpico em direo
ao seu objetivo, ou de concluso da conversa para verificar o alcance do objetivo. Sendo
assim, uma fala de transio do usurio geralmente mapeada em um link, boto ou
item de menu. Caso haja uma precondio associada fala, pode haver uma mudana no
estado (ativo ou inativo) ou na visibilidade (visvel ou oculto) do elemento
correspondente.
A Figura 7.29 ilustra um fragmento de diagrama de interao e diversos mapeamentos:
cena Consultar material mapeada para unidade de apresentao Materiais didticos
(indicao n 1 na figura)
dilogo ver materiais mapeado para a tabela de materiais didticos (n 2)
fala de usurio u: cadastrar novo material mapeada para link Cadastrar novo material
didtico (n 3)
fala de usurio u: editar material X mapeada para os links na tabela (n 4)
cena Editar material mapeada para duas unidades de apresentao semelhantes,
conforme a fala de transio de usurio que leva at ela:
Cadastrando novo material didtico, destino da fala u: cadastrar novo material
didtico (n 5)
Editando material didtico, destino da fala u: editar material X (n 6)
FIGURA 7.29 Dilogos e signos mapeados em elementos de interface.

Podemos observar ainda que o boto Gravar aparece desativado na unidade de


apresentao Cadastrando novo material didtico (n 7), pois os campos obrigatrios
ainda no foram preenchidos. Alm disso, a fala de transio do usurio para
recuperao de ruptura u: cancelar foi mapeada para o link Cancelar (n 8), que leva o
usurio de volta para a pgina Materiais didticos. No exemplo, as falas u: cadastrar novo
material e u: editar material X levam o usurio para uma nova pgina. Mas poderiam ter
aberto uma janela ou painel sobre a tela Materiais didticos, por exemplo. Nesse caso, a
fala u: cancelar teria como comportamento fechar essa janela.
As falas do preposto do designer se destinam a fornecer ao usurio feedback sobre o
andamento ou a concluso de um processamento do sistema, em resposta a uma
solicitao do usurio. Elas comumente so concretizadas na interface como mensagens
de erro (em particular no caso de falas de recuperao de uma ruptura comunicativa) e de
status. Essas mensagens podem ser apresentadas de pelo menos duas formas distintas:
embutidas na unidade de apresentao correspondente cena de destino (n 1) ou em
unidades de apresentao independentes (n 2), como pode ser visto na Figura 7.30, para
as falas d: material gravado e d: problema na gravao, respectivamente.
FIGURA 7.30 Falas de transio do preposto do designer mapeadas para elementos de interface.

7.4.4 Esquema Conceitual De Signos: Expresso (Parte II)


Em paralelo elaborao da interface, podemos definir as expresses de cada signo,
concluindo assim a definio do esquema de signos. A expresso de um signo define qual
elemento de interface (widget) dever ser utilizado para apresentar ao usurio ou
permitir que ele manipule o contedo do signo.
Cada signo pode apresentar uma expresso diferente, conforme o seu interlocutor e o
contexto de interao em que o signo ocorre (Tabela 7.6). Quando o interlocutor o
preposto do designer (emissor = d), o signo apresentado ao usurio atravs de
elementos de interface para sada de dados (output); ao passo que quando ambos, usurio
e preposto, falam sobre o signo (emissor = d+u), suas expresses so elementos de
interface para entrada de dados (input).
Tabela 7.6
Definio das expresses dos signos

Destacamos na tabela a possibilidade de haver mais de uma expresso para um mesmo


signo. Observamos que o signo data de entrega possui duas formas de expresso ao ser
emitido pelo preposto do designer: por default, ele apresentado pela data formatada
como dd/mm/aaaa; mas na cena de avisos, ele apresentado por uma representao em
calendrio (cena Consultar avisos: dd/mm/aaaa + calendrio). A Figura 7.31 apresenta
duas pginas que ilustram esses diferentes contextos de interao.
FIGURA 7.31 Esboos de tela de visualizao de lista de projetos e dos detalhes de um projeto final.

A tabela de expresses dos signos utilizada principalmente para assegurar a


consistncia de apresentao e manipulao dos signos. Pode haver mais do que uma
expresso associada a um signo, mas essa deciso deve ser tomada de forma cuidadosa e
consciente pelos designers do produto.
Alm disso, essa especificao auxilia a implementao da interface, fornecendo ao
programador orientaes detalhadas sobre ela. Sem isso, os programadores podem ter de
tomar algumas decises relacionadas ao design de interface, sem que tenham participado
ativamente do processo de anlise e design e, consequentemente, sem estar
adequadamente preparados para isso.
7.5 Projeto do Sistema de Ajuda6
Segundo de Souza (2005a), o poder explicativo do discurso do preposto do designer e,
portanto, sua capacidade em negociar significados, so limitados por propriedades
formais de linguagens computacionais. Uma das formas de maximizar a
comunicabilidade do discurso do preposto do designer enriquecer a forma e o
contedo do sistema de ajuda.
O sistema de ajuda na engenharia semitica uma forma de comunicao privilegiada
entre designer e usurios, uma vez que uma comunicao direta (Silveira et al., 2004;
Silveira, 2002). Portanto, fundamental que faamos o projeto do sistema de ajuda para
que o usurio possa entender melhor a soluo do designer e fazer melhor uso do
sistema, se recuperando facilmente de rupturas que porventura venham a ocorrer.
Com relao ao contedo do sistema de ajuda, podemos nos basear em compilaes das
dvidas frequentes dos usurios ao utilizarem sistemas interativos, classificadas de
acordo com o tipo de dvida (Baecker et al., 1995; Sellen e Nicol, 1990) (Tabela 7.7).

Tabela 7.7
Tipos de dvidas frequentes dos usurios

tipo de dvida exem plo de pergunta


Informativas O que posso fazer com este programa?
Descritivas O que isto? O que isto faz?
Procedimentais Como eu fao isto?
De escolha O que posso fazer agora?
Sugestivas O que devo fazer agora?
Investigativas O que mais devo fazer? Esqueci algo?
Interpretativas O que est acontecendo agora? Por que isto aconteceu?
Navegacionais Onde estou? De onde vim?
Histricas O que eu j fiz?
De motivao Por que devo usar este programa? Como ele ir me beneficiar?

Algumas dessas perguntas podem (e devem!) ser respondidas durante as etapas


iniciais de anlise e modelagem de usurios e tarefas. Alm disso, respostas a algumas
dessas perguntas podem ser extradas diretamente dos modelos j construdos, mas
outras devem ser explicitamente elaboradas pelos projetistas. Nesta seo, analisamos as
perguntas de acordo com os modelos que especificam a resposta, com os elementos do
sistema aos quais esto relacionadas ou com a etapa de desenvolvimento em que se pode
respond-las.
A pergunta informativa O que posso fazer com este programa? pode ser respondida
com os objetivos dos usurios que foram identificados nas personas, elaborados nos
cenrios e organizados no mapa de objetivos.
Questes descritivas, do tipo O que isto?, O que isto faz? e O que se faz com isto?
podem ser respondidas em dois nveis: um nvel conceitual, relacionado ao dom-nio, e
um nvel operacional, relacionado interface. O nvel conceitual pode ser descrito no
incio do processo de desenvolvimento, mas o nvel operacional s poder ser definido
junto com os modelos de interao e de interface.
As perguntas procedimentais, de escolha, sugestivas e investigativas esto vinculadas
principalmente aos modelos de tarefas e de interao. A estrutura hierrquica de uma
tarefa representa uma resposta de alto nvel pergunta Como eu fao isto? Uma resposta
mais detalhada pode ser obtida nos modelos de interao e de interface, descrevendo os
caminhos percorridos pelo usurio e os widgets ou elementos de interface que devem ser
manipulados a cada instante. Para responder a pergunta O que posso fazer agora?, o
sistema deve verificar em que cena o usurio se encontra e quais precondies esto
satisfeitas naquele momento. Por outro lado, as perguntas O que devo fazer agora?, O
que mais devo fazer? e Esqueci algo? requerem que o sistema mapeie as ltimas aes do
usurio nas conversas em direo a um ou mais objetivos, buscando identificar o objetivo
atual do usurio e o que falta para ele alcan-lo.
As perguntas interpretativas, navegacionais e histricas esto relacionadas
principalmente ao modelo de interao, que representa os caminhos que o usurio pode
seguir e que indicaes o sistema fornece sobre em que ponto da interao ele se
encontra a cada instante. A pergunta O que est acontecendo agora? est relacionada a
falas do preposto e mecanismos de feedback. J a pergunta Por que isto aconteceu? deve
ser respondida pela descrio do resultado esperado da ao que acaba de ser realizada,
juntamente com os possveis problemas que venham a ocorrer. As perguntas Onde
estou?, De onde vim? e O que eu fiz? requerem um acompanhamento do histrico de
interao do usurio.
Finalmente, as perguntas relacionadas motivao Por que devo usar este programa? e
Como ele ir me beneficiar? no podem ser derivadas diretamente dos modelos e,
portanto, precisam ser explicitamente respondidas pelos projetistas. Tais perguntas
dizem respeito ao sistema como um todo, e no a um objetivo especfico. Elas devem ser
respondidas no incio do processo de desenvolvimento, como registro da inteno de
design, e depois revisadas para verificar se todos os objetivos iniciais foram atingidos.
Com relao forma como o sistema de ajuda acessado, Silveira prope que o sistema
de ajuda seja apresentado de forma contextual, em camadas e sob demanda. O acesso ao
sistema de ajuda feito atravs de perguntas, dentre elas algumas do conjunto proposto
no mtodo de comunicabilidade (e.g., O que isto? e Cad?; veja Seo 10.2.2),
adicionado de outras especficas para o entendimento da comunicao designerusurio
(e.g., Para que serve isto? e Por que tenho que fazer isto?).
7.6 Desafios de Design de Sistemas Adaptveis e
Adaptativos
Diaper (2003) afirma que, como descries do mundo em IHC incluem pessoas em
ambientes sociais e organizacionais complexos, a previso acurada de qualquer futuro
ps-design praticamente impossvel, ao menos porque as pessoas, com frequncia, (1)
adaptam seu comportamento s mudanas projetadas; (2) alteram outros aspectos do
mundo para acomodar o que foi projetado; e (3) alteram e usam o que foi projetado de
formas que no foram previstas pelos designers. Suchman (1987) discute a natureza
situada da atividade do usurio, que no pode ser completamente prevista ou planejada a
priori. E a engenharia semitica levanta a necessidade de os designers buscarem ampliar
a competncia comunicativa do preposto do designer a fim de que os usurios faam uso
criativo do sistema, permitindo que eles customizem ou estendam o sistema, ajustando-o
ou reprojetando-o (de Souza 2005a; de Souza e Barbosa, 2006).
Para lidar com essa situao, diversas pesquisas vm sendo realizadas no sentido de
permitir aos usurios configurarem, adaptarem ou estenderem seus sistemas,
denominadas adaptveis, customizveis ou extensveis (Oppermann, 1994). Alm dos
desafios de engenharia de software envolvidos na oferta dessas possibilidades aos
usurios, h desafios importantes no projeto de IHC, como as decises sobre: quando e
como comunicar aos usurios o que pode ser modificado ou estendido; como permitir
que eles efetivamente realizem a modificao ou extenso; como comunicarlhes as
consequncias da modificao ou extenso e ajudarlhes a test-la; como restringir o que
eles podem modificar na interface para preservar a identidade do sistema (de Souza e
Barbosa, 2006).
Alm de permitir que os prprios usurios modifiquem o sistema, possvel tambm
projetar sistemas que se adaptam automaticamente ao usurio, denominados
adaptativos (Schneider-Hufschmidt et al., 1993; Cypher, 1993; Oppermann, 1994;
Lieberman, 2001). Nesse caso, necessrio tomar cuidado no apenas para comunicar
adequadamente ao usurio as mudanas realizadas, mas tambm permitir que ele
desfaa cada adaptao ou at mesmo impea que o sistema faa novas adaptaes
daquele tipo no futuro. Se possvel, esses sistemas devem aprender com o feedback do
usurio, para melhor ajustar seus mecanismos de autoadaptao.
Sistemas adaptveis e adaptativos trazem grandes desafios para todas as atividades de
IHC. Em anlise, os desafios envolvem identificar as necessidades e oportunidades de
adaptao, manual ou automtica, em diferentes contextos. Em design, envolvem
conceber e modelar solues flexveis e inteligentes de modo que os usurios possam
melhor se apropriar do sistema e estender a sua competncia comunicativa, ampliando a
gama de interpretaes que o sistema pode gerar e, consequentemente, os
comportamentos que pode apresentar. Finalmente, os desafios de avaliao se devem
inadequao, em geral, de avaliaes pontuais em laboratrio para julgar sistemas
adaptveis ou adaptativos. Para esse tipo de sistemas, estudos longitudinais em
contextos de uso reais muitas vezes se fazem necessrios.
Atividades
Para as atividades abaixo, considere uma agenda pessoal integrada com lista de afazeres
e correio eletrnico, que deva ser implementada para uso em dois dispositivos: um
computador desktop e um smartphone. Realize uma anlise como indicado nos Captulos
5 e 6.
1. Cenrio de interao. Para um mesmo cenrio de anlise, elabore cenrios de interao
alternativos. Que perguntas surgiram durante a elaborao da soluo e que no
haviam sido levantadas no momento da anlise?
2. Mapa de objetivos. A partir da anlise da atividade do usurio com o sistema escolhido,
construa o mapa de objetivos correspondente. H objetivos que precisam ser
apoiados em apenas uma das plataformas? Quais, e por qu? Busque sistemas
existentes que visam apoiar esses objetivos, e faa a sua engenharia reversa,
identificando os objetivos que eles de fato apoiam. H diferenas entre o resultado da
anlise do que os usurios precisam ou querem e aquilo que est projetado nesses
sistemas? Quais objetivos latentes no so apoiados? E quais objetivos os sistemas
apoiam que no surgiram na anlise de necessidades e desejos dos usurios? Discuta
as diferenas.
3. Esquema conceitual de signos. Elabore o esquema conceitual dos signos do sistema
sendo projetado, incluindo as caractersticas de contedo, expresso, preveno e
recuperao de rupturas. Avalie a necessidade de signos voltados customizao do
sistema e defina-os.
4. Modelagem de tarefas. Selecione alguns objetivos e faa a modelagem de tarefas
correspondentes. Para um mesmo objetivo, elabore modelos de tarefas alternativos,
pensando em diferentes caractersticas dos usurios e nos diferentes dispositivos
considerados. Discuta as diferenas.
5. Modelagem da interao. Para os objetivos selecionados, represente a interao
utilizando um diagrama MoLIC, um para cada dispositivo considerado. Elabore
alternativas de soluo distintas e compare suas representaes. Contraste ainda um
diagrama de interao elaborado seguindo uma abordagem top-down, e outro
elaborado a partir da engenharia reversa de sistemas existentes. Com base na anlise
feita previamente, identifique os critrios de seleo dentre os modelos de interao
elaborados.
6. Elaborao de esboos de interface a partir de um modelo de interao. Selecione uma das
solues modeladas e elabore esboos de interface alternativos para concretizar a
soluo de IHC: um conjunto de esboos a partir de um modelo de tarefas e outro a
partir de um modelo de interao. Discuta as diferenas nas decises tomadas em
cada caso e nas solues elaboradas.
7. Sistema de ajuda. Escolha um dos objetivos apoiados pelos esboos elaborados na
atividade anterior e elabore o contedo de ajuda correspondente. Discuta as formas
de acesso a esse contedo que podem ser fornecidas a partir da interface, indicando
nos esboos esses pontos de acesso.
8. Oportunidades de adaptao. Considerando diferentes perfis de usurios, atividades e
contextos de uso do sistema, identifique oportunidades de adaptao manual ou
automtica e reveja as solues modeladas e esboadas para possibilitar essas formas
de adaptao. Discuta meios de comunicar aos usurios de que maneira eles podem
adaptar o sistema ou ajustar as adaptaes realizadas automaticamente pelo sistema.
1
Estamos investigando formas de representar essa diferenciao, a fim de aumentar o carter epistmico da MoLIC e
facilitar o mapeamento da MoLIC para a interface concreta.
2
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uiml.
3
http://www.usixml.org/.
4
http://msdn.microsoft.com/en-us/library/ms752059.aspx#xaml_files.
5
www.balsamiq.com. Uma licena desse software foi gentilmente cedida aos autores para a elaborao dos esboos de tela
deste livro.
6
Esta seo foi adaptada de Prates e Barbosa (2007), com permisso das autoras.
8

Princpios e Diretrizes para o Design de IHC


Objetivos do Captulo
Apresentar princpios e diretrizes para o design de IHC, exemplificando seu uso.
Discutir os benefcios de se utilizar padres de design de IHC e apresentar alguns
modelos de documentao de padres.
Descrever brevemente o uso de guias de estilo e apresentar uma estrutura para esse
documento.
Este captulo apresenta alguns princpios, diretrizes (Norman, 1988; Tognazzini, on-line;
Nielsen, 1993; Shneiderman, 1998; Cooper, 1999) e padres de design (Tidwell, 2005)
comumente utilizados na construo das interfaces de usurio.
8.1 Introduo
A literatura de IHC est repleta de conjuntos de princpios, diretrizes (guidelines) e
heursticas. Princpios costumam representar objetivos gerais e de alto nvel; diretrizes,
regras gerais comumente observadas na prtica; e padres, solues especficas a certos
contextos bem delimitados, envolvendo certos usurios desempenhando determinadas
tarefas (Mayhew, 1999). Entretanto, essa classificao nem sempre utilizada
precisamente, e alguns proponentes de diretrizes as intitulam de princpios. Os
conjuntos mais conhecidos de princpios e diretrizes so os de Norman (1988), de
Tognazzini (2003),1 de Nielsen (1993)2 e as regras de ouro de Shneiderman (1998).
Todos os pesquisadores e profissionais de IHC ressaltam que o uso de princpios e
diretrizes jamais substitui as demais atividades de anlise, design (conceitual e concreto)
e avaliao. Embora princpios e diretrizes possam ser utilizados como auxlio ao design,
elas no substituem um processo cuidadoso que inclui a busca pelo entendimento do
problema, a elaborao de solues candidatas e a avaliao dessas solues alternativas.
Alguns conjuntos de diretrizes so desenvolvidos especificamente para certos
ambientes de trabalho, como o Windows, o MacOs e o Gnome, para certos
dispositivos, como dispositivos mveis e televiso digital interativa, e certos domnios,
como educao, governo eletrnico etc. Alguns conjuntos de diretrizes, como os voltados
para certos ambientes de trabalho, visam motivar designers a seguir uma certa
padronizao para assegurar aparncia e comportamento (look and feel) semelhantes com
o que os desenvolvedores ou alguma outra organizao propuseram. Entretanto,
diretrizes frequentemente so recomendaes genricas e descontextualizadas da teoria
ou base emprica que lhes deram origem. Alm disso, muitas vezes duas ou mais
diretrizes so conflitantes. A aplicao adequada de boa parte dos princpios e diretrizes
depende, em alguma medida, do conhecimento do designer acerca do domnio do
problema, dos usurios e das suas atividades nesse domnio. Sendo assim, cabe ao
designer considerar cuidadosamente se e quais diretrizes so adequadas sua situao
de design, e como elas devem se manifestar na soluo de IHC.
Diretrizes so comumente utilizadas em listas de verificao (checklists), em que
inspetores examinam uma interface para avaliar se ela est em conformidade com o
conjunto selecionado de diretrizes (veja a Seo 9.2). No Brasil, temos como exemplo a
ErgoList,3 lista de verificao desenvolvida com base em princpios de ergonomia.
8.2 Princpios e Diretrizes Gerais
Norman (1988) destaca a necessidade de projetarmos o sistema utilizando um modelo
conceitual que o usurio possa apreender rapidamente e sem dificuldade. O modelo
conceitual deve auxiliar a interpretar o relacionamento entre as aes e informaes
apresentadas pelo sistema e o conhecimento no mundo.
Segundo Norman (1988), o design deve facilitar: determinar quais aes so possveis a
cada momento, fazendo uso de restries (constraints); tornar as coisas visveis, incluindo
o modelo conceitual do sistema, as aes alternativas e os resultados das aes; avaliar o
estado corrente do sistema e seguir mapeamentos naturais entre as intenes e as aes
requeridas, entre as aes e o efeito resultante, e entre a informao que est visvel e a
interpretao do estado do sistema.
Os princpios e as diretrizes comumente utilizados em IHC giram em torno dos
seguintes tpicos: correspondncia com as expectativas dos usurios; simplicidade nas
estruturas das tarefas; equilbrio entre controle e liberdade do usurio; consistncia e
padronizao; promoo da eficincia do usurio; antecipao das necessidades do
usurio; visibilidade e reconhecimento; contedo relevante e expresso adequada; e
projeto para erros. As prximas subsees apresentam algumas diretrizes e ilustram
como podem ser utilizadas no design da interao e da interface.

8.2.1 Correspondncia Com As Expectativas Dos Usurios


Segundo Norman (1988), devemos explorar os mapeamentos naturais, seja entre as
variveis mentais e as fsicas, seja entre as tarefas e os controles utilizados para
manipular essas variveis no mundo real e no sistema projetado (veja Seo 3.4).
Devemos nos certificar de que o usurio consegue determinar os relacionamentos entre:
intenes e aes possveis; entre aes e seus efeitos no sistema; entre o estado real do
sistema e o que percebido pela viso, audio ou tato; entre o estado percebido do
sistema e as necessidades, intenes e expectativas do usurio.
Por exemplo, ao projetar um sistema de comrcio eletrnico, devemos examinar como
as pessoas fazem suas compras em lojas fsicas: uma pessoa entra em uma loja, escolhe
um ou mais produtos (com ou sem ajuda de um vendedor), e somente precisa se
identificar no momento de finalizar a compra e pagar pela mercadoria escolhida. Da
mesma maneira, um sistema de comrcio eletrnico deve permitir ao usurio buscar e
selecionar os produtos anonimamente, e exigir sua identificao apenas no momento de
finaliz-la (Figura 8.1a). Entretanto, ainda hoje, alguns sistemas na Web exigem que o
usurio se identifique antes mesmo de encontrar um produto do seu interesse (Figura
8.1b).
FIGURA 8.1 Sequncias alternativas de cenas em sites de comrcio eletrnico, solicitando a identificao do
usurio em diferentes momentos da interao.

Shneiderman (1998) recomenda estruturar o dilogo de forma a seguir uma linha de


raciocnio e fornecer um fechamento. Segundo ele, as sequncias de aes devem ser
organizadas em grupos com incio, meio e fim. Segundo Nielsen (1993), o projetista deve
seguir as convenes do mundo real, fazendo com que a informao aparea em uma
ordem natural e lgica. Para isso, importante entendermos as sequncias de aes que
so familiares aos usurios e, caso a soluo se desvie do que lhes familiar, deve ao
menos refletir uma organizao lgica que lhes seja plausvel. Alm disso, ele ressalta a
importncia de fornecer um feedback informativo na concluso de um grupo de aes
(veja Seo 8.2.7), para proporcionar aos usurios a satisfao de terem concludo uma
tarefa, um sentimento de alvio, um sinal de que podem deixar de lado planos de
contingncia que tiverem formulado e uma indicao de que j podem se preparar para o
novo grupo de aes.
Alm dos aspectos estruturais, o designer deve projetar a interface utilizando o idioma
do usurio, com palavras, expresses e conceitos que lhe so familiares, em vez de
utilizar termos orientados ao sistema ou a desenvolvedores.
Tognazzini (2003) recomenda o uso de metforas de forma cuidadosa, para permitir que
os usurios identifiquem rapidamente sutilezas do modelo conceitual subjacente ao
sistema. Boas metforas so como histrias, criando imagens na mente. Elas devem
evocar algo familiar, mas geralmente trazem tambm algo novo. Por exemplo, uma pasta
num gerenciador de arquivos no tem a mesma limitao de nmero de itens de
contedo que uma pasta fsica.

8.2.2 Simplicidade Nas Estruturas Das Tarefas


Norman (1988) recomenda simplificar a estrutura das tarefas, reduzindo a quantidade de
planejamento e resoluo de problemas que elas requerem. Tarefas desnecessariamente
complexas podem ser reestruturadas, em geral utilizando inovaes tecnolgicas. Para
simplificar a estrutura das tarefas, os designers podem seguir quatro abordagens
tecnolgicas: a) manter a tarefa a mesma, mas fornecendo diversas formas de apoio para
que os usurios consigam aprender e realizar a tarefa; b) usar tecnologia para tornar
visvel o que seria invisvel, melhorando o feedback e a capacidade de o usurio se manter
no controle da tarefa; c) automatizar a tarefa ou parte dela, mantendo-a igual; e d)
modificar a natureza da tarefa. Norman alerta para o perigo de a automao tirar
controle demais do usurio, escravizando-o ou tornando-o to confiante e dependente da
tecnologia a ponto de reduzir ou at mesmo eliminar sua capacidade de trabalhar sem a
automao.

8.2.3 Equilbrio Entre Controle E Liberdade Do Usurio


Norman (1988), Nielsen (1993), Tognazzini (2003), Shneiderman (1998) e Cooper (1999)
destacam a importncia de manter o usurio no controle. Tognazzini (2003) lembra que o
computador, a interface e o ambiente de trabalho pertencem ao usurio. Ele afirma
que, quando deixamos o usurio no comando, ele aprende rapidamente e ganha um
sentimento de maestria. Entretanto, ele ressalta a necessidade de buscar um equilbrio,
pois quando no h limites ou restries os usurios podem se sentir perdidos ou
angustiados com o excesso de opes. Devemos tentar reduzir o nmero de opes ou
decises que o usurio precisa tomar a cada instante. Norman (1988) recomenda explorar
o poder das restries, tanto naturais como artificiais, e projetar restries para que o usurio
sinta como se houvesse apenas uma coisa possvel a fazer: a coisa certa, claro.
Segundo Tognazzini (2003), os usurios no devem ficar presos num caminho de
interao nico para realizar uma atividade. O caminho mais rpido ou preferencial pode
ser o de menor resistncia, mas usurios que queiram explorar diferentes alternativas e
cenrios devem conseguir fazlo.
Sempre deve ser fornecida aos usurios uma sada clara e rpida, mas deve ser mais
fcil se manter no caminho do que sair dele inadvertidamente (Figura 8.2). A deciso
entre oferecer mais ou menos liberdade ao usurio varia com o seu perfil. Usurios mais
inexperientes podem precisar de mais assistncia e menos alternativas, ao passo que
usurios experientes de interfaces de uso frequente devem poder comand-la como
melhor lhes convier.

FIGURA 8.2 Tela de assistente com indicao clara do boto primrio.

Cooper (1999) afirma que o software deve ser malevel e ter jogo de cintura. Para ele,
isso significa aceitar permanecer em estados intermedirios e realizar algumas aes fora
de ordem ou antes que seus pr-requisitos tenham sido satisfeitos. Em outras palavras,
no deve forar os usurios a trabalharem de um nico modo. Entretanto, deve sempre
guardar um registro de tudo o que tiver sido feito para que o responsvel por cada ao
possa ser identificado.
Shneiderman (1998) recomenda permitir que o usurio tenha controle local da interao, ou
seja, que o usurio inicie as aes, em vez de apenas reagir a aes do sistema. Ele se
refere principalmente a usurios experientes, que costumam querer sentir que controlam
o sistema e o sistema responde s suas aes, e no o contrrio. Alm dele, Nielsen
(1993) e Tognazzini (2003) tambm destacam a importncia de permitir que o usurio
cancele, desfaa e refaa suas aes. Os usurios frequentemente escolhem funes do
sistema por engano e precisam de uma sada de emergncia claramente marcada para
sair do estado indesejado sem ter de percorrer um dilogo extenso (Figura 8.3).

FIGURA 8.3 Telas de progresso sem e com opo de cancelar.

Permitir que o usurio desfaa suas aes reduz a sua ansiedade e o medo de errar,
pois ele sabe que os erros podem ser desfeitos. Essa possibilidade tambm importante
para o aprendizado por explorao. Os usurios frequentemente exploram partes da
interface para descobrir o que aconteceria se eles fizessem isso ou aquilo, e assim
aprendem mais sobre o sistema e sobre seu prprio trabalho. Para isso, importante que
aes potencialmente perigosas possam ser desfeitas, pois podem ser acionadas
equivocadamente pelos usurios. Se um usurio pedir para apagar um arquivo, por
exemplo, o sistema deve obedecer e se preparar para desfazer a ao, caso solicitado.
Segundo Cooper (1999), a possibilidade de desfazer aes evita a necessidade de
apresentar diversos dilogos pedindo confirmao das aes dos usurios. Usar dilogos
de confirmao em excesso e de forma indiscriminada no apenas aumenta o tempo de
realizao das tarefas, mas tambm pode tornar a comunicao ineficiente, pois muitos
usurios acabam prosseguindo a interao sem mesmo ler o contedo desses dilogos.
Quando uma operao considerada perigosa no puder ser desfeita, devemos projetar
medidas de segurana para que ela no seja acionada incidentalmente (Figura 8.4).
FIGURA 8.4 Dilogos de confirmao para uma operao que no pode ser desfeita. Qual a mais segura?

Para aumentar o controle do usurio sobre a interao, o sistema tambm deve


permitir que os usurios trabalhem de modo flexvel, atravs de parmetros
configurveis, por exemplo. Entretanto, devemos buscar um equilbrio entre a gama de
opes oferecidas ao usurio e sua capacidade de entender as consequncias da
combinao de parmetros escolhida. O sistema no deve forar o usurio a escolher o
tempo todo um sem-nmero de opes para prosseguir rumo ao seu objetivo (Cooper,
1999). Da a importncia de escolher bons valores padro (defaults) para quando no for
necessrio incomodar o usurio.

8.2.4 Consistncia E Padronizao


Para facilitar o aprendizado e uso de um sistema, Norman (1988) recomenda assegurar a
consistncia da interface com o modelo conceitual embutido no sistema. Isso requer que tudo
sobre o produto (modelo de design e imagem do sistema veja Seo 3.4 , incluindo
documentao e manuais de instruo) esteja consistente com e exemplifique a operao
do modelo conceitual adequado.
Tanto Norman (1988) como Tognazzini (2003) acreditam que a consistncia mais
importante com as expectativas dos usurios, como visto na seo anterior. Segundo
eles, mesmo quando essa correspondncia no possvel, ou seja, quando precisamos
definir mapeamentos arbitrrios, devemos padronizar. Norman, Tognazzini, Nielsen e
Shneiderman recomendam padronizar as aes, os resultados das aes, o layout dos
dilogos e as visualizaes de informao. Aes relacionadas em situaes semelhantes
devem funcionar da mesma forma. Por exemplo, um boto Fechar no deve ser utilizado
para cancelar um dilogo em algumas situaes e para confirm-lo em outras.
Os usurios no devem ter de se perguntar se palavras, situaes ou aes diferentes
significam a mesma coisa. Por exemplo, utilizar rtulos Salvar e Gravar
indiscriminadamente em um mesmo sistema pode confundir o usurio. A mesma
terminologia deve ser utilizada em perguntas, menus e sistemas de ajuda. Nielsen (1993)
recomenda ainda seguir as convenes da plataforma ou ambiente computacional.
Segundo Cooper (1999), um sistema que se comporte de modo irregular ou instvel no
confivel.
Tognazzini (2003) ressalta ainda que alguns elementos de interface exigem maior
consistncia do que outros. Em particular, elementos que no possuem correspondncia
visual na interface ou cuja operao internalizada pelos usurios (e acionada sem
pensar ) no devem variar em diferentes partes do sistema. Por exemplo, sequncias de
teclas de atalho e o comportamento da roda do mouse para rolamento ou zoom devem
ser padronizados em todo o sistema.
Em contrapartida, se dois elementos de interface possuem comportamento diferente,
eles devem ter aparncias distintas. Por exemplo, um elemento de interface utilizado
para selecionar uma opo deve ser distinto de um elemento utilizado para disparar uma
ao do sistema.
Tognazzini (2003) alerta, no entanto, que eventualmente queremos propositalmente
tornar algo inconsistente, para que o usurio no possa atuar de forma automtica e
precise refletir sobre o que est fazendo. Esse o caso, por exemplo, de dilogos de
confirmao em que os botes Sim e No so substitudos por rtulos mais
representativos dos efeitos de cada boto, e que no podem ser acionados pelo simples
pressionamento das teclas S ou N.

8.2.5 Promovendo A Eficincia Do Usurio


Tognazzini (2003) recomenda considerar sempre a eficincia do usurio em primeiro lugar,
e no a do computador. As pessoas so mais custosas do que mquinas, e uma economia
de tempo e esforo do usurio costumam trazer mais benefcios do que economias
semelhantes de processamento ou armazenamento. Para isso, Tognazzini sugere manter o
usurio ocupado. Toda vez que o usurio precisa esperar o sistema responder antes que
possa continuar seu trabalho, h perda de produtividade e desperdcio de dinheiro.
Sendo assim, processamentos demorados no devem prender a interao, mas sim
permitir que os usurios continuem seu trabalho com outras partes do sistema, deixando
esses processos executando em background. Para isso, um bom projeto de arquitetura do
software essencial. Alis, esse ponto refora a necessidade de cooperao, comunicao
e parceria constante entre os engenheiros e os designers de IHC durante todo o processo
de desenvolvimento (veja a Seo 1.2).
Segundo Cooper (1999), o sistema deve ser sensvel ao que o usurio est fazendo e no
deve interromp-lo desnecessariamente enquanto o usurio estiver trabalhando em algo.
Por exemplo, mudar o estado de sistemas de comunicao (e.g., Windows Live
Messenger, Google Talk) para ocupado enquanto o usurio estiver projetando uma
apresentao.
O designer deve proteger o trabalho dos usurios (Tognazzini, 2003). Os usurios nunca
devem perder o seu trabalho, seja por um erro seu, por uma falha na transmisso de
rede, uma falha no fornecimento de energia para o computador ou qualquer outra razo.
O sistema deve se lembrar de tudo o que o usurio disse, para no perguntar de novo
(Cooper, 1999), e se manter informado sobre o usurio. O sistema deve ser capaz de saber: se
essa a primeira vez em que o usurio acessou o sistema; onde o usurio est no sistema;
para onde ele est indo (caso haja um caminho claro em direo a um objetivo); o que o
usurio tem feito durante a sesso de uso atual; onde ele estava quando deixou o sistema
na ltima sesso; e outras informaes semelhantes que permitam poupar trabalho do
usurio e melhorar sua experincia de uso do sistema. O usurio deve ser capaz de sair
de um sistema numa mquina e acess-lo a partir de outra, voltando exatamente ao
ponto em que parou.
Para promover a eficincia de usurios frequentes, Nielsen (1993) e Shneiderman
(1998) recomendam fornecer atalhos e aceleradores. medida que a frequncia de uso
aumenta, aumenta tambm a vontade dos usurios de reduzir o nmero de interaes e
acelerar o passo da interao. Teclas de atalho e comandos ocultos so bastante teis a
usurios experientes, e no prejudicam a interao dos usurios novatos. Exemplos de
aceleradores so teclas de atalho para itens de menu (e.g., Ctrl+S para salvar) e
acionamento de botes de comando em barras de ferramentas (e.g., boto para imprimir
o documento atual utilizando a configurao default). Caso haja sequncias de operaes
frequentes, o designer tambm pode fornecer meios mais sofisticados, como gravao de
macro ou programao por demonstrao (Cypher, 1993; Lieberman, 2001).
Para operaes frequentes, o designer pode oferecer tambm a configurao de valores
default, individualmente ou em grupo, formando perfis de execuo dessas operaes. A
Figura 8.5 apresenta um dilogo de gerao de arquivo PDF de um editor de
apresentaes que permite armazenar valores de parmetros na forma de perfis de
exportao.

FIGURA 8.5 Dilogo com parmetros configurveis que podem ser armazenados em um perfil de exportao.

8.2.6 Antecipao
As aplicaes devem tentar prever o que o usurio quer e precisa, em vez de esperar que
os usurios busquem ou coletem informaes ou invoquem ferramentas. O designer
deve fornecer ao usurio todas as informaes e ferramentas necessrias para cada passo
do processo (Tognazzini, 2003).
Segundo Cooper (1999), o software deve tomar iniciativa e fornecer informaes
adicionais teis, em vez de apenas responder precisamente a pergunta que o usurio
tiver feito. Por exemplo, quando um usurio pergunta sobre o telefone de um
restaurante, o software pode informar tambm seus dias e horrios de funcionamento.
Cooper acredita que, enquanto o software estiver toa, deve antecipar e se preparar para
situaes que provavelmente acontecero, de modo a responder mais rapidamente
quando chegar a hora. Alm disso, o software deve ser observador e se lembrar quais
aes o usurio realiza em sequncia, para tentar antever o prximo passo a cada
momento e facilitar a sua execuo.
Tognazzini destaca a importncia de definir cuidadosamente os valores e a
configurao padro (defaults). Ele afirma que, de qualquer forma, os defaults devem ser
facilmente substitudos por valores especficos mais adequados situao atual. Se
possvel, campos contendo defaults devem vir j selecionados, de forma que os usurios
possam editar seu contedo com novos valores rpida e facilmente. As pessoas tendem a
aceitar os valores defaults para aquilo que elas no entendem ou assumem que o sistema
j aprendeu sobre elas ou que seja a resposta certa. Por isso, a escolha deve ser
cuidadosa. Considere cada alternativa apresentada na Figura 8.6. Ela eficiente?
neutra? Ou induz a uma determinada opo?

FIGURA 8.6 Ilustraes do uso (ou no uso) de valores default.

8.2.7 Visibilidade E Reconhecimento


Norman (1988) afirma que o designer deve tornar as coisas visveis: abreviar os golfos de
execuo e avaliao (veja Seo 3.4). Antes de executar uma ao, necessrio tornar
visvel para os usurios o que possvel realizar e como as aes devem ser feitas. Para
isso, a interface deve oferecer aes que correspondam a intenes do usurio. Alm
disso, a interface no deve oferecer opes que no estejam disponveis ou no faam
sentido em um determinado momento da interao. Depois que o usurio realiza uma
ao, a interface deve lhe fornecer indicaes do estado do sistema que sejam
prontamente percebidas e consistentes com o seu modelo mental, para que ele possa
interpret-las adequadamente e entender os efeitos da ao realizada.
Em outras palavras, o estado do sistema, os objetos, as aes e as opes devem estar
atualizados e facilmente perceptveis (Nielsen, 1993; Shneiderman, 1998; Tognazzini,
2003). O usurio no deve ter de se lembrar para que serve um elemento de interface cujo
smbolo no reconhecido diretamente. Tambm no deve ter de se lembrar de
informaes de uma parte da aplicao quando tiver passado para uma outra parte da
aplicao. O sistema no deve exigir que o usurio memorize muitas informaes ou
comandos durante a interao, devido limitao humana do processamento de
informao na memria de curto prazo. As instrues de uso do sistema devem estar
visveis ou facilmente acessveis sempre que necessrio.
Os usurios tambm no devem ter de procurar informaes sobre o estado do
sistema. Em vez disso, eles devem ser capazes de olhar rapidamente para o seu ambiente
e obter pelo menos uma primeira aproximao desse estado. Segundo Tognazzini, os
mecanismos de status so essenciais para fornecer a informao necessria para os
usurios responderem adequadamente s mudanas ocorridas. O usurio poder ter
dificuldades em controlar o sistema adequadamente se no possuir informaes
suficientes sobre o seu estado atual. Entretanto, Cooper (1999) recomenda que o software
no exagere nas mensagens de status. Em geral, as informaes de status podem ser bem
sutis. Por exemplo, o cone de caixa de entrada do cliente de correio eletrnico pode
aparecer vazio, meio cheio ou lotado, para refletir o nmero de mensagens no lidas.
Quando o usurio realiza uma ao, o sistema deve mant-lo informado sobre o que
ocorreu ou est ocorrendo, atravs de feedback (resposta do sistema) adequado e no
tempo certo (Nielsen, 1993; Shneiderman, 1998; Tognazzini, 2003). Para aes frequentes
e com resultado esperado, a resposta pode ser sutil, mas para aes infrequentes e com
grandes consequncias, a resposta deve ser mais substancial. A Figura 8.7 apresenta um
feedback sutil como resultado de um cadastro bem-sucedido, e outro feedback, destacado,
indicando uma falha.
FIGURA 8.7 Feedback sutil e destacado.

Tognazzini (2003) afirma que, para reduzir a sensao de o programa no estar


respondendo, o sistema deve: fornecer feedback visual/sonoro at 50 ms aps um clique
de boto; sinalizar que est ocupado (e.g., atravs de uma ampulheta, animada para
indicar que o sistema no travou) quando o sistema realizar uma ao que leve entre 0,5 s
e 2 s; apresentar, quando a ao levar mais do que 2 segundos, uma mensagem indicando
a demora estimada e cada passo sendo realizado, juntamente com uma barra de
progresso e opes de cancelamento, suspenso ou de execuo em background. Quando
uma operao demorada (mais do que 10 segundos) terminar, o sistema deve emitir um
som e fornecer uma indicao visual destacada, para que usurios que tenham desviado
sua ateno possam retomar o seu uso do sistema.
O designer deve manter o usurio informado sobre o caminho que percorreu no
sistema ou Web site at o ponto em que se encontra. O usurio no deve ser responsvel
por elaborar um mapa mental do que fez at o momento ou por onde passou no sistema.
Alm disso, sinalizaes claras orientam a interao do usurio e lhe ajudam a navegar
pela aplicao rapidamente, sempre cientes de onde esto (Tognazzini, 2003).

8.2.8 Contedo Relevante E Expresso Adequada


Segundo Reeves e Nass (1996), as pessoas do tratamento humano para qualquer mdia
ou tecnologia que apresente comportamento semelhante ao de uma pessoa, mesmo
sabendo que isso tolice e negando que tenham feito isso a posteriori. Em linha com o
princpio de conversa cooperativa de Grice (1972), eles destacam que uma interao
polida segue quatro mximas: qualidade, quantidade, relao (ou relevncia) e modo (ou
clareza).
A mxima da qualidade afirma que no devemos dizer nada que saibamos no ser
verdade ou para o que no tenhamos evidncias, ou seja, no devemos mentir ou
especular. A mxima da quantidade diz respeito quantidade de informao comunicada:
a contribuio de uma fala deve ser to informativa quanto necessrio para os objetivos
da conversa, e no mais. Uma constante dentre os profissionais de IHC a busca pela
simplicidade. Seguem o lema menos mais. A mxima da quantidade est fortemente
relacionada simplicidade da interface. A mxima da relao ou relevncia afirma que
tudo o que for dito deve ter relao clara com os tpicos da conversa at o momento e ser
relevante ao objetivo dos interlocutores. Finalmente, a mxima de modo ou clareza pede
para evitar a prolixidade e ambiguidade, buscar a conciso e ordenar adequadamente a
conversa.
Em linha com a mxima de quantidade, Nielsen (1993) defende o projeto esttico e
minimalista. Ele afirma que os dilogos no devem conter informaes que sejam
irrelevantes ou raramente necessrias. Cada unidade extra de informao em um dilogo
compete com as unidades relevantes de informao e reduz sua visibilidade relativa.
Cooper (1999) alerta que, quando o sistema sonega informao, ele obscurece seu
comportamento. Para que os usurios gostem do software e tenham uma experincia
agradvel, ele sugere projetar uma interao respeitosa, generosa e prestativa. Ele
considera uma boa interao mais importante do que a composio da interface concreta
propriamente dita.
Tognazzini (2003) oferece uma srie de recomendaes relacionadas redao em
interfaces grficas. As mensagens de instruo e ajuda devem ser concisas e informativas
sobre problemas que ocorrerem. Os rtulos de menus e botes devem ser claros e livres
de ambiguidade. Entretanto, nem sempre um termo mais preciso melhor. Por exemplo,
considere um editor de texto com os seguintes itens de menu: Inserir Quebra de Pgina,
Acrescentar Nota de Rodap e Construir Tabela. Embora precisos, eles trazem menos
benefcios do que os itens: Inserir Quebra de Pgina, Inserir Nota de Rodap e Inserir
Tabela. Nessa segunda opo, os usurios conseguem varrer as opes disponveis mais
rapidamente, pois a variedade dos verbos utilizados aumenta o tempo que leva para
decodific-los, sem ser suficientemente informativa de modo a compensar o tempo
despendido.
Alm de cuidar do contedo, o designer deve se certificar de que o texto tambm seja
legvel. Para isso, deve ser apresentado com alto constraste e favorecer texto preto sobre
fundo branco ou amarelo-claro, evitando fundos de cor cinza (Tognazzini, 2003). Os
tamanhos de fonte devem ser suficientemente grandes para serem lidos em monitores de
tamanho e resoluo padro. E os dados podem ser apresentados em fonte maior ou com
mais destaque do que rtulos e instrues, principalmente quando os dados forem
numricos. E, sempre que possvel, o designer deve permitir que usurios com
deficincias visuais aumentem o tamanho da fonte.
Ao utilizar cores para transmitir alguma informao atravs da interface, necessrio
utilizar dicas secundrias claras para transmitir a mesma informao queles que no
conseguem distinguir as cores utilizadas, seja por limitaes fsicas, como daltonismo,
que afeta cerca de 10% da populao masculina, ou por limitaes do dispositivo
utilizado (Tognazzini, 2003). Dicas secundrias incluem variaes na escala em tons de
cinza, diferentes ilustraes ou rtulos associados a cada cor apresentada.
Como visto na Seo 1.4, profissionais oriundos de diversas reas devem colaborar em
atividades de IHC. Dentre eles, os designers grficos so os principais responsveis pela
identidade visual do sistema, incluindo o layout, que define a disposio espacial dos
elementos de interface, e a escolha de fontes, formas, cores, texturas, imagens e outros
smbolos no tipogrficos (Mullet e Sano, 1995). Ao elaborar esboos de interface ou
prottipos, deve-se buscar fazer uso de alguns princpios bsicos, para que a ateno do
usurio no se desvie para detalhes da interface que no sejam o foco do design naquele
momento, mas que, por violarem princpios bsicos de design grfico, estejam lhe
incomodando.
Mullet e Sano (1995) organizam princpios de design visual de interfaces em torno dos
seguintes temas: elegncia e simplicidade; escala, contraste e proporo; organizao e
estrutura visual; mdulo e programa; imagem e representao; e estilo. Os esboos de
interface se beneficiam principalmente dos princpios relacionados com a estrutura geral
da interface, como, por exemplo, o uso de grid para alinhar os elementos e o uso de
espao para guiar a disposio de elementos conforme a direo natural de leitura dos
usurios.

8.2.9 Projeto Para Erros


Norman (1988) recomenda projetar para o erro, ou seja, assumir que qualquer erro
potencial ser cometido. O designer deve ajudar o usurio a se recuperar de um erro,
informando-lhe sobre o que ocorreu, as consequncias disso e como reverter os
resultados indesejados. Como visto, os sistemas devem ser explorveis, ou seja, deve ser
fcil reverter as operaes e difcil realizar aes irreversveis. Alm disso, Cooper (1999)
recomenda no colocar controles de funes utilizadas com frequncia adjacentes a
controles perigosos ou que raramente so utilizados. Por exemplo, na Figura 8.8, um
boto de inspeo de Propriedades est posicionado bem prximo ao boto para
Desabilitar a conexo de rede que, inclusive, efetua a operao sem pedir confirmao do
usurio.
FIGURA 8.8 Posicionamento de um boto de uso frequente (Propriedades) prximo a um boto de uso
infrequente e consequncias graves (Desabilitar).

Nielsen (1993) e Shneiderman (1998) recomendam que o designer tente, em primeiro


lugar, evitar que os erros ocorram, caso possvel. Se um erro for cometido, o sistema deve
ser capaz de detect-lo e oferecer mecanismos simples e inteligveis para trat-lo. O
designer deve ajudar os usurios a reconhecerem, diagnosticarem e se recuperarem de erros
(Figura 8.9). As mensagens de erro devem ser expressas em linguagem simples e
inteligvel (sem cdigos indecifrveis), indicar precisamente o problema e sugerir uma
soluo de forma construtiva.

FIGURA 8.9 Exemplo de mensagens de erro (a) sem e (b) com oportunidade de recuperao e retomada de um
caminho de interao produtivo.

Alm de erros, tambm devemos apoiar os usurios a esclarecerem suas dvidas


durante a interao. Para isso, precisamos elaborar ajuda e documentao de alta
qualidade. Tais informaes devem ser facilmente encontradas, focadas na tarefa do
usurio, enumerar passos concretos a serem realizados e no ser muito extensas (veja
Seo 7.5).
8.3 Padres de Design de IHC
Padres de design (design patterns) so descries de melhores prticas num determinado
domnio de design (Tidwell, 2006; Borchers, 2001). O conceito de padres foi proposto na
dcada de 1970 por Christopher Alexander (1979), no domnio de arquitetura e
urbanismo, e apresentados comunidade de Computao na dcada de 1990 na forma de
padres de arquitetura de software orientado a objetos utilizados na Engenharia de
Software (Gamma et al., 1995). Padres capturam solues comuns a certos interesses ou
tenses de design (chamadas de foras na literatura de padres). Alexander objetivava
recriar o conhecimento compartilhado sobre solues de design boas e adequadas
tornando-o explcito, documentado, testado e gradualmente aperfeioado (Borchers,
2001).
Tidwell (2006) aponta como vantagens do uso de padres, alm da captura da
sabedoria coletiva de designers experientes em IHC, o fornecimento de um vocabulrio
de design comum e divulgao de boas solues para a comunidade de design. Ela alerta,
no entanto, que padres no so solues prontas, nem regras ou heursticas. Cada
aplicao de um padro difere ligeiramente uma da outra. Padres de design em IHC
tambm no so descries passo a passo sobre como projetar uma interface inteira, mas
sim descries para problemas pontuais. O uso de padres no substitui o processo
criativo envolvido num projeto de design, nem assegura por si s a qualidade do produto
final. Em outras palavras, padres devem ser utilizados como recursos em um processo
de design reflexivo (veja Seo 4.2), e no como solues prontas.
Os padres no so isolados; eles esto relacionados com outros padres de diversas
maneiras. Cada padro pode ser descrito em maior ou menor nvel de detalhes e pode ser
adequado a apenas um certo contexto (Borchers, 2001). Um conjunto completo de
padres de design relacionados chamado de linguagem de padres (pattern language),
que definem um extenso vocabulrio de elementos utilizados em design, alm de formas
de articul-los.
Borchers (2001) utiliza uma estrutura semelhante de Alexander e sugere que os
padres sejam descritos atravs dos seguintes elementos:
o nome do padro, para transmitir em poucas palavras a ideia do padro, de modo a
facilitar sua memorizao e a meno a ele em uma reflexo ou discusso durante o
design;
uma avaliao de sua validade (indicada por zero, um ou dois asteriscos), indicando o
grau de confiana que os autores tinham no padro;
uma imagem como exemplo de aplicao do padro;
o contexto em que o padro pode ser usado, com referncia a padres maiores que este
ajuda a implementar;
uma breve descrio do problema, um resumo da situao geral que o padro enderea;
uma descrio detalhada do problema, com base emprica e citando as foras conflitantes
que o padro almeja resolver ou equilibrar;
a soluo central do padro, um conjunto claro mas relativamente genrico de instrues
que possam ser aplicadas a diversas situaes;
um diagrama ilustrando a soluo, geralmente um esboo grfico da soluo e seus
principais constituintes;
referncias a padres menores, recomendaes do autor sobre como implementar e
desdobrar ainda mais a soluo representada no padro atual.
Tidwell (2006), por sua vez, descreve seus padres utilizando, alm do ttulo do padro
(e.g., painis colapsveis), as seguintes informaes:
o que, resumindo a soluo em um pargrafo curto;
usar quando, indicando as situaes em que o padro se aplica e as foras em atuao;
por que, fornecendo dados que justificam a adequao do padro situao descrita;
como, detalhando a soluo e as formas como ela pode ser implementada;
exemplos, incluindo diagramas e imagens de interfaces concretas que ilustram o uso do
padro.
Van Welie4 representa padres de forma semelhante a Tidwell, atravs dos seguintes
elementos: problema, soluo (texto e imagem ilustrando uso real), usar quando, como, por
que, mais exemplos, implementao e literatura.
O Exemplo 8.1 apresenta um padro de design comumente descrito: o padro de
Acordeo, adaptado da biblioteca de van Welie. Os textos em itlico representam ligaes
com outros padres, sejam da mesma biblioteca ou de outras bibliotecas, como a
biblioteca de Tidwell.5

Exemplo 8.1
P adro de D esign de I nterface
Ttulo: Acordeo
Problema: O usurio precisa encontrar um item dentre as opes de
navegao.
Soluo: Empilhar painis vertical ou horizontalmente, abrindo um
painel de cada vez, enquanto colapsa os demais.
Usar quando: Como mecanismo de navegao, sendo conceitualmente
equivalente a Guias e uma soluo alternativa a rvores de navegao.
Embora seja utilizado como parte de um Assistente, isso no
recomendado, pois apresenta pior qualidade de uso do que
implementaes tradicionais. Pode ser uma boa forma de implementar
uma seo de Perguntas Frequentes (FAQ), em que cada pergunta aberta de
uma vez. Um outro uso seria para gerenciar configuraes de preferncias.
O nmero de painis deve ser reduzido, em geral menor que dez.
Exemplo:
Como: Os painis podem ser dispostos vertical ou horizontalmente.
Apenas um painel mantido aberto de cada vez. Quando mais do que um
painel pode ser mantido aberto, trata-se do padro Painis Colapsveis. Em
geral, painis verticais so destinados a submenus, enquanto painis
horizontais revelam grandes reas de contedo. Os seguintes cuidados
devem ser tomados na implementao do padro Acordeo:
Anime a abertura dos painis para fornecer aos usurios feedback sobre o
que est acontecendo. A animao deve ser sutil e durar no mximo 250
ms.
Permita que a navegao seja feita atravs das setas do teclado.
Destaque o painel atual para que o usurio possa facilmente diferenciar o
cabealho do painel aberto dos cabealhos dos painis fechados.
Certifique-se de que o tamanho total do Acordeo pode aumentar ou
diminuir para acomodar o contedo adequadamente.
Por qu: Um acordeo til para comprimir muitos elementos num
espao de tela compacto. Os elementos podem ser propriedades,
perguntas ou simples itens de navegao. A desvantagem bvia que os
elementos dos outros painis ficam ocultos.
FIGURA 8.10 Exemplo do padro de interface Acordeo, com o painel Layouts expandido (esq.) e com o painel
Modelos de tabela expandido (dir.).
8.4 Guias de Estilo
comum, principalmente em projetos grandes, reunir os princpios e as diretrizes
adotados em um documento intitulado guia de estilo. Trata-se de um registro das
principais decises de design tomadas, de forma que elas no se percam, isto , sejam
efetivamente incorporadas no produto final. Guias de estilo servem de ferramenta de
comunicao entre os membros da equipe de design e tambm com a equipe de
desenvolvimento. importante que as decises de design possam ser facilmente
consultadas e reutilizadas nas discusses sobre extenses ou verses futuras do produto.
Um guia de estilo pode ser elaborado com diferentes escopos: plataforma (composio
de dispositivo e sistema operacional), corporativo (para assegurar a padronizao e
consistncia entre produtos de uma empresa), famlia de produtos e um produto
especifico (Mayhew, 1999).
Um guia de estilo deve incorporar decises de design envolvendo os principais
elementos e consideraes de design de interface. Marcus (1992) considera os seguintes
elementos:
layout: proporo e grids; uso de metforas espaciais; design grfico de exibidores e
ferramentas;
tipografia e seu uso em dilogos, formulrios e relatrios;
simbolismo: clareza e consistncia no design de cones;
cores: os dez mandamentos sobre o uso de cores;
visualizao de informao: design de grficos, diagramas e mapas;
design de telas e elementos de interface (widgets).
Uma estrutura comum de guia de estilo a seguinte (Marcus, 1992; Mayhew, 1999):
1. Introduo
1.1. Objetivo do guia de estilo
1.2. Organizao e contedo do guia de estilo
1.3. Pblico-alvo do guia de estilos (programadores, gerentes, equipe de suporte)
1.4. Como utilizar o guia (em produo e manuteno)
1.5. Como manter o guia
2. Resultados de anlise
2.1. Descrio do ambiente de trabalho do usurio
3. Elementos de interface
3.1. Disposio espacial e grid
3.2. Janelas
3.3. Tipografia
3.4. Smbolos no tipogrficos
3.5. Cores
3.6. Animaes
4. Elementos de interao
4.1. Estilos de interao
4.2. Seleo de um estilo
4.3. Aceleradores (teclas de atalho)
5. Elementos de ao
5.1. Preenchimento de campos
5.2. Seleo
5.3. Ativao
6. Vocabulrio e padres
6.1. Terminologia
6.2. Tipos de tela (para tarefas comuns)
6.3. Sequncias de dilogos (e.g., para feedback ou confirmao de uma operao)
Mayhew (1999) sugere ainda que o guia de estilo inclua todos os produtos do
levantamento de dados e anlise das necessidades dos usurios, registrando o design
rationale, ou seja, mantendo o rastreamento entre uma deciso de design e os elementos
de discusso que culminaram naquela deciso.
Quando elaboramos um guia de estilo, no basta simplesmente produzi-lo. Devemos
comunicar adequadamente sua existncia e importncia para os demais designers e
desenvolvedores, oferecer treinamento, facilitar o acesso ao documento como um todo ou
a um tpico especfico e investir em uma mudana na cultura de design e
desenvolvimento da equipe. Alm disso, no devemos tratar o guia de estilo como um
conjunto de regras, mas sim uma ferramenta prtica de apoio ao trabalho e
criatividade. Em outras palavras, um guia de estilo deve ser utilizado como parte de um
processo reflexivo de design, e no como um conjunto de solues prontas ou frmulas
geradoras de solues (veja Seo 4.2).
Atividades
Para as atividades abaixo, considere a agenda pessoal integrada com lista de afazeres e
correio eletrnico utilizada no captulo anterior, projetada para uso em dois dispositivos:
um computador desktop e um smartphone. Retomando as atividades do captulo anterior,
examine os esboos produzidos.
1. Uso de princpios e diretrizes. Quais princpios e diretrizes foram aplicados nos
esboos? Algum princpio ou diretriz foi violado? Como pode ser resolvido? Caso no
seja resolvido, quais as possveis consequncias da violao?
2. Uso de padres. Examine as bibliotecas de padres citadas neste captulo. Quais
padres se encaixam para a soluo sendo projetada? Que adaptaes precisam ser
feitas?
3. Guia de estilo. A partir dos modelos e esboos elaborados, destaque os elementos que
podem compor um guia de estilo para futuras funcionalidades do mesmo sistema ou
para sistemas complementares produzidos para o mesmo cliente.
1
http://www.asktog.com/basics/firstPrinciples.html.
2
Nielsen (1993) denomina seu conjunto de diretrizes alternadamente de princ-pios, diretrizes e heursticas.
3
http://www.labiutil.inf.ufsc.br/ergolist/.
4
http://www.welie.com/patterns/index.php.
5
http://designinginterfaces.com/.
9

Planejamento da Avaliao de IHC


Objetivos do Captulo
Discutir a importncia de avaliar a qualidade de uso de um sistema interativo.
Descrever o planejamento e a execuo da avaliao de IHC envolvendo ou no
usurios.
Caracterizar os objetivos de avaliao e contextos de projeto que auxiliam na escolha
do mtodo de avaliao a ser utilizado.
A avaliao de IHC uma atividade fundamental em qualquer processo de
desenvolvimento que busque produzir um sistema interativo com alta qualidade de uso.
Ela orienta o avaliador a fazer um julgamento de valor sobre a qualidade de uso da soluo
de IHC e a identificar problemas na interao e na interface que prejudiquem a experincia
particular do usurio durante o uso do sistema. Assim, possvel corrigir os problemas
relacionados com a qualidade de uso antes de inserir o sistema interativo no cotidiano
dos usurios, seja um sistema novo ou uma nova verso de algum sistema existente.
Com uma viso ampla do processo de desenvolvimento e dos critrios de qualidade
desejveis, este captulo comea discutindo a importncia de avaliar a qualidade de uso
de um sistema interativo. Ele descreve o que pode ser avaliado, quando e onde uma
avaliao pode ser realizada e quais tipos de dados so coletados e produzidos. Em
seguida, descreve os tipos mais comuns de mtodos de avaliao e as atividades bsicas
de uma avaliao de IHC. O captulo conclui com uma breve apresentao do framework
DECIDE, proposto para orientar o planejamento de uma avaliao de IHC (Sharp et al.,
2007).
9.1 Por que Avaliar?
Conhecer critrios de qualidade e seguir processos de fabricao que buscam criar
produtos adequados a esses critrios nem sempre resultam em produtos de qualidade.
possvel que algo passe despercebido durante a produo e acabe prejudicando a
qualidade do produto final. Pode ser um problema de matria-prima com defeito ou de
m qualidade; pode ser um descuido na manipulao de materiais; pode acontecer um
erro humano durante o processo de produo, e assim por diante. Em particular, quando
estamos trabalhando com sistemas interativos, os problemas costumam ocorrer na
coleta, interpretao, processamento e compartilhamento de dados entre os interessados
no sistema (stakeholders), e at na fase de implementao (por exemplo, um programador
pode cometer o equvoco de codificar uma informao errada sobre o domnio). Ento, o
que possvel fazer para entregar ao consumidor (i.e., usurio final) um produto de
qualidade? Alm de continuar seguindo processos de design e desenvolvimento
comprometidos com a qualidade do produto final, tambm preciso avaliar se o produto
resultante desse processo atende aos critrios de qualidade desejados. A avaliao do
produto final possibilita entregar um produto com uma garantia maior de qualidade.
Para isso, se algum problema for encontrado durante a avaliao, ele deve ser corrigido
antes de o produto chegar ao consumidor.
difcil garantir a qualidade total de um produto, porque seria necessrio avaliar o
produto final em todas as situaes de uso possveis. Alm de ser invivel prever todas
essas situaes, o custo de tal avaliao seria alto demais, e exigiria muito tempo e
esforo para sua realizao.
Como qualquer produto, um sistema interativo deve ser avaliado sob a perspectiva de
quem o concebe, de quem o constri e de quem o utiliza. Na perspectiva de quem
constri, o objetivo principal da avaliao verificar se o sistema funciona de acordo com
a especificao de requisitos, ou seja, o foco est em verificar se o sistema recebe os
dados de entrada, processa e fornece os dados de sada conforme especificado. Os
critrios de qualidade avaliados nessa perspectiva esto relacionados construo de
sistemas interativos, tal como robustez e confiabilidade (Avizienis et al., 2004). Esses
critrios de qualidade normalmente abstraem o que existe e ocorre fora do sistema
(atravs da interface com usurio durante a interao), e se concentram no que existe e
ocorre dentro do sistema. Existem vrios mtodos de avaliao para verificar a qualidade
de um sistema interativo do ponto de vista de quem o constri (Pressman, 2002;
Delamaro et al., 2007), como testes de caixa-branca e caixa-preta, por exemplo. Essa
avaliao costuma ser realizada por uma srie de testes ao longo do processo de
desenvolvimento, como, por exemplo, testes de unidade, de integrao, de sistema e de
operao. Mesmo depois de avaliado e confirmado que um sistema interativo funciona
conforme sua especificao, ainda assim ele pode apresentar problemas relacionados ao
uso, pois o que ocorre fora da interface durante a interao ainda no foi avaliado do
ponto de vista do usurio. Em outras palavras, problemas de IHC ainda podem continuar
existindo depois que os problemas na construo (das funcionalidades) do sistema forem
identificados e resolvidos.
Nas perspectivas de quem concebe e de quem utiliza um sistema interativo, a avaliao
tem por objetivo principal verificar se o sistema apoia adequadamente os usurios a
atingirem seus objetivos em um contexto de uso. Nessa perspectiva, o que existe dentro
do sistema s interessa medida que determina o comportamento aparente deste (i.e.,
que emerge atravs da interface) e afeta a experincia vivenciada pelo usurio durante a
interao. O foco passa a ser o que existe e ocorre da interface com usurio para fora. Os
critrios de qualidade avaliados nessa perspectiva so relacionados ao uso, tais como:
usabilidade, experincia do usurio, acessibilidade e comunicabilidade, apresentados no
Captulo 2. Neste captulo e no prximo, nos concentramos em mtodos de avaliao da
qualidade de uso propostos na rea de IHC.
Um sistema interativo resultado de decises de design tomadas com base na
interpretao do designer sobre a situao atual, sobre sua identificao e interpretao
das necessidades e oportunidades de melhoria, no seu conhecimento sobre solues para
problemas semelhantes ou relacionados e na sua criatividade para conceber novas
solues para o problema especfico em questo. Desse modo, o processo de interao
usuriosistema e o comportamento do sistema durante esse processo so regidos pela
lgica definida pelo designer. Os usurios podem ou no compreender e concordar com a
lgica do designer, podem ou no julgar a soluo de IHC apropriada e melhor do que as
solues existentes e, quando tiverem escolha, podem ou no incorpor-la no seu dia a
dia. Portanto, o designer no pode presumir que, se ele aprovar uma soluo de interao
e interface, o usurio tambm ir aprov-la e fazer uso dela no seu cotidiano.
importante lembrar que os usurios so pessoas diferentes dos designers e
desenvolvedores. Eles muito provavelmente sentem, interpretam, pensam e vivem em
culturas e sociedades diferentes, com costumes e gostos prprios, e possuem objetivos
diferentes (e.g., usar vs. conceber vs. desenvolver um produto).
As diferenas entre quem concebe e quem utiliza uma soluo IHC no podem ser
desprezadas. importante que a soluo de IHC seja avaliada do ponto de vista dos
usurios, preferencialmente com a participao deles durante a avaliao. Aquele que
avalia a qualidade de uso defende o ponto de vista e os interesses dos usurios, atuando
como uma espcie de advogado deles durante o processo de desenvolvimento (Prates e
Barbosa, 2003). Sempre que possvel, a avaliao de IHC deve ser conduzida por
avaliadores que no participaram da concepo da soluo, pois eles possuem melhores
condies de analisar a soluo sob um ponto de vista mais neutro, para defender os
usurios e no o design concebido.
A qualidade de uso de um sistema interativo sempre ser avaliada. Isso no pode ser
ignorado. O usurio final sempre avalia o sistema durante sua experincia de uso,
tecendo uma opinio sobre ele. fundamental que a equipe de desenvolvimento assuma
a responsabilidade de avaliar a qualidade de uso do sistema antes de ele ser entregue ao
usurio. preciso buscar um entendimento de como os usurios podem vir a utilizar o
sistema e se vo apreci-lo, principalmente quando ele for um sistema inovador
resultante principalmente da criatividade do designer (Sharp et al., 2007). Identificar e
corrigir os problemas relacionados com a qualidade de uso antes de o sistema ser
entregue ao usurio demonstra profissionalismo da equipe de desenvolvimento (Prates e
Barbosa, 2003).
Dentre as razes para avaliarmos a qualidade de uso de sistemas computacionais
interativos, Tognazzini (2000) destaca as seguintes:
os problemas de IHC podem ser corrigidos antes e no depois de o produto ser
lanado;
a equipe de desenvolvimento pode se concentrar na soluo de problemas reais, em
vez de gastar tempo debatendo gostos e preferncias particulares de cada membro da
equipe a respeito do produto;
os engenheiros sabem construir um sistema interativo, mas no sabem e no esto em
uma posio adequada para discutir sobre a qualidade de uso. Quem ser o advogado
do usurio para defender seus interesses durante o processo de desenvolvimento?;
o tempo para colocar o produto no mercado diminui, pois os problemas de IHC so
corrigidos desde o incio do processo de desenvolvimento, assim que aparecem,
exigindo menos tempo e esforo para serem corrigidos;
identificar e corrigir os problemas de IHC permitem entregar um produto mais
robusto, ou seja, a prxima verso corretiva no precisa j comear a ser desenvolvida
no momento do lanamento do produto no mercado.
Avaliar a qualidade de uso de sistemas interativos no representa apenas um aumento
do custo de desenvolvimento, como alguns gerentes de projeto costumam pensar. O
custo de avaliar a qualidade de uso no costuma ser alto quando comparado ao
oramento global de um projeto de desenvolvimento, e principalmente quando
consideramos os benefcios significativos e importantes para o sistema (Rubin, 1994; Bias
e Mayhew, 2005). A curto prazo, avaliar a qualidade de uso e corrigir os problemas
identificados contribuem para aumentar a produtividade dos usurios, diminuir o
nmero e a gravidade dos erros cometidos durante o uso, e aumentar a satisfao dos
usurios. A mdio e longo prazo, identificar e corrigir os problemas de IHC contribuem
para diminuir o custo de treinamento e suporte, e para planejar verses futuras do
sistema, pois chamam a ateno da equipe para partes do sistema que podem melhorar,
alm de indicar outras que podem ser mais exploradas. Um gerente de projeto no pode
deixar de usufruir dos benefcios da avaliao da qualidade de uso pelo simples
desconhecimento do que , de quanto custa e de quais so seus benefcios. possvel
equilibrar o custo da avaliao de IHC com os benefcios obtidos.
Para obter esses benefcios, uma avaliao de IHC no pode ser realizada
simplesmente entregando (um prottipo de) o sistema para alguns usurios utilizarem e
aguardando o relato espontneo de problemas. Pelo contrrio, avaliar a qualidade de uso
requer um planejamento cuidadoso da avaliao para que no sejam desperdiados
tempo e dinheiro.
Ao planejar uma avaliao de IHC, o avaliador deve decidir o que, quando, onde e
como avaliar, bem como os dados a serem coletados e produzidos, alm do tipo de
mtodo utilizado. Essas questes so importantes para orientar a escolha do mtodo de
avaliao, sua execuo e apresentao dos resultados. Nas prximas subsees,
discutimos cada uma delas.
9.2 O que Avaliar?
A questo fundamental de uma avaliao de IHC definir quais so os objetivos da
avaliao, a quem eles interessam e por qu. Os objetivos de uma avaliao determinam
quais aspectos relacionados ao uso do sistema devem ser investigados. Esses objetivos so
motivados por requisies, reclamaes ou comportamentos de qualquer interessado no
sistema (stakeholders): usurios, designers, cliente (dono do sistema), desenvolvedores,
departamento de marketing etc. Por exemplo, os usurios podem demonstrar
desinteresse em utilizar o sistema ou fazer reclamaes a respeito dele; o designer pode
desejar comparar alternativas de design; o cliente pode querer verificar se a alta
qualidade de uso um diferencial do seu produto; os desenvolvedores podem querer
examinar se a nova tecnologia empregada no desenvolvimento da interface agrada os
usurios; o departamento de marketing pode querer lanar um produto que atenda a
necessidades dos usurios ainda no exploradas pelos sistemas atuais; e assim por
diante. Portanto, o avaliador deve estar atento a situaes como essas para definir os
objetivos de uma avaliao de IHC de acordo com os interesses dos stakeholders. A
deciso sobre o que avaliar orienta o avaliador no planejamento, na execuo e na
apresentao dos resultados da avaliao de IHC.
possvel avaliar diversos aspectos relacionados ao uso de acordo com os interesses
dos stakeholders. Os principais aspectos avaliados so (Hix e Hartson, 1993; Rubin, 1994;
Mack e Nielsen, 1994; Sharp et al., 2007):
apropriao de tecnologia pelos usurios, incluindo o sistema computacional a ser
avaliado mas no se limitando a ele;
ideias e alternativas de design;
conformidade com um padro;
problemas na interao e na interface.
Avaliar a apropriao de tecnologia requer a participao dos usurios para permitir
uma melhor compreenso sobre: o contexto em que o sistema avaliado se insere, quais os
objetivos e as necessidades dos usurios, como os usurios costumam alcan-los, em
que grau as tecnologias disponveis satisfazem suas necessidades e preferncias e como
elas afetam sua vida pessoal e profissional.
A avaliao desse aspecto pode ser realizada em diferentes momentos do processo de
design. Pode consistir em um estudo exploratrio para apoiar a atividade de anlise.
Nesse caso, costumamos avaliar sistemas interativos existentes ou outras formas de
apoio s atividades dos usurios, buscando julgar se o uso da tecnologia atual
produtivo e identificar necessidades e oportunidades de interveno. J ao longo do
design, permite equipe de projeto julgar se existe um consenso entre a equipe de
design, os usurios e demais stakeholders sobre o que foi aprendido durante a elicitao e
anlise de requisitos e sobre a qualidade da soluo sendo projetada. Para isso, comum
utilizarmos como insumo prottipos do sistema sendo projetado, em geral representados
atravs de esboos de tela ou cenrios de uso, conforme apresentado no Captulo 7.
A avaliao da apropriao de tecnologia tambm permite compreender os efeitos da
introduo de um sistema interativo novo ou reprojetado no cotidiano dos usurios. Para
isso, devemos investigar como os usurios realizam suas atividades antes e depois da
interveno com o sistema, a fim de julgar se o (novo) sistema lhes oferece apoio
computacional adequado, conforme definido por algum fator que possa ser observado ou
medido. Podemos avaliar, por exemplo, se os usurios so capazes de atingir seus
objetivos em menos tempo, com um nmero menor de erros ou sem a necessidade de
treinamento prvio, se esto satisfeitos, se eles se sentem motivados a explorar e
aprender novas funcionalidades do sistema, se o uso do sistema agradvel e outras
opinies sobre aspectos gerais ou especficos do sistema. Esse tipo de investigao
tambm nos permite identificar motivos que levam os usurios a no incorporarem um
sistema interativo (ou parte dele) no seu cotidiano.
A avaliao de ideias e alternativas de design busca comparar diferentes alternativas de
soluo de acordo com critrios relacionados com o uso e com a construo da interface
com usurio. Por exemplo, com relao ao uso podemos avaliar a facilidade de
aprendizado, o apoio recuperao de erros ou o tipo de interveno pretendido na vida
dos usurios, enquanto com relao construo podemos avaliar o custo e o tempo
necessrios para o desenvolvimento de cada alternativa e a infraestrutura de hardware
necessria para executar cada proposta de soluo. Os critrios de anlise e dimenses de
comparao de alternativas de design devem ser definidos de acordo com os resultados
da anlise da situao atual, isto , o avaliador deve considerar o contexto de uso, os
objetivos, as necessidades e as preferncias dos usurios, como eles costumam satisfaz-
los e por que o fazem assim. A avaliao (comparativa ou no) de ideias e alternativas de
soluo costuma ser realizada de forma rpida e informal durante a atividade de design
como parte do ciclo iterativo de concepo da soluo final. comum utilizar prottipos
de interface em vrios nveis de detalhes nesse tipo de avaliao, mas tambm possvel
comparar solues de design de IHC prontas, ou seja, concretizadas em outros sistemas
interativos existentes. Essa avaliao pode ser realizada com ou sem a participao dos
usurios.
Avaliar a conformidade com um padro importante quando a soluo de IHC precisa
ter caractersticas especficas determinadas por padres estabelecidos. Por exemplo, pode
ser necessrio que a soluo de IHC esteja de acordo com os padres do W3C para
acessibilidade. Assim, podemos assegurar que usurios com certas limitaes fsicas no
encontraro barreiras intransponveis para acessar a interface do sistema e interagir com
ele. Tambm podemos avaliar se uma soluo de IHC segue os padres do ambiente
computacional em que ser inserida, como, por exemplo, padres estabelecidos pelos
ambientes de trabalho GNOME e KDE, ou pelos sistemas operacionais Microsoft
Windows e MacOS. Se esses padres forem seguidos, os usurios acostumados com
esses ambientes tendem a ter menos dificuldades para realizar operaes bsicas, tal
como redimensionar e fechar uma janela, por exemplo.
Alm disso, podemos verificar se a soluo de IHC est em conformidade com padres
utilizados em domnios especficos, como correio e comrcio eletrnico. Os usurios de
sistemas desses domnios j esto acostumados a certos termos e a certas formas de
realizar determinadas operaes. Desse modo, se a soluo de IHC estiver prxima das
convenes adotadas no domnio do sistema, os usurios tendem a ter menos
dificuldades para utiliz-lo porque j esto familiarizados com essas convenes. Uma
organizao tambm pode definir padres (no sentido de normas) para seus sistemas, e
exigir que as solues de IHC propostas estejam de acordo com esses padres. De
maneira geral, verificar a conformidade com padres contribui para a consistncia e
coerncia entre as solues de IHC que seguem esses padres. A avaliao desse aspecto
no exige a participao dos usurios.
Problemas na interao e na interface so os aspectos mais avaliados na rea de IHC.
Na avaliao desses aspectos, o avaliador pode contar ou no com a participao dos
usurios para coletar dados relacionados ao uso de sistemas interativos. Ele analisa os
dados coletados com objetivo de identificar problemas na interao e na interface que
prejudiquem a qualidade de uso do sistema. Os problemas identificados costumam ser
classificados de acordo com sua gravidade (grau de impacto nocivo), com a frequncia
em que tendem a ocorrer e com os fatores que compem os critrios de qualidade de uso
prejudicados usabilidade, experincia do usurio, acessibilidade ou comunicabilidade.
Por exemplo, um avaliador pode relatar e justificar um problema que prejudica a
facilidade de recordao (fator de usabilidade) e outro que dificulta a localizao na
interface de onde o usurio pode expressar determinada inteno de comunicao
durante o uso (etiqueta Cad? no mtodo de avaliao de comunicabilidade,
apresentado na Seo 10.2.2).
Os objetivos de uma avaliao de IHC precisam ser detalhados em perguntas mais
especficas para torn-los operacionais (Sharp et al., 2007). A elaborao dessas perguntas
deve considerar os usuriosalvo, suas atividades e os artefatos utilizados, que
normalmente incluem uma representao ou prottipo da soluo de IHC a ser avaliada.
A Tabela 9.1 apresenta exemplos de perguntas associadas aos objetivos de avaliao de
IHC descritos anteriormente.
Tabela 9.1
Exemplos de perguntas que uma avaliao de IHC pode responder.

objetivos exem plos de perguntas a serem respondidas


analisar a apropriao da De que maneira os usurios utilizam o sistema? Em que difere do planejado?
tecnologia Como o sistema interativo afeta o modo de as pessoas se comunicarem e relacionarem?
Que variao houve no nmero de erros cometidos pelos usurios ao utilizarem o novo sistema? E no tempo que levam para
atingir seus objetivos? E na sua satisfao com o sistema?
O quanto os usurios consideram o apoio computacional adequado para auxili-los na realizao de suas atividades?
O quanto eles so motivados a explorar novas funcionalidades?
Quais so os pontos fortes e fracos do sistema, na opinio dos usurios?
Quais objetivos dos usurios podem ser alcanados atravs do sistema? E quais no podem? Quais necessidades e desejos
foram ou no atendidos?
A tecnologia disponvel pode oferecer maneiras mais interessantes ou eficientes de os usurios atingirem seus objetivos?
O que possvel modificar no sistema interativo para adequ-lo melhor ao ambiente de trabalho?
Por que os usurios no incorporaram o sistema no seu cotidiano?
comparar ideias e alternativas Qual das alternativas a mais eficiente? Mais fcil de aprender?
de design Qual delas pode ser construda em menos tempo?
De qual delas se espera que tenha um impacto negativo menor ao ser adotada?
Qual delas torna mais evidente os diferenciais da soluo projetada?
Qual delas os usurios preferem? Por qu?
verificar a conformidade com O sistema est de acordo com os padres de acessibilidade do W3C?
um padro A interface segue o padro do sistema operacional? E da empresa?
Os termos na interface seguem convenes estabelecidas no domnio?
identificar problemas na Considerando cada perfil de usurio esperado:
interao e interface O usurio consegue operar o sistema?
Ele atinge seu objetivo? Com quanta eficincia? Em quanto tempo? Aps cometer quantos erros?
Que parte da interface e da interao o deixa insatisfeito?
Que parte da interface o desmotiva a explorar novas funcionalidades?
Ele entende o que significa e para que serve cada elemento de interface?
Ele vai entender o que deve fazer em seguida?
Que problemas de IHC dificultam ou impedem o usurio de alcanar seus objetivos?
Onde esses problemas se manifestam? Com que frequncia tendem a ocorrer? Qual a gravidade desses problemas?
Quais barreiras o usurio encontra para atingir seus objetivos?
Ele tem acesso a todas as informaes oferecidas pelo sistema?

A avaliao de qualquer aspecto relacionado ao uso de sistemas computacionais


interativos, principalmente os problemas na interao e na interface e a apropriao da
tecnologia pelos usurios, tambm fornece insumos para elaborar material de apoio e de
treinamento, tais como: tutoriais, instrues de uso e sistema de ajuda.
9.3 Quando Avaliar o Uso de um Sistema?
Os mtodos de avaliao de IHC podem ser aplicados em diferentes momentos do
processo de desenvolvimento, dependendo dos dados disponveis sobre a soluo de
IHC sendo concebida. Desde o incio da atividade de design, o designer explora ideias
alternativas de interveno na situao atual. Essas ideias so elaboradas e refinadas
atravs de ciclos de (re)design e avaliao, at o designer chegar a uma soluo de IHC
que possa ser construda. A avaliao de IHC realizada durante a elaborao da soluo,
ou seja, antes de termos uma soluo pronta, chamada de avaliao formativa ou
construtiva. A avaliao de IHC realizada depois de uma soluo estar pronta chamada
de avaliao somativa ou conclusiva (Hix e Hartson, 1993; Sharp et al., 2007).
A avaliao formativa realizada ao longo de todo o processo de design para
compreender e confirmar a compreenso sobre o que os usurios querem e precisam, e
para confirmar se e em que grau a soluo sendo concebida atende s necessidades dos
usurios com a qualidade de uso esperada. Ela envolve principalmente analisar e
comparar ideias e alternativas de design durante a elaborao da soluo de IHC. A
avaliao formativa permite identificar to cedo quanto possvel problemas na interao e
na interface que possam prejudicar a qualidade de uso, quando os custos de correo
ainda so baixos. Diversos artefatos que representam partes de uma soluo de IHC
podem servir de insumo para uma avaliao formativa, tais como: cenrios de uso,
esboos de tela, storyboards, modelagem da interao e prottipos do sistema em
diferentes nveis de detalhe e fidelidade com a soluo final, conforme apresentado no
Captulo 7.
A avaliao somativa realizada ao final de um processo de design, quando existir
uma soluo (parcial ou completa) de interao e de interface pronta, de acordo com um
escopo definido. A soluo de IHC final pode ser representada por um prottipo de
mdia ou alta fidelidade, ou at mesmo pelo sistema interativo implementado. A
avaliao somativa julga a qualidade de uso de uma soluo de IHC buscando evidncias
que indiquem que as metas de design foram alcanadas, ou seja, que o produto possui os
nveis de qualidade de uso desejados.
No planejamento da avaliao, o avaliador deve identificar em que momento no
processo de desenvolvimento a avaliao ser realizada. Isso lhe permite saber quais
representaes da soluo de IHC estaro disponveis ou se o prprio sistema pronto e
funcionando estar acessvel. Esse conhecimento auxilia na escolha do mtodo de
avaliao a ser empregado.
9.4 Onde Coletar Dados sobre Experincias de
Uso?
A interao usuriosistema afeta e afetada pelo contexto de uso, que abrange o
ambiente fsico, social e cultural em que ela ocorre. Em particular, o usurio costuma
utilizar outros artefatos em conjunto com o sistema e interagir com outras pessoas
enquanto o utiliza. Por exemplo, o usurio pode fazer anotaes em papel; ele tem a
liberdade de organizar as informaes de um modo particular nos diversos artefatos
utilizados (no papel, sobre a mesa, em pastas, gavetas, armrios etc.); ele pode consultar
informaes sobre o domnio que estejam fora do sistema; o telefone pode tocar no meio
de uma operao ou algum pode conversar com o usurio, distraindo sua ateno; o
usurio pode passar por situaes de presso e cobrana maior no trabalho; a conexo
com a Internet pode falhar; e assim por diante. Todos esses elementos e acontecimentos
comuns num contexto real podem afetar o uso de um sistema interativo. Conhecer esses
fatores importante para avaliar a adequao do sistema ao ambiente real em que ele
ser utilizado.
As avaliaes de IHC que envolvem a participao dos usurios podem ser realizadas
em contexto real de uso ou em laboratrio. A avaliao em contexto, que constitui uma
forma de estudo de campo (veja Seo 5.5.6), aumenta as chances de verificarmos a
qualidade de uso da soluo de IHC perante um conjunto maior e mais diversificado de
situaes de uso. Apesar de no ser capaz de analisar todas as situaes de uso possveis,
esse tipo de avaliao fornece dados de situaes tpicas de uso que no seriam
percebidos em uma avaliao em laboratrio. Ela permite entender melhor como os
usurios se apropriam da tecnologia no seu cotidiano e quais problemas podem ocorrer
em situaes reais de uso. Todavia, difcil controlar a execuo de uma avaliao em
contexto para assegurar que certos aspectos do sistema sejam analisados.
A avaliao em laboratrio oferece um controle maior sobre as interferncias do
ambiente na interao usuriosistema e facilita o registro de dados das experincias de
uso com a soluo de IHC avaliada. O laboratrio um ambiente preparado para
proporcionar experincias de uso sem interrupes ou inconvenientes que podem
ocorrer em um contexto real de uso e at mesmo atrapalhar certos aspectos da avaliao
do sistema. Uma avaliao em laboratrio permite comparar de forma consistente as
experincias que diferentes usurios tiveram com o sistema. Sem as interferncias do
contexto de uso, o usurio possui melhores condies de manter o foco nas tarefas sendo
avaliadas.
Dependendo do mtodo utilizado, uma sala de reunio com mesa e cadeiras pode ser
um ambiente adequado para realizar uma avaliao. Esse o caso dos mtodos de grupo
de foco e prototipao em papel. Outros mtodos de avaliao so mais indicados para
ambientes especiais que favoream a observao, como, por exemplo, o teste de
usabilidade e o mtodo de avaliao de comunicabilidade. Nesses casos, o laboratrio
costuma ser um ambiente projetado e construdo para facilitar a observao e o registro
de dados sobre experincias de uso. De qualquer forma, apesar de ser um ambiente
artificial, o laboratrio deve ser confortvel para os participantes da avaliao, conforme
visto na Seo 5.4.
Um ambiente de observao de uso costuma possuir duas salas: uma sala onde o
usurio vai utilizar o sistema (sala de uso) e outra onde o avaliador vai observ-lo atravs
de um vidro espelhado (sala de observao). Desse modo, quem est dentro da sala de uso
no consegue ver o que as pessoas que esto na sala de observao esto fazendo. Pelo
menos um avaliador fica na sala de observao, fazendo anotaes e acompanhando a
interao do participante atravs de um monitor clone, que reproduz tudo o que ocorre
no monitor do participante. Um outro avaliador pode ficar atrs do participante como
apoio, mas buscando no expressar opinies ou fornecer instrues que prejudiquem ou
invalidem a avaliao.
Em geral, apresentamos ao participante a sala de observao para que ele conhea o
que fica do outro lado do vidro espelhado, entenda melhor o procedimento de avaliao
e, assim, fique mais tranquilo. O objetivo do vidro espelhado diminuir a interferncia
das aes dos observadores sobre o comportamento do participante. Desse modo, os
avaliadores que estiverem na sala de observao durante a sesso podem fazer anotaes
livremente ou consultar algum material de apoio, sem com isso influenciar os resultados
da avaliao. A Figura 9.1 apresenta um exemplo de layout de laboratrio para observar a
experincia de uso de um participante.

FIGURA 9.1 Exemplo de laboratrio para observar um participante utilizando um sistema computacional
interativo.

O registro dos dados observados pode ser feito de vrias formas, orientado direta ou
indiretamente pelo mtodo de avaliao. A sala de uso deve ter microfones e cmeras de
vdeo para gravar falas, gestos e expresses do participante, e um computador com
software instalado para capturar um vdeo da interao do participante com o sistema e,
ocasionalmente, registrar uma lista das teclas digitadas durante a experincia de uso.
Outras configuraes de laboratrio so possveis dependendo do sistema avaliado.
Por exemplo, se for avaliado um sistema de TV digital interativa, a sala de uso deve ter
um sof e uma TV, em vez de uma mesa com computador pessoal e uma cadeira. Uma
outra instalao consiste numa sala para diversos observadores, e uma sala de controle,
por exemplo, para avaliaes do tipo Wizard of Oz, nas quais o participante do teste pensa
estar interagindo com o sistema, mas de fato uma pessoa que est enviando as
respostas do sistema para o seu terminal.
9.5 Que Tipos de Dados Coletar e Produzir?
Dependendo do tipo de avaliao, o avaliador pode coletar dados sobre a situao atual,
uso atual da tecnologia, aspectos positivos e negativos identificados durante esse uso,
necessidades e oportunidades de interveno. A abrangncia e o foco da coleta de dados
devem ser definidos de acordo com os objetivos da avaliao. Por exemplo, se o objetivo
for verificar se determinado sistema (ou prottipo) satisfaz as necessidades dos
usurios, um avaliador poderia coletar dados sobre: o grau de satisfao dos usurios
em relao ao sistema; se os usurios sentem necessidade de utilizar outros sistemas ou
artefatos para realizarem suas atividades e por que so necessrios; quais so os pontos
fortes e fracos do sistema avaliado; o que os usurios gostariam que fosse melhorado ou
estendido; e assim por diante. Se o objetivo for outro, como, por exemplo, identificar
problemas na interao e interface de determinado sistema (ou prottipo), o avaliador
poderia coletar dados sobre: quantos usurios conseguiram concluir certas tarefas;
quanto tempo foi necessrio para concluir cada tarefa; quais erros foram cometidos, em
que locais da interface e com que frequncia; quantos usurios sentiram necessidade de
consultar material de apoio (tutoriais, manuais de uso, ajuda on-line etc.) e em quais
momentos da interao o fizeram, quais eram as dvidas e se foram esclarecidas e assim
por diante.
Os dados coletados so interpretados e analisados de acordo com o mtodo de
avaliao escolhido, para produzirem resultados que atendam aos objetivos da avaliao,
ou seja, que busquem responder as perguntas especficas elaboradas na definio da
avaliao. Cada mtodo descrito no prximo captulo fornece ao avaliador orientaes
mais detalhadas sobre quais dados coletar, como analis-los e quais dados produzir como
resultado da avaliao.
Os dados coletados e produzidos em uma avaliao de IHC podem ser classificados de
diferentes maneiras. As classificaes mais comuns so: nominais, ordinais, de intervalo
e de razo (Stevens, 1946; Kiess, 2002; Levine et al., 2008); dados qualitativos e
quantitativos (Hix e Hartson, 1993; Sharp et al., 2007); dados subjetivos e objetivos
(Meister e Rabideau, 1965). Como visto ao longo do prximo captulo, cada mtodo de
avaliao de IHC privilegia dados e resultados de diferentes tipos.
Dados nominais ou categricos representam conceitos na forma de rtulos ou
categorias. Por exemplo, uma pessoa pode ser classificada conforme sua origem tnica
em caucasiana, africana, hispnica, asitica ou outra. Podemos atribuir um nmero para
dar nome categoria (e.g., 1=caucasiano), mas esse nmero no transmite qualquer
informao quantitativa, apenas serve como identificao dos dados, e poderia ser
substitudo por letra sem qualquer perda de informao.
Entre dados nominais no existe qualquer relao de ordem. Por exemplo, no se pode
dizer que um dado nominal maior ou menor, melhor ou pior, ou mais alto ou mais
baixo do que outro. possvel dizer que os dados nominais so iguais ou diferentes, mas
nem sempre se consegue caracterizar o tipo de diferena que existe entre eles. Exemplos
de dados nominais so: atividades que um usurio realiza no sistema, sistemas
semelhantes que o usurio j utilizou, formas de acesso Internet que o usurio utiliza,
idiomas que ele entende e nos quais sabe se expressar e problemas enfrentados durante
uma sesso de avaliao.
Dados ordinais, como o prprio nome revela, representam conceitos com relaes que
definem algum tipo de ordem entre eles. Essencialmente, dados ordinais produzem um
ranqueamento entre pessoas ou coisas, no qual algum ou algo possui uma varivel em
maior quantidade ou intensidade do que outros (Kiess, 2002). Por exemplo, a relao
entre o Web site que um usurio mais utiliza e o segundo site mais utilizado por ele.
Embora possamos identificar se um dado ordinal maior ou menor que outro, no
podemos quantificar com preciso a sua diferena. Por exemplo, possvel que, por trs
dos dados ordinais sobre os sites A, B e C, em ordem de frequncia de uso, esteja o fato
de o usurio visitar o site A diversas vezes ao dia, o site B uma vez por dia e o site C a
cada 15 ou mais dias. Em outras palavras, ao analisar dois ou mais dados ordinais,
possvel dizer qual maior ou melhor, mas no em quanto.
Se, alm da relao de ordem entre os dados, h uma diferena de igual magnitude
entre eles, tratam-se de dados de intervalo (ou intervalares). Eles representam perodos,
faixas ou distncias entre os dados ordinais, mas a origem da escala arbitrria, ou seja,
uma medida de intervalo no possui um valor zero verdadeiro para indicar a total ausncia
da varivel medida (Kiess, 2002). Por exemplo, na escala de temperatura em graus
Celsius, podemos afirmar que a diferena entre 20oC e 40oC a mesma que entre 40oC e
60oC. No entanto, no podemos afirmar que a temperatura de 40oC duas vezes maior do
que a temperatura de 20oC. J um dado de razo possui um valor zero verdadeiro, como,
por exemplo, o tempo que uma pessoa leva para realizar uma tarefa. Se os participantes
P1 e P2 levaram dois e seis minutos para realizar uma tarefa, respectivamente, faz sentido
dizer que P2 levou o triplo do tempo de P1 para realiz-las. Tambm so dados de razo a
frequncia de acesso Internet, o nmero de erros cometidos, o nmero de contatos que
um usurio possui em uma comunidade virtual.
Os dados coletados com as escalas frequentemente utilizadas em questionrios de
IHC, como as escalas de Likert e os diferenciais semnticos (veja Seo 5.5.2), no so
estritamente intervalares. No entanto, costumam ser considerados como dados de
intervalo nas estatsticas produzidas, no apenas em IHC, mas tambm nas cincias
comportamentais (Kiess, 2002).
Dados qualitativos representam conceitos que no so representados numericamente.
Alm dos dados nominais, tambm so dados qualitativos as respostas livres coletadas
em questionrios e entrevistas, tais como expectativas, explicaes, crticas, sugestes e
outros tipos de comentrio.
J os dados quantitativos representam numericamente uma quantidade, ou seja, uma
grandeza resultante de uma contagem ou medio, tais como: o tempo e nmero de
passos necessrios para alcanar determinado objetivo; o nmero de erros cometidos
durante uma sesso de uso; quantas vezes a ajuda on-line e o manual de uso foram
consultados; e quantos usurios conseguiram alcanar o objetivo satisfatoriamente
(Wixon e Wilson, 1997). Nessa classificao se encaixam os dados ordinais, intervalares e
de razo.
Os dados quantitativos so utilizados com frequncia para verificar hipteses,
possivelmente formuladas a partir de uma teoria ou de uma pesquisa qualitativa prvia.
Por exemplo, a hiptese de que uma soluo A melhor do que uma soluo B poderia
ser verificada, dentre outras maneiras, contabilizando quantos usurios conseguem
concluir certas tarefas em um tempo determinado utilizando cada soluo. Nesse caso,
obteramos resultados do tipo: na soluo A, 61% dos usurios concluram as tarefas com
sucesso, 23% deles concluram metade das tarefas, e 16% no concluram sequer a
metade das tarefas. J na soluo B, os dados coletados foram 82%, 13% e 5%,
respectivamente. Analisados isoladamente, esses nmeros no explicam por que alguns
usurios no concluram as tarefas. Tambm no sugerem recomendaes para tornar a
soluo A ainda mais adequada aos usurios e s suas tarefas. Apenas fornecem
evidncias de que a soluo A melhor do que a soluo B e, caso os resultados sejam
estatisticamente significativos, comprova a hiptese do estudo.
Diferente do foco na contagem e medio de quantidades realizadas na anlise de dados
quantitativos, a anlise de dados qualitativos envolve principalmente a interpretao de
conceitos por eles representados. Por isso, ao escolher trabalhar com dados qualitativos,
um avaliador normalmente est interessado em explorar e explicar o que ocorreu (ou pode
ocorrer) durante a interao usuriosistema e como, em vez de testar uma hiptese.
A terceira classificao que utilizamos distingue dados objetivos e subjetivos. Dados
objetivos podem ser medidos por instrumentos ou software, como, por exemplo, os
termos que um participante utilizou para realizar uma determinada busca, as msicas
que ele mais ouviu no ltimo ms no seu computador e o tempo que ele levou para
realizar uma tarefa numa sesso de teste. J os dados subjetivos precisam ser
explicitamente expressos pelos participantes da avaliao, como opinies e preferncias.
Nem todo uso de dados qualitativos consiste na realizao de uma pesquisa
qualitativa. A pesquisa qualitativa consiste em um conjunto de prticas interpretativas e
materiais que tornam o mundo visvel e transformam-no em uma srie de
representaes, incluindo anotaes em campo, entrevistas, conversas, fotografias,
gravaes e anotaes pessoais. A pesquisa qualitativa envolve uma abordagem
interpretativa e naturalista do mundo, atravs da coleo e anlise de uma variedade de
materiais empricos que descrevem momentos e significados rotineiros e problemticos
nas vidas dos indivduos. Esses materiais incluem: estudo de caso, experincia pessoal,
introspeco, histria de vida, entrevistas, artefatos, textos e produes culturais, textos
observacionais, histricos, interacionais e visuais. Os pesquisadores estudam as coisas
em seu ambiente natural, buscando interpretar os fenmenos em termos dos
significados que as pessoas lhes do. Eles utilizam uma ampla gama de prticas
interpretativas inter-relacionadas, sempre buscando obter um melhor entendimento do
assunto em questo (Denzin e Lincoln, 2005, p. 4).
9.6 Qual Tipo de Mtodo de Avaliao Escolher?
Existem vrios mtodos para avaliar a qualidade de uso propostos na literatura. Cada
mtodo atende melhor a certos objetivos de avaliao, orienta explicita ou implicitamente
quando e onde os dados devem ser coletados, como eles devem ser analisados, e quais
critrios de qualidade de uso (usabilidade, experincia do usurio, acessibilidade ou
comunicabilidade) sua anlise privilegia. Os mtodos de avaliao de IHC podem ser
classificados em: mtodos de investigao, de observao de uso e de inspeo.
Os mtodos de investigao (inquiry) envolvem o uso de questionrios, a realizao de
entrevistas, grupos de foco e estudos de campo, entre outros. Esses mtodos permitem
ao avaliador ter acesso, interpretar e analisar concepes, opinies, expectativas e
comportamentos do usurio relacionados com sistemas interativos. Em particular,
permitem investigar alternativas de design, problemas que os usurios costumam
enfrentar, como eles se apropriaram da tecnologia existente e quais so suas expectativas
para futuras interaes com tecnologias atuais e novas. So frequentemente utilizados
em etapas iniciais do processo de design, para ratificar ou retificar o entendimento da
situao atual e identificar necessidades e oportunidades de interveno (i.e., em
anlise), bem como explorar formas alternativas de interveno (i.e., em avaliao
formativa). Tambm so utilizados para avaliar a introduo da nova tecnologia (i.e., em
avaliao somativa). Em geral, os mtodos de avaliao atravs de investigao no
exigem que os usurios utilizem um sistema interativo durante a coleta de dados. No
entanto, o uso de um sistema ou de materiais de apoio, como imagens, cenrios e outros
tipos de artefatos, pode contribuir para a investigao, ajudando os usurios a se
lembrarem de suas experincias e expectativas e tambm a manterem o foco nas questes
de interesse. Os dados obtidos atravs de investigao com usurios e demais
stakeholders podem ser coletados atravs das tcnicas discutidas no Captulo 5, tais como:
entrevista, questionrio, grupo de foco, estudo de campo e investigao contextual.
Os mtodos de inspeo permitem ao avaliador examinar (ou inspecionar) uma
soluo de IHC para tentar antever as possveis consequncias de certas decises de
design sobre as experincias de uso. Em outras palavras, tentar identificar problemas que
os usurios podem vir a ter quando interagirem com o sistema. Esses mtodos
geralmente no envolvem diretamente usurios e, portanto, tratam de experincias de
uso potenciais, e no reais. Alm de permitir comparar designs alternativos e buscar
problemas em solues de IHC, os mtodos de inspeo permitem ainda avaliar a
conformidade com um padro ou guia de estilo.
Ao inspecionar uma interface, os avaliadores tentam se colocar no lugar de um usurio
com determinado perfil, com um certo conhecimento e experincia em algumas
atividades. Mas existe um limite na empatia do avaliador; de fato, ele no o usurio. Ele
pode deixar de encontrar problemas que os usurios teriam, e tambm pode julgar como
problemticos pontos que no causariam dificuldades aos usurios. Alm disso, um
avaliador pode se concentrar mais em alguns aspectos de usabilidade do que em outros
(Nielsen, 1993). Sempre que possvel, devemos buscar dados de diferentes fontes e
mtodos de avaliao para fazer uma apreciao mais robusta do sistema em questo. Os
mtodos de avaliao atravs de inspeo, tambm denominados mtodos analticos,
podem ser utilizados ao longo de todo o processo de design, medida que modelos ou
prottipos so elaborados. Costumam ser mais rpidos e ter um custo menor do que
mtodos que envolvem usurios. Alguns mtodos de inspeo so descritos na Seo
10.1.
Os mtodos de observao fornecem dados sobre situaes em que os usurios
realizam suas atividades, com ou sem apoio de sistemas interativos. Atravs do registro
dos dados observados, esses mtodos permitem identificar problemas reais que os
usurios enfrentaram durante sua experincia de uso do sistema sendo avaliado. O
avaliador pode observar os usurios em contexto ou em laboratrio. A observao em
contexto permite coletar uma gama mais ampla de dados mais ricos sobre a atuao dos
usurios em seu ambiente de atividade (veja estudos de campo na Seo 5.5.6). J a
observao em laboratrio costuma ser mais direcionada e simples, pois o avaliador tem
controle sobre o ambiente. Alguns mtodos de avaliao atravs de observao em
laboratrio, tambm denominados de mtodos empricos, so descritos na Seo 10.2.
Mtodos de avaliao por inspeo costumam ser mais rpidos e de custo de execuo
mais baixo do que os mtodos de investigao e de observao, pois eles no gastam
tempo com recrutamento e sesses de coleta de opinies ou de observao de usurios.
Por exemplo, Salgado et al. (2006) relatam que uma avaliao por inspeo (avaliao
heurstica) gastou menos da metade do tempo do que uma avaliao com a participao
dos usurios (avaliao de comunicabilidade). Entretanto, os resultados de uma avaliao
por inspeo so baseados apenas na experincia do avaliador, com base em hipteses
sobre os usurios. Mesmo que o avaliador se coloque no lugar do usurio, ele no o
usurio. No podemos ignorar os limites dessa empatia do avaliador. Apesar de ser
necessrio mais tempo para coletar e analisar dados empricos de experincias de uso, os
mtodos de avaliao atravs de investigao e observao costumam fornecer resultados
mais interessantes do que as previses dos avaliadores. Isso se deve ao fato de que os
usurios percorrem caminhos no previstos pelo avaliador, de forma criativa e
oportunista, proporcionando maior realidade, riqueza e diversidade nas experincias de
uso analisadas.
Os objetivos da avaliao, detalhados por questes especficas, so os guias principais
para o avaliador escolher os mtodos de avaliao a serem utilizados. Se o objetivo da
avaliao for encontrar problemas de IHC, o avaliador pode julgar mais adequado
empregar um mtodo por inspeo para cobrir (quase) toda a interface, e selecionar um
pequeno nmero de partes importantes a serem avaliadas por um mtodo de observao
ou de investigao. Geralmente, ele selecionaria as partes cuja inspeo no forneceu
resultados suficientemente confiveis. J avaliar a forma como os usurios se apropriam
de tecnologia requer o emprego de um mtodo de avaliao atravs de investigao ou de
observao, por contar com a participao dos usurios. E, para avaliar a conformidade
com um padro, mais adequado empregar um mtodo de avaliao por inspeo, pois a
participao dos usurios desnecessria.
Alm disso, o avaliador precisa escolher mtodos de avaliao adequados ao prazo,
oramento, equipamentos, nmero de usurios acessveis, nmero de avaliadores
capacitados e experientes em cada mtodo e demais recursos disponveis. Ao planejar a
avaliao, ele tem de verificar se poder contar com a participao dos usurios para
coletar e registrar dados sobre experincias de uso, ou se dever inspecionar a interface
para tentar prev-las. Essas questes prticas so responsveis por viabilizar a execuo
da avaliao de IHC planejada. No adianta o avaliador planejar uma avaliao de IHC
sem ter condies de execut-la. Por exemplo, o avaliador deve verificar se possvel ter
acesso ao contexto de uso com o tempo e a liberdade necessrios, para que possa
observ-lo adequadamente e coletar e registrar livremente os dados necessrios.
9.7 Como Avaliar?
Os mtodos de avaliao de IHC possuem as seguintes atividades bsicas: preparao,
coleta de dados, interpretao, consolidao e relato dos resultados. Caso a avaliao
encontre problemas ou oportunidades de melhoria, tambm planejado um reprojeto do
sistema.

9.7.1 Por Onde Comear?


Como primeiro passo para preparar uma avaliao, o avaliador deve aprender sobre a
situao atual, que inclui o domnio do problema, os papis e perfis dos usurios, seus
objetivos e atividades, e o contexto em que o sistema ou ser utilizado. O avaliador
tambm deve conhecer as interfaces dos sistemas complementares ou semelhantes com
os quais os usurios estejam acostumados a utilizar, alm de, claro, a interface do
prprio sistema ou prottipo a ser avaliado. Sempre que possvel, o avaliador deve buscar
saber quais so os comportamentos e as dificuldades tpicos dos usurios durante o uso
de sistemas interativos semelhantes. O Captulo 5 apresenta algumas tcnicas de anlise
que podem auxiliar os avaliadores nesse aprendizado.
Alm de necessrio para planejar a avaliao adequadamente, esse entendimento
contribui para a coleta e anlise dos dados. No caso de uma avaliao por inspeo, ajuda
os avaliadores a se colocarem no lugar dos usurios ao tentarem prever problemas na
interface e na interao. No caso de uma avaliao atravs de investigao ou de
observao, ajuda os avaliadores a compreenderem certos dados fornecidos pelos
usurios.

9.7.2 Preparao
Apesar de alguns equivocadamente considerarem-na burocrtica, a atividade de
preparao fundamental para a conduo adequada de uma avaliao que fornea
resultados teis e confiveis. Ela no pode ser negligenciada, pois pode acarretar em
desperdcio de tempo, dinheiro e outros recursos, envolvendo avaliadores, usurios e
demais interessados na avaliao.
Os objetivos da avaliao so definidos com base em requisies, reclamaes ou
comportamentos dos stakeholders do sistema. Se o avaliador conhece o que ser avaliado,
ele tem melhores condies de compreender as motivaes dos interessados e de ajud-
los a definir adequadamente os objetivos da avaliao. Os objetivos devem ser
detalhados atravs de questes mais especficas que a avaliao dever responder,
conforme apresentado na Seo 9.2.
Raramente avaliamos o sistema inteiro. Em vez disso, precisamos definir o escopo da
avaliao, delimitando quais partes da interface, caminhos de interao, tarefas e perfis
de usurio devem fazer parte da avaliao. Essa delimitao feita de acordo com os
objetivos e as questes que a avaliao pretende responder. Na escolha das tarefas a
serem investigadas, o avaliador pode considerar as tarefas mais importantes para os
usurios, as que apresentam mais problemas durante sua realizao usando a tecnologia
atual, as que foram mais difceis de projetar, as que motivaram a produo dos sistema
ou as que so o diferencial do sistema com relao a sistemas semelhantes ou
complementares. Alm disso, o avaliador deve considerar o prazo e os recursos
disponveis. Uma sesso de teste com usurios, por exemplo, costuma durar em torno de
uma hora.
O avaliador escolhe um ou mais mtodos de acordo com os objetivos da avaliao, dos
recursos disponveis e do acesso aos usurios e ao contexto de uso, conforme
apresentado na Seo 9.6. Caso seja escolhido um mtodo de avaliao que envolva
usurios, o avaliador deve tambm escolher o perfil e o nmero de participantes, com
base nos perfis de usurios, nos objetivos e no escopo da avaliao. Por exemplo, se o
objetivo for verificar como usurios novatos aprendem a realizar determinadas tarefas
utilizando o sistema, o avaliador deve recrutar usurios inexperientes no uso do sistema
e na realizao das tarefas em questo.
Os avaliadores devem buscar participantes que representem o pblico-alvo do sistema
avaliado, ou seja, que possuam caractersticas semelhantes aos usurios tpicos. A
definio dos perfis de participantes pode considerar fatores como: idade, sexo, formao
acadmica, grau de conhecimento sobre o domnio, nvel de experincia na realizao das
tarefas e nvel de experincia no uso do sistema avaliado e de sistemas semelhantes, por
exemplo. Sempre que possvel e pertinente, o avaliador deve buscar equilibrar o nmero
de homens e mulheres.
Dumas e Redish (1999) relatam que uma avaliao de IHC em geral envolve de cinco a
12 usurios. Nielsen (2000), por sua vez, afirma que bastam cinco usurios para
encontrarmos a maioria dos problemas na interface (85%, segundo o seu experimento),
alcanando uma boa relao custobenefcio. Caso seja necessrio obter resultados
estatisticamente significativos, a amostra de usurios deve ser suficientemente grande e
representativa. Entretanto, o tempo e outros recursos necessrios para a coleta e anlise
de dados de muitos usurios pode inviabilizar uma abordagem estatstica. Por isso, uma
avaliao de IHC com frequncia pretende apenas obter indcios sobre a qualidade de
uso do sistema e sobre como aument-la. Em outras palavras, mesmo quando os
resultados no so estatisticamente significativos, eles podem ser teis para o reprojeto
do sistema avaliado.
O planejamento de uma avaliao envolve questes prticas, que incluem alocar
pessoal, recursos e equipamentos e preparar o material de apoio. Uma avaliao com
usurios requer tambm a preparao do ambiente de teste, a realizao de um teste-
piloto e o recrutamento dos participantes. Ela envolve ainda questes ticas,
apresentadas na Seo 5.4.
De acordo com os mtodos de avaliao escolhidos, o avaliador deve alocar pessoal,
recursos e equipamentos necessrios. Pode ser preciso alocar outros avaliadores que
auxiliem na coleta, anlise e divulgao dos resultados. Caso os avaliadores tenham
pouca experincia com o mtodo selecionado, eles podem precisar de treinamento.
Equipamentos para o registro de dados, como cmeras, mquinas fotogrficas e
gravadores de udio so comumente utilizados na coleta de dados, e equipamentos mais
sofisticados podem requerer a contratao de profissionais especializados. Diversos
softwares podem apoiar as diferentes atividades de avaliao, desde a captura de dados
at a anlise e divulgao dos resultados.
Antes de comear a coletar dados, o avaliador deve preparar e imprimir o material de
apoio necessrio. No caso de avaliaes que envolvam participantes, esse material
costuma incluir:
termo de consentimento, de acordo com os cuidados ticos necessrios (veja Seo 5.4);
questionrio pr-teste (ou roteiro de entrevista estruturada) para coletar informaes
dos participantes que podem influenciar a interao usuriosistema, tais como:
caractersticas pessoais, experincias anteriores com tecnologia e conhecimento sobre
o domnio;
roteiro de entrevista ps-teste para coletar informaes sobre a opinio e os
sentimentos do participante decorrentes da experincia de uso observada;
instrues e cenrios para orientar os participantes sobre as tarefas a serem realizadas;
roteiro de acompanhamento da observao, de modo a facilitar a captura de dados e
anotaes.
Para assegurar a validade do estudo, importante que todos os participantes recebam
o mesmo material, as mesmas informaes e orientaes.
Quando for elaborar os cenrios de tarefa, o avaliador deve estar atento ao tempo
necessrio para os participantes realizarem as tarefas descritas. O tempo estimado para
um participante realizar cada tarefa no deveria ultrapassar 20 minutos. Se for necessrio
mais tempo, o participante deve poder fazer uma pausa rpida para evitar que sua fadiga
fsica ou mental interfira no resultado da avaliao. Podemos sugerir, por exemplo, que o
participante desvie o olhar para um ponto distante depois de passar algum tempo
olhando somente para a tela, ou faa um alongamento das mos e dos braos depois de
usar o teclado e o mouse durante algum tempo. Cada participante normalmente
despende cerca de uma hora numa sesso de avaliao. Mais do que isso seria cansativo
para ele (Sharp et al., 2007). Caso o avaliador tenha dificuldade de planejar tarefas curtas,
ele pode revisar o escopo da avaliao.
O formulrio de acompanhamento das sesses de observao facilita a anotao de
dados importantes para anlise da interao, tais como: falas espontneas do usurio
durante o uso, se o usurio conseguiu ou no concluir uma tarefa, se foi necessrio ajud-
lo em uma tarefa para prosseguir com a tarefa seguinte etc. Alm de observar e registrar
dados durante uma sesso de interao, o avaliador pode usar entrevistas curtas antes e
depois da execuo das tarefas para coletar outros dados importantes.
O avaliador deve preparar todo ambiente, hardware e software necessrio para o uso
do sistema avaliado e a captura de dados. Todas as instalaes, configuraes e demais
procedimentos de preparao para a sesso de avaliao devem ser concludos antes de
receber cada participante. Devemos configurar e testar cmeras de vdeo, gravadores de
udio, monitores-clone para o registro e acompanhamento das aes do participante e
softwares que capturem diversos dados como, por exemplo, um filme da interao do
usurio com o sistema, as teclas digitadas e os movimentos e as aes com o mouse. O
laboratrio deve estar limpo e arrumado para receber os participantes. Quando os
participantes forem utilizar o sistema, ele deve estar funcionando perfeitamente.
Concludo todo o planejamento da avaliao, muito importante que o avaliador
realize um teste-piloto. O objetivo desse teste avaliar o prprio planejamento, e analisar
se a avaliao, tal como planejada, produz os dados necessrios para responder a
questes e objetivos do estudo. O avaliador deve conduzir o teste-piloto como se fosse
uma sesso normal de avaliao. Dessa forma, ele tem oportunidade de verificar se a
linguagem nas explicaes e nos materiais fornecidos clara e objetiva, e se esses
materiais contm informaes adequadas e suficientes para orientar o participante
durante a avaliao. O teste-piloto tambm permite ao avaliador verificar se o sistema a
ser avaliado, os equipamentos e os softwares para registrar os dados esto funcionando
corretamente, e se o tempo necessrio para executar as tarefas solicitadas adequado.
Mas o teste-piloto no se limita atividade de coleta de dados. O avaliador deve fazer
uma breve anlise dos dados coletados, para se certificar de que eles permitiro
responder as questes de avaliao. A escolha de quais dados devem ser coletados deve
ser cuidadosa. Devemos registrar apenas dados que possam contribuir com os objetivos
da avaliao. Alm do desperdcio de recursos, registrar dados desnecessrios pode
tornar a sesso de uso mais artificial e constrangedora para os participantes. Por
exemplo, gravar a imagem dos participantes em vdeo pode intimid-los
desnecessariamente, caso o vdeo no seja analisado.
Se algum problema for detectado no teste-piloto, o planejamento da avaliao e o
material de apoio devem ser corrigidos. Caso sejam feitas muitas mudanas ou o
avaliador sinta necessidade, outros testes-pilotos podem ser executados, at que tudo
esteja pronto para a realizao da avaliao definitiva. Os dados do teste-piloto devem ser
descartados, pois podem estar contaminados por problemas que ocorreram durante o
piloto ou no serem compatveis ou vlidos considerando o planejamento revisado da
avaliao.
Caso haja um nmero reduzido de pessoas com o perfil desejado disponveis para
participar dos testes, o avaliador pode convidar para o teste-piloto uma pessoa com perfil
um pouco diferente do desejado. Para o teste-piloto, no h muito problema em convidar
um colega de trabalho, um amigo, ou uma pessoa mais prxima do avaliador, pois os
dados coletados sero descartados. Entretanto, esse participante no deve ter se
envolvido no planejamento e na preparao da avaliao.
Com o planejamento da avaliao concludo, o avaliador recruta os participantes para
as sesses de avaliao. Para recrutar participantes com os perfis especificados, o
avaliador pode utilizar questionrios ou entrevistas curtas a fim de conferir se uma
pessoa possui o perfil desejado. Ao convidar os participantes selecionados, o avaliador
deve esclarecer brevemente quais so os objetivos da avaliao, como e onde ela ser
realizada, e quanto tempo ser requerido do participante. Desde o primeiro contato com
o participante, o avaliador deve estar aberto e disposto a esclarecer suas eventuais
dvidas sobre a avaliao. Confirmada a disponibilidade e o interesse do participante, o
avaliador deve agendar com ele a data, o horrio e o local para a realizao da avaliao.
Sempre que possvel, o avaliador deve evitar selecionar seus conhecidos, amigos,
alunos, subordinados ou pessoas com as quais possua alguma relao prxima, para
evitar que a relao entre ele e o participante influencie ou contamine os dados coletados.
Por exemplo, um amigo e um aluno podem no relatar problemas que perceberam na
interface por se sentirem criticando o trabalho do avaliador amigo ou professor. De
qualquer modo, o avaliador pode atenuar a interferncia das relaes entre eles
esclarecendo que o objetivo da avaliao encontrar problemas na interface e que a
opinio dos participantes importante para melhor-la.

9.7.3 Coleta De Dados


A coleta de dados deve ocorrer conforme o planejamento realizado e o mtodo de
avaliao selecionado. No caso de mtodos de avaliao por inspeo, essa atividade
envolve apenas os avaliadores, que utilizam o material preparado e seguem o
procedimento prescrito pelo mtodo selecionado. Os avaliadores examinam a interface
para identificar discrepncias com um padro ou para tentar prever as experincias de
uso que os usurios tero com a soluo de IHC avaliada (veja Seo 10.1).
Em avaliaes por investigao e por observao, essa atividade costuma ter por
objetivo registrar as experincias vivenciadas pelos usurios durante a interao com o
sistema ou prottipo sendo avaliado. Os mtodos empricos contam com a participao
dos usurios para relatar experincias de uso vivenciadas ou permitir a observao de
experincias reais de uso com a soluo de IHC avaliada.
Ao receber os participantes, o avaliador deve ser cordial e deix-los bem vontade. Ele
costuma estabelecer uma conversa de aquecimento ou quebra-gelo com os
participantes, sobre tpicos gerais como: o clima, notcias recentes e como foi o trajeto
at o local da avaliao. Se a avaliao ocorrer em laboratrio, o avaliador deve apresentar
todo o ambiente de teste aos participantes, inclusive a sala de observao. Sempre que
possvel, o avaliador deve oferecer gua, caf, oportunidade para ir ao toalete ou algo
mais de que os participantes precisem. Tudo isso tem por objetivo dar oportunidade e
tempo para o participante se acostumar com o ambiente, reduzindo sua ansiedade antes
de iniciar a sesso de coleta de dados.
Depois dessa conversa inicial, o avaliador deve explicar ao participante os objetivos do
estudo, o sistema de interesse, o procedimento da avaliao (por exemplo, apresentar
uma viso geral das atividades que o participante convidado a realizar) e os cuidados
ticos sendo tomados (veja Seo 5.4). Se surgir alguma dvida, ela deve ser sanada
imediatamente pelo avaliador. Depois, o avaliador entrega o termo de consentimento em
duas vias, j assinadas por ele prprio, e aguarda enquanto o participante l e assina o
termo, caso aceite participar da avaliao. Uma via do termo de consentimento fica com o
avaliador e a outra com o participante.
Em seguida, o participante responde o questionrio pr-teste. O avaliador pode tornar
esse momento mais natural se ele ler as perguntas do questionrio para o participante e
registrar as respostas fornecidas, como numa entrevista estruturada. Isso pode ajudar o
participante a se sentir mais vontade durante a avaliao.
Respondido o questionrio, iniciada a sesso de observao. Nesse momento, o
software e os equipamentos que registram os dados da interao devem ser ativados. O
avaliador apresenta o sistema a ser avaliado e pode permitir que o participante explore-o
livremente por alguns minutos, caso seja o seu primeiro contato com o sistema. Depois
da explorao livre, o avaliador entrega ao participante as instrues e os cenrios das
tarefas a serem realizadas. Esclarecidas as eventuais dvidas, o participante passa a
realizar as tarefas solicitadas.
recomendvel que pelo menos dois avaliadores trabalhem na coleta de dados: um
para acompanhar o participante mais de perto na sala de uso do sistema e outro mais
distante da sala de observao. Enquanto o participante utiliza o sistema, os avaliadores
devem anotar qualquer acontecimento que possa ser relevante para a interpretao dos
dados coletados e sobre eventuais dvidas a serem esclarecidas na entrevista ps-teste.
Eles devem evitar interferir na atividade do usurio. O participante no deve ser
interrompido nem questionado enquanto realiza as tarefas solicitadas.
Se for adequado, o avaliador pode pedir que o participante relate em voz alta o que ele
est pensando e fazendo durante a interao. Essa tcnica conhecida como think aloud
(Ericsson e Simon, 1993). Apesar de ser uma tcnica til e relativamente simples para o
avaliador ter acesso ao que se passa na mente do participante, ela depende muito do
participante. Certas pessoas podem se distrair e parar de falar enquanto realizam alguma
atividade. Outras podem gastar mais tempo e esforo relatando o que esto pensando e
fazendo, do que realmente executando as tarefas solicitadas. Se no for aplicada de forma
adequada, essa tcnica pode interferir nos resultados da avaliao, como, por exemplo, no
nmero de erros cometidos, pois o usurio pode pensar mais antes de fazer, ou no tempo
de execuo das tarefas, pois o participante pode gastar mais tempo pensando e falando.
Portanto, a tcnica de think aloud deve ser utilizada cuidadosamente.
Caso o participante j tenha gasto muito tempo interagindo sem conseguir concluir
uma tarefa, demonstre no ter condies de concluir a tarefa, ou passe por uma situao
de constrangimento ou emoes desagradveis, os avaliadores podem intervir na
interao, sugerindo ao participante que passe para a prxima tarefa solicitada, ou at
mesmo abandone as tarefas restantes. Na transio entre tarefas, se for o caso, o
avaliador pode interagir com o sistema a fim de prepar-lo para a execuo da prxima
tarefa. Alm disso, o participante pode pedir para fazer uma pausa, sempre que quiser.
Terminada a sesso de interao, os avaliadores devem conduzir a entrevista ps-teste.
Essa entrevista uma oportunidade para coletar a opinio do participante sobre a
experincia de uso que acabou de vivenciar e esclarecer eventuais dvidas sobre seu
comportamento e suas intenes, percepes e interpretaes durante a execuo das
tarefas.

9.7.4 Interpretao
Na atividade de interpretao, o avaliador analisa o material registrado para atribuir
significado aos dados coletados. A interpretao do avaliador deve ser orientada pelo
mtodo de avaliao selecionado e pelo que foi definido durante a atividade de
preparao da avaliao. Cada mtodo de avaliao costuma apontar os focos de anlise
(i.e., quais dados devem ser analisados sob quais perspectivas de anlise) e os tipos de
interpretaes mais frequentes. Por exemplo, o mtodo de avaliao heurstica enfatiza a
anlise de um conjunto de heursticas, enquanto o mtodo de avaliao de
comunicabilidade investiga problemas na recepo da metamensagem associados a
etiquetas de rupturas de comunicao. Em geral, o avaliador se concentra inicialmente na
interpretao dos dados coletados de cada participante individualmente, buscando
respostas s questes especficas definidas no planejamento da avaliao. Esse tipo de
anlise tambm conhecido como anlise intrassujeito ou intraparticipante (Nicolaci-da-
Costa, 1994; Nicolaci-da-Costa et al., 2004).
A interpretao ou anlise dos dados coletados pode ser feita de forma automtica ou
manual, dependendo do tipo de cada dado. Alguns aspectos de uma soluo de IHC
podem ser avaliados automaticamente por um programa computacional, de forma mais
rpida e sistemtica do que um ser humano poderia realizar manualmente. A anlise
automtica dos dados tem sido utilizada para avaliar a navegao por sites na Web,
verificando, por exemplo, a existncia de links quebrados e alguns critrios de
acessibilidade (e.g., imagens que no possuem descrio textual associada). O DaSilva1
um dos primeiros programas brasileiros que avaliam a acessibilidade de Web sites. Ele
analisa o cdigo HTML do endereo indicado para detectar partes da interface que violem
regras de acessibilidade.
Tambm possvel verificar automaticamente se o uso do sistema avaliado ocorre
conforme o esperado. Para isso, na etapa de preparao o avaliador representa em algum
modelo os caminhos de interao oferecidos pelo designer para o usurio alcanar seus
objetivos (por exemplo, atravs de um modelo de tarefas ou de interao). Na etapa de
coleta de dados, um programa monitora e registra a interao do usurio com o sistema
enquanto ele tenta atingir os objetivos desejados. Desse modo, o avaliador pode
comparar automaticamente o que ele esperava que ocorresse e o que de fato ocorre
durante a interao. Dentre outros resultados, essa comparao permite calcular quantas
vezes os usurios conseguiram ou no alcanar seus objetivos da forma prevista pelo
designer, bem como identificar em que partes da interao ocorreram problemas que
dificultaram ou impediram os usurios de alcanarem seus objetivos (Lecerof e Patern,
1998). Essa uma forma de avaliao baseada em modelos e registros de interao.
Os critrios de qualidade de uso que podem ser analisados automaticamente por
programas computacionais ainda so muito limitados, pois exigem uma definio a priori
de regras definindo o que bom e ruim, e o que certo e errado. A anlise
realizada por um avaliador humano ainda fundamental para verificar a qualidade de
uso, porque difcil codificar num programa toda a viso que o avaliador pode adquirir
sobre domnio, usurio, atividades e contexto, bem como sua capacidade de anlise,
principalmente diante de situaes imprevistas. No entanto, para aspectos pontuais da
avaliao, as anlises automticas podem agilizar parte do processo.

9.7.5 Consolidao E Relato Dos Resultados


Uma vez concluda a interpretao individual dos dados coletados, seja das previses dos
avaliadores ou das observaes das experincias de uso dos participantes, os resultados
individuais so consolidados e analisados em conjunto, em uma anlise denominada de
intersujeito ou interparticipante (Nicolaci-da-Costa, 1994; Nicolaci-da-Costa et al., 2004).
Nessa atividade, os avaliadores buscam recorrncias nos resultados de acordo com o
mtodo selecionado. As recorrncias so importantes porque, ao expressarem resultados
comuns a vrios participantes de um grupo, permitem fazer uma distino entre
caractersticas representativas do grupo e as idiossincrasias de participantes individuais.
Na consolidao dos resultados, os avaliadores devem novamente enderear as
questes que motivaram o estudo, buscando respond-las ou justificar por que alguma
resposta no foi encontrada. Mesmo no caso de avaliaes empricas, a generalizao dos
resultados exige muito cuidado. Eles sempre so fortemente influenciados pelo ambiente
de avaliao e pelas caractersticas, preferncias, interesses e necessidades dos
participantes individuais.
Os mtodos de avaliao podem apresentar diferentes resultados. Por exemplo,
quando o objetivo identificar problemas em solues de IHC, diferentes mtodos
podem revelar tipos diversos de problemas que prejudiquem a qualidade de uso, seja por
causa de diferenas na coleta de dados ou na sua anlise. Outros fatores tambm
influenciam os resultados da avaliao: o conhecimento e a experincia dos avaliadores, o
tempo disponvel para a avaliao, a quantidade e qualidade dos dados disponveis, e
assim por diante.
Os resultados de uma avaliao de IHC normalmente indicam tendncias de
problemas, e no uma certeza de que eles vo ocorrer durante o uso do sistema. De modo
semelhante, caso no sejam encontrados problemas durante a avaliao, tambm no
podemos afirmar categoricamente que o sistema tenha alta qualidade de uso, apenas que
um estudo no revelou problemas num determinado escopo do sistema que foi avaliado
com base em um certo planejamento.
Finalmente, os avaliadores devem relatar os resultados consolidados, que costumam
incluir:
os objetivos e escopo da avaliao;
a forma como a avaliao foi realizada (mtodo de avaliao empregado);
o nmero e o perfil de usurios e avaliadores que participaram da avaliao;
um sumrio dos dados coletados, incluindo tabelas e grficos;
um relato da interpretao e anlise dos dados;
uma lista dos problemas encontrados;
um planejamento para o reprojeto do sistema.
9.8 O Framework DECIDE
Sharp, Rogers e Preece (2007) propem um framework chamado DECIDE para orientar o
planejamento, a execuo e a anlise de uma avaliao de IHC. As atividades do
framework so interligadas e executadas iterativamente, medida que o avaliador articula
os objetivos da avaliao, os dados e recursos disponveis. Ento, quando o avaliador
descobre uma necessidade de modificar os rumos da avaliao por algum motivo, as
demais atividades so afetadas. Por exemplo, se o avaliador no conseguir permisso
para visitar o ambiente de uso de um sistema, ele no pode aplicar um mtodo de
avaliao que coleta dados sobre o uso do sistema em contexto. Nesse caso,
provavelmente seus objetivos precisaro ser revistos. As atividades do framework
DECIDE so descritas a seguir.
D Determinar os objetivos da avaliao de IHC. O avaliador deve determinar os objetivos gerais da avaliao e identificar por que e para quem tais objetivos so
importantes. O restante do planejamento da avaliao, sua execuo e a apresentao dos resultados sero orientados por esses objetivos.
E Explorar perguntas a serem respondidas com a avaliao. Para cada objetivo definido, o avaliador deve elaborar perguntas especficas a serem respondidas
durante avaliao. Essas perguntas so responsveis por operacionalizar a investigao e o julgamento de valor a serem realizados. Elas devem
considerar o perfil dos usurios-alvo e suas atividades.
C Escolher (Choose) os mtodos de avaliao a serem utilizados. O avaliador deve escolher os mtodos mais adequados para responder as perguntas e atingir
os objetivos esperados, considerando tambm o prazo, o oramento, os equipamentos disponveis e o grau de conhecimento e experincia dos
avaliadores.
I Identificar e administrar as questes prticas da avaliao. Existem muitas questes prticas envolvidas numa avaliao de IHC, como, por exemplo, o
recrutamento dos usurios que participaro da avaliao, a preparao e o uso dos equipamentos necessrios, os prazos e o oramento disponveis, alm
da mo-de-obra necessria para conduzir a avaliao.
D Decidir como lidar com as questes ticas. Sempre que usurios so envolvidos numa avaliao, o avaliador deve tomar os cuidados ticos necessrios (veja
Seo 5.4). Os participantes da avaliao devem ser respeitados e no podem ser prejudicados direta ou indiretamente, nem durante os experimentos, nem
aps a divulgao dos resultados da avaliao.
E Avaliar (Evaluate), interpretar e apresentar os dados. O avaliador precisa estar atento a alguns aspectos da avaliao realizada antes de tirar concluses e
divulgar resultados. Ele deve considerar: o grau de confiabilidade dos dados (i.e., semelhana dos resultados obtidos quando emprega mais de uma vez o
mesmo mtodo de avaliao nas mesmas circunstncias; a validade interna do estudo (i.e., se o mtodo de avaliao mede o que deveria medir, se o faz
com rigor e evita que os dados sejam distorcidos); a validade externa do estudo (i.e., at que ponto os resultados podem ser generalizados ou transferidos
a um outro contexto semelhante); e a validade ecolgica do estudo (i.e., o quanto os materiais, mtodos e ambiente de estudo se assemelham situao
real investigada).
Atividades
1. Por que avaliar o uso de software? Imagine que voc seja apresentado a um produtor de
software que lhe conta sobre seus planos para produzir uma nova verso de um
sistema comercial. Quais argumentos voc elaboraria para convenc-lo a realizar uma
avaliao de IHC?
2. Planejamento da avaliao de IHC. Escolha um software de sua preferncia e defina dois
objetivos de avaliao (por exemplo, dois objetivos citados na Tabela 9.1). Planeje
duas avaliaes de IHC do software escolhido, uma para cada objetivo definido. Em
cada planejamento, realize cada tarefa de preparao da avaliao e relate sua
execuo. Compare os dois planejamentos.
1
http://www.dasilva.org.br/.
10

Mtodos de Avaliao de IHC


Objetivos do Captulo
Apresentar os mtodos de avaliao de IHC por inspeo: avaliao heurstica,
percurso cognitivo e inspeo semitica.
Apresentar os mtodos de avaliao de IHC por observao: teste de usabilidade,
avaliao de comunicabilidade e prototipao em papel.
Comparar os mtodos de avaliao de acordo com o que avaliado, quando a avaliao
realizada, e qual tipo de resultado produzido.
Este captulo descreve os seguintes mtodos de avaliao de IHC: avaliao heurstica
(Nielsen, 1994a), percurso cognitivo (Wharton et al., 2004), inspeo semitica (de Souza
et al., 2006; Prates e Barbosa, 2007), teste de usabilidade (Rubin, 1994), avaliao de
comunicabilidade (Prates et al., 2000a; de Souza, 2005a; Prates e Barbosa, 2007) e
prototipao em papel (Snyder, 2003). Esses mtodos so comparados na Seo 10.3, de
acordo com o que avaliado, quando a avaliao realizada, e qual tipo de resultado
produzido.
10.1 Avaliao de IHC Atravs de Inspeo
Como apresentado na Seo 9.6, os mtodos de inspeo permitem ao avaliador examinar
(ou inspecionar) uma soluo de IHC para tentar antever as possveis consequncias de
certas decises de design. Esses mtodos no envolvem diretamente os usurios,
portanto, tratam de experincias de uso potenciais, e no reais. Ao inspecionar uma
interface, os avaliadores tentam se colocar no lugar de um usurio com determinado
perfil, com um certo conhecimento e experincia em algumas atividades, para ento
tentar identificar problemas que os usurios podem vir a ter quando interagirem com o
sistema, e quais formas de apoio o sistema oferece para ajud-los a contornarem esses
problemas. Nas prximas subsees apresentamos trs mtodos de avaliao por
inspeo: a avaliao heurstica, o percurso cognitivo e a inspeo semitica.

10.1.1 Avaliao Heurstica


A avaliao heurstica um mtodo de avaliao de IHC criado para encontrar problemas
de usabilidade durante um processo de design iterativo (Nielsen e Molich, 1990; Nielsen,
1993; Nielsen, 1994a). Esse mtodo de avaliao orienta os avaliadores a inspecionar
sistematicamente a interface em busca de problemas que prejudiquem a usabilidade. Por
ser um mtodo de inspeo, a avaliao heurstica foi proposta como uma alternativa de
avaliao rpida e de baixo custo, quando comparada a mtodos empricos.
A avaliao heurstica tem como base um conjunto de diretrizes de usabilidade, que
descrevem caractersticas desejveis da interao e da interface, chamadas por Nielsen
de heursticas. Essas heursticas resultam da anlise de mais de 240 problemas de
usabilidade realizada ao longo de vrios anos por experientes especialistas em IHC
(Nielsen, 1994b). Nielsen (1993) descreve um conjunto inicial de heursticas a serem
utilizadas em seu mtodo de avaliao heurstica (p. 30):
visibilidade do estado do sistema: o sistema deve sempre manter os usurios informados
sobre o que est acontecendo atravs de feedback (resposta s aes do usurio)
adequado e no tempo certo;
correspondncia entre o sistema e o mundo real: o sistema deve utilizar palavras,
expresses e conceitos que so familiares aos usurios, em vez de utilizar termos
orientados ao sistema ou jargo dos desenvolvedores. O designer deve seguir as
convenes do mundo real, fazendo com que a informao aparea em uma ordem
natural e lgica, conforme esperado pelos usurios;
controle e liberdade do usurio: os usurios frequentemente realizam aes equivocadas
no sistema e precisam de uma sada de emergncia claramente marcada para sair
do estado indesejado sem ter de percorrer um dilogo extenso. A interface deve
permitir que o usurio desfaa e refaa suas aes;
consistncia e padronizao: os usurios no devem ter de se perguntar se palavras,
situaes ou aes diferentes significam a mesma coisa. O designer deve seguir as
convenes da plataforma ou do ambiente computacional;
reconhecimento em vez de memorizao: o designer deve tornar os objetos, as aes e
opes visveis. O usurio no deve ter de se lembrar para que serve um elemento de
interface cujo smbolo no reconhecido diretamente; nem deve ter de se lembrar de
informao de uma parte da aplicao quando tiver passado para uma outra parte
dela. As instrues de uso do sistema devem estar visveis ou facilmente acessveis
sempre que necessrio;
flexibilidade e eficincia de uso: aceleradores imperceptveis aos usurios novatos
podem tornar a interao do usurio mais rpida e eficiente, permitindo que o
sistema consiga servir igualmente bem os usurios experientes e inexperientes.
Exemplos de aceleradores so botes de comando em barras de ferramentas ou teclas
de atalho para acionar itens de menu ou botes de comando. Alm disso, o designer
pode oferecer mecanismos para os usurios customizarem aes frequentes;
projeto esttico e minimalista: a interface no deve conter informao que seja irrelevante
ou raramente necessria. Cada unidade extra de informao em uma interface reduz
sua visibilidade relativa, pois compete com as demais unidades de informao pela
ateno do usurio;
preveno de erros: melhor do que uma boa mensagem de erro um projeto cuidadoso
que evite que um problema ocorra, caso isso seja possvel;
ajude os usurios a reconhecerem, diagnosticarem e se recuperarem de erros: as mensagens de
erro devem ser expressas em linguagem simples (sem cdigos indecifrveis), indicar
precisamente o problema e sugerir uma soluo de forma construtiva;
ajuda e documentao: embora seja melhor que um sistema possa ser utilizado sem
documentao, necessrio oferecer ajuda e documentao de alta qualidade. Tais
informaes devem ser facilmente encontradas, focadas na tarefa do usurio,
enumerar passos concretos a serem realizados e no ser muito extensas.
Esse um conjunto inicial, que pode ser expandido para incluir novas diretrizes
conforme os avaliadores julgarem necessrio. Por exemplo, h diretrizes especficas para
certos estilos de interao (e.g., Web, WIMP, manipulao direta, interfaces via voz,
realidade virtual) e para certos domnios de aplicao (e.g., comrcio eletrnico, sistemas
colaborativos, educao a distncia).
Nielsen (1992) realizou um experimento com 19 avaliadores realizando
individualmente uma avaliao heurstica num sistema de atendimento eletrnico.
Naquele estudo, alguns problemas foram descobertos por todos os avaliadores, outros
foram encontrados por um nmero pequeno de avaliadores, e um nmero substancial de
problemas foi encontrado por apenas um avaliador. Com base no estudo, Nielsen
recomenda que uma avaliao heurstica envolva de trs a cinco avaliadores. Algumas
atividades devem ser realizadas por cada avaliador (individualmente), enquanto em
outras eles devem trabalhar em conjunto. A Tabela 10.1 apresenta as atividades
envolvidas em uma avaliao heurstica.
Tabela 10.1
Atividades do mtodo de avaliao heurstica

Na atividade de preparao, os avaliadores organizam as telas do sistema ou prottipo a


ser avaliado, conforme o escopo definido para a avaliao (veja Seo 9.7.2), e a lista de
heursticas ou diretrizes que devem ser consideradas. A soluo de IHC avaliada pode ser
o prprio sistema funcionando, bem como prottipos executveis e no executveis em
vrios nveis de fidelidade e detalhes, inclusive prottipos desenhados em papel. Por
isso, a avaliao heurstica pode ser executada durante todo o processo de design de IHC,
desde que haja alguma representao da interface proposta.
Em seguida, os avaliadores prosseguem com a coleta e a interpretao dos dados (veja
Sees 9.7.3 e 9.7.4). Cada avaliador deve inspecionar individualmente cada tela
selecionada e cada um de seus elementos, com o objetivo de identificar se as diretrizes
foram respeitadas ou violadas. Cada violao de diretriz considerada um problema
potencial de IHC. O avaliador deve percorrer a interface pelo menos duas vezes: uma
para ganhar uma viso de conjunto e outra para examinar cuidadosamente cada
elemento de cada tela. Ele pode adotar uma estratgia de avaliao por diretriz ou por
tela. No primeiro caso, o avaliador seleciona uma diretriz e percorre toda a interface
avaliando-a, e, em seguida, repete o procedimento com a prxima diretriz, at esgotar o
conjunto de diretrizes. No segundo caso, o avaliador seleciona uma tela, avalia-a
considerando todas as diretrizes e, em seguida, repete o procedimento com a prxima
tela, at percorrer toda a interface. Tambm possvel combinar essas duas estratgias
de inspeo.
Para cada problema identificado, o avaliador deve anotar: qual diretriz foi violada, em
que local o problema foi encontrado (em que tela e envolvendo quais elementos de
interface), qual a gravidade do problema e uma justificativa de por que aquilo um
problema. Tambm interessante anotar ideias de solues alternativas que possam
resolver os problemas encontrados.
O local em que cada problema foi encontrado indica quais partes da interface devem
ser modificadas. O problema pode ser pontual, em um nico local na interface; ocasional,
em dois ou mais locais na interface, casualmente; ou sistemtico, na estrutura geral da
interface. Alm disso, o problema pode ser causado pela ausncia de algum elemento na
interface, que deveria ser includo.
Cada avaliador deve julgar a severidade (ou gravidade) dos problemas encontrados,
para facilitar a anlise de custo/benefcio da correo dos problemas e priorizao dos
esforos de correo ou reprojeto. Segundo Nielsen (1994a), o julgamento da severidade
de um problema de usabilidade envolve trs fatores:
a frequncia com que o problema ocorre: um problema comum ou raro?
o impacto do problema, se ocorrer: ser fcil ou difcil para os usurios superarem o
problema?
a persistncia do problema: o problema ocorre apenas uma vez e ser superado pelos
usurios, ou atrapalhar os usurios repetidas vezes?
Para facilitar a compreenso e comparao do julgamento dos problemas encontrados,
Nielsen (1994a) sugere a seguinte escala de severidade:
1: problema cosmtico no precisa ser consertado a menos que haja tempo no
cronograma do projeto;
2: problema pequeno o conserto deste problema pode receber baixa prioridade;
3: problema grande importante de ser consertado e deve receber alta prioridade. Esse
tipo de problema prejudica fatores de usabilidade tidos como importantes para o
projeto (por exemplo, so exigidos muitos passos de interao para alcanar um
objetivo que deveria ser atingido de forma eficiente);
4: problema catastrfico extremamente importante consert-lo antes de se lanar o
produto. Se mantido, o problema provavelmente impedir que o usurio realize suas
tarefas e alcance seus objetivos.
Uma sesso de inspeo da interface na avaliao heurstica costuma durar em torno
de uma ou duas horas. Caso a interface seja muito complexa, podemos realizar mais de
uma sesso de inspeo para diferentes partes da interface, mas no devemos realizar
sesses longas, pois o desempenho do avaliador diminui muito com o passar do tempo, e
ele deixa de produzir dados de qualidade.
Depois que todas as inspees individuais tenham sido realizadas, os avaliadores
devem se reunir para consolidar os resultados (veja Seo 9.7.5). Nessa atividade, cada
avaliador compartilha sua lista de problemas com os demais avaliadores, para que todos
adquiram uma viso abrangente dos problemas encontrados na interface avaliada. Em
seguida, eles realizam um novo julgamento, no qual cada avaliador pode atribuir um
novo grau de severidade para cada problema. Caso um avaliador discorde que algum
item seja de fato um problema, pode atribuir a ele um grau de severidade zero.
Considerando os novos julgamentos, os avaliadores conversam e entram em acordo
sobre o grau de severidade final de cada problema e decidem quais problemas e
sugestes de soluo devem fazer parte do relatrio consolidado.
Depois que a equipe de avaliadores adquire uma viso mais abrangente, algumas vezes
necessrio unir problemas encontrados por diferentes avaliadores ou at pelo mesmo
avaliador, seja porque relatam exatamente o mesmo problema ou porque relatam casos
particulares ou partes de um problema maior.
O relato dos resultados de uma avaliao heurstica geralmente contm (veja Seo
9.7.5):
os objetivos da avaliao;
o escopo da avaliao;
uma breve descrio do mtodo de avaliao heurstica;
o conjunto de diretrizes utilizado;
o nmero e o perfil dos avaliadores;
lista de problemas encontrados, indicando, para cada um:
local onde ocorre;
descrio do problema;
diretriz(es) violada(s);
severidade do problema;
sugestes de soluo.

Exemplo 10.1
A valiao H eurstica
Considere o seguinte fragmento de tela de login de um Web site de
livraria:1.

O trecho de relatrio a seguir ilustra a descrio das violaes resultante


da avaliao heurstica. Observe que alguns problemas constituem violao
de mais de uma heurstica.
Visibilidade do estado do sistema, preveno de erros. O elemento
secundrio Cadastre-se tem mais destaque do que o elemento
Confirmar. Isso pode levar o usurio a acionar o boto errado ou se
perguntar se entrou corretamente na tela de login, e at mesmo voltar
para a pgina anterior e repetir a operao de acesso a essa pgina.
Local: abaixo do formulrio, apenas nessa tela.
Severidade: 3 (problema grande), pois o usurio pode acreditar que
precisa se cadastrar a cada compra, ou que o sistema est com defeito, e
com isso pode desistir de efetuar a compra atravs desse site.
Recomendao: destacar o boto primrio (Confirmar) e reduzir a nfase
dos botes secundrios (Cadastre-se e Esqueci senha). Considere
modificar os botes secundrios para links, mais afastados do boto
primrio do formulrio.
Controle e liberdade do usurio. Os usurios no tm a opo, atravs do
Web site, de voltar pgina anterior. Para isso, precisam utilizar o
boto de volta do prprio navegador.
Local: ausncia de um boto de volta em todos os formulrios do site.
Severidade: 2 (problema pequeno). O usurio est acostumado a utilizar
o boto de volta do navegador em outros sites, e perceber que pode
fazer isso sem perder o que tenha feito no site (e.g., itens colocados no
carrinho de compras).
Recomendao: incluir um boto Voltar como boto secundrio do
formulrio.
Consistncia e padronizao, preveno de erros. Os campos de
preenchimento alternativo (Email: e ou CPF/CNPJ:) no esto
claramente marcados, como de costume, por botes de opo (radio
buttons). Como os usurios costumam seguir dicas visuais melhor do
que instrues textuais, muitos preenchero os dois campos.
Local: formulrio de login, campos Email: e ou CPF/CNPJ:.
Severidade: 2 (problema pequeno). Apesar de ineficiente, o
preenchimento dos dois campos no impede o usurio de efetuar o
login.
Recomendao: identificar os campos alternativos por botes de opo,
que devem ser automaticamente selecionados quando o usurio inicia a
digitao no campo correspondente.
Flexibilidade e eficincia de uso, consistncia e padronizao. O usurio no
tem a opo de pedir para o sistema se lembrar do seu e-mail ou
mesmo manter seu login ativo, como ocorre em boa parte dos sites de
comrcio eletrnico.
Local: formulrio de login, ausncia de botes de seleo (checkboxes).
Severidade: 2 (problema pequeno) para usurios ocasionais; 3
(problema grande) para usurios frequentes, que provavelmente daro
preferncia a Web sites que se lembrem deles.
Recomendao: oferecer um checkbox Lembrar dos meus dados e/ou um
checkbox Manter meu login ativo por 15 dias.
1 http://www.livrariagalileu.com.br/

10.1.2 Percurso Cognitivo


O percurso cognitivo (cognitive walkthrough) um mtodo de avaliao de IHC por
inspeo cujo principal objetivo avaliar a facilidade de aprendizado de um sistema
interativo, atravs da explorao da sua interface (Wharton et al., 1994). Esse mtodo foi
motivado pela preferncia de muitas pessoas em aprenderem fazendo, em vez de
aprenderem atravs de treinamentos, leitura de manuais etc. Para julgar a facilidade de
aprendizado do sistema, o mtodo considera principalmente a correspondncia entre o
modelo conceitual dos usurios e a imagem do sistema, no que tange conceitualizao
da tarefa, ao vocabulrio utilizado e resposta do sistema a cada ao realizada.
O percurso cognitivo guia a inspeo da interface pelas tarefas do usurio. Nesse
mtodo, o avaliador percorre a interface inspecionando as aes projetadas para um
usurio concluir cada tarefa utilizando o sistema. Para cada ao, o avaliador tenta se
colocar no papel de um usurio e detalha como seria sua interao com o sistema
naquele momento. Em um bom projeto de IHC, esperamos que a prpria interface guie
os usurios pela sequncia de aes esperada (projetada pelo designer) para realizar suas
tarefas. Caso isso no acontea, o mtodo levanta hipteses sobre as possveis causas dos
problemas encontrados e busca fornecer sugestes de reprojeto. Cabe ao avaliador
formular hipteses sobre o sucesso ou insucesso da interao a cada passo. Para isso, ele
avalia o processo de interao segundo a viso da engenharia cognitiva, conforme
descrito na Seo 3.4. Ele verifica se a imagem do sistema apoia as tarefas de forma
compatvel com o modelo conceitual que os usurios de determinado perfil possuem e o
modo como realizam tais tarefas.
A Tabela 10.2 apresenta as atividades propostas pelo mtodo de percurso cognitivo. O
percurso cognitivo pode ser realizado por um ou mais avaliadores. Se houver mais de um
avaliador, todos devem realizar todas as atividades em conjunto.
Tabela 10.2
Atividades do mtodo de percurso cognitivo

Na atividade de preparao, o avaliador organiza os objetos do estudo e prepara o


material de apoio (veja Seo 9.7.2). Os objetos do estudo so: a lista de tarefas
investigadas e a sequncia das aes que, na viso do designer da soluo, um usurio
com o perfil especificado deveria executar para concluir a tarefa. O material de apoio
inclui a lista de perguntas do mtodo e a descrio do perfil de usurios, incluindo o seu
conhecimento e experincia no domnio investigado, nas tarefas e no uso de tecnologias e
sistemas semelhantes.
As tarefas a serem avaliadas podem estar representadas por um modelo de tarefas
(conforme apresentado na Seo 6.4), um prottipo em papel, um prottipo funcional ou
um sistema pronto. Quanto mais prxima e fiel for a representao da interface da
soluo final, melhores sero as condies de o avaliador prever a facilidade que o
usurio ter para aprender a realizar as tarefas em questo.
Nas atividades de coleta e interpretao dos dados (veja Sees 9.7.3 e 9.7.4), o avaliador
simula, na (representao da) interface, a execuo das tarefas que fazem parte do escopo
de avaliao. Para cada tarefa, o avaliador examina cada passo, analisando se e por que
um usurio com o perfil especificado escolheria a ao correta ou perceberia que o
efeito correto foi alcanado. Para a avaliao de cada passo, o avaliador responde as
seguintes perguntas:
o usurio tentaria atingir o efeito correto? A formulao da inteno do usurio seria a
esperada (pelo designer do sistema)? Um usurio tem mais chance de formular a
inteno correta se: a ao faz parte da tarefa tal como concebida pelo usurio; o
usurio tem experincia em utilizar o sistema avaliado ou sistemas semelhantes; ou o
sistema fornece uma instruo ou solicita que o usurio realize a ao;
o usurio perceberia que a ao correta est disponvel? Um usurio normalmente sabe que
uma ao est disponvel se: tem experincia em utilizar o sistema avaliado ou
sistemas semelhantes; ou se percebe na interface uma representao da ao desejada
(por exemplo, em um item de menu, link ou boto de comando);
o usurio conseguiria associar a ao correta com o efeito que est tentando atingir? O usurio
costuma saber qual ao adequada para o efeito esperado se: tem experincia em
utilizar o sistema avaliado ou sistemas semelhantes; se a interface comunica essa
associao entre a ao e o efeito esperado; ou se nenhuma outra ao parece
adequada (i.e., por eliminao);
se a ao correta for realizada, o usurio perceberia que est progredindo para concluir a
tarefa? O usurio geralmente sabe que est avanando na direo da concluso da
tarefa se: tem experincia em utilizar o sistema avaliado ou sistemas semelhantes; ou
as respostas do sistema esto de acordo com o efeito esperado.
Considerando a tarefa, o perfil dos usurios e a interface, o avaliador deve relatar
histrias de sucesso ou de insucesso ao responder essas perguntas. Todas as perguntas
devem ser respondidas para cada ao. Mesmo que a resposta a uma pergunta seja
negativa, isto , indique que o usurio no conseguiria avanar, o avaliador deve, aps
registrar seu relato de insucesso, supor que a resposta poderia ser positiva e ento
prosseguir respondendo pergunta seguinte, at que todas as perguntas tenham sido
respondidas para aquela ao. Em seguida, o procedimento se repete para a prxima
ao, e assim sucessivamente, at concluir a inspeo de todas as aes que compem a
tarefa sendo avaliada.
As perguntas do mtodo auxiliam o avaliador a identificar as aes que apresentam
problemas, ou seja, que prejudicam ou impedem que o usurio aprenda a interagir com a
interface para concluir sua tarefa. Tambm ajudam-no a justificar os problemas
encontrados.
Na atividade de consolidao dos resultados, os avaliadores analisam as histrias de
sucesso e insucesso sobre a realizao das tarefas para sintetizar resultados sobre:
o conhecimento que os usurios devem possuir a priori para serem capazes de executar
as tarefas analisadas;
o conhecimento que os usurios deveriam aprender enquanto realizam as tarefas
analisadas;
as sugestes de correes na interface.
As quatro perguntas que guiam a anlise definem classes de problemas de IHC para os
quais os avaliadores podem sugerir tipos de correo. Os tipos de correo previstos so
os seguintes:
Se na pergunta O usurio tentaria alcanar o efeito desejado? for relatada uma histria
de insucesso, ou seja, se o usurio no tentar fazer a coisa certa, h pelo menos trs
solues possveis:
eliminar a ao, combinando-a com outras aes ou deixar o sistema execut-la
sozinho;
fornecer uma instruo ou indicao de que a ao precisa ser realizada;
modificar alguma parte da tarefa para que o usurio entenda a necessidade dessa
ao.
Se na pergunta O usurio saber que a ao correta est disponvel? for relatada uma
histria de insucesso, ou seja, se o usurio formula a inteno correta mas no sabe
que a ao est disponvel na interface, a soluo pode ser tornar a ao mais
evidente. Por exemplo, acrescentar um item de menu ou um boto na interface para
ativar a mesma ao associada a um conjunto de teclas.
Se na questo O usurio conseguir associar a ao correta com o efeito que est tentando
atingir? for relatada uma histria de insucesso, ou seja, se o usurio no for capaz de
mapear seu objetivo nas aes disponveis na interface, pode ser necessrio renomear
as aes e reescrever as instrues da interface. Com um vocabulrio mais familiar, o
usurio tem maiores chances de realizar o mapeamento dos seus objetivos nas aes
disponveis na interface.
Se a ao correta for realizada e a resposta para a pergunta O usurio perceber que est
progredindo em direo concluso da tarefa? for relatada por uma histria de
insucesso, ou seja, se o usurio no for capaz de perceber que est caminhando para
concluir a tarefa, as respostas (feedbacks) do sistema devem ser destacadas ou
expressas mais claramente. Idealmente, as respostas do sistema devem deixar claro o
que ocorreu e o que possvel fazer em seguida para concluir a tarefa do usurio.
Caso seja esperado que uma mesma tarefa precise ser realizada por usurios de
diferentes perfis, a avaliao por percurso cognitivo deve ser realizada diversas vezes,
uma para cada perfil de usurio.
O relato dos resultados do percurso cognitivo costuma conter (veja Seo 9.7.5):
os objetivos e escopo da avaliao;
uma breve descrio do mtodo de percurso cognitivo, incluindo as perguntas que
devem ser respondidas;
o nmero e o perfil de avaliadores;
a descrio das tarefas analisadas.
Para cada tarefa analisada, o relatrio deve conter:
um resumo do conhecimento que os usurios devem ter a priori para serem capazes de
executar a tarefa;
um resumo do conhecimento que os usurios deveriam aprender enquanto realizam a
tarefa;
lista de problemas encontrados, indicando:
a ao que o usurio deveria executar;
local na interface onde ocorreu o problema;
descrio e justificativa do problema;
sugestes de soluo.

Exemplo 10.2
P ercurso C ognitivo
Perfil de usurio: aluno de graduao em projeto final
Sistema: Microsoft Word
Tarefa: formatar o relatrio conforme modelo requerido pela
universidade, com capa, contracapa, e numerao a partir da terceira
pgina, ali iniciando com o nmero 1, conforme o exemplo a seguir:

Passos necessrios para realizar a tarefa:


1. mover o cursor para o incio do texto que dever ficar na terceira
pgina
2. inserir uma quebra de seo para Prxima pgina
3. exibir cabealho e rodap
4. ir para o rodap
5. desvincular a seo atual da seo anterior
6. inserir nmero de pgina
7. formatar nmero de pgina para iniciar com 1
8. alinhar pargrafo direita
9. fechar cabealho e rodap
Percurso cognitivo (parcial)
1. Mover o cursor para o incio da terceira pgina
O usurio tentaria atingir o efeito correto?
Sim, pois a partir daquele ponto que deseja numerar o documento.
Ou no, caso acredite que pode posicionar o cursor em qualquer
ponto daquela pgina.
O usurio perceberia que a ao correta est disponvel?
Sim, por aprendizado prvio bsico sobre como navegar por um
documento com o mouse ou o teclado.
O usurio conseguiria associar a ao correta com o efeito que est
tentando atingir?
Sim, pois sabe os efeitos de utilizar o mouse e o teclado para mover
o cursor de texto.
Se a ao correta for realizada, o usurio perceberia que est progredindo
para concluir a tarefa?
Sim, pois o cursor de texto indica sua nova posio.

2. Inserir uma quebra de seo para Prxima pgina

O usurio tentaria atingir o efeito correto?


No, pois no conhece o conceito de seo.
O usurio perceberia que a ao correta est disponvel?
Sim. Se ele souber que deve inserir uma quebra de seo, vai
procurar no menu Inserir, e ver o item Quebra
O usurio conseguiria associar a ao correta com o efeito que est
tentando atingir?
Sim, pois os rtulos do item de menu e das opes do dilogo
deixam claro o seu efeito.

Se a ao correta for realizada, o usurio perceberia que est progredindo


para concluir a tarefa?
Sim, ele percebe que houve a quebra de pgina, e a barra de status
indica que ele agora est na Seo 2.
3. Exibir cabealho e rodap

O usurio tentaria atingir o efeito correto?


No, pois acredita que no precisa editar o rodap para numerar as
pginas.
O usurio perceberia que a ao correta est disponvel?
Sim. Se ele souber que deve exibir o rodap, vai procurar no menu
Exibir, e ver o item Cabealho e rodap.
Ou no. Caso ele acredite que tem de editar o rodap, ele buscar
no menu Editar e nada encontrar.
O usurio conseguiria associar a ao correta com o efeito que est
tentando atingir?
Sim, pois o rtulo do item de menu deixa claro o seu efeito.

Se a ao correta for realizada, o usurio perceberia que est progredindo


para concluir a tarefa?
Sim, ele percebe que agora est editando o cabealho da Seo 2.
Aparece uma moldura com o rtulo Cabealho - Seo 2 e tambm
uma barra de ferramentas intitulada Cabealho e rodap.
(O restante da avaliao por percurso cognitivo fica como exerccio para
o leitor.)

10.1.3 Mtodo De Inspeo Semitica


Fundamentado na engenharia semitica, o mtodo de inspeo semitica avalia a
comunicabilidade de uma soluo de IHC por meio de inspeo (de Souza et al., 2006;
Prates e Barbosa, 2007; de Souza e Leito, 2009; Seo 3.8). O objetivo da inspeo
semitica avaliar a qualidade da emisso da metacomunicao do designer codificada na
interface. Portanto, no necessrio envolver usurios nessa avaliao.
Conforme discutido na Seo 3.8, a engenharia semitica classifica os signos
codificados na interface em trs tipos: estticos, dinmicos e metalingusticos (de Souza e
Leito, 2009; de Souza, 2005a; Seo 3.8.1). Essa classificao orienta o trabalho do
avaliador durante a inspeo semitica. Para cada tipo de signo, o avaliador inspeciona a
interface, incluindo a documentao disponvel para o usurio (por exemplo, a ajuda on-
line e manuais de uso), interpretando os signos daquele tipo codificados no sistema com
objetivo de reconstruir a metamensagem do designer. Dessa forma, o avaliador tem trs
verses da metamensagem reconstruda, uma para cada tipo de signo. Em seguida, o
avaliador contrasta e compara as trs metamensagens reconstrudas, e por fim faz um
julgamento de valor sobre a comunicabilidade do sistema interativo.
Assim como ocorre nos demais mtodos de avaliao por inspeo, os resultados
fornecidos pela inspeo semitica dependem fortemente da interpretao do avaliador
sobre os signos codificados na interface. A Tabela 10.3 apresenta as atividades do mtodo
de inspeo semitica.

Tabela 10.3
Atividades do mtodo de inspeo semitica

Na atividade de preparao, o avaliador deve identificar os perfis dos usurios a quem o


sistema se destina e os objetivos que o sistema apoia, para ento definir o escopo da
avaliao (veja Seo 9.7.2). Conhecendo os perfis dos usurios e definido o escopo da
avaliao, o avaliador deve elaborar cenrios de interao (Carroll, 2000; Rosson e Carroll,
2002; Seo 7.2) para guiar a inspeo da interface e sua interpretao dos signos nela
codificados. Os cenrios de interao so ferramentas importantes para definir um
contexto de uso e um conjunto de objetivos (ou intenes de comunicao) que os
usurios desejam alcanar utilizando o sistema. Essas informaes fornecem ao avaliador
melhores condies para identificar, interpretar e analisar os signos codificados na
interface.
No mtodo de inspeo semitica, o avaliador realiza em conjunto as atividades de
coleta de dados sobre experincias de uso e de interpretao. Nessas atividades, ele
inspeciona a interface para identificar, interpretar e analisar os signos metalingusticos,
estticos e dinmicos nela codificados. Dependendo do tipo de signo analisado no
momento, o avaliador concentra sua inspeo em diferentes partes da interface. Por
exemplo, a anlise dos signos metalingusticos requer a inspeo do sistema de ajuda on-
line, das mensagens de erro e das explicaes presentes na interface. J a anlise dos
signos estticos requer a inspeo dos elementos da interface em determinado instante
no tempo. O mtodo de inspeo semitica apresenta melhores resultados se a inspeo
for realizada sobre a verso final do sistema interativo, pois a representao mais
concreta dos signos na interface influencia fortemente sua interpretao (seja pelo
avaliador ou por usurios), e a anlise dos signos dinmicos mais fcil, acurada e
precisa durante o uso de uma verso executvel do sistema.
medida que o avaliador identifica e interpreta os trs tipos de signos codificados na
interface, ele deve prosseguir sua anlise reconstruindo iterativamente uma
metamensagem do designer para cada tipo de signo analisado. A parfrase da
metamensagem deve ser usada como um modelo (template) a ser preenchido. Ela
reproduzida a seguir, com destaque em partes que devem ser completadas durante a
inspeo semitica (de Souza, 2005a, p. 25):

Este o meu entendimento, como designer, de quem voc, usurio, , do que aprendi que
voc quer ou precisa fazer, de que maneiras prefere fazer, e por qu. Este, portanto, o
sistema que projetei para voc, e esta a forma como voc pode ou deve utiliz-lo para
alcanar uma gama de objetivos que se encaixam nesta viso.

Essa parfrase serve de base para a elaborao de um conjunto de perguntas que


guiam a reconstruo da metamensagem durante a anlise dos trs tipos de signos. Tais
perguntas auxiliam o avaliador a interpretar as expectativas do designer para as situaes
de uso do sistema, e interpretar a soluo de IHC correspondente proposta por ele.
Assim, a reflexo do avaliador pode ser guiada pelas seguintes perguntas (adaptado de
Souza, 2005a; de Souza e Leito, 2009, p. 26):
[quem voc, usurio, ] A quem a mensagem do designer est endereada (i.e., para o
designer, quem so os usurios do sistema)? Quais os perfis desses destinatrios (i.e.,
quais so suas caractersticas, valores e crenas)?
[quer ou precisa fazer] Na viso do designer, o que os usurios vo querer comunicar ao
sistema (i.e., quais so os desejos e necessidades dos usurios, o que eles querem ou
precisam fazer com apoio do sistema)? Por qu?
[de que maneiras prefere fazer] Como, onde e quando o designer espera que os usurios
se engajem nessa comunicao (i.e., utilizem o sistema para realizar o que querem ou
precisam fazer)? Por qu?
[Este, portanto, o sistema que projetei para voc] O que o designer est comunicando?
Que contedo e expresso est utilizando nessa comunicao? Qual a sua viso de
design?
[a forma como voc pode ou deve utiliz-lo] Como essa metacomunicao privilegia certos
desejos e necessidades dos usurios, em detrimento a outros? Como essa
metacomunicao indica diferentes estratgias de comunicao que o usurio pode
seguir ao se comunicar com o preposto do designer? Como a comunicao do usurio
com o preposto do designer facilitada em certos contextos, em detrimento a outros?
Por qu?
[alcanar uma gama de objetivos] Que efeito(s) o designer espera que sua comunicao
cause? Que objetivos ele espera que o usurio alcance por meio dessa comunicao?
Essas perguntas so respondidas durante a anlise de cada tipo de signo, com o
objetivo de reconstruir o trecho correspondente da metamensagem do designer. Vale
lembrar que a anlise dos signos se limita aos cenrios de interao elaborados com base
no escopo da avaliao. Portanto, a metamensagem reconstruda parcial, ou seja, no
corresponde a toda a metamensagem do designer sobre o sistema avaliado. De qualquer
forma, sejam quais forem os trechos de metamensagem reconstrudos, mesmo que
incompletos, eles devem ser analisados em conjunto visando julgar se so consistentes e
coerentes entre si.
O Exemplo 10.3 apresenta um cenrio de interao definido para avaliar o
cadastramento de material didtico em um sistema de apoio acadmico.

Exemplo 10.3
C enrio de interao (parcial) utilizado em
uma inspeo semitica
Visando avaliar o sistema Moodle,2 . de apoio ao ensino a distncia ou
presencial, foi definido o seguinte cenrio:
Lucas, professor de Introduo ao Clculo, utiliza o Moodle para
divulgar o seu material didtico para os alunos. Esse material inclui
slides, listas de exerccios e provas aplicadas em perodos anteriores, e
fica armazenado em arquivos de diversos tipos: slides, animaes,
documentos textuais e planilhas. Est comeando um novo perodo, e
ele precisa cadastrar todo esse material no Moodle.
Passado um ms de aula, Lucas decide substituir parte do material
cadastrado, a fim de fazer pequenas correes, e incluir mais alguns
exemplos.

2 http://moodle.org

Mesmo dentro do escopo definido pelos cenrios de interao, comum existirem


lacunas nas reconstrues da metamensagem. Nesse caso, o avaliador deve prever suas
consequncias. Por exemplo, se no houver signos metalingusticos que expliquem
determinado signo esttico, pode ser o caso de o usurio no conseguir interpret-lo e
assim deixar de fazer uso (adequado) dele.
A partir dos cenrios de interao elaborados com base no objetivo e escopo da
avaliao, o avaliador inspeciona os signos metalingusticos: a ajuda on-line, os manuais do
usurio e demais formas de documentao do sistema e os materiais de divulgao. Os
signos metalingusticos so os primeiros a serem analisados na inspeo semitica, pois
expressam e explicam explicitamente outras partes da metamensagem do designer. Eles
comunicam aos usurios os significados dos signos estticos, dinmicos e outros signos
metalingusticos, e como todos esses signos podem ser utilizados durante a interao.
Normalmente eles so encontrados por toda a interface em instrues, explicaes,
avisos e mensagens de erros, mas se concentram na ajuda on-line, manuais do usurio e
em materiais de divulgao do sistema. O resultado da inspeo e anlise dos signos
metalingusticos a reconstruo de trechos da metamensagem do designer de acordo
com o que foi aprendido nesse passo.
O Exemplo 10.4 ilustra um trecho da metamensagem reconstruda com base em signos
metalingusticos de um sistema de apoio acadmico, conforme o cenrio de interao
definido anteriormente.

Exemplo 10.4
A nlise (parcial) dos signos metalingusticos
O sistema de ajuda on-line do Moodle apresenta o seguinte trecho de ajuda
sobre o gerenciamento dos arquivos associados a um curso:
Arquivos
A rea de arquivos pode incluir contedo em PDF, HTML, multimdia,
editor de texto, apresentaes ou qualquer outro contedo digital para
inclur em uma atividade, recurso, seo do curso, link ou download
direto.
O link de arquivos apresenta uma lista de arquivos e pastas,
dependendo do papel do usurio. A lista conter o nome, tamanho, data
da ltima modificao e aes que podem modificar o item.
Para visualizar um arquivo, clique em seu nome. Seu navegador vai
exibi-lo ou efetuar o download para o seu computador.
Ferramentas
Mover, cancelar, criar arquivo ZIP
possvel mover, cancelar completamente ou arquivar em ZIP um ou
mais itens. Primeiro, selecione os itens na lista marcando as caixas
sua esquerda. Ento utilize o menu Com arquivos escolhidos at a
ao que deseja realizar.
Criar um diretrio
O boto Criar um diretrio se encontra abaixo da lista. A estrutura
de arquivos inicial para um curso simples. Mdulos no Moodle
podem criar seu prprio diretrio. Em geral, um professor pode criar
um ou mais diretrios em qualquer lugar da rea de arquivos. Esses
diretrios podem ser vistos ao acrescentar uma imagem ou recurso de
dentro de um curso.
Enviar um arquivo
Na parte de baixo de todas as telas de arquivo h um boto Enviar
um arquivo. Isso permitir o envio de um nico arquivo. Enviar um
arquivo com o mesmo nome de um arquivo existente sobrescrever
automaticamente o arquivo existente sem um aviso.
DICA: Ao criar primeiro um arquivo ZIP com um grupo ou diretrio
de arquivos, voc pode enviar esse arquivo e o Moodle lhe dar um link
para descompact-lo. A ao de descompactao criar os arquivos e
diretrios na seo de arquivos administrativos.
Com base nesse trecho, possvel reconstruir parte da metamensagem
do designer, como a seguir:
Eu acredito que voc trabalha com diversos tipos de arquivo, cada qual
identificado pelo seu nome, tamanho e data de ltima modificao. s
vezes voc quer organizar os arquivos, e para isso prefere utilizar
diretrios, por entre os quais voc quer mover um ou mais arquivos de
uma s vez. Ainda para manter os arquivos de um curso organizados,
voc quer poder exclu-los ou compact-los em um arquivo ZIP.
Como voc costuma atualizar os arquivos com novas verses,
mantendo o mesmo nome, eu tornei muito fcil substituir a verso
anterior, bastando para isso enviar o novo arquivo com o mesmo nome
do arquivo existente. Acredito que voc ser cuidadoso e, portanto, no
vou pedir confirmao antes de efetuar essa sobreposio.
Como voc costuma enviar vrios arquivos de uma s vez, para poupar
o seu tempo eu permito que voc envie um arquivo ZIP contendo toda a
estrutura de diretrios e arquivos que voc organizou, e dentro do
Moodle descompacte-os nos diretrios apropriados.
Tendo reconstrudo a metamensagem com base nos signos metalingusticos, o
avaliador prossegue ento para a inspeo e anlise dos signos estticos. Ele inspeciona a
parte da interface que corresponde ao cenrio de interao avaliado, buscando identificar
e interpretar os signos estticos nela codificados. Os signos estticos expressam o estado
do sistema em determinado instante (veja Seo 3.8.1). Eles so representados pelos
elementos presentes nas telas da interface (ou equivalentes em interfaces no visuais),
como rtulos, imagens, caixas de texto, botes, menus etc., bem como a disposio
(layout), tamanho, cor, fonte e demais caractersticas desses elementos de interface. A
anlise dos signos estticos deve considerar apenas os elementos de interface
apresentados em cada tela num instante de tempo, sem examinar o comportamento do
sistema, nem as relaes temporais e causais entre os elementos de interface. Para
concluir a anlise dos signos estticos, o avaliador deve reconstruir um novo trecho da
metamensagem do designer, tambm guiado pelas perguntas utilizadas anteriormente
(Exemplo 10.5). Esse trecho deve ser elaborado separadamente daquele reconstrudo com
base nos signos metalingusticos, a fim de que o avaliador possa compar-los somente
aps a inspeo de todos os tipos de signo.

Exemplo 10.5
A nlise (parcial) dos signos estticos
Considere a seguinte tela de seleo de um arquivo do sistema Moodle,
para associ-lo a um tpico do curso:

FIGURA 10.1 Tela para seleo de arquivo no Moodle.

Uma possvel reconstruo (parcial) da mentamensagem do designer


com base nos signos estticos a seguinte (entre colchetes so
apresentadas as evidncias que apoiam cada afirmao):
Eu acredito que voc seja um professor que organiza seu material
didtico em diversos arquivos [apresentao em tabela], e que toda vez
que deve selecionar um arquivo pode aproveitar para reorganizar um
ou mais arquivos [vrios botes e links alm do link Escolher]. No
entanto, acredito que voc no registre tantos arquivos a ponto de
precisar orden-los de diferentes maneiras [ausncia de opes de
ordenao].
Para identificar se um arquivo o desejado, voc precisa apenas
examinar o nome, tamanho e data de registro do arquivo [colunas da
tabela]. Se identificar que o arquivo desejado ainda no foi registrado
no sistema, quer registr-lo logo a partir daqui [boto Enviar um
arquivo], para no perder tempo dando voltas no sistema.
Voc cuidadoso, e costuma examinar se o arquivo foi registrado
corretamente [link no nome do arquivo]. Mesmo aps efetuar o envio
de um arquivo, voc pode decidir modificar o seu nome [link
Renomear], para identificar mais claramente o seu contedo.
Voc gosta de organizar seus arquivos hierarquicamente em pastas
[boto Criar um diretrio], pois est acostumado a organiz-los assim
em seu sistema operacional [padro do Windows Explorer]. Alm
disso, voc quer poder manipular diversos arquivos de uma vez
[checkbox ao lado de cada arquivo, botes Selecionar tudo e Anular
todas as selees e combo Com arquivos escolhidos], para agilizar o
seu trabalho.

Na anlise dos signos dinmicos, o avaliador deve inspecionar o processo de interao


que o usurio pode vivenciar atravs da interface. Com base nos cenrios de interao, o
avaliador navega pela interface para identificar os signos dinmicos evidenciados pelas
relaes temporais e causais entre outros signos. Os signos dinmicos so percebidos
atravs de modificaes na interface que comuniquem ao usurio o comportamento do
sistema em decorrncia de aes do usurio (e.g., clicar no mouse, teclar enter, mudar o
foco de um campo de formulrio para outro), de eventos externos (e.g., receber um novo
e-mail, a conexo com a Internet falhar etc.) ou do passar do tempo. Por exemplo, signos
dinmicos so geralmente representados por animaes, abrir e fechar dilogos,
transies entre telas, ou modificaes nos elementos de uma tela (e.g., habilitar um
boto, atualizar um texto ou imagem, modificar o layout de alguns elementos de interface
etc.). A concluso da anlise dos signos dinmicos deve ser registrada pelo avaliador com
uma nova reconstruo da metamensagem pelo designer, tambm guiado pelas
perguntas apresentadas anteriormente (Exemplo 10.6).
Exemplo 10.6
A nlise (parcial) dos signos dinmicos
Considere, a partir da tela apresentada na figura anterior, esta sequncia
de telas para enviar um arquivo atravs do Moodle:

FIGURA 10.2 Tela para envio de um arquivo (acionada clicando-se em Enviar um arquivo na
Figura 10.1).

FIGURA 10.3 Tela para envio de um arquivo (acionada clicando-se em Choose file na figura
anterior).
FIGURA 10.4 Tela para envio de um arquivo (acionada clicando-se em um arquivo e em Open
na figura anterior).

Com base nessa sequncia, possvel reconstruir um trecho da


metamensagem do designer como a seguir:
Acredito que voc gosta de ser informado sobre o que pode fazer com o
sistema passo a passo, mesmo que isso seja um pouco ineficiente. Caso
haja alguma restrio sobre uma ao, voc quer ser informado antes
de realiz-la. Portanto, projetei o sistema para lhe informar o
tamanho mximo do arquivo que voc pode enviar, antes de permitir
que voc localize o arquivo. Como voc privilegia uma atuao
cuidadosa sobre a eficincia, antes de efetuar o envio propriamente dito,
o sistema pede para voc confirmar o arquivo localizado. Finalmente,
como voc deve querer confirmar que o envio foi feito, projetei o sistema
para lhe informar sobre o resultado do envio [mensagem Arquivo
enviado com sucesso], alm de incluir o arquivo na lista de arquivos
registrados, em ordem alfabtica.

Sempre que no houver signos metalingusticos que expliquem algum signo esttico
ou dinmico, o avaliador deve julgar se os signos sem explicaes podem ser
compreendidos (ou inferidos) pelo usurio com a experincia de uso.
Os signos metalingusticos, estticos e dinmicos tm poder de expresso diferente,
pois pertencem a vrios sistemas de significao. Por exemplo, os signos metalingusticos
presentes na ajuda on-line descrevem e fornecem explicaes sobre os demais signos
codificados na interface em linguagem natural, possivelmente complementada por
imagens e animaes. J os signos estticos em interfaces visuais costumam utilizar
cones, botes e menus para possibilitar a interao do usurio com o sistema. Sendo
assim, no raro haver diferenas nas metamensagens reconstrudas durante a anlise
de cada um dos trs tipos de signos. Para que a comunicao designerusurio seja bem-
sucedida, essas metamensagens no podem ser contraditrias ou inconsistentes umas com
as outras. A consistncia e a regularidade so importantes para criar e evocar padres de
significao que so familiares aos usurios.
Tambm preciso ter um cuidado especial com ambiguidades entre as
metamensagens reconstrudas, porque elas podem atrapalhar a interao. Por exemplo,
em um sistema que possui uma biblioteca de arquivos, como um reprodutor de msica
ou gerenciador de fotos, o significado do comando Excluir pode ser ambguo para o
usurio. Ele pode significar excluir o arquivo apenas da biblioteca do programa ou excluir
o arquivo da biblioteca do programa e tambm do local de armazenamento. Em casos
como esse, fundamental o designer comunicar ao usurio o significado do comando
Excluir codificado no sistema (de Souza et al., 2006; Prates e Barbosa, 2007). No sistema
Moodle, a ao Cancelar completamente (uma das opes da combo Com arquivos
escolhidos da Figura 10.5) tem o efeito de remover o(s) arquivo(s) selecionado(s).

FIGURA 10.5 Tela de gerenciamento de arquivos, aps acionar Enviar este arquivo na figura anterior.

Na atividade de consolidao dos resultados (veja Seo 9.7.5), o avaliador deve contrastar
e comparar as metamensagens reconstrudas durante a anlise dos signos
metalingusticos, estticos e dinmicos. Desse modo, ele revisa as trs metamensagens
reconstrudas, procurando intencionalmente por significados contraditrios,
inconsistentes ou ambguos para os signos que as compem (Exemplo 10.7).

Exemplo 10.7
C omparao parcial entre as metamensagens
reconstrudas a partir dos signos
metalingusticos, estticos e dinmicos
Nos exemplos anteriores, podemos observar que as metamensagens
reconstrudas a partir dos signos metalingusticos e estticos indicam que
o designer considera que usurio privilegia a eficincia, permitindo o
acesso a diversas funes diferentes quando o usurio entra na tela para
selecionar um arquivo. J na metamensagem reconstruda a partir dos
signos dinmicos, o designer parece considerar que a eficincia no to
importante. Essa discrepncia pode indicar uma falta de compreenso do
designer sobre o perfil dos seus usurios ou um descuido no momento de
projetar os passos necessrios para alcanar um determinado objetivo.
Esse tipo de inconsistncia nas metamensagens pode causar um impacto
negativo na interao do usurio, e deve ser evitada.

Para motivar e auxiliar a comparao das trs metamensagens, o mtodo de inspeo


semitica sugere as cinco perguntas a seguir (de Souza et al., 2006):
1. O usurio poderia interpretar este signo ou esta mensagem diferente do previsto pelo
designer? Como? Por qu?
2. Essa outra interpretao ainda seria consistente com a inteno de design?
3. A interpretao que estou (como avaliador) fazendo no momento me lembra de
outras que j fiz em momentos anteriores da avaliao? Quais? Por qu?
4. possvel formar classes de signos estticos e dinmicos a partir das anlises
realizadas? Quais?
5. Existem signos estticos ou dinmicos que esto aparentemente mal classificados de
acordo com as classes propostas em 4? Isso poderia causar problemas de
comunicao com o sistema? Como?
Se o avaliador desejar, ele pode realizar outras perguntas durante a comparao das
metamensagens reconstrudas. O conjunto de perguntas sugerido serve apenas como um
guia til para proporcionar uma inspeo semitica mais produtiva.
Depois de contrastar e comparar as trs metamensagens reconstrudas, o avaliador
deve elaborar uma verso unificada da metamensagem. Por fim, o avaliador deve realizar
um julgamento dos problemas de comunicabilidade identificados (de Souza et al., 2006). Esses
problemas podem atrapalhar os usurios de terem acesso metamensagem do designer
e de interagirem com o sistema de forma produtiva. Eles basicamente ocorrem quando
h lacunas, inconsistncias, contradies ou ambiguidades nas metamensagens
recontrudas a partir da inspeo e anlise de cada tipo de signo.
Na atividade de relato dos resultados, o avaliador deve (de Souza et al., 2006; veja Seo
9.7.5):
fazer uma breve descrio do mtodo para auxiliar o leitor a compreender como os
resultados foram obtidos;
descrever os critrios utilizados para selecionar as partes da interface inspecionadas;
para cada um dos trs tipos de signos inspecionados, fornecer:
identificao de signos relevantes (listar e justificar a sua relevncia);
identificao das classes de signos utilizadas;
uma verso revisada da metamensagem do designer.
redigir a apresentao e explicao do julgamento do avaliador sobre os problemas de
comunicabilidade encontrados, que possam dificultar ou impedir os usurios de
entenderem a metamensagem ou interagirem com o sistema de forma produtiva.
O mtodo de inspeo semitica no exige mais de um avaliador. Se houver mais de
um avaliador, eles devem trabalhar em conjunto em todas as atividades. Caso o sistema
avaliado possua mais de um perfil de usurio, cada avaliador pode ficar responsvel por
inspecionar a interface sob o ponto de vista de um dos perfis.
10.2 Avaliao de IHC atravs de observao
Como apresentado na Seo 9.6, os mtodos de observao permitem ao avaliador coletar
dados sobre situaes em que os participantes realizam suas atividades, com ou sem
apoio de tecnologia computacional. O registro e a anlise desses dados permitem
identificar problemas reais que os participantes enfrentaram, e no apenas problemas
potenciais previstos pelo avaliador como em uma avaliao por inspeo. Nas prximas
subsees so apresentados os seguintes mtodos de avaliao por observao: teste de
usabilidade, mtodo de avaliao de comunicabilidade e prototipao em papel.

10.2.1 Teste De Usabilidade


O teste de usabilidade visa a avaliar a usabilidade de um sistema interativo a partir de
experincias de uso dos seus usurios-alvo (Rubin, 1994; Rubin e Chisnell, 2008). Os
objetivos da avaliao determinam quais critrios de usabilidade devem ser medidos.
Esses critrios so geralmente explorados por perguntas especficas associadas a algum
dado mensurvel, que com frequncia pode ser objetivamente capturado durante a
interao do usurio com o sistema. Por exemplo, caso o objetivo do estudo seja avaliar a
facilidade de aprendizado de um determinado sistema, um teste de usabilidade poder
fornecer respostas para perguntas como: Quantos erros os usurios cometem nas
primeiras sesses de uso?, Quantos usurios conseguiram completar com sucesso
determinadas tarefas? e Quantas vezes os usurios consultaram a ajuda on-line ou o
manual de usurio?.
Para realizar as medies desejadas, um grupo de usurios convidado a realizar um
conjunto de tarefas usando o sistema num ambiente controlado, como um laboratrio.
Durante as experincias de uso observadas, so registrados vrios dados sobre o
desempenho dos participantes na realizao das tarefas e suas opinies e sentimentos
decorrentes de suas experincias de uso. A Tabela 10.4 apresenta as atividades do teste de
usabilidade.
Tabela 10.4
Atividades do teste de usabilidade

Na atividade de preparao, so realizadas as atividades comuns aos mtodos de


avaliao por observao (veja Seo 9.7.2). Em particular, so definidas as tarefas que os
participantes vo realizar e os dados a serem coletados.
A coleta de dados inclui o questionrio pr-teste, a sesso de observao e a entrevista
ps-teste (veja Seo 9.7.3). Durante as sesses de observao, so coletados diferentes
tipos de dados. Por exemplo, para cada tarefa, realizada por cada participante, possvel
medir: o grau de sucesso da execuo, o total de erros cometidos, quantos erros de cada
tipo ocorreram, quanto tempo foi necessrio para conclu-la, o nmero de vezes que a
ajuda on-line foi consultada, o grau de satisfao do usurio, e assim por diante. Alm
disso, tambm so coletados: anotaes do avaliador, vdeos de interao, registro das
teclas digitadas e udio com os comentrios dos participantes.
Nas atividades de interpretao e consolidao, os dados dos participantes devem ser
organizados de modo a evidenciar as relaes entre eles (veja Sees 9.7.4 e 9.7.5).
Historicamente, o teste de usabilidade tem sido empregado para obter sobretudo
resultados quantitativos, tais como: testar hipteses, descobrir tendncias, comparar
solues alternativas e verificar se o sistema atingiu as metas de usabilidade definidas no
incio do projeto. Para esse tipo de anlise, geralmente utilizamos tabelas e grficos, e
calculamos mdias, porcentagens e qualquer outro indicador relevante. Por exemplo,
considere uma meta de usabilidade definindo que uma determinada tarefa deve ser
realizada em at cinco minutos. Um teste de usabilidade permite avaliar o grau em que
essa meta foi atingida, atravs do nmero de usurios que concluram a tarefa dentro do
tempo desejado, do tempo mdio despendido por eles e do desvio padro
correspondente. Se as metas de usabilidade no forem atingidas, as concluses que o
avaliador pode tirar desse tipo de resultado costumam ser bem gerais, como: a parte do
sistema relacionada com a tarefa avaliada no to eficiente quanto desejado.
Mais recentemente, o teste de usabilidade tambm tem sido empregado para fornecer
resultados qualitativos (Rubin e Chisnell, 2008; Kuniavsky, 2003). Para Rubin e Chisnell
(2008), a anlise dos dados coletados tambm deve identificar a origem dos problemas na
interao que prejudicaram o desempenho mensurado. Um trecho de interao em que
ocorreu um problema pode estar associado a uma parte do udio com comentrios do
participante, a um conjunto de teclas digitadas e a certas anotaes do avaliador. A
anlise conjunta desses dados pode revelar aspectos que no seriam identificados atravs
da anlise de um nico tipo de dado. Para cada problema observado, o avaliador deve
analisar todos os dados coletados de modo a interpretar quais caractersticas, partes e
comportamentos da interface podem t-lo causado e assim elaborar possveis explicaes
sobre o problema. Essas explicaes constituem um resultado qualitativo importante
para justificar as recomendaes do avaliador no reprojeto da interface e da interao.
Na consolidao dos dados coletados, Kuniavsky (2003) tambm recomenda que o
avaliador categorize os problemas encontrados durante a interao de todos os
participantes, descrevendo cada categoria de problema, em que partes da interface ela
ocorre e os impactos imediatos na usabilidade do sistema avaliado. Tanto quanto
possvel, o avaliador deve explicar suas hipteses sobre as possveis causas de cada classe
de problemas com base nas suas interpretaes do que ocorreu e fornecer sugestes de
melhorias na interface e interao.
O relato dos resultados do teste de usabilidade deve descrever (veja Seo 9.7.5):
os objetivos e escopo da avaliao;
uma breve descrio do mtodo de teste de usabilidade;
o nmero e o perfil dos avaliadores e dos participantes;
as tarefas executadas pelos participantes;
tabelas e grficos que sumarizam as medies realizadas;
uma lista de problemas encontrados, indicando, para cada problema:
local onde ocorreu;
descrio e justificativa;
discusso, indicando os fatores de usabilidade prejudicados;
sugestes de soluo.

Exemplo 10.8
R esultados de um teste de usabilidade
Um teste de usabilidade foi projetado para avaliar o desempenho dos
usurios na incluso de um arquivo associado a um tpico de aula em dois
sistemas: no Moodle (denominado sistema A) e em outro sistema Web
desenvolvido pelo grupo que realizou a avaliao (sistema B).
O perfil dos participantes do teste era de professores que no conheciam
nenhum dos sistemas. Foram recrutados 12 professores, dentre os quais
seis homens e seis mulheres, todos professores de disciplinas de cincias
exatas e de computao. Cada usurio deveria utilizar os dois sistemas.
Para que a ordem em que eles fossem expostos ao sistema no
interferisse nos resultados do teste, metade dos participantes foi exposta
ao sistema A e depois ao sistema B (grupo AB), e a outra metade na ordem
inversa (grupo BA).
Os dados coletados foram: tempo para concluso da tarefa; nmero de
erros cometidos; nmero de acessos ao sistema de ajuda; nmero de
usurios que no conseguiram realizar a tarefa; nmero de vezes que os
usurios se desviaram do caminho mais eficiente.
Para assegurar a validade dos dados coletados, foi solicitado a todos os
usurios associar o mesmo arquivo, localizado no mesmo diretrio, sob
condies semelhantes de conexo com o servidor. A memria cache do
navegador era esvaziada entre cada sesso de teste.
A hiptese nula e a hiptese alternativa so:
H0: No h diferena entre o tempo de realizao da atividade nos
sistemas A e B.
H1: Existe diferena entre o tempo de realizao da atividade nos
sistemas A e B.
Os grficos a seguir apresentam os valores coletados para o tempo de
realizao da tarefa:

Considerando =0,05, um teste t em pares rejeita a hiptese nula (t=3,22 >3,1058). Sendo
assim, podemos concluir que, para a atividade de incluso de um arquivo associado a um
tpico de aula por usurios iniciantes, a eficincia dos usurios maior no sistema B que no
sistema A (Levine et al., 2008).
10.2.2 Mtodo De Avaliao De Comunicabilidade
O mtodo de avaliao de comunicabilidade visa apreciar a qualidade da comunicao da
metamensagem do designer para os usurios (Prates et al., 2000a; de Souza, 2005a; Prates
e Barbosa, 2007; de Souza e Leito, 2009). Assim como o mtodo de inspeo semitica, o
mtodo de avaliao de comunicabilidade tem como fundamentao terica a engenharia
semitica, apresentada na Seo 3.8. Esses dois mtodos avaliam a comunicabilidade a
partir de diferentes pontos de vista: enquanto a inspeo semitica avalia a qualidade da
emisso da metacomunicao do designer, o mtodo de avaliao de comunicabilidade
avalia a qualidade da recepo dessa metacomunicao.
Representantes dos usurios so convidados a realizar um conjunto de tarefas
utilizando o sistema em um ambiente controlado, como um laboratrio. Essas
experincias de uso so observadas e registradas, principalmente em vdeos de interao.
Os avaliadores analisam cada registro de experincias de uso para compreender como foi
a interao de cada usurio com o sistema sendo avaliado. O foco dessa anlise abrange
os provveis caminhos de interpretao dos usurios, suas intenes de comunicao e,
principalmente, as rupturas de comunicao que ocorreram durante a interao. Como
resultado, os avaliadores identificam problemas na comunicao da metamensagem do
designer e na comunicao do usurio com o sistema, e tambm ajudam a informar ao
designer as causas desses problemas. A avaliao de comunicabilidade um mtodo
qualitativo que privilegia a anlise em profundidade. Desse modo, o nmero de
participantes normalmente pequeno, variando entre cinco e dez participantes. A Tabela
10.5 apresenta as atividades do mtodo de avaliao de comunicabilidade.
Tabela 10.5
Atividades do mtodo de avaliao de comunicabilidade

Na atividade de preparao (veja Seo 9.7.2), recomenda-se realizar uma breve


inspeo dos signos estticos, dinmicos e metalingusticos da interface, caso no tenha
sido feita uma inspeo semitica completa. Essa inspeo orienta a definio dos
cenrios de tarefas que os participantes devero realizar e a elaborao do material de
apoio. Ao preparar o ambiente de avaliao, o avaliador deve configurar e testar
cuidadosamente o software de gravao do vdeo de interao, com tudo o que aparece na
tela do usurio durante a interao, bem como as teclas digitadas. Esse vdeo o material
bsico e fundamental para as atividades de interpretao e consolidao dos resultados
nesse mtodo de avaliao.
A coleta de dados inclui o questionrio pr-teste, a sesso de observao e a entrevista
ps-teste (veja Seo 9.7.3). O principal resultado da coleta de dados um conjunto dos
vdeos de interao capturados de cada sesso (um vdeo por participante, ou um vdeo
de cada tarefa), acompanhados de anotaes dos avaliadores e demais registros sobre o
que ocorreu durante essas experincias de uso e sobre o que os usurios disseram na
entrevista ps-teste.
Na atividade de interpretao (veja Seo 9.7.4), o avaliador faz a etiquetagem dos
vdeos. Ele assiste a cada vdeo de interao repetidas vezes para identificar rupturas de
comunicao, ou seja, momentos da interao em que o usurio demonstra no ter
entendido a metacomunicao do designer, ou momentos em que o usurio encontra
dificuldades de expressar sua inteno de comunicao na interface. As rupturas de
comunicao encontradas nos vdeos de interao devem ser categorizadas por uma
expresso de comunicabilidade que coloca palavras na boca do usurio, tais como:
Cad? e Epa!. Dessa forma, associar uma expresso de comunicabilidade a uma
sequncia de interao permite ao avaliador presumir o que o usurio poderia ter dito
(ou de fato disse) naquele momento. Por exemplo, se o usurio procura na interface como
executar determinada ao, o avaliador associa essa ruptura de comunicao com a
etiqueta Cad?, como se o usurio estivesse dizendo isso em voz alta naquele
momento. Existem 13 etiquetas para categorizar rupturas de comunicao no mtodo de
avaliao de comunicabilidade. So elas (Prates et al., 2000a; de Souza, 2005a; Prates e
Barbosa, 2007; de Souza e Leito, 2009): Cad? E agora? O que isto? Epa! Onde estou? U, o
que houve? Por que no funciona? Assim no d. Vai de outro jeito. No, obrigado! Pra mim est
bom. Socorro! e Desisto.
A etiqueta Cad? usada quando o usurio deseja expressar sua inteno de
comunicao, mas no consegue express-la com os signos codificados na interface. Por
exemplo, o usurio pode saber que o sistema permite executar determinada ao, mas
no encontra como acion-la na interface. semelhante ao usurio saber o que dizer, mas
no encontrar palavras para tal. Essa etiqueta pode indicar uma escolha inadequada de
organizao ou expresso dos signos de interface. Presumindo-se que o usurio saiba
qual ao deseja realizar na interface, um sintoma tpico dessa ruptura de comunicao
ocorre quando o usurio navega por vrios elementos de interface. Ele abre e fecha
menus e dilogos, e varre os elementos da interface com o cursor do mouse. Depois de
navegar pela interface e encontrar o elemento que deseja, o usurio pode atuar sobre ele
com os dispositivos de entrada (e.g., clica com o mouse, pressiona as teclas do teclado
etc.) ou simplesmente examinar os elementos de interface a fim de obter a informao
desejada. Em geral, o usurio inicia a busca guiado pela sua interpretao dos signos
codificados na interface. Por exemplo, ele abre inicialmente o item de menu que
interpreta como sendo mais prximo ao desejado, depois o segundo mais prximo, e
assim sucessivamente. Quando essa busca temtica no funciona, ele pode passar para
uma busca mais aleatria e exaustiva, percorrendo toda a interface. Quanto menor for o
tempo e os passos necessrios para o usurio encontrar o que deseja, menor ser a
gravidade dessa ruptura.
A etiqueta E agora? empregada quando o usurio no sabe o que fazer em
determinado momento para concluir a tarefa, e procura descobrir qual deve ser o seu
prximo passo. Em geral, essa ruptura de comunicao ocorre quando, na interpretao
do usurio, os signos da interface aos quais ele tem acesso no momento no contribuem
para avanar em direo ao alcance do seu objetivo. Como o usurio no consegue
formular a prxima inteno de comunicao, o sintoma tpico navegar pelos elementos
da interface de forma sequencial ou aleatria para tentar obter alguma dica que lhe
permita formular uma inteno e identificar o prximo passo a ser executado. Nesse
caso, costuma ser difcil definir alguma relao entre o passo anterior e o seguinte, pois o
usurio parece estar perdido. Ele abre e fecha dilogos, varre menus e barras de
ferramentas, e l sistematicamente as dicas, instrues e avisos em busca de uma
orientao sobre qual deve ser o seu prximo passo.
Embora os sintomas associados s etiquetas E agora? e Cad? sejam parecidos,
eles representam rupturas diferentes. No caso de Cad?, o usurio sabe o que quer
fazer. Porm, no caso da etiqueta E agora?, o usurio no sabe o que deve fazer para
concluir a tarefa. Sempre que os avaliadores perceberem esses sintomas durante uma
observao de uso e estiverem em dvida sobre qual ruptura de comunicao realmente
ocorreu, eles devem esclarecer essas dvidas na entrevista ps-teste.
A etiqueta O que isto? usada quando o usurio no consegue interpretar o
significado dos signos estticos e dinmicos codificados na interface. Pode indicar o uso
de um cdigo expressivo inadequado, que no seja familiar ao usurio. O sintoma tpico
o usurio navegar pela interface procurando por alguma dica, aviso ou explicao que
explique o significado codificado dos signos no compreendidos por ele. Por exemplo, o
usurio pode parar o cursor sobre cones e botes de comando esperando ver uma dica
explicativa, ou pode acionar um menu ou boto de comando apenas para verificar os
efeitos dessa ao.
Os sintomas da etiqueta O que isto? podem se manifestar tambm durante uma
ruptura etiquetada como Cad? ou E agora?. A inteno de comunicao do usurio
diferencia esses tipos de rupturas. Se o usurio estiver apenas explorando a interface
para aprender os significados nela codificados, tratam-se de casos isolados de O que
isto?. Caso contrrio, pode ser uma combinao de O que isto? com um Cad?
(caso o usurio saiba o que est procurando) ou com um E agora? (caso o usurio ainda
no saiba o que procurar).
A etiqueta Epa! representa uma situao em que o usurio cometeu um equvoco,
percebe o engano rapidamente e busca desfazer os resultados da ao indesejada. Essa
etiqueta pode indicar uma ambiguidade na expresso do signo que o usurio utilizou e o
levou ao equvoco. A recuperao de um equvoco pode ser rpida, como cancelar logo
um dilogo acionado por engano, sem mesmo interagir com ele, possivelmente causado
pela semelhana entre dois itens de menu. Tambm pode ser o acionamento de um
comando desfazer (undo) imediatamente aps realizar a ao equivocada. Pode ainda
exigir um caminho de interao maior e mais complexo, como editar um registro que
acabou de criar porque percebeu que digitou algo errado. Quanto maior o esforo e
tempo necessrios para desfazer o engano cometido, maior ser a gravidade dessa
ruptura de comunicao.
A etiqueta Onde estou? utilizada quando o usurio tenta dizer algo que o sistema
capaz de entender (i.e., reagir adequadamente) em um outro contexto, diferente do
atual. Sintomas comuns dessa ruptura de comunicao ocorrem quando o usurio tenta
ativar aes desabilitadas (e.g., tentar acionar um boto de comando que esteja
desabilitado momentaneamente) ou interagir com signos que so apenas de exibio
(e.g., tentar editar um texto em modo de pr-visualizao ou em uma caixa de texto
desativada). Essas operaes poderiam ser realizadas sobre esses mesmos elementos de
interface em outros contextos de uso. Nesses casos, o usurio demonstra estar confuso
em relao ao contexto atual e sobre o que possvel fazer no momento, pois sua
interpretao dos signos de interface no corresponde aos significados nela codificados
para aquele contexto.
A etiqueta U, o que houve? usada quando o usurio no percebe ou no
compreende as respostas do sistema decorrentes de uma ao ou evento anterior. Essa
etiqueta pode indicar uma ambiguidade na expresso do signo que o designer utilizou
para comunicar a resposta do sistema ou falta de familiaridade do usurio com essa
expresso. Nesse caso, comum o usurio repetir a operao realizada. Tambm
possvel perceber essa ruptura de comunicao quando as aes posteriores do usurio
so inconsistentes com as respostas do sistema.
A etiqueta Por que no funciona? representa uma situao na qual o usurio
esperava obter determinados resultados do sistema e no entende por que o sistema
produziu os resultados diferentes do esperado. Nesse caso, o usurio percebe os
resultados do sistema em decorrncia de suas aes, mas no se conforma em obter
resultados diferentes do esperado. Ele acredita ter feito as coisas certas, ento costuma
repetir suas aes com a esperana de identificar o problema que gerou resultados
inesperados para poder corrigi-lo. Essa etiqueta pode indicar uma falta de
correspondncia entre a viso do designer e a expectativa do usurio sobre os efeitos de
uma ao do usurio na interface ou sobre como um objetivo pode ser alcanado.
A repetio de aes do usurio pode ser etiquetada como U, o que houve? ou Por
que no funciona?. A diferena entre essas rupturas de comunicao depende do que o
usurio percebeu e compreendeu das respostas do sistema. Na etiqueta U, o que
houve?, o usurio nem chega a perceber ou compreender as respostas do sistema. J na
etiqueta Por que no funciona?, o usurio percebeu e compreendeu as respostas do
sistema, mas no se conformou com o resultado encontrado.
A etiqueta Assim no d usada quando o usurio interrompe e abandona um
caminho de interao com vrios passos por consider-lo improdutivo. Quando o usurio
percebe estar engajado num caminho de interao que no contribui para a concluso da
tarefa, ele costuma interromp-lo subitamente, desfazer as aes realizadas nesse
caminho improdutivo, e iniciar um caminho diferente para concluir sua tarefa. Essa
etiqueta pode indicar uma ambiguidade na expresso de uma sequncia de signos
utilizados pelo usurio e pelo preposto do designer.
As rupturas de comunicao representadas por Assim no d e Epa! se
assemelham pelo abandono de caminhos de interao. No primeiro caso, o usurio
abandona uma sequncia de aes geralmente longa, com custo maior de recuperar um
caminho produtivo. No segundo, o usurio abandona rapidamente uma ao isolada,
com um custo menor de recuperar um caminho produtivo.
A etiqueta Vai de outro jeito usada quando o usurio no conhece o caminho de
interao preferido pelo designer (geralmente mais curto e simples) ou no consegue
percorr-lo, e ento obrigado a seguir por um outro caminho de interao. Essa etiqueta
pode indicar uma falta de correspondncia entre a viso do designer e a expectativa do
usurio sobre como um objetivo do usurio pode ser alcanado. Por exemplo, num editor
de texto, o usurio pode formatar individualmente cada pargrafo por desconhecer que o
sistema oferece estilos que podem ser aplicados a diversos pargrafos, de forma
consistente. Ou ele tenta utilizar estilos, no obtm o resultado esperado e ento
prossegue para a formatao manual. Para o avaliador conhecer o caminho preferencial
do designer, ele pode consultar a ajuda on-line, a documentao do sistema, e, se
possvel, o prprio designer.
A etiqueta No, obrigado! utilizada quando o usurio decide seguir por um caminho
no preferido pelo designer, mesmo conhecendo o caminho preferido e sabendo
percorr-lo. Ela pode indicar uma falta de compreenso do designer sobre as formas
preferenciais de o usurio alcanar um objetivo ou idiossincrasias do usurio que
revelam a necessidade de mecanismos de customizao (de Souza, 2005a). O avaliador
pode perceber que o usurio conhece o caminho preferido pelo designer se o usurio o
percorre pelo menos uma vez ou se ele o menciona explicitamente na entrevista ps-
teste. Num editor de textos, por exemplo, o usurio pode dispensar a operao de
numerao automtica que j conhece por achar mais simples inserir os nmeros
manualmente.
A diferena entre as etiquetas No, obrigado! e Vai de outro jeito depende de o
usurio estar ou no ciente dos caminhos de interao oferecidos e preferenciais. No
primeiro caso, o usurio conhece o caminho preferido pelo designer, mas decide seguir
por outro. No segundo, o usurio no conhece o caminho preferido pelo designer, e por
isso tem de percorrer um outro.
A etiqueta Pra mim est bom usada quando o usurio equivocadamente acredita
que concluiu a tarefa, sem, no entanto, t-la concludo com sucesso. Nesse caso, o usurio
tipicamente d por encerrada a tarefa, e relata na entrevista ps-teste que a concluiu com
sucesso. Esse equvoco geralmente causado por uma resposta do sistema com contedo
ou expresso inadequados.
A etiqueta Socorro! usada quando o usurio consulta a ajuda on-line ou outras
fontes de informao e explicao (o manual do usurio, os avaliadores etc.) para concluir
as tarefas. Isso ocorre porque o usurio no consegue interpretar os signos estticos e
dinmicos codificados na interface, e precisa recorrer aos signos metalingusticos, que
descrevem todos os signos e explicam como utiliz-los.
A etiqueta Desisto usada quando o usurio explicitamente admite no conseguir
concluir uma tarefa (ou subtarefa) e desiste de continuar tentando. O sintoma tpico o
usurio abandonar o cenrio de tarefa atual sem t-la concludo e passar para o prximo
cenrio de tarefa. Nas etiquetas Desisto e Para mim est bom, o usurio interrompe
a interao antes de concluir a tarefa com sucesso. A diferena que, no primeiro caso,
ele sabe que no concluiu a tarefa, e no segundo, acredita erroneamente que concluiu a
tarefa.
As entrevistas pr e ps-teste, as anotaes dos avaliadores e os demais registros
obtidos durante as sesses de interao auxiliam o avaliador na etiquetagem dos vdeos
de interao. Em particular, esses dados so importantes quando o avaliador fica em
dvida sobre qual etiqueta utilizar, ou qual ruptura de comunicao ocorreu em uma
determinada parte do vdeo de interao. Por exemplo, na entrevista ps-teste, o
avaliador pode perguntar ao participante qual caminho ele acredita que seria o preferido
pelo designer e, assim, distinguir se ocorreu uma ruptura de comunicao indicada pela
etiqueta No, obrigado! ou pela etiqueta Vai de outro jeito.
No final da etiquetagem, o avaliador ter uma lista de etiquetas para cada vdeo de
interao. Cada etiqueta deve estar associada a um trecho do vdeo e pode estar
acompanhada de anotaes do avaliador (Exemplo 10.9).
Exemplo 10.9
E tiquetagem de um vdeo de interao
Considere a tarefa de ordenar uma lista estruturada de compras no
Microsoft Word. A sequncia de telas a seguir ilustra instantneos da
interao do usurio com o editor de texto, juntamente com anotaes
sobre as aes do usurio e etiquetas de comunicabilidade associadas aos
momentos interpretados como rupturas de comunicao.
Usurio seleciona os itens que deseja ordenar, esperando que o editor
preserve os agrupamentos definidos pelos ttulos.

Ele procura uma opo de ordenao no menu Ferramentas, mas no a


encontra.
Etiqueta: Cad? (temtico)

Decide procurar em Ferramentas > Opes.


Etiqueta: Cad? (temtico)
Examina a guia Exibir.
Etiqueta: Cad? (temtico)

Examina tambm a guia Geral, em vo.


Etiqueta: Cad? (temtico)

Ele decide explorar agora o menu Editar.


Etiqueta: Cad? (temtico)
Para fechar o menu, o usurio clica na rea em branco do documento,
acidentalmente desfaz a seleo dos itens que quer ordenar e rapidamente
os seleciona de novo.
Etiqueta: Epa!

Ele examina a barra de ferramentas, mantendo o mouse sobre alguns


elementos para aguardar a dica correspondente.
Etiqueta: O que isto?

Inconformado, o usurio acessa novamente o menu Ferramentas.


Etiqueta: Por que no funciona? (Por que no est aqui?)
Determinado a encontrar a ferramenta de ordenao, o usurio examina
cada menu, sequencialmente.
Etiqueta: Cad? (sequencial)

Finalmente, encontra um item Classificar no menu Tabela. Ele o aciona


e confirma a janela de dilogo apresentada pelo sistema.
No h ruptura e, portanto, no h etiqueta.

Satisfeito, ele declara a tarefa concluda com sucesso. Entretanto, o


editor no respeitou a estrutura dos itens ao orden-los.
Etiqueta: Pra mim est bom.
Na atividade de consolidao dos resultados, o avaliador interpreta o significado do
conjunto de todas as etiquetas nos vdeos de interao, ou seja, ele julga a qualidade da
comunicao da metamensagem em funo das rupturas de comunicao observadas do
ponto de quem a recebe. Para atribuir significado s etiquetas, o avaliador deve
considerar os seguintes fatores (de Souza, 2005a, p. 137):
a frequncia e o contexto em que ocorre cada etiqueta (por participante, por tarefa, ou
em toda a interao), que auxiliam o avaliador a identificar problemas recorrentes ou
sistemticos na metacomunicao;
sequncias de etiquetas (por participante, por tarefa, ou em toda a interao), que
podem indicar uma ruptura comunicativa de maior alcance, envolvendo diferentes
signos de interface e requerendo mais tempo ou esforo para o usurio se recuperar e
retomar um caminho de interpretao produtivo;
o nvel dos problemas relacionados aos objetivos dos usurios (operacional, ttico ou
estratgico);
outras ontologias ou classes de problemas de IHC oriundas de outras teorias,
abordagens e tcnicas que podem enriquecer a interpretao do avaliador.
A frequncia com que as etiquetas ocorrem tende a mudar conforme o usurio ganha
experincia de uso (Prates et al., 2000b). Por exemplo, o nmero de etiquetas Cad? e
O que isto? costuma diminuir medida que o usurio aprende a utilizar o sistema
(de Souza, 2005a).
O contexto em que as etiquetas ocorrem pode apontar inconsistncias entre os
caminhos da interpretao do usurio e do designer causadas por problemas na
diferenciao de contextos de interao. Tais inconsistncias podem revelar a
oportunidade ou necessidade de permitir que os usurios se expressem ou realizem
aes num contexto em que atualmente isso no permitido.
A sequncia de etiquetas, principalmente quando se repete algumas vezes, fornece ao
avaliador informaes relevantes para identificar problemas nos caminhos
interpretativos do usurio. Por exemplo, uma sequncia das etiquetas Cad?, Assim
no d e Desisto indica um srio problema de metacomunicao. Nesse caso, o
usurio procurou expressar uma inteno correta, e somente depois de vrios passos
percebeu que estava num caminho improdutivo e acabou desistindo de expressar sua
inteno na interface.
Os problemas nesse processo de interpretao do usurio podem ser classificados em
trs nveis: operacional, ttico e estratgico (de Souza, 2005a, p. 125; de Souza et al., 2000).
Problemas operacionais ocorrem na expresso de uma fala individual do usurio, ou na
execuo de uma ao. Os problemas tticos ocorrem na expresso de uma sequncia de
falas, ou na execuo de uma sequncia de aes do usurio, visando alcanar
determinado objetivo. J os problemas estratgicos ocorrem na prpria definio dos
objetivos do usurio. Problemas operacionais podem causar problemas tticos e
estratgicos, assim como problemas tticos podem causar problemas estratgicos. Por
exemplo, se o usurio encontra um problema operacional por no conseguir expressar
uma inteno de comunicao (etiqueta Cad?), ele tambm ter um problema ttico
por ter dificuldade de iniciar ou continuar uma sequncia de falas (ou aes) para
alcanar determinado objetivo, e possivelmente ter um problema estratgico por
considerar que o sistema no oferece suporte ao objetivo em questo, quando, na
verdade, ele o faz. Os problemas operacionais costumam ser relativamente mais fceis de
resolver do que problemas tticos e estratgicos. J os problemas estratgicos costumam
ser mais graves porque indicam falhas completas na comunicao designerusurio.
A interpretao da etiquetagem dos vdeos auxilia o avaliador a decidir se houve
problemas na recepo da metamensagem (i.e., se existem problemas de
comunicabilidade no sistema avaliado). Caso existam, o avaliador ter condies de dizer
no apenas quais so os problemas, mas tambm por que eles ocorreram. J a ausncia de
etiquetas evidencia que os participantes receberam a metamensagem corretamente
durante a avaliao.
Quando a comunicao do usurio com o preposto do designer consegue obter um
efeito coerente e consistente com a inteno do usurio, dizemos que a comunicao
usuriosistema foi bem-sucedida. Entretanto, se o efeito obtido for incoerente ou
inconsistente com a inteno do usurio, ento ocorreram falhas na comunicao, sejam
elas percebidas ou no pelo usurio. As seguintes categorias de ruptura na comunicao
ajudam a explicar essas falhas:3
o usurio no consegue expressar o significado pretendido;
o usurio escolhe o modo errado de expressar o significado pretendido;
o usurio no consegue interpretar o que o sistema expressa;
o usurio escolhe a interpretao errada para o que o sistema expressa;
o usurio no consegue sequer formular uma inteno de comunicao.
A Tabela 10.6 apresenta a classificao das falhas de comunicao entre o usurio e o
preposto do designer, de acordo com as etiquetas de rupturas de comunicao (de Souza,
2005a, p. 138; de Souza e Leito, 2009, p. 4346).

Tabela 10.6
Classificao das falhas de comunicao usuriosistema representadas pelas
etiquetas do mtodo de avaliao de comunicabilidade (adaptada de Souza, 2005a,
p.138 ; de Souza e Leito, 2009, p. 4346).
Depois da interpretao das etiquetas, o avaliador deve elaborar o perfil semitico do
sistema avaliado para identificar e explicar seus problemas de comunicabilidade, bem
como informar seu reprojeto da interface de modo a corrigi-los. O perfil semitico
elaborado atravs da reconstruo da metamensagem do designer tal como ela foi
recebida pelo usurio. A parfrase da metamensagem deve ser usada como um modelo
(template) a ser preenchido (de Souza, 2005a, p.25):

Este o meu entendimento, como designer, de quem voc, usurio, , do que aprendi que
voc quer ou precisa fazer, de que maneiras prefere fazer, e por qu. Este, portanto, o
sistema que projetei para voc, e esta a forma como voc pode ou deve utiliz-lo para
alcanar uma gama de objetivos que se encaixam nesta viso.

Essa parfrase permite definir um conjunto de perguntas que guiam a reconstruo da


metamensagem. A etiquetagem dos vdeos e as respectivas interpretaes do avaliador
fornecem ao avaliador evidncias para responder as seguintes perguntas (de Souza e
Leito, 2009, p. 47):
Quem o designer pensa ser o usurio do produto por ele projetado? Ou seja, quem so
os usurios destinatrios da metamensagem do designer? Quais so seus perfis,
incluindo caractersticas e valores? Responder essa pergunta ajuda a julgar a
correspondncia (ou falta de correspondncia) entre os usurios presumidos pelo
designer e aqueles que utilizam o sistema.
Quais so os desejos e as necessidades dos usurios, na viso do designer? Como a
metacomunicao do designer privilegia certos desejos e necessidades em detrimento
a outros? Responder essa pergunta ajuda a julgar a correspondncia (ou falta de
correspondncia) entre o que o designer quis comunicar com o seu design e o que os
usurios entendem e fazem com ele.
Na viso do designer, de que maneiras os usurios preferem fazer o que desejam e
precisam, onde, quando, e por qu? Os usurios podem escolher diferentes formas de
comunicao com o sistema? Responder essa pergunta ajuda o designer a justificar os
sistemas de significao utilizados e julgar se suas decises so compatveis com a
viso de mundo dos usurios.
Qual foi o sistema que o designer projetou para os usurios, e como eles devem utiliz-
lo? Quo bem a expresso e o contedo da metacomunicao esto sendo
transmitidos aos usurios?
Qual a viso de design? Quo bem a lgica de design (design rationale)
compreendida (e aceita) pelos usurios?
Conforme o avaliador responde essas perguntas, ele pode comparar o que o designer
pretendia comunicar com as evidncias de como os usurios interpretaram o que foi
comunicado. Um sistema com boa comunicabilidade significa que o designer conseguiu
comunicar bem a metamensagem para o usurio, atravs da interface do sistema.
Na atividade de relato dos resultados, o avaliador deve descrever (veja Seo 9.7.5):
os objetivos da avaliao;
uma breve descrio do mtodo para auxiliar o leitor a compreender como os
resultados foram obtidos;
o nmero e o perfil dos avaliadores e dos participantes;
as tarefas executadas pelos participantes;
o resultado da etiquetagem, em geral contabilizando as etiquetas por usurio e tarefa;
os problemas de comunicabilidade encontrados;
sugestes de melhorias;
o perfil semitico do sistema.

10.2.3 Prototipao Em Papel


O mtodo de prototipao em papel (Snyder, 2003) avalia a usabilidade de um design de
IHC representado em papel, atravs de simulaes de uso com a participao de
potenciais usurios. Simular o uso em papel um modo rpido e barato de identificar
problemas de usabilidade antes mesmo de construir uma soluo de IHC executvel.
Sendo assim, esse mtodo uma opo interessante para uma avaliao formativa junto
aos usurios, principalmente para comparar alternativas de design. Ele permite avaliar
facilmente solues parciais, que no cobrem toda a interface com usurio, e solues de
baixa e mdia fidelidade, que ainda no definem todos os detalhes da interface.
Com tudo preparado, o avaliador convida usurios para executarem algumas tarefas
com apoio do sistema simulado em papel. Durante a simulao, os usurios falam, fazem
gestos ou escrevem para manifestar como desejam interagir com o sistema. Um avaliador
atua como computador para simular em papel a execuo do sistema e expressar suas
reaes em resposta s aes do usurio. Essas experincias de uso simuladas permitem
identificar as partes da interface que funcionam bem e aquelas que apresentam
problemas de usabilidade. A Tabela 10.7 sumariza as atividades do mtodo de
prototipao em papel.

Tabela 10.7
Atividades do mtodo de prototipao em papel

Na atividade de preparao, alm do material de apoio elaborado na maioria das


avaliaes com usurios (veja Seo 9.7.2), o avaliador deve elaborar prottipos em papel.
Representamos as telas do sistema em papel, em geral desenhadas mo livre e sem nos
preocuparmos com detalhes de interface que no sejam relevantes para a avaliao. A
inteno representar e destacar os elementos principais da interface com os quais o
usurio vai interagir durante a simulao da interao. Alm das telas estticas, o
avaliador tambm deve preparar outros pedaos de papel com partes da interface que se
modificam durante a interao, como menus, dicas sobre elementos de interface, itens de
alguma lista, resultados de busca e dilogos, por exemplo. O que for possvel prever deve
ser preparado antes das simulaes de uso. O que no for possvel ser desenhado no
papel durante as simulaes.
O Exemplo 10.10 apresenta um esboo de tela utilizado em uma sesso de prototipao
em papel. Observe que h anotaes em pedaos de papel adesivo que sero
manipulados durante a sesso de avaliao.

Exemplo 10.10
E sboo de tela utilizado em uma sesso de
prototipao em papel4

4 Imagem extra-da do Projeto Orientado de Marcela Cmara e Eduardo Ribeiro (2010).

Em seguida, o avaliador prepara o ambiente em que a simulao vai ocorrer,


tipicamente uma sala de reunio com mesa e cadeiras, e prepara os equipamentos
necessrios para registrar os dados, como gravador de voz e cmera de vdeo.
A coleta de dados (veja Seo 9.7.3) na prototipao em papel deve ser realizada por pelo
menos dois avaliadores: um responsvel por simular o comportamento do sistema e
outro por observar a experincia de uso. O responsvel por simular o sistema busca
compreender as aes do usurio sobre o prottipo em papel (e possivelmente as
intenes que motivaram tais aes), e modifica a interface conforme o comportamento
planejado para o sistema, sem, no entanto, fornecer explicaes ou orientaes para o
usurio. Tudo o que for necessrio informar ao usurio deve estar representado na
interface do sistema.
No incio da sesso, o responsvel por simular o comportamento do sistema apresenta
o prottipo em papel e explica como esto representados os elementos de interface
(widgets) e como os participantes podem interagir com eles. Por exemplo, os
avaliadores podem mostrar o que um item de menu, um boto de comando ou uma
combobox e dizer que possvel clicar sobre eles (com um dedo, uma caneta ou algum
outro instrumento). Depois de apresentar a interface, os avaliadores entregam os
cenrios ao participante e explicam as tarefas a serem executadas.
O participante, ento, comea a interagir com o prottipo em papel da interface do
sistema. Para iniciar uma tarefa, o participante pode querer navegar pelos itens de menu.
Ele pode manifestar isso de vrias formas, tal como dizer em voz alta ou colocar o dedo
sobre um item do menu principal. Como resposta a essa ao, o avaliador responsvel
por simular o comportamento do sistema deve apresentar um pedao de papel com os
subitens do menu principal indicado. Quando o usurio escolher qual menu acionar, ele
indica isso para o avaliador, que, por sua vez, modifica a interface com usurio simulando
outro comportamento correspondente ao do usurio, seja abrindo um dilogo sobre a
tela atual, substituindo a tela atual por outra etc.
Sempre que necessrio, os avaliadores podem modificar ligeiramente a interface para
solucionar algum problema simples de usabilidade, como, por exemplo, colocar um
boto de comando numa tela de modo a facilitar o acesso a uma operao. Se o problema
de usabilidade for mais complexo, os avaliadores podem sugerir que o participante passe
para a prxima tarefa solicitada.
Durante a simulao da interao, o observador deve ficar atento a diversos aspectos:
partes da interface que funcionaram bem e que funcionaram mal, quais tarefas foram
concludas com sucesso, quais erros foram cometidos, quais comentrios foram feitos e
quaisquer outros dados que lhe auxiliem a apreciar a qualidade da interface. Como nos
demais mtodos de observao, depois de terminar a execuo das tarefas os avaliadores
podem realizar uma entrevista ps-teste para colher a opinio do participante sobre o
prottipo da interface e sugestes de melhorias.
Aps cada experincia de uso observada, os avaliadores se renem para realizar a
atividade de interpretao (veja Seo 9.7.4). As anotaes dos avaliadores sobre a
experincia de uso, as entrevistas pr e ps-teste, e possivelmente o udio e o vdeo
gravados so analisados a fim de identificar problemas de usabilidade no prottipo de
interface avaliado. O resultado dessa anlise uma lista de problemas na interface que
devem ser corrigidos, alm de indicaes de partes do sistema que podem ser
aperfeioadas. Os problemas fceis de resolver podem ser resolvidos antes da execuo
da prxima simulao de uso com outro participante. Dessa forma, o prottipo em papel
da interface com usurio pode ser aprimorado por ciclos sucessivos de avaliao e
reprojeto.
Como durante a simulao de uso existe pelo menos um avaliador responsvel pela
observao, ele pode comear a interpretar os dados da experincia de uso enquanto
observa a atuao do usurio. Portanto, na prtica no existe uma separao clara de
quando termina a atividade de coleta de dados e quando comea a atividade de
interpretao. Pelo menos algumas partes dessas duas atividades so conduzidas em
conjunto na prototipao em papel.
Na atividade de consolidao dos resultados, os avaliadores verificam quais problemas
no puderam ser resolvidos no reprojeto rpido do prottipo de interface (veja Seo
9.7.5). Eles priorizam a correo dos problemas com base na gravidade (o quanto
prejudicaram a interao) e frequncia em que ocorreram. Por fim, os avaliadores
sugerem propostas de correo desses problemas ou de caminhos que podem ser
explorados para melhorar a interface.
No relato dos resultados, os avaliadores devem comunicar aos interessados:
os objetivos da avaliao;
uma breve descrio do mtodo de prototipao em papel;
o nmero e o perfil de avaliadores e dos participantes;
as tarefas executadas pelos participantes;
uma lista de problemas de usabilidade corrigidos durante os ciclos de avaliao e
reprojeto, indicando:
local onde ocorreu;
fatores de usabilidade prejudicados;
descrio e justificativa do problema;
correo realizada no prottipo em papel;
indicao se o problema voltou a ocorrer depois da correo;
uma lista dos problemas de usabilidade ainda no corrigidos, indicando:
local onde ocorreu;
fatores de usabilidade prejudicados;
descrio e justificativa do problema;
prioridade para correo;
sugestes de correo;
indicaes de partes do sistema que podem ser mais bem elaboradas.
10.3 Resumo Comparativo dos Mtodos de
Avaliao
Os mtodos de avaliao apresentados neste captulo propem modos prprios de coleta,
anlise e julgamento do valor de dados relacionados ao uso de sistemas computacionais
interativos. Nesta seo comparamos algumas caractersticas desses mtodos para
auxiliar o avaliador na escolha do mtodo mais adequado em cada caso. Eles sero
comparados de acordo com o que e quando se avalia, bem como o tipo de resultado
produzido.
Cada mtodo de avaliao de IHC mais adequado para avaliar alguns desses aspectos
relacionados ao uso do sistema (o que avaliar; Tabela 10.8).

Tabela 10.8
Aspectos geralmente avaliados atravs de cada mtodo

A classificao varia de um mtodo mais adequado (+++) at um mtodo inadequado


() para se avaliar o referido aspecto. Para avaliar a forma como os usurios se
apropriam dos sistemas computacionais interativos, utilizamos entrevistas, estudos de
campo, testes de usabilidade e avaliao de comunicabilidade. Para comparar e avaliar
ideias e alternativas de design, costumamos utilizar grupos de foco, avaliao heurstica e
prototipao em papel. J para avaliar a conformidade com um padro, utilizamos uma
avaliao por inspeo, como a avaliao heurstica, considerando algum conjunto de
recomendaes, guia de estilo ou norma. Como era de se esperar, os problemas na
interao e na interface so avaliados por todos os mtodos de avaliao analisados.
A avaliao de IHC pode ser realizada em diferentes momentos no processo de design
e desenvolvimento. Podemos comparar os mtodos de avaliao em funo da
necessidade de existir uma soluo de IHC pronta e funcionando. A Tabela 10.9 compara
a aplicao formativa (durante o processo de design, antes de uma soluo concluda) e
somativa ou conclusiva (com uma soluo concluda) dos mtodos de avaliao
apresentados. Os mtodos classificados com ++ so empregados mais frequentemente
no tipo de avaliao referido. Entrevistas, questionrios, grupos de foco, avaliao
heurstica e de percurso cognitivo podem ser utilizados para avaliao formativa e
somativa com benefcios semelhantes. A inspeo semitica, o estudo de campo, o teste
de usabilidade e a avaliao de comunicabilidade so mais apropriados para avaliao
somativa, apesar de tambm poderem ser aplicados para certos tipos de avaliao
formativa. J a prototipao em papel mais apropriada para a avaliao formativa, por
explorar ideias em papel e no numa soluo de IHC executvel.

Tabela 10.9
Quando cada mtodo de avaliao costuma ser utilizado

Os mtodos de avaliao de IHC normalmente produzem em alguma medida tanto


resultados quantitativos quanto resultados qualitativos. Entretanto, cada mtodo
costuma privilegiar um desses dois tipos de resultados. A Tabela 10.10 sumariza os tipos
de dados produzidos pelos mtodos de avaliao apresentados. Desses mtodos,
questionrios e testes de usabilidade costumam fornecer mais resultados quantitativos
do que qualitativos. Os demais mtodos de avaliao costumam fornecer mais resultados
qualitativos. O avaliador deve escolher um mtodo de avaliao de IHC que fornea
resultados adequados ao objetivo da avaliao, sejam eles resultados quantitativos,
qualitativos, ou ambos. Por exemplo, se o avaliador estiver interessado em compreender
as causas dos problemas na interface, os mtodos que fornecem resultados qualitativos
tendem a oferecer explicaes melhores.

Tabela 10.10
Tipos de dados produzidos por mtodo de avaliao

Se houver pouco tempo disponvel para executar uma avaliao de IHC, interessante
optar por mtodos de avaliao por inspeo, pois eles costumam ser executados mais
rapidamente do que os mtodos que envolvem usurios. Entretanto, sempre que
possvel, devemos executar pelo menos uma avaliao emprica, pois atravs das sesses
de interao os usurios sempre revelam aspectos que os avaliadores no conseguiriam
prever. importante oferecermos e aproveitarmos a oportunidade para usurios
contriburem diretamente com o julgamento de valor do sistema.
Idealmente, a avaliao de IHC deveria ser realizada ao longo de todo o processo de
design e de desenvolvimento. Dessa forma, seria possvel avaliar e corrigir a soluo de
IHC conforme ela vai sendo concebida, construda e mantida. Como cada mtodo de
avaliao possui caractersticas prprias, a execuo de mtodos de avaliao de IHC
complementares uma prtica promissora para o desenvolvimento de sistemas
interativos. Desse modo, os resultados da avaliao seriam mais ricos, o reprojeto da
soluo de IHC seria mais bem informado e, assim, haveria melhores condies de
aumentar a qualidade de uso do sistema.
Atividades
1. Comparao de Mtodos de Avaliao de IHC por Inspeo. Escolha um software de sua
preferncia e realize avaliaes de IHC utilizando mtodos de inspeo distintos: uma
avaliao heurstica, uma avaliao por percurso cognitivo e uma avaliao por
inspeo semitica. Compare o trabalho necessrio para execut-las (pessoas
envolvidas, tempo de execuo, material necessrio etc.) e os resultados obtidos (que
tipos de concluses possvel tirar com cada avaliao, qual a relao dessas
concluses com o tipo de avaliao etc.).
2. Comparao de Mtodos de Avaliao de IHC por Observao. Escolha um software de sua
preferncia e realize avaliaes de IHC utilizando mtodos de observao distintos:
testes de usabilidade, avaliao de comunicabilidade e prototipao em papel.
Compare o trabalho necessrio para execut-las (pessoas envolvidas, tempo de
execuo, material necessrio etc.) e os resultados obtidos (que tipos de concluses
possvel tirar com cada avaliao, qual a relao dessas concluses com o tipo de
avaliao etc.).
3. Comparao de Mtodos de Avaliao de IHC Pautados na Engenharia Semitica. Escolha
um software de sua preferncia e realize avaliaes de IHC utilizando os mtodos de
inspeo semitica e de avaliao de comunicabilidade. Compare as metamensagens
reconstrudas pela avaliao e analise as concluses sobre a emisso e a recepo da
metacomunicao.
3
http://www.id-book.com/casestudy_14-1_2.htm.
Referncias Bibliogrficas
1. ACM, The ACM Code of Ethics and Professional Conduct. Disponvel em
http://www.acm.org/about/code-of-ethics, 1992.1.
2. Alexander C. The Timeless Way of Building. Oxford University Press 1979.
3. Annett J, Duncan KD. Task analysis and training design. Occupational Psychology.
1967;41:211221.
4. Annett J. Hierarchical Task Analysis. In: Diaper D, Stanton N, eds. Mahwah, NJ:
Lawrence Erlbaum Associates; 2003;6782. The handbook of task analysis for human-
computer interaction.
5. Armitage J. Are agile methods good for design?. Interactions. 2004;11(1):1423.
6. Aureliano VCO. eXtreme communication-centered design: um processo gil para o projeto da
interao humano-computador. Dissertao de Mestrado, Departamento de Informtica
Rio de Janeiro, Brasil: PUC-Rio; 2007.
7. Avizienis A, Laprie J-C, Randell B, Landwehr C. Basic Concepts and Taxonomy of
Dependable and Secure Computing. In: Los Alamitos, CA: IEEE Computer Society;
2004;1133. IEEE Transactions on Dependable and Secure Computing. 1(1).
8. Barbosa SDJ, Paula MG. Designing and Evaluating Interaction as Conversation: a
Modeling Language based on Semiotic Engineering. In: Jorge J, Nunes NJ, Falco e
Cunha J, eds. 2003;1633. Interactive Systems Design, Specification, and Verification 10th
International Workshop, DSV-IS 2003. 2844 Funchal, Ilha da Madeira, Portugal, Lecture
Notes in Computer Science.
9. Barbosa SDJ, Silveira MS, Paula MG, Breitman K. Supporting a Shared
Understanding of Communication-Oriented Concerns in Human-Computer
Interaction: a Lexicon-based Approach. In: 2004;271288. Proceedings of EHCI-
DSVIS04: The 9th IFIP Working Conference on Engineering for Human-Computer
Interaction and the 11th International Workshop on Design, Specification and Verification of
Interactive Systems.
10. Beck K. eXtreme Programming Explained: Embrace Change. Reading, MA: Addison-
Wesley; 2000.
11. Bertelsen OW, Bdker S. Activity Theory. In: Carroll JM, ed. San Francisco, CA:
Morgan Kaufmann; 2003;291324. HCI Models, Theories, and Frameworks: Toward a
Multidisciplinary Science.
12. Bevan N. Extending Quality in Use to Provide a Framework for Usability
Measurement. Human-Computer Interaction. 2009;10:1322.
13. Beyer H, Holtzblatt K. Contextual Design: Defining Customer-Centered Systems. San
Francisco, CA: Morgan Kaufmann; 1998.
14. Bias R, Mayhew D. Cost-Justifying Usability. San Francisco, CA: Morgan Kaufmann
Publishers; 2005.
15. Blomkvist S. Towards a Model for Bridging Agile Development and User-Centered
Design. In: Seffah A, Gulliksen J, Desmarais MC, eds. Springer 2005;219244.
Human-Centered Software Engineering: Integrating Usability in the Software Development