User Interface Design and Evaluation Samenvatting Tentamenstof

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 beïnvloed 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 TaskScenario’s, Concrete Use Cases, Essential Use Cases en use scenario’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 geëvalueerd. 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, efficiëntie, 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

Hoofdstuk 8: Work reengineering and conceptual design Task Allocation: Hoe de verschillende taken verdeeld worden tussen de gebruiker en het systeem. Kan gemaakt worden vanuit een essential use case. Hierin staat wat de gebruiker doet en hoe het systeem daarop reageert. Hoe het systeem werkt komt hierin niet voor. Conceptual Design is het proces van het maken van het geraamte van een User Interface. Content diagram: een lofi prototype dat de structuur van de user interface laat zien vanuit de ogen van de designer. Container: Abstracte representatie van een deel van het werk van de gebruiker en de functies die nodig zijn om dat deel van het werk uit te voeren. Uiteindelijk kunnen deze containers omgezet worden in schermen, navigatie-elementen enz in een UI of een GUI. Het maken van een content diagram 1. Leidt uit de essential use cases de concrete use cases af (wijst zichzelf) 2. Identificeer de belangrijke task objecten, attributen en acties Task objects: De belangrijkste objecten die gebruikt worden bij een taak Attributen: Eigenschappen van een object Acties: Dingen die mensen doen met een object 3. Identificeer de verschillende containers en de objecten die erbij horen 4. Link de containers zodat je de navigatieflow kan zien Dus een task object heeft eigenschapen, acties en eventueel andere objecten als child of parent (hij voert acties op dit object uit of dit object voert acties op hem uit) Het maken van containers Een container heeft een naam, doel, functies en links met andere containers. Ook verder nog de objecten die horen bij de uit te voeren taak en eventuele beperkingen. De main container is het eerste ding dat gebruikers zien en wat centraal staat in hun werk. Hierin moeten links naar de belangrijkste taken zijn (die snel gebruikt moeten kunnen worden). In de andere containers is het weer belangrijk dat er directe links staan naar functies die geassocieerd worden met de functie waar deze container voor dient. Alle containers dienen met elkaar verbonden te worden via links. Deze links laten zien hoe een gebruiker interacteert met het systeem. Hoofdstuk9: Design guidance and design rationale User Interface Standards: Een aantal international afgesproken design principen Design Guidelines: Iets tussen design rules en design principles in Style Guides: Een verzameling design rules, samen met een aantal design guidelines. Dus eigenlijk een soort design handleiding 2 soorten style guides 1. Commercial Style Guides 2. Customized Style Guides Een style guide bevat meestal de volgende dingen  Beschrijving van de benodigde interactie stijlen en user interface controls, die zowel de look als feel beschrijven  Assistentie voor het wanneer en hoe te gebruiken van de verschillende interactie stijlen en user interface controls  Illustraties van de verschillende interactiestijlen en user interface controls  Afbeeldingen van hoe schermen eruit zouden moeten zien

