onsdag 22 mars 2017

Inför seminarium 2

Till detta seminarium har vi läst två kapitel. 

Kapitel 13

Detta kapitel handlar om evaluation, alltså utvärdering. Utvärdering har många syften och kan utföras i olika stadier av utvecklingsfasen.  

Ett vanligt syfte med utvärdering inom HCI är att undersöka hur väl produkten uppfyller konsumenternas krav och önskemål. Man vill därför utvärdera vissa viktiga aspekter av produkten, som exempelvis hur lätt eller kul den är att använda. Var man utför utvärderingen beror helt på vad som ska undersökas. Vanligen utförs den i  ”laboratorier” då man ofta vill kontrollera mycket av utvärderingen men det kan också utföras i så kallade ”wild setting” eller ”living laboratories” i syfte att fånga en mer naturlig användning av produkten. Utvärdering är viktigt under hela utvecklingsprocessen för att identifiera problem, för att sedan lösa de och sedan återigen utvärdera förändringarna. Detta är alltså en iterativ process.

Det finns tre huvudsakliga kategorier av utvärdering:
·      Controlled setting involving users
Tillåter att utvärderaren kontrollerar insamlingen av data. Detta genom experiment, observationer, intervjuer och enkäter som sker i kontrollerade miljöer så som i ”laboratorier”. Exempel på när denna typ av utvärdering är lämplig är när man vill undersöka ifall en produkt är tillräckligt väl anpassad och användbar för den avsedda användaren.

·      Natural setting involving users
Är relevant ifall syftet med utvärderingen är att fånga en naturlig användning av produkten. Detta utförs genom att minimera utvärderarens kontroll och hämta in data som sker så spontant som möjligt. Denna typ av utvärdering utförs ofta i så kallade ”wild settings”.

·      Any setting not involving users
Utförs genom att utvärderaren modellerar hur en produkt troligtvis kommer att användas.

Det finns för- och nackdelar med samtliga utvärderingsmetoder. Fördelen med kontrollerad utvärdering är att man får konkreta svar på frågeställningarna man har. Det är därför lättare att dra slutsatser kring datamängden man samlar in. En fördel med att ha en mer spontan utvärdering är att man har större chans att fånga hur produkten faktiskt kommer att användas. Man kan även identifiera problem som man tidigare aldrig tänkt på genom att ha en mer öppen approach. Alla dessa metoder kan med fördel kombineras.

I utvärderingsprocessen bör man tänka på hur vinklad, giltig och trovärdig utvärderingsdatan är.  

Kapitel 15

Kapitlet handlar om utvärdering genom inspektion utan närvarande av användaren, och fokuserar mest på så kallad heuristic evaluation. Heuristic evaluation utförs genom att insatta personer, experter, utvärderar en typ av produkt utifrån deras kunskap och erfarenheter. De har ofta kunskap om problem som ofta förekommer hos liknande produkter. En expert kan ofta komma med viktiga insikter som utvecklaren inte tänkt på.  

Analytics är en annan metod för utvärdering som handlar om att kartlägga användarens användning av produkten. Denna kartläggning sker ofta till en mycket stor utsträckning och genererar en stor datamängd, ofta utan användarens kännedom. Denna stora datamängd kan sedan analyseras för att ge en bra bild av hur produkten används.

Predictive models är en annan metod för utvärdering och bygger på att genom användning av formler kunna förutsäga hur produkten kommer att användas.

Det jag tar med mig från detta kapitel är hur iterativ utvecklingsprocessen är. Eftersom utvecklaren hela tiden identifierar nya problem och krav bör man gång på gång återkomma till tidigare arbete för att utvärdera och förbättra det för att till slut få fram en så bra produkt som möjligt. För att uppnå detta bör man utvärdera produkten med så många metoder som möjligt för att både få en kvantitativ, kvalitativ, kontrollerad och okontrollerad datamängd.

