Eva Ericsson, ever@stp.ling.uu.se Jens Moberg, jemo@stp.ling.uu.se Peter Strömbäck, dino@stp.ling.uu.se Pensionsplanering Beskrivning, planering och diskussion av ett projekt baserat på användbarhet 1
Innehållsförteckning 1. Inledning...3 1.1 Introduktion till utvecklingsprocessen...3 1.2 Uppgiftsbeskrivning...3 2. The Usability Engineering lifecycle...5 2.1 Requirements Analysis...5 2.2 Design/Testing/Development...5 2.3 Installation...7 3. Beskrivning av ett system för pensionsplanering utifrån Mayhews användbarhetscykel...7 3.1 Requirements Analysis...7 3.1.1 User Profile...7 3.1.2 Contextual Task Analysis...10 3.1.3 Usability Goal Settings...11 3.1.4 Platform Capabilities/Constraints...11 3.1.5 General Design Principles...13 3.2 Design/Testing/Development...13 3.2.1 Nivå 1...13 3.2.1.1 Work Reengineering...13 3.2.1.2 Conceptual Model Design...14 3.2.1.3 Conceptual Model Mockups...15 3.2.1.4 Iterative Conceptual Model Evaluation...16 3.2.2 Nivå 2...16 3.2.2.1 Screen Design Standards...16 3.2.2.2 Screen Design Standards Prototyping...17 3.2.2.3 Iterative Screen Design Standards Evaluation...18 3.2.3 Nivå 3...19 3.2.3.1 Detailed user interface design (DUID)...19 3.2.3.2 Iterative DUID Evaluation...19 3.3 Installation...20 3.3.1 User Feedback...21 4. För och nackdelar med Mayhews metod...22 5. Källförteckning...22 2
1. Inledning 1.1 Introduktion till utvecklingsprocessen Vi har valt att använda oss av den utvecklingsprocess som tagits fram av Deborah J. Mayhew och som beskrivs i hennes verk The Usability Engineering Lifecycle (1999). Målet med processen är att användbarhet med användargränssnitt. En översikt över processen finns på nästa sida. Metoden i sig kan enklast beskrivas i tre huvuddelar: 1. Requirements Analysis 2. Design/Testing/Developement (delas upp i tre nivåer: nivå 1, 2 och 3) 3. Installation Varje huvuddel består av flera delmoment med konkreta uppgifter, vilka beskrivs kortfattat i kapitel två, The Usability Engineering lifecycle, och mer ingående i kapitel tre, Beskrivning av processen utifrån Mayhews användbarhetscykel. 1. 2 Uppgiftsbeskrivning Med hjälp av Mayhews cykel tar vi fram ett förslag till ett projekt som beräknar användarens framtida pension. Den första delen av vår sammanställning innehåller en beskrivning av bokens olika delar. Därefter går vi vidare och beskriver, med utgångspunkt från boken, hur vi skulle genomföra projektet om vi fick det uppdraget. Beskrivningen är ett mellanting mellan en beskrivning av ett konkret projekt och en beskrivning av ett allmänt användarcentrerat projekt. Där det är möjligt anpassar vi oss efter det tänkta pensionsplaneringsprojektet. Efter att ha skaffat oss insikt i Mayhews process listar vi de för och nackdelar vi anser att tillvägagångssättet har. Dessutom anger vi våra personliga synpunkter för varje steg i processen. 3
4
2 The Usability Engineering lifecycle 2.1 Requirements Analysis 2.1.1 User Profile Med detta steg vill man göra en beskrivning över de potentiella användarna av aktuellt system. Detta görs genom att man kartlägger vilka särdrag olika användargrupper har. Tekniker för att göra detta är dels genom enkäter och intervjuer med nuvarande användare, dels intervjuer med personer med kunskap om dessa användare. 2.1.2 Contextual Task Analysis Här studerar man användarnas nuvarande uppgifter och strategier för att lösa dessa. Detta görs genom intervjuer och observationer, och resulterar i en dokumentation som beskriver detta, vilken används senare i processen. 2.1.3 Usability Goal Settings Här specificerar man vilka kvalitativa och kvantitativa användbarhetsmålen. De kvalitativa målen arbetar man fram utifrån resultaten från momenten User Profile och Contextual Task Analysis, och med de kvantitativa definierar man målen för användartillfredställelse. Dessa mål kommer att vara drivande för designprocessen. 2.1.4 Platform Capabilities/Constraints Målet med detta moment är att identifiera och dokumentera gränssnittets möjligheter och begränsningar, utifrån den tekniska platform som ligger till grund för produkten. Detta är viktigt att fastställa redan nu för att underlätta designarbetet i senare faser. 2.1.5 General Design Principles Detta moment går ut på att samla in och sammanställa vilka relevanta riktlinjer och åsikter som finns gällande designen av användargränssnittet, ur olika synvinklar och perspektiv. Denna del ska liksom de tidigare vara drivande i det kommande designarbetet. De uppgifter man har fått fram från denna fas, Requirements Analysis, sammanfattas och dokumenteras i en Style Guide, vilken ligger till grund för och kan konsulteras i den fortsatta utvecklingen av användargränssnittet. 2.2 Design/Testing/Development Denna del av processen är indelad i tre nivåer. Den första nivån består av följande fyra delmoment. 2.2.1 Nivå 1 2.2.1.1 Work reengineering Ombearbetning av den aktuella användarmodellen med användarfall för uppnå automatisering och för att effektivt stödja affärsmässiga mål. Samtidigt ska omträning 5
minimeras genom att använda så mycket som möjligt av användarnas existerande kunskap, och produktiviteten maximeras genom att hänsyn tas till kognitiva mänskliga begränsningar. Ingen design av gränssnitt är med i detta steg. Användarmodellen ombearbetas och dokumenteras i en modell som beskriver hur produktens funktionalitet ska organiseras och struktureras. Den omarbetade modellen ska valideras med användare med hjälp av cart sorting technique eller Task Scenario walkthroughs. Produkten man får ut av arbetet är en omarbetad modell. Arbetsmodellen tas ifrån Task Analysis. Den behandlar output från User Profile och Usability goals. Modellen leder vidare till Conceptual Model Design och andra designaspekter. 2.2.1.2 Conceptual model design Etablera och definiera en regelbaserad, hög nivå design som anger tonen för lägre designnivåer. Första steget till en faktisk design tas här, genom att större displayer och sökvägar identifieras. Regler för presentation som mappar till den omarbetade användarmodellen genereras. Designmodellen tar hänsyn till all output från alla steg i Requirements Task Analysis. 2.2.1.3 Conceptual model mock ups Prototyper skapas med papper och penna för hög nivå designidéer, dock inte särskilt detaljerade. 2.2.1.4 Iterative Conceptual Model Evaluation De skapade prototyperna utvärderas och modifieras iterativt genom bland annat användbarhetstester där man låtsas att prototyperna är riktiga användargränssnitt. Detta steg, och de två föregående, upprepas tills alla användbarhetsproblem är identifierade och åtgärdade. 2.2.2 Nivå 2 Den andra nivån i Requirements Analysis består av fyra delmoment. 2.2.2.1 Screen Design Standards Målet med dessa är att säkerställa konsekvens och enkelhet i detaljerad design för alla delar i användargränssnittet. Screen Design Standards baseras på industri och företagsstandard och feedback från de föregående aktiviteterna. 2.2.2.2 Screen Design Standards Prototyping De standarder formulerade i den föregående punkten appliceras nu på en prototyp. Designen implementeras på valda delar av användargränssnittet så att prototypen går att använda. 2.2.2.3 Iterative Screen Design Standards Evaluation Prototypen från föregående steg evalueras och görs om iterativt. 6
2.2.3 Nivå 3 Den tredje nivån i Requirements Analysis består av två delmoment. 2.2.3.1 Detailed user interface design (DUID) Definiera designen baserat på 1.2.1.2 och 1.2.1.3 så att alla delar följer gränssnittsstandarden. Här realiseras bland annat designbeslut och beslut om knappstorlek, typsnitt och färg för gränssnittet. I detta steg sker också länkningen mellan dialogrutor,fönster och liknande. Dokumentation av vad som görs i detta steg kan vara önskvärt om de aktuella applikationerna är avancerade. 2.2.3.2 Iterative DUID Evaluation Detta steg utgår från 1.2.3.1 och förfinar samt utvärderar gränssnittet med hjälp av användbarhetsmål. Fokus ligger på kvantitet och effektivitet. Testerna sker i en iterativ process i vilken de huvudsakliga stegen är: Låt användare köra systemet och samla in data. Analysera och tolka resultatet. Formulera förslag till ändringar baserat på resultatet. Iterationen avbryts när användbarhetsmålen är uppfyllda. 2.3 Installation Detta tredje och sista steg i cykeln är installation av projektet och utvärdering av hur projektet fungerar. 2.3.1 User Feedback Efter att ha installerat produkten genomförs User Feedback för att samla in synpunkter. 3 Beskrivning av processen utifrån Mayhews användbarhetscykel I det här kapitlet applicerar vi Mayhew ideer på vårt tänkta projekt utan att gå in på det faktiska genomförandet av projektet. Varje steg är uppdelat i de aktiviteter som utförs, vilka roller som ansvarar för de olika delarna, samt beräknad tidsåtgång. Uppskattningen av tidsåtgång är baserad på Mayhews siffror men i viss mån anpassade till vårt projekt. 3.1 Requirements Analysis 3.1.1 User Profile Syftet med att göra en User Profile är att identifiera möjliga typer användare av aktuellt system och sedan undersöka vilka egenskaper dessa användartyper har, i form av: psykologiska karaktärsdrag kunskap och erfarenhet fysiska karaktärsdrag vilken karaktär användarens arbete och uppdrag har 7
Med hjälp av insamlad data tar man sedan fram användarprofiler, vilka systemet ska anpassas efter. Man kan tillgodogöra sig denna kunskap genom flertalet tekniken, såsom intervjuer eller enkäter. Resulterande profiler ska sedan vara kärnan i designen av användargränssnittet. 1. Utforma intervjun med frågor relevanta i sammanhanget 2. Leta upp uppgifter om användare av befintliga systemet i statens register 3. Plocka fram ett godtyckligt, representativt snitt av användare ur registret 4. Kontakta användare för bokning av intervjutid 5. Utföra intervjuerna 6. Sammanfatta resultatet av intervjuerna 7. Analysera resultatet 8. Identifiera användargrupper utifrån resultatet 9. Ställa upp användarprofiler, User Profiles, för grupperna Arbetet bör planeras av en expert på området, men kan sedan ledas och samordnas av en projektledare enligt användbarhetsingenjörens direktiv. För att utforma intervjuerna och analysera resultatet behövs en MDI expert, som kan få ut så mycket som möjligt av informationen som kommit fram under intervjuerna och se vilka behov som finns. Själva intervjuerna behöver dock inte utföras av någon expert på området, utan kan utföras av övriga projektmedlemmar. Resultatet av detta steg blir en intervjuform anpassad för just denna typ av undersökning, ett register med alla reella användare, ett register med ett godtyckligt snitt av användare samt ett antal användarprofiler, User Profiles. Då det inte finns tid att intervjua alla användare av det befintliga systemet måste vi för hand plocka ut ett snitt som enligt ovanstående egenskaper är representativt för olika användargrupper. På det sättet hoppas vi kunna täcka in alla behov som en potentiell användare kan ha. De potentiella användare avsystemet som vi har identifierat på den här nivån är följande: Yrkesverksamma medborgare Handläggare på bank/försäkringsbolag Pensionärer Arbetslösa Förtidspensionerade Studenter Yrkesverksamma medborgare Den första kategorin potentiella användare ser vi som den största och viktigaste målgruppen. Dessa användare har, oavsett hur lång tid man har varit yrkesverksam, ett behov av att ta reda på hur den framtida pensionen kommer att se ut. Nedan följer en beskrivning av dessa användares respektive 8
behov. Användargruppen ska kunna se vilka delar deras pension består av. Den typiska yrkesarbetande medborgaren samlar ihop till sin pension på flera sätt: genom ATP poäng, privata pensionsförsäkringar, pension från arbetsgivaren. Användaren ska kunna välja mellan att se de olika delarna var för sig eller se en sammanställning av den beräknade totala pensionen. Det ska gå att se hur en ökning/minskning av respektive del påverkar helheten. Underlag för beräkning av vilken pension vederbörande får vid pensionering vid en viss ålder ska finnas, och kunna tas fram på kundens begäran. Handläggare på bank/försäkringsbolag Den andra kategorin användare behöver också kunna ta del av de olika pensionskällorna,utan att ha tillgång till pensionsspararens privata uppgifter. Dessa uppgifter ska dock vara åtkomliga för den pensionssparandes privata handläggare, med tillstånd från denne. Pensionärer Den typiska medlemmen i den tredje kategorin är före detta yrkesverksamma medborgare som för närvarande får pension utbetalad. Vissa delar av sin pension, som ATP och pension från arbetsgivaren, kan inte längre påverkas utan ligger fast resten av livet. Däremot kan dessa användare fortfarande påverka pensionens storlek genom att modifiera eventuella pensionsförsäkringar. Arbetslösa Kategorin arbetslösa kan bestå av dels ungdomar som ännu inte gjort entre på arbetsmarknaden, dels av medborgare som efter en tid av arbete blivit uppsagda eller sagt upp sig självmant. Medlemmar i den här kategorin har ett behov av att ta reda på hur deras arbetslöshet påverkar deras framtida pension. Förtidspensionerade Gruppen förtidspensionerade kvitterar ut en statlig pension trots att de fortfarande är i yrkesverksam ålder, oftast beroende på sjukdom. Studenter Gruppen studenter är ofta oinformerade om hur längden på deras studier inverkar på pensionsberäkningen. Detta steg bör ta cirka 140 timmar från projektmedlemmarnas sida, och sammanlagt mellan 80 90 timmar av de intervjuade användarnas tid. 9
3.1.2 Contextual Task Analysis Målet med detta steg är att uppnå en användarcentrerad arbetsmodell såsom det för närvarande utförs, och utifrån denna exktrahera vilka användbarhetskrav som finns på systemet. Man ska studera hur användaren i dess faktiska arbetsmiljö, när denna utför sitt arbete. Även här finns ett flertal tekniker såsom kontextuella observationer/intervjuer och formella arbetsmodeller. Av detta steg får man ut en arbetsmiljöanalys, användningsfall, dokument med analys av användningsfall och en modell över hur användarens nuvarande arbetsmiljö ser ut. 1. Användbarhetsingenjören planerar lämpliga uppgifter som användaren ska utföra. Exempel på sådana kan vara ta reda på aktuell pensionspoäng, ta reda på när nästa utbetalning sker, osv. 2. I samband med intervjuerna som utförs för att fastställa användarprofiler, kommer vi att be användarna att utföra arbetsuppgifterna i det befintliga systemet, såsom att ringa till aktuell myndighet och utföra uppdraget. 3. Arbetet övervakas och anteckingar förs. 4. Anteckningarna sammanställs och dokumenteras. 5. Resultatet analyseras och formuleras i följande former: 1. Arbetsmiljöanalys (ex. i hemmet) 2. Användningsfall (ex. ta reda på pensionspoäng) 3. Analys av användningsfall (vad som fungerar bra/dåligt och varför) 6. Modell över användarens arbetsmiljö. I förhand tror vi inte att dessa miljöer inte kommer att vara heterogena, då uppgifterna ofta utförs i hemmet, och arbetsmiljön där varierar stort från fall till fall. En användbarhetsingenjör kommer att leda detta moment. Övriga projektmedlemmar sköter observationen av användaren, och anteckningar från detta lämnas till ingenjören. Denna studerar sammanställer och analyserar anteckningarna. Tanken med detta är att fånga upp det som inte går att fånga upp vid intervjuerna, det kontextuella. Därför kan man inte grunda den här delen på det man kommit fram till vid utarbetandet av User Profiles, utan snarare det man inte kommit fram till. Däremot behöver man veta vilka användarprofiler som ska studeras, och för detta behövs resultatet från förra steget. Alla frågeställningar man redan har bör klaras av i steget innan, och med det här steget ska man försöka identifiera vilka egenskaper arbetsrutinen har i praktiken. I detta steg är det alltså extra viktigt att vara lyhörd. Vi räknar med att momentet kan klaras av på c:a 230 timmar. Av användarna krävs mellan 60 och 70 timmar, exklusive restid, då vi utför observationerna i samband med intervjuerna i förra momentet. 10
3.1.3 Usability Goal Settings Med detta steg vill man etablera specifika kvalitativa och kvantitativa användbarhetsmål som driver designen av systemet. Detta görs genom att man extraherar de kvalitativa målen från tidigare användningsfall och från generella, affärsmässiga mål, och kvantifierar mål med hög prioritet. Dessa ska sedan användas för att testa användbarhet som kriterium för vad som anses som accepterbart. Tekniker för att göra detta är bl.a. att extrahera mål från User Profile steget och Contextual Task Analysis steget. Resultatet blir två dokument, ett med kvalitativa mål och ett med kvantitativa mål. Detta integreras med resten av processen i och med att målen härleds direkt från stegen User Profile och Contextual Task Analysis, samt att det driver alla andra delar av processen förutom Platform Capabilities/Constraints. 1. Hänföra till resultatet från User Profiles 2. Hänföra till resultatet från Contextual Task Analysis 3. Efterforska affärsmässiga målen för ett pensionssystem 4. Identifiera vilka kvalitativa mål som finns 5. Prioritera målen från steg 1 4 6. Omformulera målen från steg 5 till kvantitativa mål, om möjligt 7. Dokumentera de prioriterade användbarhetsmålen 8. Genomföra en användarutvärdering 9. Utifrån resultatet fastställa riktlinje för de kvantifierade målen Momentet kommer att läggas upp och ledas av en användbarhetsingenjör, men övriga medarbetare spelar här en viktig roll i att själva arbetet med att identifiera, kvantifiera och prioritera målen. Det är viktigt att komma ihåg att olika mål är olika viktiga beroende på användarens och situationens egenskaper. Alla måste samarbeta för att de sammantaget mest relevanta målen ska prioriteras i slutändan. Att kvantifiera målen är inte helt lätt det heller, men vanliga mått är tiden för att utföra något, antalet fel på en inom ett visst tidspann, antalet sätt att nå hjälpdokumentation, antal användare som lyckas slutföra ett visst uppdrag, och så vidare. Man kan även dela upp kvantitativa mål i olika nivåer: nuvarande prestationsnivå, minst accepterbara prestationsnivå, målprestationsnivå samt optimal prestationsnivå. Vi räknar med att detta moment kommer att ta c:a 180 timmar från projektgruppens sida, och c:a 50 timmar av användarnas tid. 3.1.4 Platform Capabilities/Constraints Det är även viktigt att fastställa den tekniska platformens möjligheter och restriktioner, eftersom det kan begränsa användargränssnittets designalternativ. För att studera den befintliga platformens användargränssnitt går man igenom dokumentationen i ämnet och intervjuar experter på området. 11
Resultatet av undersökningen blir en dokumentation av den aktuella platformens möjligheter och restriktioner. Detta steg kan utföras när som helst under Requirements Analysis och driver all designverksamhet i de senare stegen. Syftet med detta steg är att definiera vilka gränser och begränsningar gränssnittets plattform har. Vi måste med andra ord ta reda på om vårt pensionsplaneringsprojekt är kompatibelt med användarens utrustning. Om slutprodukten exempelvis är en hemsida måste användaren kunna läsa innehållet och utföra de tjänster som erbjuds. Konsekvenserna kan då bli att man får dra ner på avancerad grafik, stora bilder som tar lång tid att ladda ner etc. Steg ett ska alltid genomföras, resterande steg är nödvändiga i den händelse det finns mer än en plattform eller om användargränssnittsdesignern inte redan är bekant med plattformen/arnas begränsningar. 1. Identifiera plattformarnas egenskaper med avseende på tekniska specifikationer. 2. Gå igenom dokumentation för plattformen. 3. Intervjua teknisk personal. 4. Dokumentera plattformens kapacitet och begränsningar. Användbarhetsdesignern är huvudansvarig. Användbarhetsingenjörernas roll är att ta fram eventuell dokumentation om plattformskapacitet/begränsning om sådan existerar från tidigare projekt. I annat fall, assistera användbarhetsdesignern i uppgiften att strukturera dokumentationen. Konsultation är även önskvärd från teknisk personal. För att designern/designarna ska veta vad som är tekniskt rimligt är detta steg nödvändigt att utföra i ett tidigt stadium. Det är även en god hjälp vid valet av vilken hård/mjukvarumässig platform som man ska arbeta utifrån. Då pensionssystem är ett ekonomisystem innebär det att det kommer innehålla känliga uppgifter som måste skyddas. Detta förespråkar att man väljer ett så stabilt system som möjligt, hellre än ett som kan hantera många olika funktioner och arbetar snabbt. Säkerhet är ett nyckelord, dels då personuppgifter enligt lag ska skyddas från intrång, och dels eftersom det finns höga krav på att uppgifterna stämmer med verkligheten. Ingen användare kommer att uppskatta ett system som har ett väl fungerande gränssnitt men kalkulerar en felaktig pension. För användbarhetspersonal c:a 50 timmar och för utvecklare c:a 20 timmar. 12
3.1.5 General Design Principles Meningen med den här delen är att identifiera alla huvudprinciper och riktlinjer från den aktuella litteraturen om användarbarhet som kan tänkas vara relevanta under produktutvecklingen. Man konsulterar tillgänglig kunskap i ämnet i form av litteratur och experter för att uppnå detta. Denna del av utvecklingen kan utföras när som helst under Requirements Analysis, och integreras med resten av den data man har fått fram i denna huvuddel. Alla vedertagna principer rörande designbeslut övervägs här, i syfte att vårt projekt ska överensstämma med de riktlinjer som finns om hur designen bör se ut. 1. Undersök de relevanta Style Guides som finns om designbeslut 2. Leta upp övrig litteratur om generella designprinciper. Användargränssnittsdesignern har uppgiften att sammanställa tillgänglig litteratur och undersöka kostnad/tillgänglighet för extern konsultation i designprocessen. Användbarhetsingenjörerna utgör de övriga resurser som är önskvärda för insamling av kunskap om design. Då en stor del av användarna har uppnått pensionsålder, finns det skäl att koncentrera sig på vilka användaregenskaper detta medför. Möjliga egenskaper som är aktuella är olika former av handikapp som ålderssjukdomar medför (exempelvis synhandikapp), datorvana, tillgång till dator och internet och möjlighet att lära sig systemet m.h.a manualer o. dyl. Ca 30 timmar, uppdelat på framtagning av Style Guides resp. övriga källor. 3.2 Design/Testing/Development 3.2.1 Nivå 1 3.2.1.1 Work Reengineering Inputen består av användarmodeller som producerades i Contextual Task Analysis och mål som formulerades i Requirement Analysis. De ska nu ombearbetas och dokumenteras. Skälet till ombearbetningen är att uppnå tre mål; effektivitet genom automatisering, att få arbetet att uppnå ekonomiska mål, och att minimera användarnas återinlärning genom att använda deras befintliga kunskap. En viktig fråga är hur människor planerar sin pension manuellt, och hur detta kan förenklas genom automatisering. 13
De aktiviteter som krävs för att ombearbeta användarmodellen är: 1. Ombearbeta modeller och analyser från från det tidigare steget, genom att utgå från de tre målen. 2. Validering och förfining av modellerna med hjälp av faktiska och representativa användare. I vårt fall är faktiska användare till exempel pensionärer och handläggare på försäkringsbolag. Två till fem användare från varje användargrupp genomför en walk through. 3. Dokumentera de ombearbetade modellerna och inkludera dem i en Style Guide. Den som leder arbetet bör varje designern av gränssnittet. De som deltagit i skapandet av User Profile och Contextual Task Analysis ska också bidra med input. Viktigt är att ha med användare i valideringssteget, som nämnts ovan. En användbarhetsingenjör ska vara med och bistå med inriktning och återkoppling. Pensionsplaneringen som ska konstrueras existerar förmodligen redan i andra, manuella former. Det är viktigt att all information om vad som behövs i systemet kommer med, och därför krävs att de olika användargrupperna bidrar med återkoppling. Att pensionssystemet ska vara enkelt att använda för alla grupper av användare är väldigt viktigt. Pensionärer har ofta en begränsad datorkunskap, och är ibland rädda för ny teknik, därför är det speciellt viktigt att representanter från denna grupp är med och utvärderar även i detta relativt tidiga steg. De måste kunna förstå modellerna för att inte bli ifrånsprungna på ett senare stadium. Å andra sidan besitter kanske handläggare på försäkringsbolag mer specifik kunskap, till exempel alla de delar som de kommer att behöva i gränssnittet. Cirka 90 timmar kommer att gå åt i detta steg, exklusive användargruppernas tid. 3.2.1.2 Conceptual Model Design I detta steg användar man input från Work reengineering och föregående fasen som grunden för det första steget i en faktisk design av användargränssnittet. Hänsyn tas bara till högnivådesign och man tar beslut om hur produkten ska presenteras och hur den ska fungera, till exempel hur olika sidor ska se ut och sökvägarna mellan dem. Resultaten från detta steg kommer att behövas i de två efterkommande stegen. De aktiviteter som krävs för modelldesign är: 1. Definiera den konceptuella modellen som produkt eller processorienterad. Vår applikation kräver inte modifikation av dokument, men användaren måste kunna se och strukturera sin information på det sätt han/hon vill, vilken gör modellen mer process än produkorienterad. 2. Identifiera produkter eller processer, till exempel vilka verktyg som användaren i pensionssystemet behöver. 14
3. Bestäm presentationsregler för produkter eller processer. 4. Skapa regler för fönster. 5. Identifiera de större displayerna, till exempel olika fönster för olika typer av pensionssparande. 6. Definiera och designa navigationsmöjligheter. Användaren måste på ett enkelt sätt kunna ta sig mellan de olika delarna. 7. Dokumentera alternativa Conceptual Model Designs. Designern av gränssnittet tar ledningen även i detta steg. Alla medlemmar i arbetslaget som varit med i de tidigare stegen borde också vara med och bidra med synpunkter. Användare kan delta. Detta steg har iterering som huvudsyfte, med mycket brainstorming från alla som arbetar med konstruktionen av pensionssystemet. Modelldesignen kan komma att ändras även i senare steg och är inte fastlagd ännu. Vissa användare kan uteslutas från detta steg, men valda användare från handläggare eller bankpersonal kan vara med för att se till att deras tidigare synpunkter verkliges beaktas. Cirka 200 timmar kommer detta steg att ta i anspråk. 3.2.1.3 Conceptual Model Mock ups I detta steg görs pappersritningar med prototyper, mock ups, för hand med papper och penna, av de olika förslag som formulerades i det föregående steget. En ritning borde göras av exempelvis fönster för försäkringar. Det är lättare att börja om när modellerna görs för hand, eftersom tidskrävande kod inte behöver skrotas om något skulle bli fel. Prototyperna som tas fram jämförs och utvärderas sedan. För varje funktionalitet som ska göras till prototyp väljs först vilken. Sedan procuceras en skiss av användargränssnittet, varpå en mock up görs på papper eller implementeras. Arbetsfördelningen borde vara som i föregående steg. Om en fungerande prototyp ska produceras måste expertis på det området kallas in. Mindre delar av funktionaliteten för gränssnitt kan göras separat, till exempel vilken typ av menyer och dialogrutor som behövs. Cirka 70 timmar är lagom för detta steg. 15
3.2.1.4 Iterative Conceptual Model Evaluation Tester och utvärderingar görs på de mock ups som producerades i föregående steg. Designen utvärderas och modifieras iterativt med hjälp av användbarhetstester för att få bort felaktigheter. Upptäcks fel itereras detta och de två föregående stegen igenom till alla buggar är upptäckta. För varje testiteration sker följande: testet planeras och stödmaterial skapas. Testet utförs sedan och data samlas. Datan som produceras analyseras och omdesign formuleras om detta behövs. 1. Testets fokus bestäms, antingen ska det vara lätt att lära in eller lätt att göra. För ett pensionsplaneringssystem är dock båda viktiga. Den färdiga applikationen kommer att användas av viss användare med begränsad datakunskap och måste vara lätt att lära sig. Eftersom systemet kommer att användas regelbundet krävs även att det är lätt att använda. 2. Bestäm fokus för användare och uppgifter. Här väljer vi ut en grupp användare som kan förväntas använda systemet ofta, såsom yrkesverksamma människor i åldrarna 50 65 år. 3. Skapa uppgifter för testet. 4. Skapa och färdigställ testet, testmaterial och testmiljö. 5. Användare rekryteras till pilottestet som sedan utförs. Att få tag på användare är inte svårt, eftersom de flesta medborgare över 30 pensionssparar. 8. Testet genomförs och data samlas in och summeras, analyseras och tolkas. 9. Eventuella slutsatser dras och de designförändningar som behövs formuleras. 10. Resultatet dokumenteras och presenteras. En användbarhetsingenjör leder arbetet, och designern av gränssnittet är med som assistent. Hela arbetslaget är med som observatörer, och representativa användare kallas in för testet. Detta steg är mycket viktigt, då det färdiga systemet kommer användas av alla typer av användare. Så många olika användare som möjligt ska vara med testet. Testet bör ske av alla de olika funktionaliteterna. 3.2.2 Nivå 2 Nivå 2 består av tre steg och handlar i stort sett om standardisering och enkel implementation av prototypen. 3.2.2.1 Screen Design Standards Konsekvens och enkelhet i detaljerad design ska säkerställas för alla delar i användargränssnittet. Hänsyn tas till industri och företagsstandard och feedback från de föregående aktiviteterna. I detta steg kommer planer för detaljerad design in, till exempel vilka färger och vilket teckensnitt som ska användas och placering av rutor och knappar. Ett användargränssnitt för pensionsplanering bör vara enkelt och ge ett seriöst intryck, så onödiga detaljer bör undvikas här. Däremot är det bra om olika fönsters utseende skiljer sig från varandra så att inte föväxling kan ske. 16
1. Skissa upp kontrollstandard. I denna punkt ser man till att designen blir standardiserad, exempelvis att en klickruta alltid används när användaren ska svara ja eller nej. 2. Skissa upp standard för produkt och/eller processfönster. 3. Skissa up standard för dialogrutor och meddelanderutor. Troligen kommer det inte att behövas så många sådana i systemet, eftersom användarna inte ska skapa egna dokument. 4. Skissa upp standard för interaktion med pekdon. Denna punkt är viktigare för vår applikation, så att användaren kan navigera mellan sidorna på ett enkelt sätt. 5. Skissa upp standard för återkoppling till användare, exempelvis varningssignaler, val. 6. Dokumentation av standarder med bilder och text. Den som leder arbetet bör vara designern av gränssnittet. De som deltagit i skapandet av Requirements Analysis steget och modelldesignen ska också bidra med input. En användbarhetsingenjör ska vara med och bistå med inriktning och återkoppling. Som nämnts ovan är en tydlig och enkel design att föredra här, ingen lekstuga, då systemet ska användas av alla möjliga användare med olika mycket datorvana. Cirka 180 timmar. 3.2.2.2 Screen Design Standards Prototyping Detta steg utgör en brygga mellan föregående och nästkommande steg: här stöds utvärderingen av Screen Design Standards(föregående steg) som sker i Iterative Screen Design Standards Evaluation (nästkommande steg). I det här steget sker faktisk implementation för första gången. Endast de viktigaste funktionerna, kärnan av systemet, implementeras, och med enkla prototyper. Designern får här återkoppling om saker som behöver ändras för att undvika bortslösad tid på felaktiga saker. Saker som ska implementeras, efter att ha skissats upp med papper och penna, är till exempel menyer och interaktionsvägar. 1. Funktionaliteten som det ska skapas en prototyp av väljs ut. Exempelvis menyerna och fönstret för statliga pensioner 2. Enkel specifikation av funktionaliteten. 3. Implementera prototypen. Med prototyp menas föregångare/förebild. I den här kontexten innebär det att vi tar fram tidiga versioner av utvalda delar av vårt system och förbereder för en kommande utvärdering. Lämpliga prototyper kan i vårt fall vara delar av kod eller enstaka applikationer som är tänkta att figurera i den färdiga produkten. 17
Cirka 150 timmar. 3.2.2.3 Iterative Screen Design Standards Evaluation Här utvärderas de två föregående stegen. Feedback inhämtas angående användbarheten. Detta steg motsvarar 3.2.1.4(Iterative CM Evaluation), med skillnaden att i detta skede av processen har produkten kommit närmare sitt slutliga utseende och därmed finns det mer färdigt material att utvärdera. Ändå finns det tid att göra ändringar i gränssnitt och kod, detta är önskvärt i detta skede eftersom det blir svårare att göra större förändringar ju längre framskriden produkten blir. 1. Testets fokus bestäms, antingen ska det vara lätt att lära in eller lätt att göra. 2. Bestäm fokus för användare och uppgifter. I steg 3.2.1.4 var användarna högprioriterade, dvs. sådana som förväntas använda systemet ofta. I detta steg är det lämpligt att även titta på andra kategorier användare för att få nödvändig demografisk och social bredd i utvärderingen. 3. Skapa uppgifter för testet. Uppgifterna bör vara mer detaljerade än i 3.2.1.4 för att få feedback på mer detaljerade designdelar. 4. Skapa och färdigställ testet, testmaterial och testmiljö. 5. Användare rekryteras till pilottestet som sedan utförs. 6.Testet genomförs och data samlas in och summeras, analyseras och tolkas. 7. Eventuella slutsatser dras och de designförändningar som behövs formuleras. 8. Resultatet dokumenteras och presenteras. Användbarhetsingenjören leder arbetet med hjälp av användargränssnittsdesignern. Att med jämna mellanrum ha ett utvärderingssteg är något som gynnar den slutliga produkten och minimerar risken med att ha större fel som hänger kvar från början av processen till slutet. Uppdragsgivaren kan då förvissa sig om att projektet förlöper som det. En annan fördel är att eventuella allmäna ändringar som påverkar pensionsberäkningar, såsom regeringsbeslut om ändrade procentsatser eller dylikt, kan inkorporeras i projektet efter ett utvärderingssteg. På så sätt följer ändringen med i utvecklingen och itereras, så att nyheterna kan utvärderas i ett kommande utvärderingssteg. Ca 150 timmar. De mest tidskrävande posterna är framtagande av testmaterial, genomförande av testet/insamling av data, samt dokumentation/prsentation av resultat. 18
Nivå 3 3.2.3.1 Detailed User Interface Design I detta steg av processen är det dags att färdigställa gränssnittets utseende enligt de riktlinjer som dragits upp i Conceptual Model Design och Screen Design Standards modulerna. 1. Se till att applikationen har korrekta förbindelser mellan de olika funktionerna. Detta innebär i praktiken att testa de knappar och menyval som finns och säkerställa att de korrekta operationerna utförs. Finns det en funktion som beräknar pension utifrån antal yrkesverksamma år ska det valet vara kopplat till ett kalkylprogrammet som ger korrekta siffror som output. 2. Fatta ett slutgiltigt beslut om hur de knappar och menyval som användaren hamnar inför ska designas. En generell standard för design ska finnas sedan tidigare. 3. Med Conceptual Model Design modulen som underlag, specificera hur innehållet i fönster,dialogrutor och meddelandrutor ska designas. 4. Välj design på alla delar av gränssnittet där användaren interagerar med innehållet. Hur ska användaren göra för att välja ett alternativ(musklick,tangenttryckningar e.d.)? Gränssnittsdesignern bör se till att en designspecifikation tas fram, till hjälp för utvecklarna. Eftersom ett pensionsplaneringssystem kräver en pedagogisk utformning såväl som avancerade kalkylfunktioner kan detta inte betraktas som en okomplicerad applikation som utvecklarna själva kan ta ansvar för utifrån en Style Guide. Den självklara aspekten av detta steg är att vi behöver ha ett system som förstås av alla tänkbara användare, vilket innebär stora och tydliga knappar som pensionärer med nedsatt syn kan läsa, klara kontraster mellan färger o.s.v. behöver vi också ta hänsyn till gruppen pensionsberättigade invandrare. Dessa behärskar inte alltid det svenska språket till fullo och behöver ett gränssnitt som kompletterar språklig information med symboler för de olika funktioner. Vi bör också överväga att erbjuda flerspråkiga texter i vårt gränssnitt. Minst 240 timmar bör avsättas för detta steg, eftersom detta är sista chansen att modifiera produkten innan användartester tar vid. 3.2.3.2 Iterative Detailed User Interface Design Evaluation Här testas den färdiga produkten och matchas mot användbarhetsmål. De fel som hittas bör vara av typen lätta att åtgärda. Efter att felen åtgärdats testas produkten igen. 1. Bestäm förutsättningarna för testning: Välj mellan lätt att lära och lätt att använda. 19
Identifiera lämpliga användare för testet. Här är det lämpligt att välja från kategorierna användare som specificerats i kapitel 2. Önskvärt är att hitta nya användare som inte tidigare varit inblandade i produktutveckling. 2. Designa testuppgifter. Uppgifterna bör testa användarens förståelse av gränssnittets design och interaktion med systemet. Uppgifterna bör vara mer detaljerade än i 1.2.2.3. 3. Planera testmaterialet, vilka delar ska ingå? Hur ska användarna övervakas. 4. Hitta en lämplig miljö där testet ska utföras. Miljön ska efterlikna de tänkta användarnas naturliga miljö. Det är viktigt att ta hänsyn till att flera av användargrupperna kanske inte har tillgång till dator i hemmet. Pensionärer är ofta ovana vid datorer och saknar ofta dator hemma. Förtidspensionerade kanske saknar dator av ekonomiska skäl. Miljön bör samtidigt vara trygg och ge användaren möjlighet att slappna av och inte känna sig övervakade. 5. Rekrytera användare. Se punkt 1. 6. Utför testet: Utför testet och samla in data. Gå igenom inkommet data. Analysera och tolka data. Fokusera på områden där data inte uppfyller användbarhetsmålen och försök hitta orsaken till varför dessa områden är problematiska. Formulera slutsatser och rekommendation till designförbättringar. Dokumentera och presentera resultat 7. Gå igenom testproceduren och testmaterialet, gör eventuella korrigeringar. Användbarhetsingenjören har huvudansvaret i det här steget, gränssnittsdesignern bör vara med och assistera. Eftersom detta innebär sista chansen att upptäcka buggar, är noggrannhet ett nyckelord. Detta återspeglas ju också i den beräknade tidsåtgången. Sannolikt vill uppdragsgivaren i detta skede undersöka produkten, eventuella synpunkter från denne bör tas i beaktande för att undvika kritik i ett skede när produkten redan är ute på marknaden. Ca 150 timmar, varav den största delen utgörs av utformning av testmaterial samt presentation/dokumentation av resultat. 3.3 Installation 3.3.1 User Feedback I detta skede av användbarhetscykeln har produkten installerats och användarnas synpunkter samlas in. Detta görs för att möjliggöra förbättringar av produkten,för framtida lanseringar av produkten, som input till liknande produkter samt för att tillgodogöra sig allmänna kunskaper om användbarhet. Mayhew listar fem tänkbara tekniker för att hämta feedback från användarna. Dessa är användbarhetstester, intervjuer, användardiskussioner i grupp,frågeformulär samt 20
användbarhetsstudier. För ett system som tillhandahåller pensionsplanering anser vi att ett frågeformulär är det bästa alternativet. Anledningarna till detta är dels att vi kan räkna med att få in ett stort antal svar, dels att vi i lugn och ro kan konstruera ett frågeformulär som täcker in de frågor vi vill ha svar på. 1. Välj mellan lätt att lära och lätt att använda. 2. Ta fram ett utkast till frågeformulär. 3. Distribuera frågeformulär. Formuläret ska skickas ut till en representativ grupp användare och hänsyn bör tas till att andelen användare som svarar inte alltid är så hög. 4. Analysera svaren. 5. Författa slutsatser som syftar till att förbättra produkten. Användbarhetsingenjören ska ha huvudansvaret, användargränssnittsdesignern ska assistera. En potentiell risk med att samla in feedback från verkliga användare är att vi bara får med synpunkter från en viss typ av användare. Användare utgör ingen homogen grupp, och man kan anta att exempelvis pensionärer och förtidspensionerade kommer att utgöra en oproportionerligt hög procentandel av svaren, eftersom dessa har mer fritid att fylla i frågeformulär på. Vi vill även ha in svar från de som tycker att systemet fungerar bra, och dessa kanske inte ser någon anledning att svara på en enkät. Då missar vi värdefull feedback om vilka delar som fungerar bättre än andra och som det kanske kan vara värt att bygga ut. Utformningen på dessa delar kanske skulle gå att applicera på andra delar som inte har fått lika bra mottagande. För utvecklare: ca 110 timmar. För användare: ca 84 timmar. 21
4 För och nackdelar med Mayhews metod En bra egenskap är att The Usability Engineering Lifecycle föreslår konkret hur skapandet av ett gränssnitt ska planeras och genomföras, och täcker in väldigt många områden. Mayhew fokuserar på att göra produkter som är bra och användbara för användaren, inte något som bara ska skapas och säljas för att företaget som tillverkar produkten ska tjäna pengar. Det är bra att hon har delat in varje nivå i delsteg som kan följas,och att hon har definierat vem som ska göra vad i arbetet. Däremot kunde användare ha fått vara med mer i utvecklingsarbetet, inte bara i tester. Det råder dock inget tvivel om att boken fyller ett behov: oavsett om projektet går ut på att utveckla ett nytt dataspel eller ett system för pensionsplanering är boken ett värdefullt verktyg längs processens väg. Något som kan vara negativt med Mayhews teori är att den är väldigt omfattande med kanske onödigt många olika steg och nivåer som ska gås igenom och itereras under skapandet av ett gränssnitt. Vissa av stegen har också förvirrande lika namn och uppgifter. Omfattningen av teorin gör att det något svårt att arbeta med boken, det kan vara svårt att hålla isär alla begrepp. Det är ju önskvärt att arbetet med gränssnittet ska förenklas med hjälp av teorin, inte fördunklas. Mayhew föreslår väldigt frekvent dokumentation, vilket i och för sig är bra så att inget arbete går förlorat. Å andra sidan så kan överdriven dokumentation leda till onödigt mycket tidsåtgång som kunde användas till viktigare saker. En sak som är lite oklar är hur gränssnittet kopplas samman med eventuellt underliggande eller samverkande applikationer, exempelvis databaser. Teorin handlar i och för sig endast om gränssnittet, men om gränssnittet låses fast vid en viss design kanske det skapas problem när det ska användas ihop med externa applikationer. Om läsaren av boken tar sig tid att sätta sig in i och förstå de vitala delarna i teorin kan den säkert fungera bra som hjälp. Allt i teorin behöver inte tillämpas på gränssnittet. 5. Källförteckning Mayhew,D,1999: The Usability Engineering Lifecycle. A practitioner s handbook for user interface design. Morgan Kaufmann Publishers. 22