JAI2007 PratesBarbosa EngSem PDF

Captulo
6

Introduo Teoria e Prtica da Interao
Humano Computador fundamentada na
Engenharia Semitica
Raquel Oliveira Prates
1
, Simone Diniz J unqueira Barbosa
2

Abstract
The goal of this chapter is to briefly introduce the area of Human-Computer Interaction
(HCI) and to describe Semiotic Engineering, a theory of HCI that presents a broader
account to the activities involved in the conception, modeling and evaluation of
interactive systems, and also instruments these activities with methods grounded in the
theory. Semiotic Engineering was developed in Brazil in the 90s and is currently an
internationally known theory. In 2006, the Brazilian HCI community recommended that
Semiotic Engineering be included in the syllabus of undergraduate and graduate HCI
courses.
Resumo
O objetivo deste captulo introduzir brevemente a rea de interao humano-compu-
tador (IHC) e se aprofundar na Engenharia Semitica, uma teoria de IHC que apre-
senta uma caracterizao mais ampla das atividades envolvidas na concepo,
modelagem e avaliao de sistemas interativos, e instrumenta essas atividades com
mtodos ancorados na teoria. A Engenharia Semitica foi desenvolvida no Brasil nos
anos 90 e atualmente uma teoria reconhecida internacionalmente. Em 2006, a sua
incluso na ementa de disciplinas de IHC passou a ser recomendada pela comunidade
brasileira de IHC.

1
Departamento de Cincia da Computao, UFMG.
2
Departamento de Informtica, PUC-Rio.
Prates, R. O. & Barbosa, S.D.J. Introduo Teoria e Prtica da Interao Humano-Computador fundamentada na
Engenharia Semitica. In T. Kowaltowski & K. Breitman (orgs.) Jornadas de Atualizao em Informtica, JAI 2007, pp. 263-326.

6.1. Introduo
A Cincia da Computao foi definida pelo comit de fundamentos da Cincia da Com-
putao do Conselho Nacional de Pesquisa dos Estados Unidos como sendo o estudo
de computadores e o que eles podem fazer as capacidades e limites inerentes a com-
putadores abstratos, o design e caractersticas de computadores reais, e as inmeras apli-
caes de computadores na resoluo de problemas
3
[CFCS 2004, p. 12]. Assim o
comit descreve a sua rea de atuao como indo desde pesquisa sobre propriedades de
dispositivos eletrnicos at caractersticas relacionadas compreenso humana, abor-
dando tanto aspectos tericos, quanto pragmticos desta ampla gama de questes. Den-
tre as diversas especialidades que constituem a Cincia da Computao podemos des-
crever a rea de Interao Humano-Computador (IHC) como sendo aquela que
considera todos os aspectos relacionados com a interao entre pessoas e computadores
[Preece et al. 1994].
Por vrias dcadas depois de criados os primeiros computadores, era necessrio
que o usurio entendesse a fundo como a mquina funcionava para poder lhe dizer o
que fazer. Porm, na dcada de 70, observou-se um rpido crescimento e barateamento
da tecnologia, que possibilitaram a criao dos computadores pessoais, seguida de uma
popularizao do seu uso por pessoas leigas em computao [Dourish 2001]. Ao mesmo
tempo, vrias universidades e centros de pesquisa comearam a investir em pesquisas e
desenvolvimento de sistemas que pudessem ser utilizados por usurios no es-
pecializados e lhes fossem teis [Preece et al. 1994]. Assim criada na dcada de 80 a
rea de Interao Humano-Computador.
Em 1981, Moran definiu formalmente a interface de um sistema com o usurio
como sendo a parte de um sistema computacional com a qual a pessoa entra em
contato fsica, perceptiva ou conceitualmente [Moran 1981]. Em meados da dcada
de 80 foi ento cunhado o termo interao humano-computador (IHC)
4
para definir esta
nova rea de estudo, cujo foco era no apenas o projeto de interface, mas todos os
aspectos relacionados com a interao entre usurios e sistemas [Preece et al. 1994]. Por
envolver no apenas os computadores, mas tambm as pessoas que os utilizam, IHC
multidiscipilinar e se encontra na interseo das cincias da computao e informao e
cincias sociais e humanas. Em 1982 foi criado na ACM (Association of Computing
Machinery) o grupo de interesse em IHC, o SIGCHI
5
(Special Interest Group in
Computer Human Interaction) [Borman 1996], que h vrios anos o 2
o
maior grupo de
interesse da ACM [Konstan 2007]. No Brasil, os primeiros trabalhos na rea de IHC
surgiram ainda na dcada de 80. No entanto, a comunidade de IHC s se organizou no
final da dcada de 90. Em 1997, foi criada uma lista de interesse em IHC e uma pgina
contendo as informaes de contato das pessoas trabalhando na rea. Nesta poca foi

3
Traduo livre das autoras do original: Computer science is the study of computers and what they can
do the inherent powers and limitations of abstract computers, the design and characteristics of real
computers, and the innumerable applications of computers to solving problems.
4
Foi definido na comunidade internacional o termo Human-Computer Interaction, e seu acrnimo HCI.
Apenas em 1998 foi que a comunidade brasileira de IHC definiu formalmente como deveria ser o termo
em portugus.
5
O SIGCHI atualmente o 2
o
maior grupo de interesse da ACM, ficando atrs apenas do SIGGRAPH
(grupo de interesse em Computao Grfica) [Konstan 2007].

criado um potencial grupo local de interesse em IHC associado ao SIGCHI
(Prospective Local Chapter, o BRCHI). Em 1998, foi organizado o primeiro Workshop
de Fatores Humanos em Computao Grfica, junto ao SBES em Maring, PR, o IHC
1998.
Em 2000, o BRCHI se tornou um grupo consolidado junto ACM/SIGCHI e em 2002
foi criada a Comisso Especial de IHC (CEIHC) junto SBC. O evento da comunidade,
IHC, foi organizado anualmente e se tornou um Simpsio em 2002. Neste mesmo ano, a
comunidade se decidiu por tornar o evento bianual, e revez-lo com a Conferncia La-
tino-Americana de IHC (CLIHC), que teve sua primeira edio em 2003 no Rio de J a-
neiro. A comunidade de IHC atualmente est bem consolidada no Brasil, e a rea de
IHC tem se firmado no Brasil no desenvolvimento de pesquisas de qualidade, na forma-
o de profissionais de computao, sendo oferecida nos cursos de Cincia da Compu-
tao, Engenharia de Computao e Sistema de Informao como disciplina optativa ou
obrigatria, e tambm na indstria, com o crescimento da preocupao com a qualidade
do sistema para o usurio [Silveira 2007].
6.1.1. Interao e Qualidade de Uso
A interface a parte do sistema computacional com a qual o usurio se comunica, ou
seja, aquela com a qual ele entra em contato para disparar as aes desejadas do sistema
e receber os resultados destas aes, que o usurio ento interpreta para em seguida
definir sua prximas aes. A este processo de comunicao entre usurio e sistema se
d o nome interao [Preece et al. 1994]. Ver Figura 1.

Figura 1. Interao entre usurio e sistema
O usurio interage com o sistema atravs do software (e.g. janelas de dilogo e linha de
comando) e do hardware (e.g. teclado, mouse, monitor). Durante a interao, o usurio
entra em contato com o sistema fisicamente (ao manipular dispositivos de hardware),
perceptivamente (ao perceber o que lhe apresentado pela interface), e conceitualmente
(ao interpretar e raciocinar sobre a interao e seus resultados) [Moran 1981].
Ao projetar um sistema interativo, uma das preocupaes do designer deve ser
com a qualidade de uso associada interao do usurio com a interface. A usabilidade
de um sistema foi a primeira propriedade definida relativa a esta qualidade, na dcada
de 80, e leva em considerao a facilidade e eficincia com a qual um usurio consegue

utilizar um sistema [Gould & Lewis 1985]. A usabilidade atualmente a qualidade de
uso mais amplamente difundida e utilizada tanto por pesquisadores, quanto
profissionais da rea. Para se avaliar a usabilidade de um sistema deve-se levar em
conta os seguintes fatores [Nielsen 1993, Preece et al. 2002]:
facilidade de aprendizado: se refere ao tempo e esforo necessrios para que os
usurios aprendam a utilizar uma determinada poro do sistema com determinado
nvel de competncia e desempenho.
facilidade de uso: est relacionado no apenas com o esforo cognitivo para intera-
gir com o sistema, mas tambm com a facilidade de completar a interao sem co-
meter erros durante este processo.
eficincia de uso e produtividade: analisa se o sistema consegue fazer bem aquilo
a que se destina, e se o usurio completa suas tarefas de forma rpida e eficaz.
satisfao do usurio: enfatiza a avaliao subjetiva do sistema feita pelo usurio,
incluindo suas preferncias pessoais e emoes (positivas ou negativas) que possam
surgir durante a interao.
flexibilidade: considera o quanto um sistema capaz de acomodar caminhos distin-
tos para se atingir um mesmo objetivo, apoiando assim as preferncias e modo de
trabalho individuais dos usurios.
utilidade: relativo ao conjunto de funcionalidades oferecidas ao sistema para que os
usurios realizem suas tarefas.
segurana no uso: se refere ao grau de proteo de um sistema contra condies
desfavorveis ou at mesmo perigosas para os usurios, envolvendo desde aspectos
de recuperao de condies de erro at impacto no seu trabalho ou sade.
A usabilidade foi proposta com base no conhecimento emprico relativo ao uso de siste-
mas interativos. medida que a comunidade de IHC se consolidou e a pesquisa e apli-
cao de mtodos avanaram, surgiram novas abordagens e teorias para dar conta dos
processos de design e interao [Carroll 2003]. Com elas surgiram tambm novas pro-
priedades relevantes relativas qualidade de uso.
A teoria da Engenharia Semitica, como veremos na prxima seo, se
concentra na comunicao entre o designer e usurio sendo feita atravs da interface de
um sistema [de Souza 2005]. Assim, para poder avaliar a qualidade de uso da interao,
a Engenharia Semitica define a propriedade de comunicabilidade. A
comunicabilidade de um sistema se refere capacidade de o projetista conseguir
transmitir aos usurios, atravs da interface, o design tal como concebido por ele [Prates
et al. 2000]. Em outras palavras, se ao utilizar o sistema os usurios conseguem
entender, atravs da interface, para que o sistema serve, a quem ele se destina, quais as
vantagens de utiliz-lo, como ele funciona e quais so os princpios gerais que definem
as possibilidades de interao com ele.
Alm das propriedades que surgem com as novas teorias, o crescente avano da
tecnologia e de sua adoo no cotidiano das pessoas tambm requer que novas proprie-
dades sejam consideradas. Por exemplo, em sistemas de apoio ao aprendizado o mais
importante saber se o aluno, usurio do sistema, consegue de fato utiliz-lo para
aprender; ou em jogos o relevante a sua propriedade de entreter e divertir os usurios;

ou ainda em uma comunidade online a prioridade sua capacidade de apoiar s relaes
sociais entre seus membros. Dentre tantas propriedades que esto sendo consideradas
atualmente, a acessibilidade merece um destaque especial. A propriedade de acessibili-
dade est relacionada com a capacidade que o sistema tem de permitir que pessoas com
deficincias
6
possam perceber e entender o sistema, e utiliz-lo [Decreto-Lei 5296,
W3C/WAI]. Vrios pases, dentre eles o Brasil, atualmente tm leis que exigem que os
sistemas Web de administrao pblica disponibilizados aos cidados sejam acessveis
[Decreto-Lei 5296]. Relacionado acessibilidade tem-se tambm o conceito de usabili-
dade universal que prope que os sistemas devem poder ser utilizados em uma ampla
diversidade de usurios (incluindo aqueles que tm deficincia), tecnologias (e.g dife-
rentes equipamentos novos ou obsoletos e sistemas operacionais) e ambientes fsicos
(e.g. disposio dos mveis em uma sala) [Shneiderman & Plaisant 2005, Vanderheiden
2000].
6.2. Teoria da Engenharia Semitica
A teoria da Engenharia Semitica (EngSem) [de Souza 2005] uma teoria explicativa
de IHC, ou seja, uma teoria que nos permite entender os fenmenos envolvidos no
design, uso e avaliao de um sistema interativo. Como tal, ela tem por objetivo
esclarecer a natureza e aspectos envolvidos nestas atividades. A anlise fundamentada
na teoria enriquece o entendimento que os designers tm do problema que esto
tentando resolver com o sistema, e assim amplia as suas consideraes em relao a
possveis solues. No objetivo desta teoria prever os resultados de uma ao ou
levar o designer a buscar a soluo correta para o problema em questo.
O primeiro aspecto relevante para o qual a EngSem chama a ateno que um
software um artefato intelectual. Mas o que um artefato intelectual? Todos os
artefatos gerados por humanos so de fato produto de sua criatividade e exerccio
intelectual. No entanto, de Souza (2005) define como um artefato intelectual o produto
gerado a partir da interpretao de um projetista sobre um problema e sua concepo de
soluo, que ento apresentada em uma codificao lingstica. Para um artefato ser
considerado intelectual ele deve ter as seguintes caractersticas:
Codificar uma determinada interpretao de uma situao;
Codificar um conjunto de solues para a situao em questo;
A codificao da situao e das suas solues lingstica, ou seja, baseada em um
sistema de smbolos que possa ser interpretado por regras semnticas consistentes;
O objetivo do artefato s pode ser alcanado se os usurios podem formul-lo no
sistema lingstico no qual o artefato foi codificado. Em outras palavras, os usurios
devem ser capazes de entender o sistema e usar a codificao utilizada para explorar
os efeitos das solues disponibilizadas atravs do artefato.
Considerando esta definio, uma cadeira e um bule no so artefatos intelectuais, uma
vez que no possuem uma codificao lingstica associada. Por outro lado, uma tabela
peridica um artefato intelectual, pois podemos pensar nela como uma soluo pro-

6
Deficincia se refere a deficincias motoras, perceptivas ou neurolgicas, permanentes ou temporrias
(W3C/WAI).

posta para se entender a relao entre os diversos elementos qumicos existentes, e se
obter rapidamente algumas de suas caractersticas bsicas. A codificao lingstica
apresentada envolve a posio dos elementos na tabela e dentro de cada clula. Esta
codificao deve ser entendida pelo usurio para se conseguir utilizar a tabela peridica.
Assim, a EngSem caracteriza um sistema interativo como um artefato
intelectual. Neste caso, algumas particularidades devem ser levadas em considerao no
seu projeto: (1) o artefato deve ser descrito em alguma linguagem artificial que seja
processada por um computador; (2) a linguagem de interface com a qual o usurio vai
interagir sempre nica e, logo, nova para o usurio; (3) o artefato se caracteriza como
sendo de meta-comunicao.
Um artefato de meta-comunicao aquele cuja mensagem relativa prpria
comunicao. Assim, na viso da EngSem, a interface de um sistema entendida como
um caso de meta-comunicao, uma vez que comunica ao usurio a viso do projetista
sobre a quem ela se destina; que problemas ela pode resolver; e como interagir com ela,
ou seja, como trocar mensagens com o sistema atravs da sua linguagem de interface
para conseguir executar as tarefas desejadas. Em outras palavras, a interface de um
sistema uma mensagem do designer para o usurio cujo contedo [de Souza 95:84]:
Esta a minha interpretao sobre quem voc , o que eu entendi que voc quer ou
precisa fazer, de que formas prefere faz-lo e por qu. Eis, portanto, o sistema que
conseqentemente concebi para voc, o qual voc pode ou deve usar assim, a fim de
realizar uma srie de objetivos associados com esta (minha) viso.
Esta mensagem sendo transmitida pela interface indireta, pois o usurio deve compre-
end-la medida que interage com o sistema. A prpria interface quem comunica a
viso do projetista, assumindo ento um papel de seu representante ou preposto. Alm
disso, a mensagem unidirecional, pois o usurio no contexto de interao no pode dar
continuidade quela comunicao com o projetista.
Para ilustrar o conceito de meta-comunicao, vamos utilizar o sistema chamado
Student Life [Tesoro], que se prope a auxiliar o aluno na organizao de suas ativida-
des escolares e at mesmo aspectos de sua vida social. O aluno ao visitar o site do sis-
tema para baix-lo receber esta informao publicada pelo designer do Student Life
para todos os potenciais interessados. Ao instalar o sistema e iniciar seu uso, o aluno
inicia a sua interao com a interface proposta pelo designer para cumprir este objetivo.
A Figura 2 mostra a tela inicial do Student Life com a qual o aluno interage.
Imaginemos a primeira interao de um estudante brasileiro com o Student Life:
Quando a tela inicial aberta (Figura 2), o aluno imediatamente percebe as opes (1) e
(2) e entende que, para poder selecionar uma disciplina, ele deve primeiro inseri-la.
Vendo as informaes disponveis na aba (3), ele percebe que so as informaes relati-
vas a uma disciplina. Ele ento imagina se pode incluir a informao sobre a disciplina
diretamente nesta aba. No entanto, ao passar o mouse sobre ela, percebe que ela no
est habilitada para edio e conclui que o caminho para incluir uma disciplina deve ser
clicando sobre o boto Add Class (2). Ao ver as opes disponveis do lado direito, o
aluno percebe que antes de incluir uma disciplina no pode dizer nada ao sistema sobre
seus trabalhos ou provas (4). No entanto as outras opes no so dependentes de uma
disciplina. Ele ento percebe o boto My Life (5) e fica curioso tentando imaginar que
aspectos de sua vida esta opo lhe permite organizar. Finalmente, os 3 ltimos botes
(6), mais o fato de a interface estar em ingls lhe levam a crer que o sistema foi feito

para um estudante americano. Ainda assim, pode ser que lhe seja til, ele ento continua
a sua interao com o sistema para melhor entend-lo.

