1. Psykologiske metoder Peter Malling, psykolog
til brugerinddragelse !1

2. Peter Malling
!2

3. Formiddagens program
• En systematisk tilgang til brugerinddragelse
• Standarder og iterative metoder
• Etablering af en superbrugerorganisation
!3

4. 2+2
• Hvad vil du gerne forstå bedre?
• Hvad vil du gerne være bedre
til?
!4

5. !5

6. 2+2
• Fortæl om et projekt, hvor I
med succes fik involveret
brugerne
!6

7. 2+2
• Hvad er din vigtigste udfordring
pt.?
!7

8. En systematisk tilgang til brugerinddragelse
og brugerorienteret design
!8

9. Brugerdrevet design
Brugervenlighed
Brugerorienteret design
Brugerinvolvering
User adoption
!9

10. Vandfaldsmodellen
Kravspecifikation
Design
Kodning
Afprøvning
Vedligeholdelse

11. Problemer, som kan opstå
• Manglende brugerinvolvering
• Utilstrækkelig styring af krav
• Manglende koordination af aktiviteter
• Kommunikationsproblemer
• Indsamling af domæneviden
• Nøgleinformanter har travlt
• Organisatoriske og politiske hensyn
• Stærke og svage interessenter
• Ændringer i organisation og omgivelser

12. Iterativt design
Identificér behov
og krav
Brugertest
(Re)Design
og evaluering
Prototyping
Færdigt
produkt

13. SEPTIGON-modellen
Individ
Teknologi Gruppe
Fysisk miljø Organisation
Processer Samfund og kultur
!13

14. Kravspecifikationen
• Fokuserer på hvad systemet skal kunne
• Brug standard skabeloner
• Skriv simpelt, konsistent og præcist
• Brug diagrammer på passende vis
• Understødt naturligt sprog med formelle
bekskrivelsesværktøjer (afhæng af læserne)
• Angiv krav kvantitativt hvis det er muligt

15. Behov
• Oplevede behov
• Udtrykte behov
• Normative behov
Lyt til brugerne!

16. Designeren, brugeren
og systemet

17. Målgruppen og dens egenskaber
• Målgruppen: Hvem henvender
produktet sig til
• Hvad karakteriserer denne gruppe?

18. Brugeregenskaber
relevante for UI design
• Alder
• Køn
• Kultur
• Fysisk evner og handicaps
• Uddannelsesmæssig baggrund og
domæneviden
• IT erfaring
• Motivation
• Holdninger

19. Fra egenskaber til krav
Brugeregenskaber UI krav
Alder: 12-80+ Skærmen skal kunne bruges af folk med forskellig
højde
Kan have fysiske Skal kunne bruges af gående såvel som
begrænsninger kørestolsbrugere eller folk med stokke. Skal tage
hensyn til gigt i hænderne
Kan have problemer med Der skal være både visuel og auditiv feedback på
hørelsen al brugerinteraktion
Etc....

20. Brugerprofilering: Dankortautomat
Alder 12-80+
Køn Mænd og kvinder
Fysiske begrænsninger Kan have fysiske begrænsninger: hørelse, syn, mobilitet,
brug af hænder, kørestol
Kan have varierende højde
Uddannelsesmæssig baggrund Kan have minimale uddannelsesmæssige kvalifikationer og
besidde begrænset talforståelse og evne til at læse/skrive
Computer/IT erfaring Kan have ingen eller begrænset erfaring i brug af computere
Motivation Kan være meget motiveret til at bruge Dankortautomaten,
særligt hvis man kan udføre transaktionen hurtigt uden at
skulle stå i kø i banken
Holdning Holdningen til anvendelse kan variere afhængigt af
automatens services, pålidelighed og brugerens holdning
til computere

21. Mentale modeller
• Modeller, som folk har af dem selv, andre, omgivelserne og
tingene de bruger. Man danner mentale modeller gennem
erfaring, træning og instruktion
– Ofte ubevidste, "tavs viden"
– Personlige
– Ufuldstændige og ofte fejlbehæftede
– Ustabile, henfalder hvis de ikke bruges
– Dårligt afgrænsede, ofte sammenblandinger
– Uvidenskabelige og overtroiske
– Statiske - hellere udføre ekstra arbejde end ændre mentale
modeller

