– For både forretning og brugere

I dette hæfte beskriver vi, hvordan man kan introducere brugerinddragelse generelt i store offentlige it-projekter. Beskrivelserne er til dig der arbejder med (eller vil arbejde med) brugerinddragelse og/eller er ansvarlig for projektplanlægning. For at sikre gode brugeroplevelser, er det nemlig helt afgørende, at din rolle tænkes ind fra start når hegnspælene for et it-udviklingsprojekt fastsættes.

Det er vores erfaring, at mange større it-projekter, som baseres på ønsket teknologi frem for analyse af reelle behov, ofte overskrider både tidsplaner og budgetter. Sundhedsplatformen og de første udgaver af Rejsekortet er begge eksempler på dette, ligesom begge har været PR-mæssige skandaler.

1. at skabe grundlaget for at kunne skabe værdi i projektets levetid
2. at den implementerede løsning skaber værdi i den efterfølgende brug.

Begge dele opnås kun, hvis man fra idé til realisering holder sig de reelle behov for øje. Vi ved – både gennem egne erfaringer og større forskningsprojekter – at en væsentlig bidragende faktor til at implementere værdiskabende løsninger er, at løsningerne skal understøtte de opgaver, brugeren skal udføre.

Vi får kun denne understøttelse ved at have stillet klare krav til løsningen. Ikke blot til den forventede funktionalitet (hvad løsningen skal kunne), men også til den nødvendige anvendelse og oplevelse af løsningen (hvordan funktionaliteten kommer i brug).

Disse krav skal derfor være baseret på de af brugernes behov, der skal opfyldes for at kunne nå projektets formål og organisationens mål. Vi oplever, at netop dette fokus på brugerne og deres behov kommer alt for sent i offentlige it-projekter – og når punkt 1 ovenfor ikke er opfyldt, bliver det nærmest umuligt at få opfyldt punkt 2.

Der er mange grunde til problemer i store projekter, og én af dem er ofte at man fra en styregruppe eller projektledelses side ikke har et tilstrækkeligt fokus på hvad brugerne reelt ønsker, eller forstår hvilke afledte gevinster, man kan høste ved at tilbyde et system, der både rammer den ønskede funktionalitet samt en passende brugergrænseflade. Eksempler på afledte gevinster er færre ressourcer til oplæring / mandskab til support, eller en mindre mængde funktionalitet (og dermed billigere løsning) end leverandøren foreslår.

Målet med hæftet er at give dig en praktisk indgang til at navigere i de forskellige faser af offentlige it-projekter.

En forudsætning for at gennemføre anskaffelser over et vist budget i det offentlige er, at man anvender et styringsgrundlag eller Statens it-projektmodel.

At arbejde som “UX ambassadør” i Statens it-projektmodel medfører, at man skal navigere i komplekse rammer for at sikre en god brugeroplevelse. Modellen laver mange benspænd for brugerinddragelse, men vi håber med dette hæfte at gøre det lidt nemmere at inddrage brugerne i alle fire faser.

Optimalt set skal der være et formaliseret samarbejde mellem Seniorbrugeren i styregruppen, forretningsanalytikere, projektledere og UX-folk, for at der kan være fokus på brugerinvolvering gennem hele projektets udstrækning. Det er dog vores erfaring, at der sjældent er udpeget en eneste ansvarlig, der kan agere som “UX ambassadør” i projektet.

Ved at tænke brugerperspektivet ind fra starten i anvendelsen af Statens it-projektmodel – og kombinere den med anbefalinger i Double Diamond og ISO 9241-210 – undgår man de værste faldgruber og opnår de bedste betingelser for at skabe reel værdi for både brugere, borgere og organisation.

For at illustrere vores pointer vil vi referere til et fiktivt, men realistisk projekt, hvor en organisation skal anskaffe et system til overvågning af skinners tilstand på et jernbanenet. Relevante brugere skal kunne samle og analysere data om tilstanden på skinnerne fra en central placering. På nuværende tidspunkt foretages overvågningen af skinner ved hjælp af særlige måletog med sensorer, og det primære formål med projektet er at anskaffe en fleksibel løsning, der i så lav grad som muligt påvirker kørslen på jernbanenettet.