Figura 2. Tela inicial do Student Life
medida que o aluno interage com o sistema, ele vai entendendo para que serve o sis-
tema, a quem ele se destina, como utiliz-lo e que vantagens ter no uso deste sistema.
Em outras palavras, ele vai entendendo a soluo proposta pelo designer, ou seja, a
meta-mensagem sendo enviada a ele pela interface. Para o Student Life, a meta-mensa-
gem do designer para o usurio seria algo como:
Caro estudante, eu entendo que voc pode ficar sobrecarregado com suas atividades
acadmicas. Assim, estou lhe propondo uma forma de manter suas atividades e prazos
organizados. Voc registra as informaes relativas s disciplinas e seus prazos, e o
sistema lhe mostra seus horrios e agendamentos do dia ou do ms. Para as disciplinas
e trabalhos, voc pode cadastrar seus contatos, possibilitando um acesso rpido s
suas informaes. Alm disso, voc pode solicitar que lembretes dos prazos mais
importantes lhe sejam enviados com antecedncia. Como voc tambm tem uma vida
social, voc pode incluir aqui tambm seus compromissos e contatos pessoais. Este
sistema foi feito principalmente para alunos cursando o sistema universitrio
americano e o ingls nossa lngua comum de comunicao. De todo jeito, ele pode ser
til tambm para alunos em outros pases que entendam ingls.
A EngSem fundamentada na Semitica, uma disciplina que estuda fenmenos de
significao e comunicao. Um dos principais conceitos na semitica o conceito de
signo. Um signo tudo aquilo que significa algo para algum [Houser & Kloesel (1992-
1998)], assim um signo relaciona uma representao, denominada representamen (e.g.
a palavra carro, ou a foto de um carro, ou o som de um carro passando), a um referente
(o veculo) e a uma idia criada na mente da pessoa ao perceber a representao (e.g. o
carro desta pessoa, ou o seu primeiro carro, ou mesmo o filme Carros exibido nos cine-
mas), qual se d o nome de interpretante.
Na Figura 3 podemos ver que a mensagem transmitida pelo emissor contm o
signo carro, gerando um interpretante na mente do seu receptor. Atravs de um processo
de associao de idias, cada interpretante pode gerar novos interpretantes, e a este pro-

cesso d-se o nome de semiose ilimitada [Eco 1976]. A Semitica considera este fe-
nmeno ilimitado, pois teoricamente o receptor da mensagem pode gerar tantos inter-
pretantes quanto queira, no sendo possvel definir quando ou se este processo termina.
No entanto, na prtica este processo normalmente interrompido pelo receptor, seja
quando ele se d por satisfeito com o interpretante gerado, seja por falta de recursos
como por exemplo tempo ou pacincia. Por exemplo, na Figura 3 quando o emissor
comentou sobre seu prprio carro, o receptor se lembrou do seu carro, e ento do
carrinho de brinquedo que prometera a seu filho e em seguida do seu aniversrio. O
receptor poderia continuar gerando associaes, ou seja, em semiose ilimitada, ou
interromper esta semiose, por exemplo por se dar conta que deveria levar o carrinho
para o filho neste mesmo dia, saindo ento para compr-lo.

Figura 3. Semiose ilimitada
Em uma interface, os signos so os elementos da interface. No exemplo mostrado na
Figura 2, o boto Add Class um signo, assim como o texto Selected Year. Os interpre-
tantes gerados na mente do usurio so justamente os pensamentos narrados no exemplo
que surgem a partir da interao.
Entendidos estes conceitos bsicos, entendamos o foco da Semitica: significa-
o e comunicao. Significao o processo atravs do qual expresso e contedo de
signos so estabelecidos com base em convenes sociais e culturais conhecidas das
pessoas que vo utiliz-los, produzindo e interpretando signos. A esta codificao entre
expresso e contedo se d o nome de sistemas de significao [Eco 1976]. Note-se
que em IHC esta codificao pode ser feita artificialmente na definio da linguagem de
interface. Por exemplo pense-se na linguagem padro do sistema operacional Windows
e nas aplicaes que a utilizam, que normalmente associam o elemento ao de
fechar uma janela ou de desfazer. Estas associaes no surgiram de processos
culturais ou sociais, mas foram criadas em um determinado momento pelos designers do
Windows. Comunicao o processo atravs do qual pessoas produzem mensagens
formadas por signos utilizando um ou mais sistemas de significao com o intuito de
expressar determinados contedos. Vale ressaltar que uma parte importante da

comunicao consiste em no apenas se apropriar desses signos e sistemas de
significao, mas tambm em se fazer um uso criativo deles, subvertendo o que estava
prescrito pelos sistemas de significao ou ainda inventando novos signos. A mensagem
criada enviada atravs de um canal, para outro interlocutor o receptor, que deve
ento ser capaz de interpret-la.
Sendo o processo de design de uma interface um ato comunicativo, ele requer
que o designer entenda o problema, avalie as oportunidades de soluo, e tome decises
sobre esta soluo. Estas decises incluem desde aspectos relativos a que pontos do pro-
blema sero endereados, at a definio dos signos e sistemas de significao que
comporo a interface e que permitiro a interao usurio-sistema e, logo, a transmisso
da meta-mensagem do designer ao usurio. Este processo de design na EngSem visto
sob a perspectiva de reflexo durante a ao (reflection-in-action) [Schn 1983], na
qual cada problema visto como sendo um problema nico e mutvel. nico porque
cada problema caracterizado por elementos do seu contexto que definem o problema.
Mutvel porque, no apenas no existe uma nica soluo correta, mas tambm
porque o entendimento do problema pode evoluir medida que o projetista (e usurios)
pensam mais sobre ele e exploram diferentes caminhos de soluo. Para a rea de IHC,
Schn prope que a reflexo dos projetistas seja guiada pela questo de qual artefato
eles pretendem criar e como o tornar usvel [Schn e Bennett 1996]. Na perspectiva da
reflexo durante a ao, prope-se munir o projetista de ferramentas epistmicas, ou
seja, ferramentas que o permitam levantar hipteses sobre o problema, experimentar
diferentes possibilidades de soluo e avaliar os resultados. Na EngSem, o papel destas
ferramentas epistmicas permitir ao projetista da interao refletir sobre questes
relacionadas ao artefato de meta-comunicao e comparar diferentes solues.
6.3. Avaliao da Propriedade de Comunicabilidade
Na perspectiva de meta-comunicao da EngSem, a qualidade de uso de uma interface
dada pela sua comunicabilidade. Como vimos na subseo 1.1.1, a comunicabilidade
definida como a propriedade de um sistema transmitir ao usurio de forma eficaz e
eficiente as intenes e princpios de interao que guiaram o seu design [Prates et al.
2000]. Quando o usurio no capaz de entender a comunicao pretendida pelo
designer, ocorrem ento rupturas de comunicao que podem dificultar ou at mesmo
impossibilitar a meta-comunicao ou uso do sistema. A Figura 4 mostra a tela do
sistema Student Life que permite ao aluno incluir uma disciplina no sistema, e algumas
potenciais rupturas que podem surgir na comunicao usurio-sistema.
Ao clicar na tela principal (Figura 2) no boto Add Class, aberta para o aluno
esta tela. O aluno ento comea a criar o cadastro de sua disciplina. Em (1) o aluno v
uma lista vazia de cursos que deveria permitir a ele dizer a qual curso est associada a
disciplina. No entanto, no h na tela nenhuma indicao de como inserir os cursos. O
texto no pode ser clicado, e mesmo o boto da direita clicado sobre a lista no oferece
nenhuma opo. Desta forma, o aluno vivencia sua primeira ruptura, sem saber exata-
mente como incluir o curso em que est matriculado para o qual a disciplina conta. Em
seguida, em (2) o aluno deve dizer a que ano do curso a disciplina est associada. O
sistema apresenta para ele 12 anos como opo, o que ele no entende, j que no con-
segue imaginar cursos que chegariam a 12 anos de durao. Ele procura alguma
explicao, mas no encontra nem mesmo no guia do usurio, ento ele imagina que

talvez seja uma particularidade do ensino superior nos EUA. Como o seu curso tem
durao de 4 anos, ele desiste de entender a que se referem os 12 anos e marca o ano
que faz sentido para ele. O aluno segue ento e preenche o nome da disciplina, seu
cdigo, e os dias e horrios em que ministrada (3). O aluno ento tenta salvar a
disciplina, e qual no sua surpresa quando v que o boto para salvar est desabilitado
(4). Ele tenta entender por qu e v no canto inferior direito um texto informando que os
campos marcados com asterisco (*) so obrigatrios (5). Ele ento verifica os campos
marcados com * e acredita que tenha preenchido todos, e fica ento sem saber o que
fazer para habilitar o boto. Depois de muito tentar o aluno seleciona o boto Cancel, e
comea tudo novamente. Na 2
a
tentativa ele percebe que, ao preencher o horrio da
disciplina (3), ele no havia clicado no boto Set, para que o horrio fosse confirmado
para os dias selecionados, e por isso o boto para gravar no tinha sido habilitado na 1.
tentativa.

Figura 4. Student Life - Tela para Insero de Disciplina, com potenciais rupturas de
comunicao
Vale ressaltar que cada momento descrito que o aluno no entende a mensagem do de-
signer representa uma ruptura na comunicao designer-usurio. Quanto mais rupturas,
ou quanto mais severas as rupturas, mais baixa a comunicabilidade da interface. Atual-
mente, existem dois mtodos para se avaliar a comunicabilidade de uma interface: o
Mtodo de Inspeo Semitica e o Mtodo de Avaliao de Comunicabilidade. O M-
todo de Inspeo Semitica (MIS) um mtodo antecipativo, ou seja, mtodo em que
um especialista percorre a interface e identifica (i.e. antecipa) potenciais rupturas de
comunicao que poderiam surgir na interao usurio-sistema. O Mtodo de
Avaliao de Comunicabilidade (MAC) um mtodo que envolve a observao de

usurios em um ambiente controlado (e.g. um laboratrio de testes) por um especialista.
O especialista analisa a interao do usurio com o sistema, identificando ento as
rupturas vivenciadas pelos usurios. Os dois mtodos so qualitativos, ou seja, eles tm
como resultado indicadores (problemas identificados) sobre a qualidade da meta-
mensagem sendo enviada do designer para o usurio a interface
7
. Outra caracterstica
de mtodos qualitativos que os resultados dependem diretamente da interpretao, e
logo da experincia, cultura e valores, dos avaliadores aplicando os mtodos. A seguir
apresentamos em detalhes cada um destes mtodos.
6.3.1. MIS O Mtodo de Inspeo Semitica
No MIS, o avaliador examina a meta-comunicao do designer para o usurio com o
objetivo de identificar se existem rupturas de comunicao e gerar a reconstruo desta
mensagem [de Souza et al. 2006]. Como vimos na seo 1.2, esta mensagem formada
por signos de um ou mais sistemas de significao
8
. Logo, para inspecionar a meta-
mensagem, o avaliador examina os signos utilizados pelo designer na sua comunicao
em 3 diferentes nveis. Para isso a EngSem identifica trs nveis de signos: os de meta-
comunicao, os estticos e os dinmicos.
Os signos de meta-comunicao so aqueles que esto presentes na documen-
tao online (e.g. sistema de ajuda, website) ou offline (e.g. manuais de usurio, mate-
rial impresso de divulgao). Por exemplo, entrando no manual do usurio tem-se a se-
guinte informao disponvel para o usurio
9
(ver Figura 5).

Figura 5. Trecho do Guia do Usurio do Student Life
Observe que neste trecho o designer comunica diretamente ao usurio sobre o Student
Life e apresenta alguns aspectos relevantes sobre a sua soluo: ela voltada para alu-
nos universitrios, ela permite mais do que gerenciar atividades relacionadas aos cursos
sendo feitos, mas tambm da vida social e contatos. O fato de aparecerem as siglas
GPA/QPA, sem maiores explicaes, indica a expectativa do designer que o aluno-
usurio saiba o que significam, e logo o aluno considerado o americano.

7
Mtodos qualitativos se opem a mtodos quantitativos que tm por objetivo gerar dados numricos a
partir de mtricas e medidas.
8
Por exemplo, palavras e imagens normalmente pertencem a sistemas de significao que vm da cultura
fora do contexto especfico da interao humano-computador, enquanto apontadores de mouse e janelas
de dilogo pertencem a um contexto de significao nativo a aplicaes computacionais.
9
Traduo livre das autoras do texto da Introduo: Bem-vindo ao Student Life 3.0! Uma agenda pessoal
projetada com o aluno universitrio em mente. Organize tudo, de informaes relacionadas s suas
disciplinas, a suas listas de contato e sua vida social. Gerencie seu(s) curso(s) e GPA/QPA e crie
lembretes para praticamente tudo tambm!


Signos estticos so aqueles que expressam o estado do sistema. Estes signos
normalmente podem ser captados apenas olhando-se para a interface ou mesmo uma
imagem desta. Por exemplo, na Figura 6(a) a lista (Select Class) mostra o nmero e
nome das disciplinas (at 8) cadastradas. Alm disso, o boto Add Class habilitado in-
dica que o usurio pode incluir uma disciplina neste momento, mas ele no pode editar
ou remover uma disciplina (botes Edit Class e Delete Class desabilitados).

Figura 6. Parte da tela inicial do Student Life. (a) Antes de selecionar disciplina; (b)
Depois de selecionar disciplina disponvel
Finalmente, signos dinmicos expressam o comportamento do sistema, e s podem ser
percebidos quando o usurio interage com o sistema. Por exemplo, ao se selecionar a
disciplina de IHC, os botes para editar e remover a disciplina (botes Edit Class e De-
lete Class) se tornam habilitados (ver Figura 6(b)). Este comportamento um signo
dinmico da interface do Student Life.
Para inspecionar a interface, o Mtodo de Inspeo Semitica (MIS) prope 5
passos a serem seguidos pelo avaliador:
Passo 1: Inspeo dos signos de meta-comunicao presentes na documentao e
sistema de ajuda: O principal objetivo neste passo a reconstruo da meta-mensagem
do designer. Para auxiliar nesta etapa o avaliador pode utilizar a parfrase da meta-men-
sagem do designer como template a ser preenchido:
No trecho que examinamos do guia do usurio do Student Life, coletamos informao
sobre o quem voc , que seria um estudante universitrio americano. Observe que
enquanto estudante universitrio est explcito no texto do guia, americano fica
apenas implcito a partir do conhecimento esperado que o usurio compartilhe com o
designer (e.g. GPA/QPA). Da mesma forma, o que voc quer ou precisa fazer ex-
plicitado no uso do sistema para organizao das tarefas associadas ao(s) curso(s) e
tambm aspectos da vida social do estudante. Ao ler o guia de usurio e se deparar com
o trecho A maior parte das funes do Student Life pode ser usada de imediato, sem

que seja necessrio uma configurao prvia o avaliador poderia entender que o desig-
ner tambm considera que o estudante gostaria de fazer isso sem muito trabalho extra.
Alm disso, toda a parte que explica como fazer cada coisa utilizando o sistema, assim
como a definio do estilo de interao selecionado (e.g. manipulao direta x linha de
comando), est associada com a expectativa do designer sobre o seu entendimento em
relao s preferncias do usurio sobre a execuo. Finalmente, o porqu de o usurio
querer usar o sistema aparece na forma de benefcios que ele pode atingir (e.g. guia do
usurio: Gerencie seu curso(s) e GPA/QPA e crie lembretes para praticamente tudo
tambm!). Muitas vezes questes estratgicas relacionadas com o porqu de utilizar
um sistema, ou escolh-lo em detrimento de outro, aparecem apenas no website ou
documentos relacionados com a divulgao e/ou venda do produto (e.g. website do
Student Life: Obtenha melhores resultados a partir da sua experincia na universidade
atravs do aproveitamento do seu tempo
10
.). Vale ressaltar que nesta etapa a mensagem
pode ter vrios autores alm do designer do sistema, como por exemplo profissionais de
propaganda ou relaes pblicas. Esta perspectiva integrada interessante, j que o usu-
rio real normalmente recebe todas estas mensagens.
Passo 2: Inspeo dos signos estticos: Neste passo o avaliador inspeciona os signos
estticos da interface, e com base neles faz tambm a reconstruo da metacomunicao
designer-usurio, utilizando o mesmo template do passo 1. Note-se que esta meta-
mensagem reconstruda idealmente deveria complementar ou elaborar sobre aquela ob-
tida no passo 1. Por exemplo, ao observar os signos estticos na tela inicial do Student
Life (texto dos botes (6) e possibilidade de 12 anos (2)) (Figura 2), eles confirmam
para o avaliador a mensagem de que o foco o aluno universitrio americano. O avalia-
dor deve estar atento tambm para pontos onde os signos estticos esto inconsistentes
com a mensagem obtida pela inspeo dos signos de meta-comunicao. Estas incon-
sistncias devem ser registradas para elaborao sobre elas no Passo 4. Por exemplo, o
fato de a tela de calendrio no conter nenhum signo esttico que indique uma forma
rpida de navegar entre semanas ou meses (Figura 7), pode ser inconsistente com a
parte da meta-mensagem relacionada com facilidade de organizao e gerenciamento de
tarefas que permite ganhar tempo.

Figura 7 . Tela de Calendrio no apresenta signo esttico para navegao entre
semanas
Passo 3: Inspeo dos signos dinmicos: Neste passo, o objetivo do avaliador , no-
vamente, fazer a reconstruo da meta-mensagem usando mais uma vez o template uti-
lizado no passo 1, mas desta vez a partir da inspeo dos signos dinmicos da interface.

10
Traduo livre das autoras do original Get superior results from your college experience by making
the most out of your time.

Caso no processo ele identifique inconsistncias entre as meta-mensagens, deve
registr-las. Como vimos, os signos dinmicos representam o comportamento do
sistema, e logo tm um papel extremamente relevante na comunicao designer-usurio.
atravs deles que os usurios conseguem confirmar ou elucidar o significado
antecipado para os signos estticos. Por exemplo, o usurio imagina que o boto Add
Class lhe permitir cadastrar as informaes sobre uma disciplina. Ao clicar neste boto
e perceber que surge uma janela contendo as informaes sobre a disciplina a serem
preenchidas, ento o seu interpretante para aquele signo esttico ratificado. Um
exemplo de uma inconsistncia acontece ao se interagir com a tela de cadastro de
tarefas mostrada na Figura 8. Ao ver o signo esttico marcado para automaticamente
acrescentar um lembrete ao cadastro da tarefa (em destaque na Figura 8), o estudante
acredita que ao clicar no boto Add Homework lhe sero solicitadas informaes sobre
o lembrete. No entanto, isso no acontece e o usurio fica sem saber se o lembrete foi
criado ou no, e, se foi, para quando e com que texto. Assim, o signo dinmico no est
consistente com o interpretante gerado pelo esttico, e alm disso, ainda poderia estar
inconsistente com partes da mensagem transmitidas pelos signos de meta-comunicao
relacionados com facilidade de uso, e possibilidade de criar lembretes para tudo.

Figura 8. Tela de cadastro de tarefas
Passo 4: Contrastar e comparar as mensagens de meta-comunicao: Analisando os
diferentes tipos de signos nos passos 1, 2 e 3, observa-se que eles no tm o mesmo po-
der de expresso. Isto o esperado, j que eles pertencem a diferentes sistemas de signi-
ficao. Assim, enquanto signos meta-comunicativos podem ser expressos em lingua-
gem natural, os signos estticos se expressam atravs de elementos como cones, textos
e botes. Desta forma, no se poderia esperar que as meta-mensagens reconstrudas fos-
sem idnticas. No entanto, para a que a comunicao designer-usurio tenha sucesso,
necessrio que elas sejam consistentes. Neste passo, o avaliador analisa as inconsistn-
cias identificadas nos passos anteriores. Alm disso, ele deve intencionalmente procurar
rever as meta-mensagens buscando inconsistncias e ambigidades, e explorar a
possibilidade de o usurio atribuir significados contraditrios aos signos que constituem
as mensagens em cada um dos nveis. Para auxili-lo nesta tarefa, ele pode fazer uso das
seguintes perguntas:
1. plausvel que o usurio interprete este signo ou mensagem de forma diferente?
Como? Por qu?
2. Esta interpretao est consistente com a inteno de design?
3. A cadeia interpretativa me lembra outras cadeias interpretativas que gerei durante a
inspeo? Quais? Por qu?

