Mobila tjänster - Interaktionsdesignslösning av ett

Examensarbete i MDI/Interaktionsdesign Mobila tjänster - Interaktionsdesignslösning av ett webbaserat administrationsverktyg för mobila innehållstjänster Daniel Johansson & Julia Lagerstedt Göteborg, Sweden 2006 Institutionen för datavetenskap

REPORT NO. 2006/21 Mobila tjänster Interaktionsdesignslösning av ett webbaserat administrationsverktyg för mobila innehållstjänster DANIEL JOHANSSON JULIA LAGERSTEDT Department of Computer Science and Engineering IT UNIVERSITY OF GÖTEBORG GÖTEBORG UNIVERSITY AND CHALMERS UNIVERSITY OF TECHNOLOGY Göteborg, Sweden 2006

Mobila tjänster Interaktionsdesignslösning av ett webbaserat administrationsverktyg för mobila innehållstjänster DANIEL JOHANSSON JULIA LAGERSTEDT DANIEL JOHANSSON, JULIA LAGERSTEDT, 2006. Rapport nr: 2006:21 ISSN: 1651-4769 Institutionen för datavetenskap IT-universitetet i Göteborg Göteborgs universitet och Chalmers tekniska högskola P O Box 8718 SE 402 75 Göteborg Sweden Telefon + 46 (0)31-772 4895 Tryckeriet, Matematiskt Centrum Göteborg, Sweden 2006

Mobila tjänster Interaktionsdesignslösning av ett webbaserat administrationsverktyg för mobila innehållstjänster DANIEL JOHANSSON JULIA LAGERSTEDT Institutionen för datavetenskap IT-universitetet i Göteborg Göteborgs universitet och Chalmers tekniska högskola SAMMANFATTNING Mobil marknadsföring är ett effektivt sätt att sprida information. Det finns idag många aktörer på denna marknad, varav en är Micromarketing. Idag administrerar detta företag varje kund enskilt, vilket kräver mycket resurser. För att effektivisera hanteringen av de tjänster som de erbjuder sina kunder krävs en förändring i denna hantering. Om kunderna själva administrerar de beställda tjänsternas innehåll så sparas tid för både Micromarketing och deras kunder. Denna rapport beskriver arbetet med att ta fram en interaktionsdesignslösning för Micromarkteings webbaserade administrationsverktyg för mobila innehållstjänster. I vår designprocess har prototyping varit det främsta verktyget, både för att konkretisera idéer och för att utvärdera dessa. Vi har arbetat i en iterativ process, där vi genomfört tester på både hifi- och lofiprototyper. Samarbetet med vår uppdragsgivare blev inte som förväntat på grund av Micromarketing förändrade arbetsbelastning. Våra gemensamma visioner var att de skulle implementera vår designlösning under arbetets gång så att vi skulle kunna genomföra en slutlig användbarhetsevaluering av administrationsverktyget MMAS. Då inte de har implementerat vår interaktionsdesignslösning har inte detta kunnat genomföras och därför kan vi inte med säkerhet säga om vi nått önskad användbarhet i systemet. Vi har slutfört vårt arbete med målet att vår designlösning skulle kunna implementeras av Micromarketing, även om så icke blev fallet. Nyckelord: interaktionsdesign, användbarhet, användarvänlighet, MDI, prototyping, systemdesign.

Mobile Services Interaction Design Solution of a Web based Administration Tool for Mobile Content Services DANIEL JOHANSSON JULIA LAGERSTEDT Department of Computer Science and Engineering IT University of Göteborg Göteborg University and Chalmers University of Technology SUMMARY Mobile marketing is an effective way to distribute information. There are a lot of actors in this market today, one of whom is Micromarketing. Today this company administrates one client at a time, which is very time consuming. A change is necessary to make this process more effective. Time and money will be saved if the customers administrate the services Micromarketing offers, on their own. This paper describes our work of creating an interaction design solution for the web based administration tool of Micromarketing s content services. Our process involves prototyping, which has been our main development tool. Prototyping has been used both to make ideas concrete and to evaluate the solutions. We have practiced an iterative development process, in which hifi and lofi prototypes have been tested. The cooperation with Micromarketing went all but smoothly, mainly because of their changing work load. Our common visions was for them to implement the design solution, and to make it possible for us to conduct a final usability evaluation of the administration tool MMAS. Since they did not complete the implementation of our design solution, the final usability evaluation was not carried out. Therefore we can not with certainty say if the usability objective of the system was fully accomplished. Even though Micromarketing did not fulfill their side of our collaboration, we have created an implementable design solution. The report is written in Swedish. Keywords: interaction design, usability, HCI, prototyping, system design.

1 Introduktion...9 1.1 Bakgrund...9 1.2 Syfte...10 1.2.1 Problemformulering...10 1.3 Avgränsningar...10 1.4 Förväntat resultat...10 1.5 Disposition...10 2 Metod...11 2.1 Prototyping...11 2.1.1 Paper prototyping...11 2.1.2 Datorbaserad prototyping...11 2.2 Expertutvärdering...12 2.2.1 Heuristisk utvärdering...12 2.3 Användartestning...13 2.4 Gruppdiskussion...13 2.5 Wizard of Oz...13 2.6 Think aloud...14 2.7 Urval...14 3 Teori...15 3.1 Interaktionsdesign...15 3.2 Användbarhet...15 3.3 UCD User Centred Design...16 3.4 Riktlinjer...17 3.4.1 Användbarhet för webben...17 3.4.2 Datainmatning...18 3.4.3 Heuristics...18 3.5 Prototyping...20 3.5.1 Lofi- Vs. hifi-prototyper...20 3.6 Heuristisk utvärdering Vs. Användartestning...22 4 Designprocessen...24 4.1 Förstudier...24 4.1.1 Datainsamling...24 4.1.2 Kravspecifikation...25 4.2 Prototyp 1...26 4.2.1 Heuristisk utvärdering...28 4.3 Prototyp 2...31 4.3.1 Användartestning...33 4.4 Resterande krav för systemet...35 4.5 Prototyp 3...36 4.6 Nya krav!...38 4.7 Prototyp 4...39 4.7.1 Gruppdiskussion...40

4.8 Prototyp 5...41 5 Resultat...45 6 Diskussion...56 Referenslista...59 Appendix

