Inspeção e Evolução Da Usabilidade de Buscadores Tipo Diretório: Estudo de Caso Com o Fazdelivery

Juliana Fajardini Reichow
Inspeo e Evoluo da Usabilidade de

Buscadores Tipo Diretrio: Estudo de Caso
com o fazDelivery
Salvador
junho de 2014
Juliana Fajardini Reichow
Inspeo e Evoluo da Usabilidade de Buscadores Tipo
Diretrio: Estudo de Caso com o fazDelivery
Monograa parcial apresentada como pr-
requisito para a concluso do curso Bacha-
relado em Sistemas de Informao na Uni-
versidade do Estado da Bahia.
Universidade do Estado da Bahia UNEB
Departamento de Cincias Exatas e da Terra
Colegiado de Sistemas de Informao
Orientador: Eduardo Manuel de Freitas Jorge
Coorientador: Joo B. Rocha-Jnior
Salvador
junho de 2014
Folha de Aprovao
Monograa apresentada como exigncia parcial para obteno do grau de bacharel
no curso de Bacharelado em Sistemas de Informao da Universidade do Estado da Bahia,
entregue por Juliana Fajardini Reichow em junho de 2014 em Salvador, Bahia.
Prof. Dr. Eduardo Manuel de Freitas Jorge
Orientador, Professor da Disciplina
Universidade do Estado da Bahia
Prof. Dr. Joo Batista Rocha Jnior
Coorientador
Universidade Estadual de Feira de Santana
Prof. Msc. Alexandre Rafael Lenz
Professor Convidado
Universidade do Estado da Bahia
... Aos que no puderam car.
Agradecimentos
Agradeo a todas as pessoas - familiares, amigos, professores - que me apoiaram,
ou pelo menos entenderam, quando eu quis ou precisei testar novos caminhos.
Aos amigos e conhecidos do Classic Rock Army (ou no), por ajudar a dar uma
trilha sonora 24/7 para este trabalho, e por pararem de falar comigo, quando foi preciso
(em especial a Stuart, por deixar de ser um amigo virtual e me ajudar a perceber que,
encerrada esta etapa, tenho fome de mundo).
equipe do fazDelivery, por ter acolhido ao Bruno e a mim.
A meus orientadores ociais e honorrios, pelas dvidas esclarecidas, tempo con-
cedido, correes de percurso e, sempre, pela pacincia: Eduardo Jorge e Joo Rocha,
os ociais; Trcia e Marco, professores de disciplinas de tcc; Jorge Farias, pelas melhores
desorientaes; Cludio Amorim, por ser orientador da vida.
s pessoas especiais que a UNEB me trouxe, em minhas vrias fases l dentro,
com as quais convivi e convivo em vrios espaos na universidade, e que hoje so parte
de minha vida
1
: aos SIspartanos originais. Aos companheiros de noites viradas no e pelo
BRT: colegas de faculdade ou professores. A Rafael e aos demais seguranas que nos cui-
daram tantas e tantas vezes. A todo o amor do #crossjoin. Aos da Taverna do Trapeixe,
que me ajudam a escrever e ler melhor. Aos professores que abriram horizontes, orien-
taram, preocuparam-se, deram broncas, pressionaram. A Bruno, Felipe e Raul e nosso
interminvel chat de acompanhamento mtuo - a melhor equipe de trabalho de faculdade
que eu j escolhi, porque se tornaram parceiros pra vida. =]
Uma vez mais ao Bruno, porque muito rapidamente ultrapassou escopos de facul-
dade e se tornou parceiro e companheiro de tudo. A Iara, Fernando e Rodrigo, que me
aturam h mais tempo do que seria recomendvel.
A meu pai, que sabe que a gente muda de ideia. Excntrica Famlia Estendida
de Antnia, por ser como e estar sempre l, mesmo quando no consigo ver (e que eu
gostaria de nomear toda, mas felizmente muito grande). Nete, por mil cafs e risadas.
Aos meus irmos longnquos - adoro ter irmos. A meu irmo grande, que sabe crescer
mais, quando precisa. minha me, por tudo, mais um pouco e ainda mais.
Sou grata pela oportunidade de agradecer-lhes.
1
Porque no posso deixar de nome-l@s: Adailton, Adriano, Alberto, Ayran, Caios, Grimaldo, Jssica,
JJ, Renan, Ricardo, Thales
If youre making mistakes, it means youre out there doing something.
(...)
And now go, and make interesting mistakes, make amazing mistakes, make glorious and
fantastic mistakes. Break rules. Leave the world more interesting for your being here.
Make good art.
(Neil Gaiman)
Resumo
O objetivo deste trabalho propor e aplicar uma metodologia para melhoria da usabi-
lidade de buscadores do tipo diretrio (que possuem bases de dados estruturados e com
formato conhecido). A metodologia prope: a inspeo heurstica das interfaces da ferra-
menta; teste e observao com usurios em cenrios aproximados de uso real; priorizao
dos problemas de usabilidade identicados; levantamento de solues conceituais para
os problemas e de solues de ferramentas correlatas; prototipao e implementao das
solues propostas e nova rodada de testes para avaliar a efetividade das melhorias.
apresentado um estudo de caso com o fazDelivery, um buscador de deliveries georreferen-
ciado para a cidade de Salvador, na Bahia. O caminho percorrido apresentado permite,
tambm, planejar de antemo possveis solues e, assim, aumentar as chances de sucesso
de aplicaes posteriores da mesma em outras plataformas ou experimentos de melhoria
de interfaces de usurios.
Palavras-chaves: Interao Humano-Computador; Usabilidade; Metodologia para Ava-
liao e Melhoria; Interfaces de Usurio para Ferramentas de Busca.
Abstract
This project aims to propose and implement a methodological approach for improving us-
ability of directory like search engines (which have structured and well known databases).
This methodology proposes: interfaces inspection; testing interfaces with users within ap-
proximate real life scenarios; prioritizing usability problems identied on previous stages;
conceptualizing solutions and looking for similar platforms approaches to the given prob-
lems; prototyping and coding the proposed solutions and going through a new user test-
ing round. A study case of this approach with a georeferenced search engine for deliveries
based on Salvador, Bahia, called fazDelivery, is also shown. The practical path here shown
allows to think on possible solutions beforehand, therefore improving chances of others to
successfully apply this methodology to other platforms or experiments which goal is to
improve user interfaces.
Key-words: Human-Computer Interaction; Usability; Methodology for Evaluation and
Improvement; Search User Interfaces.
Lista de ilustraes
Figura 1 Atributos de aceitabilidade de sistema(NIELSEN, 1993). . . . . . . . . 15
Figura 2 Exemplo de sitelinks no Google. . . . . . . . . . . . . . . . . . . . . . . 21
Figura 3 Exemplo de atalho de predio de resposta, no Bing. . . . . . . . . . . 21
Figura 4 Modelo padro do processo de busca(BRODER, 2002). . . . . . . . . . 33
Figura 5 Pgina inicial do CiteSeerXbeta . . . . . . . . . . . . . . . . . . . . . . 35
Figura 6 Pgina inicial do Open Directory Project . . . . . . . . . . . . . . . . . 35
Figura 7 SERP do CiteSeerXbeta . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 8 SERP do Open Directory Project . . . . . . . . . . . . . . . . . . . . . 36
Figura 9 Pgina inicial do fazDelivery. . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 10 Pgina de resultados do fazDelivery. . . . . . . . . . . . . . . . . . . . 41
Figura 11 Arquitetura do fazDelivery, com foco na busca(ROCHA-JUNIOR, 2013). 42
Figura 12 Diagrama de Classes do fazDelivery (Camada de controle) . . . . . . . 43
Figura 13 Metodologia de avaliao de interfaces - verso 1 . . . . . . . . . . . . 46
Figura 14 Metodologia de avaliao de interfaces - verso 2 . . . . . . . . . . . . 47
Figura 15 Originais - Pgina Inicial do fazDelivery . . . . . . . . . . . . . . . . . 67
Figura 16 Prottipos - Pgina Inicial do fazDelivery . . . . . . . . . . . . . . . . 67
Figura 17 Prottipos - Dilogos de feedback . . . . . . . . . . . . . . . . . . . . . 68
Figura 18 Originais - Pgina de Resultados . . . . . . . . . . . . . . . . . . . . . 69
Figura 19 Prottipos - Pgina de Resultados . . . . . . . . . . . . . . . . . . . . 71
Figura 20 Atalho de resultado do Google. . . . . . . . . . . . . . . . . . . . . . . 78
Figura 21 SERP do Open Directory Project (completa). . . . . . . . . . . . . . . 79
Figura 22 SERP do fazDelivery sem menu de ltros. . . . . . . . . . . . . . . . . 80
Figura 23 Pgina inicial do fazDelivery (completa). . . . . . . . . . . . . . . . . . 81
Figura 24 Um portflio do fazDelivery . . . . . . . . . . . . . . . . . . . . . . . . 82
Figura 25 Diagrama de Classes do fazDelivery (Controlador, mtodos pblicos). . 83
Lista de tabelas
Tabela 1 Exemplo de produto cadastrado no fazDelivery . . . . . . . . . . . . . 40
Tabela 2 Nmero de Violaes de Usabilidade por Tela do fazDelivery . . . . . . 49
Tabela 3 Problemas Listados por Parte do Sistema . . . . . . . . . . . . . . . . 49
Tabela 4 Quantidade de Problemas, por Severidade Classicada . . . . . . . . . 50
Tabela 5 Dez Problemas com Mais Alta Prioridade para Resoluo . . . . . . . 51
Tabela 6 Mdias da avaliao da experincia de uso do fazDelivery . . . . . . . . 57
Tabela 7 Ferramentas de busca citadas neste trabalho, por ordem alfabtica. . . 59
Tabela 8 Levantamento de solues em trs ferramentas correlatas (tabela 1) . . 60
Tabela 9 Levantamento de solues em trs ferramentas correlatas (tabela 2) . . 61
Tabela 10 Solues sugeridas para os problemas encontrados na Pgina Inicial . . 63
Tabela 11 Solues sugeridas para os problemas encontrados na Pgina de Resul-
tados (SERP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Tabela 12 Tarefas de Busca Preestabelecidas para os Testes com Usurios . . . . 103
Lista de abreviaturas e siglas
ABNT Associao Brasileira de Normas Tcnicas
IHC Interao Humano Computador
MVC Model-View-Controller (em portugus, Modelo-Viso-Controlador, pa-
dro de arquitetura de software)
NBR Abreviao utilizada pela ABNT para Norma Brasileira
SERP Search Engine Results Page, como as pginas de resultados de ferra-
mentas de busca tambm so conhecidas
URL Uniform Resource Locator Localizador-Padro de Recursos, endereo
na web
Sumrio
Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1 Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Denio de Usabilidade de Nielsen . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Boas Prticas para Interfaces de Busca . . . . . . . . . . . . . . . . . . . . 16
1.2.1 Diretrizes de Shneiderman para interfaces de busca . . . . . . . . . 17
1.2.2 Diretrizes de Hearst para interfaces de busca . . . . . . . . . . . . . 18
2 Avaliao e Design de Interfaces de Busca . . . . . . . . . . . . . . . . . . . 22
2.1 Abordagens e Tipos de Avaliao de Interfaces . . . . . . . . . . . . . . . . 22
2.2 Avaliao Heurstica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Testes de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Perl e quantidade de participantes . . . . . . . . . . . . . . . . . . 28
2.4 Design Centrado no Usurio . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3 Ferramentas de Busca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Tipos de Ferramentas de Busca . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Modelos de Processo de Busca . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Elementos Bsicos de Interfaces de Ferramentas de Busca . . . . . . . . . . 32
3.4 Aspectos de Evoluo da Usabilidade de Ferramentas de Busca . . . . . . . 34
4 O fazDelivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 Descrio Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Interfaces do fazDelivery para Consumidores . . . . . . . . . . . . . . . . . 38
4.2.1 Pgina inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Pgina de resultados do fazDelivery . . . . . . . . . . . . . . . . . . 39
4.3 Caractersticas do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Metodologia para Avaliao e Evoluo das Interfaces . . . . . . . . . . . . 44
6 Avaliao de Usabilidade do fazDelivery . . . . . . . . . . . . . . . . . . . . 48
6.1 Avaliao Heurstica do fazDelivery . . . . . . . . . . . . . . . . . . . . . . 48
6.2 Sesses de Testes com Usurios . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.1 Metas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2.2 Questes a Serem Respondidas . . . . . . . . . . . . . . . . . . . . 51
6.2.3 Paradigma de Avaliao e Tcnica de Respostas . . . . . . . . . . . 52
6.2.4 Questes Prticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.5 Questes ticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.6 Avaliar, Interpretar e Apresentar Dados . . . . . . . . . . . . . . . . 52
6.2.7 Durao das Sesses . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.2.8 Principais Observaes Durante a Execuo dos Testes . . . . . . . 55
7 Projeto da Nova Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.1 Seleo dos Problemas a Enderear . . . . . . . . . . . . . . . . . . . . . . 58
7.2 Anlise de Ferramentas Correlatas . . . . . . . . . . . . . . . . . . . . . . . 58
7.3 Solues Propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.4 Prototipao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8 Comparao das Verses do fazDelivery . . . . . . . . . . . . . . . . . . . . 66
8.1 Pgina Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.2 Pgina de Resultados de Busca . . . . . . . . . . . . . . . . . . . . . . . . 67
9 Concluso e Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . 72
Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
APNDICE A Outras Capturas de Interfaces de busca . . . . . . . . . . . . . 78
A.1 Exemplos de Atalhos em Resultados de Busca . . . . . . . . . . . . . . . . 78
A.2 SERP do Open Directory Project . . . . . . . . . . . . . . . . . . . . . . . 79
APNDICE B Detalhamentos de Elementos do fazDelivery . . . . . . . . . . 80
B.1 Listagem de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
B.2 Pgina Inicial Completa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.3 Portflio de Empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
B.4 Diagrama de Classes - Camada de Controle . . . . . . . . . . . . . . . . . 83
APNDICE C Roteiro para Avaliaes Heursticas . . . . . . . . . . . . . . . 84
APNDICE D Questionrio de Classicao de Severidade . . . . . . . . . . 88
APNDICE E Instrumentos para os Testes com Usurios . . . . . . . . . . . 98
E.1 Termo de Consentimento e Questionrio de Entrada . . . . . . . . . . . . . 99
E.2 Questionrio de Sada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
E.3 Tarefas de Consulta para os Testes com Usurios . . . . . . . . . . . . . . 103
13
Introduo
Ferramentas de busca so utilizadas por mais de 90% dos internautas america-
nos adultos, em sua maioria em uma base diria, segundo uma anlise da Pew Internet
(2012)
2
. Em nvel mundial, o ranking de sites do Alexa
3
lista a pgina de buscas do Go-
ogle
4
em primeiro lugar, e o mesmo vale para o ranking brasileiro
5
(Alexa Internet, Inc.,
2013a; Alexa Internet, Inc., 2013b). Estes dados ilustram a importncia de buscadores no
cotidiano das pessoas, hoje em dia, e, do ponto de vista dessas ferramentas, implicam em
uma ampla variao de usurios nais, em termos de faixa etria, escolaridade e objetivos
de busca.
Tal diversidade torna o design de interfaces para busca uma tarefa complexa.
Talvez por isso alguns tipos de sistema baseiem sua interao no conhecimento de usurios
espertos, no de usurios nais (como Merun (2012) relata que ocorria para sistemas
online de bibliotecas). Segundo Hearst (2009), essa heterogeneidade uma das razes
para que a interface de sistemas de busca tenha mudado to pouco, desde que surgiram
e eram utilizados em terminais de texto, apenas por pessoas especializadas.
O contexto em que as buscas ocorrem hoje na web bastante diverso: pessoas
de todas as reas, com conhecimentos variados de mecanismos de busca e com objetivos
distintos (trabalho, lazer...), recorrero aos mesmos buscadores para realizar suas tarefas
de pesquisa. Apesar dos desaos para modicar uma interface conhecida e utilizada por
usurios to diversos, Hearst (2011) sugere que a necessidade de adequarem-se s novas
tecnologias e seguirem a tendncia por interfaces mais naturais acabar por levar os
motores de busca a modicarem sua interface, em um futuro prximo. Este cenrio indica
que existe espao para inovaes e melhorias na IHC de sistemas de busca.
O intuito deste projeto propor e aplicar uma metodologia para avaliao e melho-
ria da usabilidade de engenhos de busca a uma ferramenta de busca do tipo diretrio (ou
catlogo), visando a uma IHC mais satisfatria e eciente, tendo como base a denio de
Nielsen (2012) de tais termos. Neste trabalho, catlogos de produtos e empresas so en-
tendidos como ferramentas de busca vertical, visto que tm bases de dados estruturadas,
bem conhecidas e com tamanho relativamente menor (em oposio base de um buscador
como o Google, que tenta enderear o mximo possvel de urls nicas de uma base com
2
Pew Internet um projeto que desde 2000 acompanha o papel e impacto da internet no cotidiano dos
estadunidenses
3
Alexa <http://www.alexa.com/> uma companhia subsidiria da Amazon. Entre outros servios,
oferece listas com os 500 sites mais visitados, no mundo, por pas ou por categorias (acesso em
novembro de 2013).
4
O Google <www.google.com> , atualmente, o engenho de busca mais utilizado e visitado na internet
(acesso em novembro de 2013).
5
A verso .br ca em primeiro. A .com, em terceiro.
Introduo 14
quantidade de fontes no apenas crescente, mas de tamanho total ainda desconhecido,
que a web). A metodologia de avaliao das interfaces proposta e as melhorias sero
aplicadas e testadas no fazDelivery
6
, um buscador georreferenciado de servios de delivery
de Salvador.
As prticas e ferramentas utilizadas neste projeto para melhorar a interao das
pginas de resultados do fazDelivery podero ser consideradas para melhorar outros siste-
mas que ofeream buscas para contextos especcos, nos quais haja interesse em aumentar
a ecincia de consulta e a satisfao de seus usurios.
Este trabalho est estruturado do seguinte modo: o Captulo 1 aprofunda concei-
tos de usabilidade e apresenta diretrizes gerais para boas interfaces. O Captulo 2 lista
mtodos utilizados para avaliar a usabilidade de sistemas e aborda tcnicas para projetar
interfaces com melhor usabilidade. Em seguida, no Captulo 3, ferramentas de busca so
apresentados em mais detalhes. Uma descrio do fazDelivery dada no Captulo 4. A
metologia utilizada neste projeto para avaliao da usabilidade das interfaces descrita
no Captulo 5. Na sequncia, os resultados da avaliao da usabilidade do fazDelivery so
apresentados e discutidos, no Captulo 6. As correes e melhorias propostas para as inter-
faces do fazDelivery so descritas no Captulo 7, e em seguida as duas verses do sistema
so comparadas, no Captulo 8. Finalmente, no Captulo 9 so discutidas as contribuies
e limitaes deste projeto, apontando algumas direes para trabalhos futuros.
6
fazDelivery - o buscador de deliveries <http://www.fazdelivery.com.br/> (acesso em dezembro de
2013).
15
1 Usabilidade
Este captulo apresenta heursticas e diretrizes para avaliao e construo de
interfaces para o usurio, partindo de conceitos mais gerais at exemplos mais especcos,
direcionados para sistemas de busca e recuperao da informao.
1.1 Denio de Usabilidade de Nielsen
Segundo Nielsen (1993), dentro do conjunto de aspectos prticos importantes para
a aceitao de um site ou sistema, a usabilidade enderea quo bem os usurios conse-
guem utilizar as funcionalidades oferecidas pelo sistema (a Figura 1 ilustra os atributos
de aceitao de um sistema). Assim, a usabilidade um elemento muito importante de
qualquer software, especialmente para ferramentas na web, onde comum haver vrias
alternativas para um mesmo servio, inclusive gratuitas, possibilitando que as pessoas
abandonem com relativa facilidade um site que no lhes agrade (NIELSEN, 2012).
Figura 1 Um modelo dos atributos da aceitabilidade de sistema. Adaptado de: Nielsen
(1993).
Como pode ser visto na Figura 1, a usabilidade geralmente entendida a partir
de cinco atributos. Nielsen (1993) explica que esta subdiviso em termos mais mensu-
rveis e precisos importante para que seja vivel entender e avaliar de forma objetiva
e sistemtica este conceito abstrato. Detalhando cada aspecto, ainda de acordo com este
autor:
Captulo 1. Usabilidade 16
Facilidade de aprendizagem: quo fcil , para usurios tendo seu primeiro con-
tato com a interface, realizar uma tarefa bsica com ela?
Ecincia de uso: uma vez que os usurios j tenham experincia com a interface,
quo rpido conseguem realizar tarefas (i.e., quo produtivos conseguem ser)?
Facilidade de memorizao: se um usurio passar um certo tempo sem utilizar
o sistema, quo fcil para ele voltar a ser produtivo, quando retoma seu uso?
Frequncia e recuperao de erros: quantos erros os usurios cometem, e com
que frequncia? Quo fcil a recuperao de tais erros? Acontecem erros graves?
Satisfao subjetiva: a interface agradvel de usar?
Uma considerao importante feita por Nielsen (1993) que a usabilidade ava-
liada em relao a determinados usurios e tarefas. Isto quer dizer que o mesmo sistema
pode apresentar caractersticas distintas se avaliado em relao a outro grupo de pessoas,
e/ou com tarefas diferentes, e deve, portanto, ser observado no momento de denio do
perl dos usurios e escolha das tarefas, para realizao de um teste de usabilidade, que
aspectos so mais importantes para a ferramenta em questo.
Assim, ainda, um software que seja utilizado apenas poucas vezes, como uma
ferramenta para auxiliar turistas, pode ento preocupar-se mais com aspectos de facilidade
de aprendizado. J um sistema com uso intermitente (e.g., o programa para declarao do
Imposto de Renda) pode buscar uma interao que privilegie a facilidade de memorizao.
Pode-se concluir ressaltando que atentar para um componente no signica negar
os outros. Como Nielsen (1993) explica, um sistema que privilegie uma boa curva de apren-
dizado inicial pode oferecer atalhos que auxiliem a produtividade do usurio experiente
e, ao mesmo tempo, incentivem um novato a melhorar seu conhecimento da ferramenta.
As prximas sees deste captulo apresentam diretrizes especcas para o design
de interfaces de busca.
1.2 Boas Prticas para Interfaces de Busca
O problema de oferecer uma boa experincia para usurios de ferramentas de busca
foco do trabalho de alguns autores. Para compor a viso do que importante levar em
considerao, esta seo apresenta as diretrizes elencadas por Shneiderman, Byrd e Croft
(1997) e Hearst (2009).
1.2.1 Diretrizes de Shneiderman para interfaces de sistemas para recuperao
da informao
Shneiderman, Byrd e Croft (1997) apresentam oito diretrizes gerais, adaptadas
para o contexto de interfaces de recuperao da informao
1
:
Buscar consistncia: deve-se assegurar a consistncia de terminologia, instrues,
layout, cores e fontes utilizadas em todas as interfaces do sistema. Tambm poss-
vel abordar esta consistncia para alm do contexto da ferramenta em si, levando-se
em considerao que (i) o usurio passa mais tempo em outros sites ou ferramentas
(i.e., fora de seu sistema)(NIELSEN, 2000a) e que (ii) qualquer experincia e co-
nhecimentos prvios que ele tiver (i.e. seus modelos mentais(SERRA, 2010)) sero
utilizados para tentar entender uma nova interface ou ferramenta apresentada.
Prover atalhos para usurios experientes: Atalhos podem ser, por exemplo, as
teclas de atalho que sistemas operacionais e outros softwares costumam oferecer;
Oferecer feedback informativo: O usurio deve ser informado de todos os aspec-
tos da busca que ele est prestes a realizar: campos buscados, o que ser buscado,
onde, e que variantes so permitidas. Isto envolve, por exemplo, indicar por que um
determinado resultado foi retornado na busca;
Projetar para a concluso: Os usurios devem saber quando buscaram em todo
um banco de dados ou viram todos os itens de uma lista. Como navegar atravs de
uma rvore com muita profundidade desorientador, Shneiderman, Byrd e Croft
(1997) sugerem que rvores mais largas, com menos nveis, so mais indicadas, pois
permitem que os usurios alcancem seu destino em menos passos, alm de reduzir a
sobrecarga da memria de curto prazo (esta outra diretriz sugerida pelos autores);
Oferecer tratamentos de erros simples, reduzir a quantidade de erros:
erros de sintaxe devem ser evitados, e as mensagens de erro devem ser claras e
evitar termos tcnicos, utilizando linguagem simples e acessvel ao usurio;
Permitir fcil reverso de aes: Idealmente, toda ao deve ser reversvel,
de modo que os usurios possam voltar para um estado anterior de sua sesso. No
contexto de buscas, um bom exemplo seria manter um histrico das consultas feitas,
possibilitando que os usurios as refaam se desejarem;
Dar suporte ao controle do usurio: Em uma interface bem projetada, os usu-
rios iniciam a ao, monitoram o progresso de buscas longas e sempre se sentem no
controle. A maioria dos usurios prefere interfaces que no foram uma sequncia
1
As diretrizes foram traduzidas do artigo citado.
de aes (e.g., eles devem poder denir os parmetros de uma busca na ordem em
que preferirem);
Reduzir a sobrecarga da memria de curto prazo: Mantenha um histrico
de sesso, de modo que os usurios sempre possam voltar e reaproveitar esforos
j feitos. No projeto de pginas da web, por exemplo, apresentaes verticais da
informao, mais compactas - que reduzam, assim, a necessidade de rolar a tela -
so altamente bencas (existe inclusive um termo para designar a regio de uma
pgina que ca visvel sem que seja necessria rolagem da tela, e que , portanto,
considerada privilegiada - above the fold
2
).
1.2.2 Diretrizes de Hearst para interfaces de busca para o usurio
Hearst (2009), em seu captulo Projeto de Interfaces de Busca para o Usurio
3
,
cita as diretrizes de Shneiderman, Byrd e Croft (1997), observando, entretanto, que no
h como seguir 100% qualquer lista deste tipo, porque muitas vezes seguir um aspecto
estritamente leva a contradizer outro; listas acabam por ser incompletas e nem todas as
diretrizes so necessrias para todos os projetos.
Apesar disto, a autora reorganiza os tpicos mais importantes de Shneiderman,
Byrd e Croft (1997) e os detalha, com contribuies de outros artigos, alm de seus
prprios trabalhos e pesquisas na rea. As suas orientaes, bastante detalhadas ao longo
do livro, so tambm mais atualizadas para o modo como ferramentas de busca, interfaces
e a web em si evoluram, nos 12 anos que separam os dois trabalhos:
Oferecer feedback eciente e informativo: este um princpio basilar de inte-
rao, que permite que o usurio entenda o status do sistema. No contexto de busca
isso signica auxiliar o usurio a entender a busca que ele est realizando, e decidir
se est indo na direo certa de sua necessidade de informao ou no. Hearst (2009)
indica:
Mostrar resultados de busca imediatamente;
Mostrar substitutos de documentos
4
informativos;
Destacar os termos da consulta;
Permitir a ordenao dos resultados por vrios critrios;
Mostrar sugestes de termos de consulta;
Usar indicadores de relevncia com moderao;
Dar suporte a tempos de resposta rpidos.
2
Acima da dobra.
3
Traduo de Design of Search User Interfaces, o livro ainda no possui traduo para o portugus.
4
O termo utilizado em ingls Document surrogate.
Balancear controle do usurio e aes automatizadas: enquanto Shneider-
man, Byrd e Croft (1997) indicam que o usurio deve ter controle total, Hearst
(2009) contemporiza sobre a questo, pois nem sempre ter de lidar com muitas op-
es prtico para o usurio nal. Na web, onde h pessoas com vrios nveis de
expertise, isto pode ser ainda mais crtico. Dois pontos que ela destaca como im-
portantes de mediar o nvel de controle do usurio versus automatizao do sistema
so:
Ordenao de posies dos resultados, nas busca na web;
Transformaes na consulta.
Reduzir a sobrecarga da memria de curto prazo: o sistema deve ter formas
de apresentar informaes teis ao usurio ao longo de seu processo de busca, ao
invs de deixar a cargo deste lembrar-se das coisas. Alguns pontos em que possvel
agir sobre este aspecto:
Sugerir a ao de busca no campo de entrada;
Suportar mecanismos simples de histrico;
Integrar navegao e busca.
Oferecer atalhos: observando que a ideia comum de atalhos que se tem, do tipo
combinaes de teclas, exige que usurios memorizem tais combinaes, Hearst
(2009) d exemplos mais prticos de atalhos para o contexto de buscadores na
web, como:
Para o primeiro resultado de uma busca, oferecer links comumente visitados do
subdomnio em questo (tambm conhecidos como sitelinks; vide a Figura 2,
onde, alm do link principal para o Vitrine Inversa, so listados, diretamente,
links para Poltica de Privacidade e Termos de Servio, entre outros);
Para tipos muito bem denidos de necessidade e formatos de busca, alguns
buscadores tentam adivinhar a necessidade do usurio, oferecendo, antes da
listagem de resultados, a provvel resposta (a Figura 3, por exemplo, mostra o
Bing prevendo uma necessidade por uma operao algbrica. Para este tipo de
consulta, o Google vai ainda mais longe, mostrando no apenas o resultado do
clculo, mas uma calculadora (vide Figura 20, no Apndice A). Ainda nesta
gura, possvel ver, no canto direito, links para buscas relacionadas, que
funcionam como outra forma de atalho.).
Reduzir erros: Alm dos erros de sistemas, que Nielsen (1993) e Shneiderman,
Byrd e Croft (1997) endeream, o intuito das aes propostas por esta diretriz o
de evitar que usurios cometam erros, ao buscar, que os afastem de sua necessidade
de busca (e.g. por no conhecer os melhores termos para a consulta que desejam
realizar). Hearst (2009) salienta que algumas outras diretrizes, bem implementadas,
ajudam a lidar com isso, por exemplo, na medida em que sugestes de termos para
consulta podem evitar erros de ortograa que poderiam levar a zero resultados. E
enfatiza que se tente, principalmente:
Evitar listas de resultados vazias;
Enderear o problema do vocabulrio.
Reconhecer a importncia de pequenos detalhes: pequenas mudanas, como
tamanhos maiores do formulrio de entrada; ordem de aparecimento das informaes
nos document surrogates
5
; e at mesmo o tamanho de frases de sugesto de termos
podem fazer muita diferena na interao e sucesso dos usurios em suas tarefas;
Reconhecer a importncia da esttica no design: Hearst (2009) ressalta que:
Um designer de interfaces de busca precisa equilibrar as escolhas de
layout, localizao e quantidade de espao em branco (frequentemente
chamado de espao vazio), cor, contrastes entre estilo, peso e tamanho
das fontes. A importncia da aplicao dos princpios de design grco
est bem estabelecida na literatura sobre IHC (HEARST, 2009, p. 26)
6
.
Detalhando melhor este tpico, esta autora traz um estudo comentado em Hotchkiss
(2007), feito pela Enquiro Research(HOTCHKISS et al., 2010), em que usurios do
Yahoo!
7
e do MSN
8
foram monitorados enquanto faziam pesquisas utilizando o
Google, e relata que em quase todas as mtricas avaliadas este mecanismo de busca
se saiu melhor do que os preferidos dos usurios, no necessariamente porque os
resultados eram melhores, mas por conta de aspectos da pgina de resultados do
Google que, apesar de menores, eram muito bem planejados e testados.
5
Ao longo deste trabalho ser utilizada a traduo sumrio de documento, para o termo.
6
Traduo prpria.
7
Portal Yahoo! <http://www.yahoo.com/> (acesso em novembro de 2013).
8
Portal MSN <http://www.msn.com/> (acesso em novembro de 2013).
Figura 2 Um exemplo de atalho, em ferramentas de busca: o primeiro resultado do
Google para a busca por Vitrine Inversa, mostrando alguns links do domnio
em questo (conhecidos como sitelinks).
Figura 3 Dois tipos de atalhos: para a busca por 3 + 5, o Bing oferece, como primeiro
resultado, o resultado da operao matemtica. Tambm possvel observar,
no canto direito, links para pesquisas relacionadas.
22
2 Avaliao e Design de Interfaces de Busca
Para a maioria das tcnicas indicadas de projeto de interfaces, hoje em dia, design
e avaliao ocorrero de forma alternada e complementar. Hearst (2009) oferece uma
explicao para isso:
This iterative procedure is necessary because interface design is still more
of a practice than a science. There are usually several good solutions within
the interface design space, and the task of the designers is to navigate through
the design space until reaching some local optimum. The iterative process
allows study participants to help the designers make decisions about which
paths to explore in that space. (...) Evaluation is part of every cycle of the
user-centered design process(HEARST, 2009, p. 6)
1
.
Alm disso, como se ver mais a frente, so justamente avaliaes e experimentos
controlados que possibilitam comparar interfaces e generalizar boas prticas para sua
construo, passos importantes na direo de aproximar esta rea de abordagens mais
cientcas. Este captulo, assim, aborda aspectos de avaliao e design de interfaces.
2.1 Abordagens e Tipos de Avaliao de Interfaces
Existem vrias tcnicas de avaliao de interfaces possveis, a depender do ora-
mento, do projeto, do estgio de desenvolvimento e de quem avalia a interface. Hearst
(2009, Cap. 2) oferece um bom apanhado de tcnicas para avaliar interfaces de busca, que
podem se adequar a diversos cenrios e necessidades. Eis um resumo de cada uma:
Avaliao padro de sistemas de recuperao da informao: focada em
mensurar a qualidade dos resultados retornados. Apesar de no se relacionar com o
aspecto grco de usabilidade, um engenho de busca que no retorne bons resultados
pode inuenciar muito na produtividade dos usurios e conana no sistema, por
exemplo (conabilidade um dos aspectos de aceitao de um sistema, como pode
ser conferido na Figura 1);
1
"Este procedimento iterativo necessrio porque o projeto de interfaces ainda mais uma prtica
do que uma cincia. Normalmente h vrias possveis boas solues no espao de designs de uma
interface, e a tarefa dos designers navegar neste espao at alcanar algum timo local. O processo
iterativo permite estudar os participantes para ajudar os designers a tomarem decises sobre quais
caminhos explorar nesse espao. (...) A avaliao parte de cada ciclo do processo do design centrado
no usurio. Traduo da autora.
Captulo 2. Avaliao e Design de Interfaces de Busca 23
Testes informais de usabilidade: no existe frmula especca para sua condu-
o. Podem ser realizados com poucas pessoas, com prottipos de papel, por exem-
plo, anotando suas respostas e interaes. Outra abordagem possvel a Avaliao
Heurstica, em que especialistas em usabilidade inspecionam o sistema, com vistas a
encontrar problemas de usabilidade. Estas tcnicas so mais indicados para estgios
iniciais de desenvolvimento da interface e interessantes tambm para projetos com
oramento reduzido, tanto assim que os mtodos que fazem parte do que Nielsen
chama de Usabilidade com Desconto
2
(NIELSEN, 2009), so referidos aqui;
Estudos formais e experimentos controlados: indicados quando: se trata de
uma pesquisa cientca na rea; ou uma companhia quer avaliar quanto uma nova
funcionalidade agrega para um design; ou para comparar interfaces. Este tipo de m-
todo costuma utilizar tcnicas que mensuram variveis como movimento dos olhos,
quantidade de cliques, tempo para concluso de tarefas, capturas de telas, gravao
de voz e vdeo etc. Normalmente so feitos em laboratrios de usabilidade, com
cmeras, observadores etc., mas j existem softwares para dar suporte a testes re-
motos. Mesmo existindo alguns aspectos negativos nesse caso, pois no se observam
os feedbacks de gestos e expresses e os participantes podem esquecer de comentar
seu processo cognitivo em voz alta, j que esto sozinhos, o fato de que possvel
alcanar mais pessoas, geogracamente, e acess-las em seu ambiente normal de uso
das ferramentas tem pesado em favor dessa opo;
Estudos longitudinais: so estudos em que, ao invs de observar usurios uti-
lizando a ferramenta em laboratrio em sesses pontuais, grupos de usurios so
convidados a utilizar uma ferramenta durante longos intervalos de tempo, em seu
cotidiano, em seu prprio ambiente. O acompanhamento pode ser feito atravs de
questionrios, bem como pela quantidade de vezes em que os participantes escolhe-
ram utilizar a ferramenta. Eles permitem, por exemplo, entender como o compor-
tamento dos usurios muda na medida em que se adaptam interface, e como os
participantes interagem com a interface em diferentes necessidades de informao;
Anlise de arquivos de logs de servidores de engenhos de busca: atravs
de informaes como: consultas feitas; links escolhidos e endereos de IP; gravados
em grandes volumes nos logs dos servidores de busca, acerca de todos os usurios
que utilizam o sistema, possvel entender melhor os tipos de necessidade de infor-
mao da base de usurios de uma ferramenta de busca, melhorar pontuaes de
ordenamento de resultados e outras coisas do gnero;
Testes de usabilidade de larga escala baseados em logs: estes testes tambm
so conhecidos como teste A/B, e so teis para sistemas web, que podem alterar
2
O termo original Discount Usability. Esta escolha de traduo foi baseada em resultados de citaes
encontrados na internet.
e entregar novas interfaces de forma dinmica (em oposio ao que ocorre com
softwares de prateleira). Trabalha-se com a segmentao dos usurios que acessam o
sistema, para mostrar diferentes verses de interface ou de interao. Estas verses
podem conter apenas pequenas mudanas, como mudana de localizao de um
boto, ou testar grandes alteraes de interface. Para acompanhar os resultados,
novamente faz-se uso dos logs dos servidores, mas desta vez os usurios so de
algum modo identicados, para se manter a consistncia da interface mostrada ao
longo de vrias sesses. Para que sejam estatisticamente vlidos, importante que
haja um grande volume de usurios ativos, ou que se deixe rodando at que um
nmero signicante de interaes tenha ocorrido. Um adendo interessante que
estes testes tambm so muito comuns no marketing(GEORGIEVA, 2012), sendo
utilizados para testar taxa de abertura de e-mails e denir discursos com melhor
aceitao em pginas iniciais para produtos inovadores, por exemplo.
Merun (2012) trabalha com uma diviso mais sucinta de mtodos para avaliao
da usabilidade, de acordo com serem baseados na avaliao de especialistas (mtodos
de inspeo, onde se enquadra a Avaliao Heurstica) ou observao de interaes dos
usurios (mtodos de teste, que englobam os testes de usabilidade). O citado trabalho
tambm traz explicaes mais direcionadas de como conduzir tais mtodos.
Tendo-se em vista o oramento limitado para este projeto, e seguindo a experin-
cia de Moraes (2010), os mtodos de aferio de interfaces escolhidos foram a Avaliao
Heurstica e os Testes de Usabilidade com Usurios. Apesar de no possuir uma base com
usurios, como o fazDelivery encontra-se online durante a realizao deste trabalho, tam-
bm possvel utilizar, para complementar a avaliao e comparao, testes A/B entre a
interface vigente e a proposta. As prximas sees abordam em mais detalhes os mtodos
de avaliao utilizados neste trabalho.
2.2 Avaliao Heurstica
Avaliao heurstica uma das formas de mensurar a usabilidade de um sistema
atravs do conhecimento de avaliadores de interface, que no precisam ter conhecimento
da rea de domnio da aplicao (para outros mtodos de avaliao do gnero, pode-
se conferir Nielsen (1995e)). Uma ou algumas sesses, em que cada avaliador percorre,
sozinho, todas as telas do sistema, so feitas, durante as quais ele preenche uma lista
de problemas de usabilidade encontrados, baseado, normalmente, em um conjunto de
heursticas preestabelecidas(NIELSEN, 1995a; NIELSEN, 1995c).
possvel construir listas de heursticas especcas para categorias de produtos,
por exemplo, realizando anlise e testes de usabilidade de produtos existentes nesta dada
categoria e extraindo princpios abstratos que expliquem os problemas de usabilidade
encontrados(DYKSTRA, 1993 apud NIELSEN, 1995c).
As sesses de avaliao costumam durar uma ou duas horas. Alm do avaliador,
tem-se um observador, que pode tirar dvidas que surjam e tomar notas dos problemas en-
contrados pelo avaliador. importante, para evitar o comprometimento de opinies, que
os participantes da avaliao no conversem sobre suas impresses antes que se concluam
as sesses. Depois, uma conversa entre todos os avaliadores, o observador e os designers
representantes da equipe responsvel pela interface pode ser benca, para discutir pos-
sveis solues para os problemas encontrados e destacar pontos positivos, que no so
enfocados durante a avaliao heurstica.
Uma vez que no busca avaliar a capacidade do sistema de realizar tarefas, mas
seu comprometimento com princpios bsicos de interao, a avaliao heurstica pode
ser realizada no apenas com softwares em produo, mas tambm com prottipos de
papel, por exemplo. No entanto, Nielsen (1995b) ressalta que, como prottipos de papel
obviamente no so funcionais, os avaliadores tendem a no prestar tanta ateno a
problemas de usabilidade do tipo falta acrescentar algo a esta interface quando avaliando
prottipos de papel.
Nesse mesmo artigo, Nielsen explicita que a melhor forma de utilizar a avaliao
heurstica combinando-a iterativamente com testes de usabilidade. Isto porque, pri-
meiro, dada a diferena de perspectiva que um especialista em interfaces e um usurio
nal buscando interagir com o sistema tero deste, os problemas encontrados em cada
abordagem tendem a ser complementares(NIELSEN, 1995b). Alm disso, no faz sentido
realizar testes para encontrar problemas, no corrigi-los e fazer uma nova anlise. Assim,
uma boa medida realizar primeiro a avaliao heurstica, que permite capturar e corrigir
erros mais graves (ou tcnicos) sem gastar o tempo dos usurios, realizar uma etapa de
correo dos principais erros encontrados e, ento, realizar os testes de usabilidade, aps
os quais uma nova fase de melhorias pode ocorrer.
Independente de como ser conduzida esta questo, importante atentar para a
quantidade de avaliadores que participaro do processo. Nielsen(NIELSEN, 1995c; NIEL-
SEN, 1995b) observa que utilizar apenas um avaliador no indicado, pois este tem em
mdia apenas 42% de probabilidade de encontrar problemas graves de usabilidade, e tal
probabilidade cai para 32% para problemas menores (para uma classicao da severidade
de problemas de usabilidade, pode-se acessar Nielsen (1995d)). Ainda que o nmero de
avaliadores possa variar com o custo-benefcio da mensurao para o sistema, a sugesto
que se trabalhe com um nmero mnimo de 3 a 5 avaliadores.
Os princpios gerais de usabilidade que costumam ser aferidos nas avaliaes heu-
rsticas so listados abaixo (para uma viso mais detalhada de cada tpico, possvel
conferir Nielsen (1993, pp. 115155)). Nielsen (1995a) explica que estes princpios so cha-
mados de heursticas por tratarem-se mais de bom senso do que de diretrizes estritas.
possvel correlacionar muitos destes tpicos s diretrizes citadas nas sees anteriores,
o que faz sentido, dado que todos tm o mesmo propsito nal
3
:
Visibilidade do status do sistema (feedback): o sistema sempre deve manter os
usurios informados sobre o que est acontecendo, atravs de feedback apropriado
e em tempo hbil;
Compatibilidade entre o sistema e o mundo real (metfora): o sistema
deve falar a linguagem do usurio, com palavras, frases e conceitos familiares a ele,
ao invs de utilizar termos tcnicos. Deve-se seguir convenes do mundo real. A
informao deve aparecer em uma ordem lgica e natural;
Controle e liberdade para o usurio (navegao): os usurios frequentemente
escolhem funes do sistema sem querer, e precisaro de sadas de emergncia
bem denidas para sair de um estado indesejado de forma rpida e simples. Deve
dar suporte a aes de desfazer, refazer, cancelar;
Consistncia e padres (consistncia): os usurios no devem precisar se per-
guntar se diferentes palavras, situaes ou aes signicam a mesma coisa. Seguir
padres na plataforma;
Preveno de erros (preveno): melhor do que oferecer boas mensagens de erro
ter um design cuidadoso, que previna que problemas ocorram, em primeiro lugar.
Eliminar condies propensas a erros, ou checar quando acontecerem, apresentando
aos usurios opes de conrmao antes de eles realizarem tais aes;
Reconhecimento ao invs de lembrana (memria): minimizar a sobrecarga
da memria dos usurios, tornando objetos, aes e opes visveis. O usurio no
deve precisar lembrar de informaes de uma parte da tela para outra. Instrues
para uso do sistema devem ser visveis ou fceis de encontrar sempre que apropriado;
Flexibilidade e ecincia no uso (ecincia): aceleradores (ou atalhos) - que
no precisam estar visveis para usurios novatos - podem, frequentemente, acelerar
a interao do usurio experiente, de forma que o sistema atenda a pessoas com
variados nveis de experincia;
Design e esttica minimalistas (design): as telas no devem conter informao
que no relevante, ou que raramente necessria. Cada unidade extra de informa-
o em uma tela compete com as relevantes e diminui sua visibilidade relativa;
3
Traduo livre da apresentao das heursticas feita por Nielsen (1995a)).
Auxiliar usurios a reconhecer, diagnosticar e se recuperar de erros (re-
cuperao): mensagens de erro devem ser expressas em linguagem simples e direta
(no em cdigos), indicar precisamente qual o problema e sugerir solues;
Ajuda e documentao (ajuda): ainda que seja melhor que o sistema possa ser
utilizado sem manuais, pode ser necessrio prover ajuda e documentao. Qualquer
informao deste tipo deve ser fcil de buscar, focada na tarefa do usurio, listar
etapas concretas para sua realizao e no ser muito grande.
2.3 Testes de Usabilidade
Para se orientar no que importante para a avaliao de interfaces, Moraes (2010)
utilizou o seguinte framework, sugerido por Rogers, Sharp e Preece (2002 apud MORAES,
2010):
1. Determinar as metas que a avaliao ir abordar;
2. Explorar as questes especcas a serem respondidas;
3. Escolher o paradigma de avaliao e as tcnicas de respostas para as perguntas;
4. Identicar as questes prticas que devem ser abordadas, como a seleo dos parti-
cipantes;
5. Decidir como lidar com as questes ticas;
6. Avaliar, interpretar e apresentar os dados.
Seguir algo do gnero importante, por exemplo, para no se perder o foco do que
mais relevante avaliar, e porque, para cada aspecto a se avaliar, algumas tarefas e pers
podem ser mais teis que outros, como dito anteriormente (vide Seo 1.1).
Segundo Merun (2012), h duas abordagens principais para testes de usabilidade,
que diferem na forma como seus resultados sero utilizados no ciclo de desenvolvimento
do sistema:
Testes formativos: como o nome sugere, so mais indicados ainda na fase de
desenvolvimento da interface, quando seus resultados podero ter um impacto maior
no design. So qualitativos, utilizando-se de tcnicas como pensar em voz alta, e
podem ser conduzidos em pequenos grupos de participantes, com foco em descobrir
que tipos de problema de interao ocorrem, e porqu;
Testes sumativos: normalmente feitos com uma ateno mais voltada para aspec-
tos globais de funcionamento do sistema, buscando avaliar se o sistema corresponde
s metas do projeto e como se compara em relao a competidores. Para este tipo
de anlise, mensuraes quantitativas, como tempo para completar tarefa e nmero
de cliques, so feitas e posteriormente analisadas estatisticamente.
Para ambos os mtodos, estudos de laboratrio so abordagens comuns para a conduo
dos experimentos. No entanto, enquanto um teste formativo pode ser bem servido com
um experimento de observao, testes sumativos envolvero, por exemplo, experimentos
formais. Isto os torna mais custosos em termos de tempo e dinheiro, e exige uma con-
gurao mais rigorosa de ambiente, mas agrega a vantagem de torn-los mais replicveis
- e, portanto, como j dito, teis para comparao de interfaces, ou para generalizar
concluses(HEARST, 2009).
2.3.1 Perl e quantidade de participantes
Em relao ao nmero de usurios necessrios para tornar os resultados de um
teste de usabilidade vlidos, h bastante discusso. Para Nielsen (2000c), 5 usurios so
necessrios para encontrar a maior parte dos problemas de usabilidade de uma interface.
Contribuindo para a discusso, Lindgaard e Chattratichart (2007 apud HEARST,
2009) comparam o desempenho de diferentes grupos avaliando um mesmo design de inter-
face, variando o nmero de participantes em cada grupo. Eles no encontraram correlao
direta entre nmero de participantes e problemas encontrados, mas, sim, entre a quanti-
dade de tarefas designadas aos participantes e o nmero de problemas encontrados.
Em sua experincia, Tullis e Albert (2010) concluem que 5 participantes por perl
signicativo de usurio, i.e., por pers que representem os usurios alvo do sistema, para
um escopo bem denido e limitado de avaliao, funcionam bem.
Destas vises, talvez uma boa abordagem a seguir seja, de acordo com o oramento
do projeto, denir grupos representativos de cada segmento de usurios almejado, com
cerca de 5 pessoas cada, e trabalhar com variadas tarefas e cenrios de testes.
2.4 Design Centrado no Usurio
Idealmente, no processo de construo de um produto ou interface, primeiro deve-
se descobrir ou encontrar um problema ou necessidade real do usurio (a este processo
d-se o nome de Need Finding - busca pelas necessidades).
A partir da denio de um problema, ento, sempre em contato com usurios
representantes das pessoas que utilizaro o sistema, comea-se o desenvolvimento do pro-
jeto, de forma iterativa e incremental, sempre partindo do foco da interao do usurio
para resolver suas necessidades. Como Merun (2012) apresenta, o formato ideal que as
necessidades dos usurios sejam mandatrias para a construo da interface, e as neces-
sidades de interface ditem o que haver nas camadas subjacentes do sistema.
Esta abordagem de desenvolvimento de ideias e interfaces, conhecida como De-
sign Centrado no Usurio, mas recebe outras nomenclaturas, de acordo com a rea que
a estiver citando, e h muitas metodologias que visam ampar-la, tambm advindas de
muitas reas. Do design e marketing pode-se citar, por exemplo, a Business Model Genera-
tion
4
(OSTERWALDER; PIGNEUR, 2010), do empreendedorismo de inovao tecnolgica
das start ups, a Metodologia Enxuta(RIES, 2011; MAURYA, 2012).
Ocorre, entretanto, que as presses por entregar projetos em tempo hbil para o
mercado(NIELSEN, 2000b); a falta de cultura em se trabalhar junto a usurios e, por
vezes, a falta de prossionais da rea de design e/ou design de interao, levam a proje-
tos com desenvolvimentos que, mesmo quando se preocupam em identicar necessidades
reais do usurio, so conduzidos com pouca ou nenhuma interao com os mesmos. A
consequncia disso a existncia de muitas interfaces com problemas de usabilidade, em
um ou vrios dos aspectos que a caracterizam.
Uma vez que j se tem um design pronto e que no se trabalhou to intensamente
junto aos usurios ao longo de seu desenvolvimento, um percurso metodolgico possvel
para melhorar sua usabilidade o percorrido por Moraes (2010): avalia-se a interface
existente em busca dos problemas mais graves de usabilidade, e esta avaliao serve para
melhorar a interface do sistema. Pode-se tambm aproveitar o contato realizado nos testes
de usabilidade para iniciar um dilogo mais constante com os usurios.
A interface atual do sistema utilizado no estudo de caso deste projeto seguiu um
padro de desenvolvimento similar ao que acontece com muitas outras ferramentas no
mercado, e que levam, como dito, a problemas de usabilidade. Como, o percurso de evolu-
o da interface no seguir uma construo do zero, este trabalho focar na correo dos
problemas encontrados pelos testes, buscando aplicar as diretrizes e heursticas especcas
citadas em sees anteriores deste trabalho (Seo 1.2, Seo 2.2).
Para projetos que sigam o design centrado no usurio, o comum trabalhar com
prottipos que passam por um nvel crescente de delidade e funcionalidade. Nas fases
iniciais, tem-se vrias propostas de design para a interface, que so colocadas prova
pela equipe e com testes de usurios. As interfaces mais bem sucedidas evoluem em
complexidade. Pode-se comear com prottipos de papel, depois para representaes mais
realistas, mas ainda no funcionais das telas, e que vo, gradativamente, se transformando
em telas com as quais possvel interagir. Esta abordagem possibilita economizar no
desenvolvimento de interfaces que ainda podem ter muitos problemas, e s codicar de
4
Gerao de modelos de negcio.
fato o sistema quando se tem uma noo muito clara de como deve ser sua interface - o
que evita, tambm, que mdulos e funcionalidades desnecessrias sejam construdos.
Este captulo trouxe uma viso geral de tcnicas para avaliao e projeto de inter-
faces. O prximo apresenta ferramentas de busca em mais detalhes, visto que estas so o
foco deste trabalho.
31
3 Ferramentas de Busca
Buscadores so ferramentas amplamente utilizadas na web. Um estudo da Pew
Internet (2012)
1
relata que 90% dos internautas americanos adultos as utilizam em uma
base diria, em sua maioria, por exemplo.
Em termos simples, uma ferramenta de busca um programa de computador que,
para uma determinada consulta, lista uma srie de resultados possveis. Os mais populares
trabalham com buscas por palavras-chave, i.e., o tipo de entrada para a consulta so
termos textuais, que sero pesquisados na base de dados de documentos do buscador.
As prximas sees trazem mais detalhes destes sistemas to inseridos no cotidiano
de pessoas que utilizam a internet.
3.1 Tipos de Ferramentas de Busca
O tipo e implementao do sistema de busca denir onde os termos sero pes-
quisados, o tipo de resultados retornados, bem como a qualidade e quantidade de tais
resultados(CENDN, 2001).
Segundo Cendn (2001), caracterizando-se de acordo com o modo como agregam
a informao, h trs tipos de ferramentas de busca:
diretrios tm seus documentos divididos em categorias e, muitas vezes, tm bases
curadas por pessoas;
engenhos de busca, que tm programas automatizados que percorrem a web cons-
tantemente, para descobrir e indexar novos sites;
meta-motores que possibilitam buscar em vrias ferramentas de busca ao mesmo
tempo.
Atualmente, o termo engenho de busca mais comum, e costuma ser mais utilizado,
para qualquer caso. As ferramentas podem ser de cunho geral, como o Google, ou verticais
(especcos por rea ou propsito), por exemplo, para buscar receitas, como o Yummly
2
,
ou materiais jurdicos, como o JusBrasil
3
.
1
O Pew Internet um projeto que desde 2000 acompanha o papel e impacto da internet no cotidiano
dos estadunidenses.
2
Yummly - buscador de receitas online <http://www.yummly.com/> (acesso em novembro de 2013)
3
JusBrasil - a misso do portal da JusBrasil organizar e tornar acessvel a informao jurdica
brasileira <http://www.jusbrasil.com.br/> (acesso em novembro de 2013).
Captulo 3. Ferramentas de Busca 32
Para mais exemplos de ferramentas e engenhos de busca, podem-se acessar os
endereos:
The Search Engine List: http://www.thesearchenginelist.com/
Lista de engenhos de busca da Wikipedia:
http://en.wikipedia.org/wiki/List_of_search_engines
Apesar de haverem diversas formas de visualizar os resultados e mesmo de realizar
consultas, possvel entender o processo de busca em termos de alguns elementos bsicos,
detalhados nas prximas sees.
3.2 Modelos de Processo de Busca
Uma forma de pensar uma ferramenta de busca, coerente com a viso de design
e desenvolvimento centrados no usurio, abordar o processo cognitivo pelo qual uma
pessoa passa e que leva a uma busca. Serra (2010) apresenta uma descrio bem sucinta de
modelos mentais de busca por informao. O terceiro captulo de Hearst (2009) dedicado
a apresentar diversos modelos do processo de busca por informao.
Para o escopo deste projeto, o modelo padro de processo de busca apresentado
em Broder (2002), em conjunto com o framework de quatro fases de Shneiderman, Byrd
e Croft (1997), traz um bom aparato para o momento seguinte, de entendimento dos
elementos de interface de uma ferramenta de busca. A Figura 4 apresenta tal modelo, que
indica que toda busca surge de uma necessidade de informao, que por sua vez advm
de alguma tarefa. De modo similar, o framework de Shneiderman, Byrd e Croft (1997)
identica quatro fases importantes em uma busca, e que devem, na medida do possvel,
serem amparadas pelo design do sistema: i) Formulao da consulta; ii) Ao; iii) Reviso
dos resultados; e iv) Renamento.
A seo seguinte mostra como tais elementos so endereados, de forma geral, em
ferramentas de busca existentes.
3.3 Elementos Bsicos de Interfaces de Ferramentas de Busca
Wilson (2012) apresenta uma taxonomia bastante compreensiva de elementos do
design de interfaces de busca para o usurio. O autor identica 4 tipos distintos de fun-
cionalidades para o usurio: para entrada da consulta; para controle; que contm
informao; e personalizveis. Para cada tipo h vrios exemplos, tornando o material
interessante para quem deseja um entendimento aprofundado de interfaces de busca para
o usurio.
Figura 4 Modelo padro do processo de busca, adaptado do proposto por Broder (2002).
Entender estes modelos cognitivos ajuda a pensar o que importante para uma
interao de sistema de busca.
Em uma viso mais simples, os principais elementos de interao de uma ferra-
menta de busca para amparar o processo de busca por informao podem ser listados
abaixo (entre parnteses, faz-se a correlao com a fase apresentada por Shneiderman,
Byrd e Croft (1997):
1. Campo de entrada da consulta (para formulao da consulta ou renamento):
podero ser, por exemplo: termos, imagens, voz etc.;
2. Controle para a ao de buscar (ao): algumas ferramentas podem iniciar
a ao automaticamente, enquanto outras exigiro que se informe explicitamente
para realiz-la (normalmente atravs de um boto, ou da ao da tecla Enter do
teclado);
3. Exibio dos resultados (reviso dos resultados): as SERPs, como tambm so
chamadas, exibem os itens de resultado que correspondem busca feita;
4. Substituto de documento (reviso dos resultados): como chamado cada item da
listagem de resultados. Como tal, contm vrias informaes para auxiliar o usurio
a avaliar a relevncia do resultado para sua consulta, como ttulo, url, termos da
consulta destacados; e
5. Um Sumrio de documento (reviso dos resultados): um excerto do resultado,
preferencialmente contendo os termos da consulta, contextualizados no documento
e destacados de algum modo.
Foram escolhidas duas interfaces de buscadores para ilustrar a presena de tais
elementos: o CiteSeerXbeta, um engenho de busca e biblioteca digital de artigos cient-
cos
4
e o Open Directory Project
5
, que se dene o maior e mais abrangente diretrio da
web editado por seres humanos
6
. A motivao para escolher estas duas ferramentas foi,
por um lado, trazer exemplos distintos de buscadores, para aumentar o leque de interfaces
apresentadas neste trabalho e, por outro, mostrar exemplos tanto de engenhos de busca
quanto de diretrios.
Podem ser vistos, destacados por heptgonos em cada gura, os elementos do
processo de busca recm descritos. As Figuras 5 e 7 mostram o CiteSeerXbeta; os nmeros
destacam: 1) Campo para entrada da consulta; 2) Boto que indica realizao da ao de
buscar; 3) A pgina de resultados em si; 4) Um substituto de documento; e 5) Um sumrio
de documento. Nas Figuras 6 e 8 v-se o Open Directory, e destacam-se: 1) Campo para
entrada da consulta; 2) Boto que indica realizao da ao de buscar; 3) A pgina de
resultados em si; 4) Um substituto de documento; e 5) Um sumrio de documento. A
seta preta contendo os nmeros 1 e 2, apontando para baixo, deve-se ao fato de que nesta
pgina tais campos aparecem apenas ao nal.
Uma observao que pode ser feita em relao pgina de resultados do Open
Directory que, devido ao design de sua interface, com os campos 1 e 2, que podem servir
para renar a consulta (refazendo-a), esto localizados apenas no nal da pgina, fora da
regio above the fold da tela, no caso de serem retornados muitos resultados, os campos
de busca no cam visveis, podendo parecer, para um usurio novato, que o sistema no
prov esses campos em sua pgina de resultados (uma captura completa desta tela pode
ser vista no Apndice A, Figura 21).
3.4 Aspectos de Evoluo da Usabilidade de Ferramentas de Busca
Como Hearst (2009) detalha, historicamente, interfaces para mecanismos de busca
surgem em contextos fechados e muito especcos: pessoas habilitadas faziam consultas,
muitas vezes em terminais de texto, sobre elementos pr-determinados - ttulo, descrio,
4
CiteSeerXbeta - <http://citeseerx.ist.psu.edu/> (acesso em novembro de 2013).
5
Projeto Diretrio Aberto
6
Open Directory Project <http://www.dmoz.org/> (acesso em novembro de 2013).
Figura 5 Pgina inicial do CiteSeerXbeta.
Figura 6 Pgina inicial do Open Directory Project.
alguns metadados - de bases de dados privadas. Os resultados desta primeira busca leva-
vam a uma segunda pesquisa, desta vez nos objetos (textos) fsicos indicados pela consulta.
A mudana do cenrio hoje, que traz toda sorte de pers de pesquisadores, bem
como do tipo de fontes pesquisadas, acarreta em uma necessidade maior de se preocupar
com a usabilidade das interfaces de busca atuais, mas por outro lado, tambm, trazem
a diculdade de insero de inovaes, por se tratar de uma base de usurios muito
diversicada - ou seja, como denir um perl de usurio que seria colocado em foco, para
Figura 7 Pgina de resultados do CiteSeerXbeta.
Figura 8 Pgina de resultados do Open Directory Project.
constru-la?
Para Hearst (2011), a evoluo de interfaces no geral, e da experincia de usurio
oferecida por elas, levar necessariamente a uma mudana nas interfaces de buscadores,
tambm. Uma alternativa de abordagem para inserir novas interaes podem ser os en-
genhos de busca verticais como fazDelivery, visto que possibilitam trabalhar com uma
variao menor de usurios ou de objetivos de consulta.
Em relao s SERPs, a etapa de interao visada neste projeto, podem ser feitos
alguns questionamentos:
Que solues de usabilidade ou interface podem ser oferecidas para ltrar e/ou
reordenar documentos?
Como melhorar a navegao entre os resultados exibidos (questo que tambm en-
volve a apresentao dos substitutos de documentos)?
Como aproveitar o contexto de buscadores especcos para oferecer substitutos de
documentos mais otimizados para o tipo de consulta neles realizada?
Endereando consultas especcas, e seguindo a diretriz de oferecer atalhos aos
usurios, o Google, por exemplo, exibe alguns resultados com formato diferenciado, para
consultas por delivery, ou que contenham nomes de restaurantes. Isto corrobora a per-
cepo de que possvel fazer alteraes signicativas na usabilidade de uma interface,
quando se conhece melhor as necessidades de informao do usurio.
Estes captulo apresentou elementos principais da interface de uma ferramenta de
busca, e a questo sobre as diculdades para se realizar mudanas em sua usabilidade.
O prximo captulo descrever o fazDelivery, ferramenta de busca utilizada no estudo de
caso deste projeto.
38
4 O fazDelivery
O fazDelivery uma ferramenta de busca para encontrar produtos e servios de
fornecedores que oferecem delivery. , assim, um buscador vertical focado em delivery.
Ele foi desenvolvido e mantido pela Apimenti, uma empresa de solues de software
para internet com sede em Salvador-BA.
4.1 Descrio Geral
A verso atual do fazDelivery tem sua base de dados preenchida de modo no auto-
matizado. Para garantir a qualidade das informaes constantes (visto que conabilidade
nos resultados da busca considerada um aspecto de usabilidade, como visto na Seo
2.1), optou-se por fazer uma curadoria dos produtos e empresas inseridos e, portanto, a
utilizao de um rob para coletar automaticamente sites e informaes de empresas e
seus produtos foi descartada para o momento.
O sistema tem dois componentes bem distintos: um voltado para os consumidores,
relacionado busca de produtos ou visualizao de portflios de empresas; e um voltado
para as empresas, de carter gerencial, que permite cadastro e edio das informaes
relevantes para a busca e mostradas no portflio. Este projeto foca nas interfaces de
busca, e portanto no abordar o componente voltado para as empresas. A interface
para visualizao de portflios, como pode funcionar de modo independente busca,
tambm no entra neste escopo (uma captura de tela de um portflio do fazDelivery foi
acrescentada ao Apndice B, para melhorar a caracterizao do sistema. Vide a Figura 24).
O restante deste captulo descreve as interfaces do fazDelivery que so voltadas
para os consumidores (Seo 4.2) e caractersticas de implementao da ferramenta rele-
vantes para o contexto deste trabalho (Seo 4.3).
4.2 Interfaces do fazDelivery para Consumidores
Esta parte do sistema composta por trs telas principais: a pgina inicial, a
partir da qual j possvel fazer uma consulta; a pgina de resultados, que exibe uma
listagem de produtos ou servios relativos a uma dada busca; e o portflio de empresa,
que lista todos os produtos ou servios de uma empresa cadastrados na plataforma, e
pode ser acessado diretamente por url, sem dependncia da busca.
Captulo 4. O fazDelivery 39
4.2.1 Pgina inicial
A pgina inicial do fazDelivery traz elementos para apresentao da ferramenta,
considerados importantes por se tratar de um servio novo, e campos para que um visitante
possa realizar uma consulta. Alm disso, exibido um mapa que indica a localizao das
empresas cadastradas no sistema.
A Figura 9 apresenta a poro principal desta pgina, localizada na regio above
the fold (no Apndice B, Figura 23, pode-se ver a pgina completa). Para proceder com
uma busca, o usurio deve fornecer palavras-chave do que est procurando e informar em
que localizao o produto ou servio deve ser entregue.
A informao da localizao pode ser dada indicando-se o CEP ou digitando-se
um endereo parcial. Em ambos os casos, o sistema abre sugestes de endereos similares
entrada dada pelo usurio. A localizao necessria pois levada em considerao
para seleo e ordenamento dos resultados, j que o local de entrega precisa estar na rea
de atendimento das empresas.
Figura 9 Pgina inicial do fazDelivery.
O sistema informado para realizar a consulta quando o usurio pressiona o boto
Buscar delivery, ou quando d enter pelo teclado. Ento, exibida para ele a listagem
de resultados, apresentada na seo a seguir.
4.2.2 Pgina de resultados do fazDelivery
No fazDelivery, os documentos a serem recuperados so os produtos ou servios.
Cada produto possui quatro sees textuais (sees que contm texto): nome, categoria,
descrio e tags. Quando um produto cadastrado no fazDelivery, o usurio que cadastra
o produto pode inserir palavras em todas essas sees (alm destes campos, um produto
possui um preo e pode ou ter uma imagem e estar associado a uma subcategoria).
Uma busca bem sucedida no fazDelivery retorna uma listagem com produtos ou
servios relevantes para os termos da consulta. Estes so buscados no ttulo, descrio e
tags associados a cada produto, ou, ainda, na seo em que este se encontra; assim, um
produto cadastrado como na Tabela 1 seria listado para uma busca pela palavra-chave
pizza, por exemplo, mesmo que no contenha a palavra pizza em nenhum campo
explcito (visualmente, para um usurio, o produto faz parte da categoria Pizza).
Tabela 1 Campos textuais que caracterizam um produto cadastrado no fazDelivery.
Campo Valor
Nome (ttulo) Portuguesa
Categoria Pizza
Descrio
Tags
Nome do fornecedor Man Pizzas e Sobremesas
A busca trabalha com 4 dimenses:
preo do produto ou servio;
distncia espacial entre a empresa que o oferece e a localizao informada;
tempo estimado de entrega (informado pelo estabelecimento);
relevncia textual (consulta x produto).
A Figura 10 mostra a verso atual da SERP do fazDelivery.
Pode-se identicar, nesta pgina de resultados, indicados pelos heptgonos (as
chaves presentes so para ns de identicao dos itens, no fazendo parte da interface):
1. campo para realizar uma nova consulta;
2. o endereo que o sistema est utilizando para basear as buscas;
3. menu com as categorias gerais existentes na plataforma;
4. um ttulo para a seo de busca, que indica a que consulta a listagem se refere;
5. trs ltros estilo slider para reordenar os resultados obtidos (busca avanada)
6. a listagem de resultados, que contm os substitutos de documentos;
Figura 10 Recorte da pgina de resultados do fazDelivery, para uma busca com a palavra
chave salada.
7. substitutos de documentos, com algumas informaes acerca do produto, como t-
tulo, descrio (se houver) e da empresa que o fornece (e.g. nome, telefone, distncia
at o endereo fornecido). Caso tenha interesse, o usurio pode clicar na marca da
empresa para visitar seu portflio.
possvel esconder os ltros da busca avanada, mas esta opo no est clara
na interface (para uma viso da listagem de resultados sem os ltros visveis, conferir a
Figura 22, no Apndice B).
A seguir, os elementos que proveem as informaes utilizadas por estas interfaces
so descritos. Esta caracterizao importante pois delimita o tipo de melhoria que poder
ser feita na usabilidade do fazDelivery, partindo-se do pressuposto que no se alterar as
regras de negcio ou modelagem de dados do sistema.
4.3 Caractersticas do Sistema
A arquitetura do fazDelivery segue o modelo Model-View-Controller (MVC)
1
, ou
seja, encapsula e separa as responsabilidades de lgica de negcio e dados (Model) da
exibio e visualizao destes dados usurio (View), atravs de uma camada que media a
comunicao entre ambas (Controller), funcionando como uma espcie de interface entre
as duas (Controller).
1
Em portugus, Modelo-Viso-Controlador.
A aplicao desenvolvida em PHP, construda com o framework CakePHP
2
,
exceo da busca, feita em Java. A Figura 11 representa a arquitetura do fazDelivery, com
enfoque na tecnologia de busca, parte central do sistema.
Figura 11 Arquitetura do fazDelivery, com enfoque nos mdulos que compem o sistema
de busca. Fonte: Rocha-Junior (2013).
A Figura 12 mostra as classes mais representativas do fazDelivery, para o escopo
deste trabalho: como trabalhar-se- com as interfaces, dada a diviso de responsabilidades
do modelo MVC, as classes da camada Control ler so ao mesmo tempo a interface de
comunicao e o manual do que possvel oferecer de usabilidade, dada a implementao
atual do software. O mesmo diagrama, com viso dos mtodos pblicos, mostrado na
Figura 25, no Apndice B.
O fazDelivery tem um motor de busca prprio, modelado por um especialista em
bancos de dados e recuperao da informao. Em sua verso completa, oferece inclusive
busca semntica, para permitir consultas em linguagem mais natural. Em outras palavras,
foi construda uma soluo computacional robusta para amparar suas consultas.
Sua interface, por outro lado, no seguiu o ciclo de desenvolvimento indicado para
interfaces, com design centrado no usurio e testes de usabilidade ao longo de seu projeto.
Deste modo, no h em suas interfaces o objetivo claro de prover uma experincia mais
satisfatria ou eciente para seus usurios.
2
O CakePHP, voltado para criao de aplicaes web em PHP, mantido pela Cake Software Foun-
dation. <http://cakephp.org/> (acesso em dezembro de 2013).
Figura 12 As classes mais importantes da camada de Controle do fazDelivery.
Esta caracterstica permite supor que uma melhora na usabilidade da busca pode
levar um nmero maior de usurios a alcanarem seus objetivos quando visitam o fazDe-
livery e, assim, pode-se contribuir para a relevncia da ferramenta enquanto soluo para
o mercado de buscadores de delivery.
Dando incio parte prtica deste projeto, os captulos seguintes cobrem o processo
de avaliao da usabilidade do fazDelivery e comparao com a usabilidade de concorren-
tes; melhorias em sua interface; e uma nova rodada de avaliao, para entender o efeitos
das alteraes na experincia dos usurios.
44
5 Metodologia para Avaliao e Evoluo das
Interfaces
Para avaliar e melhorar a usabilidade da interface do fazDelivery, foi inicialmente
planejado o uso de uma metodologia hbrida, conforme proposta de Nielsen (1995b): pri-
meiro realizam-se avaliaes heursticas, que possibilitam diagnosticar erros mais severos,
que podem ento ser corrigidos antes de se apresentar a interface para os testes com
usurios.
Essa abordagem interessante para melhorar a efetividade do processo dos testes
de usabilidade, j que os erros atrapalham o uxo de uso da ferramenta e podem, as-
sim, tirar o foco dos usurios. A Figura 13 ilustra esta primeira metodologia proposta,
detalhada a seguir:
1. denio das interfaces a serem inspecionadas;
2. levantamento de heursticas de usabilidade, gerais e especcas, que sero utilizadas
na avaliao das interfaces;
3. os itens 1 e 2 so utilizados como entradas para as sesses de avaliao heurstica.
Esta etapa gera como resultado a primeira listagem de problemas de usabilidade da
ferramenta;
4. a partir da listagem de problemas, os mais severos (conforme classicao de severi-
dade de erros proposta por Nielsen (1995d)) so corrigidos, dando origem primeira
verso de interface melhorada;
5. esta interface, j limpa de alguns erros, que submetida primeira rodada de testes
com usurios, que resulta em uma segunda listagem de problemas de usabilidade da
ferramenta;
6. essa listagem serve de insumo para o desenvolvimento de uma nova interface para a
ferramenta, levando em conta, desta vez, os problemas de usabilidade enfrentados
pelos usurios;
7. esta nova interface submetida a uma segunda rodada de testes de usabilidade,
para a qual sero convidados, alm de usurios que tenham participado da etapa de
testes anterior, alguns que desconheam a interface;
8. as trs listagens resultantes das inspees so por m utilizadas para fazer um
comparativo das verses da ferramenta, visando a uma melhor compreenso de
Captulo 5. Metodologia para Avaliao e Evoluo das Interfaces 45
como as alteraes inuenciaram em sua usabilidade, e amparando uma posterior
escolha de qual interface utilizar.
As sesses de Avaliaes Heursticas, entretanto, podem levantar um grande n-
mero de problemas nas interfaces. Caso isso ocorra, a etapa posterior das avaliaes pode
ser comprometida, por ser pouco prtico ou muito difcil que cada avaliador classique a
severidade de cada uma das violaes encontradas por todos os avaliadores, para que ento
se possa calcular a severidade mdia de cada problema e, assim, priorizar sua correo.
Para lidar com grandes listas de violaes de heursticas, proposta a abordagem
de selecionar uma amostra das violaes heursticas, para classicao de severidade.
A heurstica escolhida pode variar de acordo com os aspectos mais importantes para a
ferramenta. No caso do fazDelivery, como a ferramenta havia sido pouco testada antes de
ser lanada, foram escolhidas as violaes diretamente relacionados a erros ou que tinham
grande potencial de induzir usurios a erros, no uxo de uso da ferramenta.
Para evitar que os usurios sejam expostos a problemas j conhecidos da ferra-
menta, caso os testes com usurios no possam ser feitos aps as correes sugeridas pelas
Avaliaes Heursticas, a proposta reduzir o escopo de avaliao para os testes. O ponto
focar nas interfaces que concentram as interaes mais relevantes para um uxo de su-
cesso com o sistema - isto tambm til para evitar que as sesses com usurios quem
demasiado longas, ou gerem um volume muito grande de resultados, que pode ser difcil
de mapear, arquivar e interpretar, posteriormente.
muito importante que se conhea aplicaes correlatas, tanto para propor solu-
es quanto para manter padres e coerncia com os modelos mentais j conhecidos pelos
usurios. Este o papel do estudo comparativo de concorrentes. Caso este estudo no
possa ser realizado, pode ser substitudo por uma etapa de estudo de aplicaes correla-
tas. Esta traz insumos para a posterior etapa de prototipao e construo da interface
sendo trabalhada, e pode ser direcionada para observar, por exemplo, como ferramentas
selecionadas solucionam os problemas listados para correo, na ferramenta a ser melho-
rada.
Aps essas mudanas, ao invs de trs interfaces para comparar, h duas: a verso
inicial da ferramenta, que passa pelas etapas de Avaliao Heurstica e Testes de Usurio,
e a verso ps correes e melhorias, que passa por nova rodada de Testes de Usurio.
Estas duas verses so comparadas para gerar as concluses nais deste projeto. Nos
prximos captulos, a execuo da metodologia apresentada, bem como seus resultados.
Abaixo ilustrado, na Figura 14, est o processo metodolgico resultante das alteraes
descritas.
Figura 13 A primeira metodologia de avaliao das interfaces deste projeto, que busca
se aproveitar dos benefcios da avaliao heurstica e dos testes com usurios
combinados
1
.
1
Legenda de cores: em laranja claro, etapas ou produtos que sero utilizados como insumo no processo;
em laranja escuro, etapas ou produtos que so considerados apenas sada (no escopo deste projeto).
Figura 14 A metodologia de avaliao das interfaces deste projeto, que adapta a primeira
metodologia proposta.
48
6 Avaliao de Usabilidade do fazDelivery
Para saber o que corrigir ou melhorar primeiro, em relao usabilidade de uma
ferramenta, preciso primeiro identicar quais problemas ela apresenta. H uma srie de
tcnicas possveis para fazer isto, algumas apresentadas no Captulo 2. Para identicar os
aspectos do fazDelivery que precisavam ser revistos, foram utilizadas sesses de Avaliao
Heurstica e Testes com Usurios. O processo percorrido com ambas abordagens descrito
nas sees que seguem.
6.1 Avaliao Heurstica do fazDelivery
Foram realizadas 8 sesses de Avaliao Heurstica com o fazDelivery, com ava-
liadores das reas de Computao ou Design. Um roteiro com orientaes foi enviado a
todos os avaliadores (disponvel no Apndice C). Cinco sesses foram feitas remotamente
e em quatro delas houve acompanhamento em tempo real, por teleconferncia, para sanar
eventuais dvidas. Uma das sesses no contou com tal acompanhamento, por opo do
avaliador. Duas sesses foram presenciais e uma foi a realizada pela autora do projeto.
Cada sesso durou em mdia 45 minutos (20 a mais rpida e 61 a mais longa),
contando tempos para esclarecimento de dvidas antes e aps a inspeo em si. No total
foram levantadas 255 violaes de heursticas, com uma mdia de aproximadamente 28
problemas por cada uma das 9 telas e dilogos do sistema - o ideal aqui observar a
distribuio de erros por tela, detalhada na Tabela 2, pois os mesmos se concentram
muito mais nas principais interfaces do sistema. Cada avaliador encontrou, em mdia, 32
problemas. Apesar de mudanas no portflio no entrarem no escopo deste projeto, ao
longo das sesses deixou-se os avaliadores seguirem o uxo das telas sem interromp-los.
As violaes encontradas no portflio so ento aqui listadas a ttulo de informao e
como indicativo de que esta interface, em outro projeto, poderia ser endereada.
Aps as sesses de avaliao, todos as violaes de heursticas devem ser compila-
das, para que cada avaliador classique o grau de severidade de cada problema, seguindo
a seguinte escala (traduzida de Nielsen (1995d)):
0. = No concordo que isso seja um problema de usabilidade.
1. = Problema cosmtico, apenas: no precisa ser corrigido, a menos que haja tempo
livre disponvel no projeto.
2. = Pequeno problema de usabilidade: baixa prioridade para resoluo.
3. = Grande problema de usabilidade: importante resolv-lo, alta prioridade.
Captulo 6. Avaliao de Usabilidade do fazDelivery 49
Tabela 2 Nmero de Violaes de Usabilidade por Tela do fazDelivery
Tela do Sistema Pgina
Inicial
SERP Lista por
Categorias
Portflio Demais
dilogos
Avaliador(a)
N de Problemas 5 26 0 21 9 A1
3 17 0 5 1 A2
7 17 1 8 2 A3
4 6 1 5 0 A4
4 6 1 4 2 A5
3 10 3 4 1 A6
3 12 0 17 1 A7
10 17 2 10 7 A8
Total 39 111 8 74 23 255
Valor relativo (%) 15.29 43.53 3.14 29.02 9.02 100
4. = Problema de usabilidade catastrco: o produto no deveria ser lanado sem
resolver este problema (ou trata-se de uma correo urgente).
O grande volume de problemas identicados, como previamente dito no Captulo 5,
entretanto, levou a uma necessidade de reduo da listagem de classicao, para torn-
la vivel no contexto deste projeto. Assim, foi escolhida uma amostra de problemas,
observando-se, das listagens de cada sesso, aqueles relacionados com as heursticas de
preveno a erros, considerando-se que estes teriam um potencial maior de interferir no
uxo de uso da ferramenta pelos usurios. Essa lista se resumiu em 39 problemas, divididos
como mostrado na Tabela 3.
Tabela 3 Problemas Listados por Parte do Sistema (para Classicao de Severidade)
Parte do Sistema Problemas
Listados
Pgina Inicial 10
Pgina de Resultados (SERP) 14
Sistema de Busca (aspectos relacionados ao funcionamento da
busca, no necessariamente aos resultados exibidos)
3
Portflio 7
Plataforma como um todo 5
Para coleta das classicaes foi utilizado um questionrio online criado com o
Google Forms, funcionalidade do Google Docs
1
. Uma verso do mesmo pode ser vista na
ntegra no Apndice D. Este formato foi interessante pois facilitou a distribuio, j que
1
Google Forms: formulrios online criados no Google Docs <http://www.google.com/google-d-
s/createforms.html> (acesso em maio de 2014).
nem todos os avaliadores esto no mesmo local geogrco, alm de facilitar a compilao
das respostas para clculo da mdia da severidade de cada problema, posteriormente.
Sete avaliadores classicaram os problemas listados. A partir desta classicao
individual, obteve-se a mdia de severidade de cada problema. Nos casos em que a mdia
resultante foi um valor no exato, o mesmo foi aproximado. A Tabela 4 d uma viso ge-
ral desta classicao, com a mdia de severidade de cada um. No houve elementos no
considerados como problemas (grau de severidade 0), nem como problemas catastrcos
(grau 4). Baseando-se nos signicados dos graus de severidades, h 38 problemas a con-
siderar, para correo, tendo 10 destes alta prioridade (os mesmos so listados na Tabela
5 - a severidade mdia antes do arredondamento tambm foi includa, para exemplicar
como se deu este processo). O prximo passo para melhoria da usabilidade da ferramenta
denir quais problemas sero corrigidos, levando tambm em conta os resultados da
rodada de testes com usurios (descrita na seo seguinte).
Tabela 4 Quantidade de Problemas, por Severidade Classicada
Severidade Problemas Assim Classicados
0 0
1 1
2 28
3 10
4 0
Total 39
6.2 Sesses de Testes com Usurios
Alm da inspeo formal em busca de violaes de heursticas de usabilidade,
foram observados usurios em cenrios aproximados de um uso real da ferramenta, para
ter insights de como ocorrem interaes reais com o sistema, dados os problemas que
ele tem. Isto oferece um outro ponto de vista dos aspectos mais relevantes a resolver ou
permite ver solues simples que os prprios usurios do para lidar com as diculdades
encontradas.
Foram previstos, dois momentos de observao de usurios utilizando o fazDelivery:
o primeiro para identicar os aspectos que geravam mais entraves para os usurios, e um
segundo para ter um elemento de comparao se as interfaces e correes propostas de fato
reduziriam tais diculdades. Esta seo descreve o primeiro destes momentos, realizado
antes de serem feitas alteraes nas interfaces da plataforma (conforme explicado no
Captulo 5). A abordagem utilizada para os aspectos das etapas citadas no Captulo 2,
Seo 2.3, descrita nas prximas subsees.
Tabela 5 Dez Problemas com Mais Alta Prioridade para Resoluo
Id Problema Severidade
mdia /
aproximada
av-01 s vezes, sistema no consegue localizar endereo atravs do CEP 3,14 / 3
av-02 Sistema no orienta qual o formato de endereo aceito, mesmo no
aceitando qualquer formato e.g. CEP no pode conter trao
3,29 / 3
av-03 Sistema oferece a opo de pegar endereo do usurio atravs do pino
localizado no mapa, mas no consegue de fato faz-lo
3,00 / 3
av-04 Sistema exibiu mensagem de erro no tratada, quando usurio tentou
utilizar a funcionalidade de captura automtica de endereo muitas
vezes seguidas
2,71 / 3
av-05 A depender da resoluo de tela / navegador do usurio, o pino para
capturar localizao do usurio pelo mapa aparece completamente fora
de lugar (sequer visvel na tela)
2,57 / 3
av-06 Busca avanada s vezes exibida em contextos em que no funciona 2,57 / 3
av-07 Para avaliar um produto, sistema pede para fazer login mesmo se o
usurio j estiver logado
2,71 / 3
av-08 Ao selecionar uma categoria e fazer uma nova busca, ao invs de a
busca ser interna ao escopo de categoria, volta para o escopo global
2,71 / 3
av-09 Sistema no deixa claro que no consegue realizar uma busca se no
for informado endereo
2,86 / 3
av-10 Layout quebra em vrias resolues (ou navegadores), por exemplo,
para telas maiores, ou no Mac
2,86 / 3
6.2.1 Metas
Por ser uma ferramenta com um propsito muito especco e buscando pensar em
cenrios reais de uso do fazDelivery, a principal meta denida foi que os usurios no
deveriam gastar mais do que 3 minutos, para encontrar um produto ou servio, uma vez
que soubessem o que queriam - mais do que isso, atualmente, poderia levar a frustrao
e abandono da ferramenta.
Para 80% das consultas, a concluso da tarefa deveria ser com sucesso - novamente
aqui o racional que uma ferramenta de busca que no oferea resultados teis ser
abandonada.
6.2.2 Questes a Serem Respondidas
Foram denidas tarefas de consulta que representam possveis casos de uso do
fazDelivery, tendo como principal objetivo observar se, tendo pouco ou nenhum contato
anterior com a ferramenta e uma tarefa de consulta em vista, um usurio consegue chegar
a um telefone de estabelecimento (ou seja, consegue ter um uxo de uso de sucesso).
Outras questes observadas: fcil trocar de endereo? O sistema exvel para atender
diferentes tipos de consultas? O tempo gasto no fazDelivery similar ou satisfatrio ao
gasto em solues alternativas de buscas de servios de delivery?
As tarefas de consulta criadas para apoiar o roteiro dos testes so listadas no
Apndice E, Tabela 12.
6.2.3 Paradigma de Avaliao e Tcnica de Respostas
Neste projeto, as tcnicas empricas de observao e pensar alto (Think Aloud)
foram utilizadas durante as sees com usurios. Para o questionrio de sada, a ser
respondido aps cada sesso, foram utilizadas principalmente questes com Escala Likert
2
,
til e comum para mensurar preferncias, atitudes e reaes subjetivas (veja o questionrio
completo no seo E.2).
6.2.4 Questes Prticas
O perl de usurios pensado para os testes buscou abranger possveis usurios nais
do fazDelivery. O principal aspecto considerado foi serem pessoas que tm familiaridade
com a internet (de outro modo, provavelmente escolheriam outra soluo para buscar
servios de delivery). Familiaridade com servios de delivery poderia ser interessante, mas
no foi um foco principal.
No foi utilizado laboratrio para realizao dos testes. Em vez disso, ambientes
mais prximos de um cenrio normal de uso do fazDelivery foram escolhidos: em casa, e
no trabalho (locais comuns de se pedir servios de entrega, principalmente comida). Em
relao aos recursos de software e hardware, os testes foram realizados em laptops (com e
sem mouse) ou desktops, no Windows e no Ubuntu, nos navegadores Chrome ou Firefox.
Esta rodada de testes no foi gravada (tela, udio ou vdeo).
6.2.5 Questes ticas
Todos os participantes leram e concordaram com um Termo de Consentimento e
Participao. Alm disso, tambm forneceram alguns dados de cunho demogrco, utiliza-
dos neste projeto para ajudar a traar seu perl. O Apndice E.1 apresenta o documento
utilizado para coletar tais informaes.
6.2.6 Avaliar, Interpretar e Apresentar Dados
O roteiro seguido nas sesses de teste com usurios foi o seguinte:
2
Likert Scale <http://www.usabilityrst.com/glossary/likert-scale/> (acesso em maio de 2014).
1. Pequena introduo, explicando que o sistema estava sendo avaliado, no a pessoa,
e que qualquer erro ou problema era culpa do site, ou m conduo do observador,
no do usurio;
2. Explicao da tcnica pensar alto (think aloud) e dos critrios de encerramento de
uma tarefa (quais sejam, quando a pessoa tivesse encontrado um resultado satisfa-
trio, ou quando seu limiar de frustrao, no caso de no estar encontrando, fosse
alcanado);
3. Leitura e aceitao do Termo de Consentimento;
4. Preenchimento do Questionrio de Entrada (dados demogrcos, basicamente);
5. Sortear ordem da tarefa aberta (esta podia ser a 1, 2 ou 3 a ser realizada);
6. Pegar 2 tarefas do tipo encontrar produto;
7. Pegar 2 tarefas do tipo encontrar estabelecimento;
8. Pegar 1 endereo (endereos predenidos foram providos para aumentar as chances
de pelo menos algumas consultas terem sucesso, j que o fazDelivery apresenta seus
resultados a partir da cobertura de entrega dos estabelecimentos, e era importante
ter alguns casos de sucesso para que as pessoas interagissem com a listagem de
resultados etc.);
9. Teste:
a) Entrar no fazDelivery e realizar 3 tarefas, utilizando o endereo sorteado (a
tarefa aberta sempre era realizada nesta primeira parte);
b) Mudar o endereo para algum escolhido pelo usurio, na hora;
c) Realizar as duas tarefas restantes.
10. Responder ao questionrio de sada.
Durante os testes, os usurios realizaram as tarefas sem interferncias, exceto
quando cavam muito calados ou perguntavam algo (nestes casos, eram incitados a voltar
a pensar alto, atravs de perguntas acerca do que estavam fazendo; em relao s dvi-
das, na medida em que no atrapalhassem o processo de descoberta do usurio, foram
respondidas). O tempo total de cada sesso foi medido (desde o passo 1 ao 10), e o tempo
para realizao de cada tarefa, cronometrado.
A tarefa aberta citada no roteiro foi pensada para inserir algum elemento de va-
riedade/ escolha e deixar um pouco mais ldico o processo das tarefas de consulta; sua
insero foi inspirada no que Wilson (2013) traz sobre como a natureza da tarefa de busca
pode mudar o comportamento da busca em si. Assim, das 5 tarefas de busca solicitadas,
uma delas era sempre uma consulta livre isso poderia estimul-las a testar diferentes
buscas, por exemplo, por estarem mais motivadas, j que a consulta partira de uma esco-
lha delas, e acrescentaria o elemento de buscas estranhas que no foram previstas pelas
tarefas predenidas.
Os quatro tipos de tarefas realizadas foram pensados para cobrir as seguintes
situaes, entendidas como comuns para o cenrio de delivery:
A pessoa sabe onde quer pedir (busca por estabelecimento especco ou genrico);
A pessoa sabe o qu quer pedir (busca por produto);
A pessoa encontrou o sistema e est explorando (tarefa aberta);
A pessoa est em um local (i.e., j forneceu um endereo principal) e quer testar o
que encontra para um outro endereo de seu interesse.
As tarefas intencionalmente no induziram os usurios a interagir com a busca
avanada ou o portflio. Esta deciso foi tomada: i) porque o foco do projeto a pgina
de listagem de resultados, de onde j possvel realizar as principais interaes com a
ferramenta (as demais telas, tambm so importantes, mas como complemento); ii) sem a
induo, seria mais fcil observar o quanto os elementos existentes ressaam naturalmente,
ao longo do processo, j que durante um caso de uso real isso o mais provvel de
acontecer. Pde-se notar, por exemplo, que poucos usurios interagiram com as estrelas
para avaliao de produtos e poucas pessoas navegaram espontaneamente pelas categorias,
ainda que uma das tarefas tivesse um vis para este tipo de busca.
6.2.7 Durao das Sesses
Em mdia, cada sesso durou 19 minutos, contando tempos de aceitar o Termo de
Consentimento, preencher o Questionrio de Entrada, receber instrues, realizar teste e
responder ao Questionrio de Sada (ou Encerramento).
Entre todas as sesses, foram realizadas 50 tarefas de consulta, sendo 10 destas
abertas. O tempo mdio de durao de uma tarefa de consulta foi de um minuto e vinte
e nove segundos
3
. A durao mdia subiu para um minuto e trinta e um segundos, nos
casos de consultas concludas sem sucesso. A maioria das tarefas foi realizada com tempo
inferior meta de 3 minutos (88%), independente de ter sido concluda com sucesso ou
no. Destas, 60% tiveram durao abaixo da mdia. Estes nmeros sugerem que a meta de
3 minutos pode ser alterada para uma durao menor, para esse tipo de tarefa/ferramenta.
3
Como algumas tarefas foram concludas em menos de 10 segundos, considerou-se interessante no
arredondar 29 segundos para 30, aqui.
6.2.8 Principais Observaes Durante a Execuo dos Testes
Esta seo apresenta as diculdades e problemas de interao mais frequentes
durante os testes com usurios, ou que, mesmo no tendo sido frequentes, qualitativamente
so considerados graves, merecendo tambm ateno.
tu-01 Um dos problemas observados a partir dos testes foi que algumas tarefas foram
consideradas concludas, mesmo quando o estabelecimento encontrado era diferente
do solicitado (10% das tarefas realizadas). Isto leva concluso de que a listagem
de resultados no muito eciente para apresentar os estabelecimentos
4
, e aponta
para um aspecto importante a ser corrigido, pois est confundindo os usurios;
tu-02 A parte do sistema relacionada a busca e sugesto de endereos, por questes como
trazer resultados de outros estados e no facilitar a leitura de cada endereo suge-
rido, gerou vrios contratempos, como: endereos selecionados erroneamente; quebra
do sistema; e necessidade de tentar algumas vezes para encontrar o endereo dese-
jado. Outro aspecto importante que no h muito destaque em relao ao endereo
escolhido. Isso levou pelo menos uma pessoa, mais de uma vez, a selecionar o ende-
reo errado sem notar. Tais diculdades, associadas ao fato de que o fazDelivery
uma ferramenta georreferenciada, apontam para uma alta prioridade de melhorar a
forma como o usurio insere e/ou seleciona um endereo;
tu-03 Um aspecto que gerou estupefao, confuses e frustraes foi a falta de estabele-
cimentos para endereos fora da regio Pituba-Itaigara. Apesar de o problema da
base reduzida de empresas no entrar no escopo do projeto, alguma indicao de por
que no so encontrados produtos deveria existir. No modelo de mundo das pessoas,
os estabelecimentos existem e portanto deveriam constar nos resultados ( transpa-
rente para muitas delas que as empresas precisam se cadastrar na ferramenta, ento
h uma discrepncia entre a realidade e o sistema que precisa de algum modo ser
explicada);
tu-04 A combinao de: ausncia de boto de voltar; perda dos dados informados pelos
usurios ao se clicar para ir para a pgina inicial; e problemas associados ao meca-
nismo de informar e sugerir endereo levou a muitas demoras, alguma frustrao e
mesmo a uxos errneos, quando o usurio acabava por selecionar o endereo er-
rado. A concluso que a plataforma oferece pouco suporte a controle e navegao,
para os usurios;
tu-05 O modo de funcionamento da Busca Avanada no cou claro para nenhum dos
usurios que interagiu com o mesmo, sempre levando a pensarem que a mesma no
4
fazendo uma ponte com as Avaliaes Heursticas, pode-se associar isto ao fato de que o nome dos
estabelecimentos foi considerado mal posicionado
estava funcionando. Alm disso, muitos clicaram nas palavras Busca avanada,
que aparecem ao lado do texto que apresenta os resultados, em uma atitude que
demonstrou que eles esperavam que aparecesse alguma opo, no que os sliders
fossem a Busca Avanada em si, e/ou que fossem sumir
5
. Estas observaes sugerem
que: falta feedback ou ajuda de como a Busca Avanada opera; e que sua apresentao
no corresponde ao que os usurios esto acostumados, para tal funcionalidade;
tu-06 Em alguns casos a falta de destaque de informaes dos produtos levou os usurios
a no entender o produto que estavam vendo (e.g., ao buscar por pizza de atum
e verem um resultado de borda de atum, muito mais barato do que uma pizza
costuma ser, pelo menos duas pessoas foram imediatamente para o portflio da
empresa, interessadas porque a pizza de atum estava muito em conta. Disso percebe-
se uma necessidade de reorganizar os dados dos produtos, nos resultados, visando
melhorar a apresentao do que relevante nessa etapa das buscas;
tu-07 Algumas pessoas no souberam, a princpio, como chegar a mais informaes do
estabelecimento (o portflio). Houve mais de um caso em que se tentou clicar no
ttulo do produto (que comumente leva a uma outra pgina, em listagens de resul-
tados de buscadores, mas que no fazDelivery no). Aqui o que se observou que
o sistema no segue alguns padres difundidos entre buscadores, trazendo ento
prejuzos para o entendimento de seu funcionamento e interao com o mesmo;
tu-08 Alguns usurios tiveram diculdades com o boto de ver telefone, primeiro porque
a informao no era exibida diretamente e, depois de clicar no mesmo, porque no
sabiam exatamente o que levava o nmero a aparecer e sumir;
tu-09 A barra de busca que aparece na pgina de resultados, no portflio e na listagem de
produtos por categorias tem pouco destaque, o que levou, muitas vezes, as pessoas
a voltarem pgina inicial para realizar suas buscas.
Apesar de tais problemas, e de em alguns quesitos no seguir padres comuns entre
buscadores, a percepo dos usurios sobre a experincia de uso do fazDelivery, levantada
logo aps cada sesso de testes atravs do Questionrio de Sada, teve mdia de 4,2, de
5
6
, ou seja, foi alta. Tal avaliao positiva pode, em parte, ter relao com uma predispo-
sio amigvel no uso, visto que todos os usurios eram conhecidos da observadora, mas
tambm indicam que a ferramenta no frustrou completamente suas expectativas de uso.
A Tabela 6 lista as mdias para cada pergunta feita. A escala para avaliao variou de 1
(opinio mais negativa possvel) a 5 (opinio mais positiva possvel)
7
.
5
A Busca Avanada do fazDelivery pode ser vista na Figura 10.
6
a nota 5, aqui, representava Gostei muito de utilizar a ferramenta
7
No Apndice E, Seo E.2, encontra-se o questionrio com as perguntas completas
Tabela 6 Mdias da avaliao da experincia de uso do fazDelivery
Experincia de Uso do fazDelivery
Pergunta Opinio
Mdia
Foi fcil usar o fazDelivery para fazer as tarefas predenidas? 4,2
Foi fcil usar o fazDelivery para fazer a tarefa aberta? 4,1
Foi fcil realizar a mudana de endereo? O fazDelivery mostra claramente
onde fazer essa mudana, e como deve ser feita?
3,8
No conjunto, como voc classica a experincia de uso do fazDelivery? 4,2
Considere outras ocasies em que pediu coisas por delivery, levando em conta
tempo para encontrar contato e escolher o que pedir. Na sua opinio, o tempo
gasto no fazDelivery para fazer a mesma coisa compatvel, aceitvel?
4,5
Estas foram as observaes mais recorrentes ou problemticas, surgidas da rodada
de testes com usurios. O captulo seguinte apresenta os erros e problemas considerados
prioritrios para correo, levando-se em conta as violaes heursticas e os testes com
usurios; e descreve as solues propostas para os mesmos, na interface do fazDelivery.
58
7 Projeto da Nova Interface
Este captulo descreve o processo adotado para propor melhorias na interface do
fazDelivery, desde a justicativa da seleo dos problemas e violaes heursticas a ende-
rear (prxima seo); passando pelo levantamento de como ferramentas correlatas lidam
com os mesmos aspectos (Seo 7.2), at a denio e prototipao das solues (Sees
7.3 e 7.4). Para evitar que problemas relacionados a diculdades de implementar as su-
gestes tomassem tempo que poderia ser aplicado para gerao das sugestes em si, neste
projeto, a etapa de implementao da nova interface foi excluda (e, por conseguinte,
tambm a rodada de testes de usurios com a nova interface).
7.1 Seleo dos Problemas a Enderear
Para esta etapa de prototipao, inicialmente, foram selecionadas as dez violaes
heursticas com prioridade mais alta, segundo os avaliadores, e os problemas identicados
nas sesses de testes com usurios (ambas listagens apresentadas no captulo anterior). O
recorte foi feito para tornar factvel, dentro do tempo disponvel para o projeto, percorrer
satisfatoriamente o processo de estudo de ferramentas correlatas e prototipao.
7.2 Anlise de Ferramentas Correlatas
As ferramentas escolhidas para anlise foram trs concorrentes do fazDelivery,
todos motores de busca tipo catlogo, com foco em ajudar pessoas a encontrar empresas.
Todos tm abrangncia nacional:
iFood: catlogo de restaurantes. Considerado correlato porque o principal servio
solicitado por delivery de entrega de comida e este o site com mais usurios no
Brasil nesta rea;
GuiaMais: catlogo de empresas de propsito geral;
TeleListas.net: outro catlogo de empresas, com formato que remete mais s an-
tigas pginas amarelas.
Foram observadas as abordagens dos trs buscadores, para cada problema a corri-
gir, para trazer insumos para as propostas de soluo. As Tabelas 8 e 9 correlacionam Id
do problema no fazDelivery s solues vistas nos concorrentes para a tarefa relacionada
ao problema. Os erros do sistema foram desconsiderados, nessa anlise.
Captulo 7. Projeto da Nova Interface 59
Alm do estudo direcionado com os buscadores citados, a interface do Google
serviu diretamente de insumo para observar aspectos como o posicionamento das opes
para renamento de busca , visto que alguns usurios, durante os testes, caram confusos
com a forma de apresentao dessa funcionalidade no fazDelivery
1
.
Citando como exemplo o caso do menu para renar uma busca, observou-se que
entre as ferramentas correlatas, TeleListas e iFood o posicionam na lateral esquerda da
pgina, ao lado da listagem de resultados. J GuiaMais e Google apresentam a funcionali-
dade localizada acima dos resultados. No GuiaMais, como no fazDelivery, o layout padro
j exibe os ltros. J o Google mostra apenas um boto que leva a submenus para reno
da busca - isso evita que tal funcionalidade ocupe muito espao da regio above the fold
da pgina, deixando mais rea livre para a funo principal da tela que listar resultados.
O estudo de ferramentas de busca feito para o Captulo 3 tambm contribuiu, ainda
que indiretamente, para esta etapa. A ttulo de referncia, a Tabela 7 lista os buscadores
citados neste trabalho.
Tabela 7 Ferramentas de busca citadas neste trabalho, por ordem alfabtica.
Ferramenta Endereo Propsito
Bing br.bing.com Geral
CiteSeerXbeta citeseerx.ist.psu.edu Cientco
fazDelivery www.fazdelivery.com.br Delivery (Salvador)
Google www.google.com.br Geral
GuiaMais http://www.guiamais.com.br/ Empresas e Servios
iFood http://www.ifood.com.br/delivery/ Restaurantes
JusBrasil www.jusbrasil.com.br Jurdico (Brasil)
MSN www.msn.com Geral (Bing)
Open Directory Project www.dmoz.org Geral
TeleListas.net http://www.telelistas.net/ Empresas e Servios
Yahoo! www.yahoo.com Geral
Yummly www.yummly.com Receitas
Tendo tal anlise como parmetro, e levando em considerao o escopo do projeto
e da ferramenta, foram denidas as solues para os problemas identicados na interface
do fazDelivery, descritas na seo seguinte.
7.3 Solues Propostas
Para orientar a construo dos prottipos de tela, foram pensadas primeiro solu-
es conceituais para os problemas a serem abordados. Essa abordagem ajuda a guiar a
etapa de prototipao, evitando que seja muito emprica ou que comecem a ser pensados
0
no fazDelivery identicadas como Busca Avanada
1
Conforme descrito no problema tu-05, na Seo 6.2.8.
Tabela 8 Levantamento de solues em trs ferramentas correlatas (tabela 1)
Solues de Ferramentas Correlatas parte 1
Id iFood Guia Mais TeleListas.net
av-02 S pede CEP, d exemplo
de formato, retira auto-
maticamente o trao, j
que no aceita
Aceita bairro, cidade, es-
tado. D exemplo com ci-
dade e estado
Menus dropdown para se-
lecionar Estado e Cidade
av-03 No oferece No oferece No oferece
av-07 S possvel avaliar aps
fazer pedido, no h
como avaliar na listagem
geral
Clicar para avaliar nos
resultados leva ao portf-
lio da empresa
No h como avaliar
na listagem geral, s os
usurios da app mobile
podem faz-lo
av-08 Oferece renamento por
ltros e busca interna
ltragem
Oferece renamento sim-
ples ou reordenao
Oferece renamento por
ltros e busca interna
ltragem
av-09 Pede primeiro o CEP,
sem campo para busca
O endereo de exemplo
funciona para escopo da
busca, se a pessoa no
informar outro. Se o en-
dereo informado no for
identicado, faz a busca
com escopo nacional
Deixa pr-selecionado
um escopo de busca, nos
menus, e o utiliza, se
o usurio no fornecer
endereo
tu-01 A listagem por estabelecimento (assim, as informaes do mesmo cam mais
esquerda, tendo naturalmente mais destaque (para usurios ocidentais, que
escrevem da esquerda pra direita))
tu-02 Abre uma janela de di-
logo para nalizar preen-
chimento do endereo e
conrmar dados
Abre um menu com su-
gestes que mudam na
medida em que o usu-
rio insere endereo. Se-
para sugestes por bairro
e cidade, para facilitar
leitura
Trabalha com menu
dropdown para estado,
cidade e bairro, carrega-
dos na medida em que
usurio seleciona escolhe
algum (i.e., carrega
cidades aps seleo de
estado)
Tabela 9 Levantamento de solues em trs ferramentas correlatas (tabela 2)
Solues de Ferramentas Correlatas parte 2
Id iFood Guia Mais TeleListas.net
tu-03 Quando no h nenhum
estabelecimento para a
regio indicada, informa
ao usurio que o endereo
no faz parte da rea de
cobertura e solicita um e-
mail, para que possa avi-
sar assim que a situao
mudar
Mostra estabelecimentos
prximos (e.g. para
uma busca por culin-
ria rabe no bairro de
Paripe, em Salvador,
retornou restaurantes na
Piedade e no Itaigara)
Quando no h resul-
tados para a regio ou
termo buscado, indica
algumas aes possveis,
como realizar outra
busca ou ler a ajuda
sobre como buscar
tu-04 Exibe breadcrumb pelo
qual possvel voltar
listagem de estabeleci-
mentos
No h boto de voltar Exibe breadcrumb pelo
qual possvel voltar
listagem de estabeleci-
mentos
tu-05 Utiliza palavras mais
claras para indicar o
efeito da busca (e.g.
Rene sua Busca,
Filtros). D feedback
visual quando vai recar-
regar resultados a partir
de algum renamento
Utiliza o termo Organi-
zar para indicar aes
que no geram ltragem
dos resultados
Ver apenas resultados
contendo explica que os
resultados sero ltra-
dos. Usurio explicita-
mente indica que quer l-
trar, clicando em boto
Renar
tu-06 A listagem por estabelecimento
tu-07 Ttulo do estabeleci-
mento, que o ttulo
do resultado, link -
esse um funcionamento
comum para buscadores.
Boto Pedir tambm
explicita caminho ao
portflio
Ttulo do estabeleci-
mento, que o ttulo
Link Saiba mais tam-
bm tambm explicita
caminho ao portflio
Ttulo do estabeleci-
mento, que o ttulo
Link +info tambm
explicita caminho ao
portflio
tu-08 No informa telefone (s
possvel pedir pelo site)
Uma vez que usurio
clica para ver o te-
lefone, no o esconde
mais. Exibe telefone dire-
tamente, no portflio
Exibe telefone direta-
mente
tu-09 A listagem de estabeleci-
mentos por regio, i.e.,
todos so mostrados e
possvel apenas ltrar e
renar a busca
Pgina de resultados
tem muita informao
e anncios, mas barra
de busca a mesma da
pgina inicial, na mesma
localizao, e com boto
chamativo, o que ajuda
usurio a se localizar
Barra de busca tem
mesmo estilo da pgina
inicial, com localizao
muito prxima, apenas
com um pouco menos de
destaque. Fcil de visu-
alizar. No exibe barra
de busca no portflio da
empresa
elementos fora do escopo da soluo, por um lado, e por outro permite pensar solues
sem levar tempo pensando em aspectos muito detalhistas que surgem quando se lida
diretamente com a interface (por exemplo, centralizao, tamanho de fonte etc.).
Nessa etapa, os problemas foram agrupados pelas telas em que aparecem, aps o
recorte por severidade e escopo do projeto: Pgina Inicial e Pgina de Resultados. Essa
diviso facilitou o momento posterior, de pensar as solues em termos de prottipo, j
que os elementos e solues muitas vezes dialogam com outros componentes da interface
em que se encontram, no podendo portanto serem pensados isoladamente. As tabelas 10
e 11 apresentam cada problema com comentrios e soluo indicada, a partir do escopo
do projeto, da ferramenta em questo e considerando as abordagens dos buscadores ana-
lisados. O processo para transpor tais sugestes para prottipos de tela apresentado na
prxima seo.
7.4 Prototipao
A prototipao das interfaces com as solues propostas foi feita seguindo a de-
ciso de no recriar as telas do zero, tentando reaproveitar ao mximo o que j estava
desenvolvido. Esta deciso consoante com a escolha de corrigir problemas, mais do que
de trazer um conceito novo para a plataforma, e pode ser uma abordagem interessante
para outras ferramentas em produo, ou para empresas com oramento reduzido para
melhorar suas interfaces - pois evita tempo de concepo, reaproveita trabalho j realizado
e no traz mudanas drsticas de identidade visual para os usurios.
Para a construo e edio das telas em si, as ferramentas utilizadas foram:
edies no HTML e CSS da pgina, atravs da opo ferramenta para desenvolvedor
do navegador;
retoques, ajustes e algumas construes utilizando o GIMP
2
;
para captura das telas foram utilizados dois programas para screenshots: Awesome
Screenshot
3
e o Shutter
4
, que permite registrar posio do cursor do mouse e, assim,
os resultados de interaes com a interface.
importante observar que esta abordagem, se no for orientada por objetivos
claros, pode levar a perda de tempo com manipulaes desnecessrias de elementos das
2
GNU Image Manipulation Program. Ferramenta para edio e manipulao de imagens, de cdigo
livre
3
Como plugin do Google Chrome, disponvel em <http://awesomescreenshot.com/> (acesso em junho
de 2014).
4
Programa de captura de tela para Ubuntu e Linux. Disponvel em <http://shutter-project.org/>
(acesso em junho de 2014).
Tabela 10 Solues sugeridas para os problemas encontrados na Pgina Inicial
Solues Sugeridas para os Problemas de Usabilidade da Pgina Inicial
Id Problema Comentrio / Soluo
ah-01 s vezes, sistema no consegue locali-
zar endereo atravs do CEP
Mensagem de feedback e orientao,
quando no conseguir
ah-02 Sistema no orienta qual o formato de
endereo aceito, mesmo no aceitando
qualquer formato e.g. CEP no pode
conter trao
Texto de ajuda retirado do placeholder e
colocado abaixo do formulrio, acrescen-
tado exemplo
ah-03 Sistema oferece a opo de identicar
endereo do usurio atravs do pino lo-
calizado no mapa, mas no consegue de
fato faz-lo
Opo no funciona, gera erros e foi pouco
percebida. Alm disso, com a falta de con-
troles para interao com o mapa, indicar
o endereo por ele no to prtico. Fun-
cionalidade retirada do prottipo
ah-04 Sistema exibiu mensagem de erro no
tratada, quando usurio tentou utilizar
a funcionalidade de captura automtica
de endereo muitas vezes seguidas
Funcionalidade retirada do prottipo
ah-05 A depender da resoluo de tela / nave-
gador do usurio, o pino para capturar
localizao do usurio pelo mapa apa-
rece completamente fora de lugar (se-
quer visvel na tela)
Funcionalidade retirada do prottipo
ah-09 Sistema no deixa claro que no conse-
gue realizar uma busca se no for infor-
mado endereo
Modicado o texto do campo para infor-
mar endereo, acrescentada mensagem de
feedback caso usurio tente buscar sem en-
dereo
ah-10 Layout quebra em vrias resolues (ou
navegadores), por exemplo, para telas
maiores, ou em MacBooks
Este problema precisa ser corrigido em
fase de implementao
tu-02 Forma como sistema apresenta endere-
os para sugesto
Como s funciona para salvador, ordenar
sugestes a partir disso. Exibir janela de
conrmao, como iFood
av-37 Forma de funcionamento da plataforma
no ca to clara, se no for previa-
mente explicado.
rea do mapa redimensionada, para que
instrues quem visveis above the fold
Tabela 11 Solues sugeridas para os problemas encontrados na Pgina de Resultados
(SERP)
Solues Sugeridas para os Problemas de Usabilidade da Pgina de Resultados
Id Problema Comentrio / Soluo
ah-06 Busca avanada s vezes exibida em
contextos em que no funciona
Retirar a busca avanada da listagem por
categorias
ah-07 Para avaliar um produto, sistema pede
para fazer login mesmo se o usurio j
estiver logado
No h como fazer em prototipao, mas:
permitir avaliar produtos e servios ape-
nas a partir do portflio da empresa
ah-08 Ao selecionar uma categoria e fazer
uma nova busca, ao invs de a busca
ser interna ao escopo de categoria, volta
para o escopo global
Indicar melhor que no possvel realizar
buscas nas categorias. Texto de ajuda in-
dicando aes de navegar por categorias
OU realizar buscas
tu-01 difcil identicar o estabelecimento
que oferece um produto
Mais destaque para o estabelecimento, no
item de resultado (document surrogate)
tu-03 Poucos produtos e estabelecimentos for
a do eixo Pituba-Itaigara
Como aumentar a oferta de estabeleci-
mentos no entra no escopo deste traba-
lho, buscou-se indicar que em outras re-
gies poderia haver mais resultados, nos
casos de conjunto de resultados vazio
tu-04 Ausncia de boto de voltar. Inseridos breadcrumbs para indicar onde
o usurio est em determinada sesso de
busca
tu-05 Modo de funcionamento da Busca
Avanada no claro, apresentao
gera confuses
Alterada localizao da busca avanada,
alterada para Reorganizar resultados,
acrescentar texto de ajuda
tu-06 Informaes dos produtos so apresen-
tadas de modo confuso na listagem de
resultados (nem sempre ca claro o que
so)
Repensar a apresentao das informaes
do produto, no item de resultado
tu-07 Caminho para acessar portflio no
to claro / intuitivo
Transformar ttulo de produto em link, no
item de resultado. Deixar item de resul-
tado mais intuitivo
tu-08 Funcionamento do boto ver telefone,
i.e. ser boto, mas ter comportamento
de roll over, gera diculdades para os
usurios
Deixar sempre visvel
tu-09 Barra de busca que aparece no topo das
pginas tem pouco destaque. Usurios
vrias vezes acabam voltando para p-
gina inicial
Dar mais destaque barra de busca
telas. Alm disso, como j dito, o fato de algumas solues serem componentes em mais de
uma tela, e o modo como os elementos interagem entre si em cada tela, tornam necessrio
que se dena de antemo o esquema geral e um plano de ao, para evitar retrabalho.
Percebendo-se essa questo, a prototipao no fazDelivery foi uma espcie de tra-
balho de composio em que se buscou seguir os seguintes passos:
pensar no conceito que se quer seguir - comeando com as solues conceituais;
ter uma viso do todo - o que preciso corrigir e onde, todas as correes para cada
tela;
observar elementos que se repetiro em diferentes telas ou em uma mesma tela;
utilizar uma ferramenta que permita reaproveitar e editar elementos facilmente
atravs de camadas e elementos agrupados, por exemplo;
corrigir e prototipar a partir das peas menores, componentes, que se repetem em
variados pontos do sistema;
executar a correo e/ou prototipao completa, por telas.
O resultado dessa etapa apresentado no captulo a seguir, que compara a interface
antiga do fazDelivery e os prottipos propostos, comentando as decises escolhidas.
66
8 Comparao das Verses do fazDelivery
Alm de aplicar as solues indicadas para os problemas selecionados para corre-
o, as alteraes propostas no fazDelivery buscam, de modo geral:
deixar textos de explicao mais visveis;
oferecer feedbacks mais claros. Em muitos casos no havia qualquer resposta do
sistema para situaes problemticas;
concentrar e organizar as informaes exibidas para os usurios;
aproveitar melhor a regio above the fold das pginas.
Para ilustrar isto, as prximas sees apresentam duas das principais pginas do
sistema, que foram as que mais tiveram problemas diagnosticados: a Pgina Inicial (Seo
8.1) e a Pgina de Resultados de Busca (Seo 8.2). Alm destas, so mostrados dilogos
criados para evitar os problemas surgidos com o endereo, observados tanto nas Avaliaes
Heursticas quanto nos Testes com Usurios.
8.1 Pgina Inicial
A Pgina Inicial do fazDelivery apresenta, principalmente, complicaes por conta
da parte do endereo: a explicao dos campos de busca est disponvel apenas como
placeholder, sumindo to logo o usurio digite qualquer coisa; observa-se tambm que no
h exemplos do formato de CEP aceito.
Alm disso, a verso original no d destaque aos passos criados para explicar o
funcionamento da plataforma: o mapa de estabelecimentos ocupa muito espao, escon-
dendo a explicao da regio de destaque antes da rolagem (vide Figura 15).
Como na classicao de severidade nenhum dos problemas abaixo da regio privi-
legiada tiveram grau de severidade 3 (recorte para as correes deste projeto), o restante
da pgina no foi alterado.
A Figura 16 apresenta a nova verso: exemplo para busca e formatos de endereo
mostrados abaixo dos campos, ou seja, sempre visveis. mais compacta: a rea do mapa
se reduz e os passos para uso da plataforma agora aparecem sem que o usurio precise rolar
a pgina. Ainda abordando as questes com o endereo, foram propostos trs dilogos,
visveis na Figura 17: dois com feedback em caso de erros e um para conrmao do
endereo.
Captulo 8. Comparao das Verses do fazDelivery 67
Figura 15 Pgina Inicial do fazDelivery (above the fold): modo de funcionamento da
plataforma cortado, textos de ajuda como placeholders.
Figura 16 Pgina Inicial do fazDelivery (above the fold). Mantidos conceitos, alterados
detalhes. rea do mapa reduzida para mostrar instrues do funcionamento
do sistema.
8.2 Pgina de Resultados de Busca
A Pgina de Resultados do fazDelivery (vide Figura 18) apresenta itens de resul-
tado muito espalhados na tela, com espaamentos que dicultam ter uma viso do todo ou
associar semanticamente informaes. Alm disso, elementos secundrios (como a indica-
o de qual a consulta realizada) ocupam muito espao, roubando a cena dos resultados,
Figura 17 Utilizados pelo sistema de busca do endereo, as mensagens evitam que o
usurio que preso por no saber qual o problema, ou que escolha para buscar
uma regio diferente da desejada.
que deveriam ser a principal informao apresentada: aparecem apenas dois resultados
antes de rolagem da pgina
1
. A caixa de resultados tem cores que contrastam pouco com
o fundo da pgina, o que tambm diculta identicar cada resultado.
A falta de contrastes tambm deixa informaes relevantes (como categoria de
produtos) muito apagadas e prejudica at mesmo a visualizao da barra para realizar
novas buscas (o que talvez explique porque tantos usurios voltaram Pgina Inicial para
realizar novas buscas, durante os testes com usurios, por exemplo).
Outra caracterstica marcante da pgina de resultados que ela no apresenta
qualquer mensagem de m da listagem dos resultados, nem tem algum rodap que indique
o m da pgina.
A Pgina de Resultados proposta (Figura 19) uma reformulao da original,
reaproveitando a identidade visual e a maior parte dos elementos. Para tentar reduzir as
aes de busca interna em categorias, j que o fazDelivery no oferece essa funcionalidade,
um texto explicativo entre o menu de categorias e a barra de buscas foi inserido. O campo
de busca tem cores mais fores, para que no passe desapercebido. Para melhorar o controle
e navegao, j que houve problemas pela falta de um boto de voltar, o conceito de
1
entre as ferramentas correlatas, apenas o GuiaMais tem uma pgina pior, nestes termos, exibindo
um nico resultado na regio above the fold
Figura 18 Pgina de Resultados original - a marcao em preto na horizontal indica
a regio above the fold: dois resultados visveis, Busca Avanada ocupando
regio de muito destaque. Ausncia de indicao clara de m da pgina ou
dos resultados.
breadcrumbs utilizado, por permitir no apenas voltar, mas ter uma viso geral dos
passos percorridos na sesso atual de busca.
A Busca Avanada renomeada para Reorganizar resultados por, para deixar
mais evidente qual seu efeito nos resultados. Um texto complementar indica que estes so
recarregados automaticamente (j que se observou que muitas pessoas caram confusas
com o funcionamento da busca avanada). A localizao tambm muda do topo da lista-
gem de resultados para a lateral esquerda. Isso possibilita que ela continue sempre visvel,
porm sem roubar o espao dos resultados, que devem estar no centro das atenes.
A listagem de resultados concentra-se mais no centro da pgina, para facilitar a
captura das informaes rapidamente. Com a reestruturao, aparece mais um resultado
visvel antes da rolagem - como na verso original, quando a Busca Avanada estava
oculta. Optou-se por no colocar resultados lado a lado (como por exemplo o iFood os
apresenta), mesmo que isso permita exibir mais resultados em menos espao, para evitar
que usurios confundissem resultados ou deixar cada item muito apertado e portanto com
pouco espao para informaes dos produtos.
Os itens de resultados cam mais compactos, com informaes do produto concen-
tradas do lado esquerdo do item, criando direita uma rea de destaque para as principais
informaes da empresa que o oferece, que lembra a identidade visual de ms de geladeira
2
. Essa abordagem uma tentativa de sanar o problema de identicar o estabelecimento
que oferece o produto (j que mais de uma pessoa se confundiu, durante os testes). O link
para o portflio segue o estilo das ferramentas correlatas, para facilitar identicao, e o
ttulo do produto tambm vira link para o portflio - outra tentativa de seguir convenes,
j que normalmente, em buscadores, o ttulo do resultado um link.
Para fechar, uma mensagem informa quando no h mais resultados, respeitando
o conceito de rolagem innita, mas dando algum feedback para o usurio quando esta
acaba. O rodap existente no portflio e na pgina inicial tambm exibido, compondo
o m da pgina.
O ltimo aspecto abordado relaciona-se ao mecanismo de busca. Quando no so
encontrados resultados para a consulta feita, so sugeridas algumas opes para o usurio.
Essa foi a alternativa encontrada para, sem alterar a implementao da busca, aumentar
as chances de sucesso ou reduzir a frustrao advinda de consultas que geram conjunto
de resultados vazio. A proposta que o sistema informe que No foram encontrados
resultados para termo buscado no endereo informado., e d sugestes para o usurio:
Tentar uma nova busca;
Checar por erros de digitao;
Fazer a mesma busca com outro endereo.
Estes foram os resultados dos processos de avaliar as interfaces do fazDelivery,
identicar os problemas, prioriz-los e propor solues, levando em considerao as aes
dos usurios e as abordagens de ferramentas correlatas. A partir dos prottipos pode-se,
idealmente, realizar novas rodadas de testes com usurios, para conrmar se as propostas
resolvem ou no os problemas e vericar a possibilidade de insero de novos problemas;
ou implementar as sugestes (depois disso, mais testes podem ser feitos, pois o nvel
de interao possvel com uma ferramenta funcional diferente do alcanado com um
prottipo).
2
Que, como so bastante comuns para servios de delivery, podem ser uma metfora visual interessante.
Figura 19 Pgina de Resultados proposta - a marcao em preto na horizontal indica
a regio above the fold: Busca Avanada rebatizada e trazida para a lateral,
para dar mais espao aos resultados. Resgatado o rodap do sistema.
O escopo prtico deste projeto se encerra neste captulo. As concluses da utili-
zao da metodologia, suas vantagens, limitaes e possveis caminhos futuros (como o
indicado acima aps a etapa de prototipao) so detalhados no captulo que segue.
72
9 Concluso e Trabalhos Futuros
O objetivo deste projeto foi propor e aplicar uma metodologia para avaliar a usabi-
lidade de interfaces de buscadores do tipo catlogo (i.e., com bases de dados estruturados
e conhecidos) e propor melhorias para as mesmas. A aplicao foi feita com o fazDelivery,
um buscador georreferenciado de servios de delivery para a cidade de Salvador.
Esta metodologia, adaptao da abordagem sugerida por Nielsen (1995b), possi-
bilita levantar problemas baseados em consideraes formais de como as interfaces devem
ser (as Heursticas de Usabilidade) e baseados em casos de uso reais (advindos dos Testes
com Usurios). Alm disso, ela idealmente evita que as sesses de testes com usurios
sejam prejudicadas por problemas muito evidentes existentes na interface, pois primeiro
devem ser levantados e corrigidos os problemas formais mais graves e apenas ento a
interface passa pelos testes com usurios, que podem ento oferecer mais insights sobre
questes como frustrao com tipo de resultado encontrado, ou como no dia-a-dia as
pessoas resolvem as limitaes impostas pelo sistema.
Durante o trabalho, um ponto de bastante diculdade foi como compilar e sin-
tetizar os resultados das sesses com especialistas ou usurios, no caso, principalmente
aps o levantamento feito nas Avaliaes Heursticas, pois foi gerada uma extensa lista de
problemas, abrangendo diversos aspectos e telas da ferramenta, e com impactos variados
no uxo de uso do sistema. Considerando que uma listagem com uma quantidade muito
grande de problemas poderia fazer com que poucos especialistas passassem pela etapa de
classicao dos mesmos (etapa importante das avaliaes heursticas), foi feito um re-
corte estratgico na lista de problemas inicialmente encontrados. Esta reduo de escopo
foi direcionada para a avaliao da severidade dos erros existentes na ferramenta, ou dos
aspectos que mais diretamente poderiam levar os usurios a um uxo de uso errado da
mesma.
Isto permitiu ter uma listagem mais acessvel e fcil de apresentar das violaes
heursticas, o que foi positivo. Entretanto, alm de possivelmente deixar de fora problemas
mais crticos de usabilidade, na execuo deste projeto isto no foi suciente para que
se conseguisse classicar a severidade dos problemas antes de se realizar os testes com
usurios. Desse modo, a metodologia inicialmente proposta no foi a realmente utilizada,
pois no foi feita a etapa intermediria de correo de problemas da interface. Uma possvel
abordagem para facilitar a apresentao dos problemas e evitar esse tipo de recorte
indicar visualmente, atravs de capturas de tela do sistema, todos os problemas levantados,
e solicitar a classicao a partir disso. Essa alternativa evita que seja necessrio descrever
em detalhes cada problema, e se benecia tambm do fato de que consegue apresentar
Captulo 9. Concluso e Trabalhos Futuros 73
mais problemas em menos espao, para os avaliadores.
Em relao aos testes com usurios, a principal diculdade encontrada foi de inter-
pretao do material coletado. Em parte, isso pode indicar uma necessidade de mais rigor
na denio de metas ou pers de usurio, o que ajudaria a correlacionar, por exemplo,
tempos de realizao de tarefas com algum trao demogrco. Ainda assim, no conjunto
geral, ou seja, considerando as reaes mais subjetivas dos usurios, foi possvel levantar
pontos importantes sobre frustrao, induo a erro e como a expectativa advinda do uso
de outras ferramentas inuencia na interpretao de funcionamento de uma nova ferra-
menta e, portanto, na interao com a mesma. Os testes, ento, como foram conduzidos,
funcionaram bem para uma avaliao qualitativa do sistema, mas no esto adequados
para uma comparao de interfaces, por exemplo. Isto signica que para uma avaliao
de qual a melhor interface do fazDelivery (a original ou a proposta por este projeto), o
ideal seja ter novas rodadas de testes com usurios, com as duas verses.
Um elemento acrescentado metodologia no indicado em Nielsen (1995b) mas
que foi muito importante para as fases de sugesto de solues e prototipao da interface
foi a etapa de estudo de ferramentas correlatas. Ela no apenas traz insumos de como
abordar os aspectos problemticos mas, talvez mais importante, aumenta as chances de a
interface proposta seguir padres e metforas j reconhecidos pelo usurio (isso aumenta
as chances de evitar violar a heurstica de compatibilidade com o mundo real e de seguir
padres de plataforma).
Dentro do proposto, mesmo com as limitaes apresentadas, este trabalho traz
contribuies:
ao apontar os percalos prticos do percurso metodolgico - possibilitando que se
esteja atento de antemo aos riscos e diculdades, o que permite pensar em abor-
dagens alternativas para resolv-los;
ao apresentar em mais detalhes uma aplicao prtica da metodologia proposta, que
tem possibilidades reais de melhorias para a usabilidade de um sistema, partindo
de uma necessidade real de melhorar uma interface de uso comercial e observando
limitaes de recursos comuns (e.g., falta de tempo de avaliadores para classicar
muitos problemas, ou falta de um designer para repensar toda a interface do zero),
pois leva a observar cenrios de uso reais e compara o sistema com concorrentes (e
quem sabe torn-lo mais acessvel e competitivo).
Para encerrar, consideram-se acrscimos interessantes a este projeto:
classicao da severidade de todos os problemas, para ter um melhor direciona-
mento do que deve ter mais prioridade para correo;
Captulo 9. Concluso e Trabalhos Futuros 74
utilizar (e/ou levantar) heursticas para catlogos de produtos, que levem em conta,
por exemplo, a qualidade e quantidade dos resultados existentes na base de dados
(visto que este foi um grande motivo de frustrao entre os usurios);
implementao dos prottipos e novas rodadas de testes com usurios, para fechar
pelo menos um ciclo de interao de melhoria da interface e observar o benefcio da
aplicao da metodologia completa.
75
Referncias
Alexa Internet, Inc. Alexa Top Site - Global. 2013. Disponvel em: <http:
//www.alexa.com/topsites/global>. Acesso em: 14.11.2013.
. Alexa Top Sites in Brazil. 2013. Disponvel em: <http://www.alexa.com/
topsites/countries/BR>. Acesso em: 14.11.2013.
BRODER, A. A taxonomy of web search. SIGIR FORUM, v. 36, n. 2, p. 310, 2002.
CENDN, B. V. Ferramentas de busca na web. Cincia da Informao, SciELO Brasil,
v. 30, n. 1, p. 3949, 2001.
DYKSTRA, D. J. A Comparison of Heuristic Evaluation and Usability Testing: The
Ecacy of a Domain-Specic Heuristic Checklist. PhD Thesis Texas A&M University,
1993.
GEORGIEVA, M. A/B Testing in Action: 3 Real-Life Marketing Experiments.
2012. Disponvel em: <http://blog.hubspot.com/blog/tabid/6307/bid/31634/
A-B-Testing-in-Action-3-Real-Life-Marketing-Experiments.aspx>. Acesso em:
09.10.2013.
HEARST, M. A. Search User Interfaces. [S.l.]: Cambridge University Press, 2009.
. natural search user interfaces. Commun. ACM, ACM, New York, NY, USA,
v. 54, p. 6067, nov. 2011.
HOTCHKISS, G. Q&A With Marissa Mayer, Google VP, Search Products
& User Experience. 2007. Disponvel em: <http://searchengineland.com/
qa-with-marissa-mayer-google-vp-search-products-user-experience-10370>. Acesso
em: 25.11.2013.
HOTCHKISS, G. et al. Search engine results: 2010. Enquiro Search Solutions, p.
161, 2010. Disponvel em: <http://ww.twinkelmagazine.nl/achtergronden/2007/
09/Zoekmachineresultaten_in_2010/SearchEngineResults2010.pdf>. Acesso em:
26.11.2013.
LINDGAARD, G.; CHATTRATICHART, J. Usability testing: what have we overlooked?
Proceedings of the SIGCHI conference on . . . , p. 14151424, 2007. Disponvel em:
<http://dl.acm.org/citation.cfm?id=1240839>.
MAURYA, A. Running Lean - Iterate from Plan A to a Plan That Works, 2nd Edition.
[S.l.]: OReilly, 2012. (The Lean Series).
MERUN, T. Visualization of Results and Navigation Support in User Interfaces of
Bibliographic Information Systems. 271 p. Tese (Doutorado) University of Ljubljana,
2012.
MORAES, C. S. Um Estudo de Usabilidade para Software de Prescrio de Treinamento
Neuromuscular (Digital Trainer). 56 p. Monograa Universidade do Estado da Bahia,
2010.
Referncias 76
NIELSEN, J. Usability Engineering. San Francisco, CA, USA: Morgan Kaufmann
Publishers Inc., 1993.
. 10 Usability Heuristics for User Interface Design. 1995. Disponvel em:
<http://www.nngroup.com/articles/ten-usability-heuristics/>. Acesso em: 09.10.2013.
. Characteristics of Usability Problems Found by Heuristic Eva-
luation. 1995. Disponvel em: <http://www.nngroup.com/articles/
usability-problems-found-by-heuristic-evaluation/>. Acesso em: 25.11.2013.
. How to Conduct a Heuristic Evaluation. 1995. Disponvel em: <http:
//www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/>. Acesso em:
25.11.2013.
. Severity Ratings for Usability Problems. 1995. Disponvel em: <http:
//www.nngroup.com/articles/how-to-rate-the-severity-of-usability-problems/>. Acesso
em: 25.11.2013.
. Summary of Usability Inspection Methods. 1995. Disponvel em: <http:
//www.nngroup.com/articles/summary-of-usability-inspection-methods/>. Acesso em:
25.11.2013.
. End of Web Design. 2000. Disponvel em: <http://www.nngroup.com/articles/
end-of-web-design/>. Acesso em: 01/12/2013.
. The Mud-Throwing Theory of Usability. 2000. Disponvel em: <http:
//www.nngroup.com/articles/the-mud-throwing-theory-of-usability/>. Acesso em:
13.11.2013.
. Why You Only Need to Test with 5 Users. 2000. Disponvel em: <http:
//www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/>. Acesso em:
26.11.2013.
. Discount Usability: 20 Years. 2009. Disponvel em: <http://www.nngroup.com/
articles/discount-usability-20-years/>. Acesso em: 09.10.2013.
. Usability 101: Introduction to Usability. 2012. Disponvel em: <http:
//www.nngroup.com/articles/usability-101-introduction-to-usability/>. Acesso em:
09.10.2013.
OSTERWALDER, A.; PIGNEUR, Y. Business Model Generation: A Handbook for
Visionaries, Game Changers, and Chal lengers. 1. ed. [S.l.]: Wiley, 2010.
Pew Internet. Search engine use 2012. 2012. Disponvel em: <http://pewinternet.org/
~/media/Files/Reports/2012/PIP\_Search\_Engine\_Use\_2012.pdf>. Acesso em:
09.10.2013.
RIES, E. The lean startup : how todays entrepreneurs use continuous innovation to
create radically successful businesses. New York: Crown Business, 2011.
ROCHA-JUNIOR, J. B. FazDelivery - Arquitetura de Busca e Indexao. [S.l.], 2013.
41 p.
Referncias 77
ROGERS, Y.; SHARP, H.; PREECE, J. Interaction Design: Beyond Human-Computer
Interaction. [S.l.]: John Wiley and Sons Ltd, 2002.
SERRA, A. R. Princpios do Design de Interfaces Aplicados Busca. 37 p. Monograa
Universidade Federal do Rio de Janeiro, 2010.
SHNEIDERMAN, B.; BYRD, D.; CROFT, B. W. Clarifying search: A user-interface
framework for text searches. D-Lib Magazine, 1997.
TULLIS, T.; ALBERT, W. Measuring the user experience: col lecting, analyzing, and
presenting usability metrics. [S.l.]: Morgan Kaufmann, 2010.
WILSON, M. Search User Interface Design. 2012. Disponvel em: <http://www.
slideshare.net/gingdotslideshare/search-user-interface-design>. Acesso em: 28.11.2013.
. Extended Searching Sessions and Evaluating Success. 2013. Disponvel em: <http:
//www.slideshare.net/gingdotslideshare/understanding-evaluating-search-sessions>.
Acesso em: 28.11.2013.
78
APNDICE A Outras Capturas de
Interfaces de busca
A.1 Exemplos de Atalhos em Resultados de Busca
Figura 20 Predio do Google de desejo de resposta do usurio, para a consulta 3 +
5, que, alm de exibir diretamente o resultado, oferece uma calculadora.
APNDICE A. Outras Capturas de Interfaces de busca 79
A.2 SERP do Open Directory Project
Figura 21 Listagem de resultados do Open Directory Project. Nesta captura completa,
possvel ver, nda a lista de resultados, os elementos para realizar outra
consulta - preciso rolar toda a tela.
80
APNDICE B Detalhamentos de
Elementos do fazDelivery
B.1 Listagem de Resultados
Figura 22 Viso da regio above the fold da listagem de resultados do fazDelivery,
quando os ltros no esto visveis.
APNDICE B. Detalhamentos de Elementos do fazDelivery 81
B.2 Pgina Inicial Completa
Figura 23 Viso completa da pgina inicial do fazDelivery, com seu formato long letter,
com argumentos para escolha da ferramenta. A linha preta delimita o corte
acima do qual o usurio no precisa rolar para ver o contedo da pgina
(a.k.a. regio above the fold).
B.3 Portflio de Empresa
Figura 24 O portflio da pizzaria Passione, no fazDelivery.
B.4 Diagrama de Classes - Camada de Controle
Figura 25 O diagrama de classes da camada de controle do fazDelivery, com seus mto-
dos pblicos visveis.
RoteiroeOrientaesparaasSessesdeAvaliaoHeurstica
Comoocorreroassesses?
No horrio combinado, estarei online por hangout ou skype (voc escolhe o que funciona melhor
pra voc), disponvel para conversarmos por call ou chat, e acompanharei toda a sua sesso,
paraesclarecerquestesetirardvidas.
Comofuncionaumasessodeavaliaoheurstica?
1. Vocdevepercorrertodoosistema,pelomenosduasvezes:
a. na primeira, use alguns minutos para ter uma viso geral da ferramenta. Voc
no precisa anotar problemas nesse momento, utilizeo para observar o fluxo do
sistema,comocadatelaeaoserelacionameencaixamnotodo.
b. no segundo momento, dedique um tempo maior a cada tela, e atentando se ela
segueasheursticasdeusabilidadelistadas.
2. Alm das heursticas, sua experincia e bom senso tambm so bem vindos na
inspeo das telas. Se algo lhe soar ruim, no hesite em pontuar, tambm. Quando
identificarumproblema:
a. anoteo, com alguma descrio que torne possvel outras pessoas o
identificarem,tambm
b. sequiser,vocpodertirarscreenshotsquerepresentemoproblemaouerro.
3. Apsterminaroprocesso,enviesuasanotaesparamim:
a. jufajardini@gmail.com
CenriodeUso
Nielsen recomenda que, para ajudar a ter um ponto de vista mais prximo dos usurios da
ferramenta, os avaliadores sejam apresentados a um cenrio de uso da mesma. Como o
fazDelivery no est mais em desenvolvimento, sua base no cresceu muito. Assim,
necessrio alguns cuidados para que se alcance um fluxo de sucesso com o uso do buscador.
ParaofazDelivery,umcenrio(desucesso)possvelseria:
Exemplos de endereos cobertos pela rea de atendimento dos estabelecimentos no