4. As classes de signos estticos e dinmicos
11
podem ser identificadas pela anlise?
Quais?
5. Existem signos estticos ou dinmicos que esto na classe errada de acordo com as
classes propostas em 4? Isto pode afetar a comunicao com o sistema? Como?
Outras perguntas poderiam ser adicionadas a estas para auxiliarem o avaliador na identi-
ficao de inconsistncias. A interface de um sistema compe um sistema de significa-
o nico (composto pelos signos dos 3 nveis) projetado para transmitir suas qualida-
des e caractersticas nicas. Desta forma, consistncia e regularidade so fundamentais
para evocar padres ou significaes que sejam familiares aos usurios. Assim, vale
ressaltar que, em algumas situaes, ambigidades no necessariamente configuram um
problema, j que as pessoas tm costume em lidar com elas na linguagem natural.
Quando o sistema lida com a ambigidade de forma clara para o usurio, ento no
um problema, como por exemplo a funo Salvar que em vrios sistemas pode
funcionar como Salvar como... na 1
a
vez em que acionada.
Passo 5 Apreciando a qualidade da meta-comunicao: Este o ltimo passo do
mtodo, no qual o avaliador produz um relatrio contendo sua apreciao final resul-
tante de sua inspeo. O relatrio deve ser composto pelas seguintes partes:
1. Uma breve descrio do mtodo para auxiliar o leitor a entender a apreciao feita;
2. Os critrios utilizados para selecionar pores do sistema a serem inspecionadas
(quando a inspeo no examinar todo o sistema)
3. Para cada um dos nveis de signos inspecionados, descrever:
a. A identificao dos signos relevantes (listar e justificar sua relevncia)
b. A identificao das classes de signos utilizadas
c. Uma verso unificada da meta-comunicao designer-usurio
4. A apresentao e explicao sobre os problemas de comunicabilidade encontrados
que possam dificultar ou prevenir o usurio de entender a mensagem pretendida
pelo designer, e interagir produtivamente com o artefato.
A Figura 9 apresenta uma viso geral do Mtodo de Inspeo de Semitica apresentado.
Antes de aplicar o mtodo, algumas consideraes devem ser feitas pelo avaliador. Pri-
meiramente, como o MIS requer um exame detalhado da interface nos trs nveis de
signos, dependendo do tamanho do sistema ou do objetivo da avaliao pode no ser
vivel ou necessria a inspeo de todo o sistema. Neste caso, o avaliador (ou o desig-
ner) deve definir qual parte do sistema deve ser avaliada, por exemplo uma parte crtica
para o uso do sistema ou cuja meta-comunicao seja mais elaborada.
Em mtodos de inspeo, o avaliador fala em nome do usurio. Assim, podemos
associar o seu papel ao de um advogado que, conhecendo a viso do seu cliente e as
leis, fala por ele em processos jurdicos. O avaliador deve ento conhecer a viso do
usurio e ser especialista em EngSem para ento falar por ele, identificando os

11
As classes de signos se referem aos tipos de signos usados em cada nvel. Por exemplo, as classes de
signos estticos poderiam constar de elementos como botes, menus e apontadores; enquanto as de signos
dinmicos referenciam tipos de comportamento, como abrir uma janela ou disparar a execuo de um
applet.

problemas de comunicabilidade que ele poderia vivenciar durante a interao. Para isso,
o avaliador deve adotar uma perspectiva nica para o usurio para uma inspeo (e.g.
em um sistema educacional, a perspectiva de usurios alunos e professores distinta).
Alm disso, a inteno do usurio e seu contexto so fundamentais na definio de ca-
minhos plausveis de interpretao, e logo devem ser fornecidos ao avaliador de ante-
mo por meio de cenrios
12
.

Figura 9. Viso geral do Mtodo de Inspeo Semitica [de Souza et al. 2006]
Finalmente, alguns mtodos de inspeo requerem a participao de mais de um
avaliador para que seja possvel consolidar o resultado da avaliao. Sob o ponto de
vista da EngSem, cada avaliador gera um conjunto de possveis interpretantes sobre a
meta-comunicao. No h necessidade de mais de um avaliador, j que todos os
possveis caminhos interpretativos que possam ser gerados por um ou mais avaliadores
so plausveis. No entanto, a anlise por mais de um avaliador permite que se
identifique alguns caminhos interpretativos mais salientes e se enriquea o relatrio
com vises distintas. Em casos de sistemas que envolvem usurios em diferentes papis
(e.g. professor e aluno), cada avaliador poderia ficar responsvel por inspecionar a
interface sob a perspectiva de um dos papis.
6.3.2. MAC O Mtodo de Avaliao de Comunicabilidade
O Mtodo de Avaliao de Comunicabilidade (MAC) [Prates et al. 2000, de Souza
2005], diferente do MIS, um mtodo que envolve usurios na avaliao. A apreciao
da comunicabilidade do sistema no MAC feita a partir da comunicao usurio-
sistema, com base na qual o avaliador simula a comunicao do usurio para o designer
sobre a meta-mensagem. Como veremos, isto feito utilizando um conjunto de
expresses para identificar as rupturas de comunicao com o sistema vivenciadas pelo

12
Cenrios so narrativas textuais plausveis contextualizadas e detalhadas que descrevem determinada
situao [Carroll et al. 1994]. Na seo 6.4.1 este conceito ser apresentado em mais detalhes.

usurio, como se o avaliador colocasse palavras na boca do usurio. O usurio
participa na execuo de tarefas utilizando o sistema em um ambiente controlado (i.e.,
ambiente em que o usurio poder se concentrar no sistema, sem correr o risco de ser
interrompido ou ter sua ateno desviada das atividades do teste). Em etapa posterior, o
avaliador identifica os problemas de comunicabilidade, com base na sua anlise da
experincia do usurio durante sua interao com o sistema.
A etapa de coleta de dados envolve o planejamento da avaliao e a gerao do
material necessrio, seguidos da participao do usurio em executar as tarefas previstas
no laboratrio e uma entrevista (opcional) com o usurio sobre o que ocorreu. A
preparao para a coleta deve ser minuciosa para garantir a coleta de dados teis para
anlise, ou seja, que permitam observar aquilo que se deseja. Neste captulo apresenta-
mos brevemente os passos envolvidos nesta preparao (para uma descrio detalhada
ver [Prates e Barbosa 2003 ou Preece et al. 2002]):
1. Determinao do objetivo do teste: Na avaliao com o usurio, no possvel se
avaliar todo o sistema, e logo o foco do teste deve ser definido. Para isso, o avaliador
deve levar em considerao os objetivos de design e os pontos crticos do sistema.
Como a propriedade em questo a comunicabilidade, objetivos do sistema esto
relacionados com a inteno de comunicao do designer, como por exemplo O
usurio do Student Life consegue entender que as informaes mnimas a serem
fornecidas para utilizar o sistema so sobre o seu curso e disciplinas?
13
. Pontos crticos
normalmente so as partes do sistema que o designer prev que sejam utilizadas com
maior freqncia (e.g. cadastro e visualizao de tarefas associadas disciplinas),
fundamentais para o uso do sistema (e.g cadastro de disciplinas), ou ainda cuja
comunicao o designer ache elaborada (e.g. contm ambigidades que devem ser
compreendidas pelo usurio).
2. Seleo das tarefas para teste: Com base nos objetivos especficos do teste, o
avaliador deve definir quais tarefas devero ser executadas pelos usurios durante a sua
interao com o sistema. As tarefas devem ser tpicas e realistas, e devem permitir a
coleta de dados sobre os objetivos determinados no passo 1. Alguns cuidados devem ser
tomados durante a definio da tarefa: (1) especific-las bem, para que toda a
informao necessria para sua execuo seja fornecida ao usurio, ou seja, parte do
conhecimento prvio esperado do usurio; (2) o teste normalmente no deve durar mais
do que uma hora, e a execuo de cada tarefa no mais do que 20 minutos; (3) para cada
tarefa deve ser gerado um cenrio que a contextualize em uma situao de uso plausvel,
permitindo assim ao participante se colocar em um contexto e ser capaz de se comportar
de acordo com motivaes e intenes reais.
3. Seleo dos participantes: A seleo dos (potenciais) usurios a participarem da
avaliao deve ser feita com base no perfil de usurios a que o sistema se destina. Por
exemplo, para o Student Life a avaliao deveria ser feita com alunos universitrios, e
no com profissionais atuando no mercado de trabalho nem alunos do ensino
fundamental. Normalmente recomendado que de 5 a 8 usurios participem do teste
[Prates e Barbosa 2003, Nielsen 2000]. Quando o sistema destinado a mais de um

13
Alguns objetivos podem no ser passveis de apreciao no MAC. Por exemplo, a questo O aluno
consegue terminar com rapidez o cadastro de uma disciplina? requer uma avaliao de usabilidade.

perfil de usurio (e.g. alunos e professores) ento deve-se fazer uma avaliao en-
volvendo cada um destes perfis, e neste caso pode-se envolver menos usurios (no
menos que 3) de cada perfil [Nielsen 2000].
4. Consideraes sobre aspectos ticos: No Brasil, a resoluo 196/96 do Conselho
Nacional de Sade [CNS 196] regulamenta pesquisas envolvendo pessoas, e se aplica
avaliao de sistemas interativos com usurios [Leito e Dias-Romo 2003]. Para esses
sistemas, os principais aspectos desta resoluo so: o carter voluntrio e consentido
da participao do usurio no teste; a preservao do anonimato dos participantes; a
proteo de grupos vulnerveis (e.g. crianas e alunos); a garantia de bem-estar dos
participantes e de seu direito de interromper sua participao a qualquer momento
durante a avaliao. Alm disso, o participante deve dar seu consentimento por escrito,
atravs da assinatura de um documento que especifique as condies acordadas sobre
sua participao, assinado tambm pelo avaliador.
5. Gerao do material impresso para uso durante avaliao: Depois do planeja-
mento, o avaliador deve gerar o material impresso que ser utilizado durante o teste: o
questionrio para seleo de participantes do teste (caso haja mais voluntrios do que o
necessrio); questionrio pr-teste (para coletar informaes sobre caractersticas pesso-
ais e conhecimento prvio dos participantes); scripts de apresentao e explicao do
processo de teste aos usurios (para garantir que todos tero as mesmas informaes);
formulrios de consentimento de participao (contendo as condies da avaliao s
quais o usurio deve consentir); cenrios de apresentao do sistema (descrevendo o
que se quer apresentar do sistema ao usurio) e das tarefas (descrevendo e
contextualizando cada tarefa em uma situao de uso); formulrio de acompanhamento
de teste pelo avaliador (contendo a descrio do teste e a identificao do usurio para
facilitar as anotaes do avaliador durante a execuo dos testes); roteiros de entrevista
ou questionrios para coleta ps-teste das opinies do usurio sobre o sistema.
6. Execuo do Teste Piloto: O teste piloto permite ao avaliador apreciar a qualidade
do material gerado. Para isso, executa-se a avaliao planejada, de preferncia com
pessoas do perfil desejado, e observa-se se o participante capaz de entender todo o
material apresentado, se o tempo de execuo do teste est de acordo com o tempo pre-
visto, e se as tarefas propostas geram indicadores relevantes sobre o objetivo especfico
da avaliao a que esto associadas. Assim, garante-se que os dados coletados permiti-
ro de fato avaliar os aspectos desejados do sistema, e no causaro perda de dados ou,
no pior caso, invalidao do teste. Com base na experincia obtida durante o teste pi-
loto, faz-se ajustes no material e, se necessrio, conduz-se novos testes-piloto. Os dados
coletados durante os testes-piloto so usados apenas para avaliao do material, e no
devem ser considerados para anlise e apreciao do sistema.
Uma vez terminada a etapa de preparao, segue-se ento para a execuo dos testes
com os usurios selecionados. Isto deve ser feito em ambiente controlado, idealmente
um laboratrio de testes contendo uma sala para os usurios e outra de observao para
os avaliadores. O vidro para observao deve ser espelhado para deixar o usurio mais
vontade. Da sala de observao, o avaliador deve ser capaz de acompanhar a interao
do usurio (e.g. atravs de um monitor na sala de observao ligado ao computador

usado para teste), ver suas reaes durante a interao e ouvir seus comentrios
14
. O
MAC requer que toda a interao do usurio com o sistema de interao seja gravada
atravs da utilizao de um software de captura de tela. Esta gravao fundamental
para a etapa de anlise. Gravao de vdeo ou udio do teste so opcionais, mas podem
ser teis para se tirar ambigidade ou se rever comentrios ou expresses do usurio.
Alm disso, recomendvel que o avaliador faa anotaes durante a execuo do teste
de aes dos usurios que possam auxiliar posteriormente a anlise, como por exemplo
comentrios espontneos sobre suas dificuldades ou dvidas, indicaes de sua inteno
durante um dado momento, ou pontos que o avaliador j identifica como ambguos ou
interessantes a serem discutidos com o usurio durante a entrevista. Ao fim da execu-
o, passa-se para a entrevista com o usurio sobre a sua experincia sobre os testes.
Embora a entrevista seja opcional, ela bastante til e portanto recomendada.
Executados os testes, o avaliador passa ento etapa de anlise dos dados co-
letados. O MAC divide esta etapa em 3 passos: (1) Etiquetagem: identifica-se no filme
da interao as rupturas de comunicao e associa-se a cada uma delas uma expresso
que a caracterize; (2) Interpretao da Etiquetagem: com base na etiquetagem
identifica-se classes de problema de comunicao designer-usurio ou interao; (3)
Gerao do Perfil Semitico: faz-se a reconstruo da meta-mensagem designer-
usurio. A seguir apresentamos em detalhe cada um destes passos.
Etiquetagem
Neste passo, o avaliador v o filme gravado da interao do usurio com o sistema com
o objetivo de identificar rupturas na comunicao, ou seja, pontos em que o usurio no
foi capaz de entender a comunicao sendo feita pelo designer atravs da interface. O
avaliador deve fazer uso de suas anotaes durante o teste e entrevista para resolver am-
bigidades que porventura surjam. Caso tenha gravado o vdeo e/ou udio do teste pode
fazer uso destes tambm. A cada ruptura identificada, o avaliador seleciona a expresso
que a caracteriza (a partir de um conjunto de 13 expresses). As expresses tm por
objetivo serem expresses naturais que seriam plausveis de serem manifestadas pelo
usurio (e por vezes o so) durante a interao. Desta forma, o efeito de associar uma
determinada expresso a uma seqncia de interao que representa uma ruptura o de
simular a comunicao do usurio para o designer sobre a interface. Por exemplo, se o
usurio procura na interface como executar determinada ao, o avaliador associaria a
esta ruptura a expresso Cad?. A seguir apresentamos na Tabela 1 cada uma das ex-
presses do conjunto disponvel ao avaliador.
Tabela 1. Descrio das expresses para etiquetagem do MAC.
Cad? Ocorre quando o usurio sabe a operao que deseja executar mas no a encontra de imediato na
interface. O principal sintoma desta ruptura a procura pela operao na interface, inspecionando diver-
sos elementos de interface sem ativ-los (e.g. abrindo e fechando menus e submenus ou passando o
cursor de mouse sobre botes para ver a dica associada) .

14
Se o avaliador no tem um laboratrio disponvel, ele pode criar um ambiente controlado usando um
espao de acesso restrito, que lhe permita observar o usurio sem interferir na execuo da tarefa.

U, o que houve? Identificado quando o usurio no percebe a resposta dada pelo sistema a uma ao
sua (e.g. a resposta muito sutil, ou mesmo inexistente) ou no capaz de entend-la. Os sintomas
tpicos incluem repetir a ao ou buscar uma forma alternativa de alcanar o resultado esperado.
E agora? O usurio no sabe o que fazer e procura descobrir qual o seu prximo passo. Os sintomas
incluem vagar com o cursor do mouse sobre a tela e iniciar um caminho aleatrio de interao.
Epa! O usurio realiza uma ao indesejada e, ao perceber isto, imediatamente desfaz a ao. Os
sintomas incluem o acionamento imediato do Undo ou o cancelamento de um quadro de dilogo aberto
indevidamente. Observe-se que este 2
o
sintoma poderia ser visto tambm como parte de uma busca (
Cad?). O Epa! se diferencia por ser uma nica ao e no parte de uma seqncia maior.
Assim no d. O usurio realiza uma seqncia de aes e acredita estar seguindo por um caminho
improdutivo, interrompendo-o e cancelando-o. Os sintomas incluem o acionamento de Undo repetidas
vezes, a interrupo de um caminho guiado pelo sistema ou ainda o cancelamento quadros de dilogos
relacionados. A diferena entre o Assim no d. e o Epa! que o primeiro envolve vrias passos,
enquanto o Epa! envolve apenas um.
Onde estou? O usurio tenta efetuar operaes que no so apropriadas para o contexto em que se
encontra, mas o seriam para outros contextos do sistema, indicando uma confuso em relao ao contexto
com o qual est interagindo (e.g. tenta editar um elemento da interface disponvel apenas para
visualizao). Um sintoma tpico desfazer a ao incorreta e mudar em seguida para o contexto dese-
jado.
O que isto? Ocorre quando o usurio no sabe o que significa um elemento de interface. O principal
sintoma consiste em deixar o cursor do mouse sobre o elemento por alguns instantes, esperando que uma
dica seja apresentada. Outro sintoma quando o usurio abre menus e submenus ou quadros de dilogos
para ver a que se referem. Observe que este sintoma pode acontecer tambm para a expresso Cad?. A
diferena est na inteno do usurio. Quando o usurio est procurando algo ento este mesmo sintoma
seria um Cad?, se est explorando a interface, ento seria O que isto?.
Por que no funciona? A operao efetuada no produz o resultado esperado, e o usurio no entende o
por qu (ou no se conforma com o fato). O sintoma quando o usurio executa uma ao (ou seqncia
de aes), percebe que no obteve o resultado desejado e ento repete sua ao na tentiva de identificar a
causa de no ter atingido o efeito esperado e corrigi-la.
Socorro! O usurio no consegue realizar sua tarefa atravs da explorao da interface e recorre a signos
de meta-comunicao para conseguir entender e dar continuidade sua tarefa. O sintoma recorrer aos
sistemas de ajuda (e.g. agentes automticos ao qual se pode fazer uma pergunta, ou funes de ajuda que
apresentam explicaes a elementos da interface em um contexto), documentao (eletrnica ou im-
pressa), ou mesmo pedir explicao a outra pessoa.
Vai de outro jeito. O usurio no consegue realizar a tarefa da forma prevista como preferencial pelo
designer (seja porque no sabe que ela est disponvel, ou no sabe como utiliz-la), e resolve seguir
outro caminho, geralmente mais longo ou complicado. Cabe ao avaliador determinar, se possvel junto ao
designer, qual a forma preferencial de execuo da tarefa. Normalmente, as formas mais salientes na
interface so as consideradas preferenciais. O sintoma a tentativa frustrada de executar uma ao
utilizando a forma preferencial, seguida da adoo de uma soluo alternativa, ou mesmo a direta da
soluo alternativa, sem dar sinais de conhecimento da existncia da forma preferencial.
No, obrigado. O usurio conhece a soluo preferencial do designer, mas opta explicitamente por uma
outra forma de interao. O sintoma o usurio utilizar a ao preferencial (ou demonstrar conhec-la) e
depois utilizar uma ou mais formas alternativas para se alcanar o mesmo resultado.
Para mim est bom O usurio acha equivocadamente que concluiu uma tarefa com sucesso. O
sintoma tpico encerrar a tarefa e indicar na entrevista ou no questionrio ps-teste que a tarefa foi
realizada com sucesso. O observador, no entanto, sabe que se trata de um engano, provavelmente causado
por uma falha de resposta do sistema ou modo de visualizao inadequado para a tarefa atual.
Desisto. O usurio no consegue fazer a tarefa e desiste. O sintoma a interrupo prematura da tarefa. A
causa pode ser falta de conhecimento, tempo, pacincia, informao necessria, etc.

