Apostila Modulo 1 Bootcamp UX Designer

Prévia do material em texto

Fundamentos de UX 
Alan Vasconcelos 
 
 
 
 
 
 
 
2022 
 
 
 
2 
 
 
Fundamentos de UX 
Alan Vasconcelos 
© Copyright do Instituto de Gestão e Tecnologia da Informação. 
Todos os direitos reservados. 
 
 
 
 
3 
Sumário 
Capítulo 1. Princípios de design de interação ............................................................ 5 
Então, por que precisamos de UX? ............................................................................... 7 
O que motivou as pessoas a estudarem problemas de design? .................................. 8 
Princípios de Design por Donald Norman ..................................................................... 9 
Conclusão .................................................................................................................... 21 
Capítulo 2. Pesquisa de usuários .............................................................................. 22 
O mito do usuário médio ............................................................................................ 22 
O que são modelos? ................................................................................................... 23 
Por que modelar usuários? ......................................................................................... 24 
O que são Personas? ................................................................................................... 25 
Criando Personas ........................................................................................................ 27 
Coletando dados para as Personas ............................................................................. 29 
Pesquisa Etnográfica ................................................................................................... 31 
Conclusão .................................................................................................................... 33 
Capítulo 3. Arquitetura da Informação .................................................................... 34 
Somos todos arquitetos .............................................................................................. 34 
Cardsorting e mapa de A.I .......................................................................................... 38 
Criando um mapa de Arquitetura de Informação ...................................................... 41 
Conclusão .................................................................................................................... 43 
Capítulo 4. User Story Mapping (aula interativa) .................................................... 44 
 
 
 
4 
Desenvolvendo seu produto em partes (mas pode chamar de releases) .................. 47 
User Story Mapping – Seu Backlog agora é um mapa ................................................ 49 
Conclusão .................................................................................................................... 54 
Capítulo 5. Prototipagem ......................................................................................... 55 
Benefícios .................................................................................................................... 58 
Construindo seu protótipo.......................................................................................... 58 
Protótipos de alta fidelidade ...................................................................................... 59 
Protótipos funcionais .................................................................................................. 59 
Conclusão .................................................................................................................... 61 
Referências……………….. .................................................................................................... 62 
 
 
 
 
 
 
 
 
 
5 
Capítulo 1. Princípios de design de interação 
A esta altura, você já deve saber que UX é uma sigla para o termo User 
Experience. A maioria das pessoas que optam por estudar esse ramo do conhecimento 
tem plena ciência disso. Mas o que quase todas elas não sabem, é que User Experience 
não é somente encontrar a melhor solução para seus usuários. 
UX trata sobre definir o problema que precisa ser resolvido (o porquê), definir 
para quem esse problema precisa ser resolvido (o quem), e definir o caminho que deve 
ser percorrido para resolvê-lo (o como). 
UX não é: 
• UI Design (design de interface), são decisões de interação (mesmo que isso 
afete a aparência). 
• Um passo/etapa em um processo, é uma filosofia — uma postura — de todo 
o time. 
• Uma resposta para tudo, e sim saber o que o usuário quer e precisa (envolve 
pesquisa, observação e psicologia cognitiva). 
• Tudo o que for mais bonito e estético para a interface, mais do que isso, é 
descobrir o que é mais apropriado para seu perfil de usuário. 
• Apenas sobre tecnologia, mas sim sobre qualquer produto com o qual 
interagimos. Pode ser um elevador, uma porta, câmera fotográfica, um 
mobiliário urbano, entre outros. 
• Um tratado sobre usabilidade, além da eficiência e eficácia, o UX trata de 
aspectos emocionais sobre produtos que adoramos ou odiamos. 
 
 
 
 
 
 
 
6 
• Apenas para os usuários, é também para o criador do produto. Preocupa-se 
também em gerar valor para o negócio, para o produto e para os 
consumidores, o que, consequentemente, pode converter em receita, 
visibilidade e valor para a marca. 
• UX não é altruísmo, praticar UX pode ser muito lucrativo, especialmente para 
produtos que possuem pretensões comerciais. Como foi dito acima, os 
métodos de UX levam em conta os objetivos de negócio. Um produto com uma 
boa experiência de uso tem muito mais chances de ser bem-sucedido 
comercialmente. Mas é claro que se você quer fazer o bem e usar as boas 
práticas de User Experience em projetos de impacto social, uma boa 
experiência de uso pode contribuir bastante para que seu produto ajude a 
mudar o mundo para melhor! 
Os diagramas abaixo ajudam a entender melhor como o UX pode colaborar com 
a imagem do negócio e, claro, com a experiência de uso. 
Figura 1 – Pirâmide da experiência do usuário. 
 
 
 
 
 
 
 
 
7 
Como podemos ver, a experiência começa com a utilidade, de determinado 
produto ou serviço, ou seja, se as pessoas conseguem perceber que seu produto pode 
ser útil para suprir alguma demanda, isso significa que o primeiro passo já foi dado. 
Entretanto, a usabilidade é o nível mais “básico” da experiência do usuário, uma vez 
que, sem usabilidade, é difícil criar uma experiência de usuário que valha a pena. 
Além disso, sem desejo é improvável que a experiência do usuário deixe uma 
marca duradoura no usuário. Só com a atratividade a experiência do usuário pode ser 
memorável, fazendo com que o usuário recomende o produto para outras pessoas. 
 
Então, por que precisamos de UX? 
A resposta curta é: “O mundo é difícil de usar”. 
A resposta longa é que a maioria dos produtos interativos lançados no mercado 
são centrados nas necessidades e vontade do dono do negócio e não nos usuários que 
irão comprar e usar seus produtos. 
Essa postura acaba criando uma série de problemas para a experiência de uso. 
O mais comum deles é o chamado Feature Creep ou Síndrome do Painel de Avião. 
O Feature Creep é uma anomalia comum em produtos interativos nos quais a 
visão do dono (ou contratante) é a que sempre prevalece. Com isso, algumas funções 
ficam subutilizadas; torna-se impossível entender para que servem tantas teclas, 
comandos e botões; muitas opções desnecessárias para a maioria das pessoas; e, claro, 
uma interface poluída. 
 
 
 
 
 
 
 
 
 
8 
Figura 2 – Exemplo de uma interface poluída pelo Feature Creep. 
 
O que motivou as pessoas a estudarem problemas de design? 
Primeiramente, é bom ressaltar que produtos desenhados para “apenas” 
atender às necessidades do dono do negócio, tendem a fracassar no mercado. Steve 
Mulder, autor dolivro “The User Is Always Right” sugere que o design é que deve se 
moldar em função do usuário e não o contrário. 
Donald Norman, talvez o principal nome quando se fala em UX em todo o 
mundo, escreveu um livro chamado “O Design do Dia a Dia”. Esse livro se tornou um dos 
clássicos mais importantes da área e, por isso, é uma leitura obrigatória para quem 
quiser avançar nesta área. Nesse livro, estão enumerados os seis princípios de design 
que servem para qualquer produto. 
 
 
 
 
 
 
 
 
 
 
 
