Projektuppgift ACSD HomeMedia

Transkript

1 UPPSALA UNIVERSITET PROJEKTUPPGIFT Institutionen för Informationsteknologi HT 2006 Användarcentrerad systemdesign, 5 p Robert Kajic Karin Liljefors Ken Lindeberg-Lindvet Johanna Lundhag robert@kajic.com karin.liljefors@gmail.com ken@it.sektionen.se johanna.lundhag@it.uu.se Projektuppgift ACSD HomeMedia Kursansvarig: Jan Gulliksen Institutionen för Informationsteknologi

2 Inledning... 3 Sammanfattning av processen Collaborate Requirements Dialog Role Modeling User Role Maps Task Modeling Use case map Interface Content Modeling Process för att modellera innehållet: papper och Post-its Karta över Navigering mellan Gränssnitt (KNG) Implementation Modeling Usability Inspection Expertutvärdering Användarutvärdering Concentric construction Architectural iteration Usability Test Användbarhetstest i praktiken Operational Contextualization Object structure design Standards and styleguides Help System and Documentation Resultat Tidsplan Diskussion Gulliksens och Göranssons osaliga ande Källförteckning (17)

3 Inledning I kursen Användarcentrerad systemdesign vid Uppsala Universitet har vi studenter fått presenterat för oss olika processer för att bedriva användarcentrerad systemutveckling. Som en del av kursen skulle vi tillämpa en specifik användarcentrerad process på ett projekt. I denna rapport har vi använt en process beskriven i boken Software for Use, Usage-Centered Design av Constantine & Lockwood. Denna process, som vi ger en kort sammanfattning av längre fram, består av ett antal delprocesser. Projektet vi har tillämpat processen på är HomeMedia - Hemmets Mediecentral. HomeMedia ska kunna användas för att spela in filmer, visa filmer, välja tv-program att se en viss tid, redigera privata videofilmer med mera. Vid utvecklingen av en så komplicerad produkt som HomeMedia är det lätt för företag att i första hand fokusera på tekniken och att förbise användarna. Med vår rapport som projektplanering ska denna risk minimeras. Den metod vi har använt i rapporten var att utgå från bokens process och anpassa de olika delstegen till utvecklingen av HomeMedia. I de fall vi har ansett att det inte är lämpligt att tillämpa en viss delprocess eller ett visst innehåll i en delprocess motiverar vi vår ståndpunkt. Upplägget på denna rapport följer det klassiska mönstret med en kort teoribakgrund som följs av utvecklingsprocessen för HomeMedia och slutligen en diskussion om hur användbar Constanine & Lockwoods process är på utvecklingen av HomeMedia. 3(17)

4 Sammanfattning av processen Constantine och Lockwood koncentrerar sin process kring användningscentrerad utveckling. Boken säger själv att den främst inriktar sig mot mjukvaru- och applikationsutveckling för datorer. Eftersom den process som boken beskriver är uppbyggd från en andvändningscentrerad utgångspunkt är det systemets uppgift som kommer i centrum för själva utvecklingsprocessen. Detta resulterar i att även om användarens bästa kommer främst, är det inte alltid nödvändigt att blanda in denna. Processen använder sig däremot av många olika metoder och kompetenser inom användbarhet, men även i viss mån faktiska användare, för att tillfredsställa sina kunder. Constantine och Lockwood bygger sin utvecklingsprocess på 13 olika aktiviteter, vilka visas i figuren nedan. Bilden visar i vilken ordning som de olika aktiviteterna ska utföras och vilka andra aktiviteter som utvecklas parallellt med varandra. Processen börjar med en trio aktiviteter som är till för att skapa grunden till kraven på systemet, dessa aktiviteter är markerade med ett rutmönster. Stjärnorna i figuren visar vilka steg i processen som kommer att utvecklas i samarbete med användarna. De mörkaren fälten representerar några nära kopplade aktiviteter som är del av den större mjukvarudesigns- och utvecklings-processen. Dessa aktiviteter utgör huvudrubrikerna i detta arbete. Figur 1 (källa: Software for Use, Usage-Centered Design av Constantine & Lockwood ) 4(17)

