Módulo 4 · 2 de 6
Atomic Design: a arquitetura por trás dos componentes
Leitura: ~5 min
Talvez você já tenha vivido isso: o arquivo no Figma parece organizado, os componentes existem, as variantes também. Só que, quando o produto cresce, ninguém sabe mais o que pode ser reutilizado, o que é exceção e o que virou gambiarra visual com nome bonito.
Atomic Design ajuda justamente nesse ponto. Ele não é uma verdade absoluta nem a única forma possível de organizar um sistema. Mas é uma lente poderosa para sair da lógica de “telas prontas” e passar a pensar em arquitetura.
De tela pronta para sistema montável
Brad Frost propôs o Atomic Design olhando para interfaces como quem olha para matéria: existe um nível mais básico, depois combinações intermediárias e, por fim, estruturas completas. O ganho dessa lógica não é “seguir uma moda”. O ganho é conseguir conversar sobre complexidade em camadas.
- Átomos: os elementos indivisíveis do sistema. Um input, um botão, um ícone, um label, um avatar.
- Moléculas: combinações pequenas com uma função clara. Exemplo: input + label + mensagem de erro.
- Organismos: blocos maiores e mais compostos, como cabeçalhos, cards complexos ou seções de listagem.
- Templates: estruturas sem conteúdo definitivo, úteis para validar distribuição e hierarquia.
- Pages: a interface com conteúdo real, onde você testa se o sistema aguenta a vida de verdade.
Não é sobre decorar nomes. É sobre saber em que nível do sistema você está mexendo. Às vezes a discussão parece sobre uma “tela”, mas na verdade o problema está em um átomo mal definido que contamina vinte componentes depois.
Como usar essa lógica no Figma sem virar refém dela
O erro comum é transformar Atomic Design em burocracia. Nem todo arquivo precisa ter cinco páginas separadas com esse nome. O ponto é outro: manter uma separação clara entre fundação, combinação e contexto.
Uma forma simples de aplicar isso na prática:
- Defina primeiro os elementos básicos que realmente serão compartilhados.
- Monte combinações recorrentes antes de sair desenhando telas inteiras.
- Teste com conteúdo real cedo, para descobrir onde o sistema ainda não aguenta exceções.
Pense como LEGO. A pergunta não é “quantas peças eu tenho?”. A pergunta é “consigo montar coisas diferentes sem serrar a peça toda vez que o contexto muda?”.
Checagem rápida
Sem nota, sem pressão. Responda de cabeça e depois abra para conferir.
No review, o time olha o campo de busca do topo: é um input com um ícone de lupa e um botão "Buscar" do lado. Em que nível do Atomic Design você diria que esse conjunto está?
É uma molécula: uma combinação pequena de átomos (o input, o ícone e o botão) com uma função clara, buscar. Cada peça isolada é um átomo; juntas, com um propósito, viram uma molécula. Se você encaixar essa busca dentro do cabeçalho inteiro, com logo e navegação, aí sobe para organismo.
Um colega abre um chamado dizendo "essa tela está inconsistente". Como pensar em níveis muda o feedback que você dá?
Em vez de apontar a tela inteira, você localiza a origem: muitas vezes o problema não está "na tela", está em um átomo mal definido (por exemplo, o input que não acomoda todos os estados) que contamina vinte componentes depois. Nomear o nível transforma um feedback vago em algo acionável, e é isso que muda a sua presença em review e handoff.