Department of Science and Technology Institutionen för teknik och naturvetenskap Linköping University Linköpings universitet

gnipökrroN 47 106 nedewS ,gnipökrroN 47 106-ES

LIU-ITN-TEK-G-19/065--SE

En digital manual: Attvisualisera och organisera

information genom etthjälpcenter

Mami Inada Boberg

2019-06-10

LIU-ITN-TEK-G-19/065--SE

En digital manual: Attvisualisera och organisera

information genom etthjälpcenter

Examensarbete utfört i Grafisk design och kommunikationvid Tekniska högskolan vid

Linköpings universitet

Mami Inada Boberg

Handledare Jonas LöwgrenExaminator Camilla Forsell

Norrköping 2019-06-10

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat förickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press seförlagets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

© Mami Inada Boberg

En digital manual: Att visualisera och organisera information för ett supportcenter

____________________________________

Mami Inada Boberg

Vårterminen 2019

Examinator: Camilla Forsell | Handledare: Jonas Löwgren

Kandidatuppsats | Grafisk Design och Kommunikation

Linköpings universitet | Institutionen för teknik och naturvetenskap

Sammanfattning

Denna studie har genomförts med ett syfte som består av två delar. Inledningsvis syftar studien att

fastställa informationsbehovet hos användare av ett svenskt IT-företags supportcenter. Därefter,

baserat på informationsbehovet och designlösningar inom genren, är syftet att ta fram ett grafiskt

användargränssnitt för IT-företagets supportcenter.

För att uppskatta informationsbehoven hos användare har dokumenterade chattloggar analyserats för

att uppskatta vilken typ av information som uppsökts av användaren, samt vilken typ av information

som levererats av supportpersonal.

Som grund till det grafiska användargränssnittet genomfördes en genreanalys över tre webbplatser för

att beskriva de nuvarande designlösningar inom genren och fastställa eventuella mönster. För designen

av det grafiska användargränssnittet används webbplatskartor för att utvärdera användarens

navigationsmöjligheter för att hitta eftersökt information.

Resultatet av studien finner att informationsbehoven hos användare berörde de initiala inställningarna

av systemet och typen av information ansågs i många fall som verksamhetskritisk. Det grafiska

användargränssnittet bör således prioritera att visa informationen på ett tydligt och lättillgängligt sätt.

Baserat på dessa utformningskrav sammanställdes ett konceptförslag för ett användargränssnitt.

Abstract

This study has been conducted with a purpose consisting of two parts. Initially, the study aims to

determine the information needs of users of a Swedish IT company’s supportcenter. Then, based on

the information needs and design solutions within the genre, the purpose is to produce a graphical user

interface for the IT company’s supportcenter.

To estimate the information needs of users, documented chat logs have been analysed to estimate the

type of information sought by the user and what type of information that was provided by support

staff.

To create a base for the graphical user interface, a genre analysis was carried out on three websites to

describe the current design solutions within the genre and to determine possible patterns. For the

design of the graphic user interface, sitemaps are used to evaluate the user’s navigation capabilities to

find the sought-after information.

The result of the study finds that the information needs of users concerned the initial settings of the

system and the type of information was in many cases considered critical for the user’s business. The

graphical user interface should therefore give priority to displaying the information in a clear and

easily accessible manner. Based on these design requirements a concept proposal for a user interface

was presented.

Innehållsförteckning

1. Inledning ................................................................................................................................... 1

1.1 Problemformulering .............................................................................................................. 1

1.2 Syfte........................................................................................................................................ 2

1.3 Avgränsningar ........................................................................................................................ 2

2. Teoretiskt ramverk ................................................................................................................... 3

2.1 Interaktionsdesign och användarupplevelse ....................................................................... 3

2.2 Grafiskt användargränssnitt .................................................................................................. 4

2.3 Informationsarkitektur .......................................................................................................... 4

2.4 Webbplatskarta ..................................................................................................................... 5

2.5 Tekniskt information ............................................................................................................. 5

2.6 E-support................................................................................................................................ 6

3. Metod ....................................................................................................................................... 7

3.1 Förstudie ................................................................................................................................ 7

3.1.1 Intervju med Supportchef .............................................................................................. 7

3.1.2 Webbplatskarta TaxiCaller ............................................................................................. 7

3.2 Sammanställning av användardata ....................................................................................... 8

3.3 Genreanalys ........................................................................................................................... 9

3.3.1 Jämförelse av webbplatskartor ...................................................................................... 9

3.4 Designprocess ...................................................................................................................... 10

3.4.1 Urvalsprocess ................................................................................................................ 10

3.4.2 Webbplatskarta ............................................................................................................ 10

3.4.3 Prototyp ........................................................................................................................ 10

3.5 Validering ............................................................................................................................. 11

4. Process och Resultat .............................................................................................................. 12

4.1 Förstudier ............................................................................................................................. 12

4.1.1 Intervju med Supportchef ............................................................................................ 12

4.1.2 Webbplatskarta TaxiCaller ........................................................................................... 13

4.2 Sammanställning av användardata ..................................................................................... 14

4.3 Genreanalys ......................................................................................................................... 20

4.3.1 Jämförelse av webbplatskartor .................................................................................... 27

4.4 Designprocess ...................................................................................................................... 31

4.4.1 Urvalsprocess ................................................................................................................ 31

4.4.2 Webbplatskarta ............................................................................................................ 32

4.4.3 Low-fidelity prototyp .................................................................................................... 34

4.5 Validering ............................................................................................................................. 37

5. Slutsats ................................................................................................................................... 40

6. Värdering och diskussion....................................................................................................... 41

6.1 Teoretiskt ramverk .............................................................................................................. 41

6.2 Metod ................................................................................................................................... 41

6.3 Förstudier ............................................................................................................................. 42

6.4 Sammanställning av användardata och genreanalys ........................................................ 42

6.5 Designprocess ...................................................................................................................... 42

6.6 Validering ............................................................................................................................. 43

6.7 Sammanfattning .................................................................................................................. 43

6.8 Rekommendation för vidare studier .................................................................................. 43

Litteraturförteckning ................................................................................................................ 44

Bilagor

Bilaga 1 – Intervjuguide Förstudie ............................................................................................... 45

Bilaga 2 – Användardata ............................................................................................................... 46

Bilaga 3 – Valideringsurval Användardata ................................................................................... 56

1

1. Inledning För att ett system skall kunna användas optimalt behöver användare enkelt kunna sätta sig in och

förstå hur systemet skall användas. För att underlätta denna process erbjuds information genom

manualer och kundsupport. Detta tjänar en essentiell funktion i hur väl ett system kan

implementeras och användas. Idag finns all denna informationen upplagd på internet, och det är

numera sällan som tjänsteföretag saknar ett e-supportsystem. Hur mycket information som kan

utvinnas beror till stor del på mängden information, men det som vägleder oss i

informationssökandet grundas i informationsarkitekturen. Det som gör att information presenteras

lättillgängligt beror sedan till stor del på det grafiska användargränssnittet.

TaxiCaller Nordic AB (hädanefter kallat TaxiCaller eller företaget) är ett svenskt IT företag som

tillhandahåller verksamhetskritisk mjukvara till hundratals taxi- och transportföretag (TaxiCaller,

u.å). TaxiCaller etablerades år 2011 och har sitt huvudkontor i Linköping. Man erbjuder med

mjukvaran ett komplett system för taxibolagen att hantera bokningar och vara synliga till

konsumenter genom online-bokningar via webb och applikation. Taxibolagen som använder sig av

mjukvaran kan variera i storlek och kan således ha helt olika förutsättningar att lära sig och

implementera systemet. Med kunder i över 60 länder har TaxiCaller supportbemanning runt om i

världen och en stor del av frågorna går till support genom chatt och mejlkonversationer. Detta har

genererat en stor mängd dokumenterade frågor som företagets kunder har kring systemet. Genom

att använda denna dokumenterade information kommer denna kandidatuppsats undersöka hur

TaxiCallers nya supportcenter kan struktureras för att minska flödet av inkommande frågor till

support.

1.1 Problemformulering

TaxiCaller har idag ett omfattande trafikledningssystem som kräver en funktionell manual som

kan instruera och vägleda användaren i användandet av hela systemet. I dagsläget har man, trots

en virtuell manual, ett stort antal kunder som kontaktar support för information som kan återfinnas

i denna manual. För att underlätta supporthantering bör en mer intuitiv och användarvänlig

landningssida och ett mer organiserat grafiskt användargränssnitt skapas för att användaren enkelt

skall finna informationen man söker.

2

1.2 Syfte

Syftet med denna uppsats är att undersöka hur informationsbehovet ser ut hos användare som

nyttjar TaxiCallers supporttjänster. Syftet är därefter att strukturera upp ett supportcenter för att

svara på kunders informationsbehov och underlätta användning av företagets mjukvara.

För att svara på syftet används följande frågeställningar:

- Hur ser det nuvarande informationsbehovet ut hos användare som vänder sig till företagets

supporttjänster?

- Hur kan ett grafiskt användargränssnitt för en webbplats supportcenter se ut för att besvara

det framtagna informationsbehovet?

1.3 Avgränsningar

Webbplatssidan för support är del av TaxiCallers webbplats, men endast nämnd sida samt det

grafiska användargränssnittet för kunskapsbasen kommer omformas. Ett sekretessavtal har skrivits

under för genomförandet av studien. Således har all kunddata sammanfattats och kortats ned i

bilagorna för att undvika inkluderandet av personlig information.

3

2. Teoretiskt ramverk Avsnittet presenterar tidigare forskning, riktlinjer och information som utgör grunden den följande

processen och dess resultat.

2.1 Interaktionsdesign och användarupplevelse

Interaktionsdesign handlar om att reducera negativa upplevelser, som frustration, för användaren

och att förbättra de positiva upplevelserna som kommer med att använda produkter. Enligt Preece,

Rogers och Sharp (2015).

Termen användarupplevelse, eller user experience (UX), har haft en varierande betydelse. Arvola

(2014) beskriver att begreppet myntades för att inkludera alla aspekter av en persons upplevelse

med ett system. För att skapa en god användarupplevelse har mål ofta skapats med fokus på

effektiv och lätt användning av ett system (Arvola, 2014). Inom ramen för webbdesign är

användarupplevelsens design för webben grundad utefter användarens behov och målen för

webbplatsen. Dessa skapar en specifikation som sedan informationsarkitekturen och

gränssnittsdesignen tas fram utefter (Garrett 2002, se Arvola 2014, s. 21).

Fadeyev (2012) beskriver användarens centrala roll som beslutsfattare för vilka funktioner som

kommer att användas. En användarcentrerad design har således blivit en standard för lyckad

webbdesign. För att bättre förstå användarens interaktion med webbplatser beskriver Fadeyev ett

antal beteendemönster:

Användare skannar istället för att läsa. Webbplatsen analyseras snabbt av användaren för

att finna fixerade punkter eller ankare som kan vägleda resterande innehåll.

Användare på webben insisterar på direkt belöning och är otåliga. Om webbplatsen har

hög kognitiv belastning och upplevs som mindre intuitiv i navigationen blir användare

villiga att lämna webbplatsen för att söka efter andra alternativ. Detta sker i ögonblicket

som webbplatsen inte möter användarens förväntningar.

Användare gör inte valen som är mest optimala. Användare söker inte sekventiellt från

en sektion till nästa för att finna den snabbaste vägen till informationen. Istället söker

användaren efter det första rimliga valet för att snabbt gå från ett steg till nästa.

