11. T'ænke højt test Brug af konsulent

ROLF MOLICH - 200 (

11. T'ænke højt test Brug af konsulent testdeltageren ikke er i sin vante arbejdssituation, og fordi det sinker testdeltageren at skulle tænke højt. Det er en fordel at søge sa&~yndig konsulentbistand til gennemførelsen af de første test, fordi en uerfaren testleder ofte begår en række fejl, der kan fomrindske testens nytteværdi væsentligt. 11.1 Oversigt ''Tænke højt" I en tænke højt test får en testdeltager, som er en typisk bruger, stillet 6-20 realistiske opgaver af en testieder. Mens testdeltageren løser opgaverne, skal han "tænke højt", dvs. han skal sige, hvad han tænker på, hvad han er itvivl om, hvad hlm forventer webstedet gør nu, hvordan han fortolker en fejlmeddelelse, osv. Dialogen skal testes, ganske som koden Ikke meninger men konkret adfærd T est kan ikke bruges til tidsmåling Alle erfah1e udvik\ere ved, at første version at et web-sted altid indeholder en lang række syntaktiske og logiske fejl. På samme måde forholder det sig med brugergrænseflader: Ligegyldig hvor omhyggelig man har været med sin udformning, vil der altid være nogle alvljrlige og uforudsete uhensigtsmæssigheder. Dette og det følgende kapitel beskriver nogle simple og effektive teknikker. som kan afsløre sådanne uhensigtsmæssigheder. I mange tilfælde giver teknikkerne også fingerpeg om, hvordan de fundne ploblemer løses. Grundholdningenbag de beskrevne teknikker er, at vi ikke interessel er os ret meget for hvad brugere mener - eller for den, sags skyhl, hvad udviklere eller salgsfolk eller brugerveillighedseksperter mener. Erfaringen viser. at sådanne meninger er temmelig værdiløse. Derimod interesserer vi os meget for bruge:nes adfærd i konkrete, realistiske situationer. Testteknikkerne er nødvendige, fordi erfaringen desværre viser, at brugere ikke af sig selv kommer og fortæller om problemer. Det kan der være mange grunde til, f.eks. "det kan nok ikke være anderled~,s" eller "det er nok mig, der er dum". Det kan også være, at organi~;ationen bevidst eller ubevidst giver udtryk for, at kritik er uønskd. Tidsmålirig af brugervenlighed, som er omtalt i kapitel 2, kan normalt ikke foretages i forbindelse med en test, fordi Varighed Testopgaver Tænke højt test Tænke højt test har stor spændvidde. Den kan anvendes til at teste begynderes første møde med et web-sted. Den kan anvendes til at~ teste web-stedet med erfarne brugere, når det har været i drift et stykke tid og f.eks. står over for en revision. Den kan anvendes på et helt web-sted og på udvalgte sider. Den kan anvendes på prototyper og på web-steder, som er i produktion. En test varer normalt 60-100 minutter. Hvis man f.eks. undersøger et web-sted for en bank, kan testdeltageren være en bankkunde, som har et rimeligt kendskab tin nettet. Opgaverne kan f.eks. være U1 - Find telefonnummer og åbningstid for nærmeste filial. - Hvor meget kan du få i rente på en børneopsparingskollto? En tænke højt test består af følgende trin: l. Forberedelse: - Etabler et godt samarbejde med projektgruppen. - Skriv testplan. - Fastlæg tid og sted for testen. - Udvælg og informer testdeltagere. - Udforrn testopgaver. - Vælg dataopsam1ingsmetode. - Hold generalprøve på testen og revider derefter testen. 2. Gennemførelse: - Forbered testen. - Modtag testdeltager. - Udspørg testdeltageren om hans forventninger til web-stedet. - Lad testdeltageren løse opgaver. - Diskuter med testdeltager (eftersnak, debriefing). 122

-724 3. KornmLnikation af resultater: - AnalYf,er data. - Diskuter resultater med projektgruppen. - Rapporter resultater. - Opføl!;ning. Disse trin e, detaljeret beskrevet i de følgende afsnit. Projektgruppen rådgiver, bl.a. om testopgaver lo Lad projektgruppen medvirke aktivt ved udarbejdelsen af testopgaverne. Udarbejdelse af testopgaver tvinger projektgruppen til at anskue web-stedet fra brugerens synspunkt. Det er ofte lsig selv en ny og lærerig øvelse for projektmedarbejderne. Testopgaverne af testlederen. gennemses og godkendes af typiske brugere og Udpeg testleder 11.2 Forberedelse Start med at udpege en testleder. Testlederen bør være neutral i forhold til det web-sted, som skal testes. Man kan ikke teste sit eget barn. Testledereli bør selv have prøvet at være testdeltager i en test. Det er vigtigt, at han er fortrolig med testdeltagerens rojle. Desuden bør en testleder en gang om året udføre test under overvågning af en kyndig træner Projektgruppen bør overvære testene " Lad projektgruppen udarbejde profilefi1e for testdeltagerne, dvs. beskrive testdeltagernes kvalifikationer. " Inviter projektgruppen til at overvære testene - alle bør overvære mindst to test. Hav kolde pilsnere og snacks parat. Læg så vidt muligt testene på tidspunkter, som er bekvemme for ud viklerne. " Bed projektgruppen tage noter, mens de overværer testen. Lad projektgruppens noter danne grundlag for rapporten. Lies mere på side 139, Sådan opnår du fælles fodslag om resultaterne. Aftal formålet med testen på forhånd Sælg testen til udviklerne 11.2.1 Etabler et godt samarbejde med projektgruppen En perfekt test, hvis resultater bliver ignoreret, løser ingen problemer. Arbejdet med at "sælge" resultaterne af testen starter fra det øjeblik, hvor det bliver besluttet at gennemføre testen. Inden du udfører en test, bør du aftale med ledelsen og med den projektgruppe, der er ansvarlige for web-stedet, hvad resultaterne skal bruge,; til Nedskriv aftalen i en testplan (se side 125, Skriv testplan). Mange teknisk vellykkede test er blevet fiaskoer, fordi man ikke f,å forhånd havde gjort sig klart, hvad resultaterne skulle bruges til Andre gange er det gået galt, fordi de udvikjere, der, skulie implementere resultaterne, ikke var taget i ed, og alene derfor synles, at resultaterne var tåbelige. Her er nog le konkrete ting, som du bør gøre: " Giv dig god tid til at forklare projektgruppen, hvad testen går ud på. ])e færreste udviklere ved, hvad en "test af brugervenlighed" er for noget. Varighed: 60-100 minutter 11.2.2 Skriv testplan Skriv en kort testplan, dvs. en slags kravspecifikation for testen. ' Testplanen, som bør have et omfang på 1-2 sider, beskriver f) Formålet med testen. Det web-sted eller del af web-sted, som testen omfatter. " Profil for testdeltagere.., Hvad resultaterne skal hruges til. 11.2.3 Fastlæg tid og sted for testen En test af brugervenlighcd tage!' normalt GO-IOn minuttcr inklusive modtagelse og eftersnak. Det er en god ide at placere test med to timers melleinrum - så er der tid til at testlederen kan slappe en' smule af, og til at de udviklerne, der overværer testcn, kan få læst testene. deres e-maij. Der er også tid til at bringe udstyret i orden mellem Gør projektgruppen.til dine allierede ved at forklare dem, hvad de får ud af testen: Ros fra brugere, færre ændringsønsker, færre udviklingstimer spildt på ting, som alligevel ikke bliver brugt. Valg af teststed Mange kvalificerede testdeltagere kan kun at deltage i test efter kl. 16. Derfor er det ofte nødvendigt at teste i perioden kj. 16-20. Hvis testen ikke kan foregå på brugerens normale arbejdsplads, skal den foregå et sted, som ikke virker alt for teknikfikseret. Alt for megen teknik (terminaler, videokameraer, båndoptagere, mikrofoner, osv.) har en stressende effekt på mange mennesker.

