Metod / p2. grupp 6. Johan Toresson, Makfire Petrovci, Oscar Lundahl, Palle Frid Svensson, Theo Hultberg

Transkript

1 Metod / p2 grupp 6 Johan Toresson, Makfire Petrovci, Oscar Lundahl, Palle Frid Svensson, Theo Hultberg

2 PROBLEMET Användarupplevelse och menystruktur är två extremt viktiga, och komplexa, aspekter hos mobiltelefonanvändning. Det första problemet vi hade var att verkligen förstå användarupplevelsen och menystrukturen hos Sony Ericsson K750i. Vi tyckte att detta var problematiskt eftersom vi handgripligen inte hade tillgång till någon sådan modell, utan endast en Flash-baserad variant som dessutom var begränsad till enbart några få tillgängliga funktioner. Detta medförde att vi inte fick någon känsla för mobilens egentliga brister och möjligheter samt interaktionen med knappar och menysystem, varför vi har fått föreställa oss detta själva. Detta har dels gjort att vi i vår designprocess lättare har kunnat gå utanför ramarna för Sony Ericssons system, men även att vi kanske har gått allt för långt utanför Sony Ericssons paradigm eller att det kan vara svårare att navigera med vårt menysystem än vad vi faktiskt kan tänka oss själva. Vi inledde arbetet genom att efter föreläsningen, där vår uppgift presenterades, bestämma oss för att var och en för sig under några dagar skulle uppmärksamma de olika menysystem som vi interagerade med, inte bara mobiltelefoner utan menysystem av alla sorter. Vi skulle fundera kring vad som var bra och vad som var dåligt med dem och varför vi tänkte så. Tyvärr så glömde vi vi helt enkelt av att skriva ned våra upptäckter, så när vi väl möttes igen och skulle redovisa inför varandra hade vi inget skriftligt att redogöra för. Vi bestämde oss då för att det var viktigt att någon av oss skrev ned uppgifterna och att vi skulle skriva ned milstolpar då vi skulle ha avklarat olika uppgifter. I samma andetag bestämde vi oss för att gemensamt ta reda på vad det egentligen var för problem vi skulle lösa. Vi genomförde då metoden mer eller mindre planlöst för att gå djupare in i projektet. Vi upptäckte dock att vi använde denna metod alldeles för tidigt i designprocessen, då vi inte

3 kunde komma vidare efter det att vi hade genomfört den. Vi påbörjade därför en brainstormingsession för att få klarhet i vilken metod som kunde användas för att identifiera problemet. Vi kom fram till att en brainstormingsession skulle kunna innebära att vi fick reda på vad vi som grupp tyckte var viktiga aspekter hos användarupplevelse och menystrukturer hos mobiltelefoner i allmänhet och Sony Ericsson K750i i synnerhet, och att vi därmed skulle kunna identifiera vilka problem som finns gällande dessa aspekter. Det visade sig efter sessionen, att problemen, hur öka användarupplevelsen hos mobiltelefonanvändandet och hur skapa en menystruktur där funktionerna sorteras utifrån vårt användarupplevelseparadigm, först borde delas upp och analyseras var för sig innan de sedan skulle återanslutas. På så sätt skulle det bli enklare att analysera det annars allt för komplexa området. Vi var medvetna om att denna uppdelning skulle kunna innebära svårigheter att kunna återkoppla aspekterna igen, men genom att hela tiden försöka se hur användarupplevelsen påverkar menystrukturens konstruktion får vi ett paradigm som hela tiden genomsyrar uppdelandet av funktionerna. I och med identifierandet av problem påbörjades divergensfasen. 2