1 Introduktion I dagens informationssamhälle finns stora krav från allmänheten på att all information ska finnas att tillgå. Om inte det går att få tag på information om ett företag finns inte företaget. Detta medför också att företag i sin tur ställer krav på att de på ett enkelt och snabbt sätt ska kunna sprida information till sina kunder. Historiskt sett har företag varit tvungna att kontakta exempelvis en tidning eller göra utskick via posten för att marknadsföra sig gentemot sina kunder. När Internet började användas som reklammedium krävdes att kunderna skulle klicka på en banner på en webbsajt för att kunna ta del av företagens budskap. Internet har varit det ledande informationsmediet de senast åren, men annan teknik används nu även som informationsspridare. Genom att använda sig av mobil kommunikation kan företag vara säkra på att den information som sprids kommer till rätt kund i rätt tid. I många fall sköts denna informationshantering av företag specialiserade på mobil marknadsföring, vilket gör att det finns en flaskhals genom vilken informationen måste passera. Om företagen själva kan hantera denna information och skicka ut den direkt till sina kunder, sparar företagen tid vilket i sin tur gör att kunderna får informationen snabbare. Det ökande antalet företag som arbetar med mobil marknadsföring behöver konkurrensfördelar för att kunna växa. 1.1 Bakgrund Vår uppgift i detta examensarbete var att utveckla ett administrationsverktyg för mobila innehållstjänster på uppdrag av företaget Micromarketing. Tanken är att denna applikation ska hjälpa kunderna att hantera de tjänster som Micromarketing erbjuder. Dessa tjänster är i form av utskick av olika sorters information via sms, mms eller wap. Exempel på detta kan vara sms-tävlingar kopplade till en marknadsföringskampanj, nerladdning av ringsignaler till mobiltelefonen eller digitala visitkort som kan sparas som en kontakt i mobiltelefonens adressbok. I nuläget så hanterar Micromarketing varje kund enskilt, vilket tar mycket tid och därmed kostar pengar. Administrationsverktyget tar bort denna hantering och låter kunderna administrera tjänsterna och dess innehåll på egen hand. Micromarketing arbetar med digitalt innehåll i form av mobil kommunikation och underhållning i olika former. Micromarketing hjälper företag att marknadsföra sina produkter och sig själva på nya och innovativa sätt. De har sitt huvudkontor i Stockholm, men ska öppna kontor i Göteborg inom kort. Deras vision är att arbeta med världens 100 största varumärken och skapa morgondagens mest självklara innehållstjänster. Vi presenterar i denna rapport hur vi har gått tillväga för att ta fram en designlösning för administrationsverktyget MMAS, Micromarketing Mobile Access Server. 9

1.2 Syfte Vårt uppdrag var att utveckla interaktionsdesignen för Micromarketings webbaserade administrationsverktyg för mobila innehållstjänster. 1.2.1 Problemformulering Hur ska ett administrationsverktyg för mobila innehållstjänster utformas för att nå så hög användbarhet som möjligt? 1.3 Avgränsningar Arbetet går ut på att skapa interaktionsdesignslösningen för Micromarketings administrationsverktyg MMAS. Vi kommer inte att implementera den färdiga slutprodukten och kommer inte heller att göra den grafiska utformningen av användargränssnittet eller programmering av detta system. 1.4 Förväntat resultat Målet var att skapa en interaktionsdesignslösning för administrationsverktyget MMAS, som skulle implementeras av Micromarketings utvecklare. Den ska ersätta den process som sker i dag, dvs. att användarna måste vända sig till Micromarketing varje gång som de vill modifiera innehållet i tjänsterna. 1.5 Disposition Kapitel 1 beskriver bakgrunden till detta arbete, vad arbetet går ut på och vår problemformulering. Kapitel 2 tar upp de olika metoderna som har använts i genomförandet av detta arbete. Kapitel 3 redogör för de teorier som ligger till grund för vårt utvecklingsarbete. Kapitel 4 beskriver vår designprocess från kravinsamling och utvärdering till slutprototyp. Kapitel 5 redovisar vårt interaktionsdesignsförslag Kapitel 6 diskuterar kring vår designprocess, våra problem och dess lösningar. 10

2 Metod Detta kapitel behandlar de olika metoder som vi har använt oss av i vårt utvecklingsarbete. 2.1 Prototyping I vår designprocess har prototyping varit det centrala design- och testverktyget. Preece, Rogers och Sharp (2002) menar att prototyping är ett bra kommunikationsverktyg för utvecklare samt ett bra verktyg för att testa nya idéer. En prototyp kan enligt dem vara allt från en pappersbaserad storyboard till en komplex, nästan färdig applikation. Vi har använt oss av prototyping för att låta testpersonerna interagera med den tänkta prototypen och utforska hur den är tänkt att fungera. Vi har använt oss av prototyping för att få svar på frågor och hjälp med att hitta alternativa lösningar på uppkomna problem. Genom att använda oss av metoden prototyping har det varit lättare för användarna att generera tankar och uttala sig kring våra designidéer (Williams 2002). Prototypmetoder är vanligtvis klassificerade i fidelity - vilken verklighetsgrad och interaktivitet som de erbjuder. Vilken fidelity som prototypen har bestäms av vidden, djupet och hur färdig prototypen är i jämförelse med den tänkta applikationen. Vi har använt oss av både hifi-prototyper (high fidelity) och lofiprototyper (low fidelity) i vår designprocess. En lofi-prototyp visar endast delar av den tänkta applikationen och tas fram utan att särskilt mycket energi läggs på utseendet. Hifi-prototyper är vanligtvis en första version av den färdiga applikationen. Dock behöver den inte innehålla alla delar. Vi har använt oss av prototyping så tidigt som möjligt i utvecklingsprocessen för att få fram förbättringsförslag på våra designidéer. (Rudd, Stern & Isensee, 1996) Då prototyping har varit vårt huvudsakliga designverktyg, redogör vi mer ingående om detta i teorikapitlet. 2.1.1 Paper prototyping Vi har valt att använda oss av paper prototyping som ett hjälpmedel genom hela designprocessen. Vredenburg et al. (2002) menar att denna metod är speciellt användbar i början av designcykeln, vilket vi har tagit i beaktning. Även senare i vår designprocess har vi använt oss av paper prototyping som ett kompletterande verktyg till våra hifi-prototyper. Virzi et al. (1996) menar att lofi-prototyper som exempelvis pappersprototyper kan vara effektiva under alla designprocessens stadier och inte enbart i processens inledande fas. Dumas och Redish (1999) hävdar att pappersprototyper ofta genererar lika många användbarhetsproblem som mer avancerade prototyper. En hifi-prototyp som uppfattas som ett färdigt system kan hämma användaren när det gäller att ge kritik. Vredenburg (2002) menar att användaren ger mer och bättre feedback när prototypen inte verkar vara färdig, genom att användaren då kan känna att deras åsikter kommer att tas i beaktande. 2.1.2 Datorbaserad prototyping Vi har valt att använda oss av datorbaserad prototyping för våra användartester. Dessa är i form av både datorprototyper med hög funktionalitet (hifi) och datorprototyper där funktionaliteten är låg (lofi). 11

En datorprototyp använder material som är tänkt att ingå i den slutliga produkten och liknar den slutliga produkten i stort. För att skapa snabba och enkla datorbaserade prototyper har valt att använda oss av programmet Macromedia Director. Vi har försökt att inte lägga för mycket tid eller använda för mycket resurser i skapandet av prototyperna, därför har vi bara valt att skapa hififunktionalitet i en begränsad del av systemet. En av fördelarna med vår hifiprototyp var att användaren själv kunde styra prototypen och inte behövde vänta på att vi testledare skulle styra händelseförloppet. En annan fördel med en hifiprototyp är att den kan fungera som en specifikation för systemet. (Preece, Rogers & Sharp, 2002) Hifi-prototyper tar längre tid att ta fram än lofi-prototyper, men de representerar det tänkta gränssnittet på ett bättre sätt. Hifi-prototyper kan göras vertikala där enbart ett antal funktioner finns med och är fullt implementerade, eller horisontella där de inte innehåller någon djupare funktionalitet men visar systemet i stort. Vi har använt oss av en vertikal prototyp för att se hur användarna interagerar med gränssnittet. En hifi-prototyp kan vara begränsad på många sätt men ska tillhandahålla gränssnittsinteraktivitet som kan hjälpa till att ta fram specifika designlösningar. (Rudd, Stern & Isensee, 1996) 2.2 Expertutvärdering Expertutvärdering som metod kan användas i designprocessens alla stadier. Antalet genomförda expertutvärderingar beror på projektets omfattning och resultatet av en expertutvärdering kan vara i form av en rapport innehållande identifierade problem och förslag till ändringar. Det krävs en viss tid för att sätta in expertutvärderarna i systemets krav och de uppgifter som systemet stödjer. Olika experter tenderar att finna olika problem i utvärderingen av ett gränssnitt och därför krävs minst tre till fem expertutvärderingar för att kunna täcka in de flesta problemen. (Shneiderman & Plaisant, 2005) Enligt Dumas och Redish (1999) ska en expertutvärdering genomföras av specialister inom människa-datorinteraktion som innehar kunskap om ett antal koncept som vanliga användare inte har. Experternas förståelse av koncepten inom deras specialistområde gör att de kan se mönster där andra bara ser isolerade händelser, vilket gör att de kan upptäcka saker som andra överhuvudtaget inte ser. Genom att förstå och ha kunskap inom detta område kan ett systems svagheter upptäckas i ett mycket tidigare skede i designarbetet än om man genomför användartester på den färdiga produkten. (Dumas & Redish, 1999) 2.2.1 Heuristisk utvärdering Vi använde oss tidigt i designprocessen av användbarhetsexperter för att gå igenom gränssnittet och se om det stämde överens med ett i förväg bestämt antal användbarhetsprinciper, så kallade heuristics (Vredenburg et al., 2002). De heuristics som vi har använt oss av är framtagna av Jakob Nielsen (1994), och redogörs för i teorikapitlet. Fördelen med den heuristiska utvärderingen är att det är en snabb och billig metod som upptäcker många användbarhetsproblem. För att en heuristisk utvärdering ska hitta tillräckligt många användbarhetsproblem krävs multipla utvärderingar. I vår utvärdering har vi använt oss av tre experter, vilka har bidragit till att finna många problem som inte annars skulle uppmärksammas. (Jeffries & Desurvire, 1992) 12

2.3 Användartestning Användartestning är en förutsättning för att skapa ett användbart system. I vårt användartest har användarna, sex till antalet, interagerat med en prototyp och deras beteende och subjektiva åsikter har studerats. Vi har undersökt de användbarhetskrav som kan ställas på systemet, från hur användarnas mål uppfyllts och hur de interagerat med prototypen, till hur deras subjektiva reaktioner var. (Rosson & Carroll, 2002) Vid användartest är deltagarna ofta placerade i en för dem okänd omgivning. De kan till följd av detta dra felaktiga slutsatser om vad som förväntas av dem, vilket kan leda till att de känner en vilja att imponera och därför underrapportera uppkomna fel. För att få testdeltagarna att känna sig bekväma i testsituationen har vi valt att genomföra testerna i deras hem eller arbetsmiljö,. Det är inte ovanligt att testdeltagare kämpar sig genom ett test med svårigheter för att efter testet uttrycka att systemet var lätt att använda och att inga större problem uppstod. Likväl är det inte ovanligt att användare i ett test genomför testet utan problem för att sedan uttrycka att de inte tyckte om systemet. (Dicks, 2002) Innan vi genomförde testerna berättade vi för tespersonerna att det inte var något färdigt system som skulle testas, och att anledningen till att vi genomförde testen var att vi ville lokalisera så många problem som möjligt i prototypen. Det är bäst att använda sig av en tidig, fungerande version av systemet men det går att få tillräcklig användarfeedback även om det inte finns något fungerande system att tillgå. Vi har gjort användartester med hifi- samt lofi-prototyper. Lofiprototyperna var i form av både pappersprototyper samt en så kallad scenario machine. En scenario machine liknar de test som kan göras med pappersprototyper men görs på datorn, och innehåller enbart så mycket interaktivitet att användarna kan navigera sig från en sida till nästa med hjälp av ett förutbestämt scenario. (Rosson & Carroll, 2002) Mer om användartestning finns att läsa om i teorikapitlet. 2.4 Gruppdiskussion För att få kommentarer på det skapade gränssnittet och dess funktioner genomförde vi även en kombinerad variant av fokusgrupp och användartest med fyra deltagare. I en fokusgrupp bollar deltagarna idéer mellan sig och därigenom genererar de mer tankar och idéer än vad de hade gjort om de varit ensamma (Kuniavsky, 2003). Vi ville med denna metod inbjuda till en öppen diskussion mellan testpersonerna. Deltagarna gick tillsammans med oss igenom systemet steg för steg, samtidigt som de kommenterade de problem som de upplevde med gränssnittet. 2.5 Wizard of Oz Enligt Snyder (2003) innefattar tekniken Wizard of Oz alla tester där en människa agerar mellanhand mellan användare och maskin. Vid test av de prototyper som inte innehöll någon verklig funktionalitet valde vi därför att använda oss av wizard of oz för att styra händelseförloppet. Snyder (2003) menar att denna teknik ofta används för att genomföra tester med användare innan den underliggande teknologin är utvecklad. Precis som namnet antyder, genomför en person manipulationer för att få tänkta händelser att uppstå och skapar därmed känslan av att datorn styr händelseförloppet. Då vi använde oss 13

