Prototyping

Een prototype is een klikbaar model van een website of app waarin je de werking kunt ervaren zonder dat er iets gebouwd is. Het varieert van een ruwe schets waarmee je door schermen kunt klikken tot een model dat nauwelijks van de echte site te onderscheiden is. Het doel is aannames toetsen en misverstanden opsporen voordat het duur wordt om nog van richting te veranderen.

Wat is prototyping?

Een prototype is een klikbaar model van een website of app: schermen die aan elkaar zijn gekoppeld zodat je er doorheen kunt navigeren alsof het een werkende site is, terwijl er in werkelijkheid niets achter zit. Je klikt op een knop en er verschijnt een volgend scherm, maar er wordt niets opgeslagen, verstuurd of berekend. Het is een geloofwaardige buitenkant zonder binnenkant.

Het bestaansrecht van die constructie is dat je er iets mee kunt uitproberen op een moment dat veranderen nog weinig kost. Een misverstand dat in een prototype naar boven komt, kost een middag aanpassen; hetzelfde misverstand dat pas na de bouw aan het licht komt, kost aanpassing van ontwerp, code en test. Prototyping is daarmee vooral een manier om risico naar voren te halen, naar de fase waarin het nog goedkoop is.

Prototypes bestaan in verschillende gradaties van realisme. Aan de ene kant staan ruwe modellen van grijze blokken zonder opmaak, waarin alleen de route te volgen is. Aan de andere kant staan modellen die nauwelijks van de echte site te onderscheiden zijn, met definitieve kleuren, teksten en animaties. Hoe realistischer, hoe meer tijd het kost, en hoe meer commentaar je krijgt over vormgeving in plaats van over werking. Het kiezen van het juiste niveau is een vak op zich.

Wat valt er precies onder?

Prototyping omvat het bouwen van het model, maar ook het bepalen wat er precies in moet en wat bewust wordt weggelaten.

  • Vraag afbakenen: vaststellen welke aanname of welk knelpunt getoetst moet worden, want dat bepaalt wat het prototype moet kunnen.
  • Routekeuze: bepalen welke weg door de site wordt uitgewerkt, in plaats van alles na te bouwen.
  • Schermen opbouwen: de benodigde pagina’s maken, in het gekozen niveau van detail.
  • Koppelen en interactie: knoppen en links aan elkaar knopen zodat de route klikbaar wordt, inclusief overgangen waar die iets toevoegen.
  • Realistische inhoud: echte of geloofwaardige teksten en gegevens gebruiken, omdat opvultekst het oordeel van testdeelnemers vertekent.
  • Varianten: waar nodig twee versies van hetzelfde scherm, om ze naast elkaar te kunnen voorleggen.
  • Foutsituaties: schermen voor wat er gebeurt als iets misgaat, want juist daar lopen mensen in de praktijk vast.
  • Documentatie voor de bouw: aantekeningen bij het model over gedrag dat niet uit de klikbare versie blijkt.

Hoe verloopt een prototypetraject?

Prototyping is zelden een enkele stap; het werkt in rondes, waarbij elk model iets toetst en de uitkomst het volgende model stuurt.

  1. Vraag bepalen. Er wordt vastgelegd wat het prototype moet aantonen of weerleggen. Zonder die vraag ontstaat een model dat alles half kan en niets bewijst.
  2. Niveau kiezen. Op basis van de vraag wordt bepaald hoe realistisch het model moet zijn, van grijze blokken tot afgewerkte schermen.
  3. Bouwen. De schermen worden gemaakt en aan elkaar gekoppeld, meestal in ontwerpsoftware waarin klikbare verbindingen kunnen worden gelegd.
  4. Intern doorlopen. Het team loopt de route zelf door om gaten en doodlopende paden te vinden voordat er iemand van buiten naar kijkt.
  5. Toetsen. Het prototype wordt voorgelegd aan gebruikers of aan belanghebbenden, afhankelijk van de vraag die eraan ten grondslag lag.
  6. Bijstellen of overdragen. Op basis van de bevindingen volgt een nieuwe ronde, of het model gaat als specificatie naar het ontwikkelteam.

Wanneer heb je dit nodig?

Prototyping is het nuttigst bij iets nieuws waarover onzekerheid bestaat: een bestelproces dat anders wordt opgezet, een configurator, een portaal met stappen die niemand eerder zo heeft gemaakt. Hoe groter de onzekerheid, hoe meer een klikbaar model oplevert ten opzichte van een beschrijving op papier.

