Behind the scenes: erään b2b digipalvelun palvelumuotoilu

Tämä kirjoitus on osa laajempaa Palvelumuotoilu: Kokonaisvaltainen opas aloittelijoille ja jo asiasta tietäville blogikirjoitussarjaa. Käyn tässä blogikirjoituksessa läpi, miten eräs B2B asiakassegmentille suunnattu uusi digipalvelu kehitettiin palvelumuotoilun keinoin. Tuon tässä kirjoituksessa esille myös omia tapojani työskennellä. Itse suosin end to end ajattelu- ja toimintamallia, jossa asioita katsotaan holistisesti ymmärtämällä ensin koko palapeli, mitä ollaan tekemässä ennen kuin hypätään tekemään yksittäistä palapelin palasta. Tämän lisäksi end to end ajatteluun kuuluu, että otetaan vastuu ensimmäisistä askelista sekä vastataan myös palvelun julkaisun jälkeisestä tekemisestä ts. jatkuvasta parantamisesta.

Lähtökohdat palvelun suunnittelutyölle

Tiimissämme oli määritelty design prosessi ja meillä oli systemaattinen tapa osallistaa sekä asiakkaita että sisäisiä sidosryhmiä ympäri organisaatiota suoraan asiakasrajapinnasta, mutta myös liiketoimintajohdosta.

Aiempien tutkimusten pohjalta tiesimme, että kyseinen asiakassegmentti on alipalveltu ja suunnitteilla olevalle palvelulle oli selkeä tarve. Olimme aiemmissa asiakashaastatteluisssamme sivunneet aihetta ja meillä oli jo jonkinlainen käsitys asiakkaiden sen hetkisestä tavasta toimia, ongelmista sekä tarpeista. Myös liiketoimintatavoitteet tukivat päätöstä lähteä rakentamaan täysin uudenlaista palvelua asiakkaille.

Design tiimimme koostui palvelumuotoilijasta sekä kahdesta UX designerista. Sen lisäksi tuotekehitystiimissä oli ohjelmistoarkkitehti, kehittäjiä, testaajia ja tuotepäällikkö.

Asiakasymmärryksen kerääminen

Koska olimme aiemmissa asiakastutkimuksissa jo sivunneet useaan kertaan aihetta, emme enää lähteneet tekemään puhdasta asiakastarvetutkimusta. Sen sijaan lähdimme osallistamaan eri sidosryhmiä talon sisältä ja keräämään heidän näkemyksiään asiakasymmärryksestä sekä liiketoiminnan tarpeita asian suhteen. Kävimme sekä 1 to 1 keskusteluita että pidimme työpajoja ja keräsimme monipuolisesti näkemystä eri toimipisteiden myynninjohdosta sekä henkilöiltä, jotka vastasivat asiakkuudesta sekä asiakasneuvojilta, jotka päivittäin kohtasivat asiakkaita omassa työssään. Koska uusi palvelu kosketti myös organisaation muita liiketoiminta-alueita ja oli selkeästi tunnistettavissa riippuvuuksia eri tahojen välillä, osallistimme myös liiketoiminnan kehittäjiä ja liiketoimintajohtoa laaja-alaisesti yli organisaatiorakenteiden. Myös oma tuotekehitystiimi oli mukana koko ajan alusta saakka ja tiesi, mitä missäkin vaiheessa tapahtuu.

Joku voisi kysyä, miksi osallistimme näin laaja-alaisesti sisäisiä sidosryhmiä? Tuotekehitysprosessi ei koskaan saisi olla vain tuotekehitystiimin omaa sisäistä toimintaa, vaan siinä pitäisi osallistaa useita eri tahoja. Vaikka tuotekehitystiimi loppukädessä vastaa tuotteen/palvelun kehityksestä ei palvelu vaikuta yksinään heidän toimintaansa. Useat eri tahot mm. markkinoinnista, myynnistä, asiakaspalvelusta ja johdosta tulevat jollakin tavalla omassa työssään myös kohtaamaan palvelun ja sen vaikutukset liiketoimintaan. Osa kohtaa palvelun vaikutukset omassa työssään laaja-alaisemmin, kun sisäiset prosessit kietoutuvat asiakkaan palvelun ympärille. Osa organisaatiosta kokee palvelun heijastevaikutuksia.

