Oplægget blev holdt ved arrangementet "Fra borger til bruger" afholdt den 13. november 2012. Læs mere om arrangementet på http://www.infinit.dk/dk/hvad_kan_vi_goere_for_dig/viden/reportager/den_digitale_kommune.htm

1. Usability-evaluering af løsninger til digital
borgerservice
Jan Stage
Forskningsleder, Professor
Aalborg University
Institut for Datalogi
HCI-Lab
jans@cs.aau.dk

2. Agenda
• Usability
• Usability-evaluering
• En digital borgerløsning
• Andre brugere
2

3. Agenda
• Usability
• Definition
• Vigtighed
• Usability-evaluering
• En digital borgerløsning
• Andre brugere
3

4. Usability: Hvad er det og hvad er det ikke?
Klassisk definition (ISO 1998):
The effectiveness, efficiency and satisfaction with which a specified set of users can
achieve a specified set of tasks in a particular environment
Nye typer systemer (spil, underholdning User experience
osv.) og nye brugssituationer (anytime,
anywhere osv.) giver anledning til
nye definitioner
Moderne definitioner skelner
mellem tre begreber
Konstruktivt mål: usability-problemer Utility Usability
Eksempel:
Booking/Ledige tider: kan ikke tvinge en akut operation ind.
4

5. Usability: Hvorfor er det vigtigt?
Et stigende antal software-organisationer har fokus på usability
Systemerne udvikles:
• Antallet og typen af brugere
• Brugssituationen
• Typen af system
• Kompleksiteten af software (og hardware)
Mange systemer lever slet ikke op til dette
5

6. Hvorfor: Tiden heler ikke usability-problemer
Dårlig usability vedbliver med at give problemer
Tiden heler ikke dårligt design
• Longitudinal undersøgelse af usability af EPJ
system: IBM IPJ 2.3 (05-2002 og 08-2003)
• Evaluering med sygeplejersker
2002
2003
2002
2003
2002
2003
6

7. Hvorfor: Dårlig usability koster
• Evaluering af IKEA’s hjemmeside
”Det er vist lettere at køre derned” (til Århus)
• Evaluering af Budget Cars hjemmeside
Lej en bil på 60 sekunder
10 personer: 4-17 min.; snit: 7,5 min.
79 usability problemer (5 / 36 / 38)
• Dokumenteret, at det koster kunder
7

8. Agenda
• Usability
• Usability-evaluering
• IDA
• En digital borgerløsning
• Andre brugere
8

9. Instant Data Analysis (IDA)
Gennemfør 4-6 standard tænke-højt forsøg.
En testleder og en data logger er til stede
Gennemfør derefter 1½-2 timers dataanalyse:
baseret på brainstorming og systematisk diskussion.
Organiseret af en facilitator
• Brainstorm
• Noter
• Skærmbilleder
Lad derefter facilitatoren bruge 1-1½ time på at
skrive indholdet fra whiteboardet ind i en ordnet
problemliste med direkte referencer til systemet
Review problemlisten for konsensus
Aflever problemlisten dagen efter evalueringen
9

10. Subject Room
IDA: Eksperiment Test subject
Test monitor
Vi studerede brugen af Instant Data Analysis i et eksplorativt
eksperiment
Data logger
and video
equipment
Observer operator
Formål Observation
Room
Control
Room
• Få praktisk erfaring med brug af teknikken
• Sammneligne resultaterne fra IDA med resultaterne af en traditional
videobaseret analyse
• Identificere styrker og muligheder for at
forbedre IDA
Systemet: resourcebooking på et stort hospital
Deltagere
• 5 testpersoner
• 1 testleder + 1 datalogger
• 1 IDA facilitator
10

11. IDA: Resultater
Instant Data Analysis kan …
• Hjælpe usability-evaluatorer med hurtigt at identificere de mest kritiske og
alvorlige usability-problemer, som opleves af brugere i en serie tænke-højt
forsøg
• Analysen blev gennemført på 10% af den tid, det tager at udføre en traditional
videobaseret analyse
• Reducerede støjen fra unikke (falske) usability-problemer
11

12. Agenda
• Usability
• Usability-evaluering
• En digital borgerløsning
• Sammenligning af to systemer
• Tidsforbrug for borgeren
• Andre brugere
12

13. De to systemer (A og B)
13