Att utvecklingen är iterativ har jag även märkt i praktiken då vi ofta inom gruppen har återgått till gamla diskussioner då vi kommit på en förbättring. Detta är något som jag förväntar mig att vi kommer fortsätta att göra.

Fråga till seminariet: Vilken utvärderingsmetod är mest relevant och rimlig för vår produkt? Min tanke är att en öppen utvärdering, det vill säga okontrollerad skulle vara mest intressant för vårt projekt då det är viktigt att få en bild av hur vår produkt, interaktiv skärm eller knappsats faktiskt skulle användas ifall den fanns i parken. Skulle människor kanske tröttna på den efter första knapptrycket? Efter att ha fått en uppfattning skulle man kunna utföra en kontrollerad utvärdering för att kunna testa sina hypoteser och konkret förstå varför produkten exempelvis är tråkig, genom mer djupgående intervjuer eller enkäter.

Kan man på något sätt inkludera utvärdering i själva produkten? Alltså försöka ”tvinga” användaren utvärdera produkten som en typ av kontrollerad utvärdering.

tisdag 21 mars 2017

Inf SEM 2 - Isak (kort)

Kapitel 13 - Introducing evaluation
Här bekantas vi med utvärdering och får inblick i framför allt varför, vad, var och när det är lämpligt att utvärdera - kopplat till interaktionsdesign.


  • Ett svar till varför kan vara: som medel att undersöka hur väl tjänsten/produkten möter kundens intresse/behov.
  • Svar till vad: gör systemet att användaren lyckas genomföra uppgiften snabbare eller säkrare.
  • Var: beroende på vad som utvärderas - ex. i det vilda: naturligt utövande/användande av produkten/tjänsten eller i “laboratorier”: förberedda/sammansatta platser.
  • När: Om projektet vill ta fram någonting helt nytt - förslagsvis mycket utvärdering i början för att hitta krav.


Det här tar jag med mig
En punkt som kapitlet vill markera är hur nära utvärdering och design går ihop och att utvärdering är en del som man regelbundet bör återkomma till allteftersom projektet utvecklas och går vidare.


Kapitel 15 - Evaluation: Inspections, analytics, and Models

Vikten är nu skiftad från direkt utvärdering och observation av användarens interaktion till förmån för att gå igenom utvärderingsmetoder som boken kopplar till ordet inspektion.


Tre metoder som tas upp är
  • heuristiska utvärderingsformer
  • analyser av externt insamlad data
  • modeller som förutspår användarbetéenden



Det här tar jag med mig
Modellerna talar för att det inte behövs många utvärderare för att ändå indentifiera många användarproblem/brister som systemet har.



12 nyckelprinciper
Många tycker jag är självklara som värdet av användaren i centrum, att tidigt involvera och ständig söka återkoppling från denne. Som boken även tar upp att projektet blir bättre genom att upprepa steg och gradvis förbättra systemet. Jag uppskattar betoningen att tidigt involvera och ta fram prototyper som användaren kan peta på och uttala sig om vad den gillar.


ISO 9241-11
Jag stannade till vid avsnittet 4 Grunder samt nytta där temat om användare i centrum - och respektera/ta hänsyn till och utforma systemet efter användningsområde - även här tas upp.


ISO 9241-210
Här tyckte jag rubrik 3 Rationale for adopting … och 4 Principles of human-centered design var mest intressanta då det var lätt att sammanlänka dessa med de andra läsavsnitten. Intressant här hur pengar direkt kan sparas/tjänas genom att ha en human-centered approach och att de sex principerna a) till f) alla återfinns i 12 nyckelprinciper.



Diskussionsfråga


Kan vi utforma vårt system utan att tvinga användaren att se på långa instruktionsvideor? alt. Hur utformar vi vårt system så tröskeln är så låg som möjligt och förståelse-/inlärningskurvan spikrakt går i taket?

Inf SEM 2 - Isak (lång)