Er zijn vele belangrijke design principes (7 behandeld in hoofdstuk 5). Hier nog 4  Simplicity (een UI moet zo simpel en eenduidig mogelijk werken)  Structure (Een design moet logisch en gestructureerd in elkaar zitten)  Consistency (Een UI moet consequent zijn. Een gebruiker moet kunnen voorspellen hoe een volgend scherm er ongeveer uit zal zien  Tolerance (Een systeem moet zo min mogelijk fouten kunnen veroorzaken) Een design rationale is een soort verslagje waarin je bijhoudt waarom je bepaalde keuzes gemaakt hebt. Dit zodat je later kan terugzoeken waarom je iets ook alweer gedaan hebt. Ook kan hierdoor gebruik gemaakt worden door een eventueel nieuw staflid die moet weten waarom bepaalde keuzes gemaakt zijn. Hoofdstuk10: Interactive Design De human action cycle is de ‘route’ die een gebruiker volgt om een taak uit te voeren. Deze is als volgt: Doel vormen -> acties uitvoeren die hem naar het doel leiden -> anticiperen op acties om te zien of je dichter bij het doel komt -> als het doel niet bereikt lijkt te kunnen worden, route aanpassen en opnieuw beginnen. Oftewel doel vormen -> Proberen doel te bereiken -> Evalueren Designers Model: Het systeem zoals hij eruit ziet voor de designer, dus met alle technische details. System Image: Een manier om de functionaliteit van het systeem te tonen aan de gebruiker Users Model: De mate waarin de gebruiker het systeem begrijpt. Veelal incompleet en incorrect. Metaforen Het gebruik van metaforen is een manier waarop gebruikers functies/acties associeren met de reële wereld. Bijvoorbeeld een printer icoontje en het woordje shop in een e-shop. Bij metaforen is het belangrijk dat ze aan 2 eisen voldoen:  Om bruikbaar te zijn moeten ze overeenkomen met de wereldervaringen van de gebruiker.  Om bruikbaar te zijn moeten ze wel binnen de ervaringen van de gebruiker liggen. Hoofdstuk11: Interaction Styles Interactiestijl: Een manier waarop een gebruiker interacteert met het systeem. 5 soorten toegelicht: 1. Command Line: Input mbv commando’s Voordelen: Flexibel, Goed voor experts, macro’s en shortcuts functioneel Nadelen: Kost veel tijd om alle commando’s te leren 2. Menu Selection: Door het bladeren door menu’s input geven Voordelen: Makkelijk te leren, gestructureerd Nadelen: Kan complex worden als het te groot wordt, Kost veel screenruimte, Langzaam voor experts 3. Form-Fill: Door het invullen van tekstvelden input geven Voordelen: Simpel, Kost weinig oefening Nadelen: Kost veel screenruimte 4. Direct Manipulation: Direct met de objecten interacteren, bijvoorbeeld drag&drop Voordelen: Visueel duidelijk, makkelijk te leren/onthouden, weinig errors/makkelijk herstel Nadelen: Heeft graphics nodig, kan snel onduidelijk worden qua metaforen 5. Anthropomorphic: Interactie met het systeem zoals je interactie hebt met andere mensen. Voordelen: Heel natuurlijk Nadelen: Onvoorspelbaar, Moeilijk te implementeren

Hoofdstuk13: Choosing interaction elements: software components 5 belangrijke onderdelen waar aan gedacht moet worden bij design  Tekst: Niet te groot, niet te klein, goede letterruimte, goed leesbaar lettertype, niet al te lange zinnen, maar ook niet te kort. Regellengte niet te lang, maar niet te kort  Kleur: Niet al te overheersend of irriterend. Wordt gebruikt om attention te trekken, status te laten zien of om de informatie duidelijker te maken. (Of voor layout natuurlijk). Gebruikt goed contrast tussen tekstkleur en achtergrondkleur.  Afbeeldingen: Aandacht trekken, interactie duidelijk maken. Verhelderend. Alleen gebruiken als het een doel heeft.  Animaties en videos: Hetzelfde als afbeeldingen Hoofdstuk14: Moving from choosing components into design areas Principles of good layout:  Logische structuur gebruiken  Actieve componenten apart houden  Belangrijke componenten op een opvallende plek zetten  Maak goed gebruik van de witte ruimte. Soms geldt less is more  Laat de controls goed zichtbaar zijn  Het moet er mooi uitzijn, maar ook goed bruikbaar zijn. Vind een goede balans Technological convergense: Het mengen van verschillende design areas zoals GUI’s, Web Pages en Embedded systems Ubiguitous Computing: Als computers in nieuwe design areas met elkaar gaan communiceren Hoofdstuk20: Why evaluate the usability of user interface designs (Usability) Evalation: De complete test van de User Interface Participant: De proefpersoon Observer: Degene die de test observeert en ondertussen aantekeningen maakt Facilitator: Hulppersoon voor de participant Evaluator: De persoon die de evaluatie planned, analyseert en verwerkt Evaluation Data: De informatie die opgedaan wordt tijdens een evaluatie. Problemen die gevonden worden heten usability problems Wat moet je testen?  Users  Tasks  Domain  Omgeving Evaluation Technique: Techniek om een evaluatie mee uit te voeren. 2 belangrijke  User Observations Een gebruiker maakt gebruik van het systeem, voert wat taken uit ed. En een observer maakt aantekeningen  Heuristic Inspection (Heuristische Evaluatie) De participant is een expert/usability expert. Hij test of je je goed aan de design principles e.d. gehouden hebt

Hoofdstuk 21: Deciding on what you need to evaluate: the strategy 1. Het bepalen van het doel van de evaluatie Bepaal of je de usability requirements wil bepalen of dat je problemen wil opsporen Kwalitatieve Usability requirements: Is de vorm goed Kwantitatieve Usability requirements: Is de hoeveelheid goed Weer rekening houden met de 5 e’s. Effective,Efficient,Engaging,ErrorTolerant,EasyToLearn Moeten goed in balans zijn. 2. Bepalen wat voor soort data je wil verzamelen Kwalitatieve data: Numerieke data Kwantitatieve data: Niet-numerieke data zoals subjectieve meningen van gebruikers 3. Bepalen wat je aan het evalueren bent Lo-Fi Prototype: Vooral vragen naar navigatie, kleuren, enz Hi-Fi Prototype: Meer gedetailleerd, ook kwalitatieve data opdoen 4. Bepalen welke beperkingen je hebt Mogelijk weinig budget, weinig proefpersonen enz Evaluatie aanpassen aan je beperkingen Hoofdstuk22: Planning who, what, when and where Het maken van een evaluatieplan kost een paar overwegingen. Wie zijn de participants, wat ga je evalueren (h21), wanneer ga je evalueren en waar ga je evalueren 1. De participants bepalen Het is belangrijk om een gebruiker binnen je doelgroep te gebruiken (real user). Zorg voor een goede variatie in gebruikers, dus eentje met veel IT-ervaring, oudere mensen, jongere mensen, mensen met bijv. kleurenblindheid, enz. Of je mensen moet laten samenwerken kan je het beste laten afhangen van de manier waarop ze het product gaan gebruiken in de praktijk. 2. Het aantal gebruikers Volgens het boek kan je het beste met 5 proefpersonen beginnen en als je het gevoel hebt dat dit niet genoeg opgeleverd heeft of dat je nog heel veel tijd over hebt, dan kan je dat aantal groter maken. Pretest questionnaire: Vragen die je stelt aan het begin van de evaluatie 3. Timetable maken Indien mogelijk, probeer dan de evaluatie tussen de 30 en 90 minuten te laten duren. Daarbij in zitten ook het verwelkomen van de gebruiker en een aantal vragen stellen na afloop. Task Description: Beschrijving van een taak die een gebruiker tijdens de evaluatie dient uit te voeren. 4. Waar doe je de evaluatie? Field Studies: Evaluatie vindt in de werkomgeving van de gebruiker plaats Een groot voordeel hiervan is dat je veel omgevingsdata kan opdoen Controlled Studies: Evaluatie vindt ergens anders plaats Hoofdstuk23: Deciding how to collect data Om te meten hoe lang een gebruiker erover doet kan je bijvoorbeeld een stopwatch gebruiken, maar het gebruik maken van een logging product is veel handiger. Alle gegevens kunnen hierin ingevoerd worden en het wordt automatisch voor je in een database gezet. Thinking aloud protocols: Evaluatie data die opgedaan wordt als je de gebruiker vraagt hardop te denken

Retrorespective protocol: na afloop van de evaluatie de events rerunnen en de gebruiker de mogelijkheid geven commentaar te geven Post-Session-Interview/Debrief: na afloop van de evaluatie nog even een general discussie houden Tip: Opname van de evaluaties kan handig zijn omdat je het dan later terug kan kijken. Hoofdstuk24: Final preparations for the evaluation Verschillende rollen voor evaluators: Facilitator: Zorgt dat de participants zich op hun gemak voelen, zorgt dat de participants blijven praten over wat er gebeurt en zorgt dat de evaluatie correct verloopt. Note-Taker: Maakt aantekeningen van wat er gebeurt tijdens de evaluatie Equipment Operator: Regelt video/andere opnameapparatuur. Observer: Observeert de gebruikersgroep tijdens de evaluatie. Meeter and greeter: Verwelkomt de participants en is een soort gastheer. Recruiter: Degene die de participants zoekt The Lone Evaluator: Als je alles zelf moet doen, dan kunnen de evaluaties wat langer duren. Neem zo nodig extra pauze Script voor tijdens evalueren  Verwelkomen  Uitleggen wat er gaat gebeuren  Evt. een questionnaire voorleggen  Taken en cognitieve vragen uitvoeren  Afsluitend interview afnemen  Bedanken van de participant Pilot Test/Proefevaluatie Voor een echte evaluatie kan het handig zijn om een proefevaluatie uit te voeren. Doel hierbij is om eventuele tekortkomingen of onduidelijkheden in de taken/vragen te vinden voordat je ze voorlegt aan de echte gebruikersgroep en de evaluatie misloopt. Een goede doelgroep hiervoor is hetzelfde als bij de echte evaluatie, al is het niet zo belangrijk dat ze precies de beoogde doelgroep representeren. Hoofdstuk 25: Analysis and interpretation of user observation evaluation data Tijdens een evaluatie kan het zo zijn dat je een grote berg data hebt. Om dit allemaal te verwerken zul je een aantal stappen moeten doorlopen. 1. Organiseer je data, soort bij soort en filter het onbelangrijke eruit 2. Maak evt samenvattingen van grote lappen tekst 3. Review de data om usability defects te vinden. Problemen in de user interface Drie groepen methoden om quantitatieve data te analyseren 1. Tabellen, grafieken en rankings: een visuele representatie van de resultaten 2. Descriptive Statistics: Getallen die je data beschrijven 3. Inferential Statistics: Testresultaten en bevestigingen/ontkrachtigingen van je ideeen Hoofdstuk26: Inspections of the user interface Bij een heuristische evaluatie controleren een aantal inspectors of er aan de design principles gehouden is (ook wel heuristics genoemd)

Bij een heuristische evaluatie moet allereerst de heuristics gekozen worden. Welke guidelines wil je gaan testen? Voorbeelden zijn zichtbaarheid, flexibiliteit, effiecentie en error prevention. Vervolgens moet je inspectors vinden. In tegenstelling tot bij een evaluatie niet een doelgroeprepresentatie, maar iemand met de nodige ervaring in HMI en het domein van het systeem. Vaak vind je niet beide kenmerken in 1 persoon, dus zal je vaak 2 of meer personen nodig hebben. De locatie is meestal niet de gebruiksomgeving van het product, maar meet een controlled studies locatie. Vervolgens moet je de data gaan analyseren. Dit verloopt hetzelfde als bij evaluaties. Dus eerst organiseren van de data, daarna samenvatten en vervolgens relevante conclusies uit de gegevens trekken. Voordelen:  Vaak goedkoper dan observaties  Inspectors komen veel vaker met oplossingen  Helpt vervelende errors tijdens echte evaluaties voorkomen Nadelen:  Vaak geen representatieve users te gebruiken/vinden voor de heuristische evaluatie  Inspectors vinden bepaalde errors vaak minder of juist belangrijker dan echte gebruikers  Inspectors hebben vaak bepaalde eigen smaken op het gebied van user interfaces  De data is puur afhankelijk van de skills en ervaring van de inspectors Hoofdstuk27: Variations and more complex evaluations Evaluatietechnieken hebben een aantal elementen gemeen. Namelijk het observeren, vergelijken, luisteren en een maat van resultaat. Variaties voor user observations  Remote Moderated Testing: Gebruikers op afstand het systeem laten gebruiken en observeren via een video-converentie of telefoon gesprek.  Performance Measurement Evaluation: Doel om verschillende versies van het systeem met elkaar te vergelijken. Dit om erachter te komen wat de gebruikersgroep het liefst zou willen gebruiken. Formative Evaluations: Evaluaties die deel uitmaken van een constant ontwikkelingsproces Summative evaluations: Evaluaties die na afloop van een proces worden uitgevoerd om erachter te komen of er aan de requirements voldaan is 4 typen evaluaties  Exploratory Evaluations met als doel om de requirements te bepalen en feedback te krijgen op proefversies/lofi prototypes. Veelal gebruikt aan het begin van een design proces  Validation Evaluations: Meestal gebruikt aan het eind van het ontwikkelingsproces en bedoeld om erachter te komen of het systeem voldoet aan de requirements en of de verschillende onderdelen van het systeem goed samenwerken  Assessment Evaluaties: Meestal gebruikt aan het begin van het ontwikkelingsproces na de exploratory evaluations. Bedoeld om te kijken of je op de goede weg bent  Comparison Evaluations: Kan overal gebruikt worden en heeft als doel om erachter te komen welke van de verschillende versies van je product het beste is.