Ii Testlokale 1\ Observationsrum I et mødelokale på det sted, hvor projektgruppen holder til. Denne mulighed gør det så let som muligt for projektgruppen at overvære en eller flere test. De kan endda komme og gå som det passer dem, hvis de kan iagttage testen fra et nabolokale. lo I et specialindrettet testcenter (se figuren på foregående side). Denne mulighed er god, hvis testen skal videooptages. Men den. er hverken hensigtsmæssig for testdeltager eller projektgruppe:. Sted / Test af brugervenlighed Q I tesldeltagerens hjem. kan gennemføres Bru~; denne mulighed, hvis omgivelserne skal være så naturlige som muligt for testdeltageren.. Ved testdeltagerens sædvanlige arbejdsplads. Den.le mulighed er velegnet, hvis testdeltagerne ikke har tid til transport til teststedet. I et mødelokale på testdeltagerens arbejdsplads. Denae mulighed er velegnet, hvis testdeltagerne ikke har tid til transport til teststedet. // Testeenter: Hvis en test af brugervenlighed skal videooptages, sker den bedst i et testcenter ("usability lab"), der kan være indrettet som vist i denne figur. Kameraerne (K) i testlokalet viser testdeltagerens ansigt, tastaturet og dokumentationen. Observationsrummet er adskilt fra test lokalet med en lydisoleret væg med envejsspejl, så observatørerne kan se testdeltageren, mens testdeltageren blot ser et ~;pejlbillede af sig selv. Monitorerne i observationsrurnrnet. (M) visijr kamerabillederne og det miks, der videooptages. Den store monitor på væggen deltage'rens skærm. (B) gengiver billedet på test Udviklmne sidder sammen med testlederen i observationsrumme.t. Udviklerne kan også sidde iet separat lokale, som ikke er vist på figuren. Testlederen kan sidde sammen med testdeltageren i testlokalet - så virker det ikke så unaturligt for testdeltageren at tænke højt. har travlt og har travlt og Fastlæg målgrupper Her kan du finde testdeltagere Frivillige testdeltagere Antal testdeltagere Vurder testdeltageren ud fra svar på konkrete spørgsmål 11.2.4 Udvælg og informcr tcstdcltagere Testlederen opstiller sammen med projektgruppen en oversigt over de målgrupper, der skal testes. Brug målgruppeoversigten som udgangspunkt. Ideelt set skal web-stedet testes af alle målgrupper. I praksis tester man sjældent andre end de primære, og i mange tilfælde er der kun ressourcer til at teste en målgruppe. Deltagerne i en tænke højt test kan f.eks. være co Dine egne bekendte: arbejdskolleger, venner, familie. Virksomhedens egne medarbejdere. " Personer, som et marketingbureau fremskaffer. Vikarer fra et vikarbureau. Testlederen bør sikre, at han får et repræsentativt udvalg af typiske 1'0 testdeltagere, hvad angår alder, erfaring og motivation. --..:J Hvis du anvender lutter frivillige testdeltagere, så kan rekrutteringen blive skæv. Du får urealistisk højt motiverede og åbne testdeltagere. Her kan vikarer fra et vikarbureau være nyttige, hvis de tilhører målgruppen. Der skal være mindst tre testdeltagere fra hver målg~~ppe. Min _ erfaring er, at seks testdeltagere er optimalt. Hvis du bruger færre testdeltagere, kan du let komme til at overse vigtige problemer. Hvis du bruger. flere end seks testdeltagere, vil du opdage at når den 7.,8. osv. testdeltager åbner munden for at sige noget, så ved du på forhånd præcis, hvad han vil sige. Testdeltagere er ikke altid gode til at vurdere deres egne kvalifikationer. Derfor er det vigtigt, at en potentiel testdeltager får stillet konkrete spørgsmål, som han kun kan besvare, hvis han tilhører målgruppen. Eksempler på spørgsmål om web-erfaring: - Hvad bruges knappen Tilbage (eller Back) i browseren til? - Hvad hedder den browser, som du anvender? 126 127

