The Elements of User Experience User Cen

Machine Translated by Google
OS ELEMENTOS DE
EXPERIÊNCIA DE USUÁRIO
SEGUNDA EDIÇÃO
DESIGN CENTRADO NO USUÁRIO

PARA A WEB E ALÉM
Escrito e ilustrado por

Jesse James Garrett
Os elementos da experiência do usuário: design centrado no usuário para a Web e além,

Segunda edição
Jesse James Garrett
New Riders1249 Eighth Street

Berkeley, CA 94710
510/524-2178
510/524-2221 (fax)
Encontre-nos na Web em: www.newriders.com

Para relatar erros, envie uma nota para errata@peachpit.com
New Riders é uma marca da Peachpit, uma divisão da Pearson Education.
Copyright © 2011 por Jesse James Garrett
Editor do projeto: Michael J. Nolan

Editor de Desenvolvimento: Rose Weisburd
Editor de Produção: Tracey Croom
Editor de texto: Doug Adrianson
Revisor: Gretchen Dykstra
Indexador: Valerie Perry
Designer de capa: Aren Howell Straiger
Designer de Interiores: Kim Scott
Compositor: Kim Scott
Aviso de Direitos
Todos os direitos reservados. Nenhuma parte deste livro pode ser reproduzida ou transmitida de qualquer
forma por qualquer meio, eletrônico, mecânico, fotocópia, gravação ou outro, sem a permissão prévia por escrito
do editor. Para obter informações sobre como obter permissão para reimpressões e trechos, entre em contato com
permissions@peachpit.com.
Aviso de responsabilidade
As informações neste livro são distribuídas “como estão” sem garantia. Embora todas as precauções tenham sido
tomadas na preparação do livro, nem o autor nem a Peachpit terão qualquer responsabilidade perante qualquer pessoa
ou entidade com relação a qualquer perda ou dano causado ou alegadamente causado direta ou indiretamente pelas
instruções contidas neste livro. ou pelo software de computador e produtos de hardware nele descritos.
Marcas registradas
Muitas das designações usadas por fabricantes e vendedores para distinguir seus produtos são reivindicadas
como marcas registradas. Onde essas designações aparecem neste livro e a Peachpit estava ciente de uma
reivindicação de marca registrada, as designações aparecem conforme solicitado pelo proprietário da marca registrada.
Todos os outros nomes de produtos e serviços identificados ao longo deste livro são usados apenas de forma
editorial e para o benefício de tais empresas, sem intenção de violação da marca registrada. Nenhum uso desse
tipo, ou o uso de qualquer nome comercial, tem a intenção de transmitir endosso ou outra afiliação a este livro.
ISBN 13: 978-0-321-68368-7

ISBN 10: 0-321-68368-4
987654321
Impresso e encadernado nos Estados Unidos da América

Para minha esposa, Rebecca Blood

Garrett, que torna todas as coisas possíveis.
4 OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO
Índice
CAPÍTULO 1
Experiência do usuário e por que é importante 2
Misérias do dia a dia 3
Apresentando a experiência do usuário 4
Do design do produto ao design da experiência do usuário 7
Projetando (para) experiência: o uso é importante 8
Experiência do usuário e a Web 9
Uma boa experiência do usuário é um bom negócio 12
Cuidando de seus usuários 17
CAPÍTULO 2
Conheça os elementos 18
Os Cinco Planos 19
O Plano de Superfície 20
O avião esqueleto 20
O Plano da Estrutura 20
O Plano do Escopo 21
O Plano Estratégico 21
Construindo de baixo para cima 21
Uma Dualidade Básica 25
Os elementos da experiência do usuário 28
O Plano Estratégico 28
O Plano do Escopo 29
O Plano da Estrutura 30
O avião esqueleto 30
O Plano de Superfície 30
Usando os elementos 31
OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO dentro
CAPÍTULO 3
O Plano Estratégico
Objetivos do produto e necessidades do usuário 34
Definindo a Estratégia 36
Objetivos do produto 37
Objetivos de negócios 37
Identidade da marca 38
Métricas de sucesso 39
Necessidades do usuário 42
Segmentação de usuários 42
Usabilidade e pesquisa de usuários 46
Criando Personas 49
Funções e processos da equipe 52
CAPÍTULO 4
O Plano do Escopo
Especificações Funcionais e Requisitos de Conteúdo 56
Definindo o Escopo 58
Razão #1: Então você sabe o que
Você está construindo 59

Razão #2: Então você sabe o que
Você não está construindo 60
Funcionalidade e Conteúdo 61
Definição de Requisitos 65
Especificações funcionais 68
Escrevendo 69
Requisitos de conteúdo 71
Priorizando Requisitos 74
nós OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO
CAPÍTULO 5
O Plano da Estrutura
Design de Interação e Arquitetura da Informação 78
Definindo a Estrutura 80
Design de interação 81
Modelos conceituais 83
Manipulação de erros 86
Arquitetura de informação 88
Estruturando Conteúdo 89
Abordagens arquitetônicas 92
Princípios de Organização 96
Idioma e metadados 98
Funções e processos da equipe 101
CAPÍTULO 6
O avião esqueleto
Design de interface, design de navegação
e design de informação 106
Definindo o esqueleto 108
Convenção e Metáfora 110
Design de interface 114
Projeto de navegação 118
Design de Informação 124

Orientação 127
Estruturas de arame 128

OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO vii
CAPÍTULO 7
O Plano de Superfície
Design Sensorial 132
Definindo a Superfície 134
Dando sentido aos sentidos 135

Cheiro e Sabor 135
Toque 135
Audição 136
Visão 136
Siga o olho 137
Contraste e uniformidade 139
Consistência interna e externa 143
Paletas de cores e tipografia 145
Comps de design e guias de estilo 148
CAPÍTULO 8
Os Elementos Aplicados 152
Fazendo as perguntas certas 157
A Maratona e o Sprint 159
Índice 164
viii OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO
Sobre o autor
Jesse James Garrett é um dos fundadores do Adaptive Path, um
consultoria de experiência do usuário com sede em São Francisco. Desde 1995,
Jesse trabalhou em projetos Web para empresas como AT&T,
Intel, Boeing, Motorola, Hewlett-Packard e National Public
Rádio. Suas contribuições para o campo da experiência do usuário incluem a

Foto por: Colin Peck
Visual Vocabulary, um sistema de notação aberto para arquivos de informação
documentação de arquitetura que agora é usada por organizações ao redor
o mundo. Seu site pessoal em www.jjg.net é um dos
destinos mais populares para recursos de arquitetura da informação,
e ele é um palestrante frequente sobre arquitetura da informação e usuário
questões de experiência.
OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO ix
Agradecimentos para a segunda edição

Michael Nolan passou anos me incitando a fazer uma segunda edição. Dele
persistência - e sua ingenuidade em finalmente chegar a uma oferta que eu
não poderia deixar passar - são as razões pelas quais ela existe.
Na New Riders, a equipe de Rose Weisburd, Tracey Croom e Kim
Scott me manteve no caminho certo. Nancy Davis, Charlene Will, Hilal Sala e
Mimi Vitetta ajudou a fazer as coisas acontecerem. Obrigado também a Samantha
Bailey e Karl Fast pelo apoio.
Minha esposa, Rebecca Blood Garrett, continua sendo minha primeira, última e mais
editor de confiança, conselheiro e confidente.
Novas adições à trilha musical desta vez foram o Japão
bolos, Mono, Maserati, Tarentel, Pessoas Adormecidas, Códigos no
Nuvens e (especialmente) Explosões no Céu. Muito especial obrigado
a Steve Scarborough da Maserati pela orientação musical.
Agradecimentos pela primeira edição

Não se deixe enganar pelo número de nomes na capa - é preciso muito
de pessoas para fazer um livro acontecer.
Em primeiro lugar, tenho que agradecer aos meus parceiros da Adaptive Path: Lane Becker,
Janice Fraser, Mike Kuniavsky, Peter Merholz, Jeffrey Veen e
índio jovem. É através de sua indulgência que eu fui capaz de assumir
todo esse projeto.
Depois, há todos na New Riders, especialmente Michael Nolan,
Karen Whitehouse, Victoria Elzey, Deborah Hittel-Shoaf, John
Rahm e Jake McFarland. Sua orientação foi essencial para isso
processo.
x OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO
Kim Scott e Aren Howell deram um olhar aguçado e atenção aos detalhes
para o design deste livro. Sua paciência com as sugestões do
autor foi especialmente louvável.
Molly Wright Steenson e David Hoffer forneceram inestimáveis

em sua revisão do meu manuscrito. Todo autor deveria ter essa sorte.
Jess McMullin acabou sendo meu crítico mais duro em muitos aspectos,
e este livro é imensamente melhorado por sua influência.
Agradeço também aos autores mais experientes que me deram conselhos

sobre como lidar com um projeto como este e manter meu
sanidade: Jeffrey Veen (de novo), Mike Kuniavsky (de novo), Steve Krug,
June Cohen, Nathan Shedroff, Louis Rosenfeld, Peter Morville e
(especialmente) Steve Champeon.
Outros que ofereceram sugestões valiosas ou simplesmente boa moral

apoio incluiu Lisa Chan, George Olsen, Christina Wodtke,
Jessamyn West, Samantha Bailey, Eric Scheid, Michael Angeles,
Javier Velasco, Antonio Volpon, Vuk Cosic, Thierry Goulet e Dennis
Woudt. Eles pensaram em coisas que eu não fiz, e isso faz
eles o melhor tipo de colegas.
O acompanhamento musical para o processo de escrita foi fornecido por

Man or Astro-man?, Pell Mell, Mermen, Dirty Three, Trans Am, Tortoise,
Turing Machine, Don Caballero, Mogwai, Ui, Shadowy
Homens em um planeta sombrio, faça dizer pensar e (especialmente)
Godspeed You Imperador Negro!
OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO XI
Finalmente, há três pessoas sem as quais este livro

nunca aconteceram: Dinah Sanders, que em uma festa
A noite do Texas insistia que havia alguém que eu precisava conhecer; minha esposa,
Rebecca Blood, que me faz mais forte e mais sábia em todos os sentidos;
e Daniel Grassam, sem cuja amizade, encorajamento,
e suporte eu poderia não ter encontrado meu caminho para este negócio em
tudo. Obrigada.
Esta página foi intencionalmente deixada em branco

Introdução ao
Segunda edição
Vamos direto ao assunto: é a segunda edição. O que é diferente?
A principal diferença entre esta edição e a primeira é que esta
livro não é mais apenas sobre sites. Sim, a maioria dos exemplos são
ainda relacionados à Web, mas no geral, os temas, conceitos e princípios se aplicam
a produtos e serviços de todos os tipos.
Há duas razões para isso, ambas relacionadas ao que aconteceu nos últimos dez
anos. Uma é o que aconteceu com Elements,
e um é o que aconteceu com a experiência do usuário em si.
Ao longo dos anos, eu ouvi de (ou ouvi falar) de pessoas que
aplicou o modelo Elements a produtos que nada têm a ver com a Web. Em alguns
casos, eles eram web designers solicitados a assumir
algo novo, como um aplicativo móvel. Em outros casos, eram designers de outros
tipos de produtos que de alguma forma se depararam com
Elements e viu uma conexão com seu próprio trabalho.

xiv INTRODUÇÃO
Enquanto isso, o campo da experiência do usuário ampliou seus horizontes.
Os profissionais agora falam regularmente sobre o impacto e o valor da
experiência de design em áreas muito além do contexto limitado do
Web ou até mesmo aplicativos interativos baseados em tela que dominaram
a conversa quando este livro foi escrito pela primeira vez.
Esta nova edição do livro tem uma visão igualmente ampla. A teia
ainda é central para o livro, mesmo que apenas para reconhecer as raízes do modelo
nesse meio. Mas este livro não requer conhecimento de um insider
de como o desenvolvimento da Web acontece - mesmo que você não creia
em sites da Web, você deve ser capaz de ver como aplicar essas idéias em
seu próprio trabalho.
Apesar de tudo isso, aqueles de vocês que leram a primeira edição devem
tenha certeza: esta não é uma reinvenção radical. É uma lapidação e
refinamento do modelo Elements familiar que você conhece (e espera
totalmente amor), com as mesmas ideias centrais e filosofia intactas. o
pequenas coisas mudam, mas as grandes realmente não
Eu permaneço gratificado e humilhado por onde as pessoas tomaram
Elementos. Mal posso esperar para ver o que acontece a seguir!
Jesse James Garrett
Novembro de 2010
Introdução à
primeira edição
Este não é um livro de instruções. Há muitos, muitos livros por aí
que explicam como os sites são criados. Este não é um deles.
Este não é um livro sobre tecnologia. Não há uma única linha de

código a ser encontrado entre essas tampas.
Este não é um livro de respostas. Em vez disso, este livro trata de perguntar ao
perguntas certas.
Este livro lhe dirá o que você precisa saber antes de ler
esses outros livros. Se você precisa do quadro geral, se precisa
representam o contexto para as decisões que a prática da experiência do usuário
ners fazem, este livro é para você.
Este livro foi projetado para ser lido facilmente em apenas algumas horas. Se vocês são
um recém-chegado ao mundo da experiência do usuário - talvez você seja um
executivo responsável pela contratação de uma equipe de experiência do usuário, ou talvez
você é um escritor ou designer apenas encontrando seu caminho neste campo - este
livro lhe dará a base que você precisa. Se você já é familiar
com os métodos e preocupações do campo da experiência do usuário,

xvi INTRODUÇÃO
este livro irá ajudá-lo a comunicá-los de forma mais eficaz ao
pessoas com quem você trabalha.
A história por trás do livro

Porque me perguntam muito sobre isso, aqui está a história de como The Ele
mentos de Experiência do Usuário vieram a existir.
No final de 1999, tornei-me o primeiro arquiteto de informação contratado
uma consultoria de web design de longa data. De muitas maneiras, eu estava
responsável por definir minha posição e educar as pessoas tanto
sobre o que eu fiz, e como isso se encaixa com o que eles fizeram. Inicialmente,
talvez fossem cautelosos e um pouco cautelosos, mas logo
reconhecer que eu estava lá para tornar o trabalho deles mais fácil, não mais difícil, e
que minha presença não significava que sua autoridade foi diminuída.
Simultaneamente, eu estava compilando uma coleção pessoal de
material relacionado ao meu trabalho. (Isto acabaria por encontrar o seu caminho
na Web como minha página de recursos de arquitetura de informação em
www.jjg.net/ia/.) Enquanto fazia esta pesquisa, estava continuamente
frustrado pelo uso aparentemente arbitrário e aleatório de diferentes
termos para os conceitos básicos na área. O que uma fonte chamou
design da informação parecia ser o mesmo que outro chamou
arquitetura de informação. Um terceiro juntou tudo sob
design de interface.
Ao longo do final de 1999 e janeiro de 2000, lutei para chegar
em um conjunto auto-consistente de definições para essas preocupações e encontrar uma
forma de expressar as relações entre eles. Mas eu estava ocupado com
trabalho remunerado real também, e o modelo que eu estava tentando formular
não estava realmente dando certo de qualquer maneira; então no final de janeiro eu tinha
desistiu de toda a ideia.

OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO xvii
Naquele março eu viajei para Austin, Texas, para o South by
Festival Interativo Sudoeste. Foi um envolvimento e pensamento
semana provocadora durante a qual eu não dormi muito - o contra
agenda de atividades diurnas e noturnas da ference começa a se assemelhar a um
maratona depois de alguns dias.
No final daquela semana, enquanto caminhava pelo terminal do
aeroporto em Austin se preparando para embarcar no avião de volta a San Fran
Cisco, surgiu abruptamente na minha cabeça: uma matriz tridimensional
que captou todas as minhas ideias. Esperei pacientemente até embarcarmos
o avião. Assim que cheguei ao meu lugar, peguei um caderno e

esboçou tudo.
Ao retornar a São Francisco, fui quase imediatamente
com um frio de cabeça enervante. Passei cerca de uma semana deslizando e
de um delírio febril. Quando me senti particularmente lúcido, trabalhei
transformando meu esboço de caderno em um diagrama acabado que se encaixaria
cuidadosamente em um pedaço de papel tamanho carta. Eu o chamei de “Os Elementos da
Experiência de usuário." Mais tarde eu ouviria sobre como, para muitas pessoas,
esse título evocou memórias de tabelas periódicas e Strunk and White.
Infelizmente, nenhuma dessas associações estava em minha mente quando
escolhi esse título - escolhi elementos de um dicionário de sinônimos para substituir o
componentes mais desajeitados e técnicos .
Em 30 de março, publiquei o produto final na web. (Ainda está lá;
você pode encontrar o diagrama original em www.jjg.net/ia/elements.
pdf.) O diagrama começou a receber alguma atenção, primeiro de Peter
Merholz e Jeffrey Veen, que mais tarde se tornariam meus sócios na
Caminho Adaptativo. Logo depois, conversei com mais pessoas sobre isso no
primeira Cúpula de Arquitetura da Informação. Eventualmente eu comecei a ouvir
de pessoas de todo o mundo sobre como eles usaram o

xviii INTRODUÇÃO
diagrama para educar seus colegas de trabalho e dar às suas organizações
um vocabulário comum para discutir essas questões.
No ano seguinte ao seu lançamento, “The Elements of User Expe
rience” foi baixado do meu site mais de 20.000 vezes. EU
começou a ouvir sobre como estava sendo usado em grandes organizações
e pequenos grupos de desenvolvimento Web para ajudá-los a trabalhar e se comunicar
nicar de forma mais eficaz. A essa altura, eu estava começando a formular
a ideia de um livro que atendesse a essa necessidade melhor do que um único
folha de papel poderia.
Outra março rolou, e novamente me encontrei em Austin
para o Sul pelo Sudoeste. Lá eu conheci Michael Nolan de New Riders
Publishing e disse-lhe a minha ideia. Ele estava entusiasmado com isso, e
felizmente, seus chefes acabaram sendo também.
Assim, tanto por sorte quanto por intenção, este livro encontrou seu caminho
suas mãos. Espero que o que você faça com as ideias apresentadas aqui
é tão esclarecedor e gratificante para você quanto colocá-los juntos

neste livro foi para mim.
Jesse James Garrett
julho de 2002

capítulo 1
Experiência do
usuário e por que isso
Assuntos
OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO 3
Temos uma relação de dois gumes com os produtos e serviços
vícios que usamos. Eles nos fortalecem e nos frustram; eles simplificam e
complicar nossas vidas; eles nos separam e nos aproximam.
Mas apesar de interagirmos com inúmeros produtos e serviços
todos os dias, esquecemos facilmente que eles são feitos por pessoas, e que
alguém, em algum lugar, deve receber o crédito quando trabalha bem para
nós — ou levar a culpa quando eles não o fizerem.
Misérias do dia a dia
Todo mundo, de vez em quando, tem um dia desses.
Você sabe o tipo de dia que estou falando: você acorda com o sol
luz fluindo em sua janela e me pergunto por que seu despertador
ainda não apagou. Você olha para ver que seu relógio pensa que é
03:43 Você tropeça para fora da cama para encontrar outro relógio, que diz
que você ainda pode chegar ao trabalho a tempo - se você sair

10 minutos.
4 CAPÍTULO 1 EXPERIÊNCIA DO USUÁRIO E POR QUE É IMPORTANTE
Você liga a cafeteira e se apressa para se vestir, mas quando
você vai para recuperar sua dose de cafeína que sustenta a vida, não há
café no pote. Não há tempo para descobrir o porquê - você precisa
trabalhar!
Você fica a cerca de um quarteirão de sua casa quando percebe que o
carro precisa de gasolina. No posto de gasolina, você tenta usar a bomba que
aceita cartões de crédito, mas desta vez não aceitará o seu. Então você tem
para entrar e pagar o caixa, mas primeiro você tem que esperar na fila
enquanto o caixa ajuda muito lentamente todos na sua frente.
Você tem que fazer um desvio por causa de um acidente de trânsito, então a unidade
demora mais do que você esperava. É oficial: Apesar de todos os seus esforços,
agora você está atrasado para o trabalho. Finalmente, você chega à sua mesa. Você é
agitado, atormentado, cansado e irritável - e seu dia nem
realmente começou ainda. E você ainda não tomou café.
Apresentando a experiência do usuário
Parece uma sequência de azar – apenas um daqueles dias. Mas vamos
rebobine essa série de eventos, olhe mais de perto e veja se, de alguma forma, todos
que a má sorte poderia ter sido evitada.
O acidente: O acidente na estrada aconteceu porque o
motorista tirou os olhos da estrada por um momento para ligar o rádio
baixa. Ele teve que olhar para baixo porque era impossível identificar
que era o controle de volume apenas pelo toque.
A caixa registradora: A fila da caixa registradora do posto de gasolina se moveu tanto
lentamente porque a caixa registradora era complexa e confusa, e
a menos que o funcionário preste muita atenção ao tocar algo

para cima, ele cometeria um erro e teria que começar tudo de novo. Se o
registro foi mais simples e o layout e as cores dos botões
diferente, essa linha nunca teria se formado.
A bomba: Você não teria que ficar naquela fila se
a bomba aceitou seu cartão. Teria feito isso se você tivesse
virou o cartão para o outro lado para passá-lo, mas nada
a bomba indicou para que lado o cartão deve ser girado, e você
estavam com tanta pressa que você não pensou em tentar todas as orientações.
A cafeteira: A cafeteira não fez café porque
você não pressionou o botão liga / desliga até o fim. A máquina
não faz nada para que você saiba que foi ativado: não
luz, sem som, sem resistência que você pode sentir quando o botão faz
contato. Você pensou que tinha ligado, mas estava errado.
O problema poderia ter sido totalmente evitado se você tivesse definido o
cafeteira para começar a preparar automaticamente logo de manhã
ing, mas você nunca aprendeu a usar essa função - se você soubesse
existia em tudo. O visor na frente ainda está piscando 12:00.
O relógio: E agora chegamos ao fator que iniciou toda a
cadeia de eventos: o despertador. O alarme não disparou porque
a hora estava errada. A hora estava errada porque seu gato pisou
no relógio no meio da noite e redefina para você. (Se este
parece implausível para você, não ria — já aconteceu comigo.
Eu tive que ir a comprimentos surpreendentes para encontrar um relógio que é imperceptível
ante a intromissão de gatos.) Uma configuração ligeiramente diferente de botões
teria impedido o gato de acertar o relógio, e
muitas vezes você teria saído da cama com bastante tempo - não
precisa se apressar em tudo.

Em suma, cada um dos casos anteriores de “má sorte” poderia ter
sido evitado se alguém tivesse feito escolhas diferentes ao projetar um
produto ou serviço. Todos esses exemplos demonstram uma falta de atenção
ção à experiência do usuário: a experiência que o produto cria para
as pessoas que o usam no mundo real. Quando um produto está sendo
desenvolvido, as pessoas prestam muita atenção ao que ele faz. Do utilizador
a experiência é o outro lado, muitas vezes esquecido, da equação –
como funciona - que muitas vezes pode fazer a diferença entre um sucesso
produto cessful e uma falha.
A experiência do usuário não é sobre o funcionamento interno de um produto ou serviço
vício. A experiência do usuário é sobre como funciona do lado de fora, onde
uma pessoa entra em contato com ele. Quando alguém lhe pergunta o que
é como usar um produto ou serviço, eles estão perguntando sobre o usuário
experiência. É difícil fazer coisas simples? É fácil descobrir?
Como é interagir com o produto?
Essa interação geralmente envolve apertar muitos botões, como no
caso de produtos de tecnologia como despertadores, cafeteiras,
ou caixas registradoras. Às vezes, é apenas uma questão de um simples físico
mecanismo de cal, como a tampa do tanque do seu carro. No entanto, cada
produto que é usado por alguém cria uma experiência de usuário: livros,
garrafas de ketchup, poltronas reclináveis, suéteres de cardigã.
Para qualquer tipo de produto ou serviço, são as pequenas coisas que contam.
Ter um clique de botão quando você o pressiona não parece
muito, mas quando esse clique faz a diferença entre obter
tomar café e não tomar café, importa muito. Ainda que
você nunca percebeu que o design desse botão estava causando
problema, como você se sentiria sobre uma cafeteira que você estava
capaz de usar com sucesso apenas parte do tempo? Como você se sentiria
sobre o fabricante? Você compraria outro produto desse
empresa no futuro? Provavelmente não. Assim, por falta de um botão
que clica, um cliente é perdido.
Do design do produto ao design da experiência do usuário
Quando a maioria das pessoas pensa em design de produto (se pensa em
design de produto), muitas vezes pensam nisso em termos de estética
apelo: um produto bem projetado é aquele que parece bom aos olhos
e se sente bem ao toque. (Os sentidos do olfato e do paladar não
entram em jogo para a maioria dos produtos. O som é muitas vezes esquecido, mas
pode ser uma parte importante do apelo estético de um produto.)
Seja a curva da carroceria de um carro esportivo ou a textura de um
aperto da furadeira elétrica, a dimensão estética do design do produto é uma
certeza de chamar a atenção.
Outra maneira comum de as pessoas pensarem sobre design de produto é em
termos funcionais: Um produto bem projetado é aquele que faz o que
promete fazer. E um produto mal projetado é aquele que de alguma forma
não: tesoura que não corta mesmo com as lâminas afiadas,
uma caneta que não escreve mesmo estando cheia de tinta, uma impressora que
constantemente congestionamentos.
Todos estes podem certamente ser falhas de design. Esses produtos
pode parecer ótimo e funcionar bem funcionalmente, mas projetar produtos
uitos com a experiência do usuário como um resultado explícito significa olhar
além do funcional ou estético.
Algumas pessoas responsáveis pela criação de produtos podem não pensar em
termos de design em tudo. Para eles, o processo de criação de um produto é
sobre desenvolvimento: construindo e refinando constantemente os recursos

e funções do produto até que se somem a algo viável
no mercado.
Nessa visão, o design do produto é ditado por sua funcionalidade—
ou, como os designers às vezes colocam, “a forma segue a função”. este
abordagem faz todo o sentido para o funcionamento interno de um produto,
as partes ocultas de um usuário. Mas quando se trata das partes
um produto voltado para o usuário - os botões, telas, rótulos e
assim por diante—a forma “correta” não é ditada pela funcionalidade.
Em vez disso, é ditado pela psicologia e comportamento dos usuários

eles mesmos.
O design da experiência do usuário geralmente lida com questões de contexto.
O design estético garante que o botão da cafeteira seja um
forma e textura atraentes. O design funcional garante que ele trig
ger a ação apropriada no dispositivo. Projeto de experiência do usuário
garante que os aspectos estéticos e funcionais do botão funcionem
no contexto do resto do produto, fazendo perguntas como: “É
o botão muito pequeno para uma função tão importante?” Experiência do usuário
rience design também garante que o botão funcione no contexto de
o que o usuário está tentando realizar, fazendo perguntas como: “É
o botão no lugar certo em relação aos outros controles do usuário
estaria usando ao mesmo tempo?”
Projetando (para) experiência: o uso é importante
Qual é a diferença entre projetar um produto e projetar um
experiência de usuário? Afinal, todo produto destinado a humanos tem
um usuário, e cada vez que um produto é usado, ele entrega uma experiência.
Considere um produto simples, como uma cadeira ou uma mesa. Para usar o
cadeira onde você se senta; para usar a mesa você coloca outros objetos nela. Dentro
em ambos os casos, o produto pode não entregar uma experiência satisfatória:
se a cadeira não suportar o peso de uma pessoa, por exemplo, ou
a mesa é instável.
Mas os fabricantes de cadeiras e mesas tendem a não empregar
designers de experiência. Nestes casos simples, os requisitos para
entregar uma experiência de usuário bem-sucedida estão embutidos na definição
do produto em si: De certa forma, uma cadeira na qual você não pode sentar não é uma
cadeira em tudo.
Com produtos mais complexos, porém, os requisitos para entregar um
experiência de usuário bem-sucedida são independentes da definição do
produtos. Um telefone é definido por sua capacidade de colocar e/ou receber
chamadas; mas existem variações praticamente infinitas no telefone
que podem cumprir essa definição básica - com uma ampla variedade de
graus de experiência de usuário bem-sucedida.
E quanto mais complexo é um produto, mais difícil se torna
identificar exatamente como entregar uma experiência bem-sucedida ao usuário.
Cada recurso, função ou etapa adicional no processo de uso de um
produto cria outra oportunidade para a experiência ficar aquém.
Um telefone celular moderno tem muito mais funções do que um
telefone de mesa de, digamos, a década de 1950. Com isso, o processo de criação
um produto de sucesso tem que ser bem diferente. é aí que produto
o design deve ser apoiado pelo design da experiência do usuário.
Experiência do usuário e a Web
A experiência do usuário é vital para todos os tipos de produtos e serviços. este
livro é principalmente sobre a experiência do usuário de um tipo específico
do produto: sites. (Estou usando o termo site aqui para me referir a ambos
produtos da Web orientados a conteúdo e aplicativos da Web interativos.)

Na Web, a experiência do usuário se torna ainda mais importante do que
é para outros tipos de produtos. Mas as lições que aprendemos
criar experiências de usuário na Web pode ser aplicado muito além de sua
limites.
Web sites são peças complicadas de tecnologia, e algo
engraçado acontece quando as pessoas têm dificuldade em usar peças complicadas
da tecnologia: eles se culpam. Eles sentem que devem
ter feito algo errado. Eles sentem que não estavam pagando
atenção suficiente. Eles se sentem estúpidos. Claro, é irracional. Afinal,
não é culpa deles que o site não funcione da maneira que eles esperam.
Mas eles se sentem estúpidos de qualquer maneira. E se você pretende afastar as pessoas
do seu site (ou de qualquer produto), é difícil imaginar um
abordagem do que fazê-los sentir-se estúpidos quando a usam.
Independentemente do tipo de site, em praticamente todos os casos, um site
é um produto de autoatendimento. Não há manual de instruções para ler
de antemão, sem seminário de treinamento para participar, sem atendimento ao cliente
representante para ajudar a orientar o usuário através do site. Existe apenas
o usuário, enfrentando o site sozinho com apenas sua inteligência e experiência pessoal
paciência para guiá-la.
Diante de uma vasta gama

