IT-Universitetet i Göteborg Metodik, 3p LOGGBOK. Camilla Johansson Paul Alvarado Mendoza Jenny Sjögren Jim Suonpää

Transkript

1 IT-Universitetet i Göteborg Metodik, 3p LOGGBOK Camilla Johansson Paul Alvarado Mendoza Jenny Sjögren Jim Suonpää

2 1 INTRODUKTION 1 2 DESIGNPROCESS SCENARIOS Resultat Diskussion och slutsats CARD SORT Resultat Diskussion och slutsats KLASSIFIKATION AV MENYSTRUKTUR Indelning efter användningssituation Indelning efter frekvenserad användningssituation Typindelning Frekvensindelning Diskussion och slutsats RANKING AND WEIGHTING Resultat Diskussion och slutsats PAPER PROTOTYPING Interaktion Grafisk layout Diskussion och slutsats PROTOTYPING Low Tech High Tech 25 3 REFLEKTION ÖVER DESIGNPROCESSEN 26

3 1 Introduktion Vi har diskuterat allmänt vilka metoder vi ska använda i vårt projekt. Vi har även jämfört de olika metoderna och vägt fördelar och nackdelar specifikt för vårt projekt. Vårt mål är att verkligen använda metoder genomgående under hela projektet. Vi tror att vissa metoder kan visa sig vara mer användbara och ge mer resultat än andra. Vi diskuterade bland annat att Interaction Relabelling troligen inte passar vårt projekt eftersom vår interaktion är låst till den nuvarande spaken och de begränsningar det medför i interaktionen. Extrema karaktärer är kanske inte heller så lämpligt eftersom vi redan har en produkt som vi inte har så enormt stora möjligheter att förändra. Extrema karaktärer är en metod som vi tror fungerar bättre för att utveckla en ny produkt. I början av designprocessen tror vi att det är lämpligt att använda metoderna så separat som möjligt, dvs. att inte ta in något från de andra metoderna för att vara helt öppna och få ut så mycket som möjligt. Vill vi på detta sätt vidga vårt perspektiv och tror att vi på så sätt kan komma på eller tänka på saker som vi inte hade gjort om vi hade tagit med indata in i de första metoderna. 2 Designprocess Mycket tid i början gick åt till att läsa sig in på de olika metoderna. När vi hade en översiktlig kunskap om de olika metoderna började vi välja bort och välja ut metoder som vi trodde skulle vara lämpliga i de olika designfaserna. De olika metoderna är utformade för olika delar av designprocessen, därför kändes det viktigt att försöka hitta metoder som är rätt för den fasen av projektet man är i för tillfället. Eftersom vi inte har någon större erfarenhet av att arbeta med metoder kom vi fram till att det skulle bli svårt att fastställa vilka metoder vi skulle använda vid varje specifik del av projektet. Vi bestämde oss för att börja med att ta ut en eller två metoder att börja med och sen se vart vi hamnade efter det. I början av designprocessen vill vi använda oss av metoder som ger oss massor av idéer och fastställer problemområdet. I mitten vill vi fokusera mer på de problem som kan finnas med de idéer som kommit fram. Vi vill här använda oss av metoder för att utvärdera våra idéer och på så vis få fram de problem som de innehåller. Detta kan till exempel göras genom att använda metoder som delar in våra idéer i mindre och mer lätthanterliga delar. Genom att utvärdera våra idéer får vi reda på och belyser de olika problem som kan finnas med dem. I den sista fasen av designprocessen vill vi använda oss av metoder som kan testa den interaktion som fastställts. 2.1 Scenarios Den första metod vi ska genomföra vill vi skall fastställa vilket vårt problemområde är. Metoden bör även ta reda på vad användarna anser är viktiga och mindre viktiga funktioner, när funktionerna används samt vilket 1

4 behov av funktionalitet som finns. Vi valde att starta med att skapa olika scenarios därför att vi ansåg att denna metod skulle hjälpa oss med just det som nämndes ovan. Med hjälp av metoden scenario vill vi få ut information om vilka funktioner som används vid vilka tillfällen samt hur funktionerna ska vara anpassade efter användningssituationer. Vi tittar därför på olika körsätt och körstilar och inte på funktionerna i sig. Med oss in i metoden har vi inga indata från någon annan metod, eftersom detta är vår första metod. Vi har däremot med oss information om färddatorsystemet, såsom hur färddatorsystemet fungerar idag samt vilka funktioner färddatorn innehåller. Vi tror att vi kommer att upptäcka vissa grupperingar av funktionerna, pga. att vissa funktioner endast kommer att behövas i specifika användningssituationer samt att olika funktioner kommer att behövas i få eller många situationer. Vidare kommer en del av funktionerna kräva mer uppmärksamhet än andra för att vara användbara vilket kan medföra att dessa används när föraren inte behöver koncentrera sig lika mycket på körningen. Vi tror att resultatet kommer att påvisa en skillnad för hur olika funktioner används olika ofta, vi tolkar funktioner som inte används lika ofta som potentiellt mindre viktiga, men eftersom detta bara är en första indikation så vill vi inte dra några förhastade slutsatser. Vi vill hålla scenarierna korta och koncisa för att det ska vara enklare att koppla de olika scenarierna till funktionerna samt för att försöka tänka på en sak i taget och inte försöka göra problemet svårare än vad det är. I denna metod har vi valt att inte ta med utomstående, utan metoden utförs endast av gruppmedlemmarna. Vi valde att angripa denna metod på det vis att när vi skapade scenarierna började vi att titta på vilka olika sorters användningssituationer det kan finnas. Vi diskuterade fram och listade de situationer vi kunde tänka oss. Detta ledde fram till tio stycken olika användningssituationer. Att börja på detta vis tror vi var viktigt för att få oss att tänka i ett vidare perspektiv och inte bli begränsade till ett mindre antal scenarier. Om vi hade börjat skriva varje scenario för sig tror vi inte att vi hade kommit på alla de scenarier som vi nu gjorde. Efter att vi tagit fram de tio användningssituationerna satte vi oss sedan ned och skrev ett scenario per situation Resultat Scenario 1 - stadskörning Kim bor på ena sidan av Göteborg och hans bästa kompis bor på andra sidan av Göteborg. För att ta sig till sin kompis måste han köra genom hela Göteborg. Detta innebär flera stopp vid trafikljusen och han blir flera gånger tvungen att lämna företräde för cyklister, gångare, bussar och spårvagnar. Scenario 2 - långkörning (motorväg) Kim ska ta bilen för att åka och hälsa på sin faster i Sundsvall. Detta innebär en lång sträcka på motorvägen mellan Göteborg och Sundsvall. Kim stannar och tankar, sträcker på benen samt äter en liten matbit på vägen. Körning innebär många raksträckor och höga hastigheter. 2