Para exemplificar o passo de etiquetagem, retomemos o exemplo apresentado na Figura
4, descrevendo as rupturas experimentadas por um aluno, e identifiquemos a expresso
associada a cada uma. A Figura 10 apresenta a tela com a qual o aluno est interagindo,
e a Tabela 2 descreve as aes que identificam a ruptura e a etiqueta associada.

Figura 10. Tela para incluir disciplina com a qual o aluno est interagindo.
Tabela 2. Exemplo de etiquetagem na tentativa de inlcuir uma disciplina no Student Life.
Descrio da seqncia de aes Etiqueta associada
Aluno v a lista de cursos vazia e tenta clicar no ttulo da lista, ou com o
boto direito do mouse sobre a lista para inserir um curso.

Por que no funciona?
Aluno v os anos a que o nvel da disciplina pode ser associado e passa o
cursor sobre o ttulo Class Level, ou Year para ver se obtm alguma dica
do que significa todos aqueles anos.

O que isto?

O aluno acessa o guia de usurio para tentar descobrir o que significam os
12 anos.

Socorro!
O aluno tenta acionar o boto para salvar Save and Exit, mas v que ele
est desabilitado.

U o que houve?
O aluno verifica os campos marcados como obrigatrios e percorre a tela
tentando descobrir como abilitar o boto Save and Exit.
E agora?
O aluno no consegue descobrir e clica no boto Cancel.

Assim no d.
Interpretao da Etiquetagem
Nesta etapa, o avaliador tabula os problemas identificados e sua interpretao, que de-
pende da sua experincia e conhecimento em EngSem. Alguns aspectos devem ser
considerados durante a interpretao para permitir ao avaliador identificar os principais
problemas da meta-comunicao [de Souza 2005]: (1) classificao das expresses que
caracterizam a ruptura quanto ao tipo de falha que representam na comunicao entre o
sistema (enquanto preposto do designer) e usurio; (2) a freqncia e contexto em que
ocorrem as rupturas; (3) identificao de padres de seqncias de expresses; (4) o
nvel da ao em que ocorre a ruptura.
Os tipos de falha so definidos em funo da relao entre a inteno de uma
comunicao e o efeito que ela causa. Quando a inteno de uma comunicao con-
sistente com o efeito que ela causa, ento a comunicao de sucesso. No entanto, se
existem inconsistncias, ela apresenta alguma falha, que pode ser ou no percebida pe-
los usurios. Estas falhas podem ser definidas como completas, parciais ou temporrias.
Falhas completas acontecem quando a inteno da comunicao e seu efeito so incon-
sistentes. Falhas parciais ocorrem quando parte do efeito pretendido da comunicao
no atingido. Finalmente, falhas temporrias so aquelas que ocorrem na expresso
ou inteno de um ato comunicativo entre usurio e sistema, e que so percebidas pelo

usurio que tenta ento super-las. fcil ver que falhas completas so mais graves que
as parciais ou temporrias, uma vez que representam o insucesso da comunicao desig-
ner-usurio. A Tabela 3 mostra a classificao das etiquetas em relao aos tipos de
falhas na comunicao designer-usurio atravs da interface.
Tabela 3. Classificao de etiquetas em relao ao tipo de falhas
Tipo de
Falha
Aspecto Semitico Caracterstica Especfica Expresso
Usurio percebe Desisto. Completas
Usurio no percebe Para mim est
bom
Usurio entende soluo proposta No, obrigado. Parciais
Usurio no entende soluo proposta Vai de outro jeito.
(a) No encontra expresso apropriada
para sua inteno
Cad?
(b) No percebe ou entende expresso do
preposto
U o que houve?
Semiose do usurio
interrompida tempora-
riamente
(c) No consegue formular sua inteno E agora?
(a) Dito no contexto errado Onde estou?
(b) A expresso utilizada est errada Epa!
Usurio percebe que
seu ato comunicativo
no foi bem sucedido.
(c) Vrios passos da comunicao no
chegaram ao resultado desejado.
Assim no d.
Atravs de metacomunicao implcita O que isso?
Atravs de metacomunicao explcita Socorro!
Temporrias
Usurio procura escla-
recer ato comunicativo
feito pelo sistema
Atravs de repetidos testes de hipteses
sobre o significado da comunicao.
Por que no
funciona?
Alm do tipo de falha a que cada etiqueta est associada, a freqncia e contexto em
que elas acontecem tambm so relevantes. Etiquetas que ocorrem com maior fre-
qncia apontam para um problema recorrente na metacomunicao designer-usurio.
Por exemplo, uma grande incidncia de Epa! pode indicar um excesso de ambigi-
dade na meta-mensagem, ou uma grande incidncia de O que isto? para uma baixa
interseo entre o sistema de significao adotado pelo designer e o conhecido pelo
usurio. O contexto em que as etiquetas acontecem fornece informaes relevantes
sobre a falha em indicar a inconsistncia de determinados caminhos interpretativos (e.g.
falha em indicar a diferena entre contextos ao usurio) ou mesmo apontar para o
designer caminhos interpretativos que deveriam ter sido considerados (e.g. aes que
poderiam ser consideradas vlidas em um determinado contexto).
Padres de seqncias de expresses que se repetem na etiquetagem podem for-
necer informaes relevantes sobre os caminhos interpretativos inconsistentes que o
usurio tem seguido. Isto pode ser um indicador de falhas na expresso sobre caminhos
interpretativos consistentes ou desejveis. Por exemplo, padres de Cad? seguido
por um Vai de outro jeito. apontam para a tentativa do usurio de comunicar algo ao

sistema, e a adoo de um caminho que no o timo. O fato de este padro se repetir
mostra que o usurio pode estar fazendo um uso sub-timo da soluo como um todo.
O nvel em que a ao do usurio se d pode ser classificado como operacional
uma ao individual; ttico uma seqncia de aes necessrias para se atingir um
objetivo; e estratgico relativo formulao do problema e de sua soluo. As ruptu-
ras relativas a aes so normalmente mais fceis de superar ou resolver do que aquelas
nos nveis tticos e estratgicos. No nvel ttico, elas podem indicar problemas nos
mtodos codificados, ou seja, como o designer acredita que o usurio deveria resolver
seu problema. Rupturas no nvel estratgico so graves, pois indicam falhas completas
na comunicao designer-usurio. Alm disso, rupturas em um nvel podem gerar ruptu-
ras em outro. Por exemplo, porque o usurio no entende que uma determinada seqn-
cia de aes (nvel ttico), ele pode achar que a soluo do designer no atende suas
necessidades (nvel estratgico), declinando-a como um todo. A anlise das rupturas nos
nveis operacional, ttico e estratgico pode identificar tambm alguns aspectos
relativos a aspectos da usabilidade do sistema [de Souza et al. 2000, de Souza 2005].
Embora usabilidade esteja fora do foco da EngSem, esta viso pode ser de interesse na
prtica e pode enriquecer a anlise dos problemas de comunicabilidade. Nesta mesma
direo, a anlise pode ser enriquecida fazendo-se a associao das rupturas de comuni-
cao com dimenses ou diretrizes propostas por outras teorias ou mtodos [de Souza,
2005].
Ao final do passo de interpretao, espera-se que o avaliador tenha sido capaz de
identificar os principais problemas na meta-comunicao designer-usurio. Em muitos
casos a prpria etiquetagem j pode oferecer ao designer indicadores tambm sobre uma
possvel soluo.
Gerao do Perfil Semitico
O 3
o
e ltimo passo da anlise a reconstruo da meta-comunicao transmitida do
designer tal como potencialmente percebida pelo usurio. Para isso, o avaliador pode
mais uma vez fazer uso do template:
medida que ele preenche o template, ele deve enderear os desencontros entre o que o
designer pretendia dizer e as evidncias de como os usurios esto interpretando o que
ele diz. Tais desencontros tero sido identificados.
* * *
Esta seo apresentou os dois mtodos fundamentados na EngSem para apreciao da
comunicabilidade de um sistema interativo. Do ponto de vista terico, a principal
diferena da apreciao feita por eles que o MIS se concentra na mensagem enviada
pelo designer, enquanto que o MAC se concentra em como esta mensagem est sendo
recebida e entendida pelo usurio. Em outras palavras, o MIS avalia a emisso da meta-
mensagem designer-usurio e, o MAC, a sua recepo [de Souza et al. 2006].

6.4. Projeto de Interao
A seo anterior dedicou-se a mtodos de avaliao da EngSem, uma das atividades
essenciais no ciclo de vida de design da interao. Nesta seo, apresentamos um mo-
delo simples de ciclo de vida de design da interao, bem como modelos e representa-
es de design adaptados ou concebidos com base na EngSem. Vale observar que esses
modelos tambm constituem ferramentas epistmicas. Ainda em linha com Schn
(1983), objetivamos aqui apoiar e motivar a reflexo do designer sobre a meta-
mensagem sendo elaborada, durante todo o processo de sua elaborao.
Segundo Preece e co-autoras, o design da interao envolve quatro atividades
principais: identificao de necessidades e estabelecimento de requisitos; desenvolvi-
mento de designs alternativos que satisfaam esses requisitos; construo de verses
interativas; e avaliao [Preece et al. 2002] (Figura 11).

Figura 11. Modelo de ciclo de vida para o design da interao [Preece et al. 2002].
A atividade de identificao das necessidades e definio dos requisitos visa
descobrir quem o usurio, o que ele faz, como o faz (ou preferiria fazer), em que
ambiente ou contexto de uso, e por qu. Isto importante para que seja possvel definir
como o sistema deve apoi-lo, o escopo do sistema e as condies e restries que
devem ser respeitadas. A anlise em IHC difere fundamentalmente da anlise de
sistemas tradicional: se concentra em gerar insumos para o projeto da interao e da
interface de usurio, em vez de modelos e estruturas de dados e funes. As
representaes mais utilizadas nesta etapa so cenrios e modelos de tarefa. Na
EngSem, nos concentramos, nesta atividade, em produzir insumos para a construo da
meta-mensagem designerusurio, que ser elaborada e detalhada na atividade de
design e redesign.
Na atividade de design (ou redesign), o projetista elabora o design conceitual e
o fsico. O design conceitual define o que o produto deve fazer, como deve se comportar
e se apresentar. J o design da interface envolve o detalhamento de todos os elementos
da interface do produto, incluindo cores, imagens, menus e cones, bem como a
organizao desses elementos em cada tela ou unidade de apresentao. A todo
momento so consideradas alternativas, tanto no design conceitual quanto no fsico. Do
ponto de vista da EngSem, nesta atividade o designer elabora a meta-mensagem a ser
transmitida aos usurios, projetando sistemas de significao que lhes forneam pistas

sobre como interpret-la. Neste curso, nos concentramos no design conceitual, atravs
de modelos de interao que representem a meta-mensagem designerusurio. Em
particular, utilizaremos a MoLIC, uma linguagem para modelagem de interao
ancorada na EngSem.
Segundo Preece e co-autoras, a maneira mais razovel para os usurios avalia-
rem um design interagindo com ele. Isto requer a construo de uma verso intera-
tiva dos designs, mas no significa necessariamente que uma verso em software seja
necessria. Prottipos em papel so rpidos e baratos de se construir, e podem ser avali-
ados, por exemplo, atravs de role playing.
A atividade de avaliao visa determinar a qualidade do design ou produto.
Pode-se utilizar uma variedade de critrios, como o nmero de erros cometidos, o
quanto satisfaz os requisitos, e o quanto atraente, entre outros. Como visto na seo
6.3, a EngSem se concentra na avaliao da comunicabilidade.
Nas subsees seguintes, apresentamos como cenrios e modelos de tarefas po-
dem ser utilizados (com algumas adaptaes) em projetos de design pautados na
EngSem, e introduzimos a modelagem da interao como uma conversa e a modelagem
do sistema de ajuda, elaboradas como produto da teoria.
6.4.1 Cenrios
Um cenrio uma narrativa, textual ou pictrica, concreta, rica em detalhes contextu-
ais, de uma situao de uso da aplicao, envolvendo usurios, processos e dados reais
ou potenciais. Um cenrio tpico uma histria sobre pessoas realizando uma atividade.
Rosson & Carroll (2002) descrevem os seguintes elementos caractersticos de um cen-
rio: ambiente/contexto; atores; objetivos; planos; avaliao; aes; e eventos. A identifi-
cao desses elementos nos cenrios tambm contribui para torn-los mais completos e
promove a reflexo do designer sobre a situao de uso sendo descrita. O ambiente ou
contexto envolve detalhes circunstanciais que motivam ou explicam objetivos, aes e
reaes dos atores do cenrio. Os atores so as pessoas que interagem com o computa-
dor ou com o contexto. A descrio de um ator no cenrio deve incluir as caractersticas
pessoais que forem relevantes ao cenrio. Os objetivos so os efeitos na situao que
motivam as aes que os atores realizam. J um plano uma atividade mental direcio-
nada para converter um objetivo em comportamentos. Um comportamento observvel
uma ao. J um evento uma ao ou reao externa produzida pelo computador ou
outras caractersticas do ambiente; algumas dessas podem estar ocultadas dos atores,
mas ser importantes para o cenrio. Por sua vez, a avaliao a atividade mental dire-
cionada para interpretar caractersticas de uma situao.
Alguns dos objetivos do uso de cenrios so esclarecer questes complexas e
explorar decises alternativas de projeto. Por serem ricos em contextualizao, os cen-
rios permitem explorar com detalhes os impactos da tecnologia a ser projetada nas ativi-
dades e nos processos de trabalho dos usurios. As tcnicas baseadas em cenrios vm
ganhando grande aceitao por parte dos projetistas e seus clientes. Isso se deve princi-
palmente natureza do problema de design de software, que no uma forma fcil ou
rotineira de resoluo de problemas [Carroll 2000]. Os problemas de design costumam
ser especificados de forma incompleta, as solues no so conhecidas a priori, envol-
vem trade-offs 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 hu-
manas, com freqncia extrapolando as fronteiras das solues de design originais pre-
tendidas. O design de IHC baseado em cenrios busca gerenciar a complexidade da re-
soluo de problemas de design atravs de uma concretizao de uma situao de uso
[Carroll 2000]. Carroll acredita que descrever a soluo desde o incio utilizando dia-
gramas e especificaes muito bom para documentar e transmitir a soluo para quem
vai implement-la. No entanto, essas representaes abstraem a riqueza do uso do sis-
tema em situaes reais, e podem se tornar um obstculo tanto para uma explorao
mais ampla do espao de design quanto para o envolvimento e participao dos clientes
e futuros usurios do sistema no processo de design.
Os cenrios ajudam designers e analistas a se concentrarem nas suposies sobre
pessoas e suas tarefas. Cenrios podem ser representados como prottipos, atravs do
uso de storyboards, vdeos, ou ferramentas de prototipao rpida. Eles podem ser utili-
zados em todas as fases do processo de desenvolvimento de sistemas interativos: du-
rante a fase de elicitao e anlise de requisitos, para capturar os requisitos e explorar a
introduo de tecnologia; durante a fase de design e especificao, para explorar solu-
es alternativas e basear decises de design; durante a implementao, para verificar se
a implementao est de acordo com os cenrios anteriores; e durante os testes, para
apoiar os usurios na validao do sistema.
Apesar de ricos em detalhes e contextualizados, os cenrios, quando usados na
fase de anlise de necessidades e definio de requisitos, no devem conter detalhes da
interface propriamente dita, como textos e rtulos, tipos de widgets utilizados, etc.
Pretende-se com isto evitar um comprometimento precoce dos designers com uma solu-
o 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. A Figura
12 ilustra um cenrio de uso hipottico do Student Life, elaborado pelo designer para
explorar situaes em que o objetivo do usurio adiar um trabalho.

J oo, aluno de Servio Social, est utilizando o Student Life (SL) pela primeira vez esse perodo [2]. Ele
quer organizar melhor sua vida acadmica, registrando as datas de prova e de entrega de trabalhos das
disciplinas que est cursando [1]. Na segunda semana de aula, durante uma palestra sobre o uso do SL,
ele cadastrou no seu notebook todas as disciplinas, uma a uma, juntamente com os dados do professor, de
horrios e salas de aula de cada uma, e para cada uma cadastrou as datas de provas e trabalhos [3]. No
entanto, Andr, seu professor de tica Profissional, resolveu adiar o seu trabalho por 2 semanas, aten-
dendo aos pedidos dos alunos que tinham trabalhos de 2 disciplinas a serem entregues na mesma data.
Ele aproveita um intervalo entre as aulas para utilizar seu notebook e entra no SL. Logo ativa o
calendrio [7], vai at o ms de abril para procurar o trabalho e o encontra na data em que estava
cadastrado [6, 7]. J oo seleciona o trabalho, pede para modificar seus dados e estabelece a nova data: 3
de maio de 2007 [5]. Ao voltar ao calendrio, percebe que j no est mais no ms de abril, e sim maio, e
confere que o trabalho est marcado corretamente na nova data. Ainda um pouco inseguro, J oo volta
para o ms de abril para se certificar de que o trabalho no est mais na data antiga.
Figura 12. Cenrio de uso para adiamento da data de entrega de um trabalho.
Algumas crticas ao uso de cenrios se referem freqncia com que ficam incompletos
ou ambguos.
Ainda com o objetivo de elaborar cenrios mais completos, descobrindo infor-
maes que foram omitidas, Carroll et al. (1994) propem a tcnica de questionamento

