Bring brugssituationen ind i testen

Metoderne interviewbaserede opgaver og opgavesortering giver brugerne en aktiv rolle i udformningen af scenarier og opgaver til test af en prototype. Det sker på en måde, så testsituationen kommer tættere på en realistisk brugssituation. Dette er en fordel, idet et væsentligt aspekt af et produkts brugbarhed er, om brugssituationen understøttes af produktet [1]. Ikke blot om brugeren kan forstå grænsefladen isoleret set, dvs. det traditionelle brugervenlighedsbegreb.

I testen benyttes scenarier og opgaver:

• Et scenario er en fortælling eller en drejebog. Det beskriver omstændigheder ved en situation, f.eks. en arbejds- eller undervisningssituation. Hvis situationen er, at brugeren anvender et IT-produkt, er omstændighederne bl.a. om det sker ved en hjemme-pc eller på et bibliotek, om brugeren er alene eller arbejder sammen med andre, hvorfor han anvender det o.l. Scenarier ser situationen ud fra brugerens eget synspunkt, ikke ud fra f.eks. udviklerens. I testsituationen anvendes scenarier som en iscenesættelse af testen, dvs. man lader som om, at situationen nu er den, scenariet beskriver. Eksempel på scenario.

• Brugeren anvender IT-produktet med det formål at løse en opgave i den konkrete situation. Det kan være formelt såvel som uformelt. Brugeren anvender ikke bare et IT-produkt, men går f.eks. ind på et web-sted for at finde nogle bestemte oplysninger, for at blive underholdt, for at stille spørgsmål o.l. Måske er det vigtigt at finde bestemte oplysninger hurtigt, måske skal oplysningerne gerne være på en bestemt form for at kunne bruges osv. Et scenario består typisk af en eller flere opgaver. Eksempel på opgave.

Scenarier og opgaver skal være realistiske og relevante for brugeren, dvs. svare til situationer, brugeren normalt befinder sig i. Er de ikke det giver testen ofte et falsk indtryk af prototypens brugbarhed. For ud fra scenarier og opgaver lever brugeren og testleder sig ind i de situationer, hvor det færdige IT-produkt tænkes anvendt.

Eksempel på urealistisk scenario og opgave.

Det er vigtigt at gøre brug af både scenario og opgaver for at testen giver et realistisk billede af den fremtidige brugssituation. Anvender man opgaver i testen, uden at de er en del af et scenario, tror man måske, man får noget ud af at betragte brugeren løse opgaverne, men både bruger og testleder vil formentlig have svært ved at leve sig ind i den fremtidige brugssituation.

Ved at benytte de interviewbaserede opgaver og opgavesortering kan brugerne inddrages i udformningen af opgaver og scenarier. Det er en stor fordel, for det kræver nøje kendskab til brugerne, til brugssituationen og til brugernes behov i brugssituationen at lave realistiske og relevante scenarier og opgaver. Metoderne står i modsætning til traditionelle testopgaver, der er udformet af udvikleren og testlederen alene.

• Interviewbaserede opgaver
  Scenarier og opgaver bliver til ud fra åbent interview om brugeren, brugssituationen og hans behov. Interviewet finder sted lige før testen og med uddybende spørgsmål under testen. Interviewet skal rettes mod situationer, brugeren tidligere har været i. Det gør scenarier og opgaver meget realistiske, fordi brugeren selv har været i dem og selv formulerer dem. Brugeren bliver motiveret for at besvare opgaven og også nysgerrig efter resultatet. Desuden kan han stille detaljerede krav til resultatet. Eksempel på Interviewbaserede opgaver.
• Opgavesortering
  Her præsenteres brugeren for en vifte af opgaver med tilhørende scenarier, som er blevet formuleret på forhånd. I stedet for at bede brugeren løse alle opgaver, udvælger brugeren de mest relevante og løser dem i en selvvalgt rækkefølge. Dermed undgås de opgaver, som brugeren finder mest urealistiske og irrelevante i forhold til brugssituation og interesser. Og samtidig giver brugerens valg og fravalg af opgaver samt prioritering vigtig information om brugeren. Formuleringen af scenarier og opgaver kan med fordel ske på baggrund af feltstudier, for dermed bliver viften af opgaverne så realistiske og relevante som muligt. Eksempel på opgavesortering.