23. Mentale modeller og usability
• MM hjælper til at navigere i verden gennem
effektive forudsigelser
• Eksisterende MM bruges når man møder et nyt
system
• Hvis MM ligner systemet: let at lære
• Vægte hensynet til lighed med MM og radikal
innovation

24. Strukturelle og funktionelle MM
Strukturelle MM: Funktionelle MM:
• Brugeren ved, hvorledes • Brugeren ved, hvorledes
systemet fungerer systemet anvendes
• Kontekstuafhængige • Kontekstafhængige
• "Nørd"-agtige: Kan bruge • Muliggør effektiv løsning af
systemet til at løse mange bestemte opgaver med et
opgaver, "presse minimum af mental
systemet" anstrengelse

25. At forstå
brugernes MM
• Svært pga af deres natur
(ubevidste, ustrukturerede etc.)
• Kan ikke afdækkes gennem eksplicit at spørge til dem
• Må udledes af interviews, fokusgrupper, observationer
etc.
• Interaktionen mellem et system og brugeren fortæller
noget om forskellen mellem designerens MM og
brugeren MM

26. Personaer
• Fiktive brugere
• Modelleres over generelle karakteristika
• Bruges til rollespil ved fx. brainstorms om
funktioner som brugerne vil have i fremtiden
• Holder de vilde ideer i tøjler men åbner for
kreative tanker
• Focus på brugeroplevelsen gennem indlevelse
i brugeren

27. Opgaveanalysen
• Skabe en klar forståelse af hvad et system skal
hjælpe med at udføre - FORMÅLET!
• Analyseres hierarkisk - dekomponeres så langt ned
det er nødvendigt
• Typiske spørgsmål:
– Hvilke informationer er nødvendige?
– Hvad starter en opgave?
– Hvad sker med det, som skabes?
– Afhænger den af andre opgaver?
– Hvad kan gå galt?
– Artifakter til omgåelse af uhensigtsmæssigheder

28. Opgave karakteristika
Variationen i opgaverne fra gang til gang ?
Hyppige, lejlighedsvise eller bare en gang?
Nødvendig viden og færdigheder ?
Påvirkninger fra omgivelserne?
Tidskritiske opgaver ?
Sikkerhedskritiske opgaver ?
Alene eller i samarbejde ?
Mange opgaver på samme tid (multi-tasking) ?

29. Mål, opgaver og handlinger
MÅL
Opgave Opgave Opgave
Handling Handling Handling Handling

30. Workflowanalyse

31. Formålet med prototyper
• Undersøg nye ideer sammen med brugerne
• Test brugbarheden af en applikation
• Tillad brugere at bidrage
• Tillad brugerne at afprøve deres ideer
• Validering af krav
• Forhandling af krav

32. Simple prototyper
• Skitser
• Skærm mockups
• Storyboards

33. Testning
(Tænke-højt test)

34. Choose the evaluation approach and methods
Valg af evalueringstype og metoder
• Typen af evaluering influerer på metoderne, som
anvendes, som igen påvirker, hvordan data
indsamles, analyseres og rapporteres
• F.eks. vil feltstudier typisk:
− Indbefatte observation og interviews
− Ikke omfatte kontrollerede laboratorie-tests
− Resultere i kvalitative data
• Afhænger også af praktiske og etiske forhold
• Metodetriangulering
!34

35. Opgaver
• Kerneopgaver som ofte udføres af brugere
• Opgaver, som er vigtige for brugerne eller
forretningen
• Opgaver med nyt design eller funktionalitet
• Kritiske opgaver, selvom de ikke er ofte brugt
• Opgaver, som menes at give designteamet
bedre forståelse og klarhed
!35

36. Identify practical issues
Praktiske forhold
• Rekruttering af testdeltagere *)
• Budget
• Tidsplan *)
• Sted *)
• Udstyr
• Medhjælpere
!36

37. Rekruttering af testdeltagere
• Antal deltagere
– Hellere mange tests med få brugere
• "Stand by" deltagere
• Ekspertise, demografi etc.
• Spørgeskema og interviews til screening
• "Typiske brugere" og andre
• Taget afslappet på screeningen (Krug)
– Undtagelser : afgrænset brugergruppe, forskellige grupper,
kræver domæneviden
• "Betaling"; Takkeskrivelse
!37

38. Indsamling af data
• Kvantitative data
− Tidstagning og logging
• Kvalitative data
− Testdeltagernes egne udsagn
!38

