Projektrapport Användarcentrerad Systemdesign Uppsala Universitet sommaren -04

Transkript

1 Grupp 7 Musikdistribution Utifrån Loockwood & Constantine Författare Arvid Karlsson Erik Kjellqvist Sidan 1 av 15

2 Sammanfattning I denna rapport redovisas den modell för användnings-centrerad design som görs gällande i Lockwood & Constantine s Software For Use. Modellen tillämpades sedan på ett problem om musikdistribution i form av en fiktiv projektplan. Utöver exempel på möjliga produkter från denna projektplan som är tillämpad på det aktuella problemet, redovisar även författarna de bakomliggande teorierna för modellen samt en avslutande diskussion kring dessa. Sidan 2 av 15

3 Innehållsförteckning Sammanfattning... 2 Innehållsförteckning Inledning Syfte & Metod Arbetssätt Bakomliggande teori Logiska förhållanden mellan viktiga modeller Aktivitetsmodellen Projektplan Projektmål & Projektbeskrivning Resurser och Rollbeskrivningar Aktiviteter Collaborative Requirements Dialog Domain Modelling Operation Contextualization Object Structure Design Help System and Documentation Standards and Style Definition Task Modelling Interface Content Modelling Implementation Modelling Concentric Construction & Architechtural Iteration Usability Inspection Tidsplan Möjliga Produkter Community Produkter Betaltjänster Diskussion Källor Sidan 3 av 15

4 1 Inledning På kursen Användarcentrerad Systemdesign fick vi möjlighet att välja mellan ett antal olika projekt. Vi fastnade för projektet Musikdistribution eftersom ämnet tilltalade oss mer än de övriga. Till detta projekt fick vi även möjligheten att använda oss av tre olika böcker som tog upp användarcentrerad projektplanering utifrån olika perspektiv. Vi valde det synsätt som Larry L. Constatine och Lucy A.D Lockwood gör gällande i boken Software for use. 1.1 Syfte & Metod Målsättningen var att lära oss mer om hur man bör lägga upp och planera ett användarcentrerat projekt. Resultatet på rapporten är inte att få fram en fungerande produkt utan snarare att presentera en planering på HUR en sådan produkt kan utvecklas med en användningscentrerad design. Projektet är till största delen en litteraturstudie samt ett referat av boken Software for use. 1.2 Arbetssätt Vårt arbetssätt bestod i en litteraturstudie, samt att i möten diskutera med varandra olika tolkningar kring kärnfrågorna i denna bok. Projektplanen är i sin helhet konstruerad efter samma modell som görs gällande där. Sidan 4 av 15

5 2 Bakomliggande teori I detta kapitel redogörs för Lockwood och Constantine s teorier som de beskrivs i Software for use. Boken är i grund och botten en praktisk guide till hur man kan med hjälp av olika metoder och modeller skapa sig Användningscentrerad Design, till skillnad från det traditionella Användarcentrerad Design. Grunden i Lockwood och Contantines teorier går att sammanfatta med två schematiska skisser (se figur 1 och 2): Aktivitetsmodellen Logiska förhållanden mellan viktiga modeller Vi har valt att inte översätta de olika begreppen då vi anser att styrkan i namnen försvinner vid översättning och det finns risk för begreppsförvirring. 2.1 Logiska förhållanden mellan viktiga modeller Detta diagram ska inte följas som ett flödesdiagram, utan snarare som en skiss över hur de olika modellerna förhåller sig till varandra. De två modellerna längst till vänster är de modellerna som behandlar problemdefiniering av olika slag, medan de två längst till höger behandlar design. Man kan även se de tre översta som de tre kärnmodellerna med Task Model placerad i mitten för att understryka dess centrala roll i den användningscentrerade processen. Denna figur är förenklad och åskådliggör inte den flexibilitet som finns i processen. I själva verket är bilden direkt missvisande i det avseendet eftersom flera aktiviteter sker parallellt. C&L har gjort detta diagram för att visa på hur man kan överbrygga svårigheterna att jobba parallellt, och här se hur de olika modellerna förhåller sig till varandra. figur 2. Viktiga modeller & logiska förhållanden Role Model I denna modell så tittar man närmare på vilka typer av användare som ska använda systemet och hur det kommer använda detta. När samtliga User Roles är färdigdefinierade kan man samla ihop dem till en User Role Map för att visa på deras förhållande till varandra. Sidan 5 av 15