Användare följer intuitionen. Oftast tar sig användaren igenom utan att läsa informationen

som förses. Användaren behöver inte förstå hur saker fungerar så länge de kan använda det.

Användare vill ha kontroll. Användare vill kunna lita på att informationen presenteras

konsistent genom webbplatsen och de vill kunna kontrollera det som sker i webbläsaren.

Därav kan länkar som öppnas i nya fönster vara olämpliga och sidor och en

4

saknad ”tillbaka” knapp kan göra att användaren inte kan hitta tillbaka till föregående

innehåll.

2.2 Grafiskt användargränssnitt

Grafiska användargränssnitt öppnar upp möjligheter för användare att interagera med ett system

och möjliggör produktens information att presenteras och representeras på skärmar eller dylikt

(Preece, Rogers och Sharp, 2015).

McKay (2013) talar i sin bok om att användargränssnittet är kommunikation som kräver effektiv

mänsklig kommunikation. Detta koncept förklaras som att användargränssnittet i grunden är en

konversation mellan användaren och produkten, där användaren utför uppgifter för att uppfylla

specifika användarmål. En bra användargränssnitts design handlar om att kommunicera till

användare på ett sätt man gör i person så att kommunikationen upplevs naturlig, enkel och vänlig

med ett fokus på användarens mål (McKay 2013). Element som används i ett användargränssnitt

kan mätas i hur effektivt de kommunicerar och om elementet inte tillför någon kommunikation är

det överflödigt.

2.3 Informationsarkitektur

När informationsarkitektur appliceras i grafisk design och informationsdesign syftar man på

struktureringen och den visuella representationen av information (Resmini, 2014). Informations

arkitekturen är ofta gömd i den slutgiltiga produkten som användaren interagerar med.

Webbplatsers grafiska design, funktionalitet och innehåll är de specifika element som användaren

möter i interaktionen, men strukturen som harmoniskt placerar innehållet är informations

arkitekturen (Resmini, 2014).

Webbplatser existerar i en bred mediemix där olika logiska strukturer kan komma att användas.

Brister i informationsarkitekturen kan förekomma när användare har en förväntning på en

webbplats logiska struktur som inte överensstämmer, och förvirring uppstår. Det kan även

resultera i att användarens mentala modell som skapats för att förstå en produkt eller tjänst skiljer

sig från hur företaget förstår produkten eller tjänsten (Resmini, 2014).

För att strukturera innehållet på en webbplats behöver överväganden göras för hur användare

söker efter information och sedan strukturera innehållet utefter de framtagna preferenserna

(Karafillis, 2014). Att presentera och visualisera all data för användaren kan göra gränssnittet

rörigt och därför delas informationen upp i olika metadatakategorier. Metadata syftar på

information om information och kan delas upp i tre grupper: kritisk, valbar, och irrelevant. En

vanlig regel är att de valbara kategorierna presenteras efter att användaren har navigerat genom de

kritiska kategorierna.

5

Om valen som presenteras för användaren missförstås kan kategoriseringen ha gjorts förgäves.

Därför måste viss övervägning göras för hur kategorierna bäst kan förklaras. Karafillis (2014)

beskriver hur för mycket information gör att gränssnittet upplevs som rörigt. Men med för lite

information behöver användare gissa vart länkar leder och skapar besvikelse när förväntningen

inte möts. Det kan resultera I tappat förtroende för gränssnittet och att användaren lämnar

webbplatsen. Så för att förklara navigeringsvalen kan designers utnyttja följande alternativ:

- Bemärkningar;

- Bemärkningar och bilder/illustrationer;

- Bemärkningar, bilder/illustrationer och förklaringar.

2.4 Webbplatskarta

En webbplatskarta är en representation av en webbplats arkitektur eller strukturella design. Genom

att reducera sidan till de mest viktiga komponenter till sidor, läggs fokus på att organisera dessa

komponenter i relation till varandra (Jenkins, 2009).

Enligt Slickplan (2018) kan en webbplatskarta ses som en organiserad lista eller ett flödesschema

som illustrerar kopplingar mellan webbplatsens sidor och dess innehåll. Webbplatskartan

representerar innehållet på en webbplats och är i teorin en disposition för webbplatser.

En visuell webbplatskarta är en av tre typer av webbplatskartor (Slickplan, 2018). Visuella

webbplatskartor illustreras ofta som 2D ritningar som representerar hierarkin på en webbplats. De

utgår oftast från startsidan och utmynnar i olika sidkategorier. Dessa typer av webbplatskartor

illustrerar rörelse genom att demonstrera hur användare kan navigera genom en webbplats. En

viktig del för planering av användbarhet. Webbplatskartan blir slutligen en guide till hur

webbplatsens innehåll layoutas för att främja navigationsstrukturen (Jenkins, 2009).

2.5 Tekniskt information

Webbplatser som förser information är menade för passiv konsumtion, där interaktiv text hjälper

användare att navigera genom sidorna för sidan med ett begränsat antal av aktiviteter, som

kontohantering och att fylla i formulär (Lior, 2013).

Lior (2013) beskriver informationsattribut som alla element och egenskaper av texten och med rätt

kombination gör att gränssnittet blir lättläst och användbart för användaren. Lior (2013) tar upp tre

olika attribut: synligt, läsbart, och förståeligt. Information som är kritisk prioriterar

synlighetsattributet då informationen måste vara lätt att se och hitta.

6

2.6 E-support

E-support är en generell term som används för att beskriva kundservice och support verksamhet

som nu sker via web eller över digitala system (Technopedia, u.å). Man kan även beskriva det som

all assistans eller information som ges till användare för att kunna använda en produkt eller tjänst

(Czegel, 2001).

Czegel (2001) förklarar att grunden för en supportsidas design kan fastställas genom att besvara

frågan ”varför besöker användare denna sida?”. Svaret kommer troligen indikera ett scenario där

användare behöver hjälp, de behöver hjälpen fort och de behöver hjälp i ett format som de kan

förstå. Därför bör komplex grafik och annat material som kan fördröja laddningen av sidan

undvikas och navigationen bör hållas simpel och tydlig.

7

3. Metod En förstudie kommer göras för att utvärdera den nuvarande support hanteringen hos företaget

TaxiCaller. Detta involverar bland annat en intervju med supportchef på TaxiCaller samt en

dokumentation av företagets webbplatskarta. Förstudien följs av en genomfattande undersökning

av användardata. Ett visst antal data kommer att läggas åt sidan för att användas som validering av

det framtagna konceptet. Utifrån undersökningen av data kommer informationsbehoven att

fastställas. Därefter görs en genreanalys på tre olika företags supportcenter som kommer bidra till

en grund för designprocessens olika beslut. Designprocessen följer sedan med målet att svara på

de framtagna informationsbehoven i ett koncept för hur TaxiCallers supportcenter kan se ut.

Slutligen kommer en validering göras av både konceptet och den nuvarande lösning som finns på

TaxiCallers webbplats. Valideringen kommer utnyttja användardata och därefter kommer resultat

att jämföras och analyseras.

3.1 Förstudie

Förstudien är indelad i två delar för att få en god uppfattning om den nuvarande

supporthanteringen på företaget. Den första delen består av en intervju med företagets supportchef

som ger en reflektion av företagets uppfattning av den nuvarande situationen. Den andra delen av

förstudien utgörs av att skapa en webbplatskarta av TaxiCallers nuvarande supportavdelning som

dokumenterar användarens förutsättningar för informationssökning.

3.1.1 Intervju med Supportchef

För att tydligare identifiera problemet och skapa en god grund för designprocessen behövs en

tydligare problembeskrivning tas fram. Detta kommer att göras genom en semistrukturerad

intervju med supportchef på TaxiCaller. Att kunna träffas och hålla intervjun i person gör att ett

bättre konversationsflöde kan uppnås och möjlighet att ställa följdfrågor är större. Detta gör att

eventuella problem som inte redan formulerats via tidigare mejlkonversationer kan upptäckas.

3.1.2 Webbplatskarta TaxiCaller

För att få en förståelse för hur den nuvarande lösningen ser ut på TaxiCallers webbplats görs en

webbplatskarta (2.4). Webbplatskartor är ett passande verktyg för att kartlägga vilka brister som

finns i en nuvarande webbplatsdesign (Slickplan, 2018).

8

3.2 Sammanställning av användardata

För att skapa en god uppfattning om nuvarande behov hos användare som utnyttjar TaxiCallers

supporttjänst skall data samlas in från supporthanteringen på företaget. Denna data skall

sammanställas och sedan analyseras för att utläsa konkreta användarbehov. Data hämtas främst

genom företagets CRM-verktyg. CRM står för customer relationship management och är generellt

ett system som underlättar hantering av företagskontakter och all data som associeras med

företagen (Salesforce, 2017). Data som kommer ses över i denna studie kommer innefatta

dokumenterade utdrag över kunders kontakt med support i form av chattloggar.

Data kommer väljas ut genom följande urvalsprinciper:

● Löst fråga

● En fråga per kund

● Fråga som mottagits under de senaste sex månaderna

● Frågan skall ha en problemformulering. Ej i form av en begäran om förändring i systemet,

uppdatering eller rapportering av buggar.

För att avgöra om efterfrågad information kan uppsökas behöver frågorna vara lösbara med

information som finns publicerad. Flera kunder har vid flera tillfällen varit i kontakt med support,

så för att få ett så nyanserat urval som möjligt begränsas frågorna till en per kund. Då systemet

över tid har förändrats genom diverse uppdateringar har en gräns på sex månader fastslagits för att

beröra frågor som ställts rörande den senaste versionen av systemet som används. Flera sorters

frågor rapporteras i CRM-verktyget och i chatloggarna utan sorteringsmöjlighet, således måste

frågan vara av en slags problemkaraktär. Kunders begäran om funktioner i systemet, uppdateringar

eller rapporteringar av buggar är en viktig informationskälla för företaget vilket kräver att kunden

tar kontakt med supportpersonal. Dessa frågor kan således inte lösas med publicerat

informationsmaterial.

Inledningsvis kommer ett urval på 100 chattloggar sållas ut. Därefter kommer 10 utav dessa

chattloggar läggas åt sidan för att användas i valideringsprocessen som beskrivs i avsnitt 3.4.

Totalt kommer 90 insamlade frågor analyseras och sammanställas i en tabell utefter prioritering.

Antalet frågor anses rimligt för tidsramen samt för att kunna framställa väl underbyggda

informationsbehov.

9

3.3 Genreanalys

För att skapa en uppfattning om de nuvarande strukturer och lösningar på det grafiska

användargränssnittet inom e-supportgenren skall en genreanalys göras på tre webbplatsers

supportcenter. Denna analys görs för att ta reda på eventuella riktlinjer för det grafiska

användargränssnittet, men också för att skapa en uppfattning om nuvarande trender.

Genreanalysen kommer även att kartlägga informationsstrukturerna i webbplatskartor som

kommer att skapa en grund för hur informationen struktureras och prioriteras. Denna information

kommer att vävas in i efterföljande designprocess (3.4.1).

Eftersom genren utgår från ett användarscenario där användaren har problem att utnyttja en

produkt eller tjänst och söker efter support är det viktigt att förstå den mentala modell som

användaren kan ha. Således är genreanalysen anpassad att undersöka den informationsarkitektur

som användaren kan vara van vid att möta (2.3).

Denna genreanalys utförs i fyra huvudsteg och skapas, med viss modifikation, utifrån Arvolas

(2014) beskrivning av hur en genreanalys kan utföras.

