Institutionen för datavetenskap
Department of Computer and Information Science
Examensarbete
Utformning av ett supportverktyg med hög
användbarhet
av
Hannah Börjesson
LIUIDA/LITHEXG15/034SE
20150610
Linköpings universitet
Linköpings universitet
Linköpings universitet Institutionen för datavetenskap
Examensarbete
Utformning av ett supportverktyg med hög
användbarhet
av
Hannah Börjesson
LIUIDA/LITHEXG15/034SE
20150610
Handledare: Jonas Wallgren
Examinator: Klas Arvidsson
Utformning av ett supportverktyg med hög användbarhet
Hannah Börjesson
Vallavägen 6
582 15 Linköping
hannah.borjesson@gmail.com
SAMMANFATTNINGEhandeln i Sverige omsätter miljardbelopp varje år. Antalet webbshoppar ökar år efter år och för att nå framgång måste företagen erbjuda en kundsupport av hög kvalitet. I den här studien utformas och implementeras ett verktyg för Tictail's supportteam. Verktyget utformas med hjälp av användarfokuserad design och resulterar i en produkt som Tictail's anställda tycker har hög användbarhet. Det nya verktyget innebär en tidsminskning och en minskad kostnad på 90% för supportteamet på Tictail. INLEDNING När ett företag eller en konsument säljer, köper eller byter en produkt, en tjänst eller information över internet eller andra datornätverk talar man om ehandel. Begreppet kan även omfatta kundservice, samarbeten med affärspartners med mera [1]. Under 2014 omsatte Sveriges ehandel 81 miljarder kronor. Det är en ökning med 5,3 miljarder (7%) jämfört med året innan. Mellan 2012 och 2014 ökade ehandeln i Sverige med 15% [2]. I och med denna ökning börjar företag inse att för att nå framgång gäller det inte bara att erbjuda låga priser och att ha en bra webbsida utan även att kunna erbjuda webbaserad kundsupport [3]. I DeLone & McLean Success Model presenteras sju områden som tillsammans får ett företag att nå framgång. Ett av dessa områden är service quality, vilket beskrivs som den övergripande kundsupport som företaget tillhandahåller [4]. En web baserad kundtjänst som kan ge snabb feedback, snabb respons även under de tider då trycket på supporten är högt, samt ge korrekt information anses effektiv och ger därmed nöjdare kunder [5]. Ett företag med nöjda kunder når en högre ekonomisk avkastning [6]. Tictail är en ehandelsplattform inriktad mot små butiker. Via Tictail kan använaren skapa en egen ehandelsplattform (webbshop) där de kan sälja sina produkter. Tictail startade sin verksamhet 2012 och idag ingår 70 000 butiker i deras koncept. Då antalet butiker ständigt ökar, ökar även kraven på en väl fungerande kundsupport. När en supportagent på Tictail arbetar med en förfrågan angående en specifik order, vill agenten kunna söka på ett
ordernummer och se all tillhörande information, för att kunna hjälpa kunderna när de har problem med sin order. Därför är detta är någonting som Tictail önskar implementera.
Det administrativa verktyget som finns tillgängligt för supporten i nuläget är modulärt uppbyggt där varje modul har sin egen backendkod, skriven i Python, och frontendkod, skriven i JavaScript, HTML och CSS. För tillfället finns det sju stycken fungerande moduler. Tictail's API är skrivet i Python och använder Flask som framework. Att fokusera på användaren tidigt och fortlöpande under utvecklingen av programvara är ett sätt att öka produktens kvalitet samt förhindra att stora delar av arbetet måste göras om [7]. För att produkten ska användas effektivt, i den mening att den används som den är tänkt att användas, så måste den vara lätt att använda [18]. Ett sätt för att uppnå detta är att arbeta i en iterativ process samt att tillsammans med den tänka användaren och produktägaren ta fram en prototyp [7]. Produkten bör designas så att den är lätt att använda och är användbar, det vill säga att den ökar arbetsprestation, effektivitet och/eller kvalitet [17,11]. SYFTE Målet med detta examensarbete är att implementera en ny modul som via Tictail's API ska göra det möjligt för en supportagent att söka på ordernummer och få upp specifik information om ordern, samt göra det möjligt att söka på subdomännamnet för butiken och få upp alla butikens ordrar med tillhörande information. Modulen ska vara ett användarvänligt verktyg för supportagenterna och utgöra en del av det administrativa systemet. FRÅGESTÄLLNINGAR Hur kan supportverktyget för sökning på ordernummer eller subdomännamn utformas för att uppnå en hög grad av användbarhet för supportteamet?
Hur stor ekonomisk och personaladministrativ vinst kommer implementeringen av det nya supportverktyget att ge?
TEORI Användbarhet
Användbarhet definieras enligt ISO 924111 [20] som den
grad i vilken specifika användare kan använda en produkt för att uppnå ett specifikt mål på ett ändamålsenligt, effektivt och för användaren tillfredsställande sätt i ett givet sammanhang.
För att uppnå hög användbarhet bör man arbeta i en iterativ process och använda sig av interaktionsdesign. Under mjukvaruutvecklingens gång är det lätt att tappa fokus på arbetet kring användbarhet [14]. De vanligaste hindren när det kommer till att arbeta på ett strategiskt sätt för att uppnå användbarhet är ekonomiska resurser, motstånd mot användbarhet och för liten förståelse för nyttan med användbarhet. Dessa hinder visar på att det behövs en konkret beskrivning på hur man arbetar för att uppnå hög användbarhet [13]. Mäta användbarhet För att mäta graden av användbarhet kan man använda sig av ett frågeformulär. Det finns ett antal sådana formulär att välja bland med allt från 3 frågor upp till 50 frågor. IBM har utvecklat After Scenario Questionnaire (ASQ) vilket är ett formulär som innehåller tre frågor som tar upp hur lätt användaren tyckte det var att använda produkten, användarens upplevelse av hur lång tid det tog att använda produkten samt hur nöjd användaren är med supportinformationen vid användning av produkten. ASQ har en tillförlitlighet på 0.93 [25]. DEC har utvecklat System Usability Scale (SUS). Den ger en uppskattning av användbarhet utifrån användarens uppfattning av hur det är att interagera med systemet och innehåller tio frågor. Bland annat om användarna tyckte systemet var onödigt komplext eller enkelt att använda, om de kände sig säkra när de använde systemet och om de tror att de flesta kan lära sig att använda systemet snabbt. SUS har en tillförlitlighet på 0.911 [25].
Interaktionsdesign
Med interaktionsdesign menas processen som genomförs
inom existerande begränsade resurser för att skapa, forma, och ta beslut kring alla de användarorienterade kvaliteer (strukturella, funktionella, etiska och estetiska) av en digital produkt för en eller flera användare [12].
För att nå fram till en användarvänlig implementation kan man välja en rad olika tillvägagångsätt. De flesta av dessa tillvägagångssätt bygger på ett antagande att ett passande designförslag hittas genom att man grundligt analyserar en given situation. Man vill förstå och utforska den givna situationen och användaren till den grad att designlösningen blir mer eller mindre uppenbar [19].
Man brukar tala om aktivitetscentrerad och användarfokuserad design som två olika principer för att uppnå interaktionsdesign. En aktivitetscentrerad design utgår i första hand från själva aktiviteten en användare utför medan en användarfokuserad design fokuserar på användarens mål och vad användaren själv föredrar. Aktivitetscentrerad design
Aktivitetscentrerad design utgår från begreppet aktivitetsteori [8] vilket är ett begreppsramverk som uppkom i den sociokulturella traditionen av rysk psykologi. Det fundamentala begreppet inom teorin är "aktivitet" som målmedveten, föränderlig och utvecklande interaktion mellan subjekt (person) och objekt (världen eller i detta fall datorn, mjukvara, arbetsmiljön) [9]. En mänsklig aktivitet är distribuerad över en inre och en yttre dimension, det vill säga alla aktiviteter innehåller både inre och yttre komponenter. Till exempel kan en yttre komponent vara ögonrörelser eller att räkna ett mattetal på fingrarna. En yttre komponent kan övergå till en inre, till exempel när du lär dig att räkna i huvudet istället för på fingrarna. Ett tydligt exempel på en yttre komponent i detta sammanhang är att skissa upp en designidé men även att använda metoden eyetracking för att dra slutsatser om hur exempelvis en websida ska designas[9]. Aktivitetsteori är ett sätt att ge utvecklaren stöd, inte genom redan färdiga svar utan genom en möjlighet att ställa de rätta frågorna [9]. Många olika analysverktyg har arbetats fram utifrån teorin för att ställa just de rätta frågorna vid analys, design och utvärdering av interaktiva system och de flesta är i form av en checklista [10]. I studien Activity theory for mobile learning [15] har man använt aktivitetssteorin för att utveckla design för studenters inlärning via en mobil arbetsmiljö. Här är man positiv till metoden och resultatet av den men menar att det saknas en robust designmetod. Det krävs även att utvecklaren är helt insatt i aktivitetsystem som är under observation, viktigt är att kunna urskilja på vad som faktiskt är en aktivitet.
Användarfokuserad design
Här ligger fokus på användaren och produkten optimeras utefter vad användaren vill ha och behöver. I studien Key
principles for usercentred systems design [14] har man
tagit fram tolv stycken huvudprinciper som användarfokuserad design bör bygga på.
Huvudprinciper
Fokus på användaren. Att tidigt i utvecklingprocessen fokusera på vad målet med aktiviteten är och i vilken kontext den utförs samt användarens mål och behov.
Aktivt deltagande. Den typiska användaren ska redan tidigt och även kontinuerligt aktivt delta i processen. Iterativ och stegvis utvecklingsprocess. Enkel design som alla förstår. Från början och kontinuerligt under utvecklingsprocessen bör prototyper användas för att visualisera och utvärdera idéer och designlösningar. Detta ska ske i samarbete med användaren. Utvärdera användbarheten i sin kontext. Explicita och medvetna designaktiviteter. Ett professionellt förhållningssätt. Experter i användbarhet ska delta. Helhetssyn för framtida användning. Hela processen bör specificeras och implementeras lokalt i varje organisation. En användarfokuserad attityd ska alltid etableras.
Att använda sig av användarfokuserad design i utvecklingsprocessen ger en användarvänligare produkt men det är svårt att visa hur metoden påverkar utvecklingstid och kostnad [16].
Vinst
I en studie av Chi och Gursoy [22] såg man en relation mellan nöjda kunder och företagets ekonomiska vinst. Det fanns även en relation mellan nöjda anställda och nöjda kunder vilket sekundärt även det påverkade företagets ekonomiska vinst.
När det kommer till att skapa en arbetplats med nöjda anställda finns det många olika saker företaget kan eftersträva. I studien Using employee satisfaction
measurements to improve people management: An adaption to Kano's quality types [23] tar man upp bland
annat vikten av att den anställde får delta och influera beslut och att idéer och förslag ska tas seriöst.
METOD
Design och implementation
För att utforma supportverktyget valdes en användarfokuserad designmetod. Detta för att det saknas en robust designmetod för aktivitetscentrerad design och att det nära samarbetet med användarna (supportteamet) utgjorde en bra förutsättning för att använda en användarfokuserad design. I och med det valet har huvudprinciperna [14] som presenterades i teoriavsnittet följts. I ett första skede användes brainstorming för att ta
fram vilken information som var viktig att presentera för användarna samt olika designidéer för att presentera informationen. Detta gjordes tillsammans med supportteamet och arbetet utmynnade i en första prototyp. Vid framtagning av prototyper har inspiration ur artikeln
Prototyping for Tiny Fingers [21] hämtats, bland annat tips
på material och hur prototyper kan se ut. Prototyper av typen lofi (lowfidelity), det vill säga pappersprototyper har använts. Detta för att enkelt och snabbt kunna bygga nya prototyper och för att få användaren att fokusera på flödet och generell layout istället för detaljer som typsnitt och färgen på en knapp. Efter att prototypen arbetats fram, se figur 1, har den diskuterats tillsammans med delar av supportteamet och all feedback har antecknats. Arbtetet med förståelse för vad kunden vill ha, utformning och implementation kan delas in i tre olika arbetsprocesser: 1. Basförståelse. Brainstorming tillsammans med hela supportteamet kring vad verktyget ska innehålla, vilken information den ska visa och vilka funktioner den ska uppfylla. 2. Pappersprototyp. Att tillsammans med agenterna i supportteamet arbeta fram pappersprototyper. Pappersprototypens utseende, hur och vilken information som ska presenteras har diskuterats och utmynnat i nya pappersprototyper.
3. Implementering av supportverktyget.
Utifrån pappersprototyperna har implementeringen skett. Fortlöpande under denna process har agenterna i supportteamet fått titta på och använda verktyget, samt diskutera utformingen.
Eftersom implementeringen av verktyget har skett i samma rum som agenterna själva arbetar, har den iterativa processen skett naturligt och kontinuerligt. Allteftersom verktyget har blivit möjligt att använda har det integrerats i agenternas användargränsnitt under rubriken w.i.p (work in progress) och agenterna har använt verktyget och fått ge feedback när de har velat och i två mer strukturerade omgångar i form av testscenarion. Testscenarierna har använts för att hitta designmissar och få en ytterligare diskussion med användaren kring design och funktionalitet. Den första omgången testscenarion genomfördes efter den första integreringen och den andra i samband med den näst sista integreringen. Testscenarieomgångarna gjordes på en och samma supportagent och i direkt samband med integrering. Anledningen till att samma supportagent fick göra båda testscenarierna var att den andra agenten inte hade möjlighet att genomföra testerna. Tanken med att göra testscenarierna i samband med integrering var att undvika att agenten vant sig vid att använda de nya inslagen i verktyget. Då den första omgången testscenarion resulterade i att testscenario 1 genomfördes utan problem och de andra två scenarierna resulterade i att produkten visade sig sakna information om transaktioner, valde författaren att skriva nya testscenarier till omgång två med fokus på informtaion om transaktioner och ny funktionalitet. Under testscenariets gång togs anteckningar av författaren.
Vid första integrering
Testscenario 1
En kund hör av sig via epost med följande meddelande Jag
undrar när min beställning kommer? Ordernummer 300000. /Tobbe
Testscenario 2
Kunder har hört av sig angående att deras varor inte har kommit. Alla har beställt från samma affär, med subdomännamn thestartupstore. Hitta alla ordrar för affären och kontrollera status för affärens ordrar. Testscenario 3 En kund hör av sig via epost med följande meddelande Hej! Jag har inte fått min vara jag beställt. Kan ni se om betalningen gått igenom? Ordernummer 300001. Vänligen, Joppe Vid näst sista integrering Testscenario 1 En kund med namn Emil Emilsson beställde varor från The Startup Store den 16 april vid lunchtid. Han vill veta om transaktionen för beställningen gick igenom. Testscenario 2
En kund hör av sig via epost. Hon undrar vilket transportbolag som har skickat paketet och om det har skickats från butiken än. Hon anger enbart ordernummer 2000000 som uppgift. Testscenario 3 Affären Bodil Vintage har fått in många ordrar den senaste tiden. Finns det någon möjlighet att på ett enkelt sätt hitta den allra första ordern för affären, utan att scrolla. Arbetet har utförts i linje med huvudprinciperna i studien
Key principles for usercentred systems design [14] som
presenterades i teoriavsnittet. Utvecklingen har skett genom en iterativ process där kunden och användarna har varit aktiva under stora delar av utvecklingsprocessen. Modulen har byggts med hjälp av Python och Flask på serversidan och i Javascript, AngularJS och HTML5 och CSS3 på frontendsidan.
Vinst
Ett företag med nöjda anställda har nöjda kunder och det leder i sin tur till ekonomisk vinning för företaget [22]. Genom hela utvecklingsprocessen har användarna av det tänkta supportverktyget varit delaktiga. Användarnas åsikter, idéer och förslag har tagits seriöst och påverkat de designbeslut som gjorts. Utvärdering design För att utvärdera om designen för supportverktyget nått en hög användbarhet användes två metoder. Ostrukturerad observationsstudie Detta är en kvalitativ metod för att samla in data och den genomfördes genom en deltagande observation där data i form av fältanteckningar samlades in på användarens arbetsplats. Detta för att se hur användarna använder supportverktyget i sin arbetsmiljö. I detta fall observerades en av agenterna före och efter implementationen. Fokus vid observationerna var hantering av supportärenden där enbart ordernummer fanns som tillgänglig information, utöver kundens fråga.
System Usability Scale
För att mäta graden av användbarhet användes SUS. Anledningarna till detta är att frågorna i SUS inte är beroende av vilket system eller program som ska utvärderas. Den är flexibel och går att använda för utvärdering av de flesta system. Undersökningen går snabbt att göra och den är enkel att använda. Svarsalternativen innehåller enbart en enkel skala från ett till fem vilket gör att den är lätt att förstå och fylla i [24]. Till skillnad från ASQ så passade frågorna i SUS bättre till utvärdering av supportverktyget då frågorna var något fler och lyfte fram andra aspekter av användandet än ASQ. En vecka efter den sista integreringen uppmanades alla på företagets Stockholmskontor att använda systemet (om de inte redan gjort det) och svara anonymt på tio påståenden via en webbenkät. Se tabell 1. Tabell 1. Frågeformulär designat utifrån System Usability Scale, utsickat till Tictail's stockholmskontor.
1. I think that I would like to use this product frequently.
2. I found the product unnecessarily complex. 3. I thought the product was easy to use.
4. I think that I would need the support of a technical person to be able to use this product.
5. I found that the various functions in this product were well integrated. 6. I thought that there was too much inconsistency in this product. 7. I would imagine that most people would learn to use this product very quickly. 8. I found the product very awkward to use. 9. I felt very condfident using the product. 10. I needed to learn a lot of things before I could get going with this product. För varje påstående fick användaren kryssa i ett svar på en skala från 1 till 5, där 1 betyder att man inte alls håller med och 5 att man håller med till fullo. Se figur 2. Utvärdering vinst
För att utvärdera hur stor ekonomisk samt personaladministrativ vinst implementationen gett har data samlats in, före och efter implementationen. En av agenterna fick under en veckas tid räkna antalet supportärenden där enbart ordernummret har varit tillgängligt, detta för att få en uppfattning om hur många ärenden det faktiskt gäller. Användaren antecknade även hur lång tid det tog för ett sådant ärende att avslutas. Detta för att agentenen skulle kunna besvara följande frågor: Fråga 1: Hur lång tid tar det att hantera ett supportärende som enbart har ordernummer som information? Fråga 2: Hur många sådana ärenden har ni per månad? Fråga 3: Hur mycket kostar ett sådant här ärende per minut?
Utifrån insamlat data har beräkningar utförts för att uppskatta kostnad och tid för ärendehantering av ärenden där enbart ordernummer är tillgängligt.
RESULTAT Design
Observationsstudierna
De två observationsstudierna resulterade i två olika arbetsflöden.
Arbetsflödet innan implementering 1. Ett supportärende kommer in
2. Agenten i general support läser ärendet
3. Agenten ser att länk till affären eller namnet på affären saknas
4. Agenten skickar ordernummret via ett internt meddelandesystem, till en medarbetare på den tekniska sidan av företaget
5. Medarbetaren söker efter ordern i databasen och samlar in information om affären
6. Medarbetaren skickar tillbaka svar med länken till affären samt dess epostadress 7. Agenten skickar ett svar till kunden Arbetsflödet efter implementering 1. Ett supportärende kommer in 2. Agenten i general support läser ärendet 3. Agenten ser att länk till affären eller namnet på affären saknas 4. Agenten kopierar ordernummret för ärendet 5. Agenten klistrar in ordernummret i sökfältet 6. Agenten skickar ett svar till kunden System Usability Scale
För att räkna ut SUSpoängen tar man för de udda numrerade frågorna (1, 3, 5 osv) svaret minus 1 och för de jämnt numrerade frågorna tar man 5 minus svaret. Efter detta räknar man samman alla svar för respektive respondent och multiplicerar detta med 2.5. Då får man ett svarsintervall som ligger mellan 0 och 100 där 100 är det bästa resultatet [24].
Webbenkäten skickades ut till de anställda på Stockholms kontoret som kommer att använda modulen, vilket är 10 stycken. De hade en dag på sig att svara. Antalet respondenter blev åtta till antalet.
För att se resultatet för varje enskild respondent samt medelvärdet se tabell 2.
Testscenarion
Vid första integrering
Testscenario 1, att hitta information om en order med enbart ordernummer tillgängligt. Agenten löste denna uppgift fort. Inga problem att skriva in ordernummer i sökfältet och information för att svara på frågan fanns tillgänglig. Testscenario 2, att se alla ordrar för en affär. Sökningen gick utan problem. Ordrarna presenterades men däremot saknade agenten en möjlighet att sortera dem på datum och möjligheten att se leverans och betalstatus utan att klicka på respektive order och väl inne på en order fanns inte information om betalstatus eller lista över transaktioner. Agenten saknade även en direktlänk till affären.
Testscenario 3, hitta information om betalning för en order
med enbart ordernummer tillgängligt.
Sökningen gick utan problem. Däremot fattades information om betalstatus och information om transaktioner. Tabell 2. Resultat av System Usability Scale. För varje respondent och medelvärde. Respondent Total poäng 1 97.5 2 100 3 100 4 100 5 92.5 6 87.5 7 87.5 8 95 Medelvärde: 95 Vid näst sista integrering Testscenario 1, hitta information gällande transaktioner. Agenten försökte först tabba ner, vilket inte fungerade, efter en kort stund insåg hon att hon var tvungen att klicka på affärens namn i listan för att komma vidare. Utöver detta inga problem att hitta information om transaktioner.
Testscenario 2, hitta information om leverans.
Agenten hittar snabbt informationen gällande leverans. Det stod ingen information under rubriken transportbolag, däremot stod en notering att det är Post nord som använts, under rubriken label. Testscenario 3, sortera ordrar för en affär. Agenten löste uppgiften utan problem. Implementation Arbetet enligt en användarfokuserad design resulterade i ett antal pappersprototyper. En av de sista pappersprototyperna kan ses i figur 3. Den slutliga implementationen ses i figurerna 4, 5 och 6. Figur 4 är startsidan för verktyget, med sökfält för sökning på subdomän eller ordernummer. Figur 6 visar resultatet efter sökning på subdomän Figur 4. Startsidan för verktyget. Sökfält för sökning på subdomän eller ordernummer. Figur 5. Resultatet efter sökning på subdomän.
Vinst
Frågeformulär
Gällande ekonomisk vinning har arbetstiden före och efter implementationen jämförts. Innan implementationen var två personer involverade i momentet att ta fram information om en order med hjälp av enbart ordernummret, efter implementationen är det bara en person.
Svaren på frågorna presenteras i tabell 3 och totalkostnad per månad presenteras i tabell 4.
Tack vare implementationen av det nya supportverktyget minskade den totala tidsåtgången och den totala kostnaden för denna typ av ärende med 90%. Detta innebär att supportteamet sparar 4 timmar och 30 minuter i arbetstid varje månad och företaget sparar 5670 SEK per månad.
Tid per ärende Antal ärenden
per månad Minutkostnad Före 5 minuter 60 21 SEK Efter 30 sekunder 60 21 SEK
Tabell 3: Svar på frågeformulär angående tidsmässig och ekonomisk vinning, innan och efter implementering.
Total tidsåtgång per
månad Totalkostnad per månad Före 300 minuter 6300 SEK brutto Efter 30 minuter 630 SEK brutto
Tabell 4: Total tidsåtgång i minuter per månad, samt totalkostnad i kronor per månad, innan och efter implementering.
DISKUSSION Metod
Utformning och implementering av verktyget har skett under en pågående iterativ arbetsprocess med nära kontakt med användarna. Detta har varit möjligt på grund av att företaget är relativt litet, cirka 30 personer, och den del av supportteamet som är slutanvändarna består av fem personer varav fyra satt på samma ställe som jag och den femte några skrivbord bort. För att kunna arbeta med en användarfokuserad design behövs en lätthet i kommunikationen mellan mig som utvecklare och användarna. Detta uppnådde vi dels med många kanaler till kommunikation i form av kontakt ögamotöga, epost och chatt, men även genom ett öppet klimat med högt i tak och utrymme för diskussion. Framtagning av pappersprototyp var bra som diskussionsunderlag men det var först efter den första integreringen som användarna fick en bättre bild av dels hur verktyget skulle designas, dels vilken information som skulle visas och var. Testscenarierna gav till viss del ny information och diskussion kring design och vilken information som skulle visas men jag vet inte om den informationen uppkommit iallafall. Fördelen med testscenarierna från min sida som utvecklare var att jag fick en klarare bild av hur användaren arbetade och ville arbeta med systemet. I min roll som utvecklare tog det ett tag att faktiskt förstå exakt vad systemet skulle användas till i en vidare mening än det initiala, vilket var att söka på ett ordernummer.
Resultat
Resultaten från SUS blev väldigt bra. Ett resultat med medelvärdet 95 visar att produkten har uppnått en väldigt hög grad av användbarhet och visar att en arbetsprocess med användarfokuserad design resulterar i en användarvänlig produkt. Att antalet testpersoner är litet ska inte betyda alltför mycket för resultatet då SUS har hög tillförlitlighet redan vid få tester. Däremot kan urvalet vara skevt, då de personer som svarat på enkäten känner mig personligen. Även om enkäten är anonym så kan resultatet bli mer positivt än om testpersonerna inte haft någon relation alls till den som utformat produkten. Däremot är
Figur 3. Pappersprototyp som visar sidan med information om en order.
det svårt att säga hur pass mycket detta kan ha påverkat resultatet.
När det kommer till vinst för supportteamet på Tictail, visar resultaten hela 90% minskning i tidsåtgång och minskade kostnader. Med tanke på att det inte fanns något verktyg för supportteamet att använda innan implementeringen så är inte resultatet alltför anmärkningsvärt. Man kan också se de rätt stora förändringarna i arbetsflödet för användarna. Replikerbarhet Studiens replikerbarhet är relativt hög. Alla frågor och steg presenteras i studien. Det som kan ses som ett hinder är företaget per se då jag är av uppfattningen att för att nå en framgångsrik arbetsprocess med hjälp av användarfokuserad design behöver man arbeta så nära användarna som möjligt. Både företaget och användarna måste vara delaktiga i arbetsprocessen och det är viktigt med en öppen kommunikation mellan dessa och utvecklaren. Att dessutom få integrera kod som är under utveckling kanske inte alltid är realistiskt på alla företag.
Arbetet i ett vidare sammanhang
Ur en anställds perspektiv är det intressant att se hur ett verktyg som tar några veckor att implementera kan underlätta arbetet så pass mycket. Ett förkortat arbetsflöde och en tidsvinst på 90% ger en möjlighet att svara snabbare på inkommande orderärenden, vilket ger både nöjdare anställda och nöjdare kunder. Att spara in 90% av kostnaderna för denna typ av ärenden är viktigt för ett företag som är i en expansiv fas där antalet kunder (och orderärenden) ökar för varje dag. Det visar också hur mycket ett företag kan spara genom att anpassa verktygen efter de anställdas behov. Framtida arbete Implementering Supportverktygets sökfunktion är inte optimal. Data hämtas via ett API och en sökning på alla ordrar för en affär via API'et innebär att alla ordrar hämtas ut ur databasen. I dagsläget är det inga problem då ingen affär hunnit få så många ordrar men i framtiden kommer en hämtning av alla ordrar antagligen innebära att systemet kraschar. Ett sätt att lösa det är att bygga ut API'et alternativt söka med hjälp av något sökverktyg som till exempel Elastisearch.
Verktyget visar idag all tillgänglig information och är uppbyggt så att om orderobjektet i databasen utökas med nya variabler så kommer den nya informationen också att visas. Däremot kan den inte hantera nya listor eller objekt utan där behöver man utöka implementeringen med den nya informationen. Design och resultat
Vid en framtida liknande studie skulle resultaten kunnat säkras ytterligare genom att genomföra SUS på ett bredare urval med större antal deltagare.
Användning
Verktyget kommer även att kunna användas vid bedrägerifall då det lätt går att få en översikt över en affärs ordrar och om varan har skickats iväg till kund.
SLUTSATSER
I detta projekt har ett supportverktyg utformats med hjälp av användarfokuserad design och utväderats med hjälp av SUS. Användarvänligheten bidrog till en minskad tidsåtgång för orderhantering och därmed en ökad vinst.
REFERENSER 1. Efraim T. Electronic Commerce 2010 A Managerial Perspective. Person Education Inc, Boston, 2010. 2. DIBS ecommerce Survey 2014. DIBS Payment Services AB. http://www.dibs.se/svenskehandel 3. Lee GG and Lin HF. Customer perceptions of e service quality in online shopping. International Journal of Retail & Distribution Management (2005) 33, 161176. 4. DeLone W H and McLean E R. Measuring e Commerce Success: Applying the DeLone & McLean Information Systems Success Model. International Journal of Electronic Commerce (2004) 9, 3147. 5. Negash S, Ryan T and Igbaria M. Quality and effectiveness in Webbased customer support systems. Information & Management (2003) 40, 757768. 6. Anderson E W, Fornell C and Lehmann D R. Customer Satisfaction, Market Share and Profitability: Findings from Sweden. Journal of Marketing (1994) 58, 5366. 7. Anderson J, Fleek F, Garrity K and Drake F. Integrating Usability Techniques into Software Development. IEEE Software (2001) 18, 4653. 8. Carroll J M. Interactive Technologies : HCI Models, Theories and Frameworks : Toward a MultiDisciplinary Science. Morgan Kaufmann (2003). 9. Kaptelinin V. Activity Theory. In: Soegaard, Mads and Dam, Rikke Friis (eds.). "The Encyclopedia of HumanComputer Interaction, 2nd Ed.". Aarhus, Denmark, 2014. 10. Quek A. and Shah H. A comparative Survey of ActivityBased Methods for Information System Development. Proceedings of 6th Internationl Conference on Enterprise Information Systems (2004) 5, 221229. 11. Venkatesh V. Determinats of Perceived Ease of Use: Integration Control, Instrinsic Motivation and Emotion into the Technology. Information Systems Research (2000) 11, 342365. 12. Löwgren J and Stolterman E. Thoughtful Interaction Design: A Design Perspective on Information Technology. MIT Press, 2004. 13. Rosenbaum S and Humburg J. A toolkit for strategic usability: results from Workshops, Panels and Surveys. CHI 2000 Conference on Human Factors in Computing Systems Proeceedings. ACM Press (2000) 16 april. 14. Gulliksen J et al. Key principles for usercentred systems design. Behaviour & Information Technology (2003) 22, 397409. 15. Uden L. Activity theory for designing mobile learning. International Journal of Mobile Learning and Organisation (2007) 1, 81102. 16. Vredenburg K et al. A survey of UserCentered Design Practice. CHI 2002 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (2000), 471478. 17. Venkatesh V, Speier C and Morris M G. User Acceptance enablers in individual decision making about technology: Towards an Integrated Model. Decision sciences (2002) 33, 297316. 18. Nielsen J. Usability Engineering. Academic Press, London 1993. 19. Stolterman E and Wiberg M. Conceptdriven Interaction Design Research. HumanComputer Interaction (2010) 25, 95118. 20. ISO. Ergonomic requirements for office work with visual display terminals (vdts) – part 11: Guidance on usability. ISO 924111:1998, International Organization for Standardization, Geneva, Switzerland, 1998. 21. Rettig M. Prototyping for Tiny Fingers. Communications of the ACM (1994) 37, 2127. 22. Chi C G and Gursoy D. Employee satisfaction, customer satisfaction, and financial performance: An empirical examination. International Journal of Hospitality Management (2009) 28, 245253. 23. Martensen A and Grønholdt L. Using employee satisfaction measurement to improve people management: An adaption of Kano's quality types. Total Quality Management (2001) 12, 949957. 24. Bangor A, Kortum P T and Miller J T. An Empirical Evaluation of the System Usability Scale. International Journal of Humancomputer Interaction (2008) 24, 574594.