6 Task Model I denna aktivitet åskådliggörs en komplett bild av allt som användaren ska kunna utföra i systemet. Detta görs antingen i form av use-cases eller i form av scenarion. Use-cases går även, i likhet med essential requirements, att abstrahera till Essential Use Case models. Content Model Här modelleras det tilltänkta användarinterfacet. Det finns en styrka här att använda sig av så enkla sätt som möjligt, exempelvis post-it-lappar, för att visualisera detta. Detta understryker att det är en utvecklingsbar prototyp och ej en slutgiltig produkt som det rör sig om. Operational Model Här anpassas systemet efter den aktuella användningssituationen/miljön hos de framtida användarna. Genom att denna aktivitet hela tiden ligger parallellt i tiden och överlappar övriga aktiviteter så anpassas de kontinuerligt. Implementation Model Det är här som man tar fram en detaljerad design samt prototyper. 2.2 Aktivitetsmodellen Aktivitetsmodellen är en schematisk skiss över hur arbetet bör forstskrida. Tidsaxeln visar vilka aktiviteter som ska ske och i vilken ordning. Värt att notera är att somliga aktiviteter överlappar varandra, samt att flertalet kan ske/sker parallellt. figur 1. Aktivitetsmodellen Collaborative Requirements Dialog Det här är den första fasen i aktivitetsmodellen som bestämmer hur systemet som ska designas ska se ut. Detta görs bland annat genom olika möten mellan Utvecklare, Användare och Klienter, men även genom olika typer av undersökningar. Viktigt i denna fas är att inse att det hela är en dialog och inte en monolog. För att undvika att kraven låser utvecklarna fast vid en viss typ av implementation kan man använda sig av essential requirements, en slags abstrakt kravspecifikation där alla detaljer om eventuell implementering abstraheras bort för att på så vis fokusera på de primära behoven i designen snarare än detaljer. Det är här även viktigt att alla deltagare känner sig delaktiga och att alla är lika viktiga i processen för att kunna nå målet, för detta krävs en ödmjuk ledare. Sidan 6 av 15

7 Domain Modelling Genom denna modell fastställer man en representation av olika relaterade koncept och konstruktioner. Detta gör i regel i form av ett klassdiagram. Domain modelling skapar terminologin kring systemet och dess funktioner, vilket underlättar kommunikationen mellan aktörerna i projektet. Operation Contextualization Detta är samma sak som vi tidigare beskrivit som Content Model i kapitel 2.1. Object Structure Design Denna aktivitet presenteras inte i boken, men namnet och placeringen i diagrammet antyder att rör sig om någon typ av UML-diagram som representerar arv- och klass hierarkier för utvecklarna. Help System and Documentation Detta är något som skrivs kontinuerligt genom hela utvecklingsfasen. På detta sätt får man en färdig manual samt något att göra sina sluttester emot. Standards and Style Definition Precis som tidigare aktiviteter är detta en fas som påverkar övriga faser genom hela arbetet. Här är det viktigt att använda sig av olika typer av färdiga standarder och stildefinitioner som bygger på erfarenhet och inte på tomma spekulationer. En annan viktig del i denna fas är att kritiskt granska befintliga standarder kontinuerligt för att se om de är relevanta att använda sig av. Task Modelling Detta är samma sak som vi tidigare beskrivit som Task Model i kapitel 2.1. Interface Content Modelling Detta är samma sak som vi tidigare beskrivit som Content Model i kapitel 2.1. Implementation Modelling Detta är samma sak som vi tidigare beskrivit som Implementation Model i kapitel 2.1. Concentric Construction & Architechtural Iteration Implemantationsfasen består av två olika aktiviteter, nämligen Concentric Construction och Architechtural Iteration. Concentric Construktion är en process som bygger på att utveckla systemet i lager utifrån Essential Use Case models medan Architechtural Iteration är en metod som går ut gå at upprätthålla en god intern arkitektur för att underlätta att nya lager kan läggas på systemet. Usability Inspection Här försöker utvecklare och eller användarexperter identifiera användbarhetsdefekter. Detta gör med hjälp av en mängd olika tekniker som till exempel Heuristisk utvärdering, Cognitive Walk-throughs, Pluralistic Usability Walk-throughs och Collaborative Usability Inspection. Sidan 7 av 15

