Waarom een werkend prototype altijd wint van een specificatiedocument van 50 pagina's

Een 50 pagina's tellend functioneel ontwerp geeft iedereen het gevoel dat het project goed is doordacht. Maar in onze ervaring bij Livewall is dat gevoel zelden terecht. Specificaties beschrijven intenties. Ze leggen vast wat je denkt dat gebruikers willen, wat je denkt dat technisch haalbaar is en wat je denkt dat de business nodig heeft. Al die aannames blijven aannames totdat iemand er daadwerkelijk mee werkt.

Een werkend prototype doorbreekt dat patroon. Niet omdat het alle vragen beantwoordt, maar omdat het de juiste vragen bovendrijft, en dat doet het weken eerder dan een specificatietraject ooit kan.

Wat je leert van klikken dat je niet leert van lezen

Wij bouwen platforms en webapplicaties voor merken als InShared, Sportvisunie en Zorg van de Zaak. In al die trajecten geldt hetzelfde: zodra stakeholders een werkend prototype in handen krijgen, veranderen de gesprekken. Niet omdat het prototype perfect is, maar omdat het concreet is.

Een gebruikersflow die op papier logisch lijkt, voelt in de browser meteen anders. Een knop die op de goede plek staat in een wireframe staat in de praktijk drie stappen te laat in de flow. Die inzichten komen alleen naar boven als je iets bouwt dat je echt kunt gebruiken. Rapid prototyping is voor ons dan ook geen methodiek, het is een manier van denken: bouwen om te leren, niet bouwen om te leveren.

De MVP-aanpak die we bij Livewall hanteren, begint altijd met de vraag: wat is de kleinste werkende versie die ons de meeste informatie geeft? Dat is een andere vraag dan: wat staat er in het programma van eisen?

Waar specificaties wél hun waarde hebben

We zijn niet tegen documentatie. Technische keuzes met langetermijngevolgen, beveiligingsvereisten, integratieafspraken: die hebben een gedeeld begrip nodig dat je zwart op wit vastlegt. Maar dat is iets heel anders dan een volledig uitgespecificeerd functioneel ontwerp als startpunt voor een nieuw product.

Het probleem met een dikke spec aan het begin van een traject is niet dat er te veel nagedacht wordt. Het is dat alle nadenken plaatsvindt voordat iemand ook maar één scherm heeft gezien. Elke beslissing wordt gemaakt op basis van aannames, en hoe langer het document, hoe meer aannames er in worden gebakken.

Bij web application development leren we het meeste in de eerste weken van een traject, juist omdat we dan iets bouwen dat we kunnen testen. Die kennis stuurt alle beslissingen daarna.