Utveckling av ett system för E-val

Transkript

1 Uppsala Universitet Uppsala den 2 augusti 2004 Institutionen för informationsteknologi Användarcentrerad systemdesign 5 poäng, sommaren 2004 Kursansvarig: Jan Gulliksen Assistent: Stefan Blomkvist och Inger Boivie Utveckling av ett system för E-val En projektplan baserad på Contextual Design Beyer och Holtzblatt Projektgrupp 3 Av: Kristin Schoug kristin@schoug.se Jakob Brundin Jabr0519@student.uu.se

2 UPPGIFTSBESKRIVNING... 3 SYSTEMBESKRIVNING... 3 DEFINITION AV ANVÄNDARE... 3 PROJEKTPLAN... 3 PROJEKTGRUPPEN... 4 AKTIVITETER... 5 Kontextuell utredning... 5 Tolkning och arbetsmodellering... 6 Arbetsmodellering...7 Tolkningsfas...8 Sammanställning... 9 Affinitydiagram...10 Sammanställning av arbetsmodeller...10 Omstrukturering av arbetet Design av användarmiljön Prototyping TIDPLAN DISKUSSION

3 Uppgiftsbeskrivning Vår uppgift är att skriva en projektplan för utvecklingen av ett system som stödjer olika typer av val. Vår process ska följa den modell som finns i boken Contextual Design av Hugh Beyer och Karen Holtzblatt. Boken ligger som grund genom hela projektplanen men i vissa fall har vi varit tvungna att ta bort eller lägga till delar för att anpassa modellen till vårat system. Systembeskrivning Det system som ska skapas ska användas för röstning i olika typer av val i Sverige. Det ska fungera som ett komplement till dagens manuella system genom att ta hjälp av andra verktyg som till exempel Internet eller telefonnätet. Olika typer av val ska kunna genomföras via systemet, det kan vara riksdagsval, EU-val, folkomröstningar etc. För att ett sådant system ska fungera är kraven många och avgörande. De övergripande kraven som måste uppfyllas är följande: Höga krav på användbarhet och tillgänglighet då användarna är av olika åldrar och från alla olika delar av samhället. Höga krav på tillförlitigheten då det ska vara omöjligt för fel att uppstå och för fusk att gå igenom. Krav från myndigheter och berörda organ. Det som gör systemet speciellt ur utvecklingssynpunkt är mängden användare och mångfalden dem emellan. Systemet ska vara möjligt att använda av såväl teknisk och administrativ personal, som av pensionärer utan tekniskt kunnande. Man måste även ta hänsyn till det regelverk som styr valen i Sverige och anpassa systemet så att valen kan genomföras utan risker för fel. Aspekter som vi blir tvungna att ta hänsyn till, som inte tas upp i boken, är att den första systemversionen som släpps ut på marknaden måste vara komplett. Kraven på testning och utveckling innan marknadsföring blir otroligt höga. Konkurrensen blir därmed inte lika och det finns inte samma behov av flertalet versioner och uppgraderingar. Det viktiga blir därmed att fokusera på noggrant utvecklingsarbete som slutar i en robust och tillförlitlig produkt. Definition av användare Användarna av systemet är väldigt varierande vad gäller så väl ålder, kulturell bakgrund, tekniskt kunnande och även syftet med användningen. Vi tar hänsyn till följande när vi utser användarrepresentanter: Två åldersgrupper: år och år Olika kulturell bakgrund Varierande tekniskt kunnande Administrativ personal (rösträkning t.ex.) Teknisk personal (uppdatering av systemet t.ex.) Projektplan Genom hela vår projektplan följer vi bokens teorier. Vi börjar med att bygga en projektgrupp och definiera deltagarna för att sen följa de steg som föreslås av Beyer 3

4 och Holtzblatt. Frångår vi på något sätt bokens modell förklarar vi varför och beskriver vår idé och jämför den med Beyer och Holtzblatt. Projektgruppen Projektgruppen ska innehålla de olika kompetenser som krävs för att skapa ett användbart och tillförlitligt system. Vi definierar följande deltagare: Projektledare Projektledaren har det övergripande ansvaret för projektet. Personen ska se till att tidsplanen följs, att kommunikationen fungerar och att arbetet i gruppen genomförs som planerat. Interaktionsdesigner Interaktionsdesignern ska ha kunskap om hur användaren interagerar med systemet. Personen ska vara med i designarbetet och arbeta nära användare med prototyper och tester för att skapa en fungerande interaktion mellan system och användare. Användbarhetsdesigner/-expert Användbarhetsdesignern ska ha kunskap om hur man designar ett användbart system. Personen ska vara med från början i projektet och bidra med kunskap vid designarbetet. Det är viktigt att användbarhetsdesignern är med från början för att möjliggöra att skapa en så verklig bild av användarkraven som möjligt. Användbarhetsexperten som kan vara samma person som designern ansvarar för att utvecklingen av systemet sker användarcentrerat genom hela projektet. Personen ska ha goda kunskaper om användarcentrerad systemutveckling och ska finnas med i samtliga steg bortsett från själva implementeringen. Programmerare Programmeraren ska implementera systemet efter de modeller och prototyper som tagits fram under utvecklingsprocessen. Programmerarna ska variera i kompetensområde inom programkonstruktion, detta för att samtliga delar av systemet ska implementeras på ett effektivt sätt. De ska under hela projektets gång informeras om läget för att skapa förståelse för designbesluten. Dock ligger huvuddelen av insatsen just under implementeringsfasen. Domänexpert Domänexperten ska bidra med den kunskap som krävs kring hur ett val går till och vilka krav som ställs. Det är viktigt att ha minst en representant som t.ex. kan redogöra för de specifika lagar och regler som gäller för utveckling av ett system som ska stödja en folkomröstning. Det krävs även person som har kunskap om utvecklingen av säkra och tillförlitliga system som ser till att projektet kontinuerligt tar hänsyn till säkerhet och pålitlighet hos systemet. Personerna ska finnas till hands genom hela projektet för att svara på frågor som kan påverka designarbetet. För att skapa vårt system krävs att vi tar hänsyn till olika områden och aspekter. Vi har därför valt att i början av projektet dela upp projektgruppen i mindre delar. Vi skapar en grupp som samlar information från de vanliga användarna, d.v.s. representanter från de som ska rösta med hjälp av systemet. En andra grupp samlar in information som krävs för att anpassa systemet till administrativ och teknisk personal. Dessa kan t.ex. vara personal på valmyndigheten som ska räkna rösterna eller som kontinuerligt ska uppdatera systemet med aktuella uppgifter. En tredje grupp utreder de krav som ställs på systemet vad gäller säkerhet och integritetsskydd för användarna. I varje 4