de escolhas, o usuário é
deixado para seus próprios dispositivos
para determinar qual fea
turas de um site vão atender
as necessidades dela.
Já é ruim o suficiente que ela tenha ficado presa na posição de ter que
descobrir o site por conta própria. O fato de que a maioria dos sites nem
reconhecer sua condição indefesa só piora as coisas.
Apesar da importância estratégica vital da experiência do usuário para o sucesso
acesso de um site, a simples questão de entender o que as pessoas
desejo e necessidade tem sido uma baixa prioridade para a maior parte da história da
o médio.
Se a experiência do usuário é uma parte tão vital de qualquer site, por que é tão
muitas vezes negligenciado no processo de desenvolvimento? Muitos sites são
construído com a ideia de que ser o primeiro no mercado é a chave para o sucesso.
Nos primeiros dias da Web, sites como o Yahoo! leads iniciais construídos
que os concorrentes posteriores lutaram para superar. Empresas estabelecidas
correu para criar sites, determinado a não ser percebido como
atrás dos tempos. Mas na maioria dos casos, as empresas consideradas meramente
ter implantado o site uma grande conquista; se o site
realmente funcionou para as pessoas foi, na melhor das hipóteses, uma reflexão tardia.
Para ganhar participação de mercado contra esses pioneiros, os concorrentes geralmente
adicione mais e mais conteúdo e funcionalidade na esperança de atrair
atrair novos clientes (e talvez roubar alguns clientes de
a competição). Esta corrida para colocar mais recursos em produtos é
dificilmente exclusivo da Web; de relógios de pulso a telefones celulares,
featurite é endêmica em muitas categorias de produtos.
Ter mais recursos, no entanto, acaba sendo apenas um
fonte de vantagem competitiva. Com a complexidade adicional que
vem com um conjunto de recursos em constante expansão, os sites se tornam
extremamente difícil de manejar, difícil de usar e pouco atraente para o primeiro
temporizadores que eles deveriam atrair. E ainda assim, muitas organizações
preste pouca atenção ao que os usuários gostam, acham valioso ou são realmente
capaz de usar.
Mais e mais empresas passaram a reconhecer essa oferta
Ter uma experiência de usuário de qualidade é uma competição essencial e sustentável
vantagem criativa - não apenas para sites da Web, mas para todos os tipos de produtos
e serviços. É a experiência do usuário que forma a impressão do cliente
sion das ofertas de uma empresa; é a experiência do usuário que diferencia
elimina uma empresa de seus concorrentes; e é a experiência do usuário que
determina se o seu cliente vai voltar.
Uma boa experiência do usuário é um bom negócio
Talvez você não venda nada em seu site. Tudo o que você fornece é
informações sobre sua empresa. Pode parecer que você tem um
monopólio sobre essa informação - se as pessoas querem, elas têm que obter
isso de você. Você não tem concorrência da mesma forma que um
livraria online faz. No entanto, você não pode se dar ao luxo de negligenciar o
experiência do usuário do seu site.
Se o seu site consiste principalmente no que os profissionais da Web chamam de conteúdo, ou seja,
informações—então um dos principais objetivos do seu site é
comunicar essa informação da forma mais eficaz possível. Não é o suficiente
apenas para colocá-lo lá fora. Tem que ser apresentado de uma forma que ajude
as pessoas o absorvem e o entendem. Caso contrário, o usuário pode não
descobrir que você oferece o serviço ou produto que eles procuram
por. E mesmo que eles consigam encontrar essa informação, eles estão
provavelmente chegará à conclusão de que, se seu site for difícil de trabalhar
com, sua empresa provavelmente também.
Mesmo que seu site seja um aplicativo baseado na Web que as pessoas possam usar para
realizar certas tarefas (como comprar passagens aéreas ou gerenciar
contas bancárias), a comunicação eficaz é um fator chave na

sucesso do seu produto. A funcionalidade mais poderosa do mundo
vacila e falha se os usuários não conseguem descobrir como fazê-lo funcionar.
Simplificando, se seus usuários tiverem uma experiência ruim, eles não virão
de volta. Se eles tiverem uma boa experiência com seu site, mas uma melhor
experiência com o site do seu concorrente, eles voltarão para aquele com
requerente, não você. Recursos e funções sempre importam, mas o usuário
experiência tem um efeito muito maior na fidelidade do cliente. Todo seu
tecnologia sofisticada e mensagens de marca não trarão esses
clientes de volta uma segunda vez. Uma boa experiência do usuário irá—e
você não tem uma segunda chance de acertar.
A fidelidade do cliente não é a única maneira de focar na experiência do usuário
riência do seu site pode valer a pena. Empresas de olho no bot
tom line quer saber sobre o retorno do investimento, ou ROI.
O ROI geralmente é medido em termos de dinheiro: para cada dólar que você
gastar, quantos dólares de valor você está recebendo de volta? Esse é o
ROI. Mas o retorno do investimento não precisa ser expresso em
termos estritamente monetários. Tudo que você precisa é de uma medida que mostre
que seu dinheiro saindo se traduz em valor para sua empresa.
Uma medida comum de retorno sobre o investimento é a taxa de conversão.
Sempre que você quiser incentivar seus clientes a tomar a próxima
passo na construção de um relacionamento com você - se isso envolve
algo tão complexo quanto personalizar o site de acordo com suas preferências
ou tão simples quanto se inscrever para receber um boletim informativo por e-mail - há
uma taxa de conversão que você pode medir. Ao acompanhar o que por
porcentagem de usuários que você converte para o próximo nível, você pode medir como
efetivamente seu site está atingindo suas metas de negócios.

A taxa de conversão é um
maneira comum de medir
a eficácia de uma experiência
do usuário.
3 inscrições de assinatura
÷
36 visitantes
=
taxa de conversão de 8,33%
A taxa de conversão torna-se ainda mais importante no caso de com
sites de merca. Muito mais pessoas navegam em um site de comércio do que compram de
isto. Uma experiência de usuário de qualidade é um fator chave na conversão desses
navegadores casuais em compradores ativos. Mesmo um pequeno aumento em seu
taxa de conversão pode se traduzir em um salto dramático na receita. Não é

incomum para uma mudança na taxa de conversão tão pequena quanto um décimo de
um por cento para resultar em um aumento de receita de dez por cento ou mais.
Em qualquer site onde os usuários tenham a oportunidade de lhe dar algumas
dinheiro, você tem uma taxa de conversão mensurável, quer você venda
livros, comida de gato ou assinaturas do conteúdo do próprio site.
A taxa de conversão pode dar a você uma melhor noção do retorno do seu
investimento na experiência do usuário do que simples números de vendas. As vendas podem
fer se você não for bem sucedido em divulgar seu site.
A taxa de conversão rastreia o seu sucesso em conseguir aqueles que
visitar para gastar algum dinheiro.
Mesmo que seu site não se adapte prontamente a uma métrica de ROI como
taxa de conversão, isso não significa o efeito da experiência do usuário sobre
seu negócio é menos significativo. Quer sejam usados pelo seu
clientes, seus parceiros ou seus funcionários, os sites podem ter todos

tipos de efeitos indiretos na linha de fundo.
Ninguém fora de sua empresa pode ver o site que você administra (como
no caso de uma ferramenta interna ou uma intranet), mas a experiência do usuário
ência ainda faz uma enorme diferença. Muitas vezes, pode significar a diferença
entre um projeto que cria valor para a organização e um
projeto que se torna um pesadelo que consome recursos.
Qualquer esforço de experiência do usuário visa melhorar a eficiência. Esta base
vem em duas formas principais: ajudar as pessoas a trabalhar mais rápido e ajudar
fazê-los cometer menos erros. Melhorando a eficiência do
ferramentas que você usa melhora a produtividade do negócio como um todo.
Quanto menos tempo leva para completar qualquer tarefa, mais você
pode ser feito em um dia. De acordo com a velha noção de que o tempo é
dinheiro, economizar o tempo de seus funcionários se traduz diretamente em economia
o dinheiro do seu negócio.

No entanto, a eficiência não afeta apenas o resultado final. Pessoas como
seus trabalhos mais quando suas ferramentas são naturais e fáceis de usar, não
frustrante e desnecessariamente complexo. Se essa pessoa é você, esses tipos
de ferramentas fazem a diferença entre voltar para casa satisfeito no
final do dia e chegar em casa exausto e odiando seu trabalho.
(Ou pelo menos, se você está voltando para casa exausto, é para a direita
razões - não porque você está lutando com suas ferramentas.)
Produtos de tecnologia
que não funcionam do jeito
as pessoas esperam fazer
eles se sentem estúpidos—
mesmo que eles finalmente
realizar o que eles

Disposto a fazer.
Se essa pessoa for seu funcionário, fornecer esses tipos de ferramentas
aumenta não só a sua produtividade, mas também a sua satisfação no trabalho,
tornando o empregado menos propenso a procurar um novo emprego. Isto por sua vez,
significa que você economiza em custos de recrutamento e treinamento, além de se beneficiar
do mais alto nível de qualidade que um mais dedicado, experiente
empregado traz para o seu trabalho.
Cuidando de seus usuários
A prática de criar experiências de usuário envolventes e eficientes é
chamado design centrado no usuário. O conceito de design centrado no usuário
é muito simples: Leve o usuário em consideração a cada passo do caminho,
você desenvolve seu produto. As implicações deste conceito simples,
no entanto, são surpreendentemente complexos.
Tudo o que o usuário experimenta deve ser o resultado de uma
decisão de sua parte. Realisticamente, você pode ter que fazer um com
promessa aqui e ali por causa do tempo ou despesa envolvida
na criação de uma solução melhor. Mas um processo de design centrado no usuário
garante que esses compromissos não aconteçam por acidente. Por
pensando na experiência do usuário, dividindo-a em suas
elementos componentes, e olhando para isso de várias perspectivas, você
pode garantir que você conheça todas as ramificações de suas decisões.
A maior razão pela qual a experiência do usuário deve ser importante para você é que ela
importa para seus usuários. Se você não fornecer a eles um resultado positivo
experiência, eles não usarão seu produto. E sem usuários, todos
você tem é um servidor Web empoeirado (ou armazém cheio de produtos)
em algum lugar, esperando ociosamente para cumprir um pedido que nunca virá.
Para os usuários que vierem, você deve se preparar para fornecê-los
com uma experiência coesa, intuitiva e talvez até
prazeroso - uma experiência em que tudo funciona do jeito que
deve. Não importa como foi o resto do dia deles.

capítulo 2
Conheça o
Elementos
O processo de design da experiência do usuário tem tudo a ver com garantir que nenhum
aspecto da experiência do usuário com seu produto acontece sem
sua intenção consciente e explícita. Isso significa levar em consideração
todas as possibilidades de todas as ações que o usuário provavelmente tomará e sob
atendendo as expectativas do usuário em cada etapa do processo
esse processo. Parece um grande trabalho, e de certa forma é. Mas
dividindo o trabalho de criar a experiência do usuário em seu
elementos componentes, podemos entender melhor a tarefa como um todo.
Os Cinco Planos
A maioria das pessoas, uma vez ou outra, comprou um
produto pela Web. A experiência é praticamente a mesma
toda vez: você vai ao site, encontra o item que deseja (talvez
usando um mecanismo de pesquisa ou talvez navegando em um catálogo), você dá
o site seu número de cartão de crédito e seu endereço, e o site
confirma que o produto será enviado para você.

20 CAPÍTULO 2 CONHEÇA OS ELEMENTOS
Essa experiência limpa e organizada na verdade resulta de todo um conjunto de
decisões - algumas pequenas, outras grandes - sobre a aparência do site, como
ele se comporta, e o que ele permite que você faça. Essas decisões se baseiam
uns aos outros, informando e influenciando todos os aspectos da experiência do usuário
riência. Se retirarmos as camadas dessa experiência, podemos começar
para entender como essas decisões são tomadas.
Na superfície você vê uma série de páginas da Web, compostas de imagens
e texto. Algumas dessas imagens são coisas nas quais você pode clicar, por
formando algum tipo de função, como levá-lo a um carrinho de compras.
Algumas dessas imagens são apenas ilustrações, como uma fotografia de
um produto à venda ou o logotipo do próprio site.
O avião esqueleto
Abaixo dessa superfície está o esqueleto do local: a colocação de
botões, controles, fotos e blocos de texto. O esqueleto é projetado
para otimizar o arranjo desses elementos para efeito máximo
e eficiência - para que você se lembre do logotipo e possa descobrir que
botão do carrinho de compras quando você precisar.
O esqueleto é uma expressão concreta da estrutura mais abstrata
do sítio. O esqueleto pode definir o posicionamento da interface
elementos em nossa página de checkout; a estrutura definiria como
os usuários chegaram a essa página e para onde poderiam ir quando estivessem
ido lá. O esqueleto pode definir o arranjo da navegação
elementos cionais que permitem aos usuários navegar por categorias de produtos;
a estrutura definiria quais eram essas categorias.

O Plano do Escopo
A estrutura define a maneira pela qual os vários recursos e
funções do site se encaixam. Apenas o que esses recursos e
funções são constitui o escopo do site. Por exemplo, alguns
sites de comércio oferecem um recurso que permite que os usuários salvem
endereços de entrega usados para que possam ser usados novamente. Seja isso
recurso — ou qualquer recurso — está incluído em um site é uma questão de escopo.
O escopo é fundamentalmente determinado pela estratégia do site.
Esta estratégia incorpora não só o que as pessoas que dirigem o
site quer sair dele, mas o que os usuários querem sair do
local também. No caso do nosso exemplo de loja, algumas das estratégias
objetivos são bastante óbvios: os usuários querem comprar produtos, e nós
quer vendê-los. Outros objetivos, como o papel que a publicidade
ou conteúdo produzido por nossos usuários desempenha em nosso modelo de negócios,
por exemplo - pode não ser tão fácil de articular.
Construindo de baixo para cima

Esses cinco planos – estratégia, escopo, estrutura, esqueleto e superfície –
fornecer uma estrutura conceitual para falar sobre a experiência do usuário
problemas e as ferramentas que usamos para resolvê-los.
Em cada plano, as questões com as quais devemos lidar tornam-se um pouco menos
abstrato e um pouco mais concreto. No plano mais baixo, não estamos
preocupado com a forma final do site, produto ou serviço em
tudo - só nos preocupamos em como o site se encaixará em nossa estratégia (enquanto
atender às necessidades de nossos usuários). No plano mais alto, somos apenas
preocupado com os detalhes mais concretos da aparência do
produtos. Avião a avião, as decisões que temos que tomar tornam-se um
pouco mais específicos e envolvem níveis mais sutis de detalhes.

Concreto
Abstrato
Cada plano depende dos planos abaixo dele. Então, a superfície
depende do esqueleto, que depende da estrutura, que
depende do escopo, que depende da estratégia. Quando o
escolhas que fazemos não se alinham com aquelas acima e abaixo, projetos
descarrilam, os prazos são perdidos e os custos começam a disparar à medida que o
equipe de desenvolvimento tenta juntar componentes que não
naturalmente apto. Pior ainda, quando o produto finalmente é lançado,
os usuários geralmente odeiam, porque não oferece uma experiência satisfatória.
Essa dependência significa que as decisões no plano estratégico serão
tem uma espécie de “efeito cascata” em toda a cadeia. Por outro lado,
as escolhas disponíveis para nós em cada plano são restringidas pelo
decisões que tomamos sobre questões nos planos abaixo dele.

gama de opções disponíveis no próximo plano As escolhas que você faz
em cada plano afetam

as opções disponíveis para
você no próximo avião

acima dele.
a opção que você escolheu
gama de escolhas possíveis
Esse efeito cascata
significa que escolher uma
opção “fora dos limites” em
um plano superior exigirá
repensar
decisões de menor
aviões.
Isso não significa, no entanto, que toda decisão sobre um menor
plano deve ser feito antes que o plano acima dele possa ser endereçado.
As dependências correm em ambas as direções, com decisões tomadas nos níveis superiores.
aviões às vezes forçando uma reavaliação (ou uma avaliação feita para
primeira vez!) de problemas em planos inferiores. Em cada nível, fazemos
decisões de acordo com o que a concorrência está fazendo, as melhores
práticas, o que sabemos sobre nossos usuários e o velho e comum
senso. Essas decisões podem ter um efeito cascata em ambas as direções.
Exigindo trabalho em
cada plano para terminar

antes de trabalhar no
próximo pode começar leva a
resultados insatisfatórios
para você e seus usuários.
Tempo
Uma abordagem melhor é

ter trabalho em cada
avião terminar antes do trabalho

no próximo pode terminar.
Tempo
Se você considerar que suas decisões em planos inferiores serão gravadas em pedra
antes de tomar suas decisões nos planos superiores, você quase
certamente estará jogando seu cronograma de projeto - e possivelmente o sucesso
cesso de seu produto final - em perigo.
Em vez disso, você deve planejar seu projeto para que funcione em qualquer plano
não pode terminar antes de terminar o trabalho nos planos inferiores. A importação
importante consideração aqui é não construir o telhado da casa antes
você conhece a forma de sua fundação.

Uma Dualidade Básica
Claro, existem mais do que apenas cinco elementos da experiência do
usuário e, como em qualquer campo especializado, este desenvolveu um vocabulário
tudo próprio. Para alguém que encontra o campo pela primeira vez, a
experiência do usuário pode parecer um negócio complicado. Todos estes
termos aparentemente idênticos são usados: design de interação, design de
informação, arquitetura de informação. O que eles querem dizer?
Nada? Ou são apenas chavões da indústria sem sentido?
Para complicar ainda mais as coisas, as pessoas usarão os mesmos termos em
jeitos diferentes. Uma pessoa pode usar “design da informação” para se referir
ao que outro conhece como “arquitetura da informação”. E o que é
a diferença entre “design de interface” e “design de interação?”

Existe um?
Quando a Web começou, era tudo sobre informação. As pessoas podiam
criar documentos e vinculá-los a outros documentos.
Tim Berners-Lee, o inventor da Web, a criou como um caminho para
pesquisadores da comunidade de física de alta energia, que estavam
espalhados por todo o mundo, para compartilhar e consultar as descobertas
uns dos outros. Ele sabia que a Web tinha potencial para ser muito mais do que
isso, mas poucos realmente entenderam o quão grande era o seu potencial.
As pessoas originalmente aproveitaram a Web como um novo meio de publicação,
mas como a tecnologia avançou e novos recursos foram adicionados à Web

navegadores e servidores Web, a Web assumiu novos
capacidades. Depois que a Web começou a se popularizar na comunidade
maior da Internet, ela desenvolveu um conjunto de recursos mais complexo e robusto que
permitiria aos sites não apenas distribuir informações, mas também coletá-
las e manipulá-las. Com isso, a Web tornou-se mais

interativo, respondendo à entrada dos usuários de maneiras que se baseiam em
e, às vezes, indo além dos aplicativos de desktop tradicionais.
Com o advento dos interesses comerciais na Web, este aplicativo
funcionalidade de tion encontrou uma ampla gama de usos, como
comércio, mídias sociais e serviços financeiros, entre outros.
Enquanto isso, a Web continuou a florescer como meio de publicação,
com inúmeros sites de jornais e revistas que aumentam a
onda de blogs somente na Web e “e-zines” sendo publicados. Tecnologia
ogy continuou a avançar em ambas as frentes, já que todos os tipos de sites
a transição de coleções estáticas de informações que mudaram
raramente para sites dinâmicos baseados em banco de dados que eram constantemente
evoluindo.
Quando a comunidade de experiência do usuário da Web começou a se formar, sua
membros falavam duas línguas diferentes. Um grupo viu todos os problemas
lem como um problema de design de aplicativo e solução de problemas aplicada
abordagens do software tradicional de desktop e mainframe
os mundos. (Estes, por sua vez, estavam enraizados em práticas comuns aplicadas
para criar todos os tipos de produtos, de carros a tênis de corrida.)
outro grupo via a Web em termos de distribuição de informações e
recuperação e abordagens de solução de problemas aplicadas da tradição
mundos internacionais de publicação, mídia e ciência da informação.
Isso se tornou um grande obstáculo. Muito pouco progresso poderia ser
feito quando a comunidade não conseguia nem concordar com o terminol básico
ogia. As águas ficaram ainda mais turvas pelo fato de que a maioria da Web
os sites não podiam ser categorizados como um aplicativo funcional
ções ou recursos de informação - um grande número parecia ser uma espécie de
de híbridos, incorporando qualidades de cada mundo.

Para abordar essa dualidade básica na natureza da Web, vamos dividir
nossos cinco aviões no meio. À esquerda, vamos colocar aqueles ele
específicos da Web como plataforma de funcionalidade. No
certo, vamos colocar os elementos específicos da Web como uma informação

médio.
produto como funcionalidade

cionalidade produto como informação
Concreto
Abstrato
No lado da funcionalidade, estamos principalmente preocupados com tarefas—
as etapas envolvidas em um processo e como as pessoas pensam sobre
preenchê-los. Aqui, consideramos o produto como uma ferramenta ou conjunto de ferramentas
que o usuário emprega para realizar uma ou mais tarefas.
Do lado oposto, nossa preocupação é com quais informações o produto
ofertas e o que isso significa para nossos usuários. Criando um site rico em informações
experiência do usuário é permitir que as pessoas encontrem, absorvam e façam
sentido das informações que fornecemos.
Os elementos da experiência do usuário
Agora podemos mapear todo esse conjunto confuso de termos no
modelo. Ao quebrar cada plano em seus elementos componentes,
poderemos ver mais de perto como todas as peças se encaixam
no curso de projetar toda a experiência do usuário.
As mesmas preocupações estratégicas entram em jogo tanto para a funcionalidade
produtos orientados e recursos orientados para a informação. Necessidades do usuário
são os objetivos do site que vêm de fora da nossa organização—
especificamente das pessoas que usarão nosso site. Devemos sob
entender o que nosso público quer de nós e como isso se encaixa
outros objetivos que eles têm.
Equilibrados com as necessidades do usuário são nossos próprios objetivos para o site.
Esses objetivos do produto podem ser metas de negócios (“Ganhar US$ 1 milhão
em vendas pela Web este ano”) ou outros tipos de metas (“Informar
eleitores sobre os candidatos nas próximas eleições”). No Capítulo 3
entraremos em mais detalhes sobre esses elementos.


Concreto
superfície
esqueleto
estrutura
Contente onal Funcional

Requisitos
nós
alcance
Especificações
nt
e
estratégia
Abstrato
O Plano do Escopo
Do lado da funcionalidade, a estratégia é traduzida em escopo
através da criação de especificações funcionais: uma
descrição do “conjunto de recursos” do produto. Sobre as informações
lado, o escopo assume a forma de requisitos de conteúdo: uma descrição
dos vários elementos de conteúdo que serão necessários. O capítulo 4 vai
cobrir os elementos do escopo.

O escopo recebe estrutura no lado da funcionalidade por meio de
design de interação, no qual definimos como o sistema se comporta
em resposta ao usuário. Para recursos de informação, a estrutura é
a arquitetura da informação: o arranjo dos elementos de conteúdo
para facilitar a compreensão humana. Você encontrará mais detalhes
sobre isso no Capítulo 5.
O avião esqueleto
O plano do esqueleto se divide em três componentes. Sobre
ambos os lados, devemos abordar o design da informação: a apresentação
informação de uma forma que facilite a compreensão. Por
produtos orientados à funcionalidade, o esqueleto também inclui
design de rosto ou organizando elementos de interface para permitir que os usuários
interagir com a funcionalidade do sistema. A interface para um
recurso de informação é o seu design de navegação: o conjunto de telas
elementos que permitem ao usuário percorrer as informações
arquitetura. Há mais sobre o plano do esqueleto no Capítulo 6.
Por fim, temos a superfície. Independentemente de estarmos lidando
com um produto orientado à funcionalidade ou um recurso de informação,
nossa preocupação aqui é a mesma: a experiência sensorial criada
o produto acabado. É mais complicado do que parece; Você pode descobrir
tudo sobre isso no Capítulo 7.

Usando os elementos
Esse modelo, dividido em caixas e planos organizados, é uma maneira conveniente
de pensar nos problemas de experiência do usuário. Na realidade, é claro,
as linhas entre essas áreas não são tão claramente traçadas. Frequentemente, pode
ser difícil identificar se uma experiência de usuário específica
problema é melhor resolvido através da atenção a um elemento em vez de outro.
Uma mudança no visual pode resolver o problema, ou o
o design de navegação subjacente precisa ser retrabalhado? Alguns problemas
requerem atenção em várias áreas ao mesmo tempo, e alguns parecem
atravessam as fronteiras identificadas neste modelo.
Poucos produtos ou serviços caem exclusivamente em um lado desse modelo
ou o outro. Dentro de cada plano, os elementos devem trabalhar juntos para atingir
os objetivos daquele plano. Separando os efeitos das decisões
você faz cerca de um elemento de todos os outros elementos no plano é muito
difícil. Por exemplo, design de informação, design de navegação,
e design de interface definem conjuntamente o esqueleto de um produto. Todos os
elementos em cada plano têm uma função comum na determinação
a maior experiência do usuário - neste caso, definindo o esqueleto do produto -
mesmo que eles executem essa função de maneiras diferentes.
A maneira como as organizações delegam a responsabilidade por problemas de
experiência do usuário geralmente complica ainda mais as coisas. Em algumas organizações, você
encontrará pessoas com cargos como arquiteto de informações ou designer de
interface. Não se confunda com isso. Essas pessoas geram
Todos possuem conhecimentos que abrangem muitos dos elementos da
experiência do usuário, não apenas a especialidade indicada pelo título. Não é necessário
ter em sua equipe um membro especialista em cada uma dessas áreas; em vez
disso, você só precisa garantir que alguém gaste pelo menos
parte do seu tempo pensando em cada uma dessas questões.

Alguns fatores adicionais influenciam a experiência do usuário final
ência que você não encontrará coberto em detalhes aqui. A primeira delas é
contente. O velho ditado (bem, velho nos anos da Web) é que “conteúdo é
rei” na web. Isso é absolutamente verdade - o mais importante
coisa importante que a maioria dos sites da Web pode oferecer a seus usuários é o conteúdo que
esses usuários acharão valiosos.
Os usuários não visitam sites da Web para experimentar a alegria da navegação. o
conteúdo que está disponível para você (ou que você tem recursos para obter
e gerenciar) desempenhará um papel importante na formação do seu site. Dentro do estojo
de uma loja online, podemos decidir que queremos que os usuários sejam
capaz de ver imagens de capa de todos os livros que vendemos. Se os conseguirmos,
teremos uma maneira de catalogá-los, acompanhá-los e manter
eles atualizados? E se não conseguirmos fotos do livro cov
er em tudo? Essas perguntas de conteúdo são essenciais para o usuário final
experiência do local.
Em segundo lugar, a tecnologia pode ser tão importante quanto o conteúdo na criação.
tando uma experiência de usuário bem-sucedida. Em muitos casos, a natureza
a experiência que você pode fornecer aos seus usuários é amplamente determinada
pela tecnologia. Nos primórdios da Web, as ferramentas para conectar
Web sites para bancos de dados eram bastante primitivos e limitados. Enquanto o
tecnologia avançou, no entanto, os bancos de dados tornaram-se mais
amplamente utilizado para conduzir sites. Isso, por sua vez, permitiu mais e mais
abordagens de experiência do usuário mais sofisticadas, como dinâmicas
sistemas de navegação que mudam em resposta à forma como os usuários se movem
através do site. A tecnologia está sempre mudando, e o campo de
a experiência do usuário sempre tem que se adaptar a ela. Apesar disso, o Fundo
elementos mentais da experiência do usuário permanecem os mesmos.

Embora eu tenha desenvolvido o modelo Elements no decorrer do meu trabalho
em sites, outros o aplicaram desde então a uma ampla gama de produtos
utos e serviços. Se você trabalha na Web, tudo neste livro
se aplica a você. Se você trabalha em outros tipos de produtos de tecnologia,
você verá fortes paralelos com considerações familiares. Mesmo se você
trabalhar em produtos ou serviços que não têm nada a ver com tecnologia
ogy, você pode mapear esses conceitos para seus próprios processos.
O restante deste livro examina esses elementos, plano por plano, em
maior detalhe. Vamos dar uma olhada em algumas das ferramentas e tecnologia
nicas comumente usadas para abordar cada elemento. Pelo caminho,
veremos como esses elementos entram em jogo em produtos que não são
Web sites em tudo. Veremos o que os elementos em cada plano têm em
comuns, o que torna cada um diferente e como eles afetam cada
outros para nos ajudar a criar a experiência total do usuário.

capítulo 3
A estratégia
Avião
Objetivos do produto e necessidades do usuário
Superfície
Esqueleto
Estrutura
A base de uma experiência de usuário bem-sucedida é
uma estratégia claramente articulada. Sabendo tanto o que

Alcance
queremos que o produto realize para nossos organi
Estratégia
zação e o que queremos que ela realize para nossos
usuários informa as decisões que temos que tomar sobre
todos os aspectos da experiência do usuário. Mas responda
responder a essas perguntas simples pode ser mais complicado do que
parece.
Interação tivemos
formação
Em
Projeto Arquitetura ré
Contente
Requisitos
Funcional
Especificações
nt
e
36 CAPÍTULO 3 O PLANO DE ESTRATÉGIA
Definindo a Estratégia
A razão mais comum para o fracasso de um site não é a tecnologia
nologia. Também não é experiência do usuário. Os sites da Web geralmente falham
porque - antes que a primeira linha de código fosse escrita, o primeiro pixel fosse
enviado ou o primeiro servidor fosse instalado - ninguém se preocupou em
responder a duas perguntas muito básicas:
. O que queremos com este produto?
. O que nossos usuários querem com isso?

