Användarcentrerad utveckling av e-val

Transkript

1 UPPSALA UNIVERSITET Institutionen för informationsteknologi Användarcentrerad systemdesign Sommarkurs 2004 Användarcentrerad utveckling av e-val - efter Mayhews Usability Engineering Lifecycle Eva-Lotta Högberg evho7886@student.uu.se Karin Söderbäck kaso5488@student.uu.se

2 Innehållsförteckning 1 Uppgiftsbeskrivning The Usability Engineering Lifecycle Fas 1: Requirements analysis User Profile Contextual Task Analysis Platform Capabilities and Constraints General Design Principles Usability Goal Setting Fas 2: Design/Testing/Development Fas 3: Installation Användarcentrerad utveckling av e-val Fas 1: Requirements analysis User profile Röstberättigade medborgare Vallokalsarbetare Valräknare Teknisk personal Ovälkomna användare Task analysis Platform Capabilities/Constraints General design principles Usability goal setting Fas 2: Design/testing/development Nivå 1: Högnivådesign Work Reengineering Conceptual Model Design Conceptual Model Mock-ups Iterative Conceptual Model Evaluation Nivå 2: Standardisering Screen design standards Screen design standards prototyping Iterative screen design standards evaluation Nivå 3: Designen slutförs Detailed user interface design Iterative detailed user interface design evaluation Fas 3: Installation Planering Tidplan Involverade i projektet För- och nackdelar med Mayhews metod Litteratur

3 1 Uppgiftsbeskrivning På uppdrag av Valmyndigheten har vi blivit utsedda att planera och lägga upp ett användarcentrerat projekt för att utveckla en tjänst som i framtiden gör det möjligt att vid val rösta med hjälp av informationsteknik och telekommunikation. Krav finns på att olika typer av val ska kunna genomföras såsom EU-val, riksdagsval, kommunalval och folkomröstningar. Det ska vara smidigt för valdeltagarna att använda tjänsten och ingen ska bli utestängd från möjligheten att rösta. Säkerheten är viktig då resultatet ligger till grund för politiska beslut. Användbarhetsaspekten är också mycket viktig då alla ska kunna lägga sin röst. Vi har valt att följa Deborah J. Mayhews metod som hon beskriver den i The Usability Engineering Lifecycle a practitioner s handbook for user interface design" (1999) vid uppläggningen av projektet. Vi har valt att begränsa oss till att i första hand planera för en tjänst med internet som rösthjälpmedel. Nästa steg vore att även inkludera röstning via mobiltelefon men eftersom det handlar om ett användarcentrerat projekt anser vi att det är viktigt att först samla in feedback och utvärdera ett nytt rösthjälpmedel. Då kan vi dra nytta av den kunskapen vid införandet av nästa rösthjälpmedel. Rapporten är disponerad så att den börjar med en kortfattad beskrivning av Mayhews metod, för att därefter komma ni på själva e-valet. Vi beskriver den användarcentrerade utvecklingen av systemet steg för steg. Rapporten innehåller även en planering över tidsåtgång och projektgruppssammansättning. Avslutningsvis diskuterar vi för- och nackdelar med Mayhews metod. 3

