INFORMATIK C-10. Personas Hur kan de bidra till en lyckad systemutveckling? Författare: Towa Eng

Transkript

1 INFORMATIK C-10 Personas Författare: Towa Eng

2 Mittuniversitetet i Sundsvall Institutionen för informationsteknologi och medier Systemvetenskapliga programmet Informatik C, C uppsats Handledare: Katarina Lindblad Gidlund Examinator: Karl W. Sandberg Personas Författare: Towa Eng (Toen0000@student.miun.se) ABSTRACT: Denna uppsats beskriver Personas och redogör för några aspekter som kritiseras hos denna metod. Förslag ges också till hur metoden skulle kunna leda till mer nyanserade Personas och kombineras med andra systemutvecklingsmodeller för att på så sätt bidra till en lyckad användarcentrerad systemdesign. Syftet med denna uppsats var att undersöka hur Personas framställs och hur de kan tillskrivas egenskaper för att de på ett bättre sätt ska spegla användarna samt att studera hur metoden Personas kan tidseffektiviseras och användas i en användarcentrerad systemutvecklingsprocess. Denna studie visar att delar av den kritik som riktats mot metoden bottnar i att de Personas som framställs och används som mål i systemdesign är för diffusa och inte besitter de egenskaper som skulle göra dem till lämpliga representanter för användarna. Det har också framkommit att en kombination av denna metod och traditionella systemutvecklingsmetoder skulle kunna bidra till en lyckad systemutvecklingsprocess och underlätta för arbetet med användarinteraktion. NYCKELORD: Personas, användarcentrerad systemdesign, användarinteraktion, RUP. 2

3 Mid Sweden University, Sundsvall Department of information technology and media Informatics, C Supervisor: Katarina Lindblad Gidlund Personas How can they contribute to a successful systems development process? Author: Towa Eng (Toen0000@student.miun.se) ABSTRACT: This essay describes the method Personas and presents some of the aspects often criticized. Propositions are made regarding how this method could be combined with other systems development methods in order to contribute to a better systems development process. The purpose of this essay was to study how Personas are created and how they can be ascribed details and traits to be a more helpful tool in the design process. The point was also to investigate if there are more time efficient ways to create these Personas and how this method can be used together in a participatory systems development process. The results show that part of the criticism which is pointed at this method is based on the fact that the Personas are too vague and lack the detail to be useful. A combination between Personas and a traditional systems development method could contribute to a successful development process and ease the user integration procedure. KEYWORDS: Personas, participatory design, user interaction, RUP. 3

4 1. INLEDNING PROBLEMET SYFTE FÖRVÄNTAT RESULTAT AVGRÄNSNING GENERALISERING, INTRESSENTER OCH MÅLGRUPP DISPOSITION METOD ENKÄTKONSTRUKTION BORTFALLSANALYS URVALET AV ANVÄNDARGRUPPER ARBETSGÅNG PERSONAS DEN FIKTIVA ANVÄNDAREN VAD ÄR PERSONAS? HUR KAN PERSONAS UTFORMAS? PERSONAS PÅ GOTT OCH ONT Fördelar Nackdelar ENKÄTUNDERSÖKNING RESULTAT AV UNDERSÖKNINGEN FRÅN HANDLÄGGARE TILL PERSONA ANVÄNDARCENTRERAD SYSTEMDESIGN OCH PERSONAS RATIONAL UNIFIED PROCESS RUP PERSONAS VS. RUP ANALYS DISKUSSION SLUTSATS FRAMTIDA FORSKNING KÄLLKRITIK

5 1. Inledning Isn t it funny how we never have time to do things right, but somehow we always find the time to do them over? (Wiegers 2000 s 3). Detta är ett uttalande angående den tidsbrist som ofta finns i de tidigare faserna av en systemutvecklingsprocess. Ofta satsas för lite tid och resurser på dessa delar vilket visar sig i resultatet. Wiegers ger exempel på en studie som innefattar 8380 IT-projekt där över hälften drabbades av reducerad funktionalitet, överskred budgeten och/eller levererades för sent. De tre största orsakerna till detta var brist på användarmedverkan, ofullständiga krav och förändrade krav. (ibid.) Den erfarenhet som idag finns av just sådana fallerade IT-projekt borde bidra till att mer fokus läggs på kravfångst och kravanalys men vi verkar inte lära oss av gamla misstag. När det gäller interaktionen med användarna är min uppfattning att det är en del i processen som många konsulter och utvecklare fasar för. Kanske för att de anser att användare är okunniga och att involvera dem i systemutvecklingsprocessen är tidskrävande. Enligt min ringa erfarenhet är detta dock ett område som är otroligt viktigt för slutprodukten och samtidigt en del som kanske blir allt mer komplicerad ju längre vi kommer i utvecklingen. I och med 24h-myndigheten får vi till exempel en användargrupp vi kanske tidigare inte ägnat en tanke under systemutvecklingsprojekt. Från att ha utvecklat system för specifika, identifierade användargrupper kommer nu problematiken med att utveckla för precis hela Sveriges befolkning. Hur fångar vi upp åsikter och inställning till IT-system från hela befolkningen? Vilka krav kommer de att ställa på användbarhetsfrågor? Att användare är delaktiga i utvecklingsprocessen känns för mig som den enda möjligheten att få ett bra och användbart system. Men det är inte bara tidsaspekten som gör att många utvecklare väljer att inte arbeta direkt med slutanvändarna. Alan Cooper (Cooper 2004) menar att en användare tenderar att fokusera på fel saker, till exempel var ikoner ska sitta och vilka färger som ska användas. Detta är detaljer som enligt Cooper inte är väsentliga i begynnelsen av en systemutvecklingsprocess. En annan del som Cooper kommenterar är att även om det är användaren som stöter på problemen som skall åtgärdas så innebär det inte att hon är den som bäst kan lösa dem. Här kommer Coopers egenutvecklade metod Personas in i bilden, fiktiva personer som tillskrivs personlighet, yrke, mål och så vidare och sedan används som målgrupp i systemutvecklingen. Grunden till dessa Personas vilar på en kartläggning av användarna som genomförs med hjälp av bland annat intervjuer. Det är en metod som har visat sig vara väldigt användbar. (ibid.) 1.1. Problemet Även om denna metod har visat sig vara framgångsrik enligt Cooper så finns det kritiker. Pruitt och Grudin (2003) anser att en nackdel med denna metod är att de Personas som tas fram i en utvecklingsprocess blir alltför förenklade och stereotypa. Den förstärker de fördomar som finns och placerar in användare i speciella fack. Därför skulle kanske en mer nyanserad Persona vara bra som underlag i utvecklingen. En annan risk kan vara att utvecklare för enkelhetens och kostnadens skull återanvänder de Personas som tagits fram i en systemutvecklingsprocess när ett nytt projekt påbörjas. Att återanvända Personas kan i undantagsfall fungera men kan också göra att utvecklingen sker mot helt fel målgrupp, även om det till och med är samma verksamhet det handlar om. (Pruitt & Grudin 2003) För SPV och många andra företag och verksamheter är generationsskiften en problematisk del i systemutvecklingen. Bland SPV:s interna användare finns ett större åldersglapp vilket gör att ett generationsskifte innebär en stor förändring av användarnas egenskaper och 5

