Användarcentrerad systemdesign

Transkript

1 Användarcentrerad systemdesign Rapport Senior palm; Contextual design.

2 Innehåll: 1 Kontextuell design, översikt Informationsinsamling Användargrupper Arbetsmodeller Flöde Sekvens Artefakt Kulturell Fysisk Tolkning Konsolidering Tillhörighetsdiagram Genomgångar Designrummet Prototyper Design Prototyp Evaluering Intervju Problem Tidsplan Uppskattning...10

3 1 Kontextuell design, översikt Inom Contextual design arbetar man med en stor grupp utvecklare. Gruppen skall vara av tvärvetenskaplig sammansättning, designers, programmerare, beteendevetare osv. Hela gruppen är delaktig i samtliga delmoment av designprocessen. Vissa moment kan vara enklare att göra i mindre grupper men det finns då stöd i processen för att dela resultaten från de små grupperna med de andra så att alla får tillgång till all information. Vi ger nedan, inledningsvis i varje stycke, en kort beskrivning av det steget inom ramen för Contextual design. 2 Informationsinsamling Eftersom vi anser att detta är det huvudsakliga problemområdet inom ramen för vår uppgift och Contextual design så kommer vi också att lägga mesta delen av vår tid på det. Vanligtvis i en utvecklingsprocess så har man, förhoppningsvis, relativt responsiva individer som användare och det har vi också, delvis. Sköteskorna kommer förmodligen inte att kräva särskild behandling under informationsinsamlingen eftersom de är en relativt typisk användare i en relativt typisk arbetssituation. Vårdtagarna däremot ställer till det lite. Vi kan inte räkna med att köra ett vanlig master/apprentice upplägg här (vilket däremot skulle fungera utmärkt med sköteskorna). Problemet blir att det inte handlar om människor i en arbetssituation, vi agerar i deras hem. Äldre människor kanske inte alla gånger har förståelse för att man vill, mer eller mindre, bo hemma hos dem i några dagar. Integritet är också något att tänka på. Ett angreppssätt som skulle kunna fungera är att ha någon form av videodagbok för dem. Helt enkelt sätta upp ett antal kameror hemma hos utvalda vårdtagare och filma deras vardag. Problem med denna metod är givetvis integritet och juridik. Det är knappast tillåtet att göra detta utan uttryckligt tillstånd från den man skall filma och det kanske råkar vara så att just den grupp som generellt säger nej till att ha kameror hemma också är den användargrupp som skiljer sig från de andra. Sammanfattningsvis så kan det vara lämpligt att titta på flera modeller för informationsinsamling när det gäller vårdtagarna och inte helt lita på att existerande modeller kommer att lösa dina problem. 2.1 Användargrupper Visserligen är användargrupperna på det hela taget strikt givna i uppgiften. Det man bör tänka på är dock att undergruppen vårdtagare i detta fallet kommer att skilja sig ganska mycket åt. Å ena sidan finns det äldre som knappt har slutat betrakta färgteve med fjärrkontroll som magi. Å andra så finns det äldre som glatt har satellitmottagare, surfar och mailar barnbarnen.

4 Dessutom har vi bitvis stora begränsningar i rörlighet och perception. På det hela taget en stor rad av mer eller mindre hindrande fysiska handikapp. Användar undergruppen äldre/vårdtagare är mycket komplex och en stor undersökning av hur olika handikapp är spridda, och vad det påverkar vad gäller lämplighet i vissa lösningar, är på sin plats. 2.2 Arbetsmodeller Vi beskriver här de fem föreslagna modellerna och deras styrkor och svagheter relaterat till vår uppgift. Generellt kan man se att styrkorna mest kommer till sin rätt i de fall där kontexten är mest lik den i en vanlig utvecklingssituation. Eftersom boken är skriven med djupa rötter i industrin och det sätt som man brukar utveckla system på till företag eller inom företag, så har den vissa brister när den appliceras på denna uppgiften. Det största problemet är att alla undersökningssätten bygger på personlig kontakt. Detta kan kanske verka underligt men det är värt att komma ihåg att hälften (minst) av användarna som vi utvecklar för inte kommer att gå att nå i en arbetssituation, de arbetar hemma (i bokens mening). Hur pigg hade man själv varit på att någon tjomme följde efter en i en vecka för att man kanske skulle kunna få en bättre video? Flöde Flödessteget går ut på att identifiera informationsflödet i en organisation. Hur delegeras arbetsuppgifter till sköteskorna? Scheman, inhandlingslistor, anteckningar och journaler är andra exempel på saker som kommer att ingå i kartläggningen. Till största delen är detta steg enkelt att utföra. Det handlar om att göra ett flödesdiagram över den befintliga organisationen. Det som eventuellt kan ställa till det i detta steget är att identifiera vilken information som vårdtagarna bidrar med. En del av den framgår säkert i det befintliga systemet men det är inte säkert. Merparten av kraften i detta steget bör därför läggas på interaktionen mellan sköteskor och vårdtagare och den uttalade eller outtalade information som utbyts där.

