In-flight Information System utveckling med ett användningscentrerat synsätt

Uppsala Universitet Institutionen för informationsteknologi Användarcentrerad Systemdesign, 5p In-flight Information System utveckling med ett användningscentrerat synsätt Erik Salomonsson erik@salomonsson.net Karl-Oskar Lundin karloskarlundin@hotmail.com Mats Troeng mats.troeng@swipnet.se Olle Widell olle@widell.se

Innehållsförteckning Användningscentrerad design en översiktlig beskrivning av processen...2 Vårt uppdrag - In-flight-system...4 Användarroller...5 Rollkarta...5 Användningsfall...6 Användningsfallskarta...7 Innehållsmodellering: Interaktionsmiljöer & navigationskarta...7 Implementationsmodellering: Detaljerad visuell design & flödesdiagram...9 Användbarhetsinspektion...9 Vad kan göras bättre?...10 Tidsplan...11 Källor...12 1

Användningscentrerad design en översiktlig beskrivning av processen Människor är verktygsanvändare. Vi använder oss av verktyg för att få bättre grepp, för att se bortom horisonten, för att bygga saker och riva dem, men också för att göra andra verktyg. Alla mjukvarusystem är verktyg, och mjukvaruutvecklare är därför byggare av verktyg. Bra verktyg hjälper sina användare att fortare uppnå sina mål, med en mindre arbetsinsats eller helt enkelt på ett enklare sätt. Användningscentrerad design syftar till att hjälpa utvecklare att bygga mer användbara verktyg. Användningscentrerad design är en modelldriven designprocess som använder sig av abstrakta modeller som representerar koncepten och idéerna utifrån vilka systemet kommer att byggas. Den mest centrala modellen och faktiskt det absolut minsta man måste utföra i en användningscentrerad process är uppgiftsmodellen (Task Model). Denna beskriver med hjälp av essentiella användningsfall de uppgifter som användarna kommer att behöva lösa. Dessa användningsfall är helt teknikbefriade vilket gör att de dels blir enklare och mer överskådliga men också att man i detta skede inte tvingas in i olika lösningar på grund av tekniska restriktioner. Den huvudsakliga skillnaden mellan användningscentrerad design och användarcentrerad design är enligt Constantine & Lockwood att användarcentrerad design fokuserar på användarnas upplevelse och tillfredsställelse, medan användningscentrerad design fokuserar på användning och försöker ta fram förbättrade verktyg (system) som gör det lättare för användarna att utföra sitt arbete. Användningscentrerad design består av ett antal koordinerade aktiviteter som bidrar till användbarhet. Aktiviteterna kan ses som dominobrickor som kan sättas ihop på lite olika sätt för att åstadkomma en välkonstruerad mjukvara. Beroende på vilket slags system som ska konstrueras kan det ibland vara lämpligt att till exempel helt plocka bort vissa aktiviteter, medan det i andra fall är helt nödvändigt att man verkligen utför alla aktiviteter till punkt Domain Modeling Tid Collaborative Requirements Dialog Task Modeling Interface Content Modeling Implementation Modeling Usability Inspection Concentric Construction Usability Inspection och pricka. Bilden intill beskriver schematiskt de olika aktiviteterna. Notera att det inte är frågan om en vattenfallsmodell som går i strikt ordning från aktivitet till aktivitet. Man utför aktiviteterna i den ordning och omfattning som passar det aktuella projektet. Vissa aktiviteter Object Structure Design Operational Contextualization Standards and Style Definition Architectural Iteration Aktivitetsmodellen för användningscentrerad design. Aktiviteter som involverar användare är markerade med Help System and Documentaion 2

