UNIVERSIDADE FEDERAL DO RIO DE JANEIROINSTITUTO DE MATEMÁTICA
INSTITUTO TÉRCIO PACITTI DE APLICAÇÕES E PESQUISASCOMPUTACIONAIS
PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA
VINICIUS BASTOS BITTENCOURT
USABILIDADE EM APLICATIVOSMÓVEIS: HEURÍSTICAS PARA
SITUAÇÕES-LIMITE
Rio de Janeiro2018
UNIVERSIDADE FEDERAL DO RIO DE JANEIROINSTITUTO DE MATEMÁTICA
INSTITUTO TÉRCIO PACITTI DE APLICAÇÕES E PESQUISASCOMPUTACIONAIS
PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA
VINICIUS BASTOS BITTENCOURT
USABILIDADE EM APLICATIVOSMÓVEIS: HEURÍSTICAS PARA
SITUAÇÕES-LIMITE
Dissertação de Mestrado submetida aoCorpo Docente do Departamento de Ci-ência da Computação do Instituto de Ma-temática, e Instituto Tércio Pacitti deAplicações e Pesquisas Computacionais daUniversidade Federal do Rio de Janeiro,como parte dos requisitos necessários paraobtenção do título de Mestre em Informá-tica.
Orientador: Adriana Santarosa VivacquaCo-orientador: Wallace Corbo Ugulino
Rio de Janeiro2018
CBIB Bittencourt, Vinicius Bastos
Usabilidade em Aplicativos Móveis: Heurísticas para Situações-Limite / Vinicius Bastos Bittencourt. – 2018.
100 f.: il.
Dissertação (Mestrado em Informática) – Universidade Federal doRio de Janeiro, Instituto de Matemática, Instituto Tércio Pacitti de Aplicaçõese Pesquisas Computacionais, Programa de Pós-Graduação em Informática,Rio de Janeiro, 2018.
Orientador: Adriana Santarosa Vivacqua.Co-orientador: Wallace Corbo Ugulino.
1. Avaliação de Usabilidade. 2. Aplicativos Móveis. 3. AvaliaçãoHeurística. 4. Situações-Limite. – Teses. I. Vivacqua, Adriana Santarosa (Ori-ent.). II. Ugulino, Wallace Corbo (Co-orient.). III. Universidade Federal doRio de Janeiro, Instituto de Matemática, Instituto Tércio Pacitti de Aplicaçõese Pesquisas Computacionais, Programa de Pós-Graduação em Informática. IV.Título
CDD
VINICIUS BASTOS BITTENCOURT
Usabilidade em Aplicativos Móveis: Heurísticas paraSituações-Limite
Dissertação de Mestrado submetida ao Corpo Do-cente do Departamento de Ciência da Computa-ção do Instituto de Matemática, e Instituto TércioPacitti de Aplicações e Pesquisas Computacionaisda Universidade Federal do Rio de Janeiro, comoparte dos requisitos necessários para obtenção dotítulo de Mestre em Informática.
Aprovado em: Rio de Janeiro, de de .
———————————————————————Profa. Dra. Adriana Santarosa Vivacqua (Orientador)
———————————————————————Prof. Dr. Wallace Corbo Ugulino (Co-orientador)
———————————————————————Prof. Dr. Marcos Roberto da Silva Borges
———————————————————————Eng. Dra. Denise Del Re Filippo
———————————————————————Prof. Dr. Alberto Barbosa Raposo
Aos meus avôs Walter e Ady (in memoriam).
AGRADECIMENTOS
Os agradecimentos são a todos aqueles que de alguma forma contribuíram paraque eu chegasse onde estou.
Em primeiro lugar, gostaria de agradecer à minha família, especialmente aosmeus pais Jorge e Valéria, aos meus irmãos Lucas e Júlia, e aos meus avôs Evandroe Martha, que sempre estiveram presentes para me apoiar e incentivar.
Agradeço aos meus amigos da vida toda, que sempre estiveram ao meu ladoproporcionando bons momentos. Muito obrigado pela inspiração e companheirismo.
A Adriana Vivacqua por todo o suporte e orientação no desenvolvimento dessetrabalho e a Wallace Ugulino que me co-orientou com dedicação mesmo estando emoutro continente.
A todos os demais professores do Programa de Pósgraduação em Informáticado Departamento de Ciência da Computação da Universidade Federal do Rio deJaneiro, com os quais eu tanto aprendi.
Agradeço especialmente a todos os voluntários que cederam seu tempo paraparticipar do pré-experimento e do experimento final desta pesquisa.
A todos que não foram relacionados acima, certamente não por falta de impor-tância.
RESUMO
Aplicativos móveis (“apps”) estão presentes no dia a dia das pessoas e podemser úteis em diversas situações. Avaliar a usabilidade de um app é essencial paraque seus desenvolvedores entreguem um produto de qualidade em um mercado tãocompetitivo. O contexto do uso é um fator importante que deve ser consideradodurante uma avaliação. Esta pesquisa investiga o uso das Heurísticas de Nielsenpara detectar problemas de usabilidade nos aplicativos mais baixados nas áreas decomunicação e referência, no contexto de situações-limite, usando video games comoindutores de stress com 20 usuários. Através de dados biométricos do nível de stresscoletados via sensores do tipo Skin Galvanic Response (GSR) e correlacionando asleituras obtidas com o nível de stress auto-atribuído em questionário, foi possívelconfirmar se os usuários estavam de fato se sentindo estressados. Como resultado,para acomodar as situações-limite no teste de usabilidade, foi verificada a necessi-dade de melhor especificar ou alterar 4 heurísticas e adicionar outras duas.
Palavras-chave: Avaliação de Usabilidade. Aplicativos Móveis. Avaliação Heurís-tica. Situações-Limite.
ABSTRACT
Mobile applications (“apps”) are present in people’s everyday lives and can behelpful in many situations. Evaluating the usability of an app is essential for itsdevelopers in order to deliver a high-quality product in such a competitive market.The context of use is an important factor that must be considered during an evalu-ation and this research investigates the use of Nielsen’s heuristics to detect usabilityproblems in best-selling communication and reference apps, in the context of limit-situations, by using video games as stress-inducers with 20 users. We confirmed ifusers were actually stressed by collecting biometric measures of Skin Galvanic Re-sponse sensors and by correlating the readings with users’ self-assessment level ofstress. As a result, in order to accommodate limit-situations in the usability test,we found out the need of better specifying or modifying 4 Nielsen’s heuristics andadding 2 more heuristics.
Keywords: Usability Evaluation. Mobile Applications. Heuristic Evaluation.Limit-Situations.
LISTA DE FIGURAS
Figura 3.1: Mindfield eSense Skin Response - Sensor GSR . . . . . . . . . . . 40Figura 3.2: Tela do jogo (à esquerda) e manual de instruções (à direita) . . . 43Figura 3.3: Esquema do ambiente laboratorial para realização do estudo ex-
ploratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 4.1: Vídeo de uma rodada do estudo piloto após sincronização do jogo,câmera e leitura do sensor . . . . . . . . . . . . . . . . . . . . . . 53
Figura 4.2: Três exemplos de leituras do sensor GSR: os dois primeiros, commaiores picos de variações correspondem a participantes que rela-taram maior stress, enquanto o terceiro, com variações menores,mostra um participante que relatou pouco stress . . . . . . . . . . 54
Figura 4.3: Um participante realiza as tarefas do estudo exploratório, com asua imagem capturada via GoPro . . . . . . . . . . . . . . . . . . 56
Figura 4.4: Exemplos de gravações das telas do celular durante o estudo ex-ploratório . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 4.5: Número de ocorrências por categoria de problema . . . . . . . . . 68Figura 4.6: Cartão de Informação na parte inferior da tela do Google Maps:
durante o estudo (à esquerda) e agora, após uma atualização (àdireita). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figura 4.7: Parte de baixo da tela do Google Maps visualizando um ponto deinteresse: como é atualmente (à esquerda) e como poderia ser seas instruções de uso fossem mais explícitas (ao centro e à direita) 73
Figura 4.8: Aplicativo Google Translator em sua versão atual (à esquerda) eum protótipo para ajudar a notar a existência do atalho (à direita) 76
LISTA DE TABELAS
3.1 Tarefas Propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1 Problemas de usabilidade encontrados . . . . . . . . . . . . . . . 664.2 Categorias dos Problemas Encontrados . . . . . . . . . . . . . . . 67
A.1 Perguntas do Questionário . . . . . . . . . . . . . . . . . . . . . . 89A.2 Respostas do Questionário . . . . . . . . . . . . . . . . . . . . . . 98
LISTA DE ABREVIATURAS E SIGLAS
IHC Interface Humano-Computador
SDK Software Development Kit
GSR Galvanic Skin Response
PSS Perceived Scale Stress
TSST Trier Social Stress Test
SMS Short Message Service
app Aplicativo Móvel
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1 PROPOSTA DE PESQUISA . . . . . . . . . . . . . . . . . . . . . . . 15
2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . 172.1 USABILIDADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 AVALIAÇÃO DE USABILIDADE . . . . . . . . . . . . . . . . . . . . 202.2.1 Avaliação Heurística . . . . . . . . . . . . . . . . . . . . . . . . 232.2.2 Heurísticas mais atuais . . . . . . . . . . . . . . . . . . . . . . 272.2.3 Aplicativos móveis . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.4 A importância do contexto na avaliação de usabilidade . . 35
3 PROCEDIMENTOS DESTA PESQUISA . . . . . . . . . . . . . . . 383.1 ESTUDO PILOTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2 ESTUDO EXPLORATÓRIO . . . . . . . . . . . . . . . . . . . . . . . 44
4 RESULTADOS OBTIDOS . . . . . . . . . . . . . . . . . . . . . . . 524.1 RESULTADOS DO ESTUDO PILOTO . . . . . . . . . . . . . . . . . 524.2 RESULTADOS DO ESTUDO EXPLORATÓRIO . . . . . . . . . . . . 554.2.1 Dificuldade na entrada de dados por voz . . . . . . . . . . . 684.2.2 Dificuldade de encontrar um conteúdo presente na tela . . 704.2.3 Caixas de diálogo (modais) bloqueando o acesso rápido a
uma tela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.2.4 Dificuldade de compartilhar informações entre aplicativos 754.2.5 Dificuldade de encontrar um elemento de interface pre-
sente na tela e Dificuldade em entender o significado deelementos de interface presentes na tela . . . . . . . . . . . . 77
4.2.6 Dificuldade de visualizar ou perceber uma notificação . . . 774.2.7 Dificuldade de acionar um botão por motivos ergonômicos 794.2.8 Dificuldade de buscar um elemento em uma lista . . . . . . 804.2.9 Dificuldade de voltar a um estado anterior . . . . . . . . . . 80
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
APÊNDICE A QUESTIONÁRIO E RESPOSTAS PÓS-ESTUDO . . . 88
11
1 INTRODUÇÃO
Um Sistema de Informação pode ser definido como qualquer sistema, automa-
tizado ou não, que abrange pessoas, máquinas e/ou métodos que coletam, processam,
transmitem ou disseminam dados que representam informações relevantes para um
determinado usuário.
No começo dos anos 40, os computadores eram constituídos de válvulas ele-
trônicas, componentes grandes, caros e de vida curta. Nessa época os computadores
só tinham utilidade cientifica. A partir da década de 70, surgiram os microproces-
sadores, e com isso a redução dos computadores (microcomputadores). Também
ocorreu o surgimento de linguagens novas de alto nível, bem como a transmissão de
dados entre computadores através de rede.
Após o lançamento dos primeiros computadores pessoais, começaram a surgir
programas com alto grau de interatividade com o usuário e a Internet. Tudo isso
impulsionou mais ainda a informática[12].
O surgimento dos primeiros sistemas operacionais com interfaces gráficas re-
volucionou a forma de interação entre o computador e o usuário. Com interfaces
gráficas baseadas em menus e janelas, o uso do computador se tornou intuitivo e
deixou de ser exclusividade de profissionais especializados. Não demoraria muito
tempo para que qualquer usuário pudesse adquirir um computador para processa-
mento de texto, edição de imagens, planilhas eletrônicas e diversas funcionalidades,
podendo acessar todas essas funções através de telas fáceis de serem entendidas por
humanos.
12
Fazer tais interfaces possuirem uma boa forma de interação com os usuários,
a fim de otimizar a eficiência e a eficácia do sistema e naturalmente obter um bom
índice de satisfação de quem o utiliza, ou seja, de maneira geral, uma boa usa-
bilidade, passou a ser um campo de estudo muito importante dentro da área de
Sistemas de Informação.
Avaliar a usabilidade é fundamental para identificar e corrigir problemas de
IHC antes do produto ser lançado e para permitir que a equipe desenvolvedora se
concentre na solução de problemas reais em vez de gastar tempo debatendo gostos
e preferências particulares de cada membro da equipe a respeito do produto. A
avaliação permite fazer um julgamento de valor sobre a qualidade de uso da solu-
ção de IHC e identificar problemas na interação e na interface que prejudiquem a
experiência particular do usuário durante o uso do sistema.
Métodos para avaliação de usabilidade estão presentes na literatura desde a
pesquisa de Nielsen em 1993[27], que apresenta uma série de heurísticas que devem
ser consideradas no desenvolvimento de um aplicativo. Até hoje, o trabalho de
Nielsen, é um dos mais citados em pesquisas relacionadas à avaliação de usabilidade
e novos métodos criados sempre o utilizam como base.
Na última década, iniciou-se uma nova revolução na área dos sistemas de
informação: com componentes eletrônicos cada vez menores e mais baratos, co-
meçaram a surgir os primeiros telefones celulares inteligentes. Inicialmente, estes
vinham com interfaces bastante limitadas e difíceis de usar e ofereciam aplicativos
simplificados. Essa situação começou a mudar a partir de 2007, com o lançamento
do primeiro “iPhone” pela Apple, introduzindo uma nova forma de interagir com
o dispositivo, a qual se tornou padrão nos dias de hoje: antes com teclados físicos
de plástico e telas pequenas, os smartphones agora recebem comandos pelo dedo
do usuário através de uma tela sensível ao toque que ocupa quase toda a sua su-
13
perfície frontal. Junto a isso, aplicativos tão sofisticados quanto aqueles usados em
desktops começaram a ser desenvolvidos para as plataformas móveis, que disponibi-
lizaram seus Kits de Desenvolvimento de Software (SDKs) e lançaram “Programas
de Desenvolvedor”, permitindo que qualquer pessoa ou empresa se cadastrasse para
desenvolver e publicar seus aplicativos em lojas virtuais, como a AppStore e a Google
Play.
Com o crescente uso de smartphones, tablets e demais dispositivos portá-
teis, sistemas de informação complexos estão ganhando espaço no dia-a-dia de uma
extensa base de usuários, mudando seus hábitos e oferecendo novas facilidades. Fun-
ções originais dos telefones celulares, como as chamadas de voz e o envio de men-
sagens SMS, estão rapidamente sendo substituídas por aplicativos de terceiros. Na
área da comunicação, por exemplo, estatísticas recentes mostram que Facebook Mes-
senger e Whatsapp juntos processam 60 bilhões de mensagens por dia, o que equivale
a três vezes a quantidade de mensagens SMS enviadas[14]. Já na área da saúde, 58%
dos usuários de smartphones já baixaram algum aplicativo para monitorar sua saúde
ou auxiliar na prática de atividades físicas segundo o site MobiHealthNews [28].
Com esse mercado se ampliando e tendo uma alta competitividade, desen-
volvedores de aplicativos têm o desafio de entregar produtos de maior qualidade
para competir [25]. Dentre os aspectos que fazem parte do contexto da qualidade
de aplicativos móveis, a usabilidade possui um grande destaque.
Para que um usuário substitua um processo manual por um digital usando
o celular, a qualidade da interação com o aplicativo a desempenhar essa função é
essencial. Por exemplo, trocar uma agenda de papel por um aplicativo de agenda
pode parecer vantajoso pelo usuário poder passar a ter os dados do usuário organi-
zados em um dispositivo que cabe no bolso. Porém, se o aplicativo não for fácil de
usar, não apresentar a informação de forma clara e não atender às expectativas, seu
14
trabalho não ficará mais eficiente nem prazeroso e, insatisfeito, o usuário irá preferir
voltar ao processo manual.
Os métodos existentes de avaliação de usabilidade em dispositivos móveis
ainda não estão tão consolidados quanto em sistemas para computador desktop.
Enquanto os sistemas tradicionais podem ser avaliados usando métodos que se apri-
moram desde o trabalho de Nielsen, os aplicativos móveis são uma tendência nova,
com novas características e que ainda não foram tão estudados.
Além disso, a usabilidade em sistemas operacionais e aplicativos móveis pos-
sui características específicas dos dispositivos em que são utilizados, como o tamanho
reduzido da tela e a interação por toque, dentre outros; que precisam ser consideradas
[26]. Alguns autores já propuseram métodos aprimorados para realizar a avaliação
de usabilidade em interfaces de dispositivos móveis, mas ainda não há uma referência
definitiva e muitos trabalhos ainda estão em andamento.
As diferenças no uso não ocorrem somente por conta da evolução da tecno-
logia computacional, mas também pelo ambiente. Aplicativos para desktops são
geralmente executados em um ambiente em que o usuário está sentado, usando o
computador em uma mesa, geralmente trabalhando ou navegando pela Internet, fo-
cado em sua tarefa e não no que está acontecendo ao seu redor. Já usuários de
dispositivos móveis podem estar na rua, no trânsito, aguardando em uma fila, vi-
ajando e muitas outras situações; ou seja, é bastante comum que distrações sejam
causadas pelo ambiente.
15
1.1 Proposta de Pesquisa
A pesquisa atual se propõe a verificar se as heurísticas de avaliação de usa-
bilidade mais recentes para dispositivos móveis são suficientes para cobrir o uso em
caso de situações-limite e, caso negativo, quais as novas heurísticas que devem ser
criadas para isso.
As 10 heurísticas de Nielsen [27] constituem a maior referência para avaliação
heurística de usabilidade presente na literatura. No Capítulo 2, são relacionados al-
guns trabalhos que já estudaram formas de adaptá-las para o contexto de aplicativos
móveis. Com isso, algumas heurísticas foram modificadas e novas foram criadas.
Essas novas heurísticas, entretanto, foram criadas a partir de inspeções feitas
especialistas e testes com usuários em laboratório. Em situações reais, com inter-
ferências causadas pelo ambiente, há estudos que mostram que o usuário tende a
cometer mais erros e levar mais tempo para completar tarefas. A literatura apre-
senta indícios de que, em situações-limite, como em uma emergência, as condições
psicológicas do usuário podem levar a uma experiência ainda mais diferenciada,
conforme descrito na Subseção 2.2.4.
Nesse trabalho, são identificados quais os problemas de usabilidade que po-
dem surgir em situações-limite e são estabelecidas novas heurísticas e aprimoramen-
tos em heurísticas existentes para cobrir esse tipo de situação.
Essa pesquisa teve como contribuição colaborar para a área de usabilidade de
aplicativos móveis, investigando como podemos avaliar interfaces em aplicativos para
dispositivos móveis de modo a garantir boa qualidade de uso em situações-limite. No
Capítulo 2, é apresentado o Referencial Teórico, descrevendo os conceitos envolvidos
e mostrando os trabalhos relacionados disponíveis na literatura. A Metodologia
16
adotada na pesquisa está descrita no Capítulo 3. No Capítulo 4, encontram-se os
resultados obtidos e uma discussão sobre os mesmos. Por fim, no Capítulo 5, são
apresentados a conclusão desta pesquisa, suas limitações e trabalhos futuros.
17
2 REFERENCIAL TEÓRICO
2.1 Usabilidade
O uso de sistemas interativos consiste na interação entre o usuário e sua
interface para alcançar objetivos dentro de um determinado contexto de uso. A
usabilidade é o critério de qualidade de uso mais conhecido e consequentemente, o
mais considerado. De acordo com [2], para muitas pessoas, usabilidade chega a ser
sinônimo de qualidade de uso.
A Literatura Científica apresenta diferentes definições para Usabilidade, onde
as mais comuns surgiram antes da popularização do uso de dispositivos móveis.
Sendo uma das definições mais usadas, o padrão ISO 9241-11 (1998) [17] define
usabilidade como “a capacidade de um produto ser usado por usuários específicos
para atingir objetivos específicos com eficácia, eficiência e satisfação em um contexto
específico de uso”. Nota-se que essa definição possui um alto nível de abstração,
podendo ser usada tanto dentro quanto fora do contexto de sistemas computacionais.
Para melhor compreensão desse enunciado, a norma ISO 9241-11 também
esclareceu outros conceitos:
• Usuário: pessoa que interage com o produto.
• Contexto de Uso: usuários, tarefas, equipamentos (hardware, software e
materiais), ambiente físico e social em que o produto é usado.
• Eficácia: precisão e completeza com que os usuários atingem objetivos espe-
18
cíficos, acessando a informação correta ou gerando os resultados esperados.
• Eficiência: precisão e completeza com que os usuários atingem seus objetivos,
em relação à quantidade de recursos gastos.
• Satisfação: conforto e aceitabilidade do produto, medidos por meio de méto-
dos subjetivos e/ou objetivos.
Em 2001, em uma ISO específica sobre Qualidade de Produto em Engenharia
de Software, a ISO/IEC [18] definiu a usabilidade em um contexto estritamente
computacional como a capacidade do software ser entendido, aprendido e usado de
forma que o usuário se sinta atraído pelo sistema. Embora essa definição seja mais
específica quanto ao contexto, ela não apresenta métricas viáveis de serem aferidas,
já que o termo “atração” não se refere a algo concreto e fácil de mensurar [21].
De acordo com Nielsen [27], a usabilidade está relacionada com a facilidade
de aprendizado e com o uso da interface, bem como a satisfação do usuário em
decorrência desse uso. O autor ainda cita os cinco fatores a seguir para qualificar a
interação do usuário com os sistemas interativos:
• Facilidade de aprendizado - o tempo e esforço necessários para que o usuá-
rio aprenda a utilizar o sistema com um determinado nível de competência e
desempenho;
• Facilidade de recordação - o esforço cognitivo do usuário necessário para
lembrar como interagir com a interface do sistema interativo, conforme apren-
dido anteriormente;
• Eficiência - o tempo que é necessário para conclusão de uma atividade com
apoio do sistema interativo;
19
• Segurança no uso - grau de projeção de um sistema contra condições desfa-
voráveis ou até mesmo perigosas para o usuário;
• Satisfação do usuário - fator relacionado com uma avaliação subjetiva que
expressa o efeito do sistema sobre as emoções e os sentimentos do usuário.
Em 2009, Schneiderman e Plaisant especificaram um conjunto de métricas
semelhantes que podem ser aferidas do ponto de vista prático para facilitar que
os objetivos de eficiência e satisfação no contexto de usabilidade de dispositivos
computacionais sejam atingidos:
• Tempo de aprendizagem - tempo necessário para que um usuário típico do
sistema aprenda as ações relevantes que devem ser executadas, a fim de que
sejam realizadas as principais atividades disponibilizadas pelo sistema.
• Desempenho (performance) - Tempo necessário para que o usuário execute
as tarefas principais do sistema.
• Taxa de erros cometidos pelo usuário - Contagem do número de erros
que os usuários cometem para executar cada tarefa fundamental do sistema e
respectiva listagem desses erros.
• Sedimentação do conhecimento por experiência - análise da facilidade
para que um usuário típico execute as funcionalidades principais do sistema
em uma hora, um dia ou uma semana depois de tê-las realizado pela primeira
vez. Esta métrica se relaciona diretamente com o tempo de aprendizagem.
• Satisfação subjetiva - analisa o quanto os usuários gostam de utilizar as
interfaces do sistema. Essa pergunta pode ser respondida pelos usuários por
meio de entrevistas ou questionários incluindo tanto questões na forma de
20
escalas de satisfação ou mesmo na forma aberta, em que os usuários se sentem
livres para responderem com as próprias palavras.
Atualmente é muito comum ao avaliar a qualidade de uso considerar as emo-
ções e os sentimentos do usuário ao interagir com o sistema, fator esse que se deno-
mina “experiência do usuário”, popularmente chamado de “UX (User Experience)”
[33].
2.2 Avaliação de usabilidade
A avaliação de usabilidade de uma interface é um processo indispensável para
produzir um sistema interativo de alta qualidade. É através dela que o avaliador
fará um julgamento de valor sobre a qualidade de uso e identificará problemas na
interação e na interface que prejudiquem a experiência particular do usuário durante
o uso do sistema [2].
É preciso buscar um entendimento de como os usuários podem vir a utilizar
o sistema e se vão apreciá-lo, principalmente quando ele for um sistema inovador
resultante principalmente da criatividade do designer [33].
As principais razões para avaliar a qualidade de uso de um sistema interativo
são definidas por Tognazzini [37] como as seguintes:
• os problemas de Interface Humano-Computador (IHC) podem ser corrigidos
antes e não depois de o produto ser lançado;
• a equipe de desenvolvimento pode se concentrar na solução de problemas reais,
em vez de gastar tempo debatendo gostos e preferências particulares de cada
21
membro da equipe a respeito do produto;
• os engenheiros sabem construir um sistema interativo, mas não sabem e não
estão em uma posição adequada para discutir sobre a qualidade de uso. Quem
será o advogado do usuário para defender seus interesses durante o processo
de desenvolvimento?;
• o tempo para colocar o produto no mercado diminui, pois os problemas de
IHC são corrigidos desde o início do processo de desenvolvimento, assim que
aparecem, exigindo menos tempo e esforço para serem corrigidos;
• identificar e corrigir os problemas de IHC permite entregar um produto mais
robusto, ou seja, a próxima versão corretiva não precisa já começar a ser
desenvolvida no momento do lançamento do produto no mercado.
Realizar avaliações de usabilidade não é apenas mais um custo de desenvolvi-
mento. Além de ser significativamente menos custoso que outras partes do processo
de desenvolvimento, traz benefícios siginificativos [3]. A curto prazo, avaliar a qua-
lidade de uso e corrigir os problemas identificados contribuem para aumentar a
produtividade dos usuários, diminuir o número e a gravidade dos erros cometidos
durante o uso, e aumentar a satisfação dos usuários. A médio e longo prazo, identifi-
car e corrigir os problemas de IHC contribuem para diminuir o custo de treinamento
e suporte, e para planejar versões futuras do sistema, pois chamam a atenção da
equipe para partes do sistema que podem melhorar, além de indicar outras que po-
dem ser mais exploradas. Um gerente de projeto não pode deixar de usufruir dos
benefícios da avaliação da qualidade de uso pelo simples desconhecimento do que
é, de quanto custa e de quais são seus benefícios. É possível equilibrar o custo da
avaliação de IHC com os benefícios obtidos.
Para obter esses benefícios, deve ser feito um planejamento cuidadoso, usando
um conjunto de métodos bem definida. Simplesmente entregar um protótipo ao
22
usuário e colher seu feedback espontâneo não é suficiente. Ao planejar uma avaliação
de IHC, o avaliador deve decidir o que, quando, onde e como avaliar, bem como os
dados a serem coletados e produzidos, além do tipo de método utilizado. [2].
A escolha de um método adequado é de fundamental importância para obter
resultados que realmente reflitam a realidade. De acordo com [15], uma avaliação
de usabilidade pode ser ineficaz e prejudicial se for feita apenas seguindo regras
sem realmente pensar no problema. Uma avaliação mal-feita no estágio inicial de
um desenvolvimento pode fazer com que ideias criativas sejam descartadas por não
estarem em conformidade com os padrões de interface. Se a avaliação for feita para
testar um produto que introduza uma inovação radical, os problemas de interface que
provavelmente serão notados pelo fato de ainda ser uma tecnologia imatura podem
anular o que seria uma visão inspirada. Se for feita para validar um protótipo
acadêmico, pode incorretamente sugerir um design com características que valem
para o meio científico, mas que não funcionam bem para um uso na prática dia-a-dia.
Se a avaliação for feita sem levar em conta como as culturas adotam a tecnologia ao
longo do tempo, então as reações relutantes de hoje por parte dos usuários evitarão
a aceitação ansiosa de amanhã. A escolha da metodologia precisa surgir a partir do
problema ou questão de pesquisa considerados.
Um dos métodos de avaliação são os Experimentos em Laboratório. Esse
método, um dos mais custosos por conta dos equipamentos necessários, estuda o
comportamento do usuário enquanto ele interage com o aplicativo dentro de um
ambiente bem definido. Por ter um ambiente controlado e dar tarefas pre-definidas
ao usuário, é possível que eles testem a maioria dos aspectos de usabilidade dese-
jados. O controle do ambiente também permite isolar o usuário de condições que
podem não ser relevantes para o experimento. Esse método é últil para fazer expe-
rimentos comparando diferentes designs e interfaces. Geralmente, os experimentos
são filmados e/ou a tela do dispositivo é gravada para que seja possível fazer uma
23
análise mais aprodundada posteriormente. A restrição desse método é que ao isolar
o usuário dos fatores do ambiente, pode haver diferenças em sua experiência e talvez
algo que afete a usabilidade no mundo real acabe não sendo detectado [39].
Outro método bastante comum é o Estudo de Campo, em que se colhe dados
sobre usuários, necessidades do usuário e requisitos do produto através de observa-
ções e entrevistas. Um investigador em campo observa os usuários enquanto eles
executam uma atividade, anotando e fazendo perguntas. O método é bastante útil
no início de um desenvolvimento pois permite levantar informações sobre os requi-
sitos do produto. A usabilidade de um aplicativo móvel pode ser medida em um
ambiente real [9].
Um outro método bastante usado é a Avaliação Heurística. Como este faz
parte do núcleo dessa pesquisa, a Seção 2.2.1 é dedicada a explicá-lo.
2.2.1 Avaliação Heurística
As avaliações por inspeção tentam antever as possíveis consequências de cer-
tas decisões de design. Esse tipo de método trata de experiências de uso potenciais e
não reais, já que não envolvem diretamente o usuário. Um dos métodos de avaliação
por inspeção mais utilizados é a Avaliação Heurística, que será bastante discutida
nessa pesquisa.
Esse método de avaliação é baseado em um conjunto de diretrizes que serão
verificadas no sistema interativo. Elas descrevem características desejáveis da in-
teração e da interface, chamadas de heurísticas [27]. Com isso, é possível orientar
os avaliadores a inspecionar a interface sistematicamente em busca de problemas
que prejudiquem a usabilidade. É uma alternativa mais rápida e de baixo custo em
24
comparação aos métodos empíricos.
Nielsen [27] descreve um conjunto inicial de heurísticas a serem usadas em seu
método de avaliação heurística. Essas heurísticas, relacionadas a seguir, resultam da
análise de mais de 240 problemas de usabilidade realizada ao longo de vários anos
por experientes especialistas em IHC.
1. Visibilidade do estado do sistema: o sistema deve sempre manter os usuá-
rios informados sobre o que está acontecendo através de feedback (resposta às
ações do usuário) adequado e no tempo certo;
2. Correspondência entre o sistema e o mundo real: o sistema deve utili-
zar palavras, expressões e conceitos que são familiares aos usuários, em vez de
utilizar termos orientados ao sistema ou jargão dos desenvolvedores. O desig-
ner deve seguir as convenções do mundo real, fazendo com que a informação
apareça em uma ordem natural e lógica, conforme esperado pelos usuários;
3. Controle e liberdade do usuário: os usuários frequentemente realizam
ações equivocadas no sistema e precisam de uma “saída de emergência” clara-
mente marcada para sair do estado indesejado sem ter de percorrer um diálogo
extenso. A interface deve permitir que o usuário desfaça e refaça suas ações;
4. Consistência e padronização: os usuários não devem ter de se perguntar se
palavras, situações ou ações diferentes significam a mesma coisa. O designer
deve seguir as convenções da plataforma ou do ambiente computacional;
5. Prevenção de erros: melhor do que uma boa mensagem de erro é um projeto
cuidadoso que evite que um problema ocorra, caso isso seja possível;
6. Reconhecimento em vez de memorização: o designer deve tornar os ob-
jetos, as ações e opções visíveis. O usuário não deve ter de se lembrar para que
25
serve um elemento de interface cujo símbolo não é reconhecido diretamente;
nem deve ter de se lembrar de informação de uma parte da aplicação quando
tiver passado para uma outra parte dela. As instruções de uso do sistema
devem estar visíveis ou facilmente acessíveis sempre que necessário;
7. Flexibilidade e eficiência de uso: aceleradores — imperceptíveis aos usuá-
rios novatos — podem tornar a interação do usuário mais rápida e eficiente,
permitindo que o sistema consiga servir igualmente bem os usuários experi-
entes e inexperientes. Exemplos de aceleradores são botões de comando em
barras de ferramentas ou teclas de atalho para acionar itens de menu ou bo-
tões de comando. Além disso, o designer pode oferecer mecanismos para os
usuários customizarem ações frequentes;
8. Projeto estético e minimalista: a interface não deve conter informação que
seja irrelevante ou raramente necessária. Cada unidade extra de informação
em uma interface reduz sua visibilidade relativa, pois compete com as demais
unidades de informação pela atenção do usuário;
9. Ajuda a usuários para eles reconhecerem, diagnosticarem e se recu-
perarem de erros: as mensagens de erro devem ser expressas em linguagem
simples (sem códigos indecifráveis), indicar precisamente o problema e sugerir
uma solução de forma construtiva;
10. Ajuda e documentação: embora seja melhor que um sistema possa ser
utilizado sem documentação, é necessário oferecer ajuda e documentação de
alta qualidade. Tais informações devem ser facilmente encontradas, focadas na
tarefa do usuário, dar os passos concretos a serem realizados e não ser muito
extensas.
Na lista a seguir, Nielsen descreve as atividades envolvidas em uma avaliação
heurística:
26
• Preparação
Todos os avaliadores:
- aprendem sobre a situação atual: usuários, domínio etc.
- selecionam as partes da interface que devem ser avaliadas
• Coleta de Dados e Interpretação
Cada avaliador, individualmente:
- inspeciona a interface para identificar violações das heurísticas
- lista os problemas encontrados pela inspeção, indicando local, gravidade,
justificativa e recomendações de solução.
• Consolidação dos Resultados e Relato dos Resultados
Todos os avaliadores:
- revisam os problemas encontrados, julgando sua relevância, gravidade, justi-
ficativa e recomendações de solução
- geram um relatório consolidado.
A seguinte escala de severidade também foi definida por Nielsen, com o ob-
jetivo de permitir uma melhor comparação dos julgamentos dos problemas encon-
trados:
1. Problema cosmético - não precisa ser consertado a menos que haja tempo
no cronograma do projeto;
2. Problema pequeno - o conserto deste problema pode receber baixa priori-
dade;
3. Problema grande - importante de ser consertado, devendo receber alta pri-
oridade. Esse tipo de problema prejudica fatores de usabilidade tidos como
importantes para o projeto (por exemplo, são exigidos muitos passos de inte-
ração para alcançar um objetivo que deveria ser atingido de forma eficiente);
27
4. Problema catastrófico - é extremamente importante consertá-lo antes de
se lançar o produto. Se mantido, o problema provavelmente impedirá que o
usuário realize suas tarefas e alcance seus objetivos.
Como as interfaces gráficas estão evoluindo e ficando cada vez mais sofistica-
das, as diretrizes de Nielsen são apenas um conjunto inicial, que pode ser expandido
para incluir diretrizes específicas de um determinado modelo de interação, como em
páginas Web, jogos, aplicativos móveis, realidade virtual e muitos outros.
2.2.2 Heurísticas mais atuais
A seguir serão descritas outras heurísticas encontradas na literatura recente
que fornecem uma abordagem mais atual para o desenvolvimento de interfaces.
Entretanto, essas heurísticas ainda se destinam a interfaces para sistemas de forma
geral, sem foco em dispositivos móveis.
A forma como a informação é organizada na tela é parte fundamental do
conjunto de fatores que afetará a usabilidade. É importante colocar os elementos de
interface em locais que sejam mais fáceis de serem encontrados pelo usuário e que
transmitam corretamente o significado que deseja passar. Schneiderman e Plaisant
[34] apresentaram em 2009 as seguintes recomendações para uma boa organização
da informação:
• Consistência dos dados sendo exibidos - a terminologia, abreviações,
formatos, cores e capitalizações de termos devem ser documentados na forma
de um dicionário de significados, para que todos os designers saibam como e
quando utilizá-los.
28
• Facilidade de assimilação da informação pelo usuário - a linguagem
deve ser familiar ao usuário, o formato de exibição de dados deve permitir que
os dados sejam facilmente assimilados. Estão inclusas nessa recomendação
espaçamento correto, alinhamento à esquerda de palavras, alinhamento de
casas decimais de números em ponto flutuante, dentre outros aspectos.
• Minimização da carga de memória do usuário - deve-se evitar que o
usuário tenha que se lembrar de informações entre interfaces diferentes da
aplicação. Cada atividade deve ser planejada de forma que o usuário a com-
plete em um pequeno número de passos. Em casos de grandes quantidades de
informações, deve-se separar a atividade em partes independentes, cada qual
contendo um conjunto pequeno de informações às quais o usuário deve prestar
atenção.
• Compatibilidade entre a entrada de dados e o conteúdo exibido - ele-
mentos de informação exibidos ao usuário devem associar-se de forma precisa e
sem ambiguidades com os componentes de entrada de dados. Eventualmente,
elementos de entrada de texto podem exibir informações ao usuário nos pró-
prios espaços de entrada.
• Flexibilidade do acesso e uso das informações - os usuários devem ser
capazes de assimilar as informações das interfaces de diferentes formas, para
que eles mesmos escolham o modo com que deverão realizar determinadas
atividades. Ordenações de linhas e colunas de tabelas são bons exemplos de
como tornar dados tabulares flexíveis ao usuário.
Os mesmos autores também definiram uma sequência de recomendações para
garantir uma boa navegabilidade na interface:
• Padronize a sequência de tarefas - funcionalidades semelhantes devem
29
ser executadas seguindo-se uma mesma sequência de atividades, de maneira
análoga.
• Assegure que os links da página sejam descritivos - quando um link é
criado, o texto descritivo associado a ele deve explicar com precisão a ação a
ser realizada caso ele seja ativado.
• Use cabeçalhos distintos para funcionalidades distintas - cabeçalhos
devem ser associados ao conteúdo sendo apresentado. Conteúdos diferentes
devem ter cabeçalhos diferentes.
• Use caixas de múltipla escolha (checkboxes) para escolhas que pos-
suam apenas duas possíveis respostas - escolhas referentes a perguntas
que permitem apenas duas respostas claras e distintas devem ser exibidas na
forma de checkboxes.
• Permita que o usuário imprima a página adequadamente - Desen-
volva as interfaces em medidas adequadas para a impressão, para que todos
os componentes da tela impressa apareçam corretamente no papel.
• Use imagens pequenas como forma de pré-visualizar as imagens no
tamanho original - em interfaces em que a visualização da imagem no tama-
nho original não seja necessária, providencie uma imagem menor ao usuário.
Ainda na mesma pesquisa, os autores definiram um conjunto de recomenda-
ções para serem usadas quando for preciso criar elementos para chamar a atenção
do usuário:
• Intensidade dos elementos - varie a intensidade de elementos na tela. En-
tretanto, é recomendável que apenas dois níveis de intensidade sejam usados
em uma mesma tela.
30
• Marcação - sublinhe elementos, coloque-nos bordas, aponte-os com setas ou
com indicadores que não fazem parte do texto, como asteriscos, numerais e
outros símbolos.
• Tamanho - use até quatro tamanhos diferentes em uma mesma tela. Eviden-
temente, os elementos de maior tamanho chamarão mais atenção.
• Escolha das fontes - use até três fontes diferentes para escrever mensagens.
• Efeito de vídeo inverso - inverta a cor do fundo com as do componente.
• Efeito pisca-pisca - use esse efeito em componentes pequenos e em locais
secundários da tela.
• Cores - Use até quatro cores diferentes, exceto quando o propósito da interface
depende do uso de um número maior de cores. Imagens coloridas não são
consideradas nessa contagem.
• Áudio - use sons sutis para indicar respostas positivas às ações do usuário e
sons mais chamativos para alertar sobre condições adversas.
Na seção a seguir, são mostrados os esforços para criação de métodos da
avaliação de usabilidade em dispositivos móveis.
2.2.3 Aplicativos móveis
O emergente e acelerado desenvolvimento das tecnologias usadas em dispo-
sitivos móveis tem estimulado novos estudos e pesquisas dedicados à usabilidade
[31][13]. Apesar disso, esses trabalhos ainda estão alguns passos atrás se compara-
dos à base de conhecimento relacionada à usabilidade em interfaces de computadores
31
pessoais, o que pode ser justificado tanto pelas peculiaridades da interação em dis-
positivos móveis, quanto pelo fato de que o mercado de dispositivos móveis só se
aqueceu após o de computadores pessoais já estar muito bem consolidado[21].
Avaliar a usabilidade em aplicativos para dispositivos móveis requer alguns
cuidados adicionais. Esta categoria de aplicativos possui novas características, tais
como o tamanho reduzido da tela, a tela sensível ao toque, o tamanho compacto que
permite manusear o dispositivo segurando com a mão enquanto faz outras tarefas
rotineiras, a conectividade sem fio, a capacidade de processamento mais limitada,
dentre muitos outros.
De acordo com Zhang e Adipat [39], problemas causados por restrições físi-
cas dos dispositivos móveis e redes sem fio implicam que, enquanto desenvolvendo e
conduzindo estudos de usabilidade em aplicativos móveis, esses problemas precisam
ser cuidadosamente examinados com o objetivo de escolher uma metodologia de pes-
quisa apropriada e minimizar o potencial efeito de fatores contextuais na usabilidade
percebida quando estes não são o foco do estudo.
Manter um alto padrão de usabilidade é um assunto de interesse das principais
empresas desenvolvedoras de sistemas operacionais para dispositivos móveis. Para
publicar em suas lojais virtuais de aplicativos, tanto a Apple, desenvolvedora do
iOS, quanto o Google, desenvolvedor do Android, estabelecem um conjuntos de
diretrizes que devem ser seguidas para a construção de interfaces em aplicativos que
funcionarão em suas plataformas[1][38]. Cada um desses fornecedores considera ao
elaborar suas diretrizes as peculiaridades de seu sistema, como tamanhos de tela,
posicionamento de botões, rótulos, caixas de texto e menus. Cada plataforma possui
diferentes formas de cobrar o uso dessas diretrizes: enquanto o Google apenas as
utiliza como recomendações, a Apple pode não aprovar um aplicativo para ir à sua
AppStore se o avaliador designado considerar que a interface pode induzir o usuário
32
a cometer erros ou ficar confuso. Nesse caso, a opinião subjetiva da pessoa que
recebeu a atribuição de avaliar pode ser decisiva.
Além do desafio de trabalhar com tecnologias em constante mudança, cada
método usado para avaliar a usabilidade nos dispositivos móveis atuais possui suas
vantagens e desvantagens. Alguns são difíceis de se aplicar e outros são dependentes
de opiniões subjetivas dos usuários ou do uso de instrumentos [26].
Em uma pesquisa conduzida para uma dissertação de mestrado, Neto [22]
mostrou que as heurísticas de Nielsen são deficientes em identificar problemas de
usabilidade de aplicações de dispositivos móveis. O autor fez um período de ex-
perimentação de um mês em 4 aplicativos para a plataforma Android e encontrou
vários problemas de usabilidade, sendo que alguns não se encaixavam em nenhuma
das heurísticas de Nielsen. Isso mostrou que novas heurísticas seriam necessárias e,
através de alguns ciclos de brainstormings com outros 5 especialistas e testes com
usuários, as validou e refinou. Como resultado, temos uma versão aprimorada das
heurísticas de Nielsen para dispositivos móveis, a qual está relacionada a seguir:
1. Bom aproveitamento do espaço da tela, de acordo com a orientação -
Independentemente da orientação do dispositivo, o design deve ser realizado de
forma que os itens não fiquem muito distantes, nem muito juntos. Elementos
relacionados devem estar próximos e os sem relacionamento devem estar mais
afastados. Interfaces não devem estar carregadas com muitos elementos.
2. Consistência e padrões da interface - A aplicação deve manter os compo-
nentes no mesmo lugar e na mesma configuração ao longo de toda a interação,
para facilitar a aprendizagem. Funcionalidades análogas devem possuir inte-
rações análogas, por meio de atividades parecidas. As características de cada
componente (seu tamanho, fonte, cor, etc.) devem permanecer os mesmos em
33
toda a aplicação.
3. Visibilidade e acesso fácil a toda informação existente - Todas as infor-
mações devem ser visíveis e legíveis, tanto em retrato quanto em paisagem. O
usuário não deve se esforçar para encontrar ou entender qualquer informação
sendo transmitida. Isso também vale para mídias, que devem de ser vistas
ou executadas na íntegra. Os elementos da interface devem possuir contraste
e elementos de um mesmo grupo de informações devem ter alinhamento ade-
quado.
4. Adequação entre o componente e sua funcionalidade - O usuário deve
saber exatamente o que ele deve colocar como entrada a um componente, sem
que haja ambiguidades ou dúvidas. Metáforas de funcionalidades devem ser
compreendidas sem dificuldades.
5. Adequação de mensagem à funcionalidade e ao usuário - A aplicação
deve falar a linguagem do usuário e as instruções para executar as funcionali-
dades devem ser claras e objetivas. A leitura deve ser natural e a linguagem
não deve ser invasiva no sentido de obrigar o usuário a fazer algo.
6. Prevenção de erros e retomada rápida ao último estado estável - O
sistema deve ser capaz de se antecipar a uma situação que leve a algum erro
por parte do usuário com base em alguma atividade já realizada pelo usuário.
Quando um erro ocorrer, a aplicação deve avisar o usuário prontamente e
retornar ao último estado estável. Em casos em que o retorno ao último estado
seja difícil, o sistema pode transferir o controle para o usuário, para que este
decida o que fazer (para onde ir).
7. Facilidade de entrada de dados - A forma com que o usuário fornece os
dados pode se basear em tecnologias assistivas, mas a aplicação deve sempre
mostrar com legibilidade o que está sendo digitado, para que o usuário te-
nha total controle da situação. O usuário deve conseguir fornecer os dados
34
requeridos de forma prática.
8. Facilidade de acesso às funcionalidades - As funcionalidades principais
da aplicação devem ser realizadas com maior facilidade possível, preferencial-
mente em apenas uma interação. Nenhuma funcionalidade deve ser difícil de
encontrar na interface da aplicação. Todos os componentes de entrada devem
ser assimilados com facilidade.
9. Feedback imediato e fácil de ser notado - O feedback deve ser fácil de
ser notado, para que não haja dúvidas de que a operação foi realizada ou está
em andamento. Atualizações locais na página devem ser priorizadas, para
evitar recarregamento e perda do ponto em que o usuário estava. Mensagens
que aparecem muitas vezes devem ter opção de serem ocultadas pelo usuário.
Barras de progresso demoradas devem permitir que o usuário continue exe-
cutando outras atividades. Feedbacks positivos devem ser visíveis, mas não
exigir interação redundante com o usuário, para não estressá-lo.
10. Aplicação deve ser autocontida - A aplicação deve conter todas as funci-
onalidades e informações embutidas nela, sem a necessidade de encaminhar o
usuário para programas externos.
11. Ajuda e documentação - O aplicativo deve possuir opção de Ajuda para
especificar os problemas comuns e as formas de solucioná-los. Os assuntos
considerados nessa opção devem ser fáceis de serem encontrados.
12. Minimização da carga de Memória do usuário - Aplicações devem per-
mitir que o usuário obtenha a informação de que precisa com facilidade, sem
exigir que o usuário memorize passos anteriores para completar uma atividade.
13. Personalização - A interface deve permitir opções de configurações pessoais
dos usuários, como aumentos do tamanho das letras, disposição de elementos
na tela, etc.
35
As heurísticas supracitadas obtiveram sucesso em detectar falhas de usabili-
dade e foram validadas com sucesso em experimentos feitos em laboratórios.
2.2.4 A importância do contexto na avaliação de usabilidade
O contexto tem um papel fundamental em uma avaliação de usabilidade. O
mesmo método de avaliação aplicado em contextos diferentes poderá gerar resultados
distintos. De acordo com Ryan, Pascoe e Morse [30], contexto envolve a localização
do usuário, o ambiente, identidade e tempo. Já para Hull, Neaves Bedford-Roberts
[16], contexto inclui todos os aspectos do ambiente da situação em questão. Schilit
Theimer [32] argumentam que os aspectos mais importantes do contexto são onde
você está, com quem você está e a quais recursos você possui acesso. Já uma
definição mais recente proposta por Dey e Aboud [9] atribui contexto aos estados
físicos, sociais, emocionais e informacionais do usuário.
Novas tecnologias e interfaces surgem a todo o momento. Em uma emergên-
cia, ter uma boa usabilidade é de suma importância, pois em uma situação com
potencial risco de vida, quanto mais intuitivos e claros forem os comandos de um
aparelho, mais eficiente será a utilização por parte do usuário. O trabalho de Ron-
calio, Miranda e Okimoto [29] apresenta os resultados de experimento piloto no qual
se verificou a viabilidade da simulação de um contexto de emergência para o teste
de usabilidade de um celular com tecnologia touch screen. As autoras usaram o
teste mais conhecido para indução de estresse em laboratório, o Trier Social Stress
Test - TSST, formulado para causar ansiedade e cujo protocolo já foi adaptado para
induzir estresse em outros estudos [19]. Os resultados mostraram que em uma situ-
ação de emergência onde um usuário precisa pegar um celular que não lhe pertence,
com uma interface que não é a que está acostumado a usar, ocorre uma dificuldade
já no primeiro passo, que é desbloquear o telefone. Pode-se inferir que o contexto
36
emergencial alterou o desempenho dos usuários, através do acréscimo de elementos
no ambiente, tais como ruído sonoro de sirene, presença de pesquisadores, marcador
de tempo e sugestão psicológica. Entretanto, como a mesma situação não foi testada
fora do contexto da emergência, não há dados para fazer uma comparação, como
as próprias autoras citam como limitações da pesquisa. Concluem sugerindo que
deveria haver diretrizes específicas de usabilidade em diversos contextos de uso, os
quais os produtos pudessem atender.
Outra forma de simular uma situação-limite encontrada na literatura é atra-
vés do uso de jogos de videogame. A pesquisa de Bouchard et al [5] testou diferentes
jogos 3D e tecnologias imersivas e chegou à conclusão de que jogos que combinam os
gêneros de terror e tiros em primeira pessoa podem ser indutores bastante úteis para
praticar técnicas de controle de estresse, com um menor custo e mais fácil aplicação
do que o TSST.
O trabalho de Bosse et al [4] explorou a indução de stress através de vídeos,
fazendo um experimento no qual participantes assistiam a 5 vídeos tendo os bati-
mentos cardíacos e a condutância da pele monitorados. Ao final de cada rodada,
o participante respondia a um questionário indicando o quão estressado ficou. Os
resultados mostraram que os batimentos cardíacos pouco variavam conforme o es-
tresse aumentava, enquanto a condutividade da pele se mostrou um bom indicador
para essa medida, aumentando significativamente conforme o usuário se estressava.
Outros trabalhos propuseram novas heurísticas para diferentes situações. O
trabalho de Carlo et al [8] criou um conjunto de heurísticas para aplicativos edu-
cacionais, incentivando o uso dos recursos multimídia do dispositivo para permitir
formas de aprendizado mais versáteis, além da disponibilização de conteúdo off-line,
da necessidade de clareza ao mostrar qual é o objetivo do ensino de um determinado
conteúdo e de respeitar certos conceitos de aprendizagem, como por exemplo, sina-
37
lizar com um “X” uma pergunta respondida errada. As heurísticas também devem
detectar se os aplicativos estão promovendo colaboração, cooperação e competitivi-
dade, além de motivarem o usuário com mensagens de reforço positivo. Por fim, o
conteúdo aprendido no aplicativo deve ter utilidade para que o usuário aplique esses
conhecimentos em uma situação real, seja ela uma prova ou em um dia de trabalho.
Essa pesquisa analisou os aplicativos “Nota10” e “Passei!ENEM” para chegar a tais
resultados.
A pesquisa de Feijó et al [10] avaliou a interface de aplicativos de conteúdo de
instituições de ensino superior do sul do Brasil, das categorias de utilidade, produti-
vidade e imersão. A partir da análise, baseada no estudo do Grupo de Qualidade de
Software do Instituto Nacional para Convergência Digital, na Universidade de Santa
Catarina, verificou-se se o conjunto de heurísticas de usabilidade proposto possui al-
guma limitação em relação a avaliação de diferentes categorias de aplicativos. Os
resultados mostraram que existem sim limitações, mas estas são pequenas e podem
ser sanadas se os avaliadores souberem adaptar melhor as ferramentas ao contexto
de avaliação.
Já o trabalho de Knoll [20] trata do desenvolvimento de novas heurísticas
específicas para tablets. O autor realizou uma revisão sistemática do estado da arte
em relação à usabilidade para tablets e desenvolveu um conjunto inicial de heurísti-
cas, com base em guias de estilos encontrados. Semelhanças foram verificadas entre
os guias de estilo e as heurísticas de Nielsen. Elaborou-se então um checklist que pu-
desse classificar a usabilidade dos aplicativos em relação à existência ou não destas
heurísticas. Como forma de validação do checklist, foram realizadas avaliações heu-
rísticas com três aplicativos (Gmail, Facebook e Dicionário da Língua Portuguesa),
comparando seus resultados com testes de usabilidade com os mesmos aplicativos.
38
3 PROCEDIMENTOS DESTA PESQUISA
Para que os objetivos desta pesquisa fossem logrados, foi conduzido um estudo
exploratório no qual a usabilidade foi avaliada em situações-limite. Um protocolo
de pesquisa foi definido para realizar um estudo exploratório em laboratório com
voluntários utilizando aplicativos selecionados em dispositivos móveis, com stress
induzido e tempo limitado para completar uma tarefa. A tela dos dispositivos usa-
dos foi gravada de modo que uma análise dos erros cometidos pudesse ser efetuada
posteriormente. Com os resultados dessa análise, foi possível fazer um mapeamento
de cada tipo de erro para uma das heurísticas existentes. Erros que não se en-
quadrassem em nenhuma dessas indicariam a necessidade de adaptar ou incluir uma
nova heurística no conjunto. Em uma sessão conjunta com especialistas em Interação
Humano-Computador, brainstormings foram realizados para sugerir tais adaptações
ou inclusões e assim foi elaborado um novo conjunto abrangindo o caso de situações-
limite. Por situação-limite, nessa pesquisa, compreende-se qualquer estado de alta
carga cognitiva ou emocional, tais como: medo, ansiedade ou angústia.
A visão geral dos procedimentos dessa pesquisa é descrita nos passos a seguir:
1. Seleção dos participantes
2. Preparação do ambiente laboratorial
3. Seleção de meios de controle do contexto estudado
4. Planejamento de dados a serem coletados
5. Plano de Análise Inicial
39
A seleção de participantes foi feita por meio do recrutamento de volun-
tários. Há 2 requisitos para seleção de participantes voluntários: (1) o participante
já deve possuir e usar smartphone há pelo menos 6 meses; (2) o participante deve
alegar aptidão física e emocional para a participação no estudo; Em especial, seriam
excluídos os voluntários que relatarem alguma cardiopatia ou risco de convulsões ou
crises induzidas por situações de estresse, o que não ocorreu.
A preparação do ambiente laboratorial consistiu na equipagem de uma
sala com projeção de vídeos (filmes), sons, iluminação apropriada e qualquer outra
característica técnica que seja considerada útil para induzir estados mentais/emoci-
onais nos participantes. O objetivo é criar um ambiente de imersão para a realiza-
ção do estudo. Apesar das possibilidades de imersão das tecnologias de Realidade
Virtual, nesse estudo exclui-se o uso de realidade virtual porque é preciso que o
participante tenha acesso “hands-on” ao smartphone durante o período de imersão.
A seleção dos meios de controle foi direcionada para combinar dados
biométricos (quantitativos) com a percepção de estresse do indivíduo (dados qua-
litativos). A percepcão do indivíduo foi medida na forma de escalas ordinais de
estresse (ansiedade, medo, etc.), com valores auto-atribuídos pelo participante. O
procedimento de auto-atribuição consiste em apresentar ao participante o vídeo de
sua participação e pedir uma avaliação (escalas e comentários) de cada trecho do
estudo.
Com relação aos dados biométricos, foi medida a atividade eletrodérmica do
participante durante a participação no estudo empírico. A atividade eletrodérmica
é um dos melhores indicadores biométricos do nível de estresse do participante [6].
A condutividade elétrica da pele é mais alta em situações de ansiedade, medo,
angústia, entre outros estados mentais/emocionais que normalmente ocorrem em
"situações-limite". Será usado o sensor Mindfield eSense Skin Response, um modelo
40
comercial de sensor de resposta eletrodérmica (comumente chamado de Galvanic
Skin Response - GSR) projetado para ser acoplado a um smartphone com sistema
operacional iOS ou Android. O sensor é vendido juntamente com o aplicativo que
coleta os dados e apresenta a série temporal desses dados ilustrados em gráficos de
linha.
Figura 3.1: Mindfield eSense Skin Response - Sensor GSR
Os dados a serem coletados para essa pesquisa são:
1. Dados biométricos para investigação do estado de estresse ou relaxamento do
indivíduo: esses dados são necessários para triangulação com a auto-avaliação
qualitativa feita pelo participante. O objetivo é identificar se os meios de
indução de estresse
2. Auto-avaliação pelo participante do seu nível de estresse (conforme instruções
em [7])
3. Questionário para detalhar dados do perfil do participante e sua familiaridade
com o sistema operacional do dispositivo móvel usado
41
4. Vídeo da tela do smartphone (usado para a avaliação por heurísticas)
5. Vídeo do rosto do participante (para auxiliar a compreensão das reações do
participante)
Os dados referentes à usabilidade serão coletados através de gravações em
vídeo da tela do smartphone usado no estudo, na qual serão verificados os erros que
o participante cometeu até completar a tarefa proposta (método de inspeção por
heurísticas), além de um questionário no qual o próprio participante poderá indicar
onde sentiu mais dificuldade.
O objetivo desta pesquisa é realizar uma exploração dos aplicativos de comu-
nicação e referência mais populares em situações-limite e investigar se as heurísticas
existentes estão adequadas para detectar os problemas de usabilidade que surgirão
a partir do uso. Dessa maneira, embora uma saída esperada dessa pesquisa seja um
conjunto de heurísticas especificas para dispositivos móveis e limitada ao contexto de
situações-limite, a pesquisa será focalizada em explorar e compreender esse contexto
particular.
O Plano de Análise Inicial inclui a inspeção das interfaces a partir dos ví-
deos de uso do dispositivo móvel. Nessa inspeção, especialistas em avaliação de inter-
faces serão convidados a examinar os vídeos de uso e identificar situações-problema.
Essas avaliações serão depois consolidadas pelo pesquisador e cada problema iden-
tificado será caracterizado e identificado com exemplos obtidos do vídeo do estudo
empírico. Em seguida, os problemas identificados serão agrupados e etiquetados
com o nome de uma nova heurística, se for o caso.
42
3.1 Estudo Piloto
Um estudo piloto foi conduzido para avaliar a adequação desse framework
para induzir e mensurar se o participante está em um estado mental ou cognitivo
sobrecarregado. Esse estado pode ser induzido através de estímulos que provoquem
ansiedade ou stress.
Embora existam muitas formas de fazer a indução presentes na literatura,
é fundamental para o nosso estudo a utilização de um método que permita fazer
a indução e mensurar os resultados dentro de um ambiente controlado de labora-
tório e sem necessidade de muitos recursos. O conhecido Trier Social Stress Test
foi descartado pois requer a participação de “atores” para atuar como uma banca
examinadora. Foi decidido então pelo uso de jogos de videogame/computador, que
também é citado recorrentemente na literatura como forma de provocar tais estímu-
los.
Afim de verificar a viabilidade de medir o nível de stress do usuário, foi
conduzido um estudo piloto no qual participantes voluntários deveriam jogar um
jogo de computador pré-definido, com características que podem induzir o stress.
Durante essa tarefa, o sensor GSR foi usado para medir a condutância da pele,
modulando a quantidade de secreção de suor.
Para esse estudo piloto, foi usado o jogo Keep Talking and Nobody Explodes
para induzir stress, o qual foi selecionado por requerer bastante atenção do jogador
e tempo limitado. O funcionamento do jogo sucede da seguinte forma:
• Um participante deve ficar em um computador, onde é exibida a tela do jogo,
na qual há em um ambiente tridimensional uma bomba a ser desarmada. O
43
jogador deve manipular a bomba usando o mouse e receber as instruções para
desarme do segundo participante.
• O segundo participante não pode ver a tela do computador e tem em suas mãos
o manual de desarmamento da bomba. Esse manual não pode ser mostrado
ao participante que está no computador.
• Os dois participantes devem se comunicar pela fala, explicando um ao outro
quais são as características da bomba, que, a cada partida, possui módulos
diferentes, e quais as instruções para desarmar cada um desses módulo.
• O jogo possui um limite de tempo para finalizar a tarefa. Conforme o tempo
se aproxima do final, mais estímulos sonoros e visuais (como luzes vermelhas
e sons de sirene) são emitidos, aumentando a tensão do ambiente.
Um exemplo de tela do jogo e do manual de instruções pode ser verificado
na Figura 3.2.
Figura 3.2: Tela do jogo (à esquerda) e manual de instruções (à direita)
Para realizar esse estudo piloto, foram utilizados:
• Um computador ligado a um monitor externo, onde exibia-se a tela do jogo.
A tela desse monitor era gravada para posterior conferência. A webcam do
44
computador gravava o usuário, a fim de verificar se haveria mudanças em seu
semblante decorrentes do stress ou ansiedade.
• Um sensor GSR da marca "e-Sense by Mindfield", ligado a um iPhone 7 Plus,
de onde obtém-se a leitura da condutância da pele do usuário. Os arquivos com
as leituras são exportados para formato Excel. A tela do iPhone mostrando a
leitura também foi gravada a fim de ter uma representação visual dessa leitura
para uso posterior.
• O manual impresso do jogo, traduzido para Português e disponibilizado pelo
site http://jogabilida.de/bomb/.
Para a realização desse estudo piloto, o sensor GSR foi colocado nos dedos
indicador e médio do participante e aguardou-se um tempo até a leitura se estabi-
lizar. O leitor somente foi removido após o encerramento das gravações das telas e
da câmera.
3.2 Estudo Exploratório
Para a avaliação de usabilidade em situações-limite, que consiste no estudo
exploratório principal dessa pesquisa, foram escolhidos aplicativos de uso cotidiano
que podem ser úteis em situações limite, incluindo aplicativos das categorias de
comunicação, redes sociais, geolocalização e referência. Dentro dessas categorias,
foram selecionados aplicativos dentre os mais baixados segundo os rankings das
lojas Apple Store e Google Play.
Os aplicativos selecionados são descritos a seguir:
• WhatsApp - aplicativo para trocas de mensagens que utiliza a Internet
45
(4G/3G/2G/EDGE ou Wi-Fi, conforme disponível) para enviar mensagens
de texto, áudios, imagens, videos e fazer chamadas gratuitamente para os con-
tatos que também possuem o aplicativo instalado. Em uma situação-limite,
é um dos possiveis aplicativos que o usuário tentaria usar para se comunicar
devido à sua grande popularidade.
• Facebook Messenger - O Facebook Messenger é o aplicativo de mensagens
oficial do Facebook, que permite ter conversas de texto com os contatos da
popular rede social. Assim como outros aplicativos de mensagens instantâ-
neas, o Facebook Messenger permite compartilhar imagens e a geolocalização
do usuário nas mensagens de texto; também é possível adicionar vários des-
tinatários e abrir janelas de chat com várias pessoas ao mesmo tempo. Em
uma situação-limite, é uma alternativa ao WhatsApp para comunicação, per-
mitindo entrar em contato com pessoas ou páginas sem a necessidade de ter
seus números de telefone previamente cadastrado.
• Google Maps - serviço de pesquisa e visualização de mapas e imagens de
satélite da Terra gratuito na web fornecido e desenvolvido pela empresa es-
tadunidense Google. Atualmente, o serviço disponibiliza mapas e rotas para
qualquer ponto nos Estados Unidos, Canadá, União Europeia, Austrália e Bra-
sil, entre outros. Disponibiliza também imagens de satélite do mundo todo,
com possibilidade de um zoom nas grandes cidades, como Nova Iorque, Paris,
São Paulo, Rio de Janeiro, Brasília, entre outras. Em uma situação-limite,
pode ajudar o usuário a se localizar ou traçar uma rota para um destino.
• Google Tradutor - serviço virtual gratuito do Google para tradução instan-
tânea de textos e websites. A aplicação suporta mais de 100 idiomas e pode
traduzir 37 idiomas através de imagens, 32 através de voz em modo de conver-
sação e 27 através de vídeo em tempo real no modo de realidade aumentada.
Pode ser usada em situações-limite na qual o usuário esteja em viagem ao
exterior e precise pedir orientações em um idioma que não domina.
46
Para cada um desses aplicativos, foram propostas tarefas que poderiam ser
requisitadas em um cenário real durante uma situação-limite. Essas tarefas foram
escritas seguindo as seguintes regras, propostas por Meyer [23]:
• Analisar o que os usuários podem realizar com seu produto para ter inspirações
para as tarefas, lembrando que essas devem ser as mais realistas possíveis, sem
forçar algo que os participantes jamais precisariam fazer na vida real.
• Evitar que dicas sejam dadas acidentalmente ao usuário ao descrever passos
muito detalhadamente.
• Tentar manter as tarefas emocionalmente neutras. Não se deve fazer supo-
sições sobre a vida pessoal do usuário ou seus relacionamentos ao escrever a
tarefa.
• Fazer um teste piloto de cada tarefa com um ou dois usuários para garantir
que ela é viável de ser realizada e ocorrerá como o esperado.
• Por ser um teste qualitativo, as tarefas podem ser abertas à interpretação dos
participantes, sendo possível posteriormente analisar o que eles consideraram
mais importante e quais fatores os levaram a tomar certas decisões.
• Ser objetivo e não exagerar nos detalhes ao descrever a tarefa, dando apenas
as informações necessárias para que um participante entenda o contexto, sem
ter que “escrever uma novela” para isso.
• Se não surgirem os insights esperados, as tarefas podem ser trocadas ou adap-
tadas, afim de obter melhores resultados e evitar perda de tempo.
A Tabela 3.1 descreve o conjunto final de tarefas propostas.
47
Exemplo de mensa-
gem
Aplicativo por
onde será en-
viado
Objetivo
Oi, onde você está?
(responda com áudio
ou texto)
WhatsApp Avaliar o principal recurso do What-
sApp (envio de mensagens) usando os
principais métodos de entrada ofereci-
dos pelo aplicativo (áudio e texto)
Envie uma foto via
Messenger para a
página “Experimento
Mestrado Vinícius”
mostrando o que está
fazendo.
Facebook Mes-
senger
Avaliar algumas das principais funcio-
nalidades do app, incluindo a busca por
contato, a tela para o envio de mensa-
gens e a interface com a câmera do ce-
lular.
Rápido! Preciso do
endereço do Hospital
Quinta D’Or
WhatApp Avaliar a alternância entre aplicati-
vos (WhatsApp para o Google Maps
ou Apple Maps), a localização de um
ponto de interesse no mapa e possivel-
mente o menu de contexto do sistema
operacional do celular (para copiar e
colar o endereço)
Poderia me passar o
contato de Vinícius?
App nativo de
SMS
Avaliar o aplicativo nativo de telefone/-
contatos para localizar um contato e a
transferência dessa informação para o
app de mensagens SMS, incluindo não
só a entrada de texto como a possibili-
dade copiar e colar.
48
Estou perdido em
Budapeste! Como
digo “Onde estou?“
em Húngaro???
WhatsApp Avaliar o uso de aplicativos de tradu-
ção e seus diferentes meios de entrada
(voz e texto) e a transferência do re-
sultado para o aplicativo de mensagens
Tabela 3.1: Tarefas Propostas
Os participantes tiveram o sensor GSR colocado em seus dedos e foram ins-
truídos a iniciar uma partida do jogo selecionado. A partir do momento em que a
leitura do sensor começava a indicar uma alteração no nível de estresse, as tarefas
do estudo exploratório começavam a ser enviadas para o celular do participante.
Se o participante perdesse ou ganhasse a partida do jogo antes de serem rea-
lizadas todas as tarefas propostas para o estudo, eram orientados a iniciar uma nova
partida. Alguns participantes não puderam realizar todas as tarefas pois tinham um
tempo limitado disponível.
Cada participante contou com um auxiliar para ler o manual do jogo, seguindo
as mesmas regras que foram descritas na Seção 3.1.
Para realizar esse estudo exploratório, foram utilizados os seguintes artefatos:
• Computador para execução do jogo “Keep Talking and Nobody Explodes”;
• Celular iPhone X para comunicação com o sensor GSR;
49
• Celular iPhone 7 Plus para interação com o participante em parte das rodadas
do estudo. A tela deste dispositivo foi gravada e o participante deverá realizar
as tarefas propostas, recebidas por mensagem;
• Celular Motorola Moto G5 com Android para interação com o participante
em parte das rodadas do estudo. A tela deste dispositivo foi gravada e o
participante teve que realizar as tarefas propostas, recebidas por mensagem;
• Celular iPhone 6s para envio de mensagens com as tarefas para o celular usado
pelo participante. As mensagens foram padronizadas e salvas com atalhos para
serem rapidamente enviadas em todas as rodadas do estudo.
• Sensor eSense Skin Response GSR para leitura da condutividade da pele do
participante, a fim de verificar se houve uma sobrecarga cognitiva ou emocio-
nal.
• Câmera GoPro Hero 3+ para filmar a interação do participante com o celular;
• Lâmpada Philips HUE para mudar de cor e piscar, potencializando a indução
de stress.
• Manual impresso do jogo “Keep Talking and Nobody Explodes”.
O ambiente laboratorial com esses equipamentos foi então preparado con-
forme o esquema da Figura 3.3.
50
Figura 3.3: Esquema do ambiente laboratorial para realização do estudo exploratório
51
Além dessa configuração, o ambiente também estava iluminado por lâmpadas
Philips HUE, programadas para começar a piscar constantemente na cor vermelha
quando o tempo do jogo chegasse próximo ao fim. Os sons e a música do jogo
também foram ajustados em alto volume para contribuir na sensação de imersão.
3
52
4 RESULTADOS OBTIDOS
Neste capítulo são mostrados os resultados obtidos ao longo da execução das
atividades expostas nos Procedimentos desta Pesquisa (capítulo 3).
4.1 Resultados do Estudo Piloto
Com a realização do estudo piloto, notou-se que ocorrem grandes variações
de valor quando o usuário passa por um momento de maior nervosismo, como por
exemplo, quando erra uma instrução e a bomba fica mais próxima de explodir; ou
quando soa um alarme inesperado. Tendo os vídeos gravados e o gráfico da leitura
sincronizados após um processamento com um editor de video, foi solicitado a cada
participante que indicasse o que ele sentiu nos momentos em que ocorrem os maiores
picos de variação e em todos os casos o paciente confirmou que algum fator o deixou
estressado, nervoso ou ansioso em tais momentos. A gravação do rosto do parti-
cipante não mostra nenhuma mudança facilmente identificável na expressão facial
em momentos de stress, visto que este fica bastante concentrado em completar a
tarefa, de modo que a imagem do rosto da pessoa isoladamente não seria suficiente
para indicar a sobrecarga cognitiva ou emocional. Também deve-se destacar que os
participantes que disseram já ter jogado o jogo antes ou que não costumam ficar ten-
sos com jogos tiveram como resultado uma leitura muito mais estável, sem grandes
picos de variações. A Figura 4.1 mostra um quadro do vídeo após a sincronização e
processamento, com o valor lido pelo sensor à esquerda, a tela do jogo no centro ao
fundo e a webcam com o rosto do participante à direita.
A Figura 4.2 mostra exemplos da leitura obtida pelo sensor GSR. Como cada
53
Figura 4.1: Vídeo de uma rodada do estudo piloto após sincronização do jogo,câmera e leitura do sensor
participante tem um valor diferente para sua condutância da pele em estado normal,
tais valores, obtidos na unidade de microsiemens, foram normalizados para números
entre zero (menor stress) e um (maior stress). O primeiro e o segundo gráfico
correspondem a jogadores que nunca tinham tido contato com o jogo em questão e
que tiveram picos de ansiedade em momentos que, segundo os próprios, sentiam que
iriam perder ou eram surpreendidos por um barulho inesperado. O terceiro gráfico
se refere a um participante que já conhecia o jogo e apenas relatou que foi ficando
mais nervoso com a escassez de tempo.
54
Figura 4.2: Três exemplos de leituras do sensor GSR: os dois primeiros, com mai-ores picos de variações correspondem a participantes que relataram maior stress,enquanto o terceiro, com variações menores, mostra um participante que relatoupouco stress
55
Após esse estudo piloto, foi validado que é possível induzir stress através
do jogo selecionado e confirmar através do sensor se o participante está com uma
sobrecarga emocional e/ou cognitiva.
4.2 Resultados do Estudo Exploratório
Após os resultados do estudo piloto descrito na seção anterior, obteve-se
indícios de que é possível usar este método para simular uma situação-limite e a
partir disso avaliar a usabilidade de aplicativos nessas situações.
Foram realizadas 20 rodadas do estudo exploratório, onde 13 participantes
usaram a plataforma iOS e 7 usaram Android. No total, foram identificados 42
incidentes nos quais o participante encontrou dificuldades ou cometeu erros.
A Figura 4.3 mostra um participante realizando as tarefas, em gravação de vi-
deo feita pela câmera GoPro, enquanto a Figura 4.4 mostra momentos das gravações
da tela do celular durante o estudo.
56
Figura 4.3: Um participante realiza as tarefas do estudo exploratório, com a suaimagem capturada via GoPro
57
Figura 4.4: Exemplos de gravações das telas do celular durante o estudo exploratório
Após analisar os questionários preenchidos, gravações das telas e das mãos
dos participantes, além de conversas informais sobre o que acharam, foi montada a
tabela a seguir, descrevendo os problemas de usabilidade encontrados.
No do Problema Descrição do Problema
1 Tentou usar o assistente de voz do sistema operacional
(Siri) para buscar o endereço de um hospital, mas esta
só entendeu o que ele estava dizendo na terceira vez,
quando este disse “Me leve ao Hospital Quinta D’Or”.
2 Depois, foi levado pela Siri ao aplicativo de mapas Ap-
ple Maps e o trajeto foi traçado, mas o endereço em si
não foi exibido na tela e o participante teve dificuldades
em localizar. Fotos do hospital são mostradas antes do
endereço, sendo necessário rolar para achar o endereço
e não ficou claro que havia rolagem.
58
Continuação da Tabela 4.1
No do Problema Descrição do Problema
3 O participante não sabia em que aplicativo procurar um
contato para compartilhar. Após rolar a tela inicial di-
versas vezes procurando o ícone do telefone entre os apli-
cativos, percebeu que este estava afixado no Dock do
iOS, embaixo da tela.
4 O participante abriu o Google Maps para procurar o en-
dereço. Embora este apareça simplificado (apenas a rua)
e em cor de menor destaque abaixo do nome do ponto de
interesse na busca, o participante não viu e seguiu bus-
cando. Na tela seguinte, só encontrou opção de Iniciar
uma rota ou alternar o tipo de rota, além da classificação
atribuída pelos usuários ao local. O participante tentou
clicar em vários lugares da tela até descobrir que des-
lizando a barra contendo essas opções para cima, mais
informações são exibidas incluindo o endereço. O parti-
cipante encontrou o endereço mas não sabia como com-
partilhar para o WhatsApp e acabou memorizando e
depois digitando manualmente para o solicitante.
5 O participante perdeu tempo dispensando caixas de diá-
logo confirmando se desejava permitir acesso à câmera
6 A participante ficou inconformada por não encontrar
uma opção rápida de enviar o contato do aplicativo Te-
lefone para o aplicativo do WhatsApp.
59
Continuação da Tabela 4.1
No do Problema Descrição do Problema
7 A participante não conhecia o aplicativo do Google Tra-
dutor e ao entrar nele e tentar fazer a tradução solici-
tada, usando voz como método de entrada, não conse-
guiu mudar o idioma para aquele que foi solicitado.
8 A participante tentou fazer a busca por voz no site do
Google pelo navegador, mas a versão mobile do site não
oferece essa opção
9 A participante abriu o aplicativo do Google Pesquisa e
conseguiu fazer sua busca por voz, dizendo apenas “Es-
tou perdida em Húngaro”, que teve como retorno a res-
posta desejada. Ao tentar copiar e colar, teve dificulda-
des em entender como funcionava o acionamento dessas
funções.
60
Continuação da Tabela 4.1
No do Problema Descrição do Problema
10 A participante não conhecia a Interface do Facebook
Messenger e ficou perdida quando foi solicitado que en-
viasse a foto à uma página. Não sabia onde procurar
por página, fechou o Facebook Messenger e abriu o Fa-
cebook normal e, após ser instruída a usar o Messenger,
ficou muito tempo analisando a tela e fazendo várias
tentativas até descobrir como podia encontrar uma pá-
gina. Ela chegou a começar a pesquisar corretamente
algumas vezes, mas ao ver resultados muitos distantes
da página desejada, desistia de prosseguir com a pes-
quisa, que daria certo se terminasse de digitar o termo
de busca completa.
11 A participante clicou em alguns botões errados até clicar
no botão correto da câmera.
12 A participante teve dificuldades de encontrar onde es-
tava o endereço no Google Maps até descobrir que tinha
que deslizar o menu inferior para cima.
13 A participante não conseguiu entender onde deveria pro-
curar uma página na interface do aplicativo do Face-
book.
61
Continuação da Tabela 4.1
No do Problema Descrição do Problema
14 Participante clicou e segurou sobre o endereço no Google
Maps esperando um menu de contexto para acionar um
botão de copiar, mas o Google Tradutor copiou direto e
o aviso que a cópia foi feita não foi percebido pelo par-
ticipante, que ficou repetindo a ação sem entender que
já havia copiado. O aviso de que a tradução foi copiada
aparece no rodapé da tela, enquanto o local pressionado
para copiar fica na metade de cima da tela.
15 O participante não encontrou onde entrar em contato
com uma página pelo Facebook Messenger e desistiu
dessa tarefa.
16 Quando o participante estava com o Facebook Messen-
ger aberto, novas mensagens chegaram mas ele não per-
cebeu, pois estava concentrado em outra tarefa e o apli-
cativo não emite som de notificação quando está nesse
estado.
17 O participante informou que os ícones usados na inter-
face do aplicativo do Facebook o deixaram confusos por
não serem padronizados em relação aos outros sistemas
operacionais que estava acostumado.
62
Continuação da Tabela 4.1
No do Problema Descrição do Problema
18 Tentou procurar o endereço no Safari ao invés do Goo-
gle Maps, onde teve dificuldade para copiar. Ela tentou
pressionar o local onde estava o endereço no site encon-
trado, mas ao pressionar um link com força no iPhone,
é aberto um preview do link e não o menu de contexto
e ela reclamou da confusão entre os gestos. Acabou,
no final das contas, copiando o link para a página que
continha o endereço, e não o endereço em si.
19 Teve dificuldades para compartilhar o contato pelo apli-
cativo de mensagens. Como não há um botão para isso
perto da área de digitação, o participante tentou abrir a
câmera, a loja do iMessage e as fotos do celular através
dos botões da parte de baixo da tela até perceber que
o contato deve ser procurado no aplicativo de Contatos.
Sugeriu que tivesse uma opção de compartilhar contato
dentro do aplicativo de mensagens.
20 O participante viu que o endereço do hospital aparecia
na lista de itens encontrados na busca, tentou copiar,
mas nesta tela não é possível. Ao clicar no item para
abri-lo, a tela que é aberta não mostra o endereço ini-
cialmente e o usuário demorou para entender que mais
opções estão disponíveis ao rolar a barra inferior.
63
Continuação da Tabela 4.1
No do Problema Descrição do Problema
21 Tentou procurar o endereço no Safari ao invés do Goo-
gle Maps, onde teve dificuldade para copiar. Ela tentou
pressionar o local onde estava o endereço no site encon-
trado, mas ao pressionar um link com força no iPhone,
é aberto um preview do link e não o menu de contexto
e ela reclamou da confusão entre os gestos. Acabou,
no final das contas, copiando o link para a página que
continha o endereço, e não o endereço em si.
22 A participante desistiu de compartilhar o contato pelo
aplicativo de mensagens nativo, pois não encontrou ne-
nhuma forma de acessar esse recurso pela tela em que
estava.
23 O participante não conseguiu enviar o áudio pelo What-
sApp de primeira. Segundo informou, o botão que deve
ser pressionado para acionar o microfone é muito pe-
queno e acidentalmente o soltou antes de terminar de
gravar.
24 O participante procurou o endereço no Safari, onde
achou um link para abrir no Google Maps e então foi en-
caminhado para este aplicativo. No Google Maps, não
encontrou nenhuma opção de copiar ou compartilhar o
endereço e acabou achando mais fácil memorizar e então
gravar um áudio dando a resposta solicitada.
64
Continuação da Tabela 4.1
No do Problema Descrição do Problema
25 A participante logo descobriu que a barra inferior do
Google Maps deslizava para cima, mostrando o ende-
reço, mas demorou para encontrar a opção de copiar, já
que, segundo a mesma, não havia uma indicação clara
de como fazer isso.
26 Após procurar bastante uma forma de compartilhar o
endereço pelo Google Maps, a participante desistiu, ti-
rou um screenshot da tela e enviou o screenshot como
resposta.
27 O participante confundiu o app do Facebook Messenger
com o app completo do Facebook e com isso fez um per-
curso diferente. Ao pesquisar pela página na busca, o
resultado apareceu mas ele não sabia inicialmente como
mandar mensagem, já que era necessário abrir os deta-
lhes da página primeiro.
28 No app do Google Tradutor, teve dificuldades em encon-
trar o idioma solicitado no meio da lista, achando que
essa seleção não estava prática.
29 O participante abriu o Google Maps, pesquisou o hos-
pital e sem querer clicou para traçar rota. Clicou então
no endereço da localidade atual, pensando ser o ende-
reço do hospital, e o transcreveu manualmente para o
WhatsApp, não só levando muito tempo, mas dando a
resposta totalmente errada.
65
Continuação da Tabela 4.1
No do Problema Descrição do Problema
30 O participante fechou o Messenger e tentou procurar a
página no Facebook normal. Encontrou, mas não soube
como mandar mensagem e desistiu.
31 O participante traçou a rota do endereço atual para o
hospital. Deu vários cliques na tela procurando o ende-
reço, mas não encontrou onde ficava e então achou mais
prático tirar um screenshot do mapa na tela e enviar
essa imagem via WhatsApp.
32 O participante teve dificuldades em manter o botão de
gravar áudio do WhatsApp pressionado pois, segundo
ele, é muito pequeno para o seu dedo.
33 O participante não encontrou onde ficava o endereço na
página do ponto de interesse e acabou olhando manual-
mente no mapa exibido.
34 O participante demorou para encontrar o idioma solici-
tado na lista de idiomas do Google Tradutor.
35 A participante abriu o Google Maps, procurou e encon-
trou o hospital, mas não viu o endereço e desistiu.
36 A participante enviou a foto para o Facebook pessoal
do mestrando e não para a página solicitada pois não
entendeu o que era para fazer.
37 A participante conseguiu responder corretamente as per-
guntas, mas pesquisou tudo no Chrome e não fez uso de
nenhum aplicativo.
66
Continuação da Tabela 4.1
No do Problema Descrição do Problema
38 A participante abriu o Google Maps, localizou o hospi-
tal e, após algumas tentativas de interação com a tela,
encontrou o endereço, mas não sabia que podia copiar e
colar e então transcreveu o texto manualmente.
39 A participante disse que teve dificuldades de enxergar o
ícone da câmera (muito pequeno) no Facebook Messen-
ger... e enviou para a página errada.
40 A participante não sabia como compartilhar um contato
via SMS e não completou essa tarefa.
41 O participante usou o Chrome para pesquisar a tradução
e não o tradutor.
42 O participante demorou para encontrar o botão para
acionar a câmera no Facebook Messenger.
Tabela 4.1: Problemas de usabilidade encontrados
Após avaliar as dificuldades encontradas, os mesmos foram agrupados em
categorias para melhor visualização e identificação das áreas com mais problemas de
usabilidade, conforme mostra a Tabela 4.2. Alguns problemas não foram colocados
em nenhuma categoria pois decorreram de falha na interpretação da tarefa por parte
do participante e não deixaram claro se realmente houve dificuldades de usabilidade
por conta das interfaces dos aplicativos. Ao mesmo tempo, outros problemas se
encaixaram em mais de uma categoria. O gráfico de barras na Figura 4.5 mostra o
número de ocorrências por categoria.
67
No do(s) Problema(s) Categoria
1, 7, 8 Dificuldade na entrada de dados por voz
2, 4, 12, 20, 29, 31, 33, 35 Dificuldade de encontrar um conteúdo presente na tela
5 Caixas de diálogo (modais) bloqueando o acesso rápido
a uma tela
6, 9, 18, 19, 21, 22, 24, 25, Dificuldade de compartilhar informações entre aplicati-
vos
26, 29, 38, 40
10, 13, 15, 42 Dificuldade de encontrar um elemento de interface pre-
sente na tela
11, 17, 19, 20, 38 Dificuldade em entender o significado de elementos de
interface presentes na tela
14, 16 Dificuldade de visualizar ou perceber uma notificação
23, 32, 39 Dificuldade de acionar um botão por motivos ergonômi-
cos
28, 34 Dificuldade de buscar um elemento em uma lista
29 Dificuldade de voltar a um estado anterior
Tabela 4.2: Categorias dos Problemas Encontrados
68
Figura 4.5: Número de ocorrências por categoria de problema
A seguir, foram analizadas cada uma dessas categorias, como elas se relaci-
onam com as heurísticas de Nielsen e/ou de Machado Neto e, dependendo de cada
caso, foram criadas novas heurísticas ou feitos aprimoramentos nas existentes.
4.2.1 Dificuldade na entrada de dados por voz
Essa categoria pode ser relacionada com a 7a heurística de Nielsen (“Flexibi-
lidade e Eficiência de Uso”), uma vez que a entrada de dados por voz pode acelerar
a interação entre um usuário experiente (que já conhece os comandos de voz acei-
tos) e o sistema interativo. Entretanto, a heurística é vaga e não especifica formas
para avaliar diferentes métodos de entrada. Em sua pesquisa, Neto [22] definiu uma
heurística que poderia se encaixar nesse problema: “Facilidade de acesso às funci-
onalidades”, onde é especificado que usuários devem ser capazes de acessar funções
da forma mais fácil possível.
69
Antes de pensar em discutir a criação de uma diretriz relacionada ao método
de entrada de dados por voz, é preciso destacar que os assistentes de voz presen-
tes em qualquer dispositivo móvel de hoje em dia são desenvolvidos como parte do
sistema operacional e, portanto, o desenvolvedor da aplicação final não tem total
liberdade para controlar a forma como seu produto irá interagir por voz. Tanto a
Siri, da Apple, quanto o Google Now, do Google, oferecem seus kits para desenvol-
vimento de software (SDKs), respectivamente chamados de “SiriKit”[35] e “Google
Voice Actions”[36]. Esses SDKs permitem que o desenvolvedor integre comandos
de voz em aplicativos de modo que eles sejam identificados quando o usuários os
chamar, independente de qual seja a aplicação ativa. Assim, se um usuário possui
um aplicativo de agenda médica, por exemplo, ele pode perguntar ao assistente de
voz qual é o seu próximo paciente; e a Siri ou Google Now irão, através do aplicativo
desenvolvido com esse SDK, fornecer essa informação.
Assim, a responsabilidade de oferecer um recurso que reconhece comandos de
voz com acurácia pertence ao desenvolvedor do sistema operacional, mas ao mesmo
tempo, cabe aos desenvolvedores de aplicativos escolher quais comandos seus pro-
dutos irão escutar e reconhecer. Dito isso, não faz sentido criar uma heurística
estabelecendo que os desenvolvedores devam produzir aplicativos que escutem com
clareza e entendam comandos em todos os tipos de situações, mas é possível criar
uma recomendação para que os comandos do aplicativo sejam os mais simples pos-
síveis e que existam comandos que identifiquem o que foi solicitado não somente em
uma linguagem formal mas também em linguagem mais coloquial e objetiva, a qual
possivelmente será usada em uma situação-limite.
Com base nessas informações, foi redefinida uma nova heurística, baseada na
8a heurística da pesquisa de Neto[22], estendendo seu escopo a assistentes de voz. A
parte sublinhada da heurística descrita abaixo destaca a parte que foi modificada:
70
Facilidade de acesso às funcionalidades: As funcionalidades principais
da aplicação devem ser realizadas com maior facilidade possível, preferencialmente
em apenas uma interação. Nenhuma funcionalidade deve ser difícil de encontrar
na interface da aplicação, assim como devem ser simples de se acionar através de
comandos de voz. Todos os componentes de entrada devem ser assimilados com
facilidade.
4.2.2 Dificuldade de encontrar um conteúdo presente na tela
Durante o estudo exploratório, a mesma dificuldade foi observada em diver-
sas rodadas quando o participante deveria localizar um endereço no Google Maps
e passar essa informação a um contato no WhatsApp: embora o endereço estivesse
presente na página em que o usuário chegou após pesquisar e selecionar o ponto de
interesse (POI), era necessário rolar um pouco a tela para baixo até aparecer essa
informação essencial. A dobra de cima da página mostrava informações possivel-
mente menos importantes do que a que estava sendo procurada, como por exemplo,
quantas estrelas os usuários deram a esse POI em suas classificações; além de fotos
do lugar que, dado o espaço reduzido destinado a isso na tela, não ficavam muito
legíveis. A 8a heurística de Nielsen (“Estética e Design minimalistas”) argumenta
que cada unidade extra de informação compete com a informação mais relevante,
abordagem que se encaixa muito bem na situação dos participantes. Entretanto,
a heurística não resolve completamente o problema já que essas unidades de infor-
mação, embora secundárias, podem ser úteis em outras situações, de modo que não
seria uma solução fazer uma limpeza da tela e remover esses elementos. O ponto que
a heurística precisaria abordar seria a priorização do que vem antes e ganha maior
visibilidade.
Isso foi confirmado pelo questionário pós-estudo, em que todos os participan-
71
tes dessa categoria afirmaram que um aplicativo como o Google Maps, que pode ser
usado em uma situação de emergência, deveria priorizar a visibilidade da informação
que é mais útil e não da mais atrativa esteticamente.
Sendo assim, foi especificada uma modificação na 8a heurística de Nielsen
com o objetivo de abordar o problema da priorização:
Projeto estético e minimalista: a interface não deve conter informação
que seja irrelevante ou raramente necessária. Cada unidade extra de informação em
uma interface reduz sua visibilidade relativa, pois compete com as demais unidades
de informação pela atenção do usuário. A aplicação deve dar prioridade ao uso da
parte mais visível da tela para as informações de maior importância.
Nota: O estudo exploratório foi realizado em Dezembro de 2017. Quando
acessado novamente em Janeiro de 2018 para coletar capturas de tela para essa
dissertação, uma atualização de software já havia ocorrido e trouxe mudanças muito
similares às que aqui foram propostas, substituindo a informação da categoria do
POI pelo seu endereço.
A Figura 4.5 mostra a parte inferior da tela do aplicativo Google Maps du-
rante o estudo e como ela poderia ficar seguindo a heurística descrita acima. Na
versão à esquerda, capturada de um iPhone 7, é mostrada a categoria “Hospital
Particular” e há um grande espaço ocupado pelas “estrelas” das classificações, en-
quanto a versão à direita, captura de um iPhone X mostra a classificação de forma
simplificada e o endereço do POI ao invés da categoria.
Ainda analizando esta categoria, ocorreu um outro problema: os partici-
pantes não sabiam que podiam rolar a página para obter mais informações. Um
bom indicador visual que chamasse a atenção para a existência de mais informações
72
Figura 4.6: Cartão de Informação na parte inferior da tela do Google Maps: duranteo estudo (à esquerda) e agora, após uma atualização (à direita).
abaixo da dobra da tela resolveria esse problema. Nesse caso específico, o único
indicador de que há mais conteúdo, é um “traço” reto, pequeno, em cinza claro, na
parte de cima do cartão de informação, indicando que ele pode ser puxado. A subs-
tituição desse “traço” reto por um indicador angulado e usando uma cor mais forte
ou colocado-o dentro de um botão colorido com um rótulo de “Mais informações”
anexado na parte de baixo da tela foram algumas das ideias que surgiram em um
brainstorming com o mestrando e seus orientadores. Essas ideias são reforçadas pelo
trabalho de Meyer [24], que pertence ao próprio grupo de pesquisa de Nielsen. Esse
problema seria detectado pela 6a heurística (“Reconhecimento em vez de memoriza-
ção”), que especifica que instruções sobre como usar o sistema devem estar visíveis
ou acessíveis sempre que preciso. Esta pesquisa concluiu então que a heurística exis-
tente é suficiente e não precisa ser alterada por conta desta categoria de problemas e
que o aplicativo em questão falhou e poderia ser melhorado colocando um indicador
visual melhor.
Na Figura 4.6, vemos como esse indicador aparece atualmente, à esquerda;
e alguns protótipos de como ele poderia ser para deixar mais claro ao usuário que
existe mais conteúdo ao rolar a página para baixo (equivalente a puxar o cartão
de informações para cima). O primeiro protótipo, ao centro, usa um ícone com um
ângulo apontado para cima, para deixar mais claro que essa parte da tela pode subir.
73
O segundo, à direita, inclui um botão com o ícone de um ângulo virado para baixo
na parte mais inferior da tela, com o rótulo “More Information”, indicando que há
conteúdo abaixo.
Figura 4.7: Parte de baixo da tela do Google Maps visualizando um ponto de inte-resse: como é atualmente (à esquerda) e como poderia ser se as instruções de usofossem mais explícitas (ao centro e à direita)
4.2.3 Caixas de diálogo (modais) bloqueando o acesso rápido a uma tela
Nesta categoria, um usuário teve dificuldades de lidar com uma caixa de
diálogo modal, isto é, que bloqueia o acesso ao resto das funções da aplicação até
ser respondida; a qual apareceu requisitando permissão para acessar os Serviços
de Localização do dispositivo, ou seja, o GPS. A atenção do usuário teve de ser
totalmente direcionada para responder essa pergunta, tirando o foco da atividade
principal e, após dar a permissão, o usuário levou alguns segundos para se lembrar
do que tinha que fazer na tarefa dada.
Não havia informações detalhadas sobre como lidar com modais nas heurís-
ticas de Nielsen nem no conjunto mais recente de Neto, então foi preciso pesquisar
material adicional e mais recente sobre o assunto. Fessenden[11] resume:
“Diálogos modais interrompem o usuário e demandam uma ação. São apro-
priados quando a atenção do usuário precisa ser direcionada a uma informação
74
importante.”
A autora ainda lista algumas desvantagens do uso de modais e uma delas
em particular se encaixa muito bem com a situação ocorrida com o participante do
estudo exploratório:
“Eles fazem o usuário esquecer o que estavam fazendo. Uma vez que
o contexto é alterado para uma tarefa diferente, devido à carga cognitiva adicional
imposta pelo diálogo modal, pessoas podem esquecer de alguns dos detalhes asso-
ciados à tarefa original. Se esse é o caso, retornar ao contexto da tarefa adicional
pode ser ainda mais difícil.”
Entretanto, Fessenden também descreve situações em que é conveniente fazer
o uso de modais, onde diz para “usar modais para requisitar do usuário a entrada
de informações críticas para a continuidade do processo em andamento”.
As permissões que o modal em questão solicitou são de fato necessárias para
a continuidade do uso do aplicativo. De acordo com as diretrizes para o desenvolvi-
mento de interfaces do usuário da Apple[1]:
“Usuários precisam conceder permissão para um aplicativo acessar informa-
ções pessoais, incluindo a localização atual, calendário, informações de contato, lem-
bretes e fotos. Embora as pessoas apreciem a conveniência de ter um aplicativo que
acesse essas informações, elas também esperam ter controle sobre seus dados priva-
dos.”
Conclui-se então que, nesse caso particular, quando o usuário precisa abrir
um mapa em uma situação-limite e a permissão não foi anteriormente concedida,
haverá inevitavelmente esse tipo de problema. Como as pesquisas anteriores e as
75
diretrizes para o desenvolvimento deixam claro, essas requisições via modais são
necessários para garantir a privacidade do usuário. Para cobrir esse caso, a seguinte
heurística foi proposta:
Diálogos Modais: quando a aplicação necessita interromper a tarefa atual
para solicitar algo usando diálogos modais, é preciso oferecer maneiras para que o
usuário se lembre do que estava fazendo assim que o modal for respondido.
4.2.4 Dificuldade de compartilhar informações entre aplicativos
Esse tipo de problema esteve presente tanto para copiar o endereço do hospital
no Google Maps quanto para copiar o resultado da tradução no Google Translator.
Embora o método para acessar o menu de contexto com as opções de recortar,
copiar e colar seja um padrão em todo o sistema operacional, sendo acionado ao
pressionar e segurar o texto selecionado, foi percebido que durante uma situação-
limite, muitos usuários não tiveram muita paciência com o ato de segurar e alguns
participantes até esqueceram que essa funcionalidade existe. Nós podemos trabalhar
sobre esse problema usando a 7a heurística de Nielsen (“Flexibilidade e eficiência de
uso”), a qual diz que aceleradores (atalhos) podem ser implementados para agilizar a
interação com usuários mais experientes, porém não são notados pelos mais novatos.
Nos dois tipos de problemas encontrados, havia atalhos invisíveis para agilizar a
cópia do conteúdo, porém havia espaços livres suficientes na tela, próximos ao local
do texto a ser copiado, onde os desenvolvedores poderiam incluir um indicativo ou
alguma “dica” para que os usuários novatos vissem o atalho. Um simples ícone para
copiar, em cinza claro, alinhado à direita na mesma linha do texto a copiar poderia
facilitar a identificação da ação sem competir com o conteúdo relevante, o que seria
um problema pela 8a heurística. Após essas considerações, foi redigida uma versão
aprimorada da 7a heurística de Nielsen:
76
Flexibilidade e eficiência de uso: aceleradores — pouco notados pelos
usuários novatos — podem tornar a interação do usuário mais rápida e eficiente,
permitindo que o sistema consiga servir igualmente bem os usuários experientes
e inexperientes. Exemplos de aceleradores são botões de comando em barras de
ferramentas ou teclas de atalho para acionar itens de menu ou botões de comando.
Além disso, o designer pode oferecer mecanismos para os usuários customizarem
ações frequentes. Sugestões visuais para acessar esses aceleradores podem ajudar
usuários novatos a aprender sobre eles.
Nota: na heurística original, dizia-se “invisíveis aos” usuários novatos.
A Figura 6 mostra como o aplicativo do Google Translator mostra os resul-
tados, onde há um atalho oculto para copiar o resultado ao pressionar e segurar o
texto; e depois um protótipo de como poderia ser aprimorado para ajudar usuários
novatos a notarem a existência do atalho.
Figura 4.8: Aplicativo Google Translator em sua versão atual (à esquerda) e umprotótipo para ajudar a notar a existência do atalho (à direita)
77
4.2.5 Dificuldade de encontrar um elemento de interface presente na tela
e Dificuldade em entender o significado de elementos de interface
presentes na tela
Essas duas categorias de problemas remetem à situação da Seção 4.2.2. Como
já foi discutido, a 6a (“Reconhecimento em vez de memorização”) heurística de Ni-
elsen trata adequadamente esses tipos de problemas e o uso de indicadores visuais
fracos foi o que dificultou a interação entre o usuário e o aplicativo do Google Maps.
A heurística existente foi aprimorada, ficando da seguinte forma:
Reconhecimento em vez de memorização: o designer deve tornar os
objetos, as ações e opções visíveis. O usuário não deve ter de se lembrar para
que serve um elemento de interface cujo símbolo não é reconhecido diretamente;
nem deve ter de se lembrar de informação de uma parte da aplicação quando tiver
passado para uma outra parte dela. As instruções de uso do sistema devem estar
visíveis ou facilmente acessíveis sempre que necessário. A visibilidade de elementos
indicadores deve ser mais prioritária do que a atratividade estética da tela.
4.2.6 Dificuldade de visualizar ou perceber uma notificação
Os problemas descritos nesta categoria podem ser divididos em dois tipos:
notificações por áudio e notificações visuais.
O Facebook Messenger é um aplicativo de troca de mensagens e portanto
recebe notificações frequentemente. Entretanto, quando o usuário já está com uma
conversa aberta e ativa em sua tela, os sons de notificações de novas mensagens para
essa conversa específica são suprimidos. Já que a conversa está ativa e o usuário
78
tem acesso visual a todas as mensagens e informações da conversa, faz sentido não
tocar o áudio para evitar perturbações desnecessárias no ambiente.
Porém, na situação do nosso estudo, como os usuários também estavam foca-
dos em completar uma tarefa, tendo a atenção dividida, muitos deles não percebiam
que novas mensagens estavam chegando. Em alguns casos, foram enviadas até men-
sagens adicionais apenas para chamar atenção, como “RÁPIDO!!!”, “É URGENTE!”,
dentre outras; e observou-se que sem o estímulo sonoro, mesmo com as mensagens
aparecendo na tela do dispositivo que está sendo segurado em suas mãos, o usuário
não percebeu a chegada de tais mensagens.
Já o problema da notificação visual ocorreu no aplicativo do Google Trans-
lator: quando o usuário pressiona e segura a linha contendo o resultado, ele é auto-
maticamente copiado (em vez de mostrar o menu de contexto, o que seria o compor-
tamento padrão do sistema operacional) e uma notificação informando sobre essa
ação é mostrada na parte mais inferior possível da tela, em uma faixa preta, que
desaparece alguns segundos depois. Enquanto isso, o local onde o usuário pressionou
e segurou é localizado na metade superior da tela. Um usuário chegou a realizar a
mesma ação repetidamente 4 vezes até perceber que o texto já havia sido copiado.
Na entrevista pós-estudo, esse usuário disse que como estava ansioso, apenas pres-
tava atenção onde estava apertando com o dedo e nem notou que havia algo sendo
mostrado na parte inferior da tela.
Os dois tipos de problemas podem ser relacionados à primeira heurística
(“Visibilidade e Status do Sistema”). Um pequeno incremento ao texto da heurística
foi feito para incentivar o uso das tecnologias dos smartphones em notificações:
Visibilidade do estado do sistema: o sistema deve sempre manter os
usuários informados sobre o que está acontecendo através de feedback (resposta às
79
ações do usuário) adequado e no tempo certo. Esse feedback deve usar os recursos
apropriados disponibilizados pelo dispositivo, como sons, respostas hápticas e no-
tificações visuais, de forma que o usuário possa facilmente notar a ocorrência de
qualquer mudança.
A opção de incluir informações adicionais mais específicas na heurística para
que a barra que aparece ao copiar seja melhor posicionada também foi discutida.
Primeiramente, foi considerado que esse problema seria detectado pela 4a heurística
de Nielsen (“Consistência e Padronização”), já que o comportamento padrão esperado
ao pressionar e segurar o resultado seria de mostrar o menu de contexto do sistema
operacional, onde o usuário iria clicar na opção “Copiar” e então saberia que o texto
foi copiado já que essa é a ação padrão para um botão com esse nome. Assim, o
inspetor verificaria que, por não seguir o padrão, há um problema de usabilidade.
No entanto, na Seção 4.2.4, foi concluído que aceleradores (atalhos), devem não
apenas ser usados por usuários experientes como também incentivados aos mais
novatos. Sendo assim, torna-se mais apropriado dizer que esse caso não é uma fuga
de padrão e portanto não se relaciona com a 4a heurística. Ao invés disso, podemos
tratá-lo com as já aprimoradas versões da primeira (por não usar da melhor forma
os recursos disponibilizados pelo dispositivo para emitir uma notificação, falhando
em mostrar ao usuário que houve uma mudança de status no sistema) e da 7a (não
havia indicadores visuais que sugerissem a existência do atalho).
4.2.7 Dificuldade de acionar um botão por motivos ergonômicos
Todos os casos de problemas que se encaixam nessa categoria se devem a
botões pequenos demais, difíceis de pressionar e segurar. Combinando a 4a heurística
(“Consistência e Padronização”) com as diretrizes de desenvolvimento de interfaces
do iOS[1] ou Android[38], onde há intruções sobre os tamanhos, posições e margens
80
dos elementos visuais a serem usados, temos informações suficientes para detectar
que um elemento de interface está mal dimensionado ou mal posicionado e que
portanto há um problema de usabilidade, não sendo necessário alterar heurísticas
existentes.
4.2.8 Dificuldade de buscar um elemento em uma lista
Este tipo de dificuldade ocorreu no aplicativo Google Translator, onde o
usuário deve selecionar o idioma desejado em uma lista. Como a lista tem muitas
opções e os usuários estavam se sentindo pressionados, demoraram mais tempo que
o normal (assim eles disseram) para encontrar o idioma desejado.
Este problema é tratado em diversas aplicações existentes usando atalhos
para navegar pela letra inicial dos itens na lista, como ocorre por exemplo no apli-
cativo de Contatos do iOS. Concluiu-se que a versão aprimoradada da 7a heurística
(“Flexibilidade e Eficiência de Uso”) é capaz de detectar que esta lista não está fun-
cionando de maneira eficiente e consequentemente há um problema de usabilidade.
4.2.9 Dificuldade de voltar a um estado anterior
Um usuário compreendeu incorretamente a visualização do ponto de interesse
no Google Maps e iniciou uma rota para navegação, tendo dificuldades de voltar
para a tela anterior. Esse é um problema que a 3a heurística de Nielsen (“Controle e
liberdade do usuário”) detectaria e, de fato, no aplicativo avaliado, tem um grande e
destacado botão vermelho “SAIR”. Concluiu-se que não seriam detectados problemas
de usabilidade nessa situação e o aplicativo não poderia ser mais claro, sendo assim
um caso isolado de falta de atenção do usuário.
81
5 CONCLUSÃO
As tecnologias estão mudando rapidamente ao longo do tempo e é impor-
tante que os métodos de avaliação de usabilidade se mantenham atualizados para
contemplar essas mudanças. Há situações-limite onde pessoas irão recorrer a deter-
minado aplicativo ou tecnologia pois já estão habituadas a usá-los em seu dia a dia.
É importante considerar isso e avaliar o uso da tecnologia em situações particulares,
especialmente quando envolve segurança, emergências ou qualquer outro caso em
que o usuário esteja emocional ou cognitivamente sobrecarregado.
Esta pesquisa revisou as heurísticas de Nielsen com o foco em situações-limite.
Nesse caso, situações-limite foram situações em que houve indução de stress (através
do uso de video games) e que serviram como um contexto no qual usuários foram
solicitados a realizar tarefas usando os aplicativos mais populares de comunicação
e referência. A revisão resultou em uma melhor especificação de 4 heurísticas de
Nielsen e no acréscimo de mais duas (sendo uma baseada no trabalho de Machado
Neto[22]). Também consistiu em uma revisão de literatura e consolidação de resulta-
dos encontrados por outros pesquisadores no que se refere à aplicação das heurísticas
de Nielsen.
Esta pesquisa contribuiu para o aprimoramento da Base de Conhecimento
em desenvolvimento de aplicativos móveis, especialmente no caso de aplicativos que
envolvem colaboração, como mensageiros instantâneos. O resultado pode ser útil
no âmbito industrial ao melhorar a forma como interfaces de softwares móveis são
avaliadas. Para a comunidade científica, contribuiu não somente com o conhecimento
gerado a partir desse cenário parcialmente controlado de stress induzido mas também
com um processo para avaliar outros aplicativos e, possivelmente, estender este
82
trabalho.
O uso de jogos eletrônicos como indutores de stress tem sido apoiado na
literatura e esta pesquisa usou a melhor forma de leitura biométrica atualmente
disponível, o sensor Galvanic Skin Response (GSR). Os resultados desta pesquisa
corroboram e somam à literatura atual, o que pode incentivar pesquisadores desta
área a aplicar o mesmo procedimento que foi usado para desenvolver o caso de uso
em questão.
Uma limitação da pesquisa atual é que não se pode afirmar que um “ponto
de saturação” foi alcançado. Há possivelmente outros incidentes que não foram
vivenciados acontecendo durante este estudo. Resumidamente, não se pode afirmar
que não há necessidade de outras modificações no conjunto atual de heurísticas.
Trabalhos futuros desta pesquisa incluem a replicação do estudo atual com
o foco em outras categorias de aplicativos móveis. Também é possível apontar
estudos futuros para investigar como e quando o “ponto de saturação” será alcançado.
Outro possível estudo poderia verificar os problemas de usabilidade que surgem
em situações-limite em aplicativos para computadores desktop e se as heurísticas
resultantes desta pesquisa os detectariam. Por fim, os trabalhos futuros podem
apontar para a replicação do estudo atual com deficientes visuais ou qualquer outro
tipo de necessidade especial, de forma que possam ser identificadas diretrizes para
acessibilidade no contexto de situações-limite.
83
REFERÊNCIAS
[1] APPLE. Apple iOS Human Interface Guidelines. Disponível em
http://developer.apple.com/library/ios/documentation/userexperi en-
ce/conceptual/mobilehig/introduction/introduction.html.
[2] BARBOSA, S.; SILVA, B. Interação Humano Computador. Rio de Janeiro,
Brasil: Elsevier Editora Ltda., 2010.
[3] BIAS, R.; MAYHEW, D.Cost-Justifying Usability. San Francisco, CA, EUA:
Mongan Kauffmann Publishers, 2005.
[4] BOSSE, T. et al. Inducing Anxiety through Video Material. , [S.l.], v.434, p.301–
306, 06 2014.
[5] BOUCHARD, S. et al. Modes of immersion and stress induced by commercial
(off-the-shelf) 3D games. Journal of Defense Modeling and Simulation:
Applications, Methodology, Technology, [S.l.], 2012.
[6] BOUCSEIN, W. Electrodermal Activity. 2.ed. [S.l.]: Springer US, 2012.
[7] COHEN, S.; KAMARCK, T.; MERMELSTEIN, R. A global measure of per-
ceived stress. Journal of health and social behavior, vol. 24, no. 4, pp.
385–96, [S.l.], 1983.
[8] D’CARLO, D.; BARBOSA, G. A. R.; OLIVEIRA Érica Rodrigues de. Proposta
de um Conjunto de Heurísticas para Avaliação da Usabilidade de Aplicativos
Móveis Educacionais. , [S.l.], v.5, n.2, p.16–35, 03 2017.
[9] DEY, A.; ABOWD, G. Towards a Better Understanding of Context and Context-
Awareness. CHI2000, Workshop on What, Who, Where, When and How
of Context-Awareness. Nova York, EUA., [S.l.], 2000.
84
[10] FEIJO, V.; GONçALVES, B.; GOMES, L. Heurística para avaliação de usabi-
lidade em interfaces de aplicativos smartphones: utilidade, produtividade e imer-
são. , [S.l.], v.3, n.6, p.33–42, 2013.
[11] FESSENDEN, T. Modal and Nonmodal Dialogs: when ( when not)
to use them. disponível em https://www.nngroup.com/articles/modal-
nonmodal-dialog/.
[12] FILHO, C. F. História da Computação - O caminho do pensamento e
da tecnologia. Brasil: EDIPUCRS (Domínio Público), 2007.
[13] GAFNI, R. Usability issues in mobile-wireless information systems. Issues in
Informing Science and Information Technology, vol. 6, 2009, pp. 755-
769., [S.l.], 2009.
[14] GOODE, L. Messenger and WhatsApp process 60 billion
messages a day, three times more than SMS. Disponível
em https://www.theverge.com/2016/4/12/11415198/facebook-
messenger-whatsapp-number-messages-vs-sms-f8-2016. [S.l.]: The
Verge, 2017.
[15] GREENBERG, S.; BUXTON, B. Usability Evaluation Considered Harmful
(Some of the Time). CHI 2008 Proceedings, [S.l.], 2008.
[16] HULL, R.; NEAVES, P.; BEDFORD-ROBERTS, J. Towards Situated Compu-
ting. 1st International Symposium on Wearable Computers, [S.l.], 1997.
[17] ISO. ISO 9241-11. Ergonomic requirements for office work with visual
display terminals (VDTs) – Part 11: guidance on usability. [S.l.: s.n.],
1998. ISO. (9241).
[18] ISO/IEC. ISO/IEC 9126. Software Engineering - Product Quality. In-
ternational Organization for Standarization, Geneva. [S.l.: s.n.], 2001. ISO.
(9126).
85
[19] KIRCHBAUM, C.; PIRKE, K.-M.; HELLHAMMER, D. H. The Trier Social
Stress Test: a tool for investigating psychobiological stress responses in a labora-
tory setting. Neuropsychobiology, 28:76-81, [S.l.], 1993.
[20] KNOLL, R. C. Desenvolvimento de heurísticas de usabilidade para tablets. ,
[S.l.], v.2, n.1, p.93–109, 2014.
[21] KUNJACHAN, C. Evaluation of Usability on Mobile User Interfaces. Univer-
sity of Washington, Bothel, EUA, [S.l.], 2011.
[22] MACHADONETO, O. Usabilidade da interface de dispositivos móveis: heu-
rísticas e diretrizes para o design. Dissertação (Mestrado - Programa de
Pós-Graduação em Ciências de Computação e Matemática Computaci-
onal) - Instituto de Ciências Matemáticas e de Computação, São Paulo,
SP, 2013.
[23] MEYER, K. Writing Tasks for Quantitative and Qualitative Usability
Studies: disponível em https://www.nngroup.com/articles/test-tasks-
quant-qualitative/.
[24] MEYER, K. Flat UI Elements Attract Less Attention and Cause
Uncertainty: disponível em https://www.nngroup.com/articles/flat-
ui-less-attention-cause-uncertainty/.
[25] MOBITHINKING. Global Mobile Statistics.
https://mobiforge.com/research-analysis/global-mobile-statistics-
2014-home-all-latest-stats-mobile-web-apps-marketing-advertising-
subscriber.
[26] NAYEBI, F.; DESHARNAIS, J.-M.; ABRAN, A. The State of the Art of Mobile
Application Usability Evaluation. Canadian Conference on Electrical and
Computer Engineering, [S.l.], 2012.
86
[27] NIELSEN, J. Usability Engineering. San Francisco, CA, EUA: Morgan
Kaufmann Publishers Inc., 1993.
[28] PAI, A. Survey: 58 percent of smartphone users have
downloaded a fitness or health app. disponível em
http://www.mobihealthnews.com/48273/survey-58-percent-of-
smartphone-users-have-downloaded-a-fitness-or-health-app. [S.l.]:
mobihealthnews, 2015.
[29] RONCALIO, V. W. et al. Teste de usabilidade com celular touch screen em
simulação de contexto de emergência. 12o Congresso Internacional de Er-
gonomia e Usabilidade de Interfaces Humano-Tecnologia: Produtos,
Informações, Ambiente construído e transporte, Natal, RN, Brasil, 2012.
[30] RYAN, N.; PASCOE, J.; MORSE, D. Enhanced Reality Fieldwork: the
context- aware archaeological assistant. Computer Applications in Archa-
eology, [S.l.], 1997.
[31] RYU, Y. S. Development of usability questionnaires for electronic mobile pro-
ducts and decision making methods. Virginia Polytechnic Institute and
State University, EUA, [S.l.], 2005.
[32] SCHILIT, B.; THEIMER, M. Disseminating Active Map Information to Mobile
Hosts. IEEE Network, 8(5), 22-32, [S.l.], 1994.
[33] SHARP, H.; ROGERS, Y.; PREECE, J. Interaction design: beyond human-
computer interaction. New York, NY, EUA: John Wiley Sons, 2007.
[34] SHNEIDERMAN, B.; PLAISANT, C.Designing the User Interface: strate-
gies for effective human-computer interaction. Boston, MA, EUA: Addison-Wesley
Longman, 2009.
[35] SIRIKIT. SiriKit. Disponível em https://developer.apple.com/sirikit.
87
[36] TELL GOOGLE WHAT YOUR APP CAN DO. Disponível em
https://developers.google.com/voice-actions/.
[37] TOGNAZZINI, B. How user testing saves money. Disponível em
http://www.asktog.com/columns/037testorelse.html. 2010.
[38] User Interface Guidelines: disponível em
http://developer.android.com/guide/practices/uiguidelines/index.html.
[39] ZHANG, D.; ADIPAT, B. Challenges, methodologies, and issues in the usability
testing of mobile applications. International Journal of Human-Computer
Interaction, vol. 18, no. 3, pp. 293- 308, [S.l.], 2005.
88
APÊNDICE A QUESTIONÁRIO E RESPOSTASPÓS-ESTUDO
Nesse apêndice, estão relacionadas as respostas preenchidas pelos partici-
pantes do estudo exploratório ao questionário proposto. O questionário foi feito
usando a ferramenta TypeForm (www.typeform.com) e os participantes o responde-
ram usando o computador logo após terminarem de realizar as tarefas.
A Tabela A.1 lista as perguntas que foram feitas e atribui um número a
cada uma, afim de facilitar a organização das respostas. A Tabela A.2 apresenta as
respostas dadas.
As respostas dos nomes dos participantes (Pergunta 1) foram editadas para
garantir o anonimato dos mesmos.
No Pergunta
1 Olá, qual é seu nome?
2 Você se considera uma pessoa estressada no dia-a-dia?
3 Numa escala de 1 a 10, o quão estressado/ansioso você diria que estava
no momento em que realizou as tarefas?
4 Qual o seu grau de familiaridade com o sistema operacional usado no
teste (iOS ou Android)?
5 Quais as maiores dificuldades encontradas ao usar o aplicativo do What-
sApp nessas condições?
6 Quais as maiores dificuldades encontradas ao usar o aplicativo do Face-
book Messenger nessas condições?
89
7 Quais as maiores dificuldades encontradas ao usar o aplicativo do Google
Maps nessas condições?
8 Você teve alguma dificuldade de uso geral?
9 Você tem alguma sugestão de melhora em algum desses aplicativos?
Tabela A.1: Perguntas do Questionário
Perguntas Respostas do Participante 1
1 L.
2 0
3 10
4 10
5 mandar o endereço do hospital
6
7 achar e compartilhar o endereço
8 sim, usar a siri não foi fácil
9 que o endereço ficasse mais visivel
Perguntas Respostas do Participante 2
1 G.
2 0
3 10
4 4
5
6 dificuldade na hora de achar a camera e na hora de permitir a mesma
7 tudo muito complicado, acha e compartilhar o endereço
8 sim, nao tenho habito de usar o iOS
90
9 o google maps precisa trabalhar muito pra melhorar
Perguntas Respostas do Participante 3
1 B.
2 3
3 9
4 1
5 Ter que prestar atenção no jogo; Não está familiarizada com IOS e ter
dificuldade de encontrar o aplicativo; Não conseguir prestar atenção no
jogo enquanto respondia ou percebia que tinha recebido mensagem.
6 Não usar o aplicativo do facebook messenger constantemente, por isso
não sabia como buscar como buscar o contato de uma pagina.
7 Eu nem pensei em usar direto o aplicativo google maps, pensei em pes-
quisar por voz direto no google. Tive dificuldade em copiar o endereço
para colar na conversa, estava tentando usar da forma que uso no An-
droid e como estava nervosa não cogitei de inicio que poderia ser dife-
rente para copiar e colar, perdi muito tempo esperando a barrinha para
selecionar o texto a ser copiado e na hora de colar na conversa fiquei a
"barrinha"maior.
8 Não costumo usar aplicativo de tradução, sempre pesquiso direto no na-
vegador, não pesei em procurar e como estava nervosa, passei pelo aplica-
tivo e não vi porque estava mais preocupada em procurar algo que fosse
mais familiar para responder rápido.
9 Sim, ter a opção de copiar o endereço por voz ou enviar direto pro What-
sapp. Atalho para enviar endereço por voz.
Perguntas Respostas do Participante 4
1 F.
91
2 1
3 5
4 6
5 Ter que sair do whatsapp e entrar em outros aplicativos.
6 Pesquisar a página e enviar a foto.
7 Nao aparecer o endereço logo de "cara"
8 Celular usado, iphone. Tive dificuldade com o botao home.
9 Google maps: Indicar o endereço na primeira pesquisa do local na pagina
do google maps.
Perguntas Respostas do Participante 5
1 F.
2 0
3 3
4 7
5 Simultaneamente responder às perguntas e tentar desarmar a bomba.
Particularmente ter de usar outros aplicativos para obter as respostas
contribui para dificultar a tarefa.
6 Não cheguei a usar este aplicativo enquanto jogava...
7 Não tive dificuldades adicionais com o ’Google Maps’
8 Realizar as duas atividades ao mesmo tempo já é dificuldade suficiente
9 Acredito que não tenha
Perguntas Respostas do Participante 6
1 R.
2 1
3 4
92
4 4
5 Utilizar o aplicativo enquanto sua cabeça está em outra tarefa desvia o
foco. Me senti mais lento para realizar a tarefa que normalmente realizo
de forma intuitiva.
6 Não uso facebook faz pelo menos uns dois anos, logo não reconheci a
nova interface e demorei mais que o normal para encontrar a página para
onde deveria enviar a foto.
7 Não foi solicitado durante o teste.
8 A interface do iOS é consideravelmente diferente da que estou habituado
a usar (android). Os atalhos ficam em lugares diferentes o que resultou
em demora para realizar o procedimento. Além disso, a alguns ícones
são diferentes.
9 A padronização das apresentações em diferentes sistemas operacionais
seria útil, para agilizar as tarefas.
Perguntas Respostas do Participante 7
1 L.
2 1
3 8
4 9
5 Alternar entre aplicativos: é mais fácil pelo multitarefa ou abrir a tela
de início e depois o aplicativo desejado?
6 Foi tranquilo
7 Fez a busca do endereço pelo Safari. Difícil copiar o endereço (copiou o
link ao invés do endereço)
8
93
9 Copiar o endereço no Safari poderia ser mais fácil.
Perguntas Respostas do Participante 8
1 R.
2 2
3 7
4 8
5 No iMessage, não achei onde enviar contato
6 Nenhuma dificuldade
7 Não usou
8 Não
9 Para compartilhar o contato, talvez seja melhor ter um botão para enviar
o Contato (no iMessage).
Perguntas Respostas do Participante 9
1 J.
2 2
3 4
4 9
5 Nenhuma
6 Nenhuma
7 Procurei no safari
8 Não sabia como anexar um contato
9 Não
Perguntas Respostas do Participante 10
1 F.
2 3
94
3 9
4 9
5 Dificuldade em enviar áudio. pensei que estava gravando e não estava.
O botão não é confiável.
6 Não tive dificuldades.
7 Minha maior dificuldade foi copiar o endereço que eu queria enviar por
Whatsapp. Não consegui.
8 A princípio não.
9 Era uma forma diferente na gravação de áudio no Whatsapp e na forma
de copiar ou compartilhar um endereço no Google Maps.
Perguntas Respostas do Participante 11
1 F.
2 2
3 8
4 10
5 Nao
6 -
7 Copiar o endereço
8 Não
9 -
Perguntas Respostas do Participante 12
1 J.
2 2
3 8
4 4
95
5 sem dificuldade
6 sem dificuldade
7 precisei dar print
8 não
9 o maps é um pouco confuso na relação de compartilhamento de endereço
Perguntas Respostas do Participante 13
1 G.
2 4
3 7
4 5
5 esqueci como copiar e colar
6 costumo usar a versão web
7 não tive grandes dificuldades
8 encontrar a língua especificada
9 não
Perguntas Respostas do Participante 14
1 N.
2 2
3 8
4 7
5 Nenhuma, acho que o audio inclusive era uma boa ferramenta para res-
ponder rapidamente ao que era pedido.
6 Eu quase nao uso o messenger, uso apenas o whatzapp, entao pela falta
de familiaridade eu demorei mais com o messenger, mas acredito que o
messenger tem praticamente os mesmos recursos.
96
7 O aplicativo era muito focado em informar a rota, e nao o endereço
detalhado em si.
8 Não.
9 Talvez o google maps não precise ser tão focado em mostrar as rotas, já
que esse é só uma das finalidades do aplicativo.
Perguntas Respostas do Participante 15
1 W.
2 0
3 4
4 9
5 Pensar na resposta da mensagem enquanto me preocupo com o tempo
da bomba passando
6 O problema maior é ficar pensando na bomba
7 Nao conseguir copiar a tradução e enviar para quem precisa
8 Não.
9 Não por ja estar acostumado com o sistema operacional do celular que
utilizei, ate porque sempre uso esse
Perguntas Respostas do Participante 16
1 J.
2 4
3 7
4 10
5 Segurar o botão de enviar áudio pois é muito pequeno
6 Nunca tinha usado o aplicativo, não sabia como fazer nada
7 Nenhuma
97
8 Não.
9 O botão podia ser maior
Perguntas Respostas do Participante 17
1 V.
2 0
3 7
4 5
5 Não
6 Não sabia como fazer o que foi pedido, não consegui
7 Não achei o endereço
8 Sim, pois nunca precisei usar o celular nessa situação
9 Não sei
Perguntas Respostas do Participante 18
1 L.
2 1
3 6
4 7
5 Nenhuma
6 Nenhuma
7 Nenhuma
8 Não
9 Não
Perguntas Respostas do Participante 19
1 M.
2 0
98
3 8
4 6
5 Nesse, não tive dificuldade
6 é difícil achar a câmera
7 Nunca tinha procurado um endereço antes então não sabia onde ficava
nem como copiar
8 é dificil fazer as duas coisas ao mesmo tempo
9 não
Perguntas Respostas do Participante 20
1 Sávio
2 0
3 7
4 9
5 Não tive
6 Também não
7 Não tive
8 não
9 não
Tabela A.2: Respostas do Questionário