8 3 Projektplan 3.1 Projektmål & Projektbeskrivning Vårt uppdrag kom från musikförlaget X som tycker att de börjar sälja för lite skivor. De har därför anlitat oss till att ta fram en plan på hur de skulle kunna få fram en tjänst som låter dagens människor lätt och enkelt köpa musik genom Xs egna distributionskedja. X har som grundidé att de vill utnyttja dagens teknologi kombinerat med smart design för att nå ut och göra det lätt för konsumenterna att köpa musik, samtidigt som det ska vara billigt för X att distribuera den. Då X börjar att känna av dagens dåliga ekonomiläge samt internets frammars, där ungdomar tar hem gratis musik. Därför vill de ha denna produkt färdig inom 6 månader. Vi ser gärna att X ger sin beställning tillsammans med denna rapport till konsultfirman CanIUseIT.now som har duktiga projektledare och designers, och att de i sin tur kan ge implementeringsarbetet till valfri personal, förslagsvis till It-firman UHackIT. 3.2 Resurser och Rollbeskrivningar Följande roller bör ingå i projektet. Användare Beställare Användbarhetsexpert Projektledare Utvecklare Ett antal slutanvändare. Skivbolag X-musik Inc. Konsult från firman CanIUseIT.now Konsult från firman CanIUseIT.now Programmerare från konsultfirman UHackIT 3.3 Aktiviteter I det följande avsnittet pressenteras projektets samtliga aktiviteter efter modellen som beskrivits ovan. Beskrivning : Vad sker i denna fas av process Resultat : Vad kommer denna fas att resultera i. Roller : Vilka aktörer är involverade. Tillämpning : Hur är resultatet tänkt att användas vidare i processen. Anv.involv : Är slutanvändarna involverade, och om de är det, hur? Artefakter : Vilka artefakter resulterar fasen i Collaborative Requirements Dialog Beskrivning : Här kommer ska det till möten mellan klienten, utvecklarna samt användare för att kunna få fram de krav som ligger till grund för produkten. Det är viktigt här att gruppen tar fram ett schema över hur man ska träffas och vad som ska göras emellan dessa möten. Detta schema gäller enbart under denna fas av arbetet. Det gäller att få alla att känna att de är en del av gruppen och att alla strävar efter samma mål. Sidan 8 av 15

9 Resultat : En kravspecifikation, samt en tidig prototyp Roller : Projektledare, Beställare, Utvecklare, Användare Tillämpning : Detta kommer att ge en kravspecifikation samt en prototyp som successivt kommer kontinuerligt vidareutvecklas mot den slutgiltiga produkten. Anv.involv : Användare ska finnas med i gruppen Artefakter : Kravspecifikation, Prototyp, Agenda Domain Modelling Beskrivning : Här bör man göra en marknadsundersökning för att fastställa vilka kunder bolaget X har och under vilka förutsättningar dessa människor skulle kunna tänka sig att använda en liknande produkt. Det gäller även att i denna aktivitet hitta projektets samtliga begränsningar, så som till exempel budget, tidsbrister, teknologiska förutsättningar. Resultat : Projektets tidsplan, user role-maps Roller : Projektledare, Beställare, Användare, Utvecklare Tillämpning : Fastställer ramarna för projektet Anv.involv : Användarna ges enkäter Artefakter : Projektets tidsplan, user role-maps, Klassdiagram över relationerna mellan projektets komponenter Operation Contextualization Beskrivning : Här ska användbarhetsexperten sitta och jobba. Detta sker genom att observera och analysera användarna för att hela tiden kunna förbättra slutresultatet. Hans eller hennes arbete sker parallellt med resterande processer och kommer att påverka de andra processerna. Resultat : User Cards Roller : Användbarhetsexpert. Tillämpning : Gör prototypen mer användarcentrerad. Anv.involv : Saknas Artefakter : Vidareutveckling på Prototypen, User Cards Object Structure Design Beskrivning : Här gör vi ett UML-diagram över klasserna i projektet. Resultat : UML-diagram Roller : Utveckare Tillämpning : Används i programeringsfasen Anv.involv : Saknas Artefakter : UML-diagram Sidan 9 av 15

