User Interface Design and Evaluation Samenvatting Tentamenstof

Hoofdstuk 2: How to gather requirements: some techniques to use Er zijn 2 soorten observaties 1. Directe observatie (zelf gaan kijken): Voordelen: Makkelijk te ondernemen en levert vaak interessante data op Nadelen: Je ziet snel dingen over het hoofd 2. Indirecte Observatie (m.b.v. video of geluidsopname) Voordelen: Makkelijk later terug te kijken Nadelen: Kost veel tijd om te analyseren Er zijn 2 soorten interviews 1. Gestructureerd (Alle vragen vooraf vastgesteld) Voordelen: Makkelijker voor de interviewer, Weinig data analyse tijd Nadelen: Minder kans om de gebruiker interessante dingen te laten vertellen 2. Flexibel (Vooraf onderwerpen vastgesteld, maar geen vaste vragen/volgorde) Voordelen: Handig om achter de requirements te komen, Laat gebruiker veel vertellen Nadelen: Lastiger voor de interviewer, Veel data-analyse tijd Er zijn 2 vraagstructuren 1. Gesloten Vragen (vragen met 2 of meerdere vaste antwoordmogelijkheden) Checklist bijvoorbeeld Semantic Differential (Vragen met een statement die je een rating moet geven) 2. Open Vragen (vragen waarbij de gebruiker een open antwoord kan geven) Gesloten vragen zijn makkelijker te analyseren. De vragen moeten zo eenvoudig mogelijk zijn. Ook moeten ze duidelijk zijn, omdat je ze niet kan helpen bij het invullen. Zorg voor de mogelijkheid om opmerkingen te laten geven Hoofdstuk3: Finding out about the users and the domain 2 soorten gebruikers 1. Primary Users (of users) zijn de belangrijkste gebruikers van het system 2. Secondairy Users zijn andere mensen die in aanraking kunnen komen met het systeem Primary Users en Secondairy Users worden samen stakeholders genoemd Een gebruiker heeft user characteristics. Dit zijn eigenschappen van gebruikers die van belang zijn voor het systeem. Leeftijd en geslacht Cultuur Fysieke (on)mogelijkheden (ihb (kleuren)blindheid, doofheid enz) Educatieve achtergrond Computer-ervaring Motivatie en houding Dit in een tabel zetten heet het maken van een user profile. Deze user profile kan weer onderverdeeld worden in een aantal groepen. De resultaten uit dit onderzoek naar eisen kan worden omgezet in requirements. Voor bijvoorbeeld een gebruikersgroep van 65+ zou het handig zijn om grote knoppen kunnen gebruiken met grotere letters dan normaal. Als je de eigenschappen van een gebruikersgroep in een personage stopt krijg je een persona. Een persona heeft altijd een naam, zodat je hem tijdens het ontwerp makkelijk kan benoemen. 2 typen behoeften 1. Felt Needs zijn behoeften die gebruikers willen, maar niet weten dat het ook mogelijkheden zijn. 2. Expressed Needs zijn behoeften waarvan een gebruiker zegt dat hij/zij ze nodig hebben.