14. Sammenligning af de to systemer
Usability-laboratorium
10 deltagere med erfaring fra “gør det selv”
• 8 havde helt eller delvist ombygget deres bolig
• 2 havde selv malet deres bolig
To opgaver blev løst med begge systemer:
1. Ansøg om en 24 m2 garage
2. Ansøg om en 54 m2 tilbygning med ekstra værelser
Procedure:
• Tænkte ikke højt under opgaveløsningen
• Within subject: halvdelen først system A så B, og halvdelen omvendt
• Deltagerne fik 30 minutter med det ene system og 30 med det andet system –
derefter blev de afbrudt
14

15. PDF formular (mm:ss) Dialogbaseret forløb (mm:ss)
Efficiency Deltager A1 A2 Total B1 B2 Total
1 9:32 10:58 20:30 7:16 9:25 16:41
Opgaveløsningstid
2 8:40 6:31 15:11 20:40 6:30 27:10
Begrænset forskel men højere 3 14:20 10:26 24:46 30:15 ----- 30:15
tidsforbrug for system B – 4 7:15 6:40 13:55 7:10 6:20 13:30
både:
5 11:01 7:52 18:53 7:59 5:40 13:39
• Gennemsnitlig 6 10:39 4:04 14:43 6:30 5:37 12:07
opgaveløsningstid
7 11:27 11:37 23:04 14:44 6:31 21:15
• Højeste
opgaveløsningstid 8 7:46 5:36 13:22 12:44 5:54 18:38
9 5:58 9:59 15:57 8:31 8:58 17:29
Hvad gik den ekstra tid med:
10 17:56 4:01 21:57 20:01 6:54 26:55
• Undersøgte information
• Fik lavet attachments Gennemsnit 10:27 07:46 18:14 14:19 06:52 20:30
Højeste 17:56 11:37 24:46 20:40 09:25 30:15
Laveste 05:58 04:04 13:22 07:10 05:37 13:30
15

16. Satisfaction
Brugervenlighed
• ”Nemt”, ”hurtigt”, ”enkelt” og ”overskueligt”
• ”Naturlig rækkefølge i spørgsmålene”
Udseendet
• ”Lækkert” udseende, der gør, at man ”ikke stejler over for kommunens
blanketter”
Tiltro til egen løsning
• ”Giver en mere korrekt løsning”
• ”Risikoen for at glemme noget i blanketten er mindre”
• ”Giver en større sikkerhed”
• ”Der er ikke noget at være i tvivl om”
16

17. Agenda
• Usability
• Usability-evaluering
• En digital borgerløsning
• Andre brugere
• Tidsforbrug for sagsbehandleren
17

18. Sammenligning af de to systemer
Dataanalyse
• Ansøgningerne der kom ud af brugen af de to systemer
• Fik karakterer af en specialist fra en kommune
• Karaktererne blev defineret i forhold til sagsbehandlere i en kommune og den
tid de skulle bruge på at rette fejl i ansøgningerne:
1. Mindre alvorlig fejl: ville tage mindre end 5 minutter at rette
2. Alvorlig fejl: ville tage 5 til 10 minutter at rette
3. Meget alvorlig fejl: ville enten tage mere end 10 minutter at rette, og ville
enten kræve kontakt til ansøgeren eller returnering af ansøgningen
• Den ”perfekte” ansøgning havde en samlet karakter på 29
• Hver fejl gav fradrag derfra (reducering af karakter)
18

19. Ansøgninger
System B producerede bedre
gennemsnitlige karakterer end
System A
Den laveste karakter var også
betydeligt højere for System B
Det gælder også, hvis man fjerner de
ikke afsluttede opgaver
19

20. Diskussion
Er opgaveløsningstiden for den primære bruger (borgeren) virkelig vigtig for et system
som dette?
Den er klart vigtig for den sekundære bruger (sagsbehandleren) – den estimerede
behandlingstid for de producerede ansøgningsskemaer var:
• System A: 51,0 minutter
• System B: 18,5 minutter
For digitale borgerløsninger er det godt at sætte fokus på brugbarhed for borgeren
(den primære bruger)
Men det er mindst lige så vigtigt at fokusere på kvaliteten af det resulterende produkt
og brugbarhed for sagsbehandleren (den sekundære bruger)
20

21. Tak for opmærksomheden ...
21