Hvad er atomic design?
Atomic Design lyder næsten som noget, der hører til i et laboratorie, men det er en grundsten i design systems. I praksis er det bare en enkel måde at få styr på designbeslutninger, så jeres UI kan vokse uden at blive ujævnt, dyrt at vedligeholde eller fyldt med “næsten ens” komponenter.
Metoden, som Brad Frost beskrev, handler om atomic design, hvor grænseflader bygges som et hierarki af dele: små byggesten først, større mønstre bagefter. Det giver et fælles sprog på tværs af design, udvikling og produkt, og det gør ændringer langt mindre dramatiske, når produktet skifter retning, får nye features eller rammer nye markeder.
Hvorfor Atomic Design fungerer, når tempoet stiger
Når et team skalerer, sker der typisk to ting samtidig: flere personer ændrer i UI’et, og flere skærme bliver produceret hurtigere. Hvis grundlaget ikke er tydeligt, opstår variationer, som føles små hver for sig, men store samlet. Knapper får forskellige padding. Formularer opfører sig forskelligt. Fejltekster bruger nye farver “bare her”.
Atomic Design giver jer en struktur, hvor I kan genbruge med ro i maven, fordi komponenter bliver skabt med klare grænser og ansvar. Det hjælper også, hvis I arbejder i no-code eller hybrid setups, hvor tempoet ofte er højt, og hvor et system er forskellen på “hurtigt” og “rod”.
Et robust designsystem handler ikke om at gøre alt ens. Det handler om at gøre det ens, der bør være ens, og bevidst variere det, der skal variere.
De fem niveauer, oversat til hverdagsarbejde
Atomic Design beskriver fem niveauer. Mange teams kender ordene, men får mest værdi, når de knytter dem til konkrete artefakter: tokens, komponenter, layout, skabeloner og rigtige sider.
Her er en praktisk oversættelse, som fungerer godt i både Figma, kode og no-code.
Niveau | Hvad det er i praksis | Typiske eksempler | God tommelfingerregel |
|---|---|---|---|
Atomer | Grundelementer og regler | Farver, typografi, spacing, ikoner, knap-states | Kan ikke give mening alene, men bruges overalt |
Molekyler | Små funktionsmønstre | Input + label + hjælptekst, “search field”, badge med ikon | Gør én ting og kan flyttes rundt |
Organismer | Tydelige UI-sektioner | Header, pricing table, feature grid, checkout summary | Kan stå som blok på en side |
Templates | Side-skelet uden “rigtigt” indhold | Layout med placeholders, tomme moduler | Tester struktur og flow, ikke copy |
Pages | Konkrete sider med data og indhold | Forside, produktside, onboarding step | Bruges til QA, tests og beslutninger |
Når I bruger hierarkiet konsekvent, bliver det lettere at se, hvor en ændring hører hjemme. En ny farvevariant er sjældent en “ny knap”. Det er typisk et atom eller en token, som knappen allerede burde bygge på.
Start rigtigt: fra interface-inventory til første biblioteksrelease
Den mest stabile måde at komme i gang på er at starte med det, I allerede har. Ikke med en drøm om “perfekt system”, men med en kort og ærlig optælling af UI’et.
Tag skærmbilleder af jeres vigtigste flows. Læg dem op side om side. Marker gentagelser og variationer. Det er jeres interface-inventory, og det gør diskussionen konkret: Hvad er egentlig den samme komponent, og hvad er reelt forskellige behov?
Når I har overblikket, så vælg en smal start. Ét flow. Ét produktområde. Én platform. Lav de nødvendige tokens og de mest brugte komponenter, og dokumentér dem, mens I bygger dem.
En enkel prioritering, som ofte giver hurtig effekt, er:
Buttons og links
Formularfelter
Typografi og spacing
Cards og lister
Det er ikke glamorøst. Det er til gengæld der, inkonsistens næsten altid starter.
Tokens først: farver, typografi og spacing som “kontrakt”
Hvis jeres design decisions ligger som “manuel styling” inde i 40 komponenter, får I et system, der føles hurtigt i starten, men langsomt senere. Tokens løser det ved at gøre styling til en kontrakt: komponenter refererer til tokens, og tokens kan ændres centralt.
I Figma betyder det typisk styles og variabler. I kode kan det være design tokens via fx CSS-variables eller et token-setup, der kan eksporteres. I no-code, Framer, handler det om at have et klart, begrænset sæt af styles, der genbruges konsekvent.
Efter en kort token-runde bør I kunne svare på:
Hvilke tekststørrelser findes, og hvornår bruges de?
Hvor mange spacing-trin har vi, og hvad hedder de?
Hvilke farver er “brand”, og hvilke er “funktion” (fx success, warning, error)?
Jo færre “special cases” I tillader i tokens, jo mere frihed får I senere, når der skal bygges hurtigt.
Komponentdesign i Figma: varianter, states og klare grænser
Atomic Design handler ikke om, at alt skal hedde atom, molekyle og organisme i filstrukturen. Det handler om, at komponenterne er bygget, så de kan genbruges uden at blive bøjet ud af form.
Et godt tegn på robusthed er, at en komponent har:
tydelige varianter (størrelse, type, ikon ja/nej)
tydelige states (default, hover, disabled, loading)
tydelige constraints og Auto Layout, så den opfører sig forudsigeligt
Her giver navngivning og struktur jer mere end fancy dokumentation. Hvis en ny designer eller udvikler ikke kan finde den rigtige komponent på 30 sekunder, ender de ofte med at lave en ny.
En kort navngivningsmodel, som fungerer i praksis, er at holde sig til et mønster som og kun tilføje ekstra niveauer, når I kan forklare hvorfor.
Efter et par sprints kan I med fordel lave en lille “oprulning”, hvor I gennemgår biblioteket og fjerner dubletter. Det er meget billigere at gøre løbende end én gang om året.
Fra design til implementering: Storybook, Pattern Lab og no-code (Framer)
Atomic Design bliver ekstra effektivt, når designbiblioteket og implementeringen følges ad. Mange teams lander i en af tre opsætninger:
Design i Figma, implementering i kode, dokumentation i Storybook
Design i Figma, implementering i et pattern library, dokumentation i Pattern Lab
Design i Figma, implementering i no-code, hvor komponenter bygges som “levende” blokke
Hos Studio Echo arbejder vi typisk med UX/UI, designsystemer og Framer websites, og det er netop et miljø, hvor et atomic mindset giver en klar fordel: Når komponenter lever som genbrugelige moduler, kan et site udbygges hurtigt uden at miste visuel konsistens.
Det vigtigste er ikke værktøjet. Det vigtigste er, at der findes én tydelig “kilde til sandhed” for komponenternes adfærd og regler i design systems, og at ændringer bliver fanget og kommunikeret, når de sker.
En praktisk måde at holde design og build tæt på hinanden er at kræve, at nye komponenter altid får:
Ejerskab: hvem godkender ændringer?
Definition: hvilke varianter og states er en del af “done”?
Eksempler: hvor bruges den i templates og pages?
Templates og pages: hvor kvaliteten bliver synlig
Mange designsystemer stopper ved komponentbiblioteket. Så ser alt fint ud i et grid af knapper og cards, men begynder at knirke på rigtige sider med rigtig tekst, rigtige billeder og rigtige edge cases.
Templates og pages er derfor ikke “nice to have”. De er stedet, hvor I ser:
om spacing-skalaen holder i lange tekster
om komponenter faktisk kan kombineres uden ekstra hacks
om responsiv opførsel er løst, eller bare antaget
Pages er også der, hvor samarbejdet med marketing, content og SEO bliver lettere. Når systemet kan bære rigtige sider med rigtigt indhold, kan flere i organisationen arbejde uden at skabe visuel gæld.
Vedligeholdelse uden drama: gør systemet til en del af driften
Et designsystem dør sjældent af dårligt design. Det dør af, at det bliver et sideprojekt, som ingen har tid til at passe.
Hvis I vil undgå det, så behandl det som produktarbejde: små releases, tydelig changelog, og en fast rytme. Det kan være en halv time om ugen, hvor I triager requests og beslutter, om noget er en ny variant, en ny komponent eller bare forkert brug.
Her er tre signaler, der viser, at systemet har brug for en oprydning:
Mange “one-off” komponenter, der kun bruges én gang
Komponenter der bliver kopieret ud af biblioteket og ændret lokalt
Diskussioner der starter med “kan vi ikke bare…”
Typiske faldgruber, og hvordan I kommer udenom dem
Atomic Design kan misforstås som en rigid model, hvor alt skal presses ned i en bestemt kategori. Det er sjældent en god idé. Nogle teams ender også med at over-optimere: alt bliver så generisk, at ingen tør bruge det.
To simple principper hjælper:
Kategorierne skal hjælpe jer med at træffe beslutninger, ikke skabe ekstra arbejde
Systemet skal kunne rumme både standard og undtagelser, men undtagelser skal være synlige
Det er helt normalt, at en “knap” hos ét team føles som et atom, og hos et andet team føles som et molekyle, fordi den har flere indbyggede regler, hvilket understreger principperne bag atomic design. Det afgørende er, at I er konsekvente, og at komponenten har et klart ansvar.
En kort tjekliste til næste sprint
Hvis I vil gøre Atomic Design til noget, der skaber resultater hurtigt, så vælg ét område og få det i mål, før I udvider.
Vælg scope: ét flow, én platform, én release
Definér tokens: farve, type, spacing, radius, shadow
Byg kernekomponenter: knapper, inputs, cards, feedback states
Test på pages: rigtigt indhold, lange tekster, tomme states
Dokumentér minimum: navn, formål, varianter, do’s og don’ts
Når det sidder, bliver resten mere mekanisk. Ikke kedeligt, bare stabilt. Og det er netop pointen med Atomic Design i praksis.