Een tweede aanleiding is onenigheid binnen een team. Discussies over hoe iets zou moeten werken, zijn met woorden vaak onbeslisbaar, omdat iedereen zich er iets anders bij voorstelt. Een klikbaar model maakt in tien minuten duidelijk waar de verschillen zitten, en verplaatst het gesprek van meningen naar iets waar iedereen naar kijkt.

Verder is het gebruikelijk als voorbereiding op usability-onderzoek, omdat je zonder werkende site toch met echte gebruikers kunt testen. En bij grote of risicovolle projecten wordt het ingezet om een investering te onderbouwen: het is aanzienlijk goedkoper om een prototype af te keuren dan een gebouwde applicatie.

Wat levert het op?

Een prototype levert vooral zekerheid op voordat er geld naar de bouw gaat. Het maakt misverstanden zichtbaar die in een statisch ontwerp of in een functionele beschrijving verborgen blijven, omdat mensen pas bij het doorklikken merken dat ze zich iets anders hadden voorgesteld. Voor teams werkt het bovendien als gemeenschappelijke taal: het scheelt vergaderingen als iedereen naar hetzelfde model kan wijzen.

De beperkingen zijn even belangrijk. Een prototype zegt niets over hoe de site presteert bij echte hoeveelheden gegevens, of de techniek eronder haalbaar is of hoe hij zich houdt bij drukte. Het reageert volgens een script, niet op werkelijke invoer, waardoor foutafhandeling en randgevallen grotendeels buiten beeld blijven. Er is ook een valkuil aan de kant van de opdrachtgever: een realistisch prototype voelt bijna af, waardoor de indruk ontstaat dat het meeste werk gedaan is. In werkelijkheid begint het bouwen dan nog.

Waar let je op als je dit uitbesteedt?

Vraag welke route wordt uitgewerkt en welke bewust niet. Een prototype dat de hele site nabootst is duur en zelden nodig; een goed afgebakend model van de belangrijkste route levert meer op tegen minder kosten. Vraag ook welk niveau van realisme wordt gekozen en waarom, want dat is de post die de doorlooptijd het sterkst bepaalt.

Let daarnaast op wat er met het model gebeurt na de toetsing. Vraag of het wordt bijgewerkt na de gevonden bevindingen of dat het daarna vervalt, en in welke vorm het ontwikkelteam de specificatie krijgt. Vraag ook of je zelf toegang houdt tot de bestanden, want een prototype dat alleen bij het bureau leeft, is later niet te hergebruiken. Vraag ten slotte of het testen met gebruikers is inbegrepen of dat de opdracht eindigt bij het opleveren van het model.

Veelgemaakte fouten

Prototypes lopen zelden mis in de uitvoering, maar wel in de verwachtingen die eraan worden gehangen.

  • Te realistisch te vroeg. Een afgewerkt ogend model lokt commentaar op kleuren en lettertypes uit, terwijl de vraag over de werking ging.
  • Geen vraag vooraf. Een prototype zonder duidelijke aanname om te toetsen wordt een dure tekening waar niemand een besluit op baseert.
  • Het model verwarren met de bouw. Omdat een prototype werkend oogt, wordt de resterende ontwikkeltijd stelselmatig onderschat door opdrachtgevers.
  • Opvultekst gebruiken. Onzinteksten maken schermen ruimer en overzichtelijker dan ze met echte inhoud zullen zijn, wat het oordeel vertekent.

Wat bepaalt de prijs?

De prijs volgt vrijwel recht uit het aantal schermen en het gekozen realisme. Elke variant, elke foutmelding en elk alternatief pad is in een prototype een apart scherm dat gemaakt en gekoppeld moet worden.

Wat de prijs opdrijft Waarom het meetelt
Aantal schermen en routes Elke afsplitsing in het pad verdubbelt het aantal schermen dat gemaakt en gekoppeld moet worden.
Niveau van realisme Een ruw model van grijze blokken kost een fractie van de tijd van een afgewerkt ogend prototype.
Aantal iteratierondes Elke toetsronde levert bijstellingen op, en dat bijwerken is telkens opnieuw werk aan het model.
Complexiteit van de interactie Animaties, sleepgedrag en schermen die op invoer reageren, vragen aanzienlijk meer opbouwwerk dan simpele doorklikken.

