Dokumentation og ibrugtagning

Brugervejledning og onboarding: få andre sikkert i gang med appen

En app kan fungere fint for den person, der har bygget den, og stadig være utryg for en ny medarbejder eller kunde. Opgavebaseret hjælp gør det tydeligt, hvornår appen skal bruges, hvad brugeren skal gøre, hvordan et korrekt resultat ser ud, og hvor man får hjælp uden at sende persondata eller adgangsoplysninger rundt i en chat.

Udgivet 5. november 2026 · Ca. 10 minutters læsetid

Det korte svar

Beskriv de vigtigste arbejdsopgaver for hver brugerrolle i stedet for at gennemgå alle menupunkter. Giv nødvendig hjælp dér, hvor opgaven udføres, og lav korte vejledninger til de forløb, der kræver mere forklaring. Hver vejledning skal vise forudsætninger, handlinger, forventet resultat, fejlretning og supportvej. Test den med en person, som ikke har været med til at bygge appen, og giv dokumentationen en ejer samt en fast ændringsudløser, når skærme, regler eller roller ændres.

En vejledning må ikke skjule et dårligt design. Hvis mange brugere misforstår det samme felt eller statusskift, skal appen forbedres. Dokumentationen forklarer den nødvendige arbejdsgang; den er ikke en permanent lappeløsning.

Start med brugerens opgave – ikke appens menu

GOV.UK's Service Manual anbefaler at forstå hele problemet, brugeren forsøger at løse, og ikke kun mødet med systemet. Kortlæg derfor roller og opgaver fra den virkelige arbejdsdag, før I skriver.

Spørgsmål	Eksempel	Dokumentationsbehov
Hvem?	Sagsbehandler, leder eller kunde	Den rolle og adgang, vejledningen gælder for
Hvornår?	Når en ny sag modtages	Tydelig starthændelse og nødvendige oplysninger
Hvad skal lykkes?	Sagen er gemt og tildelt korrekt	Synligt slutresultat, som brugeren kan kontrollere
Hvad kan gå galt?	Forkert kunde, dublet eller manglende rettighed	Sikker fejlretning og grænse for selvhjælp

Prioritér de hyppige og konsekvensrige opgaver. En komplet katalogisering af alle knapper kan hurtigt blive forældet, mens fem gennemprøvede opgavevejledninger kan dække det, en ny bruger faktisk skal kunne i sin første arbejdsuge.

Fordel hjælpen i tre lag

Brugeren bør ikke forlade en enkel formular for at læse en lang manual. Placér den korte forklaring tæt på handlingen, og gem den længere vejledning til opgaver med flere trin, undtagelser eller risici.

I grænsefladen: Tydelige labels, formatkrav før input, præcise knaptekster, status og fejl med et sikkert næste skridt. W3C kræver labels eller instruktioner ved input og tekstlig identifikation af automatisk fundne fejl.
Ved opgaven: En kort, søgbar vejledning til hele forløbet: forudsætninger, trin, kontrol af resultat, kendte afvigelser og recovery.
Ved behov for hjælp: En synlig supportvej med åbningstid, forventet kanal og de oplysninger, support må modtage. Når hjælp findes på flere sider, bør placeringen være ensartet.

Brug en fast skabelon til hver opgave

En ensartet skabelon gør både skrivning og vedligeholdelse lettere. Den kan ligge i appens hjælpecenter, virksomhedens vidensbase eller det dokumentationsværktøj, I allerede bruger.

1. Formål og målgruppe: “Brug denne vejledning, når du som sagsbehandler skal oprette en ny kundesag.”
2. Før du starter: Nødvendig rolle, information, godkendelse og eventuelle afhængigheder.
3. Handlinger: Ét meningsfuldt skridt ad gangen med de samme ord som i appens aktuelle knapper og felter.
4. Forventet resultat: Hvad vises, hvilken status får posten, og hvordan kontrolleres at ændringen er gemt?
5. Fejl og fortrydelse: Hvad kan brugeren selv rette, og hvornår skal personen stoppe for ikke at skabe dubletter eller datatab?
6. Hjælp og ejerskab: Supportkanal, dokumentejer, seneste faglige kontrol og den appversion eller skærmtilstand vejledningen passer til.

Beskriv ikke en omgåelse. Hvis en bruger mangler rettighed, godkendelse eller nødvendig data, er løsningen ikke at dele en administratorkonto, ændre data direkte eller springe kontrollen over. Vis den korrekte eskalationsvej.

Skriv så vejledningen kan følges uden forfatteren

Brug brugerens ord: Skriv “opret sag” frem for et internt udviklernavn, medmindre udviklernavnet også står i grænsefladen.
Giv kontekst før handling: Forklar kort hvem vejledningen gælder for, og hvad brugeren skal have klar. GOV.UK's startmønster anbefaler netop den nødvendige information før start uden at overfylde indgangen.
Vis konsekvensen før risikable valg: Ved sletning, eksport, betaling, adgangsændring eller massehandling skal brugeren kende omfang og mulighed for recovery før bekræftelse.
Skriv fejl som handling: “Vælg en kunde, før du gemmer” hjælper mere end “ugyldigt input”. Fejlteksten skal stadig være sand og må ikke afsløre interne detaljer eller andre brugeres data.
Hold alternative forløb adskilt: Hvis leder og medarbejder ser forskellige skærme, så marker forskellen tydeligt eller skriv separate korte vejledninger.

