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

3

Agenda

• Usability• Definition• Vigtighed

• Usability-evaluering

• En digital borgerløsning

• Andre brugere

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, underholdningosv.) og nye brugssituationer (anytime,anywhere osv.) giver anledning tilnye definitioner

Moderne definitioner skelnermellem tre begreber

Konstruktivt mål: usability-problemerEksempel:Booking/Ledige tider: kan ikke tvinge en akut operation ind.

Usability

User experience

Utility

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

Usability: Hvorfor er det vigtigt?

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 EPJsystem: IBM IPJ 2.3 (05-2002 og 08-2003)

• Evaluering med sygeplejersker

20022003

20022003

20022003

Hvorfor: Dårlig usability koster

• Evaluering af IKEA’s hjemmeside”Det er vist lettere at køre derned” (til Århus)

• Evaluering af Budget Cars hjemmesideLej en bil på 60 sekunder10 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

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

10

IDA: Eksperiment

Vi studerede brugen af Instant Data Analysis i et eksplorativteksperiment

Formål• 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 IDASystemet: resourcebooking på et stort hospital

Deltagere• 5 testpersoner• 1 testleder + 1 datalogger• 1 IDA facilitator

Subject Room

Observation Room

Control Room

Data logger and video equipment operator Observer

Test monitor

Test subject

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

12

Agenda

• Usability

• Usability-evaluering

• En digital borgerløsning• Sammenligning af to systemer• Tidsforbrug for borgeren

• Andre brugere

13

De to systemer (A og B)

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 garage2. 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

15

Opgaveløsningstid

Begrænset forskel men højere tidsforbrug for system B – både:

• Gennemsnitlig opgaveløsningstid

• Højeste opgaveløsningstid

Hvad gik den ekstra tid med:

• Undersøgte information

• Fik lavet attachments

Efficiency PDF formular (mm:ss) Dialogbaseret forløb (mm:ss)Deltager A1 A2 Total B1 B2 Total

1 9:32 10:58 20:30 7:16 9:25 16:41

2 8:40 6:31 15:11 20:40 6:30 27:10

3 14:20 10:26 24:46 30:15 ----- 30:15

4 7:15 6:40 13:55 7:10 6:20 13:30

5 11:01 7:52 18:53 7:59 5:40 13:39

6 10:39 4:04 14:43 6:30 5:37 12:07

7 11:27 11:37 23:04 14:44 6:31 21:15

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

10 17:56 4:01 21:57 20:01 6:54 26:55

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

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

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 rette2. Alvorlig fejl: ville tage 5 til 10 minutter at rette3. 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)

19

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

Ansøgninger

20

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)

Diskussion

21

Tak for opmærksomheden ...