9 
Princípios de Design por Donald Norman 
Princípio 1: Visibilidade 
Quanto mais soubermos sobre as possibilidades de interação, melhor. Isso 
significa que a interface deve mostrar ao usuário tudo aquilo que pode (ou não pode) 
ser feito naquele contexto. Na figura abaixo, a interface deixa claro sobre as 
possibilidades de interação. 
Figura 3 – A interface mostra o trecho selecionado ao mesmo tempo em que uma 
barra de tarefas mostra o que pode ser feito. 
 
Às vezes não sabemos onde estão os elementos de interação. Os problemas 
com a Visibilidade aparecem quando “não podermos ver” os elementos de interação do 
produto. No exemplo abaixo, temos que adivinhar onde colocar as mãos. Torneiras e 
botões visíveis foram substituídos por “zonas ativas”, que são invisíveis e ambíguas. 
 
 
 
 
 
 
 
 
 
 
 
10 
Figura 4 – Uma torneira sem a manopla. 
 
Entretanto, em alguns momentos é saudável esconder alguns elementos para 
não poluir a interface. Desse modo, é importante fazer com que esses elementos 
apareçam no contexto apropriado, como foi o caso da seleção de texto da Figura 2. Na 
figura abaixo, veja que as ferramentas de edição de imagem só aparecem quando um 
objeto de imagem é selecionado. 
 
 
 
 
 
 
 
 
11 
Figura 5 – Algumas funções se mantêm invisíveis até que sejam necessárias. 
 
 
Princípio 2: Feedback 
Este princípio prega que toda ação do usuário requer uma reação do sistema, 
ou seja, o usuário precisa estar ciente de que o sistema entendeu seu comando. 
Ações simples, feitas com poucas linhas de CSS, podem garantir um bom 
feedback aos elementos interativos do seu software, como os estados “:hover” e 
“:focus”, por exemplo. 
 
 
 
 
 
 
 
 
12 
Figura 6 – Estilos diferentes que mostram que o botão/link está ativo e pode ser 
clicado. 
 
 
Princípio 3: Restrições 
Este princípio prega que, em alguns momentos, a interface deve restringir as 
possibilidades de interação, a fim de impedir o usuário de executar operações 
incorretas, como mostra a figura a seguir: 
 
 
 
 
 
 
 
 
13 
Figura 7 – Restrições de uso propositais. À esquerda, temos o Adobe Photoshop. À 
direita, temos o padrão de tomadas de três pinos. 
 
Ou seja, princípio da Restrição se refere às limitações ou bloqueios que 
colocamos na interface de forma proposital, dependendo, é claro, do contexto de uso. 
No exemplo na imagem anterior, o Photoshop desabilitou as opções “Fade, Cut, Copy e 
Clear”, por causa daquele contexto de operação. Neste caso, esses comandos aparecem 
desabilitados, porque nenhum pixel foi selecionado na tela de trabalho. 
As restrições podem também ser aplicadas com o objetivo de prender a 
atenção do usuário em uma determinada tarefa, como nas telas modais. 
Figura 8 – Telas modais para manter o foco do usuário em uma ação específica. 
 
 
 
 
 
 
 
 
14 
Princípio 4: Mapeamento 
É preciso haver coerência entre o controle e a sua função. Ou seja, ao olharmos 
para o elemento interativo (botão, maçaneta, manopla), não deveríamos ter que 
adivinhar ou refletir sobre qual deve ser o botão/ícone correto. Na figura abaixo, o fogão 
da direita permite com que não tenhamos a obrigação de testar ou adivinhar qual botão 
acende a respectiva trempe. Já o da esquerda, possui uma interface com uma disposição 
ambígua, que não nos dá uma dica clara sobre a relação entre o botão e a trempe 
correta. 
Figura 9 – Exemplos de mapeamento bem aplicado (na direita) e mal aplicado 
(esquerda). 
 
Os tipos de mapeamento também podem variar de acordo com a sua aplicação. 
Podemos citar dois tipos predominantes de mapeamento: o natural e o direto. 
 
 
 
 
 
 
 
 
15 
Figura 10 – O mapeamento natural, como um volante ou a alavanca de seta do carro 
e o mapeamento direto, no qual basta olharmos para identificar qual botão aciona a 
chama correspondente no fogão. 
 
Figura 11 – Exemplos de mapeamento natural e direto, aplicados de forma correta e 
incorreta. 
 
 
Princípio 5: Consistência 
O princípio da consistência diz que a interface deve manter uma unidade visual 
e funcional em todo o sistema. Ou seja, além do quesito estético, é primordial que 
tarefas similares sejam realizadas com elementos similares. No exemplo abaixo, 
 
 
 
 
 
 
 
16 
podemos perceber que as plataformas PC e MAC possuem, cada uma, sua própria 
consistência no que se refere à posição do botão “Cancelar” nas telas de confirmação. 
Figura 12 – Enquanto no Windows o comando cancelar fica sempre na direita, no 
MAC OS é o oposto. 
 
Interfaces consistentes fazem com que o usuário se sinta seguro e confiante de 
que o produto é bem desenhado. Além disso, com o uso frequente fica mais fácil para o 
usuário se familiarizar com os elementos de interação e seu comportamento. 
A consistência pode acontecer de quatro maneiras: 
• Consistência funcional: Que diz respeito à coerência das funcionalidades 
Figura 13 – Exemplo de consistência funcional. 
 
 
 
 
 
 
 
 
17 
• Consistência estética: aparência e estilo bem definidos e facilmente 
reconhecidos pelo público. O fabricante Mercedes Benz, consistentemente, 
coloca seu emblema nos capôs de seus carros. O reconhecimento é associado 
à qualidade, prestígio, fino acabamento e confiabilidade. Já a Apple, 
consistentemente, coloca seu emblema nas costas de seus produtos, onde sua 
marca é mais visível. 
Figura 14 – Exemplos de consistência estética. 
 
• Consistência interna: consistência visual (ou funcional) com os demais 
elementos dentro do sistema. Reforça o senso de orientação e confiabilidade, 
e indica que o sistema é bem desenhado e bem planejado. 
 
 
 
 
 
 
 
 
 
 
 
 
18 
Figura 15 - Consistência interna. Padrões de design do Android (Material Design). 
 
Figura 16 – Apple Mail: Swipe para a direita, marca como não lido, enquanto no 
MailBox o mesmo gesto arquiva a mensagem. 
 
• Consistência externa: consistência com outros elementos no ambiente. 
Reforça a consistência interna para sistemas múltiplos. O disquete como ícone 
de salvar, e o “hambúrguer” como menu, são bons exemplos. 
 
 
 
 
 
 
 
 
 