5 1. Collaborate Requirements Dialog Processen börjar med vad som kallas för Collaborate Requirements Dialog. Detta är en fas då någon med kunskap i användningscentrering samtalar med klienter och användare och förhandlar om systemets initiala krav, som alltså är denna delprocess eftersträvade produkt. Den största och främsta gruppen av människor som vi behöver förstå och höra vid en användarcentrerad design är slutanvändarna. Det är faktiskt de som kommer använda och arbeta med systemet. Med detta sagt får vi inte glömma andra eventuella resurser inom organisationen såsom kunden, "managers", experter, utbildare, marknadsansvariga etc. Dessa "andra" användare kan komma med värdefull information men det är även nödvändigt att ta dem i beaktning av "politiska" skäl. Det är till exempel viktigt att vi faktiskt känner och förstår vår kund om vi hoppas få fler uppdrag framöver. 2. Role Modeling Det följande steget i processen är rollmodellering, en modell över de användarroller som behöver stödjas av HomeMedia. I sin enklaste form kan vi representera den här modellen som en lista av användarroller som finns, samt en beskrivning av varje roll i termer av de behov, förväntningar, beteenden och ansvar som karaktäriserar och särskiljer den rollen. Någon från systemutvecklingsteamet med kunskap i användningscentrering bör i ett så tidigt skede som möjligt sätta sig ner med potentiella användare av HomeMedia, med ett syfte att förstå de användningssituationer som behöver stödjas. Kort sagt ska denne lyssna till användarna, skapa enkla modeller av dem, presentera dessa modeller för användarna för att få feedback, vidare förfina modellerna och så vidare. Här följer en mer detaljerad beskrivning av rollmodelleringsprocessen; Vi kan börja med att brainstorma så kallade kandidatroller och ägna oss så lite som möjligt åt diskussion och detaljer. Det spelar ingen roll om dessa roller överlappar med varandra eller till och med i mångt och mycket är identiska, dessa är som sagt endast kandidatroller som senare kommer förfinas och raffineras. De funktioner som HomeMedia ska tillhandahålla kan delas upp i två paket: Basic spela upp musik och filmer, även spela in filmer, planera sin TV-kväll, komma åt bildarkivet. Avancerad redigera filmer, lägga musik på sina filmer. Ett exempel på kandidatroller för fallet HomeMedia kan se ut som följer; NybörjarAnvändare Behöver tydlig information; är rädd att göra fel; använder systemet sällan och då enbart funktioner från basic-paketet; bryr sig inte så mycket om det går långsamt. SporadiskAnvändare Behöver ganska mycket information; har viss vana; förväntar sig liknande beteende av olika funktioner; använder sällan och från basic-paketet. EnstakaTjänstAnvändare Behöver endast information de första gångerna; stor vana av enstaka tjänst; förväntar sig samma beteende; använder allt från sällan till ofta och huvudsakligen från basic-paketet. 5(17)

6 MediumAnvändare Kan behöva information men har oftast stor förståelse för tekniska produkter; har vana; vågar utforska "HomeMedia"; gör en del fel; använder ganska ofta och då mest från basic-paketet men även en del funktioner från det avancerade. AvanceradAnvändare Utforskar på egen hand innan den känner behov av hjälp; har stor vana; gör sällan fel; använder ofta; använder alla tjänster från båda paketen. I nästa steg av rollmodelleringen tittar systemutvecklaren tillsammans med användare igenom kandidatrollerna för att ordna dem, identifiera gemensamma egenskaper, slå ihop roller som visar sig ha mycket liknande egenskaper; helt enkelt generalisera modellen. När upprensningen av kandidatrollerna är klar ska man börja fylla i de kända detaljerna som karaktäriserar behov, förväntningar, beteenden och ansvar hos de destillerade rollerna. I takt med att arbetet fortskrider ska vi försöka koncentrera oss på de egenskaper som speciellt specificerar varje roll. Genom att göra detta kan vi ofta finna att vi har en mer eller mindre likadan roll under flera namn. Genom att vidare eliminera de roller som visar sig redundanta samt att ta bort triviala egenskaper hos rollerna kommer vi att hålla modellen enkel och effektiv. Efter en sista avstämning med användarna av den detaljerade rollmodellen har vi, åtminstone i sin mest enkla och informella form, en färdig rollmodell. Innan vi fortsätter med nästa modelleringsaktivitet måste vi dock identifiera en eller flera så kallade fokalroller. Fokalroller är användarroller som vi anser speciellt viktiga av olika anledningar. De kan till exempel vara betydande ur användargränssnittssynpunkt. Vissa roller är närvarande i de flesta situationer och lämpar sig bra som fokalroller av den anledningen medan andra är mer specialiserade med ändå måste definieras som fokalroller p.g.a. deras särskilda betydelse för systemets funktion. 2.1 User Role Maps Rollmodellen kan inte fånga de relationer som finns mellan de definierade rollerna. För detta ändamål skapar systemutvecklaren så kallade användarrollskartor. En sådan anger hur de olika rollerna hör ihop genom att definiera vem som kommer använda systemet samt hur det kommer användas. För att skapa användarrollskartan använder sig systemutvecklaren av information från rollmodellen och slutanvändarna. I en användarrollskarta kan roller höra ihop via flera olika relationer; likhet, klassifikation och komposition. Användarroller kan vara lika genom att dela egenskaper vad det gäller interaktion, förväntningar eller andra gemensamma egenskaper. En användarroll kan tillhöra samma klass som en annan roll genom att dela vissa egenskaper med en superroll samtidigt som den har vissa specialiserade egenskaper. En mängd roller kan tillsammans utgöra en ny roll, denna relation kallas för komposition (85). 3. Task Modeling I nästa steg beskrivs en modell för representation av det arbete som behöver utföras av dem som använder HomeMedia. Modellen kallas för essentiella användningsfall (egen förkortning; EA) och beskriver interaktionen mellan användaren och systemet i något användningsfall. Systemutvecklaren behöver alltså ha tillgång till användarrollsmodellen för att veta vilka användarroller som behöver stödjas av användningsfallen samt input från slutanvändarna för att få insikt i det arbete som kommer att utföras med hjälp av 6(17)

