Seminarium 2 Tobias Edwards

Evaluation är centralt vad det gäller en produkts design eftersom det fokuserar på användar-vänligheten och hur användaren upplever produkten. Om det finns brister där tror jag det är sannolikt att produkten inte blir särskilt populär. Idag är det viktigt att evaluera produkter eftersom, t.ex. appar, ska inte bara genomföra en uppgift, utan det ska också vara trevsamt vid utförandet. 

Evaluation genom controlled settings involving users har fördelen att man kan tydligt se användbarhetsproblem, men saknar någon användningskontext, här kan man applicera usability testing. Evaluation kan göras genom natural settings involving users, där man inte undersöker användaren i en bestämd miljö, utan i deras naturliga miljö. Sista metoden kallas för any settings not involving users. Personligen tycker jag en kombination av de två första metoderna kan ge bäst resultat, då den sista metoden involverar inte någon användare - i värsta fall har utvecklaren missat något väsentligt. T.ex. är en metod inom sistnämnda evaluation-tekninken heuristic evaluation, där man går genom scenarion och applicerar vanliga användarbeteenden utan att kontakta användarna.

Evaluation där utvecklaren inte kommer i kontakt med användaren kan bero på att det är för dyrt, eller svårt att inblanda användaren i designen. Vid hueristic evaluation är det bra om man är flera utvecklare som försöker identifiera problemen eftersom, medan en person kan la lätt att identifiera usability principles, kan en annan person kanske har väldigt svårt att se felen i en design. Då blir det istället en fråga om kostnad: fler utvecklare ger mindre fel, men kostar mer att anställa. 
 
Ibland kan tidig evaluation, opportunistic evaluation, användas för att hitta fel i en design innan det blir för dyrt/svårt att fixa. Viktiga saker att tänka på vid evaluation är reliability, validity, ecological validity, biases och scopen. I all forskning tror jag att dessa punkter är viktiga att ha i åtanke eftersom det påverkar trovärdigheten av en tes (i vårt fall motivering till en design). Om det inte går att återskapa resultaten (reliabilty), om fel metod används vid undersökning (validity) eller om data görs selektivt (bias) kan slutsatsen av en studie inte vara pålitilig.

Ett annat sätt att testa en design är med så kallad walkthroughs, som är uppgift-specifica, d.v.s. utvecklare planerar en uppgift att utföra och notera problemen med användbarheten. Jag tycker dock att denna metod kan vara dyr för företyg då jag tror att det skulle ta lång tid att genomföra för flera olika uppgifter. En variation är cognitive walkthroughs där vid varje steg i uppgiften ställer den som genomför uppgiften sig ett antal frågor angående användbarheten. Ytterligare en metod är pluralistic walkthrough som tilllåter utvecklare och användare samarbeta för att förbättra användbarheten. Jag tror en cognitive walkthrough kan vara bra tidigt i designprocessen, och sen senare använda pluralistic som hjälp att fixa det man missat.

Analytics är en metod för att evaluera användartrafiken i ett system, t.ex. en hemsida. Dessa i samband med visualiseringsverktyg kan tydligt visa ett systems designfel. Lifelogging är evaluation av GPS-data och personlig användarinfo, vilket måste behandlas försiktigt för att undvika integritetsfrågor.

Sammanfattning av Övning 3

Vi bestämde oss för att börja med att brainstorma fram idéer utifrån våra Pain Points. För att öka antalet idéer att välja mellan och eftersom vi had svårt att välja en Pain Point bestämde vi oss för att alla skulle börja på var sin idé. Vi skrev på var sin post-it lapp vad vi hade för grundidé. Sedan skickade man vidare den till nästa person som då skulle bygga vidare på idén. När alla idéer gått ett varv samlade vi ihop dem och började diskutera.

