Pensionsplanering Ett projekt planerat utifrån Contextual design

Transkript

1 UPPSALA UNIVERSITET Projektrapport Institutionen för informationsteknologi Användarcentrerad systemdesign 5p Pensionsplanering Ett projekt planerat utifrån Contextual design Carl Christiansen Joakim Severinsson Peter Sidenbladh

2 Innehållsförteckning Contextual Design enligt Beyer och Holtzblatt... 3 Genomförande av det användarcentrerade arbetet... 4 Vårt projekt...4 Steg 1 Contextual Inquiry Användningssammanhangsbaserade undersökningar...4 Steg 2 Interpretation sessions & Work models Tolkning av resultaten till arbetsmodeller...6 Steg 3 Data consilidation Sammanslagning av data...7 Steg 4 Vision & Storyboards...9 Steg 5 User Enviroment Design...10 Steg 6 Paper prototyping pappersbaserat prototyparbete...11 Avslutning...11 Tidplan...12 Diskussion

3 Contextual Design enligt Beyer och Holtzblatt Contextual Design är en process för systemutveckling utifrån ett användarcentrerat synsätt som utvecklats av ett flertal personer under en längre tidsperiod. Det är en modell som bygger på samlade erfarenheter från många typer av uppdrag och problem som sammanställts av Beyer och Holtzblatt. Enligt författarna är contextual design en modell som genom att verkligen förstå hur användarna arbetar ger möjligheten att hitta de optimala vägarna för att utföra detta arbete med hjälp av nya verktyg och arbetssätt. Mycket fokus ligger på hur man ska kunna få så omfattande data som möjligt om hur arbetet fungerar innan man börjar titta på hur ett system för området bör fungera. I fokus under hela utvecklingsprocessen ligger sedan dessa data. Utöver modeller för insamlande av data finns även arbetssättet för att hantera dessa data noggrant beskrivet i litteraturen. Regler för hur möten ska genomföras och hur man kan använda sig av olika modeller för att beskriva problemen för att optimalt kunna lösa dessa gås igenom. I början av boken ger författarna en sammanfattande bild av de steg som utgör deras process. Det första steget är att förstå användarnas behov, önskemål och arbetssätt genom omfattande intervjuer på arbetsplatsen. Detta följs av att utarbeta modeller för den information man samlat in under dessa intervjuer. Nästa steg är att använda speciella tekniker för att slå samman uppgifter från olika delar av den totala gruppen användare i systemet till en gemensam bild. Med tillgång till all denna behandlade data börjar nu själva arbetet för att förändra arbetsprocessen till en mer effektiv sådan med hjälp av bland annat storyboards. Mot slutet av processen utvecklar man nu användarmiljön, detta innebär inte en grafisk design utan strukturen för hur användarens miljö ska fungera. Det sista steget är sedan tester av prototyper mot användaren där resultatet används för att utforma ett effektivt UI. Beyer och Holtzblatt är noga med att påpeka att deras modell inte är tänkt att följas slaviskt utan måste alltid anpassas efter det projekt som genomförs. Grundmodellen är tänkt för stora och komplexa system, men har enligt författarna effektivt används även i mindre projekt. Genom att sätta fokus på olika delar och att minska eller ta bort andra delar kan processen förändras så att den kan användas för flera olika typer av projekt. Hur man ska gå tillväga för att göra detta beskrivs även det i boken. En viktig del av systemutveckling som behandlas av Beter och Holtzblatt är hur de grupper som är involverade i utvecklingen sätts samman. Författarna menar att det är av yttersta vikt att kunna föra in många olika typer av grupper och personer i utvecklingsarbetet för att kunna optimera de system som byggs. 3

