Användarcentrerad Systemdesign

Transkript

1 Uppsala universitet Institutionen för informationsteknologi Avdelningen för människa-datorinteraktion Användarcentrerad Systemdesign, 5p HT2006 Caroline Hägglund Anna Küller Magnus Larsson Användarcentrerad Systemdesign FlyttIT - Rådgivning och hjälp vid flytt

2 Innehållsförteckning 1 INLEDNING UPPGIFTSBESKRIVNING SYFTE AVGRÄNSNING TEORI KONTEXTUELL UNDERSÖKNING ARBETSMODELLER SAMMANSLAGNING AV INFORMATION ARBETSOMSTRUKTURERING SYSTEMDESIGN SKAPA PROTOTYPER FLYTTIT PROJEKTSTART Projektgruppen Potentiella användargrupper KONTEXTUELL UNDERSÖKNING ARBETSMODELLER SAMMANSLAGNING AV INFORMATION ARBETSOMSTRUKTURERING SYSTEMDESIGN SKAPA PROTOTYPER DISKUSSION KÄLLFÖRTECKNING i

3 1 Inledning Packa, adressändra, säga upp elräkning, flytta telefonabonnemang, hitta billigaste bredbandsleverantören, fixa flyttbil, et cetera. Det finns många saker man måste komma ihåg och många beslut att fatta vid en flytt. Kanske har man ingen aning om hur området man flyttar till är och det utbud av möjligheter som finns där i form av olika leverantörer. Man drunknar lätt i all information och glömmer lika lätt att fixa saker i tid. Denna rapport ämnar att belysa de processer en projekteringsgrupp kan komma att göra vid framtagningen att nytt system som skall underlätta situationen för en som flyttar. 1.1 Uppgiftsbeskrivning Vi har bestämt oss för att starta en firma som ska ge råd och hjälp till personer som ska flytta. Hur ska vi lägga upp arbetet för att ta fram en användarcentrerad tjänst som hjälper flyttare med alla behov denna kan ha vid en flytt? 1.2 Syfte Syftet med denna rapport är att beskriva, planera och diskutera processen för hur ett fiktivt ITbaserat system ska utvecklas utifrån Hugh Beyer och Karen Holtzblatts syn på användarcentrerad utveckling. 1.3 Avgränsning Design, programmering, intervjua användare, göra användningsfall och annat som innebär att genomföra själva systemutvecklingen ingår inte. De modeller som kommer användas kommer tas från boken Contextual Design: Designing Customer- Centered Systems av Hugh Beyer och Karen Holtzblatt. 1

4 2 Teori I boken Contextual Design presenterar Hugh Beyer och Karen Holtzblatt sina teorier kring hur utveckling av nya system bör bedrivas. Dessa teorier kommer att sammanfattas i följande sex faser, vilka även följer kursbokens upplägg. 2.1 Kontextuell undersökning En kundorienterad process utgår ifrån grundregeln att det är nödvändigt att verkligen förstå kundernas önskemål, behov och nuvarande arbetssituation. Detaljerad information om kunderna samlas in genom kontextuella undersökningar vilka kan ta flera olika former men som alla alltid fokuserar på användaren under pågående arbete. Genom dessa fältstudier tar man reda på kundernas bakgrund, kompetens och möjligheter. En kontextuell undersökning utgår från följande fyra principer: Kontext, partnerskap, tolkning och fokus. 2.2 Arbetsmodeller Informationen som samlades in under föregående fas måste tolkas och struktureras. Genom tolkningssessioner skapar gruppens medlemmar grafiska arbetsmodeller vilka illustrerar hur användarens nuvarande arbetssituation ser ut utifrån sett från fem olika perspektiv. Tack vare att arbetsmodellerna skapas genom gemensamma diskussioner får gruppens deltagare en gemensam uppfattning om hur kunderna arbetar. De fem modellerna som används i Contextual Design är överlappande och kompletterande för att tillsammans bilda en helhetsbild. Flödesmodellen: Sekvensmodellen: Artefaktmodellen: Kulturell modell: Fysisk modell: redogör för den kommunikation som sker mellan enskilda användare och användargrupper. förklarar i vilken ordning arbetsuppgifter utförs. beskriver de hjälpmedel som skapats, används och förändrats under arbetets gång. redogör för organisationens policy och värderingar. Därtill beskrivs de outtalade åsikter som påverkar arbetsmiljön och beteenden. beskriver hur användarens arbetsplats är uppbyggt rent fysiskt. 2.3 Sammanslagning av information System designas sällan för en enda kund, utan ofta för en hel kundpopulation. För att finna vilka krav som kan komma att ställas på systemet måste projektgruppen, utifrån användarnas individuella behov, hitta ett gemensamt mönster som visar en enda bild av kundkretsens 2