Tuotekehitysprosessi on aina myös sosiaalinen prosessi, missä hiljaista tietoa jaetaan yhteiskehittämisen muodossa eri puolille organisaatiota. On siis tärkeää, että palvelua kehitetään yhdessä osallistaen, jotta ollaan kaikki samalla kartalla eikä asioita tehdä omissa poteroissa, piilossa toisten katseilta. Yhteiskehittäminen myös rikkoo organisaation välisiä siiloja ja tuo eri tahojen välille yhteisen mission tekemiseen. Olen myös saanut palautetta tuotekehitykseen osallistetuilta asiakkuusjohtajilta, jotka ovat kokeneet, että kerrankin he pääsevät vaikuttamaan asioihin ja heidän asiakkaansa tulevat kuulluiksi ja nähdyiksi.

Ideointi ja konseptointi alkaa

Aiempien asiakastutkimusten ja talon sisältä kerätyn ymmärryksen perusteella palvelun ideointi ja konseptointi voitiin aloittaa. Ymmärryksen perusteella teimme hypoteesit konseptista, lähdimme määrittelemään konseptia mm. määrittelemällä vaatimukset käyttäjätarinoiden muotoon, visualisoimme konseptin eri ratkaisuvaihtoehtoja ja teimme interaktiiviset prototyypit prototypointityökalua hyödyntäen. Koko konseptointivaiheen ideana on muuttaa asiakasymmärrys asiakas- ja liiketoimintavaatimuksiin ja luoda erilaisia ratkaisuvaihtoehtoja ennen konseptin validointia asiakkailla.

Konseptivaihtoehtoja ja protoa käytiin samojen sisäisten sidosryhmien kanssa läpi ja iteroitiin palautteen perusteella. Myös omassa tuotekehitystiimissä alustavat tekniset tutkimukset ja arkkitehtuurikuvaukset aloitettiin. Erilaisia riippuvuuksia muiden tiimien tekemiseen eri puolille organisaatiota tunnistettiin jo tässä vaiheessa myöhempää työstöä ajatellen. Esittelimme ylätason konseptia alustavasti myös tietoturvan ja lakipuolen edustajille. Halusimme olla täysin läpinäkyviä ja avoimia työmme suhteen ja konseptia käytiin myös koko organisaatiolle suunnattussa infosessiossa läpi.

Asiakashaastattelut ja konseptin validointi

Koska kyseessä oli täysin uusi palvelu, osallistimme normaalia enemmän asiakkaita asiakashaastatteluihin ja konseptin validointiin. Asiakashaastattelun/konseptistudyn runko koostui pääpiirteissään siitä, että lähdimme ensin peilaamaan asiakkaan tämän hetken tapaa toimia. Asiakas kertoi omin sanoin, miten hän tällä hetkellä toimii/käyttäytyy, mitkä ovat hänen motiivinsa, mitä ongelmia hänellä on, millaisia tarpeita ja haluja voidaan tunnistaa. Vasta tämän jälkeen näytimme eri konseptivaihtoehtoja ja kävimme protoja läpi.

Proton tarkoitus on toimia pelkästään tarinankerronnan tukena. Jos itse moderoin eli vedän konseptistudya en koskaan anna asiakkaan käyttää protoa. Käyn itse protoa esimerkinomaisesti läpi aina osio kerrallaan ja kerron, miten palvelu voisi toimia. Tämän jälkeen siirrytään reflektoimaan asiakkaan kanssa, miten palvelu toimisi heidän tapauksessaan, ratkaiseeko se heidän nykyiset ongelmansa ja vastaako heidän tarpeisiinsa? Puuttuuko jotain, mitä ajatuksia ja tuntemuksia asiakkaalla heräsi? Yleensä tässä kohtaa keskustelu lähtee myös erilaisiin käyttötapauksiin, mitä ei välttämättä asiakkaan nykyisessä tavassa toimia tullut esille. Asiakas alkaa kysymään, “että no mites tää toimisi, kun meillä tää menee näin…“ Tästä on helppoa ottaa koppia ja lähteä selvittämään asiakkaan tarpeita kyselemällä lisää.

