Posts Tagged ‘metode’

Ekspertvurdering revisited

fredag, marts 19th, 2010

Jeg har tidligere gjort mig klog på at "ekspertvurdere", et emne jeg interesserer mig for at flere årsager: De studerende jeg underviser på IT-Universitetet skal introduceres til denne metode-kategori, men også fordi jeg selv gerne vil have skovlen under de metoder jeg har i værktøjskassen – måske er de to ting det samme :-)

Hele pointen med denne blog er at give dig mulighed for at blive inspireret eller oplyst via de erfaringer jeg gør mig – derfor skal du ikke snydes for mine nyeste forståelser indenfor emnet.

Kært barn har mange navne: Ekspertvurdering, usability evaluering, expert review, heuristic evaluation – Hvorom disse begreber ikke dækker over det samme, så er der vigtige metodiske overlap:

1) De tager alle udgangspunkt i vurdering af et IT-produkts brugbarhed UDEN direkte inddragelse af produktets brugere.
2) De er alle til dels subjektive, sådan at forstå at det er enkeltpersoner der subjektivt tager stilling til produktets kvalitet.

Fra min stol er der to grundlæggende udfordringer med disse metoder:

1) Fordi de er subjektive – hvor enkeltpersoner udfra en eller kontekst finder og definerer problemstillinger – så giver de statistisk set aldrig helt den samme mængde af problemer, nærmest uanset hvor mange gange de gentages. Er dit bud ligeså godt som mit?

2) Metoderne kan udføres på mange forskellige måder og jeg oplever det som svært at give en god entydig beskrivelse af hvordan det gøres godt. Hvordan kommer jeg igang med at lave en fornuftig evaluering af et website?

Metodeoverblik
Jeg kunne lige starte med at ridse noget metodisk landskab op:

1) Cognitve walkthrough – kognitiv gennemgang. Som navnet antyder, ser metoden på den kognitive belastning en bruger oplever i interaktionen med en brugerdialog. Metoden tager udgangspunkt i Human Action Cycle som vi kender den fra fx Donald Norman. Med udgangspunkt i dennes trin, spørger man til hvilke kognitive belastninger brugeren vil opleve undervejs i interaktionen. Det hedder walkthrough fordi man systematisk gennemgår en opgaves trin (fx via task analysis) og stiller de samme grundlæggende spørgsmål til hver sekvens

Det handler mest om indlæring (ease of use), men deri ligger jo også brugbarheden. Er det let at lære, så er det nok også let at bruge. Omend denne metode er lidt stringent og ingenøragtig :D- så er den supergod som forklaringsmodel til evaluering af brugbarhed. Det svære ligger i, at man som evaluator skal forstå/vide/have erfaret, hvad der giver brugeren kognitiv belastning.

2) Så et spring i en helt anden retning: Metaphors of thinking. Her er jeg nærmest ovre i den diamentrale modsætning, men igen er det en ikke-empirisk evalueringsmetode, med subjektiv gennemgang at brugergrænseflader. Denne metode tager udgangspunkt i 5 metaforer, der beskriver den menneskelige handlen og tankeproces (überkort fortalt). Det kan fx handle om dannelsen af vaner og hvordan en brugerdialog kan understøtte etableringen og brugen af vaner (som jo er en blanding af erfaringer og menneskelige kognitive processer). Denne metode er på papiret langt sværere at gå til, fordi det kræver forståelse for metaforerne og den bagvedliggende forståelse af disse.

3) Heuristisk evaluering (HE). Jacob Nielsen og Rolf Molich's udødelige klassiker, som nok mest overlever idag som navn, snarere end som specifik metode. Så HE bliver tit en slags massebetegnelse for alle typer evalueringer, om der så står ekspert, usability eller heuristisk foran. Metoden trækker på 10 såkaldte heuristikker (fordi de ikke turde kalde de "principper" :-) ), hvor evaluatoren forholder identificerede problemstillinger med disse 10 forhold omkring "God skik og brug".