fazDelivery:
AvenidaTancredoNeves,Caminhodasrvores,Salvador.CEP41820021
AvenidaAntnioCarlosMagalhes,Caminhodasrvores,Salvador.CEP41820000
84
APNDICE C Roteiro para Avaliaes
Heursticas
AvenidaManoelDiasdaSilva,Pituba,Salvador.CEP41830000
Exemplosdeprodutosquenoretornambuscaembranco:
Yakisoba
Pizza
guamineral
Classificandoagravidadedosproblemasencontrados
Aps as sesses, os problemas e erros encontrados por voc e pelos outros avaliadores sero
compilados em uma lista, que ser enviada a todos que inspecionaram o sistema. Cada
problema vir acompanhado de uma descrio para que voc possa classificar, de acordo com
seuentendimento,quograveoproblema,nocontextodaferramenta.
A classificao ser utilizada para calcular a mdia do grau de severidade de cada erro,
paraquesejapossvelpriorizarquaisdevemsercorrigidos.
Avaliados os problemas listados, sua contribuio est concluda! :) Mas esteja a
vontadeparadarcrticasousugestesaoprocessoeaoprojeto,sequiser.
Materialdeorientao
As heursticas a serem observadas nesta avaliao esto descritas abaixo. Alm delas, como
dito, voc pode utilizar seu feeling em relao usabilidade de plataformas web, ergonomia e
estticaparadecidiroqueumproblemaouno.
HeursticasparaoDesigndeInterfacesdeUsurio
Heursticas so boas prticas para orientar algo. No contexto da usabilidade, h uma lista de 10
heursticas bem disseminadas na rea, que buscam cobrir os aspectos mais importantes da
interao do usurio com uma dada ferramenta. Cada tela do sistema pode conter vrios
problemas, e importante que cada um seja descrito em separado, com referncia ao(s)
problema(s) de usabilidade e/ou s heursticas que ele fere. Isso evita que verses futuras da
interface no incorram nos mesmos problemas, e ajuda, quando no for possvel corrigir todas
as irregularidades apontadas, a decidir quais sero abordadas primeiro. As heursticas
observadasnestaavaliaosero:
Visibilidade do status do sistema (feedback): o sistema sempre deve manter os

