Psykologiske metoder til brugerinddragelse

Peter Malling, psykolog

!1

Peter Malling

!2

Formiddagens program

• En systematisk tilgang til brugerinddragelse

• Standarder og iterative metoder

• Etablering af en superbrugerorganisation

!3

2 + 2

• Hvad vil du gerne forstå bedre?

• Hvad vil du gerne være bedre til?

!4

!5

2 + 2

• Fortæl om et projekt, hvor I med succes fik involveret brugerne

!6

2+2

• Hvad er din vigtigste udfordring pt.?

!7

En systematisk tilgang til brugerinddragelse og brugerorienteret design

!8

Brugerinvolvering

Brugerorienteret design

Brugerdrevet design

User adoption

Brugervenlighed

!9

VandfaldsmodellenKravspecifikation

Design

Kodning

Afprøvning

Vedligeholdelse

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

Iterativt design

Identificér behov og krav

(Re)Design Brugertest og evaluering

PrototypingFærdigt

produkt

SEPTIGON-modellenIndivid

GruppeTeknologi

Processer

Fysisk miljø

Samfund og kultur

Organisation

!13

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

Behov

• Oplevede behov • Udtrykte behov • Normative behov

Lyt til brugerne!

Designeren, brugeren og systemet

Målgruppen og dens egenskaber

• Målgruppen: Hvem henvender produktet sig til

• Hvad karakteriserer denne gruppe?

Brugeregenskaber relevante for UI design

• Alder • Køn • Kultur • Fysisk evner og handicaps • Uddannelsesmæssig baggrund og

domæneviden • IT erfaring • Motivation • Holdninger

Fra egenskaber til krav

Brugeregenskaber UI krav

Alder: 12-80+ Skærmen skal kunne bruges af folk med forskellig højde

Kan have fysiske begrænsninger

Skal kunne bruges af gående såvel som kørestolsbrugere eller folk med stokke. Skal tage hensyn til gigt i hænderne

Kan have problemer med hørelsen

Der skal være både visuel og auditiv feedback på al brugerinteraktion

Etc....

Brugerprofilering: DankortautomatAlder 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

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

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

Strukturelle og funktionelle MM

Strukturelle MM: • Brugeren ved, hvorledes

systemet fungerer • Kontekstuafhængige • "Nørd"-agtige: Kan bruge

systemet til at løse mange opgaver, "presse systemet"

Funktionelle MM: • Brugeren ved, hvorledes

systemet anvendes • Kontekstafhængige • Muliggør effektiv løsning af

bestemte opgaver med et minimum af mental anstrengelse

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

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

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

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) ?

Mål, opgaver og handlinger

MÅL

Opgave Opgave Opgave

Handling Handling Handling Handling

Workflowanalyse

• 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

Formålet med prototyper

Simple prototyper• Skitser • Skærm mockups • Storyboards

Testning (Tænke-højt test)

!34

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

Choose the evaluation approach and methods

!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

!36

Praktiske forhold

• Rekruttering af testdeltagere *) • Budget • Tidsplan *) • Sted *) • Udstyr • Medhjælpere

Identify practical issues

!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

!38

Indsamling af data

• Kvantitative data − Tidstagning og logging

• Kvalitative data − Testdeltagernes egne udsagn

!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)

!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

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

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

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)

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

Drejebog

• Detaljeret forløb af en testseance • Indhold

− Indledende bemærkninger − Henvisning til evt. spørgeskemaer − Stikord til indledende interview − Testopgaver − Stikord til debriefing

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

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.

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.

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

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

Lokalitet

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

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

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

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)

Testrapport

• Udarbejdes af testleder, evt. i samarbejde med assistenter

• Brugbar for modtageren • Passende længde

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)

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

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?

Explore the questions

!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?

!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?

!62

Optagelse af deltager og skærm

!63

Roller i evalueringen

• Facilitator/testleder • Notetager • Tekniker • Observatør • Ansvarlig for velkomst • Ansvarlig for rekrutering • Én-persons teamet

!64

Drejebogen

• Fordele • Ulemper

!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?

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

!68

!69