ChiliChallenge : Utveckling av en användbar webbapplikation

Linköpings universitet SE–581 83 Linköping

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 18hp | TDDD83 Kandidatprojekt datateknik

2017 | LIU-IDA/LITH-EX-G--17/029--SE

ChiliChallenge

–

Utveckling av en användbar webbapplika on

ChiliChallenge

–

Development of a web applica on with good usability

Grupp 4: Carolina Broberg, Oscar Ek, Linus Gålén, Anders Kratz,

Andreas Niki dis, Fredrik Rundberg, Jakob Sanne, Johanna Trouvé

Handledare : Erik Berglund Examinator : Aseel Berglund

Upphovsrä

De a dokument hålls llgängligt på Internet – eller dess fram da ersä are – under 25 år från publice-ringsdatum under förutsä ning a inga extraordinära omständigheter uppstår. Tillgång ll dokumen-tet innebär llstånd för var och en a läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och a an-vända det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrä en vid en senare dpunkt kan inte upphäva de a llstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För a garantera äktheten, säkerheten och llgängligheten finns lös-ningar av teknisk och administra v art. Upphovsmannens ideella rä innefa ar rä a bli nämnd som upphovsman i den omfa ning som god sed kräver vid användning av dokumentet på ovan beskrivna sä samt skydd mot a dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannensli erära eller konstnärliga anseende eller egenart. För y erli-gare informa on om Linköping University Electronic Press se förlagets hemsida h p://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 star ng from the date of publica on barring excep onal circumstances. 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 unchanged for non-commercial research and educa onal purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are condi onal upon the consent of the copyright owner. The publisher has taken technical and administra ve measures to assure authen city, security and accessibility. According to intellectual property law the author has the right to be men oned when his/her work is accessed as described above and to be protected against infringement. For addi onal informa on about the Linköping University Electronic Press and its procedures for publica on and for assurance of document integrity, please refer to its www home page: h p://www.ep.liu.se/.

© Grupp 4: Carolina Broberg, Oscar Ek, Linus Gålén, Anders Kratz, Andreas Niki dis, Fredrik Rund-berg, Jakob Sanne, Johanna Trouvé

Sammanfattning

This report examines how a web application in e-commerce is created with a focus on good usability. The usability areas studied are navigability, reliability and how an effective purchasing process is designed. Based on established theory of usability, a web application that sells chili peppers has been created. User tests have been used as an evaluation method to review if usefulness has been achieved. During the project, three qualitative tests have been made and based on the results of these, along with established theory, functionality and design have been changed to improve usability. The conclusion indicates that it is possible to create an application that is considered useful in terms of the three main areas.

Denna rapport undersöker hur en webbapplikation inom e-handel skapas med fokus på god användbarhet. De användbarhetsområden som studerats är navigerbarhet, pålitlig-het och hur en effektiv köpprocessen utformas. Utifrån etablerad teori om användbarpålitlig-het har en webbapplikation som säljer chilifrukter skapats. Användartester har använts som utvärderingsmetod för att granska om användbarhet åstadkommits. Under projektet har tre kvalitativa tester gjorts och utifrån resultatet av dessa, tillsammans med etablerad teori, har funktionalitet och design ändrats för att förbättra användbarheten. Slutsatsen indikerar att det är möjligt att skapa en applikation som anses ha bra användbarhet utifrån de tre huvudområdena.

Författarnas tack

Vi vill tacka vår handledare Erik Berglund för många goda och insiktsfulla samtal. Detta stöd har varit mycket värdefullt under projektet. Vidare vill vi tacka Aseel Berglund för alla goda tips och information. Vi vill även passa på att tacka våra opponenter och användartestare , då deras kommentarer och insikter hjälpt oss att driva projektet vidare. Sist men inte minst ska Mattias Sundmark ha ett stort tack för hans insatser under demonstration av ChiliChallenge.

Innehåll

2.2 Användbarhet . . . 4 2.3 Navigation . . . 4 2.4 Pålitlighet . . . 9 2.5 Effektiv köpprocess . . . 11 2.6 Teori för användbarhetstestning . . . 14 2.7 Enkätundersökning . . . 17 2.8 Brainwriting . . . 17 3 Metod 19 3.1 Förstudie . . . 20 3.2 Implementation . . . 20 3.3 Utvärdering . . . 21 4 Resultat 23 4.1 Förstudie . . . 24 4.2 Implementation . . . 24

4.3 Utvärdering och testgrupper . . . 31

5 Diskussion 38 5.1 Resultatdiskussion . . . 39 5.2 Metoddiskussion . . . 46 6 Slutsats 50 Litteratur 52 A Appendix A: Användbarhetstester 57

A.1 Uppgifter för användbarhetstest . . . 58

A.2 Resultat av användbarhetstest . . . 59

A.3 Enkätresultat . . . 61

B Appendix B: Marknadsföringsplan 65 B.1 Inledning . . . 66

B.2 NABC-analys . . . 66

B.3 Omvärldsanalys . . . 67

B.4 Mikroomgivningen (Porters femkraftsmodell) . . . 68

B.5 SWOT-analys . . . 69 B.6 TOWS-analys . . . 70 B.7 Marknadsstrategi . . . 71 B.8 Marknadsmål . . . 72 B.9 STP-Analys . . . 72 B.10 Marknadsmix . . . 73 B.11 Statistik Marknadsundersökning . . . 74

Figurer

2.1 Anledningar till varför användare lämnar köpprocessen . . . 12

2.2 Förhållanden mellan olika användbarhetsmått . . . 14

4.1 Prototyp till . . . 24

4.2 Navigationsmeny 1, Startsida oscrollad . . . 25

4.3 Navigationsmeny 2, Startsida scrollad . . . 25

4.4 Navigationsmeny 3, Köpprocessen . . . 25

4.5 Navigationsmeny 4, inloggad användare . . . 25

4.6 Fot . . . 26

4.7 Knappar . . . 26

4.8 Databas i Postgresql ER-diagram . . . 27

4.9 Startsida ChiliChallenge . . . 28 4.10 ”Om”-sida ChiliChallenge . . . 28 4.11 LoginModal . . . 29 4.12 RegistrernigModal . . . 29 4.13 FelmeddelandeForm . . . 30 4.14 Köpprocess, steg 1 . . . 30 4.15 Köpprocess, steg 2 . . . 30 4.16 Köpprocess, steg 3 . . . 31 4.17 Köpprocess, steg 4 . . . 31 4.18 Köpprocess, steg 5 . . . 32 4.19 Köpprocess, steg 6 . . . 32 4.20 Köpprocess, steg 7 . . . 33

4.21 Utseende när en person utmanas . . . 33

4.22 Två utmaningar . . . 34

4.23 Betalning . . . 35

4.24 Bekräftelse . . . 36

4.25 Enkätfrågor . . . 36

A.1 Resultat Test 1 . . . 62

A.2 Resultat Test 2 . . . 63

A.3 Resultat Test 3 . . . 64

B.1 SWOT-diagram ChiliChallenge . . . 69

Tabeller

2.1 Designregler köpprocess . . . 13 2.2 10 mått på användbarhet . . . 15

1.1. Syfte

Idag är internet större än någonsin, utvecklingen går snabbt [30], samtidigt som fler av oss väljer att använda internet för att utföra många dagliga sysslor. En av de sysslor som i allt större utsträckning utförs på internet är dagligvaruhandel. Under 2016 ökade livsmedelshan-deln på internet med 30 % [47]. Detta i kombination med visat intresse att köpa en present online till en vän utifrån genomförd marknadsundersökning (se avsnitt B.11), skapades iden att utveckla en e-butik som erbjuder användare att köpa chilifrukter till bekanta.

Inom e-handel finns många konkurrerande webbapplikationer med varierande utformning och uppskattning hos användarna. Varför vissa webbapplikationer uppskattas eller föredras framför andra är inte alltid uppenbart. Ofta vet kanske inte en användare varför den föredrar en webbapplikation framför en annan. En anledning till att applikationer uppskattas är att de är användbara. Det som gör att en viss applikation upplevs användbar kan bero på en kombination av många faktorer. Då begreppet användbarhet är mycket brett har detta projekt valt att fokusera på navigerbarhet, pålitlighet och en effektiv köpprocess.

1.1 Syfte

Syftet med detta projekt är att utveckla en användbar webbapplikation inom e-handel som ska vara navigerbar, pålitlig och ha en effektiv köpprocess. Applikationen som utvecklas ska sälja chilifrukter där användaren uppmuntras att köpa produkterna till bekanta.

1.2 Frågeställning

