vamos fazer

Design de
Interaco?

Caio Cesar G. Oliveira

ilustrao e diagramao: estdio grampo

www.estudiogrampo.com.br

Vamos fazer
Design de Interao?
01 - O que Design de Interao?
02 - Verba pequena? Grandes solues!
03 - Estabelecendo metas
04 - Pesquisa com usurios
05 - A diferena entre anlise e validao
06 - Escolhendo metodologias
07 - Prottipos
08 - Validando layouts
09 - Testes com usurios
10 Monitoramento

1 - O que Design
de Interao?
As tecnologias digitais interativas esto fazendo parte de nossas vidas h tempos. Elas nos do poder, nos causam frustraes, nos aproximam e nos afastam; facilitam nossas tarefas
e, s vezes, proporcionam difculdades s nossas vidas. E,
mesmo interagindo com tecnologias digitais em nosso dia a
dia, com frequncia nos esquecemos que elas so feitas por
pessoas como ns. Pessoas que merecem elogios quando as
coisas funcionam e acabam recebendo insultos quando as
coisas simplesmente no funcionam.

Estas pessoas da mesma forma que os designers de produto

moldam nossas aes por meio de objetos que eles concebem
acabam por moldar nossas vidas no que se refere s relaes
que desenvolvemos e as atividades que desempenhamos por

meio das tecnologias digitais interativas. Elas so designers de

interao. O que elas fazem cuidar do desenvolvimento de
produtos interativos que fornecem suporte s nossas atividades cotidianas.
No passado, as pessoas que desenvolviam sistemas interativos tinham sua preocupao voltada primordialmente para
a tecnologia que tornava estes sistemas possveis e viveis. A
interface, que permite que as pessoas usem estes sistemas, era
uma questo secundria. S que um sistema no se completa
sem que as pessoas efetivamente consigam usar este sistema.
Nesse sentido, a reduo na qualidade de interao com os
novos produtos e servios tornou mais clara a necessidade
de se criar uma metodologia para avaliar e corrigir os problemas gerados por esse fenmeno. A Usabilidade e o Design de
Interao surgem como formas de se avaliar e conceber de
maneira objetiva, seguindo mtodos e estruturas a interao
entre pessoas, artefatos e instituies (levando-se em conta
cenrios e contextos) e sugerir solues para melhorar esse
processo. Desenvolvidas inicialmente a partir das teorias de
Fatores Humanos, Ergonomia, Psicologia e Engenharia Cognitiva, a Usabilidade e o Design de Interao se estabeleceram
como campos de estudo independentes, porm complementares, que, nos meados da dcada de 1980 e ampliam concomitantemente suas reas de infuncia.

Usabilidade o termo que defne o grau de facilidade de uso

de um produto ou servio. De acordo com Jakob Nielsen, a
usabilidade e a utilidade garantem a serventia de um produto.
Usabilidade de um produto foi tambm denominada como a
extenso pela qual um produto pode ser utilizado por usu-

rios especfcos, para alcanar objetivos especfcos de maneira efciente e satisfatria em determinado contexto de uso.
Uma defnio operacional do termo deve incluir um ou mais
dos quatro fatores:
1) Utilidade: est ligada ao nvel de infuncia de um produto
ou servio na concluso de uma ou mais tarefas realizadas
por usurios;
2) Facilidade de uso: normalmente defnida em termos
quantitativos, tanto por velocidade de uso quanto por ndice
de erros produzidos por uma porcentagem total da populao
de usurios;
3) Facilidade de aprendizado: est relacionada a capacidade
do usurio de aprender a utilizar um produto ou servio aps
um perodo determinado de tempo;
4) Satisfao: avaliada subjetivamente por usurios ao trmino da interao com um sistema ou servio.
Pensar nestes fatores tambm necessrio para que se produza sistemas interativos efcientes e satisfatrios. Dessa
formna, embora independentes, o Design de Interao e a
Usabilidade se relacionam intimamente. So conceitos que fazem parte de uma abordagem de design que leva em conta as
necessidades, limitaes e desejos dos usurios. A esta abordagem d-se o nome Design Centrado no Usurio. Conversar
sobre Design Centrado no Usurio algo que me deixa bastante empolgado. Mas deixarei uma abordagem mais aprofundada deste assunto para outra oportunidade.

De qualquer forma, como pode-se perceber, estes conceitos

no devem fcar presos apenas a sistemas e produtos digitais interativos. De acordo com Donald Norman, os mesmos

princpios apresentados em Design Centrado no Usurio para

artefatos complexos como instrumentao de aeronaves comerciais, usinas nucleares e sistemas computacionais podem
ser aplicados em objetos simples como portas, torneiras e
acendedores de luz.
A Usabilidade e o Design de Interao oferecem tcnicas,
mtodos e prticas que visam avaliar a facilidade de uso e a
utilidade de produtos sob a perspectiva do usurio. Fornecem
aos designers ferramentas para modifcar a maneira como os
produtos so projetados e concebidos; mtodos que operem
de fora para dentro, partindo das habilidades e necessidades
dos usurios fnais em direo eventual implementao do
produto.
Alm da preocupao com o ser humano que interage com os
produtos, a Usabilidade tambm fonte de reduo de gastos
para os desenvolvedores de produtos, assim como para os
usurios destes. Estudos mostram que a avaliao da Usabilidade desde as etapas iniciais do processo de desenvolvimento
dos produtos reduz o tempo desse desenvolvimento e resulta
em produtos mais adequados ao uso. J temos vrias pesquisas que comprovam a efcincia do envolvimento do usurio
no processo de produo. Esta efcincia demonstrada
principalmente pela quantidade de projetos que so fnalizados dentro do prazo proposto. Quando o usurio envolvido, o nmero aumenta notadamente. Produtos mais teis e
usveis reduzem os erros cometidos por seus usurios alm
de diminuir o tempo e a necessidade de treinamento.

Pra se ter uma ideia, pesquisa realizada em 1994 pelo Standish

Group, nos Estados Unidos, mostra que o envolvimento dos

usurios no processo de produo aumentou de 16% para 26%

o nmero de projetos que foram concludos dentro do prazo,
com a incluso de todas as funes especifcadas e dentro do
oramento previsto.
Falar em Design de Interao, ento, falar do processo de
concepo e desenvolvimento de produtos e servios interativos. Para se fazer isso, h diferentes vertentes e orientaes
metodolgicas. No h uma nica receita de bolo. Fazer Design de Interao no seguir um manual de instrues. No
entanto, quase todas estas vertentes metodolgicas so derivadas no Design Centrado no Usurio e se inspiram no Ciclo
Iterativo de Design, que consiste em estudar e sistematizar
as variveis, planejamento, design, teste e avaliao fnal em
relao aos requisitos.
Design Centrado no Usurio uma flosofa ou abordagem de
Design que acredita que os usurios reais e seus objetivos, e
no apenas a tecnologia envolvida, devem ser os elementos
norteadores de qualquer esforo para o desenvolvimento de
servios ou produtos. Os princpios do Design Centrado no
Usurio so: Foco em usurios e tarefas desde os momentos
iniciais do projeto; Medio e validao emprica; Iterao.

Pensamos, ento, em Design Centrado no Usurio por uma

questo muito simples: Ns, designers, temos uma viso de
mundo que nos permite entend-lo de um jeito diferente do
resto das pessoas. Em se tratando de nossos sistemas interativos (aqueles feitos por ns), o nosso entendimento bem
diferente do de nossos usurios. Isso porque temos modelos
mentais diferentes de nossos usurios. Ns, por causa de nossa experincia, envolvimento ou conhecimento sobre o pro-

jeto e o produto, conhecemos a coisa com mais profundidade

que os usurios. Nesse sentido, se fzermos as nossas solues
pensando apenas na nossa compreenso da coisa, corremos
srios riscos de desapontar os usurios.

Os usurios, portanto, tm modelos mentais diferentes dos

nossos (como dito, modelos mentais so representaes internalizadas, particulares a cada indivduo ou grupo de indivduos, sobre como as coisas so e devem funcionar). Como nossos modelos mentais e aqueles dos usurios so diferentes,
precisamos conhecer como o usurio se comporta e quais so
as suas demandas para depois de compreender seu modelo
mental, construir a nossa proposta para um sistema interativa. Esta proposta normalmente leva o nome de modelo conceitual e recebe infuncia de nossa interpretao das coisas
(nosso modelo mental) e a compreenso de como o usurio
interpreta o mundo ao seu redor (modelo mental dele).
E no que consiste este processo de concepo e desenvolvimento de produtos interativos? O ciclo Iterativo de Design
nos d boas pistas. Em suas fases, muitas atividades de Design de Interao acontecem.

Vamos pensar num website, por exemplo. Antecendendo

o projeto, voc tem pesquisa. E esta pesquisa vai consistir
em investigaes sobre os usurios (identifcao de perfs
e necessidades), pesquisas acerca da eventual soluo atual
existente e tambm investigaes de mercado (benchmarking
para identifcao de funes e diferenciais dos concorrentes
ou de outros produtos que servem ao mesmo propsito, mas
que no concorrem diretamente com o seu cliente (ou seu
produto)). Sobre esta investigao de perfs e necessidades de
usurios, falaremos com mais detalhes num futuro prximo.
Neste momento, importante termos em mente que estes
perfs e necessidades compem o que chamamos de Personas.
Estas Personas nos auxiliaro permanentemente em nosso
projeto.
Entrando propriamente na fase do projeto, as informaes

coletadas anteriormente se transformam em sua proposta,

que vai contemplar como voc imagina que acontecero as
interaes neste produto para que os usurios tenham suas
necessidades atendidas. Nesta etapa, fuxos de navegao so
construdos, mapas de contedo so desenhados e os primeiros prottipos comeam a nascer. Aqui acontecem alguns procedimentos de Arquitetura de Informao um conceito que
muitas vezes confundido com Design de Interao. Depois
de validados os primeiros prottipos, normalmente de baixa
fdelidade, o ciclo se repete para a construo de novos prottipos. Desta vez, de alta fdelidade.
Prottipos de baixa fdalidade

pgina inicial

pgina interna

Prottipos de baixa fdelidade recebem este nome pois representam com pouca fdelidade como ser o produto fnal. Sua
importncia est em representar a localizao dos contedos
e disparadores de ao em uma interface. Eles podem ser
em papel ou eletrnicos e normalmente recebem o nome de
Wireframes. O termo signifca linhas guia (como num projeto).

Ento, os Wireframes so prottipos de baixa fdelidade que

servem para dar um direcionamento inicial de como a interface ser. Como disse, estes prottipos podem ser feitos em
papel (impressos ou desenhados mo) ou digitais. As ferramentas so as mais variadas. Tem gente que usa at o PowerPoint (microsof.com) para fazer Wireframes. Pessoalmente,
uso o Gimp (gimp.org), mas sempre depois de fazer um ensaio
com papel e lpis. H aqueles que utilizam ferramentas como
o Pencil (pencil.evolus.vn) ou o Axure (axure.com) para fazer
Wireframes. Estas ferramentas so muito legais (se eu fosse
escolher, iria de Pencil) e servem para criar Wireframes navegveis.
Cada wireframe representaria uma tela ou um estado de ao
do site. Estes prottipos servem ento para dar uma plena
noo de tudo o que est acontecendo em cada atividade que
o usurio desempenhar no site. As telas se encaixam em
sequncias, formando os fuxos de navegao. Perceba ento
que para cada atividade que voc imaginou para o sistema, h
uma srie de fuxos e estes fuxos envolvem diversos wireframes (consequentemente, telas). Alm disso, estes fuxos e telas
proporcionam ao usurio navegar pelas sees do site. Verifcar se estas transies esto acontecendo da maneira mais
fcil e mais efciente possvel uma tarefa de Arquitetura de
Informao.

