Handläggningssstöd för synskadade Baserat på teorierna av Constantine & Lockwood

Grupp 4: Petter Midtsian, pemi1033@student.uu.se Handläggningssstöd för synskadade Baserat på teorierna av Constantine & Lockwood Ett projekt i Användarcentrerad systemdesign, Uppsala universitet, Ht 05

1 Inledning... 3 1.1 Syfte... 3 1.2 Constantine och Lockwoods användningscentrerade systemdesign... 3 1.3 Uppdraget: Handläggningssstöd för synskadade... 5 1.4 Antaganden och avgränsning av uppgiften... 5 2 Genomförande... 6 2.1 Collaborative Requirements Dialog... 6 2.1.1 Input... 6 2.1.2 Inblandade roller... 7 2.1.3 Resultat... 7 2.1.4 Beskrivning... 7 2.2 Task modeling... 7 2.2.1 Input... 7 2.2.2 Inblandade roller... 7 2.2.3 Resultat... 7 2.2.4 Beskrivning... 7 2.3 Operational Contextualization... 8 2.3.1 Input... 8 2.3.2 Inblandande roller... 8 2.3.3 Resultat... 8 2.3.4 Beskrivning... 8 2.4 Standards and Style Definition... 8 2.4.1 Input... 8 2.4.2 Inblandande roller... 8 2.4.3 Resultat... 8 2.4.4 Beskrivning... 8 2.5 Interface Content Modeling... 9 2.5.1 Input... 9 2.5.2 Inblandande roller... 9 2.5.3 Resultat... 9 2.5.4 Beskrivning... 9 2.6 Implementation Modeling... 9 2.6.1 Input... 9 2.6.2 Inblandande roller... 9 2.6.3 Resultat... 9 2.6.4 Beskrivning... 9 2.7 Usability Inspection... 9 2.7.1 Input... 9 2.7.2 Inblandande roller... 9 2.7.3 Resultat...10 2.7.4 Beskrivning...10 2.8 Processens resultat...10 2.9 Tidsplan...10 3 För- och nackdelar med metoden...11 4 Källor...12

1 Inledning Det har aldrig varit lätt att vara synskadad. Internet och andra IT-lösningar har underlättat tillgången till information hos de allra flesta i samhället, men de synskadade har inte kunnat nå den på samma sätt. Med ökad prestanda på datorer och andra verktyg ökar dock möjligheterna även för synskadade att ta del av informationsutbudet. Men vilket är egentligen det bästa sättet för att utveckla ett informationssystem för synskadade? 1.1 Syfte Uppgiften går ut på att beskriva, planera och diskutera processen för hur ett fiktivt IT-baserat system ska utvecklas utifrån ett specifikt synsätt på användarcentrerad utveckling. 1 1.2 Constantine och Lockwoods användningscentrerade systemdesign Det angreppssätt Constantine och Lockwood använder sig av är något de själva kallar usagecentered design. Jag kommer att översätta detta begrepp till användningscentrerad design. Utgångspunkten är att fokus ska ligga på användandet och inte på användarna, vilket författarna menar är en viktig skillnad mot de användarcentrerade metoderna. Alla system är verktyg för att utföra något och fokus bör ligga på hur dessa verktyg används, inte på vem som använder dem eller på verktyget i sig. Vilka som använder verktygen och hur dessa är utformade är naturligtvis också viktigt, men det centrala är användandet. 2 Målet med Contantine och Lockwoods metod är att systemet som utvecklas ska bli lätt att lära, lätt att komma ihåg, effektivt att använda, innehålla få fel och vara subjektivt tilltalande. Dessutom ska själva utvecklingsprocessen underlättas och effektiviseras. För att uppnå dessa mål tycker författarna att utvecklingen ska ske genom en process som leds av fem centrala element: 3 Pragmatiska designanvisningar. Systemutvecklingen ska baseras på riktlinjer för både användbarhet och design. Författarna definierar dessa regler, på en detaljerad nivå, för vad som kännetecknar ett väldesignat och användbart system. Modellbaserad designprocess. För att förstå användandet är det viktigt att arbeta med modeller då dessa underlättar möjligheten att kommunicera både med användare och med programmerare. Organiserade utvecklingsaktiviteter. För att effektivisera och underlätta utvecklingen behövs en del aktiviteter preciseras. Mer om detta följer nedan. Iterativ förbättring. Det är mycket svårt att få ett fungerande system på en gång. Genom att utföra tester löpande blir det lättare att göra förbättringar. Man bör först konstruera en kärna med de viktigaste funktionerna för att sedan utöka systemet successivt. Kvalitetsmätningar. Det är viktigt att kunna jämföra systemet med andra möjliga sätt att utveckla det. Genom att arbeta med prototyper och andra jämförelsemedel kan man se hur systemet blir relativt andra möjliga utvecklingar. 4 1 Boivie, I, http://www.it.uu.se/edu/course/homepage/acsd/ht05/projekt, besökt 051210 2 Constantine, L (1995), sid. 3 3 Egen översättning. Elementen kallas Pragmatic design guidelines, Model-driven design process, Organized development activities, Iterative improvement och Measures of quality i original. 4 Constantine o Lockwood (1999), sid. 23-25

