INF2260. Interaksjonsdesign VB2.0. Det nye Realfagsbiblioteket. Skrevet av:

Transkript

1 INF2260 Interaksjonsdesign VB2.0 Det nye Realfagsbiblioteket Skrevet av: Iben Aspelien Anders Ballangrud Marte Hesvik Frøyen Jonas Modahl Mørkåas Therese-Mari P. Thomassen Høst 2011

2 2

3 Innhold 1 Introduksjon Visjon og mål for prosjektet Om prosjektgruppen Slik jobbet vi Prosjektplan Startfasen - etablering av prosjekt Idémyldring Spørreundersøkelse Utforming og valg Resultat av spørreundersøkelsen Valg av prosjektfokus Underveis Prototyping og testing av disse Low-fidelity prototype High-fidelity prototype Resultater av testing Refleksjon av prosjektet Videre arbeid Sluttord

4 4

5 1 Introduksjon Vårt prosjektvalg i INF2260 var å utvikle en pensum-applikasjon for det nye realfagsbiblioteket (RF-biblioteket). Dette er en tjeneste universitetsbiblioteket ikke tilbyr i dag. 1.1 Visjon og mål for prosjektet Vårt prosjektvalg har forankring i flere argumenter: I anledning åpningen av det nye realfagsbiblioteket i mars den oppfatningen vi har om at bibliotekene blir for lite brukt av studenter - og at studentene kanskje ikke er klar over bibliotekets mange muligheter og ressurser. Basert på dette, ønsket vi gjennom høsten å utvikle en mobiltjeneste hvis formål er å lettere tilgjengeliggjøre biblioteket for matnat-studenter. Dette tenkte vi å gjøre gjennom å designe en pensumapplikasjon. Avslutningsvis i innledningen formulerer vi på bakgrunn av dette følgende beskrivelser av vår visjon og vårt mål: Vår visjon er å gjøre bibliotekene ved UiO mer tilgjengelig for studenter, med fokus på det nye realfagsbiblioteket. Vårt mål er å lage en applikasjon som skal gjøre pensum mer tilgjengelig for studentene. 2 Om prosjektgruppen Prosjektgruppen består av fem personer: Anders, Iben, Jonas, Marte og Therese-Mari. Vi har erfaring fra to ulike studieretninger: Digitale Medier og Design, bruk, interaksjon. 2.1 Slik jobbet vi Vi innså tidlig i prosessen at vi ville være tjent med å delegere de største oppgavene til to ulike team: utviklere og testere. Valgets formål var å effektivisere prosjektet grunnet tidspress. Litteraturen argumenterer for at utviklere ikke bør være med på testing av grensesnitt, og vi anså derfor denne inndelingen som gunstig (Lazar et al., 2010, side 260). Gruppene jobbet en god del hver for seg, men ble oppdatert på hverandres progresjon i ukentlige møter. Vi har i tillegg hatt jevnlig kontakt på Facebook, i Dropbox, og senest i Google Docs. 5

6 2.2 Prosjektplan 1 1 A=aktivitet, M=milepæl. Med tidsforbruk menes antall klokketimer. 6

