Komentarer kring slutpresentationen

I vår slutgiltiga presentation gick vi igenom hela processen. Vi tog där upp våra två personas  med tillhörande scenarion. Vidare gick vi igenom den iterativa designprocessen samt valen vi gjort som ledde till vår slutgiltiga prototyp. Slutligen reflekterade vi kring vad vi kunde gjort annorlunda, bland annat hade vi kunnat bygga våra think alouds på varandra om vi haft mer tid. På så vis hade vi kunnat få fler loopar i den iterativa processen.

Kommentarer kring designprocessen

Vi har genomgående i vår designprocess strävat efter att använda oss av vedertagna symboler för olika funktioner för att skapa en igenkänning hos användaren. Exempel på detta är varningssymbolen och GPS-symbolen. GPS symbolen bytte vi ut till en mer igenkännelig sådan efter utvärderingen som vi fick av en annan grupp. Detta är sådant som vi kunnat förbättra i den iterativa processen genom att låta testa vår design-prototyp på användare i våra think alouds. Vi har även försökt hålla designen så pass avskalad som möjligt utan att ta bort viktiga funktioner. Detta dels ur en utseendesynpunkt, men även för att inte förvirra för användaren. 

Final Design

Den slutgiltiga (interaktiva) prototypen kan ses på följande länk: https://marvelapp.com/i9ca2d

Prototypen är skapad i Marvel och har under projektets gång gått igenom många olika designversioner, som vi tyvärr missat att dokumentera och inte kan göra nu i efterhand. Grunddesignen har dock varit mer eller mindre den samma, men vi har gått igenom flera iterationer med olika ikoner och symboler, och även layouten har knåpats med en hel del (särskilt visningen av den valda resvägen) efter feedback vi fått under kursens gång. 

Thinkaloud sammanfattning

Vår thinkaloud visade på följande brister i vår design.

1. Otydlighet kring utgångspilen och rekommandationspilen för vald vagn.
2. Gps symbolen var förvirande , dess funktion framgick inte intuitivt.
3. Beskrivning behövdes för linjesymbolen.
4. Hjälpsidan behövdes uppdatersas för tydlighet.
5. Funktion för avancerad sökning.
6. Mer information om tåglinjen man åkte med text/symbol

Utifrån våra thinkalouds feedback korrigerade vi de brister som vår design hade. Vi la även till en funktion som vi saknade, en varningsymbol för event i berörda områden samt en förklarande text.

Think aloud - Daniel

Jag gjorde en think aloud med en gammal klasskamrat till mig som numera jobbar på ett sjukhus.

Jag började med att förklara att han skulle använda appen för att ta sig från T-centralen till Bruno galleria och gav honom kontroll över appen.

 - Kommentera att appen såg väldigt lik ut SL-appen
 - Undrade vad knapparna bredvid sökfälten gjorde och försökte klicka på dom.
 - Klickade sedan på sök.
 - "Okej, nu kom det massa resultat."
 - Försökte klicka på den andra (jag gav honom en hint om att bara den första fungerade).
 - Klickade på det första resultatet.
 - "Oh, karta med resvägen. Det vore nice att ha ibland <i SL-appen>."
 - "Tunnelbanan ser inte ut så... (Syftade på tåget.) Det visar hur mycket folk det är på det? Det är ju nice."
 - "Uppgången är Götgatan, okej." Han verkade inte förstå att den även visade vilken ände av tåget som utgången var på.
 - "Ja, den visar ju det man behöver. Man ser ju vilken uppgång man ska upp för, är ju så irriterande att SL aldrig gör det."
Han kände sig färdig så jag bad honom trycka på ?-knappen.
 - "Jaha, funkar den?"
 - "... (läser) Oh, var det en sån pil? (gick tillbaka till resultat-sidan) Ah, den visar vilken vagn jag ska åka också."

Vid den här punkten kände jag att vi gått igenom det mesta.



Slutsatser:

 - GPS-ikonerna på söksidan verkar inte vara särskilt intuitiva och skulle behöva bytas ut mot ikoner som folk förstår och känner igen.
 - Uppgångs-texten verkar vara lite inklämd, så det ser inte ut som att den även kan peka till vänster (den ser inte ut att få plats till vänster), så det är oklart med bara ett exempel på en sökning att den visar vilken ände av tåget utgången är. Mer ett problem i prototypen än designen, men det behöver förtydligas.
 - När vagnpilen hamnar på mittenvagnen verkade han tro att den bara var en snygg-design-grej och var till för att visa att tåget gick från T-centralen till Slussen. Tror inte att det är så otydligt om man gör flera sökningar och ser att den flyttar sig, men designen skulle kunna förbättras, kanske med en markör på själva vagnen eller en tydligare text.
 - Det var lite oklart vad som gick att göra och inte gick att göra i prototypen, så han testade till exempel inte att trycka på help-knappen innan jag sade till. Igen, problem med prototypen, inte designen.

