Användarcentrerad Systemdesign En mediecentral och Contextual Design

Användarcentrerad Systemdesign En mediecentral och Contextual Design Daniel Odervång daniel@forumet.nu Leon Ljunggren Lelj1171@student.uu.se Robert Albrektsson roal411@hotmail.com Robin Sving rosv3579@student.uu.se

Innehållsförteckning Contextual Design en introduktion... 3 Användarfrågorna... 5 Identifiera användargrupper... 5 Hitta användare... 5 Involvera användare... 6 Informationsinsamlingen... 7 Artefakter... 8 Implementation... 9 För- och nackdelar:... 10 Tidsplan... 11 Förklaring av tidsplan... 12 Källförteckning... 13

Contextual Design en introduktion Contextual Design är en amerikansk paketlösning som innehåller flera metoder för att driva ett utvecklingsprojekt på ett användarcentrerat sätt. Den lägger sin tyngdpunkt på att man måste förstå användarna och deras normala arbetsmiljö innan det går att utveckla ett nytt system åt dem. Genom att lägga ner mycket tid på att studera hur de använder sitt befintliga system, hur information flödar och hur de tänker fås mycket data som senare omvandlas till flödesdiagram och slutligen ger upphov till en prototyp av en designlösning. Contextual Inquiry o Det första steget i processen går kortfattat ut på att inhämta information om användarna och hur de använder sitt befintliga system idag. Det finns olika metoder att använda, bland annat Master-Apprentice-metoden. Interpretation Session o I det andra steget samlas alla inblandade i projektet för att gemensamt gå igenom all data från det första steget. Alla har möjlighet att presentera sina unika erfarenheter från användarna och deras sätt att jobba. I det här steget ges alla en samlad bild över arbetet.

Consolidation o Med utgångspunkt från användardata insamlad i steg 1 och 2 görs ett stort diagram där alla olika användares behov finns med. Ofta ger det här möjlighet att se gemensamma användarbehov som flera olika typer av användare har. Det här diagrammet, kallat affinity-diagram, används för att ge alla involverade i projektet en bild över hur saker och ting hänger ihop. Det är motsatsen till att bryta ner de olika delarna i listor över saker att göra. Work Redesign o Med utgångspunkt från affinity-diagrammet från föregående steg diskuteras hur modern teknik kan användas för att hjälpa användarna att utföra sina sysslor. I det här steget skapas visioner, i form av så kallade story boards, som innehåller användare, systemet och alla hjälpsystem som så småningom kommer att finnas på plats hos användarna. Visionerna ritas oftast upp för hand och är en plan över hur systemet kommer att fungera i slutändan. User Environment Design o För att underlätta arbetsfördelningen mellan olika grupper inom projektet görs en så kallad floor plan upp. Den kan ses som en flödesritning som visar de olika delsystemen och precis vad de fyller för syfte och har för funktioner. Kopplingen mellan olika delar och hur användarna kan röra sig mellan dem ska också framgå. Med en korrekt floor plan ökas förståelsen för hur de olika delarna sitter ihop och hur kopplingarna mellan dem ska ske. Paper Prototyping o Genom att bygga upp designlösningar i form av enkla pappersmodeller kan problem tidigt upptäckas. Användarna presenteras, i sin normala arbetsmiljö, med normala arbetsuppgifter där det nya systemet finns på plats i form av pappersmodeller. Eftersom ingen design redan är programmerad eller utförd på annat sätt går det snabbt att ändra i designförslaget och det tillåter många iterationer under kort tid. Hela metoden bygger på det allmänt accepterade faktum att ju tidigare ett fel i designen upptäcks desto billigare är det att åtgärda i form av både pengar och tid. Efter många iterationer med användarna påstår sig Contextual Design-metoden ha uppnått god användbarhet. Transition to Implementation o I det avslutande steget sker förvandlingen mellan designen av systemet och det faktiska utvecklandet av systemet (programmeringen exempelvis). Det finns många sätt att göra den här övergången på, men den vanligaste är att skriva funktionsspecifikationer utifrån den information som finns tillgänglig från User Environment Design och Paper Prototyping där användarna fick vara med och utarbeta en design som fungerade.