Inför det andra seminariet läste gruppen kapitel 13 och kapitel 15 i kurslitteraturboken Interaction Design. Vi fick även en länk till ett dokument med 12 st nyckelprinciper inom användarcentrerad-systemdesign (en av föreläsarna var med och tog fram dessa) + två länkar till ISO-standarder inom ämnet. När detta skrivs har gruppen precis fattat beslut om vilket koncept vi vill vidareutveckla.

Kapitel 13, 14 och 15 har alla temat utvärdering - där respektive avsnitt tar upp och lägger vikt på olika områden.

Kapitel 13 - Introducing evaluation

Här bekantas vi med utvärdering och får inblick i framför allt varför, vad, var och när det är lämpligt att utvärdera - kopplat till interaktionsdesign.

  • Ett svar till varför kan vara: som medel att undersöka hur väl tjänsten/produkten möter kundens intresse/behov.
  • Svar till vad: gör systemet att användaren lyckas genomföra uppgiften snabbare eller säkrare.
  • Var: beroende på vad som utvärderas - ex. i det vilda: naturligt utövande/användande av produkten/tjänsten eller i “laboratorier”: förberedda/sammansatta platser.
  • När: Om projektet vill ta fram någonting helt nytt - förslagsvis mycket utvärdering i början för att hitta krav.

Det här tar jag med mig
En punkt som kapitlet vill markera är hur nära utvärdering och design går ihop och att utvärdering är en del som man regelbundet bör återkomma till allteftersom projektet utvecklas och går vidare. Projektets resultat blir i regel bättre ju fler iterationer som genomförs. I kursen produktion fick jag lära mig PDCA - Plan, Do, Check, Act, som är ett sätt att identifiera stommen i utvecklingsprocesser. (OBS PDCA - står inte för Please, Don’t, Change, Anything)


Kapitel 15 - Evaluation: Inspections, analytics, and Models

Vikten är nu skiftad från direkt utvärdering och observation av användarens interaktion med (...) till förmån för att gå igenom utvärderingsmetoder som boken kopplar till ordet inspektion.

Tre metoder som tas upp är
  • heuristiska utvärderingsformer (principer, tumregler, accepterade metoder)
  • analyser av externt insamlad data (utan kontakt med användare)
  • framarbetade modeller som förutspår användarbetéenden

Fitts’ lag - tiden det tar att nå ett objekt med pekaren (formel för hur interaktionstiden kan sänkas). Den här lagen verkar till synes vara ganska trivial och slutsatsen verkar vara: använd stora ikoner/länkar/…

Det här tar jag med mig
Modellerna som visas talar för att det inte behöver krävas jättemånga utvärderare för att indentifiera många användarproblem/brister som systemet har - MEN å andra sidan även att %-andelen identifierade (existerande) problem snabbt går upp med antalet extra utvärderare som bjuds in. ÄVEN att det är viktigt att granska resultatet genom att på ett ärligt sätt väga in olika aspekter (motivation, validitet, förkunskaper, …) innan man förlitar sig för mycket på resultaten - många identifierade problem kan enligt kapitlet vara falska alarm eller inte överhuvudtaget vara kopplade till utformning eller användarvänlighet.

12 nyckelprinciper
Jag skumläste genom dokumentet men gav ordentligt fokus på de tolv nyckelprinciperna. Många tycker jag är självklara men skall ändå så klart inte underskattas som värdet av användaren i centrum, att tidigt involvera och ständig söka återkoppling från denne. Som boken även tar upp att projektet blir mycket bättre genom att upprepa steg och gradvis förbättra systemet. Jag som gillar produktframtagning uppskattar främst betoningen att tidigt involvera och ta fram prototyper (av olika slag) för att enklare få en uppfattning om vad man håller på med (eller bör hålla på med) och som användaren kan peta på och bilda sig en uppfattning av vad den gillar.

ISO 9241-11
Samma här jag skumläste igenom och stannade till vid avsnittet 4 Grunder samt nytta där temat om användare i centrum - och respektera/ta hänsyn till och utforma systemet efter användningsområde - även här tas upp.