39. Kvantitative data
• Tidstagning
• Logging software
• Kommer fra
− Sikkerhedsovervågning
− Fremstilling af demonstrationer
− Logning af brugeradfærd på websites
• Synkronisering med kvalitative data (noter og
kommentarer fra testdeltagerne)
• Software til usability testning (Ovologger)
!39

40. Kvalitative data
• Tænke-højt test
• Notetagning
− Brugerens handlinger
− Brugerens kommentarer
• Hav masser af papir
• Anvendelse af computer til notetagning
• Indsamling af data efter sessionen
− Retrospektiv gennemgang (samtidig med video af
sessionen)
• Påvirkning af test; Rationalisering; Umiddelbarhed; Svært at tale
samtidig
− Debriefing interview
!40

41. Typiske fejltagelser
• Brugertest sker ofte for lidt, for sent og
af de forkerte grunde
• Fokusgrupper forveksles med
brugertestning
• Man kan lige bruge sig selv som
testperson i en klemt situation

42. Testning
• Test med bare 1 bruger er bedre end ikke at
teste nogen
• Det er bedre at teste 1 bruger i begyndelsen
end 50 mod slutningen
• Vigtigheden af "repræsentativ" bruger er
overvurderet
• Test skal informere, ikke bevise
• Testning er en iterativ proces

43. Tænke-højt test
!43

44. Sprogbrug
En tænke-højt test af brugervenlighed (også kaldet en
test) udføres af en leverandør for en kunde på grundlag
af en kravspecifikation. En test består af en række
testseancer. I hver testseance løser en testdeltager som
tilhører en forud aftalt målgruppe, en række testopgaver
med et produkt under overvågning af en testleder!.
Forløbet af en testseance er beskrevet i en drejebog.
Efter testen udarbejder testlederen en testrapport.
! Testleder = moderator = facilitator (KBHMN)

45. Kravspecifikation
• Formål med testen
• Hvilket produkt der skal testes
• Målgruppe, screeningkriterier
• Antal testseancer
• Tidsfrister
• Navn på testleder og evt. assistenter
• Sted for testen
• Kommunikation af testresultater

46. Drejebog
• Detaljeret forløb af en testseance
• Indhold
− Indledende bemærkninger
− Henvisning til evt. spørgeskemaer
− Stikord til indledende interview
− Testopgaver
− Stikord til debriefing