Hoofdstuk 4: Finding out about tasks and work Goal: Een te bereiken eindresultaat (en niets meer) Tasks: Activiteiten die moeten worden uitgevoerd om een goal te bereiken Actions: Een individuele operatie die gezet moet worden als deel van een taak Dus meerdere actions vormen een task en meerdere tasks vormen een goal Voor het maken van een taakbeschrijving zijn een aantaldingen van belang Verschilt de taak per gelegenheid? Hoe vaak wordt de taak uitgevoerd? Moet een gebruiker iets specifieks kunnen om de taak uit te voeren? Wordt de taak benvloed door de omgeving? Is de tijd die de taak kost belangrijk? Zijn er issues voor veiligheid? Wordt de taak alleen of gezamenlijk uitgevoerd? Wisselen de gebruikers wel eens tussen verschillende taken? Workflow Analysis: Hoe het werk wisselt per gebruiker/werkers? Job Analysis: Wat gebruikers naast de taak nog aan andere taken uitvoeren Artifacts: Objecten die gebruikt worden bij de prestatie van de taak Ta skScena r io s, C oncr ete Use Ca ses, Essentia l U se Ca ses en use scena r io s Een task scenario is een klein verhaaltje hoe een gebruiker een system gebruikt en hoe het system reageert vanuit de ogen van de gebruiker. Een concrete use case is eigenlijk hetzelfde, maar dan zonder verhaaltje er omheen en alleen wat de user doet en hoe het systeem daarop reageert vanuit de ogen van de gebruiker. Een essential use case werkt op een meer abstract niveau en werkt vanuit het gezichtspunt van het systeem. Dus wat de gebruiker doet en hoe het systeem daarop reageer vanuit het oogpunt van het systeem. Een use scenario is weer hetzelfde als een task scenario, maar dan vanuit het oogpunt van de machine. Cognitieve Walkthrough Een cognitieve walkthrough is een soort expert-evaluatie techniek waarbij een aantal tasks zeer nauwkeurig worden gevalueerd. Dit wordt in 4 stappen uitgevoerd 1. De gebruiker kiest een taak om uit te voeren en schrijft alle actions in de taak op. Voor elke taak worden dan de stappen 2 t/m 4 gevolgd en daarna de vragen a t/m c gesteld. 2. De gebruiker zoekt de actie op die hij moet uitvoeren om de taak uit te voeren 3. De gebruiker selecteert de actie waarvan hij denkt dat deze het best matched met wat hij wil doen. 4. De gebruiker bekijkt de systeemreactie en bedenkt of er voortgang is gemaakt bij het bereiken van het doel. De volgende 3 vragen worden gesteld aan de gebruiker a. Weet de gebruiker wat hij moet doen? Herinnert hij het zich uit zijn geheugen of herkent hij het direct? b. Wordt de geselecteerde actie goed geassocieerd met de uit te voeren taak? c. Weet de gebruiker na a afloop van de taak of hij de goede keus gemaakt heeft? Mental Model: Mensen hebben (onbewust) een model in hun hoofd van hoe de wereld eruit zou moeten zien wat ons helpt om te gaan met niet-vertrouwde situaties. 2 Soorten: 1. Structural Models: Een gebruiker heeft in zijn hoofd een idee van hoe een systeem zou moeten werken. 2. Functional Models: Een gebruiker heeft in zijn hoofd een idee van hoe een systeem zou moeten worden gebruikt.

Een aantal aspecten van de omgeving zijn van belang voor het gebruik van het systeem. De fysieke omgeving: Voldoende licht, comfortabele temperatuur, schoon, enz De veilige omgeving: Speciale kleren nodig, moet je je hoofd er bij hebben, enz? De sociale omgeving: Deadlines, Delen gebruikers gegevens? Vertrouwen gebruikers elkaar? Enz De organisatorische omgeving: Werktijden, Functies, Onderbrekingen, Management, enz De user-support omgeving Hoofdstuk5: Requirements gathering: knowledge of user interface design Design Principles: Abstracte handleidingen voor design die moeilijk te te passen zijn Design Rules: Vertaalde principles die makkelijker toegepast kunnen worden. Er zijn vele psychologische principles, 4 belangrijke worden toegelicht 1. Gebruikers zien wat ze verwachten te zien 2. Gebruikers hebben moeite om zich te focussen op meer dan 1 activiteit tegelijk 3. Een gestructureerde layout is makkelijker te begrijpen a. Proximity: Elementen die dicht bij elkaar zijn vormen al snel een groep b. Similarity: Elementen met dezelfde vorm/kleur horen bij elkaar c. Closure: Een incompleet element wordt gezien als compleet (we vullen het gat) d. Continuity: Mensen zien al snel vormen in rijtjes elementen e. Symmetry: Twee symmetrische figuren worden al snel als samenhangend gezien f. Figure-Ground-Segregation: Plaatjes worden onderscheden als figuur en achtergrond als er 2 gebieden zijn. 4. Herkennen is beter als herinneren Er zijn vele principes van ervaring, 3 belangrijke worden toegelicht 1. Visibility: Het moet logisch zijn waar een functie voor dient 2. Affordance: Het moet logisch zijn hoe een functie gebruikt wordt 3. Feedback: Het moet duidelijk zijn dat een functie gebruikt is