5 användning av systemet. Detta utan att för den skull förlora individuella variationer. Detta görs genom att bygga ett sambandsdiagram (eng. affinity diagram ) och genom att göra sammanslagningar av arbetsmodellerna från föregående fas. Genom att sätta upp modellerna på väggen kan projektgruppen använda dem, likt en karta, för att tydliggöra vilka aspekter av arbetet som stöds, vilka aspekter som är viktiga att stödja härnäst samt vilka relaterade arbeten som kanske skulle behöva stödjas i framtiden. Modellerna kan studeras närmare genom något som kallas walking the data. Aktiviteten kan liknas vid ett museibesök, där modellerna kan ses som en utställning. Meningen är att projektgruppen ska reflektera över materialet och samtala om hur man via design ska hantera problem och stödja arbetsuppgifter. 2.4 Arbetsomstrukturering Den sammanslagna informationen från modellerna används främst för att driva konversationer kring hur kundens arbete kan förbättras. En gemensam vision tas fram för hur det nya arbetssättet kommer att bli, men den skall inte visa hur det arbetet skall gå till. Med hjälp av storyboards kan teamet utveckla visionen till en mer konkret definition av hur människor kommer att arbeta i det nya systemet. Storyboards visar hur specifika uppgifter kommer att utföras med det nya systemet. Användargränssnittets utseende och uppförande beskrivs bildligt likt en filmsekvens och ger projektgruppen en förståelse för hur designen fungerar vid användning. Varje enskild del i en storyboard bildar en scen; en interaktion mellan två människor, en person och systemet, en person och en artefakt eller ett systemsteg. 2.5 Systemdesign Vid systemdesign är det av yttersta vikt att systemet erbjuder för syftet lämpliga funktioner samt att strukturen är sådan att arbetet ter sig naturligt och sammanhängande. Denna designprocess kallar Beyer och Holtzblatt för User Environment Design, hädanefter benämnd UED. UED skall agera abstraktion av systemets delar samt relationen dem emellan sett ur användarens perspektiv och grundas på framtagna storyboards från föregående fas. Den möjliggör skapandet av ett sammanhängande system, vilket stödjer att flera olika roller utför flera olika moment. UED är så kallat gränssnittsoberoende, vilket innebär att strukturen inte kopplas till något specifikt användargränssnitt, utan endast visar respektive del av systemet, hur denna del stödjer användarens arbete, vilka funktioner som finns tillgängliga i denna samt hur den ligger i relation till övriga delar. En tydlig struktur möjliggör för senare utökningar av systemet, men även för att 3

6 enklare kunna sätta upp arbetsgrupper som kan arbeta med respektive del och inte förlora fokus på användarens uppfattning av sammanhang inom systemet. 2.6 Skapa prototyper Ju tidigare i utvecklingsprocessen fel uppmärksammas desto billigare är det att göra nödvändiga åtgärder. För att synliggöra dem behövs tester. Genom att sätta upp prototyper från UED kan man testa strukturen och tankar kring gränssnitt. Att börja med pappersexempel är ett bra och kostnadseffektivt sätt innan man börjar koda. De möjliggör kontinuerlig iteration med små medel och gör det verkligt för användaren. Tillsammans kan sedan systemutvecklarna och användarna diskutera fram en optimal design som skulle kunna passa användarens arbete. Genom att nyttja flertalet träffar mellan systemutvecklare och användarna kan man förbättra systemet och driva designen av användargränssnittet framåt. 4

