Titel: DSB lige til? Tema: Virkelighed og modeller Projektperiode: P1, 6. oktober 17. december Projektgruppe: B334. Synopsis: Deltagere:

2

Titel: DSB lige til? Tema: Virkelighed og modeller Projektperiode: P1, 6. oktober 17. december Projektgruppe: B334 Deltagere: Synopsis: Martin Langbak Mette Larsen Morten Holst Niels Wittrup Andersen Nino Tiainen Ole Kallehave Rasmus Eriksen Vejledere: Keld Petersen Thessa Lindof Rapporten omhandler www.dsb.dk, og hvorvidt web-stedet er brugervenligt i forhold til dennes brugergruppe. For at undersøge dette, har vi har brugt en metode, der tager udgangspunkt i brugeren og dennes færden på web-stedet. Der er udført tester med fem personer i et brugervenlighedslaboratorium, vi selv har opsat, til en tænke højt test. Gennem metoden er det blevet belyst, hvor der er fejl på web-stedet, og hvor DSB kunne drage nytte af ændringer. Undersøgelsen af www.dsb.dk har vist, at der er nogle katastrofale fejl ved webstedet, som bevirker, at det ikke fungerer optimalt med henblik på billetbestillingsdelen. Oplagstal: 15 Sideantal: 100 Bilagsantal og -art: 9 dokumenter + 1 cd Afsluttet den 17-12-2003 3

1 Indledning...6 1.1 Læsevejledning...7 1.2 Problemanalysen...7 1.3 Problemformulering...8 1.4 Problemafgrænsning...8 1.5 Målgruppe...8 1.6 Valg af testpersoner...8 2 Teori...11 2.1 Rammemodel...12 2.1.1 Donald Normans Konceptuelle modeller...12 2.1.2 Lisbeth Thorlacius Visuelle kommunikationsmodel...14 2.1.3 Den implicitte afsender...17 2.2 Hvorfor brugervenlighed...18 2.3 Brugervenlighed...19 2.3.1 Katastrofer...20 3 Metode...22 3.1 Metode til test af brugervenlighed...22 3.2 Tænke højt metoden...23 3.2.1 Testens forskellige roller...25 3.3 Databehandling...29 3.3.1 Analyse af data...32 4 Beskrivelse af de valgte web-sider...36 4.1 www.dsb.dk...36 4.2 Generelt design for www.dsb.dk...37 4.3 www.dsb.dk/indland...38 4.4 www.dsb.dk/netbutik...40 4.5 www.dsb.dk/orange...41 4.6 Billetbestilling...42 4.7 Mini sitemap...44 5 Analyse...46 5.1 Indledning til analyse...46 5.2 Demografiske spørgeskema...46 5.3 Resultatopsummering af analyse...47 5.3.1 Klassificering af problemer...51 5.4 Analyse af problemer i tænke højt testen...53 5.5 Analyse af post test spørgeskema...60 5.6 Analyse af debriefing-interview...62 5.7 Delkonklusion...65 6 Konklusion...70 7 Perspektivering...74 8 Metodekritik...76 9 Kilde kritik...77 10 Litteraturliste...80 11 Bilag...82 4

5