1. Avgränsa analysen: I detta steg skall målen med genresanalysen definieras och beslut tas om

vilken användningsuppgift som kommer jämföras mellan webbplatserna.

2. Kartlägga beståndsdelar: Vilka beståndsdelar är varje supportcenter uppbyggda av?

3. Identifiera syften: Hur är det tänkt att användaren skall interagera med supportcentret

utifrån beståndsdelarna?

4. Precisera likheter och skillnader: Vilka likheter och skillnader finns mellan de olika

hjälpcentren? Vad kan de bero på?

3.3.1 Jämförelse av webbplatskartor

För att kunna jämföra uppbyggnaden av andra supportcenter kommer de illustreras i form av

webbplatskartor. Genom att göra en jämförelse av de olika strukturerna kan för och nackdelar

dokumenteras och användas som inspiration för designprocessen (3.3.2).

10

3.4 Designprocess

Designprocessen kommer att baseras på informationsbehoven hos användare som framtagits

genom analys av användardata (3.2). Kunskap från teori (2.1–2.6) samt författarens befintliga

kunskaper inom grafisk formgivning kommer utgöra underlag för beslutsfattande i

designframtagningen. Detta kommer att generera en färdig presentation och visualisering av

konceptet som är menat att lösa de användarbehov som framställdes genom analys av kunddata.

Designprocessen kommer att bestå av tre faser som är anpassade utefter kandidatuppsatsens art.

3.4.1 Urvalsprocess

Designprocessen inleds med en urvalsprocess för att prioritera information som skall presenteras

och visualiseras. Att presentera all information som användare eftersöker skulle generera till att

gränssnittet kan ses som rörigt. Därför görs en avvägning mellan vilken information som anses

kritisk och valbar (2.3). Den kritiska informationen kommer sedan struktureras med hjälp av en

webbplatskarta (3.4.2).

3.4.2 Webbplatskarta

Att skapa en helt ny webbplatskarta utan att ta hänsyn till det nuvarande innehållet anses som

ineffektivt (Slickplan, 2018). Då existerande material strävar att återanvändas kommer

designprocessen att använda webbplatskartan över TaxiCallers nuvarande webbplats som grund.

Informationen från urvalsprocessen i 3.4.1 samt jämförelser av webbplatskartor gjorda i 3.3.1

kommer motivera omstruktureringen av webbplatskartan för att bidra till en mer simpel

navigering.

3.4.3 Prototyp

Utformningen av prototyper uppmuntrar till reflektion av designen och är ett effektivt verktyg för

att utforska designidéer. Prototypen underbygger valen som görs mellan alternativ genom att

manifestera en tänkt design. Prototypning involverar producering av en begränsad version av

produkten som syftar att svara på en designs lämplighet (Preece, Rogers och Sharp, 2015).

Lo-Fi

Lo-fi är en förkortning av low-fidelity som innebär att prototypen är av låg detaljeringsgrad

(Arvola, 2014). För att utforska alternativ för det grafiska användargränssnittet baseras

framtagningen genom en lo-fi prototyp. Lo-fi protypen kommer illustreras med hjälp av

wireframes, ett dokument som visar upp struktur av innehåll och interaktionsmöjligheter. Genom

att illustrera konceptet i en lo-fi wireframe kan flera iterationer göras fram till att ett eftertraktat

resultat nås.

11

3.5 Validering

För att objektivt testa nuvarande supportimplementation och det nya designförslaget används tio

frågor som framtagits ur chattloggar som tidigare lagts undan (3.2). Dessa frågor används som

informationssökningar som skall genomföras i TaxiCallers nuvarande supportcenter och i det

framtagna supportpcentret som baserats på designprocessen (3.3). Då författaren ej använt dessa

frågor för att basera det framtagna användargränssnittet på, kan de på god grund verka som

konceptets uppfyllnadskrav. För testet rangordnas frågorna om eventuellt överlapp av innehåll

existerar, där de flest efterfrågade kategorierna ges en högre prioritet.

Testet avser att dokumentera den optimala navigationsvägen startsida till det kategoriområde som

frågan berör. Detta görs genom undersökning av antal klick som i minsta mån behöver göras. Med

färre antal klick anses navigationen vara förenklad. Testet kommer även beröra antalet

informationsområden för att se eventuell spridning av informationsmaterialet. Med stor spridning

anses informationen vara svåråtkomlig.

12

4. Process och Resultat

4.1 Förstudier

I detta avsnitt beskrivs resultatet av de två delar som ingick i förstudien.

4.1.1 Intervju med Supportchef

Förstudien inleddes med en semistrukturerad intervju med TaxiCallers supportchef (se bilaga 1).

Under intervjun förklarades uppsatsens syfte och process, och därefter kunde frågor om

supporthanteringen ställas.

På företaget finns två olika supportavdelningar. Den ena avdelningen är en first-linesupport som

hanterar all kontakt med kunder. Informationen som first-linesupport utnyttjar för att för att

assistera kunder återfinns i både manualer och i knowledge base. Knowledge base samlar

informationsartiklar baserade på vanliga frågor från kunder. Den andra avdelningen, second-

linesupport, förser informationen för såväl manualer och knowledge base och fungerar som en

mellankanal mellan utvecklare och first-linesupport. Supportchefen som intervjun genomfördes

med jobbar nära second-linesupport.

Uppfattningen är att en stor del av inkommande ärenden är frågor kring initiala inställningar och

priser. Inställningar rör bland annat rapportgenerering, tilldelnings inställningar och

tariffinställningar. Information som berör dessa områden är skrivna i både manualer och i

knowledge base. Man har märkt att kunder i nuläget inte använder sig av kunskapsbasen. Något

som önskas att kunder ska nyttja mer. Kundernas kunskapsbakgrund skiljer sig även markant

beroende på företagens storlek och tidigare erfarenheter av liknande mjukvara. När first-

linesupporten löser problem åt kunder utnyttjar de samma informationskanaler som kunden har

möjlighet att använda.

Önskemålet att få kunder att nyttja knowledge base har tagits i åtanke för fortsatt process och

därför kommer ett konceptförslag med en artikelmall för knowledge basen att tas fram.

13

4.1.2 Webbplatskarta TaxiCaller

Webbplatskarta 1 - TaxiCaller

I webbplatskarta 1 illustreras den nuvarande strukturen för TaxiCallers upplagda supportmaterial. I

företagets nuvarande lösning utgör inte supportavdelningen en startsida. Supportavdelningen listas

som en nivå under hemsidan och är en del av webbplatsens sidhuvud, en så kallad header. En

webbplats header inkluderar ofta företagets logotyp samt det huvudsakliga navigeringsfältet.

Denna sektion är placerad överst på varje sida och är oftast del av en mall som visas på

webbplatsens alla sidor (Christensson, 2012). Under ”support” fliken på företagets webbplats finns

fem kategorier listade i en rullgardinsmeny. Dessa kategorier listas i webbkartan i samma vågräta

nivå. Inom varje kategori finns ytterligare länkar till både relevant informationsmaterial som berör

support och övrigt informationsmaterial. Underkategorierna är information som finns listad på

samma sida som objektet är länkat under. Vissa kategorier erbjuder ingen supportfunktion, som

exempelvis ”Video” kategorin. Upprepningar görs för området ”support” och ”knowledge base”.

Sammanfattningsvis leder den nuvarande lösningen till att användaren måste navigera in på alla

sidor för att få en översikt av informationen som erbjuds i varje flik.

14

4.2 Sammanställning av användardata

Totalt 90 dokumenterade chattloggar har analyserats och informationen har sammanställts i Bilaga

2. Baserat på användarnas formuleringar i chattloggarna samt typen av information man sökt efter

har en lista av kategorier kunnat sammanställas.

Billing

Denna kategori berör frågor som användare har rörande betalningsmetoder för användarens

klienter. Användaren sökte i denna kategori efter att sätta upp särskild betalmetod för vissa

klienter.

Kategorin berör admin panelen.

Booking/Jobs

Denna kategori innehåller information rörande bokningsprocessen som utförs i dispatch konsolen.

Användaren sökte i denna kategori efter deskriptiva förklaringar för hur man använder

bokningsverktyget, både för att utföra bokningar och se information om gjorda bokningar.

Kategorin berör dispatch konsolen.

Dispatch

Utöver bokningsfunktionerna i dispatch konsolen, sökte användarna efter förklaringar av diverse

funktioner i verktyget i helhet. Användare sökte exempelvis efter information rörande

omorganisering av förares kö-positioner.

Kategorin berör dispatch konsolen.

Driver app

I denna kategori söker användaren efter information om inställningar och användandet av driver

app verktyget.

Kategorin berör driver appen.

IVR

IVR är en samtalsfunktion som och kopplas med ett externt verktyg. Användare frågar således hur

denna funktion sätts upp.

Kategorin berör admin panelen.

Messages

Denna kategori omfattar alla frågor användare kan ha kring meddelandefunktioner. Det finns olika

typer av meddelanden i olika verktyg men de kan alla definieras som ”messages”. Frågor kan röra

meddelanden som skickas mellan dispatcher och förare, eller användare till klienter.

Kategorin berör admin panelen och dispatch konsolen.

15

Navigation

Denna kategori är en omformulering användarnas frågor. Användare frågade i chatten ”Var kan

jag hitta passenger app manualen?”. Detta indikerar att man haft problem med att navigera till

webbplatsens upplagda supportmaterial.

Kategorin berör supportcentret.

Online Booking

Online booking är en central funktion för mjukvaran och erbjuder användaren möjlighet att ta

emot bokningar via app och webb. Användare söker ofta information om processen för att aktivera

funktionen.

Kategorin berör admin panelen.

POI

POI står för en funktion som markerar punkter av intresse. Användaren söker efter information om

hur funktionen fungerar.

Kategorin berör admin panelen.

Reciepts

Användare söker i denna kateori efter hur dokumentationen av betalningar i form av kvitton kan

göras.

Kategorin berör admin panelen.

Reports/Replay

I denna kategori sökte användaren efter hur man genererar rapporter kring bokningshistorik,

sammanfattade miltal, och intäkter. Även GPS historik efterfrågades och då dessa funktioner är

positionerade nära varandra i adminverktyget slås dessa kategorier ihop.

Kategorin berör admin panelen.

Set up Account

I denna kategori hade användarna frågor som berörde många områden i adminverktyget, men

gemensamt rörde dem de initiala inställningar som görs för att använda företagets mjukvara.

Kategorin berör admin panelen.

Set up Users/Vehicles

Även denna kategori berör initiala inställningar men begränsas till området användare och fordon.

Här frågar användaren bland annat om hur information kan läggas in om förare.

Kategorin berör admin panelen.

Tariffs/Taximeter

Denna kategori berör inställningar av tariffer där användaren ofta söker efter information om hur

16

man ställer in tarifferna efter anpassade kriterier.

Kategorin berör admin panelen.

VoIP

VoIP är en funktion som stöttas av mjukvaran men som kräver att användaren nyttjar en extern

leverantör. Användaren har således frågor om hur installationen och aktiveringen av funktionen

går till.

Kategorin berör admin panelen.

Zones

Zonerna är en inställning användarna kan göra för att specificera områden med specifika tillägg.

Användarna frågar i denna kategori hur zonerna påverkar tilldelning av jobb till förare.

Kategorin berör admin panelen.

För att skapa en prioritering av kategorierna gjordes en tabell över antalet förfrågningar inom varje

kategori. Antalen summerar antalet chattloggar (90st) då varje chattlogg endast tilldelades en

