Prototyyppi on tuotteen tai ominaisuuden toimiva approksimaatio, joka on rakennettu vastaamaan kysymykseen ennen varsinaisen tuotteen rakentamista. Prototyypit vaihtelevat käsin muokatuista paperiluonnoksista suunnittelutyökaluun linkitettyihin klikattaviin näyttöihin ja toiminnalliseen koodiin, joka toimii oikeita tietoja vasten. Niitä yhdistää tarkoitus: prototyyppi on olemassa arvioitavaksi ja hylättäväksi tai tarkistettavaksi, ei toimitettavaksi.
Olennaista on päättää, mihin kysymykseen prototyypin on vastattava, koska se määrittää vaadittavan tarkkuuden. Jotta voidaan selvittää, ymmärtävätkö ihmiset navigointirakenteen, joukko linkitettyjä staattisia näyttöjä riittää. Jotta voidaan selvittää, tuntuuko vuorovaikutus riittävän reagoivalta, tarvitaan reaaliaikaisesti koodattu prototyyppi, koska mikään staattinen artefakti ei voi välittää sitä. Jotta voidaan selvittää, onko monimutkainen datataulukko käyttökelpoinen, realistiset datamäärät ovat välttämättömiä, koska kymmenellä rivillä toimiva taulukko voi olla käyttökelvoton kymmenellä tuhannella rivillä. Kysymystä tarkemman vastauksen rakentaminen vie aikaa; vähemmän vastauksen rakentaminen tuottaa vastauksia, jotka eivät siirry.
Prototyypit ovat arvokkaimpia kysymyksissä, joita ei voida ratkaista keskustelulla. Tiimit voivat väitellä loputtomiin siitä, onko työnkulku liian pitkä, onko käsite ymmärrettävä vai onko vuorovaikutus löydettävissä, eikä mikään määrä väittelyä ratkaise asiaa, koska kaikki päättelevät oman ajatusmallinsa pohjalta. Arvioidun lähestymistavan esittäminen viidelle kohdeyleisöön sopivalle henkilölle ratkaisee väittelyn tyypillisesti päivässä ja paljastaa usein, että molemmat kannat olivat vääriä syistä, joita kukaan ei osannut ennakoida.
Suurin riski on, että prototyypistä tulee tuote. Vakuuttava prototyyppi luo painetta toimittaa se, erityisesti määräaikaan mennessä, ja kysymykseen vastaamiseksi kirjoitettu koodi on harvoin kirjoitettu ylläpidettäväksi: ei virheenkäsittelyä, ei saavutettavuutta, ei reunatapauksia, ei testejä. Organisaatiot, jotka toistuvasti edistävät prototyyppien tuotantoon siirtymistä, kerryttävät teknistä velkaa mahdollisimman vähän näkyvällä tavalla. Ainoa luotettava suoja on käsitellä prototyyppikoodia nimenomaisesti kertakäyttöisenä ja sanoa se ennen sen rakentamista.
Toinen riski on yli-investointi. Prototyypeillä, joiden rakentaminen kestää viikkoja, on sama emotionaalinen painoarvo kuin valmiilla työllä, ja tiimit alkavat haluta luopua suunnasta, jota he ovat edustaneet merkittävästi. Prototypointin arvo tulee siitä, että se voidaan hylätä edullisesti, mikä tarkoittaa, että nopeus on toiminnallinen ominaisuus eikä niinkään mukavuus. Jos prototyypin rakentaminen kestää kauemmin kuin ominaisuuden rakentaminen, kysymykseen olisi pitänyt vastata toisella tavalla.
On myös hyödyllinen ero tutkimista varten rakennettujen prototyyppien ja kommunikointia varten rakennettujen prototyyppien välillä. Tutkiva prototyyppi on karkea, tiimin oma ja hylätään, kun kysymykseen on vastattu. Viestintäprototyyppi rakennetaan esittelemään ehdotettua suuntaa sidosryhmille tai määrittelemään toteutusta varten tarvittava toimintatapa, ja sen on oltava täydellisempi ja hiotumpi, koska se tulkitaan kirjaimellisesti. Näiden kahden sekoittaminen aiheuttaa ennustettavia ongelmia: johtajille esitetty tutkiva työ tulkitaan sitoumukseksi, ja tutkivalla löyhyydellä rakennetut viestintäprototyypit jättävät kehittäjät arvailemaan tiloja ja reunatapauksia, joita ei ole koskaan harkittu. Päättämällä, minkä tyyppistä prototyyppiä rakennetaan, ja kertomalla siitä esittelyn yhteydessä, estetään suurin osa tästä sekaannuksesta.
Käytännössä prototyyppien valmistus sijoittuu suunnittelun ja toimituksen risteykseen, ja sen lopputulos on pikemminkin päätös kuin artefakti. tuotesuunnittelu prototyyppejä käytetään konseptien validointiin oikeiden käyttäjien kanssa ennen määrittelyä, kun taas tuotekehitys Niitä käytetään myös teknisten oletusten toteutettavuuden, suorituskyvyn ja integroinnin riskien poistamiseen ennen arkkitehtuuriin sitoutumista. Näiden kahden tarkoituksen pitäminen erillään on tärkeää, koska käytettävyyskysymykseen vastaavan prototyypin ja tekniseen kysymykseen vastaavan prototyypin on harvoin oltava sama asia.