Ett systemutvecklingsprojekt gällande datoriserad telefonkommunikation CHRISTOFER HJALMARSSON

Transkript

1 Ett systemutvecklingsprojekt gällande datoriserad telefonkommunikation CHRISTOFER HJALMARSSON Examensarbete Stockholm, Sverige 2010

2 Ett systemutvecklingsprojekt gällande datoriserad telefonkommunikation CHRISTOFER HJALMARSSON Examensarbete i människa-datorinteraktion om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2010 Handledare på CSC var Anders Green Examinator var Yngve Sundblad TRITA-CSC-E 2010:044 ISRN-KTH/CSC/E--10/044--SE ISSN Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

3 Ett systemutvecklingsprojekt gällande datoriserad telefonkommunikation Sammanfattning Denna studie gjordes på uppdrag av GE Capital. Syftet var att göra ett utvecklingsprojekt där användarcentrerad systemutveckling är i fokus. Systemet som utvecklades är ett telefonkommunikationsverktyg där datorn ska hjälpa till att styra vilka kunder som ska ringas. Projektets mål var att utveckla ett nytt system som ökar effektiviteten för dagens användare. Metoder som användes under arbetets gång är workshops, användbarhetstest, observationer och intervjuer. Dessa metoder itererades för att stegvis klara av att utveckla det nya systemet, Solidus. Solidus är idag i drift för att hjälpa agenterna med telefonkommunikationen. Rapporten beskriver utvecklingsprojektets tillvägagångssätt. System development project in computerized telephone communication Abstract This study is about a system development project commissioned by GE Capital where user-centered design should be in focus. The system that s being developed is a telephone communication tool where the computer should help to setup the clients that are going to be called. The project goal is to develop a new system which has higher effectively for today s users. Methods that have been used in this project are workshops, usability tests, observations and interviews. These methods were iterated to be able to develop the new system, Solidus. Solidus is up and running today to help the agents with telephone communication. This report describes how this project was setup. 2

4 Innehållsförteckning 1 Introduktion Målgrupp Syfte & Mål Problemformulering Avgränsning Bakgrund GE Capital GE Capital Nordic Kunder Agenter Inkasso Dialer Ett telefonverktyg Dialer GE Capital Dialer GE Capital Nordic Teori & metod Användbarhet Användarcentrerad systemdesign Definition 1 - Norman Definition 2 Gould & Lewis Definition 3 ISO Definition G&Gs principer Intervjuer Prototyper Workshops Observationer Användbarhetstester Verbala protokoll Genomförande Metodval Workshop Utförande Observation och kontextuell intervju

5 4.3.1 Utförande Användbarhetstest Utförande Prototyp Resultat Den första iterationen Workshop Observation & Kontextuell intervju Sammanfattning Den andra iterationen Workshop Prototyp - Skärmpoppning Användbarhetstest Sammanfattning Den tredje iterationen Workshop Användbarhetstest Sammanfattning Prototyp - Slutlig Reflektion Diskussion Slutsats Litteraturförteckning Litteratur Intervju

6 1 Introduktion I den teknikrika värld vi idag lever finns alltid behov av nya datorsystem. Denna studie är ett utvecklingsprojekt vid GE Capital Nordics inkassoavdelning. Syftet är att utveckla ett nytt system som ger användare mer tid till kunden i stället för att använda dyrbar arbetstid till exempelvis datahämtning. När ett nytt system utvecklas i tanke på att passa användarna bör användarna göras delaktiga under hela utvecklingsprocessen. Reell delaktighet och medinflytande hos användarna ökar möjligheten att hela systemet kommer att nyttjas. Att använda sig av användarcentrerade metoder under hela processen ger bättre möjligheter att utveckla ett system som kommer att passa både GE Capital och dess agenter. 1.1 Målgrupp Målgruppen för studien är GE Capital Nordics agenter, d.v.s. anställda vid företaget vars huvudsakliga arbetsuppgift är att driva in pengar till företaget. Alla agenter är stationerade på kontoret i Solna men arbetar mot olika nordiska länder. Sverige har tre agenter medan Norge, Finland och Danmark har två agenter per land. Målgruppen kommer att innefatta alla nio agenter eftersom de utför liknande arbetsuppgifter och de kommer alla att vara brukare av det nya system som införs. 1.2 Syfte & Mål Målet med studien är att utveckla ett användarcentrerat system som effektiviserar agenternas dagliga telefonkontakt med kunderna. Syftet är att uppnå så bra effektivitet som möjligt för att ge kunden mer tid med agenten i stället för att agentens arbetstid ska användas till sidoarbeten som datorerna rutinartat kan utföra. Med ökad effektivitet menas att agenten ges möjlighet att ringa fler kunder per dag (ökad frekvens) samtidigt som systemet ska underlätta för agenten att komma i kontakt med kunderna (ökad precision). 1.3 Problemformulering Studien behandlar svårigheter kring användarcentrerad systemutveckling och viktiga frågor som kommer utredas är: 1) På vilket sätt ska användarna vara med i utvecklingsarbetet? 2) Hur upplever användarna sin delaktighet under utvecklingsarbetet? 3) Hur upplever användarna det nya systemet? 1.4 Avgränsning Fokus kommer att vara användarprocessen där användare av det nya systemet ska göras delaktiga i utformningen av systemet, d.v.s. tankar och idéer om hur systemet ska vara uppbyggt och utformat. Studien innefattar endast till mindre del systemets design (gränssnitt) eftersom ett utomstående företag kommer att sköta programmeringen. Designförslag kommer ändå finnas med för rekommendationer till ändringar men dessa förslag kommer endast vara på de mest svåranvända delarna. 1

