Projektarbete. Uppsala universitet Institutionen för informationsteknologi Användarcentrerad systemdesign 5p, sommaren 2004

Transkript

1 Uppsala universitet Institutionen för informationsteknologi Användarcentrerad systemdesign 5p, sommaren 2004 Grupp 8: Örjan Berglund, Johanna Lambertz, Projektarbete Uppdrag: Musikdistribution Litteratur: Mayhew, D. (1999) The Usability Engineering Lifecycle: A Practitioner's Guide to User Interface Design

2 Innehållsförteckning 1. Inledning Bakgrund The Usability Engineering Lifecycle Projektplanering Requirements Analysis User Profile Contextual Task Analysis Usability Goal Setting Platform Capabilities and Constraints General Design Principles Design/Testing/Development Nivå Work Reengineering Conceptual Model Design Conceptual Model Mock-ups Iterative Conceptual Model Evaluation Nivå Screen Design Standards Screen Design Standards Prototyping Iterative Screen Design Standards Evaluation Style Guide Development Nivå Detailed User Interface Design Iterative Detailed User Interface Design Evaluation Installation User Feedback Slutsats och kommentarer

3 1. Inledning Vår uppgift har varit att beskriva en användarcentrerad utvecklingsprocess för ett nytt musikdistributionsverktyg. En stark anledning för skivbolag att gå ifrån det nu rådande musikdistributionssättet är att det kostar pengar att pressa upp skivor och omslag och ännu mer pengar att transportera dem till olika skivaffärer. Detta skulle helt kunna frångås med hjälp av till exempel en bärbar mediaspelare till vilken dess användare kan ladda ner musik mot en fast summa per sång, för att ta ett enkelt exempel. Då det inte ingår vår uppgift att skapa själva applikationen som ska möjliggöra den nya formen av musikdistribution, är det svårt att säga ens hur den skulle ha kunnat se ut. Utvecklingsprocessen ska utformas utifrån den metod som beskrivs i boken The Usability Engineering Lifecycle av Deborah J. Mayhew. I boken beskriver Mayhew steg för steg hur man kan gå till väga för att genomföra en utvecklingsprocess med fokus på användbarhet. I uppsatsen kommer vi att gå igenom de steg som processen tar upp, samt beskriva hur dessa ska genomföras med tanke på vårt uppdrag, musikdistribution. Vi kommer att beskriva vilka roller som kommer att vara aktiva i de olika stegen, vilka artefakter som som kommer att bli resultatet av de olika stegen, samt vilken input de olika stegen behöver. För varje steg har vi även satt ut en ungefärlig tidsuppskattning. Denna är hämtad ifrån Mayhews uppskattning om omfattningen på de olika stegen. 2. Bakgrund 2.1 The Usability Engineering Lifecycle The Usability Engineering Lifecycle är den användarcentrerade process som Deborah J. Mayhew beskriver i sin bok med samma namn. Mayhew delar in processen i tre delar; Requirement Analysis, Design/Testing/Development och Installation 1. Dessa delar består i sin tur av en rad av olika aktiviteter (se figur 1). Den första delen, Requirements Analysis, har som syfte att skapa en tydlig bild av användarna och deras uppgifter för att detta sedan ska kunna kunna användas för att ställa upp krav för den nya produkten. I detta steg läggs grunden för det fortsatta arbetet och det är viktigt att det görs noggrant. Resultaten från dessa delaktivteter dokumenteras i projektets Style Guide som ska fungerar som underlag för det fortsatta arbetet. Requirements Analysis delas in i fem delmoment: User Profiles går ut på att ta fram information om användarna. Vilka användarkategorier finns representerade och vilka egenskaper, behov och mål har dessa? I Contextual Task Analysis-steget tas en analys och beskrivning av den nuvarande uppgiften, samt användningsmiljön, fram. Detta material ska användas för att ställa upp användbarhetskraven. I Usability Goals-steget sammanställs resultaten från de utförda aktiviteterna genom användbarhetskrav i form av tydliga och konkreta mål för användningen. Platform Capabilities and Constraints ser till att speciella egenskaper och begränsningar i den tekniska miljön som används är kända. Dessa undersöks och dokumenteras. 1 För att det inte ska uppstå svårigheter med att följa med i figur 1 har vi valt att behålla de engelska termerna på momenten. 3

4 I General Design Principles-steget samlas generella användbarhetsdesignprinciper som kan vara relevanta för det specifika projektet. Dessa kommer att användas under designprocessen som följer. Figur 1. En skiss över The Usability Engineering Lifecycle med de olika momenten och nivåerna. 4

5 Nästa fas, Design/Testing/Development, är indelad i tre delar. Den första nivån har fokus på högnivådesign. Organisationen undersöks och förbättringar letas för att optimera införande av systemet. Vidare skapas en bild av den övergripande designen och pappersprototyper skapas och evalueras. Denna del delas upp i fyra steg: I Work Reengineering struktureras användarnas arbetsuppgifter efter uppgiftsanalysen, krav och den organisation de arbetar i. I Conceptual Model Design byggs en användarmodell baserad på samtliga föregående aktiviteters resultat. Conceptual Model Mockups. Här skapas papper-och-penna-prototyper eller andra typer av prototyper. Iterative Conceptual Model Evaluation. Prototyperna utvärderas och modifieras iterativt. Representativa slutanvändare används i utvärderingen där de får utföra representativa uppgifter med minimal träning. Större buggar kan då identifieras och elimineras. På nästa nivå, nivå 2, sätts standarder upp för de de olika delarna av gränssnittet. Genom att göra detta skapas en bra grund för systemet. Prototyper skapas som sedan itereras med tester och utvärdering tills ett tillfredsställande resultat uppnåtts. Nivå 2 består även den av fyra delsteg: Screen Design Standards är en samling av produktspecifika standarder för att få ett konsekvent användargränssnitt. Den baseras på eventuella industristandarder, företagsstandarder och de tidigare aktiviteternas resultat. Screen Design Standards Prototyping. Här appliceras de standarder som specificerats på prototypen. Den design som nu uppkommer implementeras så att proptotypen nu går att använda. I Iterative Screen Design Standards Evaluation utvärderas och testas prototypen från det tidigare delsteget iterativt. Prototypen förändras utifrån de nya resultaten. Style Guide Development. Här dokumenteras resultaten från delaktiviteterna i Style Guiden. I nivå 3 färdigställer man designen baserat på resultatet i de två första nivåerna. Den består av de två delstegen: I Detailed User Interface Design designas en detaljerad version av den kompletta produkten baserat på det som dokumenterats från Conceptual Model och Screen Design Standards i Style Guiden. I Iterative Detailed User Interface Design Evaluation utvärderas och testas produkten. Här fortsätter förfining av gränssnittet samt tester för att se att det uppfyller användbarhetskraven. Den tredje och sista fasen, Installation, består av ett steg: User Feedback. Här samlas återkoppling från användare, efter att produkten tagits i bruk. Denna information kan användas för att producera en bättre nästa version eller helt nya produkter som liknar denna. 5