Hur kan en webbapplikation inom e-handel skapas för att den ska vara användbar med avse-ende på navigerbarhet, pålitlighet och en effektiv köpprocess.

1.3 Avgränsningar

Arbetet i rapporten fokuserar på hur en webbapplikation utvecklas med avseende på använd-barhet med avseende på navigeranvänd-barhet, pålitlighet och en effektiv köpprocess. En effektiv köpprocess syftar på användarens uppfattning av köpprocessen både i form av att denne ska känna sig trygg och ha god förståelse för köpprocessen, alltså inte den faktiska säkerheten under köp utan snarare den upplevda säkerheten. Vidare framställs inga verkliga produkter i utvecklingen av applikationen och köp genomförs enbart i ett teststadie, alltså görs inte heller verkliga transaktioner. Webbapplikationen som utvecklas är dock full fungerande och skulle kunna tas i bruk i ett framtida stadie.

Användartester som genomförs på webbapplikationen görs av studenter med god insikt i webbprogrammering. Resultatet av användartesterna kan därav i viss mån anses vara vinklat. Vidare har även webbappliaktionens syfte och koncept utformats redan i ett tidigt stadie och ansågs i och med en förstudie kunna användas på en verklig marknad.

2.1. Webbapplikation och Rich Internet Applications (RIA)

2.1 Webbapplikation och Rich Internet Applications (RIA)

En webbapplikation är ett samlingsnamn för den programvara som användare av internet kommer åt genom att använda en webbläsare. Den traditionella webben lagrade data på en server och klienten laddade ner informationen när den behövdes. Rich Internet Applications (RIA)-tekniken stödjer lagring av data i klienten. På så sätt lägger RIA en del av beräkningarna till klienten. Applikationer byggda för att låta klienten sköta en del av beräkningarna innebär snabbare responstider och optimerar kommunikationskostnader.[19]

Kalbach skriver att den största fördelen med RIA är den förstärkta användarupplevelsen. Istället för att ladda en ny sida med egen webbadress när användaren klickar på en länk, an-vänder sig RIA av en Single Page Applications vilket innebär att sidan snabbt laddar innehållet länken leder till och användaren stannar på samma webbadress. RIA gör omorienteringen till navigationsmöjligheterna på sidan minimal eller så de kan slipps helt. RIA är generellt mer responsiva och gör information tillgängligt snabbare, samtidigt som det minskar känslan av att vara ”vilsen på webben”. [31]

Den stora skillnaden med RIA är att informationen processas i klienten istället för i ser-vern. Den skillnaden förändrar upplevelsen mycket eftersom användarna direkt får respons för interaktionen som utförts. Det grundläggande sätt RIA använder för att undvika omladdning av sidor vid varje klick, är att all nödvändig information laddas in en gång. Då krävs det inte en omladdning av sidan vid sortering, filtrering eller manipulering av data. Ibland kan detta ses då det visas ett ”vänligen vänta, sidan laddas in”-meddelande första gången applikatio-nen startas, men därefter krävs ingen omladdning och användaren kan interagera snabbt med innehållet. [31]

2.2 Användbarhet

Begreppet användbarhet (usability) är centralt för att förstå hur en framgångsrik webbap-plikation för e-handel kan utformas eftersom det är en faktor som avgör kundernas attityd, återbesöksfrekvens och som i slutändan starkt är kopplat till eventuellt köpbeslut. [32][13] Användbarhet är ett mått på hur enkelt och funktionellt ett användargränssnitt (interface) är att använda eller[24] mer formellt definierat som:

”Den utsträckning i vilken en specifik användare kan använda en produkt för att uppnå specifika mål, med ändamålsenlighet, effektivitet och tillfredsställelse, i Ett givet sammanhang” [3]

2.3 Navigation

Internet är i sin grund ett navigationssystem som dess användare interagerar med genom att klicka på hyperlänkar navigera på webbsidor och mellan webbapplikationer. Med internets väldiga storlek och flera miljarder olika webbsidor och webbapplikationer som finns är det nödvändigt att förenkla navigering av webbapplikationer och hjälpa användarna att hitta över nätet. Nielsen säger att var navigationsgränssnitt måste hjälpa användaren att svara på tre frågor[38]:

• Var är jag? • Var har jag varit? • Vart kan jag gå?

Den antagligen mest viktiga frågan ”Var är jag?” måste enkelt besvaras för användaren. Om inte användarna vet var de befinner sig, kommer de ha svårt att förstå meningen med länken de just har följt, samt kommer de inte ha en möjlighet att få förståelse för sidans struktur och var de befinner sig relativt den. Därför måste frågan ”Var är jag?” besvaras på två nivåer:

2.3. Navigation

• Var användaren befinner sig relativt till internet, alltså vilken webbplats de befinner sig på. Användarna kommer inte veta vilken webbplats de är på om det inte berättas för dem, därför påstår Nielsen det viktigaste vid design av webbsidor är att visa upp logotypen på var sida av webbapplikationen. Logotypen borde ha en koncis placering, helst uppe i vänstra hörnet och vara en länk till startsidan.

• Var användaren befinner sig relativt webbplatsens struktur. Detta besvaras enkelt genom att visa upp delar av sidans struktur och markera vilken av dessa användaren befinner sig under.

Nielsen beskriver även i artikeln ”10 Good Deeds in Web Design” hur viktigt det är att ha en tydlig rubrik och titel på sidan så att användarna omgående vet var de befinner sig i förhållande till webbplatsens struktur. Detta gäller även om de har nått en sida djupt nere i webbapplikationen ur ett annat sammanhang.[37]

Att besvara frågan ”Var har jag varit?” är svårare eftersom webbapplikationer ofta inte sparar den informationen. Webbläsare bistår med hjälp, såsom bakåtknappar, och gör därmed mycket av jobbet. Vad som är viktigt är att tydligt, med hjälp av namn på länkarna, framgå vilka som leder till sidor användaren tidigare besökt. Detta för att de ska lära sig webbsidans struktur, samt så de sparar tid och besöker inte samma sida flera gånger. [38]

Frågan ”Vart kan jag gå?” besvaras helt enkelt av de länkar som syns på sidan användaren befinner sig på. Dock så är det omöjligt att samtidigt visa alla destinationer på en sida, därför krävs en bra struktur av webbplatsen för att användaren ska få en bra förståelse hur den kan navigera till alla delar av webbapplikationen. Bra namngivning av länkar är även viktigt så att användarna kan till stor del förutse var de kommer hamna efter att ha klickat på en länk. [38]

Webbplatsstruktur

All navigation följer ett gemensamt tema: Visualisera var i webbapplikationen användarna be-finner sig och vart de kan röra sig relativt till dess struktur. Detta innebär att om applikationens struktur är svårförståelig eller dålig, är det omöjligt att designa ett bra navigationsgränssnitt till webbplatsen. [38]

För att uppnå en bra struktur på en webbplats krävs två saker, att strukturen är koncis över hela webbplatsen, samt att strukturen designas ur användarnas perspektiv och mål. Ett vanligt misstag företag gör när de designar sin webbapplikation är att de låter strukturen spegla företagets struktur. Detta leder till att användarna blir tvingade att behöva förstå företagets struktur för att enkelt kunna använda applikationen. Användarna ska inte behöva bry sig om annat än sitt eget mål, och därmed måste hemsidans struktur utformas utifrån deras mål och syfte med användningen av webbapplikationen. [38]

Om hemsidan har en hierarkisk struktur med flera olika nivåer, bör användaren alltid kunna se på vilken del av webbplatsen den befinner sig på med överblick av alla nivåer. Detta görs enklast genom att för varje nivå markera rubriker användaren befinner sig under med annan färg än övriga rubriker. Anledningen till att designa webbapplikationen på detta vis är att användarna enkelt får god förståelse om den totala strukturen, men visar applikationens andra funktioner och hur den sida de befinner sig på förhåller sig till resten av webbplatsen. Detta är fördelaktigt om användarna har följt en länk som omgående leder djupt in i webbapplikationen. Då kan användarna omgående se var på webbplatsen de befinner sig även om de aldrig varit på den tidigare.[38]

Användaren och navigation

När användarna surfar på internet är det de själva som navigerar och kan då välja en väg som utvecklaren inte har avsett i en webbapplikation. Denna användarfrihet bör utvecklaren

2.3. Navigation

anamma och möjligheten att kunna navigera genom sidan på flera sätt bör erbjudas. Om användarna istället tvingas ta en viss väg kan webbplatsen upplevas som sträng. [38]