ISO 9241-210
Här tyckte jag rubrik 3 Rationale for adopting … och 4 Principles of human-centered design var mest intressanta då det var lätt att sammanlänka dessa med de andra läsavsnitten. Intressant här hur pengar direkt kan sparas/tjänas genom att ha en human-centered approach och att de sex principerna a) till f) alla återfinns i 12 nyckelprinciper.

Efter att ha läst och reflekterat över de här 5 olika texterna kommer det troligtvis vara omöjligt att inte ha i bakhuvudet att fokus vid utformning av ett interaktivt system så klart bör vara vad användaren av systemet vill/ska uppnå genom att bruka det och hur dennes upplevelse på olika sätt kan förbättras.

Diskussionsfråga


Kan vi utforma vårt system utan att tvinga användaren att se på långa instruktionsvideor? alt. Hur utformar vi vårt system så tröskeln är så låg som möjligt och förståelse-/inlärningskurvan spikrakt går i taket?

Reflektion av Kapitel 13 och 15, för seminarium 2.

Reflektion av Kapitel 13 och 15, för seminarium 2.

Kapitel 13


Målsättning att ta till sig efter att betraktat innehållet i detta kapitel är bland annat att:


  • Förstå nyckeltermer som används kring begreppet evaluering
  • Få en överblick över olika typer av evalueringsmetoder
  • Koppla hur olika evalueringsmetoder används för olika syften vid olika delar av designprocessen och i olika användarsamanhang.
  • Koppla hur evaluerare kan använda olika evalueringmetoder och anpassa dessa för att möta behovet av ett nytt system eller gränssnitt.
  • Reflektera över praktiska utmaningar som evaluerare måste förhålla sig till när evalueringen utförs.


Evaluering av en produkt innebär möjligheter att testa produkten för det den är avsedd för. Det är inte svårt att föreställa sig nyttan av att i ett tidigt skede av designprocessen låta sin produkt evalueras och därmed få nödvändig information om produktens relevans. En god respons på väl utförda evalueringar kan innebära att en investerare vågar satsa och användare får rätt behov tillgodosedda.

Det räcker inte med att göra några evalueringar i tidigt skede av designprocessen utan bör, i mån av resurser, utföras under hela den iterativa utvecklingsprocessen. Från low-fi prototyper till färdigt utvecklat system. Det är viktigt också att projektet står under god projektledning eftersom olika komptetenser troligen kommer att konsulteras när processen fortskrids.

Olika typer av evaluering angriper styrkor och svagheter hos produkten som ska evalueras på olika sätt. Det kan bland annat ske genom en kontrollerad uppställning där användaren är involverad som innebär att evaluerararen (användaren) får en begränsad uppsättning funktioner att förhålla sig till. Syftet med denna betod är att begränsa evalueringen till att testa en specifik komponent som utgör en del av produkten. Här kan data samlas in på ett effektivt sätt, och därmed ge ett statistiskt underlag för beslut. Denna typ av evaluering används oftare tidigt i designprocessen men kan förstås användas under hela designprocessen. En svaghet med denna evalueringsmetod är att den inte tar hänsyn till helheltsupplevelsen av slutprodukten, men det är samtidigt inte dess främsta syfte.

En annan evalueringsmetod är att involvera användaren på ett naturligt sätt genom att låta evaluera produkten, delar av produkten eller liknande produkter i en typisk miljö där användningen är tänkt att ske. Det ska ske på ett sätt som ger evalueraren frihet att själv evaluera produkten och själv dokumentera sin användning av den. Det är meningen att evalueraren kan göra detta under så naturliga omständigheter som möjligt utan att känna sig ledd av utvecklaren.