19 
Figura 17 – Exemplo de consistência externa (ícone hambúrguer). 
 
 
Princípio 6: Affordance 
Este princípio é um dos mais controversos. Ele diz que os elementos de 
interação devem “falar por si” sobre como operá-los. No exemplo da figura a seguir, 
tanto a maçaneta, quanto a tesoura dão dicas sobre como usá-las, mesmo só olhando 
para elas. 
Figura 18 – Affordance bem aplicado. Não há dúvidas sobre cobre como operar. 
 
 
 
 
 
 
 
 
20 
Como dito, o Affordance é a propriedade que os elementos possuem de "falar 
com o usuário" sobre como eles devem ser usados ou sobre qual é o seu status atual. 
Nesses casos, um botão que tem a aparência de desabilitado, significa que seu 
Affordance "está dizendo" para o usuário que ele não deveria ser clicado, baseando-se 
apenas em sua aparência (sem a necessidade do contexto). 
O Affordance também é dividido em quatro tipos: 
• Affordance percebida: nos dois casos da figura anterior, a ação é possível e 
também é percebida pelo usuário. 
• Rejeição correta: é quando sabemos que há uma proibição ou restrição de uso. 
Por exemplo, um botão com a aparência de desabilitado que, de fato, não 
realiza nenhum comando no sistema. 
• Affordance escondida: é quando não sabemos como operar o elemento 
interativo. Ex.: numa maçaneta esférica, nãosabemos para que lado girar e 
nem se devemos apertar. 
• Affordance falsa: é quando o elemento praticamente “conta uma mentira” 
sobre como operá-lo. Na figura abaixo, podemos observar uma porta que 
possui maçaneta, mas, no entanto, trata-se de uma porta de correr. 
Figura 19 – Péssimo exemplo. A porta possui maçaneta, mas é de correr. 
 
 
 
 
 
 
 
 
21 
Conclusão 
UX é mais que usabilidade. Trata-se também de otimizar fluxos, processos de 
design e até a postura do designer. 
Para que o UX cumpra sua missão de melhorar a experiência de uso, é preciso 
conhecer bem o usuário, suas características relevantes, sua cultura e, claro, suas 
habilidades. Portanto, esse será o tema do próximo capítulo. 
 
 
 
 
 
 
 
22 
Capítulo 2. Pesquisa de usuários 
Parece óbvio que, para proporcionarmos uma experiência de uso agradável e 
satisfatória, precisamos conhecer bem nosso público-alvo, ou a nossa população de 
usuários. Entretanto, na esmagadora maioria das empresas de design ou de software, 
acontece um fenômeno curioso. 
 
O mito do usuário médio 
O que deve ser impregnado em nossas mentes é o fato de que “nós não somos 
iguais aos nossos usuários. Não importa o quão competente (pensamos que) sejamos”. 
Essa afirmação remete a um dos casos de insucesso mais emblemáticos da história 
recente. 
O fracasso do Google Buzz 
Em 2010, o Google lança uma plataforma social que integra atualização de 
status, postagens de fotos, mensagens diretas, discussões e e-mail. Mas uma das 
funcionalidades era, justamente, conectar-se com as pessoas para as quais você já havia 
enviado um e-mail. 
A aparente boa ideia foi muito bem aceita, no início, pela população de 20.000 
usuários que serviram de amostra para os primeiros testes. É isso mesmo: 20.000 
usuários! Aí você se pergunta: “Que empresa possui 20.000 usuários só para testes 
preliminares? E se mesmo assim o produto não vingou, o que deu errado?”. 
Bem... raramente teremos uma amostragem tão grande como a do Google. O 
problema deles foi justamente a qualidade da amostra. É que esses 20.000 usuários 
eram funcionários do próprio Google. 
 
 
 
 
 
 
 
23 
Jacob Nielsen, considerado o “pai da usabilidade”, disse: 
“Uma das lições mais difíceis da usabilidade é constatar que ‘você não é o 
usuário final’. Se você trabalha em um projeto de desenvolvimento, você é um usuário 
atípico por definição”. 
As funcionalidades do Google Buzz agradavam perfeitamente para a maioria 
dos seus empregados e, mesmo assim, a empresa recebia inúmeras reclamações até ser 
descontinuado. 
Moral da história: observar usuários reais ou potenciais do seu produto pode 
trazer muitas ideias para o design da experiência, além de ser mais confiável. Por isso, 
repita em voz alta: “Não existe usuário padrão!” “Não existe usuário médio!” 
Então, como não cometer o mesmo erro? Resposta rápida: construa modelos 
para entender seus usuários. Já a resposta longa, vem a seguir. 
 
O que são modelos? 
Podemos começar dizendo que modelos são representações estruturadas de 
fenômenos e abstrações complexas. Podem ser usados nas ciências naturais e sociais. 
Os economistas se valem de modelos para entender o comportamento dos 
mercados, os físicos, para entender as partículas. Por isso, pesquisar e criar modelos 
descritivos de nossos usuários é uma ferramenta útil e poderosa. 
Os modelos também servem para otimizar a compreensão, visibilidade e 
comunicação de informações, lembrando que “informação” é bem diferente de “dado”. 
Exemplo: “Possuímos 2 milhões de usuários”. Isso é meramente um dado. Entretanto, a 
expressão: “Possuímos 2 milhões de usuários, dos quais 65% são mulheres e 35% são 
 
 
 
 
 
 
 
24 
homens, e desse total 47% possuem curso superior”, isso sim, em UX, pode ser chamado 
de informação, pois é um dado com significado. 
Um bom modelo é aquele que evidencia as características mais relevantes. Em 
se tratando de usuários, podemos sugerir modelos que sejam representativos para um 
determinado grupo, que, por sua vez, está inserido em uma população maior. 
 
Por que modelar usuários? 
É muito comum que nós (desenvolvedores, designers e gerentes de marketing), 
fiquemos tentados a encher nosso produto de novas ferramentas, estratégias ousadas 
e funcionalidades avançadas. 
Mas essas decisões devem ser pautadas em informações concretas e não em 
“caprichos” da equipe. E você deve estar muito bem embasado para convencer seu 
chefe, o gerente de marketing e sua equipe a abandonar algumas dessas coisas “super 
legais” que foram propostas. 
Para isso, pesquise fundo quem é o seu público-alvo e como ele se comporta, 
assim como quais são seus perfis. Em outras palavras, modele seus usuários! 
Em UX existe uma técnica largamente difundida para a modelar usuários. 
Estamos falando da “Persona”. A seguir abordaremos mais essa técnica. 
 
 
 
 
 
 
 
 
 
 
 
25 
O que são Personas? 
É uma técnica de modelagem de usuários que utiliza pessoas fictícias para 
representar grupos/perfis de usuários de um produto. A técnica é considerada barata, 
fácil e divertida para a equipe de desenvolvimento. 
Foi mencionada pela primeira vez no livro “The Inmates Are Running the 
Asylum” de Alan Cooper. 
A persona é como uma ficha de personagem de RPG do usuário-modelo do 
sistema, criada a partir de dados reais. Contém, entre outros, o nome, gostos, hábitos, 
necessidades e habilidades dos usuários. 
Lembre-se: “fictício” não significa “falso”. 
Uma persona é um arquétipo de usuário que ajuda a direcionar decisões sobre 
funcionalidades, navegação, interatividade e elementos visuais na interface. 
Personas são perfis representativos de comportamentos e atividades que são 
contextualizadas e específicas a um determinado produto, software ou aplicação. São 
representadas graficamente por meio de uma “prancha”, que pode ser uma folha de 
papel colada na parede. 
O ideal é que as pranchas de personas estejam em locais visíveis, não só na sala 
de desenvolvimento, mas também na da gerência e do marketing. Veja a seguir um 
exemplo de uma prancha de Persona. 
 
 
 
 
 
 
 
 
 
 
26 
Figura 20 – Exemplo de uma prancha de persona. 
 