Vid användning av internet rör sig användare ofta mellan olika webbplatser på kort tid. Denna snabba rörelse gör att användare upplever att de använder internet som en helhet och inte olika webbplatser separat. Därför klagar användare när de anländer till en webbplats där gränssnittet skiljer sig drastiskt från webbapplikationer användarna är vana vid. Det är därför viktigt att observera internet som en genre med regler om hur en webbplats ska designas och inte aktivt försöka skilja sig från andra webbplatser.[38]

Navigering i Rich Internet Applications (RIA)

Det är viktigt att ha i åtanke att navigering från en sida till en ny sida är så fundamentalt i vår normala webbupplevelse att användaren förväntar sig omladdning. Vid design RIAs behöves detta tas i beaktning genom att påvisa för användaren att någon ändring har skett efter klick av länk. Om användaren inte får någon respons och att sidan inte laddas om, kan det verka som att klicket inte har någon effekt och risken finns att användaren missar uppdaterad information. [31]

Webbläsare har sina egna navigeringsknappar som ibland kan störa RIA, framförallt tillba-kaknappen. På statiska sidor flyttar tillbakaknappen användaren till föregående besökta sida vilket ofta förväntas. Dock för applikationer med dynamiskt genererat innehåll och data kan tillbakaknappen bli problematisk. Användning av dessa kan resultera i att använderan går längre bak än menat och data kan förloras. [31]

Även om implementation görs så webbläsarens tillbakaknapp stödjer applikationen, är det bra att inkludera tydliga navigeringsalternativ för att gå fram och tillbaka i applikationen. Detta kan potentiellt avstyra användare från att ens använda webbläsarens knappar. Generellt sett ska inte användaren behöva använda tillbakaknappen i webbapplikationen och de ska tillhandahålla alternativa navigationsmöjligheter. [31]

Element användare förväntar sig i en webbapplikation

Vetskapen av vilka gränssnittselement användare förväntar sig på en specifik typ av webbap-plikation, samt vetskapen av att veta deras förväntade plats, kan hjälpa utvecklare i design av användbara och effektiva webbplatser. [25]

Forskning har visat att användare är snabbare på att hitta ett element i gränssnittet och har mindre problem att orientera sig på en webbsida när sidan är designad enligt användarens förväntningar. Användare finner det även lättare att ta fram information när gränssnittsele-menten ligger där de förväntar sig och tenderar att vara nöjdare med webbapplikationen. På grund av tekniska framsteg samt ändringar i webbdesign, ser en typisk webbsida annorlunda ut idag jämfört med hur en webbsida såg ut för fem år sedan. [25]

Studien jämförde vad som förväntades på en webbsida 2007 och vad som förväntades 2014. Jämfört med 2007 förväntas idag fler element finnas på varje typ av webbapplikation. Exem-pelvis förväntas länkar till sociala medier finnas på alla typer av webbplatser. Den förväntade platsen för flera gränssnittselement såsom kontakt, privat information, legal information och hjälp verkar sen 2007 ha flyttats till botten av sidan i vad som kallas sidfot. Denna fot har blivit integrerad i ritningen för en e-butik. [25]

På dagens webbplatser förväntar sig användaren social media och personifiering av element såsom länkar till sociala medier, önskelistor och ytor att logga in eller registrera sig. Även tack vare tekniska framsteg inom mobiltelefonbranschen, förväntas gränssnitt såsom en mobilversion av webbplatser. Exempelvis talar Heinz, Linxen, Tuch, Fraßeck och Opwis data för ett skifte till mobilversioner av applikationer är förväntat i en e-butik. En anledning till detta menar Heinz, Linxen, Tuch, Fraßeck och Opwis kan vara att användare letar efter produkter när de är i rörelse. [25]

2.3. Navigation

Andra element som förväntas är logga in/registrera sig samt en varukorg och även en logotyp placerad i toppen av det vänstra hörnet eller i mitten högst upp på sidan. Samt förväntas huvuddelen av sidans innehåll ligga centralt på sidan. För att kontakta ägaren av sidan, förväntar sig användaren konsekvent att elementen ligger i botten av sidan. På alla typer av webbapplikationer var det oklart var sociala nätverks länkar skulle ligga, vilket tyder på att användaren inte har en förväntad plats för dessa länkar än. [25]

Idag är reklam inte längre förväntad på webbsidor. Heinz, Linxen, Tuch, Fraßeck och Opwis ger en förklaring till det med att annonser kan vara oönskade och valdes därför inte, FAQs förväntas heller inte längre finnas på någon typ av webbsida. Heinz, Linxen, Tuch, Fraßeck och Opwis säger att en anledning kan vara att användare hittar andra sätt såsom sökmotorer, sociala nätverk eller kunskapsspecialiserade sidor för att hitta svaren på sina frågor. Eftersom fler och fler företag är beroende av sin närvaro på internet och framgången för många e-butiker hänger samman med att dess användare kan navigera på sidan, är det nödvändigt att förstå vad användarna förväntar sig från olika typer av sidor.[25]

Användbara flikar vid navigering

Flikar som tas upp i detta avsnitt handlar om flikar inne i applikationen, inte flikarna som klienten tillhandahåller för att hantera flera olika öppna webbapplikationer samtidigt. [40]

Nielsen ger designråd i hur och när flikar ska användas. Det viktigaste vid användning av flikar enligt Nielsen är att de används för att dela upp olika vyer inom samma område, inte för att navigera till olika platser. Det är viktigt att det framgår tydligt vad som finns bakom varje flik så att användarna kan förutse vad som kommer att visas när flikarna öppnas. Om det är svårt att tydligt gruppera vyerna är flikar förmodligen fel gränssnitt för innehållet. [40] Flikar ska endast användas när användarna inte behöver se innehållet från flera flikar samtidigt. Om användarna behöver att gå mellan flikarna för att jämföra information, så lägger det en börda på deras kortsiktiga minne, ökar kognitiv last och interaktionskostnad. Då minskar användbarheten jämfört med en utformning som lägger allt innehåll på en stor sida. [40]

Innehållet under flikarna bör efterlikna varandra, om de är tydligt olika kommer användar-na istället tolka det som sidanvändar-navigeringar. Det ska även tydligt framgå vilken flik som är öppen genom att markera den öppnade fliken. Metoder för att påvisa vilken flik som är öppnad kan vara att ändra storleken på den öppnade fliken, en etikett i fet stil, eller genom att lägga fliken framför övrig flikar. Det är även bra ifall den öppnade fliken sammankopplas till innehållet, det gör det också lättare att se vilken flik som är öppen. De flikar som inte är öppnade ska vara lätta att se och läsbara för att påminna användaren om att det finns fler alternativ. Om flikarna smälter in för mycket i bakgrunden finns det en risk att användaren aldrig klickar på den och inte upptäcker alla funktioner. [40]

Etiketterna för varje flik ska vara korta och innehålla lättförstådda ord för användaren. Helst ska etiketten bestå av en till två ord eftersom det är lättare att söka av korta etiketter. Behövs längre etiketter är det också ett tecken på att flikar är fel gränssnitt för webbsidan. Tecknen i etiketten ska inte vara i enbart versaler då det gör dem svårlästa. [40]

Flikarna ska enbart vara uppradade i en rad då flera rader skapar hoppande element. Detta förstör det spatiala minnet och därför gör det omöjligt för användarna att komma ihåg vilka flikar de redan har besökt. Dessutom är flera rader ett tydligt symptom av överdriven kom-plexitet. Behövs flikar som inte får plats i en rad måste designen göras simplare. Flikarna ska placeras på toppen av sidan, om de placeras vid kanten eller i botten förbiser ofta användarna flikarna. Flikarna ska även se likadana ut och fungera på samma sätt. Att vara konsekvent är viktigt för det grafiska användargränssnittet, därför att det bygger på användarens känsla av att bemästra gränssnittet. [40]

Nielsen påstår att om dessa råd följs så kommer användaren att veta hur de använder fli-karna utan vidare utforskning eller felbenägen gissning. Det gör att användare kan fokusera på att förstå innehållet och de funktioner som är tillgängliga i flikarna. Flikar har inget egenvärde,

2.3. Navigation

men de briljerar när de inte drar åt sig någon uppmärksamhet utan underlättar tillgången till innehållet. [40]

Användbar scrollning och lockande startsida vid navigering

Vid sidor på en webbplats som går att scrolla på, talas ofta om den del av sidan som är ovanför sidbrytningen innan användaren börjar scrolla, alltså det innehåll som syns utan att något görs, samt det innehåll som ligger därunder, det som användaren måste scrolla för att se. En vanlig myt inom webbdesign är att användare ofta inte scrollar på webbsidor. Detta är dock inte sant utan användarundersökningar visar att användare spenderar ungefär 80 % av sin tid att observera det som ligger ovanför sidbrytningen och 20 % för att observera det som ligger nedanför. Resultatet av dessa användarundersökningar visar att sidor designade för att användare ska scrolla kan användas, för att användarna kommer att göra det. Dock är valet av vilket innehåll som ska visas ovanför gentemot under sidbrytning fortfarande viktig och kommer ha stor inverkan på användarupplevelsen.[39]