47. Testopgaver (1)
• Åbne vs. lukkede testopgaver
− Web-wide ("Du og din familie er interesseret i at tage på ferie til Mazatlan,
Mexico. Find et rejsetilbud, som både ser spændende ud og er rimeligt i pris")
− Site-specific testing ("Gå til www.post.dk og find ud af hvad det
koster at sende et postkort til Kina")
• Ingen skjult hjælp
• Rammer for acceptable løsninger
• For lukkede testopgaver:
− Første testopgave skal være enkel
− Kernefunktioner før sekundære funktioner

48. Testopgaver (2)
• Max 1 time i alt
• Hver opgave max 10 min.
• Relevante opgaver
• Realistik rækkefølge
• Evt. vælge opgaver "strategisk" udfra mål om
test af særskilte dele af systemet, f.eks.
navigation, søgning osv.

49. Testdeltagere
• Hver testseance omfatter 1-2 testdeltagere fra
målgruppen
• Fortrolige med teknologien (fx. web/GUI), men
ikke fagkyndige indenfor usability
• Forskellige niveauer af brugerekspertice
• Betaling eller gave af rimelig værdi til
testdeltagere (ca. 300 kr)
− Ingen gaver giver atypiske testdeltagere
• Mindst 4 testseancer.

50. Forløbet af en tænke-højt test
• Modtagelse af testdeltager. Evt. spørgeskemaer.
• "Systemet testes, ikke testdeltageren !"
• Interview om kendskab til webstedet etc.
• Testlederen beder testdeltageren løse testopgaverne
én for én, mens han siger hvad han tænker !
• Interview: testdeltagerens opfattelse af produktet
• Farvel og gave

51. Retningslinjer for tænke-højt test
• Fokusér på adfærd - ikke meninger.
• Spørgeskemaer ej til statistik
• Testlederen skal være passiv
− Ingen hjælp, heller ikke skjult
• Prompte testdeltageren
• Hvis testdeltager går i stå
− minimal hjælp
− afbryde opgaven
• Testlederen skal være objektiv

52. Lokalitet
• Hos kunden
• Steder hvor brugere naturligt færdes
• Hos leverandøren
• I et testcenter

53. Tilskuere og optagelse af test
• Mulighed for at følge seancen fra nabolokale
• Optagelse af seancen
− Videooptagelse / Screen capture / Lydoptagelse
− Anonymitet: ikke udlevere til kunden
• Hvis ingen optagelse: omhyggelige noter
• Testleder tæt på deltager eller i nabolokale
• Andre tilskuere
− Testlederen i testlokalet
− Bag projektdeltageren
− Passiv adfærd
− Aktive under afsluttende interview

54. Andre forhold
• Én testleder
• Tilstedeværelse af observatører
• Generelle etiske regler:
− Testdeltageren orienteres om optagelse/tilskuere
− Testdeltageren orienteres om anvendelse af bånd og
resultater
− Testdeltagere skal kunne sige fra (og få gave)
− Testdeltagerens overordnede må ikke overvære test eller få
adgang til optagelser
− Testdeltagere skal fremstå anonymt

55. Testlederen
• Bør prøve testen på sig selv først
• Være god ved forsøgspersonerne
• Leve sig ind i dem (empatisk)
• Se "tankeboblerne" over brugernes hoved
• Ikke give hints
• Bore - bore - bore
• Improvisere
• Tage notater efter hver test (sammen med
observatørerne)

56. Testrapport
• Udarbejdes af testleder, evt. i samarbejde med
assistenter
• Brugbar for modtageren
• Passende længde

57. Testrapportens opbygning
• Resumé
− 3 gode ting
− 3 problemer
− Overordnede råd
• Indholdsfortegnelse
• Kort beskrivelse af fremgangsmåde
− Metode, udstyr, deltagerprofiler
• Testresultater !
• Drejebog (evt som appendiks)

58. Rapportering af testresultater
• Særligt vægt på resultater som vedrører
nøgleopgaver
• Klassifikation af testresultater:
− Forbilledlig; Mindre problem; Alvorligt problem; Kritisk
problem; God idé!
• Problemets hyppighed
• Løsningsforslag
• Skelne mellem adfærd, testdeltageres meninger og
testlederens meninger
• Passende antal testresultater (20-50)
− Testlederen skal prioritere problemerne, ikke læseren

59. Explore the questions
Formulér test-bare spørgsmål
• Operationalisering af målene
• Nedbryde spørgsmål i test-bare underspørgsmål.
• "Er det en dårlig brugerflade?":
− Er det svært at navigere i systemet?
− Er sprogbrugen forvirrende pga inkonsistens?
− Er responstiderne for langsomme?
− Er feedback fra systemet forvirrende eller utilstrækkeli?
!59

60. Anvendelse af kognitiv
gennemgang ifm tænkehøjt test
• Er der noget som fortæller dig, hvad du skal
gøre nu?
• Er der noget på skærmen som giver dig
mulighed for at gøre, hvad du vil gøre? Hvad?
• Nu du har prøvet det, gjorde den så, hvad du
ønskede?
!60

61. Anvendelse af
teknologier til optagelse
• Video og lyd optagelse
− Hvordan får man både deltager og skærm på
videoen? *)
• Eye tracking
• Teknologi vs. papir og blyant
• Hvad hvis brugeren ikke vil optages?
!61

62. Optagelse af deltager og skærm
!62

63. Roller i evalueringen
• Facilitator/testleder
• Notetager
• Tekniker
• Observatør
• Ansvarlig for velkomst
• Ansvarlig for rekrutering
• Én-persons teamet
!63

64. Drejebogen
• Fordele
• Ulemper
!64

65. Pilottesten
• Vigtig for at være sikker på, at man har husket
det hele
• Virker prototypen?
• Er materialet klart nok?
• Virker observations- og
dataindsalingsmetoder?
• Kender alle deres roller?
• Er der tid nok til opgaverne?
!65

66. !66

67. ISO 9241-210
• Designet bygger på en excplicit forståelse af
brugere, opgaver og miljøer
• Brugere inddrages gennem design og udvikling
• Designet er drevet af og forbedres ved user-
drevet evaluering
• Processen er iterativ
• Designet adresserer hele brugeroplevelsen
• Design-teamet omfatter multidisciplinær viden
og perspektiver.
!67

68. !68

69. !69