En tredje metod, och den sista jag ska ta upp här, handlar om att evaluera produkten utan att involvera någon användare. Det kan handla om analytiska tester som bygger på automatisk datainsamling, det kan också handla om att man sätter upp en trolig användarsituation och testar den mot någon parameter (exmeplvis tid). Här handlar det främst om att samla in data steg för steg och på så sätt försöka att täcka en hel användarcykel. Utöver att göra en användarcykel baserad på produkten kan delar av designen testas via exempelvis analysverktyg på internet och kan då handla om hur trafikflöden varierar för olika designlösingar.



Kapitel 15


Målsättning att ta till sig efter att betraktat innehållet i detta kapitel är bland annat att:


  • Ta till sig nyckelkoncept som berör inspektionsmetoder.
  • Förstå hur heuristisk evaluering utförs i praktiken.
  • Förstå analysens roll i evaluering.
  • Ta till sig hur Fitt's lag används som prediktiv modell

En översikt över vad en heuristisk evaluering kan innehålla enligt Jakob Nielsen:

Produktstatusens synlighet för användaren

Användaren ska vara medveten om vad som händer under användningen av produkten och under rimliga förhållanden.


Tydligt samband mellan användning av produkt och dess nytta i verkligheten

Det ska vara lätt att ta till sig hur produkten kan användas för att orientera sig mellan olika steg i produktens användning.

Användarkontroll

Det ska finnas möjlighet för användaren att lätt göra om något som användaren gjort fel genom att ta produkten från ett oönskat stadium.

Konstistens och standardisering

Det är viktigt att det finns en tydlighet i designen så att återkommande design betyder liknande funktionalitet. Användaren ska inte behöva fundera över hur design och funktion hör ihop i någon större utsträckning utan ska i största möjliga mån följa samma standard.

Idiotsäkerhet

Det är viktigt att användaren har en möjlighet att upptäcka fel innan de begås, eller att tvinga användaren att på något sätt bekräfta att en kritiskt ändring ska utföras.


Igenkänning istället för påminnelser

Reducera förekomsten av nödvändiga detaljer som användaren måste memorera, och implementera istället ett nätverk av objekt som gör att det blir tydligt för användaren vilka beslut som har föranlett ett aktuellt stadium i användingen.

Flexibilitet och effektivitet

Det ska finnas möjlihet för olika typer av användare att använda produkten baserat på hur erfaren användaren är.

Estetisk och minimalistisk design

Håll informationen kort, och relevant. Gör designen estetiskt tilltalande.

Hjälp användare att känna igen, diagnostisera och återställa produkten vid fel

I klartext bör användaren kunna, steg för steg, utföra en operation som återställer produkten till utgångsläget eller ett önskat läge.

Hjälp och dokumentation

Manual för användning, eller en lista på vilka funktioner som finns bör finnas tillgängligt på något sätt.

I korthet innebär en heuristisk evaluering att identifiera problem kopplat till användningen av gränssnittet som produkten utgör. Genom att kategorisera olika problem skulle dessa kunna mappas in i en bredare analys, och målet med en heuristisk evaluering är att kunna avgöra att förändring i design verkligen leder till en bättre produkt. Analysen skulle kunna bestå i att göra olika delar av designen användbar i en webapplikation och mäta hur trafikflödet är fördelat. Därmed kan en underbesökt del vara ett mått på att användaren inte upplever designen som tillräckligt meningsfull.

Sluligen var gäller prediktiva modeller ska det nämnas att en sådan är vad som kallas Fitt's Lag. Den säger att tiden det tar att nå ett måldon (knapp el dyl.) är proportionell mot avståndet mellan pekaren (finger, datormus el dyl.) och måldonet, och omvänt proportionell mot storleken (area) på måldonet. Det i sig känns intuitivt inte så konstigt, men eftersom den beskrivs exakt med en formel så går det att göra mätningar för att optimera designen och göra funktionaliteten mer lättåtkomlig.


Seminarie 2 - Poffe

Hej bloggen,