Centralt med metoden är också att designern ska sträva efter att göra ett så enkelt och generellt användbart system som möjligt. Genom att återvända till tidigare moment och förenkla eller återanvända dessa blir systemet smidigare och mer kärnfullt. 5 Användningscentrerad design beskrivs som en strukturerad process som kan delas in i olika separata delar. Det innebär inte att processen kan ses som ett linjärt förlopp, i praktiken kommer de inblandade i projektet att hoppa fram och tillbaka mellan aktiviteterna och alla delar är inte med i alla projekt. Men en modell gör de lättare för de inblandade att veta vad de håller på med. De aktiviteter som ingår i angreppssättet visas i Figur 1. Den visar också hur dessa överlappar varandra och förhåller sig till varandra i tiden. 6 Figur 1 Aktivitetsmodell för användningscentrerad design. De aktiviteter som innefattar användare är markerade med en stjärna och de som innefattar konstruktion av systemet är ifyllda. 7 Collaborative Requirements Dialog innebär att utvecklarna, beställarna och användarna tillsammans diskuterar och förhandlar om vilka grundläggande krav som ska ställas på systemet. Task modeling är kärnan i det användningscentrerade synsättet. Användarna och de uppgifter de utförs beskrivs för att veta vad systemet ska användas till. Domain Modeling handlar om att sammanställa inom vilka områden systemet ska användas. Operational Contextualization handlar om att kartlägga i vilken miljö systemet kommer att användas och vilka speciella behov användare har. Standards and Style Definition innebär att ta fram utseendemässiga standarder för hur systemet presenteras för användaren. Help Systems and Documentation tar fram stöd och dokumentation för systemet. Interface Content Modeling definierar de verktyg som systemet tillhandahåller för att lösa de uppgifter användarna efterfrågar. 5 ibid., sid. 33 6 ibid., sid. 34 7 Figuren är hämtad från ibid. sid. 34 (Usage-centered design activity model).