av denna teknik var vi inte dolda utan vi gick igenom ett scenario och styrde händelseförloppet tillsammans med användarna. 2.6 Think aloud En användbar teknik vid genomförande av användartester är det så kallade think aloud-protokollet. Tekniken bygger på att testledaren ber användaren att uttrycka sina tankar med ord under tiden som de genomför uppgifterna. (Snyder, 2003) För att förstå användarna i utförandet av användartestningen, har vi valt att använda think aloud-protokoll. Snyder (2003) påpekar att människan normalt inte verbaliserar sina tankar. Hon menar att det är helt i sin rätt att be användaren tänka högt under ett användartest, bara man är medveten om att de flesta användare inte kommer att kunna genomföra tekniken perfekt. Ett bra tillvägagångssätt är att prata med användaren under genomförandet av ett användartest av en prototyp. Det är då viktigt att tänka på hur man talar med användaren under testet. Istället för att ge medhåll, sätta sig emot eller förklara, har vi ställt frågor och uppmanat användaren att utforska systemet samt agera naturligt gentemot gränssnittet som testas. Det kan vara lätt att som testledare helt oavsiktligt ge användaren vägledning om vad de är förväntade att göra. Om detta är fallet kan slutsatsen, att användaren gjort de korrekta handlingarna på egen hand, felaktigt göras. (Snyder, 2003) För att undvika detta har vi försökt tänka på vilken effekt våra uttalande och agerande skulle ha på användaren vid genomförandet av testet. 2.7 Urval För att nå ett bra resultat i våra tester bör urvalet stämma överens med vissa kriterier. De personer som ska delta i undersökningarna bör ha rätt bakgrund för att korrekt resultat ska genereras och en bra analys ska kunna göras. I den heuristiska utvärderingen är det viktigt att använda personer med relevant kunskap. Deltagarna i den heuristiska utvärderingen är magisterstudenter i interaktionsdesign. Vi har använt oss av dessa för att vi ska kunna få ut relevanta kommentarer och därigenom få användbarhetsproblem specificerade. I användartestningen ville vi använda oss av verkliga användare för att kunna relatera de framkomna problemen till de verkliga användningssituationerna. Då vi inte hade tillgång till verkliga användare fick vi försöka hitta testdeltagare som på så många sätt som möjligt liknade de verkliga användarna och hade liknande karaktäristika. I gruppdiskussionen ville vi få expertkommentarer på användargränssnittet. Därför ville vi hitta deltagare som hade stor kunskap inom gränssnittsdesign och programvara. Deltagarna valdes ut från data/it-sektionen på Chalmers tekniska högskola. 14

3 Teori I detta kapitel tar vi upp teorier som stöder vår designprocess samt mer ingående beskrivningar av de teorier som våra metoder baseras på. 3.1 Interaktionsdesign Preece, Rogers och Sharp (2002) definierar interaktionsdesign som design av interaktiva produkter som hjälper människan i deras vardag och arbetsliv. De menar att interaktionsdesign är att skapa användarupplevelser som förstärker sättet människor arbetar, kommunicerar och interagerar. Enligt Cooper och Reimann (2003) innefattar interaktionsdesign: Definition av en produkts beteende och användning Hur användandet av produkten påverkar dess användare Att skapa förståelse för dialogen mellan produkt, användare och dess omgivning Interaktionsdesign angriper designarbetet i ett målinriktat perspektiv: Genom en förståelse av hur och varför användaren vill bruka det som skapas Genom att stödja användarna och deras krav Genom att titta på framtida behov och se saker som de kan komma att bli och inte enbart hur det är för stunden. (Cooper & Reimann, 2003) 3.2 Användbarhet The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. (ISO 9241-11) Med användbarhet menas i vilken utsträckning en produkt kan användas av specificerade användare för att uppnå specificerade mål med effektivitet (effectiveness), effektivitet i förhållande till nedlagda resurser (efficiency) och tillfredsställelse (satisfaction) i en specificerad användningskontext. (ISO 9241-11) Enligt Dicks (2002) bör att ett system uppfylla vissa kriterier för att kunna kallas användbart: 1. Lätt att lära. 2. Användbart 3. Lätt att använda. 4. Tillfredställande att använda. Det är viktigt att tidigt sätta upp klara mål för att uppfylla kriterierna för användbarhet. Genom att göra detta kan designprocessen effektiviseras och hjälper alla i designprocessen att arbeta mot dessa gemensamma mål för att uppnå kraven för användbarhet. (Meyhew, 1999) 15

3.3 UCD User Centred Design Bild 1: ISO 13407 UCD Process Human-centred design processes for interactive systems (ISO 13407) är en standard som tillhandahåller riktlinjer för användarcentrerad design (bild 1). (Jokela et al.,2003) UCD-processen består av fyra grundläggande steg: analys, design/prototyputveckling, implementering och evaluering (Jokela et al., 2003). Pradeep (1998) talar om hur viktigt det är att tidigt i processen fokusera på användarna och deras krav. Han menar att målet är att förstå användarnas beteende, karakteristiska drag och förhållningssätt till de uppgifter de utför samt i vilken omgivning uppgifterna utförs och varför. Analys Analysfasen innefattar aktiviteter som hjälper designteamet att få kunskaper om de specifika användare som de designar för, de uppgifter de utför och i vilken omgivning de befinner sig i. Ett antal metoder används för att analysera användaren och de uppgifter systemet ska stödja. Dessa metoder sträcker sig inom ett stort spann, från enkla diskussioner med representativa användare till fältstudier där användarna blir observerade och intervjuade i den verkliga omgivningen. Resultatet från användaranalysen resulterar i en användarprofil vilken beskriver användarens specifika egenskaper och krav. Resultaten från kravanalysen resulterar i en kravspecifikation som beskriver vilka uppgifter det utvecklade systemet måste stödja och hur användaren utför dessa uppgifter. (Pradeep, 1998) 16