sistemtico, onde so feitas perguntas sobre proposies extradas dos cenrios. Eles
descrevem alguns tipos de questes e a razo por que formul-las, mas uma taxonomia
completa deixada para um trabalho futuro.
Tabela 4. Questes para refinamento de cenrios.
Questo Contedo
Por que ...?
condies para realizao de uma atividade, suas conseqncias e
estados e eventos anteriores ou posteriores atividade sob investiga-
o
Como...? detalhes sobre a seqncia de aes que compem uma atividade, e
com freqncia revelam tambm objetos que no constavam do cen-
rio original
O que ...? objetos e seus atributos, organizados em uma hierarquia
Questes de verificao:
<Isto>pode ser feito <as-
sim>?,<Isto>faz parte <da-
quilo>?
respostas so sim ou no, servem para avaliar se uma ao ou atributo
est bem definido e localizado no nvel certo da hierarquia
No mbito da EngSem, utilizar cenrios durante a atividade de anlise visa principal-
mente definir a primeira parte da meta-mensagem designerusurio: Esta a minha
interpretao sobre quem voc , o que eu entendi que voc quer ou precisa fazer, de
que formas prefere faz-lo e por qu. [de Souza 2005:84]. Isto servir de base para a
elaborao do restante da meta-mensagem (Eis, portanto, o sistema que
conseqentemente concebi para voc,...).
Neste contexto, Paula (2003) prope complementar os cenrios com perguntas
que ajudem o designer a construir a meta-mensagem. Essas perguntas podem revelar os
intuitos do designer ao elaborar os cenrios ou identificar os pontos que o designer al-
meja descobrir, explorar ou ratificar junto aos usurios. Alm de apoiar o entendimento
do designer e a sua reflexo sobre a meta-mensagem que ser projetada, estas perguntas
tambm podem evitar que os cenrios fiquem incompletos ou ambguos, ou at mesmo
revelar novos elementos nos cenrios. O designer pode gerar uma lista global de per-
guntas que seriam referenciadas nos cenrios gerados (Figura 13).

Algumas perguntas exploradas nos cenrios do sistema de exemplo:
1. Para que serve o SL?
2. Qual o perfil de usurios do SL?
3. Que tipos de informao podem ser cadastradas no SL?
4. Como cadastrar uma disciplina no SL?
5. Como se pode cadastrar informaes sobre provas e trabalhos no SL?
6. Como as informaes sobre provas e trabalhos esto organizadas no SL?
7. Quais so as formas de consultar uma data de prova ou entrega de trabalho no SL?
Figura 13. Parte das perguntas exploradas no cenrio do Student Life.
A referncia pode ser feita incluindo-se o nmero da pergunta entre colchetes, no trecho
do cenrio onde se descreve o aspecto que a pergunta pretende abordar, como ilustrado
na Figura 12. Como algumas questes so especficas a determinadas situaes de uso,
nem todas as questes sero respondidas em todos os cenrios. Nesse exemplo, observa-
se que a questo 4 no foi explorada nesse cenrio, pois estava fora do seu escopo. Cabe
ao designer se certificar de que as questes esto sendo respondidas nos cenrios rele-
vantes.

6.4.2 Anlise e Modelagem de Tarefas
Mesmo utilizando-se as estratgias descritas acima para a elaborao de cenrios, ainda
possvel que haja ambigidades ou omisses nos cenrios descritos. Para tentar
reduzir ainda mais este problema e obter uma viso geral e estruturada das tarefas que
se pretende apoiar, utilizam-se com freqncia tcnicas de anlise e modelagem de
tarefas
15
.
A anlise hierrquica de tarefas (HTA Hierarchical Task Analysis) foi um
dos primeiros mtodos de anlise de tarefas desenvolvido [Annett & Duncan 1967,
Diaper & Stanton 2004]. Ela foi criada pela necessidade de uma base racional para a
compreenso das habilidades necessrias para tarefas complexas e no repetitivas, espe-
cialmente tarefas de controles de processos, que envolviam tanto atividades fsicas
quanto mentais. A anlise de tarefa uma abordagem top-down, que examina primeiro
as metas de alto nvel (ou objetivos), antes de considerar as aes atravs das quais a
meta pode ser atingida. Essas metas so decompostas e definidas em termos de uma
hierarquia de metas e submetas aninhadas, buscando identificar quais submetas so
mais difceis de atingir ou causam mais erros, ou seja, quais submetas podem limitar ou
impedir o alcance da meta maior.
A HTA um mtodo sistemtico de investigar problemas de desempenho hu-
mano, verificar se a tarefa realmente atingida ou, caso contrrio, por que no. O prin-
cipal objetivo da HTA poder relacionar o que os usurios fazem (ou o que se reco-
menda que faam), por que o fazem e as conseqncias de isso no ser feito correta-
mente. A HTA permite caracterizar a prtica de trabalho, identificando, categorizando e
decompondo tarefas. Um objetivo o estado desejado do sistema; tarefas descrevem a
maneira como o objetivo pode ser alcanado; operaes so as menores e mais bsicas
unidades de comportamento; e planos especificam as condies sob as quais uma tarefa
ou subtarefa deve ser realizada [Preece et al. 1994].
Inicialmente, deve-se especificar os objetivos principais que cobrem toda a rea
de interesse. Cada um deve ser dividido em subtarefas. Essas subtarefas devem ser dis-
postas como planos em camadas, certificando-se de que estejam lgica e tecnicamente
corretas, e de que no haja omisses. O prximo passo decidir o nvel de detalhe ne-
cessrio, para saber at onde deve-se decompor as tarefas. Prossegue-se a anlise, de-
compondo as tarefas em profundidade ou em largura. Deve-se utilizar uma numerao
que permita a identificao inequvoca de um plano, que consiste em um caminho desde
a raiz da tarefa at as folhas correspondentes. Ao final da anlise, deve-se verificar se
todas as decomposies e numeraes esto consistentes. Alm do diagrama de tarefas,
pode ser til produzir um texto explicativo. Como boa prtica, pode-se mostrar o dia-
grama para outra pessoa verificar sua consistncia. Esta pessoa deve conhecer a tarefa,
mas no deve ter participado do processo de modelagem.
No design de IHC pautado pela EngSem, os modelos de tarefas devem represen-
tar, alm da estrutura hierrquica: o tipo de tarefa, subtarefa ou operao no que diz res-
peito ao seu contedo, forma e ilocuo [de Souza 2005]. So representados: pr-condi-

15
H pesquisadores e profissionais que dispensam o uso de cenrios, e em vez deles utilizam modelos de
tarefas em diversas etapas do processo de design. Este captulo considera que cenrios e modelos de
tarefas podem ser utilizados de forma complementar.

es (se houver); estruturas de seqncia e iterao; tarefas alternativas, opcionais e
ubquas; signos associados e mecanismos de preveno e tratamento de erros ou ruptu-
ras de comunicao.
A representao utilizada uma adaptao ao diagrama hierrquico de tarefas
[Paula 2003, de Souza 2005]. O objetivo (meta de alto nvel) representado por um
retngulo com bordas arredondadas. As tarefas que o compem so representadas por
retngulos, com marcaes especiais para indicar a que tipo de estrutura esto associa-
das, como ser visto adiante. A decomposio das tarefas em subtarefas deve parar
antes que o modelo inclua detalhes operacionais de interface, tais como digitar X,
pressionar boto Y, etc. Dependendo do ponto em que se pra a decomposio das
tarefas, existem tarefas to simples que podero em fases posteriores no processo de
design ser mapeadas diretamente em um elemento de interface ou de interao. Estas
tarefas so representadas no modelo como operadores, os quais so representados por
uma linha abaixo do retngulo. O modelo de tarefas deve refletir como o usurio
trabalha, evitando se concentrar em um ambiente ou plataforma tecnolgica especfica.
Esta considerao no apenas facilita o re-uso 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.
Por exemplo, na Figura 14, Adiar data de entrega de trabalho o objetivo, Localizar
trabalho uma tarefa e Selecionar trabalho um operador. O projetista optou por modelar a
tarefa Ativar calendrio como um operador. Deve-se observar que as tarefas que o usurio
vai realizar de fato so as que esto representadas nas folhas (ltimo nvel) da estrutura
hierrquica, muitas das quais so representadas por operadores.

Figura 14. Modelo hierrquico de tarefas adaptado.
As tarefas podem ser organizadas nos seguintes tipos de estruturas: seqenciais,
independentes de ordem, alternativas e iterativas. Em uma estrutura seqencial, existe
uma ordem em que as tarefas devem necessariamente ser efetuadas pelo usurio. As
tarefas, nesta estrutura, so representadas por retngulos contendo o nome da tarefa,

expresso do ponto de vista do usurio, e um nmero indicando sua posio na seqncia
(Figura 15a).
Algumas tarefas podem ser realizadas em qualquer ordem. Uma estrutura de tarefas
independente de ordem representa um conjunto (e no uma seqncia) de tarefas a
serem efetuadas pelo usurio. Tipicamente, o projetista sugere uma ordem de execuo,
mas o usurio quem determina, de fato, em que ordem as tarefas sero efetuadas.
Neste tipo de estrutura, as tarefas so representadas como as tarefas seqenciais, mas,
como a ordem apenas sugerida, inclumos um ponto de interrogao aps o nmero
que indica a posio relativa da tarefa na estrutura. No exemplo, identificamos algumas
tarefas independentes de ordem (Figura 15b).
Para o alcance de uma meta, h momentos em que diversos cursos de ao so
possveis. Tais cursos de ao so representados por uma estrutura alternativa, onde o
usurio dever selecionar qual das tarefas da estrutura ser efetuada. Nesta estrutura,
utilizam-se pequenos crculos no canto superior direito do retngulo de cada tarefa al-
ternativa, e letras como identificadores em vez de nmeros (Figura 15c).
Quando uma tarefa pode ser realizada diversas vezes, utiliza-se uma estrutura
iterativa. Um asterisco (*) no canto superior direito do retngulo utilizado para indi-
car a iterao (Figura 15d). Geralmente, uma tarefa iterativa representa tarefas que po-
dem ser efetuadas zero ou mais vezes. Caso seja necessrio definir um nmero mnimo
ou mximo de repeties, pode-se 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. Alm disso, quando o usurio pode optar por realizar
ou no uma tarefa, ela dita opcional, e representada com uma borda tracejada
(Figura 15e).

(a) (b) (c) (d) (e)
Figura 15. Representao de estrutura de tarefa (a) seqencial, (b) independente de
ordem, (c) alternativa, (d) iterativa e (e) opcional.
A EngSem ressalta a importncia de se representar, associadas 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. Para isto, a representao diagramtica das tarefas com-
plementada por uma especificao textual, como ser visto adiante.
Signos
Atravs dos cenrios, pode-se identificar os signos que faro parte das ilocues do pre-
posto do designer e do usurio, ou seja, que so apresentados ao usurio ou por ele
manipulados. Examinando todos os signos presentes nos cenrios, percebe-se que al-
guns deles podem ser agrupados e relacionados a conceitos ou entidades do domnio

e/ou da prpria aplicao. Estes so representados como signos compostos. A Tabela 5
mostra os signos extrados do cenrio apresentado na Figura 12. Os signos disciplina, ttulo,
enunciado, data de entrega e referncias podem ser agrupados no signo composto trabalho.
Observa-se que o signo disciplina , ele prprio, um signo composto de outros signos (e.g.
nome, cdigo, professor). Em ltima anlise, essas composies e relacionamentos podem
auxiliar a definio de um modelo de entidades e relacionamentos. Neste momento do
design de IHC, no entanto, o foco est na identificao de quais signos esto relaciona-
dos a quais tarefas, e ainda no no relacionamento entre os prprios signos.
Os signos da interface de uma aplicao podem ser classificados como signos de
domnio, transformados ou de aplicao. Signos encontrados no mundo do usurio,
independentemente da aplicao, so chamados de signos do domnio (por exemplo,
nome e endereo). Signos originados no domnio, mas que sofrem alguma transforma-
o ao serem incorporados aplicao, como uma transformao resultante de
analogias ou metforas, so representados como signos transformados (por exemplo,
pastas na rea de trabalho do Windows). Por ltimo, signos que s fazem sentido dentro
da aplicao, e no tm significado prvio para os usurios, so chamados de signos da
aplicao (por exemplo, login e senha).
Por que classificar os signos dessa forma? Porque tipos de signos diferentes re-
querem diferentes tomadas de deciso por parte do designer. Pode ser necessrio proje-
tar ilocues que melhor apiem a interpretao do signo pelo usurio, para que este,
por sua vez, tambm seja capaz de enunciar ilocues adequadas envolvendo o signo ou
sobre ele. Para signos do domnio, tais ilocues podem ser necessrias, caso haja
limitaes impostas pela prpria aplicao, como uma restrio na sua expresso (for-
mato do dado de entrada) ou contedo (valores vlidos). Por exemplo, um signo de data
pode requerer explicaes sobre o formato esperado (dd/mm/aaaa) e sobre as datas per-
mitidas (nos ltimos 5 anos; somente dias teis). J para os signos transformados, o
designer deve fornecer aos usurios informaes sobre os limites da analogia ou met-
fora realizada para transport-los para a aplicao. Por exemplo, uma explicao sobre
as pastas em um desktop seria Estas pastas funcionam como no mundo real, exceto que
nunca ficam cheias. Isto , voc pode manter e colocar muitas coisas nelas. Na reali-
dade, o disco do seu computador o real local onde as coisas esto sendo guardadas.
Ento, ele que controla a quantidade de espao que pode ser ocupado. Finalmente,
signos de aplicao, que podem ser totalmente desconhecidos pelos usurios, requerem
uma explicao completa sobre o que significam e como so utilizados. Por exemplo, o
signo zoom em uma aplicao grfica. Alguns signos podem gerar dvidas no momento
de classificao em um dos tipos. Por exemplo, o signo senha pode ser classificado em
aplicao, mas pode aparecer a seguinte dvida No se pode considerar o signo senha
nesta aplicao como uma analogia assinatura, impresso digital ou algo que
identifica uma nica pessoa? Se sim, ento tambm se pode classific-lo como signo
transformado. Neste caso, fica a cargo do designer definir o tipo do signo, com base
nas caractersticas dos usurios e suas tarefas, bem como a quantidade de informao a
ser fornecida. Em todo caso, a classificao auxilia o designer a refletir sobre a
explicao a ser associada a cada signo.
Tabela 5. Signos simples e compostos definidos para o sistema de exemplo.
signo com-
posto
signos que o com-
pem
tipo descrio

trabalho domnio Trabalho de uma disciplina a ser entregue na data
estipulada.
disciplina
(composto)
domnio
data de entrega domnio Quando o trabalho deve ser entregue.
ttulo domnio Identificao breve do trabalho.
enunciado domnio Enunciado completo do trabalho.
referncias domnio Material de apoio execuo do trabalho.
lembrete transformad
o
Lembrete emitido alguns dias antes da data de
entrega do trabalho
disciplina domnio Disciplina cursada pelo aluno.
nome domnio Nome ou ttulo da disciplina.
cdigo domnio Cdigo da disciplina.
professor
(composto)
domnio Professor que leciona a disciplina.
...
Para se fazer referncia a um dos signos que compem um signo composto, deve-se
utilizar o formato nome_signo_composto.nome_signo. Se, por outro lado, for necessrio fazer
referncia a todos os signos de uma determinada composio, pode-se utilizar o formato
nome_signo_composto.*. Por exemplo, o signo correspondente ao nome do professor pode
ser expresso como professor.nome. J em uma ilocuo que envolve todos os dados de um
professor, como nome, e-mail, horrios de atendimento, o conjunto destes signos pode ser
representado por professor.*. Cada signo que for enunciado pelo preposto, ou seja, apre-
sentado ao usurio (considerado comumente como um dado de sada), representado
por seu nome seguido de ponto de exclamao (nome!). J um signo que ser enunciado
pelo usurio, ou seja, correspondente a um dado que ser fornecido ou manipulado pelo
usurio (considerado um dado de entrada), representado por seu nome seguido de
ponto de interrogao (nome?). Caso haja diversas instncias de um mesmo tipo, pode-se
utilizar os construtos conjunto([signos],cardinalidade) ou seqncia ([signos], cardinalidade, ordena-
o) para represent-las. Na Figura 16, observam-se, para a tarefa A.2 Fornecer dados do
trabalho, diversos signos que sero manipulados pelo usurio: disciplina, ttulo, data de en-
trega, enunciado e referncias. Para a tarefa B.2 Examinar trabalhos, definida uma seqncia
de signos que sero apresentados em ordem cronolgica inversa de data de entrega. J
para a tarefa B.4 Examinar dados do trabalho, todos os signos relacionados ao signo com-
posto trabalho sero apresentados.

A. 2 For necer dados do t r abal ho
SI GNOS: t r abal ho. di sci pl i na?, t r abal ho. t t ul o?, t r abal ho. dat a_ent r ega?,
t r abal ho. enunci ado?, t r abal ho. r ef er nci as?

B. 2 Exami nar t r abal hos
SI GNOS: seqncia( [ t r abal ho. di sci pl i na! , t r abal ho. t t ul o! ,
t r abal ho. dat a_ent r ega! ] , 0..n, ord( t r abal ho. dat a_ent r ega, inv) )

B. 4 Exami nar dados do t r abal ho
SI GNOS: t r abal ho. *!
entrada sada
sada

Figura 16: Identificao dos signos em um modelo de tarefas.