Schade säger att den stora anledningen till att placering av innehåll spelar roll är att det som läggs över sidbrytningen avgör ifall användarna kommer vara intresserade av att fortsätta scrolla. Användaren måste avgöra om det är värt besväret och interkationskostnaden att hitta det innehåll som är gömt längre ner på sidan, om det första innehållet användaren stöter på är ointressant kommer den inte navigera sig vidare i hopp om att hitta något gömt som är användbart. [50]

För att locka användaren att fortsätta scrolla behöver webbsidan bygga upp en historia som lockar användaren att fortsätta neråt och se fortsättningen. Detta görs genom att att visa det viktigaste och mest intressanta över sidbrytningen, samt ge en ledtråd av vad som dyker upp under. Bra tillvägagångssätt för att åstadkomma sådan design är exempelvis:

1. På sidans navigationsmeny, ha länkar till de olika sektionerna av startsidan och med markering eller understrykning av länken visa under vilken som användaren befinner sig 2. Att lägga objekt, exempelvis bilder, som sträcker sig över flera sektioner vilket lockar

användaren att fortsätta till ny information.

Om istället en sida med lite innehåll över sidbrytningen designas kan denna få ett attraktivt utseende, men detta attraktiva utseende blir ett utbyte mot att användare inte kommer veta vad som finns längre ner och om det är värt att scrolla.[50]

Navigation med dragspelsmenyer

En dragspelsmeny är en vertikal lista av rubriker som när de klickas på visar eller gömmer en sektion tillhörande rubriken. Fördelen med användning av dragspelsmenyer är att det är ett av de sätt som finns för att visa användare innehållet på sidan i en progressiv takt, samt ge användarna möjligheten att kontrollera vilket innehåll som visas för dem. Dragspelsmenyer minimerar även scrollning och genom att gömma innehållet och kan få webbplatsen att fram-träda som mindre skrämmande. Rubrikerna gör det även lätt för användaren att få en bra uppfattning av innehållet på sidan samt är en bra ersättning för länkar som leder till en annan plats på samma sida.[34]

De användbarhetsproblem som förekommer med dragspelsmenyer är att de ökar interak-tionskostnaden samt kan bli besvärliga för användaren om denne vill åt allt innehåll på sidan eftersom var rubrik behöver klickas på. Om rubrikerna inte är väl namngivna kan användarnas uppfattning om allt innehåll som sidan har att erbjuda minska.[34]

På grund av interaktionsnackdelarna med dragspelsmenyer bör dessa, i de flesta fall, inte användas för att ersätta lång scrollning på en sida. Användarna kommer scrolla om det är relevant för dem eller om toppen av webbsidan väcker nog med intresse (se scroll), relevans triumferar över besväret att scrolla. Därför bör valet ifall en dragspelsmeny ska användas till

2.4. Pålitlighet

stor del begrundas på hur mycket av innehållet på webbsidan som är intressant för användaren. Om större delen av innehållet är intressant bör dragspelmenyer inte användas, men om bara bitvis av innehållet är intressant kan denna typ av meny passa bra.[34]

Dock då dragspelsmenyer på större skärmar är diskuterbart passar det väldigt bra till mobildesign eftersom den nedkortning av innehåll som dessa menyer erbjuder passar in på små skärmar och ger användaren kan ge en bra överblick av allt innehåll. Vad som dock behöver undvikas är att det finns för mycket innehåll under varje sektion, då detta kan leda till för mycket scrollande samt desorientering av vilken information som finns var. Dessa problem undviks dock lätt med flera rubriker och inte för mycket innehåll under varje meny.[5]

Användning av modaler vid navigering

Fessenden definierar en dialogmodal som en dialogruta som visas ovanpå huvudinnehållet och försätter systemet i ett läge som kräver användarinteraktion. Dialogrutan inaktiverar hu-vudinnehållet tills användaren har interagerat. Denna typ av dialogrutan kommer vidare att benämnas som modal.

Modaler var ursprungligen avsedda att varna användare om varningar eller om det är något i systemet som kräver att användaren hanterar det omgående, vilket gjordes genom att placera en modal mitt på skärmen för att försäkra att man får användarens uppmärksamhet och fortsatt interaktion. Modaler har idag utvecklats ifrån detta och används nu på flera sätt för att få direkt användaruppmärksamhet av både berättigade och oberättigade själ.[17] Nackdelar med modaler:

1. De kräver direkt interaktion och användare kan inte fortsätta med vad de gjorde. 2. De avbryter användarna arbetsflöde och tar både tid och ger användarna ett nytt mål

de måste adressera: förstå modalen och bestämma vad de ska göra med den.

3. Orsakar att användarna glömmer detaljer associerade med deras ursprungliga mål på webbplatsen.

4. Blockerar innehållet i bakgrunden och potentiell viktig information.

Dessa nackdelar måste has i åtanke då modaler designas för användning vid icke kritiska aktiviteter. De bör användas för att förenkla arbetsflödet och inte avbryta det, exempelvis fråga efter nödvändig information eller bryta ner ett arbetsflöde i mindre delar. Det viktigaste är att inte avbryta användarens arbetsflöde utan istället med modaler göra det lättare för användarna att genomföra sina mål.[17]

2.4 Pålitlighet

I en webbapplikation är det extra viktigt att ge användaren ett pålitligt intryck eftersom det, till skillnad från en vanlig affär, inte finns något ansikte eller något annat bakom webbsi-dan än ditt eget intryck av webbapplikationen. Enligt en studie från The Pennsylvania State University är det tidigare kunskaper och erfarenheter av applikationen som gör att en typisk användare går tillbaka till den. För en användare som inte har hört talas om applikationen sedan tidigare måste det finnas ett mycket starkt intryck av att den känns pålitlig. Om detta intryck av pålitlighet ges, ökar chansen att användaren genomför ett köp. [36]

De faktorer som anses vara viktigast för att skapa förtroende hos en användare har trots att webbutveckling och design utvecklats i snabb takt förblivit desamma. Enligt Corbit finns det flera separata faktorer som varit och förblir mycket viktiga för att skapa förtroende för en webbsida. Dessa är designkvalitet, transparens, säkerhet och omdömen från andra sidor samt källor. [36], [11], [33]

2.4. Pålitlighet

Designkvalitet

Kvaliteten av innehållet är avgörande för pålitligheten, vilket innebär att det inte ska finnas buggar på hemsidan, andra fel eller felstavningar. En annan studie har undersökt webbappli-kationer som användaren inte känner till sedan tidigare utifrån olika designer och hur man använder dem. Resultatet visar att en applikation med tilltalande grafiskt design och som är lättanvänd ansågs mest pålitlig. Det visuella intrycket visade sig vara det som ansågs viktigast av de två kriterierna. [45], [60]

För att åstadkomma en tilltalande grafisk design och en design som man litar på menar Bandodkar och Singh att det ska vara genomgående konsekvent design över sidorna och att användaren ska känna igen sig på alla sidor. Det ska även finnas en grundläggande komplexitet och ordning för att uppfattas professionell och därav pålitlig. Undersökning som gjorts visar att trovärdigheten är större om företagslogotypen är enhetlig och passar in med övriga sidan. En logotyp som maximerar pålitligheten visualiserar vad företaget håller på med, använder ett simpelt designspråk och lugna harmoniska färger. Det visas också att kunder uppskattar när knappar och ikoner är grafiskt tilltalande. Det är även viktigt att visa bilder på produkter för att ge ett tydligare intryck av vad man egentligen köper. [60], [35], [27]

Vidare anser Sundström att det är mycket viktigt att det finns tydliga uppdelningar mellan olika delar av webbsidan, genom användning av en ’luftig’ design. Det mänskliga ögat proces-serar endast en sak i taget och därför är det viktigt att det finns tillräckligt med utrymme mellan de olika delarna av webbapplikationen. Enligt Sundström är detta designval viktigt för användares uppfattning av webbapplikationens designkvalitet samt deras generella intryck av webbapplikationen. [54]

Transparens