5 grupp ska det finnas interaktionsdesigners, användbarhetsdesigners och/eller användbarhetsexperter, dock är deras roll inte lika central i gruppen som undersöker säkerhet och integritetsskydd. Domänexperten ska finnas tillgänglig för alla grupperna genom hela projektet. Så här ser gruppen ut: En projektledare Tre användbarhetsdesigners En interaktionsdesigner En användbarhetsexpert Sex programmerare Två domänexperter (val och teknisk säkerhet) Aktiviteter Contextual Design delar upp systemutvecklingen i sju aktiviteter. Vi följer denna modell men lägger mer resurser på vissa delar. Varje aktivitet startar med en input som t.ex. kan vara ett dokument, en modell eller en prototyp. När en aktivitet är avklarad ska den ha resulterat i någon typ av artefakt som kan användas vidare i en senare aktivitet. Varje aktivitet genomförs av förutbestämda projektdeltagare och ska följa en förutbestämd tidplan. När vi framöver skriver hela projektgruppen innefattar det endast en representant från programmerarna. Detta för att göra grupperna lagom stora. Kontextuell utredning Deltagare: Ineraktionsdesigner, användbarhetsexpert, användbarhetsdesigner samt användare. Input: Förberett intervjuunderlag med information om användarna och deras situation. Output: Detaljerade renskrivna intervjuer som används vidare i arbetsmodelleringen. Tidsåtgång: Ca 200 mantimmar. Förberedelse samt bokning av intervjuer, 20 intervjuer á två timmar samt renskrivning á två timmar. Arbetet bör sträcka sig över fyra veckor parallellt med arbetsmodelleringen. För att kunna skapa ett system som passar användaren måste utvecklarna känna till användarnas vanor, deras beteenden, deras miljöer etc. Det enda och bästa sättet att göra det på är att träffa användaren och skapa sig en bild av hur användaren tänker och vilka krav som ställs på systemet. Beyer och Holtzblatt lägger stor vikt vid arbetet med kunden. En stor del av tiden går åt till intervjuer och sammanställningen av dem. Intervjuerna ska bestå av fyra delar: Kontext: Intervjuaren möter användaren i dennes miljö och ser när arbetet utförs. I vårt fall är detta inte möjligt på samma sätt eftersom det inte är några befintliga arbetsuppgifter som ska stödjas av systemet. Vår uppgift är att skapa ett system som stödjer en handling som användarna utför sällan men som ändå måste fungera helt utan problem. Det blir för oss därför viktigare att prata med användaren och ställa frågor. Partnerskap: Denna del av intervjun innebär att intervjuaren och användaren görs till medarbetare. En diskussion förs kring hur systemet bör fungera. Diskussionen ska, enligt boken, pågå samtidigt som arbetet utförs men även här blir det problem i vårt fall eftersom vi inte har något konkret att studera. Användaren får istället bli ombedd att försöka beskriva hur en röstning via ett digitalt hjälpmedel skulle gå till. Intervjuaren kan hela tiden avbryta och ställa frågor och komma med egna idéer för att uppmuntra nya tankesätt kring uppgiften. 5