7 2 Bakgrund 2.1 GE Capital GE Capital är en av världens största aktörer inom finans- och leasingbranschen och erbjuder olika typer av finansieringslösningar åt företag. Bakom företaget står GE-koncernen vilket bidrar till en stabil finansiell grund. GE Capital är en av få finansieringsföretag i världen med kreditranking AA+ hos ledande branschinstitut och det medför högt förtroende hos kunderna. Företaget har stor bredd när det gäller finansiering, fordon, entreprenad-, skogs- och tillverkningsmaskiner till flygplan och i vissa fall hela lagerverksamheter GE Capital Nordic GE Capital Nordic är beteckningen för den nordiska delen av företaget som innefattar den svenska, finska, norska och danska marknaden Kunder GE Capital Nordics kunder är både företag och privatpersoner, alla som behöver hjälp med finansiering kan ansöka om lån hos GE Capital och därigenom finansiera sina köp. Företagen är dock GE Capitals vanligaste kunder. Företagets storlek har mindre betydelse men om företagen är tillräckligt stora har de oftast ett eget finansieringsbolag och behöver på så vis inte samma stöd. När en kund beslutat att ta finansiell hjälp köper GE produkten av en återförsäljare. Därefter upprättas ett hyres- eller leasingavtal mellan kunden och GE. När leasingperioden går ut väljer kunden om den vill lämna tillbaka, ersätta eller köpa ut varan. De kunder som i studien kommer att benämnas kund är enbart de kunder som ligger efter med betalning, d.v.s. de har alla en obetald skuld till GE. Varför kunden ligger efter i betalning saknar betydelse för denna studie, det gemensamma för inblandade kunder är att de inte betalat sin avgift i tid och därmed har en förfallen faktura Agenter En agent är en anställd på företaget GE Capital vars dagliga arbetsuppgifter består av telefonsamtal med kunder i syfte att påminna dem om deras förfallna fakturor. I början av varje månad får agenten en lista på kunder som ska ringas eftersom de har förfallna fakturor. Agenten har ofta ett inaktuellt telefonnummer till kunden och därmed söker agenten reda på kundens telefonnummer med hjälp av webbsidor som t.ex. hitta.se och eniro.se. Liknande sidor används för de övriga nordiska länderna Norge, Finland och Danmark. När agenten ringt en kund så antecknas detta i en accessdatabas där all information samlas om kunden. Här finns information om kundens uppfattning kring den obetalda fakturan och om agenten ska ringa tillbaka eller dylikt. 2.2 Inkasso Som en följd av finanskrisen har skulderna till GE Capital ökat under senare år. Antalet kunder som inte betalar sina fakturor ökar och fler och fler företag begärs i konkurs. Detta leder till att effektivare metoder måste utarbetas i syfte att få tillbaka utlånade pengar. I dag använder GE Capital fyra olika sätt att driva in obetalda fakturor och det är via: 1) Brev GE Capital skickar ett brev till kunden med en påminnelse om förfallen faktura. 2) Telefonkontakt GE Capital ringer upp kunden och påminner om förfallen faktura. 2

8 3) Externt inkassoföretag GE Capital driver ärendet vidare till ett externt inkassoföretag. 4) Rättslig process GE Capital driver ärendet vidare till en rättslig process. Av dessa punkter är de två sista mest kostsamt för företaget och görs endast som sista utväg. Detta betyder att det är bättre att effektivisera punkt 1 och 2 d.v.s. de uppgifter som företaget kan sköta internt. Att skicka brev till kunden är en mindre bra lösning på problemet eftersom ett brev inte garanterar kontakt med kunden. Ett brev kan komma bort antingen via postgången eller inom det aktuella företaget innan rätt person har fått brevet, ett brev är också lätt att ignorera. Detta betyder att det är mest kostnadseffektivt att satsa på utvecklingsåtgärder gällande punkt 2 d.v.s. den del av företaget som arbetar med telefonkontakt med kunden. 2.3 Dialer Ett telefonverktyg Idag finns ett system som kallas Dialer. Det är ett datorsystem som är integrerad med telefonen via en databas vilket gör det enkelt för användare att ringa upp kunder. Detta system används i dag flitigt av företag som sysslar med antingen telemarketing eller inkasso. Fördelen med en Dialer är att man snabbt och enkelt kan ringa igenom en kundlista p.g.a. att användaren inte behöver slå upp ett nummer. Systemet kan även automatiskt ringa upp kunder på en bestämd tid. Vid telemarketingföretag används idag en enklare version av Dialer eftersom man på förhand inte behöver veta något om kunden, men inom inkasso är det viktigt att man även kan få uppgifter om kundens bakgrund. Detta leder därför till behov av en mer avancerad typ av Dialer Dialer GE Capital GE Capital har tidigare utvecklat en typ av Dialer som passar för deras inkassoavdelning i Spanien och Italien. Denna Dialer, Commander, fungerar helt efter de principer som företaget eftersträvar. Commander är en fulländad Dialer där man kan ställa in hur mycket tid agenten behöver innan en kund rings upp för att ta reda på kundens bakgrund. Agenten kan sedan notera i systemet vad kunden svarat. Alla kunder i Commander är placerade i olika köer. I början av månaden ligger alla kunder i samma kö men beroende på vad kunden svarat kommer kunden bli insorterad i ett kösystem utifrån när nästa kontakt ska ske. Denna typ av Dialer fungerar alltså som en kölista där man placerar kunderna efter sannolik betalningsförmåga. Nackdelen med Commander är att programmet i sig är dyrt att implementera i befintliga system. GE Capital söker efter billigare lösningar Dialer GE Capital Nordic Det nya systemet som ska utvecklas bör fungera liknande Commander (en utvecklad Dialer) eftersom företaget är nöjd med resultatet från Spanien och Italien. Det är inte bara ekonomisk lönsamt att titta på andra sätt än att implementera Commander i Norden det är också en nödvändighet eftersom de nordiska ländernas agenter har fler parametrar som man 3