7 3 FlyttIT I detta avsnitt kommer modellen Contextual Design att tillämpas på FlyttIT-projektet. 3.1 Projektstart Vid projektstart sätts projektgrupp upp av projektledare. Därefter identifieras det blivande systemets användaregrupper samt representativa användare för dessa grupper Projektgruppen Projektgruppen består av fem individer vilka fyller olika kunskapsområden: Projektledare, interaktionsdesigner, användbarhetsdesigner samt två produktutvecklare. Projektledaren är ytterst ansvarig för projektets tidsplan samt att gruppen präglas av samförstånd och samordning, och att informationsflödet håller hög kvalitet. Det är även projektledaren som står ytterst ansvarig gentemot beställaren. I detta projekt är projektledare och beställare samma individ. Användbarhetsdesignern är den person inom gruppen som har kunskapen om hur en användare, agerar och reagerar i olika situationer. Kognitiv psykologi tillsammans med kunskap om systemutveckling samt interaktiva system är användbarhetsdesignerns främsta egenskaper. Användbarhetsdesignern är även expert på att konkretisera användarnas behov. Interaktionsdesignern är ytterst ansvarig för att gränsytan mellan system och användare håller sådan kvalitet att användbarhetsdesignerns samt produktutvecklarnas arbete, tillsammans med interaktionsdesignerns design, förefaller optimal. Produktutvecklarna är de inom gruppen som har det främsta ansvaret att översätta givna modeller till kod. Produktutvecklarna, detta till trots, kommer även att vara delaktiga utmed hela projektet för att kunna delta i diskussioner, få förståelse för användarnas behov och skapa sig en tydlig målbild att arbeta mot. En viktig del för att kunna skapa en lyckad design och ett, för projektgruppen, effektivt arbetssätt är att ett särskilt rum avsätts för projektet. Projektet FlyttIT kommer därför att utföra alla deras arbetsuppgifter, såväl intervjuer och workshops som diskussioner och designarbete, i ett särskilt rum. All befintlig data kommer att finnas i rummet, som på så sätt blir projektgruppens kollektiva minne och en stimulans till samtal om lösningar. 5

8 3.1.2 Potentiella användargrupper Vi ser att det tänkta systemet kommer att ha två olika användargrupper. Den ena väljer vi att benämna Flyttare. Deras huvuduppgifter ser vi som att flytta ut, flytta in eller flytta ihop med någon/några. Dessa aktörer kommer vara de som interagerar med systemet med avsikten att interaktionen ska underlätta flytten. För att systemet ska fungera krävs även en annan användargrupp, systemadministratörer. Deras arbetsuppgifter är att samordna informationen som systemet ska innehålla samt att sköta informationsflödet. Vi har valt att bortse från användargruppen systemadministratörer vid utformningen av vår projektplan och tar därför endast hänsyn till hur flyttarnas behov ska kunna omformas till ett system. Vi tror dock att systemadministratörernas behov kommer att kunna identifieras under processen gång, eftersom samtliga projektmedlemmar kan vara framtida systemadministratörer. Detta är ett resultat av att vi är en lite organisation. Vi är även medvetna om att berörda företag kommer vara en användargrupp då dessa tar del av systemets output. Vi kommer dock inte behandla dessa i denna rapport. För att få kontakt med representanter från användargrupperna kommer annonseringar som beskriver projektet att användas. För att öka de presumtiva kundernas motivation att delta i projektet kommer en ersättning att erbjudas. 3.2 Kontextuell undersökning Användargruppers behov, önskemål och kompetenser ska kartläggas genom kontextuella undersökningar. Enligt kontextprincipen kommer intervjuaren att få tillgång till mycket information enbart genom att studera användaren under tiden som den genomför de uppgifter som det nya systemet ska underlätta. För den som flyttar är respektive användares kontext svåridentifierad eftersom denne/denna inte kommer att hantera flyttärenden stationärt. Inte heller kommer samtliga ärenden att utföras samtidigt. Förutsättningarna ställer stora krav på att intervjuaren får möjlighet att följa med flyttaren till olika platser och under en lång tid. En tanke är att intervjuerna skulle kunna arrangeras genom att kunden hör av sig när denne ska hantera sina ärenden, vilket dock sällan går att planera i förväg. Påverkan av en sådan datainsamling skulle troligtvis vara så pass stor att användaren skulle alternera sitt normala tillvägagångssätt. Till följd av ett flyttärendes karaktär ges inte möjlighet till längre sessioner där intervjuare kan agera lärling. Av givna anledningar dras slutsatsen att datainsamlingen därmed borde bli smidigare och mer informationsrik om det sker genom andra former än rena kontextuella undersökningar. Genom att ge flyttaren en dagbok så 6

9 kan han/hon beskriva och motivera sina arbetsmoment under flyttprocessen. Med hjälp av en handkamera kan kunden dessutom spela in sig själv när han/hon utför sina flyttärenden. På dessa sätt får projektgruppen tillgång till mycket information om kundens arbetsprocess, samt eventuella svårigheter som han/hon upplever med nuvarande system. Projektguppen kommer dessutom att genomföra individuella intervjuer med flyttare innan och efter genomförd flytt. Orsaken till intervjuernas uppdelning är att få tillgång till information om flera moment i flyttprocessen och möjlighet att upptäcka om flyttaren insett att flyttärenden utförts felaktigt eller förbisetts. Under intervjuerna kommer dagböckerna och videoinspelningarna gås igenom och flyttaren kommer att ges möjlighet att beskriva och motivera arbetsmomenten. För att få en djupare förståelse för hur flyttaren tänker och de olika arbetsmomenten ska intervjuaren förhålla sig till flyttaren som en lärling förhåller sig till sin mästare. Insamlad informationen måste alltid tolkas men för att i möjligaste mån försäkra att tolkningen är en så bra överensstämmelse med verkligheten som möjligt ska intervjuaren löpande diskutera sina bedömningar med flyttaren. Fokusen definierar det perspektiv som intervjuaren antar under en intervju. På grund av att olika intervjuare har olika erfarenheter kommer de att se skilda saker i en intervjusituation. Eftersom projektgruppen är tvärfunktionell och består av individer med olika kompetenser kommer olika aspekter av flyttaren arbetsmoment att lyftas fram under de olika intervjuerna. Deltagare: Samtliga individer i projektgruppen och 15 flyttare. Input: Kontaktinformation till presumtiva kunder Output: Dagboksanteckningar, videoinspelningar och intervjuanteckningar som tillsammans skapar en beskrivning av flyttarens nuvarande sätt att hantera flyttprocessen. Planerad arbetstid: 2 timmar per intervju med 15 flyttare ger en totaltid på 30 timmar. Tid åt projektet: 2 månader till följd av flyttens tidsspann. 3.3 Arbetsmodeller Under denna fas går hela projektgruppen igenom det material som samlats in. Denna tolkningssession ska ske relativt snart efter en genomförd intervju och kommer således till viss del överlappa med föregående fas. Den som genomfört intervjun redogör för det insamlade materialet samtidigt som projektgruppens övriga medlemmar tilldelas roller som sekreterare, moderator, kontrollant etc. Under tolkningssessionerna kommer projektgruppens diversifierade kunskap att utnyttjas och tack vare att samtliga intervjuer bearbetas skapas en gemensam förståelse av kundernas flyttprocesser. För att öka förståelsen används grafiska arbetsmodeller 7