4 2 The Usability Engineering Lifecycle Mayhew skriver att metoden The usability engineering lifecycle handlar om att uppnå användbarhet med användargränssnitt. Hon menar att för användaren så är gränssnittet produkten, eftersom det endast är genom detta som kommunikationen mellan användaren och produkten sker. Vidare anser författaren att användbarhet (usability) är en mätbar enhet hos ett gränssnitt. Man kan tala om en högre eller lägre grad av användbarhet. Som exempel på ett mått på användbarhet nämner Mayhew hur lätt användargränssnittet är att lära sig för första-gångs-användare, samt hur lätt det är att använda för vana användare. Usability engineering är ett område inom vilket strukturerade metoder utvecklats, för att med hjälp av dem uppnå användbarhet hos användargränssnitt. Mayhew har inom detta område utvecklat en metod som hon kallar The usability engineering lifecycle. Denna metod innehåller flera olika typer av uppgifter som bör utföras i ett systemutvecklingsprojekt. Det handlar om strukturerade uppgifter för att analysera användbarhetskrav, uppgifter för att utifrån användbarhetskraven ta fram användbarhetsmål, uppgifter som stödjer ett strukturerat tillvägagångssätt för utveckling av användargrässnitt utifrån användbarhetsmålen, samt uppgifter för utvärdering av användbarheten och iterering mot användbarhetsmålen. Mayhew delar upp metoden i tre faser: Requirements analysis, Design/testing/development samt Installation. Varje fas delas sedan upp i ett antal mindre steg där vart och ett av dessa innehåller konkreta uppgifter. Nedan följer en kort beskrivning av faserna och dess steg med uppgifter. 2.1 Fas 1: Requirements analysis User Profile Detta steg innebär att ta fram en beskrivning över användarna, med fokus på de särdrag som har betydelse för gränssnittet. Detta görs genom enkäter och intervjuer med användare samt genom intervjuer med personer som har kunskap om användarna Contextual Task Analysis Här studeras användarnas nuvarande uppgifter och sätt att arbeta, genom observationer och intervjuer. Resultatet av detta steg beskrivs i text, som kommer till nytta senare i processen Platform Capabilities and Constraints Gränssnittets möjligheter och begränsningar bestäms och dokumenteras här, utifrån den tekniska plattform som ska användas för produkten. Detta avgör vilka möjligheter man har vid utvecklingen av gränssnittet. 4

5 2.1.4 General Design Principles Denna uppgift innebär att samla in andra relevanta riktlinjer och åsikter om design av användargränssnitt, från Usability Engineering-litteratur. Detta material, tillsammans med det man fått fram från de fyra redan genomförda uppgifterna, används sedan i den fortsatta designprocessen Usability Goal Setting Här specificeras användbarhetsmål, både kvalitativa och kvantitativa. De kvalitativa målen sätts utifrån användbarhetskrav från de båda tidigare stegen User Profile och Contextual Task Analysis medan man med de kvantitativa definierar sådant som kriterier för användartillfredsställelse. Mayhew menar att användbarhetsmålen bör vara drivande för designen. Dessa nu genomförda uppgifter i fas 1 dokumenteras i en arbetsprodukt som Mayhew kallar en Style Guide. 2.2 Fas 2: Design/Testing/Development Mayhew delar upp fas 2 i tre nivåer. Inom den första nivån 1 sysslar man med designuppgifter på hög nivå, det vill säga man kodar inte utan strukturerar upp arbetet, skissar på mock-ups och utvärderar det förberedande designarbetet. I nivå två 2 sätter man standarder för hur designen ska se ut, baserat på gällande konventioner och resultaten från fas 1 samt tidigare steg i fas 2. Man utvecklar körbara prototyper och utvärderar dessa för att undersöka om användbarhetsmålen är uppfyllda. Dessa steg itereras ända tills alla större användbarhetsbuggar är borta. På nivå 3 3 slutförs så designarbetet genom förfining och detaljputsning, varefter systemet återigen utvärderas. Man itererar kring nivå 3 tills användbarhetsmålen är uppfyllda. I slutet av varje nivå dokumenteras arbetet i en Style guide. Om all funktionalitet fungerar tillfredsställande, går man vidare till fas 3. Annars går man tillbaka till fas Fas 3: Installation När produkten installerats och varit i produktion ett tag, samlas feedback in för att användas vid design av nya releaser. Enligt Mayhew finns det flera bra anledningar till varför det är viktigt med feedback från användare. Förutom att den kan användas vid framtida releaser så är den insamlade feedbacken till nytta vid design och utveckling av andra produkter med samma eller liknande användargrupp. Den bidrar också till lärdomar om användbarhet inför kommande utveckling inom organisationen. 1 Den fösta nivån består av stegen Work Reengineering, Conceptual Model (CM) Design, CM Mock-ups, Iterative CM Evaluation. 2 Den andra nivån består av Screen Design Standards (SDS), SDS Prototyping, Iterative SDS Evaluation. 3 Den tredje nivån består av Detailed User Interface Design (DUID), Iterative DUID Evaluation. 5

