Användarcentrerad systemdesign Baserad på kontextuell design

Transkript

1 Uppsala Universitet Institution för Informationsteknologi Människa- Datorinteraktion Användarcentrerad Systemdesign HT Användarcentrerad systemdesign Baserad på kontextuell design Elin Olsson, Mårten Wikforss, Shohreh Hörnqvist, Ulrika Lindblom,

2 INLEDNING... 2 KONTEXTUELL DESIGN... 2 INTERVJUER... 2 Kontextuella intervjuer... 2 Tolkning... 3 Arbetsmodeller... 3 Flödesmodellen... 3 Sekvensmodellen... 3 Artefaktmodellen... 4 Den kulturella modellen...4 Den fysiska modellen... 4 KONSOLIDERING... 4 Konsoliderad flödesmodell... 5 Konsoliderad sekvensmodell... 5 Konsoliderad artefaktmodell... 5 Konsoliderad kulturell modell... 6 Konsoliderad fysisk modell... 6 FRÅN DATA TILL DESIGN... 6 Genomgång av data... 7 Vision... 7 Storyboards... 7 ANVÄNDARMILJÖDESIGN USER ENVIRONMENT DESIGN (UED)... 8 Fokusområde... 8 Projektplanering... 9 Omvänd användarmiljödesign... 9 Pappersprototyper... 9 UPPGIFT KÖKSPORTALEN LÖSNING INTERVJUER TOLKNING KONSOLIDERING INNOVATION ANVÄNDARMILJÖDESIGN Prototyper, testning DISKUSSION TIDPLAN FÖR FRAMSTÄLLNING AV KÖKSPORTAL

3 Inledning Vårt arbete består av två delar. Första delen utgörs av en sammanfattning av boken Contextual Design: Definining Customer-Centered Systems av Beyer och Holtzblatt. Andra delen har som syfte att beskriva och diskutera tillämpningen av den metod som boken presenterar för utveckling av en E-handelstjänst, köksportal. Dessutom tar vi upp de nackdelar och fördelar som följer med denna metod. Arbetet innehåller även en tidsplan och ett Gantt diagram. Kontextuell design Beyer och Holzblatt betonar i inledningen av boken Contextual Design vikten av att få en djupare förståelse av användarnas behov. Det räcker inte med att identifiera behov med hjälp av en vanlig marknadsundersökning utan man måste gräva djupare om man vill skapa ett användbart system. Intervjuer Kontextuella intervjuer Författarna presenterar en metod som de kallar kontextuella intervjuer. Denna metod går ut på att man som intervjuare besöker kundens arbetsplats och studerar kunden medan han arbetar. Tanken är att det ska råda en sorts mästarlärlingsrelation mellan kunden och intervjuaren. Kunden skall alltså visa för intervjuaren hur han arbetar och löser sina uppgifter. Intervjuaren ställer under tiden frågor och ber kunden förklara oklarheter. Det gäller att försöka få kunden att berätta om vad som verkligen händer och undvika abstraktioner. Detta kan uppnås genom att fråga om detaljer när det blir tydligt att kunden abstraherar allt för mycket. Det är också viktigt att inte störa mästarlärlingsrelationen genom att ställa alldeles för många frågor, det ska råda ett sorts partnerskap mellan kund och intervjuare. När man utför intervjun skall man pendla mellan olika fokusområden. I en vanlig konversation så brukar man prata en stund om en sak och sedan om en annan. Man skall göra på samma sätt när man intervjuar kunden. Författarna betonar vikten av att intervjua många personer för att man skall få en bra överblick över hur arbetet hos kunden går till. Det är också viktigt för att man skall kunna kontrollera om uppgifterna är konsekventa. 2

4 Tolkning När intervjuerna är färdiga gäller det att hela utvecklingsgruppen snabbt får ta del av resultaten. Författarna förespråkar därför att hela gruppen träffas och den som gjort intervjun får berätta om vad han uppmärksammat. När intervjuaren berättar skall de andra hela tiden avbryta med frågor och be honom förtydliga oklarheter. Det är viktigt att ingen information försvinner under projektets gång och därför utses en i gruppen till sekreterare och får i uppgift att skriva ner det som gås igenom. Några andra gruppmedlemmar är ansvariga för att ta fram arbetsmodeller under mötets gång. Arbetsmodeller Arbetsmodeller är grafiska beskrivningar av arbetet hos kunden. De är viktiga eftersom de ger utvecklingsgruppen en djupare förståelse för hur arbetet går till hos kunden. Författarna menar att de blir utvecklingsgruppens gemensamma språk för att kunna samarbeta och lösa uppgiften. Eftersom de är grafiska är de dessutom lätta att förstå. Författarna listar och beskriver fem olika arbetsmodeller som alla ger olika perspektiv på hur arbetet går till. De menar att dessa fem olika perspektiv kompletterar varandra på ett bra sätt och tillsammans skapar en helhetsbild. Flödesmodellen När en grupp människor skall lösa en komplex uppgift delar de upp uppgiften i mindre deluppgifter där olika personer blir ansvariga för var sin del. För att kunna lösa den stora uppgiften måste de sedan kommunicera med varandra. Flödesmodellen representerar denna kommunikation. Dvs. den visar vilka som kommunicerar med varandra, hur de gör de kommunicerar och vilka dokument de skickar varandra. Den visar också vilka roller inom organisationen formella som informella som de kommunicerade innehar. Sekvensmodellen När en arbetsuppgift skall lösas brukar den oftast utföras genom att en mängd delmoment utförs i sekventiell ordning. Någonting initierar denna kedja. Sekvensmodellen visar vad som initierar kedjan och alla deluppgifter som utförs i sekventiell ordning. 3

