5
Métodos e Técnicas da Pesquisa
5.1
Delimitação da Pesquisa
5.1.1
Problema
O problema da pesquisa é o desenvolvimento de soluções confusas,
principalmente na navegação e na interação entre os elementos, ou seja, na
Arquitetura da Informação. Percebe-se, com isso, que os usuários têm
dificuldades para localizar a informação pretendida, gerando prejuízos em
termos de eficiência (aumento do tempo de execução da tarefa) e efetividade
(aumento do índice de não-completude da tarefa).
É importante destacar os vários aspectos levantados na pesquisa que
figuram hoje, potencializando ainda mais essa questão, como veremos a seguir.
5.1.1.1
A freqüente inovação tecnológica
Se no início os computadores eram usados por uma categoria específica
de usuários – pessoas da área de tecnologia que entendiam de computação e
até mesmo programação, hoje pessoas de qualquer profissão e estilo fazem
uso dessa poderosa ferramenta (HELANDER et al, 1997). E para que esta
ferramenta possa atender a todos, desenvolveu-se um único dispositivo que
pudesse atender aos mais diversos fins: o PC (private computer).
NORMAN (2002) aponta o problema de que o PC tenta fazer todas as
coisas para todas as pessoas. “É um dispositivo: o mesmo design tanto para
hardware e software feito para atender a todo mundo; uma mesma máquina
para fazer todas as tarefas e atividades que qualquer pessoa deseje.” Como
Métodos e Técnicas da Pesquisa 83
resultado, não existe foco. Significa que precisa servir a todos, direcionando um
grande número de novos atributos, um grande número de novas aplicações
específicas, e gerando como resultado, um grande número de complexidade.
5.1.1.2
A internet como nova mídia de comunicação individual e universal
O problema da internet é semelhante ao dos computadores: iniciada
como um sistema de uso restrito para uma população igualmente específica,
hoje ela está totalmente difundida para as mais diversas necessidades. Seja
para pesquisa, trabalho ou entretenimento, pessoas de diversas culturas e
classes sociais, profissões e faixa etária, acessam os mais diversos websites
com os mais diversos fins (HELANDER et al, 1997). Isso é observado pelo
rápido crescimento da mídia. Conforme aponta CALDAS (2002), “todos os
meses, cerca de 30 mil novos sites nascem na Internet brasileira, o que gera
ainda mais problemas para os navegantes”. Segundo o autor, o número de sites
existentes influenciaria a própria usabilidade da rede, confundindo os usuários.
Frente a essa diversidade, observa-se também que na Web a experiência
do usuário se torna ainda mais importante do que em outros tipos de mídia.
Conforme aponta GARRETT (2003), nesta mídia “só existe o usuário sozinho
frente ao site, apenas com seu bom senso e experiência para guiá-lo”. A
despeito disso, segundo NIELSEN (2002), ainda hoje encontramos problemas
com relação a extravagâncias da mídia, excesso no design e sites orientados
por modismos que contradizem tudo o que se sabe sobre comportamento do
usuário.
Segundo SILVA e AGNER (2003), estamos na Sexta Geração da internet
quando, depois de todo o processo evolutivo da mídia com relação a recursos e
avanços tecnológicos, nos defrontamos com a valorização da estratégia de
negócio. Muitos recursos têm sido investidos na facilitação do uso pelo fato de
estar-se percebendo que a má usabilidade acarreta prejuízos.
Métodos e Técnicas da Pesquisa 84
5.1.1.3
O processo de construção de um website
Infelizmente, boa parte dos websites ainda carrega o problema inicial da
própria internet: construídos por e para programadores. Soma-se a isso o fato
de que “tradicionalmente a preocupação com a usabilidade só ocorre no final
do ciclo de design, durante a avaliação do produto já finalizado. Resultando,
dessa forma, em poucas modificações consideradas e realizadas em virtude do
alto custo em alterar partes substantivas do produto” (MORAES E
MONT´ALVÃO, 2000). Os usuários, por sua vez, encontram dificuldade em
entender como as informações foram dispostas ali e se atrapalham ao executar
a navegação pelo site.
É curiosa também a observação feita por COOPER (1999) de que os
programadores acabam por fazer o “design” dos produtos que estão
desenvolvendo, considerando essa etapa a mais “divertida” do processo. O que
entendem por design é distorcido e isso acaba acarretando sérios problemas
de usabilidade (COOPER, 1999).
GOODWIN (2003) alerta que os executivos que lideram iniciativas
tecnológicas acreditam que eles sempre conseguem o design interativo
gratuitamente dos seus programadores. Para eles, ter designers interativos é
desnecessário; se acontecer de um produto ficar difícil de usar, eles assumem
que os programadores precisam apenas de um treinamento de sensibilidade. E
acrescenta: “O problema com programadores realizando este trabalho é que
eles não pensam como outras pessoas. De fato, programadores pensam tão
diferente que eles são como espécies separadas. Alan Cooper chama-os de
Homo logicus.”
5.1.1.4
Problemas de Navegação e Arquitetura da Informação
Segundo REISS (2000), “visitantes ficam frustrados ao deixarem um
website porque os designers simplesmente não organizam o conteúdo numa
maneira conveniente para eles.” Para ROSENFELD and MORVILLE (1998), os
usuários desejam encontrar a informação rápida e facilmente e não gostam de
se perder em sites hipertextuais caóticos. “Arquitetura da Informação pobre
torna usuários ocupados confusos, frustrados e zangados”, fazendo com que
Métodos e Técnicas da Pesquisa 85
encontrem dificuldades em entender como as informações foram dispostas ali
e se atrapalham ao executar a navegação pelo site.
PADOVANI (2002) aponta alguns estudos sobre usabilidade de sistemas
hipertextuais demonstrando que a maioria dos problemas enfrentados pelos
usuários se refere “às dificuldades de navegação que geram acionamentos
inadvertidos, acesso a telas que não interessam ao usuário, desorientação e o
conseqüente sub-aproveitamento dos recursos de navegação não-linear dentro
do sistema”.
Não apenas usuários finais, como também Gerentes de Conteúdo sofrem
com websites e intranets complicadas. ROSENFELD e MORVILLE (1998)
definem os Gerentes de Conteúdo como os profissionais que “descrevem uma
visão temporal, mostrando como a informação pode fluir dentro, em torno e
fora do mesmo sistema.” Para os autores, são eles que lidam com assuntos de
posse de conteúdo e da integração de políticas, processos e tecnologias para
suportar o ambiente dinâmico de publicação. Segundo REICHENAUER e
KOMISCHKE (2003), o “Gerente de Conteúdo pode ser definido como a pessoa
responsável pela preparação, avaliação, organização, publicação, manutenção e
armazenamento do conteúdo para um website ou intranet”.
Os autores alertam que “usuários finais não conseguem encontrar
efetivamente o conteúdo que procuram e Gerentes de Conteúdo não
conseguem gerenciar efetivamente o conteúdo (baixa efetividade), ou ambos
apenas conseguem ter sucesso com muito esforço (baixa eficiência)”. Com isso
os prejuízos são enormes: negócios não são realizados; problemas como o não
encontro da informação aumentam (decisões erradas, trabalho duplicado, perda
de consumidores); elevação de custos de manutenção, suporte, treinamento e
hardware. Os autores perceberam em seu estudo que os problemas
experenciados pelos usuários finais e Gerenciadores de Conteúdo diariamente
estão, na maioria das vezes, relacionados a sistemas de Arquitetura da
Informação deficientes.
5.1.1.5
As empresas e o investimento em atributos tangíveis
Por mais que algumas empresas sejam completamente altruístas, elas
normalmente querem saber o retorno do seu investimento em usabilidade e
Métodos e Técnicas da Pesquisa 86
arquitetura da informação; em outras palavras, o que esperar disso. Segundo
NIELSEN (1998 e 2003), o investimento nesse serviço não é como investir num
fundo de ações. Não é possível calcular exatamente os números para mostrar
os benefícios do investimento em melhorias na usabilidade. Apesar disso, é
possível demonstrar o valor do investimento através de alguns significados
científicos, com alguns números não tão precisos. Para o autor, nos cerca de
90% dos sites comerciais com muito baixa usabilidade, o web design
insatisfatório acarretaria uma série de custos para as empresas, entre eles:
Perda de aproximadamente 50% das vendas estimadas, já que os clientes
não conseguem encontrar os produtos ou informações;
Perda de 40% dos clientes, em um eventual retorno ao site, devido ao
resultado negativo da primeira visita.
NIELSEN (2003) coloca que para as empresas “custos de projetos são
medidos em dinheiro, e usabilidade é mensurada em melhoria de uso, uso mais
eficiente ou alto nível de satisfação do usuário.”
“Converter a melhoria da usabilidade em dinheiro é fácil para o e-commerce, onde o dobro de vendas possui um valor imediato. Para intranets, ganhos com produtividade também são fáceis de converter em estimativas monetárias: simplesmente multiplique o tempo ganho pelo custo/hora de seus empregados. Outros tipos de projetos de design são mais complicados de converter num ROI (return of investiment) exato. Qual é o valor de aumentar a satisfação do cliente? De aumentar o tráfego ou melhorar o uso das funções desejadas no seu site? Essas estimativas variam entre as empresas e, portanto, o valor monetário da melhoria na usabilidade também varia. Mas será substancial na maioria das vezes.”
Jakob Nielsen, 2003 REISS (2000) apresenta dados americanos publicados na Revista Time do
mesmo ano, sobre utilização de bancos on-line: durante o período de julho de
1998 a julho de 1999, 3.2 milhões de pessoas abriram contas de banco on-line
nos EUA. Todavia, durante este mesmo período, 3.1 milhões de americanos
fecharam suas contas de e-bank. Metade das pessoas que saíram explicaram
que elas estavam insatisfeitas com o serviço de atendimento ou achavam que
os sites eram muito complicados. Segundo o autor, investimentos em
Arquitetura da Informação teriam ajudado a evitar esse terrível problema para o
negócio.
É importante ressaltar que a preocupação tardia com a usabilidade de
web sites, o redesign, segundo ROSENFELD e MORVILLE (1998), impacta em
Métodos e Técnicas da Pesquisa 87
todos os outros aspectos de um website, das barras de navegação gráficas ao
conteúdo propriamente dito, e isso poderá sair muito mais caro mais à frente.
5.1.1.6
A onipresença do computador
Segundo COOPER (1999), a “comunicação pode ser precisa e exata ainda
que esteja tragicamente errada”. Para o autor isso acontece muito
freqüentemente quando nos comunicamos com computadores e na medida
em que eles invadem todos os aspectos de nossa vida moderna.
MORAES E FRISONI (2001) apontam que as mudanças na tecnologia
desmancharam as linhas entre estas partes do produto, de tal modo que não é
mais útil pensá-las como entidades separadas. “A linha entre hardware e
software tende a apagar-se. Produtos que pensávamos como máquinas
transformaram-se em computadores. Telefones, televisão e equipamentos
médicos agora apresentam mostradores ou telas com menus. (...) Designers,
ao criarem novos produtos, devem responder a perguntas como ‘Quais são as
melhores palavras e símbolos para colocar na tela? Em que ordem devo
organizá-los? Há uma metáfora adequada?´” (DUMAS e REDISH, 1994 apud
MORAES e FRISONI 2001).
Para COOPER (1999) “computadores difíceis de usar afetam a todos nós,
algumas vezes até de forma fatal. Produtos baseados em software não são
intrinsicamente difíceis de usar; eles são desta forma porque nós praticamos o
processo errado para desenvolvê-los”.
5.1.2
Hipótese
O trabalho de desenvolvimento de websites é feito sob a ótica dos
desenvolvedores, que muitas vezes desconhecem os requisitos de usabilidade
e os modelos mentais dos usuários. Por isso, as soluções de Arquitetura da
Informação encontradas são deficientes, dificultando a navegação e busca de
informações pelos usuários.
Métodos e Técnicas da Pesquisa 88
5.1.3
Variáveis
Variável Independente:
• Trabalho de desenvolvimento de websites pela ótica dos
desenvolvedores.
Variável Dependente:
• Deficiências das soluções de Arquitetura da Informação que dificultam a
navegação e busca por informações pelo usuário
Variáveis Intervenientes:
• Aspectos gerais do usuário: experiência com computadores, nível de
conhecimento do assunto, prática de uso na internet etc.
• Aspecto específico do usuário: prática de uso de websites universitários.
5.1.4
Justificativa
Infelizmente, grande parte do trabalho de desenvolvimento de sites é feito
por projetistas de sistemas, que acabam por usar muito poucas informações
externas para desenvolver seus produtos. Essa premissa leva a conclusão que
as dificuldades identificadas pelos usuários são causadas pelo caráter
extremamente técnico do desenvolvimento do produto, que muitas vezes utiliza
soluções tecnológicas de última geração.
5.1.5
Objetivo
Facilitar o uso da internet, tornando-a uma ferramenta transparente para o
usuário, de forma que as informações desejadas sejam encontradas amigável e
facilmente.
Vale ressaltar também que uma das principais preocupações em lidar
com o entendimento do processo de interação humano-computador, segundo
Métodos e Técnicas da Pesquisa 89
HELANDER et al (1997) “é exercer alguma influência não apenas no
desenvolvimento contínuo da tecnologia – melhorar sua utilidade e usabilidade
– mas também, e talvez mais importante, para ajudar a aumentar as chances de
que isso será posto em uso tanto nos construtos como para os humanos”.
5.1.6
Recorte da Pesquisa
A pesquisa aborda a parte central do processo de desenvolvimento de
websites apresentado por GARRETT (2003). Ao que o autor chama de “Os
Cinco Planos” (Figura 10), que dividem este trabalho em componentes para
facilitar o entendimento do problema como um todo; cabe à Estrutura “definir
como os usuários chegam a uma página e onde ele pode ir quando tiver
finalizado aquela”. Sendo cada plano “dependente do plano abaixo dele”, parte-
se, na presente pesquisa, do escopo dos sites analisados, focando apenas na
estruturação dessas informações e partindo-se da premissa de que o escopo
levantado já teria sido obtido baseado na Estratégia dos sites analisados.
Embora seja no esqueleto que surjam as definições de design que
realizam e exibem na interface a estrutura do site, a presente pesquisa não
abordará este item. O trabalho pretende exaurir os problemas encontrados na
estrutura dos websites, traçando recomendações que servirão de fundamento
para o design da interface.
Da mesma forma, a superfície ou interface não será
analisada no presente trabalho por (1) não ser o foco do
problema abordado e (2) pressupor uma continuidade do
trabalho, visando novos aspectos e abordagens que não
caberiam no escopo do Mestrado. Poderia vir a ser uma
pesquisa seqüencial a esta, de forma que fossem analisados
os fatores e elementos gráficos que colaboram e/ou
atrapalham o entendimento e, portanto, a navegação do
usuário pela estrutura de um website.
Figura 10: Os cinco Planos
de GARRETT (2003)
Métodos e Técnicas da Pesquisa 90
5.1.7
Escolha do Estudo de Caso
Buscou-se para realização da pesquisa, um estudo de caso que
contivesse uma grande gama de informações para usuários com interesses e
conhecimentos distintos, a fim de obter-se uma análise representativa de
Arquitetura da Informação. Também como forma de facilitar o processo, uma
vez que a pesquisa foi feita dentro de uma universidade, foram escolhidos
como estudo de caso sites de universidades. Para diminuir o universo e tornar
possível a realização da pesquisa, restringiu-se a escolha das universidades à
cidade do Rio de Janeiro, dentro dos seguintes critérios:
• Deveria ser eleita uma Universidade de cada categoria (Pública,
Confessional e Particular);
• As Universidades deveriam ter obrigatoriamente curso de Design em seu
currículo;
• Se ainda assim houvesse duplicidade, o critério de tempo de curso
deveria ser adotado, ficando a escolha com a Universidade que tivesse o
curso de design há mais tempo no currículo.
Desta forma as Universidades selecionadas foram:
• Universidade Estadual do Rio de Janeiro;
• Pontifícia Universidade Católica do Rio de Janeiro;
• Centro Universitário da Cidade (UniverCidade).
Métodos e Técnicas da Pesquisa 91
5.2
Métodos e Técnicas
A presente pesquisa foi feita em quatro etapas, utilizando-se métodos
específicos em cada uma:
1. Buscou-se perceber o que pensam os desenvolvedores sobre a construção de um
website universitário e, de outro lado, a experiência vivida pelos usuários em sites
desta natureza através de Pesquisa Exploratória;
2. Buscou-se conceber a Arquitetura da Informação de um website universitário
através da Ergonomia Participativa:
2.1. Eliciando o Modelo Mental dos usuários com relação à organização e
agrupamento da informação – Método Card Sorting;
2.2. Conhecendo a tarefa de navegação e mapeando seus fluxos – Método
Bridge;
3. Buscou-se avaliar a Arquitetura da Informação dos sites selecionados no
estudo de caso através da Análise Ergonômica da Tarefa;
4. Comparou-se os resultados dos métodos da Etapa 2 com a Arquitetura da
Informação encontrada nos websites universitários selecionados como
estudo de caso, utilizando-se a Avaliação de Especialistas.
5.2.1
Primeira Etapa
Na primeira etapa fez-se uma Pesquisa Exploratória no sentido de
explicitar-se o problema levantado e obter-se informações relevantes que
atestassem a validade da hipótese. Foi feita uma entrevista semi-estruturada
onde “o informante, seguindo espontaneamente a linha de seu pensamento e
de suas experiências dentro do foco principal colocado pelo investigador,
começa a participar da elaboração do conteúdo da pesquisa” (TRIVIÑOS, 1987).
A entrevista semi-estruturada pode ser definida como uma técnica em
que o pesquisador formula perguntas ao entrevistado para obter dados que
refutem ou comprovem suas hipóteses e predições. O método foi utilizado
neste ponto exatamente como forma de comprovar o fundamento da hipótese
da pesquisa.
Realizaram-se duas entrevistas semi-estruturadas, junto aos
desenvolvedores de um lado e aos usuários de outro, “partindo de certos
Métodos e Técnicas da Pesquisa 92
questionamentos básicos, apoiados em teorias e hipóteses que interessam a
pesquisa.”
A.) Desenvolvedores: Foram entrevistados onze desenvolvedores de
sistemas web (especificamente programadores e analistas de sistemas),
para conhecer o seu processo de trabalho ao elaborar um site universitário
hipotético. Foi pedido a eles que narrassem o processo e listassem suas
principais preocupações na hora de construir a árvore semântica do site.
B.) Usuários: Foram entrevistados dez estudantes universitários (graduados e
graduandos), de 22 a 37 anos, que já tivessem efetuado um trabalho de
busca por um artigo publicado na internet. Os entrevistados deveriam
listar suas principais dificuldades durante o processo de pesquisa.
5.2.2
Segunda Etapa
Na segunda etapa, através da Ergonomia Participativa, buscou-se conceber
a Arquitetura da Informação de um website universitário.
Utilizaram-se as abordagens para o processo de Arquitetura da Informação
apontadas por REICHENAUER e KOMISCHKE (2003), GARRET (2003) e
ROSENFELD E MORVILLE (2002) (Capítulo 2). Segundo os autores, uma
abordagem De Baixo para Cima é baseada na análise dos requisitos do
conteúdo, “focando em como este pode ser descrito por características
inerentes a cada unidade de informação, no sentido de determinar a
organização do conteúdo total do website”. Já a abordagem De Cima para
Baixo envolve criar a arquitetura diretamente de um entendimento dos objetivos
do site e das necessidades dos usuários.
Buscou-se nesta etapa, portanto, entender o processo de Arquitetura da
Informação para se ter os elementos adequados sob as duas abordagens,
dividindo-a então, nos dois momentos.
Os métodos selecionados para esta segunda etapa forma extraídos da
Ergonomia Participativa. Segundo SHNEIDERMAN (1998), a Ergonomia
Participativa (ou Design Participativo) sugere que o maior envolvimento de
usuários traz informação mais precisa sobre tarefas. Deve-se levar em
consideração o efeito da interface no usuário, e deve-se solicitar sua
participação para “garantir que todas as preocupações estão se revelando cedo
Métodos e Técnicas da Pesquisa 93
o bastante para evitar esforços contraprodutivos e resistências de mudança”.
NIELSEN (1993) coloca que “usuários sempre levantam questões que o time de
desenvolvimento não teriam sonhado em perguntar”. Mas, por outro lado,
alerta que “usuários não são designers, então não é racional que se espere
deles que venham com idéias de design a partir de rabiscos”. “É importante
perceber que um design participativo não consiste em perguntar aos usuários o
que eles querem, uma vez que eles não sabem o que querem ou precisam, ou
que possibilidades existem.” Isso porque os usuários só percebem a real
utilidade de um atributo depois que realmente lidam com ele. Eles não são
capazes de abstraí-lo.
5.2.2.1
Abordagem De Baixo para Cima
Num primeiro momento, buscou-se eliciar o conhecimento a respeito do
Modelo Mental de usuários com relação à organização e agrupamento da
informação (abordagem De Baixo pra Cima) nos websites estudos de caso.
Selecionou-se o método Card Sorting que, segundo NIELSEN (1993),
ROSENFELD e MORVILLE (1998 e 2002) e PADOVANI (1998), “é uma técnica
comumente utilizada para prover conhecimentos sobre os modelos mentais
dos usuários a respeito de informações espaciais”. O método, então, pareceu
ser bastante efetivo, por permitir o conhecimento do que está na cabeça do
usuário com relação ao agrupamento e nomenclatura dos itens contidos num
site universitário.
A técnica Card Sorting consiste em uma variação da técnica original
proposta por ANTER et al (1985 apud PADOVANI, 1998): Multiple Sorting Tasks.
Para aplicação do método, utilizam-se cartões selecionados, apresentando
vários conceitos dentro de algumas categorias. Segundo ROSENFELD e
MORVILLE (2002), a técnica pode ser aplicada desde totalmente aberta –
quando os usuários escrevem seus próprios cartões e rótulos, além de
organizá-los posteriormente, – até totalmente fechada – os usuários recebem
os cartões e categorias já previamente rotulados, devendo apenas organizá-los.
O método utilizado nesta pesquisa foi o parcialmente fechado, uma vez que os
sujeitos receberam os cartões previamente marcados, com os rótulos
Métodos e Técnicas da Pesquisa 94
levantados, e puderam criar outros ou alterar os existentes conforme suas
necessidades.
ROBERTSON (2001) afirma que o método ajuda a organizar a informação,
de forma que seja útil e significativa para os usuários do sistema. “Mesmo que
investigações e análises cuidadosas da informação possam revelar algumas
pistas, pode ser virtualmente impossível determinar quais tópicos devem ser
agrupados juntos.” Na maioria das vezes, a dificuldade em organizar o conteúdo
deriva de uma ausência de conhecimento sobre como usuários reais farão uso
dessa informação. Segundo o autor, uma seção de Card Sorting ajuda a
resolver esses problemas.
Embora os autores REICHENAUER e KOMISCHKE (2003) tenham citado o
Card Sorting como um método de Engenharia de Usabilidade aplicado numa
abordagem De Cima pra Baixo, aqui o método foi utilizado na abordagem De
Baixo pra Cima. Ao afirmar que a abordagem De Baixo pra Cima ajuda “para
organização da informação objetiva e imparcial, baseada principalmente nas
características inerentes à informação em si”, os autores acabam por se
confundir no posicionamento do Card Sorting.
O método enfoca muito mais a organização da informação contida nos
sites universitários avaliados, uma vez que levanta todo o seu conteúdo e
organiza as informações baseadas pura e simplesmente no que os usuários
pensam sobre “as características inerentes à informação em si”.
ROBERTSON (2001) acrescenta que o Card Sorting não encerra o trabalho
de estruturação do conteúdo e que devem ser considerados vários outros
aspectos como requerimentos do negócio, direcionamentos estratégicos,
objetivos e limitações técnicas e guidelines de usabilidade. Porém o método é
uma excelente forma de se iniciar este trabalho, visto que ele irá informar como
usuários reais pensam. O autor aponta alguns benefícios do método:
• Simples e fácil de ser entendido;
• Barato de usar;
• Rápido de aplicar (o único acréscimo é o tempo de preparação);
• Ele esboça agrupamentos naturais de informação numa forma que evita
questionamentos diretamente aos usuários;
• Envolve os usuários no processo de design e ajuda a demonstrar que o
sistema será criado com as necessidades dos usuários em mente.
Métodos e Técnicas da Pesquisa 95
Levantamento de Itens para Aplicação do Teste
Foram levantados todos os itens contidos nos três sites – considerando-
se sempre tópicos que englobassem conceitos e/ou levassem a outros tópicos
– eliminando-se duplicidade e/ ou itens que correspondessem ao mesmo
assunto. Como pode ser observado nas figuras 12 e 14, procurou-se os mapas
de navegação dos próprios sites. Quando não existia, utilizaram-se as
ferramentas de navegação do site (Figura 12). Procurou-se utilizar os mesmo
nomes (rótulos) dados nos sites de origem ou, quando houveram duplicidades,
utilizou-se o rótulo mais comum. Chegou-se desta forma a 80 itens no total (Ver
Anexos). Esses itens foram dispostos em 80 cartões idênticos (3’’ x 5’’ em
papel branco) e entregues a 5 usuários, conforme recomendado por NIELSEN
(1993).
Figura 11: Mapa de navegação do site da Universidade Estadual do Rio de Janeiro
Métodos e Técnicas da Pesquisa 96
Figura 12: Exibição dos itens levantados no site da UniverCIdade, já que este não possui mapa de
navegação
Figura 13: Mapa de navegação do site da Universidade PUC-Rio
Métodos e Técnicas da Pesquisa 97
Os últimos acessos aos 3 sites usados como estudo de caso ocorreram
no dia 20 de agosto de 2003. Do início da pesquisa até esta data os três sites
mantiveram-se sem alterações em suas estruturas.
Seleção de Sujeitos
Participaram do Card Sorting 5 usuários de sites universitários que faziam
consultas freqüentes a este tipo de site. Todos eram pesquisadores
(mestrandos ou pré-mestrandos) e freqüentavam sites de universidades para
busca de artigos ou informações acadêmicas, público-alvo dos sites de
Universidade, portanto.
Segundo NIELSEN (2000), consegue-se os melhores resultados de testes
de usabilidade, utilizando-se somente 5 usuários.
Ao se coletar dados de um único usuário, as percepções disparam e já se aprende quase um terço de tudo que há para conhecer sobre a usabilidade do projeto. Ao testar o segundo usuário, se descobrirá que esta pessoa faz algumas das mesmas coisas que o primeiro usuário, tendo, então, repetição no que é aprendido. Contudo, as pessoas são definitivamente diferentes e, portanto, terá algo novo que o segundo usuário faz que não se observou com o primeiro, adicionando assim novas observações, porém não tanto quanto fez o primeiro usuário. Ao aumentar-se o número de usuários, aprende-se cada vez menos, porque estão sendo observadas repetidas vezes as mesmas coisas. Após o quinto usuário, o pesquisador estará desperdiçando o seu tempo, observando os mesmos achados repetidas vezes e aprendendo pouco ou nada de novidade.
Jakob Nielsen, 2000
Em seu artigo, NIELSEN e LANDAUER (1993) demonstram que o número
de problemas de usabilidade descobertos em tese de usabilidade com n
usuários é:
N(1-(1-L )n )
Onde N é o número total de problemas de usabilidade no projeto e L a
proporção de problemas de usabilidade descobertos ao testar um único
usuário. O valor típico de L é 31%, tomando a média de um grande número de
projetos estudados. A curva para L = 31% fornece o seguinte resultado (Gráfico
01):
Métodos e Técnicas da Pesquisa 98
Gráfico 01: Gráfico que exibe curva de problemas de usabilidade encontrados de acordo com o
número de usuários testados
Aos participantes foram entregues os 80 cartões e foi pedido que os
organizassem em grupos por conceitos semelhantes, utilizando os próprios
cartões para rotular esses grupos ou utilizando cartões em branco para escrever
os rótulos desejados para cada grupo. Os grupos poderiam ser organizados
como sub-grupos, formando grupos maiores, de acordo com a relação
entendida pelos participantes. Cartões que contivessem itens indesejados ou
considerados inúteis ou duplicados pelos usuários, poderiam ser deixados de
lado.
Ferramenta de Análise dos Dados
Para análise dos dados foi utilizado o conjunto de softwares da IBM
(Developer Works – Card Sorting and Cluster Analysis) próprio para Card
Sorting: USort UZCalc. O pacote foi encontrado no site IBM Developer Works
(http://www.ibm.com/developerWorks).
Os 80 itens foram transferidos para o software USort e os grupos
atribuídos pelos participantes armazenados ali individualmente pelo nome de
cada um. O USort não foi adotado para uso pelos participantes visto que se
eles “não forem familiarizados com a estrutura de computadores, isso poderá
afetar o resultado” (MYER). Além disso, a própria interface do software poderia
induzir a resultados já que mostra uma estrutura vertical, sugerindo uma
Métodos e Técnicas da Pesquisa 99
hierarquia de informações – coisa que não foi solicitada aos participantes.
Qualquer tipo de conclusão com relação a organização foi deixada por conta
dos usuários com a utilização de Low Technique (cartões em papel), como
proposto por NIELSEN (1983).
O UZCalc utiliza os dados armazenados no USort e, através de uma matriz
de distância/agrupamento, faz o cálculo levando em consideração a
porcentagem de vezes que um cartão não foi agrupado com cada um dos
outros cartões. Essa porcentagem é expressa em números entre 0.0000 (itens
agrupados 100% das vezes) e 1.0000 (itens não agrupados 100% das vezes). O
software apresenta os resultados em diagramas, de três formas:
• Único: o algoritmo de ligação enfatiza similaridades
• Completo: algoritmo enfatiza diferenças
• Médio: provém de uma média dos dois anteriores
O diagrama em árvore é uma representação visual da matriz de
distância/agrupamento. Exatamente como na matriz, a relação entre pares é
indicada como um número de 0.00 (indicando que 100% dos participantes
agruparam os dois conceitos) e 1.00 (0% dos participantes agruparam os dois
conceitos). Quanto mais perto da pontuação 0.00, mais forte é a relação entre
os itens pares.
Para mostrar a relação entre dois itens no diagrama em árvore, é traçada
uma linha de um item para o seguinte. Uma barra vertical mais à direita une
grupos que representam a distância ou relação entre eles em pontos. O
diagrama mostra ainda a árvore separada em barras de cores diferentes, que
apresentam grupos sugeridos em alto nível.
Esses grupos são sugeridos a partir da aproximação de percentuais
padrão (.30 e .70). O percentual mínimo indica subgrupos dentro de um grupo
maior. Cada subgrupo é denotado por uma linha de cor diferente e indica que
os participantes relacionaram os itens em subgrupos mais próximos.
Quando um item é deixado de lado pelos participantes, ele é
representado no diagrama da seguinte forma: Ouvidoria (3/5). O que significa
que dois participantes excluíram este item.
Métodos e Técnicas da Pesquisa 100
5.2.2.2
Abordagem De Cima para Baixo
No segundo momento, buscou-se conhecer o comportamento e
necessidades dos usuários, a tarefa de navegação, mapeando os fluxos
apontados. Selecionou-se o método Bridge, desenvolvido por DAYTON,
MCFARLAND e KRAMER e apresentado por WOOD (1998).
Segundo WOOD (1998), “por definição, técnicas de design centrado no
usuário focam em usuários potenciais (incluindo suas características, suas
tarefas e seus ambientes) de quem o trabalho deve ser apoiado por uma
aplicação”. Desta forma, requisitos funcionais serão desenvolvidos a partir da
perspectiva dos usuários e são tratados como requisitos do usuário.
Figura 14: Atividades Típicas num processo de design centrado no usuário
Muito já existe pesquisado e publicado a respeito de técnicas e métodos para cada uma das atividades acima. Enquanto existem algumas excelentes fontes de informação em design de interfaces, nenhuma contém descrições específicas de como um designer transforma a informação adquirida sobre os usuários e seu trabalho em um design de interface efetivo. Este abismo está indicado na Figura 11 pela interrogação marcada entre a Especificação dos requerimentos do usuário e o Design da Interface. Alguns podem argumentar que isso é esperado porque este processo é extremamente criativo e, por natureza inexplicável. Mesmo que isso possa ser verdade num sentido limitado, o design não aparece como mágica. Ele é largamente resultado de um processo pensado, consciente. O autor chama essa passagem de “bridging the gap” (fazendo uma ponte sobre o abismo).
WOOD, 1998 O autor apresenta uma série de métodos que possuem méritos relativos
e condições apropriadas de aplicação. Na maioria dos casos, o autor descreve
essa transformação num contexto de metodologia usada com um projeto de
design específico. Enquanto os projetos, o processo e os métodos variam
consideravelmente, o tema comum é a construção da ponte entre os
Métodos e Técnicas da Pesquisa 101
Requisitos do Usuário e o Design da Interface. Dentre os métodos
apresentados, o método Bridge pareceu o mais preciso para uma análise De
Cima para Baixo do processo de Arquitetura da Informação, visto que foca na
tarefa do usuário.
Como já foi dito anteriormente, de acordo com REICHENAUER e
KOMISCHKE (2003), a abordagem De Cima pra Baixo do processo de
Arquitetura da Informação para o desenvolvimento do sistema de navegação de
websites se baseia nos requerimentos dos usuários, focando principalmente no
seu comportamento e necessidades.
O método Bridge foi desenvolvido por DAYTON, MCFARLAND and
KRAMER (WOOD, 1998). “A metodologia produz uma interface orientada para o
objeto, que significa que a interface gráfica reflete o foco do usuário em
unidades de dados – objetos de dados – nas quais eles realizam suas tarefas.”
Os autores declaram que o estilo de uma interface gráfica orientada ao objeto
geralmente provê uma interface mais natural e fácil de aprender.
As principais atividades do método Bridge são (1) expressar os
requerimentos dos usuários em fluxos de tarefas, (2) mapear os fluxos de
tarefas em objetos de tarefas, e (3) mapear objetos de tarefas em objetos
gráficos de interface com usuários (objetos de uma Interface Gráfica).
O método se inicia com uma série de workshops muito intensos durante
um período de poucos dias, sob a orientação do facilitador. O resultado das
atividades de design é primeiro escrito em cartões e colocado em mesas, onde
são facilmente acessíveis por todos os participantes e podem ser alterados ou
mesmo descartados. Um consenso é alcançado como resultado, eles são
fixados às paredes em volta da sala, onde ficam convenientemente disponíveis
para referência. O método é realizado num estágio inicial e é independente de
qualquer representação gráfica dos objetos.
Embora os autores recomendem sessões participativas entre 3 e 7 dias
(dependendo da complexidade do produto), para viabilização da presente
pesquisa, o método foi feito em dois dias. Para tal, todo o processo foi
apresentado aos participantes de forma que eles mesmos definissem o escopo
do projeto para que todas as etapas contempladas fossem atingidas.
Os autores recomendam como última etapa do método o desenho das
telas, onde se ”traduz os objetos de tarefa, com seus atributos, ações e
relações de hierarquia, em objetos de Interface Gráfica propriamente ditos”.
Métodos e Técnicas da Pesquisa 102
Como levantado no Delimitação da Pesquisa, a pesquisa aborda apenas o
terceiro dos 5 Planos do trabalho de desenvolvimento de websites – a Estrutura
ou a Arquitetura da Informação – proposto por GARRETT (2003). Esta última
etapa então, passaria para um nível de detalhamento que estaria inserido no
quarto plano de desenvolvimento (Esqueleto) e portanto, fora do escopo da
pesquisa. Essa última etapa foi substituída então pelo Vocabulário Visual de
GARRETT (2003), como veremos adiante.
Detalhamento do Método
Foram reunidos os sujeitos sugeridos pelo método durante um dia e meio
– das 9:30 às 19h com 1 hora e 30min. de intervalo para almoço no primeiro dia
e mais 4 horas de trabalho no segundo dia – numa sala com uma mesa redonda
onde os participantes realizaram os trabalhos. Foram utilizadas as paredes em
volta das mesas para fixar os papéis para referência durante todo o processo.
Figura 15: Início do Método Bridge
Primeira Etapa: Expressando os Requisitos dos Usuários como Fluxos de
Tarefas
• Objetivo: Traduzir as necessidades dos usuários em requisitos que
refletirão o fluxo de tarefas que serão incluídas no próximo passo;
• Atividades: Analisar, documentar, redesenhar, e testar a usabilidade dos
fluxos de tarefas
• Saídas: Roteiro do que os usuários farão com a nova Interface. O formato
é em cartões-índice para cada passo, setas coláveis entre os cartões, e
esses materiais colados com fitas sobre peças de papel de flip chart.
Métodos e Técnicas da Pesquisa 103
A primeira parte produz um ou vários fluxos de tarefa bem documentados
pela perspectiva do usuário. Os fluxos de tarefas representam concretamente o
que os usuários desejam para completar a tarefa com o produto proposto – um
site universitário. O objetivo nesta etapa é levantar o que os usuários querem
saber mais do que o que querem ver. Cada participante anota em uma folha de
papel todas as tarefas que considera importante. Os participantes começam a
trocar idéias e a discutir as tarefas levantadas. Ao final desta etapa, os
participantes devem escrever em cartões todas as tarefas levantadas que
atingiram um consenso.
Neste ponto, sempre lembrados da restrição do período de tempo, os
próprios participantes começaram a restringir o escopo do projeto,
estabelecendo apenas um público-alvo para o universo do website em questão.
Os participantes, sem intervenção alguma do pesquisador, estabeleceram que
o foco seria nas tarefas dos usuários Alunos Candidatos à Universidade em
questão.
Figura 16: Discussão dos itens levantados na primeira etapa do método
A representação do fluxo de tarefas é feita por cartões-índice colados
num papel de flip chart com linhas de fluxo entre os cartões começando a ser
traçadas. Cada passo da tarefa é representado por um nome e um verbo
escritos num cartão, como por exemplo “Imprimir o Manual do Candidato”.
Essa etapa é bastante interativa, de forma que todos concordem com o que
está sendo estabelecido. Cartões indesejados ou considerados redundantes
podem ser descartados.
Ao final do primeiro bloco (até a hora do almoço), as paredes estão
cobertas com os fluxos de tarefas que foram criadas nas mesas. Cada fluxo é
composto por um grupo de cartões conectados por setas coláveis (para serem
Métodos e Técnicas da Pesquisa 104
possivelmente removidas), todos anexados com fitas adesivas num pedaço do
papel do flip chart. Comentários são presos no topo do fluxo de tarefas com
post-its fluorescentes de tamanhos variados.
Os “testes de usabilidade” que os autores mencionam em cada etapa são
na verdade leituras do todo o processo encontrado até então e discussões
entre a equipe visando sempre a boa usabilidade do produto que está sendo
desenvolvido.
Figura 17: Os membros da equipe começam a conectar os cartões e a formar o panorama geral do sistema
O processo de mapeamento e verificação segue pela anotação de cada
atributo de objeto de tarefa em um post-it anexado a cada cartão-índice de
objeto. Vários atributos são copiados pela sua menção no fluxo de tarefa, mas
outros vêm do conhecimento do time. O foco está em descrever os fluxos mais
do que em criticá-los, mas, se problemas são mencionados, eles devem ser
escritos em post-its cor de rosa e colados no cartão-índice correspondente.
Cada post-it rosa possui apenas uma questão ou gargalo, e esse post-it é
colado no cartão-índice que representa o passo de tarefa relevante. Qualquer
tipo de questão ou gargalo justifica não apenas problemas visíveis; pode haver
um passo de tarefa que funcione corretamente quando considerado
isoladamente, mas fica óbvio um gargalo quando o fluxo de tarefa completo é
considerado. As questões são escritas mesmo que ninguém tenha uma pista
de que solução possa ter. O foco nesse passo é na documentação das
questões mais do que nas soluções, mas, se as soluções acontecerem, elas
deverão ser escritas num post-it verde, “soluções possíveis”, e presas ao post-it
rosa da questão pertinente.
Métodos e Técnicas da Pesquisa 105
Figura 18: A foto acima mostra o fluxo de tarefas com seus passos correspondentes. Os post-its cor-de-rosa forte mostram os gargalos encontrados em cada passo de tarefa e os verdes já são as soluções ideais levantadas pelo time
Esse papel fixado na parede serve agora como referência para a
montagem do fluxo de tarefas com seus objetos de tarefas delineados. Os
participantes copiam cada nome do fluxo de tarefa em cartões índice e
colocam-nos na mesa. Não são verbos, apenas nomes, por ex. em “Verificar as
datas de inscrição” os participantes deveriam escrever apenas nomes de
tarefas abstratas como “Inscrição”. Cada objeto de tarefa é realmente uma
classe de objeto, então o objeto de tarefa “Inscrição” representa a classe de
toda a tarefa. Abaixo de cada classe de tarefa, então, os participantes
adicionam seus atributos (objetos-filho e propriedades), sempre ouvindo cada
opinião e buscando um consenso em cada resultado.
Segunda Etapa: Mapeando Fluxos de Tarefas em Objetos de Tarefas
• Objetivo: Mapear as saídas dos requisitos dos usuários pela Parte 1 em
objetos de tarefas – unidades distintas de informação que os usuários
podem manipular para a realizar a tarefa – com comportamentos
especificados e relações de forças;
• Atividades: Design do Objeto de Tarefa – descobrir, desenvolver,
documentar e testar a usabilidade dos objetos de tarefas;
Métodos e Técnicas da Pesquisa 106
• Saídas: Cada objeto de tarefa é mostrado como um cartão-índice, com os
atributos dos objetos, ações, e forças descritas em fitas anexadas;
Na segunda etapa do método se constroem pontes entre os fluxos de
tarefa, criando alguns “objetos de tarefas” abstratos pelos nomes encaixados
nos fluxos de tarefas que vieram da Etapa 1. Cada nome de objeto de tarefa é
copiado do passo do fluxo de tarefa em cartões-índice e posto na mesa onde o
grupo trabalha. Por exemplo, se um passo no fluxo da tarefa é “Imprimir o
Manual do Candidato”, então “Manual do Canidato” é escrito num cartão-índice
que é colocado na mesa.
Em seguida, os participantes registram em post-its rosas ações que os
usuários necessitarão para ter os objetos. São as ações realizadas para um
objeto, como imprimir, mais do que ações realizadas pelo objeto. Em adição às
ações listadas nos fluxos de tarefas, os participantes devem considerar ações
padrão como visualizar, criar, deletar, copiar, editar, salvar, seguir e imprimir.
O último bloco da etapa corresponde às relações contidas entre os
objetos de tarefas. Essas relações detidas não estão amarradas diretamente
aos dinamismos dos fluxos de tarefas, são relações estáticas. Elas são as
hierarquias intuitivas entre os objetos quando os usuários pensam sobre os
objetos que estão usando para realizar suas tarefas. Segundo os autores,
“quando os participantes desenham suas hierarquias, eles estão desenhando
os fundamentos do modelo mental dos usuários no universo da Interface
Gráfica”. Neste passo os participantes examinam todos os atributos listados
nos post-its de atributos para cada objeto de tarefa e copiam tais atributos, que
são objetos-filho em “Dentro de mim”, numa coluna à direita no conteúdo do
post-it. A coluna “Estou dentro de” por sua vez é preenchida com o nome do
objetos de tarefa “pai”. Desta forma criam-se os relacionamentos entre as
tarefas mostrando claramente todo o processo e relacionamentos
estabelecidos ali.
O time agora testa se o grupo de tarefas é usável para execução dos
fluxos de tarefas descritos no outro papel ainda fixado na parede para
referência. Uma pessoa passeia através de cada passo no fluxo de tarefa, com
os outros participantes conferindo os cartões de objetos de tarefas e port-its
para a presença de todos os objetos, atributos e ações necessárias para
executar o passo de tarefa. O time freqüentemente irá descobrir que os objetos
Métodos e Técnicas da Pesquisa 107
de tarefas ou mesmo os fluxos de tarefas estão incompletos ou incorretos. Se
acontecer, o time deve mudá-los; toda a metodologia é interativa. Até aqui o
design da Interface Gráfica é irrelevante. O time precisa fazer esse teste de
usabilidade apenas em um nível abstrato de fluxos de tarefas e objetos de
tarefas.
Figura 19: Um participante do método preenchendo no quadro as relações contidas entre os objetos de tarefa
Ao final da Parte 2 tem-se um grupo de objetos de tarefas suficientes e
usáveis para realizar as tarefas e cada objeto de tarefa documentado como um
cartão-índice.
Na descrição do método, o resultado desta Etapa seria usado para a
Terceira Etapa do Bridge, onde se começariam a desenhar os objetos da
Interface Gráfica. Mas como foi dito anteriormente, esta etapa não faz parte do
escopo da presente pesquisa. Para finalizar o método e apresentar os
resultados, utilizou-se o Vocabulário Visual de GARRETT (2002).
Métodos e Técnicas da Pesquisa 108
Seleção dos Sujeitos
Conforme a seleção proposta pelo método, foram utilizados 5
participantes:
• 1 usuário experiente
Conhecedor do assunto tratado nos sites universitários e experiente em
websites desse gênero;
• 1 usuário iniciante
Conhecedor do assunto tratado nos sites universitários, mas inexperiente
em websites desse gênero;
• 1 Engenheiro de Usabilidade
É a pessoa responsável pela usabilidade do produto e de todas as
atividades que contribuem para ela;
• 1 Desenvolvedor
É a pessoa que irá prover as funcionalidades especificadas na
documentação da interface gráfica e de requerimentos do sistema. Na
pesquisa foi utilizado um designer que, além de trabalhar no back-end do
produto, desenvolve a interface gráfica tomando algumas definições com
relação à mesma;
• 1 Engenheiro de Sistemas
É a pessoa responsável pelo delineamento dos requerimentos do sistema,
que, junto com o documento de requerimentos do usuário, guia o trabalho
dos desenvolvedores.
Além desses, um “facilitador” (o próprio pesquisador) que coordenou a
sessão e seus objetivos e liderou cada momento, sem interferir nos resultados.
Todos os membros da equipe (exceto os usuários) trabalham
efetivamente com desenvolvimento web, sendo dois deles pesquisadores de
temas relacionados à internet. Já os usuários possuem um bom conhecimento
de como navegar na internet, visto que ambos acessam sites diversos pelo
menos uma vez por dia.
Apresentação dos Resultados do Método
O diagrama Vocabulário Visual proposto por GARRET (2002), foi utilizado
como forma de “descrever e comunicar a Arquitetura da Informação e o design
de interação”. Segundo o autor, “um vocabulário visual é um grupo de símbolos
Métodos e Técnicas da Pesquisa 109
usados para descrever alguma coisa (usualmente um sistema, estrutura ou
processo)”. O vocabulário descrito por GARRET “pode ser usado por um
arquiteto de informação ou designer de interação para descrever, em um alto
nível, a estrutura e/ou o fluxo da experiência do usuário em um website”. Como
o método Bridge de DAYTON at al (WOOD, 1998) foca em unidades que
representam o fluxo de tarefas em alto nível, o Vocabulário Visual então se
apresentou muito profícuo.
Segundo GARRETT (2003), para alguns projetos com um grande volume
de conteúdo em uma estrutura hierárquica, esquemas em textos simples
podem ser um modo efetivo de documentar a arquitetura. Porém, “a principal
ferramenta de documentação para a Arquitetura da Informação ou design de
interação é o diagrama”. A representação visual da estrutura é a forma mais
eficiente de comunicar as ramificações (arborescências), grupos e interrelações
entre os componentes de um site. O autor aponta que o diagrama serve tanto
para descrever a Arquitetura da Informação como design de interação,
bastando para tal alternar a ênfase na estrutura conceitual e a organização do
conteúdo, ou nos fluxos dos usuários através das tarefas definidas.
O autor alerta, porém, que o diagrama não deve ser confundido com a
árvore do site, “que é um termo usado para um tipo particular de ferramenta de
navegação dentro de um website”. O diagrama não documenta cada link em
cada uma das páginas no site em questão. “O objetivo do diagrama de
Arquitetura da Informação não é prover uma especificação de navegação
completa.” Esse nível de detalhe, segundo o autor, deve ser visto em outro
momento para não distrair ou confundir. “O resultado em diagrama foca no que
chamamos de macroestrutura, provendo detalhes suficientes para fornecer aos
membros do time de desenvolvimento a “big picture””. Detalhes específicos ao
nível de páginas (low level), ou o que o autor chama de microestrutura, deve ser
detalhado em outra etapa, utilizando outro tipo de documento.
O vocabulário é baseado no seguinte modelo conceitual:
• O sistema apresenta caminhos ao usuário;
• O usuário se move ao longo desses caminhos através de ações;
• Essas ações então fazem com que o sistema gere resultados.
Foram usados alguns itens do diagrama proposto pelo autor como
apresentado a seguir:
Métodos e Técnicas da Pesquisa 110
Páginas, arquivos e respectivos grupos
Página é a unidade básica da experiência do usuário em um website. No
diagrama, a página é considerada como uma unidade de apresentação, não
(necessariamente) uma unidade de implementação, o que significa que uma
página no diagrama pode corresponder a múltiplos arquivos HTML (numa
interface em frames) ou unidades múltiplas de códigos (numa aplicação
baseada em banco de dados).
Representação de página Representação de um grupo de
páginas
Figura 20: Vocabulário Visual (GARRETT, 2003): páginas
Arquivos são parcelas de dados sem propriedades de navegação, como
arquivos de som ou vídeo, PDFs ou executáveis.
Representação de arquivo Representação de um grupo de
arquivos
Figura 21: Vocabulário Visual (GARRETT, 2003): arquivos
Grupo de páginas indica páginas com funcionalidades idênticas nas quais
as propriedades de navegação são imateriais para a macroestrutura do site. Da
mesma forma, um grupo de arquivos representa que todos eles recebem um
tratamento de navegação idêntico e pode ser classificado como uma entidade
única (como uma coleção de jogos para download ou uma biblioteca de
manuais de instrução em PDF).
Os rótulos usados para nomear as páginas e arquivos servem para
identificá-los e não são necessariamente os títulos dos mesmos.
Métodos e Técnicas da Pesquisa 111
Conectores: relacionamentos entre os itens
Relacionamentos entre elementos são descritos com linhas simples ou
conectores. Esses relacionamentos conceituais irão inevitavelmente traduzir
relacionamentos de navegação – mas nem todos os relacionamentos de
navegação irão aparecer no diagrama. Na maioria dos casos de arquitetura da
informação, esses relacionamentos são representados em árvores, todavia isso
não é necessário nem recomendável aqui.
Os conectores representados com setas indicam a direção na qual o
usuário comumente irá, dando um sentido de direção entre os elementos. Os
representados por setas partidas significam caminhos sem volta. Traços
pontilhados representam conectores condicionais, o que significa que o
sistema poderá ou não prover o caminho para o usuário.
Conector simples condicional e normal
Conector direcional condicional e normal
Conector mono-direcional condicional e normal
Figura 22: Vocabulário Visual (GARRETT, 2003): conectores
Grupos concorrentes
Um grupo concorrente acontece quando uma ação do usuário gera
múltiplos e simultâneos resultados (como uma janela pop-up ao mesmo tempo
que uma página é carregada na janela principal). É representado por um meio
círculo.
Métodos e Técnicas da Pesquisa 112
Figura 23: Vocabulário Visual (GARRETT, 2003): grupos concorrentes
Quebras
Quando o diagrama se torna muito grande, as quebras são colocadas
para auxiliar na separação do mesmo em seções mais digeríveis, ligando os
pontos entre as páginas.
Continua para Continua de
Figura 24: Vocabulário Visual (GARRETT, 2003): quebras
Pontos de decisão
O sistema toma caminhos para um ou mais atributos. Esses atributos
podem ser particulares para:
• O usuário (como tipo de usuário)
• A seção (como o status do login)
• O conteúdo que está sendo acessado (como um tema importante)
• Ou como eles existem no ambiente (como a hora ou data)
A associação de um atributo com um valor particular é chamada de
condição. Condições são avaliadas pelo sistema para determinar se elas são
verdadeiras.
Métodos e Técnicas da Pesquisa 113
Numa arquitetura estática, cada passo é apresentado para cada usuário
dentro de cada circunstância, cada passo levando para o mesmo resultado.
Numa arquitetura dinâmica, o sistema decide quais passos ou resultados são
apresentados ao usuário, baseado na avaliação de uma ou mais condições.
No diagrama, esses pontos de decisão são apresentados como losangos.
As setas são fundamentais para se saber a direção do fluxo.
Figura 25: Vocabulário Visual (GARRETT, 2003): pontos de decisão
Ramificação condicional
Acontece quando o sistema precisa decidir um caminho entre um número
mutuamente exclusivo de opções a serem apresentadas ao usuário. Neste
caso, diferentemente do Ponto de decisão, o sistema decide o caminho do
usuário antes dele desempenhar uma ação. Apenas um caminho é apresentado
a ele.
Figura 26: Vocabulário Visual (GARRETT, 2003): ramificação condicional
Seletores Condicionais
A função deste elemento se parece muito com a ramificação condicional,
com uma importante diferença: aqui as várias opções subseqüentes não são
mutuamente exclusivas. Todos os números de caminhos devem ser
apresentados aos usuários. O exemplo mais comum desta situação é a
Métodos e Técnicas da Pesquisa 114
ferramenta de busca. O critério de condição foi posto pelo usuário e a escolha
será feita por ele. O resultado pode também ser nulo.
Figura 27: Vocabulário Visual (GARRETT, 2003): seletores condicionais
Cachos
Algumas estruturas condicionais requerem que o sistema apresente mais
de um caminho baseado em certas condições. Esses caminhos são associados
na estrutura pelos “cachos” (representados por um círculo). O cacho pode
aparece tanto a partir da ramificações quanto de seletores.
Figura 28: Vocabulário Visual (GARRETT, 2003): cachos
Caminhos Condicionais
O sistema pode não mostrar um caminho para o usuário, baseado em
condições pré-existentes.
Figura 29: Vocabulário Visual (GARRETT, 2003): caminhos condicionais
Métodos e Técnicas da Pesquisa 115
5.2.3
Terceira Etapa
Nesta etapa a Análise Ergonômica da Tarefa teve como objetivo identificar
os erros encontrados pelos sujeitos nos websites de Universidades da Cidade
do Rio de Janeiro, selecionadas como estudo de caso.
Para STAMMERS e SHEPHERED (1995) a observação das pessoas
envolvidas com o trabalho é uma característica principal da ergonomia. “Para
que as atividades humanas em seus sistemas sejam aperfeiçoadas, e
interfaces, programas de treinamento e equipamentos sejam projetados ou
produzidos, é sempre necessário realizar esta observação.” Com
desenvolvimento da ergonomia, muitos métodos de análise da tarefa foram
gerados.
Segundo HACKOS e REDISH (1998), qualquer produto possui uma
interface na qual as pessoas têm que saber como usar para realizar tarefas e
completar objetivos. O objetivo pode ser encontrar uma resposta ou se
comunicar com um amigo, fazer um chá, prover informação, entrar numa sala,
ter luz suficiente para ler um livro. Todos esses produtos podem ser tanto
facilitadores como podem vir a ser obstáculos para os usuários que estão
tentando realizar tarefas para atingir seus objetivos.
A visão de ciclo de tarefas de Norman (Os Estágios do Raciocínio Humano para Solução de Problemas, Cap. 4) é útil porque ela nos faz entender que as pessoas possuem sempre várias opções para as tarefas que podem ser usadas para alcançar seus objetivos. O que a pessoa escolhe depende de como ela pesa os fatores que são externos a como a tarefa é realizada mas são uma importante parte da análise da tarefa. Esses fatores incluem tempo, custo, habilidades e confianças pessoais em métodos diferentes, facilidade para aquela pessoa de aprender a usar um método particular, o valor que aquela pessoa coloca em um ou outro fator.
JoAnn T Hackos e Janice C Redish, 1998 Para SANTOS (2000) a observação da tarefa em IHC é muito mais difícil,
pois em alguns casos a tarefa observada envolve um usuário final direto ou
operador, usando um computador. Os comportamentos gerados pelo operador
são geralmente muito rápidos e bastante restritos em extensão espacial.
Segundo HACKOS e REDISH (1998), alguns especialistas em IHC sugerem que
a análise da tarefa deve ser dependente do dispositivo (equipamento,
plataforma, ferramenta ou produto que será usado para a tarefa). Sugerem
Métodos e Técnicas da Pesquisa 116
então que a tarefa deva ser realizada dentro do contexto de uma situação
específica.
Para os autores, Análise da Tarefa é o processo de aprendizado sobre
usuários comuns através da observação deles em ação. Esse procedimento é
diferente de simplesmente argüir os usuários a respeito da tarefa que
desempenham, pois a experiência tem mostrado que os usuários não sabem
articular o que eles fazem, especialmente se eles estão muito familiarizados
com as tarefas que realizam. Quando se assiste aos usuários realizarem suas
tarefas, aprende-se que seus testemunhos são sempre incompletos e
imprecisos.
Análise da Tarefa foca no profundo entendimento de como os usuários
realizam suas tarefas. Esse entendimento inclui:
• Quais são os objetivos dos usuários; o que eles estão tentando alcançar;
• O que os usuários de fato fazem para alcançar esses objetivos;
• Quais são as características pessoais, sociais e culturais dos usuários
trazidas para a tarefa;
• Como os usuários são influenciados pelo ambiente físico;
• Como o conhecimento anterior dos usuários e suas experiências
influenciam em como eles pensam sobre seu trabalho e o fluxo que eles
seguem para desempenhá-las;
• Quais valores dos usuários farão com que uma nova interface seja
aproveitada por eles (Velocidade? Precisão? Ajuda na solução de erros?
Contato humano? Diversão? Desafio?)
Para STAMMERS e SHEPHERED (1995), as técnicas de análise da tarefa
são tidas como uma intenção de representar a informação que será usada no
projeto de um novo sistema humano/máquina ou na avaliação de um projeto de
um sistema já existente. É realizada através de análise sistemática das tarefas
requeridas do usuário. Dessa forma ele pode ser tanto formativo (quando
aplicado nas fases iniciais de desenvolvimento) quanto somativo (quando
aplicado após implementação). No âmbito da pesquisa em questão será usado
o aspecto somativo.
Segundo os autores, devem ser considerados três componentes que
interagem nas tarefas:
• Os Requisitos da Tarefa: se referem aos objetivos e às metas para o
executor da tarefa.
Métodos e Técnicas da Pesquisa 117
• O Ambiente da Tarefa: se refere a fatores na situação de trabalho que
limitam e determinam como um indivíduo pode desempenhá-la.
• O Comportamento da Tarefa: se refere a ações que são levadas em
consideração pelo usuário, inseridas nos constrangimentos do ambiente
da tarefa. O comportamento do usuário pode ser limitado através de
fatores psicológicos ou fisiológicos inerentes, ou uma falta de
conhecimento apropriado à habilidade.
SANTOS (2000) acrescenta que os recursos mais utilizados para registro
de observação de tarefas em IHC são: registro em caneta e papel; registro em
áudio; registro em vídeo; captura por programas de computador. “Geralmente
esses recursos são utilizados em conjunto, a fim de dar maior fidelidade à
coleta de dados.”
Seleção de Sujeitos
Para esta terceira etapa da pesquisa, utilizaram-se 9 sujeitos, divididos em
grupos de 3 cada emparelhados. Para seleção e agrupamento dos
participantes, utilizou-se um questionário demográfico que, segundo HACKOS e
REDISH (1998) ajuda a confirmar as características que foram identificadas
quando inicialmente filtraram-se os usuários. “Também ajuda a adquirir
informações adicionais que irão ajudar a associar tarefas particulares e
comportamentos com categorias de usuários”. Segundo os autores, sendo o
questionário preparado e enviado antes da análise da tarefa propriamente dita,
é possível ter a oportunidade de comparar suposições e fazer ajustes.
Através de questionário (em Apêndice), obtiveram-se informações sobre
sexo, idade, se o participante estava ou não prestando vestibular neste ano (era
condicional o fato dos participantes estarem prestando vestibular neste ano,
2003 para 2004) e se tinham experiência em um dos 3 sites de universidades
que seriam analisados (os participantes não deveriam conhecer o site
analisado). Procurou-se separar os sujeitos, então, pela freqüência de acesso à
internet e pela experiência do site em questão. Os sujeitos foram divididos nos
seguintes grupos:
• Grupo 1 – UERJ: 2 sujeitos acessam a internet sempre (todos os dias) e 1
acessa freqüentemente (de 3 a 6 vezes por semana);
• Grupo 2 – PUC-Rio: 2 sujeitos acessam sempre; 1 sujeito acessa
raramente (menos de 1 vez por semana);
Métodos e Técnicas da Pesquisa 118
• Grupo 3 – UniverCidade: 2 sujeitos acessam sempre; 1 sujeito acessa
ocasionalmente (1 a 2 vezes por semana).
O ambiente da Tarefa
Todos os sujeitos testados participaram da Análise em situações
idênticas:
• Foi utilizado um micro PC Pentium com Windows 2000, com navegador
Internet Explorer 6.0, conexão banda-larga, em monitor de 15’’ com
resolução de 800 x 600 pixels;
• Todos os participantes foram analisados no mesmo ambiente e micro
(uma sala reservada com uma mesa isolada com o micro em questão);
• Foram adotados os mesmos esquemas de iluminação e som;
• Buscou-se também horários e dias semelhantes para não haver diferenças
com relação à velocidade de conexão, embora esse fator não pudesse ser
totalmente controlado, visto que alguns sites em dado momento estavam
com o acesso mais comprometido. Porém, o tempo de acesso não foi um
fator determinante e sim a quantidade de nós acessados para chegar ao
objetivo final.
Descrição da Tarefa
Para a Análise da Tarefa em questão foram utilizados os registros em
áudio, vídeo e software de captura de telas percorridas ScreenRecord para
registro em off de passos dos sujeitos (disponível em
http://www.versiontracker.com).
Para avaliar a Arquitetura da Informação dos sites selecionados no estudo de
caso, foi estabelecida uma tarefa na qual fosse possível a observação da facilidade
e/ou dificuldade na sua realização. A seleção de tarefa seguiu as seguintes
premissas:
• A tarefa deveria permitir observar a navegação do usuário pelos nós de cada
um dos sites em ao menos três níveis, partindo da homepage;
• Como a mesma tarefa seria realizada pelos especialistas na quarta etapa
da pesquisa – que iriam comparar os resultados dos sites com os
encontrados nos dois métodos utilizados na segunda etapa – era
essencial que a mesma fizesse parte do escopo resultante desses
métodos. Ou seja, a seqüência de nós a serem galgados para realização
Métodos e Técnicas da Pesquisa 119
da tarefa deveria estar presente na estrutura resultante do Card Sorting
bem como a própria tarefa representada no fluxo de tarefas resultante do
Bridge;
• Era essencial a ocorrência da mesma tarefa nos três sites avaliados.
Solicitou-se aos participantes então a execução da seguinte tarefa:
Localizar no site avaliado as datas de provas para ingresso na instituição
de ensino correspondente
Não foi mencionado o termo Vestibular, pois uma das instituições
avaliadas (UniverCidade) não utiliza o mesmo e sim “Teste de Acesso Direto”,
que é a sua forma de ingresso.
Enquanto os participantes executavam a tarefa, o pesquisador
questionava os links acionados e perguntava o que cada um deles estava
olhando e procurando.
5.2.4
Quarta Etapa
Nesta etapa fez-se uma Avaliação de Especialistas que avaliaram não
apenas os sites como também deram suas opiniões com relação ao resultado
dos métodos utilizados na segunda etapa.
Segundo PREECE (1993), com simulações de uso, faz-se uma revisão do
sistema para encontrar problemas de usabilidade. Essas revisões são feitas
usualmente por especialistas, que simulam o comportamento dos usuários
menos experientes e tentam antecipar os problemas de usabilidade que eles
encontrariam. Por essa razão eles também podem ser tratados como Revisores
Especialistas ou Avaliadores Especialistas. Idealmente esses revisores são
especialistas em IHC e também possuem uma grande experiência em
diferentes tipos de sistema, de forma que eles estejam aptos a apontar
problemas de usabilidade relacionados a inconsistência, estruturas pobres de
tarefa, design confuso de tela, etc.
Segundo a autora, a Avaliação dos Especialistas é um método de
diagnóstico entre uma aproximação teórica adquirida numa avaliação analítica e
um método mais empírico como uma avaliação observacional ou experimental.
Métodos e Técnicas da Pesquisa 120
Não foi utilizada aqui uma Avaliação de Especialistas a partir de
orientações (guide lines) como a Avaliação Heurística de NIELSEN (1993). O
método foi aplicado no sentido de se obter, como apontado por PREECE
(1993), feedbacks prescritivos a respeito da interface:
• Um pequeno número de especialistas pode identificar um grande número
de problemas potenciais para os usuários durante uma sessão única com
a interface;
• Sempre, pequenos empurrões são necessários para que os especialistas
sugiram soluções para os problemas identificados, porque eles devem ter
experimentado várias interfaces. Provavelmente eles irão propor rápidas
mudanças radicais na interface.
Segundo PREECE (1993) especialistas são sempre fortes em feedbacks
prescritivos sobre como o sistema pode ser melhorado e como os problemas
de usabilidade podem ser resolvidos.
Em Avaliações de Especialistas, os “especialistas” (normalmente pessoas experientes em design de interfaces ou pesquisas em ergonomia ou ambos) são requisitados para tomar a parte dos usuários menos experientes e descrever os problemas potenciais que eles prevém aparecer para esse tipo de pessoas.
Jenny Preece, 1993
É necessário considerar:
• Deve-se garantir uma opinião imparcial dos especialistas; estes não
devem ter tido envolvimento com versões anteriores do sistema
protótipo;
• Os especialistas devem possuir experiências múltiplas, tanto em
aplicações como em IHC. Design de mídia e criação podem também ser
úteis;
• A função dos especialistas precisa ser claramente definida para garantir
suas adaptações das perspectivas requeridas quando usando o sistema;
• A tarefa desempenhada, o sistema ou protótipo usado, bem como
qualquer acessório material, deve ser comum a todos os especialistas e
ao menos representativos dos intencionados para os usuários finais.
Métodos e Técnicas da Pesquisa 121
Seleção de Sujeitos
Os três especialistas selecionados trabalham e pesquisam a Interação
Humano-Computador, design de interfaces e conhecem os métodos utilizados
para avaliação de usabilidade, exceto o método Bridge utilizado na pesquisa.
Descrição da Tarefa
Aos especialistas foi pedida a realização da mesma tarefa efetuada na
terceira etapa – Análise da Tarefa – pelos usuários, cada qual num site de uma
universidade que não fosse conhecido. Ao realizarem a tarefa, deveriam
descrever os problemas encontrados de forma não-estruturada (PREECE, 1993),
reportando suas observações e categorizando as áreas de problemas comuns.
Desta forma convidam-se os especialistas a colocar espontaneamente seus
comentários e sugestões.
Ao final, foi pedido a eles que também comparassem os resultados
encontrados nos métodos aplicados na segunda etapa da pesquisa com os
encontrados nos sites universitários. Os especialistas deveriam comparar a
tarefa que acabaram de executar, analisando o posicionamento dos itens e o
próprio desempenho na execução da tarefa, com os resultados encontrados no
Card Sorting do método Bridge. Desta forma, além de propor soluções nas
interfaces avaliadas, eles mesmos deveriam criticar as soluções propostas
pelos métodos, verificando se os problemas encontrados seriam resolvidos
caso as soluções apontadas estivessem implementadas.
Métodos e Técnicas da Pesquisa 122
Referências Bibliográficas do Capítulo
EASON, Keneth D. User-centred design: for users or by users. In: Ergonomics: Iea´94 Special Issue. London, Taylor & Francis, 1995 GARRETT, Jesse James. The Elements of user Experience: User-Centers Design for the Web. 2nd Ed. Indianapolis (Indiana), 2003, 189 p. __ GARRETT, Jesse James. A visual vocabulary for describing information architecture and interaction design. Version 1.1b (6 March 2002). Acesso em 11/09/2003. http://www.jjg.net/ia/visvocab/. HACKOS, JoAnn T.; REDISH, Janice C. User Task Analysis for Interface Design. Wiley (New York) New York, 1998. 488p. HELANDER, Martin G.; LANDAUER, Thomas K.; PRABHU, Prasad V. Handbook of Human-Computer Interaction. 2nd edition. Elsevier, North-Holland. 1997, 1.582p. __ IBM DeveloperWorks. IBM´s Resources of Developers. Acesso em 23/02/2003. Exige registro: http://www.ibm.com/developerWorks LIAW, Shu-Sheng. An Internet survey for perceptions of computers and the World Wide Web: relationship, prediction, and difference. Computers in Human Behavior, 18 (2002), p. 17-35. __ MYER, Thomas. Card Sorting and Cluster Analysis. Acesso em 23/02/2003. Exige registro: http://www.ibm.com/developerWorks MAYHEW, Deborah J. Principles and Guidelines in Software User Interface Design. Englewood Cliffs (New Jersey), PTR Prentice Hall. 1992. 619p. MORAES, Anamaria de. Usabilidade de Interfaces: Ergonomização da Interação Homem-Computador; Design de telas. MORAES, Anamaria e FRISONI, Bianka Cappucci. Ergodesign: produtos e processos. Rio de Janeiro, 2AB, 2001. 206p. NIELSEN, Jakob. Usability Engineering. San Francisco (California), Morgan Kaufmann, 1993. 362p. ___. NIELSEN, Jakob. Paper Prototyping: Getting User Data Before You Code (Book Review). April 2003. Useit.com. Disponível em: http://www.useit.com/alertbox/20030414.html. Acesso em 15 abr. 2003. ___. NIELSEN, Jakob. Why you only need to test with five users. Março 2000. Useit.com. Disponível em: http://www.useit.com/alertbox/20000319.html. NIELSEN, Jakob; LANDAUER, T. K. A Mathematical Model of the Finding of Usability Problems. In: Proc. ACM INTERCHI ’93 Conf. Amsterdan, Holanda, 1993, p. 206-213.
Métodos e Técnicas da Pesquisa 123
NORMAN, Donald A. The Invisible Computer: Why Good Products Can Fail, the Personal Computer Is So Complex, and Information Appliances are the Solution. London (England), The MIT Press, 1998. 302 p. PADOVANI, Stephania. Avaliação ergonômica de sistemas de navegação em hipertextos fechados. PUC, 1998. PREECE, Jenny. A Guide to Usability. Human Factors in Computing. Harlow (England), Addison-Wesley, 1993. 144p. REICHENAUER, Arno; KOMISCHKE, Tobias. A Comprehensive Process Model for Usable Information Architecture Systems: Integrating Top-down and Bottom-up Information Architecture. In: Human Computer Interaction, International Proceedings, 2003. LEA Publishers. Mahwah, New Jersey. Vol. 1, p. 223-227. REISS, Eric L. Practical Information Architecture. A Hands-on approach to structuring successful websites. London (England), Addison-Wesley. 2000. 192p. ___ ROBERTSON, James. Information Design Using Card Sorting. Step Two Designs Pty Ltda. 2001. Disponível em: http://www.steptwo.com.au Último acesso em 23 de fev. de 2003. ROSENFELD, Louis; MORVILLE, Peter. Information Architecture for the World Wide Web. 2nd Ed. Beijing, O’Reilly. 2002. 461 p. SÄDE, Simo; NIEMINEN, Marko and RIIHIAHO, Sirpa. Testing usability with 3D paper prototypes – Case Halton system. Applied Ergonomics. Vol 29, No. 1, pp 67-73. 1998. SANTOS, Robson Luís Gomes dos. Abordagem Heurística para avaliação de usabilidade de interfaces. Dissertação de Mestrado em Design. Rio de Janeiro. PUC, 2000. SHNEIDERMAN, Ben. Designing the User Interface. 3a Ed. Reading (Massachusetts), Addison-Wesley, 1998. 639 p. STAMMERS, Robert B.; SHEPHERED, Andrew. Task analysis. In: WILSON, John R.; CORLETT, E. Nigel (Eds.). Evaluation of human work; a practical ergonomics methodology. London, Taylor & Francis, 1995. 2nd. Ed. 1134p. TRIVIÑOS, Augusto N. S. Introdução à pesquisa em ciências sociais. Editora Atlas S.A. São Paulo. 1987, 175p. __ Version Tracker. Download do software ScreenRecord. Acesso em 28/09/2003. Disponível em http://www.versiontracker.com. WODTKE, Christina. Information Architecture. Blueprints for the web. Indianapolis (Indiana), New Riders. 2002. 348p. WOOD, Larry E. User Interface Design. Bridging the Gap from User Requirements to Design. Boca Raton (Florida), CRC Press LLC. 1998. 312p.
Top Related