usurios informados sobre o que est acontecendo, atravs de feedback apropriado e
emtempohbil
Compatibilidade entre o sistema e o mundo real (metfora): o sistema deve falar a
linguagem do usurio, com palavras, frases e conceitos familiares a ele, ao invs de
utilizar termos tcnicos. Devese seguir convenes do mundo real. A informao deve
apareceremumaordemlgicaenatural
Controle e liberdade para o usurio (navegao): os usurios frequentemente
escolhem funes do sistema sem querer, e precisaro de sadas de emergncia bem
definidas para sair de um estado indesejado de forma rpida e simples. Deve dar
suporteaaesdedesfazer,refazer,cancelar
Consistncia e padres (consistncia): os usrios no devem precisar se perguntar
se diferentes palavras, situaes ou aes significam a mesma coisa. Seguir padres
naplataforma
Preveno de erros (preveno): melhor do que oferecer boas mensagens de erro
ter um design cuidadoso, que previna que problemas ocorram, em primeiro lugar.
Eliminar condies propensas a erros, ou checar quando acontecerem, apresentando
aosusuriosopesdeconfirmaoantesdeelesrealizaremtaisaes
Reconhecimento ao invs de lembrana (memria): minimizar a sobrecarga da
memria dos usurios, tornando objetos, aes e opes visveis. O usurio no deve
precisar lembrar de informaes de uma parte da tela para outra. Instrues para uso do
sistemadevemservsiveisoufceisdeencontrarsemprequeapropriado
Flexibilidade e eficincia no uso (eficincia): aceleradores (ou atalhos) que no
precisam estar visveis para usurios novatos podem, frequentemente, acelerar a
interao do usurio experiente, de forma que o sistema atenda a pessoas com
variadosnveisdeexperincia
Design e esttica minimalistas (design): as telas no devem conter informao que
no relevante, ou que raramente necessria. Cada unidade extra de informao em
umatelacompetecomasunidadesrelevantesediminuisuavisibilidaderelativa
Auxiliar usurios a reconhecer, diagnosticar e se recuperar de erros
(recuperao): mensagens de erro devem ser expressas em linguagem simples e
direta (no em cdigos), indicar precisamente qual o problema e sugerir solues
construtivas
Ajuda e documentao (ajuda): ainda que seja melhor que o sistema possa ser
utilizado sem manuais, pode ser necessrio prover ajuda e documentao. Qualquer
informao deste tipo deve ser fcil de buscar, focada na tarefa do usurio, listar etapas
concretasparasuarealizaoenosermuitogrande.
ClassificaodaSeveridadedeProblemasdeUsabilidade
Como dito anteriormente, esta classificao feita a posteriori, ento no necessrio