5 2.2.2 Sekvens Detta är en steg för steg uppdelning av varje arbetsuppgift där man försöker identifiera handlingens utlösande faktor och vilket mål handlingen har. Alla mellanliggande steg tas upp och används sedan för att se om det går att omstrukturera handlingsmönster genom att ta bort eller underlätta steg i processen. För personalen så kommer även detta att presentera sig som en ganska typisk implementation av modellen. Som ovan så kommer det att vara kontaktytan mellan vårdtagaren och personalen som blir fokus tillsammans med hur vårdtagarens vardag ser ut. Vårdtagarna lever inte sina liv i en organisation och sättet de väljer att lösa problem på kommer att skilja sig mycket. Likaså de problem som uppstår under en dag för två olika vårdtagare. Mycket tid bör läggas på att undersöka vårdtagarnas vardag, vilka sysslor som ingår, vilka problem som uppstår och vilka arbetssätt som används för att komma runt dessa problem Artefakt I detta steg skall alla fysiska föremål som används i informationsutbytet identifieras och förklaras. En personlig kalender används ju uppenbarligen till att hålla reda på sitt personliga schema men kan också innehålla annan information. Hur informationen lagras i fysiska föremål kommer att ligga till grund för besluten om vilka metaforer som är lämpliga att använda i designen. Uppenbara artefakter för sköteskorna är saker som journaler och mobiltelefoner. Kanske lappar som man skriver till varandra och lämnar på bestämda platser för att förmedla information om sitt senaste besök och vad man gjorde. Det finns säkert andra, mindre uppenbara artefakter här också, det är dem som detta steget ämnar uppenbara. I Vårdtagarens fall så kan artefakter vara i form av handlarlistor eller andra föremål som används för att förmedla information till sköteskorna eller till sig själv inom ramen för projektet Kulturell Detta steget försöker fånga in hela arbetsplatsens atmosfär. Vilka policys gäller? Finns det uttalade och/eller outtalade sätt att lösa uppgifter på? Vilken stil är det på arbetsplatsen (trendig, stilren, enkel, strikt...)? Vilka är det som sitter på det formella respektive informella ansvaret? Hur mycket av det man gör är enligt fastställda dokument och hur mycket går på ren rutin? Alla dessa faktorer, och mer, skall vägas samman till en uttrycklig bild av hur arbetet på arbetsplatsen drivs och av vad. Detta material kommer att se till så att man utvecklar en lösning som stödjer den kultur som finns, även om den inte finns nedskriven, och att stilen på lösningen passar in i det övriga sammanhanget. Huvudsakligen handlar det om att det viktigaste, efter att systemet fungerar som det är tänkt, är att det faktiskt kommer att används.

6 I sköteskornas fall så kommer denna del av arbetet att vara relativt omfattande och innebära mycket arbete med att gå igenom den, ofta till stora delar, informella maktstruktur som finns på arbetsplatsen. Man kommer att behöva titta på hur arbetsredskapen ser ut idag och om detta är hur de anställda skulle vilja att de såg ut. I vårdtagarnas fall är det en något lättare uppgift eftersom det bara är en interaktion det gäller, gentemot sköteskorna. Dock kan det visa sig svårare än man tror att få en rättvisande bild av vem som har vilket ansvar/rättigheter i interaktionen. Frågan om vilken information om vårdtagaren som skall finnas tillgänglig för vem kommer också att hamna här Fysisk Denna punkt tar upp aspekter som hur kontoret är planerat rent fysiskt och hur det fysiska arbetet ser ut. Vilka begränsningar som finns hos användaren. Dels genom hur de genomför arbetsuppgifterna men också vilka fysiska handikapp som finns. Tid räknas också in som en fysisk aspekt i detta steget. Viktiga delar av uppgiften skulle i detta skede vara sköteskornas bas betraktat som kontor. Sköteskornas arbetsuppgifter ute hos vårdtagarna. Hur lång tid de har på sig. Hur hemmen, vårdtagarnas, är planerade. Viktiga aspekter för vårdtagarna skulle vara tid, huvudsakligen. De minuter som sköteskorna kanske är hos dem kan vara den enda möjligheten att kommunicera sina behov för de kommande två till tre dagarna. 2.3 Tolkning Tolkningen av intervjuerna, som det förutsätts att man har använt som metod, skall ske inom 48 timmar från intervjutillfället. Tolkningen sker genom ett diskussionsmöte/rollspel med 4 6 personer där den som har intervjuat är sig själv. Andra roller är: Arbetsmodeller: En eller flera personer som representerar en eller flera av arbetsmodellerna från ovan. Ritar modellerna på blädderblock allt eftersom intervjuaren återger sina resultat. Endast råa fakta får ritas upp, inga tolkningar skall göras. Sekreteraren: För anteckningar på dator och visar upp dem så att alla kan se med hjälp av en projektor eller stor skärm. Moderator: Skall se till så att intervjuaren håller en rak linje genom sin berättelse och att tempot är relativt högt. Om intervjuaren tappar bort sig eller gräver ner sig för mycket i en fråga så är det moderatorn uppgift att mana på eller ge tillbaka tråden. Moderatorn får inte bli för involverad i diskussioner eller utvikningar utan måste då lämna över sin roll till någon annan. Råtthålsvaktaren: Råtthålsvaktarens uppgift är att skrika Råtthål! om diskussionen fastnar på en punkt för länge eller om man hamnar utanför ämnet. Anledningen till att man har valt denna, något udda, form av avbrott är för att den som blir avbruten inte skall ställa sig defensivt gentemot den som försöker driva vidare. Istället kan man skratta och gå vidare.