10 som skildrar kundens flyttprocess ur fem olika perspektiv. Arbetsmodeller är kompletterade och syftar till att skapa en helhetsbild. Flödesmodellen: Sekvensmodellen: Artefaktmodellen: Fysisk modell: Här redogörs för kommunikationen och utbytet av artefakter som sker mellan användare som ingår i arbetsprocessen. Eftersom flyttprocessen utförs av en enskild användare kommer inte flyttaren ha kontakt med andra flyttare, istället kommer flödesmodellen att redogöra för vilket utbyte som flyttare har med organisationer eller företag som idag förmedlar de tjänster som han/hon är i behov av. Utbytet kan bestå av information om uppsägningstid, bostadsadress, kundnummer, et cetera. Genom denna modell tydliggörs ordningsföljden av de arbetsmoment som kunden utför före, under och efter flytten. Kan exempelvis klargöra att ett elabonnemang måste sägas upp i lång tid innan flytten medan adressändringen kan ske i ett senare skede. Projektgruppen beskriver de hjälpmedel som kunden skapat, använt och förändrat före, under och efter flytten. I vårt fall kan detta handla om en telefonkatalog, anteckningar med telefonnummer, adresser et cetera. Denna modell redogör för hur kundens fysiska arbetsplats ser ut. Det kommer troligtvis att bli en komplicerad modell eftersom de ärenden som flytten kräver kan komma att bedrivas från olika platser, exempelvis kan en flyttare behöva ringa ett telefonsamtal från bussen. Deltagare: Samtliga individer i projektgruppen. Input: Dagboksanteckningar, videoinspelningar och intervjuanteckningar Output: Anteckningar från tolkningssessioner och arbetsmodeller som beskriver kundens flyttprocess. Planerad arbetstid: 3 timmar per intervju vilket totalt blir 45 timmar. Tid åt projektet: 5 arbetsdagar. 8

11 3.4 Sammanslagning av information Första steget i sammanslagningen är att bygga ett hierarkiskt sambandsdiagram. Projektmedlemmarna skriver ned anteckningarna från tolkningssessionen på post-it-lappar och grupperar dem utifrån anteckningarnas förhållande till varandra. Detta resulterar i att kategoriseringarna uttrycker liknande avsikter, problem eller frågor i flyttarnas arbete. Projektgruppen skapar sedan en helhetsförståelse för innehållet i gruppen och drar relevanta slutsatser som är viktiga för designarbetet. Det är viktigt att kategoriseringarna inte är fördefinierade utan växer fram i diagrammet. Sambandsdiagrammet ska tala flyttarnas språk och uttrycka sådant som är viktigt för dem. Projektgruppen får därför inte använda sig av ord som de är familjära med, utan måste hålla sig till ord som kommer ifrån kunddatan. Projektgruppen måste också göra sammanslagningar av arbetsmodellerna för att skapa en generell bild av systemet. Modellerna syftar till att ge en grafisk representation att diskutera och reflektera över. De visar flyttares avsikter, deras strategier för att uppnå avsikterna samt de strukturer som stödjer strategierna. Dessa kunddata är sedan med och driver designbeslut. När alla sammanslagningar är färdiga finns det utrymme för repetition och reflektion. Detta görs genom att walking the data. Efter att projektgruppen betraktat sambandsdiagrammet skriver varje deltagare ner två anteckningar som utgörs av en fråga de vill ha svar på och av en idé för hur man ska hantera befintlig data. Projektgruppen går också igenom de sammanslagna modellerna och skriver ned problem, begränsningar och andra designidéer. När alla gått igenom modellerna kollar projektgruppen igenom anteckningarna för varje modell. Att walking the data uppmuntrar till att idéer vävs samman till ett systemtänkande som underlättar skapandet av helhetslösningar. Deltagare: Samtliga individer i projektgruppen. Input: Noteringar och arbetsmodeller som gjordes under tolkningssessionen. Output: Sambandsdiagram och sammanslagna arbetsmodeller. Anteckningar, idéer och insikter som kommer från att walking the data och behövs för att skapa gemensamma visioner i nästa steg. Planerad arbetstid: En dag för sambandsdiagrammet, en dag för varje sammanslagning av de fyra arbetsmodellerna och fyra timmar för walking the data, det vill säga totalt 44 arbetstimmar. Tid åt projektet: 6 arbetsdagar 9