Alm de verifcar os fuxos, ratifcar o mapa do site uma

tarefa de Arquitetura de Informao. Voc pode fazer isso
a partir de uma explorao do eventual site atual que o seu
projeto substituir e tambm com o auxlio de procedimentos
com usurios.

O mais famoso destes procedimentos o Card Sorting. O termo explica bem o que feito no procedimento. Voc vai pedir
para usurios (que representem bem as personas encontradas
para espe projeto) organizarem o contedo do site em cartes
que voc previamente preparou escrevendo neles os nomes
das sees e pginas. O procedimento demanda um livro s
para ele, mas explicando rapidamente, ele proporciona a voc
entender como o usurio enxerga o contedo do site ou sistema.
Alm dos cartes com os nomes escritos, voc preparar cartes em branco e fornecer uma caneta para que os usurios
possam alterar nomes de cartes ou criar novos cartes. Cada
alterao ou criao feita deve ser justifcada. Pea aos usurios que, caso faam isso, justifquem isso por meio de um
pequeno texto escrito no carto. Isso poder ser til depois.
Alm de conceber, organizar e alterar cartes, os usurios
podero remover cartes excluindo-os ou colocando aqueles
que no entendem o que os rtulos signifcam numa espcie
de limbo.

10

Isso importante para voc ratifcar o entendimento do usurio dos rtulos imaginados para o site. Sobre o card sorting,

gostaria de fnalizar falando que muito legal que voc documente as sesses deste procedimento em vdeo, interfra o
mnimo possvel nas decises dos usurios e evite direcionar
a conversa. Deixe que eles se organizem. Uma ltima recomendao que voc tenha um nmero mpar de participantes por sesso. Tudo que voc no quer que no caso de
alguma disputa na sesso, acontea um empate.
Prottipos de alta fdalidade

pgina inicial

11

pgina interna

J os prottipos de alta fdelidade representam, como o nome

diz, como a interface ser com uma maior fdelidade. Normalmente os layouts so prottipos de alta fdelidade. Eles
comeam a ser produzidos depois que os wireframes so
fnalizados e validados. Ao fnal do processo de construo
dos layouts, voc ter uma representao bastante fel em
imagem de como ser cada pgina do site. Obviamente voc
no precisar fazer um layout para cada pgina do site. Num
sofware de edio e composio de imagens (novamente
recomendo o Gimp para este procedimento) voc far aquelas

imagens que representaro as pginas de algumas sequncias

/ fuxos apenas (mais ou menos como fez com os wireframes).
A validao de wireframes pode acontecer com procedimentos com usurios ou com avaliaes por especialistas. Esta
escolha vai depender de voc, da sua verba e do perfl de seu
projeto. J com layouts, numa abordagem bastante simples
(como ser visto a seguir) voc construir o bastante para
poder fazer testes e verifcar se a proposta pode ser validada.
Feito isso, tem-se incio a produo do cdigo para que o site
comece a existir como um sistema hipertextual.
Com o sistema comeando a tomar forma, o que temos um
prottipo funcional. J o site quase pronto, faltando normalmente contedo validado e ser disponibilizado para o
pblico geral. Ao caminharmos para o fnal desta etapa, o que
se recomenda que nova rodada de testes com usurios (ou
inspees por especialistas) seja conduzida.
Nunca tarde para fazer ajustes antes de fnalizar a produo
de um novo projeto. Neste momento, as etapas de Projeto e
Desenvolvimento comeam a se misturar. A parte mais pesada de concepo de cdigo tem incio. A partir deste momento, como disse, tem-se um site praticamente pronto. O contedo inicial do sistema comea a ser concebido e inserido no
sistema. As funcionalidades imaginadas so construdas no
front e back end. Em seguida, o site est pronto. O que resta
a tarefa de acompanhar o uso e fazer manuteno do contedo e sistema envolvidos.

12

Bem, voc deve ter percebido que passamos (ou iteranos) pelo
ciclo iterativo ao menos trs vezes. O principal benefcio de

se trabalhar Design de Interao sob a perspectiva do Design

Centrado no Usurio justamente este: depois de ter as ideias,
construir verses de seus designs (prottipos) e valid-las
junto a usurios ou por meio de inspees. O que descobrimos
nestes procedimentos de validao nos d mais segurana e
autoridade para ir para as prximas etapas.
Trabalhar Design de Interao basicamente isso. Fazer a insero de uma srie de procedimentos no processo de concepo de produtos interativos para que nossas solues sejam as
mais adequadas para suprir as necessidades dos usurios.
Voc deve ter visto que h uma srie de procedimentos apresentados nesta breve descrio. Espero conseguir desmistifc-los ao longo das prximas pginas deste livro. A seguir, trabalharemos a execuo destes procedimentos com oramentos
reduzidos. Voc perceber que trabalhar Design de Interao
(DI) no algo que encarece demais o projeto. E vale cada
minuto tentar adotar um procedimento.

13

2 - Verba pequena?
Grandes solues!
Ento voc tem pouca verba para o projeto?
Uma das principais difculdades que encontramos com Design de
Interao vender os procedimentos para nossos clientes ou mesmo para nossa equipe. Particularmente, eu acho que esta segunda
questo ainda mais desafadora.
Difculdade: vender DI.
Clientes > Difculdade mdia
Se voc desenvolve este expertise fca
conhecido por ele.
Equipe > Difculdade mdia ou alta
Difcil encontrar equipes dispostas a
iterar.
Em empresas > Difculdade alta
Salvo rarssimas excees, trata-se
de algo desconhecido e visto com
desconfana

muito raro e difcil encontrarmos equipes que estejam preparadas para iterar. Trata-se de um desafo e tanto.

14

Com relao aos clientes, o desafo um pouco menor. Eles podem

ter sido atrados a voc ou a sua empresa justamente por voc(s)
trabalhar(em) Design de Interao. Mas isso se aplica quando voc
faz parte de uma agncia ou produtora. A difculdade se mostra
ainda maior quando voc faz parte (ou voc o departamento) de
um departamento de design e/ou desenvolvimento de uma grande
empresa. Nesse sentido, o trabalho com DI algo realmente desa-

fador.
Mas nenhum destes desafos torna a coisa impossvel. Por proporcionar resultados muito bacanas para os projetos, uma vez que
voc demonstre que os mtodos e tcnicas de Design de Interao
funcionam, as coisas passam a fcar mais fceis.
Isso implica que, num primeiro momento, voc deve ter que trabalhar com uma verba e/ou um cronograma bastante reduzido.
Eu diria que na primeira vez que voc vai introduzir procedimentos
de DI em um projeto nas circunstncias que mencionei, voc vai
acbar tendo que lidar com verba e prazo zero. Isso mesmo. Voc
no ter nada a no ser sua vontade de fazer a coisa funcionar. Pra
piorar (como se voc tivesse escolhido jogar um game no modo
hard), tenho certeza que haver pessoas na equipe torcendo para
a coisa dar errado. brutal, eu sei. Mas infelizmente assim que
funciona. Graas s vezes s nossas prprias prticas. Mas isso
eu deixo para um outro momento.
Neste captulo veremos como podemos inserir procedimentos de
Design de Interao quase sem custos e quase sem impactos em
seu cronograma.

Voc no conseguir executar todos os

procedimentos de um mundo ideal. E da?
O importante ter resultados para comear a
criar uma cultura de DI na equipe e na empresa.

15

A primeira coisa a fazer ter a noo que voc no conseguir executar todos os procedimentos de um mundo ideal. Uma vez feito
isso, voc ter a capacidade de escolher um ou mais momentos que
considera chave no processo de desenvolvimento de uma soluo
e adotar um procedimento que vai proporcionar um resultado de

mais impacto.
O cenrio apresentado no razo para desespero. Mesmo tendo
que enfrentar o desafo de fazer a coisa funcionar com estas limitaes.
Por isso nunca demais ressaltar a importncia de se ter antes de
comear um mapa ou um roteiro de tudo o que ser feito no projeto. com este roteiro que voc vai identifcar quais so os pontos
crticos do projeto. Escolher inserir procedimentos de DI em um
desses pontos crticos, como disse, vai proporcionar resultados que
do mais impacto em seu projeto como um todo.

Antes de comear:
Tenha um mapa de tudo que ser feito no projeto.
Identifque os pontos crticos.
Escolha quais procedimentos sero inseridos nos pontos crticos.

Por exemplo, vamos pensar que seu projeto o redesign de um

produto ou um servio que no deu certo. Uma coisa importante a
se fazer antes de comear tentar compreender o motivo da verso
anterior no ter dado certo (inclusive compreendendo bem o que
signifca no dar certo).
Ser que foi por causa de um problema de interface? Ser que foi
alguma call to action mal posicionada (ou ausncia de uma call
to action?). Ou ser que foi porque o usurio que imaginaram para
o produto no comprou a ideia? Talvez a necessidade do usurio
seja outra. Talvez o usurio no tenha entendido que a sua necessidade seria contemplada com o produto.

16

Deu para perceber que muito importante saber em que cho estamos pisando antes de iniciar a caminhada, no ? Assim d para
escolher a estratgia mais adequada. Esta preparao fundamental e implica tambm em saber para quem voc far aquilo que est

fazendo. Isso signifca ter uma boa noo (ou pleno conhecimento,
o que melhor) de quem so as Personas para este projeto.
Sobre as Personas, legal deixar claro que isso ser trabalhado de
forma mais profunda na quarta parte deste livro. Mas de maneira
a proporcionar um bom entendimento da coisa neste momento,
importante saber que as Personas representam no s os diferentes
perfs de usurios que voc ter, mas tambm informam quais so
as necessidades destes usurios para com seu servio ou produto
interativo. O conceito de Personas extrapola o que entendemos
como perfl pois este conceito (o de perfl) costuma se restringir a
caractersticas demogrfcas. As Personas tm necessidades e comportamentos que precisam ser observados.
Para identifcar as personas-chave de seu projeto, um bom lugar
para olhar no caso de um redesign o cadastro atual de usurios. Quais so as suas caractersticas? Com os dados de cadastro,
podemos ter algumas dicas demogrfcas. No o sufciente, mas
ajuda. Olhar os relatrios de atividades no sistema anterior d uma
(ou vrias) dica(s) sobre o que estes usurios estavam procurando
em seu produto ou servio. Conversar com usurios seria o melhor
jeito de se obter dados mais completos sobre as caractersticas e
necessidades.
Mas vamos lembrar que voc no tem verba e nem tempo para
isso. Ento, o jeito sujo de fazer o procedimento neste momento
o mais adequado.

17

Tenha sempre em mente que voc precisa se esforar para ter

informaes sobre os usurios (suas caractersticas e necessidades).
Afnal, o que voc est fazendo Design Centrado no Usurio. Sem
as informaes nem que seja o mnimo sobre os usurios, voc
enfrentar problemas.
Para cada problema ou questo motivadora de um redesign men-

cionada, podemos aplicar procedimentos de DI no projeto em