kanske överlappar varandra eller utförs helt parallellt. Nedan följer en kort beskrivning av vad de olika aktiviteterna går ut på. Processen börjar med något som kallas Collaborative Requirements Dialog. I denna aktivitet bestämmer utvecklare tillsammans med användare och kunder kraven på systemet som ska utvecklas. Task Modeling eller uppgiftsmodellering är centralt inom användningscentrerad design. Här använder man sig av rollmodeller och essentiella användningsfall (task cases) för att få fram vilket arbete systemet ska stödja. Domain Modeling ligger egentligen lite utanför ramen för användningscentrering. Denna aktivitet syftar till att bestämma relationerna mellan alla relaterade delar i projektet. Dessa relationer beskrivs oftast som ett ER-diagram eller klassdiagram. Interface Content Modeling följer efter uppgiftsmodelleringen. (Den kan också utföras parallellt med uppgiftsmodellering). Denna modell representerar användargränssnittets innehåll och hur det är organiserat på en abstrakt nivå. Implementation modeling ger detaljerade beskrivningar av användargränssnittet genom prototyper. Usability inspection återfinns på två ställen i aktivitetsmodellen: Före och efter implementationsaktiviteterna Concentric construction och Architectural Iteration. Implementationsfasen i projektet består av de två aktiviteterna Concentric Construction och Architectural Iteration. Concentric Construction är en process för att utveckla system inkrementellt. Architectural Iteration är en metod för att bibehålla en bra övergripande programvaruarkitektur allteftersom nya delar av systemet implementeras. Operational contextualization syftar till att anpassa systemets design till existerande tekniska begränsningar och den miljö som det ska användas i. I stället för att börja med att fokusera på dessa aspekter börjar man i användningscentrerad design med att fokusera på det arbete som ska utföras med hjälp av systemet (Task Modeling), för att efterhand anpassa användargränssnittet till den miljö i vilken det ska användas. Aktiviteten Standards and Style Definition utförs liksom Operational contextualization efterhand som man bestämmer vilket arbete som systemet ska stödja. Vissa standarder och definitioner kommer säkert att finnas redan innan projektet börjar, men meningen är att man inte ska sätta upp standarder som hindrar utvecklingen av ett system anpassat till uppgifterna som ska utföras. Help System and Documentation är också aktuell under hela utvecklingsprocessen. I utvecklingen av ett bra hjälpsystem kan man använda sig av essentiella användningsfall på liknande sätt som i uppgiftsmodelleringen. Användningsfallen beskriver en rad olika situationer där användare av systemet behöver hjälp i någon form. 3

Vårt uppdrag - In-flight-system Uppdraget är att vidareutveckla den typ av informationssystem som finns i moderna flygplan. Systemet visar flygplanets aktuella läge, väderinformation, tid etc på bildskärmar vid passagerarnas sittplatser. Man kan tänka sig många nya funktioner i en vidareutveckling av ett sådant system. Visning av filmer, spel, Internetsurfning och beställning av taxfreevaror är några exempel. Vi tänker oss ett system som ger passagerarna utförlig information om resmålet. Det skulle t ex kunna vara möjligt att boka biljetter till olika attraktioner på resmålet. Information om anslutningsresor (tåg, flyg, flygbuss, taxi etc) och tider för avgångar kan visas. En viktig uppgift är förmågan att avgränsa sig. Det vidareutvecklade systemet får inte bli för stort eller komplext. Det kommer att användas av och påverka ett antal personer. Först och främst passagerarna, men även besättningen, systemadministratörerna och andra flygbolagsanställda kommer att påverkas. Representanter för dessa roller kommer att intervjuas under processens gång. Denna rapport kommer inte att presentera några lösningar på vad som kommer att ingå i systemet. Tyngdpunkten ligger istället på hur man i detta projekt kan använda den användningscentrerade process som beskrivs i Constantine och Lockwoods bok Software For Use. Vi kommer på de följande sidorna beskriva hur den användningscentrerade processen kan anpassas till just detta uppdrag - In-flight-systemet. 4

