EXPERIÊNCIA DO

CESAR RICARDO STATI

CAMILA FREITAS SARMENTO
 QUER SEP MAIS LIVRE?
Aprenda a Pesquisar e Fazer Ebooks | Armazene arquivos de forma segura

APRENDA A FAZER EBOOKS HTTPS://ODYSEE.COM

Seja a partir de Livro ou PDF escaneado Plataforma descentralizada para

Construa PDF pesquisável ou Epub Reprodução e Hospedagem de arquivos
Qualidade Profissional Garantida por BlockChain

Rápido e Eficiente Prática como Youtube

Descentralizada e resiliente como torrent
t.me/AnonLivros Facilitadora de transações financeiras como Bitcoin

Acervo em Português HTTPS://LIBGEN.IS

Mais de 70 mil ebooks no Telegram HTTPSy/Z-LIB.ORG
t.me/PolemicBooks
Portais de Ebooks e artigos científicos
Mais de 2 milhões de documentos
Mais de 2 mil cursos em vídeo
t.me/oAcervoCursos

Cursos via streaming no Telegram

t.me/LivreSaber

CONTRA A PROPRIEDADE INTELECTUAL

A fundamentação Teórica em favor do Conhecimento Livre

https://www.mises.org.br/Ebook.aspx?id=29

t.me/AnonLivros
Os livros dedicados à área de design têm projetos que reproduzem o visual de movimentos
históricos. Neste módulo, as aberturas de partes e capítulos geométricas e os títulos em linhas
redondas e diagonais fazem referencia aos pôsteres da Bauhaus, a icônica escola alemã de design,
arquitetura e artes plásticas.
EXPERIENCE
DO USUÁRIO (UX)

Cesar Ricardo Stati

.W
inter
Camila Freitas Sarmento saberes
inter Rua Clara Vendramin, 58 . Mossunguê . CEP 81200-170 . Curitiba . PR . Brasil
saberes Fone: (41) 2106-4170 . www.intersaberes.com . editora@intersaberes.com

Conselho editorial Capa

Dr. Ivo José Both (presidente) Débora Gipiela (design)
Dr? Elena Godoy vitek3ds/Shutterstock (imagem)
Dr. Neri dos Santos
Projeto gráfico
Dr. Ulf Gregor Baranow
Bruno Palma e Silva
Editora-chcfc
Diagramação
Lindsay Azambuja
Renata Silveira
Gerente editorial
Equipe de design
Ariadne Nunes Wenger
Débora Gipiela
Assistente editorial
Iconografia
Daniela Viroli Pereira Pinto
Palavra Arteira
Preparação de originais Regina Cláudia Cruz Prestes
Gustavo Piratello de Castro

Edição de tcxto
Palavra do Editor
Monique Francis Fagundes Gonçalves

Dados Internacionais de Catalogação na Publicação (CIP)

(Câmara Brasileira do Livro, SP, Brasil)

Stati, Cesar Ricardo

Experiência do usuário (UX) [livro eletrônico)/César Ricardo Stati, Camila Freitas
Sarmento. Curitiba: InterSabercs, 2021.
2 Mb; PDF

Bibliografia
ISBN 978-65-5517-913-2

1. Tecnologia 2. Usuários da Internet 3. Usuários da Internet - Comportamento de uso

I. Sarmento, Camila Freitas. II. Título.

21-54473 CDD-660.02

índices para catálogo sistemático:

I. Tecnologia 660.02

Aline Graziele Benitez - Bibliotecária - CRB-1/3129

Ia edição, 2021.
Foi feito o depósito legal.
Informamos que é de inteira responsabilidade dos autores a emissão de conceitos.
Nenhuma parte desta publicação poderá ser reproduzida por qualquer meio ou forma sem
torram afiliada a prévia autorização da Editora InterSabercs.
A violação dos direitos autorais c crime estabelecido na Lei n. 9.610/1998 c punido pelo
art. 184 do Código Penal.
Apresentação 8

1 Experiência do usuário 14

1.1 O design centrado no usuário 15

1.2 Design centrado no usuário e usabilidade 21
1.3 Design centrado no usuário não é apenas design 28
1.4 Design centrado no usuário não é relatório de problemas 36
1.5 Design centrado no usuário não é perda de tempo 39

2 Como trabalhar com o usuário 48

2.1 Diferentes tipos de usuários 56

2.2 Planejamento e definição do projeto 65
2.3 Coleta de requisitos do usuário 72
2.4 Modelos de dados e de fluxo de trabalho 77

3 Documentação dos protótipos e a importância da revisão

da documentação 82

3.1 Restrições e narrativa 88

3.2 Personas e cenários 96
3.3 Criatividade e experiência do usuário 102
3.4 Metas de experiência do usuário 118
4 Princípio da proximidade 122
4.1 Hierarquia e visibilidade 133
4.2 Análise da tarefa 142
4.3 Heurística 148
4.4 Modelos mentais e metáforas 155

5 Feedback do usuário 162

5.1 Amostragem e entrevista 172
5.2 Estudos de usabilidade 187
5.3 Plano de testes 192
5.4 Diretrizes para teste 195

6 Materiais e métodos 202

6.1 Ambiente e banco de dados 215
6.2 Gravação 219
6.3 Condução de estudo 222
6.4 Organização dos resultados 229

Consideraçõesfinais 236
Referências 240
Sobre os autores 244
 9

O estudo da interação do usuário com os diversos dispositivos

eletrônicos e suas interfaces ganhou espaço após o crescimento da
internet no final dos anos 1990 e, mais recentemente, com o acesso
a smartphones e tablets. Antes, os computadores estavam disponíveis
em áreas militares e em centros universitários de pesquisa. Os apa­
relhos nessa época não tinham os atrativos de hoje, como botões,
ícones, imagens e animações. Eram telas com fundo escuro e letras
verdes, e poucos se animavam a aprender uma linguagem de pro­
gramação ou ter um computador em casa.
Os primeiros estudos na área de interfaces concentraram-se, en­
tre outros aspectos, na resposta de pilotos ao comando de aeronaves
ou na ação de operadores de máquinas em linhas de produção de
fábrica. Poucos apelos visuais eram explorados, mas já se sabia a im­
portância da relação dos seres humanos com as máquinas. Um aviso,
por exemplo, de falta de combustível no veículo ou de defeito cm
uma máquina era uma das formas de os usuários da época obterem
feedback em alguns desses sistemas.
Em seguida, a tecnologia dos processadores evoluiu e eles ficaram
mais baratos, com isso alguns visionários apostaram na produção de
computadores pessoais. Por exemplo, Steve Jobs, fundador da Apple
com Steve Wozniak, acreditou que telas amigáveis, com recursos
visuais revolucionários, aproximariam pessoas de computadores,
leve início a era dos personal computers (PCs) e o uso de ícones para
facilitar a navegação nos softwares. Outros dispositivos também vie­
ram a se tornar populares, como os videocassetes (com seus controles
remotos cheios de botões subutilizados), até chegarem os aparelhos
de digital video disc (DVD) e os menus de escolhas de cenas dos
filmes, tarefa inimaginável em fitas de vídeo.
10

A experiência do usuário - conhecida pela sigla UX, de user

experience - tornou-se um campo de estudos no ramo de desen­
volvimento de projetos, principalmente na área digital. A internet,
a rede mundial de computadores, ampliou o uso dos computadores,
tanto em empresas como no âmbito pessoal. Páginas virtuais, que
iniciaram de forma estática, agora sâo desenvolvidas em versões
responsivas para aparelhos móveis, de maneira dinâmica e cada vez
mais interativa. Lojas de aplicativos estão a cada dia oferecendo mais
alternativas para o usuário, desde jogos até serviços bancários.
No entanto, esse cenário somente será vantajoso para quem de­
senvolver interfaces que sejam de navegação agradável para o usuário.
E é papel da experiência do usuário (ou UX design) cuidar de todos
os aspectos da interação das pessoas com os dispositivos. Equipes de
desenvolvimento antes mergulhavam no projeto com o desafio de
entregar um sistema que usasse as tecnologias do momento e agra­
dasse o cliente. Hoje, já se sabe que um usuário que nâo se satisfaz
com um aplicativo o abandona por vários fatores que poderíam ser
corrigidos ainda no processo de desenvolvimento. E é aí que se en­
contra o valor de uma equipe orientada ao UX design.
A experiência do usuário somente terá êxito quando a equipe
de desenvolvimento o envolver já no processo de construção dos
softwares, com entrevistas, testes de usabilidade, pesquisas e várias
outras ferramentas necessárias para entender as necessidades das pes­
soas. Dessa forma, criar sistemas que atendam às necessidades do
usuário e não criar novos problemas é o papel principal do UX design,
ou seja, elevar a empatia ao nível máximo.
 11

Nesta obra, veremos como trilhar os caminhos da UX, mostran­

do para todos os profissionais da área de desenvolvimento como agir
para adotar as boas práticas que estão sendo aplicadas pela maioria
das empresas de tecnologia. Com certeza, esse é um assunto que não
se esgota na última página deste livro.
EXPERIENCE
DO USUÁRIO
 15

ti O design centrado no usuário

De manhã, às 6 horas, toca o alarme do celular, programado para

o mesmo horário de segunda a sexta-feira. O som é interrompido
ao escolhermos um dos dois botões: soneca ou cancelar. As men­
sagens chegaram durante a madrugada e logo cedo e, conforme
a prioridade, nós as respondemos por ali mesmo, no smartphone.
Depois, consultamos a agenda para saber quais são os compromissos
do dia, seguida das notificações das redes sociais.
Os produtos que consumimos estão acondicionados em embala­
gens que foram planejadas para fácil manuseio. As roupas traduzem
nosso estilo e são vestidas com praticidade. As notícias se destacam
nos principais sites, nos quais damos uma rápida olhada apenas nos
títulos, que levam a um clique e, logo mais, a outros cliques. Antes
de acabar a leitura, consultamos a meteorologia no aplicativo do
tempo. Colocamos nosso destino no GPS do celular, que nos mostra
na tela o tempo de percurso e o trajeto que desvia de engarrafamen­
tos. Até quem não usa veículo próprio está recebendo mensagens não
só pelo smartphone mas também por meio de outdoors, mobiliários
urbanos ou cartazes nos ônibus.
Teixeira (2014) salienta que a experiência do usuário existe desde
que o mundo é mundo, ou melhor, desde que as pessoas começaram
a “usar” objetos para realizar alguma tarefa.

Os departamentos de TI não estão mais controlando seus ambientes, disponibili­

zando telefones e computadores; a expectativa é de que todos esses dispositivos

simplesmente funcionem na rede corporativa do usuário. Sendo assim, o nível

também foi elevado para o desenvolvedor que trabalha em empresas. Usuários

16

corporativos esperam produtos como portais para empresas e aplicativos de linha

de negócios que sejam criteriosamente projetados e cativantes, exatamente como

os produtos que usam em casa. (Lowdermilk, 2019, p. 16)

Nossa exposição às mensagens durante o dia é enorme, e são

elas que nos fazem permanecer, por exemplo, em sites, deletar um
aplicativo que não nos agrada ou ficar horas em um jogo para
atingir certo nível.

A mesma regra se aplica para os projetos nos quais você trabalha, sejam eles jogos,

websites, aplicativos para celular, serviços digitais, sites de e-commerce etc. Como

fazer o seu usuário completar as tarefas sem dificuldades? Como criar uma interface

que seja realmente simples de usar? Como manter o usuário motivado para seguir

adiante, para passar mais tempo usando o seu produto, para divulgar o seu produto

para os amigos ou para voltar mais vezes a ele? (Teixeira, 2014, p. 5)

As pessoas têm padrões e anseios ao manipular objetos tecnoló­

gicos. São hábitos e costumes que nasceram em diversas esferas de
convívio: em casa, na escola, entre amigos, enfim, nos ambientes em
que o usuário se relaciona. Desde tempos remotos, a tecnologia vem
alimentando necessidades, das mais básicas até aquelas consideradas
supérfluas. Dessa forma, pode ser que ela atenda às necessidades
e siga o caminho do sucesso ou, simplesmente, tenha seu interesse
diminuído e dê espaço para outro artefato.
Esta é a orientação que todos os desenvolvedores de novas tec­
nologias devem seguir: ter empatia com o usuário, colocar-se em
seu dia a dia, analisar suas reais necessidades e buscar atendê-las,
além de não criar produtos que acabam por revelar novos problemas
e frustrações. O controle remoto é um dos exemplos de alto nível
 17

de complexidade. Por causa da complexidade, muitas vezes, há per­

da em algumas funcionalidades de seus botões, pois não são todos
utilizados, frustrando o usuário. E o contrário do que ocorre com
a Alexa, da Amazon, que é operada com simplicidade, mas tem alto
poder de pregnância.
Desenvolver uma nova interface para um aplicativo, por exem­
plo, vai além de elaborar um código bem estruturado, seguir design
patterns ou escrever uma documentação atualizada e abrangente.
E mais do que criar um layout com todos os elementos organizados,
alinhados e esteticamente bonitos ou, ainda, redigir um manual do
usuário, disponível no site cm formato PDF, quem sabe usando tam­
bém recursos em JavaScript ou tutorials em vídeos com os recursos
mais atuais de edição. Há quem ache que o sucesso está no resultado
da quantidade de testes realizados, relatando /'wçr consertados pelos
técnicos. A equipe de marketing dirá que resultados positivos do
aplicativo estão nas estratégias de divulgação nas redes sociais.

Qualquer pessoa envolvida no processo de criação de um aplicativo (não apenas

os designers) deveria tentar compreender quais são as necessidades dos usuários

para determinar o propósito de um aplicativo. Isso envolve muito mais do que

o design da parte gráfica, o código ou a funcionalidade. É toda a equipe (ou

somente você) trabalhando continuamente para entender o usuário. Nem todos

os problemas de nossos usuários podem ser solucionados por meio de códigos,

por mais que eu desejasse; sendo assim, os desenvolvedores devem assumir uma

abordagem holística. (Lowdermilk, 2019, p. 17)

Tudo isso é importante, porém, se a equipe não estiver alinha­

da com as necessidades do usuário, o artefato não vai encontrar
espaço no mercado. Durante o ciclo de vida do projeto, é de
18

suma importância incluir a prática denominada design centrado no

usuário (DCU) ou, ainda, UX design. Essa função era do chamado
arquiteto da informação (em algumas empresas, ainda existe essa
função) e hoje é um paradigma que vem crescendo na atividade
de desenvolvimento de sistemas, mas que, para muitas equipes, ou
até mesmo para o freelancer, ainda é uma atividade subjetiva, que
depende da psicologia humana.

Toda a disciplina da usabilidade e todas as suas metodologias subjacentes repre­

sentam um conglomerado de várias disciplinas científicas. Por meio da utilização

de ergonomia, psicologia, antropologia e de vários outros campos, a usabilidade

está fundamentada em conhecimento científico. Ela está longe de ser uma forma

de raciocínio subjetiva ou uma conjectura. (Lowdermilk, 2019, p. 21)

Podemos afirmar que o DCU é uma ciência, como veremos no

decorrer deste material, pois ele analisa os requisitos do ponto de vis­
ta de quem vai utilizar o sistema, e não da experiência do time. Para
Lowdermilk (2019), uma das formas de fazer isso é educar a equipe
ou orientar a empresa a respeito da importância dessa atividade.
Contudo, isso está mudando, pois estamos vendo cada vez mais
as empresas de desenvolvimento solicitando feedbacks dos artefatos
em forma de comentários, pontuações ou ações de “favoritar”, ana­
lisando o que as pessoas estão dizendo nas redes sociais e investindo
em inteligência artificial (IA).
Para o profissional que trabalha com DCU, é inevitável fazer
vários questionamentos durante o processo de desenvolvimento:
Será que o resultado será agradável? Dará conforto visual? O usuário
relacionará o artefato à marca do cliente? O usuário chegará ao pon­
to que ele havia imaginado? O número de etapas de preenchimento
do formulário é cansativo?
 19

Quase nada daquilo que é desenhado ou projetado pelo UX designer acaba sendo

"visto" pelo consumidor final. Todos os entregáveis e processos utilizados em User

Experience tem como objetivo facilitar a comunicação entre os membros do time,

documentar decisões que foram tomadas em reuniões e brainstorms, colher insights

sobre aquilo que os usuários finais precisam e/ou garantir que todos estejam alinha­

dos a respeito do que está sendo criado. (Teixeira, 2014, p. 17)

Com isso, o sistema vai criando laços com o usuário, que con­
tinua a utilizá-lo e a compartilhar seu posicionamento referente ao
produto. Para o usuário, algumas situações que revelam um DCU
são: “A sensação é de que realmente fizeram um sistema para mim”
ou “Não encontrei dificuldades para preencher esse cadastro”.
Quando não é adotado o UX design, aumenta-se a experiência
desagradável no uso de um sistema. Nesse caso, o perigo está em
duas ocorrências:

1. Reclamação - Sabemos que informações negativas são disse­

minadas com maior rapidez e, se não foram tratadas, poderão
tomar forma, chegando ao ponto de comprometer o serviço.
A solução disso depende da atitude da empresa de correr atrás
e não dar as costas para o problema, assumindo o erro e procu­
rando consertar os pontos críticos dentro da equipe. Isso pode
demandar mais tempo (o que não acontece se forem adotadas
práticas voltadas ao usuário) de retrabalho e até mesmo a contra­
tação de mais programadores para dar conta dos prazos, além de
reduzir a confiança do cliente dono do sofiware, que pode tratar
a situação como falta de organização e de comprometimento.
20

2. Indiferença - Quando o sistema nâo agrada, há um tipo de

usuário que não volta mais a usar o aplicativo e procura por ou­
tro similar. Por mais que seja uma experiência desagradável, ele
não entra nas redes sociais para tecer comentários negativos, não
“favorita” nem reclama. Simplesmente deixa de usar. Essas pessoas
são tratadas por algumas empresas como as mais preocupantes.
Por que será? Porque eles têm a resposta para a melhoria do
sistema e não divulgam. Alguns relatam que já reclamaram e não
foram respondidos ou que reclamaram e foram respondidos, mas
o aplicativo permaneceu do mesmo jeito.

Um exemplo clássico da fascinação pela tecnologia é o caso dos QR Codes: uma

versão bidimensional dos códigos de barras que virou febre nos últimos anos entre

algumas empresas. A ideia é interessante: basta o usuário escanear o QRCode

usando a câmera do seu smartphone e ele consegue acessar alguma URL "escon­

dida" ali naquele código. Mas o problema é que os QR Codes nunca foram "febre"

entre os usuários - pesquisas mostram que a massiva maioria das pessoas nunca

ouviu falar no termo e sequer possuem um aplicativo que consegue ler QR Codes

instalado em seus celulares. (Teixeira, 2014, p. 166, grifo do original)

O design centrado na experiência do usuário analisa não somente

o que dá certo na utilização do sistema, mas também aquilo que
desagrada a audiência. Os detalhes podem fazer a diferença. Por
exemplo, um botão com cores que contrasta com o restante da pá­
gina chama mais a atenção do que um link, pois uma atividade que
é rotineira, como a ação de clicar, não pode ser tratada de maneira
displicente, ainda mais quando pensamos em telas touchscreen, em
que o ato de clicar é feito com o toque do dedo, e não com o mouse.
 21

As pessoas estão cada vez menos pacientes com páginas que demoram para carre­

gar. Um estudo recente feito pela Universidade de Massachusetts [...] mostra que

usuários perdem a paciência com vídeos após os dois segundos de espera. O mesmo

se aplica a páginas web. Ainda mais se levarmos em conta o fato de que mais e mais

pessoas estão acessando a web através de seus dispositivos móveis: muitas vezes

a baixa qualidade de conexão faz com que a experiência do usuário seja frustrante

ou até catastrófica. (Teixeira, 2014, p. 158)

Deve-se também estar atento aos casos em que o tempo de car­

regamento é superior à paciência do usuário. Muitos deixam de usar
um sistema porque ele é lento, apesar da qualidade da conexão, pois
podem compará-lo com aplicativos da concorrência e, se forem mais
eficientes, com certeza haverá migração.

1.2 Design centrado no usuário e usabilidade

O termo usabilidade, para Lowdermilk (2019), corresponde

ao estudo de como os seres humanos se relacionam com qualquer
produto. Para o autor, as práticas de usabilidade poderíam ser im­
plementadas em tudo, de uma torradeira a uma maçaneta, ou até
mesmo à embalagem de ambos. Já para Teixeira (2014), a usabilida­
de deve garantir que as interfaces sejam fáceis de usar. Para ele, esse
conceito envolve as seguintes questões: O usuário consegue realizar
uma tarefa sem transtorno ou demora? Em um número razoável de
passos? As informações são fáceis de entender? O residual após a ex­
periência é positivo ou o usuário saiu cognitivamente exausto dali?
22

Sobre a usabilidade, Nielsen e Loranger (2007, p. xvi) afirmam:

A usabilidade é um atributo de qualidade relacionado à facilidade do uso de algo.

Mais especificamente, refere-se à rapidez com que os usuários podem aprender

a usar alguma coisa, a eficiência deles ao usá-la, o quanto lembram daquilo, seu

grau de propensão a erros e o quanto gostam de utilizá-la. Se as pessoas não

puderem ou não utilizarem um recurso, ele pode muito bem não existir.

A interação humano-computador (IHC) surgiu na década

dc 1960 e está ligada à usabilidade, mas no que se refere ao uso
de produtos ligados à computação. Preece (2013) esclarece que,
quando os computadores começaram a ser utilizados, foram defini­
dos os primeiros estudos dc interação, porém entre o ser humano
e a máquina diretamente. Esses hardwares foram construídos para
desempenhar funções específicas por operadores que passavam por
inúmeros treinamentos. Por exemplo, um painel de comando em
uma linha dc fábrica ou controladores dc voo eram aplicações das
quais as atividades de IHC cuidavam. Eram as interfaces de hardware
para engenheiros com diversos botões de interação.
Um interessante estudo na área dc usabilidade em IHC foi
conduzido de 1984 a 1986 pela força aérea dos Estados Unidos
e resultou em um guia com diretrizes sobre interfaces com o usu­
ário intitulado Guidelines for Designing User Interface Software:
ESD-TR-86-278. Quem recomendou essa tarefa foi Jakob Nielsen,
nome por trás da Nielsen Norman Group, responsável até hoje por
estudos e publicações na área de experiência do usuário.
 23

0 projeto identificou 944 diretrizes, a maioria das quais relacionadas a sistemas

de comando e controle militar construídos da década de 1970 e no início dos

anos 80, que utilizavam a tecnologia de mainframe. Você poderia pensar que

essas descobertas antigas são irrelevantes para os atuais designers. Se pensou está

errado. Como um experimento, retestamos 60 das 944 diretrizes em 2005. Destas,

54 continuam válidas hoje em dia. (Nielsen; Loranger, 2007, p. 85)

Nielsen e Loranger (2007) comentam que muitas das diretrizes

não foram levadas em conta porque as interfaces eram raramente
utilizadas. Contudo, o que impressiona é que o estudo ainda con­
tinua válido 20 anos mais depois, apesar das mudanças por que
a tecnologia passou.
Lowdermilk (2019) revela que o DCU surgiu do IHC e consiste
em uma metodologia de design de software para desenvolvedores
e designers, a qual auxilia esses profissionais na criação de aplicativos
que correspondam aos desejos dos usuários.
Quando o desenvolvimento é centrado no usuário, as ambigui­
dades são eliminadas até o ponto em que surge a boa usabilidade
e desapareçam as frustações diante das interfaces. Segundo Graham
(2003), a usabilidade contempla os conceitos descritos a seguir.

Feedback
Quando uma ação é realizada, um retorno, também chamado
feedback, sobre os efeitos é esperado pelo usuário e deve ser a ele
apresentado. Por exemplo, uma busca deve gerar resultados expos­
tos na tela e, caso não se encontre nenhum registro, a informação
deve ser visualizada como um simples comunicado de “Nenhum
resultado foi encontrado". Assim, não se deixa o usuário achando
que o sistema está com problemas.
24

Acessibilidade
A informação de que o usuário necessita deve ser encontrada
de maneira rápida e fácil. O sistema deve oferecer os meios para
se localizar a informação de forma simples (o tão famoso “menos
é mais”), sem exagerar - não convém utilizar, por exemplo, plugins
dos quais o usuário precise fazer o download-, há reclamação quando
é preciso instalar algo desconhecido ou que demore para ser baixado.
Outro recurso muito empregado em preenchimentos de cadastros
é dividi-lo em etapas. A informação, quando tratada em partes
menores e relacionadas, suaviza a tarefa, muitas vezes cansativa, de
preencher formulários.

Inclua somente os recursos que ajudarão as pessoas a simplificar suas tarefas.

Quando interações são muito complexas, as pessoas costumam não encontrar as in­

formações necessárias e não se beneficiam do site. Interações complexas aumentam

tanto o tempo de aprendizagem como a probidade de as pessoas se confundirem.

É melhor ter recursos úteis do que muitos inúteis. (Nielsen; Loranger, 2007, p. 384)

Orientação
Os links devem ser descritivos o suficiente para orientar para
qual informação o usuário será direcionado. Um aviso de “Clique
aqui", às vezes, deve ser seguido de um complemento para explicar
ao usuário a que ele terá acesso. Pode-se adicionar, por exemplo,
a seguinte explicação: “Clique aqui para conhecer as promoções!”.
Isso leva o usuário a pensar sobre qual informação será apresentada.
 25

Navegação
O usuário precisa visualizar qual é a estrutura de navegação do
sistema. Seja por meio de texto - o recurso de breadcrumb, que
mostra as páginas com as quais a atual está relacionada seja por
meio do menu, o importante é saber de onde o internauta veio e para
onde ele pode ir. Esse recurso auxilia no momento de uma busca, por
exemplo, quando se é direcionado a uma página em que o usuário
precisa explorar outras seções a partir do resultado. E muito comum
também a personalização do “erro 404”, que deve ser tratada com
links para outras páginas, pois, se não for desse modo, a página
padrão de erro do navegador será apresentada e usuários menos
experientes não conseguirão sair dali facilmente. A navegação deve,
antes de tudo, estar direcionada ao propósito do produto.

Design caótico leva a becos sem saída e desperdício de esforços. Websites prema­

turamente colocados on-line e sem um esquema informacional efetivo impedem

que usuários consigam as informações que eles buscam. Quando isso acontece,

esses usuários podem desistir ou, pior ainda, ir a um outro site. (Nielsen; Loranger,

2007, p. 171)

Outra questão muito atual é o surgimento do conceito de UX

design, utilizado no início dos anos 2000 e que tomou conta dc dis­
cussões em blogs, fóruns, redes sociais e podcasts. Existem até canais
no YouTube especializados em discutir as ações de UX design, com
situações do dia a dia em empresas, e o quanto é necessária a presen­
ça de profissionais envolvidos nessa atividade. Além disso, eventos
acontecem todo o ano com a presença de pessoas importantes dis­
cutindo as práticas adotadas que deram certo e as que fracassaram,
podendo-se, desse modo, aprender com os erros dos outros.
26

UX Design não é direção de arte. Também não é planejamento, não é gerência

de projetos, não é desenvolvimento de software. UX faz o meio de campo entre

todas essas disciplinas, garantindo que todas elas estejam caminhando juntas em

direção a um mesmo objetivo. É o UX designer, por exemplo, que traduz a estratégia

criada pelo planejador em forma de telas e fluxos que serão utilizados pelo usuário.

(Teixeira, 2014, p. 12)

O UX design não está reduzido às funcionalidades de um software,

mas está relacionado ao escopo do aplicativo para tornar a experi­
ência agradável ao usuário o suficiente para mantê-lo conectado
ou voltar a usar o programa. Centrando-se no usuário, aumen­
tam-se as chances de que a boa usabilidade seja atingida. Por isso,
o UX design visualiza em diversos tipos de ferramentas um passo
a passo da interação do usuário com o sistema, desde as ações que
levam a um clique até um relatório gerado com opções de escolha de
tipo de dados solicitados, resultando em gráficos de diversas formas.

As pessoas não experienciam produtos e serviços de uma única vez. Apesar de

o Facebook ser um produto gigante, com uma série de funcionalidades, aplicativos,

páginas e recursos, não é dessa forma que o usuário comum tem contato com

a plataforma. O Facebook é aquela mensagem que um amigo mandou e você

respondeu em poucos segundos. É aquele passatempo de passear pelo seu feed de

notícias no seu celular e curtir um ou outro post de seus amigos enquanto espera

o elevador chegar. É uma notificação que você recebe no meio do dia, e uma foto

que decide compartilhar com sua família. (Teixeira, 2014, p. 93)

Existe ainda o questionamento de que o UX design é subjetivo

a ponto de cada pessoa ter suas percepções a respeito de navegabili­
dade. No entanto, são utilizadas metodologias científicas que geram
 27

estudos interessantes sobre o comportamento dos usuários. Dessa

forma, psicologia, sociologia, ergonomia, antropologia, entre outras
ciências, apoiam as ações das atividades de UX design.
Em 20 anos de pesquisa, a fundação Nielsen Norman Group
publicou cerca de 5 mil páginas de relatórios de pesquisa, ana­
lisando aproximadamente 3 mil capturas de telas de vários sites
com grupos de usuários interagindo na internet. Foram necessárias
equipes multidisciplinares para estudar o comportamento desse
enorme universo, o qual foi analisado pela fundação Nielsen; por­
tanto, não foram colhidas somente opiniões de uma equipe de
desenvolvedores e designers. Vale destacar que não é recomendado
fazer esse estudo do mesmo modo que se faz no caso das pesquisas
de mercado, com formulários para serem preenchidos.

Em vez disso, empregamos métodos de teste de usuário que se baseiam em estra­

tégias observacionais. Damos às pessoas tarefas reais a serem realizadas na Web

e observamos como elas interagem com vários sites. Isso significa que descobrimos

o que os usuários realmente fazem, nâo o que eles dizem fazer. (Nielsen; Loranger,

2007, p. xvii, grifo do original)

Nielsen e Loranger (2007, p. 13) destacam que “Na maioria

dos estudos de usabilidade, as pessoas são informadas de qual site
utilizar, mas essa não é a maneira como os usuários trabalham na
vida real. Assim, também fornecemos uma série de tarefas, e in­
formamos que eles podem visitar quaisquer sites que desejarem”.
Os testes de usabilidade são realizados com aplicação de situações
reais para que o participante analise e dê o feedback sobre como
deve ser uma interface que seja agradável e comprometida com
as necessidades do usuário.
1.3 Design centrado no usuário não é apenas design

A palavra design, presente em UX design, sugere que a comuni­

cação visual, com cores, fontes ou ícones, é o que será levado em
conta. O design nasceu por meio de estudos que ficaram famosos nas
várias fases da história da arte. Com as proporções humanas e as pri­
meiras máquinas idealizadas por Leonardo da Vinci, podemos ver
como o homem procurava a interação com as novas tecnologias,
mesmo que se tratasse de um vislumbre. Os recursos projetados por
Leonardo da Vinci eram sujeitos às necessidades das pessoas, assim
como os sistemas devem ser hoje.

Figura 1.1-Recursos projetados por Leonardo da Vinci

0(1)1115 natvs EFF0F 51T

\(RupT(XTECO ETT aCCWXT]tlX)CO
Ô010F£(i)9VE ^.«5 'lavoaqTi txo,
tOt(x(d feíixx apEFiaw eíxovf
lp5<X, QUOtE <x|i tlXO lt|VEqX0FE
VEFITUT15 ET EXClT(XTU(D

L0FEO) lp5VOT ETTCX

a5Ô010F 51T awET.
ETTa COlftECTETUF
aÔiptscino eIit,
5EÕ Ò0 EIVS(')0Ô
TEcopOr inciôiôviyr
5ai]CVT\a|J0rE et
(XÔ Ô010FE (D(XgT|a
áUç>va. I It Eqico
£FCIT(XT101]

ÒESEFVnT «WCT, C0I15ECTETVF (XÔlpl^Cl

otOVUtuxaqicoi 5^5 çvia »]0n nyroçnxXCT EiV5
 29

Quando a Revolução Industrial instituiu a produção em série,

o design apareceu como atividade de projeto, com produtos voltados
para as pessoas em suas mais diversas variedades, desde um objeto
doméstico até máquinas operadas por trabalhadores e automóveis
com mecanismos acionados pelo motorista. Tudo isso fez surgir a de­
signação desenho industrial, que estava ligado à indústria, ou seja, de
um desenho mecânico a um projetista mobiliário. E essa atividade
foi crescendo conforme as indústrias necessitavam de mais especia­
listas. Nesse sentido, a indústria têxtil se beneficiou da Revolução
Industrial aumentando sua capacidade produtiva.

Figura 1.2 - Indústria têxtil na Revolução Industrial

Everett Collection/Shutterstock
30

Surgiu também a indústria do papel, que produzia para jornais,

revistas, publicidade e fabricantes de embalagens e de rótulos. Esses
impressos precisavam de especialistas em diagramaçâo, composição
de imagens e criação, atividades diferentes das desempenhadas pelo
desenhista industrial, apesar de, no início, esse profissional também
trabalhar com impressos. Toda a criação para documentos era uma
atividade quase artesanal, com o uso de rotuladores, canetas nanquim
e tintas, por isso a semelhança com artistas, já que os meios de produ­
ção em computadores estavam ainda no início e reservados somente
para a arte final nas gráficas e nos bureaus. Alguns elementos tinham
de ser encomendados, como textos e títulos para cartazes para compo­
rem a diagramaçâo, de forma a organizar os elementos e informar com
eficiência. Porém, eles eram colados manualmcnte pelo desenhista
industrial, que, mais tarde, passou a ser chamado de design gráfico.
Com a disseminação de computadores pessoais, a prática do
designer gráfico começou a ser mais eficiente, pois toda a produção
manual, como uso de tintas, fontes e nanquim, foi absorvida pelos
softwares de criação. Os ícones traduzem o que há no mundo real,
como latas de tinta, pincéis, réguas e formas geométricas, que agora
são criados em poucos cliques. O designer assume aos poucos as ati­
vidades de uma arte finalista e de um bureau, com algumas funções
desaparecendo do mercado de trabalho, como a pessoa responsável
pelo fotolito. Agora, as artes são geradas direto para as grandes
impressoras e, com a vinda do Acrobat PDF, todo o processo é oti­
mizado e agilizado.
O trabalho home office é largamente utilizado, pois hoje o designer
gráfico pode trabalhar em casa, bastando, para isso, que tenha um
computador. E não mencionamos ainda os designers responsáveis
 31

por projetar produtos, que também relacionam suas atividades com

o estudo principalmente da ergonomia, ou os criadores de jogos,
que viram na gamificação uma porta de entrada não só para a diver­
são, mas também, por exemplo, para o treinamento de empregados
ou o aprendizado de um novo idioma. Os primeiros computadores
pessoais derrubaram as barreiras entre os usuários e a tecnologia
computacional.
Além disso, surgiu a internet para ampliar as atividades desses
designers gráficos, que, nessa época, começaram a se dividir nos cam­
pos de gráfico para impresso e gráfico digital. No início, muitos dos
conceitos no impresso eram utilizados, com diagramações blocadas
e uma tecnologia que não permitia fluidez, imitando muito as pági­
nas de revistas e jornais ou até catálogos de vendas. Com o tempo,
foi observado que a internet era uma plataforma com paradigmas
totalmente novos, com um dinamismo que foi acelerando com a po­
pularização das conexões em banda larga. Novos conceitos de comu­
nicação estavam surgindo, o consumo de informação foi se alterando
e as empresas viram a real necessidade de entrar no mundo cibernético.
Os dispositivos se diversificaram e, agora, o uso do smartphone
é disseminado entre a população. Um novo termo surgiu: responsi-
vidade — que é a versão adaptada dos sites para versão mobile, antes
criados somente para desktop e notebook. E novamente os designers fo­
ram obrigados a estudar as tecnologias e as linguagens, como HTML
e JavaScript, e a ferramenta de que todos queriam para melhorar
o visual, que é o CSS, responsável pela estilização das páginas.

Páginas que sobrecarregam os usuários com uma profusão de elementos em mo­

vimento, luzes intermitentes e links pobremente estruturados eram uma maldição

no início da Web. Os designers parecem acreditar que, quanto maior o número de

32

detalhes, melhor a chance de que algo atrairía a atenção do usuário. Naturalmente,

o que realmente acontecia era que os usuários saíam desses sites e passavam

o tempo naqueles mais simples. (Nielsen; Loranger, 2007, p. 111)

Dentro da equipe de desenvolvedores, a atividade do designer

é vista, por exemplo, como vinculada à necessidade do uso das cores
da marca do cliente, que é um indicativo de que há na estrutura do
aplicativo uma consistência na identidade visual da marca, e isso
remete à organização do sistema. Um formulário com seus campos
bem alinhados e um botão que chama a atenção para o cadastro
podem estar em harmonia com uma página com poucos elementos.
Imagens em ótima resolução, em contraste com o fundo da página
e em proximidade com elementos relacionados, perfeitamente ali­
nhados, essas são tarefas corriqueiras no dia a dia de um profissional
de design, o que sugere encerrar-se aqui o assunto da obra.
Esses apelos visuais fazem parte do design, mas, quando se trata
de experiência centrada no usuário, isso vai mais além. Junto com
o apelo visual, é necessário avaliar se o usuário encontrou a infor­
mação de que precisava, se as imagens e os ícones são referentes ao
produto ou ao serviço oferecido, se o formulário tem validação ou
recuperação de dados para não precisar ser preenchido novamente
caso haja algum erro. Todas as páginas podem ter elementos de
design atraentes, esteticamente agradáveis, tudo muito bonito, mas,
se não cumprirem com as necessidades do usuário, podem-se esperar
reclamações ou até mesmo o não uso do aplicativo. Muitas vezes,
são buscadas referências de design em sites considerados visualmente
atraentes, mas que se referem a segmentos diferentes daquele a que
pertence o cliente atendido e estão em desacordo com a marca,
o produto ou o serviço.
 33

Mas os tempos mudaram. A linguagem visual das interfaces digitais amadureceu

muito nos últimos anos, foi ficando mais sóbria, flat, com menos elementos decora­

tivos e mais foco em permitir que o usuário realize tarefas com facilidade. O advento

do design responsivo e a necessidade de criar layouts fluidos que se adaptem

a múltiplas resoluções de tela também fizeram com que as equipes aos poucos se

desapegassem do excesso de grafismos e da precisão dos pixels, que passou a ser

alcançável apenas dentro do fantástico mundo do Photoshop. (Teixeira, 2014, p.13)

Outra associação é feita em relação aos softwares utilizados, li­

mitados ao editor de imagem Photoshop, por exemplo, ferramenta
presente nas atividades do designer, que incluem o tratamento de
imagem, de efeitos e de recortes. Logo após a criação do wireframe.
que é a primeira ideia de layout de página que surgiu depois do
contato com o cliente, as interfaces passaram a ser geradas no editor
de imagem. São definidos visualmente as áreas de cada seção, os bo­
tões, a disposição das imagens e do menu, a simulação dos efeitos
e as versões em telas responsivas.

Mas apesar de o nome da profissão conter a palavra "designer", esses profissionais

não necessariamente usam o Photoshop para criar a aparência final do produto

que será visto pelas pessoas. Como projetistas da experiência do usuário, o mais

importante para os UX designers é definir como as pessoas irão interagir com

o produto, quais tarefas conseguirão realizar dentro dele, qual a ordem na qual

as telas serão apresentadas - e por aí vai. (Teixeira, 2014, p. 6)

No editor de imagens, são geradas imagens estáticas, que re­

presentam um passo anterior ao protótipo navegável, quando
ferramentas de prototipagem simulam as páginas, ainda não co­
dificadas, mas que possibilitam, por exemplo, clicar em um link
34

e abrir outra página, preencher formulários e executar alguns efeitos

em JavaScript, e são executadas em ambientes que o usuário vai
utilizar. Essas ferramentas de prototipagem estão aumentando em
diversidade de funcionalidades e podem dar a sensação falsa de que
não se precisa mais codificar o conteúdo. Não é esse o papel dessas
ferramentas, que têm o intuito de simular a navegabilidade, pois
é na codificação que certos atributos são otimizados para serem
implementados nos ambientes corretos.

Na web, como na vida, gritar mais alto normalmente é um tiro pela culatra porque
as pessoas supõem que você não tem nada mais importante a dizer. Os usuários co­

mentam que texto e imagens incessantemente animados são inúteis; portanto, eles

ignoram. Os websites também descobriram isso. (Nielsen; Loranger, 2007, p. 113)

Muitos designers recorrem a sites que exibem as melhores criações

de interfaces, com votação e destaques para designs dignos de premia
çóes, na busca de inspiração para suas criações e para a resolução de
situações de ordem visual. Os melhores ganham lugar de destaque
são copiados e conseguem grande repercussão, havendo um sistema
de votação diário, além de que mensalmente os melhores são expos
tos. Como referência para design criativo são excelentes opções, pois
traduzem o que há de mais moderno e as tendências para o futuro.
Contudo, não se considera o simples fato de ser um site com
merecido destaque e tomá-lo como modelo para criar interfaces
para qualquer outro segmento de público. Não se pode dar o mesmo
peso de um site de busca, que deve ser simples e eficiente ao apresen
tar os resultados, a um sistema web para uma concessionária, com
inúmeras fotos e detalhes dos veículos. São situações distintas e que
 35

merecem o devido cuidado, pois quem sai prejudicado é o usuário

e o cliente que investiu tempo e dinheiro no projeto.
A atividade de design é importante para a execução do proje
to, mas não podemos colocá-la acima de outras funções dentro da
equipe. O pessoal responsável pela entrevista tem seu valor quando
passa para o designers referências do público-alvo entrevistado, com
seu comportamento diante de interfaces parecidas, sua rotina ou
seus relacionamentos. O analista de teste é outra parceria muito
importante para o designer, pois traz os feedbacks após os inúmeros
testes realizados com desenvolvedores e com usuários finais. Eles têm
informações importantes que podem ser alteradas no ciclo de vida
do projeto, eliminando riscos de prejudicar a imagem do sistema
por desagradar o usuário consumidor. Portanto, os membros das
equipes se beneficiam com o feedback do usuário.
Deve ser feito um acompanhamento constante também com
os desenvolvedores que codificam as idéias do design. Hoje, estão di
minuindo as arestas que irritavam os programadores no que se referia
às criações dos designers cuja implementação era considerada muito
complexa. Essa parceria, atualmente, é vista como fundamental, pois
o que está em jogo são o usuário e suas necessidades.

Para o UX designer, mais importante do que conhecer como as tecnologias funcionam

(ou mesmo dominar cada uma delas) é entender como as pessoas interagem com

ela e como elas impactam na experiência do usuário - tanto positivamente quanto

negativamente. Afinal, isso pode ser um fator decisivo quando uma pessoa está

considerando utilizar o seu produto ou o de um concorrente. (Teixeira, 2014, p. 170)

A atividade de design, portanto, não é o elemento central do

sistema. São várias as funções desempenhadas para que o produto
36

atenda ao que o usuário necessita. Essa harmonia na equipe é o que

vai transformar um aplicativo em um produto de sucesso.
Todas as partes dentro da equipe de desenvolvimento são impor­
tantes para a construção de sistemas, e o usuário é parceiro da equipe,

1.4 Design centrado no usuário não

é relatório de problemas

Durante o desenvolvimento de sistemas, os módulos são subme­

tidos a todo tipo de situações de exame, como testes unitários feitos
pelo próprio desenvolvedor e testes de integração com as conexões
entre os módulos. Passa-se pela análise estrutural, em que os códi­
gos são avaliados e é conferido se foram utilizados design patterns
e se o suporte do hardware é compatível. Desenvolvedores testam
sistemas dos colegas de trabalho, submetendo-os à massa de dados
ou usando a criatividade para encontrar suas falhas. Relatórios com
diversos hugs do sistema chegam aos desenvolvedores, são analisados
e discutidos para serem solucionados para não suscitarem retrabalho
após a implementação do sistema final. O mínimo de bugs deve
chegar aos usuários, o que é atingido somente com testes.
Nesse caso, são várias situações que podem surgir. Por questões
de segurança, em uma tela de login, por exemplo, será restringido
o número de caracteres na senha. Nos dados preenchidos de um
cadastro, um código de endereçamento postal (CEP) deve retornar
o endereço do usuário, por meio de um script, que facilita o preen­
chimento dos dados. Uma ação, como uma busca sem resultado, por
exemplo, precisa dar um feedback para o usuário. Voltar para uma
 37

página anterior não deve ser algo restrito à seta do navegador - um

link “Voltar” é esperado ao lado do botão “Cadastrar”, por exemplo.
Uma vez logado, o aplicativo deve iniciar uma contagem limitada
de sessão, para não permitir que outra pessoa visualize dados alheios
por descuido do usuário de deixar aberta a página.
Essas são situações que passam por testes e, muitas vezes, ocor­
rem na utilização dos aplicativos. Alguns podem dizer que os relatos
já fazem parte do estudo da experiência do usuário. Para Lowdermilk
(2019), embora isso seja admirável e, certamente, algo que se deva
fazer, não se deve confundir relatório de bugs com pesquisa abran­
gente de usuário. São informações válidas obtidas em testes, mas que
são carentes, gcralmente, de acompanhamento de quem está lidando
com o sistema no dia a dia.

Ao explorar e fazer perguntas que não estejam relacionadas a bugs específicos,

você poderá descobrir que os usuários estão tentando usar seu aplicativo de uma

maneira que você não tinha percebido. Você poderá considerar a reescrita de alguns

recursos para tornar os fluxos de tarefas mais claros ou, melhor ainda, a discussão

poderia gerar novas idéias sobre como seu aplicativo podería proporcionar mais

valor. (Lowdermilk, 2019, p. 26)

Uma dificuldade do usuário pode ser compreender uma inter­

pretação que ele verificou, por exemplo, em resultados de aplicativos
de análise de sites. Por exemplo, uma dada página não está dando
retorno de quantas pessoas a acessaram, que horas do dia acontece­
ram os acessos ou outro item. São sistemas com muitos parâmetros
e que monitoram diariamente os acessos, com detalhes que podem
ser mal interpretados e que resultam em ações de marketing sem
resultados. Eles demonstram, entre outros detalhes:
38

• o período do dia em que as pessoas mais acessam o sistema;

• o dia da semana em que o usuário está mais conectado;
• os tamanhos de tela em pixel que os usuários usam para acessar
(para estudo da responsividade);
• as versões de sistema operacional mais utilizadas;
• o tempo que os usuários ficam em cada página;
• as páginas mais e menos acessadas.

Essas informações são importantes, mas não estão relacionadas

ao design centrado no usuário, pois estão sendo verificados compor­
tamentos automatizados e que ainda requerem um feedback sobre
por que tal página não foi acessada, por que tal link não está sendo
clicado ou por que uma página com formulário tem alta taxa de
desistência, por exemplo. São ferramentas de apoio para trabalhar
diretamente com o usuário.
Para adquirir um amplo conhecimento das ações do usuário,
um estudo por meio da observação se faz necessário, por exemplo,
analisar seu comportamento diante das telas e a capacidade de medir
o tempo gasto na navegação para atividades que eram consideradas
simples e que se tornaram complexas com mudanças de requisitos.
Assim, cria-se um ambiente propício que reflita a realidade do acesso,
sem se perder em inúmeros relatórios que apontam problemas que
não estão alinhados à prática rotineira do usuário.
Em uma situação de estudo, um usuário não encontra as infor­
mações em seu perfil, julgando que o sistema perdeu seus registros.
A reação mais comum seria procurar no código o erro ou tentar
identificar no banco de dados a inconsistência, já que está dentro do
perfil e não tem outra explicação. Isso pode gerar uma reclamação de
 39

que a página está confusa ou que se perderam os dados, culpando-se

os administradores do sistema. Agora, se o usuário for acompanhado
passo a passo, será possível descobrir, por exemplo, que o perfil foi
acessado com outro login por causa de um erro de sessão, que pode
ser informado por meio de um destaque de seu nome, com uma
frase como “Seja bem-vindo, fulano de tal ”.
Ter um relatório de problemas encontrados durante os testes
é importante, mas quando alinhado com a preocupação de que
o usuário deve estar inserido em todo o processo de testes, pois isso
pode abrir brechas para corrigir e confiar que consertar códigos
mudar botões de lugar ou colorir um fundo é o suficiente para
entregar um produto passível de falhas somente para cumprir prazos
O design centrado no usuário deve fazer parte de todo o processo
visto que sistemas corrigidos no início do ciclo dc vida do projeto
apresentam custos muito inferiores se comparados aos de uma cor­
reção efetuada quando o produto já está disponível no mercado.

1.5 Design centrado no usuário não é perda de tempo

A atividade de DCU requer tempo, pois uma pesquisa estrutu

rada é necessária. Nas metodologias ágeis, que atualmente ocupam
as empresas no que se refere ao ciclo de vida do projeto, é realizado
um briefing a partir do primeiro encontro com o cliente, submeten­
do-o a diversas perguntas, que incluem desde seu objetivo até o uso
da marca, passando pelas análises de sites concorrentes. Materiais
impressos, divulgação e documentos são retidos até a finalização
do sistema para que apoiem sua construção. São registros que estão
40

longe de saber qual será a linguagem de programação, muito menos

como será a codificação. Teixeira (2014, p. 133) cita uma entrevista
com Jared Spool em que se fala sobre o tempo nos testes:

Se você contrata alguém para fazer o seu teste, bem, é mais ou menos como

contratar alguém para curtir suas férias - a tarefa é feita, mas você perde a melhor

parte. Então, o maior investimento em testes de usabilidade não é o dinheiro - que

até pode ser não muito caro. É o tempo. Nossa pesquisa mostra que as equipes

das organizações mais eficazes gastam pelo menos duas horas a cada seis semanas

observando usuários interagirem com seus projetos. Cada membro da equipe.

Com o levantamento de exigências realizado pela equipe de aná­

lise de requisitos, um backlog de atividades será gerado e priorizado,
conforme contato constante com o cliente. Em seguida, a equipe
de prototipagem criará os wireframes com as primeiras idéias de
navegação, que devem ser discutidas exaustivamente. Nessa fase, não
existem links, mas apenas sugestões de fluxo de navegação.
Após essa etapa, as telas serão criadas em um editor de imagem ou
ate mesmo em ferramentas de prototipagem. O design gerará packs
dos principais elementos utilizados nas interfaces: botões, inputs Ac
campos de formulários, ícones e outros elementos visuais. Com os re­
quisitos em mãos, um protótipo navegável será desenvolvido.
Hoje, essas ferramentas, sejam on-line, sejam em versão desktop,
ampliaram o conceito de protótipo. Pode-se, por exemplo, trabalhar
em equipe, compartilhando o mesmo arquivo e criando links navegá­
veis, ou seja, gerar artefatos que podem ser abertos em ambientes fi­
nais, como navegadores, por exemplo, testando a responsividade e os
efeitos preestabelecidos. Nesse momento, é possível inserir o usuário
e sua experiência com o primeiro modelo que está surgindo e colher
 41

as informações que, na alteração do protótipo, não dispensarão

maiores transformações e economizarão o tempo necessário.

Nos últimos anos, os times de UX design passaram a incorporar protótipos em seu

fluxo de trabalho com muito mais frequência. Apesar de os wireframes estáticos

continuarem firmes e fortes, os protótipos surgem para responder a algumas necessi­

dades que se tornaram essenciais no dia a dia do UX designer. (Teixeira, 2014, p. 60)

Nessa etapa, a observação do comportamento do usuário dian­

te das interfaces geradas será analisada. Alguns ambientes gravam
a navegação entre as telas, com áudio do usuário, inclusive, e neles
o registro poderá ser avaliado quantas vezes forem necessárias pela
equipe de desenvolvimento. A geração de protótipos deve ter como
base as necessidades do usuário.
Lowdermilk (2019) destaca que a própria natureza do DCU
exige reflexão e observação. Refletindo sobre o comportamento da
atividade, pode-se pensar em perda de tempo, e a equipe deve estar
concentrando seus esforços na execução das funcionalidades do sis­
tema. Todo esse levantamento será efetivo quando a lista de tarefas
for composta e distribuída para cada membro da equipe.
Outra prática habitual do DCU é questionar o usuário se está
gostando do aplicativo, ou seja, manter um canal de comunicação
aberto. O que pode acontecer é que uma pessoa insatisfeita pode
não voltar mais nem comentar o que a desagradou. E nesse ponto
que muitas empresas falham, pois não conseguem reagir com crí­
ticas negativas, achando que preveem o que as pessoas pensam do
aplicativo e, assim, acabam negligenciando o feedback ao usuário,
construindo sistemas com base no que a equipe ou parte dela acha.
42

Elas acreditam que o usuário não tem o poder de mudar o rumo de

desenvolvimento do programa.

Um dos papéis do UX designer quando está desenhando interações é o de identi­

ficar oportunidades de prestar atenção aos detalhes. Quem trabalha diretamente

com testes de usabilidade sabe o quão gratificante é ver a reação dos usuários

a um detalhe que você pensou com cuidado na hora de colocar na interface. No fim

das contas, é a soma desses pequenos momentos de surpresa e de boa usabilidade

que faz com que as pessoas se apaixonem pelos produtos que usam e se tornem

fiéis a uma marca. E você, como UX designer, tem a possibilidade de melhorar a vida

das pessoas, uma interação de cada vez. (Teixeira, 2014, p. 109)

Como, às vezes, o prazo não é negociável no início, foca-se

no código, por exemplo, utilizando-se frameworks que agilizam
a produtividade e os ganhos para a equipe ou colocando-se mais
programadores no time, o que aumenta consideravelmente o tempo
dc desenvolvimento, já que os novos integrantes precisam passar
por um treinamento para absorver as regras de negócios, os requisi­
tos e os objetivos do sistema.
Nessa área, o que mais surge são as ferramentas. Quando se está
investindo em uma nova linguagem de programação, empregando-
-se tempo para conhecer e obter certificações, uma nova tendência
aparece em um piscar de olhos.

Olhe, eu compreendo isso. Como desenvolvedores, o conjunto de conhecimentos

com os quais devemos nos familiarizar está sempre se expandindo. Novas tecno­

logias emergem, os padrões dos dispositivos mudam e novos frameworks para

codificação surgem diariamente. Em um minuto, você passa a entender todo um

 43

conjunto complexo de APIs e, no próximo, está lendo um artigo em um blog sobre

como ele está ultrapassado, e que uma novíssima API está sendo usada no lugar!

(Lowdermilk, 2019, p. 23)

Trabalhar na área de desenvolvimento é abraçar um cenário de

constantes mudanças. São muitas comunidades espalhadas pelo
planeta, que estudam e compartilham as novas linguagens que sur­
gem. Quando uma linguagem de programação é criada, os grupos
realizam encontros virtuais, documentação, aplicações. Sites como
2 demonstram, por meio de números e gráficos,
Tiobe1 e Built With1
como estão as principais linguagens de programação. E as mudanças
são constantes se colocarmos as novidades em termos de linha do
tempo. Segundo Lowdermilk (2019), entrar no negócio de progra­
mação é concordar, para sempre, que o aprendizado será constante,
e, à medida que as tecnologias se tornam mais complicadas, elas
exigirão mais tempo e investimentos em seu estudo.
Por um lado, existe uma valorização em cima da codificação,
pois ela é o aspecto tangível e, ao mesmo tempo, complexo do de­
senvolvimento. Por outro, deve-se aceitar que estudar o usuário não
é perder tempo, pois ele é a peça fundamental que vai interagir com
as funcionalidades do sistema. Muitos programadores veem seus
recursos como um IDE {integrated development environment) ou
frameworks mais valiosos do que as necessidades do usuário. A em-
patia é o exercício diário e fundamental para criar aplicativos que
atendam de forma completa, e não somente tecnologias ou desig­
ns agradáveis e maravilhosos. Como alerta Teixeira (2014, p. 95),

1 Disponível em: <www.tiobe.com>. Acesso em: 8 dez. 2020.

2 Disponível em: <www.builtwith.com>. Acesso em: 8 dez. 2020.

44

O fato e que poucos designers e desenvolvedores dedicam tempo

suficiente para pensar nos detalhes que fazem um produto ser único -
e deixam passar oportunidades excelentes para melhorar a experiên­
cia dos usuários em sua manifestação mais granular e corriqueira ”.
Na verdade, ganha-se tempo quando o desenvolvimento é cen­
trado no usuário. Ao se colocar o foco nas tecnologias, muitas fun­
cionalidades se perdem quando há distanciamento dos requisitos
levantados com o cliente, correndo-se o risco de elevar os custos, pois
se perdeu tempo em implementações que nâo atenderam ao escopo.

Se implementado corretamente, o design centrado no usuário, na realidade, pode

fazer você economizar tempo. Ao compreender as necessidades dos usuários, você

evitará equívocos e erros que podem sair caros. Lembre-se de que refazer sua aplica­

ção porque você não atendeu às expectativas de seus usuários também representa

um desperdício de tempo! (Lowdermilk, 2019, p. 25)

Outra dimensão que deve ser trabalhada é a ideia de que, quanto

mais tempo a equipe estiver codificando, mais perto do resultado
a ser entregue ela estará, ignorando as decisões centradas no usuá­
rio. Quando se está programando, uma série de requisitos está em
jogo, pois as funcionalidades implementadas devem seguir o escopo
apresentado no início, após reuniões com o cliente. De certa forma,
os desenvolvedores responsáveis pela codificação já estão habituados
com as práticas da linguagem de programação adotadas e alinha­
das com as plataformas exigidas. Então, naturalmente, a equipe
passa a maior parte do tempo decidindo qual ou quais linguagens
e frameworks serão adotados e, em questão de manutenibilidade do
código, se o produto tem fácil aceitação no mercado para possíveis
revisões e atualizações.
 45

UX Design também não é uma disciplina de um software ou linguagem só. Podem

até existir UX designers especializados em desenhar sites em HTML, ou aplicativos

em C++; mas por ser centrada no comportamento humano, a teoria que estrutura

o trabalho desse profissional é agnóstico de código, plataforma ou tamanho de

tela. (Teixeira, 2014, p. 12)

Talvez isso venha da cultura que foi criada de que os designers

se preocupam com a estética dos aplicativos, e não com o valor
que o produto tem na própria codificação. Antes, alguns atritos
existiam no decorrer do desenvolvimento, quando o criava
os protótipos com o editor de imagem, meticulosamente alinhados
e com apelos visuais fascinantes. Muitas interfaces eram prototipa-
das por designers gráficos que tinham experiência no impresso, em
que os elementos eram dispostos sem a necessidade de um hackend.
Quando chegava às mãos dos desenvolvedores, muita coisa não era
reproduzida, pois eles julgavam as criações muito complexas para
serem codificadas, o que gerava embates, visto que o layout não
era seguido fielmente.
Em alguns lugares, ainda encontramos essas situações, po­
rém desenvolvedores e designers devem se alinhar para encontrar
o equilíbrio, que são as decisões centradas no usuário. Elas serão
as norteadoras do produto lançado no mercado e, talvez por isso,
hoje em dia as interfaces estão diferentes em relação ao que eram
há 10 anos - estão mais clean, com elementos que realmente são
necessários à navegabilidade, pois muitos estudos foram realizados
nesses últimos anos, por exemplo, pelo Nielsen Norman Group, que
mantém um site com diversas informações para quem quer sistemas
mais comprometidos com o usuário.
COMO TRABALHAR
COM O USUÁRIO
 49

O processo de desenvolvimento de um sistema está longe do

entendimento da maioria dos usuários. Conta-se com várias eta­
pas para se chegar a um artefato de sucesso e depende-se de uma
equipe multidisciplinar. Cada atividade dentro desse time deve se
ater às informações coletadas por meio das entrevistas com usuá­
rios. Estes, não tendo conhecimento de todo o processo, podem
fazer solicitações às quais o aplicativo não vai conseguir atender,
e a experiência da equipe vai apresentar a eles o que realmente pode
ser desenvolvido.

Outro cenário comum é o de o time receber um briefing do cliente que já possua

a solução técnica definida. "Precisamos criar um site responsivo para nossa marca"

ou "precisamos criar um aplicativo de celular para nossos prospects". Mas será

que aquela é realmente a melhor solução técnica para o problema da marca e do

usuário? Será que as pessoas estão dispostas a baixar um aplicativo da marca só

para conseguirem consultar o preço dos produtos, por exemplo? O ideal, nesses

casos, é que o time se reúna para discutir se aquela solução é realmente a melhor

opção para aquele produto. (Teixeira, 2014, p. 168)

Contudo, não podemos tratar o usuário como uma peça fora

do processo, mesmo que ele não entenda sohre o desenvolvimento
de um aplicativo. Deve-se inseri-lo como elemento-chave, alguém
que trará as informações necessárias, e não partir de suposições e de
pesquisa de produtos concorrentes. O usuário deve ser aquele que,
depois de o aplicativo ser entregue, sente-se parte da construção
e considera que o caso de sucesso teve sua participação, pois ele for­
neceu diretrizes para o desenvolvimento. Assim, ele deve constatar
que o produto é realmente agradável de ser usado.
50

Por que produtos ou serviços digitais similares fazem mais sucesso do que outros?

Um fator de peso está na relação entre o usuário e o produto. Nesse mundo conec­

tado em que vivemos, cada vez mais ganha força o que considero antropocentrismo

digital: o usuário é o rei. Se ele não tem uma boa experiência com o produto digital,

ele deixa de utilizá-lo e migra para interfaces mais inteligentes, agradáveis e de

fácil uso. E o diferencial do produto ou serviço digital pode residir justamente ali.

(Teixeira, 2014, p. i.)

Neste ponto, já deve estar claro que os desenvolvedores precisam

ter um olhar diferenciado do usuário sobre o produto, levando em
conta, por exemplo, que na ação de busca de um sistema ou do nível
de jogabilidade de um aplicativo pode haver caminhos mais simples
do que a equipe havia imaginado. Sem essa relação de equipe com
o usuário, corre-se o risco de ter de dedicar horas de trabalho e de
retrabalho que não estavam previstas no cronograma.
Mas como alinhar um aplicativo idealizado pelos usuários com
o que a tecnologia no momento oferece? Para isso, é preciso ter
a atitude de realizar diversas e criativas perguntas caso se esteja ini­
ciando o projeto ou estudar o comportamento do usuário diante
de um aplicativo já desenvolvido, pois a tecnologia nunca chega
a todas as classes ao mesmo tempo. Pode não ser o momento de
inserir certo programa no mercado porque em um ambiente a tec­
nologia pode estar disseminada, mas em outros segmentos pode
estar ausente, dependendo de inúmeros tutorials e de um manual
do usuário complexo.

É só nessa hora que termos como "SMS", "Bluetooth" ou "HTML" deveriam

começar a surgir na mesa. Desenvolvedores e profissionais com background mais

técnico podem assumir um papel importante nessa hora: por conhecerem de cabo
 51

a rabo as tecnologias disponíveis no mercado, é mais fácil para eles definir quais

delas podem ser utilizadas na solução.

Nesse momento, o papel do UX designer é garantir que as tecnologias façam sen­

tido para as pessoas e para o contexto onde o produto será utilizado. Afinal, você

não vai querer criar um aplicativo de smartphone para consumidores de classe D e E,

que raramente têm acesso a esses dispositivos; ou mesmo criar um site mobile para

ser acessado dentro de um shopping center, onde muitas vezes o sinal de internet

das operadoras de celular é fraco e insuficiente para garantir uma boa experiência

do usuário. (Teixeira, 2014, p. 167)

E quando a equipe nâo tem acesso aos usuários para que seus
comportamentos possam ser estudados? Talvez, por acharem que
é oneroso ou não terem alguém tão próximo que possa analisar
as idéias geradas, muitos acabam passando por cima da avaliação
que os usuários possam fazer. Sobre isso, Lowdermilk (2019) dá
um conselho: se uma empresa não estiver desenvolvendo um apli­
cativo para um cliente ou para um grupo de usuários específico,
então é melhor encontrar um.
Hoje, com o acesso à internet disseminado, muitas pessoas estão
com seus perfis ativos nas mais diversas redes sociais. O mundo
globalizado aproximou cidades e países, e as informações chegam ra­
pidamente, diferentemente de como era antigamente. Nosso círculo
de contato ampliou-se, e podemos nos comunicar com ferramentas
que incluem texto, imagens e vídeos. E muitas delas permitem a cria­
ção de formulários, com configurações acessíveis e diversificadas,
gerando relatórios em forma de gráficos, ou comportam gravadores
de telas que analisam a navegação e um mapa de cliques. Acerca des­
sas ações, Nielsen e Loranger (2007) sugerem aos desenvolvedores
52

manter os usuários no centro de seu projeto de design, escutando-os

com humildade, pois eles tornarão o aplicativo bem-sucedido.
Podemos encontrar casos de desenvolvedores que criaram apli­
cativos com boa repercussão entre os usuários e que dizem que seus
produtos surgiram com uma grande ideia inspiradora. Isso leva
a maioria a acreditar que um insight é possível; fica então esperando
o momento em que a grande solução chegará ou permanece sen­
tado em uma lanchonete, onde um guardanapo e alguns rabiscos
trarão à existência o programa que será levado ao top of mind dos
aplicativos. Quando vemos casos de sucesso na área de aplicativos,
não temos ideia clara dos bastidores de sua criação até o produto
final, pois nosso foco está no auge dentro do mercado de software.
Ao acompanharmos o lançamento da Nave Dragon Crew, da
empresa SpaceX em parceria com a Agencia Espacial Americana
(Nasa), e seu acoplamento à Estação Internacional, presenciamos
o momento da comemoração, que, na verdade, é uma parte de todo
o projeto. No entanto, não tomamos conhecimento dos fracassos
e das vitórias que ocorreram durante o processo, das palavras de de­
sânimo proferidas - sim, podemos estar cercados de pessoas que não
acreditam e não apoiam o trabalho dos outros, ainda mais quando
estão em evidência.

Em outras palavras, é fácil olhar para produtos como Google, Facebook, Twitter,

Amazon, Groupon (e isso e aquilo) e pensar que a criação de urn software tern

a ver somente com uma grande ideia. Acreditamos, erroneamente, que, assim

como ocorreu com Newton, uma maçã caiu da árvore e acertou a cabeça desses

desenvolvedores, dando início a uma revolução digital, como num passe de mágica.

Então, vejo desenvolvedores esperando que uma maçã lhes caia na cabeça e penso
 53

comigo mesmo: "Sabe de uma coisa? Se eles simplesmente gastassem algum tem­

po com as pessoas, provavelmente chegariam mais rapidamente a algum lugar”.

(Lowdermilk, 2019, p. 32)

Existem situações com as quais o usuário passará a entender

de forma diferente o acesso às informações ou ao lazer com o apli­
cativo, porém são idéias pessoais e que não têm, por exemplo,
tecnologia que dará suporte conforme elas se apresentam. Quando
se abre um leque de opções em entrevistas ou em observações,
alguns imaginam condições que fogem da realidade, precisando
de orientação da equipe, que dará alternativas apontando as tec­
nologias e os suportes mais adequados.
A expectativa de muitos usuários sempre superestimará o co­
nhecimento da equipe de desenvolvedores, os quais são envoltos em
auras como personagens de séries científicas quando conseguem de­
cifrar enigmas usando a tecnologia ou a habilidade transferida para
o mundo real, tornando comum o fato de que são nerds e sempre
têm resposta para quaisquer questões que envolvam novos sistemas.
Daí a ideia de que tudo pode ser colocado na produção de um
aplicativo, pois, para a tecnologia, não há limites.
Então, o que fazer diante do fato de que se podem frustrar
as intenções de um usuário chamado para ser parceiro no processo
de desenvolvimento de um aplicativo? Lowdermilk (2019) explica
que não se podem descartar as idéias malucas de um cliente, mas
orientá-lo de forma cuidadosa e quem sabe aproveitá-las de outra
maneira e dar valor ao que antes era considerado absurdo. Esse
cenário acontece, muitas vezes, em sessões de brainstorm, quando
os participantes passam por um período de geração de idéias que
54

fogem da censura por parte dos colegas, surgindo propostas até

mesmo irracionais que, logo depois, o moderador passa por um filtro
junto com todas as sugestões, opinando e selecionando as melhores.
Segundo Lowdermilk (2019), certa vez ele gastou trinta minutos
somente com uma pergunta para garantir que havia recebido as in­
formações corretas. Se um usuário estivesse fornecendo informações
das quais ele não necessitava, explicava educadamcnte por que essas
informações são seriam úteis.
Muitas vezes, o usuário passa informações com as quais a equipe
de desenvolvimento não tem nenhuma familiaridade. Pode ser que
o cliente deseje introduzir uma gamificação no treinamento dos co­
laboradores de uma empresa sobre um assunto totalmente estranho
à equipe ou, então, criar uma realidade virtual ou uma realidade
aumentada dentro de uma sala de aula, que será um suporte ao apren­
dizado dos alunos e uma ferramenta pedagógica para os docentes, caso
cm que precisaria de ajuda externa de uma pedagoga, de professores
da matéria e até mesmo de estudantes. Assim, a necessidade do usu­
ário vai além do que se conhece, não somente em termos de nave­
gabilidade, mas também do tema a ser tratado no escopo do projeto.

Qual é seu público-alvo - profissionais de TI, jovens, pais com crianças em idade

escolar? Identificar seu público-alvo o ajudará a comunicar idéias de maneira efi­

ciente e o manterá concentrado no assunto e tom corretos. Seus leitores querem

conteúdo que satisfaça sua procura, fale no mesmo nível deles e em um tom com

o qual eles possam se relacionar. (Nielsen; Loranger, 2007, p. 259)

É um exercício de sair da redoma em que se fecham muitos

círculos de desenvolvedores e designers e admitir ao usuário que não
se tem conhecimento do assunto, mas uma equipe comprometida,
 55

que investirá tempo na busca de mais informações e direcionara

corretamente a execução do trabalho de todo o time.
A experiência centrada no usuário pressupõe projetar um pro­
duto com base nas necessidades de quem vai consumi-lo, e não
pensar na tecnologia e, em seguida, no que o usuário quer. Steve
Jobs sempre preconizou que se deve deixar simples o que poderia
complicar a vida das pessoas. Isso significa pensar diferente. Um
curso de criação de tipos na faculdade foi o despertar para Jobs
pensar em telas de computadores mais bonitas que estimulariam
os usuários a ter um computador pessoal, diferentemente do pa­
drão computacional da época. Assim, Jobs e Steve Wozniak criaram
computadores pessoais que poderíam ser utilizados em casa ou no
trabalho, o que representou um estímulo para que outras empresas
também pegassem carona na nova realidade dessa tecnologia. Em
seguida, outros dispositivos vieram, como tocadores de música,
smartphones e tablets, com design simples e muitas funcionalidades.

Em geral, as diretrizes de usabilidade para adolescentes são um pouco diferentes

daquelas para adultos, e as diretrizes para crianças são ainda mais. Há certamente

várias semelhanças, mas se você quiser atingir usuários mais jovens, recomendamos

que conduza estudos de usuários separados dessa faixa etária. (Nielsen; Loranger,

2007, p. 184)

A visão de mercado da Apple sempre foi facilitar as tarefas

para os usuários, e não complicar ou criar problemas no uso de
seus dispositivos. E isso pode incorrer no erro de um produto
malsucedido, quando se deixa de ouvir o usuário e de atender
às suas necessidades.
56

2.1 Diferentes tipos de usuários

Segundo a obra Design centrado no usuário, de Travis Lowdermilk

(2019), há diversos tipos de usuários, e a estratégia é ouvi-los e ser
flexível em face dessa diversidade de estilos. São tipos com os quais
o autor está acostumado a se deparar.

2.1.1 O informante exagerado

O informante exagerado é aquele que junta pilhas de papéis

que julga necessários para as reuniões. Nos e-mails, coloca o maior
número de informações, muitas vezes descontextualizadas ou que
se caracterizam mais como compromissos pessoais. Isso tudo em
mensagens enviadas por áudio sobre etapas que ainda ocorrerão, sem
que o projeto tenha sido iniciado.
Esse tipo de usuário é aquele que compartilha as informações
fora da equipe e, se alguém comenta algo que não estava alinhado
ao processo de desenvolvimento, fica preocupado se essa ideia vai
fazer falta e a leva para a equipe. Manda uma mensagem detalhada
da novidade ou marca uma reunião que paralisa o time, mudando
inúmeras vezes o contexto, julgando que são adaptações que não
exercem o efeito de desacelerar o trabalho.
Seu desafio é não ser um estraga-prazeres ou chegar a não dar
retorno sobre aquelas informações que o time não considera úteis.
Na verdade, um usuário com essa característica é importante, pois
alimenta o processo. Primeiramente, deve-se orientá-lo para que
saiba como repassar as informações pelos canais adequados, como
 57

um banco de dados que será tratado pela equipe, deixando-a seguir

o fluxo do trabalho sem tantas interrupções.
E preciso avisar a esse tipo de usuário que todas as informações
enviadas por aplicativos de mensagens instantâneas devem ser no for­
mato texto, pois, como áudio, dependendo do sistema, fica difícil rea­
lizar uma busca, caso algum detalhe esteja em uma dessas mensagens.
Trata-se de uma pessoa que sempre está querendo se adiantar
às etapas, devendo ser orientada a permanecer no foco para que
as prioridades do momento sejam concluídas. Pode-se explicar a ele
que as informações serão tratadas futuramente, se fizerem parte do
escopo. E uma tarefa contínua trazê-lo à realidade do trabalho atual
da equipe. Uma atitude sugerida é manter esse usuário informado.

Acho que fornecer atualizações de status por e-mail é uma ótima maneira de

lembrá-lo do foco. Eu crio compromissos recorrentes no calendário para garantir

o fornecimento contínuo de informações atualizadas aos usuários sobre seus pro­

jetos. Essa é uma abordagem mais proativa, por meio da qual faço contato com

eles antes que sintam a necessidade de vir me perguntar. Também ajuda a reservar

um tempo para parar e refletir sobre o que já foi realizado e o que ainda deve ser

feito. (Lowdermilk, 2019, p. 38)

A quantidade de informações que o informante exagerado re­

tém está ligada à empolgaçáo de ver o sucesso do produto. Ele está
finalmente ajudando alguém e precisa da paciência do time no que
se refere a simplesmente ouvi-lo e ser-lhe grato no recebimento das
informações. Na verdade, ele é um cliente e deve ser valorizado.
58

2.1.2 O obcecado por controle

Segundo Lowdermilk (2019), o usuário obcecado por controle

quer se envolver em todas as decisões sobre o projeto e não pode
perder nenhuma reunião, ou seja, deseja manter-se informado
sempre. Sua imposição acaba atrasando o trabalho da equipe ou
acalorando as discussões entre os membros. Quando se sente fora do
controle das atividades, reclama e mostra que está insatisfeito, pois
sua característica é dar ordens aos demais.
Isso tudo demonstra, na verdade, uma insegurança que essa
pessoa sente em relação à equipe e aos resultados que o sistema vai
oferecer, já que ainda não foi lançado. Algo pode ser feito para tratar
esse usuário: marcar uma reunião particular e mostrar que o que
está em jogo é o sucesso do aplicativo, e esse é o desejo de toda
a equipe. Assim, ele pode questionar a falta de presença contínua no
processo, então esse é o gancho para mostrar como ele pode ajudar,
apresentando os momentos nos quais ele será de grande auxílio.
E necessário levantar as opções concretas de que esse usuário não
terá grande impacto de decisão no processo, apresentando-se a ele
um número reduzido de itens, já que, se for uma lista com muitos
tópicos, haverá uma grande chance de estes serem desmembrados
em subitens, abrindo-se brecha para mais discussões.
Sentir-se incluído no processo faz parte da característica do
indivíduo que deseja o controle em toda a reunião em que esti­
ver. Por isso, não se pode esquecer de direcionar a ele as perguntas.
Porém, se a discussão sair do foco, deve-se trazê-lo para o centro
da discussão. E preciso sempre ter em mente que todos devem ser
ouvidos, pois, assim, cria-se um ambiente favorável até para aqueles
 59

que se sentem mais tímidos, mas podem ter idéias valiosas. Esse
usuário tem de ser visto como fornecedor de valiosas informações
pelo seu profundo conhecimento, devendo-se considerar que tem
atitudes impositivas talvez por ter trabalhado em equipes nas quais
não foi bem recebido.
Outra forma de manter uma parceria com o usuário obcecado
por controle é deixá-lo com as partes mais críticas das avaliações, pois
são etapas que necessitam de um maior envolvimento e controle de
detalhes. Sempre se deve mostrar a duração do tempo que será dispo­
nibilizado para que ele visualize que há um limite para sua conclusão.
Esse é um tipo de usuário crítico com o próprio uso do aplicati­
vo e que observa a ação de outros clientes, fornecendo alternativas
para situações críticas que surjam durante a avaliação. Por isso, ele
deve ser valorizado pelo seu alto nível de comprometimento com
o projeto; assim, vai se sentir como membro da equipe.

2.1.3 O advogado do diabo

Existe uma prática mostrada por Lowdermilk (2019) em que

os membros das equipes ou usuários personalizam papéis durante
o processo de desenvolvimento de um sistema. Por exemplo, há um
tipo de participante que chega à reunião com uma nuvem escura
sobre sua cabeça, o chamado advogado do diabo, que, com suas
atitudes, profere palavras de desencorajamento e assume papel dife­
renciado na equipe. E uma ferramenta explorada na obra As 10faces
da inovação, de Tom Kelley, em que a exposição das pessoas é atrelada
ao tipo de usuário sugerido. São eles:
60

• Antropólogo - É aquele que tem a mente aberta para novas

idéias e percepções. Sempre procura conversar com as pessoas,
estudar o envolvimento do usuário de forma física e passional
com os artefatos. Aprende a ouvir sua intuição e deduzir pelos
fatos. Investiga até as idéias descartadas pela equipe.
• Experimentador - Tem a característica de dar forma ao que
antes era inatingível e sugerir novas práticas. Cria protótipos
sujos (feitos rapidamente com rabiscos e com baixa fidelidade,
ou seja, qualquer suporte físico serve). E excelente na hora de
economizar e otimista. Gosta de ver pessoas experimentando
suas idéias sem se deixar levar pelos detalhes, mas pelo escopo.
Divide os problemas que aparentemente são maiores.
• Polinizador - Investiga o ambiente de outros setores e examina
o que pode ser adaptável para o produto a ser desenvolvido.
Não retém as descobertas e compartilha tudo. E eclético em
apreciar a vida e registra tudo por escrito. Utiliza metáforas para
apresentar suas idéias.
• Saltador de obstáculos - Para ele, as adversidades no caminho
são oportunidades para desenvolver um produto bem-sucedido.
Ele busca por uma solução nunca utilizada antes e, por isso, gosta
de assumir riscos. Segue o lema “Menos é mais” e tem iniciativa.
Enfrenta um “Não!” com bom humor, acredita nas idéias que
defende e sai da zona de conforto do cargo que exerce explorando
novas atividades.
• Colaborador - Quer reunir todos os estilos de pessoas para um
bem comum. Passa por cima dos próprios ideais para que o pro­
jeto tenha sucesso. E proativo, típico dos que ajudam a arrumar
 61

a sala de reuniões antes que cheguem os participantes. É inspira­

dor e transmite confiança. Delega tarefas e motiva a todos a com­
partilhar suas idéias.
Diretor - Preocupa-se em levar a equipe ao sucesso do produto.
Gosta de mirar-se nos próprios exemplos, mas cede espaço para
os colegas. Como na fábula da formiga e do gafanhoto (em
algumas versões, cigarra), ele sabe das dificuldades que podem
surgir e se prepara. E visionário, usa o brainstorm para gerar
idéias e prepara o ambiente ideal para a inovação.
Arquiteto de experiências - Trabalha com todos os sentidos para
sair da mesmice de produtos monótonos para aplicativos com
a melhor experiência. Mapeia toda a jornada do usuário e pro­
cura sair do lugar-comum criando produtos únicos. Quer co­
nectar-se com as necessidades dos usuários, tanto as evidentes
quanto aquelas ainda a descobrir.
Contador de história - Ele converte pessoas reais cm heróis da
mitologia. Quer os membros da equipe coesos e trabalha míni­
mos detalhes na contaçáo de história. Aposta que as histórias
constroem a característica do grupo c do produto.
Cuidador - Leva ao máximo os cuidados com o cliente. Sabe
muito bem o que quer e o que o usuário deseja. Conhece
a visão tecnicista e promove o humanismo. Prefere mostrar
ações aos colegas a simplesmente relatar. Não é fã dos jargões
profissionais porque acredita que eles não levam ao entendi­
mento do que é simples e útil. E cativante e quer um ambiente
seguro para o usuário.
62

Essas características, também chamadas de personas., afastam

aqueles membros que querem acabar com a ideia antes mesmo
do início do desenvolvimento ou tumultuar o processo. Pode-se
encontrar resistência, é claro, pois o advogado do diabo assume
que tem funcionalidades que não serão aceitas ou serão difíceis de
serem realizadas. Contudo, é uma forma de doutriná-lo, para que
em algum momento ele possa assumir um papel de motivador da
equipe e “pôr a culpa" na persona que assumiu.

Portanto, em vez de ouvir "Deixe-me fazer o papel de Advogado do Diabo por

um momento; se mudarmos o sistema de menu, nossos usuários ficarão confusos

e frustrados", você ouvirá "Deixe-me fazer o papel de Antropólogo por um momen­

to. Venho observando nossos usuários utilizando o sistema atual de menu, e eles

já estão confusos e frustrados!". (Lowdermilk, 2019, p. 40)

Há um clichc que define uma característica de certos tipos de

usuários: quando o copo tem água pela metade, o otimista diz
que ele está meio cheio; já o pessimista afirma que está meio vazio.
Ou seja, sempre aparece o tipo dc usuário que foca somente o que
está errado e não enxerga as conquistas da equipe. Quem está no
lado que encara os desafios tem de criar uma proteção em volta que
resiste a esses tipos de pessoas que criticam o trabalho dos outros.
E não é uma tarefa fácil ficar motivado envolto por tanto negativis­
mo que se apodera de uma equipe.
Existe uma polêmica em torno do estado da arte para um apli­
cativo, ou seja, quando não há necessidade de alterações ou revisões.
Como desenvolvedor, deve-se sempre assumir uma postura otimista
em relação ao que se está buscando em termos de aplicativo ideal.
O foco sempre deve ser o de que, com esforço, o time encontrará
 63

respostas para os anseios do usuário. Aqui, muitos podem afirmar

que é uma maneira idealista de encarar, até mesmo fantasiosa, mas,
se não houver enfrentamento de situações negativas, a equipe estará
contaminada e o projeto ameaçado.
As ações dos desenvolvedores estão sempre voltadas à administra­
ção dos bugs que ocorrem. São erros no código que devem ser con­
sertados, o que confere um esforço que toma conta, frequentemente,
de horas de retrabalho. Muitas vezes, isso se torna corriqueiro, o que
pode somar-se ao fato de as questões negativas virem à tona. Assim,
a equipe acaba se concentrando mais no que não está funcionando
do que nas funcionalidades que atendem às necessidades do usuário.
Com relação à postura positiva quanto aos resultados do projeto
de um sistema, Lowdermilk (2019, p. 41) afirma:

Deixe-me esclarecer. Não estou sugerindo que procurar erros seja algo negativo.

Devemos estar focados em encontrar erros ou identificar tarefas que não este­

jam funcionando. Isso é essencial no processo de desenvolvimento de software.

Contudo acho que podemos equilibrar nosso tempo para incluir a avaliação de

aspectos que estejam funcionando. Há muito que aprender com nossos erros, mas

há muito que aprender com nossos sucessos também.

O autor defende uma postura de mais comemoração nas reuniões

sobre as conquistas para trazer motivação no enfrentamento dos de­
safios (Lowdermilk, 2019). Muitos podem estar sofrendo em equipes
que não reconhecem o sucesso de cada item do checklist concluído,
pois julgam, por exemplo, que resolveram bugs cruciais, mas que isso
é visto apenas como obrigação no desempenho de sua atividade. O ris­
co está em perder ótimos profissionais para empresas que apostam na
valorização dos resultados que atendem às necessidades do usuário.
64

Uma equipe pode ter grandes resultados na elaboração de inter­

faces para um aplicativo de jogo que está fazendo sucesso nas lojas
virtuais. Entretanto, em um projeto de gamificação para aulas vir­
tuais do ensino fundamental, a equipe pode estar tendo dificuldades
em gerar um layout que atenda às necessidades dos estudantes. Por
que não trazer o sucesso daquele aplicativo de jogo para um sistema
que atende ao aprendizado?
Um mecanismo de acompanhamento do feedback dos usuários
são os comentários feitos em sites especializados cm reclamações e nas
redes sociais. Também em lojas de aplicativos o usuário tem a opor­
tunidade de favoritar ou de redigir um texto comentando o que está
achando do produto, pois alguns têm a tendência de olhar para os co­
mentários que criticam c correm para resolver, esquecendo-se de que
muitos elogiam, o que deve ser compartilhado com todos na equipe.
Pode ser uma atitude de cuidado em entregar algo perto do ideal,
porém devem-se valorizar as conquistas no mesmo nível de críticas.
Sutherland (2014) comenta:

Um grande exemplo que os autores usam é a submissão de um artigo para pu­

blicação em um periódico. Digamos que o primeiro editor do periódico o rejeite.

Então, o autor submete aquele mesmo artigo para a publicação em um segundo

periódico. Esse segundo editor, ao saber da primeira rejeição, fica mais propenso

a rejeitá-lo também. E, se houver um terceiro periódico, aquele editor, sabendo

das suas rejeições anteriores, ficará ainda mais propenso a fazê-lo. As pessoas

presumem que as outras pessoas fazem julgamentos legítimos, mesmo que tais

julgamentos contradigam o seu próprio. Isso é ruim.

O autor exemplifica a influência sobre aqueles que não têm jul­

gamento próprio a respeito do mundo e acabam sendo influenciados
 65

pelo que os outros opinam (Sutherland, 2014). Ele cita a obra Uma
teoria sobre modismos, moda, costume e mudança cultural como cascatas
informativas, de Sushil Bikhchandani, David Hirshleifer e Ivo Welch,
que basicamente traz um relato de que, para certos indivíduos, as in­
formações em cascata são benéficas, pois observam o comportamen­
to de uma pessoa, julgam ser o ideal e o copiam, mas não analisam
os próprios julgamentos.

2.2 Planejamento e definição do projeto

Para entregar um sistema com um design centrado no usuário,

deve haver uma mudança dc paradigma, focado nas necessidades do
indivíduo que será beneficiado. Toda a equipe precisa estar antenada
e comprometida nessa nova visão, e não simplesmente colocar o projeto
para ser desenvolvido como o era antes. Também deve ocorrer a cons­
trução dc uma documentação formatada durante todo o processo.
Quando se começa o planejamento, cada membro da equipe deve
se fazer algumas perguntas: Onde ele está inserido nesse novo desafio?
Quais são as limitações e como ultrapassar as barreiras desse novo
paradigma que é um design centrado no usuário? Quais são os bene­
fícios de ter o usuário como parte do desenvolvimento do sistema?
Para que um novo padrão seja adotado, é necessário criar ferra­
mentas que sejam um modelo utilizado pela equipe e que sempre
seja referência às necessidades do usuário. Quando o produto está
sendo desenvolvido, muitas ações podem ocorrer em paralelo:
os projetos que devem ser iniciados; aqueles que saíram de stand-by,
o cliente que quer retomar a produção depois de um período de
66

interrupção; um outro que deseja marcar uma reunião de emergên

cia e alterar o processo produtivo dos membros da equipe. No final
disso tudo, deve-se retornar ao ponto no qual houve a interrupção
e recorrer ao modelo de referência que norteia os próximos passos
E uma prática que coloca toda a equipe caminhando, novamente
na mesma direção.

- O senhor poderia me dizer, por favor, qual o caminho que devo tomar para

sair daqui?

- Isso depende muito de para onde você quer ir, respondeu o Gato.

- Não me importo muito para onde... retrucou Alice.

0 Gato disse:

- Então não importa o caminho que você escolha. (Carrol, 2011, p. 59)

E uma triste constatação, mas equipes sem um plano vivem

como Alice nesse trecho da obra Alice no País das Maravilhas, de
Lewis Carrol’, sem rumo, e a direção que acham melhor é a mais
correta. E até mesmo na realidade em que alguns desenvolvedores
trabalham, como freelancers, ter um planejamento vai guiá-los e eles
não serão pegos de surpresa por cobranças de uma prioridade dei
xada de lado. Planejamento não quer dizer que tudo será realizado
dentro do prazo, mas, quando algo sair do roteiro, será mais rápido
e eficiente corrigi-lo. Um modelo de planejamento coloca a equipe
no trilho correto e o desenvolvimento dentro de um padrão.
O método clássico para desenvolver um sistema é o de levan
tamento de requisitos - análise de requisitos projeto que inclui
os mais diversos diagramas, implementação, testes e lançamento do
produto no mercado, seguido da manutenção. Entre os métodos
 67

ágeis, destaca-se o Scrum. Segundo seu criador, Jeff Sutherland,

de forma resumida, esse método foca o primeiro contato com
o cliente, feito pelo product owner, que organiza a lista de tarefas
chamada backlog. Em seguida, define qual módulo será desenvolvido
e testado na primeira etapa, chamada sprint, com duração de duas
a quatro semanas. O Scrum Master direciona as reuniões diárias, que
duram cerca de 15 minutos, com toda a equipe (em algumas reuni­
ões, pode-se incluir o usuário), fazendo basicamente três perguntas:
O que você fez até agora? O que você fará hoje? O que o impede de
prosseguir com suas atividades?
Durante o processo de desenvolvimento, são documentados
os itens importantes e que podem ser acessados por qualquer mem­
bro e até mesmo pelos novos que serão incorporados à equipe. Uma
ferramenta para documentar todas as ações muito utilizada é oTrello,
que sintetiza todas as ações da equipe em cards, que podem ser des­
locados, criados ou removidos, além de compartilhados pela equipe,
tudo isso de forma gratuita.
Lowdermilk (2019) criou um modelo que foi dividido da se­
guinte forma:

• Definição de missão e visão de equipe.

• Detalhes do projeto.
• Requisitos de usuário.
• Requisitos funcionais.
• Diagrama de banco de dados/Huxo de dados.
• Imagens de telas de protótipos.
68

Ele utiliza esse método para mostrar aos usuários que o trabalho
segue um template e que todos os membros adotam esse padrão
na empresa. E um paradigma que demonstra aos usuários que há
um método para desenvolver aplicativos que cheguem às mãos dos
consumidores de forma efetiva. São tipos de conteúdo que não serão
analisados nesta obra e que podem ser encontrados nas mais diversas
equipes no meio profissional.
Sutherland (2014) relata o caso da reforma de uma residência
que foi realizada em seis semanas, sendo que em outra casa, com
as mesmas características e os mesmos empregados, a empreitada
levou três meses. A diferença foi que, no primeiro imóvel, adotou-se
um planejamento de todas as tarefas, realizando-se reuniões diá­
rias com todos os envolvidos no projeto, com a adoção do método
Scrum, o mesmo utilizado no desenvolvimento de sistemas.

A única diferença foi que o vizinho não usou o Scrum. Os problemas que o Scrum

força a aparecerem logo no início não foram descobertos até que já fosse tarde

demais. As pessoas não se coordenaram entre si do mesmo modo e foram obriga­

das a esperar que alguém terminasse um trabalho para poderem começar o seu.

O vizinho acabou gastando o dobro do que Elco, com a maior parte do curso pago

para as pessoas esperarem outras concluírem a sua parte. (Sutherland, 2014)

Qual template será adotado para prosseguir com o planejamento?

Como no caso da reforma da casa que levou menos tempo, deve-se
optar por envolver toda a equipe junto com o usuário e acreditar
que os membros têm maturidade suficiente para seguir o caminho
do sucesso. No exemplo da casa, antes mesmo de a reforma iniciar,
todos tiveram contato com a explicação de por que deveria ser feito
daquela forma, olharam para uma planta ou para o modelo da casa
 69

e discutiram as necessidades antes de se começar a derrubada de

paredes - assim como ocorre no desenvolvimento de aplicativos,
quando os usuários sâo consultados sobre suas necessidades antes
de se começar qualquer codificação. E preciso listar as priorida­
des apontadas em entrevistas com esses usuários e criar wireframes,
mockups ou protótipos rápidos para que eles possam visualizar como
é e como ficará o projeto depois de desenvolvido.
O papel do planejamento é criar um workflow de direcionamento
das ações dos membros da equipe. E uma motivação para que todos
os feedbacks dos usuários estejam norteando as atividades desse mo­
mento em diante. Não é uma tarefa fácil, pois alguns apontamentos
podem parar a equipe e fazer com que seja repensado o desenvolvi­
mento que está sendo seguido. Como assinala Lowdermilk (2019,
p. 47), “Desenvolvimento de software é um processo dinâmico;
é impossível prescrever um fluxo de trabalho específico. Praticar
o design centrado no usuário significa que você reagirá a descobertas
que não haviam sido incluídas em seu plano”.
E frustrante no início, mas o planejamento com o design centra­
do no usuário evita a sensação de fracasso quando os erros, as falhas
e os defeitos surgem com o sistema já nas mãos do consumidor.

2.2.1 Como definir o projeto

Toda equipe necessita conhecer sua missão quando inicia um

novo projeto. E ela que faz todos voltarem quando precisam enca­
rar um desafio pela frente. A missão é a resposta a questões como:
Por que a equipe existe? Qual é o motivo de ela ser criada? Esse
é o momento de saber o que será agregado de valor a todo projeto
70

que a equipe encara. Ela constitui o que está no DNA da empresa

e é uma declaração que deve constar no início do template do
planejamento escolhido.
Para saber como direcionar o projeto, devem-se fazer as seguintes
perguntas básicas a respeito: Qual é o objetivo do desenvolvimento
desse aplicativo? Qual é o público-alvo que vai se beneficiar? Qual
é o problema que ele solucionará? Ele vai utilizar tecnologias exis­
tentes ou depende de algo novo?
São perguntas simples, mas que norteiam uma equipe acerca
de características a serem seguidas para soluções mais complexas.
O filósofo inglês William de Occam, que viveu no século XIV, de­
fendia o princípio denominado navalha de Occam. Trata-se de uma
ideia que, originalmcnte, era pregada por Aristóteles no século 4 a.C.
Segundo princípio, quando preposições são geradas para um mes­
mo problema, deve-se adotar a mais simples, pois essa tende a ser
a solução mais adequada (mas não a única). Isso é uma forma de
deixar a equipe com os pés no chão e não correr o risco de criar algo
tão complexo que será esquecido pelo usuário. Deve-se lembrar que
soluções simples ajudam a manter o usuário acessando os aplicativos.
As respostas às questões devem ser documentadas, a fim de se­
rem acessadas no momento em que houver necessidade de explicar
algumas ações que os usuários desejam. Estes sempre correm o risco
de não conseguirem abstrair as idéias, e o que for documentado
auxilia nas definições.
Lowdermilk (2019) descreve que seus planejamentos têm uma
seção chamada “Detalhes do projeto”, com os seguintes tópicos:
 71

• Título - Define como o escopo do projeto deve ser compreen­

dido em sua totalidade.
• Descrição - Trata-se da síntese do projeto, descrevendo de que
o projeto vai tratar.
• Pessoas-chave - No caso de pessoas específicas, estas devem ser
declaradas nesse tópico, pois fazem parte do grupo de usuários
que atendem aos requisitos de utilização do sistema. Se for um
aplicativo para uma massa de pessoas, pode-se defini-las como
“usuários em potencial”. Nesse ponto, vale investir um tempo
para definir quais clientes serão beneficiados. Em caso de escla­
recimentos, essa lista será consultada, pois esses usuários têm
informações valiosas para a equipe.
• Avaliação de impacto - Deve conter a descrição dc quem ou do
que será afetado pelo aplicativo, as mudanças que serão promo­
vidas no ambiente, tanto positiva como negativamente. Portanto,
é preciso explicar a visão de sucesso que todos devem vislumbrar.
Deve-se fazer uma leitura junto com os usuários para ver se há
alinhamento com as necessidades a que eles desejam atender.

A realidade do desenvolvedor pode ser de um trabalho freelancer.

Então, pode-se perguntar: Qual impacto isso trará para o trabalho?
Qual é a visão que as atividades terão para as empresas para as quais
o serviço é prestado? Deve-se lembrar que o trabalho freelancer sofre
os mesmos impactos pela falta de planejamento.
Após cada projeto finalizado, é importante analisar o impacto
que o aplicativo está exercendo e comparar com o que foi acordado
no início. Reunir toda a equipe para debater o que foi conquistado
72

e o que deve ser ajustado é um formato que descreve o nível de matu­

ridade das equipes. Isso serve para futuros projetos como experiência
de aprendizado e que pode mudar o curso do planejamento.

2.3 Coleta de requisitos do usuário

No ciclo de desenvolvimento de um software, existe uma eta­

pa chamada levantamento de requisitos, que resulta em requisitos

funcionais (RFs) e requisitos não funcionais (RNFs) do sistema.

E uma lista com todas as funcionalidades exigidas para o aplicativo,
que vão desde um simples cadastro até temas sobre a segurança de
dados, com validações de campos e detalhamento de outras ações
técnicas, que gerarão a modelagem, por exemplo, o diagrama de caso
de uso, dentro da Unified Modeling Language (UML).
Quando se fala de design centrado no usuário, há também uma
lista de itens chamada de requisitos do usuário, que difere pela parte
técnica dos RFs e dos RNFs. São as necessidades do usuário organi­
zadas cm lista para serem avaliadas por todos os membros, inclusive
pelos próprios usuários. Sem essa ferramenta, não há como direcio­
nar as atividades de design centrado no usuário.
A coleta dessas informações é estruturada de forma a deixar claro
para o usuário que elas são importantes para o sucesso do aplicativo,
pois, sem essas questões, náo é possível desenvolver um artefato
voltado para a realidade. Alguns desenvolvedores realizam entrevistas
com gravação do áudio, sendo depois desgravadas, ou sessões de uso
de dispositivos que gravam as telas do usuário, seguindo roteiros.
 73

A única maneira de saber do que os usuários gostam é ouvindo-os. Não deixe de

testar seu sistema com usuários reais. Dê-lhes tarefas, observe seu comportamen­

to e feedback. Não tenha receio de modificar seu projeto e testá-lo novamente.

Ninguém pode criar o site fácil de usar, perfeito, especialmente na primeira tentativa.

(Nielsen; Loranger, 2007, p. 395)

Pode-se avaliar também, em forma de perguntas, o que o usuário

acha de sistemas concorrentes, apontando o que há de destaque em
termos de recursos que são agradáveis de usar e aqueles que ele julga
serem barreiras para a navegação.
E preciso ter muito cuidado com a coleta de usuários que neces­
sitam de adaptações no sistema ou no hardware, como as necessárias
para deficientes visuais ou de baixa visão. Alguns navegam com fer­
ramentas que sintetizam a voz de comando, devendo estar instaladas
no computador que vai servir para analisar o sistema implementado.
Existem muitos atributos na codificação e no design que precisam
ser levados em conta nesse momento, e aí está uma oportunidade
para testar e analisar se a equipe está seguindo corretamente as re­
comendações orientadoras nesse sentido.
Dependendo do nível do perfil de usuário que se deseja avaliar-
por exemplo, se o sistema já tem cadastro -, ele não recebe login
e senha para começar a análise. Por conta própria, ele realiza todo
o cadastro e analisa se recursos de envio por e-mail ou por SMS
estão funcionando conforme está especificado no roteiro. Roteiros
muito detalhados podem mascarar situações em que o usuário
precisa realizar por ele mesmo a navegação. Portanto, não se deve
facilitar a operação quando se trata de descobrir como a navegabi­
lidade está sendo exercida considerando-se um usuário que nunca
74

entrou no sistema. Níveis detalhados são reservados para quando

o sistema já foi testado e precisa ser analisado pelo ponto de vista
de um usuário já experiente.
A coleta dos requisitos pode ser realizada com base em modelos
feitos em papel. Existe uma técnica chamada de pro totipagem no
papel, na qual a navegação é toda desenhada em folhas, com traços
que não precisam ser fiéis ao layout. Alguns recursos, como uso de
post-it, fita crepe, adesivos e recortes no tamanho da tela de um
celular, ajudam na visualização de um protótipo.
Há também o uso de protótipos navegáveis, criados por aplica­
tivos que mesclam editores dc desenho com alguma programação.
Neles, os requisitos dc usuário podem ser analisados e alterados
conforme o uso na navegação. São aplicativos que geram arquivos
que podem ser consultados remotamente, no caso de o usuário não
poder se locomover até a empresa que os está desenvolvendo.
Com o levantamento em mãos, os usuários entendem se de­
vem continuar nesse caminho ou se adaptações devem ser feitas.
Nesse ponto, quando existem termos que são próprios do universo
dos usuários, eles são discutidos. Não é incomum a equipe ficar
alheia a algumas situações específicas relatadas pelo cliente nesse
momento. O usuário tem a oportunidade de se explicar dc outra
forma e até mesmo detalhar seu desejo quando for necessário. Como
vimos anteriormente, a equipe é leiga em muitos assuntos e, por
isso, os requisitos do usuário a direcionam para o caminho correto,
evitando o desperdício de tempo em retrabalho.
 75

Coletar requisitos de usuário é tão vital para um projeto bem-sucedido que, com

frequência, eu me recuso a escrever uma linha de código sequer antes de ter várias

reuniões com usuários para extrair deles os requisitos. Sem uma comunicação

adequada e um entendimento entre o desenvolvedor e o usuário, é impossível criar

um aplicativo eficiente. Documentar requisitos de usuário é a melhor maneira para

incentivar esse tipo de comunicação. (Lowdermilk, 2019, p. 52)

Há algumas situações em que não se tem acesso aos usuários.

Como conseguir criar uma lista de requisitos de usuários? E neces­
sário, então, partir para as redes sociais e pedir um feedback para
colegas e amigos. Para isso, deve-se elaborar um texto simples, ex­
plicando o tema da pesquisa e o valor que ela terá para o sucesso do
aplicativo. E preciso ser realista no caso de querer apontar o tempo
que a pessoa gastará para participar, pois nem sempre no momento
em que recebe a mensagem a pesquisa pode ser respondida. Nesse
caso, deve-se orientar que a visão de usuário é fundamental para
um aplicativo que atenda às suas necessidades.
Há muitas ferramentas que podem ser utilizadas como formulá­
rio. Por exemplo, o Google Does possui a ferramenta de formulário,
em que se pode personalizar o layout, criar perguntas com múltiplas
escolhas, inserir imagens e vídeos. As respostas podem ser coletadas
e gerar tabelas e gráficos de análise. Não se deve esquecer de mais
tarde dar um feedback de como foi útil a participação deles.
Algo que deve ser esclarecido é a diferença entre os requisitos do
usuário, que são as necessidades do usuário, e os requisitos funcionais,
que dizem respeito ao que o aplicativo precisa, ou seja, às especifi­
cações técnicas do aplicativo. Como exemplo, podemos citar um
sistema que gerencia o atendimento a clientes em uma lanchonete.
76

Os lanches são cadastrados conforme o cardápio que são oferecidos

no local. Mas e quando o cliente não quer um ingrediente do prato
que está solicitando? Então, um requisito do usuário seria a pos­
sibilidade de retirar itens do prato, e um requisito funcional seria
um checkbox, por exemplo, no qual, quando se clica no item, este
é retirado do pedido.
Contudo, como a lista de requisitos do usuário pode ser exten­
sa, uma forma de organizá-la é em planilha, segundo a sugestão de
Lowdermilk (2019). Em uma coluna, todos os requisitos do usuário,
ou seja, suas necessidades, precisam estar listados cm ordem, com
números para serem referenciados. Na coluna ao lado, deve estar o re­
quisito funcional correspondente. Muitas vezes, é necessário colocar
mais de um requisito funcional, devendo-se reservar um espaço maior
nas células da planilha com possibilidade de incluir outras.
Todas essas informações são parte da documentação que será
formada dentro da visão do design centrado no usuário. Ela serve de
consulta posterior para novos projetos que surgirem, pois ali estão
vários tópicos que podem ser semelhantes em outros aplicativos.
E uma experiência para a equipe e uma oportunidade de formar
um cadastro de usuários que podem mais tarde participar de outros
projetos. E nunca se deve deixar de agradecer essa parceria com
o usuário, pois ela é parte fundamental no sucesso do produto.
Outro papel da documentação é em relação ao cliente que verifi­
ca que alguma mudança deve ser realizada por algum motivo em que
somente ele acredita. A documentação de requisitos blinda a equipe
contra penalizaçóes, já que as mudanças afetam as atividades de
todos. E uma forma de o cliente visualizar por que a demanda vai
ter atraso gerado pelo reinicio do processo. Muitas vezes, ele desiste
 77

das alterações, pois consegue enxergar o impacto que as mudanças

ocasionam, principalmente quando a concorrência pode entrar no
mercado antes do lançamento do aplicativo.

2.4 Modelos de dados e de fluxo de trabalho

A modelagem consiste em visualizar como as informações serão

tratadas durante o fluxo. Ferramentas on-line e desktops criam dia­
gramas que possibilitam abstrair as idéias do usuário para um enten­
dimento mais significativo. Uma das ferramentas on-line que criam
os diagramas é o Draw.io. Os desenhos podem ser compartilhados
com a equipe, editados e submetidos à análise. Outra ferramenta que
pode ser utilizada na versão desktop é o Dia Portable, que também
entrega os diagramas em formato cditável ou imagem. Ele não tem
recursos de compartilhamento. Também a Microsoft desenvolveu
o Visio, que cria a modelagem e conta com outros recursos avançados.
Alguns diagramas fazem parte da UML e podem auxiliar
na visualização esquemática do aplicativo. Entre eles, citamos
os seguintes:

• Diagrama de caso de uso, ou use case - Cada tipo de usuário

é tratado nesse diagrama como ator, representado graficamente
como um boneco-palito. Esses atores podem ou não se relacionar
entre si, dependendo do sistema. Cada requisito funcional levan­
tado é definido nos casos de uso na forma gráfica de elipses. Um
caso de uso no sistema comentado anteriormente, no exemplo
da lanchonete, seria o de “solicitar lanche”, que é genérico, já que
78

lanche pode ser variado conforme as necessidades do cliente.

O ator seria o cliente, e claro que haveria outros casos de uso
e atores no sistema de lanchonete. O detalhamento das ações do
ator e do sistema é incluído em uma planilha com cada passo que
aquele dará e as reações do sistema. Fluxos alternativos, como
erro na senha ou cadastro com e-mail já cadastrado, sâo anali­
sados nessa etapa, o que facilita nos momentos da codificação
e da construção do banco de dados.
• Diagrama de sequência - Envolve o ator e sua interação no
sistema. Sâo detalhados todos os passos de cada caso de uso com
o Huxo e os retornos, se houver. Os atores são representados
por bonecos-palito; as sequências, por linhas; e cada ação, por
retângulos. No exemplo da lanchonete, a sequência de cadastro
do cardápio seria modelada, desde o momento de logar-se no
sistema até o cardápio ser inserido.
• Diagrama de classe - Esse diagrama é modelado de forma seme­
lhante ao banco de dados. Na modelagem, aparece um retângulo
que está dividido em três seções. Na parte do topo, está a defini­
ção da classe, que no nosso exemplo do sistema para lanchonete
poderia ser o perfil. Em seguida, constam os atributos, como
nome, cadastro de pessoa física (CPF) e e-mail. E, na base, estão
os métodos que esses atributos podem executar, como cadastrar
cardápio e enviar pedido para a cozinha. Essa classe está ligada
a outras classes por meio de linhas.

Já o banco de dados é modelado em diagramas que mostram

os atributos e os métodos de forma clara e suas relações. São dese­
nhados com base em um software que gerencia um banco de dados
 79

ou podem ser gerados por programas específicos de diagramas.

Por exemplo, um cadastro de uma entidade como perfil tem vários
atributos dependendo do sistema, como nome, CPF, e-mail, data de
nascimento e endereço, e, com esses atributos, o que o cliente realiza,
por exemplo, uma compra. Nessa etapa, o usuário pode achar que
informações como o endereço precisam ser complementadas, já que
a entrega pode ser realizada em outro local. Então, chega-se à con­
clusão de que o endereço de entrega deve ser incluído na hora do
cadastro e no momento da efetivação da compra. São feitos os ajustes
no diagrama e apresentados novamente para aprovação.
Lowdermilk (2019) destaca que ele costuma manter um im­
presso do diagrama de banco de dados do projeto ao seu alcance,
pois, assim, considera a consulta mais vantajosa, a não ser que haja
muitos atributos para observar c que ficariam ilegíveis na impressão.
Então, recorre às telas do computador que possibilitam explorar
o documento. Nas reuniões com usuário, o diagrama é utilizado
como suporte para anotações.
Outra ferramenta utilizada é o diagrama de fluxo de trabalho ou
diagrama de fluxo de dados. Seu uso é recomendado quando uma
sequência de vários passos precisa ser explicada, pois textualmcnte
fica difícil para a compreensão ou há muitos perfis. O diagrama
de fluxo de dados considera todos os caminhos nas ações de cada
usuário e, por isso, é detalhado. Lowdermilk (2019) ressalta que
os diagramas de banco de dados e de fluxo de trabalho podem ser
simples ou complexos, dependendo da quantidade de informação.
Obviamente, quanto mais detalhes, melhor, mas é preferível um
diagrama limitado a nada.
DOCUMENTAÇÃO
DOS PROTÓTIPOS
E A IMPORTÂNCIA
DA REVISÃO DA
DOCUMENTAÇÃO
 83

Existe uma fase na qual as idéias discutidas geram wireframes,

que são desenhos dos espaços nos quais os elementos ficarão. São ex­
plorados de forma simples, com linhas e formas geométricas co­
muns. Após a discussão com o cliente com base no wireframes com
os desenvolvedores, a próxima etapa é a criação das telas em formato
mockup. Aqui, entram os editores de imagem, quando o visual será
mais refinado, sem codificação alguma. E, mais uma vez, o usuário
será chamado para dar suas sugestões.
Para avaliar como serão as interfaces do sistema, a equipe recorre
aos protótipos como forma de garantir visualização e navegação
por meio da participação de usuários. São testados todos os ele­
mentos que a equipe está desenvolvendo, desde as funcionalidades
até as versões em smartphones. Os testes podem ser realizados em
softwares e, depois, simulados no ambiente cm que o usuário vai
avaliar. Os protótipos são fontes de documentação até mesmo para
criar uma linha do tempo, desde quando a primeira ideia foi con­
cebida, passando por todos os ajustes necessários, até chegar à ideia
final. E uma espécie de lapidação de um diamante bruto, em que
a equipe precisa das informações do usuário para ir avaliando o que
será alterado e melhorado.
Muitos desenvolvedores não gostam muito de protótipos, prin­
cipalmente os navegáveis que geram arquivos HTML (Hyper Text
Markup Language) e JavaScript, pois julgam que, na codificação,
não apresentarão funcionalidades fiéis ao protótipo. Entretanto,
a maioria dos profissionais que trabalham com prototipagem sabe
que é uma etapa que não substitui a codificação, pois não é seu papel
criar o sistema entregável, e sim analisar como será a navegabilida­
de e explicar para o cliente que o sistema ainda será colocado em
84

produção. Muitos desenvolvedores acreditam que o protótipo revela

antes do tempo o que o programa vai fazer.

Acho que o maior desafio que os desenvolvedores enfrentam com protótipos é que

eles acabam com a grande revelação - aquela sensação de euforia inconfundível

que você tem imediatamente antes de mostrar ao usuário o produto no qual estava

trabalhando. Em certos aspectos, essa euforia é o que nos mantém motivados

a continuar a desenvolver nosso projeto em segredo. Se nossa motivação for fazer

uma grande revelação, isso fará com que escondamos nossas idéias do usuário até

que tenhamos terminado. (Lowdermilk, 2019, p. 57)

A melhor maneira de entregar um sistema que atenda aos requi­

sitos do usuário é colocá-lo no circuito do desenvolvimento. O usu
ário deve ser instruído de que protótipos são produtos inacabados
e precisam de sua aprovação. E com esse comprometimento que
o trabalho sairá conforme as expectativas do cliente.
A documentação de protótipo deve conter todos os elementos
usados que fazem parte da interação, um demonstrativo de que to­
dos esses grafismos não são somente para deixar uma interface mais
agradável, mas também funcional, já que se espera uma abordagem
mais próxima do usuário do que somente um produto para venda.
A documentação dos protótipos não se mede pela quantidade de
telas e de elementos, devendo ser um espelho próximo do que está
na lista de requisitos do usuário, pois, seguindo-se essas orientações,
não se corre o risco de entregar um software que exigirá um retraba-
Iho. E o que mais as equipes querem é apresentar um produto que
necessite do mínimo de manutenção. E uma ferramenta que será
sempre consultada para analisar como deve ser a codificação em
termos de trabalho de desenvolvedores.
 85

A documentação deve ficar acessível a todos, sanando eventuais

dúvidas, pois divergências podem ocorrer no processo de desenvol­
vimento. Outra situação é que, mesmo com a finalização do projeto,
a revisão da documentação deve ser realizada, pois são elementos
que sempre são reutilizáveis em outros projetos. Como destaca
Lowdermilk (2019), rever como foi a evolução do aplicativo desen­
volvido e como ele foi melhorado em todo esse tempo propicia um
momento de reflexão. Isso se aplica até se o método de prototipagem
está sendo feito da forma correta, pois muitas equipes adotam meto­
dologias de trabalho e, por falta de implantação da cultura, acabam
esquecendo e voltando a velhos hábitos.
A revisão da documentação consiste em fazer um análise que vai
desde a forma como a equipe está trabalhando, se é necessário haver
uma reciclagem de conteúdo, até uma comparação com projetos
atuais. E um hábito que deve ser criado em todos os projetos, sendo
reconhecido como peça importante do sistema e que traz credibi­
lidade ao trabalho, principalmente porque essa documentação foi
concebida juntamente com o usuário, que tem as informações sobre
a interação com o sistema. O usuário sente-se mais seguro com essa
documentação, pois, sem ela, não conhece o histórico completo.
Outra situação é analisar qual tipo de documentação a equipe
de desenvolvedores quer tomar como base na etapa de codificação:
wireframe ou protótipo. Algo estático ou dinâmico? E preciso dis­
cutir as opções, já que cada um tem sua preferência em termos de
documentação para tomar como base para suas atividades.
Também há quem prefira utilizar as imagens geradas em mockups,
que seguem fiéis à aparência, com cores, formas e fontes, contudo
86

sem funcionalidades. As idéias de interface aparecem em modelos

de dispositivos nos quais o sistema será aplicado.
E no caso dos usuários? Alguns têm facilidade em entender os pro­
cessos do sistema a partir do wireframe, que é uma documentação de
interface de baixa fidelidade. Ele não vai mostrar as funcionalidades
sendo executadas, mas, pela experiência no uso, os desenvolvedores
conseguem abstrair quais são as intenções com o modelo.
No caso dos mockups, os usuários visualizam o layout do sistema,
a aplicação das cores, os efeitos visuais e os diversos dispositivos,
porém não interagem. Outros se sentem melhor com protótipos na­
vegáveis, quando estes lhes permitem visualizar as ações e acompanhar
o fluxo das atividades.
A documentação pode passar pela revisão do usuário no momen­
to da execução das alterações. Alguns desses usuários querem que
as modificações sejam feitas no momento da análise, entretanto isso
depende de cada equipe, que deve se organizar nesse sentido, pois
algumas mudanças no sistema são feitas em etapas c qualquer altera­
ção é acompanhada com apreensão pelo usuário, julgando que será
definitiva. Por exemplo, arrastando um objeto no layout, ele pode
achar que não seria correto deixá-lo naquele local, mas o profissional
à frente das modificações terá de explicar que ainda não finalizou
o processo, e isso, dependendo da urgência da entrega, pode se tornar
um agravante. Nesse caso, a orientação é solicitar todas as alterações
necessárias, criar uma lista, discutir com a equipe quais modificações
serão realizadas e apresentá-las para o usuário depois de concluídas.
Deve-se sempre ter em mente que uma revisão da documen­
tação de protótipos deve abranger todos os detalhes, pois é uma
 87

forma de entregar um produto que atende às expectativas do usuário.

Uma equipe de desenvolvimento deve sempre se ater a essas revisões
alinhadas ao objetivo central, que é entregar produtos com excelên­
cia, suprindo cada necessidade do cliente. As equipes precisam ter
ideia do que vão entregar em termos de qualidade antes mesmo de
codificar ou de gerar protótipos. Trata-se de dar um sentido maior
do que entregar um sistema. E o que Lowdermilk (2019) afirma
sobre criar um manifesto pessoal - uma exposição pública de uma
opinião ou ideia a respeito de algo.

Porém aqui está outra constatação: você não só deve ter uma definição geral de

missão, mas deve ter também um manifesto para cada projeto em que estiver

trabalhando. Por exemplo, em vez de dizer "Estou desenvolvendo um aplicativo

para viagens", um manifesto afirmaria, "Estou desenvolvendo um aplicativo que

reproduz a experiência e agrega o valor de ter um assistente pessoal de viagens".

(Lowdermilk, 2019, p. 60)

Lowdermilk (2019) cita o caso da empresa de desenvolvimento

Fifty Ihree, que deixa claro seu manifesto. Ela desenvolveu o apli­
cativo Paper, para o iPad, que em duas semanas atingiu 1,5 milhão
de downloads na loja de aplicativos da Apple. E uma espécie de
prancheta na qual o usuário pode esboçar desenhos, fazer anotações
e pintar. Recebeu, em 2012, o Apple Design Awards. Um produ­
to assim nos leva a pensar que não há limites para o ser humano.
O que estava preso na mente das pessoas agora tem forma e cor.
E um produto que oferece ao usuário a liberdade que precisa para
encontrar as ferramentas certas, e não um produto que tem tantas
opções que não se sabe qual caminho tomar.
88

3.i Restrições e narrativa

Estamos vivendo cm tempos nos quais a tecnologia supera

qualquer avanço ocorrido anteriormente na história. São tantas
novidades que novos produtos surgem em velocidade assombrosa.
E desenvolvedores têm a tendência de utilizar todos que encontram
pelo caminho para aplicar em novos artefatos. Isso pode gerar tantos
caminhos dentro de um aplicativo que fica difícil uma navegação
amigável. Muitos acabam desistindo, desinstalando ou dando má
reputação ao sistema.
Como afirma Lowdermilk (2019), muitos desenvolvedores colo­
caram a tecnologia em primeiro lugar e ficaram focados demais na­
quilo que poderíam fazer, e não no que deveríam fazer. Isso significa
dar valor a um recurso irrelevante ao sistema, por isso a importância
de haver uma missão ou um manifesto norteador das atividades dos
desenvolvedores. Sempre se deve perguntar se aquilo que o cliente
quer implementar é uma diferença ou apenas mais um recurso que
sobrecarregará o programa e pode afastar os usuários. Quantos sis­
temas têm módulos que nem foram utilizados porque não foram
analisados com os usuários reais? Quantas funcionalidades vêm de
aplicativos de outras áreas que foram reaproveitados sem pensar no
usuário que fará uso dos recursos?
Quanto ao uso de recursos tecnológicos, Lowdermilk (2019)
destaca que não há nada de errado em sentir-se orgulhoso das ha­
bilidades de programação; no entanto, é preciso lembrar-se de que
isso tem pouco valor para os usuários se não for dado a eles aquilo
de que necessitam.
 89

Por exemplo, se estivéssemos criando um aplicativo de mensagens instantâneas,

poderiamos ficar empolgados com o fato de termos implementado uma tecnologia

de localização por GPS, permitindo que os usuários vejam de onde suas mensagens

estão sendo enviadas. Contudo, se enviar mensagens a um colega usuário for uma

tarefa árdua, qual será o valor geral de nosso aplicativo? Os usuários podem ficar

impressionados com o recurso de localização por GPS, mas, como aplicativo falha

em atender suas necessidades principais, eles decidirão não utilizá-lo (Lowdermilk,

2019, p. 62)

Para o autor, os desenvolvedores têm tantos recursos à disposição

que querem usá-los no sistema, o que torna o produto final mais
difícil de utilizar (Lowdermilk, 2019). Porém, como observado
no capítulo anterior, “Menos é mais”, e esse conceito só beneficia
os usuários, pois, na navegação, algumas decisões devem ser toma­
das e precisam de agilidade, por exemplo, um preenchimento de
cadastro com confirmação. Qual tecnologia utilizar? Enviar um
e-mail para que o usuário clique no link e depois confirme ou gerar
um token e enviar por SMS? A utilização do captcha vai promover
a segurança no processo ou há outro recurso para confirmar se é um
usuário ou se é uma automação de preenchimento? Aqui, vale uma
decisão em favor de quem vai usar o recurso, e não a tecnologia
que os desenvolvedores acham mais importante. Nesse momento,
entra o manifesto pessoal, o que a equipe chamou de missão em
relação ao projeto e que agora será o norteador das decisões, o que
colocará as atividades no trilho novamente. E um manifesto pode
ser formulado por meio de narrativas que vão direcionar o usuário
entre os recursos oferecidos pelo aplicativo.
90

Uma narrativa é uma história detalhada de como a pessoa vai

interagir com o artefato. E analisado o comportamento das interfa­
ces quando o usuário estiver avaliando o sistema.
Sutherland (2014) exemplifica a importância da narrativa por
meio de uma demanda de uma empresa na qual colaboradores rece­
beram do gerente geral somente a solicitação de levantar o número
de lojas com menos de 55 metros quadrados. Eles receberam so­
mente essa solicitação e acabaram receosos em pesquisar dados que
não fossem relevantes para a demanda ou que fossem errados, além
de que alguns não acharam que era uma atividade para a função
deles dentro da empresa. O gerente que fez o pedido ficou surpreso
com a equipe por não entender que ele queria fechar as lojas pe­
quenas e abrir lojas maiores. O problema foi a falta de informações.
Sutherland (2014) conclui assim: “As pessoas pensam em narrativas,
histórias. E deste modo que compreendemos o mundo. Temos uma
compreensão íntima de personagens, desejos e motivações. Nós nos
encrencamos quando tentamos abstrair partes descontínuas da linha
principal e tratá-las fora do contexto”.
A narrativa terá como base algumas variáveis a serem definidas.
Primeiro, é necessário considerar para quem é direcionado o sis­
tema. Deve-se pensar no público e no perfil desse público. Pode
ser voltado para artesãos ou empresários, adolescentes ou idosos,
vendedores de veículos ou compradores de carros em leilão. Esse
perfil é o personagem da história com todas as suas características
estruturadas. São pessoas do mundo real que vão interagir com
o aplicativo. E por meio da lente desse público que se deve construir
o projeto. Não se trata de elaborar personagens de um teatro; o que
 91

está em jogo é, por exemplo, se alguém fabrica peças para vender

ou para terceirizar a venda.
Em seguida, deve-se observar no que esse público vai realizar
a atividade e em qual meio. Segundo Sutherland (2014), nessa etapa
o processo geralmente começa e para. E a fase em que se define, dentro
do desenvolvimento de aplicativos, se vai ser, por exemplo, uma aplica­
ção web ou desktop, uma realidade virtual ou um aplicativo para celular.
Na última etapa, é preciso pensar no porquê de o público que­
rer essa funcionalidade ou aplicativo. Qual motivação está por trás
desse projeto? Aí está a resposta que ajudará o cliente/usuário no
sucesso do artefato.
No contexto de uma compra de um carro, Sutherland (2014)
exemplifica que uma história termina com o personagem declaran­
do que quer um carro para locomover-se até seu trabalho. Se essa
narrativa iniciar com uma pessoa que sai do subúrbio para ir até
uma empresa na região central, será um carro com características
diferentes daquelas preferidas por uma pessoa que trabalha na área
rural onde as estradas exigem mais do veículo. Então, a equipe precisa
saber quem é seu público e as respostas de outras questões: Quais
são as paixões e os anseios das pessoas envolvidas? O que já viram
que deu errado em outros sistemas? De que maneira elas informam
o que desejam?
Sutherland (2014) afirma que o trabalho é uma história. Deve-se
pensar primeiro em quem vai obter valor com algo; depois, o que
é esse algo e, então, por que eles precisam daquilo. Os seres humanos
pensam em uma estrutura narrativa, por isso deve-se dar isso a eles,
como em: “Como X, eu quero Y para conseguir Z”.
92

As narrativas devem ser curtas o suficiente para se ter uma ideia

real de quais necessidades atendem ao usuário. Sutherland (2014)
exemplifica uma narrativa envolvendo a Amazon na qual se consi­
dera um usuário que deseja acessar uma livraria que seja a maior do
mundo e na qual possa comprar qualquer livro em qualquer hora.
E uma narrativa abrangente demais, porque abre possibilidades para
todo o tipo de livraria virtual em que a equipe pode dar o maior
número de respostas possíveis. Nesse caso, a saída é dividir para obter
um resultado com o qual o time possa trabalhar. Para a narrativa da
Amazon, Sutherland (2014) propõe a seguinte divisão:

• “Como cliente, eu quero poder navegar pelos livros por gênero,

para que eu possa encontrar o tipo de livros de que eu gosto.”
• “Como cliente, eu quero colocar um livro em um carrinho de
compras, para que eu possa comprá-lo.”
• “Como gerente de administração de produtos, eu quero poder
rastrear as compras de um cliente, para que eu possa oferecer
livros específicos para ele, com base nas compras anteriores.”

Elas são simples o suficiente para que a equipe decida o que será
desenvolvido. Essas partes são pequenas narrativas que formam uma
grande história, o chamado épico.
Lowdermilk (2019) dá outro exemplo de narrativas que leva­
ram a construir o aplicativo que citamos anteriormente para o iPad,
o Paper. Este foi idealizado utilizando-se recursos simples de anota­
ções, esboços e aplicação de cores, sem incluir efeitos de grandes edi­
tores de imagem. Julian, o engenheiro líder responsável pelo Paper,
afirma que a FiftyThree não implementou uma técnica específica
 93

de desenvolvimento de produto. Em vez disso, eles se basearam em

sua história para o Paper:

A empresa se baseia no seguinte: Na FiftyThree, não temos nenhuma ideia pomposa

sobre desenvolvimento de produtos - não saímos por aí professando nenhuma téc­

nica, mas começamos a chamar o nosso processo de "design baseado em narrativa".

Os desenvolvedores sempre têm a tendência de querer dar mais poder ao usuá­

rio, especialmente se puderem fazê-lo... facilmente. Fazem afirmações do tipo:

"O recurso está quase pronto. Tudo o que temos de fazer é acrescentar o botão!",

e isso nem sempre pode se encaixar na história. (Lowdermilk, 2019, p. 64)

O aplicativo Paper reduziu suas ferramentas ao máximo para náo

oferecer tantas opções que deixariam perdido o usuário. Quando
existem tantas opções, fica difícil escolher qual será mais útil e nem
todas elas são aplicadas às necessidades do usuário. O Paper vai na
contramão da complexidade que outros aplicativos apresentam, o que
vai ao encontro do manifesto da empresa, que é entregar aplicativos
simples para que o usuário tenha uma experiência agradável. Segundo
Lowdermilk (2019), um recurso de misturador de cores foi adicio­
nado, o que ainda o caracteriza como um aplicativo simples de usar.
A diminuição de recursos deixa a criatividade fluir nas interações.

A narrativa do Paper estimula a simplicidade dando ênfase à redução. Ao usar

o Paper, você acaba focando naquilo que quer desenhar, e não na forma como

você quer desenhar. Essa redução na complexidade permite que os usuários

se concentrem em sua criatividade, e essa é a chave para o sucesso do Paper.

(Lowdermilk, 2019, p. 64)

Um outro exemplo de aplicativo que restringe seu uso é o Google

Tarefas. Essa ferramenta foi pensada pela praticidade de anotar itens
94

que precisam ser lembrados, com avisos no momento certo. As nar­

rativas construídas poderíam ser da seguinte forma:

• Eu quero um aplicativo que me avise sobre meus compromissos

agendados durante a semana.
• Eu quero diferenciar minhas metas pessoais das profissionais?
• Eu quero agendar meus compromissos de pagamento de contas
mensais sem precisar incluir todo mês a mesma açâo.
• Eu tenho acesso ao notebook e ao celular e quero um aplicativo
que seja lido tanto em um quanto em outro.

Vendo pelo lado das narrativas, a equipe entende que as pessoas

necessitam de uma ferramenta acessível para anotar lembretes e que
esteja vinculada a um calendário. Aa narrativas podem se estender
conforme o acordado com a equipe, mas sempre alinhadas com
o manifesto, que, todos sabem, é público e notório. Alguém, como
usuário, pode incluir a seguinte história:

• Eu, como responsável pela tarefa, não posso perder prazos, então
quero ser lembrado com uma hora de antecedência e, depois,
30 minutos antes do evento.

Alguém com visão mais detalhista pode achar que o aplicati­

vo incluiría acesso à inserção de fotos, vídeos e mensagens de voz.
Um membro da equipe, vendo o manifesto, apontaria que isso não
está dentro da proposta, que é a de agilizar o cumprimento de metas
por meio de uma lista. Um recurso que o Google Tarefas permitiu
foi que o Gmail fosse adicionado à integração como gerenciador de
e-mails. Assim, com sua lista de mensagens aparecendo, o usuário vi­
sualiza ao lado a ferramenta de tarefas que pode ser acessada ao clicar
 95

no ícone. Em seguida, aparece um sinal de mais com uma labei

em que está escrito “Adicionar uma tarefa”. Outros recursos foram
adicionados, como “data” para o lembrete e “categorizar” as tarefas.
Com visual simples, a narrativa não se estende, justamente para
atender os usuários que querem agilidade e não desejam perder tem­
po buscando a informação. E o que se pode chamar de minimalismo
de um aplicativo, ou “menos é mais”.
Para que o aplicativo seja simples e objetivo, Lowdermilk (2019)
sugere algumas perguntas:

• Que elementos devem ser incluídos?

• Que elementos devem ser deixados de lado?
• Os recursos oferecidos estão de acordo com a história que você
estava tentando contar?

Teixeira (2014, p. 10) dá outros exemplos de perguntas relacio­

nadas ao desenvolvimento:

O que acontece quando eu clico em determinado botão? Como a interface res­

ponde? Como eu arrasto um produto para meu carrinho de compras? Qual a exata

quantidade de informação que o usuário precisa saber para realizar a tarefa naquele

momento? Como a interface pode ser usada para realizar uma narrativa na expe­

riência do usuário?

Como saber se uma história está concluída? Para Sutherland

(2014), vale a dica de Bill Wake, grande desenvolvedor de software.

Bill diz que para uma história estar pronta ela precisa atender aos critérios INVEST:

• Independente. A história precisa ser prática e passível de ser "feita" por si só.

Ela não deve ser inerentemente dependente de outra história.

96

• Negociável. Até que esteja sendo realizada, ela precisa poder ser reescrita. A per­

missão para alterações está embutida nela.

• Valiosa. Ela realmente deve acrescentar valor ao cliente, usuário ou stakeholder.

• Estimável. Você deve ser capaz de mensurá-la.

• Small (pequena). A história precisa ser pequena o suficiente para que você possa

estimar e planejar facilmente. Se ela for grande demais, reescreva-a ou divida-a

em histórias menores.

• Testável. A história precisa ter um teste pelo qual deve passar para ser completa.

Escreva o teste antes de fazer a história. (Sutherland, 2014, p. 112-113, grifo

do original)

3.2 Personas e cenários

Alinhado ao método de criar narrativas que se utiliza de diversos

tipos de personagens, existe o processo chamado persona. E uma
técnica que cria atributos para os usuários que darão características
próprias para cada um deles. Como nas histórias colocamos pessoas
que têm seus desejos, a persona deixa esses personagens mais próxi­
mos do mundo real, principalmentc porque são eles que interagem
com o sistema. Lowdermilk (2019) destaca que uma persona é um
elemento determinado segundo a personalidade que ajuda o de­
senvolvedor a lembrar para quem o aplicativo está sendo criado.
E uma personagem de ficção que consiste na personificação de seus
usuários reais.
O’Connor (2011, tradução nossa), cofundador da User Insight,
explica o que épersona-.
 97

Uma persona representa um cluster de usuários que exibem padrões comporta-

mentais semelhantes em suas decisões de compra, uso de tecnologia ou produ­

tos, preferências de atendimento ao cliente, opções de estilo de vida e similares.

Comportamentos, atitudes e motivações são comuns a um "tipo", independen­

temente da idade, do sexo, da educação e de outros dados demográficos típicos.

De fato, as personas abrangem amplamente a demografia.

E como criar essa personal Onde buscar elementos para que

sejam atributos reais e não uma personificação baseada na expe­
riência dos próprios desenvolvedores? Conforme Teixeira (2014,
p. 21), “A medida que você vai conversando com mais consumidores,
é possível criar personas para o seu projeto: uma documentação de
quem é esse consumidor, qual o seu perfil demográfico, quais as suas
necessidades, desejos e anseios quando estão buscando uma solução
para seu problema”.
Teixeira (2014) ainda afirma que personas ajudam os designers
e os desenvolvedores no processo de empatia com os usuários, prin­
cipalmente pelo fato de estes não estarem todo o tempo trabalhando
com a equipe. É uma forma de recorrer aos atributos necessários
para que pensem com o fluxo mental do usuário do sistema. Nas
palavras de Teixeira (2014, p. 118): “É nessa hora que criar docu­
mentos de personas pode ser útil para o seu projeto. As personas são
uma espécie de “retrato” de quem é o público-alvo do seu produto.
Conhecer bem o perfil do usuário ajuda a marca a se comunicar de
uma forma que soe natural e lógica para eles”.
Lowdermilk (2019) destaca que, para criar uma persona, devem
ser feitas algumas perguntas aos usuários reais, como as seguintes:
98

• Cite o nome de um de seus produtos preferidos. Por que ele

é melhor do que outros produtos similares?
• Qual é o produto que mais deixa você frustrado? Por quê? O que
você faria para melhorá-lo?
• Se você pudesse criar o aplicativo perfeito para ajudá-lo nessa
tarefa, como ele seria? O que ele faria?

Essas indagações exploram características que podem levar ao

desenvolvimento de uma ideia que aparentemente não está conec­
tada. Por exemplo, quando o usuário afirma que um menu para
escolher opções em um site de compras de produtos é de difícil
navegação, pois é preciso ter mais controle por parte dele, isso pode
levar à correção da navegabilidade de um aplicativo em que a equi­
pe está trabalhando que mostra cenas de filmes e o usuário sente
dificuldades de fazer retroceder ou avançar as cenas. As conexões
entre os projetos podem surgir de diversas formas, e esse é o valor de
encarar o usuário como parceiro no desenvolvimento dos projetos.
O’Connor (2011) sugere que essas entrevistas sejam realizadas
nos espaços onde o usuário realiza suas atividades, método que é cha­
mado de etnografia. Esse termo vem da época em que pesquisadores
de tribos primitivas passavam dias nas aldeias convivendo com os
moradores e estudando sua rotina diária - como se alimentavam,
como trabalhavam, sua relação com o meio ambiente etc. -, de
modo a formar uma ideia das características daquela tribo. Dessa
forma, vivenciando-se a rotina do usuário, forma-se uma ideia de
suas angústias, frustrações e necessidades que não podem ser obser­
vadas durante uma pesquisa formal em uma sala de reuniões. Porém,
não se devem descartar entrevistas em salas, visto que também são
instrumentos de grande valor para levantar características do cliente.
 99

E como construir as características da persona depois de coletar

as informações dos usuários? Nesse momento, inicia-se o processo
de dar vida ao personagem que vai interagir com o sistema que está
sendo construído pela equipe.
Lowdermilk (2019) aponta algumas características que devem
fazer parte do perfil dessa persona-.

• nome;
• idade;
• estado civil e quantidade de filhos;
• localização;
• profissão;
• hobbies e itens prediletos;
• necessidades e frustrações.

Existem complementos para a estrutura da persona. Por exemplo:

uma característica do grau de instrução é uma referência de quanto
ele tem se relacionado com os objetos de pesquisa. Outra forma de
definir mais características reais é recorrer às imagens de pessoas, que
podem ser obtidas em bancos de imagens. Sexo também é outra
caraterística que pode ser incluída nesse perfil.
Em se tratando de disponibilidade de acesso a usuários para
construir personas, pode ser que um desenvolvedor que trabalhe
como freelancer não consiga estruturar uma entrevista com audi­
ência de muitos usuários. A alternativa sugerida por Lowdermilk
(2019) é entrar em contato com a própria rede de amigos e co­
nhecidos e usá-la para construir essas personas. Desse modo, os de­
senvolvedores podem recorrer às personas principalmente porque
não têm acesso aos usuários continuamente para recorrer quando
100

surgir alguma dúvida acerca das necessidades do cliente em relação

ao projeto. O cuidado que se deve ter é não buscar características
próprias do desenvolvedor para formar a persona, mas de usuários
que têm necessidades reais.
Essas informações precisam estar acessíveis na rede, para que
todos os desenvolvedores e designers tenham acesso a elas. Algumas
empresas criam tabelas em planilhas, com as informações dispostas
nas células e a possibilidade de serem preenchidas conforme algu­
mas características sejam descobertas. Alguns criam documentos
de personas mais elaborados, com pontuação em relação a alguns
aspectos de sistemas que já existem no mercado. Na web, há ferra­
mentas que criam documentos de personas, com acesso comparti­
lhado e a capacidade de gerar gráficos e ser gerenciadas pela equipe.
Com a construção da persona, Lowdermilk (2019) aponta que
a equipe pode mergulhar fundo na psique do usuário, entender
suas necessidades e angústias e analisar o que o motiva. Assim, ele
compreenderá o que o deixa frustrado e o que o torna feliz.
Depois de obter informações sobre os usuários e criar a persona,
serão desenvolvidos os cenários nos quais ela está inserida. São
as situações em que o futuro aplicativo será utilizado pelo usuá­
rio. Quanto mais detalhes forem adicionados ao perfil da persona,
mais informações se obtêm em relação à interação do usuário com
determinado cenário. O aplicativo é, digamos, a solução para que
a narrativa consiga se desenrolar com sucesso no cenário proposto.
O interessante é criar vários cenários em que a persona estará
inserida. São situações que colocam o projeto em testes, muitas vezes,
que exigem sair de seus limites, da zona de conforto. Sem dúvida,
 101

é preciso entender que nem sempre o aplicativo está correspondendo

às necessidades do cliente, mas os cenários serão o momento de
prova para que a equipe enxergue os limites impostos, seja pela
tecnologia, seja pelo próprio cenário.
Por exemplo, a equipe está desenvolvendo um sistema para
gerenciar um setor de impressões dentro de uma grande empresa.
A persona definida, José, um menor aprendiz, trabalha nesse setor
de segunda a sexta-feira e é responsável por receber os arquivos,
enviá-los para a impressora e entregá-los para o solicitante. Nessa
situação, quais seriam os cenários possíveis?

• José recebe pelo sistema um arquivo corrompido. Como ele

entrará em contato com o remetente?
• José não encontra papel no armário de suprimentos. Como ele
dará continuidade às impressões e como será registrada no siste­
ma essa pausa não controlada?
• José recebe pedidos no balcão para imprimir. Como ele contro­
lará esses pedidos em relação aos enviados pelo sistema?
• José tem de gerenciar pedidos conforme prioridades. Como eles
serão visualizados e quem define as prioridades?
• José tem impressões que não foram retiradas. Qual será o prazo
de validade para suas retiradas? Como ele descartará essas im­
pressões no sistema?
• José entrega a impressão no balcão. E se quem for retirá-la não
for a mesma pessoa que a solicitou?

Esses cenários, dos quais essa persona, José, faz parte, enriquecem
as narrativas, principalmente se a equipe não tem experiência em ge­
renciamento de cópias, impressões e protocolos da empresa. O desafio
102

nesse cenário é criar um sistema que auxilie o usuário em termos

de produtividade, que dê uma certa autonomia para decidir o que
é prioridade e que não seja simplesmente um gerenciador de e-mails.
Outro usuário pode fazer parte da equipe e gerenciar e-mails com
vários acessos e incorrer em tarefas que passem desapercebidas pela
quantidade de mensagens numa caixa postal sem receber tratativas.

Cenários podem ser tão detalhados quanto necessários para vislumbrar como seu

aplicativo responderá. Além do mais, quando você combinar esses cenários com

as personalidades ricas de suas personas, será possível avaliar suas decisões de

design e decidir se elas atendem às necessidades de seus usuários. (Lowdermilk,

2019, p. 67)

A estratégia dc utilizar cenários está no fato de a equipe obter

subsídios para situações cm que o desenvolvimento estiver fora das
metas propostas em relação às necessidades do cliente. Aliás, sempre
é importante que as narrativas, as personas e os cenários sejam cui­
dadosamente seguidos e que os usuários possam revisá-los e dar um
feedback sobre a coerência da construção das histórias.
Para Lowdermilk (2019), a combinação do manifesto com
as narrativas, as personas e os cenários deixará o desenvolvimento
do sistema mais perto das necessidades reais do usuário.

3.3 Criatividade e experiência do usuário

Os aplicativos crescem em número e também em recur­

sos. Novas plataformas surgem em ritmo acelerado, com novos
frameworks, o hardware ganha novos recursos e a nanotecnologia
 103

possibilitou processamentos mais rápidos. Níveis quânticos já são

uma realidade. Nunca se viveu uma atmosfera de tanta rapidez
no surgimento de novas tecnologias. Equipes de desenvolvimento
estudam hoje uma linguagem ou um hardware que amanhã pode
ser substituído. Cria-se um impasse ao se discutir qual recurso
utilizar ou se todos eles farão parte do sistema.
A ideia de que mais recursos serão utilizados em um sistema pode
atrapalhar a vida do usuário, e o que era para resolver suas neces­
sidades pode criar frustrações, pois não se encontram respostas em
várias alternativas em um momento de decisão dentro do processo
de navegação. Essa colcha de retalhos cm que se transforma um
aplicativo é fruto da ausência de foco no design centrado no usuário
e nas narrativas, nas personas e nos cenários não fundamentais para
manter a equipe no trilho correto.
No capítulo anterior, tratamos da importância de manter o de­
senvolvimento focado. Se não for assim, a criatividade pode sair dos
limites e elaborar-se um sistema que tem tantos recursos que eles
se tornam inúteis. Criam-se módulos que nem farão falta se forem
retirados do sistema. Muitas pesquisas com usuários, em relação
a aplicativos já prontos, apontam que algumas ou muitas funciona
lidades sequer foram exploradas, consumindo recursos de hardware
e, o que é pior, acarretando custo desnecessários para o cliente.

A criatividade não poderá ajudá-lo se você não tiver uma visão ou uma narrativa

para seu aplicativo. Vemos isso em aplicativos que estão repletos de intenções

criativas, mas que deixam a desejar quanto à funcionalidade essencial e ao seu

propósito. Esses aplicativos podem ser lindos no que diz respeito à aparência, mas

são virtualmente inúteis para nós. (Lowdermilk, 2019, p. 70)

104

A criatividade é vista como propriedade dos designers que lidam

com a criação de sistemas, visto que eles fomentam as melhores prá­
ticas que ninguém pensou antes. Já desenvolvedores lidam somente
com codificação e não se preocupam com o layout agradável ou outra
forma de navegação para aquela narrativa, pois não têm criatividade.
As crianças vivem um mundo de imaginação em que tudo pode
ser feito. Ser um astronauta e explorar a imensidão do Universo são
sonhos que podem ser realizados sem problema algum. Em noites
assombrosas, um monstro pode estar embaixo da cama pronto para
atacar ou uma toalha pode criar uma sombra assustadora. Um adul­
to diz que não existe monstro nenhum embaixo da cama, e faz
diferença para a criança se ele se abaixar e falar para esse monstro
sair e nunca mais voltar, mostrando à criança que ele está falando
com algo no qual também acredita. Contudo, essa criatividade vai
se perdendo com o passar dos anos. As pessoas censuram umas
às outras e, quando se dão conta, acabam desmerecendo algumas
brincadeiras e atitudes de criança. Por isso, felizes são aqueles que
adquiriram maturidade e sabem lidar com suas emoções, mas ainda
acreditam no poder criativo que todos têm.
Ed Catmull e Amy Wallace escreveram a obra Criatividade S.A,
na qual mostram como a Pixar atua no desenvolvimento das anima­
ções. Com relação à criatividade, os autores destacam:

Passei quase quarenta anos pensando a respeito de como ajudar pessoas inteligen­

tes e ambiciosas a trabalhar em conjunto de forma eficaz. Para mim, minha função

como gerente é criar um ambiente fértil, mantê-lo sadio e buscar as coisas que o pre­

judicam. Creio firmemente que todos têm potencial para ser criativos - qualquer

que seja a forma assumida pela criatividade - e que incentivar esse desenvolvimento
 105

é uma coisa nobre. Mas para mim são mais interessantes os obstáculos que surgem

no caminho, muitas vezes sem que percebamos, e prejudicam a criatividade que

está em todas as empresas que prosperam. (Catmull; Wallace, 2014, p. 11)

Para Lowdermilk (2019, p. 78), uma equipe que tem desenvolve­

dores que afirmam algo como ‘“Nâo sou criativo’ ou ‘Não sou artista,
então minha interface de usuário (UI, ou User Interface) será bem
básica’” é o mesmo que aceitar uma paleta de cores cinza ou a fonte
Comic Sans como as únicas alternativas para uma interface agradável.
Para ele, esse discurso revela que falta trabalhar com mais afinco.
E como um aplicativo sem inspiração ou que não foi bem pensado.
Os usuários já não são mais como antes, quando poucos aces­
savam aplicativos e tinham um hardware limitado. As conexões de
internet não permitiam pensar em vídeos via streaming. Filmes eram
alugados em locadoras de bairro, com um sistema de devolução que
exigia o rebobinamento das fitas, pois, do contrário, poderia haver
multa. Em caso de entregas com atraso, também eram cobradas
multas. Filmes eram aguardados após o lançamento em cinemas
e, quando disponibilizados, poderíam ser alugados, restando às pes­
soas entrar na fila de reserva.
Nessa época, o hardware limitava-se a conexões que podiam dei­
xar linhas ocupadas em casa para ligações externas, emitindo o tom
de ocupado. Nesse tempo, não se imaginava como seria como hoje,
com acesso à internet em celulares para pagamento de contas ou
contato com pessoas do mundo inteiro por meio das redes sociais.
Isso era coisa de filme de ficção.
106

Hoje, os usuários estão em contato com tecnologias e uma reali­

dade diferente. Estão mais exigentes. As reclamações sobre produtos
e serviços agora ocupam sites inteiros, especializados em mediar
conflitos entre consumidor e empresa. Fica em destaque quem não
atende a um consumidor conforme o que foi oferecido. Nas redes
sociais, existem grupos especializados em comentar sobre empresas
que não prestam serviços adequadamente, desde uma assistência
técnica até uma entrega de lanche (com foto postada mostrando
que não se sabe onde começa o recheio e onde termina o pão). Claro
que existem os elogios, mas sabemos que informações negativas
têm uma velocidade de propagação assombrosa, o que deve gerar
agilidade por parte de quem prestou o serviço ou foi responsável
pelo produto em dar uma resposta satisfatória para ganhar credibi­
lidade entre os usuários. E nesse cenário que os desenvolvedores se
encontram hoje em dia.

Nossos usuários estão se tornando um grupo mais experiente e mais exigente. Já se

foram os dias em que ficávamos satisfeitos com tempos de carga reduzidos ou com

recursos adicionais. Os usuários esperam ter uma experiência rica. Desejam obter

aplicativos que tenham sido projetados de forma inteligente e que sejam cativantes.

(Lowdermilk, 2019, p. 71)

As lojas de aplicativos estão, por exemplo, repletas de ferra­

mentas responsáveis por gerenciar a produtividade. Porém, nem
todos são sucesso de uso. Isso não se pode medir pela quantidade
de downloads, mas pelo quanto são efetivos nas mãos do usuário.
 107

Trata-se de acompanhar o feedback do cliente e entender o motivo

pelo qual ele escolheu aquele aplicativo, e não o outro desenvolvido
por sua equipe. O ideal é que nunca se chegue a esse ponto, que
a entrega da equipe seja de acordo com as necessidades do usuário,
mas não se pode fechar os olhos para os comentários negativos.
Um layout agradável, que tem uma UI que agregue valor ao apli­
cativo, sempre traz de volta o usuário que consegue navegar e tirar
proveito. As funcionalidades vêm logo após o design das interfaces;
é o que prende por segundos o usuário que está cada vez mais sensível
ao UI. Para Lowdermilk (2019), porém, não há interface mais sofis­
ticada ou que represente uma tendência no momento que consiga
consertar uma funcionalidade complicada ou uma navegação ruim.
Para desenvolver o espírito criativo, é necessário sair daquilo
que é chamado zona de conforto. Essa região é fruto da passividade
e da postura que se caracteriza por sempre se fazer a mesma coisa.
E acreditar que existe uma fórmula padrão para realizar aquilo que se
espera, cm que se está familiarizado com os mesmos procedimentos
e se pode contar com a certeza de que o resultado será alcançado
de qualquer forma. Se isso não acontecer, é que não está no padrão.
O fato é que, para desenvolver a criatividade, é preciso superar esse
obstáculo, mas é um processo que pode gerar dor - não física, mas
relacionada a sentimentos e padrões ou mesmo decorrente da expo­
sição diante dos colegas. Assim, sair da zona de conforto é o primeiro
passo para ser criativo.
108

Figura 3.1 -Saida da zona de conforto

Nesse ponto, entramos na zona do medo, na qual se acredita que

não há outra forma de se fazer aquilo que sempre foi feito. É comum
achar que padrões diferentes somente funcionam com outras pessoas,
e isso gera o medo de mudar, de fazer diferente. O que os outros vão
pensar se um de nós se arriscar em uma reunião de trabalho quando
for o momento de um brainstorm, por exemplo?
Vencendo a etapa anterior, passa-se para a zona de aprendiza­
gem. É o momento em que é preciso lidar com os desafios e os pro­
blemas propostos, pois, na zona de conforto, as dificuldades tinham
uma solução dento do padrão. Aqui, novas habilidades devem
ser desenvolvidas, como realizar um curso para aprender novas
técnicas de codificar ou um recurso fantástico para programar
 109

e até mesmo aprender a tocar um instrumento musical. Há um

paradoxo nesse momento, pois, assim como se quer vencer a zona
de conforto, ela se amplia até a zona de aprendizagem, já que foi
rompida a zona do medo.
E, felizmente, quando se chega a essa etapa, vem a sensação de
superação de barreiras que antes separavam as pessoas do crescimento
individual, como profissionais. Dessa forma, ampliam-se os sonhos,
as metas e os desejos, e os indivíduos passam a olhar os desafios
como oportunidade para crescimento. Assim, a criatividade pode
encontrar terreno fértil para lidar de forma diferente com as mesmas
situações do passado.

Admiro profundamente os desenvolvedores que são corajosos no que se refere

à criatividade: aqueles que assumem riscos e desafiam a sabedoria convencional,

independentemente de terem sucesso ou não. Ser criativo exige muita coragem.

Incertezas, coragem e criatividade estão onde a inovação prospera; e, embora

o terreno possa ser fértil, é necessário ter determinação para que o que quer que

seja possa criar raízes. (Lowdermilk, 2019, p. 73)

A criatividade tem a ver com busca, determinação. Não é uma

ideia inspiradora que surge quando algo cai na cabeça e dá um
estalo. Tem a ver com observação, curiosidade e, principalmente,
arriscar-se e não ter medo de falhar. Além disso, não se pode entrar
no mundo das idéias e não colocar a mão na massa, pois uma ideia
não executada é apenas um pensamento. Quantas vezes se deixa de
pôr algo no papel ou partir para sua execução, com receio de errar,
e alguém coloca em prática aquela mesma ideia? E não há como
convencer as pessoas de que se teve antes aquele insight, a não ser
que se registre todo e qualquer pensamento que vier à mente.
110

As equipes chegam à maturidade dos relacionamentos quando

podem contar com apoio na hora de discutir uma proposta para
resolver uma situação de um aplicativo. E o que sugerem as reuniões
diárias no método Scrum. São 15 minutos de oportunidade para
cada participante expor como está lidando com as atividades, desde
os sucessos até as frustrações. Equipes assim são intensos laboratórios
de criatividade, pois seus membros sentem-se à vontade mesmo
quando desanimados com o trabalho. E olhar para um quadro de
anotações e post-its coloridos e imaginar o fluxo do usuário e manei­
ras criativas como soluções para aquele projeto.
Lowdermilk (2019) menciona o livro Untitled: Thoughts on the
Crative Process, de Blaine Hogan, quando define o que é exigido do
indivíduo em relação à criatividade:

Sua visão deverá estar na proporção direta com o trabalho que você está disposto

a fazer para dar a vida a ela.

Conheço várias pessoas com muitas idéias realmente excelentes, mas somente

algumas delas acabam fazendo algo. E conheço menos pessoas ainda que acabam

fazendo um ótimo trabalho.

Talento raramente é a questão, caso você esteja se perguntando.

Não, a verdadeira questão é descobrir se estamos dispostos ou não a arriscar nossas

reputações para realizar o trabalho árduo, necessário para criar algo maravilhoso,

ou se preferirmos tomar o caminho mais fácil desvalorizando nossas idéias, regur-

gitando antigas visões e recriando aquilo que já conhecemos. (Hogan, 2011 citado

por Lowdermilk, 2019, p. 74)

A criatividade surge com trabalho árduo e não com a ideia

romantizada de que a inspiração vem como revelação única para
seres iluminados. Como mencionamos anteriormente, quando
 111

vemos o produto final, não temos ideia dos bastidores, do trabalho

incansável de pessoas que se dedicam a descobrir maneiras criativas
de solucionar os problemas.
Catmull e Wallace (2014) citam o desafio de criar uma animação
usando-se os recursos computacionais na década de 1970. Foram
horas de trabalho na Universidade de Utah, em uma época em que
a animação ainda era feita com acetatos. Para animar uma mão, ele
tirou um molde em gesso da própria mão para criar as linhas e gerar
os polígonos que seriam interpretados pelo computador. Para isso,
foram consumidas horas de trabalho e foi preciso acreditar que esse
desafio iria trazer conhecimento para o futuro da animação gráfi­
ca por meio de computador. Ele não ficou calado, desenvolvendo
as próprias idéias, e sim compartilhou seu projeto com colegas que
também estavam aprimorando novas formas de processar algoritmos
usando o disponível. O filme feito durou 4 minutos, mas
consumiu 60 mil minutos de intenso trabalho. Era um projeto para
ser apresentado em um evento na universidade que gerou espanto na
platéia. Não havia estudos nessa área até aquele momento. A recom­
pensa veio mais tarde, quando seu trabalho o levou a conhecer seu
sonho de infância: os estúdios da Disney.
Muitas idéias não precisam ser geradas em softwares editores
de imagem ou de prototipagem navegável. Tudo pode iniciar em
formas disruptivas com padrões de tecnologia. O papel e o lápis
são algumas delas.
Não é necessário ter talento ou dom para desenho no momento
de colocar as idéias no papel. No processo de desenvolvimento de
projetos da Google chamado Design Sprint, que consiste em entregar
uma solução em cinco dias, há uma fase em que todos da equipe
112

geram idéias com lápis e papel. Nessa fase, não se exige algo bonito,
mas a materialização da ideia que o membro da equipe quer divulgar
para os demais. Não se trata de dizer que no papel tudo vale, mas
é o início de várias etapas para entregas finais.
Muitas equipes mantêm blocos de papéis quadriculados no ta­
manho dos dispositivos, em versões retrato e paisagem, para serem
rabiscados, apagados e discutidos. Isso até pode gerar risadas ou
brincadeiras, mas vai depender da maturidade da equipe em absorver
esses momentos de descontração para deixar o ambiente mais tran­
quilo. Muitos desenvolvedores julgam que precisam ter habilidades
artísticas ou aulas de desenho. Porém, não se trata de fazer algo
comparável às belas-artes.
Lowdermilk (2019, p. 73) cita a conferência de 2002 da Agile
UX, em Nova York, quando Jeff Gothelf

explicou que, se você puder desenhar um triângulo, um quadrado ou um círcu­

lo, poderá desenhar praticamente qualquer interface de usuário. Eu concordo.

Diferentemente de codificar, desenhar exige um investimento menor de tempo

e proporciona a agilidade para transmitir rapidamente as idéias. Não há praticamen­

te nenhum comprometimento. Se uma ideia não estiver funcionando, você poderá

jogá-la fora e começar a fazer outro desenho. Diga-me o que é mais fácil jogar fora:

um esboço de cinco minutos contendo algumas formas básicas ou um exemplo

de código que levou cinco horas para ser feito? Não tenho mais nada a declarar.

Quadros brancos também são ótimas ferramentas tanto para

fazer anotações quanto para desenhar. O documentário História do
Google: o jeito Google de trabalhar (2010) apresenta toda a estrutura
que envolve uma seleção para contratar profissionais que desejam tra­
balhar em uma das maiores empresas na área de tecnologia. Durante
 113

o documentário, é mostrado como os colaboradores desenvolvem

seus projetos, e uma das ferramentas utilizadas é o quadro branco,
disponível em todos os ambientes onde as pessoas se encontram para
discutir as idéias. E não são pequenos - alguns podem tomar toda
a extensão de uma parede.
Em ambientes de startups, podemos encontrar várias dessas fer­
ramentas. São empresas com um layout diferente na disposição das
estações de trabalho, para que o profissional esteja mergulhado em
um espaço criativo. Divisórias entre as estações, às vezes de material
transparente, servem de suporte para anotações de idéias e discussão
de Huxos de atividades do usuário.
Com relação aos protótipos de papel, existem exercícios que
simulam a navegação entre as telas. Por exemplo, podemos encontrar
simuladores de entrega de camisetas impressas por sublimaçâo feitas
em caixa de papelão. Uma pessoa faz o papel de computador que
vai interagir com o usuário que navega nas telas feitas de papel.
Em dado momento, escolhe a camiseta com a arte que foi enviada
e a “máquina” imprime a camiseta. Claro, camisetas e telas já estão
prontas, mas podem gerar novas interações que, sem essa simples
prototipagem, com canetas, papel e caixa de papelão, seriam mais
complicadas de se imaginar.
Muitas empresas disponibilizam uma porcentagem da carga ho­
rária de seus funcionários para criar sistemas que não fazem parte
do fluxo do trabalho, mas cujo desenvolvimento acham importante.
Algumas pessoas acreditam em seus projetos pessoais, mas não desen­
volvem a ideia. Elas criam espaços, como os da cultura maker, que
é o “faça você mesmo”, para que que possam executar o projeto que
julgam ser relevante para a empresa.
114

Lowdermilk (2019) exemplifica essa liberdade de criação dada

aos colaboradores da empresa Atlassian, que cria ferramentas de
produtividade como o Trello. Os engenheiros de software têm um
dia reservado para trabalhar em projetos do jeito que quiserem,
somente com o compromisso de entregar o produto no prazo com­
binado. E chamado de Shiplt Day. Lowdermilk (2019, p.77) cita
o cofundador Mike Cannon-Brookes e explica que o funcionamento
basicamente é o seguinte:

às 14 horas de uma quinta-feira, o dia começa. Engenheiros, incluindo o próprio

Cannon-Brookes, mergulham de cabeça em um código novo ou em um hack ele­

gante - como quiserem, com quem quiserem. Muitos trabalham durante toda

a noite. Então, às 16 horas da sexta-feira, os resultados são mostrados ao restante

da empresa em uma reunião animada e barulhenta, com grande quantidade de

cerveja gelada e bolo de chocolate. A Atlassian chama essas 24 horas de explosões

de liberdade e de criatividade de "Shiptit Days" - porque as pessoas devem entregar

algo no prazo de uma noite. E os funcionários da Atlassian o fazem. Ao longo

dos anos, esse pequeno exercício singular produziu um conjunto de correções de

software que, de outra maneira, nunca teriam sido feitas.

Para terem uma ideia de criação, muitos recorrem ao hábito

de verificar o que se está desenvolvendo em outras empresas; na
internet, há vários portfolios interessantes para tomar como base.
E preciso ser muito meticuloso para não correr o risco de plagiar
as idéias, e o interessante é criar um banco de dados para inspirações.
Ferramentas como o Google Keep, para anotações de idéias, são
viáveis, já que podem coletar imagens e links, criar palavras-chave
para busca e compartilhar com outros colegas da equipe. Sites como
 115

CSS Design Awards' e Awwwards2 são fontes de idéias para questões

de layout. Uma ferramenta ótima para imprimir telas é a Full Page
Screen Capture, extensão do Google Chrome3 para captura da pá­
gina que, mesmo com barra de rolagem que passe a linha de corte
da tela, salva toda a extensão como um único arquivo.
Para criar um design centrado no usuário, é necessário ter curio­
sidade acerca de como os usuários se comportam diante de todos
os sistemas compilados em um banco de idéias. E importante fazer
diversas e variadas perguntas até para si mesmo. Por exemplo: Como
uma tela pode prender o usuário tanto tempo? Como a equipe che­
gou a criar aquelas interfaces? Será que usou algum grid como mode­
lo? O que não me agrada nesse layout?. O que eu posso melhorar no
meu desenvolvimento como profissional para criar telas amigáveis?

Essa investigação deve começar e terminar, pois, muitas vezes,

esses questionamentos empolgam e acaba-se não buscando as res­
postas para eles. E não é preciso navegar na internet para descobrir
como as pessoas estão usando as tecnologias. Basta andar pela rua
ou frequentar um shopping que é possível observar indivíduos intera­
gindo uns com os outros ou com dispositivos. Por exemplo, a rede de
lanchonete McDonald's instalou totens em algumas lojas na cidade de
Curitiba. Meus filhos se surpreenderam com o dispositivo e preferiram
interagir com ele, e o atendimento na fila ficou mais ágil. Não queria
apressá-los, pois estávamos passeando, então aproveitei para analisar
como é a navegação em um dispositivo incomum como aquele.

1 Disponível em: <https://www.cssdesignawards.com/> Acesso em: 11 dez. 2020.

2 Disponível em: <https://www.awwwards.com/>. Acesso em: 11 dez. 2020.

3 Disponível em: <https://www.google.eom/intl/pt-BR/chrome//>. Acesso em: 11 dez. 2020.

116

Fui fazendo perguntas enquanto eles navegavam na tela

touchscreen. "Como você achou tal produto?"; "Você já sabia o que
queria?". Eles ficaram na dúvida, pois eram tantas opções que ficaram
vendo qual era a que mais agradava, apesar de sempre consumirem
o mesmo prato. Recebi a confirmação da compra feita por cartão
e o comprovante de papel (ainda precisamos desse feedback) do nú­
mero da senha. Um painel intercalou os pedidos da fila com a aten-
dente com os feitos pelos totens até que chegou o pedido das crianças.
O mesmo lanche era entregue nos dois tipos de atendimento, mas com
uma experiência totalmente diferente.

Figura 3.2 -Telas touchscreen diferem em navegabilidade em relação

ao mouse
 117

No mesmo shopping, há totens para confirmar o pagamento do

estacionamento. Na fila para pagamento com o atendente, este opera
a entrada com o cartão do usuário e lhe entrega um comprovante de
pagamento. No totem, a pessoa tem a autonomia de clicar, porém
seguindo o Huxo sugerido pelas interfaces na tela.
Dessa forma, estamos caminhando para serviços automatizados
e precisamos saber qual é a preferência dos usuários. Eles querem
alguém para atendê-los? Como vão receber a automação de proces­
sos? Na hora de pagar uma passagem de ônibus urbano, sempre será
com um trocador ou sistemas serão implantados em todas as linhas
como já ocorre em algumas cidades?
No caso de se estacionar na rua, por exemplo, em algumas
localidades, o motorista precisa ter o aplicativo para realizar o paga­
mento da hora utilizada. Os talões de estacionamento estão acaban­
do. A experiência do usuário está cada vez dando mais autonomia
às pessoas, porém é necessário avaliar quais serviços e produtos
podem ter essas características.
Contudo, devemos admitir que a estética e o design correspon­
dem a uma parte bastante significativa da experiência do usuário.
Muitos desenvolvedores não têm acesso a uma equipe de designers,
portanto é preciso investir tempo explorando a própria criatividade
para alcançar as metas da experiência de usuário no aplicativo.
118

34 Metas de experiência do usuário

Com as histórias bem estruturadas em narrativas, personas e cená­

rios, todos eles alinhados à criatividade, mantém-se o foco nas metas
descritas centradas no usuário. No processo de desenvolvimento de
projetos, a equipe precisa concentrar-se nas atividades que tragam
experiências agradáveis ao cliente. Elas estão documentadas nos re­
quisitos e, também, nas tarefas desenvolvidas para criar as histórias.
As metas focadas no usuário permitem que a equipe trabalhe no
processo de interesse no que diz respeito ao que foi acordado entre
ela e a experiência descrita, por exemplo, nas personas. Elas podem
manter os recursos apresentados como favoráveis ao entendimento
ou indicar que as funcionalidades que desejam implantar vão deixar
mais complexa a navegação. Toda a documentação de protótipos
gerados e aprovados pela equipe é um guia para execuções que não
incorram em retrabalho de codificação e de geração de banco de
dados, por exemplo. Em atividade de freelancer, o profissional deve
sempre recorrer às documentações centradas no usuário para não
gerar conflitos nas etapas de entrega.

Exemplificando

Quando naveguei no s/te Quick, Draw!4 já tinha em mente que

era uma ferramenta para criar um grande banco de imagens para
alimentar uma inteligência artificial (IA). Nesse s/te, depois de eu
desenhar o que é solicitado, o sistema "adivinha" pelos traços o que
está ilustrado. São 20 segundos que a IA tem para descobrir. Depois

4 Disponível em: <https://quickdraw.withgoogle.com/> Acesso em: 11 dez. 2020.

 119

de esgotar a lista dos desenhos, é dado um feedback de quais ela

acertou e de quantos ela que errou e é apresentada uma relação
de ilustrações daqueles que também erraram. Para mim, começou
a ser uma diversão, mas, para o sistema, era uma coleta de várias
informações. A minha experiência foi agradável e divertida, o que
está dentro da meta proposta. Se o objetivo era colher produções dos
usuários, teria de ser criado um ambiente agradável, com estímulo
para a pessoa continuar em outro momento. Mais tarde, experi­
mentei um aplicativo no qual, quando o usuário desenha algo, são
sugeridas várias opções para aquele "rascunho" na forma de vários
exemplos em uma biblioteca, os quais podem ser editáveis.
shutterstock 1405996949
PRINCÍPIO DA
PROXIMIDADE
 123

A estrutura de um bom design segue alguns princípios que

dispõem todos os elementos na interface de forma organizada.
Não é simplesmente dizer que algo é belo e harmonioso, que está
combinando. Alguns julgam pela estética, outros pelo modismo,
mas a organização é fundamental para que o usuário tenha uma
experiência agradável e consiga chegar a seu objetivo.
A parte cognitiva é exigida quando o usuário está diante das in­
terfaces. E uma função psicológica, a qual diz respeito às percepções,
à memória, ao raciocínio, às associações, ao juízo, ao pensamento
e à linguagem. Portanto, são elementos que se combinam e que
fazem parte do estudo da psicologia, ou seja, são analisados antes
mesmo de existirem as interfaces. O processo que torna a experiência
do usuário agradável tem de levar em conta os elementos cognitivos
para que se compreenda a mensagem e se atenda às necessidades
do cliente. Somente levar em conta a estética não traz resultados
favoráveis ao usuário.
Os princípios de design são utilizados no estudo do compor­
tamento humano em relação a tudo o que o cerca. A busca por
reproduzir aquilo que agrada aos olhos foi realizada já na Grécia.
A proporção áurea (ou número áureo) foi estudada pelos gregos
e adotada nas artes (escultura e arquitetura) como a chave para se
chegar à forma perfeita, que permitiría ao ser humano reproduzir
nos objetos ou nos edifícios a mensagem da grandiosidade de deter­
minada civilização. A proporção áurea é um elemento encontrado
na natureza, principalmente na relação de alguns membros do corpo
humano, nas plantas e nos animais. Por exemplo, na disposição de
folhas e de pétalas das flores, foram encontrados padrões que mais
124

tarde foram estudados pelo italiano Leonardo Fibonacci, chegando-

-se à sequência de números que leva seu nome.

Ter um bom domínio dos princípios de design e de modelos previsíveis pode ajudar

você a criticar eficientemente o seu trabalho. É a linguagem perfeita para expressar

o que está correto ou o que está errado em um design. Além do mais, você pode

usar esses princípios para educar seus usuários, que, com frequência, têm dificul­

dades em expressar suas necessidades. (Lowdermilk, 2019, p. 88)

Como afirma Lowdermilk (2019), ao se reunir com os usuários,

os princípios ajudam na compreensão de como a navegação será
realizada, pois, com o vocabulário enriquecido pelas terminologias
apropriadas, dispõe-se de um instrumento mediador que garante um
entendimento mais significativo para o cliente. Sai-se do abstrato
e parte-se para algo tangível para o processo de entendimento.
Uma das teorias da psicologia que ganharam força no ambiente
de design foi a Gestalt, um estudo voltado à relação do ser humano
com o ambiente, seu comportamento diante da natureza e o motivo
pelo qual alguns objetos são compreendidos e outros não. Ela surgiu
no século XIX c busca entender melhor a teoria da forma.

A teoria da Gestalt, extraída de uma rigorosa experimentação, vai sugerir uma

resposta ao porquê de umas formas agradarem mais e outras não. Esta maneira de

abordar o assunto vem opor-se ao subjetivismo, pois a psicologia da forma se apoia

na fisiologia do sistema nervoso, quando procura explicar a relação sujeito-objeto

no campo da percepção. (Lowdermilk, 2019, p. 89)

Para os estudiosos da Gestalt, não conseguimos visualizar uni­

dades isoladas, mas um conjunto de elementos que formam o todo.
A forma só é entendida quando existe um contraste com o fundo.
 125

Um ponto preto, por exemplo, só é visto quando há diferença com

um plano de outra cor. Cada vez que o fundo se aproxima da cor
do ponto, menos contraste há e, por consequência, menos evidência
da forma do ponto.

Figura 4.1- Não enxergamos os objetos desconstruídos,

vemos apenas a unidade

iurii/Shutterstock

Na figura do carro desmontado, percebemos as partes que

compõem o veículo. São as unidades de que trata a Gestalt e que
formam um elemento maior. Não vemos os carros andando nas ruas
divididos dessa forma, mas, como suas partes estão próximas, nosso
cognitivo processa que é um veículo por inteiro.
126

Outro conceito estudado pela Gestalt é a pregnância do objeto

ou da forma. Uma interface, por exemplo, é compreendida tão mais
rapidamente quanto maior for sua pregnância. Quando há confusão
entre os elementos, ou seja, o usuário demora para entender a nave­
gação, isso resulta em uma baixa pregnância.
A Gestalt chegou a alguns princípios que serão estudados nesta
obra. Eles são os orientadores visuais para que a navegabilidade seja
realizada com sucesso pelo usuário.
O princípio da proximidade é um dos mais utilizados nas inter­
faces. Ele leva para o usuário a compressão dos objetos dispostos na
tela e a relação entre eles. Para Gomes Filho (2006), elementos óticos
próximos uns dos outros tendem a ser vistos juntos e, por conseguin­
te, a constituir um todo ou unidades dentro do todo. Quanto mais
afastados estiverem, menos relação o usuário estabelecerá entre eles.
Por outro lado, a proximidade será reforçada quando mais elementos
forem comuns entre os objetos (por exemplo, cores, tipo de letra,
linhas, formas geométricas).
Em termos de interfaces, o princípio da proximidade pode ser
compreendido quando colocamos texto como legenda de ícones
em um painel de controle. O ícone precisa do reforço do texto,
por exemplo, quando estamos diante de um aplicativo de banco
e vários serviços são disponibilizados. A organização espacial precisa
ficar correta, pois é um sistema que deve gerar credibilidade, já que
o usuário fará ações que levam em conta um investimento ou um
pagamento de conta. E necessário haver clareza na escolha do ícone,
o que se dá pela proximidade com o texto.
 127

Em uma tela em que há produtos para a venda, a descrição do

produto deve estar próxima da imagem e não gerar dúvidas na hora
da decisão da compra. Geralmente, os usuários fazem comentários
e avaliações do produto que está sendo adquirido.

É por isso que o princípio da proximidade pode exercer o impacto mais significativo.

Ao simplesmente organizar e agrupar itens de uma maneira que sua função seja

descrita, você poderá melhorar significativamente a experiência de usuário com seu

aplicativo. Um layout organizado faz com que seja mais fácil aprender a usar seu

aplicativo e exige menos do usuário para que ele possa encontrar os itens. Muitos

desenvolvedores ignoram esse princípio simples porque não reservam tempo para

refletir sobre como seus aplicativos deveríam estar organizados. Eles acham que

o layout de seus aplicativos faz sentido; enquanto isso, seus usuários ficam confusos

e frustrados. 0 princípio da proximidade pode ser usado como um poderoso indi­

cador deque determinados recursos devem estar juntos. (Lowdermilk, 2019, p. 89)

O aplicativo Figma é um editor de gráficos vetoriais e uma fer­

ramenta de prototipagem. Ele funciona com acesso por meio do
navegador e com versão desktop, além de apresentar vários recursos.
Como em diversos aplicativos, os elementos clicáveis são organiza­
dos em categorias para otimizar a produtividade do usuário. Os itens
do menu superior estão dispostos de forma que o usuário associe
os itens por proximidade, começando pelo menu “hambúrguer ”,
com acesso às funcionalidades do software. Como se trata de um
aplicativo para desenhos vetoriais, do lado esquerdo superior os íco­
nes são associados a figuras geométricas básicas e a uma caneta para
desenhar as linhas. Juntos estão os ícones para movimentar a página
para todas as direções, o de inserir texto e o de adicionar comentário.
128

Quando se clica no ícone das figuras geométricas representado

pelo quadrado, um submenu do contexto aparece, com a possi-
blidade de se criarem objetos além do quadrado, como uma linha,
uma seta ou uma elipse. Eles estão próximos para o usuário não
ter dúvidas de que está escolhendo os ícones relativos ao quadrado.
Os recursos de um aplicativo precisam ser orientados de maneira
a ficarem próximos um do outro. Principalmente para proporcio­
nar uma experiência agradável a fim de que o usuário volte a usar
o artefato, os ícones podem ter ainda uma legenda, ou labei, na
linguagem dos desenvolvedores, para não gerar dúvidas na escolha
das funcionalidades corretas.
Em muitos aplicativos, podemos ver várias categorias em forma
de ícones e suas legendas logo abaixo. Essas legendas são importantes
para o entendimento e devem estar perto dos ícones, para que não
haja confusão na escolha da categoria pelo usuário, ainda mais no
caso de busca de produtos para comprar.
Quando se trata somente de texto, a proximidade também orga­
niza os elementos para que, por exemplo, o resultado de uma busca
seja efetivo. Dessa forma, o usuário vai clicar no texto maior que está
relacionado ao conteúdo imediatamente abaixo dele. E um princípio
claro que traz a ideia de organização dos elementos na página e não
deixa o usuário confuso na navegação.

Nada é mais frustrante do que um aplicativo desorganizado. Isso exige que

o usuário percorra menus complexos e opções, procurando uma agulha virtual

em um palheiro. Esse processo reduz nossa eficiência e acaba com nossa paciência.

Organizar um aplicativo por proximidade ajuda os usuários a entender como seu

aplicativo funciona e permite que eles avaliem rapidamente as opções disponíveis.

(Lowdermilk, 2019, p. 90)

 129

A proximidade entre os elementos também passa a ideia do

todo, um conjunto de elementos que formam uma unidade maior,
como no caso da extrusão do carro mostrada na Figura 4.1. Uma
interface é compreendida nos segundos iniciais pela organização dos
elementos próximos.

Figura 4.2 - Painel de partidas e chegadas em um aeroporto

Vinícius Bacarin/Shutterstock.com

Como visto nos painéis de voos nos aeroportos, a interface deve

ter alta pregnância, pois seus conteúdos sâo decisivos para o usuário
acompanhar sua partida. Os logotipos das empresas estão próximos
da coluna do voo e, em seguida, vê-se qual aeroporto será o destino.
Essa associação é necessária para que não fique nenhuma dúvida
e a pessoa não corra o risco de perder sua viagem ou a conexão.
130

Na criação de formulários, os campos de preenchimento e de

opções devem estar claros e compreendidos pelo fato de que se trata
de dados que o usuário vai incluir. Os desenvolvedores utilizam
o recurso chamado labei, que é a descrição do conteúdo dos inputs
que serão armazenados no banco de dados. A confiabilidade que
o usuário deposita no sistema é fruto da consistência entre o que
ele preencheu e o que a interface apresenta na descrição dos itens.
A proximidade, no caso do formulário, fica evidente nos alinha­
mentos entre os campos e a descrição, entre o recurso de checkbox
e o item, entre os botões “editar o item” e “deletar”, que se torna de
grande risco para o sistema. Deletando a informação, o usuário não
tem como recuperá-la, e a frustração o leva a abandonar a página.
Para jogar cm videogames de console, o uso de joystick é funda­
mental para interagir com a interface. Os botões e os comandos
estão próximos o bastante para o jogador fazer associações rápidas,
pois são necessárias tomadas de decisão para prosseguir com o jogo.
A ergonomia, que estuda a relação dos objetos com o ser humano,
é imprescindível para propiciar conforto e, no caso dos videogames,
para fazer o usuário chegar até o final. Por isso, os botões têm
funções específicas no controle de joystick. Nos joysticks dos conso­
les, os botões e os comandos devem ficar próximos para favorecer
a jogabilidade.
 131

Figura 4.3 - Joysticks: botões e comandos próximos

favorecem a jogabilidade
yudha satia/Shutterstock

Outro reforço para o princípio da proximidade é quando

elementos apresentam as mesmas características. Até o momento,
mencionamos que os elementos devem ficar fisicamente próximos.
Porém, eles também podem fazer parte de uma unidade quan­
do têm aspectos como cor, traçado e tipos de letras semelhantes.
Um dos recursos usados pelos designers é manter uma proximidade
com a marca utilizada na interface.
132

Figura 4.4 - Interfaces: elementos devem manter as mesmas

características

Assim, o usuário é levado a um ambiente único, e as relações

formais, entre as cores e a marca, compõem a comunicação visual
das interfaces.
 133

41 Hierarquia e visibilidade

A hierarquia dos elementos está relacionada aos padrões esta­

belecidos no posicionamento e no tamanho. Sempre quando vi­
sualizamos uma interface, o sentido da leitura, no Ocidente, é de
cima para baixo e da esquerda para a direita. Algumas regiões são
mais valiosas, pois o usuário se atém, por exemplo, à tela na porção
do corte, que é a primeira página que é vista e representa a tela
do dispositivo. Na hierarquia relacionada à tela, o que está abaixo
da linha de corte do dispositivo apresenta informações secundárias
e, muitas vezes, irrelevantes, pois, para acessá-las, o usuário precisa
rolar a página para baixo.

Hierarquia nada mais é do que usar diferentes estilos visuais para os elementos da

tela de modo a priorizar o que é mais importante. Através de uma boa hierarquia,

é possível guiar os olhos do usuário pelo caminho que você deseja que ele percorra.

Qual a primeira coisa que você quer que ele leia ou veja assim que entrar no seu

site? (Teixeira, 2014, p. 75)

De acordo com o princípio da hierarquia, quanto mais próximo

da porção inferior da interface o elemento estiver, menos requisições
serão feitas pelo usuário. Informações importantes ficam acima da
linha de corte. Em sites de notícias, podemos identificar a aplicação
desse princípio pela opção de situar as manchetes do momento na
parte superior e as notícias que se desdobraram na semana ocupando
a parte inferior.
Quando elementos devem ser categorizados, o princípio da hie­
rarquia organiza os mais importantes na parte superior, por exemplo,
de um menu com submenu. Nem sempre é necessário colocar todas
134

as informações na interface quando se trata de categorias. O ele­

mento macro fica em destaque, e o que estiver subordinado a ele
será visualizado logo abaixo, com efeitos que otimizam os espaços.
Outra utilização que deve ser observada em relação à hierarquia
é com relação aos textos. Títulos, subtítulos e conteúdos devem ficar
claros quando se coloca peso no tamanho. E indicado usar tamanhos
distintos e trabalhar com poucos tipos de letras, pois isso reflete
a organização dos textos distribuídos na tela. Deve-se ter cuidado
com frases ou textos aplicados em cima de imagens, pois é preciso
haver um contraste para não prejudicar a leitura.

figura 4.5- Textos devem seguir hierarquia de

tamanho entre título e subtítulos

Zaur Rahimov/Shutterstock
COMPANY
LOGO Headline ROLL UP
TEMPLATE
DESIGN
ANNUAL
REPORT' -> LOREM

STATISTICS -> DUMMY

ANALYTICS -> PRINTING

-> TYPESETTING

REPORT -> INDUSTRY

STATISTICS
ANALYTICS
CCMWft
IOOO

•ooo
•
oooo
COMPANY
LOGO
 135

Como definir quais elementos têm maior peso e importância

para o usuário, principalmente quando o cliente deseja ter mais
informações além daquelas acordadas em reunião? Algumas práticas
são sugeridas para que o campo visual da interface não seja prejudica­
do, quando se trata de organizar elementos para obter alta pregnância.
Lowdermilk (2019) sugere a utilização de um recurso chamado
diagrama de afinidades, ou seja, assuntos que têm relação devem
manter a proximidade, primeiramente, e depois ser categorizados.
O autor destaca que isso tem sido de valor inestimável para esse tipo
de desafio, que consiste no processo de posicionar os recursos do
aplicativo (tipicamente por meio de notas adesivas, como o post-it)
e organizá-los em grupos que façam sentido. Assim, utilizam-se cores
fortes para destacar os elementos entre si e marcadores para desenhar
pontos nas notas e indicar outros aspectos que o usuário queira ver.
As cores dos marcadores e das notas adesivas possibilitam perceber
padrões rapidamente c permitem obter diferentes organizações.
Lowdermilk (2019) utilizou o diagrama de afinidades no projeto
de um portal com diversas informações, como política, aplicativos
e gráficos, que devem ser distribuídos de forma organizada e hierár­
quica, o que se obtém rapidamente com esse recurso.
Para pôr em prática a hierarquia, Teixeira (2014, p. 79) reco­
menda algumas práticas para que se consiga atingir a organização
das informações:

• Organize itens similares com visual similar.

• Evite inconsistências. Utilize o mesmo estilo visual para elementos que têm fun­

ções parecidas. Estilos visuais inconsistentes causam confusão para o usuário

e deixam a interface poluída.

136

• Use cores para diferenciar as ações principais. Use o contraste a seu favor para

atrair o olhar do usuário para a ação que você quer que ele faça.

• Categorize. Agrupe links por temas, em vez de simplesmente listá-los na tela.

• Use tamanhos de fonte diferentes para criar hierarquia na página, mas limite

a quantidade de tamanhos de fonte para manter harmonia.

• Tenha um bom equilíbrio de textos e imagens. Lembre-se que, dependendo da

tarefa que o usuário está realizando, imagens nem sempre são bem-vindas. Se

ele está no meio de um processo de pagamento, imagens podem acabar tirando

o foco da ação principal que você quer que ele faça.

A visibilidade diz respeito a alguns recursos que são impor­

tantes para manter o foco do usuário no processo de navegação
e ter uma experiência agradável com o sistema. Lowdermilk (2019)
destaca algumas características desse fator, as quais veremos a seguir.

Tipos de letra
São importantes porque destacam as seções e passam as informa­
ções ao cliente. Primeiramente, deve-se prestar atenção à ortografia,
pois, conforme o tipo de usuário, erros de escrita fazem com que
o aplicativo perca a credibilidade. Sempre é importante ter revisores
na equipe, os quais podem ser os de conteúdo, que analisam se
as informações sâo pertinentes ao escopo do projeto, e os de lingua­
gem, que verificam a escrita ou os erros de digitação.
São também trabalhados os destaques em termos de tamanho da
fonte e peso, como vimos anteriormente. Textos com fontes maiores
são visíveis naturalmente e demonstram importância. Outro recurso
são estilos que podem variar até mesmo quanto ao conteúdo, com
 137

o uso de bold para destacar informações. Também é comum utilizar

o itálico, mas não um misto de itálico com bold, pois esteticamente
não fica agradável. Outra situação que deve ser evitada é o emprego
de diversas famílias de fontes, pois isso ocasiona confusão visual
e a experiência para o usuário será comprometida.

Opacidade
A opacidade ou transparência é alterada no sentido de aumentar
ou diminuir, com os elementos sobrepostos ou próximos. Esse recur­
so é utilizado, por exemplo, quando se coloca um menu superior em
cima de uma foto. O menu pode ficar confuso com a imagem logo
abaixo dele, e a opacidade é considerada colocando-se um elemento
entre a foto e o menu. Assim que a opacidade diminui cm termos
de porcentagem, é possível visualizar os itens do menu sem retirar
a foto da página.

Proeminência
E um recurso utilizado que lembra a hierarquia por tamanho.
Elementos com destaque no tamanho são visíveis antes dos demais
de tamanho inferior. Quanto mais próximos eles ficarem, mais visi­
bilidade será ordenada pelo elemento maior, e, em seguida, o usuário
navegará para os elementos menores. Por exemplo, em fotos de pro­
dutos de sites de e-commerce, a foto principal é visível, até porque
é necessário dar destaque a alguns detalhes. Imagens menores ficam
restritas à opção de serem clicadas ou não pelo usuário.
138

Status
Esse método diz respeito à condição da ação do usuário.
Quando a página está sendo carregada, recursos gráficos como
texto e animação passam o feedback para o usuário sobre o que
está ocorrendo após uma ação. Ele quer saber, por exemplo, se um
e-mail que estava aguardando já chegou a sua caixa postal. Outra
forma que hoje os sistemas usam para definir o status do usuário
é pelo acesso ou não a algumas páginas. Por exemplo, sites que fun­
cionam com sistemas de assinatura informam o status do usuário
(se está efetivado ou não) pela mensagem geralmente destacada
com o perfil ativo no cabeçalho.
Outra forma são as barras animadas. Por exemplo, no caso de
um arquivo que está sendo baixado, o usuário deve acompanhar
o quanto já foi feito do download, qual o total do tamanho do
arquivo e quanto tempo resta para completar a ação. Qualquer
falha deve ser comunicada de forma destacada para que o usuário
faça novamente o download.
Um status muito utilizado é criado em situações de videoconfe­
rência quando o microfone ou o vídeo devem estar desativados em
reuniões. Sons e vídeos podem prejudicar a transmissão cm termos
de velocidade, pois sobrecarregam a rede, e até mesmo podem gerar
situações embaraçosas, como temos acompanhado neste tempo em
que várias empresas colocaram seus empregados em home office.
Nas abas dos navegadores, alguns aplicativos e sites utilizam recur­
sos de animação para indicar o tempo cronometrado, por exemplo.
E o caso do site The Pomodoro Tracker1, voltado à produtividade.
Um ícone gira enquanto o tempo passa até atingir a próxima etapa.

1 Disponível em: <https://pomodoro-tracker.com/>. Acesso em: 11 dez. 2020.

 139

Cores
As cores sâo elementos que trazem destaque ou desorganizam
visualmente a interface e devem ser criteriosamente empregadas.
Geralmente, acompanham as cores da marca e seu uso deve dar
oportunidade para aqueles que enxergam de maneira diferente,
como os daltônicos e os deficientes visuais. As cores não podem ser
decisivas na escolha dos itens, se não houver um texto alternativo
para a acessibilidade ocorrer. Na codificação, o uso das tags Alt ou
Title são eficientes nesse momento, pois os leitores de texto vão
sintetizar essas tags em voz para os deficientes visuais, no caso de
terem recursos de voz instalados em seus dispositivos.
Para os daltônicos, é importante haver contraste entre as cores.
Para isso, são utilizados alguns recursos em navegadores que desta­
cam o contraste ou o script-, quando acessados pelo usuário, realizam
o contraste na página. Essa ação afeta tanto o texto quanto as imagens.
Para um daltônico para o vermelho, não será visto o contraste entre
dois elementos vermelhos, sendo que um deles não corresponde
a essa cor. Fica prejudicada, dessa forma, a experiência do usuário.
Aplicativos de organização de tarefas podem apresentar o recurso
de visualização de etiquetas para que os usuários possam determinar
que categoria está associada ao projeto. Assim, podem usar cores
para possibilitar que se reconheçam as categorias mais rapidamente.
Mas como tratar as cores para que um daltônico possa re­
conhecer de imediato as categorias? A solução é criar diferentes
hachuras para cores específicas, sem prejudicar o usuário que tem
essa deficiência.
140

Quando o usuário está preenchendo um cadastro no input de

senha, é solicitado que ele crie uma que tenha segurança forte. Em al­
guns casos, conforme ele digita a senha, uma barra colorida indica
se ela é forte ou fraca, possibilitando alertas de segurança para ele.
Outro elemento destacado por Lowdermilk (2019) em relação
à visibilidade é o do feedback visual. Imagine andar com o carro
sem saber o nível de combustível do tanque. No painel dos veículos
constam várias informações, inclusive um alerta sobre o nível de
combustível. Com sistemas, aplica-se a mesma idcia. Ao solicitar
alguma ação na interface, o usuário espera ser informado, e nâo
ficar alheio ao sistema. O feedback visual é a garantia de que algo
que foi solicitado pelo usuário vai ter retorno, como no caso de um
resultado de busca em que ele procurou por um termo e alguns
itens foram trazidos à tela.
Quando aparece o resultado, o usuário tem a garantia de que
algum ou todos os dados informados podem satisfazer a seu pedido.
Porém, quando se faz uma busca e não há retorno, a interface deve
apresentar alguma informação do tipo: “Não foram encontrados
registros, tente alterar os termos da busca”. Isso porque, se somente
uma tela em branco aparecer, o usuário poderá ficar algum tempo
esperando e, por fim, achar que o sistema não está funcionando.
Outro feedback visual importante é por meio das imagens.
Ao passar o mouse sobre elas, podemos notar que algumas apresen­
tam o recurso tooltip, que é a descrição daquela imagem. Em alguns
sistemas, já existe uma inteligência artificial que descreve a tela, mas,
quando não houver, será necessário implementar esse texto alterna­
tivo na codificação, como citado anteriormente no item “Cor”, para
fins de acessibilidade, utilizando-se as tags Alt ou Title. São elas que
 141

funcionam como uma espécie de legenda das telas, muito utilizadas

quando o tempo de carregamento era demorado, sendo que, no lugar
das imagens, aparecia o texto alternativo e depois a foto era carregada.

Em outras palavras, seu aplicativo deve apresentar algum tipo de indicação de que

recebeu informações do usuário. Um exemplo simples desse caso seria disponibilizar

um ícone giratório ou uma mensagem de "procurando..." quando um usuário

submeter uma solicitação de busca. A questão geral do princípio de feedback visual

é notificar o usuário de que houve uma interação. Sem essa confirmação, o usuário

fica confuso a respeito de a sua ação ter sido recebida ou não pelo aplicativo.

(Lowdermilk, 2019, p. 91)

Sempre que um sistema é acessado pela primeira vez, os desen­

volvedores se perguntam se o usuário terá uma experiência agradável
e se terá sucesso em sua navegação. Muitos utilizam manuais em
PDF, com o passo a passo sobre como usar o programa, ou realizam
treinamentos presenciais ou com tutorials em forma de vídeo, mas
alguns recursos são usados como guias que facilitam a compreensão.
São os balões, que são sinalizadores dos elementos com funciona­
lidades importantes que estão dispostos na interface. Eles precisam
ter um texto objetivo para que não tome o tempo do usuário, e para
cada click outro balão aparece em outra funcionalidade. Após a ins­
trução, o usuário pode acessar com uma compreensão melhor, junto
com os materiais disponibilizados, como manuais e tutoriais.
Para Lowdermilk (2019, p. 93),

problemas com visibilidade e feedback visual adequado são os mais comuns de

usabilidade que vejo nos aplicativos. Sempre que ouço um usuário reclamar dizendo

que uma interface é confusa ou difícil de ser compreendida, começo a examinar

maneiras pelas quais eu poderia estar violando os princípios de visibilidade.

142

O feedback visual é uma maneira de deixar o usuário confor­

tável pelas ações que está realizando na interface, mesmo que esta
não apresente problemas, mas haja dificuldades encontradas no
nível de hardware. Como explica Lowdermilk (2019, p. 93), "Seu
aplicativo deve fornecer mensagens apropriadas de status con­
tinuamente. Nunca permita que seu usuário questione se o seu
aplicativo continua funcionando. Se o seu aplicativo exigir algum
tempo de processamento para atender a uma solicitação, informe
isso ao usuário".
As mensagens tratadas no feedback sempre devem ser orienta­
doras e esclarecedoras, eliminando-se toda forma de ambiguidade.

« Análise da tarefa

A análise de tarefas é o acompanhamento das atividades do usuá­

rio cm trabalhos que são pertinentes ao aplicativo. As tarefas podem
ser desde um simples login até um preenchimento de cadastro ou.
ainda, ações mais complexas. São atividades que exigem um roteiro
que descreva passo a passo o que se deve fazer e o que implica
cada ação. Dependendo da equipe do projeto, o acompanhamento
pode ser presencial ou com a execução sendo analisada pelo que
foi efetuado no aplicativo, por exemplo, se o cadastro foi realizado.
O usuário recebe as instruções, e a experiência de navegação será
avaliada pelo nível de dificuldade em realizar as tarefas. Os procedi
mentos precisam ficar claros na hora da elaboração das ações, pois
deve ser observado se a estrutura da apresentação das atividades está
 143

correta, sem prejudicar a compreensão da interface. No momento

de estruturar o roteiro, a equipe deve estar atenta em relação ao que
precisa ser monitorado e o que deseja de retorno do usuário.
A estrutura de conexão, o sistema operacional e o processador
são itens que influenciam, por exemplo, o desempenho da máquina
e o carregamento dos aplicativos. Nesses casos, são necessários equi­
pamentos que não frustrem a análise de tarefas cujo foco é o sistema.
Nielsen e Loranger (2007) utilizam o método chamado pensan­
do em voz alta, no qual os usuários são colocados separadamente
para que os comentários sobre como o colega está navegando não
influenciem o outro. Eles utilizam o dispositivo pelo qual será feita
a tarefa, e o moderador vai dando as instruções conforme o desen­
rolar da tarefa. O observador anota todos os pontos importantes
que são decisivos para a experiência do usuário e, se houver mais
observadores, uma sala com espelho separa o usuário para que não
fique apreensivo.
Esse ambiente de teste incita o usuário a expressar suas interações
com o sistema, desde o que está correto e compreensível até o que
causa demora ou não foi encontrado.

É interessante saber que os usuários, por exemplo, clicaram no botão errado e não

puderam fazer check-out, isto é, concluir uma operação de compra, em site de

comércio eletrônico. Mas se quiser aprimorar o processo de check-out e, assim,

aumentar as vendas, você precisa saber por que as pessoas clicam nos botões

errados. (Nielsen; Loranger, 2007, p. 6)

Nielsen e Loranger (2007) fazem uso de equipamentos de gra­

vação de telas e de áudio, com os comentários acerca do processo
144

de navegação. Quando são necessárias correções, a equipe não

chega a revisar o vídeo, pois os problemas de design são reconhe­
cidos na hora pelos observadores. A fim de realizar uma pesquisa
mais profunda, recorre-se às gravações.
Foram fornecidas de três a quatro tarefas para serem realizadas
em um total de 25 sites, de comércio eletrônico a notícias. Todos
os usuários tinham as atividades em forma de texto e, por mais que
o número de ações fosse pouco, seriam observados pontos críticos.
Nielsen e Loranger (2007, p. 12) descrevem como as tarefas
foram realizadas com os seguintes detalhamentos:

• Visite [...]2 e descubra o custo do envio de um cartão postal para a China.

• Visite [...] e encontre o nome do membro do governo municipal responsável

por uma das áreas dessa cidade.

• Você está planejando uma reunião familiar em Sugarloaf Ridge, California. Visite

[...] e faça uma reserva para uma área de camping, que possa acolher 35 pessoas.

• Você está procurando algo para comer durante seus exercícios. Visite [...] e veja

os produtos que essa empresa de alimentos oferece.

• Visite [...] e verifique se você pode descobrir de onde veio a ideia do filme

Monsters, Inc. /Monstros S.A].

[...]

• Você lê um artigo sobre como a tecnologia de células de combustível pode mudar

o mundo. Visite [...] e procure as duas principais vantagens e desvantagens da

tecnologia das células de combustível.

Nielsen e Loranger (2007) destacam que todas as tarefas

apresentadas para os usuários eram possíveis de serem realizadas.

2 Optamos por omitir os sites indicados na descrição.

 145

“Observamos as várias dificuldades simplesmente vendo-os tentar

fazer as tarefas que um site supostamente suporta, portanto, isso
é tudo o que testamos” (Nielsen; Loranger, 2007, p. 12).
Esses são exemplos de tarefas direcionadas com instruções
específicas, em que se pode controlar o que o usuário pode fazer.
Dificuldades são bem pontuais, já que a autonomia é retirada dos
internautas nessa etapa.
Em uma próxima fase, Nielsen e Loranger (2007) relatam que
as tarefas são apresentadas, porém os usuários podem acessar quais­
quer sites, ou seja, têm autonomia para decidir onde realizar as pes­
quisas. Esse cenário é o mais parecido com o mundo real. O ponto
negativo, afirmam os autores, é não conseguir controlar os sites em
que os usuários navegam para que outros possam também fazer
uso dos mesmos endereços. “A vantagem é que podemos ver como
as pessoas criam suas soluções em diversos sites, como quando não
estão no laboratório” (Nielsen; Loranger, 2007, p. 13).
Segundo Nielsen e Loranger (2007, p. 13-14), as tarefas consis­
tiram no seguinte:

• Você e a sua família estão interessados em passar férias em Mazatlan, México.

Encontre um pacote de viagens que seja atraente e esteja ao alcance da sua família.

• Você tem algum tempo extra durante a semana e quer fazer algo para ajudar

a comunidade. Encontre um programa de serviço comunitário adequado para você.

• O tio George está pensando em comprar um computador pessoal para sua re­

sidência. Ele irá utilizá-lo principalmente para navegar pela Web, para acessar

e-mails e para imprimir fotografias digitais. Encontre um computador que você

recomendaria a ele.
146

• Descubra o que é um "let" no jogo de tênis.

[...]

• Um bom amigo queixa-se de dores de palpitações que normalmente se irradiam

a partir de um dos olhos até a testa, têmpora e bochechas. Do que seu amigo

poderia estar sofrendo?

Os sites foram analisados e as impressões de cada usuário fo­

ram acompanhadas por alguns dos representantes das empresas
visitadas. Para alguns usuários, foram apresentadas as gravações
das telas para que se fizessem análises mais profundas. Todos os
sites visitados foram implementados há mais de 10 anos. Podemos
questionar se esses sites seriam válidos para análise no momento
atual, pois muito da tecnologia mudou. Nielsen e Loranger (2007,
p. 7) declaram que

Os princípios e as diretrizes que uma captura de tela ilustra são relevantes por

muito tempo depois que um site mudou. Na realidade, muitas descobertas a partir

dos nossos testes de usuários em 1994 continuaram ocorrendo nos estudos em

2006 e provavelmente serão encontradas novamente por testadores sem sorte

em 2020 e depois.

As tarefas devem ser estruturadas para manter o foco do usuário

naquilo que precisa ser realizado, sendo importante categorizá-las.
Se tem de acessar o site como visitante, ele não pode ter permissão
para entrar no perfil de qualquer usuário e ver que o que observa nas
telas é a experiência de alguém sem cadastro. Para que sejam analisa­
das as tarefas de um usuário com perfil de acesso, deve-se conduzi-lo
à tela de cadastro para que efetue o preenchimento do formulário
 147

ou fornecer e ele um login e uma senha para que a navegação seja

analisada por outro contexto.

0 desafio de percorrer uma análise de tarefas com os usuários ocorre, em geral,

porque eles querem descrever todos os aspectos da tarefa, tudo de uma só vez.

Se não for cuidadoso, sua análise estará repleta de passos confusos, fora de sequência.

Os usuários nem sempre têm a habilidade de explicar as tarefas que executam. Com

mais frequência do que se espera, eles fornecem detalhes insignificantes ou deixam

de lado passos cruciais. Não é culpa deles. Eles não sabem que os desenvolvedores

pensam em termos de loops e de instruções condicionais. Eles não entendem que es­

tamos pensando na tarefa e tentando aplicar Os e Isaela. (Lowdermilk, 2019, p. 118)

Para a análise de tarefas, Lowdermilk (2019) segue pela mesma

linha de informar um cenário e, em seguida, passar a ação proposta
para o usuário. Como trabalha cm hospital e é responsável pelo
portal da instituição, o autor criou situações que podem, a princípio,
parecer embaraçosas, mas que fazem parte da rotina desse ambiente.
Ele cita um dos cenários e, cm seguida, a tarefa: “Tudo bem, vamos
recapitular. Suponha que meu braço tenha sido decepado e que
acabei de chegar à emergência. O que acontece a seguir?”, indaga
Lowdermilk (2019, p. 118) ao usuário.
Parece-nos uma cena terrível, mas foi retirada de um contexto
em que possivelmente deve acontecer. E quando os usuários relatam
situações que não fazem parte do roteiro ou do escopo do projeto
ou que parecem ser a solução para resolver o problema, mas saem do
foco do projeto? Nesses casos, eles devem ser guiados para que perma­
neçam nas atividades relacionadas, informando-se que essas situações
serão anotadas para, quem sabe, fazer parte de futuras atualizações.
148

Lowdermilk (2019, p. 118) exemplifica quando os usuários

adiantam situações ou usam termos técnicos para explicá-las:

Também procuro interrompê-los, caso eles se adiantem demais, e peço que expli­

quem os acrônimos ou os termos técnicos. Além do mais, é crucial que você repita

o que compreendeu aos usuários. Com frequência, será algo assim: Então, deixe-me

ter certeza de que entendi o que você está dizendo. Você disse que seu primeiro

passo consiste em ir até o scanner; em seguida, você chama o aplicativo de scanning

no computador, e depois você... É incrível como é fácil interpretar incorretamente

o que os usuários estão nos explicando. Somente ao repetir minhas percepções,

posso ter certeza de que entendi corretamente suas explicações.

Em situações na quais o usuário relata termos que não são

da área de domínio da equipe, o procedimento seguinte é buscar
o entendimento, pois podem estar nas entrelinhas da explicação
as informações necessárias ao bom desempenho do sistema.

43 Heurística

A avaliação heurística é realizada seguindo-se os princípios

defendidos por Nielsen e Loranger (2007). São diretrizes que
mapeiam problemas que se referem à interação do usuário com
as interfaces. A avaliação consiste em observar o comportamento
do usuário em relação à interação com os sistemas e levantar quais
ações seguem ou ferem esses princípios. Vejamos as 10 diretrizes
que foram destacadas por Nielsen (1994) no artigo 10 Usability
Heuristics for User Interface Design {10 heurísticas de usabilidade
para o design de interface do usuário).
 149

1. Visibilidade do status do sistema

Já discutimos esse princípio anteriormente. Basicamente, trata-se
de criar feedbacks para o usuário que correspondem ao que se está
esperando do sistema. Por exemplo, pode-se clicar em um botão
e esperar que a ação se concretize com uma animação de load.

2. Correspondência entre o sistema e o mundo real

O sistema deve ser feito para o mundo onde o usuário se encontra,
e não o contrário. A equipe não pode criar um contexto dentro
do sistema no qual os usuários não veem familiaridade com termos,
ícones ou imagens. Por exemplo, um sistema para biblioteca deve
conter vocabulário próprio, com termos como livros, empréstimos,
reservas, ISBN, títulos e outros que sejam reconhecidos quando o usu­
ário for emprestar, cadastrar ou devolver uma obra, conforme seu
perfil. Outro exemplo é um site de peças de motocicletas que deve
ter nomes de peças que, muitas vezes, não são próprios do dia a dia
de um desenvolvedor c por isso não podem ser adaptados. Os£<w»m
também dispõem de termos que são utilizados no mundo real e são
muito críticos quando algo não tem correspondência com um usu­
ário desse público.

3. Controle e liberdade do usuário

Sistemas engessados somente dificultam a experiência do usuário.
Quando alguma ação é realizada e não leva para onde o usuário
precisa, o sistema deve apoiá-lo em recursos para voltar ao estado
anterior ou a outro de que ele tenha conhecimento.
150

Um exemplo é o ícone “Voltar” dos navegadores. Muitos sites não

deixam claras as ações de retornar, e o usuário recorre ao navegador
para executar essa ação. Se não existisse essa alternativa, o internauta
teria de sempre acertar na navegação, sem cometer erros ou entrar
acidentalmente em alguma página.
Um botão “Cancelar” também é uma forma de o usuário desfazer
suas ações caso não queira prosseguir com o formulário. Em muitas
situações, o “Voltar” do formulário pode recuperar dados já preen­
chidos e continuar daquele ponto.
Isso é representado também pelo “Desfazer” de muitos aplicati­
vos, como no caso de um efeito aplicado no editor de imagem que
não teve bom resultado. Basta seguir para o “Desfazer” ou procurar
uma janela de histórico com todas as ações realizadas desde quando
o arquivo foi aberto.
Uma alternativa é o breadcrumbs, ou “migalhas de pão”, que
oferece ao usuário qual histórico pertence à página em que ele está.
O controle do usuário deve ser permitido principalmente nos
dispositivos com touchscreen, em que é muito comum clicar no
ícone errado acidentalmente por haver regiões pequenas. Trata-se
de permitir ao usuário o controle de suas ações, e não de fazer com
ele seja controlado pelo aplicativo.

4. Consistência e padrões
As ações que os usuários realizam devem ser as mesmas interna­
mente ao sistema e também quando se usam padrões externos.
Quando, por exemplo, os links são na cor cinza e em dados
momentos se tornam laranja, o usuário não fica seguro, pois foi
 151

quebrada a consistência interna. Uma página com ícones no menu

superior deve permanecer assim em todo o sistema, pois os usuários
criam padrões quando seguem a navegação.
A consistência externa refere-se aos padrões que já são comuns
aos usuários. Para Nielsen (1994), o usuário já passou por muitos
sites antes de encontrar o ideal, então os padrões desse universo de
sistemas já fazem parte de sua rotina. Por exemplo, em um site de
compras, a pessoa vai realizar a ação de comprar por meio do ícone
“Carrinho de compras”, que já é aceito por todos os usuários. Outro
exemplo é o ato de deletar as informações, já convencionada pela
imagem da lixeira. Caso queira quebrar algum padrão, deve-se ter
certeza das consequências de se fazer algo novo.

5. Prevenção de erros
Os usuários podem ter uma experiência desagradável quando,
por exemplo, clicam no botão “Enviar e-mail” e acabam percebendo
que não poderiam ter enviado a mensagem. Aí, já é tarde demais.
Nesse caso, é necessário enviar outro e-mail para desconsiderar o an­
terior. Entretanto, alguns aplicativos de e-mail, já prevendo esses
deslizes, criaram a funcionalidade de “Desfazer o e-mail” antes de
completar a ação, para não precisar desligar o dispositivo, algo mais
radical. Essa funcionalidade é uma antecipação que auxilia os usuá­
rios e que não gera arrependimento pela ação.
Outro recurso utilizado é quando, por exemplo, um jogo não
terminou, mas o usuário precisa sair e o sistema alerta que será
desconsiderado todo o progresso, fazendo a pergunta: “Tem certeza
de que deseja sair?”. Em smartphones, é comum o usuário deletar
arquivos para liberar espaço no armazenamento. Antes de apagá-los,
152

o sistema pergunta se ele tem certeza de que deseja deletar as fotos.

E o momento em que o usuário reflete se continua a ação ou se
precisa realizar um backup.

6. Reconhecimento em vez de recordação

Trata-se de minimizar o lado do usuário em lembrar as ações que
realizou ou que precisa refazer. Por exemplo, nos leitores de livros
digitais, as páginas as quais o usuário terminou de ler podem ser re­
cuperadas pela funcionalidade das anotações. Basta acessar o ícone
que lembra um marcador de página e escolher entre as marcações
realizadas naquele livro.
Nâo se deve superestimar o usuário, mas criar condições para
que seja possível recuperar informações ou ações. Por exemplo, em
aplicativos de banco, como são sistemas especialistas e lidam com
as finanças do cliente, os recursos devem sempre estar nas mesmas
posições já utilizadas anteriormente. Editores de imagem dispõem
de recursos de gravar a área de trabalho para que o usuário encontre
as ferramentas sempre no mesmo local, mesmo que o editor seja
compartilhado com outros.
O reconhecimento tem mais pistas para lembrar a pessoa de
realizar as ações. O ato de recordar exige mais processos cognitivos
e pode causar frustação ao usuário.

7. Flexibilidade e eficiência de uso

Os sistemas devem oferecer para algumas ações caminhos alter­
nativos que definem se os usuários são experientes ou estão iniciando
o aplicativo pela primeira vez. O ato de recortar, por exemplo, em
alguns sistemas é acessado pelo menu “Editar” e depois pelo item
 153

“Recortar”. Pode ser usado também com o ícone de uma tesoura,

comum nos sistemas. Para os mais experientes, basta acessar o atalho
do teclado pelo Ctrl + X.
Outra forma de encontrar essa heurística é na edição de imagens
ou de vídeos, quando o usuário básico é ensinado a conhecer o sis­
tema pelos ícones. Após certa experiência, a produtividade aumenta
pelo acesso dos atalhos do teclado, que terá o mesmo resultado, po­
rém com mais agilidade e eficiência. O desafio é tornar a experiência
agradável para ambos os níveis de usuários e, principalmente, não
sobrecarregar de informação aqueles de primeira viagem.

8. Design estético e minimalista

O sistema precisa ter elementos que não sobrecarreguem o layout
da interface, pois, com muita informação, o usuário pode se per­
der. Não se trata somente de texto, mas também de recursos como
animação, que devem ser equilibrados, pois carregam a página
visualmente e podem tornar cansativa a experiência se o usuário
precisa entrar várias vezes ao dia. Assim, devem ser eliminados itens
desnecessários que não dizem respeito ao assunto diretamente, que
estão ali somente porque integram uma figura bonita retirada de
algum banco de imagens, mas que, quando disponibilizados no
aplicativo, não têm relevância.
Na teoria da comunicação, esses elementos que sobrecarregam
visualmente são chamados de ruídos, porque atrapalham e desviam
o foco. Convém evitar imagens em todos os fundos com texto so­
breposto, pois atrapalham a leitura, preferindo-se fundos neutros,
que ajudam na leitura e atraem o usuário.
154

9. Ajuda aos usuários para reconhecer, diagnosticar

e recuperar erros
No preenchimento de formulários, é comum o usuário esquecer
algum campo que seja obrigatório. Nesse caso, recursos devem ser
ativados, como alertas ou destaques com cores, mostrando-se quais
dados devem ser inseridos ou que falta completar alguma informação.
Outro alerta para os usuários é quando estão navegando e um
erro da página aparece, como o “Erro 404”, de forma que o usuá­
rio pode saber que não existe mais aquela página, porém consegue
continuar navegando pelo sistema. Deve-se deixar disponível algum
menu para acessar as páginas que estão funcionando.
Em sites de e-commerce, alguns produtos podem não estar mais
disponíveis para venda. Para que o usuário não seja informado depois
que passou por todo o processo de compra, é recomendável alertá-lo
anteriormente de que aquele produto está indisponível e perguntar
a ele se ele quer ser avisado quando o item chegar.

10. Ajuda e documentação

Esse princípio se refere à disponibilização de auxílio quando
necessário. Os usuários podem ficar em dúvida sobre alguma in­
formação relativa ao sistema. Alguns sistemas utilizam manuais em
PDF que são acessados via link. Contudo, não se deve exagerar
nas informações, podendo-se utilizar captura de telas do sistema
e explicar o que é cada ação em forma de legendas e textos.
Outro recurso é usar tooltips com explicações objetivas sobre
o assunto e que se destacam do restante da página. As perguntas mais
frequentes dos usuários podem ser usadas para criar uma página de
 155

frequently asked questions (FAQ) com acesso pela página principal.

Dessa forma, com um clique, tem-se acesso às informações sobre
o uso do sistema. E recomendável utilizar linguagem própria para
o público-alvo. Mais recentemente, os bots (robôs) tomaram a vez.
São recursos de inteligência artificial que, por meio de cadastro de
conteúdo sobre o sistema, são apresentados ao usuário conforme
este faz perguntas.

44 Modelos mentais e metáforas

As informações dispostas nos sistemas são organizadas de forma

que os usuários encontrem relações com o mundo em que vivem.
A experiência do usuário sempre será externa ao aplicativo cm re­
lação aos objetos e aos relacionamentos. Quando foi criada a ideia
de armazenar dados no sistema, a interface abstraiu do objeto físico
(disquete, na época) a melhor forma de induzir ao clique e garantir
a segurança dos dados.
No entanto, quem da geração mais nova teve acesso a um dis­
quete como dispositivo de armazenamento? Hoje, o pendrive é mais
seguro, com capacidade muito maior e é um ícone atualizado para
a ação de salvar arquivos. Alguns o estão substituindo por um ícone
de nuvem, uma alusão ao armazenamento nas nuvens.
Modelos mentais ajudam a melhorar a produtividade dos
usuários diante das interfaces. Alguns ainda causam certa confusão,
como copiar estilos, sendo usado um pincel ou um rolo de pintu­
ra. Na rotina diária de trabalho, é possível apresentar aos usuários
156

o recurso de copiar estilos. Eles ficam surpresos com a funcionalida­

de dessa ferramenta, pois ela aumenta a produtividade, porém não
relacionam o ato de pintar com uma cópia de atributos - acham
que é pintar com cores diferentes.
O efeito de comparar o aplicativo com o mundo real aproxima
o usuário do sistema, mas isso deve ser apresentado na cultura e no
contexto físico do usuário. No filme índia: o buraco no muro (2002),
uma empresa de tecnologia leva computadores para uma região pobre
da India. As crianças que nunca tiveram acesso a um computador
conseguem navegar na internet pelo fato de suas interfaces serem
relacionadas a seu mundo real. Na história, o único ícone não com­
preendido é o da ampulheta, que, na época, era usada nos sistemas
para indicar o carregamento de página. Para as crianças do filme,
a ampulheta era o símbolo de um tambor que a deusa hindu Sarasvati
carrega cm uma das mãos - elas nunca haviam visto uma ampulheta.
A revelação progressiva, segundo Lowdermilk (2019), é uma ma­
neira de não apresentar itens desnecessários ao usuário. O desenvol­
vedor não deixa evidente, mas espera a utilização quando necessário.

Por exemplo, o Adobe Photoshop, um software profissional para edição de fotogra­

fias, está cheio de recursos e de ferramentas para designers. Se a Adobe não incorpo­

rasse a revelação progressiva, todos os seus recursos apareceriam como disponíveis,

independentemente do que eu estivesse fazendo no aplicativo. Isso representaria

um fardo significativo para mim, à medida que tentasse descobrir o que é e o que

não é possível fazer. Em vez disso, a Adobe deixa em cinza e desabilita os itens que

não são aplicáveis à minha situação corrente. (Lowdermilk, 2019, p. 96)

 157

Tal como mencionado por Nielsen e Loranger (2007),

Lowdermilk (2019) utiliza a consistência como um modelo mental
para que os usuários não se percam na navegação, tendo de, por
exemplo, aprender uma nova maneira de navegar no sistema ou
utilizar recursos que não estão dentro do escopo do projeto. Ou seja,
a ferramenta não faz parte da rotina diária, o que é um peso a mais
e que acaba criando mais problemas do que resolvendo.

Desse modo, assim como acontece em várias situações, não há uma resposta fácil.

Consistência em seus aplicativos é crucial porque reduz o fardo cognitivo de seus

usuários e deixa-os mais à vontade para aprender como seu aplicativo funciona. Não

há nada pior do que ter de reaprender funções básicas porque o desenvolvedor achou

que seria melhor fazer as tarefas de maneira diferente. (Lowdermilk, 2019, p. 99)

A disponibilidade de informações úteis deve ser atrativa, porém

o cuidado é com recursos que se criam para atividades que não
são próprias do público. Por exemplo, em alguns casos, quando
acessamos o ntede uma operadora para pagar uma conta de telefone,
existem duas faturas: uma com vencimento no dia do pagamento
e a outra do próximo mês, a vencer, que está no topo da lista de
faturas. Assim, pode-se acabar pagando a conta que ainda vai vencer,
pois ela aparece por primeiro, uma vez que visualmente as duas
faturas estão disponíveis.
A lei de Hick refere-se ao processo de decisão do usuário.
Segundo essa lei, quanto mais itens aparecem para o usuário, mais
tempo ele perde para escolher aquele que é necessário. Aumentam-
se as escolhas, e o tempo de decisão também aumenta, o que pode
causar fadiga no usuário diante do sistema.
158

Já a lei de Fitt diz respeito ao tamanho dos elementos que

determinam a ação com os campos para completar, por exemplo.
No campo, o preenchimento é feito manualmente, pelo teclado,
e o botão é acionado com o clique ou com o toque.

A Lei de Fitt é correlativa. Em outras palavras, quanto maior a distância que um

usuário deve percorrer, maiores deverão ser os objetos-alvo. O tamanho exato será

determinado pelo tempo de movimento aceitável. A Lei de Fitt é útil no caso de inter­

faces orientadas a mouse; porém, há alguns estudos novos que ajustaram o modelo

para acomodar interfaces sensíveis ao toque também. (Lowdermilk, 2019, p. 103)

Logo, o tempo disponível entre o preenchimento e o toque

pode acarretar erros ou acertos, dependendo da proximidade e do
tamanho do botão.
shutterstock_!047259321
FEEDBACK
DO USUÁRIO
 163

O momento de desenvolver um projeto de sistemas, princi­

palmente em atividades técnicas, pode ser desafiador. Na criação
de layout, os elementos mais modernos em termos de estética são
estudados e aplicados para que a harmonia deixe claro o que o design
comunica de forma eficiente. Cada campo do formulário, cada texto
alinhado corretamente, cada imagem com sua legenda combinando
com as cores da marca - tudo é colocado para chamar a atenção.
Durante a codificação, os desenvolvedores mergulham de cabeça
para encontrar a solução dos desafios impostos na implementação
das linguagens adotadas. Cada linha de código deve funcionar per-
feitamente, e a escolha de design patterns para otimizar a estrutura
do código deve ser certeira.
Todas as atividades dentro da equipe são importantes, porém,
sem a avaliação dos usuários, serão inúteis, já que suas necessidades
não foram levadas em conta. O feedback do usuário é o que leva
o projeto ao sucesso, e a frequência dessa análise realizada pelo usu­
ário deve ser contínua. Muitos desenvolvedores buscam o feedback
não porque gostam de ouvi-lo, tendo em vista que toda mudança
pode atrasar o processo, mas porque é a garantia de que o caminho
percorrido pelo time está correto.

É hora de sair pelo mundo e descobrir o que os usuários realmente pensam dos

aplicativos que criamos para eles. Devemos fazer perguntas detalhadas e estar

abertos a críticas que podem ser difíceis de escutar. Devemos observar os usuários

e documentar nossas descobertas para adquirir uma compreensão geral do que

funciona e do que não funciona. (Lowdermilk, 2019, p. 106)

Algumas equipes podem não gostar de receber feedbacks dos

usuários porque isso pode resultar em muito mais trabalho. Muitas
164

revisões de código podem ocasionar efeitos em estruturas já orga­

nizadas e que levam os programadores a temer um colapso, pois
eles convocam o teste de regressão para analisar o que já estava
implementado. Tudo o que seria o estado da arte do sistema pode
ter de ser alterado quando o usuário descobre que itens decisivos
não estão sendo seguidos e que alterações precisam ser realizadas.
Assim, os codificadores voltam à sua IDE {integrated, development
environment) e os designers, às atualizações dos protótipos, pois
novos rumos foram dados a suas atividades depois de o usuário
dar o retorno de sua avaliçâo.

Aqui está minha sugestão: devemos aprender a ser tolerantes com os feedbacks.

Os melhores desenvolvedores que conheço desejam fazer o que é certo, não im­

portam as consequências. Acima de tudo (sono, dinheiro ou ego), eles querem de­

senvolver o melhor aplicativo possível. Percebem que receber feedback honesto, de

qualidade, é a única maneira de chegar lá, e aqui está o segredo - na verdade, eles

pedem para ter feedback Não disse que eles gostam disso, mas eles o valorizam.

Esses desenvolvedores colocam seus aplicativos nas mãos de potenciais usuários

o mais rápido possível. Fazem perguntas detalhadas aos usuários e os estimulam

a ser brutalmente honestos. Eles pesquisam o mercado, observam seus concorrentes

e revisam seus aplicativos para garantir que proporcionarão vantagem competitiva.

(Lowdermilk, 2019, p. 106)

A questão é que, com o job em mãos, todos querem acertar na

primeira entrega, pois, nas equipes entrosadas, o objetivo é atingir
as metas da forma mais rápida e eficiente possível. Quem trabalha
com desenvolvimento deve ter em mente que faz parte de suas ativi­
dades compreender as regras de negócios do cliente, que, muitas vezes,
não fazem parte de sua rotina. Um backlog é discutido e entregue,
 165

e as tarefas de codificar e de desenvolver o layout são ações que po­

deríam atingir o nível desejado do usuário já na primeira entrega.
Lowdermilk (2019) relata que todos querem marcar um gol de placa,
mostrando o novo aplicativo aos usuários, aos clientes, aos amigos
e aos familiares e ouvir que o acerto foi preciso, que a equipe entendeu
tudo corretamente, terminou o projeto e fez tudo na versão 1.0.

Figura5.1-Realizar o feedback é importante para o sucesso do aplicativo

fizkes/Shutterstock

Dificilmente o cliente é agradado na primeira vez, pois o desen­

volvimento exige cuidados em ouvir o que o se deseja. Uma equipe
bem estruturada quer o feedback do cliente para que o tempo inves­
tido na realização do sistema seja voltado para entregar um produto
à altura de suas necessidades. Muitas equipes passam horas a mais
166

para resolver questões cruciais e lutam contra o relógio só porque

nâo ouviram o usuário ou porque muitas vezes negligenciaram
os requisitos. Equipes com alta maturidade não trabalham dessa
forma. Projetos desafiadores, que à primeira vista podem parecer
um absurdo em termos de tempo e de tarefas, devem levar em conta
o cuidado em colocar o usuário como parceiro nas entregas, o que
pode economizar horas de retrabalho. São equipes que têm a visão
macro do projeto, porque o valor do produto está nos desejos do usu­
ário, e não na linguagem de programação mais utilizada no mercado
de tecnologia ou no design minimalista mais moderno que existe.
Quando se sai do foco das necessidades do usuário, entra-se no
terreno das incertezas, mesmo com todo o aparato tecnológico em
software ou em hardware por trás de um produto entregue. E envol­
vente participar de projetos em que um produto está surgindo de
uma intenção abstrata do cliente e será entregue ao mundo para ser
usado e aplaudido como o melhor dos sistemas.

Quando estou trabalhando no código, sinto-me confortável e, por mais que possa

soar estranho, ele proporciona as menores dificuldades. Posso ficar golpeando

o teclado e permanecer super focado para fazer os recursos funcionarem. 0 pro­

blema com essa abordagem é que nunca paro para refletir: "Os usuários, antes de

tudo, querem esse recurso?". Sei que devo passar um tempo com meus usuários

previamente, e sei que deveria estar fazendo perguntas e criando um plano de ação.

Em vez disso, acabo dizendo algo do tipo "Só quero ver se [um desafio de progra­

mação] é possível, em primeiro lugar." Digo a mim mesmo, inúmeras vezes, que

retornarei para um processo mais estruturado de desenvolvimento de software

assim que eu tiver [um desafio de programação) funcionando. Quando faço isso,

estou fadado ao fracasso. (Lowdermilk, 2019, p. 107)

 167

Ao codificar ou criar um wireframe, o profissional precisa a todo

momento se perguntar se tal recurso terá impacto positivo para o usuá­
rio, e não se será a resolução de uma funcionalidade ou um novo meio
de navegação que vai revolucionar o mercado de software. Pode ser
que trabalhar sem alguém ao lado desestimulando o serviço - dizendo
frases como “Isso não vai dar certo!” e “Por que esse botão, e não o ou­
tro?” - seja o melhor dos mundos, mas são feedbacks que podem ser
reunidos anteriormente e que são recorrentes ao longo das atividades.
Uma consulta rápida aos requisitos pode fazer toda a diferença no que
se está entregando no mercado de software.

Com frequência, lembro a mim mesmo que chegarei à fase de codificação no

tempo devido, mas, até lá, devo obter respostas para algumas perguntas. Devo

adquirir uma compreensão básica sobre o que estou tentando criar. É claro que

posso ter uma ideia geral, mas tenho de garantir que entendi as especificidades.

É impossível descobrir de maneira eficiente como será meu aplicativo ao mesmo

tempo em que estou escrevendo seu código. Se eu quiser ser bem-sucedido e criar

um aplicativo que os usuários irão querer usar, deverei ser disciplinado e paciente.

(Lowdermilk, 2019, p. 107)

Uma equipe orientada às atividades pode achar que as funciona­

lidades que estão nos sistemas concorrentes obtêm sucesso porque
chegaram primeiro ou que funcionam em todos os sistemas porque,
no momento, o hardware está acessível a todos. Contudo, equipes
orientadas ao usuário sempre buscam nos anseios e nos desejos do
cliente entregar um produto que atenda a suas necessidades.
168

Se você estiver trabalhando em um aplicativo no momento, eu o desafio a responder

as seguintes perguntas básicas:

• Que problema seu aplicativo resolve? Qual é seu foco principal?

• Quem são os usuários ideais para seu aplicativo? Como são eles? São usuários

experientes ou são novatos?

• Quais são os três recursos que devem ter presença obrigatória? Como você sabe

que eles são os mais importantes?

• Como seu aplicativo agregará valor? Como ele trará melhorias em relação ao

que as pessoas estão usando atualmente?

Se você não puder responder facilmente a algumas dessas perguntas, não se de­

sespere. A maioria dos desenvolvedores que conheço tem dificuldades com elas.

A verdade é que, se estivermos focados somente em fazer os recursos funcionarem,

será impossível manter uma perspectiva sobre a visão geral e o propósito de nosso

aplicativo. (Lowdermilk, 2019, p. 108)

A questão é permitir à equipe ter insights baseados na experiência

do usuário com a atitude de buscar respostas. E um cenário que
ocorre e faz com que muitas vezes as equipes se preocupem com
a visão macro do projeto e esqueçam suas especificidades, que são os
elementos que fazem a diferença, muitas vezes. Algumas pesquisas
apontam que, por exemplo, o usuário quer somente o telefone da
empresa, mas esta não o deixa disponível em seu site, ou ele procura
por uma informação que não está atualizada. Esses detalhes são
tangentes em relação à codificação ou ao design, ou seja, não fazem
parte do core dessas atividades. Parecem informações muito especí­
ficas para o usuário, mas que para ele são essenciais e poderíam ser
facilmente detectadas em uma atividade voltada a sua experiência.
 169

Somente se permitirmos que os usuários ofereçam feedback continuamente, po­

deremos testar nossos pressupostos e garantir que estamos seguindo na direção

correta. No entanto isso vai muito além de simplesmente pedir aos usuários que

compartilhem suas opiniões. Devemos ser metódicos, quase antropológicos, em

nossos estudos. Devemos pedir informações a nossos usuários e observar seus

comportamentos. Dessa maneira, podemos aprender com o que eles nos dizem

e podemos ler nas entrelinhas. (Lowdermilk, 2019. p. 108)

Os desenvolvedores não podem perder a oportunidade de

acompanhar um usuário em suas atividades mesmo que seja com
aplicativos com os quais eles não estão trabalhando no momento.

Exemplificando

Quando precisei agendar corte e barba no barbeiro, eu o fiz por

aplicativo de mensagens e depois acabei desmarcando e remarcando
o serviço por três vezes, por causa de compromissos de última hora.
Antes de o barbeiro finalizar o corte, percebi pelo espelho que havia
uma tela de 32 polegadas com uma espécie de calendário e algumas
áreas destacadas com cores. Como profissional da área de desenvolvi­
mento, não pude conter a curiosidade e, no momento certo, perguntei
ao barbeiro como funcionava aquele aplicativo. Ele explicou que ali es­
tavam os clientes e os horários agendados previamente e o profissional
que iria realizar o serviço. Ele apontou para o meu nome e demonstrou
como o sistema funcionava. Com um clique, finalizou e abriu uma
tela com o valor de cada serviço e as opções de pagamento, junto
com a descrição do que foi feito. E, como o espelho refletia a tela, ele
podia acompanhar quanto faltava para finalizar algum serviço e se
havia alguém para ser atendido em seguida.
170

Quando fiz uma pergunta específica, ele chamou o administrador

do local que mostrou outros recursos a que ele tinha acesso: o cadas­
tro de produtos consumidos e vendidos no local, o gerenciamento
financeiro de cada corte, as comissões dos barbeiros e a dinâmica
de preenchimento e de cancelamento de dados. Umas das carac­
terísticas mais importantes do aplicativo era a transparência com
o cliente. O fato de um barbeiro estar sem atividade no momento
poderia parecer displicência com o trabalho, mas na tela era possível
ser visualizada a próxima entrada de cliente e que qualquer encaixe
naquele momento poderia atrasar todo o restante do serviço.

A atitude de ser um desbravador dos espaços ganha mais detalhes

quando o usuário é observado em sua rotina. Em alguns casos, é pre­
ciso ser respeitoso, pois pode-se estar invadindo o espaço do cliente
e parecer um espião de dados ou algo do tipo. Por isso, é necessário
ter muito cuidado nessa dinâmica, porque é uma relação de con­
fiança com o usuário fazer um trabalho etnográfico. As informações
do local em que ele atua estarão expostas, e a ética determina que
o que faz parte da documentação e de dados do cliente não deve ser
levado adiante como benefício próprio.
Com a aprovação da Lei Geral de Proteção de Dados (LGPD) -
Lei n. 13.709, de 14 de agosto de 2018 (Brasil, 2018) -, aumentou
a fiscalização dos dados pessoais. Muitos casos de vazamento de
informações colocaram em risco empresas e governo, e, hoje em dia,
mais que recorrente está o uso desse conteúdo para a publicidade ou
o direcionamento de campanhas políticas.
Se o aplicativo for desenvolvido para uma instituição de ensino,
muitos dados estarão envolvidos, como informações pessoais de
 171

familiares (endereço, número de filhos estão na escola ou nomes dos

responsáveis). Outras informações podem causar constrangimento,
como as financeiras, no caso de alguns estarem em dívida com a ins­
tituição, ou as sociais, como no caso de um aluno não poder sair com
determinado familiar. Em alguns locais, não é permitido o registro
de imagens, por isso sempre é bom perguntar se há autorização para
fazer filmagens ou tirar fotografias de documentos e do local.
A etnografia é um exercício além da empatia, pois o desenvolve­
dor está vendo e vivenciando as necessidades e os desejos do cliente.
Algumas atividades podem exigir mais observação do que perguntas
em algum momento, como no caso de uma oficina mecânica onde
o cliente está ansioso para que o serviço finalize e não quer ser inter­
rompido com perguntas. Por isso, é necessário ter cautela à medida
que mais pesquisas desbravadoras forem realizadas, ganhando expe­
riência para definir como serão as próximas abordagens.
O feedback pode ser coletado também pelo próprio uso do apli­
cativo, depois de este ser lançado. A busca é pelo sistema perfeito,
mas todos têm consciência de que não pode ser atingido o estado
da arte. Mesmo com o sistema sendo usado, devem-se criar canais
de comunicação com o cliente para que não se perca o foco em suas
necessidades. Pode ser que algo tenha mudado após o lançamento,
que algumas funcionalidades sejam substituídas em termos de tec­
nologias e exijam da equipe uma atualização parcial ou completa.
O problema não é a nova tecnologia a ser adotada, mas o momento
em que a equipe soube qual é o impacto que isso está causando
na vida dos usuários. Às vezes, o fórum de desenvolvedores não
vai revelar esses problemas do usuário, nem sites especializados em
tecnologia (a não ser que estejam focados na experiência do usuário).
172

Saber ouvir o cliente requer deixar de lado as paixões relaciona­

das à área, pelo que ela pode fazer pelo usuário em termos do que
de mais moderno existe e centrar em suas necessidades, orientando
as atividades pelo feedback constante desses parceiros da equipe.

5.1 Amostragem e entrevista

A amostragem diz respeito ao universo de entrevistados que

farão parte da pesquisa. E um número representativo, já que não
é possível entrevistar todos os usuários em potencial. Podemos
citar como exemplo um aplicativo para uma clínica médica no
qual os usuários dos sistemas seriam as atendentes, o corpo médico,
os administradores e os diretores. Como é um sistema multiusuário,
ou seja, para qualquer clínica médica, supõem-se que todos esses
profissionais teriam de ser entrevistados. Essa seria uma prática
impossível de ser realizada, já que não se conseguiría a atenção de
todo esse público-alvo de imediato, pois isso dependería de deslo­
camentos até os locais, agendamento com cada profissional e outros
fatores que tornam impraticável entrevistar todos.
Quando pesquisadores querem entender como está a situação
política, fazem entrevistas com certo número de pessoas que têm
o direito de votar, e não com toda a população do local. Eles conver­
sam com uma parte significativa das pessoas por meios eletrônicos
ou presencial men te.
 173

Em alguns casos, eu começaria com algumas perguntas bastante informais. Posso

fazer algumas perguntas somente para um grupo pequeno de pessoas a respeito

de suas necessidades no domínio de um determinado problema. Sei que o feedback

dessas pessoas pode não ser representativo da base mais ampla de usuários, por­

tanto, contextualizo isso quando estiver analisando suas respostas. Eu argumentaria

que a variedade pesa muito mais do que a quantidade. (Lowdermilk, 2019, p. 108)

Com relação ao número de entrevistados, deve-se concentrar

a atenção sobretudo no perfil dos usuários e menos na quantidade.
O usuário deve reunir as qualidades necessárias para ser objeto de
estudo. Seria muito conveniente conversar com os membros da equi­
pe de trabalho sobre o que achariam que determinado aplicativo
deveria fazer. Contudo, essas pessoas dariam respostas voltadas para
soluções técnicas e, por causa de sua experiência com tecnologia, não
chegariam às dificuldades de um usuário comum.
Para Teixeira (2014, p. 33), a pesquisa quantitativa pode ser
utilizada na seguinte situação: "Questões que produzem um nú­
mero como resultado. E uma forma rápida e simples de medir
a satisfação dos consumidores e coletar feedback sobre o produto.
As pesquisas quantitativas podem apontar a necessidade de outro
tipo de pesquisa em profundidade".
Dessa forma, um aplicativo voltado para uma agência de viagens
exigiría entrevistar pessoas formadas em turismo, administradores de
hotéis e de pousadas e empresas que prestam serviços de translado
e serviços públicos para turistas. Não caberia entrevistar os colegas
de trabalho que não conhecem os procedimentos dentro de uma
agência de turismo.
174

Nielsen e Loranger (2007, p. 25) relatam sua experiência nas

entrevistas com 25 usuários da internet da seguinte forma:

Dividimos nossos usuários em dois grupos, com base na soma das suas experiências

com internet. Todos tinham pelo menos um ano de experiência no uso da web, mas

ainda havia uma ampla variedade no nível de perícia entre eles. Para os fins dessa

análise, dividimos esses grupos em "usuários pouco experientes" e "usuários muito

experientes" de acordo com várias questões:

• Há quanto tempo eles estão online.

• Quantas horas por semana eles utilizam a Web, sem contar o tempo gasto com

e-mails.

• Quantos hábitos "avançados" eles demonstravam, como bate-papo (chat) na

web, mudança de nome de favoòtos/bookmarks, atualização dos navegadores

e criação de suas próprias páginas na web.

• Se eles mesmos solucionavam problemas nos seus computadores.

• Até que ponto eles seguiam as tendências atuais na área de tecnologia - por

exemplo, se assinavam revistas de informática ou se eram considerados pelos

amigos como uma fonte de consulta em informática.

Lowdermilk (2019) aponta que exigir, nesse caso, um feedback

dos colegas desenvolvedores não traria quantidade suficiente de
informações, já que a experiência deles com a área de enfermagem
é mínima, ou às vezes nula. O autor cita um exemplo com um
aplicativo na área da saúde:

Se eu estiver desenvolvendo um aplicativo para os enfermeiros supervisores organi­

zarem os funcionários em cada turno, vou querer reunir feedback de uma variedade

de pessoas que estejam envolvidas no processo de organização dos enfermeiros.

 175

Poderei pesquisar junto aos enfermeiros supervisores, os enfermeiros, os auxiliares

de enfermagem, os diretores dos enfermeiros e os coordenadores das unidades.

Pode ser um grupo pequeno de cinco pessoas ou um grupo grande de trinta. Só de­

pende da quantidade de recursos que tenho disponível. (Lowdermilk, 2019, p. 109)

E como recrutar os usuários? A forma adotada para isso pode

atingir um número significativo de pessoas ou afastá-las. Se for usado
o e-mail, a lista deve conter um número controlado para avaliar para
quem foi enviada a mensagem e quantos a responderam. Essa lista
de e-mail pode ser obtida diretamente com o cliente, que provavel­
mente tem um banco de dados com essas informações.
Outra forma são as redes sociais vinculadas à página do cliente.
Existem aplicativos que fornecem formulários estruturados para se­
rem abertos nas redes sociais e que colhem as informações em forma
de gráficos ou de porcentagem. O Google Does tem uma ferramenta
que cria formulários que fornecem uma lista de resultados em forma
de planilha ou de gráficos.
A quantidade de usuários é apontada por Lowdermilk (2019)
como uma questão polêmica entre os profissionais de estatística.
Em estudos na área da usabilidade, o autor cita as declarações de
Nielsen e Loranger (2007) de que, em um universo de usuários,
cinco deles são suficientes para extrair informações e que acrescentar
mais pessoas a esse número se torna mais complexo para algumas
equipes administrarem (Lowdermilk, 2019). O que essa quantidade
a mais de entrevistados vai acrescentar em termos de informações
não será de grande impacto.
176

Lowdermilk (2019, p. 110) exemplifica:

Pense em quando você pede uma pizza. A primeira fatia é sempre a melhor porque

proporciona o mais alto nível de satisfação. Se estiver com fome, você poderá estar

disposto a pagar 5 dólares por ela. A sexta fatia (se você conseguir comer tanta

pizza quanto eu) simplesmente não será tão satisfatória, e é provável que você

estará menos disposto a pagar 5 dólares por ela. Sendo assim, podemos concluir

que a sexta fatia de pizza simplesmente não é tão valiosa quanto a primeira.

No artigo How Many Test Users in a Usability Study? (Quantos

usuários de teste em um estudo de usabilidade?), Nielsen (2012,
tradução nossa, grifo do original) relata que encontrou algumas
exceções para esse número ideal de cinco participantes nas entre­
vistas com usuários:

• Estudos quantitativos (visando estatísticas, não insights): Teste pelo menos

20 usuários para obter números estatisticamente significativos; intervalos de

confiança apertados exigem ainda mais usuários.

• Card sorting: teste pelo menos 15 usuários por grupo de usuários.

• Eyetracking: teste 39 usuários se você quiser mapas de calor estáveis.

No entanto, essas exceções não devem preocupá-lo muito: a grande maioria de

sua pesquisa de usuários deve ser qualitativa - ou seja, destinada a coletar insights

para impulsionar seu design, não números para impressionar as pessoas no

PowerPoint.

Com relação a esses apontamentos, Teixeira (2014, p. 35), ex­

plica o que é o card sorting: “Uma técnica que consiste em pedir aos
usuários que agrupem conteúdos e funcionalidades em categorias.
Dá inputs valiosos ao time sobre hierarquia de conteúdo, organização
 177

e taxonomia”. Define também eyetracking: “Uma tecnologia que

consegue analisar o movimento dos olhos do usuário à medida que
ele interage com o produto. Dá informações sobre as partes da inter­
face que mais interessam ao usuário e sobre qual a ordem de leitura
dos elementos da tela” (Teixeira, 2014, p. 36).
No artigo de Nielsen (2012), o autor revela alguns argumentos
que sâo usados para que mais participantes sejam inseridos além
dos cinco:

• “Um grande site tem milhões de usuários” (Nielsen, 2012, tradu­

ção nossa) - Em uma pesquisa de opinião, segundo a estatística,
é importante o tamanho da amostra, e não o tamanho da popu­
lação completa. Nos testes aplicados com usuários, são avaliados
quais elementos de design têm maior ou menor facilidade no
uso. A qualidade no uso desses elementos é independente de
quantos vão testá-los. A correção deve se concentrar nos recursos
que o maior número de usuários utilizará dentro do sistema,
evitando-se esforços em funcionalidades que poucos utilizam.
• “Um grande site tem centenas de recursos” (Nielsen, 2012, tradu­
ção nossa) - Esse argumento acaba ferindo a disponibilidade de
usuários que fazem os testes, que podem acabar esgotados e dar
um feedback para se livrar da tarefa. Mais recursos exigem divisão
do estudo em porções maiores, evitando-se sobrecarregar o usuário.
• “Temos vários públicos-alvo diferentes” (Nielsen, 2012, tradução
nossa) - É um motivo legítimo se os diferentes públicos se com­
portam totalmente de maneira específica. Em um sistema para
lanchonete, por exemplo, o funcionário pode cuidar do caixa
e cadastrar um cardápio, assim como essas atividades podem
178

ser realizadas pelo gerente. A secretaria de uma escola pode

visualizar as notas dos alunos, assim como o setor de pedagogia.
Um fórum pode ser moderado por alguém que também publi­
ca informações. Dessa forma, os integrantes acabam cruzando
funções que nem sempre sâo específicas e podem ser comparti­
lhadas por diversos públicos.
• “O site ganha tanto dinheiro que até o menor problema de usa-
bilidade é inaceitável” (Nielsen, 2012, tradução nossa) - As em­
presas querem retorno sobre o que os usuários estão consumindo
em termos de acessos a seus sistemas. Querem análises detalhadas
para saber de onde vem maior interação do usuário e onde os pro­
blemas acontecem. “No entanto, mesmo os projetos de design de
maior valor ainda otimizam seu ROI [Return over Investment],
mantendo cada estudo pequeno e realizando muito mais estudos
do que um projeto de menor valor poderia permitir”, destaca
Nielsen (2012, tradução nossa).

Durante o processo de pesquisa de usuários, foi constatado que

o número excedente de usuários, a partir de cinco, não trouxe mu­
danças significativas em relação ao que já havia sido relatado por um
número menor. Conforme o Gráfico 5.1, a seguir, 83 estudos de
caso recentes revelam essa relação da quantidade de usuários com
as variações de usabilidade.
 179

Gráfico 5.1 - Acima de cinco usuários, não há grande representatividade

na maioria dos testes

Fonte: Nielsen, 2012, tradução nossa.

Nielsen (2012) esclarece que equipes que adotaram o método

ágil no desenvolvimento de sistemas são menos sobrecarregadas

com as tarefas, conseguem corresponder aos resultados de pesqui­
sas com menos participantes e dividem os apontamentos realizados
pelos usuários. O método ágil se beneficia da abordagem menor de
usuários pelo fato de desenvolver projetos com divisão de tarefas
por prioridade.
180

Para projetos realmente baixos, geralmente é ideal testar até 2 usuários por

estudo. Para alguns outros projetos, 8 usuários - ou às vezes até mais - podem ser

melhores. Para a maioria dos projetos, no entanto, você deve ficar com o testado

e comprovado: 5 usuários por teste de usabilidade. (Nielsen, 2012, tradução nossa,

grifo do original)

Lowdermilk (2019) segue os mesmos princípios de Nielsen

(2012): realiza pesquisa com uma amostra em torno de cinco a dez
pessoas e destaca que as reuniões são efetivas para extrair uma quan­
tidade significativa de informações. Esse é um número de usuários
fácil de controlar. Por exemplo, se houver acesso a um laboratório de
dispositivos, será possível colocar metade das pessoas avaliando nos
equipamentos, com observadores registrando visualmente e ouvindo
relatos, e a outra metade em entrevistas com formulários e conversas
gravadas. Com um número reduzido de participantes, entre cinco
e dez pessoas, pode ser adotado um distanciamento que evite a in­
fluência no que cada um está respondendo, pois, no momento da
dúvida, alguns podem achar que a resposta do outro tem mais valor.
O mais importante quanto à forma de recrutar esses usuários
é o modo de abordá-los, e não o uso de ferramentas. Uma apresen­
tação sobre o que está sendo pesquisado é essencial para o usuário
sentir-se à vontade com as questões. Não é simplesmente enviar as
perguntas e aguardar que eles as respondam. Primeiramente, deve ser
feita a apresentação de quem está solicitando as respostas e para o que
elas serão usadas. E preciso sempre deixar o usuário ciente de que
sua participação é para criar um produto que atenda às necessidades
dele e que sua contribuição é para desenvolver artefatos com excelên­
cia. Ser sincero aproxima mais ainda para futuras contribuições do
 181

usuário (por exemplo, quanto tempo será necessário para responder

ao formulário). Ao final, deve-se agradecer a participação dele.
Algumas ferramentas já foram citadas anteriormente, como
o Google Does, com o formulário; há também o SurveyMonkey
e o Forms, da Microsoft. Todas elas têm recursos que facilitam
quando o usuário não pode deslocar-se até o ambiente de pesquisa.
As pesquisas devem ser estruturadas com perguntas claras e obje­
tivas. E necessário avaliar questões pertinentes e verificar se há algo
que não é relevante, como o número de celular do entrevistado, que
pode levar a pessoa a achar que vão entrar em contato ou oferecer
algum produto. Primeiramente, é preciso definir que relevância terá
a pesquisa para o sucesso do aplicativo, pois criar perguntas sem um
direcionamento recairá simplesmente na cópia de outros formulá­
rios prontos. O escopo da entrevista deve ser definido junto com
o cliente e a equipe que vai estruturar as questões.

Criar uma pesquisa válida e confiável é uma forma de arte. É verdade! É preciso

não só saber que perguntas deverão ser feitas, mas também fazê-las de modo

a obter feedbacks úteis. Realizar perguntas claras, concisas e imparciais, bem como

selecionar o grupo correto de pessoas, é a chave para uma pesquisa bem-sucedida.

(Lowdermilk, 2019, p. 111)

Lowdermilk (2019) cita a pesquisa conforme estudos de Ren.sis

Likert, que criou o método que leva seu sobrenome. E uma escala
que apresenta várias respostas que deixam o entrevistado com uma
noção mais precisa do que se quer avaliar. Apresentaremos a seguir
um exemplo desse método.
182

Exemplificando

Questão: Os smartphones são prejudiciais para o desenvolvimento

de crianças até os 8 anos:

• Concordo plenamente.
• Concordo.
• Não concordo nem discordo.
• Discordo.
• Discordo plenamente.

Essa escala serve para avaliar aqueles usuários que não conse­
guem decidir-se com perguntas abertas. Sempre deve existir um ponto
neutro. Com essas opções, o pesquisado enxerga a totalidade de
respostas. Esse tipo de questão é indicado para aqueles que ficam
em cima do muro.

Outros exemplos de aplicação da escala de Likert são encontra­

dos no site SurveyMonkey (2020, grifo do original)1:

Satisfação do cliente

Em geral, qual é seu nível de satisfação ou insatisfação com nossa

empresa?

• Muito satisfeito
• Mais ou menos satisfeito
• Nem satisfeito, nem insatisfeito
• Mais ou menos insatisfeito
• Muito insatisfeito

1 Disponível em: <https://pt.surveymonkey.com/mp/likert-scale/>. Acesso em: 14 dez. 2020.

 183

Envolvimento do funcionário

Estou satisfeito com o investimento da minha organização

em educação:

• Concordo totalmente
• Concordo
• Não concordo nem discordo
• Discordo
• Discordo totalmente

Feedback de eventos profissionais

Qual foi a utilidade do conteúdo apresentado no evento profissional?

• Extremamente útil
• Muito útil
• Mais ou menos útil
• Um pouco útil
• Nem um pouco útil

De acordo com Lowdermilk (2019, p. 111),

Com as escalas de Likert, você poderá abranger uma variedade de tipos de resposta:

Frequência - Sempre; frequentemente; às vezes; nunca.

Importância - Muito importante; importante; um pouco importante; nem um

pouco importante.

Valor - Muito alto; alto; médio; baixo; muito baixo.

Satisfação - Totalmente satisfeito; satisfeito; neutro; insatisfeito; totalmente

insatisfeito.

Classificação - 5, 4, 3, 2 e 1.
184

Para o autor, esse método pode ser utilizado quando o entrevis­

tado estiver sendo direcionado para avaliações com confirmação de
que os recursos utilizados já foram examinados (Lowdermilk, 2019).
Isso não exige esforço maior do entrevistado, já que existe uma gama
de respostas plausíveis que pode levá-lo a escolher uma das opções.
Além disso, conforme Lowdermilk (2019, p. 112), "Com muita
frequência, você conduzirá uma pesquisa somente para descobrir
que tem um conjunto de usuários que está totalmente de acordo
com o que você está afirmando. Essas informações não são muito
úteis, se estiver tentando decidir em quais recursos você deverá
investir seu tempo".
Se o diagnóstico é para estudar o quanto há de interesse no uso
de algum recurso, por exemplo, entre os entrevistados, o método
de levantamento da pesquisa tem de direcionar para o resultado
mais satisfatório cm relação à escolha do usuário. Toma-se o nú­
mero de respostas para o melhor resultado c divide-se pelo número
de entrevistados.

Por exemplo, se optar por usar uma escala de frequência duas vezes, eu devo ga­

rantir que o conjunto de respostas seja o mesmo. Também prefiro limitar o conjunto

de respostas a não mais do que cinco, e certifico-me de que elas sejam fáceis de ser

compreendidas. Não quero que os usuários tenham a intenção de concordar com

uma afirmação e discordem acidentalmente. Ao criar afirmações breves e oferecer

consistência nas opções para respostas, permito que os entrevistados avaliem rapi­

damente e respondam às minhas pesquisas. (Lowdermilk, 2019, p. 113)

No entanto, a indicação é que nem todas as perguntas sejam

abordadas pelo método de Likert. Algumas serão abertas, aquelas
 185

que exigem um pouco mais de atenção, como no caso de justificar

uma escolha em que o entrevistado deve discorrer sobre o assunto,
ou uma sugestão que pode ser aplicada diferentemente do que foi
tratado ao longo da entrevista.

Você poderá coletar respostas abertas, como, por exemplo, por meio de respostas

dissertativas, mas acho que muitos participantes não querem gastar tempo para

respondê-las. Além disso, erros de ortografia, sentenças fragmentadas e afirma­

ções obscuras acabam por agregar muito pouco valor. Como tudo mais, o uso de

respostas dissertativas dependerá, provavelmente, do público-alvo que você estiver

pesquisando. (Lowdermilk, 2019, p. 114)

As entrelinhas durante a pesquisa somente são observadas com

a presença do entrevistador e do entrevistado. Algumas reações
e comentários não são registrados por escrito, o que leva o pesquisa­
do a falar sobre o que está acontecendo. Dependendo das expressões,
as atitudes são registradas para o estudo do usuário. Por exemplo,
o tempo que uma página demora para carregar não pode ser medido
sem um cronômetro, mas, pela avaliação do usuário, demorou. Com
uma observação mais acurada, ou, posteriormente, com o uso de
ferramentas específicas, pode-se avaliar quais recursos foram exigidos
da máquina para que levasse um tempo demasiado longo.
Teixeira (2014, p. 33) aponta o método Focus Group para le­
vantar informações com os usuários: "[Trata-se de] Um painel de
discussão com vários usuários sobre determinado assunto ou questão.
Ajuda a entender os sentimentos das pessoas, suas opiniões e até
a linguagem que utilizam ao falarem sobre o produto. Útil quando
o time não está muito familiarizado com o público-alvo do produto".
186

As entrevistas são divididas em: estruturadas, não estruturadas

e contextuais. Todas sâo abordagens diretas com o entrevistado, al­
gumas mínimas, outras maiores.
A abordagem não estruturada tem como base a informalidade.
E uma espécie de bate-papo com o entrevistado, em que ambos fi­
cam mais à vontade para analisar e fazer os apontamentos necessários.
A pergunta, quando não entendida, pode ser formulada de outra
forma até que o nível de compreensão seja atingido. Como permite
discorrer sobre o assunto, novas perguntas podem surgir e acabam
enriquecendo os requisitos do usuário.

Isso nâo quer dizer que sua discussão deverá ser aleatória. Ela simplesmente será

menos focada em formalidades e em consistência. Entrevistas não estruturadas

são úteis quando você realmente não sabe quais perguntas deve fazer. Talvez você

tenha uma ideia para um aplicativo, mas não tenha tomado nenhuma decisão

ainda sobre qualquer recurso específico. O objetivo das entrevistas não estruturadas

é conversar com o número máximo de pessoas que puder sobre o problema que

você está tentando solucionar. (Lowdermilk, 2019, p. 114)

Com a abordagem não estruturada, mantém-se um diálogo aber­

to para que hipóteses sejam levantadas ou descartadas, já que o nível
de detalhes é explorado ao máximo durante esse tipo de entrevista.
Já a entrevista estruturada segue um roteiro específico e é realiza­
da da mesma forma com todos os usuários. A mesma entonação de
voz, o mesmo ambiente, os mesmos recursos devem ser explorados.
Geralmente, as entrevistas são mais rápidas e com tempo definido.
Um tipo de pergunta nessa abordagem é aquela em que o campo
de pesquisa está trazendo resultados de uma busca sobre o nome
de um prato no site de um restaurante ou se a edição do perfil do
 187

usuário trouxe os dados de CPF que ele tinha preenchido. São per­
guntas específicas que exigem respostas diretas, e não do tipo que
teria de ficar no lado direito ou logo abaixo do nome.

Se você planeja conduzir entrevistas estruturadas, eu o aconselho a assumir um

comprometimento em relação a elas. Prepare um roteiro com antecedência e faça

o máximo para lê-lo, de forma consistente, para cada usuário. Foque somente no

roteiro e evite distrações ou conversas paralelas. Isso permitirá comparar igualmente

as respostas de cada usuário. (Lowdermilk, 2019, p. 115)

A investigação contextual é uma abordagem feita diretamente

no ambiente e no contexto de uso do sistema. Também conhecida
como etnográfica, ela envolve tudo o que acontece durante o uso de
um aplicativo, como conversas, interrupções e efeitos físicos.

5.2 Estudos de usabilidade

Durante o estudo da usabilidade, os usuários são levados aos mais

diversos cenários de interação com sistemas e, muitas vezes, a equipe
precisa descrever em quais situações será estudado o comportamento
do usuário diante dos aplicativos. Teixeira (2014, p. 81) descreve
algumas ações para o teste de usabilidade:

• 0 usuário sabe onde está? A tela comunica com clareza em que página/site/

passo do fluxo ele se encontra?

• 0 usuário sabe o que fazer a seguir? A ação principal está nítida o suficiente?

• O botão onde eu quero que o usuário clique está claro? O texto do botão dá

ao usuário alguma dica do que vem a seguir?

188

• Se essa tela é uma tela de confirmação no final de um fluxo, eu estou aproveitan­

do para sugerir que o usuário faça algo mais, aumentando o tempo de navegação

e o nível de engajamento dele com o produto?

Os aplicativos exigem dos dispositivos os mais variados recursos,

como processamento, memória, qualidade gráfica e armazenamento,
que podem variar conforme o aparelho utilizado. Como há uma
infinidade de artefatos e configurações, cada usuário pode dar um
feedback diferente para um mesmo aplicativo. Para um, o sistema
está abrindo e tudo está normal. Para outro, o tempo de carrega­
mento é demasiado longo, o que o faz desistir de usar o programa.
Essas nuances entre os dispositivos são reveladas durante a condução
dos testes de usabilidade que habilitam os observadores a trabalhar
diretamente no ponto em que as tecnologias são utilizadas no apli­
cativo ou podem ser decorrentes de um design que foi concebido
para plataforma desktop e, nos smartphones, não oferecem os recursos
próprios para uma manipulação em touchscreen.

Com efeito, os estudos de usabilidade são um dos recursos-chave do design cen­

trado no usuário. Se você estiver iniciando um redesign de um site, por exemplo,

como saber se seu novo design é melhor do que o original? Como saber se você

realmente atingiu sua visão e melhorou a experiência de seus usuários? Os estudos

de usabilidade podem ajudar a fornecer essas respostas. Eles determinam linhas

de base para acompanhar as melhorias no design de seu aplicativo. Ao observar

ativamente os usuários e documentar seus comentários, suas ações, seus erros

e sucessos, pode-se obter uma perspectiva valiosa sobre como, exatamente, seu

aplicativo está sendo utilizado. (Lowdermilk, 2019, p. 129)

 189

Figura 5.2 - Responsividade

Rido/Shutterstock

Duas abordagens levarão à investigação de aproximação com

o usuário, que será orientada ao comportamento das pessoas diante
dos aplicativos.
A primeira é a investigação contextual. Como abordamos an­
teriormente, o usuário está em seu ambiente de uso e o observador
anota todas as interações que estão ocorrendo. Por exemplo, em
uma pizzaria, quais são os procedimentos de atendimento ao cliente?
Quando ele liga, ele já se identifica ou tem de perguntar pelo telefo­
ne? Haveria alguma promoção interessante para oferecer? Quais são
os sabores que existem? E se o cliente quer saber quais sabores são
indicados, como o atendimento procede? A forma de pagamento,
o endereço de entrega e o telefone de contato são registrados em que
190

meio? Isso somente em relação ao cliente, mas ainda há os processos

de fazer a pizza, de cadastrar o cardápio e de entregar o pedido.
Na investigação contextual, existem elementos que com certeza
não foram citados durante o primeiro contato com a empresa e que
somente no contexto do usuário é possível verificar.
Quando se trata dos estudos de usabilidade, que é a outra
abordagem, toda a estrutura da investigação contextual é realiza­
da de forma roteirizada, com detalhes técnicos que passam pela
configuração de equipamentos até quantos processos existem entre
o atendimento e a anotação de um pedido, no caso da pizzaria.

O objetivo geral de um estudo de usabilidade é medir a eficiência de um recurso

ou de um conjunto de recursos presentes em seu aplicativo. Para isso você deve

definir métricas, como o tempo para execução ou a quantidade de erros ou uma

combinação dessas medidas. O estudo também pode ser combinado com uma

pesquisa para medir aspectos que são difíceis de ser observados, como satisfação

ou percepção de valor. (Lowdermilk, 2019, p. 130)

Em testes de usabilidade, são avaliados diversos itens, por exem­

plo, qual foi a primeira impressão quando abriu o site ou se foi
possível identificar do que ele tratava e quanto tempo isso levou.
Alguns estudos podem apurar se a página fornece os dados corretos
sobre um produto pesquisado, se as imagens são exatamente do
produto que se está querendo comprar e se não haverá surpresas
quando o comprador o receber.
Entre os objetivos do teste de usabilidade estão:

• Averiguar a aceitação de um novo produto no mercado: será que as pessoas estão

dispostas a começar a usar o seu produto para resolver o problema que elas têm?
 191

• Avaliar a usabilidade do produto: as pessoas conseguem completar a tarefa sem

dificuldades, em um tempo aceitável e com baixo nível de esforço cognitivo?

• Comprar a usabilidade de várias versões diferentes da mesma interface: será

que os usuários têm mais facilidade de utilizar botões ou gestos para realizar

uma tarefa? Será que uma versáo funciona melhor do que a outra? Testes de

usabilidade podem ser úteis para entender o que funciona e o que náo funciona

em cada uma das versões testadas.

• Identificar o motivo que leva as pessoas a usarem ou a abandonarem o produto:

será que estão tendo dificuldade em um passo específico do fluxo? Será que

a interface não está fornecendo as informações suficientes para que o usuário

complete a tarefa? Será que eles estão tendo dificuldade em entender o que está

acontecendo com o sistema à medida que interagem com o produto?

• Coletar opiniões e idéias de melhorias: durante os testes, os usuários fazem muito

comentários sobre o que gostam e o que não gostam em determinada solução

de interface, em alguns casos podendo até fazer sugestões de funcionalidades

que eles gostariam de ver naquele produto. (Teixeira, 2014, p. 137)

O teste de usabilidade é definido por Teixeira (2014, p. 34) da

seguinte forma:

Uma entrevista um-a-um com o consumidor, na qual pede-se a ele que realize

uma série de tarefas em um protótipo ou mesmo no produto. À medida que

o consumidor interage com o produto, o pesquisador faz anotações sobre seu

comportamento e suas opiniões. Ajuda a validar fluxos, layouts e funcionalidades.

Existem ferramentas que usam recursos de mapa de calor, no

qual se verifica em quais pontos o usuário clicou mais para realizar
uma tarefa. Nesse mapa, áreas avermelhadas representam as regiões
em que o usuário clicou e que podem ser avaliadas como locais para
192

incluir um anúncio, por exemplo. Outra ferramenta utilizada para

estudos de usabilidade sâo os sensores que seguem o movimento
dos olhos. Um mapeamento é realizado conforme o usuário fixa
seus olhos em determinados pontos da interface, como a demora
em carregar uma página, situação na qual o usuário fica aguardando
algum feedback que demonstre o carregamento.

5.3 Plano de testes

Para avaliar a interação dos usuários, é necessário criar um plano

de testes, que inclui desde o que será avaliado, qual o objetivo das
tarefas, quando será realizado, quem o realizará e um roteiro que
guiará o usuário pelas interfaces. Sem um plano de testes, não há
como atingir o objetivo de conseguir informações acerca da intera­
ção do usuário com o sistema.
O plano de teste deve seguir os requisitos do usuário já mencio­
nados anteriormente e que constituem as especificações de como será
o comportamento exigido do sistema. Muitos querem funcionalida­
des e recursos que podem parecer interessantes no início, mas que,
depois de realizados os testes, podem ser irrelevantes para o sistema.

Pode parecer óbvio, mas, antes de poder conduzir testes, será necessário saber

o que você está procurando. Se você estiver desenvolvendo um aplicativo para

celulares, não entregue simplesmente o celular para as pessoas para ver se elas

vão gostar. Melhores resultados poderão ser obtidos com uma abordagem organi­

zada e que contenha medições. Provavelmente você vai querer ter os participantes
 193

corretos, um roteiro preparado e um conjunto de diretrizes. Isso garante que

os dados que você coletar sejam consistentes e viáveis. (Lowdermilk, 2019, p. 130)

Para realizar o teste de usabilidade, é necessário considerar o tipo

correto de usuário do sistema. Se é para um consórcio de vendas de
carros, por exemplo, deve-se contar com vendedores de automóveis
para testar o aplicativo e consumidores que querem adquirir o con­
sórcio. Se é para analisar a bolsa de valores, os usuários devem ser
investidores e pessoas que querem investir pela primeira vez. Se for
para lojas que vendem produtos infantis, é preciso tratar somente
com crianças ou com os responsáveis que decidem pela compra.
A escolha do tipo de usuário é fundamental para fazer uma investi­
gação correta, e esse tópico deve estar destacado no plano de teste.
Para que não seja um teste aleatório, o mínimo de instrução deve
ser dado ao usuário, isto é, quais são as tarefas ele deve realizar, tanto
específicas, como preencher um cadastro, quanto mais abrangentes,
como fazer a busca de um termo qualquer e verificar o retorno.

Um roteiro pode ser uma maneira produtiva de prover consistência em seus testes.

É fácil desviar-se do curso ou distrair-se quando estiver conduzindo um estudo.

Preparar um roteiro permitirá executar o teste exatamente da mesma maneira

com todos os participantes. Pode parecer estranho ler um roteiro, mas realmente

é a melhor maneira de garantir a consistência. Acho que um roteiro define o tom

para um bom estudo qualitativo. Os usuários saberão que você está agindo se­

riamente para obter resultados válidos e que você veio preparado para o estudo.

(Lowdermilk, 2019, p. 130)

194

Lowdermilk (2019) indica alguns itens que devem fazer parte

de um roteiro de teste de usabilidade:

• Introdução - Na apresentação do roteiro, assim como no for­

mulário, deve ser informado o objetivo do teste que será rea­
lizado. Deve-se comunicar que há segurança dos dados e que
todas as informações serão mantidas em sigilo, além de informar
que são tarefas exclusivas de um comportamento do usuário
diante do sistema e que será de grande ajuda para o sucesso do
aplicativo. "Não se esqueça de apresentar o conceito do estudo
e seu propósito. Dependendo da situação, você poderá ter de
pedir permissão legal ao participante. Certifique-se de saber com
antecedência como você planeja usar os resultados, especialmen­
te se tiver planos para publicar suas descobertas" (Lowdermilk,
2019, p. 131).
• Garantias - Os usuários ficam temerosos ao avaliar sistemas
principalmente se isso ocorrer em seu local de trabalho. Não que­
rem indispor-se com a hierarquia a ponto de colocar em dúvida
um sistema que foi gasto para melhorar a produtividade, por
exemplo. Esse tópico é a garantia de que haverá sigilo das infor­
mações em relação à empresa em que eles trabalham. Ninguém
gosta de falar a verdade e ser exposto ao risco de ser mandado
embora, principalmente em instituições que se recusam a ouvir
seus funcionários. "Nenhum funcionário vai querer que seu che­
fe saiba que ele está tendo dificuldades para usar o software da
empresa. Acho que o uso de palavras como testar ou classificação
pode deixar as pessoas nervosas; em vez disso, considere o uso de
palavras como observar e estudo" (Lowdermilk, 2019, p. 131).
 195

Para elaborar cenários em que o usuário possa interagir, Teixeira

(2014, p. 32) define da seguinte forma os casos de uso que podem
ser explorados: "Uma lista exaustiva dos cenários possíveis enquanto
os usuários estão interagindo com o produto: logado, não logado,
primeira visita etc. Ajuda a garantir que todas as ações são possíveis
dentro do sistema, assim como visualizar como ele se comporta em
cada um dos cenários listados".

5.4 Diretrizes para teste

A equipe designada para coordenar os testes, ou mesmo o pro­

fissional que atua comofreelancer, deve planejar o roteiro definindo
todas as etapas. A preparação é fundamental para o sucesso do evento
e principalmcnte para deixar o participante confiante de que fará
parte de algo que será benéfico tanto para si quanto para o projeto.
Quem conduz o teste precisa ter conhecimento de todo o pro­
cesso de desenvolvimento do sistema. Ter as informações da equi­
pe sobre em que consiste o aplicativo, para qual público-alvo ele
é destinado, qual é o escopo do produto e do teste são informações
importantes, pois o participante sempre terá dúvidas a respeito do
que está fazendo e não se pode deixá-lo sem resposta, mesmo que
seja para lhe dar as respostas na conclusão do evento.
A equipe de teste precisa explicar que a análise será ou do projeto
em andamento ou de um produto finalizado. O protótipo navegável,
que é o sistema inacabado, depende de outros módulos para cumprir
suas funcionalidades. Por exemplo, pode ser que não haja um banco
196

de dados implementado e, por isso, deve-se explicar que os cadastros

já foram feitos pela equipe. Ou seja, o usuário pode visualizar ou
fazer uma busca em uma lista. Alguns softwares que geram protótipos
podem ordenar uma sequência de informações e até mesmo criar
login e senha para acessos, mas essas são funcionalidades que devem
ser implementadas posteriormente, na codificação.
Os testes com sistemas finalizados já passaram por diversas análi­
ses e estudos, e suas funcionalidades foram implementadas depois de
os protótipos serem aprovados. Em sistemas ou módulos finalizados,
o usuário deve ser informado de que o produto em teste já está
com as características com as quais será lançado no mercado. E um
sistema que já deve estar rodando cm ambientes próximos ou seme­
lhantes ao real, principalmcnte para medir a eficiência do produto.
Um participante do teste já consegue cadastrar, editar e remover
informações de um banco de dados. Na listagem visualizada pelo
usuário, os itens cadastrados previamente devem ser consistentes, ou
seja, é preciso evitar o uso de termos como teste o\i teste 123 e nomes
jocosos, pois acabam tirando a credibilidade da avaliação.
Saber com antecedência quais passos serão tomados durante o tes­
te deixa os usuários mais à vontade para realizar as tarefas. Deve-se
informar aos participantes como será conduzida a avaliação em ter­
mos de quantidade de usuários ou se haverá mais pessoas no recinto.
O tempo de condução do teste também deve ser comunicado aos
participantes, pois pode ser programado o quanto eles ficarão naque­
le ambiente. Com um número considerável de usuários, a disponi­
bilidade de equipamentos deve ser otimizada para que todos possam
participar de forma efetiva. Por isso a importância de saber quantos
 197

usuários participarão e qual infraestrutura estará disponível. Quando

se trata de notebooks ou desktops, o layout influencia a permanência
de mais ou menos pessoas circulando no recinto.
Em se tratando de dispositivos móveis, como smartphones
e tablets, deve-se verificar se todos os usuários têm conhecimento
sobre a manipulação desses aparelhos. Outro fator é o tempo de
duração das baterias. E necessário saber qual é o rendimento dos
aparelhos, pois, se for preciso instalar ou atualizar muitos softwares
ou se houver redes móveis instáveis, esses pormenores influenciarão
a durabilidade da carga e não é recomendável utilizar conectores
ligados diretamente na tomada com o manuseio dos dispositivos.
Durante a condução dos testes, o ambiente deve ser organizado
e somente a equipe organizadora e os participantes devem estar pre­
sentes no local. Em alguns casos, uma sala ao lado c utilizada como
observação ou são emitidos ruídos para simular ambientes onde, por
exemplo, conversas entre funcionários na empresa são muito comuns.
Teixeira (2014, p. 32) destaca a importância dos resultados dos
testes para a análise de métricas:

Análise dos números fornecidos por alguma ferramenta de métricas que dão

insights sobre como os usuários interagem com o produto: número de cliques,

tempo de navegação, palavras-chave buscadas etc. Os números ajudam a descobrir

insights valiosos sobre o comportamento dos consumidores, que muitas vezes não

podem ser capturados em um teste de usabilidade.

Ao concluir as entrevistas, é recomendável perguntar ao usuário

como foi participar da entrevista e se algum item ficou de fora do
estudo. Ter a visão clara de como o entrevistado se saiu no teste de
usabilidade é importante para estruturar futuros exames. Geralmente,
198

os participantes querem falar sobre como se saíram ou se fizeram

as tarefas corretamente e acabam esquecendo um pouco o sistema.
Por fim, não se deve esquecer de agradecer o tempo disponibili­
zado para testar o sistema e de informar que todos os feedbacks ano­
tados serão compilados para melhorar o aplicativo. Vale até entregar
um mimo para os participantes, como um simples bombom, como
agradecimento. Um e-mail mais tarde é importante para lembrar
mais uma vez a importância do teste de usuário.
Após a condução dos testes, os resultados devem ser docu­
mentados e apresentados à equipe de desenvolvimento conforme
o cronograma, pois todos estarão, a essa altura, curiosos sobre como
os trabalhos foram executados durante o projeto do aplicativo e qual
impacto isso teve nas mãos de um usuário.
Todo os testes de usabilidade servem para verificar o estado
atual de um sistema e a forma como o usuário se comporta diante
dos recursos oferecidos. E uma construção contínua de projetos de
softwares que faz parte do design centrado no usuário e que já está
sendo a realidade de muitas equipes de desenvolvimento.
utterstock_1405996949
MATERIAIS
E MÉTODOS
 203

Antes de iniciar qualquer teste com usuários, é importante ter

em mente algumas práticas que serão norteadoras para o sucesso da
análise dos resultados obtidos. Simplesmente, não é recomendável
colocar um participante diante de um aplicativo e fazê-lo testá-lo
exaustivamente, mesmo que seja um protótipo. A ambientação
é o primeiro contato entre o usuário e o aplicativo, o que possibilita
análises fiéis sobre o uso correto dos sistemas. E como se preparar para
a análise de estudos com os usuários? Na Plataforma Corais (2020),
é apresentado um checklist de alguns itens que devem ser verificados:

• Os objetivos do teste estão bem definidos?

• As tarefas a serem propostas ao usuário estão claras?

• Os equipamentos estão todos funcionando?

• Já testou os equipamentos de novo?

• Agendou direitinho horário e local com o usuário?

• Você tem o guia para conduzir o teste à mão?

• E o termo de consentimento para o usuário?

• Vai aplicar um questionário de satisfação?

• Está com as recompensas para os usuários preparadas?

• Já realizou um teste-piloto?

• Você tem certeza de que realizou um teste piloto?

E quando a cultura do local é impeditiva para a realização dos

testes de usabilidade? Levar a cabo todo o processo de entendimento
da experiência do usuário pode ser penoso em algumas empresas que
desenvolvem sistemas, pois é uma prática não muito comum e vista
como perda de tempo. Muitas equipes acabam não adotando pesqui­
sas com usuários por tratarem o assunto com muitos complicadores.
Teixeira (2014, p. 140) relata algumas desculpas para equipes não
realizarem os testes de usabilidade:
204

Eu não tenho um laboratório de usabilidade. Você não precisa de um laboratório

completo, com equipamentos de última geração e com sala de espelho. De fato,

você nem quer ter um. Laboratórios muito elaborados podem deixar os partici­

pantes nervosos e influenciar no resultado. Um lugar mais casual traz resultados

melhores para os testes.

Eu não tenho um software de gravação de tela. Bom, existem softwares gratuitos

disponíveis online que fazem isso, ou então versões "Trial" de softwares pagos

que você pode usar por alguns dias. E se você não puder instalar um software para

gravar o que está sendo testado, faça o teste mesmo assim. Você sempre aprenderá

alguma coisa dos usuários.

Eu não sei fazer uma análise estatística dos resultados. Não precisa. Testes de

usabilidade são qualitativos, por natureza. Você está em busca de insights, não

de estatísticas.

Eu não conheço participantes suficientes. Já que você não está procurando por

estatísticas, e sim por insights, teste com três a cinco usuários. Na verdade, testar

com um usuário já é infinitamente melhor do que testar com zero usuário.

Alguns podem deixar de realizar os testes de usabilidade por

terem um orçamento apertado ou até mesmo por não contarem
com nenhum investimento. Por que o próprio desenvolvedor ou
o designer nâo faz o teste? E questão de procurar um tempo para
testar todas as formas de navegação.
Casos de outras equipes de desenvolvimento que praticaram os tes­
tes de usabilidade são formas de ter um direcionamento sobre como
aplicar nas empresas que não adotam essa prática. Basta entrar em
contato e solicitar informações sobre a aplicação com os participantes.
Outros podem afirmar que o sistema está atendendo a todas
as solicitações do cliente e que este já fez a revisão. Porém, a questão
é analisar se o cliente será o usuário ou quem vai utilizar o sistema
 205

é somente o cliente? Pois há diferenças significativas entre esses casos,

como estamos vendo.
Se o produto não está finalizado, podem ser testados os protóti­
pos ou até mesmos os wireframes, com a equipe de desenvolvimento
dando apoio na condução dos testes. São as primeiras idéias que
ainda podem ser ajustadas, e nada melhor do que fazê-lo com a pre­
sença de um usuário.
Pode ser que não se encontrem exatamente os usuários que
atendem ao perfil, mas nada impede de procurar perfis próximos,
por exemplo, que participam dos mesmos grupos em redes sociais.
Entrar em contato pode ser uma forma de encontrar pessoas que
podem realizar os testes, até mesmo remotamente.
Para o projeto ter sucesso, é necessário realizar os testes de usa-
bilidade com os usuários em potencial. Os participantes dos testes
serão o “termômetro” em se tratando de avaliar se as necessidades
estão sendo abordadas pela ótica do usuário. Mas como conseguir
um determinado número de usuários, como foi sugerido no capítulo
anterior? Para algumas equipes, conseguir cinco pessoas é uma tarefa
nada fácil, por isso alguns sistemas não passam pela análise dos
usuários, considerando-se a aprovação do cliente como suficiente
para o lançamento do aplicativo.
As necessidades do usuário somente serão avaliadas se o sistema
for submetido a uma análise criteriosa. Essa apreciação do aplicativo
como projeto deve contar com a participação do usuário, por mais
que as equipes tenham maturidade em desenvolvimento. Para atestar
a importância do teste de usabilidade, Lowdermilk (2019, p. 133)
destaca que a regra de cinco usuários, descrita no Capítulo 5 con­
forme Nielsen (2012), pode ser adaptada:
206

Lembre-se de que a única garantia é que, se você não conduzir nenhum estudo,

poderá esperar que nenhum problema de usabilidade seja encontrado. Prefiro

conduzir um estudo com três pessoas, a não fazer nenhum estudo. Por outro

lado, ter participantes demais pode ser um pesadelo logístico que traria complica­

ções e atrasos aos seus esforços.

Um número inferior a cinco participantes continua a ser uma

análise das interfaces. Como visto anteriormente, muitos dos testes
de usabilidade são avaliados por poucos usuários, pois a maior parte
vai chegar aos mesmos resultados. Um número grande de usuários
pode significar uma estrutura maior de preparação, pois envolve
contato com os participantes, disponibilidade dos observadores,
ambiente adequado para receber muitas pessoas e equipamentos
disponíveis para todos.

Figura 6.1 - Cinco participantes: número suficiente

na maioria dos testes de usabilidade

 207

Talvez muitas equipes acreditem que seja necessário um número

alto de usuários para se realizar um teste de usabilidade com sucesso,
mas, como foi tratado no capítulo anterior, ter poucos participantes
é o suficiente e não exige grandes esforços, já que é uma prática
orientada ao sucesso do projeto. Segundo Lowdermilk (2019,
p. 133), não é o número de participantes que define um teste de
usuário: "Não pense que testar somente algumas pessoas seria um
desperdício de tempo. Se você tiver acesso somente a um grupo
pequeno de usuários, mesmo assim, eu o aconselho a tentar realizar
testes de usabilidade. Já conduzi estudos bem pequenos e, apesar
disso, obtive conhecimentos valiosos".
A equipe que adota a visão da experiência centrada no usuá­
rio precisa se ater a algumas práticas quando iniciar os testes com
eles. Anteriormente, deve-se ter em mente que a convocação dos
participantes deve ser esclarecedora sobre a natureza do teste e a im­
portância de sua contribuição ao evento. Da parte dos usuários que
se envolvem nos testes, é um chamado para que um projeto tenha
características suas, pois houve contribuição. Da parte da equipe,
é uma oportunidade para alinhar as atividades e as tarefas com
o escopo do projeto, com uma menor incidência de retrabalho.
Muitos desenvolvedores e designers trabalham como freelancers
e acabam não envolvendo usuários nos testes dos aplicativos, pois
acreditam que não têm a estrutura necessária. No entanto, como
vimos, eles podem contar com colegas, amigos, familiares e todos
os perfis ligados a suas redes sociais. Até mesmo em cursos voltados
à área de desenvolvimento de sistemas, os alunos e os professores de­
vem realizar a prática de testes de usabilidade. No primeiro momen­
to, isso deve ser feito com colegas da sala de aula e professores; após
o refinamento, pode-se procurar outros cursos da mesma instituição
208

e que sejam fora da área de tecnologia da informação para se realiza­

rem os testes com usuários com menor carga de experiência técnica.
Isso leva a prática de testes de usabilidade ao conhecimento de outros
cursos e pode gerar trabalhos em grupos, pois algumas modalidades
precisam inovar em termos de produtos durante uma apresentação
de trabalho de conclusão de curso, que é a oportunidade de alunos
de tecnologia da informação (TI) desenvolverem seus produtos.
Estudantes se transformam em clientes, o que faz com que se saia
da teoria, aplicando-se os conhecimentos de usuários na prática.
Para os estudos voltados a dispositivos móveis, é recomenda­
do saber se os usuários já estão familiarizados com aplicativos em
smartphones. Budiu (2014), no artigo Usability Testingfor Mobile Is
Easy, observa que o participante de testes em dispositivos móveis
deve ter pelo menos três meses de experiência no uso, pois usuários
recentes não terão comportamento típico em relação à navegação
em aplicativos para smartphones.
Muitos usuários podem ter mais de um modelo de smartphone,
o que representa uma navegação diferenciada, podendo gerar temas
bem específicos, por exemplo: “Qual seu nível de satisfação ao usar
o tablet NT ou “Agende um compromisso para amanhã, ao meio-
-dia, no smartphone X”.
Budiu (2014, tradução nossa) destaca alguns itens que são neces­
sários quando o usuário precisa realizar o download dos aplicativos:

Se você deseja que os usuários instalem aplicativos de uma app store em seus

dispositivos, verifique se:

• Eles sabem como fazer isso (isso pode ser um problema especialmente para

tablets, que geralmente são dispositivos compartilhados).

 209

• Eles sabem sua senha da app store ou a trarão para a sessão de teste.

• Eles têm um cartão de crédito associado à conta (se você deseja que eles baixem

aplicativos pagos durante o estudo). Se eles não tiverem um, esteja preparado

para oferecer a eles um cartão-presente que eles possam usar para comprar

os aplicativos - e, é claro, reembolsá-los imediatamente por essa compra.

Deve-se levar em conta que os testes de dispositivos móveis sâo

testes de usabilidade, e não avaliação dos aparelhos. São atividades
distintas, assim como a navegação em desktop ou em notebook-, não
se está avaliando a ergonomia do dispositivo. O que vem ocorren­
do é que aparelhos estão ficando cada mais sofisticados e menores,
porém a interação com o usuário vem aumentando.
Outra forma de testar interfaces é a avaliação de telas responsivas.
O comportamento dos elementos na interface iveb se dará conforme
o dispositivo acessado, que pode ser o desktop (largura de 1.280
pixels), o tablet (largura de 760 pixels) ou o smartphone (largura
de 320 pixels). Na codificação, o desenvolvedor deve programar as
medidas de como o layout ficará para que o usuário tenha uma boa
experiência. Nos testes que não envolvem o aparelho, os navegadores
simulam as telas dos diversos dispositivos. E nesse momento que
o usuário observa o comportamento de tabelas, menus e imagens
no tablet e no smartphone, principalmente se há o movimento de
pinça com os dedos para navegar entre as telas, prática incômoda
entre os usuários.
Muitas atividades durante os testes podem ser cronometra­
das, pois dependem de alguns apontamentos sobre a eficiência
do sistema. Os smartphones, hoje em dia, têm cronômetros com
recursos que otimizam a marcação do tempo, com registros de
210

todas as etapas e avisos sonoros. Entretanto, podem também atra­

palhar o usuário se ele perceber que está sendo avaliado pelo tempo
que executa as tarefas. Pode-se achar que seu desempenho é inferior
ao de outro usuário.
O que deve ser explicado nesse momento para o participan­
te é que será anotado o tempo das tarefas, mas que a execução
e o entendimento serão diferentes para cada um. Quanto aos alarmes
e aos avisos sonoros, eles devem ser comedidos, podendo restringir-
-se à vibração do aparelho. Vale lembrar que qualquer semelhança
com uma prova ou um exame deve ser descartada dos vocabulários
da equipe, pois muitos usuários não se sentem confortáveis sendo
analisados. Muitas funcionalidades independem de cronometrar
o tempo da atividade, por isso não é necessário preocupar-se em ser
meticuloso com cada movimento do usuário.

Obviamente, o tempo para completar uma tarefa não deve determinar todas

as decisões de design. Só porque um usuário consegue completar rapidamente

uma tarefa não significa que o design seja mais agradável. Mesmo que não seja um

fator específico em minha decisão de design, gosto de registrar o tempo que cada

participante gasta para completar as tarefas. (Lowdermilk, 2019, p. 133)

Iodos os registros das observações do usuário durante os tes­

tes devem ser documentados, e suas ações, anotadas conforme são
realizadas.
Como ocorrem atividades que podem ser rápidas, aconselhamos
realizar as anotações no papel, em vez de usar notebooks ou smartphones.
Durante o acompanhamento dos testes, não deve haver interrupções,
por exemplo, solicitar ao usuário que faça novamente uma ação para
 211

que seja anotada em um aplicativo de registros. Com um bloco de

anotações, as considerações sobre os usuários são registradas e depois
compiladas em um aplicativo. Esses conteúdos são parte da docu­
mentação que compreende o histórico do sistema, com informações
valiosas e sempre à disposição da equipe.
E quando os testes não podem ser realizados presencialmente,
como na situação de pandemia, em que vários ambientes tiveram seu
acesso restrito? Nesse caso, existe a alternativa do teste remoto, no
qual os usuários acessam o sistema de outras localidades, a partir de
seus dispositivos. A moderação ficará comprometida, já que a equipe
não estará ao lado do participante o tempo todo, explicando e reali­
zando as anotações, mas algumas ferramentas podem facilitar, como
o site Mouseflow1, que registra todas as ações do usuário e mostra,
em forma de mapa de calor, onde se dá a maioria dos cliques.
Moran e Pernice (2020) descrevem como o teste remoto não
moderado pode ser uma alternativa para procedimentos de análise
da experiência de usuário e que ganhou importância quando as pes­
soas precisam permanecer em suas casas ou isoladas.
O teste remoto não moderado é realizado na forma assíncrona,
com a disponibilidade do participante podendo ser mais flexível,
porém dentro de um tempo predeterminado. Algumas ferramentas
dão suporte para que os registros sejam coletados e estudados depois
de se completarem os testes.
Para Moran e Pernice (2020, tradução nossa), o teste remoto não
moderado tem as seguintes vantagens:

1 Disponível em: <http://www.mouseflow.com/heatmap>. Acesso em: 14 dez. 2020.

212

• Sem recrutamento (se você estiver usando os painéis integrados de usuários que

os serviços de teste remoto fornecem)

• Nenhuma habilidade de moderação necessária

• Configuração fácil de teste

• Resultados rápidos

• Baixo custo

Os pontos negativos do teste remoto nâo moderado são dados pela

ausência de detalhamento da condução das ações. Moran e Pernice
(2020, tradução nossa) destacam os seguintes pontos negativos:

• Sessões curtas de teste (a duração é limitada pelas regras do serviço de teste,

mas geralmente é de cerca de 20 minutos, em comparação com 1 -2 horas para

estudos presenciais)

• Instruções um pouco ambíguas ou pouco claras não são esclarecidas no momento

• Incapacidade de pedir aos usuários que elaborem um comentário ou continuem

usando uma área do design

• Testadores não representativos

• Variabilidade na motivação e comprometimento dos participantes com o teste

• Alta chance de que os testadores executem várias tarefas ou se distraiam com

o ambiente

Os testes remotos moderados utilizam as práticas do teste pre­

sencial e do teste remoto nâo moderado, criando uma alternativa
também barata. Para a preparação do teste, é importante verificar
o recrutamento e as versões de software disponíveis nos dispositivos
dos participantes.
 213

Portanto, o teste remoto não moderado é uma alternativa para

situações em que o presencial estará descartado principalmente em
termos de custo. E uma opção melhor do que não realizar nenhum
teste. Nessa modalidade, as análises e as idéias podem surpreender,
pois é externa ao terreno do olhar técnico. Moran e Pernice (2020,
tradução nossa) afirmam que “o teste remoto não moderado tem
a vantagem de ser rápido, barato e fácil. Ele pode nos dar ótimos
insights e deve fazer parte da caixa de ferramentas de todo pesquisa­
dor de UX”. Porém, o teste remoto moderado traz à luz riquezas de
detalhes muitas vezes não observados pela equipe.
Com o teste remoto, também se pode analisar o quanto o parti­
cipante consegue interagir com o sistema sem a constante presença
de um interlocutor, pois o acompanhamento presencial pode deixar
o usuário um tanto quanto constrangido.
E com relação à experiência do usuário cm jogos, como deve ser
a preparação para os testes? São detalhes que caracterizam o tipo de
público que vai jogar e será estudado seu comportamento diante
desses aplicativos. Por exemplo, se forem crianças, devem-se evitar
distrações no ambiente que tiram o foco do jogo, como uma cadeira
giratória que possibilita ao jogador observar todo o ambiente em
que ele se encontra.
Nielsen (2016) relata que, em uma conferência, ouviu a mesma
prática que havia adotado em suas pesquisas nos anos 1990, só que
em outro ambiente: o uso, hoje em dia, de câmeras para estudar
o comportamento do jogador e que na época era um recurso para
analisar o ambiente de sistemas.
214

Para gravar as sessões de teste e obter os gestos em vídeo, os pesquisadores reco­

mendaram o uso de 3 câmeras de vídeo: de cima, de lado e de frente para o usuário.

Exatamente o que fizemos há 20 anos no laboratório de fatores humanos de

hardware para registrar os administradores de sistema que instalam discos rígidos

em servidores. Testar interfaces de usuário 3D requer mais equipamentos do que

estudar sites 2D. (Nielsen, 2016, tradução nossa)

Outra situação é o comportamento dos gestos do jogador quan­

do existem sensores de movimento. Nielsen (2016, tradução nossa)
explica que, “por exemplo, os pesquisadores precisaram incluir
o tamanho da mão dos usuários como um dos critérios de triagem
ao recrutar os participantes do teste. Certamente não perguntamos
sobre o tamanho das mãos em nossos filtros e, aparentemente,
é um desafio acertar”.
Os testes com vários usuários jogando também têm suas parti­
cularidades, principalmente porque os jogos demoram muito tempo
para serem jogados.

Os jogadores hardcore frequentemente jogarão por horas seguidas, com muito do

seu tempo gasto atirando em algo repetidamente. Como resultado, laboratórios

de playtesting em todo o mundo parecem ser uniformemente projetados para

acomodar 12-20 testadores de jogos (ou mais, para grandes empresas) que jogam

o mesmo jogo, cada um em seu próprio console. (Nielsen, 2016, tradução nossa)

O jogo não tem outro propósito senão a diversão. Alguns pesqui­

sadores adotam leitores biométricos para analisar como está o nível
de envolvimento dos usuários com o game.
 215

6.1 Ambiente e banco de dados

Se o local onde será realizado o teste com o usuário for a empresa

em que se está desenvolvendo o projeto, é recomendável avisar a todos
da equipe que a condução do evento será decisiva para o andamento
das etapas de produção. É importante que somente a equipe de teste
tenha acesso ao usuário e que qualquer pergunta seja feita antes da
realização do estudo com ele. A abordagem por alguém de fora da
equipe de teste pode constranger o usuário, a não ser que ele queira
encaminhar alguma questão, mas isso deve ser feito no final do teste.

Figura 6.2 - Dados registrados: armazenar para consultas futuras

216

Antes de o usuário entrar no ambiente de testes, deve-se recebê-lo

em uma sala de espera com um sofá ou uma poltrona confortável,
para que fique à vontade. Pode-se oferecer a ele alguma bebida
e, caso haja atrasos, informá-lo sobre o ocorrido.
Para que os usuários se sintam bem para executar as tarefas,
o ambiente deve ser preparado adequadamente, com climatização
em relação à temperatura apropriada, pois tanto o frio como o calor
podem deixar o participante desconfortável.
Outro fator que influencia é o som no local. Por isso, as jane­
las devem estar bem vedadas, para que o barulho do trânsito não
incomode, principalmente em regiões onde o tráfego é intenso.
Conversas próximas podem levar o usuário a pensar que estão criti­
cando suas tarefas e acabam desestimulando sua participação. Além
disso, o smartphone deve ser deixado no modo silencioso para que
nenhuma ligação seja atendida naquele momento.
Deve-se considerar, se possível, um local para a concentração dos
observadores, que podem fazer parte da equipe técnica ou ser o cliente
ou convidados. As conversas geradas no local não devem interromper
o fluxo de teste, por isso o ambiente deve ser isolado. As observações
feitas pelos usuários podem ser ouvidas pela equipe de observadores,
o que facilita análises sobre o fluxo cognitivo do participante.
Os equipamentos que serão utilizados no teste de usabilidade
devem ser familiares ao ambiente em que o aplicativo será imple­
mentado. Muitas vezes, os testes são realizados em equipamentos
com configuração mais avançada do que a daqueles utilizados pelo
usuário no dia a dia. Dessa forma, uma infraestrutura média em
relação aos processadores, memórias, tamanho de telas e velocidade
da internet deve ser observada.
 217

Alguns participantes acabam trazendo dispositivos pessoais

para o ambiente de teste, por isso, para se ter certeza de que não
haverá interrupções, deve-se solicitar educadamente que esses
aparelhos sejam desligados ou que alguém próximo que executará
um teste de usabilidade seja avisado. As pessoas admiram quando
os detalhes da atividade estão sendo observados para que tudo saia
conforme o planejamento.
Outro fator importante: caso o tempo de teste seja prolongado,
devem ser providenciados lanches e bebidas. A atividade de teste
exige concentração, o que pode demandar recursos como esses.
Para testes com dispositivos móveis, Budiu (2014) explica que
é necessário adequar o ambiente com alguns procedimentos extras.
Recomenda-se um ambiente com luzes controladas, a começar com
a luz natural que incide pela janela. Cortinas com blackout dificul­
tam a passagem da luz e contribuem para se ter uma boa experiência
do usuário, já que reflexos diretamente na tela do dispositivo podem
dificultar a visualização da interface.
Esses cuidados podem influenciar até mesmo o vídeo resultante
da filmagem. Sobre isso, Budiu (2014, tradução nossa) destaca:

O brilho da câmera, da tela do dispositivo e do monitor no qual a tela do dispositivo

é projetada influenciará na qualidade da projeção ao vivo e do vídeo resultante.

Você deve poder ajustá-los facilmente no início da sessão de teste e, se necessário,

durante o teste (embora seja melhor evitar interromper o participante durante

as tarefas com uma solicitação para ajustar o brilho da tela do dispositivo).

Outra observação em testes com dispositivos móveis diz respeito

à qualidade do sinal dentro do ambiente. Se forem utilizados dados
218

móveis, é necessário certificar-se de que não há regiões com sombra,

que são locais aos quais o sinal não chega. Caso seja utilizada a rede
WiFi do local, a senha para acesso deve estar acessível e com ótima
qualidade, para que durante o teste não haja interrupções. Contudo,
qualidade ruim de sinal pode ser um outro item a ser avaliado nos
testes. Budiu (2014, tradução nossa) ressalta que "Como a conec­
tividade geralmente é pior no sinal celular, é possível ver como
o aplicativo se sai em uma conexão ruim. Por outro lado, com um
bom WiFi, você pode se concentrar nos problemas da interface: esse
botão é saliente o suficiente? O usuário pode entender o conteúdo?".
Diferentemente do que foi comentado sobre o som no ambiente,
para dispositivos móveis é recomendado criar uma atmosfera de
ruídos cm torno do teste. Geralmente, as pessoas utilizam os dispo­
sitivos móveis cm locais com diversos tipos de sons, e é interessante
escolher momentos em que haja, por exemplo, conversas próximas
ou movimentos da equipe no local.
Com todas as observações anotadas em papel, é o momento de
compilá-las e formar um banco de dados dos registros do teste com
o usuário. Esse banco de dados não deve ser alimentado durante
o teste, pois as atividades do usuário costumam ser rápidas e não há
tempo hábil para registrá-las em aplicativos. Editores de planilhas,
como o Excel', da Microsoft, ou a planilha do Google Does, ofere­
cem excelentes recursos para armazenar esses registros, que podem
ser compartilhados com toda a equipe. Organizando-se por projetos,
é possível fazer uma busca mais otimizada e, dentro de cada projeto,
as funcionalidades podem ser registradas, com níveis de prioridade
baixa, média e alta, identificadas com cores e símbolos acordados
entre os membros da equipe.
 219

Aqui, pode-se considerar até mesmo a possibilidade de criar um

aplicativo que personalize as atividades de teste. Uma plataforma
especialista em teste de usabilidade pode ser adaptada aos trabalhos
da equipe e essa é outra forma de encontrar padrões rapidamente.

6.2 Gravação

Quando se trata de registrar as ações do usuário, muitos recor­

rem à gravação de áudio e de vídeo. Porém, isso deve ser feito de
maneira discreta, pois muitos ficam constrangidos quando estão
sendo observados executando atividades. Aos usuários deve ser in­
formado que será feita a gravação de áudio e vídeo a fim de realizar
registros. Como destaca Lowdcrmilk (2019, p. 134), “a maioria das
pessoas detesta a ideia de ser filmada e, não importa o quanto você
lhes assegure do contrário, os participantes terão a sensação de estar
sendo testados”.
A gravação pode ser feita por smartphones que dispõem de re­
cursos como balanceamento de luzes do ambiente ou lentes grandes
angulares que conseguem capturar maiores espaços.
Durante o teste, pode-se recorrer à captura de algumas fotos,
em vez de gravação. Muitos detalhes nas fotos são registrados e im­
portantes para a condução da análise. Segundo Lowdermilk (2019,
p. 134-135),

Se achar que uma câmera ou um dispositivo para gravação seja necessário, certi­

fique-se de que o equipamento seja discreto. Além do mais, inclua o fato de que

você estará gravando o estudo em seu roteiro. Você também deverá considerar
220

a opção de perguntar se o participante prefere não ser filmado. Usar a câmera de

seu smartphone para tirar algumas fotos poderá ser menos intrusivo. Às vezes, um

conjunto de fotos é suficiente para documentar como os participantes responderam

durante o estudo.

E importante informar aos usuários que qualquer manifesta

ção oral pode ser realizada, pois muitas anotações dependem das
reações verbais que eles têm.
Caso o usuário se sinta constrangido com a gravação, outro re
curso que pode ser adotado é a captura de tela em vídeo, a mesma
que os apresentadores de tutoriais utilizam para explicar como são
usados os softwares. Aplicativos de captura são configurados para
destacar ações do mouse, por exemplo, e armazenam o resultado
em espaços gratuitos, como o Google Drive.
Budiu (2014) menciona testes para dispositivos móveis que têm
procedimentos diferentes ao realizar as gravações, a começar pela
captura da ação dos dedos. Para registrar os movimentos de pinça
ou de arrasto, os softwares de gravação não conseguem ainda diferen
ciá-los. Por isso, é necessário um auxílio externo para capturar esses
movimentos, como uma câmera ou uma webcam.
Para os testes que usam dispositivos móveis, os equipamentos
externos são os mais utilizados pelos pesquisadores. Como explica
Budiu (2014, tradução nossa),

Por todos esses motivos, a gravação com uma câmera externa ainda é o método

preferido ao realizar testes de usuário para celular. Quase qualquer câmera de vídeo

pode ser usada, desde que ela permaneça focada na tela enquanto o participante

do estudo estiver usando o dispositivo. Embora seja possível fixar uma câmera

comum em um tripé logo acima do dispositivo móvel, a maioria dos pesquisadores

 221

de usabilidade móvel prefere uma webcam ou uma câmera de documentos porque

eles geralmente vêm com um software que permite a projeção em tempo real das

imagens de vídeo na tela do computador. Isso permite que o facilitador testemunhe

o que o participante do estudo faz em seu telefone sem se intrometer em seu espa­

ço pessoal. Em nossos estudos de usabilidade em dispositivos móveis, usamos dois

tipos de câmeras: uma câmera de documentos e uma webcam. Existem vantagens

e desvantagens para cada um deles.

Para registrar as ações do usuário manipulando o smartphone,

é recomendada a gravação com webcam. Para isso, deve-se restringir
o local onde o participante vai testar o aplicativo e conectar o dis­
positivo a um notebook ou desktop, de maneira que o usuário não
visualize a gravação, para que não se distraia vendo as próprias ações.
Se for colocado sobre a mesa, o smartphone ficará a maior parte do
tempo imóvel, o que facilita a filmagem. No entanto, essa não é a for­
ma natural de se utilizar o celular, o que acaba restringindo alguns
movimentos, por exemplo, estar deitado navegando no aplicativo.
Algumas equipes de testes acabam fixando o celular em uma
espécie de berço, que deixa o dispositivo móvel junto à webcam,
liberando as ações do usuário e tornando mais natural a navegação.
Outra característica importante da webcam é ter o foco manual
e o zoom, pois, no automático, a tendência é focalizar o movimento
dos dedos, e não a tela do dispositivo.
No momento da gravação, é importante que o teste seja projeta­
do em um notebook ou desktop para ser acompanhado e armazenado
para futuras edições. Hoje, as webcams, quando conectadas, já são
reconhecidas pelo sistema operacional. Caso não apareça a imagem,
é necessário atualizar o drive do dispositivo de filmagem, que é ob­
tido no site da empresa do dispositivo.
222

Após a gravação, a filmagem pode ser editada no software com

o qual a equipe está acostumada a trabalhar, eliminando-se sequên­
cias desnecessárias para posterior análise.
Para reproduzir a gravação, Budiu (2014, tradução nossa) reco­
menda: "Até 2 observadores podem assistir ao vídeo em uma tela de
laptop aglomerando-se perto do facilitador; com mais observadores,
use a porta de monitor externo do laptop para projetar a alimentação
de vídeo em um monitor ou projetor externo”.
Uma projeção pode ser realizada na parede, caso não haja suporte
para projetores. A imagem ampliada ajuda a equipe na observação
de detalhes.

6.3 Condução de estudo

Os usuários vão seguir o roteiro preparado previamente no qual

está descrito o passo a passo que devem executar. Por isso, é im­
portante fazer a revisão de todo o conteúdo para observar se há
inconsistências, como caminhos, links, dados de usuário e imagens
para anexar. Deve-se criar um roteiro separado para os analistas
e para o usuário. O plano de quem está observando é o geral, em
que cada etapa está resumida, já que os detalhes devem ficar com
o usuário. Na condução do estudo, a equipe tem a ideia geral do teste
por meio do roteiro macro, com o mínimo de detalhamento. Para
o participante, os detalhes são importantes porque refletem o passo
a passo da execução da tarefa.
Contudo, o nível de detalhamento do roteiro não pode fazer au­
mentar a quantidade de papéis em cima da mesa do usuário. Por isso,
 223

é recomendável evitar acumular roteiros em cima da mesa do par

ticipante no momento do teste, pois pode parecer que será uma
tarefa árdua e longa. Assim, convém conduzir as tarefas por etapas
apresentando-se antes cada uma delas e recolhendo-se aquelas que já
foram realizadas. Sâo distrações assim que acabam deixando o teste
superficial, pois o participante vai querer encerrá-lo antes do tempo.
E importante que não se disponibilizem roteiros em arquivos
PDF, pois o usuário terá mais uma tarefa ao visualizar o arquivo de
roteiro toda vez que precisar saber qual o próximo passo. Alguns
são hábeis com o teclado para saltar de um aplicativo para o outro,
porém não está sendo avaliada a performance de abrir aplicativos
pelos atalhos do teclado.
Na parte superior de quem está liderando e de quem está exe­
cutando as tarefas de teste de usabilidade, colocam-se o nome do
projeto e a data da execução. Uma logo da empresa deixa o teste
mais profissional. A impressora deve estar calibrada e imprimindo
corretamente, sem falhas. O texto deve estar formatado em tamanho
legível c que apresente contraste com o papel, ou seja, se o papel for
branco, usa-se preto para os textos. Alguns criam roteiros com espa­
ço para anotações e dúvidas para serem respondidas posteriormente.
A linguagem usada no roteiro deve ser adequada ao usuário, pois,
quando se utiliza linguagem técnica da informática, pode haver
dúvidas sobre o significado de determinadas palavras. Sabendo-se
qual é a regra de negócio do cliente, consegue-se o vocabulário
adequado, que seja de fácil compreensão, quando for apresentado
o roteiro aos participantes.
Aos participantes é recomendado que pensem alto durante a exe­
cução das tarefas. Pode parecer loucura, mas, quando eles verbalizam
224

as ações, a equipe pode colher mais informações referentes ao pro­

cesso cognitivo dos usuários. Caso eles cliquem em alguma área que
não executa a ação desejada, eles verbalizam e fica explícito por que
escolheram errado ou associaram a ação com aquele recurso.
No roteiro, é interessante fazer as marcações nos pontos em que
eles precisam falar o que está ocorrendo no momento. A verbalização
se torna um estranhamento no início para o usuário, mas, com
uma conversa explicativa sobre a importância disso, o processo vai
transcorrendo normalmente. Segundo Lowdermilk (2019, p. 135),

Você deve recomendar continuamente aos participantes que eles pensem alto.

Por meio desse processo a pessoa estará dizendo a você o que ela está pensando

enquanto executa a tarefa. É muito fácil para os usuários focar silenciosamente

na execução da tarefa. O problema com isso é que você perderá seu processo de

raciocínio. Você não poderá realmente saber o que eles estão pensando enquanto

eles estiverem usando seu aplicativo a menos que eles digam a você.

Podemos tomar como exemplo uma situação cm que o usuário

está testando um sistema com o perfil com atributos que só o gerente
pode executar. Quando for iniciar o teste, ele verbaliza que está
entrando com o perfil “Gerente” e vai colocar login e senha. Caso
não entre, ele se manifesta que não está acessando com os dados
previamente cadastrados. No decorrer do teste, o usuário não con­
segue realizar uma tarefa. Foi colocada propositadamente, pois era
atributo de outro perfil. Então, caso verbalize o erro, o observador
consegue intervir, explicando que é ação de outro perfil. Se o usuário
não se pronuncia, pode achar que o erro está na própria execução.
Nos casos em que se direciona o usuário para encontrar uma ferra­
menta e ele não consegue visualizar, falar que não está conseguindo
 225

torna mais evidente o problema e ajuda a estudar as outras ações

que precisam ser tomadas.
Outra prática recomendada é ler e dar instruções em voz au­
dível, para que o participante possa se concentrar nas atividades
do teste, e perguntar a ele se compreendeu a instrução. Intervalos
de descanso caso o teste demore muito são interessantes para não
sobrecarregar o usuário.
Uma possibilidade é que o usuário peça ajuda para executar as ta­
refas. Quando se trata de intervenções, é preciso observar se o roteiro
foi mal redigido, se há uma rubrica para pedir ajuda à equipe ou se
é problema de navegabilidade. Questões que envolvam a navegação
no sistema não podem ser resolvidas com a ajuda da equipe, pois
ali está um problema que deve ser entendido posteriormente pelas
anotações que serão realizadas. Quando se esgotarem as tentativas
por parte do usuário, deve-se intervir no caso de se tratar de uma
ação imprescindível para a continuidade do teste daquela tarefa cm
questão; do contrário, segue-se o teste e medidas serão tomadas.
Sempre é importante dar o feedback para o participante, ainda que
seja algo no seguinte sentido: “Como você resolvería essa questão?”.
Fazer o usuário participar das decisões cruciais vai levá-lo a conhecer
a importância da análise da participação no teste de usabilidade.
A explicação sobre como o aplicativo funciona precisa ser apre­
sentada no momento de treinamento de uso do sistema, e não quan­
do o comportamento do usuário está sendo analisado. No treina­
mento, o aplicativo já foi validado e está no ciclo de vida do produto,
e as intervenções são necessárias para que nenhuma dúvida fique sem
resolver. Segundo Lowdermilk (2019, p. 135),
226

Você deve recomendar continuamente aos participantes que eles pensem alto.

Por meio desse processo a pessoa estará dizendo a você o que ela está pensando

enquanto executa a tarefa. É muito fácil para os usuários focar silenciosamente

na execução da tarefa. O problema com isso é que você perderá seu processo de

raciocínio. Você não poderá realmente saber o que eles estão pensando enquanto

eles estiverem usando seu aplicativo a menos que eles digam a você.

E qual seria a posição da equipe dentro da sala de testes diante do

usuário que está testando o aplicativo? Lowdermilk (2019) explica
que é interessante posicionar-se atrás do usuário, local que oferece
visão completa das ações de navegação.

Criar um ambiente próximo ao do uso do aplicativo,

Figura 63-

como conversas e ruídos, pode medir o grau de satisfação

do participante

fizkes/Shutterstock
 227

Durante as anotações, é importante evidenciar os locais de alta

prioridade, em que o usuário não conseguiu continuar a navegação
ou em que ele acabou fazendo comparações com sistemas concor­
rentes. São termômetros que sugerem mudanças de atitude por
parte da equipe, pois são frustrações do usuário que determinam
a continuidade ou não de uso do sistema. As observações no bloco
de anotações devem ser realizadas no momento em que o usuário
verbaliza que está com dificuldades, pois são tantas informações que,
se isso ficar para depois, elas podem cair no esquecimento. Triste
é encontrar o erro depois de o sistema já estar implementado.
Após a finalização do teste, faz-se uma revisão em cada anotação
e verifica-se se os tempos foram anotados, aproveitando-se para
sanar as dúvidas com o usuário, pois pode ser que ele não tenha
mais oportunidade de conversar sobre o aplicativo. Esse relacio­
namento direto com o usuário é rico cm informações que podem
ser acrescentadas na documentação.
A quantidade de erros encontrados também é uma ótima métrica.
E o feedback quantitativo que pode alertar a equipe sobre o setor no
qual deve concentrar-se como prioridade. Lowdermilk (2019) cita
a importância de revisar as anotações ao mesmo tempo que o usuário
responde a um questionário com perguntas sobre o que achou de
participar do teste. E o momento, inclusive, de se preparar para
a próxima tarefa ou reinicializar o cronômetro.
O estudo terá sucesso somente a partir do momento em que
o roteiro for bem estruturado e as anotações forem feitas. E quando
a equipe de teste reúne a maior quantidade de informação possível,
o que garante o sucesso do aplicativo. Aqui, a relevância do teste de
usabilidade com o usuário é reconhecida como parte integrante do
228

projeto, e não algo que pode ser descartado. A análise de experiência

do usuário tem o mesmo nível de importância das outras etapas do
processo de desenvolvimento, pois sâo suas necessidades que são
verificadas e validadas. “Ter um roteiro claro, materiais impressos
e qualquer outra ferramenta pronta contribuirá para que seu estudo
transcorra de maneira eficiente”, destaca Lowdermilk (2019, p. 134).
Antes de aplicar o teste de usabilidade, recomenda-se realizar
um estudo para averiguar se a estrutura está adequada ao usuário,
orientando-se pelos seguintes passos:

• Fazer a revisão do conteúdo do roteiro - Deve-se observar toda

a parte gramatical e ortográfica, procurando por erros no cor­
retor do aplicativo que foi digitado. E importante um colega
ler e perguntar a ele se entende o que está escrito em termos de
concordâncias ou de idéias.
• Datas - Se no roteiro houver datas, deve-se verificar se estão
todas atualizadas para o dia em que as tarefas estão sendo efe­
tuadas ou, se o campo “data” estiver em aberto, verificar se não
está pequeno.
• Tarefas em ordem lógica - As tarefas que o usuário vai executar
obedecem a uma ordem lógica de navegação? Os passos estão
aleatórios ou são etapas que dependem uma da outra? Deve-se
atentar ao ritmo que será imposto ao teste de usabilidade, pois
o usuário vai seguir as etapas que lhe forem apresentadas.
• Praticar o estudo - Deve-se procurar seguir as ações que estão
no roteiro, fazendo pausas entre uma etapa e outra para analisar
se o usuário vai desempenhar aquela tarefa ou se está confuso.
Muitas vezes, é preciso sair da frente do computador, ater-se
 229

a outras atividades e observar se há algo que é preciso melhorar.

Muitas idéias nascem do distanciamento momentâneo para que
o cérebro receba um refrigério e os pensamentos sejam colocados
em ordem.
• Chamar um colega para analisar o roteiro - A estrutura do roteiro
deve obedecer aos critérios do requisito do usuário. Porém, no
momento de redigir, alguns conceitos podem estar sujeitos à visão
do técnico. Uma prática que ajuda a melhorar o entendimento
do documento é pedir para alguém de fora ler e testar o roteiro.
No desenvolvimento do roteiro, alguns detalhes podem passar
desapercebidos e sempre é importante ter outro olhar. Nesse caso,
tratar com um colega da equipe que tem pouco contato com
o projeto seria uma ótima forma de obter mais uma validação.

6.4 Organização dos resultados

Farrell (2017, tradução nossa) escreve, no artigo UX Research

Cheat Sheet, o que já ouviu em relação aos usuários:

"Quando devo fazer pesquisas com usuários no meu projeto?" Existem três respostas

diferentes:

• Pesquise usuários em qualquer estágio em que esteja agora. Quanto mais cedo

a pesquisa for realizada, maior o impacto que as descobertas terão sobre o seu

produto e, por definição, mais cedo você poderá fazer algo em seu projeto atual

(ausente uma máquina do tempo) hoje.

230

• Faça pesquisas com usuários em todas as etapas. [...] há algo útil para aprender

em cada estágio de qualquer plano de projeto razoável, e cada etapa da pesquisa

aumentará o valor do seu produto em mais do que o custo da pesquisa.

• Pesquise a maioria dos usuários no início do projeto (quando terá mais impac­

to), mas guarde algum orçamento para uma quantidade menor de pesquisa

suplementar posteriormente no projeto. Esse conselho se aplica no caso comum

de você não poder obter orçamento para todas as etapas de pesquisa que

seriam úteis.

Com base nos resultados do estudo com o usuário, é possível

analisar algumas informações antes de ir para a prática das correções.
A análise dever ser criteriosa para não incorrer em alterações que não
sejam de alta prioridade nem despender energia da equipe desneces­
sariamente. Conforme o andamento do projeto, muitas decisões são
tomadas e todas devem estar centradas no usuário.
Em 2019, uma empresa que fabrica bancadas para aulas de
física solicitou que novas ferramentas tecnológicas fossem im­
plementadas como diferencial, já que outras empresas também
trabalham com esse tipo de material pedagógico. Depois de sondar
algumas tecnologias, a realidade aumentada foi uma das opções
que se mostraram mais acessíveis.
Em posse de alguns experimentos, uma equipe de desenvolvi­
mento foi contratada para criar um modelo de gerador de Van der
Graaff em realidade aumentada. A primeira etapa foi entender como
funciona o gerador e como isso seria explicado para os estudantes.
Um técnico fez a montagem da bancada com todos os elemen­
tos, e a equipe de desenvolvimento analisou como seria a modelagem
em software 3D com animação.
 231

Conforme a modelagem foi sendo realizada, o feedback dos pro

fissionais na área foi solicitado para que o trabalho fosse desenvolví
do conforme o escopo do projeto. Na primeira etapa, a modelagem
de algumas peças acabou ficando com caraterísticas muito artificiais
segundo o apontamento na avaliação do usuário, o que exigiu uma
correção de imediato. Foram realizados vários experimentos e cada
um deles demandou uma montagem diferente na bancada. O propó
sito era que cada montagem seguisse o correspondente na realidade
aumentada. Farrell (2017, tradução nossa) sugere:

• Realize estudos de campo e entreviste os usuários: Vá para onde os usuários

estão, assista, pergunte e ouça. Observe as pessoas em contexto interagindo

com o sistema ou resolvendo os problemas para os quais você está tentando

fornecer soluções.

• Execute estudos diários para entender as necessidades de informação e os com­

portamentos de seus usuários.

• Entreviste as partes interessadas para reunir e entender os requisitos e restrições

de negócios.

• Entreviste a equipe de vendas, suporte e treinamento. Quais são os problemas

e perguntas mais frequentes que eles ouvem dos usuários? Quais são os piores

problemas que as pessoas têm? O que deixa as pessoas com raiva?

• Ouça as chamadas de vendas e suporte. Sobre o que as pessoas perguntam?

O que elas têm problemas para entender? Como a equipe de vendas e supor­

te explica e ajuda? Qual é a incompatibilidade de vocabulário entre usuários

e funcionários?

• Faça testes competitivos. Encontre os pontos fortes e fracos dos produtos de seus

concorrentes. Descubra o que os usuários mais gostam.

232

A bancada necessitava de detalhamento na montagem e, dessa

forma, foi constatado que algumas peças deveríam ser modeladas
conforme as características do experimento. Parafusos, porcas sex-
tavadas, peças de acrílico, todas precisavam ficar em locais corretos
para que a montagem não interferisse no experimento.
Depois de concluídos todos os experimentos, foi marcada uma
reunião com vários professores para que analisassem o experimento
na ótica da realidade aumentada. A análise foi feita com aponta­
mentos relacionados a outros experimentos, e um em especial foi
a inclusão de gráficos para apresentar a evolução do experimento.
Com o gráfico, aluno e professor conseguiram acompanhar no plano
cartesiano como ocorriam as alterações do experimento.
Alguns encontros foram agendados, porém a condução da aná­
lise foi informal. O clima descontraído favoreceu o surgimento de
vários apontamentos. Em momentos com maior formalidade, foram
tiradas fotos para documentar a navegação do usuário, e todos os re­
gistros foram armazenados para posterior consulta.
Outra forma de obter resultados é disponibilizar o sistema para
testadores beta. O aplicativo, já com todas as implementações, pode
ser analisado em seu ambiente de infraestrutura. Por exemplo, se
o sistema for feito por meio de pagamento mensal, pode-se dispo­
nibilizar um plano gratuito com todas as funcionalidades liberadas
para que sejam testados todos os recursos. E, como não está sendo
acompanhado de perto pela equipe, não há como agendar uma
análise de usabilidade. Então, criam-se ferramentas que analisam
o histórico de uso do sistema, com a data e hora de interação. Assim,
pode-se visualizar quem não está acessando e entrar em contato para
verificar por que não está acessando. Muitas vezes, as pessoas acham
 233

que está sendo feita a cobrança, o que é sinal de falta de clareza sobre
o plano gratuito, ou que a navegação é difícil. E aí que entram em
ação os questionamentos que fazem parte dos requisitos do usuário.
E uma oportunidade para obter informações dos usuários sobre
o sistema que nem sempre seguem os protocolos de agendamento
e feedback do usuário. De acordo com Lowdermilk (2019, p. 140),

É por isso que os estudos de usabilidade são o centro da metodologia de design

centrado no usuário - eles corrigem suposições por meio de observações sistemáticas

de usuários e pela coleta de seus feedbacks. No mundo do design centrado no usu­

ário, não seguimos somente a intuição. Acredito que, quando você começar a fazer

estudos de usabilidade, não só irá fortalecer os relacionamentos com os usuários, mas

poderá também ser um melhor programador. Você aprenderá o que funciona, o que

não funciona e, mais importante ainda, terá os dados em que se apoiar.

Farrell (2017, tradução nossa) incita a equipe a ter espírito

explorador:

Explorar

Os métodos de exploração são para entender o espaço do problema e o escopo do

projeto e atender às necessidades do usuário adequadamente.

• Compare os recursos com os concorrentes.

• Faça revisões de design.

• Use a pesquisa para criar personas de usuários e escrever histórias de usuários.

• Analise as tarefas do usuário para encontrar maneiras de economizar tempo

e esforço das pessoas.

• Mostre às partes interessadas a jornada do usuário e onde estão as áreas de risco

para a perda de clientes ao longo do caminho. Decida em conjunto como seria

uma jornada ideal para o usuário.

234

• Explore as possibilidades de design imaginando muitas abordagens diferentes,

fazendo brainstorming e testando as melhores idéias para identificar os melhores

componentes de design a serem mantidos.

• Obtenha feedback sobre os fluxos de tarefas em estágio inicial, percorrendo

os projetos com as partes interessadas e especialistas no assunto. Peça reações

e perguntas escritas (brainstorming silencioso), para evitar o pensamento do

grupo e permitir que as pessoas que não falam em um grupo lhe digam o que

as preocupa.

• Itere projetos testando protótipos em papel com usuários-alvo e, em seguida,

teste protótipos interativos observando pessoas usando-os. Não reúna opini­

ões. Em vez disso, observe como os projetos funcionam para ajudar as pessoas

a concluir tarefas e evitar erros. Deixe as pessoas mostrarem onde estão as áreas

problemáticas e depois redesenhe e teste novamente.

• Use a classificação de cartões para descobrir como as pessoas agrupam suas

informações, para ajudar a informar seu esquema de organização de navegação

e informação.

Para finalizar, cabe destacar as recomendações que devem ser

contínuas no processo de design centrado no usuário, segundo Farrell
(2017, tradução nossa, grifo do original):

• Preste atenção ao sentimento do usuário A mídia social é um ótimo local

para monitorar problemas, sucessos, frustrações e publicidade boca a boca do

usuário. Quando surgem concorrentes, as postagens nas redes sociais podem

ser a primeira indicação.

• Reduza a necessidade de treinamento. O treinamento geralmente é uma

solução alternativa para interfaces de usuário difíceis e é caro. Use os tópicos

de treinamento e ajuda para procurar áreas propensas a alterações no design.

 235

• Comunique direções futuras. Clientes e usuários dependem do que são ca­

pazes de fazer e do que sabem fazer com os produtos e serviços que usam.

A mudança pode ser boa, mesmo quando perturbadora, mas as mudanças

surpreendentes costumam ser mal recebidas porque podem quebrar coisas que

as pessoas já estão fazendo. Sempre que possível, pergunte, conte, teste e ouça

os clientes e usuários que você tem. Consulte-os em vez de apenas anunciar

alterações. Discuta as principais mudanças cedo, para que o que você ouvir possa

ajudá-lo a fazer um trabalho melhor e o que elas ouvirem possa ajudá-los a se

preparar para as mudanças necessárias.

• Recrute pessoas para pesquisas e testes futuros. Incentive ativamente as pes­

soas a se juntarem ao seu grupo de testadores voluntários. Ofereça incentivos

à participação e facilite a inscrição por meio do site, do boletim informativo e de

outros pontos de contato.

A experiência centrada no usuário veio para mostrar que seguir

num projeto sem analisar as reais necessidades que fazem um apli­
cativo ter sucesso significa ir em direção ao retrabalho ou descartar
meses de desenvolvimento. Ser meticuloso com os feedbacks do
usuário possibilita construir sistemas mais robustos e capazes de
atingir a maturidade rapidamente.
 237

A experiência do usuário relaciona diversos fatores anteriores

à execução do projeto e pressupõe conhecer mais o usuário dos
sistemas que serão desenvolvidos.
No Capítulo 1, vimos o que é design centrado no usuário desde
os primeiros passos dessa ciência até os nossos dias. O que acontece
quando o desenvolvimento do projeto deixa de lado o usuário e se
concentra somente nas tecnologias existentes é um produto que não
deixa uma experiência agradável para o usuário. As dúvidas, as frus­
trações e o abandono são mais comuns do que imaginamos cm se tra­
tando de desenvolvimento que não leva em consideração o usuário.
Muitos acabam entregando projetos centrados nas funcionalidades
que as novas tecnologias proporcionam, e não no que o usuário
gosta e no que sabe que dá resultado. Busca-se um sistema que
seja fácil de usar e, para isso, são necessários alguns procedimentos.
O contrário é destacar o layout, ou seja, considerar o aspecto gráfico
do sistema. Usar elementos de design que são atuais não se constitui
em garantia de aplicativo de sucesso. Para o usuário, até o fato de
ser bonito contribui, mas, se isso não ajuda na navegabilidade, deixa
de ser um ponto favorável. Há aqueles que acham que relatórios de
serviços de análise automatizada são suficientes para explicar por
que os usuários não passam da primeira página de um site. Aliado
a esses fatores, um outro grupo responde que é uma grande perda
de tempo estudar o comportamento do usuário diante das interfaces.
E como entender o usuário? No Capítulo 2, vimos que a equi­
pe deve trazer o usuário como participante ativo no processo de
desenvolvimento. Muitas perguntas que surgem durante a criação
são respondidas com a experiência do usuário. Este faz parte de
algumas categorias comentadas nesse capítulo, que o definem de
238

várias formas e mostram o jeito certo de abordá-lo. E como inserir

o usuário? Antes, deve-se adotar um dos métodos existentes de de­
senvolvimento de sistemas que preconizam os requisitos funcionais
e não funcionais como norteadores de um projeto, aliados aos re­
quisitos de usuário. Alguns métodos foram tratados nesse capítulo,
como a coleta dessas informações, porém sabemos que cada equipe
deve encontrar a que mais se encaixa em seu perfil, pois não há uma
metodologia correta.
A documentação para muitos é uma atividade chata e que pode­
ría resumir-se aos tutorials. Entretanto, no Capítulo 3, observamos
que documentar é acompanhar o desenvolvimento desde um rabisco
no papel de como será a navegação até os protótipos navegáveis,
passando pelos mockups e wireframes. São atividades que não preci­
sam ser custosas, mas são imprescindíveis, adiantando vários fatores
antes mesmo da implantação. E, para quem gosta de histórias, vimos
que é possível criar narrativas de como um usuário vai se comportar,
por exemplo, na compra de um produto por aplicativo e adotar até
mesmo nomes e perfis para esses consumidores, que chamamos de
personas. Essa pode ser a parte divertida da equipe, pois cenários,
fantasias e humor podem ser usados nesse momento. Quem sabe
há um artista escondido no rime?
Alguns recursos de outras áreas são utilizados no processo
de criação dos sistemas. No Capítulo 4, a Gestalt foi vista como
elemento construtor de interfaces, lermos como proximidade,
hierarquia e visibilidade colocam os gráficos dispostos de forma
organizada. Cores, fontes, ícones devem passar a ideia de consistên­
cia, para que o usuário se sinta no mesmo ambiente. Observamos
os benefícios que Jakob Nielsen deixou após seus estudos exaustivos
 239

sobre as heurísticas desde a década de 1990 e sua aplicação hoje na

experiência do usuário, examinando como o mundo real fornece
os modelos para que as equipes desenvolvam sistemas que façam
parte do ambiente do usuário.
E como analisar o comportamento do usuário se não se dispõe
de condições de abordá-lo ou acomodá-lo em salas de testes? Ou será
que realizar testes remotos vale a pena? Situações como essas foram
tratadas no Capítulo 5, desde a elaboração de questionários, pas­
sando pelo acompanhamento de testes, até o uso de procedimentos
para a criação de ambientes mais sofisticados de testes. Elaborar
um plano de teste exige tempo c dedicação. Por que não testá-lo?
E importante ver o usuário testando seus sistemas sem constrangê-lo
e fazer com que ele sinta parte de uma equipe, lembrando-se de
agradecer o empenho dispensado.
Por fim, no Capítulo 6, vimos que não há preocupação cm esta­
belecer um número grande de usuários para testar. Ter uma pessoa
que teste, desde que não seja da equipe, é melhor do que não fazê-lo.
Buscar amigos em redes sociais também vale, desde que se explique
qual é o propósito da entrevista e do teste. Gravação em vídeo, fotos,
áudio são meios simples que estão disponíveis e são poderosos para
registrar o comportamento do usuário. Também mostramos como
capturar e organizar os resultados para servir de apoio à construção
de sistemas de sucesso.
Nesta obra, explicamos o início do caminho da experiência do
usuário, que sempre contará com novos métodos inovadores que
ainda surgirão, pois, na área de tecnologia, uma vida é pouco para
conter todo o conhecimento que surge.
 241

BRASIL Lei n. 13.709, de 14 de agosto de 2018. Diário Oficial

da União, Poder Executivo, Brasília, DF, 15 ago. 2018.

Disponível em: <http://www.planalto.gov.br/ccivil_03/
_ato2015-2018/2018/lei/Ll 3709.htm>. Acesso em: 12 fev.
2021.
BUDIU, R. Usability Testing for Mobile Is Easy. Nielsen Norman
Group, 9 Feb. 2014. Disponível em: <https://www.nngroup.
com/articles/mobile-usability-testing/>. Acesso em: 12 fev.
2021.
CARROL, L. Alice no País das Maravilhas. Portugal: Casa das
Letras, 2011.
CATMULL, E.; WALLACE, A. Criatividade S.A.: superando
as forças invisíveis que ficam no caminho da verdadeira
inspiração. Tradução de Nivaldo Montingelli Jr. São Paulo:
Rocco, 2014.
FARRELL, S. UX Research Cheat Sheet. Nielsen Norman Group,
12 Feb. 2017. Disponível em: <https://www.nngroup.com/
articles/ux-research-cheat-sheet/>. Acesso em: 12 fev. 2021.
GOMES FILHO, J. Gestalt do objeto: sistema de leitura visual
da forma. São Paulo: Escrituras, 2006.
GRAHAM, I. A Pattern Language for Web Usability. São
Paulo: Pearson Education. 2003.
HISTORIA do Google: o jeito Google de trabalhar. Direção:
led Remerowski. Estados Unidos: National Geographic
Channel, 2010. 45 min.
242

INDIA: o buraco no muro. Direção: Rory O’Connor. India;

Estados Unidos: GlobalVision, 2002. 8 min.
LOWDERMILK, T. Design centrado no usuário. São Paulo:
Novatec, 2019.
MORAN, K.; PERNICE, K. Remote Moderated Usability
Tests: Why to Do Them. Nielsen Norman Group, 12 Apr.
2020. Disponível em: <https://www.nngroup.com/articles/
moderatcd-remote-usability-test-why/?lm=game-user-
research&pt=articlc>. Acesso em: 12 fev. 2021.
MOUSEFLOW. Disponível em: <http://www.mouscHow.com/
heatmap>. Acesso em: 11 fev. 2021.
NIELSEN, J. 10 Usability Heuristics for User Interface Design.
Nielsen Norman Group, 24 Apr. 1994. Disponível em:
<https://www.nngroup.com/articles/ten-usability-heuristics/>.
Acesso em: 11 fev. 2021.
NIELSEN, J. Games User Research: What’s Different?
Nielsen Norman Group, 20 Mar. 2016. Disponível em:
<https://www.nngroup.com/articles/game-user-research/>.
Acesso em: 11 fev. 2021.
NIELSEN, J. How Many Test Users in a Usability Study?
Nielsen Norman Group, 3 June 2012. Disponível em:
<https://www.nngroup.com/articles/how-many-test-users/>.
Acesso em: 11 fev. 2021.
NIELSEN, J.; LORANGER, H. Usabilidade na web: projetando
websites com qualidade. Tradução de Edson Furmankiewicz
e Carlos Schafranski. Rio de Janeiro: Elsevier, 2007.
 243

O’CONNOR, K. Personas: The Foundation of a Great User

Experience. UX Magazine, 25 Mar. 2011. Disponível em:
chttps://uxmag.com/articles/personas-the-foundation-of-
a-great-user-experience>. Acesso em: 11 fev. 2021.
PLATAFORMA CORAIS. Laboratório para teste de usabilidade.
Disponível em: <https://corais.org/node/219>. Acesso em:
11 fev. 2021.
PREECE, J. et al. Design de interação: além da interação
homem-computador. Porto Alegre: Bookman, 2013.
SURVEYMONKEY. O que é uma escala de Likert. Disponível
em: <https://pt.surveymonkcy.com/mp/likcrt-scale/>. Acesso
em: 11 fev. 2021.
SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho
na metade do tempo. São Paulo: LeYa, 2014.
TEIXEIRA, F. Introdução e boas práticas em UX design.

São Paulo: Casa do Código, 2014.

244
 245

Camila Freitas Sarmento é graduada (2011) em Tecnologia em

Telemática pelo Instituto Federal de Educação, Ciência e Tecnologia
da Paraíba (IFPB) e mestre (2016) em Ciência da Computação pela
Universidade Federal de Campina Grande (UFCG). Atualmente,
é analista de informática/programadora web no Instituto Senai de
Tecnologia em Automação Industrial (1ST) e também atua como
professora substituta no IFPB. Tem experiência na área da ciência
da computação, com ênfase em desenvolvimento zpcZ' e interação
homem-computador.

Cesar Ricardo Stati é designer formado pela Universidade

Tecnológica do Paraná (UTFPR) e pós-graduando em Processos
Inovadores de Ensino-Aprcndizagem do Serviço Social da Indústria
(Sesi) e do Serviço Nacional de Aprendizagem Industrial (Senai)
pelas Faculdades da Indústria. E professor no Senai na área de tec­
nologia da informação (TI), em web design, design thinking, testes
e projetos, bem como técnico de alunos participantes da WorldSkills,
competição mundial na área de educação profissional.
Os livros direcionados ao campo do design são diagramados com famílias tipográficas
históricas. Neste volume foram utilizadas a Garamond - criada pelo editor francês
Claude Garamond em 1530 c referencia no desenho de fontes pelos próximos
séculos -ca Frutiger - projetada cm 1976 pelo suíço Adrian Frutigcr para a
sinalização do aeroporto Charles de Gaulle, em Paris.