Implementation Modeling gör en visuell design av systemet med hjälp av prototyper. Usability Inspection förekommer på två platser, före och efter faserna då huvuddelen av systemet kodas. Object Structure Design är att hålla ordning på sina objekt för att minska och förenkla systemet. Concentric Construction innebär att utvecklingen baseras på uppgiftsanalysen och byggs iterativt i lager. Architectural Iteration är en kontroll för att se till att strukturen bibehålls mellan iterationerna. 8 Constantine och Lockwood ser användare som experter på sina arbetsuppgifter och deras eget systemanvändande och systemutvecklare som experter på mjukvara och användbarhetsdesign. De menar att användarna bör vara med vid ett litet antal välspecificerade tillfällen för att effektivt använda både användarnas och utvecklarnas tid (se markeringar i Figur 1). När det är jobb som utvecklarna ska göra ska inte användarna blandas in eftersom de inte tillför något. Rollerna kompletterar varandra och de båda grupperna bör göra det som de är experter på. 9 1.3 Uppdraget: Handläggningssstöd för synskadade Talboks- och punktskriftsbiblioteket (TPB) är en myndighet som har i uppgift att förse personer med funktionshinder (huvudsakligen synskadade och dyslektiker) med litteratur anpassat utefter deras förutsättningar. Det kan handla om att producera talböcker av kurslitteratur eller digitala versioner av böcker för skärmläsare, osv. TPB har beslutat sig för att ha målgruppen representerad bland sina handläggare, vilket ju då givetvis ställer speciella krav på designen av deras handläggningsstöd. Samtidigt är det en liten myndighet utan tillgång till så stora utvecklingsresurser, varför man blir tvungen att förlita sig på standardsystem och redan utvecklade lösningar. Hur kan man på ett användarcentrerat sätt jobba med blinda och synskadade brukare som inte lika enkelt kan ta till sig prototyper och andra visuella representationer av systemen. Hur hanterar man hela utvecklingsprocessen från krav till leverans och underhåll när man jobbar under dessa speciella förutsättningar med en extern leverantör? 10 Synskadade är de personer som har svårt att läsa vanlig text eller orientera sig på okända platser med hjälp av synen, trots glasögon. Det innefattar både blinda och synsvaga personer. 11 1.4 Antaganden och avgränsning av uppgiften Det sätt som uppgiften är beskriven på gör att det finns en del utrymme för tolkningar. Jag har valt att se uppdraget som att TPB redan har ett existerande handläggningssystem som är utvecklat för de användargrupper som tidigare varit användare av det, men behöver utöka det för att möjliggöra de synskadades användning av det. Det innebär att uppgiften huvudsakligen blir att fram nya interface för systemet och viss ytterligare funktionalitet för att stödja de nya användargrupperna, men inte att ta fram ett helt nytt system. Jag har också valt att se TPB som en organisation som har mycket begränsade resurser för att utveckla sitt handläggningsstöd. Detta medför att de inte kan lägga så stort fokus på alla delar 8 Ibid. sid. 35-36 9 Constantine o Lockwood (1999), sid. 484 10 Boivie, I, http://www.it.uu.se/edu/course/homepage/acsd/ht05/projekt, besökt 051210 11 SRFbroschyr, www.srfriks.org, besökt 051207

i modellen och att TPB inte har möjlighet att fullt ut ge stöd till blinda användare utan får nöja sig med att ha med synsvaga och dyslektiker bland sina handläggare. Jag ser det som ett rimligt antagande baserat på uppgiftsbeskrivningen och har valt att göra det eftersom jag blev ensam i min grupp och därmed inte ville ha en lika omfattande uppgift. Constantine och Lockwood framhåller att deras metoder är möjliga att skala ner till att omfatta mycket begränsade delar av den ursprungliga modell som de beskriver ser jag inte detta som något problem ur metodhänseende 12. Dessa avgränsningar gör att jag kommer att utgå från en nedbantad version av Constantine och Lockwoods modell: Figur 2 De aktiviteter i den användarcentrerade systemdesignen som jag kommer att beröra. De skuggade bubblorna kommer inte att avhandlas. De aktiviteter som innefattar användare är även här markerade med en stjärna. Förutom dessa avgränsningar i metoden kommer jag heller inte att genomföra själva systemutvecklingen då det inte ingår i denna uppgift. 2 Genomförande Constantine och Lockwood beskriver en modell för att involvera användarna i utvecklingen som de kallar Joint Essential Modeling (JEM). Den går ut på att användare, utvecklare och beställare träffas och diskuterar systemet utifrån förbestämda teman. Jag kommer att beröra denna modell här, men kommer att utgår från de aktiviteter som jag presenterat tidigare. Jag kommer att använda de engelska termerna från JEM då jag inte hittat några bra svenska översättningar. 13 2.1 Collaborative Requirements Dialog 2.1.1 Input För att genomföra det här steget krävs inget material eftersom det är det första momentet. 12 Se t ex Constantine och Lookwood (1999) sid. 37. 13 Den följande beskrivningen av tillvägagångssättet baseras på resonemanget i Constantine och Lockwood (1999), huvudsakligen kap. 20.