7 HomeMedia. EA beskriver en förenklad, generaliserad, abstrakt, teknik -och implementationsoberoende avsikt med en interaktion. En EA består av tre saker; en rubrik som beskriver meningen eller avsikten som beskrivs av användningsfallet, en användaravsiktsmodell (user intention model) och systemansvarsmodellen (system responsibility model). Enligt en konvention som härstammar från av Wirfs-Brock placerar vi de två senare komponenterna i användningsfallet som två parallella kolumner. Resultatet blir alltså användarens intentioner/avsikter i den vänstra kolumnen och de förväntningar användaren har på systemet i termer av dess ansvar i den högra. 3.1 Use case map Användningsfall är, på liknande sätt som användarroller, inte oberoende. Man kan dra nytta av att beskriva de relationer som finns användningsfall emellan i en så kallad användningsfallskarta (use case map). Genom att göra detta får vi en bild av strukturen hos det arbete som kommer att stödjas av systemet och dess användningsgränssnitt. Den färdiga användningsfallsmodellen kommer att bestå av en beskrivning för var och en av de essentiella användningsfallen samt en karta som visar de relationer som finns dem emellan. Till de möjliga relationerna hör klassifikation, extension, komposition samt närhet. Man kan använda dessa relationer för att identifiera gemensamma egenskaper hos det stödda arbetet och därmed även förenkla uppgiftsmodellen (task modell). Klassifikation är att då ett användningsfall är en specialiserad version av ett mer generellt användningsfall. Användningen av klassifikation ger oss möjlighet att förenkla användningsfallen så att generella interaktionsmönster separeras från mer specifika sådana varpå de mer generella kan återanvändas istället för att upprepa sig i flera användningsfall. Extension beskriver relationen mellan två användningsfall där det ena beskriver alternativa interaktionsmönster i det första. Extension ger stora möjligheter att förenkla användningsfallsmodellen. Komposition beskriver användningsfall som är sammansatta av två eller fler andra användningsfall. Närhet beskriver att det finns vissa likheter hos användningsfall, ofta kan användningsfall som är relativt nära grupperas ihop. Närhet kan ha en positiv effekt då det har inverkan på den slutgiltiga designen så att liknande eller relaterade saker hamnar nära varandra på användningsgränssnittet och orelaterade saker längre ifrån. Till sist behöver vi identifiera fokala användningsfall. Dessa användningsfall kommer att hamna i fokus och runt vilka användargränssnittet eller delar av det kommer organiseras. Ofta kommer vi att välja de användningsfall som stödjer de fokala användarrollerna till våra fokala användningsfall. Fokala användningsfall fungerar som en grund runt vilka man utformar användargränssnittet. 4. Interface Content Modeling I Interface Content Modeling, översatt till Modellering av Innehållet i Gränssnitten, bestäms vilka verktyg och material som ska tillhandahållas av användargränssnitten i HomeMedia, och hur dessa gränssnitt är länkade till varandra. För att modellera innehållet i gränssnitten används de minimala användningsfallen som input. Det är framförallt designers som arbetar och användarna är inte involverade. En viktig utgångspunkt är att varje användningsfall stöds av ett gränssnitt så att det inte finns ett överflöd av verktyg, material eller information. Ibland om ett användningsfall är mycket komplext kan designerna behöva göra flera gränssnitt som används efter varandra vid utförandet av uppgiften. Eftersom användningsfall bygger på användarroller är det viktigt att användarrollerna är välgjorda och att dessa finns representerade. En användarroll som inte stöds av något användningsfall måste undersökas. Kanske blev rollen felaktigt beskriven från början, eller den kanske är redundant. En annan 7(17)

8 förklaring till bortglömda användarroller är då några användningsfall saknas i uppgiftsanalysen. Om så är fallet borde utvecklarna försöka identifiera dem. Användningsfall som inte associeras med någon användarroll kan vara resultatet av en fantasirik modellbyggare 4.1 Process för att modellera innehållet: papper och Post-its Ett separat papper används för varje gränssnitt och dessa papper ges namn efter vilken funktion som tillhandahålls. För varje gränssnitt funderar designern på vilken information som användaren behöver för att utföra uppgiften som finns beskriven i användningsfallet. Designern skriver namnet på informationen på post-it-lappar, och om nödvändigt ytterligare text, och klistrar upp lappen på pappret. Användarna kanske behöver veta tiden oavsett gränsnitt, och då kan det behövas en egen post-it för en klocka. När informationsbehovet är utrett tittar designern än en gång på användningsfallet för att identifiera de funktioner/operationer som användaren behöver utföra i gränssnittet. Mot varje funktion svarar ett verktyg och det verktyget ges en post-it som klistras på pappret, med namn på vad den gör. Ett verktyg i något av gränssnitten i HomeMedia kommer kanske att vara sök film och en post-it där det står sök film sätts då på pappret. Post-it-lapparna får gärna vara av olika färg och storlek för att underlätta för användarna att skilja på dem i delprocessen Användarinspektion. Som ett tillägg till de verktyg och material som finns beskrivet i det minimala användningsfallet kan designern lägga till valbara verktyg för att underlätta uppgifter och användning. Fördelen med post-its jämfört med utskrivna papper med verktyg, dialogrutor och annat tryckt på papper är att post-its är lätta att flytta runt och därmed ökar kreativiteten och ifrågasättandet av den nuvarande placeringen samt det logiska tänkandet. Dessa papper med post-its är den resulterande artefakten och sparas och används i Implementation Modeling, samt Användbarhetsinspektionen. Constantine & Lockwood uppmanar designern att utefter artefakten göra enkla listor med namnen på innehållet i gränssnittet. En sådan lista är mer överskådlig och formell och är därmed ett bättre sätt att dokumentera gränssnitten på än att spara post-its. Denna textmodell är också bra när projektmedarbetare kommunicerar med kunder. Innehållslistorna kan inlemmas i kravspecifikationen vilket underlättar kravspårning. 4.2 Karta över Navigering mellan Gränssnitt (KNG) Nybörjare föredrar ofta fler men enkla gränssnitt för en svår uppgift, medan den vana användaren ofta föredrar färre men mer komplexa gränssnitt för samma uppgift. Designerna måste därför kompromissa mellan antalet gränssnitt och komplexiteten i dessa. KNG är ett sätt att representera hur olika gränssnitt är länkade. Input till KNG är papperen med postitlapparna som modellerats enligt ovan. På ett papper representeras varje gränssnitt av en rektangel och pilar mellan olika rektanglar visar att gränssnitten är åtkomliga från varandra. Alltför långa kedjor av gränssnitt är en signal om att det borde gå att förenkla för användaren, exempelvis genom att göra fler tillåtna vägar till olika gränssnitt. När den slutgiltiga modelleringen av gränssnitten och KNG är klara ska designern undersöka en sista gång att alla användningsfall kan utföras. Den resulterande artefakten är pappret med rektanglarna och pilarna, KNG, som används i Implementation Modeling. 5. Implementation Modeling Implementationsmodeller, prototyper, är till för att utvärdera det HomeMedia-system som hittills utvecklats. Det är viktigt att skapa prototyper av systemet så att användbarheten kan inspekteras när det ännu är relativt enkelt att ändra på designen. 8(17)

