Användbarhet

Hur en mätning av användbarhet kan genomföras kan ske genom olika typer av testning. I de genomförda testerna användes System Usability Scale (SUS) som verktyg för att un- dersöka hur användbar applikationen upplevdes. Metoden beskrivs i detalj i avsnitt 2.6.5. Att det skedde en ökning av medelvärdet från det första användartestet, med ett SUS värde på 72,5 poäng, till det andra användartestet, 82,9 poäng, innebär en ökning på 14 % (se figur 5.1). Genom testning som genomfördes med hjälp av användarcentrerad utveckling, fanns det möjlighet att ta ställning till delar av applikationen som inte utformats på ett användarbart sätt. Att det dessutom genomfördes tester kontinuerligt gav också möjligheten att ställa case-frågor såväl följdfrågor för att förstå användarens resa på hemsidan och hur denna förändrades genom de olika utvecklingsfaserna. Likt den teori som presenterades kring kvalitetsattribut, länkar, informationsplacering och förväntningar på denna typ av webbapplikation har frågor och beteenden hos användarna observerats och sedan förbättrats i så stor mån som möjligt. När applikationen sedan testats igen har alla dessa faktorer ansetts bli bättre, enligt användarna, och därmed är det med stor sannolikhet en bidragande faktor till att medelvärdet för SUS har ökat.

Som Arning et al. menar i den undersökning som genomfördes fanns det ett antal grundläg- gande funktionalitetskrav som ställdes på en webbappikation i form av en samåkningstjänst (se avsnitt 2.1.1). Om dessa funkationalitetskrav uppfylls upplevdes webbapplikation som användbar för 66 % av testgruppen. Denna teori bekräftas även av det resultat som visas utifrån SUS som visas genom den ökning på 14 % ovan då alla grundläggande funkationali- tetskrav utom prissättninginformation var uppfyllda och ett slutgiltigt resultat på 82,9 poäng av 100.

Att det under testerna uppkom en del problem med systemet till följd av den implemen- terade LinkedIn-API:n, som egentligen ska göra det lättare att logga in på applikationen, kan vid lansering av applikationen leda till brist på trovärdighet och tillförlitlighet. Enligt den presenterade teorin kring J. Nielsens kvalitetsattribut är fel i applikationen något som avseevärt kan påverka en användares uppfattning av användbarheten. Många testdeltagare uttryckte även ett behov av ett kvitto eller liknande vid genomförd betalning, något som skulle kunna öka trovärdighet och tillförlitlighet, vilket tas upp av Nielsen i avsnitt 2.4.1.3. Enligt användartesterna framkom ett resultat att det var svårt att hitta viss information.

Till exempel informationen kring bokade, genomförda och obetalda resor. När deltagarna fick i uppgift att hitta den informationen gick deltagarna till profilen. Däremot fanns det oklarheter kring flikarna “Obetalda resor “ och “Genomförda resor”, eftersom de resor man gjort också kan vara obetalda. Det uppkom alltså att orienteringen på applikationen ansågs svår, vilket kan anses vara motsägelsefullt kring det som tagits upp i teorin i avsnittet 2.2.5 kring orientering. För att uppnå en väl navigerbar och användbar applikation skulle oriente- ringen på tjänsten behöva förtydligas, specifikt på de delar av applikationen som användarna uttrycke under testerna var svåra att förstå sig på.

5.1.7 Betalning

Under utvecklingen har det varit svårt att bestämma hur priset ska sättas och betalning ske. I applikationens nuvarande form kan inte förare få betalt utan det som betalas går istället till applikationens Stripe-konto. Om plattformen ska lanseras behöver en funktion för att direkt betala förare implementeras.

Ytterligare betalningsaspekter som bör övervägas att implementeras är fler betalmetoder som Swish och faktura. Detta skulle underlätta betalningen för passageraren då det inte skulle vara tvunget att betala med kort samt att det stöds av den undersökning som Arning et al. genomförde angående de funktionskrav som användare har på ett webbaserat samåk- ningssystem [8].

Beräkningen av priset kan även förbättras. Formeln som används nu multiplicerar anta- let åkta mil med 18:50 kronor, vilket inte tar i beaktning antalet passagerare. Anledningen till maxtaket är satt på grund av gränsen innan man som förare blir deklarationsskyldig [11], vilket kan vara ansträngande om man ska använda tjänsten vardagligen. Detta behöver förbättras, till exempel genom att dividera priset som sätts nu genom antalet resenärer för att få ett bättre pris.

Samåkningstjänsten måste även vara mer transparent när det kommer till hur priset be- räknas. I nuläget finns det inget sätt att som användare kan ta reda på hur priset sätts eller vad det är baserat på. Detta är en av de grundläggande funktionalitetskraven som Arning H. al tog fram i sin undersökning [8].

5.2 Metod

I detta delkapitel diskuteras de metod-modeller som användes vid utförandet av arbetet samt utfallet av detta.

5.2.1 Förstudie

