Atomic Design — fondamenti, atomi, molecole e organismi nell'interfaccia utente

Cos'è l'Atomic Design?

L'Atomic Design è una metodologia per creare sistemi di interfacce gerarchici, in cui ogni elemento dell'interfaccia utente appartiene a uno dei cinque livelli: atomi (elementi di base), molecole (combinazioni di atomi), organismi (blocchi complessi), template (wireframe di pagina) e pagine (schermate specifiche con dati). L'analogia è presa in prestito dalla chimica: gli atomi si combinano in molecole, le molecole in organismi, gli organismi in template, i template vengono riempiti di contenuto e diventano pagine.

La metodologia è stata proposta dal web designer Brad Frost nel 2013 come risposta al problema del "pensiero basato sulle pagine" — quando ogni nuova schermata viene progettata da zero senza considerare i componenti esistenti. Nel libro "Atomic Design" (2016), Frost descrive l'implementazione della metodologia in progetti di grandi aziende: IBM, GE, Starbucks. Secondo Nielsen Norman Group (2022), l'Atomic Design riduce il tempo di progettazione di nuove schermate del 30–50% grazie al riutilizzo di componenti pronti.

L'Atomic Design non è tanto una tecnologia quanto una filosofia di organizzazione dell'interfaccia utente. Non è legato a un framework specifico ed è applicabile sia nel web (React, Vue) che nello sviluppo mobile (Jetpack Compose, SwiftUI). In IT Sectr, utilizziamo l'Atomic Design per costruire sistemi di design per i clienti: identifichiamo i componenti atomici nella fase di progettazione e li trasferiamo in componenti di codice in Compose/SwiftUI.

Cinque livelli: atomi, molecole, organismi, template, pagine

Ogni livello dell'Atomic Design risolve il proprio problema e ha un'area di responsabilità rigorosa. Gli atomi sono i più piccoli elementi costitutivi dell'interfaccia che non possono essere ulteriormente suddivisi senza perdere significato: pulsante, campo di testo, icona, etichetta, casella di controllo. Gli atomi non contengono logica di business e non dipendono dal contesto. Definiscono le caratteristiche visive di base: colore, dimensione, spaziatura, tipografia.

Le molecole sono combinazioni di due o più atomi che formano unità funzionali semplici. Un campo di input con etichetta e messaggio di errore è una molecola. Una scheda prodotto con immagine, nome e prezzo è una molecola. Le molecole possono contenere logica di base (mostrare/nascondere errore), ma non contengono processi di business. Le molecole sono il primo livello in cui i componenti diventano riutilizzabili su schermate diverse.

Gli organismi sono blocchi di interfaccia complessi composti da molecole e atomi che implementano una funzione specifica dell'applicazione. Un modulo di accesso (campo email, campo password, pulsante di invio, link "password dimenticata") è un organismo. Un'intestazione con logo, ricerca e navigazione è un organismo. Gli organismi possono contenere logica di business e accedere all'API, ma solo nell'ambito della loro funzione.

I template sono wireframe di pagina che definiscono la disposizione degli organismi sullo schermo senza contenuto specifico. Un template definisce la griglia, le colonne, le aree di contenuto — un wireframe a livello di codice. I template non contengono dati, solo segnaposti. Permettono di valutare la struttura della pagina prima di riempirla con il contenuto.

Le pagine sono schermate specifiche dell'applicazione in cui il template viene riempito con dati reali. A questo livello, si verifica l'aspetto dei componenti con contenuto reale (stringhe lunghe, dati mancanti, errori). Le pagine sono l'unico livello che l'utente finale vede. Le modifiche a livello di pagina non devono influenzare atomi, molecole e organismi — se un componente deve essere modificato, la modifica viene apportata al suo livello e la pagina lo recepisce automaticamente.

Vantaggi e limiti dell'Atomic Design