7 Deltagare: Alla på mötet har också rollen som deltagare. En deltagares uppgift är att ställa frågor och komma med idéer. Dock inte att diskutera andras förslag eller intervjuarens fakta, detta görs senare för att man inte skall låsa sig vid designidéer i ett tidigt stadium. Ett möte skall hålla på i cirka två timmar. Varje deltagare sammanfattar sina bästa insikter från mötet och dessa sätts upp på lappar på väggen. I detta steg är det svårt att se om något skulle skilja sig från standardförfarandet. Det kan dock vara lämpligt att sammanföra de olika gruppernas (sköteskor, vårdtagare och administrationen kan lämpligen ha intervjuats av olika grupper) resultat på en Dela med sig session. Ett möte där två representanter från varje grupp presenterar och diskuterar resultaten från sin grupps möte. 3 Konsolidering 3.1 Tillhörighetsdiagram Under denna delen av processen så tar man lapparna som deltagarna skrev i slutet på sitt gruppmöte och sorterar dem. Det handlar dock inte om en fast modell för sortering utan en princip om att det man tycker hör ihop sätter man i en grupp. Man tillåter inte att utvecklarna grupperar data efter tidigare erfarenhet. Om man har löst en liknande uppgift innan så kan det vara frestande att ta med sig en gruppering (som leder till en viss lösning) från detta tidigare projekt. Det kan till och med vara värt att bannlysa vissa ord som inte får användas i beskrivningar och namn. Allt detta för att få en struktur som är rent baserad på den data man har och inte färgad av tidigare projekt eller en viss modell. Hela modelleringen görs på en vägg och ett bestämt färgsystem används för att hålla isär vilken nivå de olika lapparna tillhör. I slutändan har man skapat en trädliknande struktur, som kan ha flera rötter, som abstrakt representerar en lösning. 3.2 Genomgångar När tillhörighetsdiagrammet är färdigt så långt så är det dags för genomgångarna. En och en så går projektmedlemmarna igenom rummet och reflekterar tyst över strukturen. Man skriver ner saker som man tycker fattas och designidéer som man får för delar av systemet. Sedan går man igenom samma sak igen fast två och två och diskuterar vad de andra har skrivit och kommer med nya förslag och idéer. Slutligen så går hela gruppen i och betraktar strukturen för att bekanta sin med idéerna och får en bättre översikt.