alcance
estratégia
Ao responder à primeira pergunta, descrevemos os objetivos do produto vindos
de dentro da organização. A segunda pergunta
atende às necessidades do usuário, objetivos impostos ao produto de fora.
Juntos, os objetivos do produto e as necessidades do usuário formam a estratégia
egy plane, a base para todas as decisões em nosso processo à medida que
projetamos a experiência do usuário. No entanto, surpreendentemente, a experiência de muitos
os projetos não começam com um entendimento claro e explícito da estratégia
subjacente.
A palavra-chave aqui é explícita. Quanto mais claramente pudermos articular
exatamente o que queremos, e exatamente o que os outros querem de nós, o
mais precisamente, podemos ajustar nossas escolhas para atingir esses objetivos.
Objetivos do produto
A primeira parte de tornar nossa estratégia explícita é examinar nossos próprios
objetivos do produto ou serviço. Muitas vezes, os objetivos do produto
existe apenas como um entendimento tácito entre aqueles que constroem o
produtos. Quando esse entendimento permanece não dito, diferentes
as pessoas geralmente têm ideias diferentes sobre o que o produto é oferecido
posta para realizar.
Objetivos de negócios
As pessoas costumam usar termos como metas de negócios ou impulsionadores de negócios
para descrever objetivos estratégicos internos. vou usar o termo
objetivos do produto porque esses outros termos são muito restritos e
muito amplo: muito estreito porque nem todo objetivo interno é um negócio
objetivo (afinal, nem toda organização tem os mesmos tipos de objetivos
que as empresas fazem), e muito ampla porque nossa preocupação aqui realmente
é identificar nos termos mais específicos possíveis o que esperamos do
próprio produto para realizar, independentemente do resto do nosso negócio
Atividades.
A maioria das pessoas começa descrevendo os objetivos de seus produtos em
termos muito gerais. No caso dos sites, eles fundamentalmente
servir a um de dois propósitos: fazer dinheiro para a empresa ou economizar
o dinheiro da empresa. Às vezes são os dois. Mas exatamente como esses
sites devem fazer isso nem sempre é claro.

Por outro lado, objetivos muito específicos não
descrever as preocupações estratégicas em questão. Por exemplo, afirmando que
um de seus objetivos é “fornecer aos usuários uma comunicação de texto em tempo real
ferramenta de comunicação” não explica como tal ferramenta ajuda a avançar
os objetivos de sua organização, ou como ela ajuda a atender às necessidades
de seus usuários.
Ao tentar encontrar um equilíbrio entre ser muito específico e ser
muito geral, queremos evitar saltar à frente para identificar soluções
quando ainda não compreendemos completamente os problemas. Para criar um sucesso
experiência do usuário, temos que garantir que todas as decisões
fazemos está enraizado em uma firme compreensão de suas consequências.
Definir claramente as condições para o sucesso - sem definir o
caminho para chegar lá - garante que não nos precipitemos.
Identidade da marca
Uma consideração essencial na formulação dos objetivos para qualquer
produto é a identidade da marca. Quando a maioria de nós vê a palavra branding,
pensamos em coisas como logotipos, paletas de cores e tipografia. Enquanto
esses aspectos visuais da marca são importantes (vamos revisitá-los em
mais detalhes quando chegarmos ao plano da superfície no Capítulo 7), o
conceito de marca vai muito além do visual. Identidade da marca - um
conjunto de associações conceituais ou reações emocionais - é importante
porque é inevitável. Na mente de seus usuários, uma impressão
sobre sua organização é inevitavelmente criado por suas interações
com seu produto.
Você deve escolher se essa impressão acontece por acidente ou
como resultado de escolhas conscientes que você fez ao projetar seu
produtos. A maioria das organizações opta por exercer algum controle sobre o
percepção de sua marca, e é por isso que comunicar a marca
identidade é um objetivo de produto muito comum. Branding não é apenas para
entidades comerciais - todas as organizações com um site,
de fundações sem fins lucrativos a agências governamentais e indivíduos,
cria uma impressão através da experiência do usuário. Ao codificar o
qualidades específicas dessa impressão como um objetivo explícito, você
aumentar suas chances de que será uma impressão positiva.
Métricas de sucesso
As corridas têm linhas de chegada. Uma parte importante da compreensão do seu
objetivos é entender como você saberá quando tiver
os alcançou.
Elas são conhecidas como métricas de sucesso: indicadores que podemos acompanhar após
o produto foi lançado para ver se está atendendo aos nossos
próprios objetivos e as necessidades de nossos usuários. Definindo boas métricas de sucesso
não influencia apenas as decisões tomadas ao longo do projeto;
alcançá-los fornece evidências concretas do valor do usuário
experimente esforços se você se deparar com um público cético
ao buscar aprovação de orçamento para seu próximo projeto de experiência do usuário.
Às vezes, essas métricas estão relacionadas ao próprio produto e como
é usado. Quanto tempo o usuário médio gasta em seu site
durante cada visita? (As ferramentas de análise podem ajudá-lo a determinar isso.) Se
você deseja incentivar seus usuários a se sentirem confortáveis com o site,
sair e explorar o que você tem a oferecer, você vai querer ver o
aumento do tempo por visita. Por outro lado, se você deseja fornecer
acesso rápido e direto a informações e funcionalidades, você
pode querer diminuir o tempo por visita.

As métricas de sucesso são

10
indicadores concretos de
com que eficácia a 9
experiência do usuário está

8 alvo
atendendo aos objetivos
estratégicos. Neste exemplo, medindo7

o número de visitas
por usuário registrado por 6
mês indica como

5
valioso o site é para
seu público-alvo. 4
2
lançamento de
1 site redesenhado
Jan Fev Mar Abr Mai Jun Jul Ago Set Out Nov Dez
visitas por mês (somente usuários registrados)
Para sites que dependem de receita de publicidade, impressões—o
número de vezes por dia que um anúncio é veiculado a um usuário - é um
métrica muito importante. Mas você tem que ter cuidado para equilibrar seu
objetivos e as necessidades de seus usuários. Adicionando várias camadas de
páginas de navegação entre a página inicial e os usuários de conteúdo
deseja certamente aumentará suas impressões de anúncios, mas está veiculando
necessidades do usuário? Provavelmente não. E, a longo prazo, mostrará: Como seu
os usuários ficam frustrados e decidem não voltar, suas impressões
cairá dessa alta inicial e provavelmente terminará abaixo
eles eram quando você começou.

Nem todas as métricas de sucesso precisam ser derivadas diretamente do seu site.
Você também pode medir os efeitos indiretos do site. Se o seu site
fornece soluções para problemas comuns que as pessoas encontram
seu produto, o número de chamadas telefônicas que chegam ao seu cliente
linhas de suporte de tomer devem descer. Uma intranet eficaz pode
vide acesso imediato a ferramentas e recursos que podem reduzir o
tempo que seus vendedores levam para fechar uma venda, o que, por sua vez,
se traduz diretamente em aumento de receita.
Para que as métricas de sucesso impulsionem significativamente a decisão da experiência do usuário
sions, essas métricas devem estar claramente vinculadas a aspectos do comportamento do usuário
que podem ser moldados por nossas escolhas de design. Claro, quando uma rede
assinam lançamentos e receita diária de transações online salta 40
por cento, é fácil ver a relação entre causa e efeito.
Mas para mudanças que acontecem por um longo período de tempo, pode
ser difícil identificar se essas alterações se originam do usuário
experiência ou de outros fatores.
Por exemplo, a experiência do usuário do seu site não pode fazer muito por si só
para trazer novos usuários ao seu site - você terá que confiar na palavra de
boca ou seus esforços de marketing para isso. Mas a experiência do usuário

tem muita influência sobre se esses visitantes voltarão.
Medir as revisitas pode ser uma ótima maneira de avaliar se você está
atender às necessidades do usuário, mas tenha cuidado: às vezes, esses usuários não
volte porque seu concorrente lançou uma gigantesca propaganda
campanha ou porque sua empresa acabou de receber uma má publicidade. Algum
métrica vista isoladamente pode ser enganosa; certifique-se de dar um passo
voltar e ver o que está acontecendo além do site para ter certeza
você está recebendo toda a história.

Necessidades do usuário
Pode ser fácil cair na armadilha de pensar que estamos projetando nosso produto
ou serviço para um usuário idealizado - alguém exatamente como
nós. Mas não estamos projetando para nós mesmos; estamos projetando para
outras pessoas, e se essas outras pessoas vão gostar e usar o que nós
criar, precisamos entender quem eles são e o que eles precisam.
Ao gastar tempo pesquisando essas necessidades, podemos sair de nossa
própria perspectiva limitada e ver o site do ponto de vista de
os usuários.
Identificar as necessidades do usuário é complicado porque os usuários podem ser
bastante diversos. Mesmo se estivermos criando um site para uso dentro de nossa organização
nização, talvez ainda tenhamos que atender a uma ampla gama de necessidades.
Se estivermos criando um aplicativo móvel destinado a um público consumidor, o
possibilidades aumentam exponencialmente.
Para chegar ao fundo dessas necessidades, temos que definir exatamente quem
nossos usuários são. Uma vez que sabemos quem estamos tentando alcançar,
podemos realizar pesquisas com eles - em outras palavras, fazer perguntas
e observar o seu comportamento. Essa pesquisa pode nos ajudar a definir e priorizar
o que as pessoas precisam quando usam nosso produto.
Segmentação de usuários
Podemos dividir essa massa de necessidades do usuário em partes gerenciáveis
por meio da segmentação de usuários. Dividimos nosso público em
grupos menores (ou segmentos) consistindo de usuários com certas características-
chave em comum. Há quase tantas maneiras de segmentar
ment grupos de usuários, pois existem tipos de usuários, mas aqui estão algumas
das abordagens mais comuns.

A segmentação do
usuário nos ajuda a
entender melhor as
necessidades do usuário, dividindo todo o

audiência em menor
grupos de pessoas com

necessidades compartilhadas.
Os pesquisadores de mercado geralmente criam segmentos de público com base
em critérios demográficos: sexo, idade, nível educacional, estado civil,
renda, e assim por diante. Esses perfis demográficos podem ser bastante gerais
(homens de 18 a 49 anos) ou muito específicos (mulheres solteiras, com formação universitária
25-34 ganhando mais de $ 50.000 por ano).

A demografia não é a única maneira de analisar seus usuários.
Os perfis psicográficos descrevem as atitudes e percepções que
seus usuários têm sobre o mundo ou sobre o assunto de
seu site em particular. A psicografia muitas vezes se correlaciona fortemente com
demografia: pessoas na mesma faixa etária, localização e renda
nível muitas vezes têm atitudes semelhantes. Mas em muitos casos, a demografia
pessoas supostamente idênticas têm maneiras muito diferentes de ver e interagir
atuando com o mundo. (Basta pensar em todos que você foi para o alto
escola com.) É por isso que descobrir os psicográficos de sua
os usuários podem fornecer informações que você não pode obter dos dados demográficos.
Ao desenvolver um site ou qualquer produto de tecnologia, há
outro conjunto muito importante de atitudes a considerar: a atitude dos usuários
tendências para a Web e a própria tecnologia. Quanto tempo faz
seus usuários gastam usando a Web toda semana? A tecnologia faz parte
suas vidas diárias? Eles gostam de trabalhar com produtos de tecnologia?
Eles sempre têm os melhores e mais recentes produtos, ou eles
só atualizam quando precisam? Tecnofóbicos e usuários avançados
abordar sites da Web de maneiras muito diferentes, e nossos projetos precisam
acomodá-los. Respostas a perguntas como essas podem nos ajudar
faça apenas isso.
Além de entender a familiaridade e o conforto de nossos usuários
nível de tecnologia, precisamos entender o que e quanto
eles sabem sobre o assunto do nosso site. Vendo panelas para
as pessoas que estão aprendendo o caminho de uma cozinha devem ser tratadas
muito diferente de vender para cozinheiros profissionais. Da mesma forma, um estoque
aplicativo de negociação usado por quem não está familiarizado com o mercado de ações
exigirá uma abordagem diferente daquela para investidores experientes.
Essas diferenças de experiência ou especialização podem formar a base para
segmentar nosso público.

A forma como as pessoas usam a informação muitas vezes depende de suas relações sociais ou
papel profissional. As necessidades de informação dos pais de um aluno
candidatar-se à faculdade são diferentes daquelas da própria aluna.
Identificar as diferentes funções dos usuários do seu produto pode ajudar você
separá-los e analisar suas diferentes necessidades.
Depois de realizar algumas pesquisas sobre seus grupos de usuários, você
pode ser necessário revisar os segmentos com os quais você está trabalhando. Para a prova
Por exemplo, se você estiver pesquisando mulheres de 25 a 34 anos com formação universitária,
você pode descobrir que as necessidades das pessoas de 30 a 34 anos diferem das
os da faixa etária de 25 a 29 anos. Se a diferença for grande o suficiente, você
pode querer tratá-los como grupos separados, em vez de um único
25–34 com o qual você começou. Por outro lado, se o 18-24
parece bastante semelhante ao grupo 25-34, talvez você possa
combiná-los. Criar segmentos de usuários é apenas um meio para o fim
de descobrir as necessidades do usuário. Você realmente só precisa de tantos
segmentos, pois você tem diferentes conjuntos de necessidades do usuário.
Há outro motivo importante para criar segmentos de usuários: não apenas
diferentes grupos de usuários terão necessidades diferentes, mas às vezes
essas necessidades estarão em oposição direta. Faça o exame anterior
ple do aplicativo de negociação de ações. Os novatos provavelmente seriam
melhor servido por um aplicativo que dividiu o processo em um
sequência de passos simples. Para os especialistas, no entanto, tal sequência
seria um empecilho. Os especialistas precisam de uma interface unificada que
fornece acesso rápido a uma ampla gama de funções.
Obviamente, não podemos atender a ambos os conjuntos de necessidades do usuário com uma única solução
ção. Nossas opções neste momento são focar em um segmento de usuário para
a exclusão do outro, ou fornecer duas formas separadas para os usuários

abordar a mesma tarefa. Qualquer que seja o curso que escolhermos, esta stra
decisão técnica terá consequências para cada escolha adicional
fazemos sobre a experiência do usuário.
Usabilidade e pesquisa de usuários

Para entender o que nossos usuários precisam, primeiro temos que ter uma noção de
quem eles são. O campo de pesquisa do usuário é dedicado a coletar os
dados necessários para desenvolver essa compreensão.
Algumas ferramentas de pesquisa – como pesquisas, entrevistas ou grupos focais –
são mais adequados para coletar informações sobre as atitudes gerais
e percepções de seus usuários. Outras ferramentas de pesquisa, como usuário
testes ou estudos de campo - são mais apropriados para entender
aspectos específicos do comportamento do usuário e da interação com seu produto.
Geralmente, quanto mais tempo você passa com cada usuário individual, mais
mais detalhadas as informações que você obterá do estudo de pesquisa.
No entanto, esse tempo adicional gasto com cada usuário necessariamente
significa que você não poderá incluir tantos usuários no estudo (se
apenas porque o produto ou serviço tem que ser lançado eventualmente).
Métodos de pesquisa de mercado, como pesquisas e grupos focais, podem ser
valiosas fontes de informações gerais sobre seus usuários. Esses
métodos são mais eficazes quando você articula claramente para si mesmo
quais informações você está tentando obter deles. Você quer
descobrir o que seus usuários estão fazendo quando usam um recurso específico
tura do seu produto? Ou talvez você já saiba disso, mas precisa
para saber por que eles estão fazendo isso. Quanto mais claramente você puder descrever
o que você quer, mais estreita e eficazmente você pode formular
as perguntas que você faz para garantir que você obtenha as informações corretas.
A investigação contextual refere-se a todo um conjunto de métodos que,
letivamente, formam o kit de ferramentas mais poderoso e abrangente para
entender seus usuários no contexto de suas vidas cotidianas
(daí o nome). Essas técnicas são derivadas dos métodos
usado por antropólogos para estudar culturas e sociedades. Aplicado em
escala menor, os mesmos métodos usados para examinar, por exemplo,
como funciona uma tribo nômade, também pode ser usado para examinar como
as pessoas que compram peças de aeronaves funcionam. A única desvantagem é que
a investigação contextual pode ser muito demorada e muito dispendiosa
seguro. Se você tem os recursos e seu problema requer uma profunda
compreensão de seus usuários, um estudo de consulta contextual completo

pode revelar sutilezas do comportamento do usuário que não podem ser descobertas
através de outros métodos.
Em outros casos, os métodos contextuais podem ser leves e inexplicáveis
pensativos, embora tendam a não produzir a compreensão profunda
de uma pesquisa completa. Um exemplo de um método intimamente relacionado com
a investigação contextual é a análise de tarefas. A ideia por trás da análise de
tarefas é que a interação de cada usuário com um produto ocorra no
contexto de alguma tarefa que o usuário está executando. Às vezes a tarefa
é muito focado (como comprar ingressos de cinema) e às vezes é
mais amplo (como aprender sobre a regulamentação do comércio internacional
ções). A análise de tarefas é um método de examinar de perto o
etapas que os usuários percorrem para realizar essas tarefas. Este exame
ção pode ser feita por meio de entrevistas nas quais você obtém usuários
para contar histórias sobre suas experiências ou por meio de observação direta
em campo, estudando os usuários em seu habitat natural.
O teste de usuário é a forma mais comumente empregada de teste de usuário
pesquisar. O teste de usuário não é sobre testar seus usuários; em vez disso, é
sobre como fazer com que seus usuários testem o que você produziu. As vezes
testes de usuário funcionam com um produto acabado, seja em preparação para um
redesenhar ou eliminar quaisquer problemas de usabilidade antes do lançamento. Em outros
casos, os usuários podem testar um trabalho em andamento ou até mesmo um protótipo áspero
do produto acabado.
Se você já leu alguma coisa sobre web design, provavelmente
se deparar com o conceito de usabilidade. Esta palavra significa diferente
coisas para pessoas diferentes. Algumas pessoas o usam para se referir à prática
de testar projetos com usuários representativos. Para outros, significa
adotando uma metodologia de desenvolvimento muito específica.
Toda abordagem de usabilidade procura tornar os produtos mais fáceis de usar.
Muitas definições diferentes e listas de regras estabelecidas para codificar o que
constitui um design de site utilizável. Alguns até concordam com
uns aos outros. Mas todos eles têm o mesmo princípio em seu núcleo: usuários
precisa de produtos utilizáveis. É a necessidade de usuário mais universal de todas.
Testes com um site totalmente operacional podem ser muito amplos ou muito
estreito no escopo. Assim como em pesquisas ou grupos focais, é melhor se você
tenha uma noção clara do que deseja investigar antes de se sentar
para baixo com os usuários. Isso não significa, no entanto, que um teste de usuário tenha
ser estritamente limitado a avaliar com que sucesso os usuários completam
uma tarefa estreitamente definida. O teste do usuário também pode investigar mais amplo,
questões menos concretas. Por exemplo, um teste de usuário pode ser usado para encontrar
determinar se as modificações no projeto reforçam ou prejudicam o
mensagem da marca da empresa.
Outra abordagem para testar o usuário é fazer com que os usuários trabalhem com
totipos. Estes podem assumir uma variedade de formas, desde esboços
papel, para maquetes “lo-fi” usando designs de interface simplificados,
a protótipos “click-through” que criam a ilusão de um
produtos. Projetos de maior escala empregam diferentes tipos de protótipos

em diferentes estágios para coletar a entrada do usuário durante todo o
processo de design.
Às vezes, os testes de usuário não envolvem o site. Você pode recrutar
usuários a realizar uma variedade de exercícios que podem fornecer insights
em como eles abordam o assunto do seu site. Para informações
sites orientados a informações, a classificação de cartões é um método usado para explorar
como os usuários categorizam ou agrupam elementos de informação. O usuário é
dado uma pilha de cartões de índice, cada um com o nome, descrição
ção, ou imagem de uma peça ou tipo de conteúdo nele. O usuário então classifica
as cartas em pilhas de acordo com os grupos ou categorias que parecem
mais naturais. Analisando os resultados das classificações de cartões realizadas com
vários usuários podem nos ajudar a entender como eles pensam sobre o
informações que nosso site fornece.
Criando Personas
Coletar todos os tipos de dados sobre seus usuários pode ser incrivelmente valioso
capaz, mas às vezes você pode perder de vista as pessoas reais por trás de tudo
As estatísticas. Você pode tornar seus usuários mais reais, tornando-os
em personas (às vezes chamadas de modelos de usuário ou perfis de usuário). UMA
persona é um personagem fictício construído para representar as necessidades
de toda uma gama de usuários reais. Ao colocar um rosto e um nome no
bits de dados desconectados de sua pesquisa e segmentação de usuários
funcionar, as personas podem ajudar a garantir que você mantenha os usuários em mente
durante o processo de projeto.
Vejamos um exemplo. Suponha que nosso site seja projetado para fornecer
informações para pessoas que estão começando seus próprios negócios. Nós
sabemos de nossa pesquisa que nosso público cai principalmente na faixa de 30 a 45
faixa etária. Nossos usuários tendem a se sentir bastante confortáveis com a Web e
tecnologia em geral. Alguns deles têm muita experiência no

mundo dos negócios; para outros, esta é sua primeira exposição a todos os
questões envolvidas na gestão de um negócio.
Nesse caso, pode ser apropriado criar duas personas. Poço
chame a primeira Janet. Ela tem 42 anos, é casada e
tem dois filhos. Ela passou os últimos dois anos como vice-presidente
em uma grande empresa de contabilidade. Ela ficou frustrada com o trabalho
para outras pessoas, e agora ela quer construir sua própria empresa.
A segunda pessoa é Frank. Ele tem 37 anos e é casado com
uma criança. A marcenaria tem sido um hobby de fim de semana de Frank há
muitos anos. Alguns amigos dele ficaram impressionados com alguns móveis
ele fez, então ele está pensando que poderia entrar no negócio para ele
auto vendendo seu trabalho. Ele não tem certeza se terá que deixar seu emprego como
motorista de ônibus escolar para lançar seu novo negócio.
De onde veio toda essa informação? Bem, para a maioria,
nós inventamos. Queremos que nossas personas sejam consistentes com o que
saber sobre os usuários de nossa pesquisa, mas os detalhes específicos de
nossas personas são invenções fictícias, usadas para dar vida a esses
personagens que substituirão nossos usuários reais e ao vivo.
Janet e Frank representam a gama de necessidades do usuário que teremos que
tenha em mente enquanto tomamos decisões sobre a experiência do usuário
do nosso site. Para nos ajudar a lembrá-los e suas necessidades, vamos pegar um
algumas fotos de banco de imagens para dar a Janet e Frank um pouco mais de identidade,
e combine essas fotos com as informações sobre elas que temos
coloque junto. Esses perfis podem ser impressos e postados ao redor
escritório para que, quando tivermos decisões a tomar, possamos pedir aos nossos
eus (e uns aos outros): “Isso funcionaria para Janet? Como seria
Frank reage a isso? As personas nos ajudam a manter nossos usuários em mente
cada passo do caminho.

Personas são fictícios
Janet personagens extraídos de
pesquisa de usuários que
“Eu não tenho tempo para resolver um monte de servir como casos de exemplo
em formação. Preciso de respostas rápidas.”
durante o desenvolvimento da
Janet está frustrada por trabalhar em um ambiente corporativo experiência do usuário.

e quer começar seu próprio escritório de contabilidade.
Idade: 42 Perfil técnico: Bastante confortável com tecnologia; Dell

Ocupação: Vice-presidente de escritório de contabilidade laptop (com cerca de um ano) rodando Windows; 5 Mbit
Família: Casado, dois filhos Conexão de internet; 15-20 horas/semana online
Renda familiar: $ 180.000/ano Uso da Internet: 75% em casa; notícias e informações,
Shopping
Sites favoritos:
WSJ.com Salon.com Travelocity.com
Franco
“Essas coisas são novas para mim. eu quero um site
isso vai explicar tudo.”
Frank está interessado em aprender como ele pode transformar seu
hobby de transformar móveis em um negócio.
Idade: 37 Perfil técnico: Um pouco desconfortável com tecnologia;

Ocupação: Motorista de ônibus escolar Apple iMac (com cerca de dois anos); Conexão DSL à Internet;
Família: Casado, um filho 8-10 horas/semana online
Renda familiar: $ 60.000/ano Uso da Internet: 100% em casa; entretenimento, compras
Sites favoritos:
ESPN. com moviefone. com eBay.com

Funções e processos da equipe
As questões estratégicas afetam todos os envolvidos no processo de design da
experiência do usuário. Mas apesar desse fato (ou talvez por causa dele),
a responsabilidade de formular esses objetivos muitas vezes é esquecida. As
empresas de consultoria às vezes empregam estrategistas
em projetos de clientes para gerenciar esses problemas - mas porque esse
conhecimento raro tende a ser caro e porque os estrategistas não são
diretamente responsável pela construção de qualquer peça do produto em si, esse
item de linha geralmente é um dos primeiros a ser cortado do orçamento do projeto.
Os estrategistas conversarão com muitas pessoas em toda a organização para obter
o maior número possível de perspectivas sobre as questões de prod
objetivos e necessidades do usuário. Stakeholders são tomadores de decisão
seniores que são responsáveis por partes da organização que irão
ser afetado pela direção estratégica final do produto. Por exemplo, no caso de um
site projetado para fornecer aos clientes
com acesso a informações de suporte ao produto, as partes interessadas podem
incluir representantes de comunicações de marketing e clientes
atendimento ao cliente, bem como gerentes de produto. Depende da estrutura formal
de tomada de decisão (e das realidades políticas informais) de
a organização.
Um grupo frequentemente negligenciado na formulação de uma estratégia é a classificação
e arquivo — as pessoas responsáveis por manter a organização funcionando no dia-
a-dia. Mas essas pessoas costumam fazer uma aposta
melhor noção do que funciona e do que não funciona do que seus gerentes. Eles
podem informar a estratégia de maneiras que os tomadores de decisão seniores
não pode, especialmente quando se trata de necessidades do usuário. Ninguém sabe
melhor com o que os clientes estão tendo problemas do que as pessoas que
fale com esses clientes todos os dias. Muitas vezes me surpreendo com a forma como
raramente o feedback do cliente chega ao design do produto
e equipes de desenvolvimento que precisam.
Os objetivos do produto e as necessidades do usuário são frequentemente definidos em um
documento de estratégia ou documento de visão. Este documento não é apenas um
lista de objetivos - fornece uma análise das relações entre
os vários objetivos e de como esses objetivos se encaixam no
contexto da organização. Os objetivos e sua análise são
muitas vezes apoiado por citações diretas de partes interessadas, rank-and-file
funcionários e os próprios usuários. Essas citações ilustram claramente a
questões estratégicas envolvidas no projeto. As necessidades do usuário são às vezes
documentado em um relatório de pesquisa de usuário separado (embora existam
certas vantagens de ter todas as suas informações em um só lugar).
Maior não é necessariamente melhor quando se trata de documentar sua
estratégia. Você não precisa incluir todos os pontos de dados e todos os sup
cotação de portabilidade para transmitir sua ideia. Mantenha-o conciso e ao
ponto. Lembre-se que muitas pessoas que serão expostas ao doc
ument não terá tempo ou interesse para percorrer centenas de
páginas de material de apoio, e é muito mais importante que eles
entender a estratégia do que se impressionar com o volume
de palavreado que você produziu. Um documento de estratégia eficaz não
serve apenas como uma pedra de toque para o desenvolvimento da experiência do usuário
equipe; ele também pode ser usado para construir suporte para o projeto em outros
partes da organização.
A pior coisa que você pode fazer com seu documento de estratégia é
limitar o acesso de sua equipe a ele. O documento não foi criado para ser
arquivado em algum lugar ou compartilhado apenas com um punhado de veteranos
membros da equipe - se o esforço investido vai valer a pena,
o documento deve ser usado ativamente durante o projeto. Tudo

participantes - designers, desenvolvedores, gerentes de projeto - precisam da
documento de estratégia para tomar decisões informadas sobre seu trabalho.
Os documentos de estratégia geralmente contêm material sensível, mas a organização
podem ir longe demais e manter a estratégia longe dos responsáveis
equipe, o que prejudica sua capacidade de realizá-lo.
A estratégia deve ser o início do design da experiência do usuário
processo, mas isso não significa que sua estratégia deva ser definida
antes que o projeto possa avançar. Embora tentando acertar um movimento
alvo pode ser uma tremenda perda de tempo e recursos (para não
mencionar uma enorme fonte de frustração interna), as estratégias podem e
deve evoluir e ser refinada. Quando sistema revisado e refinado
ticamente, o trabalho de estratégia pode ser uma fonte contínua de inspiração
durante todo o processo de design da experiência do usuário.


capítulo 4
O escopo
Avião
Especificações Funcionais e
Requisitos de conteúdo
Superfície
Esqueleto
Com uma noção clara do que queremos e do que Estrutura
usuários desejam, podemos descobrir como satisfazer todos esses

Alcance
objetivos estratégicos. A estratégia se torna escopo quando
Estratégia
você traduz as necessidades do usuário e os objetivos do produto em
requisitos específicos para que conteúdo e função
lidade que o produto oferecerá aos usuários.
Interação tivemos
formação
Em
Contente
Requisitos
Funcional
Especificações
nt
e
58 CAPÍTULO 4 O PLANO DE ESCOPO
Definindo o Escopo
Fazemos algumas coisas porque há valor no processo, como correr ou praticar
escalas no piano. Fazemos outras coisas porque
há valor no produto, como fazer um cheesecake ou consertar um carro. Definir o
escopo do seu projeto é tanto: um processo valioso
que resulta em um produto valioso.
O processo é valioso porque força você a abordar potenciais
conflitos e pontos ásperos no produto enquanto a coisa toda ainda é hipotética.
Podemos identificar o que podemos enfrentar agora e
o que terá que esperar até mais tarde.
O produto é valioso porque dá uma referência a toda a equipe
ponto para todo o trabalho a ser feito ao longo do projeto e uma linguagem
comum para falar sobre esse trabalho. Definindo sua exigência
mentos elimina a ambiguidade do processo de design.
Certa vez, trabalhei em um aplicativo da Web que parecia estar em um estado
de beta perpétuo: quase, mas não totalmente, pronto para ser lançado para
usuários reais. Muitas coisas estavam erradas com nossa abordagem - a tecnologia
ogy era instável, não sabíamos nada sobre nossos usuários, e eu era a única
pessoa em toda a empresa que tinha alguma
experiência com desenvolvimento para a Web.
Mas nada disso explica por que não conseguimos que o produto
lançar. O grande obstáculo foi a falta de vontade de definir os requisitos. Afinal,
deu muito trabalho escrever tudo
quando todos trabalhávamos no mesmo escritório de qualquer maneira e, além
disso, o gerente de produto precisava concentrar sua energia em criar
Novas características.
O resultado foi um produto que era uma mistura em constante mudança de
características em vários estágios de completude. A cada novo artigo alguns
corpo lido ou cada novo pensamento que surgiu enquanto alguém
estava brincando com o produto inspirou outro recurso a ser considerado
ção. Havia um fluxo constante de trabalho, mas não havia
cronograma, não havia marcos e não havia fim à vista.
Como ninguém conhecia o escopo do projeto, como alguém poderia