9 Viktigt när designerna utvecklar prototyperna är att de har en bra bild över hur gränssnittet till HomeMedia ska se ut. Det är även viktigt att de vet hur funktionerna som systemet innehåller ska fungera och hur dessa hänger ihop. Informationen hämtas från de kartor och post-it lappar som togs fram i föregående steg, Interface Content Modeling Modellering av Innehållet i Gränssnittet. Resultatet därifrån ska nu visualiseras så att användarna kan få en bild av hur systemet kommer att se ut och testa de beslut som hittills tagits. Användaren kommer dock inte att vara delaktig i detta steg utan inspektion av prototyperna kommer att sparas tills nästa steg, Usability Inspection Användarbarhetsinspektion. Prototyperna som ska visualisera systemet kan göras genom så kallade passiva prototyper, vilket innebär att jobbet med pappersmodeller fortskrider genom att rita bilder över gränssnittet för hand eller på datorn. Ett alternativ till detta är att utveckla aktiva prototyper, vilket innebär att designern börja implementera delar av systemet och låter användarna testa dessa. Den mest användbara tekniken för HomeMedia är att designern använder sig av aktiva prototyper. Dessa prototyper kommer att ge användaren en bättre uppfattning om hur systemet kommer att fungera och det bidrar till att utvecklarna lättare kan förstå hur användaren kommer att interagera med systemet. För att minska risken att överarbeta detta steg är det viktigt att enbart göra en begränsad implementation, vilket innebär att enbart delar av systemet implementeras. Om det inte kommer att vara möjligt att använda aktiva prototyper på grund av till exempel tekniska svårigheter så kan det även fungera bra att använda passiva prototyper. Viktigt att tänka på då är att dessa prototyper kanske inte är tillräckliga för att studera de beteende- och interaktionsproblem som kan förekomma. Det kan därför bli aktuellt att komplettera den informationen med mer information från aktiva prototyper. 6. Usability Inspection Det finns många sätt att göra användbarhetsinspektioner på; expertutvärdering, användarutvärdering, kognitiva genomgångar, multidisciplinär genomgång med mera. De användbarhetsinspektioner som vi tycker passar bäst till HomeMedia är expertutvärdering och användarutvärdering eftersom de är relativt enkla att genomföra i förhållande till projektets omfattning. 6.1 Expertutvärdering Input till expertutvärderingen är den aktiva prototypen producerad i Implementation Modeling. En expert som passar för att utvärdera HomeMedia-artefakten har en bakgrund som användbarhetsingenjör eller användargränssnittsdesigner. När experten utvärderar HomeMedia testar han/hon att göra saker i fel ordning, att göra saker upprepade gånger och att göra fel för att se hur felmeddelanden ser ut. Experten använder inte färdiga scenarios särskilt ofta eftersom han/hon vill undersöka allt i HomeMedia. Artefakten är en lista på användbarhetsproblem och rekommendationer. Fastän expertutvärderingar är ganska dyra är de värda de satsade pengarna eftersom experterna kan gå igenom 30 gränssnitt per dag och upptäcker många användbarhetsproblem. Experter kan antingen göra en allmän utvärdering eller fokusera på hur speciella användargrupper använder produkten. 6.2 Användarutvärdering Input till användarutvärderingen är den passiva prototypen, papperen med Post-its, som blev resultatet av Modellering av Innehållet i Gränssnittet. En användarutvärdering tar ungefär 30 minuter och kräver mycket förberedelse. Alla gränssnitt med alla dialoger, menyer, 9(17)

