KomUt : Utveckling av en samåkningsplattform för företagsanställda

Kandidatuppsats, 18 hp | Industriell Ekonomi - Datateknik

Vårterminen 2018 | LIU-IDA/LITH-EX-G--2018/001--SE

KomUt - Utveckling av en

samåkningsplattform för

före-tagsanställda

KomUt - Development of a carpooling platform for employees

Jonatan Bjurenfalk

Saam Cedighi

Simon Fröberg

Oskar Holmström

Oscar Hubertsson

Axel Leth

Linda Olsson

Sara Ågren

Handledare : Sonia Sangari Examinator : Aseel Berglund

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admi-nistrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstan-ces. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchang-ed for non-commercial research and unchang-educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

c Jonatan Bjurenfalk Saam Cedighi Simon Fröberg Oskar Holmström Oscar Hubertsson Axel Leth Linda Olsson Sara Ågren

I samhället finns det en ökad medvetenhet kring miljöpåverkan och att minska utsläpp av växthusgaser. En påverkande faktor är transport i personbil till och från arbetet. För att öka nyttjandegraden av personbilar och därmed minska miljöpåverkan är en lösning att samåka. Syftet med projektet var att skapa en webbapplikation för att hjälpa de som vill samåka. För att vara effektiv och intressant för användarna behövde en sådan web-bapplikation vara användbar och lätt att navigera i, vilket stöds i tidigare undersökningar. Därför är rapportens frågeställning hur en webbapplikation för samåkning, för företag och dess anställda, designas och implementeras så att den är användbar med avseende på navigerbarhet.

Besvarandet av frågeställningen inleddes med att relevant teori om navigerbarhet och användbarhet togs fram. Efter det gjordes en marknadsundersökning, för att tydliga-re förstå målgruppens behov, och en prototyp skapades utifrån den framtagna teorin. User stories användes för att definiera applikationens funktionalitet och utvecklingen av webbapplikationen skedde parallellt med iterativa användartester, där feedbacken från testerna implementerades.

I slutet av projektet analyserades slutresultatet och varje enskilt användartest för att jämföra användarnas respons mot rådande teori, och genom det besvara arbetets fråge-ställning. Utifrån resultatet av testerna, sett till de teoretiska ramarna, visades det att två av fyra testpersoner var vilsna på webbapplikationen. Testpersonerna hade svårigheter att ta sig igenom köpprocessen. De hade bristande förståelse för vad som händer när man placerar resor i varukorg, att resorna bokas i varukorgen och att betalning av genomförda resor skedde på profilsidan. Anledningar till resultatet kan såväl bero på brister i web-bapplikationens navigerbarhet eller egenskaper hos testpersonerna. Trots detta ansågs webbapplikationen användbar i enlighet med de System Usability Test som utfördes. I sin helhet kan webbapplikationen därmed bedömas som användbar, däremot den kan inte anses uppfylla de teoretiska kraven för navigerbarhet.

Slutsatsen dras att ennavigerbar webbapplikation kan utvecklas genom att användar-na effektivt ska kunanvändar-na hitta webbapplikationens mest väsentliga funktioner. Detta kan implementeras med en tydlig navigationsbar, visuella indikationer för länkar, informa-tionsrutor, ett naturligt flöde för användaren genom sidstrukturen och att användaren kan ta sig igenom den med få steg. Detta bör specifikt tillämpas i köpprocessen, som är central i en webbapplikation för konsumenter, för att minska upplevd komplexitet och att den är användbar och navigerbar för användaren. För att webbapplikationen ska upplevas som användbar bör den innehålla de grundläggande funktionalitetskraven som ställs på en samåkningstjänst. Dessa är att kunna registrera sig, hitta en resa, skapa en resa, hitta information kring prissättning och att kunna ta bort en resa.

In our society there is an increased awareness of environmental impact and reducing greenhouse gas emissions. An influencing factor is transport in passenger cars to and from work. In order to increase the utilization rate of passenger cars and thereby reduce environmental impact, a possible solution is to carpool. The purpose of the project was to create a web application to help those who want to carpool. To be effective and interesting to users such a web application needs to be useful and easy to navigate, as supported in previous surveys. The report’s issue is therefore how a carpooling web application, for companies and their employees, is designed and implemented to make it useful with regard to navigability.

The attempt to answer the issue was initiated by finding relevant theory of navigabil-ity and usabilnavigabil-ity. After that a market survey was conducted, to better understand the needs of the target group, and a prototype was developed based on the found theory. User stories were developed to define the application’s functionality and the development of the web application took place in parallel with iterative user tests, where feedback from the tests was implemented.

At the end of the project, the final result and each user test were analyzed to compare users’ response to current theory and by answering the issue of the report. Based on the results of the tests, given the theoretical framework, it was shown that two out of four test subjects got lost in the web application. The test subjects were struggling to get through the buying process. They had insufficient understanding of what happens when placing a trip in the cart, that the trips are booked inside the shopping cart and that the payment of completed trips are found on the profile page. Reasons for the result may be due to both the weaknesses of the web application navigability or the characteristics of the test subjects. Despite this the web application was considered useful in accordance with the System Usability Test performed. In its entirety, the web application can be assessed as useful, though it can not be considered to meet the theoretical requirements for navigability. The conclusion is that a navigable web application can be developed by allowing users to effectively find the most important features of the web application. This can be imple-mented with a distinct navigation bar, visual indications for links, information boxes, a natural flow for the user through the page structure, and that the user can get through it with few steps. This should be specifically applied to the buying process, which is central to a consumer web application, to reduce perceived complexity and to be useful and navigable to the user. In order for the web application to be perceived as useful, it should contain the basic functionality requirements expected of a carpooling service. These are being able to register oneself, find a trip, create a trip, find information about pricing and to be able to remove a trip.

Innehåll

2.1.1 Samåkningssystem . . . 5 2.2 Användbarhet . . . 5 2.2.1 Användning av samåkningssystem . . . 6 2.2.2 Riktlinjer för användbarhet . . . 6 2.2.2.1 Effektivitet . . . 6 2.2.2.2 Fel . . . 7 2.2.2.3 Tillfredställande . . . 7 2.3 Navigerbarhet . . . 7

2.3.1 Vikten av god navigerbarhet . . . 7

2.3.2 En webbapplikations utformning för ökad navigerbarhet . . . 8

2.3.3 Informationsplacering . . . 8 2.3.4 Länkar . . . 8 2.3.5 Orientering . . . 9 2.3.6 Utformning av köpprocessen . . . 9 2.3.7 Startsida . . . 9 2.3.8 Karta . . . 10 2.3.9 Filtrering . . . 10 2.4 Metodteori . . . 10 2.4.1 Enkätundersökning . . . 10 2.4.2 User stories . . . 11 2.4.3 Prototyp . . . 11 2.4.4 Användartester . . . 12

2.4.4.1 Mäta användarens orienteringsförmåga på en hemsida . . . . 12

2.4.4.2 Mäta navigerbarhet . . . 13

2.4.4.3 System Usability Scale . . . 13

3.1.1 Besvarande av frågeställning . . . 16 3.1.2 Behov . . . 17 3.1.3 User Stories . . . 18 3.1.4 Prototyp . . . 18 3.2 Implementation . . . 18 3.2.1 Arbetsmetodik . . . 18 3.2.2 Användartester . . . 18 3.2.2.1 Navigerbarhetstest . . . 18 3.2.2.2 Orienteringstest . . . 19

3.2.2.3 System Usability Scale . . . 20

3.3 Utvärdering . . . 21 4 Resultat 24 4.1 Förstudie . . . 24 4.1.1 Enkätundersökning . . . 24 4.1.2 Marknadsföringsplan . . . 24 4.1.3 User stories . . . 25 4.1.4 Prototyp . . . 25 4.2 Implementation . . . 26 4.2.1 Användartester . . . 27 4.2.1.1 Första användartestet . . . 27 4.2.1.2 Andra användartestet . . . 29

4.2.2 Funktionalitet och design . . . 32

4.2.2.1 Navigationsmeny . . . 32 4.2.2.2 Startsida . . . 33 4.2.2.3 Hitta resa . . . 34 4.2.2.4 Skapa resa . . . 35 4.2.2.5 Logga in . . . 38 4.2.2.6 Registrera . . . 38 4.2.2.7 Varukorgen . . . 40 4.2.2.8 Profilsidan . . . 40 4.2.2.9 Databasen . . . 42 4.2.3 Systemarkitektur . . . 43 4.2.3.1 Front-end . . . 44 4.2.3.2 Back-end . . . 44 4.2.4 Köpprocessen . . . 44 4.3 Slutligt utvärderingstest . . . 45

4.3.1 Navigerbarhet - Smiths L-formel . . . 45

4.3.2 System Usability Scale . . . 47

4.3.3 Utvärderingsformulär . . . 47 5 Diskussion 49 5.1 Resultat . . . 49 5.1.1 Förstudie . . . 49 5.1.1.1 Enkätundersökning . . . 49 5.1.1.2 User stories . . . 49 5.1.2 Implementation . . . 50 5.1.2.1 Navigationsmeny . . . 50 5.1.2.2 Startsida . . . 50 5.1.2.3 Hitta resa . . . 51 5.1.2.4 Skapa resa . . . 52

5.1.2.7 Profilsidan . . . 53 5.1.3 Användartester . . . 54 5.1.4 Slutgiltigt utvärderingstest . . . 54 5.1.4.1 Köpprocess . . . 55 5.1.4.2 Testpersoner . . . 55 5.1.4.3 Casets utformning . . . 56

5.1.5 System Usability Scale . . . 56

5.1.6 Användbarhet . . . 57 5.1.7 Betalning . . . 58 5.2 Metod . . . 58 5.2.1 Förstudie . . . 58 5.2.1.1 Enkätundersökning . . . 58 5.2.1.2 Prototyp . . . 59 5.2.1.3 User stories . . . 59 5.2.2 Implementation . . . 60

5.2.2.1 Användartester och användarcentrerad utveckling . . . 60

5.2.3 L-formeln . . . 61

5.2.4 Källkritik . . . 62

5.3 Arbetet i ett vidare sammanhang . . . 62

5.3.1 Samhälle . . . 62

5.3.2 Integritet och säkerhet . . . 63

5.3.3 Företag . . . 63

6 Slutsats 64 Litteratur 66 A Appendix A - Enkätundersökning 69 B Appendix B - Marknadsföringsplan 83 C Appendix C - Kravspecifikation för webbapplikation 99 D Appendix D - Användartester 102 E Appendix E - User Stories 119 E.1 User Stories . . . 119

F Appendix F - Slutgiltigt utvärderingstest för webbapplikationen 122 F.1 Slutgiltigt utvärderingstest . . . 122

Figurer

3.1 Tillvägagångssättet gruppen använde för att besvara frågeställningen. . . 16

3.2 Ett exempel på enkätens grafiska utformning. . . 17

3.3 Exempel på kritisk väg för ett användartest. . . 23

4.1 Versionen av låg naturtrogenhet som togs fram innan implementationen. . . 26

4.2 Hög naturtrogenhet versionen som togs fram innan implementationen. . . 26

4.3 Webbapplikationens utseende under det första användartestet. . . 27

4.4 Webbapplikationens utseende under det andra användartestet. . . 29

4.5 Navigationsmeny. . . 33 4.6 Startsida. . . 34 4.7 Hitta resa. . . 35 4.8 Skapa resa. . . 37 4.9 Sida för inloggning. . . 38 4.10 Sida för registrering. . . 39 4.11 Varukorgen. . . 40

4.12 Profilsidan, när användaren klickat på knappen redigera. . . 40

4.13 Profilsidan, på fliken ”Kommande resor”. . . 41

4.14 Profilsidan, på fliken ”Resehistorik”. . . 41

4.15 Profilsidan, på fliken ”Obetalda resor”. . . 41

4.16 Fönstret för betalning. . . 42

4.17 ER-diagram för databasen. . . 43

4.18 Modell av systemet där server, klient och databas illustreras med respektive verktyg. 43 5.1 Grafen visar värden för de olika SUS-testerna i förhållande till målvärdet på 68. . . 57

Tabeller

3.1 Formulär för användartestcase . . . 19

3.2 Formulär för användartestcase . . . 19

3.3 Formulär för Orienteringstest . . . 20

3.4 Formulär för utvärderingstest baserat på kravspecifikation . . . 21

4.1 Utdrag av user stories . . . 25

4.2 Sammanställning av det första orienteringstestet. . . 28

4.3 Sammanställning av det första navigeringstestet. . . 28

4.4 Sammanställning av system usability scale-enkäten från det första användartestet. 29 4.5 Sammanställning av testpersoner ett till tre orienteringstest i det andra användar-testet. . . 30

4.6 Sammanställning av testpersonerna fyra till sex orienteringstest i det andra an-vändartestet. . . 30

4.7 Sammanställning av testpersonerna ett till tre navigeringstest i det andra an-vändartestet. . . 31

4.8 Sammanställning av testpersonerna fyra till sex navigeringstest i det andra an-vändartestet. . . 31

4.9 Sammanställning av system usability scale-enkäten från det andra användartestet. 32 4.10 Webbapplikationens bokningsprocess . . . 47

4.11 Sammanställning av system usability scale-enkäten från utvärderingstestet. . . 47

4.12 Summerade svar till formulär för utvärderingstest. . . 47

E.1 User stories - Hög prioritet . . . 120

E.2 User stories - Medel prioritet . . . 120

1

Inledning

I följande avsnitt presenteras motiveringen till varför detta arbete om en webbapplikation för samåkning genomförs. Dessutom presenteras arbetets syfte, dess relevanta frågeställningar samt avgränsningar.

1.1 Motivering

Dagens städer konsumerar två tredjedelar av världens energi och står för 70 % av växthus-gasutsläpp, enligt en rapport från Förenta Nationerna (FN). Rapporten påpekar att städers tillväxt och människors behov av mobilitet sätter krav på framtidens smarta städer [1]. I en smart stad ligger fokus inte enbart på att minska utsläpp utan även på att minska trafiken [2]. Samåkning kan vara en del av lösningen till problemen ovan.

Organiserad samåkning är en bransch som just nu befinner sig i startgroparna med flera etablerade aktörer på svenska marknaden, som exempelvis Comovee1 _{och WayWay}2_.

En-ligt en marknadsundersökning genomförd som förstudie till detta arbete svarar 75,5 % av respondenterna att de aldrig samåkt till sitt arbete (Appendix A). Utöver det uppger 93,4 % av respondenterna att de aldrig använt sig av en samåkningstjänst. Vidare finns det andra fördelar med att samåka, som exempelvis att det finns möjlighet att dela på kostnaderna samt minska varje persons klimatpåverkan [3]. Detta projekt har som mål att skapa en web-bapplikation med hög användbarhet så att samåkning kan ske på ett smidigt och effektivt sätt.

I enkätundersökningen på 333 personer konstaterades att de 57 % av svarsdeltagarna som ställde sig negativa till samåkning ansåg att det var osmidighet, mindre flexibilitet och be-hovet av att anpassa sig till andra som gjorde att de inte skulle kunna tänka sig att samåka. Trots detta svarade en majoritet av respondenterna att ett företag som erbjöd samåkning via ett samarbete med en samåkningstjänst skulle göra arbetsplatsen mer attraktiv (Appendix A). Trots respondenternas negativa inställning till samåkning kan det finnas ett behov av en

