Utvärdering 6 november 2002 Kap 10-11, 12.3 12.5, 13.5
Frågeställningar kring utvärdering Varför utvärdera? Med eller utan användare Olika utvärderingsmetoder Bearbetning av testresultat Video: Private and Public Spaces
Varför utvärdera? Följa upp sina användbarhetsmål Injicera objektivitet i designprocessen Jämföra olika designförslag Förstå den verklighet systemet skall finnas i
Fem goda skäl att investera i användbarhetstester Problem kan rättas till innan leverans Designteamet kan fokusera på verkliga problem Utvecklare kodar istället för att debattera eventuella problem TTM (Time To Market) minskar Första releasen är en färdig design (kunden behöver inte vänta till 1.1 eller 2.0 för att få det den vill ha)
Utvärdering Formativ utvärdering under de olika designfaserna Summativ slututvärdering av en produkt
Olika utvärderingsparadigmer Quick & Dirty Användbarhetstest (lab) Fältstudier Expertutvärderingar Se tabell 11.1 och 11.2 i Preece
Expertutvärderingar Heuristisk utvärdering expert utvärdering utgående från riktlinjer markera brott mot regler samt en bedömning av hur allvarigt brottet mot riktlinjen är Cognitive walk-through en medlem i designgruppen tar på sig rollen som användare och testar att utföra realistiska uppgifter
Heuristisk utvärdering, riktlinjer Från Nielsen, useit.com/papers/heuristic Synbar systemstatus feedback inom rimlig tid Kopplingen mellan systemet och verkligheten används ett språk begripligt för användaren är systemets vokabulär hämtat ur uppgiftsdomänen visas information i en för uppgiften naturlig ordning Användarkontroll finns undo och redo kan användaren ta sig ur oönskade situationer på ett smidigt sätt
Heuristisk utvärdering, riktlinjer Följ standard och konventioner samma betydelse av ord, termer etc genom HELA systemet Förhindra uppkomsten av fel begränsningar Igenkänning istället för hågkomst synbarhet hos objekt, funktioner och information användaren skall inte behöva komma ihåg vital information
Heuristisk utvärdering, riktlinjer forts Flexibilitet och användningseffektivitet olika nivåer av användande personifiering Minimalistisk design och estetik endast nödvändig information i dialoger Stöd till användaren för felsökning diagnostik begripliga felmeddelanden
Heuristisk utvärdering, riktlinjer forts Hjälpsystem och dokumentation sökbarhet användarfokus, fokus på systemets uppgift konkret och tydlig
Heuristisk utvärdering Ett team går igenom systemet (4-5 personer, begränsad tid) Noterar brott mot riktlinjerna Värderar problemet, hur allvarligt det är Resultaten sammanställs i en rapport
Heuristisk utvärdering, forts MAYA Design Handlingsplan för att gå vidare med problemen Svårighet/kostnad Lågt prioriterade Strategiska Enkla Högt prioriterade Effekt
Cognitive walk-through Simulering av en användares problemlösningsprocess 1. Identifiera och dokumentera användarens typiska drag. Ta fram exempel på uppgifter som berör det man ska utvärdera och en prototyp eller beskrivning av systemet. 2. Designern och en eller flera expertutvärderare träffas för att göra utvärderingen.
Cognitive walk-through Forts... 3. Steg för steg går man igenom varje uppgift i kontexten av ett lämpligt scenario. Under tiden försöker man besvara dessa frågor: Vet användaren vad denne ska göra för att slutföra uppgiften? Upptäcker användren att rätt moment/handling finns tillgänglig (i form av knappar och menyer)? Kommer användaren förstå att de har gjort rätt m h a den feedback de får?
Cognitive walk-through Forts... 4. Under genomgången samlar man kritisk information. Man gör: Antaganden om varför det gick fel och motivering om varför det är kritiskt. Noteringa om designförändringar. Summering av resultaten. 5. Designen ändras till slut för att lösa problemen man har stött på.
Olika utvärderingsmetoder, med användare Kontrollerade experiment Tänka högt protokoll Observationer Intervjuer Enkäter kronor
Kontrollerade experiment Testar två (eller flera) system mot varandra G1 System A System B G2 Variansen i tid skall komma från skillnader i systemen och inte från skillnader hos testdeltagare
Kontrollerade experiment, forts Skall G1 och G2 testa båda systemen? Ja, + Större statistisk säkerhet eftersom varje deltagares prestation i de bägge systemen kan ställas emot varandra Tränings och ordningseffekter Nej, + Skall användas när all transfer av kunskap från ett system till ett annat bör undvikas. Exempel: databassökningar
Kontrollerade experiment,forts Två eller flera system att testa mot varandra. Obs! Behöver ej vara datorbaserade. Mätbara användbarhetsmål - olika grader av uppfyllande. När resurser (tid och pengar) att statistiskt analysera testresultaten finns att tillgå
Tänka-högt protokoll För att observera mismatch mellan intention och handling Används främst vid tester av funktionalitet, interaktion. Förse testdeltagaren med den information han/hon behöver innan Förbered noga. Tänk igenom möjliga scenarion innan. Testar du en prototyp som inte är fullt utbyggd, ge ett scenario
Tänka-högt protokoll, forts Låt en person vara provledare. Provledaren skall inte anteckna. Samla in data samtidigt som experimentet pågår. Anteckningar eller video. Stör så lite som möjligt
Tänka-högt protokoll, forts Begränsa störningar till att be deltagaren att fortsätta prata. Fortsätt tala högt Vad tänker du nu? Vad tror du att detta meddelandet betyder? Om deltagaren frågar: Kan jag göra så? bör provledaren inte svara. Motfråga: Vad tror du händer om du gör det? Verkar deltagaren förvånad då något händer, kan man fråga: Vad detta vad du väntade dig skulle hända?
Tänka-högt protokoll, fördelar: Direkt se vad en användare gör och varför Ser direkt irritationsmoment i interaktionen Ger användarens modell av systemets olika tillstånd
Tänka-högt protokoll, nackdelar: Risk att interaktionen påverkas Svårt att kvantifiera data som samlats in Tänka högt påverkar hastigheten Ericsson och Simon: multiplikationer långsammare, men ändrade inte tankebanorna Finns experiment som visar på att tänka högt => strukturerar arbetet => fortare klar.
Observationer Observera användare av system genom: Övervakning, personligen Videofilma Loggning av händelser Insider - Outsider
Observationer, forts Viktigt att du som testledare förhåller dig passiv, (outsiderobservation). Testledare behöver inte vara närvarande, kan loggas via dator eller videoinspelning.
Intervjuer och enkäter: Intervjuer och enkäter har många likheter. Lämpar sig för att ta reda på: Användarens subjektiva åsikter (Attitude) Hur användare verkligen använder ett system (Throughput) Oro över systemet Oavsett om en intervjun/enkäten används för insamling av analysdata eller utvärdering bör de följa de riktlinjer som gavs på föreläsningen den 24/9
Intervjuer: Djupgående Adaptiv Intervjuobjektet kan ge information som man inte själv tänkt på Möjlighet att ställa följdfrågor Svårt att kvantifiera Ingen anonymitet
Enkäter Enkel kvantifiering Anonymitet Billigt Problem att folk tenderar att svara som man borde Det är det du frågar om som blir besvarat Inte följsamt
Exempel: QUIS Mäter nöjdhet hos användare. Standardiserad frågebank, utvecklat vid University of Maryland. Indelat i frågekategorier Tidigare erfarenheter Inlärning Skärmlayout Terminologi... www.umd.cs.edu/hcil/
Kom ihåg! Utvärdera alltid mot dina mätbara användbarhetsmål När du formulera ett krav i kravspecifikationen skall du redan då ha tänkt ut hur du skall avgöra om systemet uppfyller kravet När du testar mot en prototyp: Hur stor roll spelar prototypens begränsningar?
forts... Hur väl passar testpersonen in på användarprofilen för ditt system? Var testsituationen realistisk? Tester måste också utvärderas
Analysera testdata Kvalitativ bearbetning Team analysis Affinity diagrams Kvantitativ bearbetning Statistiska metoder
Team analysis Går igenom vad som hänt direkt efter observation och intervju Summerar och analyserar utifrån det fokus man etablerat Börjar tolka data
Affinity diagram Post it-lappar med fakta Använder rå data (ex transkript) Kategoriserar bottom up Flyttar alla som hör ihop i en grupp och benämner den Abstraherar, rangordnar och illustrerar beroenden. Ger en bild av hela datamängden
Att testa och utvärdera Exempel: I en undersökning om mobiltelefoner (Karis och Ziegler) visades att... 24 av 25 testpersoner tyckte att manualerna var lätta att förstå och gav dem betyget bättre än genomsnitt. när testpersonerna däremot fick faktiska uppgifter att utföra gjorde de fel i 50% av fallen.
DECIDE Vad är målet med utvärderingen? Vilka frågor är det vi vill ha svar på? Vilka krav är det vi vill testa? Välj lämplig metod Tänk igenom det praktiska upplägget Etiska frågor Analysera och presentera data
Målet med utvärderingen Har alla samma mål? Vad kan vi förändra? Sekundära mål, t ex förankring i organisationen, delaktighet
Vilka frågor Vad är viktigast att få svar på? Lägg inte till frågor som inte är viktiga, det sänker den generella kvaliteten! Vilka krav måste vi testa? ISO-standarder etc
Välj metod Vilken fas befinner sig projektet i? Standarder... Lagkrav Tid och pengar Hur ska resultatet presenteras?
Praktiskt upplägg Antal personer Rätt personer Kontakta i god tid!! Roller och rollfördelning Kolla utrustning Backup!! Förbered mallar Förbered ev testscenarier Ge er tid att testa testupplägget! Tillstånd, avtal Betalning, presenter
Etiska frågor Sekretessavtal Anonymitet Inte sprida vidare Consent forms Få ta del av och godkänna innehållet innan det sprids Självklarheter, men det påverkar personernas förtroende i hög grad!
Analysera och presentera Tänk igenom innan! Lätt att drunkna i dataflödet... En mängd olika metoder Presentera, konkreta exempel ger stor effekt video/ljudklipp, citat, snapshots etc Jobbigt att påpeka fel... glöm inte positiva aspekter Handlingsplan
Video Private and Public Spaces. Scenario över framtidens hem. Fundera på hur man skulle kunna utvärdera detta? Utvärdera helhet och utvärdera ingående komponenter? Användbarhetskrav? Försök hitta.