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?

SOTA-analys Ludvig

Jag har valt att analysera appen ”Res i Stockholm”, som är en reseplanerare för Stockholms lokaltrafik.

I appen skriver man in mellan vilka stationer man vill åka (nuvarande plats går också att välja).  Man specificerar även när man vill åka eller senast vara framme, och appen svarar med en lista på olika resvägar man kan ta. Den berättar vilken buss/tåg/etc som går från vilken hållplats/station vilken tid. Vilka hållplatser/stationer den passerar på vägen och visar även en kartbild som där alla dessa samt din egen position finns utsatta. Appen ger dig alltså en överblick över de alternativ du har för din resa.

Mig själv inkluderad finns det ingen jag känner som reser i Stockholm som har uttalat att de inte har appen. Jag har alltså inte frågat alla men varje gång den kommer på tal känner folk till den och kan relatera till användningen. Vidare verkar även de intervjuade vara bekanta med appen. Jag drar därför slutsatsen att de flesta som reser med Stockholms lokaltrafik använder sig av den.

Detta verkar också vara tanken med appen. Den fungerar för alla de olika typerna av lokaltrafik som t.ex. tunnelbana, pendeltåg och färja. Om du reser i Stockholm ska du ha användning av appen för att planera dina resor. 

Appen fungerar i allmänhet väl. Den är mycket sällan ur funktion, och informationen stämmer överens med verkligheten. Anledningen till att den behövs är att vi åker på så många olika ställen i Stockholm, på olika tider på dygnet, helger och vardagar. Därför är det omöjligt att hålla alla tider i huvudet. En av de intervjuade personerna nämnde att fast hon levt länge i Stockholm och för det mesta lärt sig tiderna efter många år måste använde sig av liknande denna app (ingen specifik app nämndes) när det blir ändringar i tidtabellerna. Visserligen är Slussen-T-Centralen inte en särskilt svår sträcka att resa emellan då det finns många linjer som går däremellan men när det behövs (till exempel på kvällarna då färre tåg går) ser appen till att det inte finns några oklarheter gällande när tågen går eller liknande.

Ett problem som finns är att appen inte tar vissa resvägar i beaktande. Om du till exempel vill till Tekniska högskolan från karlaplan föreslår den att du går en bra bit och tar en buss. Istället för att åka mot slussen längs den ena röda linjen för att sedan byta till den andra röda linjen  vid Östermalmstorg till högskolan, trots att tunnelbanan skulle gå snabbare finns den i det fallet inte ens med som alternativ. Möjligen för att det inte krävs något byte om man tar bussen, möjligen för att du först måste färdas åt ”fel” håll om du vill väljer tunnelbanan. Hur som helst väljer reseplaneraren inte en optimal väg, men ger ändå en fungerande resväg. Detta är inte ett vanligt förekommande problem bland de jag känner personligen, och ingen av de intervjuade har nämnt liknande problem. För den relevanta sträckan finns det heller ingen väsentlig misstanke om att liknande problem skulle kunna uppstå, då det går flera linjer direkt mellan Slussen och T-Centralen.

Slutsatsen jag drar av denna analys är att det inte finns några betydliga problem gällande state-of-the-art reseplanering. Den teknik som finns är inte helt felfri men fungerar väl och i de flesta situationer, där den relevanta situationen för våran undersökning är en av dem. 

Intervju Ludvig

En intervju med en dam vid stationen i Gamla Stan

Är du Stockholmsbo?

   Mm, ja.

--Hur ofta åker du tunnelbana?

   Varje dag.

--Vid vilka tider?

   På morgonen vid sju ungefär och på eftermiddagen den här tiden vid ungefär halv tre.

--Hur kommer det sig att du åker tunnelbana och inte buss eller annat färdmedel?

    Jag åker buss och tunnelbana.

--Då du väljer tunnelbanan, känner du någon särskild fördel?

    Ja, för det mesta så går det snabbare med tunnelbanan, och känns säkrare.

--Hur tycker du att det fungerar med biljett?

    Jag har en sån här månadsbiljett, alltså 30 dagars biljett.

--Och det tycker du fungerar bra?

    Ja det tycker jag.

--Hur tycker du att det fungerar med att ta reda på hur du tar dig någonstans?

    Nu så har jag bott i Stockholm i hela mitt liv så att jag har rätt bra koll.

--Men om du ska till ett ställe du inte har varit på, vad gör du då?

    Då får jag väl kolla på mobilen och se om det är någon information där.

--Hur tycker du att det fungerar på själva tunnelbanan?

Det fungerar bra.

--Det är inte svårt att få plats?

     Nej, för jag åker ju inte i de stora strömmarna utan jag åker åt motsatt håll, så jag får alltid sittplats. I alla fall för det mesta. Det är inga problem.