(Husk at se Rolf Molich's gentagne og påtrængende sammenligning af evalueringsmetoder i Comparative Usability Evaluation undersøgelserne).
(Se eventuelt også dette paper om variationer eller forbedringer af HE: A comparative evaluation of heuristic-based usability inspection methods).

Tre perspektiver
Det var tre metoder, tre perspektiver, tre grundlag at spørge ind med. For de første to er det påkrævet at opstille en kontekst for gennemgangen, typisk de opgaver som brugeren søger at løse i produktet. Min erfaring er, at det også er en meget god idé for HE. Den kontekst kan være meget forskelligartet: Det kan være personas, det kan være funktioner/features, det kan være resultatet af en spørgeskema – men det er det man vælger at fokusere gennemgangen imod, en ramme, en afgrænsning.

HE kan man også tage mere generelt, som en slags tjekliste, men det kræver at kan oversætter heuristikkerne til regler for godt interaktionsdesign, så man ved hvad man skal se efter. Dermed kommer man (som jeg oplever det) potentielt kun længere væk fra den faktiske (formodede) brug.

Men når nu det hele handler om en individuel, subjektiv vurdering, hvordan så med validitet og ikke mindst reliabilitet  – altså hvor vidt vi reelt får svar på det vi spørger om og især om gentagne evalueringer kommer til samme resultat. Grundlæggende må man nok acceptere at disse metoder minder om smagsdommeri. Om et slags peer-review, hvor en der ved lidt bedre, giver sit besyv. Derved kaster jeg umiddelbart en hvid pind efter disse begreber, måske mest efter HE, der kun er funderet på sine 10 (delvist forældede og software-relaterede) heuristikker. Men hvis jeg ved at der er problemer med resultaterne, så kan jeg også bedre forhold mig til dem.

Udfordringerne
Så tilbage til de to udfordringer:

1) Ja, de er subjektive – så hvad gør man der? Målet må være at finde en måde at påpege kvaliteter i den måde de udføres. Et kunen være at påpege evaluatorens kvalitet igennem dennes erfaring og evner. En anden kunne være at opstille brugerens mål og opgaver, for at henvise til den værdi der kan skabes i det evaluere netop denne. En tilgang kunne være at beskrive helhedsorientering og systematik (altså metodik), for derved at kunne gentage og sammenligne resultater. Det gør ikke metoderne mindre subjektive, men udstiller så svar på denne udfordring og angiver derved en kvalitet. Metoderne angiver naturligvis at flere evaluatorer udfører metoden, sammenligner og prioriterer problemer, for derved at konsolidere disse.

2) Hvordan udføres en evaluering bedst muligt? Hvor skal man starte? Det kommer an på hvad formålet er. For de studerende, der potentielt aldrig har lavet en evaluering før, er det underordnet om man bruger heuristikker eller andre former for usability-relaterede principper og regler. De skal blot have noget at læne sig opad. På sigt opbygger de deres eget katalog af heuristikker og opøver derved noget der med rette kan kaldes for "ekspert-gennemgang". Jeg tror meget metodevalget afhænger af hvad man vil. Fordi evaluering af websites ofte er mere generel, ikke kun ser på løsningen af en specifik afgrænset opgave og ser på den samlede oplevelse, så er det nemmest at gå efter HE. Men resultatet bliver derefter. Det bliver lidt på overfladen og det bliver potentielt falske positiver – problemer der faktisk ikke er problemer for de virkelige brugere.

Svaret herfra bliver derfor – brug HE og de retningslinje-orieterede tilgange til det generelle og det "lette". Brug de andre metoder til det specifikke og opgave-relaterede.

Jeg er ikke færdig med disse metoder, men jeg er nu blevet langt klogere på hvilke der er, hvad deres udfordringer er,hvordan jeg kan retfærdiggøre brugen af dem og hvordan jeg kan argumentere for at levere en evaluering af en god kvalitet.

Sig CISU-R til dit Projekt-ür (bedre titel søges…)

onsdag, maj 20th, 2009