Think aloud av Patrik

Jag lät göra en think aloud genom att låta en kompis stega sig igenom vår design och kommentera på de val han gjorde samt tankarna han hade kring designen. Resultatet följer nedan:

Jag vill tydligen åka från Slussen till Bruno Galleria, jag trycker på knappen till höger det ser ut att vara en knapp för att ”välja destination på kartan”. Jag vill åka nu, så jag trycker på sök. Jaha, här får jag välja resväg. Det ä lite konstigt att det står Slussen, jag ville ju till Bruno Galleria. Det är tydligt vilka avgångstider som gäller. Varför står det ... mellan stationsnamnen? Jag trycker på den översta, det kommer då fram en mer detaljerad bild av resvägen. Det är tydligt vart jag skall åka. Jag antar att Götgatan kommer vara längst fram i tågets färdriktning. Pilen på mitten verkar vara den vagn jag ska välja. Här står det fortfarande att jag skall åka till Slussen (och inte Bruno Galleria). Jag trycker på frågetecknet. Jaha, ledig vagn osv. Bra förklaringar här på vad de olika symbolerna innebär. Jag fattar det alltså som att jag ska sitta i mittenvagnen.

Ett resultat av denna metod var hur användaren blev förvirrad av att det stod Slussen istället för Bruno Galleria. Kanske kan det vara bra att på något vis göra det tydligt att det är stationen Slussen som personen först måste åka till för att sedan gå till Bruno Galleria som ligger i närheten. Detta är något som kan diskuteras med gruppen för att eventuellt implementera i vår design. Det är även möjligt att vi behöver kolla på "prickarna" mellan stationsnamnen för att se om vi där hittar en bättre lösning. I övrigt verkar designen intuitiv, användaren kunde gissa sig till vad de olika pilarrna betydde redan innan han tryckte på hjälpknappen. 

Sammanfattning av seminarium 2

Under seminarie pratade vi om hur vi kunde applicera ramverket DECIDE på våran process. En stor del av diskussionen kretsade kring valet av metod och vilka praktiska/etiska problem respektive metod skulle kunna medföra. Vi kom fram till att en stor del av utvärderingen skulle utföras av oss själva som i en heuristisk utvärdering, och att det därmed inte skulle finnas så många etiska problem att hantera. Ett praktiskt problem som vi betonade var att vår produkt fortfarande är i ett tidigt stadium och vår prototyp inte ännu är riktigt klar. Det vi landade i var alltså följande:

D: vår övergrippande målet med utvärderingen kommer att avgöra om appen är användarvänlig.
E: Frågor som skulle hjälpa att besvara denna fråga: Visas rätt information vid rätt tillfälle?
Finns det överflödig information? Är designen intuitiv?
C: Vi kom fram att cognitive walkthrough var mest praktisk att använda eftersom vi redan har personas och scenarion som kan appliceras i en cognitive walkthrough.
I: Praktiska problem som vi kommer att stöta på är att tid är vår enda egentliga resurs , att vi inte har någon färdig produkt och att våra tänkta personas inte nödvändigtvis reflekterar oss själva.
D: Vi har inga etiska problem eftersom vi gör det själva.
E: Det sista man gör är att kolla igenom hur evalueringen gick, vid behov loopar man igenom punkterna igen tills målet med utvärderingen uppnåtts.

Seminarium 2: Evaluation

I kapitel 13 presenteras DECIDE, som är en iterativ metod för att planera utvärderingen av en produkt. Den tar hänsyn till etiska och rent praktiska problem som kan uppstå under utvärderingen och ämnar att hantera dessa på ett strukturerat sätt. Enligt denna metod är bör man vara noga med att specifikt avgöra målet med utvärderingen och vilka frågor som är relevanta i utvärderingen, för att sedan kunna välja lämpliga evalueringsmetoder och hantera eventuella problem.

Kapitel 15 tar fram evalueringsmetoder som är mindre beroende på användare och istället använder experter inom design och MDI-området för att utvärdera produkten. I vårt fall kan kanske medlemmar från andra grupper i kursen agera som experter i testandet. En annan metod är s.k. walkthroughs eller genomgångar, där man försöker förutse vilka problem en användare skulle kunna stöta på i användandet av produkten. I en kognitiv genomgång försöker man karakterisera den typiska användaren och sedan tänka sig att man går igenom de olika stegen i designen ur den tänkta användarens perspektiv. Pluralistiska genomgångar går ut på att de som utvärderar designen var för sig antar rollen som användare och ett steg i taget försöker lösa en viss uppgift mha produkten, där de efter varje steg jämför och diskuterar vad de gjorde. Detta är nog en metod som skulle kunna vara användbar för oss för att förbättra vår design, i och med att de begränsningar som boken tar fram (ex att samla ihop gruppen och tidstillgång) inte är ett problem för oss i lika stor utsträckning.

