Metodreflektion

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

M e to d e r / p 2 / G ru p p 6
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å 6-3-5-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

M e to d e r / p 2 / G ru p p 6
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.

M e to d e r / p 2 / G ru p p 6
Divergensfasen
Användarupplevelsen
Vi använde resultatet av den tidigare genomförda 6-3-5-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

M e to d e r / p 2 / G ru p p 6
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.

M e to d e r / p 2 / G ru p p 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

M e to d e r / p 2 / G ru p p 6
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

M e to d e r / p 2 / G ru p p 6
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

M e to d e r / p 2 / G ru p p 6
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.

M e to d e r / p 2 / G ru p p 6
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

M e to d e r / p 2 / G ru p p 6
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. 2005.
Systematic evaluation methodology for cell phone user interfaces. Interaction
with computers xx(x):1-22. [electronic resource].
10