4 Genomförande av det användarcentrerade arbetet Beyer och Holtzenblatt går i boken igenom de steg som bör ingå i en användarcentrerad systemutveckling enligt deras modell. Dessa ska sedan naturligtvis anpassas till de förutsättningar som gäller för det aktuella projektet. Nedan går vi igenom dessa steg utifrån vårat projekt med ett pensionsplaneringsverktyg. Inom varje steg kommer vi att redovisa orsakerna till att de nämnda åtgärderna bör genomföras och hur vi planerar att dessa borde genomföras i vårt projekt. Innan dessa steg beskrivs beskriver vi översiktligt vårt projekt och generella antaganden vi gjort om detta. Vårt projekt Pensionsplanering är något som innebär att användaren måste använda sig av flera olika system för att kunna se hur mycket deras pensionssparande för närvarande uppgår till. För att kunna skapa ett system som gör just detta krävs kunskap om hur användare vanligtvis går tillväga för att kontrollera sin pension, hur nuvarande system används. Ett system som samlar alla olika pensionsformer, presenterar saldon på ett överskådligt sätt och möjliggör för användaren att göra ändringar på ett enkelt sätt skulle inneböra en stor förbättring. Flera olika användargrupper kan direkt identifieras. Den första är privatpersoner som kontrollerar sitt saldo, byter sparform eller fond och så vidare. En annan kan vara personer inom banker och försäkringsbolag som administrerar konton för kunders räkning. En tredje kan vara personer (utan teknisk kompetens men med ekonomisk) som utför underhåll på systemet: tillägg av nya fonder, uppdatering av information, felavhjälpning med mera. Steg 1 Contextual Inquiry Användningssammanhangsbaserade undersökningar Ett stort problem i systemutveckling är att man inte har tillräckligt bra förståelse för användarnas önskemål och hur de uppgifter som systemet ska ersätta utförs idag. Det första steget i en användarcentrerad systemutveckling är naturligtvis att grundligt undersöka detta. Beyer och Holtzenblatt har utvecklat ett antal modeller för att genomföra intervjuer med användarna på deras arbetsplatser utgående ifrån vilken typ av system man utvecklar. Beyer och Holtzenblatt utgår från en modell enligt mästare/lärling. På samma sätt som en lärling lär sig från sin mästare ska de som designar ett system lära sig från användarna. Eftersom användare, i de flesta fall, inte är vana lärare kan det finnas mycket att vinna på att låta dessa lära ut sitt arbetssätt genom att helt enkelt utföra det. Fyra principer inom contextual inquiry sätts upp av Beyer och Holtzenblatt. Dessa fyra principer visar på olika aspekter av detta sätt att intervjua användarna och gör 4

5 det möjligt att utforma modellen utefter det specifika projektet. Dessa fyra principer är sammanhang, partnerskap, tolkning och fokus och beskrivs kortfattat nedan. Den första, sammanhang bygger på att undersökningen skall bedrivas i den miljö användaren vanligtvis arbetar. Man vill uppnå en förståelse för miljö och användarens situation. Genom att göra så kommer man runt problemet med att personer i efterhand har svårt att redogöra för mer än ett fåtal detaljer om hur deras arbetsprocess går till, vilket är svårt att överkomma om man i efterhand intervjuar användare. Princip nummer två, partnerskap utgår från mästare/lärlingsmodell beskriven ovan. Detta angreppssätt skiljer sig från hur en normal intervju går till, där intervjuaren kan uppfattas vara den som står för kunskapstyngden. En skillnad mot hur en vanlig lärling agerar är att intervjuaren här till viss del styr sin mästare och ber om klargörande av vissa detaljer och för ned beskrivningen på en konkret nivå. Det som eftersträvas en beskrivning av vad som sker för tillfället, inte en summering av det som skett. Princip nummer tre, tolkningen handlar om att kontrollera med användaren att den tolkning man gjort angående användarens arbete stämmer med användarens egen uppfattning. Under arbetets gång skapar man som lärling hypoteser om hur arbetets processer hänger ihop. Dessa arbetas samman till designidéer. Dessa testas allt eftersom mot användaren och felaktigheter kan direkt förkastas. Den fjärde och sista, fokus behandlar det sätt en lärling intellektuellt angriper problemet. Om nya eller motsägande data dyker upp bollas detta direkt med intervjupersonen. På detta sätt motverkas att missuppfattningar och fördomar färgar det sätt designen löser problemet. Förhoppningsvis blir designen den bästa tänkbara. Varje projekt som rör kommersiella produkter kan enligt Beyer och Holtzenblatt ha tre olika utgångspunkter som är styrande för hur detta steg av utvecklingen genomförs. Antingen rör det sig om en ny produkt, en ny domän eller ny teknik. Om det är ett ITprojekt anses det falla i någon av grupperna, uppgradering, nytt system eller process redesign. Hur uppgiften utförs idag är naturligtvis också den av stor betydelse för hur intervjun ska utföras. Olika arbetsuppgifter delas av Beyer och Holtzblatt upp i normala, ovanliga, oavbrytbara, extremt långa, extremt fokuserade och interna. Den avslutande punkten inom detta steg är att göra ett bra urval av användare att intervjua. Ett antal olika roller som användare kan hamna i identifieras. Beyer och Holtzenblatt anser att två eller tre personer ur de olika rollerna bör intervjuas. När valet görs skall man tänka på att användarna som väljs bör vara så olika som möjligt för att hålla variationen på en hög nivå. 5