Personas são também um meio muito eficaz de comunicação interna da equipe. 
Quando uma descoberta importante é feita sobre o projeto, é muito mais fácil 
comunicar a equipe toda. 
Por exemplo, utilizar a frase: 
"Eu acho que a Jill Anderson não vai conseguir usar a ferramenta de busca" 
é melhor do que: 
"Uma quantidade representativa dos participantes dos testes de usabilidade, 
tiveram problemas com a ferramenta de busca”. 
Personas servem para otimizar o processo de desenvolvimento, uma vez que: 
• Engaja e conscientiza a equipe de projeto. 
 
 
 
 
 
 
 
27 
• Chega-se a um consenso dos interesses do usuário. 
• Mantém o foco no usuário durante todo o projeto. 
• Agiliza a tomada de decisões, pois não é preciso consultar usuários reais a cada 
etapa. 
Como disse Alan Cooper, “Personas são uma forma de dar ao usuário um 
assento na mesa de desenvolvimento”. 
 
Criando Personas 
Uma boa prancha de persona deve conter: 
• Nome e foto. 
• Frase de efeito e características gerais. 
• Tipo. Ex.: “Adolescente do ensino médio” ou “Aposentada doméstica”. 
• Função. Ex.: “usuário administrador” ou “editor de conteúdo” ou “usuário 
final”. 
• Motivações. 
• Objetivos. 
• Necessidades. 
• Dificuldades. Ex.: “Nunca usou um dispositivo touch na vida” ou “usa versão 
antiga do S.O em smartphone de baixo custo e baixa resolução” ou “não possui 
plano de dados 3G”. 
 
 
 
 
 
 
 
28 
• Comportamentos e habilidades. É uma escala visual que mede uma certa 
habilidade ou comportamento da persona como “proficiência em informática: 
alta-baixa” ou “tendência de uso do seu smartphone: trabalho-diversão”. 
Para entender melhor, veja um exemplo a seguir: 
Figura 21 – Template para a construção de uma persona.Fonte: http://goo.gl/HlvXiG. 
 
 
 
 
 
http://goo.gl/HlvXiG
 
 
 
 
 
 
 
29 
Figura 22 – As pranchas ficam visíveis para toda a equipe. 
 
Figura 23 – Grande parte dos produtos interativos demandam mais de duas 
personas. 
 
 
Coletando dados para as Personas 
Existem várias maneiras de se obter dados relevantes para a construção das 
personas, por exemplo: 
 
 
 
 
 
 
 
30 
• Analisando estatísticas de acesso (como Google Analytics). 
• Entrevistando com equipes de suporte (que, por sinal, sempre dão ótimas 
ideias sobre os diferentes perfis de usuário e suas demandas). 
• Verificando com a equipe de marketing se já não existe alguma pesquisa feita 
sobre o público-alvo (mesmo que a intenção seja descobrir consumidores e 
não usuários). 
• Criando questionários on-line (com perguntas-chave que irão revelar como são 
os perfis de usuário). 
Entretanto, é muito importante tomarmos alguns cuidados para que o processo 
não se complique ou pior, pois o seu método pode criar arquétipos falsos. 
Ao se trabalhar com personas, podemos cometer alguns enganos típicos que 
poderão prejudicar todo o planejamento estratégico. Por isso, preste atenção nos 
seguintes tópicos: 
• Personas não são segmentos de mercado definidos pela equipe de marketing 
(lembre-se: uma persona é um modelo de usuário e não de comprador). 
• Personas não são atores de sistema (personas são modelos de usuário sendo 
que um ator pode ser até uma máquina ou outro sistema). 
• Personas não são papéis de usuários (“usuário administrador” ou “cliente 
comprador” são perfis orientados à tarefa já as personas são orientadas a 
objetivos e comportamentos). 
• Não crie segmentações demais (muitos segmentos de usuários tornam sua 
compreensão mais difícil, além de não ser muito representativo). 
 
 
 
 
 
 
 
31 
• Nas pesquisas, não pergunte informações pessoais em exagero (pergunte a si 
mesmo: “será que preferência musical, religião ou inclinação política são 
mesmo relevantes para o projeto da interface?”). 
 
Pesquisa Etnográfica 
WIll Evans, diretor de User Experience Design na TLC Labs, afirmou que: 
“Projetar baseando-se na sua própria experiência, sem nenhuma pesquisa de usuários, 
é como apostar na loteria”. Por incrível que pareça, há muitos projetos com orçamento 
grande que não investem em pesquisa alguma. 
Lembre-se, pessoas são complexas. 
Por isso, a etnografia permite extrair algum sentido nessa complexidade. Ela 
faz com que a gente veja além do nosso (pré-)conceito e mergulhe no mundo dos outros. 
O mais importante é que a etnografia nos permite enxergar padrões de comportamento 
no contexto do mundo real, que podem ser entendidos tanto racionalmente, como 
intuitivamente. 
O termo vem do Grego “éthnos” (raça, povo) + “gráphein” (escrita). 
Este método de pesquisa foi utilizado pela primeira vez pelo historiador alemão 
Gerhard Friedrich Müller, considerado o pai da etnografia. Hoje, o método é usado para 
pesquisas de cunho social (indicadores de desenvolvimento) e mercadológico 
(comportamentos de consumo). 
 
 
 
 
 
 
 
 
 
32 
Figura 24 - Livro Observing the User Experience: A Practitioner's Guide to User 
Research. 
 
Em 2003, Mike Kuniavsky escreveu um clássico do UX chamado: “Observing the 
User Experience: A Practitioner's Guide to User Research” Este livro foi um marco na 
história do UX, pois foi um dos primeiros a tratar com bastante praticidade, as técnicas 
para ultrapassar o abismo entre o comportamento dos usuários e o que designers e 
desenvolvedores imaginam sobre eles. 
Uma das principais recomendações em pesquisas etnográficas, é: 
“Observe e aprenda com o público observado”. 
Por exemplo, em vez de fazer suposições sobre o comportamento de uso de 
mulheres que jogam videogames, há duas alternativas: 
a) Convidar alguma mulher “gamer” e fazer um questionário bem extenso 
com ela. 
 
 
 
 
 
 
 
33 
b) Gastar uns 4 ou 5 dias observando e fazendo anotações sobre como as 
mulheres interagem e se comportam nas lan-houses, nos jogos on-line, 
nos fóruns, em casa etc. 
Entrevistas e questionários são bem úteis, mas podem deixar escapar algumas 
peculiaridades. Em pesquisas etnográficas, é mais indicado uma observação ativa 
(quando o pesquisador se apresenta e até participa no grupo observado) ou passiva 
(quando apenas observa). 
Em vez de fazer perguntas, observe e converse bastante para saber sobre as 
motivações de cada mulher jogadora e o que interfere em suas escolhas. 
 
Conclusão 
Não dá para criar experiências de uso sem conhecer seus usuários. Por isso, 
para evitar o achismo, pesquise sempre e modele seus usuários utilizando Personas. As 
chances de acerto e de sucesso no mercado são muito maiores. 
 
 
 
 
 
 
 
34 
Capítulo 3. Arquitetura da Informação 
Antes de abordarmos os conceitos e técnicas de Arquitetura de Informação, é 
preciso saber que, na verdade... 
 