Seminarie 2, Daniel Isheden

Evaluation

Kapitel 13 beskriver en metod för evaluation som förkortas DECIDE. Om man vill evaluera en produkt behöver man först ett övergripande mål med evalueringen. Detta beror på vem som vill göra evalueringen och vad syftet med den är. Man kan sedan gå vidare till att definiera specifika frågor man vill besvara med evalueringen. Därefter väljs en evalueringsmetod som kan svara på dessa frågor. Man behöver också ta hänsyn till praktiska och etiska problem som kan uppstå under evalueringen och hur dessa ska behandlas. Hur data ska samlas in och hur datan ska behandlas är ett exempel på vardera. När man har samlat in data är det dags att evaluera, analysera, tolka och presentera datan.

Kapitel 15 handlar om olika evalueringsmetoder. Då boken tidigare mest använt sig av utvärderingar med hjälp av ett stort antal användare fokuserar kapitel 15 på utvärdering utan användare, då involvering av ett stort antal användare kan vara kostsamt och ta tid. Heuristic Evaluation är en metod där man med hjälp utav ett gäng experter utvärderar användargränssnitt med hjälp av vissa riktlinjer kallade heuristics. Walkthroughs är en annan metod där man steg för steg går igenom en användares upplevelse av ett användargränssnitt och försöker att föreställa sig hur detta är för användaren. Cognitive walkthroughs fokuserar på just kognitiva saker, till exempel ifall användaren har fått all information för att kunna göra det de vill. I Pluralistic walkthroughs involverar man även faktiska användare, inte bara utvecklare och/eller experter. Ännu en teknik kallas GOMS-modellen och är en teknik där man försöker sätta exakta nummer/värden på användarens prestanda, vilket gör att man kan göra konkreta jämförelser mellan olika versioner av ett gränssnitt möjliga.

Inför Seminaruim 2, Tärning

   När det kommer till att evaluera sitt arbete så är DECIDE en utmärkt mall att använda inför detta steg. Först och främst är steg nummer ett att ställa upp ett mål, vilket man därefter kopplar olika frågor till. Efter det kommer val av metod och identifiera vilka praktiska problem som kan uppstå från det. Slutligen gäller det fundera över hur de etiska aspekterna ska hanteras och hur ens erhållna data ska tolkas, analyseras och presenteras.

   En stor fråga är hur vi själva ska kunna applicera denna metod när det enda vi har att komma med är en pappersdesign av vår reseplanerare.

   Utöver DECIDE så finns det naturligtvis andra sätt att gå till väga, såsom utvärderingsstudier. Inom det här området finns det en skala som går mellan en kontrollerad och en okontrollerad miljö, vilket begränsar en till olika typer studier som går att utföra. Vi har tre stora tillvägagångssätt här: Användbarhetstest, experiment och fältstudier. För oss kommer med största sannolikhet fältstudier vara den typen av studie för att evaluera vår applikation ifall vi utför en. De två andra metoderna är helt enkelt allt för tids och resurskrävande. Jag förutspår att det kommer bli mycket svårt att hitta en sal som vi kan använda för att inrätta ett användbarhetslaborationsrum, om vi nu bestämde oss för det.

   Slutligen kan det vara värt att nämna den heuristiska granskningen. Den här metoden har en någorlunda klar checklista som vi bör kunna applicera på vårt eget arbete gällande användbarhet och effektivitet, även om vi inte är experter borde vi kunna åtminstone hade den i åtanke när vi designar applikationen. Vad mer skulle en genomgång av vissa delar också vara aktuellt till skillnad från analys av användarna. Ett sådant åtagande skulle återigen vara för resurs och tidskrävande. Avslutningsvis så tror jag inte heller vi kommer kunna ha den kunskap som krävs för att kunna använda någon metod om förutsägbarhet på ett effektivt sätt

Seminarie 2, Erik Ledin

Kapitel 13 och 15 handlar om evaluation, och ger konkreta riktlinjer för hur det kan utföras. Detta bidrar till att ge oss en teoretisk grund att utgå ifrån både då vi designar och evaluerar designer.

Kapitel 13 fokuserar främst på evaluering med hjälp av användare och DECIDE. DECIDE är ett framework som ger en checklista för att hjälpa planera en evaluering, där man ofta iterativt rör sig framåt och bakåt i checklistan, snarare än rakt igenom, då alla delarna beror på varandra, och måste därför ses på som en helhet.

Kapitel 15 behandlar evaluation methods där man inte behöver användare på plats, utan istället fokuserar på förståendet av användaren, bland annat med hjälp av analys av inhämtad data eller modeller som söker att förutspå användares beteende. Heuristic Evaluation är en metod för att undersöka användbarhet baserat på testade principer. Denna metod är mycket användbar då man inte behöver användare för att utföra en evaluering, men man behöver istället experter inom området. Kapitlet beskriver också analytics som en metod som används för att evaluera ett system.  Det går ut på att man loggar användare, och analyserar det data man får fram. Då dessa data ofta är exakta och *kvantitativa* är de ofta mycket lätta att visuallisera.