6 Vi anser att vårt projekt är ett IT-projekt och faller in under gruppen process redesign. Vidare anser vi att de olika arbetsuppgifterna som de olika användarrollerna ska utföras kan föras in under följande kategorier Privatpersoner: Ovanliga Bank-/försäkringsbolagsanställd: Normala Underhållsansvarig: Interna För att genomföra denna del av projektet enligt Beyer och Holtzenblatts process bör arbetet strukturera enligt följande: Inledningsvis väljs två till tre personer ut inom respektive kategori. Varje person får en introduktion och en förklaring av vad som kommer att ske under intervjun. Viktigt här är att betona skillnader gentemot hur en normal intervju går till. När detta är klart görs det klart att från och med nu jobbas det enligt mästare/lärling konceptet och själva undersökningen kan ta sin början. Direkt när intervjuaren upptäckter någon oklarhet avbryts användaren för förklaring, följt av att användare så smidigt som möjligt kan återgå till arbetet. Detta tar ett antal timmar, kanske två till tre. När lärlingen känner sig fullärd rundas det hela av med att man under femton minuter summerar de observationer som gjorts. Den intervjuade får då ännu en chans att korrigera felaktigheter och missuppfattningar. Processen upprepas sedan på alla inblandade. Steg 2 Interpretation sessions & Work models Tolkning av resultaten till arbetsmodeller Efter att alla intervjuer är slutförda går man över till att tolka det som observerats och skapa heltäckande modeller för hur arbetet egentligen bedrivs. Eftersom de olika användarna troligen intervjuats av en person är det också viktigt att resultaten sprids till alla som kommer att vara sysselsatta med projektet. Systematiskt går man igenom respektive intervju med alla i projektet, ritar arbetsmodeller och frågeställningar. I detta skede upprättas ett kort för varje enskild delmodell som påträffas. Dessa kort upprättas fortlöpande utan att någon egentlig värdering läggs i om de stämmer eller inte. Med tiden bör detta ge en samfälld syn på hur arbetet går till och vilka uppgifter projektet skall lösa. Alla kan lättare förstå de data som inhämtats, även om de själva inte var med under intervjun. Det är otroligt viktigt att gruppen som skall utveckla systemet har fullständig förståelse för de rutiner användaren är van vid, lokala avvikelser och annat som kan påverka hur systemet i slutändan skall vara utformat. Detta är en del som kommer och måste få ta tid då det i slutändan sparar tid och pengar i form av insparat förändringsarbete när utvecklingen av systemet väl kommit igång. När en utbredd förståelse för hur systemet fungerar är på plats är nästa steg att ta fram en mer konkret bild av hur arbetet är organiserat, detta baserat på all information från intervjuerna. Enligt Beyer och Holzblatt finns det fem arbetsmodeller som var och en beskriver en syn på hur det ligger till. Sammantaget ger de en relativt heltäckande bild och de går ibland in i varandra. 6