10 felmeddelanden med mera ska vara förberedda likaså några användningsfall som användaren ska utföra. En av utvecklarna planerar användarutvärderingen och sitter med och ställer båda öppna frågor och ja/nej-frågor till användarna. Exempel på frågor kan vara Vilken dialogruta var svårast att använda? Finns det några ytterliggare funktioner som inte fanns i gränssnittet och som du tycker skulle underlätta uppgiften? Användarna sitter i par och diskuterar tillsammans hur de ska lösa uppgifterna i användningsfallen. Dessutom ska utvecklaren låta användarna kommentera varje interaktion direkt när de möter den, och när utvärderingen är klar ska användarna ge sina övergripande intryck. Lika viktigt som att ställa frågor är att observera hur användarna interagerar med gränssnitten. Under utvärderingen spelar utvecklaren systemet och sköter interaktionen, det vill säga tar fram ett nytt gränssnitt när det riktiga systemet skulle ha gjort så. Artefakten som blir resultatet är de anteckningar som utvecklaren gör angående de problem eller oklarheter som användarna har hittat. När Användbarhetsinspektionen ger ett tillfredställande resultat med eventuella mindre designfel skickas artefakten (anteckningarna) vidare till Concentric Construction och Architectual Iteration. Om utvecklaren vid användbarhetsinspektionen upptäcker stora fel angående exempelvis användningsfall som inte stöds fullt ut får projektet hoppa tillbaka till Implementation Modeling och åtgärda problemen och senare göra nya användbarhetsinspektioner. 7. Concentric construction Denna punkt går ut på att förverkliga det utvecklingsarbete som skett; ut kommer en färdig produkt. Men när det väl blir dags för produkten att bli verklighet är det bra att inte försöka genomföra allt på en gång. Identifiera de viktigaste, mest centrala, funktionerna/delarna i mediecentralen och börja därifrån. Lämpligt kan vara att börja med en enda av alla delprodukter, exempelvis en enkel meny och få detta att fungera. Bygg ett fungerande gränssnitt för CD-spelaren och tillse att mediecentralen kan kommunicera med denna på ett smidigt sätt. Här kommer självklart det i tidigare skeden utvecklade biblioteket av objektklasser och standardmallar till stor nytta. När väl CD-spelaren fungerar kan ytterligare spelare och övriga delar implementeras i systemet. Inget användardeltagande behövs i det här steget, utan det här är främst programmerarnas stora stund. Men när CD-spelaren är klar kan den synas i sömmarna av användbarhetsdesigners som arbetat fram den lösning som nu förverkligas. Fördelen med concentric construction i fallet HomeMedia är att den tillåter att en produkt i taget tillverkas. HomeMedia kommer främst bli en sambandscentral som samordnar olika fristående moduler och varje varv i concentric construction kan ses som påbyggnad av ännu en modul. Det gör det även lätt att utveckla olika avancerade versioner för olika användare, även det tack vare modultänkandet. 8. Architectural iteration När produkten väl utvecklas på kodningsstadiet är det viktigt att fundera på vilka kommande moment eller uppgraderingar som kan tänkas komma. Oreda är programmerarens värsta fiende och förr eller senare, efter några uppgraderingar och tilläggsfunktioner, kommer den krypande. Men det räcker självklart inte att enbart sia inför framtiden för att komma undan oredan, utan det krävs mer handfasta metoder för att behålla ordningen när nya implementationer sker. 10(17)

11 Constantine & Lockwood anser att det är nödvändigt att alltid backa några steg när dessa uppgraderingar kommer, att delvis börja om från början och omformulera syftet med produkten så att dessa nya funktioner är inom ramen för den och inte bara som någon form av utfyllnad runt omkring eller inpressad innanför. Detta bör även tänkas på när mediecentralen utvecklas. När gränssnittet programmeras enligt den koncentriska modellen kommer det även att bli nödvändigt att iterera över arkitekturen varje gång en ny produkt läggs till. När först CD-spelaren utformas finns främst den i tankarna, även om alla ändå räknar med att senare implementera DVD-varianten också. Men när det väl är dags för DVD-spelaren behöver ändå alla backa tillbaka några steg och se till att DVDn får sin naturliga plats i helheten, utan att vara inklämd i ett skal utvecklat för en annan produkt. Det kan krävas att även CD-spelaren ändras; DVD-spelaren behöver kanske fler interaktionsval i sin del och för att lyckas behålla igenkänningsfaktorn mellan de båda, eller liknande kodstruktur, kan det bli nödvändigt att anpassa CDn efter DVDn och inte enbart vice versa. Även detta är främst programmerarnas, men även användbarhetsdesigners, arbetsuppgift och eventuellt är det inte så mycket som produceras, utan mer att existerande produkter modifieras. Architectural iteration känns lämpligt när väl concentric construction används. 9. Usability Test I figur 1 som visar processen för att utveckla HomeMedia finns inte användbarhetstester representerade, utan författarna anser att prototypen av HomeMedia även i slutet av utvecklingen ska genomgå användbarhetsinspektioner. Vi anser att deras åsikt i frågan är mycket präglad av miljön som råder i USA, synen att användbarhetstester inte är bra, medan den rådande inställningen i Skandinavien och även i vår grupp är att användbarhetstester är nödvändiga. Tack vare användbarhetstester av en tidig version av produkten ser företaget hur den fungerar i verkligheten och vilka störningar som finns i miljön där produkten används, produktens prestanda vid hög minnesbelastning med mera. 9.1 Användbarhetstest i praktiken Input till användbarhetstest är en tidig version av HomeMedia. Den som leder testerna är professionell testledare. HomeMedia ska testas i verkligheten och inte i ett laboratorium eftersom laboratoriemiljön kommer att upplevas som alltför konstgjord av de personer som testar produkten. Planeringen av testet är mycket viktig, testledaren måste bestämma sig för vad han/hon vill testa, exempelvis hur lång tid det tar att programmera 3 tv-program, hur många fel som görs när testpersonen vill spela in en dvd, hur lång tid det tar att lägga på en musiksnutt på en privat videofilm, etc. Det som testas måste kvantifieras, exempelvis i tid, antal fel, antal gånger testpersonen tittar i hjälpfiler etc. När testledaren bestämt vad han/hon vill testa samt hur detta ska kvantifieras ska testledaren skriva användningsfall som testpersonerna ska utföra. Testpersonerna måste representera alla användargrupper, och variationen inom användargrupperna gällande ålder, utbildning, kön med mera. För att testledaren bättre ska förstå vad testpersonen tänker och varför han/hon gör vissa saker är det bra om testpersonen tänker högt, exempelvis jag tror att jag kommer åt mina privata videofilmer i menyn Filer. Under hela testet är det bra om testpersonen filmas eftersom det kan vara svårt för testledaren att hinna anteckna all interaktion, men testledaren borde ändå 11(17)