5 Scenario 3 - landsväg Kims föräldrar har bjudit hem honom på middag. Hans föräldrar bor i Borås och detta innebär en del landsvägskörning för Kim. Körningen växlar mellan högre och lägre hastigheter. Scenario 4 - parkering När Kim kommer till jobbet parkerar han bilen i en parkeringsruta. Bilen står på samma ställe under dagen tills Kim ska hem på kvällen när han slutat arbeta. Efter arbetet ska Kim in till staden för att göra några ärenden. Han fickparkerar bilen utanför affären där han ska in och göra ett snabbt ärende. Sedan kör Kim hem och parkerar bilen för dagen. Scenario 5 - tomgångskörning Kims kompis Lisa ska in i en butik och köpa Coca Cola. Under tiden som Lisa är inne och handlar sitter Kim i bilen utanför affären. Eftersom Lisa är tillbaka snabbt tycker Kim det är onödigt att stänga av bilen och låter därför bilen gå på tomgång. När Lisa kommer tillbaka kommer de även iväg snabbt. Scenario 6 - mörkerkörning När Kim ska åka hem från jobbet har det hunnit mörkna och han slår därför på helljuset och ljuset för displayen. Det tar längre tid än vanligt för Kim att komma hem eftersom han kör långsammare och försöker vara mer uppmärksam. Scenario 7 - vinterkörning, halka När Kim kommer ut på morgonen måste han skrapa rutorna och sätter igång bilen på tomkörning för att få upp värmen i kupé. Innan Kim kör iväg bromsar han några gånger för att testa hur halt det är. Scenario 8 - sommarkörning När Kim ska köra hem från stranden har bilen stått i solen hela dagen och blivit uppvärmd. Kim blir varm, svettig och irriterad. Han får även solen i ögonen och har svårt att se vägen. Scenario 9 - regn Regnet öser ned när Kim ska köra och träna. Han sätter på vindrutetorkarna på högsta hastighet men har ändå svårigheter att se vägen. Han försöker undvika att köra i stora vattensamlingar som finns på vägen. Scenario 10 - kö, rusningstrafik När Kim kör till och hem från arbetet hamnar han i rusningstrafik. Köbildningarna är stora och väntetiden är lång. Kim blir irriterad och stressad för att han inte tror att han kommer hinna i tid. Körningen innebär korta och ryckiga sträckor där växlingarna blir många Diskussion och slutsats När vi genomförde metoden fick vi fram fler scenarion än vad vi hade trodde på förhand. Det var bra att begränsa de olika scenarierna så att de är korta, det var därmed lättare att komma på användbara scenarier. Efter att vi utvecklat scenarierna hade vi tänkt analysera och koppla samman detta med funktionerna i färddatorn. Vi ändrade oss och ville istället ta med dessa scenarier in i nästa metod för att utföra analysen där istället. Vi tror nämligen att metoden card sort 3

6 kan vara bra för att se vilka funktioner som är viktiga i vilka användningssituationer. Vi valde alltså att gå vidare i designprocessen genom att direkt utföra metoden card sort, utan att först försöka dra några slutsatser om vilka funktioner som används/är användbara i de olika scenarier vi tagit fram. Innan vi påbörjade vår första metod tänkte vi genomföra de första metoderna i designprocessen separat för att vidga vårt perspektiv och tänka på saker som vi kanske inte hade tänkt på om vi använt oss av resultatet från en metod som utgångspunkt för nästa metod. När vi sedan utvecklat scenarierna märkte vi att det skulle vara bra att använda oss av en metod för att koppla samman funktionerna i färddatorn med scenarierna. Då vi läste på bättre om metoden card sort ansåg vi den var en väldigt lämplig metod för just det här. Vi valde därför att frångå det arbetssätt som vi från början hade tänkt oss. Vi tror att detta var lämpligt eftersom card sort kan hjälpa oss att gå framåt i processen och även hjälpa oss att använda scenarierna för att få fram ett resultat. 2.2 Card sort In i denna metod tog vi med oss det som vi fått fram genom den föregående metoden, scenarios. De tio scenarier som vi tagit fram mappades till de olika funktionerna som färddatorn har i nuläget. På detta vis ville vi utvärdera, analysera och dra slutsatser från de scenarier vi tagit fram. Detta tror vi kan vara ett bra sätt för att få fram olika mentala modeller. Detta kan visa att olika användare tycker att olika funktioner är viktiga i samma användningssituation och vice versa. Vi utförde card sort genom att först lista de olika scenarierna och sedan skriva ned de olika funktionerna i färddatorn på post-it lappar. Flertalet lappar gjordes för varje funktion eftersom en funktion skulle kunna placeras på flera scenarier (se Figur 1). Genom att göra på detta vis kan vi se grupperingar och vilka som är de mest användbara funktionerna. Med att se grupperingar menar vi att vi kan se ett samband mellan att samma funktioner används i flera scenarion. Vi kan också rangordna funktioner och därmed se vilka funktioner som är mer eller mindre viktiga. Detta tyckte vi var ett handgripligt sätt som även gav en bra överblick över de olika funktionerna. Innan vi körde igång med card sort gick vi igenom alla funktioner för att se till att alla inblandade var medvetna om vad de olika funktionerna innebär. Vi ville egentligen göra card sort för alla funktioner men efter genomgången kom vi fram till att vi inte hade någon aning vad vissa funktioner gjorde. De vi inte förstod var de funktioner som används i stillastående läge, vi försökte få tag på mer material, dock utan framgång (på grund av tidsbrist var det inte heller möjligt att skjuta på utförandet av denna metod) och valde därför att inte ta med dessa funktioner vid tillfället. Vi kom fram till att funktionerna under körning trots allt var de viktiga funktionerna att reflektera över eftersom dessa är fler och används i fler och mer stressande situationer. De scenarier vi tagit fram innefattade även mest situationer under körning. Endast ett scenario, det som involverade parkering hanterade funktioner i stillastående läge. Vi valde därför att utesluta detta scenario från card sorten. 4

7 Figur 1. Post-it lappar med funktioner innan metodutförande. Innan vi startar med utförandet av metoden funderar vi på hur vi ska utföra card sorten; ska vi sätta ut funktionerna på varje scenario för sig eller ska vi sätta ut funktionerna tillsammans i gruppen. Vi funderade också på hur vi skulle analysera all data, om detta skulle göras för varje person eller om vi skulle sätta samman resultatet från gruppen för att analysera det sedan. Vi bestämde att vi skulle sätta ut funktionerna separat för att inte påverka varandra och även för att vi ville se om resultatet från de olika personerna skiljde sig (se Figur 2). Vi kom fram till att det var bästa sättet eftersom ett av målen med metoden var att vi ville få fram olika mentala modeller. Vi valde sedan att gå igenom resultatet för varje person för att göra det möjligt för varje gruppmedlem att motivera sina val för de andra i gruppen. Vi skrev ned alla funktioner som en person placerat på ett scenario. Vi gick därmed igenom alla personer var för sig och alla scenarier i ordning. Vi märkte direkt att det var tre funktioner som inte användes så mycket eftersom det var många post-its kvar i de funktionerna. I tabell 1 kan en sammanställning av resultatet från card sorten ses. 5