9 måste ta hänsyn till. I Norden finns fyra olika språk som systemet ska hantera, dessutom tillkommer mail-, brev- och telefonkontakter. Commander är enbart byggd för ett språk och telefonkontakt vilket medför svårigheter att implementera systemet i Norden. Den huvudsakliga funktionaliteten som finns i det spanska och italienska Commander bör även finnas i det nya system som annars grundar sig på resultatet från denna studie. 3 Teori & metod 3.1 Användbarhet Användbarhet är ett uttryck som beskriver huruvida en produkt eller ett gränssnitt är lätt att använda. ISO är en internationell standard som definierar användbarhet på följande sätt: "The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use." 1 ISO 9241 använder sig av fyra nyckelord för att beskriva användbarhet, vilka är effectiveness, efficiency, satisfaction och specified context. De är definerade på följande vis: 1) Ändamålsenligt (effectivness) Noggrannhet och fullständighet med vilken användarna uppnår givna mål. 2) Effektivitet (efficiency) Resursåtgång i förhållande till den noggrannhet och fullständighet med vilken användarna uppnår givna mål. 3) Tillfredsställelse (satisfaction) Frånvaro av obehag samt positiva attityder vid användningen av en produkt. 4) Användningssammanhang (specified context) Användare, uppgifter, utrustning (maskinvara, programvara och annat material) samt fysisk och social omgivning i vilken produkten används. En annan definition av användbarhet kommer från Jacob Nielsen 2 där han använder sig av fem nyckelord i stället för de fyra som ISO använde sig av. Nielsens definition är: 1) Lätt att lära (learnability) Så att användaren snabbt kommer igång med arbetet. 2) Effektivt att använda (efficienty) När användare har lärt sig systemet måste det vara effektivt att arbeta med. 3) Lätt att komma ihåg (memorability) Det måste gå att återkomma till systemet efter en tids frånvaro och ändå kunna komma ihåg hur det fungerar. 4) Få fel (errors) Användarna ska kunna göra så få fel som möjligt. Om man ändå gör fel måste det gå att komma tillbaka till situationen innan felet uppstod. 5) Subjektivt tilltalande (satisfaction) 1 ISO Nielsen, J.(1993) 4

10 Det skall kännas angenämt att använda systemet. Man ska känna att det är tilltalande att jobba med systemet. Det finns även fler definitioner av användbarhet än här nämnda men de alla är snarlika. Denna tabell visar likheterna mellan tre olika definitioner 3 gjorda av ISO , Shneiderman och Nielsen. ISO Shneiderman Nielsen Effektivitet Tid att utföra en uppgift Tid att lära Effektivt att använda Lätt att lära Ändamålsenlighet Kvarhållande i minnet Över i tid Lätt att komma ihåg Få fel Frekvensen användarfel Tillfredsställelse Självupplevd tillfredsställelse Subjektivt tilltalande Tabell 1: Mätbara aspekter av användbarhet enligt ISO , Shneiderman och Nielsen 3.2 Användarcentrerad systemdesign Användarcentrerad systemdesign är en process som fokuserar på användare och användbarhet genom hela utvecklingsprocessen och vidare genom hela livscykeln. Det finns dock ingen samstämmig definition på vad användarcentrerad systemdesign innebär. Många MDI experter runt om i världen gör sin egen tolkning och likheter mellan de olika tolkningarna kommer här påvisas Definition 1 - Norman Denna definition kommer från Donald Norman 4 och den lyder; User centered design emphasizes that the purpose of the system is to serve the user, not to use a specific technology, not to be an elegant piece of programming. The needs of the users should dominate the design of the interface and the needs of the interface should dominate the rest of the system Definition 2 Gould & Lewis Gould och Lewis menar att man definierar användarcentrerad systemdesign genom tre principer. 5 1) Tidig fokus på användare Designteamet bör vara användardrivet och insatta i hur användarna tänker och fungerar. De rekommenderar intervjuer, observationer och mycket direkt kontakt med användarna innan den första designen har kommit ut. 2) Empiriska studier Under utvecklingsperioden bör olika slags tester göras för att säkerställa användbarheten i systemet. För att göra dessa tester krävs någon slags delprototyp av systemet och detta arbete bör ske kontinuerligt under hela systemutvecklingsperioden. Nya prototyper bör skapas för att säkerhetsställa hur användarna använder systemet. Det är viktigt att låta användarna testa prototyperna och inte bara köra dem som uppvisningsprojekt. 3) Iterativ design 3 Gulliksen,J & Göransson,B.(2002) 4 Norman, D.A.(1986) 5 Gould, J.D. Lewis, C. (1985) 5

11 Hela systemutvecklingen ska itereras flera gånger. Man kan inte ta för givet att det går att göra en perfekt prototyp som passar användarna på första försöket, det hela handlar om att göra om alla steg flera gånger för att uppnå bästa möjliga resultat Definition 3 ISO ISO definierar olika moment som bör vara med när man gör användarcentrerad design. Dessa fyra aktiviteter är följande: 1) Förstå och specificera användningssammanhanget 2) Specificera användarnas och organisationens krav 3) Producera designlösningar 4) Utvärdera designen gentemot krav Dessa fyra punkter bör itereras om och om igen tills den slutgiltiga versionen uppfyllt kraven som ställts från både användare och organisation Definition G&Gs principer Gulliksen och Göranssons 7 principer fångar representativt ett stort antal av de principer som föreslagits av övriga författare. Här följer en sammanfattning av dessa principer. 1) Användarfokus Verksamhetens mål, användarnas arbetsuppgifter och behov ska tidigt vara vägledande i utvecklingen. 2) Aktiv användarmedverkan i utvecklingen Representativa användare ska aktivt medverka, tidigt och kontinuerligt genom hela systemets livscykel. 3) Prototyping Tidigt och kontinuerligt skall prototyper användas för att visualisera och utvärdera idéer och designlösningar med slutanvändarna. 4) Utvärdera verklig användning Mätbara mål för användbarheten och kriterier för designen skall så långt som möjligt styra utvecklingen. 5) Explicita och uttalande designaktiviteter Utvecklingsprocessen skall innehålla dedikerade och medvetna designaktiviteter. 6) Tvärdisciplinära team Utvecklingen skall utföras av effektiva team med en bredd av kompetenser. 7) Användbarhetsförespråkare Erfarna användbarhetsförespråkare skall involveras tidigt och kontinuerligt under hela utvecklingsprojektets gång. 8) Lokalanpassa processerna Den användarcentrerade processen skall specificeras, anpassas och införas lokalt i varje organisation. 9) En användarcentrerad attityd En användarcentrerad attityd skall alltid etableras. 6 ISO (1999). 7 Gulliksen,J & Göransson,B.(2002) 6