6 3. Projektplanering 3.1 Requirements Analysis User Profile Det inledande steget i User Profile är att ta reda på vilka som kommer att använda systemet/produkten, dvs. de tänkta slutanvändarna. För detta föreslår Mayhew ett antal tillvägagångssätt som kan användas. Valet av metod är beroende av vilken typ av organisation det handlar om. Hon skriver dock att det bästa man kan göra är att fråga rätt personer (ex. marknadsavdelningen) för att få en lista med tänkta användargrupper. Därefter ska användarna beskrivas i termer av psykologiska karaktärsdrag, kunskap och erfarenheter, jobboch uppgiftskaraktärsdrag och fysiska karaktärsdrag. För att göra detta föreslår Mayhew användning av enkäter och intervjuer. I vissa fall kan man erhålla denna information direkt från marknadsavdelningen. Utifrån dessa data dras sedan slutsatser vad gäller krav på designen och dessa dokumenteras i produktens Style Guide. Även User Profiles för vardera användargrupp dokumenteras. Mayhew anser att den bästa metoden för att samla data om ett nytt systems användare är att utföra enkäter. I andra hand nämner hon intervjuer med sådana som har en stor kunskap om den gällande användargruppen. 1. Bestäm användarkategorier. 2. Bestäm relevanta användarkarakteristika. Om sådana finns, utgå ifrån tidigare existerande frågeformulär och diskutera dem med relevanta projektmedarbetare, samt representativa användare för att samla användarkarakteristika och bestämma vilka av dessa som ska representeras i det kommande frågeformuläret. Då våra tilltänkta användare är konsumenter, bör fokus i enkäten ligga på deras konsumtionsmönster och deras teknikkunnande, samt deras relevans inför ett nytt system för musikdistribution. 3. Utveckla ett utkast till en enkät. Enkäten ska innehålla en introduktion där syfte och fördelar förklaras. 4. Visa enkäten för företagets ledning för att denna ska ha möjlighet att ge synpunkter på och eventuellt godkänna enkäten. 5. Revidera enkäten så den inkorporerar ledningens åsikter, om nödvändigt. 6. Utför en pilotundersökning med intervjuer av ett mindre urval av potentiella enkätbesvarare, gå igenom varje fråga i enkäten och fråga om ordval, ämnestäckning, frågornas lämplighetsgrad och dylikt. Att intervjua två eller tre användare från varje större användargrupp är lämpligt. 7. Revidera enkäten så att den inkorporerar de intervjuades åsikter, om nödvändigt. 8. Gör ett urval av användare. Vanligtvis är svarsprocenten för en postad enkät 10%, enligt Mayhew. Tumregeln är att inte förvänta sig att få tillbaka fler enkäter än 30% av de utskickade. I vårt fall, då våra användare är konsumenter, och vår användarpopulation med all sannolikhet är större än 3000, är det enligt Mayhew bäst att istället skaffa ett sample av ungefär 100 användare från alla större användargrupper. I vårt fall är detta speciellt svårt, då det är mycket svårt att hitta större användargrupper bland musikkonsumenter, om man inte målar med mycket breda drag och sätter till exempel tonåringar som en grupp och så vidare. Det bästa alternativet är förmodligen att skicka ut en generell enkät om musikkonsumtion och sedan dela in de svar som kommer in i grupper efter teknikkunnande i kombination med konsumtionsmönster. 6