8 Figur 2. Utplacering av funktioner för respektive scenario Resultat Total Summa Tid från start Nuvarande förbrukning Sträcka till tom tank Medelhastighet Medelförbrukning Hastighetsvarning Driver Alert

9 Hastighet Förbrukad körtid Lane Warn Anti Spin Tabell 1. Resultat av metoden card sort. I tabell 1 kan resultatet från card sort metoden ses. Här visas hur många som ansett att en funktion är viktig för ett visst scenario. Efter det att resultatet från card sorten sammanställts kom det fram att resultatet kunde vara något missvisande på grund av att det funnits en viss tvekan om de olika funktioners verkliga mening och tanke innan vi utförde metoden (trots att vi diskuterade funktionerna innan genomförandet av metoden). Gruppmedlemmarna hade något skilda åsikter om vi skulle ta hänsyn till hur funktionerna fungerade idag eller inte. Detta betydde att vissa gruppmedlemmar hade placerat sina funktioner med tanke på att vissa funktioner inte fungerar så bra i dagsläget och därmed försökt undvika dessa funktioner. Andra gruppmedlemmar placerade däremot sina funktioner utan att tänka på hur funktionen fungerar idag, utan mer på hur det är tänkt att de ska fungera. Det hade nog därför varit bättre om vi hade haft en tydligare dialog innan vi utförde metoden för att utesluta osäkerheter. På grund av denna osäkerhet valde vi att föra en diskussion om resultatet från card sorten. Syftet med denna diskussion var att de mest viktiga funktionerna för varje användningssituation skulle kunna vaskas fram. Detta gjordes genom att föra en diskussion där varje gruppmedlem fick motivera varför en funktion skulle anses som viktig för just det scenariot. Genom denna diskussion kunde de allra viktigaste funktionerna för varje scenario tas fram och därmed reda ut de oklarheter som funnits innan metoden genomfördes. Genom denna diskussion kunde vi se vilka funktioner som är viktigast för varje scenario och det framkom även att vissa funktioner hade passat extra bra för att visas som modeless feedback. Nedan presenteras de funktioner som är extra viktiga i varje specifikt scenario. Vi motiverar varför dessa funktioner är de viktigaste samt noterar de mest framstående delar i den diskussion som ägde rum. Scenario 1 - Stadskörning Av de funktioner som placerades på stadskörning, var tid från start samt nuvarande förbrukning de två funktioner som ansågs som mest viktiga. I en stad så tyckte de flesta att man inte behöver tänka på hur mycket bensin man har kvar eftersom det oftast är så nära bensinstationerna, men det kom även upp att stadstrafik troligen drar mest bensin i och med de många nedbromsningarna och accelerationerna. Vidare så kom det även upp att hastighetsvarningen kunde vart användbar, men på grund av stress så har man inte så mycket tid att pilla med funktionerna i färddatorn och ställa in sådana saker som t.ex. hatighetsvarning. Tid från start vore användbart för att t.ex. kunna jämföra hur 7

10 långt man hunnit i staden jämfört med en tidigare gång man kört samma sträcka. Scenario 2 - Långkörning (Motorväg) I det här scenariot ansågs driver alert, hastighetsvarning, sträcka till tom tank samt tid från start vara de viktigaste/mest användbara funktionerna. Vi hade en diskussion om att vi egentligen inte vet hur funktioner fungerar. Vi kom fram till att vi inte ska tänka på detta. Vi kom också fram till att Lane warn och Driver alert måste vara kopplade till varandra på displayen. Sträcka till tom tank är viktigt att se när man kör långt eftersom det kan vara långt mellan bensinstationerna. Det är lättare att motivera fler funktioner när man kör långt eftersom det är lättare att navigera mellan dem. Det är lätt att bli fartblind, därför kan hastighetsvarning vara en bra funktion. Scenario 3 - Landsväg De funktioner vi kom fram till är viktigaste då du kör på landsväg är sträcka till tom tank, hastighetsvarning samt driver alert. Sträcka till tom tank är bra av samma anledning som ovan, det kan vara långt till nästa station. Även argumenten för funktionen "Hastighet" ovan håller för i det här scenariot också. Hastighetsvarning är bra eftersom det ofta är en längre sträcka man kör på landsväg, hastigheten kan variera och det kan vara farligt att köra för fort. Driver alert & lane warn kan vara väldigt användbara här eftersom det kan vara svårt att se vägen. Scenario 5 Tomgångskörning Vi kom fram till att funktionalitet i färddatorn är ganska oviktig vid tomgångskörning. Anledningen till att nuvarande förbrukning och tid från start finns med beror på att det är dessa som ändras och skulle kunna vara intressanta om man trots allt väljer att interagera med färddatorn. Den andra aspekten är att det är nu man har tid och möjlighet att fokusera på färddatorn fullt ut (dvs. det ska vara lätt att komma åt alla funktioner). Scenario 6 - Mörkerkörning Driver alert (tillsammans med lane warn) är viktig vid mörkerkörning eftersom det är svårare att se vägen i mörker. Tid från start kan också vara viktigt, ett argument för detta är att det går långsammare att köra när det är mörkt. Scenario 7 - Vinterkörning, halka Vid halka är det viktigt att ha funktionerna anti spinn och driver alert. Det är viktigt att komma åt Anti spinn funktionen så att man kan slå på den om man vill ha den. Vi skulle vilja att man kunde visa om denna funktion är på, så att man ser det hela tiden oavsett vart man är i färddatorn, när man slår av den visas ingenting. Scenario 8 - Sommarkörning Driver alert kan vara en bra funktion på sommaren om du har solen i ögonen. Resultatet är väldigt beroende på hur scenariot är utformat. Scenario 9 - Regn De funktioner som är viktigast vid regn är anti spinn och driver alert. Resultatet beror till stor del på hur det är upplagt rent funktionellt med Lane warn och Driver alert, det är driver alert som är viktig men för att den ska funka måste 8