Design/Prototyputveckling En prototyp av det nya användargränssnittet utvecklas baserat på de uppgifter som analysen har genererat. I detta skede beslutas hur systemet ska se ut och fungera för att tillmötesgå användbarhetskraven. Denna prototyp kan bestå av en pappersprototyp eller en fungerande interaktiv prototyp. Dessa prototyper utvecklas i en iterativ process tills användarnas krav och förväntningar uppnås. (Pradeep, 1998) Implementering Efter att ha utvecklat en prototyp som uppfyller kraven, implementeras prototypen till ett fullt fungerande användargränssnitt. I denna fas skapas dokumentation i form av exempelvis detaljspecifikation, funktionsbeskrivning eller diagram. (Pradeep, 1998) Evaluering Under analysfasen planerar utvecklarna för användbarhetstestning. Evaluering är en iterativ process som sker genom hela den användarcentrerade designprocessen. (Pradeep, 1998) 3.4 Riktlinjer För att nå ett bra resultat i designprocessen finns det olika riktlinjer till stöd för utvecklandet. De hjälper utvecklarna att följa de standarder som är satta och genom detta förbättras användbarheten. 3.4.1 Användbarhet för webben Brinck, Gergle och Wood (2002) menar att det finns flera aspekter att ta hänsyn till för att uppnå maximal användbarhet vid utvecklandet för webben. Något som de menar är viktigt att ta hänsyn till är användarens förmåga att hålla saker aktiva i minnet. Människan har en begränsad förmåga att hålla mycket information under en längre tid i sitt korttidsminne. Detta gör att informationen bör vara ordentligt genomtänkt och välstrukturerad. Om det existerar för mycket krav på att tidigare händelser måste hållas i minnet är det lätt att användaren tappar bort sig i den pågående aktiviteten. Ju längre tid saker ska hållas aktiva i minnet, desto större är risken att de glöms bort. (Brinck, Gergle & Wood, 2002) Webbapplikationen bör innehålla relevanta element och presentera dess innehåll i en logisk ordning samtidigt som dess layout är ett viktigt element för användbarheten. Layouten påverkar starkt användbarheten, då ett överhopat och ostrukturerat gränssnitt skulle göra användarna förvirrade och de skulle få problem att utföra uppgifter eller finna önskad information. För att skapa användarvänlighet i en webbapplikation är det viktigt med tydlig och intuitiv navigation, konsistens och enkelhet. (Brinck, Gergle, & Wood, 2002) På vilket sätt en användare navigerar i en applikation är beroende av de uppgifter som användaren planerar att genomföra (Brinck, Gergle & Wood, 2002). Viktigt är att användarna förstår var de befinner sig i strukturen, vilka uppgifter de har utfört och vad de kan göra i nästa steg. Enligt Nielsen (2000) är det vanligt att använda sig av understrukna länkar för navigering. När navigeringen består av understrukna länkar är det viktigt att inte låta annan text än den klickbara vara understruken. Om detta skulle vara fallet blir applikationen inkonsekvent och användaren blir lätt förvirrad. Det är viktigt med en väl genomarbetad och strukturerad navigation för att skapa ett användbart gränssnitt. (Nielsen, 2000) 17

3.4.2 Datainmatning Då användaren ställs inför uppgiften att mata in information finns flera kriterier att ta hänsyn till. Det är viktigt att tänka på hur information ska matas in då det gäller att optimera mot fel, minimera användarens tidsåtgång och undvika frustration. Shneiderman och Plaisant (2005) tar upp ett antal guidelines för datainmatning och då vårt system bearbetar inmatad information har dessa riktlinjer stor relevans: Consistency of data-entry transactions Liknande funktioner, avgränsningar och förkortningar bör användas på ett konsekvent vis. Minimal input actions by user Mindre antal inmatningsfunktioner ökar systemets effektivitet och minimerar riskerna för fel. Det är bättre att använda en knapptryckning eller ett musval istället för en längre inmatning av tecken. Val från en lista, t.ex. drop-down, minimerar minnesbelastningen och hindrar för fel vid inmatning av tecken. En annan viktig aspekt att ta hänsyn är hur redundant data hanteras. Det irriterar användaren att behöva behandla samma data på mer än ett ställe. Om så sker, borde systemet automatiskt kopiera informationen åt användaren, samtidigt som möjligheten att redigera data måste existera. Minimal memory load on user Vid inmatning av data, ska användaren inte behöva hålla mycket information i minnet under en längre tid. Compability of data entry with data display Formen på den inmatade informationen ska ha en nära samhörighet med den visualiserade informationen. Flexibility for user control of data entry Erfarna datoranvändare kan föredra att själva kunna kontrollera i vilken följd informationen ska matas in. Viktigt är dock att använda flexibilitet med en försiktighet eftersom det strider mot principen av konsistens. (Shneiderman & Plaisant, 2005) 3.4.3 Heuristics Heuristisk utvärdering är en informell utvärderingsteknik som är skapad av Jakob Nielsen, där experter genom att följa riktlinjer utvärderar gränssnittets användbarhet. Nielsens heuristics är ganska generella och är skapade för att vara enkla att lära, eftersom en viktig faktor för användbarhetsutveckling är att den lätt kan implementeras i olika utvecklingsprocesser. (Preece, 2002) Vi har valt att behålla dessa heuristcs i dess ursprungliga form för att inte påverka dess innehåll. Nedan följer Nielsens (1994) heuristics. Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow 18

real-world conventions, making information appear in a natural and logical order. User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. Enkelt beskrivet ska användargränssnittet enligt Nielsens heuristics uppfylla följande kriterier: 1. ge återkoppling 2. använda ett språk användaren förstår 3. ha tydligt markerade utgångar 4. vara konsekvent 5. förebygga fel 5. minimera användarens minnesbörda 6. använda genvägar 8. skapa enkel och naturlig dialog 19