7 9. Distribuera enkäterna. Här är det viktigt att göra återförandet av enkäterna så enkelt som möjligt, till exempel är det bra att skicka med ett frankerat och addresserat kuvert med enkäten. Sätt en klar deadline, men uppmana de som missar denna att returnera enkäten närhelst de kan. 10. Designa ett system för databehandling/analys. Använd de redskap som finns tillgängliga, ett statistikprogram, en kalkylator, penna och papper, för att skapa ett slutgiltigt datauppsamlingssystem för enkäterna. Detta system bör kunna hantera användarkommentarer som ligger utanför enkätens frågeställningar. 11. Lägg in data i systemet. 12. Summera data. 13. Analysera data. Det är viktigt att inte på något sätt göra några antaganden eller prioriteringar gällande de olika användarkategorierna i detta skede. 14. Presentera våra resultat för alla som är berörda av dem, främst de som arbetar inom projektet samt företagets ledning. 15. Resultat dokumenteras i produktens Style Guide. En User Interface Designer har huvudansvaret för momentet. En Usability Engineer ska hjälpa till att ta fram de olika användargrupperna, samt att dra slutsatser om designen utifrån de egenskaper dessa grupper har. Användare fungerar som informationskällor till intervjuer och enkäter. Kommentar Mayhew beskriver svårigheten med att hitta rätt användaren för en helt ny produkt. Det är inte säkert att man då känner till vilka slutanvändarna är och det är då omöjligt att få tillgång till representativa användare vilket leder till att det är omöjligt att göra User Profiles. Hon skriver vidare att man kan då behöva vänta tills den första versionen är ute på marknaden för att sedan kunna göra User Profile inför nästa version av produkten. Vidare skriver hon att det bästa man kan göra i sådana situationer är att tillfråga organisationen som är ansvarig för att planera och definiera nya produkter. Denna har troligen definierat potentiella kunder för den nya produkten och på så sätt kan användare hittas. Det är tänkbart att användning av personas skulle passa bra i vårt projekt i och med att det kan vara svårt att hitta användare, men om detta nämns ingenting i litteraturen. Ungefärlig tidsåtgång för detta delsteg : 140 timmar. Användare deltar 84 timmar Contextual Task Analysis Syftet med detta moment är att ta fram en användarcentrerad modell för hur arbetsuppgifterna utförs idag hur användarna tänker, pratar om och utför arbetet i den faktiska arbetsmiljön. Detta görs enligt Mayhew genom att samla information om arbetet som ska automatiseras genom att observera användarna i den verkliga arbetssituationen. Att enbart fråga användarna om hur de utför sina uppgifter ger inga tillförlitliga svar. Den information som samlas in analyseras sedan och en modell över den nuvarande uppgiftsorganisationen kan åstadkommas. Denna modell kan därefter valideras. Modellen dokumenteras i produktens Style Guide och resultatet från detta steg kommer sedan att påverka alla designmoment i processen, samt påverka urvalet av de aspekter av produkten som sedan ska utvärderas och testas. Enligt Mayhew finns det idag ingen vedertagen universell metod för att utföra en Contextual Task Analysis. Hon ser det snarare om en konstart än en vetenskap där varje 7

8 användarcentrerare använder sina egna metoder. Hon delar in sin egen metod i följande principiella delar: - Del 1 : Samla bakgrundsinformation om det arbete som ska automatiseras (steg 1-4) - Del 2 : Samla och analysera data från observationer och/eller intervjuer av verkliga användare som utför arbetet i sin arbetsmiljö (steg 5-8) - Del 3 : Konstruera en modell av en användares arbetsuppgifter (steg 9-11) 1. Gå igenom kravspecifikationer (om sådana finnes). Detta steg blir inte aktuellt i vårt fall, då vi ännu inte har någon färdig kravspecifikation. Vi går direkt vidare till nästa steg. 2. Möt och socialisera med medlemmarna i projektet. 3. Möt användarrepresentanter. Utför intervjuer med användarrepresentanter (dvs chefer, gruppledare, områdesexperter etc.), också detta i syfte att få en heltäckande bild av de moment som ska automatiseras med hjälp av vår slutprodukt. Man ska också utföra intervjuer med indirekta användare. I vårt fall är det naturligtvis just dessa vi i första hand vill kartlägga, då de är de primära nyttjarna av vårt framtida system. Vi lägger därför den största vikten på att intervjua musikköpare, samt områdesexperter, främst statistiker och musikåterförsäljare. Våra intervjuer i kombination med våra User Profiles kommer utgöra en god grundplåt för våra senare intervjuer och eventuella observationer av användare. 4. Identifiera och dokumentera nyckelaktörer och användningsfall. 5. Utför kontextuella observationer/intervjuer. 6. Dokumentera arbetsmiljöanalysen. 7. Konstruera arbetsscenarios. 8. Dokumentera Task Analysis. 9. Identifiera enkla användaruppgifter. 10. Gör ett första utkast till en Current User Task Organization Model. Baserat på kontextuella observationer och intervjuer organiseras användarnas nuvarande uppgifter i en hierarki beroende på hur de logiskt och arbetsflödesmässigt hänger ihop. 11. Skapa en Current User Task Organization Model utifrån resultatet av steg 10. En Usability Engineer leder detta delsteg. User Interface Designers och alla andra medlemmar i projektgruppen ska deltaga i alla delar av detta steg. Användare deltar genom att vara föremål för intervjuer/observationer. De kan också vara aktiva deltagare i ananlysprocessen. Kommentar I vårt fall är det viktigt att man i detta steg tar reda på vilka termer som används inom branchen för att produkten ska vara trovärdig. Även i detta steg kan det vara svårt, med tanke på att vår produkt är helt ny, att finna lämpliga arbetsuppgifter som ska observeras. Det går dock ut på att finna de aktiviteter som kan underlättas för de tänkta slutanvändarna. Ungefärlig tidsåtgång för detta delsteg : 272 timmar. Användare deltar 66 timmar. 8