11 man veta att lane warn är på. Anti spinn funktionen har samma motivering som den hade under halkscenariot. Scenario 10 - Kö, Rusningstrafik I rusningstrafik och köbildningar är det tid från start, medelhastighet och nuvarande förbrukning som är de viktigaste funktionerna. Tid från start kan hjälpa en att uppskatta tiden i rusningstrafik, det kan även medelhastigheten hjälpa till med. Det kan vara intressant att veta vilken hastighet man har i rusningstrafik. Nuvarande förbrukning kan vara intressant eftersom det kanske skiljer mkt på hur mkt bensin det går åt och man då kanske kommer fram till att man tjänar mkt på att starta en timme tidigare nästa gång för att man sparar mkt pengar på det i längden Diskussion och slutsats Vi kom fram till att vissa funktioner är kopplade till hastigheter eller till varandra. Ett exempel är om man huruvida skulle kunna se att lane warn är på genom att kolla på driver alert eftersom de är kopplade till varandra. Det är endast när lane warn är på som Driver alert är användbar, eftersom den annars inte fungerar som det är tänkt. Det framkom även genom våra diskussioner att hastighetsfunktionen inte är så användbar som färddatorfunktion. Denna funktion ska antingen vara synlig hela tiden som ett komplement till den analoga hastighetsdisplayen eller vara kopplad till annan funktionalitet, som till exempel farthållare. Däremot kan det vara bra att kunna välja att se hastigheten i mph om bilen körs utomlands. Framkom gjorde även att det är dåligt att användaren ska behöva gå in under olika funktioner i färddatorn för att enbart se om den funktionen är på eller av. Detta borde kunna ses på ett enklare vis, exempelvis genom modeless feedback. Vi kom även fram till att vissa funktioner är väldigt viktiga beroende på olika förhållanden, som till exempel att driver alert är viktig vid farligt väglag eller riskfyllda vägsträckor. Den mänskliga faktorn kan ses som den största faran i andra scenarier. I diskussionerna framkom att det finns ett stort behov av att gruppera de olika funktionerna på ett bra sätt. Vissa självklara grupperingar kom fram genom card sort men fler alternativ för gruppering måste undersökas. Metoden utfördes endast med medlemmar i gruppen, vilket dels är en liten grupp att få input ifrån och dels är en grupp med enbart unga människor. Att önska hade vart att utöver de i gruppen ha med någon med gedigen erfarenhet av bilkörning, t.ex. en yrkesförare. Vidare hade det vart intressant att ta del av åsikter från någon som äger en Volvo med åtminstone en liknande färddator. Åsikterna i gruppen gick isär ganska mycket gällande vilka funktioner som var mer eller mindre viktiga, detta tyder än mer på att en breddning av metodgenomförare hade kunnat vara givande. Pga. tidsbrist var det inte möjligt att genomföra metoden med ett noggrannare och större urval av personer. Dock har det ingen direkt betydelse för metodgenomförandet i sig utan snarare för slutresultatet om det skulle tas i bruk. Att ta med resultatet från scenario metoden minskade risken att enbart tänka på de väglag, situationer och miljöer man oftast kör i. Troligen hade resultatet blivit sämre utan scenariona. Beslutet att sätta ut de olika funktionerna var och en för sig tror vi var viktigt. Genom att göra så fick vi fram de olika personernas åsikter 9

12 och de olika funktionerna, på så sätt utnyttjades åtminstone de erfarenheter som finns i gruppen till max. 2.3 Klassifikation av menystruktur Genom metoden card sort framkom det att vi behövde göra en gruppering av de olika funktionerna. En diskussion fördes därför för att komma fram till hur denna gruppering ska gå till. Vi startar med att ta fram hur funktionerna kan grupperas. Under diskussionen framkom det att funktionerna kunde grupperas efter ett antal olika saker, såsom användningssituation, hur ofta funktionen används eller en gruppering efter funktioner av liknande typ (se Figur 3). Figur 3. Framtagning av de olika grupperingarna. När vi hade fått fram olika sorters grupperingar visste vi inte hur vi skulle gå vidare. Vi funderade först på att göra en ren idégeneringsmetod för att få fram nya tankar. Vi var lite oense i gruppen om detta var rätt väg att gå, eftersom det då kändes att vi förkastade det resultat som framkommit genom metoderna scenario och card sort. Efter lite vägledning kom vi därför fram till att det är bättre att bygga vidare på det resultat vi redan fått fram. Vi valde därför att först försöka att visualisera resultatet så att det skulle vara enklare att se olika mönster. När vi kommit en bit in i processen slog det oss att vi på ett modifierat vis utfört metoden klassifikation. Denna metod handlar om att gruppera och sedan visualisera de olika grupperingarna. Att visualisera de olika designförslagen på detta vis tyckte vi var bra eftersom det då är lättare att se olika mönster. Det vi tog med oss in i denna gruppering var det resultat som kom ut från scenarios och card sort. Vid genomförandet av dessa metoder 10

13 framkom vissa självklara grupperingar Indelning efter användningssituation Vi börjar med att gruppera efter användningssituation. Här grupperar vi efter de olika användningssituationer i card sort där samma funktioner rankades som viktiga. Vi får då fram tre huvudgrupper. Stadskörning, kö- och rusningstrafik samt tomgångskörning ingår under en grupp. Landsväg och långkörning blir en grupp samt mörkerkörning, regn och halka blir den tredje gruppen. Vi ser även att dessa grupper kanske inte fungerar att använda separat. Exempelvis kanske du ska köra på landsväg samtidigt som det är mörkt. Det kanske ska vara möjligt att välja flera av dessa grupper eller först välja hur du ska köra, om det är på landsväg eller i stadstrafik och sedan om det även råder några speciella förhållanden, så som mörker, regn eller halka. I Figur 4 kan de tre grupperingarna efter användningssituation ses där endast de viktigaste funktionerna syns under varje kategori. Figur 4. Gruppering efter användningssituation Indelning efter frekvenserad användningssituation Ovanstående exempel kan även göras om så att istället för att endast visa de viktigaste funktionerna för varje kategori så visas alla funktioner under kategorierna men de sorteras efter frekvens, hur ofta de används just vid den användningssituationen. Detta innebär att samma funktion kommer att finnas med tre gånger på olika ställen, men det innebär även att användaren kan nå alla funktionerna även om den gått in i en kategori, till skillnad från i exemplet ovan. Denna gruppering kan ses i Figur 5 nedan. 11

14 Figur 5. Gruppering efter frekvenserad användningssituation Typindelning När det gäller typ kom det fram två olika sätt att naturligt dela in funktionerna på. Dels har vi indelning efter den mentala modellen och dels en indelning som beror på bakomliggande funktionalitet. Detta designförslag innebär att funktionaliteterna delas in efter vilken typ de tillhör. De olika indelningarna syns i Figur 6 nedan. Vi tror att indelning efter den mentala modellen stämmer bättre 12

