Mobiilipalvelun rakentamisessa on helppo astua harhaan. On helppo innostua mobiililaitteiden ominaisuuksista ja siitä, että laitteet kulkevat käyttäjiensä mukana kaikkialle. Ei siis ole lainkaan yllättävää, että mobiilipalvelun strategiaa ja fokusta ei aina ole suuremmin mietitty, vaan on vain haluttu tuoda olemassa oleva palvelu asiakkaan taskuun esimerkiksi sovelluksen muodossa. Tällöin on valitettavan usein epäselvää, mitä lisäarvoa sovellus tuottaa asiakkaille verkkopalveluun verrattuna tai organisaatioille kymmenien tai satojen tuhansien eurojen kehityspanoksen vastineeksi. Tässä kirjoituksessa tarkastelemme tapoja tehdä kestäviä strategisia valintoja mobiilipalvelua kehittäessä.
Tyypillisen mobiilipalvelun lanseeraus näyttää karrikoiden jotakuinkin tältä:
Lanseerauspäivänä 1000 käyttäjää vierailee palvelussa tutustumassa. 20 % heistä luo palveluun tunnuksen. 40 % näistä käyttäjistä palaa seuraavana päivänä. 50 % heistä palaa vielä viikon kuluttua. 50 % jäljelle jääneistä pysyy aktiivisina käyttäjinä vielä kuukauden kuluttua – eli 20 käyttäjää tuhannesta.
Tällainen tulos voi olla lannistava, mutta laantuva alkuinnostus kuuluu kaikkien palvelujen elinkaarelle, eikä se itsessään ole ongelma, jos kiinnostuneiden joukko on riittävä ylläpitämään positiivista liiketoimintapotentiaalia suhteessa vaadittuihin kehitysresursseihin.
Ongelmia syntyy erityisesti, kun uusien ja palaavien käyttäjien toivossa rakennetaan ominaisuuksia ominaisuuksien päälle ilman selkeää fokusta.
Aikamatka palvelun mahdollisiin tulevaisuuksiin
Kuten palveluille laajemminkin, oikea tavoiteasetanta on mobiilipalvelun kehittämisessä ja toimivan strategian muovaamisessa keskeistä. Mobiilipalveluja suunniteltaessa riittävän tiukan fokuksen löytäminen korostuu. Tarjolla on miljoonia mobiilipalveluja ja -sovelluksia, mutta keskimäärin asiakkailla on säännöllisesti käytössään parisenkymmentä ja vain pieni osa tarjolla olevista sovelluksista tuottaa kehittäjilleen kassavirtaa. Markkinan tarkastelu on siksi jo lähtövaiheessa tärkeää.
Mobiilipalvelun teknologia, toiminnot, rakenne ja sisältö eivät merkitse mitään, mikäli palvelun olemassaolon tarkoitusta ja kykyä erottua ei ole kirkastettu.
Vahva tavoiteasetanta auttaa määrittämään, miten suunniteltava mobiilipalvelu vastaa liiketoimintatarpeisiin ja tuottaa palvelun käyttäjille aitoa arvoa. Liiketoiminnallisen kestävyyden lisäksi oikeanlainen tavoiteasetanta auttaa toteuttamaan myös sosiaalista kestävyyttä: välttämään kieroja monetisointimalleja ja rakentamaan palveluja, joiden pariin palataan tuotetun arvon vuoksi, eikä koukuttavaksi rakennettujen algoritmien.
Suunniteltaessa mobiilipalvelua on pohdittava mm. palvelun tarkoitusta, kohderyhmiä, liiketoimintamallia sekä vaadittuja osaamisia, kyvykkyyksiä ja resursseja. Kun edessä on mahdollisuuksien maailma ja resursseja on kuitenkin rajatusti, on design-ajattelu kätevä aikakone, jonka avulla on mahdollista kokeilla ja todentaa palvelun erilaisia mahdollisia tulevaisuuksia. Laadullisen ja määrällisen asiakasymmärryksen menetelmiä sekä nopeaa prototypointia yhdistämällä voidaan arvioida vaihtoehtoisia näkemyksiä siitä, mihin palvelun pitäisi keskittyä ja mitkä ovat sen potentiaalisimmat toteutus- ja kaupallistamistavat.
Kertynyt ymmärrys luo pohjaa teknisille valinnoille, käyttökokemuksen hiomiselle sekä kehitysorganisaatiota, kyvykkyyksiä ja dataa koskettavien vaatimusten tunnistamiselle. Prototyyppien testaus asiakkaiden kanssa muuttuu parhaimmillaan lähes huomaamatta palvelun tekniseksi pilotoinniksi ja iteratiiviseksi kehittämiseksi.
Selkeä kuva tavoitteista ja tuotetusta arvosta auttaa valitsemaan oikean toteutustavan
Koska toteutusteknologian vaihtaminen matkan varrella on hyvin vaikeaa ja kallista, toteutustavan valinta kannattaa tehdä vasta kun sen valitsemiseksi on suunnitteluprosessissa syntynyt riittävä ymmärrys palvelun tulevaisuuden visiosta. On tärkeä voida hahmottaa palvelun roadmapia pidemmälle tulevaisuuteen ennen kuin tehdään päätös siitä, tehdäänkö palvelulle oma sovellus vai riittääkö sen toteuttamiseen selaimessa toimiva verkkopalvelu. Nämä kaksi vaihtoehtoista suuntaa pitävät molemmat sisällään vielä useita erilaisia teknisiä vaihtoehtoja.
Milloin kannattaa rakentaa selaimella käytettävä palvelu?
Jos palvelua käytetään harvoin tai korkeintaan ajoittain eikä käyttäjän laitteen tarkoilla ominaisuuksilla ole keskeistä merkitystä palvelun tuottamiselle, on usein kustannustehokkaampaa ja käyttäjille helpompaa tarjota palvelu selaimen kautta käytettävänä, mobiilioptimoituna verkkopalveluna. Näin on myös, jos palvelu on selkeästi sisältövetoinen, oli sisältönä sitten verkkokaupan tuotevalikoima, artikkeleja tai mediasisältöä. Verkkopalvelu on matalamman konversiokynnyksen takana, sillä mitään ei ole pakko asentaa puhelimeen.
- Verkkopalvelu on varteenotettava vaihtoehto suurimmalle osalle mobiilipalveluista. Hyvin mobiililaitteilla toimivan verkkopalvelun rakentaminen vaatii vähemmän spesifistä teknologiaosaamista kuin sovellusten rakentaminen, laitekannat ja käyttöjärjestelmät eivät muodosta palvelun toteutukselle riskiä ja selainten suorituskyky on mobiililaitteissakin nykyään erinomaisella tasolla. Verkkopalvelun heikkouksia ovat alhainen kyky hyödyntää laitteen teknisiä ominaisuuksia sekä luotettavan verkkoyhteyden tarve.
- Progressive Web App (PWA) on verkkopalvelu, joka voidaan asentaa mobiililaitteen kotinäytölle ja jota on mahdollista käyttää ilman verkkoyhteyttä. Joillekin toimijoille PWA:sta on muodostunut tapa tuottaa alemman suorituskyvyn älypuhelimissa toimiva palvelun versio – kuten Instagram Lite tai Google Maps Go. PWA-sovellus on mahdollista julkaista Google Play -kaupassa, mutta iOS:n App Storeen sellaista ei voi julkaista.
Milloin mobiilisovelluksen kehittäminen on perusteltua?
Jos tapa käyttää palvelua on säännöllinen tai jopa rutiininomainen, ja palvelu täyttää asiakkaan arjessa jonkin täsmätarpeen, sovellus on usein luonteva valinta toteutustavaksi. Sovelluksen tulisi kuitenkin helpottaa palvelun käyttöä konkreettisella tavalla, jotta asiakkaan näkökulmasta on perustetta asentaa sovellus verkkoselaimen avaamisen sijaan. Asennettava sovellus on kannattava valinta erityisesti silloin, kun palvelun perusidea nojaa mobiililaitteen teknisiin ominaisuuksiin kuten sensoreihin, GPS-sijaintiin, kameraan tai vaikkapa lisätyn todellisuuden renderointiin.
Verkkopalveluun verrattuna sovelluksen kehittämiseen vaadittu alkuinvestointi on selvästi korkeampi. Osaamisen hieman korkeampi hintataso web-kehittämiseen verrattuna voi korostua palvelun elinkaarella. Muuttuvan sisällön esittäminen on sovelluksessa teknisesti työläämpää kuin verkkopalvelussa, ja asiakkaan näkökulmasta käyttöönotto on moniportaisempaa.
Mobiilisovelluksen rakentamiseen on useita teknisiä vaihtoehtoja.
- Natiivi sovellus rakennetaan kullekin käyttöjärjestelmälle niiden omilla ohjelmointikielillä ja sovelluskehyksillä. Natiivi toteutus vähentää riippuvuuksia ja helpottaa mukautumista laitealustojen kehittymiseen. Natiivisti tehty sovellus saa usein enemmän toiminnallisuuksia ilmaiseksi käyttöjärjestelmän puolelta kuin muulla tavoin rakennettu sovellus. Esimerkiksi mobiilialustojen saavutettavuusteknologioiden hyödyntäminen on natiivissa sovelluksessa helpompaa. Natiivin sovelluskehityksen tyypillisimmät haasteet ovat osaamisen saatavuus sekä sovelluskoodin erilaisuus laitealustojen välillä.
- Cross-platform -ohjelmistokehyksellä (esim. React Native, Xamarin, Flutter) on mahdollista rakentaa sovellus samaa tai pääosin samaa ohjelmistokoodia hyödyntäen sekä Android- että iOS-laitteille. Kullakin ohjelmistokehyksellä on omat ohjelmointikielensä ja konventionsa, ja osaamisen saatavuuden tulisi vaikuttaa ohjelmistokehyksen valintaan. Cross-platform -ratkaisu vähentää tarvittavien osaamisten määrää mutta tyypillisesti kasvattaa hallittavan ohjelmistokoodin määrää. Jaetusta koodikannasta huolimatta esimerkiksi käyttöliittymään liittyviä asioita joudutaan useimmiten tekemään laitealustoille eri tavoilla. Ohjelmistokehyksen tuottamat välikerrokset käyttöjärjestelmän ja sovelluksen välissä luovat myös uusia riippuvuuksia ja riskejä.
- Low-code on erityisesti organisaation sisäisiin tarpeisiin soveltuva tapa tuottaa olemassa oleviin järjestelmiin ja datalähteisiin kytkeytyviä mobiilisovelluksia mahdollisimman vähällä ohjelmointityöllä. Low-code -alustat kuten OutSystems ja MS PowerApps tarjoavat valmiita käyttöliittymäratkaisuja esimerkiksi tilaus- tai tuotannonohjausdatan tarkasteluun sekä sovellusjakelukanavan organisaation sisäisille käyttäjille.
- Pienoissovellus (App Clip, Instant App) tarjoaa tietyn palasen laajemman sovelluksen ominaisuuksista. Käyttökokemus on sujuvampi kuin selaimella, mutta sovelluksen asentamista ei silti vaadita, vaan käyttöönottoon riittää esimerkiksi QR-koodin lukeminen. Pienoissovellukset soveltuvatkin erityisesti fyysisen maailman palveluille, jotka vastaavat satunnaisiin tarpeisiin. Esimerkiksi sähköpotkulaudassa oleva QR-koodi voi johtaa pienoissovellukseen, jossa käyttäjä maksaa laudan käytöstä.
Teknologiavalinta on osa asiakaskokemusta
Jotkin teknologiaratkaisut soveltuvat tiettyihin ongelmiin ja tilanteisiin paremmin kuin toiset. Toteutustavan ja -teknologian valinnassa on puntaroitava palvelun konseptin asettamia vaatimuksia, organisaation omaa toteutuskyvykkyyttä ja saatavilla olevaa osaamista.
Jos teknologiavalinnassa ei ole huomioitu organisaation kykyä resursoida oikeanlaisia tekijöitä palvelun elinkaarelle, lopputuloksena voi olla käsiin happaneva koodikanta, jonka sielunelämää kukaan ei oikein tunne.
Asiakkaalle tämä voi näkyä huonosti toimivana palveluna ja epätasaisena käyttökokemuksena. Liiketoiminnalle tämä voi näyttäytyä hitaana kehittämisenä ja paisuvana teknisenä velkana. Lopulta edessä saattaa olla palvelun alasajo tai koko koodikannan uusiminen toisella teknologialla.
Teknologiaa valittaessa tulisi siis pyrkiä varmistumaan siitä, että teknologia itsessään ei muodosta sellaisia riskejä ja riippuvuuksia, joita organisaatio ei yhdessä kumppaniensa kanssa pysty taklaamaan palvelun elinkaarella – liittyivät ne sitten osaamisen saatavuuteen tai ohjelmistokehyksen tulevaisuuden roadmapiin.
Työ ei lopu ensimmäiseen julkaisuun
Niin verkkopalvelujen kuin sovellustenkin kohdalla elintärkeää on muodostaa jo varhain lanseeraussuunnitelma ja pohtia, miten potentiaalisille asiakkaille tullaan havainnollistamaan palvelun tuottama hyöty. Jos palvelun strategiset valinnat, tavoitteet ja fokus on suunnitteluvaiheessa kirkastettu, myös sen hyödyistä viestiminen suoraviivaistuu. Kohderyhmän ja sovelluksen käyttötarkoituksen mukaan on luonnollisesti valittava oikeat markkinointikanavat, tarkoittaa se sitten sosiaalista mediaa, sisältömarkkinointia tai maksettua mainontaa.
Jopa yli puolet sovelluskaupassa listatun sovelluksen asennuksista voi tulla itse sovelluskaupan haun sekä kaupan suosittelujen kautta. Siivu on niin merkittävä, että sovelluskauppakuvausten ja -kuvakaappausten optimointi ja huolellinen rakentaminen hyvin kiteytetyksi kokonaisuudeksi kannattaa.
Hinnoittelua ja monetisointimallia on hyvä suunnitella ajoissa yhdessä palvelun käyttäjien kanssa – sekä markkinaa analysoiden. Onko kyseessä jotakin olemassa olevaa palvelua tai tuotetta täydentävä sovellus, jonka hinta on jyvitetty muualle? Jaellaanko sovellusta ilmaisena kokeiluna, vai tarjoaako se lisätoimintoja jatkuvan tilauksen ostajille? Kertaostokin on relevantti vaihtoehto, jos palvelulla on tarkoituksenmukaisesti lyhyt elinkaari asiakkaan laitteella, mutta kokeilun kynnys on korkeampi.
Sovelluskaupoissa suosituin monetisointimalli on mainosten näyttäminen sovelluksessa, mutta tämä ei välttämättä ole brändistään tarkoille yrityksille järkevä vaihtoehto.
Mobiilipalvelun julkaisuille on monia malleja. Esimerkiksi rajattu pilotti tai soft launch on luonteva jatko yhdessä asiakkaiden kanssa prototypoinnille. Täsmällistä julkaisumallia tärkeämpää on kuitenkin se, että on olemassa selkeä suunnitelma ja riittävät resurssit palvelun käytön mittarointiin ja jatkokehittämiseen. Esimerkiksi sovelluskauppa-arvostelujen seuranta, niihin reagointi ja kehitystarpeiden jäsentäminen arvostelujen perusteella voi vaatia yllättävän paljon panostusta.
Mobiilipalvelun tuottaminen ei suinkaan lopu ensimmäiseen tuotettuun versioon. Jatkokehitys on usein muuttuvien asiakas- ja liiketoimintatarpeiden sekä teknisten kehityskohteiden välillä tasapainottelua. Kehitystyön arjessa on kuitenkin hyvä muistaa, että missä tahansa kehitystyön päätöksentekopisteessä on mahdollista ottaa avuksi aikakone, eli tutkailla suunnittelun menetelmin kulloisiakin mahdollisia tulevaisuuksia. Näin voidaan jatkuvasti varmistaa, että palvelu vastaa liiketoimintatavoitteisiin, luo aidosti arvoa asiakkaalle ja että tekniset valinnat vastaavat organisaation kyvykkyyttä tuottaa palvelua korkealaatuisesti.
Tutustu lisää aiheeseen katsomalla webinaaritallenne Hypen jälkeen – mobiilista tuloksellista liiketoimintaa.