De forventede gevinster for organisationen er økonomiske, da man forventer at kunne erstatte de nuværende processer med mere effektive arbejdsgange.

Organisationen kender allerede til flere standardsystemer, der generelt kan gøre de nuværende opgaver nemmere for personalet.

I dette hæfte antages derfor, at projektet forventes at ende med et standardsystem som løsning.

Organisationen har en forventning om, at en form for AI-teknologi kan hjælpe med overvågningen og den efterfølgende analyse, men ikke en klar idé om hvordan.

Et statsligt it-projekt har typisk tre niveauer af beslutningskraft:

1. Styregruppen sætter de overordnede rammer, godkender faser og fokuserer på fire faktorer: økonomi, gevinster, risici og fremdrift. Et almindeligt styregruppemedlem vil som udgangspunkt ikke være interesseret i gode brugeroplevelser – kun i den udstrækning, de kan påvirke de fire faktorer. Dog kan en Seniorbruger i styregruppen have et formelt ansvar for at sikre brugeroplevelsen – hvis rollen tages med, når styregruppen bliver nedsat. Vi oplever ikke dette som en standard.
2. Projektlederen planlægger og styrer projektet efter styregruppens retningslinjer, bemander holdet og rapporterer fremdrift. Det er altså projektlederen der kan udforme eller videreformidle materiale omkring gevinsterne ved brugerinddragelse, og risici ved at undlade brugerinddragelse, som styregruppen kan tage stilling til, og som den kan acceptere som en del af projektets udformning og plan.
   
   
3. Projektgruppen består af specialister som udarbejder konkrete leverancer. De forskellige leverancer i projektet, for eksempel kravspecifikationer, arkitekturtegninger, testplaner og meget andet, udarbejdes her af specialister som testere, løsningsarkitekter, forretningsanalytikere, designere, sikkerhedsspecialister m.fl. I projektgruppen sidder den udførende ansvarlige for brugerinddragelse, med opgaven at indhente ønsker og behov fra brugerne. Disse skal senere omformuleres til krav, der kan bruges i en formel kravspecifikation – alt sammen inden for de overordnede rammer udstukket af styregruppen.

Statens it-projektmodel fastlægger en række regler og betingelser for arbejde i hver af disse niveauer. Yderligere informationer om disse regler kan findes i Økonomistyrelsens vejledning til modellen.

Derudover vil vi anbefale, at der i hvert af de tre niveauer er fokus på brugerinddragelse, enten ved at en UX ambassadør er til stede i de tre grupper. Alternativt kan en UX ambassadør klæde beslutningstagerne på til bevidst at tage stilling til graden af brugerinddragelse i it-projektet.

Offentlige it-projekter med et budget over en vis grænse skal bruge Statens it-projektmodel. Modellen er ejet af Økonomistyrelsen og fungerer som en projektledelsesmodel – ikke en egentlig udviklingsmodel. Den fortæller altså ikke, hvordan systemet skal designes, eller hvilke specialister man har brug for, men hvordan man leder projektet igennem fire faser:

1. Idéfasen
2. Analysefasen
3. Gennemførelsesfasen
4. Realiseringsfasen.

Som UX ambassadør – altså ansvarlig for den gode brugeroplevelse – kan det være en fordel at kende modellen og dens dokumenter, for det er her, man kan forankre vigtigheden af at inddrage brugere. Modellen fokuserer mest på gevinster, risici, fremdrift og økonomi, så man skal aktivt gøre opmærksom på brugeroplevelser.

Fokus i idéfasen er at udarbejde et beslutningsgrundlag for, om projektet skal prioriteres i forhold til andre projekter i organisationen. Man beskriver projektets idé inkl. det egentlige formål. Fokus er på de overordnede gevinster, risici, tidsplan og økonomi – men ikke selve løsningsdesignet i detaljer.