15 överens med var en användare förväntar sig att hitta funktioner. Däremot tror vi att den andra varianten, uppdelning efter funktionalitet, troligen är mer logisk för användaren när den väl förstått varför funktionerna är uppdelade som de är. Att funktioner under beräknad data är funktioner som måste nollställas för att räknas om och att funktioner under "Nu status" är funktioner som inte går att nollställa utan endast är aktuella för tillfället. Figur 6. Gruppering efter typ. 13

16 2.3.4 Frekvensindelning Det tredje designförslaget går ut på att ranka de olika funktionerna efter hur ofta de används. Det bästa hade varit om denna ranking skulle kunna förändras efter hur färddatorn används. En sådan förändring hade gjort detta designförslag dynamiskt och på så vis kan de funktioner som användaren använder oftast visas överst. Om en sådan dynamisk uppdatering inte är möjlig kan en lösning vara att undersöka vilka funktioner som allmänt är mest använda. Att göra detta innebär dock att lösningen blir generell och inte anpassningsbar för den specifike användaren. Att i detta stadium lägga ned mycket tid på att sortera de olika funktionerna efter vilka som används oftast tycker vi är onödigt. Om detta designförslag skulle väljas skulle det krävas omfattande testningar i verklig miljö för att få fram denna rangordning. För tillfället rangordnar vi därmed inte funktionerna utan nämner bara att en rangordning skulle finnas. Figur 7 visar en menystruktur där funktionerna är rankade efter frekvens. Figur 7. Gruppering efter frekvens Diskussion och slutsats Eftersom vi inte tog något medvetet beslut om att utföra metoden klassifikation kan vi inte reflektera över huruvida vi fick ut det vi förväntade oss av metoden. Positivt är att vi genomförde metoden för att den var så självklar efter att ha utfört föregående metoder. Idéer om att gruppering var nödvändigt och vilka olika sorters gruppering som kunde vara möjliga hade redan uppkommit. En fråga att ställa sig är om resultatet hade blivit annorlunda (bättre/sämre) ifall vi hade bestämt oss för att utföra metoden i sin helhet och därmed fått en mer kontrollerad klassificering. När vi delade in funktionerna i grupper kom vi på väldigt många sätt att göra detta på, för att inte ödsla alltför mycket tid och 14

17 fasta i denna metod slog vi samman vissa förslag samt valde bort förslag som var snarlika andra, bättre, förslag. Troligen hade resultatet blivit bättre om vi hade haft mer tid till den här metoden och kunnat utvärdera ännu fler grupperingar och konstellationer. Vi kände att vi inte kunde lägga för mycket tid på menystrukturen utan behövde gå vidare och komma in på hur interaktionen skulle gå till samt hur visualiseringen, den grafiska layouten skulle se ut. 2.4 Ranking and weighting För att välja mellan de olika designförslagen på menystruktur som framtogs med hjälp av klassifikation använder vi oss av metoden ranking och weighting. Genom denna metod ska vi göra vårt val av designförslag och använder därmed metoden för att sålla bort de sämre förslagen. Det vi förväntar oss att få ut av denna metod är att de förslag vi har blivit reducerade till ett mer lätthanterligt antal. De förslag som blir kvar tar vi sedan med oss in i nästa steg i processen som är att göra en pappers prototyp på de återstående förslagen. De indata som vi tar med in i metoden är de olika designförslagen på menystrukturer. All information som vi arbetat fram hittills om de olika förslagen kommer att hjälpa oss att välja mellan förslagen. Vi startar med att utveckla tre objektives som ska användas för att bedöma de olika designförslagen. Dessa objektives är de mål som vi vill att vår design ska uppnå. Vi kan därmed senare bedöma hur väl de olika designförslagen kan leva upp till dessa mål. En diskussion om vad som är viktigt i detta stadium uppkom. Vi kom fram till att det kan vara svårt att bedöma saker som till exempel visualisering och feedback, eftersom vi inte gått in på hur detta ska göras. Vi valde objektives som vi i detta stadium kan bedöma för att få ner våra designförslag till ett färre antal. De objektives som vi kom fram till var: Snabb navigation Logisk navigation Felprocent Under snabb navigering diskuterade vi fram att vi ska titta på hur funktionerna är grupperade i designförslagen och även på hur många steg eller knapptryckningar användaren måste göra för att komma till en viss funktion, eftersom detta påverkar hur snabbt användaren kan hitta den funktion den vill hitta. Under logisk navigation tittar vi bland annat på hur mycket användaren måste memorera för att kunna hitta det den vill hitta. Här handlar det mycket om mentala modeller, hur logisk du anser att förslaget är, hur väl det stämmer överens med hur du själv grupperar de olika funktionerna. Under felprocent uppskattar vi hur stor vi anser att risken för att göra fel är när användaren ska hitta en viss funktion eller nollställa en funktion. Vi diskuterade om vi redan innan vi utförde metoden skulle bestämma hur många designförslag som vi skulle sålla bort och hur många som skulle bli kvar. Vi tyckte alla att det skulle bli antingen ett eller två förslag kvar, men vi valde att inte bestämma antingen det ena eller det andra. Detta gjorde vi för att vi ville se resultatet först. Om ett förslag visar sig vara överlägset känns det onödigt att behöva välja två bara för att vi kommit överens om det innan. Vi valde därför att vara öppna för resultatet och utifrån detta sedan bestämma om vi ville gå vidare med ett eller två förslag. 15

18 2.4.1 Resultat De designförslag som rankades och vägdes mot varandra är: A. Gruppering efter användningssituation B. Gruppering efter frekvenserad användningssituation C. Gruppering efter typen mental modell D. Gruppering efter typen funktionalitet E. Gruppering efter frekvens Vi startade med att ranka våra objektives (se Tabell 2). Därefter betygsatte vi de olika designförslagen utefter de tre objektives som vi tagit fram (se Tabell 3). Sedan var det dags att göra de uträkningar som krävs för att ranka och väga de olika designförslagen. Resultatet av rankningen kan ses i Tabell 4 och resultatet från vägningen kan ses i Tabell 5. Objektives Totalt 1. Snabb navigering Logisk navigering Felprocent Tabell 2. Rankning av objektives. Score 1. Snabb navigering 2. Logisk navigering 3. Felprocent 4 C 3 C,D C 2 A,B B,D B,D,E 1 A,E A 0 Tabell 3. Betygsättning av designförslag. 16