4 Divergensfasen Användarupplevelsen Vi använde resultatet av den tidigare genomförda metoden eftersom vi nu hade identifierat problemet. I och med att vi hade fått väldigt konventionella lösningar, som att ta bort ikoner och minska användandet av animationer, och eftersom liten tid förflöt mellan metodens utförande och tolkningen av detsamma, tror vi att resultatet inte blev chockerande annorlunda än om vi hade gjort om metoden på nytt. Därför kunde vi använda oss av resultatet fast metoden hade utförts i en tidigare fas. Eftersom resultatet på föregående metod blev så konventionell och övergripande använde vi oss av five why s-metoden då vi misstänkte att detta kunde ge oss mer ingående svar på vad vi egentligen ville få fram. Varje person blev tillfrågad om varför denne hade svarat som denne hade gjort. Detta ledde mycket riktigt till att vi fann två substantiv som har varit vår utgångspunkt i resterande delen av projektet: Snabbhet och enkelhet. Vanliga funktioner skall vara så lättåtkomliga som möjligt och användarupplevelsen skall stämma överens med den mentala modellen. Vi ville göra menysystemets hierarki så grund som möjligt. Vi använde oss av metod som mycket tidigt i designprocessen gav oss ett konkret resultat. Om vi hade använt oss av I nte rvjuformul är

5 någon annan metod som analyserade andra användare innan vi analyserade våra egna preferenser först, hade vi kanske fått ett annat resultat. Därefter utförde vi fyra intervjuer på studenter på IT Universitetet och fyra think-aloud-tester på bekanta för att få reda på vad andra användare än de i gruppen anser vara problem vid interaktion med mobiltelefoners menysystem, samt hur en bra användarupplevelse utkristalliserar sig. Det visade sig att intervjuerna bekräftade våra egna tankar om användarupplevelse och menysystem. Att likheterna mellan metoderna gav så likartade resultat medförde att vi uppfattade oss ha hittat kärnpunkten i vad en del mobilanvändare anser om användarupplevelse och menysystem. Vårt resultat kan bero på att intervjuerna gjordes på personer som delar vår kontext. Om vi hade intervjuat exempelvis mycket äldre eller yngre personer med icketekniskt intresse hade vi kanske fått ett annat resultat. Det samma kan sägas om att vi utförde thinkaloud-testerna på bekanta. Det finns en uppenbar risk att vi har förlorat integreringen mellan vår egen syn på hur användarupplevelsen och menystrukturen bör vara utformat, och allmänhetens uppfattning, eftersom vi inte har integrerat metoderna, och eftersom vi har ett litet urval av externa respondenter vilket kan ge en skev bild av vår målgrupps uppfattning. Med hjälp av Systematic Evaluation Method for Cell Phone User Interfaces, (SEM-CPU)-metoden, skapad av Lee, Hong, Smith-Jackson, Nussbaum, Tomioka (2005), hade vi kunnat undvika risken att förlora data eftersom kombimetoden integrerar metoderna scenario-based task performance, questionnaries, post-task analysis, user observation, och retrospective think aloud, och därmed översförs data naturligt mellan dem. Vi hade dock redan genomfört hälften av våra valda metoder när vi hittade kombimetoden och på grund av tidsramen beslutade vi oss för att följa vår upplagda strategi. Om vi hade haft mer tid på oss hade vi naturligtvis grundligt tagit reda på att denna och liknande metoder fanns att tillgå redan innan vi påbörjade användning av andra metoder. Vi tror oss ändå ha fått tag på intressanta och vettiga resultat. Av ovanstående testresultat, i divergensfasen gällande användarupplevelse, kom vi fram till dessa användarupplevelsepunkter: Det är inte uppenbart att adressboken är central. Hitta informationen någon annanstans, nätverksstruktur. Använda fler dimensioner (upp, ner, vänster, höger, in och ut) i så många situationer som möjligt. Tillämpa 3D-djup. Komma åt syftet med en funktion direkt på ett tryck med knappen, sedan göra speciella inställningar för denna funktion (exempel SMS). I och med identifierandet av dessa konkreta punkter slängde vi oss in i transformationsfasen varpå sorteringen av funktionerna påbörjades med grund i punkterna.

