Jos täytyisi mainita yksi tuotekehityksen alue, jonka priorisoinnin kanssa kärvistelyä olen todistanut useammassakin organisaatiossa, olisi se käyttäjätestaus.
Käyttäjätestaus on tyypillisesti tuotteen tai palvelun testiversiolle suoritettava laadullinen kehityskeino, jolla pyritään selvittämään suunnittelutiimin näkökulmavirheitä – ja pidemmällä tähtäimellä viemään koko kehitystä käyttäjäkeskeisemmäksi.
Se on suunnittelulle sitä, mitä perinteinen ohjelmistotestaus on koodaamiselle; otetaan ammattilainen katsomaan asiaa tuorein silmin. Ja käyttäjätestauksen tapauksessa tämä ammattilainen on niin rautainen kuin vain olla voi: tuotteen tai palvelun potentiaalinen loppukäyttäjä.
Käyttäjätestauksella voidaan nopeasti tunnistaa muuten hankalasti havaittavat kontekstuaaliset käytettävyysvirheet, ja kaiken lisäksi se on niin halpaa, että heinäntekijöitäkin kadettaa! Kuluttajaproton kanssa joskus riittää pelkkä suklaapatukka ja jokunen tunti aikaa, kun taas normipalvelun kanssa hintalappu keikkuu vain muutamissa tonneissa.
Mikä käyttäjätestauksessa sitten mättää? Omasta kokemuksestani yksittäinen merkittävä asia on tiimin ajatuspinttymä siitä, että me kyllä osaamme hommamme niin hyvin, ettei lopputulosta tarvitse koeponnistaa. Se on vähän kuin keksisi omasta mielestään tosi makoisan vitsin, mutta kertoisi sen ääneen ensimmäisen kerran vasta Superbowlin live-lähetyksessä.
Aloittakaa testaus siinä vaiheessa, kun tuote on vielä niin raakile että hävettää.
On käsittämättömän ajatus, että suunnittelijan suorastaan oletetaan tekevän niin valistuneita arvauksia, että niiden toimivuutta ei ole tarpeen kokeilla. En itse ole törmännyt vielä yhteenkään käyttäjätestaukseen, jonka tuloksena ei olisi löytynyt jotain korjattavaa. Siis jotain, jota tiimi ei vain yksinkertaisesti osannut odottaa.
Vaikka projektitiimi koostuisi koko tunnetun maailman parhaista tekijöistä, ei mikään poista sitä faktaa, että he ovat kuitenkin vain oman alansa ammattilaisia, eikä kukaan heistä vastaan kokemukseltaan ja ajatusmalliltaan lopullista käyttäjää.
Ihka oikea käyttäjä nimittäin on ainoa taho, joka tuo peliin juuri oikealla tavalla subjektiivisen ennakkoasenteen, osaamistason ja käyttökontekstin. Käyttäjä ei välitä siitä, vastaako palvelu iso-standardia tai montako sprinttiä julkaisuun on jäljellä. Siinä vaiheessa, kun käyttäjä istuu tuoliin, hän ajattelee ainoastaan omaa toimintaansa, ilman minkäänlaisia projektityön laseja – ja juuri siksi onkin niin tärkeä.
Toinen ongelma on tietenkin aika ja sitä kautta raha – tai tarkemmin ottaen niiden käytön jaksottaminen. Noin nyrkkisääntönä mitään testaamista ei kannata pihistellä aivan maaliviivalle asti ja todeta sitten, ettei mitään ole enää tehtävissä.
Yksikään tiimi ei tietenkään tahallaan jätä käyttäjätestausta ihan viime tinkaan, mutta luovassa toiminnassa mukaan astuu erittäin usein täydellisyyden tavoittelu. Ominaisuutta ei vielä voi altistaa käyttäjätestaukselle, kun se ei ole vimpan päälle valmis, parit pikkubugit on fiksaamatta ja visukaan ei vastaa vielä meidän laatutasoamme.
Siinä vaiheessa, kun tiimi vihdoin on tyytyväinen ominaisuuden toteutukseen, on objektiivista palautetta jo hankala tuoda mukaan prosessiin: ei ole enää aikaa tehdä korjauksia, tai ominaisuuteen on jo laitettu niin paljon työtä, ettei projektijohto halua tehdä sitä uusiksi. Tai miten olisi kaikkien kaameuksien äiti: käyttäjä ei vain tajua… mutta kyllä sitten kun koko tuote on valmis, niin kyllä ne varmasti sitten ymmärtävät!
Oikein tehty ja kiinteäksi osaksi prosessia tuotu käyttäjätestaus on pohjimmiltaan aika helppoa priorisoida: tehkää sitä pienimuotoisesti jatkuvalla syklillä ja siinä vaiheessa, kun tuote on vielä niin raakile, että hävettää oikein kunnolla näyttää sitä kenellekään.
Ainoastaan siinä vaiheessa tiimi on avoin muuttamaan suuntaansa ja katsomaan tuotoksiaan sen ainoan oikeasti merkitsevän linssin kautta: henkilön, joka tuotetta tulee käyttämään.