Designsystem fra Figma til ferdig kode

Et designsystem samler komponenter, design tokens og regler for bruk, så en virksomhet kan bygge flere produkter raskere, oppfylle kravene til universell utforming og holde den tekniske gjelden nede i mange år.

Mange designsystemer stopper i Figma. Biblioteket ser bra ut, men koden i produksjon følger sine egne regler, og avstanden mellom de to vokser for hver måned. Hos oss er designsystemet et teknisk produkt. De samme seniorutviklerne som lager det visuelle språket, bygger også komponentene, pipelinen som holder design og kode i takt, og styringsmodellen som gjør at systemet fortsatt blir brukt om fem år.

Hva er et designsystem?

Et designsystem er en samling gjenbrukbare komponenter, retningslinjer og verktøy som gjør det mulig å bygge store digitale produkter med samme utseende og høyt tempo.

Det skiller seg fra en stilguide, som er statisk dokumentasjon, og fra et komponentbibliotek, som bare er kode, ved at det binder delene sammen med faste rutiner for styring og vedlikehold. Et komplett designsystem består som regel av:

• Design tokens: de minste verdiene, som farger, avstander, typografi, skygger og animasjoner.
• Komponenter: ferdig kodede byggeklosser som knapper, skjemafelt, dialoger og navigasjon.
• Mønstre: dokumenterte løsninger på vanlige oppgaver som innlogging, feilhåndtering og tabeller.
• Styring: regler for hvordan systemet utvikles, vedlikeholdes og distribueres.

I Norge har vi gode eksempler i Aksel fra NAV og designsystemet til Skatteetaten. De viser hvordan offentlig sektor kan forvalte digitale fellesgoder.

Hva får du igjen for et designsystem?

Et godt designsystem handler mer om fart, kvalitet og risiko enn om utseende:

• Samme opplevelse overalt: brukerne møter den samme merkevaren uansett produkt, plattform eller team.
• Raskere utvikling: gjenbrukbare komponenter korter ned veien fra design til produksjon.
• Enklere vedlikehold: en endring gjøres ett sted og når alle produktene, så oppdateringer blir forutsigbare.
• Bedre samarbeid: designere og utviklere får et felles språk og færre misforståelser.
• Kvalitet når teamet vokser: systemet holder kvaliteten oppe uten at noen blir en flaskehals.
• Tilgjengelighet som arves: testingen mot WCAG skjer i komponentene, og produktteamene får den med på kjøpet.

Når trenger du et designsystem, og når ikke?

Et designsystem lønner seg når flere team eller flere produkter skal se like ut og oppføre seg likt. Typiske tegn er at den samme knappen finnes i fem varianter, at designerne tegner skjermbilder som utviklerne bygger på hver sin måte, eller at hver ny funksjon starter med å lage de samme skjemafeltene på nytt.

Har du ett produkt og et lite team, er et fullt designsystem med egen styringsmodell ofte for mye. Da holder det med et sett tokens, de viktigste komponentene og en kort beskrivelse av hvordan de brukes. Det kan vokse til et designsystem senere, når behovet er der. Å bygge for stort for tidlig er en vanlig feil, og vi sier fra hvis det er der du står.

Designsystemet fra Digdir eller et eget?

Offentlige virksomheter kan bruke Designsystemet fra Digdir, et felles og åpent designsystem med komponenter og tokens for Figma, CSS og React. Tanken er at du bygger på det og legger din egen visuelle profil over.

For mange offentlige løsninger er det et godt utgangspunkt, og da hjelper vi deg med å ta det i bruk, lage temaet ditt og bygge de komponentene som mangler. Private virksomheter med en sterk merkevare eller produkter med helt egne behov får som regel mer ut av et eget system. Spørsmålet vi stiller, er hvor mye av grensesnittet som er spesielt for virksomheten din, og hvor mye som er vanlige skjemaer, tabeller og dialoger.

Design tokens som sannhetskilde

Grunnmuren i et designsystem er design tokens. Det er en måte å skille designbeslutningene fra de enkelte plattformene på.

I stedet for å skrive en fargekode som #0056b3 rett inn i en iOS-app eller en React-komponent, lagrer vi verdien i et plattformuavhengig format (JSON), slik W3C Design Tokens Community Group har definert det. Tokenene får navn etter hva de brukes til, som primærfarge eller feilfarge, så det er lett å endre en verdi uten å lete etter hvor den er brukt. Slik kan du også ha mørk modus eller flere merkevarer i samme kodebase: du bytter verdiene bak navnene, mens komponentene er de samme.

