Samenvattingen · InformaticaNL · HAVO

Domein F: Interactie

Interactie gaat over de communicatie tussen mens en computer: hoe een gebruiker een doel omzet in handelingen en hoe het systeem daarop reageert. Je leert de handelingscyclus van Norman met de uitvoerings- en evaluatiekloof, de rol van feedback, feedforward en mentale modellen, de belangrijkste interactiestijlen en modaliteiten, en hoe je gebruikersgericht en iteratief ontwerpt. Toegankelijkheid (WCAG) en usability-heuristieken komen apart aan bod in het keuzethema Usability; hier ligt de nadruk op het interactiemodel en het ontwerpproces.

4 Onderdelen~21 min leestijd4 VaardighedenNiveau Basis 1 · Standaard 2 · Verdieping 1

T·0666 / 12

Examenprofiel

De handelingscyclus van Norman toepassen op een concrete taak en de uitvoeringskloof en evaluatiekloof aanwijzenFeedback, feedforward, affordances en signifiers herkennen en het verschil tussen mentaal en conceptueel model uitleggenInteractiestijlen en modaliteiten vergelijken en een passende stijl kiezen bij taak, gebruiker en contextGebruikersgericht en iteratief ontwerpen met persona's, gebruiksscenario's en prototypes

Operatoren:leg uitbeschrijfberedeneerontwerpvergelijkpas toe

basisniveau

Zorg dat je de handelingscyclus, feedback en feedforward en de belangrijkste interactiestijlen met eigen voorbeelden kunt uitleggen en herkennen.

verhoogd niveau

Beredeneer ontwerpkeuzes: koppel de twee kloven aan concrete interface-elementen en onderbouw je keuze voor een interactiestijl en een prototypeniveau voor een specifieke doelgroep.

Diepte

Tekst

Inhoud · 4 onderdelen

Domein F: Interactie

Mens-computerinteractie en het interactiemodel#

Basisexamenblad-nl

Mens-computerinteractie (MCI, in het Engels human-computer interaction) is het vakgebied dat bestudeert hoe mensen en interactieve systemen met elkaar communiceren, en hoe je die communicatie zo ontwerpt dat ze doeltreffend, efficiënt en prettig is. De plek waar mens en machine informatie uitwisselen heet de gebruikersinterface: het scherm, de knoppen, de geluiden en de gebaren waarmee jij en het systeem elkaar iets duidelijk maken. Interactie is nooit eenrichtingsverkeer maar een wisselwerking: jij doet iets, het systeem verandert van toestand, jij neemt dat waar en bepaalt je volgende zet. Om die wisselwerking te ontwerpen en beoordelen, hebben onderzoekers modellen gemaakt die de stappen van een interactie beschrijven; het bekendste is de handelingscyclus van Donald Norman.

Norman splitst één handeling op in zeven stappen die samen een cyclus vormen. Het begint met een doel: wat wil je bereiken? (bijvoorbeeld „ik wil dat de muziek zachter gaat”). Dat vage doel vertaal je in een concrete intentie („ik ga het volume verlagen”), en die intentie werk je uit in een handelingsplan: wélke knoppen of gebaren, in welke volgorde? Ten slotte voer je de handeling uit. Deze eerste helft — doel, intentie, plan, uitvoeren — heet de uitvoeringskant: hier zet je een wens om in fysieke acties op de interface. Hoe beter de interface toont wat je kunt doen en hoe je dat doet, des te makkelijker doorloop je deze helft.

Na de handeling verandert het systeem van toestand: de versterking gaat omlaag, een bestand verdwijnt, een pagina laadt. Dan begint de tweede helft van de cyclus, de evaluatiekant. Je neemt de nieuwe toestand waar (je hoort of het zachter is, je ziet de volumebalk zakken), je interpreteert wat je waarneemt, en je evalueert of het resultaat je oorspronkelijke doel dichterbij heeft gebracht. Is dat zo, dan ben je klaar; zo niet, dan stel je een nieuw (deel)doel en begint de cyclus opnieuw. Daarom is de handelingscyclus juist een cyclus en geen rechte lijn: interactie bestaat uit vele kleine rondjes achter elkaar (zie Afb. 1).

