DLS do Airbnb: o sistema que recusou o atomic design

No relato publicado pela própria equipe de design sobre o DLS, a escolha estrutural fundadora é declarada diretamente: em vez de depender de átomos individuais, eles consideraram os componentes como elementos de um organismo vivo — cada um com uma função e uma personalidade, definidos por um conjunto de propriedades, capazes de coexistir com outros e de evoluir ou morrer independentemente. O benefício declarado é a ausência de uma rede complicada de partes interconectadas.

Isso é uma rejeição ao atomic design, feita por uma equipe que tinha os recursos para implementá-lo adequadamente e escolheu não fazê-lo. Vale a pena levar isso a sério, em vez de tratar como uma preferência estilística, porque o raciocínio é generalizável.

Nenhuma das colunas está correta em geral. A resposta certa depende de qual modo de falha você pode tolerar. Um produto web de plataforma única com uma equipe pequena consegue absorver o risco de propagação e obtém valor real do reuso. Um sistema que abrange iOS, Android, tablet e web não consegue, porque a árvore de átomos teria que ser reproduzida identicamente em Swift, Kotlin e qualquer que seja a stack web daquele ano — e ela não será.

Um detalhe do relato sobre o DLS explica toda a filosofia melhor do que a própria filosofia. Em vez de ter linhas divisoras como elementos próprios entre componentes, cada componente deve conter seu próprio divisor, exibido ou oculto pela lógica de visualização.

Considere o custo da alternativa. Se os divisores vivem entre componentes, então a exibição de um divisor é uma propriedade da lista, não da linha — portanto, a lista precisa saber que aquela é a última linha, em quatro plataformas, em quatro bases de código, inclusive no caso em que uma linha é ocultada condicionalmente. Cada implementação de lista reimplementa essa lógica e uma delas acaba errando. Mova o divisor para dentro da linha e a regra torna-se local: a linha sabe se deve desenhar sua própria borda inferior, e nada acima dela precisa raciocinar sobre a posição.

O mesmo documento observa que os elementos que definem cada componente foram declarados tanto no arquivo do Sketch quanto no código. Essa é a outra metade do contrato: um componente não é definido por sua renderização em qualquer plataforma, mas pela lista de coisas que ele deve conter. Sketch e Swift são duas implementações da mesma declaração.

O DLS é descrito como majoritariamente agnóstico a plataforma — a maioria dos componentes parece e funciona da mesma forma no iOS e no Android — enquanto segue deliberadamente as convenções nativas em uma lista curta de itens: navegação, iconografia do sistema, ações contextuais e interações. A barra de navegação do Android difere da do iOS e usa um ícone diferente, por design.

A lista curta é a parte interessante. Um sistema que busca paridade total produz um app que parece estrangeiro em ambas as plataformas; um sistema que se curva às convenções da plataforma em tudo produz dois produtos que compartilham apenas um logo. O DLS traça a linha nos elementos que os usuários aprenderam com o sistema operacional, e não com o seu produto. A navegação de retorno é uma convenção do SO. Uma linha de preços não é.

O mesmo documento observa que o sistema foi construído para que códigos, componentes e designs idênticos funcionem em diferentes tamanhos de dispositivo, com um pequeno conjunto de regras de layout lidando com a transformação para tablet. Esse é o mesmo princípio aplicado a um eixo diferente: mantenha uma definição, adicione regras para o eixo que genuinamente varia.

O fio condutor de tudo isso é que a unidade de verdade do DLS é uma declaração, não uma implementação. Um componente é um nome mais uma lista de elementos obrigatórios, elementos opcionais e propriedades comportamentais. Swift, Kotlin, o build web e a biblioteca do Sketch são quatro renderizações dessa declaração.

É por isso que a abordagem escalou entre plataformas, enquanto uma abordagem de árvore de átomos não teria escalado. Um contrato pode ser satisfeito por qualquer implementação. Uma árvore de composição só pode ser satisfeita reproduzindo a árvore, e no momento em que o framework de uma plataforma torna isso complicado, alguém cria um contorno e os sistemas divergem.

É também por isso que o modelo se aplica a uma plataforma em que ninguém pensava em 2015.

Quando um agente de código escreve sua interface, ele está fazendo exatamente o que a equipe de iOS fez: renderizando seu sistema em um ambiente com seus próprios idiotismos e restrições, a partir de qualquer definição que você tenha fornecido. Cada pergunta que o DLS teve que responder retorna inalterada.

A última linha é a diferença prática, e é por isso que isso importa mais agora do que antes. Um desvio cross-platform leva um ciclo de release para aparecer e um designer percebe. O desvio de um agente aparece em uma única sessão, entre dois arquivos, e ninguém percebe até a terceira tela.

Analisamos 299 arquivos DESIGN.md publicados para leitura de agentes de IA para ver quanto de um contrato eles realmente contêm. 86% especificavam cores como valores hexadecimais puros, sem função atribuída — uma lista de valores, não um contrato. 76% não continham proibições de qualquer tipo. 44% não continham nenhum valor de tamanho concreto em lugar nenhum, e 54% baseavam-se em pelo menos um adjetivo vago, sendo os mais comuns "clean" (39%) ou "modern" (36%).

Um arquivo assim é a falha do atomic design em forma de prosa. Ele entrega partes sem declarar para que servem, e cada tela que o agente escreve as remonta de forma diferente. O que o DLS teria escrito em vez disso seria uma declaração: este componente requer estes elementos, esta cor tem esta função, isso não é permitido.

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

Isso representa trinta segundos de escrita, e é a diferença entre um agente que produz o mesmo card na tela quatorze e um que inventa um novo.

O DLS não está disponível para instalação, e tentar replicar seu resultado visual seria o exercício errado de qualquer maneira — ele foi projetado para um marketplace de viagens com fotografia como conteúdo principal, que é um problema específico que a maioria dos produtos não possui.

O que é transferível são três decisões, todas com custo zero de adoção:

1. Defina componentes por contrato, não por composição. Documente os elementos obrigatórios, elementos opcionais e propriedades. Deixe que a implementação seja o que cada destino precisar.
2. Empurre visuais dependentes de contexto para dentro do componente. A regra do divisor, generalizada. Se um container precisa saber algo sobre seus filhos para renderizá-los corretamente, você colocou a lógica no lugar errado.
3. Nomeie a lista curta de coisas que podem divergir. Todo o resto é unificado por padrão. Um sistema sem essa lista ou força uma paridade falsa ou diverge em todos os lugares.

Nenhuma dessas coisas exige uma equipe de design systems, uma biblioteca Sketch ou quatro plataformas. Elas exigem decidir o que são seus componentes, que é o trabalho que a maioria dos sistemas pula no caminho para a escolha das cores.