A prototípus egy termék vagy jellemző működőképes közelítése, amelyet egy kérdés megválaszolására terveztek, mielőtt a valódi dolog megépülne. A prototípusok a kézzel manipulált papírvázlatoktól a tervezőeszközben összekapcsolt kattintható képernyőkön át a valós adatokon futó funkcionális kódig terjednek. Ami összeköti őket, az a szándék: a prototípus azért létezik, hogy kiértékeljék és eldobják vagy felülvizsgálják, nem pedig azért, hogy szállítsák.
A lényeg annak eldöntése, hogy a prototípusnak milyen kérdésre kell válaszolnia, mert ez határozza meg a szükséges pontosságot. Annak megállapításához, hogy az emberek megértenek-e egy navigációs struktúrát, elegendő egy összekapcsolt statikus képernyőkészlet. Annak megállapításához, hogy egy interakció eléggé reagálónak tűnik-e, valós időzítésű kódolt prototípusra van szükség, mivel ezt egyetlen statikus műtermék sem tudja közvetíteni. Annak megállapításához, hogy egy összetett adattábla használható-e, realisztikus adatmennyiségek elengedhetetlenek, mivel egy tíz sorral működő táblázat tízezer sorral használhatatlan lehet. A kérdésnél hűségesebb válaszok létrehozása időpazarlás; a kevesebb válasz olyan válaszokat eredményez, amelyek nem kerülnek átvitelre.
A prototípusok azoknál a kérdéseknél a legértékesebbek, amelyeket nem lehet megbeszéléssel eldönteni. A csapatok a végtelenségig vitatkozhatnak arról, hogy egy folyamat túl hosszú-e, hogy egy koncepció érthető-e, vagy hogy egy interakció felfedezhető-e, és semmilyen vita nem oldja meg a problémát, mert mindenki a saját mentális modelljéből indul ki. Ha egy közelítő választ adunk öt, a célközönségnek megfelelő embernek, az általában egy napon belül eldönti a vitát, és gyakran kiderül, hogy mindkét álláspont téves volt, olyan okokból, amelyekre senki sem számított.
A fő kockázat az, hogy a prototípusból lesz a termék. Egy meggyőző prototípus nyomást gyakorol a szállításra, különösen a határidő előtt, és egy kérdés megválaszolására írt kód ritkán olyan kód, amelyet karbantartásra írtak: nincs hibakezelés, nincs akadálymentesítés, nincsenek szélső esetek, nincsenek tesztek. Azok a szervezetek, amelyek ismételten prototípusokat tesznek elérhetővé a gyártásban, a lehető legkevésbé látható módon halmoznak fel technikai adósságot. Az egyetlen megbízható védelem az, ha a prototípus kódját explicit módon eldobhatóként kezelik, és ezt a gyártás előtt ki is mondják.
A második kockázat a túlzott befektetés. A hetekig tartó prototípusok ugyanolyan érzelmi súllyal bírnak, mint a kész munka, és a csapatok vonakodnak feladni egy olyan irányt, amelyet jelentős erőfeszítéssel képviseltek. A prototípusgyártás értéke az olcsó selejtezési lehetőségből fakad, ami azt jelenti, hogy a sebesség inkább funkcionális tulajdonság, mint kényelem. Ha egy prototípus elkészítése tovább tart, mint a funkcióé, akkor a kérdésre másképp kellett volna válaszolni.
Hasznos különbséget kell tenni a felfedezésre és a kommunikációra készült prototípusok között is. A felfedező prototípus egy durva, a csapat számára privát, és a kérdés megválaszolása után elvetendő. Egy kommunikációs prototípust azért építenek, hogy bemutassák a javasolt irányt az érdekelt feleknek, vagy meghatározzák a megvalósításhoz szükséges viselkedést, és teljesebbnek és kidolgozottabbnak kell lennie, mert szó szerint értelmezik. A kettő összekeverése kiszámítható problémákat okoz: a vezetőknek bemutatott felfedező munkát kötelezettségvállalásként értelmezik, a felfedező lazasággal épített kommunikációs prototípusok pedig azt hagyják, hogy a fejlesztők találgassanak az állapotokról és a szélső esetekről, amelyeket soha nem vettek figyelembe. Ha eldöntjük, hogy melyik típust építik, és ezt a bemutatáskor ki is mondjuk, az a legtöbb zavart megelőzi.
A gyakorlatban a prototípusgyártás a tervezés és a megvalósítás metszéspontjában helyezkedik el, és a végeredmény inkább döntés, mintsem egy műtermék. termék dizájn prototípusokat használnak a koncepciók valós felhasználókkal való validálására a specifikáció előtt, míg a termékfejlesztés Emellett arra is használják őket, hogy kockázatmentesítsék a megvalósíthatósággal, teljesítménnyel és integrációval kapcsolatos technikai feltételezéseket, mielőtt elköteleződnénk egy architektúra mellett. Fontos, hogy ez a két cél külön legyen, mivel egy használhatósági kérdésre választ adó prototípusnak és egy technikai kérdésre választ adó prototípusnak ritkán kell ugyanazon dolognak lennie.