Palvelumuotoilu on koodarinörtin opaskoira

Introspektiivinen kolumni siitä, miten outoa ja yhtä lailla kaivattua palvelumuotoilu on koodarille.

Vuonna 2010 tulin Palmulle ja kuulin ensimmäistä kertaa sanan ”palvelumuotoilu”. Enkä ymmärtänyt yhtään mistä on kysymys. Hetkessä palasin vuoteen 1999. Silloin törmäsin termiin ”konsepti” ja ajatuksiin siitä, miten webbikoodaus yleensäkään liittyy tenteistä tuttuihin konseptipapereihin. Reilussa kymmenessä vuodessa olin oppinut konseptoinnin merkityksen, joten uskalsin hypätä tutustumaan palvelumuotoiluunkin.

Nyt olen tehnyt palvelumuotoilua kuusi vuotta. Siitä huolimatta ajatuksissani ja töistäni puhuessa haen yhä parasta mahdollista kuvausta ja selitystä sille, mitä ihmettä on palvelumuotoilu.

Minulle palvelumuotoilu on sitä, että palveluja rakennetaan ihmisille. Tämä tehdään tutkimalla sitä, miten ihmiset hyötyvät ja pärjäävät palvelun kanssa. Heille näytetään käsin kosketeltavia esimerkkejä: piirroksia, kuvauksia, digitaalisia demoja, pienoismalleja.

Samalla huomioidaan palvelutarjoajan tavoitteet, eli kannattaako palvelua tarjota

Palvelu on kokonaisuus ja suunniteltaessa se pitää huomioida kokonaisuutena. Tarkoitan, että ei vain hiota parasta mahdollista sovellusta, vaan mietitään sen markkinointi, viestintä, tuki ja laajentaminen – tai myös elinkaari käyttöönotosta päivitykseen, tai käytön lopettamiseen.

Palvelua tehdään pienissä palasissa. Aloitetaan karkeista ja nopeasti tehdyistä esimerkeistä, joita näytetään ihmisille. Seurataan reaktioita, kysytään tarkennuksia ja kuunnellaan.

Nöyryys tekee hyvän palvelun

Usein (juuri koskaan) omat ideat eivät toimi sellaisenaan, vaan pitää olla nöyrä ja hyväksyä palaute. Sen pohjalta suunnitellaan palveluista parempia – ja sitten viedä ne uudelleen ihmisten käytettäväksi. Tätä kuuntelua ei saa lopettaa siihen, kun palvelun ensimmäinen ilmentymä on valmis ja julkinen.

Entä mikä tässä koodarina vetoaa minuun?

Koodatessani sovelluksia erilaisille asiakkaille tai käyttäjille, pohdin aina, mikä on tärkeintä. Mitä yritys hakee sovellukselta (tai siis palvelulta), ja mitä sen käyttäjä haluaa.

Mitkä ovat ne ongelmat, joita minun pitää oikeasti ratkaista?

Harvoin nämä välittyivät vaatimusmäärittelyistä ja konseptisuunnitelmista, joita 2000-luvun alussa sain työohjeiksi. Muutaman vuoden yritin hioa näitä ja auttaa konseptoijia kertomaan asiat tarkemmin. Se oli turhauttavaa, koska dokumentilla välitetty tieto ei edes kuvitettuna voi vastata kaikkiin kysymyksiin. Se myös helposti hautaa varsinaiset tavoitteet yksityiskohtien alle.

Kuuntele liiketoimintaa, mutta myös asiakkaita

Muutaman vuoden tein myös ketterästi asiakkaiden kanssa sovelluksia – ja pääsin vihdoin kiinni liiketoiminnan tavoitteisiin ja sain kysyä haluamani tarkennukset suoraan ja silloin, kun vastauksilla oli merkitystä. Tämä puolestaan vääristi painotusta liiketoiminnan näkemyksiin: todellisia käyttäjiä näin harvoin, yleensä vasta testausvaiheessa. Silloin oli myöhäistä (”budjetti meni jo!”) tehdä suurempia muutoksia toimintoihin.

Vasta palvelumuotoilussa olen nähnyt, miten liiketoiminnan tavoitteet ja asiakaskokemukselle tärkeät vaatimukset kerätään systemaattisesti – ja tuodaan ne ohjaamaan sovelluskehitystä ajoissa ja läpi kehitysvaiheen.

Näkemistäni tämä on paras tapa toteuttaa oikeasti hyödyllisiä ja merkittäviä sovel…, tai siis palveluja.