Till vilken grad är det okej att logga användare av ett system? Trots att det är för att förbättra systemet för användarna så kan det ändå ses som integritetskränkande.

Seminarium 2

Nu har vi kommit till det stadium där vi behöver utvärdera våran produkt. Kapitel 13 handlar just om detta, hur man ska utforma en utvärdering. Detta gör att vi lättare kan upptäcka eventuella problem med våran produkt.Till vår hjälp erbjuder boken metoden "DECIDE". Det är en punktlista med saker man bör iterera igenom tills man har en bra utvärdering. 

D står för Determine the Goals och det handlar om att man bör fastställa vad målet med undersökningen är. Det är bra i vårt fall eftersom vi då kan utforma undersökningen efter detta, varför vill folk använda sig just av våran app? E står för Explore the questions och det handlar om att man måste specifiera vilken fråga utvärderingen ska svara på. Det gör att man kan begränsa sin undersökning eller förbredda den. Det tredje C i decide står för Choose the evaluation metods det handlar om att man ska välja rätt utvärderingsmetod för att svara på frågorna. I vårt fall kanske det är bäst att observera någon som använder sig av appen. I står för Indetify the practrical issues, det betyder att man ska ta hänsyn till vilka användare som ska vara med i utvärderingen.Detta för att de ska representerara potentialla användare. Man bör också ta hänsyn till budget och verktyg.  I vårt fall är tid den mest begränsade resursen.Det femte d står för Decide how to deal with ethical issues och det handlar om hur man ska genomföra utvärderingen med personens integritet i baktanke.Den sista bokstaven står för Evaluate,Analyze,Interpret,and Present the data. Hur ska man analysera datat och hur presenterar man det man kom fram till . Utvärderingen ska vara pålitlighet(reliable) ifall man repiterar undersökningen ska samma svar komma up.Den ska vara giltig(validity). mäter ens undersökning det den ska? En ecologisk giltighet(ecological validity ) mäter hur miljön kan ha påverkat resultaten. En person kommer att agera annorlunda i en lab miljögemfört med i verkligheten. Scope är i vilka områden ens resultat kan apliceras på , var det en smal eller bred undersökning? Bias är när undersökarens själva osikter påverkar resultaten.

Kapitel 15 handlar om hur man kan samla data utan att själv interagera med det man undersöker. Heuristik utvärdering innebär att expert undersöker produkten, i vårt fall kommer vi inte kunna anlita en expert för att undersöka våran produkt. Man kan använda sig av genomgång(walkthroughs ). I en cognitive genomgång man tänker sig hur en person skulle kunna använda appen och vad hen skulle göra. En pluralistic genomgång tänker man sig att man har ett scenario och persona. Detta gjorde vi själva i övning 3.  Analytisk utvärdering innebär att man kollar igenom traffiken. Förutsägbar utvärdering ( predictive models) innebär att man försöker se samband i användandet av appen och sedan kunna skapa modeller efter det. 

Seminarium 2.

Med hjälp utav DECIDE ramverk, så kan man enkelt och strukturerad; att ställa upp ett klart och tydlig mål för en projekt, utforma frågor relaterad till ens mål. Baserade på hur man fick fram data för sitt arbete så används olika utvärderingsmetod. Utvärderingen kan utföras av olika personer , ex. experter eller användare. Man tar också hänsyn tills ens budget och resurser i problem delen.

Då man inte alltid har möjligt att ha en användar-undersökning, då använder man sig av en Heuristic evalutation, där man använder sig av experter för att få fram dem information man behöver för sitt projekt, inga användare används under hela processen utan är enbart några få personer som går igenom ens applikation/projekt, kan kosta mer men är mer effektivt.

Det finns också Walkthroughs, då finns det olika metoder inom det:

Cognitive walktrough, där man genererar fram relaterade scenario som man sedan går igenom med experter och letar efter problem som kan uppstå för användaren.

Predictive, där man förutspår ett problem som kan förekomma utan att göra en användar-undersökning. En pluralistic genomgång, där man tänker sig utifrån användares perspektiv ( persona ), och går igenom alla problem som de kan påträffa.

Analytisk utvärdering, innebär att man kollar igenom trafiken för ett ställe eller hemsida.

Begrepp till seminarie 2

DECIDE är ett ramverk för att göra evalueringar genom att använda sig av användarna. Mål ställs upp och därefter frågor kopplat till målen. Beroende på vilken typ av data som behövs för att svara på frågorna ställs olika evalueringsmetoder upp. Olika deltagare kan vara med i evalueringen, experter, användare, eller potentiella användare.     