1_{https://www.comovee.com/} 2_{https://www.wayway.se/}

tjänst som möjliggör samåkning. Enligt tidigare studier, presenterade i teorin, går det att se att personer med erfarenhet av samåkning har en mer positiv inställning än de som inte samåkt tidigare. Webbapplikationen bör därför ha som uppgift att sänka barriärerna för samåkning, bland annat genom att motverka de negativa aspekter målgruppen ser med samåkning genom att göra det smidigt, mer flexibelt, och lättare att anpassa sig till andra samåkare. Det kan också påpekas att enkäten endast frågar om generella inställningar till samåkning, och inte om samåkning med hjälp av en webbapplikation. Detta medför att målgruppen fortfarande kan vara positivt inställd till en tjänst för samåkning.

Syftet med KomUt, den utvecklade webbapplikationen, är därmed att göra det enkelt för människor som bor i samma närområde att samåka till deras respektive arbetsplatser. Tjänsten riktar sig främst mot vardagliga resor till och från arbetsplatser där föraren får en ekonomisk ersättning mot att hämta upp andra resenärer. Föraren skall på ett enkelt sätt kunna lägga in varifrån och när den åker tillsammans med slutdestination. Passagerarna ska på samma vis kunna se olika startpunkter samt vad slutdestinationen är för dessa och anmäla sig till en resa.

För att denna tjänst ska bli så framgångsrik som möjligt är det viktigt att webbapplika-tionen designas med målet att den ska ha hög användbarhet, vilket innebär att plattformen ska vara smidig att använda samt enkel att förstå [4]. Lyckas inte detta finns det risker i att användarna inte fortsätter använda tjänsten. Enligt International Organisation for Standardi-zation (ISO) - som skapar internationella standarder - definieras användbarhet som till vilken grad en användare kan använda en tjänst för att uppnå ett specifikt ändamål på ett effektivt och tillfredställande sätt [5]. En funktion som gör det enkelt att specificera varifrån man åker samt vart man ska kommer därför att bli viktig. Vidare kommer även navigerbarheten av tjänsten att bli viktig för att göra den så tillfredsställande och effektiv som möjligt. Naviger-barhet definieras enligt Zhu, Greenwood, Zhang som hur enkelt en användare kan hitta den information som söks efter på en webbapplikation när den navigerar på den [6].

1.2 Syfte

Syftet med projektet är att undersöka hur en webbapplikation för samåkning kan implemen-teras och designas så att den uppfattas som enkel att använda för företagsanställda vid pend-ling till och från arbetsplatser.

1.3 Frågeställning

Hur kan en webbapplikation för samåkning riktad mot företagsanställda designas och im-plementeras för att uppnå god navigerbarhet och användbarhet?

1.4 Avgränsningar

Arbetet riktas primärt mot företagsanställda och framtida företagsanställda i form av studen-ter. Webbapplikationen kommer inte att vara tillgänglig för utomstående, det innebär att det kommer gå att skapa eller boka in sig på resor under arbetets gång annat än på den lokala versionen på hemsidan.

Webbapplikationen utvecklas för användning av webbläsaren Chrome och i arbetet kommer inte det tas hänsyn till andra webbläsare.

testerna för att kunna dra några slutsatser om hur minnesbar webbapplikaktionen är. Även lärbarhet testas inte och tas därför inte med i arbetet.

2

Teori

Nedan presenteras den teoretiska referensram som använts för att genomföra projektet. Den-na består av relevant teori om samåkningstjänster tillsammans med teori för att besvara fråge-ställningen. Specifikt fokus har legat på navigerbarhet. Avslutningvis presenteras teori kring de metoder som kom att användas under projektets gång.

2.1 Samåkning och samåkningstjänster

Idag åker allt fler personer bil och trafikstockningar är ett växande problem i storstäder världen över. Under rusningstrafiken när människor ska till jobbet ökar risken för trafik-stockning, trafikolyckor, högre bränslekostnad och ökade luftföroreningar [7]. En lösning på detta kan vara samåkning [8]. Samåkning innebär att två eller fler personer åker tillsammans till en gemensam destination, där passagerare delar på resekostnaden [9].

Det finns flera olika skäl till att samåka. En studie av Arning et al., som undersökte samå-kares anledningar till att samåka, angav att de tre största faktorerna i fallande ordning är ekonomiska motiv, mindre miljöpåverkan och sociala aspekter [8]. En studie genomförd av Trivector Traffic AB, angav samma anledningar i samma ordning som ovan [10].

Studierna ovan har också identifierat potentiella barriärer som kan göra att folk väljer att inte samåka. Arning et al. menar att det upplevs som besvärligt eller krångligt att behöva koordinera resan med andra, behöva ta omvägar och hämta upp andra personer. De menar också att säkerhet är en viktig fråga för potentiella samåkare, då utlämning av personuppgif-ter samt att åka med främlingar ses som potentiella barriärer [8].

Enligt Arnings et al.s studie har de med tidigare erfarenhet av samåkning en mer posi-tiv inställning till samåkning än de som inte samåkt innan [8]. Det är något som Trivectors studie stödjer. Vidare följer även att de som samåkt tidigare visade sig också vara mer flexibla och mer villiga att ta omvägar än de som inte samåkt [10].

mellan de parter som är inblandade. Enligt skatteverket har föraren skyldigheten att göra en inkomstdeklaration då föraren får mer än 18:50 kronor per mil [11].

2.1.1 Samåkningssystem

Deltagarna i studien av Arning et al. uppgav följande funktionskrav på ett webbaserat samåkningssystem [8]:

• Hög transparens om resans kostnad innan resans start - detta för att minska chansen att prutning uppstår mellan passagerare och förare.

• Hur kostnaden beräknats • Information om skattesatser

• Bonussystem som ger förmåner ju mer man använder tjänsten • Fakturasystem som fakturerar varje månad

• Information om försäkingar, olyckor eller förseningar, rättigheter och skyldigheter som samåkare

• Funktion för att kunna se ett dokument med all reseinformation • Ett system för att kunna betygsätta passagerare och förare • Parkeringsrabatt eller bränslerabatt

• Personlig information ska vara säker

• Man måste registrera sig för kunna använda tjänsten och söka resor

Dessa funktionskrav kokades sedan ner till mer allmänna funktioner som var grundläg-gande för att ett samåkningssystem ska upplevas som användbar och navigerbar. Dessa funktionaliteter var att kunna registreras sig, hitta en resa, skapa en resa, hitta information om hur priset av resan beräknas samt kunna ta bort en resa. Arning et al. testar i studien dessa faktorer och visar utifrån testning att om man kombinerar de ovan nämnda funktions-kraven med tydliga navigationselement bidrar detta till att 66 % av testgruppen upplever samåkningsplattformen som användbar. [8].

I en studie av Andrew et al angav prospektiva användare att de som passagerare tydligt vill kunna se en status på en samåkningsförfrågan. Detta kan t.ex. vara ”förfrågan skickad” eller ”bekräftad”. Detta innebär att en passagerare ska kunna se i vilket skede ens bokning är. Ett annat krav deltagarna hade var ett sätt att checka in och ut från bilen för att bekräfta att resan skett. Liksom i Arning et al.s studie begärdes ett protokoll för regler, ansvar och vad som skulle hända vid en eventuell försening [12].

2.2 Användbarhet

Användbarhet är en viktig kvalitetsfaktor när det kommer till programutveckling. Brist på användbarhet är enligt J. Nielsen räknat som en av de största orsakerna till att interaktiva system inte fungerar när människor användander dem [4]. Enligt Seffah och Donyaee är användbarhet den viktigaste kvalitetsfaktorn i ett webbaserat projekt och med dålig använd-barhet kan det uppstå svårigheter för webbapplikationen [13].

För att uppnå användbarhet har The International Organization for Standardization ut-vecklat standarder för användbarhet och användbarhetsorienterad design uppdelat i tre kategorier. Dessa tre kategorier är [5]:

• Hur bra användare fullgör uppgifter och hur nöjda de är med applikationen • Design av gränssnittet och interaktion med detta

• Aktiviteter som utförs under produktutvecklingen för att nå ett uppsatt mål

Enligt Calisir et al. är användbarhet ett viktigt element i webbapplikationer. Användare pri-oriterar användbarhet över en webbapplikations funktionalitet. Anses inte en webbapplika-tion användbar av användare kommer den att väljas bort. Det är därför relevant för web-bapplikationer att utvecklas med hänsyn till användbarhet. Tas detta inte i åtanke kan en lanserad webbapplikation misslyckas vid lansering oavsett dess funktionalitet om den inte anses användbar [14].

2.2.1 Användning av samåkningssystem

För att lyckas lansera ett samåkningssystem krävs även att samåkarna har vissa förutsätt-ningar. Dessa är bland annat regelbundna arbetstider, längre färdväg, möjlighet att åka med personer av samma kön samt liten tidsskillnad jämfört med att åka på egen hand [10]. Enligt Arning et al.s tester av användbarhet hade formuleringar större påverkan på an-vändbarheten och effektiviteten än designen av applikationen. Effektivitet innebär i det här fallet antal uppgifter som löstes rätt per tidsenhet. Det framgick även i studien att det största problemet i användning är navigeringssvårigheter. Detta gällde i alla åldrar av deltagare och problemet kan komma att påverka kundens nöjdhet med tjänsten. För att underlätta navi-geringen förespråkar Arning et al. att använda sig av klart och tydligt språk som är lätt att förstå. Då minskar risken för att missförstånd och förvirring ska uppstå under användning. Utöver det är det viktigt att användaren hela tiden vet var i systemet och i vilken process den befinner sig i [8].

Arning et al. rekommenderar att designen av ett samåkningssystem ska följa använda-rens mentala modell av hur en samåkning bestäms. De menar att användaren först tänker på vart den vill åka ifrån, innan den tänkt på om den är förare eller passagerare [8].

2.2.2 Riktlinjer för användbarhet

I ISO 9241-11 definieras riktlinjer för användbarhet som:

Den grad i vilken användare i ett givet sammanhang kan bruka en produkt för att uppnå specifika mål på ett ändamålsenligt, effektivt och för användaren tillfredsställande sätt.

Hur olika modeller och standardiserade arbetsformer för att uppnå användbarhet skiljer sig åt baseras på vilket syfte applikationen ska användas i [13]. När användbarhet ska appliceras på en applikation kan detta mätas med olika typer av kvalitetsattribut. J. Nielsen anser att användbarhet är nödvändigt för att en applikation ska överleva. Genom att ta hänsyn till ytterligare kvalitetsattribut, förutom de som nämns i ISO 9241-11, såsom antal fel, anser J. Nielsen att en mer genomgående förståelse för användbarhet kan uppnås [4].

2.2.2.1 Effektivitet

Effektivitet innebär hur snabbt en användare kan ta sig igenom en uppgift efter inlärning. Effektivitet bidrar till ändamålsenligheten som innebär att en användare spenderar en rim-lig mängd resurser i relation till hur effektivt användaren tog sig igenom uppgiften [13]. En

försvårar förmågan att ta sig mellan webbapplikationens olika delar. Därför är det relevant att parrallelt med utveckling av en användbar webbapplikation också göra den navigerbar. Eftersom navigerbarhet behövs för att en webbapplikation ska fungera är det därför ett om-råde som bör fokuseras på i utvecklingen av en webbapplikation [16].

2.2.2.2 Fel

Fel syftas till antalet faktiska fel, hur stora dessa fel är och hur snabbt programmet kan åter-hämta sig, anser J. Nielsen som en av de viktigaste kvalitetsattributen för ett system. Ifall ett system inte fungerar och klarar av de uppgifter som det ska kommer inte en användare välja att fortsätta använda applikationen. Detta mäter på hur tillförlitlig ett program är och påverkar därför den upplevda av tillfredsställelsen [4].

2.2.2.3 Tillfredställande

Hur tillfredställande ett program är refererar till hur användare uppfattar produkten efter användning och hur användaren upplevde en behaglig känsla under och efter användning [4].

2.3 Navigerbarhet

Navigerbarhet syftar på hur lätt användare kan uppfylla det de avsåg att göra på en webbap-plikation. Navigerbarhet bör ha hög prioritet hos webbdesigners, detta för att få webbappli-kationer lyckas om inte användarna effektivt kan hitta informationen de söker på applika-tionen [17]. Enligt Kincl och Strach uppfattar en användare att webbapplikaapplika-tionen har bättre kvalitet om den har god navigerbarhet [18].

2.3.1 Vikten av god navigerbarhet

Min Chen och Young U. Ryu menar att dålig navigerbarhet är det problem som får flest användare att lämna en webbapplikation och sedan vända sig till en konkurrent. Detta gör att god navigerbarhet blir avgörande för webbapplikationens överlevnad och konkurrens-kraft [19]. Webster och Ahuja menar att ett vanligt problem med dålig navigerbarhet är att användare tenderar att “gå vilse” i webbapplikationen och tappar uppfattningen om var de är, vilket i sin tur kan leda till frustration, förlorat intresse och en mätbart lägre användaref-fektivitet [20].

Enligt Vaseem Basha Shaik och Shakeel Ahamed Pathan är den huvudsakliga anledningen till att hemsidor saknar god navigerbarhet på grund av att webbutvecklare saknar förståelse över hur webbapplikationen ska utformas med tanke på vad användarna efterfrågar. De menar även att webbapplikationens utformning oftast baseras enbart på utvecklarnas egna omdöme [21].

God navigerbarhet kan hos användaren bidra till en positiv inställning mot företaget med applikationen och stimulera nätköp, medan dålig navigerbarhet sällan attraherar nya an-vändare, utan stöter bort användarna och bidrar till att de inte återvänder. Att reducera desorienteringen hos användarna har inte bara prestationsfördelar utan möjliggör även för användaren att vara mer engagerad i deras webbinteraktion. Att användaren känner att webbapplikationen fångar dennes intresse är ett viktigt mål när det kommer till navi-gationdesign, vilket ökar sannolikheten att användarna återvänder till webbapplikationen [20].

2.3.2 En webbapplikations utformning för ökad navigerbarhet

Min Chen et al. menar att utformningen av en webbapplikation kan ske på två olika sätt när det kommer till att öka navigerbarhet. Den första metoden är Web personalization. Denna metod innebär att “skräddarsy” webbapplikationen utifrån de behov som specifika använ-dare har genom den data som samlats från användarbeteenden. Den andra metoden kallas Web transformation. Web transformation innebär en omstrukturering av webbapplikationen för att underlätta navigationen för en större användarbas istället för att fokusera på specifika användare [19].

2.3.3 Informationsplacering

F-modellen är en modell framtagen av Jacob Nielsen genom att studera hur hemsidebesö-kare läste informationen på hemsidan när det inte finns några tydliga visuella referenser som attraherar besökarens blick. F-modellen säger att en hemsidebesökare först läser ho-risontellt längst upp hemsidan. Sen flyttar besökaren ner blicken och fortsätter att läsa in informationen horisontellt, men täcker ett mindre område än innan. Slutligen läser besökaren informationen vertikalt till vänster på hemsidan [22].

Om webbutvecklaren inte har designat hemsidan så att besökaren blir guidad till den mest relevanta, intressanta och mest hjälpsamma informationen kommer besökaren hitta sin egna väg. Besökaren tenderar att följa den väg som kräver minst ansträngning och att fixera blicken där de började att läsa, vilket ofta är längst upp till vänster [22].

2.3.4 Länkar

Hemsidor är nätverk av länkade sidor där en bra hemsida gör det enkelt för dess användare att navigera runt på den. Ett sätt att förenkla navigationen är genom att lägga till genomtänkt placerade länkar på hemsidan menar Paranjape, West, Zia och Leskovecet. De menar att länkarna är essentiella för att användarna ska kunna hitta den informationen de letar efter samt hitta ny information [23].

Farkas och Farkas hänvisar till tre faktorer när det kommer till effektiv design av länkar. Den första faktorn är att tydligt indikera att en länk är en länk. Detta kan göras genom att signalera med hjälp av upphöjda knappar eller text. Farkas och Farkas menar att användare ska veta vad som är en länk för att inte gå miste om viktig information [17].

Den andra faktorn är att försäkra att länkar är synliga och att de blir upptäckta. Farkas och Farkas menar att detta kan göras genom att designa minimala hemsidor där länkar är lätta att upptäcka. Länkar ska även placeras högt upp på hemsidan så användaren kan hitta dem utan att behöva skrolla [17].

Den tredje faktorn är att indikera länkens destination. Detta kan göras genom markera länkarna med en tydlig text som förklarar vart länken leder en. Författaren menar även att det kan vara fördelaktigt att använda sig av layering techniques, vilket innebär att lägga till tilläggstexter eller alternativa texter som dyker upp när muspekaren placeras på länken. Dessutom kan även grafiska länkar i form av ikonlänkar ha en signifikant fördel i jämförelse mot textlänkar. Detta är på grund av att en ikonlänk med en igenkännbar ikon snabbare kan förmedla användaren vart länken leder. Ikonlänkar kan även formas och framställas som mer visuellt intressanta och attraktiva [17].

2.3.5 Orientering

Det är inte garanterat att startsidan är den första sidan som en användare besöker. Av den anledningen är det viktigt att ge användaren tillräckligt med information som inte bara säger hur användaren tar sig vidare därifrån, utan också var användaren befinner sig just nu. Susan Farell skriver om olika hjälpmedel som en webbutecklare kan implementera för besökare att kunna orientera sig lättare [7].

• Logga och varumärkesstrategi: Att visa en logga visar äganderätt för innehållet. Log-gan bör vara länkad till startsidan. Annan varumärkesstrategi, till exempel varumär-ken, färgpaletter och signaturfonter kan användas till att påminna besökare om en or-ganisations trovärdighet. Vanligtvis brukar man finna dessa högst upp till vänster på hemsidan, vilket brukar vara det som syns på skärmen först, oberoende av skärmstor-lek [24].

• Orienteringsändringar: Att en länk eller ett grafiskt element (flik, knapp, märke, etc.) relaterad till orientering blir mer visuellt framträdande när en användare väljer det äm-net. Ofta uppnås detta genom att ändra färgen eller att flytta det grafiska elementet, eller både och [24].

• Rubriker: Vänsterjusterade rubriker hjälper vänster-till-höger-läsare att snabbt kunna scanna efter nyckelord. Flera nivåer av rubriker kan visas samtidigt för att ge mer kon-text och orienterings-information [24].

• Titel på webbfönstret: HTML-titlar syns längst upp på varje webbfönster eller flikar. Beskrivande, unika titlar hjälper med att indikera ägandeskap, information om organi-sationen och om sidans innehåll [24].

• URL: En väl vald, mänskligt läsbar hemsideadress är viktigt för delning, trovärdighet, igenkänning och att kunna erinra sig. En sidas webbadress kan hjälpa till att kontextu-alisera innehållet genom att visa en del av informationsarkitekturen [24].

2.3.6 Utformning av köpprocessen

Det finns två faktorer som bidrar till att användare har en bättre upplevelse vid nätköp, menar Dutta, Jarvenpaa och Tomak. Enligt författarna är den första faktorn bekvämlighet. Användaren har nämligen en mer positiv upplevelse om hemsidan uppfattas vara bekväm att använda. Den andra faktorn är ansträngning: kunderna tenderar nämligen att ha en bättre upplevelse om de upplever mindre kognitiv ansträngning [25].

Enligt författarna är antal steg som kunden behöver gå igenom vid köpprocessen väldigt avgörande när det kommer till upplevelsen. De menar att kunden oftast måste gå igenom många steg vid köpprocessen, så som inmatning av personlig information, kreditkortinfor-mation, fraktadress och konfirmering av köpet. Författarna menar att om kunden behöver gå igenom flera steg vid köpprocessen kommer kundens uppmärksamhet öka för betalningen. Om betalningen tar för lång tid kan det hos kunden uppkomma en känsla av att förlora något. Därför borde köpprocessen utformas på ett sådant sätt att den har så få steg som möjligt. Detta för att eliminera tankar om att inte genomföra köpet och istället bidra till fler impulsiva köp. [25].

2.3.7 Startsida

Startsidan är en viktig del av webbapplikationen. Denna kan förtydliga applikationens funk-tion och hur användaren ska navigera sig igenom de olika sidor som finns. Farkas och Farkas betonar vikten av att förse användare med en kort, sammanfattande och iögonfallande be-skrivning av orienteringen på hemsidan. Denna information ska inte gömmas bakom reklam

eller överskuggas av andra element. Genom att strukturera upp webbapplikationens flöde förtydligas de olika sidornas identitet och funktion vilket gör förstagångsanvändare säkrare och förenklar navigationen [17].

2.3.8 Karta

Om en webbapplikation använder sig av geografiska positioner kan en interaktiv karta för-bättra en användares upplevelse. Enligt Fu et al. kan företag använda bland annat Google Maps Application Programming Interface (API) för att erbjuda interaktiv kartfunktionalitet på sin webbapplikation. Applikationen erbjuder navigation, körstreckor, adresser och till-hörande information mellan startpunkt och destination på kartan. Det är ett av de starkaste verktygen tillgängligt för företag i dagsläget. Användningen av detta API skapar ett beroende av Google. Detta är dessutom dess styrka då Googles databaser och kartpositioner överskri-der allting ett mindre företag, vars fokus inte ligger i navigationssystem, kan framställa. En-ligt Fu et al innebär detta att ett kart-API som Google Maps inte bara kan öka interaktiviteten för användaren och förbättra användarupplevelse utan kan också öka webbapplikationens funktionalitet [26].

2.3.9 Filtrering

När en användare söker en specifik produkt på en webbapplikation krävs filtreringsfunktio-ner för att förenkla åtkomsten till produkten. Nudelman föreslår två typer av effektiva, navi-gerbara och användbara filtreringsmenyer i webb-butiker. Antingen filtrerar användaren via kategorier och tillhörande underkategorier för att hitta sin produkt genom successiv sökning eller genom en meny med direkt filtrering baserad på varors egenskaper som namn, antal eller annan information. För att göra filtreringen användbar för användaren är det viktigt att filtreringen går igenom hela sortimentet av aktuella produkter och att inmatningsfälten finns lättillgängliga samt är tydliga och intuitiva [27].

2.4 Metodteori

Nedan följer en beskrivning av den bakomliggande teorin för de metoder som använts i för-studien, implementation och utvärdering av arbetet.

2.4.1 Enkätundersökning

Enkätundersökningar gör det möjligt att på ett smidigt sätt komma åt information i ett tidigt skede i projektet. Enligt Tourangeau ska frågorna i en enkätundersökning skrivas med fet stil och betoningar i frågor skrivas med kursiv stil. Vidare ska bakgrunden i undersökningen vara ljus med mörk text på, samt att det inte ska vara bilder eller figurer som kan störa respondenten [28].

Likert- modellen är en frågestruktur som kan användas för att bygga upp frågor i enkä-ter. Respondenter får välja på en skala hur denne håller med ett visst påstående. Till vänster på skalan är det svar som “Jag håller inte med alls” eller “Jag känner inte igen mig alls”. I mitten på skalan är det ett neutralt svar som “Det spelar ingen roll”. Till höger på skalan är det ofta ett jakande svar som håller med påståendet som “Jag håller med helt”. Eftersom denna typ av frågor är vanliga i enkäter är respondenter ofta vana och bekväma med att svara på dessa. Formatet kan även bli justerat till att värdera en mängd olika åsikter och attityder [29].

2.4.2 User stories

User stories är användares förväntningar på funktioner och funktionalitet i ett system. Det är en metod som används för att bestämma vad ett system ska kunna göra [30]. En user story beskriver funktionaliteten, i ett system eller en mjukvara, som skapar värde för användaren. Tanken är att det skulle kunna vara användaren eller kunden som skrivit önskemålen, därför är det inget krav att tekniska specifikationer finns med [31].

User stories behöver inte vara särskilt detaljrika och det är bättre att ha många beskriv-ningar än för långa. Samtidigt är för abstrakta eller ospecifika stories svårhanterliga. En tumregel är att ha user stories som kan kodas och testas mellan en halv dag och två veckor, om en eller några få personer jobbar på storyn. En mer omfattande story kallas en ’Epic’, och kan delas upp i flera mindre stories. Samtidigt behöver stories inte delas upp för att täcka alla detaljer. Detaljer behöver inte heller skrivas ner, det kan vara bättre att diskutera dem med prospektiva användare [31].

Efter att en story implementerats kan funktionen verifieras med ett slutgiltigt utvärde-ringstest. Utvärderingstestet ska visa eller motbevisa att storyn fyller sitt syfte och fungerar som användaren tänkt sig [31].

Bra stories ska vara: • Oberoende • Förhandlingsbara

• Värdefulla för användare eller kunder • Uppskattningsbara

• Små • Testbara

User stories ska även sorteras enligt en prioriteringslista [31].

2.4.3 Prototyp

En prototyp kan delas in i två kategorier, låg naturtrogenhet och hög naturtrogenhet, vilket innebär hur trogen prototypen är en verklig produkt. Trovärdigheten är beroende den grad av noggrannhet prototypen är utförd med. Den lägre graden av naturtrogenhet kan till exem-pel skapas med penna och papper. Prototypen ska ge en enkel och skissartad utgångspunkt i hur produkten kan se ut och hur den fungerar. Vid utvärdering av prototypen tar personen som utvärderar rollen som dator och förmedlar flödet mellan olika tillstånd i produkten. Tanken är att tidigt i utvecklingsprocessen skapa en prototyp för att få input från användaren och förståelse för vilken riktning produkten ska utvecklas, utan att generera stora kostnader i tid och pengar. Den är därför fördelaktig tidigt i utvecklingsprocessen när det är aktuellt att pröva flera olika koncept. Nackdelen är att den inte exakt representerar produkten, vilket gör det svårare att identifiera de problem som kan existera i prototypen [32]. Nielsen visar i en jämförelse mellan utvärderingar av prototyper med låg och hög noggrannhet att det identifierades fler problem i prototypen med hög noggrannhet [33].

Prototyper med hög grad av noggrannhet har grafiska representationer av den funktio-nalitet som ska finnas i slutprodukten. Användaren ska kunna interagera med prototypen genom att till exempel kunna skriva in data i fält, klicka på knappar och öppna nya fönster.

Prototypen kan vara utförd på sådant sätt att användaren inte kan särskilja den från en slut-produkt i en kontrollerad testmiljö. Den höga graden av noggrannhet medför däremot större tidsåtgång och ekonomiska kostnader, och används gärna i ett senare utvecklingsskede när man vill utvärdera ett fåtal, eller endast ett, val av gränssnitt [32].

Utöver att utforma sin prototyp efter låg och hög noggrannhet kan en horisontell eller vertikal prototyp skapas. En horisontell prototyp är en ytlig representation av hela pro-dukten. Den ger en överblick av produktens olika delar och flödet mellan dessa, även när underliggande funktionalitet inte existerar. En vertikal prototyp representerar funktionali-teten av en specifik del av produkten, utan att möjligheten att pröva hur den hänger upp med övrig funktionalitet. Den kan utföras med hög noggrannhet då funktionaliteten behö-ver vara exakt representerad och begränsningen i det som representeras motibehö-verar de höga ekonomiska kostnaderna och tidsåtgång [34].

2.4.4 Användartester

Anledningen till användandet av användartester är för att se till att produkten eller tjänsten är användbar för målgruppen. Till exempel kan produktens navigerbarhet och användbarhet utvärderas [35].

Då användartester genomförs är det viktigt att inte för få deltagare testas. Enligt Faulkner krävs det minst fem testdeltagare för att få en bra bild av vilka problem applikationen har [36]. Är det mindre än fem deltagare kan det bli ett spritt resultat vilket gör det svårt att hitta problemområden som behöver lösas. Fem testdeltagare visar i snitt 85,55 % av problemen, medan snittet för en testgrupp med mer än 15 deltagare är över 95 %. Det är även viktigt att välja vilka deltagare som ska testas. Användarna som testas ska komma från projektets målgrupp då det är på det sättet rätt problem uppdagas [37].

Under ett användartest får deltagaren en specifik uppgift, där personen i fråga uppma-nas att använda sig av ”think aloud”. Metoden går ut på att användaren säger det som den tänker på medan uppgiften utförs. Om personen är tyst under en tid ska denne påminnas om att säga det den tänker på av en observatör. Denna metod påverkar endast tiden det tar att utföra uppgiften och inte resultatet i slutändan [38].

Enligt Gwizdka och Spence kan problem med webapplikationen identifieras med en testper-son lyckas eller misslckas med givna caseuppgifter. Exempel på caseuppgifter är faktatest som handlar om att lokalisera specifik information eller ta reda på vart användaren befinner sig i webbapplikationen och navigationstest där testpersonen navigerar sig igenom webap-plikationen för att utföra uppgiften. Skulle testpersonerna misslyckas med dessa uppgifter förmedlas information inte tydligt nog och navigering är inte intuitiv [39].

2.4.4.1 Mäta användarens orienteringsförmåga på en hemsida

Webbutvecklare har ofta en klar bild över hur deras applikation fungerar, och kan därför ha problem med att utvärdera om hemsidan är navigerbar eller inte. Susan Farrell beskriver att webbutvecklare ofta använder allt för subtila orienteringsindikatorer, då de själva lägger märke till alla designfunktioner och för att de vet hur orienteringen på applikationen ska gå till. Eftersom besökare kan vara nya på hemsidan, eller att de använder den sällan, är det flera element som potentiellt lockar deras intresse. Av den anledningen menar Susan Farrell att signaler som kan vara distraherande och självklara för webbutvecklaren blir ofta förbisett

väntas att finnas när applikationen öppnas upp för allmänheten, är på plats när den testas. Det är sådana designelement som troligast kommer ha störst inverkan på testpersonens uppmärksamhet [24].

Susan Farrell beskriver hur testning av en användares orientering kan göras: 1. Visa olika sidor på din hemsida, en i taget, utan att navigera till dem

2. Säg till testpersonen: “Låtsas att du just har kommit till den här sidan. Var är du på hemsidan?”

3. Om de ger ett svar (rätt eller fel), fråga: “Hur ser du det?”

4. Om de säger att de inte är säkra, fråga: “Vad förväntar du dig att se för att hjälpa dig att veta var du är?”

5. Om de fortfarande inte är säkra på var de är, fråga: “Vad skulle du vanligtvis göra för att lista ut var du är?”

2.4.4.2 Mäta navigerbarhet

För att kunna mäta om en webbapplikation har god navigerbarhet skriver Krahmer och Um-melen om Smiths L-formel som kan visa hur vilsen en användare är på hemsidan:

L= d✓_N S ´1 ◆2 +✓ R N ´1 ◆2

Formeln bygger på användarens interaktion med noder, där noder är de sidor som webbap-plikationen läser in. N är antalet unika noder användaren besöker under tiden hen söker, S är det totala antalet noder användaren besöker under sökandet och R är det minimala antalet noder som krävs för att användaren ska kunna hitta det hen söker. Teoretiskt har L-formeln ett spann från 0 (användaren är inte vilsen alls: N = S = R, i.e. ingen skillnad mellan den faktiska vägen och den kortaste möjliga vägen) till 2 (helt vilsen). I praktiken kommer ald-rig en användare få ett värde av 2, då det totala antalet länkar på hemsidan gör att N har en övre gräns (en användare kan inte se fler unika länkar än de som finns på hemsidan). Enligt Smiths observationer, kan en användare anses vara vilsen för värden större än 0,42 [40]. Enligt Gwizdka och Spence kan tid spenderad på en hemsida agera som en indikator på lostness vid en webnavigeringsuppgift. Längre tid spenderad av en användare på en uppgift utan att lösa den ökar troligheten för att hen är vilsen. Går det för lång tid jämfört med förutbestämda gränser kan navigeringsuppgiften anses misslyckad. Misslyckas användare med en uppgift kan faktorer som påverkar detta hittas med hjälp av att användaren utö-var think-aloud, tänka högt, för att indikera utö-varför de misslyckades och blev vilsna. Enligt Gwizdka och Spence kan antal musklick agera som en ytterligare indikation på hur vilsen användaren när de använder webbapplikationen. Avgår antalet klick från förväntade vägen och antalet klick på en navigeringsuppgift finns moment på webbapplikationen som försäm-rar navigerbarhet. Även dessa kan identifieras med hjälp av att låta användaren tänka högt under uppgiften [39].

2.4.4.3 System Usability Scale

En metod för att snabbt och enkelt mäta en produkts eller applikations subjektiva användbar-het är System Usability Scale (SUS) som kan användas på en rad olika produkter och tjänster. En av fördelarna är att den idag är industristandard och kan användas för att jämföra olika produkter både nationellt och internationellt. Den kan användas på mindre testgrupper och

samtidigt ge tillförlitliga resultat. Testet går ut på att användaren får svara på tio fördefini-erade frågor med ett till fem som svar, där ett är att inte hålla med alls och fem är att man håller med starkt. [41].

Poängen räknas ut på följande vis:

• För varje udda numrerad (1, 3, 5 ...) fråga subtraheras värdet på svaret med 1. • För varje jämn numrerad (2, 4, 6 ...) fråga subtraheras värdet på svaret från 5. • Värdena summeras och multipliceras med 2,5.

Produkten får poäng i intervallet 0-100, där allt över 68 räknas som över medel. Högre poäng indikerar bättre användbarhet. Resultatet ska inte tolkas som procent [41].

2.4.4.4 Användarcentrerad utveckling

Användarcentrerad utveckling av interaktiva system avser på fyra designaktiviteter som bidragande faktorer för att uppnå användbarhet genom hela utvecklingen av en applikation. Till dessa aktiviteter räknas till att förstå och specificera användningssammanhanget, att specificera användarnas krav, ta fram designlösningar som möter användarnas krav och att utvärdera dessa lösningar mot krav [42].

Syftet är att med ett användarperspektiv sätta alla frågor som rör applikationen i relation till applikationens främsta användare. Detta kan göras bland annat genom en uppsättning av user stories som matchas med användarnas krav på systemet. Enligt Bengt Göransson, som skrivit en bok om användarcentrerad design, kan användbarhet vara svårt att mäta och svårt att sätta i ett helt objektivt perspektiv och anser därmed att användbarhet är ett relativt be-grepp. För att lyckas med en användbar applikation krävs det främst ett användarfokus, ett aktivt involverande av användarna, ett pågående prototypande samt explicita och medvetna designaktiviteter. Alla funktioner i en applikation ska vara väl motiverade och grundade i ett kundperspektiv i relation till mätetal för användbarhet för att lyckas med en utveckling av en fullt användbar applikation [43].

2.4.5 Slutgiltigt utvärderingstest

Utvärderingstester genomförs i slutet av utvecklingen av mjukvaruprojekt. Syftet är att testa systemet så det uppfyller den kravspecifikation som definierats i projektets inledande skede. Det utvärderingstest som genomförs är inriktat mot användarna och fokuserar på funktio-nalitet. Enligt Hambling och Goethem är det viktigt att sätta realistiska krav på sina utvär-deringstestet. Vidare menar de det finns 3 nivåer av kritisk funktionalitet som bör testas vid utvärderingstestet:

• Essentiella funktioner – utan dessa kan systemet inte uppnå sina affärsmål.

• Viktiga funktioner – är inte kritiska för användandet men systemet kommer ej att pre-stera på en bra nivå utan dessa.

• Kosmetiska funktioner – funktioner som höjer användbarheten.

Eftersom att utvärderingstestet sker i slutskedet av utvecklandet av mjukvaran är det för-hoppningsvis enbart kosmetiska funktioner som kommer att testas [44].

information som eftersöks. Slutligen definieras de steg som användarna kommer att göra testerna i för att få reda på den eftersökta informationen [44].

3

Metod

Nedan beskrivs de metoder som användes under projektet. Den förstudie, imlpementation och utvärdering som användes.

3.1 Förstudie

En förstudie genomfördes i syfte att kartlägga behovet som kan finnas av den tilltänkta tjäns-ten tillsammans med vilken funktionalitet som efterfrågas. I förstudien planrades besvaran-det av frågeställningen och besvaran-det togs fram en litteraturstudie, en enkätundersökning och två prototyper.

3.1.1 Besvarande av frågeställning

Figur 3.1: Tillvägagångssättet gruppen använde för att besvara frågeställningen. Under förstudien planerades det hur frågeställningen skulle besvaras. Inledningsvis togs re-levant teori fram. Exempelvis hur navigerbarhet testas och hur många personer en testgrupp ska innehålla för att få bra respons. Efter det utfördes en marknadsundersökning för att se

Utvecklandet av webbapplikationen planerades sedan ske parallellt med iterativa användar-tester. Den feedback som mottogs från användartesterna skulle sedan implementeras om möjligt. Slutresultatet, samt varje iterativt användartest, skulle sedan analyseras för att till-sammans med teorin besvara frågeställningen. Figur 3.1 illustrerar tillvägagångsättet som planerades under förstudien.

3.1.2 Behov

För att undersöka ett behov av tjänsten genomfördes en kvantitativ enkätundersökning som riktades mot företagsanställda och studenter som representerar framtida företagsanställda. Utformandet av enkätfrågorna (Appendix A) utfördes med fokus på intresset för dessa typer av tjänster, vad som skulle efterfrågas i dem, samt tidigare erfarenheter av samåknings-tjänster. En majoritet av frågorna var utformade så att respondenten får ett flertal alternativ denne kan välja som svar. Detta för att få så tydliga svar som möjligt och säkerställa att respondenterna tyckte att enkäten var enkel att förstå och svara på.

Enkäten skapades även i syfte att identifiera och förstå potentiella målgrupper. Enkätens spridning var viktig för att få många svar och samtidigt få en heterogen grupp av respon-denter. Anledningen till att en heterogen grupp av respondenter eftersöktes var för att få mer nyanserade svar och på ett tydligare sätt representera målgruppen. Av svaren i enkätun-dersökningen (Appendix A) kunde behov bekräftas och dementeras. Frågorna i enkäten var delvis utformade enligt likert-like modellen och delvis med ja- och nejfrågor.

Enkäten skickades ut till studenter vid Linköpings universit och företagsanställda på fö-retag vid Science Park Mjärdevi. Detta gjordes genom sociala medier i kanaler för studenter som studerar till civilingenjör i Industriell Ekonomi och via företagskontakters mailadresser. Exempelvis skickades enkäten ut i företagets Ericssons intranät i Linköping. Enkäten var in-delad i avsnitten “Om dig”, “Samåkning” och “Användbarhet i applikationer”, där frågorna i enkäten inte var obligatoriska. Själva utformningen av enkäten skapades med det digitala verktyget Google Forms och representerades grafiskt med fetstilta frågor, mörk text med ljus bakgrund och inga bilder eller figurer på sidan, se figur 3.2.

3.1.3 User Stories

Målet med user stories var att skapa användares förväntningar på funktionaliteten i webbap-plikationen. Då user stories skapades fick hela gruppen vara med och bidra med idéer. En utsedd ledare för mötet skapade en tankekarta på en whiteboard-tavla för att kartlägga de idéer som genererades under mötet. Idéer rangordnades sedan baserat på hur väl de uppfyll-de webapplikationens syfte och mål (se 1.2). Sedan prickauppfyll-des olika koncept in och uppfyll-det blev tydligt vad som eftersöktes i en samåkningstjänst. Dessa berättelser låg sedan som grund för projektets produktbacklogg.

3.1.4 Prototyp

Under förstudien arbetades två prototyper fram, en med låg noggranhet och en med hög. Prototypen med låg noggrannhet var utformad med penna på whiteboardtavla medan pro-totypen med hög noggranhet byggdes i webbapplikationen Figma1_{. Figma är en}

webbase-rad applikation för att utveckla grafiska prototyper. Den gav dessutom möjligheten att öka noggrannheten genom att implementera interaktivitet i prototypen och att enkelt översätta grafiska element till Hypertext Markup Language (HTML) och Cascading Style Sheets (CSS). Detta för att påskynda övergången från prototyp till fungerande produkt.

3.2 Implementation

Nedan presenteras implementationsdelen av metoden som redovisar hur webbapplikatio-nen, med avseende på användbarhet och navigerbarhet för användaren, togs fram med hjälp av olika metoder och verktyg.

3.2.1 Arbetsmetodik

Allt arbete utfördes med hjälp av användarcentrerad utveckling (se 2.4.4.4) i flera iteratio-ner och i slutet av varje iteration utfördes användartester baserade på användbarhet och navigerbarhet. Med hjälp av testerna upptäcktes problem under utvecklingsstadiet. En an-nan anledning till att jobba iterativt var att målgruppen kunde integreras i utvecklingen av applikationen, då kunde deras respons användas för att förbättra och få bort otydligheter. Responsen användes även för att specificera krav och se till att de uppfylldes.

3.2.2 Användartester

När applikationen utvecklades utfördes användartester för att se till att slutprodukten skulle bli användbar i enlighet med Rinder (se 2.4.4). Testerna kunde visa på brister i navigerbarhet eller användbarhet som då kunde åtgärdas innan applikationens färdigställande.

Alla deltagare plockades från den tilltänkta målgruppen, framtida och nuvarande före-tagsanställda. Respondenterna hittades genom att kontakta företag där deras anställda erbjöds att delta i användartesterna. Då detta skulle ge ge data som var relevant för vi-dareutveckling. De specifika uppgifterna utformades efter teorin om hur navigerbarhet och användbarhet kan mätas (se 2.4). Det vill säga uppgifter som testade implementerade funktioner i applikationen. Det utfördes orienterigstest, navigeringstest och SUS-frågor efter testen.

terades vad testpersonerna sade under uppgifterna. Eftersom fler funktioner skapats i web-bapplikationen till det andra testet tillkom fler fråger för att testa dessa, se tabell 3.2 .

Tabell 3.1: Formulär för användartestcase

Uppgift Success

(ja/nej) Antalklick Tid (s) Förväntattal klick och tid an-(klick/sekunder)

Kommentar

Skapa ett konto - - - 6/45

-Logga in - - - 4/15

-Skapa en resa - - - 7/50

-Hitta den resan du just skapade. Vad tror du skulle hän-da om du trycker på den?

- - - 3/50

-Hitta resan från Lynch Street 64 till Woodpoint Road 59. Hur många lediga platser finns i bilen?

- - - 3/50

-Tabell 3.2: Formulär för användartestcase

Uppgift Success

(ja/nej) Antalklick Tid (s) Förväntattal klick och tid an-(klick/sekunder)

Kommentar

Skapa ett konto (kan välja att göra det med LinkedIn)

- - - 8/45

-Skapa en resa - - - 8/50

-Hitta den resan du

just skapade - - - 3/50

-Boka in dig på två

resor - - - 3/15

-Hitta din profil och

kommande resor - - - 1/5

-Gå till din profil

och fyll i fälten - - - 6/40

-Avboka en av re-sorna du bokat ti-digare

- - - 1/10

-Betala resan du

bo-kat in dig på - - - 7/30

-3.2.2.2 Orienteringstest

Orienteringstestet gick ut på att användaren startade på en specifik sida och blev utfrågade om sidans upplägg vilket baserades på Farrells metod för att testa orientering i ett system (se 2.4.4.1). Anteckningar togs över kommentarer som gavs av testdeltagare.Innan testet började gavs en kort presentation om plattformen och dess syfte. I tabell 3.3 presenteras det formuär som användes för att dokumentera orienteringstestet.

• Visa olika sidor på applikationen, en i taget, utan att låta testpersonen se hur du kom-mer dit.

• Säg till testpersonen: ”Låtsas att du just har kommit till den här sidan. Var är du på hemsidan?”

• Om de ger ett svar (rätt eller fel), fråga: ”Hur ser du det?”

• Om de säger att de inte är säkra, fråga: ”Vad förväntar du dig att se för att hjälpa dig att veta var du är?”

• Om de fortfarande inte är säkra på var de är, fråga: ”Vad skulle du vanligtvis göra för att lista ut var du är?”

Tabell 3.3: Formulär för Orienteringstest

Uppgift Success

(ja/nej) Kommentar Gå till startsidan. Fråga var de

tror att de är. -

-Gå till hitta-resa sidan. Fråga var

de tror att de är. -

-Gå till skapa resa-sidan. Fråga

var de tror att de är. -

-Gå till registrera-sidan. Fråga

var de tror att de är. -

-Gå till profilsidan. Fråga var de

tror att de är. -

-3.2.2.3 System Usability Scale

System Usability Scale(SUS) är tio fördefinierade frågor om hur användbart systemet upp-levdes. Efter att testpersonerna slutfört testernas navigerbarhets- och orienteringstester fick de svara på SUS-frågorna med ett av fem svar på skalan ett till fem, där ett är ”håller inte alls med” och fem motsvarar ”håller med helt”.

Därefter sammanfattades svaren till ett poäng i intervallet 1-100. Poängen beräknades på följande vis:

• För alla frågor med udda nummer, subtrahera 1 från poängen • För alla frågor med jämna nummer, subtrahera poängen från 5

• Summera de nya, uträknade poängen och multiplicera summan med 2.5 Påståendena som besvarades var följande:

1. I think that I would like to use this system frequently. 2. I found the system unnecessarily complex.

6. I thought there was too much inconsistency in this system.

7. I would imagine that most people would learn to use this system very quickly. 8. I found the system very cumbersome to use.

9. I felt very confident using the system.

10. I needed to learn a lot of things before I could get going with this system

3.3 Utvärdering

För att utvärdera hur mjukvarusystemet genomfördes ett slutgiltigt utvärderingstest på web-bapplikationen (se 2.4.5). Utvärderingen bestod av tre delar: en caseuppgift där testpersonens lostness mättes med Smiths L-formel, ett utvärderingstest baserat webbapplikationens krav-specifikation och ett SUS-test.

Caseuppgiften för lostness var en större uppgift än tidigare användartester som skulle testa all funktionalitet på webbapplikationen. Testpersonen skulle:

• Skapa en resa

• Boka en resa från Ljungvägen 12 i Halmstad till Slottgatan 54 i Örebro • Betala alla resor

• Redigera informationen i din profil

För att simulera en ny användare fick testpersonerna inte veta att en profil skulle skapas för att kunna skapa resor utan endast delmålen ovan förklarades. När denna uppgift hade genomförts beräknades användarens vilsenhet (lostness) med hjälp av Smiths L-formel (se 2.4.3.2). För att kunna värdera resultatet som mottogs utifrån Smiths L-formel måste det minimala antalet noder som krävdes för att användaren ska hitta det hen söker bestämmas, R, se figur 3.3 för den kritiska vägen noder. Detta gjordes genom att gå igenom de kritiska stegen som användaren var tvungen att ta på den kritiska vägen genom testet och definiera varje steg i den kritiska vägen som en nod. Utifrån användarens respons och L-formeln kunde webbapplikationens navigerbarhet sedan bedömmas.

I (Appendix C) finns den kravspecifikation som utvärderingstestet utgick från. Med hjälp av kravspecifikationen identifierades olika områden som behövde testas. Testet utformades där-för där-för att motsvare en bekräftelse på att allting i kravspecifikationen hade implementerats. Utformningen av testet kan ses i tabell 3.4.

Tabell 3.4: Formulär för utvärderingstest baserat på kravspecifikation

Fråga Success

(ja/nej) Tyckte Du att webapplikationen var lätt att förstå sig på? -Tyckte Du att det var lätt att navigera runt mellan de olika

sidor-na?

-Uppstod det fel med applikationen medan Du utförde uppgifter-na?

-Upplevde Du att det var behagligt att använda applikationen?

-Applikationens hemsida har en navigationsbar där kunden kan logga in/ut, kontakta organisationen, boka resa, se sin profil (om inloggad).

-Användaren kan interagera med företagsloggan för att ta sig till startsidan.

-Startsidan har en interaktiv knapp som tar användaren till en re-gistreringssida eller log-in sida.

-Användaren kan, genom länkade knappar ta sig till hitta-resa-sidan samt skapa-resa-hitta-resa-sidan från starthitta-resa-sidan. -Användaren kan registrera sig på Registrera-sidan genom att fyl-la i Namn, Email, Lösenord, Företag.

-Användaren kan logga in på Login-sidan med sin registrerade email, lösenord och submit.

-Användaren kan ta sig från Login-sidan till registersidan med en interaktiv länk.

-Användaren kan logga in och registrera sig via Linkedin. -Användaren kan som förare ange startpunkt och destination på Boka Resa-sidan.

-Användaren kan som förare ange antal platser i bilen på Boka Resa-sidan.

-Användaren kan som förare ange avgångstid på Boka

Resa-sidan.

-Användaren kan som förare ange datum för resan på Boka Resa-sidan.

-Användaren kan som förare ange datum för resan på Boka Resa-sidan.

-Användaren kan som förare se sin rutt på en karta. -Användaren kan som passagerare ange startpunkt och destina-tion på Boka Resa-sidan.

-Användaren kan som passagerare ange datum för resan. -Användaren kan som passagerare ange önskad avgångstid. -Användaren kan som passagerare få förslag på resor efter sin sökning.

-Användaren kan som passagerare boka flera resor genom att klicka på bokningsknappar.

-Användaren kan som passagerare gå vidare från bokningsförslag till sin varukorg.

-Användaren kan som passagerare se sina bokade resor i en

“va-rukorg” med summerat pris.

-Användaren kan som passagerare avbryta sitt köp eller ta bort objekt i sin varukorg genom att klicka på “kryss”-knappar.

-Användaren kan som passagerare betala sina resor genom att skriva in Email, Kontonummer, CVS, och klicka “betala”.

-Användaren kan se sin profil efter att hen loggat in. -Användarens profil innehåller namn, företag, telefonnummer, beskrivning.

-Från sin profil kan användaren länkas till sina tidigare resor. -Från sin profil kan användaren se hur mycket pengar hen är skyl-

-Inbokade resor kan avbokas och användare skall få en notifika-tion om resan avbokats.

-På profilsidan finns det en “redigera info”-knapp där använda-ren kan ändra sin info.

-Det SUS-test som genomfördes för att mäta användbarhet var samma fördefinerade test som används vid de tidigare användartesterna och dess frågor kan hittas i 3.2.2.3.

4

Resultat

I detta kapitel presenteras resultatet som erhållits under arbetet och utvecklingen av webbap-plikattionen KomUt. Kapitlet behandlar följande delar:

• Förstudien - Resultat från marknadsplanen, enkätundersökningen, user stories och pro-totyperna.

• Implementation - Den fullt utvecklade webbapplikationen, dess funktionalitet och tek-niska struktur.

• Utvärdering - Resultat från det slutgiltiga utvärderingstestet.

4.1 Förstudie

Här presenteras resultatet från marknadsplanen, enkätundersökningen, user stories och pro-totyperna. Den fullständiga marknadsplanen och enkätsvaren resovisas i (Appendix B) re-spektive (Appendix A).

4.1.1 Enkätundersökning

Endast 27,9 % av de drygt 330 tillfrågade sa att samåkning är ett alternativ för dem. Av de som svarade att det inte var ett alternativ nämnde majoriteten att det skulle vara omständligt att anpassa sig till andras scheman. Om samåkning erbjöds som tjänst av företaget svarade majoriteten 73,2 % att de inte skulle använda det. Trots det svarade 80,4 % att de skulle erbju-da sin bil om företaget skulle ha en samåkningstjänst. Majoriteten av de tillfrågade svarade även att de varken hade samåkt eller använt en samåkningstjänst tidigare. 46,9 % sa att det skulle vara en mer attraktiv arbetsplats om de erbjöd samåkning.

4.1.2 Marknadsföringsplan