10 3.3.5 Help System and Documentation Beskrivning : Denna process är i gång hela projektets gång och ska dokumentera allt arbete, samtidigt som man skriver en användarmanual till produkten. Resultat : Förenklar att ta in ny arbetskraft, samt förenklar felsökning. Roller : Användbarhetsexpert, Utvecklare, Projektledare Tillämpning : Manualen testas senare mot slutanvändaren. Anv.involv : Nej Artefakter : Användarmanualer, Utvecklingsdokumentation Standards and Style Definition Beskrivning : Olika standarder ska gås igenom och användas på produkten. Denna process kommer att fastslå båda nya styleguides för produkten samt ser till att styleguides och standarder som beställaren kräver används. Resultat : Gör produkten standardiserad vilket kan underlätta användandet för slutanvändaren Roller : Användbarhetsexpert, Projektledare Tillämpning : Används överallt där standarder och styleguides kan spela roll. Anv.involv : Saknas Artefakter : Styleguides och Standarder Task Modelling Beskrivning : Här gäller det att försöka få till en komplett bild av hur systemet ska funka. Systemets olika funktioner ska skrivas ner som use cases eller essential use cases som sedan går att abstrahera till use case-maps. Resultat : Efter denna fas ser man hur samtlig funktionalitet ser ut. Roller : Projektledare, Beställare, Användare, Utvecklare, Användbarhetsexpert Tillämpning : Detta ger utvecklarna direkta saker att jobba på Anv.involv : De har rätt att tycka till om hur de vill att produkten ska fungera Artefakter : Use Cases, Essential Use Case Models, Use Case-maps Interface Content Modelling Beskrivning : Här träffas de aktuella rollerna för att utveckla användargränssnittet till systemet. Detta sker i vanlig ordning inkrementellt, d.v.s. dellösningar modifieras och förbättras successivt från idéer till konkretiseringar av dessa. Resultat : Resultaten från denna aktivitet skiftar beroende på var i processen aktiviteten befinner sig. I ett inledande skeende kan interfacet beskrivas m.h.a post-it-lappar, skisser på whiteboard och i kollegieblock. Roller : Användbarhetsexpert, Projektledare Tillämpning : Resultatet kommer att användas inom aktiviteten Implementation Modelling. Sidan 10 av 15

11 Anv.involv : Användarna kommer med synpunkter och är aktivt delaktiga i aktiviteten tillsammans med de övriga rollerna. Artefakter : Mock-ups (skisser, post-it-lappar eller dylikt) Implementation Modelling Beskrivning : I denna aktivitet förfinas och realiseras de olika idéerna och mock-upsen från Interface Content Modelling till konkretare prototyper. Resultat : En prototyp av systemets användargränssnitt. Roller : Användbarhetsexpert, Utvecklare, Projektledare Tillämpning : Resultaten kommer att användas i aktiviteten Usability Inspection, samt inom utvecklingen. Anv.involv : Saknas. Artefakter : Prototyp Concentric Construction & Architechtural Iteration Beskrivning : Precis som i Object Structure Design är det utvecklarna som är huvudrollsinnehavare i dessa två aktiviteter. Här gäller det att realisera de klassdiagram som gjorts gällande i Object Structure Diagram till ren kod. Detta görs i lager inom aktiviteten Concentric Construction och modulariseras i Architectureal Iteration. Resultat : Detta producerar och förfinar kod Roller : Utvecklare Tillämpning : Hjälp och dokumentation Anv.involv : Saknas Artefakter : Hjälp och dokumentation Usability Inspection Beskrivning : Denna fas är till för att hitta saker i produkten som inte fungerar eller som fungerar dåligt. Inspektionen kommat att göras två gånger under projektet. Första gången när man tittar närmare på prototypen och andra gången är efter att ha gjort klart den slutliga produkten. Resultat : Detta resulterar i feedback på prototyp eller slutprodukt. Roller : Användbarhetsexpert, Användare Tillämpning : Utvecklarna eller användbarhetsexperten får ändra de saker som man fått backning på. Anv.involv : Användare får tycka till vad de inte tycker är bra. Artefakter : Prototyp Sidan 11 av 15

12 3.4 Tidsplan Nedan följer ett Ganttschema över projektets tidsplanering. För att se vilka roller som är inblandade i de olika aktiviteterna se kapitel 3.3. En vecka motsvarar 40h arbetstid. Sidan 12 av 15