( JV'JIIWIIIIIIOlJlOtlU 11111111111111110111 Informer testdeltagere Videooptagelse Database med testdeltagere Genbrug af testdeltagere Testdeltagere kan også være overkvalificerede. Imange test er det f.eks. uhensigtsmæssigt at anvende testdeltagere, som selv har prøvet at udvikle web-steder. Ved udvælgelsen kan du stille kontrolspør,~smål, som kun overkvalificerede testdeltagere kan svare på. H'Iis en person kan svare på disse spørgsmål, er han måske ikke velegnet som testdeltager. Eksempler på spørgsmål af denne type:. - Hvad er elllitml-tag? _ Der står ell tekst på ca. 600 linier i din browser. Hvordan vil du finde alle forekomster af ordet "forsikring" i denne tekst? En brugers ulyst til at deltage i en tænke højt test skal naturligvis respekteres Desværre siger brugere sjældent udtrykkelig fra. En brugers uly:;t viser sig typisk ved, at han gentagne gange kommer med undskyldninger for ikke at kunne deltage (for travlt, andre aftaler, osv,). Her må testlederen være på vagt. En testdeltbger, som skal deltage i en test, vil naturligt være i tvivl om, hvad det skal foregå. Derfor er det en god ide at afmystificere testen ved H sende testdeltageren et kort brev umiddelbart efter, at Ihar aftalt hans deltagelse i testen. Brevet afmystificerer testen ved at forklare testens formål. Brevet understregtr, at det er web-stedet og ikke brugeren, der skal testes. Hvis du øn:;ker at videooptage testdeltageren under testen, er det vigtigt, at du siger det til testdeltageren og skri ver det i brevet. Nogle testdeltagere ønsker ikke at deltage i test, hvor de videooptag,~s. Hvis der er udarbejdet en skriftlig orientering om web-stedet eller brugerdokumentation, som brugeren forventes at læse i forvejen, skal den også vedlægges. Men erfaringen viser, at mange, testdeltagere ikke får tid til at læse dokumentationen inden testen ganske som i en reel brugssituation! Næsten allt: testdeltagere synes, at det er interessant at deltage i en tcst af brugervenlighed. De får mulighed for at arbejde med ny, spændende teknologi, og som en testdeltager sagde til mig: "Det er sjældent at nogen gider høre på mig uafbrudt i 90 minutter". Det er nemmere at overtale en person, som tidligere har deltaget i en test, til at møde op til en ny test, end det er at finde en helt ny testdeltager. Hvis du gennemfører mange test af brugervenlighed, er det derf(jr en god ide at føre lister over, hvem der har deltaget i test. Husk at notere testdeltagernes kvalifikationer. "Vi tester webstedet, ikke dig" Afmystificer testen. Forklar hvad der skal ske "Vi tester webstedet, ikke dig" (igenl) Anonymitet Gave Eksempel på brev til testdeltager: Kære Erik Nielsen. Tak for dit tilsagn om at deltage i en test af et web-sted for forsikringsselskabet Selandia. FormAlet med testen er at finde ud af om web-stedet er let og behageligt at bruge. Formålet er ikke at vurdere dig eller dine evner. Testen foregår hos onsdag den 28. juli kl ; ~6. 00 Selandia Bygmarken 4 4000 Roskilde Du bedes henvende dig i receptionen. Jeg kommer og henter dig på det aftalte tidspunkt. Testen kræver ingen forberedelse fra din side. Testen tager ca. 90 minutter. Ved testen fungerer jeg som testleder. Jeg kommer fra det uafhængige firma DialogDesign. Ved testen vil jeg bede dig løse en række konkrete. opgaver ved hjælp af Selandias web-sted. Mens du løser opgaverne skal du "tænke højt", dvs. forklare hvad du er i tvivl om, hvad du synes er godt, hvad du synes er dårligt udformet osv. Kun på den måde kan vi' forstå hvilke dele af designet, der volder brugere problemer, og hvordan disse problemer kan rettes. Situationen under en test kan måske virke lidt eksamensagtig. Men husk: Hvis nogen er til eksamen, så er det ikke dig, men dem der har lavet web-stedet. Hvis dem der du har ikke lavet kan finde web-stedet, ud af web-stedet, som har et problem. så er det I ~ (X) DialogDesign garanterer din anonymitet. Udenforstående får kun oplyst din omtrentlige alder og stilling men hverken dit navn eller din adresse. Det er muligt at en eller to medarbejdere fra Selandia ønsker at overvære testen for at få et førstehånds indtryk af brugeres mening om web-stedet.,, Disse medarbejdere har strenge ordrer om at forholde sig passivt under testen. Som tak for din ulejlighed modtager du en gave. Du kan vælge mellem tre flasker god rødvin eller gavekort på 150 kr. til Fona eller Magasin. Hvis du har spørgsmål, er du velkommen til at kontakte mig på nedenstående telefonnummer. Med venlig hilsen, DialogDesign Rolf Molich 129

11.2.5 Udi orm testopgaver ViI'tlJ, HI tllhlj,lollth hl 1 IlIitu,II. ' 'tt HI lilfll "'" I 'I IH fil 1111 rondkdllg~;:-10h;kah. t.g alllau ~~II,d\1t1HI 1IIIitilti'll~ ulll '1IllllllllIdlh Ilt i det selskab, hvis wt:b-stcd skallcst<.:s. Test helheden Brugere bedømmer et web.sted på grundlag af den samlede oplevelse. Hvis der f.eks. er tale om en web-butik, omfatter den samlede oplevelse betaling, bekræftelse, information om evt. leveringsproblemer og modtagelse af varen. Selvom web-dialogen er god, kan kundeservicen være elendig. Mange test stopper desværre på det tidspunkt, hvor brugeren skal til at betale. Derved får vi ikke en væsentlig del af oplevelsen med, f.eks. kan brugeren finde ud af at betale? Kan han finde ud af at holde øje med leveringsdatoen? Hvordan opfatter brugeren elektroniske nyhedsbreve og tip om gode tilbud? Realistiske opgaver Se kritisk på brugeropgaver Teknikken kræver, at der udarbejdes en række realistiske opgaver, som testdeltagerne skal løse ved hjælp af web-stedet. Testlederen udarbejder opgaverne. Testlederen bør indbyde projektgruppen til at deltage i dette arbejde for at projektgruppen kan blive aktivt engageret i testen som beskrevet på side 124. Testlederen skal sikre, at web-stedet testes med typiske opgaver. Opgaverne skal tage udgangspunkt ibrugeres behov og ikke i webstedets mellupunkter. Fastlæg opgaverne uden at se på web-stedet. Et af formt lene med testen er netop at finde ud af, om web-stedet kan gøre dl: ting, som brugere har behov for. Brugeropgaverne kan være et godt udgangspunkt (se side 43). Husk, at projektgruppen kan have o "erset eller nedprioriteret arbejdsopgaver, som er vigtige for brugere. Brug af personlige oplysninger I forbindelse med helhedstest er der et moralsk problem: Kan man bede testdeltagere, som man ikke kender i forvejen, om at indtaste deres personlige adresse og bruge deres Dankort eller internationale betalingskort til at betale en vare som led i en test? Også selvom du tilbyder at refundere alle omkostninger? Eksempler på testopgaver Her er et opgavesæt, som jeg flere gange har brugt på kurser til at teste DSBs web-sted, www.dsb.dk. 1. Find DSBs web-sted. 2. Du skal fra Høje Tåstrup til Aarhus på fredag til et møde. Mødet starter kl. 12.30, og der er ca. 15 minutter med taxa fra banegården til mødestedet. Hvornår skal du køre fra Høje Taastrup?!i 3. Hvad koster en returbillet? 4. Kan du bestille en pladsreservation på web-stedet? Hvis ja, så gør det, og få reservationen sendt til din privatadresse. Skjult hjælp Drejebog Søg inspirhion til testopgaver ved at spørge dig for hos typiske brugere _ gerne hos venner og bekendte, hvis de er typiske brugere. Lcd et par typiske brugere gennemse og kommentere opgaveme. Derved sikrer du, at opgaverne bliver forståelige og realistiske. Opgaverne skal overholde en række simple regler. De må for eksempel Lcke indeholde skjult hjælp. Se boksen "Uheldige testopgaver" nedenfor. Opgaverne kan kædes sammen i en drejebog, dvs. en historie, der mere eller.nindre realistisk begrunder opgaven. Det kan f.eks. 5. Du skal besøge noget familie i Fåborg. Hvornår kan du være fremme hvis du kører fra Kbh. kl. 8? 6. Du bor i Kolding og overvejer et job i Odense. Udskriv en samlet køreplan for strækningen Kolding-Odense. Opgave 1 er standard ved alle mine test. Det er jo en katastrofe, hvis brugere ikke kan finde web-stedet. Opgave 5 og 6 er realistiske, men vanskelige for web-stedet. Web-stedet kender ikke forkortelsen Kbh. og det har svært ved al forklare brugere, at der ikke længere går tog til Fåborg - kun bus. Opgave 6 kan web-stedet vistnok ikke klare. 130 131

Ingen "morsomheder" Skriftlige opgaver Første opgave skal yrere let Opgaver skal være realistiske. "Morsomheder" er malplacerede. Husk, at der er tale om web-steder for seriøst arbejdende mennesker. Opgaverne ~,kalforeligge skriftligt. Herved begrænser du påvirkningell fra testlederen under selve testen. Hver opgave skal stå på et separat stykke papir. Udlever opgaverne en ad gangen, så du nårsomhdst kan afslutte testen, uden at brugeren føler sig dårlig tilpas, fordi han ikke. nåede alle opgaverne. Den første (Jpgave skal være så let, at testdeltageren kan løse den på ganske fil minutter. Det er et psykologisk u1ck, som tjener til at afstresse te~tdeltageren. TestdeItageren får en hurtig succes og føler ubevicst "Nåh, det er jo ikke så slemt". Advarsel: Det er svært at lavl~en opgave, som en første gangs bruger med garanti kan løse på et par minutter. Den skal være meget lettere end testlederen tror! Uheldige testopgaver Her er nogle eksempler på uheldige testopgaver. I alle tilfælde var målgruppen den brede befolkning. 1. Test af BG Banks web-sted: "Hvad Biger BG Bank i sin seneste pressemeddelelse?" Problem: Opgaven er ikke relevant for målgruppen. Opgaven er derirnod relevant, hvis web-stedet testes med f.eks. journalister. 2. Test al Told og Skats web-sted: "Find ejendomsavancebeskatningsloven." Problem: Målgruppen kender ikke betegnelsen "ejendomsavancebeskatningsloven". Denne betegnelse er fagsprog og skjult hjælp. Opgaven skal omlormes. så ordvalg og problemstilling er hentet Ira brugerens verden, f.eks. "Du har lige! solgt dit hus og tjent 300.000 kr. Skal du betale skat af det tjente?" 3. Test af Tryg-Balticas web-sted: "Anme!d en støjskade. Den er forårsaget af Sture Brage, Rabaloerstræde 12, 9999 Bulderby." Problem: Urealistiske data. Forsøg på at være morsom. Typer af testopgaver Der findes flere typer af t~stopgaver. Her er en oversigt med eksempler fra et web-sted, der sælger hårde hvidevarer: 1. Find kendsgerning "HVad koster mikrobølgeovnen Samsung M1753?" 2. Foretag personlig vurdering "Opfylder mikrobølgeovnen Samsung M1753 dine behov?" 3. Sammenlign kendsgerninger "Find den billigste mikrobølgeovn, som kan rumme en dybfrossen pizza." 4. Sammenlignende personlig vurdering "Find den mikrobølgeovn i butikken, som bedst opfylder dine behov." Testopgaver af type 1 er enkle at udarbejde, men testopgaver af type 2-4 er ofte mere realistiske set fra testdeltagerens. synspunkt. Bemærk, at svarene på opgave 2 og 4 afhænger af entydigt testdeltageren. svar. En god testopgave behøver ikke at have noget 11.2.6 Vælg dataopsamlingsmetode CN CJ En tænke højt test behøver ikke at kræve særlig megen teknik. Som den ene yderlighed kan du sidde ved siden af testdeltageren og notere på et stykke papir, hvad han siger og gør. Som den anden yderlighed kan du videooptage skænnen og testdeltagerens kommentarer og handlinger. ",

Papirnotater Båndoptagelser Videooptagelse Min eriarirg viser, at papimotater giver tilstrækkelige oplysninger. Se side 50, Notatteknik. Du kan også bruge båndoptager og mikrofon. Kontroller på forhånd, at lydkvaliteten er acceptabel. Placeringen af mikrofonen er kritisk. Uvedkommende lyde, f.eks. fra tastaturet, kan gå højt igennem p<ibåndet. Eventuelt kan du anvende en clipsmikrofon. Videoopta~.elser kan give problemer. Kun video optagere og monitorer af meget høj kvaliteter i stand til at gengive et normalt skærmbille,le læseligt. Forberedelse testen af 11.3 UCl1ncm fjjrdt>c Computer, web-sted og datagrundlag skal gøres klar i god tid, inden testen starter. Erfaringen viser, at testlederen ofte går for sent i gang med at forberede eo test. Det virker ikke befordrende for en afslappet stemning, at testen korrimer i gang med et kvarters forsinkelse og en stresset testleder, eller at testdeltageren i første omgang kommer til at arbejde med forkerte data. Kaffe, te, småkager, øl, vand, osv. kan bidrage til at skabe en afslappet stei1ll1ing. Brugeren skal give tilladelse til videooptageise Videooptagelser, der bruges til andet end hukonunelsesstøtte for testlederen, bryder med princippet om, at testdeltageren har ret til at være anonym. Hvis man kan genkende en testdeltager på en videooptagdse, som vises for andre end testlederen, skal testdeltagelen forinden have givet sin skriftlige tilladelse til fremvisningen på et stykke papir, der kort og letforståeligt forklarer, hvad optagelsen skal bruges til. Testdeltageren skal naturligvis kunne nægte at give tilladelse. En eller lo brugervenlighedsspecialister? Der kan være en eller to brugervenlighedsspecialister til stede under en test. Hvis der er to, kan den ene koncentrere sig om at tale med testdeltageren, mens den anden koncentrerer sig om at tage noter. Men det er kostbart - se diskussionen på side 146, Ressourcernæssige overvejelser. Checkliste før test Detaljeret analyse af video er tidskrævende Jeg fraråder video og ordret ne(jskrivning Inden du går i gang med lyd- eller videooptagelser bør du overveje, hvad du vil bruge de store datamængder til, som optagelserne giver. Der lindes mig bekendt ingen systematiske metoder til at analysere og uddrage relevant information fra sådanne optagelser, med et udbjtte, der står mål med den meget store analyseindsats. Jeganbefal~r hverken lyd- eller videooptagelse. Hvis du optager lyd eller video, så lad være med at lave en ordret nedskrivning af, hvad der bj..ver sagt. Det tager tid, og udbyttet er begrænset. Se i øvrigt diskussionen på side 146, Ressourcernæssige overvejelser. Test af forsikringsselskabet Selandias web-sted: 1. Velkomst. "Det er web-stedet vi tester - ikke dig". 2. Gennemlæs og underskriv Aftale om testdeltagelse. Fastlægger dine rettigheder og vore. 3. Personlige oplysninger. Brug spørgeskema. 4. Hvad er dit nuværende forsikringsselskab? - Hvis ikke kunde i Selandia: Har du hørt om Selandia? 5. Har du besøgt web-steder for forsikringsselskab~r? - Hvis ja: Hvilke? Hvad var din mening om web-steået? Pilottest Revision af test n.2.7 Hold generalprøve på testen Du bør holde generalprøve på din tænke højt test ved at gennemfør< en eller to pilottest. Efter pilottestene - men inden de egentlige test - skal du kritisk.vurdere op!.averne, testforløbet og din egen rolle. Testdeltageren i pilottesten bin give nyttige vink. De fejl, som pilottesten uvægerligt.lfslører, skal rettes. 6. Hvad vil du gerne finde på et forsikringsselsl(abs web-sted? ("Hvad ville være vidunderligt?") 7. Hvad ønsker du ikke at se på et forsikringsselskabs websted? 8. Instruks: Du får hver opgave udleveret af mig på et stykke papir. Mens du løser opgaven, vil jeg bede dig tænke højt. Det vil sige mig lidt om, hvad du overvejer. Når du mener, at du har løst opgaven, så giv mig opgavearkel tilbage. Hvis pilottesten afslører mange fejl, eller hvis du vælger at ændre opgavesættd radikalt, bør du overveje en ny pilottest. 9. Opgaveløsning. Fejl i opgaver Her er nogb eksempler på typiske fejl, som en pilottest kan afsløre: Første opgave for svær; testdeltageren misforstår opgaveteksten; irrelevante opgaver; relevante opgaver mangler; for mange opgaver. ]34 135

Modtagelse af testdeltager Spørg om forventninger løsning Eftersnak Gennemgå katastrofer af opgaver Indled test!:n med en uformel samtale om formålet med testen, testdeltagerens faglige og edb-mæssige baggrund, osv. Mange af de informationer, som kommer ud af denne snak, er nyttige ved vurderingen af testen. Spørg testdeltageren om hans forventninger til web-stedet. Stil dette spøresmå!, inden testdeltageren får vist web-stedets forside. En checkli3te sikrer, at du husker at stille alle relevante spørgsmål til testdeltlgeren. Udlever opgaverne til testdeltageren en for en. Kun hvis testdeltageren spørger, skal du fortælle, hvor mange opgaver der er. Hvis te.;tdeltageren ikke ved, hvor mange opgaver der er i alt, er det nemmere at afslutte testen, når tiden er udløbet, selvom testdeltageren ikke har nået alle opgaver. Hver opgave skal have et klart slutpunkt. Testdeltageren skal tydeligt mlrkere, når han mener, at en opgave er løst, f.eks. ved at give opgavearket tilbage til testlederen. Når testde!tageren har løst den sidste opgave, må du ikke bare sige tak og følge ham ud af lokalet. En eftersnak ("debriefing") er vigtig forlt finde ud af, hvordan testdeltageren opfatter webstedet. Eftersnakken undersøger bl.a., om testdeltagerens opfattelse af web-stedet er så god, at han kan drage slutninger om virkemådw af de dele af web-stedet, som han ikke har været i direkte kontakt med. For at du kan anbefale en god løsning på et problem er det ikke nok at vid~, hvad testdeltageren faktisk gjorde. Du må også prøve at finde ut! af, hvorfor testdeltageren gjorde det. Hvad han troede,.web-stede t gjorde osv. Det kan komme frem gennem, velovervejede spørgsmål (checkliste l) under eftersnakken. Igen er det testdeitageren, der skal tale, og dig, der skal lytte. Du må ikke falde for fristelsen til at demonstrere, hvor smart web-stedet er, og hvor nem: testdeltageren kunne have løst opgaverne. Se dine notater igennem under eftersnakken. Vend tilbage til hver af de steder, hvor testdeltageren gik istå. Bed testdeltageren komme n,ed forslag til, hvordan web-stedet kan ændres, så problemet ikke opstår for andre. Når testddtageren og du har fået diskuteret, hvorfor der opstod problemer, viser det sig ofte, at testdeltageren kan komme med gode forslag til, hvordan problemerne kan løses. Gave Undgå eksamensstemning Checkliste efter test Test af forsikringsselskabet Selandias web-sted: 1. Nu har du fået et overblik over Selandias web-sted. Har det indfriet dine forventninger (overgået, skuffet)? 2. (Hvis der var alvorlige problemer, så vis de web-sider, som forårsagede problemerne) Hvordan kan vi ændre web-stedet så disse problemer forsvinder? 3. Hvis du skulle give Selandia et par gode råd, hvad skulle det så være? 4. Er svartiderne på web-sted~t tilfredsstillende? 5. Hvordan opfatter du strukturen af forsiden? 6. Passer den designmæssige stil af web-stedet med din opfattelse af Selandia? 7. Forklar: Hvad bruger testleder disse resultaier til? Vi gennemfører flere test med forskellige personer. Mange gode ideer. Specielt interessant hvis flere siger det samme. 8. Var opgaverne realistiske? Manglede der noget vigtigt? 9. Har du lyst til at deltage ien sådan test en anden gang? 10.Udlever gave. Under eftersnakken vil det også være rimeligt at bede CJ-.I testdeltageren kommentere de stillede opgaver: Er opgaverne N realistiske? Hvilke to opgaver er mest/mindst relevante? Når testen er slut, kan du udlevere gaven til testdeltilgeren. Gaven er typisk et gavekort ener vin til en værdi af 150-300 kr. Vikarer fra vikarbureauer, som får løn for deres arbejde, får normalt ikke nogen gave. Medarbejdere, som udfører testarbejdet i arbejdstiden, får en symbolsk gave eller ingen gave. 11.3.1 Testlederens rolle Det er en stressende situation for en testdeltager at bli ve sat til at løse opgaver under overvågning. For at undgå "eksamensstemning" skal du sørge for, at testdeltageren oplever situationen som rolig og afslappet. Forhold dig neutralt og venligt. Du skal opfordre testdeltageren til at prøve selv. Hvis testdeltageren f.eks. spørger: "Må jeg klikke på det link?", kan du svare: "Prøv!" ener "Hvorfor er du i tvivl?", og ikke "Ja" eller "Nej". Du bør opmuntre testdeltageren til at fortælle om sine tanker og overvejelser ved spørgsmål som "Hvad /,

Afslut eller hjælp, når problemet er klart For tidlig hjælp Ubevidst, : I hjælp overvejer du nu?" eller "Hvad siger den meddelelse dig'!" eller "Hvad tror du def sker?". Afslut opgaveløsoingen eller hjælp testdeltageren, hvis han f.eks. siger "Nu yille jøg bruge telefonen for at få svar på dette spørgsmål', elle( hvis testdeltageren ikke kommer nogen vegne i f.eks. 5 millutter. Det har ingen mening at lade testdeltageren flakke rumit i m~re end et par minutter i en blindgyde, som han ikke selv km ko(l1ffie ud af. På den anden side er den hyppigste fejl ved tænke højt test, at testlederen hj~~lper Vrugeren for tidligt. Det skyldes typisk, at testlederen sylles, døter synd for testdeltageren, at han har problemer. Testdeltag'~re er imidlertid forbavsende opfindsomme og finder ofte efter kort tio en udvej fra håbløst udseende situationer. Hvis du hjælper for htlrtigt, kan vigtige detaljer gå tabt, og testdeltageren køn blive irriteret over, at han ikke fik lov til at prøve selv HjælPen kan også uforvarende komme til at anvise testdeltageren ej1anden strategi end den, han ellers ville have. fulgt. Tænk over, hvao du siger. EJJers kan du let komme til ubevidst at give testddtage(cn vigtige signaler om, hvordan opgaven skal løses. Eks,~mpel: Under test af en papirprototype sagde testlederen "... og nu hvor du har indtastet beløbet, så skifter Betal-knappen farve og bliver øktiv". Der var andre knapper, der samtidig skiftede farve, så t<;stdellageren blev klar over, at det nok var Betalknappen, han sl<ulle trykke på nu. Ofte er testdeltageren også selv ubevidst (offi del1 ubevidste hjælp fra testlederen. Problemerne med ubevidst hjælp er særlig store, når testdeltageren er tæt ved at have løst opgaven. Det er svært at undlade et næsten uhørligt, lilfrerl' suk eller et lille smil, når testdeltageren efter mange beiværljgheder har fundet det rigtige svar - og det mærker testdeltag~ren straks. Husk, at testdeltageren måske ikke selv er klar over, at haj1 har fundet svaret. Ubehagelige nyheder Tips om formidling al resultater Metode til at opnå fælles fodslag blllgclc, IICllllig Ild vildc. lic. I)c 1)1 IIgCI vcii1igljcd~lq)(:cllllltilljl, lit "" selv har prøvet at være udviklere, har en lille fortid [Ja tlettc p"llkt. Udviklere har travlt. Projektet er ofte forsinket i forvejen. Desuden tror mange udviklere, at netop deres web-sted vil bestå testen med lutter rosende kommentarer. "Dine testresultater bringer derfor næsten altid ubehagelige og dermed upopulære nyheder om yderligere forsinkelse, som projektgruppen helst er fri for at høre. Her er nogle gode råd: Overvej at bruge e-mai! til at kommunikere de vigtigste resultater hurtigt. ("Rigtige udviklere læser ikke rapporter"). Lever testrapporten hurtigt. Ideelt: Dagen efter sidste test. Rapporten skal være kortfattet og præcis. Det er ikke noget udtryk for dovenskab, at du leverer en rapport på "kun" 12 sider efter 50-100 timers arbejde. " Projektgruppen skal have testrapporten til kommentering, inden den bliver udsendt til andre, så eventuelle misforståelser kan blive rettet. Tilbyd at holde et møde med udvikleme, hvor I gennemgår kommentareme i fællesskab. " Efterlys udviklemes kommentarer ti! brugervenligheden af din rapportering - du kan også lære noget. 11.4.1 Sådan opnår du fælles fodslag om resultaterne Målet med en test af brugervenlighed er ikke at skrive en god rapport. Målet er at opnå fælles fodslag om hvilke problemer der er på web-stedet, og hvordan de bør rettes. Her er en metode, som du kan bruge til at opnå enig~e~: o Indbyd alle udviklere der har ovei'været mindst et par test til et møde. Afhold mødet umiddelbart efter den sidste test, f.eks. dagen efter. " Nedskriv observationer. Sælg resultaterne til projektgruppen Kend din bruger (udvikleren) 11.4 Kommunikation af resultater Når testen er gennemført skal du "sælge" resultaterne til projektgr'jpperj' Hvis udviklerne har overværet nogle af testene, går det olle nej11t.du kan opleve, at web-stedet ændrer sig under testene, fardi uoviklerne skynder sig at rette nogle af de værste problemer. Vi prædi Ker, al udviklere skal kende deres brugere. Tilsvarende skal vi, der arbejder med brugervenlighed, også kende vore Hver mødedeltager skriver sine observationer på papkort. Der skal stå en observation på hvert kort. Sørg for rigeligt med pap kort i AS format. Mødedeltagerne taler ikke sammen under dette punkt. Placer kortene på en væg. Hver mødedeltager placerer sine kort på væggen. Beklæd væggen med et stort stykke papir inden mødet. Brug f.eks. 5 m af en papirdug. Spray papiret med Post-it lim. Spraydåser med 138 139

Post-it lim fås hos farvehandleren. Du kan også notere observationerne på store, selvklæbende Post-it ark. Indholdet af en kommentar En testrapport indeholder normalt 20-50 konunentarer. For hver kommentar bør du angive: e Tilføj yderligere observationer. Lad mødedeltagerne studere hinandens forslag. Hvis en deltager derved kommer i tanker om yderligere observationer, kan lian også slå dem op på væggen. e Sort('r kortene. Alle deltagere pass,:nde grupper. arbejder sammen om at sortere kortene i Kategorier af kommentarer " Klassifikation - kommehtarens kategori (se nedenfor). Beskrivelse.. - " Antallet af brugere, som oplevede dette problem. e Løsningsforslag. Alle kommentarer i en testrapport bør klassificeres i en af følgende seks kategorier. " Godt. Omfang Indhold ElilT,iner dubletter. Hvis der er fuld enighed om, at flere kort beskriver samme observation, fjernes alle disse kort undtagen et. Hvis et kort beskriver et problem, som er en del af et andet problem, skal I beh{llde begge kort. e Sæt overskrifter på grupperne. Brug en anden farve kolt til overskrifterne. Resultatet er et godt grundlag for at skrive testrapporten. Testlederen fungerer som observatør under denne øvelse. Testlederen har lov til at komme med forslag til observationer, men det er mødedeltagerne, som har det afgørende ord. Denne metode hedder KJ-metoden Kawakita Jiro. 11.4.2 Testrapport El pas~ende omfang for en testrapport indholdsfortegnelse og appendiks. Sidem~ kan fordeles på følgende måde: Rewme - l side Melode, udstyr - I side. Profiler for testdeltagere - I side StiJlede opgaver - l side " Ko,nmentarer (se nedenfor) - 6-8 sider efter den japanske etnolog er 10-12 sider plus forside, Appendiks kan være på op til 20 sider. pel kan indeholde testlederens drejebog inklusive checklister samt 10-20 repræ~,entative billeder fra web-stedet. Disse billeder er nyttige for persor;er, som ikke kender web-stedet godt. De er også nyttige som hukonunelsesstøtte senere, når web-stedet er blevet ændret. Husk at rose Eksempler på testrapporter Denne måde at gøre tingene på syntes testdeltagerne godt om. Den kan tjene som forbillede for den videre udvikling. s Forbedringsforslag. Et forslag fra en testdeltager eiter testlederen, som kan medføre en væsentlig forbedring af brugeroplevelsen. Kosmetisk problem. Brugeren studser eller bliver sinket i op til et minut. Bør rettes ved lejlighed. Alvorligt problem. Brugeren bliver sinket væsentligt, dvs. i flere minutter. Problemet giver lejlighedsvis anledning til kataslrofer.. Kritisk problem (katastrofe). Giver anledning til hyppige katastrofer. En katastrofe er en situation, hvor web-stedet "vinder" over brugeren. Det kan C>.J være fordi problemet forhindrer brugeren iat anvende web- ~ stedet uden menneskelig hjælp, citer fordi problemet irriterer brugeren voldsomt, eller fordi brugeren misfmjstår web-stedel på et eller flere væsentlige punkter. Funktionsfejl. Web-stedet fungerer ikke korrekt: Stavefejl, Iinks fører ikke de rigtige steder hen, meddelelser resultater. om inteme fejl, ukoltekte Erfaringen viser, at det er nemmere at kritisere end at rose. Testrapporter, som indeholder ingen eller ganske få rosende konunenlarer, er vanskelige at sælge til ud viklerne. En tommelfingerregel er at stræbc. efter en rosende bemærkning for hver lo problemer. Pas på, at du ikke glemmer at rose, fordi du opfatter de vellykkede ting som selvfølgeligheder. Hvis du vil vide mere, kan du finde eksempler på professionelle testrapporter på web-stedet www.dialogdesign.dk., 1(1

11.4.3 Eksempler på kommentarer Eksempel på katastrofe, alvorligt problem og kosmetisk problem Katastrofe: Testdeltagere forstod ikke betydningen al de feller, som de udfyldte. Testdeltagere klagede over, at de ikke følte sig kvalificeæde til at benytte web-stedet på grund af manglende indsigt i lånes ager: Der findes en realkreditordbog på web-stedet. Den afujalp nogle af problememe, men de fleste testdeltagete vidste ikke, at den var der, og fandt den ikke. Katastrofe: Nogle testdeltagere indtastede beløbet som 250.000 (i stedet for 250000). Det fortolkede web-stedet som 250 kr. På grund af de faste gebyrer for lånesagsbehandling m.v. betød det, at lånet blev på ca. 10.000 kr. og derfor gennemskuede testdeltagerne ikke umiddelbart problemet, selvom en studsede "De er godt nok billige hos Nykredit!". Alvorligt problem: Førstegangsbrugere havde svært ved at gennemføre en låneprocedure, fordi de ikke forstod, hvad en lånesag er. En mulig løsning kunne være at udvikle en "Indføring lånesager for begyndere" og vise et tydeligt link til den. ' Kosmetisk problem: Tre testdeltagere foretrak tiltalefcirinen"du" i stedet for "De". En testdeltager sagde: "Jeg er dus med Vorherre!". Forbedringsforslag: To testdeltagere efterlyste en mulighed for at få vist en graf over udviklingen af f.eks. nettoydelsen o'ver hele låneperioden. Ros: Godt at man kan beregne lån. i II ')97 testede vi Nykredits web-sted. Dukan se et udsnit af låneskemaet fra web-stedet ovenfor. En typisk testopgave til dette låreskema er "Du skal bruge 250.000 kr. tit ombygning af dit hus. 1-hor meget vil lånet i alt koste dig pr. måned?"denne testopgave ga v bl.a. anledning til følgende ko(11!nentarer: Problemer ignoreres eller rettes forkert 11.4.4 Opfølgning Erfaringen viser, at testresultaterne i nogle tilfælde, bliver CN ignoreret I andre tilfælde bliver der foretaget reuelsei-, som ikke UI løser problemerne. Disse problemer kan skyldes, at du ikke har kommunikeret resultaterne godt nok til dine udviklere. De kan også skyldes, at udviklerne ikke har tid. '" LØsninger: () Sørg for at inddrage udvikleme og sælge resultateme godt til dem. Se afsnit 11.2.1 og 11.4. Brug ekspertbistand for at øge sandsynligheden for, at problemerne bliver løst. Test igen for at se om problemerne er løst. Behandl bruge'rvenlighedsproblemer på samme måde som ordinære funktionsfejl. Anvend det fejlrapporteringssystem for traditionelle funktionsfejl, som Isikkert har iforvejen. 143

F,}rebyg problemer snarere end at fjerne dem via test. Se ailbefalingeme i kapitel 3-9. 11.5 V ariant: Konstruktiv interaktion For nogle web-steder er nybegyndere ikke typiske brugere 11.6 Test med øvede brugere De anbefalinger, som står tidligere i dette kapitel, gælder først ~g fremmest ved test med pers~ner, som ikke tidligere har anvendt web-stedet. Men i mange tilfælde er brugere kun nybegyndere i ganske kort tid. Resten af tiden er de let Øvede eller Øvede, og får dermed andre behov. Det er derfor også vigtigt at teste med Øvede brugere.. Bestående web-sted Test med øvede brugere er relevant, når'du allerede har en kørende version af et web-sted, som skal forbedres. Nyt web-sted Tesi af et nyt web-sted med øvede brugere er vanskeligt, fordi der desvælte ikke findes nogen metode til hurtigt at producere erfarne brugere af et nyt web-sted. Du kan få en ide om eventuelle problemer ved at anvende udviklere eller brugere, som har deltaget i udviklingen af web-stedet, som testdeltagere. Tænke højt test med to brugere. Ulemper Nogle brugere er bange for at dumme sig over for kolleger Konstruktiv interaktion er en variant af tænke højt tesl. I kon:;truktiv interaktion arbejder to brugere sammen om at løse opgaver på web-stedet. problemerne med web-stedet vil så fremgå af d~res samtale. Korstruktiv interaktion atbøder det unaturlige i at tænke højt. At sidde to sammen og løse et problem og tale om det er en naturlig situ ltion for de fleste mennesker. Desuden er mange brugere vant til at lære af andre brugere. Derne teknik har følgende ulemper i forhold til almindelig tænke høj! test med en testdeltager: Det kan være svært at holde styr på brugemes problemløsnings- ~;trategier. Brugerne vil ofte springe mellem forskellige :;trategier. Disse strategier kan da blive sammenblandet på en måde, så det er vanskeligt bagefter at finde ud af, hvordan hver.,mkelt bruger har opfattet web-stedet..i nogle tilfælde kan de to brugere ikke arbejde sammen. Ol Nogle brugere bryder sig ikke om. at kolleger opdager huller i Jeres faglige viden, hvilket kan ske, når man bruger konstruktiv interaktion. Det genererdem derimod mindre, at en fremmed (testlederen) ser disse huller. til Teknikken kræver dobbelt så mange brugere, som kan være vanskelige og kostbare at skaffe. Kendetegn for øvede brugere Vigtige punkter ved les I med øvede brugere Karakteristisk for øvede brugere er De har et grundigt kendskab til web-stedet. De lægger vægt på effektivitet. " De lægger vægt på, at der optræder så få fejlsituationer som muligt. De har udviklet teknikker til problemløsning, når de kommer i en uvant situation. Test med øvede brugere adskiller sig fra test med nybegyndere på følgende punkter:. '" Bed kunder, undervisere og support om at udpege erfarne brugere. '" Bed hver testdeltager medbringe typiske eksempler på det arbejde han udfører med web-stedet - gerne i fomi af arbejdsdokumenter, formularer og udskrifter. '" Lad testdeltageren løse nogle af sine egne opgaver med webstedet (ud over de opgaver, som indgår i testen). " Fokuser på testdeltagerens erfaringer. Udspørg testdcltilgeren grundigt om - Typiske brugeropgaver. - Utraditionelle anvendelser af web-stedet. - Erfaring med web-stedets meddelelser, specielt fejlmeddelelser. - Brug af dokumentation. - Brug af hjælp. Vær opmærksom på, at nogle Øvede brugere har stærke meninger og står tøvende over for ændringer i et produkt, som de kender godt, og som de måske har bygget en del af deres kaitiere op III 145

omkring. Sådanne brugere kan måske umiddelbart have svært ved at se, hvad de får ud af at arbejde sammen med en specialist i brugerveillighed. 11.8 Etiske regler 11.7 Ressourcemæssige overvejelser " I Discount usability test Testcenter som synligt bevis på..brugervenlighed Når du planlægger test af brugervenlighed, skal du træffe en række vigtige bt:slutninger af økonomisk og ressourcemæssig art som f.eks. Rvornange test skal jeg gennemføre? " Skal t,~sten foregå i et testcenter eller i vore egne lokaler? lo Er vi bedst tjent med at indrette vores eget testcenter? Skal j~g videooptage testen? Skall.ver test overværes af en eller to brugervenlighedsspeci8lister (en testleder og en notetager)? Rvore an skal jeg analysere data? Disse sp~jrgsmål besvarer du bedst ud fra en omkostningsanalyse. For alle disse spørgsmål gælder, at udbyttet bliver større, jo flere ressource r du bruger. Min erfaring er imidlertid, at du opnår de bedste resultater ved at spare så meget som muligt på de enkelte test ("discount usability test"). BlUg de sparede ressourcer på at gennemføre flere testseriel. Altså: Gennemfør 4-6 test i egne mødelokaler uden videooptagelse og med en specialist. lndskrænk analysen til notetagning under testen. Derved er der nok nogle problemer, som du ikke får med fra de enkelte h~st. Pointen er imidlertid, at den brugervenlighedsmæssige kvalitet af de fleste nuværende web-steder er så ringe, at de probiernu', som du overser, alligevel ikke betyder ret meget. Du er 'bedre tje.lt med at have ressourcer til en konlroltest eller til en ekstra tef.tserie med andre teslspørgsmål. Disse øk1momiske overvejelser gælder kun til en vis grænse. Enkelte j irmaer har indrettet et testcenter primært for at vise, at direktionen lægger stor vægt på brugervenlighed. Test web-stedet, ikke brugeren Sige fra undervejs Anonymitet Ved tænke højt test arbejder du med mennesker. Du skal tage særlige hensyn under testen for at undgå situationer, der'er ubehagelige for testdeltageren. Dette afsnit beskriver en række simple forholdsregler, som sikrer, at både testleder og testdeltager føler sig godt tilpas under testen. En testdeltager kan føle, at han er til eksamen. Derfor skal du gøre testdeltageren klart, at det er web-stedet, som er til eksamen, og ikke testdeltageren. Det bør du gøre både i del brev, som testdeltageme får inden testen, og i den mundllige information. Hvis der er noget, som brugeren ikke kan finde ud af, skal du slå fast, at det er udtryk for fejl i web-stedet og ikke dumhed hos brugeren. Hvis testdeltageren føler, det er ubehageligt at delt~ge, skal han '..J kunne stoppe. Men det er uheldigt at fortælle testde'ltageren på forhånd, at han kan afbryde ("Er det virkelig så slemt, at jeg kunne få lyst til at afbryde?"). I øvrigt sker det meget sjældent, at en testdeltager synes, at det er ubehageligt at deltage i en test af brugervenlighed, så længe du følger de regler, som står i dennc bog. Testdeltageren bør have vished for, at testresultater kun videregives til udenfbrstående,herunder overordnede, på anonymiseret form. Det må ikke fremgå af testresultaterne, hvem testdeltageren er. Du bør også på forhånd have gjort de overordnede klart, at de ikke vil få udleveret oplysninger om en medarbejders præstation, men kun om web-stedets brugervenlighed. (N 146 147

5. Testlederen giver ubevidst hjælp. 6. Ingen eftersnak. Ingen udforskning af brugernes overordnede forståelse af web-stedet efter testen. 7. I sin rapport forstærker testlederen fundne problemer, som han er enig i, og undertrykker problemer, som han ikke er enig i. 8. Kommentareme i testrapporten er ikke kategodseret. Det er svært al skelne mellem kosmetiske problemer og katastrofer. 9. Resultaterne kommunikeres ikke effektivt til udviklerne. Testlederen skriver en rapport, som han "kaster over muren" ind til udviklerne. Sprogbrug - undgå "laboratorium" og "forsøg" Etiske regler: Må udviklere tænke tløjt testen udføres? være til stede i det lokale, hvor Det afh,:enger af deres temperament og vilje til at lære. Der finoes eksempler på, at udviklere har følt sig trådt på af "de dumme brugere" og har reageret voldsomt under selve testen. Til gen~læld har udviklernes personlige tilstedeværelse i selve testlokalet den fordel, at de kan føle, hvordan brugere reagerer på web stedet. Det kan de ikke føle via video eller gennem tykke glasrudar. Nogle udviklere nægter at godtage referater af, hvad der rent faktisk ~;kete under en test. Videooptagelser er heller ikke altid overbevisende'- udviklere ved, at de kan manipuleres. Hvis udviklere er iii stede, skal de have besked på at forholde sig fuldstændig passive ("holde kæft"). For de fleste udviklere vil det være vanskeligt at overvære en bruger med problemer uden at kunne hjælpe ham med al den viden,som de har om webstedets virkemåde.,pas på din sprogbrug, når du omtaler test af brugervenlighed. Undgå furmuleringer som "Tak fordi du vil deltage som forsøgsp,~rson i et eksperiment i vores laboratorium". Data er bedre end meninger Er dine meninger særlig gode? 10. Testrapporten indeholder meninger, dvs. problembeskrivelser, som alene bygger på testlederens personlige opfattelse. 11.9.1 Meninger Punkt 10 ovenfor fortjener en uddybende kommentar: Fakta er altid bedre end meninger. Dette udsagn er dikteret af politiske hensyn. Det er ikke en objektiv sandhed, for i mange tilfælde vil en erfaren brugervenlighedsspecialists meninger være mere effektive end en test af brugervenlighed - se side 150, Inspektion. Den politiske nødvendighed dikterer, at personlige meninger bør (N undgås ien testrapport, også selvom det tydeligt fremgår, at der erco tale om meninger. Det skyldes, at udviklere er vant til meninger. Hvis udvikleme blot opfatter testiederen som en ny spiller med et yderligere sæt meninger, som oven i købet bygger på nogle præmisser, som de ikke kan gennemskue, så forsvinder respekten for brugervenlighedsarbejdet. Det er vanskeligt at give et overbevisende svar på spørgsmålet "Hvorfor er dine meninger bedre end vores meninger?" 11.9 'fi typiske fejl De ti hyppigst forekommende fejl i tænke højt test er: l. Opgaverne er fjollede. 2. Opgaveformuleringerne giver ubevidst hjælp. 3. Test:ederen hjælper for meget eller for hurtigt - testen udarter til er demonstration af web-stedet. 4. Tcstedcrcn undlader at hjælpe, når problemet er klart. 1111 /49