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.
- 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.
- Niveau kiezen. Op basis van de vraag wordt bepaald hoe realistisch het model moet zijn, van grijze blokken tot afgewerkte schermen.
- Bouwen. De schermen worden gemaakt en aan elkaar gekoppeld, meestal in ontwerpsoftware waarin klikbare verbindingen kunnen worden gelegd.
- Intern doorlopen. Het team loopt de route zelf door om gaten en doodlopende paden te vinden voordat er iemand van buiten naar kijkt.
- Toetsen. Het prototype wordt voorgelegd aan gebruikers of aan belanghebbenden, afhankelijk van de vraag die eraan ten grondslag lag.
- 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.