Nyt jatkuu käytettävyystutkimusta koskeva blogisarja. Ensimmäinen osa oli nimeltään ”Miksi”. Tämä toinen osa keskittyy kätettävyystutkimuksen osalta kysymykseen ”Milloin”, eli mikä on oikea käytettävyystutkimuksen ajoitus?

Tarkoitan käytettävyystutkimuksella tässä yhteydessä tieteenalaa ja toimintatapaa, jossa tuotteiden käyttöliittymiä tutkitaan tavoitteena minimoida erilaisten käyttäjien kohtaamat käytettävyysongelmat.

Osa 2 – milloin?

Milloin? Se on yksi yleisimmistä kysymyksistä, jonka kuulen asiakkailtani. Ja vastaukseni on aina sama: mitä aiemmin, sen parempi. Käytettävyysongelman korjaaminen on nimittäin 100 kertaa helpompaa tuotekehityksen alussa kuin se on julkaisemisen jälkeen. Kerron seuraavaksi, mistä tämä johtuu.

Tuotekehitystapa 1 – ei tehdä käytettävyystutkimusta

Tuotekehitystiimi pakertaa johtajan vision perusteella uutta huipputuotetta, jonka avulla maailmalaiset voivat vuokrata autoaan muiden käyttöön silloin, kun eivät itse tarvitse sitä.

Tuotekehitysprosessi menee periaatteessa niin, että tiimi työstää tuotetta eteenpäin ja esittelee tulokset aina kahden viikon välein johtajalleen. Johtaja kommentoi, antaa risuja ja ruusuja, ja homma rullaa eteenpäin. Välillä tehdään omalla intuitiolla ja välillä lainataan ratkaisuja muista sovelluksista. TEKESin ja Finnveran suosiollisella avustuksella markkinoille tuupataan valmis sovellus.

Sovelluksen perustoiminta

Sovelluksen käyttö on hyvin suoraviivaista:
1. Ota autosta kuva ja anna muut olennaiset tiedot
2. Kerro, milloin auto on käytettävissä
3. Kerro, mistä auton voi noutaa ja minne se palautetaan
4. Kerro pyytämäsi hinta
5. Potentiaalinen auton vuokraaja voi selailla autoja haluamillaan yksityiskohdilla – esimerkiksi 5-hengen farmariauto Seinäjoen keskustassa.

Tämä kaikki on niin yksinkertaista, että mikä muka voi mennä pieleen? Markkinointi on onnistunut ja käyttäjiä on saatu palvelun piiriin iso määrä, mutta tarvitsijat ja auton omistajat eivät jostain syystä kohtaa. Tiimi käy prosessia läpi ja se on aivan itsestään selvä. Kenelläkään heistä ei ole sovelluksen käytössä mitään ongelmaa.

Käyttäjät kohtasivat ongelmia kuitenkin

Yleensä käyttäjät eivät kovinkaan helposti anna palautetta vaan siirtyvät vain käyttämään muita palveluita. Mutta tällä kertaa tiimillä käy onni ja muutama käyttäjä kertoo heille ongelmistaan:
1. Jostakin syystä tilauksen hyväksymisnappi ei toimi????
2. Samoja autoja näkyy olevan useita kappaleita ja niissä on ristiriitaisia varaustietoja???
3. Vuokralle laitettavan auton tietojen syöttäminen mobiilikäyttöliittymällä on vaivalloista.

Kohdan 1 ongelmaksi ilmenee tarkemmalla tutkimisella se, että tilaaminen onnistuu vain, jos palvelun käyttöehdot on ruksattu hyväksytyiksi. Käyttöehtojen hyväksyminen ei näy samassa näkymässä tilauksen hyväksymisnapin kanssa, joten osalta käyttäjistä tämä jää huomaamatta.

Kohdan 2 ongelman on aiheuttanut puutteellinen palautteenanto käyttäjälle. Käyttäjälle ei ole selkeästi ilmaistu, että auton tietojen syöttönappia on nyt painettu onnistuneesti. Osa käyttäjistä on hakannut nappia moneen kertaan, kun ovat luulleet, että mitään ei tapahdu. Järjestelmä on virheellisesti sitten rekisteröinyt palveluun useaan kertaan saman auton, mikä on ollut omiaan sekoittamaan autoa etsiviä käyttäjiä.

Viimeisen kohdan ongelmat johtuvat siitä, että käyttäjien on osuttava esimerkiksi ominaisuusvalinnoissa nimenomaan pieneen ruksittavaan kohtaan. Osuminen itse tekstiin ei riitä.

Mikä käytettävyystutkimuksen puuttumisessa tuli maksamaan?

Ensimmäisen käytettävyysongelman korjaaminen ei ole kovinkaan kallista. Kustannuksia toki tulee valmiin korjaamisessa aina jonkin verran, koska pitää huomioida kaikki olemassa oleva koodi. Ja sekin on hankalaa, että osa käyttäjistä on jo tottunut näkemään ruksattavan kohdan tietyssä paikassa ja joutuvat nyt opettelemaan uuden tavan. Eniten ongelma on tullut maksamaan menetettynä tulona, kun auton varaaminen ei ole onnistunut. Käyttäjät eivät myöskään suosittele palvelua kavereilleen innosta hihkuen, jos palvelu ei toimi.