Somos todos arquitetos 
Sim! Em nossa vida, nós temos a necessidade de organizar, classificar e 
categorizar tudo que conhecemos. 
Figura 25 – Todo mundo categoriza/classifica/organiza. 
 
E essa é uma prática que aperfeiçoamos a cada dia para tirar proveito da 
informação organizada. Na figura anterior, a informação é organizada pelos sabores e 
tipos de alimentos. Na figura a seguir, a arquitetura é feita por assunto: 
 
 
 
 
 
 
 
 
35 
Figura 26 – Os cadernos de um jornal são exemplos de organização da informação, 
cujo esquema é o assunto. 
 
Ou seja, todo mundo categoriza/classifica/organiza alguma informação ou 
coisa. O que varia são os esquemas de organização. 
Os esquemas de organização podem ser ambíguos ou exatos. Veja: 
• Ambíguos por assunto: organiza a informação em temas. 
‒ Ex.: cardápios, editorias do jornal, supermercado. 
• Ambíguos por tarefa: organiza a informação em sequência de ações. 
‒ Ex.: menu aplicativos Windows (editar, exibir, formatar). 
• Ambíguos por audiência: organiza a informação para diferentes públicos. 
‒ Ex.: lojas de departamento (classifica seus produtos em masculino, 
feminino e infantil). 
Quanto aos esquemas exatos, temos: 
 
 
 
 
 
 
 
36 
• Alfabeto: indicado para organizar informação extensa e de público variado. 
‒ Ex.: dicionários, enciclopédias, listas telefônicas. 
• Tempo: indicado para mostrar a ordem cronológica de eventos. 
‒ Ex.: livros de história, grade de programação, banco de notícias. 
• Localização: compara informações de diferentes locais. 
‒ Ex.: previsão do tempo, pesquisa boca-de-urna, Atlas. 
• Sequência: organiza itens por ordem de grandeza e valor. 
‒ Ex.: lista de preços, classificação do campeonato. 
No fim das contas, o objetivo da Arquitetura de Informação é quase que “pegar 
o usuário pela mão” e conduzi-lo à informação que ele deseja. 
Figura 27 – Procedimentos da Arquitetura de Informação. 
 
 
 
 
 
 
 
 
37 
Segundo Rosenfeld e Morville (1998), a AI é fruto da combinação de quatro 
elementos: 
1. Sistema de organização: refere-se a uma maneira lógica de classificação 
informacional, definindo os tipos de relacionamento entre itens de conteúdos e 
grupos; 
2. Sistema de rotulagem: representa a nomenclatura dada a cada grupo ou 
categoria de informação; 
3. Sistema de navegação: apresenta a trajetória que o usuário terá disponível no 
website, sistema ou aplicativo para acessar cada informação com a distribuição 
de links, botões e menus; 
4. Sistema de busca: é a estratégia para auxiliar o usuário na localização e no acesso 
rápido a informações armazenadas no produto. 
Figura 28 – O livro Arquitetura da Informação, também conhecido como “o livro do 
urso polar”, é a principal obra sobre o tema. 
 
 
 
 
 
 
 
 
38 
Morville e Rosenfeld, em seu livro “Arquitetura da Informação”, alertam que a 
arquitetura deve ser pautada em três pilares: usuário, contexto e conteúdo. Dessa 
forma, deve-se evitar ao máximo classificar/organizar/rotular o conteúdo 
doseu produto, baseando-se apenas na estrutura organizacional da sua empresa. A 
organização da informação deve ser lógica do ponto de vista do usuário e não do 
organograma. 
Então, como organizar os conteúdos de um produto interativo, que leve em 
consideração a perspectiva do usuário? Bem, a maneira mais segura é pedir ao público 
para que ele mesmo organize e, assim, observar o resultado. 
Ou seja, faça um Cardsorting. 
 
Cardsorting e mapa de A.I 
Cardsorting é uma técnica para compreender como o usuário agrupa 
informações dentro de um domínio. Nela, os participantes organizam cartões 
representando tipos específicos de informação. 
Segundo Nielsen (2004), um erro comum nos sites e intranets é estruturar a 
informação baseando-se em como a empresa enxerga a sua informação. (espelhamento 
do organograma). O Cardsorting evita esse erro e elimina o achismo da equipe de 
desenvolvimento. 
Quanto à sua aplicação, pode ser ABERTO ou FECHADO: 
• Aberto: o usuário agrupa livremente os itens criando o número de conjuntos 
que achar necessário. 
 
 
 
 
 
 
 
39 
• Fechado: os grupos são previamente criados e rotulados pelo pesquisador, e 
o usuário apenas agrega itens a grupos pré-existentes. 
Figura 29 – Exemplo de um cardsorting sendo aplicado em uma oficina. 
 
No exemplo acima, podemos ver uma oficina de cardsorting onde os 
participantes organizam as informações em cartões espalhados. Dessa forma, o 
avaliador deve observar os padrões e, de posse desses dados, propor a organização da 
informação do produto. 
Na figura a seguir, temos um exemplo de uma ferramenta on-line para 
aplicarmos cardsorting à distância, ou seja, não é necessária a presença física dos 
participantes. Além disso, a ferramenta já fornece os dados tabulados e os termos mais 
recorrentes. 
 
 
 
 
 
 
 
 
 
40 
Figura 30 – Exemplo de um Cardsorting fechado, usando a ferramenta Optimal 
Workshop. 
 
Fonte: optimalworkshop.com. 
Na figura a seguir, temos um exemplo de uma matriz de similaridade, extraída 
da tabela de resultados de um Cardsorting fechado usando a ferramenta Optimal 
Workshop. Pela imagem, é possível observar quais termos possuem mais afinidade uns 
com os outros na medida em que a cor fica mais forte: os agrupamentos formados pelos 
quadradinhos com a cor mais forte são os termos (ou cartões) que os participantes 
acreditam que são mais similares. 
 
 
file:///C:/Users/Usuario/Downloads/optimalworkshop.com
 
 
 
 
 
 
 
41 
Figura 31 – Matriz de similaridade do Optimal Workshop. 
 
 
Criando um mapa de Arquitetura de Informação 
Um mapa de A.I bem-feito, deve contemplar o máximo de variáveis possíveis 
(atores, funcionalidades, possíveis caminhos, desvios e relacionamentos). Por isso, não 
economize nos comentários e anotações. 
Deixe o mapa em um local acessível a todos da equipe (impresso ou on-line). 
Caso o mapa sofra alguma alteração, deixe claro o que mudou. Aplicar um número de 
versão é uma boa prática, como por exemplo: ai_produto_rev03.html 
 
 
 
 
 
 
 
 
42 
Figura 32 – Exemplo de um mapa de AI em HTML, feito com a ferramenta MindJet 
Manager. 
 
 
Ferramentas 
A princípio, o mapa pode ser feito até mesmo em papel e afixado na parede. 
Mas existem ferramentas que auxiliam na criação e compartilhamento do mapa de AI. 
Veja alguns exemplos: 
• whimsical.com (Web). 
• Mindjet Mind Manager (Desktop / Mobile). 
• xMind (Desktop). 
 
 
 
 
 
 
 
43 
• iMindMap (Desktop, Web, Mobile). 
• Omnigraffle (Desktop / Mobile - Apple). 
• EasyMapper (Desktop). 
• MindMeister (Web). 
 