De handelingscyclus van Norman

Afb. 1Afb. 1 — De handelingscyclus doorloopt een uitvoeringskant (doel, plan, handeling) en een evaluatiekant (waarnemen, evalueren) en sluit zich weer bij het doel.

Twee begrippen maken scherp waar interactie mis kan gaan. De uitvoeringskloof (Engels: gulf of execution) is de afstand tussen wat jij van plan bent en wat het systeem je toestaat of aanbiedt te doen. Die kloof is groot als je niet kunt zien hóé je je doel bereikt: een afstandsbediening vol cryptische knoppen, of een touchscreen zonder zichtbare volumeregeling. Je weet wat je wilt, maar niet welke handeling daarbij hoort. Een goed ontwerp verkleint deze kloof door duidelijk te tonen welke acties mogelijk zijn en hoe je ze uitvoert — daarover gaat de volgende paragraaf, over feedforward en affordances.

De evaluatiekloof (gulf of evaluation) is de afstand tussen de werkelijke toestand van het systeem en jouw vermogen om die waar te nemen en te begrijpen. Die kloof is groot als het systeem niet laat merken wat er gebeurd is: je drukt op „opslaan” maar er verandert niets zichtbaars, dus je weet niet of het gelukt is. Een goed ontwerp verkleint deze kloof met heldere terugkoppeling: een melding, een veranderd icoon, een geluid. Kort gezegd overbrugt feedforward de uitvoeringskloof (hóé doe ik het?) en feedback de evaluatiekloof (is het gelukt?). Wie deze twee kloven scherp uit elkaar houdt, kan bijna elk interactieprobleem precies benoemen.

Uitgewerkt voorbeeld

De handelingscyclus toegepast: het volume harder zetten

Je luistert naar muziek op een bluetooth-speaker en vindt het te zacht. Doorloop de handelingscyclus van Norman voor de taak „het volume harder zetten” en geef aan waar een uitvoeringskloof of een evaluatiekloof kan ontstaan.

Doel
Je stelt een doel: de muziek moet harder klinken.
Intentie en plan
Je vormt de intentie „ik ga het volume verhogen” en bedenkt het plan: op deze speaker draai je de knop rechtsom, op je telefoon sleep je de volumeschuif omhoog of druk je de volume-omhoog-knop.
Handeling uitvoeren
Je draait de knop rechtsom (of drukt de volumeknop op de telefoon).
Systeem verandert
De versterking van de speaker gaat omhoog; het geluid wordt luider.
Waarnemen, interpreteren, evalueren
Je hoort dat het harder wordt en ziet eventueel de volumebalk stijgen; je beoordeelt of het nu hard genoeg is. Zo niet, dan begin je de cyclus opnieuw met een nieuw deeldoel.
Uitvoeringskloof
Ontstaat als je niet kunt zien hóé je het volume verhoogt: een knop zonder markering welke kant harder is, of een touchscreen zonder zichtbare volumeregeling.
Evaluatiekloof
Ontstaat als het systeem het resultaat niet toont: de speaker staat per ongeluk gedempt en er is geen volume-indicator, dus je weet niet of je handeling effect had.

Resultaat: De taak doorloopt alle stappen van doel tot evaluatie. Duidelijke markeringen op de knop (feedforward) verkleinen de uitvoeringskloof, en een zichtbare volumebalk plus hoorbaar geluid (feedback) verkleinen de evaluatiekloof.

Veelgemaakte fouten

De twee kloven verwisselen: de uitvoeringskloof gaat over HÓE je iets doet, de evaluatiekloof over of je ZIET dat het gelukt is.
Denken dat de cyclus maar één keer doorlopen wordt; hij is iteratief — na evalueren volgt vaak meteen een nieuw (deel)doel.
De interface gelijkstellen aan alleen het uiterlijk; het is het hele kanaal waarlangs mens en systeem informatie uitwisselen.

Actieve herhaling