7 Den första modellen, flödesmodellen behandlar hur arbetsflödet går till och hur olika användare interagerar med varandra, i alla de olika roller en användare kan uppträda. All interaktion behöver inte vara via formella kanaler utan kan mycket väl vara via informella, av ledningen inte planerade kanaler. Modellen försöker kartlägga alla användarroller och hur de kommunicerar med andra. Modell nummer två, sekvensmodellen behandlar i vilken ordningen användare utför olika steg under det att de löser en arbetsuppgift. Syftet är att ge en överblick över stegen och ge möjlighet att ta bort onödiga steg. En stor svårighet är att det blir svårt att veta vilka steg som är viktigare än andra att förenkla för användaren. I modell tre, artefaktmodellen är en sammanställning och förklaring av de artefakter som påträffats under intervjuerna. Strukturen, informationsinnehållet, adderad informell information (t ex post-it-lappar) och hur artefaktens information är presenterad är viktiga faktorer. Tanken är att få ett grepp om dem i syfte att kunna efterlikna dem i systemet. Om de har en motsvarighet i systemet tas troligen användarna det lättare till sig och de behöver inte komplettera systemets funktionalitet med att fortsätta använda sig av de befintliga artefakterna. En klar risk här är att misstolka artefakterna, detta bör klargöras med användarna. Den fjärde, kulturella modellen tar upp de organisatoriska aspekter som inverkar på hur systemet bör designas. Kunskap om ett företags kultur (informella strukturer, vanor, hierarkin osv.) kan vara det som fäller avgörandet om designen kommer bli framgångsrik eller inte. Om någon viktig aspekt missas kanske systemet tas emot på ett mycket negativt sätt. Den kulturella modellen är den modell som är minst konkret, vilket gör att den främst kan formuleras som riktlinjer för hur systemet bör och inte bör designas I den sista och femte modellen, den fysiska modellen beskrivs i vilken miljö arbetsuppgifterna utförs. Olika miljöer ställer olika krav vilket denna modell skall specificera upp. Exempelvis kan systemet försöka efterlikna placeringen av olika föremål i systemet om den är upplagd på ett speciellt sätt i verkligheten. När detta skall omsättas i praktik för vårt projekt kommer det från början ske på tre fronter, där de tre användarkategoriernas data analyseras. Dessa tre uppsättningar med modeller smälts sedan samman till en, bestående av de fem modellerna. Steg 3 Data consilidation Sammanslagning av data När man har kommit så här långt i processen har man, förhoppningsvis, fått en klar bild över hur de individuella användarna arbetar i dagens system och dessutom en djupare förståelse för arbetssättet genom utformandet av arbetsmodeller. Ett problem som kvarstår är dock att dessa data, mestadels, behandlar enskilda användare. Författarna ger i litteraturen flera verktyg för att effektivt kunna representera hela användarpopulationer på ett tydligt sätt. Dels använder man sig av så kallade affinity diagrams och dels presenteras metoder för att slå samman de olika arbetsmodellerna. 7

8 Ett affinity diagram används för att organisera de individuella kort som kom fram under interpretation sessions hierarkiskt för att kunna hitta samband och gemensamma teman. Resultatet när diagrammet är färdigställt består av ett träd där detaljnivån blir högre längre ner i trädet. Trädet byggs underifrån genom att man tar upp ett kort med en punkt och försöker hitta andra lappar som på något sätt hör ihop med det kortet. Kort som hör ihop grupperas sedan utefter vad de har gemensamt, sedan paras dessa grupper in i set som i sin tyr delas in i olika områden. Område Set Set Grupp av lappar Grupp av lappar Grupp av lappar Lappar Lappar Lappar Strukturen för ett affinity diagram. När man väljer ut vilka kort som ska grupperas tillsammans är det viktiga att det gemensamma är vad de säger om arbetet som arbetaren utför och att det inte är ett självklart samband, på det sättet att det inte kan leda till något man inte redan visste. Ifall tolkningen av lapparna vid något tillfälle blir oklar får man naturligtvis undersöka hur lappen bör tolkas genom att tillfråga personen som utförde intervjun där åsikten kom fram. För att arbetet med att bygga trädet ska bli mer kreativt och mindre förutsägbart nämner författarna ett knep som innebär att man förbjuder användningen av vissa ord som gruppen vanligtvis använder för att beskriva vanliga tankegångar runt arbetet. När man börjar få ett så stort antal grupper att det blir svårt att överskåda dem är det dags att skriva sammanfattande rubriker för de grupper man delat in korten i. Om någon grupp får fler än fyra lappar ska man dela upp gruppen i mindre grupper. Allt eftersom antalet grupper växer blir det sedan dags att dela in grupperna i set och tillslut dessa set i områden. För att lättare kunna överskåda diagrammet använder man färgkoder där de ursprungliga lapparna är vita, gruppnamnen är blå, seten rosa och områdena gröna. I vårt projekt uppskattar vi att antalet kort kommer uppgå till cirka 500, det vill säga ungefär så många lappar per intervju som Byer och Holtzblatt uppskattar antalet till. 8