Konseptin validoinnin tarkoituksena on validoida konseptin hypoteesit ja selvittää tarkat asiakastarpeet, jotka jalostuvat vaatimuksiksi kehitystiimille. Konseptistudyssa ei koskaan keskitytä käyttöliittymän yksityiskohtiin, vaikka protoa asiakkaille näytettäisiinkin. Proto toimii puhtaasti tarinankerronnan tukena ja auttaa konkretisoimaan asioita sekä tukee dialogin syntymistä ja syventymistä asiakkaan ja haastatteluiden vetäjän välillä. Jos haluat oppia lisää asiakkaiden haastattelusta, tutustu Opi haastattelemaan asiakkaita -oppaaseen.

Konseptistudyn jälkeen, iteroimme konseptia palautteen perusteella, päivitimme vaatimukset käyttäjätarinoiden muotoon niin, että ohjelmistoarkkitehdit pystyivät myös tekemään lopulliset tekniset kuvaukset. Konseptistudyn pohjalta pystyimme myös määrittämään kehittämisen tiekarttaa pitkäksi aikaa, kun ymmärsimme palvelun ison kuvan ja mitä toiminnallisuuksia on järkevää kehittää missäkin vaiheessa.

Meillä työnjako meni niin, että palvelumuotoilija oli päävastuussa asiakasymmärryksen keräämisestä, asiakkaiden sekä sisäisten sidosryhmien osallistamisesta että konseptoinnista. UX designerit kuitenkin osallistuivat esimerkiksi konseptistudyn validointiin myös itse observoijan roolissa, jotta heillä olisi yksityiskohtien suunnittelusta vastaavina henkilöinä aina ensi käden tieto asiakkaiden käyttäytymisestä, ongelmista ja tarpeista. Konseptointivaiheen jälkeen isompi porukka kehitystiimiä lähti työstämään palvelun MVP ratkaisua, suunnittelun päävastuun siirtyessä palvelumuotoilijalta UX designerille. Palvelumuotoilija jäi tämän jälkeen tukemaan ja tarvittaessa sparraamaan UX designereita yksityiskohtien suunnittelussa.

UX Design - yksityiskohtien suunnittelu alkaa

UX design on käyttäjäkokemuksen suunnittelua ts. sen tavoitteena on suunnitella mahdollisimman käytettävä ja helppokäyttöinen, asiakkaalle arvoa tuottava palvelu. UX design on yksityiskohtien suunnittelua, missä määritellään niin interaktiot, navigaatio, UI komponentit, lopullinen visuaalinen ilme, tekstit sekä virhe- ja erikoistilanteet. UX designia tehdään tiiviissä yhteistyössä ohjelmistokehittäjien ja testaajien kanssa ja työ on jatkuvaa vuoropuhelua, miten yksityiskohdat on järkevää toteuttaa teknisestä että käytettävyyden näkökulmasta. UX designin yhteydessä viimeistään myös määritellään, mitä dataa halutaan kerätä ja datapisteet määritellään myös koodiin, jotta ne saadaan data-analytiikkaan mukaan. Palvelun julkaisun jälkeen voidaan näin mm. seurata mitä toiminnallisuuksia asiakkaat käyttävät/eivät käytä, miten liikkuvat palvelussa, jättävätkö jonkin asian kesken yms.

UX designin tehtävänä on huolehtia palvelun yksityiskohtien laadukkaasta suunnittelusta ja palvelun käytettävyydestä. UX design on iteratiivinen prosessi, jossa designeja käydään jatkuvasti läpi kehitystiimin kanssa yhdessä toisia sparraillen, jotta optimaalinen ratkaisu löydetään sekä teknisen toteutettavuuden että käytettävyyden näkökulman välillä.