5 Artefaktmodellen Den här modellen visar hur de viktigaste arbetsredskapen som kunden använder fungerar och används. De är dessa arbetsredskap som kunder använder för att lösa deluppgifter med i sekvensmodellen och kanske skickar mellan sig i flödesmodellen. En artefaktmodell är oftast en fotokopia av arbetsredskapet på vilken man skriver ner viktiga funktioner och hur artefakten används. Den kulturella modellen Med hjälp av den här modellen kan man synliggöra värderingar och outtalade regler inom en organisation. Man skall försöka göra diagram där det går att utläsa vilka element som fungerar som påtryckare på organisationskulturen. Att känna till dessa kan vara mycket viktigt då man skall designa system om man överhuvudtaget vill få kunderna att använda det. Den fysiska modellen Med hjälp av den fysiska modellen beskrivs hur arbetsplatsens fysiska miljö påverkar arbetet. Den visar alltså hur kunden interagerar med den fysiska miljön för att utföra sina arbetsuppgifter. Konsolidering Nästa steg är att sätta ihop individuella diagram för att få en bild av alla användares arbetssätt. Detta är viktigt då systemen oftast ska passa många. Man letar alltså efter en generell struktur bakom alla individuella parametrar. Det gäller att alla i teamet kan se det generella mönstret utan att förlora individuell variation. Konsolideringsfasen i kontextuell design för samman data från olika användare och procedurer till en bild av användarna som systemet ska möta. Detta görs genom att uppföra ett samhörighetsdiagram samt konsoliderade arbetsmodeller. Ett samhörighetsdiagram är ett hierarkiskt diagram där de individuella fakta som erhållits under tolkningstillfället visar vilka problem som är gemensamma för de intervjuade personerna. De konsoliderade arbetsmodellerna visar det underliggande mönstret i arbetet som den nya designen ska möta. I tolkningsfasen skapades fem olika arbetsmodeller för varje person som intervjuats. Dessa skall i konsolideringsfasen slås samman (konsolideras) till en 4

6 generell arbetsmodell, exempelvis skall alla olika flödesmodeller som skapats konsolideras till en generell flödesmodell, för alla som intervjuats. Tillsammans visar de vad som är viktigt i projektet och vägleder till hur utvecklingen ska strukturera en sammanhängande lösning. Konsoliderad flödesmodell I den konsoliderade flödesmodellen tas gemensamma roller för arbetsuppgifterna fram. Modellen visar vilka användarna är och med vilka de interagerar. Att konsolidera flödesmodeller innebär att identifiera och kombinera roller som olika individer innehar. Konsolideringen sker genom att ta reda på när olika användare har samma roller i olika arbetssituationer, och se till att denna roll blir en enskild roll i systemet. Om en användare har flera olika roller, ska systemet avlasta användaren genom att till exempel automatisera vissa uppgifter eller flytta vissa roller till andra personer. Målet med dessa modeller är framförallt att ta reda på vilka roller som är beroende av varandra och hur de kommunicerar för att kunna utföra arbetet. Det är sedan viktigt att systemet stödjer denna kommunikation. Denna modell bör användas närhelst ett arbete kräver interaktion med andra användare eller system. Konsoliderad sekvensmodell Sekvensmodellen visar de steg en användare tar för att utföra sina arbetsuppgifter, och klarlägger vilka steg som är nödvändiga, samt vilka som kan tas bort. Modellen tar alltså fram strukturen av en arbetsuppgift, och detta görs genom att visa de gemensamma strategier för att lösa en uppgift som delas av användarpopulationen. Nyckeln till att upptäcka den generella strukturen är att identifiera aktiviteter som existerar i alla sekvenser i hela användargruppen, och att förstå meningen bakom varje aktivitet i sekvensen. Om strukturen beror av uppgiften i sig, kan den byggas in i det nya systemet, men om strukturen beror av begränsningar i arbetssituationen ska den tas bort i det nya systemet för att effektivisera arbetet. Konsoliderad artefaktmodell Artefaktmodellen visar hur artefakterna i arbetet används och vad avsikten med dem är. Denna modell visar hur människor strukturerar sitt arbete över tiden. Den visar gemensamma organiseringssätt och koncept som människor använder för att skapa ett mönster i sin vardag. Denna modell kompletterar den sekventiella genom att beskriva saker som hanteras under en sekvens som beskriver arbetsuppgiften. Artefaktmodellen visar hur information grupperas och underlättar därmed gränssnittsdesignen. 5

