Digipalvelujen käyttäjäkokemuksen laatua mitataan usein vasta silloin, kun jokin menee pieleen. Palvelu ei ole saavutettava, se on hankalakäyttöinen eikä asiakas saa asiaansa hoidettua ilman ohjeita ja tukea. Tässä vaiheessa korjaaminen on hidasta, kallista ja turhauttavaa kaikille osapuolille.
Tämä ei kuitenkaan ole sattumaa. Usein kyse ei ole yksittäisestä virheestä, vaan siitä, että käyttäjäkokemuksen laadunvarmistus on nähty testeinä, jotka tehdään lopussa eikä päätöksenä, joka tehdään alussa.
UXQA-blogisarjassa olemme aiemmin puhuneet siitä, miksi käyttäjäkokemuksen laatu ei synny sattumalta. UXQA tarkoittaa käyttäjäkokemuksen (UX) laadunvarmistusta (QA): teknistä saavutettavuutta, helppokäyttöisyyttä ja ymmärrettävyyttä, joita tarkastellaan yhtenä kokonaisuutena. Tässä kirjoituksessa keskitymme siihen, miten UXQA integroidaan osaksi digipalvelujen koko elinkaarta kerralla oikein -periaatteella.
Laatu ei synny vain osaamisesta
On helppo todeta, että hyvä laatu syntyy osaavista tekijöistä. Tarvitaan kokeneita suunnittelijoita, kehittäjiä ja sisällöntuottajia, jotka ymmärtävät käyttäjiä ja noudattavat hyviä käytäntöjä. Tämä on totta, mutta se ei yksin riitä.
Todellisuudessa jopa erittäin osaavat tiimit tekevät jatkuvasti kompromisseja. Aikataulu painaa, vaatimukset jäävät tulkinnanvaraisiksi, hankintamalli ohjaa vääriin asioihin tai vastuu laadusta hajautuu niin, ettei kukaan kanna sitä kokonaisuutena. Näissä tilanteissa UX:n laatu ei romahda siksi, etteivät tekijät osaisi, vaan siksi, ettei laatua ole määritelty, johdettu ja varmistettu systemaattisesti.
Siksi UX:n laatu ei voi olla vain yksittäisten tekijöiden ammattitaidon varassa. Tarvitaan myös selkeä, tietoinen ja riippumaton laadunvarmistus, ja ennen kaikkea päätös siitä, että UXQA on osa tekemisen perustaa.
Shift left vai vain hieman aiemmin?
Laadunvarmistuksessa puhutaan paljon shift left -ajattelusta, eli laadun huomioimisesta mahdollisimman varhaisessa vaiheessa. Ajatus on oikea, mutta käytännössä se ymmärretään usein liian kapeasti.
Monessa organisaatiossa UXQA tarkoittaa edelleen käytettävyystestausta tai saavutettavuusauditointia juuri ennen julkaisua, tai parhaimmillaan muutamaa tarkistuspistettä projektin varrella. Tämä on parempaa kuin ei mitään, mutta kyse on usein vain siitä, että laadunvarmistusta on siirretty hieman aikaisemmaksi, ei siitä, että sen rooli olisi muuttunut. Tällöin UXQA on edelleen erillinen tarkistus eikä se alkuvaiheen päätös, joka sen pitäisi olla. Laatu todetaan, mutta sitä ei varsinaisesti rakenneta.
Todellinen shift left UXQA:ssa tarkoittaa jotain muuta. Se tarkoittaa, että UX:n laatu tehdään todeksi jo määrittelyvaiheessa – riippumatta siitä, hankitaanko palvelu ulkoa vai tuotetaanko se itse – sekä suunnittelussa. Ei tarkistamalla jälkikäteen, vaan tekemällä alussa päätöksiä, jotka ohjaavat koko tekemistä oikeaan suuntaan.
UXQA alkaa määrittelyvaiheessa
Moni digipalvelun laatua koskeva ongelma on nähtävissä jo ennen kuin ensimmäistäkään rautalankaa väännetään tai luonnosta piirretään. Määrittelyvaiheessa – ja hankinnassa silloin, kun palvelua ostetaan – päätetään, mitä pidetään laatuna, miten sitä mitataan ja kuka vastaa sen varmistamisesta.
Jos hankinnassa painottuvat vain hinta, aikataulu ja tekniset vaatimukset, UXQA jää helposti sivurooliin. Saavutettavuus, helppokäyttöisyys ja ymmärrettävyys saatetaan mainita, mutta niitä ei sidota konkreettisiksi vaatimuksiksi eikä jatkuvaksi tekemiseksi.
Laadukas määrittely tekee päinvastoin. Se määrittelee UX:n laadun keskeiseksi osaksi onnistumista, edellyttää jatkuvaa laadunvarmistusta eikä vain loppuarviointia, ja tunnistaa riippumattoman UXQA:n roolin tilaajan työkaluna. UXQA ei ole toimittajan sisäinen asia, vaan keino varmistaa, että palvelu täyttää vaatimukset ja toimii oikeasti käyttäjilleen.
Tässä kohtaa UXQA on jo selvästi alkuvaiheen päätös.
Suunnittelu ja tuotanto – yhdessä, mutta ei yksin
Kun projekti on käynnissä, UX:n laatu syntyy lukemattomissa arjen päätöksissä. Tekijöiden osaaminen on ratkaisevaa, mutta se ei poista tarvetta taholle, joka katsoo kokonaisuutta käyttäjän näkökulmasta, tunnistaa toistuvat riskit ja uskaltaa kysyä vaikeita kysymyksiä.
Siksi UXQA:n rooli ei voi olla vain sisäinen arviointi tuotantotiimin sisällä. Sen on oltava riittävän itsenäinen ja riippumaton, jotta se pystyy toimimaan laadun varmistajana, mutta samalla riittävän lähellä tekemistä, jotta yhteistyö säilyy luontevana.
Hyvä UXQA ei jaa vain virhelistoja. Se perustelee havainnot käyttäjävaikutuksilla, tukee oppimista ja auttaa tiimiä tekemään parempia ratkaisuja itse. Kun laadunvarmistus nähdään valmentavana ja kehittävänä roolina, se ei hidasta tekemistä vaan vähentää korjaustyötä myöhemmin.
Kerralla oikein on ennen kaikkea ennakointia
“Kerralla oikein” ei tarkoita täydellisyyttä tai sitä, ettei virheitä koskaan synny. Se tarkoittaa, että tunnetut riskit tunnistetaan ajoissa, laatuvaatimukset ovat näkyviä ja yhteisesti ymmärrettyjä, ja ongelmat eivät tule yllätyksinä projektin lopussa.
Kun UXQA on integroitu osaksi prosessia, saavutettavuus ei ole erillinen tarkistus vaan suunnittelun ja kehityksen lähtökohta. Helppokäyttöisyys ei ole mielipidekysymys, vaan arvioitava ominaisuus. Ymmärrettävyys ei jää oletukseksi, vaan sitä testataan ja varmistetaan systemaattisesti.
Tällöin UXQA ei ole enää viimeinen portti ennen julkaisua, vaan jatkuva tuki paremmille päätöksille.
UXQA on myös luottamuskysymys
Se toimii parhaiten silloin, kun se perustuu tekijöiden osaamiseen ja motivaatioon, prosessiin, joka tukee laatua eikä taistele sitä vastaan, sekä riippumattomaan arviointiin, jonka tarkoitus on parantaa lopputulosta, ei etsiä syyllisiä. Kun UX:n laadunvarmistus integroidaan hankintaan, suunnitteluun ja tuotantoon, kyse ei ole ylimääräisestä vaiheesta vaan tietoisesta päätöksestä tehdä digipalveluja ihmisille, jotka niitä oikeasti käyttävät.
Lopulta UXQA on myös investointipäätös
Panostus laadunvarmistukseen koko digiprojektin ajan maksaa itsensä takaisin vähentyneenä korjaustyönä ja sujuvampana tuotantona. On kaksi tapaa tehdä: kerralla oikein tai myöhemmin uudestaan. Riippumaton UXQA auttaa varmistamaan, että oikeita kysymyksiä esitetään silloin, kun niihin vastaaminen on vielä helppoa ja edullista.
Blogin kirjoittajana Ari-Pekka Saarela, Q-Factoryn kehitysjohtaja ja eQual-tiimin vetäjä.