Käytettävyystestit ennen palvelun julkaisua

Vaikka olimme keränneet asiakasymmärrystä aiemmin ja validoineet asiakastarpeet konseptistudyn muodossa, eivät ne yksinään riitä. Tarvitaan myös käytettävyystestausta, jotta varmistetaan, että myös yksityiskohdat toimivat ja palvelu on helppokäyttöinen asiakkaille.

Käytettävyystestaus ja konseptistudy eroavat toisistaan siinä, että käytettävyystestien fokus on nimensä mukaisesti käytettävyyden ja yksityiskohtien varmistamisessa, kun taas konseptistudyssa validoidaan asiakastarpeita. Käytettävyystestaus eroaa myös siinä, että asiakkaalle annetaan ennaltamääriteltyjä tehtäviä suoritettavaksi, joita he suorittavat itsenäisesti protoa käyttäen. Jos asiakkaat eivät pysty itsenäisesti ilman moderoijan apua tehtävää suorittamaan, kertoo se siitä, että jotkin asiat ovat liian monimutkaisia tai vaikeita käyttää/ymmärtää ja ne pitäisi suunnitella uudestaan. Käytettävvystesteillä myös testataan kuinka hyvin asiakkaat löytävät asioita ja osaavat navigoida, ymmärtävätkö he termien ja ikonien merkityksen yms. Yleensä tässä vaiheessa asiakas myös käyttää jo koodattua protoa, kun taas konseptistudyssa proto on tehty prototypointityökalulla tai se voi olla vain jonkin asteinen visualisointi palvelusta.

Jos asiakasymmärrystä on aiemmin kerätty ja konseptistudylla validoitu asiakastarpeita, ei käytettävyystesteissä pitäisi enää mitään fataalia tulla vastaan, mikä romuttaa koko tiimin tekemisen. Joitain toiminnallisuuksia voidaan joutua uudelleen suunnittelemaan ja hiomaan sekä termejä miettimään uusiksi ennen palvelun julkaisua. Osa työstä voidaan myös ajoittaa palvelun seuraavaan julkaisuun, jos nähdään etteivät ne huononna käytettävyyttä liikaa. UX design vaiheen sekä käytettävyystestien vetämisen päävastuullinen meillä oli aina UX designer.

Jatkuva parantaminen julkaisun jälkeen

Milloin digipalvelu on valmis? Vastaus on, että ei koskaan. Digipalvelun kehittäminen loppuu vasta siinä vaiheessa, kun töpseli vedetään kokonaan pois seinästä ja palvelu lakkautetaan. Muuten digipalvelun kehittäminen on jatkuvaa. Tiekartta ohjaa tekemistä isossa kuvassa ja sen lisäksi palvelua kehitetään jatkuvasti palautteen ja analytiikan perusteella. Asiakaspalautteita siis kerätään ja palvelun käyttöä sekä asiakkaiden käyttäytymistä digipalvelussa seurataan säännöllisesti data-analytiikan pohjalta. Sen lisäksi tiekartalta otetaan seuraavia osa-alueita työstöön ja riippuen minkä tason tekemisestä on kyse, joko lähdetään tutkimaan asiakastarpeita ja konseptoimaan tai suunnittelemaan käyttöliittymää ja käytettävyyttä. Riippuen siis suunnittelun abstraktiotasosta, suunnittelua lähtee ajamaan joko palvelumuotoilija tai UX designer.

Palvelumuotoilun dokumentointi

Nostan tähän vielä palvelumuotoilun dokumentoinnin. Olen monta kertaa törmännyt tilanteeseen ettei vaatimuksia ole kunnolla dokumentoitu tai ylipäätänsä mitään ei ole oikein kunnolla dokumentoitu. Tämä puute kertaantuu kaikissa seuraavissa työvaiheissa ja aiheuttaa harmaita hiuksia erityisesti ohjelmistoarkkitehdeille, joiden pitäisi lähteä työstämään vaatimusten perusteella arkkitehtuurikuvauksia.

