Pienimmän riesan tie: käyttäjälähtöinen konseptisuunnittelu

Toukokuussa 2014 julkaistu FlowIT-tutkimus paljastaa julkishallinnon tietotyöläisten haasteellisen arjen – 65 prosenttia kyselyyn vastanneista koki tietotekniikkaan liittyvien ongelmien haittaavan päivittäistä työntekoaan ja arvioi hukatuksi ajaksi neljä tuntia viikossa. Pelkästään menetettynä työaikana aiheutuu jopa 275 miljoonan euron vuotuinen kustannus valtiolle. Tutkimuksessa nostetaan esille keskeiseksi tekijäksi erilaiset käytettävyyteen ja käyttäjäkokemukseen liittyvät ongelmat. “Ehkä tässä on vielä vahva ajatus, että työympäristössä ihmisiä voidaan kouluttaa järjestelmien käyttämiseen. Sen sijaan pitäisi lähteä siitä, että uuden järjestelmän käyttöönotto voitaisiin tehdä kouluttamatta ihmisiä.” [1] Tähän ongelmakenttään voitaisiin vaikuttaa merkittävästi jo aikaisessa vaiheessa käyttäjälähtöisellä suunnittelulla.
Kehitysprojektien alkuvaiheessa on tyypillistä dokumentoida esimerkiksi sidosryhmiä, prosesseja, käyttötapauksia, tietorakenteita ja rajapintoja tavoitteena määritellä sekä asiakkaan liiketoiminta että tekninen ympäristö. Näistä uutetaan usein suoraan joukko vaatimuksia uudelle järjestelmälle tarkastelematta kuitenkaan aidosti ja määrämuotoisella tavalla käyttäjän tarpeita, motivaatioita ja käyttökontekstia. Tämän seurauksena myös erilaisten vaihtoehtoisten konseptien paremmuus käyttäjälle jää testaamatta. Tuoreen tutkimuksen mukaan esimerkiksi kokonaisarkkitehtuurityö näyttäytyy käytännössä useimmiten hyvin IT-keskeisenä [2]. Tulevien käyttäjien ja käyttäjien tarpeiden tunnistaminen ei ole useinkaan itsestään selvä osa projektien toimitussisältöjä, joten vaatimusmäärittelyssä ja toteutuksessa oikaistaan käyttäjälähtöisyyden kustannuksella. Joudutaan tilanteeseen, jossa jo alkuvaiheessa esitetään vaatimuksia, jotka ovat käyttäjien kannalta epämääräisiä ja jopa virheellisiä.
Jotta voitaisiin varmistua jo projektin alkuvaiheessa ollaanko ratkaisemassa oikeita asioita oikeilla lähestymistavoilla, tarvitaan selkeitä menetelmiä, joilla voidaan löytää ja testata nopeasti käyttäjien tarpeisiin pohjautuvia oletuksia. Käyttäjälähtöisen suunnittelun keskiössä on pitää käyttäjänäkökulmaa esillä koko projektin ajan monien eri menetelmien avulla. Käyttäjälähtöisen suunnittelun näkökulmasta projekti alkaa usein konseptisuunnittelulla, jonka avulla luodaan yhteinen visio toteutettavasta järjestelmästä. Konseptisuunnittelun ydintavoitteina on määritellä järjestelmän halutut liiketoimintavaikutukset, selvittää käyttäjätarpeita sekä luoda, priorisoida ja testata näihin perustuvia oletuksia ja suunnitteluratkaisuja yhdessä käyttäjien kanssa. Käyttäjälähtöisessä konseptisuunnittelussa on näin ollen sama pyrkimys kuin ketterissä projektimenetelmissä – pyrkimys “epäonnistua” nopeasti ja välttää tuotoksia, joiden merkitystä ja toimivuutta ei voida nopeasti arvioida.
Konseptisuunnitteluun soveltuvat käyttäjälähtöiset menetelmät voivat olla samoja kuin muissakin projektin vaiheissa – esimerkiksi sidosryhmähaastattelut, persoonat ja skenaariot, määrämuotoista prosessia seuraavat suunnittelutyöpajat (design studio), yhteenkuuluvuuskaaviot (affinity diagram), luonnokset (sketches), storyboardit, rautalankamallit ja eri tavoin toteutetut prototyypit. Joissakin tapauksissa voidaan tuottaa jopa jonkinlainen minimitoteutus (minimum viable product, MVP), jolla voidaan arvioida vaikkapa potentiaalisen markkinan suuruutta testaamalla yleisesti käyttäjien kiinnostusta. Uusien palveluiden ja tuotteiden innovoinnissa ja konseptoinnissa edellä mainittuja käyttäjälähtöisiä menetelmiä voidaan hyödyntää yhdessä erilaisten liiketoimintapainotteisempien discovery-menetelmien kanssa [4].
Konseptisuunnittelun aikana rautalankamalleilla tai kevyillä prototyypeillä on tärkeä tehtävä: niiden avulla voidaan arvioida varsin konkreettisesti eri suunnitteluratkaisuja käyttökontekstissa ennen tarkkoihin toteutusvaatimuksiin päätymistä. Karkeat luonnokset ja rautalankamallit ovat usein käytännöllisin tapa visualisoida ja hahmottaa vaikeitakin kokonaisuuksia. Samalla sidosryhmien huomio keskittyy käyttäjille tärkeimpien asioiden arviointiin. Konseptisuunnittelulla voidaan tutkia myös korkealla tasolla tietoarkkitehtuuria sekä tarvittavan tiedon ja toimintojen löytymistä. Huomioitavaa on, että liian laajat dokumentaatiot ja kaaviot sekä tarkkaan viimeistellyt käyttöliittymäsuunnitelmat konseptoinnin yhteydessä voivat nostaa kynnystä kommentoida ja tarvittaessa hylätä asioita. Konseptisuunnittelun haasteena on löytää suunnittelulle ja tuotoksille sopiva tarkkuus ja näkökulma, ettei päädytä vesiputousmallisesti määrittelemään järjestelmää toteutusnäkökulmasta yksityiskohtineen etukäteen.
Käytetyistä menetelmistä ja tuotoksista riippumatta on oleellista järjestelmällisesti priorisoida ja testata tunnistettuja oletuksia. Lisäksi on tärkeää pyrkiä konseptointiin väistämättä kuuluvasta kohinasta huolimatta kohti järjestelmän haluttuja vaikutuksia ja säilyttää kirkas kokonaiskuva. Onnistunut konseptisuunnittelu vaatii “komentoketjuista” riippumatonta rohkeutta kaikilta sidosryhmiltä – on uskallettava sanoa ääneen kun jokin esitetyistä oletuksista ei toimi tai keskustelu ajautuu väärille raiteille. ”If it disagrees with experiment, it’s wrong.” (Dr. Richard Feynman) [3]
Käyttäjälähtöisen suunnittelun menetelmillä aikaansaatu konseptisuunnitelma tuottaa jo aikaisessa projektin vaiheessa hyvin perusteltuja vaatimuksia ja suunnitteluratkaisuja. Korkealaatuinen konseptisuunnitelma tarjoaa vankan lähtökohdan päätöksenteolle, suunnittelun tarkentamiselle ja toteutuksen aloittamiselle. Tuloksena on kivuttomampi toteutusvaihe, valmiin toteutuksen hyvä käyttäjäkokemus sekä parantunut käyttäjätyytyväisyys ja näiden kautta asiakkaalle syntyvät kustannussäästöt. Konseptisuunnitelma ei ole kuitenkaan yksinään ratkaisu kaikkeen – sen yhteydessä ei yleensä kuvata tarkkaan teknisiä yksityiskohtia eikä testata esimerkiksi käyttöliittymän yksityiskohtia ja lopullista käytettävyyttä. Siksi käyttäjälähtöinen suunnittelu ei rajoitukaan vain projektin alkuvaiheisiin – toteutuksen alkaessa käyttäjälähtöisen suunnittelun menetelmillä pureudutaan yhä tarkemmin yksityiskohtiin, arvioidaan toteutuksen vastaavuutta käyttäjien tarpeisiin ja reagoidaan muuttuneisiin tilanteisiin ja mahdollisiin teknisiin rajoitteisiin. Käyttäjälähtöinen suunnittelu ei siis ole yksittäinen vaihe tai tuotos vaan luonteva osa koko ketterän projektin elinkaarta.
[1] Montako tietojärjestelmää työpaikallasi on? Trafissa niitä on 170. (YLE, 23.5.2014)
[2] Jakobsson, Aino: User-Centered Aspects in Enterprise Architecture Practices: Exploratory study on the Perceptions of Finnish Enterprise Architecture Practitioners (2014)
[3] Gothelf, Jeff & Seiden, Josh: Lean UX (2013)
[4] McGrath, Rita Gunther & MacMillan, Ian C.: Discovery-driven growth: a breakthrough process to reduce risk and seize opportunity (2009)