Beschrijf de handelingscyclus van Norman voor de taak „een bestand verwijderen op een laptop” en geef één plek aan waar een evaluatiekloof kan optreden.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Feedback, feedforward en mentale modellen#

Standaardexamenblad-nl

Feedback is de informatie die een systeem geeft ná een handeling, over wat er is gebeurd of wat de nieuwe toestand is. Het sluit de lus van de handelingscyclus: zonder feedback blijf je in het ongewisse en groeit de evaluatiekloof. Goede feedback is direct (komt meteen), informatief (zegt wát er gebeurde) en gepast (niet te veel, niet te weinig). Denk aan een knop die kort indrukt en van kleur verandert, een laadbalkje, een trilling bij een appje of het klikgeluid van een toets. Slechte of ontbrekende feedback is een van de meest voorkomende ontwerpfouten: als je niet zeker weet of je tik geregistreerd is, tik je nog eens — en verstuur je per ongeluk twee berichten.

Feedforward is het spiegelbeeld van feedback: informatie vóór of tijdens een handeling over wat een actie zál doen en wat er mogelijk is. Het overbrugt de uitvoeringskloof. Twee begrippen horen hierbij. Een affordance is de relatie tussen de eigenschappen van een object en de handelingen die het uitnodigt: een plat plaatje op een deur nodigt uit tot duwen, een handgreep tot pakken en trekken; op een scherm nodigt een opbollende knop uit tot klikken en een schuif tot slepen. Een signifier is een waarneembare aanwijzing die vertelt wáár en hóé je moet handelen: het woord „DUW”, een onderstreepte link, een pijltje. Norman vat het samen: affordances bepalen wat mogelijk is, signifiers communiceren waar de handeling plaatsvindt.

Consistentie maakt een interface voorspelbaar: dezelfde handeling leidt overal tot hetzelfde effect, en dezelfde functie ziet er overal hetzelfde uit. We onderscheiden interne consistentie (binnen één programma werkt „opslaan” altijd gelijk) en externe consistentie (het sluit aan bij wat je elders gewend bent — een diskette-icoon voor opslaan, een kruisje om te sluiten). Consistentie verlaagt de leerlast, want wat je op één plek leert, kun je overal toepassen; het versterkt bovendien je vertrouwen in het systeem. Een inconsistente interface dwingt je telkens opnieuw na te denken en vergroot zo beide kloven.

Elke gebruiker bouwt een mentaal model op: een innerlijke voorstelling van hoe het systeem werkt, gevormd door eerdere ervaring, door wat de interface laat zien en door algemene kennis van de wereld. De ontwerper heeft een eigen conceptueel model (ook wel ontwerpmodel): de manier waarop het systeem volgens de bedoeling in elkaar zit. Het probleem is dat ontwerper en gebruiker nooit rechtstreeks met elkaar praten. De ontwerper kan zijn model alleen overbrengen via het systeembeeld: de interface, de documentatie, de labels en de reacties van het systeem. Is dat systeembeeld helder, dan gaat het mentale model van de gebruiker lijken op het conceptuele model van de ontwerper. Is het onduidelijk, dan vormt de gebruiker een verkeerd model en ontstaan er fouten die eigenlijk ontwerpfouten zijn.

Feedback, feedforward, consistentie en een helder systeembeeld werken samen (zie Afb. 2). Bij een goede lichtschakelaar zie je aan de stand of het licht aan hoort (feedforward), gaat het licht meteen aan (feedback) en werkt elke schakelaar in huis gelijk (consistentie). Bij een slecht ontwerp — denk aan een rij identieke schakelaars zonder aanduiding welke welke lamp bedient — kloppen deze principes niet en moet je gokken. Wie een interface beoordeelt, loopt daarom deze vragen langs: laat het systeem vooraf zien wat kan (feedforward), en achteraf wat er gebeurde (feedback)? En komt het gedrag overeen met het model dat de gebruiker waarschijnlijk in zijn hoofd heeft? Deze principes vormen de basis voor het gebruikersgericht ontwerpen in de laatste paragraaf.

De terugkoppelingslus tussen gebruiker en systeem

