BLOG
SOFTWARETEST

Blog: Usability test

IT, hvad end det er hjemmesider eller andre applikationer, er ikke længere primært arbejdsredskaber til brug uden for hjemmet, og vi er ikke længere lige så tålmodige eller tilgivende. Det skal være intuitivt forståeligt og let at bruge – ellers finder vi en anden løsning.

[20. september 2016] Alle har efterhånden hørt om Usability eller den danske udgave: Brugervenlighed – selv Fru Hansen, som kun anvender ”det der EDB noget til e-boksen, når det nu ikke kan være anderledes” har efterhånden stiftet bekendtskab med brugervenlighed, enten som modtager af en dårlig oplevelse eller i pressen, hvor der er meget fokus på brugernes oplevelser med IT løsninger. Der er også mange, om ikke andet så i IT branchen, der også har hørt om Usability test. Desværre er der også en opfattelse af, at Usability test kan være en besværlig og dyr proces at sætte i gang. Ligesom med meget anden test, er det primært dyrt hvis det ikke bliver gjort på det rette tidspunkt og helst lang tid inden en løsning skal i produktion. Selvom en større test kan være at foretrække, så kan mindre også gøre det og det behøver hverken at være besværligt eller dyrt.

I test verdenen er der en tendens til at fokusere mere på systemtest, hvor især de kvantitative og mere analytiske metoder virkelig kommer til deres ret – målbare konkrete tests, hvor der kommer ”rigtige” metrikker ud af en struktureret test, hvor der testes smart og lean. Det er langt sværere på forhånd at forudsige hvad der kommer ud af en usability test – defects er ikke små, klart definerede fejl som kan sendes til en udvikler til fejlrettelse. En defect fra en usability test, kan i værste fald resultere i et nyt design eller omstrukturering med mange timers omkodning som følge, da det kan være et grundlæggende flow der skal laves om.

Men lad os først lige genopfriske hvad Usability egentlig er. Usability defineres som: ”I hvor høj grad et produkt kan bruges af en bestemt brugergruppe til at opnå bestemte mål med effektivitet, lethed og tilfredshed i en bestemt brugskontekst.” Usability er udtrykt i forhold til primært flg. parametre:

-        Let at lære

-        Effektivt at anvende

-        Let at huske

-        Evne til at behandle fejl der opstår

-        Tilfredshed

Altså er det disse parametre, som du skal have fokus på i testen.

Hvem, hvad og hvornår?

Inden vi adresserer ’hvordan’, så er det vigtigt forinden at etablere hvad det helt præcist er der skal testes. F.eks. hvis løsningen er en hjemmeside, er det så navigationen generelt eller er det en købssituation der skal testes? Hvis det er et arbejdsredskab, hvad er det for nogle arbejdsopgaver der skal løses? De skal identificeres og prioriteres.

’Hvem’ er også en vigtig parameter her – hvis løsningen er tiltænkt Fru Hansen fra før, nytter det ikke noget at det er Agnete fra IT Support, der tester det. For at hjælpe processen, kan der udarbejdes personaer til formålet. En persona er en fiktiv person, som beskriver en typisk bruger af løsningen som bruges til at synliggøre en typisk brugers forventede interaktion med løsningen. Der kan udarbejdes lige så mange personaer som løsningen har typer af brugere. Fru Hansen er en fin start på en persona – målet med en persona er, at det næsten er muligt at se den fiktive person foran sig i en brugssituation – du har sikkert allerede selv dannet et mentalt billede af Fru Hansen? Personaen kan også bruges udover testsituationen – især i design fasen vil et mentalt billede af de endelige brugere forbedre og målrette designet.

Hvornår skal der testes er et let spørgsmål; så tidligt som muligt. Så snart der er noget for en bruger at forholde sig til i form af design og arbejdsprocesser, kan der med fordel testes, så det er muligt tidligt at få afprøvet flows og brugergrænsefladen – det er langt billigere at ændre et flowdiagram eller en tegning end at ændre i koden.  

Hvordan?

Der findes en stor mængde af metoder til at teste Usability – jeg foretrækker de kvalitative metoder, men en gennemgang af heuristikker, designguides og andre former for review kan også sagtens anvendes i den rette sammenhæng. Fælles for de kvalitative metoder er, at systemets slutbrugere skal anvendes for virkelig at give stor værdi.

Den metode jeg foretrækker at anvende er den gode gamle brugertest, men der er også andre metoder til at give et hurtigere indblik i brugervenligheden af et system. Jeg vil give en kort gennemgang af begge dele i de følgende afsnit.

Brugertest

Brugertest er nok den mest kendte brugervenlighedstest, som typisk går ud på at give en bruger en opgave at løse i løsningen mens der observeres. Testen styres af en test moderator suppleret af en observatør. Der findes et væld af variationer på testen og den er relativ let at gennemføre. Forbered testen ved at udarbejde en side pr. opgave der skal testes. Siden skal indeholde følgende informationer:

-        Hvad det er du gerne vil have testet

-        Beskriv den måde hvorpå det er tiltænkt opgaven skal løses i designet

-        Hvor lang tid det forventes opgaven skal løses på

-        En opgavetekst du kan give til testeren

-        Plads til noter på siden, til når testen skal gennemføres

