Keskisuuressa pohjoismaisessa yrityksessä oli työskennelty jo jonkin aikaa uuden asiakaslähtöisen sähköisen palvelukonseptin kanssa. Kehittäjistä, muotoilijoista ja liiketoiminnan asiantuntijoista koostuva tiimi oli aloittanut työn selkeältä vaikuttavan vision kanssa mutta nyt tuntui, että tämä visio oli kadotettu. Asia oli häirinnyt erästä tiimin kehittäjää jonkin aikaa ja hän jakoi havaintonsa muiden kanssa. Hänen kokemuksensa sai vastakaikua, ja asiaa pohdittiin tarkemmin.
Tiimi havaitsi, että he olivat kadottaneet yhteisymmärryksen siitä, ketä varten he kehittivät palvelua. Eri sidosryhmien tarpeet olivat ristiriitaisia keskenään, eikä tiimi pystynyt olemaan yksimielinen siitä, mikä oli heidän tärkein kohderyhmänsä. Tarvittavien ominaisuuksien listakin oli kasvanut, eikä kukaan tuntunut tietävän kenen tarpeita uudet vaatimukset olivat, tai kuinka tärkeitä ne olivat verrattuna aikaisempiin.
Miksi alkuvaiheen asiakastutkimusta ei saatu konkretisoitua? Miksi tarpeiden priorisointi oli niin vaikeaa, vaikka taustalla oli suuri määrä kerättyä dataa? Miksi visio oli hukassa?
Kun kehitetään monimutkaisia eri käyttäjiä palvelevia sovelluksia, on projektien onnistumisen ja etenemisen kannalta tärkeää tunnistaa tärkeimmät käyttäjät, eli ihmiset, jotka sovellusta tulevat käyttämään. Käyttäjäymmärrystä rakennetaan keräämällä dataa ja tekemällä tutkimuksia, haastatteluja ja luotaimia, mutta pelkkä datan kerääminen ei tietenkään riitä konkreettisten ja todistettavasti toimivien ratkaisujen tuottamiseen. Haasteeksi jää tiivistää tieto käyttäjistä käsin kosketeltavaan muotoon, sellaiseksi että kehitettäessä jokainen työhön osallistuva hahmottaa muun muassa:
- Sovelluksen tärkeimmät käyttäjät
- Tärkeimpien käyttäjien tavat ajatella ja toimia
- Käyttäjien tärkeimmät tarpeet
- Käyttäjien todennäköisimmät tilanteet, välineet ja tavat käyttää tuotetta
- Tavat, miten tuote tuottaa lisäarvoa kullekin käyttäjälle.
Tällä listalla on erittäin tärkeä kääntöpuoli – vaatimukset, jotka eivät ole välttämättömiä. Kaikille kehitysprojekteille on aina olemassa budjetti ja aikataulu, joiden sisällä on pysyttävä. On aika yleistä, että jossain kohtaa vaatimuslista kasvaa eri sidosryhmien osallistuessa kehitykseen, ja se saattaa olla jo lähtöpisteessä erittäin suuri. Tämä itsessään ei ole huono asia, mutta ellei ole olemassa tapaa priorisoida tarpeita ja selkeää metodia niiden dokumentoimiseen, vaatimuslistan kasvaminen estää koko projektin etenemisen. Myös lisäarvoa tuottavien ominaisuuksien toteutusjärjestys täytyy jotenkin päättää. Kaikkea ei voi tehdä, joten täytyy olla yhdessä sovittuja työkaluja päätöksenteon tueksi.
Miten tämä voidaan tehdä?
Hyvä keino kohderyhmän ja tarpeiden koostamiseen on käyttäjäpersoonien muodostaminen. Käyttäjäpersoonat ovat kehitettävän aiheen mukaan tehdyn käyttäjätutkimuksen perusteella muodostettuja hahmotelmia todennäköisimmistä kohderyhmistä ja heidän ajatusmaailmoistaan. Käyttäjäpersoonien ehdottomasti paras ominaisuus on niiden tapa tiivistää asiakastutkimuksen tulokset helposti sisäistettäviksi, nimettäviksi ja todentuntuisiksi hahmoiksi. Niiden avulla eri käyttäjien tarpeisiin voidaan viitata tehokkaasti, järjestelmällisesti ja tutkimukseen perustuen. Ne siis helpottavat sekä tarpeiden dokumentoimista että niiden kommunikointia. Käyttäjäpersoonat koostuvat karkeasti ottaen
- Kuvasta, nimestä ja lyhyestä tarpeen mukaan valikoidusta taustatietopaketista, esimerkiksi:
- persoonallisuustyypistä
- perhetaustasta
- vaikutteista
- hänen käyttämistään välineistä
- muista tuotteen käyttöön ja ajattelutapaan vaikuttavista taustatiedoista
- Henkilön tavoitteista
- Hänen käyttäessään tuotetta
- Hänen elämässään laajemmin
- Henkilön tavoittelemasta tunnetilasta tuotetta käyttäessään
- Tuotteen käyttöä estävistä asioista
- Tuotteen käyttöä vaikeuttavista asioista.
Mitä hyötyä käyttäjäpersoonan taustatiedoista on?
Persoonia kehitettäessä tiimi huomasi ajan kuluvan helposti persoonien yksityiskohtien miettimiseen. Minkä ikäinen hahmo on kyseessä? Onko hänellä lemmikkejä? Montako lasta hänellä on? Vai onko parisuhdetta ollenkaan, käyttääkö hän kenties deittisovelluksia? Mitä limonadimerkkiä hän juo? Onko hän korkeakoulutettu vai ei?
Hetkittäin koko touhu tuntui turhalta, eihän näistä yksityiskohdista ole mitään hyötyä itse sovelluksen kehittämisessä.
Ei olekaan. Mutta turhia nämä yksityiskohtaisemmat taustatiedot eivät suinkaan ole, jos ne valikoidaan oikein ja perustuen todelliseen asiakastutkimukseen.
Persooniin sisältyy kahdenlaista tietoa. Suoraan kehitettävään tuotteeseen liittyvää, ja välillisesti siihen liittyvää tietoa. Kehittämisen työkaluna persoonat toimisivat varmasti ilman välillisesti asiaan liittyviä yksityiskohtia, mutta niistä jäisi pois paljon samaistumiseen vaadittavaa tarttumapintaa. Palvelumuotoilussa on tärkeää muodostaa empatiaa käyttäjiä kohtaan, ja aito empaattisuus vaatii eläytymistä käyttäjän elämäntilanteeseen ja niihin ongelmiin, joita hän kohtaa. Persoonan sisältämillä tiedoilla on siis kaksi eri tarkoitusta – ensiksi perustella todisteisiin pohjautuen, miksi käyttäjät ajattelevat tietyllä tavalla ja toiseksi tarjota samaistumiseen tarvittava määrä elämänmakuisuutta. Verrataan kahta esimerkkiä.
Kummassakin persoonassa on suoraan esimerkissä kehitettävään tuotteeseen liittyvät tiedot, ja jotain voitaisiin molempien pohjalta jo suunnitella, mutta suppeamman persoonan tarpeet eivät tunnu niin konkreettisilta. Ne on helppo unohtaa, tarpeilla ei ole nimeä, eikä omistajaa. Muut tarpeet saattavat alkaa tuntumaan tärkeämmiltä, kuin nimettömän ja taustattoman haamupersoonan tarpeet.
Voiko persoona johtaa harhaan?
Lisäksi eräs persoona nimettiin aluksi erään julkkiksen mukaan, mutta sen huomattiin aiheuttavan täysin päästä keksittyjä olettamuksia henkilön ajattelutavasta. Onneksi tämä kuitenkin ymmärrettiin tarkistaa asiakastutkimusmateriaalista, ja harhaanjohtavat yksityiskohdat poistettiin – ja persoonien nimet muutettiin neutraalimmaksi.
On totta, että esimerkiksi varallisuus, sukupuoli, kansallisuus, ikä ja puhuttu kieli eivät välttämättä oikeasti vaikuta käyttäjän tarpeisiin. Vaarana on, että tosiasiassa samat tarpeet tuodaan esille useammassa persoonassa, joiden demografiset piirteet on muokattu erilaisiksi, tai että luodaan keinotekoisesti erilaisia tarpeita esimerkiksi varallisuustason tai ihonvärin mukaan. Myös persoonien huolimaton nimeäminen saattaa ohjata olettamaan henkilön olevan tietynlainen, tehden persoonasta vääriä olettamuksia aiheuttavan ja siten epätarkan. Tällaisia tietoja kannattaa harkinnan mukaan jättää persoonista pois, tai muokata tilanteen mukaan, jotta vältytään keinotekoisilta olettamuksiin perustuvilta vinoumilta. Esimerkiksi persoonat voidaan nimetä eläinlajien tai horoskooppien mukaan, jolloin vältytään liittämästä mukaan haitallisia stereotypioita, mutta niiden muistettavuus säilyy kuitenkin hyvänä.
Taustatiedoista voi olla suuri hyöty myös esimerkiksi markkinoinnin kohdentamisessa oikean tyyppisille henkilöille, testauksen suunnittelussa ja testihenkilöiden rekrytoinnissa.
Tiimi jopa tulosti tekemänsä persoonat pahvifiguureiksi, jotka pidettiin mukana työpajoissa. He saivat siten pari kollegaa lisää tiimiin. Persoonat auttoivat myöhemmin monessa asiassa, kuten sovelluksen markkinoinnin kohdentamisessa sen kohderyhmälle, testihenkilöiden rekrytoinnissa käytettävyystesteihin ja sisäisissä auditoinneissa, joissa sovelluksen ominaisuuksien hyödyllisyyttä loppukäyttäjälle arvioitiin.
Persoonat ovat vain yksi esimerkki siitä, kuinka käyttäjäymmärrystä voidaan palvelumuotoilussa jalostaa. Se on käyttökelpoinen työkalu, joka on ollut käytössä jo pitkään. Se toimii parhaiten oikein käytettynä, tarpeen mukaan muokattuna. Verkosta löytyy tuhansittain sapluunoita persoonien muodostamiseen ilman varoitustekstiä siitä, että jos teet asiakastutkimusta täyttääksesi sapluunoiden tyhjät kohdat, tulet saamaan vääriin asioihin vastaavaa dataa. Tutkimuksen tulee muodostaa käytetty sapluuna, eikä toisinpäin.
Pingback: Millaista muotoilua tarvitset? Tai tarvitsetko muotoilijaa? Me voimme auttaa varmasti. — Teamit
Pingback: What kind of design do you need? Or do you need a designer? We can definitely help. — Teamit