Se kilde til Tænke Højt Test

Tænke højt testen er muligvis det mest effektive værktøj, når man skal teste brugervenligheden af en hjemmeside. Det vigtigste ift. brugervenlighed er at målgruppen er i stand til at navigere rundt på siden uden problemer. Det er derfor også vigtigt at testpersonerne passer med hjemmesidens målgruppe, for at testen skal kan vi brugbare resultater.  

Navnet i sig selv siger en del om hvordan testen foregår, at det helt centrale i metoden er at testpersonen tænker højt - det kan faktisk også være noget af det der er lidt problematisk i testen. Testen går ganske enkelt ud på at testpersonen får stillet en opgave, fx at vedkommende skal finde en bestemt artikel. Testpersonens skal så "tænke højt" omkring de overvejelser som personen gør sig. 

[[fil:Think-aloud.jpg|right|thumb|300px|[http://ux.hellogroup.com/methods/sample/think-aloud ux.hellogroup.com/]]]
[[fil:Think_aloud.png|right|thumb|300px|[http://www.ac4d.com/ ac4d.com] ]]
__TOC__
Tænke højt testen er som sagt anset for at være blandt de bedste testforme til usability, både fordi resultaterne altid er brugbare, og fordi det er en meget simpel og billig test at udføre.<ref>http://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/ Fra Jacob Nielsens NN-Group</ref>. Metoden er udviklet af C.L. Lewis i 1982, mens han arbejdede ved IBM<ref>http://www.slideshare.net/antarleena/think-aloud-protocol-a-reflection Slideshow om Think Aloud</ref>

Typisk vil man anvende tænke højt testen i udviklingen af et bruger interface<ref>[http://grouplab.cpsc.ucalgary.ca/saul/hci_topics/tcsd-book/contents.html Beskrivelse af udviklingsprocessen for et brugerinterface] Task-Centered User Interface Design: 
"A Practical Introduction"
skrevet af Clayton Lewis and John Rieman</ref>.

==Specielt for testen==
Det er vigtigt at man anvender '''rigtige brugere''' til at teste sit produkt med. Det nytter ikke noget at man tester et program, der skal anvendes af børnehavebørn, ved at få rutinerede programmører til at teste det. Det er her at målgruppen kommer ind i billedet. 

Når man tester skal man stille nogle '''realistiske''' opgaver til brugeren. Man skal være opmærksom på at man får gennemtestet de centrale dele af produktet, og at man også tillader brugeren at komme ud i de hjørner af produktet, hvor der måske er nogle svagheder. Dvs. at hvis hjemmesiden er en webshop, så kan man teste indkøbskurvens funktionalitet. 

Som navnet siger skal testpersonen/brugeren '''Tænke Højt''', det kan godt være lidt akavet for testpersonen, eller de glemmer det undervejs i testen, så de skal lige hjælpes til fortsat at tænke højt.

For at testen skal være valid (at man kan regne med man får testet produktet bedst muligt), så er det vigtigt at man kun observerer brugeren. Man må '''ikke påvirke''' dem på nogen måder, give hints eller lignende, da det vil kunne skjule nogle eventuelle fejl i produktet. Testpersonen kan måske også finde andre måder at løse problemet på, and man selv havde forestillet sig. Man skal også lade testpersonen komme på afveje, da det kan være vigtigt at se hvad der sker, når man kommer ud i nogle hjørner man ikke havde forventet, og om brugeren evt. kan finde tilbage igen.

Det er altså vigtigt kun at hjælpe, hvis det kan bidrage til testen (hjælpe over et punkt, når man har fået set klart hvad der er galt, så man kan gennemføre resten af testen).

For at kunne bruge testen til noget skal man optage det (evt. notere).

==Miljø==
Når man skal lave test generelt, men også tænke højt test, så er den første overvejelse man skal gøre sig, hvilket miljø testen skal foregå i, og mest af alt om det skal være en felt-test eller om det er bedst at lave laboratorie-test.

===Felten===
Hvis man vil teste i Felten er der både fordele og ulemper:
*En fordel er at man fåe en evaluering i den situation og sammenhæng, teknologien skal benyttes i
*Der er samtidig fokus på brugen af produktet
*Der er så til gengæld den ulempe at der kan være mange faktorer kan påvirke resultater
===Laboratorium===
Tilsvarende hvis man vil teste i Laboratoriet er der igen fordele og ulemper:
*Evaluering i laboratoriet er fjernt fra den virkelighed, hvor teknologien skal benyttes
*Der kommer langt mere fokus på systemet eller apparatet, hvilket kan være både en fordel og en ulempe
*Man har langt bedre styr på de variable faktorer der kan påvirke en test
*Men man skal være opmærksom på at det er en kunstig situation

Nogle gange giver det sig selv hvordan man skal teste. Forestil jer at teste kørselsfunktionen i en GPS i laboratorium, mens det er noget andet med en hjemmeside

==Simpel metode==
Det at gennemføre en Tænke Højt test kan gøres meget avanceret med testlaboratorie og alt muligt, men man kan også få rigtigt meget ud af at test ved hjælp af simple midler, hvis man bare har en smule omtanke.

Hvis det blot er et program eller en hjemmeside man skal teste, så kan det gennemføres med en bærbar PC og et gratis program.

Det kan være en stor fordel at gennemføre testen i et '''roligt lokale''', så testlederen kan have fuld koncentration om testen, og testpersonen ikke bliver distraheret og kan få lov til at tænke højt, uden at det virker mærkeligt.

Fordelen ved at anvende en '''Bærbar PC''' er at der normalt er indbygget en mikrofon, så man kan optage lyden af det testpersonen "tænker højt", og hvis man ydermere vil have optaget testpersonens ansigtsudtryk, så vil der også tit være indbygget webcam. Ansigtudtryk kan i visse tilfælde være godt at have med, men er på ingen måde nødvendigt for en succesfuld/brugbar test. 

For at lave '''optagelsen''' af brugerens interaktion med PC'en og samtidig optage lyden, så kan gratisprogrammet [[CamStudio]] fint anvendes. Alternativt så kan man bruge et simpelt Video-kamera hvor man optager skærmen, men det kan tit være svært at få den samme opløsning, så man kan se præcist hvad der sker. Hvis testpersonen ikke har det godt med at blive optaget, så kan man nøjes med at tage '''noter''', men det kan ikke anbefales, da man ikke får muligheden for at gå tilbage og kigge en gang til, hvis man overser et eller andet, eller er i tvivl om hvad der sker. Der er en optagelse af skærmen rigtig god.

Typisk vil det ud over testpersonen være nok at have en '''Testleder''' der kan sørge for at rammerne for testen bliver holdt. Vedkommende skal være så godt inde i det der testes, at man kan hjælpe igennem, hvis noget kikser helt, men man skal huske på at det er nødvendigt at være meget '''passiv''' og neutral, så længe det kan lade sig gøre. Selvom testpersonen fumler noget rundt, så kan man få meget ud af det - det er faktisk der man får mest ud af usability test. Det vigtigste testlederen skal gøre er at skabe trygge rammer og så huske testpersonen på at '''udtrykke''' sine tanker højt, da man herved får en information om hvad der kan gøres bedre.

For at sikre at man får testet de relevante ting af, så skal man anvende nogle '''opgaver''' som testpersonen skal kunne løse i det produkt der testes. Opgaverne er beskrevet senere.

==Testlaboratoriet==
[[Fil:test-rum.png|frame|right|Skitse af et testrum, med angivelse af funktioner]]

Hvis man skal lave mange tests, og hvis man vil gå meget videnskabeligt til værks, så kan det være en fordel at have et specielt indrettet testlaboratorie, som kunne indrettes på den måde der er skitseret her til højre. Det skal ikke nødvendigvis se ud som vist, men det illustrerer nogle af de muligheder det er godt at have.

Til en normal test vil der kun være 2 personer i anvendelsesområdet. Der skal selvfølgelig være brugeren / test-personen, der betjener det udstyr der skal testes, og så testlederen, der er den overordnede person som skal styre testens forløb. Det kan være en fordel om testlederen kan kommunikere med en af observatørerne, også på en måde så det ikke forstyrrer testpersonen.

For ikke at distrahere testpersonen vil vinduerne ind til observatørerne normalt være forsynet med envejs-glas, så man kan se hvad der sker inde i testrummet. Gardinet foran det lille observatør-rum er der, så man kan indrette det til testrum, og udføre to tests samtidigt, hvis man ellers kan være der i observatørrummet.

Hvor mange observatører der skal være er noget afhængigt af hvad man vil have ud af testen, og hvilket udstyr det er man tester på, men i det primære observatør-lokale vil der typisk være tale om følgende funktioner:
* En videooperatør, der sørger for at der bliver optaget af alt hvad der er relevant. Det kan være en skærm, brugerens hænder, brugerens ansigtsudtryk. Det er vigtigt at videooperatøren holder styr på at billederne bliver skarpe og at det man ønsker at observere er i billedet (kameraerne er normalt fjernstyrede). Desuden skal operatøren sørge for at alt optages med synkroniserede tidskoder.
* Loggerens opgave er at sikre at der bliver logget alt hvad der er relevant, f.x. indtastninger, lagring af data osv. og igen at der er synkronisering med tiden.
* Tidtageren har det overordnede ansvar for at alt bliver logget synkront, samt at andre tidsmæssige hændelser bliver noteret.
* Andre observatører kan alt efter det testede produkt være relevante i observatørrummet.

Hvis man ønsker det, så kan der også være et formål i at anvende det lille observatørrum til nogen der ikke direkte trækker data ud af processen, men som i stedet oplever hvordan testen forløbet. Det kan typisk være produkteksperter, udviklere, investorer, eller andre former for observatører, der kan få noget ud af at overvære testen, og som skal have mulighed for at snakke sammen, uden det skal forstyrre de forskellige operatører.

Det er selvfølgelig ikke en billig sag at opsætte sådan et testlaboratorie, specielt ikke med alt optageudstyret, så mange firmaet vil leje sig ind ved steder der udbyder denne service, eller udnytte at universiteter har den slags faciliteter. Det vil også kun være nødvendigt med så omfattende et setup, hvis det er en meget omfattende og stor test der skal udføres.

==Opgaver til testen==
For at kunne gennemføre en tænke højt test, så skal der formuleres en række opgaver som testpersonen skal udføre. Det er vigtigt at disse opgaver bliver udformet således at man får testet produktet ordentligt igennem.
* Det siger sig selv at man skal teste de '''relevante''' dele af produktet.
* Hvis man har en fornemmelse at at produktet har nogle '''svagheder''' så skal man afteste disse svagheder.
* Det kan lyde banalt, men man skal teste det brugeren anvender. Hvis dele af produktet bliver anvendt meget, så er det vigtigst at teste disse dele specielt effiktivt, og måske i forskellige situationer, da det er vigtigst at disse dele er meget brugervenlige.
* Testen skal udformes i brugerens sprog. Det skal være reelle opgaver at testpersonen skal løse, og ikke bare en instruktion i hvad testpersonen skal gøre. Ellers har testen ingen værdi.
* Testen skal være formuleret i målgruppens sprog. Hvis man vil teste om brugeren kan vedhæfte billeder i et mailprogram, så skal man bede testpersonen om at sende to fotos til en adresse, i stedet for at bede dem om at sende en mail med to billeder vedhæftet.

==Vigtige roller==

Der er forskellige roller i et testforløb, som man skal have styr på

===Test-personen===
Det er personen der skal teste det produkt man ønsker at lave usabilitytest på.

Test-personen skal udvælges inden for målgruppen til produktet, og her er der ikke kun tale om alder og social status. Hvis det f.x. er et program der skal anvendes af sygeplejesker, så giver det ingen mening at lade en maskinarbejder testet programmet, fordi maskinarbejderen sandsynligvis mangler den faglige viden der skal til for at forstå hvad man skal bruge programmet til.

På den anden side må man heller ikke anvende testpersoner der er for dygtige. Hvis man vil teste om et program er brugervenligt, så duer det ikke at tage en test-person som er ekspertbruger på 3 lignende programmer, så finder man nemlig slet ikke de fejl man ønsker at finde.

===Test-leder===
Test-ledern skal have '''overblikket''' over hele forløbet. Det vil typisk være test-lederen der tager imod test-personerne, byder dem velkommen, og får dem til at føle sig godt tilpas - det kan måske være lidt ubehageligt for nogen at være i et laboratorie-miljø, med så mange personer der iagttager en.

Under selve testen har test-lederen til opgave at sikre at testen forløber bedst muligt under de givne forhold.
* Test-lederen skal skabe '''tryghed'''. Det er vigtigt at understrege at hvis der er noget man ikke kan finde ud af, så er det fordi produktet ikke er lavet ordentligt.
* Normalt skal et produkt kunne fungere uden at man har en hjælpende person lige ved hånden, så test-lederen skal være '''tilbagetrukket'''.
* Det er vigtigt af test-lederen kun hjælper minimalt, og det skal kun være hvis testen kommer på afveje, og test-lederen skal '''ikke korrigere''' før man har fundet ud af hvor problemet ligger henne i produktet.
* Test-lederen skal være '''fleksibel''' under forløbet. Der kommer altid et eller andet uventet, som man skal tage stilling til i situationen og kunne kompensere for.
* Det er test-lederen der skal få testpersonen til at tænke højt, og også være opmærksom på det under forløbet, hvor man kan hjælpe processen ved at stille små afklarende spørgsmål som f.x. "hvad tænkte du da det vindue kom frem", hvis test-personen bare arbejder videre uden at kommentere vinduet.

===Udviklerne===
En del steder et det specielt uddannede personer der laver usability test, og det er godt nok, for de er rigtigt gode til det.

Man skal dog ikke glemme at det er udviklerne der skal rette de problemer man finder, så der kan være meget værdi i at have en god kommunikation mad udviklerne, og måske endda tage dem med på rå omkring hvad der skal testes, og hvordan man evt. kan gøre det.

Det er også udviklerne der skal kunne forstå hvilke problemer der er fundet i testen af produktet, så det er godt at man kan tale et fælles sprog.

En god ting, der til tider kan være en øjenåbner for udviklere er at lade dem overvære et test-forløb. Det kan godt være de syntes at brugerne er dumme, men når den tredje bruger har problemer med at betjene produktet det samme sted i testen, så vil de normalt kunne indse at de godt kunne lave det anderledes, og måske endda allerede på det tidspunkt kan komme op med ideer til hvordan tingene kunne løses.

==Anvendelse af testen==
Når man har gjort et stort stykke arbejde med at lave en analyse, så skal man selvfølgelig også anvende de resultater man finder til at forbedre usability med, ellers giver det ingen mening at lave arbejdet.

Man skal tage brugerens reaktion alvorligt – selvom man i første omgang kan syntes at det er da brugeren der er dum, når de ikke kan finde ud af at bruge produktet, så skal man tænke anderledes. Det er produktet der fejler, eller i det mindste kan laves bedre, så brugeren har lettere ved at bruge det - det skal man så arbejde på efterfølgende.
===Antal Testpersoner===
Austin Center for Design har lavet meget omfattene forsøg vedrørende Tænke højt testen, og de har blandt andet fundet ud af, at man skal have op mod 15 testpersoner, for at identificere majoriteten af usability-problemerne på en hjemmeside. De har opstillet grafen ude til højre, til at vise tendensen.<ref>http://www.ac4d.com/classes/201_open/03.AC4D_IDSE201_ThinkAloudProtocol.pdf Think Aloud user testing - Austin Center for Design</ref>
[[fil:Statistic_ta.png|right|thumb|500px|[http://www.ac4d.com/classes/201_open/03.AC4D_IDSE201_ThinkAloudProtocol.pdf Statistik over antallet af testpersoner i en Tænke højt test] ]]

===Analysen===
Selve det at analysere usabilityproblemer fra et sæt brugertest kan være et stort arbejde.

Det man jo skal er at identificer brugbarhedsproblemer, der viser sig i de tests man har lavet, og det gør man ved følgende proces:
*Man foretager en video-analyse, hvor man kan se/høre på brugerens tænke højt, at der er noget der er svært at bruge.
*Man ser om man kan identificere nogle af de samme problemer i log-filerne
*Man sammenholder det med tiderne der er registreret
*Man foretager en kategorisering af problemerne, om det er katastrofer, alvorlige problemer eller kosmetiske fejl, således at man kan prioritere det i den videre udvikling.
*Det hele dokumenteres i en usability rapport, så udviklerne kan bruge det til at rette op på fejlene

Ovenstående proces kan være ret omfattende. Selv om man er rutineret, så skal man regne med en faktor 6-10 for at dokumentere, hvilket betyder at de tests man har kunne lave i løbet af en dag, de tager 6-10 dage at dokumentere.

===IDA===
Som alternativ til det har man på Aalborg universitet udviklet en metode IDA, hvilket står for Instant Data Analysis <ref>http://people.cs.aau.dk/~jesper/pdf/conferences/Kjeldskov-C23.pdf Test og analyse på en dag - Aalborg universitet</ref>, hvor man afsætter ca. 2 timer efter brugertestene til at man i gruppen af test-leder og observatører laver en hurtig kategorisering af hvilke brugerfejl man fandt - gerne ved at bruge whiteboard til en slags mindmap. I processen anvender man de optagelser til at understøtte de ting man er i tvivl om, så man får en rimelig valid identifikation. Dokumentationen vil så være et billede af mindmappet samt evt. de dele af videoer og andre data der understøtter de fundne problemer.

Processen er ikke helt så systematisk, og det kan sagtens være at man overser noget, men normalt er det mest kosmetiske fejl man overser, så i forhold til at omkostningerne måske er en femtedel - hvilket kan gøre at man kunne lave en test senere, når man har rettet de fundne problemer.

===RITE===
Rapid Iterative Test and Evaluation er en videreudvikling fra Tænke Højt, eller nærmere betegnet, så indgår tænke højt som et element i metoden.

Ideen er at man udfører et kort test-forløb med måske bare 3-5 testpersoner, og ud fra disse resultater laver man forbedringer, hvorefter man laver et nyt testforløb og forbedrer ud fra det. Denne proces kan forløbe ret hurtigt, specielt hvis rettelserne laves på et relativt tidligt stadie i udviklingen, hvor det er til at rette på tingene endnu. Denne proces fortsætter indtil man er tilfreds med produktet.

Elementerne i navnet er:
*Rapid - at man hurtigt kan foretage nogle test-forløb og lave rettelserne
*Iterative - at man tilnærmer sig iterativt det optimale produkt
*Test - at der indgår test i metoden
*Evaluation - at man løbende evaluerer produktet hen gennem forløbet

===Evaluering af test===
Efter testen kan det være en god idé at samle op på resultaterne vha. af en SUS (System Usability Scale) score. Det er et simpelt skema, hvor testpersonen skal tage stilling til, i hvor høj grad vedkommende er enig eller uenig. Følgende udsagn skal person tage stilling til:<ref>http://www.measuringusability.com/sus.php Measuring Usability With The System Usability Scale (SUS)</ref>
*Jeg regner med at bruge dette system jævnligt.
*Jeg mener dette system er unødigt kompliceret.
*Jeg syntes systemet er nemt at bruge.
*Jeg vil tro jeg får brug for en teknikers hjælp for at kunne anvende systemet.
*Jeg syntes at de forskellige funktioner i systemet fungerer godt sammen.
*Jeg syntes at der var for mange forskellige måder at betjene systemet på.
*Jeg kunne forestille mig, at de fleste brugere hurtigt vil kunne lære at bruge dette system..
*Jeg syntes systemet var besværligt at anvende.
*Jeg havde god tillid til systemet og brugen af det.
*Jeg vil være nødt til at lære meget, for at kunne anvende dette system.

==Andre Metoder==
Selve tankegangen i at bruge Tænke Højt kan også anvendes lidt i andre sammenhænge end blot at teste det færdige produkt.

Et sted hvor det har været anvendt med stor succes er i forbindelse med udvikling af programmer og websites helt i starten på idestadiet, hvor man kun har en papir-model, og en ide om hvad der skal ligge bag ved af kode, men endnu ikke har skrevet en eneste programlinje.

Rent praktisk kan det foregå ved at man har lavet nogle skitser af hvordan man forestiller sig at det skal se ud, og så "spiller" en opgave / et forløb igennem, og tænker højt hvad man forventer der skal ske i programmet og hvordan man kunne tænke sig det skal se ud. Man kan så rette og tilføje til skitserne og med papirlapper og gule sedler ind over beskrive hvordan produktet skal se ud og optage funktionaliteten på video, så man på denne måde får opstillet en kravspecifikation til det produkt man ønsker at fremstille.

==Referencer==
<references />
[[Kategori:Usability Hjemmesider]]