Transparens är en mycket viktig faktor då målet är att skapa ett förtroende hos en användare för en webbapplikation. Detta kan exempelvis innefatta att tydligt presentera information om exempelvis fraktkostnader, moms och garantier man får som kund. Det anses även vara viktigt att tillhandahålla återkoppling vid en utförd aktion, exempelvis ett köp, för att uppnå en god transparens. En annan aspekt är att ha en lättillgänglig kontaktinformation med exempelvis FAQ och direktmeddelanden till kundtjänst. Då webbapplikationer utelämnar grundläggande information om exempelvis priser eller kontaktuppgift tar det ofta mycket kort tid innan tjänsten som erbjuds avfärdas av användarna. Kraven på nödvändig information beror ofta på typ av tjänst, här förväntas exempelvis budfirmor kunna tillhandahålla information om vart produkten befinner sig, samt beräknad leveranstid. [23]

Då man erbjuder information till användare måste man vara noga med att metoden för att tillhandahålla denna inte uppfattas som icke transparent, eller rentav avstängd/avgränsade. Enligt Harley, Aurora kan bara intrycket av en informationsbarriär, som exempelvis att an-vändaren måste fylla i ett formulär innan information förmedlas vara förödande för användares förtroende för applikationen. Därför är det mycket viktigt att också erbjuda information på ett enkelt sätt, som inte kräver för mycket av användaren. [23]

Säkerhet

Det finns stor oro hos många om sina kreditkort och man är generellt rädd att få sina kort-uppgifter stulna. Detta har lösts genom att använda regulationer för att minska bedrägerier, vilket kallas Payment Card Industry Data Security Standard (PCI DSS). Inom denna stan-dard finns flertalet betaltjänster som tar hand om transaktionen åt webbapplikationen. Detta görs för att kunden ska känna sig säker och på så sätt ökar pålitligheten [46]. Det är mycket viktigt att under köpprocessen, i samband med betalning, visa säkerhetscertifikat och andra indikationer tydligt. Enligt Smriti är det exempelvis viktigt att visa eventuella certifikat och understryka bolagets rätt/expertis att sälja de produkter som ställs ut i webbapplikationen.

2.5. Effektiv köpprocess

Detta bör även kompletteras med ett kvalitetsmått, samt en indikation om att hög kvalitet upprätthålls för de produkter som erbjuds på sidan. [52]

Om konsumenten känner att hanteringen av deras personuppgifter är god, kommer den även känna ett större förtroende för hela applikationen. Desto mer en användare litar på sidan, desto större är chansen att vederbörande återkommer till sidan. En annan sak som visats ge mer pålitlighet är att uppmärksamma de säkerhetsfunktioner som applikationen har. Det kan till exempel vara en https-adress (HTTP Secure) eller information om vad som kommer hända med dina uppgifter och varför. [51], [7] Enligt Dan J Kim har användarens upplevda risk på hemsidan en avgörande betydelse för dennas beslut att avsluta ett köp eller inte.[12]

Omdömen från andra källor

I dagsläget bör ingen webbapplikation vara helt separerad från övriga internet. Enligt Harley, Aurora är sammankoppling med andra sidor en mycket viktig faktor för att skapa förtroende för webbapplikationen. Det måste finnas tillgängliga oberoende omdömen, som inte kan ha påverkas av de som står bakom applikationen för att försäkra användarna om att sidan är pålitlig. Då användare söker information om en webbapplikations trovärdighet används sällan en enda källa, istället används ett flertal oberoende hemsidor oftast som bas för efterforskning. En isolerad webbapplikation antas antingen ha något att dölja, eller också är det inte en stabilt och etablerat organisation som ligger bakom dess uppkomst, vilket undergräver sidans trovärdighet. Det som inger störst förtroende hos en kund är om det är ett känt företagsnamn eller välkänt varumärke. [45]

2.5 Effektiv köpprocess

Inom e-handel är det vanligt att kunden lämnar köpprocessen innan betalning vilket leder till att köpet inte blir av. En mått på detta är Abandonment rate, det vill säga hur stor andel som inte slutför ett påbörjat köp. Baymard institute har sammanställt statistik från 37 st studier mellan 2006 och 2017 om Abandonment rate och den ligger i snitt på 69.23 % [28]. Baymard Institute undersökte anledningarna till varför kunderna lämnade processen och den främsta anledningen, som 58.6 % av personerna angav, var: “jag kollar bara / jag är inte redo att köpa”. Filtrerades denna anledning bort erhölls fördelning enligt figur 2.1.

Designkriterier

I artikeln ”Customer-centered Rules for Design of e-Commerce Web Sites” av Fang och Salven-dy presenteras ett antal designkriterier eller attribut, som reflekterar de studerade användarnas åsikter om bland annat köpprocessen och produktinformation. Dessa presenteras i tabell 2.2.

Nielsen presenterar också liknande kriterier angående produktpresentation i artikeln ”10 Good Deeds in Web Design”. Han menar på att innehållet på alla sidor ska struktureras för att underlätta avsökning och att produktbilder är viktiga. Stora bilder ska undvikas på sidor där flera produkter visas. Istället ska en miniatyr användas och fullstorleksbilden med eventuella funktioner, så som zoomning och rotation, ska först finnas på produktsidan. Miniatyrbilden bör dock inte bara var en storleksändrad variant av fullstorleksbilden som lätt kan bli oläsbar, utan en kombination av storleksändring och beskärning bör användas för att framhäva de viktigaste detaljerna hos produkten.[37]

Prestanda

Att ha en köpprocess med dålig prestanda i en webbapplikation kan ofta leda till att besökare lämnar processen och sidan. Mer ingående, om en köpprocess har en laddningstid under två sekunder visar det sig att besökare tappar förtroende och lämnar. 47% av internethandlarna i

2.5. Effektiv köpprocess

Figur 2.1: Anledningar till varför användare lämnar köpprocessen

undersökningen förväntar sig en laddningstid under två sekunder innan de tappar förtroende för sidan vilket leder till missnöje.[9]

Sökfuntion

Genom att implementera en sökfunktion och sortering för produkterna, kan kunden hitta produkter lättare, vilket har visats ge en betydlig ökning i försäljning [56]. En dålig sökfunktion kan däremot skada navigerbarheten och därmed ge ett sämre intryck. Exempel på dåliga attribut för en sökfunktion är att den inte kan hantera felstavningar, plural och bindestreck [41].

Antal betalsätt

Att erbjuda flera betalsätt än ett minskar risken för att besökaren ska lämna processen. I Baymard Institutes undersökning om när besökare lämnar sidan, visar det sig att 8 % lämnar köpprocessen då det finns för få betalsätt.[28]

Obligatorisk registrering

En vanlig orsak till att besökare på en webbshop blir frustrerade, är att de måste registrera sig för att kunna slutföra ett köp. En registrering är bra för besökare som kan tänkas komma tillbaka, men det finns anledningar som gör att användarna inte alls vill registrera sig. Många besökare kan även känna att de endast vill handla på sidan en gång och vill därför inte registrera sig. Att ha en frivillig registrering anses positivt.[49]

2.5. Effektiv köpprocess

Komponent Designregel/ Attribut

Kategorisering av produkter Kategorisera produkter på ett meningsfullt sätt för vanliga användare.

Djupet av kategorier får ej vara mer än 3 Max tre klick för att hitta en produkt

Produktinformation Visa korrekt, konsekvent och detaljerad produktinformation Visa fullständiga bilder av produkterna

Storleken av produkterna presenteras på ett mätbart och jämförbart sätt

Visa lagerstatus av produkterna i början produktpresenta-tionen

Presentera produkter i en tabell med tillräckligt mycket in-formation för att ta beslut om köp. Till exempel pris och egenskaper för enkel jämförbarhet.

Var öppen med och presentera relaterade avgifter på ett kor-rekt sätt.

Samma produkter ska presenteras på samma sätt, och ha samma position

Produkterna ska inte tas bort även om de är slut i lager Kassa och registrering Fråga endast efter nödvändig och meningsfull information

som namn och adress. Inga marknadsföringsfrågor

Erbjud kunden möjlighet att navigera runt på sidan utan att logga in.

Tabell 2.1: Designregler köpprocess

Validering av formulär

Två av de tre vanligaste orsakerna till att avbryta köpprocessen som framgår i tabell 2.1, “The site wanted me to create an account” (35 %) och “Too long / complicated checkout process” (27 %), innehåller moment där användaren måste mata in information via ett formulär. I en användbarhetsstudie om köpprocesser av Baymard Institute [26] framgick en direkt korrela-tion mellan hur och när användarna fick felmeddelanden och hur snabbt och med hur stor ansträngning de kunde rätta sina fel. Baymard Institute menar även på att texten och logiken bakom felmeddelandet är viktiga faktorer för en lyckad felhantering, men för att öka använd-barheten ytterligare bör realtidsvalidering användas. Utifrån studien kunde fem fördelar med realtisvalidering sammanställas:

1. Lättare att hitta fel. Användarna slipper navigera tillbaka till felet.

2. Fortfarande fokus på inmatningsfältets sammanhang. Användaren slipper att återigen sätta sig in i vad som ska matas in i fältet.

3. Positiv realtidsvaliderng ökar säkerheten hos användaren. Användaren slipper själv gå igenom formuläret och oroa sig för fel.

4. Mindre risk för att hoppa över obligatoriska fält. Användaren får direkt veta om den missat ett obligatoriskt fält när den använder tab för att ta sig igenom formuläret. 5. Säkerställa kreditkortsdata trots lägre PCI-standard. Minskar risken för att

an-vändaren blir nekad när informationen skickas till kreditkortsföretaget på grund av ogiltig inmatning, som till exempel för kort kreditkortsnummer eller passerat utgångsdatum. I samma artikel ”Usability Testing of Inline Form Validation: 40% Don’t Have It, 20% Get It Wrong” tas även fallgropar och eventuella nackdelar för användbarheten som kan upp-stå om realtidsvalideringen inte implementeras rätt. Är valideringen för aggressiv och visar

2.6. Teori för användbarhetstestning

Figur 2.2: Förhållanden mellan olika användbarhetsmått [32]

felmeddelande innan användaren är klar med inmatningen av fältet kan irritation uppstå då webbapplikationen påstår felaktigt att användaren har fel trots att den inte har det. För ag-gressiva felmeddelanden kan även leda till att användaren misstolkar felet och börjar felaktigt rätta sin hittills rätta inmatning. En annan fallgrop som tas upp är att felmeddelandet in-te tas bort samtidigt när inmatningen är korrekt. Detta kan också leda till att användaren felaktigt försöker rätta korrekt information. För att komma tillrätta med detta problem bör felmeddelanden uppdateras vid varje tangenttrycking och tas bort så fort informationen är korrekt.[26]

2.6 Teori för användbarhetstestning

Användbarhet är ett mångfacetterat begrepp. Det kan dels handla om tekniska prestanda så som sidladdning, nedladdningshastighet och muspekarförflyttningar men hänsyn måste också tas till mjukare värden som relevans och trovärdighet. [32]Lee och Kozar tar upp 10 mått kopplat till användbarhet, se tabell 2.2.

Användbarhetstestning i praktiken

För att kunna utvärdera och förbättra användbarheten har genom åren ett antal meto-der utvecklats. I ”A comparison of usability evaluation methods for evaluating e-commerce websites” [24] listas tre huvudsakliga utvärderingsmetoder (usability evaluatin methods, UEMs); användarbaserad (User-based UEM), utvärderarbaserad (Evaluator-based UEM) samt verktygsbaserad (Tool-based UEM). Hasan, Morris och Probets jämför i artikeln de två förstnämnda som båda bygger på mänsklig interaktion med den testade mjukvaran. Nielsen[42] gör en liknande kategorisering men delar upp Tool-based i automatiserad och formell men mänsklig analys. I det första fallet, användarbaserad UEM (”empirisk”[42]), observeras ’verkliga’ användare som genomför fördefinierade listor av uppgifter för att kunna identifiera och gradera problem i applikationens användbarhet. För utvärderarbaserad UEM är det istället experter som utvärderar gränssnittet utifrån gällande principer om användbar-het (heuristisk utvärdering). [24] Exempel på uppgifter som panelen i en användarbaserad UEM ska utföra i frågan om att utvärdera en webbutik är; köpa en specifik produkt, ändra kvantitet, hitta priser, lista produkter med specifika egenskaper, kontakta kundservice usw.

2.6. Teori för användbarhetstestning

Construct Items

Consistency (1)The website repeats the same structure, components, and overall look across pages. (2) The website contains similar components across web pages. (3) Web pages in the website are consistently designed. (4) Each web page on the website is of similar design. (5) The website adheres to rules and standards of other online shopping sites. Navigability (1) The website provides multiple search features (e.g., search

engi-ne, menu bar, go-back-and-forward button, etc.) to obtain the target information. (2) The web page that I am looking for can be reached through multiple pathways. (3)There are multiple ways to access the web page that I am looking for and/or return to shopping menus. (4) It is very easy to locate what is needed in this website. (5) The website keeps the user oriented as they shop.

Supportability (1) While visiting the website, I feel that I can get just-in-time support anytime I need it. (2) The website provides features to ask for help anytime I need. (3) Getting support through a series of options is easy and convenient.

Learnability (1) The contents provided by the website are easily understood. (2) The website is designed for easy understanding. (3) I can easily re-member how to reach the same page when I visit next time. (4)As time passes, I am more accustomed to the website with less effort. Simplicity (1) The structure of the website is succinct. (2)I can comprehend most

components of a page within seconds. (3) The website has components that are not necessary. (4) There are redundant components in the website.

Interactivity (1) The website provides an appropriate amount of interactive fea-tures (e.g., graphics, pop-up windows, animation, music, voices). (2) The website contains components to help the interaction between it and consumers. (3)Interactive features of the website are vivid and evoke responses. (4)The website provides features for interactive com-munication between consumers, or between consumers and the online company.

Telepresence (1) I felt empathy with the website. (2) I feel I have personal ties to the website. (3)I feel as though I am emotionally connected to the website. (4) I feel as though I am taking part with the website. Credibility (1) I feel safe in my transactions with the website. (2) I trust the

website to keep my personal information safe. (3)I trust the website administrators will not misuse my personal information. (4) The web-site is stable to use. (5) Services are routinely delivered as promised. (6)The website provides detailed information about security features. Content Relevance (1) The website contains in-depth information. (2) The website pro-vides up-to-date information. (3) The scope of information provided by the website is appropriate. (4) The information provided by the website is accurate.

Readability (1) The websites wording is clear and easy to understand. (2) The website has enough white space (or margins) to make it readable. (3) Every page contains the appropriate amount of components to into a page. (4) The website uses colors and structures that are easy on the eyes.

2.6. Teori för användbarhetstestning

Testgruppens storlek föreslås vara 8-20 personer [24]. Expertpanelen kan utgå från ett ramverk av kategorier för att bedöma mjukvarans användbarhet, till exempel utifrån kategorier som arkitektur/navigation, innehåll, tillgänglighet/kundservice, design och köpprocess [24] men också arbeta mer fritt utifrån intuition och sunt förnuft [42].

I boken “Observing the user experience: a practitioner’s guide to user research” [21] före-slår författarna två nedskalade varianter av empirisk användbarhetstestning: ”Nano-Usability Test” och ”Micro-Usability Test”. I den förstnämnda introduceras produkten för en person som uppmanas använda den för att utföra någon uppgift under 15 minuter utan några närmare instruktioner. 15-minuters modellen är effektiv eftersom den snabbt och billigt kan ge svar på grundläggande problem i funktionaliteten. Det är inte någon djupgående metod men som författarna påpekar, ”användbarhet är inte hjärnkirurgi” [21]. För ett ”Micro-Usability Test” krävs lite mer förberedelser. Processen består av fyra steg:

1. Definiera målgruppen och dess mål

2. Skapa uppgifter som syftar till att uppfylla dessa mål 3. Sätt ihop testgrupp

4. Observera när testgruppen utför sina uppgifter

Målgruppen bör definieras tydligt så att den är anpassad till den aktuella produkten. Det är onödigt att försöka testa användbarhet på någon som inte är aktuell för att köpa eller använda produkten.

Vidare ska produktens nyckelkomponenter identifieras. Skapa en lista över vilka egenskaper den har och varför produkten ska användas och vilket värde den skapar för kunderna.Dessa bör användas för att definiera uppgifter, som ska uppfylla kundernas mål eller avsikter med att använda produkten. Det ska vara specifika uppgifter som går att utföra, exempelvis köpa en specifik produkt, söka efter produkter eller använda supportfunktioner.

För att sätta ihop testgruppen går det bra att använda personer i projektets närhet, kollegor eller vänner men hänsyn bör tas till att de helst inte ska vara partiska i frågan om vad de tycker om produkten eller tjänsten. Det är också en fördel om gruppen inte består av professionella designers eftersom de helt enkelt är för insatta i frågeställningarna. Testgruppen kan urskiljas med hjälp av ett förtest alternativt väljas utefter specifika kriterier [29]. Testgruppen får gärna bestå av fem till sex personer.