De angivna kapitlen handlar först och främst om att utvärdera projekt. Alltså hur bra uppfyller en produkt de behov användaren har på den. En hel del metoder för att utvärdera, både under och efter projektets gång, presenteras för läsaren. Alla dessa metoder kunde kategoriseras som metoder som kräver att en användare testar produkten och de som inte kräver det.

Den mer intuitiva kategorin, att fråga vad användaren tycker om produkten, kan i sig delas upp i underkategorier. Men även den kan på ett enkelt sätt kategoriseras i två grupper med en simpel fråga: testas produkten under en evaluators uppsyn? Dessa metoder är väldigt bra då det är svårt att förutsäga vad en användare ska göra och de kan använda produkten på sätt som inte riktigt är förväntat av dem. Om de testas under en evaluators uppsyn ökar chansen att man upptäcker något fel med produkten. Om de inte är direkt övervakade av en evaluator kan de ofta implementera något annat sätt att veta ungefär hur du använder produkten, exempelvis genom att spara vilka knappar du klickar på eller svara på frågor efter att de är färdiga. Det här är metoden som är vanligast att stöta på och det är inte sällan att man möts av frågan: "är det ok att vi samlar in information om hur du använder våran applikation när" man köper en ny dator eller att man ombeds lämna in feedback ringt supporten i stora företag.

Den andra kategorin handlar om testning utan användare. Då har man istället "utvärderare" som gissar hur användaren skulle bete sig med produkten och vilka problem som skulle kunna uppstå. Dessa är ofta förknippade med heuristiker som innebär att man hittar något som brukar fungera och implementerar det. Heuristiker finns även inom datalogin där de betyder samma sak, man löser svåra problem genom att gissa en rimlig lösning men som inte nödvändigtvis är optimal. Denna metod är ofta bra då man slipper involvera kunden men man missar ofta en del då den som utvärderar produkten kan ha det svårt att tänka sig in i hur en kund skulle uppfatta produkten när man själv jobbat med den ett tag.

Det som slog mig som mest spännande, förmodligen för att det är det enda jag stött på i vardagslivet, var hur man kunde implementera insamling av information i våran produkt? Ska man ens spara något då vi rör oss i gränslandet till politik?

tl;dr jag förstod varför man vill ha feedback från kunden 👌

måndag 20 mars 2017

Läseseminarium 2 - sammanfattning

I kurslitteraturen till detta seminarium beskrevs hur utvärdering under och efter en designprocess kan gå till. Innan en väljer metod för utvärdering är det viktigt att fråga sig och förstå varför, vad, vart och när det ska utvärderas. Om dessa frågor är ordentligt besvarade har grunden för en bra utvärdering lagts.

I boken delas de olika sätten att utvärdera användarvänlighet in i 3 huvudsakliga kategorier. Den första är controlled settings involving users där användarens beteenden insamlas genom till exempel att filma användaren eller att logga hur de använder ett program och vad de klickar på. Ett annat sätt ät natural settings involving users där användarens beteenden istället studeras i den naturliga användarmiljön. Fokus blir då att hitta aspekter av användarvänligheten som kanske missas när utvärderingen sker i en mer kontrollerad miljö. Slutligen kan också utvärderingen ske genom any settings not involving users. Detta är en väldigt resurssnål metod som ofta går ut på att gissa och anta hur användare skulle använda en produkt. Ofta är det fördelaktigt att använda flera olika utvärderingsmetoder i olika steg i designprocessen. 

Särskilt intressant i litteraturen tyckte jag att kapitel 15 var som beskrev tydligare hur en kan arbeta för att förutse eventuella problem för användare utan att behöva använda tid och resurser att testa programmet på användarna själva. En studie visade att genom att 3-5 erfarna utvärderare kan ca 75% av problemen upptäckas. Det verkar vara en bra arbetsmetod i ett tidigt skede i en process som senare kan kompletteras med användartester för att också kunna hitta mer oväntade problem.


Diskussionsfråga till gruppen: Vilka utvärderingsmetoder tyckte ni verkade mest spännande till vårt projekt?