6 Tolkning: Varje tolkning som intervjuaren gör baseras på fakta från användaren. För att tolkningarna ska vara korrekta krävs det att intervjuaren hela tiden kontrollerar att de stämmer överens med användarens uppfattningar. Fokus: Intervjuaren måste under hela intervjun behålla fokus. Alla som intervjuar användare måste ha samma fokus och intervjuaren ska styra användaren så att samtalet rör väsentliga delar hos systemet. Bokens teorier om hur intervjuerna ska gå till bygger till stor del på att det finns en specifik arbetsuppgift som ska utföras eller ett befintligt system som ska ersättas eller utvecklas. Det är därför svårt för oss att helt hålla oss till denna modell. Våra utvecklare måste lägga stort arbete på att välja ut vilka personer som ska intervjuas och planera intervjuerna väl för att få ut bra underlag. Samtalen blir därmed mer styrande av den som intervjuar än den blir när användaren kan studeras under arbete. Intervjuarna ska i vårat fall leta efter problem med dagens röstningsform och försöka få fram idéer om nya typer av verktyg som användaren kan ha användning av. Frågor måste förberedas och man måste bestämma hur man ska få en användare att på ett bra och insiktsfullt sätt beskriva hur de skulle genomföra en handling som användaren ännu inte har någon erfarenhet av. I och med detta blir användarens roll otroligt viktig senare i utvecklingsfasen då det faktiskt finns något att testa och då det blir möjligt att faktiskt studera användaren. För att bestämma vilka som ska intervjuas och vad som ska tas upp under intervjun, måste gruppen fundera på vad systemet ska stödja, hur systemet kan passa in i användarens tillvaro, vad det huvudsakliga syftet är med användarens handlingar, vilka som är informella hjälpredor och vilka som använder resultatet av handlingarna. Hur intervjun ska gå till tas fram genom att fundera ut var användaren kommer att använda systemet och vilka kulturella och sociala förhållanden som påverkar användandet av systemet. På detta sätt har vi tagit fram våra tre olika grupper av användare som i sig ska innehålla variationer av användare inom gruppen. 20 intervjuer ska genomföras med användare från de olika grupperna. Olika användare har olika roller och använder systemet på olika sätt. Det är också viktigt att man tänker på att man intervjuar användare som är så olika som möjligt. De utvalda användarna ska ha olika tekniskt kunnande, vara av skilda åldrar och komma från olika kulturella områden. Varje intervju ska ta två timmar och innehålla en presentation av intervjuaren, en förklaring av vad som är syftet med intervjun, själva observationen och samtalet samt en genomgång av att intervjuaren har tolkat användaren rätt. Samtliga intervjuer spelas in och anteckningar tas kontinuerligt under samtalen. En intervju genomförs mellan en deltagare ur projektgruppen och en användare. Intervjuerna följs sen upp så att alla gruppdeltagare får ta del av intervjuerna och ge nya perspektiv på innehållet. Tolkning och arbetsmodellering Deltagare: Hela projektgruppen. Input: Intervjuunderlag från den kontextuella utredningen. Output: Sammanställda arbetsmodeller. Tidsåtgång: Ett möte per intervju á två timmar med samtliga deltagare. 9*20*2 =360 mantimmar under fyra veckor parallellt med den kontextuella utredningen. 6

7 Arbetsmodellering Under arbetsmodelleringen tas grafiska arbetsmodeller fram som visar information om användarens sätt att arbeta. Contextual Design använder fem arbetsmodeller som ger olika synvinklar på arbetet och som ska ligga till grund för designen av systemet. Modellerna kan under projektets gång fungera som underlag vid diskussioner med olika användare och mellan olika delar av projektgruppen samt som en strukturerad sammanställning av intervjuerna. Enligt boken ska samtliga fem modeller användas för varje intervju men i vårat fall är detta inte helt nödvändigt. Efter varje intervju hålls ett tolkningsmöte för att gruppen tillsammans ska kunna gå igenom och tolka modellerna. Mötet ska hållas inom 24 timmar efter intervjun. De fem modellerna är: Flödesmodellen representerar den kommunikation och koordination som är nödvändig för att utföra en handling. Det viktiga är att få fram hur olika användare kommunicerar för att få deras jobb utfört. Modellen visar på alla kontakter som en användare tar hjälp av i arbetet. Genom att ta fram modellen försöker man svara på frågor så som: Hur fördelas ansvar? Vilka är de olika roller som antas för att få ett jobb gjort? Vem behöver de hjälp från för att utföra sina arbetsuppgifter? I arbetsflödet visas artefakter som varje telefonsamtal, dokument och e-post som skickas mellan olika personer. Även kommunikation som sker informellt tas med i modellen. Flödesmodellen kan i vårt fall hjälpa oss att ta fram information om hur Sveriges röstberättigade tar reda på kunskap om hur röstningen ska gå till. De ska visa vilken kommunikation som sker och vilka roller som antas och tilldelas av användaren. Den ska också visa på problem med kommunikationen och förståelsen. Sekvensmodellen visar de arbetssteg som krävs för att utföra en handling. Modellen visar vad som utlöser en sekvens av handlingar och det syfte som uppfylls då stegen utförs. De handlingar som människor gör när de utför ett arbete avslöjar deras tankesätt, deras syfte och vad som är viktigt för dem. Att förstå det riktiga syftet är det viktigaste för att förbättra ett arbetssätt. När man väl har förstått syftet kan man omstrukturera arbetssättet på ett sådant sätt att syftet fortfarande uppnås. Sekvensmodellen kan skapas från våra intervjuer genom att gå igenom hur användare har beskrivit vad de skulle kräva av ett system för röstning. Genom att tolka hur användaren skulle använda systemet kan man få fram en sekvensmodell. Det blir inte lika självklart som när man har möjlighet att studera en användare men det är ändå möjligt att ta fram modellen. Sekvensmodeller kan även användas när användare får testa en prototyp längre fram i projektet. Artefaktmodellen visar de artefakter som användaren använder sig av för att utföra en handling. Artefakter är konkreta saker användaren skapar eller använder sig av, det kan till exempel vara en almanacka eller ett dokument. Artefakterna visar vad människor har i åtanke när de utför sitt arbete och hur de tänker på det. En artefaktmodell visar vad våra användare skulle ta till för hjälpmedel för att klara av att rösta i ett val. Det kan vara en röstsedel, en personlig kod, almanacka med egna anteckningar eller information från olika partier t.ex. Modellen ger oss en bra bild av vad systemet ska stödja för artefakter. Kulturella modellen visar influenser på arbetet som har att göra med policy, kultur eller värderingar. Enligt boken ingår i kulturen organisationens formella och informella policy, affärsklimatet skapat av motståndare, arbetsmiljön, självbilden hos 7