9 3.1.3 Usability Goal Setting Användbarhetsmål baserade på User Profile, Contextual Task Analysis och generella affärsmässiga mål skapas i detta moment. Alla typer av användare har inte samma typer av mål och det är därför viktigt att skapa mål för vardera användargrupp. Mål kan vara antingen av kvalitativ eller kvantitativ art. De ska rangordnas och dokumenteras i Style Guiden. Målen ska sedan fungera som acceptanskriterier vid utvärderingarna, speciellt i slutskedet av designprocessen. 1. Konsultera resultatet av User Profile. Den User Profile som vi tidigare utarbetat kan innehålla många ledtrådar till användbarhetsmål för vår produkt. Om det till exempel står i vår User Profile att majoriteten av användarna regelbundet använder Microsofts operativsystem Windows, skulle ett mål kunna vara att låta vår applikations gränssnitt följa Windows utseendestandarder så långt det är möjligt. Även andra slutsatser kan dras ur en User Profile; i det fall det skulle visa sig att våra användares kulturella/sociala bakgrunder visar upp en markant divergens, är det viktigt att utforma applikationens gränssnitt så att det är fritt från kulturella antaganden och symboler. 2. Konsultera Contextual Task Analysis. Vår Contextual Task Analysis ger oss information som kan ge oss ledtrådar till användbarhetsmål för applikationen vad gäller den arbetsmiljö i vilken applikationen används. Om den miljö som applikation används i är bullrig och/eller distraherar användaren, bör applikationen ge riklig kontextuell information till användaren så att denna/denne kan återuppta sitt arbete där hon/han blev avbruten. Contextual Text Analysis anger även de viktigaste användningsfallen för applikationen, och med hjälp av dessa kan vi identifiera de arbetsuppgifter på vilka vi ska formulera kvantititiva målsättningar. 3. Utrön affärsmässiga/ekonomiska målsättningar. 4. Identifiera och skissera kvalitativa användbarhetsmålsättningar utifrån vad de föregående stegen resulterat i. 5. Prioritera bland användbarhetsmål. Med hjälp av vår User Profile, Contextual Task Analysis och våra affärsmässiga målsättningar har vi nu ett antal viktiga användbarhetsmål som vi bör sträva efter att tillfredsställa. De ger oss också insikter om hur vi bör prioritera bland målen; det vill säga identifiera vilka av målen som är viktigast för projektets framgång, vilka som är viktiga men inte livsnödvändiga samt vilka som vore trevliga att uppnå men inte nödvändiga för projektets framtid. För att ta ett exempel kan både en User Profile och en Contextual Task Analysis visa på att det är viktigt att applikationen är lätt att lära sig och lätt att använda för olika användargrupper. Då kan det vara så att den ena gruppen är viktigare eller fler till antalet än den andra, vilket gör att bägge kraven tas hänsyn till men blir olikt prioriterade. 6. Formulera kvantitativa användbarhetsmålsättningar. 7. Dokumentera de prioriterade användberhetsmålen. 8. Informera alla berörda parter. 9. Etablera måldata för de kvantitativa målen. En Usability Engineer leder arbetet i detta delsteg. User Interface Designer ska identifiera målen. Även andra medlemmar i projektgruppen inkluderas med fördel i arbetet. Ungefärlig tidsåtgång för detta delsteg : 170 timmar. Användare deltar 46 timmar. 9

10 3.1.4 Platform Capabilities and Constraints Syftet med momentet är att identifiera användargränssnittsrelaterade begränsningar och möjligheter hos bade hård- och mjukvaruplattformar för en produkt. Dessa plattformar bidrar till en mängd begränsningar på användargränssnittsdesignen. Om designerna är medvetna om de möjligheter och begränsningar som plattformarna medför kan de undvika att föreslå designlösningar som varken är genomförbara eller kostnadseffektiva. Exempel på aspekter som kan medföra begränsningar är storleken på displayen, antalet färger som kan användas och sättet att ge produkten input (mus, tangentbord, röst etc.). Mer specifika möjligheter och begränsningar kommer upp i de olika nivåerna av designprocessen. Designerna bör ha ständig kontakt med utvecklarna för att på så sätt försäkra sig om att designen lätt kan implementeras på den tänkta plattformen. Detta delsteg kan genomföras när som helst före Design/Testing/Development-fasen. Det är oberoende av alla de andra stegen i Requirement Analysis. Det material som framkommer ska dock användas i samtliga efterföljande steg som behandlar användargränssnittets design. 1. Identifiera alla relevanta aspekter på alla hård- och mjukvaruplattformar. Detta görs genom intervjuer med teknisk personal. 2. Läs tillgänglig dokumentation om plattformarna för att få bakgrundskunskap och deras möjligheter och begränsningar. 3. Gernomför intervjuer med lämplig teknisk personal för att få mer information om plattformarnas möjligheter och begränsningar. 4. Dokumentera resultaten i produktens Style Guide. 5. Validera plattformarnas dokumenterade möjligheter och begränsningar genom att lämna ut dokumentationen till lämplig teknisk personal och hålla ett möte där den diskuteras. 6. Dokumentationen ändras utifrån vad som framkommit i steg 5. En User Interface Designer leder arbetet. En Usability Engineer kan assistera genom att ta fram redan dokumenterat material, samt hjälpa User Interface Designern att strukturera arbetet och dokumentationen. Teknisk personal behöver konsulteras för att identifiera plattformar som ska användas, samt för att klargöra dess möjligheter och begränsningar. Kommentar Mayhew skriver att om designerna är obekanta med plattformarnas möljigheter och begränsningar bör resultatet dokumenteras i Style Guide, annars kan detta uteslutas. Vi har valt att ta med det i vår beskrivning av tillvägagångssättet, men om kunskaper finns i den projektgrupp som utför projektet tas steg 4-6 bort. Mayhew skriver även att om antalet plattformar i organisationen är litet och designerna är väl bekanta med dem kan hela steget uteslutas ur processen. Ungefärlig tidsåtgång för detta delsteg : 44 timmar. Användare deltar 16 timmar General Design Principles Syftet med detta moment är att hitta och gå igenom generella principer för gränssnittsdesign och guidelines som kan vara användbara under designfasen som följer. Dessa principer ska ses som ett komplement till resultaten från föregående delmoment. Momentet kan genomföras när som helst i den första delen av processen, före Design/Testing/Development-fasen. Till 10

