Käytettävyystestit

Kävin pitämässä 12.6. torstaina Pirkanmaalla kolme käytettävyystestiä, joiden tavoitteena oli löytää käytettävyysongelmia TKrekryn uuden sivuston työpaikkailmoitusten julkaisusta ja terveyskeskusten tietojen muokkauksesta ja näihin luonnollisesti mahdollisia korjauksia ja parannusehdotuksia. Avaan tässä jutussa testien pitämiseen liittyviä ajatuksiani.

Testien tavoite ja käytettävyyden mittaaminen

Testeihin liittyvät tutkimuskysymykset olivat mm:

  • Onnistuuko kirjautuminen palveluun?
  • Osaavatko käyttäjät vaihtaa salasanansa?
  • Ymmärtävätkö käyttäjät mitä tietoja terveyskeskuksesta palveluun syötetään ja miten ne näkyvät julkisella sivustolla?
  • Onnistuuko käyttäjiltä työpaikkailmoitusten tallentaminen ja julkaiseminen?
  • Ymmärtävätkö käyttäjät miten ilmoitusten julkaisu ajastetaan ja miten ilmoitukset poistuvat sivustolta?
  • Mistä tai keneltä käyttäjät pyytävät apua, jos jonkin asian tekeminen ei onnistu?

Vaikka käytettävyystestien ensisijainen tavoite oli löytää kvalitatiivista informaatiota sovelluksen käytöstä (ongelma ja korjaukset), suunnittelin myös etukäteen kvantitaviiviset mittarit sovelluksen käytettävyydelle.

Käytettävyys on numeerisesti mitattavissa oleva laatuominaisuus ja sen määritelmän mukaisia tekijöitä voidaan mitata eri tavoin. Yleensä tuloksellisuutta mitataan onnistuneiden vs. epäonnistuneiden tehtävien määrällä, tehokkuutta tehtäviin käytetyllä ajalla sekä niiden suorituksen aikana tehtyjen virheiden määrällä. Käyttäjien tyytyväisyyttä puolestaan voidaan mitata erilaisten kyselyiden ja haastatteluiden avulla tai testisession aikana testihenkilöiden ääneen ilmaisemien positiivisten vs. negatiivisten kommenttien määrällä.

TKrekryn testeissä mittareiksi valikoituivat:

  • Onnistuneiden tehtävien määrä suhteessa tehtävien kokonaismäärään.
  • Tehtävien aikana tapahtuneiden virheiden määrä.
  • Käyttäjän kommenttien laatu testin ja sen jälkeisen haastattelun aikana.
  • Testin jälkeisen käyttäjätyytyväisyyskyselyn pisteet.

En ottanut aikaa mukaan mittariksi, koska epäilin kykyäni ottaa sitä luotettavasti ja johdonmukaisesti ks. testin järjestelyt. Testejä suunnitellessa alkoi olla sellainen fiilis, että nyt alkaa olla vähän liikaa ohjelmaa yhteen tunnin mittaiseen testisessioon.

Minkä hyvänsä vähänkään monimutkaisemman sovelluksen käytettävyyttä tulisi testata useampaan kertaan sen kehityksen aikana. Esim. pelkästään jo sen takia, että ensimmäisen iteraation testien perusteella tehdyt parannukset eivät vie käytettävyyttä huonompaan suuntaan. Tällöin testien luonnetta voidaan matkan varrella muuttaa puhtaan formatiivisesta (laadullisia ongelmia) enemmän summatiiviseksi (numeerisia käytettävyyden mittareita) testi testiltä, kun sovelluksen valmiusaste kasvaa. Näin kaikkia mahdollisia mittareita ei tarvitse käyttää jokaisella testikierroksella ja testien suunnittelu ja pitäminen helpottuu.

Käytettävyysvaatimukset eivät aina päädy tarjouspyyntöihin ja määrittelyihin ja silloin, kun ne päätyvät niin epäilen, että niille ei ole useinkaan asetettu kovinkaan selkeitä mittareita. Tätä aukkoa voidaan hyvin paikata uuden järjestelmän määrittelyn aikana (joka luonnollisesti tehdään käyttäjäkeskeisesti eikö niin?) siten, että tehdään ns. benchmark-käytettävyystestit vanhalle järjestelmälle sen tehtäväanalyysin / vaatimusten keräämisen yhteydessä. Näissä mitattua tuloksellisuutta, tehokuutta ja käyttäjien raportoimaa tyytyväisyyttä verrataan sitten uuteen järjestelmään sen kehityksen aikana ja mahdollisesti käytön jo alettua, kun käyttäjät on koulutettu ja tuotantoympäristön suorituskyky optimoitua. Toivon, että ammatikseen tietojärjestelmiä ostavat henkilöt osaisivat nämä asiat ilmaista luotsaamissaan hankinnoissa jatkossa paremmin.