12 anteckna det han/hon hinner eftersom det tar tid att gå igenom en videupptagning. Självklart ska inte testledaren ge ledtrådar till testpersonerna om hur han/hon ska utföra användningsfallen. Efter testerna gör testledaren en sammanfattning och analys av videoinspelningen och sina anteckningar. Sammanfattningen och analysen bildar den resulterande artefakten av denna del av processen. Om analysen visar att produkten är så gott som tillfredställande väljer företaget att påbörja den industriella tillverkningen av HomeMedia. Om analysen visar på flera brister förs en diskussion om hur stora dessa brister är och om det finns pengar och tid att åtgärda bristerna. Om företaget vill åtgärda bristerna skickas analysen bakåt till lämpligt steg beroende på vad som brustit. 10. Operational Contextualization Operational Contextualization innebär att designern ska tänka på att den miljö som användaren sitter i när han använder HomeMedia ska påverka hur systemet designas. Operational Contextualization är inte bara till för att anpassa HomeMedia utifrån användarmiljön utan även för att kunna prioritera användbarhetens objekt och kunna fördela resurserna på de designaspekter som kommer att ha störst påverkan på effektivitet och ett felfritt system. Detta är inte en separat aktivitet utan bör pågå parallellt med andra designaktiviteter. Bäst designresultat ges om fokus i första hand är på vad systemet ska göra och i andra hand på hur omgivningen påverkar utseendet på systemet. Här är det viktigt att utgå ifrån de användarrollar som definierades i steget Domain Modeling (Role Modeling). Användarna i de olika grupperna kommer i olika avseenden att uppfatta systemet på olika sätt och kommer därför att ha olika behov. Resultatet av denna aktivitet kommer att vara till hjälp i utformandet av designbesluten som fattas i Implementation Modeling - Implementeringsmodellering. 12(17)

13 11. Object structure design Object structure design handlar lika mycket om objektorienterad programmering som hur användaren förhåller sig till objekt. Idén med objektorienterad programmering är i grund och botten samma idé som överallt där detta tillämpas; återanvänd kod och skapa en struktur som gör det enkelt att implementera och att greppa. Försök att få koden att i så stor utsträckning som möjligt påminna om den struktur som visas upp mot användaren, men kom då ihåg att det är koden som skall påminna om ett lämpligt gränssnitt och inte vice versa. Men om det inte är möjligt att likna koden efter gränssnittet vill Constantine & Lockwood poängtera att även om den bakomliggande koden inte har objektbaserad struktur är det ändå ytterst lämpligt att gränssnittet är objektifierat ; det är lättare för användaren att förstå ett verktyg och att navigera däri om det mesta presenteras som objekt: kom-ihåg-notiser ser ut som post-it-lappar och så vidare. Bygg upp ett kodbibliotek under hela projektet som är till nytta för den slutgiltiga utvecklingen och allra helst ett som strukturellt påminner om det som syns ut mot användaren. Objektorienteringen får dock inte gå till överdrift: Constantine & Lockwood nämner själva att även om användaren tänker i objektbanor tänker hon aldrig i banor om att hon skriver och flyttar runt post-it-lappar eller liknande. Vad hon gör är påminnelsenotiser som i sin tur tjänar ett högre syfte som till exempel att ringa ett samtal. Arbetet är i slutändan ett beteendemönster, operationer, och inte en hög objekt. Objekten skall bara vara ett stöd för att förenkla och tydliggöra arbetet, de kommer aldrig att utgöra själva syftet. Allt detta innebär att det går att skapa en hel del klasser långt innan det färdiga resultatet är avgjort, eftersom den objektorienterade programmeringen främst skall hjälpa programmerarna att strukturera sitt arbete. Det gör även att den slutgiltiga produkten kan innehålla många olika sätt för att göra samma arbete. En parallell kan dras till en ordbehandlare där ett nytt objekt kan skapas genom att klicka på rätt knapp, klicka på Arkiv->Nytt eller t.o.m. trycka Ctrl+N; samma handling kan nås på flera olika sätt utan att det kostar mer för utvecklarna. Den objektbetonade strukturen på gränssnittet gör sig bäst i att försöka skilja på de olika delarna av mediecentralen. CD- respektive MP3-spelarna kan påminna om varandra, om de inte till och med är samma, och DVD-spelaren kan, även om den är ett särskilt objekt i mediecentralen, påminna om ljuduppspelaren. När objektbiblioteket fylls ut behöver ingen användare vara närvarande och resultatet av arbetet blir kort och gott färdiga klasser åt programmerarna att använda sig av när gränssnittet väl förverkligas i concentric construction och architectural iteration. 12. Standards and styleguides För att skapa en igenkänningsfaktor är det lämpligt att det finns standarder och riktlinjer för hur en serie av in- och utgångsvärden ska se ut. Standarder och riktlinjer skall användas, men skall inte uppfattas som något statiskt, orubbligt. Tillåt standarder att utvecklas, men tillse att detta sker kontrollerat eftersom det annars kan resultera i en allmänt icke standardiserad standard. Utvecklingen av standarder bör vara ett nära samarbete mellan användbarhetsdesigners, utvecklare och med inblandning av användarna själva. 13(17)