kategori.

Tabell 1 - Kategori frekvens

17

För att bearbeta informationen ytterligare rangordnades alla kategorier med hjälp av support- och

säljpersonal (2.3). Rangordningen placerade kategorier utefter kritiska och valbara områden i

förhållande till varandra. Den kritiska evalueringen gjordes baserat på hur verksamhetskritisk en

kategori är för att driva systemet med minsta möjliga ansträngning. Eftersom alla kategorier hade

efterfrågats var det ingen kategori som ansågs irrelevant. Baserat på rangordningen gavs kategorin

ett värde från 1–16 som sedan slogs ihop med antalen listade i tabell 1. Totalvärdet i tabell 2 är

den slutgiltiga prioriteringen som skall tas i hänsyn i efterföljande designprocess.

Tabell 2 - Värderingstabell

18

Figur 1 - Procentuel fördelning

I figur 1 dokumenteras det procentuella förhållandet av lösningsmetoder i chattloggarna. I 35

chattloggar försågs användaren endast med förklaringar i form av beskrivande text. I 55

chattloggar försågs användaren med någon form av stöd. Utöver den beskrivande förklaringen

som gavs kunde supportpersonal bistå med skärmbilder, URL, remote session och länkar till

manualtexter.

Förklaring med stöd

av följande:

Skärmbild, URL,

Remote Session &

Manuallänk

61%

Endast förklaring

39%

Lösningsmetod

Förklaring med stöd av följande: Skärmbild, URL, Remote Session & Manuallänk Endast förklaring

19

Slutligen sammanställdes antalet gånger som stöd användes i chattloggarna, detta resultat

illustreras i figur 2. I de flesta fall behövde användaren navigera till rätt sidor för att kunna sätta

upp inställningar eller se särskild information. Då försågs användaren med URL och/eller

skärmbild. För ytterligare förklaring om inställningsprocesser och funktioner försågs användaren

med länkar till berörda områden i manualerna. I de fåtal fall som användaren hade svårighet att

genomföra processerna, användes remote session för att låta supportpersonal assistera i

uppsättningen av användarens inställningar. Detta förekom bland annat kring uppsättningen av

tariffer.

Figur 2 – Stöd frekvens

21

4

22

30

0

5

10

15

20

25

30

35

Manual Länk Remote Session Skärmbild URL

Förklaringar med stöd

Antal gånger som typen av stöd användes

20

4.3 Genreanalys

Valet av supportcenter har baserats på att de skall underhålla programvara riktade åt andra företag.

Efter att ha skummat igenom ett flertal webbplatser valdes slutligen supportcenter från företagen

Asana, Upsales och Zendesk. Användningsuppgiften som kommer undersökas är hur

supportcentret samlat och presenterat informationsmaterial för användaren.

Skärmbild 1 - Upsales Supportcenter

Skärmbild 1 illustrerar en klassificering av beståndsdelarna på Upsales supportcenter. Överst i

sektion 1 finner vi en header som inkluderar företagets logotyp med en platsindikation som

beskriver var användaren befinner sig. I denna header listas även sökmotor, formulär för att skicka

förfrågningar, och inloggning. Denna header varierar i innehåll på webbplatsens övriga sidor.

21

Störst fokus i sektion 1 läggs på att låta användaren själv formulera sin fråga genom den

centrerade sökmotorn. Direkt under sökmotorn listas alternativ som ger användaren möjligheten

att kontakta supportpersonal via chatt, telefon, mejl eller skärmdelning. Chattverktyget, som på

bilden är placerad i det nedre högra hörnet är responsiv och följer användaren när hen scrollar

genom sidan.

I följande sektion finner användaren huvudkategorier som var och en innehar flertal artiklar och

guider. Dessa kategorier är tydligt uppdelade genom ikoner som stöttas av titlar samt en kort

säljande beskrivning av varje kategori.

I sektion 3 listas verktyg och allmän relevant information. De listas i två kategorier där API

verktyg, systemets statusinformation och systemets varumärkesmanual utgör en kategori. Den

andra kategorin är avsedd för företagets nyhetsflöde. Båda kategorier utformas som

huvudkategorierna med ikon, titel och kort säljande beskrivning. Då dessa har placerats längre ned

håller de en lägre prioritet och anses vara sekundära kategorier. De sekundära kategorierna kan

tolkas som något separat från hjälpärenden då de öppnas i separata flikar i webbläsaren. I samma

sektion följer en lista med ett fåtal utvalda hjälpartiklar.

Den fjärde sektionen, ses som en footer för webbplatsen. En footer innehåller vanligen namnet

på företaget som publicerat webbplatsen tillsammans med relevant upphovsrättsinformation. De

kan även innehålla vanliga navigationslänkar som ”Om oss” och ”Kontakt” (Christensson, 2012).

Innehållet i denna footer upprepar länkar till supportcentret, API och status, samt länkar tillbaka

till företagets huvudwebbplats. Under dessa länkar upprepas kontaktlänkarna som listades under

sökmotorn.

Användare kan i Upsales supportcenter leta upp information genom att söka efter nyckelord eller

en fråga i sökmotorn. Detta ses troligt som det första valet användaren gör för att komma till nästa

steg (2.1). Alternativt kan användaren kontakta support direkt om frågan har en mer komplicerad

eller kritisk karaktär genom att klicka på någon av länkarna listade under sökmotorn.

Huvudkategorierna är tydligt listade och underlättar för användaren att skanna områden efter det

som passar användarens ärende (2.1). De sekundära kategorierna används inte enbart för att lösa

problem som användaren kan ha stött på i systemet, utan bidrar med ytterligare information som

kan vara lämplig i andra användarscenarion. Användarscenarion där användaren behöver riktlinjer

för marknadsföringen kan lösas med information i varumärkesmanualen osv. Slutligen listas ett

urval av artiklar som troligen listar de mest efterfrågade artiklarna. Om användaren vid denna

punkt inte hittar det hen söker erbjuds kontaktinformationen ännu en gång i footern. Det går ej att

avgöra om detta val är medvetet för användarscenariot eller endast följer en standard för

webbplatsstruktur.

22

Skärmbild 2 - Asana Supportcenter

23

Skärmbild 2 illustrerar en klassificering av beståndsdelarna på Asanas supportcenter. Överst i

sektion 1 finner vi en header som listar logotyp, produktinformation, kontakt, inlogg och demo.

Denna menyrad finns tillgänglig i huvuddelen av Asanas webbplats. I samma höjd som

platsindikationen som ges i en rubrik, finner användaren sökmotorn. Under dessa element listas tre

kategorier där användaren har möjlighet att dela in sin problemformulering på tre olika sätt.

Kategorierna kan ses som huvudkategorier som kan hjälpa användaren att formulera sitt problem.

Dessa expanderas till ytterligare kort för olika problem som användaren kan stöta på.

I sektion 2 listas alla övriga resurser som användaren kan utnyttja. Dessa listas med titel, kort

beskrivning och en länk till varje resurs som är skrivna i handlingar såsom ”besök” och ”läs”.

Footern är placerad i sektion 3. Denna sektion är expanderad på höjden för att rymma

länklistorna som tillhör de fem listade kategorierna. Genom dessa kategorier kan användaren

navigera genom alla delar i Asanas webbplats. Strax under länklistorna kan användaren ställa in

språk, få tillgång till användarvillkor, sociala medier och nedladdning av Asanas applikation.

I Asanas supportcenter läggs huvudfokus på de frekventa problem som användaren kan stöta på.

Dessa listas i de tre huvudkategorier. Huvudkategorierna är skrivna på ett sätt så att användaren i

problemsituationen kan få hjälp med att formulera vad för problem hen har stött på. De är tydligt

skrivna och kan enkelt uppfattas av en användare som skummar igenom informationen. Om frågan

är så pass tydlig eller om det gäller en specifik funktion kan användaren utnyttja sökmotorn som

listas ovanför huvudkategorierna. Listan med ytterligare resurser kan hjälpa användaren att

navigera till andra platser där användaren kan finna svar. Den presenterar alla områden tydligt så

att användaren kan få en uppfattning om all hjälp och information som erbjuds. Då alla länkar

öppnas i nya flikar kan användaren enkelt gå tillbaka och navigera till en annan sida om

informationen ej skulle stämma. Om användaren vid denna punkt inte finner det hen söker finns

en länklista att tillgå i footern. Denna länklista återfinns på övriga delar av Asanas webbplats

skapar således en förväntning hos användaren. Allra längst ned har övrig information och

inställningar placerats, troligen då de inte kan kategoriseras på andra platser på sidan. Asanas

lösning erbjuder inte användaren en direkt kontakt med personal. Användaren kan om så önskas

kontakta säljare för att få mer information om verktyget, men detta görs via formulär som innebär

en viss väntetid.

24

Skärmbild 3 - Zendesk Supportcenter

25

Skärmbild 3 illustrerar en klassificering av beståndsdelarna på Asanas supportcenter. I sektion 1

finns en menyrad som leder till produktinformation, användarforum, språkinställning och

inloggning. Men huvudfokus läggs på platsindikationen, skriven som en titel samt sökmotorn.

Chattverktyget, som på bilden är placerad i det nedre högra hörnet är responsiv och följer

användaren när hen scrollar genom sidan.

I sektion 2 listas huvudkategorierna utifrån de olika produkter som Zendesk erbjuder. De listas

med ikoner och en titel och utgör ett helt element med inbäddad länk.

Strax under i sektion 3 listas fyra kategorier som kan ses som sekundära kategorier då de berör

information utöver ren problematisk karaktär. Bland annat listas uppdateringar, och utveckling. I

kategorin ”Community” länkas användarforumet en andra gång. Strax under de fyra sekundära

kategorierna listas utvalda artiklar. Artiklarna är sorterade under tre olika tabbar som användaren

kan navigera mellan.

I sektion 4, följt efter en titel och kort beskrivande text, länkas forumet ännu en gång. Strax

under följer en säljande text och en länk till en demoversion av programmet. I footern listas

företagets adress såväl som länkar till säkerhetspolicy, användarvillkor och systemstatus.

I Zendesks supportcenter erbjuds användaren direkt att söka efter sitt problem genom sökmotorn

som placerats i sektion 1. Eftersom Zendesk tillhandahåller flera programverktyg så listas dessa i

huvudkategorierna för användarens möjlighet att hitta svar för ett specifikt program. De är

framställda med titel och ikon för att användaren enkelt ska skanna informationen och få en

överblick av alla delar. I de sekundära kategorierna ges användaren färre valmöjligheter, där två av

alternativen kan bidra i problemscenarion och de övriga två innehåller mer allmän information. De

utvalda artiklarna är listade under olika tabbar och på så vis minskar belastningen av att ha all

information på display. I sektion 4 uppmanas användaren att dra nytta av Zendesks användarforum

för att finna svar. Om övriga användare som ej påbörjat användning av systemet navigerat in på

sidan erbjuds dessa användare att prova på systemet genom en länk i sektion 4. Slutligen listas vad

som vanligen återfinns i en webbplats footer såsom ”användarvillkor”. Chattverktyget finns

tillgängligt för användaren genom hela sidan och ses också som ett lösningsscenario på

användarens eventuella problem.

26

Alla webbplatsernas supportcenter erbjuder användaren möjligheten att söka efter sitt problem

genom en sökmotor. Placeringen är genomgående gjord i den första sektionen på alla webbplatser

och kan ses som en logisk placering där användare ofta stöter på denna funktion.