Conclusão 
Arquitetura da Informação visa garantir que todo o conteúdo está organizado 
e categorizado da maneira mais lógica para o usuário. Por isso, elimine os achismos e 
observe seu público. 
Uma vez que com as personas nós já sabemos como é o perfil do nosso público, 
chega a hora de modelarmos as tarefas que serão desempenhadas por eles. Hoje em 
dia, a melhor maneira de conseguir isso é criando pequenas histórias que descrevem 
como os usuários realizam essas tarefas. É o que veremos a seguir. 
 
 
 
 
 
 
 
44 
Capítulo 4. User Story Mapping (aula interativa) 
Afinal, o que é User Story para início de conversa? 
Durante a aula interativa nós iremos abordar este tema com mais exemplos, 
mas de toda forma, podemos explicar uma User Story ou História de Usuário com nada 
mais do que a descrição de uma pequena funcionalidade que o cliente pretende ver 
desenvolvida no sistema. Nesse caso, é bom prestar atenção no termo em inglês story 
(história – conto) e não history (história - relato de fatos). Podemos entender as USs 
como uma breve descrição de uma funcionalidade que foi discutida e acordada entre a 
equipe. De toda forma é sempre bom ressaltar o que as USs não são. Veja: 
• Documentos de implementação (classes, modelagem...), 
• Artefatos imutáveis: podem sofrer alterações e negociações ao longo do 
projeto. 
• Casos de uso: este último se refere à narrativa de funções de forma impessoal, 
ou seja, independente do usuário. 
Cada User Story foca nos objetivos do usuário e como o sistema vai ajudar o 
usuário a alcançá-los. Ou seja, elas fracionam os requisitos com descrições simples de 
uma funcionalidade segundo o ponto de vista do usuário. 
Devem ser curtas, simples e claras. Devemos conseguir escrevê-las em um 
simples e pequeno cartão (User Index Cards). Se não houver espaço para escrevê-la em 
um cartão, é porque devemos refiná-la mais e, quem sabe, dividi-las em outras User 
Stories. 
Os stakeholders que escrevem User Stories, não os desenvolvedores. Isso se 
deve ao fato de que as USs devem sempre levar em conta a perspectiva do usuário. 
 
 
 
 
 
 
 
45 
Dessa forma, as User Stories são simples o suficiente para que as pessoas possam 
aprender a escrevê-las em alguns minutos. 
A sintaxe – digamos assim – para se escrever uma US é composta de três 
elementos principais: 
a) Ator – É quem desempenha a ação no sistema. De forma simplista é o usuário, o 
interessado naquela funcionalidade, mas é recomendado descrever de forma 
específica quem é o ator para ser mais fácil identificar o contexto da história 
dentro do sistema. Nesse caso, podemos usar a própria persona. 
b) Ação – É o que o ator quer fazer. Utilizando aquela ação, ele espera alcançar seu 
objetivo dentro do sistema. 
c) Objetivo/Funcionalidade – É o que o ator espera que aconteça ao realizar a 
ação. Ou seja, é o resultado de executar a ação segundo a ótica do ator. Também 
pode ser visto como justificativa. 
Figura 33 – Sintaxe de uma User Story. 
 
 
 
 
 
 
 
 
46 
Abaixo, podemos ver como uma típica US de um sistema para livraria se parece: 
Figura 34 - User Story preenchida. 
 
São tradicionalmente escritas em cartões ou post-its, ou seja, são curtas, quase 
atômicas em termos de funcionalidades. De toda forma, para escrevermos boas User 
Stories precisamos nos certificar que elas sejam: 
a) Independentes: histórias devem ser independentes uma das outras. 
Ex.: usuário pode entrar com o nome do meio, primeiro nome e último nome. 
b) Negociáveis: histórias não são contratos, mas lembretes para discussões (por 
questões de escopo, orçamento ou complexidade, as histórias podem ser 
removidas ou alteradas.) 
c) De valor agregado: histórias devem agregar valor para o usuário/cliente. Por 
exemplo, dizer que o sistema será feito em Java e MySQL não é relevante para o 
usuário/cliente. 
 
 
 
 
 
 
 
47 
Desenvolvendo seu produto em partes (mas pode chamar de releases) 
Em times que adotam os métodos ágeis (como o famoso Scrum), escrever USs 
é uma tarefa super corriqueira. Além disso, é mais seguro tanto para a equipe quanto 
para o cliente, entregar o sistema em pequenos ciclos de entrega, ou Sprints. Ou seja, a 
cada intervalo de tempo, o cliente poderá ver qual “pedaço” ou release do sistema já 
ficou pronto. 
Antes de iniciar os trabalhos de desenvolvimento do sistema,um membro da 
equipe reúne todas as USs em uma grande “pilha” que é chamada de Backlog, que é 
uma lista de todas as funcionalidades que o produto precisa ter. 
O processo de construir o sistema em pequenas entregas (iterações), é 
chamado de processo iterativo (sem a letra “n” mesmo, não confundir com interativo). 
Ou seja, cada pequena entrega é chamada de iteração, que acontece ao final de cada 
sprint. Dessa forma, quando uma nova Sprint se inicia, a equipe escolhe quantas (e 
quais) USs serão retiradas da pilha (ou do backlog) para serem implementadas neste 
novo ciclo (Sprint). 
No entanto, há uma certa confusão de conceitos entre o processo iterativo e o 
processo incremental. 
No modelo incremental, o produto vai sendo entregue em pedaços (ou 
incrementos) sendo que, cada “pedaço” corresponde a uma funcionalidade completa, 
testada e tida como pronta. Ou seja, uma vez entregue, essa funcionalidade – em tese 
– não deveria voltar para o time de desenvolvimento, que, por sua vez, deve estar 
ocupado desenvolvendo o próximo incremento ou funcionalidade. 
 
 
 
 
 
 
 
48 
Incrementação presume que já se tenha uma ideia completa e imutável do que 
será construído. Além disso, terminar o projeto no prazo estimado requer uma 
estimativa ultra precisa. 
Figura 35 – Exemplo de um processo incremental, onde já se sabe tudo o que deve 
ser feito desde o início do projeto. 
 
O processo iterativo, ao contrário, parte de um rascunho e gradativamente vai 
aperfeiçoando a qualidade. Além disso, permite criar produtos a partir de uma mera 
ideia, sendo que as correções, validações e ajustes vão acontecendo ao longo do 
caminho. 
Figura 36 – Processo iterativo. Alto grau de incerteza no início dos trabalhos, mas, ao 
longo do ciclo de desenvolvimento, essa incerteza diminui até chegarmos na ideia 
final. 
 
 
 
 
 
 
 
 
49 
O mais interessante dessa abordagem é que ela pressupõe que o cliente ainda 
não sabe de tudo que o sistema precisa ter, ou seja, esse processo é mais tolerante a 
novas ideias, correção de rotas e incertezas. 
Portanto, iteração é entregar o produto em partes funcionais ou releases ao 
final de cada Sprint. 
E se ao invés de “empilharmos” as USs em uma grande pilha (no caso o 
backlog), pudéssemos distribuí-las em um “mapa”? Foi o que Jeff Patton, criador do 
método chamado “User Story Mapping” (Mapeamento de Histórias de Usuário) fez. 
 