Testien järjestelyt

Päätin pitää testejä kolme lähinnä logistisesta syistä. Testit pidettiin testihenkilöiden omilla työpisteillä, jotka sijaitsivat eri paikkakunnilla. Neljäs testi olisi ehkä mahtunut päivään, mutta ei missään nimessä viittä.

Olin yksin liikenteessä (vettä tuli kuin esterin ****) joten sekä moderaattorin, että tarkkailijan tehtävät lankesivat vastuulleni. Lisäksi kuvittelin olevani superihminen ja pärjääväni ilman mitään nauhoitteita niin testitehtävien suorittamisesta, kuin näiden jälkeisistä haastatteluista. Testejä edeltäneessä pilotissa kollegani Johannes Pitkänen varoitteli jo nauhoitusten tekemättä jättämisestä, joten riski oli ainakin hyvin tiedostettu.

Testisessio alkoi perinteisesti esittelyillä ja testin sisällön läpikäymisessä. Sen jälkeen täyteltiin tutkimukseen osallistumisen lupalappu ja taustatietolomake, joista siirryttiin itse testitehtävien suorittamiseen.

Testihenkilöitä pyydettiin ajattelemaan ääneen tehtävien suorituksen aikana mikä oli yksi syy sille, etten lähtenyt mittaamaan tehtävien suorittamiseen kuluvaa aikaa. Testitehtävät ojennettiin lapulla testihenkilölle ja tämän tuli lukea tehtävänanto ääneen ennen sen aloittamista. Tehtävän suorittamisen jälkeen testihenkilö ojensi lapun takaisin ja kertoi vastauksen vielä ääneen. Pyrin välttämään testihenkilöiden auttamista tehtävien suorittamisen aikana ja kirjasin havainnoista muistiinpanot kynällä ja paperilla.

Kaikilla testihenkilöillä oli samat kahdeksan tehtävää suoritettavana ja näiden tekemiseen olin järkeillyt kuluvan noin 20 minuuttia. Ensimmäisen testin jälkeen muutin ajan suosiolla 30 minuutiksi. Pari testihenkilöä jännitti tilanne aluksi aika paljon, mikä myös silmin nähtävästi vaikutti parin ensimmäisen tehtävän suorittamiseen.

Testien jälkeen testihenkilöt saivat täytettäväkseen käyttäjätyytyväisyyskyselyn positiivisen SUS-lomakkeen muodossa, joka oli käännetty Timo Jokelan version pohjalta. Kyselyn täyttämisen jälkeen esitin vielä muutaman kysymyksen sovelluksen käytöstä ja siihen liittyvistä fiiliksistä ja terveyskeskuksen rekrytoinnista ylipäätään. Kirjasin myös tästä haastattelusta kevyet muistiinpanot kynällä ja paperilla.

Testien tulokset

Testitehtävien suorittamisen yhteydessä ei havaittu ns. kriittisiä käytettävyysongelmia eli niitä, jotka olisivat estäneet sovelluksen käytön ja johtaneet tehtävän epäonnistumiseen. Ainoastaan yksi tehtävä kaikkiaan 24:stä ei onnistunut, kun testihenkilö jätti sen kesken ja siirtyi seuraavaan. Luovuttaminen johtui kuitenkin mielestäni enemmänkin testitilanteen epämiellyttävyydestä ja jännittämisestä kuin kriittisestä käytettävyysongelmasta.

Kaikilla testihenkilöillä oli ongelmia omien tietojen muokkaamisessa, terveyskeskusten esittelysisältötekstien käyttötarkoituksen ymmärtämisessä ja työpaikkailmoituksen julkaisun ajastamisessa. Lisäksi jokaisella oli näiden aiheiden lisäksi muutamia muita yksittäisiä ongelmia. Havaittuihin ongelmiin tuli kaiken kaikkiaan sittemmin listattua toistakymmentä korjausta ja parannusta, jotka ovat luonteeltaan lähinnä asioiden uudelleen nimeämistä ja sijoittelua. Tehtävien suorittamisen aikana tapahtuneiden virheiden määrää oli mahdotonta tallentaa täsmällisesti kynällä ja paperilla, joten se mittari jäi kokonaan hyödyntämättä.

