torsdag 28 april 2016

Skisser till prototypen

Under dagen har vi träffats och diskuterat ändringar som ska göras utifrån evalueringen som gjordes av den andra gruppen. Vi ritade skisser av hur det kommer se ut i prototypen.

Resan väljs genom att dra på en spårkarta

Tiden ställs in 

Resan visas

Pilen som visar hur man ska gå

torsdag 14 april 2016

Evaluering från annan grupp

Under dagens övning fick vår design en evaluering från en annan grupp.

Gruppen var generellt positivt inställda till designen men hade ett par frågor och mycket bra konstruktiv kritik.

De tyckte vår design var tydligt inriktad på målgruppen endast om man i förväg visste vad det var för målgrupp vi hade. Dock tyckte de inte det framgick tydligt vad målgruppen var endast genom att se designen eftersom den skulle kunna tilltala flera olika grupper.

Svårighetsgraden tyckte de kändes enkel och passande för målgruppen men de ställde sig frågande till om målgruppen verkligen skulle vara positivt inställda till att skaffa Google Glass. Detta är eventuellt något som målgruppen skulle kunna bli mer positivt inställda till längre in i framtiden. Samtidigt trodde gruppen att designen skulle kunna göra livet enklare för målgruppen och att många nog skulle vilja fortsätta använda produkten så länge den fungerar som den ska utan problem.


Flödet kunde de inte kommentera så mycket på ännu eftersom vi inte har så många skisser. De ville gärna se mer konceptbilder på hur interfacet ser ut i olika situationer t.ex. inne på en tågvagn.

Många av funktionerna bedömdes som något som de flesta skulle behöva få förklarat för sig. Att dra resmål på karta bedömdes som en enkel funktion men funktionaliteten måste förmedlas till målgruppens nybörjare till produkten.


Designen bedömdes som förväntat lite inkonsekvent eftersom vi inte är helt klara med den. Gruppen gillade konceptet och var positivt inställda t.ex. till färgerna som visar hur fulla vagnarna är och varningen för hög ljudvolym. Dock tyckte det att designelementen kändes hastigt ihopplockade och i behov av en större gemensam design. Layouten bedömdes naturlig och lätt att överskåda i synfältet. De gav oss goda tankeställare angående färgerna i designen. Hur skarpa färger bör vi ha för att tilltala målgruppen?

Ett viktigt påpekande gruppen gjorde var att Google Glass i dagsläget endast projicerar bild i hörnet av synfältet vilket gör att vårt interface inte stämmer överens med dagens teknik. Vi behöver alltså istället glasögon liknande Microsoft Hololense som projicerar på hela synfältet.

Gruppen påpekade också att interfacet fungerar bra när det är tomt på plattformen men att pilar och färger på marken kan bli svåra att implementera när det är mycket folk. Detta är något vi kommer behöva tänka mer på.

Slutligen tyckte gruppen vi bör ha någon slags hjälpskärm för nya användare.

tisdag 12 april 2016

Slutgiltig design

För vår slutgiltiga design kombinerade vi våra favoritidéer från de tidigare designerna och den kollaborativa iterationen. Genom att kombinera de bästa komponenterna från varje design skapade vi en idé med basen i Design 2:

- Från Design 1 togs planerna om en interaktiv skärm och kombinerades med Design 2. Google Glass-glasögonen ska kunna läsa av handrörelser via kamera vid en spårkarta t.ex. Detta för att användaren ska, endast med glasögonen, kunna planera sin resa genom att t.ex. dra och peka med hand/finger/käpp ( interagera )  mellan stationer. Även tid för avgång ska kunna hanteras på liknande sätt, t.ex. genom att peka på en klocka.

En central del i att välja tid och resväg via en spårkarta är att det ska vara okej att göra fel och lätt att rätta till eventuella fel. På grund av detta ska man inte behöva gå igenom någon krånglig process för att göra om ett misstag. Väljer användaren fel sträcka eller fel tid är det bara att göra om valet genom att dra igen. Genom att välja tiden minuter och timmar separat är det lätt att göra om om användaren väljer fel minut utan att behöva ändra timmen.