6 3 Användarcentrerad utveckling av e-val I detta kapitel beskrivs hur arbetet med e-valsprojektet ska utföras. Upplägget följer det i föregående kapitel, då beskrivningen görs fas för fas. I varje steg anges vem som enligt Mayhew bör leda och deltaga i aktiviteterna. För en beskrivning av de uppgiftsansvariga hänvisas till kapitel Fas 1: Requirements analysis User profile För att få fram användarprofiler kommer vi att göra frågeformulär som delas ut till röstberättigade. Dessa sammanfattas och analyseras sedan för att ta fram så kallade user profiles som är nödvändiga för att identifiera olika användargrupper. Dessutom kommer vi att göra intervjuer med valarbetare samt experter på valdeltagande och rösträkning. En användbarhetsingenjör bör leda uppgiften att ta fram användarprofiler och då dra nytta av sina kunskaper inom frågeformulärsdesign och dataanalys. Han bör också åtminstone leda, granska och bidra med slutsatser från insamlad data. Projektmedlemmar och/eller användargränssnittsdesignern kan utföra större delen av arbetet. Användare deltar i frågeutformningen, i pilotfrågeformuläret, och som svarande på det slutgiltiga frågeformuläret. Vi har identifierat följande användare: Röstberättigade medborgare, vallokalsarbetare, valräknare, teknisk personal samt ovälkomna användare Röstberättigade medborgare Eftersom alla med rösträtt får delta i val får vi ett extremt stort antal användare. Gemensamt för valdeltagarna är att de är svenska medborgare (dock ej krav vid kommunalval) och över 18 år. Faktorer som skiljer dem åt och har betydelse för systemutvecklingen är; datavana, psykologiska (motivation, villighet att rösta över internet) samt fysiologiska (olika handikapp som till exempel färgblindhet) förutsättningar. Vi rekommenderar att användarna delas in i olika användargrupper för att på så sätt skapa möjligheten att kunna välja ut ett antal personer från varje grupp som får deltaga i utvecklingsarbetet. Alla som kan rösta med dagens system ska kunna göra det även när det nya systemet införs. En minimal nivå (x) sätts för hur många procent av det totala antalet röstdeltagare en användargrupp bör utgöra för att dess speciella krav ska uppfyllas med elektronisk röstning. Det vill säga om minst x % av de röstberättigade kräver en viss tjänst, t.ex. en viss språköversättning eller funktionshindersanpassning, så genomför vi den. Annars hänvisas de till att rösta på traditionellt sätt. 6

7 Vallokalsarbetare Det är inte bara valdeltagare som kommer att använda systemet utan det kommer även personal som arbetar med valet att göra. Det bör utredas vad som händer med denna grupp när valet blir allt mer datoriserat. De datakunniga kan få nya uppgifter medan övriga blir utan arbetsuppgifter. Det kommer att krävas nedskärning och kompetensutveckling av personalen. Nya uppgifter kan bli att vara behjälplig vid en publik röstningsdator eller som telefonsupport. Möjligheten att rösta på traditionellt sätt ska finnas kvar så viss ordinarie personal kommer att behövas. Det som är gemensamt för vallokalsarbetarna är deras kunskap och erfarenhet från tidigare val. Erfarenheten är dock olika stor. Det som skiljer dem åt är deras yrkesvana, datavana samt även här psykologiska och fysiologiska förutsättningar. Några av dem kanske vill vidareutbilda sig inom data medan andra inte har något intresse av att göra det Valräknare Valräkningsprocessen kommer delvis att automatiseras i och med införandet av det nya systemet. En del röster kommer fortfarande att räknas för hand medan sammanräkningen av elektroniska röster nu blir datoriserad. Möjlighet till kontroll av den datoriserade räkningen ska finnas, och backuper måste tas. Valräkningen måste omgärdas av hög säkerhet så att exempelvis en röst inte räknas dubbelt. De som ska arbeta med den datoriserade räkningen måste ha viss statistik- och datakunskap. Precis som för vallokalsarbetarna skiljer sig arbetarna i denna grupp åt när det gäller yrkeserfarenhet, datavana samt psykologiska och fysiologiska förutsättningar. Det kommer att behövas experter på datoriserad rösträkning som planerar, lägger upp och övervakar arbetet Teknisk personal Det kommer att krävas teknisk personal som arbetar med uppbyggnad och underhåll av systemet. De som arbetar med tekniken får inte utnyttja sin position och fiffla med valresultat eller ta reda på vad någon individ röstat. Ett problem är hur denna personal ska kontrolleras utan att det blir kränkande. Eftersom systemet bygger på avancerad teknik måste kontroll genomföras av personer med sådan kompetens. Sekretessavtal som personalen får skriva under kan också vara en nödvändig åtgärd, samt inloggningskrav Ovälkomna användare Vid val får inte fusk förekomma. Vid en datorisering av röstprocessen skapas nya möjligheter att fuska. Därför är säkerheten viktig. Röstdeltagare måste identifiera sig elektroniskt och ska bara kunna lägga sin röst en gång. Det ska vara anonymt att rösta och därför måste elektronisk avlyssning motverkas. Detta kan ske med till exempel kryptering av den data som skickas från röstdeltagaren till valmyndigheten. Kommunikationen mellan webbläsare och webbserver bör ske 7

