Atomic Design — basis, atomen, moleculen en organismen in UI

Wat is Atomic Design?

Atomic Design — methodologie voor het creëren van hiërarchische interfacesystemen, waarbij elk UI-element tot een van de vijf niveaus behoort: atomen (basiselementen), moleculen (combinaties van atomen), organismen (complexe blokken), sjablonen (paginaskelets) en pagina's (concrete schermen met gegevens). De analogie komt uit de chemie: atomen combineren tot moleculen, moleculen tot organismen, organismen tot sjablonen, sjablonen worden gevuld met inhoud en worden pagina's.

De methodologie werd in 2013 voorgesteld door webdesigner Brad Frost als antwoord op het probleem van "paginagericht denken" — wanneer elk nieuw scherm vanaf nul wordt ontworpen zonder rekening te houden met bestaande componenten. In het boek "Atomic Design" (2016) beschrijft Frost de implementatie van de methodologie in projecten van grote bedrijven: IBM, GE, Starbucks. Volgens Nielsen Norman Group (2022) verkort Atomic Design de ontwerptijd van nieuwe schermen met 30–50% door herbruik van kant-en-klare componenten.

Atomic Design — is niet zozeer een technologie, maar een filosofie van UI-organisatie. Het is niet gebonden aan een specifiek framework en is toepasbaar zowel in het web (React, Vue) als in mobiele ontwikkeling (Jetpack Compose, SwiftUI). Bij IT Sectr gebruiken we Atomic Design voor het bouwen van designsystemen voor klanten: we onderscheiden atomaire componenten in de ontwerpfase en zetten ze over naar codecomponenten in Compose/SwiftUI.

Vijf niveaus: atomen, moleculen, organismen, sjablonen, pagina's

Elk niveau van Atomic Design lost zijn eigen taak op en heeft een strikt verantwoordelijkheidsgebied. Atomen — de kleinste bouwstenen van de interface, die niet verder kunnen worden opgesplitst zonder verlies van betekenis: knop, tekstveld, pictogram, label, selectievakje. Atomen bevatten geen bedrijfslogica en zijn niet afhankelijk van context. Ze bepalen de basis visuele kenmerken: kleur, grootte, marges, typografie.

Moleculen — combinaties van twee of meer atomen die eenvoudige functionele eenheden vormen. Een invoerveld met een label en foutmelding — molecuul. Een productkaart met afbeelding, naam en prijs — molecuul. Moleculen kunnen basislogica bevatten (toon/verberg fout), maar bevatten geen bedrijfsprocessen. Moleculen zijn het eerste niveau waarop componenten herbruikbaar worden tussen verschillende schermen.

Organismen — complexe interfaceblokken, bestaande uit moleculen en atomen, die een specifieke functie van de applicatie implementeren. Het inlogformulier (e-mailveld, wachtwoordveld, verzendknop, link "wachtwoord vergeten") — organisme. De header met logo, zoekopdracht en navigatie — organisme. Organismen kunnen bedrijfslogica bevatten en API's aanroepen, maar alleen binnen hun functie.

Sjablonen — paginaskelets die de plaatsing van organismen op het scherm bepalen zonder concrete inhoud. Het sjabloon definieert het raster, kolommen, contentzones — wireframe op codeniveau. Sjablonen bevatten geen gegevens, alleen plaatsaanduidingen. Ze maken het mogelijk de paginastructuur te beoordelen voordat deze met inhoud wordt gevuld.

Pagina's — concrete schermen van de applicatie, waarbij het sjabloon is gevuld met echte gegevens. Op dit niveau wordt gecontroleerd hoe componenten eruitzien met echte inhoud (lange regels, ontbrekende gegevens, fouten). Pagina's zijn het enige niveau dat de eindgebruiker ziet. Wijzigingen op paginaniveau mogen geen invloed hebben op atomen, moleculen en organismen — als een component moet worden gewijzigd, wordt de wijziging op zijn niveau doorgevoerd en neemt de pagina deze automatisch over.

Voordelen en beperkingen van Atomic Design