6 förutsättningar. Eftersom generationsskiften alltid kommer att ske är detta ett intressant problem. Även om det inte går att skapa Personas som klarar av en sådan övergång eftersom en Persona måste förändras i takt med användarna så kanske det är möjligt att ta fram en bra metod som hanterar detta på ett bra sätt. Johan Linder och Jens Eriksson (jag kommer senare att presentera dem närmare) är konsulter på Sigma Pleon. De anser att metoden Personas har många positiva delar men att det skulle vara för tidskrävande att göra en grundlig kartläggning av användare i inledningen av varje systemutvecklingsprojekt. (Samtal med Linder och Eriksson ) Dessa problem leder mig fram till följande frågeställningar: Coopers Personas har kritiserats för att vara förenklade och stereotypa. (Pruitt & Grudin 2003) Hur kan metoden användas för att dessa Personas ska bli mer nyanserade och inte resultera i stereotyper? Hur kan Personas vävas in i en användarcentrerad systemdesign för att vara ett stöd i utvecklingen? När metoden utförs enligt Coopers anvisningar är den ganska tidskrävande. Hur skulle Personas kunna tas fram på ett alternativt och mindre tidskrävande sätt utan att kvalitén försämras? Jag kommer att använda mig av de resultat jag uppnår i denna undersökning för att ta fram Personas för SPV:s interna användare Syfte Syftet med denna uppsats är att undersöka hur Personas framställs och hur metoden kan användas för att resultera i mer nyanserade Personas. Att därefter studera hur metoden på ett mindre tidskrävande sätt kan användas tillsammans med en traditionell systemutvecklingsprocess tillhör också mitt mål. Jag hoppas att resultatet av denna uppsats ska vara ett bidrag till hur systemutvecklingsprocesser kan förbättras Förväntat resultat Detta examensarbete hoppas jag skall leda fram till hur Alan Coopers metod kan användas för att ge mer nyanserade Personas genom en mindre tidkrävande process. Samt hur en kombination mellan denna metod och en traditionell systemutvecklingsprocess skulle kunna se ut. Det ska även resultera i framtagandet av Personas för SPV som sedan förhoppningsvis kommer att vara ett redskap i deras interna systemutveckling Avgränsning I det här arbetet har jag tänkt att genom en enkätundersökning ta reda på vilka Personas som kan vara aktuella för SPV i deras utveckling av interna system samt hur dessa kan användas i en användarcentrerad systemutvecklingsprocess. Jag kommer inte att studera huruvida Personas metoden är bättre eller sämre än andra metoder och inte heller vilka andra metoder som skulle vara lämpliga för just SPV. 6

7 1.5. Generalisering, intressenter och målgrupp Jag hoppas att resultaten av detta examensarbete kommer att vara användbart för SPV i deras utvecklingsprocess. Om uppsatsen dessutom skulle resultera i bra idéer gällande hur Personas kan användas på ett bra sätt inom användarcentrerad systemdesign tror jag att den kan vara intressant även i ett större sammanhang. Eftersom SPV och deras användare har huvudrollen i denna studie är de också min målgrupp. Jag hoppas dock att även Sigma Pleon kommer att ha glädje av resultatet om det leder till bra idéer om hur Personas kan underlätta arbetet i systemutvecklingsprojekt Disposition Dispositionen för denna uppsats ser ut på följande sätt: Kapitel två beskriver vilken metod som har använts för att uppnå de resultat som senare presenteras. Kapitel tre presenterar resultaten av litteraturstudien. Kapitel fyra redogör för enkätundersökningen. Kapitel fem är resultatet av en diskussion som har förts med utvecklare på Sigma Pleon rörande hur en kombination mellan RUP och Personas skulle kunna fungera. Kapitel sex är en analys av det resultat jag kommit fram till i denna uppsats. Kapitel sju redogör för mina egna tankar kring resultatet. Kapitel åtta är en sammanfattning av resultatet. Kapitel nio tar upp områden jag ser som intressanta för framtida forskning. Kapitel tio ger några korta kommentarer angående de källor som uppsatsen grundas på. Slutligen presenteras referenser och bilagor. 2. Metod Jag har i detta arbete gjort en litteraturstudie om Personas för att få en teoretisk bakgrund och insikt i ämnet. Den litteratur jag har utgått ifrån är Allan Coopers bok The inmates are running the asylum (Cooper 2004) som beskriver metoden, samt några vetenskapliga artiklar inom området där metoden diskuteras. Jag gjorde sedan en enkätundersökning för att få information om vilka slags användare som finns bland SPV: s handläggare. Utifrån resultaten av denna enkät skapade jag grupperingar av användare varifrån jag sedan identifierade vissa karaktärsdrag som är vanligt förekommande hos SPV: s handläggare. Dessa egenskaper fick sedan ligga till grund för skapandet av tre Personas. Jag har också diskuterat metoden med Sigma Pleons konsulter för att få deras åsikter om detta sätt att arbeta i en systemutvecklingsprocess. Slutligen kommer jag att analysera de resultat som framkommit och förhoppningsvis nå några slutsatser Enkätkonstruktion För att göra en kartläggning av SPV: s användare har jag använt mig av en enklare enkät som delades ut till den aktuella användargruppen; handläggarna. I denna enkät ställde jag frågor 7