Scenarier Scenarier är ett sätt att modellera hur en viss process/handling går till. Man beskriver processen/handlingen i berättande form. Detta är av både positiv och negativ karaktär. Positiv i den bemärkelse att många människor har svårt att tänka i abstrakta interaktioner som användningsfall normalt sett kräver och därför passar denna berättande form bra. Negativ på grund av att den är begränsad då den kan missa hur händelser relaterar till varandra. Att använda oss av scenarier vid intervjuer med vanliga användare kan komma till användning för oss vid utveckling av In-flight-systemet. Vi kan sedan använda oss av dessa scenarier och generalisera dessa för att ta fram användarroller och användningsfall. Användarroller Genom att använda oss av användarroller kan vi dela upp olika behov, förväntningar och användningsmönster mellan olika typer av användare. Modellen är enkelt uttryckt en lista på vilka typer av användare som kommer att använda systemet samt vilka behov, förväntningar och användningsmönster dessa olika grupper har. I In-flight-systemet kan detta komma att vara personal, passagerare samt andra användare så som tax-free system. Detta beror helt och hållet på vilka funktioner systemet skall innehålla. Vi ställer följande frågor då vi tar fram de olika rollerna: Vilka kan och vilka kommer att använda In-flight-systemet? Vilken grupp tillhör dessa? Hur skiljer sig dessa från varandra när det gäller utnyttjande? Vad karakteriserar deras användning av In-flight-systemet? Vad är deras typiska behov av In-flight-systemet? Hur hanterar de systemet och hur tror de att de ska hantera det? Antalet användarroller kommer inte att bli stort för In-flight-systemet. Vi uppskattar att det ligger mellan 4 och 5 stycken användarroller. På grund av detta kommer man inte att behöva lägga så stor vikt vid framtagandet av dessa. Rollkarta För att få en uppfattning om hur olika användarroller relaterar till varandra använder vi oss av en karta där vi kan se direkt hur de olika relationerna ser ut. Detta ger oss även möjlighet att få en överblick över systemet vilket kan vara en stor fördel när vi ska utse de primära rollerna samt vilka roller som är sekundära. Detta är ett viktigt steg för att vi ska kunna utveckla ett bra användargränssnitt för de användare som kommer att använda systemet mest. 5

Relationerna som används mellan del olika användarrollerna är: Släktskap - Användarroller som har likartade behov, förväntningar samt användningsmönster. Klassifikation - Användarroll som är underklasser till en annan användarroll. Komposition - Användarroller där två eller flera andra användarroller ingår. Då In-flight-systemet enbart består av ett litet antal användarroller kan en användarrollskarta komma att vara överflödig för detta projekt. Däremot är det viktigt att vi utser de primära användarrollerna. Användningsfall Ett användningsfall beskriver hur användaren interagerar med systemet på ett meningsfullt sätt. För att undvika att redan i denna fas påverka designen av systemet kommer vi att använda oss av en speciell typ av användningsfall som kallas essentiella användningsfall. Skillnaden mellan essentiella användningsfall och den vanliga typen av användningsfall är att essentiella användningsfall är baserade på en modell som är fri från tekniska aspekter. Detta resulterar i att fokus hamnar på användarens avsikter istället för användarens agerande samt systemets skyldigheter istället för systemets respons. Vidare bidrar detta till att fokus flyttas till användarnas problem istället för systemspecifika problem. En annan fördel är att användningsfallen blir betydligt kortare och enklare vilket öppnar för många fler möjligheter vid design och implementation av användargränssnittet samt att utvecklarna och användarna förstår varandra vilket bidrar till att missförstånd kan undvikas. Man kan sammanfattningsvis säga att vi använder oss av en användningscentrerad design istället för att använda oss av en användarcentrerad design. En användarcentrerad design ger användarna vad de tror de vill ha medan en användningscentrerad design ger användarna vad de egentligen behöver. Vi kommer att använda oss av följande frågor för att få svar på vad användarna egentligen behöver: Vad försöker användarna i denna användarroll åstadkomma? För att uppfylla denna användarroll, vad behöver användarna kunna göra? Vilka funktioner behövs för att användarna ska kunna göra det? Vad är den primära uppgiften för användare i denna användarroll? Vilken information kommer användarna i den här användarrollen behöva undersöka, skapa eller förändra? Vilken information behöver användarna få från systemet? Vilken information behöver systemet få utav användarna? Ett användningsfall för In-flight-systemet skulle t.ex. kunna beskriva händelseförloppet när en användare vill se en film. 6

