Gør det selv - usability-test

Selve afviklingen af en test tager relativt kort tid. Til gengæld skal der bruges tid på omhyggelig planlægning, hvis man vil opnå et anvendeligt testresultat.

Gør formålet med usability-testen klart for dig selv

• Er det meningen, at du skal teste alle dele af et givent produkt, eller skal der fokuseres på særlige områder?
• Er udviklingsprocessen nået så langt, at der kun kan foretages kosmetiske rettelser i produktet, eller har udviklerne behov for grundlæggende strukturelle input? Måske skal testen foretages for at få ideer til indholdet af online-hjælp og manualer, eller for at få overblik over emner, der bør undervises i på kurser, hvor produktet introduceres.
• Er der elementer, som udviklingsholdet er særligt interesseret i at få brugernes feedback på?

Feltstudium inden usability-testen?

Opstil brugerprofiler

Det er derfor vigtigt, at du bruger tid på at opstille krav til hvilke brugere, det er relevant at invitere til testen. Hvem skal bruge produktet, når det er færdigt, og hvilke variationer i brugergruppens baggrund, bør der tages højde for? En klassisk variation, man næsten altid bør inddrage, er aldersforskelle. Ældre brugere reagerer anderledes på software end helt unge af flere forskellige grunde. Dels ser ældre typisk dårligere end de unge, dels har de grundlæggende forskellige erfaringer med teknologi.

For at kunne udpege de rette brugerprofiler er det en god idé at opstille en liste over aspekter, der kan variere inden for målgruppen:

• Alder
• Køn
• Uddannelse
• Arbejdsopgaver og/eller viden om det domæne test-programmet eller -web-stedet tilhører
• Generel it-erfaring
• Erfaring fra brug af programmer eller web-steder, der minder om det produkt, der skal testes eller fra brug af tidligere versioner af produktet.

En typisk udviklerreaktion på et kritisk testresultat er, at du har udvalgt urepræsentative brugere. Sørg derfor for at få udviklingsholdets accept af brugerprofiler og af de indkaldte brugere før testen afvikles!

Antallet af testpersoner

Der er ingen grund til at bestræbe sig på straks at finde 100% af alle problemer i et givent produkt, fordi der altid vil skabes nye problemer i det øjeblik, man går i gang med at udbedre de problemer, man opdagede i første testrunde. Hvis man ønsker at sende et velfungerede produkt på markedet, er det derfor mest hensigtsmæssigt at gennemføre en efterfølgende testrunde med 5 nye brugere i stedet for at invitere 10 brugere til én eneste testrunde.

Du bør være meget opmærksom på, at de statiske beregninger er lavet ud fra en antagelse om, at brugergruppen er homogen. For mange produkter er dette ikke tilfældet, og i så fald bør man principielt set teste med 5 brugere fra hver hovedgruppe. Fx kan et web-site være henvendt til både brugere og tekniske administratorer, og deres behov vil være så forskellige, at man ikke kan betragte dem som én gruppe.

En eller to testpersoner ad gangen

1. For brugerne er det som oftest en mere behagelig oplevelse at deltage i en test et fremmed sted med en fremmed testleder, hvis de følges med en kollega eller ven.
2. Man har ikke nævneværdige problemer med at få brugerne til at "tænke højt", når de sidder to sammen foran computeren; de snakker helt naturligt med hinanden.
3. Testlederen kan antage en langt mere observerende rolle, idet brugerne kan hjælpe hinanden, når der opstår problemer, og de kan stille opklarende spørgsmål til hinandens handlinger. Der er således mindre usikkerhed mht. at vurdere, om testlederen har påvirket brugerne til et bestemt resultat.

Invitér testpersonerne

Vær sikker på, at testpersonen forstår, at du ikke vil teste hans evner til at betjene en computer, men derimod designet af dit produkt. Ellers risikerer du, at mange brugere takker nej på forhånd eller får en dårlig oplevelse. Man bør også under den indledende samtale få gjort det helt klart, hvorvidt brugeren skal være testperson alene eller sammen med en kollega eller ven.

En typisk misforståelse beror på, at testpersonerne tror, at de er blevet inviteret til at deltage i et kursus. Understreg derfor, at det ikke er hensigten, at du vil demonstrere produktet, tværtimod er det meningen, at testpersonen selv skal foretage en afprøvning. Samtidig bør du dog berolige med, at du vil træde til med en hjælpende hånd undervejs, hvis det er nødvendigt.

Efter telefonsamtalen bør du sende et brev eller en e-mail til testpersonen, der gentager alle de oplysninger, du har givet mundtligt. Sørg for at dato, tidspunkt og adresse fremgår utvetydigt. Hvis du har et fotografi af det lokale, usability-testen skal foregå i, kan det være en idé at indsætte det som en del af brevet, så testpersonen på forhånd kan danne sig et indtryk af omgivelserne.

Test i brugskonteksten, i lab eller i et almindeligt kontorlokale