7 Konsoliderad kulturell modell Den kulturella modellen visar de värderingar, standarder, restriktioner, relationer och policys som finns inom ett företag. Kulturen behöver inte vara unik inom en användargrupp med samma arbetsuppgifter. För att ett system ska bli bra bör det stämma överens med företagets kultur. Konsoliderad fysisk modell Genom den fysiska modellen beskrivs arbetssituationens fysiska miljö och förutsättningar. För att stödja arbetet ska till exempel objekt som användarna utnyttjar finnas i den fysiska närheten, och detta betyder också att de ska vara lätt tillgängliga även i systemet. Den fysiska modellen visar hur den gemensamma strukturen av den fysiska miljön påverkar arbetet i användarpopulationen, och även de variationer som systemet måste kunna klara av. Modellen håller designteamet medvetet om de begränsningar som den fysiska miljön utgör. Den visar också hur rumsliga och layoutmässiga aspekter påverkar arbetet. Genom att sedan sätta upp de konsoliderade arbetsmodellerna och samhörighetsdiagrammet på väggen, får alla i teamet en gemensam bild av processen, och detta är något som förespråkas av kontextuell design. Dessutom ska dessa steg göras väldigt snabbt; det skall helst bara ta en dag för att få till samhörighetsdiagrammet och en dag var till varje konsolideringsmodell. Detta för att det gynnar fokus på helheten. Från data till design Enligt författarna krävs vid övergången från data till design ett kreativt hopp från en fokusering på vad som är viktigt till vad som ska göras åt det. Gruppen föreslår designlösningar som bygger på de färdigheter och de kunskaper som gruppen själv besitter samt deras gemensamma syn på designarbetet. För att inte begränsa gruppens kreativitet uppmuntras gruppmedlemmarna att tänka brett, stort och radikalt utan att ta hänsyn till andra faktorer. Detta för att i senare skedet putsa och förfina idéerna efter de olika utvärderingar som ingår i processen. 6

8 Kontextuell design består av fyra steg: (1) att gå genom data för att se de olika aspekterna av arbetet; (2) att formulera de möjliga lösningarna; (3) att utveckla en enkel corporate response ; och (4) att utveckla de olika delarna av systemet parallellt. Genomgång av data I det moment där data studeras, börjar man med att gå igenom kunddata, en process som kallas Walking the wall. Rent konkret innebär detta att man går igenom samhörighetsdiagrammet och de konsoliderade arbetsmodellerna som man satt upp på väggen i konsolideringsfasen. Denna genomgång av data leder till att gruppmedlemmarna har materialet i huvudet inför visualiseringsmomentet som ska grunda sig på kunddata. Efter genomgången av data fortsätter gruppen processen genom att med hjälp av modellerna arbeta fram olika perspektiv på arbetet. Nästa steg är visionsprocessen och innan man påbörjar denna tar man fram två listor. Den ena redogör för de tänkbara tekniker som kan användas för att lösa problemen och den andra innehåller startpunkter, Starting points, dvs. de inledande diskussionerna om hur gruppen bör lösa problemet. Vision Under visionsprocessen väljer teamet en starting point och utvecklar den till en beskrivning av det nya arbetssättet. Visionen växer fram i och med att gruppmedlemmarna kommer med idéer och förslag på hur arbetsmodellerna kan förändras och utvecklas. I de flesta fallen resulterar visionsprocessen till mångsidiga visioner. Dessa behandlas var för sig, bl a genom att man tar fram och analyserar de negativa och de positiva aspekterna hos varje vision. I slutskedet av en kontextuell design, tar man fram en ny lösning som bygger på det bästa av de olika visionerna. Storyboards Under visionsprocessen visionerar gruppen och kommer fram till nya spännande arbetssätt. De nya arbetssätten preciseras med hjälp av en storyboard. Denna visar hur de olika arbetsuppgifterna fungerar inom ramen för det nya arbetssättet. Denna metod, som är hämtad från filmvärden, syftar till att ta fram beskrivning som visar en enkel scen, exempelvis interaktion mellan två personer, eller mellan en person och ett system, samt innehållet i denna 7

9 interaktion. Samtidigt som storyboards grundar sig på visionen underordnar de sig den konsoliderade sekvensmodellens struktur. Därför kan arbetsuppgiften som behandlas i en storyboard också beskrivas i form av en konsoliderad sekvensmodell. Användarmiljödesign User Environment Design (UED) Ett nytt system måste ha lämpliga funktioner och en lämplig struktur för att stödja det naturliga arbetsflödet. För att få fram detta använder man inom kontextuell design något som heter användarmiljödesign. Användarmiljödesign har samma betydelse inom kontextuell design som kartläggningen av våningsplan i husdesign för arkitekter. Användarmiljödesignen visar varje del i systemet, hur det stödjer användarnas arbete, exakt vilka funktioner som är tillgängliga i den delen, och hur användarna tar sig till och från andra delar i systemet utan att knyta strukturen till något särskilt användargränssnitt. Användarmiljödesignen byggs på successivt utifrån storyboards som man går igenom en i taget. Storyboards går igenom sekventiellt vad som händer för att utföra en uppgift. Det arbete som varje storyboard presenterar definierar fokusområdena i användarmiljön. Varje storyboard innehåller information om platser, funktioner och länkar i användarmiljödesignen. Diskussioner om varje cell på en storyboard leder till identifieringen av nya fokusområden. Efter att ha infogat innebörden av varje storyboard i användarmiljödesignen så ser man över hela användarmiljödesignen för att bibehålla sammanhållningen av systemet. Fokusområde I användarmiljödesign kallas platser i systemet där användarna fokuserar på en sorts arbetsuppgift för fokusområde. Varje fokusområde har ett syfte för arbetet som det stödjer. Om det inte går att skriva en enkel mening som beskriver syftet av fokusområdet för att det innehåller så många olika funktioner som gör olika saker så är antagligen systemet dåligt strukturerat. När fokusområden som överlappar varandra identifieras så sätter man ihop dessa till ett fokusområde. Man ser över användarmiljödesignen och tar bort funktioner som är onödiga och ser till att varje fokusområde har ett klart syfte och lämpliga länkar till resten av systemet. Varje fokusområde presenterar en sammanhängande plats att utföra arbete på. Länkarna mellan platserna visar hur systemet stödjer flödet av aktiviteter men beskriver inte vilken ordning arbetet ska utföras. Ett fokusområde innehåller alltså syftet med området, listor 8