Användarfrågorna Identifiera användargrupper När man designar ett system så är det viktigt att veta vilka användargrupper som systemet ska inriktas till. Olika användare har i regel skilda behov som kräver av produkten olika designlösningar. Om ett system ska designas för mediefantaster så kommer det att vara viktigt att bilden och ljudet är av yttersta kvalitet och att det finns många avancerade funktioner som hjälper till att förstärka upplevelsen, till exempel en avancerad equalizer. En sådan person skulle inte kräva ett simpelt interface, då denne skulle lära sig alla funktioner som den ville ha oavsett hur svårt, men skulle produkten vara inriktad på äldre herrar i sin medelålderskris så skulle produkten vara skapad mer med imponerande yttre attribut än med inre. En stor skärm är oftast viktigare än skärmens upplösning, ljudet kan vara skapat med budget i åtanke, och om mediecentret är för avancerat så kommer inte användaren att kunna nyttja produkten till dess fulla kapacitet. Tekniken Contextual Design, som är anpassad för att utveckla en företagsbeställd produkt, tar inte upp hur man kan välja sina användargrupper redan då systemet beställts. Det företag som beställer produkten brukar vanligtvis veta vilka som produkten är till för. Detta görs oftast inom företagets marknadsavdelning innan en produkt skapas, för att se om projektet kommer att vara ekonomiskt försvarbart. Contextual Design utgår ifrån att information om användargrupperna redan finns tillgänglig. Även om man oftast får användargrupperna bestämda av företaget, så finns det tillfällen då företaget inte kan ge en specifik användargrupp utan vill designa projektet för alla användare eller ger en användargruppsindelning som är mer eller mindre felaktig. Det är då upp till projektgruppen att analysera vilka användargrupper som finns. För att hitta användargrupperna så finns det många tillvägagångssätt som används idag, men många av dessa kan dock, ur ett användarcentrerat synsätt, anses vara obrukbara. Ska man göra det användarcentrerat så räcker det inte med att sitta och spåna inom gruppen, utan man måste självklart inkludera användarna i processen. Till exempel så kan man skicka ut en mängd enkäter till personer av olika social status, åldrar, kön, arbetssituation (inkomst) och etniska grupper, samt även grupper med speciella behov. Ju fler enkäter man får in desto bättre resultatanalys kan åstadkommas, därför är det rekommenderat att man inkludera med ett incitament, exempelvis att man skickar tillbaks en trisslott till alla som har skickat in sin enkät. Resultaten som fås fram ger möjlighet att analysera vilka användargrupper som finns. Om det skulle visa sig att användargrupperna är för många kan vi behöva gå tillbaka till företaget och införa någon typ av begränsning.

Hitta användare Contextual Design tar inte upp problemet med att hitta användare som kan medverka i designprocessen. Metoden utgår helt enkelt från att användarna finns där och är engagerade i projektet, till exempel när det gäller utveckling av ett nytt system för att utföra en arbetsuppgift. Man kan ju hoppas att de anställda är intresserade av att förbättra sin egen situation. När man utvecklar en produkt för försäljning är det inte så enkelt att hitta potentiella användare som är villiga att hjälpa till med utvecklingen. Man kan inte förvänta sig att de är villiga att medverka utan någon form av ersättning. Detta kan skapa problem, hur mycket ersättning är rimligt och i vilken form? Om för lite ges riskerar man att få omotiverade användare medan för mycket kan leda till användare som är alldeles för intresserade i själva ersättningen istället för produkten som ska utvecklas. Det finns också en viss risk att den typ av användare som går med på att medverka inte korrekt representerar sina grupper. Till exempel så är det tänkbart att en barnfamilj som är villig att medverka i utvecklingen av ett mediecenter är mer teknikintresserade än medelfamiljen. Detta är ett mycket svårt problem att lösa och i de flesta fall får man nöja sig med att ta med så många försökspersoner att risken minimeras. I detta projekt kommer det att användas två grupper av användare; en mindre grupp som är anställda under projekttiden och en större grupp som får ersättning allt eftersom de olika momenten genomförs. Tanken är att den mindre gruppen ska jobba närmare designteamet och sedan ska resultaten genomgå grundligare utvärdering av den större gruppen. I den mindre gruppen, bestående av människor vi anställt, finns det stor risk att de medverkande inte till fullo representerar de grupper de kommer ifrån, eller att det helt enkelt saknas representanter från vissa användargrupper. Exempelvis kan det vara svårt att anställa en barnfamilj. Det är på grund av detta den större användargruppen existerar. Kanske vore det önskvärt att endast använda sig av en stor grupp som får ta del i all utvärdering, men detta är tyvärr inte möjligt inom rimliga tidsramar och är dessutom inte ekonomiskt försvarbart. Involvera användare När användargrupperna väl är identifierade och användarrepresentanter är utvalda så kommer de att spela en betydande roll under ett par faser under utvecklingsprocessen. I processens första fas ska användarna observeras i deras naturliga arbetsmiljö och man ska även ha möjlighet att kunna intervjua dem. Eftersom vi utvecklar Hemmets mediecentral kommer vi att behöva observera användarna när de använder systemet. I det här fallet är det inget system som de använder på sin arbetsplats vilket gör användarinvolveringen lite annorlunda. I grund och botten finns samma krav på hur och när i projektet användarna ska involveras men vi kommer att behöva vara mer flexibla än normalt eftersom största delen av användarinvolveringen kommer att ske hemma hos användarna. Mer tid kommer förmodligen att behöva läggas på Contextual Inquiry än vad som anses normalt i och med att vårt system används på fritiden. I och med att Contextual Design sammanställer olika användares behov på ett bra sätt ibland annat affinity-diagram så finns det ingen anledning att sortera bland användartyper eller användargrupper redan här. En användargrupp i minoritet kan exkluderas, om den visar sig efter framställning av affinity-diagrammet, ha en betydande inverkan på designen.