Preveno e Tratamento de Rupturas
Como dito anteriormente, a EngSem ressalta a importncia de se representar os signos e
rupturas que possam ocorrer durante a realizao de uma tarefa. No momento de
representao de uma tarefa, j possvel prever algumas possveis rupturas (break-
downs) na comunicao entre o preposto do designer e o usurio que podem ocorrer
durante a sua realizao. Nestes casos, o designer deve representar, para cada tarefa, os
tipos de apoio preveno e tratamento de ruptura que pretende oferecer, classificando-
os em uma das seguintes categorias [Barbosa & Paula 2003]:
preveno passiva (PP): Rupturas que devem ser evitadas por ilocues do pre-
posto do designer, como documentao ou instrues online (por exemplo, uma dica
de formato como (dd/mm/aaaa) ao lado de um campo de data; ou uma instruo
explcita como * indica campo obrigatrio).
preveno ativa (PA): Rupturas que devem ser evitadas ativamente pelo sistema,
que restringe a possibilidade de expresso do usurio a ilocues vlidas. No mo-
delo de interface, por exemplo, isto poder ser concretizado atravs de: habilitar ou
desabilitar botes de acordo com o status atual da aplicao; impedir que o usurio
digite letras ou smbolos em campos numricos; um controle de calendrio que im-
pede que o usurio indique uma data invlida; e assim por diante.
preveno apoiada (alerta - AL): Situaes que o sistema detecta como sendo
rupturas em potencial, mas cuja deciso recai sobre o usurio. Cabe ao preposto des-
crever adequadamente a situao e solicitar que o usurio tome uma deciso infor-
mada sobre os rumos da interao. Isto ocorre, por exemplo, quando o usurio ex-
pressa a inteno de gravar um arquivo com um nome diferente (Salvar como...),
mas em seguida informa o nome de um arquivo existente. Geralmente esse meca-
nismo concretizado na interface por mensagens de confirmao (por exemplo,
Arquivo j existe, deseja sobrescrev-lo?; Foram feitas alteraes no trabalho.
Deseja armazen-las?).
tratamento apoiado (TA): Rupturas que ocorreram e devem ser tratadas pelo usu-
rio com apoio do preposto do designer, ou seja, a partir de ilocues do preposto, o
usurio enuncia novas ilocues que lhe permitam prosseguir com a sua tarefa (por
exemplo, o preposto apresenta uma mensagem descrevendo o problema e d uma
oportunidade para o usurio corrigi-lo).
captura de erro (CE): Erros que so identificados pelo preposto e devem ser
notificados ao usurio, sem que haja qualquer passo corretivo possvel dentro do
sistema (por exemplo, O arquivo est corrompido. ou Espao em disco insufici-
ente.).
Os tipos de preveno e tratamento de ruptura so apresentados de forma textual no
modelo de tarefas, logo aps a indicao dos signos (Figura 17).

A. 2 For necer dados do t r abal ho
SI GNOS: t r abal ho. di sci pl i na?, t r abal ho. t t ul o?, t r abal ho. dat a_ent r ega?,
t r abal ho. enunci ado?, t r abal ho. r ef er nci as?
PREVENO PASSI VA e TRATAMENTO APOI ADO: dat a_ent r ega e t t ul o so campos
obr i gat r i os

Figura 17. Representao de alguns tipos de preveno e tratamento de ruptura.

6.4.3 Modelagem de Interao
A partir da caracterizao dos usurios, seu ambiente de trabalho, e suas tarefas, pode-
mos prosseguir para a modelagem da interao
16
. O objetivo da modelagem de
interao definir as conversas que o usurio poder travar com o preposto do designer
(e quando, e sob que condies), ou seja, especificar as ilocues que esses
interlocutores podero enunciar para o usurio atingir seus objetivos.
responsabilidade do designer contar para o usurio sua viso de design e dar-lhe
melhores condies de entender e aprender sobre o sistema projetado e as formas de
utiliz-lo. Portanto, precisamos estabelecer sobre o que se est conversando e de que
forma esta conversa ocorre. A modelagem da interao pode ento ser considerada
como a especificao de todas as possveis conversas que os usurios podero travar
com o preposto do designer. Em linhas gerais, trata-se de projetar os caminhos de
interao que o usurio pode percorrer, incluindo caminhos alternativos e de exceo
ou ruptura. Cada passo de interao ocorre dentro de uma cena, na qual so travados
dilogos entre usurio e sistema, guiados por um ou mais objetivos comunicativos. Um
dilogo tem tpico e foco. O tpico o tema central do dilogo, e o foco consiste em
um trecho de conversa sobre algum aspecto especfico do tpico. A Tabela 6 apresenta
um exemplo de interao como uma conversa na marcao de uma reunio de grupo de
trabalho.
Tabela 6. Exemplo de interao como uma conversa.
U: Preciso marcar uma reunio do grupo do trabalho de IHC. Tpico: marcar uma reunio
U: Deixe-me ver os compromissos dessa semana.
S: Ei-los.
Foco: compromissos da semana
U: A reunio deve durar umas 3 horas. No tem nenhum hor-
rio disponvel para ela.
Foco: horrios disponveis com dura-
o determinada
U: Deixe-me ver a prxima semana.
S: Aqui est. Voc tem aulas todos os dias de manh, e as tar-
des de 2, 4 e 6 esto ocupadas.
Foco: compromissos da prxima se-
mana
U: Tem horrio disponvel na 3 feira s 14h-17h. Foco: horrios disponveis com dura-
o determinada
U: Vou marcar a reunio nesse dia e horrio Foco: novo compromisso no dia e
horrio selecionados
S: Que tipo de compromisso? Com quem e onde?
U: Reunio com o grupo de trabalho, nas salas de estudo.
Foco: dados da reunio
S: Marcado. Foco: verificao dos dados da reunio
Paula (2003) props, no mbito da EngSem, uma linguagem para a modelagem da
interao humano-computador como uma conversa, MoLIC (Modeling Language for
Interaction as Conversation). MoLIC foi projetada para apoiar os designers no planeja-
mento da interao, motivando sua reflexo sobre as estratgias de resoluo de proble-
mas dos usurios que deveriam ser apoiadas pelo sistema interativo. Desde sua
proposta, diversas aplicaes vm sendo modeladas com a MoLIC, para diferentes do-
mnios e plataformas. Algumas extenses foram propostas e dispararam um extenso
esforo de reviso, que resultou na 2 edio da MoLIC [Silva 2005]. Esta seo apre-
senta a verso diagramtica dessa segunda edio.

16
Esta subseo apresenta uma sntese da monografia [Silva & Barbosa 2007].

MoLIC foi projetada para representar a interao humano-computador como o
conjunto de conversas que os usurios podem (ou devem) travar com o sistema (mais
precisamente, com o preposto do designer) para atingir seus objetivos. Nessas conver-
sas, para os usurios entenderem melhor seu interlocutor, o preposto do designer precisa
comunicar-lhes adequadamente: 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. MoLIC foi projetada para ser uma
ferramenta epistmica, ou seja, utilizada para aumentar a compreenso dos designers
sobre o problema sendo resolvido e o artefato sendo projetado, e no para oferecer solu-
es e respostas diretas para os problemas e questes em pauta. importante observar
que a MoLIC foi proposta para uso humano e, portanto, no representa um modelo
formal processvel por computador. MoLIC no foi concebida para substituir
representaes existentes, mas sim complement-las. Por exemplo, seqncias de
eventos descritas em cenrios e estruturadas em modelos de tarefas podem ser articula-
das num diagrama MoLIC, motivando a representao de relaes e intersees entre
objetivos, cenrios ou tarefas.
MoLIC composta atualmente de quatro artefatos: um diagrama de metas, um
esquema conceitual de signos e um diagrama de interao complementado por uma es-
pecificao textual. O diagrama de metas indica o que os usurios podem fazer com a
aplicao, ou seja, quais objetivos podem atingir. O esquema conceitual de signos de-
fine e organiza os conceitos envolvidos no sistema, em particular aqueles que emergem
na interface de usurio. Inclui informaes envolvidas em cada ao do usurio ou ao
externa que afete a interao usuriosistema. O diagrama de interao representa como
as metas podem ser atingidas durante a interao, e a especificao textual detalha o
contedo do diagrama de interao para servir como ponte entre a modelagem da intera-
o e o projeto da interface propriamente dita. Nesta seo, nos concentramos na
construo dos diagramas de metas e de interao. As representaes detalhadas (es-
quema conceitual de signos e especificao textual da interao) no so endereadas
neste documento.
Diagrama de Metas
O diagrama de metas utilizado para representar as metas dos usurios que tenham sido
identificadas na etapa de anlise. Um diagrama de metas diferente de um modelo de
tarefas: utilizado apenas para definir o que o usurio deseja realizar, sem considerar
como ele o far. Para construir um diagrama de metas, o designer precisa inicialmente
listar as metas identificadas na etapa de anlise. Essas metas correspondem aos objeti-
vos descritos nos cenrios e estruturados nos modelos de tarefas.
As metas podem ser classificadas em finais e instrumentais. As metas finais po-
dem geralmente ser formuladas como: Eu (usurio no papel <Papel>) quero utilizar o
sistema para <atingir metaFinal>. J as metas instrumentais so utilizadas como
facilitadoras para as metas finais. Alm disso, as metas instrumentais podem ser
planejadas ou oportunistas. As metas instrumentais planejadas podem ser formuladas
como: Quero <atingir metaInstrumental> para <atingir metaFinal> [de forma mais
eficiente|fcil|...]. J as metas oportunistas surgem durante a interao, e podem ser
formuladas como: Aqui de onde estou no sistema, vou <atingir metaInstrumental>

para <atingir metaFinal> [de forma mais eficiente|fcil|...]. No diagrama de metas,
so representadas apenas metas finais e instrumentais planejadas.
Atravs do diagrama de metas, visa-se organizar e anotar as metas dos usurios
de acordo com algumas dimenses de interesse do designer. Essas dimenses variam
com o tipo de projeto. Alguns elementos que podem ser utilizados para organizar as
metas so:
papis de usurios (i.e. papis que podem atingir cada meta, tais como
aluno/professor);
tipo de meta (meta final ou instrumental planejada);
entidade principal envolvida na meta (e.g. professor, disciplina, prova etc.)
Metas concretas, que os usurios podero atingir utilizando a aplicao, podem ser
agrupadas em metas mais abstratas para facilitar a visualizao. O diagrama de metas
representado por uma estrutura hierrquica anotada, indicando grupos de metas e papis
de usurios. No diagrama, ns-filhos herdam os papis do n-pai, isto , se um n A
possui um n B como filho, ento todos os papis que podem atingir a meta A tambm
podem atingir a meta B. No caso do sistema de exemplo, algumas metas so:
cadastrar, visualizar, modificar, remover disciplinas;
cadastrar, visualizar, modificar, remover provas e trabalhos; e
descobrir quais so as atividades nos prximos dias.
A Figura 18 apresenta um diagrama de metas ilustrando o que pode ser feito
com o sistema de exemplo. Esse diagrama bem simples, pois h somente um papel de
usurio: aluno. Nele, pode-se observar que as metas finais e instrumentais esto
separadas: as metas finais so aquelas relacionadas diretamente com as atividades dos
alunos, ao passo que as instrumentais (planejadas) so aquelas relacionadas
configurao do sistema. Alm disso, algumas metas abstratas so definidas para
organizar as metas concretas de acordo com os signos sendo manipulados. Estas so
indicadas por linhas pontilhadas no diagrama.
Cada meta pode estar associada a um ou mais cenrios. Numa abordagem
baseada exclusivamente em cenrios, algumas relaes entre as metas podem ser
deixadas sem representao. Considerando as metas Visualizar objeto e Remover objeto
ilustrados na figura, pode acontecer de um cenrio para Remover um objeto definir uma
forma diferente de localizar um trabalho do cenrio Visualizar objeto. Isso pode causar
inconsistncias e dificuldades na interao usurio-sistema. Uma situao extrema
aconteceria se o usurio visualizasse um trabalho e, percebendo que este deveria ser
removido, ele no pudesse faz-lo naquele momento. Em vez disso, teria que abandonar
a atividade de visualizao, selecionar uma opo para remover o trabalho, localizar
novamente o trabalho e s ento remov-lo. Esse exemplo de problema muito trivial e
portanto raro, mas ilustra uma possvel inconsistncia ou ineficincia que pode no ser
detectada utilizando-se somente cenrios.

Figura 18. Diagrama de metas para o sistema de exemplos (adaptado de [Araujo 2005]).
Diagrama de Interao
O diagrama de interao da MoLIC permite aos designers representar todas as possveis
conversas interativas que os usurios podem travar com o preposto do designer para
atingir suas metas [Paula 2003, Silva 2005]. Ele foi concebido para motivar os designers
a refletir sobre a metacomunicao, permitindo-lhes especificar conversas alternativas
para o atingimento de um mesmo objetivo, e analisar o relacionamento e interferncias
entre metas (e, portanto, especificar as conversas relativas a metas instrumentais oportu-
nistas). A representao diagramtica foi escolhida para promover uma viso global da
aplicao tal como o preposto vai apresent-la para o usurio
17
. Isso ajuda a evitar o
tipo de problema descrito acima.
A construo de diagramas MoLIC realizada em dois passos. Primeiro, os de-
signers definem os tpicos de todas as possveis conversas usurio-sistema e as trocas
de turno entre usurios e o preposto que encadearo os tpicos dessas conversas. Esse
nvel de abstrao promove uma reflexo, anlise e discusses sobre a interao por
uma equipe multidisciplinar cedo no processo de design [Paula et al. 2005]. Ao final
dessas discusses, ou mesmo durante, caso necessrio, os tpicos so detalhados, e os
designers definem os 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,
mas no ser apresentado neste captulo por restries de espao.
Deve haver um diagrama MoLIC para cada papel de usurio. Cada diagrama re-
presenta 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 ele quer rea-
lizar (e como o preposto permite/recomenda/requer que ele o faa). importante obser-
var que essa perspectiva comunicativa no implica que a interface de usurio concreta
ser uma interface no estilo conversacional. Significa apenas que as questes comunica-

17
Quando h mltiplos papis de usurios, a interao usurio-sistema de cada papel deve ser
representada em seu prprio diagrama MoLIC. Isso significa que, quando dizemos viso global, nos
referimos perspectiva de um nico usurio da aplicao (i.e., todas as partes da aplicao s quais ele
tem acesso), e no aplicao inteira transpassando mltiplos papis, tal como visto pelo designer.

tivas envolvidas na interao usurio-sistema so trazidas para o primeiro plano e expli-
citamente durante o design da interao.
No primeiro passo da construo de diagramas MoLIC, os designers especificam
todas as conversas entre usurio e preposto do designer. O foco dessa etapa apoiar os
designers na reflexo de questes gerais de interao, sem detalhar cada passo de intera-
o em estruturas de elementos atmicos. Algumas dessas questes gerais so:
troca de turnos entre usurio e sistema para atingir uma meta;
conversas (caminhos de interao) alternativas para os usurios atingirem uma
mesma meta (possivelmente endereando as necessidades e preferncias de diferen-
tes perfis de usurios);
conversas relativas a metas instrumentais oportunistas;
conversas para a recuperao de rupturas, i.e., mecanismos para os usurios se
recuperarem de rupturas;
a consistncia (ou no) entre caminhos de interao semelhantes ou anlogos.
No restante desta subseo, vamos utilizar como exemplo a situao em que o aluno
quer cadastrar uma disciplina no sistema StudentLife.
Como a conversa aberta? E como fechada?
Um ponto de abertura onde a conversa usurio-sistema se inicia. Na maioria dos am-
bientes, o momento em que a aplicao ativada no sistema operacional. Num nave-
gador, o momento em que uma URL vlida digitada ou um link seguido para a
aplicao Web. Em aplicaes baseadas em documentos, por outro lado, geralmente h
dois pontos de entrada: um acessado ativando-se a aplicao, e outro acessado quando
um documento produzido por aquela aplicao ativado. Em cada caso, a conversa
pode iniciar de forma diferente: abrindo um documento em branco ou o documento
acessado. J um ponto de fechamento pode ser utilizado para indicar o encerramento
da conversa (i.e. trmino da interao usurio-sistema). Isso geralmente indica
momentos especficos da interao de onde o usurio pode sair da aplicao. Os pontos
de sada geralmente so representados quando uma conversa de encerramento pode
ocorrer antes do final real da interao. Por exemplo, quando necessrio armazenar
mudanas realizadas antes de sair da aplicao.
A Figura 19a ilustra dois pontos de entrada para um editor de texto,
representados por crculos preenchidos na cor preta, e a Figura 19b ilustra a
representao de um ponto de sada para um editor de texto, representado por um
crculo negro circunscrito a um crculo branco.

(a) (b)
Figura 19. Pontos de a) abertura e b) fechamento para um editor de texto.
Sobre o qu o usurio poder falar?
A forma mais simples de representar isso na MoLIC utilizar uma cena. As cenas re-
presentam 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 numa pea teatral, onde as trocas
comunicativas entre usurio e sistema ocorrem. Na notao da MoLIC, uma cena re-
presentada por um retngulo com bordas arredondadas. No incio da construo de uma
cena, somente o tpico da conversa precisa ser representado. Essa representao m-
nima de uma cena representada na Figura 20a. O tpico de uma cena pode ser lido,
do ponto de vista do preposto
18
, como Neste momento, voc (usurio) pode (ou deve)
<tpico>
19
.
A conversa numa cena pode ser composta de diversos dilogos, que por sua vez
so compostos de pares conversacionais. Os dilogos de uma cena so representados
num segundo compartimento da cena, entre colchetes. Os dilogos indicam os subtpi-
cos da cena, isto , o contedo das ilocues que o usurio e o preposto podem enunciar
sobre o tpico da cena naquele momento. A Figura 20b ilustra a cena Cadastrar disciplina
com um dilogo, indicando ainda os signos envolvidos nas ilocues correspondentes.
(a)
(b)
Figura 20. Representao da cena Cadastrar disciplina: a) mnima; b) com dilogos.
Numa cena, alguns dilogos podem ocorrer que no so parte da aplicao sendo proje-
tada, mas sim do sistema operacional ou ambiente computacional. Por exemplo, quando
um usurio manipula uma pgina Web utilizando uma barra de rolamento, ele no est
trocando falas com a aplicao projetada, e sim com o navegador. Em geral, o designer

18
Um diagrama MoLIC pode ser lido do ponto de vista do preposto do designer ou do ponto de vista do
usurio, dependendo do objetivo do leitor.
19
No momento, no h uma diferenciao, na MoLIC, entre pode e deve. Essa distino est
implcita na indicao dos signos obrigatrios que compem os dilogos da cena. Estamos investigando,
no entanto, uma forma de tornar essa diferenciao mais explcita, alm de acrescentar uma outra
modalidade: eu [preposto] recomendo a voc [usurio]..., que contribuir ainda mais para o
mapeamento da MoLIC para a interface concreta.

conhece esses tipos de dilogos, mas tem pouco ou nenhum controle sobre eles. Por
isto, esses dilogos no so representados no diagrama de interao. Somente nos casos
em que o designer quer que seu preposto fale sobre esses interlocutores externos
que ele deve representar os dilogos e signos correspondentes.
Quando vista de forma isolada, uma cena no informa muita coisa aos designers.
Quando que um usurio pode falar sobre aquele tpico (i.e. cadastrar uma disci-
plina)? Quando e como o sistema pode responder ao que o usurio disse sobre o tpico?
Qual o resultado (i.e. as alteraes no sistema ou no mundo real) desse trecho de
conversa (i.e. o que o usurio realiza)? Pode algo dar errado? Se der, o qu, e como o
usurio pode se recuperar disso e prosseguir em direo ao alcance de sua meta? Qual
a correspondncia entre um diagrama MoLIC e o diagrama de metas? Os elementos da
MoLIC que permitem aos designers enderear essas questes so vistos a seguir.
Quando e como o preposto pode responder ao que o usurio disse?
Para o sistema responder a tudo o que o usurio falou sobre o tpico da cena, o usurio
precisa passar o turno para o sistema, que pensar sobre (i.e. processar) a comunica-
o do usurio e responder de acordo. Dois elementos da MoLIC so utilizados aqui:
uma fala de transio (ou fala de troca de turnos) e um processo de sistema.
Uma fala de transio representa uma troca de turno com mudana de tpico
conversacional
20
. Pode ser causada por uma fala do usurio ou do preposto do designer.
Tal fala 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. A Figura
21a ilustra uma fala de transio do usurio a partir da cena Cadastrar disciplina:
(a)
(b)
Figura 21. a) Fala de transio do usurio; b) Processamento do sistema como uma
caixa-preta, seguida de fala de transio do preposto.
Em alguns casos, as falas de transio se referem a algum signo manipulado na cena de
origem. Por exemplo, quando o usurio examina um conjunto de disciplinas, pode
selecionar uma delas para modificar ou remover. Isso poderia ser representado por uma
fala de transio [ u: modi f i ca di sci pl i na D] , onde D representa uma disciplina. O
signo pode ser indicado atravs de uma seleo de usurio, por exemplo, mas as deci-
ses sobre a expresso dos signos so deixadas para mais tarde, na etapa de modelagem
da interface.