8 dem som utför arbetet och de känslor och rädslor skapade av människor eller grupper inom organisationen. Eftersom vi inte skapar ett system för en direkt organisation skiljer sig våra kulturella modeller från dem i boken. Vår projektgrupp måste få fram vilka kulturella och sociala faktorer som kan påverka användningen av systemet men dessa behöver inte ha att göra med ett affärsklimat eller en organisation. Systemet kan istället påverkas av personliga värderingar och kulturella principer. Fysiska modellen visar den fysiska strukturen av arbetsplatsen, så som den påverkar arbetet. Varje objekt eller system måste finnas med i modellen med de begränsningar som den fysiska miljön sätter. Även denna modell skiljer sig i vårt fall. Vi har inga typiska miljöer att kartlägga. Vårt syfte med den här modellen är att skapa en generell bild av den fysiska situation användaren befinner sig i när röstningen ska ske. De här modellerna kommer att skilja sig väldigt mycket mellan våra olika användargrupper. Det är möjligt att skapa en bild av den fysiska miljön kring administrativ och teknisk personal men andra metoder måste användas till de vanliga användarna. Det är ändå viktigt att notera användarens fysiska miljö för att längre fram i processen kunna få fram hur systemet ska nå ut till samtliga användare. Tolkningsfas Tolkningsfasen är ett möte där hela teamet får ta del av arbetsmodeller och erfarenheter. Genom att studera modeller från olika användare får designers en uppfattning om generella arbetssätt. Beyer och Holtzblatt föreslår metoder för att få hela projektgruppen att se generella mönster utan att förlora variationen mellan användarna. Tolkningen innebär att fler får ta del av användardata och komma med nya synpunkter och infallsvinklar. Resultatet blir mer genomarbetade och tydliga arbetsmodeller. En tolkningsgrupp ska inte innehålla fler än 12 personer. Vår projektgrupp består av 14 deltagare. Trots detta väljer vi att genomföra mötet med hela gruppen. Vår motivering till detta ligger i att det är kompetensen från interaktionsdesigner, användbarhetsexpert och användbarhetsdesigner som är väsentlig då modellerna ska sammanställas. Eftersom vi har fem deltagare med denna kunskap vill vi inte dela upp dem i två grupper. Vi har valt att endast en programmeringsansvarig ska delta på mötet. Denna kan sen informera samtliga programmerare om läget och längre fram dela upp arbetet mellan dem. De båda domänexperterna behöver inte heller nödvändigtvis vara med under mötet utan kan ta del av modellerna vid ett senare tillfälle. Under tolkningsmötet tilldelas gruppdeltagarna olika roller. Anledningen till detta är att mötet ska hålla en fast struktur och att alla ska medverka aktivt. Följande roller definieras: Intervjuare: Personen som har gjort intervjun tar denna roll. Intervjuaren berättar om intervjun och går igenom de modeller som tagits fram ur data från intervjun. Det är viktigt att intervjuaren berättar i kronologisk ordning så att inga delar förbises. Intervjuaren ska inte komma med egna åsikter utan de ska komma från övriga gruppdeltagare. 8