Under den andra fasen av användarinvolveringen kommer användarna att testa och utvärdera våra olika designlösningar. Genom att utgå från användarnas behov och den floor plan vi har tagit fram (se nedan för en utförligare beskrivning av hur en floor plan är uppbyggd) kan vi konstruera modeller av olika komplexitet med hjälp av papper och enkla hjälpmedel. Fram till denna fas ska helst inget arbete ha gjorts i form av programmering eller fysisk formgivning av delarna i vårt system. Tack vare de relativt enkla pappersmodellerna går det snabbt att ändra i designen och presentera förändringar för användarna. Den här processen är väldigt iterativ och iterationerna går snabbt. När användarna och utvecklarna har kommit överens om en designlösning som fungerar så avslutas användartesterna. Informationsinsamlingen I Contextual Design finns en grundidé för inhämtning av information. Denna informationsinhämtningsmetod är kallad Contextual Inquiry, själva grundidén med denna metod är att gå ut till användarna för att observera dem när de är i systemets tänkta användningsområde. Under denna observation kan man avbryta användaren genom att ställa frågor angående dennes agerande, för att kunna få en djupare förståelse av de befintliga problemen. Efter detta går man vidare till att med användarnas hjälp utvärdera den nyintagna informationen. Ett annat sätt att samla information kallas Master-Apprentice-metoden. Denna metod går ut på att intervjuaren agerar lärling och låter användaren vara läraren. Med andra ord får användaren lära intervjuaren hur hon använder det nuvarande systemet, och intervjuaren kan ställa frågor när någonting är oklart. Detta betyder i praktiken att användarna själva bestämmer hur systemet ska fungera. Det finns både för- och nackdelar med dessa metoder. En fördel med att använda sig av Master-Apprentice-metoden är att både användaren och intervjuaren har lättare att hamna på samma kunskapsnivå. Genom att låta användaren lära intervjuaren ger man användaren en känsla av att det är hon som kan bäst. Detta underlättar när intervjuaren ställer frågor om systemet. Om man låter användaren lära intervjuaren ökar dock risken att användaren undviker vissa situationer där hon anser att något är omständigt i det befintliga systemet. En fördel med att istället intervjua användaren på plats är att man får se hur användarna agerar vid användning av det befintliga systemet, och på så sätt kan se eventuella problem. Nackdelen blir då att intervjuaren måste ha en stor kunskap inom området för att kunna ställa rätt frågor. Contextual Inquiry i sig kan ha en generell nackdel beroende på hur användarna väljs ut. Om samma användare används under hela projektet ökar risken att de blir påverkade av utvecklingsarbetet och inte längre blir objektiva. Å andra sidan kan det vara en fördel att använda sig av samma användare genom hela utvecklingsprocessen eftersom dem då vet precis vad de hade för problem och synpunkter tidigare och kan snabbt peka ut vilka förändringar som har varit bra respektive dåliga.