I sista steget ska först ett manuskript utformas som testdeltagarna sen ska följa. Det är en fördel om deltagarna kan läsa uppgifterna själva för att testen ska bli så likvärdiga som möjligt. Testets olika delar ska även ges till testpersonen som deluppgifter. Det gör att risken minskar för att testpersonen förväxlar de definierade uppgifterna och går händelserna i förväg [29]. Under testet är det viktigt att deltagarna ska vara införstådda med att det är produkten och inte de själva som ska testas och att de ska utföra momenten på manuskriptet så gott det går. Observera deras beteenden och låt dem kommentera sina beslut och eventuella problem. Webbläsare och andra hjälpmedel som behövs för att utföra uppgifterna ska vara nollställda före varje testdeltagare genomför sina uppgifter.

Insamling av material under testet kan ske enligt olika metoder. Manuell datainsamling görs av en eller flera observatörer till testet som antecknar testpersonens framsteg under testets gång genom att använda specificerade formulär för vilken information som ska samlas. Det kan vara både kvalitativ eller kvantitativ information, om exempelvis hur mycket hjälp test-personen krävde under testets gång eller kommentarer som gavs av testtest-personen. Vidare kan användargenererad datainsamling användas. Då testpersonen får besvara ett formulär på sam-ma dator som används under testets genomförande. Formuläret är vanligtvis en checklista eller

2.7. Enkätundersökning

frågeformulär som används för att besvara den givna uppgiftens svårighetsgrad. Vid utform-ning av ett formulär krävs beräkutform-ning i att inte använda ord som är okända för testpersonen och att inte författa frågorna så att testpersonen kan förutspå dess givna svar.[29]

Testgruppens Storlek

Enligt Virzi i hans studie om vilken testgruppsstorlek som är optimal för att kunna erhålla ett relativt pålitligt resultat samtidigt som kostnaderna för testningen hålls nere, finner virzi att det räcker med fem testpersoner för att uppräthålla pålitliga resultat. Detta är enligt Virzien avvägning av kostnad mot nytta och fem personer anses vara en bra testgruppsstorlek ur denna aspekt. Då man använder sig av större testgrupper avtar enligt Virzi den marginella upptäckandegraden av buggar i systemet, om man begränsar testgruppen till fem individer kan man förvänta sig att finna cirka 80 % av alla buggar. [59]

Enligt Faulkner finns det vissa brister i Virzis teori presenterad ovan. I sin artilek ”Beyond the five-user assumption: Benefits of increased sample sizes in usability testing” menar Faulkner att det finns stor varians av upptäckandegraden då man använder en testruppsstorlek på fem individer. Faulkner menar att den lägsta upptäckandegraden för ett sådant test ligger på cirka 50 %. Istället menar Faulkner att man med fördel kan öka testgruppens storlek till tio individer, för att kunna uppnå en lägsta upptäckandenivå om cirka 80 %. [16]

Tidpunkt för testning

Enligt Goodman, Kuniavsky och Moed är användbarhetstestning inget som bör sparas till när produkten är färdig utan snarare göras iterativt under utvecklingsfasen. Som mest effektiv är den enligt författarna i de tidiga och halvfärdiga faserna av utvecklingen, gärna innan olika funktionerna är helt fastställda. Användbarhetstestning blir på så sätt värdefullt för att testa helt nya funktioner (exploratory), när funktioner implementeras (assessment), för att jämföra funktioner mot varandra (comparison) eller för att fastställa att en funktion uppfyller vissa krav eller standarder senare i utvecklingsfasen (validation). Att vara medveten om vilken typ av användbarhetstestning som är aktuell för olika faser och funktioner i produktutvecklingen ger oftast mer insiktsfulla resultat än att bara fiska efter svar. [21]

2.7 Enkätundersökning

Att utforma och tolka resultaten från enkätundersökningar är enligt Colton och Covert en konstform i sig. [8]. Den vanligaste grunddesignen utgår från Likertskalan [8, 10] (vanligen uttryckta som numeriska värden där respondenten får sätta ett värde på hur väl denna håller med om ett påstående eller fråga [10]). Fördelar med att använda Likertskalan är en enligt Cooper och Johnson dels att både respondenter och frågeställare är bekväma med formatet, dels att det är en enkättyp som går att anpassa till många olika frågeställningar [10]. Ett vanligt problem, enligt Cooper och Johnson, är bland annat hur svar som placerar sig mitt i spektrat (vanligen ”tre” på en femgradig skala) där detta kan vara ett uttryck både för en faktisk indifferens men lika gärna beteckna ett ovilja att ge ett socialt opassande svar. Ett sätt att komma runt problemet är enligt Cooper och Johnson att (1) dela upp oklara eller mångtydiga frågor i flera olika för att bringa klarhet eller att (2) var särskilt noggrann i språkbruket när det gäller svarsalternativen för att eliminiera alltför neutrala alternativ [10] eller risken att omedvetet föra in mångtydighet i svarsalternativen [6].

2.8 Brainwriting

Metoden går ut på att under en given tid ska alla deltagare skriva ned tre idéer på ett papper och skicka vidare papperet till nästa person när tiden är slut. Alla skriver alltså på samma gång. Utifrån den tidigare personens idéer kan du välja att antingen vidareutveckla dessa eller

2.8. Brainwriting

att fortsätta komma på nya. Detta upprepas till dess att papperna har gått ett varv runt bordet.[43]

I kontrast till den mer traditionella Brainstormingen där gruppen genererar idéer genom att tala är Brainwriting en metod där de i tystnad skriver ned och delar idéer. Undersökningar har visat att Brainwriting genererar fler unika idéer än de verbala metoderna i det inledande stadiet av ett projekt [22, 44]. Det som visat sig vara den avgörande skillnaden från brainstorming är att deltagarna inte behöver oroa sig för omedelbar återkoppling för kvaliteten, att det finns en given tidsram och att genereringen av idéerna bygger på andras [43].

3.1. Förstudie

3.1 Förstudie

Beskriver de metoder som tillämpats före implementeringen av webbapplikationen och de beslut som togs kring webbapplikationens utkristallisering.

Enkätundersökning till affärsidé

En enkätundersökning genomfördes för att ge underlag i skapande av e-handel som enligt frågeställning ska erbjuda god navigerbarhet, pålitlighet och en effektiv köpprocess. Enkätun-dersökningen utformades online via ett formulärverktyg ägt av Google Drive och distribuerades därefter på fyra studentgrupper via plattformen Facebook. Formuläret innehöll sju frågor som besvarades genom flersvarsalternativ samt fri text. Frågorna riktades för att besvara markna-dens inställning till utmaningsmoment, användning av sociala medier samt gifting. Avgräns-ningen för spridAvgräns-ningen av enkäten enbart till studenter ansågs tillräcklig då denna innehåller en stor del av målgruppen.

Insamling av material

Arbetet har använt sig av ett flertal rapporter samt ytterligare litterärt underlag för att stödja metoder, tillämpningar samt tillvägagångssätt. Vid användning av dessa externa källor ge-nomfördes källkritisk granskning av äkthet, närhet, beroende samt tendens av informationens innehåll. [2]

Prototypframtagning

För att besvara frågeställningen krävdes framtagning av en webbapplikation. Upplägget för arbetets framfart är att verka enligt en iterativ process som startade i och med en proto-typframtagning. Ett flertal enklare arbetsmetoder användes för att generera en prototyp av den tänkta produkten. Idégenerering genomfördes enligt en Brainwriting teknik som i vissa fall lämpas bättre för att ta vara på samtliga deltagares idéer, undvika att fastna i specifika tankebanor samt att minska tiden för idégenerering.[58]

En treminutersperiod per idésession tillämpades under processen och resultatet fanns sedan till grund för projektets produktbacklog och prototyp.

Visualiseringen av webbapplikationens funktioner gjordes först genom enklare skisser med papper och penna. Detta för att öka flexibiliteten i framtagningen av funktionaliteten samt för att skapa en tydlig visuell grund för projektets utformning. Användningen av papper och penna anses i vissa fall lämpas som en viktig del för kommunikation inom områden som design. Efter att prototypen fastställts digitaliserades och strukturerades skissen med verktyget Adobe Illustrator.

3.2 Implementation

I denna del beskrivs implementationen av webbplatsen och de arbetsmetoder som använts för att undersöka frågeställningen.

Utvecklingsspråk och ramverk

Valet att designa en RIA med ”Single Page Application” gjordes tack vare användbarhets-fördelarna, se teori 2.1. Vid utveckling av applikationens backend valdes utvecklingsspråket Python med ramverket Flask. Fördelen med användningen av Flask är ett det är ett så kallat ”micro framework”. Det innebär att ramverkets funktioner är i sin grund väldigt simpla, men det finns möjlighet att utöka dessa[57]. På detta vis kunde gruppen välja vilka funktioner av Flask som vill användas själv, vilket gjordes så att de skulle passa utveckling av en ”Single Page Application” samt så att vissa grundläggande funktioner slapp utvecklas på egen hand.