9 När det kommer till att bygga om arbetsmodellerna så faller det naturligt att intervjuaren arbetar med den fysiska modellen, eftersom han är den enda i gruppen som har varit på plats. Arbetsmodellerare: Arbetsmodellerarna ritar upp arbetsmodeller på blädderblock allt eftersom intervjuaren berättar. Det kan finnas två modellerare, En som tar hand om flödesmodellen och den kulturella modellen och en annan som tar hand om sekvensmodellen. När artefakter påträffas tas de om hand och diskuteras gemensamt mellan modellerarna. Tanken är att modellerarna ska arbeta fritt under fasen och att övriga gruppdeltagare får komma med kommentarer om de har åsikter kring hur modellerna byggs. Registrerare: Alla anteckningar som tas skrivs ner av registreraren på en stor LCDskärm. Placeringen av skärmen ska ske så att alla har möjlighet att se den, t.ex. på en vägg. Under mötet ser deltagarna vad som har sagts och kan komma med ändringar och nya åsikter. Varje viktig observation och åsikt om modellerna som byggs upp ska registreras för att inte tappas bort. Medlare: Medlaren ser till att mötet flyter på och att tempot hålls uppe. En talarlista kan användas under mötet och det är då medlaren som ansvarar för denna. Egna åsikter och kommentarer ska hållas nere, men inte alls undvikas helt, för att fokusera på att mötet fortskrider som det ska. Ordningsvakt: Ordningsvakten ser till att mötet inte spårar ur och att alla håller sig till ämnet. Mötet ska vara fokuserat på nuvarande tankar och idéer och inte gamla erfarenheter. Om mötet ändrar fokus ska ordningsvakten säga ifrån och föra mötet tillbaka på rätt spår igen. Ordningsvakten deltar i mötet och kommer med åsikter och fungerar därmed även som en vanlig deltagare. Deltagare: Resten av projektgruppen är deltagare. De ska komma med nya idéer och kommentarer och se till att modellerarna bygger upp bra modeller. De måste även kontrollera registrerarens noteringar så att dessa stämmer överens med mötets innehåll. Sammanställning Deltagare: Användbarhetsexperter, Användbarhetsdesigners samt Interaktionsdesginers. Input: Intervjuunderlag samt utvecklade arbetsmodeller. Output: Affinitydiagram samt sammanställda arbetsmodeller. Tidsåtgång: En dag per modell samt en dag för affinitydiagrammet. 5*6*8 = 240 mantimmar under två veckor. När arbetsmodellerna är sammansatta måste projektet arbeta med att få en tydlig och korrekt bild av vad som är viktigt hos systemet. Alla anteckningar från tolkningsmötena gås igenom och man skapar en möjlighet att se de huvudsakliga faktorerna som påverkar användarens handlingar och de problem som kan uppstå. Utmaningen är att designa ett system för en population men ändå uppfylla de krav som enskilda användare ställer. Sammanställningen ger en sammanhängande förståelse som är baserad på verklig användardata. Under sammanställningen skapas affinitydiagram och sammanställda arbetsmodeller. Diagrammen och modellerna fungerar som en bra grund för förståelse och kommunikation längre fram i projektet. 9

10 Affinitydiagram Syftet med ett affinitydiagram är att generera nya insikter om användare och hur de löser problem. Diagrammet byggs upp via induktion, egna teorier får aldrig ligga som grund. Ett affinitydiagram visar användarproblemens omfång. Det tydliggör på ett och samma ställe de problem, de frågeställningar och de huvudsakliga artefakter som styr arbetet. Arbetsgången är som följer: 1. Dela upp de noteringar som har gjorts under mötena och notera dem på enskilda lappar. 2. Sätt upp lapparna på väggen och gruppera dem efter likheter. 3. När grupperna når en storlek som blir svårhanterlig ska dessa generaliseras och grupperas ytterligare. 4. När alla lapparna är placerade på väggen är det dags att dela upp dem i olika grupper och undergrupper. Resultatet beskriver hur noteringarna hänger ihop och ger en bild av de viktiga delarna. Antalet noteringar ska i slutet ska hamna på ca 1500 stycken och det ska ta en dag att skapa ett affinitydiagram. Ett liknande diagram i vårt fall ska ge information om de olika användarna och vilka roller de kan tänkas anta. En och samma användare kan anta olika roller i diagrammet. Egenskaperna hos de olika rollerna ger en uppfattning om vilka krav som ställs på systemet. Sammanställning av arbetsmodeller I detta skede sammanställs de arbetsmodeller som togs fram under tolkningsmötena. Arbetsmodellerna från mötena beskriver varje enskild användare och ska i sammanställningen föras samman till modeller som är gemensamma för samtliga användare. Samma fem modeller används som under arbetsmodelleringen. Flödesmodellen Flödesmodellen visar vilka användarna är, vad de gör och hur de interagerar med varandra. Modellen beskriver roller som kan antas av flera användare och kommunikationen mellan rollerna blir synlig. Första steget är att komponera en lista över de ansvarsområden varje person har. Man går sen igenom listan och definierar möjliga roller bland ansvarsområdena. De kvarstående områdena placeras in hos varje roll och kommunikationen mellan de olika rollerna beskrivs. Slutligen jämför man modellen med de ursprungliga modellerna så att man inte förbisett användare eller ansvarsområden. En flödesmodell kan på många sätt vara användbar i vårat fall. Modellen kan ge en tydlig bild av våra olika roller samt kommunikationen dem emellan. Användare från de tre grupperna använder systemet på olika sätt och kommunicerar olika både med systemet och med andra användare. Sekvensmodellen Sekvensmodellen visar arbetsstrukturer och arbetsstrategier, därmed ger den värdefull information vad som används, och i vilken ordning, för att utföra en viss handling. Modellen visar även om en uppgift är för komplex och kan underlättas av ett nytt system, detta är viktigt i vårt fall eftersom det är ett helt nytt system som ska skapas. Det första som görs vid sammanställningen är att leta igenom alla sekvensmodeller efter de sekvenser i arbetet som leder till samma uppgift. Sekvenserna letas sen 10