8 rörande datorvana och inställning till datorer och teknik. Under utformningen av denna enkät gjorde jag vissa antaganden. Min egen erfarenhet och förförståelse säger mig att det är skillnad på att endast använda dator i arbetet och att använda den i hemmet för privat bruk. Om jag ser till mig själv så är det sällan jag för en diskussion eller ett resonemang där inte datorer, Internet eller IT på något sätt är involverat, även om kopplingen inte alls är uppenbar så finns den ändå ofta där. Detta tror jag bottnar i att min generation har levt med denna teknik under i stort sett hela vår uppväxt och att använda datorer i hemmet har blivit en självklarhet. Jag tror att en person som endast använder en dator för att klara sina arbetsuppgifter kanske bara använder de program som behövs för att lösa dessa. Om så är fallet har en person som använder datorer för privat informationssökning och allmän surfning antagligen större erfarenhet och känner sig kanske också mer hemma på datorer. Jag tror också att det finns skillnader hos personer som använder datorn i hemmet. En person som har en dator hemma och använder den dagligen för att göra enbart bankärenden får inte samma breda kunskap om vad en dator kopplad till Internet kan användas till. En person som däremot använder sin dator i hemmet för även andra ändamål som informationssökning till exempel får en bättre datorvana och större erfarenhet. Dessa antaganden grundar jag delvis på de problem vi ofta stöter på när det gäller Internetanvändning. Jag syftar här på de säkerhetsvarningar, förfrågningar om uppdateringar och installationer och andra pop-ups som kan dyka upp när vissa webbsidor besöks. Jag menar att Internetanvändning utöver säkra sidor, som till exempel bankens hemsida, leder till erfarenhet av dessa typer av problem vilket gör att vi känner oss säkrare i vår användning av datorer och Internet Bortfallsanalys Jag anser att svarsfrekvensen var relativt hög i min enkätundersökning. 109 enkäter skickades ut till handläggare på SPV varav 83 personer svarade. 10 personer kunde inte svara på grund av frånvaro. Jag menar att dessa 83 svar är tillräckligt för att jag ska kunna bilda mig en uppfattning om användarna hos SPV. Jag räknar med en viss avvikelse från verkligheten då frågor kan misstolkas eller vara för känsliga Urvalet av användargrupper När jag skapade användargrupper utifrån de resultat enkäten gav gjorde jag vissa urval. Jag valde att utgå från de åldersgrupperingar som svarsalternativen gav, av den anledningen att dessa indelningar verkar ha varit bra brytpunkter när det gäller relation till datorer. Det vill säga, efter att ha gjort en analys av svaren insåg jag att personer inom samma åldersgrupp hade givit liknande svar när det gäller frekvensen av datoranvändning. En av dessa åldersgrupper: 25 år eller yngre har jag dock inte tagit med då endast två personer angivit denna åldersgrupp. Jag har därefter sett till resultaten på frågan hur ofta dator används i hemmet. Detta för att jag misstänker att just denna aspekt speglar vilken syn vi människor har på datorer. I denna fråga har det också i alla åldersgrupper funnits en klar majoritet. I åldergruppen var majoriteten, som väntat, mer vana vid att använda dator i hemmet och i de två äldre åldergrupperna var det däremot fler som aldrig eller sällan använde dator i hemmet. 8

9 2.4. Arbetsgång Samarbetspartner i detta examensarbete har varit SPV och Sigma Pleon. Vi hade vårt första möte redan i november och har sedan dess haft regelbunden kontakt. När mitt arbete med denna uppsats började på allvar tog vi tillsammans fram fyra faser: 1. En enkätundersökning bland SPV: s handläggare. 2. Nyanserade Personas lämpliga för SPV: s systemutveckling. 3. Dessa Personas presenterar jag sedan för utvecklare på Sigma Pleon för att få kommentarer angående hur dessa kan kommuniceras i en användarcentrerad systemutvecklingsprocess och hur metoden Personas kan göras mer tidseffektiv. 4. Analys av materialet. 9

10 3. Personas Den fiktiva användaren Detta avsnitt kommer att ägnas åt Alan Coopers koncept Personas (Cooper 2004) som är en metod för användarmedverkan inom systemutvecklingsprocesser. Jag börjar med att presentera Coopers egen litteratur om metoden och går sedan vidare med några vetenskapliga artiklar som kritiserar metoden Vad är Personas? Det mest uppenbara sättet att integrera användare i en systemutvecklingsprocess är kanske att låta henne vara med i utvecklingen samt även vara målet för designen. Enligt Allan Cooper tenderar dock den verklige användaren att ibland fokusera på detaljer som i det tidiga skedet av utvecklingen inte är det mest väsentliga. Dessutom menar han att även om användaren är den som faller offer för eventuella problem som finns i nuvarande system innebär inte det att hon är den som bäst kan se en lösning på dem. Cooper menar att det finns andra, bättre sätt att genomföra användarcentrerad systemdesign. Att använda sig av fiktiva användare som mål i designen istället för verkliga användare är enligt Cooper en bättre lösning. Han har därför skapat konceptet Personas. Personas går ut på att information samlas in om de verkliga användarna som sedan ligger till grund för skapandet av ett fåtal fiktiva användare; Personas. Var och en av dessa Personas representerar sedan varje typ av användare som finns i organisationen. Enligt Cooper är termen användare inte specifik nog för att kunna beskriva vilken person det rör sig om. En Persona däremot är en mycket specificerad fiktiv användare som speglar de karaktärsdrag som finns hos de aktuella användarna. Cooper menar också att termen användare är för elastisk, enligt honom står begreppet för någon som måste forma och anpassa sig till de förutsättningar som finns när det gäller mjukvara när det egentligen är mjukvaran som ska formas och designas efter användaren. Ju mer specifika Personas blir, ju mer förlorar de sin elasticitet och tvingar utvecklaren att hela tiden vara medveten om vem han designar för. När ett designteam inte har specifika uppgifter om vem de utvecklar för utan bara har som mål att ta fram ett system för användarna sker designen ofta utifrån programmerarens perspektiv. För att underlätta ytterligare i frågan att hålla rätt fokus och perspektiv ska hela designteamet använda sig av namnen på de Persona de designar för i sin kommunikation sinsemellan. Ett annat ofta förekommande fel i utveckling av IT-system är att utvecklingen sker med köparen i åtanke och inte användaren. Den risken elimineras när designen sker för en Persona. Cooper menar också att stereotypa Personas kan vara en fördel på så sätt att de ger en större tilltro till en Persona. Känner vi igen stereotypen är det lätt att förhålla sig till den, med detta menas inte att stereotypen behöver vara sann. Det är viktigare att en Persona är detaljerad än att den stämmer överens med verkligheten. De scenarier som skapas runt denna Persona måste dock vara faktiska. Enligt Cooper är det farligt att fastna i tankar angående vilka scenarier som kan vara möjliga, utan endast utgå ifrån de som kommer att äga rum. Om slutanvändaren aldrig kommer att vilja använda systemet för att skriva ut dokument så behöver inte heller den funktionen finnas. Det är det som skiljer design för en specifik person ifrån att designa för vem som helst. I en utvecklingsprocess är det också mycket fördelaktigt att ta fram Personas för vilka slags användare designen inte sker. Handlar till exempel utvecklingen om ett system för experter så kommer inte noviser att finnas bland användarna vilket utesluter många funktioner såsom förenklade hjälpavsnitt till exempel. Om det 10

