Prototyyppaus - luonnostelua

Prototyyppaus eli prototyypin rakentaminen on tehokas ja toimiva tapa testata erilaisia ideoita ja iteroida niitä paremmiksi. Tyypillisesti prototyypillä pyritään kokeilemaan jotain selkeää osakokonaisuutta, ei koko tuotetta. Näitä osa-alueita voivat olla esimerkiksi käyttöliittymään liittyvät seikat, liikkumisen luontevuus tai erilaiset tavat esittää tilastodataa.

Prototyyppi voi periaatteessa toimia alustana varsinaiselle tuotteelle. Usein prototyypit pidetään kuitenkin erillisinä tuotantoina, joiden koodia ei sellaisenaan käytetä varsinaisessa tuotteessa. Tällä mahdollistetaan nopea ja "sotkuinen" prototyyppaus, jossa ei tarvitse keskittyä koodin tai muun tuotannon kauneuteen tai rakenteeseen, vaan pyritään ratkaisemaan se ongelma, jonka tutkimiseen prototyyppi on rakennettu. Toisinaan näistä irrallisista, nopeista prototyypeistä käytetään myös nimitystä spike.

Analogi, digitaali, simulaati

Protoilua voidaan suorittaa useilla eri tavoilla, joista protoilijoiden täytyy löytää tilanteeseen sopivin menetelmä. Mikäli tutkitaan esimerkiksi strategiapelin osumatodennäköisyyksiä tai kykyjen tasapainotusta, saattaa taulukkolaskentaohjelmalla toteutettu laskukaavasto ja taulukosto olla paras metodi. Tosiaikaisten pelien ohjaustuntumaa protoillessa tarvitaan toimivaa digitaalista prototyyppiä. Käyttöliittymien testaamiseen voi käyttää esimerkiksi Wizard of Oz -menetelmää tai paperiprotoilua, joka toimii mainiosti myös vuoropohjaisten pelien mekaniikan testaamiseen. Flashilla tai muilla vastaavilla nopean kehityksen välineillä voi kätevästi testailla tavallista monipuolisempia interaktiomalleja ja käyttöliittymäkomponentteja.

Välineen valinnassa kannattaa käyttää harkintaa. Paperiproto on nopea tehdä ja muutella, mutta sen rajat tulevat nopeasti vastaan. Digitaalisen prototyypin tekeminen saattaa viedä päiviä, eikä sen muuntelu ole välttämättä kovin nopeaa. Taulukkolaskentaohjelmalla on kömpelö kokeilla muuttuvia käyttöliittymiä. Tärkeintä menetelmän valinnassa on käyttää sitä välinettä, jolla nopeimmin pystyy toteuttamaan halutut toiminnot. Mikäli prototypointi sisältää paljon muuttujien säätämistä, kannattaa säätimet tuoda käyttäjien näkyville, jotta virittely käy nopeasti ja tehokkaasti. Esimerkiksi autopelin kitkan, ohjausnopeuden ja kiihtyvyyden säätäminen hauskalle tasolle vaatii paljon hienosäätöä, joten numeroarvoja on hyvä päästä muuttelemaan "lennosta".


Protokieriö

Protoilu pyörii suunnittelun, toteutuksen, käytön ja evaluoinnin muodostamaa kehää. Tyypillisesti kehää kierretään muutamia iteroivia kierroksia. Kolmen - neljän parannetun version jälkeen prototyypin jatkokehityksellä ei yleensä saavuteta kustannuksia vastaavia parannuksia, joten jatkaminen on epätaloudellista ja turhaa. Jokainen protokieriön osa-alueesta on syytä suorittaa huolella ja ajatuksen kanssa.

Suunnitteluvaiheessa mietitään, mikä osa-alue tarvitsee kokeilua. Ehkäpä jostain kontrollimekanismista tai näkymästä on olemassa useampia kilpailevia vaihtoehtoja, joiden paremmuusjärjestystä ei pysty suoralta kädeltä näkemään. Kenties jollakulla on käyttöliittymää varten vallankumouksellinen idea, joka kuitenkin sotii totuttuja käytäntöjä (konventioita) vastaan. Oleellista on hahmottaa ja määritellä mitä halutaan tutkia ja minkälaisia lopputuloksia odotetaan. Tämä ei tarkoita sitä, että pitäisi tietää heti alussa, mikä menee pieleen ja mikä toimii, vaan sitä, että jos tutkitaan esimerkiksi valikkorakenteen toimivuutta, tuloksena ei voi olla asiasisältöjen muotoilun muuttaminen.

Toteutusvaiheessa on tarkoituksena jollain metodilla (paperiprotona, Flash-koodina tms) toteuttaa oikeasti käytettävä versio tarkastelun alla olevasta osasta. Yleensä tarkoituksena on kokeilla osa-alueen toimivuutta, joten toteutuksessa kannattaa keskittyä toiminnallisuuksiin ulkoasun sijaan. On tietenkin tilanteita, jolloin täytyy kokeilla esimerkiksi fonttien näkyvyyttä tai värien käyttöä, mutta niissäkin pätee sama periaate: mahdollisimman nopeasti riittävän toimiva versio, jota hypistelemällä on mahdollisuus saada käsitys toiminnasta tai ulkoasusta.