11 igenom för att identifiera aktiviteter i arbetet. För varje aktivitet ska meningen med just den aktiviteten belysas och beskrivas. Artefaktmodellen Den sammanställda artefaktmodellen visar hur människor organiserar och strukturerar sitt dagliga arbete. Varje artefaktmodell sorteras in i en grupp efter vilken roll den spelar i arbetet. Där identifieras gemensamma delar av varje artefakt samt avsikten och användningen med just denna. De strukturer och användningsområden som liknar varandra tas fram för varje del och sedan byggs en ny artefakt som visar alla gemensamma delar, uppgifter och avsikter. Fysiska modellen Den sammanställda fysiska modellen visar strukturen av den fysiska miljön som berör arbetet. Modellerna grupperas efter den plats de representerar. Enligt boken gås modellerna igenom och liknande strukturer identifieras vartefter sakers placering markeras. De förflyttningar som användaren gör på arbetsplatsen eftersöks och en ny gemensam modell byggs upp med förflyttningarna markerade. På grund av vårt projekts natur blir denna modell lite annorlunda eftersom det inte finns någon specifik arbetsplats som kan identifieras. Vår fysiska modell ska istället ge en bild av den generella miljön där användaren befinner sig. Den ska i och med det bidra till en systemdesign som är lättillgänglig för samtliga användare. Kulturella modellen Den kulturella modellen framhäver gemensamma värderingar, motsättningar och kulturella influenser. De gemensamma aspekterna som genomsyrar användargrupperna blir synliga i modellen. Informationen från varje användares kulturella modell katalogiseras och samma sak görs med de gruppinfluenser som begränsar arbetet. Influenserna från de individuella modellerna grupperas och den slutliga modellen ritas upp vilken visar samtliga unika influenser. Dessa kan i vårt fall vara olika kulturella och sociala värderingar som påverkar sättet användaren väljer att rösta på. Omstrukturering av arbetet Deltagare: Hela projektgruppen Input: Affinitydiagram samt sammanställda arbetsmodeller Output: En vision av det nya arbetssättet beskrivet i ett antal storyboards. Tidsåtgång: 2240 mantimmar under 4 veckor I denna del av projektet så ska affinity diagram samt de sammanställda arbetsmodellerna som beskriver arbetssättet idag, analyseras och förbättras till en vision av ett nytt system med nya bättre arbetssätt för användarna. 1) Denna process inleds med att affinity diagrammet samt respektive arbetsmodell gås igenom och omformuleras till nya sammanställda modeller med förändringar och förbättringar bättre anpassade till de förutsättningarna och krav som ställs på det nya systemet. Den sammanställda flödesmodellen beskriver de roller som människor spelar och hur dessa kan länkas till individer. Dessutom beskrivs flödet mellan dessa, vilket kan visa på kommunikationsmönster och andra problem i arbetet. Det är viktigt att förenkla skiftandet mellan roller genom att t.ex. eliminera överflödig 11

12 datainmatning och använda sammanhängande gränssnitt för olika roller. Dessutom bör systemet undvika att personer blir överbelastade med för många roller genom att automatisera eller ta bort roller. För vårt system kan denna modell hjälpa till att visa på situationer där väljarna måste spela flera roller, som t.ex. då väljaren samtidigt som de är väljare också måste hämta information för att förstå hur en viss sekvens ska utföras. Den sammanställda kulturella modellen visar på vilka värderingar, attityder, begränsningar och maktförhållanden som råder mellan människor och grupper i anknytning till systemet. Eftersom att modellen mest fokuserar på känslor ger inte denna några strukturella design råd, utan istället riktlinjer för vilka värderingar som bör stödjas samt vilka begränsningar som måste respekteras. Här är det i vårat fall viktigt att försöka förstå vilka värden och attityder som finns i de olika användargrupperna och deras inställning gentemot det nya sättet att rösta. För de grupper som är negativt inställda till det nya arbetssättet kan modellen visa på vad som skapar denna inställning och vilka värden som man bör sträva efter att förmedla. Det är viktigt att förstå att vissa värderingar som användargrupper har inte går och heller inte bör förändras. Här måste modellen istället bemöta dessa negativa värden genom att införliva nya positiva värden. Den sammanställda fysiska modellen är som tidigare nämnts svår att applicera på användarna av vårat E-val system. Anledningen är att den fysiska miljön skiljer sig så kraftigt från användare till användare. Det som här kan vara intressant är att försöka återspegla arbetssättet för valet på ett liknande sätt i det nya datasystemet. T.ex. att låta det som är viktig information på pappersvalsedeln bli lika centralt på datavalsedeln. Den sammanställda sekvensmodellen innebär att olika arbetsmoment som beskriver en sekvens analyseras och ur detta identifieras ett primärt mål eller orsak till varför arbetsuppgiften gjordes i det gamla arbetssättet. Dessutom identifieras delmål som nås på vägen mot det primära målet. Om det primära målet med arbetsuppgiften fortfarande är relevant arbetas det fram en ny sekvens av moment för att nå detta mål, där delmål som inte längre fyller någon funktion tas bort. Steg kan tas bort eller automatiseras fritt så länge det primära målet uppfylls. Det är dock viktigt att vara uppmärksam på att det kan existera sekundära mål som parallellt det primära målet kan vara viktiga på sitt sätt. Dessa får inte tas bort vid förändringen av sekvensmodellen. I vårat system är det extra viktigt att inte det primära målet, att kunna rösta på ett så enkelt sätt som möjligt, försvinner bland design förslag och speciella UI lösningar. Den sammanställda artefaktmodellen behandlar de hjälpmedel som användaren använder sig av då denne utför sin arbetsuppgift. Då man utvärderar dessa hjälpmedel och utformar den nya sammanställda modellen bör utvecklarna sträva efter att hjälpmedlen utför sin uppgift på ett så direkt sätt som möjligt. Ersätts ett hjälpmedel är det också viktigt att det nya hjälpmedlet verkligen stöder alla de funktioner som det gamla gjorde. 12