- Från Design 3 togs idén om att med lysen på perrongen visa vilka vagnar som är fulla och var sittplats finns. Dessa lysen visas, istället för med fysiska lampor på perrongen, genom glasögonen. Detta ger ekonomiska fördelar och möjlighet för individuell anpassning. I glasögon kan även varningar om högljudda vagnar, smuts.

Bilden visar skiss över hur användare interagerar med existerande spårkarta på perrong, med glasögonen som hjälpmedel. Glasögonen avläser rörelser och skapar reseplanerare.
- Från Design 2 är idén om pilar som visar vägen till målet. Från denna design slopades planera om att kontrollera glasögonen via en applikation, då detta inte behövs och samtidigt inte passar målgruppen. Detta mönster uppstod efter kvalitativ analys av intervjuer.
Detta är en konceptbild för interfacet till den slutgiltiga designen. På bilden visas synfältet från en användare av glasögonen. Användaren ser bland annat en högljudd vagnsektion, kantlysen som indikerar tillgängligheten av sittplats, vägvisare på marken.
På bilden ser vi även en eventuell markering på användarens kompis/kollega/övrigt Inga Britt. På detta sätt kan användaren hitta t.ex. vänner, kontrollanter eller vart man kan köpa biljett. Under designprocessen är det viktigt att överväga hur mycket information som är lagom mycket. För lite ger förvirring medan för mycket gör synfältet överfullt vilket döljer viktig info. Detta kan undersökas med evaluering.

Design 3 - Lysen på perrongen

Tredje designen har som mål att åtgärda de problem målgruppen har med att hitta sittplats och bli störda av många människor som gör vagnarna stökiga. Tanken är att det finns sensorer på varje vagn som mäter hur många människor som går av och på och sen sensorer i vagnen som mäter var folk befinner sig. När tåget lämnar en station skickar den information om antalet resenärer vidare till systemet på nästa station som då lyser upp perrongen med färger som visar hur full respektive vagn är, vill man t.ex. sitta i en tom vagn rör man sig mot det grönaste området på perrongen.

Sketch på upplyst perrong
För att göra det så lättförstådd som möjligt använder vi av oss grönt, gult och rött, där grönt representerar en i princip tom vagn, gul en lite fullare och rött i princip helt fullt.

Nackdelar med designen är att sensorerna kan ha svårt att känna av individuella människor när stora folkmassor går på/av vilket skulle ge vilseledande information till nästa station.

Designen hjälper vår målgrupp genom funktionella behov

Design 2 - Google Glass Glasögon

Den andra designen som vi kom fram till efter den kollaborativa iterationen var idén om Google Glass. Vi resonerade att många äldre och pensionärer ( vår målgrupp ) har glasögon och ogillar i regel mobilskärmar och appar. Med detta i baktanke föddes idén att använda Google Glass för att hjälpa äldre med sina resor, t.ex. visa vägen.

Google glass är ett slags glasögon som projicerar bilder på glasögon och kombinerar därmed en datorskärm med användarens synfält. Resenären
väljer resa via en skärm på perrongen, eller applikation. Google glass visar sedan med hjälp av pilar på vägen för resenären och t.ex. tid kvar och tid till avgång. 

Tekniken som används är bland annat GPS och gyro. 

Nackdelar skulle kunna vara kostnad, internettillgång och applikation för att ställa in resväg.

Design 1 - Interaktiv Skärm

Vår första design är en interaktiv skärm som är tänkt att vara placerad på perronger och utanför spärrarna. Från början tänkte vi att man skulle kunna använda den antingen genom touch eller röststyrning. Dock så kom vi på att röststyrning skulle bli problematiskt då det är högljutt på perrongen på grund av folk och förbipasserande tåg. Det ska däremot finnas en inbyggd högtalare som kan läsa upp alla alternativ för dem med dålig syn. Inbyggt i skärmen ska det också finnas en SL-korts skannare som man kan använda för att enkelt se information om sin reskassa eller periodsbiljett.