En annan evalueringsmetod är att använda sig av heuristiker för att evaluera en applikation. Det är en mängd principer som definierats för att kunna hitta problem hos en app. I denna typ av evaluering används experter som sitter under en tid och systematiskt går igenom applikationen och testar dem mot heuristikerna. Det är dock dyrt med experter, men inga användare behövs för denna typ av evaluering, så på det viset kan det i många fall vara en bättre metod.

Kognitiv Walkthrough, annan typ av evaluering som inte häller behöver användare. Man går igenom ett scenario i appen och dokumenterar tydligt problem man stöter på på vägen. Denna metod är mer inriktad på att identifiera specifika problem med hög noggrannhet. Tar lång tid.

I pluralistisk walkthrough arbetar utvecklare användare och experter tillsammans för att steg för steg gå igenom ett scenario.

Analytics, man kan mäta hur många som besökt en viss hemsida under en tid och använda det i sin evaluering.

Parallell Design slutgiltig version

Den slutgiltiga Parallell designen kombinerade båda 2 tidagare designs. Vi använde oss av design 1 som grund och la till funktioner från design 2. Funktioner som lades till var en  karta över färdväg med event och en tredje sida,färdsidan som visade hur man skulle åka i realtid.

Sammanfattning av designprocessen

I vår designprocess har vi arbetat med tre olika metoder, collaborative iteration, parallell design samt word association. Resultaten från de olika arbetsmetoderna har vi kunnat sammanställa till en slutlig idé om hur vår app skall vara designad. Vi har i alla metoder haft nyckelorden ändamålsenlighet, effektivitet och tillfredsställelse (hämtade från ISO-definitionen av användbarhet) i tankarna. Genom att använda oss av flera olika metoder har vi kunnat arbeta fram en designidé utan att snöa in på ett visst spår. De olika metoderna gör att vi tvingas tänka om kring begreppen och hela tiden uppdatera vår designidé, således är vår designprocess iterativ.

Definition av användbarhet

Följande definition (1SO -9241-11)  av användbarhet gavs på föreläsningen 9/2:

"Den utsträckning till vilken en specificerad användare kan använda en produkt för att uppnå ett specifikt mål, med ändamålsenlighet, effektivitet och tillfredsställelse, i ett givet användningssammanhang."

Utsträckning, innebär att användbarhet är något mätbart, man kan således jämföra två produkter med varandra genom att testa dem på:

-Samma användare
-Samma sammanhang
-Samma uppgift

Det man då mäter är ändamålsenligheten, effektiviteten och tillfredsställelse. Detta motiverar den State of the Art analys som gjordes på liknande applikationer. Vi kunde med den titta på appens ändamålsenlighet och effektivitet. Huruvida de ledande apparna inom området tillfredsställer de behov användarna har kunde vi mäta med intervjuerna. 

ISO-definitionen har även funnits med i tankarna när vi sedan utvecklat vår egna design. Vi tar där fasta på begreppen ändamålsenlighet, effektivitet och tillfredsställelse.

Parallell design #2

Den andra gruppen hade en liknande idé. Man har 3 stages I appen search stage, route stage och travelstage. Search stage liknar förra gruppens söksida fast med en fysisk karta som visar väg och event. Route stage liknar resultatsida fast med en karta och en sortering beroende på snabbhet och folktäthet. Travelstage är ett gps stage som visar hur man ska åka.

Parallell desigin #1

Söksida: Söka från och till. Nuvarande positions-knappar. Swap till och från-knapp. Tidval. Avancerad-knapp för att få fler alternativ.Resultatsida: Sammanfattad lista över resor. Ikoner visar byten, men by default visas bara avgångstid och ankomsttid samt stationsnamn. Klickar man på en resa expanderas den. Visar alla byten, knapp för att undvika ett visst färdmedel I resan, visar tiden för byten. Mellan stationerna som en resa innefattar finns grafik för färdmedlet (tåg, tunnelbana, buss) för folkmängden I varje vagn och vilken vagn som rekommenderas. Uppgångsnamn + vilken ände av tåget man ska upp på finns I varje byte som det är relevant för (inte buss).

Collaborative Iteration

Vi började med att göra en Collaborative Iteration. Resultaten från våra post-it lappar sammanställdes nedan.

Position ( pereong )

Vi diskuterade kring hur vi ville presentera datan för användaren och kom fram till att för

mycket bilder tar fokus ifrån appens huvudsyfte. Därför kommer information om vilken

uppgång användaren skall ta presenteras I textform. En bild på ett tåg kommer att finnas högst upp på söksidan där det framgår vilken vagn användaren bör välja utifrån antal personer som reser och vilken sida av perrongen som användaren skall upp på.

Info om event
Vi kom fram till att mycket av problemet som denna pain point handlar om kan reduceras till lösningen av positioneringen på perrongen. Vart användaren skall gå upp skall baseras på om det sker något event I närheten. Den information som användaren skall få kring detta är snarare en liten varning I samband med sökningen, att det kan tänkas vara väldigt mycket folk på perrongen. En annan resväg skall då erbjudas via en knapp till höger om sökningen. Intill knappen för den alternativa resvägen skall tiden för den resan stå.