Afb. 2Afb. 2 — Op de heenweg stuurt feedforward de gebruiker naar de juiste handeling; op de terugweg meldt feedback wat het systeem deed, zodat de lus zich sluit.

Uitgewerkt voorbeeld

Een slecht ontworpen deur analyseren en verbeteren

Aan een glazen deur die je moet duwen, zit aan beide kanten een verticale beugel. Bezoekers trekken er telkens vergeefs aan. Analyseer welke feedforward en feedback ontbreken, betrek het mentale en conceptuele model, en verbeter het ontwerp.

Affordance
De verticale beugel nodigt uit tot pakken en trekken. Voor een deur die geduwd moet worden is dat een verkeerde (valse) affordance: de vorm stuurt de verkeerde handeling.
Signifier ontbreekt
Er is geen zichtbare aanwijzing zoals „DUW” of „TREK” die vertelt wat je moet doen; er is dus geen feedforward.
Feedback
Je merkt pas dát het misgaat nadat je vergeefs hebt getrokken (negatieve feedback achteraf). Het ontwerp stuurt je niet vooraf.
Mentaal versus conceptueel model
De ontwerper weet dat de deur duwt (conceptueel model), maar het systeembeeld — de beugel — communiceert „trekken”, zodat het mentale model van de bezoeker verkeerd wordt.
Verbetering
Vervang de beugel aan de duwzijde door een vlakke duwplaat (affordance = duwen) en houd een echte handgreep alleen aan de trekzijde; voeg eventueel het woord „DUW” toe als signifier.

Resultaat: De vorm van de deur stuurt nu vanzelf de juiste handeling: de affordance klopt, de feedforward is aanwezig en het mentale model van de bezoeker gaat overeenkomen met dat van de ontwerper — de uitvoeringskloof sluit.

Veelgemaakte fouten

Feedback en feedforward door elkaar halen: feedback komt ná de handeling, feedforward vóór of tijdens.
Affordance en signifier gelijkstellen: een affordance is wat een object mogelijk maakt, een signifier is de zichtbare aanwijzing wáár en hóé je moet handelen.
Denken dat „het mentale model” van de ontwerper is; het mentale model is juist dat van de gebruiker, het model van de ontwerper heet conceptueel model.

Actieve herhaling

Noem bij een pinautomaat twee voorbeelden van feedback en één van feedforward, en leg voor elk uit welke kloof het overbrugt.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Interactiestijlen en modaliteiten#

Standaardexamenblad-nl

Een interactiestijl is de manier waarop gebruiker en systeem informatie uitwisselen — de „grammatica” van de bediening. Een modaliteit is het zintuiglijke of fysieke kanaal dat daarbij wordt gebruikt: visueel (beeld), auditief (geluid), tactiel of haptisch (aanraking en trilling) en spraak. Eén principe loopt als een rode draad door alle stijlen: herkennen is makkelijker dan herinneren. Bij een menu zie je de opties staan en hoef je alleen te herkennen wat je zoekt (recognition); bij een opdrachtregel moet je het juiste commando uit je hoofd weten (recall). Dat verschil verklaart voor een groot deel waarom de ene stijl makkelijk te leren is en de andere krachtig maar veeleisend.

De opdrachtregel (command line) is de oudste stijl: je typt commando's in een precieze syntaxis, bijvoorbeeld in een terminal of via SSH naar een server. Ze is krachtig, snel voor wie ze beheerst en laat zich met scripts automatiseren, maar kent een steile leercurve en is foutgevoelig omdat je alles uit je hoofd moet weten. De menugestuurde stijl, meestal in de vorm van WIMP (Windows, Icons, Menus, Pointer), is de klassieke desktop-GUI: je kiest uit zichtbare opties met een muisaanwijzer. Ze leunt op herkenning en is daardoor laagdrempelig en foutarm, maar kan voor ervaren gebruikers traag voelen door het vele klikken en kost schermruimte.