User Story Mapping – Seu Backlog agora é um mapa 
Um problema comum em muitos times ágeis é a falta da percepção do produto 
como um todo, ou, como dizem lá fora, the big picture. Isso acontece devido ao fato de 
o backlog (a lista completa das funcionalidades que o produto precisa ter) do produto 
ser mais útil para sabermos quais são as próximas coisas a serem feitas. Mas e o conjunto 
da obra? Em que direção o projeto está caminhando? 
Outra lacuna na abordagem do backlog seria a priorização das histórias. Quais 
são as funcionalidades chave? Quais funcionalidades têm mais valor para o cliente e 
para o usuário do produto? 
Essa última pergunta nos leva a outros questionamentos: Como saberemos o 
que é mais importante para o usuário final? Como introduzir os requisitos de 
Usabilidade num processo ágil? 
Como bons designers de interação, não podemos ter a pretensão de ter uma 
resposta para tudo, mas devemos saber conduzir atividades que auxiliem a sua 
 
 
 
 
 
 
 
50 
descoberta. Uma das ferramentas que podem ajudar bastante nesse processo chama-
se User Story Mapping. 
“User Story Mapping é um mapa que organiza as histórias de usuário 
em um modelo que ajuda a compreender a funcionalidade do sistema, 
a identificar falhas no seu backlog, e a, efetivamente, planejar releases 
holísticas que oferecem valor aos usuários e ao negócio a cada versão.” 
Jeff Patton, em The New User Story Backlog Is a Map. 
Ou seja, em vez de empilhar, mapeie! 
Diferentemente de um backlog típico, o USM pode: 
• Tornar mais visível o fluxo de atividades e a cadeia de valor de cada história. 
• Mostrar os relacionamentos entre histórias dentro de uma atividade maior. 
• Ajudar a checar a completude do backlog. 
• Revelar um contexto mais amplo do que deve ser priorizado. 
• Ajudar a planejar os releases com mais valor (de negócio) agregado. 
 
Por onde começar? 
Antes de tudo, reúna os stakeholders e elabore uma oficina em que todo 
mundo participa, principalmente o usuário final. É muito comum que nós 
(desenvolvedores, designers e donos de produto) esqueçamos alguns pontos que só o 
usuário seria capaz de nos lembrar. 
Nessa oficina, distribua os cartões ou post-its e tente identificar quais são as 
atividades macro, ou seja, um conjunto de funcionalidades (histórias) que serão 
 
 
 
 
 
 
 
51 
alinhadas horizontalmente na parede, por ordem de importância (valor). Patton afirma 
que também é possível fazer esse ordenamento por sequência de operação, como em 
um e-commerce, onde a atividade “adição do produto ao carrinho” vem antes de 
“checkout” e antes de “pagamento”. É possível perceber que, em cada atividade, há 
diversas histórias de usuário como: pesquisar o produto pelo nome, alterar a quantidade 
e escolher o meio de pagamento, entre outras. 
Uma das missões mais importantes quando praticamos o USM é ordenar as 
histórias verticalmente. Como podemos ver na imagem a seguir, as histórias são 
ordenadas na vertical por ordem de “valor agregado” para o usuário. Ou seja, aquelas 
histórias que são mais “valiosas” para a nossa persona ficam mais para cima, enquanto 
as demais vão ficando para baixo. 
Basicamente, a ordenação vertical das histórias deve seguir um princípio muito 
importante: pergunte a si mesmo, “o que a(s) minha(s) persona(s) mais gostaria(m) de 
ver no meu produto?”. As histórias que ficam mais altas no mapa são aquelas que devem 
satisfazer as maiores expectativas da(s) persona(s). Resumindo, ordene as histórias 
verticalmente, colocando a mais importante lá em cima, e a menos importante (ou a 
menos prioritária) lá embaixo. 
 
 
 
 
 
 
 
 
 
 
 
 
52 
Figura 37 – Debaixo de cada funcionalidade vem as histórias, que são organizadas 
verticalmente por ordem de importância (as de cima valem mais). 
 
 
Passando a faca – Ou criando releases 
Depois de posicionar as histórias, chega a vez de “fatiar” o mapa a fim de 
estabelecermos os releases do nosso projeto. Geralmente, o primeiro release é o que 
chamamos de MVP ou Minimum Viable Product, isto é, Produto Mínimo Viável. 
 
 
 
 
 
 
 
 
 
 
 
53 
Figura 38 – “Fatiando” o mapa. A linha separa o que deverá ser feito primeiro 
(release 1) e o que vai ser feito depois (release 2). Um USM pode ter quantos 
releases forem necessários. 
 
Provavelmente, os grandes méritos do USM dizem respeito ao fato de todo o 
time ter uma noção da importância daquela história no produto como um todo, além 
da priorização de cada “pedaço”. Outras vantagens dessa ferramenta até já foram 
citadas aqui, mas não custa repetir: 
• Ajuda a entender, como um todo, o que o sistema faz. 
• Ajuda a entender o que está sendo construído. 
• Ajuda a fazer um planejamento e entendimento do release. 
• Oferece uma visão mais clara das prioridades e do valor agregado. 
• Por ser uma técnica colaborativa, engaja a equipe. 
• Prioriza os requisitos (histórias) de uma forma ágil. 
 
 
 
 
 
 
 
54 
• Preenche o abismo entre processo de design e o processo ágil de 
desenvolvimento. 
• Evita a síndrome do canivete suíço (feature creep), já que as histórias são bem 
discutidas. 
Importante: o mapa não fica pronto e imutável depois da oficina. É natural e 
saudável que ele sofra adaptações, ajustes, incrementos, mudanças de rumo e 
melhorias ao longo do projeto. 
 
Conclusão 
Até aqui, nosso conhecimento de UX está bastante abstrato, ou seja, já vimos 
como modelar usuários, navegação e até as tarefas que o usuário precisa realizar. Como 
dito durante a aula interativa,veremos mais detalhes e exemplos sobre modelagem de 
tarefas com User Story Mapping. Enquanto isso, chegou a hora de materializarmos 
nossas ideias em algo mais palpável. Vamos prototipar! 
 
 
 
 
 
 
 
55 
Capítulo 5. Prototipagem 
Uma definição bem abrangente do termo prototipagem, seria: “uma versão 
simulada ou amostra de um produto final, utilizada para testes antes do lançamento”. 
Ou seja, o objetivo de qualquer protótipo é testar... seja uma tela, um caso de 
uso, uma funcionalidade ou mesmo uma ideia. 
Um dos equívocos mais comuns sobre prototipagem é pensar que ela só 
acontece uma ou duas vezes, no final do processo de concepção. Isso não é verdade, 
prototipe o mais cedo possível e sempre que puder. 
No contexto do software, são representações visuais que servem para melhorar 
a visibilidade e compreensão de telas, fluxos e interações, sempre do ponto de vista do 
usuário. Podem se de baixa ou alta fidelidade (ou resolução). Protótipos de baixa 
fidelidade, geralmente são feitos em papel. 
Os de alta fidelidade, também são chamados de Wireframes, ou protótipos 
funcionais, justamente por serem mais próximos do modelo de interação do produto 
final (alguns consideram o wireframe como um protótipo de “média fidelidade”). 
Sempre acontecem depois da Arquitetura de Informação. 
O gráfico abaixo, criado por Traci Lepore, UX Sênior da Bridgeline Digital, faz 
uma relação bem clara sobre o nível de fidelidade e o contexto do ciclo de vida de 
desenvolvimento do produto. Quanto mais à esquerda, ou seja, no início do 
desenvolvimento, menor a fidelidade do protótipo. Por outro lado, quanto mais 
refinado e maduro estiver o escopo do produto, maior será o nível da fidelidade da 
prototipagem. 
 
 
 
 
 
 
 
 
56 
Figura 39 – Relação do nível de fidelidade com o momento do projeto. 
 
