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.