11 program/system som ska utvecklas kommer att användas av allt ifrån data- och teknikexperter till fullkomliga amatörer bör utvecklingen ske utifrån amatörens perspektiv. Det är alltså den Persona som gestaltar de som inget kan om datorer som ska styra. Detta är dock en svår balansgång, att designa för nybörjaren utan att tråka ut den erfarne. (Cooper 2004) 3.2. Hur kan Personas utformas? Grunden för bra Personas vilar på en noggrann undersökning av de aktuella användarna. (Goodwin, K. (2001)) Denna görs genom personliga intervjuer för att få en klar bild över vilka personligheter som finns inom användargruppen. Med hjälp av dessa intervjuer fångas sedan beskrivningar upp och bildar några Personas som från och med detta ögonblick är målet för designen. Dessa Personas beskrivs noga med hjälp av beteende mönster, mål, färdigheter och attityder. En av dessa utformas med särskild noggrannhet och blir en så kallad primär Persona. Goodwin menar att det är enkelt att utarbeta en samling karaktärer och kalla dem Personas men att det däremot inte är en enkel uppgift att arbeta fram Personas som verkligen är effektiva verktyg i en designprocess. (Ibid.) 3.3. Personas på gott och ont Vad säger andra forskare och författare om Alan Coopers Personas? Här tar jag upp några av de för- och nackdelar som uttrycks angående metoden Fördelar I Personas: Practice and Theory (Pruitt och Grudin, 2003) menar författarna Pruitt och Grudin att metoden Personas leder till en fokusering på användarna och det arbete som ska utföras å deras vägnar. De menar också att i och med användandet av denna metod får utvecklingsteamet mycket klart för sig vilka de utvecklar åt. När väl en uppsättning Personas har etablerats kan kommunikationen inom utvecklingsteamet ske på helt nya grunder. Istället för termen användaren används nu istället namnet på en Persona; till exempel Vad skulle Alan säga om den här lösningen. Att på detta sätt kommunicera en verklig persons mål och önskningar menar Grudin och Pruitt ger en mycket tydlig förståelse för vad slutanvändaren har för förväntningar på systemet. Slutligen poängterar de också att användningen av Personas ger en tydlig bild av vilka designen sker för och lika viktigt vilka den inte sker för. (ibid.) Nackdelar De risker Pruitt och Grudin ser med Personas är att stor vikt läggs vid att de Personas som används i utvecklingsprocessen på ett bra sätt representerar de verkliga användarna. (Pruitt och Grudin, 2003) Det vill säga, när Personas väl är framtagna så spelar de en betydande roll i utvecklingen. Om de inte skulle skildra användarna på ett korrekt sätt så snedvrids hela designen. En annan risk kan vara att det är lättsamt att återanvända tidigare framtagna Personas i en ny utvecklingsprocess. Detta kan leda designen fel då olika användare och produkter har olika mål. Författarna varnar också för en överanvändning av Personas. Trots 11

12 att detta är ett mycket användbart hjälpmedel så anser de att övriga användarcentrerade utvecklingsmetoder inte får glömmas bort. (ibid) En aspekt som Olsen (Olsen, 2004) kritiserar är att Personas ofta blir för diffusa och saknar de detaljer som skulle göra dem lämpliga som mål under systemutvecklingen. Han menar också att Personas ofta har ett för smalt fokus vilket leder till att de inte kan identifiera den information som utvecklaren behöver. Personas säger heller inte något om de emotionella aspekter som spelar in och gör att vi människor vill ha en viss produkt. Olsen menar att dessa tveksamheter gör Personas till en checklista mer än till ett användbart verktyg. Han pekar också på att många utvecklingsprojekt har försökt sig på metoden vilket ofta har resulterat i misslyckande. En orsak till detta menar Olsen kan vara att Alan Cooper i sin litteratur om Personas redogör tydligt varför Personas är ett bra och viktigt hjälpmedel i systemutvecklingsprocesser men tillhandahåller inte tillräckliga detaljer om hur Personas skapas. (ibid.) Nielsen (Nielsen 2002) pekar i denna artikel på att användarscenarier sällan presenterar användare som levande karaktärer. Hon delger att när hon först började studera och arbeta med scenarier så var användarna i bästa fall beskrivna som stereotyper som lockade till skratt, men många gånger existerade de inte som mer än ett namn. Hon menar att det är omöjligt att förutse mål och handling hos en användare när ingen information presenteras om denne. Enligt Nielsen har Cooper en för inskränkt syn på vad som utgör en människa och vilka skillnader och likheter som finns mellan olika personer. Hon menar att vi människor är så mycket mer än våra mål. För att ett scenario ska leda till insikt i och lösningar till användarens problem krävs en mycket djupare och mer definierad bild av vem användaren är. Nielsen jämför utarbetande av scenarier med författande av filmmanus där en rollfigur med tillhörande karaktärsdrag måste sättas på papper. Det måste vara en rollfigur som läsaren av manuset anser är trovärdig och vars handlingar har sitt ursprung i figurens personlighetsdrag. På samma sätt måste läsaren av ett scenario kunna föreställa sig användaren, hennes handling och motiven bakom dessa handlingar. Nielsen vill beskriva användaren som en rounded user (Nielsen 2002 s 103) istället för den stereotypa användarrepresentant hon anser Personas vara. Med rounded user menar Nielsen att egenskaper som olika karaktärsdrag, psykologiska, fysiska och sociologiska faktorer samt inre behov och mål ska spela en större roll hos användaren som beskrivs. Hon anser att genom att beskriva användaren på detta sätt skapas bättre fokus i designen. Det hjälper designteamet att engagera sig i användaren på ett mer deltagande sätt vilket leder till att designen styrs mot rätt mål, det vill säga användaren. (ibid.) 12

