A NPASSNING AV ERP SYSTEM FÖR
MOBILT BRUK
2020KANI13
Svensk titel: Anpassning av ERP-system för mobilt bruk Engelsk titel: Adaptation of ERP systems for mobile use Utgivningsår: 2020
Författare: Jad Saih , Melker Ågren Handledare: Petter Rittgen
Examinator: Daniel Yar Abstract
Previous research has shown that ERP systems and complex systems generally suffer from usability problems and low user experience. Because ERP systems have to process and integrate large amounts of data, it places even higher demands on usability and user experience when users want to access this data via mobile devices. The PACMAD model, which is a relatively new usability model, builds on previously established models such as the ISO standard and Nielsen's theories of usability and complements some of the shortcomings of existing usability models regarding mobile applications. The model is based on existing theories in usability but is adapted especially for applications used on mobile devices. The PACMAD model contains all the attributes for both the ISO standard and Nielsen's model, but also introduces the attribute cognitive load, which is of particular importance for mobile applications.
To answer our question, workshops and interviews were conducted with two suppliers of the ERP module Field Service Management. Based on the results from these, usability tests were performed with end users from both suppliers in the form of observation tests to measure its efficiency and effectiveness and NASA task load tests to measure the cognitive load of the applications.
The results showed that their existing application suffered from major usability problems and that the design of the applications did not take into account factors such as user, context and task. The discoveries made contributed to the development of a new prototype using established design patterns and the PACMAD model, which was set against existing literature, was tested again and compared with their existing application. This was the main result of the study that the navigation consisted of too many steps, that there were lack of functionalities and a high cognitive load. The keywords that were key to the conclusion were
"consistency", "clarity" and "structure" and explained the design process which constituted many discoveries that the companies did not follow established design patterns or usability models. These keywords were of great importance to increase usability and user experience.
Keywords: Field Service Management, ERP systems, Mobile Applications, Usability, User experience, PACMAD, NASA Task Load Test, Design patterns
Sammanfattning
Tidigare forskning har påvisat att ERP-system och komplexa system överlag lider av
användbarhetsproblem och låg användarupplevelse. Eftersom ERP-system måste bearbeta och integrera stora mängder av data ställer det ännu högre krav på användbarhet och
användarupplevelse när användare vill få åtkomst till denna data via mobila enheter.
PACMAD modellen som är en relativt ny användbarhet modell bygger vidare på tidigare etablerade modeller såsom ISO-standarden och Nielsens teorier om användbarhet och
kompletterar några av de brister som existerande användbarhetsmodeller har gällande mobila applikationer. Modellen bygger på befintliga teorier i användbarhet men är anpassad speciellt för applikationer som används på mobila enheter. PACMAD-modellen innehåller samtliga attribut för både ISO-standarden och Nielsens modell men introducerar även attributet kognitiv belastning som är av särskild betydelse för mobila applikationer.
För att besvara vår frågeställning utfördes workshops och intervjuer hos två leverantörer av ERP-modulen Field Service Management. Utifrån resultatet från dessa utfördes
användbarhetstester med slutanvändare från båda leverantörer i form av observation test för att mäta dess effektivitet och verkningsgrad och NASA task load test för att mäta
applikationernas kognitiva belastning.
Resultatet påvisade att deras befintliga applikation led av stora användbarhetsproblem samt att utformningen av applikationerna beaktade inte faktorer såsom användare, kontext och uppgift.
De upptäckter som gjordes i bidrog till framtagning av en ny prototyp med hjälp av etablerade designmönster och PACMAD-modellen som ställdes mot existerande litteratur, testades igen samt jämfördes med deras befintliga applikation. Detta utgjorde studiens huvudsakliga
resultat att navigationen bestod av för många steg, att det fanns avsaknad av funktionalitet och hög kognitiv belastning. De nyckelord som var huvudsakliga för slutsatsen var “konsekvens”,
“tydlighet” och “struktur” och förklarar designprocessen som utgjorde många upptäckter där företagen inte följde etablerade designmönster eller användbarhet modeller. Dessa nyckelord ägde stor tyngd för att öka användbarhet och användarupplevelse.
Nyckelord: Field Service Management, ERP-system, Mobilapplikation, Användbarhet, Användarupplevelse, PACMAD, NASA Task Load Test, Designmönster
Introduktion 8
1.1 Inledning 8
1.2 Problemdiskussion 9
1.3 Problemformulering och syfte 10
1.4 Avgränsning 10
2.0 Teoretisk ramverk 11
2.1 User Experience(UX) & Användbarhet 11
2.2 Designmönster 12
2.2 ERP-system & Mobilbaserad ERP-System 14
2.3 PACMAD 15
3.0 Metod 17
3.1 Designbaserad forskning 18
3.2 Tillvägagångssätt 19
3.3 Urval 20
3.4 Datainsamlingsmetod 21
3.4.1 Workshops 21
3.4.2 Intervjuer 22
3.4.3 Observationstester 23
3.4.4 NASA Task Load test 24
3.5 Metodreflektion 26
3.6 Validitet 27
3.7 Reliabilitet 27
4.0 Resultat 28
4.1 Identify problems & motivate 28
4.1.1 Resultat från workshops 28
4.1.2 Resultat av intervjuer 31
4.2 Resultat av observationstester av befintlig applikation 37
4.3 Design and development 40
4.4 Utvärdering 50
4.4.1 Observationstest 50
4.4.2 Nasa task load test 50
4.5 Demonstration 53
5.0 Resultatanalys 53
5.1 Krav för designbaserad forskning 53
5.1.1 Navigering 54
5.1.2 Funktioner 54
5.1.3 Användare 55
5.1.4 Kontext 55
5.2 Utvärdering 55
5.3 Prototypen 58
6.0 Slutsatser 59
6.1 Relevans och överförbarhet 60
6.2 Förslag till fortsatt forskning 61
7.0 Källförteckning 61
8.0 Bilagor 66
1. Introduktion
1.1 Inledning
Affärssystem definieras som en typ av programvara eller programvarupaket som syftar till att på olika sätt underlätta och understödja företagsverksamhet. En fundamental form av
affärssystem är Enterprise Resource Planning förkortad ERP. ERP-system ses idag som en miljardindustri, till en början med inriktning och etablering hos större företag. Idag har nya smidigare system lett till att även medelstora och små företag tillämpar olika sorters
datoriserad affärsstöd (Adam, Kotze, & Van der Merwe, 2011). Omvandlingen beror dels på en ökad konkurrens och dels den tekniska utvecklingen. ERP-system är ett mjukvarusystem som sällan utvecklas internt utan vanligtvis sker utvecklingen externt av diverse
mjukvaruföretag som SAP, Oracle, Microsoft, IFS m.fl. Dessa företag erbjuder universala systempaket som passar ett stort antal företagstyper och användningsområden (Brehm,Heinzl
& Markus, 2001). Dessa användningsområden består främst av Human Resources
Management, Field Service Management, Customer Relationship Management och Financial Management Module.
Systempaket för ERP-system har skapats för att främja delar inom organisationer och att datorisera affärsstödet för arbetsområden. Detta har gjort att Field Service Management har kunnat förbättras med hjälp av mer mobila alternativ som surfplattor och mobiltelefoner.
ERP-system i allmänhet har redan komplex användbarhet och användarupplevelse, detta har gjort att när nya systempaket har utvecklats för att främja fältarbete, har nya användbarhets modeller inte beaktats. Detta leder till att mobila ERP-system kräver ny designad
användargränssnitt med det begränsade skärmstorleken och touch funktionen i åtanke(Sontow 2015, se Omar 2015, s.1786). I dagsläget är mobila ERP-system ett relativt nytt ämne därav finns det brist på forskningar och kunskap om hur man bör ta itu med mobila ERP-systemets överflödiga gränssnitt och användbarhetsproblem (Omar, Rapp & Gomez , 2016). Därför behövs det mer forskning kring hur ett mobilbaserad ERP-System kan vara utformat för att öka användbarhet och användarupplevelse.
1.2 Problemdiskussion
Som tidigare nämnt är ERP-system en omfattande programvara som hanterar olika
verksamheters processer. Problemet är att de ledande aktörerna som utformar dessa system har stor målmarknad. Detta skapar en stor utmaning för användarupplevelsen och användbarhet eftersom system är så pass omfattande och har ett överflödigt gränssnitt. Just på grund av detta bidrar det också till att implementeringen av ERP-system förblir komplexa, detta kan i sin tur bidra till ökade kostnader. Smarttelefonens stora påverkan och popularitet har gjort att
utvecklingen har gått framåt och att telefonens användning i arbetet har ändrat från att vara ett verktyg för att ringa och smsa till att kunna scanna varukoder, gps, söka efter information och mycket mer. Detta har gjort att fältarbetet har kunnat ta vara på smarttelefonens bredd och har blivit en modul inom vissa ERP-system. Denna utveckling vill dessa företag av ERP-system använda för att på fältarbetet kunna driva, ändra och få åtkomst till praktiska tjänster i affärssystemet var som helst, när som helst. Omar (2015) hävdar att det problem som mobila ERP-System plågas av är smartphonens skärmyta, vilket leder till överflöd av information.
Definitionen av användbarhet är ganska begränsad då den endast fokuserar på att systemet skall vara enkelt att använda. Arbetsplatser där fältarbete utförs har oftast krav för att vara mobilt, simpelt och lätthanterligt vilket gör att användandet behöver utvecklas i takt med arbetsuppgifterna men det är också minst lika viktigt att ha användarupplevelsen i åtanke. Att kunna återkoppla information från fältarbetet är viktigt för många företag och det behövs därför utvecklas bättre användbarhet och användarupplevelse när det kommer till fältarbete.
En kunskapsklyfta finns angående användbarhetsfrågor under utformning av mobila ERP-system och deras gränssnitt. Det finns även en avsaknad på specifika metoder för utvärdering av användbarhet för mobila ERP-system och hur dessa system bör designas för öka användbarhet och användarupplevelse. Tidigare studier tyder på att användarupplevelse är en av de viktigaste faktorerna som leder till framgång inom informationssystem där
användbarhet ses som en faktor som direkt påverkar slutanvändarnas tillfredställse och upplevelse(Calisir & Calisir, 2004). Tidigare nämnda användbarhetsproblem kanske inte direkt leder till omfattande misslyckanden men det kan stå i vägen för användarnas produktivitet, vilket bidrar till att användare får det svårare att utföra sina arbetsuppgifter
effektivt. Statistik som Technological evaluation center(TEC) har samlat in genom åren om urval, implementering och användning av ERP-system. Statistiken visade på att 65% av fallen överskred sin budget vid implementering av ERP-system. Detta berodde främst på att system behövdes modifieras i efterhand för att försöka öka dess användbarhet.
1.3 Problemformulering och syfte
I problemdiskussionen framgår det att det finns problematik inom användbarhet och användarupplevelse gällande mobila ERP-system applikationer. Det framgår också att de traditionella användbarhet principerna är mest lämpliga för dator applikationer.
Arbetets syfte är att presentera förslag på en interface prototyp för mobila ERP-system baserad på teorier inom UX/UI design, gällande ERP modulen Field Service Management.Field Service management kräver ett mobilt ERP-system då användarna är ute i fält. Detta kräver arbetsuppgift som behöver tillbaka rapportering för att kunna samla kritisk information som kan orsaka skador på egendom eller olycksfall där personal eller civila kan komma till skada.
Sammanfattningsvis har denna problemformulering lett oss till följande forskningsfråga.
● Hur kan ett mobil baserad ERP-System för användning i fältarbete vara utformat för att öka användbarhet och användarupplevelse?
1.4 Avgränsning
Avgränsningen skedde för användbarhet och användarupplevelse inom ERP-system för mobila applikationer gällande modulen Field Service management.
2.0 Teoretisk ramverk
För att begripa oss på problemområdet som resultatet och diskussionen i denna uppsats kommer röra sig i finns det begrepp som måste definieras och beskrivas. Detta kapitel börjar med kort presentation av användarupplevelse, användbarhet och designmönster som är
relevanta för denna uppsats. Kapitlet redogör även tidigare studier som behandlats relaterat till vårt problemområde samt PACMAD användbarhetsmodell.
Litteraturen är vald utifrån sökningar i olika typer av artikeldatabaser, främst från PRIMO samt researchgate. Sökorden formulerades utifrån våra huvudsakliga teoriområden mobila ERP-system, användbarhet och ERP-system.
2.1 User Experience(UX) & Användbarhet
Begreppet User experience är direktöversatt användarupplevelse på svenska och är idag en viktig kvalite och forskningsämne inom Human Computer Interaction (HCI) (Bargas-Avila &
Hornbaek, 2011). Emellertid finns det olika uppfattningar och definitioner om begreppet användarupplevelse. Däremot råder det en generell enighet om att användarupplevelse är “ En persons uppfattningar och respons vid interaktion med en produkt, system eller tjänst samt nyttighet, önskvärdhet, estetik, tillgänglighet, enkelhet och uppgift effektivitet ”.
(Bargas-Avila & Hornbaek, 2011; HassenZahl, 2008; ISO 9241-210.). Begreppet
användbarhet anses vara ett mycket smalare koncept som främst fokuserar på att ett system skall vara enkelt att använda och bör urskiljas från UX begreppets breda koncept(Norman, Nielsen 2012). En nyckelaspekt Jakob Nielsen (2012) tillägger är kvalitets attributet nytta, vilket refererar till designens funktionalitet. Erbjuder den funktioner användare behöver?
Vidare påstår författaren att konceptet användbarhet är hur enkla och tillfredsställande dessa funktioner är att använda och består av fem grundläggande principer (ibid)
1. Lärbarhet- Hur lätt är det för användare att utföra grundläggande uppgifter första gången de på stöter på designen?
2. Effektivitet- När användare lärt sig designen, hur snabbt kan de utföra uppgifter?
3. Förmågan att minnas- Graden av hur väl användaren kan minnas olika funktioner efter de har lärt sig funktionerna
4. Fel- Hur många fel för användaren, hur allvarliga är dessa fel och hur lätt kan de återhämta sig från felen?
5. Tillfredsställelse- Hur behaglig designen är att använda.
Det råder en generell enighet bland tidigare studier om att användare bör vara involverade genom hela designprocessen för att uppnå god användbarhet och användarupplevelse (Göransson, Gulliksen, Inger 2003; Cajander ,2006; ISO 9241-210:2019). Det finns olika metoder för att utvärdera och testa användbarhet av ett system. Användbarhetsutvärdering delas upp i formativ och summativ utvärdering(Hewett, 1986). Formativ utvärdering används för att samla feedback från användare för fortsatt utveckling varav summativ utvärdering används för att bedöma om ifall en uppsättning av användbarhetskrav har uppnåtts. Eftersom designprocessen är iterativt är användbarhets utvärderingen för det mesta formativ (Riihiaho, 2018). Exempel på formativ utvärdering är användartester(Tänka högt test och/eller
observationstest) och inspektionsmetoder exempelvis Heuristisk utvärdering.
2.2 Designmönster
Med layout innebär det att presentera något innehåll i tryckta eller digitala verk till någon (Tidwell, 2011). Författaren presenter också vidare hur layout kan se ut samt vilka
designmönster man kan ta hjälp av i sitt arbete för att öka användbarhet(ibid). I detta arbetet fokuserar vi på följande komponenter som är grundläggande för vår design baserade
forskning. Dessa komponenter är navigering och funktioner.
2.2.1 Navigering
Navigering inom en applikation eller dylikt kan jämföras med ett mål. Granell(2005) definierar Navigering som “ Något som måste göras för att nå sitt mål”. Vidare hävdar författaren att navigering bör vara konsekvent och organiserad i en design annars kan detta bidra till misslyckande oavsett hur bra och tillfredsställande en design kan se ut(ibid). Krug (2006) drar paralleller med att en användare befinner sig i en främmande affär. Hur vet användaren vart de skall gå eller ta sig runt i affären?
Tidwell (2011) menar på att vägen till målet skall vara så kort som möjligt för att det skall upplevas bekvämt. Denna väg till målet skall också vara tydlig och ge användaren mönster att följa som som leder denne på rätt väg, likt vägskyltar vid bilresor (Krug, 2006; Kreitzberg &
Little, 2009). För att underlätta denna navigering hävdar Corio & Lapalme (1998) att både bild och text kan användas som kompletterar varandra.
Tidwell(2011) lyfter fram tyngden av att “less is more” och motiverar detta med att genom tvinga användaren gå via flera steg eller nivåer varje gång denne skall utföra en uppgift är det värsta man kan utsätta användaren för. Dels för att denna måste komma ihåg fler steg vilket skadar användbarheten. Det är därför högst nödvändigt att försöka eliminera dessa överflöd av steg. Detta kan man, i mer komplexa applikationer, göras genom att en del av varje sida eller funktion grupperas till en knapp som leder till fler funktioner eller dela upp det i sektioner.
Detta gör att man, oavsett var i applikationen man befinner sig, hela tiden kan se dess
övergripande struktur. För att veta var man är i förhållande till denna översikt kan man enkelt markera det aktuella steget med t.ex. en avvikande färg mot de övriga valen. (Krug, 2006;
Tidwell, 2011). Dessa tillvägagångssätt härstammar från grunderna för layout och user interface Visuell Hierarki, Visuellt flöde samt gruppering och placering som Tidwell(2011) har presenterat i litteraturen.
2.2.2 Funktioner
Komplexa system definieras som ett system med många komponenter och funktioner där komplexiteten ligger i att få med alla delar på ett användbart sätt(Mitchell 2006). Genom att ha hög tillfredsställelse i ett systems design, desto högre motivation får användaren till att använda ett system (Ottersten & Berndtsson, 2002; Tidwell, 2011). Ottersten & Berndtsson (2002) tillägger också en faktor som är nödvändig för att underlätta för en användare. Denna faktor innebär att systemens funktioner som används mest bör prioriteras högst och lyftas fram samt måste var särskilt enkla och effektiva att använda. Norman (2013) hävdar att en designer fördelaktigt bör designa för eventuella misstag eller fel som kan uppkomma men som nödvändigtvist inte finns vid användandet av det befintliga systemet.
2.2 ERP-system & Mobilbaserad ERP-System
Ett affärssystem är enligt Computer Sweden(2018) ett program som hanterar ett företags behov av styrning, administration och analys även känd som ERP-System(ibid). ERP-system är generellt skapad för att passa många olika industrisektorer och verksamhetsformer det innehåller fler funktioner än vad som oftast behövs. Ett alltför omfattande ERP-system bidrar till sämre användbarhet. Den dåliga användarupplevelsen gör det svårare för användarna att interagera med ERP-system och utföra nödvändiga uppgifter, vilket vidare påverkar tiden för
att lära sig systemet samt riskerar att ge oönskade slutresultat för användaren(Matthews, 2008; Topi, H., Lucas, W. and Babaian, T. 2005). Tidigare studier har identifierat ett stort behov av att förbättra användarupplevelsen inom ERP-system. Dessa studier påvisade att ERP-system innehar ett komplext användargränssnitt som i sin tur bidrar till
användbarhetsproblem (Uflacker & Busse, 2007; Oja & Lucas, 2010). Uflacker & Busse (2007) framhäver också vikten av minska komplexiteten för att öka användarupplevelsen.
Smarttelefonens stora påverkan och popularitet har ändrat beteendet hos
mobiltelefon-användare samt förstärkt utvecklingen av mobil handel. Denna utvecklingen har ERP-företag upptäckt, de vill erbjuda mer praktiska tjänster där användarna kan driva, ändra och få åtkomst av affärssystemet genom olika mobila enheter när som helst, var som helst(Tai, Huang & Chuang 2016) den ERP-modul som främst tillgodogör sig detta är modulen för fältarbete och underhållsservice (Field Service Management). Detta bidrar till att
användarupplevelsen har blivit allt mer viktigare vid utveckling av mobila applikationer eftersom den har stort inflytande på produktens framgång eller misslyckande (Yazid, Jantan 2016). Eftersom ERP-system måste bearbeta och integrera stora mängder av data ställer det ännu högre krav på användbarhet och användarupplevelse när användare vill få åtkomst till denna data via mobila enheter. Den största utmaningen som mobila ERP-system lider av är dess begränsade skärmstorlek vilket bidrar till att mindre information kan visas samt att dess gränssnitt kan kännas överflödig(Omar, 2015).
2.3 PACMAD
Det finns olika modeller och definitioner av användbarhet vare sig det är ISO definitionen eller Nielsens principer som tidigare nämnts. Omar, Rapp och Gomez (2016) menar dock på att dessa modeller härstammar från traditionella dator applikationer och föreslår därför användbarhet modellen PACMAD utvecklad av Harrison, Flood & Duce(2013). PACMAD modellen bygger på bestående attribut som återfinns för både ISO-standarden och Nielsens modell om användbarhet men är mer specifik utvecklad för mobila enheter, PACMAD modellen tillägger också attributet Kognitiv belastning.
Det huvudsakliga bidraget till PACMAD modellen är den kognitiva belastningen som ett attribut för användbarhet. Till skillnad från de traditionella applikationerna som är stationära
så kan användare av mobila applikationer utföra ytterligare uppgifter. Detta kan vara att samtidigt som användare skickar meddelande så kan personen gå på en promenad eller köra bil. Av detta skäl så är det viktigt att beakta hur dessa applikationer påverkar användningen och så att de ytterligare uppgifter påverkas. Ett exempel kan vara hur gånghastigheten minskas när användare koncentrerar sig på att skicka meddelande som blir en distraktion från att
fokusera på att gå.
Kognitiv belastning syftar på att mängden kognitiv process som krävs för att använda
applikationen. I traditionella användbarhetsstudier är det vanligt att användaren endast utför en uppgift och därför kan koncentrera sig helt och hållet på uppgiften. I mobila sammanhang kan användaren ofta utföra en annan åtgärd förutom att använda mobilapplikationen t.ex. att använda navigering applikationen samtidigt som man kör en bil. När en användare utnyttjar en applikation i ett sammanhang där personen rör på sig påverkar det användaren förmåga att röra sig och använda mobilapplikationen. Därför är det viktigt att beakta flera dimensioner när man studerar användbarhet inom mobila applikationer. Ett sätt att mäta detta är genom att utföra NASA Task Load, detta är ett subjektivt verktyg för bedömning av arbetsbelastningen för att mäta den kognitiva arbetsbelastningen (Harrison, Flood, Duce 2013).
Figur 1 Jämförelse av de olika användbarhet modellerna enligt (Harrison, Flood, Duce 2013).
PACMAD användbarhet modell för mobila applikationer identifierar faktorerna användare, uppgift och kontext som bör vara grundläggande vid design av mobila applikationer och där dess sju attribut kan användas för att mäta användbarheten av en mobilapplikation(Harrison et a 2013).
Användare
Eftersom mobila applikationer oftast är begränsade till mindre skärmytor jämfört med traditionella dator applikationer så kan inte traditionella inmatningsmetoder såsom mus och tangentbord användas. Det är då viktigt att ha detta i åtanke genom utvecklingsprocessen och därför bör personen som designar en applikation finna alternativa inmatningsmetoder såsom t.ex. touch eller röstinmatning(Harrison et a 2013). En annan viktig beståndsdel som en designer bör ha i åtanke är slutanvändarnas tidigare erfarenhet. Om slutanvändare har lång erfarenhet på den valda uppgiften är sannolikheten hög att denne använder sig av diverse kortkommandon eller kan utföra uppgiften rent av muskelminne. Om slutanvändare har kortare erfarenhet kan denne tvärtemot föredra ett simpelt och intuitivt gränssnitt som gör det möjligt för denne att enkelt utföra den uppgift som krävs. Denna avvägning måste man som designer ta hänsyn till när man utformar en applikation(ibid).
Uppgift
Denna faktor definieras som det mål användaren vill åstadkomma med applikationen. Under utveckling av mobila applikationer kan ytterligare funktioner läggas till för att tillåta
användaren att åstadkomma mer med applikationen. Denna extra funktionaliteten kan öka komplexiteten hos applikationen som i sin tur kan försämra användbarheten och därmed kan användarens mål bli svårare att åstadkomma(Harrison et a 2013).
Kontext
Kontext, det vill säga i vilket användningssammanhang kommer användaren använda applikationen. Med detta menas det inte nödvändigtvis fysiska platser utan inkluderar också andra sammanhang såsom användarens interaktion med andra människor och/eller uppgifter användaren samtidigt försöker åstadkomma. Eftersom mobila applikationer kan användas av användare när denna samtidigt utför andra uppgifter är det viktigt att tänka på effekterna av att använda applikationen i ett lämpligt användningssammanhang(Harrison et a 2013).
Som tidigare nämnt identifierar PACMAD modellen sju attribut som speglar användbarheten av en applikation: Verkningsgrad, Effektivitet, Tillfredsställelse, Lärbarhet, Minnesvärdhet,
Fel och Kognitiv belastning. Dessa sju attribut bygger vidare på ISO-standarden och Nielsens modell om användbarhet. Fem av dessa har redan beskrivits i Nielsens teori om användbarhet.
Verkningsgrad
Verkningsgraden är kapaciteten hos en användare att slutföra en uppgift i en förutbestämd kontext. Verkningsgrad mäts genom att utvärdera om en användare kan utföra dessa förutbestämda uppgifter via ja eller nej (Harrison et a 2013).
3.0 Metod
I detta avsnitt presenterar vi den metodik som vi kommer använda oss av under uppsatsen, gällande designbaserad forskning, hur denna metodik kommer att användas i praktiken samt hur data skall samlas in. Vi utgick ifrån induktion från kvalitativa observationer för att nå resultatet.
3.1 Designbaserad forskning
Valet av forskningsmetod föll på designbaserad forskning. Designbaserad forskning har sina rötter inom teknik och och ingenjörskonsten. Det är i grund och botten ett problemlösande paradigm. Denna forskningsmetod strävar efter att förbättra mänsklig kunskap genom att skapa innovativa artefakter. Dessa artefakter skall sedan ligga till grund för att lösa ett definierat problem (Hevner & Chattarje 2010). Däremot är denna forskning relativt ny inom informationssystem. Peffers , Tuunanen, Rothenberger & Chatterjee (2007) identifierar två anledningar till detta. Dels områdets blygsamma ålder, samt att det faktum att det har saknats en gemensam forskningsmetod inom detta området.
Inom området informationssystem har Peffers et al (2007) utformat en gemensam metodologi som kan utföra, presentera och utvärdera en designbaserad forskning på ett effektivt och enhetligt sätt. Denna forskningsprocess har sedermera använts brett och består av sex steg.
(ibid)
Figur 2 Beskrivning av Peffers 6 steg för designbaserad forskning
1. Identify problem & motivate: Definiera ett forskningsproblem och berättiga värdet av en lösning. Detta ligger sedan som motiv för forskarna i utvecklingen av en prototyp.
2. Define objectives of a solution: Definiera målsättningar med eventuell lösning utifrån problem. Undersök hur lösningen ser ut och fastställa krav för den.
3. Design & development: Skapandet av själva prototypen eller artefakten.
4. Demonstration: Visning av prototypen eller artefaktens potential att lösa det identifierade problemet.
5. Evaluation: Utvärderera artefaktens förmåga att lösa problemet. Detta med hjälp lämplig mätmetod för att ser ifall måluppsätningarna har uppnåtts. Forskarna avgör då ifall resultatet är tillfredsställande genom testmetoder. Om inte krävs det att forskarna itererar tillbaka till processteg tre.
6. Communication: Anpassa kommunikation av arbetet. Det identifierade problemets betydelse och prototypens användbarhet uppmärksammas för forskare och andra intressenter.
Denna process behöver inte nödvändigtvis följas från början till slut enligt Peffers et al(2007).
I vårt fall skedde utvärderingsprocessen efter design och utvecklingsprocessen. Figuren illustrerar att forskningen kan initieras i ett annat skede. I denna uppsats initierades arbetet i första steget.
3.2 Tillvägagångssätt
Fokus i detta arbete lades på första steget identify problem and motivate och stegen design &
development, evaluation och demonstration i den designbaserad forskningsmetodik som presenterats ovan. I detta kapitel beskriver vi arbetsgången för uppsatsen.
Identify problem & motivate: Detta skedde genom workshops, kvalitativa intervjuer samt observationtester. Målet här var att identifiera problemen som skulle ligga till grund för steg två.
Define objectives of a solution: Målsättningen för vår lösning var att förbättra och
effektivisera deras befintliga applikation med hjälp av användbarhetsprinciperna som beskrivs i teoriavsnittet. Undersökningen på vår lösning skedde med hjälp av problem som vi
identifierade i första steget samt tidigare forskning som sedan låg till grund för nästa steg i arbetet. Många av kraven för applikationen var fördefinierad genom att utgå från de krav på vad deras applikation hade i dagsläget. Nya krav uppkom genom intervjuer och tester som utfördes på deras befintliga applikation som identifierats i första steget.
Design and development: En tidig prototyp utvecklades och demonstrerades på hur ett mobilt ERP-system inom fältarbete kan se ut utifrån de krav och problem vi identifierade gällande användbarhet och användarupplevelse. Prototypen var i princip fullt funktionell vid
observationstesterna. Därigenom underlättade det inhämtning av data från slutanvändarna.
Evaluation: Därefter utvärderades prototypen gentemot de krav och problem vi hade
identifierat. Utvärderingen av prototypen utfördes med hjälp av observationstester och NASA task load test som presenterats i forskningsöversikten bland företagens slutanvändare.
Demonstration: Prototypen som presenteras gentemot företag och användare ska visa hur ett mobilt ERP-system vid fältarbete kan vara utformat för ökad användbarhet och
användarupplevelse.
Communication: Detta arbete och artefakt ligger till grund för kommunikationen. Det identifierade problemets betydelse präglar hela arbetet och förhoppningsvis uppmärksammas
av andra forskare och läsare. Kommunikationen har anpassats på så sätt att det skall vara enkelt att följa arbetsprocessen och lättbegriplig genom att inkludera skärmdumpar av artefakten, dess design och design process.
3.3 Urval
Urvalen av företag bestod av två företag. Företagen som har varit delaktiga i denna rapport kommer att förbli anonyma. Syftet med detta var att bevara deras integritet och opartiskhet.
Dessa företag benämns hädanefter som företag X och Y. Båda företag X och Y har sitt huvudkontor i Göteborg och deras affärsmodell går ut på att leverera olika ERP-System moduler för diverse företag och där Field Service Management modulen ingår. Företag X har kontor i nio länder och deras främsta kund i Sverige gällande Field Service Management modulen är Transtema som jobbar mycket med fältarbeten och underhållsservice. Företag Y har ca femtio anställda och 17.000 användare med kontor i Stockholm utöver sitt huvudkontor i Göteborg. Anledningen till valen av dessa företag berodde på att dessa två var väletablerade inom Field Service Management i Sverige, vilket vi ansåg bidra till hög validitet samt styrka tidigare forskning gällande dålig användbarhet inom ERP-system. Slutanvändarna som utförde testerna var kunder av applikationen från företag X och Y. Båda dessa företag hjälpte oss att komma i kontakt med dess kunder. För att öka validitetet i testerna hade vi som krav att involvera både användare med lång erfarenhet samt kortare erfarenhet av användning av dessa system som testade befintlig applikation och den nya artefakten. Anledningen till detta var för att PACMAD modellen menar på att både erfarna användare och nya användare bör beaktas när man utformar en applikation och därav blev urvalet av testdeltagare ett naturligt val gällande deras erfarenhet. Erfarenheten från dessa slutanvändare varierade mellan 3- 5 år och snittåldern var 36 år. Testerna utfördes av totalt fyra personer slutanvändare.
Nielsen(2000) och Krug (2006) menar på att de första tre användarna man testar kommer att hitta i princip alla stora fel som finns och därför utvinner man inte mycket mer på att testa ytterligare användare. Mot bakgrund av detta bedömdes samtliga slutanvändare uppfylla de uppsatta kraven.
3.4 Datainsamlingsmetod
Datainsamlingen gällande utvärderingen och förstudien skedde utifrån workshops med berörda aktörer såsom produktägare, utvecklare samt systemarkitekt. Sedan utfördes öppna intervjuer med företagens UX-designers, och utvärderingstester som var planerade att ske på företagens arbetsplats. Detta fick övergå till Skype samtal på grund av Corona pandemin. De personer som intervjuades var företagens UX designers som arbetar på företag där de
utvecklar ERP-system där mobila applikationer ingår och även fältarbete. Personer som också var involverade var dess slutanvändare, som deltog i våra användbarhetstester. Dessa personer ser problemen dagligen och har oftast en annan insikt var problemen kan ligga. Dessa
intervjuer och utvärderingar låg till grund för vår primärdata och gav oss en förhands blick av de typiska användbarhet problemen. Intervjuerna var formella där fördefinierade frågor ställdes och intervjuerna skedde i grupp om två respondenter.
3.4.1 Workshops
Till en början anhöll företagen varsin workshop för att bli mer insatta hos företagen och deras produkt. På dessa möten så var det en produktägare, en systemarkitekt och minst en
systemutvecklare närvarande. Resultatet av dessa workshops användes sedan för att forma relevanta intervjufrågor som vi skulle använda i senare skede. Små observationer av deras produkt utfördes också indirekt när de presenterade och demonstrerade sin produkt.
3.4.2 Intervjuer
De gruppintervjuer som utfördes var kvalitativa och halvstrukturerade, de som blev
intervjuade var fyra UX/UI-designers. Två från vardera företag. Urvalet av respondenter var på grund av att dessa personer är delaktiga i utvecklingen av systemet eftersom att de kan påverka de framtida systemet men också användandet av systemet eftersom att de har kunskaper och är insatta i det dagliga arbetet med systemet.
Till alla intervju möten var det avsatt en timme men den faktiska tiden som användes för intervjua varierade från 20 minuter till nästan en timma. Intervjuerna gjordes utifrån en frågelista som var densamma för bägge företagen. Följdfrågorna kunde dock variera beroende
på svaren. Intervjuerna hos företagen gjordes på deras kontor de övergick sedan till Skype-samtal på grund av Corona pandemin. Företag Y och slutanvändarna genomgicks endast via Skype-samtal på grund av denna pandemi. De intervjutillfällen som utfördes på kontoret spelades in med ljudupptagning som sedan sammanställdes. Mötesintervjuer som genomfördes via Skype spelades in via ljudinspelning på mobiltelefon.
Datan som samlades in var kvalitativ data det vill säga hur de som använder systemet ser på dess användarupplevelse och ifall det var användbart. De kvalitativa intervjuerna
transkriberades och kodades sedan för att identifiera olika citat och teman. Dessa teman granskades sedan för att få en överblick av olika respondenter och deras olika syn. Det tar generellt sett mer tid att samla datan för kvalitativ metod jämfört med datainsamlingen med en kvantitativ metod. Att koda kvalitativ data kan oftast bli mer tidskrävande. En annan nackdel är att resultatet kan bli mer påverkad av oss genom att omedvetet vinkla resultatet(Johnson &
Onwuegbuzie, 2004).
3.4.3 Observationstester
För att säkerställa att datan från de kvalitativa intervjuerna var giltig, användbar och pålitlig genomförde vi ett observationstest som bestod av fyra styckna personer från respektive företagen, för att utvärdera användbarheten av den nuvarande mobilapplikationen. Nielsen (2000) menar på att en kvalitativ studie inte behöver mer än fem testdeltagare, då fler
deltagare inte absolut kommer resultera i fler identifierade problem i användbarheten. För att bevara dessa personers anonymitet så valde vi att skapa alias med fiktiva namn.
Observationstesterna gick ut på att slutanvändarna skulle utföra en rad uppgifter som de fick från oss och utgjorde vår objektiva data. Insamlingen av data bestod av observationer som skedde genom att respondenten delade skärm med oss medans de följde en rad uppgifter de skulle utföra på befintlig applikation. Tiden för att utföra varje uppgift utgjorde våra objektiva mätvärden och var ett mått på verkningsgraden, där längre tid det tog för att utföra en uppgift påvisade att uppgiften var svårare att utföra. Resultatet av dessa tider för uppgifterna
analyserades för att identifiera likheter och skillnader i data mellan dess befintliga applikation och vår prototyp. Detta analyserade enligt ISS argument:
"Efficiency measures are typically compared with the efficiency when using a different product or version, or the efficiency in the absence of the product" (ISS 2016).
För att analysera effektiviteten av test uppgifterna följde vi SSIs ekvation enligt formel 1.
Efter varje testuppgift fick slutanvändarna svara på om uppgiften gick att genomföra eller inte. Summan av antalet utförda uppgifter sammanställdes sedan och fungerade som ett underlag för ekvationen för effektivitet.
Formel 1: Effektivitet Ekvation enligt SSI (2016)
För att samla in subjektiv data för att mäta applikationens kognitiva belastning utförde vi även ett subjektivt test i form av NASA-task load test.
Båda applikationerna var android baserade och testuppgifterna var inspirerade utifrån det resultat vi tolkade från de kvalitativa intervjuerna och workshopsen. Samtliga slutanvändare jobbade ute på fält där deras arbetsuppgifter bestod av underhåll, reparation och diverse kundbesök och samtliga hade längre erfarenhet av att använda den befintliga applikationen.
Tabellen nedan visar på hur testerna var utformade.
Items to test/jobb som skall vara klart/ namn
usability tester/roll
Mål avklarat Ja eller nej
Genomsnittliga tid per mål
/sekunder
Kommentarer
observationer observerare/ Test namn
3.4.4 NASA Task Load test
NASA-task load test(TLX) är en populär teknik för att mäta och bedöma subjektiva arbetsbelastningar. Det är en flerdimensionellt utvärderingsverktyg som betygsätter användarens upplevda arbetsbelastning för att utföra en uppgift och/eller ett systems effektivitet. Det utvecklades av Human Performance Group vid NASA:s Ames
forskningscenter och har citerats i över 4 400 studier. Detta test låg till grund för att mäta användbarhet principen kognitiv belastning från PACMAD modellen.
Figur 3: Bild av ett NASA task load test bedömningsmall hämtad från NASA:s egna hemsida.
Testet kan antecknas på olika sätt. Ett sätt är att anteckna direkt på bedömningsmallen som visas i figur, detta görs genom att slutanvändaren drar ett streck beroende på sin upplevelse med den angivna uppgiften. Ett annat smidigare sätt är att göra det direkt via deras egna mobilapplikation. Bedömningsmallen är den samma, det som urskiljer sig är att man skriver in resultaten direkt på mobilen och därefter sammanställer applikationen resultatet i ett diagram som gör det enklare att utläsa. Mätvärdena består av sex underskalor som kan ses i figur. NASA TLX erhåller ett totalt arbetsbelastning resultat baserat på ett genomsnitt av betyg på dessa underskalor, ju högre snittbetyg desto högre arbetsbelastning. Slutanvändarna
var det samma som fick utföra observationstesterna och dessa fick ta del av samma bedömningsmall som figur 4.
Betygens intervall för varje underskala sträcker sig från 0-100. NASA task load test utfördes i detta fall på NASA:s egna mobilapplikation. Slutanvändarna ombads att ladda ner
applikationen på deras telefoner innan testerna. Fördelen var att applikationen gav
slutanvändaren information och beskrivning om vad de olika underskalorna innebar vilket bidrog till färre oklarheter och missförstånd, därefter tog de en skärmdump på resultatet och skickade in de till oss. Eftersom det blev så många skärmdumpar sammanställdes resultaten i en tabell diagram för att göra detta läsbart.
Insamling av data från forskningsartiklar var också en stor del av data och vår sekundärdata.
Detta för att förbättra kunskapen och skapa en innovativ artefakt i form av en prototyp. Denna artefakt låg till grund för forksningsfrågan: “Hur kan ett mobil baserat ERP-System för
användning i fältarbete vara utformat för att öka användbarhet och användarupplevelse?”.
3.5 Metodreflektion
Fördelar med designbaserad forskning är att den följer forskningsmetoder samtidigt som det går att lösa ett problem. Den utgör en förmåga att skapa innovativa lösningar på komplexa problem och vida individernas, företagens och samhällets möjligheter. För att det skall gå att dra allmänna slutsatser så är det viktigt att intervjua lämpliga personer hos företagen. Däremot som tidigare nämnt är metoden relativ ny och fortfarande under utveckling. Det finns inte heller någon direkt fastställd standard för att kunna bedöma en artefacts effektivitet och därför kan det vara svårt att skapa en generaliserad bild. Därför lade vi extra stor vikt vid
utvärderingsprocessen där vi kunde bedöma artefaktens effektivitet genom redan etablerade utvärderingsmetoder och användbarhetstester. Det som också kan konstateras är att en
kvalitativ undersökning utfördes, detta resulterade i analytisk generalisering av den datan som samlas. En analytisk analys kommer att sedan resultera i att tolka olika respondenternas svar för att hitta likheter som vi kallade för teman. Det går inte att generalisera för en total
population men en viss bredd försöker vi uppnå. Valet av kombinationen intervjuer och
observation tester var för att få subjektiv data från intervjuer och objektiv data från observations testerna.
3.6 Validitet
Validitet innebär relevansen av insamlad data för problemet och förmåga att mäta det författarna avser att mäta(Recker 2013). Recker (2013) argumenterar också för att öka validiteten för studier bör testdeltagare vara representativa för den studien som utförs. Vår testgrupp bestod av applikationens slutanvändare och som var dagliga användare av denna ERP-applikation med lång erfarenhet. De testuppgifter som utfördes under
observationstesterna av slutanvändarna var uppgifter som de kom i kontakt med dagligen.
Detta var ett sätt att öka validiteten för studien och den insamlade data. Ett annat sätt att öka validiteten över studien och få betrodd data var att komplettera observations testerna med intervjuer och workshops samt att utföra fler tester än ett observations test vilket i vårt fall blev ett NASA task load test.
Gällande validitet finns det två aspekter inom detta område. Intern validitet och extern validitet. Vår undersökning går i harmoni med intern validitet då det vi undersöker har utstått kritik som teori kapitlet har påvisat. Detta då Recker(2013) menar på att intern validitetet behandlar om hur väl undersökningen stämmer överens med verkligheten.
3.7 Reliabilitet
Validitet innebär vad vi mäter medans reliabilitet innebär hur vi mäter. Reliabilitet är vad som hur vi skall få samma resultat vid flera mätningar, oberoende av att flera personer genomför mätningen (Recker, 2013).Det är svårt att få samma resultat när undersökningarna sker under observationer. De som utför testerna har olika kunskap och skicklighet vilket kan påverka utfallet för olika tester och testdeltagare (Bryman, 2016).
De olika applikationer som utvärderas hade helt olika gränssnitt men det fanns inte flera olika gränssnitt för samma applikation på olika plattformar. Alla tester utfördes på smartphone plattformar bara och var i båda fallen android applikationer.
Den datan som vi hade genererat från uppgifterna givna från testerna har visats vara för det mesta konsistenta då slutanvändarnas erfarenhet har varit ganska lika och de befintliga applikationerna besatt samma typ av användbarhetsproblem. Den data som var inkonsekvent berodde främst på att testerna utfördes på två olika applikationer därav skiljde det sig i utfallet. Det var även svårt att få ett generaliserbart resultat då utförandet var undersökningar som var kvalitativa. Ett exempel på en del av utvärderingen som troligen inte skulle gå att få samma svar flera gånger var workshopen där de fick prata fritt och beskriva sitt egna system och problem med det.
4.0 Resultat
I denna del presenterar vi resultatet från vår design baserade forskning. Resultatet utgår från de sex steg som beskrivs i Peffers et al (2007).
4.1 Identify problems & motivate
Forskningen baseras på redan identifierade problem inom field service management. Dessa problem har uppdagats i tidigare studier gällande användbarhet inom mobila ERP-System.
Behovet har uppstått då användbarheten inte är tillfredsställande. För att identifiera problem och hitta lösningsförslag på forskningsfrågan användes intervjuer. Initialt ville vi även utföra observationer hos urvalets arbetsplatser men på grund av corona pandemin fick detta uteslutas då de företag vi utförde studierna på jobbar hemifrån tills vidare.
4.1.1 Resultat från workshops
Dessa teman uppkom från de två första workshopens av företagen X, Y:
● Kognitiv belastning: Den fysiska och psykiska belastningen som användaren utsätts för på fält påverkar applikationens användarupplevelse.
● Navigering: Svårigheter med att följa arbetsflödet.
● Användarupplevelse i applikationen: Avsaknad av diverse funktionaliteter som bidrar till sämre effektivitet.
● Hur tillfredsställande är applikationen att använda: Vad är upplevelsen av att använda applikationen.
● Arbetsprocesser: De olika delar som behövs för en välfungerande Field Service Management
Kognitiv belastning
Många som arbetar med Field Service Management arbetar med fysiskt och psykiskt påfrestande arbeten där de måste vara mobila för att kunna utföra diverse arbetsuppgifter.
Några av arbetsuppgifterna kan vara fulla av risker och behöver därför ge användarna hjälp att klara av dessa på ett sätt som minskar dessa risker och inte höjer riskerna. Den kognitiva påfrestningen kan bli att användaren behöver ofta anstränga sig under användandet av arbetsuppgifter och detta kan tillföra fler onödiga risker. De fysiska påfrestningarna kan vara att användaren behöver utföra fysiskt uppgifter som bidrar till att båda händerna är upptagna.
De som arbetar med dessa uppgifter behöver hjälp att utföra arbetsuppgifter utan att störas så gott som det går och som effektivt som möjligt som avlastar.
”Ett exempel på arbetsplatser är ett företag som arbetar med master och ledningar, ett annat exempel är järnväg”
“(...) det kan vara så att de som arbetar på fältet behöver skanna in en streckkod som de behöver för att beställa nya varor, det kan också vara någon last skall transporteras till en visst koordinat och avlastas.” Produktägare Företag X
Kognitiv belastning påverkas också hur enkelt det är att minnas och slippa minnas viss information i huvudet istället för att enkelt komma ihåg det. Att transportera varor kan betyda att användaren behöver en gps för att kunna ta sig till en plats vilket kan göra att personen behöver multitaska under färden vilket kan öka risken trafikolyckor.
Navigering
Detta nämndes som ett ganska stort hinder. De anställda menade på att vissa steg kunde anses vara otydliga. Detta rapporterades oftast från nya användare och rutinerade användare.
“ Många användare som precis hade börjat använda sig av applikationen rapporterade in att de hade svårt att hitta vissa funktioner som vi ansåg var ganska uppenbara. Vi ändrade inte på detta då många av våra etablerade kunder som har använt sig av applikationen länge har sagt att det är enkelt att komma ihåg efter att man har använt applikationen ett tag”
Navigering berör hur flödet ser ut i applikationen från att en uppgift har skapats tills att den har färdigställts. Detta menade produktägaren för företag X kunde uppfattas svårt hos nya användare.
Användarupplevelse
Under workshopen berörde produktägare av båda företagen att många av deras slutanvändare inte var så tekniskt kunniga vilket gjorde att slutanvändarna kunde uppleva att applikationen jobbade emot dem istället för att jobba för dem.
“ Många av våra användare är ju inte så tekniskt kunniga. Detta är ett stort problem då det kan vara svårt att infoga nya funktionaliteter då de kanske börjar känna att de behöver lära sig något nytt. Att vi inte heller tillhandahåller en kartfunktion som är en sådan fundamental funktion inom Field Service Management bidrar till användarna behöver använda sig av en annan kartapplikation med ett annorlunda gränssnitt.”
Tillfredsställelse
Då Field Service management inte är en så högt prioriterad del i ett ERP system så gör detta att inte så mycket kraft läggs ner på designaspekten utan mer på funktioner. Detta gör att den ibland kan se ganska så ofärdig och mindre estetiskt tilltalande.
“Användarna tycker inte att den är så användarvänlig”
Att användarna inte tycker detta kan bero på att applikationen inte är så lätt att navigera i men
det kan också vara att användarna inte tycker om utseendet. Detta kan påverka hur deras dagliga arbete utförs då frustration och avsky kan uppstå mot applikationen vilket ger negativa reaktioner mot företaget och deras förhandlingsmakt. Vissa av de saknade
funktionaliteten kan vara anledningen till att användarna uttrycker sig på detta vis även om funktionalitet inte mäts på samma sätt som tillfredsställelse.
Arbetsprocesser
ERP-system innehåller många olika moduler och dessa moduler kan innehålla flera olika arbetsprocesser. För fältarbetet så berättade produktägarna om de arbetsprocesser som utgör field service management modulen idag. Utifrån workshopen kunde vi sammanställa en objektiv kravlista på de arbetsprocesser som är fundamentala inom fältarbete och
underhållsservice som används idag bland företag och som utgör en grund för vår artefakt. De arbetsprocesser är följande:
● Navigering: Det behövs ett sätt för slutanvändaren att ta sig från en startposition till platsen där arbetsorden skall utföras.
● Rapportera in tider: Fältarbetare skall gå att rapportera in vilka tider som arbetsordern har arbetats med.
● Arbetsåtgärder: Åtgärder som har utförts för berörd arbetsorder.
● Arbetsinstruktioner: Det skall finnas instruktioner på vilka arbetsuppgifter som skall göras under arbetsordern.
4.1.2 Resultat av intervjuer
Dessa teman uppkom från de intervjufrågorna med PACMAD’s användbarhetsprinciper som gjordes med UX designers på företagen X, Y.
● Navigering: Svårigheter med att följa processflödet.
● Hur lätt är det att minnas utförandet i applikationen: Hur väl kan användaren minnas olika funktioner efter de har lärt sig funktionerna.
● Kognitiv belastning: Den fysiska och psykiska belastningen som användaren utsätts för på fält påverkar applikationens användarupplevelse.
● Användbarhet i applikationen: Avsaknad av diverse funktionaliteter som bidrar till sämre effektivitet.
● Hur tillfredsställande är applikationen att använda: Vad är upplevelsen av att använda applikationen.
● Lärbarhet under första användningen: Hur lätt är det att använda applikationen och utföra uppgifter på rätt sätt.
● Designprinciper och process: Designprinciper som tillämpas vid skapande av applikationen och processen vid skapandet av designen.
Navigering
Samtliga respondenter hävdade att navigeringen inom applikationen var ett problem.
UX-designerna från företag X sade följande.
“De problem som oftast kommer in och som våra slutanvändare rapporterar är gällande navigation.” Anledningen till detta menade UX-designers från företag Y berodde på att det var så hög mängd av information och funktioner som skulle tillhandahållas på en liten skärmyta.”(...) eftersom det är mycket information som ska få plats på ett litet format. Man kanske får till exempel lägga flera funktioner bakom flera knapptryck vilket gör att det kräver fler steg att utföra en uppgift.”
Minnesvärdhet:
Att återkomma till systemet efter en kort paus var någonting som båda företagen såg som något enkelt. Det som kan vara mindre lätt att återkomma till kan vara extensions som inte har med just Field Service Management att göra. Det kan vara någon ny tekniskt produkt som används som tillägg till arbetsuppgifterna.
“Vi tror det är lätt, problemet är däremot att tekniken går så snabbt framåt att man måste också anpassa sig efter det. Det kan bidra till att slutanvändaren också behöver anpassa sig och lära sig något nytt.”
Kognitiv belastning:
Kognitiv belastning var ingenting som någon av de vi intervjuade visste vad det innebar. Det var heller ingenting som kom i åtanke när de utvecklade applikationerna.
“Som designer så försöker man ju minska den kognitiva belastningen. Det beror på hur du använder applikationen. Det är klart att man försöker automatisera så mycket som möjligt men det är ingenting vi direkt tänker på när vi sitter och designar applikationen utan det är mer i så fall om det är ett krav från kunderna.”
De förklarade att de inte tog i hänsyn till om det är en mobilapplikation eller en dator som arbetsuppgifterna utförs på utan att de bryr sig mer funktionalitet.
Företag y:
“Det är faktiskt ingenting vi har tänkt på. Vi arbetar med att få ut en så bra produkt som möjligt och blir det fel på vägen så löser vi det senare. Vi tänker inte på några dolda risker utan produkten kommer i första hand”.
Deras lösning på problemet ifall det skulle uppstå i framtiden var en slags lean att de löser det problemet senare och de problem som uppstår från de problemet löser de efteråt och så fortsätter det så. De kunde inte se några dolda risker och att produkten kommer i första hand innan de tänker på underliggande problem.
Lärbarhet:
Lärbarhet var någonting som båda företagen såg som någonting enkelt. Båda noterade att det svåraste för användarna var att lära sig är navigeringen i applikationen,
“Vi anser att de är ganska enkla att använda. Vi vet ju att kunderna inte är så tekniskt kunniga av sig men återigen är det navigeringen som strular. Men när de har fått kläm på flödet så flyter det nog på ganska bra anser vi.”
Företag Y:
“Det intryck vi har fått är att den är ganska enkel att använda men navigeringen är nog det som slutanvändaren ser som svårast att lära sig.”
Tillfredsställelse
Tillfredsställelse, komfort och layout var ingenting som något av företagen hade medvetet hade avsett utan någonting som kom naturligt. En del av ämnet var angående layouten och komfort där företag x och y besvarade.
“Tyvärr är ju folk vana nu att hantera tråkiga appar på sitt jobb. Men konstigt nog vill de också ha det tråkigt för det är så de är vana. Så layout mässigt så försöker vi hålla oss till det
“tråkiga” och inte ha så mycket grafiska element för då kanske de klagar på det istället, så det är lite på gott och ont där.”
Någonting som också sades var att ibland så antog slutanvändarna att de visuella
förbättringarna som gjordes till systemet skulle sakta ner prestandan och att deras arbete skulle ta längre tid. Komfort och behag var ingenting som medvetet var övervägt i förtid utan någonting som de ser utvecklas med att deras arbetsuppgifter har automatiserats men inte designmässigt.
“Vi har inte det så mycket i åtanke faktiskt. Men jag tror går du till en slutanvändare så skulle de säga att den har hög komfort och behag för att den effektiviserar deras arbete men gällande design så tror jag helt ärligt inte har det i åtanke.”
Företag Y:
“Komfort och behag gällande arbetsprocessen tror jag är hög. Det är därför vi kan sälja våra tjänster. Men gällande design är det inte så mycket vi har i åtanke, vi vill egentligen främst effektivisera kundernas arbetsprocesser.”
“Problem som uppstår är oftast att vissa funktioner saknas och att slutanvändarna behöver ringa fram och tillbaka för att kontrollera med någon som är ansvarig”
Företaget indikerade att vissa funktioner som saknades gjorde att slutanvändaren som var på plats inte visste hur de skulle utföra vissa uppgifter och behövde därför ringa till backoffice, filma sin telefon eller filma någonting på arbetsplatsen.
Användbarhetsprinciper och process
Svaren vi fick från intervjuerna påvisade att företag X inte direkt följer några etablerade användbarhetsprinciper. “Vi har inga direkta fastställda principer som vi lutar oss mot”
“(...)Jag instämmer jag tror det är viktigare att skapa en egen uppfattning om vad som bör göras och inte göras för följer man principer slaviskt så händer det att man inte kan tänka själv vilket jag anser är negativt. ”
Anledningen till detta tolkade vi att det är viktigare att se till helheten och kunna tänka själv om vad som behövs och inte behövs i en design. Respondenterna från Företag Y menade däremot på att de försöker följa Nielsen fem användbarhetsprinciper men att det är svårt att följa principer då deras applikation besitter så hög mängd av information.
“Vi använder oss mest av Nielsens 5 användbarhetsprinciper. Kanske inte till punkt och pricka eftersom ibland kanske vi inte kan följa de just på grund av applikationens mängd av information och då blir det svårt att följa allihopa.”
Båda företagen inkluderade inte sina slutanvändare genom hela designprocessen. Detta berodde på flera olika anledningar. Företag X menade på att de inte har det som en del av deras arbetsprocess även om de egentligen ville ha detta. De följer ramverket SAFE där det är produktägaren som tillhandahåller kundbehoven som UX-designers sedan har till grund för att designa applikationen
“Nej det är de inte. Även om vi som UX-designers vill pusha åt det hållet så är det inte aktuellt just nu. Utan vi utgår från de kundbehov och krav som finns och som tillhandahålls av produktägaren.”
Företag Y menade på att deras kundbas är för stor och bred. De utförde interna
utvärderingstester men ingenting där slutanvändarna var delaktiga. De itererade sin design baserad på feedback de fick från slutanvändarna i efterhand.
“Eftersom det är så pass många olika kunder och kompetensen varierar mellan dessa så brukar vi inte använda oss av någon utvärderingstest på slut användarna, vi brukar däremot
göra interna tester men det är mer för att se till att processflödet är enkelt och effektivt. Det är för tidskrävande och kostsamt att utföra så många och få trovärdig data. Vi lutar oss helt enkelt mot de krav och feedback som inkommer från slutanvändarna i efterhand.”
Användbarhet i applikationen
Gällande användbarhet ansåg båda företagen var högst viktigt. Båda såg det som en konkurrensmedel som urskiljde de från dess konkurrenter.”
Användbarhet är A och O inom alla applikationer och det är vad vi alltid försöker sträva mot och det som säljs idag.” Företag X.
“I den bransch vi jobbar i är användbarhet väldigt viktigt. Vi ser det också som ett
konkurrensmedel. Ju högre användbarhet vår applikation har desto fler vill använda sig av vår applikation.” Företag Y.
Båda företagen försökte nå hög användbarhet genom att skala ner på mängden av onödig information och försöka automatisera arbetsprocesserna mer som kunde bidra till mindre interaktion mellan användare och dess applikation vilket i sin tur kunde effektivisera deras arbete i fält. Utmaningen var att ha funktioner som inte kompromissa dess användbarhet-
“Det vi anser är användbart idag är enkelheten i applikationen. Den är inte överflödig med information och vi försöker skala ner på detta så mycket som möjligt utan att påverka dess funktionalitet.” Företag X
“Det viktiga är också att försöka få med alla funktioner på ett användbart sätt som kan höja användarupplevelsen. Det är mycket information fältarbetarna jobbar med och många komponenter som finns med. Det är där jag tror utmaningen ligger att få ihop allt på ett snyggt och bra sätt.” Företag Y
4.2 Resultat av observationstester av befintlig applikation
Observationstesterna gjordes för två av företagens slutanvändare på deras befintliga applikation och sedan sammanställdes de i två kalkylblad. Observationerna bestod av fyra olika observationer för företag x och y, där respondenterna fick utföra angivna uppgifter individuellt. Eftersom sluttiderna var så pass identiska valde vi att lägga ihop dessa för varje observation och räkna ut den genomsnittliga tiden för att utföra en uppgift. Resultatet
sammanställdes av genomsnittlig tid och med kommentarer om vad som kunde ändras till det bättre. Test Uppgifterna bestod av 18 testuppgifter som användarna skulle utföra. Dessa uppgifter identifierades i utifrån resultatet av de identifierade problem som beskrevs utifrån workshopen och intervjuerna. Därefter beräknade vi dess effektivitet med hjälp av formel 1 och verkningsgrad med hjälp av ISS definition (2016).
Resultatet från båda testerna påvisade att det tog lång tid att navigera till första sidan från att de hade valt en arbetsorder vilket bidrog till att navigeringen av arbetsflödet gick extra långsamt, då det krävdes att användaren utförde flera steg. Det som också stack ut väldigt mycket var kartfunktionen. Att inte ha en sådan fundamental funktion integrerat i
applikationen bidrog till att tiden för att navigera till en arbetsorder tog längre tid samt att det bestod av fler steg än vad en användare nödvändigtvis behöver göra och komma ihåg. Båda företagen hade enligt formel 1 en effektivitet på 66,6% på sin nuvarande applikation. Däremot skiljde verkningsgraden mellan dessa två då företag Y hade en lägre verkningsgrad på 202 sekunder kontra företag X som hade en verkningsgrad på 237 sekunder. Fullständig tabell på test uppgifterna av dess befintliga applikation samt dess effektivitet och verkningsgrad finns att återfinna under bilaga 3 och 4.
Den låga effektivitet samt höga verkningsgraden kan bero på att företagen vill skala ner på funktioner för att inte ha överflöd av funktioner som kan bidra till sämre användbarhet som nämndes i intervjuerna vilket i sin tur bidrog till att uppgifterna utfördes efter fler steg än nödvändigt. Många andra uppgifter kräver manuell hantering som till exempel
tidrapportering, navigering eller utförda åtgärder till arbetsorder. Detta kan bidra till en högre kognitiv belastning för slutanvändaren. Företag X hade ingen instruktionslista som underlättar
för användarna att utföra en åtgärd rätt och effektivt medan företag Y hade kortfattad instruktion på vad det var som skulle utföras men inte någon ingående beskrivning.
4.2.1 NASA-Task Load Test
NASA-Task Load testerna utfördes på samma slutanvändare som observationstesterna.
Eftersom resultaten från observationstesterna av befintlig applikation var såpass lika så utfördes detta test endast av en användare från vardera företag. Uppgifterna som utfördes i detta test var uppgift 9, 11,12,13,14,16 och 17 från observationstesterna. Anledningen till detta var för att observationstesterna påvisade att dessa uppgifter var de som tog längst tid att utföra och hade lägst effektivitet. Mätvärdena består av sex underskalor som kan ses i figur 4.
NASA TLX erhåller ett totalt arbetsbelastning resultat baserat på ett genomsnitt av betyg på dessa underskalor, ju högre snittbetyg desto högre arbetsbelastning. Nedan visar ett snittbetyg av samtliga parametrar i testets underskalor på genomförda uppgifter.
Uppgift 9 11 12 13 14 16 17
Beskrivning Hitta instrukti oner för åtgärd
Navigera till vald arbetsorder
Bocka i alla utförda åtgärder
Granska och färdigställ åtgärder
Gå till karta
Välj en arbetsorder med pågående status
Stämpla in på vald arbetsorder
Företag X 50 50 68.3 60.8 66.6 20.8 61.6
Företag Y 55.8 51.6 27.5 28.3 60 20 50.8
Tabell 1 genomsnittlig arbetsbelastning för varje uppgift.
De underskalor som påvisade högst belastning på samtliga uppgifterna var underskalorna Mental Demand, Temporal Demand, Performance, Effort, Frustration. Generellt sagt kan vi påvisa utifrån de resultat vi har utvunnit att företag X hade högst arbetsbelastning vid testuppgift 12(se Figur 4) detta berodde på att användaren var tvungen att skapa en åtgärdsrapportering manuellt efter utförd arbetsorder. Detta var lägre hos företag Y då det finns en fördefinierad checklista som användaren bockar i beroende på utförda åtgärder. Den uppgift som företag Y upplevde hade högst arbetsbelastning uppgift 14(se figur 5). Detta