Hoofdstuk 6: Thinking about requirements and describing them 2 soorten usability requirements 1. Kwalitatieve usability requirements Subjectieve eisen aan het system op een hoog niveau van abstractie. Voorbeelden zijn moet makkelijk te gebruiken zijn, of gebruikers moeten tevreden zijn 2. Kwantitatieve usability requirements De wat meer specifieke performance eisen (usability metrics) als completion tasks, errors, enz. Bij het ontwerpen van een product moet ook aan de gebruikers gedacht worden in de vorm van learnability (de tijd die nodig is om te leren omgaan met het systeem), throughput (de snelheid waarin een taak kan worden uitgevoerd en het aantal fouten dat gemaakt wordt), flexibility (of een systeem zich makkelijk kan aanpassen aan wat de gebruiker op dat moment doet) en attitude (zorgen dat een gebruiker positief tegenover het gebruik van het systeem staat). Tegenwoordig zijn deze dingen omgezet in een moderne view van usability. De belangrijkste eisen aan een systeem waaraan moet worden gedacht zijn effectiviteit, efficintie, aannemelijk (moet plezierig in gebruik zijn, engaging), error tolerantie en makkelijk te gebruiken (easy to learn).

Ook zijn er nog enkele niet-systeemgerelateerde eisen waar rekening mee gehouden dient te worden. Kosten: Je moet wel binnen het budget blijven. Technische Beperkingen: Alles moet wel mogelijk zijn met de huidige technologie (of je moet zelf met nieuwe technologie komen). Te maken overwegingen: Soms moeten er keuzes gemaakt worden, bijvoorbeeld een feature voor slechts een klein deel van de gebruikersgroep. Een prototype is een experimenteel, incompleet design van het systeem die gebruikt kan worden voor het testen. Je test de haalbaarheid van je ideeen met gebruikers. De bruikbaarheid van het systeem. Je geeft gebruikers de mogelijkheid om bij de dragen aan het design van het systeem. Je test ideeen en controleert of er aan de requirements voldaan is. Het eerste prototype dat je gaat maken heet een lo-fi prototype. Deze hebben nog geen functionaliteit en hebben als doel om de gebruiker een idee van de look and feel van het systeem te geven. Meestal worden hiervoor op papier schetsen gemaakt van hoe het systeem eruit zou zien. Ook is het mogelijk om hierbij storyboards te maken waarbij je aan de hand van een actie een illustratie laat zien van hoe het eruit zou zien. Een hi-fi prototype is een veel gedetailleerder prototype Voordelen van een lofi prototype Goedkoop te produceren Ze kunnen gebruikt worden om ideeen te evalueren Makkelijk aan te passen (tijdens het testen) Ze laten de look & feel zien Nadelen van een lofi prototype Error-detectie is zeer gelimiteerd Specificatie is niet erg gedetailleerd Er zijn mensen nodig om te laten zien hoe het werkt Voordelen van een hifi prototype Ze kunnen de volldige functionaliteit laten zien Ze laten de look and feel, de layout en het gedrag van het uiteindelijke product zien Zijn volledig interactief en kunnen goed bij marketing gebruikt worden Nadelen van een hifi prototype Ze kosten heel veel tijd om te produceren Ze kunnen niet makkelijk aangepast worden tijdens het testen Ze kunnen er erg professioneel uitzien waardoor gebruikers moeite hebben kritiek te geven Problemen bij prototyping Kan erg veel tijd kosten om een prototype te maken, dus zal alleen gedaan moeten worden als het noodzakelijk is. Het kan erg veel geld kosten om een prototype te maken