1 Indledning Dette P1 projekt er lavet i løbet af første semester på Aalborg Universitets Tekniske og Naturvidenskabelige basisår for Informatik. Temaet for semesteret er: Virkelighed og modeller Desuden er der for P1 forløbet givet undertemaet: Et brugbart IT-design: Analyse, vurdering og alternativ. I projekt kataloget står bl.a.: Nogle af de teknikker IT-designeren også skal mestre er at indhente information fra andre end sig selv. Brugerne af systemet har ofte en mening om brugbarheden af det og hvad der kan gøres for at forbedre det. Derfor er det vigtigt at IT-designeren er i stand til at anvende spørgeskemaer og/eller interviews til at indhente relevant information fra brugerne, udviklerne, designerne, eller andre relevante målgrupper. Desuden er det relevant at vide en del om, hvordan mennesket i det hele taget forholder sig til designet: Hvordan kan designet af systemet underbygge den forståelse eller viden, brugeren har i forvejen eller skal få gennem systemet? Hvordan erkender mennesket de forskellige dele af skærmfladen eller den bagvedliggende struktur? Gruppen forholder sig til dette ved i projektet at vurdere brugervenligheden af et web-sted gennem brugervenlighedstest, interview og spørgeskemaundersøgelse i forbindelse hermed. Rapporten vil ikke indeholde færdige design forslag, som kan erstatte funktioner på det nuværende web-sted. Dog er det hensigten, at komme med forslag til ændringer, som kan afhjælpe eventuelle brugervenlighedsproblemer, som måtte vise sig under testen af web-stedet. Flere og flere mennesker bruger Internettet dagligt 1, og det bliver fortsat mere udbredt at have et web-sted, både som privatperson og firma. Konkurrencen om brugernes opmærksomhed er derfor større, og det er således vigtigt at web-stedet er overbevisende i sin måde at interagere med brugeren på. Problemet med nogle web-steder er, at de bliver udviklet af designere, der ikke tænker i de samme baner som deres kommende brugere. F.eks. kan der forekomme interne og tekniske termer, som ikke forstås af brugergruppen. Det er vigtigt, at udviklere af web-steder kan sætte sig i brugernes sted, da der ellers er risiko for at udvikle et web-sted, som kun få vil kunne bruge. Med det in mente har vi valgt at lave en undersøgelse, der tager udgangspunkt i www.dsb.dk, da vi mener, der kan være brugervenlighedsproblemer på web-stedet. Dette baserer vi på egne og bekendtes erfaringer med web-stedet. 1 [http://www.dst.dk/upload/2haar2003.pdf, 11-12-2003] 6

Er der brugervenlighedsproblemer, og er de af en sådan karakter, at de forhindrer brugeren i at udføre en handling, kan det udover konsekvenser for brugeren, også blive et problem for DSB. Resultatet kan i sidste ende være, at brugerne ikke anvender web-stedet, og kan derudover forringe helhedsindtrykket af DSB. Derfor vil vi med denne rapport teste web-stedet og finde ud af om der er hold i DSBs slogan: DSB - lige til 1.1 Læsevejledning Vi har i rapporten fastlagt nogle retningslinier i forhold til opbygning og sprogbrug. Ved kildehenvisning bruges fodnoter, der angiver efternavn på forfatter, titel på bogen, samt sidetal. Der vil desuden kunne findes en komplet litteraturliste sidst i rapporten med uddybende oplysninger. Ovennævnte fodnoter, der refererer til bøger i litteraturlisten, er markeret med klammer som nedenstående eksempel: [Rubin, Usability Testing, side 153] Henvisninger til web-sider vil blive angivet i fodnoter med URL 2 samt dato for brug af web-siden. I litteraturlisten er URL til web-stedet angivet: [Http://www.DSB.dk/orange, 11-12-2003] Alle bilag er nummererede, og der henvises hertil i en fodnote. Desuden kan samtlige bilag, og testnotater findes på den vedlagte CD. I bilag til brugertest har vi, for at bevare en tydelig adskillelse mellem testpersoners udtalelser og personlige tilføjelser, benyttet kursiv skrift ved udtalelser fra testforløbet. For at bevare et ensartet sprog i rapporten, har vi desuden holdt os til bestemte betegnelser for nedenstående begreber: Web-sted: Forside: Link: Web-side: Samtlige sider der forefindes på domænet. Den web-side der fremkommer, når man søger på adressen. Som regel er det den førsteweb-side. Genveje der henter en ny web-side frem, eller udfører en funktion. Skrives i anførselstegn. Enkelt side under www.dsb.dk. 1.2 Problemanalysen Brugervenlighedsproblemer på web-steder er noget, der bliver sat mere og mere fokus på, samtidig med at konkurrencen på Internettet er tiltagende. Hvis man vil sælge et produkt over Internettet, er det vigtig at have et brugervenligt web-sted. Hvis brugerne går i stå og har problemer med at bruge web-stedet, kan det til sidst føre til, at ingen ønsker at bruge web-stedet. På www.dsb.dk har vi skønnet, at der er nogle fejl og mangler - vi har simpelthen svært ved at bruge web-stedet. For at finde ud af om det er sandt, og for at påvise hvor problemerne er, har vi planlagt nogle brugervenlighedstester. Konsekvenserne vil være at brugerne foretrækker et nemmere alternativ, og bestiller på traditionel vis. Dermed har web-stedet mistet sin funktion. 2 URL = Uniform Resource Locator, er en standardiseret og unik adresse, der peger på en ressource på Internettet eller et intranet. F.eks. er URL for www.dsb.dk, http://www.dsb.dk/ 7

Vi undersøger www.dsb.dk, fordi det er et web-sted, som kan være et nyttigt redskab for mange. Dette leder os frem til den følgende problemformulering for projektet. 1.3 Problemformulering På www.dsb.dk har vi oplevet, at der kan opstå problemer ved udførsel af bestemte handlinger på web-stedet. Dette har vi bl.a. oplevet i forbindelse med billetbestilling og rejseplanen. Disse erfaringer leder os frem til følgende problemstilling: Hvilke problemer er der med brugervenlighed på web-stedet, hvor alvorlige er de og hvordan kan de evt. udbedres? For at udspecificere problemet afgrænser vi os på følgende vis. 1.4 Problemafgrænsning Web-stedet er stort, og vi har derfor udvalgt en række web-sider for at gøre testen mere dybdegående. Vi har udvalgt de dele af web-stedet, vi formoder benyttes mest. Eksempelvis kan nævnes billetbestilling, hvor brugeren skal foretage en lang række valg, og udfylde forskellige felter for at udføre en bestilling osv. Vi vurderer risikoen for at systemet skaber problemer for brugeren, som størst i de tilfælde, hvor der er mest interaktionen mellem bruger og system. Afgrænsningen kan formuleres som billetbestillingen og kørerplanen på www.dsb.dk herunder hører følgende sider: 1.5 Målgruppe Forsiden www.dsb.dk Netbutik www.dsb.dk/netbutik Indland www.dsb.dk/indland Orange www.dsb.dk/orange Da vi har valgt at analysere et web-sted med henblik på brugervenlighed, vil den overordnede målgruppe, være designere og udviklere af lignende produkter. Da formålet med projektet er, at påvise eventuelle brugervenlighedsproblemer på www.dsb.dk, vil især udviklere af dette web-sted kunne få nytte af resultaterne. De modeller vi har analyseret ud fra omfatter, i store træk, samspillet mellem bruger og maskine, og kan anvendes på de fleste web-steder. Med dette taget i betragtning vil udviklere af andre web-steder også kunne have gavn af vores resultater, da lignende brugervenlighedsproblemer kan opstå så snart, der er tale om brugere, der interagerer med systemer. 1.6 Valg af testpersoner Nu hvor vi har afgrænset problemet, er det vigtigt også at få foretaget en afgrænsning af brugergruppen vi vælger at teste web-stedet ud fra. Deltagerne i en brugertest skal alle høre ind under brugergruppen for det pågældende produkt 3. Da der her er tale om et internetbaseret produkt, er det essentielle krav, at brugeren har adgang til Internettet. Således må den egentlige brugergruppe være: Brugere med adgang til Internettet 3 [Rubin, Usability Testing, side 120] 8

Da de brugervenlighedsproblemer vi ønsker at se på er problemer, som kan opstå for alle indenfor den egentlige brugergruppe, må den endelige gruppe nødvendigvis repræsentere denne. Med dette for øje, kan vi således begynde at afgrænse og udvælge testpersoner indenfor denne brugergruppe. I første omgang er der tale om en meget bred del af befolkningen, da fire ud af fem danskere i 2. halvår 2003, havde adgang til Internettet 4. I og med at DSB sælger et produkt der, stort set, appellerer til hele den danske befolkning, må man derfor også antage at hjemmesiden ideelt set er konstrueret for at tilpasses alles behov. Først vælges ikke at se på grupper, hvor problemer kan være relateret til specielle behov. Det vil sige grupper hvori der findes: Brugere som har behov for specielle hjælpemidler for at bruge siden Brugere med problemer, som resultat af manglende computer erfaring o Givet at det er et krav man har adgang til Internettet, antager vi at dette kun gælder for en minimal del af den egentlige brugergruppe. Et yderligere fravalg sker med henblik på følgende grupper: Pendlere o Folk der bruger DSB som primært transportmiddel, og som sådan ikke har et behov for at bruge www.dsb.dk Rejsende der ikke selv foretager køb eller bestilling af billet på www.dsb.dk o Herunder bl.a. forretningsfolk med sekretær. Personer under 18 år falder også herunder, da disse ikke har mulighed for at købe billet selv på web-stedet. Efter vi nu har sorteret dele af den egentlige brugergruppe fra, kan vi således opstille følgende specifikationer for den endelige brugergruppe: Brugere med adgang til Internettet. Brugere uden specielle behov. Brugere med basal computererfaring. Brugere der ikke benytter DSB som primært transportmiddel. Brugere over 18 år, der selv foretager køb og bestilling af billet på www.dsb.dk. 4 [http://www.dst.dk/upload/2haar2003.pdf, 13-12-2003] 9

10

11

2 Teori For at se undersøgelsen i en større sammenhæng, har vi valgt en rammemodel bestående af to modeller, som er lavet af henholdsvis Donald Norman og Lisbeth Thorlacius. Modellerne ser på kommunikationen som en helhed og inddrager både afsender, system og modtager. Dette giver os mulighed for at beskrive problemer, der opstår under testen med nogle overordnede kommunikationsteoretiske begreber, hvilket kan supplere de årsagsforklaringer, som tager udgangspunkt i web-stedet. Rolf Molichs teorier omhandler de problemer, der opstår i interaktionen mellem computer og menneske, som præcis er det vi ser på. Derfor har vi, ved at kombinere disse teorier, mulighed for både at se hvor i systemet fejlen forekommer, men også hvor i kommunikationsprocessen det går galt. Således supplerer og støtter de to teorier hinanden, og er med til at give et klart billede af problemerne. 2.1 Rammemodel Som en overordnet ramme for projektet, har vi taget udgangspunkt i to modeller, der beskriver interaktionen mellem designer, system og bruger. 2.1.1 Donald Normans Konceptuelle modeller Første model vi kigger på er Donald Normans beskrivelse af konceptuelle modeller, fig. 2.1. 12

Fig. 2.1 Konceptuelle modeller 5 Når et system udvikles, er det med udgangspunkt i designerens konceptuelle model, her Designmodel. Det vil sige hvordan designeren har tænkt sig systemet skal fungere. Den faktiske funktion af systemet er beskrevet ved Systembillede, altså et billede der viser strukturen. Gennem interaktion med systemet, opbygges der hos brugeren også en konceptuel forståelse af systemet, her Brugermodel. Da der ikke forekommer nogen kommunikation mellem bruger og designer, er det vigtigt at systembilledet klart og sammenhængende viser designerens model, altså den tanke der ligger bag systemets opbygning. Hvis ikke dette er tilfældet, vil brugerens model ikke svare til designerens, hvorfor systemet ikke vil fungere som tiltænkt. Brugeren kan i nogle tilfælde også være grunden til, at interaktionen ikke fungerer, nemlig i det tilfælde hvor brugeren ikke forstår systemet, fordi der ikke er en naturlig forbindelse mellem brugerens model og systembilledet. I og med at det er konceptuelle modeller, vi kigger på, er de forskellige dele kun tænkte og ikke noget mulige at se på i visuel form. I dette projekt vil vi dog forsøge at gøre netop dette. Ved at sammenligne den hurtigste vej gennem systemet, altså den man må forvente at designer havde tiltænkt brugeren, med den vej brugeren faktisk tager, kan vi få en idé om Brugermodel faktisk svarer til Systembilledet. 5 [Norman, The design of everyday things, side 16] 13

2.1.2 Lisbeth Thorlacius Visuelle kommunikationsmodel For at udspecificere yderligere hvad det er vi kigger på i denne sammenhæng, inddrager vi endnu en model. Nemlig Lisbeth Thorlacius visuelle kommunikationsmodel, som tager udgangspunkt i Roman Jakobsons Lingvistiske kommunikationsmodel 6. KONTEKST Den referentielle og den intertekstuelle funktion FAKTISK AFSENDER Undersøgelse af afsenders intention IMPLICIT AFSENDER Den ekspressive og de emotive funktioner PRODUKT Den formale og uudsigelige æstetiske funktion MEDIUM Den fatiske og den navigative funktion KODE Den metakommunikative og den intersemiotiske funktion IMPLICIT MODTAGER Den konative og de interaktive funktioner FAKTISK MODTAGER Undersøgelse af den kognitive, den konative og den emotionelle reception Fig. 2.2 Visuel kommunikationsmodel med særligt henblik på web-sites 7 Afsender Vi kigger først på afsenderen, hvor der skelnes mellem faktisk afsender og implicit afsender. Den faktiske afsender, som Norman kalder designer, altså den eller de personer, der har udarbejdet systemet. For at kunne undersøge dennes intentioner med systemet, vil det derfor være nødvendigt at gennemføre et interview med de pågældende personer. Dette forsøgte vi på, men mødte desværre ikke den samarbejdsvilje, vi havde håbet på. Derfor vælger vi i stedet at se på den implicitte afsender, som tilhører den del der, i Normans model, blev kaldt system. Den implicitte afsender er den vi kan se på web-stedet, altså i vores tilfælde virksomheden DSB, sådan som den gennem beskrivelser fremstår på web-stedet. Vi ser her på to funktioner, nemlig den ekspressive - og den emotive funktion. Den ekspressive funktion beskriver, hvordan vi kan se den implicitte afsender ved at kigge på selve web-stedet, f.eks. logo, firmabeskrivelser samt beskrivelser af visioner med web-stedet. Den emotive funktion beskriver de følelser og holdninger, som man af web-stedet forstår, afsender vil overføre til modtager. Denne funktion er yderligere opdelt i tre kategorier 8 : o Første emotive funktion: Udtryk for de følelser, holdninger o.l.., som afsender er i besiddelse af, og som afsender ønsker at fremkalder hos modtager. o Anden emotive funktion: Udtryk for de følelser, holdninger o.l., afsender ønsker at fremkalde hos modtager, men som afsender ikke nødvendigvis selv er i besiddelse af. o Tredje emotive funktion: Udtryk for de følelser, holdninger o.l., afsender fremkalder hos modtager, men som afsender ikke havde tiltænkt. 6 [Thorlacius, Visuel kommunikation på websites, side 41] 7 [Thorlacius, Visuel kommunikation på websites, side 49] 8 [Thorlacius, Visuel kommunikation på websites, side 58] 14

De første to funktioner kan læses direkte ud fra web-stedet, ved at undersøge f.eks. visioner og se hvad afsenderen har tænkt sig med web-stedet. Den tredje kaldes også den emotive reaktion, da den beskriver de følelser og holdninger brugeren får, som resultat af interaktion med web-stedet. Det kan være både negative og positive reaktioner. Vi fokuserer dog først og fremmest på de negative, da de positive ikke er uønskede. Selve web-stedet kigger vi nærmere på under Kontekst, Produkt, Medium og Kode, hvor der til hvert punkt er forskellige funktioner. Kontekst - Den sammenhæng hvori web-stedet findes. Den referentielle funktion: At web-stedet er enkelt og logisk opbygget, således at den refererer til kendte forhold i den virkelige verden. Den intertekstuelle funktion: Det der sætter web-stedet i forbindelse med noget ud over siden, som f.eks. henvisninger til reklamefilm eller andre ting man kender i forbindelse med afsender. Et eksempel her kunne være Harry-figuren, der er kendt fra de mange DSBreklamefilm. Produkt - Indhold og udtryk på web-stedet. Den formale æstetiske funktion: Det der er fysisk måleligt, som farver, opbygning, osv. Den uudsigelige æstetiske funktion: Den subjektive opfattelse af web-stedet, som varierer fra individ til individ. Medium - Det der gør kontakten mellem afsender og bruger mulig. Den fatiske funktion: Det der skaber og holder kontakten til brugeren, samt løbende holder brugeren informeret, om hvad der foregår i systemet. Det kan f.eks. være en form for velkomst, dialogbokse der fortæller om ændringer, en farve eller et navn der går igen og dermed lader brugeren vide at denne stadig er i samme del af systemet. Den navigative funktion: Det der lader brugeren, vide hvor i systemet han er. Et tænkt eksempel kunne være en besked som Trin 2 af 4, der fortæller brugeren at vedkommende befinder sig på andet trin ud af fire i en proces. Den navigative funktion har også til formål at lade brugeren vide hvordan, man kommer videre, f.eks. i form af links, knapper osv. Kode - Den sammensætning af tegn, hvormed der kommunikeres. For at en kommunikation kan forekomme, er det nødvendigt at både afsender og modtager kender koden. Med andre ord at afsender og modtager taler samme sprog. Den metakommunikative funktion: Dele af web-stedet der, omskrevet ved hjælp af tegn fra samme kodesystem, beskriver noget andet. F.eks. billeder, fagsprog eller myter. Mere konkret kunne det være et billede af en løve, der så henleder tankerne på noget vildt. 15

Den intersemiotiske funktion: Dele af web-stedet, der gennem tegn fra ét kodesystem forklarer noget i et andet kodesystem. F.eks. forstås der ved et billede af en printer, at man kan udskrive noget. Modtager Den sidste del af modellen omhandler modtageren, hvor der igen skelnes mellem implicit - og faktisk modtager. Den implicitte modtager er den målgruppe, vi kan se på web-stedet gennem design og indhold. Her ser vi igen på to funktioner: Den konative funktion: Dele af web-stedet, der opfordrer brugere til handling gennem f.eks. bydeform. Det kunne være opfordringer som Find rejse, Print side osv., som man kan se på www.dsb.dk. Det er her, at afsenderen skal lede brugeren den rette vej gennem systemet. Den interaktive funktion: Det vi kalder menneske-computer-interaktion - altså når en menneskelig bruger interagerer med systemet. Med henblik på den interaktive funktion opstiller Lisbeth Thorlacius fem kommunikationsformer. Information/varer produceret af center Information produceret af bruger Distributionen kontrolleret af center 1) Transmission 5) Registrering Envejs-kommunikation Ikke-interaktiv funktion Flervejskommunikation Interaktiv funktion Distributionen kontrolleret af bruger 3) Konsultation 4) Transaktion Flervejskommunikation Interaktiv funktion 2) Konversation Flervejskommunikation Interaktiv funktion Fig. 2.3 Fem Kommunikationsformer 9 Transmission: Envejskommunikation, som f.eks. en fjernsynsudsendelse, hvor bruger ikke interagerer. Det er her center, eller i sammenhæng med kommunikationsmodellen, afsenderen, der producerer og kontrollerer distributionen af produktet. Brugeren har kun mulighed for at lukke af for transmissionen og kan ellers ikke gøre noget for at påvirke den. Konversation: Flervejskommunikation hvor både information og distribution er kontrolleret af brugerne, f.eks. under chat eller telefonsamtaler. Konsultation: Flervejskommunikation hvor afsenderen producerer informationen, mens brugerne kontrollerer distributionen af den. Eksempler kan være informationstjenester, som f.eks. www.krak.dk. Her har brugerne mulighed for at benytte sig af de oplysninger der foreligger, hvis de besøger web-stedet. Transaktion: Denne er meget lig konsultationen, dog med den forskel at der her sker en faktisk udveksling. Et eksempel er web-stedet vi kigger på, www.dsb.dk, der benytter sig af dette når der 9 [Thorlacius, Visuel kommunikation på websites, side 84] 16