Käyttövaiheessa prototyyppiä testataan. Tämä on osittain hyvin läheistä sukua käyttäjätestaukselle ja samoja metodeja voidaan hyödyntää. Mikäli protoillaan käyttöliittymää tai pelifiilistä, "flowta", voi olla hyödyllistä videoida tai muuten tallentaa protoilutilanteet. Tällöin on myös hyvä käyttää tekijäryhmän ulkopuolisia henkilöitä testauksessa. Lähes aina nämä ulkopuoliset testaajat onnistuvat löytämään prototyypistä tai toiminnoista joitain sellaisia puolia, joita asiaan perehtyneet tekijät eivät ole havainneet. Tilastollista arviointia varten annetaan esimerkiksi taistelusimulaation pyöriä satoja tai tuhansia kierroksia, joiden tulokset tallennetaan myöhempää analyysiä varten. Mitä tahansa menetelmää käytetäänkin, käyttövaiheesta tulisi jäädä jonkinlaisia muistiinpanoja tai tuloksia, joita voidaan evaluoida seuraavassa vaiheessa. Käyttövaihe voidaan myös lopettaa kesken, mikäli prototyypin toiminnassa havaitaan selkeästi fataali virhe, joka käytännössä tekee koko muun testaamisen turhaksi. Tällöin tuo virhe on korjattava ennen kuin käyttöä kannattaa jatkaa.

Evaluointi- eli arviointivaihe koittaa, kun prototyyppi on toteutettu ja sitä on käytetty riittävän paljon, että käsillä on jonkinlaisia tuloksia. Evaluointivaiheessa käydään läpi käyttövaiheessa kertyneet kokemukset ja tulokset ja verrataan niitä haluttuihin lopputuloksiin. Mikäli käytön aikana prototyypistä löytyi selkeitä parannustarpeita, ne huomioidaan. Tilastollisen simulaation ollessa kyseessä tarkastellaan tuloksia, joista saattaa paljastua esimerkiksi epätasapainossa olevia mekaniikkoja tai liian suuren painoarvon saavia nopanheittoja. Evaluoinnin tuloksena on lista asioista, jotka kaipaavat muutosta tai parannusta. Tämän listan kanssa voidaankin sitten pyörähtää protokieriön seuraavaan vaiheeseen, eli takaisin suunnitteluun, jossa mietitään ratkaisuja käytön ja evaluoinnin aikana löytyneisiin ongelmakohtiin.

Protoilun ajoitus

Toisinaan protoilu pyritään aloittamaan mahdollisimman aikaisessa vaiheessa, heti ensimmäisen idean synnyttyä. Tällöin protoilu toimii myös brainstormauksen välineenä. Oleellista on pitää kehityssykli mahdollisimman nopeana. Protoilu on usein ennemminkin kvantitatiivista kuin kvalitatiivista, eli kokeilujen määrä on tärkeämpää kuin niiden laatu. Tämä siksi, että toisinaan määrä johtaa laatuun, eli todennäköisyys hittituotteen tai loistavan ratkaisun löytymiseen kasvaa, mikäli pohjamateriaali (tässä tapauksessa proton iteraatiot ja versiot) on tarpeeksi laaja. Mikäli kyseessä on kehitysryhmän oma sisäinen testi, kannattaa muutokset protoon tehdä heti, kun niiden tarve huomataan. Näin päästään kokeilemaan uusia versioita heti, eikä vasta suunnitellun testin täytyttyä.

Kaikkia ominaisuuksia ei tietenkään voida protoilla heti projektin alussa. Usein esimerkiksi käyttöliittymäsuunnittelu seuraa vasta myöhäisemmässä vaiheessa projektia, kun kaikki halutut ominaisuudet ja toiminnot on saatu selville. Tällöin on mahdollista käyttää jo tuotettua materiaalia protoilun alustana. Esimerkiksi strategiapelin käyttöliittymän protoilussa kannattaa käyttää alustana aiemmin tehtyä peliengineä. Aito ympäristö on aina parempi alusta protoilulle kuin mock-up näkymät tai paperiprotot. Kustannustehokkuus täytyy kuitenkin pitää mielessä, eikä ole välttämättä mielekästä toteuttaa täydellistä käyttöliittymäprototyyppiä vain testiä varten. Ennemminkin kannattaa kokeilla yksi kerrallaan itsenäisiä osa-alueita, kuten protoillessa yleensäkin. Käytettäessä rinnakkain uutta ja vanhaa versiota voidaan helposti todeta uudemman version mahdolliset edut ja puutteet aiempaan verrattuna.


Seuraavassa vielä lista metodeista ja avainsanoista, joiden avulla löytyy protoilumetodeja ja muita aiheeseen liittyviä asioita:

- Wizard of Oz
- Paper prototyping
- Design probes
- Adobe Flash
- Spreadsheet simulation
- Jacob Nielsen: Usability Engineering
- http://www.usabilitybok.org/methods