Let's Walk, (interaktionsdesign) från början till slut

Transkript

1 Let's Walk, (interaktionsdesign) från början till slut Alexander Pettersson 20 januari 2012 Examensarbete i Datavetenskap, 20 poäng Handledare på CS-UmU: Lars-Erik Janlert Examinator: Jerry Eriksson Umeå Universitet Instutionen för Datavetenskap UMEÅ Sverige

2

3 i Sammanfattning Många interaktiva produkter som konstrueras idag är inte framtagna mot en specik målgrupp och hur de interagerar med produkten. Detta examensarbete följer designprocessen i utvecklingen av webbapplikationen Let's Walk. I designprocessen har användare av webbapplikationen identierats, prototyper har utvecklats och en interaktiv version har utvärderats. Let's Walk webbapplikationen är ett fungerande system som används för att administrera Let's Walk, en motionstävling företag emellan. Experter och användare har varit inblandade för att utvärdera high-delity prototypen av webbapplikationen Let's Walk. Resultatet av utvärderingarna visar att det är mycket betydelsefullt att involvera användare och experter i en designprocess när det gäller att hitta användbarhetsproblem i ett gränssnitt. Detta har lett till synpunkter i hur man kan utvecklar framtida versioner av Let's Walk systemet. Let's Walk, (interactiondesign) from start to nish Abstract Many interactive products constructed today is not produced towards a specic target audience and how they will interact with the product. This master's thesis follows the designprocess in the development of the Let's Walk webapplication. In the designprocess has users of the webapplikation been identied, prototypes developed and an interactive version has been evaluated. The Let's Walk webapplication is a fully working system used to administrate Let's Walk, an exercise competition between companies. Experts and users have been involved to evaluate the Let's walk high-delity webapplication prototype. The result of the evaluation shows that involving users and experts in the designprocess is very important when nding usabilityproblems in an interface. It has lead to comments of how to develop future versions of the Let's Walk system.

4 ii

5 Innehåll 1 Inledning Bakgrund Disposition Problembeskrivning Uppgift Scenario Mål Omfattning Metoder Interaktionsdesign Diskussioner om interaktionsdesign Användbarhet Användarupplevelse Diskussioner om användbarhet och användarupplevelser Designprinciper Diskussioner om designprinciper Utvecklingen genom en interaktionsdesign Identiera behov Diskussioner om att identiera behov Konceptuella modeller Aktiviteter Diskussioner om konceptuella modeller Design och prototyper Prototyper Diskussioner om prototyper Utvärdering Utvärderingsparadigm Quick and dirty utvärdering iii

6 iv INNEHÅLL Användartester Fältstudier Förutsägande utvärdering Heuristisk utvärdering Tio heuristiska användbarhetspunkter Diskussioner om användbarhets heuristiker DECIDE Diskussion kring utvärdering Tekniker Iaktta användare Tänka högt tekniken Diskussion om tekniker Prestation och resultat Teknisk beskrivning Systembeskrivningar och krav Identiera användare Low-Fidelity Prototyper Resultat av low-delity prototyperna High-Fidelity Prototyper Utvärdering Skärmdumpar Analys från utvärderingarna Slutsatser Framtida arbeten Tack 31 Referenser 33 A Frågor som använts i utvärderingen av användargränssnittet 35 B Användningsfall 37 C Synpunkter från utvärderingen 43

7 Figurer 5.1 En low-delity prototyp av login webbsidan En low-delity prototyp av menyn Logga in sidan för Let's Walk systemet Webbsida för att skapa nya projekt Webbsida för att skapa nya stationer och sträckor Webbsida för att ladda upp och skapa statistik v

8 vi FIGURER

9 Kapitel 1 Inledning Många datorprogram, mobiltelefoner och dvd-spelare används dagligen av tusentals användare. Men hur användbara är de? Hur många produkter är enkla och intuitiva att använda? Varför ska vissa produkter leda till att du som användare känner frustration när du interagerar med dem? Produkterna har nog inte tagits fram med användaren i åtanke och hur en tilltänkt användare bör interagera med dem. De kan fungera bra ur ett tekniskt perspektiv men inte från användarens perspektiv [15]. Alla inser bristen på användbarhet när de stöter på ett problem vid en interaktion. De ser det inte som ett användbarhetsproblem men det är vad det är, när till synes enkla uppgifter är svåra och när det är svårt att nå det avsedda målet. Systemutvecklare tenderar att starta utveckling innan design och standard har diskuterats vid framtagande av webbapplikationer. Detta resulterar i användbarhetsproblem och ökade kostnader. Pressmans studie 1992 rapporterar om att kostnaden för förändringar i utvecklingsfasen är 1,5 till 6 gånger större än i konstruktionsfasen och efter en produktlansering är den 60 till 100 gånger större [2]. Utformningen bör fokusera på användarupplevelser och utvärderingar av webbapplikation bör involvera användare. Detta kommer att leda till en framgångsrik och eektiv webbapplikation [3]. Användbarhet avfärdas ofta som onödiga kostnader i webbprojekt som görs med snäva tidsplaner och med begränsade resurser, men de bör tas med i designprocessen. Inriktningen bör vara att utveckla en produkt som hjälper användare att uppnå sina mål vid interaktion med den. För att uppnå detta bör en detaljerad plan för interaktionsdesign följas. Interaktionsdesignplanen består av att: identiera behov och fastställa krav, utveckla designalternativ, implementera interaktiva versioner och utvärdera dem [5]. Viktiga frågor vid utveckling av en webbapplikation är att identi- era användare, klassicera användare, identiera typ av webbapplikation att producera, identiera innehåll och klargöra om begränsningar nns. Webbapplikationens design kan vara mycket olik beroende på målgrupper och vilken typ av webbapplikation som produceras. Användarklassicering görs för att få en förståelse för framtida användare och deras bakgrund och här grupperas användare med liknande erfarenheter [1]. 1.1 Bakgrund Let's Walk är ett projekt inriktat på hälsa och friskvård och är utvecklat på it-företaget Explizit i Skellefteå. Projektets syfte är att få er människor delaktiga i friskvård på ett enkelt och behagligt sätt. Projektet går av stapeln mellan 5-20 maj 2007 och är en tävling mellan företag där anställda motionerar Broarna Runt så ofta som möjligt 1