7 3 Startfasen - etablering av prosjekt Vi valgte kategorien «Design for et moderne bibliotek», og møtte utfordringen med et mangfold av idéer og forventninger. Det første vi gjorde som gruppe, var å diskutere de idéer og tanker vi personlig hadde reflektert oss rundt oppgaven, samtidig som det ble holdt en mer generell diskurs. Prosjektet vårt var i utgangspunktet basert på en oppgavebeskrivelse fra det nye Realfagsbiblioteket. Vi brukte derfor mye tid i starten på å undersøke hvilke ønsker de hadde for prosjektet og produktet. Dernest avtalte vi møter med vår oppdragsgiver, Live Rasmussen 2, i form av omvisning på biblioteket, samt samtaler og diskusjon rundt prosjektet. Omvisningen genererte innsikt i bibliotekets nye utseende - mulige løsninger og begrensninger. Dette var med på å påvirke vårt valg av prosjektfokus. Vårt møte med Live gikk ut på å kartlegge hennes tanker, ønsker, krav og behov for en eventuell tjeneste til nytte for biblioteket. På denne måten fikk vi konkrete forslag, impulser og mer informasjon som ville være nyttig for videre arbeid. 3.1 Idémyldring Som nevnt stod vi ovenfor utfordringen mer spesifikt å velge et grunnlag til videreutviklingen. Utover dette ble tre valg sett på som de mest gunstige løsningene: interaktivt kart som grafisk viser hvor man er og hvordan man finner frem på biblioteket, romreservering hvor studenter gjennom applikasjonen kan reservere grupperom og tilslutt en tjeneste som gjør at studentene lett kan finne pensum i sine fag, samt sjekke status 3 for disse bøkene på biblioteket. For hvert av disse forslagene begynte vi hver for oss å lage low-fidelity prototyper hvis mening var å inkludere de viktigste funksjoner og designløsninger. Dette for å demonstrere deres anvendelsesområder. Prototypene vi utviklet på dette stadiet var papirskisse-prototyper. Disse ble igjen diskutert og vurdert i plenum på et gruppemøte. I denne fasen av prosjektet ble det også lenge vurdert en kombinasjon av disse løsningene. Hvorfor vi til slutt inkluderte kun en av løsningene i applikasjonen har flere grunner. Det viktigste vi måtte forholde oss til var tidspress, og vi skjønte etter en rekke impulser at vi burde begrense oss med tanke på antall funksjoner og løsninger. Vi ble anbefalt av foreleser at vi burde begrense prosjektets rammer, og heller sette fokus på testing, da dette er et av emnets hovedfokus. Med mer innsikt i hva vi skulle og kunne gjøre, samlet vi en del konkrete og mer detaljerte forslag for prosjektet. Vi tok så kontakt med Live og avtalte et møte for å diskutere proto- 2 Live Rasmussen er ansvarlig for det nye realfagsbiblioteket. 3 Med status menes hvor boken befinner seg, samt hvorvidt boken er tilgjengelig for utlån eller ikke. 7

8 typene nærmere. Av møtet kom det frem at hun holdt pensumapplikasjonen som favoritt, men at de andre forslagene også kunne være nyttige. I starten baserte vi oss i høy grad på Lives ønsker, men fokuserte samtidig på at vi tidlig måtte få innspill fra brukere for å kunne kartlegge studentenes krav og behov. På denne måten ville det være mulig for oss å lage en applikasjon med funksjoner som brukerne faktisk ville ønske å ta i bruk. Etter omvisningen i biblioteket innså vi at et interaktivt kart ville være vanskelig for oss å utvikle, og dette forslaget ble derfor tidlig forkastet. Åpenhet og mobilitet er viktige nøkkelord for design av det nye biblioteket, noe som i seg selv er positivt, men som dessverre for oss vanskeliggjorde muligheten for å utvikle en god kartløsning. Derfor fokuserte vi videre hovedsaklig på de to resterende prototypene; applikasjon for reservasjon av grupperom og pensumapplikasjon. 3.2 Spørreundersøkelse I den videre fasen var det viktig for oss å skape en bredde i prosjektet ved å undersøke behovet for produktet på markedet og hos brukergruppen. For å gjøre dette falt valget ganske raskt på nettbasert spørreundersøkelse. En slik måte å samle inn informasjon på er gratis, lettvint å lage og viktigst av alt en effektiv måte å skaffe et godt overblikk over brukernes behov på kort tid. (Lazar et al., 2010, side 101) 3.3 Utforming og valg Utforming av spørreundersøkelsen tok overraskende lang tid. Det var viktig at spørsmålene ikke var uklare eller ledende. Dårlig formulerte spørsmål kan gi data av varierende troverdighet. (Lazar et al., 2010, side 113). Gjennomgang av spørreundersøkelsen foregikk i plenum, og vi gjennomførte en pilottest innad i gruppen. Vi forklarte kort innledningsvis målet for spørreundersøkelsen, at den ville ta maks fem minutter, samt at vi ønsket å lage en applikasjon som potensielt kunne bedre studiehverdagen. Undersøkelsen bestod hovedsaklig av lukkede spørsmål med to eller flere svarmuligheter, eller et kommentarfelt. Rekkefølgen på spørsmålene var satt opp på en logisk måte, der vi grupperte beslektede spørsmål. En side omhandlet pensum og tilleggslitteratur, mens den neste handlet om bruk av grupperom. Strukturen var i tillegg slik at de som for eksempel ikke brukte grupperom ble sendt videre til neste del (Lazar et al., 2010, side ). Det er i utgangspunktet matnat-studenter som vil ta i bruk det nye RF-biblioteket, men 8