Brug billeder og video uden at skabe nye risici

Et skærmbillede kan gøre placeringen tydelig, men det er ofte det første, der bliver forældet. Teksten skal derfor stadig kunne forklare opgaven, og eksemplet skal være sikkert at dele med hele vejledningens målgruppe.

Brug syntetiske navne, adresser, ordrenumre og dokumenter frem for kopier fra produktion.
Kontrollér hele billedet og videoen for persondata, tokens, browserfaner, notifikationer, interne URL'er og andre kunders oplysninger.
Beskær til det relevante område, men bevar nok kontekst til at brugeren kan finde stedet i appen.
Tilføj tekst, der forklarer billedets formål, og undgå instruktioner som kun siger “klik på den grønne knap” eller kun kan forstås visuelt.
Gem kildefil, ejer og opdateringsudløser. En video på ti minutter er dyr at rette, hvis én knap ændrer navn.

Test onboarding som en rigtig arbejdsopgave

Den bedste kontrol er ikke, om forfatteren kan forklare appen, men om en repræsentativ bruger kan gennemføre opgaven med den adgang, enhed og information, der findes i hverdagen. GOV.UK anbefaler løbende brugertest af hele den oplevelse, brugeren møder.

Vælg et konkret resultat. Eksempelvis opret, find, ret og afslut én sag med kontrollerede testdata.
Giv kun normal startinformation. Lad vejledningen og appen bære opgaven; notér hvor testpersonen spørger, gætter eller går i stå.
Kontrollér sluttilstanden. Se både skærmbillede, gemte data, rolle, status og eventuelle beskeder eller integrationer.
Ret det rigtige sted. Forbedr appen, når problemet er et uklart felt eller manglende feedback. Ret vejledningen, når et nødvendigt trin eller en undtagelse mangler.
Gentag med en ny person. En rettelse er først bevist, når en bruger uden ekstra forklaring kan gennemføre forløbet.

Knyt dokumentationen til ændringer i appen

Dokumentation bliver upålidelig, hvis den kun har en kalenderpåmindelse. Gør den til en del af den ændringsproces, der allerede bruges til kode og konfiguration.

Tilføj “påvirker brugerhjælp eller oplæring?” til releasegrundlaget eller pull request-skabelonen.
Opdatér vejledningen i samme release, når navne, roller, regler, datafelter eller fejlforløb ændres.
Bevar én godkendt placering pr. vejledning, og link dertil fra appen; undgå ukontrollerede kopier i mails og lokale dokumenter.
Brug supporthenvendelser, søgninger uden resultat og fejl i brugeraccepttest som konkrete signaler om manglende eller uklar hjælp.
Arkivér eller omdirigér forældede vejledninger tydeligt, så gamle bogmærker ikke leder til en farlig arbejdsgang.

Typiske fejl

Manualen følger menuen: Brugeren skal selv oversætte funktioner til den opgave, der skal løses.
Onboarding er en udviklerdemo: Alt ser let ud, fordi den erfarne person styrer musen og forklarer undtagelserne mundtligt.
Skærmbilleder er facit: Teksten mangler, billedet kan ikke bruges af alle, og næste mindre redesign gør vejledningen forkert.
Produktionsdata bruges som eksempel: Persondata eller fortrolige oplysninger ender i dokumenter med bredere adgang end appen.
Kun den normale vej er beskrevet: Brugeren ved ikke, om en timeout, dublet eller uventet status skal prøves igen eller eskaleres.
Ingen ejer vejledningen: Appen ændrer sig, mens den gamle instruktion fortsat ligger øverst i søgningen.

Tjekliste før andre skal bruge appen

☐ De vigtigste opgaver er valgt ud fra virkelige roller og arbejdssituationer.
☐ Hver vejledning har målgruppe, starthændelse, forudsætninger og forventet slutresultat.
☐ Knapper, felter og statusser kaldes det samme i vejledning og app.
☐ Labels, inputkrav, status og fejl giver nødvendig hjælp direkte i grænsefladen.
☐ Fejlretning forklarer, hvad brugeren sikkert kan gøre, og hvornår personen skal stoppe.
☐ Eksempler, billeder og video er fri for rigtige persondata, secrets og andre kunders oplysninger.
☐ Hjælp og support kan findes ensartet, og brugeren ved, hvilke oplysninger der må deles.
☐ En repræsentativ ny bruger har gennemført opgaven med korrekt rolle, enhed og sikre testdata.
☐ Hver vejledning har ejer, godkendt placering og en udløser ved relevante appændringer.
☐ Releaseprocessen kontrollerer, om brugerhjælp, onboarding eller kendte begrænsninger skal opdateres.

Relaterede guides

Brugeraccepttest af de virkelige arbejdsprocesser Pilotdrift med en afgrænset brugergruppe Supportproces og sikker fejlrapportering Teknisk driftsdokumentation og overdragelse

Officielle kilder

Vælg format og omfang efter appens brugere, opgaver og risiko. Kilderne nedenfor underbygger principperne om brugerbehov, brugertest, startinformation, inputhjælp, tekstlige fejl og ensartet adgang til hjælp.

Virker appen, men lever oplæringen stadig i dit hoved?

I Startklar kan vi gennemgå de kritiske brugerrejser, gøre hjælpen sikker og opgavebaseret og forbinde dokumentationen med test, support og appens ændringer.

Se Startklar-forløbet