Atomic Design — grunder, atomer, molekyler och organismer i UI

Vad är Atomic Design?

Atomic Design — metodologi för att skapa hierarkiska gränssnittssystem, där varje UI-element tillhör en av fem nivåer: atomer (grundläggande element), molekyler (kombinationer av atomer), organismer (komplexa block), mallar (sidskelett) och sidor (konkreta skärmar med data). Analogin är lånad från kemi: atomer kombineras till molekyler, molekyler till organismer, organismer till mallar, mallar fylls med innehåll och blir sidor.

Metodologin föreslogs av webbdesignern Brad Frost 2013 som ett svar på problemet med "sidbaserat tänkande" — när varje ny skärm designas från grunden, utan hänsyn till befintliga komponenter. I boken "Atomic Design" (2016) beskriver Frost implementeringen av metodologin i projekt hos stora företag: IBM, GE, Starbucks. Enligt Nielsen Norman Group (2022) minskar Atomic Design designtiden för nya skärmar med 30–50% tack vare återanvändning av färdiga komponenter.

Atomic Design — är inte så mycket en teknik som en filosofi för UI-organisation. Den är inte bunden till ett specifikt ramverk och är tillämplig både på webben (React, Vue) och inom mobilutveckling (Jetpack Compose, SwiftUI). På IT Sectr använder vi Atomic Design för att bygga designsystem åt kunder: vi identifierar atomära komponenter i designfasen och överför dem till kodkomponenter i Compose/SwiftUI.

Fem nivåer: atomer, molekyler, organismer, mallar, sidor

Varje nivå i Atomic Design löser sin egen uppgift och har ett strikt ansvarsområde. Atomer — de minsta byggstenarna i gränssnittet, som inte kan delas ytterligare utan att förlora mening: knapp, textfält, ikon, etikett, kryssruta. Atomer innehåller ingen affärslogik och är inte beroende av kontext. De definierar grundläggande visuella egenskaper: färg, storlek, marginaler, typografi.

Molekyler — kombinationer av två eller fler atomer som bildar enkla funktionella enheter. Ett inmatningsfält med etikett och felmeddelande — molekyl. En produktkort med bild, namn och pris — molekyl. Molekyler kan innehålla grundläggande logik (visa/dölj fel), men innehåller inga affärsprocesser. Molekyler är den första nivån där komponenter blir återanvändbara mellan olika skärmar.

Organismer — komplexa gränssnittsblock, bestående av molekyler och atomer, som implementerar en specifik funktion i applikationen. Inloggningsformuläret (e-postfält, lösenordsfält, skicka-knapp, länken "glömt lösenord") — organism. Rubriken med logotyp, sökning och navigering — organism. Organismer kan innehålla affärslogik och anropa API, men endast inom ramen för sin funktion.

Mallar — sidskelett som bestämmer placeringen av organismer på skärmen utan konkret innehåll. Mallen definierar rutnätet, kolumner, innehållszoner — wireframe på kodnivå. Mallar innehåller inga data, endast platshållare. De gör det möjligt att utvärdera sidstrukturen innan den fylls med innehåll.

Sidor — konkreta skärmar i applikationen, där mallen är fylld med verkliga data. På denna nivå kontrolleras hur komponenterna ser ut med verkligt innehåll (långa strängar, saknade data, fel). Sidor är den enda nivån som slutanvändaren ser. Ändringar på sidnivå bör inte påverka atomer, molekyler och organismer — om en komponent behöver ändras, görs ändringen på dess nivå och sidan tar automatiskt över den.

Fördelar och begränsningar med Atomic Design

Fördelar med Atomic Design framträder vid skalning av gränssnitt. Ett enhetligt komponentbibliotek garanterar visuell konsekvens: knappen ser likadan ut på alla skärmar eftersom det är samma atom. Enligt Brad Frost (2016) minskar företag som implementerat Atomic Design utvecklingstiden för nya skärmar med 30–50% tack vare återanvändning av färdiga molekyler och organismer.

Begränsningar — Atomic Design beskriver inte hur man hanterar applikationens tillstånd. Metodologin svarar bara på frågan "hur man organiserar UI-komponenter", men berör inte affärslogik, routing eller datahantering. En andra begränsning — svårigheten att bestämma gränser: var slutar molekylen och var börjar organismen? I praktiken är gränserna otydliga och olika team kan klassificera samma komponent olika. Det rekommenderas att fastställa regler i designtoken och komponentkatalog (Storybook, Jetpack Compose Preview).

En tredje begränsning — överdriven abstraktion för små projekt. Om applikationen består av 5 skärmar är det onödigt arbete att skapa en hierarki av atomer och molekyler. Atomic Design blir fördelaktigt när antalet skärmar överstiger 20 och komponenter återanvänds på olika sidor.

Atomic Design vs Feature-Sliced Design

Atomic Design och Feature-Sliced Design (FSD) löser olika uppgifter och kan användas tillsammans. Atomic Design är en metodologi för att organisera UI-komponenter, FSD — en metodologi för att organisera affärslager och hela applikationen. Atomic Design svarar på frågan "hur man delar upp UI i återanvändbara delar", FSD — "hur man organiserar kod kring affärsfunktioner". De konkurrerar inte: man kan ha en FSD-struktur med lager features och entities, och inom varje lager använda Atomic Design för att organisera UI-komponenter.

Typisk kombination: FSD definierar applikationens modulära struktur (lager, skivor), Atomic Design — den interna strukturen av UI-komponenter inom varje skiva. Till exempel innehåller skivan feature.auth molekyler (LoginForm, PasswordInput) och organismer (AuthPage), sammansatta enligt Atomic Design-reglerna. Det delade lagret innehåller atomer (Button, Input, Label) som är återanvändbara i alla funktioner.

Atomic Design i mobilappar: Compose och SwiftUI

Jetpack Compose och SwiftUI stöder naturligt Atomic Design-hierarkin genom komponentkomposition. Atomer i Compose — grundläggande @Composable-funktioner: AppButton, AppTextField, AppCheckbox. Varje funktion tar emot anpassningsparametrar (färg, storlek, status) och innehåller ingen affärslogik. Atomer definieras i det delade lagret och exporteras som UI-kit.

Molekyler — @Composable-funktioner som kombinerar flera atomer: LabeledTextField (etikett + inmatningsfält + felmeddelande), ProductCard (bild + namn + pris). Molekyler kan innehålla grundläggande tillstånd (fältets giltighet), men har inte tillgång till API eller ViewModel. De återanvänds i olika organismer.

Organismer — @Composable-funktioner på funktionsnivå: LoginForm (LabeledTextField för e-post + LabeledTextField för lösenord + AppButton skicka + återställningslänk). Organismer arbetar med ViewModel via Intent-funktioner och kan innehålla affärslogik. I SwiftUI byggs en liknande hierarki via @ViewBuilder och anpassade View-strukturer.

I SwiftUI är en atom — en anpassad View-struktur AppButton, en molekyl — ett inmatningsfält med etikett på HStack, en organism — ett inloggningsformulär. En sådan struktur möjliggör återanvändning av komponenter på alla skärmar — en ändring av en atom (knappfärg) tillämpas automatiskt på alla skärmar. Kombinationen av Atomic Design med ett designsystem garanterar gränssnittskonsistens utan manuell kontroll av varje skärm.