Zendesk och Upsales erbjuder användaren möjligheten att få personlig hjälp i sökningen med att

erbjuda ett chattverktyg. Placeringen för dessa verktyg är i det nedre högra hörnet på skärmen,

vilket kan påträffas även på övriga webbplatser.

Zendesks supportcenter tar upp en del funktioner ett flertal gånger, exempelvis användarforumet.

Med största sannolikhet är detta val gjort för att uppmana användare att vända sig till denna

lösning. I Asanas och Upsales lösning görs inga upprepningar utöver information som samlats i

footern. Denna information kan vara lämplig att upprepa främst på grund av konvention för var

användaren oftast kan hitta denna typ av information, som exempelvis kontakt eller

användarvillkor.

I alla lösningar erbjuds användaren flera kategorival för att kunna organisera och navigera till rätt

typ av information. Den främsta anledningen till att kategorierna kan ses som huvudkategorier och

sekundära kategorier är på grund av kategoriernas natur. I huvudkategorierna kan användaren

påträffa information specificerad att lära ut systemet eller svara på eventuella frågor/problem. Men

i de sekundära kategorierna expanderas typen av information till exempelvis nyheter,

utvecklingsverktyg och systemstatus. Information som kan komma till användning men inte direkt

avsedd för att lösa akuta problem som användaren kan stöta på när hen använder systemet i fråga.

Alla supportcenter har en viss likhet i den generella layouten. Eftersom supportcentret är en

samlingsplats för användaren att vidare navigera genom, så läggs prioritet på att synliggöra en

mängd kategorier såväl som alla hjälpverktyg som finns till användarens förfogande.

I helhet handlar supportcentret om att samla alla områden som användaren kan finna till nytta och

ge användaren en överblick på alla verktyg som finns till förfogande (2.6).

27

4.3.1 Jämförelse av webbplatskartor

Webbkartor skapas utifrån genreanalysens dokumentation av beståndsdelar (4.2). De huvudsakliga

beståndsdelarna illustreras sedan i webbplatskartor för att jämföras med TaxiCallers nuvarande

webbplatskarta. Denna jämförelse görs för att hitta för och nackdelar med lösningarna som blir

beslutsgrundande för omfromningen av webbplatskartan i designprocessen. Webbplatskartorna

dokumenterar den övergripande relationen mellan webbplatssidor och berör inte underkategorier

då det arbetet blir för omfattande.

Webbplatskarta 2 – Upsales Supportcenter

Webbplatskarta 2 illustrerar den uppfattade lösningen utifrån analys av skärmbild 1. Upsales

supportcenter agerar som startsida och leder ut till resterande sidor aw webbplatsen. Header samt

hjälpverktyg har placerats i en nivå över resterande innehåll då de båda ingår i sektion 1 i

skärmbild 1. Innehållet i Upsales header är betydligt mindre till skillnad från TaxiCaller, vilket

leder till färre länkar som leder bort från webbplatsens supportavdelning. Hjälpverktygen listas

28

separat från informationsmaterialet då de involverar kontakt med supportpersonal. Övrigt

informationsmaterial har placerats över de sex huvudsakliga informationkategorierna för att

begränsa illustrationsytan och reflekterar inte den prioritering som görs i skärmbild 1. I Upsales

har man valt att länka de sex webbplatssidorna till varandra och användare kan enkelt, utan att

behöva gå tillbaka, navigera till de olika huvudkategorierna. En lösning som ger användaren

mycket mer frihet och översikt, till skillnad från den begränsade översikt som ges i TaxiCallers

supportavdelning. De specifikt utvalda artiklarna i skärmbild 1 utgör artikellänkar som tar

avändaren direkt till avsedd underkategori. Denna funktion har även de två sökmotorerna, och

därför länkas dessa navigationsvägar med blocket som utgör allt informationsmaterial. Som mest

finns tre olika navigationsvägar för användaren att komma till avsedd underkategori. Även detta

skapar en större frihet för användaren att enkelt komma åt information i förhållande till

TaxiCallers webbplatskarta som består av direkta länkar. Övrigt informationsmaterial har också

inkluderats i Upsales supportcenter och dessa kan vara relevanta, som tidigare nämnt, i övriga

möjliga användarscenarion.

29

Webbplatskarta 3 – Asanas Supportcenter

Webbplatskarta 3 illustrerar den uppfattade lösningen utifrån analys av skärmbild 2.

Supportcentret agerar som startsida och leder ut till resterande sidor aw webbplatsen. Headern har

placerats i en nivå över resterande innehåll då dess länkar inte relaterar till övriga webbplatssidor.

Headern på Asanas webbplats länkar till ett flertal webbplatssidor likt TaxiCallers header.

Skillnaden är att användaren ej navigerar genom headern för att få tillgång till supportrelaterad

information. Huvudresurserna med informationsmaterial är listade under sex kategorier som utgör

de sekundära kategorierna i skärmbild 2. Huvudkategorierna i skärmbild 2 listas inte på samma

sätt i webbplatskarta 3 då de utgör ett slags artikelurval. Dessa resultetar i artikellänkar som tar

användaren till underkategorier inom något av de sex webbplatssidorna. Sökmotorn har precis som

artikellänkarna möjlighet att leda användaren till en specifik underkategori som listas under

specifik webbplatssida. Asanas webbplatskarta har således möjlighet att navigera till en

underkategori på tre olika sätt. Något som saknas i TaxiCallers nuvarande webbplatskarta.

30

Webbplatskarta 4 – Zendesks Supportcenter

Webbplatskarta 4 illustrerar den uppfattade lösningen utifrån analys av skärmbild 3. Zendesks

supportcenter agerar som startsida och leder ut till resterande sidor aw webbplatsen. I Zendesks

header är fyra länkar inbäddade, något färre än i TaxiCallers header. Övrigt informationsmaterial

samt upprepade webbplatssidor har klumpats ihop i samma nivå för att spara plats på

illustrationsytan. Det som kan utläsas är att ”community” kategorin är upprepad vid tre tillfällen,

vilket ger användaren minst tre länkvägar till underkategorin listad under ”community”. Det

övriga informationsmaterialet är även här anpassat för övriga användarscenarion. Då Zendesk har

totalt nio huvudkategorier blir underkategorierna väldigt spridda och informationsmaterialet kan

bli svårare att navigera till. Men med tre navigationsvägar kan informationen uppsökas efter

användarens preferens. Då artikellänkarna är samlade under ”tabbar”, som kan ses i skärmbild 3,

illustreras de som kategorier. Kategorierna har med denna lösning listats i samband med

navigationssvägen artikellänkar.

31

4.4 Designprocess

4.4.1 Urvalsprocess

Designprocessen påbörjades genom en urvalsprocess som gick ut på att sortera ut kategorierna

med värden presenterade i tabell 2. De kategorier som ansågs vara kritiska för att presenteras för

användaren på supportcentrets startsida bestämdes ha ett värde på minst 12. Detta resulterade i en

lista med kategorierna:

- Bookings/Jobs

- Set up Account

- Set up Users/Vehicles

- Dispatch

- Online Booking

- Tariffs/Taximeter

- Reports/Replay

- Driver app

- VoIP

Denna lista utgör innehållet som kommer presenteras i för att göra gränssnittet välordnat baserat

på användarnas preferenser (2.3). Övriga kategorier som inte listas behandlas som valbara och

faller således under det systemverktyg som berörs av kategorin. Exempelvis för att hitta till

kategorin ”Zones” bör användaren gå in på information om Admin panelen där ”Zones” listas som

en underkategori.

32

4.4.2 Webbplatskarta

Baserat på listan i 4.3.1 har kategorierna placerats ut i en webbplatskarta. Utifrån jämförelsen av

webbplatskartor i 4.1 har flera beslut fattats kring utformningen av webbplatskartan. Resultatet

kan ses nedan i webbplatskarta 5.

Webbplatskarta 5 - Omstrukturerad för TaxiCaller

I den omstrukturerade webbplatskartan kommer supportcentret utgöra startsidan för allt

supportrelaterat material. Användare kan på så sätt få en överblick av allt informationsmaterial

från en och samma webbplatssida och få en känsla av kontroll (2.1). Antalet länkar listade i

TaxiCallers header minskar genom att navigationen till informationsmaterialet flyttas till

supportcentrets startsida. Övrigt informationsmaterial har tagits bort, då detta material inspekterats

och bedömts av författaren som överflödigt när användarens strävan efter direkt belöning tagits i

åtanke (2.1). Hjälpverktyget i form av ”Contact us” är bevarat från webbplatskarta 1, men med

annan formulering. Hjälpverktyget är placerat i nivå med header, men detta är endast för att

33

komprimera illustrationsytan. För att inkludera kategorier samt det nuvarande tillgängliga

materialet har sju huvudkategorier listats där tre utgör guider och de övriga fyra är listade som

manualerna i webbplatskarta 1. Då guider och manualer avgränsar informationen har ett beslut

tagits av författaren för att bevara ”Knowledge base” som listar artiklar över användares vanliga

frågor. Med inspiration av Zendesks lösning av att ha ”tabbar” (skärmbild 3) för att navigera

mellan utvalda artiklar har denna lösning lagts in i webbplatskarta 5.

Kategorierna ”Bookings”, ”Reports” och ”VoIP” är huvudsakligen underkategorier till

information rörande admin panelen och dispatch konsolen. Så genom att använda sagd lösning kan

alla kategorier listas i webbplatskartan med hänsyn till områdenas omfattning. Slutligen har

användarnas möjlighet till navigation tagits i åtanke och kategoriområden kan nås med upp till tre

navigationsvägar.

34

4.4.3 Low-fidelity prototyp

Inledningsvis påbörjades pappersskisser för att jämföra strukturer för olika gränssnitt. Utifrån

pappersskisser fördes diskussion med supportpersonal för att ta beslut om en organiserad struktur.

Baserat på besluten togs en wireframe fram över supportcentrets startsida för att illustrera

presentationen av de utvalda kategorierna. Resultatet kan ses i skiss 1. Med hänsyn till önskemål

som framkom i intervjun (3.1.1) har även en mall för knowledge base tagits fram och illustrerats i

skiss 2. Objektens storlekar har anpassats i skiss 1 för att läsas i denna rapport.

Skiss 1 - Supportcenter Taxicaller

35

Utifrån webbplatskartan lades header objekten in först på skissen då placeringen av dessa objekt är

begränsad genom konvention.

Genreanalysen (4.2) visade att sökmotorn var ett högt prioriterat objekt och har i skiss 1 placerats

på en plats där användaren förväntas möta det. Med hjälp av uppmanande text placerad i

sökmotorn kommer sökfunktionen att konversera med användaren på ett naturligt sätt (2.2).

Eftersom resultat illustrerat i tabell 1 indikerade att en stor del av användare sökte efter kategorier

som berör de initiala inställningarna av systemet och tabell 2 indikerade att dessa höll ett högt

prioriteringsvärde bör dessa kategorier placeras väl synligt. Det baseras också på logiken att

användare som söker dessa kategorier oftast är nya, eftersom inställningarna inleder processen till

utforskning av andra funktioner. Därför har tre kategorier som berör de initiala inställningarna

prioriterats högst och placeras synligt för användaren i blocket under sökmotorn (2.5).

Då manualerna visats vara viktiga stöd för att besvara användarens frågor (figur 2) har objekten

och gets en hög prioritet listats med bemärkning och bild (2.3).

Med inspiration från Zendesks lösning har liknande navigationstabbar illustrerats i skiss 1. Det