12 En enklare sammanfattning är att säga att fokus i användarcentrerad design ligger på användarna. De bör involveras i designprocessen från början till slut genom en iterativ designprocess. Det betyder att alla idéer måste testas och utvärderas innan man går vidare till nästa fas. Enligt Jeffrey Rubin är det viktigt att förstå principerna för användarcentrerad design för att kunna förstå hur och varför användbarhetstester ska utföras. Rubin menar även att användartester är verktyg som används för att säkerställa en bra användarcentrerad design Intervjuer När man pratar om intervjuer avser man vanligen tre typer, de strukturerade, semistrukturerade och ostrukturerade. De strukturerade intervjuerna är planerade på förhand, man använder givna frågeställningar vilket kan leda till begränsade svar. Därmed blir det viktigt att göra intervjuplanen så specifik man någonsin kan. Fördelen med en strukturerad intervju är att man lätt kan sammanfatta och analysera dess resultat. De ostrukturerade intervjuerna är till mindre del planerad och man kan på förhand inte veta vad respondenten svarar utan man får ta det som det kommer. Fördelen men denna typ av intervju är att intervjuaren vidgar sina vyer då man kan få oväntade svar. Enligt Judith Bell 9 krävs det mer övning att utföra denna typ av intervju. Den sista intervjutypen, den semistrukturerade, ligger mitt i mellan den strukturerade och ostrukturerade. Intervjun görs ofta under neutrala förhållanden som t.ex. i ett mötesrum bortkopplat från respondentens vanliga arbetsbord. Detta medför att respondenten kanske inte kan svara på alla frågor och därför menar Preece, Sharp och Rogers 10 att man bör göra intervjuer tillsammans med en prototyp eller likande för att underlätta för respondenten att svara på frågorna. För att ytterligare underlätta för respondenten kan man använda en kontextuell intervju. Det är en intervju som görs i den miljö där respondenten normalt befinner sig. En kontextuell intervju kan göras strukturerad, semistrukturerad eller ostrukturerad. Det är mindre vanligt att man använder sig av den strukturerade intervjun eftersom man på förhand inte vet vad som händer på arbetsplatsen. 3.4 Prototyper Det finns olika typer av prototyper och den mest kända uppdelningen görs med hjälp av low- och high-fidelity prototypning. 11 Low-fi innefattar all prototypning som inte liknar den slutgiltiga produkten. Det kan handla om att man använder fel medium för prototypen eller att den inte innehåller den funktionalitet som den kommer innehålla i slutprodukten. Low-fi prototypning är användbart eftersom det är en relativt billig prototyp samtidigt som det går fort att göra en ny. Denna typ av prototypning är vanlig i början av projekt för att spinna vidare på en idé. Men dessa blir aldrig implementerade som slutprodukter. 12 Den andra typen av prototyp som kallas high-fi använder samma medium som man har i den slutgiltiga produkten, den är i själva verket menad att vara så lik slutprodukten som möjligt. Denna typ av prototyp innefattar så mycket funktionalitet som möjligt för att demonstrera hur produkten kan se ut när den är färdig. Nackdelen med denna typ av prototypning är att den är resurskrävande och svår att ändra på. Varför ska man då ha prototyper? Preece, Sharp och Rogers ger sin förklaring. 8 Rubin, J. (2008) 9 Bell, Judith (2005) 10 Preece, J.: Rogers, R. & Sharp, H. (2007) 11 Lbid 12 Lbid 7

13 It is often said that users can t tell you what they want, but when they see something and get to use it, they soon know what they don t want. 13 Det finns en risk för att prototypning ses som ett alltför stort, svårt och dyrbart verktyg. I de flesta projekt görs prototyper utan att det ens var tanken från början, små prototyper som storyboards är en del av en low-fi prototypning. Denna studie kommer använda sig av båda typerna av prototypning. I början av projektet används low-fi prototyper för att spinna vidare på idéer och funktionalitet mot att i slutet av projektet gå mot en prototyp som går att vidareutveckla till det riktiga systemet. 3.5 Workshops Workshop är en term som används för möten där det förväntade resultatet är nya idéer. Lindquist och Westerlund 14 menar att workshops har lika många betydelser som uttolkare av ordet. Workshops kan struktureras på olika sätt och kan hålla på allt från någon timme till flera veckor. Det är vanligast att workshops använder sig av 4-8 personer och att dessa personer är potentiella användare. Det är meningen att dessa användare ska representera sig själva och inte en grupp. Varje individ är viktig för workshopen. 3.6 Observationer Observation är en bra metod för att samla data i alla stadier i ett projekt. Tidigt i projektet hjälper observationer till att förstå användarna, hur de arbetar och vad de gör. Men det är även viktigt att göra observationer senare i projektet då prototyper används för att se hur användarna använder prototyperna. Det kan vara svårt att göra korrekta observationer, man vet inte vad man ska titta eller tänka på när man observerar användarna när de arbetar. Det finns tre regler från ett ramverk som man kan följa 15. 1) Vem använder sig av prototypen/systemet som observeras? 2) Vart används prototypen/systemet? 3) Vad gör användarna med prototypen/systemet? Det kan underlätta att använda detta ramverk för att samla data under observationen, mer erfarna observatörer brukar använda mer avancerade ramverk. Det ovanstående ramverket tar endast upp vem/vart och vad användarna gör med systemet. 3.7 Användbarhetstester Användbarhetstest är en metod som används för att kontrollera att användbarheten hos en produkt eller prototyp uppfyller de krav som tidigare ställts. Syftet med dessa test är att hitta användbarhetsfel och därmed höja kvalitén på produkten. Preece, Sharp och Rogers påpekar även att det är produkten som ska testas och inte användarna själva Preece, J.: Rogers, R. & Sharp, H. (2007) 14 Lindquist,S.: Westerlund,B. (2004) 15 Preece, J.: Rogers, R. & Sharp, H. (2007) 16 Lbid 8