19 Objektives A B C D E Maximum 1. Snabb navigation 2/4 x 100 = 50% 2/4 x 100 = 50% 3/4 x 100 = 75% 3/4 x 100 = 75% 1/4 x 100 = 25% Logisk navigation 1/4 x 100 = 25% 2/4 x 100 = 50% 3/4 x 100 = 75% 2/4 x 100 = 50% 1/4 x 100 = 25% Felprocent 1/4 x 100 = 25% 2/4 x 100 = 50% 4/4 x 100 = 100% 2/4 x 100 = 50% 2/4 x 100 = 50% 100 Medel 33% 50% 83% 58% 33% Tabell 4. Ranking resultat. Objektives A B C D E Maximum 1. Snabb navigation 2. Logisk navigation 3. Felprocent 2/4 x 25 = 12,5% 1/4 x 40 = 10% 1/4 x 35 = 8.75% 2/4 x 25 = 12,5% 2/4 x 40 = 20% 2/4 x 35 = 17.5% 3/4 x 25 = 18.75% 3/4 x 40 = 30% 4/4 x 35 = 35% 3/4 x 25 = 18.75% 2/4 x 40 = 20% 2/4 x 35 = 17.5% 1/4 x 25 = 6.25% 1/4 x 40 = 10% 2/4 x 35 = 17.5% Totalt 31.25% 50% 83.75% 56.25% 33.75% 100 Tabell 5. Weighting resultat Resultatet från denna metod var väldigt klart och enkelt att förstå. Resultatet från rankingen och vägningen visade tydligt att designförslag C, gruppering efter typen mental modell, var det som föredrogs. Förslag B och D var de som kom efter förslag C. Dessa förslag hade dock väldigt liknande ranking och vägning, inget av dessa förslag var övervägande. På grund av att förslag C var så överlägset valde vi att endast gå vidare med detta förslag. Vi tyckte att det var omöjligt att välja mellan förslag B och D, om vi skulle ha gått vidare med det ena förslaget tyckte vi även att vi borde gå vidare med det andra eftersom de var så lika. Vi valde därmed designförslag C och tar med oss denna design in i nästa metod Diskussion och slutsats När vi skulle ranka vilket objektive som var viktigast hade vi stora problem. De objektives som vi satt upp påverkar alla varandra, exempelvis om navigationen är logisk är det även större chans att navigationen är snabb. Detta gjorde att vi hade stora diskussioner om vilket objektive som var viktigast. Det hade troligtvis varit enklare om de olika objektiven hade varit mer olika och separata, eftersom vi då hade kunnat jämföra objektiven på ett annat vis. När det kom till att sammanställa resultatet för weighting märkte vi att vi borde ha bestämt 17

20 procentantalen innan vi satt ut våra betyg. Nu fastnade vi åter igen i en diskussion om vilket objektive som är viktigast. Eftersom vi ansåg att våra objektives var väldigt sammankopplade och påverkar varandra i stor grad valde vi att inte sätta för stora skillnader på procenten när vi skulle väga de olika designförslagen mot varandra. En positiv sak som framkom när vi gjorde denna metod var att vi tyckte att metoden gav mer än vad vi trodde att den skulle ge från början. De diskussioner som vi hade när vi skulle ranka de tre objektive och sätta betyg på de olika designförslagen fick oss att tänka på saker som vi inte hade tänkt på förut. Vi värderade de olika designförslagen på ett sätt som vi inte gjort innan. Det är lätt att döma ett förslag på förhand utan att riktigt tänka igenom om det är bra eller dåligt. Vi har ofta förutfattade meningar om saker även om vi inte vet tillräckligt mycket om dem för att bedöma dem. Med denna metod kunde vi kontrollera hur bra de egentligen var för att sedan välja ut de förslag som bästa följde de mål som vi ville att designen skulle uppfylla. 2.5 Paper prototyping Vi gjorde en enkel pappers prototyp av designförslag C. Vi skapade en spak med hjälp av en penna, lite papper och tejp (se Figur 8, Figur 9). Med pennan vill vi se hur interaktionen ser ut idag och försöka komma på nya sätt att interagera. Data som vi har med oss in i denna metod är designförslag C som valdes av föregående metod, som vi i paper prototyping använder som menysystem. Kunskap om spaken, hur den används, ser ut och fungerar. Med denna metod förväntar vi oss att klura ut hur interaktionen ska ske gentemot färddatorn. Det finns olika funktioner som vi ska fastställa dessa är bekräfta val i meny, backa tillbaka i meny, aktivera/deaktivera, ställa in saker och nollställning. Först testade vi prototypen fritt för att se olika interaktionsmöjligheter. Vi diskuterade och listade upp alla förslag för hur interaktionen kunde vara möjlig, dessa olika interaktionsmöjligheter ordnade vi i en tabell (se Tabell 7). För att utvärdera dessa interaktionsmöjligheter och bestämma mellan dem använde vi oss utav ett scenario. Vi tog fram ett scenario som fick oss att använda alla de olika funktioner och tvingade oss att gå fram och tillbaka i menyn, nollställa en funktion, ställa in en funktion samt aktivera en funktion. Scenariot var följande: Kontrollera hur långt det är kvar till tom tank, nollställ förbrukad körtid, ställ in hastighet för hastighetsvarnaren till 110 km/tim samt aktivera den. Med hjälp av scenariot kunde alla i gruppen testa de olika interaktionsmöjligheterna (se Figur 10) och välja den interaktionssättet som föredrogs. Resultatet från detta kan ses i Tabell 7. 18

21 Figur 8. Pappers prototyp av spaken. Figur 9. Pappers prototyp av menysystemet 19

22 Figur 10. Utförande av interaktionsscenario med hjälp av pappers prototyper Interaktion Vi var alla väldigt överens om vilket interaktionssätt som passade bäst för vilket ändamål. I Tabell 7 kan vi se att den knapp som kallas för read ska användas för att göra val i menyn samt aktivera och deaktivera funktioner. Detta interaktionssätt kändes mest naturlig för medlemmarna i gruppen. Knappen som idag heter Reset används för att göra inställningar och nollställa. För att nollställa måste användaren hålla inne knappen i 2 sekunder, detta för att bekräfta att en nollställning ska ske. Att användaren måste hålla inne för att nollställa tycker vi är viktigt för att inte användaren ska råka nollställa något av misstag. För att gå tillbaka i menyn så föredrog vi att lägga dit ett val i menyn som ger användaren möjlighet att gå tillbaka. Anledningen är att vi har få interaktionsmöjligheter med knappar och på detta sätt behöver ingen knapp ha en tillbaka funktion, på så sätt kan vi spara ett kontrollsätt. Genom att lägga en tillbaka funktion kan användaren också se vilket val som är sist i menyn. Om inte detta val fanns tyckte vi att användaren skulle kunna missa att alla funktioner har gåtts igenom. Att använda hjulet för att välja upp och ner var självklart, det var det mest logiska och naturliga valet. Detta för att du faktiskt rullar hjulet upp och ner, och det gör mappningen för menyn lättare att förstå. 20