Avsnittet presenterar diskussion om metoderna som använts i förstudien. 5.2.1.1 Enkätundersökning

I början av projektet skickades en enkät ut för att undersöka behovet av en plattform för samåkning. Enkäten genomfördes med verktyget Google Form och dess grafiska utformning låg till stor del i linje med Tourangeaus riktlinjer: frågorna var fetstilta, texten var mörk och bakgrunden ljus, och i enkäten fanns inga bilder eller figurer som kunde störa responden- ten[28]. Själva enkäten hade frågor om demografi, samåkningsvanor eller transportvanor,

del svar att det saknades utrymme för svarsdeltagarna att diskutera deras synpunkter och lyfta fram problem som de såg med plattformen, detta uppmärksammades i den sista frågan då respondenterna fick svara på om det var något mer de trodde skulle vara viktigt i en plattform för samåkning. Svaren var spridda och visade på aspekter vi inte tagit i akt vid formuleringen av frågorna till enkäten.

För att öka reliabiliteten i enkätsvaren hade en fördjupad studie om enkätmetodik för bättre utformning av enkäten sannolikt resulterat i mer givande och tydligare svar. Det är också svårt att med relativt få respondenter i en homogen grupp kunna dra några slutsatser om det finns ett behov för en samåkningsplattform och hur den i så fall ska fungera. Respondenterna bestod huvudsakligen av äldre personer (57 % var över 40 år). Det är svårt att dra generella slutsatser fast en sådan grupp kan ha en annorlunda inställning till nya tekniska tjänster, som den plattform vi erbjuder, och därmed kan enkäten som helhet ge ett sken att det finns en negativ inställning till samåkning. Det hade därför varit relevant att av enkätsvaren göra tydliga uppdelningar mellan olika subgrupper, för att se hur enkätsvaren kan skilja sig och ge ett tydligare underlag för utvecklingen av applikationen. Ett ytterligare exempel är att det inte gjorts en distinktion mellan de som idag tar bil och de som inte tar bil eller personer som arbetar och som inte arbetar. Däremot gick det att urskilja pålitliga resultat i de mer allmänna frågorna: respondenterna skulle erbjuda sin bil för samåkning ifall de har en bil, arbetsgivare skulle vara mer attraktiva om de erbjuder en samåkningstjänst, billigare pris samt positiv miljöpåverkan är de faktorer som motiverar att samåka och att tjänsten är lätt att använda är viktigt.

Utöver enkätstudien hade det varit intressant om en kvalitativ undersökning genomförts, i form av intervjuer. I vissa av enkätsvaren, när respondenterna fick skriva svar på en öppna frågor, gav de konkreta förslag på behov de har och funktioner tjänsten behöver. Ofta var det aspekter som inte tagits i akt i utvecklandet av applikationen hittills eller synts i enkätens övriga svar. Mer djupgående intervjuer skulle kunna ge en bättre förståelse för användarens behov, gett projektet en bättre grund att stå på och potentiella problem med applikationen hade kunnat upptäckas och lyftas tidigare.

5.2.1.2 Prototyp

Under projektets gång utveckades två prototyper, en med låg naturtrogenhet och en hög na- turtrogenhet. Nielsen hävdade i sin jämförelse mellan utvärderingar av prototyper identifie- rades fler problem i prototypen med hög noggrannhet [33]. Till skillnad från vad Nielsen fö- reslog så upptäcktes fler problem vid konstruktionen av prototypen med lägre nogggrannhet som ritades upp på en tavla jämfört med versionen av hög trogenhet som skapades i Figma. Detta beror på hur prototyperna användes under projektet. Prototypen av högre noggrannhet användes inte gentemot försökspersoner, vilket går emot teorin om att tidigt utvädera olika koncept [32]. Prototypen fungerade som en visuellt mer avancerad version av den med lägre grad av noggrannhet som lade grunden för webbapplikationens utseende. Detta hjälpte till med utvecklingen av webbapplikationens front-end medan de funktionella problemen som skulle uppstå uppmärksammades med prototypen av låg naturtrogenhet.

5.2.1.3 User stories

Framtagningen av user stories gav en indikation på vad webapplikationen ska ha för funk- tionalitet. Det var en bra metod för att effektivt generera idéer med relevans för kund. Vikten låg dock inte i metodens skapande av idéer utan i avgränsningen av genererade idéer. Att välja bort idéer var av största vikt då projektet hade begränsad tid och begränsade resurser. Alla user stories delades in i tre rangordningar baserade på deras relevans till grundläggande funktionalitet. När alla user stories med högst prioritet blev klara var webbapplikationen i

teorin klar. Allt utöver det var bonusfunktionalitet. Denna metod med user stories var den metod som följde metodteorin mest och resultatet var bra och relevant. Det var dock synd att projektets tidsmässiga begränsningar och resursbegränsningar inte tillät en implementation av alla idéer som framkom.