13 2) Nästa steg i denna del av arbetet är att skapa en vision, vilket föregås av en brainstorming, där en grund för det fortsatta visionsarbetet skapas. Visionsarbetet går ut på att startpunkterna som tagits fram vid brainstormingen utvecklas till olika historier som beskriver hur det nya arbetssättet skulle kunna se ut. Under visionsarbetet bör en person vara ansvarig för att skriva ner förslagen och uppmuntra gruppen till att komma med nya förslag och en annan ansvara för att gruppen håller sig till ämnet som för närvarande diskuteras. När alla idéer för en viss startpunkt är slut påbörjas en ny tills gruppen nått minst tre eller fyra alternativa visioner. Utifrån dessa separata visioner skapas sedan en gemensam vision baserat på det bästa från varje genom att gruppens medlemmar listar positiva och negativa aspekter på varje vision. Slutligen dokumenteras arbetet genom att den nya kombinerade visionen ritas upp. 3) För att ta fram hur visionen ska implementeras görs storyboards som också sätter krav på systemet. Ett storyboard visar hur en specifik uppgift i det nya systemet ska utföras genom att beskriva aktörer för denna uppgift och interaktionen dem emellan. För varje uppgift arbetar ett par i gruppen fram ett storyboard förslag som sedan revideras av de övriga gruppmedlemmarna. Design av användarmiljön Deltagare: Användbarhetsexperter, interaktionsdesigners och användbarhetsdesigners. Input: Ett antal storyboards beskrivande det nya arbetssättet. Output: En strukturerad User Environment Design. Tidsåtgång: 600 mantimmar under 3 veckor. Tanken med denna del av utvecklingsarbetet är att strukturera de olika storyboarden så att de hamnar i ett sammanhang i förhållande till varandra. Anledningen till att detta är en viktig del i designprocessen är för att det bidrar till att skapa ett naturligt sammanhang för det slutgiltiga systemet och därmed för användarnas arbete. Att varje delmoment hänger ihop sekventiellt på ett naturligt sätt är redan ordnat genom storyboarden, men nu gäller det att knyta ihop dessa till en enhetlig struktur. För att skapa en sådan struktur används i boken en teknik som kallas User Environment Design (UED), i vilken fokus ligger på att beskriva hur olika arbetsuppgifter förhåller sig till varandra ungefär som rummen i ett hus. Tanken med UEDn är att den ska beskriva alla de möjliga flöden som en användare kan förflytta sig i systemet. En fördel med UED är att det inte finns någon möjlighet att designa något gränssnitt, vilket innebär att allt fokus kan läggas på strukturen av systemet. I UEDn har olika arbetsuppgifter i systemet (de olika storyboarden) delats upp så att var och en av dessa representerar en så kallad fokusyta, vilken i sin tur innehåller ett antal funktioner som krävs för att uppfylla syftet, arbetsobjekt, hinder samt länkar till andra fokusytor. Fokusytans namn är tänkt att beskriva dess syfte, vilket betyder att om detta syfte inte kan beskrivas i en mening är strukturen dålig och fokusytan bör delas upp i flera mindre. En länk från en fokusyta till en annan representeras av en pil, medan en dubbel linje mellan två fokusytor innebär att då användaren utför ett arbete i en av fokusytorna behöver denna samarbeta med den andra. Funktionerna är av två olika typer: funktioner som styrs av användaren samt funktioner som styrs av systemet. Arbetsobjekten är de saker som användaren ser och manipulerar i fokusytan, medan hinder beskriver implementeringsbegränsningar för fokusytan. 13

14 UED avslutas med en genomgång av hela designstrukturen, i vilken olika principer för god design testas mot lösningarna som implementerats. Anledningen till detta steg är att det är lätt att förstöra en bra design allt eftersom fler storyboards tillkommer och systemet växer. Vid genomgången undersöks framförallt om fokusytorna hänger samman på ett naturligt sätt och om strukturen stödjer arbetet som användarna ska utföra. Implementeringen av ett stort system måste delas upp på olika team. Uppdelning av arbetsuppgifterna skapar en balansgång mellan att få hela systemet sammanhängande och att få respektive grupps arbete sammanhängande. UED är här användbart eftersom att det visar på vilka delar av systemet som integrerar och därmed vilka subteam som måste samarbeta. På så sätt hjälper de team att inte överfokusera på sin specifika uppgift. Dessutom hjälper det till att fördela arbetsuppgifterna mellan teamen så att varje team får sammanhängande delar av systemet. Prototyping Deltagare: Interaktionsdesigner, användbarhetsdesigners, användbarhetsexpert, användare. Input: User Environment Designen samt storyboards. Output: En färdig prototyp redo för implementering. Tidsåtgång: 1200 mantimmar under 6 veckor. Prototyping är det sista designsteget innan det är dags för programmerarna att implementera systemet och de verkliga användarna får nu en mycket viktig roll genom sin möjlighet att påverka utformningen av systemet. Arbetet sker iterativt genom att prototyper av systemet utvecklas, testas av användarna och sedan modifieras efter de resultat som testen visade. För att undvika arbete i onödan är det viktigt att en första enkel prototyp tas fram så tidigt i processen som möjligt, så att utvecklarna kan få feedback från användarna och svar på om de är på rätt väg. I ett projekt av våran storleksordning bör en första prototyp vara klar efter två veckor. De första prototyperna bör vara ritade på papper, eftersom att denna prototyputveckling är snabb, enkel, billig och ger upphov till förändringar undertiden testet fortlöper. Dessutom förstår användarna att pappersprototyper inte är det färdiga systemet, vilket gör det enklare för användaren att kritisera systemet. För att försäkra sig om att systemet kan användas av alla olika typer av användare är det viktigt att testa varje prototyp på personer från olika användargrupper samt att dessa inte varit delaktiga i den tidigare utvecklingsprocessen. Själva testningen av prototypen mot en användare bör vara okomplicerad och ska uppmuntra användaren till att våga kritisera och kommentera olika design val. Det är viktigt att testledaren kan tolka hur användaren upplever systemet och anteckna detta istället för att tillrättavisa en användare som tolkar en viss detalj annorlunda än hur den är tänkt att fungera. Anledningen till detta är att det är användaren som i slutändan ska använda systemet och uppfattar denne systemet på ett visst sätt är det så det bör fungera. Efter att den första prototypen testats efter två veckor ska ytterliggare fyra prototyper testas under de återstående fyra veckor som denna del av utvecklingsarbetet fortlöper. Efter varje testningsomgång bör hela gruppen samlas och ta del av användarnas synpunkter för att sedan omarbeta prototypen efter dessa riktlinjer. Om det under testningen framkommer fel som beror på felaktig struktur ska gruppen avbryta 14