Kun itse olen toiminut palvelumuotoilijana, omaan työtapaani on kuulunut aina mahdollisuuksien mukaan kerätä asiakasymmärrystä, tehdä kokonaiskonsepti ja vastata myös sen validoinnista. Tämä siksi, että on tärkeää ensin ymmärtää itse palapeli kokonaisuutena ennen kuin lähdetään työstämään yksittäisiä palapelin palasia. Oma työtapani on hyvin osallistavaa ja suosin paljon 1 to 1 keskusteluita erityisesti talon sisäisten sidosryhmien osallistamisessa tehokkaan ajankäytön vuoksi, mutta myös siksi, että ihmiset kertovat omia ajatuksia ja kokemuksia helpommin eikä tule lauman mukana menemistä kuten työpajoissa joskus saattaa käydä.

Olen dokumentoinut työni esimerkiksi Confluenceen tai muuhun wiki sivustoon niin, että sivusto sisältää alla mainitut asiat. Erilaisia canvaksia käytän hieman riippuen tilanteesta ja nykyään kehitän yleensä omia malleja, miten asioita voi kussakin tilanteessa parhaiten kuvata. Homman pihvi ei ole täyttää x määrää erilaisia canvaksia/templateja yms. Tarkoituksena ei ole rakastua lopputuotoksiin vaan lopputulemaan. Lopputulemaan voi päästä monella eri tavalla, ei ole yhtä ainutta oikeaa tapaa toimia.

Jonkinlainen dokumentointi on kuitenkin järkevää, koska se auttaa muiden kehitystiimiläisten tekemistä ja kokoaa kaiken materiaalin yhteen paikkaan. Isoissa organisaatiossa samaa asiakasymmärrystä voidaan myös hyödyntää toisella puolella organisaatiota ja siksi sen tuominen kaikkien saataville on tärkeää. Confluence sivun rakenne on yleensä jotakin tämän tapaista, kun olen itse toiminut palvelumuotoilijana:

• Asiakastutkimusraportit

• Talon sisältä kerätty ymmärrys dokumentoituna

• Big picture koko konseptista asiatasolla esimerkiksi mindmapiksi piirrettynä

• Asiakaspolut tai service blueprint

• Mahdollisesti jonkin canvaksen käyttö kuten esim empatiakartta, arvolupauscanvas, persoonat, business model canvas/business model innovation framework tai itse kehittelemä malli aina tilanteen mukaan yms.

• Alustava ehdotus tiekartasta peilaten asiakasymmärrykseen. (Yleensä tuotepäällikkö vastaa lopullisesta tiekartasta. Asiakasymmärryksen lisäksi, moni muu asia vaikuttaa myös siihen, missä järjestyksessä asioita tehdään)

• Vaatimukset käyttäjätarinoiksi purettuna

• Ylätason UX konsepti päänäkymistä

• Linkki protoon

Palvelumuotoilu - Iisakin kirkon rakentamista vai ketterää arvoa tuottavaa toimintaa?

Jos otetaan pari askelta taaksepäin ja mietitään, miksi yritykset ovat olemassa? Yritykset ovat olemassa tuottaakseen arvoa. Lopullisen tuomion jokaiselle yritykselle antaa asiakas. Asiakas päättää, oletteko vaivan ja hinnan väärti. Ilman asiakasta ei ole liiketoimintaa, sillä asiakas on aina rahan alkulähde aivan joka ikiselle yritykselle. Ei siis ole aivan sama, miten tuotteita/palveluita kehitetään. Pitäisi nimittäin kehittää jotain sellaista, mistä asiakas kokee saavansa arvoa ja on siitä vielä valmis maksamaankin. Läjällä kivan näköisiä hilavitkuttimia ei vielä tee yhtään mitään. Kaikki yrityksen toiminta, mikä ei tähtää asiakkaan arvon tuottoon, on täysin turhaa.