14 Enligt Rubin 17 så måste vissa grundkriterier uppfyllas för att få kalla testen användbarhetstest. Dessa krav är följande. 1) Hypotesskapande En hypotes måste skapas innan testningen utförs för att visa vad man tror kommer att hända innan man utför testningen. 2) Slumpade personer från målgruppen Man måste förstå målgruppen för att kunna ta slumpmässigt urval som sedan representerar den väl. 3) Kontrollerade omständigheter Kontrollerande omständigheter är kritiska för denna typ av test eftersom det är viktigt att kunna validera testet. Alla testpersoner bör ha liknande erfarenhet av systemet innan och under testet. 4) Storleken på gruppen För att man ska utföra statistik på testen måste det vara en viss storlek på gruppen, för liten grupp testpersoner kan medföra fel i sammanfattningarna. Men Rubin menar även att det ibland är omöjligt att uppnå dessa krav och att man enbart ska sträva efter att uppfylla dem. It is often impossible or inappropriate to use such a methodology to conduct usability tests in the fast-paced, highly pressurized development environment in which most readers will find themselves. 18 När man utför användbarhetstest bör man befinna sig på en lugn plats där användarna inte behöver känna sig stressade. Denna typ av plats brukar vara ett användbarhetslabb men många företag har inte tillgång till denna typ av rum utan får nöja sig med ett vanligt kontorsrum. Det viktiga är att låta användaren i lugn och ro testa produkten utan att känna sig stressad av sina arbetskamrater. 3.8 Verbala protokoll Den så kallade tänka-högt metoden 19 är till som ett hjälpmedel för andra metoder som exempelvis observationer. Vid observationer kan observatören inte veta vad den som observeras tänker utan bara uppmärksamma vad den gör. Meningen med metoden är att den som observeras hela tiden berättar vad den tänker när den utför vissa uppgifter. Detta medför större förståelse för hur produkten används. 4 Genomförande 4.1 Metodval Metoderna som har använts i denna studie har valts utifrån teorin för användbarhet, målet med studien samt de givna förutsättningarna från företaget. En större workshop gjordes i början för att så snabbt som möjligt sätta fart på arbetet. Denna workshop anordnades för att projektets ansvariga samt några utvalda användare skulle få en större insikt i hur projektet skulle komma att fortskrida. En 17 Rubin, J. (2008) 18 Lbid 19 Preece, J.: Rogers, R. & Sharp, H. (2007) 9

15 fokusgrupp eller någon liknande metod kunde ha använts i projektets start men dessa metoder valdes bort eftersom detta projekt gjordes internt där de flesta tilltänkta användarna redan var insatta i att ett nytt system skulle komma att utvecklas. Det finns inga självklara metoder som måste användas i användarcentrerad systemutveckling, istället bör man anpassa metoderna efter de enskilda projekten. De flesta undersökningarna valdes att göras i form av gruppövningar eftersom fri tillgång till användare fanns under hela projektets gång. Gulliksen och Göransson 20 menar att man som ny användbarhetsexpert måste anpassa sig till företagets gamla process och införa användarcentrerade metoder i den redan existerande processen. Med detta i åtanke skapades därför en designprocess som var anpassad till företagets gamla projektprocess men med förnyelse i att användarcentrerade aktiviteter infördes. Den systemutvecklingsprocess som användes ser ut så här; Processen innehåller tre olika iterationer där användarna är med och påverkar resultatet i varje iteration. Vikten av att ha kvar företagets gamla process är betydelsefull eftersom man inte bör förnya processen alltför snabbt och därför utgick detta arbete från företagets gamla systemutvecklingsprocess. De stora förändringarna är att man lagt till iterationer parallellt med nya aktiviteter för att förbättra användbarheten. Först kommer en iteration med workshop där användarna skriver ner all funktionalitet som ska vara med i systemet. GE Capital var noga med att ha ett kravdokument där all funktionalitet dokumenterades skriftligt eftersom de ville vara säkra på vad de får när de skriver kontrakt med det företag som ska utföra programmeringen. Därefter kommer en ny iteration där första upplägget till design skapas, hur interaktionen ska se ut i systemet samt vad som faktiskt går att genomföra i systemet. Denna iteration testades av användare för att få en klar beskrivning av hur användarna ville att systemet skulle se ut samt att få en tillökning på funktionaliteten om så önskades. Den tredje iterationen handlade till största del om att testa och ändra den slutgiltiga prototypen för att göra de sista nödvändiga ändringarna. Det är viktigt att påpeka att det kravdokument som skapades i början ändrades under alla iterationer. 4.2 Workshop Det fanns två olika typer av workshops under projektets gång. I början av projektet, den första iterationen, var den största och mest genomgående workshopen. I de andra iterationerna förekom flera möten med användare, designers och programmerare. Under dessa möten användes också workshops men de var av en annan typ. 20 Gulliksen,J & Göransson,B.(2002) 10

16 4.2.1 Utförande Den första workshopen varade i två dagar. Den var planerad som informationsworkshop för att lära känna projektets medlemmar samtidigt som den hade informationsföreläsningar om hur en Dailer fungerar. Workshopen var i GE Capitals kontorslokaler och programmet Commander var till stor hjälp och användes som grund för att visa hur systemet bör fungera. Efter föreläsningarna började det skissas på hur det nya systemet skulle se ut. Sedan åkte alla och hälsade på programmerarna för att se hur det nuvarande systemet ser ut d.v.s. det system som kommer att vidareutvecklas. Den andra typen av workshop genomfördes på användarnas arbetsplats. 2-4 användare samlades i liten grupp för att träffa utvecklare och designers men även annan IT personal. Målet med mindre workshops var att ta reda på vart projektet var på väg och vad som saknades för att komma vidare. De prototyper som fanns tillgängliga testades under denna typ av workshops. 4.3 Observation och kontextuell intervju Under projektets gång gjordes fyra kontextuella intervjuer för att få svar på frågor om hur användarna arbetar idag samt få deras syn på vad för funktionalitet som saknas idag. Genom att göra observationer har man möjlighet att samla information om hur mycket agenterna faktiskt ringer Utförande Fyra agenter observerades under den tid de ringde kunder som hade förfallna fakturor. Externa hörlurar som kopplades till telefonen användes för att kunna följa samtalet parallellt med att agenten arbetade via datorn. Efter varje samtal ställdes frågor till agenten om vad kunden ville göra och vad för arbete agenten behövde göra för att uppfylla dessa krav. En ostrukturerad intervjumetod genomfördes eftersom man inte kan förutspå vad kunderna kommer att svara. Detta möjliggör även att agenterna får berätta mer fritt om hur de tycker dagens system ser ut och hur de skulle vilja ha det nya systemet. 4.4 Användbarhetstest Syftet med användbarhetstesten var att testa de olika prototyperna för att hitta användbarhetsfel och funktionsfel. Det gjordes två olika användbarhetstest. Under det första testet valdes 4 agenter ut för att ringa till tre fiktiva kunder med fixerad data eftersom vi ville styra vilka uppgifter som agenten skulle utföra. Det andra testet genomförde alla agenter som var tillgängliga och de ringde skarpt till kunder för att testa stress och andra faktorer som inte går att testa under fixerad data Utförande Det första användbarhetstestet utfördes på en tidig prototyp. Där var fokus att agenterna skulle få testa de nya verktygen och komma med åsikter och tankar om hur de ville ha det. Agenterna skulle ringa tre fiktiva kunder där telefonnumret gick till min mobiltelefon. Under testet fick agenterna uppgifter och jag observerade hur de utförde uppgifterna. Det andra användbarhetstestet utfördes på den slutgiltiga prototypen. Fokus var att finna ytterligare designfel samtidigt som stressfaktorer och olika timers testades. Alla agenterna deltog i testet där de ringde skarpt till kunder för att i möjligaste mån efterlikna autentiska förhållanden. Alla agenterna hade samma uppgifter i det första testet medan det andra testet kunde leda till olika uppgifter för agenterna beroende på kundens svar. Under båda testen fick agenterna använda tänkahögt metoden. 11

17 4.5 Prototyp En första low-fi prototyp skapades redan under den första workshopen där olika storyboards skapades tillsammans med några skisser. Denna variant av prototyp var till hjälp för att illustrera och demonstrera hur programmet fungerade. De andra prototyperna liknade mer typen high-fi, där ett datorprogram programmerades och testades av användarna. Den första av high-fi prototypen var en interaktionsprototyp som testades på fyra användare, den andra och sista high-fi prototypen var en förbättring av den första samtidigt som mycket mer funktionalitet och design fanns med. 5 Resultat 5.1 Den första iterationen Den första iterationen handlade om att ta fram ett koncept på hur ett nytt system kan skapas. Denna iteration fokuserade på att ta fram förslag på hur projektet ska komma vidare och även visa tidiga lösningsförslag Workshop De tre agenterna som var utvalda att komma på workshopen kom tillsammans med två chefer från GE Capital. Workshopen utgjordes av föreläsningar om hur en Dialer fungerar och föreläsare var Andy Smale 21 och Lee Camerrige 22 som var med och vidareutvecklade Commander. Användarna fick då information om hur en Dialer kan se ut och fick se exempel från Commander. De viktigaste punkterna som togs upp och diskuterades under denna workshop var: 1) Vilken grund i systemet ska vi välja? Det finns tre alternativ att välja mellan. Det första alternativet var att vi skulle installera Commander vid GE Capital. Programmet är dyrt och GE Capitals ledning efterfrågade ett billigare alternativ. Det andra alternativet var att utveckla ett helt nytt system men detta är också kostnadskrävande, kan bli både dyrt och ta lång tid. Det sista alternativet var att vidareutveckla en nuvarande Dialer till den funktionalitet och design som GE Capital önskar och har behov av. Det sista alternativet valdes eftersom det ansågs mest kostnadseffektivt och då marknaden för Dialer inte är alltför stor visste vi att Aastra hade en Dialer kallad Solidus ECare (hädanefter kallad Solidus). Under workshopen diskuterades frågor kring vad som behövde förbättras för att Solidus skulle uppfylla våra önskemål och krav. 2) Hur fungerar en Dialer? En Dialer fungerar genom att den sorterar kunderna i olika köer. Kunderna sorteras utifrån dess historik, t.ex. hur långt efter kunden är med betalning samt hur stor skuld kunden har. Efter att kunden är sorterad i kö är det dags för agenten att ringa. Agenten kan välja mellan en eller flera köer och ett förslag på kund att ringa kommer då fram på skärmen. När samtalet är avslutat ställer programmet en fråga till agenten vars svar påverkar kundens köplacering inför nästa samtal. 3) Vilka köer ska finnas? 21 Andy Smale (2009) 22 Lee Camerrige (2009) 12

18 Under workshopen framkom önskemål om att minimera antalet köer i syfte att underlätta för agenterna. Ett stort problem var att de nordiska länderna måste ha egna köer eftersom det pratas olika språk med kunderna. De köer vi kom fram till skulle skapas var följande: - Inget löfte om betalning Från början ligger alla kunder i denna kö eftersom man inte ringt kunden ännu. Det betyder med andra ord att denna kö är till för en första kontakt med kunden. - Återuppringning Denna kö är till för återuppringning när man haft kontakt med kunden tidigare under månaden. - Klagomål/Rättslig process/administrationsfel Om kunden har klagomål och vill lämna tillbaka varan de leasar/hyr hamnar den här. Även rättsliga processer eller administrationsfel hamnar i denna kö. Kön kräver att agenten i lugn och ro tar varje fall för sig och inte stressar sig genom kön. - Konkurs Om kunden gått i konkurs hamnar man i denna kö. - Fel nummer Vissa kunder har fel telefonnummer inlagda i systemet och numret bör därför uppdateras och hamnar därmed i denna kö. Dessa fem köer ska multipliceras med fyra (för de nordiska språken svenska, norska, danska och finska) vilket leder till att 20 olika köer bildas. Eftersom det är köerna som kommer att styra vilka kunder som agenten ska ringa är det viktigt att kunderna är rätt sorterade. 4) Import och export av data När man skapar ett nytt system gäller det att import och export fungerar på ett bra sätt. GE Capital har en stordator som kallas Fabriken. Denna stordator innehåller alla fakturor och inbetalningar. Problemet med Fabriken är att den använder sig av rådata och inte visar all fakta om kunden. GE Capital har tidigare utvecklat en accessdatabas som kallas Collector som ska vara till hjälp i detta syfte. Denna databas importerar rådata från Fabriken som sedan illustrerar informationen mycket tydligt för agenterna. När vi diskuterade import och export under denna workshop handlade det om vi skulle ha kvar Collector eller inte. Det nya systemet ska klara att både illustrera och hantera data för att agenterna ska bli nöjda. Slutsatsen blir att Collector ska finnas kvar som det gör idag d.v.s. exportera data om vilka kunder som ska ringas via Solidus. 5) Informationsskärmar poppas Under workshopens gång beslutades att Collector skulle vara kvar eftersom agenterna ville ha kvar det redskap som de utvecklat under en längre tid. Detta betydde i sin tur att det nya systemet Solidus ska kunna visa information från Collector i sitt program eller interagera med accessdatabasen. Det beslutades att programmet ska klara att interagera med Collector och poppa upp på skärmarna på det sätt som agenterna önskar. Agenterna önskade även en popp på skärmen i Fabriken eftersom de alltid använder Fabriken för att få ytterligare information när de pratar med kunderna. 6) Att spara uppgifter efter uppringd kund Efter att agenten ringt en kund måste resultatet av samtalet sparas i antingen Solidus, Collector eller Fabriken. Det som diskuterades under workshopen var att det hade varit bra 13

19 om man kunde göra så att man enbart sparade resultaten i Solidus och Solidus uppdaterade de andra programmen automatiskt. 7) Hur man sparar kunduppgifter I dagsläget sparas ett av kundens telefonnummer och med en Dialer är det meningen att man kan spara flera telefonnummer. Om kunden inte svarar på ett nummer ringer programmet automatiskt upp ett annat. Detta är praktiskt när man har en kund som har ett kontorsnummer, ett mobilnummer och även ett nummer till en telefonväxel på företaget. Det som beslutades under workshopen var att dagens system i Fabriken och Collector ska byggas ut så att fler telefonnummer kan sparas. Det nya systemet Solidus ska kunna lagra och använda flera nummer för samma kund, för att kunna välja vilket nummer man vill ringa. 8) Löpande informationsflöde Agenternas chefer är i behov av ett verktyg i Solidus som kan illustrera agenternas arbeten. Detta verktyg ska även kunna visa vilka köer som har problem och behöver extra resurser under dagen. Det beslutades att ett sådant informationsverktyg är viktigt och bör finnas med i systemet. 9) Besök hos utvecklarna Eftersom denna workshop var att knäcka idéer om hur det nya systemet ska fungera åkte vi på studiebesök till TDC vid Telefonplan i Stockholm. TDC är det företaget som GE Capital har kontrakt med för utveckling av Solidus men det är Aastra som säljer programmet, TDC gör vidareutvecklingen. Det fanns ingen utgående telefonfunktionalitet i Solidus utan enbart ingående. Tillsammans med TDC beslutades att undersöka den ekonomiska planen för vidareutveckling av Solidus för att fungera som en Dialer (Solidus är i dag ett multimediaverktyg och ingen Dialer) Observation & Kontextuell intervju Fyra agenter observerades när de ringde skarpt till kunder. Eftersom studien handlar om systemutveckling har GE Capitals kundrelation mindre betydelse. Därför kommer jag presentera resultatet från agenterna oberoende av kundrelation. Här nedan presenteras resultatet. Agenterna på GE Capital Nordic använder sig av accessdatabasen Collector och stordatorn Fabriken som hjälpmedel när de ringer kunderna. Systemet känns ineffektivt eftersom det tar tid för agenterna att dela upp kunderna mellan sig. Det tar också tid att få fram telefonnumret till kunderna eftersom agenten använder sig av olika webbsidor som t.ex. eniro.se. När agenterna frågades om hur de kände inför att börja arbeta med ett nytt system blev svaren till stor del negativa kommentaren som exempelvis; Jag vill inte sitta på ett callcenter! Flera agenter sa att de var helt ointresserade av ett nytt system där man blev påtvingad samtal hela dagarna och att det skulle bli den enda arbetsuppgiften för dem. Eftersom agenterna har många andra sysslor t.ex. mailkonversation kommer detta inte att hända. Förändrade metoder kräver ofta ökat engagemang och arbetsinsats då det krävs tid att vänja sig med ett nytt system. Systemet ska vara till hjälp för agenterna under den tid de ringer kunderna. Under observationen upptäcktes att agenterna inte loggade samtalen rätt i Collector. Detta leder till fel i programmet och kommer även leda till fel i det nya systemet om man inte loggar samtalen rätt. 14

20 Det som samtliga agenter missade var användningen av funktionen next action date. Den funktionen håller reda på när kunden ska ringas nästa gång och är förinställd på en vecka efter samtalet. Önskas annan tidsrymd måste agenten manuellt ändra inställningen till annat datum, det datum som passar bättre. Agenterna nyttjade inte det gamla automatiska systemet med next action date, i stället kändes det lättare för dem att använda ett system med post-it lappar. När agenterna tillfrågades om varför de inte skrev in mer lämpliga datum i systemet så kom följande svar; Nej den där använder jag inte Jag har aldrig behövt göra det Vi sorterar aldrig efter next action date så den har ingen betydelse för oss Det visade sig vara relativt vanligt att kunder som blev uppringda hade tappat bort fakturan och behövde därför få en ny. Agenten tog då fram en ny faktura genom fakturadatabasen och denna databas nåddes via en inloggning till ett annat system. Agenterna tyckte det var ett jobbigt moment som tog tid eftersom det var ganska vanligt att kunderna saknade fakturan. Jag gillar inte att man måste logga på så många ställen, kan man inte få så man bara behöver logga på ett ställe? Övriga kommentarer som framfördes var; Kommentarfliken i Collector är för liten, jag ser inte vad som står Alla telefonnummer är inaktuella i Collector, de går till fel personer Sammanfattning Den första iterationen handlade om att ta fram en idé om hur det nya systemet ska utvecklas samt hur systemet ska se ut och fungera. Det började med en större workshop där användare och chefer samlades för att få igång projektet. Denna workshop illustrerade Commander för att visa hur en Dialer fungerar. Det var därefter dags att ge förslag på hur en ny Dialer skulle kunna utvecklas. Det beslutades att undersöka om det var möjligt att vidareutveckla multimediaverktyget Solidus till att bli den Dialer som företaget behövde. Användarna gav intrycket att det inte behövdes ett nytt system men det var ändå moment i dagens system som de inte var nöjda med. Användarna var angelägna om att det nya systemet inte skulle fungera som ett callcenter. Iterationen avslutades med syftet att Solidus ska bli den nya Dialern. 5.2 Den andra iterationen Den andra iterationen hade som syfte att ta fram en tidig prototyp som skulle vidareutvecklas och testas Workshop Denna workshop var av mindre modell där fem personer deltog, två agenter och en IT ansvarig från GE Capital, en utvecklare från Solidus och jag. Under denna workshop diskuterades olika lösningar på 15