23 Bekräfta val Gå tillbaka i menyn De-, aktivera Nollställning Göra inställning Upp, ned i menyn Enkeltryck read 3 Enkeltryck reset Håll inne read Håll inne reset Menyval Hjul 3 Tabell 7. Resultat från paper prototyping angående interaktion. Efter det att vi bestämt de olika interaktionssätten diskuterade vi ett eventuellt namn byte på knapparna för att motsvara vårt användningssätt. Att ändra read tyckte vi var nödvändigt eftersom denna knapp inte längre används till att läsa meddelanden. Knappen används nu istället till att bekräfta saker, varav valet av namnet OK, för att det kändes mest naturligt. Vi ville inte använda namnet reset, eftersom knappen inte enbart används för att nollställa funktioner utan även för att ställa in funktioner. Vi tyckte inte att reset var ett jättedåligt namn på knappen men att ändra den till set kändes bättre eftersom den är till för att göra inställningar. Vi döpte därmed om knapparna till OK och Set (se Figur 11). Figur 11. Spaken för interaktion Grafisk layout Efter det att vi fastställt interaktionen med hjälp av paper prototyping började vi skissa på hur den grafiska layouten skulle kunna se ut. Genom designprocessen har vi fått fram ett antal saker som vi måste tänka på nu när vi ska ta fram den 21

24 grafiska layouten. Vi har dels kommit fram till att det är viktigt att kunna visa om funktioner är av eller på med hjälp av modeless feedback. Vi tycker därför att det kan vara bra att ha ett default mode där de funktioner som är på visas med hjälp av en symbol. Här kan det vara lämpligt att visa fyra ikoner, både med tanke på plats och vilka funktioner som är viktiga att se om de är på eller av. Ikonerna ska visas på sin förbestämda position, när funktionen är avstängd blir denna plats tom. Detta tror vi underlättar för användaren att lära sig vilken funktion som är vilken och om funktionen är av eller på. För att användaren ska kunna koppla samman denna symbol med en funktion bör ikonen även finnas vid varje funktion i menyn. Detta kommer dock att ta mycket plats så det skulle eventuellt inte fungera i low tech versionen, utan endast i high tech versionen. Detta blir alltså något som endast kan finnas om det finns mer plats. Vi har även fått fram att det är viktigt att se var i menyn du befinner dig, eftersom du annars inte vet om du kan gå bakåt, framåt, uppåt eller nedåt. Här diskuterade vi olika alternativ för att lösa detta problem. Vi kom fram till olika förslag, såsom att använda oss av någon sorts numrering som visar de olika nivåerna, använda oss av pilar som visar åt vilket håll du kan gå eller använda oss av någon liten symbol, exempelvis ett streck eller en punkt som visar var du är. Efter diskussioner kom vi fram till att vi ville använda oss av streck. Genom att visa två streck för de olika nivåerna i menyn där den nivå du är på markeras genom att göra strecket fetstilt. Detta var ett diskret sätt att ge användaren information på vilket gör att det inte stör layouten eller tar för mycket plats. Om användaren inte heller förstår vad dessa streck innebär, betyder inte detta att användaren inte kan använda systemet. Dessa streck är en hjälp för användaren som underlättar för att förstå var i menyn du befinner dig. Men när vi satt och jobbade på just den biten så ansåg vi att det inte egentligen behövdes utan bara kunde störa eftersom det inte blev så snyggt grafiskt. Det förstörde med andra ord balansen och störde. Vi har även fått fram att det är viktigt att användaren kan se vad den kan göra med funktionen, om den till exempel kan nollställas, aktiveras/deaktiveras eller om någon inställning kan göras. Här anser vi också att en ikon är det bästa sättet att visa detta på. Efter det att vi fastställt hur vi vill att de olika saker ska vara utformade i den grafiska layouten började vi skissa på möjliga ikoner och symboler som kan representera de olika valen och funktionerna (se Figur 11 och Figur 12). 22

25 Figur 12. Skiss av olika idéer för lägen. Figur 13. Skiss på möjliga ikoner för olika funktioner. 23

26 2.5.3 Diskussion och slutsats Med hjälp av denna metod kom vi fram till hur de olika interaktionerna skulle gå till. Det visade sig att det var svårt att tänka sig att hjulet inte skulle användas till något annat än att göra val upp och ner, och ställa in värden. Vi kanske låste oss lite till hur knapparna används idag. Det kanske hade funnits ett bättre sätt att använda hjulet än upp och ned men detta var det som kändes mest logiskt och naturligt för oss när vi testade interaktionen. Vi kom även fram till att vi ville döpa om namnen på knapparna till OK och set. Vi kom även fram till att det tydligt måste synas om användaren kan gå tillbaka eller gå framåt i menyn. Detta är viktigt för att veta var du befinner dig i menyn. Vi tyckte att paper prototyping kanske inte var den bäst lämpade metoden för det stadiet vi var på. Men det gav oss en känsla för hur spaken skulle kunna fungera, och hur vi själva hade kunnat tänka oss använda den. Under paper prototyping kom även idén om att lägga in meddelanden i vår meny istället för att ha detta som en fristående funktion utanför färddatorn fram. Om meddelande läggs in här kan även den knapp som heter read användas på ett annorlunda vis. Detta gav oss därmed större möjligheter att ändra på interaktionen. Denna metod tyckte vi kunde ha använts i ett annat stadium i designprocessen, den hade nog även varit lämpad för att testa den slutgiltiga designen. Vi kunde få ut ganska många idéer genom att skissa och se hur interaktionen skulle tänka sig fungera. Genom att skissa bestämde vi hur det mesta skulle se ut innan vi startade med den interaktiva skissen. Vi la ner tid på hur vi ville att ikoner eventuellt skulle se ut. 2.6 Prototyping Low Tech Vi diskuterade hur det grafiska skulle se ut och ett grundläggande problem är att det är skillnad på skisser och den verkliga platsen på skärmen. Den låga upplösningen sätter svåra gränser och gör det svårare att illustrera. Detta gjorde att vi var tvungna att anpassa våra idéer för att passa in i den upplösningen. Det gjorde även att vissa idéer inte kunde riktigt genomföras. Vi tyckte att det var viktigt att kunna se om man var i huvudmenyn eller i en undermeny. Vi kom då fram att vi kunde använda oss av någon sorts indikator som visade detta. Förslaget som verkade mest genomförbart på den låga upplösningen var streck för att visa det. De beskrev vilken nivå användaren var på, men när det skulle visualiseras såg det inte så estetiskt och balanserat ut och eftersom antalet pixlar var så begränsat var det svårt att få till nått vettigt och förståeligt. Vi löste det delvis genom att få huvudmenyerna att se annorlunda ut än undermenyerna, på så sätt kan de urskiljas. I den högupplösta versionen hade det vart möjligt att försöka få in någon sorts indikator för menynivå för att underlätta navigation och ta bort onödiga inlärningsmoment. I huvudmenyn så syns tre menyval samtidigt och om användaren inte gör något så kommer han till ett default läge som bara visar klockan, växel och temperatur. När ett val gjorts i huvudmenyn så stannar den där till användaren 24