preocuparsecomeladuranteasessodeavaliaoheurstica.
No momento de avaliar a severidade de um problema de usabilidade devese levar em
consideraotrsfatores:
frequnciacomqueeleocorre:algocomum,ouraro?
impactodoproblema,seeleocorre:fciloudifcilparaosusuriossuperlo?
persistncia do problema: tratase de algo de ocorrncia nica, que os usurios podem
superarumavezqueconheam,oualgoqueosincomodarreiteradamente?
Esses trs aspectos costumam ser combinados para gerar uma nica classificao,
para cada problema. Use a seguinte escala para avaliar os problemas levantados por esta
sessodeavaliaoheurstica:
0=Noconcordoqueissosejaumproblemadeusabilidade.
1 = Problema cosmtico, apenas: no precisa ser corrigido, a menos que haja tempo
livredisponvelnoprojeto
2=Pequenoproblemadeusabilidade:baixaprioridadepararesoluo
3=Grandeproblemadeusabilidade:importanteresolvlo,altaprioridade
4 = Problema de usabilidade catastrfico: o produto no deveria ser lanado sem
resolveresteproblema(outratasedeumacorreourgente)
Algumadvida?
Sentiu falta de alguma orientao ou conceito? Por favor, entre em contato comigo para que eu
possaesclarecloparavoceosdemaisoquantoantes!
Gratamaisumavezpelaparticipao,
Juliana
AvaliaoHeursticafazDelivery
Parareduziraquantidadedeproblemasidentificadosnasavaliaesheursticasqueprecisamser
classificados,apenasosproblemasdiretamenterelacionadoscomheursticasdeerros(Prevenode
Erros,AjudaraDetectareRecuperarsedeErros),ouquepoderiamlevaraerrosporpartedos
usurios,foramaquilistados.Elesestoseparadosportelaemqueocorrem.
SevocquiservoltaraofazDeliveryenquantorespondeaestequestionrio,sigaolink:
www.fazdelivery.com.br
Suaclassificaosercontabilizadajuntocomad@sdemaisavaliador@sparagerarumamdiada
severidadedecadaerroeembasaraescolhadequaisdeverosercorrigidos.
*Obrigatrio
Sobrevoc
Essainformaoparacontroleinternoenoserdivulgadanoprojeto.
1. Nome*
PginaInicial
Problemasencontradosnapginainicial.
Paracadaproblema,avalieaseguinteescaladeusabilidadeparafazersuaclassificaodeseveridade
1=Problemacosmtico,apenas:noprecisasercorrigido,amenosquehajatempolivredisponvelno
projeto
4=Problemadeusabilidadecatastrfico:oprodutonodeveriaserlanadosemresolveresteproblema
(outratasedeumacorreourgente)
2. Mapadescentralizado,dificultandosuavisualizao.*
Nofazsentidoomapaapareceremumaposionatelaondenopossvelvlobem.
Marcarapenasumaoval.
0 1 2 3 4
Eunoconsideroissoum
problema
Problemadeusabilidade
muitosevero
88
APNDICE D Questionrio de
Classicao de Severidade
3. svezes,sistemanoconseguelocalizarendereoatravsdoCEP.*
Nessasocasies,osistemanoexibequalquermensagemparaousurio,nemdsugestesde
soluo,tampoucoserecuperaautomaticamentedoproblema.Mesmoproblematambmpode
ocorrer:najanelaparamudanadeendereo.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
4. Sistemanoorientaqualoformatodeendereoaceito,mesmonoaceitandoqualquer
formatoe.g.CEPnopodecontertrao.*
Almdapginainicial,ocorrenaJaneladeMudanadeEndereo.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
5. Textodeajudasobreformatospossveisdeendereonomuitovisvel.*
ProblematambmocorrenaJaneladeMudanadeEndereo.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
6. Modocomoosistemacarregaosendereosparasugestopodelevaraerros.*
Carregamentolentoequandohmuitassugestes,comooespaoreduzido,aleiturados
endereosficacomprometida.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
7. Quandoousurioinformaapenasobairro,noendereo,noficaclaroqueosistema
escolheumendereoaproximadoapartirdisso,nemqueendereofoiescolhido.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
8. Ocampodeendereonoexibeendereosmuitolongoscompletos,masosdeixacortados.
*
Issopodelevarousurioaescolherumendeodiferentedodesejado.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
9. Sistemaofereceaopodepegarendereodousurioatravsdopinolocalizadonomapa,
masnoconseguedefatofazlo.*
Quandoousuriotentautilizaressafuncionalidade,osistemasempreinformaquenoconseguiu
pegarsualocalizao.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
10. Sistemaexibiumensagemdeerronotratada,quandousuriotentouutilizara
funcionalidadedecapturaautomticadeendereomuitasvezesseguidas.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
11. Adependerdaresoluodetela/navegadordousurio,opinoparacapturarlocalizaodo
usuriopelomapaaparececompletamenteforadelugar(sequervisvelnatela).*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
PginadeResultados
projeto
12. Senohestabelecimentosqueoferecemoprodutoparaoendereoescolhidopelousurio,
buscainformaapenasquenoexistemresultados.*
Osistemanoindica,porexemplo,quenohprodutosparaoendereoespecificado.Issopode
levarousurioapensarqueosistemanotemmuitosprodutos,oquepodeserestranhopara
consultasporprodutosquecostumamserfacilmenteencontrados.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
13. Textoinformandosobreconjuntoderesultadosvaziotemerrodeportugus.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
14. Botodemostrartelefonetemcomportamentoestranho.*
Primeironecessrioclicarparaqueotelefoneaparea,depoisapenaspassaromouseporcimao
mostra,massistemadeixadeexibiloseomousesaidoboto,podeserconfuso,irritantee
frustranteparaousurio.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
15. Buscaavanadasvezesexibidaemcontextosemquenofunciona.*
Abuscaavanadanodeveserexibidanalistagemporcategoriasjquenomaisocontexto
debusca,masistotambmnoficaclaroparaousurio.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
16. Nomedoestabelecimentoficamuitoembaixo,longedamarcadaempresa,eaomesmo
tempomuitoprximodooutroresultado.*
Passaduasimpresses:1)dequenomeestrelacionadoaoresultadoseguinte2)dequenome
noestpresente.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
17. Mauusodoespaamentoentreoselementos.Diferentestensnapginaderesultadosora
estoprximosdemais,oramuitodistantes,mesmosendosemanticamenteprximos.
Leituraeinterpretaodoquecadaumficamprejudicadas.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
18. TextodeexplicaodaBuscaAvanadaestdistantedolinkparaamesma,dificultandoa
associaodetaiselementos.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
19. FontedoslabelsdosslidersdaBuscaAvanadaestmuitopequena.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
20. Porvezes,asinformaesexibidasnosresultadosdebuscasoinsuficientesparaentender
oqueoitemlistado.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
21. Informaodetempodeentrega,quandoexiste,ficapoucovisvel(muitoapagada).*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
22. Tempodeentregaedistnciaestocomolinks,masnotmcomportamentodeum(i.e.,
nolevamalugaralgum).*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
23. Faltamelementosparadarconfianaaosusuriosemrelaoaosprodutos,serviose
estabelecimentoslistados.Faltaalgumtipodeavaliaodoestabelecimento.*
Tambmumproblema:nosportfliosdosestabelecimentos.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
24. Paraavaliarumproduto,sistemapedeparafazerloginmesmoseousuriojestiver
logado.*
Epedenovamenteacadanovoitemquesetentaavaliar.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
25. Aoselecionarumacategoriaefazerumanovabusca,aoinvsdeabuscaserinternaao
escopodecategoria,voltaparaoescopoglobal.*
Aexpectativa,aqui,queabuscaocorranoescopoqueosistemaestapresentandono
momento,masocontextotrocado,enohqualqueraviso,oquepodeserfrustrante.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
Sistemadebusca
Problemasrelacionadosbusca,ondequerqueocorram.
projeto
26. Buscasvezestrazresultadosmuitodiferentesdaconsultarealizada,semdeixarclaroos
elementosquelevaramaisso.*
Alistagemderesultados,porvezes,nofazqualquersentidoparaomodelodemundodousurio,
porexemplo,listando"massagem"paraumaconsultapor"massa".
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
27. Sistemanoidentificaquandoumabuscaestpossivelmenteerrada.*
Comerrosdedigitao,outermosmuitovagose.g.,buscarapenaspor"as".Noexibida
qualquersugestodetermos,oualertadequeresultadosestranhospoderoserretornados.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
28. Sistemanodeixaclaroquenoconseguerealizarumabuscasenoforinformado
endereo.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
Portflio
Problemasocorridosnainteraocomoportflio.Sedesejarvisitarumportfliopararesponderaessa
seo,vocpodeclicarnolink:http://www.fazdelivery.com.br/store/apizza
projeto
29. Barradebuscainternaaoportflionemsemprefunciona.*
svezesocampoficadestacadocomhighlight,masaosetentardigitar,nadaacontece.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
30. Mensagemdosistemadebuscainternaparaconjuntoderesultadosvazionosome,mesmo
quandosepassaanavegarpelomenulateraldecategorias.*
Seousuriorealizaumabuscadentrodoportflioenohresultadosparaaconsultarealizada,a
mensagemcontinuaaparecendomesmoquandoousuriosaidocontextodabusca.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
31. svezes,marcasdeempresasficamdescentralizadasesaemdascaixasquedeveriam
limitlas(quebradelayout).Naverdade,issopodeaconteceremqualquerteladosistema
quemostremarcasdeestabelecimentos*
Ondepodeocorrer:naseoderecomendaes,napginaderesultados,nalistagempor
categorias.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
32. conesdasredessociaissoexibidosmesmoqueoestabelecimentonoostenha(ea
distinoentreconeativoounomuitosutil).*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
33. conesreferentesaopagamentodoestabelecimentosopequenosdemais,dificultam
interpretaodosmesmos.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
34. svezes,aoclicarparaexibirfotodeumproduto,aoinvsdeosistemaabrirumajanelade
dilogoexibindoafoto,abreaimagemnaabacorrentedousurio(noocorresempre,nem
foiidentificadooqueocausa).*
Comportamentoinesperadoedespadronizadoparaessetipodecontexto,tantopiorporquetira
completamenteousuriodocontextodaplataforma.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
35. Quandosepassaomousesobreoconederemoveravaliaodeumprodutojavaliado,
apagamseasestrelaselabeldeavaliao.*
Depoisasmesmasreaparecem,masaprimeiraimpressodequeosistemaapagouaavaliao
antesdequalqueraosertomadadefato.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
Plataformacomoumtodo
Problemasqueocorremnoconjuntodaplataforma.
projeto
36. Layoutquebraemvriasresolues(ounavegadores),porexemplo,paratelasmaiores,ou
noMac.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
Poweredby
37. Apginainicialdizqueositeresponsivo,masno.*
Nofuncionaacontentoemtabletsousmartphones,sequeremvariadasresoluesdedesktop.
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
38. Formadefuncionamentodaplataformanoficatoclara,senoforpreviamenteexplicado.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
39. QuandoseclicanamarcadofazDeliveryparavoltarpginainicial,osistemaperdeo
endereodousurioeinformaesdaconsultarealizada.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
40. conedefechar(x)dealgumasjanelasdedilogocompoucodestaqueesem
padronizaodeformato.*
0 1 2 3 4
Eunoconsideroissoum
problema
muitosevero
98
APNDICE E Instrumentos para os Testes
com Usurios
TermodeConsentimento
VocestsendoconvidadoparaparticipardapesquisadeAnlisedeUsabilidadedofazDelivery.
Suaparticipaonoobrigatriaeporserumaparticipaovoluntriaeseminteressefinanceiro
vocnoterdireitoanenhumaremunerao.Aqualquermomentovocpodedesistirdeparticipare
retirarseuconsentimento,bastandoapenasinformarsuadeciso.
Suarecusanotrarnenhumprejuzoemsuarelaocomospesquisadores.Osobjetivosdeste
estudosoanalisarausabilidadedaferramentafazDelivery(www.fazdelivery.com.br)paradetectar
falhasepontosquegeramdificuldadenousopelosusuriosepropormudanasquemelhorema
ferramenta.OfazDeliveryummecanismodebuscadedeliveriesqueutilizageoreferenciamentopara
exibirosmelhoresresultadosdedeliveryemsuaregio.
Suaparticipaonestapesquisaconsistiremutilizaraferramentadeacordocomumroteiro,e
responderaquestessobreessaexperincia.Nohriscosouprejuzosconhecidosporseparticipar
nestapesquisa.
Asinformaesobtidasatravsdessapesquisaseroconfidenciaiseasseguramososigilo
sobresuaparticipao.Osdadosnoserodivulgadosdeformaapossibilitarsuaidentificao.Em
casodenecessidadedeutilizaodealgumainformaoespecficadeumparticipante,utilizaremos
nomesfictciosparailustraromesmo.
Afirmoparaosdevidosfinsquesoumaiorde18anosedesejoparticipardoprojetodepesquisaque
estsendoconduzidoporJulianaFajardiniReichow,estudantedegraduaodocursodeSistemasde
InformaodaUniversidadedoEstadodaBahiaUNEB,concordandocomestetermode
consentimento.
*Obrigatrio
1. Qualseunomecompleto?*
2. Euconsintoemparticipardestarodadadetestesdeusabilidade*
Marcarsimnestarespostarepresenta,paraestetermo,omesmoquedarsuaassinatura.:)
Sim
No
3. DatadeConsentimento
Exemplo:15dedezembro
QuestionriodeEntrada
Esteumquestionrioparaentenderseuperfil.Oquevocdissernelenoserutilizadopara
identificarvocunicamentenosresultadospublicadosdoprojeto.
4. Quantosanosvoctem?
APNDICE E. Instrumentos para os Testes com Usurios 99
E.1 Termo de Consentimento e Questionrio de Entrada
Poweredby
5. Qualseusexo?
Masculino
Feminino
6. Vocmorasozinho(a)?
Sim
No
7. Qualsuaexperinciadeusocomainternet,nodiaadia?
1 2 3 4 5
Usonomximoumavezporsemana,ou
apenasparatrabalho.
Usotodosos
dias,para
trabalhoe
lazer.
8. Vocjcomproualgumprodutoouservioviadelivery?
Teleentrega,entregaemdomiclioetc.
0 1 2 3 4
Nuncapedi Peoumavezporemana
9. VocjutilizououinteragiucomainterfacedofazDeliveryemalgumaoutraocasio?
Sim
No
10. VocjusoualgumsitecomoiFood,GuiaMaisousimilar?
Parapedircomidaoualgumoutroservio,paraencontrarcontatodeempresas?
Sim
No
Outro:
QuestionriodeEncerramento
Parafechar,gostariadesaberalgumascoisassobresuaexperinciacomousodofazDelivery.
1. Seunome,novamente
Parapoderassociarcomseuperfildemogrfico.
^.^
2. FoifcilusarofazDeliveryparafazerastarefasprdefinidas?
1 2 3 4 5
No,tivebastantedificuldade. Sim,foimuitofcil.
3. FoifcilusarofazDeliveryparafazeratarefaaberta?
Atarefaabertafoiaquelaemquevocescolheuoqueiriapesquisar.
1 2 3 4 5
No,tivebastantedificuldade. Sim,foimuitofcil.
4. Foifcilrealizaramudanadeendereo?
OfazDeliverymostraclaramenteondefazeressamudana,ecomodeveserfeita?
1 2 3 4 5
Tivedificuldadeenosentiqueo
sistemameajudouaresolvlas.
Foitranquilo
encontraronde
mudaroendereoe
sabercomofazlo.
5. Considereoutrasocasiesemquepediucoisaspordelivery,levandoemcontatempopara
encontrarcontatoeescolheroquepedir.
Nasuaopinio,otempogastonofazDeliveryparafazeramesmacoisacompatvel,aceitvel?
1 2 3 4 5
No,foidemoradoeconfuso.
Prefiromeumtodoatual.
Sim,foiprticoe
umaalternativavivel
nessesmomentos.
E.2 Questionrio de Sada
Poweredby
6. Noconjunto,comovocclassificaaexperinciadeusodofazDelivery?
1 2 3 4 5
NogosteideusarofazDelivery,no
usarianovamente.
Gosteimuitode
usar,usaria
outrasvezes.
7. Sequiser,faleumpoucosobrecomofoiusarofazDelivery.Gostouespecialmentedealgo?
Sesentiufrustado(a)comalgumacoisa?