11 skillnad från andra delmoment dokumenteras inte resultatet av detta moment i produktens Style Guide. Delsteget har istället som syfte att göra materialet tillgängligt. 1. Hitta och gå igenom relevanta högnivå Style Guides. 2. Läs Style Guides från tidigare liknande produkter. 3. Hitta andra källor som innehåller generella designprinciper och gör dem tillgängliga för alla designers i de följande designstegen i processen. Huvudansvaret för delsteget har en User Interface Designer. Han/hon ska samla in relevant material, samt ansvara för ett schema och budget för eventuellt involverande av konsulter under designfasen. En Usability Engineer ska hjälpa User Interface Designern med att finna lämpliga källor och konsulter. Kommentar Ett annat sätt som föreslås i litteraturen är att genomföra en kurs för projektgruppen om användargränssnittsdesign i inledningen av designfasen. Detta görs eventuellt som fjärde steg i vårt projekt om vi anser att de personer som ingår i projektet är i behov av en sådan. Ungefärlig tidsåtgång för detta delsteg : 28 timmar. 3.2 Design/Testing/Development Nivå Work Reengineering I det här steget omarbetas de modeller som togs fram i Contextual Task Analysis (3.1.2). Även resultatet från User Profile (3.1.1) liksom de mål som togs fram i Ussability Goal Setting (3.1.3) används i detta steg. Dessa modeller beskriver användarnas arbetsmiljö, uppgifter och organisation. Modellerna ska förändras med hänsyn till tre mål: 1. Realisera den kraft och effektivitet som automatisering möjliggör. 2. Omarbeta arbetet för att mer effektivt uppnå de affärsmässiga målen. 3. Minimera återinlärning genom att använda så mycket som möjligt av användarnas nuvarande kunskap, terminologi etc., och maximera effektiviteten genom att utgå ifrån människans kognitiva begränsningar och möjligheter inom arbetssituationen. Nästa steg är att validera modellerna genom att utvärdera dem med hjälp av användare. De omarbetade modellerna dokumenteras sedan i Style Guiden och resultatet ska ligga till grund för den kommande designstegen i processen. 1. Omarbeta modeller och uppgiftsanalyser från föregående steg genom att analysera modellerna och förändra dem utifrån de tre målen ovan. 2. Validera och förfina modellerna med hjälp av tänkta slutanvändare och representativa användare genom att genomföra en typ av walk-through. Detta för att få reda på att viktiga moment inte missats. 11

12 3. Dokumentera de slutgiltiga modellerna i produktens Style Guide. En User Inderface Designer leder med fördel arbetet. Alla som deltagit i User Profile och Contextual Task Analysis ska deltaga även här. En Usability Engineer ska bistå med direktiv och återkoppling. Användare deltar i valideringen. Kommentar Mayhew skriver att utvärderingssteget eventuellt kan hoppas över, men då vårt uppdrag handlar om en helt ny produkt är det viktigt att detta genomförs för att man ska kunna försäkra sig om att produktens funktioner är logiskt planerade liksom att viktiga funktioner inte har missats. På grund av att produkten är helt ny kan dock problem uppstå när det gäller att finna de moment som ska automatiseras. Detta delsteg är kanske därför mindre viktigt för vårt projekt, men bör dock genomföras. Det är möjligt att det för personer inom musikbranchen finns sysslor som kan underlättas i och med automatisering. Ungefärlig tidsåtgång för detta delsteg : 88 timmar. Användare deltar 18 timmar Conceptual Model Design I Conceptual Model Design sammanställs regler för hur applikationen ska presenteras och hur funktionaliteten ska organiseras. Momentet baseras på Work Reengineerings-steget och använder all insamlad data från Requirements Analysis-fasen. Här begränsas man av de fakta som framkom i Platform Capabilities and Constraints. Resultatet ska användas direkt i de två nästföljande stegen och dokumenteras i produktens Style Guide. 1. Definiera Conceptual Model som antingen produkt- eller processorienterad. 2. Identifiera produkter eller processer. 3. Bestäm presentationsregler för produkterna eller processerna. 4. Skapa regler för fönster. 5. Identifiera större displays. 6. Definiera och skapa navigationsmöljigheter (major navigational pathways). 7. Dokumentera alternativa Conceptual Model Designs i skisser och tydliga anteckningar i produktens Style Guide. En User Interface Designer ska ha den ledande rollen i momentet. Alla projektdeltagare som deltagit i User Profile, Contextual Task Analysis och Work Reengineering ska deltaga i det här steget. Usability Engineer ska också deltaga genom att ge direktiv och återkoppling. Även användare kan deltaga. Kommentar Det är viktigt att tänka på att detta steg är en iterativ process vars resultat kan modifieras, inte bara inom detta och de två nästföljande stegen, utan även senare när man kommer in på mer detaljerad design. Ungefärlig tidsåtgång för detta delsteg : 204 timmar. 12

13 Conceptual Model Mock-ups Detta steg bygger på föregående stegs resultat. Prototyper görs av de alternativa modeller som uppkom i det steget. Resultatet, i form av prototyper, jämförs och utvärderas. Det kan till exempel vara så att vi har två relativt jämbördiga designförslag mellan vilka vi måste välja ett att gå vidare med. På denna nivå är prototyperna mycket enkla, pappersbaserade modeller fungerar utmärkt. 1. Välj funktionalitet som ska göras till en prototyp. 2. Skissera användargränssnittet. 3. Bygg Mock-up antingen som enkla pappersprototyper eller som fungerande implementeringar. En User Interface Designer ska ha den ledande rollen i det här delsteget. Alla projektmedlemmar som deltog i Requirements Analysis-fasen och de i Work Reengineeringsteget och Conceptual Model Design-steget ska deltaga här genom att åstadkomma input och återkoppling. Usability Engineer ska ge direktiv och återkoppling. Om fungerande prototyper planeras ska en kunnig person inom prototyping anställas för att skapa dem. Användare deltar med fördel i designfasen av detta steg. Ungefärlig tidsåtgång för detta delsteg : 80 timmar Iterative Conceptual Model Evaluation I detta steg utförs tester på de Mock-ups som uppkom i föregående steg. Användbarhetskraven från Usability Goal Setting används också. De uppgifter som testas bestäms utifrån Contextual Task Analysis. Generella steg för varje testiteration lyder: - Planera testet och skapa stödmaterial. - Utför testet och samla data i testplanen. - Analysera och tolka dessa data och formulera omdesign, om nödvändigt. Vid slutet av varje test är stegen: - Modifiera Conceptual Model Designs. - Modifiera Conceptual Model Mock-ups. - Modifiera testplanen och stödmaterialet. Det vill säga, vi itererar mellan detta steg och de två föregående tills dess att alla identifierade problem är åtgärdade, och en enda kvarvarande Conceptual Model Design för den specifika uppgiften har kunnat väljas ut. Resultatet används sedan som input i designfasen och dokumenteras i produktens Style Guide. 1. Bestäm vilket som ska vara fokus för testet; lätt-att-lära eller lätt-att-göra. 2. Bestäm fokus för användare och uppgifter. 3. Skapa de uppgifter som ska utgöra testet. 4. Färdigställ testet och testmaterial. 5. Skapa och färdigställ testmiljön. 13

