Hvornår i udviklingsforløbet laves papirprototyper?

Transkript

1 Papirprototyper Af Julia Gardner, UNI-C Papirprototyper er et billigt og ekstremt nemt redskab til at få præcist feedback fra kommende brugere uden at skrive en eneste kodelinje. De sætter fokus på brugernes behov i stedet for på udviklerens tekniske muligheder. En papirprototype er udviklerens svar på arkitektens model af det færdige hus. Hvad er en papirprototype? En papirprototype består af en række skitser af skærmbilleder, der skal indgå i et fremtidigt system eller web-sted. De bedste papirprototyper er håndtegninger, men der kan også være tale om skitser, der er fremstillet vha. et tegneprogram eller et andet ITbaseret værktøj. Papirprototypen viser, hvordan udviklingsholdet forestiller sig, at det færdige system eller web-sted skal opbygges. En papirprototype kan altså sammenlignes med den model, arkitekten laver for at vise, hvordan de bygninger, han tegner, kommer til at se ud. Brugeren har mulighed for at se, hvilke rum der er i huset, hvordan de er forbundet, og om der er plads til møblerne. Papirprototypen fokuserer på indhold og struktur, hvorimod æstetisk design er trådt i baggrunden. Det drejer sig om at få klarlagt, hvilke opgaver brugeren skal kunne løse, og hvordan de skal løses. I arkitektens model er der tilsvarende ikke sat tapet på væggene og gardiner for vinduerne. Hvornår i udviklingsforløbet laves papirprototyper? Papirprototyper er et uundværligt arbejdsredskab i de indledende faser af et udviklingsforløb. Som regel anvendes de før, der overhovedet er fremstillet en kravspecifikation. Typisk kan man udarbejde en eller flere papirprototyper i forbindelse med det indledende møde, der holdes ved projektopstart. Inden nogen når at lægge sig alt for fast på et bestemt koncept for det kommende system eller web-sted, kan man få et meget præcist feedback fra brugerne som 11

2 beskrevet i næste afsnit. Det er ikke ualmindeligt, at man lader en papirprototype indgå som en del af selve kravspecifikationen, idet den er et forståeligt kommunikationsredskab for alle parter. En papirprototype består som nævnt af en stak papirer. Som ekstra supplement har man brug for post-its, blyant og viskelæder. Post-its bruges til at illustrere menu-punkter eller drop-down knapper, der folder sig ud. Blyanten fungerer som brugerens tastatur: hvis der skal indtastes noget i et felt, skriver man simpelthen med blyanten. Viskelæderet fungerer som Delete-tasten på tastaturet. Brugeren benytter sin egen finger som mus: hvis han vil klikke på et link eller en knap, peger han på det med fingeren, siger "klik", hvorefter et nyt skærmbillede forevises. Mark Rettig 3 giver i en artikel en glimrende introduktion til forberedelsen af en papirprototypetest samt inspiration til, hvordan forskellige funktioner kan illustreres. Til en papirprototypetest bør der altid være mindst 3 personer til stede: en bruger, en testleder og en udvikler, der agerer "computer": Brugeren skal løse opgaver som under enhver anden brugbarhedstest (usability test). Opgaverne bør være fuldstændig realistiske, selvom der ikke er tale om et rigtigt system eller web-sted endnu. I takt med at brugeren arbejder sig gennem systemet eller web-stedet, afsløres brist og mangler, og frem for alt opnås et langt mere nuanceret billede af brugernes arbejdsform og behov. Testlederen skal sørge for, at testen afvikles efter alle kunstens regler: sikre at brugeren forstår opgaven, stille relevante spørgsmål og notere reaktioner. "Computeren" har til opgave at reagere på brugerens handlinger: når der "klikkes" på papirprototypen skal "computeren" fx fremvise et nyt skærmbillede eller demonstrere en anden ændring, der sker på skærmen. Der kan med fordel deltage flere personer end de 3 nævnte. Fx viser erfaringen, at det er en god idé at lade brugerne teste i par. Dels fordi de appellerer til hinandens fantasi og kan have spændende faglige diskussioner indbyrdes, men også fordi nogle kan være tilbageholdende, hvis de sidder alene over for hele to personer, de ikke kender (testlederen og "computeren"). Det kan også være relevant at udpege en person fra projektteamet til at nedskrive alle brugernes handlinger og kommentarer, så testlederen frigøres for denne ganske arbejds- og opmærksomhedskrævende opgave. I fagkredse kaldes dette at 3 "Prototyping for Tiny Fingers". Communications of the ACM, April 1994, Vo. 37, No. 4.

3 "logge". En anden mulighed er at videooptage eller båndoptage brugerens kommentarer, men man skal være opmærksom på, at det er meget tidskrævende at analysere sådanne optagelser. Stort tidsforbrug matcher dårligt den hurtige, skitsebaserede proces, man er i gang med, når man arbejder med papirprototyper. En lang række argumenter taler for anvendelsen af papirprototyper: De er konkrete. Et typisk problem i forbindelse med fastlæggelse af funktioner og indhold i et nyt system er, at brugere og udviklere taler hver deres sprog. Til møder kan man fx opnå enighed om, at det nye system skal rumme xxx. Men hvad betyder det reelt? Udvikleren forestiller sig yyy, imens brugeren regnede med zzzz. I det øjeblik papirprototypen fremstilles, har man konkretiseret, hvordan xxx skal forstås, og brugeren får lejlighed til at prøve, hvordan det virker og forklare sine mere præcise ønsker. En "hands-on" oplevelse, som er meget værd i forhold til at læse en kravspecifikation! De er billige. Det koster kun meget få ressourcer at fremstille selv omfattende papirprototyper. Det betyder, at udviklerne er meget mere lydhøre over for brugernes kommentarer: hvis brugerne hader en papirprototype, er det nemt at krølle den sammen og begynde forfra - det har nemlig ikke kostet blod, sved og tårer at fremstille den. Det er muligt at arbejde med alternativer. Fordi papirprototyper er så billige at fremstille, er det oplagt at arbejde med alternativer, dvs. fremstille flere forskellige bud på, hvordan systemet eller web-stedet kan udformes. Når brugere præsenteres for valgmuligheder, engageres de langt mere i arbejdet, fordi det tydeliggøres meget kontant, at der ikke er én endelig løsning på, hvordan det færdige system eller web-sted ser ud.