27 bestämmer sig att gå tillbaka eller byta val. Pil upp och ner har vi för att se att det finns fler val. Detta kom upp i en diskussion att det kanske inte var helt lätt att veta att det finns fler val än just det som visas. Väl inne i en undermeny tyckte vi att användaren på något sätt borde få information om vilka funktioner ett val har. Uppe till vänster använder vi ikoner för aktivera/deaktivera och uppe till höger fanns det ikoner för att ställa in eller nollställa. Vi tyckte inte att det var så självklart i dagens läge vad som gick att göra på funktioner. Inne i en undermeny så visas ikonerna i 2 sekunder, efter det så kommer klockan tillbaka. Om det inte finns något att aktivera, deaktivera eller andra inställningar så visas klockan istället på det utrymmet. Att gå tillbaks ifrån undermenyn visste vi inte om vi skulle använda oss av en knapp, men till slut så blev det ett val i menyn. Detta för att vi inte ville binda upp en knapp enbart för att gå tillbaka i menyer och vi ville använde de två knapparna för att ändra på inställningar istället. Vi diskuterade då att på nått sätt använda oss av parenteser som farthållaren, för av och på. Men det var krångligt när det kom till Antispinn som inte har några siffror utan är bara text. Det skulle inte se så bra ut, så vi bestämde att använda på och av istället. Efteråt fick vi dessutom reda på att parenteserna inte betydde AV eller PÅ utan snarare den tillfälligt inte var aktiv då den var i ett sorts viloläge High Tech Tack vare de fler pixlarna till hands är det möjligt att få in samma innehåll på ett smidigare sätt och dessutom få in extra information. Vi kunde t.ex. nu behålla klockan synlig hela tiden eftersom det fanns tillräckligt med plats för det nödvändiga i mitten av displayen. Det är också mycket lättare att göra ikoner och text lättförståeliga på en mindre yta vilket underlättar extremt mycket när man har ett litet utrymme att arbeta med. En detalj som lades till var en översiktsbild över några viktiga funktioner, där man snabbt kan se vilka som är aktiverade och vilka som inte är på för tillfället. Det är inte längre nödvändigt att gå in i de individuella funktionerna för att se detta. Detta var något som även var tänkt för den lågupplösta versionen men på grund av utrymmesbrist så valde vi bort det. Det är även möjligt att använda färger för att förtydliga vissa detaljer, men vi valde att inte använda färger i överdrift eftersom designen skulle framstå som spretigt. Menyn skulle kunna konfigureras för att mjukt skrolla när man bläddrar i den för att underlätta den visuella feedbacken man får. Skillnaderna mellan de två versionerna är främst utseendemässiga och detta beror självklart på den högre upplösningen. Den högupplösta skärmen har även ett översiktsläge som saknas i den andra. I övrigt är de mycket snarlika då de bygger på samma koncept och de har samma navigationsidé. Dock så kunde man försökt anpassa en indikator för menynivåerna eftersom man nu skulle ha kunnat ha plats för en vettig lösning. 25

28 3 Reflektion över designprocessen Den första metoden, scenario, tyckte vi var väldigt nyttig. Vi kunde med hjälp av denna metod se verkliga användningsområden för vår produkt. Så som vi utförde metoden, att utgå från användningssituation var också väldigt bra, eftersom det fick oss att tänka i andra banor än vad vi tror att vi annars hade gjort. Att vi tyckte denna metod var så bra har mycket med att göra att metoden passade just i det stadium vi var i processen samt att vi modifierade metoden så att den passade vårt problem. Vi valde att göra korta scenarion som visade sig vara bra, eftersom de var lätta att använda senare i processen. Om vi istället valt att göra färre och mer utvecklade scenario tror vi att det hade varit svårare att använda dessa tillsammans med nästa metod, card sort. Card sort var en lämplig metod för att koppla samman våra användningssituationer med funktionerna. Däremot tyckte vi att metoden krävde väldigt stora förberedelser innan den utfördes. Vi märkte att det är väldigt viktigt att klart och tydligt bestämma regler innan metoden utfördes. Vi hade behövt diskutera mer innan vi utförde metoden för att vi alla skulle vara överens om exakt hur vi skulle göra och tänka. Vi var nog för dåligt inlästa på metoden, hur den egentligen skulle gå till och vad som skulle komma ut från den. Vi tyckte att det var svårt att hitta information om denna metod och det blev därför så att vi fick utveckla en egen version av metoden. Card sort var däremot bra för att den är handgriplig och gav en bra insikt och överblick över de olika funktionerna. En sak som gav mycket var diskussionerna efteråt där vi gick igenom hur man tänkt när vi satt ut våra funktioner. Vi märkte att vi alla tänker olika, vilket gjorde att vi såg att det kunde vara viktigt att titta på olika mentala modellerna. Card sort och scenarios är båda beroende av varandra. Mest för att card sorten inte hade blivit lika bra utan scenarierna men också för att scenarierna i sig inte säger så mycket. Bäst hade varit att i början ha tillgång till en bil med liknande färddator för att kunna sätta sig in bättre i problemet. Uppgiften och tidsbegränsningen tillåter inte detta, så våra första två metoder är någon form av kompensation till att inte kunna vara i situationerna på riktigt. Klassifikationen gav oss en ännu bättre överblick över hur de olika funktionerna skulle kunna grupperas än vad card sorten gjorde. Denna metod fungerade väldigt bra som en divergensmetod, då många förslag framkom. Vi började med tre olika förslag som kommit fram genom card sort och genom klassifikationen kunde vi skapa ytterligare två förslag. Genom att visualisera de olika grupperingarna kunde vi se nya sätt att gruppera funktionerna. Vi slog samma två av förslagen till ett nytt förslag. På detta vis var metoden bra, men metoden kändes dock inte så strukturerad. Det vi kom fram till blev bra men det kändes inte som vi följde någon viss ordning eller struktur för att komma fram till det vi gjorde. Vår klassifikation gjordes genom att rita upp ett slags diagram över olika grupperingar. Om vi istället hade valt ett tillvägagångssätt som att skapa olika kort med funktionerna som vi sedan hade grupperat hade vi kanske haft enklare att hitta nya grupperingar, eftersom det hade varit lättare att ändra om funktionerna. Nästa metod, ranking och weighting, valde vi för att vi vill ha hjälp med att besluta vilket designförslag vi skulle gå vidare med. Metoden hjälpte oss att ta 26