Användningsfallskarta Användningsfallen för stora system kan bli väldigt många och effekten av detta blir ofta att de relaterar till varandra. Genom att använda en karta för att se relationerna mellan användningsfallen kan vi på ett överskådligt sätt se hur de olika fallen relaterar till varandra och vi får en bra överblick över hela systemet. Vi kan med hjälp av denna karta sedan konstruera en bättre övergripande modell av hur arbetet bör läggas upp samt vilken kapacitet systemet bör ha. Relationerna mellan de olika användningsfallen består av följande fyra typer: Specialisering - Vissa fall är specialiserade versioner av andra fall. Denna relation kan ses som relationen klass-subklass som används i objektorienterad design. Detta ger oss möjlighet att återanvända fall som ingår i andra fall. Utbyggnad - Ett fall kan vara en utbyggnad av ett annat fall. Detta kan exempelvis vara ett fall där en viss väg genom fallet innefattar ett annat fall. Del av - Relationen del av beskriver två eller flera vägar genom ett fall. Detta kan vara ett aktivt val som användaren exempelvis gör, eller ett val som systemet gör, baserat på någon variabel. Släktskap - Vissa relationer mellan olika fall kan ibland vara otydliga. Däremot kan man ofta samla dessa olika fall inom vissa logiska eller meningsfulla grupper. För att visa denna relation används relationen släktskap. Antalet användningsfall för In-flight-systemet kommer att ligga mellan 20-30 stycken. Eftersom användarrollerna kommer att vara väl avgränsade från varandra kan denna typ av karta komma att bli överflödig för detta projekt. Innehållsmodellering: Interaktionsmiljöer & navigationskarta Hittills har inga beslut om hur själva användargränssnittet för systemet ska vara uppbyggt tagits. Hur angriper vi den frågan? Till att börja med föreslår vi att en abstrakt prototyp tas fram. Denna abstrakta prototyp visar den övergripande organisationen och strukturen för In-flight-systemets olika delar. Med de tidigare modellerade användningsfallen som grund kan en innehållsmodell och en navigationskarta tas fram. Innehållsmodellen visar på en abstrakt nivå hur de olika interaktionsmiljöerna (interaction contexts) är uppbyggda. En interaktionsmiljö är en sida, en dialog eller motsvarande i det färdiga användargränssnittet. I In-flight-systemet kan en interaktionsmiljö t ex vara en huvudmeny där användaren väljer önskad uppgift att utföra. Innehållsmodellen ska som sagt vara abstrakt. Detaljnivån når vi efter hand, i implementationsmodelleringen, när innehållsmodelleringen utförts. En metod som Constantine och Lockwood förespråkar är att modellera interaktionsmiljöernas innehåll med post-it-lappar. Dessa lappar motsvarar de olika knappar, inmatningsrutor, menyer etc som varje interaktionsmiljö består av. Med de regler och principer för användbarhet som författarna beskriver byggs sedan modellerna över interaktionsmiljöerna upp. 7