Det vi har behövt tänka på mest när det gäller själva skärmen är hur stor den ska vara och hur högt ovanför marken den ska vara placerad. Det är viktigt att pensionärer, tonåringar, med mera skall kunna använda den och nå alla alternativ utan att behöva sträcka sig eller böja sig. I början tänkte vi oss en enorm skärm som stod rakt upp, men på grund av kraven valde vi om till en lite mindre skärm som är lutad bakåt en aning.

Själva appen som ska köras på skärmen har vi designat så att den förklarar allt man behöver göra väl, utan att någonsin förvirra användaren. Den har därför få alternativ vid varje varje som man gör. Alternativen är också placerade innanför stora knappar som i princip täcker hela skärmen. Man kan när som helst se vad klockan är och vart man befinner sig i reseplanerarprocessen. Vid samma ställe ska det också finnas en flagga som visar det nuvarande språket, om man trycker på den kan man byta till andra språk. Detta har inte helt något som har just med vår målgrupp att göra, men det är en funktion vi tyckte skulle finnas.

Då det var en snabb prototyp så var det många funktioner som inte kom med, men vi kom direkt också på nya idéer. Det viktigaste vi kom på är att man lätt borde kunna gå tillbaka till gamla steg, till exempel byta avgångstid. Alla ens tidigare val bör också alltid synas vid ett hörn av skärmen så att man får en bättre överblick.

Prototypen finns inbäddad nedan. (Obs: 404 skärmen är en placeholder för resultatskärmen av ens sökning)

måndag 11 april 2016

Seminarium 2 Sammanfattning

Mycket av det som står i boken är uppenbart men den ger en bra lista på vad man bör tänka på eftersom det finns en del saker att komma ihåg.

Utvärdering utan inblandning av användare kan vara bra men lite osäkert (heuristics).

Vi är inriktade på ett google glasses interface för pensionärer (de har ju ofta glasögon), den andra gruppen en interaktiv skärm för turister.

Svårt att utföra evaluering eftersom vi inte har en faktisk app eller liknande. Vi har inga experter, och det är inte lätt med field studies eller liknande.

Vi diskuterade triangulation, vilken sorts evaluering vi ska använda och hur vi ska hålla den opartisk. Vi tror att evaluering med användare kan bli svårt eftersom vi inte utvecklar ett färdigt system utan endast en design. Dock skulle vi kunna framställa koncept-prototyper och se vad målgruppen tycker om dem.

Seminarium 2 - Isak Peterson

Evaluering gör man för att kolla så att designen fungerar bra, vad som kan förbättras och om den över huvud taget passar målgruppen. Det är lätt att tappa målgruppen på vägen när man designar en produkt, för att i slutändan ha en design som inte kommer användas. Därför använder man sig av evaluering. Evaluering kan vara formativ eller summativ. Formativ evaluering sker under själva designprocessen, medan summativ evaluering sker när designen är klar.

Evalueringen kan se ut på olika sätt. Den kan ske både med och utan användare i antingen kontrollerad eller naturlig miljö. Med användare kan man använda sig av exempelvis fältstudier där man helt enkelt testar hur användaren hanterar produkten. Detta kan göras antingen där produkten är menad att användas eller i kontrollerad miljö, till exempel i ett labb.

Ett annat sätt att evaluera är genom så kallad heuristisk evaluering. I detta alternativ undersöker kunniga i ämnet designen för att se om den uppfyller de riktlinjer föregående designer fastställt som fungerande. På detta sätt kan en design som är intuitiv för användaren skapas, då den känner igen funktioner i designen från föregångare.

Hela evalueringsprocessen är till för att se om produkten är användbar i verkligheten, så det är viktigt att designteamet verkligen analyserar och tar till sig av processens resultat. Då är det värt att tänka på exempelvis partiskhet, huruvida evalueringen verkligen undersökt designens hållbarhet och att evalueringen är trovärdig.


Diskussionsfråga: Kan vi använda oss av heuristisk evaluering? Hur gör vi det i google glasses designen om det inte finns någon etablerad föregångare?

