Å sette opp et designsystem er enkelt. Du tegner opp noen greier i Figma, implementerer noen greier i React, skriver litt om hvordan man burde bruke det, og vips så har du noe du med mye godvilje kan kalle et designsystem.

Å lage et designsystem som er levedyktig over tid, forvaltet på en bærekraftig måte, derimot – det er en skikkelig utfordring! En av de vanskeligste aspektene med å lage gode designsystemer, er nemlig å løse hvordan det skal forvaltes.

Denne artikkelen går ned i forskjellige måter å løse denne forvaltningen på, hva som er opp- og nedsidene med hver av dem, og kommer med en anbefaling rundt hva man burde velge.

Livssyklusen til et designsystem

Et designsystem er som mange andre produkter – det går gjennom forskjellige faser. I denne artikkelen går vi gjennom to av dem:

Oppstartsfasen

Starten til et designsystem er ofte en hektisk periode. Det er nemlig ganske mange ting som skal på plass på veldig kort tid. Noen eksempler er:

• Etablere kjerneprinsipper og design tokens for farge, spacing, typografi osv
• “Byggesteinkomponenter” som knapper, bokser, kort og bilder i både Figma og kode
• Dokumentasjon for alt fra bruk av komponenter til stil og tone
• Verktøykjeden som trengs for å dele kode, komponenter og dokumentasjon med andre i organisasjonen
• Skape initiell adopsjon rundt om i organisasjonen

Arbeidet gjøres ofte av en eller flere ildsjeler, og struktureres vanligvis som et prosjekt.

Forvaltningsfasen

Men det er når det mest grunnleggende er på plass, at det vanskelige virkelig starter. For hva skjer når man er i mål med “prosjektet” designsystem?

Det som typisk skjer i denne fasen er:

• Fokus på iterativ forbedring
• Optimalisering av arbeidsflyt, via tester og utrulling av endringer
• Kontinuerlige brukerstudier og feedback sessions med produktteamene
• Alt fra teknisk forvaltning til produksjon av nye komponenter og retningslinjer
• Versjonering og deprecation av gamle komponenter

Sagt på en annen måte – når man har lagt grunnmuren og skapt noen byggesteiner, er det i forvaltningfasen at man kan begynne å fokusere på den faktiske byggingen. Men hvordan skal denne fasen egentlig formes? Hva slags arbeidsform fungerer best? La oss ta en titt på det.

Forskjellige forvaltningsmodeller

Det finnes i hovedsak tre forskjellige måter å strukturere arbeidet med å forvalte et designsystem på.

Produktteam-modellen

Et designsystem er – på tross av hva du har blitt fortalt – et produkt. Brukerne dine er kanskje interne istedenfor eksterne, men det er et verdifullt produkt som utvikles og lages innenfor de samme rammene som ethvert annet produkt.

I boken Team Topologies definerer Manuel Pais og Matthew Skelton en rekke forskjellige team-typer. Innenfor dette rammeverket ville man plassert et designsystemteam innenfor plattformteam-kategorien. Plattformteamets rolle er å tilby en felles, gjenbrukbar infrastruktur og komponenter som de andre, “stream-aligned” teamene i organisasjonen kan bygge på. Designsystemteamet fungerer da som en intern leverandør av verktøy, retningslinjer og ferdige byggeklosser, slik at produktteamene kan levere verdi raskere og mer konsistent uten å måtte “finne opp hjulet på nytt” hver gang. Andre eksempler på slike team er infrastruktur-team og sikkerhetsteam.

Som produktteam, har designsystemteamet gode premisser for å forvalte og videreutvikle designsystemet. Noen av det teamet vil fokusere på da er:

• Bygge et internt (eller eksternt) brand for designsystemet
• Jobbe aktivt med kontinuerlig innsiktsarbeid fra organisasjonen
• Fokusere på å lage systemer som fungerer på tvers av team og brukere
• Forbedre utvikler- og designeropplevelsen for å gjøre produktteamene så effektive som mulig
• Fungere som et slags “designpoliti” på tvers av organisasjonen

Det finnes flere store organisasjoner som har slike team, som for eksempel Nav (Team Aksel) og Gjensidige (Team Builders), og som har lykkes veldig godt med denne modellen.

Nedsiden med produktteam-modellen er at den ofte er vanskelig å selge inn rent politisk. Interne team er dyre, og å kutte et mer strøm-rettet produktteam til fordel for et designsystemteam sitter ofte langt inne for forretningssiden. Det er også en reell risiko for at man ender opp med et designsystem er “for” bra – at man overinvesterer uten å få noen merverdi tilbake.