9 Metoderna för sammanslagning av arbetsmodellerna är olika för de olika arbetsmodellerna, men det finns anvisningar för hur man gör detta steg för steg. I flow model omordnas de olika ansvarsområdena hos användarna i roller. Datan från sequence model grupperas in i abstrakta steg och mening. Artifakterna grupperas och placeras i en fysisk miljö. Slutligen tar man vara på påverkare och påverkan i cultural model. I vårt projekt genomförs naturligtvis dessa sammanslagningar av den data som finns tillgänglig efter steg 2. Steg 4 Vision & Storyboards Det första steget som tas i själva designfasen är att skapa en gemensam vision för hela teamet som arbetar i projektet. Visionen skapar en visuell karta över arbetet, kartan säkerställer att de olika grupperna i teamet kan jobba parallellt och självständigt med sina områden utan risk att falla utanför projektets ramar. Visionen är en karta över hur det nya systemet kommer att fungera i praktiken och hur användarens arbetssätt kommer att förändras med det nya systemet. Vilka roller det finns, systemets tekniska processer, hur rollerna och andra delar kommer att kommunicera och hur de är kopplade till varandra. Grunden till visionen fås genom att teamet sätter upp startpunkterna som speglar grundstommarna i hela systemet, t.ex. designidéer eller hur användaren kommer att integrera med systemet. Dessa startpunkter utvecklas sedan så långt som möjligt, utvecklandet sker punkt för punkt genom att alla i teamet får uttrycka sina tankar kring idéen t.ex. kopplingar, design och olika tekniska lösningar. Teamet skall inte begränsa sig när det gäller implementering, detta för att öka kreativiteten och locka till att bygga på varandras idéer oberoende av teknisk kunskapsnivå. För att det skall finnas någon struktur och ledning i detta annars kaotiska arbetssätt så skall det finnas två nyckelpersoner under ett visionsscenario. Pennan är den som uppmuntrar alla till att säga sin mening, ser till att idéerna passar in i visionen och är den som håller i pennan och ritar ner det som sägs. Facilitator ser till att diskussionen blir effektiv genom att följa tråden och koppla tidigare diskuterade idéer, värderingar och roller till tråden. Idéer som ligger för långt ifrån tråden tas till vara på och skrivs upp som nya startpunkter för vidare diskussion. Eftersom varje startpunkt följs upp och skapar i sin tur flera visioner så skall detta överflöd minskas ner till en slutlig version. Detta görs genom att ta fram listor över de positiva i varje vision, sedan vidare till de negativa. När det negativa delarna skrivs ner så kommer det att genereras lösningar på de negativa delarna, dessa tas till vara för framtida bruk. De positiva delarna från varje vision sammanställs och det diskteras hur dessa skall sammanföras till en vision (Visionen). Om några av lösningarna är i konflikt med varandra löses detta genom att välja den minst tidskrävande. Om inte detta går att avgöra så skall man undersöka det data som generera lösningen i intervju med den berörda användargruppen. 9

10 Visionen beskriver systemet i en gemensam bild över alla processer. För att kunna designa systemet så måste varje delprocess studeras och utvecklas mer i detalj. Detta är nästa steg i designdelen och görs med en Storyboard, skiss som beskriver den separata processens design. När man skapar en Storyboard sätts den separata processen i fokus genom att betrakta allt material som har tagits fram under utvecklingen rörande just denna delprocess, både positiva, negativa delar och lösningar på problem som identifierats tas fram. Materialet sätts samman till ett antal skisser beskrivande delprocessens förfarande delvis. De olika processerna bildar sedan tillsammans Storyboards. Målet med Storyboards är att på ett sekventiellt sätt beskriva hela systemet, inte bara de processer som integrerar med systemet utan alla steg som det nya systemet bidrar till i användarens arbetssätt. Steg 5 User Enviroment Design Om Storyboards är ett sekventiellt sätt att presentera designen på, så är User Enviroment Design ett strukturellt sätt att representera samma design, genom att illustrera hur de olika sekvenserna är samankopplade till en helhet. I pensionsplanerings projektet är den strukturell visualisering av designen att föredra. Helhetsbilden bidrar till att lättare bygga fungerande prototyper över systemet. Om designteamet inte har en bild över kopplingarna är det risk att man under utvecklingen av prototyperna hittar fel som tvingar till att start om prototyputvecklingen. Detta skall undvikas eftersom det är tidskrävande och kostsamt. User Enviroment Design konstrueras ur Storyboards, under konstruktionen gås varje Storyboard igenom och plats, funktioner, behov och kopplingar till andra funktioner listas upp. Varje Storyboard får sin egen ruta på pappret med sin lista, de olika rutorna kallas för fokusområden. Projektgruppet ser nu till att strukturera fokusområdena. Detta så att det inte finns fokusområden i konflikt med varandra, finns det flera fokusområden som i princip gör samma sak skall dessa bilda ett gemensamt, finnas det delar i fokusområdena som pekar på att ett nytt fokusområde behöver finnas, skapas detta. När struktureringen är avklarad kopplas fokusområdena ihop så att inget hänger i luften. Om något fokusområde står för sig själv så måste detta lösas genom sammanslagning eller utdelning av delar till de andra fokusområdena. Det har nu skapats en helhetsbild över hur det nya pensionsplanerings systemet kommer att se ut med alla delars separata platser, funktioner, kopplingar och vilka roller som integrerar med vad. Projektgruppen vet nu hur de skall dela upp arbetet, vilka delar som behöver implementeras först och vilka tekniker som kan tänkas användas. Men för att vara säkra på att slutsatserna är korrekta skall dessa testas på de olika användargrupperna. 10

