Apostila - Módulo 1 - Bootcamp UX Designer

Fundamentos de UX
Bootcamp de UX Designer
Alan Vasconcelos
2021
Fundamentos
Bootcamp de UX Designer
Alan Vasconcelos
© Copyright do Instituto de Gestão e Tecnologia da Informação.
Todos os direitos reservados.
Fundamentos de UX Designer – Página 2 de 55

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 ............................................................... 8
Princípio 1: Visibilidade ....................................................................................... 8
Princípio 2: Feedback ....................................................................................... 10
Princípio 3: Restrições ...................................................................................... 11
Princípio 4: Mapeamento .................................................................................. 13
Princípio 5: Consistência ................................................................................... 14
Princípio 6: Affordance ...................................................................................... 17
Conclusão ............................................................................................................. 19
Capítulo 2. Pesquisa de usuários ........................................................................ 20
O mito do usuário médio ....................................................................................... 20
O fracasso do Google Buzz .............................................................................. 20
O que são modelos? ............................................................................................. 21
Por que modelar usuários? ................................................................................... 22
O que são Personas? ........................................................................................... 22
Criando Personas ................................................................................................. 24
Coletando dados para as Personas ...................................................................... 26
Pesquisa Etnográfica ............................................................................................ 28
Conclusão ............................................................................................................. 29
Capítulo 3. Arquitetura da Informação ................................................................. 30
Somos todos arquitetos ........................................................................................ 30
Cardsorting e mapa de A.I .................................................................................... 34

Criando um mapa de Arquitetura de Informação .................................................. 36
Ferramentas ...................................................................................................... 37
Conclusão ............................................................................................................. 38
Capítulo 4. User Story Mapping (aula interativa) ................................................. 39
Desenvolvendo seu produto em partes (mas pode chamar de releases) ............. 42
User Story Mapping – Seu Backlog agora é um mapa ......................................... 45
Por onde começar? ........................................................................................... 46
Passando a faca – Ou criando releases ........................................................... 47
Conclusão ............................................................................................................. 48
Capítulo 5. Prototipagem ..................................................................................... 49
Benefícios ............................................................................................................. 51
Construindo seu protótipo ..................................................................................... 52
Protótipos de alta fidelidade .................................................................................. 53
Protótipos funcionais ............................................................................................. 53
Conclusão ............................................................................................................. 54
Referências........... ................................................................................................... 55

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.
▪ 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.
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.
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 do livro “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.
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.
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.

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.

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:

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.

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.

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,
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.
▪ 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.
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.
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.
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ão sabemos 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.
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.

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.
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 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.
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.
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.
▪ 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”.
▪ 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.

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:
▪ 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 online (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 torna sua

compreensão mais difícil, além de não se muito representativo).
▪ 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).
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.
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
online, 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.

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:

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:
▪ 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.
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.
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
do seu 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.
▪ 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 online 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.
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.

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

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

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, é porquê 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. 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.
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.

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.
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.
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
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
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 que 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á em baixo.

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.
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.
▪ 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!

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.

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).
▪ 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.
▪ 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;
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.
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 online, 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.
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”.

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.

Apostila - Módulo 1 - Bootcamp UX Designer

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila - Módulo 1 - Bootcamp UX Designer

Enviado por

Direitos autorais:

Formatos disponíveis

Fundamentos de UX

Fundamentos de UX Designer – Página 2 de 55

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

Princípio 1: Visibilidade ....................................................................................... 8

Princípio 2: Feedback ....................................................................................... 10

Princípio 3: Restrições ...................................................................................... 11

Princípio 4: Mapeamento .................................................................................. 13

Princípio 5: Consistência ................................................................................... 14

Princípio 6: Affordance ...................................................................................... 17

Capítulo 2. Pesquisa de usuários ........................................................................ 20

O mito do usuário médio ....................................................................................... 20

O fracasso do Google Buzz .............................................................................. 20

O que são modelos? ............................................................................................. 21

Por que modelar usuários? ................................................................................... 22

O que são Personas? ........................................................................................... 22

Criando Personas ................................................................................................. 24

Coletando dados para as Personas ...................................................................... 26

Pesquisa Etnográfica ............................................................................................ 28

Capítulo 3. Arquitetura da Informação ................................................................. 30

Somos todos arquitetos ........................................................................................ 30

Cardsorting e mapa de A.I .................................................................................... 34

Fundamentos de UX Designer – Página 3 de 55

Capítulo 4. User Story Mapping (aula interativa) ................................................. 39

Desenvolvendo seu produto em partes (mas pode chamar de releases) ............. 42

User Story Mapping – Seu Backlog agora é um mapa ......................................... 45

Por onde começar? ........................................................................................... 46

Passando a faca – Ou criando releases ........................................................... 47

Capítulo 5. Prototipagem ..................................................................................... 49

Construindo seu protótipo ..................................................................................... 52

Protótipos de alta fidelidade .................................................................................. 53

Protótipos funcionais ............................................................................................. 53

Fundamentos de UX Designer – Página 4 de 55

▪ UI Design (design de interface), são decisões de interação (mesmo que isso

▪ Um passo/etapa em um processo, é uma filosofia — uma postura — de todo

▪ Um tratado sobre usabilidade, além da eficiência e eficácia, o UX trata de

▪ Apenas para os usuários, é também para o criador do produto. Preocupa-se

Fundamentos de UX Designer – Página 5 de 55

Os diagramas abaixo ajudam a entender melhor como o UX pode colaborar

Figura 1 – Pirâmide da experiência do usuário.

Como podemos ver, a experiência começa com a utilidade, de determinado

Fundamentos de UX Designer – Página 6 de 55

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

Essa postura acaba criando uma série de problemas para a experiência de

O Feature Creep é uma anomalia comum em produtos interativos nos quais

Figura 2 – Exemplo de uma interface poluída pelo Feature Creep.

Fundamentos de UX Designer – Página 7 de 55

Primeiramente, é bom ressaltar que produtos desenhados para “apenas”

Donald Norman, talvez o principal nome quando se fala em UX em todo o

Princípios de Design por Donald Norman

Quanto mais soubermos sobre as possibilidades de interação, melhor. Isso

Figura 3 – A interface mostra o trecho selecionado ao mesmo tempo em que

Fundamentos de UX Designer – Página 8 de 55

Figura 4 – Uma torneira sem a manopla.

Entretanto, em alguns momentos é saudável esconder alguns elementos para

Fundamentos de UX Designer – Página 9 de 55

Fundamentos de UX Designer – Página 10 de 55

Este princípio prega que, em alguns momentos, a interface deve restringir as

Fundamentos de UX Designer – Página 11 de 55