Atomic design na era dos agentes: o que ainda se sustenta

O atomic design propôs que as interfaces fossem entendidas como uma hierarquia: átomos (um rótulo, um input, um botão), moléculas (um formulário de busca), organismos (um cabeçalho de site), templates (layout de nível de página sem conteúdo) e páginas (um template com conteúdo real).

Vale a pena lembrar o contexto. Em 2013, a maior parte do trabalho de front-end era baseada em páginas. Designers entregavam comps de páginas individuais; desenvolvedores construíam páginas individuais; o mesmo botão existia em onze formas ligeiramente diferentes e ninguém tinha um nome para esse problema. O atomic design deu às equipes um vocabulário compartilhado e, mais importante, o argumento de que as interfaces deveriam ser compostas a partir de um sistema, em vez de desenhadas página por página.

Esse argumento venceu completamente. Todo framework baseado em componentes, todo design system e toda camada de design tokens em uso atualmente assume isso. Quando as pessoas dizem que o atomic design morreu, geralmente querem dizer que sua conclusão se tornou o padrão e sua terminologia se tornou opcional — que é exatamente como se parece a vitória para uma metodologia.

Os cinco níveis não são igualmente úteis, e fingir que são é onde as equipes perdem tempo. Ordenados por quanto debate cada um gera por unidade de valor:

A questão da linha de moléculas não é mero preciosismo. Pergunte a cinco engenheiros se um card com imagem, título e botão é uma molécula ou um organismo e você terá uma conversa de quarenta minutos sem qualquer consequência prática. Qualquer nível de taxonomia cuja fronteira não possa ser decidida rapidamente e que não altere a forma como algo é construído é apenas overhead.

Existe uma crítica mais forte do que "os rótulos são meticulosos demais", e ela vem de um time que teve os recursos para implementar o atomic design adequadamente e escolheu não fazê-lo.

A equipe de design do Airbnb publicou que, em vez de depender de átomos individuais, eles trataram os componentes como elementos de um organismo vivo — cada um com uma função e personalidade, definidos por um conjunto de propriedades, capazes de coexistir e de evoluir ou morrer independentemente. O benefício declarado foi evitar uma rede complicada de partes interconectadas.

Este é um trade real, não uma preferência:

Nenhuma das colunas está correta de forma geral. Um produto web de plataforma única com uma única base de código obtém valor real do reuso máximo e pode absorver o risco de propagação. Um sistema que abrange quatro plataformas não pode, porque a árvore de átomos teria que ser reproduzida identicamente em cada uma, e não será. O Airbnb tinha quatro plataformas.

Aqui está a parte genuinamente nova, e ela corta em uma direção inesperada.

A principal contribuição do atomic design foi um vocabulário compartilhado. Ele permitiu que um designer, um engenheiro e um gerente de produto apontassem para a mesma coisa e quisessem dizer a mesma coisa. Um agente de código não precisa disso. Ele já sabe o que são um botão, um card, uma barra de navegação e uma tabela de dados, em detalhes imensos, em qualquer framework que você utilize. O problema de nomenclatura que o atomic design resolveu não é um problema que um agente tenha.

O que falta a um agente está em outro lugar inteiramente:

As três linhas inferiores estão vazias à esquerda, e isso não é uma crítica à metodologia — ela nunca tentou preenchê-las. É um motivo para não esperar que ela ajude com o problema atual.

Analisamos 299 arquivos DESIGN.md escritos para dar orientações de design a agentes, e o vazio também aparece ali. 76% não contêm proibições de qualquer tipo. 86% especificam cores como hexadecimais puros, sem função semântica. 57% não definem motivos distintos. 44% não contêm nenhum valor de tamanho concreto em lugar nenhum, e 54% dependem de pelo menos um adjetivo vago — "clean" em 39%, "moderno" em 36%.

Um arquivo organizado impecavelmente por átomos, moléculas e organismos, mas que não contenha nada disso, produzirá uma interface genérica bem estruturada. A taxonomia nunca foi a restrição determinante.

Não uma nova taxonomia. O movimento útil é manter a disciplina composicional — que todos já possuem — e adicionar as camadas que o atomic design nunca cobriu.

1. 1

   Mantenha a hierarquia, descarte a discussão

   Primitivos, componentes, layouts. Três níveis, decidíveis instantaneamente. Se sua equipe já concorda com átomos/moléculas/organismos e isso não custa nada, mantenha — os rótulos não são o problema, a discussão é.

2. 2

   Defina componentes por contrato, não por composição

   Escreva os elementos obrigatórios, elementos opcionais e propriedades. "Um card requer um título e texto de apoio, opcionalmente uma imagem, um badge e uma ação no rodapé." Essa afirmação sobrevive a qualquer implementação, inclusive a uma escrita por um agente em um framework que você não previu.

3. 3

   Adicione a camada de restrição

   A lista de coisas que nunca são feitas. Sem gradientes, sem elevação de sombra, sem peso de fonte acima de 600, sem cores fora do conjunto de tokens. Esta é a camada que mais altera o resultado gerado e a camada que a maioria dos sistemas não possui.

4. 4

   Adicione a camada de intenção

   Para que serve o design e quem o lê. Uma ferramenta densa para pessoas que passam o dia nela e uma página de marketing que alguém escaneia por quarenta segundos exigem decisões opostas, e nenhuma hierarquia de componentes codifica qual delas você está criando.

O segundo passo vale a pena ser expandido, pois é a parte que melhor se transfere para o código escrito por agentes. Um contrato pode ser satisfeito por qualquer implementação; uma árvore de composição só pode ser satisfeita reproduzindo a árvore. Quando o implementador é um modelo que pode optar por uma estrutura diferente da sua, um contrato se mantém e uma árvore não.

## Card

Required: title, supporting text
Optional: image, badge, footer action
Contains its own bottom divider; hidden when last in a list.

Padding 16px. Radius 12px. Border 1px --border-subtle.
Never uses a drop shadow — elevation is a surface step.
Never uses the accent colour for its border or background.

Nove linhas, e cada uma delas é verificável. Note quanto disso é proibição. Essa proporção é a diferença entre uma especificação e uma descrição.

Não, e essa abordagem não é útil. O atomic design defendeu que interfaces são sistemas compostos. Esse argumento agora é tão amplamente aceito que se tornou invisível — está incorporado ao React, a cada ferramenta de design, a cada design system publicado desde então. Você não pode descartá-lo, porque você já está dentro dele.

O que expirou foi a ideia de que a taxonomia é a entrega final. Um sistema organizado em cinco níveis nomeados, mas que não contém restrições, funções ou declarações de intenção, é apenas um esquema de arquivamento. Ele produzirá interfaces consistentes, bem estruturadas e inteiramente intercambiáveis, o que nunca foi o objetivo.

O trabalho que resta é aquele que o atomic design deliberadamente deixou de fora: decidir para que serve o seu design, o que ele se recusa a fazer e escrever ambos em algum lugar que a ferramenta que constrói sua interface realmente leia.