9 i våre øyne var problemstillingen gjeldende for alle studenter ved UiO. Vi opererte derfor ikke med noe videre avgrensning i forhold til hvem som kunne svare på spørreundersøkelsen, utover at de var student ved UiO. Ettersom dette omfatter alt fra førsteårsstudenter til doktorgradstudenter, gav det oss en utfordring ved analyseringen av svarene. Vi anså det likevel som viktigere med et raskt overblikk over et generelt behov hos studentene, fremfor å ta i betraktning hvor i studieprogresjonen de var (Lazar et al., 2010, side 105). Vi valgte å bruke Facebook som en metode for å innhente deltakere til spørreundersøkelsen. Dette er å anse som en svakhet ved en slik form for informasjonsinnsamling, fordi at vi kan anta at de fleste som svarte er i vår egen bekjentskapskrets. Vi hadde heller ingen annen mulighet til å begrense deltakelsen til bare UiO-studenter enn å legge inn et kontrollspørsmål. Tidspress og usikkerhet rundt antall deltakere vi kunne klare å innhente, bidro til at vi likevel valgte å gjøre det på denne måten. Brukerne ble gitt en tidsfrist på en uke for å besvare undersøkelsen, og vi startet dernest umiddelbart med analysering av resultatene. 3.4 Resultat av spørreundersøkelsen Vi innhentet totalt 28 svar, hvorav 25 oppga at de var UiO-studenter. Under spørsmålet «Hvordan finner du pensumlitteraturen for det faget du tar?» har noen deltakere svart at de finner pensumlitteraturen på emnesiden, mens andre sier at de benytter tjenester som amazon.com og bokklubben.no. Dette tolker vi som at spørsmålet var vagt formulert og at det er mulig at også andre deltakere kan ha misforstått dette. Videre oppga 66% av 18 svarende at de ikke benytter biblioteket. Vi spurte også om hvordan studentene synes det er å finne obligatorisk pensum med gjeldende løsning, noe de stort sett synes var lett (61%) eller ganske lett (27%). Kanskje vi istedet burde ha benyttet brukere som ikke studerer ved UiO og heller undersøkt hvordan de opplever systemet eller pensumlistene. Et forslag til videre undersøkelser av dette, kan være at et utvelgelseskriterium formulerer at 50% av deltakerne ikke skal være studenter ved UiO. I kjølvannet av dette spurte vi om hvordan studentene opplever å finne fram til relevant faglitteratur, noe som 67% av de som svarte syntes er «ganske lett». I det neste steget spurte vi om de ville bruke biblioteket mer dersom det hadde vært lettere å finne denne relevante faglitteraturen. 44% responderte med at de er fornøyde med nåværende løsning, og sannsynligvis ikke ville ha brukt biblioteket mer ved nyere løsning, 33% svarte «Ja» til spørsmålet og 22% «Nei». 9

10 En annen tjeneste vi ønsket å kartlegge meninger om, var funksjonen «Bestill en bibliotekar». Om nåværende bruk av funksjonen sa kun 6% at de benyttet den, og 50% svarte «Nei». Tjenesten var ukjent for de resterende 44%. En annen kategori vi ville finne mer ut om, var hvorvidt studentene bruker grupperom på UiO. Her svarte 83% at de har benyttet grupperom. I et tilhørende spørsmål svarer 65% «vet ikke» om hvorvidt det går an å reservere grupperom. Påfølgende undret vi på om studentene ville benyttet en slik tjeneste dersom det eksisterte. Her mener 56% at det er irrelevant, mens øvrige svar er jevnt fordelt på ja- og nei-kategoriene. I vårt siste spørsmål spurte vi om «Hva er viktigst for deg? Pensumoversikt eller mulighet til å reservere grupperom?» Her svarte 11% at de ønsket muligheten til å reservere grupperom, hele 89% ønsket en pensumapplikasjon. Selv om spørreundersøkelsen ikke gav oss dybdeinformasjon, var det en passende innsamlingsmetode for informasjonen vi trengte. Ved å kartlegge brukernes krav og behov kunne vi endelig bestemme oss for prosjektfokus samt begynne å utforme kravspesifikasjoner for applikasjonen Valg av prosjektfokus På bakgrunn av tilbakemeldinger fra Live og det overveldende flertallet brukere som ønsket pensumapplikasjon, valgte vi dette som prosjektfokus. Vi mener en slik applikasjon har potensiale til å nå ut til mange studenter ettersom den kan hjelpe med å gjøre biblioteket mer tilgjengelig og studiehverdagen enklere. I applikasjonen kan studenten legge inn de fag for semesteret og få oppgitt pensum og anbefalt tilleggslitteratur. Den vil benytte seg av bibliotekets ressurser gjennom Bibsys og gi status på disse bøkene. I tillegg vil den inneholde funksjonen «Bestill en bibliotekar» og praktisk informasjon om biblioteket. «Bestill en bibliotekar» var en funksjon vi valgte å implementere av flere grunner. Oppdragsgiver gav uttrykk for at dette var en tjeneste som var ønskelig å inkludere i en applikasjon. Gjennom spørreundersøkelsen kom det frem at dette var en tjeneste som veldig få visste om. I tillegg ville det være forholdsvis lett å gjøre tjenesten til en del av applikasjonen og vi synes den ville være passende ettersom en av visjonene med prosjektet var å gjøre biblioteket mer tilgjengelig. Navnet «VB 2.0» 5 kommer fra navnet på bygget og at applikasjonen skal være med å representere den nye versjonen av biblioteket. En mer detaljert beskrivelse av nåværende 4 Se «Vedlegg 1-Spørreundersøkelsen» 5 VB er en forkortelse for «Vilhelm Bjerknes» 10