8 på ett säkert sätt förslagsvis med SSL 4 -kryptering. För många användare samtidigt kan leda till överbelastning och innebära att tjänsten tidvis inte fungerar alls eller bristfälligt. Detta kan motverkas genom direktioner om vid vilken tidpunkt olika distrikt kan lägga sin röst. Det är dock viktigt att röstdeltagarna inte får mindre tid på sig än vid tidigare val. Kanske kan man utöka röstningsperioden till mer än en dag. Poströstning i elektronisk form kräver att tjänsten går att använda under ett längre tidsintervall. Det bör undersökas vilka säkerhetsrisker det kan innebära att ha tjänsten öppen under längre tid. Det kan förekomma hot på väg till traditionella vallokaler men väl inne i vallokalen garanteras idag röstdeltagarens anonymitet genom att röstningen sker bakom en skärm med personal i närheten som ser till att denne inte blir störd eller hotad. En sådan garanti är svårare att ge vid röstning hemifrån. Det bör därför undersökas hur möjligheten att rösta hemifrån kan medföra högre risk för påtryckningar och hotsituationer och hur det skulle kunna motverkas. Det bör tillsättas en säkerhetsgrupp för att utreda ovanstående och eventuella ytterligare risker. Säkerhetsexperter bör tillsättas för att arbeta fram vilken teknik som ger högst säkerhet Task analysis Vi kommer att studera hur röstandet går till idag genom att besöka vallokaler och där studera både valdeltagarna och valarbetarna i arbete. Hur de tänker, pratar om och utför sina uppgifter. Dessutom kommer vi vara med efteråt vid rösträkningen för att studera hur den går till vid nuvarande system. Resultatet av iakttagelserna dokumenteras. En användbarhetsingenjör bör leda uppgiften och därmed bidra med sina kunskaper inom Task analysis. En gränssnittsdesigner och alla projektmedlemmar bör delta i alla delar av uppgiften. Användare deltar genom att bli observerade/intervjuade. De kan också vara aktivt deltagande i analysprocessen Platform Capabilities/Constraints Möjligheter och begränsningar med användargränssnittet beroende på vald teknisk plattform ska bestämmas och dokumenteras enligt Mayhew. I detta fall så kan vi inte begränsa oss till en plattform eftersom det ska gå att deltaga i valet oavsett vilken typ av dator valdeltagaren använder. En begränsning till följd av detta är att tjänsten inte får kräva för hög prestanda. Dock krävs internetuppkoppling för att kunna rösta elektroniskt hemifrån. I detta steg bestäms minimikrav på röstdatorerna. Det ska finnas minst en publik röstningsdator i varje valdistrikt men också möjlighet att rösta på vanligt sätt för den som föredrar det. Det är viktigt att respektera de medborgare som av någon anledning inte vill rösta elektroniskt. Uppgiften leds av användargränsnittsdesignern assisterad av användbarhetsingenjören. Teknisk personal behöver konsulteras för att identifiera 4 Secure socket layer. Säkerhetsprotokoll som använder publika/privata nycklar för autentisering och kryptering av kommunikation. 8

