Skip to content

Protoillen onneen - prototyypin monet muodot digitaalisessa kehityksessä

Kuuntele ääniblogina (6.07 min)

Digitaalisuus on täynnä terminologiaa, jolla on lähestulkoon yhtä monta tulkintaa kuin on tulkitsijaakin. Termi konsepti on ollut suosikkini, mutta olen huomannut, että yhtä laveasti tulkittu sana on prototyyppi.

Kuten konseptinkin osalta, kaikki tulkinnat sanasta ovat varmasti oikein, mutta kehityshankkeissa termin erilaiset tulkinnat aiheuttavat valtavat määrät sekaannusta erilaisten ammattilaisten keskuudessa.

Kun kehityshankkeessa mainitaan sana prototyyppi, ei siis kannata automaattisesti lukkiutua ajattelemaan vain sitä, mitä juuri sinulle tämä termi tarkoittaa.

Norttiaski-proto

Prototyypin monitulkintaisuus tuli mieleeni, kun aloin lueskelemaan Google Venturen kehittämästä Design sprint -menetelmästä (http://www.gv.com/sprint/), missä nopea prototypointi on olennainen osa sprintissä ideoitujen konseptien (haha) arvioinnissa loppukäyttäjien kanssa.

Tässä yhteydessä puhutaan siis prototyypistä, jonka tarkoitus on tehdä tuote- tai palveluideasta konkreettinen, niin että testaava kuluttaja ymmärtää (tai ei ymmärrä) mistä on kyse ja pystyy antamaan siitä palautetta.

Idean koeponnistamiseen ei tarvita kovin kummoista prototyyppiä, vaan hyvin simppeli, jopa paperille piirretty hahmotelma tuotteesta riittää.

UX-ammattilaisille tämä onkin riittävä prototypoinnin taso.

Norttiaskin kylkeen raapustettu prototyyppi voi auttaa siis kirkastamaan ideaa ja varmistamaan, että asiakaskin sen ymmärtää.

Paperiproton avulla tehtävällä testauksella voidaan myös antaa käyttäjien ratkaista suurimmat linjaerimielisyydet, joita tuotekehittelyssä väistämättä tulee eteen.

Esimerkkinä nyt vaikka kirjautumisen konsepti. Että tehdäänkö Facebook-login vai pyydetäänkö käyttäjää tekemään ihan oma palvelukohtainen käyttäjätunnus. Pahimmillaan tämäntyyppiset väännöt lähestulkoon pysäyttävät koko suunnittelun, kun omasta näkemyksestään kiinni pitävät ammattilaiset linnoittautuvat poteroihinsa käymään asemasotaa.

Eli, mitä nopeammin asiaan saadaan käyttäjiltä palautetta, sitä vähemmän tarvitaan mutua.

Hötskä-proto

Paperiprototyyppi ei kuitenkaan ole ainoa prototyyppi, jota digitaalisten palveluiden kehittämisessä tarvitaan.

Toisaalla Loihde Advancen blogissa otettiin jo kantaa siihen, että miten kauan palvelun ulkoasua kannattaa hifistellä esimerkiksi photarissa sen sijaan, että visuaalisten päälinjauksien selvittyä se koodattaisiin mieluummin samantien HTML-prototyypiksi.

HTML-prototyypillä päästään nopeammin toteamaan, että toimiiko visualistin näkemys sen aidossa ympäristössä - selaimessa. Ja erityisesti responsiivisena. Ja oikeiden sisältöjen kanssa.

Visujen hinkuttaminen photarissa on todella työlästä ja hidasta. On huomattavasti parempaa budjetinkäyttöä siirtyä hyvissä ajoin HTML-protoiluun ja pyytää visualistilta parannusehdotuksia ja lisäelementtejä, kun ensimmäinen versio HTML-protosta on kasassa.

Monesti myös erityyppisten animaatioiden, interaktioiden ja siirtymien suunnittelu staattisessa ympäristössä on hankalaa. Interaktio, joka näyttää hyvältä kuvassa, ei välttämättä olekaan kovin smooth toteutettuna tai siirtymiin ei tule mietittyä animointeja ja tulos on töks töks.

HTML-prototyyppi siis vähentää visualistilta turhaa työtä ja tekee käyttöliittymän kehittämisestä ketterämpää. HTML-protoon voi halutessaan pyytää myös käyttäjien palautetta. Palvelun idean ja hyödyllisyyden lisäksi käyttäjät pystyvät myös ottamaan kantaa siihen, että osaavatko he moista häkkyrää käyttää.

Eli jos kysyt visualistin tai fronttikoodarin tulkintaa sanalle prototyyppi, se on mitä todennäköisimmin juurikin HTML-proto.

Proof of concept -proto

HTML-proto riittää kertomaan miltä käyttöliittymä näyttää ja miten se toimii. Se, miten kaikki ne näkyvät asiat käyttöliittymään tulevat, on vielä miettimättä. Ja tämä onkin usein se kriittinen vaihe kehittämisessä. Onko esimerkiksi alunperinkään mitään taustajärjestelmää, jossa se data tai sisältö, jota siis ei siis välttämättä vielä ole, asuisi?

Valitettavan usein digitaalisen palvelun eri elementtejä kehitetään siiloissa. Taustajärjestelmiä speksailee oma porukansa, tietomalleja toinen ja varsinaista käyttökokemusta kolmas ja niitä sisältöjä ei tee kukaan.

Jos kehitystä halutaan tehostaa ja laatua parantaa, toimii liimana konseptin eri osasten välillä jälkeen kerran asia, jota kutsutaan prototyypiksi.

Tämän prototyypin on tarkoitus koeponnistaa itse ratkaisu - eli siis olla proof of concept.

Siis ennen varsinaista tuotantokehitystä.

Voi nimittäin olla, että tosiaan konseptin vaatimat taustajärjestelmät puuttuvat ja onkin järkevää ensin protoilla kevyesti, että miten niiden kannattaisi toimia ja vasta sitten alkaa etsimään markkinoilta sopivaa tuotetta tai vetää muita arkkitehtuurillisia linjauksia. Prototyypin avulla myös konseptin operoinnin vaatimukset konkretisoituvat.

Jos palvelusta voi lohkaista hajoita ja hallitse -menetelmällä pienen osan ja toteuttaa sen kokonaisuudessaan prototyypiksi niin näin kannattaa toimia. Vesiputousmaisen upfront-määrittelyn sijasta kannattaa vaan alkaa tekemään. Ja oppia tekemällä.

Tämä tapa toimia vaatii kaikilta osapuolilta joustavuutta, kun eteen tulee tilanteita, missä työtä menee hukkaan ja asioita joudutaan tekemään uudelleen, koska kaikkea ei vaan osattu ennakoida. Mutta niin käy ja yleensä vielä laajemmassa mittakaavassa myös vesiputousmallissa, koska dokumenttia kirjoittaessa asioita osataan vielä vähemmän ennakoida.

Toimiva prototyyppi on myös kokonaisuus, joka on helppo pilkkoa tuotantokehityksen backlogille ilman, että kokonaiskuva katoaa.

Ja sitten digihankkeissa voikin hylätä sanonnan “hyvin suunniteltu on puoliksi tehty” ja ottaa käyttöön hiukan muokatun savolaisen viisauden “prototyypin avulla kehitetty palvelukonsepti on tekemistä vaille valmis”.