usabilidade em aplicativos mÓveis: heurÍsticas para ... · ii. ugulino, wallace corbo...

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


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


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

Whatsapp

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


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



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



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



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



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



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



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



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



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


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


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.


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.


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


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.


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.


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


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


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.


1 F.

2 2

3 8

4 10

5 Nao

6 -

7 Copiar o endereço

8 Não

9 -


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


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


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.


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


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


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


1 L.

2 1

3 6

4 7

5 Nenhuma

6 Nenhuma

7 Nenhuma

8 Não

9 Não


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


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

usabilidade em aplicativos mÓveis: heurÍsticas para ... · ii. ugulino, wallace corbo...

Documents