momentos diferentes. Percebam como tentarei deixar isso claro a
seguir.
Se o problema da verso anterior do produto estava na interface,
seu foco deve ser o desenvolvimento da nova interface. D ateno
ao processo de criao de wireframes. Se voc tiver acesso a dados
que mostrem o motivo de a interface anterior no ter dado certo,
as coisas fcaro muito fceis. A voc conseguir estabelecer com
mais exatido quais sero as metas da nova interface.
Como dito, voc pode trabalhar a interface com procedimentos de
DI desde a concepo dos wireframes. Tente valid-los usando um
mtodo simples e barato chamado percurso cognitivo.
Este mtodo consiste em voc designer ou especialista atuar
perante a interface (ou seu prottipo) como se fosse uma das personas identifcadas para o projeto. Demanda maturidade e saber se
separar de seu modelo mental. Tente executar uma tarefa do produto interativo como se voc fosse o seu usurio. Tente agir como
se voc tivesse a necessidade que ele tem e como se voc tivesse o
repertrio que ele tem.
Passe pelas telas e preste ateno no que elas informam a este usurio que tem as caractersticas e necessidades bem defnidas. No
fcil e talvez voc no consiga os melhores resultados na primeira tentativa. Mas este um procedimento muito barato e rpido.
Alm disso ele permite descobrir problemas graves quando feito
corretamente.

18

Percurso cognitivo?
Rpido e barato (relativamente simples).
Demanda maturidade e descolamento
do seu modelo mental.

#comofas
Escolha uma tarefa no sistema.
Tente execut-la como se voc fosse a persona em questo.
Pode ser feito em qualquer etapa do processo de produo.
Quando feito corretamente, permite descobrir
problemas com muita efcincia.
Se o percurso cognitivo no a sua praia, voc pode tentar validar
os wireframes adotando uma anlise heurstica. Trata-se de outro
procedimento bastante rpido e barato e que no necessariamente
envolve usurios (como voc est com prazo e verba restritos, preste ateno nisso).

19

Conduzir uma anlise heurstica algo bastante rpido. Dada uma

tarefa (sempre, pense numa tarefa. Tanto na anlise heurstica
quanto no percurso cognitivo e em qualquer outro procedimento),
passe pelas telas observando a lista de heursticas (recomendaes
/ boas prticas) e verifque o que est e o que no est sendo contemplado. Alm disso, para as coisas que no esto sendo contempladas, procure indicar qual o impacto deste problema no projeto.
Isso pode ajudar a focar as foras para a resoluo de problemas
mais graves. Voc deve estar se perguntando de onde vm estas
listas de recomendaes, n?

Anlise Heurstica?
Simples, rpido e barato. No necessariamente envolve usurios.
Alguns erros podem passar.

#comofas
A partir de uma lista de heursticas, preencha um formulrio /relatrio indicando quais delas so e no so contempladas.
Quando no contempladas, indique a gravidade do
problema e o impacto.
Em etapas mais avanadas do processo, geram
melhores resultados.
Voc pode conceber uma lista de heursticas (a partir de metas
especifcadas para o projeto) ou usar heursticas j prontas.
O Jakob Nielsen tem um trabalho muito bacana j consolidado
sobre heursticas. Voc pode pegar as heursticas para sistemas
interativos feitas por ele e adaptar s suas necessidades. Alm disso, as metas traadas para a interface do uma dica das heursticas
a seguir para conduzir a validao.
Outra fonte bacana o trabalho da Claudia Dias, que fltrou estas
heursitcas para a realidade de portais corporativos. Alm destes,
h vrios outros autores que trabalharam a construo de heursticas para diferentes realidades de projetos. Vale dar uma olhada e
conduzir uma anlise heurstica nos wireframes.

20

E pense que voc pode conduzir estes dois procedimentos em

sequncia ou isoladamente. Voc pode fazer uma anlise heurs-

tica na fase de fnalizao de wireframes e conduzir um percurso

cognitivo quando os layouts estiverem prontos. Voc pode repetir
os procedimentos quando o prottipo funcional estiver pronto para
ver se houve algum ganho efetivo ou se algum erro ainda persiste.
Como disse, so procedimentos rpidos e baratos. Voc consegue
conduz-los em uma tarde. Os resultados sempre traro benefcios
ao projeto.
Se o problema no foi na interface em si, mas sim no entendimento
do usurio acerca do produto, saber de suas necessidades e caractersticas proporcionar o conhecimento necessrio para voc
corrigir isso. Talvez melhorando o texto, cores, desolcando botes...
Tambm recomendado dar uma olhada nos produtos concorrentes (especialmente os que so lderes) para ver o que h neles
que voc no fez em seu projeto. Talvez al esteja a resposta para o
entendimento do usurio. Procure investigar quais so os nomes de
sees e os rtulos usados nos sistemas concorrentes. Se eles tm
sucesso, os motivos podem estar ali.
Envolver os usurios no necessariamente proibido num contexto de pouca verba ou cronograma apertado. Nada impede que
voc promova testes remotos em ferramentas como o GoToMeting
(gotomeeting.com), use o CrazyEgg (crazyegg.com) para monitorar o que usrios remotos esto fazendo em sua interface (mesmo
que em teste), ou use o FiveSecondTest (fvesecondtest.com) para
rpidos feedbacks com usurios acerca daquilo que voc est construindo. Sem mencionar que tudo isso que acabei de falar tambm
pode ser feito via Google Hangouts (plus.google.com) sem qualquer
custo.

21

Todos estes servios tm pacotes gratuitos e o que voc precisa

para faz-los funcionar ter algum do outro lado para testar o que
voc quiser verifcar. Se voc tiver acesso a pessoas que possam colaborar com isso de maneira rpida e gratuita, um bom caminho a

seguir tambm.
Verifque se os procedimentos remotos se adequam ao projeto.
Como? A partir das respostas que sero obtidas!

Alm de procedimentos de validao, investigaes e descobertas

tambm podem ser feitos com ferramentas online. OptimalSort
(optimalworkshop.com/optimalsort) e WebSort (websort.net) so
ferramentas que permitem conduzir procedimentos de card sorting
remotamente. Isso proporciona economia de dinheiro (voc no
gasta com transporte, sala, lanchinho, recompensas) e tempo (cada
participante pode fazer o procedimento isoladamente e depois voc
verifca como as respostas se encaixam, entendendo o que seria a
deciso de uma maioria.
Claro que os procedimentos feitos remotamente no necessariamente se encaixam em todos os projetos, mas saber que eles existem de grande ajuda.
E voltando a nossa questo principal, voc pode obter bons resultados conduzindo procedimentos simples, rpidos e baratos em seu
projeto. Certamente fazer uma avaliao heurstica no vai proporcionar atrasos em seu cronograma. Mesmo que voc descubra
problemas. Fazer o procedimento no momento em que as primeiras
verses dos prottipos fcam prontas no proporcionar atrasos. E
o ganho pode ser muito grande.
Finalizando, aps voc inserir estes procedimentos em seu projeto,
basta mostrar os resultados.

22

Voc perceber que a guarda baixar um pouco e no prximo

projeto voc ter um pouco mais de espao e quem sabe verba.
Com o tempo, sem perceber, sua equipe estar trabalhando Design de Interao e voc poder falar com todas as letras para seus
clientes que seus projetos so feitos pensando-se no usurio.

3 - Estabelecendo
metas!

Como nos procedimentos de Design de Interao estamos lidando o tempo todo com validaes e avaliaes, as metas so muito
importantes. Sem elas, no saberamos onde chegar e nem com o
que comparar os resultados que encontramos. Ficar comparando
nossos achados em testes e avaliaes de nossos produtos apenas
com produtos de terceiros pode no ser muito produtivo.

23

Para colocar esta questo de melhor maneira, uma argumentao

bsica: Resolver um problema dos usurios com menos cliques ou
em menor tempo do que o concorrente pode ser bom, mas no necessariamente signifca que estamos fazendo o que de melhor pode
ser feito.

Alm disso, conduzir os procedimentos e tocar um projeto de

produto interativo sem ter metas a cumprir beira o nonsense (alm
de ser um tanto quanto montono). E olha que nem mencionamos
o mais importante: as metas so primordiais para quantifcarmos
os nossos resultados e verifcarmos se efetivamente conseguimos
concretizar tudo o que foi proposto. Por fm, verifcar se as metas
foram cumpridas imprescindvel para calcularmos o eventual
Retorno do Investimento (ROI) feito em procedimentos de Design
de Interao.
Mas, como estabelecer as metas?
No ciclo iterativo temos logo no comeo das atividades a identifcao de necessidades de usurios e estabelecimento de requisitos
do sistema (justamente para contemplar estas necessidades). As
metas tm relao ntima com estes requisitos.

Uma pista pode ser obtida retomando a relao que o Design de

Interao tem com a Usabilidade.
Podemos, por exemplo, ter metas quantifcveis em termos de:

24

Utilidade
Como este quesito se relaciona a capacidade de o usurio conseguir concluir uma tarefa, metas de utilidade vo desde o simples o

usurio deve ser capaz de conseguir concluir a tarefa at especifcaes mais complexas como o usurio deve ser capaz de conseguir concluir a tarefa em X cliques ou o usurio deve ser capaz de
conseguir concluir a tarefa em X minutos ou ainda o usurio deve
ser capaz de conseguir concluir a tarefa passando por X telas tanto
de forma isolada quanto de forma combinada.
Facilidade de uso
Novamente um quesito que pode se relacionar com tempo ou outra
varivel para mensurao e validao. Por exemplo, podemos estabelecer a meta de que o usurio deve ser capaz de compreender
determinada mensagem em X segundos. Outra maneira de verifcar isso acompanhar o uso em um procedimento com usurio e
observar se o usurio comete erros ou se mostra confuso em algum
momento. Depois do procedimento de execuo da tarefa ser fnalizado, uma entrevista ou questionrio ratifca os achados.
Facilidade de aprendizado
A prpria defnio deste quesito em usabilidade remete a capacidade de o usurio se lembrar como algo executado em um sistema interativo depois de usar. A validao deste ponto pode ser
feita depois que o usurio exposto ao sistema por meio de uma
nova exposio (passado determinado tempo) ou ainda por meio de
questionrio ou entrevistas.

25

Satisfao
Satisfao um quesito extremamente subjetivo, no acha? Aquilo que me deixa satisfeito no necessariamente vai deixar outras
pessoas satisfeitas tambm. Mas isso no um problema do quesito, mas sim uma questo de direcionamento de sua pesquisa. De
qualquer forma, possvel verifcar satisfao por meio de entrevistas e questionrios da mesma maneira que se faz em pesquisas
de mercado. Uma maneira menos direta de se verifcar satisfao
observar o que se repercute do sistema interativo em questo

Acompanhar as avaliaes de um aplicativo, por exemplo, pode ser

uma boa. Outra coisa a fazer monitorar o que se fala do sistema
nas mdias sociais e tambm verifcar as questes que chegam at a
empresa por meio de um eventual canal de contato. No entanto, na
fase de desenvolvimento, questionrios, entrevistas e grupos focais
so excelentes para verifcar satisfao.
Alm disso, podemos trabalhar tambm metas relacionadas a preveno de erros. Neste caso, podemos estabelecer que uma meta
pode ser a de que o sistema deve ser capaz de explicar a situao
para o usurio quando ele est prestes a cometer um erro e este
usurio deve ento tomar uma deciso. Em um teste, devemos
pensar numa tarefa que um procedimento de erro pode ser facilmente detectado e ento acompanhamos as reaes do usurio
frente as respostas do sistema. Se o sistema conseguir impedir o
usurio de cometer o erro, a meta foi alcanada.
No entanto, nem sempre conseguimos prever isso com exatido.
Mais difcil ainda planejar um teste que contemple isso em uma
de suas tarefas. Mesmo assim, possvel verifcar se metas de
aprendizado so contempladas com questionrios posteriores a
conduo do teste, da mesma forma que relatado no que se refere a
avaliao de satisfao (que um tanto quanto subjetiva).
Metas de Design de Interao podem ser verifcadas a partir de
anlise de logs de acesso, realizao de testes com usurios (presenciais ou remotos), entrevistas ou questionrios. Fica implcito,
ento, que bem provvel que voc tenha que fazer testes com
usurios para verifcar se as metas esto sendo contempladas.

26

Mas cuidado. A realizao de procedimentos com usurios

recomendada, no obrigatria. Voc pode verifcar metas utilizando de metodologias j conhecidas como o percurso cognitivo e a
avaliao heurstica. No entanto, estes procedimentos no necessariamente lhe fornecero todos os dados da maneira mais completa

possvel para verifcao do status de uma determinada meta.

De qualquer forma bom ter em mente que as metas servem para
que norteemos a nossa produo. O ciclo iterativo de design mostra que devemos parar de iterar (ou seja, dar voltas no ciclo) em
duas circunstncias: 1) quando as metas com relao quele ponto
do projeto so contempladas e/ou; 2) quando o tempo do projeto
demanda esta parada e precisamos seguir adiante.
Outra coisa muito importante sobre as metas se refere a sua aplicao. No precisamos estabelecer metas relacionadas a todos os
quesitos para todos os momentos do desenvolvimento. Podemos
escolher quesitos e concentrar metas de apenas alguns deles em
nossas avaliaes. E estas metas podem ser aplicadas a diferentes
momentos do desenvolvimento, sendo mais comum que as validemos em etapas mais avanadas do desenvolvimento (novamente,
no obrigatoriamente assim. Afnal, Design de Interao no uma
cincia exata).
Dessa forma, ao iniciarmos o processo de desenvolvimento e
estabelecermos onde realizaremos validaes e anlises, muito
importante que tambm acertemos as metas para estes procedimentos de validao e anlise. Assim, quando chegar o momento
de fazer algum procedimento, saberemos o que ser um desempenho aceitvel, no aceitvel e excelente.