13 4. Enkätundersökning I denna undersökning användes ett webbaserat enkätverktyg vilket innebär att sammanställning av svaren har gjorts per automatik och ingen annan än jag har gått igenom resultatet. Den enkät som besvarades finns att studera i bilaga 1. Enkäten som skickades ut till handläggarna på SPV syftade till att beskriva vilka användargrupper som finns på den aktuella avdelningen. I enkäten ställdes frågor angående utbildning, fysiska handikapp, frekvens av datoranvändning på arbetet och i hemmet, ändamål för Internetanvändning samt inställning till datorer. Totalt besvarades 83 enkäter (vilket motsvarar en svarsfrekvens på ungefär 76 %) och i detta avsnitt presenteras resultatet Resultat av undersökningen Gemensamt för alla deltagare i denna enkätundersökning är att de använder sin dator hela dagen på arbetet. Detta gör att datorvana finns hos alla undersökta personer. Det som däremot varierar väldigt är användandet av datorer i hemmet. Här syns en tydlig skillnad mellan åldersgrupper. Något som inte verkar ha stor betydelse för huruvida datorer används i hemmet eller vilken inställning som uppvisas gentemot teknik är utbildning. Här hade jag förväntat mig en skillnad mellan personer som har läst en IT-inriktad utbildning och de som inte läst någon datorrelaterad utbildning. Min uppfattning är att en person som har studerat ITrelaterade utbildningar har valt detta av en anledning och därför kanske ett större intresse för datorer också finns. På frågan Hur ser du på datorer? svarade två personer Det är ett nödvändigt ont men jag måste använda datorer på arbetet och i hemmet. Hos dessa personer finns också en vilja att lära sig mer om datorer för att de ska känna sig säkrare i sitt arbete samt att kunna använda sig av datorer för privat bruk. Två andra har på frågan om synen på datorer svarat Det är ett nödvändigt ont som jag skulle undvika om det inte ingick i arbetet. Dessa två anser sig dock klara sig bra med de kunskaper de har idag. Av alla personer som svarat på enkäten anser bara sex att de har mycket goda kunskaper om datorer. Av dessa personer hör fem till åldersgruppen år och frekvensen av datoranvändning i hemmet är mycket hög. De kommentarer jag fick i enkäten var följande: Det är roligt att använda datorer. Jag anser att jag klarar mig med de kunskaper jag har idag. Men det är alltid bra att lära sig mer. De åldersgrupperingar jag använde som svarsalternativ blev grunden till de användargrupperingar jag har skapat. Följande användargrupperingar kunde urskiljas ur enkätresultatet: 25 år. Använder inte dator i hemmet i någon större utsträckning. De anser sig ha goda kunskaper om datorer och brukar kunna lösa de problem som kan uppstå på egen hand. Denna grupp innehåller dock endast två personer vilket gör att jag bortser från dessa i min fortsatta analys. Detta av den anledningen att jag anser att det är svårt att uttala mig om en grupp med så få personer år. Här finns en ganska jämn fördelning av personer som använder dator i hemmet och de som inte gör det. Det är dock en majoritet som använder dator i 13

14 hemmet. De flesta anser sig ha relativt goda kunskaper om teknik och datorer och ser datorn som ett bra hjälpmedel år. I den här gruppen är frekvensen av datoranvändning i hemmet väldigt låg. Endast två personer använder dator ofta i hemmet. De anser sig dock ha relativt goda kunskaper när det gäller datorer och ser datorn som ett bra hjälpmedel. 45 år eller äldre. I denna grupp är antalet personer som använder dator i hemmet minimalt. De flesta har ingen dator alls, eller använder den väldigt sällan. Här finns också fler med nedsatt hörsel eller syn än i de yngre grupperna Från handläggare till Persona Här presenterar jag de förslag till Personas jag har skapat med hjälp av min enkätundersökning. Dessa Personas är grundade på den informationen om datoranvändning och inställning till datorer jag kunde utläsa bland enkätsvaren. Alla eventuella likheter med handläggare på SPV när det gäller namn, personlighet, intressen och så vidare är slumpmässiga. Följande Personas kunde uppdiktas med hjälp av enkätresultaten: Lars är en 27 årig singel som bor i en insatslägenhet i centrala Sundvall. Han har arbetat som handläggare på SPV i fem år och har idag kronor i månadslön. Lars har tidigare haft ett liknande arbete i fyra år och trivs bra med denna typ av arbetsuppgifter. Han använder dator hela dagen på arbetet och när han är hemma spelar han mycket, till exempel World of Warcraft, Heroes of Might and Magic och andra strategispel. Detta intresse har gjort honom mycket kräsen när det gäller layout och design och han ställer höga krav på dessa bitar hos informationssystem. När han inte använder datorn till att spela utför han bland annat bankärenden, söker information för olika ändamål eller helt enkelt nöjessurfar. Han har mycket goda kunskaper om datorer och teknik och klarar av installationer av både mjukvara och hårdvara. Lars ser datorer som ett mycket bra hjälpmedel i sin vardag och känner inget behov att utöka sina kunskaper. Något Lars inte kommer överens med är dagens vanliga operativsystem. Han anser att för mycket av datorns prestanda går åt till att köra ett system vars enda mål, enligt honom själv, är att behaga så många användare som möjligt. Detta har resulterat i en oändlig rad funktioner och ljud som inte gör någon nytta alls anser Lars. Han menar också att leverantörer av mjukvara ofta är så ivriga att få ut nya system på marknaden att de inte testas grundligt innan de går till försäljning, vilket leder till att systemet ofta behöver uppdateras för att fungera tillfredsställande. Anna är 43 år och jobbar även hon som handläggare på SPV sedan 25 år tillbaka. Hon har i månadslön och har inte haft något liknande arbete innan. Hon använder nästan aldrig dator hemma och när hon använder den till annat än arbetsrelaterade ändamål så gäller det informationssökning och för nöjes skull. Hon anser att hennes kunskaper är tillräckliga men om något händer med datorn så måste hon be om hjälp. Hon anser att datorn är ett bra hjälpmedel som hon använder i sitt arbete men hon kan inte riktigt relatera till den teknik som finns idag och det tempo som utvecklingen har i dessa tider. En situation som kan göra Anna nervös är till exempel när något går fel i programmet hon använder i sitt arbete och hon får upp ett fönster som säger Programmet har utför en förbjuden åtgärd och kommer att avslutas. När hon ser en sådan text känner hon sig mycket illa till mods och drar ofta ur strömkabeln till datorn. Hon muttrar över det faktum att sådant händer alltför ofta och menar att detta är något IT-administratörerna borde se över. 14

