Fra Figma til komponentplatform

Pipelinen: Figma → design tokens → komponenter → applikation

De fleste forklaringer af denne pipeline beskriver Figma som 'kilden til sandhed' og tokens som en praktisk måde at synkronisere farver på. Det undervurderer hvad der faktisk sker.

Pipelinen har fire konkrete trin, hvert distribueret som sit eget artefakt. Figma er der hvor din UX-designer arbejder — komponenter i Figma bruger variabler (tokens) direkte, så enhver ændring af en token opdaterer Figma-komponenten med det samme. Disse tokens eksporteres derefter og publiceres som en selvstændig pakke. Hver komponent er sin egen separate pakke, der kun importerer de tokens den har brug for. Applikationer erklærer derefter afhængigheder af de komponentpakker de har brug for og sammensætter deres UI fra dem — Lego-klodser samlet til et specifikt use case.

Dette fungerer uanset hvilken UI-teknologi dine teams bruger. Token-pakken og komponentpakkerne forbruges på samme måde, hvad enten du bygger i Angular, React, Blazor eller et andet framework. Pipelinen er ligeglad.

Resultatet er at en ændring i Figma flyder igennem token-pakken, ind i alle komponentpakker der refererer til den token, og ud til alle applikationer — uden at røre en eneste linje komponentlogik.

Hvad design tokens faktisk er

Design tokens er CSS custom properties. Ikke abstraktioner over CSS — faktiske CSS-variabler som dine komponenter refererer direkte til. En token som --button-padding-x eller --card-border-radius er lige så konkret som enhver anden CSS-egenskab. Den har en værdi, og den værdi bestemmer hvad der renderes.

De fungerer på to niveauer. Generiske tokens udtrykker globale designbeslutninger: --color-primary, --spacing-4, --font-size-base. Disse er byggeklodserne. Specifikke tokens udtrykker komponentniveaubeslutninger: --button-bg bruger --color-primary, --button-padding-x bruger --spacing-4. De specifikke tokens refererer til de generiske, så en ændring på generisk niveau propagerer automatisk til alle komponenter der afhænger af det.

Det er dette der gør Figma-forbindelsen reel. Figmas variabler mappes direkte til disse tokens. Når en designer sætter en komponents padding i Figma, er det ikke en designannotation der skal fortolkes af en udvikler — det er tokenværdien. Når de ændrer den, ændres den eksporterede token, CSS-variablen ændres, og komponenten ændres. Designeren og komponenten redigerer den samme ting.

• Farvetokens: global palette, semantiske roller (succes, advarsel, fejl), overflade- og teksthierarki — refereret af alle komponenter med baggrund eller tekstfarve
• Afstandstokens: en konsistent skala der bruges til padding, margin, gap og positionelle værdier i alle komponenter
• Størrelses-tokens: bredder, højder, ikonstørrelser, kantstørrelser — så komponenter forbliver proportionelt konsistente på tværs af systemet
• Typografitokens: skriftfamilie, størrelseskala, linjehøjde, vægt, bogstavafstand — brugt direkte i komponenttekststile
• Form- og dybde-tokens: kantradiusser, skyggeniveauer, z-indeks-skala — der styrer det rumlige udtryk i hele UI
• Bevægelsestokens: varighed og lettelsesværdier konsumeret af alle komponenter der animerer

Du behøver ikke bygge komponenter fra bunden

Dette er erkendelsen der ændrer økonmien i en komponentplatform fundamentalt. De fleste organisationer antager, at de skal håndbygge hver komponent — hver datovælger, hvert multi-select, hvert datatabel. Det er enormt dyrt og producerer komponenter der uundgåeligt er mindre tilgængelige, mindre testede og mindre robuste end hvad etablerede open source-biblioteker allerede leverer.

En langt mere praktisk tilgang er at wrappe et veldokumenteret tredjepartskomponentbibliotek og eksponere det via din egen API. Hvis dine teams bruger Angular, er PrimeNG et fremragende fundament. React-teams kan wrappe Radix UI eller Headless UI. Blazor-teams har deres eget økosystem. Princippet er det samme: du adopterer den interaktionslogik, tilgængelighed og edge case-håndtering som det overordnede bibliotek allerede har løst — og du ejer designlaget oven på.

I praksis ser det sådan ud: du opretter en wrapperkomponent (en web-komponent eller framework-native komponent) der eksponerer kun de props dine teams har brug for, skjuler implementeringsdetaljer og delegerer rendering til det overordnede bibliotek. Du anvender dine design tokens via bibliotekets temaningssystem. Resultatet er en komponent der ser præcis ud som dit UX-design foreskriver og opfører sig præcis som det overordnede bibliotek garanterer — med minimal egenskabt logik.

Temaing, ikke overskrivning

Moderne komponentbiblioteker som PrimeNG er bygget til at drives af tokens. Deres temaningssystem eksponerer et struktureret sæt CSS custom properties — én for hvert visuelt aspekt af hver komponent. Du overskriv ikke deres stilarter. Du leverer tokenværdierne og de renderer derefter.

Dette er integrationspunktet hvor Figma bliver komponenten. Dine eksporterede Figma-tokens føder direkte ind i bibliotekets tokenlag. Biblioteket bruger disse værdier til at rendere. Når en designer ændrer en komponents udseende i Figma, opdateres tokeneksporten, biblioteket tager den til sig, og den renderede komponent afspejler ændringen — automatisk, uden at komponentkode røres.

Grænsen er tydelig: biblioteket ejer interaktionsadfærd og tilgængelighed, dine tokens ejer alle visuelle beslutninger. Den fordeling er det der holder platformen vedligeholdbar efterhånden som både designet og biblioteket udvikler sig.

Wrapping som web-komponent eller framework-komponent

Din wrappingstrategi afhænger af, hvor mange frameworks din organisation kører. Hvis alle teams bruger det samme framework — f.eks. Angular — er en native Angular-komponentwrapper det simpleste og mest ergonomiske valg. Den deltager naturligt i Angulars change detection, dependency injection og reactive forms.

Hvis teams bruger forskellige frameworks, lader wrapping som web-komponent (ved hjælp af Angulars @angular/elements eller et dedikeret værktøj som Lit) dig publicere én gang og konsumere overalt. Komponenten fungerer i Angular, React, Blazor eller plain HTML. Afvejningen er lidt mere kompleksitet ved grænsen — men for organisationer med genuint polyglotte frontends er det det rigtige valg.

Uanset hvad er wrapperen tynd. Den ejer den offentlige API dine teams bruger — props, events og slots — og delegerer alt andet til den overordnede komponent. Jo mindre logik der er inde i wrapperen, jo nemmere er den at vedligeholde.

Distribution som pakker

Tokeneksporten fra Figma publiceres som en dedikeret pakke — et enkelt distributionspunkt for alle CSS custom properties i systemet. Den indeholder intet andet: ingen komponenter, ingen utilities, kun tokens.

Hver komponent er derefter sin egen separate pakke. En knap-komponent importerer kun de tokens den har brug for — dens baggrundsfarve, afstandsskala, kantradius, skriftstørrelse. En datatabel importerer sit eget undersæt. Komponenter er uafhængige, versioneret individuelt, og teams installerer kun hvad deres applikation faktisk bruger.

En applikation der har brug for en søgeboks, en datatabel og en datovælger erklærer simpelthen disse tre komponenter som afhængigheder. Den får præcis disse komponenter, stilet konsistent via den fælles token-pakke. At bygge en ny side bliver et spørgsmål om at vælge de rigtige komponenter og sammensætte dem — klodser med veldefinerede former, der passer sammen fordi de alle deler det samme underliggende tokensystem.

Storybook fungerer som interaktivt katalog ved siden af. Hver komponent har stories der viser dens varianter, tilstande og konfiguration. Det er stedet hvor udviklere opdager hvad der eksisterer inden de bygger, og hvor designere verificerer at tokenmappingen er korrekt inden en komponent publiceres.

Hvad vedligeholdelse faktisk indebærer

Her betaler investeringen sig. Fordi dine komponenter wrapper et overordnet bibliotek, arves det meste vedligeholdelse automatisk. Fejlrettelser, tilgængelighedsforbedringer og browserkompatibilitetsrettelser leveres med det overordnede bibliotek og flyder ind i din platform ved opgradering.

Dit teams vedligeholdelsesarbejde koncentrerer sig om to ting: at holde token-pipelinen præcis efterhånden som designs udvikler sig, og at håndtere wrapper-API'en efterhånden som teams beder om nye muligheder. Ingen af dem er trivielle, men begge er langt mindre i omfang end at vedligeholde håndbyggede komponenter fra bunden.

Når et rebrand sker — ny primærfarve, opdateret typografiskala, justeret kantradius — er arbejdet: opdater tokens i Figma, re-eksportér, opdater temaningskonfigurationen, publicer en ny version. Alle forbrugende applikationer tager ændringen til sig ved deres næste afhængighedsopdatering. Ingen komponent-omskrivning nødvendig.

Platformen har brug for en tydelig ejer

En komponentplatform er infrastruktur. Som al infrastruktur har den brug for én der er ansvarlig for den — ikke som et sideprojekt, men som et primært ansvar.

Det betyder et lille, dedikeret team (eller som minimum én fokuseret ingeniør parret med den UX-ansvarlige) der ejer token-pipelinen, gennemgår komponentforslag, håndterer versionering, vedligeholder Storybook og kommunikerer breaking changes til forbrugende teams.

Uden tydeligt ejerskab drifter platformen. Tokens falder ud af sync med Figma. Komponenter akkumulerer udokumenterede varianter. Teams begynder at arbejde uden om platformen frem for igennem den. Investeringen eroderer.

Udbyttet: udvikling som samling

Når platformen er moden, ændrer oplevelsen af at bygge en ny feature sig fundamentalt. Et produktteam modtager et Figma-design bygget med det eksisterende tokensæt og komponenter. De åbner Storybook, finder de komponenter de har brug for, og samler siden. Det visuelle output matcher designet fordi begge er drevet af de samme tokens.

AI-assisteret udvikling drager direkte fordel af dette: når dit komponentbibliotek er tilgængeligt som kontekst, kan en kodningsassistent sammensætte sider med dine faktiske komponenter frem for at generere vilkårlig markup. Det første forslag bruger allerede de rigtige komponenter, de rigtige props og den rigtige navngivning.

Resultatet er hurtigere levering, færre designinkonsistenser, lavere reviewomkostninger og et produkt der føles sammenhængende — selv når det er bygget af mange teams der arbejder uafhængigt.