Prototyping wordt zelden apart gefactureerd en zit meestal verwerkt in een ontwerptraject, waar het als tussenstap tussen wireframes en definitief ontwerp fungeert. Waar het wel los wordt aangeboden, gebeurt dat op projectbasis voor een afgesproken aantal schermen, of op uurbasis wanneer vooraf onduidelijk is hoeveel rondes er nodig zijn. Vraag bij een offerte voor een compleet ontwerp expliciet of er een klikbaar model bij zit, want dat scheelt in wat je vooraf kunt beoordelen.

Prototyping en aanverwante diensten

Prototyping is een tussenstap en hangt daardoor aan meerdere diensten vast. Webdesign levert de schermen waaruit een prototype wordt opgebouwd, en het prototype toetst op zijn beurt of die schermen als route werken. Usability-testen is de belangrijkste afnemer: een klikbaar model is het materiaal waarmee je kunt testen voordat er gebouwd is. Informatiearchitectuur gaat eraan vooraf, omdat de routes in een prototype de structuur volgen die daar is vastgelegd. Interactie en motion raakt eraan waar het prototype ook overgangen en bewegingen laat zien, wat vaak de enige manier is om die vooraf te beoordelen. En frontend-development gebruikt het model als specificatie voor wat er precies gebouwd moet worden. Vrijwel elk bureau dat webdesign aanbiedt, werkt met prototypes, al verschilt het sterk hoe ver ze worden uitgewerkt.

Veelgestelde vragen

Wat is het verschil tussen een wireframe en een prototype?

Een wireframe is een statische schets van één pagina: wat staat waar, zonder kleur en zonder definitief beeld. Een prototype koppelt schermen aan elkaar zodat je erdoorheen kunt klikken en de route kunt ervaren. Het verschil is dus beweging: een wireframe laat zien hoe een pagina is ingedeeld, een prototype laat zien hoe het voelt om er doorheen te gaan. Veel prototypes zijn gemaakt van wireframes die aan elkaar zijn geknoopt.

Hoe realistisch moet een prototype zijn?

Dat hangt af van de vraag die je wilt beantwoorden. Wil je weten of mensen de structuur begrijpen, dan volstaat een ruw model zonder opmaak, en dat heeft zelfs een voordeel: deelnemers geven dan commentaar op de werking in plaats van op de kleuren. Wil je toetsen of een ontwerp vertrouwen wekt of hoe mensen op detailniveau reageren, dan is een realistischer model nodig. Realistischer betekent altijd meer tijd, dus maak het zo ruw als de vraag toelaat.

Kan een prototype worden hergebruikt als basis voor de bouw?

Meestal niet als code. Prototypes worden doorgaans gemaakt in ontwerpsoftware zoals Figma, en die bestanden zijn geen bruikbare basis voor een developer om op voort te bouwen. Wat wel wordt hergebruikt, is de inhoud ervan: schermen, componenten en de vastgelegde interacties dienen als specificatie voor de bouw. Er bestaan ook prototypes die in echte code worden gemaakt; die zijn soms deels herbruikbaar, maar kosten aanzienlijk meer tijd om te maken.

Is een prototype hetzelfde als een demo?

Nee, al worden ze vaak door elkaar gebruikt. Een prototype is een onderzoeksmiddel: het bestaat om iets te toetsen en mag daarna weg. Een demo is een presentatiemiddel, bedoeld om iets te laten zien aan een opdrachtgever of investeerder. Het verschil zit in de intentie, en dat maakt uit voor hoeveel werk erin gaat zitten. Een prototype dat vooral bedoeld is om indruk te maken, is meestal geen goed onderzoeksinstrument meer.

Werkt een prototype met echte gegevens?

Doorgaans niet. In een prototype staat verzonnen of gekopieerde inhoud, en de schermen reageren volgens een vast script in plaats van op werkelijke invoer. Dat is precies de beperking: zaken als traagheid bij veel gegevens, foutmeldingen bij verkeerde invoer of het gedrag bij lege lijsten laten zich er slecht mee onderzoeken. Voor dat soort vragen is een werkende testversie nodig. Gebruik in een prototype wel realistische inhoud in plaats van opvultekst, want dat beïnvloedt hoe mensen erop reageren.

Hoe lang duurt het maken van een prototype?

Een ruw model van een handvol schermen is een kwestie van dagen; een realistisch prototype van een compleet bestelproces kost weken. De grootste factor is het aantal schermen en het aantal routes dat erin moet zitten, want elke variant en elke foutsituatie is een apart scherm. Daarom is het verstandig om vooraf af te bakenen welke route je wilt toetsen, in plaats van de hele site na te bouwen in ontwerpsoftware.