sabe quando terminamos?
Há duas razões principais para se preocupar em definir requisitos.
Razão #1: Então você sabe o que está construindo

Isso parece meio óbvio, mas foi uma surpresa para a equipe
construir esse aplicativo da Web. Se você articular claramente o que
você está planejando construir, todos saberão qual é o projeto
metas são e quando foram alcançadas. O produto final pára
sendo uma imagem amorfa na cabeça do gerente de produto, e
torna-se algo concreto que todos em todos os níveis da
organização, de altos executivos a engenheiros iniciantes, pode

trabalhar com.
Na ausência de requisitos claros, seu projeto provavelmente
acabar como um jogo de "Telefone" no pátio da escola - cada pessoa
a equipe obtém uma impressão do produto por meio do boca a boca e
a descrição de todos acaba sendo um pouco diferente. Ou ainda pior,
todos assumem que outra pessoa está gerenciando o design e o desenvolvimento
mento de algum aspecto crucial do produto, quando na verdade ninguém o é.

Ter um conjunto definido de requisitos permite parcelar
responsabilidade pelo trabalho de forma mais eficiente. Vendo todo o escopo
mapeado permite que você veja conexões entre
requisitos que de outra forma não seriam aparentes. Por exemplo,
nas primeiras discussões, a documentação de suporte e o produto
as folhas de especificações podem parecer recursos de conteúdo separados, mas
defini-los como requisitos pode tornar aparente que há
muita sobreposição e que o mesmo grupo deve ser responsável

para ambos.
Razão #2: Então você sabe o que não está construindo

Muitos recursos parecem boas ideias, mas não necessariamente
alinhamento com os objetivos estratégicos do projeto. Além disso, todos
tipos de possibilidades para recursos surgem depois que o projeto é bem
em andamento. Ter requisitos claramente identificados fornece a você
com uma estrutura para avaliar essas ideias à medida que elas surgem,
ajudando você a entender como (ou se) eles se encaixam no que você
já se comprometeu a construir.
Saber o que você não está construindo também significa saber o que você está
não está construindo agora. O valor real em coletar todos aqueles grandes
ideias vem de encontrar maneiras apropriadas de encaixá-las em seu
planos de longo prazo. Ao estabelecer conjuntos concretos de requisitos, e
pedidos de armazenamento que não se encaixam como possibilidades para lançamentos futuros,
você pode gerenciar todo o processo de uma forma mais deliberada.

Janeiro (agora) abril Julho Outubro (próximo) Janeiro Requisitos que

não pode ser atendido no
programação atual pode
formam a base para a
próximo marco em seu
ciclo de desenvolvimento.
Versão 1.0 Versão 1.1
Se você não gerenciar conscientemente seus requisitos, será pego no temido
“deslocamento de escopo”. A imagem que isso sempre traz
para mim é a bola de neve que rola para frente uma polegada - e então
outro - pegando um pouco de neve extra a cada volta até que esteja
descendo a colina, ficando maior e mais difícil de parar todo o caminho. Da mesma
forma, cada requisito adicional pode não parecer
como muito trabalho extra. Mas junte todos eles e você terá um projeto fora de
controle, esmagando prazos e
estimativas orçamentárias a caminho de um colapso final inevitável.
Funcionalidade e Conteúdo
No plano do escopo, partimos da questão abstrata de “Por que
estamos fazendo este produto?” que tratamos no plano estratégico e construímos
sobre ele uma nova pergunta: “O que vamos
fazer?"

estrutura
alcance
estratégia
A cisão entre a Web como veículo de funcionalidade e a
A Web como meio de informação começa a entrar em jogo no
plano de escopo. No lado da funcionalidade, estamos preocupados com o que
seria considerado o conjunto de recursos do produto de software. Sobre
o lado da informação, estamos lidando com conteúdo, o tradicional
domínio de grupos editoriais e de comunicação de marketing.
Conteúdo e funcionalidade parecem tão diferentes quanto dois
coisas poderiam ser, mas quando se trata de definir o escopo, elas podem ser
abordados de forma muito semelhante. Ao longo deste capítulo, usarei
o termo recurso para se referir tanto às funções do software quanto ao conteúdo
ofertas.
No desenvolvimento de software, o escopo é definido por meio de
requisitos funcionais ou especificações funcionais. Algumas organizações
usar esses termos para significar dois documentos diferentes: requisitos
no início do projeto para descrever o que o sistema deve
fazer e especificações no final para descrever o que ele realmente faz.
Em outros casos, as especificações são desenvolvidas logo após a

requisitos, preenchendo detalhes de implementação. Mas a maioria dos
tempo, esses termos são intercambiáveis - na verdade, algumas pessoas usam o
termo especificação de requisitos funcionais apenas para ter certeza de que eles
cobriu todas as bases. Usarei especificações funcionais para me referir ao
documento em si e requisitos para consultar o seu conteúdo.
A linguagem deste capítulo é principalmente a linguagem do software
desenvolvimento. Mas os conceitos aqui se aplicam igualmente ao conteúdo.
O desenvolvimento de conteúdo geralmente envolve requisitos menos formais
processo de definição do que o software, mas os princípios subjacentes
são os mesmos. Um desenvolvedor de conteúdo vai sentar e conversar com
pessoas ou se debruçar sobre o material de origem, seja um banco de dados ou
uma gaveta cheia de recortes de notícias, a fim de determinar quais informações
informação precisa ser incluída no conteúdo que ela está desenvolvendo. este
processo para definir os requisitos de conteúdo não é tudo isso
diferente dos recursos de brainstorming do tecnólogo com participação
titulares e revisar a documentação existente. Os propósitos e
abordagens são as mesmas.
Os requisitos de conteúdo geralmente têm implicações funcionais. Esses
dias, sites de conteúdo puro geralmente são tratados por meio de um
sistema de gestão (CMS). Esses sistemas vêm em todas as formas
e tamanhos, de sistemas muito grandes e complexos que dinamicamente
gerar páginas de uma dúzia de fontes de dados diferentes para
ferramentas otimizadas para gerenciar um tipo específico de recurso de conteúdo em
a forma mais eficiente. Você pode decidir comprar um proprietário
sistema de gerenciamento de conteúdo, use um dos muitos
alternativas, ou até mesmo construir uma do zero. De qualquer forma, será
faça alguns ajustes para adaptar o sistema à sua organização e
seu conteúdo.
Um gerenciamento de conteúdo editor de conteúdo Editor de cópia
sistema pode automatizar
o fluxo de trabalho
necessário para produzir e entregar
conteúdo aos usuários.
escritor do utilizador
parte interessada advogado
A funcionalidade que você precisa em seu sistema de gerenciamento de conteúdo
dependerá da natureza do conteúdo que você gerenciará. Vai
você está mantendo conteúdo em vários idiomas ou formatos de dados?

O CMS precisará ser capaz de lidar com todos esses tipos de conteúdo
elementos. Todo comunicado à imprensa precisa ser aprovado por seis executivos
vice-presidentes efetivos e um advogado? O CMS terá de suportar
esse tipo de processo de aprovação em seu fluxo de trabalho. Elementos de conteúdo
ser recombinado dinamicamente de acordo com as preferências de cada
usuário ou o dispositivo que eles estão usando? O CMS deverá ser capaz de
atingir esse nível de entrega complexa.
Da mesma forma, os requisitos funcionais de qualquer produto de tecnologia
têm implicações de conteúdo. Haverá instruções no pref
erences tela de configuração? E as mensagens de erro? Algum
corpo tem que escrever aqueles. Toda vez que vejo uma mensagem de erro em um
Web site como "Exceção de campo de entrada nulo", conheço alguns engenheiros
mensagem de espaço reservado chegou ao produto final porque ninguém
fez dessa mensagem de erro um requisito de conteúdo. Incontáveis alegadamente
projetos técnicos poderiam ter sido melhorados imensamente se o
os desenvolvedores simplesmente se deram ao trabalho de fazer alguém olhar para o
aplicação com um olho para o conteúdo.

Definição de Requisitos
Alguns requisitos se aplicam ao produto como um todo. Os requisitos de marca
são um exemplo comum disso; determinado técnico
requisitos, como navegadores e sistemas operacionais suportados,

são outro.
Outros requisitos se aplicam apenas a um recurso específico. Na maioria das
vezes, quando as pessoas se referem a um requisito, estão pensando em um
breve descrição de um único recurso que o produto deve ter.
O nível de detalhamento de seus requisitos muitas vezes dependerá do
escopo específico do projeto. Se o objetivo do projeto é implementar um
subsistema muito complexo, um nível de detalhe muito alto
pode ser necessário, mesmo que o escopo do projeto em relação ao site maior
possa ser muito pequeno. Por outro lado, uma grande escala
projeto de conteúdo pode envolver uma base tão homogênea de conteúdo
(como um grande número de PDFs funcionalmente idênticos de produtos
manuais) que os requisitos de conteúdo só podem ser muito gerais.
A fonte mais produtiva de requisitos sempre será sua
próprios usuários. Mas, com mais frequência, seus requisitos virão de partes
interessadas, pessoas em sua organização que têm algo a dizer
sobre o que entra no seu produto.
Em ambos os casos, a melhor maneira de descobrir o que as pessoas querem é simplesmente
para perguntar a eles. As técnicas de pesquisa de usuários descritas no
Capítulo 3 podem ser usadas para ajudá-lo a entender melhor os tipos
de recursos que os usuários desejam ver em seu produto.
Se você está definindo requisitos com a ajuda das partes interessadas
ers dentro de sua organização ou trabalhando diretamente com usuários, o

requisitos que saem do processo cairão em três
categorias gerais. Primeiro, e mais óbvio, são as coisas que as pessoas dizem
eles querem. Algumas delas são claramente boas ideias e encontrarão
seu caminho para o produto final.
Às vezes, as coisas que as pessoas dizem que querem não são as coisas que elas
realmente deseja. Não é incomum para ninguém, quando eles encontram
alguma dificuldade com um processo ou um produto, para imaginar uma solução.
Às vezes, essa solução é impraticável ou aborda um sintoma
em vez da causa subjacente do problema. Ao explorar
essas sugestões, às vezes você pode chegar a conclusões completamente diferentes
requisitos que resolvem o problema real.
O terceiro tipo de requisito é o recurso que as pessoas não conhecem
eles querem. Quando você faz as pessoas falarem sobre objetivos estratégicos
e novos requisitos que podem satisfazê-los, às vezes eles
teve grandes ideias que simplesmente não haviam ocorrido a ninguém durante
a manutenção contínua do produto. Estes muitas vezes saem
exercícios de brainstorming, quando os participantes têm a chance de conversar
e explorar as possibilidades para o projeto.
Ironicamente, às vezes as pessoas mais profundamente envolvidas na criação
e trabalhando com um produto são os menos capazes de imaginar novas
direções para isso. Quando você passa todo o seu tempo imerso na principal
mantendo um produto existente, muitas vezes você pode esquecer qual dos seus
restrições são reais, e que são simplesmente produtos de
escolhas. Por esta razão, sessões de brainstorming em grupo que trazem
reunir pessoas de diversas partes da organização ou representar
diversos grupos de usuários podem ser ferramentas muito eficazes para abrir as mentes
dos participantes a possibilidades que eles não teriam considerado antes.
Conseguir um engenheiro, um agente de atendimento ao cliente e um gerente de marketing
pessoa em uma sala para falar sobre o mesmo site pode ser
esclarecedor para todos. Ouvindo perspectivas desconhecidas - e
ter a oportunidade de responder a eles - incentiva as pessoas a
pensar em termos mais amplos sobre os problemas envolvidos no desenvolvimento
o produto e as soluções possíveis.
Qualquer que seja o dispositivo para o qual estamos projetando - ou se estamos projetando o
próprio dispositivo - nosso conjunto de recursos precisará levar em consideração
requisitos de ware, também. O aparelho tem câmera? GPS?
Sensores de posição giroscópicos? Essas considerações informarão e
restringir suas possibilidades funcionais.
Gerar requisitos é muitas vezes uma questão de encontrar maneiras de
remover impedimentos. Por exemplo, suponha que você tenha um usuário
que já decidiu comprar um produto - eles simplesmente não
decidiu se o seu produto é o que eles vão comprar. O que seu site pode
fazer para fazer esse processo - primeiro selecionando seu produto e depois comprando
seu produto - mais fácil para eles?
No Capítulo 3, examinamos a técnica de criação de personagens fictícios.
atores chamados personas para nos ajudar a entender melhor as necessidades do usuário. Dentro
determinando os requisitos, podemos usar essas personas novamente colocando
transformar nossos personagens fictícios em pequenas histórias chamadas cenários. UMA
cenário é uma narrativa curta e simples que descreve como uma persona pode
tentar satisfazer uma dessas necessidades do usuário. Ao imaginar o
processo pelo qual nossos usuários podem passar, podemos apresentar possíveis
requisitos para ajudar a satisfazer as suas necessidades.
Também podemos buscar inspiração em nossos concorrentes. Qualquer outra pessoa em
a mesma empresa está quase certamente tentando atender o mesmo usuário
precisa e provavelmente está tentando atingir um objetivo de produto semelhante
também. Um concorrente encontrou um recurso particularmente eficaz
para atender a um desses objetivos estratégicos? Como eles abordaram
os mesmos trade-offs e compromissos que enfrentamos?

Mesmo produtos que não são concorrentes diretos podem servir como
fontes para possíveis requisitos. Algumas plataformas de jogos, por
exemplo, oferecer aos usuários a capacidade de criar grupos sociais de colegas
jogadoras. Adotar ou desenvolver sua abordagem ao definir o escopo de um
recurso semelhante para nosso gravador de vídeo digital pode nos dar uma vantagem
sobre nossa concorrência direta.
Especificações funcionais
As especificações funcionais têm uma má reputação em
determinados trimestres. Os programadores geralmente odeiam especificações porque tendem a
ser terrivelmente maçante, e o tempo gasto lendo-os é o tempo gasto
longe de produzir código. Como resultado, as especificações não são lidas, o que
por sua vez reforça a impressão de que produzi-los é um desperdício
de tempo - porque é! Uma má abordagem às especificações torna-se um self
cumprindo a profecia.
Uma reclamação sobre as especificações funcionais é que elas não
refletem o produto real. As coisas mudam durante a implementação.
Todo mundo entende isso - é a natureza de trabalhar com tecnologia
nologia. Às vezes, algo que você pensou que funcionaria não funcionou, ou
mais provavelmente não funcionou do jeito que você pensou que funcionaria. Este,
no entanto, não é uma razão para abandonar as especificações de escrita como uma causa perdida.
Em vez disso, destaca a importância das especificações que realmente funcionam.
Quando as coisas mudam durante a implementação, a resposta não é
levante as mãos e declare a futilidade de escrever especificações. o
a resposta é tornar o processo de definição de especificações leve
o suficiente para que a especificação não se torne um projeto separado do desenvolvimento
operando o próprio produto.

Em outras palavras, a documentação não resolverá seus problemas. Definido
vontade. Não se trata de volume ou detalhe. É sobre clareza e accu
atrevido. As especificações não precisam incorporar todos os aspectos do produto - apenas
aqueles que precisam de definição para evitar confusão no design e
processo de desenvolvimento. E as especificações não precisam capturar algum ideal
estado futuro do produto – apenas as decisões que foram
feito durante a sua criação.
Escrevendo
Não importa quão grande ou complexo seja o projeto, algumas
regras se aplicam a escrever qualquer tipo de requisitos.
Seja positivo. Em vez de descrever uma coisa ruim, o sistema não deveria
fazer, descreva o que ele fará para evitar essa coisa ruim. Por exemplo,
em vez disso:
O sistema não permitirá que o usuário compre uma pipa sem
corda de pipa.
Isso seria melhor:
O sistema direcionará o usuário para a página da linha de pipas se o usuário tentar
comprar uma pipa sem barbante.
Seja específico. Deixar o menos possível aberto à interpretação é
a única maneira de determinar se um requisito foi

realizada.
Compare estes exemplos:
1. Os vídeos mais populares serão destacados.
2. Os vídeos com mais visualizações na última semana aparecerão no
topo da lista.
O primeiro exemplo parece identificar um requisito claro, mas não
não é preciso muita investigação para começar a fazer buracos nele. O que conta
tão popular? Vídeos com mais comentários? Os com o
mais votos “like”? E o que é realçá-los?
O segundo exemplo define nosso objetivo em detalhes específicos, definindo
o que queremos dizer com popular e descrevendo um mecanismo de alta
iluminação. Ao eliminar a possibilidade de interpretações divergentes,
o segundo requisito contorna nitidamente os tipos de argumentos prováveis
surgir durante ou após a implementação.
Evite a linguagem subjetiva. Esta é realmente apenas outra maneira de
sendo específico e removendo a ambiguidade - e, portanto, a possibilidade
para interpretações erradas - dos requisitos.
Aqui está um requisito altamente subjetivo:
O site terá um estilo moderno e chamativo.
Os requisitos devem ser falsificáveis - isto é, deve ser possível
demonstrar quando um requisito não foi atendido. É difícil
demonstrar se qualidades subjetivas como hip e chamativo têm
foi cumprido. Minha ideia de modernidade provavelmente não combina com a sua,
e muito provavelmente o CEO tem outra ideia inteiramente.
Isso não significa que você não pode exigir que seu site seja moderno. Você apenas
tem que encontrar maneiras de especificar quais critérios serão aplicados:
O site atenderá às expectativas descoladas de Wayne, o funcionário dos correios.
Wayne normalmente não teria nada a dizer sobre o projeto, mas nosso
o patrocinador do projeto respeita claramente seu senso de modernidade. Espero que seja
o mesmo sentido que nossos usuários têm. Mas a exigência ainda é bastante
arbitrário porque estamos contando com a aprovação de Wayne em vez de cri
critérios que podem ser definidos de forma mais objetiva. Então talvez isso exija
mento seria o melhor de tudo:
A aparência do site estará em conformidade com as diretrizes de marca da empresa
documento.
Todo o conceito de modernidade desapareceu completamente de
o requerimento. Em vez disso, temos uma referência clara e inequívoca
às diretrizes estabelecidas. Para garantir que as diretrizes da marca sejam
suficientemente moderno, o vice-presidente de marketing pode consultar Wayne pelo correio
balconista, ou ela pode consultar sua filha adolescente, ou ela pode até
consulte alguns resultados de pesquisas de usuários. Cabe a ela. Mas agora podemos
dizer definitivamente se o requisito foi cumprido.
Também podemos eliminar a subjetividade definindo alguns requisitos
quantitativamente. Assim como as métricas de sucesso tornam os objetivos estratégicos
identificável, definir um requisito em termos quantitativos pode nos ajudar
identificar se atendemos ao requisito. Por exemplo, em vez
de exigir que o sistema tenha “um alto nível de desempenho”,
pode exigir que o sistema seja projetado para suportar pelo menos 1.000
usuários simultâneos. Se o produto final permitir apenas o usuário de três dígitos
números, podemos dizer que o requisito não foi atendido.
Requisitos de conteúdo
Na maioria das vezes, quando falamos de conteúdo, estamos nos referindo a
texto. Mas imagens, áudio e vídeo podem ser mais importantes do que o
texto que acompanha. Esses diferentes tipos de conteúdo também podem funcionar
juntos para atender a um único requisito. Por exemplo, um conteúdo

recurso que cobre um evento esportivo pode ter um artigo acompanhado
nida por fotografias e videoclipes. Identificando todo o conteúdo
tipos associados a um recurso podem ajudá-lo a determinar quais
serão necessários recursos para produzir o conteúdo (ou se ele pode
ser produzido).
Não se confunda entre o formato de um conteúdo e sua
propósito. Ao discutir os requisitos de conteúdo com as partes interessadas,
uma das primeiras coisas que costumo ouvir é: “Deveríamos ter perguntas frequentes”. Mas
o termo FAQ realmente se refere apenas a um formato de conteúdo: uma série simples
de perguntas e respostas. O valor real de um FAQ para os usuários é que
ele fornece acesso imediato a informações normalmente necessárias. Outro
requisitos de conteúdo podem cumprir esse mesmo propósito; mas quando o
o foco está no formato, o propósito em si pode ser esquecido. Mais
muitas vezes, as FAQs negligenciam a parte “frequentemente” da equação,
oferecendo, em vez disso, respostas para quaisquer perguntas que o provedor de conteúdo
poderia pensar para satisfazer o requisito de FAQ.
O tamanho esperado de cada um dos seus recursos de conteúdo tem uma enorme
influência nas decisões de experiência do usuário que você terá que tomar.
Seus requisitos de conteúdo devem fornecer estimativas aproximadas do
tamanho de cada recurso: contagem de palavras para recursos de texto, dimensões em pixels
para imagens ou vídeo e tamanhos de arquivo para download, autônomo
elementos de conteúdo como arquivos de áudio ou documentos PDF. Estas estimativas de tamanho
os companheiros não precisam ser precisos — as aproximações são boas. Nós apenas
tem que coletar as informações essenciais necessárias para projetar um
veículo apropriado para esse conteúdo. Projetar um site para fornecer acesso a
pequenas imagens em miniatura é diferente de projetar um site para fornecer
acesso a fotografias em tela cheia; sabendo de antemão o tamanho

os elementos de conteúdo que temos que acomodar nos permite fazer
decisões inteligentes e informadas ao longo do caminho.
É importante identificar quem será o responsável por cada conteúdo
elemento o mais cedo possível. Uma vez validado em relação ao nosso
objetivos estratégicos, qualquer recurso de conteúdo inevitavelmente soa como um
ideia muito boa - contanto que outra pessoa seja responsável por criar
e mantendo-o. Se nos aprofundarmos muito no desenvolvimento profissional
sem identificar quem será responsável por todas as
recurso de conteúdo, é provável que acabemos com lacunas em nosso site
porque esses recursos todos adoravam quando eram hipóteses
cal acabou dando muito trabalho para qualquer um realmente assumir.
E é isso que as pessoas muitas vezes esquecem quando o desenvolvimento exige
mentos: O conteúdo é um trabalho árduo. Você pode ser capaz de contratar no contrato
recursos (ou, mais provavelmente, prender alguém no marketing com
o trabalho) para criar o conteúdo a tempo do lançamento inicial, mas quem
vai mantê-lo atualizado? Conteúdo—bem, conteúdo eficaz, de qualquer maneira—
requer manutenção constante. Abordando o conteúdo como se pudesse
postá-lo e esquecer que leva a um site que, com o tempo, aumenta
trabalho ingly pobre de atender às necessidades do usuário.
É por isso que, para cada recurso de conteúdo, você deve identificar como
frequentemente ele será atualizado. A frequência das atualizações deve ser
derivados de seus objetivos estratégicos para o site: com base em seu produto
objetivos, com que frequência você deseja que os usuários voltem? Baseado em
as necessidades de seus usuários, com que frequência eles esperam informações atualizadas
ção? No entanto, tenha em mente que a frequência ideal de atualizações para
seus usuários (“Quero saber tudo instantaneamente, 24 horas por dia!”)
pode não ser prático para sua organização. Você terá que chegar a
uma frequência que representa um compromisso razoável entre o
expectativas de seus usuários e seus recursos disponíveis.
Se seu site precisa atender a vários públicos com necessidades divergentes,
saber a qual público um conteúdo se destina pode
ajudá-lo a tomar melhores decisões sobre como apresentar esse conteúdo.
A informação destinada às crianças requer uma abordagem diferente
de informações destinadas a seus pais; informações para ambos
deles precisa ainda de uma terceira abordagem.
Para projetos que envolvem trabalhar com muito conteúdo existente,
muitas das informações que irão alimentar suas necessidades são
registrados em um inventário de conteúdo. Fazendo um inventário de todos os
conteúdo em seu site existente pode parecer um processo tedioso - e
geralmente é. Mas ter o inventário (que geralmente leva o
forma de uma planilha simples, embora muito grande) é importante para o
mesma razão pela qual ter requisitos concretos é importante: então
todos na equipe sabem exatamente com o que precisam trabalhar
na criação da experiência do usuário.
Priorizando Requisitos
Coletar ideias para possíveis requisitos não é difícil. Quase
todos que regularmente entram em contato com um produto - seja
eles estão dentro ou fora da organização - terão pelo menos um
ideia para um recurso que poderia ser adicionado. A parte complicada é resolver
quais recursos devem ser incluídos no escopo do seu projeto.

Às vezes, uma estratégia
objetivo resultará em
vários requisitos
(deixei). Em outros casos,
um requisito pode
atender a várias estratégias
objetivos (direita).
Na verdade, é bastante raro que você veja uma simples correlação de um para um
entre seus objetivos estratégicos e suas necessidades. Algum
vezes, um requisito pode ser aplicado a vários objetivos estratégicos.
Objetivos. Da mesma forma, um objetivo será frequentemente associado a
vários requisitos diferentes.
Como o escopo é construído sobre a estratégia, precisaremos avaliar
requisitos possíveis com base em se eles cumprem nossos requisitos estratégicos
metas (objetivos do produto e necessidades do usuário). Além daqueles
duas considerações, definir o escopo adiciona uma terceira: quão viável
será para realmente fazer essas coisas?

Alguns recursos não podem ser implementados porque são tecnicamente
impossível — por exemplo, simplesmente não há como permitir que os usuários cheirem
produtos pela Web ainda, não importa o quanto eles desejem
essa habilidade. Outros recursos (principalmente no caso de conteúdo)
não são viáveis porque exigiriam mais recursos - humanos
ou financeiro - do que temos à nossa disposição. Em outros casos, é apenas um
questão de tempo: o recurso levaria três meses para ser implementado,
mas temos um requisito executivo para lançar em dois.
No caso de restrições de tempo, você pode enviar recursos para um
lançamento ou marco do projeto. Para restrições de recursos, tecnologia
ou mudanças organizacionais podem, às vezes, mas, mais importante, não
sempre—reduza a carga de recursos, permitindo que um recurso seja implementado
mente. (No entanto, coisas impossíveis permanecerão impossíveis. Desculpe.)
Poucos recursos existem no vácuo. Até mesmo recursos de conteúdo em um site
confiar nos recursos ao seu redor para informar o usuário sobre a melhor forma de
usar o conteúdo fornecido. Isso inevitavelmente leva a conflitos entre
recursos. Alguns recursos exigirão trocas com outros para
para produzir um todo coerente e consistente. Por exemplo, os usuários podem
querem um processo de envio de pedidos em uma etapa, mas o emaranhado de legados
os bancos de dados que o site usa não podem acomodar todos os dados de uma vez. É isso
preferível seguir um processo de várias etapas, ou você deve retrabalhar
o sistema de banco de dados? Depende dos seus objetivos estratégicos.
Fique de olho nas sugestões de recursos que indicam possíveis mudanças
em estratégia que não eram aparentes durante o desenvolvimento do
documento de visão. Qualquer sugestão de recurso que não esteja de acordo com o projeto
A estratégia ect está, por definição, fora do escopo. Mas se um recurso sugerido
que está fora do escopo não se encaixa em nenhum dos tipos de restrições
acima e ainda parece uma boa ideia, você pode querer reexaminar
alguns de seus objetivos estratégicos. Se você se encontrar revisitando
muitos aspectos de sua estratégia, no entanto, você provavelmente saltou
em definir requisitos muito cedo.
Se sua estratégia ou documento de visão identificar uma hierarquia clara de
prioridades entre seus objetivos estratégicos, essas prioridades devem
ser os principais fatores para determinar a prioridade de sugestões
recursos. Às vezes, porém, a importância relativa de dois
diferentes objetivos estratégicos não está claro. Nestes casos, quer
recursos acabam no escopo do projeto muitas vezes se resume a
política corporativa.
Quando as partes interessadas falam sobre estratégia, geralmente começam com
ideias de recursos e, em seguida, têm que ser persuadidos de volta ao subjacente
fatores estratégicos. Porque as partes interessadas muitas vezes têm problemas para separar
recursos da estratégia, certos recursos geralmente terão campeões.
Assim, o processo de definição de requisitos torna-se uma questão de negociação
interação entre as partes interessadas motivadas.
Gerenciar esse processo de negociação pode ser difícil. Ao melhor
abordagem para resolver um conflito entre as partes interessadas é apelar para
a estratégia definida. Foco nos objetivos estratégicos, não nos meios propostos
de realizá-los. Se você pode assegurar uma parte interessada com ela
coração definido em um recurso específico que o objetivo estratégico do recurso
se destina a cumprir pode ser abordada de alguma outra forma, ela não
sente que as necessidades de seus eleitores estão sendo negligenciadas. Reconhecidamente,
isso é muitas vezes mais fácil dizer do que fazer. Demonstrando empatia com o
necessidades das partes interessadas é essencial para resolver conflitos de recursos. Quem
diz que os trabalhadores de tecnologia não precisam de habilidades pessoais?

capítulo 5
A estrutura
Avião
Design de interação e
Arquitetura de informação
Superfície
Esqueleto
Estrutura
Após a definição dos requisitos e
priorizados, temos uma visão clara do que será

Alcance
incluídos no produto final. Os requisitos,
Estratégia
no entanto, não descreva como as peças se encaixam
para formar um todo coeso. Este é o próximo nível acima
do escopo: desenvolvendo uma estrutura conceitual para
o site.
Interação tivemos
formação
Em
Contente
Requisitos
Funcional
Especificações
nt
e
80 CAPÍTULO 5 O PLANO DE ESTRUTURA
Definindo a Estrutura
O reino da estrutura é o terceiro dos cinco planos e, apropriadamente, é
o ponto em que nossas preocupações mudam do mais
questões abstratas de estratégia e escopo aos fatores concretos que
determinarão o que os usuários finalmente experimentarão. Mas a linha entre
abstrato e concreto podem ser embaçados - embora muito do que
decidimos aqui terá uma influência perceptível e tangível no resultado final.
produto, as próprias decisões ainda envolvem

assuntos.

esqueleto
estrutura
alcance
No desenvolvimento de software tradicional, a disciplina envolvida na
criar uma experiência estruturada para o usuário é conhecido como interação
projeto. Costumava ser agrupado sob o título de “interface
design”, mas o design de interação agora é reconhecido como um
disciplina.
No desenvolvimento de conteúdo, estruturar a experiência do usuário é uma questão

arquitetura da informação. Este campo baseia-se em um número
de disciplinas que historicamente se preocuparam com a organização
nização, agrupamento, ordenação e apresentação de conteúdo: biblioteca
ciência, jornalismo e comunicação técnica, entre outros.
O design de interação e a arquitetura da informação compartilham uma ênfase
na definição de padrões e sequências em que as opções serão pré
enviados aos usuários. O design de interação diz respeito às opções envolvidas na
executar e concluir tarefas. Acordos de arquitetura de informação
com as opções envolvidas na transmissão de informações para um usuário.
O design de interação e a arquitetura da informação soam como algo esotérico,
áreas altamente técnicas, mas essas disciplinas não são realmente sobre
tecnologia em tudo. Eles tratam de entender as pessoas - a maneira
eles se comportam e pensam. Ao construir esse entendimento no
estrutura do nosso produto, ajudamos a garantir uma experiência de sucesso

para quem o usa.
Design de interação
O design de interação está preocupado em descrever o possível comportamento do usuário
ior e definindo como o sistema irá acomodar e responder a
esse comportamento. Toda vez que uma pessoa usa um produto, uma espécie de dança
continua entre os dois. O usuário se movimenta e o
sistema responde. Então o usuário se move em resposta ao sistema,
e assim a dança continua. Mas a maneira típica que o software tem
foi projetado realmente não reconhece essa dança. O pensamento

parece ter sido que se cada aplicação dançasse um pouco diferente
De qualquer forma, não era irracional esperar que o usuário se adaptasse.
O sistema poderia fazer o seu trabalho, e se alguns dedos fossem pisados,
bem, isso fazia parte do processo de aprendizagem. Mas todo dançarino vai
dizer que para a dança realmente funcionar, cada participante deve
antecipar os movimentos do outro.
Os programadores tradicionalmente se concentram e se preocupam mais com
dois aspectos do software: o que ele faz e como ele faz. Há um
boa razão para isso - é precisamente sua paixão por esses detalhes
que torna os programadores bons no que fazem. Mas esse foco
significava que os programadores gravitariam em direção à construção de um sistema
da maneira que fosse tecnicamente mais eficiente, sem levar em consideração
o que funcionou melhor para os usuários. Especialmente de volta quando o poder de computação
era um recurso limitado, a melhor abordagem era aquela que
trabalho feito dentro dessas limitações técnicas.
A abordagem que funciona melhor para a tecnologia quase nunca é
a abordagem que funciona melhor para a pessoa que a utiliza. Assim, softwares
adquiriu a reputação que o assombrou durante a maior parte de sua existência:
O software é complicado, confuso e difícil de usar. Isso é por que,
durante anos, “alfabetização de computador” – ensinando as pessoas sobre o
funcionamento dos computadores - foi amplamente considerado como a única maneira
para fazer usuários e software se darem bem.
Demorou muito, mas à medida que aprendemos mais sobre como as pessoas usavam
tecnologia, eventualmente começamos a entender que,
em vez de projetar o software que funciona melhor para a máquina,
poderíamos projetar o software que funciona melhor para as pessoas que usam
isso, pulando todo esse negócio de enviar arquivistas para
aulas de programação para melhorar seus conhecimentos de informática. O novo
disciplina que surgiu para ajudar os desenvolvedores de software a fazer isso é chamada
projeto de interação.
Modelos conceituais
As impressões dos usuários sobre como os componentes interativos que criamos
irá se comportar são conhecidos como modelos conceituais. Por exemplo, faz
o sistema trata um recurso específico como algo que o usuário consome,
um lugar que o usuário visita ou um objeto que o usuário adquire? Sites diferentes
tomar diferentes abordagens. Conhecer seu modelo conceitual permite
que você tome decisões de design consistentes. Não importa se
o elemento de conteúdo é um lugar ou um objeto; o que importa é que
site se comporta de forma consistente, em vez de tratar o elemento como um lugar
algumas vezes e um objeto em outras.
Por exemplo, o modelo conceitual para a composição do carrinho de compras
mento de um site de comércio eletrônico típico é o de um contêiner. Esta meta
conceito fórico influencia tanto o design do componente quanto
a linguagem que usamos na interface. Um contêiner contém objetos; Como
como resultado, “colocamos coisas” e “tiramos coisas” do “carrinho”,
e o sistema deve fornecer funções para realizar essas tarefas.
Suponha que o modelo conceitual para o componente fosse diferente
analógico do mundo real, como um formulário de pedido de catálogo. O sistema
pode fornecer uma função de edição que substituiria tanto o add
e remover funções do carrinho tradicional, e ao invés de usar um
metáfora de checkout para completar o processo, os usuários podem enviar seus
pedidos em.
Tanto o modelo de loja de varejo quanto o modelo de catálogo parecem perfeitamente
adequado para permitir que os usuários façam pedidos pela Web. Para o que
escolher? O modelo de loja de varejo é tão amplamente utilizado na Web que
é assumido o status de uma convenção. Se seus usuários fizerem muito
comprando em outros sites, você provavelmente vai querer manter isso
convenção. Usando modelos conceituais as pessoas já estão familiarizadas
com torna mais fácil para eles se adaptarem a um site desconhecido. Do
claro, não há nada de errado em romper com a convenção
também - contanto que você tenha uma boa razão para fazê-lo e tenha um
modelo conceitual alternativo que atenderá às necessidades de seus usuários enquanto
ainda fazendo sentido para eles. Modelos conceituais desconhecidos são apenas
eficazes quando os usuários podem entendê-los e interpretá-los corretamente.
Um modelo conceitual pode se referir a apenas um componente de um sistema ou
ao sistema como um todo. Quando o site de notícias e comentários Slate
lançado, seu modelo conceitual era uma revista do mundo real: o site
tinha uma frente e um verso, e cada página tinha um número de página
e elementos de interface que permitem ao usuário “virar a página”. Como é
acontece que o modelo conceitual da revista não se traduz muito
efetivamente para a Web, e Slate acabou abandonando-o.
Não precisamos comunicar nossos modelos conceituais aos nossos usuários
explicitamente - na verdade, às vezes isso apenas confunde os usuários
de ajudá-los. É mais importante que os modelos conceituais sejam
usado de forma consistente ao longo do desenvolvimento da interação
Projeto. Compreender os modelos que os próprios usuários trazem para o
site (Funciona como uma loja de varejo? Funciona como um catálogo?)
nos ajuda a escolher os modelos conceituais que funcionarão com mais eficácia
tivamente. Idealmente, os usuários não terão que ser informados sobre quais conceitos
modelo que estamos seguindo; eles vão perceber isso intuitivamente à medida que usam
o site porque o comportamento do site corresponderá ao seu implícito
expectativas.
Baseando nossos modelos conceituais em metáforas envolvendo o mundo real
análogos às funções do sistema podem ser valiosos, mas é importante não
tomar nossas metáforas muito literalmente. A página inicial do site para
A Southwest Airlines costumava consistir apenas na foto de um cliente
balcão de atendimento, com uma pilha de folhetos ao lado, um telefone
para o outro lado, e assim por diante. Durante anos, o local foi considerado um
exemplo de um modelo conceitual que foi longe demais - colocar uma reserva
ção pode ser análoga a fazer uma chamada telefônica, mas isso não
significa que o sistema de reservas deve ser representado por um
Telefone. Southwest deve ter se cansado de ser usado como um mau
exemplo; seu site posteriormente tornou-se luz na metáfora e con
consideravelmente mais funcional.
O velho sudoeste
O site das companhias aéreas é um clássico
exemplo de conceito
modelos sendo amarrados também
próximo ao mundo real

homólogos.
Manipulação de erros
Uma grande parte de qualquer projeto de design de interação envolve lidar com
erro do usuário - o que o sistema faz quando as pessoas cometem erros,
e o que o sistema pode fazer para evitar que esses erros aconteçam
pendurando em primeiro lugar?
A primeira e melhor defesa contra erros é projetar o sistema de modo
que os erros são simplesmente impossíveis. Um bom exemplo desse tipo de
defesa pode ser vista em qualquer carro com transmissão automática.
Dar partida no carro com a transmissão engatada pode danificar o
mecanismo de transmissão sensível e complexo; além disso, o carro
não começa realmente, mas em vez disso avança abruptamente. Mau
para o carro, ruim para o motorista e possivelmente ruim para um inocente
espectador que por acaso está no caminho do carro balançando.
Para evitar isso, qualquer carro com transmissão automática é projetado
para que o motor de partida não engate a menos que a transmissão seja desengatada.
Porque é impossível ligar o carro com a transmissão
engatado, o erro nunca acontece. Infelizmente não é bem assim
fácil tornar a maioria dos erros do usuário impossíveis dessa maneira.
A próxima melhor coisa para tornar os erros impossíveis é torná-los
meramente difícil. Mas mesmo com tais medidas em vigor, alguns erros
estão fadados a acontecer. Neste ponto, o sistema deve fazer o que
pode ajudar o usuário a descobrir o erro e corrigi-lo. Em alguns casos, o
sistema pode até corrigir o erro em nome do usuário. Mas tenha cuidado-
alguns dos comportamentos mais irritantes dos produtos de software resultam
de esforços bem intencionados para corrigir erros do usuário. (Se você já
usei o Microsoft Word, você sabe exatamente do que estou falando.

Cada camada de erro

manipulação em seu
design de interação
garante um maior
porcentagem de usuários
terá positivo
experiências.
recuperação
prevenção correção
O Word oferece vários recursos destinados a corrigir erros comuns;
invariavelmente, eu me pego desligando-os para que eu possa parar de corrigir
as correções e fazer algum trabalho.)
Mensagens de erro úteis e interfaces fáceis de interpretar podem ajudar
os usuários detectam muitos tipos de erros depois que eles acontecem. Mas alguns
as ações do usuário podem não parecer erros até que seja tarde demais para o
sistema para pegá-los. Nesses casos, o sistema deve fornecer um
maneira para os usuários se recuperarem do erro. O exemplo mais conhecido de
esta é a famosa função desfazer, mas a recuperação de erros pode levar muitos
formas diferentes. Para erros que não podem ser recuperados, fornecendo
muito aviso é o único meio de prevenção que o sistema pode
providenciar. Claro, este aviso só é eficaz quando os usuários
aliado notá-lo. Incluindo muitos "Tem certeza?" confirmações
pode fazer com que os realmente importantes sejam esquecidos - e muitas vezes
incomoda mais usuários do que ajuda.
Arquitetura de informação
A arquitetura da informação é uma ideia nova, mas é uma prática antiga - em
na verdade, pode-se dizer que é tão antigo quanto a própria comunicação humana. Por
desde que as pessoas tenham informações para transmitir, elas tiveram que
fazer escolhas sobre como eles estruturam essa informação para que outros
as pessoas podem entendê-lo e usá-lo.
Porque a arquitetura da informação está preocupada com a forma como as pessoas
processar cognitivamente a informação, a arquitetura da informação considera
surgem em qualquer produto que exija que os usuários façam sentido
das informações apresentadas. Obviamente, essas considerações são

crítico no caso de produtos orientados à informação (como
sites de informação), mas eles podem ter um enorme impacto mesmo em mais
produtos orientados à funcionalidade (como um telefone celular).
Estruturando Conteúdo
Nos sites de conteúdo, a arquitetura da informação se preocupa com a criação
esquemas organizacionais e de navegação que permitem aos usuários
mover-se pelo conteúdo do site de forma eficiente e eficaz. Em formação
arquitetura na Web está intimamente relacionada ao campo da informação
recuperação: o projeto de sistemas que permitem aos usuários encontrar informações
facilmente. Mas as arquiteturas de sites da Web são frequentemente chamadas a fazer
mais do que apenas ajudar as pessoas a encontrar coisas; em muitos casos, eles precisam
educar, informar ou persuadir os usuários.
Mais comumente, os problemas de arquitetura da informação requerem
esquemas de categorização que corresponderão ao nosso próprio objetivo
para o site, as necessidades do usuário que pretendemos atender e o conteúdo
que será incorporado ao site. Podemos lidar com a criação de tais
um esquema de categorização de duas maneiras: de cima para baixo, ou de
o de baixo para cima.
Uma abordagem de cima para baixo para a arquitetura da informação envolve
a arquitetura diretamente a partir de uma compreensão da estratégia
considerações de plano: objetivos do produto e necessidades do usuário. Iniciando
com as categorias mais amplas de conteúdo e funcionalidade possíveis
necessários para atingir esses objetivos estratégicos, então quebramos o gato
egorias em subseções lógicas. Essa hierarquia de categorias
e subcategorias serve como o shell vazio no qual o conteúdo
e a funcionalidade será alocada.

Uma abordagem de baixo para cima para a arquitetura da informação também deriva
categorias e subcategorias, mas o faz a partir de uma análise
o conteúdo e os requisitos funcionais. Começando pela fonte
material que existe (ou que existirá quando o site for lançado),
agrupamos os itens em categorias de baixo nível e depois agrupamos
aqueles em categorias de nível superior, construindo em direção a uma estrutura que
reflete os objetivos do nosso produto e as necessidades do usuário.
Um de cima para baixo
arquitetônico
abordagem é impulsionada por
considerações do
plano de estratégia.
categorias
contente
Um de baixo para cima
arquitetônico
abordagem é impulsionada por
considerações do
plano de escopo.
categorias
contente
Nenhuma abordagem é melhor que a outra. Abordar a arquitetura de cima para
baixo às vezes pode causar detalhes importantes
sobre o conteúdo em si a ser ignorado. Por outro lado, um
abordagem de baixo para cima às vezes pode resultar em uma arquitetura tão
precisamente ajustado e ajustado ao conteúdo existente que não é flexível o
suficiente para acomodar mudanças ou acréscimos. Golpeando uma bola
A relação entre o pensamento de cima para baixo e o pensamento de baixo para cima é a
única maneira de garantir que o resultado final possa evitar essas armadilhas.
Não é necessário aderir a um determinado número de categorias
em qualquer nível ou em qualquer seção da arquitetura. As categorias
só precisam ser os corretos para seus usuários e suas necessidades. Algum
as pessoas preferem contar o número de passos necessários para completar um
tarefa ou o número de cliques necessários para um usuário alcançar um determinado
destino como forma de avaliar a qualidade da estrutura de um site. o
sinal mais importante de qualidade, no entanto, não é quantos passos
o processo levou, mas se cada passo fazia sentido para o usuário e
se seguiu naturalmente da etapa anterior. Os usuários irão
invariavelmente favorecem um processo de sete etapas claramente definido em vez de um confuso
alternativa de três etapas ingly comprimida.
Web sites são entidades vivas. Eles exigem cuidados constantes e alimentação
ing. Inevitavelmente, eles crescem e mudam com o tempo. Na maioria dos casos, um
alguns novos requisitos adquiridos ao longo do caminho não devem exigir
repensando a estrutura geral do site. Uma característica de um eficaz
estrutura é sua capacidade de acomodar o crescimento e se adaptar à mudança.
Mas a acumulação de novos conteúdos acabará por exigir uma
exame dos princípios de organização empregados no site. Por
Por exemplo, a arquitetura que permitia aos usuários paginar através da imprensa
lançamentos do dia-a-dia poderia ter sido bom quando você tinha apenas alguns
meses, mas organizá-los por tópico pode ser mais prático
cal depois de alguns anos.
Toda a experiência do usuário, incluindo a estrutura do site, é
construído sobre uma compreensão de seus objetivos e as necessidades de sua
usuários. Se o que você deseja realizar com o site for redefinido ou
as necessidades que você pretende que o site atenda mudam, esteja preparado para retrabalhar
a estrutura do seu site em conformidade. A necessidade de tal estrutura
a mudança raramente se anuncia com antecedência; muitas vezes, pelo
tempo você pode dizer que precisa retrabalhar a arquitetura, seu
os usuários já estão sofrendo.

Um adaptável
arquitetura pode
acomodar o
adição de novo conteúdo
dentro de uma seção (topo)

bem como todo novo
seções (parte inferior).
Abordagens arquitetônicas
A unidade básica das estruturas de informação é o nó. Um nó pode
corresponder a qualquer pedaço ou grupo de informação - pode ser tão pequeno
como um único número (como o preço de um produto) ou tão grande quanto uma
biblioteca inteira. Ao lidar com nós em vez de páginas, docu
mentos, ou componentes, podemos aplicar uma linguagem comum e um conjunto
comum de conceitos estruturais a uma gama diversificada de problemas.
A abstração de nós também nos permite definir explicitamente o nível de detalhe
com o qual estaremos preocupados. A maioria dos projetos de arquitetura de sites
ects se preocupam apenas com a disposição das páginas no site; ao identificar a
página como nosso nó de nível básico, tornamos explícito
que não estaremos lidando com nada menor. Se a própria página for
muito pequeno para o projeto em questão, podemos fazer com que cada nó corresponda
para uma seção inteira do site. Se a página for muito grande, podemos definir
nós como elementos de conteúdo individuais dentro da página e a página
como um grupo de nós.
Esses nós podem ser organizados de muitas maneiras diferentes, mas esses
estruturas realmente se enquadram em apenas algumas classes gerais.
Em uma estrutura hierárquica – às vezes chamada de árvore ou hub – e
estrutura spoke —os nós têm relacionamentos pai/filho com outros
nós relacionados. Os nós filhos representam conceitos mais restritos dentro do
categoria mais ampla representada pelo nó pai. Nem todo nó
tem filhos, mas cada nó tem um pai, levando todo o caminho para cima
para o nó pai de toda a estrutura (ou a raiz da árvore,
se você preferir). Porque o conceito de relacionamentos hierárquicos é
bem compreendido pelos usuários e porque o software tende a funcionar em
hierarquias de qualquer maneira, este tipo de estrutura é de longe o mais
comum.
Estrutura hierárquica.
Uma estrutura de matriz permite que o usuário se mova de nó para nó
ao longo de duas ou mais dimensões. As estruturas matriciais são frequentemente usadas
completo para permitir que usuários com diferentes necessidades naveguem pelo
mesmo conteúdo, pois cada necessidade do usuário pode ser associada a um

eixo da matriz. Por exemplo, se alguns de seus usuários realmente quiserem
para navegar pelos produtos por cor, mas outros precisam navegar por tamanho,
uma matriz pode acomodar ambos os grupos. Uma matriz de mais de
três dimensões podem causar problemas, no entanto, se você espera que os usuários
confiar nele como sua principal ferramenta de navegação. O cérebro humano
simplesmente não está muito bem equipado para visualizar o movimento em quatro ou
mais dimensões.
Estrutura matriz.
As estruturas orgânicas não tentam seguir nenhum padrão consistente.
Os nós são conectados caso a caso, e os
a arquitetura não tem um conceito forte de seções. Estruturas orgânicas
são bons para explorar um conjunto de tópicos cuja relação não é clara
ou evoluindo. Mas as estruturas orgânicas não fornecem aos usuários uma
forte senso de onde eles estão na arquitetura. Se você quiser
para encorajar um sentimento de exploração de forma livre, como em alguns
sites de entretenimento ou educacionais, uma estrutura orgânica pode ser um
boa escolha; no entanto, pode representar um desafio se seus usuários precisarem
para encontrar o caminho de volta de forma confiável para o mesmo conteúdo novamente.
Estrutura orgânica.
Estruturas sequenciais são aquelas com as quais você está mais familiarizado
de mídia offline — na verdade, você está experimentando uma agora.
O fluxo sequencial da linguagem é o tipo mais básico de informação
arquitetura de informação que existe, e as faculdades necessárias para processá-la são
construído diretamente em nossos cérebros. Livros, artigos, áudio e vídeo são
tudo projetado para ser experimentado de forma sequencial. Sequencial
estruturas na Web são usadas com mais frequência para estruturas de menor escala
turas como artigos ou seções individuais; sequencial em grande escala
estruturas tendem a ser limitadas a aplicações em que a ordem de
apresentação de conteúdo é essencial para atender às necessidades do usuário, como na
material instrucional.
Estrutura sequencial.
Princípios de Organização
Os nós em uma estrutura de informação são organizados de acordo com a organização.
princípios nistas. Em seu nível mais básico, o princípio organizador
é o critério pelo qual determinamos quais nós são agrupados
juntos e que são mantidos separados. Princípio organizador diferente
princípios serão aplicados em diferentes áreas e em diferentes níveis de

o site.
Por exemplo, no caso de um site de informações corporativas, podemos
temos categorias perto do topo da nossa árvore, como "Consumidor", "Busi
ness” e “Investidor”. Nesse nível, o princípio organizador é a
público para o qual o conteúdo se destina. Outro site pode ter
categorias de nível superior, como "América do Norte", "Europa" e "África".
Usar a geografia como um princípio organizador é uma abordagem para
atendendo às necessidades de um público global.
Geralmente, os princípios de organização que você emprega no mais alto nível
els do seu site estão intimamente ligados aos objetivos do produto e usuário
precisa. Em níveis mais baixos da arquitetura, questões específicas do
requisitos de tenda e funcionais começam a ter maior influência
sobre os princípios de organização que devem ser usados.
Por exemplo, um site com conteúdo voltado para notícias geralmente terá
cronologia como seu princípio organizador mais proeminente. Pontualidade
é o fator mais importante para os usuários (que, afinal, procuram
sites de notícias para informações sobre eventos atuais, não história), bem como
para os criadores do site (que devem enfatizar a oportunidade de
seu conteúdo para se manterem competitivos).

No próximo nível da arquitetura, outros fatores mais próximos
ligados ao conteúdo entram em jogo. Para um site de notícias esportivas, o conteúdo
podem ser divididos em categorias como “Beisebol”, “Tênis” e
"Hóquei"; um site de interesse mais geral pode ter categorias como
“Notícias Internacionais”, “Notícias Nacionais” e “Notícias Locais”.
Qualquer coleção de informações - quer consista em dois itens,
200, ou 2.000 — tem uma estrutura conceitual inerente. Na verdade, é
geralmente tem mais de um. Isso é parte do problema que temos que
resolver. O desafio não é criar uma estrutura, mas criar a
estrutura para nossos objetivos e as necessidades de nossos usuários.
Por exemplo, suponha que nosso site contenha um repositório de informações
ção sobre carros. Um princípio organizador possível seria organizar
as informações de acordo com o peso do carro em questão. Então
a primeira coisa que o usuário veria seriam informações sobre o
carro mais pesado em nosso banco de dados, depois o segundo mais pesado, e assim por diante
ao mais leve.
Para um site de informações ao consumidor, esta é provavelmente a maneira errada
para organizar as informações. A maioria das pessoas, na maioria das vezes, não
preocupado com o peso de um carro. Organizando as informações
de acordo com a marca, modelo ou tipo de carro provavelmente seria mais
adequado para este público. Por outro lado, se nossos usuários
profissionais que lidam diariamente com o negócio de transporte
carros no exterior, o peso se torna um fator muito importante. Para estes
pessoas, qualidades como economia de combustível e tipo de motor são consideradas
possivelmente menos importantes, se é que importam.

Esses atributos, na linguagem da biblioteconomia, são conhecidos como
facetas, e eles podem fornecer um conjunto simples e flexível de organização
princípios para quase qualquer conteúdo. Mas como o exemplo anterior
mostra, usar as facetas erradas pode ser pior do que não usar facetas
de forma alguma. Uma resposta comum a este problema é posicionar cada
faceta concebível como um princípio organizador e deixar os usuários escolherem
aquele que é importante para eles.
Infelizmente, a menos que você esteja lidando com informações muito simples
consistindo em apenas algumas facetas, essa abordagem logo transforma o arqui
transformar em uma bagunça pesada. Os usuários têm tantas opções para
classificar através de que ninguém pode encontrar nada. A carga não deve
estar no usuário para classificar todos os atributos e escolher o que é
importante - o fardo está sobre nós. A estratégia nos diz o que o
os usuários precisam, e o escopo nos diz quais informações atenderão a esses
precisa. Ao criar a estrutura, identificamos os aspectos específicos da

aquela informação que estará em primeiro lugar na mente dos usuários. Um sucesso
A experiência do usuário final é aquela em que as expectativas do usuário são
previsto e contabilizado.
Idioma e metadados
Mesmo que a estrutura seja uma representação perfeitamente precisa do
como as pessoas pensam sobre seu assunto, seus usuários não serão
capazes de encontrar seu caminho na arquitetura se não puderem
mantenha sua nomenclatura: as descrições, rótulos e outros
terminologia que o site usa. Por esta razão, é fundamental utilizar o
idioma de seus usuários e fazê-lo de forma consistente. o
ferramenta que usamos para impor essa consistência é chamada de controle
vocabulário.
Um vocabulário controlado nada mais é do que um conjunto de padrões

termos de uso no site. Esta é outra área em que a pesquisa de usuários
é essencial. Conversando com os usuários e entendendo como eles se comunicam
nicado é a maneira mais eficaz de desenvolver um sistema de nomenclatura
que vai parecer natural para eles. Criando e aderindo a um controle
vocabulário que reflita o idioma de seus usuários é a melhor maneira
para evitar que o jargão interno da sua organização se espalhe
o site, onde apenas confundirá seus usuários.
Vocabulários controlados também ajudam a criar consistência em todos os seus
contente. Se as pessoas responsáveis pela produção do conteúdo
sentados um ao lado do outro ou em escritórios em continentes separados, os
vocabulário controlado fornece um recurso definitivo para garantir que
todos estão falando a língua do usuário.
Uma abordagem mais sofisticada para controlar o vocabulário é criar
comeu um dicionário de sinônimos. Ao contrário de uma simples lista de termos aprovados, um dicionário de sinônimos
rus também documentará termos alternativos que são comumente usados
mas não aprovado para uso no site. Com um dicionário de sinônimos, você pode
mapear jargões internos, taquigrafias, gírias ou acrônimos para seus
homólogos aprovados. Um dicionário de sinônimos também pode incluir outros tipos
das relações entre os termos, fornecendo recomendações para
termos mais amplos, mais restritos ou relacionados. Documentando essas relações
navios podem lhe dar uma visão mais completa de toda a gama de
conceitos encontrados em seu conteúdo, que por sua vez podem sugerir
abordagens arquitetônicas tradicionais.
Ter um vocabulário controlado ou tesauro pode ser especialmente útil
completo se você decidir construir um sistema que inclua metadados. O termo
metadados significa simplesmente “informações sobre informações”. Isso se refere a
uma abordagem estruturada para descrever um determinado conteúdo.

Suponha que estivéssemos lidando com um artigo sobre como seu último
produto está sendo usado por bombeiros voluntários. Alguns dos
metadados para esse artigo podem incluir
. O nome do autor
. A data em que a peça foi postada
. O tipo de peça (por exemplo, um estudo de caso ou artigo)
. O nome do produto
. O tipo de produto
. A indústria do cliente (por exemplo, bombeiros voluntários
departamento)
. Tópicos relacionados (por exemplo, agências municipais ou
serviços de emergência)
Ter essas informações nos permite considerar uma série de possíveis
abordagens arquitetônicas que seriam difíceis (se não totalmente
impossível) implementar sem ele. Em suma, quanto mais detalhado
informações que você tem sobre seu conteúdo, mais flexibilidade
você tem ao estruturá-lo. Se os serviços de emergência de repente mostrarem
potencial como um novo mercado lucrativo para a empresa se expandir,
ter esses metadados nos permitirá criar rapidamente uma nova seção
para atender as necessidades desses usuários com o conteúdo que já temos.
Mas criar sistemas técnicos para coletar e rastrear toda essa meta
os dados não nos ajudarão se os dados em si não forem consistentes. Isso e onde
vocabulários controlados entram. Usando apenas um termo para cada
conceito único em seu conteúdo, você pode contar com a automação para
ajudam a definir as conexões entre seus elementos de conteúdo. Sua
o site pode vincular dinamicamente todas as páginas de um tópico específico
sem que ninguém precise fazer nada além de usar o mesmo
termo consistentemente em seus metadados.

Além disso, bons metadados podem fornecer uma informação mais rápida e confiável.
maneira para seus usuários encontrarem informações em seu site do que um
motor de busca de texto pode fornecer. Os motores de busca podem ser poderosos,
mas em geral eles são muito, muito burros - você dá a eles uma série de
caracteres, e eles praticamente procuram exatamente essa string
de personagens. Eles não entendem o que isso significa.
Conectando seu mecanismo de pesquisa com um dicionário de sinônimos e fornecendo
metadados para seu conteúdo podem ajudar a tornar o mecanismo mais inteligente. o
mecanismo de pesquisa pode usar o dicionário de sinônimos para mapear uma pesquisa por um disal
termo reduzido para um termo preferido; então ele pode verificar os metadados para
esse termo preferido. Em vez de não obter nenhum resultado, o usuário obtém
resultados altamente direcionados e relevantes - e talvez até algumas recomendações
menções para outros assuntos relacionados que possam ser de interesse.
Funções e processos da equipe
Os documentos necessários para descrever a estrutura de um site - desde o
detalhes específicos de nomenclatura e metadados para o quadro geral de
arquitetura geral da informação e design de interação - pode variar
dependendo da complexidade do projeto. Para projeto
ects envolvendo muito conteúdo em uma estrutura hierárquica,
contornos de texto podem ser uma maneira eficaz de documentar a arquitetura.
Em alguns casos, ferramentas como planilhas e bancos de dados serão pressionados
em serviço para ajudar a capturar as nuances de uma arquitetura complexa.
Mas a principal ferramenta de documentação para arquitetura de informação ou
design de interação é o diagrama. Representando a estrutura visu
ally é a forma mais eficiente de comunicarmos as filiais,
grupos e inter-relações entre os componentes do nosso site.

As estruturas de sites da Web são coisas inerentemente complicadas; tentando
transmitir essa complexidade em palavras praticamente garante que nenhum