3.3. Utvärdering

En PostgreSQL-databas användes för att lagra data, så som produkter eller användare, vilken kodades i SQLite. Under utvecklingsfasen kördes servern lokalt på utvecklarnas datorer i Pyt-hons virtuella miljö virtualenv för att enkelt köra den nuvarande versionen av applikationen. I ett senare skede av utvecklingsfasen distribuerades även en live-version till Heroku. Heroku är en plattform som låter utvecklare testa sina applikationer i molnet, vilket gruppen använde för att förenkla användartesting då applikationen inte längre behövde köras lokalt[14]. Frontend utvecklades i HTML, CSS och Javascript med biblioteket jQuery, ett bibliotek som hjälper att manipulera och animera webbapplikationer[18], och ramverket Bootstrap, ett CSS ram-verk vars design fungerar över flera plattformar[4]. Utvecklingen av både frontend och backend utvecklades med hjälp av den integrerande utvecklingsmiljön, IDE:n, Jetbrains PyCharm och texeditorn Atom. Som betalningsfunktion i applikationen används Stripe, en betalningstjänst menad att vara lätt för utvecklare att implementera och är säkert designad för att undvika bedrägeri[53].

Iterativt förbättringsarbete

Webbapplikationen utvecklades genom iterativt förbättringsarbete. Totalt genomfördes tre iterationer och för att underlätta versionshanteringen användes git med hjälp av plattformen Gitlab. Under samtliga iterationer togs hänsyn till navigerbarhet, pålitlighet och köpprocessens effektivitet och ett användartest genomfördes i slutskedet av varje iteration. Resultatet från användartestet analyserades och förbättringsmöjligheter hos webbapplikationen identifierades till nästa iteration i arbetet.

En första version av webbapplikation utvecklades utifrån prototypen och produktbacklog-gen med mål att vara en fungerande sida med hänsyn till inloggning samt registrering. Under iteration två fanns fokus på implementation av funktioner gruppen ansåg önskvärda att finnas med i applikationen samt förbättring av tidigare funktioner. Vid den slutliga arbetsprocessen stod webbapplikationens design i fokus samt implementering av mindre omfattande funktioner som uppkommit under tidigare användartester.

3.3 Utvärdering

I avsnittet presenteras den metod som tillämpades för utvärdering av webbapplikationen.

Användartest

För att testa navigerbarhet, pålitlighet och köpprocessens effektivitet hos applikationen utför-des användarbaserade tester konstruerade utifrån artikeln Running a Usability Test [48] och kapitlet A Micro-Usability Test [20]i fyra steg.

1. Definiera användare och deras målsättning

Steg ett utfördes i förstudien med marknadsundersökning och utförande av marknadsförings-plan med bland annat STP-analys (se appendix B.9). Målgruppen för den marknadsförings-planerade produkten definierades och användes för framtida underlag.

2. Skapa uppgifter som syftar till att uppfylla dessa mål

Utefter målgruppen och prototypens stadium utformades uppgifter inför varje test. Uppgifter-na skiljde sig delvis inför olika test då produkten utvecklats olika mycket i respektive stadium. En del funktioner fanns ej implementerade tidigt i processen vilket togs i beräkning under testens gång. Uppgifterna bestod av 3-5 mindre test som skulle genomföras. (Se appendix A.1 för uppgifterna som togs fram för testerna). Däremot har frågorna varit samma över alla iterationer.

3.3. Utvärdering

3. Sätt ihop testgrupp

Enligt marknadsundersökningens resultat för målgrupp och enligt produktens utformning val-des testpersoner från Linköpings Universitet. Testgruppens sammansättning underbyggval-des av de delar som Goodman, Kuniavsky och Moed vidrör i avsnitt 2.6 och valdes så att de ansågs vara opartiska och någorlunda lika den framtagna målgruppen. De tre fristående testgrupperna som användes vid de tre testtillfällena varierade i storlek mellan fyra till fem personer.

4. Observera när testgruppen utför sina uppgifter

Varje person ur testgruppen utförde testet individuellt på tillhandahållna Macbook-datorer i webbläsaren Safari eller Windows laptops i webbläsaren Chrome. Innan testet började var observatörerna noga med att poängtera att, om testpersonen fastnade eller inte klarade av en uppgift var det inte fel på personen utan webbapplikationen samt att det är webbappli-kationen som testas och inte testpersonen. Testpersonen blir även instruerad att prata och förmedla intryck medan denne genomför uppgiften, men att observatörerna sitter tysta under tiden och ska ignoreras, avsnitt 2.6. Testpersonen informerades även om antalet uppgifter som skulle genomföras och att denne kommer få ta del av uppgifterna en i taget. Detta för att öka fokuseringen på den givna uppgiften enligt teoriavsnitt 2.6.En till två personer fungerade som observatörer och tillämpade manuell data insamling genom att föra anteckningar under förloppet om: fel, kommentarer från testpersonen och hur lyckat uppgiften utfördes. Efter testets slut tillämpades användargenererad datainsamling (teoriavsnitt 2.6) genom att använ-darna svarade på en enkät. Enkäten innehöll frågor om intryck av webbapplikationen med avseende på olika parametrar kopplade till det framtagna syftet samt parametrar kopplade till produktens stadium. För enkät, se appendix A.3. När alla uppgifter var utförda var testet slut och cacheminnet i webbläsaren rensades och flikar stängdes ner för att kunna utföra testet på nästa person.

Enkätdesign

För att kvantifiera materialet från användartesterna utformades testenkäten med inspiration av idéerna från Cooper och Johnson och Colton och Covert. Likertskalan valdes med tanke på att det skulle ge respondenterna enklast möjliga utgångsläge. I utgångspunkt var inslaget av att se var användarna fastnade i sina tester, samt deras kommentarer under genomförandet det centrala, dock var enkäterna viktiga för att få jämförande mått mellan iterationerna. I linje med Cooper och Johnson förslag om att använda ett konsekvent språk och addera frågor för att undvika att för många svar hamnade för nära den neutrala zonen utformades en enkät som ansågs vara tillräckligt noggrann. Efter första iterationen visade sig att vissa av enkätfrågorna trots denna ansträngning gick att tolka på flera sätt. I detta skede gjordes en avvägning om att det trots bristerna skulle vara bättre ur studiesynpunkt att inte förändra enkätdesignen, detta för att inte tappa jämförbarheten mellan testiterationerna.

Testgruppens Storlek

Utifrån teori presenterad i teoriavsnitt ’Testgruppens Storlek’ 2.6 valdes det att under arbetets gång använda sig av mindre testgrupper om fem individer. Detta val gjordes då fem individer anses vara kostnadseffektivt i testningssamband. Större testgrupper skulle troligtvis ge ett mer sanningsenligt resultat, som påpekas av Faulkner men detta skulle också kräva en betydligt större anstängling i form av testförberede lser och tid vilket diskuteras av Virzi. Eftersom det dessutom planerades att genomföra en serie av användartester ansågs fem personer vara optimalt som underlag för utvärdering av användartester. 2.6

4.1. Förstudie

4.1 Förstudie

I figur 4.1 presenteras protoypen som framtogs under förstudien.

Figur 4.1: Prototyp för webbapplikation

Resultatet av enkäten för affärsidén till webbapplikationen sammanställdes och finns som del i en marknadsföringsplan (se appendix B.2).

4.2 Implementation

I detta avsnitt presenteras det tekniska resultatet av webbapplikationen efter den tredje och sista iterationen.

Övergripande design och funktionalitet

Avsnittet beskriver den övergripande design och funktionalitet som finns implementerad på webbapplikationen.

Navigationsmeny

Navigationsmenyn ser olika ut beroende på vilken sida som används samt vilken vy på start-sidan som iaktas, samtliga sidor har dock en liknande design av navigationsmenyn. På startsi-dans första vy, finns en transparent navigationsmeny där användaren kan navigera sig genom länkarna (Se figur 4.2). Scrollar användaren ner på startsidan ändras navigationsmenyns bak-grundsfärg till vit och textfärgen till svart (Se figur 4.3). På övriga sidor används samma design och struktur som på startsidans andra vy.

Köpprocessens navigationsmeny skiljer sig. Här finns inte länkarna “Om” och “Har du blivit utmanad?” och logotypen är ersatt med länken “Avsluta” som leder tillbaka till startsidan (Se figur 4.4). Är användaren inloggad byts länkarna registrering och logga in till användarens användarnamn och en logga ut länk (Se figur 4.5). Klickar användaren på sitt användarnamn kommer denne till sin profilsida.