14 Skriv noggranna standarder från början och gå på en gång igenom dem för att se hur de kan göras lättbegripliga för utvecklarna som kommer att beröras av dem. Det är lämpligt att utgå från existerande standarder och konventioner; play-knappen bör vara en triangel osv. I övrigt är egentligen inte utvecklingen av standarder ett särskilt moment i arbetet, utan skall vara en del av alla övriga kringliggande moment; något som skall finnas med i bakhuvudet under hela utvecklingsprocessen. Parallellt med exempelvis den objektorienterade designprocessen bör standarder sättas för de olika objekten. Det som faktiskt produceras är för det första dokument som behandlar hur dessa standarder och style guides ska användas. Men för att förenkla för utvecklarna är det fördelaktigt om det finns mallar för hur de implementeras i koden (eller vad det nu handlar om): XML-filer, klasser att anropa eller dylikt. Prova alla standarder på användare såväl som de som i ett senare skede skall använda standarder i utvecklingsprocessen. Test av standarder skall undersöka conformity, coverage, convenience, consistency samt compliance, översatt till likhet, täckning, bekvämlighet, konsekvens samt hörsammande. - Conformity mäts kvantitativt genom att undersöka om de olika delarna i standarden följer allmänna konventioner. - Coverage undersöker hur heltäckande standarder är. Hur stor andel av frågor från användare och förbättringsförslag kan kopplas till standards? - Convenience är ett lättanvändlighetsindex. Hur enkelt är det att förstå standarden? - Consistency mäter hur konsekvent är standarden. Ser CD-spelaren och DVD-spelaren helt annorlunda ut? - Compliance mäter hur mycket standarden fått genomslagskraft. Används den överhuvudtaget av utvecklarna och används den till det som den var tänkt? Det verkar fördelaktigt att löpande arbeta med standards och style guides. Men beroende på utseendet på HomeMedia kommer det arbetet att bli olika stort. Om det blir en fjärrkontroll eller kanske ett avancerat peka-klicka-gränssnitt kommer olika stora krav ställas på arbetet med standards. 13. Help System and Documentation Denna aktivitet utvecklar hjälpverktygen som ska finnas till systemet, både den manual som kommer att levereras med HomeMedia och den hjälp som kommer att finnas inbyggt i systemet. Hjälpverktyg kräver inte någon direkt användarinblandning utan pågår större delen av processen för att hämta material från de pågående aktiviteterna. Arbetet kommer däremot att vara mest koncentrerad till slutet av projektet eftersom det då kommer att finnas mest korrekt information att bygga dokumentationen på. Om systemet inte utrustas med en anslutning till Internet är det viktigt att det finns en utskriven manual med utförliga användningsfall som följer med HomeMedia. Enligt Constantine & Lockwood ska helst professionell kompetens anlitas för att utforma den del av dokumentationen som användaren kommer att komma i kontakt med, i detta fall manualen. Om det ändå beslutas att manualen ska skrivas inom utvecklingsgruppen är det viktigt att använda ett språk som användaren talar och att dokumentationen sammanfattar hela beskrivningen i ingressen, första meningen och i första stycket. Eftersom olika användare har olika behov av hjälp och en van användare ska inte behöva läsa igenom ett helt stycke om det hade räckt med en mening för honom. 14(17)

15 Det är även bra att systemet designas på så sätt att det finns inbyggda hjälpfunktioner, små ledtrådar på vägen som säger vad användaren missat för att kunna gå vidare till nästa steg. Det skulle till exempel kunna vara ett statusfält som meddelar att användaren har glömt att fylla i ett fält för att kunna gå vidare i processen. Boken diskuterar utifrån användningsfall. Det är meningen att användaren utifrån den hjälp som kommer att finnas i manualen och den inbyggda hjälpen ska kunna få svar på följande frågor: Vad är det här? Hur gör jag? Vad bör jag göra? Vad menar du? Berätta mer Påminn mig om Var är? Vad kan jag göra? Dessa är bra att ha som riktlinjer så att för varje funktion skall finnas beskrivningar som ger svar på frågorna/påståendena ovan. 15(17)