Seminarium 2, Lars Pettersson

Evaluering verkar vara en väldigt central del av mdi:n som omfattar nästan allting. Anledning till att man utvärderar sin lösning är för att man ska se till att fokusgruppens behov täcks, att användarvänligheten och belåtenheten är hög och så vidare. Med andra ord testar man för att se vad som behöver förbättras, och det ska helst ske inom en iterativ designprocess. Då evaluering är så vital är frågan alltså inte om, utan istället när, vad och hur man ska utvärdera.

Man kan gruppera in utvärderingar i två grupper, formativ evaluering och summativ evaluering. En utvärdering är formativ om den görs under skapandet av ens lösning och är alltså vad som "formar" produkten. Den summativa varianten utförs alltså när ens produkt är ute på marknaden och är till för att underhålla den. Enligt mig är såklart båda sorts utvärderingar viktiga, men den formativa är nog viktigast. Då den formativa evalueringen utförs innan alla delar av produkten är klara så blir utvecklingskostnaden mindre. Om man väntar tills produkten är helt utvecklad innan man evaluerar så slösar man inte bara pengar om man märker att man måste ändra på saker, utan också tid.

Evalueringen kan se väldigt olika ut beroende på hur man väljer att göra den på.  Evaluering där användare utvärderar kan ge kvalitativa resultat med hög validitet. Å andra sidan kan det ta lång tid, kosta mycket och införa integritetsfrågor. En annan metod som inte inblandar riktiga användare är prediktiva evalueringar. Det är när experter inom ämnet sätter sig in i rollen av användaren och förutser potentiella problem och brister med designen. Man använder sig då normalt av heuristik, som helt enkelt är förutbestämda riktlinjer som underlättar evalueringen. 

Hela meningen med evaluering är alltså för att man som utvecklare inte möjligt kan se alla möjliga brister i ens lösning. Därför ifrågasätter jag heuristik metoden lite då jag inte finner den mycket annorlunda. Blir resultaten nödvändigtvis bättre för att en "expert" utför evalueringen? Vad kännetecknar ens en expert? Utvecklarna av en produkt borde ju själva ha ganska mycket erfarenhet. 

Min fråga blir därför, hur kan vi bäst garantera hög reliabilitet och validitet med vår evaluering, med tanke på att vi troligen inte kommer att ha mycket tid på oss?

söndag 10 april 2016

Seminarium 2 - Lucia Edwards

Kapitlen till seminarium 2 berör evaluering och hur en projektgrupp ska gå tillväga efter de har gjort datainsamlingar, designat en produkt och skapat en prototyp. Evaluering är en väldigt viktig del av projektet då det är lätt att en grupp gör en datainsamling, analyserar datan och kommer fram till en produkt som de tycker löser ett givet problem och sen skapar produkten. Risken finns då att datan har analyserats fel och produkten inte alls är användbar för den valda målgruppen.

Hur en evaluering ska göras beror på produkten och vilken typ av information man vill samla in om sin produkt. Gruppen måste bestämma vad som ska evalueras, när det ska ska göras och var det ska utföras. Det finns även finansiella aspekter som påverkar vilken typ av evaluering som kan göras. 

Formativa och summativa evalueringar diskuteras, vilket jag tyckte var intressant då min fråga till seminarie 1 berörde huruvida man ska fortsätta interagera med målgruppen under designprocessen för att vara säker på att man fortfarande är på rätt väg dvs göra en formativ evaluering. Då vi har en viss begränsning vad gäller tid i kursen är det inte realistiskt att följa upp varje designsteg med målgruppen men i ett "riktigt" projekt tror jag att det kan vara väldigt givande.