Automatisk fra Figma til kode

Vi setter opp en pipeline som fjerner det manuelle arbeidet mellom design og kode:

1. Definisjon: designerne endrer en farge eller en font i Figma med Tokens Studio.
2. Versjonering: endringen sendes til kodelageret som en JSON-fil.
3. Oversettelse: en CI/CD-pipeline, ofte med Style Dictionary, gjør JSON-filen om til formatene utviklerne trenger: CSS custom properties for web, XML for Android og Swift for iOS.
4. Distribusjon: de nye verdiene publiseres automatisk som en ny versjon av en NPM-pakke.

Dermed holder design og kode seg i takt. Endres merkevarefargen, slipper du å lete gjennom tusenvis av kodelinjer. Du endrer tokenet, og alle applikasjonene får endringen neste gang de oppdaterer pakken.

Headless-komponenter

For å få både fleksibilitet og tilgjengelighet bygger vi ofte på headless-komponenter. I stedet for å skrive logikken for tastaturnavigasjon og skjermlesere fra bunnen av, bruker vi biblioteker som Radix UI eller React Aria. De leverer oppførselen uten utseendet.

• Riktig oppførsel fra start: piltastnavigasjon i nedtrekksmenyer, riktig fokushåndtering og støtte for skjermlesere er på plass fra første versjon.
• Full frihet i stilen: vi legger på egen CSS med Tailwind eller CSS Modules, så komponentene følger merkevaren helt, og vi slipper å overstyre ferdige stiler fra et rammeverk som Bootstrap.

Komponentene bygger vi i React og TypeScript, med sammensetning i stedet for lange lister med innstillinger. Da blir de enklere å bruke riktig og vanskeligere å bruke feil.

Universell utforming som arves

EUs tilgjengelighetsdirektiv (EAA) skjerper kravene til universell utforming, også for private virksomheter. Designsystemet er det viktigste verktøyet du har for å oppfylle dem.

Vi jobber etter prinsippet om arvet samsvar. Det er lite effektivt at hvert produktteam skal sjekke om kontrasten på en knapp er god nok, eller om et skjemafelt har riktig aria-label.

• Testet ett sted: vi tester komponentene mot WCAG 2.2 AA i designsystemet, med skjermlesere som NVDA og VoiceOver, med tastatur og med automatiske verktøy.
• Kvalitet som sprer seg: når et team henter <Button /> fra systemet, får de all denne kvaliteten med. Endres reglene, som da WCAG 2.2 kom, oppdaterer vi komponenten ett sted, og alle applikasjonene som bruker den, blir oppdatert.

Det reduserer risikoen for brudd på regelverket og lar utviklerne bruke tiden på forretningslogikk i stedet for detaljene i WCAG. Komponentene alene gjør likevel ikke et produkt tilgjengelig. Overskrifter, tekster og rekkefølgen på innholdet må også være riktige, og det sjekker vi når systemet tas i bruk. Les mer om universell utforming og hvordan vi hjelper med tilgjengelighetserklæringer.

Styring og dokumentasjon

Å bygge versjon 1.0 av et designsystem er den enkle delen. Det vanskelige er å forvalte det år etter år. Uten en tydelig styringsmodell dør systemet ut eller sprekker opp i varianter ingen kjenner igjen. Vi hjelper deg med å velge modell etter teamstruktur og modenhet:

• Sentralisert modell: et eget team eier systemet og bygger, tester og distribuerer alt. Passer der kontroll og konsistens er viktigst, som i bank og finans. Risikoen er at teamet blir en flaskehals for produktteamene.
• Føderert modell: representanter fra produktteamene møtes jevnlig, tar beslutninger og bidrar med kode. Passer der den tekniske kompetansen er spredt i teamene. Risikoen er sprik og trege beslutninger.
• Hybrid modell: et lite kjerneteam har ansvar for infrastrukturen og dokumentasjonen, mens produktteamene bidrar med komponenter gjennom en fast bidragsprosess.

Den hybride modellen anbefaler vi for de fleste norske virksomheter. Den gir eierskap i hele organisasjonen, mens kjerneteamet passer på kvaliteten.

Et designsystem er dessuten lite verdt hvis ingen vet hvordan det skal brukes. Dokumentasjonen er den delen av systemet de fleste i organisasjonen møter. Vi setter opp levende dokumentasjon med Storybook for utviklerne og Zeroheight for designere og produktledere. Utviklerne kan prøve komponentene i nettleseren, endre props og kopiere koden. For hver komponent dokumenterer vi hva den er, når den skal brukes og hvordan, med eksempler på riktig og feil bruk.

Designet og bygget av de samme folkene

Et vanlig problem med designsystemer er overleveringen. Noen lager et bibliotek i Figma, andre skal bygge det i kode, og underveis blir det gjort små valg som ingen dokumenterer. Etter et halvt år finnes det to systemer som nesten ligner hverandre.

Hos oss tegner og bygger de samme folkene. Alle har over ti års erfaring, og du får ingen juniorer på prosjektet. Den som bestemmer hvordan en dialog skal oppføre seg, er også den som skriver koden for den, og vet hva som er dyrt å bygge og vanskelig å vedlikeholde. Kvaliteten sikrer vi med faste rutiner:

• Storybook: hver komponent har sine varianter og tilstander i Storybook, der de kan testes og sammenlignes.
• Tilgjengelighet: automatiske tester og manuell testing med tastatur og skjermleser før en komponent regnes som stabil.
• Versjonering: endringer får versjonsnummer og endringslogg med Changesets, så produktteamene vet hva som er endret og kan oppgradere i sitt eget tempo.
• Kodegjennomgang: en annen seniorutvikler leser koden før den blir publisert.

Hva koster det, og hva sparer du?

Timeprisen starter på 1 500 kr, og arbeid med et tydelig omfang, som en revisjon eller et sett med kjernekomponenter, får fastpris. Prisen avhenger mest av tre ting: hvor mange plattformer systemet skal dekke, hvor mange komponenter som trengs, og hvor mye som må ryddes i det du har i dag. Etter revisjonen får du et estimat, så du vet hva du får før vi begynner.

Hva du sparer, er lett å regne på. Har du 20 utviklere som hver bruker to timer i uken på å lage en knapp, rette en modal eller justere farger på nytt, går det med 40 timer i uken. Det tilsvarer omtrent ett årsverk.

Med et designsystem forsvinner mye av dette arbeidet, og teamene kan bruke tiden på funksjoner kundene merker.

Slik jobber vi

Mange har allerede et halvferdig designsystem: et Figma-bibliotek som ikke stemmer med koden, eller komponenter som bare ett av teamene bruker. Da er det sjelden riktig å begynne på nytt. Ofte er tokens og styring det som mangler, mens mange av komponentene kan brukes videre med litt opprydding. Vi følger den samme metoden enten vi bygger nytt eller rydder i det du har:

1. Teknisk og visuell revisjon: vi kartlegger dagens situasjon. Hvor mange blåtoner har du? Hvor mange ulike knappestiler finnes i produksjon? Det blir grunnlaget for oppryddingen, og du får en liste over hva som kan beholdes, hva som bør samles og hva som mangler.
2. Tokens: vi definerer det visuelle språket med meningsbærende navn og setter opp den tekniske infrastrukturen for distribusjon.
3. Komponentarkitektur: vi bygger kjernekomponentene med etablerte React-mønstre og headless-biblioteker.
4. Pilot: vi tester systemet i et ekte prosjekt for å bekrefte at det løser problemene teamene har i hverdagen.
5. Skalering og opplæring: vi ruller ut systemet til resten av organisasjonen, holder workshops for utviklere og designere og setter styringsmodellen i drift.

Vi kombinerer designsystemet med UX-design og tjenestedesign, så systemet støtter hele brukerreisen. Du eier koden og Figma-filene vi lager, og de kan ligge i dine egne kontoer hvis du ønsker det.

Verktøyene vi bruker

Dette er verktøyene vi bruker i de fleste designsystemene vi bygger:

• Design og tokens: Figma med variabler og Auto Layout, Tokens Studio, Style Dictionary og formatet til W3C Design Tokens.
• Komponenter: React med TypeScript, Radix UI og React Aria, Tailwind CSS og Storybook for dokumentasjon og testing.
• Infrastruktur: GitHub Actions for CI/CD, NPM eller monorepo for distribusjon, Changesets for versjonering og Zeroheight for dokumentasjon som både designere og utviklere bruker.