# Digdirs arkitekturprinsipp 1: Brukerorientering

**Last updated:** 2026-02
**Status:** Gjeldende
**Category:** Norwegian Public Sector AI Governance
**Type:** reference
**Source:** https://learn.microsoft.com/azure/well-architected/ai/responsible-ai

---

## Innhold

- [Introduksjon](#introduksjon)
- [Prinsippets kjerneinnhold](#prinsippets-kjerneinnhold)
- [Anvendelse på AI-løsninger](#anvendelse-på-ai-løsninger)
- [Beslutningsveiledning](#beslutningsveiledning)
- [Eksempler fra norsk offentlig sektor](#eksempler-fra-norsk-offentlig-sektor)
- [For arkitekten](#for-arkitekten)
- [Kilder og verifisering](#kilder-og-verifisering)

## Introduksjon

Brukerorientering er det første og mest fundamentale arkitekturprinsippet etablert av Digitaliseringsdirektoratet (Digdir) for offentlig sektor i Norge. Prinsippet slår fast at **offentlige tjenester skal være basert på brukernes behov og perspektiver, og være brukbare for alle, uavhengig av alder og funksjonsevne**.

Dette prinsippet er gjort obligatorisk for statlig sektor gjennom digitaliseringssirkulæret og er anbefalt for kommunal sektor. Det skal anvendes ved etablering av nye IT-løsninger eller ved vesentlig ombygging av eksisterende IT-løsninger, og gjelder både for egenutviklede løsninger og ved anskaffelser.

For AI-løsninger er brukerorientering spesielt kritisk. AI-systemer opererer ofte med komplekse beslutningsprosesser som ikke er umiddelbart forståelige for brukerne. Samtidig plasserer brukerne sin tillit i systemets etiske funksjonalitet, selv når de ikke forstår den underliggende logikken. Dette gjør det essensielt å bygge AI-løsninger som aktivt involverer brukere, sikrer universell utforming (UU), og gir forståelige forklaringer på AI-beslutninger.

## Prinsippets kjerneinnhold

### Digdirs formulering

Prinsippet har tre hovedkomponenter:

1. **Basert på brukernes behov og perspektiver** — Tjenesteutvikling skal starte med innsikt i hva brukerne faktisk trenger, ikke med hva teknologien kan tilby
2. **Brukbar for alle** — Universell utforming skal sikre at tjenester fungerer uavhengig av brukerens alder eller funksjonsevne
3. **Sammenhengende tjenester** — Tjenester skal oppleves som helhetlige på tvers av etater, ikke som fragmenterte silo-løsninger

### Underliggende krav

Brukerorientering stiller flere konkrete krav til utvikling:

- **Brukerinvolvering** — Brukere skal involveres gjennom hele utviklingsløpet, fra problemdefinisjon til testing og iterasjon
- **Tilgjengelighet** — Løsninger skal følge WCAG 2.1-standarder (minimum nivå AA) og være testbare med hjelpemiddelteknologi
- **Transparens** — Brukere skal forstå hvordan systemet fungerer og hvordan beslutninger tas
- **Feedback-mekanismer** — Brukere skal kunne gi tilbakemelding og oppleve at innspillene påvirker utviklingen
- **Kontinuerlig forbedring** — Tjenester skal itereres basert på faktisk bruk og brukerinnsikt, ikke kun på interne antagelser

### Koblinger til andre prinsipper

Brukerorientering er tett koblet til andre Digdir-arkitekturprinsipper:

- **Prinsipp 2: Ta arkitekturbeslutninger på rett nivå** — Beslutninger skal tas så nært oppgaveløsningen og brukernes behov som mulig
- **Prinsipp 3: Samhandling** — Digital samhandling på tvers av offentlig sektor skal skje ut fra brukernes behov, ikke organisasjonsstruktur
- **Rammeverk for digital samhandling** — Brukerorientering er et gjennomgående tema i Digdirs nasjonale interoperabilitetsrammeverk

## Anvendelse på AI-løsninger

### Brukerinvolvering i AI-utvikling

AI-systemer har en tendens til å bli utviklet som "black boxes" der brukere først møter systemet når det er ferdig trent. Dette bryter med brukerorienteringsprinsippet. For AI-løsninger i offentlig sektor kreves:

**Early-stage research:**
- Forstå brukernes faktiske problemer før du definerer AI som løsning
- Identifiser hvilke brukerbehov AI faktisk kan adressere (og hvilke den ikke kan)
- Kartlegg brukergrupper med ulike funksjonsevner og digitale ferdigheter

**Co-creation og co-design:**
- Inviter brukere til workshops og design sprints der AI-systemets oppførsel diskuteres
- Prototype med low-fidelity mock-ups av AI-interaksjoner før du trener modeller
- Test tidlige versjoner (MVPs) med reelle brukere, ikke kun med tekniske testere

**Kontinuerlig testing og iterasjon:**
- Launch beta-versjoner til et subsett av brukere for å samle inn feedback på AI-genererte svar
- Analyser faktisk bruksmønster (ikke kun tekniske metrics som accuracy)
- Iterer på prompts, grounding-data og UI basert på brukerinnsikt

### Tilgjengelighet (UU) og AI

AI-løsninger må oppfylle kravene i forskrift om universell utforming av IKT-løsninger. Spesifikke hensyn for AI:

**Skjermleser-kompatibilitet:**
- AI-genererte svar må være tilgjengelige for skjermlesere (Narrator, JAWS, NVDA)
- Alt-tekst for AI-genererte bilder må genereres automatisk eller manuelt legges til
- Tabelldata fra AI må struktureres med korrekt markup (headers, data cells)

**Tastaturnavigasjon:**
- AI-chatbots må være fullt navigerbare med tastatur (tab, enter, esc)
- Focus-indikatorer må være tydelige når bruker navigerer mellom AI-svar og input-felt
- Shortcuts som "skip to main content" må fungere i AI-grensesnitt

**Kognitiv tilgjengelighet:**
- AI-svar må være skrevet på et språknivå tilpasset målgruppen (typisk B1-nivå for offentlig sektor)
- Lange AI-svar bør struktureres med headings og lister for lettere skanning
- Brukere med kognitive utfordringer må få mulighet til å be om forenklede svar

**Visuell tilgjengelighet:**
- Kontrast mellom AI-generert tekst og bakgrunn må være minimum 4.5:1 (WCAG AA)
- Fonter bør være lesevennlige (anbefalt: Fluent Sitka Small, Fluent Calibri for dysleksi)
- AI-grensesnitt må fungere med zooming opp til 200 % uten tap av funksjonalitet

### Forståelige AI-beslutninger

**Transparens i AI-svar:**
- Vis brukere hvilke kilder AI-modellen har konsultert (f.eks. top 3 dokumenter i en RAG-løsning)
- Inkluder confidence scores eller usikkerhetsmarkører når modellen er usikker
- Lag logging som sporer hver steg i en multi-agent workflow (men unngå å overvelde brukeren)

**Gradvis disclosure:**
- Bruk minimalt disruptive UI-metoder (tooltips, expandable sections) for å vise teknisk informasjon
- La brukere selv velge hvor mye detalj de ønsker (f.eks. "Vis kilder", "Forklar hvordan dette ble beregnet")
- Ikke krev at brukere forstår tekniske termer som "embeddings" eller "retrieval" for å bruke systemet

**Feedback-loops:**
- Implementer "thumbs up/down" eller lignende mekanismer for hvert AI-svar
- La brukere rapportere problematiske svar (bias, feilinformasjon, upassende tone)
- Sørg for at feedback faktisk påvirker modellen eller grounding-data i neste iterasjon

## Beslutningsveiledning

### Beslutningstabell for AI-prosjekter

| Scenario | Brukerorientert tilnærming | Anti-pattern å unngå |
|----------|----------------------------|----------------------|
| Velge AI-modell | Velg basert på brukerbehov (responstid, språk, domene), ikke kun på teknisk performance | Velge den "beste" modellen på benchmarks uten å teste med reelle brukere |
| Designe chat-grensesnitt | Prototype med brukere før du bygger backend, test med hjelpemiddelteknologi | Bygge et generisk chat-vindu uten tilpasning til brukergruppen |
| Velge grounding-data for RAG | Basert på hvilke spørsmål brukere faktisk stiller, ikke på hvilken data organisasjonen har | Inkludere all tilgjengelig data "for sikkerhets skyld" |
| Håndtere AI-feil | Forklare hva som gikk galt i brukervennlig språk, gi forslag til omformulering | Vise tekniske feilmeldinger ("Error 500: model timeout") |
| Evaluere AI-suksess | Måle brukertilfredshet og oppgavegjennomføring, ikke kun accuracy | Kun rapportere tekniske metrics (F1-score, BLEU) til stakeholders |

### Vanlige feil (og hvordan unngå dem)

❌ **"Vi bygger en AI-løsning først, så tester vi med brukere etterpå"**
✅ Involver brukere i problemdefinisjonen før du bestemmer at AI er løsningen

❌ **"WCAG-compliance er noe vi fikser i slutten av prosjektet"**
✅ Design for tilgjengelighet fra dag 1, test med skjermleser hver sprint

❌ **"Brukere trenger ikke å vite hvordan AI-modellen fungerer"**
✅ Gi transparens om kilder og usikkerhet, men på en måte som ikke overvelder

❌ **"Vi har gjort brukerundersøkelser, så vi vet hva de trenger"**
✅ Brukerinvolvering er kontinuerlig, ikke en engangshendelse i discovery-fasen

❌ **"Bare 44 % av offentlige virksomheter bruker brukerinnsikt til å styre digital strategi"**
✅ Vær i den andre halvparten — gjør brukerinnsikt til en del av beslutningsprosessen

### Røde flagg i AI-prosjekter

- Ingen brukere involvert i de første 3 sprintene
- AI-modellen velges før problemet er fullt forstått
- Ingen testing med hjelpemiddelteknologi (skjermleser, tastaturnavigasjon)
- Stakeholders ber om "en AI-løsning" uten å definere brukerbehov
- Prosjektet måler kun tekniske KPIer (accuracy, latency), ikke brukertilfredshet
- AI-svar gir ikke kilder eller forklaring på hvordan de ble generert

## Eksempler fra norsk offentlig sektor

### StimuLab — Digdirs innovasjonsprogram

StimuLab er Digdirs og DOGAs stimuleringsordning for brukerorientert innovasjon i offentlig sektor. Etablert i 2016, skal programmet bidra til å løse komplekse problemer i stat og kommune gjennom tjenestedesign med brukeren i sentrum.

**Nøkkelprinsipper:**
- Holistisk perspektiv med brukeren i sentrum
- Involvering av innbyggere fra frontlinjen av offentlig innovasjon
- Tverrfaglig samarbeid mellom designere, tjenesteansvarlige og teknologer

**Relevans for AI:** StimuLab-metoden kan anvendes på AI-prosjekter for å sikre at teknologivalg (f.eks. hvilken type modell, hvilken grounding-strategi) er drevet av brukerbehov, ikke av teknologihype.

### "Én digital offentlig sektor" (2019-2025)

Regjeringens og KS sin felles digitaliseringsstrategi legger vekt på:
- Tydelig brukersentrisk tjenesteutvikling
- Sammenhengende tjenester på tvers av forvaltningsnivåer
- Kun 44 % av offentlige virksomheter bruker innsikt om brukerbehov til å styre digital strategi (måltall: øke denne andelen)

**Implikasjon for AI:** AI-løsninger i offentlig sektor må designes for samhandling på tvers av etater, ikke som isolerte chatbots eller interne verktøy.

### Rammeverk for digital samhandling (NIF)

Norges nasjonale interoperabilitetsrammeverk definerer digital samhandling som mer enn et teknisk spørsmål. Brukerorientering er et gjennomgående tema, med krav om at:
- Kommuner, fylkeskommuner og statlige etater skal kunne samarbeide for å utvikle brukerorienterte, sammenhengende og effektive digitale tjenester
- Arbeidet skal skje ut fra brukernes behov, ikke ut fra organisasjonsstruktur

**Relevans for AI:** En RAG-løsning som bruker data fra flere etater må ha authorization-aware retrieval (brukeren får kun se data de har tilgang til), men samtidig oppleves som én helhetlig tjeneste.

## For arkitekten

### Spørsmål å stille kunden

1. **"Hvem er brukerne, og hva er deres faktiske behov?"**
   (Ikke aksepter "alle ansatte" eller "publikum" som svar — be om personas og bruksmønstre)

2. **"Har dere involvert brukere i problemdefinisjonen, eller er AI-løsningen allerede bestemt?"**
   (Rødt flagg hvis AI er løsningen før problemet er forstått)

3. **"Hvordan har dere testet tilgjengelighet (UU) så langt?"**
   (Hvis svaret er "vi skal gjøre det senere", gi en tydelig advarsel)

4. **"Hvilke brukergrupper har spesielle behov (eldre, synshemmede, kognitive utfordringer, ikke-digitale innbyggere)?"**
   (AI-løsninger må fungere for de mest sårbare brukergruppene, ikke kun for tech-savvy brukere)

5. **"Hvordan vil dere måle om AI-løsningen faktisk møter brukernes behov?"**
   (Forvent konkrete KPIer som brukertilfredshet, oppgavegjennomføring, ikke kun accuracy)

6. **"Har dere planlagt for hvordan brukere skal forstå og stole på AI-beslutninger?"**
   (Transparens og forklarbarhet må være en del av design, ikke et "nice-to-have")

7. **"Hvordan vil dere samle inn og agere på brukerfeedback etter lansering?"**
   (AI-systemer krever kontinuerlig iterasjon basert på faktisk bruk)

8. **"Hvordan sikrer dere at AI-løsningen fungerer på tvers av etater (hvis relevant)?"**
   (Sammenhengende tjenester krever planlegging for interoperabilitet, ikke silotekning)

### Fallgruver å unngå

1. **Teknologi-først-tilnærmingen**
   Ikke start med "vi skal bruke Azure OpenAI" — start med "hva prøver brukerne å oppnå?"

2. **"One size fits all"-grensesnitt**
   AI-chatbots som ser identiske ut for alle brukergrupper bryter med brukerorienteringsprinsippet

3. **Manglende tilgjengelighetstesting**
   Testing med hjelpemiddelteknologi må skje hver sprint, ikke kun ved avslutning

4. **Overveldende transparens**
   Ikke dump alle tekniske detaljer på brukeren — bruk gradvis disclosure

5. **Antagelser om digital kompetanse**
   Ikke design kun for brukere som forstår hva "AI" eller "språkmodell" betyr

### Anbefalinger ved arkitekturbeslutninger

**Ved valg av AI-modell:**
- Prioriter norsk språkstøtte hvis brukerne primært skal interagere på norsk
- Velg modeller med lav latency hvis brukere forventer sanntidssvar
- Test med reelle brukere, ikke kun på benchmarks (GPT-4 kan score høyt på MMLU, men gi dårlige svar for din brukerkontekst)

**Ved design av grensesnitt:**
- Bruk Microsoft Human-AI Experiences Design Library som utgangspunkt
- Implementer feedback-mekanismer (thumbs up/down, rapporter problem) fra dag 1
- Sørg for at fokus-indikatorer og tastaturnavigasjon fungerer perfekt

**Ved valg av grounding-strategi (RAG):**
- Basér chunking-strategi på hvordan brukere faktisk stiller spørsmål (f.eks. korte chunks hvis brukere ber om faktasvar, lengre hvis de ber om sammenhenger)
- Implementer authorization-aware retrieval hvis data kommer fra flere etater
- Vis brukerne hvilke kilder som ble brukt (øker tillit)

**Ved evaluering:**
- Mål ikke kun teknisk accuracy — mål brukertilfredshet, oppgavegjennomføring, tillit
- Samle inn kvalitativ feedback (ikke kun kvantitativ) for å forstå hvorfor brukere liker eller misliker svar
- Test med brukergrupper som har spesielle behov (eldre, synshemmede, lavt utdannede)

**Ved deployment:**
- Lanser som MVP til et subsett av brukere, ikke big-bang til alle
- Implementer logging som lar deg spore hver interaksjon (men respekter personvern)
- Ha en plan for hvordan du itererer basert på faktisk bruksdata

## Kilder og verifisering

### Offisielle Digdir-ressurser (Verified via WebSearch 2026-02)

- [Arkitekturprinsippene bidrar til bedre digitale løsninger | Digdir](https://www.digdir.no/krav-og-anbefalinger/arkitekturprinsippene-bidrar-til-bedre-digitale-losninger/3172)
- [Overordnede arkitekturprinsipper | Digdir](https://www.digdir.no/digital-samhandling/overordnede-arkitekturprinsipper/1065)
- [Rammeverk for digital samhandling | Digdir](https://www.digdir.no/digital-samhandling/rammeverk-digital-samhandling/2148)
- [Sammenhengende tjenester med brukeren i sentrum | Digdir](https://www.digdir.no/handlingsplanen/sammenhengende-tjenester-med-brukeren-i-sentrum/1255)

### Tjenestedesign og brukerinvolvering (Verified via WebSearch 2026-02)

- [Design | Digdir](https://www.digdir.no/innovasjon/design/3075)
- [StimuLab: Brukerorientert offentlig innovasjon | Digdir](https://www.digdir.no/stimulab/stimulab-brukerorientert-offentlig-innovasjon-rad-og-erfaringer-fra-frontlinjen/1986)
- [StimuLab – Digdir og DOGA | DOGA](https://doga.no/aktiviteter/design-og-innovasjon/stimulab/dette-er-stimulab/)

### Nasjonal digitaliseringsstrategi (Verified via WebSearch 2026-02)

- [Digitalisering i offentlig sektor | Regjeringen.no](https://www.regjeringen.no/no/dokumenter/digitalisering-i-offentlig-sektor/id2830849/)
- [Én digital offentlig sektor | Regjeringen.no](https://www.regjeringen.no/no/dokumenter/en-digital-offentlig-sektor/id2653874/)
- [Bli kjent med digitaliseringsstrategien | Digdir](https://www.digdir.no/digitalisering-og-samordning/bli-kjent-med-digitaliseringsstrategien/2847)

### Microsoft-kilder for AI og tilgjengelighet (Verified via microsoft_docs_search 2026-02)

- [Design methodology for AI workloads on Azure | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/ai/design-methodology)
- [Application design for AI workloads on Azure | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/ai/application-design)
- [Responsible AI in Azure workloads | Microsoft Learn](https://learn.microsoft.com/en-us/azure/well-architected/ai/responsible-ai)
- [Accessibility information for IT professionals | Microsoft Learn](https://learn.microsoft.com/en-us/windows/configuration/accessibility/)
- [Recommendations for a user-centered design strategy | Microsoft Learn](https://learn.microsoft.com/en-us/power-platform/well-architected/experience-optimization/user-centered-design)
- [Microsoft Human-AI Experiences Design Library](https://www.microsoft.com/en-us/haxtoolkit/library/)

### Baseline (Modellkunnskap)

- WCAG 2.1 Level AA-standarder for digital tilgjengelighet
- Forskrift om universell utforming av IKT-løsninger (Norge)
- Azure Well-Architected Framework AI-prinsipper