27

4 - Descobrindo perfs
e necessidades dos usurios

Quando estamos falando de Design de Interao e Design Centrado no Usurio, temos como vocs j sabem o usurio no centro
do processo. a partir da identifcao de suas caractersticas e
necessidades que vamos projetar nossos produtos interativos.
Recuperando o que j foi falado anteriormente, fazemos isso pois
ns, designers, pensamos o mundo de uma maneira diferente de
nossos usurios. Esta premissa verdadeira para 99% dos casos. A
exceo aquele raro projeto que fazemos para pessoas que pensam como ns. No restante das vezes, somos pessoas externas
realidade de nossos usurios, que a partir de um conjunto limitado de informaes e experincia restrita com a realidade deles
(usurios) construmos algo para eles.

28

como um trabalho de consultoria. O grande benefcio que temos um olhar externo, o que proporciona uma viso diferente dos
problemas que as pessoas enfrentam. Um olhar novo. Isso pode ser

muito bacana. No entanto, tambm o ponto fraco. Ns, alm de

termos um repertrio diferente do usurio, normalmente lidamos
com informaes limitadas sobre sua realidade.
Nesse sentido, muito importante levar bem a srio a pesquisa
com usurios para que minimizemos os eventuais erros de nossos projetos. Se sabemos exatamente como so e do que precisam
os usurios, as coisas fcam mais fceis e os nossos acertos, mais
frequentes. Afnal, mais do que necessrio construir modelos
conceituais de produtos que tragam o frescor e a viso diferente para solucionar um problema que o designer traz e ao mesmo
tempo no se afasta da concepo de mundo daqueles que usaro
o produto a ser desenvolvido.
Um exemplo bem bacana da importncia de se conhecer as caractersticas dos usurios e de se compreender suas necessidades
pode ser visto no vdeo The Deep Dive, que mostra o processo de
concepo de uma soluo por parte da IDEO conceituada empresa de design. No vdeo (youtube.com/watch?v=oRrrSMZN85w)
a empresa desafada a fornecer uma nova soluo para um problema velho: o carrinho de supermercado. Uma coisa muito importante que a empresa faz logo no incio do processo de concepo do
produto investigar os usurios. Eles se dividem em equipes que
passam o dia observando e conversando com as pessoas que usam
o produto a fm de descobrir quais so os problemas enfrentados e
as necessidades especfcas relacionadas ao carrinho de compras.

29

Em essncia, isso que precisamos fazer. Observar e conversar

com os usurios para entend-los bem. Alguns chamam isso de
pesquisa etnogrfca. No entanto, mesmo embora eu j tenha at
usado este termo no passado, tomo emprestada a cautela que vi
o pessoal de uma fnada empresa de Arquitetura de Informao
chamada Mapa Digital e evito me referenciar a este procedimento
como pesquisa etnogrfca. No porque eu no sou cientista social.
Nada disso. Evito usar o termo porque pesquisa etnogrfca algo

que demanda muito mais tempo. Pense na pesquisa que os irmos

Vilas-Boas fzeram com os ndios brasileiros. Aquela pesquisa
durou anos. E este um tempo que no temos para nossos projetos.
Nesse sentido, embora a essncia seja a mesma, prefro me referir a
este tipo de pesquisa simplesmente como pesquisa com usurios.
E, antes que eu me esquea, vale ressaltar que este tipo de observao deve ser contnua por parte do designer. Uma coisa que eu
aprendi que nunca demais prestar ateno em tudo. Sempre.
Observar continuamente como as pessoas usam as coisas, como
as coisas fcam depois que as pessoas as usam (para vocs terem
uma ideia, isso j est to inserido no meu comportamento que me
pego observando as marcas deixadas pelas mos das pessoas em
elevadores, portas, teclados...). Se prestarmos ateno nestas coisas,
estaremos sempre um passo adiante na hora de fazermos as pesquisas com usurios.
Pois bem. Fazemos pesquisas com usurios para descobrir quais
so as suas caractersticas, em que circunstncias usaro aquilo
que estamos projetando e quais so as necessidades especfcas
relacionadas a estes produtos.