Jeg har tidligere skrevet om ressourcer (dokumenter) til usability-kriterier. Mere præcist har jeg henvist til Common Industry Specification for Usability – Requirements – eller CISU-R. Ganske fortinligt dokument viser det sig (ved granskning). Faktisk understøtter det en af mine kæpheste (eller darlings (don’t kill it!)), nemlig det at opstille usability-mål for det projekt eller produkt man arbejder med. Idéen er helt rationel og logisk: Hvis man ikke sætter et mål for hvor brugbart noget er, så kan man heller ikke vurdere om man har opnået det niveau.

Jeg har gjort mig en del tanker og etableret mig en forståelse omkring brugen af usability-kriterier og -mål. En forståelse jeg så prædker, primært på IT-Universitetet: På samme måde som de fleste af mine andre mentale modeller, så ender formidlingen ofte i noget tre-punkts-form. Usability-kriterierne har jeg passet ind i en model med: Brugssituation (brugere, mål, brugskontekst), Usabilitymål (kvalitet) og Produkt (adgang til ressourcer og kompetencer). Den opstilling synes jeg er frugtbar. Grunden til, at jeg nævner den her er, at CISU-R præsenterer en anden og tilsvarende tre-punkts-liste, som på mange måder er relateret. I den indgår: Context of Use, Performance and Satisfaction Criteria og Test Method and Context for Test. De to opstillinger vil lidt det samme, jeg har blot taget teknologien mere direkte med, mens CISU-R holder lidt mere fast i sammenhængen mellem kriterier og test til vudering af deres opnåelse.

CISU-R er en ramme, en mængde informationer der skal tilvejebringes, en bunke beslutninger der skal tages. Dertil er dokumentet fyldt med eksempler og skabeloner, så det er også ret handlingsanvisende.

Uanset. Jeg synes CISU-R er superfedt, fordi det også passer ind i en problematik jeg gerne arbejder med: Hvad er det der mangler i udviklingsprojekter, for at sikre, at der bliver arbejdet seriøst, professionelt og kompetent med usability. Svaret ligger i CISU-R. Og det er: Specificering af usabilitykrav!

Det er ikke krav til brugergrænsefladen. Det er ikke funktionelle krav til interaktion (der måske, måske ikke er brugervenlig). Nej, det er specifikke usabilitykrav, som understøtter og komplimenterer de øvrige funktionelle, processuelle og kvalitetsorienterede krav.

Det er såre simpelt. I kan ikke arbejde med usability, hvis ikke I stiller krav til det. Det giver ikke mening at slås om ressourcer, testmetoder eller udviklingsproces, hvis ikke der er enighed om, at der skal opnås en bestemt kvalitet i brugen af produktet. Den kvalitet fordrer processen, metoderne og behovet for kompetencer – eller skulle det i bedste fald.

Jeg arbejder selv til daglig i en virksomhed som ikke direkte stiller krav til usability. Der stilles mange andre krav, hvoraf flere er relaterede. Men også derfor er arbejdsprocessen omkring håndtering af usability ikke fastlagt. Den er beskrevet, men bliver – som mange mange andre steder – hånderet lidt lemfældigt (og det er pænt sagt).

Det lækre ved CISU-R, er at den tager opgaven meget alvorligt, hvilket jeg også tror er måden gøre det på, i den moderne, dokumentations-fikserede, modenheds- og certificerings-fokuserede, styringsliderlige softwareudviklings-verden. Der henvises til ISO-standarder i flæng og det beskrives hvordan CISU-R passer ind i alle mulige seriøse  og gennemdokumenterede proces- og metode-beskrivelser.

Men igen. Kunsten er at få etableret usabilitymål i den organisation man indgår i. Som en del af den fælles strategi, som et eksplicit kvalitetsniveau produktet skal opnå.

Tilbage er kun at argumentere for værdien af denne proces (i rigtige penge). Det findes der med garanti også et godt, praksis-orienteret svar på derude…

Lad os komme igang med at specificere vore usability-krav.

Ohür