21 hur import och export ska fungera mellan programmen samt en av de viktigaste funktionerna i det nya systemet, skärmpoppning. 1) Import och export Import och export från två skilda system kan vara en krävande process. Det kräver mycket reflektion för att få det på ett bra sätt från början. Under denna workshop diskuterades olika lösningar på hur Collector bör exportera data för att Solidus ska kunna importera, sortera och samtidigt läggas i rätt kö. Vi delade därför upp denna fråga i tre mindre frågor. - Exportering från Collector Under workshopen kom flera förslag på exportering fram men det beslutades att bara en av dessa skulle ta steget till prototypstadiet. Exporteringen skulle se ut som följande: Collector ska dagligen exportera sina listor på kunder till filer. Dessa filer ska ha namnen på de köer man vill skapa samtidigt som dagens datum. Ett exempel är om man vill ha en kö som heter no contact i Solidus så ska Collector exportera en fil som heter nocontact är datumet och denna fil ska innehålla alla kunder som har statusen no contact i Collector. Dessa filer ska dagligen läggas på Solidus server i en speciell mapp så Solidus vet vart filerna finns. - Sortering efter prioriteringsalgoritm Kundlistan i Collector är byggd så att man kan sortera efter prioritering. Denna prioritering är en algoritm som viktar de olika kunderna i betydelsen vilka som bör ringas först. Kunder med stora skulder är naturligtvis viktigare att ringa än kunder med liten skuld. Under workshopen diskuterades hur man ska sortera datan till Solidus. Solidus klarar inte att sortera kunderna och har ingen prioritering inbyggd, för detta krävs stora omprogrammeringar. Det beslutades därför att sorteringen ska ske i exporteringen. Collector som dagligen ska exportera filer med kunder ska exportera dessa filer i sorterad ordning där den första kunden i filen ska ha högst prioritet. Solidus kommer därmed att bygga sina köer utifrån hur filerna är sorterade på förhand. - Rätt kunder i rätt kö Det beslutades att alla kunder med samma status i Collector ska läggas i samma fil. Det innebär att alla kunder med olika status i Collector kommer exporteras till olika filer och därmed hamna i olika köer i Solidus. 2) Skärmpoppning Skärmpoppning var en annan viktig del i denna workshop. Här fanns en osäkerhet hos oss hur vi skulle lösa problemet. Under workshopen kom vi fram till att vi ska använda oss av vbscript (visual basic script). Solidus har inbyggda triggers i sitt system som löser ut när man önskar. När dessa triggers aktiveras ska vårt skärmpoppningsskript köras. Det skriptet ska utföra är att anropa bakgrundsprogram som Collector och Fabriken för att ta fram data om aktuell kund. Om man utnyttjar kundens telefonnummer och namn kan det matchas med den data som finns om kunden i Collector och Fabriken. Under workshoppen utformades en prototyp över detta som vi testade på användarna (senare följt av användbarhetstestet). 16

22 5.2.2 Prototyp - Skärmpoppning Den prototyp som utvecklades under workshopen var ett vb-script. Skriptet länkades ihop i Solidus för att kunna testats när man ringer kunder. Prototypens huvudsakliga mål var att testa skärmpoppningen för att få svar på om det var möjligt att göra skärmpoppningarna på det sätt som användarna önskat. För att göra det enklare för testning och vidareutveckling av prototypen så användes en testdator. Denna testdator placerades i användarnas arbetsmiljö för att återspegla den autentiska arbetsmiljön Användbarhetstest Prototypen med skärmpoppning testades av fyra användare. Dessa användare fick sätta sig vid den uppställda testdatorn och ringa tre fiktiva kunder. Testet gav oss möjlighet att förstå vad som saknades och vad som borde ändras. Här kommer några exempel på de förändringar användarna hade synpunkter på under testet. Antalet fönster man kan använda i Fabriken är låst till endast ett fönster. Detta eftersom scriptet inte klarar att hålla reda på vilket fönster som ska uppdatera vad. Användarna påpekade denna brist tidigt och sa att de brukar använda sig av tre olika fönster, ett för notat (kommentarfält), ett för reskontra och ett annat för information om vad för produkt det handlar om (t.ex. en Dell dator för leasning). Ett annat problem som upptäcktes var att scriptet matchar telefonnummer. Vissa företag använder sig av samma företagsväxel vilket kan leda till att fel kund presenteras eftersom företagen har samma telefonnummer. Användarna menade att detta inte är vanligt i Sverige och Finland men betydligt vanligare i Danmark och Norge. Innan testet såg vi ett hinder i att det tog för lång tid för fönstren att poppa upp, det tar ca 3 sekunder att poppa Collector men det tar upp till 10 sekunder att poppa fönstret från Fabriken. Användarna sa ingenting om tiden och när jag ställde en ledande fråga om hur de tycker prototypen fungerade svarade de att den var snabb och att det var skönt att slippa leta efter kunddata och istället få informationen automatiskt. Under testet hittades flera funktionsfel som buggar och logiska fel. Dessa fel ändrades efter testningen Sammanfattning Den andra iterationen handlar om att fortsätta med idén om att Solidus kan utvecklas till att bli den nya Dialern. Det utfördes en workshop som tog fram en prototyp där man kan illustrera skärmpoppning. Denna prototyp är gjord av ett vb-script (visual basic script) och användes på en testdator med modifierad Solidus för att klara poppningen. Testdatorn placerades hos användarna och användbarhetstest utfördes. Testet gav möjligheter till förbättringar på bland annat antalet fönster som kan poppas och även poppningstiden. Iterationen avslutades med förhoppning om att Solidus ska utvecklas till den nya Dialern där testerna på prototypen visade att det är fullt möjligt. 5.3 Den tredje iterationen Den tredje och sista iterationen handlade om att utveckla systemet från prototyp till färdig produkt. I slutet av denna iteration är systemet fortfarande en prototyp men väldigt nära den slutgilltiga produkten. 17