Atomic Design — fundamentos, átomos, moléculas e organismos na UI

O que é Atomic Design?

Atomic Design é uma metodologia para criar sistemas hierárquicos de interfaces, onde cada elemento de UI pertence a um dos cinco níveis: átomos (elementos básicos), moléculas (combinações de átomos), organismos (blocos complexos), templates (wireframes de página) e páginas (telas específicas com dados). A analogia é emprestada da química: átomos se combinam em moléculas, moléculas em organismos, organismos em templates, templates são preenchidos com conteúdo e se tornam páginas.

A metodologia foi proposta pelo designer web Brad Frost em 2013 como resposta ao problema do "pensamento de página" — quando cada nova tela é projetada do zero sem considerar os componentes existentes. No livro "Atomic Design" (2016), Frost descreve a implementação da metodologia em projetos de grandes empresas: IBM, GE, Starbucks. Segundo Nielsen Norman Group (2022), o Atomic Design reduz o tempo de design de novas telas em 30–50% através do reuso de componentes prontos.

Atomic Design não é tanto uma tecnologia quanto uma filosofia de organização da UI. Não está vinculado a um framework específico e é aplicável tanto na web (React, Vue) quanto no desenvolvimento mobile (Jetpack Compose, SwiftUI). Na IT Sectr, usamos Atomic Design para construir sistemas de design para clientes: identificamos componentes atômicos na fase de design e os transferimos para componentes de código em Compose/SwiftUI.

Cinco níveis: átomos, moléculas, organismos, templates, páginas

Cada nível do Atomic Design resolve seu próprio problema e tem uma área de responsabilidade estrita. Átomos são os menores blocos de construção da interface que não podem ser divididos sem perder significado: botão, campo de texto, ícone, label, checkbox. Átomos não contêm lógica de negócio e não dependem de contexto. Eles definem características visuais básicas: cor, tamanho, espaçamento, tipografia.

Moléculas são combinações de dois ou mais átomos que formam unidades funcionais simples. Um campo de entrada com label e mensagem de erro é uma molécula. Um card de produto com imagem, nome e preço é uma molécula. Moléculas podem conter lógica básica (mostrar/esconder erro), mas não contêm processos de negócio. Moléculas são o primeiro nível em que os componentes se tornam reutilizáveis em diferentes telas.

Organismos são blocos de interface complexos compostos por moléculas e átomos que implementam uma função específica da aplicação. Um formulário de login (campo de email, campo de senha, botão de envio, link "esqueci a senha") é um organismo. Um cabeçalho com logotipo, busca e navegação é um organismo. Organismos podem conter lógica de negócio e acessar a API, mas apenas dentro de sua função.

Templates são wireframes de página que definem o arranjo dos organismos na tela sem conteúdo específico. Um template define a grade, colunas, áreas de conteúdo — um wireframe no nível de código. Templates não contêm dados, apenas placeholders. Eles permitem avaliar a estrutura da página antes de preenchê-la com conteúdo.

Páginas são telas específicas da aplicação onde o template é preenchido com dados reais. Neste nível, verifica-se como os componentes se parecem com conteúdo real (strings longas, dados ausentes, erros). Páginas são o único nível que o usuário final vê. Mudanças no nível de página não devem afetar átomos, moléculas e organismos — se um componente precisa ser alterado, a mudança é feita em seu nível, e a página o absorve automaticamente.

Vantagens e limitações do Atomic Design

Vantagens do Atomic Design se tornam evidentes ao escalar interfaces. Uma biblioteca única de componentes garante consistência visual: um botão parece o mesmo em todas as telas porque é o mesmo átomo. Segundo Brad Frost (2016), empresas que implementaram Atomic Design reduzem o tempo de desenvolvimento de novas telas em 30–50% através do reuso de moléculas e organismos prontos.

Limitações — Atomic Design não descreve como gerenciar o estado da aplicação. A metodologia apenas responde à pergunta "como organizar os componentes de UI" mas não aborda lógica de negócio, roteamento ou gerenciamento de dados. A segunda limitação é a dificuldade de definir limites: onde termina uma molécula e começa um organismo? Na prática, os limites são difusos, e diferentes equipes podem classificar o mesmo componente de forma diferente. Recomenda-se estabelecer regras em tokens de design e em um catálogo de componentes (Storybook, Jetpack Compose Preview).

A terceira limitação é a abstração excessiva para projetos pequenos. Se uma aplicação consiste em 5 telas, criar uma hierarquia de átomos e moléculas é trabalho desnecessário. Atomic Design se torna benéfico quando o número de telas excede 20 e os componentes são reutilizados em diferentes páginas.

Atomic Design vs Feature-Sliced Design

Atomic Design e Feature-Sliced Design (FSD) resolvem problemas diferentes e podem ser usados juntos. Atomic Design é uma metodologia para organizar componentes de UI, FSD é uma metodologia para organizar camadas de negócio e a aplicação como um todo. Atomic Design responde à pergunta "como dividir a UI em partes reutilizáveis", FSD responde a "como organizar o código em torno de funcionalidades de negócio". Eles não competem: você pode ter uma estrutura FSD com camadas features e entities, e dentro de cada camada usar Atomic Design para organizar os componentes de UI.

Combinação típica: FSD define a estrutura modular da aplicação (camadas, slices), Atomic Design define a estrutura interna dos componentes de UI dentro de cada slice. Por exemplo, o slice feature.auth contém moléculas (LoginForm, PasswordInput) e organismos (AuthPage) montados de acordo com as regras do Atomic Design. A camada shared contém átomos (Button, Input, Label) reutilizados em todas as funcionalidades.

Atomic Design em aplicativos móveis: Compose e SwiftUI

Jetpack Compose e SwiftUI suportam naturalmente a hierarquia do Atomic Design através da composição de componentes. Átomos no Compose são funções @Composable básicas: AppButton, AppTextField, AppCheckbox. Cada função aceita parâmetros de customização (cor, tamanho, estado) e não contém lógica de negócio. Átomos são definidos na camada shared e exportados como um UI-kit.

Moléculas são funções @Composable que combinam vários átomos: LabeledTextField (label + campo de entrada + mensagem de erro), ProductCard (imagem + nome + preço). Moléculas podem conter estado básico (validade do campo) mas não acessam API ou ViewModel. Elas são reutilizadas em diferentes organismos.

Organismos são funções @Composable no nível de funcionalidade: LoginForm (LabeledTextField para email + LabeledTextField para senha + AppButton de envio + link de recuperação). Organismos trabalham com ViewModel através de funções Intent e podem conter lógica de negócio. No SwiftUI, uma hierarquia similar é construída através de @ViewBuilder e estruturas View personalizadas.

No SwiftUI, um átomo é uma estrutura View personalizada AppButton, uma molécula é um campo de entrada com label em HStack, um organismo é um formulário de login. Essa estrutura permite reutilizar componentes em todas as telas — alterar um átomo (cor do botão) aplica-se automaticamente a todas as telas. A combinação do Atomic Design com um sistema de design garante consistência da interface sem controle manual de cada tela.