2.1.2 Inblandade roller Sponsor: En representant från beställarens sida. Har som uppgift att öppna och avsluta mötet med leder det inte. Användare: Representanter från flera områden, både domänexperter och riktiga användare. Lead analyst: Expert på användningscentrerad design och tekniskt kompetent. Fungerar mest som konsult i svårare frågor och som stöd till resten av gruppen. Facilitator: Är en neutral ledare för gruppen. Scribe: Skriver ner det som sägs och bestäms, behöver ha kunskap inom systemutveckling för att kunna fungera effektivt. 2.1.3 Resultat Bakgrundsmaterial, översikt över området, grundläggande vision om vad systemet ska användas till, preliminär lista över användargrupper, lista över vilka som ska vara med på kommande möten. 2.1.4 Beskrivning Det här steget innefattar att fastställa på ett översiktligt plan vad det är systemet ska göra. Det är viktigt att fastställa systemets mål och att inte blanda ihop det med projektets mål, då det inte alltid är samma sak. Genom att börja stort och undersöka användare och låta dessa önska fritt vad de eftersträvar samlas mycket information in. I det här fallet skulle beställare och utvecklare börja med att fritt brainstorma vad systemet skulle kunna användas till, utan att införa så mycket begränsningar. Detta skulle kombineras med att utvecklarna skulle studera det existerande handläggarstödet för att se hur det fungerar idag och framförallt vilka uppgifter som utförs och hur detta görs. För att undersöka det skulle utvecklarna göra contextual inquirys och diskutera med grupper av nuvarande användare. Dessutom skulle en studie av de synskadade genomföras för att få en bättre bild av deras förutsättningar. Rollen som Lead analyst skulle inte finnas då projektet är relativt litet. 2.2 Task modeling 2.2.1 Input Detta steg baseras på den information som erhållits från Collaborative Requirements Dialog: deltagarna är de som beslutades där, den preliminära listan över användargrupper används liksom systemets övergripande vision. 2.2.2 Inblandade roller Samma som ovan. Användargruppen kommer bestå av representanter från de användarroller som definieras när de är bestämda. 2.2.3 Resultat Systemets mål, användarrollmodell, karta över användarroller, lista över alla viktiga användningsfall med förklaringar, karta över användningsfall, beslut om fokala användningsfall och i vilken ordning funktioner ska implementeras. 2.2.4 Beskrivning Aktiviteten består av två steg som var och en kan ta en eller flera träffar i anspråk. Det första momentet är att identifiera användarroller och det andra är att identifiera användningsfall och hitta de viktigaste av dessa. Inom den användningscentrerade systemdesignen vill man hålla