15 En äldre dam som vi hittar i det prydligaste rummet på kontoret är Maj, 61 år. Hon anser att den viktigaste uppgiften hennes arbetsdator har är att fungera som blompiedestal, något hon har fått åtskilliga tillsägelser för. Hennes svar har alltid varit: Den där burken är ju så ful att jag inte vill se den! Hon använder dock datorn ganska ofta i sitt arbete men har aldrig tänkt tanken att skaffa en dator till hemmet. Hon har nedsatt syn vilket gör det svårt att se vad som står på skärmen ibland. Hon har på grund av sin dåliga syn fått hjälp med speciella inställningar på sin dator för att underlätta hennes arbete. En morgon när Maj kom till kontoret kunde hon inte utläsa något alls på skärmen. Ett nytt operativsystem hade installerats under natten och hennes inställningar var borta. Detta är inget hon klarar av att göra själv och hon kände sig mycket illa till mods av att behöva söka efter någon som kunde hjälpa henne. Hon har också nedsatt hörsel och har mycket svårt att urskilja de signaler som ibland hörs från datorn. Maj behöver ett gränssnitt med tydliga ikoner och kompatibla färger. Det viktigaste är att systemet är enkelt och funktionsdugligt, fritt från för henne onödiga detaljer. 15

16 5. Användarcentrerad systemdesign och Personas Jens Eriksson och Johan Linder arbetar som konsulter på Sigma Pleon i Sundsvall. De har aldrig använt sig av metoden Personas och känner en tveksamhet inför det faktum att ingen egentlig dialog förs med den verkliga användaren i den här metoden. Enligt Eriksson och Linder är användarmedverkan ett av de viktigaste momenten i en användarcentrerad systemutvecklingsprocess. Att vara ute hos kunden, se hur slutanvändarna arbetar och få insikt i deras arbetsuppgifter och mål är en oerhört väsentlig del i processen. Eriksson och Linder menar dock att en av bristerna med den modell de använder sig av idag, RUP (Rational Unified Process) är att när konsulten väl är tillbaka på kontoret kan det vara lätt att perspektivet förändras. Det blir svårt att hålla fokus på användarnas önskemål och krav vilket kan leda till att konsulten utgår ifrån sig själv. När diskussioner då förs på konsultens kontor rörande funktionalitet är det lätt att det blir Vad skulle vi tycka om den här lösningen istället för, för att använda en av de Personas jag tagit fram, Vad skulle Lars tycka om den här lösningen?. En annan nackdel Eriksson och Linder ser med den traditionella utvecklingsprocessen är att om, som fallet ofta är, beställare och användare inte är samma person händer det att beställarens krav inte helt stämmer överens med de krav som en slutanvändare skulle ställa på ett system. När det gäller dessa problem anser Eriksson och Linder att Personas skulle kunna bidra med viktiga fördelar inom en systemutvecklingsprocess. De är båda övertygade om att metoden som den är faller på att inte innehålla någon användarinteraktion. Hur genomtänkta de fiktiva användarna än är, kan de inte ersätta dialogen med de verkliga användarna. De anser dock att en kombination av dessa två metoder skulle vara mycket fördelaktigt. Genom att metoden Personas arbetar med fiktiva användare som finns med i konsulten dagliga arbete, till exempel i form av bilder uppsatta på väggen på kontoret, så är det lättare att hålla rätt fokus i designen. Att använda denna Persona i all kommunikation som sker i utvecklingsteamet eliminerar risken att glömma bort vilken personlighet de utvecklar för. Det skulle också, enligt Eriksson och Linder, leda till bredare infallsvinklar och rätt nivå på funktioner och gränssnitt. (Samtal med Eriksson och Linder, Sigma Pleon) 5.1. Rational Unified Process RUP Rational Unified Process, härefter benämnd RUP, är en systemutvecklingsmodell framtagen av Rational Software Corporation. Det är en allomfattande modell som kan användas inom många olika områden. Modell går i huvudsak ut på att säkra hög kvalitet på mjukvara och underlätta för projektplanering. Utveckling ska ske enligt användarens behov och hålla tidsoch budgetramar. RUP kan mycket kortfattat beskrivas som en iterativ process som fokuserar på modeller och inte dokument, bygger på best practices 1, tillhandahåller riskhantering och är anpassningsbar för olika projekt. (Apelkrans och Åbom, 2001) 1 De bästa erfarenheterna från modern systemutveckling som: iterativ utveckling, komponentbaserad arkitektur, visuell modellering och kvalitetssäkring. (Power Point presentation, Sigma Pleon) 16