Bij directe manipulatie bewerk je zichtbare objecten rechtstreeks: je sleept een bestand naar de prullenbak, knijpt een foto groter, tikt op een tegel. Kenmerkend zijn de continue weergave van de objecten, snelle omkeerbare acties en een direct zichtbaar resultaat. Dat maakt de stijl intuïtief en snel te leren, met weinig om te onthouden; nadeel is dat niet elke actie een zichtbaar object heeft (abstracte bewerkingen zijn lastig) en dat de precisie soms tekortschiet. Formulieren (form fill-in) zijn een stijl apart: je vult gestructureerde velden in, zoals bij een registratie of bestelling. Ze zijn ideaal voor veel geordende gegevens en maken validatie mogelijk, maar voelen rigide en saai bij lange lijsten.

Bij natuurlijke taal en spraak communiceer je in gewone taal, bijvoorbeeld met een spraakassistent. Het grote voordeel is handenvrije, toegankelijke bediening zonder dat je een „taal” hoeft te leren; de nadelen zijn herkenfouten, dubbelzinnigheid, privacyzorgen en vooral lage vindbaarheid: je ziet niet welke opdrachten mogelijk zijn. Gebaren en touch (tikken, vegen, knijpen) zijn direct en natuurlijk op mobiele apparaten, maar veel gebaren zijn onzichtbaar en moet je leren of onthouden. In de praktijk worden kanalen vaak gecombineerd tot een multimodale interface — een navigatiesysteem dat tegelijk spreekt én een kaart toont — zodat de sterke kanten van meerdere modaliteiten elkaar aanvullen (zie Afb. 3).

Interactiestijlen vergeleken

Afb. 3Afb. 3 — Zes interactiestijlen naast elkaar; directe manipulatie is uitgelicht als de dominante stijl op moderne touchapparaten.

Er bestaat geen „beste” interactiestijl; de juiste keuze hangt af van de gebruiker, de taak en de context. Voor een expert die dag in dag uit dezelfde bewerkingen doet, wint de snelle, scriptbare opdrachtregel; voor een incidentele gebruiker die weinig wil leren, wint een menu of directe manipulatie die op herkenning leunt. De omgeving telt mee: onderweg met één hand is touch handig, in een lawaaierige ruimte werkt spraak slecht, en achter een kassa tellen tempo en foutarme invoer. Bij het beoordelen van een ontwerp vraag je je dus af: wie is de gebruiker, hoe vaak en hoe snel moet de taak gebeuren, en onder welke omstandigheden? De volgende paragraaf laat zien hoe je die vragen systematisch beantwoordt.

Uitgewerkt voorbeeld

Een passende interactiestijl kiezen voor drie situaties

Kies voor (a) een supermarktkassa, (b) een smartphone en (c) het beheer van een webserver telkens een passende interactiestijl en beredeneer je keuze.

a) Supermarktkassa
Kies directe manipulatie via een touchscreen met grote knoppen, aangevuld met een barcodescanner. Wisselend personeel moet met minimale training snel en foutarm werken; herkenning van grote knoppen werkt beter dan een commando onthouden, en scannen houdt het tempo hoog.
b) Smartphone
Kies directe manipulatie met touch en gebaren, aangevuld met spraak. Het scherm is klein en je bedient het onderweg met je vingers; tikken en vegen zijn direct, en spraak biedt handenvrije bediening.
c) Webserverbeheer
Kies de opdrachtregel (via SSH). Het beheer is krachtig, precies en herhaalbaar, laat zich met scripts automatiseren en werkt over het netwerk zonder grafische schil; de beheerder gebruikt het dagelijks, dus het uit het hoofd kennen van commando's is geen bezwaar.
Afweging
Merk op dat de beste keuze per situatie verschilt: dezelfde opdrachtregel die ideaal is voor de server zou aan de kassa veel te traag en foutgevoelig zijn.

Resultaat: Kassa → directe manipulatie op touch; smartphone → directe manipulatie met touch, gebaren en spraak; serverbeheer → opdrachtregel. De keuze volgt telkens uit gebruiker, taak en context, niet uit één „beste” stijl.

Veelgemaakte fouten