6 Tr ansformationsfasen Nät verksprincip För att leva upp till våra slutsatser ifrån divergensfasen har vi strukturerat upp funktionerna i ett tänkt tredimensionellt nätverk. Tanken är att olika nivåer i nätverket innefattar olika abstraktionsgrad av en funktion, exempelvis kan en nivå innehålla Meddelanden, Adressbok, Kalender, och nivån under funktioner som Skriv meddelande, Lägg till kontakt, Se händelse. Funktionerna är sedan sammankopplade mellan och inom nivåerna beroende på om de kan tänkas användas tillsammans. Vår struktur skiljer sig alltså från den klassiska hierarkiska strukturen som finns i dagens system i det att funktioner kan vara kopplade på fler sätt än ett, och att samma funktion kan gå att komma åt från flera ställen i strukturen. Målen med omstruktureringen är att funktioner som är starkt associerade med varandra skall gå att komma åt där de behövs. Alla funktioner skall också kunna nås relativt enkelt utan att man för den skull avslutar det man håller på med. Säg att en användare behöver använda sig av filhanteraren för att bifoga en bild till ett MMS. Kanske vill användaren även bifoga en ljudslinga och därför öppna mediaspelaren för att lyssna vilket ljud det var. Samtidigt skickar någon ett MMS som användaren vill svara på direkt. Vi vill göra en meny där användaren kan gå från Skriv meddelande-funktionen, in i Mediespela- E n första s kiss av nät verks m e nyn

7 ren direkt, sedan till Läsa meddelande när det nya meddelandet kommer, och sedan tillbaks för att skriva klart meddelandet igen, allt utan att behöva ta omvägen runt huvudmenyn. Vi har tänkt lösa detta genom att låta användaren zooma mellan de olika nivåerna i vår menystruktur, genom att använda plusoch minusknapparna på telefonen. Sorter a funktionerna Med grund i användarupplevelsepunkterna och nätverksprincipen påbörjade vi nedskrivningen av alla funktioner på post-it-lappar och klistrade upp dessa på en whiteboard. Dessa verktyg tyckte vi fungerade bra att använda i en brainstormingsession eftersom alla kunde se vad som skrevs och möjliggjorde att alla gemensamt kunde diskutera upplägget och få klarhet i våra idéer, till skillnad mot om vi enbart hade suttit runt ett bord och diskuterat. Vi tycker att vi hade stor hjälp av att vi hade en gemensam ståndpunkt när vi använde oss utav brainstormingen. Brainstormingsessioners lösa struktur kan dock lätt medföra svårigheter för alla personer att förmedla sin åsikt, samt innebära dataförluster. Dataförluster skulle ha kunnat undvikits genom strukturering av sessionen med hjälp av fler skisser och bättre dokumentation i form av exempelvis videoupptagning. När vi började placera ut funktionerna valde vi en central punkt som vi kallade plexus, som skulle symbolisera huvudmenyn. Antalet menyalternativ sattes till fem så att användaren på ett snabbt och enkelt sätt skulle få en överblick över de vanligaste funktionerna, i enlighet med våra punkter från användarupplevelsen samt en studie av K750i-simulatorn. Vi ville även använda navigeringspaken till fullo (valknappen, höger, vänster, upp och ner). Vidare identifierade vi noder i nätverkstrukturen med starkast koppling till huvudmenyn. Eftersom en nätverkstruktur kan innebära att det tar lång tid att ta sig från en nod till en annan som ligger långt därifrån införde vi, efter brainstorming, zoomfunktioner med vilka användaren snabbt kan navigera till rätt menyfunktion. Detta skulle passa in i vår idé om användarupplevelsen samt kunna ge en logisk koppling och att erbjuda den snabbhet vi var ute efter. Idén om navigation via zooming förklaras mer under rubriken Nätverksprincip. Efter att ha identifierat vilka noder som har starkast band till huvudmenyn började vi skapa ett flödesschema som dels skulle hjälpa oss att konkretisera vår idé om navigation med zoom, men även hjälpa vårt designteam att skapa vår interaktiva skiss. sorte ring av m e nya lte rnativ 6

