Het klinkt simpel: vraag ze om feedback. Maar in de praktijk gaat er veel mis tussen het moment dat een idee wordt geopperd en het moment dat een product in gebruik is. Vergaderingen worden gevuld met aannames. Documenten stapelen zich op. En pas als het te laat is — als het product al gebouwd is — blijkt dat de gebruiker iets heel anders nodig had.
Rapid prototyping keert de volgorde om. In plaats van jarenlang bouwen voordat iemand het ziet, maak je in dagen een werkende versie en laat je echte gebruikers ermee werken. De feedback die je dan krijgt is concreet, direct en bruikbaar. Vraag ze vroeg en vaak om feedback en verwerk deze zo snel mogelijk.
Rapid prototyping werkt omdat het risico-gebaseerd is — alle betrokken partijen kunnen hun risico's inbrengen. Het stelt de gebruiker centraal, het product vormt de kern van de ontwikkeling, en je kunt snel bijsturen terwijl stakeholders betrokken blijven.
We namen onze eigen tool als voorbeeld: Examenbaas. Een website waar leerlingen Nederlands VWO-eindexamens kunnen oefenen, met AI-gegenereerde hints per vraag en een docentenoverzicht. We bouwden een eerste versie in enkele dagen. Niet mooi. Niet af. Maar werkend genoeg om te testen.
Hieronder zie je die eerste versie. Gebruik het zoals een leerling dat zou doen. Wat valt je op?
De feedback was direct en ongezoet. Zes observaties — van een tikfout tot een fundamenteel probleem met hints die het antwoord al weggeven. Dit is precies de bedoeling: je leert meer uit vijf minuten gebruikerstest dan uit vijf vergaderingen.
Maar rapid prototyping heeft ook beperkingen. Veiligheid, privacy en ethiek zijn harde grenzen. Daarnaast spelen er belangen buiten het directe product: efficiënte bedrijfsvoering, wetenschappelijke verantwoording, beschikbaarheid van data voor onderzoek. Nieuwe features botsen soms met privacy & security — dat is een afweging die je bewust moet maken.
De developer verwerkte drie verbeteringen. Niet alles, bewust. Rapid prototyping is ook kiezen: wat heeft nu de meeste impact? Kijk eerst naar de kern, verdeel dat in kleine stukken, en itereer.
Probeer het opnieuw. Merk je het verschil? En: wat is nu het grootste risico? Moet het helemaal anders?
Sommige post-its kwamen terug. De tikfout stond er nog. Dat is geen falen — dat is het proces. Niet alles kan in één ronde worden opgelost. Je kiest telkens wat nu het meest waarde toevoegt.
De aanpak: kijk eerst naar de kern. Verdeel dat in kleine stukken. Itereer. En blijf de NOLAI-driehoek in de gaten houden: onderzoek, onderwijs en technologie in balans. Iedereen moet meedoen en zijn rol kennen — het bedrijf moet kritiek aankunnen, de begeleider moet niet focussen op de dingen die er niet toe doen maar feedback geven op wat we aan het itereren zijn.
De eindversie laat zien hoeveel er in twee iteraties kan veranderen zonder de kern aan te raken. Timer. Markeringen. Individuele leerlingresultaten voor de docent. Het is nu een veel bruikbaarder product waarbij de basis niet veel veranderde, maar we door te prototypen konden zien wat wel en niet werkt.
Welke post-its zie je terug? Wat zou je in een derde ronde aanpakken?
Bouw iets en demo het — ook als het nog niet af is. Paper prototyping telt ook: zelfs een schets op papier is een prototype. Zorg dat alle partijen meedoen: developer, opdrachtgever én gebruiker. En organiseer je feedbackloop.
Dus: bouw iets en demo het. Zorg dat alle partijen meedoen. Organiseer je feedbackloop. Over feedback gesproken — mail ons.
