5 métodos e técnicas da pesquisa - dbd puc rio · métodos e técnicas da pesquisa 5.1...

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

DBD

PUC-Rio - Certificação Digital Nº 0210297/CA

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.

DBD



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

DBD



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

DBD



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

DBD



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.

DBD



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

DBD



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)

DBD



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

DBD



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

DBD



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

DBD



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

DBD



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.

DBD



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

DBD



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

DBD



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):

DBD



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

DBD



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.

DBD



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

DBD



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

DBD



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.

DBD



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

DBD



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.

DBD



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;

DBD



• 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

DBD



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

DBD



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

DBD



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:

DBD



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.

DBD



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.

DBD



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.

DBD



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

DBD



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

DBD



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

DBD



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.

DBD



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


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);

DBD



• 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

DBD



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.

DBD



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.

DBD




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.

DBD



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.

DBD



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.

DBD


5 métodos e técnicas da pesquisa - dbd puc rio · métodos e técnicas da pesquisa 5.1...

Documents