8 I vårt arbete med att sortera funktionerna har vi tagit hänsyn till att det finns ett antal hardkeys. De funktioner, såsom kameran, som har en hardkey kopplat till sig har fått en lägre prioritering och placerats längre bort från huvudmenyn i vår nätverksstruktur. Vi vill argumentera för att detta ändå är i enlighet med vår idé om användarupplevese då snabbheten och enkelheten sitter i hårdvaran. Vi har även funderat på vad knapparna för zoomning och ljudstyrkan gör när man till exempel aktiverat kamerafunktionen eller ljudspelaren. Här vi vill argumentera för konsistens och helt enkelt avgränsa oss att plusoch minusknapparna alltid styr navigationen i vår nätverkstruktur. Kamerans zoomfunktion samt ljudkontrollen i mediaspelaren kan lätt mappas om och kontrolleras via styrspaken. Konvergensfasen I vår interaktiva skiss, som just är tänkt som ett koncept och ingen färdig lösning, vill vi visa på våra huvudidéer, dels de övergripande, snabbhet och enkelhet, men också de mer konkreta, exempelvis zoomning. Skissen har inte en komplett uppsättning funktioner, av naturliga skäl, men vi har försökt att implementera tillräckligt mycket för att våra idéer skall vara tydliga. Tyvärr har vi inte hunnit med att göra 3D-känslan så tydlig som vi hade velat. Det finns en stor risk för att den som prövar vår interaktiva skiss inte förstår var han eller hon befinner sig i systemet eftersom det idag inte finns någon tydlig indikation i form av exempelvis en bild som visar var i nätverket man befinner sig. Om vi hade hunnit implementera det hade vi förmodligen satt in en ickedetaljerad nätverksbild över hela systemet i övre statusfältet, där aktiva och passiva funktioner hade visats med hjälp av olikfärgade punkter. Vi skulle även tydligt velat visa vilka funktioner som var associerade med varandra. För att förtydliga var man kan zooma skulle vi velat implementera ett förstoringsglas som berättar för användaren att det går att zooma just där han eller hon befinner sig. Det första som möter en när man börjar använda menyerna är huvudmenyns fem alternativ. Antalet fem har vi bestämt oss för i en tidigare fas. Menyalternativen vi har valt är: Meddelande, Adressbok, Kalender och Underhållning, Inställningar. Dessa alternativ är de vi har tyckt vara mest relevanta för en huvudmeny, dock inser vi att det självklart kan finnas andra kandidater till huvudmenyn. Genom att begränsa antalet menyalternativ till fem går det snabbare för användaren att välja rätt funktion direkt. I bakgrunden syns en korridor vilken ska ses som en portal mot de andra funktionerna. Vi har även f lödesschema över m e nyerna