Når testen starter giver du opgaveteksten til testeren og beder testeren om verbalt at beskrive hvad han forsøger og oplever. Det kan være svært for en der ikke er vant til det, så du kan med fordel stille små spørgsmål undervejs – ”hvorfor klikkede du der”, eller ”hvorfor mente du at opgaven kunne løses der?” eller muligvis starte med en prøve – f.eks. at skille en kuglepen ad og kommentere undervejs for at vise hvad det er du forventer af testeren. Under testen skal du placere dig, så du kan se skærmen, dog uden at invadere testerens privatsfære. Observatøren skal, udover notere hvad der bliver sagt, notere den non-verbale kommunikation ned der opstår undervejs, som f.eks. suk, rysten på hovedet eller små udbrud. For at lette testen, kan der anvendes programmer, der kan optage skærmen og evt. et videokamera (i stedet for en obervatør). Når opgaverne er løst, afsluttes testen med et lille interview – for at få de sidste observationer med fra testeren – måske i et mere overordnet perspektiv. Du kan finde en række uddybende beskrivelser af brugertest på nettet og i bøger, hvis du har brug for mere information.

Gangstertest

Peter går på en mørk vej i en øde del af byen. En bil kører op langs siden af Peter. To mænd hopper ud af bilen, griber fat i Peter og giver ham bind for øjnene. De binder hans hænder og kaster ham ublidt ind i bagagerummet. Bagagerumsklappen smækker. En dør smækker og bilen sætter i gang.

Peter ved ikke hvor længe de har kørt da bilen endelig stopper. En bildør åbner og derefter åbnes bagagerummet. Peter bliver hevet ud af bagagerummet og sat på knæene på den kolde asfalt. Rystende spørger Peter … “Hvor er jeg?”… “Hvem er I?”… “Hvad vil I?” … men ingen svarer. Bildøren smækker og bilen kører væk i høj fart. Forvirret fjerner Peter bindet for øjnene …

Ideen om at mafiaen kidnapper en tilfældig på gaden og smider vedkommende af et ukendt sted er udgangspunktet for hvorfor Gangstertest har fået sit navn – det går i bund og grund ud på at finde et tilfældigt sted på hjemmesiden eller applikationen og så bede testeren om at finde ”hjem”. Undervejs skal testeren stilles spørgsmål som; hvilken type applikation det er, hvad man kan her, hvad applikationens primære formål er, hvorhenne i applikationen man er, hvordan strukturen er, hvor og hvordan søgefunktionen fungerer osv.

Til Gangstertest kan du selvfølgelig godt selv være testeren, men det kan være svært at distancere sig selv fra ens eksisterende viden om systemet/hjemmesiden – du kan sammenligne det med, at det jo er dig der har kørt bilen og ikke lå bundet i bagagerummet.

Kortsortering

En anden metode til at teste navigationen på en hjemmeside er kortsortering. Kortsortering går helt kort ud på at skrive alle menupunkter ned på små lappe papir. Der må ikke være nogen indikation på om det er et overordnet menupunkt eller en underside punktet omhandler. Derefter skal testeren, gerne en der ikke er bekendt med hjemmesiden, forsøge at stykke menuerne sammen igen. Kortsortering kan give fint input til om menupunkter er navngivet sigende og om strukturen har en logisk opbygning.

Hvilken metode du ender med at anvende, afhænger af både projektets art, kravene til brugervenlighed og testen, og hvornår i projektet testen skal afvikles. Er der ikke tid eller penge til en stor test, så gennemfør en i en mindre skala i stedet.

Hvorfor?

Det sidste spørgsmål som måske trænger sig på nu, er nok; Hvorfor? Usability test er som nævnt ofte en meget subjektiv test, men brugt rigtigt så kan den give meget stor værdi, især tidligt i projektet, og med relativ få midler. Det behøver ikke at være en dyr test foretaget af et specialiseret firma - en simpel gennemgang af et flow vha. grove tegninger eller prototyper, kan sagtens afdække huller i både viden og designet. Der findes en stor mængde bøger og sider hvor du kan finde inspiration til din usability test – jeg kan anbefale at starte med bogen ’Usability – Test methods for making usable websites’[1] - den beskriver nogle af de metoder jeg har beskrevet mere udførligt.

Til svaret på hvorfor, hører det med at der især indenfor det offentlige er krav om brugertest og brugervenlighed og til borgervendte løsninger også er krav om tilgængelighed for brugere med funktionsnedsættelse. Det er ikke alle løsninger, der er optimeret til brugere med funktionsnedsættelse af en eller anden art, men for offentlige systemer der er borgervendte, er der som regel krav om hvilket niveau af WCAG[2] standarden som siden skal leve op til. Der findes firmaer der er specialiseret i at teste det, men grundlæggende set skal der overvejes følgende i testen;

-        Hvordan er strukturen synlig

-        Overvej brugen af grafik, de fleste programmer der kan læse tekst op, kan ikke læse tekst der står i billeder eller andre steder i grafikken

-        Overvej brugen af både keyboard og mus – det skal være muligt at klare sig med udelukkende den ene eller den anden

Der er en masse andre større og mindre ting der kan overvejes, og jeg anbefaler at undersøge kravene til tilgængelighed grundigt.

Endelig så er forventningen til brugervenlighed på hjemmesider og applikationer i dag langt større end det har været tidligere. IT, hvad end det er hjemmesider eller andre applikationer, er ikke længere primært arbejdsredskaber til brug uden for hjemmet, og vi er ikke længere lige så tålmodige eller tilgivende. Det skal virke med det samme og vi skal ikke tænke så meget over hvordan det virker, selv fru Hansen er efterhånden vant til et ret højt niveau af brugervenlighed, så når en løsning ikke er det, slår det ekstra hårdt – det skal være intuitivt forståeligt og let at bruge – ellers finder vi en anden løsning.



[1] Af Ole Gregersen og Ian Wisler-Poulsen

[2] WCAG står for Web Content Accessibility Guidelines og kan læses her: https://www.w3.org/TR/WCAG20/

todo todo