Artefakter Ett projekt som drivs i enlighet med Contextual Design kommer att generera stora mängder artefakter i form av affinity-diagram, skisser, floor plans, story boards, pappersprototyper etc. Affinity-diagram är det första dokumentet som genereras, där alla observerade användares önskningar och krav finns sammanställda på ett ställe. Ur diagrammet, som oftast blir väldigt stort, går det oftast att se användargemensamma behov och önskningar. Genom att ställa upp allas krav tydligt och sedan slå ihop liknande krav så säkerställs att ingen användares behov går förlorat. Floor plan, eller User Environment Design som den också kallas, kommer att innehålla en detaljerad karta över hur de olika delarna i systemet hänger ihop. För varje del framgår det tydligt vad den hjälper användaren att utföra, samt precis vilka funktioner den innehåller. De olika delarna binds ihop på ett sådant sätt att det enkelt går att se hur delarna hör ihop och hur användarna navigerar sig från del till del. Viktigt att poängtera är att kartan inte ska bindas till något specifikt gränssnitt. Den ska snarare fungera som ett skelett som det sedan ska gå att applicera ett gränssnitt ovanpå. Story boards är en ögonblicksbild över situationer där användarna använder det färdiga systemet och eventuella tillbehör som vi anser att de kommer att behöva. Fler story boards görs för att visualisera de olika scenarion som vi anser vara möjliga. Pappersprototyperna produceras sist av de nämnda artefakterna och baserar sig på alla tidigare dokument och data. Prototyperna används för att visa designlösningar för användarna och för att få en möjlighet att se hur designen fungerar utan att faktiskt bygga den. Pappersprototyperna byggs upp för att visa hur hela systemet kommer att se ut och agera. Dialogrutor, felmeddelanden, bilder och all form av layout åskådliggörs med papper och handritade bilder. Fördelen med den här metoden är att prototyperna är enkla i sin natur och de går enkelt att ändra. Detta ger möjlighet att göra den här fasen iterativ i och med möjligheten att snabbt och billigt göra ändringar i designen. Små ändringar kan till och med göras på plats hos användaren för att utvärdera hur designändringar påverkar användbarheten hos systemet. Snabba iterationerna gör det möjligt att under en relativt kort tidsperiod göra många iterationer och på det sättet eliminera de flesta felen i designen.

Implementation I det sista steget, kallat Transition to Implementation, ska designen omsättas till färdig produkt. Även om designen är fastslagen så går det inte att släppa all kontroll i det här steget. Det bör finnas en kontrollplan för att säkerställa att inga ändringar smyger sig in när den färdiga designen ska omsättas i mjuk- och hårdvara. Iterativ utveckling som kontinuerligt kontrolleras mot användare, så att allting fortfarande går enligt plan, är en god idé. När det gäller vår mediecentral så kommer det vara mjukvaruutvecklingen som tar längst tid. Hårdvaran som kommer att användas är till största del standardiserad och väl beprövad. Att börja med mjukvaran och göra den helt färdig innan den implementeras på hårdvaran är troligtvis det bästa ur både tids- och budgetsynpunkt. Användarna ska kontinuerligt få ta del av arbetet för att säkerställa att det fortfarande går enligt plan. När mjukvaran är färdigutvecklad återstår bara att implementera den på hårdvaran. Denna del kommer vara den kortaste. Utveckling av den hårdvara som inte nödvändigtvis är standardiserad, till exempel fjärrkontroll och display, tillåts ta lite längre tid. När allting fungerar avslutas utvecklingsprojektet med ett slutligt användartest där produkten i sin helhet testat hos användarna.