Vissa idéer gick snabbt bort medan andra liknade varandra.  Till slut satte vi ihop två olika idéer utifrån vad vi hade skrivit och gick vidare till parallell design. En idé byggde på en relativt traditionell app men som både bör finnas lätt tillgänglig för användaren och vara väldigt användarvänlig. Den andra byggde på en google glasses app där användaren automatiskt får information.

I gruppen med Lucia, Toby, Lars och Ludvig diskuterade man den första idén. En app som skulle finnas tillgänglig på perongen, utanför spärrarna, och även andra ställen i samhället där många kan tänkas använda den. Tanken var att den skulle finnas på en stor touch-skärm så att den är lätt att läsa och använda. Det ska även finnas högtalare som kan läsa upp information för att underlätta för de med synproblem. Röststyrning diskuterades också men lades åt sidan då det kräver att användaren känner sig säker i att prata med en skärm, vilket gruppens personas inte tros vilja, och att ljudnivån runt omkring inte är allt för hög. Själva app-designen började också utformas.

I gruppen med Martin, Isak och Jacob diskuterade man den andra idén. En kombination av google glass och en mobilapplikation. Appen skulle sköta val av resvägar medan glasögonen skulle kunna visa pilar på marken till vart personen ska gå eller färgade bitar av perongen som visar vart personen ska gå på för att få en lugn vagn. Efter diskuterande kom de fram till att en applikation inte behövdes, istället kan resor göras t.ex. genom att peka och dra på kartor vid stationerna för att välja var du åker ifrån och vart du ska.

Collaborative iteration

Idé-mängden som skulle sållas

De två idéerna 

Sammanfattning av intervjuer och SotA-analyser.

Intervjuer

Utifrån våra intervjuer har vi fått information om problem som målgruppen känner att de har.

Majoriteten av målgruppen använde reskassa med några undantag på års- respektive månadsbiljett. Detta beror främst på att de inte åker så ofta och vill få ut så mycket som möjligt av vad de betalar.

Målgruppen vänder sig till tunnelbanan för att det går snabbt och är lättare än att köra bil. Vissa hade inte bilar.  De flesta åkte några gånger i veckan men det var inte många som åkte varje dag.

Majoriteten åker mitt på dagen och skulle inte känna sig bekväma med att åka för sent på natten.

Mobilapplikation är ovanligt för att ta till sig information men förekom i vissa fall. De andra använde högtalarsystemet eller kände till avgångstiderna tillräckligt väl för att inte behöva kolla upp.

Målgruppen uppfattar inga större problem med sittplatser men behöver ibland säga till för att få en plats.

Särskilda problem som uppkommit under intervjuerna är störelsemoment (musik och tiggeri samt stökiga ungdomar), synfel, krångliga applikationer, tidtabellsbyten som stör synkningen av olika transporttyper och förseningar.

Målgruppen tycker det är lätt att hitta på stationen och är i regel nöjda med regelbundenheten av avgångar.


"State of the Art"-analyser

Våra analyser har varit på reseappar, sl.se, tiggeri, vad SL har gjort för att öka tillgängligheten på tunnelbanestationen och system för synskadade som åker kommunalt.

Genom analyserna har vi fått information om vad som gjorts i området tidigare och hur tillgängligheten är på några av dagens mest populära applikationer och hemsidor.

Applikationer kan se krångliga ut från början men inte vara så svåra när man fått vana i applikationen. Detta kan lösas t.ex. med en hjälpskärm när du använder appen för första början och genom att ha en applikation/hemsida som inte visar så mycket information på en gång.

Återkommande nackdelar i system är att det inte alltid är självklart hur de fungerar och att de är lätta endast om man har erfarenhet av att använda dem tidigare.

Slutsatser
Från intervjuerna ser vi att många inte har så stor koll på information om avgångar och att många är negativt inställda till att använda mobilapplikationer för att de anser att det verkar för krångligt. Problem vi kan angripa i vår design är ljudnivå på vagnar, tiggeri, applikationer som är lätta även för de helt utan erfarenhet och eventuellt något för att få målgruppen att känna sig säkrare med att resa på natten.