Tre typer av evaluering tas upp, controlled och natural settings involving users och any settings not involving users. Det finns för- och nackdelar med alla typer och det viktiga är att man vet vilka typer av fel man vill upptäcka när man väljer vilken metod man vill använda. De första två handlar om att låta en från den tänkta målgruppen använda produkten antingen i en kontrollerad miljö exempelvis laboratorium eller "in the wild" dvs där användaren rör sig naturligt. Metoder som inte inkluderar användaren är exempelvis heuristisk evaluering och walkthroughs. I heuristisk evaluering "jämför" man sin produkt med en uppsättning principer, heuristics. Vad gäller walkthroughs kan man göra antingen en kognitiv eller en pluralistisk walkthrough. I det tidigare fallet samlar man designern och experter och man går igenom en problemlösningsprocess där man försöker simulera hur den tänkta användaren skulle gå tillväga i varje steg medan i det senare fallet samlar man användare, utvecklare och experter som tillsammans arbetar sig genom givna scenarier och diskuterar hur man går tillväga när man använder produkten i det givna scenariot. I vårt fall skulle det nog vara svårt att utföra evalueringar med användare men en kognitiv walkthrough skulle nog gå att genomföra. Vi har våra personas baserade på våra fieldstudies och utifrån dem skulle vi kunna sätta oss in i hur användaren skulle gå tillväga för att använda vår produkt. Självklart skulle vi inte upptäcka alla fel men en första evaluering av prototypen skulle hjälpa oss att förstå vilka typer av fel som kan uppstå i en liknande designprocess.

Inför seminarium 2, Martin Wass

Evaluering
Evaluering är extremt viktigt i en designprocess för att se om den designade produkten är tilltalande för målgruppen och vad som kan förbättras. Evaluering är viktigt eftersom designers ofta anser att deras design är perfekt eftersom de själva tycker designen fungerar bra. Genom evaluering testas om detta verkligen stämmer.

Evaluering kan ske tidigt för att framställa skisser/prototyper eller senare för att testa färdiga system. Evaluering under designprocessen kallas formativ evaluering medan slutgiltig evaluering kallas summativ evaluering. Evaluering kan vara mer eller mindre strukturerad och kan vara både tester med eller utan användare. Olika evalueringstekniker såsom fältstudier, användbarhetstest, experiment, modeller och analyser har olika för och nackdelar. Precis som i intervjuerna är etiken viktig i evaluering. Se till att den som evalueras har sina rättigheter klara för sig. I slutet av evalueringen ifrågasätts och analyseras pålitlighet, korrekthet (har du evaluerat det du skulle), yttre påverkningar och eventuell partiskhet.

Evaluering: Inspektion, analys och modeller
Heruristisk evaluering innebär att experter undersöker om delar av en design uppfyller de krav och riktningslinjer som bevisat sig fungera i tidigare designer. Exempel på dessa är att använda redan kända namn på funktioner och att göra så användaren kan se alternativ lätt utan att behöva leta efter dem. Dessa riktlinjer kan sedan appliceras på scenarier. Med fler personer som utför evalueringen ökar kvaliteten samtidigt som priset ökar. Heuristisk evaluering har tre stadier:

1. Den inledande stadien när experter får veta vad de ska göra.
2. Evalueringsperioden där experterna inspekterar designen/produkten med Heuristiska riktlinjer.
3. Diskussion där alla experter diskuterar problem och försöker hitta lösningar.

Ännu en evalueringsteknik är så kallade walkthroughs. I en walkthrough undersöks hur en viss uppgift utförs för en given design. Problem noteras och försöker lösas i slutändan. Walkthroughs kan ske utan användare (kognitiv) eller med användare (pluralistisk). Walkthroughs verkar enligt mig vara väldigt bra för evaluering. T.ex. fick vi på föreläsningen med Jan se hur problem lätt blev uppenbara när två elever fick boka en tennistid online. (Något som visade sig vara mycket svårare än man kan tro)

Kapitlet avslutades med information om evalueringstekniken analys av data t.ex. från Google analytics samt en presentation av Fitts ekvation för att räkna ut hur lång tid det tar att t.ex. klicka sig fram på en hemsida.

Min diskussionsfråga är "Hur kan man se till att få triangulering på evalueringen?".

Seminarie 2, Ludvig

Evaluation verkar vara en ganska komplex men ändå väldigt viktig del av en design-process.  Man måste veta varför man utvärdera, vad man ska utvärdera, samt vart och när man ska utvärdera.