resulterar i att kategorier med hög prioritet som vanligtvis faller in i underkategorier till guide och

manual har kunnat göras synliga på ett tydligt sätt.

Eftersom kunders begäran om funktioner i systemet, uppdateringar eller rapporteringar av buggar

är en viktig informationskälla för företaget så erbjuds kunden kontaktmöjlighet genom en knapp

längst ned på sidan. Då TaxiCallers webbplats även har en chattfunktion har denna funktion även

bevarats i skissen, med placering utifrån Upsales och Zendesks utformning.

36

Skiss 2 - Knowledge base artikelmall

Baserat på resultat från figur 1 och figur 2, har en mall tagits fram (skiss 2) för utformningen av

supportartiklar i knowledge basen. Majoriteten av stöd som gavs av supportpersonal var i form av

URL länkar. Baserat på detta anses stödet ha en hög prioritet och bör listas strax under

supportartikelns titel. Skärmbilder var också ett vanligt stöd och därav bör dessa i form av bilder

inkorporeras tillsammans med text som stegvis förklarar processen för användaren. Om

artikelförklaringen inte svarar på alla frågor så länkas också relevant område i manualen i slutet av

artikelmallen. Vid de få tillfällen som remote session är relevant kan funktionen bytas ut mot en

videoguide med placering likt bildrutorna. Genom skiss 2 illustreras alla stöd som användare gavs

genom chattverktyget i en struktur likt den illustrerad i skiss 1.

37

4.5 Validering

För att objektivt testa nuvarande supportimplementation och det nya designförslaget granskas de

tio chattloggarna som framtagits i avsnitt 3.1. I listan nedan har tio huvudfrågor eller påståenden

hämtats ur chattloggarna och listats tillsammans med kategoriområdet de tillhör. Frågorna

dokumenterades först när valideringen skulle genomföras för att inte påverka designprocessen.

Fråga 1 – ”Dispatch”

• Var kan man se en karta över alla fordon?

Fråga 2 – ”Tariffs/Taximeter”

• Taximeter inställningen visas inte

Fråga 3 – ”Bookings/Jobs”

• Var kan man finna tiden då ett jobb lades in?

Fråga 4 – ”Dispatch”

• Hur skapar man konton för företag i Dispatch Console?

Fråga 5 – ”Set up Account”

• Hur ändrar man datumformatet och längdenheten till miles istället för km?

Fråga 6 – ”Dispatch”

• Hur omorganiserar man fordonen i zon kön?

Fråga 7 – ”Set up Account”

• Hur delar man upp mitt företags verksamma tider?

Fråga 8 – ”Zones”

• Hur påverkar zoner hur samtal placeras till varje förare?

Fråga 9 – ”Tariffs/Taximeter”

• Hur sätter man upp zontariffer?

Fråga 10 – ”Pricing”

• Hur mycket måste man betala för tre fordon?

38

Valideringstestet undersöker antalet klick från startsida till rätt kategoriområde. För att navigera

till berörd artikel krävs ytterligare antal klick och en mer dokumenterad sökväg. Antalet klick

dokumenterar den optimala navigationsvägen till ett kategoriområde och tar inte hänsyn till

eventuell felnavigering. Valideringstestets resultat är illustrerade i tabell 3 och tabell 4.

Tabell 3 - Validering av Taxicallers nuvarande webbplatskarta

Fråga Antal

klick

Antal

vägar

Antal

kategoriområden

1 3 4 4

2 3 2 2

3 3 4 4

4 3 4 4

5 3 2 2

6 3 4 4

7 3 3 3

8 3 2 2

9 3 2 2

10 1 1 1

Totalt: 28 28 28

39

Tabell 4 - Validering av omstrukturerad webbplatskarta

Med den omstrukturerade webbplatskartan kan användaren nå kategoriområden med betydligt

färre klick än med den nuvarande webbplatskartan. Antalet sökvägar i TaxiCallers nuvarande

webbplatskarta är relativt många, men detta beror på den stora mängden av källområden. Den

stora mängd källområden gör att användaren kan finna relevant information på olika platser, men

med risk till förvirring i navigationen. Med den omstrukturerade webbplatskartan hålls

källområden begränsade till två platser, ett område som innefattar guider och manual och ett

område som innefattar knowledge base.

Fråga Antal

klick

Antal

vägar

Antal

kategoriområden

1 1 3 2

2 1 3 2

3 1 3 2

4 1 3 2

5 1 3 2

6 1 3 2

7 1 3 2

8 1 3 2

9 1 3 2

10 1 1 1

Totalt: 10 28 19

40

5. Slutsats För att besvara syftet togs två frågeställningar upp varav den ena var att ta reda på ”Hur ser det

nuvarande informationsbehovet ut hos användare som vänder sig till företagets supporttjänster?”.

Data från 4.2 visar att informationsbehovet huvudsakligen bestod av frågor som berör

användandet av admin och dispatch systemen. Med högst frekvens sökte användaren efter

information om bokningar och information om dispatch konsolen, följt av rapportgenerering och

initiala inställningar i admin panelen. En stor del av frågelösningarna innefattade manuallänkar

och guidelänkar, vilket indikerade att denna information redan fanns tillgänglig för kunderna.

Detta tyder på att det högst prioriterade informationsbehovet är att lägga upp informationen mer

lättillgänglig för kunderna. Informationsbehoven kan summeras som följande:

Användarna sökte främst information om hur uppsättning görs av inställningarna för användandet

av systemet. Således borde en introducerande funktion erbjudas i supportcentret.

Användarna sökte information i vad man på företaget anser vara verksamhetskritiskt. Det innebär

att många av dessa frågor bör besvaras i den snabbaste mån som möjligt. Så att erbjuda denna

information på ett tydligt och lättillgängligt sätt bör prioriteras.

Användarna möttes av stegvisförklaring som i majoriteten av fallen innehöll stöd i form av URL,

skärmbild, manuallänk och remote session. Således bör informationen som användaren möter i

hjälpartiklar använda stöd i form av länk och bild, med eventuell hänvisning till manual.

Den andra frågeställningen var följande: ”hur kan ett grafiskt användargränssnitt för en webbplats

supportcenter se ut för att besvara det framtagna informationsbehovet? ”

Rekommendationen utifrån denna uppsats är ett grafiskt användargränssnitt som baseras på

webbplatskarta 5 med mer utformade riktlinjer som illustreras i skiss 1 och 2.

41

6. Värdering och diskussion

I detta avsnitt beskrivs författarens egna kritiska värderingar av arbetet som helhet där diskussion

förs om alternativa tillvägagångssätt och lösningar. Avsnittet avslutas med rekommendationer för

vidare studier.

6.1 Teoretiskt ramverk

Litteraturanvändningen syftade att ge en begriplig inblick i hur teknisk information bör presenteras

och evalueras. En stor del av litteraturen som gåtts igenom har varit för detaljspecifik och berört

mer tekniska områden som föll utanför författarens kunskapsområde, vilket gjort att teori bland

annat hämtats från diverse webbsidor. På grund av detta är inte alla källor granskade i den mån

som hade önskats. Även avsaknaden av liknande studier gjorde att teorin byggts upp från början

efter författarens bästa förmåga.

De teorier som har valts ut för detta arbete i bland annat avsnitt 2.1, 2.2 och 2.6 har även haft ett

syfte att beskriva frekventa användarbeteenden för att väga upp för avsaknaden av användarstudier

i denna rapport. Dessa teorier har således influerat utformningsbeslut för gränssnittets

användaranpassning.

Trots utmaningen har ansträngning gjorts för att inte utgå från en ensam ståndpunkt i varje

teorikapitel. Detta har gjorts genom att sträva efter att utnyttja mer än en källa i teorikapitlen. för

att skapa en mer nyanserad bild av teorin som presenteras och ligger till grund för rapporten. Det

har ej varit möjligt i alla teorikapitel och med mer tid hade större försök gjorts för att hitta fler

referenser.

6.2 Metod

Metoden för denna studie bestod av fem huvuddelar: förstudie, sammanställning av användardata,

genreanalys, designprocess och validering. Denna metod är inte byggd på samma iterationsprocess

som vanligtvis förekommer vid forskning genom design, vilket berodde på att relevant data som

designprocessen bygger på fanns dokumenterad redan innan. Då metoden inte följer den generella

strukturen har utformningen av metoden strävat att ha en så deskriptiv utformning som möjligt för

att vidare studier skall kunna utnyttja metoden.

Metoden bör byggas ut med vidare iterationsprocess där målgruppen involveras för tester. Då

målgruppen i fråga är verksamma företag har de inte tillfrågats att medverka i användarstudier

med respekt för bristen av tid. Målgruppen i fråga har också en stor variation gällande

kunskapsbakgrund där stora företag har avdelningar avsedda att sköta installation av mjukvara,

medan mindre företag med bristande förkunskap skall sköta samma process. Detta skapar en stor

spridning gällande användarens förutsättningar och det är även viktigt att tillägga att alla

42

användare är bekanta med terminologi relevant för taxiindustrin. Således har det varit svårt att

finna lämpliga användare som kan avspegla målgruppen. Detta gör att resultatet saknar en

validering med användare som mer tydligt bevisar att informationsbehoven har lösts.

6.3 Förstudier

Förstudien består av en intervju samt en dokumentation av företagets nuvarande webbplatslösning.

Gällande intervjun bör man ta hänsyn till att den intervjuade supportchefen inte själv hanterar

kundkontakt i vidare stor mån och har endast haft tjänsten i mindre än ett år. Trots detta är

supportchefens uppgift att översiktligt dokumentera och förbättra supporthanteringen överlag och

således ansågs ha bäst överblick i hur supporthanteringen ser ut på företaget. Men för ytterligare

insikt bör fler anställda ha intervjuats.

Dokumentationen av företagets nuvarande webbplatslösning har gjorts utefter författarens egen

bedömning som delvis baserats på funnen teori. Då utformningen av webbplatskartor kan variera

stort och inte har en regelrätt utformning, så anses dokumentationen vara välgrundad.

6.4 Sammanställning av användardata och genreanalys

Då teorikapitlen inte ämnat att dokumentera hur dataanalys bör genomföras har slutsatser från

användardata tagits utifrån författarens bedömning. Eftersom data utgjordes av chattloggar formas

författarens uppfattning endast av det dokumenterade innehållet i en konversation som tidigare

gjorts. Detta resulterar i att förståelsen för informationsbehovet är något begränsad eftersom

författaren inte haft möjlighet att direkt fråga användare. Eftersom data berör TaxiCallers system

och dess funktioner blir uppsatsens trovärdighet hög ur TaxiCallers perspektiv. Således blir

potentialen för uppsatsens kunskapsbidrag aningen lägre till samhället i stort.

I genreanalysen görs däremot en utförlig undersökning med förklaring av författarens

genomförande. Detta påverkar i sin tur kunskapsbidraget för interna och externa intressenter som

kan söka att genomföra liknande analyser. De webbplatser som har valts att analyseras är till

författarens kännedom inte användartestade. Urvalet av webbplatser har gjorts baserat på

kritikerrosade blogartiklar av aktörer i industrin samt att Zendesk är ett företag som utvecklar

mjukvara för hantering av kundsupport.

6.5 Designprocess

Designprocessen i detta arbete har fokuserat på att svara på de behov som framtagits ur

sammanställningen av användardata, vilket har gjort att processen inte kan itereras i ytterligare

steg. Om iteration skall genomföras hade den krävt involvering av målgruppen. Då