bestilles eller købes billetter. Når der bestilles billetter, er der mulighed for enten at afhente billetten og betale ved afhentning, eller betale billetten på web-stedet og få billetten tilsendt. En mere direkte transaktion sker ved køb af Orange-billet, hvor man selv printer billetten ud, og dermed modtager produktet umiddelbart efter betaling. Alle tre er eksempler på transaktioner, da der i alle tilfælde udveksles noget i forskellig grad. Registrering: Flervejskommunikation hvor det er bruger, der producerer informationen, mens centeret kontrollerer distributionen. Eksempler på dette er optælling af besøgende på et web-sted, registrering af cookies 10 på Internettet osv. Den sidste funktion i kommunikationsmodellen, den faktiske modtager, er den eller de personer, der bruger web-stedet. Her er det receptionen, vi ser på. Denne opdeles i tre dele: Den kognitive reception: Den forståelse og erkendelse brugeren skaber gennem brug af web-stedet. Her er der tale om de dele af web-stedet, der er målelige, så som opbygning, farver osv., altså en intellektuel oplevelse. Den konative reception: Den påvirkning der gør, at brugeren handler, altså leder brugeren igennem systemet til en evt. billetbestilling. I sammenhæng med den konative funktion hos den implicitte modtager, er det vigtigt at receptionen er tilsvarende for at bruger model og system billede bliver ens, i henhold til Donald Normans konceptuelle modeller. Den emotionelle reception: Her er det brugerens oplevelse af web-stedet, der opleves gennem sanserne. Det er en følelsesbestemt opfattelse, og kan være fremprovokeret af de emotive funktioner hos den implicitte afsender. Det skal dog pointeres at disse ikke er de samme, da de emotive funktioner handler om afsenders overførsel af følelser eller holdninger til modtager. Det der her er tale om er, hvordan modtagers reelle følelser er. 2.1.3 Den implicitte afsender Som nævnt i foregående afsnit, er der hos den implicitte afsender tale om to kommunikationsfunktioner, nemlig den emotive og den ekspressive. Vi har fokuseret på den ekspressive kommunikationsfunktion, da denne kan analyseres direkte ud fra siden. Begrebet dækker over, hvordan den implicitte afsender gør sig synlig på web-stedet, f.eks. gennem tekst, hvad enten det er bevidst eller ej. På www.dsb.dk kan man, under menu-bjælken på forsiden, finde et link med titlen: Om DSB, hvorunder man kan læse om DSBs visioner. Det fremgår tydeligt, at DSB i fremtiden satser på salg via web-stedet 11, og samtidig at benytte sig mere af transaktionsformen, hvor brugeren selv udskriver billet. Som de selv siger 12 : Siden 1999 har DSB tilbudt kunderne at reservere plads og bestille billet på www.dsb.dk. Mange kunder bruger denne mulighed, men flere ville få en fordel, hvis de ikke var nødt til at hente deres billet i en automat eller i et salgssted. 10 Små tekstfiler der lægges ind på harddisken, når et web-sted besøges. De informationer der gemmes i tekstfilen kan f.eks. være et unikt ID-nummer. Næste gang samme hjemmeside besøges, sender browseren automatisk de informationer der blev lagt i tekstfilen ved sidste besøg. [http://www.webtip.dk/artikler/cookie.php, dato 13-12-2003] 11 [http://www.dsb.dk/fremtiden/billetter/m_bottom.htm, dato 13-12-2003] 12 [http://www.dsb.dk/fremtiden/billetter/internet.htm, dato 13-12-2003] 17

Indtil videre er det kun muligt at udskrive Orangebilletter, og det fortælles, at der har været gode erfaringer med dette. Sikkerheden menes dog endnu ikke at være god nok, til at man kan overføre det til andre billetter. På grund af den stigende konkurrence 13 satser DSB på at gøre www.dsb.dk til hele Danmarks rejseportal 14, og udtrykker ønsker om at gøre den enkel at bruge. Det er altså målet, at det skal være simpelt at benytte web-stedet. For at bevare brugerne, og samtidig få dem til at handle over nettet, er det vigtigt, at der tages hensyn til brugbarheden af systemet. Dette er der tilsyneladende lagt op til, ud fra ovenstående perspektiver. Netop det at vi selv har oplevet problemer med brugen af web-stedet, som det tidligere er omtalt, giver os grund til mistanke, om at de to konceptuelle modeller for henholdsvis bruger og system ikke stemmer overens. For at undersøge dette er det interessant at kigge på sammenspillet mellem den faktiske modtager og den implicitte modtager, hvilket vi igennem en tænke højt test netop gør. For at kunne analysere i forhold til brugervenlighed, er det vigtigt at vide hvad brugervenlighed er, hvilket næste afsnit omhandler. 2.2 Hvorfor brugervenlighed I takt med udbredelsen af edb-systemer og brugen af Internettet, er brugernes forventning til det færdige produkt stigende, og brugervenlighed er efterhånden blevet et krav 15. Der kan nævnes flere grunde til, at tage hensyn til brugervenligheden ved udviklingen af et produkt. Generelt set er brugervenlighed, iflg. Rolf Molich 16, med til at skabe et effektivt samspil mellem bruger og maskine, og kan derved øge produktiviteten. Ved at gøre et produkt så let anvendeligt som muligt, kan man spare en del tid på uddannelse. Den korte indlæring, der gerne skulle være et resultat at brugervenligheden, gør at flere kan lære at anvende produktet inden for en kortere tidsperiode. Dette kan også være medvirkende til, at brugeren vælger det givne produkt frem for et andet således er der tale om en konkurrencefordel. Det kan også være en fordel for virksomheder, at arbejdet flyttes ud til kunderne, hvorved virksomhederne kan spare en del resurser og administrativt arbejde. Ydermere kan brugervenlighed være med til at spare udgifterne på kundeservice, som f.eks. en hotline 17. Ovennævnte taget i betragtning, er brugervenligheden relevant at tage hensyn til i forbindelse med www.dsb.dk. At kunderne selv kan reservere og købe billetter via web-stedet, kan bl.a. mindske belastning af telefonisk eller personlig kundekontakt, hvilket ellers ville være alternativet. Samspillet mellem bruger og maskine er her vigtigt, da brugeren selv skal være i stand til at udføre ovennævnte funktioner, som pladsreservation og billetkøb o.l. Med henblik på uddannelse og kort indlærings periode, er det nødvendigt, at web-stedet ikke kræver yderligere introduktion eller anden form for hjælpeforanstaltninger. Er web-stedet derimod lige til at gå til for brugeren, vil dette ligeledes være tidsbesparende både for bruger og udvikler, samt besparende rent økonomisk. 13 [http://www.dsb.dk/fremtiden/konkurrence/m_bottom.htm, dato 13-12-2003] 14 [http://www.dsb.dk/fremtiden/konkurrence/forbered.htm#1, dato 13-12-2003] 15 [Rubin, Handbook of Usability Testing side 11] 16 [http://www.dialogdesign.dk/brugervenlighed.html, 12-12-2003] 17 [http://www.dialogdesign.dk/brugervenlighedbetalersig.html 12-12-2003] 18

2.3 Brugervenlighed Det er ikke entydigt hvad brugervenligt web-design og brugervenlighed egentligt er. Noget som er brugervenligt i en persons øjne, behøver ikke nødvendigvis også at være det i en andens. Brugerens baggrund i form af miljø, uddannelse, erfaring med computersystemer og lignende vil spille ind på hvordan et design opleves. Grundlæggende vil det være slutbrugerne af et produkt, der bliver dommere over, om det er brugervenligt. Brugervenlighed er således en størrelse som i praksis defineres relativt i forhold til det enkelte system og dets brugere. Helt overordnet er der dog en række faktorer, som spiller ind på om et system opleves som brugervenligt. En række eksperter i brugervenlighed, f.eks. Nielsen, Molich og Rubin, ser brugervenlighed i forhold til web-design som en kombination af en række forskellige egenskaber som man kan undersøge og måle. Vi har i denne opgave valgt at tage udgangspunkt i Rolf Molichs definition, som opdeler begrebet brugervenlighed i fem faktorer og desuden inddrager hans alternative definition på brugervenlighed antallet af katastrofer på et web-sted. Vi ser her på Molichs definitioner i forhold til vores rammemodel. Let at lære Indlæringstid Den tid det tager for brugeren, at lære at løse bestemte opgaver ved hjælp af web-stedet. Altså hvor længe brugeren er om at lære Systembilledet at kende, dvs. skabe sin egen konceptuelle model. Let at huske Genindlæringstid Den tid det tager en bruger, som sjældent anvender web-stedet, at løse bestemte opgaver ved hjælp af det. Det vil sige tiden brugeren er om at genskabe sin Brugermodel. Effektivt at bruge Effektivitet Hastigheden, hvormed bestemte opgaver løses af brugere og web-sted i forening. Det er her vigtigt at brugermodel og systembillede mest mulig ligner hinanden. Her kan man bl.a. kigge på den fatiske og den navigative funktion, der guider brugeren igennem systemet, og dermed påvirker brugernes konative reception. Effektiviteten afhænger af bl.a. svartid og fejlhyppighed, dvs. antallet af fejlmeddelelser, som brugere får, når de forsøger at løse bestemte opgaver ved hjælp af webstedet. Forståeligt Forståelighed Brugernes evne til at svare korrekt på spørgsmål om web-stedets virkemåde efter at de har arbejdet med det. Forståeligheden afhænger af kvaliteten af de forklaringer og kvitteringer som web-stedet gennem den fatiske funktion giver brugeren. Her handler det om at koden, altså den Metakommunikative og den Intersemiotiske funktion, hvormed informationerne afgives, er forståelig for brugeren. Tilfredsstillende at bruge Subjektiv tilfredshed Web-stedets forskellige funktioner og services, som brugere udtrykker tilfredshed med under tester og interviews. Altså den emotionelle reception af web-stedet hos den faktiske modtager. I forbindelse med denne opgaves brugertest har vi valgt at undersøge to af Molichs kategorier; systemets forståelighed og den subjektiv tilfredshed da en undersøgelse af alle elementer i hans definition af brugervenlighed ville kræve at vi havde inddraget præstationsmåling som metode. Vores valg af tænke højt metode til at skabe data til analyse, er ikke velegnet at bruge til tester, 19

hvor tidstagning har en central rolle, da brugerens arbejdshastighed påvirkes. Kategorien Effektivitet, som den bliver defineret af Molich, har vi derfor ikke kunnet undersøge. På trods af vi ikke har inddraget kategorierne let at lære og effektivt at bruge og dermed ikke har bygget vores test op, så den har kunnet besvare dem i henhold til Molichs definitioner, vil vi alligevel diskutere dem indirekte i besvarelsen med hensyn til Thorlacius begreber. Antallet af fejl på web-stedet systemets forståelighed og den subjektive tilfredshed som vi undersøger i testen vil naturligvis også sige noget om hvor let systemet er at lære. Man vil således ikke kunne forestille sig et web-sted med mange kritiske fejl og katastrofer, som samtidig er let at lære. De forskellige kategorier skal derfor ikke forstås som strengt adskilte, men gensidig supplerende og underbyggende. Afhængigt af hvilket system man undersøger, vil de forskellige karakteristika for brugervenlighed være mere eller mindre vigtige at inddrage. Eksempelvis vil effektiviteten være vigtigere end indlæringstiden på systemer som brugeren anvender jævnligt 18. I metodeafsnittet beskrives, hvordan vi helt konkret anvender disse begreber i analysen. På trods af vi ikke har inddraget de andre kategorier i analysen, vil de alligevel være til stede i besvarelsen. Brugerens subjektive tilfredshed vil uundgåeligt være påvirket af, om de andre kategorier bliver opfyldt, bl.a. om deltageren har let ved at bruge web-stedet, og om det er effektivt at bruge. Som en supplerende indgangsvinkel til at sige noget om brugervenligheden, ser vi på antallet af katastrofer på web-stedet, og de forskellige typer af fejl. Denne metode tager udgangspunkt i fejl, der opstår, i forbindelse med brugertesten, og hvor seriøse disse fejl er for brugernes anvendelse, og dermed brugervenligheden af systemet. 2.3.1 Katastrofer En katastrofe opstår, når to eller flere brugere af et web-sted, uafhængigt af hinanden, støder ind i et kritisk problem. Årsagen til at flere skal have oplevet problemet er, at sikre problemer, der kategoriseres som katastrofer, virkelig skyldes web-stedet og ikke brugerrelaterede årsager, såsom misforståelser. Rolf Molich opererer med tre typer af kritiske problemer, der kan opstå under en brugertest: 1. Brugeren kan ikke fortsætte sit arbejde med web-stedet, uden at få hjælp. 2. Brugeren mener web-stedets opførsel er stærkt irriterende og irrationelt. Brugeren kan godt finde ud af, hvad han skal gøre, men føler at web-stedet spilder hans tid, med urimelige eller overflødige opgaver. 3. Der er en kritisk forskel mellem det, som brugeren tror, at web-stedet gør, og det som webstedet rent faktisk gør. Kritiske problemer af den første type, vil være nemme at opdage under testen, mens opdagelse af de andre to kategorier kræver, at brugeren enten udtaler sig om systemet i løbet af testen, eller efterfølgende i det afsluttende interview. Under afsnittet Metode kan der læses mere om, hvordan vi har tilskyndet brugeren til at udtale sig om systemet og tænke højt. Desuden beskrives metoden til at kategorisere de forskellige typer af fejl. 18 [Molich; Brugervenligt webdesign, side 23] 20

21

3 Metode 3.1 Metode til test af brugervenlighed I afsnittet præsenteres de metoder, vi har valgt til brugertesten: tænke højt metode, videoobservation, interview og spørgeskemaundersøgelser. Desuden beskrives vores hovedovervejelser i forbindelse med metodevalg og den analytiske tilgang til datamaterialet. Hvorfor vælge brugertest De to oplagte indgangsvinkler til at undersøge brugervenligheden og finde fejl på et web-sted er, enten heuristisk inspektion eller brugervenlighedstest. En heuristisk inspektion udføres traditionelt ved, at minimum fem inspektører gennemser et web-sted, med udgangspunkt i en række regler, heuristikker, for godt web-design. Testmetoden tager således ikke udgangspunkt i rigtige brugere og brugssituationer, men forudsætter at inspektørerne ved hjælp af et regelsæt og fornemmelse for brugervenligt web-design kan finde frem til de fejl, som brugeren vil støde på. Inspektørernes baggrundserfaring er dog afgørende for kvaliteten af den heuristiske inspektion 19. Jakob Nielsen anbefaler således, at man, som uerfaren tester af brugervenlighed, anvender tænke højt metode, og derigennem får erfaring med brugervenlighedsprincipper, ved at se rigtige brugere anvende systemer 20. Da ingen i gruppen, før studiestart, har arbejdet med brugervenlighed, er vi ikke de ideelle inspektører. Den primære årsag til at vælge brugertest, har dog været at anvende den viden vi har fået ved forelæsningerne på dette semester, og prøve de planlægningsmæssige, metodiske og analytiske udfordringer, der er forbundet med en brugertest, og som ikke findes tilsvarende i forbindelse med en heuristisk inspektion. Jakob Nielsen fortæller dog også, at den bedste måde at teste brugervenlighed på et web-sted er at undersøge, hvordan det fungerer i praksis i sammenspil med en bruger 21. Når software udvikles, vælges heuristisk inspektion hovedsageligt af økonomiske årsager, eller som supplement til brugertest. Forudsat den praktiske udførsel er i orden, kan en brugertest med fire til fem deltagere, ifølge Jeffrey Rubin, afsløre omkring 80 procent af de brugervenlighedsproblemer, der vil være i et system 22. Således er det ikke nødvendigt at lave omfangsrige undersøgelser, for at kunne sige om et system er brugervenligt. Datamængden stiger naturligvis i takt med antallet af testpersoner, og det kan pludseligt blive et problem i sig selv, at gennemse, overskue og analysere så store mængder data, specielt når vi vælger en så datatung metode som videoobservation til at fastholde testsituationen. Vi har valgt at følge Rubins anbefalinger og gennemfører testen med fem deltagere, som hører til målgruppen for www.dsb.dk. Der findes forskellige metoder til at gennemføre den praktiske del af brugervenlighedstesten og udføre dataindsamling. Vi har valgt at anvende tænke højt metoden til at få oplysninger om brugerens oplevelse af systemet og tanker under ibrugtagning. Disse oplysninger giver de forskellige observationsdata en ekstra dimension, da vi ikke kun opsamler brugerens handlinger - altså hvad de gør - men også ideelt set, hvorfor de gør, som de gør, og dermed deres antagelser om systemet. 19 [Nielsen, Usability Engineering, side 161] 20 [Nielsen, Usability Engineering, side 225] 21 [Nielsen, Usability Engineering, side 165] 22 [Rubin, Handbook of usability testing, side 93] 22

3.2 Tænke højt metoden Denne metode består i, at man beder testpersonen om at tænke højt, mens forskellige opgaver løses med systemet. Testpersonen skal sige, hvad denne tænker på, er i tvivl om, forventer web-stedet gør osv. 23 Det gælder om at tilskynde testdeltageren til at fortælle hvilke tanker, der dukker op i forbindelse med interaktionen med web-stedet. Udført under ideelle forhold, vil det give et direkte indblik i, hvad testpersonen tænker om systemet. Gennem brugerens fortolkninger af brugerfladen Brugermodellen - kan man se, hvornår systemdesignet er årsag til forkerte antagelser og fejlfortolkninger. Testpersonen vil desuden ofte kommentere, hvad denne kan lide og ikke lide ved systemet - kommentarer som senere kan vise sig nyttige. En styrke ved tænke højt metoden er således, at man kan fremskaffe en stor mængde kvalitative data fra et lille antal testpersoner 24. Af ulemper kan nævnes, at det kan føles unaturligt og kunstigt, at skulle sætte ord på sin tankeproces. For nogle testpersoner vil det være et reelt problem, at holde en stadig strøm af kommentarer i gang. Testlederen må her tilskynde testpersonen til at fortsætte, og eventuelt stille spørgsmål som; Hvad tænker du på nu?, hvis testpersonen udfører en handling uden at tænke højt. Som et supplement og sikkerhedsnet til tænke højt testen udfylder testpersonen umiddelbart herefter et post test spørgeskema, og bliver desuden interviewet - dette vil vi referere til som et debriefing interview. Hvis testpersonen har undladt at tænke højt, så testlederen og observatøren er i tvivl om, hvorfor denne har handlet på en bestemt måde, gives her mulighed for at stille uddybende spørgsmål. Et andet problem med tænke højt metoden er, at den ikke altid er særlig god at bruge i en test, hvor måling af præstationstid er afgørende. Når brugeren er tvunget til at tænke højt, vil det uundgåeligt have betydning for, hvor lang tid det tager at løse opgaven. Arbejdshastigheden vil for nogle sænkes, for andre betyder det, at de hurtigere kan overskue og anvende systemet 25. Hvordan folk reagerer på testmetoden er derfor forskelligt fra person til person. Måling af præstationstid er derfor ikke en afgørende parameter i brugertesten. Tænke højt metodens afsmittende virkning på brugernes arbejdshastighed, vil derfor ikke ødelægge testens muligheder for at sige noget væsentligt om problemstillingen. Testmål og testopgaver Ifølge Rubin er det essentielt at gøre det klart, hvad man ønsker at lære ved testen - at formulere sine testmål. Testen får derved retning og fokus, og i arbejdsgruppen opnås fælles enighed, om hvad man egentligt er på udkig efter og hvor. Testmålene overlapper og udvider problemafgrænsningen som indsnævrede undersøgelsen til nogle bestemte dele af www.dsb.dk. Testmålene beskriver yderligere hvilken funktionalitet og services vi ønsker at teste. Med andre ord beskrives hvilke dele af systembilledet vi vil undersøge. Det er vigtigt, at man har en ide om, hvordan man kan få svar på testmålene. De fungerer nemlig på næste trin i testplanlægningen som udgangspunkt for formulering af testspørgsmålene. Vores testmål lyder: Overordnet Er den navigative og den æstetiske funktion med til at understøtte brugerens opfattelse af systembilledet? - Er forsiden overskuelig? - Er Rejseplanen nem at benytte? 23 [Molich, Brugervenligt webdesign, side 135] 24 [Nielsen, Usability Engineering, side 195] 25 [Nielsen, Usability Engineering, side 196] 23

Bestilling Svarer brugermodellen til systembilledet? - Kan brugeren finde prisen på sin billet? - Kan brugeren uden problemer bestille en enkeltbillet? - Kan brugeren uden problemer afbestille en billet? - Kan brugeren uden problemer bestille en Orangebillet? - Hvordan oplever brugeren skiftet mellem DSB Orange og den normale side? Navigation er den navigative og fatiske funktion tilstrækkelig tydelige? - Kan brugeren finde rundt på siden? - Kan brugeren nemt finde hjælp? - Er der sammenhæng mellem knappernes påskrift og funktion? Andet - Er der unødvendig information på siden? - Er der tilstrækkelig information på siden? Testopgaver Vi har lavet fem opgaver, som skal hjælpe os med at svare på vores testmålene. Således skal deltageren, under løsning af opgaverne, bruge de dele af web-stedet, den funktionalitet og de services, vi har som mål at teste. I det følgende beskrives hvilke principper, vi har brugt som retningslinier, da testspørgsmålene skulle formuleres. Vi har været opmærksomme på at skabe så realistiske opgaver som muligt, set fra testpersonernes synsvinkel. Testopgaverne skal således afspejle en brug af web-stedet, som ligner den, der finder sted i en brugskontekst hos vores brugergruppe. Opgaverne er bygget op om en historie, hvor en studerende skal rejse med tog, for at komme hjem til familiekomsammen og julefrokost. For at få de mest realistiske data ud af brugertesten, er det vigtigt at spørgsmålene ikke indeholder oplysninger, som øger testpersonens chance for at løse opgaven hurtigt. Eksempelvis vil det hjælpe deltagernes forståelse af billetbestillingssystemet for Orange, hvis vi først guidede testpersonen hen til web-stedet Orange bestilling med et testspørgsmål som: Bestil en Orange billet under menupunktet Rejseplanen. Det er ikke sikkert, at brugeren ville have valgt Rejseplanen i første omgang, hvis vi ikke havde hjulpet til? Hvert testspørgsmål gives skriftligt til testpersonen et ad gangen. Når der er flere testpersoner, er vi derved sikret, at spørgsmålene hver gang bliver formuleret på akkurat samme måde. Desuden er testpersonen fri for at belaste hukommelsen med at huske spørgsmålets detaljer. Denne kan derved fokusere fuldt og helt på at løse opgaverne. Det første testspørgsmål, som udleveres, skal helst være let at løse 26. Herved giver vi testpersonen en tidlig succesoplevelse, som gerne skulle give mod på at udforske systemet videre og løse de næste opgaver. Plan over testforløb Hver enkelt test følger et ganske bestemt forløb fra deltagerens ankomst til testens afslutning. Kort skitseret ser et testforløb ud som følgende. 1. Testdeltageren ankommer og bliver budt velkommen af testleder. Spørgeskema, som er udfyld inden mødet, afleveres. 2. Testlederen introducerer deltageren til de formelle procedurer og fortæller kort, hvad det er, der skal ske. 26 [Molich, Brugervenligt webdesign, side 143] 24

3. Testen sættes i gang. 4. Efter sidste opgave er gennemgået, udfylder deltageren et afsluttende spørgeskema. 5. Interview. I de næste afsnit gennemgås de forskellige roller, som skal udfyldes under testen, hvad de forskellige testfaser indeholder og de praktiske overvejelser, som følger med. 3.2.1 Testens forskellige roller For at en brugertest skal lykkes, må der være en klar rollefordeling. Der skal indsamles data, én skal styre testforløbet og andre observere. I det følgende introduceres de forskellige roller: Testleder, Data logger og Observatør. Testlederen Testlederrollen er ifølge Rubin den mest krævende i forbindelse med en brugervenlighedstest. Den ideelle testleder skal bl.a. være hurtig til at lære, have en god hukommelse, være en god lytter, være fleksibel og kommunikere godt med andre mennesker. I stedet for at kaste os ud i en vurdering af hvem i gruppen, der bedst kunne indfri disse kriterier en vurdering som uundgåeligt ville være baseret på fordomme og ikke faktisk viden - har vi valgt at lade opgaven som testleder gå på skift. Vi er i en læringskontekst, og det vil derfor give mest mening, at flest mulige gør sig erfaringer som testleder. Senere i afsnit 7.1 Metodekritik diskuterer vi implikationerne af dette valg på resultatet af testen. Under testforløbet har lederen den primære kontakt til testdeltagerne og sørger for at de sociale rutiner opretholdes. Når deltageren ankommer til laboratoriet, byder testlederen således velkommen og introducerer kort resten af testholdet for deltageren. For at fremme en afslappet stemning er det udelukkende de gruppemedlemmer, som har en funktion som enten testleder, data logger eller observatør, der er til stede i lokalet. Umiddelbart inden opgaveløsningen giver testlederen en velkomst, som introducerer til testforløbet, fortæller at testdeltageren skal tænke højt, hvordan deltageren skal løse opgaverne osv. 27 Her er det også vigtigt at understrege, at det er systemet som testes og ikke brugeren. Medens testpersonen forsøger at løse opgaverne ved hjælp af web-stedet, noterer testlederen spørgsmål, som er vigtige at få besvaret under det afsluttende interview. Det kan f.eks. være, at testlederen er usikker på, hvorfor deltageren vælger at klikke på et bestemt link. For at kunne bruge de opsamlede data, er det vigtigt at kende grunden til testpersonens handlinger. 28 Testlederen skal forholde sig så neutralt som muligt under opgaveløsningen. Det er testdeltageren, som skal løse opgaverne og ikke testlederen. Hvis deltageren spørger efter hjælp, er det således vigtigt at denne tilskyndes til selv at løse opgaven. Udtrykkes der besvær med at løse opgaven, er det vigtigt ikke, med det samme, at komme til undsætning - vigtige detaljer kan gå tabt. Til gengæld skal testlederen kunne afslutte en opgave, hvis testdeltageren ikke kommer nogen vegne, i eksempelvis fem minutter. Det er vigtigt ikke at signalere, når testdeltageren er tæt på at løse en opgave, dvs. undgå at smile eller på anden måde udtrykke at deltageren er på rette vej. Samtidig er det også vigtigt at testlederen ikke stopper testpersonen, når opgaven er løst, da denne måske ikke er klar over opgaven er færdig. Måske er testdeltageren ikke selv klar over, at han har løst opgaven. 27 Se bilag 2 for velkomsttekst 28 [Rubin, Handbook of usability testing, s.69] 25

Datalogger Dataloggerens opgave er bl.a. at holde øje med hvor lang tid testen varer, notere løsningstid for hver enkelt opgave og hvornår der sker noget vigtigt. De forskellige data skrives ind i et regneark, og resultatet er en overbliksside, der fungerer som et indledende fokus, når data skal viderebehandles 29. Observatøren Observatøren fungerer som hjælper for testlederen og noterer handlinger, som er vigtige at få uddybet i forbindelse med det afsluttende interview. Mens testdeltageren udfylder spørgeskemaet går observatøren og testlederen udenfor lokalet, og taler om hvad der er vigtigt at få uddybet under interviewet. Afslutning Som afslutning på vores test har vi tilrettelagt to forløb: et posttest spørgeskema efterfulgt af et debriefing interview. Post test spørgeskemaet er den skriftlige del, hvor vi har udarbejdet et evalueringsskema, som testpersonen udfylder 30. Interviewet finder sted umiddelbart herefter, hvor testpersonen udspørges af testlederen. Formålet med spørgeskemaet er, at få et overblik over testpersonernes holdning, til web-stedets evt. stærke eller svage sider, der senere behandles i analysen. Vi kan ikke forvente, at testpersonerne vil afsløre alle relevante oplysninger ved at tænke højt under testen. Dette er der taget højde for i skemaet, der hjælper os til at få de ønskede oplysninger. Typisk vil dette indeholde testpersonernes meninger om, hvorvidt web-stedet er let at lære og - huske 31. Spørgeskemaet og interviewet har til formål at uddybe testpersonens tanker og handlinger under selve test-forløbet. Under interviewet får testpersonerne mulighed for at forklare yderligere, hvorfor de handlede som de gjorde under testen de følelser testpersonen evt. har haft under forløbet, kan komme til udtryk her. Omvendt har testlederen også mulighed for, at få forklaret udtalelser eller handlinger fra testen, der evt. kunne herske tvivl omkring. Pilottest Som en del af forberedelsen til den rigtige test lavede vi en pilottest på AAUs brugervenlighedslaboratorium. Formålet var overordnet at finde oversete fejl ved vores testopgaver og procedurer, bl.a. at undersøge om spørgsmålene var godt nok formuleret, og om vi havde fornemmelse for de forskellige roller under testen. Som testdeltager valgte vi en medstuderende, som ikke kendte til udformningen af opgaverne og heller ikke var regelmæssig bruger af www.dsb.dk. Som resultat af pilottestesten lavede vi nogle små justeringer af opgaverne. Bl.a. krævede en opgave at testpersonen skulle anvende www.hotmail.com. Da vi udelukkende ønsker at teste www.dsb.dk, er det uhensigtsmæssigt, at brugeren kommer udenfor systemet. Desuden blev vi opmærksomme på, at vi skal være bedre til nøjagtigt at få præciseret, hvem der tager ansvar for de forskellige praktiske detaljer. Testopstilling Når man udfører en brugervenlighedstest, er der mange muligheder for testopstillinger til rådighed. Det optimale er et decideret brugervenlighedslaboratorium. Det skal dog her nævnes, at et dyrt brugerlaboratorium ikke gør en brugertest god. Mange firmaer, som vælger at satse på 29 Se bilag 3 til 7 30 Se bilag 8 31 [Rubin, Handbook Of Usability Testing, side 199] 26