um vai lê-los.
Nos primórdios da Web, esse tipo de diagrama era chamado de site
mapa; mas como o mapa do site também é um termo usado para um tipo específico de
ferramenta de navegação em um site (sobre a qual você lerá mais no Cap.
ter 6), diagrama de arquitetura é agora o termo preferido para a ferramenta que
usamos internamente para descrever a estrutura do site.
O diagrama não precisa documentar todos os links em todas as páginas
em seu site. Na verdade, na maioria dos casos, esse nível de detalhe serve apenas
para confundir e obscurecer as informações que a equipe realmente precisa. Isso é
mais importante documentar as relações conceituais: Qual gato
egories andam juntas, e quais permanecem separadas? Como os passos
em uma dada sequência de interação se encaixam?
No início de minha carreira, me vi tendo que expressar a mesma
estruturas de interação repetidas vezes de projeto para projeto.
Com o tempo, comecei a padronizar a maneira como ilustrava minhas ideias em
meus diagramas de site. Eu estabeleci um conjunto particular de formas que usei,
e definiu o que cada uma dessas formas significava.
O sistema que criei para diagramar as estruturas do site é chamado de Visual
Vocabulário. Desde que a publiquei pela primeira vez na Web em 2000, informações
arquitetos e designers de interação em todo o mundo têm
o adotou. Você pode aprender mais sobre o Vocabulário Visual, consulte
diagramas de amostra e ferramentas de download para usá-lo em meu site:
www.jjg.net/ia/visvocab/.
O vocabulário visual
casa é um sistema de
diagramação
arquiteturas que variam
do muito simples
(topo) até o
informações de mídia produtos Apoio, suporte complexo (parte inferior).
Veja www.jjg.net/ia/
visvocab/ para mais
detalhes.
casa
produtos
Arquivo
comunicados de imprensa
arquivos
escritório
produtos
continuar de:
fluxo de login últimas notícias
casa
(2c)
continua a:
página de entrada (2a)
lista de membros
técnico
papéis
Muitas organizações empregam designers de experiência do usuário em tempo integral
responsáveis pelas questões estruturais. Em outras organizações,
no entanto, a responsabilidade pela estrutura muitas vezes cai no colo de alguém
por padrão e não por meio de planejamento consciente. Quem acaba
responsável pela estrutura muitas vezes depende da cultura da organização
nização ou a natureza do projeto.
Para sites com conteúdo pesado ou em organizações nas quais a criação de um
presença na Web foi inicialmente vista como uma atividade de marketing,
a responsabilidade de determinar a estrutura do site tem
residia no desenvolvimento de conteúdo, editorial ou marketing com
grupos de comunicações. Se a organização tem sido historicamente liderada
por pessoas técnicas ou tinham uma cultura interna orientada para a tecnologia,
A responsabilidade pela estrutura geralmente recai sobre os técnicos
gerente de projeto trabalhando no site.
Cada projeto pode se beneficiar de ter um dedi especialista em tempo integral
voltada para questões estruturais. Às vezes essa pessoa vai pelo trabalho
designer de interação do título, mas outros preferem ser referidos como um
arquiteto da informação. Não deixe o título confundir você - embora
é verdade que alguns arquitetos de informação se especializam exclusivamente em
criar esquemas organizacionais e estruturas de navegação para
sites de conteúdo, na maioria das vezes, um arquiteto de informação
ter algum grau de experiência com questões de design de interação e
vice-versa. Porque a arquitetura da informação e o design de interação
problemas são muitas vezes tão intimamente relacionados, o designer de experiência do usuário tem
tornar-se um título mais comum para alguém com essas habilidades.
Sua organização pode não ter o volume de trabalho contínuo para
garante a contratação de um designer de experiência do usuário em tempo integral como permanente
membro de sua equipe. Se seus esforços de desenvolvimento Web são principalmente

limitado a manter o conteúdo que você tem atualizado e você não
fazer muito desenvolvimento novo entre projetos de redesenho em todo o site
a cada dois anos, um designer de experiência do usuário da equipe provavelmente não é
uma boa maneira de gastar seu dinheiro. Mas se você tiver um fluxo constante
de novos conteúdos e funcionalidades sendo adicionados ao seu site, um usuário
designer de experiência pode ajudá-lo a gerenciar esse processo da maneira
que será mais eficaz para atender às necessidades de seus usuários e
para atingir seus próprios objetivos estratégicos.
Se você tem um especialista para lidar com questões estruturais não é
importante, mas é importante que essas preocupações sejam abordadas por
alguém. Seu site terá uma estrutura planejada ou não
Fora. Os locais que são construídos de acordo com um plano estrutural claro tendem a
serem os que requerem revisões menos frequentes, produzem
criar resultados para seus proprietários e satisfazer as necessidades de seus usuários.

capítulo 6
O esqueleto
Avião
Design de interface, design de
navegação e design de informação
Superfície
Esqueleto
A estrutura conceitual começa a dar forma Estrutura
a massa de requisitos decorrentes de nossa estratégia

Alcance
Objetivos. No plano do esqueleto, refinamos ainda mais
Estratégia
essa estrutura, identificando aspectos específicos de
face, navegação e design de informação que
tornar concreta a estrutura intangível.
Interação tivemos
formação
Em
Contente
Requisitos
Funcional
Especificações
nt
e
108 CAPÍTULO 6 O PLANO ESQUELETO
Definindo o esqueleto
O plano de estrutura abordado no capítulo anterior define como nosso
produto funcionará; o plano do esqueleto define a forma que
funcionalidade vai demorar. Além de abordar mais concreto
questões de apresentação, o plano esqueleto trata de assuntos que
envolvem um nível de detalhe mais refinado. No plano da estrutura,
analisamos as questões de arquitetura e interação em grande escala; sobre
No plano do esqueleto, nossas preocupações existem quase
exclusivamente na escala menor de componentes individuais e seus relacioname
No lado da funcionalidade, definimos o esqueleto por meio do design

de interface - o domínio familiar de botões, campos e outras interfaces
componentes. Mas os produtos de informação têm um conjunto único
de problemas próprios. O design de navegação é a forma especializada de
design de interface sob medida para apresentar espaços de informação.
Por fim, cruzando os dois lados, temos o design da informação, a apresentação
de informação para uma comunicação eficaz.

superfície
esqueleto
estrutura
Esses três elementos estão intimamente ligados - mais do que
qualquer um dos outros elementos abordados neste livro. Não é incomum
mon para enfrentar problemas de design de navegação que começam a se confundir
em problemas de design de informação, ou para encontrar questões sobre
design de informação que acabam por ser questões de design de interface.
Mesmo que as linhas às vezes fiquem embaçadas, identificá-las como
áreas de preocupação separadas nos ajuda a avaliar melhor se
resolvido em uma solução adequada. Um bom design de navegação não pode corrigir
design de informação ruim. Se não podemos dizer a diferença entre o
tipos de problemas, não podemos dizer se realmente os resolvemos.
Se envolve fornecer aos usuários a capacidade de fazer coisas, é inter
desenho de rosto. A interface é o meio pelo qual os usuários realmente
entrar em contato com a funcionalidade definida na especificação
ções e estruturadas no design de interação.
Se envolve fornecer aos usuários a capacidade de ir a lugares, é navi
projeto de portão. A arquitetura da informação aplicou uma estrutura para
os requisitos de conteúdo que desenvolvemos; o projeto de navegação é
a lente através da qual o usuário pode ver essa estrutura, e é a
meio pelo qual o usuário pode se mover por ele.
Se envolver a comunicação de ideias ao usuário, é informação
Projeto. Este é o mais amplo dos três elementos neste plano,
potencialmente incorporando ou aproveitando aspectos de quase
tudo o que vimos até agora no lado da funcionalidade e
o lado da informação. O design da informação cruza a fronteira
entre funcionalidade orientada a tarefas e sistemas orientados a informações
porque nem o design de interface nem o design de navegação podem ser
totalmente bem-sucedidos sem um bom design de informações para apoiá-los.

Convenção e Metáfora
Hábito e reflexo são a base para grande parte de nossa interação
com o mundo - de fato, se não pudéssemos reduzir tanto
o que fazemos para refletir, realizaríamos muito menos a cada dia.
Você pode imaginar se dirigir um carro nunca ficou mais fácil do que era
a primeira vez que você tentou? Sua capacidade de dirigir, cozinhar uma refeição ou
usar um telefone celular - sem ficar completamente exausto pelo
a tremenda concentração necessária para a tarefa depende do acúmulo de muitos
reflexos minúsculos.
A convenção nos permite aplicar esses reflexos em diferentes circunstâncias. Eu
costumava ter um carro que invariavelmente causava problemas quando
nunca algum dos meus amigos dirigiu. Quando ligaram o carro, a primeira coisa que
fizeram foi lavar o para-brisa. Isso não foi porque
eles achavam que o para-brisa estava sujo (embora provavelmente estivesse); em
vez disso, era porque eles estavam tentando acender os faróis.
Os controles do meu carro eram diferentes das convenções que eles
foram usados para.
Os telefones são outro bom exemplo da importância da convenção. De tempos em
tempos, os fabricantes têm experimentado
desvios do layout padrão de três por quatro para os botões em um telefone, como
duas fileiras de seis botões cada ou três fileiras
de quatro. Arranjos circulares ainda aparecem de tempos em tempos, mas estão se
tornando cada vez mais raros à medida que os telefones de discagem rotativa nas
em que se baseiam desaparecem nas brumas do esquecimento tecnológico.
Parece que o layout não deve fazer muita diferença,
mas sim. Se você mediu o tempo que um usuário gasta tentando descobrir
qual botão apertar em um telefone fora do padrão, ele pode
acabam por ser algo como três segundos por chamada. Não tão grande
uma diferença - mas para o usuário, esses três segundos não são apenas perdidos
Tempo. Esses três segundos estão cheios de pura frustração, como um
tarefa reflexiva torna-se dolorosamente lenta simplesmente porque o tapete da
convenção foi retirada de debaixo dos pés do usuário.
Na verdade, a matriz de três por quatro dígitos do telefone é tão bem
enraizado que se tornou o padrão para outros dispositivos que
não têm nada a ver com telefones, como fornos de microondas
ou controles remotos. Curiosamente, o teclado do telefone não é o único
padrão nesta área: O padrão de “10 teclas” usado pelos antigos
máquinas, que inverte a ordem dos dígitos no telefone
teclado, é usado em calculadoras, teclados, caixas eletrônicos, caixas registradoras e
em aplicativos especializados de entrada de dados, como sistemas de inventário.
Como ambos os padrões usam uma matriz de três por quatro, as pessoas podem
adaptar a qualquer um com relativa facilidade, embora um único padrão
realmente ser a melhor solução de todas.
Isso não quer dizer que a resposta para todo problema de interface seja
adesão escrava à convenção. Em vez disso, você deve simplesmente ser
cauteloso em desviar-se da convenção e só o faça quando um
abordagem diferente oferece benefícios claros. Criando um usuário de sucesso
experiência requer ter razões explicitamente definidas para cada
escolha que você faz.
Tornando sua interface consistente com outras que seus usuários estão
já familiarizado é importante, mas ainda mais importante é
tornando sua interface consistente consigo mesma. O modo conceitual
els para os recursos do seu produto podem ajudá-lo a garantir

consistência. Se você tiver dois recursos com o mesmo conceito
modelo, eles provavelmente terão requisitos de interface semelhantes. Usando
as mesmas convenções em ambos os lugares permitem que um usuário familiarizado
com um para se adaptar rapidamente ao outro.
Mesmo onde os modelos conceituais para recursos diferem, ideias que
aplicáveis em uma variedade de modelos conceituais devem ser tratados
de forma semelhante (se não idêntica) onde quer que apareçam. Conceitos como
“iniciar”, “terminar”, “voltar” ou “salvar” podem ser encontrados em uma ampla variedade de
contextos. Dar a eles um tratamento consistente permite que os usuários
aplicar o que eles já sabem de ter usado outras partes do
sistema, levando-os a seus objetivos mais rapidamente e com menos erros.
Assim como você não deve tomar os modelos conceituais subjacentes ao seu
design de interação muito literalmente, você deve resistir ao impulso de
construa seu produto em torno de uma série de metáforas concretas.
As metáforas para os recursos do seu produto são fofas e divertidas, mas
eles quase nunca funcionam tão bem quanto parece que deveriam. Na verdade, eles
muitas vezes não funcionam.
Em alguns casos, você pode estar inclinado a padronizar o design da interface
para uma função específica após a interface de um objeto do mundo real.
Lembre-se da navegação do Slate em que você poderia “virar” as páginas
como em uma revista real? A maioria das interfaces e navegação
dispositivos no mundo real são o produto das restrições do
mundo real: física, as propriedades dos materiais e assim por diante. Tela
produtos baseados, como sites e outros softwares, têm poucos
mesmas restrições.
Fazendo analogias entre os recursos do seu site e as experiências
que as pessoas têm no mundo real pode parecer uma boa maneira de ajudar
as pessoas entendem do que se tratam esses recursos. No entanto,
esse tipo de abordagem geralmente obscurece a natureza do recurso
em vez de revelá-lo. Mesmo que a associação entre o
característica e sua representação metafórica é clara para você, é apenas
uma de qualquer número de associações que seus usuários podem aplicar, especialmente
cialmente se esses usuários vierem de uma formação cultural diferente da
Você faz. O que significa aquela pequena imagem de um telefone? Vai
permite-me fazer uma chamada telefónica? Verificar meu correio de voz? Pague meu
conta de telefone?
É claro que o conteúdo do seu site deve fornecer algum grau de
contexto para ajudar os usuários a fazer melhores suposições sobre quais recursos seu
metáforas pretendem representar. Mas quanto mais diversificado o
variedade de conteúdo e funcionalidade que você oferece, menos confiáveis
suposições se tornam - e de qualquer forma, uma parte de seu público é
sempre vai adivinhar incorretamente. Seria melhor (e mais simples)
para eliminar completamente essa adivinhação.
Usar metáforas de forma eficaz é realmente apenas reduzir o
esforço necessário para os usuários se locomoverem e usarem a funcionalidade
do seu produto. Ter um ícone de uma lista telefônica para representar um
diretório real de números de telefone pode ser bom; tendo
uma foto de uma cafeteria para representar sua área de bate-papo é um pouco mais
problemático.
Design de interface
O design da interface consiste em selecionar os elementos de interface
corretos para a tarefa que o usuário está tentando realizar e organizá-los
na tela de uma forma que será facilmente compreendida e

usado. As tarefas geralmente se estendem por várias telas, cada uma contendo
um conjunto diferente de elementos de interface para o usuário lidar.
Quais funções acabam em quais telas é uma questão de interação
projetar no plano da estrutura; como essas funções são realizadas na tela
é o domínio do design de interface.
Interfaces bem-sucedidas são aquelas em que os usuários percebem
imediatamente as coisas importantes. Coisas sem importância, por outro lado, não
ser notado - às vezes porque não está lá. Um dos maiores desafios de
projetar interfaces para sistemas complexos é
descobrir com quais aspectos os usuários não precisam lidar e reduzir sua
visibilidade (ou deixá-los de fora completamente).
Para pessoas com experiência em programação, essa maneira de pensar
pode exigir alguns ajustes. Muitas vezes é muito diferente do que
eles estão acostumados a. Bons programadores sempre levam em conta os
cenários mais improváveis (chamados de “casos de borda” no jar de programação
vai). Afinal, a maior conquista para os programadores é criar um software
que nunca quebra; mas programação que não
conta para casos extremos provavelmente fará exatamente isso nessas
circunstâncias extremas. Assim, os programadores são treinados para tratar cada
caso igualmente, se representa um usuário ou mil.
Essa abordagem não funciona para design de interface. Uma interface que
dá a um pequeno número de casos extremos o mesmo peso que as necessidades

da grande maioria dos usuários acaba mal equipado para fazer tanto
platéia feliz. Uma interface bem projetada reconhece os cursos
de ação que os usuários são mais propensos a tomar e torna essas interfaces
elementos mais fáceis de acessar e usar.
Isso não significa que a solução para todo problema de interface seja
para fazer o botão os usuários são mais propensos a empurrar o maior.
Os designs de interface podem empregar uma variedade de truques para facilitar os usuários ao longo
o caminho para seus objetivos. Um truque simples é pensar cuidadosamente sobre
as opções padrão selecionadas quando a interface é apresentada pela primeira vez
o usuário. Se sua compreensão das tarefas e metas de seus usuários levar
você pensar que a maioria deles preferiria resultados de pesquisa detalhados em vez de
breves, deixando a caixa de seleção Mostrar mais detalhes marcada por
padrão significa que mais pessoas ficarão automaticamente satisfeitas com o que
recebem, independentemente de terem tido tempo para ler o rótulo
na caixa de seleção e tomar uma decisão por si mesmos. Melhor ainda é
um sistema que lembra automaticamente as opções que um usuário selecionou
a última vez que eles pararam, mas isso às vezes requer mais
acrobacias técnicas do que pareceria necessário na superfície,
e, como resultado, é impraticável para algumas equipes de desenvolvimento implementar
mento com sucesso.
Ferramentas e frameworks de tecnologia têm vantagens técnicas inerentes
restrições que limitam as opções de interface disponíveis para nós. Isso é verdade
aliado tanto ruim quanto bom. É ruim porque limita nossas oportunidades
para inovação - algumas abordagens de interface que podem ser possíveis
usando certas tecnologias pode ser impossível de realizar com outras
s. Mas essa situação também é boa, porque os usuários que aprendem como
trabalhar com um conjunto bastante pequeno de controles padrão pode aplicar isso
conhecimento em uma ampla gama de produtos.

Convenções de interface parecem que não deveriam mudar, mas elas
fazer, se muito lentamente. As novas tecnologias às vezes trazem a necessidade de
reexaminar as convenções existentes ou inventar algumas novas.
Os designers de experiência do usuário continuam buscando novas convenções para
tecnologias como controles gestuais e dispositivos touchscreen. A maioria
dos controles padrão que vemos em uma ampla variedade de
produtos originados com sistemas operacionais de computadores desktop como
Mac OS ou Windows. Esses sistemas operacionais oferecem um punhado de
elementos de interface padrão:
As caixas de seleção permitem que os usuários selecionem opções independentemente de uma
outro.
Os botões de opção permitem que os usuários selecionem uma opção entre um conjunto
de opções mutuamente exclusivas.
Os campos de texto permitem que os usuários — aguardem — insiram texto.

As listas suspensas fornecem a mesma funcionalidade que os botões de opção,
mas o fazem em um espaço mais compacto, permitindo muito mais
opções sejam apresentadas de forma eficiente.
As caixas de listagem fornecem a mesma funcionalidade que as caixas de seleção,
mas o fazem em um espaço mais compacto (porque as caixas de listagem rolam). Como com
dropdowns, isso permite que a caixa de listagem suporte facilmente um grande
número de opções.
Os botões de ação podem fazer muitas coisas diferentes. Normalmente, eles dizem ao
sistema para pegar todas as outras informações que o usuário
fornecido por meio de outros elementos de interface e faça alguma coisa - pegue
ação – com ela.
Algumas tecnologias fornecem esse mesmo conjunto de elementos básicos, mas não
forçar os designers a continuar usando-os, permitindo um maior grau
de flexibilidade em como a interface pode responder ao usuário. Vigarista
consequentemente, essas interfaces envolvem muito mais escolhas a serem feitas
durante o processo de design e tendem a ser mais difíceis de acertar.

As listas suspensas
podem atrapalhar os usuários
ocultando opções importantes
da visualização (esquerda). Rádio
botões exibem facilmente
todas as opções disponíveis (à
direita), mas ocupam mais
espaço no
Fazendo malabarismos com todos os diferentes elementos da interface e escolhendo entre
interface.
entre eles envolve inevitavelmente trade-offs. Verdade, esse dropdown
irá poupar algum espaço no ecrã relativo a um conjunto de rádios
botões, mas também ocultará as opções disponíveis do usuário.
Fazer com que as pessoas digitem as categorias que desejam pesquisar pode
coloca menos carga no banco de dados, mas coloca mais carga no usuário; E se
existem apenas seis para escolher de qualquer maneira, talvez algumas caixas de seleção
seria melhor.
Projeto de navegação
Projetar a navegação para a Web parece um negócio simples: colocar
links em todas as páginas que permitem aos usuários se locomover no site. Se você
arranhar a superfície, no entanto, as complexidades do projeto de navegação
tornar-se aparente. O design de navegação de qualquer site deve contemplar
realizar três gols simultâneos:
. Primeiro, deve fornecer aos usuários um meio para obter de um
apontar para outro no site. Porque geralmente é impraticável
cal (e mesmo quando prático, geralmente não é uma boa ideia)
para vincular a todas as páginas de todas as outras páginas, elemento de navegação
mentos devem ser selecionados para facilitar o comportamento real do usuário—
e, a propósito, isso significa que esses links precisam realmente
trabalhar, também.
. Em segundo lugar, o projeto de navegação deve comunicar a relação entre
os elementos que ele contém. Não é o suficiente
apenas para fornecer uma lista de links. O que esses links têm a ver uns
com os outros? Alguns são mais importantes que outros?
Quais são as diferenças relevantes entre eles? Este com
comunicação é necessária para que os usuários entendam quais opções
estão disponíveis para eles.
. Terceiro, o projeto de navegação deve comunicar a relação
ship entre seu conteúdo e a página que o usuário está visualizando no
momento. O que essas coisas têm a ver com o que
estou olhando agora? Comunicar isso ajuda os usuários a entender
quais das opções disponíveis podem oferecer melhor suporte
a tarefa ou objetivo que estão perseguindo.
Mesmo para produtos que não são orientados à informação - ou não são Web
sites — essas três considerações entram em jogo. A menos que todas as suas
funcionalidades se encaixem em uma única interface, você precisará de alguns
navegação para ajudar os usuários a se orientarem. Em um espaço físico, as pessoas
podem confiar até certo ponto em um senso inato de direção para
orientar-se. (É claro que algumas pessoas parecem estar perpetuamente perdidas.)
Mas os mecanismos em nosso cérebro que nos ajudam a encontrar nosso
no mundo físico (“Vamos ver, acho que a entrada por onde entrei deve estar atrás
de mim e à esquerda”) são totalmente
inútil para nos ajudar a encontrar nosso caminho em um espaço de informação.
É por isso que é de vital importância que cada página de um site
comunicar claramente aos usuários onde eles estão no site e onde podem ir. Até
que ponto os usuários se orientam na informação
espaços é uma questão de debate: algumas pessoas defendem fortemente a noção
de que os usuários fazem pequenos mapas em suas cabeças quando visitam
Sites da Web, assim como em lojas de hardware e bibliotecas; outros

alegam que os usuários dependem quase inteiramente da navegação e do wayfind
dando dicas na frente deles, como se cada passo que eles dessem no site
desapareceu de sua memória logo depois que eles o pegaram.
É difícil para nós saber exatamente como (ou quanto) as pessoas mantêm o
estrutura de sites da Web em suas cabeças. Sem esse conhecimento, o
melhor abordagem é assumir que os usuários não possuem nenhum conhecimento com
-los de página em página. (Afinal, se um motor de busca público como
O Google indexa seu site, qualquer página pode ser um ponto de entrada para seu
site de qualquer maneira.)
A maioria dos sites fornece vários sistemas de navegação, cada um
cumprindo um papel específico ao permitir que o usuário navegue no site
com sucesso em uma variedade de circunstâncias. Vários tipos comuns de
sistemas de navegação surgiram na prática.
Navegação global.
A navegação global fornece acesso a uma ampla gama de todo o
local. O uso do termo global aqui não implica necessariamente que essa
navegação apareça em todas as páginas do site, embora isso seja
Não é uma má ideia. (Usamos o termo persistente para nos referirmos aos
elementos de navegação que aparecem em todo o site; novamente, lembre-se de que
elementos persistentes não são necessariamente globais.) Em vez disso, a
navegação global reúne o conjunto chave de pontos de acesso que os usuários
pode precisar ir de uma extremidade do site para a outra. Navegação

barras com links para todas as seções principais de um site são um exemplo clássico
de navegação mundial. Em qualquer lugar que você queira ir, você pode obter
lá (eventualmente) com navegação global.
Navegação local.
A navegação local fornece aos usuários acesso ao que está “próximo”
na arquitetura. Em uma arquitetura estritamente hierárquica, a navegação local
pode fornecer acesso ao pai, irmãos e
crianças. Se sua arquitetura for construída para refletir a maneira como os
usuários pensam sobre o conteúdo do site, a navegação local normalmente
obter mais uso do que outros sistemas de navegação.
Complementar
navegação.
A navegação suplementar fornece atalhos para conteúdo relacionado
que podem não ser facilmente acessíveis através da navegação global ou local
ração. Este tipo de esquema de navegação oferece alguns dos benefícios
de classificação facetada discutida no Capítulo 5 (permitindo que os usuários
mudar o foco de sua exploração do conteúdo sem começar
no início), enquanto ainda permite que o site mantenha um
principalmente arquitetura hierárquica.

Navegação contextual.
A navegação contextual (às vezes chamada de navegação em linha) é incorporada ao
conteúdo da própria página. Esse tipo de
a navegação — por exemplo, um hiperlink no texto de uma página — geralmente é
subutilizada ou mal utilizada. Quando eles estão lendo o texto
geralmente é o momento em que os usuários decidem que precisam de uma
informação adicional. Em vez de forçar seus usuários a escanear a página para o
elemento de navegação certo - ou pior, enviando-os correndo para o mecanismo de
pesquisa - por que não colocar o link relevante ali mesmo?
Voltando ao plano estratégico, quanto melhor você entender seus usuários e suas
necessidades, mais efetivamente você
pode implantar navegação contextual. Se ele não apoiar claramente as tarefas e metas
de seus usuários, se seu texto estiver repleto de tantos
hiperlinks que os usuários não podem escolher o que é relevante para suas necessidades—
navegação contextual será (corretamente) vista como desordem.
A navegação de cortesia fornece acesso a itens que os usuários não precisam
regularmente, mas que geralmente são fornecidos como um contra
veniência. No mundo físico, uma loja de varejo costuma postar seu horário de
funcionamento em sua entrada. Para a maioria dos clientes, a maioria dos
tempo, esta informação não é tão útil: qualquer um pode dizer rapidamente se a loja
está aberta ou não para negócios. Mas sabendo
que a informação esteja prontamente disponível os ajuda quando eles precisam.
Links para informações de contato, formulários de feedback e política
declarações são comumente encontradas na navegação de cortesia.

Navegação de cortesia.
Alguns dispositivos de navegação não estão incorporados na estrutura
das suas páginas, mas são independentes, independentemente do conteúdo
ou funcionalidade do seu site. Estas são ferramentas de navegação remota
que os usuários recorrem quando ficam frustrados com a outra navegação
sistemas internacionais que você forneceu, ou quando eles deram uma olhada
seus sistemas de navegação e chegar rapidamente à conclusão de que
é melhor nem mesmo tentar entendê-los.
Um mapa do site é uma ferramenta de navegação remota comum que oferece aos usuários uma
instantâneo conciso de uma página da arquitetura geral do site. O site
geralmente é apresentado como um esboço hierárquico do site, pro
vide links para todas as seções de nível superior com links para as principais segundas
seções de nível recuadas abaixo deles. Os mapas do site geralmente não são exibidos
mais de dois níveis de hierarquia - além disso, há mais detalhes
do que os usuários normalmente precisam (e se não for, provavelmente há algo
errado com sua arquitetura de alto nível).
Um índice é uma lista alfabética de tópicos com links para
páginas, bem como o índice na parte de trás de um livro. Este tipo de ferramenta
é mais eficaz para sites que têm uma grande quantidade de conteúdo cobrindo um
diversa gama de assuntos. Na maioria dos outros casos, um mapa do site e um poço
arquitetura planejada deve ser suficiente. Os índices são às vezes
desenvolvido para seções individuais de um site, em vez de tentar
para cobrir toda a extensão do conteúdo do site; esta abordagem pode ser
útil quando você tem seções destinadas a atender a diferentes públicos
com necessidades de informação divergentes.

Design de Informação
O design da informação pode ser difícil de entender. Mas muitas vezes serve como
a cola que mantém os outros componentes do
projetar juntos. Em todos os casos, o design da informação se resume a tomar
decisões sobre como apresentar a informação para que as pessoas
pode usá-lo ou entendê-lo mais facilmente.
Às vezes, o design da informação é visual. Um gráfico de pizza é a melhor maneira
para apresentar esses dados ou um gráfico de barras funcionaria melhor para nossos usuários?
O ícone de binóculos transmite adequadamente o conceito de pesquisa
o site, ou uma lupa seria melhor compreendida?
Às vezes, o design da informação envolve agrupar ou organizar
Partes da informação. Muitas vezes tomamos esse aspecto do design como garantido
porque estamos acostumados a ver informações comuns
agrupados de determinadas maneiras. Por exemplo, veja esta lista de itens:
. Estado
. Cargo
. Número de telefone
. endereço da Rua
. Nome
. Código postal
. Organização
. Cidade
. Endereço de email
Parece um pouco confuso, porque geralmente é assim:
. Nome
. Cargo
. Organização
. endereço da Rua
. Cidade
. Estado
. Código postal
Mesmo esse arranjo poderia ser esclarecido ainda mais:
. Informação pessoal
. Nome
. Cargo
. Organização
. Informação de Endereço
. endereço da Rua
. Cidade
. Estado
. Código postal
. Outras informações de contato
Este exemplo parece bastante simples, mas um pouco diferente
lista de itens seria mais desafiadora:
. Limite de energia
. Tamanho do rotor
. Capacidade do tanque
. Tipo de transmissão
. Velocidade angular mediana
. Estilo do chassi
. Saída máxima
A chave, é claro, é agrupar e organizar os elementos de informação
de uma maneira que reflita como seus usuários pensam e apoie suas tarefas
e objetivos. As relações conceituais entre esses elementos
realmente equivalem a uma arquitetura de informação em nível micro; em formação
design entra em jogo quando temos que comunicar essa estrutura
tura na página.
O design da informação desempenha um papel nos problemas de design de interface porque
a interface não deve apenas coletar informações do usuário, mas
comunicar informações ao usuário também. As mensagens de erro são
problema clássico de design de informações na criação de interfaces bem-sucedidas;
fornecer informações instrucionais é outra, mesmo que apenas porque
o maior desafio é fazer com que os usuários realmente leiam as instruções
ções. Sempre que o sistema tiver que fornecer alguma informação aos usuários
para eles usarem a interface com sucesso - seja porque
eles cometeram um erro ou porque estão apenas começando - isso é
um problema de design da informação.