• Tidlig projektbeskrivelse (idé, formodede gevinster, risici,
  økonomi mv.) Her kan UX ambassadøren spille ind med
  brugerinvolvering som en gevinst (sparet tid til oplæring af
  personale, da det nye system passer til optimale arbejdsgange)
  eller til risikominimering (mindre risiko for dårlig datakvalitet, da
  det nye system kan have en højere grad af validering)
• Beskrivelse af den overordnede anskaffelse her kan UX
  ambassadøren forsøge at få beskrivelsen til at indeholde
  referencer til de brugere, der skal anvende den nye løsning (“Et
  system, der sætter personalet til vedligeholdelse af
  jernbanenettet i stand til at overvåge status på skinnerne på en
  måde, der kræver mindst mulig oplæring.”)
• Argumentation for relevans i forhold til organisationens mål.
  Hvis disse kan vinkles i forhold til effektivitet, brugertilfredshed
  eller understøttelse af konkrete opgaver, vil UX ambassadøren
  kunne hjælpe med at omsætte det til konkrete, målbare
  gevinster (“Nemmere mulighed for administration og analyse af
  data af høj kvalitet kan give besparelser i driften”). Disse kan
  danne basis for den business case, der skal udarbejdes – og ofte
  påbegyndes her i idéfasen.
• Mulige risici Herunder risici relateret til manglende
  brugerinvolvering. “For at mindske risikoen for en mangelfuld
  implementering af systemets forventede funktionalitet, er det
  vigtigt at tage slutbrugernes ønsker og behov i betragtning ved
  udformning af det endelige system.”

Når beslutningstagerne har vurderet materialet, afgør de, om projektet
skal fortsætte til Analysefasen, hvor projektgruppen nedsættes.

De involverede parter er:

• Projektejer (har idéen til projektet)
• Projektleder (kender til formalia og skabeloner i denne fase)
• Beslutningstagere (ofte et ledelses- eller styregruppelag), der vurderer, om projektet skal videreføres.

UX’eren eller forretningsanalytikeren kan være perifer eller helt fraværende (bliver ofte ikke formelt indraget i denne fase, men bør forsøge at påvirke såvel projektleder som projektejer, hvis de får kendskab til projektet).

Alle kan som nævnt optræde som UX ambassadør.

Fokus i analysefasen er at udarbejde et detaljeret projektgrundlag, som gør det klart for styregruppen, hvordan projektet bedst gennemføres og hvilke forretnings- og brugerbehov, der skal opfyldes af it-løsningen. Her afdækkes bl.a. scope, planer og ressourcer, så styregruppen kan beslutte, om projektet skal fortsætte til gennemførelsesfasen.

• Kommissorium (spilleregler for styregruppens samarbejde og roller, inkl. fokus på brugerne). Beskrivelsen af seniorbrugerrollen kan udspecificere, at denne rolle skal sikre et fokus på brugerne, og at resten af projektet skal bevise over for hende, at der tilrettelægges opgaver, der kan sikre at gevinster nås og at risici minimeres.
  
  
• Opdateret projektgrundlag og Business Case (uddybet scope, økonomi, tidsplan, risikobillede, ressourcer m.m.). UX ambassadøren bør kobles på i Analysefasen, og kan nu begynde at udforske hvilken funktionalitet systemet skal stille til rådighed. UX ambassadørens bidrag kan være tidlige prototyper til afdækning af behov, brugergruppebeskrivelser og brugsscenarier – samt risici ved at undlade at inddrage brugerne i projektet. Er målet for projektet højere effektivitet (i skinneinspektion), så kan en risiko være at analysetiden forøges med 25%, hvis operatørerne ikke forstår at anvende systemet.
  
  
• Eventuelle behov og ønsker fra såvel projektejer, organisation og brugere i forhold til det endelige system (fx funktionalitet, brugergrænseflade, platform). For at kunne beskrive den funktionalitet der skal tilbydes, skal UX ambassadøren sætte sig ind i forventede arbejdsgange, viden hos slutbrugerne, forventninger til platform (fx app/PC), brugergrænseflade og meget andet. Det er op til den enkelte UX ambassadør i projektet, hvordan dette skal udføres. Planen for brugerinvolvering skal formidles til projektlederen, så den kan indgå i den samlede projektplan.