beskrivningar av roller och användningsfall på en så abstrakt nivå som möjligt för att inte låsa sig i ett tidigt stadium. Det går hand i hand med att låta användarna göra sina saker och utvecklarna sina, de tekniska lösningarna ska lämnas till de som kan det bäst. Aktiviteten har som mål att få fram några centrala Essential Use Cases som systemet sedan kan baseras vidare på och en prioriteringsordning för hur funktioner ska införas. Här skulle man börja med att göra en kartläggning av de roller som finns i organisationen idag och komplettera detta med de roller som skulle tillkomma. Genom att koppla samman dessa skulle man kunna se på vilket sätt de skiljer sig från varandra. Eftersom modellerna görs på en abstrakt nivå skulle de inte skilja sig så mycket, uppgifterna som handläggarna utför är de samma oavsett om handläggaren är synskadad eller inte. 2.3 Operational Contextualization 2.3.1 Input Baseras huvudsakligen på användarrollmodellerna. 2.3.2 Inblandande roller Projektledare och designer, men inte användare. 2.3.3 Resultat Mer detaljerade användarprofiler (incumbent profile), interaktionsprofiler. 2.3.4 Beskrivning Genom att gå in mer i detalj på i vilken miljö som systemet kommer att användas och om användarna har några speciella förutsättningar ska aktiviteten få med en större helhet i utvecklingen. Det här momentet är viktigt i det här fallet. Eftersom inte de synskadade skiljer sig från de övriga användarna när uppgifterna beskrivs i form av Essential Use Cases måste olikheterna fångas in här. 2.4 Standards and Style Definition 2.4.1 Input Användarrollmodellerna, användningsfallen, om det finns: önskningar på utseendet från beställaren. 2.4.2 Inblandande roller De viktiga användargrupperna, designers, beställare, utvecklare. 2.4.3 Resultat Ett sätt att presentera information i systemet. 2.4.4 Beskrivning I detta moment tas standarder fram för hur informationen förmedlas från systemet till användaren.

För att systemet ska stödja de synskadade användarna måste denna uppgift arbetas igenom ordentligt. Det finns redan en standard för text i det system som finns, men det måste justeras till de nya användarnas behov. Dessutom behövs talstöd. 2.5 Interface Content Modeling 2.5.1 Input Användningsfall. 2.5.2 Inblandande roller Gränssnittsdesigner. 2.5.3 Resultat En abstrakt beskrivning av samspelet mellan användaren och systemet för varje användningsfall, gärna i form av ett papper och några post-it-lappar, och en karta över hur en användare kan navigera i systemet. 2.5.4 Beskrivning Genom att gå igenom varje användningsfall och på en abstrakt nivå bestämma vad de ska innehålla och hur man rör sig mellan dessa skapar man en översiktlig bild av systemet. I det här fallet borde det här inte vara en så stor sak då det redan finns ett system och strukturen på det inte går att ändra utan vidare. 2.6 Implementation Modeling 2.6.1 Input Den abstrakta beskrivningen från Interface Content Modeling, användningsfallen. 2.6.2 Inblandande roller Gränssnittsdesigner. 2.6.3 Resultat En prototyp av hur gränssnittet kan komma att se ut, gärna på papper. 2.6.4 Beskrivning Genom att gå vidare med den abstrakta modellen från Interface Content Modeling skapas ett första utkast till interface. I det här fallet är den här fasen inte heller så viktig, av samma anledning som den förra. 2.7 Usability Inspection 2.7.1 Input Allting som producerats så långt. 2.7.2 Inblandande roller De viktiga användargrupperna, designers, beställare, utvecklare.

2.7.3 Resultat En prototyp som kan gå vidare till de mer programmeringsintensiva faserna. 2.7.4 Beskrivning Genom att utvärdera de prototyper som kommit från de tidigare momenten så får användarna ta ställning till om det blivit något som svarar mot deras behov. För att den här fasen ska ge något bra resultat är det centralt att det kommit in modeller som de nya användargrupperna kan ta till sig. Det här fallet ställer högre krav på prototyperna då dessa måste vara tillgängliga även för användare som ser mycket dåligt. Prototyperna behöver vara på högre nivå så att de också kan ge talstöd då detta är centralt för att vissa användare ens ska kunna utvärdera om de är användbara eller inte. 2.8 Processens resultat Det som borde komma ut från den här utveckligsprocessen är ett kompletterande gränssnitt som är användbart för personer med synskador. Det vore bra om de som inte har nedsatt syn kan fortsätta använda det gamla gränssnittet, men att det ska finnas möjlighet att välja ett som är bättre anpassat. Det ska vara helt anpassat för skärmläsningsverktyg och följa andra rekommendationer för att vara anpassat för synskadade 14. 2.9 Tidsplan Tid 30 Collaborative Requirements Dialog resurser: projektledare, scribe 40 Task modeling resurser: projektledare, scribe 40 Operational Contextualization resurser: projektledare, gränssnittsdesigner 40 Standards and Style Definition resurser: projektledare, gränssnittsdesigner 5 Interface Content Modeling resurser: gränssnittsdesigner 5 Implementation Modeling resurser: gränssnittsdesigner 30 Usability Inspection resurser: projektledare, gränssnittsdesigner 80 Programmeringsaktiviteterna resurser: projektledare, programmerare 10 Hjälp och resurser resurser: projektledare, programmerare 30 Usability Inspection resurser: projektledare, gränssnittsdesigner Totalt 310 timmars utvecklingstid, vilket skulle kunna omfatta sex veckor i kalendertid. 14 Se Öppna IT-världen för synskadade på www.srfriks.org.