I vantaggi dell'Atomic Design diventano evidenti quando si scalano le interfacce. Una libreria di componenti unica garantisce la coerenza visiva: un pulsante appare uguale su tutte le schermate perché è lo stesso atomo. Secondo Brad Frost (2016), le aziende che hanno implementato l'Atomic Design riducono i tempi di sviluppo di nuove schermate del 30–50% grazie al riutilizzo di molecole e organismi pronti.

Limiti — l'Atomic Design non descrive come gestire lo stato dell'applicazione. La metodologia risponde solo alla domanda "come organizzare i componenti dell'interfaccia utente" ma non affronta la logica di business, il routing o la gestione dei dati. Il secondo limite è la difficoltà di definire i confini: dove finisce una molecola e dove inizia un organismo? In pratica, i confini sono sfumati e team diversi possono classificare lo stesso componente in modo diverso. Si consiglia di stabilire regole nei token di design e in un catalogo componenti (Storybook, Jetpack Compose Preview).

Il terzo limite è l'astrazione eccessiva per progetti piccoli. Se un'applicazione è composta da 5 schermate, creare una gerarchia di atomi e molecole è un lavoro inutile. L'Atomic Design diventa vantaggioso quando il numero di schermate supera 20 e i componenti vengono riutilizzati su pagine diverse.

Atomic Design vs Feature-Sliced Design

L'Atomic Design e il Feature-Sliced Design (FSD) risolvono problemi diversi e possono essere usati insieme. L'Atomic Design è una metodologia per organizzare i componenti dell'interfaccia utente, il FSD è una metodologia per organizzare i layer di business e l'applicazione nel suo complesso. L'Atomic Design risponde alla domanda "come suddividere l'interfaccia utente in parti riutilizzabili", il FSD risponde a "come organizzare il codice intorno alle funzionalità di business". Non sono in competizione: si può avere una struttura FSD con layer features ed entities, e all'interno di ogni layer utilizzare l'Atomic Design per organizzare i componenti dell'interfaccia utente.

Combinazione tipica: il FSD definisce la struttura modulare dell'applicazione (layer, slice), l'Atomic Design definisce la struttura interna dei componenti dell'interfaccia utente all'interno di ogni slice. Ad esempio, lo slice feature.auth contiene molecole (LoginForm, PasswordInput) e organismi (AuthPage) assemblati secondo le regole dell'Atomic Design. Il layer shared contiene atomi (Button, Input, Label) riutilizzati in tutte le funzionalità.

Atomic Design nelle applicazioni mobili: Compose e SwiftUI

Jetpack Compose e SwiftUI supportano naturalmente la gerarchia dell'Atomic Design attraverso la composizione dei componenti. Gli atomi in Compose sono funzioni @Composable di base: AppButton, AppTextField, AppCheckbox. Ogni funzione accetta parametri di personalizzazione (colore, dimensione, stato) e non contiene logica di business. Gli atomi sono definiti nel layer shared ed esportati come kit dell'interfaccia utente.

Le molecole sono funzioni @Composable che combinano più atomi: LabeledTextField (etichetta + campo di input + messaggio di errore), ProductCard (immagine + nome + prezzo). Le molecole possono contenere stato di base (validità del campo) ma non accedono all'API o alla ViewModel. Vengono riutilizzate in diversi organismi.

Gli organismi sono funzioni @Composable a livello di funzionalità: LoginForm (LabeledTextField per l'email + LabeledTextField per la password + AppButton di invio + link di recupero). Gli organismi lavorano con la ViewModel tramite funzioni Intent e possono contenere logica di business. In SwiftUI, una gerarchia simile viene costruita tramite @ViewBuilder e strutture View personalizzate.

In SwiftUI, un atomo è una struttura View personalizzata AppButton, una molecola è un campo di input con etichetta su HStack, un organismo è un modulo di accesso. Questa struttura consente di riutilizzare i componenti su tutte le schermate — la modifica di un atomo (colore del pulsante) si applica automaticamente a tutte le schermate. La combinazione dell'Atomic Design con un sistema di design garantisce la coerenza dell'interfaccia senza controllo manuale di ogni schermata.