E.3 Tarefas de Consulta para os Testes com Usurios
Tabela 12 Tarefas de Busca Preestabelecidas para os Testes com Usurios
Tarefa Tipo
Pegar o telefone de um lugar que venda gua Busca por produto
Encontre o telefone de um lugar que venda cerveja Busca por produto
Conseguir o telefone de um lugar que venda pizza de atum Busca por produto
Encontrar o telefone de um lugar que venda yakisoba Busca por produto
Encontrar o telefone da Subway Busca por estabelecimento
Encontrar o telefone da pizzaria Rocca Busca por estabelecimento
Encontrar o telefone da pizzaria do canal Busca por estabelecimento
Encontrar o telefone de uma oricultura Busca por estabelecimento

Inspeção e Evolução Da Usabilidade de Buscadores Tipo Diretório: Estudo de Caso Com o Fazdelivery

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Inspeção e Evolução Da Usabilidade de Buscadores Tipo Diretório: Estudo de Caso Com o Fazdelivery

Caricato da

Copyright:

Formati disponibili

Juliana Fajardini Reichow

Inspeo e Evoluo da Usabilidade de

Exemplos de endereos cobertos pela rea de atendimento dos estabelecimentos no

Visibilidade do status do sistema (feedback): o sistema sempre deve manter os

Como dito anteriormente, esta classificao feita a posteriori, ento no necessrio

APNDICE E. Instrumentos para os Testes com Usurios 103

Potrebbero piacerti anche