9 valt att reducera antalet animationer så att användaren lättare kan fokusera på vad han eller hon vill utföra istället för att distraheras. Vi vill komma åt syftet med en funktion direkt när funktionen väljs. Så fungerar exempelvis kamerafunktionen på Sony Ericssons K750i idag. Väljer användaren kameran aktiveras aktiviteten som användaren tycker är meningen med att aktivera kameran, nämligen att ta en bild. Samma sak vill vi applicera på fler funktioner, man skall inte behöva ställa in vilken typ av meddelande man vill skicka innan man skriver meddelandet. Meddelandetyp kan man ställa in efteråt, precis som i exemplet med kamerafunktionen. Väljer man kameran, kan man ta en bild direkt, man behöver inte ställa in slutartid, mörkerläge eller liknande innan. Detta stämmer överens med våra idéer om enkelhet och snabbhet. Därför visas Skriv meddelande direkt när meddelandefunktionen aktiveras. När Skriv meddelande har valts och gjorts aktiv kan man antingen fortsätta med att skriva meddelande eller gör diverse inställningar genom att zooma ut och få tillgång till associerade funktioner. Funktionerna på vår hjulmeny är liknande huvudmenyn, alltså bara våra åsikter om vilka funktioner som har starkast koppling till varandra i vår nätverksstruktur, vi kan mycket väl tänka oss att vissa funktioner saknas eller är överflödiga, syftet är dock att visa vår idé. De associerade funktionerna, som man kommer åt genom att zooma ut, ligger som på ett hjul med associerade funktioner på den vertikala axeln och de lokala funktionerna på den horisontella axeln. Associerade funktioner är alltså funktioner som är starkast ihopkopplade med den aktiva funktion som man zooma ut ifrån och lokala funktioner är de alternativ som en associerad funktion har, exempelvis den utifrån funktionen adressbok associerade funktionen meddelande med den lokala funktionen skicka meddelande. Vi har inte hunnit animerat vår hjulmeny, därför kan det kännas lite konstigt att navigera med den då den ser ut som en vanlig lista. Vi hade som ett mål att använda styrspaken på ett så bra sätt som möjligt därför har vi gjort vår hjulmeny så att användaren kan navigera upp och ner, vänster och höger. Vi borde ha skissat mer på papper för få en klarare bild över systemet och framför allt för att hjälpa till att konkretisera våra idéer så att Flash-modellen enklare skulle ha kommit till stånd.

10 Slutsatser Det känns som att vi valde metoderna mer slumpartat än på grund av övertygelse om att de skulle vara lämpligast i det skede de användes. Detta berodde nog mycket på att vi blev stressade av att det var mycket att göra och lite tid till att reflektera över och gå djupare in i vad de olika metoderna egentligen skulle ge för resultat. Dessutom var det första gången som vi jobbade med metodbaserad design, så det kändes ovant, och vi saknade erfarenhet att välja rätt metod vid rätt tillfälle. Däremot har vi försökt att jobba på ett sådant sätt att vi försöker reflektera och se om det finns någon metod som kunnat hjälpa oss vid olika tillfällen, snarare än att vi gått från metod till metod. Vi tror det har varit bra, vi har inte låst in oss på att vi måste använda någon metod, utan försökt att använda metoderna som verktyg där de passat. Något vi tänkt på är att vi är osäkra på om vi utnyttjad den fulla potentialen av vissa metoder, och hur vi skulle kunna kombinerat metoder för att utnyttja dem bättre. Vi funderar på om vi inte förlorat idéer och data under vägen, helt enkelt för att vi inte kunnat ta med oss allt till nästa steg. Så här i efterhand hade det varit lämpligare att skynda långsamt i början och ta reda på vad det var vi egentligen ville ta reda på, och att med stöd av denna vetskap ta reda på vilka metoder som var lämpligast för det. Vi tror dock att det hade varit ett mindre effektivt en bild från vår interaktiva skiss

11 sätt att lära om olika metoder än om någon med erfarenhet hade förklarat de olika metoderna för oss. Vi skulle ha velat ha en bättre genomgång av vilka metoder som fanns att tillgå och vad de kunde användas till, och när de var lämpliga att använda. Hur ser ett bra metodarbete ut? Som det är nu vet vi bara hur vi har jobbat, och hur det fungerat, men vi vet inte hur man borde jobba. Som det är nu så har vi inte analyserat slutresultatet, det skulle kunna varit lämpligt att testa vår idé och analysera den, men det finns inte tid att göra det inom kursens ramar. Referenser Lee, Y. S., Hong, S. W., Smith-Jackson, T. L., Nussbaum, Tomioka, K Systematic evaluation methodology for cell phone user interfaces. Interaction with computers xx(x):1-22. [electronic resource]. 10