14 6. Rekrytera och schemalägg användare till pilottestet. Dessa ska vara representativa för användarpopulationen, i vårt fall så representativa som möjligt. 7. Utför pilottestet. 8. Revidera testet och/eller testmaterial, om nödvändigt. 9. Rekrytera och schemalägg användare till testet. Dessa ska vara representativa för användarpopulationen, i vårt fall så representativa som möjligt. 10. Genomföra testet och samla in data. 11. Summera data. 12. Analysera och tolka data. 13. Dra slutsatser/formulera designförändringar 14. Dokumentera/presentera resultatet. Ledaren för detta delsteg ska vara en Usability Engineer. User Interface Designern ska assistera vid planeringen och genomförandet av utvärderingen. Andra projektmedlemmar kan deltaga vid behov och alla ska fungera som observerare. I den formella användbarhetstestfasen ska användare deltaga som testanvändare och de kan också ge värdefull input till designen av testfasen. Ungefärlig tidsåtgång för detta delsteg : 144 timmar Nivå Screen Design Standards Detta steg går ut på att försäkra sig om att gränssnittet i applikationen är konsekvent standardiserat. Konsekvens bidrar till att öka enkelheten i både inlärningen av och användandet av en produkt. Dessutom kan standardisering av en applikation bidra till återvinning av programkod och minskad arbetsbörda för designern. Screen Design Standards baseras på tidigare utförda steg, bland andra User Profiles, Contextual Task Analysis och Usability Goal Setting. Resultatet dokumenteras, gärna i form av bilder, i Style Guiden och används i den del av processen där detaljerad design utförs (nivå 3). Exempel på komponenter i ett gränssnitt som bör standardiseras: - Kontrolldon (klickrutor, knappar, listor mm.). - Plats och format för standardkomponenter (titelrad, statusrad, display body etc.). - Terminologi. - Färganvändning. - Typsnitt och mallar. - Interaktion med pekdon och kortkommandon. - Plats, format, sort, frasering för meddelanden och instruktioner. 1. Skissera kontrollstandarder. 2. Skissera standarder för produkt-/processfönster. 3. Skissera standarder för dialogrutor. 4. Skissera standarder för meddelanderutor. 5. Skissera standarder för interaktion med pekdon. 6. Skissera standarder för feedback. 7. Dokumentera alla standarder. Bilddokumentation är att föredra. 14

15 Ledaren för detta steg ska vara User Interface Designer. Alla deltagare från Requirements Analysis, Work Reengineering och Conceptual Model Design ska deltaga även här genom att generera input och återkoppling. Även Usability Engineer ska deltaga genom att ge direktiv och återkoppling. Användare kan deltaga aktivt i designfasen. Ungefärlig tidsåtgång för detta delsteg : 180 timmar Screen Design Standards Prototyping I detta steg byggs enkla prototyper upp av de viktigaste funktionerna i applikationen. Syftet med detta är att få återkoppling på den design som redan gjorts, så designern får reda på saker som måste ändras etc. Prototyperna ska baseras på det som framkommit av Conceptual Model Design, Screen Design Standards samt de generella designprinciperna och begränsas av Platform Constraints. I nästa steg itereras detta steg tills alla stora problem är eliminerade och de kvantitativa målen finns inom räckhåll. 1. Välj ut den funktionalitet som ska bli föremål för en prototyp. Man gör i första hand prototyper av de element anser ha störst vikt för applikationen. 2. Förbered en enkel specifikation. 3. Bygg prototypen av den specifika funktionaliteten. En User Interface Designer ska ta den ledande rollen när det gäller design och specifikation av prototypen. Om man väljer att använda en enkel typ av prototyp (ex pappersprototyp) kan User Interface Designern förbereda denna. Alla medlemmar från Requirements Analysis och Work Reengineering, Conceptual Model Design och Screen Design Standards ska delta genom att ge input och återkoppling på prototypens designspecifikation. Usability Engineer ska delta genom att ge direktiv och återkoppling. En erfaren prototypare ska skapa prototypen om den är av av mer avancerad art. Ungefärlig tidsåtgång för detta delsteg : 152 timmar Iterative Screen Design Standards Evaluation I detta steg vill vi få fram reaktioner på de prototyper vi skapat i de föregående stegen, vilka speglar de designbeslut som tidigare framkommit. Fördelen med att utföra tester redan i detta stadium är att vi inte ännu investerat tid och arbetskraft i att skapa någon slutgiltig version av gränssnittet och inte heller skrivit någon programkod. Därför är det enkelt och billigt att göra ändringar nu, om de skulle behövas, i stället för att i ett senare skede spendera mycket mer resurser på att ändra i vår kod eller vår design. Steget baseras på de två tidigare stegen. Användbarhetskraven används för att formulera lämpliga testuppgifter. När sista itereringen är genomförd dokumenteras Screen Design Standards tillsammans med Conceptual Model Design i produktens Style Guide. Resultatet ska användas senare i Detailed User Interface Design. 1. Bestäm vilket som ska vara fokus för testet; lätt-att-lära eller lätt-att-göra. 2. Bestäm fokus för användare och uppgifter. 15