11 versjon og ønsket sluttprodukt finnes i avsnitt 6 «Videre arbeid». 4 Underveis Valg av oppgavetilnærming var nå bestemt, og fokuset ble flyttet til utviklingen av ulike prototyper og testing av disse. I denne fasen ble det mer naturlig å dele gruppen i to, slik at vi kunne drive utvikling og testing parallellt, og dermed utnytte tiden vi hadde tilgjengelig på en bedre måte. Nå ble det også viktigere å ta hensyn til brukernes krav og behov fremfor oppdragsgivers ønsker, i henhold til brukersentrert design. 4.1 Prototyping og testing av disse Den opprinnelige tanken var å utvikle prototypene iterativt med jevnlige brukertester. Dette var en metode som fungerte bra i utviklingen av low-fidelity prototypen men som viste seg utfordrende i high-fidelity prototypen. Oppbyggingen av begge brukerundersøkelsene var ganske lik. Vi startet med å informere brukeren om prosjektet vårt, formålet med testingen og fremgangsmåten, samt anonymitet og tilbaketrekking av gitt informasjon. Brukerne måtte signere på et samtykkeskjema 6 før vi startet brukerundersøkelsen. Hoveddelen av undersøkelsen var basert på at bruker skulle utføre konkrete oppgaver som var representative for brukergruppen og prosjektet. Meningen var at brukerne skulle klare å løse oppgavene uten hjelp fra testleder, men heller ved å prøve og feile. Vi oppfordret også brukerne til å bruke «think-aloud»-teknikken (Lazar et al., 2010, side 273) for lettere å kunne kartlegge hvilke aspekter av grensesnittet de mente var uklare. Brukerundersøkelsene ble avrundet med en uformell samtale 7, der brukerne ble oppfordret til å kommentere konseptet og komme med forslag til forbedring. I alle samtalene var vi bevisst på ikke å legge føring på deltagerne. Ifølge Toftøy-Andersen og Wold, anbefales det å være minst to tilstede i en brukerundersøkelse: en testleder og en observatør (Toftøy-Andersen and Wold, 2011, side 49). Vi fulgte denne anbefalingen, noe som førte til at vi hadde god kontroll og oversikt under testing, samt analysering av resultatene. 6 Se «Vedlegg 2-Samtykkeerklæring-Low-fidelity» og «Vedlegg 3-Samtykkeerklæring-High-fidelity» 7 Low-fidelity: individuelle samtaler, High-fidelity: fokusgrupper 11