--Finns det några andra problem som du upplever i allmänhet med tunnelbaneåkandet?

     Nä det tycker jag nog inte, att det är några direkta problem. Det enda är ju i Slussen nu för jag kommer ju med bussarna där, att det börjar bli lite stökigt nu på grund av ombyggnationen. Men det är väl sånt man får ta.

Inför seminarium 1 Ludvig

En av de saker som intresserar mig mest är triangulation. Själva konceptet finns till för att få en mer klar bild av det som undersöks, vilket jag tror är viktigt. Tänk dig att du ser på bilder från en vanlig övervakningskamera som sitter i ett rum. Det ger en bild av rummet, men om du samtidigt har en till övervakningskamera på andra sidan rummet riktad mot den första kan du få en mycket klarare bild av rummet, du kan se vad som pågår under/bakom den första kameran och möjligtvis utrymmen som är skymda av diverse objekt utifrån den första kamerans vinkel. Detta är ett mycket simpelt exempel, men jag tycker att det visar väldigt bra på vikten av triangulation, om du inte  hade den andra kameran kan du trots filmning 24/7 missa händelser som sker i rummet. På samma sätt kan du utan ordentlig triangulation missa viktiga aspekter av ett område du studerar. Triangulationen är ingen garanti (tänk ett mindre rum inuti rummet, väggarna skulle hindra insyn fastän kamerorna har olika synvinklar) men fler perspektiv ger ändå en klarare bild. Det är även intressant att triangulation kan ske på olika sätt, bland annat genom olika undersökningsmetoder som intervjuer och frågeformulär, eller analysera data utifrån olika teorier.

I övrigt tyckte jag även att hela kapitel 10 var mycket intressant då det handlade om kontakt med kunder och metoder för att använda data för att anpassa sitt program efter omständigheterna, bland annat med hjälp av uttrycken Task description och Task analysis. Task analysis som innebär att man ser till hur personer löser problem/använder program och därefter uttrycka hur designen för ens program bör se ut. Task description som handlar mycket om interaktionen med någon som beställt en produkt av dig. Ännu intressantare finner jag Non-functional requirements, som betyder allmänna aspekter av programmet som hur lätt det är att utöka det (maintainabillity) eftersom vi har hållit på med sådant mycket inom INDAn. I allmänhet har dessa saker även gemensamt att de väldigt direkt handlar om viktiga aspekter av arbetslivet, vilket så vitt jag förstått också är varför vi läser kursen. Kapitel 10 kändes därför högst relevant. Däremot är jag högst osäker på om (och vill därför diskutera) hur meriterande kunskap om att utforma och utföra undersökningar är som t.ex. mjukvaru utvecklare. Det känns definitivt som bra kunskaper att ha, men vilken vikt har dessa kunskaper?

Kapitel 7, 8, 10 Ludvig

Data recording

Är insamlandet av data. Det finns många olika sätt att göra detta på, bland annat frågeformulär och intervjuer. Den andra viktiga aspekten av detta är på vilket sätt man sparar denna data, som t.ex. anteckningar eller genom att spela in en intervju. 

Interviews

Intervjuer är en av de vanligaste formerna av data insamlande. Består traditionellt av en längre session (upp till över en timme) där en person svarar på frågor som en annan ställer. Det finns olika sorters intervjuer där det som skiljer mestadels är frågornas natur, men det finns också t.ex. gruppintervjuer där flera personer intervjuas samtidigt. Vanliga sätt att samla data vid intervjuer är att anteckna eller att göra en ljudinspelning.

Questionnaires

Frågeformulär är också ett vanligt sätt att samla in data på. Frågeformulär har fördelen att de kan nå ut till många människor lätt. Det är visserligen många som inte svarar på utskickade frågeformulär, men det brukar ändå gå att få ordentliga data från formulär. Det finns både pappers-formulär och digitala formulär. En fördel med digitala formulär är att data-insamlingen är lätt att framställa automatiskt. 

Observation

Observation kan till exempel innebära att man som observatör följer med en person på en dag på jobbet. Viktiga saker att tänka på vid observation är att inte påverka den som observeras, samt att man på ett effektivt sätt kan observera och samla in data samtidigt. Därför föredras inspelning över anteckningar, men det fungerar ändå att anteckna. Det finns olika sorters observationer, både sådana i den observerades vanliga miljö och sådana i laboratorium miljö. Det finns också varierande grad av medverkande hos observatören i olika undersökningar.

Triangulation

Triangulation handlar om att undersöka någonting utifrån olika vinklar. Det finns olika sorters triangulation, t.ex. att man undersöker någonting med hjälp av olika metoder eller att olika personer undersöker samma sak.

Rating scales