16 3. Skapa de uppgifter som ska utgöra testet. 4. Färdigställ testet och testmaterial. 5. Skapa och färdigställ testmiljön. 6. Rekrytera och schemalägg användare till pilottestet. Dessa ska vara representativa för användarpopulationen, i vårt fall så representativa som möjligt. 7. Utför pilottestet. 8. Revidera testet och/eller testmaterial, om nödvändigt. 9. Rekrytera och schemalägg användare till testet. Dessa ska vara representativa för användarpopulationen, i vårt fall så representativa som möjligt. 10. Utför testet och samla in data. 11. Summera inkomna data. 12. Analysera och tolka data. 13. Drag slutsatser och formulera eventuella designändringar. 14. Dokumentera och presentera resultaten. Huvudrollen i detta steg tas av vår Usability Engineer. En User Interface Designer ska assistera denna/denne, vilket också andra projektmedarbetare bör göra. Användare deltar i de test som ingår i steget. Ungefärlig tidsåtgång för detta delsteg : 144 timmar Style Guide Development I detta steg är det nu dags att sammanställa och slå ihop alla analyser och produkter som tidigare skapats till en mall för en färdig produkt. Detta är i första hand till för systemutvecklarna i projektet, så att de ska kunna få en färdig bild av det gränssnitt testerna kommit fram till, samt att de ska veta hur detta gränssnitt arbetats fram. Detta steg inleds redan i Requirements Analysis-fasen men stabiliseras först i slutet av nivå 2 i Design/Testing/Development-fasen. Innehållet kan komma att förändras även i resterande delar av utvecklingen och även efter installationsfasen. 1. Dokumentera produkter från alla steg i Requirements Analysis-fasen. 2. Dokumentera vår validerade Conceptual Model Design. 3. Dokumentera våra validerade Screen Design Standards. 4. Delge vår Style Guide till alla berörda parter. 5. Se till att vår Style Guide följs. En User Interface Designer ska leda arbetet i det här momentet. En Usability Engineer kan ha en vägledande roll och andra projektmedlemmar kan deltaga, speciellt de som har varit involverade i Requirements Analysis-fasen. Ungefärlig tidsåtgång för detta delsteg : 256 timmar. 16

17 3.2.3 Nivå Detailed User Interface Design Syftet med detta steg är att definiera och dokumentera applikationens gränssnitt, så att det på alla sätt följer de riktlinjer framkommit i de föregående stegen. Den detaljerade designen genereras direkt från Conceptual Model Design och Screen Design Standards. Resultatet dokumenteras i produktens Style Guide. I nästa steg kommer resultatet att utvärderas utifrån användbarhetsaspekter. I det fall applikationen är baserad på en typisk GUI-plattform, består denna uppgift av följande delar: 1. Färdigställ identifikationen av alla vägar mellan fönster, dialogrutor och meddelanderutor. 2. Färdigställ detaljdesignen av menyraden etc. 3. Färdigställ detaljdesignen av allt innehåll i alla fönster, dialogrutor och meddelanderutor. 4. Färdigställ detaljdesignen av all interaktion med hjälp av olika sätt att ge input. Här beror rollfördelningen i viss mån på projektets komplexitet samt utvecklarnas kompetens och erfarenhet. I de fall projektet är komplext och/eller utvecklarna har liten erfarenhet av att utveckla system direkt efter en Style Guide, ska en User Interface Designer ta ledarrollen i projektet och skapa en Detailed User Interface Design från vilken utvecklarna kan skriva sin kod. Å andra sidan, i de fall då projektet är av mindre art och/eller utveckarna har stor erfarenhet av dylik systemutveckling, kan utvecklarna själva skapa gränssnittet under förutsättning att de står i ständig kommunikation med varandra och en User Interface Designer. En Usability Engineer kan också komma med värdefulla synpunkter. Kommentar Vår applikation måste vara attraktiv och lätthanterlig för en stor mängd människor med olika intressen, bakgrunder och teknikvana. Därför ska vårt gränssnitt dels vara utan funktioner som bedömts onödiga i tidigare steg, dels så fritt som möjligt från religiösa symboler och kulturella antaganden. Ungefärlig tidsåtgång för detta delsteg : 240 timmar Iterative Detailed User Interface Design Evaluation Syftet med detta steg är att ytterligare förfina resultatet från föregående steg och att under utvärderingsfasen utvärdera gränssnittet med användbarhet som fokus. Tidigare steg ska ha tagit hand om de större designlösningarna och här ska bara de sista detaljerna finslipas. 1. Bestäm vilket som ska vara fokus för testet; lätt-att-lära eller lätt-att-göra. 2. Bestäm fokus för användare och uppgifter. 3. Skapa de uppgifter som ska utgöra testet. 4. Färdigställ testet och testmaterial. 5. Skapa och färdigställ testmiljön. 6. Rekrytera och schemalägg användare till pilottestet. Dessa ska vara representativa för användarpopulationen, i vårt fall så representativa som möjligt. 17

18 7. Utför pilottestet. 8. Revidera testet och/eller testmaterial, om nödvändigt. 9. Rekrytera och schemalägg användare till testet. Dessa ska vara representativa för användarpopulationen, i vårt fall så representativa som möjligt. 10. Utför testet och samla in data. 11. Summera inkomna data. 12. Analysera och tolka data. 13. Drag slutsatser och formulera eventuella designändringar. 14. Dokumentera och presentera resultaten. En Usability Engineer ska leda arbetet i detta steg. En User Interface Designer ska deltaga som assistent när det gäller planering och genomförande av utvärderingen. Andra deltagare kan deltaga om det behövs, men samtliga ska observera. Användare ska deltaga som testanvändare i användbarhetstestningen. Kommentar Det svåra med att hitta representativa testanvändare är främst att vår produkt har, åtminstone i teorin, en mycket heterogen användarbas. Testet måste se till att så många som möjligt av våra signifikanta användargrupper representeras, och att det allmänna teknikkunnandet hos testpersonerna tas upp och ventileras. Ungefärlig tidsåtgång för detta delsteg : 144 timmar. 3.3 Installation User Feedback Detta steg genomförs när produkten har kommit ut på marknaden. Vad finns det för mening med att fråga ut användare om vår produkts användbarhet efter det att produkten installerats? Mayhew räknar upp fyra exempel: 1. För att få information som kan vara till nytta för produktens underhåll och eventuella förbättringar. 2. För att få information som kan vara till nytta för framtida versioner av produkten. 3. För att få information som kan vara till nytta för skapandet av liknande produkter som kommer användas av samma eller liknande användargrupper. 4. För att få generell information om användbarhet som kan vara nyttig för framtida projekt inom vår organisation. Mayhew föreslår att antal tillvägagångssätt för att få denna information; enkäter, intervjuer, fokusgrupper, användbarhetstestning och användarstudier. Vi har valt att utföra enkäter för att få information från ett stort antal användare. Här blir de svar man får dock specifika, därför har vi även valt att genomföra fokusgrupper för att på så sätt få mer allmän och bred information från användarna. 18