9 plattform samt klargöra möjligheter och begränsningar General design principles Generella principer för gränsnittsdesign kommer att samlas in från användarcentrerad litteratur. Vi kommer även att titta på redan existerande elektroniska tjänster som till exempel riksskatteverkets deklarationsservice samt bankernas internetservice, för att undvika att uppfinna hjulet två gånger. Användargränsnittsdesignern är primärt ansvarig för att samla in och läsa igenom tryckt material, samt för att planera och sätta upp budget för extern konsulthjälp. Användbarhetsingenjören kan med sin bakgrund komma med råd om metoder och litteratur Usability goal setting Nu sätts det upp kvalitativa mål, utifrån User profile och Task analysis, och kvantitativa mål, som definierar minimalt accepterad nivå av användarbeteende, samt tillfredställelsekriterier. Specifika användarmål ger designers något konkret att arbeta efter. Kvalitativa mål kan till exempel vara att systemet ska vara lätt att lära för förstagångsanvändare, eller att det ska vara lätt att använda för erfarna användare. För e-valet kommer till exempel gälla att användarna inte ska behöva känna till hur systemet är uppbyggt för att kunna använda det. Sådana kvalitativa mål ska tas fram i detta steg. Kvantitativa användbarhetsmål är mätbara, som till exempel Det ska ta användaren (i detta fall den som avger sin röst) maximalt fem minuter att avlämna sin röst via datorn. Mål ska tas fram för varje användarprofil; Röstberättigade medborgare, vallokalsarbetare, valräknare, teknisk personal samt ovälkomna användare (här är målen att förhindra intrång). Användbarhetsingenjören leder uppgiften. Användargränsnittsdesignern deltar med identifiering, kvantifiering och prioritering av användbarhetsmål. Deltagande från övriga projektmedlemmar samt andra intressenter är önskvärt. Allt arbete från fas 1 dokumenteras i produkten Style guide. 3.2 Fas 2: Design/testing/development Nivå 1: Högnivådesign Nivå 1 består av fyra steg; Work reeingeneering, Conceptual model design, Conceptual model mock-ups samt Iterative conceptual model evaluation. Användargränssnittsdesignern bör leda uppgiften i varje steg. Alla projektmedlemmar som deltagit i User profile och Task analysis bör delta och komma med idéer och synpunkter. Användbarhetsingenjören bör också delta för att bidra med ledning och feedback. I tredje steget behövs en person med kunskap från att skapa mock-ups. Användare deltar främst i utvärderingen men även en del vid skapandet av mock-ups Work Reengineering Här tittar vi först på hur valet går till idag hur beter sig personer när de röstar, hur beter sig valarbetarna? Denna information finns redan tillgänglig från fas 1. Nästa steg är att fundera på vad i 9