En test i et lab har den fordel, at det er muligt at lade alle interesserede udviklere følge testene. Under en test i konteksten kan man normalt kun tillade sig at være to personer, dvs. ud over testlederen kan der kun deltage én udvikler. Det er også muligt at gennemføre flere test på kort tid, når der anvendes et lab, fordi du ikke selv skal transportere dig rundt imellem testpersonernes adresser.

Hvis du ikke har adgang til et lab, er det muligt at leje lab-faciliteter til at gennemføre egne test. Du kan også vælge at gennemføre en test uden brug af lab-teknologi. I så fald har du bare brug for et kontorlokale, der er udstyret med en pc (husk netadgang, hvis det er et web-sted, der skal testes). Det er vigtigt, at testen kan foregå uforstyrret, og noget så simpelt som at sætte en seddel op på døren, hvor der står, at man ikke vil forstyrres, kan gøre en stor forskel. Overvej om en eller to interesserede udviklere kan sidde diskret i lokalet for at opleve testpersonens reaktioner.

Video eller ej?

Som testleder kan du have glæde af videooptagelserne som supplement til dine noter. Samtidig kan du forbedre din kompetence som testleder ved at observere dine egne handlinger og måden du kommunikerer på.

Testopgaver og testdata

Testopgaver udarbejdes på brugerens præmisser, dvs. de skal være typiske eksempler på opgaver, som brugeren løser i sin hverdag. Opgaverne bør absolut ikke være lavet med udgangspunkt i de funktioner, som systemet understøtter. Hvis du har lavet feltbesøg, vil det normalt være nemt at formulere realistiske opgaver.

Når du formulerer opgaven, så sørg for at give den en sandsynlig ramme, som brugeren i en eller anden udstrækning kan genkende fra sin hverdag. Du skal ydermere være opmærksom på at undgå at give ubevidst hjælp til opgavens løsning via dine formuleringer. Se eksempel på en god og en dårlig testopgave.

Hos UNI-C Usability betragter vi i stadig stigende grad testopgaver som en sekundær løsning. Man kommer alt for nemt til at teste, om brugeren kan betjene systemet, frem for hvorvidt systemet understøtter brugernes opgaver. I stedet benytter vi såkaldte interviewbaserede opgaver.

Denne testform er behandlet grundigt i en tidligere artikel i Designværkstedet: "Bring brugssituationen ind i testen: Interviewbaserede opgaver og opgavesortering".

Hvad enten du benytter den ene eller den anden slags opgaver, er det af afgørende betydning, at testpersonen anvender realistiske testdata under arbejdet med prototypen eller det færdige produkt. Testdata er noget som typisk levnes meget lidt eftertanke; det skal laves i en fart, og ofte vælger man den humoristiske tilgangsvinkel.

Desværre har det ofte katastrofale følger for testresultatet. Testpersonerne får problemer med at betjene systemet, fordi de fx ikke kan omsætte "Anders And" og adressen "Andeby" til navn og adresse på en kunde. Husk på, at for brugeren er det centrale ikke selve systemet, men derimod de oplysninger, det indeholder. Hvis brugeren skal kunne gøre brug af sin kompetence under testen, er det vigtigt, at han genkender ting, som han kan overføre kompetencen på. Det betyder ikke, at man fx skal benytte en kopi af test-personens kundekartotek, blot at de testdata, der stilles til rådighed tydeligt ligner et kundekartotek. Dybest set handler det også om at udvise respekt; humoristiske testdata kan opfattes som en latterliggørelse af testpersonens arbejde.

Lav planer: tidsplan og drejebog

• Lav en grundig tidsplan der viser hvilke brugere, der kommer hvornår samt deres kontaktadresser. Det er vigtigt at kunne komme i kontakt med brugerne, hvis de ikke møder op til den aftalte tid.
• Lav en drejebog for den enkelte test. Drejebogen indeholder interviewguide til det indledende interview, testopgaver og/eller opmærksomhedspunkter, der skal bruges under selve testen samt en interviewguide til det afsluttende interview.

Sørg for at aftale på forhånd, hvorvidt udviklerne og andre interessenter fra projektholdet skal deltage i testen eller ej. UNI-C Usability har kun gode erfaringer med at involvere personer, der har aktier i det produkt, der skal testes. Det er langt nemmere at diskutere designproblemer, hvis alle har set med egne øjne, at testpersonerne havde svært ved betjene det eksisterende design.

Slutteligt skal man huske de praktiske ting så som:

• Have gave eller betaling klar til brugere som tak for deres ulejlighed.
• Sørge for forplejning til testpersonen (som minimum drikkelse - man bliver tør i halsen af at "tænke højt").
• Udforme blanketter der skal underskrives, hvis der er optaget videofilm.
• Hvis testen foregår i din egen virksomhed, så sørg for at orientere receptionen om at du får gæster, så der kan blive taget venligt imod testpersonerne.
• Have blanke videobånd klar, hvis der skal laves videooptagelser.
• Fjerne data som evt. er indtastet under pilottesten.

En usability-test består normalt af fire etaper: velkomst og præsentation, indledende interview, selve testen og endelig et opfølgende interview.