Är någonting man använder för frågor i frågeformulär så att de tillfrågade får chansen att specifikt uttrycka hur de känner för en fråga. Boken beskriver två stycken ”rating scales”. En där man kryssar i en av flera boxar där den längst till vänster uttrycker en extrem åsikt åt ena hållet och varje steg åt höger går en bit åt det andra hållet tills man kommer till den andra extremiteten. Den andra innebär istället att man endast beskriver de två extrema åsikterna och att den tillfrågade får märka ut var på skalan de anser att deras åsikt ligger.

Ethnographic data

Handlar om att förstå bakomliggande orsaker till varför viss data ser ut som det gör. Till exempel om det finns regler eller normer på en arbetsplats som påverkar de anställdas beteende.

Think-aloud technique

Innebär att en person får tänka högt medan de blir observerade. Detta kan vara bra för att få en djupare förståelse för hur användare av en tjänst tänker, men kräver en hel del av den som blir observerad.

Indirect observation

Vid indirekt observation är den som observerar inte närvarande vid data insamlingen. Exempel är dagböcker eller data-loggar.

Controlled environment

Innebär att man utför en observation i laboratorium, alltså i en omgivning utformad för observation. Det behöver dock inte nödvändigtvis betyda ett rum eller en byggnad gjort för det ändamålet, det finns också portabla laboratorium som tillåter observation i kontrollerad miljö samtidigt som den som ska observeras kan känna sig säker.

Qualitative analysis

Innebär att man istället för som i kvantitativ analys (ser till siffror) ser till de egenskaper någonting/några besitter. I kvantitativ analys skulle man kanske säga att medellängden hos en population är 150cm medan en kvalitativ analys skulle säga att populationen är kort.

Recurring patterns

Handlar om att se till återkommande företeelser, t.ex. att människor av en viss ålder föredrar en viss hemsida. Det är mycket viktigt att man undersöker dessa noga då det i detta fall inte nödvändigtvis är så att valet av hemsida beror främst på åldern, det kanske beror på att äldre människor i allmänhet ser sämre etc. 

Categorization data

Innebär att sortera den data som samlas in genom undersökningen och bestämt vanligtvis av undersökningens natur och vad målet med undersökningen är. Sorteringen är en mycket viktig del då en bra sortering underlättar analyserandet av datan, och kanske även resultatet. 

Quantitative analysis

Till skillnad från kvalitativ analys ser man på saker och ting i termer av siffror. Välanvända begrepp är medelvärde och procent.

Presenting findings

Handlar om att redovisa det man kommit fram till genom sin undersökning. Boken nämner främst tre stycken olika sätt att presentera sitt resultat på, som dock vanligtvis inte används enskilt utan i kombination. Ett sätt använder förutbestämd syntax för att modellera resultaten, ett annat är att berätta en historia för att gestalta sina resultat, och det sista är att skriva en sammanfattande rapport om resultatet.

Grounded theory

En teori som appliceras på kvalitativ data. Inte någon förutbestämd teori utan istället en som byggs upp helt runt den data som erhålles i undersökningen. De som utför undersökningen kan även använda sig av sin egna teoretiska kunskap de redan har, men måste då vara försiktiga för att inte skada undersökningens objektivitet.

Empirical data

Data grundad på riktiga upplevelser.

Task description

En beskrivning av det som skall uppnås. Finns till för att kunder ska kunna specifiera vad de förväntar sig av en produkt och liknande. Kan utformas på olika sätt (boken beskriver tre), bland annat genom att måla upp ett scenario, som kan (men måste inte) vara bland annat en beskrivning av en situation där någon skulle vilja använda produkten.

Task analysis

Används för att undersöka en, ofta redan existerande, situation. Man analyserar alltså den rådande situationen för att försöka få en förståelse för vad som behövs/vad folk vill ha. Man ser till hur människor i rådande omständigheter löser problem eller använder program, så att man kan utforma nya program/uppdatera existerande program för att åtgärda problem etc.

Non-functional requirements

Till skillnad från funktionella krav, som handlar om mer specifika funktioner som någon vill ha ut av ett program, handlar icke-funktionella krav om hur man vill att programmet ska fungera i allmänhet. Till exempel användbarheten, säkerheten eller hur lätt det är att lägga till nya funktioner till programmet. Alltså egenskaper som beskriver programmet snarare än direkta funktioner som programmet har.

Context of use

Beskriver hur/när/varför/etc programmet förväntas användas. Väldigt viktigt eftersom det är dessa förväntningar som i stort sett bestämmer hur man i slutändan väljer att utforma programmet. Man vill ju skapa ett program som passar användarna.

Use cases

Ett av de tre sätt att utföra en ”Task description”  som boken beskriver. Är i stort sett ett scenario utformat utifrån användarens perspektiv. Fokus ligger alltså på hur användaren upplever situationer och faktiskt använder program.