10 valprocessen som kan göras enklare och smidigare genom att införa e-val. Vi tittar inte bara på hur röstdeltagarnas aktiviteter ska förändras, utan på hela den omgivande organisationen. För att tala i Mayhews termer, så undersöker vi vad som kan automatiseras för att göra processen effektivare. Med andra ord strukturerar vi upp arbetet för att ha något att utgå ifrån i följande steg Conceptual Model Design Nu är det dags att ta det första klivet mot design, fram tills nu har arbetet rört förberedande och övergripande frågor. En utgångspunkt för detta är användarens så kallade mentala modell. Användarens mentala modell är den enklast möjliga modell som hjälper till att förklara ett visst fenomen (Gulliksen & Göransson 2002 s. 115). Den som röstar via en dator kommer att uppfatta det systemet på ett visst sätt, antagligen inte på samma sätt som vi som designar systemet. Olika användare, även inom samma användargrupp, kan dessutom ha olika uppfattningar om vad det är de ser. Därför är det viktigt att ha detta i åtanke genom hela utvecklingsprocessen, så att det i möjligaste mån blir ett logiskt och konsekvent system. Det är en konceptuell design som tas fram i detta steg högnivådesign. Ett antal alternativa skisser (cirka 2-3 stycken) tas fram, som var och en visar systemets övergripande funktionalitet. Hur navigering ska gå till kommer studeras här, däremot inte hur systemet kommer att se ut rent layoutmässigt på skärmen Conceptual Model Mock-ups Nu har vi kommit fram till en kreativ aktivitet med papper och penna. Denna kan utföras genom att göra körbara program, men eftersom inga dörrar ska hållas låsta föredrar vi att skissa på gammalt hederligt sätt. (Som Mayhew säger är det betydligt lättare att skrota pappersskisser och börja om, än att slänga kod i papperskorgen.) I denna aktivitet kommer vi att ta fram ett antal så kallade mockups. En mock-up är en pappersritning som symboliserar hur något ska se ut i framtiden. Det är inte tänkt som något slutgiltigt och inte heller görs någon större ansträngning för att det ska se snyggt ut, utan syftet är att snabbt få fram exempel på hur designen kan se ut. Genom att utgå från grundskisserna från föregående steg, kommer vi här arbeta vidare med den konceptuella designen. Vi kommer att ta fram de olika fönster som ska finnas i gränssnittet för olika funktioner (till exempel för att lämna en röst), samt skriva viss förklarande text till vilka funktioner fönstret ska innehålla. På separata papper kommer vi att skissa på funktioner som dialogrutor och rullgardinsmenyer Iterative Conceptual Model Evaluation Den konceptuella designen utvärderas och modifieras iterativt genom att låta slutanvändare testa mock-upsen för att upptäcka felaktigheter och otydligheter. Eftersom vår användargrupp är så pass bred så kommer vi att låta ett antal av dem (som väljs ut så att alla olika profiler blir representerade) vara med vid testningen. Upptäcks fel (som till exempel att användarna inte inom en förutbestämd 10

11 tid kan lösa vissa uppgifter) så går vi tillbaka till Work reengineering-steget. Sedan går vi igenom stegen Conceptual model design och Conceptual model mock-ups, för att därefter göra en ny utvärdering. På så sätt itererar vi fram den konceptuella designen tills inga större felaktigheter längre finns. Allt arbete från denna nivå 1 av fas 2 dokumenteras i produkten Style guide Nivå 2: Standardisering Nivå 2 består av tre steg; Screen design standards, Screen design standards prototyping samt Iterative screen design standards evaluation. Användargränssnittsdesignern bör leda uppgiften i varje steg. Alla projektmedlemmar som deltagit i Requirements analysis och stegen i designnivå 1 bör delta och komma med input och feedback. Användbarhetsingenjören bör delta för att komma med riktlinjer och feedback. Användare ska också delta aktivt som designmedlemmar i det första steget och som testanvändare i tredje steget. I steg två behövs en person med erfarenhet från att skapa prototyper Screen design standards Produktspecifika standarder och konventioner för detaljerad skärmdesign utvecklas. Det ska säkerställa koherens och konsistens i designen av användargränssnittet. Saker som ingår här är terminologi, färg, teckensnitt, hur kommunikationen ser ut (markera rutor, klicka på olika saker) samt placering av knappar, menyer med mera. I vårt fall är det en fördel om det som väljaren ser framför sig är likadant oavsett om denne röstar på en publik dator eller en privat, eftersom det ger en trygghetskänsla. Det är vidare viktigt att gränssnittet rent generellt ger ett seriöst intryck Screen design standards prototyping I detta steg kommer implementation ske på riktigt för första gången. Systemet ska inte byggas i ett svep, utan de funktioner som kommer att utgöra kärnan av systemet, samt de vi tror kommer vara mest problematiska, kommer att byggas först. Utifrån designspecifikationerna från tidigare steg kommer skisser på funktionerna först ritas upp på vanligt papper. Skisserna kommer att innehålla fönster, menyer, interaktionsvägar mellan användare och system samt meddelanderutor. Först därefter kommer prototypen att byggas Iterative screen design standards evaluation Detta steg liknar det tidigare utvärderingssteget (Iterative conceptual model evaluation) ganska mycket. Det som skiljer är att det som nu ska utvärderas är körbara prototypprogram, samt att testerna som utförs är mer noggrant specificerade och mer detaljerade. Användare från de olika användargrupperna tas in för att testa prototyperna. Alla användare behöver inte testa allt, utan de som arbetar med valräkning får exempelvis i första hand testa just prototyper som har med det att 11