Anledningen till att modellen med post-it-lappar är lämplig är att den hjälper till att hålla oss på en övergripande, abstrakt nivå. I den här fasen vill vi inte gå in på detaljnivå. Att diskutera grafiska detaljer, färg, val av gränssnittskomponenter etc leder ofta till att man inte tänker på helheten. En ogenomtänkt helhet leder ofta till ett bristfälligt slutresultat. Dessutom är det enkelt att flytta omkring de olika lapparna för att testa många olika lösningar. Det aktuella systemet bygger mycket på att visa information, och mindre på att användaren ska lösa uppgifter eller problem. Det handlar alltså om att på bästa sätt visa denna information för användaren. Inmatning och andra verktyg förekommer i mindre omfattning. Med post-it-modelleringen kan man förhållandevis snabbt testa olika upplägg för hur informationsvisningen ska vara strukturerad. Här kan vi få svar på hur menyerna ska vara grupperade jämfört med text och bilder, och andra liknande frågor. Navigationskartan innehåller information om hur de olika interaktionsmiljöerna är relaterade till varandra. Med användningsfallen som grund byggs denna upp. In-flight-systemets navigationskarta kan tänkas visa hur man når undermenyerna för väderinformation, val av film och så vidare från huvudmenyn. Navigationskartan kan användas för att undersöka om användningsfallen sträcker sig över onödigt många interaktionsmiljöer, vilket inte är önskvärt i vårt system. Vidare kan vi ha nytta av navigationskartan vid dokumentation av det färdiga systemet. Till exempel kan hjälpfoldrar placeras i stolssätena där navigationskartan, kompletterad med bilder från det slutliga gränssnittet, ger användarna en överblick över hur systemet och dess möjligheter. Vi väljer att ta fram navigationskartan parallellt med interaktionsmiljöerna för att så snart som möjligt få överblick över In-flight-systemet. Dessa får sedan genomgå ett antal revisioner när vi stämmer av den mot användningsfallen. Som tidigare sagts är det önskvärt att användningsfallen sträcker sig över få interaktionsmiljöer. Hur mycket ska vi ta hjälp av användarna i denna del av processen? Constantine och Lockwood anser att användarna inte skall involveras alltför mycket i själva gränssnittsdesignen. Det räcker med användardeltagandet i de andra delarna av processen, menar författarna. Vi vill i detta skede ändå ta med dem. Speciellt modellerna av interaktionsmiljöerna kan vara intressanta att diskutera med olika typer av användare: resenärer med varierande språkkunskaper, från olika kulturer och med skiftande vana från liknande system. Dessutom kan nyckelpersoner från flygbolaget, t ex informatörer och besättningspersonal, involveras. Varför vill vi då involvera olika typer av användare under innehållsmodellelleringen? In-flightsystemet visar, som tidigare nämnts, enbart olika typer av information. Någon djupare behandling eller manipulation av denna information sker inte. Själva informationsvisningen är alltså central i detta sammanhang. Därför anser vi att användarna ska ges möjlighet att tycka till om hur själva gränssnittet för informationsvisningen ska vara uppbyggt. I de traditionella användningscentrerade synsättet tas användarnas synpunkter tillvara under roll- och uppgiftsmodelleringen. Dessa täcker dock inte upp gränssnittsmodelleringen. 8