8 3.3 Designrummet Det rum som man skapat ovan genom att samla och sammanföra data från kunderna kallas designrummet. Detta rum kommer att användas som centrum under hela utvecklingsprocessen. Alla nya idéer som tillkommer förs upp på väggen och alla ändringar skall synas. Idéen bakom ett designrum är ganska sund. Vi använder oss väll alla av stora ytor för att få översikt över våra tankar och att erbjuda en yta för detta inom utvecklingsprocessen är därför en bra idé. På samma sätt som en bra produkt skall stödja kundernas behov och arbetssätt så skall en bra process stödja utvecklarens. 4 Prototyper 4.1 Design Design sessionen består i ett brainstormingmöte där man, återigen, använder sig av roller för att styra diskussionen. Man väljer ett antal startpunkter som är relevanta utifrån datan i designrummet, tex Vårdtagarna skall kunna ringa in sina handlarlistor. eller Det skall finnas en pekskärm på kylen där man kan peka på det man vill beställa hem. Utifrån startpunkterna diskuterar man sedan fram en vision och om diskussionen hamnar för långt utanför ämnet eller kommer tillbaka till samma idé på ett nytt sätt så gör man det till en ny startpunkt. En sekreterare antecknar alla visioner och ser till så att samtalen förs framåt. Alla visioner sätts sedan upp i designrummet och man diskuterar igenom dem och sätter ut för och nackdelar. Om man kommer på en lösning till en nackdel senare så sätts även den ut. Visionerna är tänkta att fungera som idédatabas för designen. Från alla visioner väljer man sedan de bästa bitarna från varje. De smartaste lösningarna på nackdelarna. Detta blir sedan till den grundläggande designidén. Design, prototyp och evaluering itereras tills man når en design som användarna är nöjda med. 4.2 Prototyp Prototyper inom Contextual design skall hållas enkla. Oftast så nöjer man sig med pappersprototyper och muntliga beskrivningar av vad systemet gör vid ett visst agerande. Man använder sig också av data från användarens vanliga arbete för att de lättare skall kunna sätta sig in i hur systemet kommer att fungera i kontrast till vad de är vana vid. 4.3 Evaluering När man väl har en prototyp så är det viktigt att användarna får se den och komma med synpunkter. Ju fler synpunkter desto bättre slutprodukt, generellt.

9 4.3.1 Intervju Detta är steget när man tar sina prototyper till användaren och håller en intervju med dem där man beskriver hur systemet fungerar och lyssnar på vad de tycker och föreslår. Det är viktigt att komma ihåg att designern skall komma med förslag och möjligheter medan det är användaren som bestämmer var som är bra design för just dem Problem Det stora problemet i detta steget kommer utan tvekan att vara vårdtagarnas deltagande. Förhoppningsvis har man valt relativt bra metaforer och gjort en icketeknisk lösning, en lösning där tekniken inte märks, så långt det går. Man skulle kunna använda sig av det faktum att det finns vissa äldre, som är insatta i tekniken, kan agera testgrupp. Det antagande man då gör är att de är representativa för alla användare av den delen av systemet och det är med mycket stor sannolikhet inte så. Kärnan i problemet blir att försöka förklara för vårdtagaren som man intervjuar hur det kommer att fungera på ett sådant sätt att denne kan komma med konstruktiv kritik. Gamla Agda, som bara får besök en gång var tredje dag av en sköterska, kommer nog att tycka att det är väldigt trevligt med någon som visar henne uppmärksamhet i en timme eller så. Men kommer hon att förstå vad det är man försöker presentera? Kommer hon att kunna ge sådan kritik att det färdiga systemet verkligen blir användbart och framförallt, använt?

10 5 Tidsplan Vi anser att denna fråga är konstigt formulerad. Om ni menar att vi skall komma med en uppskattning på hur stor del av projekttiden som är rimlig i de olika delarna så har vi bifogat en sådan, men frågan är i så fall väldigt otydlig. Anledningen till att vi har tolkat det så är att alternativet är att ni ber oss göra en uppskattning av hur lång tid det skulle ta att genomföra ett projekt om vars omfattning vi inte vet någonting. Är det glada gläntans äldreboende med 10 platser som har beställt eller är det Sveriges landsting? Utan dylik information så är det omöjligt att ens göra en lekmannamässig, vilket är det ni hade fått, uppskattning av tidsåtgången. Vi minns att en av våra gästföreläsare, som varit aktiv i industrin i många år, fick en fråga angående ett specifik projekt med en specifik omfattning. Han kunde inte göra en uppskattning och svarade med att de lägger veckor på att undersöka hur långt tid det kommer att ta att genomföra ett projekt innan de lägger sina anbud. 5.1 Uppskattning Informationsinsamling 30%; Eftersom alla stegen som beskrivs under denna rubriken sker mer eller mindre samtidigt så är det svårt att göra en striktare uppdelning av tidsåtgången här än så. Konsolidering 10%; Visserligen så är det en stor och tung uppgift. Men alla momenten har betoning av att ske ganska snabbt. Man skall agera intuitivt på den data man har och inte tänka för mycket. Design Prototyp Evaluering 60%; Huvuddelen av tiden kommer att hamna här. Detta är visserligen det steg som kommer att få stryka på foten om tidsramen inte håller eller om man börjar glida över budget. Men målsättningen skall vara att man skall hålla på tills man är klar. Hellre be om för mycket pengar i början än att sakna dem när man väl kommer dit. Implementationen täcks inte in av vår modell. Men eftersom man inte har några krav på UI eller funktionsdesign i implementationsfasen så kan man nog räkna med att kostnaderna för implementation blir lägre i ett Contextual design projekt än i ett klassisk mjukvaruprojekt.