12 Ettersom målgruppen vår var studenter, brukte vi campus på UiO som utgangspunkt for å finne representative test-brukere. Det var spesielt viktig for oss at deltagerne hadde tid og motivasjon til å gjennomføre brukerundersøkelsen. I tillegg var det ønskelig å fjerne stress og andre momenter som kunne påvirke resultatet.(lazar et al., 2010, side ) 4.2 Low-fidelity prototype Vi kom raskt i gang med å utvikle en vertikal low-fidelity prototype. Med dette innskrenket vi antall funksjoner som kunne testes, og valgte heller å gå i dybden på hver enkelt. Fremgangsmåten vi benyttet var story-cards der brukerne selv kunne oppleve en form for interaksjon med systemet. Ved å velge vertikal prototyping, begrenset vi antall story-cards som skulle inkluderes i testingen. I denne fasen hadde vi bevisst lite fokus på design av grensesnittet, for å gi brukerne muligheten til å gi tilbakemeldinger på funksjonaliteten vi hadde inkludert. Samtidig gir en papirskisse-prototype brukerne inntrykk av at det ikke er brukt mye tid på å lage den, hvilket senker terskelen for å gi konstruktiv kritikk. (Lazar et al., 2010, side 260) Målet med prosjektet var å lage en applikasjon som var lett å lære, enkel å forstå meningen bak, og lett å navigere i. For utviklingen av story-cards valgte vi derfor å legge hovedvekten på tre brukbarhetsmål: utility, learnability og efficiency. I tillegg fokuserte vi på designprinsippene mapping, consistency og affordance. Før vi startet brukertestingen gjennomførte vi en pilottest for å sikre at prototypen var klar for testing, og for å sikre at ingenting kunne virke forvirrende eller uklart. I tillegg brukte vi pilottesten til å konkretisere og forbedre oppgaver og spørsmål til brukerne. Målet for selve testfasen var å avdekke feil og mangler i grensesnittet for å kunne gjøre applikasjonen mer brukervennlig. I gjennomføringen av brukerundersøkelsen opplevde vi at de fleste brukerne var positive til utformingen av prototypen, og at navigasjonen stort sett var tilfredsstillende. Noen kommenterte at valget «Min side» var forvirrende i starten, men at dette var noe de vennet seg til. Den største utfordringen for brukerne, var at de måtte interagere med papirkort, da dette for mange føltes som en svært unaturlig brukeropplevelse. Det ble også kommentert at prototypen var visuelt kjedelig, og at dette påvirket synligheten av de ulike valgene. Da vi ikke lenger fikk ny data fra brukerne, valgte vi å avslutte testingen av low-fidelity prototypen. Dataene ble analysert og informasjonen videreformidlet til utviklerne, som vi- 12

13 dereutviklet high-fidelity prototypen High-fidelity prototype Formålet med å utvikle en high-fidelity prototype er å gjøre brukeropplevelsen mer realistisk under testing. I vårt tilfelle valgte vi å utvikle en iphone-applikasjon på bakgrunn av den første samtalen med Live, der hun nevnte at det var flere av bibliotekarene som er tilhenger av Apple sine produkter, og vi ønsket derfor å utvikle noe til denne plattformen. Ingen i gruppen hadde tidligere erfaring med å utvikle til Apple-produkter, og utviklingsprosessen ble derfor utfordrende. Utviklerne startet med å lære seg Objective-C 9, noe som viste seg å være et krevende språk å lære. Etter å ha deltatt på et foredrag om HTML5 10 og fått innsikt i dets fordeler, ble det bestemt at vi burde endre taktikk. Vi valgte heller å programmere en vanlig nettside, som på en iphone vil oppføre seg som en applikasjon.det viste seg etter hvert at vi ikke hadde tid til å perfeksjonere koden og samtidig ha tid til å teste prototypen. Vi endte derfor opp med å designe applikasjonens utseende i Adobe Photoshop, og benytte HTML5 til å lage klikkbare linker. På denne måten vil brukerne kunne gi tilbakemeldinger på design, innhold, funksjoner og brukervennlighet, på tross av at det ikke fungerer helt optimalt. Det viktigste for oss var å klare å produsere en testbar prototype, som i tillegg vil være mulig å videreutvikle dersom det er ønskelig fra oppdragsgivers side. I utviklingen av high-fidelity prototypen utvidet vi fokusområdet til å inkludere brukbarhetsmålet effectiveness, og designprinsippene constraints, visibility og feedback. Dette innebar blant annet et større fokus på design, i tillegg til at vi stilte større krav til applikasjonen som helhet. 11 Valg av testmetoder Vi valgte å fokusere på brukbarhetstesting i håp om å få en dypere forståelse av brukers interaksjon med applikasjonen. Brukbarhetstesting handler om å finne feil og mangler i et spesifikt grensesnitt der representative brukere utfører representative oppgaver. (Lazar et al., 8 «Vedlegg 5-Papir prototype» viser et oversiktsbilde over storycards vi testet helt i starten av prosjektet. 9 Dette er språket Apple bruker til sine applikasjoner 10 HTML5 er det nyeste språket for programmering av websider. 11 «Vedlegg 6-High-fidelity prototype» viser hovedsiden i den siste versjonen av prototypen. 13

14 2010, side 252) Vi var ute etter å evaluere løsninger fremfor å forstå problemer, og grensesnittet stod i fokus. En fordel med brukbarhetstesting er det kan gjennomføres med relativt få deltagere i motsetning til eksperimentell design (Lazar et al., 2010, side 255). Many people say that five users is the magic number and that five users will find approximately 80% of usability problems in an interface 12 Selve testingen av denne prototypen var en kombinasjon av formativ og summativ testing. Med dette mener vi at ikke alle funksjonene vi ønsket å implementere i en faktisk applikasjon, var tatt med i prototypen. Vi hadde imidlertid muligheten til å teste hvorvidt designet gjorde applikasjonen mer effektiv, noe som er målet med en summativ test. (Lazar et al., 2010, side 260) I likhet med low-fidelity prototypen valgte vi å gjennomføre pilottester i forkant. Her ble det spesielt viktig å presisere for brukerne at det var systemet som skulle testes og ikke dem. Gjennomføring av brukbarhetstest Vi bestemte oss for å utføre to brukertester av applikasjonen. Dette gav oss muligheten til å forbedre grensesnittet i henhold til brukernes tilbakemeldinger før andre testrunde. Deltagerne fikk de samme oppgavene i begge testrundene, og de hadde de samme forutsetningene 13. Vi hadde i utgangspunktet tenk å gjennomføre en A/B-test av vår applikasjon opp mot Universitetes egen nettside. Kravet til A/B-testinger er at begge systemene må være like ferdigstilte. Dette var ikke et krav systemet vårt oppfylte, og vi så oss derfor nødt til å velge en annen metode. (Toftøy-Andersen and Wold, 2011, side ) I begge testrundene ønsket vi å undersøke hvordan deltagerne navigerte i applikasjonen ved å gi dem konkrete oppgaver 14. I tillegg skulle brukerne utføre tilsvarende oppgaver på uio.no. Vi oppdaget raskt at det tok for lang tid å teste begge deler, og valgte derfor å avslutte testing av navigering på nettsiden til fordel for fokus på applikasjonen. Hadde vi utført en grundigere pilottest, og dermed fått en bedre oversikt over tidsperspektivet, kunne dette ha vært vurdert annerledes. Dersom vi hadde valgt eksperimentell design hadde en slik sammenlingning absolutt vært mer relevant. Applikasjonen ble testet av én til to deltagere av gangen. En fordel ved å teste med en bruker var at vi fikk bedre innblikk i hva deltageren mente uten at den ble påvirket av 12 (Lazar et al., 2010, side 263) 13 Deltagerne hadde ingen kjennskap til oppgavene og heller ingen forkunnskap om applikasjonen 14 Se «Vedlegg 4-Testplan» 14