17 5.2. Personas vs. RUP Eriksson och Linder anser att processen för att skapa representativa Personas verkar vara mycket tidskrävande. Det krävs en grundläggande kartläggning av vilka användargrupperingar som finns i verksamheten och intervjuer med representanter ur dessa. Detta är delar som Eriksson och Linder tvivlar på att alla företag är villiga att lägga ned tid och pengar på då det inte ger något direkt synbart resultat för verksamheten. En förenkling av metoden Personas skulle däremot göra den mycket användbar. Ett förslag är att med hjälp av en psykolog ta fram lämpliga frågor till en enkät ämnad att kartlägga vilka användarpersonligheter som finns i en verksamhet. I en sådan enkät är det egenskaper som personlighet, inställning till datorer och teknik samt mål med användningen av informationssystem som är väsentliga att få information om. En sådan enkät kan på ett enkelt sätt skickas ut via e-post till berörda användare och används dessutom ett webbaserat enkätverktyg för detta kan också sammanställning av enkätsvaren ske mycket snabbt. Tanken är då att denna enkät kan återanvändas i alla projekt där en sådan kartläggning är önskvärd. Utifrån enkätresultaten kan vi sedan urskilja vilka användargrupperingar som finns i verksamheten och skapa Personas som representerar dessa. På det här sättet menar Eriksson och Linder att konsulten skulle få en bra överblick över vilka användare som är aktuella i utvecklingen. Här kan också informella ledare urskiljas. Dessa kan vara väldigt viktiga att ha i åtanke under utvecklingsprocessen då de ofta har en förmåga att påverka andra som har till exempel en negativ inställning till förändringar eller datorer. Genom att den traditionella användarkontakten finns kvar finns också möjlighet att revidera dessa Personas under hela utvecklingsprocessen. På detta sätt nyanseras Personas mer och mer och fungerar som bra representanter för användarna. (Samtal med Eriksson och Linder, Sigma Pleon). Enligt Inger Erlander, projektledare på Sigma Pleon, är det dock väldigt beroende på projektets storlek och karaktär huruvida en sådan här kartläggning av användare är nödvändig eller ej. I mindre projekt där systemet som ska utvecklas berör runt 10 användare är detta en onödighet eftersom det i sådana fall ofta inte tar lång tid innan projektledare och utvecklare har lärt känna användarna. Erlander menar dock att det kan vara fördelaktigt att ha två olika metoder för olika typer av projekt. Det är alltid nödvändigt att göra någon typ av målgruppseller användaranalys, men de behöver inte alltid vara så omfattande och avancerade. I större projekt med uppemot 100 berörda användare eller fler kan det vara mycket bra att göra en mer omfattande analys av användargruppen och här kan kanske Personas vara lämpligt. (Samtal med Inger Erlander, projektledare på Sigma Pleon). 17

18 Idag är det som jag tidigare nämnt RUP som används av utvecklarna på Sigma Pleon. Stegen i denna process ser ut enligt följande: De lodräta stegen till vänster kallas discipliner och de vågräta representerar faserna i varje disciplin. Iterationerna ser lite olika ut beroende på projektets storlek och karaktär. För att på ett lämpligt sätt väva in Personas i dessa steg bör kartläggningen av användarna börja så tidigt som möjligt. Den första disciplinen Business Modeling är processorienterad och inriktar sig på verksamheten vilket gör att analyser av användare inte är aktuella i detta steg. Däremot i nästa disciplin; kravfångsten (på bilden benämnd Requirements) är arbetet mer fokuserat på användarna och deras krav på systemet. I begynnelsen av detta steg, som bilden på nästa sida visar, skulle därför denna kartläggning vara lämplig. 18

19 6. Analys Alan Coopers Personas är en metod för att involvera användaren i systemutvecklingsprocesser utan att egentligen göra det. Det handlar om fiktiva Personas istället för verkliga användare. Metoden kritiseras för att skapa stereotyper som är diffusa och saknar de detaljer som behövs för att representera användare på ett bra sätt. Enligt Cooper är det väldigt viktigt vad en användare har för mål med sina handlingar och sitt användande av ett system. Detta kritiserar Lene Nielsen i sin artikel och menar att vi människor är mer än bara de mål vi har i livet. (Nielsen 2002) Hon menar att fler egenskaper måste tillskrivas en Persona för att denne ska vara en bra representant för användarna. Hon pekar på att karaktärsdrag rörande psykologiska, fysiska och sociala faktorer har stor betydelse för hur en människa agerar och varför. (ibid.) Coopers metod innehåller dock även många fördelar som kan underlätta i en systemutvecklingsprocess. (Samtal med Eriksson och Linder, Sigma Pleon) Att använda Personas i kommunikationen utvecklare sinsemellan leder till en fokusering på vem designen sker för. Det skulle leda till ett bredare perspektiv då utvecklare hela tiden tvingas resonera i banor som Vad skulle Lars anse om den här funktionen? eller Skulle Maj med sin nedsatta syn kunna utläsa vad som står i dessa ikoner?. Denna typ av kommunikation ska finnas med i alla beslut som fattas gällande designen av ett system. Gör den det, finns hela tiden medvetenheten om vem som är målet för designen vilket förhoppningsvis kommer att öka chansen till en lyckad lösning. (ibid.) En av riskerna Pruitt och Grudin ser med denna metod är att det kan vara lätt hänt att Personas återanvänds i andra projekt än det projekt de var framtagna för. Detta kan leda till att hela designen sker mot en användare som inte ens finns i verksamheten. (Pruitt & Grudin 2003) Att skapa Personas som alltid fungerar är en omöjlighet då alla människor och organisationer är unika. Att däremot skapa en metod som går att återanvända är möjligt. (Samtal med Eriksson och Linder, Sigma Pleon) Med hjälp av en enkät som kartlägger användarna och ger information om vilka användargrupperingar som finns kan Personas skapas på ett mindre tidskrävande sätt. En sådan enkät kommer inte att resultera i Personas som är mer nyanserade än de som Cooper skapar i sin process. Men genom att väva samman Personas med en traditionell metod där det finns en regelbunden kontakt med de verkliga användarna kommer dock en nyansering att vara möjlig. När Personas är framtagna med hjälp av enkätundersökningen och kontakten med de verkliga användarna fortlöper kan dessa Personas revideras och nyanseras eftersom. Med hjälp av denna enkät kan möjligtvis också informella ledare urskiljas vilka kan vara viktiga att ha i åtanke genom hela utvecklingsprocessen. Att få reda på i vilka användargrupper dessa finns kan ha stor betydelse för projektets framgång. Eriksson och Linder menar att även om de informella ledarna tillhör en minoritetsgrupp bland det totala antalet användare så kan det vara fördelaktigt att fokusera på dem i designen för att deras entusiasm ofta sprider sig till de andra. (ibid.) 19

