Plan gebruikersinterviews met een werkend prototype in 48 uur: snel rekruteren, taakscripts schrijven, notities vastleggen en feedback omzetten in duidelijke bouwverzoeken.
Een werkend prototype legt de meeste discussies snel aan banden. Als iemand een echte taak probeert af te ronden, stop je met raden wat ze zouden doen en begin je te zien wat ze daadwerkelijk doen. Daarom verslaan gebruikersinterviews met een werkend prototype discussies in chat, zelfs als het prototype ruw is.
Met 3 tot 6 sessies kun je veel leren als je de scope strak houdt. Je krijgt geen perfecte statistieken, maar je ziet herhaalde patronen die je deze week kunt oplossen.
In 48 uur kun je betrouwbaar ontdekken waar mensen vastlopen of teruggaan, welke labels ze verwarren, wat ze eerst proberen (en wat ze negeren), wat er mist voordat ze de flow vertrouwen, en welke momenten twijfel oproepen, zoals prijsstelling, toestemmingen of het opslaan van voortgang.
Deze aanpak vermijdt grote onderzoeksprojecten, lange vragenlijsten en open vangstacties. Je probeert niet de hele markt in kaart te brengen. Je probeert de grootste wrijving in één belangrijke flow te verwijderen.
Definieer één leendoel voordat je iemand inplant. Een simpel format werkt goed: “Kan een eerste keer gebruiker X doen in minder dan Y minuten zonder hulp?” Als je een eenvoudige CRM bouwt, kan dat zijn: “Kan een nieuwe gebruiker een contact toevoegen, taggen en het weer terugvinden?”
Als je het prototype snel hebt gebouwd in een tool zoals Koder.ai, blijft het doel hetzelfde: kies één flow, kijk hoe echte mensen het proberen en leg precies vast wat er moet veranderen.
Een 48-uur ronde werkt alleen als je de scope reduceert. Kies één specifiek gebruikerstype en één scenario dat ze al begrijpen. Als je probeert onboarding, prijsstelling, instellingen en randgevallen in één sessie te behandelen, eindig je met meningen in plaats van bewijs.
Schrijf een eentekenzin doel, bijvoorbeeld: “Kan een eerste keer freelance ontwerper een factuur maken en verzenden in minder dan 3 minuten zonder hulp?” Die zin vertelt wie de persoon is, wat ze moeten doen en wat “goed” betekent.
Bepaal wat je gaat meten voordat je met iemand praat. Houd het simpel en zichtbaar tijdens de sessie. Voor de meeste teams is dat een mix van snelheid (tijdsduur om te voltooien), frictie (hoe vaak ze vastlopen of vragen “en nu?”), navigatieproblemen (aarzeling, opnieuw lezen, teruggaan) en vertrouwenstekens (zorgen over betaling, privacy of fouten).
Schrijf daarna 3 tot 5 vragen die je aan het eind van de ronde moet kunnen beantwoorden. Voorbeelden:
Ga niet door met interviewen alleen omdat je kunt. Bepaal van tevoren wanneer je stopt zodat je kunt terugschakelen naar bouwen. Een praktische regel: stop na vijf sessies, of eerder als dezelfde twee belangrijkste issues drie sessies op rij terugkomen.
Voorbeeld: als drie van de vijf deelnemers “Maak factuur” niet kunnen vinden omdat het verborgen zit onder “Betaling”, heb je al een duidelijk bouwverzoek: hernoem het label, verplaats het toegangspunt en test die ene wijziging opnieuw.
Je kunt nuttige gebruikersinterviews met een werkend prototype uitvoeren in twee dagen als je het behandelt als een korte sprint: rekruteren, voorbereiden, uitvoeren en vervolgens synthetiseren terwijl de details vers zijn. Streef naar 3 tot 5 sessies. Drie is het minimum om de grootste problemen te ontdekken. Vijf toont meestal patronen.
Een realistisch plan ziet er zo uit:
Als rekruteren traag gaat, wacht niet. Verminder scope en vergroot beschikbaarheid. Bied meer tijdslots aan (inclusief vroeg in de ochtend of ’s avonds), verkort sessies tot 15 minuten of werf uit een nabijere kring die nog steeds bij je gebruiker past.
Om het georganiseerd te houden, zet voor de eerste call een klein mappensysteem op:
01_Recruiting02_Recordings03_Notes04_Synthesis05_TicketsNoem bestanden bijvoorbeeld P01_2026-01-16_Record.mp4 en P01_Notes.md. Die kleine gewoonte maakt prototype-bruikbaarheidstests later makkelijker te bekijken.
Snelheid telt meer dan perfectie. Je doel is geen statistisch perfecte steekproef. Het zijn 5 tot 8 echte mensen die ongeveer overeenkomen met de gebruikers die je wilt, geboekt binnen een dag.
Begin met de snelste bronnen en verbreed dan. Start met mensen die al om het product vragen (klanten, proefgebruikers, wachtlijst), ga daarna naar recente gesprekken (supportthreads, demo-aanvragen, e-mailreacties). Als je meer nodig hebt, zoek communities waar het probleem besproken wordt, vraag om introducties via vrienden van vrienden (niet om meningen) en benader voormalige collega’s of klanten met dezelfde workflow.
Houd de uitnodiging kort en specifiek. Maak duidelijk dat het geen verkoopgesprek is en dat je het product test, niet de persoon. Geef wat je bouwt en voor wie, de vraag (20 minuten op video of audio), wat ze doen (2 tot 3 taken op een prototype) en een simpel bedankje zoals een kleine cadeaubon, een gratis maand of een donatie. Bied twee tijdbalkopties vandaag of morgen.
Als je snel een intern CRM-prototype hebt gebouwd (bijvoorbeeld in Koder.ai) voor freelancers, nodig zowel “rommelige spreadsheet”-gebruikers uit als mensen die al een CRM gebruiken. Die mix helpt voorkomen dat je alleen feedback van power users krijgt. Vertrouw ook niet alleen op goede vrienden. Die zullen proberen aardig te zijn.
Vergoedingen moeten normaal aanvoelen, niet ongemakkelijk. Een klein vast bedrag werkt beter dan “betaal wat je denkt.” Als je een gratis maand aanbiedt, zorg dat het geen aankoop vereist.
Boek tot slot extra mensen. Streef ernaar twee meer te werven dan je nodig hebt. No-shows gebeuren, en backups houden je schema intact.
Bespaar uren door screening, planning en toestemming als één snelle flow te behandelen. Bevestig dat ze op jouw echte gebruiker lijken, boek een tijd en maak opnemen en notuleren duidelijk voordat je ze ontmoet.
Een lichte screener zijn drie vragen:
Let op rode vlaggen die sessies verspillen. Mensen die ver van je doelgroep zitten geven vol vertrouwen feedback die niet past. Mensen die te betrokken zijn (een goede vriend, een partner, iemand die hetzelfde bouwt) duwen hun persoonlijke agenda. Mensen die te druk zijn zullen haasten, multitasken of niet komen opdagen.
Voor planning: houd het strak: 30-minuten sessies met een buffer van 15 minuten. Die buffer gebruik je om nette notities te schrijven, opnames te benoemen en het prototype te resetten. Als je calls achter elkaar stapelt, worden je notities slordig en mis je patronen.
Toestemming kan één korte boodschap zijn: vraag om opname, leg uit dat notities gebruikt worden om het product te verbeteren en dat citaten geanonimiseerd worden bij delen. Bied een makkelijke opt-out: ze kunnen nee zeggen tegen opnemen en je maakt in plaats daarvan notities.
Stuur een simpele pre-call boodschap met tijd, verwachte lengte, agenda (5 minuten intro, 20 minuten taken, 5 minuten afronding) en wat ze nodig hebben (laptop vs telefoon, inlog als nodig, rustige plek). Dit voorkomt “ik deed het op mobiel”-verrassingen die prototype-bruikbaarheidstests kunnen ontsporen.
Een goed interview kan nog steeds mislukken als het prototype rommelig is. Het doel is niet indruk maken met omvang. Het is dat deelnemers de taken kunnen proberen zonder op doodlopende takken te stuiten of dat jij moet uitleggen.
Houd het prototype klein. Neem alleen de schermen en paden op die je taken vereisen en verberg de rest. Een kortere route verslaat een “volledige app” die half af is.
Laat de inhoud echt voelen. Vervang lorem ipsum door geloofwaardige copy en data zodat gebruikers natuurlijk reageren. Test je een CRM-flow, toon 6 tot 10 contacten met namen, bedrijven en een paar notities. Test je een checkout, gebruik realistische prijzen en bezorgopties. Nep maar specifiek werkt beter dan generiek.
Bepaal vooraf wat je gaat observeren en noteer het elke keer: waar ze als eerste klikken, momenten van verwarring (wat ze zeggen en wat ze daarna doen), waar ze vastlopen of teruglopen, de woorden die ze voor functies gebruiken en vragen die ontbrekende informatie blootleggen.
Zet een dedicated testaccount en een resetroutine op zodat elke deelnemer vanuit dezelfde startpositie begint. Als het prototype records aanmaakt, houd een korte resetchecklist (leeg de winkelwagen, verwijder het laatst aangemaakte item, keer terug naar het startscherm, log uit en opnieuw in).
Kies capture-tools voordat je met iemand praat. Neem het gesprek op als dat kan en houd een simpele notitensjabloon met drie kolommen: Taak, Observaties (wat gebeurde) en Citaten (exacte woorden). Als je Koder.ai gebruikt, maakt het nemen van een snapshot vóór de eerste sessie het makkelijker om terug te rollen als je per ongeluk iets mid-dag verandert.
Een goed taakscrip zorgt dat mensen zich gedragen zoals in het echte leven, niet alsof ze een test afleggen. Houd het kort, herhaalbaar en verbonden aan één hoofdscenario. Voor een werkend prototype zijn 2 tot 4 taken meestal genoeg om patronen te zien zonder dat het gehaast aanvoelt.
Begin met het benoemen van het hoofdschema in eenvoudige woorden (bijv.: “Ik wil mijn eerste project opzetten en een teamgenoot uitnodigen”). Kies daarna taken die de momenten vertegenwoordigen waar falen het meest schade zou doen: eerste keer setup, het vinden van een belangrijke functie en het voltooien van één betekenisvolle actie.
Gebruik elke sessie dezelfde structuur zodat resultaten vergelijkbaar zijn:
Formuleer elke taakprompt zo dat hij niet de knopnaam of het exacte pad verklapt. Fout: “Klik Snapshots en rol terug.” Beter: “Je maakte een fout en wilt terug naar de versie van gisteren. Laat zien wat je zou doen.”
Stel na elke taak één korte vraag. Vooraf: “Waar zou je beginnen?” Achteraf: “Wat maakte dat je dat pad koos?” Als ze vastlopen, vraag “Waar ben je nu naar op zoek?” en niet “Heb je het menu gezien?”
Als je het prototype in Koder.ai hebt gebouwd, koppel taken aan uitkomsten (een app maken, broncode exporteren, een aangepast domein instellen) in plaats van platformtermen. Zo vertalen je notities makkelijker naar bouwverzoeken.
Begin elke sessie op dezelfde manier. Dat verlaagt spanning en maakt resultaten makkelijker vergelijkbaar.
Open met een kort script: bedank ze, leg uit dat je het product test (niet hen) en dat er geen foute antwoorden zijn. Vraag ze hardop te denken en te delen wat ze verwachten voordat ze klikken.
Geef telkens één taak tegelijk en blijf stil. Je hoofdtaak is te observeren waar ze aarzelen en korte, neutrale vragen te stellen zoals “Waar denk je aan?” en “Wat had je verwacht te zien?” Vermijd lesgeven, prijzen of het verdedigen van het prototype.
Als ze vastlopen, duw lichtjes zonder te redden. Een goede aanzet gaat over hun doel, niet de interface: “Wat zou je nu proberen?” of “Waar zou je daarvoor zoeken?” Als ze echt meer dan een minuut blokkeren, ga door en noteer het als een issue met hoge ernst. Weersta de verleiding het prototype tijdens het gesprek te repareren. Leg het vast en ga verder.
Feature-verzoeken zijn nuttig, maar voer er geen discussie over. Zet ze in de wacht met één vraag: “Welk probleem zou dat voor je oplossen?” Ga daarna terug naar de huidige taak.
Sluit ook consistent af. Vraag wat ze leuk vonden, wat hen frustreerde, of ze ervoor zouden betalen (en wat eerlijk voelt) en of je hen later mag contacteren na de volgende update.
Goede notities zijn niet “alles wat er gebeurde.” Het zijn kleine, consistente eenheden die je later kunt sorteren. Als je de structuur hetzelfde houdt over sessies, verschijnen patronen na de derde interview.
Kies één notitendocument of spreadsheet dat elke waarnemer gebruikt. Maak één regel per taakpoging en schrijf korte, feitelijke notities op dezelfde plekken iedere keer. Een simpele indeling:
Tijdstempels laten je terug naar opnames springen en woordkeuzes verifiëren. Taaknummers voorkomen dat je issues door elkaar haalt over flows.
Als iets misgaat, noteer het als één simpele zin die een teamgenoot zonder context kan begrijpen. Noem het moment, niet je interpretatie.
Voorbeeld: “T2 06:14: Klikte op ‘Opslaan’ in de veronderstelling dat er een bevestiging komt, maar er veranderde niets en ze vroegen of het gelukt was.”
Voeg een citaat toe wanneer het de zaak versterkt, vooral bij vertrouwen of verwarring (“Ik weet niet of dit veilig is” of “Waar begin ik?”). Citaten maken prioritering makkelijker omdat ze impact tonen.
Houd tags klein zodat je snel kunt filteren:
Als je prototype in Koder.ai is gebouwd, concentreer notities zich op gebruikersgedrag en productgedrag, niet op hoe het prototype is gegenereerd.
Een laatste regel: als je een notitie niet in een tickettitel kunt omzetten, herschrijf hem totdat je dat wel kunt.
De snelste manier om momentum te verliezen is feedback als citaten en indrukken te bewaren. Zet wat je zag om in bouwverzoeken waar een bouwer zonder te raden mee aan de slag kan.
Begin met het groeperen van issues per taak, niet per persoon. Als drie mensen moeite hadden tijdens “account aanmaken,” is dat één probleem met meerdere gegevenspunten, niet drie afzonderlijke meningen.
Gebruik één consistent verzoekformat zodat elk issue vergelijkbaar is:
Scheid “woordkeuze en duidelijkheid” fixes van “scope”-wijzigingen. “Ik weet niet wat deze knop doet” is vaak een label- of plaatsingsfix. “Ik heb exports, rollen en goedkeuringen nodig” is een grotere productbeslissing. Die mix maakt tickets opgeblazen.
Bepaal daarna voor elk issue: nu fixen, opnieuw testen of parkeren voor later. Een eenvoudige ordeningsmethode is gebruikersimpact, moeite, confidence (herhaalde observatie?) en de volgende actie (bouwen, her-testen of parkeren).
Als je in Koder.ai werkt, schrijf de acceptatiecheck in gewoon Nederlands zodat je het direct in je buildchat als heldere, testbare instructie kunt plakken.
Een niet-technische oprichter bouwt een eenvoudige CRM-onboardingflow in Koder.ai en voert de volgende dag gebruikersinterviews uit. Het doel is smal: kan een salesmedewerker zonder hulp “eerste deal aangemaakt” bereiken.
Rekruteren gaat snel: ze benaderen hun netwerk en een paar lokale sales-communities en bieden een kleine cadeaubon. Vijf salesmedewerkers boeken 20-minuten slots op één middag.
Elke sessie gebruikt dezelfde drie taken, woordelijk voorgelezen:
Over vijf sessies loggen ze herhaalde issues en een paar blockers. Twee reps vinden de import niet. Drie reps denken dat “Reminder” een notificatie-instelling is, niet een follow-up.
Aan het eind van de dag worden die observaties bouwverzoeken die een bouwer direct kan uitvoeren:
Dat is het doel: consistente taken, herhaalde patronen en tickets zo helder geschreven dat ze dezelfde dag nog gebouwd kunnen worden.
De meeste slechte interviewresultaten komen door een paar kleine fouten, niet door het prototype zelf.
Leidende vragen zoals “Dit is logisch toch?” leveren beleefde instemming op. Gebruik neutrale prompts zoals “Wat denk je dat dit doet?” en blijf stil.
Te veel willen testen in één sessie levert oppervlakkige opmerkingen en zwakke signalen op. Kies 2 tot 3 kernflows.
Het script halverwege veranderen breekt vergelijkbaarheid. Zet nieuwe ideeën in een backlog en houd de taken stabiel.
Slordige notities zijn een andere stille mislukking. Vertrouw je geheugen niet: je onthoudt de grappige stukjes, niet de pijnlijke. Noteer precies waar ze vastliepen en wat ze daarna probeerden.
Een simpele realiteitstest: als een deelnemer “Ziet er goed uit” zegt maar 90 seconden nodig heeft om de volgende knop te vinden, zijn hun acties de data. Het compliment is ruis.
Eén luide opinie kan het plan worden. Behandel sterke meningen als hypothesen totdat je hetzelfde probleem in meerdere sessies ziet.
Als je grote aanpassingen maakt, test snel opnieuw. Zelfs twee korte sessies kunnen bevestigen dat je het probleem hebt opgelost in plaats van het te verplaatsen.
Voordat je de eerste call boekt, zet de basis vast:
Direct na elke sessie: doe een drie-minuten check terwijl het vers is: noteer je top drie issues en één verrassing. Als je ze niet kunt noemen, zijn je taken mogelijk te breed of je notities te vaag.
Doe dezelfde dag een korte wrap-up die ruwe notities omzet in beslissingen. Groepeer vergelijkbare problemen, kies wat het meeste telt en definieer wat je hierna gaat veranderen.
Plan daarna een her-test binnen 72 uur na het uitrollen van fixes. Zelfs drie korte sessies kunnen bevestigen of de wijziging heeft geholpen.
Als je in Koder.ai itereert (Koder.ai), kan Planning Mode helpen je bevindingen te herschrijven als afgebakende taken (“Verander X zodat gebruiker Y kan doen zonder Z”), en snapshots maken het makkelijk om snel fixes te proberen zonder een stabiele versie kwijt te raken.
Streef naar 3 tot 5 sessies. Drie onthult meestal de grootste blokkades, en vijf is vaak genoeg om patronen te bevestigen. Stop eerder als dezelfde twee topissues drie sessies op rij terugkomen, en ga dan weer bouwen en opnieuw testen.
Gebruik één zin die de gebruiker, de taak en een meetbare norm noemt. Een goed format is: “Kan een eerste keer [gebruikertype] [taak] doen in minder dan [tijd] zonder hulp?” Dat houdt de sessie gericht op observeerbaar gedrag.
Kies 2 tot 4 taken die de belangrijkste momenten in één flow vertegenwoordigen, zoals de eerste setup en het afronden van één betekenisvolle actie. Maak de taken resultaatgericht zodat je test of mensen kunnen slagen, niet of ze een specifieke knopnaam vinden.
Begin met de snelste bronnen: mensen die al dicht bij het product staan, zoals proefgebruikers, wachtlijstinschrijvingen, recente supportgesprekken of demo-aanvragen. Houd de uitnodiging kort, maak duidelijk dat het geen verkooppraatje is en bied twee concrete tijdopties vandaag of morgen.
Stel drie korte vragen: wat gebruiken ze nu, wat gebeurde er de laatste keer dat ze de taak deden, en welke rol beschrijft hen het beste (en waarom). Vermijd mensen die ver van je doelgroep zitten, te betrokken zijn (dichte vrienden of concurrenten) of te druk om zich te concentreren.
Vraag om toestemming om op te nemen, vertel waarvoor de opname en aantekeningen gebruikt worden (het product verbeteren) en zeg dat citaten geanonimiseerd worden bij het delen van inzichten. Geef een makkelijke opt-out: ze kunnen opname weigeren en nog steeds meedoen terwijl je notuleert.
Beperk het prototype tot alleen de schermen die je taken nodig hebben en laat de inhoud echt aanvoelen, zodat mensen natuurlijk reageren. Maak een testaccount en een eenvoudige resetroutine zodat elke deelnemer vanuit dezelfde staat begint — dat maakt resultaten vergelijkbaar.
Voer elke sessie hetzelfde uit: dezelfde intro, dezelfde taken en vooral stilte terwijl ze werken. Stel neutrale vragen zoals “Waar ben je nu naar op zoek?” en vermijd lesgeven of het verdedigen van het ontwerp — dat verbergt waar het product echt faalt.
Schrijf korte, consistente notities per taakpoging: wat ze probeerden, wat ze verwachtten en wat er gebeurde, plus één citaat wanneer dat relevant is. Voeg een simpele severity-tag toe (blokkeert, vertraagt, klein) zodat je snel kunt prioriteren terwijl het bewijs nog vers is.
Maak van elk herhaald probleem een bouwverzoek met vijf onderdelen: het probleem, het bewijs, de impact, een voorgestelde wijziging en een simpele acceptatiecheck die je in de volgende test kunt verifiëren. Groepeer issues per taak in plaats van per deelnemer zodat één probleem niet als vijf meningen wordt behandeld.