Alternativa resvägar
Vi kom fram till att många av de reseappar som finns redan har funktionen att få fram alternativa resvägar. Så detta är inte riktigt en Pain point, men fortfarande något som skall implementeras I vår app. En knapp för alternativ sökning skall finnas till höger om sökningen man gjort.

Sökväg
Användaren skall kunna skriva in saker som ”KTH”, eller namnet på en restaurang I sökfältet. En liten karta kommer upp där användaren ser närmaste hållplats och vägen dit, samt vilken tid det tar.

Persona & Scenarios

Persona #1: Turist
Persona #2: Förälder 

Persona #1

Maxime, Turist 25 år. Södra Frankrike.

Bakgrund

Fransk student som pluggar marknadsförning , bristande engelska och ingen svenska. Två veckors semester innan hösterteminen börjar. Han föräldrar äger en väldigt framgångsrik företag, så de har bidragit med pengar till resan. Han bor ensam I en lägenhet I Paris som hans föräldrar har köpt till honom när han började plugga I universitet.

Personlighet

Han är en nyfiken person som gärna vill uppleva nya saker och upptäcka nya platser och människor. Äventyrlig. Han blir lätt uttråkad så han ville gärna resa runt och utforska världen.

Mål

Han är nyfiken på att uppleva Stockholm då han har hört mycket från sin kompis som nyligen varit där. Under sin tid I Sverige har Maxime tänkt att spendera en vecka I Stockholm. Maxime har fått en lista av tips från sin kompis på ställen att besöka I Stockholm.

Scenario #1

Efter sin ankomst till T-centralen, med arlanda express vill Maxime hitta sitt hotell för att checka in. Maxine har namnet på hotellet, men vet inte vilken station han skall av på. På sin Iphone skriver Maxime in vilket hotell han skall till, men telefonen visar bara gångväg/ bilväg. Eftersom att han har mycket väskor med sig så vill han helst inte gå sträckan. Maxine går till pendeltågen och kollar kartan, men förstår inte hur han skall hitta sin resväg. Han går då till SL-centret och frågar om vägen. De pekar honom mot tunnelbanan och säger åt honom att ta den till Slussen. På plattformen tittar Maxime på en karta över tunnelbanestationerna och hittar efter en stund Slussen på kartan. Väl framme vid Slussen blir Maxime osäker på vilken av uppgångarna som är närmast till hotellet. Han testar då den ena, och hamnar I bussterminalen. Han går då tillbaka upp till perongen och söker sig ut till gatan istället. Därifrån följder Maxime telefonens vägbeskrivning till Hotellet.

Scenario #2

Under sin första kväll I Stockholm träffade Maxime en trevlig svensk tjej och de bestämde sig för att äta middag ute dagen efter. Den svenska tjejen kände till en bra restaurang vid kungsträdgården och bokar ett bord för dem klockan 19.00. Maxime är sent ute och har väldigt kort tid på sig att komma fram från Slussen till Kungsträdgården. Maxime har listat ut att resan kräver ett byte till blåa linjen I T-centralen genom att titta på en karta I tunnelbanan. När Maxime anländer till T-cetnralen visar det sig att en stor demonstration har ägt rum och det är väldigt mycket folk på perongen. I den stora folkmassan hittar Maxime inte nedgången till blåa linjen och missar därmed bytet vilket resulterar I att han får vänta ytterligare 5 minuter. Väl framme I kungsträdgården har Maxime svårt att hitta rätt uppgång, när Maxime som inte gett sitt nummer till den svenska tjejen kommer fram 30 minuter sent, har tjejen redan gått hem.

Persona 2 Pernilla 32 år

Bakgrund

Pernilla är 32 år hon har precis fått ett barn martin som är 5 månader gammalt. Hon gick samhälle på gymnasiet och arbetar vanligtvis som sekreterare men är nu mammaledig.Hon är inte teknik intresserad och kan ha problem med komplicerade gränssnitt. Pernilla är gift med Ragnar ,de har en stabil ekonomi och Jacob är deras första barn.

Mål

Pernilla vill utföra ärenden I stan I lugn och ro utan att stressa. Hon vill undvika att störa så många som möjligt med sin son Martin.

Personlighet

Pernilla gillar att ta det lugnt och har sällan bråttom. Hon gillar långa promenader och att dricka latte.

Scenario 1,babykläder

Det är onsdag och Pernilla är på väg för att köpa rutigababykläder. Denna dag är Jacob ovanligt högljud och pernilla har gott om tid för att ta sig till affären. Hon kommer söderut för att ta sig in till NK.Hon går in I felände av parången ock måste kånka med vagnen igenom hela änden.När hon kliver på tåget är det svårt att ta sig fram med barnvagnen eftersom de är trångt på tåget. Väl inne på tåget skriker Martin högljudd och Pernilla önskar att hon kunde tagit en lugnare väg eller tillfälle att åka tåg