19 Enkät 1. Utveckla en enkät. Frågorna i enkäten sätts ihop efter det att möten med lämpliga projektmedlemmar har hållits där information om vilka användbarhetsaspekter som bör undersökas samlas in. 2. Utföra en pilotundersökning med enkäten som underlag. Gå igenom varje fråga i enkäten med ett antal testpersoner som får komma med synpunkter på formuleringar och struktur.två eller tre testpersoner per användargrupp är lämpligt. 3. Förbättra enkäten utifrån återkoppling från steg Distribuera enkäten till användare av samtliga användargrupper som framkommit i User Profile. Här är det viktigt att man gör ett representativt urval. 5. Analysera data och sammanfatta svar och kommentarer som inkommit. 6. Dra slutsatser och dokumentera dessa i form av rekommendationer inför fortsatt arbete. Fokusgrupper 1. Bestäm hur fokusgruppsmötet ska vara upplagt; öppet eller styrt. 2. Bestäm hur data ska samlas in, förbered frågor som ska tas upp. 3. Hitta lämpliga personer till fokusgruppen. 4.Genomför mötet med användarna. 5. Analysera data. Sammanfatta kommentarer och resultat från fokusgruppen. 6. Dra slutsatser och dokumentera dessa i form av rekommendationer inför fortsatt arbete. En Usability Engineer har här rollen som ledare. En User Interface Designer ska assistera när det gäller planering och genomförande av utvärderingen. Andra deltagare kan deltaga om det behövs, men samtliga ska observera. Användare deltar som källa för återkoppling. Kommentar Detta är ett extremt viktigt steg för vår produkt. I och med det att vi inte har någon erfarenhet av liknande produkter, samt att vårt användarunderlag är otroligt heterogent, måste vi lägga den största vikt vid de åsikter som genereras kring vår applikation. Ungefärlig tidsåtgång för detta delsteg : 220 timmar. Användare deltar 168 timmar. 19

20 4. Slutsats och kommentarer Mayhew s modell är mycket grundlig och välstrukturerad och har ett tydligt fokus på att konstruera användbara system/produkter. Den är lätt att förstå även om vi kan se svårigheter med att införa den i ett företag som inte arbetat på detta sätt förut. Modellen är väldigt omfattande och innehåller en mängd bra exempel på hur de olika momenten ska/kan genomföras. Den är generell och borde gå att tillämpa på de flesta typer av projekt och kan utan svårighet anpassas till specifika uppgifter. Vidare märks att Mayhew är väl medveten om att alla steg inte passar för alla typer av projekt, organisationer och budgetar och ger då förslag på vilka steg som kan hoppas över eller förenklas. Användarmedverkan i utvecklingsprojekt ses oftast som att plocka in användarrepresentanter i projektgruppen. Detta är naturligtvis en del av det hela, men det är minst lika viktigt att se till att utvecklarna kommer närmare användarna och deras arbetssituation. I Mayhew s modell involveras inte användarna direkt i utvecklingen, förutom när det gäller utvärderingar och tester. Vi hade gärna sett att Mayhew föreslagit mer aktiv användarmedverkan i form av fokusgrupper eller workshops för att på så sätt få mer feedback på prototyper och skisser. För att användarna ska vara positivt inställda till slutprodukten krävs att de får feedback på de synpunkter och förslag som de kommit med, annars kan de lätt känna sig överkörda. Detta saknar vi i Mayhew s modell där användarna inte alls får någon återkoppling under arbetets gång. Modellen förutsätter att användare finns till projektets förfogande. Detta betyder att utvecklarna av en produkt som inte har några omedelbara användare, till exempel den nya musikdistributionstjänst vi sökt beskriva, blir hänvisade till att lita på externa källor, till exempel statistik och enkäter gällande liknande system. Detta gäller fram tills dess att produktens första version släppts, på vilken man kan använda metoden fullt ut. Modellen innehåller väldigt mycket dokumentering. Detta är i och för sig är bra, men är mycket tidskrävande. För att få en bra dokumentation är det viktigt att de som utför den är vana vid att uttrycka sig genom att skriva, det kan annars lätt uppstå missförstånd när utvecklarna sedan läser texterna. Om man lyckas med dokumentationen är denna naturligtvis ovärderlig vid utvecklingen av nästkommande produkter. Vidare är dokumentationen i vissa fall den enda länken mellan användarna och utvecklarna och det kan då tänkas att utvecklarna på grund av tidsbrist eller att de inte förstår dokumentationen missuppfattar det som står skrivet. För att undvika detta vore det lämpligt att utvecklarna hade möjlighet att själva träffa användarna och på så sätt ta reda på deras mål och önskningar (som beskrivits ovan). Installationsfasen innehåller ingen information om hur ett system/en produkt verkligen ska/kan sättas i bruk. Ingenting om hur eventuell utbildning ska genomföras tas upp. Modellen innehåller heller ingenting om själva implementeringen av systemet eller andra delar av utvecklingsprocessen som ligger utanför användbarhetsdesignen. Den borde dock med fördel kunna kombineras med andra utvecklingsprocesser, t.ex. RUP. 20