10 med de funktioner som ska ingå i området, länkar till andra fokusområden samt vilka objekt som berörs i de aktuella fokusområdena. När alla fokusområden är gjorda och länkarna mellan dem är dragna så ger de en bra överblick av det nya systemets struktur. Projektplanering Det kan bli problem när man har stora projekt där man skall bygga stora system eller knyta ihop flera befintliga. Man kan inte göra allt på en gång. Det gäller att kunna producera dellösningar som tillslut kan utgöra ett helt system. Författarna menar därför att man kan använda sin användarmiljödesign för att identifiera flera mindre deluppgifter som systemet ska klara av och sedan börja med att implementera dessa. Detta görs genom att man studerar användarmiljödesignen och tittar på vilka fokusområden som kan fungera som delsystem. Omvänd användarmiljödesign En omvänd användarmiljödesign gör man på system som redan existerar för att få fram deras underliggande struktur och få en överblick av hur de olika delarna i systemet sitter ihop. Den omvända användarmiljödesignen avslöjar vad användarna kan göra i systemet och de antaganden som byggts in i systemet om användarnas arbete. En omvänd användarmiljödesign kan vara bra för att analysera vilka styrkor och svagheter en konkurrerande produkt har, eller för att avslöja strukturen på flera system som måste integreras, eller för att se hur den nuvarande systemversionens struktur ser ut för att kunna göra en ny och bättre version av systemet. Pappersprototyper Testning är viktigt i alla delar av systemutveckling. Det är generellt accepterat att ju fortare man hittar problemen ju mindre kostare det att åtgärda dem. Så det är viktigt att testa och iterera en design tidigt, före någon investerar i designen och någon kod blivit skriven. Ju enklare testningsprocess ju fler iterationer kan man göra för att fundera ut den detaljerade designen med sina användare. I kontextuell design använder man pappersprototyper som grova modeller av systemet där Post-it lappar används för att presentera fönster, dialogrutor, knappar och menyer. Designteamet testar dessa prototyper med användare på deras arbetsplats när de utför riktiga 9

11 arbetssysslor på det föreslagna systemet. När användarna upptäcker problem så omdesignar de prototypen tillsammans med designerna så att den tillfredställer deras behov. Grova pappersprototyper av systemdesignen testar strukturen av användarmiljödesignen och de grundläggande idéerna innan något kodats. Får man en designidé så skissar man ner den på papper och testar den på en gång med användarna för att se om den fungerar. Författarna säger att det enda egentliga skälet till att göra en pappersprototyp är för att stödja konversationen mellan användare och designers om hur man ska modifiera det föreslagna systemet så att det passar användarens arbete bättre. Uppgift Köksportalen Uppgiften går ut på att planera ett användarcentrerat projekt för att utveckla en e-handelstjänst (Köksportalen) för att hjälpa privatpersoner vid inköp av köksutrustning. Systemet skall möjliggöra för användaren att planera, hitta, välja och köpa hela eller delar av kök från olika leverantörer. Den skall också hjälpa användarna att beställa hantverkare till olika arbeten. Lösning I boken kontextuell design utgår författarna från att man skall gå till en kunds arbetsplats och studera hur arbetet går till där för att sedan omdesigna deras arbetsuppgifter och skapa nya system till dem. Vårt fall har inte samma förutsättningar. Vi skall istället försöka skapa ett nytt verktyg för privatpersoner och kan inte på samma sätt sätta oss in i kontexten på en arbetsplats. Intervjuer För att förstå hur man skulle kunna ta fram ett system för inköp av köksutrustning tänker vi studera hur professionella inköpare arbetar genom att intervjua dessa enligt mästarlärlingsmodellen. Vi tänker också ta reda på hur vanliga privatpersoner löser den här uppgiften. Det blir dock svårt att intervjua dessa när de arbetar eftersom de troligtvis inte gör allt på en gång. Därför går vi här ifrån bokens mästarlärlingsmodell och ber istället privatpersonerna att föra dagbok över sitt arbete med sitt nya kök. I dessa kommer det att 10

12 avslöjas om privatpersonerna har använt konkurrenters köksportaler. Vi kommer att välja ut ett par av dessa personer för intervju gällande deras erfarenheter av andra portaler. I samband med detta tar vi fram omvända användarmiljödesigner för dessa system. De som arbetar professionellt och de som redan utfört inköpsuppgiften är dock kanske inte de som i slutänden kommer att använda vårt system. Därför är det viktigt att också sätta sig in hur vanliga privatpersoner tror att de skall gå till väga för att lösa den här uppgiften. Detta för att bättre kunna anpassa det nya systemet efter dessa personers uppfattning av hur uppgiften borde lösas. Därför kommer ett antal privatpersoner som inte ännu gjort några inköp intervjuas. När intervjuerna utförs och dagböckerna gås igenom finns det mycket att tänka på. Det är mycket viktigt att stämma av att man tolkat informationen man fått rätt. Under intervjuerna skall man därför kontinuerligt sammanfatta och fråga om man tolkat svaren rätt. De sammanfattade inköpsprocesserna från dagböckerna stäms av med dagboksförfattarna genom att man kontaktar dessa i samband med detta genomför man också en liten mindre intervju med dagboksskrivarna om hur de gått tillväga. Tolkning Sedan skall hela gruppen träffas för att tillsammans tolka all data från intervjuerna. Detta för att alla projektdeltagare skall få en gemensam bild av situationen. Här är det den som utfört intervjun som skall berätta om vad han fått fram genom att bli intervjuad av de övriga deltagarna. Under tolkningssessionen ska de första arbetsmodellerna skapas, detta utförs medan intervjuaren berättar om intervjun, av andra projektdeltagare. Under mötet skriver också en sekreterare ner allt som sägs för att man senare skall kunna gå igenom det och inte förlora någon information. Projektledaren är moderator under tolkningsmötet och ser till att det flyter på, håller sig till ämnet och att alla får komma till tals. De intervjuer som givit material lämpligt att ta fram arbetsmodeller för är de som beskriver inköpsprocessen. Detta material består av de svar vi fått från professionella kökskonsulter och de dagböcker vi fått in. Utifrån studier av professionella inköpare på deras arbetsplats samt intervjuer av dessa kan vi ta fram alla fem arbetsmodeller som författarna talar om. Med hjälp 11