20
Vale observar que trocas de turno podem ocorrer dentro de uma cena, tal como expresso nos dilogos.
No entanto, optamos por representar explicitamente como fala de transio somente as trocas que
envolvem mudana de tpico.

O que houve? Qual o resultado (i.e. as alteraes no sistema ou no mundo real )
desse trecho de conversa (i.e. o que o usurio realiza) concludo pela fala de transio?
Um processo de sistema ocorre quando a vez de o sistema pensar e decidir qual ser
o prximo tpico da conversa, geralmente como resposta a uma fala de transio do
usurio. Enquanto o sistema est pensando, o usurio no sabe o que est
acontecendo exceto pelas falas do preposto do designer sobre o que est
pensando/fazendo, tanto durante quanto aps o processamento. Portanto, importante
motivar os designers a pensarem sobre como comunicar aos usurios sobre o progresso
e os resultados do processamento do sistema, e sobre para onde a conversa vai dali, e
por qu.
Um processo de sistema representado num diagrama MoLIC por uma caixa
preta (retngulo 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), como e
por qu. A Figura 21b ilustra a troca de turnos usurio-sistema, indicada pela seqncia
[cena, fala de transio do usurio, processo do sistema, fala de transio do preposto
do designer].
Como resultado do processamento, o preposto do designer pode levar a conversa
para uma cena ou, caso no haja mais nada para o usurio fazer para atingir a meta cor-
respondente, pode encerrar a conversa com um monlogo, que deve ser apenas perce-
bido e interpretado pelo usurio. Um monlogo representado por uma caixa branca e
seu contedo redigido entre colchetes duplos, como em: <<contedo >>
21
.A Figura
22a ilustra um monlogo do preposto do designer como resultado de um processamento
de sistema sobre o cadastramento da disciplina
22
.
Cenas sem dilogos
H cenas em que o preposto do designer fala sobre um ou mais signos, para que o usu-
rio possa examin-los e decidir como a conversa deve prosseguir dali. Nesse caso, o
segundo compartimento contm apenas os signos, sem uma indicao do dilogo cor-
respondente. A Figura 22b ilustra uma cena para gerenciar disciplinas, a partir da qual o
usurio pode prosseguir para criar uma nova disciplina, modificar ou remover uma dis-
ciplina existente.
Nesse caso, pode-se considerar que o usurio est envolvido numa conversa no
sentido atribudo por Schn (1983) expresso conversa com materiais. Podemos
considerar que esse tipo de conversa composto de falas epistmicas, enunciadas (ou
simplesmente pensadas) pelo usurio para seu prprio entendimento do que lhe foi (ou

21
importante observar que o texto entre colchetes no expressa as palavras exatas que o preposto do
designer utilizar, apenas o contedo relevante a ser comunicado naquele momento da interao.
22
Geralmente, esse tipo de operao levaria a uma nova cena do tipo Visualizar disciplinas, onde o
usurio veria todas as disciplinas cadastradas, ou ainda a uma cena Visualizar disciplina, onde o usurio
veria os detalhes da disciplina que acabou de cadastrar e poderia iniciar outras conversas sobre a
disciplina, tal como Cadastrar trabalho, por exemplo. O monlogo foi utilizado aqui para introduzir esse
elemento, apesar de no constituir necessariamente uma boa soluo de design.

est sendo) comunicado pelo seu interlocutor sobre os signos representados na cena.
Vale observar que isso diferente do monlogo do preposto do designer descrito acima.
Pode algo dar errado? Se der, o qu, e como o usurio pode se recuperar disso e
prosseguir em direo ao atingimento de sua meta?
Em algumas situaes, rupturas comunicativas podem ocorrer. Quando resultam de um
problema ou falha no processamento do sistema (e.g. U, o que houve? ou Por que
no funciona?), a fala do preposto do designer pode representar um caminho de
recuperao. Falas de transio de recuperao de ruptura so representadas na MoLIC
por linhas direcionadas tracejadas. A Figura 22c ilustra uma fala desse tipo quando o
aluno tenta cadastrar uma disciplina com um cdigo que j tinha sido cadastrado
previamente.

(a) (b) (c)
Figura 22. a) Monlogo do preposto como resultado de um processamento; b) Cena
sem dilogos; c) Fala de transio de recuperao de ruptura.
Dizemos que uma ruptura ocorre quando a expresso da inteno do usurio no o leva
a atingir o efeito pretendido com essa inteno (tal como presumido pelo preposto do
designer), ou seja, a perlocuo inconsistente com a ilocuo. Nesse caso, o usurio
precisa desviar da interao na direo da meta a ser atingida e buscar um entendimento
da prpria interao. Em outras palavras, o usurio deve aprender, com o preposto,
como expressar sua inteno de forma que o preposto possa entend-la (i.e., process-
la para a realizao bem-sucedida da meta tal como projetada, para satisfazer a inteno
presumida do usurio). Como natural e freqente que mal-entendidos ocorram numa
conversa, a EngSem destaca a importncia de representar as rupturas comunicativas que
podem ocorrer durante a interao. Mais do que tentar antecipar as rupturas possveis,
necessrio definir a forma como o preposto 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. Portanto, para cada momento de interao
no qual uma ruptura pode ser antecipada, o designer deve definir os mecanismos e falas
de recuperao apresentadas aos usurios.
Pode-se observar o prefixo [TA] na Figura 22c. Isso indica o tipo de mecanismo
oferecido aos usurios para se recuperarem da ruptura, tal como descrito na subseo
sobre modelagem de tarefas. Nesse caso, o mecanismo oferecido o de tratamento apoi-
ado. importante observar que nem todas as falas de recuperao de ruptura so enun-

ciadas pelo preposto do designer. Quando uma fala de recuperao de ruptura enunci-
ada por um usurio, representa uma oportunidade explicitamente projetada para o usu-
rio se recuperar de um caminho de interao acidental (no-intencional). Tais falas po-
dem ser lidas como Epa! (No era isso que eu queria fazer).
Nos processos de sistema vistos at agora, o resultado do processamento s
comunicado aps o processo ter sido concludo, atravs de uma fala de transio do pre-
posto do designer. Para alguns processamentos, o designer pode querer comunicar ao
usurio tambm o progresso do processamento ou seus estados intermedirios. Essa
comunicao sncrona se torna mais importante na medida em que a durao do pro-
cessamento aumenta, como por exemplo durante o download de um arquivo ou a reali-
zao de uma busca. Nesses casos o preposto do designer pode emitir diversas falas
durante o processamento. Para representar esse tipo de comunicao, representamos
uma caixa branca acoplada caixa preta, que representa falas sincronizadas com o pro-
cessamento do sistema e sobre ele. A Figura 23 ilustra esse elemento.

Figura 23. Comunicao sncrona sobre o progresso de um processamento de sis-
tema em andamento.
importante assegurar que a comunicao sobre um processamento seja uma indicao
correta do estado 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 ao usurio algum controle sobre
esse processamento, tal como suspend-lo, cancel-lo ou ajust-lo. Portanto, pode haver
falas de transio de usurio saindo da caixa branca, como ilustrado na figura.
Quando um usurio pode falar sobre um tpico (i.e. travar uma conversa sobre um
tpico)?
Para completar nosso exemplo sobre o cadastramento de uma disciplina, precisamos
representar o momento de incio da conversa sobre esse tpico especfico. A abertura de
conversas sobre tpicos especficos representada por acessos ubquos, falas de transi-
o de usurio a partir de cenas annimas com fundo cinza. Um acesso ubquo significa
que, a partir de qualquer cena, e em qualquer momento da aplicao, tal conversa pode
ser iniciada. A Figura 24a ilustra um acesso ubquo para a cena Cadastrar disciplina.
Examinando um diagrama, o designer pode perceber que no faria sentido para o
usurio travar uma determinada conversa. Por exemplo, pode no fazer sentido tentar
agendar uma reunio de estudos para uma prova que j passou
23
. Para restringir os mo-

23
No existe ainda um mtodo de avaliao formativa de diagramas de interao, que organize e
sistematize as reflexes relevantes sobre a soluo de interao sendo projetada. No ano de publicao
deste captulo, uma proposta de mtodo para isto est sendo elaborada por membros do grupo de pesquisa
em EngSem, o SERG.

mentos na interao onde o usurio pode travar certas conversas, uma fala de transio
pode ser representada com um ou mais pressupostos (pr-condies). Esses so repre-
sentados tambm como texto na fala de transio, precedidos pela palavra-chave pr e.
Eles podem ser redigidos em linguagem natural ou numa linguagem artificial escolhida
pelo designer. Por exemplo:
pr e: dat a de pr ova ant er i or dat a do si st ema
[ u: agendar r euni o de est udos par a pr ova]
Qual a correspondncia entre um diagrama MoLIC e o diagrama de metas?
At agora, no mostramos como o diagrama MoLIC est relacionado com as metas re-
presentadas no diagrama de metas, ou seja, como as seqncias de ilocues esto asso-
ciadas s perlocues globais. Apesar de Cadastrar disciplina ser o mesmo texto que identi-
fica uma meta e um tpico de cena, no est claro quando a meta considerada atingida
ou qual o caminho completo de interao correspondente meta. No diagrama
MoLIC, representamos as metas utilizando uma forma geomtrica com fundo cinza
claro envolvendo os elementos da MoLIC que correspondem meta, com uma identifi-
cao da meta em um de seus lados (Figura 24b).

(a)

(b)
Figura 24. a) Acesso ubquo para a cena Cadastrar disciplina; b) Correspondncia
entre um trecho de diagrama MoLIC e o diagrama de metas.
A identificao das metas no diagrama MoLIC aumenta a rastreabilidade entre os
modelos. Isso facilita a avaliao do impacto de correes e revises que podem
ocorrer, assim como a manuteno de consistncia entre os modelos, a cada nova
verso.
Pontos de contato
Alguns dilogos durante a interao usurio-sistema tm como interlocutor um ator ex-
terno ao contexto imediato da interao. Quando isso ocorre, o designer deve represen-
tar as influncias entre o usurio e esses atores externos [Silva & Barbosa 2004]. Aps

construir os diagramas de interao para cada papel, representamos pontos de contato
entre os diagramas para indicar a influncia de um ator A1 com o sistema sobre a
interao de um outro ator A2 com o sistema. As falas chegando a ou partindo de um
ponto de contato podem ser originadas ou direcionadas a qualquer ponto no diagrama,
seja processamento ou cena. Cada ponto de contato representado graficamente por um
crculo com um rtulo indicando o papel correspondente no diagrama alvo. A Figura 25
ilustra os pontos de contato de uma aplicao de publicao eletrnica, na qual um autor
redige um texto e o submete para o editor aprov-lo ou enviar de volta ao autor para
reviso.

Figura 25. Ponto de contato entre dois diagramas MoLIC.
Apoiando decises de design
Esta subseo apresenta brevemente dois exemplos do uso da MoLIC para ajudar a des-
crever algumas decises de design que a MoLIC objetiva apoiar.
Exemplo1: solicitar ou no confirmao. A partir de uma cena onde o preposto do
designer pede ao usurio para informar alguns dados, o designer pode considerar as
seguintes opes (Figura 26):
a) armazenar os valores fornecidos pelo usurio e prosseguir com a interao
(supondo improvvel que o usurio informe um valor incorreto);
b) solicitar uma confirmao do usurio, levando-o a verificar os dados que
forneceu e somente aps a confirmao armazen-los; ou
c) armazenar os dados, mas, em vez de prosseguir com a interao, mostrar os
dados armazenados para dar ao usurio uma chance de verificar e corrigir os
valores, se necessrio.

(a) (b) (c)
Figura 26. Opes para uma meta de " publicar notcia " : a) grava sem pedir
confirmao; b) pede confirmao antes de gravar; c) grava e permite verificao.
Exemplo 2: Articulando a conversa. Quando um tpico envolve subtpicos, h pelo
menos duas opes (Figura 27):

(a) (b)
Figura 27. Disposio de dilogos a) numa nica cena ou b) em diferentes cenas.

a) oferecer mltiplos dilogos numa mesma cena, cada qual correspondendo a
um subtpico diferente; ou
b) projetar mltiplas cenas, ligadas por falas de transio de usurio, tal como
num assistente ou wizard.
Essa situao tambm pode ocorrer quando o objetivo do usurio simplesmente
explorar signos de diferentes formas, envolvendo operaes de navegao, sem
processamento.
6.4.4 Modelagem do Sistema de Ajuda
O sistema de ajuda na EngSem uma forma de comunicao privilegiada entre designer
e usurios, uma vez que uma comunicao direta [Silveira et al. 2004, Silveira 2002].
Portanto, fundamental que se faa o projeto do sistema de ajuda para que o usurio
possa entender melhor a soluo do designer, se recuperar de problemas que porventura
venham a ocorrer e fazer melhor uso do sistema. O modelo fundamentado em EngSem
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?, Cad?),
adicionado de outras especficas para o entendimento da comunicao designer-usurio
(e.g. Para que serve isto? Por que tenho que fazer isto?).
Como complemento aos modelos de tarefa e de interao, devemos representar
diversas outras informaes necessrias elaborao do contedo de ajuda a ser dispo-
nibilizado no sistema. Em estudos realizados sobre sistemas de ajuda, foram compiladas
dvidas freqentes dos usurios ao utilizarem sistemas interativos, classificadas de
acordo com o tipo de dvida [Baecker et al. 1995, Sellen & Nicol 1990] (Tabela 7).
Tabela 7. Tipos de dvidas freqentes dos usurios.
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 destas perguntas podem (e devem!) ser respondidas durante as etapas iniciais
de anlise e modelagem de usurios e tarefas. Alm disto, respostas a algumas destas
perguntas podem ser extradas diretamente dos modelos j construdos, mas outras de-
vem ser explicitamente elaboradas pelos projetistas. Nesta seo, analisaremos as per-
guntas de acordo com os modelos que especificam a resposta, os elementos da aplicao
a que esto relacionadas, ou com a etapa de desenvolvimento em que se pode respond-
las.
A pergunta O que posso fazer com este programa? pode ser respondida rela-
cionando-se as metas dos usurios identificadas nos cenrios e organizadas no diagrama
de metas.

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 ao modelo de interface. O nvel conceitual
pode ser descrito no incio do processo de desenvolvimento, enquanto 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 vin-
culadas principalmente ao modelo de tarefas. A estrutura hierrquica de uma tarefa re-
presenta 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 ca-
minhos 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 quais so as tarefas cujas pr-condies 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
estruturas de tarefas conhecidas, e procure identificar em que tarefa o usurio se encon-
tra no momento e quais aes ou subtarefas faltam para complet-la.
As perguntas interpretativas, navegacionais e histricas, por sua vez, esto rela-
cionadas principalmente ao modelo de interao, que representa os caminhos que o usu-
rio pode seguir e que indicaes o sistema fornece sobre onde ele se encontra a cada
instante. A pergunta O que est acontecendo agora? est relacionada a mecanismo 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 pro-
blemas 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 pro-
grama? e Como ele ir me beneficiar? no podem ser derivadas diretamente dos mo-
delos e, portanto, precisam ser explicitamente respondidas pelos projetistas. Estas per-
guntas dizem respeito aplicao como um todo, e no a uma tarefa especfica. Elas
devem ser respondidas no incio do processo de desenvolvimento, como registro da in-
teno de design, e depois revisadas para verificar se todos os objetivos iniciais foram
atingidos.
6.5. Consideraes Finais
Neste captulo, apresentamos a teoria da EngSem e vimos mtodos de avaliao e
modelos de design de IHC que nela se baseiam. Nesta seo, descrevemos brevemente
algumas questes de pesquisa da EngSem em diferentes domnios, como programao
feita por usurio final, sistemas colaborativos, sistemas educacionais e sistemas de
informao geogrfica.
6.5.1 EngSem e Programao Feita por Usurios Finais
Este captulo apresentou tcnicas, modelos e representaes desenvolvidos ou
adaptados com o objetivo de oferecer sistemas interativos de alta qualidade de uso, que
satisfaam as necessidades dos usurios, respeitando seus valores e sua cultura. At aqui
trabalhamos com uma abordagem que instrumenta o designer para capturar essas
necessidades e valores e codific-los numa tecnologia que os apie na realizao de