15 andre. I testinger med to deltagere opplevde vi at vi fikk mer ut av «think-aloud»-teknikken, da det var lettere for brukerne å diskutere underveis. I begge tilfellene kunne vi se hvor brukerne gjorde feil, som i stor grad viste seg å være unødvendige operasjoner. Testing i laboratorium Vi valgte å gjennomføre testene i et laboratorium, for lettere å kunne kontrollere forstyrrende faktorer. En ulempe ved denne metoden er at brukerne utsettes for ukjente omgivelser, som kan føre til stress og ubehag. Oppgavene i seg selv kan virke krevende og enkelte brukere kan også bli redd for å gjøre feil. (Sharp et al., 2007, side ) Fordi testing i slike omgivelser krever mer av deltagere enn andre typer brukertesting, er det vanlig å gi en form for betaling i etterkant av testingen. Etter avtale med Live kunne vi i innhenting av deltagere, love dem gavekort fra Akademika pålydende 200 kr. Dette førte til en «snowball sampling», som førte til ytterligere rekruttering internt blant deltagerne (Lazar et al., 2010, side 110). Dersom vi hadde hatt bedre tid til å innhente brukere til testingen, ville vi ha satt strengere krav til utvelgelses- og demografiske kriterier. Eksempelvis bedre sjiktvis fordeling av studieprogresjon og alder, samt å inkludere studenter også utenfor UiO. For vår del var den beste måten å dokumentere det brukerne gjorde, å bruke en emulator og filme skjermen, samt ta opp lyd. På den måten kunne vi gå tilbake og se hva brukerne gjorde feil, og høre hva som ble sagt. 15 Det å bruke en emulator gjorde at testingen ble desto mer urealistisk, i den forstand at de ikke kunne bruke telefonen slik de vanligvis ville ha gjort. Fordelene veiet for oss opp for ulempene ved at det gav oss en unik mulighet til å kunne gjøre opptak av alt som ble sagt og gjort. Vi kunne blant annet se hvor de beveget musepekeren, noe som gav indikasjoner på hvorvidt de var usikre på hvor de skulle videre. Denne formen for dokumentasjon gav oss muligheten til å legge større vekt på det brukerne gjorde, enn det de sa (Toftøy-Andersen and Wold, 2011, side 73). 4.4 Resultater av testing For å bevise at noe er brukervennlig, trenger du et større statistisk grunnlag. Da 15 Samtykkeerklæringen for testing av high-fidelity prototypen stadfester at det kun er gruppens medlemmer som har tilgang til opptak og testdata. Vi ønsker ikke derfor ikke å levere dokumentasjon fra testingene. Vi åpner likevel opp for muligheten til at foreleser kan få tilgang til dette dersom det er nødvendig. 15