16 14. Resultat HomeMedia är en produkt som kan kommunicera med olika elektronisk utrustning i hemmet, främst på multimedia-sidan. Den sammanlänkar datorns varierande filer, DVD-spelare, TV, stereo med mera. Med hjälp av passande gränssnitt kan användaren därefter navigera runt och få åtkomst till det eftersökta objektet för att spela upp på önskat medium. Gränssnittet kan vara allt från en häftig fjärrkontroll till en egen central peka-tryck-skärm. Visuell åtkomst till centralen skulle även kunna ske, där det är möjligt, via de olika komponenternas egna skärmar: åtkomst till datorns katalogträd via TV för att visa bilder och filmer, bläddra bland låtar via stereon eller varför inte sitta vid datorn och spela upp låtar från winamp på stereon? Vilket sorts gränssnitt som väljs lämnas åt de första stegen i utvecklingsprocessen att avgöra. 15. Tidsplan Constantine & Lockwood nämner över huvud taget ingenting om hur lång tid en processfas kan tänkas ta, inte ens i förhållande till varandra. Den tidsplan som här presenteras kommer med största sannolikhet att vara alldeles för optimistisk vad gäller antalet dagar per moment. Däremot hoppas vi att den kan spegla hur mycket arbete som varje del kräver i jämförelse med de andra delarna. Den grundläggande tanken som vi utgått ifrån är åtminstone att det användningscentrerade arbetet får lika mycket utrymme i utvecklingen som själva kodningen. Tidsplan i mandagar Collaborate Requirements Dialog Role Modeling Task Modeling Interface Content Modeling Implementation Modeling Usability Inspection Concentric Construction Architectual Iteration Usability Test Operational Contextualization Object structure design Standards and styleguides Help System and Documentation Summa 2 dagar 14 dagar 14 dagar 10 dagar 12 dagar 6 dagar 16 dagar 16 dagar 6 dagar 5 dagar 16 dagar 14 dagar 5 dagar 136 dagar 16. Diskussion Under genomförandet av denna rapport har vi insett hur svårt det är att utveckla ett system på ett användarcentrerat sätt. Alla medarbetare i ett tänkt HomeMedia projekt måste hela tiden ha användarna i åtanke även om användarna inte medverkar i alla delprocesser. Boken Software for Use har sin styrka i de detaljerade delprocesserna med många exempel och råd. Men precis som vi redogörde för i början av denna rapport är boken främst inriktad på mjukvaruutveckling för datorer. Eftersom HomeMedia är en produkt som inte nödvändigtvis är ett program i en dator har vi anpassat processen i boken men vi tror att det finns åtskilliga andra processer som skulle vara bättre för vårt projekt. Om det någon gång i framtiden är ett företag som vill utveckla en produkt som HomeMedia hoppas vi att de kommer att ha hjälp av planeringen i vår rapport, men vi anser som sagt att en annan process skulle vara mer passande. 16(17)

17 17. Gulliksens och Göranssons osaliga ande I mångt och mycket påminner Constantine & Lockwoods användningscentrerade inställning om den användarcentrerade filosofi som Gulliksen & Göransson mässar. Så är fallet åtminstone vid en första genomläsning. Många delar verkar snarlika: metoder, iteration, inställning (kom ihåg vem som egentligen skall använda produkten) och så vidare. Men vid en mer noggrann läsning är det lätt att hitta många ganska stora skillnader som påvisar skillnaden mellan användningscentrering och användarcentrering. För även om Constantine & Lockwood vill att slutanvändarna skall vara nöjda är de restriktiva i frågan att blanda in dem i själva utvecklingen. De lovordar den skandinaviska modellen, de uppmuntrar läsaren att blanda in användare och de markerar flera processfaser där detta ska ske. Men i förklaringen av dessa faser får användaren mycket lite plats och i många fall verkar det snarare handla om en användbarhetsexpert som skall utföra testen, inte riktiga användare. Därav beskriver de, precis som bokens titel faktiskt säger, hur användningen skall stå i centrum användarna själva kommer i andra hand. Förordet anmärker på att boken främst riktar sig till utvecklare av datorprogram för professionella användare, vilket märks tydligt. Denna inställning gör att författarna ofta förväntar sig att kunden, dvs köparen av verktyget, antingen är slutanvändaren själv eller kanske snarare slutanvändarens chef. Så kan antagligen ofta vara fallet, men begränsar ändå författarnas värderingar till att ibland nästan vara politiska : vi måste kanske göra avsteg från slutanvändarens bästa för att istället göra chefen nöjd. Till deras försvar diskuterar Constantine & Lockwood även att det viktigaste är att göra vad kunden behöver, vilket inte alltid är vad kunden vill. Något som verkar oklart i bokens metoder är tidsaspekten per moment i förhållande till varandra samt hur iterationerna skall gå till. Att utvecklingsprocessen kan vara iterativ nämns på flertalet ställen, men den beskrivs aldrig. Inte heller det återkommande diagrammet över processen visar någon vidare iteration med sin tidslinjära axel. Alla dessa saker är något som Gulliksen & Göransson klarar med bravur, galans och fingertoppskänsla :P Summa summarum är att ur Gulliksens & Göranssons synvinkel gör Constantine & Lockwood ett bra försök, men att de inte orkar riktigt ända fram. 18. Källförteckning Software for Use - A Practical Guide to the Models and Methods of Usage-Centered Design av L. Constantine & L. Lockwood, Addison-Wesley, 1999 Användarcentrerad systemdesign av Jan Gulliksen och Bengt Göransson, Studentlitteratur, (17)