4 Få feedback før der er skrevet en eneste kodelinje. Med papirprototyper er der reel mulighed for afvikle et iterativt forløb helt i henhold til lærebøgerne: en papirprototype fremstilles, udsættes for brugerafprøvning og medfølgende kritik, hvorefter en ny model udarbejdes, som herefter gennemløber samme proces. På denne vis præciseres forventninger og behov, før programmeringen overhovedet begynder. Jo før man får brugerne i direkte tale, des større sandsynlighed er der for, at man fremstiller et produkt, der falder i deres smag. Især fordi man kommunikerer sammen på en måde, der er entydig for alle parter. Alle kan deltage i fremstillingen af papirprototyper. Når man starter et nyt projekt er mange forskellige parter involveret, men kun nogle få kan programmere. Ved at arbejde med papir-prototyper sikrer man, at alle relevante personer har mulighed for at bidrage med ideer til systemets udformning. Alle kan tage et stykke papir og en blyant i hånden - selv brugerne! Brugeren kan se, at der ikke er tale om et færdigt system. Når man tester rigtige elektroniske prototyper, får brugeren ofte det indtryk, at der er tale om et næsten færdigt system. Det kan derfor medføre skuffede forventninger, når brugeren får at vide, at der vil gå flere måneder før systemet er på markedet. En test går aldrig i stå pga. programmeringsfejl etc. Mange venter med at vise et system eller et web-sted til de har en kørende, elektronisk prototype. Dette er fuldt legitimt, men der opstår ofte problemer, når man tester sådan en prototype: brugeren skriver et uventet input eller klikker det forkerte sted, og så går prototypen ned. Det bremser testen, virker irriterende og hæmmer brugerens lyst til at udforske prototypen. Disse problemer er man helt ude over, når man tester papirprototyper; her kan systemet ændres på stedet. Hvis brugeren klikker et sted, man ikke havde regnet med, kan han fortælle, hvad han forventer at få at se, og det nye skærmbillede kan hurtigt skitseres på et blankt stykke papir. Den nye skitse indgår herefter i testen på lige fod med de øvrige skærmbilleder. Mange udviklere reagerer stejlt, første gang de hører om papirprototyper. Nogle af de typiske indvendinger, vi støder på, er beskrevet nedenfor, og i forlængelse heraf vises vores forsvar for arbejdsformen. Indvending: "Brugerne vil ikke tage os alvorligt, når de ser gnidrede håndtegninger". Svar: Brugerne opfatter udviklingsprojektet som meget seriøst, når de får forklaret, at arbejdet med papirprototyper drejer sig om at få præciseret brugernes behov, før programmeringen starter. Når man fortæller historien om arkitekten, der laver model, før huset bygges, er alle helt med på ideen. De fleste brugere føler sig

5 ydermere langt bedre tilpas ved at kritisere en papirprototype end en elektronisk prototype, fordi papirprototypen ikke ser fin og færdig ud. Hvis der er problemer i en rigtig prototype, beskylder brugeren ofte sig selv for at være dum, hvis noget ikke virker; det problem er man fuldstændigt ude over med papirprototyper. Indvending:"Det er lige så hurtigt at lave en rigtig HTML-side eller bruge VisualBasic til at "tegne" et skærmbillede, som det er at lave en læselig håndtegning". Svar: Så snart man går væk fra håndtegninger, kommer æstetik langt mere i fokus. Der bruges meget mere tid på at få hvert enkelt skærmbillede til at se ordentligt ud. Dvs. at fokus flyttes væk fra det egentlige: at få lavet systemets grundplan og finde ud af, hvad det skal kunne brugs til. Derudover begynder man alt for hurtigt at tænke på, hvordan man skal løse de forskellige programmeringsspørgsmål. Indvending: "Brugere kan ikke designe". Svar: Brugere skal ikke designe på egen hånd, men med udgangspunkt i den inspiration prototypen giver. Når brugeren skitserer en idé, skal den ikke nødvendigvis tages for pålydende men i stedet tjene som udgangspunkt for bedre forståelse af brugerens tanker. Brugere engageres meget seriøst i processen, når de kan se, at deres skitser indgår i det samlede materiale. Når man kan tegne sine forklaringer i stedet for at skulle prøve at beskrive sine behov med (tekniske) ord, er det faktisk en lettelse for mange. Indvending: "Mange avancerede funktioner og muligheder kan slet ikke illustreres vha. papir". Svar: Det meste kan faktisk lade sig gøre med lidt behændighed og fantasi. Vi har med held testet papirprototyper, der senere skulle udmøntes som avanceret 3D grafik. Hvis man planlægger at bruge meget specielle funktioner eller lignende, og finder det umuligt at tegne dem på papir, er det ikke sjældent udtryk for, at man er ved at lave et system, der ikke er særlig brugbart!

6