Det finns också ett "hur ska jag utvärdera?".  De tre olika sorternas utvärdering är: utvärdering i kontrollerad miljö med användare, utvärdering i naturlig miljö med användare, vilken miljö som helst utan användare. De två metoderna med användare inkluderar bl.a. Usability tests och  Field Studies, i den utan använder man sig t.ex. av Heuristics.

Heuristic Evaluation är när experter med hjälp av Heuristics, d.v.s. användbarhets riktlinjer, utvärderar ett programs UI. Jag tycker visserligen detta är intressant, men som kan ses på min diskussionsfråga ifrågasätter jag huruvida detta ger ordentliga resultat.

Utvärderingen fungerar som feedback på designen och utan den har man ingen aning om vad de framtida användarna kan tänkas tycka om produkten. Men med hjälp av feedbacken man får vid utvärderingen kan man rätta till fel och brister i sin produkt, för att bättre möta användarens förväntningar. Det är dock viktigt att tänka på saker som Reliability och Validity. 

Reliability innebär hur konsekventa dina resultat skulle bli om du utförde samma tester vid olika tillfällen men under samma omständigheter. Detta är ju mycket viktigt eftersom man inte vill att när man ändrar sin produkt efter feedback man fått visar det sig att det endast var otur att någon hade problem med en viss del av din produkt, och att du ändrat den helt i onödan/försämrat produkten. 

Validity handlar om huruvida din utvärderingsmetod undersöker de saker den är avsedd att undersöka. Om du designar en app för användning på förskola vill du till exempel inte ha feedback från vuxna (utom möjligtvis lärare). Eftersom det är små barn som ska använda appen leder det antagligen inte till så användbara förbättringar om du låter någon äldre testa den, då det inte är de som ska använda appen som ger feedback.

En sak jag tänkte på är den sortens utvärdering när användare inte involveras. Då använder sig t.ex. forskare  av olika metoder för att bedöma en produkt. Men jag tänker att precis som med när man utgår från sina egna preferenser som utvecklare, kan inte heller forskare veta vad användarna vill ha eller vad de föredrar. De kanske istället kommer fram till en design som passar dem själva. Så hur effektivt kan det vara att låta någon som inte representerar användarna utvärdera produkten?

Seminar 2 - Jacob Sörme


Evaluation is an important part of the design process. To evaluate means that one collect data and information about users and user experience. This is made to improve the design. As the creator of a product everything might seem easy and obvious. However, this is seldom the case for the majority of the users. It is important to get the outside view of the product and not see everything from your own creator view. To evaluate means that one observe users and how they react to using the product. There are other methods of evaluation that does not take users in account, instead taking for example collected data in account. The level of control can differ, from controlled experiments in laboratories to uncontrolled in field studies.

Controlled experiments in laboratories enables evaluators to control the environment and social influences. This method is good for collecting data, for example to measure the time it takes for users to complete a task or the number of times a situation occurs.

Field studies are evaluation studies with little or no control of the study. This method shows how users use the product in their every-day lives, in contrast to controlled experiments that show how users perform in special laboratories or environments. This method is more messy, and it is often hard to tell what causes what. On the other hand this opens for the qualitative analysis of behaviour and feelings.

Controlled experiments and field studies can be combined. One can for example set up a sort of lab out in the field. An example of this is collecting data from a skier that has different modules of measuring fastened to the gear, while the skier is skiing. This is called in the wild study.

lördag 9 april 2016

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. 

http://www.oxha.org/cih_manual/images/evaluation.png
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.

tisdag 5 april 2016

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 



Pain Points

1: mycket viktigt ---- 5: inte viktigt
Problem
Ulla-Britt
Stig “Ica” Göransson
Svårlärda applikationer
1
2
Mycket folk på vagnarna
2
4
Stökiga ungdomar
1
1
Komma i tid
1
3
Trafikinformation
3
                  3
Ändrade tidtabeller
2
                  1
Reskassa - ser inte hur mycket man har kvar
2
3
Reskassa - välja biljettyp
3
2