Fler problem uppstod vid översättningen av user stories till konkreta uppdrag inför kodning. I Trello (en organiseringsapplikation som användes för att hantera projektet) fanns både en lista av user stories och en lista med konkreta uppdrag baserade på dessa. Detta skapade missförstånd och problem med kommunikation mellan gruppmedlemmar och user stories listan borde i ett tidigare skede ha lagts åt sidan som en checklista som användes i slutet av applikationen medan de konkreta uppdragen skulle hamna mer i centrum.

5.2.2 Implementation

Avsnittet presenterar diskussion om metoderna som använts vid implementationen, vilka slutsatser som kunder göras och vad som hade kunnat göras annorlunda.

5.2.2.1 Användartester och användarcentrerad utveckling

Att använda sig av användarcentrerad utveckling under projektet gav många nya idéer som användes för att förbättra webbapplikationen. Under de användartester som utfördes fram- kom kritik och idéer som inte övervägts tidigare. Användartester utfördes vid två tillfällen, testgrupp 1 med tre personer som baserades på en tidig version av webbapplikationen och testgrupp 2 med sex personer baserad på den nästintill färdiga applikationen.

Från testgrupp 1 framkom ett antal överlappande idéer som kunde implementeras samt några förslag som inte kunde implementeras med den tid som fanns tillgänglig under pro- jektet. Detta flöde av idéer framkom trots att metodteorin inte följdes till fullo och testgrupp 1 endast hade tre personer istället för minst fem som föreslogs av Faulkner[36]. Istället ge- nomfördes genomgående och detaljerade tester för att kompensera för det mindre antalet deltagare. Trots detta orsakade det mindre antalet testpersoner problem när resultatens skul- le tydas och analyseras vilket gjorde det svårt att dra säkra slutsatser. Risken att ett antal problem med webbapplikationen inte upptäcktes kvarstod också. En större testgrupp hade enligt Faulkner kunnat lyfta fler stora problem och underlättat att besvara frågeställningen. Användartesterna utfördes dock bättre under den andra iterationen med testgrupp 2 på sex personer. Problemet som uppstod vid detta test var en följd av att webbapplikationen var nästintill klar vilket orsakade att många ideér inte kunde implementeras innan projektets slut eller inte hade samma direkta relevans som idéerna från testgrupp 1.

Navigerings- och orienteringstesterna som genomfördes var utformade utifrån den teori som presenteras i avsnitt 2.4.4.1 och 2.4.4.2. Den största problematiken med de utformade testerna var inte själva utformadet men vad som testades. Då testerna genomfördes vid två distinkt olika iterationer av webbapplikationen fanns det olika funktionalitet som kunde mätas i webbapplikationen. Mycket av den funktionalitet som testades i det första användar- testet fanns även kvar i andra användartestet, men det hade även tillkommit mycket ny funktionalitet. Den nya funktionaliteten mättes därmed för första gången i det andra an- vändartestet och kunde inte jämföras med något tidigare resultat. Grunden i problematiken ligger därmed i att det utvecklades ny funktionalitet som inte var färdigutvecklat i första användartestet som sedan testades i andra användartestet. Därmed blir det svårt att mäta

skulle mätas var utvecklad redan i första iterationen av webbapplikationen som användes för testning för att få ett kvantitativt resultat där utvecklingen kan mätas bättre.

Det hade varit önskvärt att utföra fler tester över flera versioner av webbapplikationen för att få en tydligare röd tråd mellan testerna och utveckla webbapplikationen med ännu mer kontakt med målgruppen. Därmed går det att diskutera Faulkners teorier om testgrup- pens storlek när det kommer till mindre projekt med begränsade resurser. Ett alternativ skulle vara att testa användare i mindre grupper vid fler tillfällen för att få den tydligare kopplingen.

Testerna genomfördes av olika observatörer och antecknare. Detta kom också att i viss mån avgöra hur resultatet kan tolkas. I en del test togs relativt få eller inga anteckningar över testdeltagares beteende eller reaktioner. En tydligare genomgång före testen kunde ha gjort att testen utfördes mer enhetligt. Det kunde också varit tydligare vad som skulle utvärderas med testerna.

Hur testerna var utformade hade också stor betydelse över vilka slutsatser och analyser som kunde göras. Det hade i retrospektiv varit lättare att analysera om testerna utformats tydligare och med mer fokus på användbarhet. Framförallt var det svårt att veta hur den data som insamlats skulle användas. Det var dessutom svårt att jämföra de olika testerna, dels på grund av att antal testdeltagare skiljde sig och dels för att uppgifterna skiljer sig något. Nya funktioner testades som inte fanns i de tidigare testerna.

Många av de problem som lyfts fram under testerna har korrigerats för att göra applika- tionen mer användbar, men en del av den funktionalitet som föreslogs implementerades inte. Detta beror på att gruppen varken hade tid eller resurser till att göra det. Fler tester hade även kunnat lyfta fram fler problem och på så sätt lett till en bättre tjänst.