11 Steg 6 Paper prototyping pappersbaserat prototyparbete För att testa slutsatserna från de olika stegen tidigare, skapas en prototyp av pensionsplanerings systemet som testas på de användargrupper som identifierats. Målet med dessa tester är att få fram bara feedback på hur system fungerar utifrån användarens perspektiv och om det stämmer med projektgruppens slutsatser om funktionalitet. För att feedbacken skall ge mer än ja, nej svar så ska det skapas en metod för att involvera användaren i en djupare diskussion. Denna diskussion skall leda till att användaren utan att veta om det analyserar tekniska byggstenar i systemet. För att skapa dess komplicerade diskussioner skapas prototypen i pappersform. Pappersbaserade prototyper har de egenskaper som eftersträvas. Det finns här inget inbyggt motstånd för förändring. Det är lätt att peka, sudda eller rita till saker på ett papper. Genom att arbeta i pappersform där ikoner och andra detaljer inte är så framträdande, förblindas inte användaren av den fina designen. Utan kan koncentrera sig på det som är viktigt, strukturen med vilken prototypen är byggd. Användning av pappersprototyper underlättar att beskriva flödet genom de olika funktionerna som användaren kommer att utsättas för i det färdiga pensionsplanerings systemet. Om flödet inte känns rätt för användaren kan man enkelt ändra detta genom att byta platts på funktionen eller lägga till ett mellansteg. Testat kommer även att visa om det finns funktioner som användaren anser vara överflödiga eller förvirrande. Projektgruppen har nu en fullständig överblick hur pensionsplanerings systemet kommer att designas, detta utan att ha kodat en rad. Avslutning Med hjälp av papersprototypen och testresultaten utvecklas en interaktiv prototyp, den interaktiva prototypen arbetas fram stegvis i nära förbindelse med användargrupperna. Ur stegvis utveckling och implementering av prototypen kommer den färdiga produkten pensionsplaneringssystemet att växa fram. Genom att bygga prototypen på de slutsatser och modeller som har växt fram allt eftersom användargrupper, roller och funktioner utvecklats ur pensionsplaneringsprojektet. Har en grundlig skiss av designen utvecklats för prototypen. Genom att sedan testa denna design grundligt med användargrupperna finslipas designen. Ur det nära sammanbetet mellan användare och designers växer ett system som är omtyckt och lätt att använda. 11