13 av dessa får vi en bra förståelse av hur inköpsprocessen bör gå till. Ur dagböckerna är det framförallt flödes-, sekvens- och artefaktmodellerna som blir möjliga att skapa. Konsolidering När arbetsmodellerna från intervjuerna är genomförda är det viktigt att snabbt göra ett samhörighetsdiagram. I vårt fall blir samhörighetsdiagrammet en viktig pusselbit för att kunna skapa ett användbart system. Detta eftersom kunddata bygger på många olika typer av användare gäller det att identifiera de gemensamma problem som angivits. Genom att göra ett samhörighetsdiagram får man dels en bra bild på de gemensamma problem som de olika användarna upplevt under inköpsprocessen. Dessutom kommer de individuella problemen att synliggöras. Vi kommer alltså att sätta upp Postit-lappar på väggen i en hierarkisk struktur där varje lapp representerar ett problem som vårt system ska lösa. De viktigaste problemen dvs. de gemensamma kommer att hamna högst upp i hierarkin. Vi har som nämnts tidigare skapat arbetsmodeller för olika typer (professionella på företag och privatpersoner hemma) av användare. Detta försvårar konsolideringsprocessen. Vi kommer bara att ha sekvens-, flödes och artefaktmodeller från privatanvändare medan vi noggrant studerat de professionella användarna och därför kunnat skapa alla fem arbetsmodeller för dessa. Man kan därför inte konsolidera alla arbetsmodeller och man kan fråga sig om de kulturella- och fysiska arbetsmodellerna från de professionella användarna verkligen behövs. Vi kommer dock att kunna ta fram konsoliderade sekvens-, flödes-, och artefaktmodeller och vi är övertygade om att det faktum att vi utgått från både privatpersoner och professionella användare leder till att vi får en helhetsbild och kan skapa ett smartare system. Innovation Innan vi kan börja visionera måste vi ordentligt gå igenom allt vårt material. Detta material utgörs av de konsoliderade arbetsmodellerna, samhörighetsdiagrammet, intervjusvar från vanliga privatpersoner som inte tidigare köpt in köksutrustning, synpunkter på konkurrenters system från dagboksskrivarna och slutligen de omvända användarmiljödesigner som tagits fram utifrån våra konkurrenters system. Vi skall alltså walking the wall för att förbereda inför visionsprocessen helt i författarnas anda. 12

14 Vi kommer att skapa ett antal olika visioner som bygger på idéer som tar hänsyn till de skilda rollerna (flödesmodellen), de olika arbetsuppgifterna (sekvensmodellen) och de detaljerade konceptuella strukturerna (artefaktmodellen) för att senare kunna sammanföra dessa till en helhetsbild som kan ligga till grund för hela arbetet. Detta resulterar till en ritning av hur det nya e-handelsystemet kommer att fungera. För att kunna redogöra för funktionen hos de olika delarna i systemet kommer vi att använda oss av storyboard. Vi kommer alltså att beskriva hur varje arbetsuppgift skall lösas i vårt nya system. Användarmiljödesign Vi går igenom alla våra storyboards och skriver ner de fokusområden vi hittar, syftet med varje fokusområde samt listar vilka funktioner som fokusområdet ska innehålla och hur de ska vara länkade till varandra. På detta sätt får vi fram en grundläggande struktur för systemet de författarna kallar användarmiljödesignen. Denna användarmiljödesign kan även ligga till grund för planeringen av implementeringen av systemet. Eftersom detta är ett relativt stort system kanske inte allt kan implementeras direkt. Därför kan användarmiljödesignens fokusområden vägleda oss i valet av vilka delsystem som skall implementeras i den första releasen och i vilken ordning de skall implementeras. Prototyper, testning När användarmiljödesignen är färdig är det dags att ta fram prototyper och testa dessa på användare. Designteamet börjar därför med att göra några grova pappersprototyper med Positlappar för dialogrutor, knappar, menyer med mera. De tar idéer från de skisser som uppstått vid genomgången av storyboardsen. De grova inledande pappersprototyperna är till för att testa den struktur som användarmiljödesignen lett till. Vi har tidigare i projektet involverat ett antal olika typer av användare för att samla in data om inköpsprocessen. Det blir nu viktigt att vid testning fokusera på systemets målgrupp. Vi kommer därför att testa de grova pappersprototyperna på privatpersoner som för första gången skall köpa in köksutrustning. Men för att få lite extra synpunkter kommer också att besöka professionella köksinköpare på deras arbetsplatser och be dem att försöka utföra sina arbetssysslor på vår prototyp. Vi kommer dessutom att be dagboksskrivarna att testa att göra om sina verkliga inköp på vår prototyp. Men det är förstagångsanvändare synpunkter som väger tyngst. 13