De involverede parter er:

• Styregruppe (seniorleverandør, seniorbruger, styregruppeformand)
• Seniorbruger/Gevinstejer
• Projektleder
• Specialister (herunder UX’ere, forretningsanalytikere, arkitekter osv.).

Også her kan alle optræde som UX ambassadør.

I analysefasen tager UX ambassadøren et stort skridt frem mod specificering af, hvad det endelige system skal kunne. I tilfældet
med skinneovervågningssystemet, kan resultatet af UX ambassadørens arbejde være med til at afklare:

• Brugergrupper
• Miljø
• Ressourcer
• Forventninger
• Behov
• Opgaver/aktiviteter

Da det specifikke projekt med skinneovervågning har som mål at indkøbe et standardsystem, skal UX ambassadøren huske, at det ikke handler om at designe et system, men at skabe grundlaget for fastlæggelse af de krav, som en leverandør skal leve op til i et senere udbud. Det er muligt at bruge prototyping, skitser og tilsvarende til afklare behov, men ved standardsystemer er det leverandørens design man ender med at købe, og derfor skal evaluere.

Behovsafdækningen kan derfor fx give anledning til følgende observationer:

• At brugerne vil foretrække en løsning med droner, der flyver
  langs skinnerne, og melder data ind i forhold til nogle fastsatte
  parametre om slid, rust, med videre.
• At dronerne bliver sat i gang af operatører, som kører ud til den
  relevante strækning, sætter dronen i gang, og overvåger dens
  fremdrift.
• At brugerne foretrækker en løsning med både en app med
  begrænset funktionalitet til operatøren, samt et system til PC,
  med den fulde funktionalitet, fx dybdegående analyse af data.
• At alle typer af brugere kommer til at arbejde med systemet som
  en bærende del af deres arbejdsdag, og at man derfor kan tillade
  sig at se dem som Ekspertbrugere.
• At systemet skal kunne bruges til planlægning af eftersyn på
  strækninger.
• At systemet skal kunne alarmere brugerne, hvis fx brud i
  skinnerne overskrider en fastsat tærskel (som brugerne selv
  konfigurerer).

I analysefasen kan UX ambassadøren vælge at formulere disse behov og ønsker i et format som for eksempel lister (som ovenfor), scenarier,
processer, user stories på epic niveau, der omsættes til egentlige krav – eller kan bruges direkte – i en kravspecifikation.

Når analysefasen er gennemført, har styregruppen et klart billede af, hvordan projektet kan gennemføres og beslutter, om det skal videre til
gennemførelsesfasen.

Typisk den længste fase, hvor kravspecificering, udbud og udvikling af det endelige system finder sted. Organisationen udarbejder et formelt kravmateriale, offentliggør det og indhenter tilbud fra leverandører. Der gennemføres evt. forhandling, kontraktunderskrivelse, efterfølgende udvikling og test.

De involverede parter er:

• Styregruppen: Sikrer overordnet fremdrift, godkender leverancer og ændringer.
• Seniorbruger/Gevinstejer (i styregruppen) skal sikre, at brugernes perspektiv bliver prioriteret
• Projektlederen: Koordinerer udarbejdelsen af kravspecifikationer, udbudsprocessen, tidsplaner, tests og
  dialog med leverandøren.
  • Potentielt en Product Owner-rolle på organisationssiden, for at sikre at forretningens og brugernes behov tilgodeses.
• Specialister (inkl. UX, jura, tekniske eksperter): Udarbejder og evaluerer krav, deltager i test og kvalitetssikring.
• Leverandør: Præsenterer tilbud, deltager i forhandling, udvikler og tester systemet i samarbejde med projektgruppen. Kan have
  egen UX’er.