12 Tidplan Vi bedömer att projektet kan genomföras med en grupp bestående av fem personer. Av dessa bör det finnas en person som kommer att vara involverad i programmeringen av systemet och en person som är huvudansvarig för den grafiska designen, dessutom ska en tredje person fungera som projektledare. Samtliga i gruppen bör ha goda kunskaper inom människa-datorinteraktion. Förberedelser inför projektet och intervjuerna bör utföras av projektledaren tillsammans med en av de två personer som inte innehar en av de ovan nämnda rollerna, tidsåtgången för detta beräknas vara en arbetsvecka. Själva intervjuerna bör genomföras av samtliga i projektet utom projektledaren för att kunna få in fler aspekter av problemet, varje intervju beräknas uppta en arbetsdag. Men en användargrupp på tio personer innebär det knappt tre hela arbetsdagar för att genomföra intervjuerna. Troligtvis kommer det inte gå att planera så pass bra att intervjuerna kan genomföras inom dessa tre dagar, men vi uppskattar att den effektiva arbetstiden kommer att stanna där. Även i tolkningen och sammansmältningsprocessen bör samtliga fem i projektet vara involverade. Med fem personer arbetandes med affinity diagram beräknar vi att vi når det rekommenderade antalet personer som är en per 100 kort. Ifall det skulle bli fler kort får man involvera ytterligare personer inom detta steg. För tolkningen beräknar vi drygt en arbetsdag, för affinity diagram ytterligare en och för sammansmältningen av modellerna uppskattas tidsåtgången till en halv arbetsdag per modell. Visionen med pensionsplaneringsprojektet med utgångspunkt från beställaren skall tas fram av hela projektgruppen, detta så att alla får säga sitt och känna att de är delaktiga till lika stor del i projektet. Det bör inte ta mer än två arbetsdag för fem personer att arbeta fram visionen. När projektets Storyboards skall sättas ihop är det viktigt att alla som har genomfört intervjuer med användarna deltar. Detta för att säkra att alla tänkbara vinklingar från de olika intervjutillfällena tas med. Fyra personer som är väl insatta i projektet borde arbeta fram Storyboards på en och en halv arbetsdag. User Enviroment Design kräver att samtliga I projektgruppen är närvarande för att alla skall ha en god överblick i hur pensionsplaneringssystemet kommer att se ut och arbetas med. Den tid som kommer att krävas är tre arbetsdagar för att få alla bitar att falla på plats. Utformningen av pappersprototypen kommer att involvera samtliga i projektgruppen under vissa faser och bara någon under andra. Utvecklingen av första varianten kommer att ta en sju arbetsdagar. Första testerna med användarna tar fyra dagar, två dagar per grupp om fem användare. I dessa tester medverkar två av utvecklarna per tillfälle samt att projektledaren medverkar vid båda. Sedan följer vidareutveckling av prototypen med hjälp av testresultaten. Denna procedur fortsetter sedan till leverans. 12

13 Inledande planering 2 (personer) 80 (mantimmar) Steg 1 intervjuer 4 80 Steg 2 tolkning 5 40 Steg 3 sammansmältning Steg 4 vision, storyboards 5, 4 80, 60 (140) Steg 5 UED Steg 6 Pappersprototyp 300 Diskussion Sammantaget tycker vi att Contextual Design ger goda förutsättningar för att styra en användarcentrerad systemutveckling. Det är positivt att man sätter så pass stor fokus på att undersöka användarna och den miljö de arbetar i. Att användaren är involverad i processen ger dem en känsla av delaktighet i utvecklingen som gör acceptansen för systemet högre. Varje steg i utvecklingen finns väl beskrivet och de olika modellerna som används för arbetet känns i de flesta fall användbara. Att ett flertal modeller används för att visa på olika aspekter av problemet är positivt. För mindre projekt känns dock Contextual Design överdrivet omfattande och tidskrävande i förarbetet. Det finnas en risk att mindre projekt drunknar i sin egen dokumentation, samma risk finns det för de stora projekten. De stora projekten löper den risken genom att vid deadline för projektet så är den ända produkten som finns tillgänglig en hög med dokumentation. Fördelen med att dokumentera mycket under hela processen säkrar att man behåller de idéer man fått tidigt i projektet och även vet hur och varför dessa uppkommit. Stor del av dokumentationen som kommer fram under användning av Contextual Design är visuella bilder av projektet så som skisser och kartor. Bilder är mer positivt än metervis av dokumentation, det går mycket fortare för nya resurser som skall in i projektet att ta del av helhetsbilden, om denna kan visualiseras. Det finns andra risker förutom massan av dokumentation i Contextual Design att personen som genomför intervjun missuppfattar användarens synpunkter, och eller lägger in sina egna värderingar och tolkningar av användarens arbetssituation utan att kontrollera detta med användaren. Visionsdelen uppfattar vi också kan leda till en produkt som är överflödig i hänsyn till den faktiska produkt som beställaren ville ha från början 13