13 4 Möjliga Produkter Vi som författare kan aldrig egentligen veta vad som kommer att komma ut ur detta projekt (se kap.5 Diskussion), därav överskriften möjliga produkter. Vi vill ändå passa på att redovisa de tankar och idéer som väckts hos oss under arbetets gång. Produkterna kommer i första hand att förenkla för kunderna att köpa musik, och i andra hand låta X att sälja mer musik. Eftersom musiken är kodad som mp3 så får X räkna med ett visst svinn, men det är bättre att få en liten bit av marknaden än ingen del alls. Vi antar även att bolaget X inte är ett bolag med egna artister, utan att de köper in färdigproducerat material som de sedan säljer som skivor. 4.1 Community X signade med MSN s community att de ska sälja Xs musik på nätet. Lösningen bildade en plugintjänst till MSN där man kunde ladda ner billig musik och sedan föra över den till Mp3- spelaren. Communityt erbjuder tjänster som visar toplistor, ny musik, betygsättning, recensioner, rekommendationer, diskussionsforum, fanpages med mera. 4.2 Produkter X välde också at ta fram en stationär dator/monter, med den senaste musiken på. Denna kan X placera ut på olika ställen där de kan tänka sig att sälja musik, som tex, flygplatser, folkparker, tågstationer, konserthus mm. Denna produkt kommer att finansiera sig genom reklamintäkter. Montern fungerar genom att man pluggar in sin Mp3-spelare och via en touchdisplay navigerar sig runt bland den musik som är inlagd i den specifika stationen. Vald musik laddas sedan ner i spelaren. De personer som inte har med sig sin mp3-spelare eller som inte kan koppla in den i stationen, har istället möjlighet att ha ett konto på ovanstående community och med hjälp av sin mobiltelefon sms a in användar-id och låt-id / album-id, för att sedan få den skickad till sin community-mailbox som man kan öppna och ladda ner när man kommer hem. På samma sätt kan man även göra reklam och sälja nya skivor via trycksaker som mjölkpaket, affischer, tidningar osv. varhelst id-kod tryckts. 4.3 Betaltjänster Eftersom en stor del av syftet med detta projekt var att bringa in pengar till X så måste de se till att erbjuda en bredd i olika betallösningar, så att inte vissa kunder exkluderas (t.ex. kan man ej kräva att en kund har eget kontokort o.s.v.). Möjliga betaltjänster vore: Via Internet-bank Pay-Pal SMS-avgift Betalsvar (för de som endast äger fast telefon) Kontokort Utöver detta tänker vi oss att man kan köpa crediter, en fiktiv musik-valuta, på tjänsten. Olika låtar kommer sedan att kosta olika många crediter o.s.v. Sidan 13 av 15

14 5 Diskussion Ett problem med detta projekt som vi tidigt stötte på och som riktigt aldrig lämnade oss var att projektbeskrivningen blir så abstrakt att den ej säger något alls om musikdistribution överhuvudtaget, för att inte tala om implementaionsmässiga detaljer. Själva kärnan i Lockwood s tankegångar är i mångt och mycket att abstrahera och befinna sig på det allmänna planet, detta återkommer i beskrivningen av flera olika aktiviteter. Tanken är att processens olika aktiviteter skall vara definierade abstrakta och att de i deras konkreta utföranden kommer att leda fram till en mer och mer detaljrik implementation. Själva huvudsyftet med aktiviteterna är att prova idéer mot varandra och genom utvärdering av olika modeller m.h.a. erfarenhet skapa en produkt. Denna erfarenhet får ej finnas nedskriven i projektbeskrivningen i förväg. Detta är kanske både styrkan och svagheten med Lockwoods arbetssätt. För att arbeta riktigt Usage-centered måste man vara beredd att frigöra sig från konventionella, invanda sätt att tänka och våga släppa in nya, fräscha idéer. Detta kräver att samtliga deltagare är vidsynta och objektiva, att all implementation är baserad på erfarenhet och ej på föreställning o.s.v. Lockwood ger en mängd olika förslag på hur detta enklare skall åskadkommas, genom användning av Essential Use Cases, informella möten et.c. Problemet i praktiken borde ändå vara att det blir svårt att förutsäga dimensionen för ett projekt. Projektbeskrivningen blir så allmän att man i princip kan lämna samma projektbeskrivning till två helt olika projekt (exempelvis Elmätaren ) och man kan ej i förväg ens gissa sig till hur det slutgiltiga resultatet kommer att bli, vilket också gör det svårt att veta tidsåtgång, kostnad och dyl. Om obegränsad tid och budget vore förutsättningen skulle Lockwoods arbetssätt vara idealiskt, men hur ofta är det fallet gällande i praktiken? Vi diskuterade livligt de första träffarna om vilka olika lösningar som skulle kunna vara möjliga för detta projekt, för att sedan inse att det är helt ovesäntligt vad vi tycker. Hela arbetssättet bygger i själva verket på att man skall undersöka hur de olika aktörerna vill ha det och utifrån det leverera, eller för att uttrycka sig i Bert Karlsson terminologi: Det handlar om att ge fölk va fölk vill ha. Det intressanta i det hela är ändå: Vet folk alltid vad folk vill ha? T.ex. kunde en av författarna till denna rapport aldrig veta att han ville ha en microvågsugn innan han faktiskt köpte en och upptäckte hur bra den var. Visserligen ingår det använbarhetsexperter i aktiviteterna, men de styrs ändå väldigt hårt av användarna. Ett annat problem var att boken tog upp väldigt mycket konkreta guidelines för design, något som går stick i stäv med den ovan beskrivna abstraktionspricipen och får resonemanget i boken att kännas lite paradoxalt. Sidan 14 av 15

15 6 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 Sidan 15 av 15