3 För- och nackdelar med metoden När jag använde Constantine och Lockwoods angreppssätt på det givna uppdraget stötte jag på två huvudsakliga problem. Det första av dessa är det rent praktiska problemet att metoden baseras mycket på kommunikation som bygger på synintryck och det andra att metoden inriktar sig på uppgifter och inte på användarnas behov. Det praktiska problemet ställer till besvär då utvecklarna ska kommunicera med användarna. För att förklara systemet används till stor del användarrollmodeller och användningsfall, och dessa är inte så svåra att förmedla även till en person som inte kan se. Eftersom det är Essential Use Cases som används så är det inte så mycket information som behöver förmedlas. Det är svårare att förmedla kartor över hur användningsfallen hänger ihop med varandra eller hur man navigerar i systemet. När det kommer till att göra prototyper av systemet ställer det högre krav på utvecklarna eftersom dessa bör ha talstöd i ett tidigt skede för att kunna utvärderas av användarna. Det andra problemet tyckte jag var värre eftersom det handlade om att metoden inte riktigt passade till uppgiften. Då fokus i den användningscentrerade systemdesignen tydligt ligger just på användning och uppgifter finns det en risk att användarens behov tappas bort. I detta fall kommer handläggarna att utföra samma uppgifter, men på olika sätt beroende på förutsättningarna. Det finns stöd för att lösa detta i Constantine och Lockwoods metod, men jag tror att en modell som tydligare fokuserar på användarna skulle vara bättre i det här fallet. Att jag gjorde antagandet att det redan fanns ett system gjorde också att det användningscentrerade angreppssättet fick det lite svårare, i och med det finns det ingen möjlighet att göra om alla uppgifter och systemets arkitektur för att göra det smidigare. Generella positiva aspekter med metoden tycker jag var att den kändes verklig. Den är begränsad till vilken grad användare involveras och i verkligheten tror jag att det är svårt att få med dessa i så många moment. Det är då bra med en metod som säger det och ger stöd för att veta när man ska använda användarna, annars kan det vara svårt att besluta när det är det viktigast att ta med dem. Naturligtvis föreligger en risk att användarna är med för lite och att deras behov inte kommer med, men det är alltid en tradeoff. Om det blir mer kostnadseffektivt är det också en mening, det är ingen idé att bygga utopiska modeller som ändå inte går att använda i verkligheten. Risken med att användarnas behov kommer bort tycker jag förstärks genom användandet av abstrakta roller och användningsfall. Det ger programmerarna stor frihet och möjlighet att göra bra lösningar, men det blir svårt för de som fångar upp behoven att förmedla dessa.

4 Källor Constantine, L, Lockwood, L (1999) Software for use A Practical Guide to the Models and Methods of Usage-Centered Design. Addison Wesley, USA. Constantin, L (1995) What Do Users Want? Engineering Usability into Software. Publicerad i Windows Tech Journal, december 1995. Hämtad från www.foruse.com. Boivie, I, http://www.it.uu.se/edu/course/homepage/acsd/ht05/projekt, besökt 051210 SRFbroschyr, www.srfriks.org, besökt 051207 Öppna IT-världen för synskadade, www.srfriks.org, besökt 051207