9. använda tydligt formulerade felmeddelanden 10. tillhandahålla hjälp och dokumentation Utvärdering med hjälp av heuristics är inte en metod som genomförs för att ge exakta svar, utan bör snarare ses som en hjälp att placera användaren av metoden i närheten av vad som är korrekt och användbart (Gibbon & Higgins 1996). 3.5 Prototyping Efter att ha samlat in nödvändig kravinformation, är det bra att testa idéerna genom att bygga prototyper. Prototyping är en process som sker i flera steg, med återkoppling mellan stegen och där kritik och utvärdering genomförs efter varje förändring av prototypen. Metoden innebär upprättandet av en modell över ett problemområde som representeras i olika medier t.ex. skisser, ritningar, skalmodeller och diagram. Utvecklingen av prototypen sker gradvis i små steg och utvärderas kontinuerligt. Detta sker fördelaktigt genom tester och simuleringar av förlopp samt steg för steg gå djupare på detaljnivå och öka konkretionen. Ju fler iterationer desto bättre bör den slutliga produkten bli. (Lundequist, 1995) (Preece, Rogers & Sharp, 2002) Enligt Vredenburg et al. (2002) är huvudanledningen till att använda prototyping i designprocessen att samla in feedback från användarna under tiden som designen växer fram. Dumas och Redish (1999) menar att prototyping är ett väldigt bra verktyg för att utvärdera alternativa koncept. De anser även att det är onödigt att lägga för mycket tid på prototypen för att få den att likna den färdiga produkten i funktionalitet. 3.5.1 Lofi- Vs. hifi-prototyper Lofi-prototyper är användbara för visualisering av designidéer i ett tidigt skede av designprocessen och kräver inte någon längre tid att utveckla. En Lofi-prototyp kan vara både horisontal eller vertikal och kan vara skapad i papper och andra lofimaterial eller genom ett enkelt programmeringsverktyg. (Sefelin et al., 2003) Hifi-prototyper är interaktiva och används för utveckling och testning. Användaren kan interagera med prototypen och den kan se ut som en färdig applikation. När användaren sitter framför en hifi-prototyp får han eller hon förväntad feedback på utförda handlingar och prototypen reagerar och beter sig som den framtida produkten kan tänkas göra. I stort så får användaren en känsla av hur produkten kommer att fungera, och kan genom detta ge feedback på hur användargränssnittet ska förbättras. (Rudd, Stern, & Isensee, 1996) Lofi-prototyper är oftast begränsade i funktion och interaktion. De är gjorda för att representera koncept, designalternativ och skärmlayout och inte för att testa användarens interaktion med systemet. Huvudanledningen till att använda lofiprototyper är att de går snabbt att skapa. Lofi-prototyper ska kunna lösa 80 % av de största gränssnittsproblemen och har ett stort värde då de används för tidig kravinsamling och i analysfasen av designprocessen. De kan snabbt och kostnadseffektivt användas för att ta fram idéer om hur en produkt kan fungera. Lofiprototyper kan användas för att undersöka tidiga funktionskoncept och för att visa för utvecklarna hur de ska visualiseras för användaren. (Rudd, Stern & Isensee, 1996) Sefelin et al. (2003) menar att användartester med datorbaserade prototyper ger deltagarna en större frihet i att utforska systemet de testar och kräver även mindre involvering av testledaren vilket bidrar till att testpersonerna känner sig mindre 20

övervakade. De menar även att om pappersprototyper många gånger är billigare och går snabbare att utveckla kvarstår fortfarande problematiken att testpersonerna känner sig övervakade och att ett större arbete krävs av testledaren. Snyder (2003) säger att till skillnad från hifi prototyper är lofi-prototyper inte skapade att upplevas som det verkliga gränssnittet - det går omöjligen uppfatta en bunt med papper för ett verkligt system i form av en programvara. Då en prototyp ser ut att vara en färdig produkt kan det tendera till att användaren vid testning fokuserar på innehåll och visuella detaljer i prototypen istället för konceptuella aspekter och funktionalitet. Detta kan undvikas genom att använda lofi-prototyper som har en låg nivå av innehåll och estetik. (Kinns & Hamliton, 2002) Det tar ofta lång tid att vänta på en färdig fungerande version av systemet, vilket då medför att det inte går att genomföra användartester på det färdiga systemet förrän utvecklingen har kommit en bra bit på vägen. Ett alternativ är då att använda sig av ett datorbaserat prototypverktyg. En sådan prototyp används enbart för användartesting och kommer inte att bli någon del av det slutliga systemet. Ett fungerande system skapar en känsla av realism till testuppgifterna, vilket gör att testpersonerna kan bete sig relativt naturligt och obehindrat. Instruktionerna inför uppgiften bör vara minimala eftersom systemet i sig ska guida testdeltagarna genom uppgiften. (Rosson & Carroll, 2002) Macromedia Director är ett verktyg som traditionellt använts som prototypverktyg. Directors programmeringsspråk Lingo är komplext och kan användas till att visualisera och demonstrera bl.a. funktionalitet och interaktionstekniker. Man kan antingen använda Director till enkla lofi-prototyper, liknande bildspel, där man med hjälp av Lingo hoppar mellan olika bildrutor, eller så kan man använda programmeringsspråket till att skapa komplex och fungerande interaktion i hifiprototyper. (Löwgren & Stolterman, 2004) Det skiljer sig inte nämnvärt på vilken sorts användbarhetsproblem som lofi- och hifi-prototyper genererar. Det kan dock skilja i antal identifierade problem beroende på vilken typ av prototyp som används i användartester. Att helt förlita sig på lofi-prototyper i en utvecklingsprocess kan därför vara en fara. Lofiprototyper är i sin natur begränsade i funktionalitet men kan ändå vara användbara för användartestning. Användandet av metoden prototyping är effektivt i fastställandet av användbarhetsspecifikationer och fungerar även som ett stöd för att skapa en förståelse över systemets funktioner och krav. I alla lägen är det dock viktigt att designern eller användbarhetstestaren noggrant tänker igenom vilken metod som används för att identifiera ett systems svagheter och krav. (Virzi et al., 1996) Användarna känner oftast till vilka uppgifter som systemen ska hjälpa dem med men kan inte alltid uttala dessa krav på sätt som är passande för gränssnittsdesignen. En lofi-prototyp ger dem en bild av vad som går att genomföra och ger dem möjligheten att diskutera detta samt ge kritik på denna. (Rudd, Stern & Isensee, 1996) Sefelin et al. (2003) menar att dator- och pappersprototyper leder fram till ungefär lika många användarkommentarer om de båda är i form av lofi-prototyper. De har dock kommit fram till att användarna föredrar datorprototyper då det är enklare att interagera med dem. En viktig del av användartestning är att få deltagarna att känna sig bekväma och därför menar de att datorbaserade lofi-prototyper kan vara att föredra men att faktorer som enkelheten och snabbheten i utvecklandet talar till 21