15 Kommer det fram att något fokusområde inte fungerar kan förändringar i detta fokusområde påverka hela strukturen. Så vi ser noga över strukturen igen om vi gör några sådana förändringar. När strukturen är fastlagd går vi vidare och koncentrerar oss mer på användargränssnittet i testningen med pappersprototyper. Dessa skall förstås också testas men det kommer enbart att utföras med förstagångsanvändare. De här två stegen kommer att itereras tills vi är nöjda med användarnas respons på systemet. Sedan återstår själva implementeringen av systemet. Som nämnts tidigare avslöjar användarmiljödesignen vilka delsystem som blir möjliga att skapa och i vilken ordning de skall implementeras. Vi planerar projektet så att ett antal delsystem först skickas till utvecklingsteamet (systemutvecklarna). När de är klara ser vi till att testa dessa delsystem på användarna samtidigt som vi skickar in nya delsystem till utvecklingsteamet. På det sättet kan vi spara tid i projektet. De användare som blir aktuella för testning är desamma som vi använde vid testningen av användargränssnittets prototyper dvs. förstagångsanvändare. Vi jobbar på så här och skickar tillbaka det som måste göras om till utvecklingsteamet tills vi är nöjda med resultatet. Diskussion Fördelar med kontextuell design som den beskrivs i boken Contextual Design, Defining Customer-Centered Systems av Beyer och Holtzblatt är att användarna kommer i fokus genom processen. Man ser till att tidigt sätta sig in i användarens situation genom kontextuella intervjuer och man testar också sina lösningar på användare innan de implementeras. Vikten av att hela teamet får en gemensam bild med hjälp av gemensamma tolkningstillfällen, samhörighetsdiagram och konsoliderade arbetsmodeller tror vi är en nyckelfaktor för att utvecklingsteamet skall förstå varandra och lyckas med projektet. Arbetsmodellernas olika perspektiv på arbetssätten tror vi hjälper utvecklingsteamet att se helheten och inte fokusera för mycket på detaljer. Vi tycker vidare att storyboardsen verkar vara ett naturligt sätt att representera hur arbetsuppgifterna skall utföras och leder direkt vidare till de fokusområden som behövs för användarmiljödesignen. Att användarmiljödesignen förenklar arbetet för gränssnittsdesignern och möjliggör uppdelning i delsystem tycker vi också verkar bra. Vi hade dock lite svårigheter med att tillämpa metoden kontextuell design i vår uppgift och fick därför hitta på några egna lösningar för att erhålla användardata t.ex. våra 14

16 dagboksskrivare. Metoden verkar fungera utmärkt då man som utvecklare kommer till ett företag och skall omdesigna, vidareutveckla eller sätta ihop flera befintliga system. Det blir troligtvis enklare att hitta användare då man redan har en riktig kund och författarna använder också begreppet kund i boken genomgående. Något som skulle kunna uppfattas som en nackdel med processen är att den innehåller väldigt många steg. Utvecklarna skall ha tänkt ut hela systemet och testat allt innan någon som helst programmering sätts igång. De nya Agile-metoderna framförallt Refactoring men också Open Source utveckling har ett annat perspektiv på hur utvecklingen bör gå till. De menar att systemutveckling bör utgå från kod som sedan testas av många användare och skrivs om och itereras på detta sätt tills ett bra system skapats. En förespråkare av dessa synsätt skulle säkerligen tycka att kontextuell design är för omständig. Vad som leder till det mest användbara systemet är dock svårt att svara på. Tidplan för framställning av köksportal Projektets anställda och användare: Projektet förfogar över en projektledare P samt fyra användbarhetsdesigners A1, A2, A3 och A4 samt tio systemutvecklare S1, S2,, S9 och S10. Tjugo privatpersoner som planerar köksinköp blir dagboksskrivare av inköpsprocessen D1,, D20. Sedan har vi även fyra användare som är yrkesverksamma köksinköpare, dessa kallar vi professionella PK1, PK2, PK3 och PK4. Ytterligare användare kommer att behövas för tester. Dessa kallas AN1 ANx. Sedan finns även några konkurrentportaler som kallas K1, K2 och K3. Inledande informations- och planeringsmöte. Ett informations- och planeringsmöte med projektledare och de blivande projektdeltagarna. Mantid: P = 4 timmar, A1 A4 = 3 timmar, S1 S10 = 3 timmar. Kalendertid: Dag 1 i Vecka 1. Utformande av dagbok och instruktioner för dagboksskrivandet. Användbarhetsdesignerna utformar ett missivbrev samt instruktioner som ska delas ut tillsammans med dagböckerna till köksinköpare. Mantid: A1 = 14 timmar, A2 =14 timmar, A3 = 14 timmar, A4 = 14 timmar. Kalendertid: Dag 2 och Dag 3 i Vecka 1. Leta reda på ställen som säljer kök och köksutrustning. Användbarhetsdesignerna tar två timmar att spåna var de ska åka och dela ut dagböckerna dagen därpå. De kollar upp adresser med mera. Mantid: A1 = 2 timmar, A2 = timmar, A3 = timmar, A4 = timmar Kalendertid: Dag 3 i Vecka 1. 15