Ofte er det først her, rollen som UX ambassadør formelt besættes med en forretningsanalytiker, UX’er eller anden med relateret jobtitel. Har projektet ikke haft brugerinddragelse for øje i de tidligere faser, vil mulighederne for UX ambassadørens arbejde være for begrænsede, og indsigter vil komme for sent til at kunne håndteres uden fordyrende ændringsanmodninger.

Udbuds- og tilbudsproces

• Kravspecifikation offentliggøres
• Leverandører afgiver tilbud
• Organisationen evaluerer tilbud ift. de opstillede kriterier og evalueringsmodel
• Hvis udbudsformen er udbud med forhandling kan leverandøren skulle afgive flere versioner af tilbuddet – så der evalueres af flere omgang.

Tildeling

• Kontrakt underskrives, hvorefter en afklaringsfase sikrer fælles forståelse af kravene

Udvikling og test

• Udvikling / konfigurering af standardsystem i samarbejde med leverandøren for at opfylde kravene i kravspecifikation og bilag
• Løbende tests (tekniske og brugermæssige) op mod definerede krav og acceptkriterier (samt evt. kontraktuelle krav)

Implementering og udrulning

• Systemet implementeres i organisationen, og projektet gør klar til realiseringsfasen
• Brugerne uddannes i anvendelse af systemet

Udbudsbetingelser

Især i forbindelse med konstruktionen af udbuddets evalueringsmodel kan der sikres fokus på brugerinddragelse. Hyppigt vægtes prisen højere end kvalitet og tid. Ved at vægte kvalitet højest, kan fokus skiftes til brugervenlighed og anvendelighed generelt. Når man beskriver sin evalueringsmodel, vil hver af de tre faktorer skulle foldes yderligere ud.

Ved fokus på kvalitet.er det muligt at inkludere test af standardløsningen med brugere som en faktor i evalueringen (“Proof of Concept”). Det er desuden muligt at teste undervejs, når leverandørerne vender tilbage med tilrettede udgaver af deres standardsystem for hver iteration i forhandlingsrunderne.

Det er også her der kan stilles krav til, hvilke kompetencer leverandøren skal stille med. Man kan fx bede om, at leverandøren stiller med en senior UXer, og at de skal være skolet i bestemt metode eller standard, ligesom når man beskriver typen af projektleder og udviklingsmetode, man ønsker i projektet.

Kontrakt

Til offentlige indkøb findes flere standardkontrakter, der hver er målrettet en specifik type ydelse – fx varekøb, drift eller udvikling.

Økonomistyrelsens K02-skabelon anvendes ofte som grundlag for kontrakten, når it-projekter inkluderer udvikling og drift. Skabelonen indeholder en række bilag, hvor man især som UX ambassadør i de herunder nævnte bilag kan tilføje et fokus på brugerinddragelse

Detaljeret tidsplan (Bilag 1B)

Detaljeret tidsplan for specifikke opgaver og delprojekter.

Her kan fokus på brugervenlighed beskrives i form af fastlagte brugervenlighedstests og tilgængelighedstests under udvikling / konfiguration af standardsystemet Tidsplanen kan også indeholde en beskrivelse af hvilken udviklingsmodel, der skal anvendes, samt af ønsket bemanding hos leverandøren; eksempelvis at en UX’er/BA’er skal være tilknyttet i hele udviklingsfasen (på linje med en projektleder) – omend ikke nødvendigvis fuld tid i hele perioden.

Kravspecifikation (Bilag 3A)

Funktionelle og ikke-funktionelle krav til de it-løsninger, der skal leveres (kan have yderligere underbilag fx scenarier, informationsmodel mv.) Her kan brugervenlighed beskrives i kontekstbeskrivelser + deciderede krav/acceptkriterier samt generelle kvalitetskrav (effektivitet, fejlhåndtering, læringskurve
m.m.)

Foruden de specifikke krav, skal man også angive kravtypen. Typisk:

• Mindstekrav: Skal opfyldes
• (Forhandlings)krav: Kan opfyldes – evt. med mindre tilpasninger, i løbet af forhandlingsrunderne
• Evalueringskrav: Her kan leverandøren få “point” for hvor godt kravet opfyldes ift. de parametre, der evalueres på.

Især den sidste type krav giver anledning til at bringe brugervenlighed i spil. I referenceprojektet kan et evalueringskrav være, at leverandøren skal redegøre for, hvilken brugeroplevelse opfyldelsen af et specifikke krav giver for specifikke brugergrupper Det kan tælle op, at den er baseret på AI – det kan også tælle op, at den er nem for et specifikt antal brugere at anvende.

Brugsscenarier (Bilag 3D)

Beskrivelse af as-is og to-be i det omfang, det er muligt. Her kan den forventede brug af systemet beskrives i scenariebeskrivelser, procestegninger, prototyper og skitser (af varierende detaljeringsgrad)

Bruger- og systemdokumentation (Bilag 4A)

Her kan fokus på brugervenlighed beskrives i krav til den ønskede brugerdokumentation og undervisningsmateriale.

Vedligeholdelse og support (Bilag 5)

Her begynder projektet at forholde sig til, hvordan den senere forvaltning og drift skal fungere efter idriftsætningen. Også her kan det være nødvendigt at sikre den fortsatte brugerinddragelse: Hvad skal processen fx være i forbindelse med efterfølgende forbedringer af systemet? Her bør en UX ambassadør sikre at processen inkluderer at ændringer og forbedringer fortsat baseres på reelle brugerbehov – og at de brugervenlighedstestes inden den næste release.
Kravene kan sagtens være magen til dem i bilag 9 om ændringshåndtering i forbindelse med udvikling, men de skal altså specificeres i begge bilag.

Ændringshåndtering (Bilag 9)

Procedurer for håndtering af ændringer i krav der skal opfyldes af standardsystemet. Her kan fokus på brugervenlighed beskrives i form af krav til behovsafdækning, brugervenlighedstests samt tilgængelighedstests af ændringerne.

Samarbejdsorganisation (Bilag 10)

I dette bilag beskrives den ønskede udviklingsmodel, de faste møder og de forskellige roller, der forventes udfyldt af såvel kunde som leverandør.

Leverandørens opgave er naturligvis at tjene mest muligt på projektet – og kundens at få mest muligt for pengene – det kan give nogle gnidninger, hvis ikke begge parter er indstillet på at levere den bedst mulige kvalitet ved projektets afslutning. Den reelle oplevelse af samarbejdet kan betyde, at modellen eller de faste møder skal justeres undervejs.

Kun meget sjældent ses krav om UX ressourcer eller beskrivelser af deres rolle i projektet. Der bør dog her beskrives, hvilke UX ressourcer kunden forventer at bidrage med, samt stilles krav om at leverandøren byder ind med en tilsvarende ressource.

Prøver (Bilag 14)

Overordnet strategi for test af leverancer. Kriterier for godkendelse af tests og leverancer Her skal man evt. have særlige kriterier for godkendelse af brugervenlighed.

Typisk skelnes generelt mellem:

• Kritisk fejl (kategori 1),
• Stor fejl (kategori 2),
• Mindre fejl (kategori 3) og
• Kosmetisk fejl (kategori 4).

Antallet af fejl i hver kategori kan være blokerende for idriftsætningen – fx kan der i kontrakten stå, at der ikke må være kategori 1-fejl, mens vi kan gå i drift med 5 kategori 2- fejl, 20 kategori 3-fejl og 50 kategori 4-fejl.

Brugervenlighedsudfordringer karakteriseres ofte som kategori 3 eller 4, hvilket sjældent standser/udskyder idriftsætningen. UX ambassadøren bør derfor få indføjet, at et vist antal kategori 4-fejl tæller som én kategori 3-fejl; og et vist antal kategori 3-fejl tæller som én kategori 2-fejl.

Testplan (Bilag 14A)

Detaljeret plan for gennemførelse af tests.

I dette bilag kan UX-ambassadøren sætte fokus på brugervenlighed ved at lave detaljerede beskrivelser af hvilke typer af brugervenlighedstests, der skal udføres på de tidspunkter, der er angivet i bilag 1B. Dette inkluderer også tilgængelighedstests.

UX’erens rolle og påvirkningsmuligheder

• Specificering af brugerkrav i kravspecifikationen (scenarier, user stories, acceptkriterier).
• Bidrage til evalueringen af leverandørtilbud: Sikre, at løsningerne imødekommer brugernes behov samt lever op til kriterierne i evalueringsmodellen
• Deltage i tests før og efter kontraktunderskrivelse (Proof of Concept, prototyper, brugertest).
• Løbende samarbejde med projektleder og styregruppe:
  • Sikre, at brugerorienterede leverancer godkendes og indgår i projektets milepæle.
  • Påpege risici ved utilstrækkelig brugervenlighed, så styregruppen kan træffe informerede beslutninger.
• Støtte implementering og træning: Udarbejde eller bidrage til vejledninger, undervisningsmaterialer og eventuelt supportmateriale for slutbrugerne. Indsigter fra undervisningen skal føres tilbage til projektgruppen.

Når gennemførelsesfasen er afsluttet, overgår projektet til realiseringsfasen, hvor fokus ligger på drift, gevinstrealisering og efterfølgende vurdering af systemets succes.

Systemet er officielt færdigudviklet og overgår til drift. Projektgruppen nedlægges, men styregruppen bør bestå og følge op på gevinstrealiseringen. Driftsorganisationens fokus bør – særligt i begyndelsen af denne fase – være på ændringer og opdateringer baseret på tidlig brugerfeedback. Selvom det ofte nedprioriteres, kan det derfor være en fordel at have en UX’er tilknyttet efter overdragelsen til drift.

De involverede parter er:

• Styregruppen/gevinstejer: Overvåger, om de forventede gevinstmål opnås, og beslutter evt. større ændringer.
• Driftsorganisationen: Har ansvaret for forvaltning af systemet, herunder håndtering af fejl og forslag til forbedringer.
• Leverandør: Modtager ændringsønsker fra driftsorganisationen, foretager udvikling og vedligehold.
• Slutbrugere: Indrapporterer problemer eller ønsker til forbedringer.

Igen opstår behovet for en UX ambassadør, da den UX-ressource, der var tilknyttet under gennemførelsesfasen, ofte flyttes til andet arbejde – og da der sjældent er specialiserede UX-ressourcer i driftsorganisationen.

Hvis organisationen ønsker at føre projektets fokus på brugeroplevelsen med ind i driften, kan følgende leverancer være et
udgangspunkt:

• Proces for modtagelse af input fra brugerne. Det er vigtigt at driftsorganisationen har opbygget en proces for hvordan de forskellige tilbagemeldinger om brug af systemet modtages, evalueres og specificeres som ændringsønsker til leverandøren.
  Alle tilbagemeldinger fra brugerne skal tages i betragtning, når systemet skal opdateres, og skal evalueres ud fra en betragtning om at brugervenlighed kan være grundlaget for fejl i brug af løsningen, opkald til support mv.
• Proces for ændringshåndtering: Hvordan driftsorganisationen melder ønsker ind til leverandøren, og hvorledes leverandøren tager imod og prissætter. Det er særligt vigtigt at sikre, at leverandøren forstår værdien af de inputs, brugerne giver, og forstår at disse inputs viser den reelle brug og værdi af systemet.
• Afklaring af formalia omkring test af forslag til opdatering. Det er optimalt, hvis leverandøren også efter idriftsætning stiller et testmiljø til rådighed for organisationen, og viser forståelse for at forslag til opdateringer af systemet skal testes med egentlige slutbrugere før de implementeres.
  Formalia kan fx indeholde: Fastlæggelse af ansvaret for afvikling af disse tests, sikring af fælles forståelse for resultatet af tests, metoder til afvikling af tests, afklaringer af forståelse af brugeroplevelse, evt. aflønning af deltagere og meget andet.