suas atividades e no alcance de seus objetivos. No entanto, fato que os designers no
podem antecipar todas as possveis atividades que um usurio precisar realizar com o
apoio dos sistemas interativos que eles projetam. Para oferecer uma correspondncia
duradoura entre as intenes e necessidades dos usurios e as possibilidades
tecnolgicas preciso dar mais poder aos usurios para que eles prprios possam
customizar e estender os sistemas interativos de forma que contemplem suas
necessidades ao longo do tempo.
Os computadores so mquinas de processamento simblico nas dimenses l-
xica, sinttica e semntica. Os seres humanos, por sua vez, para se comunicar uns com
os outros, manipulam signos nas dimenses de inteno, contedo e expresso. De
acordo com de Souza & Barbosa (2006), no existe uma correspondncia das dimenses
nessas diferentes perspectivas. A grosso modo, as dimenses de expresso humana
esto relacionadas s dimenses lxica e sinttica dos computadores, ao passo que a
dimenso semntica do processamento computacional est relacionada s dimenses de
contedo e inteno da comunicao humana. Para projetar sistemas computacionais
com alta usabilidade, os designers precisam [de Souza 2005]: i) sintetizar um sistema de
significao para apoiar a IHC; ii) comunicar sua viso de design atravs desse sistema
de significao; iii) comunicar as regras e princpios de acordo com os quais certas
expresses so sistematicamente associadas a certos contedos para atingir uma gama
especfica de intenes; iv) comunicar se e como tais princpios e regras podem ser
modificados; e v) comunicar como os significados modificados podem ser utilizados de
forma eficiente na interao com a aplicao.
Para se beneficiarem das qualidades desse tipo de design, os usurios precisam
[de Souza & Barbosa 2006]: i) entender o sistema de significao projetado;
ii) formular uma hiptese satisfatria sobre como os significados so codificados nesse
sistema; iii) dominar seu uso para comunicar as intenes ao sistema e atingir uma vari-
edade de objetivos com isso; iv) formular uma hiptese satisfatria sobre quais novos
significados (ou modificaes de significados) podem ser codificados e como; e
v) codificar tais significados no sistema e incorpor-los s variedades possveis de dis-
curso interativo com a aplicao.
6.5.2 EngSem e Sistemas Colaborativos
Com a popularizao da Internet, houve tambm um grande crescimento da oferta e uso
de ambientes que promovem interao entre pessoas, sejam eles para fins sociais, de
ensino ou de trabalho. Nestes ambientes, o usurio deve interagir no apenas com o sis-
tema, mas com outros usurios atravs do sistema. Assim, os projetos destes sistemas e
de suas interfaces lidam com novas questes relativas comunicao, coordenao e
colaborao. Como tratar estas questes no projeto e avaliao de interface um desafio
sendo tratado tanto na rea de IHC, quanto de CSCW (Computer Supported Collabo-
rative Work, ou sistemas colaborativos).
Na EngSem, a interface de um sistema colaborativo continua sendo uma mensa-
gem do projetista para os usurios. No entanto, neste caso o projetista no est se comu-
nicando apenas com um usurio, mas com todo um grupo. Assim alm de sua mensa-
gem ser capaz de transmitir aos usurios quem o projetista acredita que eles sejam, os
seus propsitos para utilizar o sistema e como interagir com este sistema, ela deve tam-
bm transmitir aspectos da soluo relacionados com o grupo. A mensagem para o

grupo deve comunicar quem o grupo, e os membros que o formam, quais as suas ne-
cessidades, com quem podem se comunicar atravs do sistema e atravs de que lingua-
gem e protocolos o fazem [Prates 1998, de Souza 2005, Barbosa 2006].
As ferramentas epistmicas para projetistas de ambientes multi-usurio devem
apoi-los na reflexo sobre a sua meta-comunicao com os usurios membros do
grupo. A EngSem atualmente conta com diferentes tipos de ferramentas epistmicas
especficas para sistemas colaborativos. A primeira delas a descrio de trs metforas
que podem ser utilizadas com base na apresentao de um sistema colaborativo [de
Souza 2005]. A segunda, um conjunto de questes a serem propostas para guiarem a
avaliao por inspeo de um sistema colaborativo, mas que tambm poderia ser utili-
zado para apoiar o designer nas suas decises de projeto [de Souza 2005]. Finalmente,
modelos com o objetivo de apoiar o projetista na definio da sua soluo para o projeto
da interao entre membros de um sistema colaborativo [Prates 1998, Barbosa 2006].
Dentre estas ferramentas, damos destaque Manas, uma ferramenta capaz de
apoiar o designer na descrio de sua soluo [Barbosa 2006]. O modelo de arquitetura
proposto composto por uma linguagem de design, utilizada para descrever a
metacomunicao prevista; um interpretador para esta linguagem; e uma base de
conhecimento para armazenar as decises do designer sobre sua soluo. A Manas pro-
pe determinadas dimenses de anlise para motivar a reflexo do designer enquanto
ele descreve a sua soluo. Desta forma, fornece indicadores qualitativos sobre as
decises tomadas, em particular no que tange a potenciais impactos sociais que essas
decises possam ter no grupo de usurios.
6.5.3 EngSem e Sistemas Educacionais
Um importante aspecto no projeto de interfaces de apoio ao aprendizado que vrias
das decises relativas a estratgias de ensino e planos pedaggicos cabem ao educador,
e no ao projetista. Assim, idealmente, o projeto feito por uma equipe composta (no
mnimo) pelo educador e pelo projetista. A implicao disto para a teoria da EngSem
[Prates et al. 2003, Prates 2004] que neste caso a interface uma meta-mensagem con-
junta do educador e do projetista para os alunos. Conseqentemente, o preposto repre-
senta dois emissores distintos, cada um transmitindo a sua soluo para um determinado
aspecto do problema, e estas integradas em um nico discurso.
Para a EngSem, esta co-autoria do projetista e do educador tem uma conseqn-
cia sobre os aspectos em que as ferramentas epistmicas devem apoiar os emissores da
mensagem. Os problemas e espaos de soluo desses emissores so distintos, embora
fortemente relacionados. Por isto, essas ferramentas devem tambm apoiar a comunica-
o entre educador e projetista sobre suas mensagens, a sua integrao, e a reflexo so-
bre a mensagem como um todo.
6.5.4 EngSem e Sistemas de Informao Geogrfica
Sistemas de Informao Geogrfica (SIGs) apresentam desafios interessantes para a
EngSem. So sistemas que manipulam dados e objetos geogrficos, ou seja, dados e
objetos cujas caractersticas inerentes incluem a sua localizao geogrfica. Uma carac-
terstica distintiva dos SIGs de especial interesse para a EngSem o uso de interfaces
baseadas em mapas, parcial ou completamente co-referentes, e em vrias escalas
[Seixas 2004]. Seixas enderea caractersticas especficas desse tipo de sistema, como

a percepo de orientao, de navegao, a identificao de objetos e a interpretao
da simbologia. Ela parte da hiptese que rupturas ou falhas na semiose do usurio,
decorrentes de apresentaes no relacionadas com tarefas e contextos, correspondem a
rupturas no contnuo semitico entre as linguagens de representao ou descrio da
interface. Seixas explora questes interessantes de escalas e abstrao, zoom
inteligente, metforas, e mltiplas representaes. Ela enderea questes como: Como
manter o foco da tarefa durante a interao com mapas? Quais elementos precisam ser
mantidos visveis para que o usurio no se perca? Como modificar a apresentao dos
objetos de modo que o usurio consiga manter a referncia do objeto?. Seu trabalho
aponta ainda para a necessidade de se considerar novas interpretaes para expresses
que representam rupturas na comunicao usurio-sistema de aplicaes tradicionais, e
que devem ser especializadas no contexto de domnios especficos como interfaces
baseadas em mapas.
6.5.5 A EngSem no Cenrio de IHC
Recentemente, a rea de IHC vem ganhando teorias inspiradas na antropologia e na psi-
cologia social, como por exemplo a teoria da atividade [Kaptelinin, Nardi & Macauley
1999] e cognio distribuda [Hollan, Hutchins & Kirsh 2000]. De acordo com de Souza
(2005), essas teorias expandiram consideravelmente o escopo de anlise apoiado pelas
teorias cognitivas tradicionais. Nas palavras de de Souza, elas ofereceram um rico re-
lato da experincia do usurio no mundo, onde a tecnologia computacional est pre-
sente, e expandiram os horizontes dos designers com relao a para quem eles estavam
projetando e por qu. No entanto, nenhuma dessas teorias foi suficientemente clara so-
bre como esses horizontes expandidos se traduzem em produtos de design. O preposto
do designer lhes oferece uma ponte para a natureza de artefatos de base computacional e
uma oportunidade de explorar o contedo e a forma do seu discurso interativo para in-
cluir as dimenses que cada teoria promove como distintiva [ibid.:91-2].
No cenrio internacional, a EngSem teve seu reconhecimento com a publicao
do livro sobre a teoria pela MIT Press [de Souza 2005] e alguns de seus mtodos sendo
publicados em livros bsicos de IHC no exterior [Preece et al. 2007]. No Brasil, a inclu-
so da EngSem como um tpico recomendado para o ensino de IHC na graduao dos
cursos de computao tambm demonstra sua aceitao pela comunidade acadmico-
cientfica nacional. Para saber mais sobre a EngSem, recomendamos acessar o site do
grupo de pesquisa em EngSem, SERG, em http://www.serg.inf.puc-rio.br.
Referncias Bibliogrficas
Adler, P. & Winograd, T. (eds., 1992) Usability: Turning Technologies into Tools. Ox-
ford University Press. New York, NY.
Annett, J ., & Duncan, K. D. (1967). Task analysis and training design. Journal of Oc-
cupational Psychology, 41, 211-221.
Araujo, A. C. I. C. (2005) Mecanismos de Customizao no Ambiente de Discusso
OriOn. Trabalho Final. Departamendo de Informtica, PUC-Rio.
Baecker, R.M. et al. (1995) Readings in Human-Computer Interaction: toward the year
2000. San Francisco: Morgan Kaufmann Publishers, Inc.
Barbosa, S.D.J .; Paula, M.G. (2003) Designing and Evaluating Interaction as Conversa-
tion: a Modeling Language based on Semiotic Engineering. In 10th International

Workshop on Design, Specification and Verification of Interactive Systems, DSV-IS
2003, Madeira Island, J unho 11-13, 2003, LNCS 2844, pp. 1633.
Barbosa, C. M. A. (2006) Uma Ferramenta Epistmica de Apoio ao Projeto da Comu-
nicao em Sistemas Colaborativos. Tese de doutorado. Departamento de Inform-
tica. PUC-Rio. Rio de J aneiro.
Borman, L. (1996) SIGCHI: The Early Years. SIGCHI Bulletin. Vol.28 No.1, J anuary
1996. http://sigchi.org/bulletin/1996.1/borman.html
Carroll, J .M. (2000) Making use: scenario-based design of human-computer interac-
tions. Cambridge, MA: The MIT Press.
Carroll, J . M. (2003) HCI Models, Theories, and Frameworks: Toward a multidiscipli-
nary science. San Francisco Morgan Kaufmann Publishers.
Carroll, J .M.; Mack, R.L.; Robertson, S.P.; Rosson, M.B. (1994) Binding Objects to
Scenarios of Use, International Journal of Human-Computer Studies 41:243-276.
Academic Press.
CFCS (2004) Committee on the Fundamentals of Computer Science: Challenges and
Opportunities, National Research Council. Computer Science: Reflections on the
Field, Reflections from the Field, 208 pages, National Academies Press,
http://www.nap.edu/catalog/11106.html [ltima visita: fev/2007]
CNS - Conselho Nacional de Sade. Resoluo 196/96. Disponvel em
http://conselho.saude.gov.br/resolucoes/1996/Reso196.doc [ltimo acesso:
fev/2007].
de Souza, C. S.; Prates, R. O.; Carey, T. (2000) Missing and declining affordances: Are
these appropriate concepts?. Journal of the Brazilian Computer Society. 1(7): 26-34.
de Souza, C. S. (2005) The Semiotic Engineering of Human-Computer Interaction.
Cambridge, MA: The MIT Press.
de Souza, C.S. & Barbosa, S.D.J . (2006) A Semiotic Framing for End-User Develop-
ment. In: Henry Lieberman et al. (eds.) End User Development, 401-426. The Neth-
erlands: Springer.
de Souza, C. S., Leito, C. F., Prates, R. O., da Silva, E. J . (2006) The Semiotic Inspec-
tion Method. VII Simpsio sobre Fatores Humanos em Sistemas Computacionais,
IHC 2006.
Decreto-Lei 5296 Lei de Acessibilidade. Disponvel em:
http://www.acessobrasil.org.br/index.php?itemid=43). [ltima visita: fev/2007].
Diaper, D. & Stanton, N. (eds., 2004) The Handbook of Task Analysis for Human-Com-
puter Interaction. Mahwah, NJ : Lawrence Erlbaum Associates.
Dourish, P. (2001). Where the action is. Cambridge, MA: The MIT Press.
Eco, U. (1976). The Theory of Signs. Bloomington: Indiana University Press.
Gould, J ., Lewis, C. (1985) Designing for usability: key principles and what designers
think. Communications of the ACM, Volume 28 , Issue 3 , pp 300 311
Grice, H.P. (1975) Logic and Conversation. In Cole & Morgan (eds.) Syntax and Se-
mantics, Speech Acts, vol. 3, 41-58. New York, NY: Acadamic Press.
Hollan, J .E.; Hutchins, D.; Kirsh, D. (2000) Distributed cognition: Toward a new foun-
dation for human-computer interaction research. ACM Transactions on Computer-
Human Interaction 7(2): 174-196.

Houser, N. & Kloesel, C. (1992-1998) The Essential Peirce, Vols. I & II. Bloomington,
IN. Indiana University Press.
J akobson, R. (1960) Linguistics and Poetics. In: Sebeok (ed.) Style in Language, 350-
377. Cambridge, MA: The MIT Press.
Kaptelinin, V.; Nardi, B. & Macauley, C. (1999) The activity checklist: A tool for
representing the space of context. Interactions 6(4): 27-39.
Konstan, J (2007). Presidente do Special Interest Group in Computer Human Interaction
(SIGCHI) da Association of Computing Machinery (ACM). Comunicao pessoal.
Leech, G. (1983) The Principles of Pragmatics. London: Longman.
Leito, C, F. e Dias-Romo, D. (2003). Pesquisas em IHC: um debate interdisciplinary
sobre a tica. Em Nicolaci-da-Costa, A. M. E Leite, J . C. Atas do Workshop sobre
Interdisciplinaridade em IHC, CLIHC 2003.
Moran, T. (1981) The Command Language Grammars: a representation for the user
interface of interactive computer systems. In: International Journal of Man-Machine
Studies 15:3-50, Academic Press.
Nielsen, J . (1993) Usability Engineering. Academic Press.
Nielsen, J . (2000) Test with 5 Users, Alertbox. Disponvel online em
http://www.useit.com/alertbox/20000319.html [ltimo acesso: fevereiro/2007].
Paula, M. G.; Silva, B. S.; Barbosa, S. D. J . (2005) Using an Interaction Model as a Re-
source for Communication in Design. Proceedings of CHI 2005, Extended abstracts
Volume. Portland, OR, USA.
Paula, M.G. (2003) Projeto da Interao Humano-Computador Baseado em Modelos
Fundamentados na EngSem: Construo de um Modelo de Interao. Dissertao de
Mestrado. Departamento de Informtica. PUC-Rio.
Prates, R. O. (1998) A EngSem de linguagens de interfaces multi-usurio. Tese de
doutorado. Departamento de Informtica. PUC-Rio. Rio de J aneiro.
Prates, R. O.; de Souza, C. S.; Barbosa, S. D. J . (2000) A method for evaluating the
communicability of user interfaces. Interactions. 7(1): 31-38
Prates, R. O., Barbosa, S. D. J . (2003) Avaliao de Interfaces de Usurio - Conceitos e
Mtodos. J ornada de Atualizao em Informtica, SBC.
Prates, R. O.; Figueiredo, R. M. V. de; Bach, C. F. (2003) Um Modelo de Apoio ao
Projeto de Design de Interfaces de Ambientes de Aprendizado. Anais do WIE, SBC,
2003. V.541- 552.
Prates, R. O. (2004) A EngSem para o Domnio Educacional, Atas da Oficina Design
e Avaliao de Interfaces para Ambientes Educacionais organizado no IHC 2004.
(Disponvel em http://www.ime.uerj.br/~raquel/WIEd).
Preece, J .; Rogers, Y.; Sharp, H.; Benyon, D.; Holland, S.; Carey, T. (1994) Human-
computer interaction. Reading, MA. Addison-Wesley.
Preece, J .; Rogers, Y.; Sharp, E. (2002) Interaction Design: Beyond Human-computer
Interaction. New York, NY: J ohn Wiley & Sons, 1
st
edition.
Preece, J .; Rogers, Y.; Sharp, E. (2007) Case Studies in Website material for Interaction
Design: Beyond Human-computer Interaction Website . New York, NY: J ohn Wiley
& Sons, 2
nd
edition. Disponvel em: http://www.id-book.com/casestudy_14-1.htm
[ltima visita em fevereiro de 2007].

Preece, J .; Rogers, Y.; Sharp, E.; Benyon, D.; Holland, S.; Carey, T. (1994) Human-
Computer Interaction. Harlow, England: Addison-Wesley.
Rosson, M.B. & Carroll, J .M. (2002) Usability Engineering: scenario-based develop-
ment of human-computer interaction. San Francisco, CA: Morgan Kaufmann.
Schn, D.A. (1983) The Reflective Practitioner. New York, NY: Basic Books.
Schn, D. and Bennett, J . (1996). Reflective conversation with materials. In Winograd,
T. (ed.) Bringing design to software. New York, NY. Addison-Wesley. Pp. 171-184.
Seixas, M. L. A. (2004) Um Mtodo de Avaliao para Interfaces Baseadas em Mapas.
Tese de Doutorado. Departamento de Informtica. PUC-Rio. 2004.
Sellen, A.; Nicol, A. (1990) Building User-Centered On-line Help. In Laurel, B. The Art
of Human-Computer Interface Design. Reading: Addison-Wesley.
Shneiderman, B., Plaisant, C. (2005). Chapter 1: Usability of Interactive Systems. In
Designing the User Interface. Addison Wesley.
Silva, B.S. (2005) MoLIC Segunda Edio: reviso de uma linguagem para modelagem
da interao humano-computador. Dissertao de Mestrado. Departamento de In-
formtica. PUC-Rio. 2005.
Silva, B.S. & Barbosa. S.D.J . (2007) Designing Human-Computer Interaction With
MoLIC Diagrams A Practical Guide. In C.J .P. Lucena (ed.) Monografias em Cin-
cia da Computao. Departamento de Informtica. PUC-Rio. 2007.
Silva, B. S.; Barbosa, S. D. J . (2004) Modelando a Interao do Nita: um estudo de caso
e extenses ao MoLIC. Anais do VI Simpsio sobre Fatores Humanos em Sistemas
Computacionais, IHC 2004. Curitiba, outubro de 2004.
Silveira, M.S. (2002) Metacomunicao Designer-Usurio na Interao Humano-Com-
putador. Tese de Doutorado. Departamento de Informtica. PUC-Rio.
Silveira, M.S. (2007) Relatrio do Grupo de Discusses sobre Currculo de IHC. VII
Simpsio sobre Fatores Humanos em Sistemas Computacionais, IHC 2006. Dispon-
vel em: http://www.sbc.org.br.
Silveira, M.S.; Barbosa, S.D.J .; de Souza, C.S. (2004) Designing online help systems
for reflective users. In: J ournal of the Brazilian Computer Society, J BCS, vol. 9,
No. 3, abril de 2004. pp.25-38.
Tesoro Software Student Life Product. Student Life v. 3.0 Disponvel em:
http://www.tesorosoft.com/studentlife.htm [ltima visita: fev/2007]
Vanderheiden, G. (2000) Fundamental Principles and Priority Setting for Universal Us-
ability. Conference on Universal Usability. Pages 32-38.
W3C Web Acessibility Initiative. Disponvel em: http://www.w3.org/WAI [ltima
visita: fev/2007]


JAI2007 PratesBarbosa EngSem PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

JAI2007 PratesBarbosa EngSem PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Captulo

Anda mungkin juga menyukai