SUS-kyselyn pisteiden keskiarvoksi tuli tasan 80 (asteikolla 0-100), mitä voidaan pitää hyvänä tuloksena, mutta sen yleistäminen koko käyttäjäpopulaatioon ei ole mielekästä kolmen testihenkilön otoksen perusteella. Keskiarvon luottamusväli on aivan liian iso. Kaksi kolmesta testihenkilöstä antoi haastattelun aikana positiivisia kommentteja helppokäyttöisyydestä, selkeydestä ja siitä, että sovellus ei ole muuttunut liikaa vanhaan verrattuna.

Käytettävyystestaus on palkitsevaa

Käyttöliittymäsuunnittelijan näkökulmasta on erittäin palkitsevaa nähdä omien pikku kätöstensä tuotokset oikean käyttäjän murjottavana. Tilaisuus on ainutlaatuinen mahdollisuus oppia itsestään, käyttöliittymäsuunnittelusta sekä siitä miten ihmiset käyttävät niitä sovelluksia ja päätelaitteita joiden parissa työskentelet. Totuuden hetki voi olla myös selkäpiitä karmiva. Lentääkö päiviä suunnittelupöydällä hierottu ja asiakkaan suitsuttama ominaisuus roskiin, kun testihenkilöt eivät tajua siitä mitään vai onko sen käyttäminen itsestään selvää tai jopa palkitsevaa? Sen näkeminen, kun käyttäjä tekee onnistuneesti ja tehokkaasti tehtäviä ja pääsee tavoitteeseensa (sovelluksella jonka olet suunnitellut), on kokoluokkaa kovempi huume kuin esim. tieto julkaisun jälkeisestä 5% konversion noususta.

Mielestäni testit nämä onnistuivat haasteista huolimatta, koska ensisijainen tavoite täyttyi eli käyttävyysongelmia, parannusehdotuksia ja mahdollisia korjauksia löytyi. Useammalla testihenkilöllä olisi löytynyt lisää eri ongelmia ja kaikilla toistuneet ongelmat olisivat saaneet lisää todistusta ja kontekstia, mutta mielestäni lopputulos on riittävä tämän projektin ja sovelluksen puitteissa. Jos testausta tullaan tekemään vielä tälle verkkosivustolle, niin lähden tavoittelemaan suurempaa osallistujamäärää etätestauksen avulla.

Käytettävyystestaaminen kannattaa jopa näinkin pienellä käyttäjämäärällä ja on aina parempi ratkaisu testata vaikka budjetti ja resurssit olisivat kortilla, kuin jättää kokonaan testaamatta. Useimmiten on halvempaa testata ja korjata, kuin julkaista softaa jota käyttäjät eivät osaa käyttää saati tarvitse lainkaan.

Käytettävyystestaus voi olla haastavaa

Käytettävyystestaus voi myös olla haastavaa ja tämän kertaisten testien perusteella tuli muistutettua itselle, ainakin se että:

  1. Älä tunge liikaa ohjelmaa testisessioon! Tunnissa ehtii testaamaan, mutta jos tavoitteena on vähänkään syvemmin tutustua itse käyttäjiin tai tehtäviin liittyvään liiketoimintaprosessiin esim. haastattelemalla, kannattaa aikaa varata 1,5-2 tuntia.
  2. Suunnittele huolella testien tallennus. Jos et aio käyttää sähköisiä apuvälineitä, niin kohta 1 korostuu entisestään. Myös työparista on ehdoton apu, jolloin toinen voi moderoida ja toinen tarkkailla. Yhden henkilön kynäpaperitiimin kannattaa ehdottomasti keskittyä vain yhteen asiaan, sillä ihmisen tarkkaavaisuus ja muisti on rajallinen (toki kuuntelemista, keskittymistä ja muistiinpanojen tekemistä voi harjoitella tietoisesti).
  3. Testin pitäjällä ei saisi olla liikaa hattuja päässään, koska nämä voivat olla ristiriidassa keskenään. Tunnistin itsessäni ainakin seuraavat: moderaattori, tarkkailija, käyttöliittymäsuunnittelija, kouluttaja ja markkinoija. Käyttöliittymäsuunnittelija pyrki koko ajan ryntäämään parannusehdotusten kimppuun, kun taas kouluttaja ja markkinoija olisivat halunneet kädestä pitäen näyttää miten kaikki toimii ja kuinka autuaaksi tekeviä uudet ominaisuudet ovat.

Laitetaan tähän loppuun vielä muutama hävytön Amazon mainos eli suosittelen kaikkia seuraavia kirjoja lämpimästi aiheesta kiinnostuneille (tosin viimeinen vaatii jo hiukan ymmärrystä ja mielenkiintoa tilastotieteisiin):

Yksi kommentti artikkeliin ”Käytettävyystestit

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s