Implementationsmodellering: Detaljerad visuell design & flödesdiagram I denna aktivitet utvecklas den detaljerade gränssnittsdesignen (implementationsmodellen) för den aktuella delen av systemet. Vid utvecklingen av enklare system kan man tänka sig att utvecklarna går direkt från de abstrakta prototyperna till själva programmeringen av systemet. För de flesta programmerare är dock gapet mellan abstrakta prototyper och färdig design för stort, och därför väljer vi att i utvecklingen av In-flight-systemet ha med implementationsmodellen som ett mellansteg. Implementationsmodellen beskriver visuellt hur det färdiga gränssnittet ska se ut och hur det ska fungera. Det är lämpligt att de designers som utförde uppgiftsmodelleringen (dvs. tog fram de essentiella användningsfallen) också utvecklar implementationsmodellen, eftersom de har den bästa förståelsen för användarkraven och hur man bäst uppfyller dessa i praktiken. Förutom skisser över den visuella designen gjorda med papper och penna kommer implementationsmodellen också att bestå av flödesdiagram som beskriver hur gränssnittet beter sig. De dokument (skisser, diagram) som blir resultatet av denna aktivitet kommer i nästa aktivitet att granskas av användarna innan själva implementeringen görs. Användbarhetsinspektion Utan feedback och förbättring kan även den bästa användningscentrerade designen misslyckas. Det viktigaste för att förbättra designen är att lära sig vad som gick fel. En mängd olika tekniker gör det möjligt för utvecklare att identifiera problemen i mjukvara och mjukvarudesign. Vid utvecklingen av In-flight-systemet är Collaborative Usability Inspection lämplig att använda. Denna typ av användbarhetsinspektion involverar användare, mjukvaruutvecklare, domänexperter samt användarbarhetsspecialister. Dessa samarbetar för att utföra en grundlig och effektiv inspektion. En annan stor fördel med denna typ av inspektion är att den går snabbt att genomföra men ger samtidigt ett bra resultat. Man måste under hela inspektionen komma ihåg att upptäckandet av brister i systemet är tecken på en lyckad inspektion och inte tecken på en misslyckad utvecklingsprocess. De brister som upptäcks under användbarhetsinspektionen kan fortfarande rättas till. Kritik ska riktas mot den blivande produkten och inte mot utvecklarna som utvecklat den. 9

Vad kan göras bättre? Constantine och Lockwood betraktar innehållsmodelleringen som en del i processen där användarinvolvering inte är nödvändig. De anser att den involvering av användare som sker i de inledande faserna av processen (roll- och uppgiftsmodelleringen) är tillräcklig. Vi håller inte helt med om detta påstående, speciellt inte i processen för In-flight-systemet. Visserligen saknar många användare kunskaper i gränssnittsdesign, men synpunkterna kan ändå vara väl värda att ta tillvara. Att få dessa synpunkter i användbarhetsinspektionen är onödigt sent. Som vi förstår ingår role model i task model enligt aktivitetsmodellen. Vi anser däremot att role model borde vara en egen aktivitet i processen då detta är en av grundstenarna i användningscentrerad design. Boken är lite otydlig på denna punkt. Användningscentrerad systemutveckling förespråkar till skillnad från många andra synsätt inte iterationer över hela processen. Detta innebär att det är viktigt att göra rätt från början. De olika modellerna är verktygen som används för att göra rätt från början. Om verktygen används på rätt sätt leder det till ett bra resultat, men vad händer om roll- eller uppgiftsmodelleringen missar viktiga delar? Avsaknad av iterationer över hela processen försvårar i detta fall. Förhoppningsvis hamnar man, tack vare skickliga användbarhetsdesigner och medarbetare, inte i den situationen. 10

Tidsplan Ansvariga för aktiviteter Förstudie Projektledare, användbarhetsdesigners Scenarier Användbarhetsdesigners, användare Användarroller Användbarhetsdesigners, användare Rollkarta - Användbarhetsdesigners Användningsfall Användbarhetsdesigners, användare Användningsfallskarta - Användbarhetsdesigners Interaktionsmiljöer Användbarhetsdesigners, användare Navigationskarta - Användbarhetsdesigners Detaljerad visuell miljö Användbarhetsdesigners, designers, programmerare Flödesdiagram Användbarhetsdesigners, programmerare Användbarhetsinspektion Användbarhetsdesigners, designers, programmerare, användare Utveckling Programmerare, designers Användbarhetsinspektion - Användbarhetsdesigners, designers, programmerare, användare 11

Källor Constantine, Larry L och Lockwood, Lucy A D: Software for Use A Practical Guide to the Models and Methods of Usage-Centered Design, ACM Press, New York 1999 Gulliksen, Jan och Göransson, Bengt: Användarcentrerad systemdesign en process med fokus på användare och användbarhet, Studentlitteratur, Lund 2002 Constantine, Larry L och Lockwood, Lucy A D: Usage-Centered Engineering for Web Applications, 2001, http://www.foruse.com/articles/webapplications.pdf 12