För- och nackdelar: Contextual Design har precis som alla andra utvecklingsmodeller både för- och nackdelar. Metoden lägger stor vikt på de första stegen som handlar om insamlandet av data samt hur data ska hanteras och sammanfattas till en överskådlig form. Contextual Inquiry genererar ofta enorma mängder svårtolkad data. Till skillnad från andra metoder där data kan tolkas mer eller mindre automatiserat genererar Contextual Inquiry ofta data som måste tolkas för hand. En stor mängd data kan vara både bra och dåligt beroende på vad för typ av system som ska utvecklas. Mycket data är bra om det finns resurser och kunskaper nog att behandla den, men risken är att projektet svämmas över av så mycket data att det blir ohanterligt. Ett sätt att komma undan detta är att begränsa mängden användare i första fasen av projektet vilket naturligtvis även innebär risker. Beroende på hur många användare man väljer att studera i den här inledande fasen kan det behövas en stor mängd intervjuare eftersom alla intervjuer och observationer sker one-onone, dvs. en intervjuare behandlar endast en användare samtidigt. Vid användandet av Contextual Inquiry är det mycket viktigt att insamlingen av data sker på ett korrekt sätt som speglar användarnas sätt att arbeta på. Om felaktigheter uppstår i det data som är insamlat blir resten av stegen i modellen också felaktiga. Förvisso gäller detta nästan oavsett vilken modell man väljer att arbeta utifrån, men det är extra viktigt i Contextual Design på grund av den enorma datamängd som potentiellt samlas in. Att behöva göra om datainsamlingen kan bli en väldigt kostsam process både ur pengasynpunkt men även ur en tidsaspekt. De olika flödesdiagrammen som skapas under projektets gång för att underlätta bland annat arbetsfördelning mellan olika delgrupper inom projektgruppen fungerar bra så länge ingenting oförväntat inträffar. Contextual Design fungerar dåligt om förändringar i grunddata sker under projektets gång. Ju längre in i projektet desto mer måste göras om när grunddata ändras. Affinity-diagrammet och därmed även floor planen måste ändras om det upptäcks att användarnas behov inte har uppfattats korrekt. I Contextual Design blir användarna konfronterade med pappersprototyper som är tänkta att fungera istället för det nya systemet. Även om denna metod ofta fungerar och har många fördelar såsom minskade kostnader och tidsbesparing eftersom inga äkta prototyper behöver göras, så finns det många nackdelar. När vi ska utveckla en mediecentral är det svårt att presentera allting med pappersmodeller. Många detaljer är av teknisk natur som är svåra att beskriva med pappersmodeller. I de fallen skulle det vara bättre att lägga ner lite tid på att bygga eller programmera vissa delar av systemet och sedan kombinera det med pappersmodeller och kanske även andra former av presentationsmöjligheter. I utvecklandet av mediecentralen är det lämpligt att bygga upp verklighetsliknande imitationer av systemet för att ge användarna en idé om hur det kommer att se ut rent formmässigt. Med rätt verktyg kan detta göras utan omfattande extrakostnader.

Tidsplan

Förklaring av tidsplan Användaridentifiering 4 veckor o Att identifiera användargrupperna genom enkäter beräknas ta ungefär 4 veckor på grund av lång svarstid. Informationsinsamling 2 veckor o När användargrupperna är identifierade ska användarna observeras i deras normala arbetsmiljö. Varje intervju bör vara ungefär 2-3 timmar lång. Det beräknas ta ungefär 2 veckor. Informationsbearbetning 3 veckor o Consolidation Affinity-diagram skapas o Work redesign Med utgångspunkt från affinity-diagrammet genereras story boards o User Environment Design En detaljerad floor plan skapas. Prototypgenerering 4 veckor o Användartesterna måste få ta mycket tid. Under dessa veckor kommer vi successivt att iterera fram en designlösning som vi och användarna är nöjda med. Vi planerar att ha mycket korta iterationer för att hinna med så många som möjligt. Iterationstid är planerad till 1 dag. Implementering 5 veckor o Omvandling från design till produkt. Mjukvaran produceras först, sedan hårdvaran. Även här itererar vi men med en planerad iterationslängd på ungefär 4 dagar.

Källförteckning Böcker: Användarcentrerad systemdesign av Jan Gulliksen och Bengt Göransson. Publicerad av Studentlitteratur 2002 ISBN: 91-44-02029-5 Contextual design Defining Customer-Centered Systems av Hugh Beyer & Karen Holtzblatt. Publicerad av Academic Press 1998. ISBN: 1-55860-411-1 Human Computer Interaction av Alan Dix, Janet Finlay, Gregory D. Abowd och Russell Beale. Publicerad av Prentice Hall 2004. ISBN: 0130461091 Uppsatser: Contextual Design Ett tidens tecken? av Katrina Anderson. Från http://webzone.k3.mah.se/kit01005/contextualdesign.pdf Internet: Contextual Design Process, 2006-12-09, http://incontextdesign.com/cd/cdprocess.html Contextual inquiry, 2006-12-09, http://en.wikipedia.org/wiki/contextual_inquiry Notes on Contextual Design, 2006-12-09, http://regexp.bjoern.org/archives/000138.html Paper prototyping, 2006-12-09, http://en.wikipedia.org/wiki/paper_prototyping