Doku - Pub Atomic Design Brad Frostpdf

Machine Translated by Google
Design Atômico
Brad Frost
Design Atômico
Brad Frost
Índice
1. Projetando Sistemas
Crie sistemas de design, não páginas 8
2. Metodologia de Design Atômico

Átomos, moléculas, organismos, modelos e páginas
38
3. Ferramentas do comércio
Pattern Lab e as qualidades de guias de estilo eficazes
64
4. O fluxo de trabalho atômico

Pessoas, processos e como fazer os sistemas
de design acontecerem 94
5. Manutenção de sistemas de design

Fazendo com que os sistemas de design resistam ao teste do tempo 142
Agradecimentos e Reconhecimentos 182
Recursos 184
Sobre o autor 191

Copyright © 2016 Brad Frost Todos os direitos reservados
Editor: Brad Frost

Editor de texto: Owen Gregory
Designer de livro impresso: Rachel Arnold Sager
Designer de e-book: Rachel Andrew
ISBN: 978-0-9982966-0-9
Orgulhosamente criado em Pittsburgh, Pensilvânia

Prefácio
Era 2013 e estávamos reunidos com Brad Frost e Jennifer Brook em torno de uma mesa de
cozinha ensolarada no Brooklyn. Nós quatro tínhamos acabado de começar a trabalhar
em um novo site para o TechCrunch e estávamos desenhando wireframes no apartamento
de Jennifer, lutando com as novas demandas de design responsivo. Brad pegou seu laptop:
“Estou brincando com uma nova ideia”.
A tela de Brad parecia que uma página da web havia explodido. Pedaços de UI flutuavam
livres uns dos outros, livres de um design ou hierarquia unificada.
Parecia uma pilha de peças sobressalentes de uma garagem virtual.
Brad deu seu sorriso maluco e acenou com a cabeça: "Ótimo, certo?" Nós três olhamos
de volta sem expressão. Alguém tossiu.
E então Brad Frost, o desenvolvedor front-end, começou a falar como Brad Frost, o
químico. Ele falou sobre átomos, moléculas e organismos – sobre como grandes peças de
design podem ser divididas em peças menores e até mesmo recombinadas em
diferentes peças grandes. Em vez de visualizar a receita finalizada do design,
ou seja, ele estava nos mostrando os ingredientes. E nós nos iluminamos: esta foi
uma mudança de perspectiva, uma forma de deixar de conceber o design de um
site como uma coleção de modelos de páginas estáticas e, em vez disso, como um
sistema dinâmico de componentes adaptáveis. Foi uma maneira inspirada de abordar este
site responsivo – e todos os projetos responsivos nesse sentido.
A nova ideia de Brad foi o design atômico e mudou a maneira como trabalhamos neste
mundo surpreendentemente multidispositivo. Ao pensar em interfaces simultaneamente
tanto no nível grande (página) quanto no nível pequeno (atômico), simplificamos
nosso processo: introduzimos um pensamento mais rigoroso na função de cada elemento;
adquirimos hábitos que melhoraram a consistência da nossa experiência do usuário; e, o que
é mais importante, começamos a trabalhar de forma muito mais rápida e colaborativa. O
design atômico era nosso superpoder.
Nos estágios iniciais do redesenho do TechCrunch, houve um momento em que

conversamos sobre como queríamos que a página do artigo fosse. Em uma hora, Brad
tinha uma versão totalmente responsiva instalada em seu kit de peças. Foi nesse
momento que percebemos a rapidez com que seríamos capazes de avançar, um argumento
poderoso para investir nesta abordagem inteligente e modular.
Quase quatro anos depois, não olhamos para trás. Brad continuou a refinar suas
técnicas e ferramentas nos projetos que se seguiram,
6PROJETO ATÔMICO
incluindo sites de grande sucesso da Entertainment Weekly e Time, Inc.

Usamos essas lições para ajudar equipes internas de produtos a tornar
sites mais rápidos e com maior qualidade, construir sistemas de design
massivos para organizações que buscam centralizar seu trabalho de design e
desenvolvimento em escritórios internacionais e muito mais.
O design atômico nos deu velocidade, liberdade criativa e flexibilidade.

Isso mudou tudo. Achamos que fará o mesmo por você também.
Este livro maravilhoso explica a filosofia, prática e manutenção de

sistemas de design atômico. E faz isso com a generosidade alegre e
prestativa que o próprio Brad descreve.
A energia e o grande entusiasmo de Brad pela web e seus criadores

são ilimitados. Durante anos, Brad trabalhou na vanguarda da técnica de
design responsivo – e compartilhou tudo ao longo do caminho. Seu site This
Is Responsive é o recurso ideal para encontrar soluções responsivas para
qualquer problema de UX. Seu blog e feeds do Twitter compartilham seus
obstáculos e soluções. Quando designers e desenvolvedores seguem Brad
Frost, eles obtêm um fluxo rápido e denso de insights práticos e
apaixonados para a construção de sites bonitos e resilientes.
Este livro se desdobra em tudo isso.
Se tivesse oportunidade, Brad bateria na porta de cada designer e

desenvolvedor para entregar pessoalmente sua mensagem. Observamos
com espanto (e uma leve inveja) como esse dervixe rodopiante percorreu
o mundo para compartilhar seus conselhos com centenas de equipes e
organizações em seis continentes. (Design atômico, em breve na Antártica!)
Mas mesmo Brad Frost não pode estar em todos os lugares ao mesmo
tempo, e estamos muito satisfeitos por ele ter detalhado suas ideias com
tanta profundidade e bom humor neste livro.
O design atômico está explodindo em todo o mundo; transformou nossa

prática de design; e estamos entusiasmados por trazer a mesma combustão
criativa para o seu processo também.
-Josh Clark e Dan Mall, Os colaboradores frequentes de Brad e seus

Maiores fãs
ANTERIOR 7
Capítulo 1
Projetando
Sistemas
Crie sistemas de design, não páginas
7 http://www.uie.com/articles/magic_escalator/
8 http://en.wikipedia.org/wiki/Scrum_%28software_development%29
8PROJETO ATÔMICO
Há muito, muito tempo atrás, existiam essas coisas chamadas livros.

Lembra deles? Essas engenhocas eram pesadas e volumosas e feitas de polpa
de árvores mortas. Dentro desses livros havia coisas chamadas páginas. Você os
virou e eles cortaram seus dedos.
Coisas horríveis. Estou tão feliz que esses livros com suas páginas nítidas não
existam mais.
Oh espere…
Nosso passado paginado
A página está conosco há muito tempo. Alguns milênios, na verdade. Os primeiros

livros eram grossas placas de argila criadas há cerca de 4 mil anos, logo substituídas
por pergaminhos como forma preferida de consumir a palavra escrita. E embora a
tecnologia de leitura tenha percorrido um longo caminho – do papiro ao pergaminho,
do livro de bolso aos pixels – o conceito de página permanece forte até hoje.
A metáfora da página está inserida no léxico da web desde o início. Tim Berners-Lee
inventou a World Wide Web para que ele, os seus colegas do CERN e outros
académicos pudessem facilmente partilhar e interligar o seu mundo de documentos.
Essa gênese acadêmica da web baseada em documentos é a razão pela qual o
conceito de página está tão profundamente enraizado no vocabulário da Internet.
E daí?
Como discutiremos ao longo deste livro, a forma como as coisas são nomeadas
tem um grande impacto no modo como elas são percebidas e utilizadas. Pensar
na web como páginas tem implicações reais em como as pessoas interagem com
as experiências na web e influencia a forma como criamos interfaces web.
Desde o início, a metáfora da página forneceu aos usuários uma linguagem

familiar para navegar nesta admirável nova World Wide Web. Conceitos como
bookmarking e paginação ajudaram novos usuários da web a explorar e,
eventualmente, dominar um meio inteiramente novo usando convenções com as quais
já estavam familiarizados.
CAPÍTULO 1 / PROJETO DE SISTEMAS 9

Navegador Chrome exibindo a mensagem "Esta página da web não está disponível".
A página foi – e continua a ser – uma metáfora muito visível e útil para os
utilizadores da web. Também tem uma influência profunda sobre como as experiências
na web são criadas.
Nos primórdios da web, as empresas que desejavam ficar on-line simplesmente

traduziam seus materiais impressos em seus sites. Mas mesmo que esses sites
de folhetos oferecessem uma perspectiva muito unidimensional do que a web
poderia oferecer, ver os sites como representações digitais da página impressa era
fácil para os criadores entenderem.
Mas já estamos há 25 anos neste novo meio de comunicação, e esta

forma de expressão, outrora necessária, deixou de ser bem-vinda.
Infelizmente, a metáfora da página continua a ser profunda no que diz
respeito à forma como avaliamos e executamos nossos projetos web. Aqui
estão apenas alguns exemplos que ouço regularmente:
“Somos uma startup que pretende lançar um site de cinco páginas em

outubro…”
“Brad, quanto tempo a página inicial levará para ser construída?”
“Como vamos redesenhar este site universitário que contém mais de 30.000
páginas?!”
10DESIGN ATÔMICO
Todas as afirmações acima cometem o erro fundamental de

assumindo que uma página é algo uniforme, isolado e quantificável. A realidade
é que a web é um meio fluido, interativo e interdependente. Assim que
aceitamos esse fato, a noção de página rapidamente se desgasta como um
meio útil para definir o escopo e criar experiências na web.
Quanto tempo levará para construir uma página inicial? Bem, isso depende do que
está nele, certo? Talvez a página inicial consista simplesmente em um slogan e
uma imagem de fundo, o que significa que pode ser feita na hora do almoço. Ou
talvez esteja repleto de carrosséis, formulários dinâmicos e integrações de
terceiros. Nesse caso, talvez a página inicial demore vários meses para ser
concluída.
Quanto ao site da universidade com 30.000 páginas, pode ser tentador declarar:
“Milhares de páginas?! Uau, isso parece desafiador! Mas, na realidade, essas 30 mil
páginas podem consistir em três tipos de conteúdo e dois layouts abrangentes.
Em última análise, o nível de esforço de um projeto é muito melhor determinado

pela funcionalidade e pelos componentes contidas nessas páginas, e não na
quantidade de páginas em si.
A metáfora da página serviu ao seu propósito de ajudar os usuários a se familiarizarem

com a web e forneceu aos criadores a linguagem de transição necessária para criar
um meio totalmente novo.
Mas para construir interfaces pensadas destinadas a servir a uma infinidade de
dispositivos conectados, chegou a hora de evoluirmos além da página.
Rasgando a página
Felizmente, a comunidade da web está trabalhando arduamente para

estabelecer princípios e práticas que nos ajudem a falar e criar de maneira
eficaz para a web. E há um conceito que continua surgindo em todas as
conversas sobre como criar experiências na Web bem-sucedidas:
modularidade.
A modularidade é muito anterior à web. A Revolução Industrial trouxe

peças intercambiáveis e a linha de montagem de Henry Ford transformou para
sempre a fabricação de automóveis

processo. Os primeiros carros e componentes foram fabricados individualmente, o que

gerou muitos pesadelos de segurança e manutenção. A Ford dividiu o automóvel em
seus componentes e modularizou o processo de montagem. Os resultados falaram por
si: carros mais uniformes, mais confiáveis e mais seguros saíram da fábrica e, ainda
por cima, em tempo recorde.
À medida que a era da máquina se tornou a era do computador, os cientistas da

computação começaram a praticar a programação orientada a objetos e a
estabelecer conceitos modulares importantes, como a separação de preocupações e o
princípio da responsabilidade única. Foi deste mundo que nasceu a World Wide Web,
por isso não é surpresa que o design modular rapidamente se tornou um princípio de
design para a arquitetura da web.
Lentamente, mas com segurança, esses conceitos chegaram aos fluxos de trabalho dos
web designers. No início dos anos 2000, vimos a introdução de bibliotecas como
YUI e interface jQuery que forneceu aos desenvolvedores um kit de ferramentas
de widgets e padrões para criar interfaces de usuário mais consistentes.
Se a modularidade já existe há tanto tempo, por que estamos falando dela agora?
A resposta curta é que a modularidade é mais importante do que nunca. No momento,

toda a nossa indústria está se afogando em um mar de dispositivos, tamanhos de
janelas de visualização e ambientes online. E as coisas não vão desacelerar tão
cedo.
A disrupção só irá acelerar. A quantidade e a diversidade de

dispositivos conectados – muitos dos quais ainda não imaginamos –
irão explodir, assim como a quantidade e a diversidade das pessoas
em todo o mundo que os utilizam. Nossos padrões, fluxos de trabalho e
infraestrutura existentes não se sustentarão. O ataque atual de dispositivos
já os está levando ao ponto de ruptura. Eles não podem suportar o que
está por vir.
- O manifesto Amigo do Futuro
12PROJETO ATÔMICO
Estes são apenas alguns dos dispositivos conectados com os quais precisamos nos preocupar.
Goste ou não, este universo multi-dispositivos é a nossa realidade. Já foi bastante

difícil fazer com que nossas páginas da Web fossem exibidas de forma consistente
em alguns navegadores de desktop, mas agora temos a tarefa de garantir que nossas
experiências na Web tenham uma aparência e um funcionamento perfeitos em uma
variedade estonteante de smartphones, tablets, phablets, netbooks, notebooks, desktops. ,
TVs, consoles de jogos e muito mais.
Para enfrentar esta realidade e ao mesmo tempo manter a nossa sanidade, é

absolutamente necessário darmos um passo atrás e dividirmos estas
responsabilidades gigantescas em pedaços menores e mais administráveis.
E é exatamente isso que as pessoas estão fazendo. O espírito da modularidade está

presente em todos os aspectos do processo de criação da web e tem efeitos
profundos na estratégia, no processo, no conteúdo, no design e no desenvolvimento
das organizações.
Uma estratégia gerenciável
Cada organização está finalmente percebendo que demolir todo o seu site e substituí-
lo por um site New-And-Shiny™ a cada três a oito anos não é (e nunca foi) uma
solução ideal.

Fora com o velho! Com o novo! É certamente uma perspectiva atraente.

Mas mesmo antes de os confetes da festa de lançamento serem varridos, as
ligações começam a chegar. “Você mexeu no meu queijo!” gritam os usuários, que
passaram anos aprendendo a interface e a funcionalidade anteriores.
Quando grandes reformulações são lançadas com mudanças significativas na

experiência, os usuários são derrubados no que Jared Spool chama de
“escada rolante mágica do conhecimento adquirido”. Grandes reformulações
são um choque para o sistema, e os usuários recentemente frustrados precisam
gastar muito tempo e energia reaprendendo a experiência para poder subir lentamente
de volta na escada rolante do conhecimento adquirido.
Além de desorientar os usuários, essas reformulações monolíticas não

chegam à raiz organizacional do problema. Sem uma mudança fundamental
no processo, a história certamente se repetirá, e o que é novo e brilhante™
hoje se tornará velho e encrostado™ amanhã. O ciclo se repete à medida
que as empresas empurram pequenas atualizações até a próxima grande
reformulação, acabando por paralisar-se e frustrar os usuários no processo.
Felizmente, até mesmo grandes organizações estão seguindo dicas do mundo

menor e mais enxuto das startups e se esforçando para lançar as coisas mais
rapidamente. Ao criar produtos mínimos viáveis e enviá-los com frequência
para melhorar iterativamente a experiência, as organizações são capazes de
atender melhor ao feedback do usuário e acompanhar o cenário da web em
constante mudança.
Afastar-se dos redesenhos do tipo "configure e esqueça" no estilo Ron

Popeil requer mudanças deliberadas na estrutura organizacional e no fluxo de
trabalho. O que é muito mais fácil falar do que fazer.
Um processo iterativo
Se eu ganhasse 25 centavos por cada vez que ouço uma parte interessada
declarar “Estamos tentando ser mais ágeis”, estaria orbitando a Terra em minha
espaçonave particular, em vez de escrever este livro.
Querer ser mais ágil é louvável. Mas ágil é um termo carregado, com grandes diferenças entre
Ágil maiúsculo e Ágil minúsculo. Capital-A Agile é uma metodologia específica para desenvolvimento
de software, equipada com um manifesto e estruturas de acompanhamento como Scrum e
magro.
14PROJETO ATÔMICO
Em minúsculas, ágil é mais um desejo informal de criar um processo eficiente.

Este desejo pode certamente passar pela adopção de princípios gerais do A maiúsculo
Ágil, mas pode não envolver a adoção do processo Ágil em sua totalidade. O gerente
de projeto Brett Harned explica:
Queremos ser mais ágeis; estamos abraçando a mudança, a melhoria

contínua, sendo o mais flexíveis possível e nos adaptando
conforme acharmos. A questão é que nunca seremos realmente
ágeis, como afirma o Manifesto. Tudo bem, desde que digamos o que seremos.
- Brett Harned
A estrutura organizacional, as relações com os clientes, as personalidades e assim

por diante desempenham papéis importantes na determinação do processo de um
projeto. O truque é encontrar o processo que funciona melhor para você, para suas
restrições e oportunidades organizacionais.
Mesmo que seja impossível adotar um processo verdadeiramente Ágil, ainda é uma boa
ideia trabalhar em equipes interdisciplinares, chegar ao ambiente final mais
rapidamente, entregar com antecedência e frequência e dividir tarefas maiores em
componentes menores. No capítulo 4, detalharemos como estabelecer um fluxo de
trabalho eficaz baseado em padrões.
Modularizando conteúdo: estou no Team Chunk
Prepare seu conteúdo para ir a qualquer lugar, porque ele irá a

qualquer lugar.
- Por uma Web favorável ao futuro
Publicar conteúdo para a Web costumava ser uma tarefa bastante simples, já que a
Web para desktop era o único jogo disponível. Oh, como as coisas mudaram. Hoje,
nosso conteúdo é consumido por uma grande quantidade de smartphones, telefones
inteligentes, netbooks, notebooks, tablets, e-readers, smartwatches, TVs, consoles de
jogos, sinalização digital, painéis de carros e muito mais.
Para abordar adequadamente este cenário digital cada vez mais diversificado e
eclético, precisamos de rever drasticamente a nossa perceção do conteúdo e
das ferramentas que utilizamos para o gerir.

No futuro, acredito que teremos melhores ferramentas de gerenciamento

e publicação de conteúdo. Teremos maneiras de obter conteúdo
bem estruturado, pedaços de conteúdo bem projetados que
poderemos então descobrir como queremos reestruturar, publicar
e exibir de uma forma que seja adequada para a plataforma apropriada.
-Karen McGrane
Felizmente, este futuro está começando a tomar forma. As organizações estão

reconhecendo a necessidade de criar conteúdo modularizado para melhor alcançar
seu público onde quer que ele esteja. E os sistemas de gerenciamento de
conteúdo estão evoluindo além das raízes da plataforma de publicação na web
para ferramentas que podem criar e manter conteúdo modular com elegância.
Embora sistemas sofisticados de gerenciamento de conteúdo existam há anos na
forma de soluções personalizadas, como a plataforma COPE (Create Once, Publish
Everywhere) da NPR, o pensamento modular inteligente está entrando nos
principais sistemas de gerenciamento de conteúdo.
Código elegante
A modularidade tem sido um princípio básico no mundo da ciência da

computação, como discutimos anteriormente. Embora esse princípio já
existisse muito antes de a web ser inventada, levou algum tempo para que a
modularidade se tornasse enraizada nas mentes e nos corações dos
desenvolvedores web.
Apesar de existir desde 1995, o JavaScript, a linguagem de programação da

web, primeiro teve que suportar algumas dores de crescimento para amadurecer
e se tornar a linguagem capaz e respeitada que é hoje. Agora que o JavaScript
cresceu, os desenvolvedores podem aplicar esses princípios testados e comprovados
da ciência da computação aos seus fluxos de trabalho de desenvolvimento web.
Como resultado, estamos vendo pessoas desenvolvendo padrões JavaScript
sofisticados e arquiteturas.
Aplicar princípios de programação modular ao JavaScript é um tanto óbvio, já que

o próprio JavaScript é uma linguagem de programação.
Mas o pensamento orientado a objetos também está se infiltrando em outros
aspectos da web, incluindo CSS, a linguagem de estilo da web.
Metodologias como OOCSS, SMACSS, e BEM surgiram para ajudar web
designers a criar e manter arquiteturas CSS modulares.
16PROJETO ATÔMICO
Reparado visualmente
A modularidade não está apenas infiltrando o lado do código do estilo na web,

mas também revolucionando a forma como os designers visuais abordam o web
design moderno.
À medida que o número de janelas de visualização e ambientes prolifera, torna-se insustentável

produzir modelos estáticos de cada página de uma experiência web. Como brincou Stephen
Hay, apresentar composições completas do Photoshop “é a maneira mais eficaz de mostrar aos
seus clientes como o site deles nunca será”.
Isso não quer dizer que ferramentas de design estáticas como Photoshop e
Sketch não sejam importantes. Longe disso. Mas foi a forma como usamos
essas ferramentas que mudou drasticamente. Embora a criação de centenas
de composições completas não seja realista, essas ferramentas estáticas
são excelentes por fornecer um playground para estabelecer o que Andy
Clarke chama de “atmosfera de design”:
A atmosfera descreve os sentimentos que temos e que são

evocados pela cor, textura e tipografia. Você já deve pensar na
atmosfera em termos diferentes. Você pode chamar isso de
“sensação”, “humor” ou mesmo “identidade visual”. Quaisquer que sejam
as palavras que você escolher, a atmosfera de um design não
depende do layout. É independente da disposição e posicionamento
visual. Será visto ou sentido em todos os tamanhos de tela e em todos os dispositivos.
-Andy Clarke
Estabelecer antecipadamente a atmosfera do design é fundamental para o

sucesso de um projeto, e é por isso que os designers encontraram maneiras de facilitar
essas conversas importantes sem ter que gerar maquetes completas.
A designer Samantha Warren desenvolveu artefatos de design chamados
blocos de estilo, que demonstram explorações de cor, tipo e textura em uma bela
página encapsulada. O designer Dan Mall baseou-se na ideia de Samantha
com um conceito chamado colagens de elementos, que demonstram explorações
da atmosfera de design em uma colagem explodida de elementos de interface.

Os blocos de estilo, um conceito criado pela designer Samantha Warren, permitem que os designers
explorem cores, tipografia e textura sem ter que desenvolver composições totalmente realizadas.
Ao dividir as explorações visuais em partes menores, os designers

economizam tempo e esforço, evitando apresentar layouts
prematuros e irrealistas aos clientes. Mais importante ainda, estas
abordagens afastam as partes interessadas de simplesmente reagirem a
uma imagem bonita e, em vez disso, facilitam conversas cruciais sobre
a direção geral do design e como elas se relacionam com os objetivos do
projeto. Discutiremos esses conceitos com mais detalhes no capítulo 4,
mas basta dizer que o fluxo de trabalho do design visual está mudando muito!
Design sistemático de UI
Não estamos projetando páginas, estamos projetando sistemas

de componentes.
-Stephen Hay
Do que é feita uma interface? Quais são os nossos tijolos Lego? Quais
são os nossos sanduíches Subway que combinamos em milhões de
combinações deliciosas? São essas perguntas que temos nos perguntado
cada vez mais agora que enviamos nossas interfaces para cada vez mais
lugares.
Há alguns anos, Ethan Marcotte nos apresentou a ideia de web

design responsivo e seus três princípios básicos: grades fluidas, mídia
flexível e consultas de mídia CSS. Esses três ingredientes forneceram uma
base muito necessária para os designers criarem layouts flexíveis
18 PROJETO ATÔMICO
que se adaptam de forma inteligente a qualquer tamanho de tela. Talvez o mais importante
seja que o design responsivo ajudou a deixar os designers entusiasmados com a
criação de experiências web bem pensadas, adaptáveis e para vários dispositivos.
Como os designers descobriram rapidamente, criar experiências web para vários

dispositivos envolve muito mais do que criar páginas moles. Cada parte individual de uma
interface contém seus próprios desafios e oportunidades exclusivos para que ela tenha uma
ótima aparência e funcione perfeitamente em vários tamanhos de tela e ambientes.
Como podemos apresentar a navegação primária – normalmente exibida como uma lista
horizontal em telas grandes – de maneira cuidadosa em telas menores? Como lightboxes,
breadcrumbs e carrosséis se traduzem em viewports menores e tipos de entrada alternativos?
Foram essas perguntas que me levaram a criar This Is Responsive, uma vitrine de padrões
responsivos que demonstram as diversas maneiras pelas quais um determinado componente
pode ser executado em um ambiente responsivo.
Embora This Is Responsive tenha sucesso em articular como esses padrões de interface
podem ser dimensionados em tamanhos de tela e ambientes, ainda cabe aos designers e
desenvolvedores colocar esses padrões em ação. E acontece que isso dá muito trabalho.
Frameworks de UI, na teoria e na prática
Designers e desenvolvedores já estão precisando de tempo e recursos e agora têm

a tarefa de criar interfaces que tenham uma ótima aparência e funcionem perfeitamente
em qualquer ambiente. Essa é uma tarefa muito difícil.
Essa necessidade de abordar a crescente diversidade de dispositivos e, ao

mesmo tempo, lançar projetos de maneira sã, deu origem a estruturas de front-
end como Foundation by Zurb e Bootstrap. Essas estruturas de interface de usuário
fornecem aos designers uma coleção de padrões HTML pré-montados, estilos CSS e
JavaScript para adicionar funcionalidade a componentes interativos, como menus
suspensos e carrosséis. Em essência, essas estruturas são kits de ferramentas úteis para
montar interfaces rapidamente.

Bootstrap fornece uma coleção de componentes de UI para acelerar o desenvolvimento.
E cara, essas coisas são populares. Enquanto escrevo isto, Bootstrap é o

repositório mais popular no site de compartilhamento de código GitHub, com
mais de 77.000 estrelas e 30.000 garfos. A popularidade dessas estruturas é
uma prova do fato de que designers e desenvolvedores estão buscando uma
base sólida para se firmarem neste cenário web cada vez mais complexo.
Um dos aspectos mais atraentes dessas estruturas é a velocidade.

Frameworks como o Bootstrap permitem que os designers obtenham ideias
básicas rapidamente, criem protótipos rapidamente e lancem sites mais cedo.
Como os padrões fornecidos por um kit de ferramentas já foram testados em
vários navegadores, os desenvolvedores podem gastar seu tempo em tarefas mais
importantes, em vez de bater a cabeça em uma mesa testando alguma versão
arcaica do Internet Explorer. E caso os designers tenham problemas, as
comunidades dessas estruturas podem fornecer suporte e conselhos úteis.
Para os freelancers, esse aumento na velocidade pode significar que eles

podem assumir um ou três projetos extras, gerando mais estabilidade
financeira para o ano. E no mundo das startups – um lugar onde o Bootstrap está
vinteDESIGN ATÔMICO
omnipresente – produtos mínimos viáveis podem ser lançados mais cedo, levando a
respostas mais rápidas relativamente à viabilidade dos produtos.
Portanto, estruturas como Bootstrap são sistemas de design extremamente populares que
fornecem componentes bem testados, resultando em designs consistentes e
lançamentos mais rápidos. O que há para não amar? Bem, como quase tudo na vida,
existem contras ao lado dos prós.
Problemas no paraíso da estrutura
Quando eu era criança, assistia a filmes de ficção científica e programas de TV com um

estranho fascínio. Havia uma pergunta da qual nunca conseguia me livrar: por que estão
todos vestidos da mesma forma?
No futuro, todos se vestirão iguais. Crédito da ilustração: Melissa Frost.
Eu só poderia imaginar que com tempo suficiente, resolveríamos a moda. “Diga, esses
macacões são bem estilosos e confortáveis também! Vamos todos usar isso de agora em
diante.” "Parece bom para mim!"
Claro, não é assim que os seres humanos funcionam. Todos nós temos gostos, objetivos e
desejos diferentes. A variedade, como se costuma dizer, é o tempero da vida, e a moda, a
música e o design refletem a nossa natureza diversa. No entanto, na web tendemos a cair
na armadilha de querer que todos façam as coisas da mesma maneira. “Por que todos
os navegadores não padronizam apenas o WebKit?” “Por que os fabricantes de
dispositivos não podem usar os mesmos tamanhos de tela?” “Sempre use jQuery!” “Nunca
use jQuery!” “Basta usar estruturas!” “Nunca use estruturas!”

Assim como no mundo real, as diversas necessidades, objetivos e desejos dos projetos web levam a
uma infinidade de soluções diferentes. É claro que há hora e lugar para tudo, e designers e
desenvolvedores precisam de discernimento para saber quais ferramentas usar e quando.
Frameworks front-end são ferramentas que fornecem uma solução específica e

uma aparência específica. Embora essas soluções ajudem a acelerar o
desenvolvimento, as experiências resultantes acabam lembrando aqueles
macacões de ficção científica. Quando todos usam os mesmos botões, grades,
menus suspensos e componentes, as coisas naturalmente começam a parecer
iguais. Se Nike, Adidas, Puma e Reebok redesenhassem seus respectivos sites
usando Bootstrap, eles seriam substancialmente semelhantes. Certamente
não é isso que essas marcas buscam. Claro, cada marca pode modificar e estender
a aparência padrão, mas depois de um tempo a personalização significa lutar
contra a estrutura, o estilo e a funcionalidade fornecidos pela estrutura.
Além de problemas semelhantes, essas estruturas podem adicionar inchaço desnecessário

a uma experiência. É fantástico que os frameworks forneçam muitos componentes e funcionalidades
pré-construídos, mas uma grande porcentagem de designers e desenvolvedores não adotará todos os
aspectos do framework. Infelizmente, os usuários ainda precisam baixar o CSS e o JavaScript não
utilizados da estrutura, resultando em carregamentos de página mais lentos e frustração.
No lado positivo dessa moeda, as estruturas podem não ir longe o

suficiente, fazendo com que os desenvolvedores precisem criar uma
quantidade substancial de código personalizado para atingir os objetivos de seus
projetos. Em algum momento, é ultrapassado um limite em que os benefícios
iniciais da utilização de uma estrutura – nomeadamente o desenvolvimento – são
compensados pelo tempo gasto na modificação, extensão e correção da estrutura.
E depois há o problema com a nomenclatura. Usar uma estrutura significa

aderir à estrutura, nomenclatura e convenções de estilo de outra pessoa. É claro
que é importante estabelecer um léxico de front-end útil, mas o que faz sentido
para uma organização pode não ser o que sai da caixa de uma estrutura. Eu, por
exemplo, recusaria a ideia de usar o componente padrão do Bootstrap para
uma área de conteúdo em destaque que eles chamam de “jumbotron”. Como as
convenções de nomenclatura de uma estrutura combinam com uma base de código
e fluxo de trabalho existentes deve ser discutida adequadamente antes de embarcar
no trem da estrutura.
22 PROJETO ATÔMICO
Agora que colocamos as estruturas à prova, é importante dar um

passo atrás e reconhecer que conceitualmente essas estruturas estão muito
corretas. É uma excelente ideia trabalhar com um kit de ferramentas de
design que promova consistência e acelere o tempo de desenvolvimento.
Ao discutir o redesenho da página inicial da Microsoft pela loja virtual
Paravel, com sede em Austin, o desenvolvedor Dave Rupert enfatizou a
importância de criar e entregar um sistema de design para seu cliente. Dave
articulou maravilhosamente que não se trata necessariamente de usar
Bootstrap para cada cliente, mas sim de criar “pequenos Bootstraps
para cada cliente”.
Os resultados responsivos devem se parecer muito com sistemas totalmente

funcionais no estilo Twitter Bootstrap, personalizados para as necessidades
de seus clientes. Esses exemplos de código vivo são guias de estilo
autodocumentados que se estendem para acomodar as necessidades do
cliente, bem como as necessidades da web em constante evolução para vários dispositivos.
-Dave Rupert
Não se trata apenas de usar um sistema de design, trata-se de criar

seu sistema.
Os sistemas de design salvam o dia
Então, como são os sistemas de design robustos? Que forma eles

assumem? Como você os cria, mantém e aplica?
Os pilares de bons sistemas de design são guias de estilo, que documentam

e organizam materiais de design, ao mesmo tempo que fornecem diretrizes, uso
e proteções.
Na verdade, existem muitos guias de estilo, incluindo documentação para

identidade de marca, escrita, voz e tom, código, linguagem de design e
padrões de interface de usuário. Este livro não detalha todas as categorias de
guias de estilo, mas é importante dar uma olhada em cada uma para
entender melhor como cada guia de estilo influencia os outros e como
os guias de estilo para a web se encaixam em um ecossistema maior.

Identidade da marca
As diretrizes de identidade da marca definem os ativos e materiais que tornam

uma empresa única. Logotipos, tipografia, paletas de cores, mensagens
(como declarações de missão e slogans), materiais (como cartões de
visita e modelos de PowerPoint) e muito mais são agregados e descritos nas
diretrizes de identidade da marca.
Guia de estilo de marca da West Virginia University.
É essencial que uma marca se apresente de forma coesa em um número

cada vez maior de mídias, canais e pontos de contato.
Como é que todos dentro de uma organização podem falar a uma só voz e
sentir-se parte de uma entidade singular? Como terceiros sabem quais
cores Pantone utilizar e como utilizar corretamente o logotipo da marca?
As diretrizes de identidade da marca fornecem respostas a essas questões
fundamentais em um hub centralizado.
Historicamente, as diretrizes de identidade da marca estavam contidas

em livros de capa dura (lembra daquelas coisas com as páginas?), mas, como
acontece com tudo o mais, os guias de estilo da marca estão chegando online.
24 PROJETO ATÔMICO
Linguagem de design
Embora as diretrizes de identidade da marca sejam bastante táteis, as diretrizes da

linguagem de design são um pouco mais difíceis de definir. Os guias de estilo da linguagem
de design articulam uma direção geral de design, filosofia e abordagem para projetos
ou produtos específicos.
Para se apresentar de forma coesa em uma gama crescente de produtos e

mídias, o Google desenvolveu uma linguagem de design chamada material design.
O guia de estilo de design de materiais define sua filosofia de design
abrangente, objetivos e princípios gerais, ao mesmo tempo que fornece aplicações
específicas da linguagem de design de materiais.
A linguagem de design de materiais do Google.
Os guias de estilo da linguagem de design podem (e geralmente o fazem)

incorporar aspectos de outras categorias de guias de estilo para tornar os conceitos de
alto nível um pouco mais tangíveis.
As diretrizes da linguagem de design não são imutáveis como as diretrizes da marca. Por
exemplo, um dia o Google provavelmente desenvolverá uma nova linguagem de
design para substituir o material design, portanto, embora a marca geral do Google
permaneça intacta, o vocabulário de design em torno de seus produtos mudará.

Voz e tom
As pessoas interagem com marcas em uma grande variedade de canais e mídias. Além
da mídia digital que discutimos até agora, as marcas também operam em canais
impressos, varejistas, outdoor, rádio, TV e outros. Quando uma marca precisa se
comunicar através de tantos pontos de contato variados, falar de maneira unificada e
consistente torna-se fundamental para o sucesso da marca.
A voz de uma marca permanece a mesma no dia a dia, mas seu

tom precisa mudar o tempo todo, dependendo da situação e dos
sentimentos do leitor.
-Kate Kiefer Lee
A voz é um aspecto elementar da identidade de uma marca, portanto, normalmente as diretrizes

de identidade da marca incluem alguma referência à voz da marca.
No entanto, essas diretrizes geralmente não têm muitas nuances, e é por isso que as
diretrizes de voz e tom são tão importantes.
Diretrizes de voz e tom do MailChimp
As diretrizes de voz e tom entram em ação ao articular como a voz e o tom da empresa
devem mudar em uma variedade de cenários. Diretrizes brilhantes de voz e tom do
MailChimp definir
26 PROJETO ATÔMICO
como o tom da marca muda entre os tipos de conteúdo, de modo que, quando o
cartão de crédito de um usuário é recusado, os escritores saibam que devem
abandonar seu tom de voz geralmente atrevido e brincalhão e adotar um tom mais
sério.
Escrita
A ascensão da web e dos sites gerenciados por conteúdo torna mais fácil do
que nunca para muitas pessoas dentro de uma organização publicar
conteúdo. Isto, claro, pode ser uma faca de dois gumes, pois manter um estilo de
escrita consistente para uma organização com muitas vozes pode ser um
desafio. Os guias de estilo de redação fornecem a cada autor algumas diretrizes e
proteções para contribuir com conteúdo.
Os guias de estilo de escrita podem ser extremamente granulares, definindo detalhes

sobre pontuação e gramática, mas nem sempre precisam ser tão detalhados. Guia
de estilo de redação da Dalhousie University fornece uma lista concisa de princípios e
práticas recomendadas que os colaboradores de conteúdo devem seguir.
O guia de estilo de redação do The Economist.

Guias de estilo de código
É essencial que as equipes escrevam códigos legíveis, escaláveis e de fácil manutenção.

Mas sem uma maneira de promover e reforçar a consistência do código, é fácil que as coisas
desmoronem e deixem cada desenvolvedor se defender sozinho.
Os guias de estilo de código fornecem convenções, padrões e exemplos de como as

equipes devem abordar seu código. Essas diretrizes e proteções ajudam a controlar a
loucura para que as equipes possam se concentrar na produção de um ótimo
trabalho em conjunto, em vez de refatorar um monte de códigos desleixados e
inconsistentes.
O guia de estilo de código do GitHub fornece práticas recomendadas para escrever HTML, CSS, JavaScript e
Ruby dentro de sua organização.
28 PROJETO ATÔMICO
Bibliotecas de padrões
E agora para o evento principal. Bibliotecas de padrões, também conhecidas como

guias de estilo front-end, bibliotecas de UI ou bibliotecas de componentes, estão
rapidamente se tornando a base do design de interface moderno.
Código para a biblioteca de padrões da América
O restante deste livro se concentrará em como abordar o design de interfaces de

maneira sistemática e detalhará como estabelecer e manter bibliotecas de padrões.
Benefícios do guia de estilo
Fazer com que as UIs funcionem em uma infinidade de tamanhos de tela,

dispositivos, navegadores e ambientes é uma tarefa difícil por si só. Mas uma vez
que você leva em consideração outros membros da equipe, clientes, partes interessadas
e peculiaridades organizacionais, as coisas começam a parecer totalmente intimidantes.
Os guias de estilo são ferramentas importantes que ajudam a prevenir o caos,

tanto do ponto de vista de design e desenvolvimento como também do ponto
de vista organizacional. Veja por que os guias de estilo são agora ferramentas
essenciais para o design e desenvolvimento web moderno.

Consistentemente incrível
Os guias de estilo da Web promovem consistência e coesão em toda a interface do

usuário. Essa consistência beneficia tanto as pessoas que criam essas interfaces
quanto seus usuários.
Visitei recentemente o site da minha seguradora de saúde para pagar minha conta.
No decorrer de cinco cliques, fui atingido por quatro designs de interface distintos,
alguns dos quais pareciam ter sido tocados pela última vez em 1999. Essa experiência
inconsistente colocou sobre mim, o usuário, o fardo de descobrir o que foi, onde e
como interpretar. elementos de interface díspares. Quando cheguei ao formulário de
pagamento, senti que não poderia confiar na empresa para processar meu pagamento
com sucesso e segurança.
Os guias de estilo ajudam a resolver essas inconsistências, incentivando a

reutilização de elementos da interface. Designers e desenvolvedores podem
consultar padrões existentes para garantir que o trabalho que estão produzindo seja
consistente com o que já foi estabelecido.
Mesmo terceiros responsáveis por combinar suas UIs com a aparência das UIs
internas de uma empresa podem fazer ótimo uso de um guia de estilo. Experiências
hospedadas externamente, como portais de pagamento ou sites localizados, podem
corresponder melhor à aparência da experiência principal aplicando os estilos
definidos no guia.
Tornar os guias de estilo centrais para o seu processo resulta em interfaces

de usuário mais unidas e confiáveis, o que ajuda os usuários a realizar suas
tarefas com mais rapidez e os capacita a dominar a interface.
Um vocabulário compartilhado
O que significa “barra de ferramentas do utilitário”? Todos entendem o que é um “herói

do controle deslizante de toque”?
À medida que aumenta o número de pessoas trabalhando em um projeto, torna-se muito

fácil ocorrer falhas de comunicação. Não é incomum que disciplinas diferentes
tenham nomes diferentes para o mesmo módulo e que indivíduos se desviem e inventem
suas próprias convenções de nomenclatura. Para que ocorra uma verdadeira
colaboração, é essencial que as equipes falem uma linguagem comum. Os guias de
estilo existem para ajudar a estabelecer esse vocabulário compartilhado.
30 PROJETO ATÔMICO
Dar nomes a padrões como 'Blocks Three-Up' no guia de estilo da Starbucks ajuda os membros da
equipe a falar a mesma língua.
Os guias de estilo estabelecem um vocabulário consistente e compartilhado

entre todos os envolvidos em um projeto, incentivando a colaboração entre
disciplinas e reduzindo falhas de comunicação.
Educação
Em seu livro Front-End Style Guides, Anna Debenham explica habilmente as muitas
vantagens de criar guias de estilo, incluindo um dos benefícios mais importantes: a
educação.
A educação é tão importante quanto a documentação. Um guia de estilo

pode mostrar aos clientes que os sites são sistemas e não coleções de
páginas.
- Anna Debenham
Os guias de estilo demonstram aos clientes, partes interessadas e outras

disciplinas que há muito trabalho realmente cuidadoso no design e
desenvolvimento de um site, além de apenas “Ei, vamos fazer um novo site”. Uma
biblioteca de padrões comunica a linguagem de design de uma forma
muito tangível, o que ajuda as partes interessadas a compreender que
um sistema subjacente está determinando a interface final.
Os guias de estilo podem ajudar a aliviar o que chamo de síndrome do snowfake

especial, em que certos departamentos de uma organização pensam que
têm problemas únicos e, portanto, exigem soluções únicas.
Ao expor o sistema de design na forma de um guia de estilo, esses
snowfakes especiais podem apreciar melhor a consistência e entender por que
suas solicitações de designs personalizados recebem resistência.

Um fluxo de trabalho empático
A educação não é importante apenas para clientes e partes interessadas. Um bom guia
de estilo ajuda a informar designers e desenvolvedores sobre as ferramentas que
possuem em sua caixa de ferramentas e fornece regras e práticas recomendadas sobre
como usá-las corretamente.
Ao fazer do guia de estilo a base do seu fluxo de trabalho (que detalharemos no capítulo
4), designers e desenvolvedores são forçados a pensar sobre como suas decisões
afetam o sistema de design mais amplo. Torna-se mais difícil ser desonesto e
mais fácil pensar no bem maior.
E é exatamente aqui que você deseja que os membros da equipe estejam.
Um guia de estilo fornece um local para cada disciplina contribuir com suas respectivas
considerações e preocupações com os padrões. Ao reunir todas essas considerações
sob o mesmo teto, o guia de estilo se torna um centro para todos os envolvidos no
projeto, o que ajuda cada disciplina a compreender melhor o sistema de design de muitas
perspectivas.
Testando, testando, 1-2-3
A página inicial está quebrada, você diz? Bem, o que exatamente está quebrando isso?
A capacidade de separar uma interface em seus componentes torna o teste muito

mais fácil. Um guia de estilo permite visualizar padrões de interface isoladamente,
permitindo que os desenvolvedores se concentrem no que está causando erros,
inconsistências do navegador ou problemas de desempenho.
Velocidade
No início do capítulo, discutimos como o design e o desenvolvimento mais rápidos

é uma das principais razões pelas quais frameworks de UI como Bootstrap são tão
populares. Estamos sob pressão para lançar projetos o mais rápido que for humanamente
possível. Ao desenvolver seu próprio sistema de design, você pode obter as mesmas
recompensas de velocidade que os kits de ferramentas de UI prontos para uso.
É verdade que desenvolver um sistema de design de interface e criar uma biblioteca

de padrões personalizados inicialmente exige muito tempo, reflexão e
32 PROJETO ATÔMICO
esforço. Mas uma vez estabelecida a biblioteca de padrões, o design e o

desenvolvimento subsequentes tornam-se muito mais rápidos, o que tende a deixar
todos felizes.
Federico Holgado, desenvolvedor líder de UX da MailChimp, explicou como a

biblioteca de padrões do MailChimp consistia inicialmente em padrões criados a
partir das quatro telas principais de seu aplicativo. Mas assim que passaram para
outras áreas do site, perceberam que eram capazes de usar os padrões
existentes em vez de ter que gerar novos padrões a partir do zero a cada vez.
…Depois que fizemos isso, enquanto íamos implementando coisas em

outras páginas, começamos a perceber: cara, esse sistema vai realmente
funcionar aqui e esse sistema vai realmente funcionar aqui e aqui.
-Federico Holgado
Nele para o longo prazo
Não há dúvida de que os guias de estilo ajudam as equipes a realizar as tarefas de

maneira eficaz aqui e agora. Mas, assim como um bom vinho, os guias de estilo
aumentam de valor com o tempo. A beleza dos sistemas de design de
interface é que eles podem e devem ser modificados, ampliados e refinados
nos próximos anos.
Como mencionado anteriormente, a criação de uma biblioteca de padrões

personalizados requer muito trabalho inicial, mas esse trabalho árduo deve
fornecer uma base estrutural para futuras iterações e refinamentos. As lições
aprendidas com análises, testes de usuário, testes A/B e experiência devem ser
incorporadas ao guia de estilo, tornando-o um centro poderoso para a verdade, o
conhecimento e as melhores práticas.
Melhor ainda, mesmo que você realize uma grande reformulação, descobrirá
que muitos dos blocos de construção da interface estrutural permanecerão
os mesmos. Você ainda terá formulários, botões, cabeçalhos, outros
padrões comuns de interface, então não há necessidade de jogar o bebê fora junto
com a água do banho. Um guia de estilo fornece uma base sólida para todos os
trabalhos futuros, mesmo que esse trabalho futuro possa parecer totalmente
diferente.

Desafios do guia de estilo
A esta altura, os benefícios da criação de sistemas de design

devem estar bastante claros e, esperançosamente, visões de
ameixas açucaradas e belos guias de estilo estão dançando em sua cabeça.
Mas para alcançar o nirvana do guia de estilo, você deve primeiro superar os
muitos desafios traiçoeiros que acompanham o território.
A venda difícil
Para se beneficiarem dos guias de estilo, as organizações devem primeiro

apropriar-se do tempo e do orçamento necessários para que eles aconteçam.
Isso exige que as organizações superem a mentalidade de curto prazo
que muitas vezes se insinua na cultura empresarial.
Os benefícios de longo prazo que os guias de estilo oferecem são óbvios

para aqueles que já estão pensando no longo prazo. O desafio, portanto, é
convencer aqueles que estão presos a uma mentalidade de curto
prazo, trimestre a trimestre, de que estabelecer um sistema de design bem
pensado é um investimento inteligente no futuro.
Uma questao de tempo
A parte difícil é construir a máquina que constrói o produto.

-Dennis Crowley
Talvez o maior e mais inevitável desafio seja que a criação de guias de estilo
consome muito tempo. Não sei sobre você, mas não vou para o trabalho
todos os dias girando os polegares e me perguntando o que fazer com meu
tempo. Nunca conheci uma pessoa que não se sentisse pressionada para
começar a trabalhar, e essa pressão naturalmente leva ao foco no projeto
principal da web. Infelizmente, cronogramas agressivos e orçamentos finitos
prejudicam o esforço necessário para fazer com que os guias de estilo
aconteçam, mesmo quando as equipes estão comprometidas com a causa.
34 PROJETO ATÔMICO
Projetos Auxiliares
Bibliotecas de padrões são frequentemente tratadas como projetos auxiliares,

e não como partes componentes do produto final. Ao tratar as bibliotecas de
padrões como algo separado do projeto principal, elas tendem a cair na categoria
de bom ter e se tornar as primeiras a serem cortadas quando as coisas ficam
difíceis.
Esse enigma do projeto auxiliar me lembra os sentimentos que ouço com frequência
sobre a inclusão da acessibilidade nos projetos. Eles dizem: “Oh, gostaríamos
de ter tempo e orçamento para acessibilidade, mas…” A noção de que
acessibilidade (e outros princípios como desempenho e capacidade de
resposta) é um item de linha extra caro é uma falácia. Bibliotecas de padrões,
como acessibilidade, são boas ideias para incluir em seu fluxo de
trabalho, independentemente de o plano do projeto explicitamente exigir isso ou não.
Manutenção e governança
Mesmo que tempo e dinheiro sejam alocados para estabelecer guias de estilo, essas
ferramentas valiosas muitas vezes morrem se não receberem o foco necessário
para atingir seu verdadeiro potencial.
Uma estratégia de manutenção e governança é fundamental para o sucesso

dos guias de estilo. Os guias de estilo serão jogados no lixo (ao lado de
todos aqueles PSDs e wireframes) e abandonados sem uma estratégia
adequada para quem irá gerenciá-los, mantê-los e aplicá-los.
A manutenção do guia de estilo é um tópico extremamente importante e merece

ser abordado em detalhes, por isso vamos nos aprofundar em como criar guias de
estilo sustentáveis no capítulo 5.
Confusão do público
Os guias de estilo podem ser mal interpretados como ferramentas

úteis apenas para designers ou desenvolvedores, o que leva a uma falta
de visibilidade que limita imediatamente a sua eficácia. Em vez de servir
como um ponto de encontro para todos na organização, um guia de estilo pode
se tornar um segredo mais bem guardado, guardado por uma disciplina. Me
considere ingênuo, mas não acho que isso ajude a promover uma cultura de colaboração.
Sem pensar em públicos mais amplos, os guias de estilo podem parecer

demasiado vagos ou demasiado técnicos, o que pode intimidar outras
disciplinas e levá-las a acreditar que estes recursos não são para elas.

Estrutura do guia de estilo
Para que os guias de estilo sejam recursos úteis para todos em uma
organização, eles devem transmitir claramente o que são e por que são importantes.
Os guias de estilo devem ser atraentes, convidativos, visíveis, claros e fáceis de
usar. Como mencionado acima, eles devem estar cientes de que um grande número
de públicos os assistirá, portanto, devem procurar ser acolhedores e úteis para o
maior número de pessoas possível.
A página inicial do guia de estilo do Yelp apresenta um design bonito e um importante texto de introdução
explicando o propósito e o público do guia.
Falta de contexto
O contexto é a chave para a compreensão de um sistema de design. Infelizmente,

a maioria das bibliotecas de padrões disponíveis não fornece nenhuma dica sobre
quando, como e onde seus componentes são usados. Sem fornecer contexto,
designers e desenvolvedores não sabem o quão global é um padrão específico e, como
resultado, não saberiam quais páginas de seu aplicativo precisariam ser revisitadas,
submetidas a controle de qualidade e testadas se alterações fossem feitas.
36 PROJETO ATÔMICO
'Bloco de destaque' parece útil, mas onde esse padrão está sendo usado?
Falta de uma metodologia clara
Por mais que eu adore as bibliotecas de padrões que existem, Não posso deixar
de notar falta de estrutura em muitos deles. Não me interpretem mal, acho
absolutamente fantástico que as equipes estejam pensando sistematicamente e
documentando seus padrões de UI. Mas muitas vezes sinto que muitas bibliotecas
de padrões são pouco mais do que sprays de módulos dispostos de maneira
livre. Acho que há espaço para melhorias.
Em busca de uma metodologia de design de interface
Para criarmos experiências para esse cenário eclético da web, precisamos

evoluir além da metáfora da página que nos acompanha desde o nascimento da
web. Felizmente, as organizações estão a adoptar a modularidade em todos
os aspectos do processo de criação web, o que está a conduzir a um trabalho mais
inteligente e a sistemas mais sustentáveis.
À medida que o número de dispositivos, navegadores e ambientes continua a aumentar a um ritmo

impressionante, a necessidade de criar sistemas de design de interface bem pensados e
deliberados está se tornando mais aparente do que nunca.
Entre no design atômico.

Capítulo 2
Design Atômico
Metodologia
Átomos, moléculas,
organismos, modelos e páginas
7 http://www.uie.com/articles/magic_escalator/
8 http://en.wikipedia.org/wiki/Scrum_%28software_development%29
38 PROJETO ATÔMICO
Minha busca por uma metodologia para criar sistemas de design de interface
me levou a buscar inspiração em outros campos e indústrias. Dado este mundo
surpreendentemente complexo que criámos, parecia natural que outros campos
tivessem abordado problemas semelhantes com os quais poderíamos aprender e
nos apropriar. Acontece que muitos outros campos, como o industrial
design e arquitetura desenvolveram sistemas modulares inteligentes para fabricar
objetos imensamente complexos, como aviões, navios e arranha-céus.
Mas minhas explorações originais continuaram voltando ao mundo natural, o que

desencadeou lembranças de estar sentado em uma mesa frágil no laboratório
de química da minha escola.
Seguindo dicas da química

Minha aula de química no ensino médio foi ministrada por um veterano do Vietnã,
com um bigode extraordinariamente impressionante. A aula do Sr. Rae tinha a
reputação de ser uma das mais difíceis da escola, em grande parte por causa de uma
tarefa que exigia que os alunos equilibrassem centenas e centenas de equações
químicas contidas em uma planilha enorme.
Se você é como eu, pode precisar de uma atualização para lembrar como é uma
equação química, então aqui está:
Um exemplo de equação química mostrando átomos de hidrogênio e oxigênio se combinando para

formar uma molécula de água.
CAPÍTULO 2 / METODOLOGIA DE PROJETO ATÔMICO 39

As reações químicas são representadas por equações químicas, que geralmente

mostram como os elementos atômicos se combinam para formar moléculas.
No exemplo acima, vemos como o hidrogênio e o oxigênio se combinam para formar
moléculas de água.
No mundo natural, os elementos atômicos se combinam para formar

moléculas. Essas moléculas podem se combinar ainda mais para formar
organismos relativamente complexos. Para expor um pouco mais:
ÿ Os átomos são os blocos básicos de construção de toda a matéria. Cada elemento

químico tem propriedades distintas e não podem ser decompostos sem perder o
significado. (Sim, é verdade que os átomos são compostos de pedaços
ainda menores, como prótons, elétrons e nêutrons, mas os átomos são a menor
unidade funcional .)
ÿ Moléculas são grupos de dois ou mais átomos mantidos juntos por

ligações químicas. Essas combinações de átomos assumem propriedades únicas
e tornam-se mais tangíveis e operacionais do que os átomos.
ÿ Organismos são conjuntos de moléculas que funcionam juntas como uma

unidade. Essas estruturas relativamente complexas podem variar
desde organismos unicelulares até organismos incrivelmente sofisticados
como os seres humanos.
É claro que estou simplificando a composição incrivelmente rica do universo, mas a essência
básica permanece: os átomos se combinam para formar moléculas, que posteriormente se
combinam para formar organismos. Esta teoria atômica significa que toda a matéria do universo
conhecido pode ser dividida em um conjunto finito de elementos atômicos:
A tabela periódica dos elementos químicos.
40 PROJETO ATÔMICO
Aparentemente, a estratégia do Sr. Rae de fazer com que os alunos equilibrassem

toneladas de equações químicas funcionou, porque estou voltando a isso todos
esses anos depois em busca de inspiração sobre como abordar o design de
interface.
A metodologia de design atômico
A esta altura você deve estar se perguntando por que estamos falando sobre
teoria atômica, e talvez esteja até com um pouco de raiva de mim por forçá-lo a
reviver memórias das aulas de química do ensino médio. Mas isso vai levar a
algum lugar, eu prometo.
Discutimos anteriormente como toda a matéria do universo pode ser dividida em

um conjunto finito de elementos atômicos. Acontece que nossas interfaces
podem ser divididas em um conjunto finito de elementos semelhante.
Tabela Periódica de Elementos HTML de Josh Duck articula lindamente como todos
os nossos sites, aplicativos, intranets, hoobadyboops e tudo o mais são
compostos dos mesmos elementos HTML.
A tabela periódica de elementos HTML de Josh Duck.

Como estamos começando com um conjunto finito de blocos de construção,

podemos aplicar o mesmo processo que acontece no mundo natural para projetar e
desenvolver nossas interfaces de usuário.
Entre no design atômico.
O design atômico é uma metodologia composta por cinco estágios distintos

trabalhando juntos para criar sistemas de design de interface de maneira
mais deliberada e hierárquica. Os cinco estágios do design atômico são:
1. Átomos
2. Moléculas
3. Organismos
4. Modelos
5. Páginas
O design atômico consiste em átomos, moléculas, organismos, modelos e páginas trabalhando juntos simultaneamente
para criar sistemas de design de interface eficazes.
O design atômico não é um processo linear, mas sim um modelo mental para
nos ajudar a pensar em nossas interfaces de usuário como um todo coeso e uma
coleção de partes ao mesmo tempo. Cada um dos cinco estágios desempenha um
papel fundamental na hierarquia de nossos sistemas de design de interface. Vamos
mergulhar em cada estágio com um pouco mais de detalhes.
42 PROJETO ATÔMICO
Átomos
Se os átomos são os blocos de construção básicos da matéria, então os

átomos de nossas interfaces servem como os blocos de construção
fundamentais que compõem todas as nossas interfaces de usuário. Esses
átomos incluem elementos HTML básicos como rótulos de formulários, entradas,
botões e outros que não podem ser decompostos sem deixar de ser funcionais.
Os átomos incluem tags HTML básicas,

como entradas, rótulos e botões.
Cada átomo no mundo natural tem suas próprias propriedades únicas.

Um átomo de hidrogênio contém um elétron, enquanto um átomo de hélio
contém dois. Estas propriedades químicas intrínsecas têm efeitos profundos
na sua aplicação (por exemplo, a explosão de Hindenburg foi tão catastrófica
porque o dirigível estava cheio de gás hidrogénio extremamente famoso em vez
de gás hélio inerte). No mesmo
42 https://developer.mozilla.org/en-US/docs/Web/HTML/Element

Dessa forma, cada átomo da interface tem suas próprias propriedades exclusivas,
como as dimensões de uma imagem principal ou o tamanho da fonte de um título
primário. Essas propriedades inatas influenciam como cada átomo deve ser aplicado
ao sistema mais amplo de interface do usuário.
No contexto de uma biblioteca de padrões, os átomos demonstram todos os seus estilos

básicos rapidamente, o que pode ser uma referência útil para consultar conforme você
desenvolve e mantém seu sistema de design. Mas, como os átomos do mundo
natural, os átomos de interface não existem no vácuo e só ganham vida com a aplicação.
Moléculas
Na química, as moléculas são grupos de átomos ligados entre si que assumem novas
propriedades distintas. Por exemplo, as moléculas de água e as moléculas de peróxido
de hidrogénio têm as suas próprias propriedades únicas e comportam-se de forma
bastante diferente, embora sejam constituídas pelos mesmos elementos atómicos
(hidrogénio e oxigénio).
Nas interfaces, as moléculas são grupos relativamente simples de

elementos de UI funcionando juntos como uma unidade. Por exemplo, um
rótulo de formulário, uma entrada de pesquisa e um botão podem se unir para criar
uma molécula de formulário de pesquisa.
44 PROJETO ATÔMICO
Uma molécula de formulário de pesquisa é composta por um átomo de rótulo, um
átomo de entrada e um átomo de botão.
Quando combinados, esses átomos abstratos de repente têm um propósito. O rótulo

átomo agora define o átomo de entrada. Clicar no botão átomo agora envia o
formulário. O resultado é um componente simples, portátil e reutilizável que pode
ser colocado em qualquer lugar onde a funcionalidade de pesquisa for necessária.
Agora, montar elementos em grupos funcionais simples é algo que sempre

fizemos para construir interfaces de usuário. Mas dedicar uma etapa na
metodologia de projeto atômico a esses componentes relativamente simples
nos proporciona alguns insights importantes.
A criação de componentes simples ajuda os designers e desenvolvedores de UI

a aderir ao princípio de responsabilidade única, um antigo preceito da ciência da
computação que incentiva a mentalidade de “faça uma coisa e faça bem”.
Sobrecarregar um único padrão com muita complexidade torna o software
complicado. Portanto, a criação de moléculas de UI simples facilita os testes,
incentiva a reutilização e promove a consistência em toda a interface.
Agora temos componentes simples, funcionais e reutilizáveis que podemos colocar

num contexto mais amplo. Entre nos organismos!

Organismos
Organismos são componentes de IU relativamente complexos compostos por grupos de moléculas
e/ou átomos e/ou outros organismos. Esses organismos formam seções distintas de uma interface.
Vamos revisitar nossa molécula de formulário de pesquisa. Muitas vezes, um formulário de pesquisa pode
ser encontrado no cabeçalho de muitas experiências na web, então vamos colocar essa molécula do formulário
de pesquisa no contexto de um organismo de cabeçalho.
Este organismo de cabeçalho é composto por uma molécula de formulário de pesquisa, um átomo de logotipo e uma
molécula de navegação primária.
O cabeçalho forma uma seção independente de uma interface, embora contenha vários pedaços menores de
interface com suas próprias propriedades e funcionalidades exclusivas.
Os organismos podem consistir em tipos de moléculas semelhantes ou diferentes. Um organismo de
cabeçalho pode consistir em elementos diferentes, como imagem de logotipo, lista de navegação primária e
formulário de pesquisa. Vemos esses tipos de organismos em quase todos os sites que visitamos.
46 PROJETO ATÔMICO
Organismos como cabeçalhos de sites consistem em moléculas menores, como navegação primária, formulários de
pesquisa, navegação utilitária e logotipos.
Embora alguns organismos possam consistir em diferentes tipos de

moléculas, outros organismos podem consistir na mesma molécula repetida
continuamente. Por exemplo, visite uma página de categoria de quase qualquer site
de comércio eletrônico e você verá uma lista de produtos exibidos em alguma forma
de grade.
A construção de moléculas em organismos mais elaborados fornece aos designers

e desenvolvedores um importante senso de contexto.
Os organismos demonstram esses componentes menores e mais simples em
ação e servem como padrões distintos que podem ser usados repetidas vezes.
O organismo da grade de produtos pode ser empregado em qualquer lugar em
que um grupo de produtos precise ser exibido, desde listagens de categorias até
resultados de pesquisa e produtos relacionados.
Agora que temos organismos definidos em nosso sistema de design, podemos

quebrar nossa analogia química e aplicar todos esses componentes a algo que
se assemelhe a uma página da web!

Um organismo de grade de produtos no site de comércio eletrônico da Gap consiste na mesma molécula de item de
produto repetida continuamente.
Modelos
48 PROJETO ATÔMICO
Agora, amigos, é hora de dizer adeus à nossa analogia com a química.

A linguagem dos átomos, moléculas e organismos traz consigo uma hierarquia
útil para construirmos deliberadamente os componentes dos nossos sistemas
de design. Mas, em última análise, devemos adotar uma linguagem que seja
mais apropriada para o nosso resultado final e que faça mais sentido para os
nossos clientes, chefes e colegas. Tentar levar longe demais a analogia da
química pode confundir as partes interessadas e fazer com que pensem que você
é um pouco maluco. Confie em mim.
Os modelos são objetos no nível da página que colocam componentes

em um layout e articulam a estrutura de conteúdo subjacente do design.
Para desenvolver nosso exemplo anterior, podemos pegar o organismo do
cabeçalho e aplicá-lo a um modelo de página inicial.
O modelo da página inicial consiste em organismos e moléculas aplicados a um layout.
Este modelo de página inicial exibe todos os componentes

necessários da página funcionando juntos, o que fornece contexto para
essas moléculas e organismos relativamente abstratos. Ao criar um sistema
de design eficaz, é fundamental demonstrar como os componentes se
parecem e funcionam juntos no contexto de um layout para

provar que as partes resultam em um todo que funciona bem. Discutiremos isso mais em
breve.
Outra característica importante dos modelos é que eles se concentram na

estrutura de conteúdo subjacente da página, e não no conteúdo final da página. Os
sistemas de design devem levar em conta a natureza dinâmica do conteúdo, por isso é
muito útil articular propriedades importantes de componentes, como tamanhos de
imagens e comprimentos de caracteres para títulos e passagens de texto.
Mark Boulton discute a importância de definir a estrutura de conteúdo subjacente de

uma página:
Você pode criar boas experiências sem conhecer o conteúdo.

O que você não pode é criar boas experiências sem conhecer a
sua estrutura de conteúdo. De que é feito o seu conteúdo, não
qual é o seu conteúdo.
-Mark Boulton
Ao definir o esqueleto de uma página, somos capazes de criar um sistema que pode dar
conta de uma variedade de conteúdo dinâmico, ao mesmo tempo em que fornece as
proteções necessárias para os tipos de conteúdo que preenchem determinados
padrões de design. Por exemplo, o modelo de página inicial da Time Inc. mostra alguns
componentes principais em ação, ao mesmo tempo que demonstra a estrutura do
conteúdo em relação ao tamanho da imagem e ao comprimento dos caracteres:
50 PROJETO ATÔMICO
O modelo de página inicial da Time Inc. demonstra a estrutura subjacente do conteúdo.
Agora que estabelecemos o sistema esquelético de nossas páginas, vamos colocar um pouco de
carne nos ossos!

Páginas
As páginas são instâncias específicas de modelos que mostram a aparência

de uma IU com conteúdo representativo real implementado. Com base em
nosso exemplo anterior, podemos pegar o modelo de página inicial e inserir texto,
imagens e mídia representativos no modelo para mostrar o conteúdo real em ação.
O estágio da página é o estágio mais concreto do design atômico e é importante por

alguns motivos bastante óbvios. Afinal, é isso que os usuários verão e interagirão
quando visitarem sua experiência.
É isso que suas partes interessadas assinarão. E é aqui que você vê todos esses
componentes se unindo para formar uma interface de usuário bonita e funcional.
Excitante!
52 PROJETO ATÔMICO
O estágio da página substitui o conteúdo do espaço reservado por conteúdo representativo real para dar vida ao
sistema de design.
Além de demonstrar a interface final como seus usuários a verão, as páginas são essenciais
para testar a eficácia do sistema de design subjacente. É no estágio da página que
podemos observar como todos esses padrões se comportam quando o conteúdo real é aplicado
ao sistema de design. Tudo parece ótimo e funciona como deveria? Se a resposta for não,
podemos voltar atrás e modificar nossas moléculas, organismos e modelos para melhor
atender às necessidades de nosso conteúdo.
Quando colocamos conteúdo representativo real no modelo de página

inicial da Time Inc., podemos ver como todos esses padrões de design
subjacentes se comportam.

Na fase da página, podemos ver a aparência da página inicial da Time Inc. com conteúdo representativo real
implementado. Com o conteúdo real implementado, podemos ver se os componentes da UI que compõem a
página atendem adequadamente ao conteúdo que está sendo colocado nelas.
Devemos criar sistemas que estabeleçam padrões de design reutilizáveis e também reflitam
com precisão a realidade do conteúdo que colocamos dentro desses padrões.
54 PROJETO ATÔMICO
As páginas também fornecem um local para articular variações em modelos, o

que é crucial para estabelecer sistemas de design robustos e confiáveis.
Aqui estão apenas alguns exemplos de variações de modelo:
ÿ Um usuário tem um item no carrinho de compras e outro usuário tem

dez itens em seu carrinho.
ÿ O painel de um aplicativo web normalmente mostra atividades recentes, mas essa

seção é suprimida para usuários iniciantes.
ÿ O título de um artigo pode ter 40 caracteres, enquanto o título de outro artigo pode ter
340 caracteres.
ÿ Os usuários com privilégios administrativos poderão ver informações adicionais

botões e opções em seu painel em comparação com usuários que não são
administradores.
Em todos esses exemplos, os modelos subjacentes são os mesmos, mas as interfaces

do usuário mudam para refletir a natureza dinâmica do conteúdo. Essas variações
influenciam diretamente a forma como as moléculas, organismos e modelos
subjacentes são construídos. Portanto, criar páginas que levem em conta essas
variações nos ajuda a criar sistemas de design mais resilientes.
Então isso é design atômico! Esses cinco estágios distintos trabalham juntos
simultaneamente para produzir sistemas de design de interface de usuário eficazes.
Para resumir o design atômico em poucas palavras:
ÿ Átomos são elementos de UI que não podem ser mais decompostos e servem como
blocos de construção elementares de uma interface.
ÿ Moléculas são coleções de átomos que formam moléculas relativamente simples

Componentes da IU.
ÿ Organismos são componentes relativamente complexos que formam

seções discretas de uma interface.
ÿ Os modelos colocam componentes em um layout e demonstram

a estrutura de conteúdo subjacente do design.
ÿ As páginas aplicam conteúdo real aos modelos e articulam variações para demonstrar
a UI final e testar a resiliência do sistema de design.

Vantagens do design atômico

Então, por que passar por todo esse rigamarole? Para que serve o design atômico?
Essas são perguntas válidas, considerando que já há muito tempo que
construímos interfaces de usuário sem ter uma metodologia explícita de cinco
estágios em vigor. Mas o design atômico nos fornece alguns insights importantes
que nos ajudam a criar sistemas de design de UI mais eficazes e deliberados.
A parte e o todo
Uma das maiores vantagens que o design atômico oferece é a capacidade de
alternar rapidamente entre o abstrato e o concreto. Podemos simultaneamente ver
nossas interfaces divididas em seus elementos atômicos e também ver
como esses elementos se combinam para formar nossas experiências finais.
O design atômico permite que os designers transitem entre o abstrato e o concreto.
Em seu livro The Shape of Design, Frank Chimero articula lindamente o poder que
essa travessia oferece:
O pintor, quando distante do cavalete, pode avaliar e analisar o

conjunto da obra a partir desta posição. Ele examina e escuta, escolhe
o próximo traço a ser feito e depois se aproxima da tela para fazê-lo.
Então, ele recua novamente para ver o que fez em relação ao todo. É
uma dança de troca de contextos, um ritmo acelerado pelo chão
do estúdio que produz um ciclo de feedback estreito entre a criação e
a avaliação da marca.
-Frank Chimero
56 PROJETO ATÔMICO
O design atômico nos permite dançar entre contextos como o pintor Frank descreve
tão eloquentemente. Os átomos, moléculas e organismos que compõem as nossas
interfaces não vivem no vácuo. E os modelos e páginas de nossas interfaces são de
fato compostos de partes menores. As partes dos nossos projetos influenciam
o todo, e o todo influencia as partes. Os dois estão interligados e o design atômico
abraça esse fato.
Quando designers e desenvolvedores criam um componente específico, somos como

o pintor na tela criando traços detalhados. Quando visualizamos esses componentes
no contexto de um layout com conteúdo representativo real, somos como o pintor,
vários metros atrás da tela, avaliando como seus traços detalhados afetam toda a
composição. É necessário focar em um componente específico para garantir que ele
seja funcional, utilizável e bonito. Mas também é necessário garantir que o
componente seja funcional, utilizável e bonito no contexto da UI final.
O design atômico nos fornece uma estrutura para navegar entre as partes e o todo
de nossas UIs, por isso é crucial reiterar que o design atômico não é um processo
linear. Seria tolice projetar botões e outros elementos isoladamente e depois cruzar
os dedos e esperar que tudo se junte para formar um todo coeso. Portanto,
não interprete os cinco estágios do projeto atômico como “Etapa 1: átomos; Etapa
2: moléculas; Etapa 3: organismos; Etapa 4: modelos; Etapa 5: páginas.” Em vez
disso, pense nos estágios do design atômico como um modelo mental que
nos permite criar simultaneamente UIs finais e seus sistemas de design
subjacentes.
Separação limpa entre estrutura e conteúdo
Discutir design e conteúdo é um pouco como discutir o ovo e a galinha. Mark Boulton
explica:
O conteúdo precisa ser estruturado e a estruturação altera o seu

conteúdo, o design altera o conteúdo. Não é 'conteúdo depois design'
ou 'conteúdo ou design'. É 'conteúdo e design'.
-Mark Boulton

Um sistema de design bem elaborado atende ao conteúdo que reside

nele, e o conteúdo bem elaborado está ciente de como é apresentado
no contexto de uma IU. Os padrões de interface que estabelecemos devem
refletir com precisão a natureza do texto, das imagens e de outros
conteúdos que residem dentro deles. Da mesma forma, nosso conteúdo
deve estar atento à forma como será apresentado. A estreita relação entre
conteúdo e design exige que consideremos ambos ao construirmos nossas UIs.
O design atômico nos dá uma linguagem para discutir a estrutura de

nossos padrões de UI e também o conteúdo que está dentro desses padrões.
Embora exista uma separação clara entre o esqueleto da estrutura do
conteúdo (modelos) e o conteúdo final (páginas), o design atômico
reconhece que os dois influenciam um ao outro. Por exemplo, veja o
seguinte exemplo:
À esquerda vemos o esqueleto de conteúdo da UI, que consiste na mesma molécula de bloco de
pessoa repetida repetidas vezes. À direita, vemos o que acontece quando preenchemos cada
instância da molécula do bloco pessoal com conteúdo representativo. A visualização do esqueleto do
conteúdo e do conteúdo final representativo nos permite criar padrões que refletem com precisão o
conteúdo que reside dentro deles. Se o nome de uma pessoa fosse dividido em cinco linhas dentro
do padrão, precisaríamos abordar esse comportamento quebrado em um nível mais atômico.
58 PROJETO ATÔMICO
O conteúdo que colocamos em nossas UIs no estágio da página influenciará as

características e os parâmetros dos padrões de design subjacentes.
O que há em um nome?
Ao longo deste livro mencionei que o design e o desenvolvimento modular

não são novidade. Então, por que estamos introduzindo termos como átomos,
moléculas e organismos quando podemos apenas nos ater a termos estabelecidos
como módulos, componentes, elementos, seções e regiões?
Desde que falo sobre design atômico, tenho ouvido pessoas oferecendo nomes
alternativos para os estágios da metodologia. A Pessoa Um sugeriria: “Por
que não apenas nomeá-los como elementos, módulos e componentes?”
enquanto a Pessoa Dois sugeriria: “Por que não apenas nomeá-los como base,
componentes e módulos?” O problema com termos como componentes e
módulos é que um senso de hierarquia não pode ser deduzido apenas dos
nomes. Átomos, moléculas e organismos implicam uma hierarquia que
qualquer pessoa com um conhecimento básico de química pode entender.
Dito isto, nomear as coisas é difícil e imperfeito. Os nomes que escolhi para os
estágios do design atômico funcionaram muito bem para mim e para as equipes
com quem trabalhei enquanto criamos sistemas de design de UI. Mas talvez
eles não funcionem para você e sua organização. Isso é mais do que OK. Aqui
está uma perspectiva da equipe de design da GE:
Ao mostrarmos aos nossos colegas nossos conceitos iniciais de

sistema de design que usavam a taxonomia do Atomic Design, nos
deparamos com alguns olhares confusos. […] A evidência era clara,
para que isto tivesse sucesso dentro da nossa organização tínhamos que
tornar a taxonomia mais acessível.
- Jef Crossman, GE Design
A taxonomia que a equipe encontrou foi “Princípios”, “Básico”,

“Componentes”, “Modelos”, “Recursos” e “Aplicativos”. Esses rótulos fazem
sentido para você? Não importa. Ao estabelecer uma taxonomia que fizesse
sentido para sua organização, todos puderam aderir aos princípios do design
atômico e realizar um trabalho eficaz em conjunto.

“Design atômico” como palavra da moda encapsula os conceitos de

design e desenvolvimento modular, o que se torna um atalho útil para
convencer as partes interessadas e conversar com colegas.
Mas o design atômico não é um dogma rígido. Em última análise,
qualquer taxonomia com a qual você escolher trabalhar deve ajudar você
e sua organização a se comunicarem de forma mais eficaz, a fim de criar
um sistema de design de UI incrível.
O design atômico é para interfaces de usuário
O design atômico é um conceito nascido da web. Afinal, seu humilde autor é

um web designer, e é principalmente por isso que este livro se concentra
principalmente em interfaces baseadas na web. Mas é importante entender
que o design atômico se aplica a todas as interfaces de usuário, não
apenas às baseadas na web.
Você pode aplicar a metodologia de design atômico à interface de usuário de

qualquer software: Microsoft Word, Keynote, Photoshop, caixa eletrônico do seu
banco, qualquer que seja. Para demonstrar, vamos aplicar o design atômico
ao aplicativo móvel nativo Instagram.
Design atômico aplicado ao aplicativo móvel nativo Instagram.
60 PROJETO ATÔMICO
Vamos percorrer esta interface atomizada do Instagram:
ÿ Átomos: esta tela da IU do Instagram consiste em um punhado

de ícones, alguns elementos de nível de texto e dois tipos de imagem: a
imagem primária e a imagem do avatar do usuário.
ÿ Moléculas: Vários ícones formam componentes utilitários simples

como a barra de navegação inferior e a barra de ações de fotos, onde os
usuários podem curtir ou comentar uma foto. Além disso, combinações
simples de texto e/ou imagens formam componentes relativamente simples.
ÿ Organismos: Aqui podemos ver o fotorganismo tomando forma,

que consiste nas informações do usuário, carimbo de data e hora, a foto em
si, ações em torno dessa foto e informações sobre a foto, incluindo
contagem e legenda. Este organismo se torna a pedra angular de toda a
experiência do Instagram, pois é empilhado repetidamente em um
fluxo interminável de fotos geradas por usuários.
ÿ Modelos: podemos ver nossos componentes reunidos no contexto de um

layout. Além disso, é aqui que vemos o esqueleto do conteúdo exposto
da experiência do Instagram, destacando o conteúdo dinâmico, como
identificador do usuário, avatar, foto, contagem de curtidas e legenda.
ÿ Páginas: E finalmente vemos o produto final, completo com imagens reais

conteúdo derramado nele, o que ajuda a garantir que o sistema de design
subjacente se una para formar uma interface de usuário bonita e funcional.
Mostro este exemplo não-web porque o design atômico tende a ser mal
interpretado como uma abordagem para tecnologias específicas da web,
como CSS e JavaScript. Deixe-me ser claro: o design atômico não tem
nada a ver com assuntos específicos da web, como CSS ou arquitetura
JavaScript. No capítulo 1 discutimos a tendência à modularidade em todos os
aspectos de design e desenvolvimento, o que inclui CSS e JavaScript. Essas
são tendências fantásticas em CSS e JavaScript, mas o design atômico
trata da criação de sistemas de design de interface de usuário,
independentemente da tecnologia usada para criá-los.

Design atômico na teoria e na prática

Este capítulo introduziu a metodologia de design atômico e
demonstrou como átomos, moléculas, organismos, modelos e páginas
trabalham juntos para criar sistemas de design de interface bem
pensados e deliberados. O design atômico nos permite ver nossas UIs
divididas em seus elementos atômicos e também nos permite analisar
simultaneamente como esses elementos se unem para formar nossas UIs
finais. Aprendemos sobre o vínculo estreito entre conteúdo e design e como
o design atômico nos permite criar sistemas de design adaptados ao
conteúdo que reside dentro deles. E, finalmente, aprendemos como a
linguagem do design atômico nos fornece um atalho útil para discutir
modularidade com nossos colegas e fornece um senso de hierarquia
muito necessário em nossos sistemas de design.
O design atômico é uma metodologia útil de design e desenvolvimento,

mas essencialmente é apenas um modelo mental para construir uma UI.
Agora você deve estar se perguntando como fazer o design atômico acontecer.
Bem, não tema, caro leitor, porque o restante do livro se concentra em
ferramentas e processos para tornar realidade seus sonhos de design atômico.
62 PROJETO ATÔMICO
Capítulo 3
Ferramentas
do comércio
Pattern Lab e as qualidades de

guias de estilo eficazes
No capítulo anterior, apresentei a metodologia de design atômico para

construir interfaces de usuário. Espero que você considere o design atômico um modelo
mental útil para a construção de sistemas de design de UI, mas agora é hora de descer
da torre de marfim e realmente colocar o design atômico em prática no mundo real.
A base do design e desenvolvimento baseado em padrões é a biblioteca de padrões, que

serve como um hub centralizado de todos os componentes de UI que compõem sua
interface de usuário. Conforme discutimos no capítulo 1, os benefícios das bibliotecas de
padrões são muitos:
ÿ Eles promovem consistência e coesão em toda a experiência.
ÿ Eles agilizam o fluxo de trabalho da sua equipe, economizando tempo e dinheiro.
ÿ Eles estabelecem um fluxo de trabalho mais colaborativo entre todos

disciplinas envolvidas em um projeto.
ÿ Eles estabelecem um vocabulário compartilhado entre todos em um

organização, incluindo fornecedores externos.
ÿ Eles fornecem documentação útil para ajudar a educar as partes

interessadas, colegas e até mesmo terceiros.
ÿ Eles facilitam a compatibilidade entre navegadores/dispositivos, desempenho e

testes de acessibilidade mais fáceis.
ÿ Eles servem como uma base favorável ao futuro para as equipes modificarem,
estender e melhorar ao longo do tempo.
Tudo isso parece maravilhoso, certo? Quase posso ouvir você dizendo: “Preciso
de toda essa biblioteca de padrões na minha vida”. Mas como fazemos com
que as bibliotecas de padrões aconteçam? Bem, você veio ao lugar certo, amigo,
porque o restante deste livro é dedicado exatamente a isso. Este capítulo
apresentará ferramentas úteis para a criação de bibliotecas de padrões, o próximo
capítulo discutirá como tornar os padrões a base de seu fluxo de trabalho de
design e desenvolvimento e o quinto capítulo abordará como fazer seu sistema de
design resistir ao teste do tempo.
Este capítulo falará sobre as qualidades de bibliotecas de padrões eficazes através

das lentes de uma ferramenta chamada Pattern Lab, um projeto de código aberto
mantido pelos desenvolvedores web Dave Olsen,
CAPÍTULO 3 / FERRAMENTAS DO COMÉRCIO 65

Brian Muenzenmeyer, e eu para executar sistemas de design atômico.

Embora eu discuta com entusiasmo o Pattern Lab e seus vários recursos,
quero enfatizar que o objetivo deste capítulo é cobrir as características de
bibliotecas de padrões bem construídas, e não vender nenhuma ferramenta
específica para você. Inferno, o Pattern Lab nem está à venda! Nenhuma
ferramenta será perfeita para cada configuração e cenário, mas lembre-se dos
seguintes princípios ao decidir quais ferramentas usar para criar suas bibliotecas
de padrões.
O que exatamente é Pattern Lab?
Antes de nos aprofundarmos nos detalhes de como o Pattern Lab funciona, é

importante reservar um tempo para explicar o que a ferramenta é e o que não é.
O Laboratório de Padrões é...
ÿ uma ferramenta geradora de sites estáticos para a construção de sistemas de design atômico.
ÿ uma ferramenta de documentação e anotação de padrões.
ÿ um kit inicial de padrões.
O Pattern Lab não é...
ÿ uma estrutura de UI como Bootstrap ou Foundation.
ÿ dependente do idioma, da biblioteca ou do estilo.
ÿ um substituto para um sistema de gerenciamento de conteúdo.
Vamos examinar esses pontos, começando com o termo site estático

gerador. As ferramentas geradoras de sites estáticos pegam alguns códigos-
fonte e ativos, compilam-nos e emitem HTML, CSS e JavaScript simples na
outra extremidade. O Pattern Lab pega o código-fonte – ou seja,
padrões – e compila esses padrões em uma interface de usuário front-end
funcional dentro de um shell de biblioteca de padrões.
Então, como é o Pattern Lab pronto para uso? Por favor, rufem os tambores.
66 PROJETO ATÔMICO
Um painel padrão do Pattern Lab. O que falta em beleza compensa em utilidade.
Não é um design muito inspirador, hein? Acredite ou não, esse design mínimo (pode-
se até dizer que falta dele) é deliberado. Para evitar a classificação incorreta como uma
estrutura de UI como o Bootstrap, o design é deliberadamente simplificado para
que ninguém tome por engano a UI de demonstração do Pattern Lab como estilos
sugeridos. O Pattern Lab não fornece nenhuma resposta sobre como projetar ou
arquitetar seu código front-end – você precisa fazer todo esse trabalho sozinho. A
aparência, as convenções de nomenclatura, a sintaxe, a estrutura, as bibliotecas e
os scripts que você escolhe usar para criar sua IU dependem inteiramente de você e
sua equipe. Caramba, você pode até usar estruturas de UI como Bootstrap no Pattern
Lab.
O Pattern Lab está lá apenas para ajudar a unir tudo.
Como um aparte técnico, o Pattern Lab usa PHP ou Node.js como o mecanismo que
une os padrões e gera a biblioteca de padrões. No entanto, você não precisa ser um
assistente de PHP ou um guru de Node.js para usar o Pattern Lab, assim como não
precisa saber como construir um motor de combustão interna para dirigir um carro.
Além disso, seu site final não precisa ser construído com PHP ou Node.js para usar a
ferramenta, já que a saída do Pattern Lab é HTML, CSS e JavaScript independente de
backend. Então, como qualquer decisão tecnológica, escolha uma biblioteca de padrões

ferramenta que se adapta à infraestrutura da sua organização e combina com a forma como sua
equipe trabalha em conjunto.
Se tudo isso soou como algo sem sentido para você, não se preocupe. Este capítulo se concentra
nos recursos abrangentes do Pattern Lab e nos princípios de bibliotecas de padrões eficazes, em
vez de ir muito longe na toca do coelho técnico. Se estiver interessado, você pode verificar a
documentação do Pattern Lab para mergulhar no âmago da questão.
Construindo sistemas de design atômico com Pattern Lab
Para entender o conceito central por trás do Pattern Lab, você precisa entender as bonecas
russas.
Bonecas russas. Crédito da imagem: S. Faric no Flickr
As bonecas Matryoshka (também conhecidas como bonecas russas) são bonecas ocas
de madeira lindamente esculpidas, de tamanho crescente, que são colocadas umas dentro das
outras. Os padrões no Pattern Lab funcionam de maneira semelhante: os padrões menores
(átomos) são incluídos dentro de padrões maiores (moléculas), que são incluídos em padrões
ainda maiores (organismos), que por sua vez são incluídos em padrões ainda maiores
(modelos).
68 PROJETO ATÔMICO
Construir UIs dessa maneira mantém as coisas SECAS, que é um princípio de

longa data da ciência da computação que significa “não se repita”. O que isso
significa é que você pode fazer uma alteração em um padrão, e qualquer lugar em
que esse padrão seja empregado será atualizado magicamente com essas alterações.
Essa abordagem de boneca russa acelera consideravelmente seu fluxo de
trabalho e certamente é melhor do que vasculhar centenas de documentos do Photoshop
para cada instância de um padrão, a fim de fazer uma alteração simples.
Para que isso aconteça, o Pattern Lab usa o recurso include do Moustache,
uma linguagem de modelagem sem lógica. Esta é a aparência de um bigode:
{{> miniatura do átomo }}
Este é o código do bigode, caso as chaves duplas ({{}}) que parecem pequenos
bigodes não o denunciem. O símbolo maior que (>) é a maneira do Moustache
dizer ao Pattern Lab para incluir um padrão de átomo chamado “miniatura”. O Pattern
Lab irá pesquisar em suas pastas de padrões para encontrar um átomo chamado
“miniatura”.
Esta é a aparência da estrutura de pastas de padrões do Pattern Lab.

Você pode nomear e categorizar essas pastas como desejar, inclusive
alterando os rótulos “átomos”, “moléculas” e “organismos”, “modelos”
e “páginas”. A consideração mais importante é estabelecer a
nomenclatura e a categorização mais eficazes para sua equipe.

Agora que sabemos como é uma inclusão, vamos colocá-la em prática e

dar uma olhada em alguns padrões de um site que ajudei a criar para a Time
Inc. Aqui está um padrão reutilizável que criamos:
Para o site da Time Inc., criamos uma molécula de bloco básica que consiste em uma imagem em
miniatura, título e trecho.
Esse padrão deve parecer bastante familiar. Uma imagem em miniatura,

título e trecho trabalhando juntos como uma única unidade é um padrão comum
encontrado em inúmeros sites. Vamos dar uma olhada por trás da cortina para
ver como esse padrão é construído.
70 PROJETO ATÔMICO
<div class="bloco-postagem">
<a href="{{ url }}">
{{> átomos-polegar }}
<h3>{{ título }}</h3>
<p>{{ trecho }}</p>
</a>
</div>
Você pode ver que temos: marcação HTML que consiste em uma div wrapper
com um nome de classe block-post; um link; um bigode incluído para a imagem em
miniatura; um elemento <h3> para o título; e uma tag <p> para o trecho. Você notará que
há mais código Moustache para URL, título e trecho, que usaremos mais tarde para
trocar dinamicamente o conteúdo real. Mais sobre isso daqui a pouco.
Agora que nossa marcação de padrão está estabelecida, podemos incluir

esse pedaço de código em padrões maiores usando o mesmo método include:
{{> moléculas-bloco-post }}
Agora vamos passar para organismos mais complexos, como o cabeçalho do site, que
se parece mais ou menos com isto:
O cabeçalho do site consiste em convenções bastante comuns, como um átomo de logotipo, uma molécula de navegação
primária e uma molécula de formulário de pesquisa.

Quando abrimos o capô para ver a marcação do cabeçalho em

Laboratório de padrões, vemos o seguinte:
<header role="banner">
{{> logotipo dos átomos }}

{{> moléculas-navegação primária }}
{{> pesquisa de moléculas }}
</header>
O que está acontecendo aqui? Bem, temos um elemento <header> básico e dentro
desse elemento incluímos o átomo da imagem do logotipo, a molécula de navegação
primária e a molécula do formulário de pesquisa.
E agora podemos incluir esse padrão relativamente complexo em qualquer lugar que
precisarmos.
{{> cabeçalho de organismos }}
Espero que agora você já possa ver as bonecas russas em ação.

Os menores átomos estão incluídos em moléculas maiores, e essas moléculas são
incluídas em organismos ainda maiores. Agora vamos pegar esses componentes e
conectá-los em um layout. Veja o modelo da página inicial, por exemplo:
72 PROJETO ATÔMICO
O modelo de página inicial da Time Inc. consiste em alguns padrões repetíveis: um

cabeçalho global, uma área principal, algumas seções (contendo uma imagem, título,
trecho e frase de chamariz), uma área com quatro itens, uma área factóide e um rodapé global.

Dê uma rápida olhada no modelo da página inicial e você verá alguns

padrões bastante padrão: um cabeçalho de site na parte superior, um
rodapé de site na parte inferior e uma área principal em tela cheia.
Você também verá alguns outros padrões se repetindo em todo o modelo.
Então, como isso fica no código? Como você pode esperar, envolve mais
inclusões!

< papel principal="principal">
{{# herói }}
{{> herói-moléculas }}
{{/ herói }}
<seção>
{{# bloco de experiência }}

{{> moléculas-bloco-principal }}
{{/ bloco de experiência }} {{#
recurso de experiência }}
{{> recurso de história de organismos }} {{/
recurso de experiência }}
</seção>
<seção>
{{# publicidade factóide }}

{{> organismos-factóide }}
{{/factoid-publicidade }} </section>
<seção>
{{# anúncio }}
{{> moléculas-bloco-principal }} {{/
publicidade }}
</seção>
...
</principal>
{{> rodapé de organismos }}
Nesta fase do jogo, os padrões menores já estão construídos, então tudo o

que o modelo precisa fazer é colocá-los no contexto de um layout de página e dar-
lhes nomes exclusivos.
74 PROJETO ATÔMICO
Observando o código mais de perto, observe que certos padrões como {{>
organismos-cabeçalho }} e {{> organismos-rodapé }} são incluídos da mesma
forma que os exemplos anteriores. Mas também existem alguns outros padrões de
inclusão que são complementados por algumas informações adicionais, como as
seguintes:
{{# publicidade factóide }}

{{> organismos-factóide }}
{{/publicidade factóide }}
Estamos incluindo organismos-factoides da mesma forma que todos os outros

padrões, mas também o chamamos de publicidade-factoide
agrupando o include em uma seção Moustache, indicada pelo código Moustache
contendo os símbolos # e /. Ao atribuir um nome exclusivo à instância do padrão,
podemos agarrá-la e substituir dinamicamente o conteúdo do padrão. Mais sobre isso
na próxima seção!
Essa abordagem de boneca russa para construir UIs é simples, mas

tremendamente poderosa. A estrutura permite que designers e desenvolvedores
mantenham os padrões SECOS, economizando tempo, esforço e dinheiro.
A abordagem permite que as equipes construam uma UI final e, ao mesmo tempo,
criem o sistema de design de UI subjacente. Afinal, a interface final é uma instanciação
do seu sistema de design subjacente. As equipes também podem alternar
entre o abstrato e o concreto, concentrando-se em um padrão específico para corrigir
bugs (“O cabeçalho está quebrado!”), ao mesmo tempo em que observam como as
alterações em pequenos padrões afetam o layout geral da página.
Trabalhando com dados dinâmicos
É importante articular a estrutura de conteúdo subjacente dos padrões de UI no contexto de uma

biblioteca de padrões. É por isso que estamos analisando imagens em escala de cinza com
exibição de dimensão e texto de espaço reservado contendo limites de caracteres. Mas, embora
essas informações sejam úteis para equipes criativas, imagens em tons de cinza e texto Lorem
ipsum não são o que os usuários interagem em seu site real. Precisamos de uma maneira de substituir
nosso conteúdo fictício por conteúdo representativo real para garantir que nossos padrões de UI
correspondam à realidade do conteúdo que reside dentro deles.
Para demonstrar como o Pattern Lab troca dinamicamente conteúdo real em

modelos, vamos dar uma olhada em uma comparação lado a lado do modelo de página
inicial e dos níveis de página da Time Inc.:

Uma comparação lado a lado do modelo de página inicial e dos níveis de página da Time Inc. O
template articula a estrutura de conteúdo do sistema de design, enquanto a página mostra a aparência do
sistema com o conteúdo real exibido por ele.
76 PROJETO ATÔMICO
À esquerda temos o nível de template, que articula a estrutura de conteúdo dos padrões
que compõem a página web. E à direita temos o nível da página, onde colocamos
conteúdo representativo real para demonstrar como seria a interface final e testar a
eficácia do sistema de design.
Como trocamos conteúdo fictício por conteúdo real no Pattern Lab?

O Pattern Lab usa JSON (bem como YAML, Markdown e outros formatos de
dados) para definir e trocar os bits dinâmicos de conteúdo em nossos designs.
Os dados do espaço reservado padrão são definidos em um arquivo chamado

data.json que fica no diretório /source do Pattern Lab . Dentro deste arquivo
definimos todos os textos, caminhos de imagens e outros dados dinâmicos que irão
compor nossa UI. Aqui está uma pequena amostra do arquivo data.json da Time Inc .:
"herói" : {
"título": "Lorem Ipsum",
"img": {
"src": "/images/sample/fpo_hero.png",
"alt": "Imagem do herói"
}
}
Para os desenvolvedores, esse tipo de formato provavelmente parece familiar. Se

você não é desenvolvedor, não se desespere! Depois de olhar além das chaves e
aspas, você verá que estamos definindo um objeto de herói (para a área de herói sem
margens diretamente abaixo do cabeçalho) que tem um valor de título de “Lorem
Ipsum” e uma imagem com um valor src de “/images/sample/fpo_hero.png”. Estamos
simplesmente definindo os atributos deste objeto e fornecendo valores para
esses atributos.
Depois que esses objetos forem definidos, podemos substituir seus

atributos no nível da página do Pattern Lab. Isso é feito criando um novo arquivo
JSON que corresponda ao nome do padrão de página (para a página inicial
da Time Inc., chamaremos de 00-homepage.json) dentro do diretório /pages.

Dentro do diretório 'pages' temos o padrão da página inicial, bem como um arquivo JSON
que corresponde ao nome do padrão. É aqui que substituiremos o conteúdo padrão
pelo conteúdo específico da página.
Quando abrimos 00-homepage.json podemos substituir os dados do espaço reservado

que estabelecemos anteriormente. Veja como isso pode ser:
"herói" : {
"headline": "Movendo Pessoas",
"img": {
"src": "/images/hero_beyonce.jpg",
"alt": "Beyoncé"
}
}
Ao substituir os dados padrão, o título principal agora é “Moving People” em

vez de “Lorem Ipsum”. E em vez de apontar para uma imagem de herói
somente para posicionamento (FPO) em tons de cinza, agora estamos apontando
para uma foto de Beyoncé localizada em “/images/
hero_beyoncé.jpg”.
78 PROJETO ATÔMICO
Este processo de estabelecer padrões para dados dinâmicos e depois

substituí-los por conteúdo específico da página continua para cada seção do
site. Além de substituir strings simples como títulos, também podemos definir
variáveis dinamicamente como verdadeiras ou falsas, percorrer uma matriz de
itens e muito mais. Podemos até alterar drasticamente a UI com apenas algumas
alterações em um arquivo JSON, sobre o qual falaremos a seguir.
Articulando variações de
padrões com pseudopadrões
Historicamente, os designers que trabalham com ferramentas estáticas

tendem a projetar apenas os melhores cenários. Você sabe do que estou falando:
o nome do usuário é Sara Smith e sempre cabe perfeitamente em uma linha; a foto
do perfil dela parece ter sido recortada de uma revista; seu perfil está
completamente preenchido; as duas colunas do conteúdo do perfil dela têm
exatamente a mesma altura.
É claro que estes melhores cenários raramente, ou nunca, ocorrem no mundo real.
Para criar projetos mais robustos e resilientes, precisamos levar

em conta simultaneamente as melhores e as piores situações – e tudo o
que está entre elas.
E se o usuário não enviar uma foto de perfil? E se o usuário tiver 87 itens no

carrinho de compras? E se o produto tiver 14 opções? E se o título da postagem
do blog contiver 400 caracteres?
E quanto a um usuário recorrente? Um usuário iniciante? E se o artigo não tiver
comentários? E se tiver sete camadas de comentários aninhados? E se precisarmos
exibir uma mensagem urgente no painel?
Articular essas variações de UI em uma ferramenta de design estático é um exercício

de tédio e redundância, o que pode explicar por que elas raramente são
projetadas. Mas se quisermos criar sistemas que abordem todas as variáveis e
realidades do nosso conteúdo, devemos levar em conta essas questões do tipo “e
se”.
Como podemos abordar todos os tipos de variação da IU sem nos esgotarmos no

processo? Pseudopadrão do Pattern Lab recurso

nos permite articular cenários às vezes totalmente diferentes com apenas

algumas alterações em nossos dados.
Digamos que estamos criando um aplicativo cujo painel exibe uma lista de
colaboradores do projeto. A IU pode ser semelhante a esta:
Uma lista de colaboradores do projeto
em nosso aplicativo hipotético.
Para criar o conteúdo dinâmico dentro de cada um desses blocos,

definiremos nossa lista de colaboradores como um array dentro de dashboard.json:
"colaboradores": [
{
"img": "/images/sample/avatar1.jpg",
"nome": "Steve Boomshakalaka",
"título": "CIA"
},
{
"img": "/images/sample/avatar2.jpg", "name":
"Gingersnap Jujubees-Daniels",
"title": "Presidente da Empresa Mais Longa
Nome na Corporação Mundial, Divisão Global"
},
{
"nome": "Sarunus Marciulionis",
"título": "Guerreiros do Golden State"
},
{
80 PROJETO ATÔMICO
"nome" : "Sara Smith",

"title" : "Título curto"
}
]
Por padrão, nosso design pressupõe que o usuário seja um usuário normal e não
um administrador, mas e se quiséssemos dar aos administradores a capacidade de
gerenciar os colaboradores do projeto a partir do painel? Essa IU pode ser parecida
com isto:
A IU do painel do administrador
apresenta ações extras de
edição e exclusão.
Para mostrar ações adicionais de edição e exclusão do administrador no painel

no Pattern Lab, podemos criar um pseudopadrão, um novo arquivo na pasta /pages
que se parece com isto:
painel~admin.json
O símbolo til (~) indica um pseudopadrão. painel~admin.json

herdará todos os dados contidos em dashboard.json, mas também nos dará a
oportunidade de anexar ou substituir dados adicionais. Isso significa que a lista de
colaboradores que definimos anteriormente em dashboard.json ainda está disponível,
mas podemos adicionar dados adicionais dentro de dashboard~admin.json
igual a:
"isAdmin" : verdadeiro
Estamos definindo uma variável chamada isAdmin e configurando-a como verdadeira.

Agora podemos usar isso para incluir condicionalmente as ações adicionais dentro do
padrão de bloco.

<div class="bloco">
<img src="{{ img }}" alt="{{ nome }}" />

<h3>{{ nome }}</h3>
<h4>{{ título }}</h4>
{{#isAdmin }}
{{> ações de bloqueio de moléculas }}
{{/ isAdmin }}
</div>
As primeiras linhas trazem a imagem, o nome e o título que definimos em

dashboard.json. Mas preste muita atenção ao que está incluído na seção isAdmin
Moustache. O que estamos dizendo aqui é: se isAdmin estiver definido como
verdadeiro, inclua um padrão de molécula chamado ações de bloqueio. O padrão de
ações de bloqueio contém os botões de edição e exclusão e só será exibido se isAdmin
estiver definido como verdadeiro (ou qualquer coisa além de falso). Em nosso dashboard.json
padrão, isAdmin não está definido, portanto, as ações extras não serão exibidas. Em
dashboard~admin.json, estamos definindo isAdmin como true para que as ações extras
sejam exibidas. Você pode estender essa técnica para alterar drasticamente toda
a UI (como alterar a navegação principal, mostrar painéis adicionais no painel, adicionar
controles extras e assim por diante) apenas alterando uma única variável. Coisas
poderosas, de fato.
Ufa. Se você chegou até aqui, parabéns! Agora você sabe adicionar e manipular
dados dinâmicos no Pattern Lab.
A capacidade do Pattern Lab de projetar com dados dinâmicos oferece alguns
benefícios cruciais:
ÿ Cria uma separação clara entre estrutura e conteúdo. A estrutura de um padrão

e seu conteúdo influenciam-se mutuamente. No entanto, os sistemas de design
resilientes se esforçam para estabelecer padrões agnósticos e flexíveis que
possam conter uma variedade de conteúdos.
A dissociação da estrutura do padrão e dos dados nos permite manter as coisas
SECAS (que, novamente, significa não se repita) e fazer alterações no conteúdo
sem afetar a estrutura do padrão.
Da mesma forma, podemos fazer alterações em um padrão sem precisar
atualizar cada instância desse padrão, simplesmente porque cada instância contém
dados diferentes. Essa separação resulta em enormes economias de tempo e esforço.
ÿ Estabelece um CMS ad hoc. Estabelecendo padrão e page-

dados específicos servem como um sistema de gerenciamento de conteúdo ad hoc.
82 PROJETO ATÔMICO
Conforme mencionado anteriormente, as ferramentas de design estático não estão bem

equipadas para lidar com dados dinâmicos, mas também é um exagero instalar
WordPress, Drupal ou algum outro CMS apenas para demonstrar variações de UI.
O Pattern Lab encontra um equilíbrio, pois permite que as equipes trabalhem
com dados dinâmicos, mas não requer a configuração de bancos de dados

MySQL malucos.
ÿ Serve como um modelo para desenvolvedores back-end responsáveis pela integração

da UI front-end em um sistema real de gerenciamento de conteúdo. Os
desenvolvedores de back-end podem observar a UI criada no Pattern Lab,
entender quais bits são estáticos e dinâmicos e, em seguida, traduzir isso para o sistema
de back-end.
ÿ Permite que escritores, profissionais de conteúdo, designers e outros não

desenvolvedores contribuam para o sistema de design vivo e vibrante.
Como desenvolvedor front-end, não consigo contar quantas vezes tive que corrigir
erros de digitação, trocar novas imagens, traduzir decks de cópias e fazer outras
edições relacionadas ao conteúdo no código front-end.
É a morte por um milhão de cortes de papel, e tenho certeza que a maioria dos
desenvolvedores concordaria que fazer pequenas alterações nas cópias não é um uso
eficaz de seu tempo. Ao separar estrutura e dados, o Pattern Lab permite que membros
da equipe que não são desenvolvedores gerenciem com segurança os aspectos
do design relacionados ao conteúdo, liberando os desenvolvedores para se
concentrarem na construção da estrutura do sistema de design.
Já cobrimos a funcionalidade principal do Pattern Lab, mas ainda não terminamos! A seguir,
abordaremos alguns recursos adicionais que devem ser considerados, independentemente
da ferramenta usada para criar sua biblioteca de padrões.
Ferramentas de viewport para padrões flexíveis
A multiplicidade de dispositivos que agora acessam a web forçou os designers a

abraçar novamente a fluidez intrínseca do meio.
Felizmente, técnicas como web design responsivo nos permitem criar layouts que ficam lindos
e funcionam perfeitamente em qualquer tela.
É óbvio que precisamos estabelecer padrões de UI flexíveis se quisermos criar designs

responsivos, mas criar padrões fluidos tem vantagens adicionais. Quanto mais fluido
for um componente de UI, mais resiliente e versátil ele se tornará. Imagine ser capaz
de pegar um componente – digamos, um controle deslizante de galeria de fotos – e
inseri-lo

em qualquer lugar que precisarmos. Às vezes, podemos precisar que seja um elemento sem margens
ocupando toda a janela de visualização. Outras vezes, poderemos precisar incluí-lo no contexto de
um artigo. E ainda outras vezes nós
pode querer incluí-lo na barra lateral. O sonho é construir nossos componentes de

maneira fluida e eles adaptarão seus estilos e funcionalidades para se adequarem a
quaisquer recipientes em que os colocarmos.
Na verdade, esta é a promessa das consultas em contêineres. As consultas de contêiner

permitem que os elementos se adaptem com base em seus contêineres pais, em
vez de em toda a janela de visualização, que é como manipulamos os elementos
usando consultas de mídia no momento. Embora ainda estejam sendo desenvolvidas como
um recurso nativo do navegador, as consultas de contêiner permitirão que designers e
desenvolvedores enlouquecidos por padrões criem e implantem facilmente sistemas de UI fluidos.
Entre design responsivo, consultas de contêiner e o bom e velho

Adotado o bom senso, agora entendemos por que é imperativo criar padrões de UI flexíveis.
Mas como nós fazemos isso? E como nossas ferramentas de biblioteca de padrões podem
nos ajudar a pensar e agir de maneira flexível?
Muitas das primeiras ferramentas de teste de design responsivo focavam na

visualização de designs em larguras populares de dispositivos móveis, como 320px (um
iPhone 4 em modo retrato), 480px (um iPhone 4 em modo paisagem), 768px (um iPad em
modo retrato) e assim por diante. . Mas, claro, a web é muito
mais diversificado do que uma visualização móvel, uma visualização de tablet e uma visualização de desktop.
Para ajudar os designers a considerar melhor todo o espectro de resolução ao testar

seus designs responsivos, criei uma ferramenta chamada ish.
A ferramenta é chamada ish. porque selecionar o botão pequeno resulta em uma janela
de visualização pequena. Selecioná-lo novamente fornece uma janela de visualização
diferente e pequena. Selecionar o botão médio fornece uma janela de visualização média.
E o botão grande resulta em uma – espere – janela de visualização grande. Esses
valores aleatórios ajudam os designers e desenvolvedores a considerar melhor todo o
espectro de resolução, em vez de um punhado de dimensões de dispositivos populares.
Sim. está integrado ao Pattern Lab, o que significa que podemos visualizar nossas UIs e
seus padrões subjacentes em todo o espectro de resolução.
Enquanto isso. ajuda designers e desenvolvedores a descobrir bugs ao longo do

continuum da janela de visualização, descobri que ele é mais útil como ferramenta
educacional para clientes e colegas. Ao construir uma ferramenta de redimensionamento
de viewport independente de dispositivo diretamente na biblioteca de padrões, clientes e colegas
84 PROJETO ATÔMICO
podem apreciar o fato de que seu sistema de design deve ter uma boa aparência e funcionar bem,
independentemente do tamanho da janela de visualização.
Pattern Lab exibindo um design em uma janela de visualização pequena.
Pattern Lab exibindo um design em uma viewport média.

Laboratório de padrões exibindo um design em uma janela de visualização grande.
Uma olhada nos bastidores com visualização de código
Um recurso comum da biblioteca de padrões é a capacidade de espiar nos bastidores

e visualizar o código subjacente que compõe um componente específico. Expor
o código de um padrão de UI acelera o tempo de desenvolvimento (adoro copiar e
colar tanto quanto qualquer outro codificador) e ajuda os líderes de equipe a aplicar
a sintaxe do código e as convenções de estilo. Isso se torna especialmente gratificante
quando muitos desenvolvedores estão trabalhando na base de código de uma organização.
Os tipos de código a serem destacados em uma biblioteca de padrões variam

naturalmente de organização para organização, a fim de atender aos requisitos
da vasta gama de ambientes, tecnologias e convenções utilizadas. A maioria das
bibliotecas de padrões disponíveis
demonstram o HTML subjacente de um padrão, enquanto outros também
incluem CSS e JavaScript específicos do padrão. O sistema de design Lightning da
Salesforce, por exemplo, mostra o HTML de um padrão, bem como todo o (S)CSS
pertencente a esse padrão.
86 PROJETO ATÔMICO
O sistema de design Lightning da Salesforce mostra o código HTML e SCSS dos componentes da UI.
A inclusão do código front-end faz com que os autores o escrevam de forma mais consistente,
mas isso não garante a perfeição. Ainda há espaço para os desenvolvedores se tornarem desonestos e
escreverem códigos desleixados e incongruentes – e é por isso que algumas organizações foram além para
estabelecer sistemas de design incrivelmente sofisticados. Empresas como a Lonely Planet alcançaram o
Santo Graal das bibliotecas de padrões, o que significa que sua biblioteca de padrões e seu ambiente
de produção estão perfeitamente sincronizados. Discutiremos o Santo Graal com mais detalhes no capítulo
5, mas vale a pena trazê-lo à tona nesta seção para demonstrar como isso afeta o código exposto no contexto
de uma biblioteca de padrões.
Em vez de oferecer HTML e CSS, o guia de estilo Rizzo da Lonely Planet apresenta o código de inclusão
para que as equipes extraiam o componente de UI apropriado.
A biblioteca de padrões do sistema de design Rizzo da Lonely Planet mostra o uso do modelo.

Essa configuração permite que a equipe principal de desenvolvimento mantenha uma

única fonte de verdade para o código front-end de todos os padrões. Para que os
desenvolvedores comecem a trabalhar, a biblioteca de padrões precisa apenas fornecer
o código para incluir um padrão específico.
O Pattern Lab oferece a capacidade de visualizar o HTML subjacente de um padrão e o

código do modelo usado para gerar o HTML. Ele também pode ser estendido para mostrar
o código CSS e JavaScript que o acompanha.
A visualização de código do Pattern Lab demonstra o código do modelo de um padrão e o HTML compilado.
Em última análise, qualquer ferramenta de biblioteca de padrões que você decidir usar
deve ter alguma forma de visualização de código. Talvez o mais importante seja
que as bibliotecas de padrões que você cria devem mostrar os tipos de código
que permitem que você e sua equipe de desenvolvimento sejam tão eficazes
quanto possível.
88 PROJETO ATÔMICO
Documentação viva e anotações

Em um processo de design tradicional isolado, é comum ver longos wireframes
e documentos de especificações criados, debatidos e aprovados.
Esses documentos geralmente assumem a forma de PDFs gigantescos, o que
é lamentável, considerando que geralmente contêm todos os tipos de informações,
instruções e documentação valiosas sobre o sistema de design.
Infelizmente, esses artefatos volumosos são frequentemente jogados em uma
lata de lixo (virtual) no momento em que o projeto entra em produção.
Este não deveria ser o caso. A documentação de uma UI deve conter

insights de todas as disciplinas envolvidas em sua criação e – isso é
fundamental – devem ser incorporados ao sistema de design vivo e vibrante.
Bibliotecas de padrões eficazes criam um espaço para definir e descrever
componentes de UI, articulando considerações que vão desde acessibilidade até
desempenho, estética e muito mais.
O Pattern Lab fornece várias maneiras de adicionar descrições e anotações

de padrões a um sistema de design. Descrições de padrões podem ser
adicionadas criando um arquivo Markdown que corresponde ao nome de um
padrão (por exemplo, nome-padrão.md), que mostrará a descrição do padrão
na visualização de lista da biblioteca.
O Pattern Lab exibe documentação importante de padrões junto com os exemplos de padrões vivos,
o que ajuda as equipes a comunicar definições, uso, exemplos, recursos externos e muito mais.

O Pattern Lab também fornece um recurso interessante (ouso dizer) que

permite anexar anotações a qualquer elemento da interface do usuário e
visualizar essas anotações no contexto do design vivo e vibrante. Quando
as anotações estão ativadas, cada elemento anotado recebe um número
que, quando clicado, leva você para a anotação correspondente. Isso
permite que as equipes visualizem considerações de padrões no contexto
da IU completa. Muito arrumado!
O recurso de anotação do Pattern Lab é interativo e integrado à interface de usuário ativa.
Fornecendo contexto com linhagem de padrões
Ao observar vários padrões em uma biblioteca, me perguntei: “Ótimo,

mas onde esse componente é realmente usado?”
Definir e descrever características de padrões é uma coisa, mas há uma
oportunidade de fornecer informações contextuais adicionais sobre seus
padrões de UI.
90 PROJETO ATÔMICO
Graças à abordagem de inclusão de bonecas russas descrita anteriormente,

o Pattern Lab pode exibir quais padrões constituem qualquer componente e
também mostrar onde esses padrões são empregados no sistema de design.
O recurso de linhagem do Pattern Lab exibe quais padrões compõem qualquer componente e também mostra todos
os locais em que esse componente é empregado.
No exemplo acima, temos um padrão molecular chamado media-block, que

contém uma imagem, título, texto e um grupo de botões. Observando a
linhagem do padrão, podemos ver que ele contém um padrão chamado átomos-
quadrado, que é a imagem do tamanho de uma miniatura, bem como moléculas-
botão-barra, que é o grupo de botões.
Também podemos ver onde exatamente esse padrão é usado: o organismo
da lista de bloqueios de mídia.
Essas informações contextuais são extremamente úteis para designers e

desenvolvedores; Eu sei que uso o recurso de linhagem o tempo todo em meu
próprio fluxo de trabalho. Digamos que quiséssemos fazer alterações em um
padrão específico, como dobrar o tamanho de uma imagem ou adicionar um
elemento adicional: saberíamos imediatamente quais padrões e modelos
precisariam ser testados novamente e submetidos a controle de qualidade para garantir que nada

as mudanças. O recurso de linhagem também ajuda a apontar padrões

redundantes e subutilizados para que as equipes possam eliminá-los da biblioteca
de padrões conforme a data de lançamento se aproxima.
Cada um com sua mania
Então aí está. O Pattern Lab oferece vários recursos úteis para as equipes criarem
sistemas de design deliberados e bem pensados. Mas, como mencionei antes,
nenhuma ferramenta será perfeita para todos e todas as situações. Existem muitas
ferramentas excelentes estão disponíveis para ajudá-lo a criar bibliotecas de
padrões eficazes, e as ferramentas que você escolher serão, sem dúvida,
influenciadas pelo ambiente, pelas tecnologias, pelo fluxo de trabalho e pela cultura
da sua organização.
Ao escolher ferramentas para criar sua biblioteca de padrões, você deve manter os
olhos abertos para estas qualidades e recursos de bibliotecas de padrões eficazes:
ÿ Fornecimento de descrições e anotações de padrões.
ÿ Apresentando o padrão relevante HTML, modelos, CSS e/ou

Código JavaScript.
ÿ Visualização de padrões em todo o espectro de resolução.
ÿ A capacidade de mostrar variações de padrões, como ativo ou

guias desabilitadas.
ÿ A capacidade de adicionar dinamicamente conteúdo representativo real às

estruturas dos padrões.
ÿ Fornecer informações contextuais, como quais padrões compõem um determinado

componente, bem como onde esse componente é usado.
No final das contas, não se trata das ferramentas que usamos para criar bibliotecas de
padrões, mas sim de como as usamos. Criar e manter um sistema de design eficaz
significa mudar drasticamente a cultura, os processos e os fluxos de trabalho da sua
organização. Se isso parece difícil para você, é porque é. Mas não tema! O restante do livro
detalhará todo o processo de criação e manutenção de um sistema de design bem-sucedido para
preparar sua organização para o sucesso a longo prazo.
92 PROJETO ATÔMICO
Capítulo 4
O Atômico
Fluxo de trabalho
Pessoas, processos e como fazer os sistemas

de design acontecerem
Falar é fácil. E até agora, temos conversado muito. Isso não quer dizer que
não tenha sido uma conversa produtiva! Afinal, discutimos a importância do
pensamento modular, aprendemos uma metodologia para criar sistemas de design
de UI deliberados e apresentamos ferramentas para criar bibliotecas de padrões
eficazes.
Mas é aqui que a borracha encontra a estrada. Onde arregaçamos as mangas e

colocamos em prática toda essa teoria. Onde fazemos as coisas. Este capítulo
abordará tudo o que envolve a venda, criação e manutenção de sistemas de design
eficazes. Esta pronto? Vamos.
São pessoas!
O segredo não tão secreto sobre a criação de sistemas de design eficazes (ou
sobre a realização de qualquer ótimo trabalho, na verdade): tudo se resume a
pessoas que realmente colaboram e se comunicam umas com as outras.
Se isso é de conhecimento geral, por que não ouvimos constantemente

milhares de histórias de sucesso em todo o mundo? Vou deixar Mark Boulton
explicar:
O processo de design é estranho e complicado, porque as pessoas

são estranhas e complicadas.
-Mark Boulton
Você pode ter todas as tecnologias certas implementadas, usar as melhores e

mais recentes ferramentas e até mesmo ter indivíduos extraordinariamente
talentosos a bordo, mas se todos os envolvidos não estiverem realmente
cooperando e se comunicando entre si, você não criará um ótimo trabalho. . É
simples assim. Isso não quer dizer que você não possa criar um bom trabalho, mas
na maioria das vezes você criará uma das muitas nuances decepcionantes de um
trabalho ruim.
Estabelecer e manter sistemas de design de interface bem-sucedidos exige um

esforço de toda a organização, e este capítulo discutirá como superar as muitas
peculiaridades dos seres humanos para que isso aconteça.
CAPÍTULO 4 / O FLUXO DE TRABALHO ATÔMICO 95

Quando estabelecer um sistema de design
Então, qual é o melhor momento para estabelecer um sistema de design de interface?

Resposta curta: agora.
Os sistemas de design e suas bibliotecas de padrões que os acompanham são

frequentemente criados em conjunto com um novo projeto de design ou
redesenho, esforço de reformulação de plataforma ou outra iniciativa. Pegar carona em
outro projeto é uma ótima maneira de inserir uma biblioteca de padrões em sua
organização.
Dito isto, a criação de um sistema de design e de uma biblioteca de padrões não

precisa necessariamente coincidir com outro projeto. Se você conseguir convencer
seus clientes e partes interessadas a desembolsar dinheiro e recursos para um projeto de
sistema de design dedicado, ótimo para você!
Como exatamente você vende um sistema de design para seus clientes, chefes,
colegas e partes interessadas? Coloque seu chapéu de negócios, porque abordaremos
isso na próxima seção!
Padrões de arremesso
Introduzir uma nova forma de fazer as coisas não é uma tarefa fácil, pois exige a mudança
das mentalidades e dos comportamentos existentes nas pessoas. Conseguir a
participação das partes interessadas e dos clientes no estabelecimento de um sistema de
design envolve educação constante, além de um pouco de conhecimento de marketing.
As primeiras coisas primeiro. É necessário apresentar o conceito de sistemas de design de

interface aos seus clientes, colegas e partes interessadas.
Explique o que são esses sistemas de design e as muitas maneiras pelas quais eles
podem ajudar a organização. Discutimos esses benefícios ao longo do livro, para que
você possa explicar como os sistemas de design promovem consistência e
coesão, aceleram a produtividade da sua equipe, estabelecem um fluxo de
trabalho mais colaborativo, estabelecem um vocabulário compartilhado,
fornecem documentação útil, facilitam os testes e servem como uma base favorável
ao futuro. Quem pode dizer não a tudo isso?!
Infelizmente, descobri que posso exagerar nos sistemas de design até ficar com o rosto
azul, mas os trajes nem sempre veem as coisas pelas mesmas lentes que as pessoas no
terreno. Uma simples reformulação da questão ajuda
96 PROJETO ATÔMICO
imensamente. É muito mais eficaz simplesmente perguntar: “Você gosta de

economizar tempo e dinheiro? Sim ou não?" Se a resposta a essa pergunta for não,
temo que você tenha problemas muito maiores do que vender um sistema de design. Se a
resposta for sim, então você pode apresentar os benefícios sob a ótica do tempo e do
dinheiro. Vamos tentar isso, certo?
ÿ Os sistemas de design levam a experiências coesas e consistentes. Isso

significa que os usuários dominam sua IU com mais rapidez, gerando mais
conversões e mais dinheiro com base nas métricas que interessam aos seus
stakeholders.
ÿ Os sistemas de design aceleram o fluxo de trabalho da sua equipe. Em vez de

reinventando a roda sempre que uma nova solicitação chega, as equipes podem
reutilizar peças do quebra-cabeça da interface do usuário já estabelecidas para lançar
novas páginas e recursos com mais rapidez do que nunca.
ÿ A centralização dos componentes da UI em uma biblioteca de padrões estabelece um

vocabulário compartilhado para todos na organização e cria um fluxo de trabalho
mais colaborativo em todas as disciplinas. Com todos falando a mesma língua, gasta-
se mais tempo realizando o trabalho e menos tempo lidando com comunicações e
reuniões supérfluas.
ÿ Os sistemas de design facilitam os testes entre navegadores/dispositivos,

desempenho e acessibilidade, acelerando enormemente o tempo de produção e
permitindo que as equipes iniciem trabalhos de maior qualidade com mais rapidez.
Além disso, incorporar coisas como acessibilidade em um sistema de design vivo
dimensiona essas práticas recomendadas, permitindo que suas interfaces alcancem
mais usuários e, ao mesmo tempo, reduzindo o risco de você ser processado!
ÿ Uma vez estabelecido um sistema de design (com a biblioteca de padrões que o

acompanha), ele serve como uma base favorável ao futuro para a organização
modificar, ajustar, ampliar e melhorar ao longo do tempo.
Fazendo alguns testes A/B? Transforme as lições desses testes no sistema de design
vivo. Fez algumas grandes otimizações de desempenho?
Coloque-os no sistema de design vivo! A parte viva dos sistemas de design vivo
significa que eles sempre podem se adaptar para atender às necessidades futuras da
organização, economizando tempo e dinheiro ao mesmo tempo.
Enquadrar as coisas em termos de tempo e dinheiro ajuda as pessoas que

controlam o orçamento a entender por que um sistema de design vale a pena. Com
alguma sorte, essas conversas se traduzirão em um compromisso concreto da organização
(leia-se: alocação de tempo e dinheiro real) para fazer um sistema de design acontecer.

Mostre, não conte: o poder dos inventários de interface
Se ao menos conseguir adesão fosse tão fácil quanto ter algumas conversas
oportunas com as pessoas certas. Talvez você seja experiente o suficiente para
fechar o acordo apenas com pontos de discussão, mas para nós, meros mortais,
palavras não são suficientes. Às vezes você precisa de mais. Às vezes você
precisa fazê-los sentir a dor.
Entre no inventário da interface.
Muitos estão familiarizados com o conceito de inventário de conteúdo. As auditorias

de conteúdo geralmente são realizadas nos estágios iniciais do processo de
reformulação de um site para fazer um balanço de todo o conteúdo do site. É
um processo tedioso que envolve planilhas e cafeína, mas todo esse trabalho duro compensa.
No final do exercício, o conteúdo da organização é apresentado sobre a mesa,
dando às equipes informações valiosas sobre como lidar com seu conteúdo à
medida que abordam o projeto.
Um inventário de interface é semelhante a um inventário de conteúdo, só que em

vez de filtrar e categorizar o conteúdo, você está avaliando e categorizando
todos os componentes que compõem sua interface de usuário. Um inventário
de interface é uma coleção abrangente de partes que compõem sua interface
de usuário.
Aqui está uma coleção de todos os estilos de botões exclusivos encontrados na página inicial do
United.com. Um inventário de interface reúne e categoriza todos os padrões exclusivos que compõem uma interface.
98 PROJETO ATÔMICO
Conduzindo uma auditoria de interface
Como você conduz uma auditoria de interface? Como você reúne todos os
componentes que compõem sua IU? A resposta simples são capturas de tela.
Muitos deles! A criação de um inventário de interface requer captura de tela e
categorização vaga de todos os componentes exclusivos que compõem suas
interfaces de usuário. Embora seja um esforço relativamente simples, há
algumas considerações importantes a serem lembradas para tornar o inventário
o mais útil possível. Vamos passar pelo processo de criação de um inventário de
interface bem-sucedido.
Passo 1: Reúna as tropas
Encontrei muitos designers e desenvolvedores ambiciosos que assumiram a

responsabilidade de começar a documentar os padrões de UI de suas
organizações. Embora eu certamente aplauda essa ambição individual, é absolutamente
essencial fazer com que todos os membros da equipe experimentem a dor de
uma UI inconsistente para que comecem a pensar sistematicamente.
Para que o inventário da interface seja o mais eficaz possível,

representantes de todas as disciplinas responsáveis pelo sucesso do site devem
estar reunidos em uma sala para o exercício. Reúna as tropas: designers UX, designers
visuais, desenvolvedores front-end, desenvolvedores back-end, redatores, estrategistas
de conteúdo, gerentes de projeto, proprietários de empresas, controle de qualidade e
quaisquer outras partes interessadas. Quanto mais melhor! Afinal, um dos
resultados mais cruciais deste exercício é estabelecer um vocabulário partilhado para
todos na organização, e isso requer a contribuição de toda a equipa.
Etapa 2: prepare-se para a captura de tela
O exercício de inventário de interface gera uma tonelada de capturas de tela,

então, naturalmente, você precisará de um software para capturar e exibir essas
capturas de tela. Algumas ferramentas possíveis incluem:
ÿ PowerPoint ou Keynote
ÿ Photoshop ou Sketch
ÿ Evernote Web Clipper
ÿ Google Docs ou Microsoft Word

É importante que todos os participantes façam capturas de tela usando o mesmo software para que possam ser
combinadas posteriormente. Criei um modelo de inventário de interface do Apresentações Google para as equipes
usarem como ponto de partida.
ÿ Apresentações Google (se você estiver interessado, criei um modelo de inventário

de interface do Apresentações Google )
Em última análise, realmente não importa qual ferramenta você usa, mas todos devem
concordar com uma única ferramenta para facilitar a combinação no final do exercício.
Descobri que softwares de criação de slides on-line, como o Apresentações Google, são
muito eficazes, pois fornecem uma tela para posicionamento de imagens de formato livre,
eles são divididos em slides para facilitar a categorização e são baseados na Web,
portanto podem ser compartilhados com facilidade.
Etapa 3: exercício de captura de tela
Prepare seus dedos para capturar imagens porque é hora do evento principal! O
exercício de auditoria de interface envolve capturar imagens e categorizar todos
os padrões de UI exclusivos que compõem sua experiência. Tenha em mente
que este exercício não significa capturar todas as instâncias de um padrão de UI
específico, mas sim capturar uma instância de cada padrão de UI exclusivo.
Atribua a cada participante uma categoria de UI. Poderá ser necessário formar pares
de pessoas ou pedir aos participantes que documentem múltiplas categorias,
dependendo de quantas pessoas participam no exercício. Mais uma vez, é útil ter o
maior número possível de participantes, já que mais pessoas capturando capturas de
tela resultarão em uma documentação mais completa.
100 PROJETO ATÔMICO

Quais padrões capturar
Quais categorias de elementos de interface devem ser capturadas? Obviamente, as

categorias variam de interface para interface, mas aqui estão algumas categorias para
começar:
ÿ Elementos globais: componentes como cabeçalhos, rodapés e outros elementos

globais que são compartilhados durante toda a experiência.
ÿ Navegação: navegação primária, navegação de rodapé, paginação, localização atual,

controles de componentes interativos e essencialmente qualquer coisa usada para
navegar em uma interface de usuário.
ÿ Tipos de imagens: logotipos, imagens de heróis, avatares, miniaturas,

planos de fundo e qualquer outro tipo de padrão de imagem que apareça na IU.
ÿ Ícones: os ícones são um tipo especial de imagem digno de sua própria categoria.
Capture lupas, ícones sociais, setas, hambúrgueres, spinners, favicons e todos
os outros ícones da interface.
ÿ Formulários: entradas, áreas de texto, menus de seleção, caixas de seleção, interruptores,

botões de opção, controles deslizantes e outras formas de entrada do usuário.
ÿ Botões: os botões são o elemento de UI por excelência. Capture todos os padrões de

botões exclusivos encontrados ao longo da experiência: primário, secundário,
grande, pequeno, desativado, ativo, de carregamento e até botões que parecem
links de texto.
ÿ Títulos: h1, h2, h3, h4, h5, h6 e variações de tipografia

títulos.
ÿ Blocos: também conhecidos como anúncios, frases de destaque, resumos, anúncios

ou unidades heróicas, os blocos são coleções de títulos tipográficos e/ou
imagens e/ou texto de resumo (veja o artigo de Nicole Sullivan sobre o objeto de
mídia como exemplo de bloco).
ÿ Listas: não ordenadas, ordenadas, definição, com marcadores, numeradas,

forrado, listrado ou qualquer grupo de elementos apresentados em formato de lista.
ÿ Componentes interativos: acordeões, abas, carrosséis e outros módulos funcionais

com peças móveis.
ÿ Mídia: reprodutores de vídeo, reprodutores de áudio e outras mídias avançadas

elementos.
ÿ Componentes de terceiros: widgets, iframes, cotações de ações, botões sociais, scripts

de rastreamento invisíveis, e qualquer outra coisa que não esteja hospedada em
seu domínio.

ÿ Publicidade: todos os formatos e dimensões de anúncios.
ÿ Mensagens: alertas, sucessos, erros, avisos, validação, carregadores, pop-ups, dicas de

ferramentas e assim por diante. Essa pode ser uma categoria desafiadora de
capturar, pois as mensagens geralmente exigem a ação do usuário para serem expostas.
ÿ Cores: capture todas as cores exclusivas apresentadas na interface. Esta categoria pode
ser auxiliada por fantásticas ferramentas de inicialização de guia de estilo, como
CSS Stats e Estilifique-me.
ÿ Animação: a animação é um aspecto elementar das interfaces de usuário e, portanto,

deve ser documentada. Isso requer o uso de um software de gravação de tela, como
o QuickTime, para capturar qualquer elemento da interface do usuário que se mova,
desapareça, trema, faça transições ou oscilações na tela.
tela.
Um exemplo de padrões de botões exclusivos capturados em um inventário de interface para o site de um grande banco.
Novamente, essas categorias não são imutáveis e variam de acordo com a natureza
da interface do usuário com a qual você está lidando. É claro que é importante adicionar,
subtrair ou modificar essas categorias para melhor atender às suas necessidades
organizacionais.

Um exemplo de vários elementos de formulário capturados em um inventário de interface para o site de um grande banco.
Tempo é tudo
É importante definir limites de tempo para o exercício de captura de tela para evitar
cair na toca do coelho que dura o dia todo. A quantidade de tempo alocada irá
variar dependendo de quantas pessoas estão participando, mas acho que
entre 30 e 90 minutos são suficientes para uma primeira passagem de um inventário
de interface. Defina um cronômetro e jogue um pouco do Jeopardy! música (bem,
talvez não a música Jeopardy!, mas alguma outra música que crie um clima otimista
para o exercício) e faça com que os participantes se concentrem em capturar imagens
dos padrões de IU exclusivos que encontrarem.
Cave fundo
Quais partes do site os participantes devem capturar no inventário de interface?

Resposta curta: tudo. Qualquer parte da UI que seja ou possa ser gerenciada pela
sua organização deve ser documentada.

Isto é difícil porque as organizações tendem a favorecer certas partes da experiência

(tosse , página inicial, tosse) em detrimento de outras. Por exemplo, as pessoas
que trabalham em um site de comércio eletrônico tendem a se concentrar na
experiência principal de compra, embora áreas como suporte ao cliente, perguntas
frequentes, tabelas de dimensionamento, páginas 404 e termos legais também sejam
extremamente importantes para a experiência do usuário. Lembre-se de que os
usuários percebem sua marca como uma entidade única e não se importam com sua
estrutura organizacional, pilha de tecnologia ou qualquer outra coisa que possa
causar disparidades na IU. Incentive os participantes da auditoria de interface a
serem tão minuciosos quanto possível durante o exercício.
Etapa 4: apresentar descobertas
O exercício de captura de tela pode ser um pouco complicado, portanto, certifique-

se de que a equipe faça uma pausa após a conclusão do exercício. Pegue um pouco
de comida, tome um café e estique um pouco as pernas. Quando todos estiverem
revigorados, é hora de discutir o que você capturou.
Faça com que cada participante gaste cinco ou dez minutos apresentando cada
categoria de IU ao grupo. É aqui que a diversão começa. A apresentação ao grupo
permite que a equipe discuta a lógica por trás dos padrões de UI existentes, inicia
uma conversa sobre convenções de nomenclatura e deixa a equipe entusiasmada
para estabelecer uma interface mais consistente.
Nomear as coisas é difícil. É fascinante ouvir os nomes inconsistentes que designers,

desenvolvedores, proprietários de produtos e outras partes interessadas têm para o
mesmo padrão de UI. “Oh, chamamos isso de barra de utilidades.” “Oh, nós chamamos isso de
navegação administrativa.” “Oh, nós chamamos isso de área de ação flutuante!” Este exercício é uma
oportunidade para descobrir e eliminar disparidades entre rótulos de padrões e também estabelecer
nomes para padrões anteriormente não rotulados. Não sinta que precisa chegar a um consenso
sobre os nomes finais dos padrões no decorrer de dez minutos; este exercício pretende simplesmente
abrir uma discussão mais ampla.
Depois que cada categoria for apresentada e discutida, todos os participantes

deverão enviar seus slides ao líder do exercício. O líder combinará então tudo
num superdocumento gigante, que em breve se tornará uma bola de demolição de
verdade e justiça.

Passo 5: Reagrupar e estabelecer os próximos passos
Com o superdocumento em mãos, é hora de envolver toda a organização na

elaboração de um sistema de design de interface.
Você já quis ver um CEO chorar? Revelar todas as inconsistências da sua IU é uma ótima
maneira de fazer isso acontecer! Um dos benefícios mais poderosos dos inventários
de interface é que você pode mostrá-los a qualquer pessoa, incluindo não designers
e desenvolvedores, e eles entenderão por que UIs inconsistentes são problemáticas.
Você não precisa ser um designer para reconhecer que ter 37 estilos de botões exclusivos
provavelmente não é uma boa ideia. Esta é sua oportunidade de deixar bem claro para as
partes interessadas que abordar sua UI de uma forma mais sistemática faz muito sentido tanto
para seus usuários quanto para sua organização.
Além de vender a ideia aos principais interessados, todo o trabalho árduo e discussão
envolvidos no exercício inicial de inventário de interface devem ser traduzidos nas
sementes do seu futuro sistema de design e biblioteca de padrões.
É muito provável que o exercício inicial não tenha capturado todos os padrões de UI
exclusivos, portanto, talvez seja necessário realizar outro exercício de auditoria de
interface para capturar uma imagem mais completa de seus padrões de UI.
Isso pode envolver novamente um grupo grande, mas na realidade uma equipe menor
e interdisciplinar analisará o superdocumento e estabelecerá os próximos passos para o
sistema de design.
Depois que as lacunas no inventário de interfaces forem preenchidas, o grupo de

trabalho poderá ter algumas conversas importantes sobre os próximos passos do projeto do
sistema de design. Algumas questões-chave a serem abordadas por este grupo incluem:
ÿ Quais padrões devem permanecer, quais devem desaparecer e quais podem ser mesclados?
ÿ Que nomes de padrões devemos escolher?
ÿ Quais são os próximos passos para traduzir o inventário de interface em

uma biblioteca de padrões vivos?

Benefícios de um inventário de interface
Criar um inventário de interface pode ser uma tarefa e tanto, mas os benefícios
de fazer um são muitos:
ÿ Captura todos os padrões e suas inconsistências: uma interface

o inventário reúne todos os padrões exclusivos que compõem sua IU.
Ver todos esses padrões semelhantes, mas ainda diferentes, próximos uns
dos outros expõe a redundância e ressalta a necessidade de criar uma
experiência consistente e coesa.
ÿ Obtém adesão organizacional: ter um grupo grande e diversificado de

disciplinas participam do exercício ajuda todos a compreender o valor de
criar e manter uma interface de usuário consistente. Além disso,
o superdocumento de inventário de interface pode ser uma ferramenta
tremendamente poderosa para convencer as partes interessadas, chefes e
clientes a investir em um sistema de design de interface.
ÿ Estabelece um escopo de trabalho: um inventário de interface ajuda as

equipes de design a determinar o nível de esforço necessário para projetar
e construir cada padrão de UI como parte de um projeto de design ou
redesenho. Quais componentes serão relativamente fáceis ou difíceis de
converter em um ambiente responsivo? Quais são as considerações de
conteúdo, design e desenvolvimento em torno de cada componente? Um
inventário de interface permite que as equipes tenham conversas
importantes que ajudam a estabelecer o escopo e o cronograma realistas de um projeto.
ÿ Estabelece as bases para um sistema de design de interface sólido: o

inventário de interface é um primeiro passo importante para configurar
uma biblioteca de padrões abrangente. É essencial capturar todos os padrões
de UI existentes para determinar quais padrões farão o corte final no sistema
de design vivo. O exercício de auditoria de interface também ajuda as
equipes a estabelecer um vocabulário compartilhado, que será crucial para o
sucesso do eventual sistema de design.
Peça perdão, não permissão
Então, você discutiu os benefícios de estabelecer um sistema de design

vivo com suas partes interessadas e até criou um inventário de interface para
mostrar a eles o desastre inconsistente que é a UI atual. E ainda assim,
apesar de todos os seus esforços, eles ainda derrubam o

boa ideia de estabelecer um sistema de design de interface e uma biblioteca de padrões. O que uma
equipe web responsável deve fazer?
Faça isso de qualquer maneira.
Assim como construímos coisas como desempenho, acessibilidade e capacidade de resposta

em nossos produtos e processos por padrão, também deveríamos criar sistemas de design por padrão.
Você não precisa da aprovação do cliente para seguir as melhores práticas do seu ofício. Quando
você dá às partes interessadas a opção de dizer não a alguma coisa, elas o farão. Então simplesmente
não dê a eles essa oportunidade. Nosso trabalho é criar um excelente trabalho para nossos clientes
e organizações, e os sistemas de design de interface são um meio para esse fim.
Na verdade, para criar o todo, é preciso criar as partes desse todo. Nossas interfaces consistem
em peças menores, quer você se importe com essas peças menores ou não.
Você tem uma decisão a tomar: concentrar-se apenas na criação do todo, ignorando as partes, ou
passar algum tempo organizando as partes para ajudá-lo a criar o todo com mais eficiência. Em seu
livro Multiscreen UX Design, Wolfram Nagel articula maravilhosamente essas abordagens usando peças
de Lego como analogia.
Uma maneira de abordar um projeto Lego é simplesmente despejar as peças da caixa sobre uma
mesa, arregaçar as mangas e começar a construir sua criação.
Uma maneira de abordar um projeto Lego é simplesmente despejar as peças sobre uma mesa e
vasculhar a pilha para encontrar as peças necessárias. Imagem adaptada de "Multiscreen UX
Design" de Wolfram Nagel.

Esta abordagem a um projecto Lego é certamente uma estratégia viável, mesmo

que seja assumidamente aleatória. O único momento em que você prestaria
atenção à pilha de tijolos seria quando estivesse vasculhando-a para encontrar
a peça específica de que precisa.
Isso não é diferente de quantos projetos digitais são abordados.

O cliente precisa de um site, então começamos a projetá-lo e construí-lo. O cliente
precisa de um aplicativo mobile, então começamos imediatamente a construir as
telas do aplicativo. Nosso olhar permanece paralisado no produto final e
raramente, ou nunca, olhamos para os padrões subjacentes que compõem nossas
UIs finais.
Claro, há outra maneira de abordar seus projetos Lego e digitais. Em vez de

mergulhar de cabeça na construção do trabalho final, você pode reservar um
tempo para fazer um balanço das peças disponíveis e organizá-las de forma que
se tornem mais úteis.
Reservar um tempo para organizar as peças que compõem suas criações finais permite que você
aborde o trabalho de maneira mais deliberada e eficiente. Imagem adaptada de "Multiscreen UX
Design" de Wolfram Nagel.
Sem dúvida, organizar exige tempo, planejamento e esforço. Não vem de

graça. O fato de essa configuração não estar visivelmente representada no produto
final pode nos levar a dizer que ela serve como uma distração para o trabalho real
que precisa ser feito. Porque se importar?
Ao reservar um tempo para organizar as partes, você agora pode criar

o todo de uma maneira mais realista, deliberada e eficiente.
Criar uma biblioteca com os materiais disponíveis permite abordar o projeto de uma
forma mais metódica e economiza muito tempo no processo. Em vez de vasculhar
uma situação aleatória

pilha de tijolos e gastando tempo reinventando padrões, você pode criar um sistema
organizado de componentes que ajudará a produzir um trabalho melhor em menos
tempo.
Reservar um tempo para organizar as peças que compõem suas criações finais permite que você
trabalhe de maneira mais deliberada e eficiente. Em vez de vasculhar uma pilha aleatória de tijolos, um
inventário organizado de componentes pode produzir um trabalho melhor e mais rápido. Imagem
adaptada de "Multiscreen UX Design" de Wolfram Nagel.
No que diz respeito aos seus clientes e stakeholders, o produto final ainda está
em produção. Contanto que você mostre progresso no trabalho final, você pode
decidir quanto do seu processo interno deseja expor. O fato de você estar criando um
sistema de design para produzir o produto final não é motivo de preocupação
para eles; é simplesmente uma decisão que sua equipe está tomando para criar um
trabalho melhor.
Se você estiver lidando com partes interessadas avessas à mudança, eu

digo para fazer o que for preciso e dizer-lhes para não prestarem atenção ao que
está acontecendo nos bastidores. Depois de lançar o projeto com sucesso e o
champanhe ter sido servido, você pode abrir a cortina e dizer: “Ah, a propósito,
estabelecemos um sistema de design e uma biblioteca de padrões para que a
equipe pudesse colaborar e trabalhar em conjunto com mais eficiência. ” Seria
extremamente difícil para eles argumentarem contra você agora, especialmente
se o projeto chegasse dentro do prazo e do orçamento. Se você tiver muita sorte,
poderá transformar o sucesso do projeto inicial em uma iniciativa mais oficial dentro
da organização para evoluir seu sistema de design.

Claro, é preferível deixar seus clientes, colegas e partes interessadas

entusiasmados com a criação de um sistema de design de interface ou, pelo menos,
obter sua aprovação para prosseguir com o projeto de forma modular. Mas acho importante
encontrar maneiras de seguir as melhores práticas do seu ofício, mesmo quando você
enfrenta extrema resistência organizacional.
(Re)definindo expectativas
Você trabalhou muito para vender o conceito de um sistema de design, mas

ainda precisa definir as expectativas das partes interessadas e da equipe antes de
arregaçar as mangas e começar a trabalhar.
Quando digo “definir expectativas”, na verdade estou dizendo “redefinir expectativas”.

Veja, todos nós trazemos nossas próprias experiências, opiniões e preconceitos
para um projeto. Nossa indústria ainda é incrivelmente jovem, então muitas pessoas
que trabalham em projetos web vêm de outras indústrias com seus próprios
Ways Of Doing Things™ estabelecidos. Mesmo as pessoas que trabalharam
exclusivamente no mundo digital sentiram a bagagem das indústrias do passado. Além
disso, os princípios orientadores, as melhores práticas e as táticas do design digital
ainda estão em grande parte sendo codificados.
É ridículo alguém pronunciar a frase: “É assim que sempre fizemos as coisas”

numa indústria que tem apenas 25 anos.
Infelizmente, nós, humanos, somos criaturas de hábitos, e sair do abraço
caloroso da familiaridade é desconfortável. Não gostamos de ficar desconfortáveis.
Devemos superar as nossas predisposições existentes se quisermos adotar as melhores
práticas da nossa indústria em constante mudança e criar um trabalho digital de
sucesso.
Redefinindo o design
Percorremos um longo caminho desde a simples transplantação de PDFs impressos

para a World Wide Web, mas o design de impressão ainda lança uma longa
sombra e continua a influenciar a forma como as coisas são feitas online.
O design no mundo da impressão concentra-se fortemente na estética visual. Afinal,

você não pode fazer muito mais com um pôster do que olhar para ele. Para ser claro,
certamente não estou sugerindo que o design de impressão seja fácil ou
unidimensional; o mundo da impressão está repleto de nuances e artesanato. O que
estou dizendo é que a natureza bidirecional e interativa da web acrescenta
muito mais dimensões ao que constitui um bom design. Velocidade,

tamanho da tela, ambiente, capacidades tecnológicas, formato, ergonomia,

usabilidade, acessibilidade, contexto e preferências do usuário devem ser
considerados se quisermos criar um ótimo trabalho para este admirável novo
mundo digital.
Essas considerações adicionais de design são vitais para a criação de ótimos

trabalhos digitais, mas muitas vezes estão ausentes de nossos processos e
fluxos de trabalho. O designer Dan Mall explica:
Como indústria, vendemos sites como pinturas. Em vez disso,

deveríamos vender um acesso bonito e fácil ao conteúdo, independentemente
do dispositivo, tamanho da tela ou contexto.
-Dan Mall
Como chegamos ao ponto em que vendemos e criamos sites como se

fossem imagens estáticas? Durante os anos de formação da web, criamos
experiências destinadas a serem consumidas exclusivamente por
computadores desktop, o que é compreensível, já que os desktops eram
realmente o único jogo disponível. O espaço fornecido pelas telas de
desktop tornou viável e atraente a ideia de simplesmente traduzir um PDF para
a web. Então foi isso que fizemos – e por um tempo realmente funcionou!
Era uma vez, a web era consumida principalmente em telas de desktop, daí esta máquina velha e de
aparência áspera.

No entanto, isso não veio sem consequências. Essa perspectiva impressa da

web reforçou a noção de que os designs da web, assim como seus equivalentes
off-line, poderiam e deveriam ter a mesma aparência em todos os ambientes. Ele
também manteve o foco na aparência de um web design
e não como funcionava , ignorando todas as características únicas deste novo e
rico meio de comunicação. Além disso, reforçou a crença de que poderíamos
aplicar os mesmos processos lineares usados para criar trabalhos impressos ao
nosso trabalho digital.
O tempo passou, é claro, e os dispositivos móveis explodiram, a

tecnologia melhorou e a web se tornou o cenário incrivelmente grande e
diversificado que conhecemos hoje. Já se foram os dias apenas de desktops e,
em seu lugar, veio o tempo dos smartphones, telefones burros, tablets, phablets,
netbooks, notebooks, leitores eletrônicos, wearables, TVs, consoles de jogos,
painéis de carros e muito mais.
Esta é a web: uma miscelânea de dispositivos, tamanhos de tela, capacidades, formatos, velocidades de rede,
tipos de entrada e muito mais.
A diversidade do panorama atual da web destruiu a alucinação consensual da web

para desktop, onde poderíamos simplesmente incorporar as mentalidades e os
processos de impressão a esse novo meio. Simplesmente

olhar para um smartphone, tablet e desktop próximos um do outro rapidamente

destrói a suposição de que um web design deve ter a mesma aparência em
todos os ambientes.
Ainda estamos no início do Big Bang dos dispositivos conectados. O

cenário dos dispositivos e da web de amanhã será, sem dúvida,
ainda maior e diversificado do que o de hoje. Além dos dispositivos atuais e
das tecnologias nascentes já no horizonte, a web do futuro envolverá
tecnologias e ideias que ainda não foram concebidas.
Além de todos os dispositivos com capacidade para web com os quais nos preocupamos hoje, devemos
compreender que o cenário dos dispositivos e da web está se tornando cada vez maior e mais diversificado.
Achei as três imagens anteriores um resumo extremamente útil para ajudar

clientes, colegas e partes interessadas a compreender a realidade do
cenário da web. Com esse novo entendimento, todos se tornam muito mais
receptivos à atualização de seus processos e fluxos de trabalho para criar
ótimos trabalhos para esse meio único.
Nosso trabalho é criar ótimas experiências para pessoas que usam diversos
dispositivos, tamanhos de tela, velocidades de rede, recursos de dispositivos,

recursos do navegador, tipos de entrada, fatores de forma, contextos e

preferências. Essa é sem dúvida uma tarefa hercúlea, mas todas essas variáveis
realmente ressaltam a necessidade de ir muito além da estética visual ao criar sistemas
de design de interface.
Além de criar experiências visualmente bonitas e consistentes, devemos:
ÿ Aproveite a onipresença da web criando sistemas de design acessíveis e resilientes.

Reconheça que um grande número de pessoas com um vasto espectro de
capacidades terá acesso às nossas experiências, por isso construa sistemas de
design que sejam tão inclusivos quanto possível.
ÿ Crie layouts e componentes flexíveis para que nossas interfaces tenham uma ótima
aparência e funcionem perfeitamente, independentemente da dimensão específica
do dispositivo ou do tamanho da tela.
ÿ Trate o desempenho como um princípio essencial de design e crie experiências de

carregamento rápido que respeitem os usuários e seu tempo.
ÿ Melhorar progressivamente nossas interfaces estabelecendo

experiências e, em seguida, aplicar melhorias para aproveitar os recursos exclusivos de
dispositivos e navegadores modernos.
ÿ Crie sistemas de design amigáveis ao futuro, destinados a resistir ao teste do tempo

e antecipar mudanças inevitáveis no dispositivo e no cenário da web.
É claro que há muitas outras considerações de design que deveriam ser incluídas em
nossos sistemas de design de interface (ergonomia, tipo de entrada, conformidade
com a Seção 508, legibilidade e assim por diante), mas a principal lição aqui é expandir
a definição do que constitui um bom sistema digital. design além da estética visual.
Como seria de esperar, mudanças substanciais em nossos processos precisam acontecer

para que possamos abordar adequadamente todas essas considerações de design
exclusivamente digital. Portanto, torna-se nossa responsabilidade definir as expectativas
dos clientes, colegas e partes interessadas para que todos saibam que o processo de
criação será diferente desta vez.
Morte à cachoeira
Diga-me se você já ouviu isso antes. Uma equipe tem a tarefa de fazer um site.
Assim que a poeira da reunião baixar, um UX

designer vai embora, abaixa a cabeça e eventualmente surge com um

documento PDF gigante detalhando toda a experiência. Este documento
monolítico de wireframe é repassado às partes interessadas do projeto, que o
assinam após alguns comentários e sugestões.
O designer UX então passa os wireframes para o designer visual, que acessa

o Photoshop ou Sketch para aplicar cor, tipografia e textura aos wireframes
estruturados, mas estéreis. Na reunião de revisão do projeto, as partes
interessadas sentam-se ansiosamente enquanto o projetor se prepara e o
gerente do projeto sai correndo para imprimir cópias da apresentação do
projeto para todos. O diretor de arte se posiciona na frente da sala e revela o
design. Eis o design de um site! Assim que a apresentação for concluída, a
sala rapidamente vibra com comentários e conversas. Depois que as reações
iniciais e os elogios cessam, uma das principais partes interessadas se
manifesta.
“Isso parece fantástico e acho que realmente atinge o que estamos tentando
realizar com este projeto. Mas…"
Eles expressam seu desejo de ver algo talvez com um layout alternativo,
algo que capte uma certa vibração, talvez algo que use fotografia diferente, algo
que simplesmente… estale.
Com os foodgates abertos, as outras partes interessadas percebem

subitamente que também têm opiniões e críticas construtivas que gostariam
de partilhar. Quando a reunião chega ao fim, todos já divagaram sobre sua
lista de desejos sobre o que gostariam que o projeto realizasse.
Um pouco desanimado, mas determinado a acertar, o designer visual

volta às suas ferramentas para trabalhar nas sugestões das partes interessadas.
Na próxima reunião de revisão de design, a mesma cena se repete, com as
partes interessadas expressando em partes iguais encorajamento e
desejo por mais. “Sinto que estamos quase lá. Poderíamos apenas…”
As semanas passam e as estações mudam. Os nervos se esgotam e o prazo

final paira sobre a cabeça de todos. É com urgência que homepage_v9_fnal_for-
review_FINAL_bradEdits_for-handof.psd
finalmente obtém a aprovação das partes interessadas.
O designer visual, aliviado por finalmente ter concluído seu trabalho, vai na
ponta dos pés, silenciosamente, até a entrada da Caverna do Código. Eles
deslizam o projeto aprovado por baixo da porta e, à medida que fogem,

grite: “Você consegue fazer isso em três semanas? Já estamos atrasados e sem
orçamento!”
O designer visual já desapareceu na noite quando o desenvolvedor front-end

escolhe o design do piso. Com uma rápida olhada na composição, um sentimento
estranho – alguma combinação de perplexidade, raiva e pavor – toma conta deles.
O que há de errado com o design, exatamente? Talvez sejam as sete fontes e os
nove estilos de botões exclusivos espalhados pelas composições. Talvez seja o
layout centrado na área de trabalho e impossível de executar. Talvez seja o conteúdo
gerado pelo usuário perfeito, mas improvável.
O desenvolvedor front-end tenta em vão levar suas preocupações ao grupo mais

amplo, mas é rapidamente descartado como sendo inepto ou mesquinho.
Infelizmente, é tarde demais para fazer alterações significativas no design,
especialmente porque ele já foi aprovado pelas partes interessadas.
Portanto, o desenvolvedor faz o possível para fazer limonada com as composições

estáticas de limão. Eles se esforçam para criar layouts responsivos que ainda mantêm
a integridade das composições estáticas, normalizam algumas das inconsistências
de componentes mais flagrantes, estabelecem estados de padrão (como passar
o botão, estados ativos e desativados) que não foram articulados nos designs, e
tomar algumas decisões imediatas sobre os aspectos interativos da experiência.
As discussões com os designers são tensas, mas todos percebem que precisam
resolver essas questões para concluir o projeto.
Depois de inserir o código front-end em um CMS, finalizar freneticamente o conteúdo

do site e fazer alguns testes de controle de qualidade de última hora, a equipe
finalmente lança o site. Embora ninguém diga isso em voz alta, há um toque de
decepção no ar, juntamente com a alegria e o alívio de lançar o projeto. Afinal, o
site ao vivo carece do polimento brilhante que as composições prometiam às partes
interessadas, e o atrito entre as disciplinas prejudicou alguns relacionamentos.
Espero que esta história pareça uma obra de ficção para você, mas com base
em minhas próprias experiências e conversas com inúmeras outras pessoas,
imagino que você já tenha vivenciado essa história de sofrimento em um momento ou outro.
Pode até atingir o alvo como um soco no estômago. Quer você tenha
passado por esse processo em primeira mão ou não, é importante reconhecer
que o processo em cascata no estilo Henry Ford cada vez mais não é provável que
resulte em um excelente trabalho digital.

O processo em cascata, onde as disciplinas passam o trabalho umas para as outras em ordem sequencial, provavelmente não
resultará em um ótimo trabalho digital.
O processo em cascata pode fazer sentido para impressão, arquitetura,

fabricação e outras mídias físicas, uma vez que erros e alterações são
extraordinariamente caros. Se uma equipe ignorar um erro cometido no início
do processo, pagará caro por isso mais tarde. No entanto, o mundo digital não
está limitado pelas mesmas limitações que o mundo digital.
físico. Pixels são baratos. As mudanças podem acontecer em um instante, as
hipóteses podem ser testadas rapidamente e os designs e códigos podem ser
repetidos continuamente.
O processo em cascata depende da premissa de que o trabalho deve fluir em

ordem sequencial: o trabalho do designer de UX deve ser concluído antes que
o design visual possa ser iniciado; o designer visual deve terminar seu trabalho
antes que o desenvolvimento front-end possa começar. Isso simplesmente não é verdade.
Há muito trabalho que pode e deve acontecer em paralelo. Para criar sistemas
de design de UI sólidos, devemos redefinir as expectativas dos nossos
stakeholders e deixá-los confortáveis com um processo mais confuso e
colaborativo.
O fato de o trabalho acontecer em paralelo não significa que todos estarão

armados durante todo o processo. É claro que a maior parte da pesquisa, da
arquitetura da informação e de outros aspectos elementares do design UX
tenderão a acontecer mais cedo no processo, mas esse trabalho não deve
atrasar o início dos trabalhos de outras disciplinas.
E mesmo quando a maior parte do trabalho ativo de uma pessoa estiver
concluída, ela nunca deve simplesmente desaparecer do projeto. É crucial para

cada disciplina continue a consultar as outras para garantir que sua visão
chegue ao produto final. Portanto, em vez de um processo em cascata rígido
e sequencial, um processo mais colaborativo ao longo do tempo é mais ou
menos assim:
Um fluxo de trabalho mais colaborativo envolve uma equipe interdisciplinar trabalhando em conjunto durante
todo o processo. Embora o trabalho ativo aumente e diminua, cada disciplina continua a consultar os outros
membros da equipe para garantir que seus insights estejam presentes no trabalho final.
Desenvolvimento é design
Quando um empregador anterior descobriu que eu escrevia HTML, CSS

e JavaScript de apresentação, eles me levaram para conversar com os
engenheiros e desenvolvedores de back-end. Em pouco tempo me perguntaram:
“Ei, Brad. Quanto tempo esse middleware levará para ser construído?” e
“Você pode normalizar este banco de dados bem rápido?”
O problema é o seguinte: nunca tive aulas de ciência da computação na

minha vida e passei minha carreira no ensino médio na sala de artes.
Basta dizer que esses pedidos me deixaram extremamente desconfortável.
Há um mal-entendido fundamental de que toda codificação é uma

programação ultra-nerd, o que simplesmente não é o caso. HTML não é
uma linguagem de programação. CSS não é uma linguagem de programação.
Mas como HTML e CSS ainda são códigos, o desenvolvimento front-end é

frequentemente colocados no mesmo intervalo que Python, Java, PHP, Ruby, C++ e
outras linguagens de programação. Esse mal-entendido tende a causar a muitos
desenvolvedores front-end, inclusive eu, uma grave crise de identidade.
Organizacionalmente, muitas vezes há uma enorme divisão entre designers e

desenvolvedores (ou marketing e TI, ou criação e engenharia, ou alguns outros
rótulos divisivos). Designers e desenvolvedores muitas vezes sentam-se em andares
diferentes, em edifícios completamente diferentes, em cidades diferentes e, às vezes,
até em países diferentes, em continentes diferentes.
Embora parte dessa separação organizacional possa ser justificada, criar
uma divisão entre designers e desenvolvedores front-end é uma ideia
absolutamente terrível.
O fato é que HTML, CSS e JavaScript de apresentação constroem interfaces de

usuário – sim, as mesmas interfaces de usuário que esses designers estão
criando meticulosamente em ferramentas como Photoshop e Sketch. Para que
as equipes construam juntas sistemas de design de interface de usuário bem-
sucedidos, é crucial tratar o desenvolvimento front-end como uma parte central
do processo de design.
Quando você mostra às partes interessadas apenas imagens estáticas de sites,

elas naturalmente só podem comentar e assinar fotos de sites.
Isso define as expectativas erradas. Mas ao colocar o design no navegador o
mais rápido possível, você confronta as partes interessadas com a realidade do
meio final muito mais cedo no processo. Trabalhar em HTML, CSS e JavaScript de
apresentação permite que as equipes não apenas criem designs esteticamente
bonitos, mas também demonstrem considerações de design exclusivamente digitais,
como:
ÿ flexibilidade
ÿ impacto da rede
ÿ interação
movimento
e ergonomia
ÿ renderização de cores e texto
ÿ densidade de pixels

ÿ desempenho de rolagem
ÿ peculiaridades do dispositivo e do navegador
ÿ preferências do usuário
Crucialmente, entrar no navegador mais rápido também dá início à criação dos

padrões que constituirão o sistema de design vivo e vibrante. Mais sobre isso
daqui a pouco.
Isso não quer dizer que as equipes devam projetar inteiramente no navegador.
Como qualquer coisa, trata-se de usar as ferramentas certas no momento certo para
articular as coisas certas. Ter o design representado no navegador , além de
outros artefatos de design, dá às equipes a capacidade de pintar uma imagem mais
rica e realista da UI que estão criando.
As equipes podem demonstrar uma ideia de design com foco estético como uma
imagem estática e, simultaneamente, demonstrar um protótipo funcional dessa
mesma ideia no navegador.
Um processo iterativo iterativo iterativo

Acredito que um processo de design digital bem-sucedido é bastante semelhante
à escultura subtrativa em pedra. No início do processo de escultura, o artista e
seu patrono têm uma ideia geral do que está sendo criado, mas essa visão não
será totalmente concretizada até que a escultura esteja concluída.
O escultor começa com uma placa gigante de rocha e começa a desbastá-la. Uma
forma grosseira começa a se formar após a primeira passagem, e a forma se
torna mais pronunciada a cada passagem subsequente. Depois de algumas rodadas
de golpes na rocha, fica claro que o tema do escultor é uma forma humana.
Com a forma geral da escultura esboçada, o artista começa então a se concentrar em

seções específicas da peça. Por exemplo, eles podem começar com o rosto,
aproximando-se para esculpir o formato dos olhos, nariz e boca. Depois de várias
passagens, eles passam para os braços e começam a detalhar as pernas. Em
intervalos regulares, o artista recua para ver como o seu trabalho detalhado afeta a
escultura geral. Este processo continua até que a escultura esteja completa e todos
fiquem satisfeitos com o resultado.
Mais uma vez, penso que a escultura subtrativa em pedra é uma ótima analogia
para um processo digital bem-sucedido, embora, ao contrário da escultura, tenhamos
o poder de desfazer!

Um processo digital iterativo é semelhante à escultura subtrativa em pedra, onde a fidelidade é construída ao longo
de muitas iterações. Crédito da imagem: Mike Beauregard no Flickr
É essencial deixar as partes interessadas confortáveis com a revisão dos

trabalhos em andamento, em vez de designs e códigos totalmente elaborados.
Como mencionei no capítulo 1, hoje em dia todas as organizações querem se
tornar mais ágeis, e a iteração é uma parte fundamental para ser ágil. É mais
importante dar passos na direção certa do que esgotar uma tonelada de esforço
pintando imagens irrealistas do que você deseja que a peça final seja. Um
sistema de design de som não sai de uma linha de montagem, mas é
esculpido em loops iterativos, construindo fidelidade à medida que o projeto
avança.
Se tudo isso parece um pouco confuso, é porque é! Para consternação de alguns

gerentes de projeto, o processo de design não se enquadra perfeitamente nas
fronteiras rígidas das planilhas do Excel e dos gráficos de Gantt. A verdadeira
colaboração entre disciplinas é confusa e caótica, e isso não é uma coisa ruim. A
comunicação constante, os ciclos de feedback estreitos e a verdadeira
colaboração tornam-se, portanto, a cola que mantém

o processo juntos. Faça com que toda a sua equipe se comprometa com uma
conversa honesta e uma colaboração genuína, e os detalhes do seu processo se
encaixarão.
As expectativas de todos estão devidamente definidas? Bom! Agora vamos arregaçar

as mangas e começar a trabalhar estabelecendo nosso sistema de design.
Estabelecendo direção
As equipes geralmente estão ansiosas para começar o trabalho divertido de design

e desenvolvimento de alta fidelidade, e os clientes estão ansiosos para ver e reagir a
esse trabalho detalhado. No entanto, isso leva a distrações, suposições e todas as
expectativas equivocadas mencionadas acima. É essencial chegar a um acordo
sobre uma direção geral de design e traçar os traços gerais primeiro, antes de
passar para o design e desenvolvimento de alta fidelidade. Isto requer contenção e
gestão de expectativas, mas resulta numa tomada de decisões mais focada e num
trabalho mais realista.
Como é esse trabalho lo-f? Vamos dar uma olhada em algumas técnicas que
designers de UX, designers visuais e desenvolvedores front-end podem
usar para começar a elaborar uma direção geral forte para um sistema de
design de UI.
Estabelecendo conteúdo e padrões de exibição
Há muito trabalho estratégico e de pesquisa inicial que pode e deve acontecer

no início de um projeto. Designers de experiência do usuário
(conhecidos por outros nomes, como designers de informação, arquitetos de informação,
designers de interação e assim por diante) são responsáveis por sintetizar
todas essas informações vitais e traduzi-las em uma interface de usuário que atenda
aos objetivos de negócios e de usuário do projeto.
Em um processo tradicional em cascata, muitos designers de UX realizaram essa

tarefa gerando wireframes de alta fidelidade que documentam cada tela de
toda a experiência do usuário. Esses documentos wireframe, repletos de
retângulos pretos e anotações, especificam os detalhes do que a interface
realizará e são usados para obter a adesão das partes interessadas. Por mais
completos que esses documentos tendam a ser, eles não retratam o quadro
completo e muitas vezes fazem suposições perigosas sobre o layout visual e a
funcionalidade técnica.

Em vez de pular direto para esses documentos de alta fidelidade, é melhor

começar com esboços lo-f que estabelecem o que aparece em uma tela
específica e em que ordem geral. O estabelecimento da arquitetura básica de
informações da experiência pode ser realizado com uma simples lista com
marcadores e uma conversa. Para um projeto que fiz para o Banco Alimentar
Comunitário da Grande Pittsburgh, comecei desenhando a arquitetura básica da
informação para uma página de um site.
Wireframes HTML básicos para a página inicial do Greater Pittsburgh Community Food Bank.
Ninguém em sã consciência confundiria esta página bloqueada em tons de cinza como

completa, mas ela fornece informações mais do que suficientes para ter conversas
importantes sobre a estrutura e hierarquia da página.
Criando wireframes lo-f primeiro para dispositivos móveis significa usar as restrições
das telas pequenas para forçar a equipe a se concentrar no conteúdo principal e
hierarquia. Agora você pode perguntar: “Temos as coisas certas nesta tela?” “Eles
estão na ordem geral correta?”

Esses wireframes em blocos de tons de cinza ajudam a estabelecer os

padrões de conteúdo necessários para a tela, mas os designers de UX também
podem articular alguns padrões de UI em todo o site que eles prevêem usar
para exibir esses padrões de conteúdo. Para o redesenho do TechCrunch, a
designer Jennifer Brook definiu alguns padrões de UI para todo o site que
poderiam ser usados em qualquer lugar:
Para a reformulação do site TechCrunch, Jennifer Brook definiu padrões de exibição gestuais em
todo o site, que não fazem suposições sobre estética ou funcionalidade.
Pela imagem acima, você pode perceber que o componente “ilha em destaque”
mostrará o conteúdo de alguma forma. Observe a natureza gestual deste
esboço e como ele não faz nenhuma suposição específica sobre
layout ou funcionalidade. Os detalhes sobre a aparência e o funcionamento
desse padrão virão mais tarde, mas no início do projeto é útil simplesmente defini-
lo e articular onde ele poderá ser usado.
Como descobri em projetos subsequentes, o conteúdo e os padrões de

exibição podem ser efetivamente comunicados em um formato ainda mais simples:
a planilha simples.

Uma planilha simples pode articular qual conteúdo e padrões de exibição aparecem em uma determinada página, ao mesmo
tempo que descreve sua ordem e finalidade.
Com algumas colunas simples da planilha, podemos articular quais padrões de

exibição devem ser incluídos em um determinado modelo e quais padrões de
conteúdo eles conterão. Mais importante ainda, somos capazes de articular a
hierarquia relativa de cada padrão e o papel que ele desempenha na tela. Se
você ler a coluna mais à esquerda verticalmente, estará efetivamente olhando
para a visão móvel do que a IU poderia ser.
“Que conteúdo e padrões de exibição aparecem nesta página? E em que ordem

geral?” são perguntas cruciais a serem feitas, e as técnicas que acabamos de
descrever podem ajudar os designers a discuti-las de maneira eficaz, sem fazer
qualquer layout ou suposições técnicas.
Estabelecendo direção visual
O trabalho de um designer visual é criar uma linguagem estética e aplicá-la à

interface do usuário de uma forma que se alinhe aos objetivos do projeto.
Para fazer isso, é essencial que um designer visual descubra os valores estéticos
das partes interessadas.
Historicamente, os designers visuais fizeram isso criando composições

completas – muitas vezes muitas composições – para sentir os valores estéticos
da organização. Jogue algumas composições contra a parede e veja o que
gruda. Como você pode imaginar, gerar uma série de composições do zero
exige muito tempo e esforço e, infelizmente, grande parte desse trabalho acaba
na sala de edição. Deve haver uma maneira mais eficiente.

Acontece que há um caminho melhor a seguir para chegar a valores

estéticos sem ter que fazer muito trabalho de design inicial.
Vamos falar sobre algumas das táticas para fazer isso acontecer.
O teste intestinal de 20 segundos
Um exercício fantástico para estabelecer rapidamente valores estéticos é o

teste intestinal de 20 segundos. Normalmente realizado como parte da
reunião inicial do projeto, o exercício envolve mostrar às partes interessadas
alguns sites pertinentes (cerca de vinte a trinta deles) durante vinte
segundos cada. Os sites que você escolher devem ser uma mistura
saudável de sites específicos do setor e outros sites visualmente
interessantes de outros setores. Para maior credibilidade, você pode fazer
photoshop no logotipo do seu cliente no lugar do logotipo real do site.
Para cada site apresentado, cada pessoa vota em uma escala de 1 a 10,
onde a pontuação 1 significa “Se este fosse o nosso site eu largaria meu
emprego e choraria até dormir”, enquanto a pontuação 10 significa “Se isso
fosse nosso site eu ficaria absolutamente extasiado!” Instrua os participantes a
considerarem as propriedades visuais que consideram interessantes, como
tipografia, cor, densidade, layout, estilo de ilustração e vibração geral.
Para o início da reformulação do site do Pittsburgh Food Bank, mostramos às partes interessadas uma
variedade de sites relevantes por vinte segundos cada. Os participantes votaram em quão felizes ficariam se
aquele site específico fosse deles. Depois discutimos os resultados.

Quando o exercício estiver concluído, calcule rapidamente as pontuações e volte

ao grupo para discutir os resultados. Converse sobre os sites que receberam as
cinco pontuações mais baixas, as cinco pontuações mais altas e as pontuações
mais controversas (sites que algumas pessoas classificaram como muito altas
e outras como muito baixas). Os participantes devem explicar porque se
sentiram atraídos ou repelidos por um determinado site e trabalhar as diferenças
de opinião com o grupo.
Este exercício expõe as partes interessadas a uma variedade de

direções estéticas no início do processo, permite-lhes trabalhar com
diferenças de gosto e (com alguma sorte) ajuda a chegar a alguns valores estéticos
partilhados. O designer visual pode então agarrar-se a esses insights e
começar a traduzir esses valores estéticos em uma direção visual para o projeto.
Blocos de estilo
Mais uma vez, o primeiro instinto dos designers visuais é muitas vezes ir
direto para a criação de composições completas para articular uma direção
estética para o projeto. Esse trabalho de alta fidelidade é certamente tangível,
mas também desperdiça muito tempo e esforço se as compensações não
agradarem as partes interessadas. Além disso, a criação de composições de
alta fidelidade geralmente faz grandes suposições sobre a viabilidade técnica, o
que leva a expectativas irrealistas e relacionamentos antagônicos com
desenvolvedores front-end.
É essencial estabelecer uma direção visual sólida para o projeto, então como
um designer visual faz isso sem gastar muito tempo em composições iniciais
de alta fidelidade? Essa é a pergunta que a designer Samantha Warren
respondeu ao criar azulejos de estilo, um resultado que é mais tangível do que um
painel de humor, mas não tão de alta fidelidade quanto uma composição
totalmente pronta.

Para o projeto de reformulação do site da Entertainment Weekly, os designers visuais usaram blocos de estilo para
explorar cores, tipos, texturas e muito mais.
Blocos de estilo (junto com suas contrapartes no navegador, protótipos de estilo )

permitem que os designers explorem cores, tipografia, textura, ícones e outros aspectos da
atmosfera do design sem fazer suposições sobre o layout ou se preocupar com o
acabamento. Eles podem ser projetados com muito mais rapidez porque não estão
sobrecarregados pelas expectativas de composições de alta fidelidade, o que significa
que o feedback e a discussão podem acontecer mais cedo.

Os blocos de estilo facilitam a conversa para descobrir o que as partes

interessadas valorizam e o que não valorizam. “Este estilo de ladrilho combina melhor
com você do que este? Por que?" “Por que essa paleta de cores não combina com
você?” “O que você gosta nesse tipo de letra?” Você pode ter conversas
importantes sobre design estético sem precisar criar composições completas.
Crucialmente, os blocos de estilo também reforçam o pensamento

baseado em padrões, educando as partes interessadas sobre sistemas de
design em vez de páginas. A apresentação de amostras de cores, exemplos
de tipos e texturas expõe as partes interessadas aos ingredientes que
sustentarão qualquer implementação do sistema de design.
Colagens de elementos
Embora os ladrilhos de estilo sejam ótimos para explorar a atmosfera do design, eles
ainda são um pouco abstratos. Para ter uma ideia de como esses ingredientes de
design serão aplicados a uma interface, é importante passar rapidamente para algo
um pouco mais tangível do que um bloco de estilo. Mas isso significa que os
designers visuais precisam pular dos blocos de estilo direto para as composições
completas? Não necessariamente.
Em algum lugar entre blocos de estilo e colagens completas de elementos ao

vivo , que são coleções de explorações de design de componentes de UI.
As colagens de elementos fornecem um playground para os designers aplicarem a
atmosfera de design aos elementos reais da interface, mas ainda assim livres
de layout e apresentação altamente refinada.

Uma colagem de elementos para o redesenho da Entertainment Weekly aplicou cor, tipografia e
textura aos elementos reais da interface. Essas colagens possibilitaram conversas importantes sobre
o rumo estético do projeto.
Assim como os azulejos de estilo, as colagens de elementos têm como objetivo facilitar a discussão
sobre a direção estética do projeto. Está muito claro que essas colagens não são um site real,
mas as partes interessadas ainda podem ter uma ideia de como o site poderia ser. A conversa
sobre essas colagens de elementos pode dar aos designers visuais mais ideias e orientações
sobre o próximo passo a seguir no design e, devido à sua natureza lo-f, os designers podem iterar e
desenvolver ideias rapidamente.
Sem dúvida existem outras táticas para estabelecer uma direção estética para seus projetos,
e as técnicas que você decide empregar variam de projeto para projeto. Mas o segredo é
pintar alguns traços mais amplos antes de gastar muito tempo e esforço em um trabalho de design
altamente detalhado. O envolvimento em conversas com as partes interessadas nesta fase
exploratória cria um processo mais inclusivo, que é muito preferível a um processo em que as
partes interessadas simplesmente aprovam ou desaprovam os resultados do design.

Chef de preparação de front-end
Como discutimos anteriormente, os desenvolvedores front-end são frequentemente

relegados a máquinas de produção rudimentares que são trazidas para o projeto
somente depois que todas as decisões de design são tomadas. Esse processo arcaico
mantém as disciplinas fora de sincronia entre si e impede que as equipes trabalhem juntas
de maneira significativa. Este é um grande erro. Incluir o desenvolvimento front-
end como uma parte crítica do processo de design requer mudanças tanto na estrutura
do projeto quanto nas mentalidades dos membros da equipe.
No ramo de restaurantes, um papel importante, mas desconhecido, é o do chef

preparador. Um chef preparador corta vegetais, marina a carne e prepara saladas
para o trabalho do dia seguinte. Ao preparar os ingredientes com antecedência, o pessoal
da cozinha pode se concentrar na colaboração e na culinária, em vez de tarefas servis.
Sem o trabalho inicial do chef preparador, o fluxo dos chefs principais seria interrompido e
o ritmo acelerado da cozinha seria paralisado.
Um chef preparador corta vegetais, marina a carne, faz saladas e prepara outros ingredientes para que a equipe
principal da cozinha possa se concentrar no preparo das refeições e na colaboração.

Os desenvolvedores front-end precisam ser os chefs preparatórios do processo de

web design. Se os desenvolvedores não estiverem codificando desde o primeiro
dia do projeto, há algo errado com o processo. “Mas Brad”, posso ouvir você
dizendo, “como posso começar a programar se não sei o que devo codificar?”
Acredite em mim, há muito trabalho inicial a ser feito sem saber nada sobre o design de
informação ou a direção estética do projeto.
Além de configurar o ambiente de desenvolvimento (como preparar repositórios
Git, servidores de desenvolvimento, CMSes e ferramentas de desenvolvimento), os
desenvolvedores podem mergulhar no código e começar a marcar padrões.
Mas o que você deveria marcar se não sabe nada sobre design? Isso depende do tipo de
projeto em que você está trabalhando.
Você está criando um site de comércio eletrônico? Você pode configurar a pesquisa
no site, uma tabela de carrinho de compras, uma página de detalhes do produto
de espaço reservado, a página inicial e páginas de checkout. Fazendo um serviço
online? Comece a marcar os formulários de inscrição e login, o fluxo de senha esquecida
e o painel. E, claro, a maioria dos sites terá cabeçalho, rodapé e área de conteúdo
principal. Configure modelos de shell e escreva marcações básicas para padrões que você
pretende usar. Esta marcação será inicialmente rudimentar, mas fornece um ponto de
partida crucial para colaboração e iteração.
Esse trabalho de preparação de front-end libera tempo dos desenvolvedores

para colaborar com os designers, em vez de trabalhar após a conclusão do
design. Com a marcação básica implementada, os desenvolvedores podem
trabalhar com designers para ajudar a validar decisões de design de UX por meio de
conversas e protótipos funcionais. Eles podem ajudar os designers visuais a
entender melhor a ordem de origem e o layout da web, e podem produzir rapidamente
uma base de código incipiente que eventualmente evoluirá para o produto final.
Pare, colabore e ouça

Vamos revisar rapidamente como é estabelecer a direção do design em todas as
disciplinas:
ÿ Os designers de UX podem criar esboços lo-f para estabelecer

arquitetura de informação e alguns padrões de UI previstos.
ÿ Os designers visuais podem reunir os valores estéticos das equipes

conduzindo um exercício de teste de 20 segundos e, em seguida, crie blocos de
estilo e colagens de elementos para explorar as direções iniciais do design.

ÿ Os desenvolvedores front-end podem configurar dependências do projeto, criar

modelos básicos e escrever marcações estruturais para padrões que a
equipe prevê usar no projeto.
Este trabalho pode acontecer simultaneamente, mas não deve acontecer

isoladamente. Claro, será necessário algum tempo inicial de reflexão para que
cada disciplina seja configurada, mas todos os membros da equipe devem
estar plenamente conscientes das explorações de cada disciplina, antecipando
o trabalho conjunto para desenvolver essas ideias.
As ideias foram feitas para serem feias.
-Jason Santa Maria
Nesta fase inicial, é importante enfatizar a importância da exploração, da

brincadeira e da geração de ideias. A natureza lo-f das técnicas que
acabamos de discutir ajuda a incentivar essa exploração, permitindo que
os membros da equipe busquem ideias que os entusiasmem.
Às vezes, essas ideias podem ser melhor articuladas como um esboço de
guardanapo, um protótipo no CodePen, uma exploração visual no Sketch, uma
ligação rápida no Balsamiq, um conceito de movimento no After Effects ou alguma
combinação de mídia e ferramentas. A questão é que a equipe gere ideias
e resolva problemas, e não imponha uma ordem rígida de operações. Ao
abordar esta exploração do design de forma interdisciplinar, as equipes podem
encontrar equilíbrio entre estética, viabilidade técnica, usabilidade e
funcionalidade.
Arregaçando as mangas
Com uma direção geral de design estabelecida, a equipe pode arregaçar as

mangas para construir a interface e seu sistema de design subjacente.
Mas como as equipes transformam um vago senso de direção em um sistema
de design bonito, funcional, utilizável e completo?
Do conceito à conclusão
Transformar explorações em padrões acabados é um processo confuso e

imperfeito. Isso não deve ser nenhuma surpresa para você neste ponto do livro.

Para o projeto TechCrunch, Dan Mall aproveitou as conversas iniciais de design

da equipe para criar uma exploração visual para o cabeçalho do site. Essa parte
da interface foi um ponto de partida lógico, já que o cabeçalho é um dos elementos
mais proeminentes e de marca da página. Depois de um pouco de trabalho,
atendemos uma ligação para discutir a exploração com o cliente.
Dan Mall criou uma colagem de elementos para explorar uma direção estética para o cabeçalho global.
Embora esse artefato de design fosse uma simples exploração em

andamento, pudemos ter conversas importantes sobre a estética, a hierarquia e a
funcionalidade sugerida do cabeçalho.
Como o cabeçalho foi apresentado sem contexto, pudemos discutir as questões
relativas ao cabeçalho sem que o foco das partes interessadas se desviasse para
outros elementos da página.
Embora o cliente não soubesse disso, eu estava desenvolvendo uma versão HTML
funcional do cabeçalho nos bastidores do Pattern Lab.
Usando a exploração de Dan como referência, criei uma versão HTML do cabeçalho global no Pattern Lab.
Este protótipo em escala de cinza nos ajudou a demonstrar a interatividade e como o cabeçalho se adaptaria
em todo o espectro de resolução.

Este protótipo em escala de cinza permitiu demonstrar interatividade e capacidade de

resposta, o que gerou ainda mais discussão. Coletivamente, propusemos alterações no
layout e na funcionalidade do cabeçalho, e pude fazer alterações usando as ferramentas
de desenvolvimento do navegador durante a chamada. De repente, toda a equipe e as
partes interessadas estavam participando ativamente do processo de design!
Com a contribuição das partes interessadas e da equipe, iteramos no padrão do

cabeçalho para aprimorar o layout, a IA, os detalhes estéticos e a funcionalidade para
chegar à solução que finalmente lançamos.
O cabeçalho com o qual lançamos foi o culminar de muitas conversas e decisões sobre o
conteúdo, design e funcionalidade do padrão.
Obviamente, o padrão de cabeçalho não existe no vácuo. No Pattern Lab, o cabeçalho

foi incluído em todos os modelos usando o padrão include do Moustache que
discutimos no capítulo 3.
Isso nos permitiu visualizar o cabeçalho dentro do contexto do restante
as páginas, por mais incompletas que fossem inicialmente. Portanto, embora nos
concentrássemos no design de um padrão específico, levamos simultaneamente em
consideração o contexto de onde esse padrão seria empregado.

Num processo mais iterativo, haverá casos em que alguns padrões serão mais desenvolvidos do que
outros. Ver uma página parcialmente concluída pode parecer incomum fora do contexto, mas a
comunicação entre a equipe e as partes interessadas deve aliviar a confusão.
Inicialmente, os designs do navegador tendem a parecer, na melhor das hipóteses, grosseiros, o que
é OK. A intenção é delinear a arquitetura de informações básicas do modelo no navegador, definir padrões,
conectar esses padrões usando inclusões e iniciar a marcação geral dos padrões. Com esse trabalho
implementado, a equipe pode começar coletivamente a definir padrões específicos e refinar a

estrutura geral.
Ver esses protótipos parcialmente projetados pode parecer incomum para aqueles acostumados com
produtos de design mais tradicionais e com pixels perfeitos.
Mas é muito mais importante comunicar o progresso do que uma falsa sensação de perfeição, e é por
isso que as atualizações contínuas são preferíveis às grandes revelações.

O papel dos comps na era pós-PSD
Até este ponto estivemos falando sobre estabelecer uma direção estética geral e
então projetar alguns padrões para experimentar a aplicação dessa direção estética.
Essas táticas relativamente baixas permitem que as equipes explorem livremente,
iterem rapidamente e obtenham feedback mais cedo.
Mas nunca esquecerei o feedback dos clientes que recebemos sobre o primeiro
projeto baseado em padrões em que trabalhei: “Essas colagens de elementos
parecem ótimas, mas é como se você estivesse me pedindo para comentar sobre o
quão bonito é um rosto, mostrando-me o nariz. .”
Se você chegou a esse ponto do seu processo, parabéns!

Feedback como esse significa que eles estão ansiosos por mais, então agora que
você capturou uma direção estética geral, você pode colocar essas explorações
no contexto com segurança. Isso provavelmente envolve a criação de composições
estáticas completas.
Ouça a conversa sobre “projetar no navegador” e você sem dúvida ouvirá que as
composições do Photoshop são a encarnação do diabo. O que, claro, não é verdade.
Ao longo deste livro discutimos a importância de decompor as coisas em seus
elementos atômicos e, ao mesmo tempo, construir um todo coeso. As
composições estáticas são eficazes para pintar uma imagem completa de
como seria a interface do usuário. O truque é saber quando pintar essas imagens
completas e saber quanto tempo permanecer em documentos de design estáticos.

Dan Mall criou uma composição completa para demonstrar a aparência de um modelo de artigo em destaque
para o TechCrunch. Este artefato foi usado para mostrar o sistema de design no contexto e obter
aprovação para o design abrangente. As revisões de design subsequentes seriam tratadas no navegador.

Para o projeto TechCrunch, criamos uma composição para o modelo de artigo

somente depois que o cliente se sentiu bem com nossas explorações de colagem
de elementos. Criar composições completas exige muito esforço, e é por isso que
estabelecemos a direção do design primeiro para mitigar o risco de todo esse
esforço de compensação total ir direto para o lixo se erramos totalmente.
Comps, como qualquer outro artefato de design, são usados para facilitar
uma conversa com as partes interessadas do projeto. Se o feedback for: “Parece
que está tudo errado”, então voltamos à prancheta para criar uma nova composição.
Mas se o feedback deles sugerir: “Podemos mudar isso daqui para aqui? Podemos
adicionar uma borda cinza ao redor do texto do artigo?
Podemos aumentar o tamanho desta imagem?” isso é um sinal de que a direção
geral está em boa forma e que esses problemas relativamente menores podem ser
resolvidos no navegador.
Iteração no navegador
As composições estáticas podem ser ótimas para definir a direção estética geral de um modelo, mas
os usuários acabarão visualizando e interagindo com a experiência em um navegador. É por isso
que os designs devem ser rapidamente traduzidos para o ambiente final e iterados nele.
Trabalhar no navegador permite que as equipes resolvam problemas de

layout em todo o espectro de resolução, projetem em torno de dados
dinâmicos (como comprimentos variáveis de caracteres, tamanhos de imagem
e outros conteúdos dinâmicos), demonstrem interação e animação,
avaliem o desempenho, levem em consideração a ergonomia e confrontem
considerações técnicas (como densidade de pixels, renderização de texto,
desempenho de rolagem e peculiaridades do navegador). As composições de
projeto estático não podem lidar com todas essas considerações; portanto, devem ser
tratadas apenas como hipóteses, em vez de especificações fixas. Somente quando
transferida para o navegador qualquer hipótese de design pode ser
verdadeiramente confirmada ou rejeitada.
Vamos mudar a frase “projetar no navegador”

para “decidir no navegador”.
-Dan Mall

Assim que os designs estiverem no navegador, eles deverão

permanecer no navegador. Nesta fase do processo, o ponto de produção
muda para os membros da equipe adeptos da elaboração de HTML, CSS
e JavaScript de apresentação. Os padrões devem ser criados,
estilizados e inseridos onde quer que sejam necessários. Os designers
podem reagir a essas implementações no navegador e criar composições
pontuais em ferramentas estáticas para ajudar a eliminar rugas
responsivas no nível do organismo. Esse vaivém entre ferramentas
estáticas e no navegador estabelece um ciclo saudável entre design e
desenvolvimento, onde o código front-end se torna mais sólido e estável a cada ciclo iterativo.
Esta ilustração de Trent Walton da Paravel articula perfeitamente um processo de design e

desenvolvimento mais iterativo. Ao colocar os designs no navegador mais cedo, as equipes podem iterar
no design e abordar as muitas considerações que só podem ser tratadas quando o design estiver no navegador.
A beleza de um fluxo de trabalho baseado em padrão é que, à

medida que cada padrão se torna mais completo, qualquer
modelo que inclua o padrão também ficará mais completo.
Isso significa que o nível de esforço para criar novos modelos diminui
drasticamente ao longo do projeto, até que a criação de um novo modelo
envolva principalmente unir padrões existentes.

Trazê-lo em casa
O sistema de design está tomando forma e a equipe está cozinhando a gás

para levar o projeto para casa. Neste estágio, os padrões de UI estão
bem estabelecidos, a equipe está tomando algumas medidas finais para
aprimorar tudo e se preparar para o lançamento.
Os designers de UX estão trabalhando duro no protótipo para garantir

que os fluxos e interações sejam todos lógicos e intuitivos. Os designers visuais
estão examinando a interface e propondo ajustes de design na IU para
aprimorar o design. Os desenvolvedores front-end estão testando a
experiência em vários navegadores e dispositivos, ao mesmo tempo
que abordam o feedback do design. Os desenvolvedores back-end estão
trabalhando arduamente para integrar a UI front-end ao CMS (falaremos mais
sobre o relacionamento entre front-end e back-end no capítulo 5).
E, claro, os clientes e as partes interessadas estão a fazer exigências de última
hora – quero dizer, sugestões – sobre o design e o conteúdo.
Toda a equipe está contribuindo com documentação para o guia de estilo,
limpando os padrões da biblioteca de padrões e trabalhando duro para colocar o
site em prática.
Então – aparentemente em um piscar de olhos – o site e o sistema

de design que o acompanha são lançados. Champanhe é servido,
cumprimentos são trocados e, claro, bugs pós-lançamento são eliminados.
Os usuários visitam o novo site para encontrar uma experiência bonita,
funcional, consistente e coesa que, sem dúvida, os faz chorar de alegria.
Missão cumprida.
O que começou como uma placa gigante de rocha agora é uma

escultura cuidadosamente polida, graças a muito trabalho duro, colaboração
genuína, comunicação constante e muita iteração. Além disso, além de um
site totalmente novo, a equipe deixa para trás um sistema de UI flexível e
deliberado, agrupado em um belo guia de estilo.
Este capítulo explorou tudo o que é necessário para criar um sistema de design
de UI eficaz. No próximo capítulo, discutiremos como garantir que o design
system continue a ser bem-sucedido no longo prazo.

capítulo 5
Manutenção
Sistemas de Projeto
Fazendo com que os sistemas de design resistam ao
teste do tempo
E eles criaram um sistema de design, entregaram um guia de estilo e viveram

felizes para sempre. Certo?
Não exatamente.
Há um risco muito real de que um guia de estilo acabe na lixeira junto com
todos os PSDs, PDFs e outros artefatos estáticos do processo de
design. Apesar das melhores intenções de todos, todo o tempo e esforço
investidos na criação de um sistema de design e guia de estilo bem pensados
podem ir direto para o ralo.
Como pode ser?
Um guia de estilo é um artefato do processo de design. Um sistema de design é um

produto vivo e financiado, com um roteiro e uma lista de pendências, servindo a um
ecossistema.
-Nathan Curtis
Um artefato é algo que você encontraria em uma escavação arqueológica

ou em um museu, enquanto um sistema é uma entidade viva que respira. Um estilo
CAPÍTULO 5 / MANUTENÇÃO DE SISTEMAS DE PROJETO 143

guide pode fornecer documentação e servir como um recurso útil, mas a simples
existência de um guia de estilo não garante o sucesso a longo prazo do sistema
de design subjacente. Um sistema de design precisa de manutenção contínua,
suporte e cuidado amoroso para que realmente prospere.
Mudando de idéia, mais uma vez
Já discutimos a importância de redefinir as expectativas de todos para estabelecer

um fluxo de trabalho mais colaborativo e orientado por padrões. Para salvar
nossos guias de estilo das entranhas da lata de lixo, precisamos mais uma vez
reprogramar fundamentalmente o cérebro das pessoas.
O que estamos fazendo de novo?
Achamos que apenas projetamos e construímos sites e aplicativos. E isso é verdade

na maior parte. Afinal, é para isso que nossos clientes nos pagam, e os produtos que
criamos são os veículos que geram dinheiro e sucesso para nossas organizações.
Parece natural focar nas implementações finais e não no sistema subjacente. Os
produtos ativos continuam sendo o foco principal da atenção de todos, enquanto
qualquer biblioteca de padrões existe como uma ramificação que simplesmente
fornece documentação útil.
O problema com essa mentalidade é que você quase pode ver aquela biblioteca
de padrões se quebrando e deslizando para o abismo. Uma vez que a biblioteca
de padrões deixa de refletir o estado atual dos produtos

serve, torna-se obsoleto. E quando a biblioteca de padrões que gerencia

o sistema de design não é mais precisa, o processo de manutenção do site
se transforma em um punhado de hotfxes e alterações ad hoc, arruinando toda a
consideração necessária para criar o sistema de design original.
Para nos prepararmos para o sucesso a longo prazo, temos de mudar

fundamentalmente a nossa perspectiva em torno do que estamos realmente
a criar. Em vez de pensar nas aplicações finais como nossa única
responsabilidade, devemos reconhecer que o sistema de design é o que sustenta
nossos produtos finais e bibliotecas de padrões.
Essa mentalidade de “sistema de design em primeiro lugar” insere um pouco de

atrito no processo de manutenção, e esse atrito pode ser amigável. Isso nos
força a dar um passo atrás e considerar como quaisquer melhorias, solicitações
de clientes, acréscimos de recursos e iterações afetam o sistema como um
todo, e não apenas uma parte de todo o ecossistema.
Digamos que você esteja trabalhando em um site de comércio eletrônico e

execute um teste que descobre que um menu suspenso com estilo personalizado
na página de detalhes do produto não está funcionando tão bem quanto o menu
suspenso padrão do navegador. Um curso de ação é simplesmente remover o
menu suspenso com estilo personalizado daquela página específica e
encerrar o dia. No entanto, considerar todo o sistema de design, em vez de
apenas a página de detalhes do produto, pode fazer com que você dê um
passo para trás e se pergunte: “Se este menu suspenso personalizado
não está funcionando bem aqui, talvez não esteja funcionando bem em outro
lugar”. Depois de aprofundar a questão, você descobre que o melhor curso de ação é globalmente

modifique o padrão suspenso no sistema de design para remover o estilo

personalizado. Agora, em qualquer lugar que o padrão suspenso aparecer
refletirá essas alterações e provavelmente verá melhorias de desempenho
semelhantes.
Este é apenas um exemplo de como o pensamento do sistema de design

pode levar a mudanças mais amplas e mais ponderadas. Comportamentos
quebrados e oportunidades para melhorar a UI serão muitas vezes
realizados no nível do aplicativo , mas essas mudanças geralmente devem ser
implementadas no nível do sistema . Adicionar esse atrito amigável ao seu fluxo
de trabalho garante que as melhorias sejam compartilhadas por todo o
ecossistema e evita que o sistema seja corroído por uma série de mudanças únicas.
Feito e feito
Outra expectativa que devemos rever é a nossa definição de feito.
Criar coisas para impressão e outras mídias físicas envolve criar objetos permanentes
e tangíveis. Esse sentimento de finalidade simplesmente não existe no mundo
digital, o que significa que a mudança pode acontecer com muito menos esforço
e atrito do que outras mídias. Clientes, colegas e partes interessadas devem
abraçar a natureza flexível do mundo digital para criar sistemas de design vivos
que se adaptem à natureza em constante mudança do meio, às
necessidades do usuário e às necessidades do negócio.
Esta mudança de pensamento afeta fundamentalmente o escopo do nosso trabalho.

As pessoas que trabalham no ramo de serviços ao cliente costumam entregar
um projeto em um pacote organizado e depois partir até o pôr do sol.
As equipes internas não se saem muito melhor, já que tendem a flutuar de uma
iniciativa para outra. Quer você faça parte de uma equipe interna ou seja um
pistoleiro externo contratado, suponho que você já tenha experimentado as
deficiências do trabalho baseado em projetos. Tendemos a falar sobre um futuro
que nunca chega e, em vez disso, definimo-lo, esquecemo-lo e depois passamos
para o próximo projeto brilhante.
Se estivermos comprometidos em criar um trabalho genuinamente útil que

realmente atenda às necessidades de nossos clientes e organizações,
devemos redefinir fundamentalmente o escopo do nosso trabalho. Como diz
Nathan Curtis, um sistema de design não deve ser um projeto com escopo finito,
mas sim um produto destinado a crescer e evoluir ao longo do tempo:

Concentrar-se na entrega do guia de estilo como clímax é a história

errada para contar. Um sistema não é um projeto com fim, é a
história de origem de um produto vivo e em evolução que servirá outros
produtos.
-Nathan Curtis
A web nunca acaba, e a criação de um sistema de design é apenas o primeiro

passo de uma longa (e esperançosamente frutífera!) jornada.
Um sistema de design deve ser um compromisso de longo prazo com o objetivo
ambicioso de revolucionar a forma como a sua organização cria trabalho digital.
Emocionante, né?! Então, como podemos garantir que isso aconteça?
Criando sistemas de design sustentáveis
Ao embarcar nesta jornada baseada em padrões, vamos falar sobre coisas que
você pode fazer para criar um sistema de design que prepare sua
organização para o sucesso a longo prazo. Como você cria um sistema de design
que se enraíze e se torne uma parte essencial do fluxo de trabalho da sua
organização? Quais armadilhas você precisa estar atento? Como você garante
que o sistema de design produza grandes resultados? Para configurar seu
sistema de design para sucesso a longo prazo, você precisa:
ÿ Torne isso oficial.
ÿ Torne-o adaptável.
ÿ Torne-o sustentável.
ÿ Torne-o interdisciplinar.
ÿ Torne-o acessível.
ÿ Torne-o visível.
ÿ Torne-o maior.
ÿ Torne-o independente do contexto.

ÿ Torne-o contextual.
ÿ Faça durar.
Vamos mergulhar em cada um desses pontos com mais detalhes.

Torne isso oficial
Seu guia de estilo inicial pode começar como um projeto paralelo, o

resultado de um hackathon de fim de semana ou como ideia de um ou dois
ambiciosos membros da equipe. Como discutimos no capítulo anterior, seu
cliente ou chefe nem precisa saber que você está criando um sistema de
design bem pensado e acompanhado de uma biblioteca de padrões.
Lembre-se: peça perdão, não permissão!
Os começos orgânicos são muito bons, mas para estabelecer um sistema

de design verdadeiramente impactante que crie sucesso de longo prazo
para sua organização, o sistema de design precisa evoluir para um
empreendimento oficialmente sancionado. Isso significa pensar nele
como um verdadeiro produto e não como um simples projeto paralelo e,
consequentemente, alocar tempo real, orçamento e pessoas para ele.
Convencer as partes interessadas a comprometer grandes quantias de dinheiro,

tempo e recursos antecipadamente para um sistema de design pode ser
extremamente desafiador. Então, o que devemos fazer? Aqui está meu conselho:
1. Faça algo.
2. Mostre que é útil.
3. Torne isso oficial.
Vamos detalhar essas etapas um pouco mais.
1: Faça uma coisa
Você tem que começar de algum lugar, e começar algo é melhor do que
nada. Escolha um projeto que seja um ótimo piloto para estabelecer
seu sistema de design; siga um processo semelhante ao discutido no
capítulo 4; pense no modelo mental do design atômico detalhado no
capítulo 2; e você terá uma base sólida para um sistema de design bem
pensado e uma biblioteca de padrões que ajudará sua equipe a trabalhar
com mais eficiência.
Reserve um tempo para empacotar seus padrões de UI em uma biblioteca

de padrões e prepare-os para serem adquiridos. Conversei com vários
membros ambiciosos da equipe que estabeleceram a essência básica de sua
biblioteca de padrões ao longo de um fim de semana. Este esforço faz
toda a diferença no mundo, pois proporciona algo tangível para as partes
interessadas reagirem. Novamente: mostre, não conte.

2: Mostre que é útil
Com um sistema de design incipiente, mas tangível, você pode ter conversas
mais significativas com as pessoas que controlam o dinheiro, a programação e
os recursos. Você pode discutir exatamente como o sistema de design ajudou
a economizar tempo e dinheiro (consulte “Padrões de pitch” no capítulo 4)
e, em seguida, traçar um quadro de como esses benefícios aumentariam
ainda mais se a organização investisse em um sistema de design oficial e
completo.
Faça com que membros da equipe de diferentes disciplinas o apoiem e

discutam o sucesso inicial do sistema, e também atraia outras pessoas que
simpatizem com a causa e que se beneficiariam de um sistema de design
expandido.
3: Torne isso oficial
Você provou o valor do seu sistema de design inicial e apresentou um roteiro

para torná-lo ainda melhor. Com alguma sorte, sua organização se
comprometerá a tornar o sistema de design uma coisa oficial.
Com a aprovação dos níveis mais altos, agora você pode colocar em ação
um plano que envolve: alocar ou contratar pessoas para trabalhar no sistema
de design; desenvolver um plano para torná-lo mais robusto; estabelecer
uma estratégia de governação clara; e traçar um roteiro de produto.
Vale ressaltar que as coisas podem não acontecer como você esperava.
Apesar de demonstrar valor real e apresentar um plano de ação concreto, os
superiores ainda podem derrubar sua iniciativa.
Não desanime. Você pode ter perdido a batalha, mas certamente poderá
vencer a guerra. Sua equipe deve continuar a crescer e ampliar o
sistema de design em qualquer capacidade possível até que seu valor se
torne inegável. À medida que mais pessoas se beneficiam do sistema, você
terá um sistema apoiado pelas bases que pode ajudar a impulsionar o
empreendimento.

Estabelecendo uma equipe de sistema de design
Com a iniciativa do sistema de design aprovada, agora é hora de implementar as

pessoas e os processos certos para garantir que o sistema funcione para sua
organização.
Projetar criadores e usuários de sistemas
As primeiras coisas primeiro. É importante reconhecer que inevitavelmente

haverá pessoas na organização que ajudarão a criar e manter o
sistema de design, e que haverá pessoas que serão usuários do sistema
de design. Pode haver sobreposição entre estes dois grupos, mas mesmo
assim é importante estabelecer os papéis dos criadores e dos utilizadores.
Quando falo sobre estabelecer um processo mais colaborativo como o que detalhei
no capítulo anterior, inevitavelmente ouço pessoas que trabalham em grandes
organizações dizerem: “Mas Brad, temos centenas (ou mesmo milhares) de
desenvolvedores trabalhando em nossos produtos. Conseguir que todas essas
pessoas colaborem e contribuam dessa forma seria muito difícil.”
Eles provavelmente estão certos. Seria ideal se toda a organização adotasse

processos mais ágeis e colaborativos, mas a logística difícil em torno de tal
esforço torna-o improvável. Mas o problema é o seguinte: nem todos na organização
precisam contribuir diretamente para o sistema de design, mas alguém (ou, mais
provavelmente, algumas pessoas) deve assumir a responsabilidade por ele.
Os criadores do sistema de design são aqueles que criam, mantêm e

governam o sistema, e precisam trabalhar em estreita colaboração para garantir
que o sistema seja inteligente, flexível, escalável e atenda às necessidades dos
usuários e dos negócios. Os usuários do sistema de design são as equipes da
organização que usarão o sistema e empregarão seus padrões de interface
para aplicações específicas.

Projete criadores e usuários de sistemas.
Os criadores e usuários do sistema de design precisam manter uma

relação de trabalho estreita para garantir que os padrões definidos no
sistema atendam às necessidades dos aplicativos e que toda a
documentação seja clara. Os fabricantes fornecem uma perspectiva
panorâmica de todo o ecossistema que o sistema de design atende,
enquanto os usuários fornecem uma perspectiva prática focada em
aplicações específicas do sistema. Jina Bolton, da Salesforce, resume muito
bem o relacionamento entre fabricantes e usuários:
O Sistema de Design informa nosso Design de Produto. Nosso Design

de Produto informa o Sistema de Design.
-Jina Bolton, Salesforce

Ambas as perspectivas são críticas para o sucesso do sistema de design, e é

por isso que é tão importante que criadores e usuários tenham um
relacionamento saudável que envolva comunicação e colaboração frequentes.
Criadores de sistemas de design
Quem atualiza o sistema de design? Quem aprova as mudanças? Quem

se comunica com os usuários do sistema de design para garantir que ele atenda
às suas necessidades? Quem decide quais padrões permanecem, desaparecem
ou precisam de ajustes?
As respostas a essas perguntas dependerão muito do tamanho e da configuração

da sua organização.
Grandes organizações são capazes de dedicar recursos sérios ao

gerenciamento de sistemas de design. A Salesforce, por exemplo, mantém
uma equipe oficial de sistemas de design, que atualmente inclui cerca de
uma dúzia de funcionários em tempo integral, segundo ouvi pela última vez.
Essa equipe dedicada é responsável por governar o sistema de design e
garantir que ele atenda às necessidades das equipes internas de produto, bem
como dos desenvolvedores externos que constroem coisas na plataforma da
empresa. Quando um sistema de design atende literalmente milhares de
usuários, é uma ideia inteligente dedicar pelo menos alguns funcionários em
tempo integral para gerenciar e expandir o sistema.
As organizações menores provavelmente não podem se dar ao luxo de formar

uma equipe inteira para atender um sistema de design. Os membros da
equipe em organizações menores precisam usar muitas funções (espero que
elegantes!) Por necessidade, portanto, governar o sistema de design
provavelmente se tornará outra responsabilidade. Isso pode parecer um fardo
adicional (“Oh, ótimo, mais uma coisa pela qual sou responsável e que não
envolve aumento de salário!”), mas este chapéu em particular deve ser um
prazer de usar, pois melhora a eficiência e a qualidade do trabalho. todos os
outros trabalhos. Viva os sistemas de design!
Normalmente, os criadores de sistemas de design em organizações menores

serão funcionários de nível sênior que têm experiência para tomar decisões
ponderadas e autoridade para fazer cumprir o sistema de design.
E há agências externas, empreiteiros e consultores.

Qual é o papel de terceiros quando se trata da manutenção de longo
prazo do sistema de design de um cliente? Por um lado, o exterior

os parceiros estão em desvantagem, pois na verdade não trabalham para a

organização de seus clientes. Um sistema de design bem-sucedido precisa se
tornar parte do DNA de uma organização e, como terceiros existem fora dos muros
da empresa, sua influência é intrinsecamente limitada.
Mas, por outro lado, as partes externas muitas vezes podem fornecer um
senso de perspectiva que é difícil de ver quando se trabalha dentro de uma empresa.
É aqui que os estrangeiros podem realmente brilhar. Em meu trabalho como
consultor, trabalho com organizações para estabelecer estratégias de
manutenção de sistemas de design de longo prazo e ajudar a implementar as
pessoas e os processos certos. Embora o sucesso a longo prazo do sistema
dependa, em última análise, da organização, terceiros podem ensiná-los a pescar
e fornecer orientação estratégica, feedback e perspectiva importantes.
Projetar usuários do sistema
Quem são as pessoas responsáveis por usar o sistema de design para construir
novos recursos e aplicações? Quem são as pessoas que conversam com os
criadores do sistema para relatar problemas e solicitar recursos?
Mais uma vez, as respostas a estas perguntas dependerão em grande parte do

tamanho e da estrutura da sua organização.
Os usuários do sistema de design podem ser a mesma equipe que cria o

sistema de design, equipes de desenvolvimento separadas dentro de sua
organização, designers e desenvolvedores de nível júnior, agências parceiras,
lojas de desenvolvimento externas ou outras equipes terceirizadas.
A proximidade e o envolvimento dos utilizadores na criação do sistema de

design irão, sem dúvida, variar. Você pode trabalhar em um único produto em
uma startup fragmentada, para que sua pequena equipe possa criar e usar
simultaneamente o sistema de design. Ou você pode trabalhar em uma grande
empresa multinacional com equipes de desenvolvimento e parceiros terceirizados
espalhados por todo o mundo. Se for esse o caso, os criadores de sistemas
de design e os usuários raramente (ou nunca) se encontrarão, o que significa que
a documentação útil e uma perspectiva panorâmica nítida se tornarão muito
mais importantes.

Há um espectro de relacionamentos potenciais entre usuários e criadores de sistemas de design, e o

tamanho e a composição da sua empresa, sem dúvida, moldarão esses relacionamentos.
Uma das maiores vantagens de estabelecer um sistema de design bem pensado é que ele permite que
as organizações ampliem as melhores práticas. Se todas essas práticas recomendadas – capacidade de
resposta, acessibilidade, desempenho, UX, ergonomia e assim por diante – forem incorporadas ao
sistema, os usuários poderão simplesmente inserir os padrões e colher os frutos. Isso significa que os
usuários do sistema de design não precisam ser designers ou desenvolvedores de nível sênior para produzir
um bom trabalho; o sistema de design serve como um veículo de controle de qualidade que ajuda os
usuários a aplicar as melhores práticas, independentemente do nível de habilidade de cada indivíduo.
Composição da equipe do sistema de design
Uma equipe interdisciplinar deve ser estabelecida para gerenciar, manter e ampliar
adequadamente o sistema. Todas as disciplinas de uma organização – designers UX, designers

visuais, estrategistas de conteúdo, desenvolvedores front-end, desenvolvedores back-end, gerentes de
produto, gerentes de projeto, executivos e outras partes interessadas – têm perspectivas únicas que
podem, sem dúvida, informar e moldar o trabalho. Incorporar essas perspectivas no sistema de
design é importante, mas não exige necessariamente que todas as disciplinas estejam constantemente
envolvidas no seu desenvolvimento.

Haverá inevitavelmente disciplinas que farão o trabalho ativamente, enquanto outras

poderão assumir um papel mais consultivo. Os responsáveis por projetar e
construir a interface do usuário – designers UX, designers visuais,
desenvolvedores front-end – provavelmente servirão como mãos que fazem o
trabalho e fazem atualizações no sistema de design.
Eles devem trabalhar de forma colaborativa (conforme detalhado no capítulo 4)
e coordenar-se com outras disciplinas para garantir que o sistema reflita os valores e
considerações de todo o negócio.
Outras pessoas podem não ser as que realizam ativamente o trabalho, mas
devem ser consultadas para garantir que as suas perspectivas sejam
devidamente refletidas no sistema. Os engenheiros de back-end precisam conscientizar
a equipe sobre quaisquer decisões arquitetônicas que possam afetar a IU de front-end;
os executivos precisam conscientizar a equipe sobre iniciativas importantes que afetarão
a função e a utilidade do sistema; e, claro, os usuários do sistema de design
precisam coordenar-se com os fabricantes para garantir que o sistema atenda às
necessidades de aplicações individuais.
Torne-o adaptável
A mudança é a única constante, como dizem. A parte viva de um sistema de design
vivo significa que ele precisa acompanhar os movimentos, adaptar-se ao feedback,
ser iterado e evoluir junto com os produtos que serve.
Um equívoco sobre sistemas de design é que, uma vez estabelecidos, eles

se tornam uma fonte de verdade onipotente e imutável. Pensar de uma forma tão
rígida é uma maneira segura de fazer com que o esforço do seu sistema de
design retroceda. Se os usuários se sentirem algemados e obrigados a usar
padrões que não resolvem seus problemas, eles perceberão o sistema de design
como uma ferramenta inútil e começarão a procurar em outro lugar por algo que
atenda melhor às suas necessidades.
Criar um plano de governança claro é essencial para garantir que seu sistema
de design possa se adaptar e prosperar com o passar do tempo. Uma estratégia de
governação sólida começa por responder a algumas questões importantes sobre como
lidar com a mudança. Considere o seguinte:
ÿ O que acontece quando um padrão existente não funciona bem para uma aplicação
específica? O padrão é modificado? Você recomenda usar um padrão
diferente? Um novo padrão precisa ser criado?
ÿ Como são tratadas as solicitações de novos padrões?

ÿ Como os padrões antigos são retirados?
ÿ O que acontece quando bugs são encontrados?
ÿ Quem aprova mudanças no sistema de design?
ÿ Quem é responsável por manter a documentação atualizada?
ÿ Quem realmente faz alterações nos padrões de UI do sistema?
ÿ Como as mudanças no sistema de design são implementadas em aplicativos ativos?
ÿ Como as pessoas ficarão sabendo das mudanças?
Provavelmente há muitas outras perguntas específicas a serem respondidas, mas a

questão é que sua equipe deve ter respostas e processos em vigor para lidar com
mudanças inevitáveis no sistema.
Como já mencionado algumas vezes, a comunicação e a colaboração frequentes

entre criadores e usuários são fundamentais para governar com sucesso o seu
sistema de design. Facilite ao máximo a comunicação entre usuários e
fabricantes. Configure um sistema de design de canal Slack ou Yammer, estabeleça
horários regulares de atendimento, certifique-se de que seu software de ticket de bug
ajude a facilitar a conversa e mantenha as portas abertas para bate-papos e chamadas ad
hoc. Se os usuários estiverem presos em alguma coisa, eles devem saber
exatamente onde e a quem recorrer para obter ajuda.
Além da conversa informal do dia a dia entre criadores e usuários, agende reuniões
regulares sobre o “estado da união” para revisar o sistema de design com
criadores, usuários e outras partes interessadas importantes. Discuta o que está
funcionando, seja honesto sobre o que precisa ser melhorado e revise as prioridades
e o roteiro para garantir que o sistema esteja atendendo às necessidades do
negócio. Essas verificações regulares são especialmente úteis para manter as partes
interessadas atualizadas, uma vez que muitas vezes elas não estão envolvidas
no dia a dia das operações do sistema de design.
Fazendo alterações nos padrões
Uma parte crítica da manutenção do sistema de design é garantir que os padrões

de UI permaneçam atualizados, adotem as melhores práticas de design e desenvolvimento
em evolução e continuem a atender às necessidades reais da organização.
Desenvolver uma estratégia para lidar com mudanças de padrões é crucial, e é por isso
que Inayaili de León Persson e a equipe web da Canonical gastaram

hora de mapear sua estratégia enquanto criavam a estrutura de front-end Vanilla.
Achamos que seria bom documentar o processo que um padrão

deve seguir para se tornar um padrão Vanilla, então depois de
um pouco de brainstorming, criamos um diagrama que mostra os
diferentes passos que devem ser seguidos antes de enviar um
padrão proposta para sua plena aceitação como padrão Vanilla.
- Inayaili de León Persson, Canônico
O resultado é uma linda árvore de decisão que mapeia exatamente quais

processos precisam acontecer para adicionar um novo padrão ao sistema de design.
A equipe web da Canonical mapeou o processo de decisão usado para gerenciar atualizações e adições
a padrões na estrutura de front-end Vanilla.
Os três tipos de mudança que podem ocorrer nos padrões em um sistema de

design são modificação, adição e remoção.
Modificando padrões
Os padrões de UI podem e devem ser modificados por vários motivos: adições

de recursos, correções de bugs, ajustes sutis ou importantes no design visual,
melhorias de desempenho, melhorias de acessibilidade, refatoração de código,
atualizações de práticas recomendadas de UX e assim por diante.

Os mantenedores do sistema de design precisam entender por que e quando ajustar

os padrões, como fazer essas alterações e como implementar essas melhorias em
aplicativos individuais.
Manter os padrões atualizados é essencial para a saúde do sistema de design

a longo prazo. Ninguém quer usar e manter um sistema de design com
aparência de Web 2.0, cheio de chanfros e códigos complicados!
Adicionando padrões
Por mais inteligente que sua equipe seja, é bem possível que você não pense em
todos os padrões concebíveis para incluir em seu sistema de design desde o início.
À medida que o sistema for aplicado a mais produtos, surgirão inevitavelmente lacunas
onde as necessidades da aplicação não forem resolvidas pelos padrões existentes.
Nesses casos, ficará claro que serão necessários novos padrões para atender a
essas necessidades.
Deve-se ter cuidado ao adicionar padrões à biblioteca. Se cada capricho resultar

em um padrão totalmente novo, o sistema de design se tornará um Velho
Oeste inchado e pesado. Vale a pena perguntar se esta é uma situação única ou
algo que pode ser aproveitado em outras aplicações.
Talvez você queira assumir um caso único até que uma equipe diferente encontre
um caso de uso semelhante. Se a equipe que trabalha na Aplicação 2 olhar para a
Aplicação 1 e disser: “Eu quero isso!” talvez seja um bom indicador de que um
padrão único deva ser adicionado à biblioteca de padrões.
Removendo padrões
Os padrões podem ser descontinuados por vários motivos. Talvez você descubra
através do uso que um determinado padrão é uma péssima ideia.
A retrospectiva é 20/20, meu amigo. Talvez a indústria tenha se afastado de um
padrão por razões técnicas ou de experiência do usuário. Talvez um padrão tenha
ficado ali sem ser usado por qualquer aplicativo por muito tempo. Talvez os
usuários tenham relatado muitos comentários negativos sobre como trabalhar com um
padrão específico.
Ter um plano para descontinuar padrões é uma ótima ideia. Mas como você
remove padrões do sistema de design sem puxar o tapete das pessoas que
confiam nesses padrões em suas vidas?

formulários? Para resolver esse problema, a Salesforce criou um utilitário

interessante chamado Sass Deprecate que sinaliza padrões que estão se
encaminhando para o bloco de desbastamento em um futuro próximo. Através
do uso inteligente de fags e estilos variáveis do Sass, a equipe do criador
pode avisar aos usuários que um padrão específico está sendo obsoleto e
recomendar um padrão alternativo.
Torne-o sustentável
Com toda essa conversa sobre modificar, adicionar e remover padrões, você
pode estar se perguntando: “Como diabos nossos aplicativos conseguem
realmente acompanhar todas essas mudanças?!” E ao fazer essa
pergunta, você terá se deparado com um dos maiores desafios que as
organizações enfrentam para manter com sucesso um sistema de design.
A maior ameaça existencial a qualquer sistema é a negligência.
-Alex Schleifer, Airbnb
Muitos sistemas ficam inutilizáveis porque o esforço necessário para

fazer atualizações é muito alto. Se for difícil e demorado atualizar padrões,
documentação e aplicativos, as pessoas acabarão ficando tão frustradas
que pararão de fazer o esforço e o sistema de design começará a cair
no esquecimento.
Fazer atualizações nos padrões de UI, documentação e aplicativos deve
ser o mais simples possível, portanto, reduzir esse atrito deve se
tornar uma alta prioridade para a equipe do sistema de design. Isto
envolve uma consideração cuidadosa do ponto de vista tecnológico
e de fluxo de trabalho.
Em busca do Santo Graal
O Santo Graal do sistema de design envolve a criação de um ambiente

onde a biblioteca de padrões e os aplicativos ativos estejam
perfeitamente sincronizados. A ideia é que você seja capaz de fazer uma
alteração em um padrão de UI e ver essa alteração refletida
automaticamente na biblioteca de padrões e em qualquer lugar em que o padrão esteja incluído na

O Santo Graal dos sistemas de design é um ambiente onde fazer alterações em um padrão de UI
atualiza a biblioteca de padrões e os aplicativos de produção simultaneamente.
Essa técnica elimina qualquer duplicação de esforço e garante que a biblioteca

de padrões e os aplicativos que usam os padrões permaneçam
sincronizados. Parece um sonho, certo?
Acontece que esse sonho pode se tornar realidade. A Lonely Planet,

empresa de guias de viagem, foi uma das primeiras a estabelecer um sistema
de design do Santo Graal chamado Rizzo. Por meio de uma arquitetura
inteligente, eles criaram uma API para seus padrões de UI que alimenta
seu ambiente de produção, bem como sua biblioteca de padrões. O resultado é
um sistema de design centralizado que garante que a aplicação e a documentação
em tempo real permaneçam perfeitamente sincronizadas.
Esta abordagem não é uma tarefa fácil, pois requer uma arquitetura técnica
sofisticada, pessoas inteligentes para configurar tudo e uma cultura
organizacional relativamente centralizada. A forma como você busca o
Santo Graal – ou mesmo se você consegue alcançá-lo – depende de uma
série de fatores, incluindo sua arquitetura técnica e composição organizacional.

A Lonely Planet criou uma API para seus padrões de UI que é consumida tanto pela biblioteca de padrões
quanto pelo ambiente de produção. Ao construir seu sistema de design dessa maneira, as alterações nos
padrões de UI são automaticamente refletidas na biblioteca de padrões e no ambiente de produção.
Superando obstáculos técnicos
Manter uma biblioteca de padrões sincronizada com ambientes de produção

requer o compartilhamento de código de maneira inteligente, escalonável e sustentável.
Detalhar todas as diferentes estratégias e considerações técnicas em torno do
Santo Graal exigiria um livro próprio, mas vamos cobrir algumas áreas importantes
sobre como manter o código front-end sincronizado.
O front-end das coisas

Um sistema de design de UI se manifesta como o front-end de uma experiência
web, que é composta por HTML, CSS e JavaScript. Como colocar esse código front-
end em um ambiente de produção, com lógica de aplicação complexa e código
back-end, é a tarefa em questão.
Em seu artigo “Perseguindo o Santo Graal”, o desenvolvedor web Marcelo

Somers detalha várias abordagens técnicas para alcançar o Santo Graal. Ele
destaca os prós e os contras de cada estratégia para alimentar uma

sistema de design em aplicativos para manter ambas as bases de código em sincronia.

Embora eu não vá detalhar cada uma das estratégias de Marcelo, vale a pena notar
que há um espectro de abordagens para escolher: copiar e colar código front-end
manual em uma extremidade, até incorporar a biblioteca de padrões diretamente
no ambiente de produção no outro.
Na minha experiência, descobri que compartilhar CSS e JavaScript de apresentação

com ambientes de produção é relativamente fácil, enquanto compartilhar marcação
é difícil. Como CSS e JavaScript tendem a ser compilados em um único arquivo
(ou talvez em vários arquivos), torna-se possível colocá-los em uma CDN e simplesmente
vincular esses arquivos em cada aplicativo. Marcelo explica como fazer isso tendo
em mente o versionamento:
Você forneceria às equipes de desenvolvimento uma URL com versão

(por exemplo, http:// mycdn.com/ 1.3.5/ styles.css) e a atualização seria
tão simples quanto inserir o número da versão na URL.
-Marcelo Somers
Compartilhar CSS e JavaScript é muito bom, mas as coisas ficam complicadas

quando você deseja compartilhar marcação entre ambientes.
Por que? você pergunta. Bem, a marcação e a lógica de back-end
geralmente estão interligadas na base de código de um aplicativo, o que tende a
dificultar simplesmente copiar e colar a marcação entre sua biblioteca de padrões
e os ambientes de produção. Felizmente, existem maneiras de contornar esse
problema.
Preenchendo a lacuna de marcação com linguagens de modelos
O uso de linguagens de modelagem HTML (como Moustache, Handlebars, Twig,

Underscore, Jade, Nunjucks e uma série de outras) torna a marcação mais portátil
e dinâmica. As linguagens de modelagem separam estrutura e dados e sobrecarregam
nosso HTML para evitar que tenhamos que escrever os mesmos padrões de
marcação repetidamente. A boa notícia é que muitos CMSes e ambientes de aplicativos
também fazem uso de linguagens de modelos para servir marcação de front-end.

A linguagem de modelagem pode servir como ponte entre sua biblioteca

de padrões e os ambientes de produção. Se você usar uma linguagem
de templates para criar os padrões em seu sistema de design (algo que
discutimos detalhadamente no Capítulo 3), você poderá facilmente
compartilhar esses padrões com ambientes de produção que utilizam o mesmo
mecanismo de templates.
Uma linguagem de modelagem como Moustache, Handlebars, Underscore, Jade e outras pode servir como uma ponte
que permite que o código front-end seja compartilhado entre a biblioteca de padrões e o aplicativo de produção.
A equipe da Phase2 Technology alcançou o Santo Graal usando o Pattern

Lab como ferramenta de desenvolvimento de biblioteca de padrões e o Drupal
como seu sistema de gerenciamento de conteúdo. Porque tanto o Pattern Lab
quanto o Drupal suportam o popular Twig mecanismo de modelagem, o Phase2
é capaz de compartilhar facilmente padrões entre os dois ambientes, garantindo
que as bibliotecas de padrões e construções de produção de seus clientes
estejam sempre em sintonia entre si.
Ao usar o mesmo mecanismo de modelagem, junto com a ajuda do

Módulo Drupal de Bibliotecas de Componentes, a ferramenta dá ao
Drupal a capacidade de incluir, estender e incorporar diretamente
os modelos Twig que o Pattern Lab usa para seus componentes, sem
qualquer duplicação de modelo!
- Evan Lovely, Tecnologia Phase2

A sua cultura é compatível com o Santo Graal?
Você pode ter lido a última seção e pensado: “Isso é incrível!

Minha empresa precisa disso agora!” Embora os sistemas do Santo Graal sejam
realmente ótimos, há motivos pelos quais você pode não conseguir manter
sincronizados automaticamente seus ambientes de produção e sua biblioteca de padrões.
Talvez sua organização crie toneladas de produtos digitais em muitas plataformas
diferentes, usando tecnologias totalmente diferentes. Talvez você seja uma
empresa multinacional gigante espalhada por todo o mundo.
Talvez a sua empresa tenha uma cultura extremamente descentralizada e autônoma.
Ou talvez você seja um governo federal gigantesco.
Os Draft US Web Design Standards são o sistema de design do governo federal dos Estados Unidos.
O sistema de design do governo dos EUA – chamado Draft US Web Digital

Standards – é uma coleção de componentes de UI e estilos visuais criados
para ajudar as pessoas que fazem sites governamentais a construir UIs mais
consistentes. O sistema de design fornece marcações e estilos para os usuários
baixarem e inserirem em seus aplicativos. Certamente seria incrível ver um
sistema de design do Santo Graal implementado em uma escala tão gigantesca,
mas como você pode imaginar, isso é uma tarefa bastante difícil. A vastidão e a
natureza descentralizada da organização

significa que uma biblioteca de padrões sincronizados não é realmente alcançável sem
alguma reestruturação dramática de como os sites do governo federal são construídos.
Se uma cultura relativamente dispersa e descentralizada é a sua realidade, não desanime!

Até mesmo implementar algum sistema de design – um punhado de padrões de UI,
alguma documentação útil e princípios orientadores – pode mostrar à sua organização
a luz que aponta para o Graal. Como discutimos ao longo deste capítulo, esses
esforços devem ser contínuos e, antes que você possa correr, você deve primeiro
aprender a engatinhar.
Torne-o interdisciplinar
Os guias de estilo geralmente vão direto para trechos de código e uso de padrões
para o benefício dos usuários do sistema de design. É claro que uma biblioteca
de padrões precisa ser útil para as pessoas que realmente fazem uso dos padrões, mas
tratar um guia de estilo apenas como um recurso para desenvolvedores limita seu
potencial.
Um guia de estilo tem a oportunidade de servir de ponto de encontro para toda a

organização, ajudando a estabelecer um vocabulário comum para cada disciplina
investida no sucesso dos produtos digitais da empresa. Estabelecer esse vocabulário
comum pode levar a um trabalho mais eficiente, melhor comunicação e mais
colaboração entre disciplinas em toda a organização. É por isso que o guia de estilo
deve ser um lugar convidativo para todos, não apenas para usuários de sistemas de
design.
Pegue o carrossel (por favor!). Este componente é incrivelmente complexo do ponto de

vista organizacional. Um carrossel de página inicial em um site de comércio eletrônico
requer informações de uma série de disciplinas de toda a organização. Os
empresários e a equipe editorial devem escolher os produtos que serão apresentados
no carrossel. Os redatores devem garantir que a cópia seja eficaz e permaneça dentro
das restrições do design. Os diretores de arte precisam ter certeza de que o design
estético é agradável e que a fotografia do produto é legível em todos os tamanhos de
tela. Os designers de UX precisam confirmar que a funcionalidade e os controles são
intuitivos. O pessoal de front-end deve ter certeza de que o componente é responsivo,
acessível e tem bom desempenho. Os desenvolvedores back-end precisam garantir
que o componente esteja conectado corretamente ao sistema back-end. Você entendeu
a ideia.

Um carrossel de página inicial em um site como o Walmart requer contribuições de diversas disciplinas e partes
interessadas. Um guia de estilo pode ajudar a reunir essas diferentes perspectivas sob o mesmo teto.
Um guia de estilo bem elaborado pode ajudar a gerenciar todas essas partes móveis
e garantir que as muitas perspectivas que influenciam cada padrão sejam
devidamente documentadas no guia de estilo. Torne a biblioteca de padrões
acessível a todas as disciplinas e pense em como torná-la fácil e convidativa
para que diferentes disciplinas contribuam para a documentação.
Torne-o acessível
Não deveria ser surpresa para ninguém que as pessoas tendem a gravitar em torno
de coisas atraentes. Uma grande parte de tornar um guia de estilo um recurso
interdisciplinar é garantir que o contêiner que abriga sua biblioteca de padrões e
outras documentações seja bonito, convidativo e fácil de navegar.
Reservar um tempo para criar um local atraente para seu guia de estilo e documentação
pode levar a mais uso, ajudar a aumentar a conscientização, ajudar a criar
investimento organizacional e ajudar a chamar a atenção de não-desenvolvedores
para o guia de estilo. Tudo isso contribui para aquele importante vocabulário
compartilhado que leva a uma melhor colaboração interdisciplinar.
Mas criar uma experiência de guia de estilo intuitiva e atraente não acontece
simplesmente, e isso pode ser problemático ao obter

O guia de estilo do Yelp tem uma página inicial atraente e amigável que explica o que é o recurso, para quem
se destina e como usá-lo.
um guia de estilo do terreno. Se as equipes pensarem que criar um guia de

estilo útil envolve fazer algo grande e oficial com uma marca personalizada e um
site brilhante, elas podem ser dissuadidas de iniciar a iniciativa. Então lembre:
1. Faça algo.
2. Mostre que é útil.
3. Torne isso oficial.
Criar um sistema de design útil deve ser a primeira prioridade da equipe.

Construir uma casa feliz para conter tudo pode não acontecer imediatamente,
mas deve se tornar uma prioridade maior quando o sistema de design se tornar
oficial. Criar um guia de estilo bonito não é apenas design pelo design;
reflete o compromisso de uma organização em criar e manter um sistema
de design bem pensado e deliberado.
Torne-o visível
A visibilidade é extremamente importante para a saúde contínua do seu

sistema de design. Um empreendimento tão importante não deveria ser esquecido

em um canto escuro da sua intranet. Que etapas você pode seguir para garantir
que o sistema de design continue sendo a base de seus fluxos de trabalho de
design e desenvolvimento?
Evangelismo do sistema de design
Você pode criar o melhor guia de estilo do mundo, usar a tecnologia

mais sofisticada, ter uma equipe incrível e ter usuários entusiasmados, mas se
você não promover ativamente o sistema de design e comunicar as mudanças,
todo o esforço sofrerá muito.
Evangelizar os esforços do seu sistema de design pode e deve acontecer

antes mesmo de o sistema ser lançado. No início do seu projeto, você
pode configurar locais para documentar o progresso do projeto para ajudar a
aumentar a conscientização e o entusiasmo pelo esforço do sistema de
design. Um cliente meu criou um blog interno para publicar atualizações do
projeto, bem como um canal do Yammer do sistema de design onde
desenvolvedores e outras partes interessadas podem compartilhar ideias,
abordar preocupações, dar feedback e fazer perguntas. Estabelecer uma cultura
de comunicação no início do processo aumentará a probabilidade de o sistema
de design se enraizar.
Comunicando a mudança
Uma vez que o sistema de design esteja pronto e sendo usado em aplicações
reais, é imperativo comunicar mudanças, atualizações e uma visão contínua para
toda a organização.
As táticas para essa comunicação podem variar desde utilidades básicas até
esforços de marketing mais voltados para o exterior. Aqui estão alguns materiais
que podem ajudar a comunicar a mudança:
ÿ Registros de alterações: “Aqui está o que mudou na biblioteca de padrões neste

mês."
ÿ Roteiro: “Aqui está o que está por vir nos próximos

meses."
ÿ Histórias de sucesso: “A Equipe X lançou este novo aplicativo excelente

usando o sistema de design; leia mais sobre como eles fizeram isso.
ÿ Dicas e truques: “Aqui estão algumas práticas recomendadas e

considerações para usar os botões do nosso sistema em toda a sua
aplicação.”

Ter uma base para todos esses materiais é uma ótima ideia, e mantê-los
adjacentes (ou mesmo dentro) do próprio guia de estilo também faz muito sentido.
A equipe de design de material publica um changelog útil em seu guia de estilo para que os usuários possam
aprender facilmente sobre as atualizações e melhorias mais recentes do sistema.
Mudanças, atualizações e solicitações no sistema de design devem

ser comunicadas onde quer que sua equipe esteja. Isso pode incluir Slack,
Basecamp, GitHub, wikis, Yammer, listas de e-mail, blogs de empresas, intranets
e quaisquer outras ferramentas internas que sua equipe usa para se comunicar
e colaborar. Se isso parece muito trabalho para
você, não tema! Manter sua equipe e usuários atualizados não exige um grande
esforço manual. Graças à natureza conectada de nossas ferramentas, as equipes
podem ser alertadas automaticamente sobre mudanças por meio de software, como
explica Micah Sivitz, da Shyp:
Sempre que alguém faz um pull request, ele envia uma notificação
para nosso canal #Design no slack, anunciando à equipe que
há uma alteração na proposta e é necessário feedback.
- Micah Sivitz, Shyp

Integrar essa comunicação ao fluxo de trabalho diário da equipe mantém os criadores, os

usuários e as partes interessadas engajados e ajuda a garantir aos usuários que a biblioteca
de padrões está sendo mantida e aprimorada ativamente.
Treinamento e suporte
Você não entregaria a alguém um martelo, uma serra e uma chave de fenda e depois diria:
“Tudo bem, você tem o que precisa; agora vá e construa para mim uma linda casa nova.”
Saber como usar uma ferramenta de maneira adequada costuma ser ainda mais importante
do que a disponibilidade dessa ferramenta. A documentação na forma de guia de estilo é
sem dúvida útil, mas por si só não é suficiente. É essencial fornecer treinamento
adequado e oferecer suporte contínuo aos usuários do seu sistema de design para
garantir que eles comecem a usar o kit de ferramentas com sucesso e continuem a
criar um ótimo trabalho com ele.
O treinamento dos usuários sobre como trabalhar com o sistema de design pode assumir
várias formas, incluindo:
ÿ Sessões em pares: Nada se compara a puxar uma cadeira e trabalhar juntos em

um projeto. Embora seja mais demorado do que outros veículos de treinamento,
é a melhor maneira de fazer com que criadores e usuários colaborem juntos,
aprendam como o sistema funciona e exponham novas oportunidades e
deficiências.
ÿ Workshops: desde sessões imersivas de um dia inteiro até caminhadas rápidas

através disso, é extremamente útil organizar oficinas de treinamento presenciais
envolvendo fabricantes e usuários. Essas sessões podem ajudar a eliminar quaisquer
equívocos sobre o sistema, ajudar a nivelar os usuários com orientação prática e
criar um relacionamento saudável entre as pessoas encarregadas de manter o
sistema e as pessoas encarregadas de trabalhar com ele.
ÿ Webinars: se não for possível realizar workshops ou sessões em pares, ou se você

precisar treinar muitos usuários em grande escala, os webinars podem ser fantásticos.
Os usuários podem participar de sessões on-line para aprender como
usar corretamente o sistema. Ao conduzir webinars, certifique-se de reservar

bastante tempo para perguntas e respostas para responder perguntas,
preocupações e comentários em áudio e digitados.
ÿ Tutoriais: uma série de postagens de blog e screencasts podem ser facilmente

encapsular os conceitos básicos de trabalho com o sistema de design.
Eles não apenas servem como uma ferramenta de treinamento, mas também
podem servir como uma ótima referência para voltar sempre.

ÿ Integração: Uma ótima maneira de injetar seu sistema de design na cultura da sua
empresa é incorporar o treinamento do sistema de design diretamente no
processo de integração de novos funcionários. Os novos colegas compreenderão a
importância da modularidade, da reutilização e de todos os outros benefícios que um
sistema de design traz.
Os usuários, sem dúvida, terão dúvidas ou encontrarão problemas quando

começarem a trabalhar e a construir coisas com o sistema de design. Eles precisam
saber que existe um sistema de suporte robusto para ajudar a responder quaisquer
perguntas, ouvir seus requisitos e solucionar bugs. Há uma série de mecanismos
em vigor para fornecer suporte aos usuários, incluindo:
ÿ Rastreadores de problemas: ferramentas como JIRA e GitHub Issues são

ótimas para usuários e criadores relatarem bugs e terem conversas
técnicas. Os usuários devem estar cientes do protocolo para lançar bugs e sentir-
se capacitados para contribuir.
ÿ Horário de atendimento: agende horários regulares em que a equipe do sistema

de design esteja disponível para responder perguntas, resolver problemas e
conversar sobre o que vem por aí para o sistema de design.
ÿ Ferramentas Slack e chat: a natureza em tempo real de muitos de nossos

as ferramentas de colaboração no trabalho apresentam uma grande oportunidade
para manter a conversa carregada de padrões. Graças a ferramentas como
Slack, Yammer e HipChat, criadores e usuários podem interagir quando e onde
quiserem.
ÿ Fóruns: Comunidades como Stack Overfow e GitHub provaram ser extremamente

eficazes em permitir suporte comunitário e de base. Em vez de os
criadores de sistemas de design se tornarem um gargalo de suporte, pode valer a
pena abrir o suporte para toda a comunidade de usuários.
ÿ Divulgação: nem todo mundo tem tempo ou personalidade para perguntar

tirar dúvidas e sugerir alterações. Os criadores de sistemas de design devem ser
proativos e entrar em contato com os desenvolvedores que usam o sistema de
design para ver se eles têm algum problema ou preocupação. Este tipo de ações
pode ajudar a construir uma relação genuína e positiva entre criadores e
utilizadores.

O sistema Draft US Web Digital Standards rastreia problemas usando o GitHub, fornecendo um local para
usuários e fabricantes fugirem de bugs e conversarem sobre os detalhes.
Graças a ferramentas como o GitHub, os usuários do sistema de design não

precisam ser relegados ao papel de consumidores burros. As pessoas que
usam o sistema todos os dias podem ser contribuidores extremamente valiosos
para o sistema de design, se tiverem oportunidade. Aceite o fato de que os
usuários estão ansiosos para contribuir e tornar o sistema o melhor possível.
Aqui estão algumas táticas para incentivar as contribuições dos usuários:
ÿ Sugestões e solicitações pull: incentive qualquer pessoa que use o

sistema de design para sugerir mudanças e novos recursos. Melhor ainda,
convide os usuários a enviar alterações na forma de solicitações pull que
podem ser mescladas diretamente na base de código.
ÿ Entrevistas individuais e mesas redondas: é sempre uma boa ideia

conversar com os usuários, portanto, agende regularmente um horário
para conversar com as pessoas que tocam nesses padrões regularmente.
Absorva tudo, ouça o que há de bom e de ruim e determine coletivamente
um plano de ataque para resolver quaisquer problemas e sugestões.

ÿ Solicitações de feedback: gerenciar um sistema que pode ser potencialmente

implantado em centenas de aplicativos pode ser complicado. Antes de tomar
decisões que possam impactar muitas pessoas, peça opiniões: “Estamos
considerando descontinuar nosso padrão carrossel e gostaríamos de ouvir sua
opinião”.
ÿ Pesquisas: se as entrevistas não forem viáveis, você pode recorrer rapidamente

pesquisas para ter uma ideia da eficácia dos padrões de UI e do guia de estilo.
Perguntas como “Em uma escala de um a cinco, quão útil é a documentação
do padrão? Alguma sugestão?" pode ajudar a identificar pontos cegos e fazer com
que os usuários sugiram recursos que tornariam suas vidas mais fáceis.
ÿ Reuniões regulares sobre o “estado da união”: agende reuniões regulares

reuniões onde a equipe do sistema de design discute o roteiro do produto, lições
aprendidas ao longo do caminho e sugestões e feedback. Incentive qualquer
pessoa a participar da reunião e certifique-se de gravar e distribuir essas sessões
para que todos estejam cientes do plano diretor.
Torne isso público
Comunicar mudanças, evangelizar e estabelecer treinamento e suporte

adequados são ótimas coisas para aumentar a visibilidade do seu sistema. Mas há
outra grande oportunidade para levar a sua estratégia de comunicação a
outro nível: tornar o seu guia de estilo acessível ao público.
Por que? Um guia de estilo não é apenas um recurso interno para ajudar as pessoas
da sua organização a trabalharem melhor juntas? Qual a utilidade disso para o
mundo exterior? E publicar seu guia de estilo não revelaria todos os seus segredos
comerciais?
Publicar seu guia de estilo para o mundo ver aumenta sua visibilidade,
aumenta a responsabilidade e serve como uma ferramenta de recrutamento
incrível.
Colocar seu guia de estilo atrás de um login ou frewall reduz a visibilidade e adiciona
uma carga desnecessária para sua equipe e parceiros, o que limita a eficácia e o
potencial do recurso. E os receios de revelar os seus segredos comerciais são
completamente infundados.
Estes são padrões de UI, não códigos nucleares.

Styleguides.io reúne mais de 150 guias de estilo públicos de organizações de todo o mundo.
Além de facilitar o acesso a documentação importante, um guia de estilo público ajuda a

criar responsabilidade organizacional.
Publicar seu guia de estilo demonstra o compromisso da sua organização com o
sistema de design, o que cria uma pressão útil para mantê-lo um recurso útil e atualizado.
Guias de estilo voltados ao público também são extremamente úteis para o recrutamento.
Designers, desenvolvedores e pessoas que trabalham em outras disciplinas desejam
trabalhar para organizações que adotam as melhores práticas digitais modernas e (como
discutimos ao longo deste livro) os sistemas de design estão rapidamente se tornando
uma prática recomendada em todo o setor.
Publicar seu guia de estilo envia um forte sinal de morcego que pode atrair pessoas
apaixonadas e preocupadas com os padrões. Por exemplo, a especialista em guia de estilo
Jina Bolton foi trabalhar na Salesforce depois de ver o guia de estilo da empresa para seu
produto Salesforce1.
Quando vi [o guia de estilo do Salesforce] achei lindo e

por isso quis entrar nesse time.
-Jina Bolton

Desde que ingressou na Salesforce, ela ajudou a criar o extremamente bem-

sucedido Lightning Design System e ajuda a gerenciar sua crescente equipe
de sistemas de design. A história de Jina não é isolada; quase todos os
convidados que Anna Debenham e eu entrevistamos no Styleguides Podcast
discutiu como sua biblioteca de padrões voltada ao público era útil para
atrair talentos. Tudo isso significa que seu guia de estilo público torna sua
organização mais competitiva, e não menos.
Torne-o maior
Uma biblioteca de padrões visível, interdisciplinar e acessível é aquela à
qual sua equipe voltará sempre. Use isso a seu favor. Como os olhos da
equipe já estão fixados nesse recurso, há uma grande oportunidade de
estendê-lo para incluir outra documentação útil, como a voz e o tom, a marca,
o código, os princípios de design e as diretrizes de redação que discutimos no
capítulo 1.
O sistema de design Harmony da Intuit inclui uma biblioteca de padrões, princípios de design, voz
e tom, diretrizes de marketing e muito mais. Alojar esta documentação útil sob o mesmo teto ajuda a
aumentar sua visibilidade e eficácia.
Agora, sua organização pode não precisar implementar todos os guias de

estilo existentes, mas a questão é que a criação de um hub centralizado
de guias de estilo cria mais consciência sobre as melhores
práticas, aumentando a eficácia da documentação.

Outra maneira de estender a funcionalidade da biblioteca de padrões é incluir diretrizes

para padrões de plataforma nativa junto com padrões baseados na web. Podemos olhar mais
uma vez para o sistema de design Harmony da Intuit como exemplo de como os padrões
nativos de plataforma móvel para iOS e Android podem conviver ao lado de seus
equivalentes baseados na web.
A biblioteca de padrões Harmony da Intuit inclui botões para alternar entre web, iOS e Android para cada padrão.
Isso permite que a equipe mantenha um sistema de design consistente em todas as plataformas, mas também
documente divergências de padrões quando elas ocorrerem.
Torne-o independente do contexto
A forma como seus padrões de UI são nomeados, sem dúvida, moldará a forma como
eles serão usados. Quanto mais agnósticos forem os nomes dos padrões, mais
versáteis e reutilizáveis eles se tornarão.
Como tendemos a estabelecer padrões de UI no contexto de uma página mais ampla, pode
ser tentador nomear componentes com base em onde eles residem. Mas em vez de nomear
seu componente como “carrossel da página inicial” (perdoe minha obsessão mórbida por
carrosséis), você pode simplesmente chamá-lo de “carrossel”, o que significa que agora
você pode colocar carrosséis em todos os lugares!
(Mas pelo amor de tudo o que é sagrado, por favor, não faça isso.)
Outro desafio para nomear padrões de exibição é que tendemos a nos distrair com os
padrões de conteúdo que residem dentro deles. Por exemplo, se estiver trabalhando
em um site de comércio eletrônico, você pode ficar tentado a chamar um bloco contendo a
imagem de um produto e o título de “cartão de produto”.

Mas nomear as coisas dessa maneira limita imediatamente o tipo de conteúdo que
pode existir dentro delas. Ao nomear o padrão simplesmente como “cartão”, você pode
colocar todos os tipos de padrões de conteúdo dentro dele: produtos, promoções,
localizações de lojas e assim por diante.
Aviso justo: nomear as coisas é realmente muito difícil. Mas existem estratégias
para ajudá-lo a criar nomes robustos para seus padrões.
A realização de um inventário de interface (conforme detalhado no capítulo 4) ajuda
a remover padrões do contexto da página onde normalmente residem, o que significa
que sua equipe pode criar nomes que não se distraiam com seu contexto. Conduzi
exercícios de nomenclatura com equipes onde desfocamos o conteúdo que reside
dentro de um padrão para que todos possam se concentrar na estrutura do padrão , e
não no conteúdo que reside dentro dele.
Um bom exercício ao nomear padrões é desfocar o conteúdo para que seus nomes reflitam as estruturas
dos padrões, em vez do conteúdo que vive dentro deles.
Embora nomear coisas sempre seja um desafio, nomes de padrões independentes de

contexto e conteúdo serão mais portáteis, reutilizáveis e versáteis.
Torne-o contextual
Apresentar padrões de UI em uma biblioteca de padrões é muito bom, mas você

precisa demonstrar o contexto para que os usuários do sistema de design
entendam como e onde usá-los adequadamente. A maioria dos padrões

as bibliotecas mostram uma demonstração de cada padrão de UI, mas, como

discutimos, esses padrões não vivem no vácuo. Onde exatamente esses
padrões são usados?
Uma forma de demonstrar o contexto pode incluir mostrar capturas

de tela ou vídeos de um componente em ação. A documentação do Material
Design faz um trabalho fantástico nisso; cada componente é rico em fotos,
vídeos e detalhes de uso para fornecer aos usuários uma compreensão clara
da aparência desses padrões no contexto de um aplicativo e demonstrar como
cada padrão deve ser usado.
A biblioteca de componentes do Material Design não contém apenas um exemplo de cada

componente; ele documenta minuciosamente o uso do componente com muitas imagens e vídeos para apoiá-lo.
Outra forma de mostrar o contexto é fornecer informações de linhagem para cada

padrão. Como discutimos no Capítulo 3, uma ferramenta como o Pattern Lab
gera automaticamente essas informações, permitindo ver quais padrões
compõem um determinado componente, além de mostrar onde cada
componente é empregado. Isso fornece uma espécie de registro de padrões que
ajuda imensamente nos esforços de controle de qualidade, pois destaca
exatamente quais padrões e modelos precisariam ser testados se alterações
fossem feitas em um padrão específico.

Ferramentas como o Pattern Lab fornecem informações de linhagem, permitindo que as equipes vejam quais
componentes menores estão incluídos em qualquer componente, bem como onde cada padrão é usado.
Faça durar
Criar um sistema de design é um empreendimento incrível e importante.

Mas sem a manutenção adequada, o valor do seu sistema de design se desvalorizará
da mesma forma que um carro que acabou de sair do estacionamento de uma
concessionária. Em vez disso, seu sistema de design deve ser como uma garrafa de
bom vinho cujo valor aumenta com o tempo.

Com a manutenção adequada, o valor do seu sistema de design deve aumentar com o tempo, como uma garrafa de
bom vinho, em vez de um carro usado que acabou de sair do estacionamento. Crédito da imagem: Sabin Paul
Croce no Flickr e Ray Larabie no Flickr
Como discutimos ao longo deste capítulo, fazer com que seu sistema de
design resista ao teste do tempo requer uma quantidade significativa de tempo
e esforço. Mas não é esse o caso com todos os seres vivos? Os animais
precisam comer e as plantas precisam de água e luz solar para sobreviver.
Criar um sistema de design vivo significa dar-lhe atenção e cuidado para que
continue a prosperar.
Todo esse esforço não apenas cria um presente melhor para sua
organização, mas também prepara você para o sucesso a longo prazo.
Estabelecer um plano de governança claro, comunicar mudanças e
implementar os outros conselhos encontrados neste capítulo ajuda o sistema
de design a criar raízes e a se tornar parte integrante do fluxo de trabalho da sua organização.
Criar a maldita coisa em primeiro lugar é a parte difícil, mas uma vez
estabelecido, você terá uma base sólida para construir nos próximos anos.
Mesmo se você queimar tudo e reconstruir um novo sistema do zero, você
descobrirá que suas UIs ainda precisarão de botões, campos de formulário,
guias e outros componentes existentes.
E você precisará de um lar feliz para exibir e documentar o sistema.
Não jogue fora o bebê junto com a água do banho!

Então aí está. Para criar um sistema de design sustentável, você deve:
ÿ Torne isso oficial alocando tempo real, dinheiro e recursos para seu
sistema de design.
ÿ Torne-o adaptável contando com mudanças e estabelecendo um

plano de governança claro.
ÿ Torne-o sustentável buscando o Santo Graal e facilitando a implantação

e a comunicação de alterações no sistema de design.
ÿ Torne-o interdisciplinar, tornando sua biblioteca de padrões um ponto

de encontro em torno do qual toda a organização pode se reunir.
ÿ Torne-o acessível criando um guia de estilo atraente e fácil de usar,

acompanhado de documentação útil.
ÿ Torne-o visível comunicando mudanças, evangelizando o sistema de

design e tornando-o público.
ÿ Torne-o maior incluindo marca, voz e tom, código, design

princípios e diretrizes de redação.
ÿ Torne-o agnóstico nomeando padrões de acordo com sua estrutura, e

não com seu contexto ou conteúdo.
ÿ Torne-o contextual demonstrando quais padrões compõem um padrão

específico e mostrando onde cada padrão é usado.
ÿ Faça com que dure estabelecendo uma base sólida para construir nos
próximos anos.
Vá em frente e seja atômico
Nossa tarefa é fazer com que uma série de produtos, sites e aplicativos
funcionem e tenham uma ótima aparência em uma variedade estonteante de
diferentes dispositivos, tamanhos de tela, formatos e ambientes. Espero
que os conceitos abordados neste livro lhe proporcionem uma base sólida
para enfrentar corajosamente esse cenário digital cada vez mais diversificado.
Ao criar sistemas de design, ser cuidadoso na construção de interfaces de
usuário, estabelecer um fluxo de trabalho colaborativo e baseado em
padrões e configurar processos para manter seu sistema de design com
sucesso, espero que você e sua equipe possam criar grandes coisas
juntos. Vá em frente e seja atômico!

Agradecimentos e Reconhecimentos
Este livro é dedicado à minha incrível esposa Melissa, que apoia todas as minhas
ideias malucas e de alguma forma aguenta todas as minhas merdas.
Obrigado. Eu te amo.
Gostaria de agradecer imensamente a Dave Olsen, que conduziu meu nascente

e mal programado Laboratório de Padrões conceito e o transformou em um software
legítimo e incrível. Graças ao trabalho incansável de Dave e Brian Muenzenmeyer,
o Pattern Lab está ajudando equipes de todo o mundo a criar sistemas de design
atômico. Serei eternamente grato por todo o seu excelente trabalho e me considero
um sortudo por poder chamá-los de amigos.
A Josh Clark e Dan Mall por ajudarem a solidificar o design atômico como
metodologia e por escreverem o prefácio deste livro. Você confiou em mim o
suficiente para seguir essa abordagem e de alguma forma convenceu nossos
clientes de que não era totalmente insano. Sem a sua contribuição e os cérebros
extremamente inteligentes dos primeiros colaboradores como Jennifer Brook,
Jonathan Stark, Robert Gorrell, Kelly Shaver e Melissa Frost, este livro não
teria existido.
Agradeço a Owen Gregory por editar o manuscrito do livro e assumir a tarefa

hercúlea de me fazer parecer razoavelmente coerente. Obrigado a Rachel Andrew
por discutir todo o material técnico necessário para fazer e-books. E um grande
obrigado a Rachel Arnold Sager por todo o seu trabalho em preparar a versão
impressa do livro para a impressão.
Para Anna Debenham, por todo o seu pensamento incrível sobre guias de estilo de
front-end, seu livro sobre o assunto e sua disposição de co-apresentar um podcast
sobre guias de estilo comigo. Estou orgulhoso do trabalho que fizemos no
Styleguides.io e estou muito feliz por termos trabalhado juntos.
A Jonathan Snook, por sua fantástica metodologia SMACSS e por dedicar

seu tempo para me guiar no processo de autopublicação de um livro. Obrigado
por tornar um empreendimento tão assustador muito mais acessível.

Para Stephen Hay, que foi a primeira pessoa que ouvi articular a necessidade de
quebrar as interfaces em pedaços menores. Obrigado por ser uma fonte contínua
de sabedoria e sarcasmo.
Para Andy Clarke, que estava falando sobre sistemas de design e átomos
antes era a coisa mais moderna a se fazer. Obrigado por todos os seus escritos e
pensamentos, mas você ainda não está recebendo meu cachorro.
A Dave “Tiny Bootstraps” Rupert, Susan Robertson, Samantha Warren, Jina Bolton,
Nathan Curtis, Paul Robert Lloyd, Harry Roberts, Nicole Sullivan, Brett Jankord,
Tyler Sticka, Lincoln Mongillo, Nicholas Gallagher e muitos outros que
avançaram os conceitos de sistemas de design, bibliotecas de padrões e guias
de estilo. Obrigado por ajudar a mim e a tantos outros a pensar de forma mais
modular.
A Jefrey Zeldman, Eric Meyer, Marc Thiele, Vitaly Friedman e todos os outros
organizadores da conferência que me deram a oportunidade de subir ao palco para
divagar sobre os conceitos contidos neste livro.
Este livro não teria sido possível se não fosse pelo incrível trabalho realizado
por algumas pessoas incríveis da comunidade da web.
Tenho muita sorte de trabalhar em uma comunidade tão aberta, compartilhada e
colaborativa; todos os dias estou ansioso para aprender coisas novas com todos vocês.
E por último, mas não menos importante, muito obrigado à minha família por todo o seu
amor e apoio incrível ao longo dos anos.
AGRADECIMENTOS E RECONHECIMENTOS 183

Recursos
Capítulo 1
• Componentes de escopo, não páginas

http://bradfrost.com/blog/post/scope-components-not-pages/
• Princípios de Design W3C - Design Modular http://

www.w3.org/DesignIssues/Principles.html#Modular
• Biblioteca YUI
http://yuilibrary.com/
• jQuery U
http://jqueryui.com/
• Manifesto Amigável ao Futuro

http://futurefriendlyweb.com/
• Andando na escada rolante mágica do conhecimento

adquirido http://www.uie.com/articles/magic_escalator/
• Manifesto Ágil
http://www.agilemanifesto.org/
• Desenvolvimento de software
Scrum http://en.wikipedia.org/wiki/
Scrum_%28software_development%29
• Desenvolvimento de software enxuto

http://en.wikipedia.org/wiki/Lean_software_development
• Princípios por trás do Manifesto Ágil

http://www.agilemanifesto.org/principles.html
• Processo DIY
http://cognition.happycog.com/article/diy-process
• Para uma Web Amigável ao Futuro

http://bradfrost.com/blog/web/for-a-future-friendly-web/
• Adaptando-nos ao conteúdo adaptável http://

karenmcgrane.com/2012/09/04/adapting-ourselves-to-adaptive-content-
video-slides-and-transcript-oh-my/
• COPE: crie uma vez, publique em qualquer

lugar http://www.programmableweb.com/news/cope-create-once-
publish-everywhere/2009/10/13

• Aprendendo padrões de design JavaScript

http://addyosmani.com/resources/essentialjsdesignpatterns/book/
• OOCSS
http://oocss.org/
• SMACSS
https://smacss.com/
• MindBEMding – entendendo a sintaxe do BEM

http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-
bem-syntax
• Um extrato de Projetando Átomos e Elementos

http://stufandnonsense.co.uk/blog/about/an-extract-from-designing-
atoms-and-elements
• Blocos de
estilo http://styletil.es/
• Colagens de
Elementos http://danielmall.com/articles/rif-element-collages/
• BDConf: Stephen Hay apresenta fluxo de trabalho de design responsivo

http://bradfrost.com/blog/mobile/bdconf-stephen-hay-presents-
responsive-design-workfow/
• Web design responsivo

http://alistapart.com/article/responsive-web-design
• Isso é responsivo
http://bradfrost.github.io/this-is-responsive/index.html
• Fundação pela ZURB

http://foundation.zurb.com/
• Inicialização
http://getbootstrap.com/
• GitHub
https://github.com/
• Entregáveis responsivos
http://daverupert.com/2013/04/responsive-deliverables/
RECURSOS 185
• Guias de estilo
http://bradfrost.com/blog/post/style-guides/ • Design de
materiais
http://www.google.com/design/spec/material-design/introdução.html
• Voz e tom: criação de conteúdo para humanos

http://www.slideshare.net/katekiefer/kkl-c-sforum
• Tom de voz http://
voiceandtone.com/
• Escrevendo para a Web

http://www.dal.ca/webteam/web_style_guide/writing_for_the_ web.html
• Guias de estilo de front-end

http://maban.co.uk/projects/front-end-style-guides/
• Podcast de Guias de Estilo com Federico Holgado

http://styleguides.io/podcast/federico-holgado/
• Dennis Crowley: “A parte difícil é construir a máquina que constrói o produto”

http://techcrunch.com/
2011/03/03/founder-stories-foursquare-crowley-machine/
• Exemplos de guias de estilo em Styleguides.io

http://styleguides.io/examples.html
Capítulo 2
• Projeto Sistêmico
http://us5.campaign-archive1. com/?
u=7e093c5cf4&id=ead8a72012&e=ecb25a3f93
• Tabela Periódica de Elementos HTML de Josh Duck

http://smm.zoomquiet.io/data/20110511083224/index.html
• Referência de elemento HTML
https://developer.mozilla.org/en-US/docs/Web/HTML/Element
• Princípio de responsabilidade única

https://en.wikipedia.org/wiki/Single_responsibility_principle
• Estrutura primeiro. Conteúdo sempre.

http://www.markboulton.co.uk/journal/structure-frst-content-always

• A forma do design http://

read.shapeofdesignbook.com/chapter01.html
• Sistema de Design Predix da GE

https://medium.com/ge-design/ges-predix-design-
system-8236d47b0891#.uo68yjo9g
Capítulo 3
• Laboratório de Padrões
http://patternlab.io
• Dave Olsen
http://dmolsen.com
• Brian Muenzenmeyer http://

www.brianmuenzenmeyer.com/
• Documentação do Pattern Lab http://
patternlab.io/docs/
• Não se repita
https://en.wikipedia.org/wiki/Don't_repeat_yourself
• Bigode https://
mustache.github.io/
• Pseudopadrões do Pattern Lab http://

patternlab.io/docs/pattern-pseudo-patterns.html
• Web design responsivo

http://alistapart.com/article/responsive-web-design
• Consultas de contêiner: mais uma vez até a violação

http://alistapart.com/article/container-queries-once-more-unto-the-breach
• Ish
http://bradfrost.com/demo/ish/
• Exemplos de recursos de guias de estilo de sites

http://styleguides.io/examples.html
• Guia de estilo Rizzo

http://rizzo.lonelyplanet.com/
• Ferramentas de recursos do guia de estilo

do site http://styleguides.io/tools.html
RECURSOS 187
Capítulo 4
• Inventário de conteúdo
https://en.wikipedia.org/wiki/Content_inventory
• Modelo de inventário de interface do Apresentações Google

https://docs.google.com/presentation/d/1GqFmiDV_
NqKi36fXAwD3WTJL5-JV-gHL7XVD2fVeL0M/edit?usp=sharing
• O objeto de mídia salva centenas de linhas de código

http://www.stubbornella.org/content/2010/06/25/the-media-object-saves-
hundreds-of-lines-of-code/
• Revestindo Elementos Invisíveis

http://bradfrost.com/blog/post/surfacing-invisible-elements/
• Estatísticas
CSS http://cssstats.com/
• Estilize-me
http://stylifyme.com/ •
Design UX multitela http://

store.elsevier.com/Multiscreen-UX-Design/Wolfram-Nagel/
isbn-9780128027295/
• A era pós-PSD http://
danielmall.com/articles/the-post-psd-era/
• Alucinação consensual https://
adactio.com/journal/4443
• Modelo em cascata
https://en.wikipedia.org/wiki/Waterfall_model
• Desenvolvimento é Design
http://bradfrost.com/blog/post/development-is-design
• É hora de parar de mostrar aos clientes recursos visuais de design estáticos

https://stufandnonsense.co.uk/blog/about/
time_to_stop_showing_clients_static_design_visuals
• Dispositivos móveis primeiro
http://www.lukew.com/f/entry.asp?933 • Conteúdo
e padrões de exibição
http://danielmall.com/articles/content-display-patterns/
• Jennifer Brook
http://jenniferbrook.co/about

• O teste de “intestino” de 20 segundos

http://goodkickofmeetings.com/2010/04/the-20-second-gut-test/
• Blocos de
estilo http://styletil.es/
• Protótipo de estilo
http://sparkbox.github.io/style-prototype/
• Colagens de Elementos
http://danielmall.com/articles/rif-element-collages/
• Pilhas de ideias
http://jasonsantamaria.com/articles/piles-of-ideas
• CodePen
http://codepen.io/
• Dan Mall no Projeto Pastry Box https://the-

pastry-box-project.net/dan-mall/2012-september-12
capítulo 5
• Nathan Curtis no Twitter

https://twitter.com/nathanacurtis/status/656829204235972608 • Um Design
System não é um projeto. É um produto, servindo produtos. https://medium.com/

eightshapes-llc/a-design-system-isn-ta-project-it-sa-product-serving-
products-74dcffef935#.4umtnfxsx
• O modelo da equipe Salesforce para dimensionar um sistema de design

https://medium.com/salesforce-ux/the-salesforce-team-model-for-scaling-a-design-
system-d89c2a2d404b
• Estrutura baunilha
http://ubuntudesign.github.io/vanilla-framework/
• Preparando o Vanilla para v1: o roteiro http://

design.canonical.com/2016/07/getting-vanilla-ready-for-v1-the-roadmap/
• Sass obsoleto
https://github.com/salesforce-ux/sass-deprecate
• A maneira como construímos

http://airbnb.design/the-way-we-build/
RECURSOS 189
• Guia de estilo Rizzo

http://rizzo.lonelyplanet.com/ •
Perseguindo o Santo Graal

https://medium.com/@marcelosomers/chasing-the-holy-grail-
bbc0b7cce365#.ay1xeej7d
• Drupal
https://www.drupal.org
• Galho
http://twig.sensiolabs.org •
Apresentando o Pattern Lab Starter 8 https://

www.phase2technology.com/blog/introduzindo-pattern-lab-starter-8/
• Rascunho dos Padrões Digitais da Web

dos EUA https://standards.usa.gov/
• Gerenciando guias de estilo na Shyp

https://medium.com/shyp-design/managing-style-guides-at-shyp-c217116c8126
• Guias de estilo com Jina Bolton http://

styleguides.io/podcast/jina-bolton
• Podcasts de recursos do guia de estilo do site

http://styleguides.io/podcast

Sobre o autor
Brad Frost é web designer, palestrante,

consultor e músico localizado na bela
Pittsburgh, PA. Ele é apaixonado por criar
experiências na Web que tenham uma ótima
aparência e funcionem perfeitamente
em um fluxo interminável de dispositivos
conectados e adora ajudar outras pessoas a fazer o mesmo.
Ele ajudou a criar diversas ferramentas e recursos para web
designers, incluindo Pattern Lab (com Dave Olsen e Brian
Muenzenmeyer), Styleguides.io (com Anna Debenham), Isto é
responsivo, Web móvel WTF (com Jen Simmons) e Melhores Práticas para Web Móvel.
SOBRE O AUTOR 191

Nossa tarefa é criar interfaces para mais usuários em mais contextos, usando
mais navegadores, em mais dispositivos, com mais tamanhos de tela e mais recursos
do que nunca. Essa é uma tarefa realmente assustadora. Felizmente, os sistemas
de design estão aqui para ajudar.
O Atomic Design detalha tudo o que é necessário para criar e manter sistemas de
design robustos, permitindo que você implemente interfaces de usuário mais
consistentes e de maior qualidade com mais rapidez do que nunca. Este livro
apresenta uma metodologia para pensar em nossas UIs como hierarquias bem
pensadas, discute as qualidades de bibliotecas de padrões eficazes e apresenta
técnicas para transformar o fluxo de trabalho de design e desenvolvimento de sua
equipe.
Ir corajosamente além das “páginas”. Esse é o universo do design moderno e não

há melhor guia para explorá-lo do que Brad Frost. Em Atomic Design, ele substitui
nossos fluxos de trabalho fechados e desatualizados por novos e empolgantes fluxos
de trabalho colaborativos e nos ensina a projetar não apenas páginas, mas também sistemas.
Recomendado para todos os designers de web e interação.
- Jefrey Zeldman, autor, Projetando com padrões da Web
Brad está sugerindo que seríamos web designers melhores se pensássemos no que
estamos construindo como um sistema. Um sistema hierárquico que se encaixa para
formar partes maiores. Porque, alerta de spoiler, é e estaríamos.
- Chris Coyier, truques de CSS

Doku - Pub Atomic Design Brad Frostpdf

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

Doku - Pub Atomic Design Brad Frostpdf

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

2. Metodologia de Design Atômico

4. O fluxo de trabalho atômico

5. Manutenção de sistemas de design

Agradecimentos e Reconhecimentos 182

Sobre o autor 191

Copyright © 2016 Brad Frost Todos os direitos reservados

Editor: Brad Frost

Orgulhosamente criado em Pittsburgh, Pensilvânia

Nos estágios iniciais do redesenho do TechCrunch, houve um momento em que

incluindo sites de grande sucesso da Entertainment Weekly e Time, Inc.

O design atômico nos deu velocidade, liberdade criativa e flexibilidade.

Este livro maravilhoso explica a filosofia, prática e manutenção de

A energia e o grande entusiasmo de Brad pela web e seus criadores

Se tivesse oportunidade, Brad bateria na porta de cada designer e

O design atômico está explodindo em todo o mundo; transformou nossa

-Josh Clark e Dan Mall, Os colaboradores frequentes de Brad e seus

Há muito, muito tempo atrás, existiam essas coisas chamadas livros.

Nosso passado paginado

A página está conosco há muito tempo. Alguns milênios, na verdade. Os primeiros

Desde o início, a metáfora da página forneceu aos usuários uma linguagem

CAPÍTULO 1 / PROJETO DE SISTEMAS 9

Nos primórdios da web, as empresas que desejavam ficar on-line simplesmente

Mas já estamos há 25 anos neste novo meio de comunicação, e esta

“Somos uma startup que pretende lançar um site de cinco páginas em

“Brad, quanto tempo a página inicial levará para ser construída?”

Todas as afirmações acima cometem o erro fundamental de

Em última análise, o nível de esforço de um projeto é muito melhor determinado

A metáfora da página serviu ao seu propósito de ajudar os usuários a se familiarizarem

Felizmente, a comunidade da web está trabalhando arduamente para

A modularidade é muito anterior à web. A Revolução Industrial trouxe

CAPÍTULO 1 / PROJETO DE SISTEMAS 11

processo. Os primeiros carros e componentes foram fabricados individualmente, o que

À medida que a era da máquina se tornou a era do computador, os cientistas da

A resposta curta é que a modularidade é mais importante do que nunca. No momento,

A disrupção só irá acelerar. A quantidade e a diversidade de

- O manifesto Amigo do Futuro

Goste ou não, este universo multi-dispositivos é a nossa realidade. Já foi bastante

Para enfrentar esta realidade e ao mesmo tempo manter a nossa sanidade, é

E é exatamente isso que as pessoas estão fazendo. O espírito da modularidade está

Uma estratégia gerenciável

CAPÍTULO 1 / PROJETO DE SISTEMAS 13

Fora com o velho! Com o novo! É certamente uma perspectiva atraente.

Quando grandes reformulações são lançadas com mudanças significativas na

Além de desorientar os usuários, essas reformulações monolíticas não

Felizmente, até mesmo grandes organizações estão seguindo dicas do mundo

Afastar-se dos redesenhos do tipo "configure e esqueça" no estilo Ron

Em minúsculas, ágil é mais um desejo informal de criar um processo eficiente.

Queremos ser mais ágeis; estamos abraçando a mudança, a melhoria

A estrutura organizacional, as relações com os clientes, as personalidades e assim

Modularizando conteúdo: estou no Team Chunk

Prepare seu conteúdo para ir a qualquer lugar, porque ele irá a

- Por uma Web favorável ao futuro

CAPÍTULO 1 / PROJETO DE SISTEMAS 15

No futuro, acredito que teremos melhores ferramentas de gerenciamento

Felizmente, este futuro está começando a tomar forma. As organizações estão

A modularidade tem sido um princípio básico no mundo da ciência da

Apesar de existir desde 1995, o JavaScript, a linguagem de programação da

Aplicar princípios de programação modular ao JavaScript é um tanto óbvio, já que

A modularidade não está apenas infiltrando o lado do código do estilo na web,

À medida que o número de janelas de visualização e ambientes prolifera, torna-se insustentável

A atmosfera descreve os sentimentos que temos e que são

Estabelecer antecipadamente a atmosfera do design é fundamental para o