17 Hitta privatpersoner som planerar köksinköp plus professionell inköpare. Här låter vi A1, A2, A3 och A4 dela på sig och åka ut till olika ställen där man kan köpa kök och köksutrustning under två dagar. De får i uppgift att hitta minst fem personer var som planerar att göra köksinköp och förse dem med varsin dagbok. De ska också hitta sig varsin professionell köksinköpare på något av de olika ställena som de kan följa med en dag på jobbet och utföra en kontextuell intervju på. De ska dessutom hitta ett antal privatpersoner som vill köpa in köksutrustning men ännu inte börjat planera inköpsprocessen. Dessa skall alltså inte förses med dagbok utan istället intervjuas angående om hur de tror processen skall gå till. Mantid: A1 = 16 timmar, A2 = 16 timmar, A3 = 16 timmar och A4 = 16 timmar. Kalendertid: Dag 4 och Dag 5 i Vecka 1. Påläsning i ämnet. Intervjuförberedelser. Framtagning av konkurrenter. Användbarhetsdesignerna sätts att läsa allt som finns i ämnet och kolla upp vilka andra portaler i området som finns som kan tänkas bli konkurrenter. De väljer ut några som möjliga konkurrenter som man vill göra en omvänd användarmiljödesign på. Under påläsningen förbereder de sig för mästarlärlingsintervjuerna som de bokat in i Vecka 4. Mantid: A1 = 24 timmar, A2 = 24 timmar, A3 = 24 timmar och A4 = 24 timmar. Kalendertid: Dag 6, Dag 7, Dag 8 i Vecka 2. Omvänd användarmiljödesign. Vi säger att användbarhetsdesignerna har hittat tre konkurrentportaler K1, K2 och K3. Hela utvecklingsgruppen deltar i detta arbete. Som beräknas ta två dagar för varje konkurrentportal. Mantid: P = 55 timmar, A1 A4 = 55 timmar, S1 S10 = 55 timmar Kalendertid: Dag 9 och Dag 10 i Vecka 2, Dag 11 till Dag 14 i Vecka 3. Milstolpe. Överblick över de färdiga omvända användarmiljödesignerna. Utvecklingsgruppen ser över sina tre färdiga omvända användarmiljödesigner av K1, K2 och K3. Mantid: P = 1 timma, A1 A4 = 1 timma, S1 S10 = 1 timma. Kalendertid: Dag 14 i Vecka 3. Kontextuella intervjuer utförs. Användbarhetsdesignerna genomför sina intervjuer efter mästarlärlingsmodellen på de professionella köksinköparna. Dagen därpå utförs intervjuer med vanliga privatpersoner som ej för dagbok om hur de tror man går tillväga vid köksinköp. Mantid: A1 - A4 = 16 timmar, PK1 PK4 = 8 timmar, AN1 ANx = 1-2. Kalendertid: Dag 16 och Dag 17 i Vecka 4. Tolkning 1 Tolkning av de kontextuella intervjuerna på professionella köksinköpare samt tolkning av intervjuer med privatpersoner. Hela utvecklingsgruppen deltar. Intervjuaren blir intervjuade av de andra i teamet som samtidigt som intervjuaren berättar skissar på de fem arbetsmodellerna. En person är sekreterare och skriver ner allt som sägs. Projektledaren är moderator vid tolkningstillfället. Mantid: P = 32 timmar, A1 A4 = 32 timmar, S1 S10 = 32 timmar. Kalendertid: Dag 17, Dag 18, Dag 19 och Dag 20 i Vecka 4. 16

18 Insamling och genomgång av dagböckerna. Avstämning/telefonintervju med dagboksskrivaren. Dagböckerna samlas in under Dag 21 i Vecka 5 och gås igenom de två följande dagarna. Alla utom projektledaren tar varsin dagbok för genomläsning. Användbarhetsdesignerna läser två och ytterligare två i teamet får göra detta. När de läst igenom ringer de upp och stämmer av med dagboksskrivaren att de förstått allt riktigt. Har dagboksskrivaren använt någon av konkurrentportalerna blir han intervjuad om intrycket av denna. Mantid: A1 A4 = 24 timmar, S1 S10 = 24 timmar. D1 D20 = 1 timma. Kalendertid: Dag 21, Dag 22 och Dag 23 i Vecka 5. Tolkning 2 Tolkning av dagböcker och intervjuer med dagboksskrivare. Hela utvecklingsgruppen deltar. Läsaren/intervjuaren blir intervjuad av de andra i teamet medan han berättar en sammanfattning av inköpsprocessen i dagboken och av intervjun med dagboksskrivaren. Projektledaren agerar moderator, en i teamet är sekreterare och de övriga är ansvariga för att skissa på arbetsmodellerna som i detta fall blir främst flödesmodellen, sekvensmodellen och artefaktmodellen. Mantid: P = 55 timmar, A1 A4 = 55 timmar, S1 S10 = 55 timmar. Kalendertid: Dag 24 och Dag 25 i Vecka 5. Dag 26 Dag 29 i Vecka 6. Milstolpe. Överblick över de färdiga tolkningarna/arbetsmodellerna. En överblick/sammanfattning innan man går in i konsolideringsfasen. Mantid: P = 1 timma, A1 A4 = 1 timma, S1 S10 = 1 timma. Kalendertid: Dag 29 i Vecka 6. Konsolideringen inleds med ett samhörighetsdiagram. Alla i projektet deltar i framtagandet av ett samhörighetsdiagram för att få en bra överblick över de gemensamma och individuella problem som användarna stött på. Mantid: P = 8 timmar, A1 A4 = 8 timmar, S1 S10 = 8 timmar. Kalendertid: Dag 30 i Vecka 6. Konsoliderad flödesmodell. Alla i projektet deltar i framtagandet av en konsoliderad flödesmodell. Mantid: P = 8 timmar, A1 A4 = 8 timmar, S1 S10 = 8 timmar. Kalendertid: Dag 31 i Vecka 7. Konsoliderad sekvensmodell Alla i projektet deltar i framtagandet av en konsoliderad sekvensmodell. Mantid: P = 8 timmar, A1 A4 = 8 timmar, S1 S10 = 8 timmar. Kalendertid: Dag 32 i Vecka 7. Konsoliderad artefaktmodell Alla i projektet deltar i framtagandet av en konsoliderad artefaktmodell. Mantid: P = 8 timmar, A1 A4 = 8 timmar, S1 S10 = 8 timmar. Kalendertid: Dag 33 i Vecka 7. Konsoliderad kulturell modell Alla i projektet deltar i framtagandet av en konsoliderad kulturell modell. Mantid: P = 7 timmar, A1 A4 = 7 timmar, S1 S10 = 7 timmar. 17