Desde a validação de uma ideia até a simulação do produto final, os protótipos 
são úteis para manter a segurança da equipe de desenvolvimento. É que como as ideias 
já foram testadas, fica muito mais confortável implementar uma solução sem o medo 
de ter que refazer tudo. 
Prototipação em papel = Prototipação rápida. 
• É um método que permite delinear de forma ágil e barata, a interface de um 
sistema (web, app, game etc.). 
• Devem elucidar a lógica e as regras de negócio do produto. 
• É bem barato! (gasta-se, basicamente, papel, lápis e tempo). 
 
 
 
 
 
 
 
57 
• Possui o fator “engajamento” (por envolver mais pessoas e ter um caráter 
quase lúdico). 
• Não precisa ser bonito! (Aliás, a proposta é ser ágil. O foco é na experiência de 
uso). 
• Não deve refletir a aparência estética (design). 
• Podem ser usados em testes de usabilidade. 
Figura 40 – Exemplo de um protótipo em papel. 
 
Pode servir de documentação, em lugar às documentações mais extensas, e 
deve ser um reflexo de: 
• Modelagem de tarefas. 
• Requisitos. 
• Arquitetura de informação. 
 
 
 
 
 
 
 
58 
• Conteúdo. 
 
Benefícios 
• As alterações de design, decorrentes de testes com usuário, podem ser feitas 
em tempo real. 
• As pessoas que participam do teste ficam mais confortáveis em criticar o 
produto, pois têm plena noção que se trata de um protótipo. 
• Propor alterações conceituais nessa etapa, economiza tempo e dinheiro, já 
que alterar um software pronto é sempre mais custoso. 
“Estima-se que seja 100 vezes mais barato fazer mudanças antes de escrever 
qualquer código, do que aplicá-las após a implementação.” (NIELSEN, Jakob) 
 
Construindo seu protótipo 
Em 2009, a Interactions Magazine publicou um artigo de três pesquisadores da 
universidade de Indiana, que propunha uma nova abordagem para a prototipagem em 
papel. A proposta seria inserir os desenhos no próprio dispositivo para que os testes 
fossem mais fidedignos. 
Segundo o artigo, a prototipagem deveria conter as etapas a seguir: 
1. Desenhar os protótipos; 
2. Digitalizar os desenhos e ajustar os tamanhos das telas; 
3. Salvar as imagens na galeria de fotos do dispositivo; 
 
 
 
 
 
 
 
59 
4. Ordenar as imagens na ordem correta do fluxo de operação; 
5. Ao testar, explicar ao usuário que a interação se dará ao fazer o “slide” de uma 
foto para outra. 
Entretanto, já existem ferramentas próprias destinadas a prototipagem 
via “Paper in Screen”, como o POP – Prototyping On Paper, (que foi adquirido pela 
MarvelApp). 
 
Protótipos de alta fidelidade 
São protótipos que representam a estética e o layout final que o produto terá. 
Esses protótipos são norteados pela linha gráfica do produto (identidade visual, paleta 
de cores, tipografia) ou pelo manifesto de design da empresa. 
No caso de aplicativos, é necessário seguir as guidelines de design de cada 
plataforma. Para saber sobre as guidelines do Android, acesse: 
http://developer.android.com/design/. Para saber sobre as orientações do iOS, acesse: 
http://goo.gl/01xkAk. 
 
Protótipos funcionais 
Também são conhecidos como Wireframes. São protótipos que simulam o 
comportamento, funcionalidade e a navegação de forma mais semelhante à versão 
final. 
 
http://developer.android.com/design/
http://goo.gl/01xkAk
 
 
 
 
 
 
 
60 
Figura 41 – Snapshot do Figma. 
 
São feitos a partir de ferramentas mais elaboradas, como: 
• Figma (Web e Desktop). 
• UXPin. 
• Adobe XD. 
• JustInMind. 
• Excode (Apple). 
• Axure. 
Existem ainda ferramentas on-line, como o excelente Figma e o UXPin, que 
além de possuir muitos componentes prontos, é multiplataforma e ainda permite 
compartilhar a URL do protótipo no final. 
 
 
 
 
 
 
 
61 
 
Conclusão 
Prototipe sempre e o mais cedo possível. Só assim a equipe poderá avançar no 
desenvolvimento com segurança de que o produto foi bem testado e não sofrerá 
grandes alterações. 
E por falar em testar, chegou a hora de colocar seu protótipo à prova, ou seja, 
tomar algumas atitudes que visam checar os possíveis problemas de usabilidade que sua 
interface possa ter. Você pode fazer isso de duas maneiras: 
1. Convidando pessoas reais para usar o seu protótipo funcional e observar o que 
acontece. 
2. Convidando pessoas de dentro da sua equipe para fazer uma espécie de 
“inspeção” de usabilidade, a fim de encontrar possíveis problemas (problemas 
de usabilidade, claro). 
A primeira abordagem é mais conhecida como “teste empírico de usabilidade”, 
ou apenas “Teste de Usabilidade”. Já a segunda, o mercado chama de “inspeção de 
usabilidade”, em que o método mais popular, criado por Jacob Nielsen, é a famosa 
“Avaliação Heurística”. 
 
 
 
 
 
 
 
62 
Referências 
COOPER, Alan et al. The inmates are running the asylum: Why high-tech products drive 
us crazy and how to restore the sanity. USA, Indianapolis: Sams, 2004. 
DRAFT INTERNATIONAL STANDARD. ISO/DIS 13407:1999 Human-centred design 
processes for interactive systems. 1999. 
KRUG, Steve. Don't make me think: A common sense approach to web usability. Pearson 
Education India, 2005. 
KUNIAVSKY, Mike. Observing the user experience: a practitioner's guide to user research. 
Morgan kaufmann, 2003. 
MOATTI, Yosef. Dynamic conversion rate optimization. U.S. Patent Application n. 
11/289,234, 29 nov. 2005. 
MULDER, Steve; YAAR, Ziv. The user is always right: A practical guide to creating and 
using personas for the web. New Riders, 2006. 
NIELSEN, J. Usability Engineering. Chestnut Hill, MA, Academic Press, 1993. 
NORMAN, Donald A. The design of everyday things: Revised and expanded edition. Basic 
books, 2013. 
PATTON, Jeff; FOWLER, Martin; COOPER, Alan; et al. User story mapping. Beijing: 
O'Reilly, 2014. 
PREECE, Jenny; ROGERS, Yvonne; SHARP, Helen. Design de interação. Bookman, 2005. 
ROSENFELD, Louis; MORVILLE, Peter. Information architecture for the world wide web. 
O'Reilly Media, Inc. 2002.