Orientação
Uma função importante que o design e a navegação da informação
o trabalho de design em conjunto para realizar está apoiando o wayfinding—
ajudando as pessoas a entender onde estão e para onde podem ir.
A ideia de wayfinding vem do desenho de espaços públicos em
o mundo físico. Parques, lojas, estradas, aeroportos e estacionamentos
todos se beneficiam da incorporação de dispositivos de orientação. Parque
por exemplo, às vezes usam códigos de cores para dar
dicas de pessoas para ajudá-los a lembrar onde deixaram seus carros. Dentro
aeroportos, placas, mapas e outros indicadores ajudam as pessoas a
caminho de volta.
Em sites da Web, o wayfinding normalmente envolve o design de navegação
e design da informação. Os sistemas de navegação empregados por um site
não só tem de fornecer acesso às diferentes áreas do site,
eles também precisam comunicar essas escolhas com clareza. Bom caminho
descoberta permite que os usuários obtenham rapidamente uma imagem mental de onde eles
estão, para onde podem ir e quais escolhas irão aproximá-los
seus objetivos.
O componente de design da informação do wayfinding envolve a página ele
mentos que não executam uma função de navegação. Por exemplo, apenas
como em garagens de estacionamento, alguns sites foram muito bem sucedidos
em usar o código de cores para indicar qual seção um usuário está olhando.
(No entanto, o código de cores quase nunca é usado sozinho - em vez disso, ele
reforça outro sistema de orientação também em vigor.) Ícones, rótulo
sistemas de criação e tipografia são outras opções de design de informação
às vezes usado para ajudar a reforçar a sensação de “você está aqui” para os usuários.
Estruturas de arame
O layout da página é onde o design da informação, o design da interface e o
design de navegação se unem para formar um esqueleto unificado e coeso
eton. O layout da página deve incorporar todos os vários sistemas de navegação,
cada um projetado para transmitir uma visão diferente da arquitetura
tura; todos os elementos de interface exigidos por qualquer funcionalidade na
página; e o design da informação que suporta ambos, como
bem como o design de informação do próprio conteúdo da página.
É muito para equilibrar tudo de uma vez. É por isso que o layout da página é abordado
detalhes em um documento chamado esquema de página ou wireframe. O
wireframe é uma representação básica (como o nome sugere) de todos os
os componentes de uma página e como eles se encaixam.
Captura de wireframes
todo o esqueleto CORTESIA NAV
LOGOTIPO
decisões em um único
NAV GLOBAL
documento que serve
como referência para SUGESTÕES DE PASSAGEM
trabalho de design visual e

CONSULTA DE PESQUISA
GRÁFICO DE CABEÇALHO
implementação do local.
Os wireframes podem suspenso
Embale minha caixa com cinco dúzias de jarras de licor.
LOCAL
contêm níveis variados Como sapos saltadores podem chegar ao nível seis campo de texto
NÃO SÃO ginastas excitadas! Não gostamos de trocar
de detalhes - este é
lotes de trabalho de tamanhos variando de um quarto para cima.
botão
O trabalho exige coragem e zelo extras de
bem leve.
cada jovem assalariado.
CONTEÚDO DO PARCEIRO
Um frasco de litro de óleo misturado com óxido de zinco
faz uma pintura muito brilhante. Seis grandes suculentos O trabalho exige extra
bifes chiaram em uma panela enquanto cinco operários saíam
arrancar e zelo de cada
a pedreira. A música da juke box intrigou um
jovem assalariado. UMA
gentil visitante de uma pitoresca cidade do vale. frasco de litro de óleo misturado com
SUPP. NAV
o óxido de zinco faz um
Embale minha caixa com cinco dúzias de jarras de licor. pintura brilhante. Embalar minha caixa
Como sapos saltadores podem chegar ao nível seis com cinco dúzias de jarras de licor.
ginastas excitadas!
CORTESIA NAV
Este desenho de linha simples é geralmente muito anotado, referindo-se
o leitor a diagramas de arquitetura ou outro design de interação
documentação, requisitos de conteúdo ou especificações funcionais,
ou outros tipos de documentação detalhada conforme necessário. Por exemplo,
se um wireframe se refere a elementos de conteúdo existentes específicos, ele pode
fornecer ponteiros para onde eles podem ser encontrados. Além disso, o fio
quadro geralmente conterá notas suplementares sobre o comportamento pretendido
que pode não ser óbvio apenas olhando para o wireframe e
o diagrama de arquitetura.
De muitas maneiras, o diagrama de arquitetura que vimos na estrutura
plano de tura é a grande visão do projeto; aqui no esqueleto
plano, o wireframe é o documento detalhado que mostra como
essa visão será cumprida. Os wireframes às vezes serão flexíveis
mentado por especificações de navegação abrangentes, descrevendo em
mais detalhes a composição precisa de cada um dos vários naviga
componentes cionais.
Para produtos menores ou menos complexos, um único wireframe é suficiente
cient para servir de template para todas as telas que serão construídas. Por
muitos projetos, no entanto, vários wireframes são necessários para transmitir
a complexidade do resultado pretendido. Você provavelmente não vai precisar de um
wireframe para cada tela, no entanto. Assim como o profissional de arquitetura
cess nos permitiu classificar os elementos de conteúdo em categorias amplas
ou tipos, um número relativamente pequeno de telas padrão surgirá
desde o desenvolvimento de wireframe, baseado no funcional ou naviga
diversidade nacional do seu produto.
Os wireframes são um primeiro passo necessário no processo de formalização
estabelecendo o design visual do site, mas quase todos
envolvidos no processo de desenvolvimento irão usá-los em algum momento.

As pessoas responsáveis pela estratégia, escopo e estrutura podem consultar
o wireframe para confirmar que o produto final atenderá às suas
expectativas. Pessoas responsáveis por realmente construir o produto
pode consultar o wireframe para responder a perguntas sobre como o site

deve funcionar.
O wireframe, sendo o lugar onde a arquitetura da informação e
design visual se juntam, muitas vezes é assunto de debate e
putar. Os designers de experiência do usuário reclamam que os designers visuais que
criar wireframes obscurecem suas arquiteturas por trás da navegação
sistemas que não refletem os princípios subjacentes à arquitetura
turas. Os designers visuais reclamam que os wireframes produzidos pelo usuário
designers de experiência reduzem seu papel ao de um pintor por números
artista, desperdiçando a experiência e expertise em comunicação visual
nicação que eles trazem para os problemas de design da informação.
Quando você tem designers de experiência do usuário e recursos visuais separados
designers, a única maneira de produzir wireframes de sucesso é através
colaboração. O processo de ter que trabalhar os detalhes do
wireframe juntos permite que cada lado veja os problemas do outro
ponto de vista, e pode ajudar a descobrir problemas no início do processo
(em vez de mais tarde, quando o produto está sendo construído e todos estão
perguntando por que não está funcionando como planejado).
Tudo isso faz com que os wireframes pareçam muito trabalhosos. Elas
não precisa ser. A documentação nunca é um fim em si mesma; é apenas
Um meio para o fim. Criar documentação por si só não é
apenas uma perda de tempo - pode ser contraproducente e desmoral
izar. Produzindo o nível certo de documentação para suas necessidades—
e não se iluda pensando que você pode sobreviver com menos — voltas
documentação de um problema em uma vantagem.

Alguns dos wireframes de maior sucesso com os quais já trabalhei
nada mais do que esboços a lápis com notas adesivas anexadas.
Para uma pequena equipe na qual o designer e o programador se sentam
um ao lado do outro, esse nível de documentação é perfeitamente
suficiente. Mas quando a programação é responsabilidade de toda uma
equipe e não apenas uma pessoa - e essa equipe está no meio do caminho
mundo - algo um pouco mais formal é provavelmente necessário.
O valor dos wireframes é a forma como eles integram os três elementos
do plano da estrutura: design da interface, através do arranjo
e seleção de elementos de interface; projeto de navegação, através
a identificação e definição dos principais sistemas de navegação; e
design da informação, através da colocação e priorização de
componentes informativos. Ao reunir os três em um
documento único, o wireframe pode definir um esqueleto que constrói
na estrutura conceitual subjacente ao mesmo tempo em que aponta o caminho
para a frente em direção ao desenho da superfície.

capítulo 7
A superfície
Avião
Design Sensorial
Superfície
Esqueleto
Estrutura
No topo do modelo de cinco planos, voltamos nossa atenção
ção a esses aspectos do produto, nossos usuários

Alcance
observe primeiro: o design sensorial. Aqui, conteúdo, função
Estratégia
cionalidade e estética se unem para produzir um
design acabado que agrada os sentidos enquanto cumpre
todos os objetivos dos outros quatro planos.
Interação tivemos
formação
Em
Contente
Requisitos
Funcional
Especificações
nt
e
134 CAPÍTULO 7 O PLANO DE SUPERFÍCIE
Definindo a Superfície
No plano do esqueleto, estávamos lidando principalmente com

arranjos. O design de interface diz respeito ao arranjo de elementos para
permitir a interação; design de navegação, o arranjo de elementos
para permitir o movimento através do produto; e informação
design, o arranjo de elementos para comunicar informações
ao usuário.
Movendo-se para o plano da superfície, estamos agora lidando

com o design sensorial e a apresentação dos arranjos lógicos que
compõem o esqueleto do produto. Por exemplo, por meio da
atenção ao design da informação, determinamos como devemos agrupar e
organizar os elementos de informação da página; através da
atenção ao design visual, determinamos como esse arranjo deve ser
apresentado visualmente.

superfície
esqueleto
Dando sentido aos sentidos

Cada experiência que temos – não apenas com produtos e serviços, mas com
o mundo e uns com os outros – vem fundamentalmente
nós através dos nossos sentidos. No processo de design, esta é a última parada
no caminho para entregar uma experiência aos nossos usuários: determinar
como tudo em nosso design se manifestará aos sentidos das pessoas.
Qual dos cinco sentidos (visão, audição, tato, olfato e paladar)
podemos empregar depende do tipo de produto que estamos projetando.
Cheiro e Sabor
Exceto para alimentos, fragrâncias ou produtos perfumados, cheiro e sabor são
raramente considerações para designers de experiência do usuário. É verdade
que as pessoas às vezes desenvolvem fortes associações com o cheiro de um
produto – como “cheiro de carro novo”, que provou ser tão popular que pode
ser adicionado como fragrância muito depois que o carro superou
definição de “novo” de qualquer um – mas esses cheiros são tipicamente o
resultado da escolha de materiais na construção do produto, não
as decisões dos designers de experiência.
Toque
A experiência de toque de um produto físico está dentro do domínio do
desenho industrial. Os designers industriais estão preocupados principalmente
com o envolvimento físico do usuário com um produto. Isso implica ele
mentos de design de interface e interação (como a disposição dos botões em
um telefone celular), mas também inclui
considerações, como a forma de um dispositivo (arredondado? quadrado?), as
texturas utilizadas (liso? áspero?) e os materiais empregados

(plástico? metal?). Graças a dispositivos vibratórios, experiência baseada em tela
também podem ter dimensões de toque. Telefones celulares e vídeo
os controladores de jogo usam vibração para se comunicar com o usuário.
Audição
O som desempenha um papel na experiência de muitos tipos de produtos.
Pense em todos os diferentes bipes e zumbidos em um automóvel típico
e as mensagens que eles enviam: Seus faróis estão acesos. Seu cinto de segurança
é desatado. Sua porta está aberta, mas você deixou sua chave na ignição
ção. O som pode ser usado não apenas para informar o usuário, mas para imbuir um
produto com um senso de personalidade. Por exemplo, qualquer usuário TiVo pode
lembrar facilmente a variedade de bings, boops e solavancos que acompanham
navegação através da experiência TiVo.
Visão
Esta é a área onde os designers de experiência do usuário têm mais
sofisticação, porque o design visual desempenha um papel em praticamente todos os
tipo de produto que existe. Por esta razão, o restante deste capítulo
concentre-se em como o design visual suporta a experiência do usuário.
Inicialmente, você pode pensar que o design visual é uma simples questão de aes
thetics. Todo mundo tem um gosto diferente, e todo mundo tem um gosto diferente
ideia do que constitui um design visualmente atraente, então cada argumento
mento sobre as decisões de design apenas se resume à preferência pessoal,
certo? Bem, todo mundo tem um senso de estética diferente, mas
isso não significa que as decisões de design tenham que ser baseadas no que parece
legal para todos os envolvidos.
Em vez de avaliar ideias de design visual apenas em termos do que
parece esteticamente agradável, você deve concentrar sua atenção em

quão bem eles funcionam. Com que eficácia o design apoia a
objetivos definidos por cada um dos planos inferiores? Por exemplo, faz
a aparência do produto fazem distinções entre as seções do
arquitetura pouco clara ou ambígua, minando a estrutura? Ou
o design visual esclarece as opções disponíveis para os usuários,
forçando a estrutura?
A comunicação de uma identidade de marca, por exemplo, é uma estratégia comum
objetivo gic para um site. A identidade da marca aparece em muitos
maneiras - na linguagem que você usa ou no design de interação do seu
funcionalidade do site, mas uma das principais ferramentas usadas para comunicar
identidade de marca é design visual. Se a identidade que você deseja transmitir
é técnico e autoritário, usando fontes de quadrinhos e cores
cores pastel provavelmente não é a escolha certa. Não é apenas uma questão de
estética, é uma questão de estratégia.
Siga o olho
Uma maneira simples de avaliar o design visual de um produto é perguntar:
Onde o olho vai primeiro? Que elemento do design inicialmente
chama a atenção dos usuários? Eles são atraídos por algo importante
aos objetivos estratégicos do produto? Ou é o primeiro objeto de sua
atenção uma distração de seus objetivos (ou seus)?
Os pesquisadores às vezes usam equipamentos sofisticados de rastreamento ocular
para determinar exatamente o que os sujeitos de teste estão olhando e como
olhos se movem pela tela. Se você está apenas ajustando o visual
design de um produto, no entanto, você geralmente pode se safar com sim
ply perguntando às pessoas - mesmo apenas perguntando a si mesmo. Essa abordagem não vai
fornecer os resultados mais precisos, e nunca irá capturar todos os
nuances que o equipamento de rastreamento ocular pode fornecer. Mas a maioria dos
tempo, simplesmente fazer perguntas é perfeitamente adequado. Outra maneira de
encontrar o elemento de design dominante é apertar os olhos para a página ou desfocar
seus olhos até que você não consiga distinguir os detalhes - ou caminhe até o outro
final da sala e olhe para ele de lá.
Em seguida, tente determinar para onde vai o olho. Se você está servindo como seu
própria cobaia, tente notar os movimentos inconscientes de seu
olhos ao redor da página. Não pense muito sobre o que você é
olhando para; apenas deixe seus olhos observarem a página naturalmente. Se alguém
mais é o seu assunto de teste, peça-lhes para chamar os elementos do
página na ordem em que sua atenção é atraída para eles.
Geralmente, você encontrará padrões bastante consistentes em como as pessoas se movem
seus olhos - afinal, estes são em grande parte inconscientes, instintivos
movimentos. Se os sujeitos relatarem que seus olhos seguem um caminho muito diferente
padrão de outras pessoas, eles provavelmente não estão realmente cientes de suas
movimentos oculares naturais, ou eles estão apenas dizendo o que eles pensam
você quer ouvir (ou ambos).
Se o seu design for bem sucedido, o padrão que o olho do usuário segue será
tem duas qualidades importantes:
. Primeiro, segue um fluxo suave. Quando as pessoas comentam isso
um design está "ocupado" ou "desordenado", eles estão realmente reagindo a
o fato de que o design não os conduz suavemente
a página. Em vez disso, seus olhos saltam para frente e para trás entre um
variedade de elementos todos clamando por sua atenção.

. Em segundo lugar, oferece aos usuários uma espécie de visita guiada às possibilidades
disponíveis para eles sem sobrecarregá-los com detalhes. Como
sempre, essas possibilidades devem apoiar os objetivos e tarefas que o
usuário está tentando realizar neste momento em sua interação.
ção com o produto. Talvez mais importante, aqueles pos
bilidades não devem distrair de informações ou funções que
os usuários precisarão cumprir esses objetivos.
O movimento dos olhos do usuário pela página não acontece por
acidente. É o resultado de um conjunto complexo de respostas instintivas
profundamente arraigadas a estímulos visuais que todos os humanos compartilham. Felizmente
para nós como designers, essas respostas também não estão completamente fora
de nosso controle - ao longo dos séculos, desenvolvemos uma variedade de
técnicas visuais eficazes para atrair e direcionar a atenção.
Contraste e uniformidade
No design visual, a principal ferramenta que usamos para chamar a atenção do usuário
ção é contraste. Um desenho sem contraste é visto como uma massa cinzenta e
inexpressiva, fazendo com que os olhos do usuário vagueiem sem
fixando-se em algo em particular. O contraste é vital para chamar a atenção do
usuário para aspectos essenciais da interface, o contraste ajuda
o usuário entende as relações entre os elementos de navegação na página e o
contraste é o principal meio de comunicação
comunicação de grupos conceituais em design de informação.
Quando os elementos de um design são diferentes, os usuários prestam atenção. Elas
não pode ajudar. Você pode usar esse comportamento instintivo para sua vantagem,
fazendo com que as peças que os usuários realmente precisam ver se destaquem
o resto dos elementos. As mensagens de erro nas interfaces da Web geralmente são suficientes
para não se misturar com o resto da página; contrastando-os por
colocando o texto em uma cor diferente (como, digamos, vermelho) ou destacando
com um gráfico em negrito pode fazer toda a diferença.
Em um layout
visualmente neutro (próximo
à direita, em cima), nada se destaca.

O contraste pode ser usado
para guiar o olhar do
usuário pela página
(extrema direita, superior)
ou chamar sua atenção para
alguns elementos-chave
(próximo à direita, inferior). Uso excessivo de
contraste leva a
aparência desordenada (extrema
direita, inferior).
Para que essa estratégia funcione, no entanto, a diferença deve ser
significativo o suficiente para o usuário dizer claramente que a escolha do projeto é
pretende comunicar algo. Quando o tratamento do projeto
de dois elementos é semelhante, mas não exatamente o mesmo, os usuários ficam con
fundido. “Por que eles são diferentes? Devem ser iguais?
Talvez tenha sido apenas um erro. Ou eu deveria notar algo
aqui?" Em vez disso, queremos atrair a atenção dos usuários e garantir

eles que é intencional.
Manter a uniformidade em seu projeto é uma parte importante da
garantindo que seu design se comunique de forma eficaz sem
fundindo ou sobrecarregando seus usuários. A uniformidade entra em jogo
muitos aspectos diferentes do design visual.
Manter os tamanhos dos elementos uniformes pode facilitar a recom
combiná-los em novos designs conforme você precisar deles. Por exemplo, se todos
os botões gráficos que você usa para navegação têm a mesma altura,
eles podem ser misturados e combinados conforme necessário sem criar um clut
layout ou exigindo que novos gráficos sejam produzidos.
O layout baseado em grade é uma técnica do design de impressão que carrega
mais efetivamente para a Web. Essa abordagem garante uniformidade de
design por meio de um layout mestre que é usado como modelo para
variações de layout. Nem todo layout usará todas as partes do
grid - na verdade, a maioria dos layouts provavelmente usará apenas alguns - mas cada
a colocação do elemento na grade deve ser uniforme e consistente.

Layout baseado em grade
garante que diversos
os designs têm uma partilha
ordem visual.
No entanto, como os dispositivos, tamanhos de tela e resolução de tela podem
variam muito, aplicar grades ao design baseado em tela nem sempre é
tão simples quanto no design de impressão. É fácil cair na armadilha de
aderindo a um sistema de grade - ou qualquer padrão destinado a garantir
uniformidade — mesmo quando claramente não está mais funcionando. O anar
chy de trabalhar sem padrões de design é ruim, mas a camisa de força

de tentar trabalhar dentro de padrões de projeto que são inadequados para
suas necessidades podem ser piores. Talvez o produto tenha assumido novas
funcionalidade que ninguém imaginava na época em que a grade
foi desenvolvido; talvez a grade nunca tenha funcionado tão bem em
o primeiro lugar. Seja qual for o motivo, é importante ser capaz de
reconhecer quando é hora de revisitar os fundamentos do seu visual
sistema de projeto.
Consistência interna e externa

Por causa da maneira como os sites da Web geralmente são produzidos - aos poucos,
ad hoc e isolado de outros trabalhos de design em andamento na organização
nização - eles têm sido atormentados com problemas de consistência em
design visual. Esses problemas assumem duas formas:
. Existem problemas de consistência interna, em que diferentes
partes do produto refletem diferentes abordagens de design.
. Depois, há problemas de consistência externa, em que
o produto não reflete a mesma abordagem de design usada em
outros produtos da mesma organização.
Boas soluções para problemas de consistência interna estão enraizadas em
uma compreensão do esqueleto do local. A chave é identificar
tificar elementos de design recorrentes que aparecem em diferentes contextos
ao longo das várias interfaces, navegação e informações
problemas de projeto no produto. Ao isolar cada elemento de design
desses diferentes contextos antes de projetá-lo, podemos mais
ver claramente o problema de pequena escala que estamos tentando resolver, em vez de
se distrair com os problemas de maior escala impostos pelo contexto.
Em vez de projetar o mesmo elemento repetidamente,
pode projetá-lo uma vez e usar esse design em todo o produto.

Para que tal abordagem funcione, teremos que verificar nosso trabalho
contra os diferentes contextos em que esse elemento aparece. Pode ser
um botão STOP grande, redondo e vermelho funcionará bem para a página de checkout,
mas pode não ser tão visualmente eficaz no produto lotado
página de personalização. A melhor abordagem é projetar cada elemento,
experimente em vários contextos e, em seguida, refaça o design conforme necessário.
Mesmo que muitos dos elementos de design sejam criados isoladamente
ção uns dos outros, eles ainda devem trabalhar juntos. Um sucesso
design não é meramente uma coleção de objetos pequenos e bem desenhados;
em vez disso, os objetos devem formar um sistema que opera como um sistema coeso,
todo consistente.
Reforçar a consistência do design em todas as mídias apresenta seu audi
ence – clientes, prospects, acionistas, funcionários ou
observadores - com uma impressão uniforme da identidade da sua marca. este
consistência da identidade da marca deve estar presente em todos os níveis de
o design visual do seu produto, desde os elementos de navegação
aparecendo em todas as telas até o botão humilde que aparece
apenas uma vez.
Apresentar um estilo em seu site que é inconsistente com sua
estilo em outras mídias não afeta apenas a impressão do público
desse produto; afeta a impressão que eles têm de sua empresa como um
todo. As pessoas respondem positivamente a empresas com
identidades. Estilos visuais inconsistentes prejudicam a clareza do seu
imagem corporativa e deixar o público com a impressão de que
esta é uma empresa que ainda não descobriu quem é.

Paletas de cores e tipografia

A cor pode ser uma das formas mais eficazes de comunicar uma identidade
de marca. Algumas marcas estão tão intimamente associadas às cores que é
difícil pensar na empresa sem que a cor automaticamente venha à mente —
considere Coca-Cola, UPS ou Kodak. Estes com
empresas têm empregado cores específicas (vermelho, marrom, amarelo)
consistentemente ao longo dos anos para criar um sentido mais forte de suas identidades em
mente do público.
Isso não significa que eles usam essas cores com a exclusão de todos
outros. As cores principais da marca geralmente fazem parte de uma paleta de
cores mais ampla usada em todos os materiais de uma empresa. As cores em um com
A paleta padrão da empresa é selecionada especificamente para o quão bem
eles funcionam juntos, complementando-se sem competir.
Uma paleta de cores deve incorporar cores que se prestam a uma ampla gama
de usos. Na maioria dos casos, cores mais brilhantes ou mais ousadas podem
ser usado para o primeiro plano do seu design - elementos para os quais você
deseja chamar a atenção. Cores mais suaves são melhor usadas para
elementos de fundo que não precisam saltar para fora da página. Ter uma
gama de cores para escolher nos fornece um kit de ferramentas para fazer
escolhas de projeto eficazes.
Assim como o contraste e a uniformidade são importantes para outras áreas de
design visual, eles também desempenham um papel vital na criação de paletas
de cores. Quando usadas no mesmo contexto, cores muito próximas
entre si, mas não exatamente iguais, prejudicam a eficácia de sua paleta de
cores. Isso não significa que você só tem um tom de vermelho,

Orbitz usou um
paleta de cores
limitada (topo) para diferenciar
características e
r:102 r:0 r:0 r:0 r:255
funcionalidade no
g:153 g:102 g:51 g:153 g:153
site (abaixo). b:204 b:204 b:153 b:0 b:0
r:255 r:204 r:153 r:51 r:204

g:255 g:204 g:153 g:51 g:204
b:204 b:153 b:102 b:51 b:204
um tom de azul, e assim por diante. Isso significa que se você quiser usar dif
diferentes tons de vermelho, certifique-se de que sejam diferentes o suficiente para que os usuários
pode diferenciá-los e certifique-se de usar cada um de maneira consistente.
Para algumas empresas, tipografia - o uso de fontes ou tipos de letra
para criar um estilo visual específico - é tão importante para sua marca
identidades que eles encomendaram fontes especiais para serem
produzidos especificamente para seu uso. Organizações que vão desde
Apple para Volkswagen para o metrô de Londres e até mesmo Martha
Stewart usaram tipografia personalizada para criar uma sensação mais forte de
identidade em suas comunicações. Mesmo se você optar por não tomar
neste passo extraordinário, o tipo ainda pode servir como uma parte efetiva da
comunicar a sua identidade através do design visual.
Para corpo de texto—qualquer material que será apresentado em blocos maiores
ou que será lido pelos usuários em trechos mais longos - quanto mais simples, melhor.
Nossos olhos rapidamente se cansam de tentar assimilar muito texto de uma forma mais
tipografia ornamentada. É por isso que fontes simples como Helvetica ou Times são
tão amplamente utilizado. Eles não são suas únicas escolhas, no entanto; você não
tem que sacrificar o estilo para acomodar a legibilidade.
Para elementos de texto maiores ou rótulos curtos como os vistos no naviga
elementos cionais, fontes com um pouco mais de personalidade são
perfeitamente apropriado. Mas um dos nossos objetivos não é sobrecarregar nossos
usuários com desordem visual e usando uma variedade desnecessariamente ampla
de fontes - ou mesmo usando um pequeno número de fontes em
maneiras - pode contribuir para essa sensação de desordem. Na maioria dos casos, você
não precisará de mais do que um punhado de fontes para atender a todos os seus commu
necessidades de nicao.
Os princípios de usar o tipo de forma eficaz são realmente os mesmos que aqueles
para outros aspectos do design visual: Não use estilos que são muito
semelhantes, mas não exatamente iguais. Use estilos diferentes apenas para indi
cate as diferenças nas informações que você está tentando comunicar.
Forneça contraste suficiente entre os estilos para que você possa desenhar o
atenção do usuário conforme necessário, mas não sobrecarregue o design com um
ampla gama de diversos estilos.
Comps de design e guias de estilo
O analógico mais direto para o wireframe para o reino do visual
design é a maquete visual ou composição de design. Comp é abreviação de
composto, porque é exatamente isso: uma visualização do
produto acabado construído a partir dos componentes que foram
escolhido. A composição mostra como todas as peças trabalham juntas para formar
um todo coeso; ou, se não, mostra onde o detalhamento
está acontecendo e demonstra restrições que qualquer solução

tem que prestar contas.
Você deve ser capaz de ver uma simples correlação um-para-um entre
componentes do wireframe e componentes do design
comp. A composição pode não reproduzir fielmente o layout do
wireframe — na verdade, provavelmente não. O wireframe não
levar em conta as preocupações de design visual, concentrando-se em documentos
no esqueleto. Construindo o wireframe antes de abordar o
design comp nos permite analisar primeiro os problemas do esqueleto isoladamente,
então veja como as questões superficiais entram em jogo. Apesar disso, o núcleo
ideias no wireframe, particularmente em relação ao design da informação
questões, devem ser claramente evidentes nas composições de design, mesmo que
eles podem não seguir o arranjo preciso apresentado no

estrutura de arame.
O projeto visual
ÁREA DE MARCA CORTESIA NAV
LOGOTIPO
não tem que
NAV GLOBAL
corresponder ao wireframe
precisamente - só tem
para dar conta do
importância relativa e
agrupamento de elementos
ARTIGOS INCLUIDOS
apresentados no
estrutura de arame.
NAV SUPLEMENTAR
PRINCIPAIS HISTÓRIAS NACIONAIS PRINCIPAIS HISTÓRIAS LOCAIS

Toda essa documentação é, obviamente, muito trabalhosa, mas acontece
por um bom motivo: com o tempo, os motivos de nossas decisões desaparecem
da memória. As decisões ad hoc tomadas para resolver um problema específico
lem em uma circunstância específica ficar todo confuso com as decisões
destinado a formar a base para o trabalho de design futuro.
Outra razão para documentar seu sistema de design é que as pessoas
eventualmente abandonar seus empregos. Quando o fazem, eles vão embora com um
riqueza de conhecimento sobre como um produto é projetado e construído
diariamente. Sem um guia de estilo que permaneça atualizado
atualizado com os padrões e práticas mais recentes, esse conhecimento é perdido.
Com o tempo, à medida que as pessoas mudam de posição, toda a organização
gradualmente sofre uma espécie de amnésia, como as coisas foram feitas
e as razões para essas decisões se afastam para outras partes do
empresa ou de volta à força de trabalho.
A documentação definitiva das decisões de design que temos
feito é o guia de estilo. Este compêndio define todos os aspectos
do design visual, desde a maior escala até a menor. Global
padrões que afetam todas as partes do produto, como grades de design,
paletas de cores, padrões de tipografia ou diretrizes de tratamento de logotipos—
são geralmente as primeiras coisas a entrar em um guia de estilo.
O guia de estilo também incluirá padrões específicos para um determinado
seção ou função de um produto. Em alguns casos, os padrões
documentado no guia de estilo irá até o nível
de interface individual e elementos de navegação. O objetivo geral
do guia de estilo é fornecer detalhes suficientes para ajudar as pessoas a
decisões inteligentes no futuro - porque a maior parte do pensamento
já foi feito para eles.

Criar um guia de estilo também é útil para impor consistência de design
em uma organização descentralizada. Se suas operações da Web con
uma gama diversificada de projetos independentes sendo iniciados e
trabalhado por pessoas em escritórios espalhados por todo o mundo, seu site
é provável que pareça uma mistura aleatória de estilos e padrões.
Fazer com que todas essas pessoas sigam um conjunto unificado de padrões
pode dar muito trabalho, e é por isso que a responsabilidade de fazer cumprir
guias de estilo de design geralmente residem em cargos mais altos na organização
do que você poderia esperar. Ter um guia de estilo que você pode consultar é o
única maneira mais eficaz de fazer com que seu produto pareça um
inteiro em vez de apenas um amontoado de peças pregadas.

capítulo 8
Os elementos
Aplicado
Os elementos da experiência do usuário permanecem consistentes, não importa quão
complexo é o seu produto. Mas colocar as ideias por trás dos elementos
em prática às vezes pode parecer um desafio por si só. Isso é
não apenas uma questão de tempo e recursos - muitas vezes é uma questão de
mentalidade.
Olhando para trás sobre os cinco planos - estratégia, escopo, estrutura, esqueleto
tonelada e superfície - tudo parece muito trabalho. Certamente tal
atenção cuidadosa a todos esses detalhes deve levar meses de desenvolvimento
ment tempo e um pequeno exército de especialistas altamente treinados, certo?
Não necessariamente. Certamente, para alguns projetos e algumas organizações
ções, empregar uma equipe de especialistas dedicados é a forma mais eficaz
maneira de dividir a responsabilidade por um produto que é simplesmente muito
plex para lidar com qualquer outra maneira. Além disso, como os especialistas podem se concentrar
exclusivamente em um subconjunto da experiência completa do usuário, eles geralmente
trazer uma compreensão mais profunda dessas questões para suportar em seu trabalho.
154 CAPÍTULO 8 OS ELEMENTOS APLICADOS
Na maioria das vezes, no entanto, equipes pequenas com recursos limitados podem
alcançar resultados semelhantes. Às vezes, um grupo de apenas algumas pessoas pode
realmente produzem melhores resultados do que uma grande equipe, porque é mais fácil
para que eles permaneçam em sincronia em uma visão compartilhada da experiência do usuário.
Projetar a experiência do usuário é realmente pouco mais do que um
grande coleção de problemas muito pequenos a serem resolvidos. A diferença
entre uma abordagem bem sucedida e uma fadada ao fracasso realmente
se resume a duas ideias básicas:
. Entenda qual problema você está tentando resolver. Então
você descobriu que o grande botão roxo na casa
tela é um problema. É a grandeza e a púrpura de
o botão que precisa mudar (superfície)? Ou será que o
botão está no lugar errado na página (esqueleto) ou que
a função que o botão representa não faz o que os usuários
esperar (estrutura)?
. Entenda as consequências de sua solução para o
problema. Lembre-se de que há um potencial efeito cascata para cima
e para baixo nos elementos de cada decisão que você
faço. O design de navegação que funciona tão bem em uma parte do
seu produto pode não atender às necessidades de outro segundo
ção da arquitetura. O design de interação para o produto
assistente de seleção de uct pode muito bem ser uma abordagem inovadora,
mas atenderá às necessidades de seus usuários tecnofóbicos?

Somente tendo
alguém em sua
organização pensando
sobre cada um dos cinco
aviões você pode abordar

todas as considerações
crucial para criar

um usuário de sucesso
experiência. Como essas
responsabilidades são
distribuídas em sua
organização não é tão
importante quanto fazer

com certeza todos os elementos
de experiência do usuário são

contabilizado.
Você ficaria surpreso com quantas das pequenas decisões que fazem
o processo de design da experiência do usuário não são feitos conscientemente
tudo. Na maioria das vezes, as escolhas feitas sobre a experiência do usuário

cair em um destes cenários:
. Projeto por padrão. Isso acontece quando a estrutura de
a experiência do usuário segue a estrutura do
tecnologia ou de sua organização. Mantendo o cliente
histórico de pedidos e informações de cobrança em bancos de dados separados
pode funcionar melhor para o seu sistema técnico existente, mas isso
não significa mantê-los separados na experiência do usuário é
também uma boa ideia. Da mesma forma, o conteúdo que vem de diferentes
departamentos da empresa podem servir melhor ao usuário se
é reunido, não mantido separado.
. Design por mimetismo. Isso acontece quando a experiência do usuário
recorre a convenções familiares de outros produtos, publica
cations ou aplicativos de software, independentemente de como
essas convenções podem ser para seus usuários (ou mesmo para o
própria web).
. Projeto por fiat. Isso acontece quando as preferências pessoais
em vez das necessidades do usuário ou objetivos do produto, impulsionam a experiência do usuário
decisões. Se laranja domina sua paleta de cores
porque um dos vice-presidentes seniores gosta dele, ou se
todos os seus elementos de navegação são menus suspensos porque
é disso que seu engenheiro-chefe gosta, você perdeu de vista o
objetivos estratégicos e insights do usuário que devem conduzir o
escolhas que você faz.

Fazendo as perguntas certas
Enfrentar o emaranhado de pequenos problemas a serem resolvidos ao projetar a
experiência do usuário às vezes pode ser desanimador. Ocasionalmente um
A solução para um problema o forçará a repensar outros problemas que você achava
que já havia resolvido. Muitas vezes, você terá
para fazer concessões e avaliar as compensações entre as diferentes abordagens.
Quando você está no meio de ter que fazer esses
tipos de decisões, é fácil ficar frustrado e questionar se você está adotando a
abordagem correta. A abordagem correta é
para fundamentar cada decisão em sua compreensão das questões subjacentes em
jogo. A primeira pergunta que você deve fazer a si mesmo (e a
primeira pergunta que você deve ser capaz de responder) sobre qualquer aspecto da
experiência do usuário é: Por que você fez isso dessa maneira?
Ter o estado de espírito certo sobre como abordar os problemas que você está
enfrentando é o que mais importa. Todos os outros aspectos da experiência do usuário
O processo de design de experiência pode ser ajustado para se adequar ao tempo,
dinheiro e pessoas à sua disposição. Não há tempo para coletar dados de pesquisa de mercado sobre
seu público? Talvez você possa encontrar maneiras de ver as informações que já
possui, como logs do servidor ou mensagens de feedback, para obter
um senso das necessidades de seus usuários. Não tem condições de alugar um
laboratório de testes de usabilidade? Recrute amigos, familiares ou colegas de trabalho para participar
testes informais.
Resista à tentação de encobrir a experiência fundamental do usuário
questões do projeto em nome da economia de tempo ou dinheiro. Em alguns projetos,
alguém vai pensar em alguma forma de usuário
avaliação da experiência até o final do processo - muito depois da

o tempo para realmente resolver esses problemas se esgotou. Correndo para
lançar sem olhar para trás pode ter parecido uma boa ideia
quando a data de lançamento foi definida, mas o resultado provavelmente será um
produto que atende a todos os requisitos técnicos para o projeto, mas
não funciona para seus usuários. Pior ainda, ao abordar a experiência do usuário
avaliação no final, você pode acabar lançando um produto
que você sabe que está quebrado, mas não tem oportunidade (ou dinheiro sobrando)
Consertar.
Algumas organizações favorecem essa abordagem, chamando-a de “aceitação do usuário
testando.” A palavra aceitação é muito reveladora aqui - a questão
não é se eles gostam do produto ou vão usar o produto, mas
sim eles podem aceitar o produto? Este tipo de teste com muita frequência
acontece no final do processo, momento em que incontáveis
suposições moldaram a experiência do usuário sem nunca serem
examinado. Essas suposições podem ser extraordinariamente difíceis de
descobrir no teste do usuário do produto acabado, porque eles são
escondido atrás de camadas de interface e interação.
Muitas pessoas defendem o teste do usuário como o principal meio de
garantindo uma boa experiência do usuário. Essa linha de pensamento parece ser
que você deve fazer algo, coloque na frente de algumas pessoas para
veja como eles gostam e depois corrija o que eles reclamaram.
Mas o teste nunca substitui um usuário atencioso e informado
processo de projeto de experiência.
Fazer perguntas aos seus usuários que se concentrem em elementos específicos do
a experiência do usuário pode ajudá-lo a coletar informações mais relevantes. Testes de usuário
construído sem olhar para os elementos da experiência do usuário
pode acabar fazendo as perguntas erradas, que por sua vez podem
levar a respostas erradas. Por exemplo, ao testar protótipos,

saber qual problema você pretende investigar é crucial para
apresentando suas cobaias com uma experiência que não turva
o assunto com questões não relacionadas. É o problema com que naviga
barra de ção realmente apenas a cor? Ou é o texto que seus usuários
estão respondendo?
Você simplesmente não pode depender de seus usuários para articular suas necessidades.
O desafio na criação de qualquer experiência do usuário é entender o
necessidades dos usuários melhor do que eles entendem essas necessidades
eus. Os testes podem ajudar você a entender as necessidades de seus usuários,
mas é apenas uma das muitas ferramentas que podem ajudar a alcançar o mesmo objetivo.
A Maratona e o Sprint
Assim como você não deve deixar nenhum aspecto da experiência do usuário para
chance, você não deve deixar seu próprio processo de desenvolvimento para
chance também. Muitas equipes de desenvolvimento operam em um estado de
emergência permanente. Cada projeto é concebido como a resposta
alguma crise percebida e, como resultado, todo projeto está atrasado
antes mesmo de começar.
Aqui está uma metáfora para o processo de desenvolvimento da experiência do usuário que
Costumo usar ao descrever problemas aos clientes: Uma maratona não é
uma corrida. Saiba em que tipo de corrida você está e corra de acordo.
Um sprint é uma corrida curta. Os velocistas têm de recorrer a vastas reservas de
energia no instante em que a arma de partida é disparada - e eles gastam
dessa energia no espaço de alguns minutos. Logo no início
linha, o velocista tem que correr o mais rápido que puder e continuar correndo
o mais rápido que puder até alcançar a linha de chegada.

Uma maratona é uma corrida longa. Os maratonistas precisam tanto
energia como os velocistas, mas eles a gastam de maneira muito diferente. Sucesso
O sucesso na maratona depende da eficácia com que os corredores andam
eles mesmos. Todos os outros fatores sendo iguais, o corredor que sabe
quando acelerar e quando desacelerar é muito mais provável

vencer — ou até mesmo terminar a corrida.
A estratégia de sprint - corra o mais rápido que puder do início ao fim
fim - pode parecer a única abordagem sensata para uma corrida. Isto
parece que você deveria ser capaz de correr uma maratona como se fosse
uma série de sprints, mas não funciona assim. Parte da razão
não funciona dessa maneira é o simples limite físico da resistência humana
ance. Há outro fator aqui também: para acomodar esse limite,
maratonistas monitoram constantemente seu desempenho, observam
o que está funcionando e o que não está funcionando, e ajustar sua abordagem
adequadamente.
O desenvolvimento de produtos raramente é um sprint. Mais frequentemente, haverá
momentos em que você avança, construindo protótipos e gerando
ideias, seguido por momentos em que você recua, testando o que você
construído, vendo como as peças se encaixam e refinando o quadro geral
para o projeto. Algumas tarefas são melhor realizadas com ênfase
na velocidade; outros requerem uma abordagem mais deliberada. Boa mara
os corredores sabem qual é qual – você também deveria saber.
Decisões de design ponderadas e deliberadas custarão a você tempo no
curto prazo, mas eles vão lhe poupar muito mais tempo no longo
prazo. Designers e desenvolvedores muitas vezes lamentam a falta de atenção
à estratégia, escopo e estrutura nos projetos em que trabalham. Eu tenho
esteve envolvido em mais de um projeto em que essas atividades
estavam constantemente sob a ameaça de serem eliminados. Algumas pessoas ficam

impaciente com tarefas que não envolvem a produção de um
componente do site como um gráfico ou um pedaço de código. Essas tarefas são
muitas vezes os primeiros itens de linha são cortados de um projeto que está atrasado
ou acima do orçamento.

Concreto
superfície
Projeto Interface
Navegação Projeto
D n
esqueleto
Designação
_
estrutura
Contente onal Funcional

Requisitos
nós
alcance
Especificaçõ
nt
e
estratégia
Abstrato
Mas essas tarefas foram incluídas no escopo do projeto em primeiro lugar
porque serviram como preparação essencial para entregas posteriores para
venha. (É por isso que os cinco aviões são construídos de baixo para cima, cada um
servindo como base para aqueles acima dela.) Quando essas tarefas são
eliminadas, as tarefas e entregas deixadas no cronograma do projeto
sentir-se desinformado pelo contexto maior do projeto e desconcertado
ligados um do outro.
Quando você chega ao fim, você tem um produto que fica aquém
as expectativas de todos. Não só você não conseguiu resolver o seu
problema original, você realmente criou novos problemas para o seu
auto, porque agora o próximo grande projeto no horizonte é tentar
para resolver as deficiências do último projeto. E assim o ciclo
repete.
Olhando para um produto de fora – ou entrando no desenvolvimento
processo de desenvolvimento pela primeira vez - é fácil se concentrar no mais óbvio
elementos próximos ao topo do modelo de cinco planos à custa de
os mais próximos do fundo. A ironia, porém, é que os elementos
que são mais difíceis de ver - a estratégia, o escopo e a estrutura do
produto - desempenham o papel mais importante no sucesso geral ou
falha da experiência do usuário.
Em muitos casos, falhas nos planos superiores podem obscurecer sucessos em
planos inferiores. Problemas com design visual - layouts que parecem desajeitados
ted ou ocupado, ou cores que são inconsistentes ou conflitantes - podem se tornar
usuários tão rapidamente que eles nunca descobrem todas as escolhas inteligentes
você fez com navegação ou design de interação. Mal concebido
abordagens de design de navegação podem fazer todo o seu trabalho para criar um
uma arquitetura de informação sólida e flexível parece uma perda de tempo.

Da mesma forma, tomar todas as decisões corretas nos planos superiores significa
nada se essas decisões são baseadas em más escolhas feitas no
planos inferiores. A história da Web está repleta de sites que falharam
porque, embora fossem bonitos, eram totalmente inutilizáveis.
Concentrando-se no design visual com a exclusão dos outros elementos do
experiência do usuário levou mais de uma startup à falência e
levou outras empresas a se perguntarem por que estavam se preocupando com o
Web em tudo.
Não precisa ser assim. Se você abordar o desenvolvimento do seu produto
processo de otimização com a experiência completa do usuário em mente, você
pode sair disso com um produto que é um ativo, não um passivo.
Ao tornar tudo o que o usuário experimenta com o seu produto, o
resultado de uma decisão consciente e explícita, você pode garantir que o
produto funciona para cumprir tanto seus objetivos estratégicos quanto as necessidades de
seus usuários.
UMA C
botões de ação, descritos, 117 classificação de cartões, 49
abordagens arquitetônicas. caixas de seleção, descritas, 116,

Veja também informações 118
arquitetura CMS (gerenciamento de conteúdo
estrutura hierárquica, 93 sistema), 63-64
estrutura hub-and-spoke, paletas de cores, considerando em
93 design sensorial, 145-148
estrutura matricial, 93-94 comunicação, importância de, 12–
estrutura orgânica, 94-95 13
estrutura sequencial, 95 comp, definido, 148
estrutura de árvore, 93 concorrentes, inspirando-
atitudes dos usuários, se, 67-68
considerando, 44 modelos conceituais, 83-85, 97,
audiência, considerando conteúdo 111-112
para, 74 consistência
segmentos de público, com base considerando em design
em dados demográficos, 43–44 sensorial, 143-144
interno versus externo,
143–144
B contente
identidade da marca, considerando, considerando o público para,
38–39 74
requisitos de marca, definido, 12
considerando, 65 formato versus propósito, 72
objetivos de negócios, impacto na experiência do usuário,
definindo, 37–38 32
estruturação, 89-92
versus tecnologia, 32
166 ÍNDICE
recursos de conteúdo, atualização, sistemas de design, documentação,

73–74 150
inventário de conteúdo, tendo, 74 documentar. Veja também
requisitos de conteúdo, 71– wireframes
74. Veja também requisitos sistemas de design, 150
do projeto; requisitos especificações funcionais,
considerando, 29 69-71
considerando no plano listas suspensas, descritas, 117–
do escopo, 61-64 118
definindo, 63
inquérito contextual, 47
E
navegação contextual, 122
contraste e uniformidade, eficiência, melhorando, 15–16
considerando em design Modelo de elementos. Ver aviões
sensorial, 139-143 tratamento de erros, 86–88
vocabulário controlado, usando, correção, 86-87
98-99 prevenção, 86-87
convenção e metáfora, recuperação, 86-87
110–113 função desfazer, 88
convenções mensagens de erro, ocorrência
considerando, 84 de, 64
desenvolvendo, 116 rastreamento ocular, considerando
taxa de conversão, medição, 13– em design sensorial, 137-139
15
navegação de cortesia, 122–123
F
fidelidade do cliente, 13
facetas
benefícios de, 121
D definido, 98
dados demográficos, aplicando- Perguntas frequentes, considerando, 72
se a segmentos de público, 43–44 recursos
Projeto. Veja também design conflitos entre, 76

de produto; design centrado no usuário fazendo analogias com
por padrão, 156 experiências, 113
por fiat, 156 implementação de, 76
por mimetismo, 156 sugestões, 76–77
composições de design, restrições de tempo, 76
considerando em design sensorial, 148-151 uso de terminologia, 62
consistência do projeto, aplicação, cinco aviões. Veja também
144 plano de escopo; plano do
esqueleto; plano estratégico; estrutura
avião; plano de superfície; adaptabilidade de, 91-92

experiência de usuário abordagens, 92-95
construindo de baixo para abordagem de baixo para cima, 90
cima, 162 categorias em, 90-91
escolhas relacionadas a, 23 estrutura conceitual de, 97
considerando, 155 considerando, 30
decisões relacionadas a, 24 vocabulário controlado,
dependências de, 22-23 98-99
falhas em, 162-163 diagramação, 101-105
escopo, 21, 29 documentando, 101-105
esqueleto, 20, 30 fluxo de linguagem em, 95
estratégia, 21, 28 idioma, 98-101
estrutura, 20, 30 metadados, 98–101
superfície, 20, 30 nós em, 92-93
usando elementos de, 31-33 princípios de organização,
trabalhando, 24 96-98
especificações funcionais, 29, 62-64, estruturando conteúdo, 89-92
68-71 abordagem de cima para baixo, 89-90
uso do dicionário de sinônimos, 99
Vocabulário Visual, 102–

G 103
navegação global, 120-121 design da informação, 108-109.
técnica de layout baseada em grade, Veja também design de interface
141-142 considerando, 30, 45
princípios organizadores,
124–126
H
papel no design de interface,
experiência auditiva, 136 126
estrutura hierárquica, 93
tipo visual de, 124
estrutura de cubo e raios, 93 orientação, 127
hiperlinks, subutilização de, 122 navegação em linha, 122
design de interação, 81-82
modelos conceituais, 83-85
considerando, 30
EU
consistência de, 111-112

impressões, definidas, 40
convenção e metáfora,
índices, usando para navegação, 110
123
convenções, 84
arquitetura da informação, 81, 88-89.
tratamento de erros, 86–88
Veja também abordagens
convenções de interface,
arquitetônicas
mudanças em, 116
168 ÍNDICE
design de interface, 108–109. Veja índices, 123

também design de informações em linha, 122
considerando, 30 local, 121
sucesso de, 114 elementos persistentes, 120
elementos de interface mapas do site, 123
botões de ação, 117 suplementar, 121
caixas de seleção, 116, 118 ferramentas de navegação, 123
listas suspensas, 117–118 nós
caixas de listagem, 117 filho e pai, 93
botões de rádio, 116, 118 na estrutura hierárquica,
campos de texto, 116 93
na estrutura matricial, 93-94
em estrutura orgânica, 94
eu
princípios organizadores de,
idioma e metadados, 98–101 96
papel na informação
caixas de listagem, descritas, 117 estruturas, 92-93
navegação local, 121 nomenclatura, 98
M O
maratona e sprint, 159– Objetivos. Veja os objetivos
163 do produto
métodos de pesquisa de mercado, 46 sistemas operacionais, elementos
estrutura matricial, 93-94 de interface, 116–118
metadados e idioma, 98–101 Paleta de cores Orbitz, 146
estrutura orgânica, 94-95
metáfora e convenção, princípios de organização,
110–113 aplicação, 96–98
N P
projeto de navegação, 108-109. layout de página, 128–131
Veja também orientação elementos de navegação
considerando, 30 persistentes, 120
gols de, 118-119 pessoas
importância de, 119-120 criando, 49-51
sistemas de navegação, 120 inclusive nos requisitos,
contextual, 122 67
cortesia, 122-123 telefones, convenções
global, 120-121 relacionadas a, 110–111
aviões. Veja também plano requisitos do projeto. Consulte

de escopo; plano do também requisitos de conteúdo;
esqueleto; plano estratégico; requisitos
plano da estrutura; plano de esclarecendo, 59-61
superfície; experiência de usuário definindo, 65-68
construindo de baixo para gerando, 67
cima, 162 incluindo personas em, 67
escolhas relacionadas a, 23 gestão, 61
considerando, 155 projetos, planejamento, 24
decisões relacionadas a, 24 protótipos, 48-49
dependências de, 22-23 perfis psicográficos, 44
falhas em, 162-163
escopo, 21, 29
esqueleto, 20, 30
Q
estratégia, 21, 28 perguntas, colocando aos usuários,
estrutura, 20, 30 158–159
superfície, 20, 30
usando elementos de, 31-33
R
trabalhando, 24
botões de rádio, descritos, 116,
resolução de problemas, 157-159
118
design do produto, conceito de, 7–
8. Veja também projeto; design requisitos. Consulte também requisitos
centrado no usuário de conteúdo; requisitos do projeto
objetivos do produto,
esclarecendo, 61–64 coletando ideias para, 74
objetivos do produto desenvolvendo, 73
identidade da marca, 38–39 avaliando, 75
metas de negócios, 37–38 priorizando, 74-77
considerando, 28, 36, 91 objetivos estratégicos para, 75

ferramentas de pesquisa
métricas de sucesso, 39–41
classificação de cartões, 49
produtos
descrevendo conjuntos de recursos de, inquérito contextual, 47
29 métodos de pesquisa de mercado,
46
como funcionalidade, 27-29,
161 protótipos, 48-49
como informação, 27-29, 161 análise de tarefas, 47
planejamento, 59-60 teste de usuário, 47–48

sucesso de, 12-13 visitas de retorno, medição, 41
receita, aumentando, 14–15
ROI (retorno do investimento),
13
170 ÍNDICE
S plano esqueleto, 20, 30. Veja

também planos
escopo, definição, 58-59
convenção, 110-113
plano de escopo, 21, 29. Veja também
design da informação, 30,
aviões
108-109, 124-127
conteúdo, 61-64
design de interface, 30, 108–
requisitos de conteúdo, 29,
109, 114-118
71–74
metáfora, 110-113
definição de conteúdo
projeto de navegação, 30,
requisitos, 63
108–109, 118–123
definição de requisitos, 65-68
wireframes, 128-131
olfato e paladar, considerando no
Especificações funcionais,
design sensorial, 135
29, 62, 68-71
software, foco de, 82–83
funcionalidade, 61–64
soluções, encontrar
priorização de requisitos, 74-77
problemas, 157–159
Local da Southwest Airlines, 85
papel na arquitetura
arrancada
de baixo para cima, 90
definido, 159
componente de estratégia de, 75
estratégia, 160
partes interessadas
paletas de cores, 145–148
preocupações com a estratégia, 77
consistência, 143-144
definido, 52
contraste e uniformidade,
resolver conflitos
139-143
entre, 77
composições de design, 148-151
objetivos estratégicos, reunião, 40
rastreamento ocular, 137-139
objetivos estratégicos,
audição, 136
requisitos para, 75
cheiro e sabor, 135
estrategistas, emprego de,
guias de estilo, 148–151
52
toque, 135-136
documento de estratégia
tipografia, 145-148
conteúdo de, 53-54
visão, 136-137
hierarquia de, 77
experiência sensorial,
plano estratégico, 21, 28. Veja também
considerando, 30
aviões
estrutura sequencial, 95
objetivos do produto, 28
site, uso de terminologia, 9–10
papel na arquitetura
mapas do site, uso de, 102, 123
de cima para baixo, 90
esqueleto, definição, 108-109
necessidades do usuário, 28
plano de estrutura, 20, 30. Veja T

também planos
análise de tarefas, 47
arquitetura da informação, 30,
paladar e olfato, considerando no
81, 88–101
design de interação, 30, 80-88
papéis e processos da equipe
para plano de estratégia, 52-54
funções e processos da
para plano de estrutura,
equipe, 101–105
101–105
estruturas
ferramentas de tecnologia, restrições,
definindo, 80-81
115
estrutura hierárquica, 93
tecnologia versus conteúdo, 32
estrutura hub-and-spoke,
telefones, convenções
93
relacionadas a, 110–111
estrutura matricial, 93-94
elementos de texto, considerando,
estrutura orgânica, 94-95
147
estrutura sequencial, 95
campos de texto, descritos, 116
estrutura de árvore, 93
dicionário de sinônimos, usando, 99
guias de estilo, considerando em
experiência de toque, 135–136
design sensorial, 148-151
estrutura de árvore, 93
métricas de sucesso, 39–41
tipografia, considerando em design
navegação suplementar,
sensorial, 147-148
121
superfície, definindo, 134

plano de superfície, 20, 30. Veja também DENTRO
aviões
função desfazer, usando no tratamento
paletas de cores, 145–148
de erros, 88
consistência, 143-144
uniformidade e contraste,
contraste e uniformidade,
considerando em design
139-143
sensorial, 139-143
composições de design, 148-151
usabilidade, definida, 48
rastreamento ocular, 137-139
teste de aceitação do usuário, 158
audição, 136 comportamento do usuário. Veja o design
sentidos, 135-137
de interação
experiência sensorial, 30
experiência de usuário. Veja também
cheiro e sabor, 135
aviões
guias de estilo, 148–151
escolhas feitas, 156
toque, 135-136
definido, 6
tipografia, 145-148
delegando responsabilidade
visão, 136-137
por, 31
projeto, 7–8
172 ÍNDICE
experiência do usuário DENTRO
(continuação ) design por

conteúdo do
padrão, 156 design por fiat,
documento de visão
156 design por mimetismo,
de, 53–54 hierarquia
156 design para, 8–9 detalhes
de, 77 experiência de visão, 136–
de, 6 analogias de desenho
137 designs visuais,
com recursos, 113
correspondência com wireframes,
149 layout visual neutro, 140
formação da comunidade,
Vocabulário Visual, 102–103
26
impacto do conteúdo em, 32
Dentro
impacto nos negócios, 12–17
incluindo no processo de
wayfinding, 127. Veja também
desenvolvimento, 11 metáfora
design de navegação
para, 159 qualidade de, 12–17 Interesses comerciais na Web
design bem sucedido de, 154 na
sobre,
Web, 9–12 modelos de usuário, 26
criação, 49–51 necessidades do
requisitos de conteúdo, 62
usuário
evolução de, 25-26
especificações funcionais,
considerando, 28, 36 62
criando personas, 49–51
experiência do usuário ativada, 9–12
identificando, 42 perfis Elementos da Web
psicográficos, 44 ferramentas de
funcionalidade, meio de
pesquisa relacionadas a,
informação 27-28,
46
27–28
compreensão, 46–49
Web sites, falha de, 36
usabilidade, 46–49 perfis de wireframes. Consulte também
usuário, criação, 49–51 pesquisa de
a documentação de designs
usuário, 46–49, 51 segmentos de
visuais correspondentes ao
usuário, 42–46 importância de, 45
plano de esqueleto 149, 128–
revisão após pesquisa, 45 teste
131
de usuário, 47–48 centrado no
usuário design, 17. Veja também
design; design de produto
usuários
escolhas apresentadas para,

10 perguntas para, 158-159

The Elements of User Experience User Cen

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

The Elements of User Experience User Cen

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Machine Translated by Google

DESIGN CENTRADO NO USUÁRIO

Escrito e ilustrado por

Os elementos da experiência do usuário: design centrado no usuário para a Web e além,

New Riders1249 Eighth Street

Encontre-nos na Web em: www.newriders.com

Copyright © 2011 por Jesse James Garrett

Editor do projeto: Michael J. Nolan

ISBN 13: 978-0-321-68368-7

Impresso e encadernado nos Estados Unidos da América

Para minha esposa, Rebecca Blood

4 OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO

Experiência do usuário e por que é importante 2

Misérias do dia a dia 3

Apresentando a experiência do usuário 4

Do design do produto ao design da experiência do usuário 7

Projetando (para) experiência: o uso é importante 8

Experiência do usuário e a Web 9

Uma boa experiência do usuário é um bom negócio 12

Cuidando de seus usuários 17

Construindo de baixo para cima 21

Uma Dualidade Básica 25

Os elementos da experiência do usuário 28

OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO dentro

Usabilidade e pesquisa de usuários 46

Funções e processos da equipe 52

Você está construindo 59

Você não está construindo 60

nós OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO

Funções e processos da equipe 101

Definindo o esqueleto 108

Convenção e Metáfora 110

Design de interface 114

Projeto de navegação 118

Design de Informação 124

Estruturas de arame 128

OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO vii

Definindo a Superfície 134

Dando sentido aos sentidos 135

Siga o olho 137

Contraste e uniformidade 139

Consistência interna e externa 143

Paletas de cores e tipografia 145

Comps de design e guias de estilo 148

Os Elementos Aplicados 152

Fazendo as perguntas certas 157

A Maratona e o Sprint 159

viii OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO

consultoria de experiência do usuário com sede em São Francisco. Desde 1995,

Jesse trabalhou em projetos Web para empresas como AT&T,

Intel, Boeing, Motorola, Hewlett-Packard e National Public

Rádio. Suas contribuições para o campo da experiência do usuário incluem a

documentação de arquitetura que agora é usada por organizações ao redor

o mundo. Seu site pessoal em www.jjg.net é um dos

destinos mais populares para recursos de arquitetura da informação,

e ele é um palestrante frequente sobre arquitetura da informação e usuário

OS ELEMENTOS DA EXPERIÊNCIA DO USUÁRIO ix

Agradecimentos para a segunda edição

persistência - e sua ingenuidade em finalmente chegar a uma oferta que eu

Na New Riders, a equipe de Rose Weisburd, Tracey Croom e Kim

Mimi Vitetta ajudou a fazer as coisas acontecerem. Obrigado também a Samantha

Bailey e Karl Fast pelo apoio.