Projektuppgift i Användarcentrerad Systemdesign Utveckling av e-dagis baserad på Contextual Design av H. Beyer och K. Holtzblatt Kaveh Mehrabi Gustav Mena Marcus Rosengren Ellen Tjälldin
Användarcentrerad process Contextual Design Introduktion Kontextuell design handlar om att utveckla kundcentrerade system. Boken är en guide för systemutvecklare för att skapa system som passar in i kundens sammanhang. Denna metod är ett sätt att möta de ökade kraven från marknaden där nya produkter inte accepteras om de inte passar in i kundens andra system och arbetssätt. Metoden tillhandahåller olika tekniker att lära sig om kunden genom insamling av data och hur man bildar en helhetsbild av kund och det system som ska utvecklas. Förutom att förstå kunden bygger metoden på ett designtänkande och en hantering av team och organisationssammanhang. Detta ger även systemutvecklarna en enad helhetsbild och ett sammanhang under arbetets gång, vilket gör det lättare att fokusera på målen och syftena med systemet. Kontextuell design lämpar sig egentligen bäst för design av stora komplexa system, därför att det handlar om metoder att organisera arbetet så att man bevarar sammanhanget och helhetsbilden trots att arbetet är uppdelat på en stor grupp. Metoden fungerar också bra för mindre system och mindre arbetsgrupper. Det huvudsakliga målet är att få ett system som underlättar och stödjer arbetet för kunden och inte utgör ett hinder. Steg i processen Metoden definierar följande steg i utvecklingsprocessen: - Kontextuell undersökning och tolkning Det första steget handlar om att förstå och bilda sig en uppfattning om kundens behov och arbetssätt. Datainsamlingen görs ofta genom intervjuer med kund, för att sedan tillsammans med teamet tolka informationen. Om medlemmarna i teamet har olika erfarenheter blir tolkningen mer översiktlig, vilket minskar risken att missa viktiga detaljer. - Arbetsmodeller I detta steg skapas en representation av arbetssättet. Det finns fem olika arbetsmodeller; flödes-, sekvens-, artefakt-, fysisk och kulturmodell. I var och en av dessa modeller representeras den insamlade data i olika sammanhang och med olika fokus. Varje modell är en komplett beskrivning av kundens arbetssätt, men ur olika perspektiv. - Sammanslagning För att skapa en sammansatt bild av hela den population som systemet involverar, och inte enskilda individer, används så kallade samhörighetsdiagram. Detta organiserar de anteckningar och noteringar som man har samlat på sig under tolkningssessionen. Genom att betrakta samhörighetsdiagrammet kan en designer lät få en bra överblick över arbetet som ska utföras. Utöver samhörighetsdiagram, används sammansatta arbetsmodeller som visar arbetsstrukturen, det vill säga sammansatt flödes-, sekvens-, artefakt-, fysisk och kulturmodell.
- Omdesign av arbete Skapa gemensamma visioner i teamet, vilka sedan utgör grunden för att ta fram storyboards. Dessa beskriver hur en arbetsuppgift ska utföras i det nya systemet, följer den sammansatta sekvensmodellen. - Design av användarmiljö Skall vara ett hjälpmedel vid design för att bevara sammanhanget. Den ligger mellan storyboards och gränssnittsdesignen. - Testning Innan kodning kommer igång testas enkla pappersprototyper och gränssnittsidéer tillsammans med kund, på kontinuerligt iterativt arbetssätt.
E-dagis Uppgift Uppgiften går ut på att beskriva och planera processen för hur en IT-baserad systemutveckling ska utföras utifrån en användarcentrerad synsätt. Eftersom uppgiften är att enbart beskriva upplägget och genomförandet för utvecklingen av IT-systemet, inkluderas inte utförandet. Design, programmering eller intervjuer av användare är inte en del av detta projekt. Denna rapport beskriver, med andra ord, en planering över hur vi skulle genomföra projektet. Tillvägagångssättet baseras på den processmodell som beskrivs i boken Contextual Design av Hugh Beyer och Karen Holtzblatt. Vi beskriver de användarcentrerade metoderna och processerna som vi har använd oss av för att konstruera ett IT-system. Fokus ligger främst på olika användare och deras arbetsmiljö. IT-systemet som vi har fått i uppdrag att planera en utveckling för är ett e-dagis. Detta är en betaltjänst till föräldrar som har sina barn på dagiset i Krylboda. Tanken bakom detta är att föräldrar ska kunna följa sina barns utveckling, även barnen många gånger tillbringar de flesta timmarna av dagen på dagis. Idag sker detta genom att dagispersonalen, om de har möjlighet och ork, berättar för föräldrarna om barnens aktiviteter. Man har därför tänkt lösa problemet genom ett e-dagissystem, där dagispersonalen dokumenterar barnens lekar och aktiviteter under dagen och att föräldrarna får tillgång till valda delar av denna dokumentation. Förhoppningsvis blir dokumentationen i form av bilder, videoklipp, text och ljud. Krylboda kommun har ställt dagispersonal till förfogande. En genomförd marknadsundersökning har visat att intresset för systemet är stort hos föräldrarna. Kontextuell undersökning, förstå kunden Författarna Holtzblatt och Beyer fokuserar designprocessen på att systemutvecklarna skall förstå organisationen som de ska utveckla ett nytt system för. För att utvecklarna skall få en bild av organisationen, genomförs en kontextuell undersökning. Först åker en grupp av designteamet ut på en fältintervju hos kunden. En person från teamet kommer att intervjua medan de andra antecknar, observerar och deltar aktivt. Om teamet hade haft fler än fyra medlemmar hade en uppdelning av teamet varit nödvändig. I detta fall är det dock inte aktuellt. Med projektet e-dagis kommer intervjuer äga rum med dagispersonal, föräldrar samt ansvariga på kommunen. Dagispersonalen intervjuas på dagiset och föräldrarna i den miljö där de skulle använda tjänsten, förmodligen hemma eller på jobbet. Målet med den kontextuella undersökningen är att få en detaljerad bild av organisationen, få kunskap om arbetsmomenten som har blivit osynliga och rutinmässiga, införskaffa data om hur arbetsmomenten går till och explicit bestämma outtalade arbetsmoment. Inblandning av användare i den kontextuella undersökningen sker i huvudsak med intervjuer. Dagispersonal är de som ska förse systemet med data om barnen, som en slags administratörer. Föräldrarna kommer att använda systemet för att få del av information om barnens aktiviteter på dagiset. Därför är dessa två användare speciellt intressanta, och bör anses som primära. Personal från kommunen är i detta fall den betalande kunden, men med en systemutvecklingsprocess som utgår från kontextuell design ligger fokus på hur systemet skulle passa in i vardaglig användning, och därför är information från dagispersonal och föräldrar mer intressant.
Tolkningssessioner & gruppering av data Efter den kontextuella undersökningen kommer utvecklarna att ha möten där de diskuterar insamlad data. Dessa möten kallas tolkningssessioner. Utifrån designgruppens olika perspektiv kommer de fram till en gemensam syn på vad som är viktigt att fokusera på i det fortsatta arbetet. Det är viktigt att få med alla aspekter av kundens arbetssätt. Teamet behöver sedan sätta in och gruppera den information de fått fram i de olika arbetsmodellerna som följer: Flödesmodellen denna förtydligar förloppet av arbetssättet på dagiset. Arbetet är uppdelat i olika ansvarsområden och roller. Modellen visar vilka roller dagispersonalen och föräldrarna har, vad de gör och hur de kommunicerar med varandra. Den visar dessutom hur kommunikationen mellan dagispersonal och föräldrarna brister. Sekvensmodellen identifierar strategier och tillvägagångssätt som dagispersonalen använder för att lösa olika arbetsuppgifter. En sammanslagning av flera individuella sekvensmodeller ger en detaljerad och allmän bild av hur arbetet genomförs. Olika dagispersonal har olika sätt att genomföra en viss uppgift och det gäller att få en generell och omfattande översikt över vilka arbetsstrategier de använder. Sekvensmodellen är senare en bra vägledning för att strukturera e-dagiset så att den passar hela användargruppen och deras olika sätt att angripa arbetsuppgiften. Artefaktmodellen visar det allmänna temat och konceptet som en enskild dagispersonal använder för att få ett visst mönster i arbetet. För att visa en övergripandebild av hur hela dagispersonalen och alla föräldrarna organiserar och strukturerar sina arbeten slår man samman alla artefakter. Detta görs genom att man grupperar artefakter som är likartade och har samma avsikt i arbetet. På så sätt kan man, vid senare skede i utvecklingsprocessen, vägleda teamet till att strukturera e-dagiset så att den kan stödja hela dagispersonalen och alla föräldrarnas olika sätt att lösa arbetsuppgiften. Fysiska modellen visar strukturen av den fysiska omgivningen och miljöns inverkan i dagispersonalens arbetar. Den fysiska individuella modellen visar hur platsen är strukturerad, hur den är organiserad och hur dagispersonalen själva och deras redskap förflyttar sig under arbetets gång. Den samanslagna fysiska modellen visar den gemensamma fysiska strukturen för hela kundpopulationens arbetsmiljö. Den åskådliggör dessutom de variationer i arbetsmiljön som e-dagiset måste kunna handskas med för att den ska bli så användbart som möjligt och inte ett hinder i personalens arbete. Kulturmodellen bidrar inte med någon strukturell information till designen av e-dagiset, men betonar värderingar, standarder, begränsningar och makt- och känslorelationer mellan individer och grupper. Det vill säga den tar upp alla aspekterna och inflytanden av kulturen inom kundpopulationen och hur den berör deras tillvägagångssätt. Den framhäver även de faktorer som dagispersonalen bryr sig om när de arbetar. Den belyser vad dagispersonalens prioriteringar, vad de bryr sig om, hur de tänker om sig själva och det jobb de gör, vilka begränsningar de har och vilken policy de följer. Den här modellen styr riktningen som konstruktionen av e-dagiset bör följa, till exempel om en användare gillar att driva omkring och arbeta är det viktigt att utvecklarna inte binder honom eller henne vid skrivbordet, utan då kan det vara smart och göra systemet portabelt istället, vilket kan vara en lämplig lösning i vårat fall, eftersom dagisbarnen är livliga och springer runt väldigt mycket.
När de olika arbetsmodellerna som beskriver dagisverksamheten tagits fram, ska teamet skapa sig en enad bild om vad all data betyder, och komma in i ett systemtänkande. Detta sker mycket genom diskussioner i teamet. I ett samhörighetsdiagram (affinity diagram) samlas all data, och det är först nu som designgruppen, tillsammans eller var för sig, kan börja fundera på hur en lösning till e-dagis skulle kunna se ut. Samhörighetsdiagrammet består av många postit-lappar strukturerade på en vägg. Alla ska lätt kunna ta del av det. Vid detta skede upptäcks dels designidéer och dels brister i data. Allt skrivs ned för att inte förloras. Brister i data kan lösas vid senare intervjuer. Vad idéerna bör inrikta sig på är att inte lösa ett enstaka problem utan det som hela väggen beskriver. Detta betyder att teamet helst behöver ett eget design-rum till förfogande. Omdesign av arbetsmodell Vi det här laget har förmodligen teamet en god bild av dagispersonalens och föräldrarnas behov, och nu gäller det som ett första steg i omdesign, att omdesigna arbetsmodellen. Ett införande av en ny systemlösning, e-dagis, gör att arbetssättet på dagiset ändras. Att omdesigna arbetssättet är ett explicit designsteg som sätter ramar bland annat för mjukvara och hårdvara av e-dagislösningen. Det är viktigt att designidéer för hur e-dagis skulle kunna fungera bygger på all den data teamet fått fram. För att se arbetsstrukturen studeras dels de sammanslagna modellerna och dels metaforer. Med metaforer menas att designgruppen utforskar liknande arbetsområden, lämpligen andra dagis, för att se problem och möjligheter på just dagiset i Krylboda. Användningen av de olika sammansatta modellerna driver fram olika frågor för designgruppen att beakta: Flödesmodellen Visar kommunikationsmönstret mellan dagispersonal och föräldrar samt vilka roller som dessa har. En roll kan exempelvis vara den som lägger upp bilder på e- dagiset. Vad som bör ses över är hur denna roll kan vara uppdelad bland personalen på dagis och om systemet fungerar för alla personer som delar denna roll. Eftersom de flesta sitter på olika ansvarsområden och därmed olika roller gäller det att e-dagissystemet stödjer de rollbyten som krävs. Föreståndaren på dagiset har kanske rollen som ansvarig för systemet, och denna roll bör stödjas och möjligen automatiseras för att inte utgöra att hinder i arbetet. Eventuellt kan e-dagis medföra ändringar i den befintliga rollstrukturen eller arbetsprocessen, vilket är viktigt att beakta. Det kan till exempel vara att den roll på dagiset som har hand om kommunikationen och informationsspridning till föräldrar idag, minskas och även stöds av e- dagissystemet. Denna modell visar e-dagisets ändamål i den vardagliga dagisverksamheten, och hur e-dagistjänsten kan designas för att stödja verksamheten. Kulturmodellen I denna modell som beskriver vad föräldrarna och dagispersonalen tycker är viktigt och vad de bryr sig om, bör man försöka få e-dagissystemet att få bort friktionen mellan personer. Kulturmodellen bidrar inte med någon strukturell information till designen, men tar fram värderingar, standarder, begränsningar och makt- och känslorelationer mellan individer och grupper. Fysiska modellen Här gäller det att förstå hur dagisets fysiska miljö sätter gränser, och avgör vad man kan och vad man inte kan ändra på. Exempelvis kan det handla om att se över
om e-dagislösningen även behöver finnas tillgängligt på papper, för arkivering eller till föräldrar som inte har tillgång till dator med Internetuppkoppling. För att e-dagiset ska designas så att den passar kundens fysiska struktur och organisation är det viktigt att utvecklarna utnyttja de möjligheter som finns i omgivningen och försöker komma underfund med vad som kan ändras och vad som inte kan ändras i dagismiljön. Sekvensmodellen Denna modell, vilken beskriver arbetsuppgifter i aktiviteter, syfte, strategi och olika steg, är den bästa vägledningen till att strukturera e-dagissystemet för att passa de som skall angripa en arbetsuppgift. En sammanslagning av flera individuella sekvensmodeller ger en detaljerad och allmän bild av hur arbetet och dess syften kan stödjas av e-dagiset. En arbetsuppgift i e-dagislösningen kan vara att ta bort gammal information. Vid design handlar det för det första att se om sekvensen tjänar sitt syfte, och sedan bör designgrupper se om man kan underlätta eller till och med eliminera steg i sekvensen. Artefaktmodellen Denna modell vägleder också systemstrukturen. Vad som är viktigt här är att se till att e-dagissystemet stödjer syftet med användningen, men även den informella användningen. Att ta hänsyn till informell användning av artefakt gör att syftet med användningen uppfylls mer direkt. Dessa modeller diskuteras av teamet och ger olika aspekter av arbetet på dagiset i Krylboda. Återigen, insamlad kunddata anger vad som är viktigt, men inte vad som ska designas. I en kontextuell designprocess ska teamet ledas till kreativ design där många olika idéer får prövas. Design från data Designprocessen börjar med att teamet går igenom modellerna och samhörighetsdiagrammet på väggen i sitt design-rum, för att få en flerdimensionell bild över hur allt hänger ihop. Teamet diskuterar och fokuserar på mål och visioner. Det genomförs två olika brainstorm; en som rör teknologi och dess olika möjligheter för e-dagiset, och en som tar upp olika utgångspunkter. En utgångspunkt beskriver designlösningen ungefär som en slogan, till exempel E-dagiset ska fungera som multimedia-dagbok. Här utvärderas inte idéerna utan allting antecknas. Sedan ska teamet skapa visioner utifrån de två brainstorm, genom att rita bilder i team. Man börjar med en av utgångspunkterna och fortsätter bygga på idén. Krockar idéer sätter man upp nya utgångspunkter. Till slut har man flera olika visioner, och det gäller nu att skapa en gemensam vision utan att kompromissa. Teamet listar för- och nackdelar med varje, och tillsammans kommer man fram till en gemensam vision. Visionen blir en karta för koordinering av arbete i team för att utveckla e-dagiset, och gör att de arbetar mot ett genensamt mål. Visionen definierar också vad som förväntas av mjuk- eller hårdvara. Vad som sedan designprocessen handlar om är att beskriva hur en arbetsuppgift ska utföras i det nya e-dagissystemet. Teamet ängar sig åt att ta fram så kallade storyboards. Dessa följer mestadels sekvensmodellen och baseras på visionen. De visar även en uppgift i ett sammanhang. Man använder sig av rutor (t.ex. postit-lappar eller pappersark) som var och en beskriver en scen; interaktion mellan människa människa, människa system, människa artefakt eller systemsteg. En storyboard täcker således mer än bara interaktionen med e- dagissystemet.
Målet med en storyboard är att beskriva hela arbetsuppgiften, där varje ruta inte kan innehålla så många detaljer, men ger en bild av hur användaren kan dra fördel av e-dagiset. Eftersom framtagandet av storyboards sker parvis i teamet utvärderar och omarbetar hela teamet tillsammans de olika storyboards, så att fler idéer kommer fram och se om de verkligen baseras på visionen. Eftersom utvecklingen av ett e-dagis inte bör vara alltför komplext och stort, behövs problemen inte delas upp ytterligare i mindre problem med risk att förlora sammanhanget. Men det gäller för teamet att hålla systemmodellen i ett sammanhang, annars kan dagispersonalens arbete inte hållas i ett sammanhang. Designprocessen bör alternera mellan sekvensfall och strukturmodeller. Systemdesign Kundorienterad design handlar om att ta fram en systemstruktur som skall stödja arbetet, som dagispersonalen upplever som naturligt. En systemstruktur består av platser, funktioner på dessa och länkar till andra platser. Görs en ändring i designen måste hela designen ses över så att sammanhanget behålls. En bra struktur kan stödja flera olika användare. Att designa en struktur är emellertid inte att ta fram ett gränssnitt. User Environment Design (UED) ligger mellan storyboards och gränssnittsdesign, och är det steg teamet nu går igenom. UED belyser de huvudsakliga koncepten för att designa en systemmodell. Även här använder man rutor som hjälpmedel. Varje ruta representerar ett användningsområde i e-dagissystemet och innehåller listor på funktioner, länkar och berörda objekt. Detta skulle kunna liknas vid ett UML-diagram (Unified Modeling Language). Sammanhangen som UED visar upplevs även av de tekniker som sedan utvecklar mjukvaran för e-dagiset, vilket leder till att även e-dagiset sätts i ett sammanhang. Hantera bilder Funktioner: - Lägga till - Ta bort Länkar: > Hantera information Funktioner: - Se vilka som har tillgång till e- dagis Länkar: > Hantera bilder Skriva meddelanden Funktioner: - Editera innehåll Länkar: UED låter utvecklarna bygga en enda sammanhängande struktur som stödjer flera olika uppgifter utförda av flera roller. UED-strukturen är byggd med hjälp av de olika storybords som finns. Utvecklarna tar ett storyboard i taget och inför detta i UED strukturen. Anledningen till att bygga en UED är att UED stödjer strukturellt tänkande, det vill säga att utvecklarna får en helhetsbild av hur systemet är tänkt att fungera. Medan storyboards stödjer en uppgift som utvecklarna har tänkt sig systemet skall utföra. Genom att både titta på storyboards och UED-strukturen kan designerna identifiera och gruppera uppgifter som har likheter mellan varandra. Med hjälp av grupperingen kan utvecklarna se att storyboards fyller en funktion inom ramen för projektet och inte svävar ut samt att det underlättar för design av användargränssnittet.
Testning Teamet har kunskap om kundens behov, och en vision för design. Det är nu dags att testa hur väl denna vision stämmer överens med kundens behov, och om så krävs förfina designen. För att kunna testa visionen behöver teamet någon sorts prototyp att förevisa, så kunden kan anmärka på vad som är bra, och vad som är mindre bra. Demonstrationer av en design är problematiska av flera skäl. Designen kan framstå som slutgiltig och därför inte uppmuntra vidare utveckling, den kan även vara för komplex så att själva inlärningen av gränssnittet blir ett problem i sig. Testningen sker på samma form som användarintervjuerna i den första fasen. För att få substantiell feedback från användaren gäller det att de upplever sig delaktiga i designarbetet, de måste våga ifrågasätta och förändra existerande design. Vid testning behöver därför teamet även intervjua användare som inte intervjuats vid tidigare tillfällen. De kan komma med nya uppslag som övriga användare ignorerat då de kanske redan är låsta vid en viss lösning. För att komma runt ovan nämnda problem med demonstrationer genomförs testningen med hjälp av pappersprototyper. Tillsammans går användare och designer igenom arbetsprocessen i pappersprototypen för att se om visionen är hållbar. Den största styrkan är att en prototyp i papper förmedlar att systemet fortfarande är i utvecklingsstadiet, så att ändringar är välkomna och snabbt går att utföra, ingen kodning behövs. Vid arbetet med pappersprototypen framgår också vissa dolda arbetsmoment som är viktiga att tänka på. Har de inte varit med tidigare är det lätt gjort att lägga till dem i pappersprototypen. När en prototypintervju är slutförd har man nya resultat som behöver tolkas, för att sedan införlivas i en ny prototyp. Denna iteration upprepas tills designer och användare nått fram till en nöjdaktig lösning. I de första prototypintervjuerna fokuserar man på att undersöka strukturen. Efter att man itererat ett par gånger och uppnått en tillfredsställande struktur koncentrerar man sig på detaljerna.
Utvärdering Enligt uppgiften har kommunen, som är beställare, bara en idé om vad de vill göra. När beställaren har en vag uppfattning om vad systemet skall göra passar kontextuell design bra. Utvecklarna går ut i verkligheten och pratar med tilltänkta användare och skaffar sig en uppfattning om hur användarna vill ha systemet. Utifrån användarnas önskemål kan nu ett system börja växa fram. En annan fördel med kontextuell design är att utvecklarna hela tiden får en bild av systemet, även om en utvecklare bara jobbar med en liten del av systemet. Att utvecklarna får en helhetsbild beror på samhörighetsdiagrammen. De nackdelar som har framkommit är att Holtzblatt och Bayer fokuserar mycket på kunden. Det är inte alltid kund och användare är samma sak och det kan vara svårt att se skillnad vem kunden är. Företaget som utvecklar har en kund som beställer systemet och beställarna har också kunder. Hur systemet kommer att se ut bygger till stor del på intervjuer med användare samt utvärdering av pappersprototyper. Vi anser att det skulle vara bra att även använda sig av andra utvärderingsmetoder, till exempel låta användarna utvärdera en mer färdig prototyp i datorn. I boken framhåller författarna att det är viktigt med användarvänlighet och att systemet skall möta användarnas behov. Som vi har diskuterat i kursen är dessa termer inte entydiga och ofta upp till utvecklare att tolka. För att komma tillrätta med detta problem måste utvecklarna vara medvetna om farorna med dessa vaga termer eller så måste användarvänligheten förklaras mer explicit i systemutvecklingsmetoden.
Tidsplan Översikt tidsplan - Intervjuer tar 2-3 timmar, vi intervjuar 6 st förskolelärare, 2 st kommuntjänstemän, 8 st föräldrar i första fasen - Hela gruppen (4 pers) deltar i varje intervju, snabbar upp tolkningssessionen - Tolkningssession inom 48 tim - Vid testning görs intevjuer med samtliga tidigare nämnda användare samt ytterligare 4 st förskolelärare Datum Tid Aktivitet Dag 1 8h 3 st intervjuer av förskolelärare Dag 2 8h 3 st intervjuer på förskolelärare Dag 3 8h Tolkningssessioner dagisintervjuer Dag 4 4h 2 st intervjuer av kommunmuppar Dag 4 4h Tolkningssession av kommunintervjuer Dag 5 8h Bearbetar data från intervjuer mha arbetsmodeller Dag 6 8h Bearbetar data från intervjuer mha arbetsmodeller Dag 7 8h Omdesign av arbetsmodell Dag 8 8h Omdesign av arbetsmodell Dag 9 8h Brainstorm, vision, storyboard Dag 10 8h Brainstorm, vision, storyboard Dag 11 8h Brainstorm, vision, storyboard Dag 12 8h Systemdesign (UED) Dag 13 8h Systemdesign (UED) Dag 14 8h Framtagning av pappersprototyp Dag 15 8h Genomför test av design mha pappersprototyp Dag 16 8h Tolka data från test, designa om Dag 18 8h Genomför test av design mha pappersprototyp Dag 19 8h Genomför test av design mha pappersprototyp Dag 20 8h Tolka data från test, designa om Dag 21 8h Genomför test av design mha pappersprototyp Dag 22 8h Genomför test av design mha pappersprototyp Dag 23 8h Tolka data från test, designa om