12 göra. Testerna utförs i en miljö som liknar den verkliga. Det bästa vore att befinna sig i exakt den miljö användarna senare kommer att vara i, men det kan vara svårt att exempelvis testa e-val i en röstlokal där det pågår ett vanligt val. Efter testerna tolkas resultaten och det bestäms vilka förändringar som bör göras. Så länge man inte är nöjd med testresultaten itererar man tillbaka till Screen design standards och går ett varv till i nivå 2. Allt arbete från nivå 2 dokumenteras i produkten Style guide Nivå 3: Designen slutförs. Nivå 3 består av två steg; Detailed user interface design och Iterative detailed user interface design evaluation Detailed user interface design Detta steg handlar om att färdigställa designen utifrån det arbete som gjorts fram till nivå 3. Det kommer röra sig om att färdigställa innehållet i fönster, dialogboxar, menyer och interaktionsvägar. Designers och programmerare kommer att arbeta med detta, i samråd med bland andra användbarhetsdesignern och användbarhetsingenjören Iterative detailed user interface design evaluation Syftet med detta steg är att utvärdera den slutgiltiga designen mot användbarhetsmålen. Förhoppningen är att endast mindre buggar kommer att upptäckas i detta steg, eftersom alla större fel ska vara upptäckta redan. Användbarhetsingenjören bör leda uppgiften, med assistans av användargränsnittsdesignern som bidrar med planering och utvärdering. Användare deltar vid utvärderingen som testanvändare. Hittar vi något fel går vi tillbaka ett steg till Detailed user interface design. Om funktionaliteten fungerar tillfredställande så sätts systemet i bruk och anses färdigt, annars så går vi tillbaka till fas Fas 3: Installation I denna fas samlar vi in och utvärderar feedback efter att systemet varit i bruk ett tag. Feedbacken används vid nya releaser och vid framtida system som också har en stor del av befolkningen som användargrupp. Före en ny release bör man överväga om fördelarna med den nya versionen överväger det motstånd som följer med att ändra systemet. Att systemet utifrån användarens syn fungerar på samma sätt kan vara till fördel när det gäller att ge ett säkert och seriöst intryck. Däremot är det viktigt att felaktigheter åtgärdas och att glömda målgrupper kan inkluderas. Det är också viktigt med feedback kring hur säkerheten har fungerat. Intressanta feedbackgrupper är valdeltagare, både de som röstat elektroniskt samt de som röstat på 12

13 vanligt sätt (har den vanliga servicen till exempel upplevts som försämrad?), valarbetare, samt rösträkningsexperter (är resultatet normalt i förhållande till andra år, gick det smidigare?) och säkerhetsexperter inom IT. En användbarhetsingenjör bör leda denna uppgift. En användargränssnittsdesigner bör delta som assistent med planering och feedbackteknik. Andra projektmedlemmar kan delta som assistenter om det behövs, och alla bör delta som observatörer. Användare deltar genom att ge feedback. 4 Planering 4.1 Tidplan Nedan följer en grov uppskattning av hur lång tid de olika stegen i livscykeln skulle ta att utföra. Fas 1: Requirements analysis User Profiles: 220 timmar Contextual task analysis: 340 timmar Usability goal setting: 220 timmar Platform Capabilities/Constraints: 60 timmar Fas 2: Design/testing/development Work Reeingenering: 90 timmar Conceptual Model Design: 200 timmar Conceptual Model Mock-ups: 80 timmar Iterative Conceptual Model Evaluation: 450 timmar (150 per iteration) Screen Design Standards: 180 timmar Screen Design Standards Prototyping: 150 timmar Iterative Screen Design Standards Evaluation: 450 timmar (150 per iteration) Detailed User Interface Design: 240 timmar Iterative Detailed User Interface Design Evaluation: 450 timmar (150 per iteration) Fas 3: Installation User Feedback: Sker inför vidareutveckling inför nya lanseringar, varför den inte räknas med i denna första tidplan. 13