pappersprototypens fördel. Vilken nivå av fidelity som väljs beror dock på vilka användarna är och i vilken nivå utvecklingsarbetet befinner sig. (Sefelin et al., 2003) 3.6 Heuristisk utvärdering Vs. Användartestning Användartester påvisar allvarligare problem än heuristiska utvärderingar och lokaliserar problem som verkligen påverkar användaren (Jeffries & Desurvire, 1992). En svaghet med heuristisk utvärdering är att den inte involverar representativa användare. Om enbart heuristisk utvärdering används i designprocessen kan stora användbarhetsproblem förbli oidentifierade. Bland de problem som hittas i den heuristiska utvärderingen kan finnas sådana som de verkliga användarna inte kommer att uppleva, vilket gör att man åtgärdar saker i onödan. En heuristisk utvärdering kan vara ett enkelt sätt att snabbt få en idé om hur designen ska utvecklas. (Vredenburg et al., 2002) En risk med att använda sig av experter i utvärderingen är att de kan ha svårt att ha en verklig förståelse för slutanvändarnas krav och situation. För att uppnå ett så verkligt resultat som möjligt, är det viktigt att välja experter med en så nära anknytning till systemet, dess krav och omgivning som det går. Dock kan även erfarna expertutvärderare ha svårigheter med att förstå den verkliga användaren, och särskilt hur förstagångsanvändaren kommer att agera. (Shneiderman & Plaisant, 2005) Användartestning kan användas för att öka förståelsen kring användbarhetsproblem i designen och förbättra designteamets kunskaper vad det gäller de tekniska aspekterna av produkten. Metoden stimulerar även samarbetsförmågan mellan de skilda delarna i teamet. (Dumas, 1989) Vid genomförandet av ett användartest bör testdeltagarna representera de verkliga användarna och genomföra verkliga uppgifter. Testledarna observerar och dokumenterar vad deltagarna gör för att slutligen analysera resultatet och ge konkreta förslag på hur uppkomna problem bör åtgärdas. Ett test genomfört på så få som fyra till fem användare påvisar så mycket som 80 % av ett systems användbarhetsproblem. Användartestning kan vara tidskrävande, men den mängd problem som upptäcks gör att testning lönar sig i längden. Fel som upptäcks i ett tidigt skede är billigare och enklare att åtgärda. Eftersom det oftast testas hur väl en användare genomför en mindre del av ett systems uppgifter finns det en fara i att testet inte effektivt nog beskriver systemets alla problem och kvalitéer. Test i mindre skala identifierar inte alla problem men vid genomförandet av iterativ testning kan det flesta problem identifieras. (Dicks, 2002) Beroende på var man befinner sig i utvecklingsprocessen eller beroende på vilka resurser man har, kan valet av utvärderingsmetod variera. Det går snabbare att använda sig av experter medan det krävs lite mer resurser för att genomföra ett användartest. Valet av metod kan även styra vilka problem som uppmärksammas. (Dumas & Redish, 1999) De huvudsakliga skillnaderna mellan de olika utvärderingsmetoderna är enligt Dumas och Redish (1999) att: Användartester finner mer användbarhetsproblem än heuristisk utvärdering. Användartester upptäcker mer globala problem än heuristisk utvärdering. 22

Användartester hittar mer unika problem än heuristisk utvärdering. Användartester finner mindre lokala problem än heuristisk utvärdering. Användartester tar längre tid att utföra än heuristisk utvärdering, men är kostnadseffektiv gällande antal problem som hittas. Heuristisk utvärdering blir mer kvalitativ när flera användbarhetsexperter, oberoende av varandra, har genomfört dem. Heuristisk utvärdering hittar mer små problem än användartestning men dessa problem behöver inte ha någon inverkan på hur användarna uppfattar systemet. Genom att använda en kombination av både användartester och heuristisk utvärdering så får man en bättre utvärdering genom att utnyttja de två skilda metodernas styrkor. Om det bara genomförs användartester så riskerar den färdiga produkten att dras med oupptäckta små lokala problem. Dessa problem kan vara av sådan art att det inte stör användaren men många sådana problem kan göra att designen uppfattas som ofärdig. (Dumas & Redish, 1999) 23

4 Designprocessen I detta kapitel redogör vi för utvecklingen av administrationsverktyget MMAS. 4.1 Förstudier Efter första kontakten med Micromarketing visste vi inte mycket om vad uppdraget skulle innebära. På deras hemsida stod det att läsa att: Micromarketing arbetar med digitalt innehåll och innovativa sätt att distribuera det samt med mobil kommunikation och underhållning i olika former. Den initiala kontakten gav oss känslan av att det var ett företag som verkligen satsade på att växa inom sitt område. För att ta fram fakta om vad uppdraget innebar så bokade vi ett möte med Debbie Lygonis, en av grundarna av Micromarketing och den som vi hade varit i kontakt med från första början. Hon berättade att Micromarketing skulle behöva vår hjälp med att designa ett gränssnitt till ett administrationsverktyg för mobila innehållstjänster, vilket vi ansåg vara ett intressant och spännande uppdrag. Vi bestämde att vi skulle träffas igen, denna gång tillsammans med deras utvecklare, Daniel Niklasson. Mötet skulle ge oss svar på vad som skulle utvecklas - om det skulle vara ett program eller en webbapplikation och vilka tjänster som det skulle stödja. 4.1.1 Datainsamling Vid nästa möte var de entusiastiska över att vi tog oss an uppdraget och presenterade övergripande vad de ville ha ut av arbetet. Vi presenterade även våra mål med examensarbetet och vad vi ville få ut av det. Våra gemensamma mål: Vi skulle ta fram interaktionsdesignen för en webbapplikation för administrering av mobila innehållstjänster. Vi skulle genomföra användartester och få tillgång till deras verkliga kunder till våra undersökningar. Deras utvecklare, Daniel Niklasson, skulle genomföra programmeringen. De skulle hyra in en grafisk designer för den grafiska utformningen av applikationen. Vi skulle genomföra ett slutligt användbarhetstest och genomföra utvärdering av applikationen när den blivit implementerad för att se om målen blivit uppfyllda. Debbie Lygonis skulle vara vår företagskontakt samt handledare. Vi skulle arbeta på egen plats då de inte har kontor i Göteborg. Utvecklingsprocessen skulle ske iterativt i ett nära samarbete med Micromarketing och med tillgång till deras kunder. Vi skulle genomföra tester i omgångar för att uppnå så bra användbarhet som möjligt. Preece (2002) menar att ju fler iterationer som genomförs desto bättre bör slutresultatet bli. Vi gick igenom en presentation av företaget och de tjänster som de tillhandahöll. Vad som skulle ingå i applikationen Micromarketing Mobile Access Server (MMAS) presenterades övergripande (bild 2). En detaljerad kravspecifikation skulle skickas till oss senare. 24