„Directe manipulatie” verwarren met „touch”: directe manipulatie is een interactieSTIJL (zichtbare objecten direct bewerken), touch is een MODALITEIT of invoerkanaal.
Denken dat één stijl altijd het beste is; de passendheid hangt af van gebruiker, taak en context.
Spraak of natuurlijke taal overschatten en de lage vindbaarheid en de herkenfouten vergeten.

Actieve herhaling

Kies een passende interactiestijl voor een geldautomaat en voor een fotobewerkingsprogramma, en beredeneer elke keuze met twee argumenten.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Ontwerpen voor gebruikers#

Verdiepingexamenblad-nl

Gebruikersgericht ontwerpen (user-centered design, UCD) plaatst de echte gebruiker, zijn taken en zijn context in het middelpunt van elke ontwerpbeslissing. In plaats van te beginnen bij wat technisch kan of mooi lijkt, begin je bij de vraag: voor wie maken we dit, wat willen die mensen bereiken, en onder welke omstandigheden gebruiken ze het? Gebruikers worden gedurende het hele traject betrokken — je onderzoekt hun behoeften vooraf, en je laat ze tussentijds ontwerpen uitproberen. De aanname erachter is dat ontwerpers slechte voorspellers zijn van wat gebruikers begrijpen: alleen echte mensen die het proberen, onthullen waar het misgaat. Zo voorkomt UCD dat een systeem technisch klopt maar in de praktijk onbruikbaar is.

Een persona is een concreet, verzonnen maar op onderzoek gebaseerd portret van een typische gebruiker. Je geeft hem een naam, leeftijd, doelen, behoeften, context en frustraties, plus een inschatting van zijn digitale vaardigheid. Bijvoorbeeld: „Sanne, 15 jaar, havo-4, wil overzicht over haar toetsen, raakt opdrachten kwijt in een chaotische agenda, gebruikt vooral haar telefoon in korte momenten tussen de lessen.” Het nut van een persona is dat het team voor een specifiek iemand ontwerpt in plaats van voor „de gemiddelde gebruiker” — een fictie die niet bestaat en waarvoor je uiteindelijk voor niemand goed ontwerpt. Een goede persona is scherp en herkenbaar en dwingt keuzes af.

Een gebruiksscenario (of user story) beschrijft in een kort verhaaltje hoe een bepaalde persona het systeem gebruikt om een doel te bereiken in een concrete situatie. Een veelgebruikte vorm is: „Als [persona] wil ik [handeling], zodat [doel].” Bijvoorbeeld: „Als Sanne wil ik na een les binnen tien seconden een opdracht met deadline toevoegen, zodat ik niets vergeet.” Zo'n scenario maakt abstracte wensen concreet en toetsbaar: het benoemt de gebruiker, de taak, de context (staand, met één hand, weinig tijd) en de gewenste uitkomst. Scenario's sturen het ontwerp én leveren later de taken op waarmee je met gebruikers gaat testen.

Ontwerpen gebeurt niet in één rechte lijn maar iteratief: je doorloopt telkens opnieuw de ronde ontwerpen → prototype maken → testen → verbeteren, en elke ronde maakt het ontwerp beter op grond van wat de test liet zien (zie Afb. 4). Cruciaal is dat je toetst met een prototype: een goedkope, voorlopige versie van het ontwerp, zodat je fouten ontdekt vóórdat je het dure echte systeem bouwt. Prototypes kennen een oplopende getrouwheid. Een lo-fi prototype is een papieren schets of wireframe: snel, goedkoop en juist bedoeld om weg te gooien, ideaal om vroeg de indeling en de ideeën te testen. Een hi-fi prototype is een klikbaar, realistisch model (bijvoorbeeld in Figma) waarmee je de details van de interactie beproeft. Vroeg en vaak testen is goedkoper dan één keer laat.

De iteratieve ontwerpcyclus

Afb. 4Afb. 4 — Gebruikersgericht ontwerpen doorloopt de kring behoeften → ontwerp → prototype → testen → verbeteren telkens opnieuw; elke ronde verbetert het ontwerp.