Scenario2.

Det är lördag och pernilla ska på barnbio och see zootopia på svenska.Hon vet verken adress eller station till bion.Hon måste då spendera tid på att hitta väg till salongen.När hon åker från slussen är det exremt mycket folk dära på grund av en mattävling.Hon önskar att hon visste om att det var ett event just idag.

List of pain points

Problem	Persona #1	Persona #2
Positionen vid perrongen	2	2
Info om event	2	4
Alternativa resval	1	1
Sökväg(Utöver adress)	1	1

1(Viktigt)------5(Onödig)

Gruppens State of the Art sammangfattning

Ett tydligt genomgående tema som framgick i vår analys av de ledande apparna för reseplanering var frånvarandet av möjligheten att i appen kunna få information om saker som vilken nedgång/uppgång som är bäst lämpad till den resväg man söker. Samt information kring event och dylikt som kan innebära en stor trängsel i tunnelbanan visa perioder. Genom att gå tillbaka till de intervjuer som vi tidigare gjort kan vi konstatera att detta var kriterier  som var önskvärda hos många av de intervjuade personerna. Således ämnar vi ta fasta på detta som funktionella krav i vår app.

State of the art - Apple Maps

Apple Maps

Funktionella krav
Apple Maps är en app för iOS som kan användas för att utforska och söka på en världskarta. Kartan kan visas antingen som en färgkodad logisk representation av världen (standard), från en satellitvy eller i olika 3D-lägen, dock stöds 3D-lägen endast i vissa städer. Den har även funktioner för att beräkna vägbeskrivningar mellan två punkter på kartan, antingen med bil eller till fots. Den kan sedan användas som en GPS som signalerar när det är dags att svänga, etc. Maps kan inte söka vägar med lokaltrafik i Sverige, men har till viss grad integration med andra appar, där den kan vidarebefoga en sökning till en annan installerad app, till exempel SL-appen. Vid en sådan vidarebefogning startas den andra appen och utför sökningen direkt, vilket i alla fall är något. Maps kan även vidarebefoga en sökning till appen "Uppgångar Stockholm", där man verkar kunna söka just vilken uppgång man bör ta för att ta sig till en viss plats, men denna app kostar pengar och är som sagt en separat app.

Icke-funktionella krav
Appen har ett trevligt användargränssnitt som är bekant för alla som använder kartor och appar generellt på mobilen. Den är också kraftigt integrerad i operativsystemet på ett sätt som gör att man kan se kartan och vägbeskrivningen även om mobilen inte är upplåst, vilket är praktiskt. En mer frustrerande funktion är att kartan går att rotera genom att dra med två fingrar. Tyvärr är det samma gest som för att zooma vilket man vill göra betydligt oftare än att rotera, och det slutar ofta med att man av misstag roterar kartan en aning.

Apple Maps har grundläggande funktioner för att hitta vägen mellan två punkter, men ingen funktion för att hitta vägen med kollektivtrafik. Den saknar även information om var exakt nergångar i tunnelbanan är, då den bara visar var stationen är (alltså kanske mitt i en gata om stationen är under marken). Den kan i alla fall skicka dig till rätt app för att göra sådana sökningar, men detta är klumpigt och kräver att användaren installerar dessa appar, som kan kosta pengar. En app som har funktionen att söka en väg inom kollektivtrafiken med exakta instruktioner om uppgångar och vägar mellan byten, samt information om vilka vagnar som har minst folk på tunnelbanan/pendeltågen och vilken ände av stationerna man vill kliva av på för att komma till sitt mål skulle vara en stor förbättring jämfört med Apple Maps.

State-of-the-Art analysis: Hitta.se

Hitta.se finns både som internettjänst och som mobilapplikation och erbjuder utöver en reseplanerare vissa andra tjänster, som till exempel personupplysning och vägbeskrivningar. I reseplaneraren kan användaren mata in två punkter som hen vill resa mellan och även ange tid och datum för antingen avresa eller ankomst. Till skillnad från till exempel SLs reseplanerare kan dessa punkter vara vart som helst i Sverige och behöver inte nödvändigtvis vara adresser eller hållplatser, utan kan även vara byggnader, områden eller till och med personer. Använder man en dator kan man flytta dessa punkter på kartan med hjälp av musen. Det finns även en knapp för användaren att använda sin nuvarande position som startpunkt för resan. Hitta.se har alltså integrerat sina tjänster i reseplaneraren genom att man till exempel kan skriva in ett namn på en person eller ett företag som destination och reseplaneraren då genom personupplysningen tar fram adressen. För varje resa anges förväntad tidsåtgång och instruktioner på vart man ska gå och vilka tåg och bussar man ska ta. Resvägen visas även på kartan i blått, och finns det alternativa resvägar visas de på kartan i grått. Dessa är de huvudsakliga funktionella kraven på reseplaneraren som är uppenbara för användaren, och utöver dem finns det självklart vissa icke-funktionella krav som kan vara svårare att se. Till exempel lär reseplaneraren vara kompatibel med de flesta webbläsare och mobilmodeller, och även själva utformningen av reseplaneraren lär fylla vissa icke-funktionella krav så som att den ska vara tydlig och lättanvänd.