16 holder det ikke å teste på tre til fem brukere. Du kan derimot bevise at noe ikke er brukervennlig med bare en håndfull personer 16. Av sitatet ovenfor ser vi at det ikke er nødvendig med mange deltagere i brukbarhetstesting, noe vi erfarte at stemte i våre brukertester. Vi opplevde at en del brukere ikke alltid forstod hvordan de skulle navigere i grensesnittet, for å klare å løse oppgavene korrekt. Et eksempel på dette er funksjonen «Min side», hvor mange av deltagerne ikke forstod innholdet i funksjonen. Dette gjorde seg gjeldende i oppgaven «Hva er obligatorisk pensum i INF1300 dette semesteret?», der flere av deltagerne i ettertid forklarte at de resonnerte seg frem til at «Min side» måtte være det riktige valget. Dette er en sterk indikasjon på at funksjonen bør forbedres. Andre resultater vi merket oss var at brukerne som først testet nettsiden satt mer pris på applikasjonen, ettersom alle nødvendige funksjoner for å utføre oppgavene var samlet. De syntes også å ha en bedre forståelse av «Min side», men dette er noe som bør undersøkes videre. Vi var usikre på hvorvidt kvalitativ eller kvantitativ data var viktigst å innhente i dette stadiet av brukbarhetstesting. Valget falt til slutt på kvalitativ data, med fokus på designprinsippene mapping, affordance, constraints og feedback. I ettertid ser vi at formålet for brukerundersøkelsen kunne ha vært klarere formulert, og at vi med fordel kunne ha fokusert mer på timeperformance, taskperformance og user satisfaction (Lazar et al., 2010, side 270), for å skape en bredde i materialet. 5 Refleksjon av prosjektet Nå som vi etter fagets premisser er ferdig med prosjektet, sitter vi igjen med en high-fidelity prototype av en mobilapplikasjon, som har hovedfokus på pensum, designet for matnatstudenter. Det fungerte bra med å dele gruppen inn i to team. Vi måtte delegere en del viktige arbeidsoppgaver for å møte de utfordringer vi sto ovenfor på effektiv måte, og tok valg ut i fra den innsikten vi hadde. Vi startet så raskt som mulig med brukertester av den papirbaserte prototypen, for tidlig å få tilbakemeldinger på funksjonalitet. Flere av deltagerne uttrykket at det var vanskelig å utføre oppgavene de ble gitt, og papirskissene ble derfor forbedret på grunnlag av tilbakemeldinger fra deltagerne. 16 (Toftøy-Andersen and Wold, 2011, side 120) 16