Palvelumuotoilu on holistinen tapa kehittää liiketoimintaa asiakkaita ja sisäisiä sidosryhmiä osallistaen. Edelleen on valtava määrä yrityksiä, jotka pahimmassa tapauksessa alkavat suoraan koodaamaan asioita ilman minkäänlaista asiakkaiden tarpeiden tutkimista, vaatimusten määrittelyä ja validointia sekä suunnittelua. Sitten on myös yrityksiä, jotka kyllä suunnittelevat, mutta lähtevät suunnittelemaan heti yksityiskohtia. Se, mitä näkyy käyttöliittymällä on vain osa totuutta liiketoiminnan kehittämisessä.

On valtava määrä asioita, joita pitää myös määritellä ja suunnitella, mitkä eivät asiakkaan käyttöliittymällä sellaisenaan näy. Asioita pitäisi suunnitella eri abstraktion tasoilla aloittaen ylätasosta ja porautuen sen jälkeen yksityiskohtiin. Jos asioita suunnitellaan ja visualisoidaan pelkästään käyttöliittymätasolla, on fokus väärissä asioissa väärään aikaan. Ts. keskitytään lillukan varsiin heti alussa, kun pitäisi ensin ratkoa isompia asioita koko liiketoiminnan tasolla tai esimerkiksi miten, sisäiset prosessit toimivat palvelun ympärillä.

Design prosessiin kuuluu useita eri vaiheita niin tutkimusta, konseptointia kuin yksityiskohtien suunnittelua sekä jatkuvaa parantamista. Joku voisi pitää tällaista tapaa Iisakin kirkon rakentamisena, missä lähdetään rakentamaan vaihe vaiheelta järkälettä, mikä ei valmistu ikinä. Itse voin sanoa oman kokemukseni perusteella tähän vahvan vastaväitteen. Työskentelytapa on hyvin iteratiivista, osallistavaa, ketterää ja useita asioita tapahtuu saman aikaisesti eri tahojen välillä. Ketterä tapa toimia ja pitkän tähtäimen visio eivät ole toistensa poissulkevia, vaan niitä voidaan tehdä rinnakkain. Kun palvelumuotoilua tehdään systemaattisesti, antaa se myös suuntaviivoja pitkäksi aikaa koko kehitystiimille. Palvelumuotoilu varmistaa, että vaatimukset on määritelty ja validoitu ja poistaa myös riskiä, kun tehdään varmuudella oikeita asioita ja tehdään niitä myös oikein.

Otetaan vielä loppuun vertaus reaalimaailmaan. Jos olisit rakentamassa taloa, tilaisitko kilometritolkulla kakkosnelosta, 100 kg ruuveja ja muuta rakennustilpehööriä tontin täyteen, ottaisit timpurit rakentamaan ja sanoisit, että rakentakaa minulle talo, kyllähän te nyt tiedätte, mikä talo on. Toimisitko näin? Et todellakaan. Talon olisi ensin piirtänyt arkkitehti, rakennussuunnittelija suunnitellut yksityiskohtia, LVI ja sähkötöistä olisi myös omat piirustuksensa, voisipa sinulla olla myös jo sisustusarkkitehdin suunnitelmatkin pinnoille, värimaailmalle yms ja pihakin pitäisi suunnitella. Ja olihan siellä vielä kaikki maatyötkin pitänyt tehdä oikeaan paikkaan ja oikeaoppisesti.

Miksi siis digimaailmassa edelleen lähdetään suoraan koodaaman asioita ilman, että asioita on kunnolla suunniteltu eri abstraktion tasoilla? Mitä puutteellisemmin vaatimukset ja suunnitelmat on tehty niin liiketoiminnan, asiakaskokemuksen sekä teknisen työn osalta, sen enemmän se aiheuttaa harmia, harmaita hiuksia ja soutamista ja huopaamista edestakaisin. Mitä tämä tarkoittaa käytännössä? Täydellistä rahan ja resurssien hukkaan heittämistä.