Toinen käytettävyysongelmakaan ei koodausmielessä ole iso asia. Pitää vain värkätä selkeä ilmoitus ja latausta ilmaiseva merkki, jotta käyttäjä tietää painaneensa nappia. Tuplana olevien autojen poistaminen sen sijaan on työlästä. Ja mitäs tehdään poistettavissa autoissa oleville varauksille? Aika manuaaliseksi asianhoidoksi tämä menee, koska tätä ei voi hoitaa millään yleisellä kirjeellä. Käyttäjän pitäminen edes vähän tyytyväisenä vaatii henkilökohtaisen yhteydenoton ja ehkä apua uuden vuokra-auton tai vuokraajan etsimisessä. Pahaa mieltä on jo vähän siellä sun täällä.

Raksiruutuun osumisen korjaus on kohtalaisen yksinkertainen iltapuhde. Työläintä on varmistaa, että kaikki toimii muutosten jälkeen, niin kuin on tarkoitus.

Tuotekehitystapa 2 – käytettävyystutkimusta tehdään säännöllisesti

Optimaalisessa tuotekehitysprosessissa käyttöliittymäsuunnittelu on koko ajan muuta porukkaa askeleen edellä. Kun aletaan vaikka koodaamaan autopalvelussa osaa, jossa käyttäjä hyväksyy tilauksen, käyttöliittymäsuunnittelija on jo hionut prototyyppien ja oikeiden käyttäjien kanssa käyttöliittymän lähes ongelmattomaksi. Tällainen toimintatapa pitää tiimin tehon hyvällä tasolla ja myös tekijät tyytyväisinä. Mikäs sen mukavampaa koodareille kuin valmiiksi pureskeltu käyttöliittymä. Ei tarvitse muutella ratkaisuja koko ajan vaan puskea vaan eteenpäin. Ei tarvitse pysähtyä pohtimaan, että mitenköhän jokin kohta toimii. Käytettävyystutkimuksen ajoitus oikein palvelee koko projektia.

Ehtojen hyväksymisongelma voidaan huomata käytettävyystestillä jo silloin, kun käyttöliittymä on pelkkä prototyyppi. Korjaaminen vaatii vain pienen muutoksen prototyyppiin ja taas voi testata uudestaan käyttäjien kanssa.

Autojen tuplana näkymisen ongelma tulisi karsittua jo sillä, että käyttöliittymäsuunnitelmaa tarkasteltaisiin nojaamalla helppokäyttöisyyden nyrkkisääntöihin. Palaute on yksi tärkeimmistä suunnitteluperiaatteista. Taas tehdään muutosta vain suunnitelmaan/prototyyppiin. Huomattavan helppoa verrattuna siihen, mitä jouduttiin värkkäämään tuotekehitystapa 1:ssä.

Kolmas ongelma on taas tyypillinen asia, joita selviää käytettävyystesteissä. Asia vaikuttaa itsestään selvältä, mutta usein juuri tällaiset jäävät tiimiltä huomaamatta. Käytettävyystestissä käyttäjä painelee turhaan tekstikohtia eikä mitään tapahdu. Asia kirjataan ylös ja osataan huomioida toteutuksessa saman tien.

Satakertainen vaiva

Väännän vielä rautakangesta, mistä se johtuu, että käytettävyysongelmien korjaaminen on sata kertaa kalliimpaa julkaisun jälkeen kuin projektin alussa. Ytimessä on se, että alkuvaiheessa ei tarvitse muuttaa kuin prototyyppiä/suunnitelmaa. Mitä alkeellisempi prototyyppi, sen helpompi muuttaa. Paperiprototyypissä vedät korjauskynällä toimimattoman kohdan yli ja piirrät uuden version tilalle.

Valmiissa tuotteessa korjauskynä ei enää riitä, vaan joudut aina koodaamaan, tarkistamaan, tekemään graafista suunnittelua, menettämään asiakastyytyväisyyttä ja markkinoimaan muutoksista. Hyvinkin helposti tuo kaikki maksaa sata kertaa enemmän kuin korjauskynän käyttö. Sata ei välttämättä edes riitä!

Tee siis käytettävyystestaamista jo alkuvaiheessa. Se on täysin mahdollista, aika helppoakin ja edullista.

Yhteenveto

Käytettävyystutkimus – lyhyt oppimäärä -osa 2: Milloin? käsitteli käytettävyystutkimuksen ajoitusta tuotekehitysprosessissa. Käytettävyystutkimus on sitä edullisempaa, mitä aiemmin sitä tehdään. Koskaan ei kuitenkaan ole liian myöhäistä. Jos käytettävyysongelma on päässyt julkaistuun tuotteeseen asti, sen korjaaminen on aina kannattavaa. Käyttäjien tyytyväisyys paranee, myynti helpottuu, tuotetuen ja -koulutuksen tarve vähenee ja sovelluksen käytön tehokkuus lisääntyy.

Itse asiassa koko ajatuksen voi kääntää toisinkin päin – investoinniksi. Käytettävyyspanostus on aina kannattava, mutta projektin alkuvaiheessa voit saada jopa 100 kertaa suuremman tuoton käytettävyyspanostukselle kuin loppuvaiheessa!

Kolmannessa ja viimeisessä osassa tulen käsittelemään kysymystä ”Miten”. Miten käytettävyystutkimusta tehdään?

* Lähde: Cost-Justifying Usability: An Update For an Internet Age. 2005.

Koko sarja

Käytettävyystutkimus – lyhyt oppimäärä – Osa 1/3: Miksi?

Käytettävyystutkimus – lyhyt oppimäärä – Osa 2/3: Milloin?

Käytettävyystutkimus – lyhyt oppimäärä – OSa 3/3: Miten?