UX ambassadørens rolle og påvirkningsmuligheder

• Overvåge brugeroplevelse i drift: Indsamling af feedback, udførelse af test og evaluering af nye ændringer.
• Prioritere og specificere ændringsønsker: Sikre, at brugerinvolvering tages alvorligt i driftsorganisationen.
• Samarbejde med leverandøren: At være bindeled mellem forretning og leverandør ved vurdering af, om ændringsforslag opfylder det kravstillede niveau til brugervenlighed i den originale leverance.
• Vedligeholde dokumentation og proces for fortsat UX-arbejde: Hjælpe driftsorganisationen med at opretholde fokus på brugernes
  behov gennem hele systemets levetid.

I denne artikel har vi beskrevet, hvordan en UX ambassadør effektivt kan integrere brugerinddragelse i offentlige ITanskaffelsesprojekter. Forfatterne har erfaret, at tidlig og kontinuerlig inddragelse af slutbrugere ikke kun forbedrer projektets slutresultater, men også øger tilfredsheden og accepten af det endelige system blandt brugerne. Disse metoder og tilgange understøtter en mere brugervenlig udvikling, der er i overensstemmelse med både Double Diamond-principper og ISO 9241-210 standarder, selv inden for de rammer, statens it-projektmodel fastlægger.

Så derfor, tøv ikke med at tage skridtet videre: Kontakt din projektejer i dag. Det er tid til at omsætte princippet om “bedre brugervenlighed” til håndgribelige fordele, som din styregruppe ikke kan ignorere. Når du præsenterer din sag for styregruppen, skal du klart fremhæve, hvordan brugerinddragelse direkte påvirker projektets succes:

1. Økonomi: Forklar hvordan brugerinddragelse kan reducere omkostningerne ved indkøb af et standardsystem, der kan for meget. Ofte kan man nøjes med mindre funktionalitet end leverandørerne af standardsystemer vil sælge. En god afklaring kan også mindske behov for senere ændringer og fejlrettelser, hvilket sparer væsentlige ressourcer – det er nemlig altid dyrere at rette kørende systemer.
2. Gevinster: Demonstrér potentialet for øget anvendelighed og dermed højere adoption og brug, hvilket fører til hurtigere realisering af projektmålene. Et brugervenligt system vil også kunne forkorte træning i systemet, og mindske antallet af supportopkald.
3. Risici: Påvis hvordan tidlig og kontinuerlig brugerinddragelse minimerer risikoen for modstand i modtagerorganisationen, fejlslutninger i projektet, og sikrer compliance med brugerbehov og -krav.
4. Fremdrift: Argumentér for, at brugerinddragelse ikke nødvendigvis forlænger projektets tidsplan, men snarere optimerer udviklingsprocessen ved at fokusere indsatsen der, hvor den giver størst værdi fra starten. Færre ændringer giver hurtigere projektafslutning.

Brug data, brugerfeedback og konkrete eksempler til at underbygge dine pointer og vise, at inddragelse af slutbrugere fra projektets start ikke kun er en strategisk fordel, men en nødvendighed for at opnå en succesfuld implementering.

Find mere viden

• Lyt til IT-Udviklingsrejsen, hvor konklusionerne fra et forskningsprojekt på KEA vedrørende udfordringer og løsningsforslag ved offentlige it-anskaffelser
• Læs mere om den tilgang, der anbefales i ISO 9241-210, på UXQB.org
• Find værktøjer til at skabe gode brugeroplevelser i det offentlige på digst.dk/digital-inklusion/brugeroplevelse
• Læs mere på trustworks.dk/vaerdiskabende-udbud og peytz.dk/vaerdiskabende-udbud