{
30

Os usurios so pessoas muito inteligentes, porm muito

ocupadas. Eles, como qualquer pessoa, no tem tempo para fcar
lendo manuais e estudando o funcionamento de um sistema.

Alan Cooper

A primeira coisa a fazer parar de termos preconceitos com os

usurios. Os usurios so o que so. Algo muito legal que o Alan
Cooper fala que os usurios so pessoas muito inteligentes, porm muito ocupadas. Esta fala legal pois resume e explica duas
coisas. A primeira a de que eles so pessoas plenamente capazes.
No devemos tratar os usurios como cidados de segunda classe.
Lembre-se que eles tm apenas concepes de mundo diferentes

das nossas. Alm do mais, ns que devemos ser especialistas em

design. Eles so especialistas naquilo que fazem. A segunda coisa
que eles, como qualquer pessoa, no tm tempo para fcar lendo
manuais e estudando o funcionamento de um site ou sistema para
fazer o resgate de pontos num programa de fdelidade, por exemplo.
Isso apenas refora a premissa de que devemos conceber as coisas
de forma que demandem o mnimo possvel de esforo dos usurios para que eles efetivamente as usem. Se vocs olharem bem, era
esta a premissa seguida por Steve Jobs no comando da Apple. Seu
modo de enxergar as coisas direcionava a produo de produtos
extremamente simples e elegantes, que ningum precisa pensar
muito para usar.
Agora que estamos tentando nos despir dos preconceitos, vamos
a mais um deles: no ache que voc conhece o usurio. Por mais
que voc pense isso, sempre necessrio pesquisar sobre ele. Um
dos maiores e mais frequentes erros que cometemos termos em
mente que conhecemos os nossos usurios. Pensar assim receita
para fracassar em um projeto.
Uma coisa que deve fcar clara que fazer pesquisa com usurios
algo essencialmente qualitativo. Embora seja possvel ter pistas
de perfs e caractersticas de usurios com pesquisas quantitativas,
para resolver os problemas de design (o que demanda saber sobre
comportamentos, circunstncias e particularidades de uso), uma
pesquisa quantitativa d apenas pistas sobre isso.

31

Sei que falei anteriormente que voc pode usar de dados secundrios (cadastros de usurios num site, por exemplo) para ajudar
a construir este conjunto de informaes sobre os usurios. Isso
bastante til. Mas no representa a totalidade do que necessrio.
Como disse, muito bom para dar pistas.

Com minha formao, tambm sei que muito comum fazermos

pesquisas de mercado e construir perfs psicogrfcos de consumidores. Isso tudo muito bacana e muito til. Mas no para
desenvolvermos produtos. Perfs psicogrfcos, para quem no
sabe, so os perfs de consumidores construdos a partir de informaes demogrfcas e de informaes sobre comportamento dos
consumidores. Embora isso seja muito importante em pesquisas
de mercado, insufciente caso nossos objetivos incluam construir
sistemas interativos para estas pessoas realizarem tarefas.
Precisamos de algo mais, informaes peculiares de cada usurio
que no podem ser obtidas atravs de um questionrio. preciso
conversar com eles, observ-los e obter informaes variadas sobre
tudo o que envolve o usurio e o contexto do uso daquilo que estamos tentando desenvolver.
Novamente recorro s cincias sociais e cito Alan Cooper para fundamentar esta posio:

{
32

Os cientistas sociais h muito perceberam que os

comportamentos humanos so muito complexos e sujeitos a
muitas variveis, o que torna invivel depender exclusivamente
dos dados quantitativos para compreend-los.

Alan Cooper

Isso no quer dizer, no entanto, que voc vai abandonar completamente os dados quantitativos. Esta apenas uma abordagem de se
conduzir a coisa. Como disse vrias vezes, Design de Interao no
se faz seguindo uma receita. Sei de gente que constri personas a
partir de questionrios, exclusivamente. Pessoalmente no gosto
desta abordagem pois tenho experincia o sufciente com pesquisa
quantitativa para saber que para se construir um questionrio confvel leva-se s vezes muito mais tempo do que o necessrio para
ir a campo e conversar com os usurios.
Ento vamos colocar as nossas mos e cabeas para trabalhar.

Como disse, as pesquisas quantitativas no devem ser jogadas

fora. Uma olhadela nos cadastros de usurios por exemplo, d o
caminho a seguir. A partir destes dados voc saber onde esto os
usurios.
A pode ir at eles para observar:
Comportamentos, atitudes, aptides;
O contexto de negcio, tcnico e ambiental onde ocorrem as interaes (uso daquilo que voc vai fazer);
Vocabulrio especfco e outros aspectos culturais que envolvem a
comunidade e o uso daquilo que est sendo projetado;
Como os produtos que atendem as pessoas hoje so usados (caso o
produto a ser desenvolvido no seja um redesign, este o caminho
a seguir. Faa tudo o que est sendo falado aqui tendo em mente
que voc vai observar os usurios dos produtos existentes).
E quando digo observar exatamente isso que recomendo que
faa. Olhe as pessoas usando os produtos. Preste ateno nelas e
pergunte o que precisar perguntar. Formalidade costuma atrapalhar muito neste momento (alm de deixar o usurio acanhado,
trava o processo de obteno de informaes).
Obviamente h circunstncias especiais que impedem que voc
faa as observaes no contexto real de uso, mas tente chegar o
mais prximo disso. Quando no der, pacincia, chame os usurios
para o seu ambiente e converse com ele ali. Tenha em mente no
entanto que o mais legal sempre estar no ambiente do usurio.

33

Novamente isso pode ser feito dependendo das circunstncias

distncia. Google Hangouts e GoToMeeting so boas ferramentas
para isso. Compartilhamento de telas pode fornecer muitas informaes bacanas sobre o uso. Mas tenha em mente novamente que
estas ferramentas tm limitaes.
Com estas observaes, a equipe de design ser capaz de ter uma

base comum para tomada de decises (especialmente se mais gente

participar destas observaes). Alm disso, ser possvel descobrir
como o produto se encaixa no contexto mais amplo da vida das
pessoas, quais objetivos motivam as pessoas a utilizar o produto, e
quais as tarefas bsicas ajudar pessoas atingir esses objetivos. Por
meio de observaes e entrevistas tambm possvel descobrir
quais so as experincias que as pessoas acham atraentes e como
elas se relacionam com o produto que est sendo projetado. Principalmente, observar as pessoas usando o produto ou servio em
questo permite descobrir os problemas que as pessoas se deparam
com as suas atuais formas de fazer as coisas.
Documente estas observaes da melhor maneira possvel. Vdeo,
udio, fotos, texto... O que te ajudar melhor. Lembre-se sempre de
pedir autorizao para os usurios e de deixar claro para eles o que
ser feito com o material coletado.
Este tipo de pesquisa (observao) a mais comum e costuma
fornecer muitas informaes. Alm dela, h as entrevistas com os
usurios (que podem ou no ser realizadas em conjunto da observao do uso) feitas individualmente ou em grupo (grupos focais)
e investigao de produtos semelhantes ou concorrentes.
Pessoalmente, gosto muito de grupos focais. Eles permitem descobrir muita coisa, embora precisem ser realizados fora do ambiente
de uso do produto e por isso normalmente no incluem investigaes sobre o uso em si. Por outro lado, o fato de os usurios estarem
ali disposio para conversar entre si e com voc sobre o produto
algo fantstico. Costuma-se tirar bom proveito de entrevistas e
grupos focais nos extremos (incio e fm) do processo de produo
de uma soluo.

34

Estes tipos de pesquisa permitem conhecer bem os usurios ao

ponto de sermos capazes de classifc-los. Esta classifcao gera
as personas. Voc cria personagens que representam os diferentes

eventuais pblicos de seu produto que renem caractersticas e

necessidades de diferentes usurios.
Estas personagens ganham fchas (como as que fazemos em jogos
de RPG) com suas caractersticas, necessidades, comportamentos,
hbitos... Usamos estas fchas para conduzir avaliaes por meio
do percurso cognitivo, por exemplo. Ou seja: as personas podem
(e devem) nos acompanhar at a fnalizao do projeto. Caso voc
agende testes com usurios ao longo do projeto, so as personas
que guiaro quais os tipos de usurios recrutar. Ou seja: no d
para fugir das personas.
Cada projeto vai demandar uma quantidade de personas especfca.
Mas temos que ter em mente que uma delas ser a mais importante e representar o principal pblico do seu produto. H ainda
autores como Louis Rosenfeld e Peter Morville que argumentam
que voc no deve ter mais do que cinco personas para um projeto,
sendo que o foco ser maior em uma delas e outras duas tero peso
menor. As restantes teriam peso quase insignifcante. No entanto,
isso vai depender de voc.
O que mais do que recomendvel guardar que esta investigao
sobre os usurios imprescindvel. E que voc deve reunir informaes relevantes sobre o contexto de uso, as caractersticas e
demandas destes usurios para poder ter os subsdios necessrios
para elaborar boas propostas de design.

35

36

5 - Anlise
ou validao?

Quando falamos em procedimentos de Design de Interao, muita

gente se perde quando o assunto anlise e validao. E a cria-se
uma dicotomia desnecessria entre eles. Como se s fosse permitido adotar um tipo ou outro. Normalmente quando me perguntam
isso, respondo: Por qu no ambos?
Afnal, no h mandamentos sagrados que impeam uma equipe
de desenvolvimento fazer diferentes procedimentos com diferentes
abordagens.

37

Imagino que a esta altura voc deve estar se perguntando qual a

diferena entre os dois tipos de procedimento. Pois ento... Trataremos deste tema agora.
Os procedimentos de Usabilidade so rapidamente falando

divididos em dois tipos: Empricos e Analticos. Obviamente, como

veremos a seguir, as coisas no so to preto ou branco assim. Mas
o esforo de classifcao ainda vale.
Os procedimentos empricos so aqueles que demandam ensaios e
testes. Normalmente (mas no obrigatoriamente) envolvem usurios. Tanto que isso chega a ser sinnimo. Tem muita gente que
encara como empricos apenas os procedimentos que envolvem
usurios. uma maneira fcil de classifcar e entender a diferena.
Por outro lado, os procedimentos analticos no costumam envolver usurios (novamente, isso no obrigatrio).
Um exemplo de procedimento analtico a Anlise Heurstica.
Neste procedimento, um especialista passa pelo sistema fazendo
uma validao deste sistema perante uma lista de recomendaes
(as heursticas).

Um exemplo de procedimento emprico a realizao de testes

com usurios. Nestes procedimentos, o usurio realiza uma tarefa
no sistema sendo acompanhado por especialistas que documentam
esta interao para posterior avaliao.

38

No entanto, o que impede que voc convoque usurios para fazer

conjuntamente uma avaliao heurstica? Dessa forma, percebemos que a escolha de abordagens no como a escolha do time
para o qual voc vai torcer. algo mais fuido e menos defnitivo.
O que importa (sempre) que tipo de descoberta ser feita e o que
poder-se- fazer com elas. Ter isso em mente antes de decidir quais
testes fazer fundamental para que esta escolha no seja prejudicada.
E como disse, nada impede que voc misture abordagens ao longo
do projeto.
Por exemplo, um projeto de redesign pode comear com uma
anlise heurstica ou mesmo com um expert review para ajudar a
estabelecer as metas de DI. Depois, uma vez iniciado o desenvolvimento, procedimentos empricos podem ser conduzidos para
validao de wireframes, layouts e do prottipo funcional. Para
fechar, pode-se voltar aos procedimentos analticos fnalizando os
procedimentos com uma anlise heurstica.

39

Como j falei algumas vezes, a escolha da quantidade de metodologias e dos momentos de aplicao vai depender de cada projeto e
do perfl de quem estiver conduzindo o projeto.
Uma coisa, no entanto, que no pode passar em branco o que

 gerado com cada um destes procedimentos. Um procedimento

emprico costuma servir para validao (funciona / no funciona.
Consegue / no consegue. Erra / acerta). No comum termos
sugestes de ajustes como parte dos resultados de procedimentos
empricos. a que entra o especialista que, ao avaliar os resultados, pode elaborar recomendaes.
Da mesma forma, procedimentos analticos no so os mais apropriados para proporcionar validao. Como o prprio nome diz,
so procedimentos mais voltados para a anlise e compreenso.
Vo dizer (ou dar resultados) se quesitos so ou no contemplados,
mas no necessariamente quer dizer que por algum quesito ter sido
contemplado o usurio vai entend-lo da maneira apropriada. Para
isso, necessrio fazer um procedimento emprico.
Assim sendo, o que recomendo que voc equilibre estes tipos de
procedimentos em seus projetos. O feedback de um especialista
to valioso quanto as descobertas obtidas com procedimentos
com usurios. Tudo vai depender daquilo que voc objetiva ter no
procedimento. Voltamos, ento, necessidade de um plano muito
bem construdo no incio do projeto. Isso permitir a voc defnir
e se planejar para realizar os procedimentos mais adequados nos
momentos recomendados.
Espero que o contedo da sequncia proporcione o necessrio para
lhe ajudar a fazer estas escolhas.

40

6 - Escolhendo
metodologias

Uma das coisas que me deixa embasbacado a quantidade de metodologias que temos disposio para procedimentos de Design
de Interao. Para se ter uma ideia, a IDEO tem at um baralho de
metodologias. A publicao bem bacana e mostra a pletora de
opes nesse sentido.
IDEO Method Cards is a collection of 51 cards representing
diverse ways that design teams can understand the people they
are designing for. They are used to make a number of diferent
methods accessible to all members of a design team, to explain
how and when the methods are best used, and to demonstrate
how they have been applied to real design projects.
htp://www.ideo.com/work/method-cards/

41
Obviamente no devemos usar todas em cada um de nossos projetos. Na verdade as cartas da IDEO tm sido usadas at por quem

no designer no intuito de entender diferentes maneiras de se

solucionar problemas. De qualquer forma, o que no devemos
deixar de usar ao menos uma metodologia (da IDEO ou no) em
nossos projetos.
Como a prpria descrio da publicao indica, as 51 cartas representam as diferentes maneiras disponveis que o designer pode
lanar mo para compreender as pessoas para quem est desenvolvendo a soluo. A fca claro que a maior parte destas metodologias se aplicam de maneira adequada na fase de descobertas do
desenvolvimento de um produto interativo. legal ver tambm que
este baralho mostra as diferentes e inusitadas maneiras de se obter
informaes sobre o contexto do uso, as caractersticas do pblico
e sobre as funcionalidades que um produto interativo deve ter.
Mas apenas falar do baralho no vai resolver os nossos problemas.
E apenas saber que existem vrias metodologias tambm no vai
ajudar muito no desenvolvimento de nossos projetos, certo? Ento
bom estabelecer um ponto de partida.
Acho que o jeito mais legal de se escolher as metodologias que
sero usadas entendendo o que se quer delas ou com os procedimentos que executaremos. Nesse sentido, fao meno ao captulo
anterior. Na ocasio, mostrei as diferenas entre metodologias empricas e analticas. Se voc pretende validar um produto ou uma
funcionalidade, o mais indicado realizar uma metodologia emprica e buscar envolver os usurios no processo. Mas que fque bem
claro que possvel fazer validaes com metodologias analticas.
Esta abordagem tambm se faz valer quando voc quer verifcar se
o caminho escolhido para determinada soluo o mais adequado.
Envolver o usurio e descobrir dele o que voc precisa saber ser
em 98% das situaes a coisa mais recomendada.

42
Quando o tempo no permitir ou o oramento estiver apertado ou
ainda se voc no tem como chegar aos seus usurios, as metodo-

logias analticas vo te dar respostas satisfatrias. Vale dizer tambm que num contexto de desenvolvimento gil, o envolvimento
dos usurios bastante simplifcado e os testes so mais rpidos e
localizados. Isso pode baratear a coisa.
Assim sendo, pense naquilo que voc precisa. Se envolver validao, recomendaria trabalhar com metodologias empricas. Se for
apenas uma verifcao, as metodologias analticas podem ajudar.
Se alm disso tudo voc precisa argumentar e defender algum
ponto para seu cliente, equipe ou chefe, acho que inegvel que o
envolvimento dos usurios necessrio. Vamos a um exemplo.
Certa vez fz no incio de um projeto um expert review. Em meu relatrio constatei que algumas sees poderiam ser unidas, simplifcando o acesso s informaes que os usurios precisavam. Alm
disso, indiquei que o site estava por demais lento e com pginas
muito pesadas e que demoravam mais do que o normal para serem
carregadas. Mesmo em conexes de banda larga. Quando mostrei
o relatrio para o cliente, o responsvel pela equipe de desenvolvimento torceu o nariz dizendo que eu estava fora da realidade. O
projeto continuou. Numa etapa mais adiante realizamos grupos focais e um dos participantes falou (com suas prprias palavras) dos
problemas que eu havia indicado no meu relatrio. Fiquei muito
feliz com a constatao. E fz questo de mostrar o vdeo com esta
fala do usurio para o cliente numa reunio seguinte. Dessa forma,
fcou claro que aquele relatrio inicial no era a minha opinio enviesada. Era um diagnstico. E este diagnstico foi confrmado com
a fala do usurio.

43

Acho que com este exemplo podemos perceber que a escolha das
metodologias depende do tipo de resposta que eu estou pretendendo obter. Assim sendo, o que recomendo a vocs estabelecer
o tipo de resposta que esperam em cada momento para que seja
ento defnida a metodologia e a abordagem a ser adotada.

7 - Prottipos

Em 2003 Jakob Nielsen abriu os olhos de muita gente para a importncia dos prottipos de papel. Obviamente no foi o primeiro
texto escrito sobre o tema. Na verdade ele mesmo j havia falado
disso anos antes no livro Projetando Websites. Alm disso, quem
trabalhava com desenvolvimento j conhecia o termo desde (no
meu caso) o fnal dos anos 1990 com o livro do urso polar.

44

Mas acho que a coluna do Jakob Nielse ajudou muito a espalhar

o termo. Em primeiro lugar porque ela chegava de graa s caixas postais de muita gente (e quela poca muita gente assinava a
newsleter do Jakob Nielsen para saber qual seria o prximo motivo para odiar este simptico senhor). Em segundo lugar porque,
justamente em virtude da grande resistncia a Usabilidade, este

texto acabou surpreendendo os designers, pois falava de algo que

eles poderiam fazer indicado pelo Jakob Nielsen que poderia
melhorar os seus processos.
Aliado coluna do Jakob Nielsen, o livro do Jesse James Garret
ajudou muito a popularizar o termo. Isso porque este ltimo de
cara havia cado nas graas dos designers. E seu livro Os elementos da experincia do usurio falava de se construir prottipos
antes de partir para o design fnal.
E ento chega a minha vez de falar isso com vocs e sem medo
de repetir o que todo mundo que j abordou o tema antes de mim
(especialmente estes que citei) disse falo: fazer um prottipo pode
representar um ganho enorme em seu projeto.
Os motivos so vrios. Em primeiro lugar, falando especifcamente
de sites e sistemas computacionais com interfaces em telas, voc
poder ensaiar como as coisas acontecero em cada momento de
interao de seu produto antes de efetivamente construir a tela.
Descobrir algo errado neste momento como diagnosticar uma
doena grave logo em seu incio. O tratamento pode ser muito mais
efciente do que se descoberto mais adiante em sua vida.
Nesse sentido, todo mundo que fala de prototipao refora que
voc deve insistir em ter uma verso de ensaio de tudo o que for
fazer e valid-la a fm de ter um passo seguinte mais certeiro e correr menos risco de errar.

45

Alm dessa funo mais voltada para a preveno de erros, um

prottipo serve tambm para que voc possa ensaiar e experimentar formatos e caminhos diferentes. E isso pode representar um
produto mais bacana e inovador ao fnal do processo.
Acredito que a elaborao de prottipos ainda se mostra ser uma
excelente estratgia para conduzir o processo de aprovao junto a
um cliente.

Vamos a mais um exemplo:

Suponha que voc (ou sua equipe / sua empresa) foi contratado
para elaborar um site para um cliente. A primeira coisa a fazer
aprovar o projeto de como ser este site. Os prottipos comeam
a se mostrar excelentes ferramentas aqui. Na hora de aprovar o
projeto, mostre um prottipo de baixa fdelidade, e no um layout
(que um prottipo de alta fdelidade) e nem sonhe em j mostrar
uma soluo funcional de cara. O motivo? Voc separa o processo
de aprovao da soluo efetivamente visual da parte funcional do
projeto.

46

Nos projetos que me envolvo costume pararmos nos wireframes

(que so os exemplos mais comuns de prottipos de baixa fdelidade). Dessa forma o projeto consiste em uma descrio textual de
como ser a soluo acompanhada de trs adendos visuais. Dois
deles podem ser considerados prottipos. O primeiro o wireframe, que representa o prottipo da tela. Claro que voc vai fazer

quantos wireframes forem necessrios para demonstrar o padro

que voc estabeleceu para o projeto e tambm para deixar o cliente
a par de como a coisa vai fazer.
Estes prottipos, como j disse em diferentes ocasies, podem
ser construdos usando-se as mais diversas ferramentas. Desde o
lpis e papel at ferramentas mais arrojadas como o Axure (que
gera wireframes funcionais e navegveis). O importante escolher
a ferramenta mais adequada para voc e sua equipe. Pode ser (e
eu recomendo) a mesma ferramenta que ser usada para fazer os
layouts. Falo isso porque depois que voc aprovar os wireframes
pode at aproveitar os mesmos documentos para dar continuidade
ao processo e construir os layouts.
Assim sendo, no frigir dos ovos comeo fazendo meus prottipos
com lpis e papel e, depois que passo pro Gimp, acabo aproveitando a coisa na hora de fazer os layouts (na verdade eu acabo
repassando os arquivos do Gimp exportados para o formato do
Photoshop para o designer de interfaces trabalhar. Como voc sabe,
designers costumam ter preguia do Gimp. Puro preconceito, mas
o mundo assim). Costumo recomendar tambm o Pencil que um
add-on para Firefox muito bacana para se fazer wireframes. Para
mais dicas de ferramentas para auxiliar o processo, consulte este
site htp://www.uxforthemasses.com/free-ux-tools/

47

O outro adendo visual de um projeto que pode ser considerado um

prottipo o fuxo de navegao. Este documento mostra a sequncia de telas pelas quais os usurios tero que passar para realizar
as tarefas. Neste sentido, o fuxo um ensaio de prottipo da interao do site. O Jesse James Garret se refere a estes fuxos como
os documentos do design da interao do projeto. Interessante, n?
Pois bem... Podemos encar-los como tal e tambm como os prottipos da interao pois observando estas sequncias que poderemos detectar alguns problemas que s apareceriam no desenvolvimento, o que daria mais trabalho para corrigir. Para constru-los,

muita gente usa o Visio, da Microsof, ou ainda ferramentas de

mapeamento de ideias, como o fnado Inspiration (que ainda
muito til), ou solues online como o Balsamiq (que tambm serve
para fazer wireframes) ou o Xmind ou o FreeMap. Para mais dicas
de ferramentas para auxiliar o processo, consulte este site: htp://
www.uxforthemasses.com/free-ux-tools/
O terceiro adendo visual (o mapa do site) no um prottipo, mas
ajuda bastante (quando somado aos wireframes e aos fuxos de navegao) a explicar visualmente para um cliente como o site ser.
Obviamente voc s vai inserir em um projeto e consequentemente
apresentar um prottipo para o cliente (fuxo e wireframe) depois
de validar estes documentos com procedimentos que podem ser
desde um simples percurso cognitivo ou um teste com usurios.
Ao fazer isso voc estar separando a parte funcional da forma na
hora de aprovar um projeto. Minha experincia mostra que isso
ajuda na aprovao.
Somente depois de ter os wireframes e fuxos aprovados (normalmente no momento que o projeto mostrado para o cliente) que
sigo em frente com a elaborao dos layouts. Novamente reforo:
separar estas aprovaes importante pois voc reduz o risco de
o cliente reprovar um projeto porque ele no soube dizer que na
verdade o que o incomodava era a cor do layout. E no espere que
um cliente saiba separar as coisas.

48

Os layouts, por sua vez, constituem um novo patamar em seus prottipos. Sobre eles, pouco tenho a dizer. Mas dando sequncia ao
processo que comecei a ilustrar, legal entender que uma vez que
separada a sua aprovao do restante do projeto, os resultados costumam ser melhores. Em primeiro lugar porque o papel do wireframe (prottipo de baixa fdelidade) junto ao cliente foi contemplado.
Ele deu uma prvia de como as coisas sero. Nesse sentido, quando

o cliente visualizar o layout, j estar devidamente preparado.

Outra coisa que deve fcar clara que alm de ser uma representao fdedigna do que ser o sistema ao fnal do processo e de servir
como pea de aprovao visual para o cliente, o layout um prottipo que pode ser testado. Nesse sentido, devemos proceder da
mesma forma que fzemos com os wireframes. Os testes podem ser
feitos adotando-se metodologias empricas ou analticas. Tudo vai
depender do seu tempo e oramento.
Por fm, gostaria de falar sobre os prottipos funcionais, que representam efetivamente o sistema em funcionamento. Eles tm grande importncia no processo pois atravs deles que voc far os
testes fnais de seu sistema. Tanto com usurios quanto os testes de
performance e de funcionamento do sistema em si. Eles costumam
fcar prontos bem no fnal do processo e para estes imprescindvel que voc conduza testes com usurios para descobrir as ltimas
arestas que devem ser aparadas. Ah, e antes que eu me esquea,
jamais deixe para fazer testes apenas neste momento. Isso porque
quando descobrimos algo to tarde assim, normalmente os problemas so remendados da pior forma possvel e os resultados acabam
sendo bem aqum do esperado.

49

8 - Validando layouts

Voc j deve ter percebido que os nossos captulos tm fcado mais

curtos, no ? Isso se d por alguns motivos. Em primeiro lugar,
pelo fato de que trabalhando com metodologias de design de interao, nossos projetos vo fcando mais fceis medida em que o
tempo vai caminhando. Isso quer dizer que as primeiras etapas so
sempre mais complicadas e medida em que voc vai avanando
no tempo, as coisas vo fcando mais fceis. Uma outra razo
que quando adotamos estas metodologias cada nova etapa valida a
anterior e se voc fez uma etapa anterior bem feitinha a etapa
seguinte ser sempre mais tranquila.

50

A mesma coisa se aplica a esta etapa. Se voc veio de um processo

em que os wireframes foram validados (com ou sem a participao
dos usurios), provvel que seus layouts estejam com poucos problemas. Mas nunca custa valid-los para se certifcar disso, no ?
Uma coisa muito bacana que devemos fazer ao validar layouts

algo que devemos fazer para qualquer validao, na verdade... Precisamos estabelecer as metas deste procedimento. Vamos validar
o qu? Quais sero os nossos parmetros? O qu esperamos em
termos de rendimento e performance? Claro, tambm ser defnido
o que (qual aspecto do) no layout est sendo validado.
Estas devem ser as metas de usabilidade que normalmente foram
estabelecidas l atrs e os wireframes j foram feitos seguindo estas
diretrizes. Se voc tem difculdades para estabelecer estas metas,
uma dica que costumo dar olhar uma lista de heursticas (as heursticas do Nielsen ou as da Cludia Dias podem ser um excelente
ponto de partida, mas como j disse tambm, basta dar uma googlada que voc encontrar heursticas para praticamente todo tipo
de sistema interativo).
Ento... Uma vez revisadas as suas metas, voc ter mais do que
pistas para estabelecer como devero ser validados os seus layouts.
Dependendo do estado das suas metas e das caractersticas de seu
projeto, nada impede que voc resolva validar seus layouts com a
realizao de um expert review ou uma anlise heurstica.
Metodologias analticas no so recomendadas apenas quando
houver alguma questo de performance ou algo que demande a
participao de um usurio real nos procedimentos. E voc descobre isso verifcando as suas metas de usabilidade. Se este o seu
caminho, perceba que necessrio ter a maior quantidade de telas
prontas pois sem elas voc no consegue conduzir as avaliaes
(anlise heurstica ou expert review) a contento.

51

O passo seguinte defnir qual ser a abordagem da validao.

Como j deixei claro anteriormente, tendo a recomendar a conduo de anlise heurstica. O motivo simples: voc corre o risco de
deixar as suas preferncias pessoais interferirem no processo de
um expert review, e isso pode comprometer a sua avaliao.

Consulte a lista original de heursticas de Nielsen ou qualquer

outra lista que voc j tiver preparada ou ainda que for mais adequada ao seu tipo de projeto. Como j disse, h muito material na
comunidade internacional de design de interao e em repositrios
como o da IXDA e ACM sobre o assunto. H listas de heursticas
para praticamente todo tipo de projeto interativo. Faa as adequaes mais relevantes na lista para que sua avaliao seja certeira e
monte o formulrio.
Costumo adotar um modelo de formulrio que tem mais ou menos
o seguinte aspecto: so quatro colunas de informaes na sequncia da exibio da heurstica ampla e da questo especfca. Uma
coluna reservada para o sinal que mostra se a heurstica ou no
contemplada. A segunda coluna reservada para colocarmos a gravidade do erro. Na terceira coluna vo as observaes do avaliador
e, na quarta coluna no caso de deteco de um problema qual
o impacto deste problema. Esta informao crucial para a parte
fnal.
Se suas metas, por outro lado, consistem em verifcar compreenso
de usurios, tempo de realizao de procedimentos e processamento de informaes por parte dos usurios, pode ser que voc no
consiga escapar de ter que fazer procedimentos empricos. Na verdade, bem recomendado que voc faa isso mesmo. Para tanto,
bem importante que voc tenha ao menos trs fuxos (este nmero
vai variar, dependendo de seu projeto e tambm do que voc quer
avaliar) completos para que os usurios consigam passar pelas telas
nos procedimentos e voc consiga obter mais informaes nos
testes. Nem preciso dizer que voc precisa que os contedos sejam
fdedignos e que tudo esteja o mais prximo de fnalizado possvel.

52

importante tambm que estes fuxos sejam aqueles cruciais para

seus sistema. De nada adiantar ter fuxos de cadastro se o que
voc precisa testar no o processo de cadastro, por exemplo.

Como j disse antes, estes fuxos podem estar representados em

papel ou em telas navegveis. Voc pode construir estas telas navegveis usando uma ampla opo de sofware desde o Fireworks
at o Axure para realizar os testes. Tenha em mente, no entanto,
que esta etapa no e nem deve ser confundida com a construo
de um sistema e estes prottipos no so ainda prottipos funcionais.
Assim sendo, no se espera que a esta altura voc tenha um cadastro funcionando ou mesmo um servio de buscas dando resultados
verdadeiros. Nesta etapa, sua preocupao verifcar questes
relacionadas a parte do design visual do seu projeto e como as telas
transmitem informaes para seus usurios. As funcionalidades do
sistema so tratadas aqui num nvel intermedirio. Para a validao fnal do sistema ele precisa estar operacional. A esta altura,
imagina-se que seu sistema no esteja neste ponto ainda.
Pois bem, com os fuxos em mos, hora de realizar os testes.
Organize-se para o teste. Tenha tambm as tarefas em mos e um
roteiro validado de teste. Selecione os usurios e conduza o procedimento focando na verifcao das metas propostas. Seus testes
podem ser feitos local ou remotamente. Em procedimentos locais,
fazendo com papel ou com telas navegveis, no se esquea de
documentar tudo o que acontecer nas sesses; especialmente as
reaes dos usurios. Caso os procedimentos sejam feitos remotamente, procure se possvel acompanhar o andamento (via tela
compartilhada e/ou recursos de telepresena). Na impossibilidade
de acompanhar os procedimentos ao vivo, estude bem os vdeos
das interaes.

53

Analisar os resultados de testes realizados com usurios para

validao de layouts no nada muito difcil. Como espera-se
que voc tenha uma listagem das coisas que pretende testar (por
exemplo: ser que as pessoas vo entender esta mensagem? ou
Quanto tempo o usurio levar para realizar o procedimento X),

a validao ser bem simples (entenderam ou no entenderam.

Os usurios levaram Y segundos para fazer o procedimento).
O segredo aqui ter uma amostra confvel de usurios. E por
amostra confvel entenda que no estou me referindo a quantidade, mas sim qualidade dos seus recrutados. Quanto mais fel for
a sua amostra referindo-se s caractersticas dos usurios melhor.

54

Da mesma forma que analisar ser algo no muito difcil, escrever

um relatrio de concluses ( bacana ter isso em mos para eventual justifcativa para o cliente ou setor) ser algo simples e direto.
Use e abuse dos recursos visuais e atenha-se a metas identifcadas
e a questes abordadas pelo teste. Muito importante voc ter
claros os motivos para eventuais alteraes. Ento, se no teste voc
descobrir que algo precisa ser alterado, o mais interessante proceder com a alterao e novamente realizar um teste para validar esta

alterao. Claro que voc vai fazer isso dentro de seu

cronograma e oramento.
Fazendo isso, eu posso te garantir que muitos confitos com clientes
podem ser minimizados. Alm disso, voc ter a certeza de que as
coisas estaro do jeito que estaro em relao a seu projeto por motivos
validados (e no por causa da opinio do designer). Mais importante
ainda, isso mostra que voc fez o que fez pensando em quem vai usar o
seu sistema.
Garanto que, se foram feitos procedimentos anteriores, provvel que
aqui s ocorram validaes e pequenas indicaes de correo. Isso
ser um indicativo de que voc mandou mais do que bem!
E no deixe de conferir a seguir os meandros e procedimentos envolvendo os testes com usurios.

55

9 - Testes com usurios

Uau! Estamos quase no fm! Mas ainda falta muita coisa para
falar... Acho que isso deixa uma dica do que vem por a, no ?
Bem, falando nisso... outra coisa que eu fquei pensando agora
que algumas referncias adicionais sobre parte dos temas abordados precisam ser repassadas. Deixei alguns textos especfcos para
download aqui: htps://copy.com/dgP1V8iWjywv . Coisa tranquila
de ler, mas que ajuda muito a entender os impactos da adoo de
procedimentos de DI. Para baixar este material, use a senha agosto (tudo em caixa-baixa, ok?).

56

Bem, mas vamos ao contedo deste captulo... Agora o nosso tema

testes com usurios. Como nas ltimas sees deste livro, este
um tema de aplicao direta e por isso mesmo serei bem objetivo. Costumamos fazer testes com usurios sempre que temos
algum deliverable (algo entregvel, tangvel e passvel de validao)
pronto. Isso pode acontecer at mesmo antes de o projeto comear
(por exemplo, testando o sistema atual; antes de pensarmos em
qualquer alterao. Este tipo de teste, embora opcional, bas-

tante elucidador e ajuda muito a descobrir qual caminho tomar

num processo de redesign por exemplo. Se houver tempo e verba,
recomendo fazer). Descobrimos coisas muito bacanas com testes
e normalmente, decises importantes so tomadas com um grau
maior de certeza de acerto quando embasadas em procedimentos
que envolvem usurios.
Enfm... Voc pode chamar usurios para testar seus prottipos em
fase inicial (wireframes ou prottipos de papel), na etapa de fnalizao de layouts ou quando voc j tem um prottipo funcional
pronto. Como j disse algumas vezes, tudo vai depender de sua
verba e cronograma.
Seguindo o que o Jared Spool fala (e a gente deve sempre ouvir o
que ele diz), fazer testes com usurios deve ser simples e fcil. Se
complicarmos muito (a quem nos ajuda com estas ideias o Steve
Krug) acabamos no fazendo a coisa. Procure sempre deixar o
usurio bem confortvel e para coletar os dados apenas preste
ateno no que ele faz com o sistema. Anote tudo. Tudo mesmo.
Como ele reagiu a cada clique ou nova tela, qual foi a interpretao
que ele fez a cada nova instruo, etc...
Procure fazer isso sem atrapalh-lo, apenas anotando. No interaja
com ele no momento do teste, apenas observe. Isso costuma ser
bastante efcaz quando estamos fora de nosso escritrio e com um
prottipo funcional. A temos a condio de testar o sistema funcionando no ambiente do usurio.

57

Embora nem sempre seja assim, d para continuar seguindo os

ensinamentos do jared Spool. A premissa bsica : tudo o que voc
precisa observar como o sistema funciona quando o usurio usa
o sistema e como o usurio responde ao sistema. Fazendo isso, d
para descobrir muita coisa.
Claro que para fazer o teste, como j conversamos na oitava sema-

na, preciso ter fuxos prontos (mesmo que sejam micro interaes)
para que o usurio consiga percorrer os caminhos que voc est
construindo. Alm disso voc precisa estabelecer o que ser testado
e quais os parmetros para o teste. Tendo isso defnido, seu trabalho de anlise ser sempre muito mais tranquilo.
Tambm recomendado que voc procure repetir (se possvel)
com mxima fdelidade o ambiente e contexto de uso. Se conseguir, ser timo. Mas no obrigatrio... Por isso, muita gente
recomenda ir at o usurio para conduzir os testes. Quando no d
para fazer isso, uma sala de tamanho mdio resolve o problema.
No h necessidade de espelho falso e nem de ante sala. Isso s se
faz necessrio se voc for realizar grupos focais. O que voc precisa
de espao para voc acompanhar o teste, o usurio usar o sistema
em questo e tambm se possvel uma cmera registrar a coisa
num trip.
Voc captar o vdeo da cmera (posicionada preferencialmente
para registrar o rosto do usurio) que pode ser at uma webcam,
mas neste caso, tome conta da mquina pois voc estar captando
duas trilhas de vdeo e isso pode demandar muito processamento. Se for uma cmera externa, sem problemas. Falei que so duas
trilhas de vdeo pois alm da cmera que registra o usurio, voc
pode (recomendado) registrar o vdeo da tela, mostrando a interao em si. Para isso voc pode usar sofware como o camtasia
(techsmith.com/camtasia.html), BB Flashback (bbsofware.co.uk/
bbfashback.aspx), camstudio (camstudio.org), kazam (launchpad.
net/kazam) ou qualquer outro de sua preferncia.

58

O camtasia bem, bacana, mas tem um custo. O mesmo com o BB

Flashback. Tanto o camstudio quanto o kazam so livres. Eu uso
muito o kazam. O mesmo fabricante do camtasia faz tambm o
Morae, que uma mo na roda (claro que tem um custo mais alto).
Este sofware sincroniza at trs trilhas de vdeo, ajudando muito
no trabalho de anlise. Mas se voc no tem verba, no h proble-

ma. Com um pouco de experincia voc conseguir sincronizar

essas duas trilhas de vdeo em seu editor preferido ou voc poder
ainda fazer a anlise em separado (mais trabalhoso, mas vivel).
Para voc que se perguntou o motivo de trs trilhas de vdeo no
morae, a vai a resposta: voc pode deixar uma cmera mostrando
o rosto do usurio e outra em suas mos. A terceira trilha seria a da
tela.
Se voc no tem cmera, no h o que temer. Grave ao menos a
tela do computador e tente registrar ao menos o udio (pode ser at
com o gravador de som do celular) para voc sincronizar as trilhas
num editor de vdeo e tentar entender o que estava acontecendo
quando aconteceram as coisas mostradas na tela. Graas popularizao dos equipamentos de foto e vdeo, esta estrutura no cara.
Pelo contrrio. E por mais que representa um investimento, fque
tranquilo pois ele se paga rapidinho.
Procure no ter ningum extra tomando nota neste procedimento.
Apenas voc dar conta do recado. Mais gente costuma inibir o
usurio e tumultua o processo.
Monte um roteiro para o teste. Este roteiro deve constar a recepo
do usurio, as diretrizes do que voc dir para ele ( importante
deixar o usurio tranquilo e ciente de que no ele que est sendo
testado, mas sim que ele est te ajudando a testar um sistema), a
explicao dos procedimentos que sero realizados, e a fnalizao
do teste. Tem gente que gosta de fazer uma pequena entrevista ao
fnal do processo. Isso pode ser bem interessante para voc arrematar eventuais arestas que tenha percebido durante o teste. Por fm,
voc remunera o usurio (falaremos disso daqui a pouco) e fecha a
sesso.

59

A realizao das tarefas importante tambm. Procure ter estas

tarefas relacionadas e preferencialmente escritas claras para o
usurio. Explique para ele que ele ter que fazer tais tarefas, pea

que ele leia com ateno e confrme se ele compreendeu as instrues antes de comear. Uma vez que ele comeou, no interaja
com ele. Se ele te perguntar algo, no d a resposta. Apenas pea
para ele agir como se agisse se se deparasse com aquela situao no
contexto de uso do sistema. No custa repetir: anote tudo!
Vale a pena fazer uma simulao do teste antes de partir para a
execuo para verifcar qual a durao mdia das tarefas e do teste
como um todo. Um teste muito longo costuma ser cansativo e o
rendimento do usurio cai aps uns 40 minutos de sesso. Alm
disso, fca muito caro fazer testes longos (mais tempo para cada
usurio = mais tempo no geral). bacana tambm ver se est tudo
funcionando direitinho (cmera, computador, registro de tela, etc)
para no ser surpreendido e acabar frustrado.
Sobre recrutamento e remunerao de usurios, algumas dicas importantes. Embora o Jakob Nielsen fale que no necessrio testar
com mais do que cinco usurios, isso no deve ser levado a ferro
e fogo. Mas tambm no quer dizer que voc precisa de validao
estatstica com margem de erro de 0,1% para que os testes sejam
vlidos.
Eu costumo recomendar que duas ou trs pessoas que representem
cada persona mais do que o sufciente para encontrar a maior
parte das questes. Para recrut-las h empresas de pesquisa de
mercado especializadas nesse servio ou ento voc pode verifcar se o seu cliente tem um cadastro de usurios e pode te passar
alguns contatos. D a ele os parmetros e procure as pessoas. No
recrutamento, explique a coisa de forma clara e procure explicar
que a participao do usurio importante para que seja construdo um servio mais apropriado para as suas necessidades.

60

H controvrsias com relao a remunerao. Eu costumo falar de

remunerao apenas depois que a pessoa aceitou fazer parte. A
eu meio que me certifco de que as pessoas que esto participando

no esto afm apenas de uma grana ou um presente. Como uma

sesso costuma durar aproximadamente uma hora, pense em remunerar seu usurio com o pagamento de uma hora de servio.
Como no Brasil a gente no costuma falar nossos salrios e nem saber certinho (pelo menos muita gente assim) saber quanto ganha
por hora, remunerao em dinheiro pouco usada. No entanto,
no desrecomendado. Outra forma de recompensar o usurio
dando a ele um presente pela participao. Eu j dei cestas de caf
da manh, vale-almoo em churrascaria e vale presente em lojas de
departamento. Este aspecto livre e como quase todo o resto
depende de seu oramento. O usurio te prestou uma baita ajuda e
o mnimo que voc pode fazer remuner-lo por isso.
Voltando ao roteiro do teste, pense em tarefas em que seja possvel
extrair o mximo possvel de feedback do uso do sistema. Claro,
estas tarefas devem contemplar o que voc especifcou para parametrizar seu teste.
O processo de anlise simples. Se voc tomou nota direitinho,
saber quais pontos do vdeo aconteceram os problemas (sacou a
dica?) v para estes pontos e tente entender o que ocorreu. Se possvel, edite o vdeo para acrescentar ao relatrio. Especialmente se
for importante para mostrar como as coisas esto dando errado em
um procedimento especfco, por exemplo. Escreva seu relatrio
de recomendaes de forma objetiva e direta. Aponte os problemas
(use e abuse de trechos de vdeo e captura de telas) e faa as recomendaes de correo.

61

Ah, ao fnal de tudo, vale a pena agradecer os usurios quando o

sistema fcar pronto. Mande a eles um e-mail de agradecimento e
mostrando o link do projeto fnalizado e no ar (no caso de um site)
dizendo que a ajuda dele foi importante para o sistema estar do jeito que est e claro coloque-se aberto a receber feedback extra.
Claro que esta etapa fnal completamente opcional, mas mostra

ateno e agradecimento aos que te ajudaram a fechar um ciclo de

DCU.

62

10 - Monitoramento

E eis que chegamos ao ltimo captulo de nosso livro!

Espero que ao longo deste livro o contedo que trabalhei aqui tenha sido til a voc. E reforo que este apenas um livro introdutrio. Estamos arranhando o tema.

63

Pra fechar ento, vamos falar de monitoramento.

Bem, monitorar acompanhar de perto, ver o que est acontecendo. No caso de um produto interativo, podemos fazer isso de diferentes maneiras. Pense num app. por exemplo, podemos monitorar
o uso do sistema se ele, por exemplo, fzer requisies ao servidor
sempre que for acionado. Outra maneira, acompanhar o que
discutido sobre o app. na loja de aplicativos. Ler os reviews, entender os eventuais problemas reportados ali. Falando em problemas
reportados, operacionalizar um canal para ouvir questes relacionadas ao app. uma excelente maneira de entender quais so os
problemas enfrentados pelos usurios. Olhar fruns de discusso

tambm interessante e acompanhar os reviews de sites especializados pode ser tambm um tanto quanto esclarecedor.
Como vocs podem ver, este monitoramento consiste em acompanhar como o sistema em questo est sendo usado e o que esto
dizendo sobre o seu uso. A gente pode descobrir muita coisa importante que eventualmente deixamos passar no desenvolvimento ou
ainda identifcar diferentes maneiras que as pessoas usam nossos
servios e sistemas interativos. Coisas para as quais nem imaginamos usar aquilo que fzemos. Entender estes usos e as particularidades dos usurios, seus problemas e como eles os resolvem
crucial para propormos melhorias no futuro.
Em se tratando de um site, h outras maneiras bem bacanas que
complementam as que falei anteriormente. Voc pode (e deve)
acompanhar as estatsticas de acesso ao site e entender o que est
acontecendo nas visitas dos usurios. A ferramenta mais conhecida para isso o Google Analytics, mas ela no a nica. O GA
fornece uma pancada de dados sobre os acessos ao seu site. Desde
as origens dos usurios, os caminhos que esto percorrendo na
estrutura, para onde eles vo e assim sucessivamente.
Outra ferramenta bem legal que costumo recomendar o CrazyEgg. Esta outra ferramenta semelhante ao Google Analytics, mas
ela tem alguns diferenciais. O primeiro deles que uma ferramenta paga. Mas isso pode valer muito a pena porque ela fornece
algumas informaes bem legais. As duas principais so o mapa
de calor que vai mostrar por onde passa o ponteiro do mouse
dos usurios (o que d uma pista de onde eles esto olhando) e a
outra um vdeo que mostra o que cada usurio fez no site. Isso
genial e quase como ter um Camtasia trabalhando o tempo todo
para voc.

64
Fazendo este acompanhamento de perto voc vai compreender
muito bem o que est acontecendo com o sistema e poder fazer

com muita facilidade (acompanhando em tempo real) experimentos com a interface. Fazer testes a/b fca bastante tranquilo se voc
tem estas ferramentas de acompanhamento a seu dispor.
Outra maneira ainda conduzir sesses de grupo focal. O investimento maior, pois demanda recrutar e remunerar usurios alm
de providenciar um local, assistentes e etc, mas vale a pena pois
voc ter a oportunidade de conversar com usurios para obter
percepes e compreender melhor como eles usam e como eles se
apropriam do sistema que voc fez.
Uma alternativa bem barata de fazer este tipo de acompanhamento
operada pelo Google via Hangouts. Frequentemente os gestores
de comunidades dos produtos do Google recrutam usurios destes produtos para participarem de Hangouts para falarem de suas
experincias com o produto. Este tipo de iniciativa bem barata e
proporciona um canal de comunicao bem legal do usurio com
a equipe de desenvolvimento. Nestes hangouts os usurios podem
fazer pedidos de funcionalidades e descrevem os eventuais problemas que enfrentam com o produto.
Ou seja: informao vai chegar de tudo quanto fonte. Voc precisa apenas se organizar e manter-se aberto para receber estes
inputs. muito importante ter esta abertura e tambm a maturidade de entender que mesmo que voc tenha lanado o produto,
ele nunca est pronto. O ciclo de desenvolvimento iterativo e no
tem fm. Voc no pode achar que um projeto (especialmente se ele
for seu, no um servio feito para um cliente que voc nunca mais
vai atender) no acaba. O desenvolvimento de um produto interativo um trabalho que no tem fm.

65

Diferente de nosso livro, que est acabando com este captulo.

hora de encerrar este ciclo, n? Para mim a experincia foi muito
boa. Espero que aquilo que foi apresentado ao longo destas pginas
tenha sido til para voc. Agradeo a todos que acompanharam ao

longo deste livro, aos membros de nossa comunidade e a todos os

que colaboraram no processo. A coisa no acaba aqui. Espero continuar. Mas para saber que assuntos tratar no futuro, preciso que
vocs comentem e indiquem quais so as suas necessidades em se
tratando de Design de Interao. E no deixe de dar o seu pitaco no
contedo do curso, do site e em nossas discusses, ok? A interao
continua em nossa comunidade! Nos vemos em breve!

REFERNCIAS
Alan Cooper, Robert Reimann e David Cronin - About Face 3
Caio Cesar G. Oliveira e Daniel P. Alenquer - Projeto original da Ps-Graduao em Design de Interao da PUC Minas
Christina Wodtke - Information Architecture: Blueprints for the web
Claudia Dias - Usabilidade na web
Donald Norman - The design of everyday things
Donna Booth - Product usability testing in a laboratory
D. Wallach and S.C. Scholz - User-Centered Design: Why and How to Put Users First in Sofware Development
Gillian Crampton Smith - in: Designing Interactions
Jakob Nielsen e Rolf Molich - Heuristic evaluation of user interfaces
Jakob Nielsen - Paper prototyping
Jakob Nielsen - Projetando websites
Jakob Nielsen - Usability Engineering
Jefrey Rubin - Handbook of Usability Testing: How to Plan, Design, and Conduct Efective Tests
Jennifer Preece, Yvonne Rogers e Helen Sharp - Design de Interao
Jesse Sames Garret - The Elements of User Experience
John D. Gould and Clayton Lewis - Designing for Usability: Key Principles and What Designers Think
Peter Morville e Lous Rosenfeld - Information Architecture for the WWW

66

Raquel Prates - Avaliao de Interfaces de Usurio

Steve Krug - No me faa pensar
Steve Krug - Rocket Surgery made easy
Walter Cybis - Ergonomia e Usabilidade