Na elk prototype evalueer je kort met echte gebruikers: je laat een handjevol mensen uit je doelgroep een paar taken uitvoeren en vraagt ze hardop te denken (de hardop-denk-methode). Je let vooral op wáár ze aarzelen of vastlopen — dat wijst je naar de knelpunten. Al enkele gebruikers brengen de meeste grote problemen aan het licht, dus een groot onderzoek is niet nodig om je ontwerp flink te verbeteren. Belangrijk voor de afbakening van dit domein: de formele evaluatiemethoden — zoals de heuristieken van Nielsen en de toegankelijkheidsrichtlijnen (WCAG) — horen bij het keuzethema Usability en komen daar uitgebreid aan bod. In Interactie blijft de nadruk op het ontwerpproces zelf: begrijp je gebruiker, maak iets tastbaars en verbeter het op grond van wat je ziet.

Uitgewerkt voorbeeld

Een persona, gebruiksscenario en eerste prototype opstellen

Je ontwerpt een app die havo-leerlingen helpt hun huiswerk en toetsen bij te houden. Stel een persona en één gebruiksscenario op en beschrijf welke eerste prototype-stap je zou testen.

Persona
„Sanne, 15 jaar, havo-4. Doel: overzicht houden over toetsen en deadlines. Frustratie: raakt opdrachten kwijt in een chaotische papieren agenda. Context: gebruikt vooral haar telefoon, in korte momenten tussen de lessen. Digitale vaardigheid: hoog met apps, maar weinig geduld.”
Gebruiksscenario
„Als Sanne wil ik na een les binnen tien seconden een opdracht met deadline toevoegen, zodat ik niets vergeet.” Dit benoemt de gebruiker, de taak, de context (staand, één hand, weinig tijd) en de gewenste uitkomst.
Eerste prototype (lo-fi)
Teken op papier het scherm „opdracht toevoegen”: één groot invoerveld voor de titel, een eenvoudige datumkiezer en één opvallende plusknop. Papier is goedkoop en snel te wijzigen.
Kort testen
Laat drie klasgenoten uit de doelgroep hardop denken terwijl ze proberen binnen tien seconden een opdracht in te voeren; noteer waar ze aarzelen.
Verbeteren
Blijkt de datumkiezer onduidelijk, vervang die in de volgende iteratie door de snelkeuzes „vandaag / morgen / kies datum” en test opnieuw.

Resultaat: Met een scherpe persona en een concreet scenario ontwerp je gericht; door eerst een papieren prototype te testen ontdek je knelpunten vroeg en goedkoop, precies zoals de iteratieve ontwerpcyclus voorschrijft.

Veelgemaakte fouten

Een persona opschrijven als „de gemiddelde gebruiker”; een persona moet juist specifiek en op onderzoek gebaseerd zijn.
Denken dat één ontwerpronde genoeg is; gebruikersgericht ontwerpen is per definitie iteratief.
Meteen een duur werkend product bouwen in plaats van eerst goedkoop te prototypen en te testen.

Actieve herhaling

Bedenk een persona en één gebruiksscenario voor een app die ouderen helpt hun medicijnen op tijd in te nemen, en beschrijf welk lo-fi prototype je als eerste zou testen.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Referenties en bronnen

Bronnen

CvTE / Examenblad

Examenprogramma informatica (HAVO)

Domein F: Interactie

4 Onderdelen~21 min leestijd4 VaardighedenNiveau Basis 1 · Standaard 2 · Verdieping 1

Domein F: Interactie

Kernpunten

De handelingscyclus toegepast: het volume harder zetten

Kernpunten

Een slecht ontworpen deur analyseren en verbeteren

Kernpunten

Een passende interactiestijl kiezen voor drie situaties

Kernpunten

Een persona, gebruiksscenario en eerste prototype opstellen

Bronnen

Domein F: Interactie

Kernpunten

De handelingscyclus toegepast: het volume harder zetten

Kernpunten

Een slecht ontworpen deur analyseren en verbeteren

Kernpunten

Een passende interactiestijl kiezen voor drie situaties

Kernpunten

Een persona, gebruiksscenario en eerste prototype opstellen

Bronnen