19 Kalendertid: Dag 34 i Vecka 7. Konsoliderad fysisk modell Alla i projektet deltar i framtagandet av en konsoliderad fysisk modell. Mantid: P = 8 timmar, A1 A4 = 8 timmar, S1 S10 = 8 timmar. Kalendertid: Dag 35 i Vecka 7. Milstolpe. Överblick över de färdigkonsoliderade arbetsmodellerna. Projektgruppen ser över sina färdig konsoliderade arbetsmodeller. Mantid: P = 1 timma, A1 A4 = 1 timma, S1 S10 = 1 timma. Kalendertid: Dag 35 i Vecka 7. Walking the wall. Projektdeltagarna går igenom all kunddata. Efter genomgången av kunddata fortsätter de processen med hjälp av modellerna och tar fram olika perspektiv på arbetet. De tar fram två listor, en för tänkbara tekniker och en som innehåller startpunkter till diskussioner om hur olika problem bör lösas. Mantid: P = 24 timmar, A1 A4 = 24 timmar, S1 S10 = 24 timmar. Kalendertid: Dag 36, Dag 37 och Dag 38 i Vecka 8. Vision och storyboard Projektdeltagarna tar fram förslag på hur arbetsmodellerna kan förändras och utvecklas. Det nya arbetssättet för varje arbetsuppgift skissas ner på varsin storyboard. Mantid: P = 56 timmar, A1 A4 = 56 timmar, S1 S10 = 56 timmar. Kalendertid: Dag 39 och Dag 40 i Vecka 8, Dag 41 Dag 45 i Vecka 9. Användarmiljödesign En användarmiljödesign av systemet utvecklas genom genomgång av varje storyboard. Det arbete som utförs på storyboarden definierar ett fokusområde i den blivande systemstrukturen. Mantid: P = 24 timmar, A1 A4 = 24 timmar, S1 S10 = 24 timmar. Kalendertid: Dag 46, Dag 47 och Dag 48 i Vecka 10. Grova pappersprototyper för testning av strukturen tas fram. Användbarhetsdesignerna tar fram en grov pappersprototyp för testning av användarmiljödesignen. Mantid: A1 A4 = 16 timmar Kalendertid: Dag 49 och Dag 50 i Vecka 10. Testning av strukturen med grova pappersprototyper. Användbarhetsdesignerna utför användbarhetstester med privatpersoner och professionella köksinköpare samt några av våra dagboksskrivare. Mantid: A1 A4 = 24 timmar, AN1-AN6 = 2 timmar, D1-D6 = 2 timmar, PK1 och PK2 = 4 timmar. Kalendertid: Dag 51, Dag 52 och Dag 53 i Vecka 11. Iteration, vidareutveckling, testning av gränssnittsprototyp. Användbarhetsdesignerna utför tester, vidareutvecklar och förfinar gränssnittet till systemet och testar på användarna igen. 18

20 Mantid: A1 A4 = 120 timmar, AN1-ANx = 2 timmar åt gången. Kalendertid: Dag 54 och Dag 55 i Vecka 11. Dag 56 Dag 60 i Vecka 12. Dag 61 Dag 65 i Vecka 13. Dag 66 Dag 68 i Vecka 14. Milstolpe. Genomgång av färdig struktur och användargränssnitt. Kick-off med alla projektdeltagare innan systemet börjar implementeras. Ordningen på implementeringen av delsystemen bestäms. Mantid: P = 8, A1 A4 = 8 timmar, S1 S10 = 8 timmar. Kalendertid: Dag 69 i Vecka 14. Implementering av delsystem. Systemutvecklarna implementerar systemets delsystem. Mantid: S1 S10 = 128 timmar. Kalendertid: Dag 70 I Vecka 14, Dag 71 Dag 75 i Vecka 15. Dag 76 Dag 80 i Vecka 16. Dag 81 Dag 85 i Vecka 17. Dag 86 Dag 90 i vecka 18. Testning av delsystem. Användbarhetsdesignern testar delsystemen allteftersom de blir färdiga. Mantid: A1 A4 = 32 timmar. AN1 ANx = 2 timmar. Kalendertid: Dag 75 i Vecka 15, Dag 80 i Vecka 16, Dag 85 i Vecka 17 och Dag 90 i Vecka 18. Milstolpe. Sjösättning av hela systemet. Någon gång i Vecka 20 uppskattar vi att sjösättningen blir av. Men som alltid när det gäller systemutveckling får man ta tiduppskattningen med en nypa salt. 19