MMAS - Micromarketing Mobile Access Server Content Management SMS Engine (marketing, information, competitions etc) Mobile Membership Card Administration Wap Engine (WAP tester etc) Mobile Businesscard Administration Premium SMS/WAP Billing Mobile Access Server User Interface MicroMarketing Access Server Customer Database Service Secure logon from any computer Customer Database Each service can be activated to fit customers need Wap templates SMS templates for marketing, competitions etc Comprehensive Statistics Billing administration Customer Bild 2. MMAS Den målgrupp som applikationen skulle riktas till var viktig att definiera för att ett fullgott slutresultat skulle kunna uppnås. För att kunna börja utvecklingen av interaktionsdesignslösningen så behövde vi ta reda på vissa fakta om deras kunder - hur ofta de använder Micromarketings tjänster, hur ofta de kommer att använda applikationen samt vilken kunskapsnivå de ligger på. Målgruppen för MMAS: Jobbar på marknadsföringsavdelning Från enmansföretag till storföretag Har medelgod datavana Använder sig av tjänsterna någon gång i veckan eller ännu mer sällan Kommer att använda sig av applikationen i samma omfattning, möjligtvis lite oftare 4.1.2 Kravspecifikation Då vi genomförde mötet med Micromarketing samlade vi in grundfakta om företaget och deras kunder. Detta kompletterades med en kravspecifikation (appendix I) som de skickade till oss i efterhand. Kravspecifikationen specificerade vissa delar av modulen SMS Engine. Delarna i SMS Engine: Informera i vilken användaren kan skicka ut information till slutkunden då han eller hon beställer denna tjänst. Tävla i vilken slutkunden kan vara med i en tävling genom att först skicka in en beställning. Ladda ner i vilken slutkunden kan beställa en bakgrundsbild till sin mobiltelefon genom att skicka in en beställning. 25

Dessa tjänster beställs av slutkunden genom att de skickar in ett specifikt prefix via sms, och tjänsten distribueras därefter till slutkunden via sms. I fallet Ladda ner används mms för distribution till slutkunden. De delar som alltid ska finnas med i innehållstjänster från MMAS är prefix och kostnad. Prefixet är de ord som slutkunden skickar in via sms för att beställa tjänsten, t.ex. GRANIT BESTÄLL. Kostnaden är det som slutkunden får betala för den beställda tjänsten. Mer specificerat ska de olika delarna i SMS Engine innehålla: Informera prefix, kostnad, och sms-text. Grundprefixet GRANIT ska reserveras för denna tjänst. Tävla prefix, kostnad, fråga samt bekräftelse på mottaget svar. Ladda ner prefix, kostnad samt en av användaren vald bakgrundsbild SMS Engine var enbart en del av hela applikationen och vi kunde inte gå in närmare på de andra delarna i MMAS på grund av att vi i detta läge inte fått någon information om vad dessa skulle innehålla. 4.2 Prototyp 1 De krav vi hade fått från Micromarketing på delen SMS Engine fick fungera som en grund i utvecklandet av gränssnittsdesignen. Vi diskuterade igenom dessa krav tillsammans med tankarna från mötet för att stämma av med varandra att vi hade en samstämmig syn på vad Micromarketing ville ha utvecklat. För att vidare kunna förmedla våra tankar mellan oss så valde vi att använda paper prototyping som ett kommunikationsverktyg. Lofi-prototyper som papppersprototyper är användbara för visualisering av designidéer i ett tidigt skede av designprocessen (Sefelin et al., 2003). Vi skissade därför ner våra designtankar för att få en bild av det tänkta systemet. Genom olika skisser testade vi våra designidéer. En fördel i att använda lofiprototyper är att det går att visa generella koncept snabbt och enkelt (Vredenburg et al., 2002) (Rudd, Stern & Isensee, 1996). Placeringar av objekt, gränssnittets struktur och dess funktioner var element vi testade. Under tiden vi skissade på designförslag kom saker som inte nämnts i kravspecifikationen fram, som t.ex. visualisering av antal sms och sms-längd. Vi testade oss även fram till hur textinmatningen skulle se ut. Valet föll på att göra textinmatningsfältet i samma storlek och form som en mobilskärm, för att i den mån det gick visualisera den inmatade informationen på så verklighetstroget sätt som möjligt (Shneiderman & Plaisant, 2005). En funktion som vi ansåg vara nödvändig var möjligheten att skriva ut viktig information. Vi såg även ett behov av dialogrutor och frågetecken för att ge hjälp och feedback till användaren vid behov. Enligt Shneiderman och Plaisant (2005) är det bra att hålla nere antalet sätt att mata in information. För att förhindra risken för fel ville vi därför använda oss av drop-downmenyer, radiobuttons och check boxes i största möjliga mån. Vi ville lyfta upp den hierarkiska strukturen till en plan yta för att användaren inte ska behöva gå mellan olika nivåer i strukturen. Enligt Brink, Gergle och Wood (2002) är det viktigt att ta hänsyn till användarens förmåga att hålla saker i minnet och all nödvändig information ska kunna finnas tillgänglig hela tiden. Vi valde därför att dela in ytan i tre sektioner där de olika uppgifterna utförs. 26