Aksel er til for å hjelpe de tverrfaglige produktteamene i NAV med styling, komponenter og retningslinjer. I denne artikkelen forklarer vi relasjonen mellom Aksel og produktteamene, og hvordan vi sammen utvikler designsystemet.

Aksel er basert på samarbeidet mellom produktteamene og team Aksel. Team Aksel jobber fulltid med å forvalte alle delene av designsystemet, og produktteamene hjelper til med bidrag og erfaringer. Vi sitter alle med forskjellige perspektiver og ekspertise som vi tar med inn i utviklingen av Aksel.

Hvordan bruke Aksel

Aksel skal brukes av alle produktteamene, men i hvilket omfang kommer an på produktet som teamet er ansvarlig for. Noen team kan bruke alt fra Aksel, mens team som har eldre produkter kanskje bare kan bruke deler av det Aksel tilbyr. Vi kan dele opp Aksel på denne måten: design tokens (styling/CSS-variabler), komponenter og retningslinjer.

Design tokens (styling/CSS-variabler)

Design tokens er obligatorisk for alle produkter som har et grafisk grensesnitt. Det er dette som er grunnlaget i alle komponentene og theming-muligheter som dark mode og høykontrastmodus. Design tokens har innebygde designavgjørelser som kommuniserer NAVs brand og tilfredsstiller UX/UU-krav.

Komponenter

Komponentene i Aksel er bygget med React og følger viktige UU- og UX-prinsipper. Om teamet ditt kan bruke komponentene er avhengig av deres tekniske løsninger. Det kommer også an på hvilke komponenter produktet har behov for selvsagt. Det beste er om du kan bruke komponentene ut av boksen. Da får du og teamet ditt mye gratis, og det lønner seg for hele NAV at vi gjenbruker komponenter når det er mulig. Det nest beste er at du speiler dem funksjonelt og visuelt i egen løsning så godt det lar seg gjøre.

Retningslinjer

Den enhetlige brukeropplevelsen på tvers av produkter vil bli bedre om vi løser ting likt. Retningslinjene på Aksel er basert på en blanding av UU-krav, UX-prinsipper og erfaringer fra produktteamene i NAV.

Behov for endringer eller nye ting

Hva er prosessen om du oppdager at noe ikke helt passer for deg, eller at noe mangler i Aksel? Tid for samarbeid! Vi skal ikke tvinge deg til å pugge et avansert flytdiagram som beskriver hvordan du skal gå fram. Samarbeid med Aksel skal være lavterskel og hyggelig! Men det er viktig at du tar kontakt med oss. Vi er ikke tankelesere 🧘

Enkle saker

For avklaringer og spørsmål er det veldig enkelt å bruke Slack. Det er bare å joine kanalen #aksel-designsystemet med en gang. Der hjelper hele produktutviklingsmiljøet hverandre med stort og smått. Om kanalen ikke funker for deg kan du sende DM til oss i team Aksel.

Komplekse saker

Om du trenger å endre på noen komponenter eller bygge nye komponenter ønsker vi å ta en prat med deg. I løpet av praten vil vi finne ut av kompleksiteten og hva ditt team har kapasitet til. Vi i team Aksel har lite lyst til å bli en propp i deres produktutvikling. Derfor vil vi finne ut hva ditt team kan bidra med av konsept, design og kode. Dere skal slippe å forholde dere til alt det systemrelaterte, det fikser vi.

Eksempler på retninger en samtale kan ta:

• Endringen gir bare mening for ditt team. Ditt team lager en lokal komponent. Vi har dialog om hvordan det går, og ser om andre team får samme behov etter hvert.
• Endringen er relativt enkel, og andre team har samme behov. Teamet ditt kan lage en forespørsel på endringen i Aksel, som kalles PR (pull request). Team Aksel hjelper til og følger opp PR’en.
• Endringen er avansert, eller det skal bygges en ny komponent. Ditt team og team Aksel samarbeider om en løsning. Vi finner ut av arbeidsfordelingen.

Bidrag = kvalitetsstempel

Samarbeidet som vi har beskrevet over betyr at produktteam aktivt bidrar til eller med kode/design til Aksel. Denne samarbeidsformen kan gi produktutviklingen i NAV store gevinster, og er det motsatte av et bestillingssystem. En så stor produktorganisasjon som NAV trenger prosesser som skalerer og som involverer bredt. Da har man ikke lyst på et sentralt team som tar imot bestillinger og blir en propp for produktutviklingen. Når et team bidrar vil de også lære litt om hvordan komponentene er satt sammen, hvordan design tokens brukes, navngivning, API-design, etc. Dette vil spre kunnskapen om hvordan designsystemet funker utover i organisasjonen. Når kunnskapen og tryggheten øker vil forhåpentligvis antall bidrag også øke.
Det er win, win, win! 🙌