10 2 Kapitel 1. Inledning under projektets gång. Det företag med est registrerade kilometer/sysselsatta under projekttiden belönas med ett friskvårdspris. Denna rapport presenterar designprocessen vid utvecklingen av Let's Walk systemet. 1.2 Disposition Nedan följer en beskrivning av rapportens innehåll. I kapitel 2 presenteras problembeskrivning, mål, omfattning och metoder som använts i detta examensarbete. Kapitel 3 är det avsnitt där den teoretiska delen presenteras med begrepp inom interaktionsdesign. Kapitel 4 är ett annat teoriavsnitt som presenterar designprocessen utifrån hur man identierar användarnas behov, utvecklar designalternativ, bygger interaktiva prototyper och hur man utvärderar ett system. I kapitel 5 presenteras en systembeskrivning, en teknisk beskrivning och de krav som nns samt hur användare har identierats. Vidare i detta kapitel nns low-delity prototyper i form av skisser, high-delity prototyper samt resultat från utvärderingar och analyser. I kapitel 6 presenteras slutsatser och framtida arbeten i Let's walk systemet.

11 Kapitel 2 Problembeskrivning Detta kapitel beskriver projektets uppgift, projektets mål och vilka metoder som har använts vid designen av Let's walk systemet. 2.1 Uppgift Idag är datoranvändandet stort bland människor där datorer nyttjas dagligen antingen på jobbet eller i hemmet. Detta måste leda till att utvecklare och designers riktar sin utveckling mot användare av systemen. Fokusering på användbarhetsfrågor och identiering av framtida användare av systemen är nödvändiga med en ökad konkurrens inom programvaruutveckling. Uppgiften i detta examensarbete består i att designa och utveckla en webbapplikation för att administrativa Let's walk projektet. Målet är att följa designprocessen vid utvecklingen av systemet, allt för att försöka konstruera ett system för användaren. Systemet som ska utvecklas är en webbapplikation för att administrera Let's Walk projektet. Let's walk systemet ska bestå av följande funktioner: Skapa projekt: En administratör ska kunna använda systemet för att skapa ett projekt med startdatum och slutdatum. Skapa stationsnamn: Administratören ska kunna namnge de stationer som ska nnas med i projektet. Skapa sträcka: En sträcka med namn, avstånd, minimumtid och maxtid ska kunna skapas mellan stationer. Registrera företag: Det ska vara möjligt att skapa företag som ska medverka i Let's walk tävlingen Scenario Administratören av webbapplikationen är ansvarig för att sätta upp projektet på ett korrekt och riktigt sätt. Uppgifterna består i att sätta upp datum då projektet kommer att äga rum, registrera företag och deras anställda, skapa stationer och sätta ut avstånd mellan stationer samt att ta hand om insamlad data från de handhållna streckkodsläsarna. Varje företagsanställd identierar sig med ett ID-kort med en streckkod. Vid friskvårdsaktiviteter används ID-kortet vid startstationer och slutstationer där funktionärer med 3

12 4 Kapitel 2. Problembeskrivning en handhållen streckkodsläsare står placerad. Efter varje dag är det funktionärernas ansvar att docka den handhållna streckkodsläsaren för att kopiera de registrerade resultaten till en dator. Let's Walk webbapplikationen används sedan för att ladda upp resultaten till en central databas. Resultaten kan följas under projektets gång varje dag på och i tidningen Norra Västerbotten under helger. I bilaga A nns ytterligare funktioner beskrivna. Där presenteras användningsfall för att beskriva systemet och dess funktioner. 2.2 Mål Målet med detta examensarbete är att designa och implementera en webbapplikation med fokus på användbarhet för att administrera Let's walk projektet. Webbapplikationen ska vara enkel att lära sig och använda för administratörer. Delar från den presenterade teoridelen om interaktionsdesign, designprinciper och utvärderingsparadigm kommer att användas vid utvecklingen av webbapplikationen. Användare och experter kommer att delta i utvärderingen för att söka efter användbarhetsproblem med webbapplikationen. 2.3 Omfattning Uppsatsen är begränsad till ett teoriavsnitt om hur man utvecklar ett system med fokus på användbarhet och en praktisk del med genomförandet av Let's walk systemet. Diskussioner har gjorts efter teoriavsnitt för att ge kommentarer och reektioner kring det som presenterats med fördelar och nackdelar på de presenterade materialet. Den praktiska delen med genomförandet av Let's walk systemet har följt designprocessen som presenteras i teoriavsnittet med hur man identierar användare, bygger prototyper och utvärderar dem. En medarbetare på Explizit har implementerat streckkodsläsare Argox-PT12 och utfört beräkningar av statistiken. Därför har användbarhetsaspekter av streckkodsläsare inte analyserats och diskuterats. Ingen iteration har gjorts i designprocessen vid utvecklingen av Let's walk systemet på grund av tidsbegränsningar. Fler iterationer skulle ha utförts om mer tid hade funnits. 2.4 Metoder Designprocessen som presenteras i teoriavsnittet har använts vid utvecklingen av Let's walk systemet med hur man identierar användare, bygger prototyper och utvärderar dem. Heuristisk utvärdering och en tänka-högt teknik har använts vid bedömningen av high-delity prototypen och skisser har använts för low-delity prototyper. High-delity prototypen implementerades i C# i Visual Studio 2005 och en MySQL-databas användes för att lagra data.

13 Kapitel 3 Interaktionsdesign Detta kapitel är det första kapitlet av två som presenterar den teoretiska delen av detta examensarbete, processen i hur man utvecklar ett användbart och intuitivt användargränssnitt. Varje avsnitt kommer att presentera olika delar i designprocessen och efter varje del är en diskussion med för att ge kommentarer och reektioner kring ämnet. Kapitlet börjar med olika interaktionsdesigndelar och sedan följer processen för att utveckla användbara användargränssnitt. Interaktionsdesign ses idag som en viktig del vid utveckling av interaktiva produkter, och med en ökande skara av interaktiva produkter på marknaden är det viktigt att ha en produkt som är lätt och eektiv att använda. En produkt som inte är lätt och eektivt att använda kan vara svår att sälja på marknaden. Interaktionsdesignprocessen kan delas in i fyra grundläggande delar: [15]: 1. Identiera behov och krav. 2. Utveckla designalternativ som uppfyller kraven. 3. Bygga interaktiva versioner. 4. Utvärdera produkten. De fyra delarna i interaktionsdesignprocessen bör upprepas under hela tiden vid utveckling av en interaktiv produkt där utvärdering ses som den viktigaste delen av alla fyra. Utvärderingen är till för att försäkra sig om att produkten uppfyller kraven som är uppsatta samt att produkten är lätt att använda ur en användares perspektiv. En utvärdering görs där användare deltar i hela designprocessen. Det nns många sätt att utföra en utvärdering och den kan bestå av att: 1. Observera användare. 2. Prata med användare. 3. Använda testanvändare. 4. Mäta prestanda hos användare. 5. Använda frågeformulär. 6. Involvera användare vid utveckling av produkten. 5

14 6 Kapitel 3. Interaktionsdesign Användare har olika behov och därför är det viktigt att involvera och förstå dem. Ett tillägg till de fyra delarna i designprocessen som presenterats tidigare: 1. Involvera användare i utvecklingen av en interaktiv produkt. 2. Identiera de objektiva målen för användbarhet och de subjektiva målen för användarupplevelser tidigt i början av ett projekt. 3. Iterera genom de fyra delarna i designprocessen [15]. Gränssnittet hos en interaktiv produkt är det som en användare ser i vad en produkt är kapabel till att utföra. Det används för att förstå produktens koncept och för att utföra det tilltänkta arbete som användaren utför. Gränssnittet är långt ifrån bara en fråga om layout och utseende, gränssnittet visar för användaren vad systemet är och vad det gör. Gränssnittsdesign handlar mer om användare och deras uppgifter än om utseendet på menyer och ikoner. Utvecklare måste ha framtida användare i åtanke och förstå deras behov [6]. 3.1 Diskussioner om interaktionsdesign En produkt som sticker ut från andra produkter och som är lätt att använda och är användarvänlig är förmodligen ett bra argument när man ska marknadsföra och sälja en produkt. En användarvänlig produkt som är lätt att använda bör intressera alla användare från nybörjare till experter. Vikten bör ligga i att kunna identiera ett behov för den avsedda produkten. Om det inte nns något behov av en produkt bör den då utvecklas? Är det värt det? Eller är det möjligt att ett behov av en sådan produkt uppstår inom en nära framtid? En alternativ design kan vara ett sätt att uppfylla kraven och bör därför göras med skisser för att ta emot snabb feedback från användarna. Det viktiga här är att informera användaren att det är en skiss och att den används för att presentera olika designförslag. Men kan en användare påverkas av att en skiss är mer omsorgsfullt konstruerad än vad en annan är? För att undvika en sådan situation kan ett skissprogram användas. Vid användning av sådana program föryttas fokus mot designförlagen istället för mot hur de olika designförslagen ser ut. Bör ett förslag av en interaktiv produkt ha mer än de huvudsakliga funktionerna implementerade? Kostnaden blir större med er funktioner som implementeras, därför bör det vara en avvägning mellan att visa huvudsakliga funktioner och olika designförslag. 3.2 Användbarhet Användbarhet är ett sätt att försäkra sig om att en interaktiv produkt är enkel att använda, lätt att lära sig och rolig från en användares perspektiv samt att den hjälper dem i deras dagliga verksamhet när de interagerar med den. Målen med användbarhet kan denieras med dessa ord [15]: 1. Eektivitet 2. Säkerhet 3. Nytta

15 3.3. Användarupplevelse 7 4. Förmåga att lära sig 5. Minnesvärdhet Eektivitet: Hur bra ett system i allmänhet är på att utföra de uppgifter som systemet är ämnad att göra. Kan systemet hjälpa användaren att uppnå syftet med interaktionen? Hur stödjer systemet användarna i deras uppgifter? Säkerhet: Skydda användare från osäkra och inte avsedda situationer. Nytta: Hur systemet förser användaren med funktionalitet så att användarna kan åstadkomma det de avsåg att göra. Förmåga att lära sig: Hur lätt är det för en användare att lära sig systemet? Minnesvärdhet: Hur lätt är det att komma ihåg systemet efter att en gång ha lärt sig det? 3.3 Användarupplevelse Ny teknik har lett interaktionsdesign mot nya mål för att hjälpa användare i vardagslivet. Det primära är att förbättra eektiviteten och att stödja användare i sina dagliga arbeten. Interaktionsdesign har gått mot att också fokusera på att skapa system som är tillfredsställande, underhållande, roliga, hjälpsamma, motiverande, estetiskt tilltalande, kreativitetshöjande och känslomässigt givande. Användarupplevelser skiljer sig från de mer objektiva målen med användbarhet eftersom de handlar om hur en användare upplever ett system utifrån deras eget perspektiv. Mål för användbarhet och mål för användarupplevelser är viktiga att hitta och förstå för att se om de kan kombineras för att uppfylla olika användares behov. Vad som skall ingå i ett system beror på sammanhanget, uppgiften och vem som är användare [15] Diskussioner om användbarhet och användarupplevelser Vid utveckling av ett användargränssnitt bör eektivitet, säkerhet, nytta, förmåga att lära sig och minnesvärdhet vara ord som designen kretsar kring. Dessa mål för användbarhet bör användas under hela designprocessen. Frågan är hur man ska veta när de är uppfyllda? Användare som deltar i designprocessen är ett svar, men när kan en designer vara säker på att alla mål för användbarhet är uppnådda? Målen för användbarhet säger inte när de är uppfyllda, utan bara vad man ska leta efter när man utvecklar användargränssnitt. Användarupplevelser är svårare och är subjektiva, en användargrupp kan identieras men användare i den gruppen kan ha olika användarupplevelser. 3.4 Designprinciper Designprinciper används för att hjälpa en designer med vad som är bra att tänka på vid utveckling av ett system. De är avsedda att hjälpa designern med vad de kan och inte kan göra med ett gränssnitt men de säger inte hur grak ska se ut och hur ett användargränssnitt struktureras. De vanligaste designprinciperna är: Synlighet: En användare vet förmodligen hur man interagerar med funktioner om de är synliga, ifall de inte är synliga är de svårare att hitta och använda.

16 8 Kapitel 3. Interaktionsdesign Feedback: Feedback handlar om att skicka information tillbaka till användaren om vilken handling som har utförts. Det nns några tillgängliga återkopplingar för interaktionsdesigners att använda som ljud, känsel, verbal och visuell feedback. De kan användas separat eller i kombinationer beroende på situationen. Begränsningar: Begränsningar är att avgränsa vad en användare kan göra i en viss interaktionssituation. Ett exempel kan vara att skugga olika delar i en grask meny när de inte ska kunna vara valbara. Detta hjälper användare vid navigering. Användarna vet att de skuggade delarna inte går att använda vid detta stadium. Mapping: Mapping handlar om hur en artefakt och kopplingen av dess eekt är när de används. Konsekvent: Konsekvent är att liknande funktioner i ett användargränssnitt ska ske på ett liknande sätt. Det kommer att leda till ett användargränssnitt som är lättare att använda och lära sig. Aordance: Aordance är när ett föremål visar hur det kan användas, den talar om för användaren på vilket sätt det ska hanteras. I användargränssnitt där virtuella objekt används nns termen uppfattad aordance. Virtuella objekt är inlärda konventioner och har inte riktiga aordances [15] Diskussioner om designprinciper Designprinciper bör vara riktigt användbara vid utveckling av ett användargränssnitt. De designprinciper som presenterats kommer att bidra till att designern utformar ett mer användbart gränssnitt och bör vara en grundsten i de iterationer som utförs i designprocessen. Synlighet är en del som är användbar i designprocessen, men allt kan inte vara synligt i ett gränssnitt. Funktioner som är tänkta att användas ofta och regelbundet bör vara synliga för användarna. Feedback är kanske den viktigaste av dem alla, den hjälper användarna med att få information när de navigerar genom användargränssnittet. Begränsningar kan vara mycket användbara för att leda en användare till möjligheterna i ett användargränssnitt. Val som inte går att göra hjälper användaren att förstå att dessa inte kan användas. Det hjälper dem att veta vad man ska göra i en viss situation. Mapping är ett bra sätt att visa på förhållandet mellan en kontroll i ett användargränssnitt och eekten av användning av en sådan i verkligheten. Standardkontroller som används i andra tillämpningar kommer förmodligen att minska missförstånd om vad man ska göra och hur interaktionen ska ske, användaren har kunskap om dessa standardkontroller som används i andra liknande applikationer. Konsekvens är användbart när man ska gruppera liknande operationer för att uppnå liknande uppgifter. Problem som kan uppstå är att en alltför liknande operation kan göra att en användare förväxlar dessa med varandra. Aordance kan vara mycket användbart, men om attributen inte är tillräckligt tydliga kommer det förmodligen att förvirra användarna mer än att hjälpa dem.

17 Kapitel 4 Utvecklingen genom en interaktionsdesign Syftet med interaktionsdesign är att ersätta, uppdatera eller att skapa en ny interaktiv produkt. Vid utveckling av interaktiva produkter nns det frågor som behöver diskuteras, användares behov, projektets mål, krav och förväntningar. Prototyper och utvärderingsparadigm presenteras för att beskriva olika utvärderingsmetoder att använda i en designprocess [15]. Ett system utvecklat för människor bör vara lätt att använda, lätt att komma ihåg och behaglig att använda. Systemets funktioner bör vara funktioner som användarna verkligen behöver när de interagerar med det [5]. 4.1 Identiera behov I början av ett projekt utarbetas en projektplan med information om personer som är inblandade, budget och en tidsplan. En användbarhetsplan skapas också för att identiera användargruppen och deras behov [4]. En förståelse av användarna är viktig i stället för att beskriva och kontrollera dem. Direktkontakt bör tas med framtida användare vid utveckling av ett system istället för att höra och läsa om dem. Kontakten ska tas före en systemdesign [5]. Identiera behov innebär att förstå så mycket som möjligt om tänkta användare, deras arbete och sammanhanget där de arbetar. Det görs för att systemet som utvecklas ska hjälpa användarna att uppnå sina mål när de interagerar med det. Ett antal krav som används genom hela designprocessen skapas utifrån de identierade behoven. Att identiera krav och behov är en iterativ process i sig och förändras när beställare av systemet är involverade i designprocessen. Produktförståelse för att stödja beställares behov är viktig för att utveckla produkten. Om kraven inte uppfylls resulterar detta i ett system som kommer att ignoreras av användaren. Ett sätt för att undvika detta är att involvera användarna i designprocessen. Då är det mer troligt att slutprodukten kommer att uppfylla användarnas behov och förväntningar. En kravspecikation är att säga vad en produkt bör göra och hur den skall användas på ett så tydligt som möjligt sätt. Vikten är att vara tydlig och abstrahera delar av produkten. Två typer av krav som används mest i mjukvaruutveckling är funktionella och icke funktionella krav. Ett funktionellt krav, säger vad systemet ska göra och icke funktionella krav handlar om vilka begränsningar systemet har [15]. 9

18 10 Kapitel 4. Utvecklingen genom en interaktionsdesign Diskussioner om att identiera behov När man utvecklar en ny produkt ska en detaljerad plan utarbetas för att söka efter användarnas behov. En viktig punkt är att involvera och förstå sig på de framtida användarna av produkten. Svårigheter kan vara är att veta hur mycket en användare bör involveras vid utveckling av produkten. Användares synpunkter är viktiga, de kan komma med idéer som är omöjliga att genomföra, men deras idéer bör diskuteras. Vad händer om en produkt inte har en tilltänkt målgrupp när den utvecklas? Produkten kommer troligen vara svår att marknadsföra och sälja. Produkten har inga målgrupper och kommer inte att vara utformad mot någon specik användare. Det kommer förmodligen att leda till användbarhetsproblem och en produkt som ingen vill ha. 4.2 Konceptuella modeller Konceptuella modeller utvecklas utifrån användarnas behov. En konceptuell modell denieras som "en beskrivning av det föreslagna systemet i termer av en uppsättning av integrerade idéer och koncept om vad den ska göra, bete sig och se ut, som kommer att förstås av användare på avsett vis"[15]. Iterativ testning krävs för att se till att en produkt är utformad på ett begripligt sätt och testning bör ske under hela perioden när produkten utvecklas. Konceptuella modeller kan beskrivas och kategoriseras i de som grundas på verksamhet och i det som baseras på objekt [15] Aktiviteter Instruerande: En konceptuell modell som bygger på instruerande verksamhet bygger på användarnas instruktioner till systemet för att fullgöra arbetsuppgifterna. Många enheter som videobandspelare, hi-system och datorer har utformats på detta sätt. Samspelet sker med knappar, fjärrkontroller eller med skrivtecken. Fördelen med att använda instruktionsbaserade prototyper är att stödja snabb interaktion genom kommandon från användaren. Samtalande: Den samtalande konceptuella modellen bygger på användare som har ett samtal med ett system. Systemet är utformat för att ge svar på frågor och att agera som en partner att interagera med. Denna konceptuella modell används i system som hjälper användarna att hitta specik information. Exempel när detta används är i sökmotorer och hjälpsystem där användarna använder frågor för att hämta svar från systemet. Fördelarna med den samtalande konceptuella modellen är att nybörjare kan interagera med ett system på ett sätt som de känner till och använder i verkliga världen. En nackdel är när systemet inte kan ge ett korrekt svar på en specik fråga, vilket kan förvirra användare. Manipulera och navigera: Den konceptuella modell för att manipulera och navigera i en virtuell plats görs på ett sätt som användarna känner till från den fysiska världen. Exempel kan vara att ytta, välja, öppna och stänga virtuella objekt. Det kan nnas situationer där det är möjligt att manipulera och navigera i den virtuella världen på ett sätt som inte är möjligt i den fysiska världen. Exempel på detta kan vara att omvandla ett objekt till ett annat objekt. Utforska och surfa: Den konceptuella modellen att utforska och surfa är att låta användarna utforska och söka efter information på ett sätt som de är vana

19 4.3. Design och prototyper 11 att använda äldre medier så som tidningar och böcker. Webbsidor, portaler etc använder denna konceptuella modell, så att användarna kan söka igenom delar för att hitta vad de söker [15] Diskussioner om konceptuella modeller En konceptuell modell bör identieras så tidigt som möjligt i designprocessen och vara i fokus vid senare utveckling av prototyper. Bör olika konceptuella modeller bara diskuteras eller bör de alla leda till olika prototyper? Det kan vara tidskrävande att utveckla prototyper utifrån många olika konceptuella modeller. Bör en konceptuell modell först beslutas att använda för att sedan göra prototyper av denna modell? Förmodligen är en konceptuell modell mer passande än en annan när de nns en fördenierad produkt i åtanke. 4.3 Design och prototyper En fysisk design handlar om hur man kan strukturerar menyer, ikoner och annan grak Den konceptuella och fysiska utformningen sker genom en iterativ process där användare är inblandade för att utvärdera en interaktiv produkt. Tidigt i utvecklingen kan pappersversioner användas för att bedöma idéer men senare i processen är det att föredra att ha en produkt som liknar den slutliga produkten [15]. 4.4 Prototyper En prototyp kan vara allt från en storyboard till en komplex programvara och är en representation av en framtida slutprodukt [15]. Prototyper och skisser kan användas för att skapa designalternativ och för att få snabb återkoppling från användare [4]. En prototyp kan göras av papper eller kartong och användas för att representera en del av ett system. En pappersbaserad prototyp är väl lämpad att använda för att klargöra hur användare kan utföra vissa uppgifter och om den föreslagna lösningen kommer att hjälpa dem att uppnå sina mål. Prototyperna gör det möjligt för intressenter att interagera med den förväntade produkten för att få en förståelse av vad produktens intentioner är. Low-delity prototyper är ofta gjorda av papper eller kartong och ser inte ut som den färdiga produkten utan avsikten är att använda sådana tidigt i designprocessen. De är användbara eftersom de enkelt, billigt och snabbt går att producera dem. Ändring av dem kan därför göras snabbt och det gör dem mycket användbara. De är aldrig avsedda att användas som en slutprodukt utan används för att representera ett tilltänkt framtida system. High-delity prototyper är modeller som kan representera hur en framtida slutprodukt skulle se ut. Utseendet och känslan av en high-delity prototyp är ofta vad man kan förvänta sig av en slutprodukt. High-delity prototyper av mjukvara är bra för att presentera och sälja idéer till människor och för att testa olika delar i designen [15]. En prototyp som är byggd för att testas kan antingen testas som ett systemtest eller som ett användartest. Skillnaden är att ett användartest fokuserar på hur lätt användare kan lära sig och använda produkten samtidigt som ett systemtest fokuserar på systemet och dess olika delar [5].

20 12 Kapitel 4. Utvecklingen genom en interaktionsdesign Diskussioner om prototyper Pappersprototyper bör vara mycket användbara när man snabbt ska presentera idéer vid utveckling av mjukvara. Två skäl till att använda pappersprototyper bör vara att man snabbt och billigt kan presentera idéer. Postitlappar kan i ett trevligt och enkelt sätt användas för att diskutera användargränssnitt. Författaren kan inte se några nackdelar med att använda pappersprototyper i en designprocess. Det nns för många fördelar att inte involvera dem och de bör därför användas under hela utvecklingsfasen. 4.5 Utvärdering Utvärdering är att samla in data för att informera en designer hur det är för en viss användare att använda en produkt för en viss uppgift i ett visst sammanhang. Utvärderingar bör göras i olika stadier vid utveckling av en produkt och detta har visat sig vara billigare än att rätta till och åtgärda problem efter att en produkt har släppts. För en interaktionsdesigner är det viktigt att veta vad, när och varför man ska utvärdera. Trenden nu för tiden är att observera hur användare interagerar med ett system i deras naturliga miljöer. Detta görs för att se hur användare agerar med systemet där det är avsett att användas. Det är inte ofta att användare utför en uppgift från början till slut utan att bli störd. På jobbet avbryts människor ofta av telefonsamtal, e-post och så vidare, det är därför interaktionen är annorlunda i en naturlig miljö jämfört med i ett laboratorium. Målet med en utvärdering är att se hur väl ett designförslag uppfyller användarnas behov och om de gillar systemet [15]. Funktionella tester och användartester bör ske genom hela designprocessen för att avgöra när en produkt ska lanseras. Användbarhetsinspektioner och feedback är viktiga för att hitta problem med designen. En webbplats är användbar och redo att lanseras när den fungerar korrekt och klarar av användarnas behov. Kända problem kan guida ett användartest för att snabbt identiera användbarhetsproblem [4]. 4.6 Utvärderingsparadigm När en produkt utvecklas från en idé till en konceptuell modell och till en prototyp genom iterativa cykler av design och utvärderingar är avsikten att nå och möta användarnas behov. Detta och att identiera användbarhet och användarnas förväntningar är av betydelse när man utvecklar en framgångsrik produkt. Att planera en utvärdering är att titta på centrala frågor och att ställa frågor om dem [15]. Empiriska studier som innebär verkliga användare som testar användargränssnitt är den metod som används mest vid utvärdering av användargränssnitt [9] Quick and dirty utvärdering En "Quick and dirty"utvärdering används när en designer informellt vill få feedback från användare för att kontrollera att ett designkoncept möter användarnas behov. Utvärderingsparadigm kan användas i alla skeden av designprocessen och används för att få snabb feedback från användare. Tidigt i en design kan den användas för att få feedback på idéer om en ny produkt. Senare kan samma paradigm användas för att titta på graska delar av designen, och så som namnet säger är det tänkt att ske på kort tid med snabb feedback. De uppgifter som samlas in från paradigmet är ofta beskrivande och informella med anteckningar, skisser och verbala anteckningar [15].

21 4.6. Utvärderingsparadigm Användartester Användartester involverar typiska användare när de utför förberedda uppgifter som är typiska för vad systemet är utformat att göra. Användarnas prestanda mäts i antal fel och tid att slutföra en uppgift. Vanligtvis är testet starkt kontrollerat av utvärderaren och sker i ett laboratorium där inga andra personer är tillåtna, och där testet bör ske utan avbrott. En videobandspelare används ofta för att logga och samla in data när användare interagerar med systemet. Data som spelas in är knapptryckningar, kommentarer och pauser, allt som kan vara bra att veta och hjälpa designers att analysera och söka efter användbarhetsproblem med systemet. För att slutföra användbarhetstestet används enkäter och intervjuer för att frambringa användarens tillfredsställelse och synpunkter [15] Fältstudier Fältstudier görs i naturliga sammanhang för att få en förståelse för hur användare agerar med tekniken i sin naturliga miljö. Den kan användas när man ska upptäcka nya teknik att använda, komma med krav på en design, bistå införandet av ny teknik och för att utvärdera teknik. Tekniker som kan vara lämpliga i en fältstudie är intervjuer, observationer, deltagandeobservationer och etnograska studier. Den insamlade datan består av ljud, anteckningar eller bilder från händelser och samtal. Dessa används senare för analys [15] Förutsägande utvärdering En förutsägande utvärdering är när experter förutspår användbarhetsproblem genom att använda heuristik. I en förutsägande utvärdering deltar inte användare och är därför snabb och relativt billig [15] Heuristisk utvärdering Heuristisk utvärdering är en metod för att snabbt och billigt utvärdera ett användargränssnitt. Det viktigaste i en heuristisk utvärdering är att nna användbarhetsproblem i ett användargränssnitt och göra iterationer på dem. Detta sker genom ett fåtal utvärderare för att se om användargränssnittet följer kända användbarhetsprinciper [11]. I en heuristisk utvärdering utvärderar gränssnittsspecialister gränssnittet för att nna användbarhetsproblem. De kan hitta användbarhetsproblem på grund av sin erfarenhet som specialister [7]. Heuristisk utvärdering är en av de mest använda utvärderingsmetoder numera vid inspektering av användargränssnitt [13]. För att nna användbarhetsproblem är det viktigt att känna till syftet med produkten, känna typiska användare av produkten och att ha scenarier när användare interagerar med produkten [8]. En heuristisk utvärdering kan vara svår att genomföra för en person eftersom en enda person aldrig kan hitta alla användbarhetsproblem i ett användargränssnitt. Därför bör era utvärderare involveras för att söka efter användbarhetsproblem och för att förbättra mätresultatet. I en heuristisk utvärdering kan en observatör svara på frågor och ge tips, men hjälp bör inte ges förrän testpersonen har problem och har upptäckt ett användbarhetsproblem. Resultaten är en lista med användbarhetsproblem från en heuristisk utvärdering och de bör förklaras separat med hänvisning till kända användbarhetsprinciper för att ge information om varför de är användbarhetsproblem. I en omdesign används listan

22 14 Kapitel 4. Utvecklingen genom en interaktionsdesign för att förbättra användargränssnittet [10]. Tre till fem utvärderare är en rekommendation för att nna användbarhetsproblem i ett gränssnitt och andra tillgängliga resurser bör användas på andra utvärderingsmetoder. De främsta fördelarna med en heuristisk utvärdering är: Det är billigt. Det är intuitivt och det är lätt att motivera folk att göra det. Det kräver ingen framförhållning. Den kan användas tidigt i utvecklingsprocessen. Nackdelen med en heuristisk utvärdering är att den ibland hittar användbarhetsproblem men inte föreslår en lösning på problemet [13] Tio heuristiska användbarhetspunkter Jakob Nielsen har lagt fram tio olika allmänna principer för gränssnittsdesign. 1. Synlighet av systemets status Systemet bör alltid informera användarna vad som händer genom återkoppling inom en rimlig tid. 2. Matchning mellan systemet och den verkliga världen Systemet bör använda ord och fraser som är kända av användare och presentera informationen i en naturlig och logisk ordning. 3. Användarkontroll och frihet Systemet bör innehålla ångra och göra om funktioner för att stödja användare vid oönskade tillstånd. 4. Konsekvens och standarder Systemet bör vara konsekvent i ord, situationer och åtgärder. 5. Förebygga fel Systemet bör utformas för att förebygga problem och fel som uppstår. 6. Igenkännande hellre än att komma ihåg Systemet bör minimera användarens minnesbelastning genom att göra objekt, handlingar och alternativ synliga. 7. Flexibilitet och eektivitet i användning Systemet bör vara exibelt så att oerfarna och erfarna användare kan använda det på deras eget sätt. 8. Estetisk och minimalistisk design Systemet bör använda dialoger som är relevanta och nödvändiga.

23 4.6. Utvärderingsparadigm Hjälpa användare att känna igen sig, diagnostisera och återhämta sig från fel Systemet ska visa felmeddelanden i klartext vid information om problemet och föreslå en åtgärd. 10. Hjälp och dokumentation Dokumentationen ska vara enkel att söka i och ha fokus i användarnas uppgifter och inte vara allt för lång [12] Diskussioner om användbarhets heuristiker Användbarhetsheuristiker kan vara mycket användbara i en utvärdering av ett användargränssnitt. Fördelen är att ha en billig och snabb utvärdering som kan göras med bara några få bedömare. Användbarhetsexperter kan navigera genom användargränssnittet för att söka efter kända användbarhetsproblem. Problem med en heuristisk utvärdering är att det inte innefattar verkliga användare, istället är experter involverade. Verkliga användare kommer förmodligen att identiera användbarhetsproblem som experter inte hittar. Hur tillförlitliga är resultaten om inga verkliga användare är inblandade? Man kan inte helt förutsäga hur en användare kommer att reagera och acceptera en ny produkt som inte är testad med riktiga användare DECIDE DECIDE är ett ramverk för att styra en utvärdering och är en checklista för att hjälpa utvärderare som är noviser. 1. Determine, Bestämma de övergripande målen av utvärderingen. 2. Explore, Utforska de specika frågor som ska besvaras. 3. Choose, Välja utvärderingsparadigm och tekniker för att besvara frågorna. 4. Identify, Fastställa praktiska frågor som måste behandlas, t.ex. välja ut deltagare. 5. Decide, Bestämma hur etiska frågor hanteras. 6. Evaluate, Utvärdera, tolka och presentera den insamlade datan [15]. Målen Målen bör vara vägledande för vad som ska utvärderas och bör därför lösas innan utvärderingen. Målen påverkar hur man utvärderar och vilket paradigm som man väljer [15]. Frågorna Frågor som skall användas för att klargöra om målen är uppfyllda bör identieras. Frågorna kan vara allmänna eller mycket specika [15].

24 16 Kapitel 4. Utvecklingen genom en interaktionsdesign Välj utvärderingsparadigm Om mål och frågor har identierats är nästa del att välja tekniker och en utvärderingsparadigm. En kombination av tekniker kan användas om en anpassad är för dyr, tar för lång tid eller om expertishjälp inte nns tillgänglig [15]. Identiera praktiska frågor Innan en utvärdering kan börja är det många praktiska frågor att hantera och identiera. En viktig aspekt är att involvera rätt användare i utvärderingen, sådana som representerar användare som är tänkta att använda systemet. För de användare som deltar i utvärderingen är det viktigt att de känner sig välkomna och komfortabla. En viktig sak att påpeka för användarna är att det är systemet som testas och inte användarna [15]. Etiska frågor Integriteten bör skyddas så att insamlad data inte kan identieras till en specik användare som deltar i testet [15]. Utvärdera, tolka och presentera data Före utvärderingen startar måste beslut fattas på vad som ska samlas in, hur data ska analyseras och presenteras [15] Diskussion kring utvärdering En utvärdering bör vara en del i en designprocess, det är en chans för designers att få information om produkten uppfyller användarnas behov. Hur ska annars en designer veta om en produkt är bra nog? Utvärderingen är den del i designprocessen som ger den sortens information. Informationen används för att söka efter användbarhetsproblem med produkten och hur man kan göra förbättringar utifrån användarnas perspektiv. Quick and dirty utvärderingar är ett bra sätt att snabbt få information om en produkt och det är därför som den kan användas när som helst i designprocessen. Användartester kan vara svåra att genomföra eftersom verktyg och ett laboratorium behövs. Resultaten från ett sådant prov kan också vara svåra att tolka med siror att analysera. Fältstudier kan vara bra för att se hur användare beter sig i sin naturliga miljö och den kan användas i olika stadier av designprocessen. En automatisk utvärdering kan vara mycket värdefull där experter är involverade i att se användbarhetsproblem i ett användargränssnitt. Det nns fördelar och nackdelar till samtliga av de presenterade utvärderingsmetoder men den övergripande frågan är att veta hur man ska tolka resultaten? Med mer erfarenhet bör en designer veta vad man ska titta på när man söker användbarhetsproblem i ett användargränssnitt. 4.7 Tekniker Det nns många utvärderingsmetoder några av dem presenteras här:

25 4.7. Tekniker Iaktta användare Att observera användare är att titta och lyssna på vad användare gör när de interagerar med användargränssnittet. De kan berätta vad de gör, hur kontexten ser ut, hur tekniken stödjer dem och vad som behövs för att stödja dem. Vilken observationsteknik som man kan välja bland beror på utvärderingens mål, vilka frågor som man vill ha besvarade och på praktiska hinder. Fokus för observation ges av vilka mål och frågor som har satts upp och bör vägleda utvärderingen. En observation kan göras när som helst i utvecklingen av ett system. Tidigt kan den användas för att förstå användarnas behov och senare för att se om en prototyp uppfyller användarnas behov [15]. Grundläggande är att involvera nybörjare vid observationer av användare, eftersom många problem är ett resultat av användarnas kunskap eller avsaknaden av den när de interagerar med ett system [3] Tänka högt tekniken Tänka högt tekniken kan användas för att ta reda på vad en användare tänker och vad avsikterna i interaktionen med gränssnittet är [15]. Tekniken används ofta vid utvärdering av ett användargränssnitt och för att få feedback från användare [16]. Vid interaktion med systemet så berättar användarna högt vad de tänker och försöker att göra. Detta hjälper en designer att hitta delar av användbarhetsproblem som annars kan vara svåra att hitta. Om en användare är tyst under ett test kan utvärderaren avbryta för att påminna användaren att tänka högt [15]. Tänka högt metoden ses av Joe Duman som den viktigaste metoden i en användbarhetsutvärdering. Den nner mer användbarhetsproblem än någon annan teknik [16]. Nörgaard med er med sin studie av hur professionella användbarhetsutvärderare leder ett tänka högt test säger att testet kanske inte analyseras tillräckligt. Utvärderarna fokuserar för mycket på kända problem snarare än att fokusera på problem under testet. De föreslår ett sätt att förbättra tänka högt tekniken genom att utreda upplevda problem mer än att förutse problem [14] Diskussion om tekniker Tänka högt tekniken bör vara en mycket användbar teknik vid utvärdering av ett användargränssnitt. Fördelen är att ha en användare som beskriver för utvärderaren vad han tänker och hur han navigerar. Det bör därför vara lätt att följa om en användare stannar när man interagerar med användargränssnittet och sedan säga att han har problem. Detta är ett typiskt användbarhetsproblem när användaren inte vet vad de ska göra. Ett problem med denna teknik är att den inte säger hur ett användbarhetsproblem kan lösas utan bara visar att det nns ett sådant. En fördel med tekniken är att ha riktiga användare som interagerar med applikationen och om utvärderingen kan ske i rätt miljö är det ännu mer användbart. Att förutsäga hur en användare interagerar med en produkt är inte lämpligt och verkliga användare bör därför delta vid utvärderingen av ett användargränssnitt. Hur kan en designer annars veta om en produkt kan användas utifrån en användares perspektiv?

26 18 Kapitel 4. Utvecklingen genom en interaktionsdesign

27 Kapitel 5 Prestation och resultat Detta kapitel beskriver metoder, tekniker och varför de olika delarna i designprocessen har valts vid utveckling av Let's walk systemet. 5.1 Teknisk beskrivning Let's walk systemet består av en webbapplikation som körs på en IIS server, en handhållen streckkodsläsare, Argox-PT12, för att registrera användare som promenerar och en MySQL-databas för att lagra information. Visual Studio 2005 med programspråket C# har använts för att implementera webbapplikationen 5.2 Systembeskrivningar och krav Innan jag påbörjade examemsarbetet hade ett koncept utvecklats, detta bestod av en kravspecikation med en systemarkitektur och användarfallsbeskrivningar. Användningsfallen användes för att få en förståelse för uppbyggnaden av systemet. Användningsfallen kan ses i bilaga B. Systemarkitekturen är uppdelad i två delar, en central del ( webbapplikationen med en MySQL-databas) och en handhållen del (en streckkodsläsare, Argox-PT12). De viktigaste funktionerna i kravspecikationen för den centrala delen är: Registrering av företag Registrering av deltagare, kortidentiering Registrering av motionsrunda med tillåtna gränsvärden Insamling av statistik Den handhållna delen av systemet, en streckkodsläsare av typen Argox-PT12 implementerades av en medarbetare på Explizit. De huvudsakliga funktionerna för Argox- PT12 är: Registrera station Registrera motionär 19

28 20 Kapitel 5. Prestation och resultat Den handhållna enheten, Argox-PT12 användes av funktionärer på givna stationer för att registrera personer som motionerade runt broarna i Skellefteå, det så kallade Broarna Runt. Två stationer användes under hela projektet och det fanns möjlighet att gå vid lunchtid eller på eftermiddagen under vardagarna och vid middagstid under helgerna. En station låg vid södra Lejonströmsbron, Skellefteå och den andra stationen var belägen på norra sidan av Parkbron. Detta var slingan man kunde gå på eftermiddagen och om helgerna, lunchvarvet hade en station på södra sidan om Viktoriabron och en station på norra sidan om Parkbron. Ett varv på lunchen var 1,6 kilometer och varvet på eftermiddagen eller på helgerna var 5,0 kilometer långt. Deltagarna hade möjlighet att börja och sluta på vilken som helst av stationerna och det var tillåtet att gå så många varv som möjligt. Det enda de var tvungna att komma ihåg var att registrera sina kort vid varje station som de passerade. 5.3 Identiera användare Det viktiga här var att ha en klar uppfattning om vilka användare som skulle använda Let's walk systemet. Identierade användare var anställda på tre idrottsföreningar i Skellefteå, de var ansvariga för att administrera Let's walk systemet. Åtminstone skulle en i varje sportklubb vara administratör och använda webbapplikationen. Administratörerna skulle använda webbapplikationen för att sätta upp Let's Walk projektet och för att ladda upp ler till det centrala systemet (databasen). De identierade användarpro- lerna var användare som hade administratörsroller på sina idrottsföreningar och hade datorvana. Användare som identierats att använda de handhållna streckkodsläsarna var från unga till gamla med olika erfarenheter av en handdator. Användarprolens spann var stort på grund av att stationerna behövde vara bemannadade varje dag under projektet, gruppen som använde streckkodsläsaren identierades därför till att vara nybörjare. 5.4 Low-Fidelity Prototyper När användare av systemet hade identierats och analyserats konstruerades några low- delity prototyper i papper. Prototyperna användes för att presentera några förslag till en design av användargränssnittet. Detta gjordes på papper för att snabbt komma fram med idéer hur webbapplikationen skulle utformas. Ingen implementation gjordes i denna del av designprocessen utan endast penna och papper användes. I denna del av designprocessen diskuterades olika designidéer med kollegor på Explizit om hur utformningen av Let's walk webbapplikation skulle se ut. Diskussioner som kom upp i denna fas var: Hur organiserar man ödet i webbapplikationen? Hur presenterar man informationen för användaren? Hur presenteras och organiseras menyn? Hur organiseras layouten när ett nytt projekt skapas? Var ska logotypen placeras?

29 5.4. Low-Fidelity Prototyper 21 Low-Fidelity prototyperna var mycket användbara att använda vid diskussionerna med kollegorna kring designförslagen. Metoden att använda low-delity prototyper hade aldrig använts till denna grad och var en nyttig erfarenhet. Om denna metod inte hade använts skulle det antagligen ha lett till förutfattade idéer om hur webbplatsen skulle utformas. Idéer skulle inte ha diskuterats i sådan omfattning som det gjordes och resultaten från low-delity prototyperna skulle inte ha uppnåtts. Om prototyperna skulle ha implementerats skulle det ha kostat mycket tid, och därför gjordes prototyperna i papper. Fördelen med att bygga en pappersprototyp var att få snabb feedback och att diskutera olika designförslag innan en interaktiv version implementerades.

30 22 Kapitel 5. Prestation och resultat Figur 5.1: En low-delity prototyp av login webbsidan. Två low-delity prototyper, en representerar inloggningen till webbplatsen och den andra representerar menyn:

31 5.4. Low-Fidelity Prototyper 23 Figur 5.2: En low-delity prototyp av menyn.