17 Hadde vi visst i oppstarten det vi vet i dag, hadde utviklerne brukt den første tiden noe annerledes. Mye tid forsvant til å lære seg et kodespråk vi endte opp med ikke å bruke, og enda mer tid ble brukt til å prøve å lære enda flere språk. Det hadde vært til vår fordel å starte med å lage prototypen slik den ble i dag, med design av elementer i Photoshop, og enkle lenker. Det hadde gitt oss bedre tid til grundigere testing samt mer rom for videreutvikling. Videre hadde dette gitt oss muligheten til å kunne bruke tid på å lære det nye kodespråket ordentlig, slik at vi hadde kunnet overlevere et mer ferdigstilt produkt til oppdragsgiver enn vi kan i dag. Utover dette er vi rimelig fornøyde med hvordan vi har gått fram for utviklingen. 6 Videre arbeid Den siste versjonen av prototypen 17 er en mockup 18 av en applikasjon i form av en highfidelity prototype. Denne har blitt testet og utviklet iterativt, hvor vi stadig har avdekket nye problemområder. For å komme nærmere et sluttprodukt, bør utviklingen fortsette iterativt. Her tilhører det at vi må gå fra mockup prototypen til å programmere den mer omstendelig. Rent funksjonelt bør den etterhvert knyttes opp mot UiO-brukerkontoer 19, Bibsys 20, Feide 21, og StudWeb 22, for å nå det endelige målet. De enkelte designvalg og funksjoner bør hele tiden endres og testes etter impulser fra såvel diskusjoner gruppen innad som tilbakemeldinger fra oppdragsgiver og testpersoner. Vi ser i ettertid at vi ville ha vært tjent med å bruke enda mer tid på kartlegging av brukernes behov, samt å forstå eventuelle problemer ved dagens løsning. Eksperimentell design ville ha generert en deskriptiv statistikk, og generaliserbare resultater over problemer og utfordringer ved denne. Disse resultatene kunne vi videre ha sammenlignet med resultatene fra brukbarhetstestene, noe som ville ha hjulpet oss i det videre arbeidet. En alternativ vei videre kunne ha vært å utvide vår løsning til en mer generell applikasjon for biblioteket. Enkelte av deltagerne i brukbarhetstestene vi har utført, har gitt uttrykk for at applikasjonen, slik den er i dag, er litt for enkel og innholdsfattig. Det rår usikkerhet om hvorvidt dette er et ønske fra enkeltpersoner, eller om dette er et generelt behov hos studente- 17 Ingen endringer etter En mockup brukes i produksjon og baserer seg på å demonstrere og promotere et produkt, og er egnet for evaluering (Wikipedia, 2011). 19 UiO-brukerkontoer: Brukernavn og passord for inn- og utlogging bør være det samme som alle andre UiOs tjenester. 20 Bibsys: Informasjon om status på bøker 21 Feide: UiOs eksisterende innloggingssystem. Dette vil gjøre systemet sikrere. 22 Studweb: Det ideelle er å koble utdanningsplanen opp mot dette systemet. 17

18 ne. Ved bruk av eksperimentell design, og dermed flere testpersoner, ville vi kunne avdekket dette. Det er heller ikke utenkelig at funksjonalitetene vi har implentert i vår applikasjon, med fordel kan inkluderes i andre parallelle prosjekter i emnet. Før en eventuell beslutning kan tas, vil det være fordelaktig å bruke tilstrekkelig tid på å avdekke slike problemområder. I dette prosjektet var det viktig å prioritere tidsbruken på en slik måte at vi hadde tid til å teste applikasjonens hovedfunksjoner med målgruppens majoritet. I videre arbeid ville det derfor vært mer nødvendig å ta hensyn til mennesker med nedsatte funksjonsevner eller på andre måter spesielle behov. I tillegg til tidspress, er mangel på tilstrekkelig kunnskap en viktig årsak til at vi ikke har hatt muligheten til å inkludere disse i testingen. Ved universell utforming er det dessuten særlig viktig med tverrfaglig samarbeid (Toftøy-Andersen and Wold, 2011, side 62), for å sikre at alle i målgruppen blir påtenkt. Avslutningsvis vil vi anbefale at denne tjenesten blir tilgjengeliggjort på alle plattformer, eksempelvis desktop, nettbrett og andre smartphones. 7 Sluttord Etter endt prosjekt tør vi påstå at en applikasjon som i større eller mindre grad inkluderer pensumrelaterte tjenester, er noe studenter både ønsker og trenger. Samtidig virker det som om forslaget mottas positivt fra andre hold, deriblant oppdragsgiver. Selv om vi ikke er helt ferdig rent produktvis, synes vi at vi har anskaffet et godt utgangspunkt for eventuell videreutvikling. Det være om vi velger å finpusse vår egen, selvstendige applikasjon eller implementere den i en større sammenheng. Helt til slutt er vi innad i gruppen enige om at dette prosjektarbeidet og emnet for øvrig har vært en spennende og lærerik periode. 18

19 Bibliografi Lazar, J., Feng, J. H., and Hochheiser, H. (2010). Research Methods in Human-Computer Interaction. John Wiley and Sons, Ltd, Publication. ISBN: Sharp, H., Rogers, Y., and Preece, J. (2007). Interaction Design: Beyond Human-Computer Interaction. John Wiley and Sons, Ltd, Publication, second edition. ISBN: Toftøy-Andersen, E. and Wold, J. G. (2011). Praktisk brukertesting. Cappelen Damm AS. ISBN: Wikipedia (2011). Mockup. Website. lest 17: