Em junho de 2013 o front-end designer Brad Frost publicou em seu blog um texto chamado Atomic Design. Este texto propõe um nova maneira de construir interfaces digitais, e não é exagero dizer que ele revolucionou o trabalho de designers e desenvolvedores pelo mundo todo.

We’re not designing pages, we’re designing systems of components.
— Stephen Hay

O conceito evoluiu. Virou palestra, livro e workshop. Gerou comunidades e estimulou debates entre designers e desenvolvedores. Mas afinal, como aplicar todos os esses novos conceitos atômicos?

Por ser um conceito mais abstrato do que metodológico, alguns times que trabalham de forma ágil começaram a se questionar sobre a viabilidade da proposta. Dessas dúvidas, destacarei três delas, as que mais me desafiaram no processo de trazer para o dia-a-dia a proposta atômica.

Um breve histórico do Atomic Design

Bom, se você ainda não está familiarizado com o tema, sugiro começar pelo artigo original, do próprio Brad. E para entender como o Atomic Design pode ser usado na prática, recomendo o episódio 04 da série Lean Redesign, sucesso de audiência no nosso blog!

Indo direto ao ponto, para resumir em uma frase: o Atomic Design é um conceito hierárquico para construção de interfaces digitais.

Toda a ideia se baseia no princípio de construir componentes de interfaces mínimos (botões, ícones, títulos, labels…), e combiná-los para montar estruturas mais complexas até conseguirmos montar páginas inteiras. Muito similar ao LEGO™ em muitos aspectos. E para ilustrar os conceitos, buscou-se na química a metáfora dos átomos que se aglutinam e formam estruturas maiores.

E por que isso é importante? Quem já passou pela experiência de fazer ajustes em dezenas de telas de interface direto no software de desenho sabe o quão trabalhoso e ingrato é fazer retrabalho (pra não dizer coisa pior). Sério, ninguém merece gastar tempo e energia fazendo edições de pixels toda vez que o cliente pedir para aumentar o tamanho do botão ou trocar a cor dos links do site/sistema.

As mudanças propostas pelo Atomic Design estimulam que o time de design converse sobre as decisões que precisam ser tomadas na interface com base no que o navegador mostra. Assim, as mudanças em grande quantidade são facilitadas com o uso do CSS e das bibliotecas de estilo. A conversa passa a ser menos sobre telas e mais sobre pequenos componentes.

Veja a imagem a seguir para entender como esses elementos se combinam:

O contexto de desenvolvimento ágil

Se você já acompanha o Taller, sabe que somos entusiastas da agilidade. Aliás, temos uma categoria dedicada só ao desenvolvimento ágil. E se está se familiarizando com o tema agora, nosso infoquadrinho é um bom ponto de partida.

Aqui usamos o Método Kanban para termos um processo evolucionário de melhoria contínua. O Atomic Design não fala nada sobre como utilizá-lo em contextos de times ágeis, mas como o Atomic Design é em si um processo evolucionário de melhoria contínua da interface dos produto que estamos criando, então Kanban e Atomic se encaixaram como uma luva!

O próprio autor faz questão de frisar que as duas áreas não estão intrinsecamentes relacionadas, embora tenham muito em comum.

Nas palavras do autor:

Atomic design:
“não é um processo linear”
“não é um passo-a-passo”
“não é um dogma rígido”
“não é ágil”

Já que nos deparamos com essa série de perguntas fundamentais sobre esse novo processo de trabalho, resolvemos compartilhar alguns caminhos que descobrimos por aqui.

1. Devemos criar histórias para páginas inteiras do sistema?

R: Não.

A ideia é dividir as páginas por áreas de valor do sistema. Com exemplos fica mais fácil de entender. Digamos que eu queira criar a home de um site. Se pararmos para pensar na sua estrutura, teremos uma combinação de área de destaque (hero), área de descrição da empresa, área de cases, área que chama para os serviços, newsletter e rodapé.

E por qual dessas partes é melhor começar? Pelo o que é mais importante, uai!

São as áreas mais importantes que vão ditar a sequência dos componentes que iremos desenvolver. Afinal, por que pensar nos detalhes de áreas que ainda estão longe de serem feitas no código? Calm down, jovem… A ideia é sempre pensar em pequenas partes, e priorizá-las.

Dica: A primeira história é sempre mais demorada, pois leva em consideração a criação da base dos átomos (cores, fontes e tamanhos).

2. Devemos criar colunas no board para cada etapa de trabalho?

R: Não.

Para evitar que o quadro do kanban tivesse muitas colunas, e isso é um problema quando o processo de trabalho tem muitas etapas, criamos uma coluna responsável por concentrar as decisões de design: a coluna de análise!

Ela foi criada originalmente para descrever as necessidades específicas das áreas que serão feitas para que os desenvolvedores pudessem começar a história com confiança.

Consideramos que a interface desenhada pelo time de design é, também, uma forma de conversar com o desenvolvedor sobre o que precisa ser criado em código. Então, a coluna de análise acaba servindo tanto para desenhar algo difícil de explicar em palavras e para ser um momento para detalhar os objetivos da tarefa.

Obs.: Como algumas atividades de design não precisam passar pelo desenvolvimento, em alguns casos, as histórias pularão dela da análise para a coluna de revisão.

3. Como lidar com a evolução dos componentes?

R: Compartilhando.

Depois de todo o esforço e mobilização para criar o guia de estilo atômico, o trabalho não acaba quando o último componente é criado. Na verdade, não existe fim para esse trabalho. Sim, amigas e amigos, o trabalho é infinito. Mas isso é bom! Significa que a interface evoluirá de forma incremental a cada feedback que recebermos dos clientes e dos usuários.

Tendo isso em mente, não faz mais sentido os arquivos de design estarem nas mãos apenas dos designers. Quanto mais liberdade e autonomia criativa os desenvolvedores tiverem, melhor pra todos.

Já existem serviços que sincronizam os arquivos do Photoshop (ou Sketch – bem melhor) na nuvem eliminando a necessidade de todos terem os programas instalados em suas máquinas. Zeplin e Simpli se destacam nessa categoria.

Os estudos continuam…

Questões como essas são apenas a ponta de um iceberg de uma nova forma de se construir interfaces digitais. Na medida que novos cases começarem a aparecer, o conceito ficará mais maduro. Em comunidades como a Design Systems, o IxDA Brasil no Slack e o ModularUI no Facebook, podemos acompanhar o que de mais novo está surgindo. Inclusive com a participação do próprio Brad Frost.

E vocês, como estão lidando com os desafios de aplicar o Atomic Design no contexto de vocês?

Vamos continuar essa conversa nos comentários.

***

Este artigo foi publicado originalmente em: http://blog.taller.net.br/atomic-design-no-contexto-de-um-time-agil/