designprocessen utförts på plats hos företaget har också supportpersonal haft synpunkter och

kunnat föra diskussion om designens utformning. Således har ingen särskild dokumentation förts

över dessa diskussioner och är något som kan ses som en saknad dokumentation av processen.

43

6.6 Validering

Valideringsmetoden valdes för detta arbete utifrån de förutsättningar som funnits gällande tidsram

och avsaknad möjlighet att utföra tester med målgruppen. Valideringen tar fram ett rent teoretiskt

resultat där ett felfritt scenario iscensätts och är således inte av största trovärdighet.

6.7 Sammanfattning

Sammanfattningsvis kan studien anses som lyckad i den mån forskningsfrågorna besvaras. Hur väl

studien levererar ett kunskapsbidrag beror på hur reflektionen görs. Uppsatsens process över lag,

att omstrukturera innehåll på en webbplats, kan ses som ett allmänt kunskapsbidrag då processen

utgör ett exempel på hur en sådan uppgift kan utföras. På grund av att mycket information

exkluderats från bilaga 2 och bilaga 3, blir analysprocessen inte lika transparent och gör att

trovärdigheten minskas något.

Resultatet i stort är baserat på en analys av information som funnits tillgänglig genom chattloggar

och användning av befintlig teori. Det kan tilläggas att om ytterligare statistik funnits kring

användarbeteende på TaxiCallers webbplats och användartestning hade genomförts, så hade

resultatet kunnat ses som än mer pålitligt.

Slutligen är det värt att poängtera att skapandet av en supportsida endast kan lösa de problem som

kunderna stöter på genom användning av programvaran om de väljer att navigera in på

supportcentret. I det optimala fallet skall hjälpen tillgå genom programvaran i sig självt, med

inbyggda guider eller förinställningar som användaren kan dra nytta av för att förstå programmet

enklare. Man kan säga att denna lösning endast behandlar resultatet av problemen men inte källan

till problemen.

6.8 Rekommendation för vidare studier

Vid eventuella vidare studier rekommenderas att omstruktureringen av webbplatsen

implementeras för att dokumentera och utvärdera slutresultatet av designen. Således kan en mer

pålitlig validering göras baserat på användare. För ett sådant genomförande krävs däremot utökade

resurser och en större tidsram. Det kan också vara av intresse att undersöka hur omstrukturering av

innehåll kan göras på andra plattformar som exempelvis i en mobilapp och jämföra dessa

processer.

44

Litteraturförteckning

Arvola, M. (2014). Interaktionsdesign och UX : om att skapa en god användarupplevelse. Lund: Studentlitteratur.

Christensson, P. (2012). Footer Definition. https://techterms.com/definition/footer [2019-05-18]

Christensson, P. (2012). Header Definition. https://techterms.com/definition/header [2019-05-18]

Czegel, Barbara. Technical Support on the Web: Designing and Managing an Effective E-Support

Site. John Wiley & Sons.

Fadeyev, D. (2012). User experience. practical techniques. Freiburg, Germany: Smashing Media GmbH.

Jenkins, S. (2009). Web design all-in-one for dummies. John Wiley & Sons.

Lior, L. (2013). Writing for interaction : crafting the information experience for web and software

apps. Waltham, MA: Morgan Kaufmann.

McKay, Everett N. UI is Communication: How to Design Intuitive, User-Centered Interfaces by

Focusing on Effective Communication. Morgan Kaufmann Publishers.

Preece, J., Rogers, Y. & Sharp, H. (2015). Interaction design : beyond human-computer

interaction. Chichester, West Sussex: John Wiley & Sons Ltd.

Resmini, A. (2014). Reframing information architecture. Cham: Springer.

Karafillis, A. (2014) Navigation & Interaction, Vol. 2. Smashing Magazine GmbH.

Salesforce. (2017) What is CRM? https://www.salesforce.com/blog/2013/01/what-is-crm-your-

business-nerve-center.html [2019-04-16]

Slickplan. (2018) Site Mapping: A Comprehensive Guide. https://slickplan.com/blog/site-

mapping-a-comprehensive-guide [2019-05-03]

TaxiCaller. (u.å.) Om oss. https://www.taxicaller.com/sv/om-oss [2019-03-17]

Technopedia. (u.å) E-Support. https://www.techopedia.com/definition/14041/e-support [2019-04-

17]

45

Bilaga 1 – Intervjuguide förstudie

Semistrukturerad intervju – TaxiCaller support

Inledning

Kort presentation om vad mitt exjobb kommer fokusera på.

Är det tillåtet att jag spelar in ljud för intervjun?

Bakgrund

- Hur arbetar ni på support här på TaxiCaller?

- Hur länge har du själv jobbat på support på TaxiCaller?

o (Om länge) Har arbetet på support förändrats över tid?

Omfattning

- Hur ser dagens inkommande tickets generellt ut?

- Hur mycket hanterar er supportpersonal dagligen/veckovis?

- Ni har två olika supporthanteringar, 1st linesupport och 2nd linesupport. Hur skiljer sig dessa?

- Är de lika mycket belastning i båda supporthanteringarna?

Ticket typ

- Får ni ofta in simpla problem som enkelt kan lösas genom att läsa er online-manual? Beskriv

hur dessa kan se ut.

- Hur tar ni emot era tickets? (Samtal, mejl etc.)

o Vilket typ av mottagning föredrar du och varför?

- Har ni dokumentation på era lösta tickets och hur används dessa?

Kunden

- Beskriv generellt era kunder som kontaktar supporten.

- Får ni respons på kundernas supportupplevelse? Och hur ser dessa ut?

- Finns det önskemål från kunder om förbättrade guider? Och hur ser dessa ut?

Egna tankar

- Har du några tankar kring lösningar som skulle kunna underlätta arbetsbördan hos supporten?

- Har du några idéer om hur ett hjälpcenter kan underlätta arbetsbördan hos supporten?

46

Bilaga 2 – Användardata

1. 29-04-2019

- Start 03:31:(52) End: 04:39:(06) - ” Reports/Replay” – ”How do you check earnings and total of jobs?” - Issue was explained.

2. 26-04-2019

- Start 10:18:(33) End: 11:39:(50) - ”Tariffs/Taximeter” – ”How do you change the rates between busses and cars?” - Remote session was used.

3. 26-04-2019

- Start 02:20:(26) End: 02:57:(23) - ”Billing” – ”How do you set up monthly billing for customers?” - URL and manual link were provided.

4. 25-04-2019

- Start 16:28:(43) End: 16:37:(42) - “Online Booking” – “What is required to start Online Booking?” - Issue was explained.

5. 25-04-2019

- Start 13:47:(20) End: 14:20:(34) - ”Dispatch” – “How can you indicate cash or account payment in dispatch console?” - URL and screenshot were provided.

6. 25-04-2019

- Start 11:20:(28) End: 12:09:(28) - ”Set up Account” – “What legal documents are required to start your company?” - Issue was explained.

7. 24-04-2019 - Start 18:26:(49) End: 19:13:(42) - “Receipts” – “How do you request a signature on the receipts?” - Issue was explained.

8. 20-04-2019

- Start 22:24:(48) End 23:24:(35) - “Tariffs/Taximeter” – “How does the different criteria’s work for setting up a tariff? How

do they work together?” - Remote session was used and manual link provided.

9. 20-04-2019

- Start 01:47:(02) End 01:53:(50) - “Reports/Replay” – “How can you check previous months weekly job count?” - URL was provided.

10. 19-04-2019

- Start 03:08:(44) End 03:29:(19) - “Receipts” – “How do you generate receipt for cash paying customers?”

47

- Screenshot was provided.

11. 17-04-2019

- Start 11:08:(11) End 11:23:(18) - “Set up Account” – “How do you update the account information?” (e.g. email address) - Issue was explained.

12. 15-04-2019

- Start 18:28:(37) End 18:53:(36) - “VoIP” – “How do you populate the info when a call comes in?” - Manual link was provided.

13. 15-04-2019

- Start 06:39:(27) End 07:07:(32) - “Set up Users/Vehicles” – “How do set a driver to only receive street jobs?” - URL and screenshot was provided.

14. 10-04-2019

- Start 16:19:(36) End 17:29:(16) - “Reports/Replay” – “How can you download account reports?” - URL and screenshot was provided.

15. 10-04-2019

- Start 13:52:(19) End 13:55:(10) - “Messeges” – “Where can you change the massages from dispatchers to drivers?”

(Automated message when logging in) - Issue was explained.

16. 10-04-2019 - Start 12:41:(37) End 14:23:(35) - “VoIP” – “What do you need in order to use Caller ID?” - Issue was explained.

17. 09-04-2019

- Start 12:37:(03) End 12:46:(30) - “Zones” – “How do you set the zones for assignment?” - URL and manual link was provided.

18. 08-04-2019

- Start 13:16:(55) End 14:13:(05) - “Tariffs/Taximeter” – “How do you set up a tariff based on specific numbers of

passengers?” - Remote session was used.

19. 08-04-2019

- Start 01:39:(35) End 01:44:(39) - “Bookings/Jobs” – “How do you look up who created a job?” - Issue was explained.

20. 06-04-2019

- Start 16:22:(31) End 16:36:(59)

48

- “Bookings/Jobs” – “How do you hide pre-booked jobs older than 24 hours?” - URL was provided.

21. 06-04-2019

- Start 00:03:(31) End 00:06:(59) - “Set up Users/Vehicles” – “Can you add another Admin user?” - Issue was explained.

22. 05-04-2019

- Start 14:21:(04) End 14:22:(42) - “Set up Account” – “How do you set your service area?” - URL was provided.

23. 31-03-2019

- Start 05:52:(39) End 06:22:(01) - “POI” – “How do you load streets that are not on google maps?” - Manual link was provided.

24. 31-03-2019

- Start 04:01:(02) End 04:46:(06) - “Set up Account” – “How do you change system units from km to miles?” - URL and screenshot was provided.

25. 28-03-2019

- Start 14:40:(34) End: 14:56:(42) - ”Driver app” – ”Why does the pickup location not show when the driver sets himself to

busy?” - Screenshot was provided.

26. 27-03-2019

- Start 12:13:(56) End: 12:36:(00) - “VoIP” – “How do you add a phone number so you get calls in to the dispatch?” - Issue was explained.

27. 26-03-2019

- Start 10:27:(13) End: 10:35:(09) - ”Tariffs/Taximeter” – ”How do you enable in app taximeter?” - URL was provided.

28. 26-03-2019

- Start 06:46 End: 09:22 - ”Dispatch” – ”The right side of the dispatch console disappeared, how do you get it

back?” - Issue was explained.

29. 24-03-2019

- Start 17:54:(22) End: 17:56:(58) - ”Messages” – “How do you send emails to customers?” - Manual link was provided.

49

30. 23-03-2019

- Start 17:31:(08) End: 18:14:(24) - “Online Booking” – “How do you use the Online Booking?” - Manual link was provided.

31. 21-03-2019

- Start 12:46:(16) End: 12:53:(52) - ”Zones” – ”Recently added zones not appearing” - Issue was explained.

32. 21-03-2019

- Start 02:46:(56) End: 03:55:(25) - ”Tariffs/Taximeter” – ”How do you configure VAT?” (adding VAT in fare calculation) - Screenshots were provided

33. 20-03-2019 - Start 03:02:(25) End: 03:04:(43) - “Reports/Replay” – “How do you go back to a particular date to view where the cars

were?” - Manual link was provided.

34. 19-03-2019