12 3.5 Arbetsomstrukturering Arbetet påbörjas med att projektgruppen skapar en gemensam vision av kundernas tillvägagångssätt via en flytt, som det nya systemet möjliggör. En person ansvarar för att rita upp idéerna till en design av det nya arbetssättet. En annan person har ansvaret att hjälpa till att binda ihop idéerna och ger förslag på andra infallsvinklar. Beyer och Holtzblatt rekommenderar att framtagandet av en vision ska ske med maximalt tio personer, så att alla får chans att prata. Eftersom vår projektgrupp endast består av 5 personer anser vi att hela gruppen bör vara med. Det viktiga är att det finns en känsla för att man får säga vad man tänker samt att alla förslag uppmärksammas och inte filtreras bort. Om en vision innehåller mer än vad projektgruppen kommer att kunna bygga spelar mindre roll, det viktiga är att låta kreativiteten flöda. Projektgruppen ritar åtminstone tre till fyra visioner och visionernas styrkor och svagheter utvärderas. Detta för att kunna hitta en ny lösning där det bästa från varje individuell vision tas in. Utifrån den sammanslagna visionen och den sammanslagna Sekvensmodellen kan designern grafiskt illustrera hur det nya arbetssättet kommer att gå till, uppgift för uppgift. Detta görs genom att skapa storyboards likt en filmsekvens, där alla steg i en arbetsuppgift ritas i varsin scen. Till exempel kommer en storyboard att visa alla ingående steg som en flyttare utför när denne/denna vill säga upp sitt el-abonnemang. Storyboards byggs tillsammans av projektgruppens två designers och dessa visar sedan sitt resultat för de andra i projektgruppen så att de får komma med kommentarer. Vid behov sker bearbetning. Beyer och Holtzblatt uppmärksammar endast att det är projektgruppen som ska kommentera resultatet. Vi anser dock att flyttarna ska involveras i detta steg genom att även låta de utvärdera de storyboards som visualiserats. Detta sker lämpligen genom att bjuda in flyttare till en workshop där resultatet diskuteras och utvärderas. Den färdiga storyboarden ger designern en idé för hur designen kommer att operera och interagera med flyttarna när de utför sina uppgifter. Deltagare: Samtliga individer i projektgruppen och flyttare. Input: Sambandsdiagram och sammanställningen av arbetsmodellerna. Anteckningar, idéer och insikter som kommer från att walking the data. Sammanslagen sekvensmodell. Output: Storyboards. Planerad arbetstid: Fyra timmar till att skapa en gemensam vision och cirka 40 timmar för att bilda storyboards, alltså 44 timmar totalt. Tid åt projektet: 6 arbetsdagar 10

13 3.6 Systemdesign UED visar på områden vilka man bör fokusera på. Den baseras på föregående storyboards, vars berättelser sammanfogas till en helhet och dess struktur måste passa det tänkta arbetet. Eftersom UED inte är beroende i samma utsträckning på uppgiftens karaktär som de andra faserna kan denna appliceras på situationer av vitt skilda slag. UED skapas framförallt för att underlätta designen, men eftersom den porträtterar systemet från användarens synvinkel är den även ett medel för att hålla projektet kundcentrerat. Vidare, genom att hålla systemet sammanhängande kan även förhållandet mellan projektmedlemmarnas arbetsuppgifter tydliggöras. I arbetet med FlyttIT kommer denna fas att underlätta för produktutvecklarna att hålla fokus mot en gemensam målbild där kunden kommer i första rummet. UED:n kommer att göra så att kommande användare av FlyttIT kan se en tydlig och logisk relation mellan olika funktioner samt minska utrymmet för feltolkning eller missa viktig information. De skall få en sammanhängande arbetsgång. Genom att lägga tid på att verkligen ta fram den optimala strukturen kommer, utöver redan nämnda faktorer, systemet att kunna utökas och ändå bibehålla en känsla av sammanhang. Beroende på storyboardens/-as omfattning kommer processen med att ta fram en sammanhängande UED ta olika lång tid. Händelserna presenterade i storyboarden kan ge olika idéer till lösningar som måste behandlas iterativt innan UED kan ses som stabil. En förändring i UED kommer att få följdverkningar. En god och stabil grund måste skapas i projektet för att hålla nere kostnader. För att projektgruppen skall få en tydlig bild av vad som förväntas av systemet samt vad avsikten med designen är. I detta projekt bedöms dock arbetstiden inom gruppen till gemensamma en arbetsvecka. Deltagare: I denna fas är det lämpligt att användbarhetsdesignern samt produktutvecklare sitter med. Input: Storyboards från föregående fas. Output: Designmodell vilken specificerar vilka delar som skall ingå I systemet, samt vilket syfte, funktioner och kopplingar respektive del innehåller. Tid åt projektet: 1 vecka 3.7 Skapa prototyper Då man skall presentera data för kunderna är det svårare att förklara den tänkta designen än att illustrera den. Genom att sätta upp, till att börja med, illustrationer på papper kan man snabbt och enkelt finna problem hos designen av användargränssnittet samt finna lösningar som är 11