20 7. Diskussion Idén att använda sig av en mer noggrant utformad enkät anser jag är intressant. Om vi ser till dagstidningar på nätet så är just webbaserade enkäter något som är väldigt populärt. Det är ett enkelt sätt att snabbt göra en opinionsundersökning och jag tror att många människor tycker att det är roligt att delta. Den enkät som är aktuell i detta fall kan givetvis inte jämföras med de frågeformulär som används i nättidningar men idén är densamma. Genom ett webbaserat enkätverktyg sker sammanställning av resultaten automatiskt och utvecklaren kan relativt snabbt bilda sig en uppfattning om vilka användargrupperingar han har att förhålla sig till. Enligt Eriksson och Linder på Sigma Pleon skulle det underlätta för designen om även informella ledare kunde urskiljas på detta sätt. (Samtal med Eriksson och Linder, Sigma Pleon.) Här delar jag deras uppfattning och anser att dessa människor kan vara viktiga att uppmärksamma. Jag är av den åsikten att det finns informella ledare på varje arbetsplats och om dessa personer visar en positiv inställning till ett nytt system eller en annan typ av förändring smittar de ofta av sig på sina mindre entusiastiska medarbetare. När det gäller risken att Personas resulterar i stereotyper anser jag att det finns både för- och nackdelar. Att fastna i ett resonemang som kretsar kring förutfattade meningar om människor och deras vanor är nog farligt i systemutvecklingssammanhang. Det går inte alltid att utgå ifrån sina erfarenheter när det till exempel gäller vad en viss åldersgrupp har för krav på ett system. Även om de förutfattade meningar vi har kanske ofta är korrekta så är alla människor unika och möjligheten finns att en 65 årig gammal dam vill ha utmaningar och flash-detaljer i sitt system. Chansen är kanske inte så stor, men den finns. Om en användargrupp skulle stämma väl överens med de förutfattade meningar som finns kan det kanske vara en fördel om den Persona som ska representera dem är en stereotyp. Med det menar jag att om stereotypen stämmer överens med verkligheten och utvecklarna känner igen den, kan de också relatera till den på ett bra sätt. Men jag är dock kritisk till Personas tendens att representera och förstärka de stereotyper och förutfattade meningar som existerar. Jag anser dock att det ligger mycket sanning i det Alan Cooper uttrycker när han förespråkar Personas. En av de största fördelarna jag ser med metoden är att namnet på en specifik Personas används i kommunikationen utvecklare sinsemellan. Detta tror jag resulterar i att det är lättare att hålla rätt fokus genom hela utvecklingsprocessen. Det blir svårt att glömma bort vem som är målet för designen om till exempel bilder på de Personas teamet använder sig av finns uppsatta på utvecklarens kontor. Att utesluta kommunikation med verkliga användare helt anser jag dock är en negativ sida. Som jag tidigare nämnt så är interaktionen med användarna något jag tror är avgörande för en lyckad systemutveckling. Jag tror inte att en fiktiv användare i form av en Persona kan ersätta den verkliga kontakten. Kombinerat med en traditionell metod tror jag dock att Personas kan ge många fördelar, speciellt när det gäller att få mer nyanserade Personas. När dialogen med de verkliga användarna pågår under hela utvecklingsprocessen ges möjligheten att uppdatera dessa Personas under projektets gång. Jag vill avsluta med att upprepa det citat jag inledde denna uppsats med: Isn t it funny how we never have time to do things right, but somehow we always find the time to do them over? (Wiegers 2000 s 3). Att involvera användare i systemutvecklingsprocesser måste enligt mig få ta tid. Det finns kanske inga genvägar till ett lyckat systemutvecklingsprojekt, bara mer eller mindre tidskrävande alternativ. Jag tror att traditionell användarmedverkan i kombination med Personas kan vara ett bidrag till en lyckad systemutvecklingsprocess. 20

21 8. Slutsats Att metoden Personas har många positiva sidor verkar många konsulter, författare och forskare vara eniga om. Lika eniga är de dock om att det finns negativa sidor. Metoden leder till stereotypa, fiktiva användare som saknar detaljer och är för diffusa. (Pruitt och Grudin, 2003) Konsulter på Sigma Pleon menar också att det inte skulle fungera att driva ett systemutvecklingsprojekt utan kontakt med de verkliga användarna. (Samtal med Eriksson och Linder, Sigma Pleon.) Att använda sig av en väl utarbetad enkät innehållande personlighetsfrågor framtagna av förslagsvis en psykolog skulle innebära att en kartläggning av användarna kan genomföras på relativt kort tid. Utifrån resultatet av denna enkät kan Personas skapas. Om vi sedan kombinerar Personas med exempelvis RUP får vi kanske en mycket användbar metod för användarcentrerad systemutveckling. Att på så sätt växla mellan kontakt med verkliga användare och Personas leder till att vi hela tiden har möjlighet att revidera våra Personas om det skulle visa sig att de inte håller måttet. Detta skulle resultera i mer nyanserade Personas som på ett bra sätt representerar användaren. Väl ute hos kunden finns kontakten med slutanvändaren och tillbaka på konsultens kontor finns en representant för denna upphängd på väggen i form av till exempel Lars, Anna eller Maj. På detta sätt elimineras också risken med att programmeraren tappar fokus och börjar designa från sitt eget perspektiv istället för användarens. (ibid.) 21

22 9. Framtida forskning Jag har i denna uppsats tagit fram förslag på Personas för SPV med hjälp av en enkätundersökning. Dessa ska dock inte ses som definitiva eftersom de är tänkta som exempel på Personas som senare bör nyanseras genom den kombination av metoder jag tidigare har diskuterat eller kompletteras med hjälp av intervjuer. Detta är något som skulle vara väldigt intressant att gå vidare med vid ett annat tillfälle. På så sätt skulle jag kunna se om mina antaganden angående datoranvändning i hemmet stämmer genom att ta reda på närmare vilka bakomliggande orsaker som finns till att inte använda datorer för privat bruk. Mest intressant skulle dock vara ett eventuellt samarbete med en psykologistuderande för att ta fram lämpliga frågor för en enkät som skulle kunna användas i den kombination av Personas och RUP som jag har beskrivit. 10. Källkritik Jag anser att de källor jag använt mig av är pålitliga. Eftersom arbetet handlar om Personas har Alan Coopers litteratur givetvis varit en viktig källa. En källa som av uppenbara anledningar inte kritiserar denna metod på något sätt. Detta anser jag dock har kompenserats av de vetenskapliga artiklar som uttrycker både fördelar och nackdelar om metoden. När det gäller mina Internetkällor känns även de tillförlitliga. 22