15 gränssnittsdesignen och gå tillbaka och omarbeta UEDn, då det är viktigt att hålla isär problem som berör strukturen och problem som berör användargränssnittet. Vid utformningen av gränssnittet till prototyperna är det viktigt att sammanhanget i strukturen som har arbetats fram vid UED processen inte förstörs. Ett viktigt steg för att åstadkomma detta är att gränssnittet utformas enhetligt så att användaren kan följa ett liknande gränssnittsmönster genom hela systemet. Det är också viktigt att interaktionen med gränssnittet känns naturlig för alla typer av användare vilket gör att detta i vårat fall måste vara väldigt generellt implementerat. Tidplan Aktivitet/Vecka Kontextuell utredning Tolkning och arbetsmodellering Sammanställning Omstrukturering av arbetet Design av användarmiljön Prototyping 15

16 Diskussion Efter att ha studerat processen Contextual Design i anslutning till projektet för E-val har vi under arbetets gång gjort vissa reflektioner angående våran syn på metodens användbarhet och dess för- och nackdelar. I det stora hela anser vi att processen är ett användbart hjälpmedel vid systemdesign i projekt med mycket resurser både vad gäller tid, pengar och arbetskraft. För lite mindre projekt tror vi dock att processen kan bli lite för tidskrävande och kostsam att genomföra i sin helhet. I dessa fall skulle ett alternativ kunna vara att minska ner på omfattningen av designarbetet, utan att förlora de centrala delarna i processen. Grunden i designprocessen, vilken också är dess stora styrka, är den omfattande fokuseringen på användarna och dess arbetsuppgifter och miljö. Att genom hela processen låta faktisk användardata avgöra designbeslut ger inte bara ett bättre användaranpassat system utan bidrar också till att beslut inom utvecklingsgruppen kan göras på ett mer konsekvent sätt, vilket medför att enskilda personers åsikter inte får utrymme att i alltför stor grad få styra utvecklingsarbetet. En annan stor fördel med Contextual Design är att den separerar de olika delarna i designprocessen så att full fokus kan ägnas åt det centrala i varje steg i processen utan störande moment från andra delar i processen som har helt andra krav. Detta medför också att risken för att systemet blir feldesignat minskar, genom att respektive steg arbetas igenom noggrant och iterativt i flera steg. Utan ett sådant arbetssätt finns en risk att det i den avslutande implementeringsprocessen upptäcks ett fel som går tillbaka ända till själva den strukturella uppbyggnaden av systemet, vilket kan få till följd att hela systemet måste omdesignas. Nackdelar med designprocessen är som tidigare nämnts att den är mycket tids- och resurskrävande, samt att processen saknar en tydlig kravspecifikation från användarna och andra intressenter som i vårat fall staten. Utan en sådan specifikation blir det också svårt att kontrollera om systemet verkligen uppfyller sitt mål, och följaktligen svårt att visa för en beställare vad som verkligen uppnåtts. Boken koncentreras till stor del på utveckling av system som ska ersätta ett redan befintligt system eller som ska stödja en tydlig arbetsuppgift. Teorierna baseras mycket på att användaren befinner sig i en bestämd kontorsmiljö och styrs av en organisation. I vårt fall har detta varit en anledning till att vissa delar har blivit svårt att applicera på vårt system. En annan brist med Contextual Design är att den inte separerar användaren från kunden i de fall dessa är olika personer. Vad kunden har för krav på systemet och vad användaren vill ha behöver inte stämma överense och i detta fall är det den faktiska kunden som har sista ordet. Självklart är det användaren av systemet som ska följa med genom designprocessen, men i vissa fall kanske dessa har krav som kunden inte är beredd att betala för. Boken ger en intressant och enligt oss användbar modell som kan följas vid utveckling av ett användbart system. Dock finns det, som vi nämnt, många brister som främst har att göra med tid och resurser. Vissa av delarna kan nog sättas ihop och ändå få fram en bra process som leder till ett användbart system. 16