14 lämpade för just denna tillämpning. Genom att nyttja prototyper nertecknade på papper ges utrymme till diskussion bland användare kring designen och funktionaliteten då de utför de arbete de normalt utför i befintligt system. Då momenten vid en flytt ej tidigare utförts på liknande sätt kommer detta skapa problem sett utifrån modellen. I FlyttIT-projektet kommer detta att utföras med hjälp av workshops där personer som under flyttfas ges möjlighet att pröva på hur det skulle vara att nyttja FlyttIT och ge feedback. Tillsammans med interaktionsdesigner och användbarhetsdesigner kan användargränssnittet förfinas. Papparsprototyper inbjuder till förändring. Vidare menar Beyer och Holtzblatt att en kontinuerlig kontakt med kunderna skapar förtroende till projektet. Detta är ett problem för FlyttIT då sannolikheten att en person som nyss flyttat gör det igen inom en snar framtid; återväxten är inte speciellt stor. Trotts detta är denna fas förmodligen relativt viktig på grund av att rykten sprids. Flertalet versioner av systemet kan tas fram och modifieras under en vecka och i takt med att prototyperna blir allt mer stabila kan man gå över till att göra dessa i allt mer kodad form. För att slutligen utifrån UED via prototyper ha en färdig release. Deltagare: Samtliga individer i projektgruppen samt användare Input: UED-modell Output: Prototyper Planerad arbetstid: 5 veckor innan första release då systemet är helt nytt. Tid åt projektet: 5 veckor 12

15 4 Diskussion Under tiden projektplanen växt fram har vi kunnat identifiera både svagheter och styrkor med de föreslagna metoder som Beyer och Holtzblatt presenterar i Contextual Design. Vi har upptäckt att projektet får en strukturerad och detaljerad arbetsbeskrivning samtidigt som samtliga projektmedlemmar ges tydliga uppgifter. Projektgruppens sammansättning av individer med skilda bakgrunder och kompetenser medför att information om kunderna kan studeras från olika perspektiv. Därigenom reduceras risken att väsentligheter försummas. Vidare ger metoderna möjlighet till en helhetsförståelse genom de arbetsmodeller och sambandsdiagram som skapas. Det finns dock flera moment som inte är helt förenliga med FlyttIT-projektet. Den största nackdelen med metoden är att den förutsätter att kunderna agerar inom en organisatorisk struktur vilket inte är fallet i detta projekt. Det har exempelvis medfört att de föreslagna arbetsmodellerna inte kunnat appliceras i enlighet med teorin. Vi har till exempel helt bortsett från den kulturella modellen eftersom den ämnar kartlägga organisatoriska värderingar och restriktioner, och inte enskilda individers uppfattningar. Dessutom har den rena kontextuella undersökningen förbisetts på grund av karaktären på kundens uppgift, att flytta är en arbetsprocess som utförs sporadiskt, och är inte knuten till en specifik arbetsplats. Vidare är det inte säkert att flyttaren känner sig speciellt angelägen att förbättra den nuvarande flyttprocessen eftersom han/hon inte själv kommer att nyttja tjänsten under närmaste perioden. Flyttarens bristande engagemang kan leda till att den insamlade informationen blir ytlig. Vi har dock försökt lösa det problemet genom att de kunder som medverkar i undersökningen ersätts för sitt deltagande. Slutligen anser vi även att det faktum att projektledaren agerar beställare i FlyttIT-projektet även kan komma att medföra problem. Om ett känslomässigt förhållande finns till projektet kan det vara svårt att fatta rationella beslut om projektets fortgång. 13

16 5 Källförteckning Beyer, Hugh, Holtzblatt, Karen. Contextual Design: Defining Customer-Cantered Systems. USA: Academic Press