Een prototype is een werkende benadering van een product of functie, gemaakt om een vraag te beantwoorden voordat het uiteindelijke product wordt gebouwd. Prototypes variëren van met de hand bewerkte schetsen op papier, via klikbare schermen die in een ontwerptool zijn gekoppeld, tot functionele code die draait op echte data. Wat ze gemeen hebben, is de intentie: een prototype is bedoeld om te worden geëvalueerd en vervolgens te worden afgekeurd of herzien, niet om te worden uitgebracht.
De essentiële discipline is bepalen welke vraag het prototype moet beantwoorden, want dat bepaalt de vereiste mate van detail. Om te leren of mensen een navigatiestructuur begrijpen, volstaat een set gekoppelde statische schermen. Om te leren of een interactie responsief genoeg aanvoelt, is een gecodeerd prototype met realistische timing nodig, omdat geen enkel statisch artefact dit kan overbrengen. Om te leren of een complexe gegevenstabel bruikbaar is, zijn realistische gegevensvolumes essentieel, aangezien een tabel die werkt met tien rijen mogelijk onbruikbaar is met tienduizend. Meer detail bouwen dan de vraag vereist, is tijdverspilling; minder detail levert antwoorden op die niet overdraagbaar zijn.
Prototypes zijn het meest waardevol voor vragen die niet door discussie kunnen worden opgelost. Teams kunnen eindeloos discussiëren over de vraag of een workflow te lang is, of een concept begrijpelijk is, of een interactie wel te ontdekken is, en geen enkele discussie lost het op omdat iedereen vanuit zijn eigen mentale model redeneert. Door een benadering voor te leggen aan vijf mensen die de doelgroep vertegenwoordigen, is de discussie doorgaans binnen een dag beslecht en blijkt vaak dat beide standpunten onjuist waren om redenen die niemand had voorzien.
Het grootste risico is dat een prototype het product wordt. Een overtuigend prototype zet druk op om het te lanceren, vooral onder tijdsdruk, en code die geschreven is om een vraag te beantwoorden, is zelden code die onderhouden moet worden: geen foutafhandeling, geen toegankelijkheid, geen rekening gehouden met uitzonderlijke gevallen, geen tests. Organisaties die herhaaldelijk prototypes naar productie brengen, bouwen op de minst zichtbare manier technische schuld op. Het expliciet beschouwen van prototypecode als wegwerpbaar, en dit ook aangeven vóór de implementatie, is de enige betrouwbare bescherming.
Een tweede risico is overinvestering. Prototypes die weken in beslag nemen om te bouwen, hebben dezelfde emotionele waarde als het uiteindelijke product, waardoor teams terughoudend worden om een richting los te laten waar ze veel tijd en energie in hebben gestoken. De waarde van prototyping schuilt in de mogelijkheid om prototypes goedkoop te vervangen, wat betekent dat snelheid een functionele eigenschap is in plaats van een gemak. Als het bouwen van een prototype langer duurt dan de uiteindelijke functionaliteit, had de vraag op een andere manier beantwoord moeten worden.
Er is ook een nuttig onderscheid tussen prototypes die zijn ontworpen om te verkennen en prototypes die zijn ontworpen om te communiceren. Een verkennend prototype is ruw, alleen voor het team beschikbaar en wordt weggegooid zodra de vraag is beantwoord. Een communicatieprototype is ontworpen om een voorgestelde richting aan stakeholders te demonstreren of om gedrag voor implementatie te specificeren. Het moet completer en verfijnder zijn, omdat het letterlijk zal worden geïnterpreteerd. Het verwarren van de twee leidt tot voorspelbare problemen: verkennend werk dat aan leidinggevenden wordt getoond, wordt gezien als een toezegging, en communicatieprototypes die met een verkennende, losse aanpak zijn gebouwd, laten ontwikkelaars in het ongewisse over mogelijke scenario's en randgevallen die nooit zijn overwogen. Door te bepalen welk type prototype wordt gebouwd en dit ook te vermelden tijdens de presentatie, wordt de meeste verwarring voorkomen.
In de praktijk bevindt prototyping zich op het snijvlak van ontwerp en realisatie, en de output ervan is een beslissing in plaats van een tastbaar product. productontwerp Bij betrokkenheid worden prototypes gebruikt om concepten te valideren met echte gebruikers voordat ze worden gespecificeerd, terwijl in productontwikkeling Ze worden ook gebruikt om technische aannames over haalbaarheid, prestaties en integratie te toetsen voordat er voor een architectuur wordt gekozen. Het is belangrijk om deze twee doelen gescheiden te houden, aangezien een prototype dat een gebruiksvriendelijkheidsvraag beantwoordt en een prototype dat een technische vraag beantwoordt zelden hetzelfde hoeven te zijn.