Velkomst og præsentation

En test starter med, at du byder testpersonen velkommen og prøver at afdramatisere situationen - gerne vha. lidt almindelig snak om emner, der ikke er beslægtede med testen.

Finder testen sted i et lab, er det vigtigt, at du viser testpersonen rundt, inden testen starter, så han er klar over, hvad der kan ses og høres fra tilstødende lokaler. Videooptages testen, er det ligeledes vigtigt at vise, hvad der kommer med på filmen.

Det er også væsentligt at introducere samtlige tilstedeværende personer samt deres roller, så testpersonen er klar over, hvem hver enkelt er. Fx er det vigtigt at vide, at én person har den opgave at nedskrive alt, hvad der bliver sagt og gjort undervejs (logning), så testpersonen ikke undrer sig over, hvad det er, der bliver noteret.

Brug herefter lidt tid på at gentage formålet med testen for brugeren og fortæl, hvordan du forventer, at det hele vil forløbe: først et indledende interview, dernæst selve testen og endelig et afsluttende interview. Understreg igen, at der ikke er tale om en test af brugerens viden og it-kvalifikationer; i stedet er det de tilstedeværende udviklere og systemet, der er til eksamen.

Hvis det er en prototype, der skal testes, er det vigtigt at gøre det klart, at eventuelle problemer, der måtte opstå undervejs ikke skyldes fejlbetjening, men derimod at systemet ikke er færdigudviklet. Sørg i det hele taget for at gøre det helt klart, hvad en prototype er.

Indledende interview

Det indledende interview skal bruges til at få præciseret, hvem brugeren er, og hvilket kendskab han har til det område, testsystemet dækker. Omhandler testen fx et færdigt web-sted er det vigtigt at vide, om brugeren tidligere har været inde og prøve web-stedet, så du kan medregne dette under analysen af testresultaterne.

Såfremt du ønsker at anvende interviewbaserede opgaver, benyttes det indledende interview til at formulere opgaverne i samarbejde med brugerne. Opgaverne laves på baggrund af opgaver, som brugere tidligere har prøvet at løse inden for det område testsystemet dækker.

Selve usability-testen

Testseancen begynder med, at du introducerer tænke-højt-metoden. Mange folk vægrer sig umiddelbart ved at skulle tænke højt, så derfor er det vigtigt, at du understreger, at du nok skal hjælpe med at holde snakken i gang. Næste artikel i denne serie handler om, hvordan du konkret håndterer selve testledelsen, dvs. holder dialogen med testpersonen i gang, imens han løser testopgaverne, uden at du kommer til at styre testen.

Testen består helt grundlæggende i, at testpersonen løser opgaver vha. testsystemet.

Afsluttende interview

Når testpersonen har været igennem systemet, har løst opgaverne, eller tiden er ved at være gået, er det væsentligt at samle op på testen sammen med testpersonen.

Indled med at spørge til testpersonens oplevelse af testen. Blev hans forventninger opfyldt? Man kan med fordel få testpersonen til at uddybe sin holdning ved at bede ham om at nævne de tre mest positive og de tre mest negative oplevelser, han har haft med testsystemet. Det giver ham mulighed for at lave sin egen udlægning af testforløbet. Sørg for at testpersonen ikke brænder inde med vigtige spørgsmål eller kommentarer.

Det er imidlertid ikke kun testpersonen, der skal snakke. Det er vigtigt, at du som testleder laver en kort opsummering af de ting, du har fundet vigtige i testforløbet. Ofte oplever testpersonerne større problemer undervejs i testene, og det kan derfor være en stor lettelse, når testlederen fortæller, at de områder, der har voldt kvaler, faktisk er områder, der er behæftet med væsentlige usability-problemer. Det viser, at man som testleder har taget testen og dermed brugeren meget alvorligt, og at det er systemet - ikke brugeren - der har været til eksamen.

Byder lejligheden sig, kan du med fordel spørge testpersonen, hvordan han synes, det var at deltage i testen - Det kan du lære af! Det er fx vigtigt at vide, om der var der dele af testen, som forekom svær eller mærkværdig. Hvis du har mulighed for det, så overvej at sende et brev til testpersonen efter testen, hvor han kan udtale sig om oplevelsen efter at have haft lejlighed til at reflektere over den. Mange kommer i tanker om ekstra kommentarer, når de er kommet hjem. Det virker normalt bedst at sende et spørgeskema, hvor der indgår talrige fritekstfelter.

Testen afsluttes med, at du takker brugeren for hans tid og hjælp. Hvis dit projekt tillader det, kan du vise din taknemmelighed med en mindre gave eller et gavekort. Vær forberedt på at brugerne ofte vil have at vide, hvornår systemet er færdigt, og - hvis det er et web-sted - hvilken web-adresse, de kan finde web-stedet på.

1. Jakob Nielsen: "Usability Engineering"
2. Joseph S. Dumas, Janice C. Redish: "A Practical Guide to Usability Testing"
3. Jeffrey Rubin: "Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests"