Som en del av forarbeidet til utviklingen av Sprik ble det gjort omfattende dokumentasjon av behovet for en ny løsning, og hvordan en eventuell løsning ville være hensiktsmessig å utforme.
Dokumentasjonen er resultatet av brukerintervjuer, innsiktsarbeid, prototyping og funksjonalitetsprioritering.
Dokumentasjonen beskriver teknologien bak applikasjonen, referater fra innsiktsarbeidet, lenker til prototypeskissering i Figma, ROS og definerer problemet som Sprik skal løse.
- React & Typescript
- Aksel & TailwindCSS
- Axios & Ktor
- Kotlin
- PostegreSQL & Flyway
- HikariCP & Exposed
- JUnit & Cypress
- Yarn & Gradle
Når saksbehandlere oppdager feil eller avvik i sykepengeløsningen Speil må dette meldes til utviklingsteamet.
Vår oppgave var å få innsikt i utfordringer ved dagens løsning, behovene til saksbehandlere og utviklingsteamet, samt påbegynne en løsning basert på innsiktsarbeidet.
-
Dagens løsning for kommunikasjon mellom saksbehandlere og teamet er både treig og lang. Saksbehandler → Teams → Coach → slack → Teams
-
Det er ikke tilstrekkelig tilgangskontroll for å verne om brukere (personvern), under innmelding av saker. Saker relatert til kode 6 og 7 brukere er veldig utsatte i dagens løsning da de kan formidles mot mange som ikke har tjenstlig behov for informasjonen.
-
De fleste saksbehandlere har ikke direkte mulighet til å melde ifra om feil og feature requests hvilket kan føre til at mange feil går under radaren.
-
Uoversiktlig presentasjon og formidling av saker fører til at saker rapporteres inn gjentatte ganger (dobbelt arbeid), at de kan glemmes bort, og i verste fall gå uløst.
-
Det er et utydelig skille mellom feature-requests og innmeldte feil i dagens løsning.
-
Det er vanskelig å se hvem som er egnet til å besvare
Applikasjonens formål er i henhold til oppgaveteksten:
Lage en applikasjon der saksbehandlere kan melde inn feil/mangler/ønsker. Og potensielt en visning over hva som er meldt inn.
Feil med speil skal kunne gi både saksbehandlere og utviklere en raskere og bedre flyt i kommunikasjonen. Dette vil føre til at vi utviklere kan oppdage og rette opp i feil raskere. Det vil forhåpentligvis også føre til en bedre saksbehandleropplevelse.
"Lage et fantastisk produkt som har ekstremt stor verdi for de fine saksbehandlerne og strålende utviklerne."
Dette mener vi at vi har fått til når:
- 80% av saksbehandlere klarer å melde inn feil (KR1)
- 75% av brukere synes Sprik er mer oversiktlig enn dagens løsninger (KR2)
- Ingen uten tjenstlig behov har tilgang til persondata i innmeldte saker (KR3)
KR1 og KR2:
- Ikke hatt brukertester med saksbehandlere der de får prøve å bruke applikasjonene selv grunnet mangel på tid. Derfor har vi ikke målbare tall. KR3:
- Har foreløpig ikke implementert tilgangskontroll.
Fokus i sommer:
- Viktige saker første fire uker:
- Få på plass basic funksjonalitet
- Forstå hva tjenesten innebærer og illustrere dette i prototype
- Få deploya applikasjonen i devmiljø
- Viktige saker siste fire uker:
- Ha en brukervennlig applikasjon
- Et utvalg av brukere har begynt å teste/ta i bruk applikasjonen
- Ha en overføringsklar dokumentasjonsbase
- Implementere alle must-haves
Frontend applikasjonen bygges med React på TypeScript
Applikasjonen er hovedsaklig bygget av komponentbiblioteket til NAVs designsystem Aksel, men egen styling gjøres gjennom utility-first rammeverket TailwindCSS. Tailwind sine små utilityklasser er kompatible med Aksel og gjør at styling går svært fort. Ikoner og farger er også hentet fra Aksel.
Axios benyttes som HTTP klient-rammeverk for kommunikasjon med endepunkter i backend. Ktor er en asynkron HTTP server, som brukes som et HTTP API. Ktor hører til Kotlin språket.
Kotlin er et moderne javabasert språk. Applikasjonens backend er skrevet i Kotlin.
Databasen er skrevet i PostgreSQL og i backenden brukes Flyway rammeverket for migrering av databasen slik at en enkelt kan gjøre endringer på databasen
HikariCP danner en database connection pool mellom DB og backend. Exposed er jetbrains sin SQL-ORM for Kotlin, som brukes til å gjøre spørringer mot databasen. Sammen utgjør de kommunikasjonen mellom Backend og database.
JUnit er et Kotlin kompatibelt testrammeverk, og Cypress er et testrammeverk for frontend som kan utføre både komponenttesting og ende-til-ende testing. Cypress-axe er en pakke for cypress som kan brukes til UU-testing.
Yarn og Gradle er dependency-management verktøyene for frontend og backend applikasjonene.
-
Hva anser du som en utfordring ved å bruke dagens løsning (slack)?
- Utfordring at mange av saksbehandlerne ikke er på slack
- Teams = møk
- Delayed rapportering fordi det er en lang vei
- Gjentakende rapportering av samme feil
- Noen kan vurdere det som meldes inn før det går videre til teamet.
- Usikker på om redteam er nødvendig i kommunikasjonsprosessen
- Tråd kommunikasjonen er tungvinnt
- Ting vi har avklart drukner i slack
- Utfordring at mange av saksbehandlerne ikke er på slack
-
Er det noe du er fornøyd med rundt dagens løsning?
- Redteam løsningen vi har i dag fungerer ganske bra, med tanke på å rotere på hvem som er redteam
-
Hva slags arbeidsflyt ønsker du å ha med ny løsning?
- Varslinger nice, ellers lite preferanser
-
Hva er spesielt viktig for saksbehandlere/utviklere/jurister/designer/… å få ut av en slik plattform.
- Vanskelig å fange opp hvor stor grad en feil skjer.
- Jetbrains har en issue tracker med voting
- De kan se hvilke feil som er meldt inn og saksbehandlere skal kunne vote opp spesiellt relevante cases for å se “hvor skoen trykker i systemet”
-
Hvilke data ønsker du skal være presentert om en sak i Sprik?
- Greit å ha med innmelder av en sak
- Greit at utvikler kan labele saker mtp app og sann
- Kunne generere lapper i Trello.
-
Hvordan kunne du sett for deg at dataen presenteres i sprik?
- Enkelt kunne skille feil og feature requests
- Enkle detaljer
- Sortere etter traction etc
- Kanskje tenk gallery view, eller feed.
- Type feil: Feilinfo, handlingsfeil, grensesnittsfeil etc.
-
Feature requests
- Vanskelig å sørge for at saksbehandlere ikke blir demotiverte dersom endringene ikke skjer.
- Feature voting side hvor man kan vote opp feature forslag
- Lar utviklere se hvor skoen trykker
- Veldig delte meninger
-
Hvilke behov ønsker du at applikasjonen skal dekke? (forstå hva folk vil bruke det til)
- “Jeg bruker appen når jeg er redteam”
- Enkel måte å få vite om noe er galt, vite om noe haster eller ikke”
- Ikke en stor blob med tekst men kategorisert og organisert.
- Voting er bra for å se hva som er veldig aktuellt.
- Hashtags/emneknagger/tags for å organisere i type feil → ser antall feil av en type.
-
Hvilken funksjonalitet er det viktig for deg at er med i applikasjon?
- “Feilen kommer lett frem”, “beskrivelse av casen” hadde vært enkelt med en kort tittel på problemet.
- Oversikt over hva som er meldt inn tidligere
-
Hvilken funksjonalitet tenker du har mest verdi for deg? Altså hva er viktigst først?
- Å kunne kategoriesere hvilke feil man har
- Få inntrykk av hvilke features som eksisterer samt muligheten til å komme med tilbakemelding.
-
Hva anser du som en utfordring ved å bruke dagens løsning (Slack)?
- Ikke god oversikt over hva som er meldt ifra før
- Vanskelig å se hvem som passer til å svare på spm
-
Hva er den største av disse utfordringene?
- Vanskelig å ha oversikt over hva som er meldt inn (enklere med status, men tungvinnt).
- Mistenker dobbelt arbeid
-
Er det noe du er fornøyd med rundt dagens løsning?
- Mulighet til å ta kontakt med saksbehandlere hvis det trengs (ved feks ønske om flere opplysninger)
- Trådsvar - nais to have, ikke kritisk
-
Hva slags arbeidsflyt ønsker du å ha med ny løsning?
- Er en del felter som ville gjort det enklere (Dette går under data også)
- Skjermbilde
- Tags
- AktørID
- Egendefinerte tags
- Kan være en utfordring med flere måter å definere et begrep (grunnbeløp vs G vs 6G)
- Tildele til personer
- Er en del felter som ville gjort det enklere (Dette går under data også)
-
Hva er spesielt viktig for saksbehandlere/utviklere/jurister/designer/… å få ut av en slik plattform.
- Unngå dobbeltarbeid
- Sortere traction eller hvor kritisk det er
-
Hvilke data ønsker du skal være presentert om en sak i Sprik
- +aktøride
- +skjermbilde
- +tags
- +tittel,
- +status
- +innmeldt saksbehandler
- statusflagg?
- forklarende bilde?
- Saksnummer?
- Beskrivelse?
- innsender?
- mer?
-
Hvordan kunne du sett for deg at dataen presenteres i sprik?
- Galleri-visning
-
Syntes du at redteam ordningen som et vaktlag skal implementeres videre? har du noe forslag
- Red team har tatt lang tid å få til å fungere
- Er ikke nødvendigvis beste løsning
- Handler om at man skal rullere for å få noen til å ta ansvar
-
Hva er din opplevelse av dagens løsning?
- Skille mellom innspill og feil kan være litt uklart
- Det er bra med direkte kontakt (fine med meldingstjenesten)
- En del som meldes inn flere ganger
- En del saksbehandlere man ikke har kontakt med
-
Hvorfor fungerer ikke dagens løsning?
- Ikke kontakt med alle saksbehandlere ~ saksbehandler-kanalen kan bli litt uoversiktelig
- Viktig-info kanalen funker fint ettersom det kun kommer enveis-meldinger
- Er nok en del feil som glipper (går under radaren/ikke blir meldt inn)
-
Hva er de største utfordringene i dagens løsning?
- Går under radaren
- Hvorfor? Travel hverdag
- Slack ikke optimal til oppfølging
- Går under radaren
-
Hva fungerer godt i dagens løsning?
- Funker bra at det er en direkte kontakt mellom saksbehandlere og utviklingsteam (ikke erstatte dette)
- Gir ett forhold til brukeren og løsninga si
- Mange ting som blir fiksa fortløpende
- Funker bra at det er en direkte kontakt mellom saksbehandlere og utviklingsteam (ikke erstatte dette)
-
Hva er det viktigste for deg som (utvikler/saksbehandler/…) å oppnå med plattformen?
- Hjelpe dem med å jobbe med de riktige tingene
- Slippe å bruke unødvendig tid
-
Hva tenker du er formålet med Sprik?
- Å fjerne gapet mellom saksbehandlere og utviklingsteam
- Gapet = de som ikke er i Slack, ikke alle tør å poste i Slack (fører til lite kontakt)
- Få flere informerte saksbehandlere
- Å fjerne gapet mellom saksbehandlere og utviklingsteam
-
ukategorisert
- en ting som kunne vært kult hvis vi skal jobbe med målinger, kunne vært kult med temperaturmålinger for saksbehandling (hvordan trives du med å jobbe i speil, får du hjelp når du trenger det, hvordan har du det, hvordan er motivasjonen, målt over tid for å påvirke prouktet)
- hvordan gjøres: brukt en vanlig helsesjekk i starten for å sjekke om de vil bruke denne, evt. spesiallaget noe i speil der det kommer en boble i speil eksempelvis hver fredag som tar 30sek å svare på
- kunne forbedret dagens løsning
- vanlig spørsmål og svar (q&a forum)
- hvordan gjør jeg dette og dette
- løsning: faq side
- vanlig spørsmål og svar (q&a forum)
- tips
- intervjue de som ikke er i slack av saksbehandlere (ikke like mye innsikt, mer realistisk brukeropplevelse)
- rammeverk å tenke på når vi skal arbeide:
- kjapt å lage → tar lang tid å lage (x akse)
- lav verdi ^ høy verdi (y akse)
- lapper med forslag man plasserer på grafen
- prioriterer kjapt å lage med høy verdi
- redteam fungerer?
- funker, men må kanskje gjøres på en annen måte ved ny løsning
- det de blir tagga i blir oftest løst, men er fortsatt ting som kan forsvinne pga. mengden meldinger
- ikke alle i redteam er like på, eksempelvis jurister, til å svare på saker
- en ting som kunne vært kult hvis vi skal jobbe med målinger, kunne vært kult med temperaturmålinger for saksbehandling (hvordan trives du med å jobbe i speil, får du hjelp når du trenger det, hvordan har du det, hvordan er motivasjonen, målt over tid for å påvirke prouktet)
- Hva skal vi kalle hvert element (lapp, feilmelding, feil)?
- Innmeldte feil (med parantes på)
- Hva syntes du om statuslappene?
- Likte statuslabelsa
- Dropdown var veldig intuitivt
- For å holde oversikt over egne saker, syntes du det funker å bare bruke filtrering for dette? (evt. bruke egne farger for lapper eller labels)
- filtrering enten høyere eller venstre side, mer naturlig på venstresiden
- egne saker → filtrer etter initialer
- filtrer automatisk etter kronologisk tid, tidligst først
- egen farger for egne saker kan bli litt mye
- Hva tenker du om å se feil på denne måten? (oversiktelig?)
- Førsteinntrykk er mye, men etterhvert veldig oversiktelig
- “melde inn feil/funksjonalitetsønsker”-knapper legges høyere
- Hva er det første du ser?
- Mye informasjon, mye tekst, må bruke litt tid for å forstå hva det egt er
- “Hva er søkefeltet til”-spørsmål
-
Hvordan syntes du det er å jobbe med speil idag?
- Kan du fortelle litt om hvordan du bruker Speil i dag?
- Skjønte ikke helt spørsmålet her
- Hvordan går du frem når du finner feil i Speil i dag?
- Tar kontakt med coacher eller super
- De melder videre
- eller kan melde fra i support-kanal på teams
- Kan du fortelle litt om hvordan du bruker Speil i dag?
-
Hvordan synes du feilinnmelding angående Speil fungerer i dag?
- Slack ble fjernet som forstyrrende element i arbeid
- mener de fortsatt burde hatt slack, lavere terskel for å melde inn
- tungvinnt å gå via coacher
- La kanskje til henne en mening om lang vei??
-
Hvordan syntes du det er å jobbe med speil idag?
- Kan du fortelle litt om hvordan du bruker Speil i dag?
- Hvordan går du frem når du finner feil i Speil i dag?
- Går til coach som melder til utvikler
- Svarer som de gjør fordi hovedproblemet med å jobbe med sykepenger fordi det er for mange som ikke kan sykepenger
- omfattende domene
- Noen er raske fordi vi har produksjonstall
- Lang tid å skaffe domene kunnskap
- Mange tror de kan sette seg ned og bare gjøre ting, det er mye å sette seg inn i
-
Hvordan synes du feilinnmelding angående Speil fungerer i dag?
- Det er så som så
- tror at utfordringen er at noen enheter er flinke til å bruke faglige ressurser rundt seg, samtidig som andre bruker support rollen
- Bruker ikke mye tid der, men drukner i repetetive innmeldinger.
- brukerutbetaling skaper mange feil → større konsekvens
- Siden det er så komplisert det vi jobber med (sykepenger) → fordi ting gjøres automatisk
- Det er så som så
- Hva er det viktigste for deg i en ny løsning for feilinnmelding?
- det må være toveiskommunikasjon
- å melde inn er ikke nok så lenge man ikke får noe respons
- Hvordan synes du feilinnmelding angående Speil fungerer i dag?
- Er det noe som fungerer godt?
- Er det noe som fungerer mindre godt?
- ordinær opplæring innenfor fag og systemer, fungerte ikke fordi ingen har kunnskaper om speil
- er veldig misfornøyd med oversikten over benken min
| Ønsker | Intervjuobjekt | Prioritet | Brukerhistorie |
|---|---|---|---|
| Kunne se helt tydelig, uten å grave i diskusjonstråd, hva status og konklusjon er for en sak. | Saksbehandler | - Jeg vil se behandlingsstatus på en sak - Jeg ønsker å enkelt kunne finne frem konklusjonen for en lukket sak |
|
| Ønsker type nyhets feed eller gallery view | Utvikler | - Jeg vil se en ryddig og organisert visning av innmeldte saker | |
| Ryddig oversikt over innmeldte saker | Utvikler | - Jeg vil se en ryddig og organisert visning av innmeldte saker | |
| Voting er bra for å se hva som er aktuelt | Utvikler | - Jeg vil se hvor aktuell en sak er | |
| Måle “traction” på ulike saker for å fange opp i hvor stor grad en feil skjer. Foreslår et voting system. Hvor trykker skoen i systemet. Fint om utviklere kan sortere etter traction | Utvikler | Største ønske | - Jeg vil se hvor akutell en sak er - Jeg ønsker å sortere etter hvor aktuell en sak er |
| Se om en sak er rapportert tidligere evt behandlet (unngå gjentakende rapportering) | Saksbehandler | Største ønske | - Jeg vil sjekke om en sak er rapportert inn tidligere - Jeg vil se behandlingsstatus på en sak |
| Tydelig skille mellom rapporterte feil og feature requests | Utvikler | - Jeg vil se tydelig skille mellom feature requests for en sak jeg "følger" | |
| Bli varslet om aktivitet på en sak/post (diskusjon, status endringer, etc.). Da slipper man å overvåke. | Saksbehandler | - Jeg vil varsles ved endringer/aktiviteter for en sak jeg "følger" | |
| Kunne være i direkte kontakt med utviklere | Saksbehandler | - Jeg ønsker å ha direkte kontakt med saksbehandler/utvikler | |
| Utvikler skal kunne varsle saksbehandler dersom mer informasjon om sak trengs for å løse den. | Saksbehandler | - Jeg ønsker å ha direkte kontakt med saksbehandler/utvikler | |
| Kunne kontakte saksbehandler dersom det trengs for ytterligere info om saken | Utvikler | - Jeg ønsker å ha idrekte kontakt med saksbehandler/utvikler | |
| Kunne søke opp saker på nøkkelord | Saksbehandler | Største ønske | - Jeg ønsker å kunne søke opp saker på nøkkelord og tagger |
| Generere lapper på en sak i Trello | Utvikler | Nice to have | - Jeg ønsker å lage en lapp på en sak i Trello |
| Mulighet til å initiere samtale relatert til posten. Utviklere og saksbehandlre kan ha en dialog som kan organiseres i en tråd festet til en post. | Saksbehandler | - Jeg ønsker å lese/skrive i diskusjonstråd for en sak | |
| Trådsvar | Utvikler | Nice to have | - Jeg ønsker å lese/skrive i diskusjonstråd for en sak |
| Kunne se en diskusjonstråd eller annen aktivtet/varsler rundt en sak. | Saksbehandler | - Jeg ønsker å lese/skrive i diskusjonstråd for en sak - Jeg vil varsles ved endringer/aktiviteter for en sak jeg "følger" |
|
| En sak skal kunne innehold skjermbilder, beskrivelse, aktør-id og dato(er) | Saksbehandler | - Jeg ønsker å opprette/lese en sak som inneholder tittel, beskrivelse, skjermbilder, datoer, innmelder, feiltype (grensesnitt, handling, logik) og behandlingsstatus | |
| Innmelder må være felt på en sak, type feil (grensesnitt, handlingsfeil, verdifeil) | Utvikler | - Jeg ønsker å opprette/lese en sak som inneholder tittel, beskrivelse, skjermbilder, datoer, innmelder, feiltype (grensesnitt, handling, logik) og behandlingsstatus | |
| Feilen kommer lett frem med en beskrivelse og tittel | Utvikler | - Jeg ønsker å opprette/lese en sak som inneholder tittel, beskrivelse, skjermbilder, datoer, innmelder, feiltype (grensesnitt, handling, logik) og behandlingsstatus | |
| Sak burde ha aktørid, mulighet for skjermbilde opplastning, tags, tittel, status. innmelder (saksbehandler) | Utvikler | - Jeg ønsker å opprette/lese en sak som inneholder tittel, beskrivelse, skjermbilder, datoer, innmelder, feiltype (grensesnitt, handling, logik) og behandlingsstatus | |
| Oversikt over hva som støttes i Speil. Funksjonalitetsoversikt (kommunikasjonskanal for ny funksjonalitet i Speil) | Saksbehandler | - Jeg ønsker å se hvilken funksjonalitet som Speil har | |
| Få inntrykk av hvilke features som eksisterer samt. muligheten til å komme med tilbakemelding | Utvikler | Største ønske | - Jeg ønsker å se hvilken ufnksjonalitet som Speil har |
| Se om saken haster å løse | Utvikler | - Jeg ønsker å se om en sak haster å løse | |
| Utviklere skal kunne gi en label til en sak ifht. relatert app | Utvikler | Jeg ønsker å tildele en sak en emneknagg | |
| Kategoriere hvilke typer feil som finnes | Utvikler | Største ønske | - Jeg ønsker å tildele en sak en emneknagg |
| Hashtags/emneknagger | tags for å organisere i type feil -> ser antall feil av en type. Disse kan være egendefinerte | Utvikler | |
| Ha et "beredskapsteam" (redteam), som svarer raskt | Saksbehandler | REDTEAM | |
| Låse en løst tråd??? | Saksbehandler | ||
| Vurdere en innmeldt sak før den sendes videre til utviklingsteam - for å unngå gjentakende rapportering | Utvikler |
| Funksjonalitet | Implementasjonsdetaljer | MoSCoW | Status |
|---|---|---|---|
| Oppdatere innmeldt feil | Must have (dev) | Done (mangler aktorid) | |
| Saksbehandlere skal kunne melde inn saker | • Legge til en god beskrivelse av saken (~ juss) ◦ Skjermbilder, aktør-id, datoer ◦ Se en oversikt over meldte saker (egne saker? ~ juss) |
Must have (dev) | Done |
| Kunne se innmeldte feil | Must have (dev) | Done | |
| Teamet skal kunne gi beskjed om at saker er løst | Must have (dev) | Done | |
| Enkelt se konklusjon av en sak | Must have (dev) | Done | |
| Søkefunksjonalitet | Must have (dev) | Done | |
| Redigere innmeldt feil | Should have | Done | |
| Filtrering av saker etter type feil og lables | Should have | Started frontend | |
| Gi labels/kategorisering av/til feil | Should have | Not started | |
| Kunne oppdage at noe er meldt inn tidligere | Could have | Not started | |
| Kunne stemme på saker for å måle "hvor skoen trykker i systemet" | Could have | Not started | |
| Trådsvar | Could have | Not started | |
| Oversikt over kjente feil / løsninger | Could have | Not started | |
| Opprette Trello lapper direkte fra appen på en rapportert sak | Will not have | Not started | |
| Formidle støttet funksjonalitet i Speil | Will not have | Not started | |
| Komme med tilbakemelding på støttet funksjonalitet i Speil | Will not have | Not started | |
| FAQ side om Speil | Will not have | Not started | |
| Sortering av saker etter traction | Will not have | Not started | |
| Ved jobbing med målinger hadde det vært kult med temperaturmålings for saksbehandling (spørsmål rundt trivsel målt over tid for å påvirke produktet) | Will not have | Not started | |
| Direkte kontakt mellom de to partene | Must have (prod) | Not started |
Hensyn å ta:
- Hvem har tjenstlig behov for å se innmeldte feil?
- Tilgangskontroll
- Logging og sporing
- Skal alle kunne se alle felter av innmeldte feil?
- Skal kun RedTeam se saker?
- Personvernhensyn
- Akørid må nesten med både for å kunne sjekke en sak, men også for å logge hvordan en brukers info er behandlet
- Ha info-bokser for å minne på at personopplysninger ikke skal deles
- Kan ha en pop-up som kommer når man trykker "meld inn sak" som ber innmelder dobbeltsjekke personopplysninger
- Deling av personopplysninger i skjermbilde?
- Færre muligheter for å skrive fritekst kan redusere sannsynligheten for å dele for mye, men kan bli vanskelig med standard kategorier som er dekkende
- Spesielle hensyn å ta ang. kode 6 og 7?
ROS er påbegynt og registert i TryggNok
- Applikasjonen er skissert i Figma.
- Figma prosjektet finner du her.
- Underveis i designprosessen har UX/UI-Designer i PO-Helse gitt råd.
- Prototypen er raffinert gjennom flere iterasjoner med brukerintervjuer av fagfolk, utviklere og saksbehandlere.
- Prototypen bygges på designsystemet Aksel sine tokens og komponenter.