Dugnadsmodellen

Motsetningen til produktteam-modellen er dugnadsmodellen. I en dugnadsmodell er det ingen som “eier” designsystemet som helhet, men det forvaltes på tvers av organisasjonen ved hjelp av utviklere og designere fra forskjellige produktteam, som tilfeldigvis har litt tid til overs.

I en dugnadsmodell, er du veldig avhengig av at det er noen som tar et uformelt eierskap til designsystemet, slik at man klarer å drive de prosessene og forvalte infrastrukturen som skal til for å “holde lysene på”.

Det er også helt avgjørende at designsystemet brukes aktivt av mesteparten av organisasjonen for at en dugnadsmodell skal kunne fungere. Hvis det kun er et fåtall team som kan bidra inn, vil farten i de aller fleste tilfeller bli for lav. Det er også viktig at produktlederne i de forskjellige teamene har fått “lov” til å bruke litt av tiden sin til å forvalte designsystemet av sine ledere igjen – ellers vil det fort bli vanskelig å forsvare eventuelle bidrag oppover i organisasjoner.

Det er flere ulemper med dugnadsmodellen:

• Man er veldig eksponert for at designsystemet kan “råtne på rot” om feil ildsjel bytter jobb
• Det er vanskelig å vedlikeholde en helhetlig look-and-feel og utvikleropplevelse, som fører til at det blir vanskeligere å bruke
• Bidrag til designsystemet blir ofte nedprioritert av produktteamene, som igjen fører til lite videreutvikling, synkende adopsjon og avgrunn.

Vi er ikke så glad i dugnadsmodellen – og vi har heller ikke erfart at den fungerer spesielt godt noe sted.

Hybridmodellen

Noe som er mer vanlig er en slags kombinasjon av de to ytterpunktene – hva vi kaller en hybridmodell.

I hybridmodellen forvaltes designsystemet av et veldig lite kjerneteam. Deltakerne i dette teamet kan gjerne være med i andre produktteam, men har deler av arbeidstiden sin (f.eks. 50 %) avsatt til å jobbe med og forvalte designsystemet. Dette sikrer et faktisk eierskap, fast fremgang, og noen som kan holde i tverrliggende behov.

Teamet styrer og koordinerer resten av organisasjonen, arrangerer samarbeids- og synkroniseringsmøter, og hjelper andre produktteam med å koordinere arbeidet seg i mellom.

Utviklingen av nye design og komponenter skjer som regel i produktteamene – enten i workshops eller på eget initiativ.

En hybridmodell kan fungere godt, gitt at man har de riktige folka i kjerneteamet. Man trenger å ha noen som kan “selge” inn viktigheten av designsystemet på tvers av organisasjonen, og fagfolk som er flinke til å disponere tiden sin. Man løper allikevel risikoen av at resten av produktteamene ikke bidrar nok til å kunne lage et produkt som er godt nok til å bli brukt og elsket på tvers av organisasjonen.

Alt handler om kontekst

Det er ikke én forvaltningsmodell som passer for alle designsystem. Hva som funker i din kontekst avhenger av hva slags rammebetingelser man har rundt seg. Egentlig vil vi argumentere for at forvaltningsmodellen avhenger av antall brukere.

Jobber man i en organisasjon med kun et fåtall produktteam, bør man vurdere en dugnads- eller hybridmodell. Så lenge man har en ildsjel til å holde i det hele, og gir den personen nok tid til å holde i prosess og delt infrastruktur, kan resten av organisasjonen være nærme nok til å faktisk kunne bidra.

I mellomstore og større organisasjoner bør man vurdere å jobbe seg mot et eget produktteam for designsystemet. Nedslagsflaten blir fort stor, og forventningene til både design- og utvikleropplevelsen øker. Veien dit kan gjerne være i form av en hybridmodell, men sluttmålet bør alltid være et eget produktteam med egne ambisjoner, nøkkelresultater og effekteiere.

Man trenger heller ikke binde seg til en forvaltningsmodell. Man kan starte med en dugnadsmodell i starten, bygge seg opp til en hybridmodell, før man skalerer opp til et eget designsystemteam til slutt. Og får man jobbet lenge nok med et designsystem til at man føler at vinningen går opp i spinningen, så kan man endre modell igjen.