14 Total projekttid: Cirka 1,5 år Den totala projekttiden är beroende av hur många iterationer som kommer att behövas i de olika nivåerna och därför omöjlig att ange exakt. Dessutom påverkas projekttiden av när de val som ska studeras äger rum. 4.2 Involverade i projektet Användbarhetsingenjör (Usability Engineer) Har utbildning och kunskap för att kunna utföra alla steg och många av de tekniker som används i livscykeln. Rollen kräver utbildning och erfarenhet från åtminstone någon av disciplinerna inom användarcentreringsområdet. Ska vara skicklig på att utföra user profiles, contextual text analysis samt usability testing. Användargränsnittsdesigner (User Interface Designer) Roll som kräver god designförmåga men inte utbildning och erfarenhet från annan användarcentrerad teknik. Utför den faktiska designen i livscykeln. Viktiga medlemmar i projektet är också prototyputvecklare, programmerare, designers, valmyndighetsrepresentanter, valräkningsexperter, valdeltagandeexperter samt användare. 5 För- och nackdelar med Mayhews metod Som vi ser det finns både för- och nackdelar med metoden The usability engineering lifecycle. Bland fördelarna är det främst två som kan nämnas. Den första är att det är konkreta uppgifter som ska genomföras vid systemutvecklingen. Mayhew talar klart och tydligt om, inte bara vad, utan även hur man bör gå tillväga. Exempelvis finns det många step-by-step -beskrivningar i boken som kan vara praktiska att följa. Den andra stora fördelen är det användarfokus som finns genomgående i metoden. Från början genom att först göra en noggrann kartläggning av vilka användarna är, till att i utvecklingsarbetet ta med dem exempelvis vid utvärdering av mock-ups, men även i de flesta andra steg. Faktum är att Mayhew för varje uppgift specificerar användarnas roll. Nackdelarna med metoden är dels att kopplingen till användargränssnittet är så stark och genomgående, dels att det inte finns så många bakåtpilar i modellen som kanske skulle vara önskvärt. Den starka kopplingen till design beror på att Mayhew anser att gränssnittet är systemet, i användarens ögon. Detta kan hon nog ha rätt i, men frågan är om man inte genom att ständigt ha 14

15 detta i åtanke, binder sig för mycket vid en viss design. Det finns en risk att man tidigt i projektet får en syn på hur designen ska se ut, som kan vara svår att ändra senare. Då kan det bli så att designen så småningom kommer att få prioritet över användbarhetsmålen, vilket inte är önskvärt. Den andra punkten i kritiken gäller som sagt bakåtpilar. Inom fas 2 sker iterationer på bra ställen, då varje nivå itereras tills användbarhetsmålen är uppfyllda. Detta håller vi med om, men vi ställer oss lite frågande till att man måste genomföra hela fas 2, innan man kan iterera tillbaka till fas 1. Fas 2 innehåller mycket arbete och tar enligt vår planering 20 veckor. Vi efterlyser därför en möjlighet att gå från något tidigare ställe i fas 2, alltså utan att hela fasen är slutförd, tillbaka till fas 1. Visst går det att själv välja att göra iterationen, men om Mayhews metod ska följas konsekvent så måste fas 2 slutföras helt innan det sker någon iteration tillbaka till fas 1. 6 Litteratur Mayhew, D. J., 1999, The Usability Engineering Lifecycle a practioner s handbook for user inteface design. Academic Press, San Diego. Gullliksen, J. & Göransson B., 2002, Användarcentrerad Systemdesign. Studentlitteratur, Lund. 15