Brugen af interviewbaserede opgaver kan anvendes som grundmetode i test, men der er situationer, hvor interviewbaserede opgaver med fordel kan kombineres med opgavesortering. Eller situationer hvor man vælger udelukkende at anvende opgavesortering. Under alle omstændigheder giver testen et mere realistisk billede af brugbarheden, end hvis testlederen selv udformer og udvælger opgaver.

Opgavesortering kan være nødvendig at bruge i de situationer, hvor brugeren har svært ved at formulere tilstrækkeligt med opgaver og scenarier selv. F.eks. en yngre folkeskoleelev, der skal afprøve et IT-produkt til brug i undervisning. Her kan elevens lærer foreslå meget realistiske scenarier og opgaver til brug i opgavesorteringen. Er der tale om et IT-produkt, der lægger op til nye brugssituationer, kan det være svært for brugeren selv at formulere opgaver, og opgavesortering kan anvendes som alternativ og/eller inspiration til interviewbaserede opgaver.

Uanset valget af opgavetype kan testlederen have gavn af en "opmærksomhedsliste" over funktioner, man gerne vil have brugeren til at prøve af, eller spørgsmål der ønskes besvaret, hvis det er muligt. Testlederen finder så et godt tidspunkt at bringe listens punkter på bane i testen. Eksempel på opmærksomhedsliste.

Med Interviewbaserede opgaver kan der opstå situationer, hvor testlederen på forhånd ved, at en opgave ikke kan løses med prototypen. Alligevel vil opgaven ofte være relevant, idet den fortæller, at brugeren også gerne vil kunne løse denne opgave med prototypen. Det kan give anledning til at diskutere med brugeren, hvor i prototypen svaret på opgaven skal placeres.

Når man formulerer opgaver og scenarier, træffer man nogle valg med hensyn til sprogbrugen. Sprogbrug og formuleringer sender en masse signaler til brugeren og kan dermed let blive ledende og give ubevidst hjælp til brugeren. Der er to slags ubevidst hjælp:

1. Man kan fortælle via opgaven, hvad prototypen kan.
2. Man kan fortælle navnet på funktionen, der skal bruges for at løse opgaven.

I det første tilfælde beskriver man faktisk for brugeren, præcist hvordan man forventer, han/hun løser opgaven! Risikoen er, at man ikke bliver opmærksom på, at brugeren måske slet ikke ville have overvejet at bruge en bestemt funktion i prototypen til at løse denne opgave med: Det ville måske falde brugeren mere naturligt eller hensigtsmæssigt at løse opgaven på en anden måde.

I det andet tilfælde er risikoen, at man "overskygger" brugerens eget sprogbrug med ord i prototypen, som brugeren ikke nødvendigvis selv ville have brugt. Dermed finder man ikke ud af, om prototypens ordbrug er så god, at brugerne umiddelbart har en idé om funktionernes betydning.

Eksempel på opgave med og uden ubevidst hjælp.

Risikoen er i begge tilfælde, at billedet af brugbarheden bliver begrænset og/eller forvrænget. Testbrugeren har jo fået ubevidst hjælp, som brugeren, der sidder med det færdige IT-produkt, ikke får, og derfor giver testen et forkert billede af brugbarheden.

Testlederen skal finde en balancegang mellem at give ubevidst hjælp og at være vildledende i sine formuleringer. For i sin iver for at undgå at give ubevidst hjælp i sin formulering af opgaverne er der en fare for, at testlederen går i den anden grøft og bliver vildledende. Mange brugere vil finde det ubehageligt at føle sig vildledt, og samtidig giver det heller ikke et realistisk billede af prototypens brugbarhed.

Et IT-produkts brugbarhed er afhængig af brugssituationen, og med denne artikel håber vi at have inspireret til at bringe brugssituationen ind i brugbarhedstesten med scenarier og opgaver.

1. Bødker, S. & Halskov Madsen, K.: Context - An active choice in Usability Work. In Interactions, July + August 1998, p. 17-25.
2. Bødker, S. & Grønbæk, K.: Design in Action: From Prototyping by Demonstration to Cooperative Prototyping. In: Greenbaum, Joan & Kyng, Morten (eds): Design at Work, Lawrence Erlbaum Associates, Publishers, Hillsdale, New Jersey, 1991.