Designsystemet i Avinors løsninger
Avinor bygger både interne og eksterne løsninger på Designsystemet, og opplever at samarbeidet mellom design og utvikling flyter bedre.
Avinor har tatt i bruk Designsystemet i flere av sine løsninger, både interne og eksterne. De bruker systemet direkte i løsningene sine, uten å bygge eget designsystem oppå. Løsningene som er bygget på React tar Designsystemet i bruk rett ut av boksen, og egne ikoner og komponenter brukes ved behov.
Erfaringene så langt viser at prosessen mellom design og utvikling har blitt langt mer effektiv, og at samarbeidet mellom design og utvikling flyter bedre. Det går raskere å lage design, overgangen til utvikling er enklere, og variabler og tokens gir et felles språk.
For å lære mer om Avinors erfaringer med Designsystemet, har vi stilt dem noen spørsmål.
Hva var det som gjorde at dere valgte å ta i bruk Designsystemet?
– Vi hadde tidligere et eget designsystem til interne løsninger, men ønsket å teste Designsystemet for å få en mer helhetlig og konsistent opplevelse. Det gir et uttrykk og en semantikk som passer en offentlig aktør, samtidig som det er mer ressurseffektivt enn å utvikle alt selv. Vi får dermed frigjort kapasitet til å fokusere på brukerne, forteller Sverre Øberg, UX Designer i Avinor.
– En stor fordel er at team uten dedikerte designere også kan bruke det, og at de får mye ferdig kode og enklere forvaltning. Det gjør det også enklere å vise frem løsninger, både internt og eksternt.
Hvilke løsninger bruker dere Designsystemet i?
– Vår nylanserte hjemmeside avinor.no har akkurat tatt det i bruk, samt en flyplassassistent vi jobber med. For oss er digitale flater på lufthavnen en viktig del av helheten, og Designsystemet bidrar til å gjøre opplevelsen mer sømløs og gjenkjennbar for både ansatte og reisende, forteller Sverre.
Interne løsninger
– Internt bruker vi det i en rekke løsninger. Vi har blant annet et system som gir oversikt over bagasje på lufthavnene og en værløsnig for brøytemannskaper. Vi har også en løsning som viser nåsituasjon av det som skjer for de som jobber operativt på alle de store lufthavnene.
– Etter hvert kommer vi også til å få det inn i både passasjer-appen vår og en intern app for alle som jobber på lufthavner i Norge. Standarden nå er at om det lages nye løsninger skal man ta i bruk designsystemet, sier Sverre.
Erfaringer
Avinor var tidlig ute med å teste Designsystemet. De forteller at det tok litt tid å bli kjent med både mulighetene og begrensningene, men at dokumentasjonen har vært nyttig i prosessen.
På utviklersiden trekker de frem flere fordeler med å ta Designsystemet i bruk. Det gjør arbeidet mer ressurseffektivt, sikrer universell utforming, og gir tilgang til funksjoner som dark mode og temabygger. Ferdige, gjennomarbeidede komponenter gjør at teamene kan jobbe raskere, samtidig som erfaringsdeling via Slack-kanalen har vært verdifull.
De opplever også at Avinors visuelle profil og identitet kommer tydelig frem i løsningene. Temabyggeren trekkes frem som et sentralt verktøy for å sikre at uttrykket er i tråd med selskapets identitet.
Samtidig har de møtt noen utfordringer. Versjonsoppdateringer har tidvis vært krevende å følge opp, og ulikheter mellom kode og Figma har gitt ekstra arbeid. De peker også på breaking changes ved navneendringer, noe de særlig erfarte i beta-perioden før en stabil versjon ble lansert. I tillegg er enkelte komponenter de har behov for fortsatt ikke dekket av systemet, og dette må de løse selv.
Har bruken av Designsystemet endret måten dere jobber på mellom design og utvikling?
– Ja, prosessen er blitt mye mer effektiv. Det tar langt kortere tid å lage design, og overgangen til utvikling er forenklet. Standardisering gjennom variabler og tokens gir felles vokabular, tydelige guidelines og konsistente farger. Samarbeidet flyter bedre, forteller Sverre.
Hva slags videreutvikling ønsker dere fra Designsystemet fremover?
Avinor ønsker seg flere mønstre og komponenter tilpasset mobilflater, flere løsninger for store skjermer, samt støtte for flere teknologier.