Voordelen van Atomic Design komen tot uiting bij het schalen van interfaces. Een uniforme componentenbibliotheek garandeert visuele consistentie: een knop ziet er op alle schermen hetzelfde uit, omdat het dezelfde atoom is. Volgens Brad Frost (2016) verkorten bedrijven die Atomic Design hebben geïmplementeerd de ontwikkeltijd van nieuwe schermen met 30–50% door herbruik van kant-en-klare moleculen en organismen.

Beperkingen — Atomic Design beschrijft niet hoe de applicatiestatus moet worden beheerd. De methodologie beantwoordt alleen de vraag "hoe UI-componenten te organiseren", maar raakt niet aan bedrijfslogica, routing of gegevensverwerking. Een tweede beperking — de moeilijkheid om grenzen te bepalen: waar eindigt het molecuul en begint het organisme? In de praktijk zijn de grenzen vaag en verschillende teams kunnen hetzelfde component anders classificeren. Het wordt aanbevolen om regels vast te leggen in designtokens en de componentencatalogus (Storybook, Jetpack Compose Preview).

Een derde beperking — overmatige abstractie voor kleine projecten. Als de applicatie uit 5 schermen bestaat, is het creëren van een hiërarchie van atomen en moleculen overbodig werk. Atomic Design wordt voordelig wanneer het aantal schermen groter is dan 20 en componenten op verschillende pagina's worden hergebruikt.

Atomic Design versus Feature-Sliced Design

Atomic Design en Feature-Sliced Design (FSD) lossen verschillende taken op en kunnen samen worden gebruikt. Atomic Design is een methodologie voor het organiseren van UI-componenten, FSD — een methodologie voor het organiseren van bedrijfslagen en de hele applicatie. Atomic Design beantwoordt de vraag "hoe de UI in herbruikbare delen te verdelen", FSD — "hoe code rond bedrijfsfuncties te organiseren". Ze concurreren niet: men kan een FSD-structuur hebben met features- en entities-lagen, en binnen elke laag Atomic Design gebruiken voor het organiseren van UI-componenten.

Typische combinatie: FSD definieert de modulaire structuur van de applicatie (lagen, slices), Atomic Design — de interne structuur van UI-componenten binnen elke slice. Bijvoorbeeld, de slice feature.auth bevat moleculen (LoginForm, PasswordInput) en organismen (AuthPage), samengesteld volgens de regels van Atomic Design. De shared-laag bevat atomen (Button, Input, Label), herbruikbaar in alle functies.

Atomic Design in mobiele apps: Compose en SwiftUI

Jetpack Compose en SwiftUI ondersteunen op natuurlijke wijze de Atomic Design-hiërarchie door componentcompositie. Atomen in Compose — basis @Composable-functies: AppButton, AppTextField, AppCheckbox. Elke functie ontvangt aanpassingsparameters (kleur, grootte, status) en bevat geen bedrijfslogica. Atomen worden gedefinieerd in de shared-laag en geëxporteerd als UI-kit.

Moleculen — @Composable-functies die meerdere atomen combineren: LabeledTextField (label + invoerveld + foutmelding), ProductCard (afbeelding + naam + prijs). Moleculen kunnen basistoestand bevatten (veldvalidatie), maar hebben geen toegang tot API of ViewModel. Ze worden hergebruikt in verschillende organismen.

Organismen — @Composable-functies op functieniveau: LoginForm (LabeledTextField voor e-mail + LabeledTextField voor wachtwoord + AppButton verzenden + herstelllink). Organismen werken met ViewModel via Intent-functies en kunnen bedrijfslogica bevatten. In SwiftUI wordt een vergelijkbare hiërarchie opgebouwd via @ViewBuilder en aangepaste View-structuren.

In SwiftUI is een atoom — een aangepaste View-structuur AppButton, een molecuul — een invoerveld met een label op HStack, een organisme — een inlogformulier. Zo'n structuur maakt herbruik van componenten op alle schermen mogelijk — een wijziging van een atoom (knopkleur) wordt automatisch toegepast op alle schermen. De combinatie van Atomic Design met een designsysteem garandeert interfaceconsistentie zonder handmatige controle van elk scherm.