Problem som reseplaneraren har är att den blir väldigt kompakt på mobiler, vilket gör att kartan i mitt fall endast syns som en ca 1cm hög rand längst ner på skärmen. Reseplaneraren är alltså mycket bättre lämpad större skärmar än små. Något som jag tycker är väldigt användbart med reseplaneraren på Hitta.se är att man kan skriva in t ex restauranger som destination, så att man slipper kolla upp adressen separat. 

En analys av Tärning

   Då vår grupp planerar på att bygga en reseplanerare så bestämde jag mig för att undersöka Nobinas app  ”Res i STHLM: SL reseplanerare ” närmre. Appen är tillgänglig gratis via appstore på iphone. Som funktionella krav har vi naturligtvis som alla andra reseplanerare att utifrån en viss startpunkt och slutdestination skall programvaran generera de mest effektiva resvägarna med avseende på tid. I de föreslagna alternativen skall både den totala tiden och samtliga byten med avgångstider samt en karta med den utplottade vägen redovisas. Som funktionellt krav finns det dessutom också en möjlighet att använda sin nuvarande plats som både start och slutpunkt, spara både favoritplatser och resor för återanvändning och lägga olika begränsningar på sökningen såsom att resan skall gå via en viss station, vilka linjer som ska eller inte ska ingå, vilken sorts färdmedel man vill använda och alternativa hållplatser. En användare kan också bestämma i sökningen när de vill åka och om det är då de senast vill åka eller tidigast vara framme. Utöver det ska användaren också kunna se avgångar i realtid för en vald hållplats och även kunna se störningar i lokaltrafiken.

   Till det icke funktionella kraven så är appen designad på ett sådant sätt att den emulerar Apples egen design för sina mobiler vilket skapar en konsistent känsla mellan operativsystemet och programmet för vana iphoneanvändare. Val mellan menyerna finns i botten och i toppen finner man knappar för att verkställa sina sökningar, uppdatera sidorna eller backa tillbaks, vilket lämnar ett stort utrymme i mitten för alla information. Majoriteten av fälten för olika alternativ finner en bra kompromiss mellan en onödig storlek och svårighet att markera. Trots det så är appen mycket lik Stockholms Lokaltrafiks reseplanerare på nätet, vilket inte är särskilt förvånande med tanke på deras gemensamma syfte. Då båda systemen delar många funktioner förenklar det för personer som övergår från den ena till den andra. Vad mer är även paletten mycket lik varandra utan att försvåra läsandet. De olika resemetoderna är utöver det färgkodade i resebeskrivningarna vilket också underlättar.

   Utifrån analysen och våra intervjuer så har vi kommit fram till några så kallade ”fit criterions”. En av de tydligaste var trängseln på tågen och svårigheten att veta i förväg hur situationen såg ut. Vi ser det som ett funktionellt krav som vi kan utföra i vår egen produkt som saknas i dess konkurrenter.

Felix Kam, State of the art analysis -- SL

Jag har undersökt http://www.sl.se
Funktionella krav
Enkelt att navigera på sidan, man kan enkelt välja när man vill åka och vilken tid, fastän det finns alternativ att välja vilka stationer man vill passera eller ändra färdmedel, så är den funktionen dold när man besöker sidan. Det får en och tro att det inte går och ändra i första början.
Bra att det medförs en karta, ifall man skulle behöva gå en bit för att komma till sin destination, så man vet hur långt och vart man ska gå.
Finns klart och tydliga information om det är något fel på någon färdmedel som de använder sig av.

Icke funktionella krav
Den funkar lika bra oavsett storleken på dataskärmen eller ens smart-phone, Android eller iOS.
Det finns en knapp så att man kan byta plats på Från och Till, så att man kan se vilka tider det finns på tillbaka vägen.

Det som jag personligen tycker saknas på SL, är mer information om alla färdmedel t.ex. en live update där man kan läsa eller se, hur mycket utrymme som är finns på alla färdmedel på den sökta färdsträckan.
SL rekommenderar alltid tunnelbanan eller pendeltågen, då de rymmer mest människor per åktur, fast det är kanske inte den snabbaste vägen, så man måste själv bocka av tunnelbanan/pendeltågen som färdmedel, det vore smidigare om de nu hade en funktion som man kunde välja "kortaste vägen" eller "snabbaste vägen". Och med hjälp av live update som de borde skaffa, kan man t.ex. se hur full bussen är.