Department of Science and Technology Institutionen för teknik och naturvetenskap
Linköping University Linköpings universitet
g n i p ö k r r o N 4 7 1 0 6 n e d e w S , g n i p ö k r r o N 4 7 1 0 6 -E S
LIU-ITN-TEK-G-19/065--SE
En digital manual: Att
visualisera och organisera
information genom ett
hjälpcenter
Mami Inada Boberg
LIU-ITN-TEK-G-19/065--SE
En digital manual: Att
visualisera och organisera
information genom ett
hjälpcenter
Examensarbete utfört i Grafisk design och kommunikation
vid Tekniska högskolan vid
Linköpings universitet
Mami Inada Boberg
Handledare Jonas Löwgren
Examinator Camilla Forsell
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ör
ickekommersiell forskning och för undervisning. Överföring av upphovsrätten
vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av
dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,
säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ
art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i
den omfattning som god sed kräver vid användning av dokumentet på ovan
beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan
form eller i sådant sammanhang som är kränkande för upphovsmannens litterära
eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se
förlagets hemsida
http://www.ep.liu.se/
Copyright
The publishers will keep this document online on the Internet - or its possible
replacement - for a considerable time from the date of publication barring
exceptional circumstances.
The online availability of the document implies a permanent permission for
anyone to read, to download, to print out single copies for your own use and to
use it unchanged for any non-commercial research and educational purpose.
Subsequent transfers of copyright cannot revoke this permission. All other uses
of the document are conditional on the consent of the copyright owner. The
publisher has taken technical and administrative measures to assure authenticity,
security and accessibility.
According to intellectual property law the author has the right to be
mentioned when his/her work is accessed as described above and to be protected
against infringement.
For additional information about the Linköping University Electronic Press
and its procedures for publication and for assurance of document integrity,
please refer to its WWW home page:
http://www.ep.liu.se/
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
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
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
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
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.
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
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.
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.
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
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
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
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
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
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.
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”
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.