- Start 08:39:(48) End: 11:17:(45) - “Dispatch” – “What does the exclamation mark next to the driver number mean?” (in

Dispatch) - Issue was explained.

35. 18-03-2019

- Start 15:49:(32) End: 17:52:(46) - “Online Booking” – “My company does not appear on the passenger app” - URL was provided

36. 18-03-2019

- Start 12:20:(07) End: 12:27:(10) - “VoIP” – “What VoIP service is TaxiCaller compatible with?” - Issue was explained.

37. 18-03-2019

- Start 07:32:(40) End: 07:35:(47) - ”Navigation (Where can I find?)” – “Where can you find the passenger app manual?” - Manual link was provided.

38. 16-03-2019

- Start 16:34:(47) End: 16:45:(12) - “Dispatch” – “How do you reorder zone queues?” - URL was provided.

39. 16-03-2019

- Start 01:39:(27) End: 01:47:(39) - ”Dispatch” – ”How do you change drivers queue positions?” - URL was provided.

50

40. 14-03-2019 - Start 17:03:(17) End: 17:36:(13) - “Dispatch” – “How do I edit zone queue?” - URL and screenshot was provided.

41. 13-03-2019

- Start 01:58:(56) End: 02:14:(14) - ”Set up Account” – ”Where can you change the display name?” - URL was provided.

42. 13-03-2019

- Start 01:28:(40) End: 01:43:(02) - “Dispatch” – “How do I edit zone queue?” - Issue was explained.

43. 12-03-2019

- Start 17:17:(10) End: 17:51:(37) - “Dispatch” – “How do I edit zone queue?” - URL and screenshot was provided.

44. 12-03-2019

- Start 11:11:(35) End: 11:26:(31) - ”Bookings/Jobs” – ”Can the system do pre-bookings?” - Screenshot was provided.

45. 10-03-2019

- Start 14:36:(54) End: 15:08:(44) - ”Online Booking” – “How often is the company list updated on the TC passenger app? - URL and manual link was provided.

46. 08-03-2019

- Start 09:26:(36) End: 09:38:(58) - ”Bookings/Jobs” – ”How do you create repeated bookings?” - Issue was explained.

47. 08-03-2019

- Start 01:26:(36) End: 01:37:(37) - ”Zones”- “How does the system assign jobs depending on zones?” - Manual link was provided.

48. 07-03-2019

- Start 12:02:(02) End 12:13:(11) - “Set up Users/Vehicles” – “How can you add a driver from the dispatch console?” - Issue was explained.

49. 04-03-2019

- Start 12:03:(03) End 12:18:(13) - “VoIP” – “Which VoIP provider do TaxiCaller support?” - Issue was explained.

51

50. 04-03-2019

- Start 10:21:(29) End 10:27:(45) - “Bookings/Jobs” – “How do you find details on cancelled jobs?” - Issue was explained.

51. 04-03-2019

- Start 10:19:(14) End 10:48:(18) - “Messages” – “How do you install the Envelope app on your phone?” - URL and screenshot was provided.

52. 01-03-2019

- Start 14:16:(08) End 15:14:(20) - “Set up Users/Vehicles” – “How do you delete a vehicle?” - Issue was explained.

53. 28-02-2019

- Start 01:42:(28) End 02:00:(13) - “Reports/Replay” – “How to generate/print weekly, monthly, and yearly income report?” - Manual link and screen shot was provided.

54. 26-02-2019

- Start 12:07:(48) End: 12:14:(59) - “Bookings/Jobs” – “How do you see future jobs that don’t appear on the main dispatch

screen?” - Screenshot was provided.

55. 25-02-2019

- Start 12:54:(37) End: 13:10:(18) - “Online Booking” – “How do you disable Online Booking temporarily?” - Issue was explained.

56. 21-02-2019

- Start 11:17 End 11:41 - “VoIP” – “What does ‘clean jobs’, ‘reset job counts’ and ‘force transfer’ mean? - Issue was explained.

57. 20-02-2019

- Start 10:46:(52) End: 13:17:(37) - “Bookings/Jobs” – “How do you view when the job was created?” - Issue was explained.

58. 20-02-2019

- Start 05:38 End: 06:44 - “Bookings/Jobs” – “What does T-assign time mean?” - Issue was explained.

59. 18-02-2019

- Start 15:26:(10) End: 16:56:(28) - “Online Booking” – “Does our company show up in the app when asked to select a

company?”

52

- Issue was explained.

60. 15-02-2019

- Start 12:18:(43) End: 12:36:(58) - “Tariffs/Taximeter” – “How do you change the currency? (in this case to US dollars?) - URL and screenshot was provided.

61. 15-02-2019

- Start 01:04:(35) End: 01:46:(11) - “Reports/Replay” – “How do you export your booking data?” - URL and manual link was provided.

62. 14-02-2019

- Start 07:08 End: 07:15 - “Navigation (Where can I find?)” – “Where can you find the manual for caller ID?” - Manual pdf was provided.

63. 13-02-2019

- Start 09:33:(28) End: 11:45:(48) - “Receipts” – “How do you view receipts signed from a customer?” - Manual link and screenshot was provided.

64. 11-02-2019

- Start 09:44:(24) End: 10:36:(16) - “Bookings/Jobs” – “Is there an option for seeing queued jobs in the driver app and how

does the dispatcher queue jobs for a driver? All in all, dispatch features. - Manual link was provided.

65. 10-02-2019

- Start 23:40:(08) End: 00:59:(41) - “Bookings/Jobs” – “Can you make online bookings, repeated bookings? And how are

these enabled?” - Screenshot and URL were provided.

66. 10-02-2019

- Start 12:07:(14) End: 12:17:(08) - “Driver app” – “How do you turn off the incoming job notifications when a driver is

working on a current job?” - URL was provided.

67. 09-02-2019

- Start 01:53:(32) End: 02:09:(43) - “Bookings/Jobs” – “How do you view the declined jobs by a specific driver?” - URL was provided.

68. 05-02-2019

- Start 03:02:(29) End: 03:37:(12) - “Reports/Replay” – “How do you view the total vehicle mileage for a year?” - Issue was explained.

53

69. 03-02-2019

- Start 05:22:(25) End: 05:27:(07) - “IVR” – “How do you use the IVR feature?” - Manual link was provided.

70. 02-02-2019

- Start 23:44:(20) End: 00:32:(46) - “Set up Account” – “How do you begin testing the system?” - URL was provided.

71. 30-01-2019

- Start 17:16:(11) End: 18:56:(06) - “Bookings/Jobs” – “How do you mass delete open jobs?”

Issue was explained.

72. 30-01-2019

- Start 15:45:(25) End: 16:05:(25) - “Set up Users/Vehicles” – “What are permits and tags?” - Manual links were provided.

73. 29-01-2019

- Start 06:23:(40) End: 06:28:(45) - “Reports/Replay” – “How do you view the mileages driven by each driver?”

Issue was explained.

74. 21-01-2019

- Start 11:41 End 11:42 - “VoIP” – “How can you make the customers numbers info auto populate?”

Issue was explained.

75. 21-01-2019

- Start 12:56:(27) End: 13:49:(02) - “Set up Account” – “How do you set the system to assign jobs?” - Issue was explained.

76. 21-01-2019

- Start 04:55:(12) End: 05:56:(17) - “Set up Users/Vehicles” – “How do you add pictures of your drivers?” - URL was provided.

77. 10-01-2019

- Start 12:33:(42) End: 13:32:(29) - “Dispatch” – “Why does the vehicles appear green on the map when you have set colours

for each vehicle?” Issue was explained.

78. 09-01-2019

- Start 06:13:(17) End: 07:07:(53) - “Set up Users/Vehicles – “How do you unsuspend a driver?” - Screenshots were provided.

54

79. 04-01-2019

- Start 17:11:(00) End: 17:19:(45) - “Bookings/Jobs” – “How do you set repeated bookings?” - Issue was explained.

80. 01-01-2019

- Start 09:59:(56) End 11:12:(26) - “Reports/Replay” – “Where can you see the total drives?” - URL, manual link and screenshots were provided.

81. 30-12-2018

- Start 21:23:(48) End: 22:53:(56) - “Tariffs/Taximeter” – “How do you set up and enable tariffs?” - URL was provided

82. 28-12-2018

- Start 01:04:(35) End: 01:46:(11) - “Dispatch” – “How do you send out jobs from dispatch console to drivers?” - Manual link and URL was provided.

83. 19-12-2018

- Start 12:02:(29) End: 13:01:(26) - “Reports/Replay” – “How do you view a drivers GPS information on the replay feature?” - Manual link was provided.

84. 18-12-2018

- Start 13:15:(15) End: 14:42:(26) - “Set up Account” – “Why does the non-settled payment method appear when drivers

deliver a trip?” - URL was provided.

85. 06-12-2018

- Start 15:58:(28) End: 16:25:(27) - “Bookings/Jobs” – “How do you view yesterday’s trip information?” - Issue was explained.

86. 06-12-2018

- Start 01:18:(54) End: 02:25:(09) - “Tariffs/Taximeter” – “How do you set up tariffs?” - Remote session was used and screenshot was provided.

87. 05-12-2018

- Start 17:28:(19) End: 17:37:(54) - “Driver app” – “How do you hide incoming jobs in zones?” - Issue was explained.

88. 30-11-2018

- Start 07:33 End: 07:53 - “Set up Acount” – “How do you connect Stripe to your TaxiCaller account?” - URL and screenshot was provided.

55

89. 18-11-2018

- Start 11:38:(37) End: 11:40:(50) - “Online Booking” – “Why is my company not showing in the booking area?” - Issue was explained.

90. 07-11-2018

- Start 00:06:(58) End: 00:22:(20) - “VoIP” – “How do you download the softphone?” - Screenshots were provided.

56

Bilaga 3 – Valideringsurval Användardata

1. 20-04-2019 - Start 04:14:(03) End: 04:31:(36) - “Dispatch” – “Where do you see the map of all your vehicles?” - URL was provided.

2. 13-04-2019

- Start 16:53:(21) End: 17:16:(15) - “Tariffs/Taximeter” – “The taximeter setup does not show up” - Remote session was used and URL was provided.

3. 10-04-2019

- Start 12:54:(34) End: 13:07:(27) - “Bookings/Jobs” – “Where can you find the time the job was filled?”

- Issue was explained.

4. 03-04-2019 - Start 10:05:(46) End: 10:23:(34) - “Dispatch” – “How do you create accounts for companies in Dispatch Console?” - Screenshot was provided.

5. 22-03-2019

- Start 09:53:(47) End: 09:55:(51) - “Set up Account” – “How do change date format and the distance in miles instead of km?” - URL was provided.

6. 13-03-2019

- Start 12:17:(01) End: 12:36:(02) - “Dispatch” – “How do you rearrange the vehicles in zone queue”?

- URL and screenshot were provided.

7. 16-02-2019 - Start 02:01:(59) End: 02:10:(33) - “Set up Account” – “How do you split up operating hours?” - Issue was explained.

8. 13-01-2019

- Start 10:28:(02) End: 10:34:(56) - “Zones” – “How does zones affect how calls are placed to each driver?” - URLs and manual links were provided.

9. 12-11-2018

- Start 19:04:(19) End: 20:08:(25) - “Tariffs/Taximeter” – “How do you set up zone tariffs?” - Remote session was used, URL and manual links were provided.

10. 07-11-2018

- Start 11:31 End: 11:43

- “Pricing” – “How much do you need to pay for three vehicles?” - URL was provided.