Menu


Pikakurssi käyttäjätestauksen suorittamiseen

Aug 3rd 2017

Käyttäjä­testaus on tehokkain tapa varmistaa palvelun tai sovelluksen käytettävyys. Tästä kirjoituksesta löydät pikakurssin käyttäjä­testauksen suorittamiseen ja tarkastuslistan testauksen aikana toimimiseen. Kirjoitus on suunnattu kaikille käytettävyydestä kiinnostuneille, ja siten painopiste on käytännön­läheisessä ja realistisessa toteutuksessa.

Käytettävyys­testaus (tai käyttäjä­testaus) on tapahtuma, jossa testikäyttäjät suorittavat ennalta määrättyjä tehtäviä käytettävyy­sasiantuntijan havainnoidessa, tarkoituksena havaita mahdollisia käytettävyysongelmia. Testattava ratkaisu voi olla prototyyppi­asteella oleva suunnitelma tai jo valmis ratkaisu, jonka käytettävyyttä halutaan parantaa.

Käytettävyystestaus on yhdistelmä sitä, minkä suunnittelija olettaa käyttävän tekevän, ja sitä minkä käyttäjä oikeasti tekee

Käytettävyys­testejä voi suorittaa niin livenä kuin verkonkin yli, sekä valvotusti tai ilman asiantuntijan valvontaa. Tämä kirjoitus keskittyy valvotusti paikan päällä suoritettavan käytettävyys­testin järjestämiseen.

Lataa mallipohjat eri vaiheisiin
Käytettävyys­testauksen tehtävien esimerkki
Käytettävyys­testauksen rekrytointikutsun malli
Käytettävyys­testauksen suoritusvaiheen tarkastuslista
Purkuvaiheen Excel-esimerkki
Analyysivaiheen Excel-esimerkki

Mitä käyttäjä­testaus maksaa?

Käyttäjä­testaus ei useimmiten vaadi mitään erityisiä välineitä; yksinkertaisimmillaan pelkkä tietokone/älypuhelin ja hiljainen tila riittää. Isossa maailmassa toki hifistellään silmänliikekameroiden ja kaksisuuntaisten peilien kanssa, mutta tyypillisesti kulut koostuvat miltei täysin henkilötyöstä. Jos käytettävyysalan ammattilainen löytyy omasta takaa, voi ”sissitestausta” vetää käytännössä ilmaiseksi.

Mikäli testilaitteet löytyvät omasta takaa, syntyvät ainoat hankintakustannukset testaustilanteen nauhoituksesta. Tyypillisesti nauhoitussovelluksille tulee hintaa noin 50 € per laitetyyppi.

Henkilötyön osalta on vaikeaa heittää tarkkaa arvoa, mutta viiden hengen laajuiseen käyttäjä­testaukseen kuluu kaikkine järjestelyineen tyypillisesti noin viisi työpäivää. Luonnollisesti tämä työ täytyy olla käytettävyysalan henkilöiden suorittamaa, ja varsinkin purku- ja analyysivaiheessa ammattilaisten hyödyntäminen on välttämätöntä.

käyttäjä­testauksen kulku

Tämän kirjoituksen malli on sovellettavissa pieniin ja keskisuuriin käytettävyys­testauksiin. Prosessimalli on käytännössä sama projektin koosta riippumatta, mutta pienemmissä tiimeissä dokumentaation laajuus on pienempi (testaaja, analysoija ja suunnittelija ovat usein sama henkilö).

  1. Testattavien kokonaisuuksien rajaus
  2. Testin suunnittelu
  3. Testikäyttäjien rekrytointi
  4. Testin suorittaminen
  5. Testimateriaalin purku
  6. Analyysi ja raportointi

Käytännön minimitaso käyttäjä­testaukselle ovat kohdat 2 ja 4. Mikäli kyseessä on autotalli­firmaa suurempi kokonaisuus, ovat kohdat 1–5 käytännössä pakollisia. Viimeisen vaiheen erillinen raportointi tulee kyseeseen lähinnä silloin kun projektihallinnolliset syyt tulevat mukaan kuvioihin.

1. Testattavien kokonaisuuksien rajaus

Käytettävyyttä voidaan toki testata ilman suunnitelmaa, ihan vaan päästämällä testikäyttäjä seikkailemaan testattavassa ympäristössä ja etsimällä huomionarvoisia havaintoja. Kohdistetumpia vastauksia kuitenkin saadaan esittämällä tarkempia kysymyksiä: mitä osioita halutaan testata ja minkä tyyppisillä käyttäjillä?

Esimerkkejä testattavista kokonaisuuksista ovat esimerkiksi haun käyttäminen, tietyn tiedon löytäminen, tuotteen ostaminen tai sovelluksen asentaminen. Mikäli prosessi on hyvin pitkä tai monimutkainen, kannattaa siitä testata osissa.

Kirjoita ranskalaisilla viivoilla, mitä haluat testata. Heti kättelyssä ei kannata yrittää haukata liian suurta kakkua. Tunnista ratkaisustasi kaikkein tärkeimmät alueet ja keskity aluksi niihin – vältät ongelmaähkyn ja prosessi eteneekin sujuvammin pienissä askelissa. Toki, jos testattava kokonaisuus on hyvin pieni (kuten yrityksen www-sivut), on koko paketti mahdollista testata kerralla.

2. Testin suunnittelu

Tavoitteet siis selvillä? Hyvä. Sitten on aika pähkäillä, miten valituista kokonaisuuksista saadaan järkevää tietoa ulos. Käyttäjä­testauksen suunnittelu sisältää:

  • Laitekannan valinnan (desktop, mobiili, konsolit…)
  • Testikäyttäjien määrä
  • Testauksen konteksti
  • Testitehtävät

Laitekanta ja testikäyttäjien määrä korreloivat molemmat tulosten yleistettävyyttä ja löydösten määrää. Yleisesti ottaen alle kymmenellä testikäyttäjällä saa löydettyä miltei kaikki löydettävissä olevat käytettävyysongelmat, mutta jo kolmella-neljällä käyttäjällä on varsin hyvin mahdollista löytää tärkeimmät ongelmat. Huomaa, että eri laitteiden testitulokset eivät useimmiten ole täysin vertailukelpoisia; kymmenen testikäyttäjää kuudelle eri laitteelle ei ole riittävä määrä.

Yleensä rauhallinen huone on riittävä testiympäristö

Testauksen konteksti on tärkeää lähinnä silloin, jos halutaan testata ammattisovellusta (kuten taksikuljettajan ajotietokonetta) tai erityiskäyttöön tehtyä ratkaisua (kuten juoksu- tai leivontasovellus). Mikäli käytön konteksti on tärkeä, on testaustilanne syytä järjestää todellisuutta vastaaviin olosuhteisiin. Muussa tapauksessa ns. laboratorio-olosuhteet – siis rauhallinen huone – on riittävä.

Testitehtävät ovat testikäyttäjille suoritettavaksi annettavia, esilaadittuja tehtäviä, joiden on tarkoitus kuljettaa testikäyttäjiä testin tavoitteita sivua polkuja pitkin. Tehtäviä suunnitellessa on tärkeää tehdä niistä mahdollisimman realistisia ja yksiselitteisiä. Tyypillinen tehtävä voisi olla esimerkiksi ”Etsi verkkokaupasta halvimmat 3-vuotiaalle sopivat kumisaappaat”.

Tehtävän realistisuutta voi kasvattaa tehokkaasti tekemällä siitä avoimen skenaarion. Tällöin testikäyttäjän on helpompi samaistua tehtävän asetteluun, ja myös ilmenevät käytettävyysongelmat ovat realistisempia. Avoin skenaario voisi olla esimerkiksi ”Etsi palvelusta kolme itseäsi eniten kiinnostavaa kurssia ja ilmoittaudu niille itsellesi sopivina ajankohtina. Käytettävissäsi on 800 €.”

Lataa tästä käytettävyys­testauksen tehtävien esimerkki

Yhden testikäyttäjän tehtäviin käytettävissä oleva aika kannattaa mitoittaa noin 30 minuuttiin. Tehtäviä ei siis kannata olla kovin montaa, käytännössä kolme-neljä tehtävää on maksimi. Avoimien skenaarioiden kohdalla on hyvä muistaa, että niiden suorittamine vie tyypillisesti moninkertaisesti aikaa suljettuun tehtävään verrattuna.

Kun olet saanut tehtävät hyvään kuosiin, vedä se läpi kertaalleen sellaisen tuttavan tai kollegan kanssa, jolle testattava ratkaisu ei ole entuudestaan kovin tuttu. Näin saat realistisemman käsityksen tarvittavasta ajasta ja voit vielä hienosäätää sanamuotoja.

3. Testikäyttäjien rekrytointi

Käytettävyys­testauksen tulosten laatu riippuu hyvin vahvasti valittujen testikäyttäjien valinnasta. Jos testikäyttäjät eivät vastaa kohderyhmää, tai valinta on muutoin vääristynyt, ovat tulokset yhtä tyhjän kanssa. Kaiva aluksi esille käyttäjädatasi ja pohdi millaisilla käyttäjillä haluat käytettävyys­testausta tehdä.

Käytettävyystestaus ei ole innovointitapahtuma, eikä siinä ole tarkoituksenakaan luoda uusia, tavallisuudesta poikkeavia ideoita. Ei ole mitään järkeä testata senioreille tarkoitettua sovellusta teineillä, tai asiakaspalvelijoiden työvälinettä IT-osaston väellä.

Valitse siis testihenkilöiden perusmassaksi kohderyhmäsi kannalta tyypillisiä henkilöitä, sisällyttäen mukaan korkeintaan yksi tai kaksi erityiskäyttäjää. Kohderyhmän sisäinen vaihtelu – esimerkiksi sukupuolen tai tietoteknisten kykyjen osalta – sen sijaan on toivottavaa, mikäli sellaista kohderyhmässäsi esiintyy. Mikäli käyttäjäkuntasi on erittäin kirjavaa, on järkevää jakaa testi useaan osaan, jo pelkästään työmäärällisistä syistä.

Rekryä valmiiden asiakaskanavien kautta, jos mahdollista

Testikäyttäjien rekrytointi on helpointa jo valmiista palvelukanavasta, esimerkiksi kanta-asiakasohjelman kautta. Mikäli sinulla ei ole valmista poolia mahdollisista testikäyttäjistä, kannattaa käyttää hyödykseen erilaisia verkostojaan ja varautua suhteellisen pitkäkestoiseen prosessiin.

Rekryäminen lähipiiristä ei yleensä ole suositeltavaa. Käytettävyys­testauksessa haetaan kipeän kriittistä palautetta, eivätkä tuttavat useimmiten osaa suhtautua tilanteeseen riittävän neutraalisti. Jos et yksinkertaisesti vain saa testeihin muita kuin omia tuttujasi, kannattaa testihenkilöille kertoa, että hoidat itse vain itse testausta, eikä sinulla ole mitään tekemistä itse kehitystyön kanssa.

Testikäyttäjien rekrytointia varten tarvitset rekrytointikutsun, jossa mainitaan

  • Testattava ratkaisu (jos vain mahdollista)
  • Lyhyt kuvaus testaustilanteesta
  • Käytännön asiat: valmistautuminen, pysäköinti, osallistumisesta annettava korvaus
  • Ajankohta

Lataa tästä käytettävyys­testauksen rekrytointikutsun malli

Rekrytointikutsussa kannattaa kiinnittää suoraan tietyt testiajankohdat, jotta vältyt uuvuttavalta kalenterirallilta. Osalle ilmoittautuneista (10–20 %) ilmaantuu tyypillisesti esteitä, eli varahenkilöiden jemmaaminen on fiksua.

4. Testin suorittaminen

Käytettävyys­testauksen lähestyessä on valmistautuminen tärkeää. Testaustilanteen ohjaaminen voi vaatia, varsinkin aloittelevalla testaajalla, suuren osan huomiostasi, eli improvisoinnin varaan ei kannata laskea.

Tarkastuslista testien valmisteluvaiheeseen

  • Käytettävien testilaitteiden päivitys
  • Nauhoitussovellusten asentaminen
  • Mahdollisten sovellusten asentaminen ja käyttäjätunnusten luominen
  • Testitehtävien tulostaminen paperille
  • Demokäyttäjä­tunnusten tulostaminen paperille

Suosin itse aina tulostettuja ohjeita. Testaustilanteen riskitekijät kannattaa minimoida mahdollisimman tarkasti, eikä paperien kanssa ole vaaraa virran loppumisesta tai ohjelmistovirheestä. Osa testikäyttäjistä voi olla heikkonäköisiä, joten tuloste teksti suurella fonttikoolla.

Mikäli testaat sovellusta, joka vaatii rekisteröitymistä, tulosta myös demo­käyttäjä­tunnukset. Tällöin testikäyttäjän ei tarvitse arkailla henkilökohtaisten tietojensa syöttämisen kanssa. Sama koskee myös esim. luottokorttitietoja ja liitetiedostoja.

Tarkastuslista ennen jokaista testisessiota varten

  • Siisti testihuone
  • Aseta testilaitteet aloitustilaan (esim. sivuhistorian tyhjennys tai sovelluksen aloitusnäkymään siirtyminen). Sulje ylimääräiset ohjelmat (kuten automaattiset päivitykset).
  • Tarkista nauhoituslaitteiden toimivuus. Testaa, että mikrofoni on varmasti päällä.
  • Varaa itsellesi muistiinpanoja varten kynää ja paperia
  • Aseta testikäyttäjän tulosteet helposti saataville ja suoritusjärjestykseen
  • Mikäli testikäyttäjän korvaus on fyysinen esine, varaa se nopeasti saataville
  • Laita testihuoneen oveen lappu ”käyttäjä­testaus käynnissä, älä häiritse”

Lataa tästä käytettävyys­testauksen tarkastuslistan tulostettava versio

käyttäjä­testaus on usein testi­henkilöille melko henkilökohtainen, jopa stressaavakin kokemus. Testaustilanteen tulisi edetä testikäyttäjän ehdoilla ja muutenkin eettisesti toimien. On tärkeää, että testikäyttäjille aina erikseen kerrotaan heidän oikeutensa, ja usein se myös parantaa testikäyttäjän luottamusta itse testaustilanteeseen.

Testikäyttäjän oikeudet pähkinänkuoressa

  • Mahdollisuus lopettaa yksittäinen tehtävä tai koko testaustilanne milloin tahansa, jos siltä tuntuu
  • Oikeus kieltäytyä testaustilanteen nauhoittamisesta
  • Yksityisyyssuoja. Kaikkea testi­materiaalia käsitellään anonyymisti, niin että mitään henkilöön yhdistettävää tietoa ei mainita materiaalin käsittelyssä.

Testitilanteen nauhoittaminen

Testitilanteen nauhoitus on erittäin suositeltavaa, jos vain suinkin mahdollista, sillä se helpottaa huomattavasti purkuvaiheen suoritusta. Tekniikka vaihtelee testattavan ratkaisun mukaan videokamerasta ruudun nauhoitukseen, joskin videokamera toimii parhaiten lähinnä fyysistä toimintaa sisältäviin tilanteisiin. Äänen nauhoittaminen on yhtä lailla tärkeää kuin kuvankin; ääni selventää käyttäjän aikeita korkealla tasolla, kuva hieno­varaisempaa interaktiota.

Työpöytäkäytössä ruudun nauhoitus on toimivin vaihtoehto, sillä hiiren liike mukailee usein käyttäjän aikeita. Kosketusnäyttöä käytettäessä sormen liike on mahdollista nauhoittaa vain ulkoisella kameralla, joskin oman kokemukseni mukaan sellaisen käyttö on varsin kömpelöä. Jos et halua rakennella nauhoitustelinettä, kannattaa panostaa omien muistiin­panojen tekemiseen testisessioiden aikana.

Suosituksia nauhoitussovelluksiksi

  • FlashBack Recorder on Window-käyttöön tehty täyden palvelun nauhoitus- ja toistosovellus, joka sisältää aika lailla kaikki tarpeelliset toiminnot. Perusversio ilmainen, täysversio $99.
  • Lookback on nauhoituspalvelu, joka tarjoaa sovelluksen Android-laitteille ja Mac-tietokoneen kautta nauhoitus­toiminnon iOS-laitteille. Toimii erinomaisesti ryhmäkäytössä. Kokeiluversio ilmainen, täysversio $29/kk.
  • UX Recorder on iOS-laitteiden huonoista sovellusvaihtoehdoista paras. Käytä ainoastaan, jos et omista Lookbackin vaatimaa Mac-tietokonetta. Hinta $2 per nauhoituskerta.

Kaikki luetellut sovellukset nauhoittavat ruudun kuvaa ja ääntä. Mobiilikäytössä etukameran käyttö on usein turhaa (jos et halua tarkkailla testikäyttäjien leukaa), mutta desktop-laitteilla webkameran käyttö katseen suunnan nauhoittamiseksi voi olla hyödyllistä.

Nauhoittamiseen tulee ehdottomasti kysyä testikäyttäjän lupa, ja heillä on oltava mahdollisuus kieltäytyä siitä (varaa aina kynää ja paperia!). Nauhoituslaitteistoon tutustuminen ja anonymiteetin korostaminen voi auttaa tilanteissa, joissa testikäyttäjä jännittää nauhoitusta.

Toiminta testisession aikana

Kun testisession hetki vihdoin koittaa, kannattaa testihenkilön kanssa alkuun hieman jutustella ja kertoa käyttäjä­testauksen tarkoituksesta. Tilanne on usein testi­henkilöiden kannalta uusi ja jännittävä, minkä vuoksi ei kannata hypätä suoraan asiaan.

Tiimin jäsenien tuominen testaustilanteeseen on mainio tapa sitouttaa heitä käytettävyyden parantamiseen, mutta testihenkilöiden kannalta suuren yleisön edessä toimiminen on usein kiusallista. Usean havainnoijan hyödyntäminen tai monimutkaisen nauhoituslaitteiston käyttö aiheuttaa pääsääntöisesti turhaa stressiä testikäyttäjissä, joten pidä asetelma yksinkertaisena, jos vain mahdollista.

Kun olet siirtymässä itse testaustapahtumaan, muista mainita seuraavat asiat

  • käytettävyys­testauksessa arvioidaan käyttöliittymän ymmärrettävyyttä, ei käyttäjän toimintaa. Oikeita tai vääriä vastauksia ei ole.
  • Testauksen kulku yleisesti ja testikäyttäjän toiminnan (ääneen ajattelu) selittäminen
  • Testitilanteen maksimikesto
  • Testikäyttäjän oikeudet (mahdollisuus lopettaa, anonymiteetti, nauhoitus)
  • Kysy lupa nauhoitukseen ja laita se päälle. Kannattaa sanoa myös ääneen ”Nauhoitus on nyt päällä”, eikä kiinnittää siihen huomiota sen jälkeen.

Käyttäjä­testauksen kulusta kannattaa mainita kyseessä olevan ratkaisun laadun parantamis­prosessi, jossa testataan käyttöliittymän soveltuvuutta todellisten käyttäjien tarpeisiin. Testikäyttäjiä kannattaa pyytää toimimaan testitilanteessa niin kuin he normaalistikin toimisivat.

Laske seitsemään ennen kuin avaat suusi testisession aikana

Ääneen ajattelu (think aloud) on hyvä toimintatapa testikäyttäjälle selittää toimintansa aikeita, ja testikäyttäjää kannattaa kannustaa siihen. Metodi on nimelleen varsin uskollinen: siinä käyttäjä yrittää ajatella motiivejaan ja tekojaan ääneen, testaajan kuunnellessa. Ääneen ajattelu on usein alkuun hieman kömpelöä, mutta siihen tottuu todella nopeasti. Testikäyttäjää voi myös muistuttaa kesken testisession ääneen ajattelusta, mikäli hän puuhastelee pitkään hiljaa.

Testaajan sen sijaan tulee suurimmaksi osaksi olla hiljaa. Voit nyökkäillä ja hymähdellä silloin tällöin pitääksesi tilanteen luontevampana, mutta testikäyttäjän toiminnan kommentointi tai ohjaaminen on ehdottomasti kielletty. Testikäyttäjille onkin hyvä sanoa, ettet voi auttaa testauksen suorittamisessa. Riittävän etäinen toimintatapa voi olla yllättävän vaikea omaksua, ja hyvä nyrkkisääntö onkin laskea seitsemään asti ennen kuin avaat suusi testisession aikana.

Täysin tuppisuuna ei tietenkään tarvitse olla. Tarkentavien kysymysten esittäminen on suotavaa, kunhan pidät huolta siitä, ettei testisessio ajaudu keskusteluksi. Kannattaa kiinnittää huomioita varsinkin käyttäjän toistuviin toimintoihin sekä käyttöliittymässä hapuiluun; voit esimerkiksi kysyä, mitä käyttäjä olettaisi toiminnosta tapahtuvan.

Mikäli testikäyttäjä kysyy suoraan jonkin toiminnon tarkoitusta tai apua sen suorittamiseen, voit hyödyntää Echo, Boomerang, Columbo -metodia, jonka perusajatus on rohkaista käyttäjää pohtimaan itse omaa kysymystään, ja näin ohjata tämä pukemaan oma mentaalimallinsa sanoiksi.

Jos testikäyttäjä näyttää olevan selkeästi hukassa, voit avata keskustelua siitä, kuinka hän olettaa käyttöliittymän toimivan; testikäyttäjien on toisinaan vaikea kuvata oma-aloitteisesti ajatuksiaan silloin kun he keskittyvät täysvaltaisesti ongelman­ratkaisuun. Mikäli testikäyttäjä tyystin turhautuu eikä oma-aloitteisesti ota esille tehtävän lopettamista, voit tietyn harkinta-ajan jälkeen kysy, haluaisiko testikäyttäjä lopettaa tehtävän ja siirtyä seuraavan.

Jos testikäyttäjä tekee aivan suoranaisen virheen, älä korjaa sitä. Jos käyttäjä alkaa pian epäilemään valintojaan, voit kysyä miten hän olettaisi käyttöliittymän toimivan. Muista, että virheen esiintyminen jo sinänsä on arvokas testihavainto, ja osoitus siitä, ettei käyttöliittymä ole tarpeeksi selkeä.

Itse testisession käytännön ohjaamisen ja tarkentavien kysymysten lomassa on hyvä tehdä lyhyitä muistiinpanoja (kynällä ja paperilla), jotta voit myöhemmin kiinnittää niihin erityishuomiota tai tarkastaa tietyn yksityiskohdan nauhoituksesta. Muistiin­panojen rauhallinen tekeminen on myös luonteva syy olla hetki hiljaa, ja näin ohjata testikäyttäjää olemaan enemmän äänessä.

Testisession lopuksi

Testin loputtua – oli kyse sitten kaikkien tehtävien suorittamisesta tai ajan loppumisesta – kannattaa vielä kysyä yleisesti testikäyttäjän ajatuksia testisessiosta. Usein suoran palautteen kysyminen itse käyttöliittymästä ei ole kovinkaan hedelmällistä, eli korkeamman tason ”fiiliksien” keskustelu voi johtaa hyödyllisempään keskusteluun. Toisinaan testikäyttäjät rentoutuvat silmin nähden tehtävien päätyttyä, jolloin keskustelu on muutenkin tuloksellisempaa.

Olen itse kokenut hyödylliseksi lopettaa nauhoituksen vielä testikäyttäjän läsnä ollessa, yleensä ilmaisten konkreettisesti ”nauhoitus on nyt lopetettu”. Tämä antaa testikäyttäjälle vielä mahdollisuuden perua nauhoituslupansa, mutta ennen kaikkea nauhoituksen loppuminen avaa herkullisen tilanteen pöytäkirjan ulkopuolisille kommenteille, joita testikäyttäjä ei ehkä nauhalle uskaltaisi sanoa.

Muista lopuksi myös mahdollinen kiitoslahja käyttäjä­testiin osallistumisesta sekä jättää testikäyttäjälle yhteystietosi mahdollisten myöhempien kysymysten esittämistä varten.

Testikäyttäjän poistuttua täydennä vielä muutaman minuutin ajan muistiinpanojasi. Kirjoita ylös yleisiä havaintojasi sekä tilaisuuden tunnelmaan liittyviä huomioita, jotka eivät enää välity selkeästi nauhoituksesta. Mikäli tilannetta ei ollut mahdollista nauhoittaa, kannattaa materiaali purkaa välittömästi, kun muistikuvat ovat vielä tuoreita.

5. Testimateriaalin purku

Testimateriaalin purkamisen vaiheessa on tarkoituksena tuottaa suuri määrä raaka­materiaalia analyysivaihetta varten. Puretun materiaalin on tarkoitus olla niin tarkalla tasolla, että periaatteessa kuka tahansa pystyisi tekemään analyysin sen pohjalta. Purkuvaiheessa ei vielä ideoida, eli pyri tietoisesti välttämään säästämään ratkaisuehdotukset analyysivaiheeseen.

Testimateriaalin purku on samanaikaisesti tuskaista pakertamista ja löytämisen riemua. Puolen tunnin testisession purkuun menee tyypillisesti aikaa pari-kolme tuntia, ja tyypillisesti ensimmäisten testihenkilöiden kohdalla aikaa vaaditaan enemmän. On suositeltavaa, että kunkin testisession purkaa paikalla havainnoimassa ollut henkilö, ja että purku suoritetaan mahdollisimman pian itse testin jälkeen.

Aineiston tuottaminen

Purkamiseen on useita tapoja, mutta hyvä peruskeino on käydä materiaali jokainen nauhoitus yksittäin läpi ja kirjoittaa muistiinpanoihin ranskalaisilla viivoilla jok’ikinen tapahtuma tai huomio. Aivan kaikkea ei kannata kirjoittaa muistiin – tarkoitushan on löytää niitä käytettävyys­ongelmia. Etsi siis tilanteita, joissa käyttäjä epäröi, mietiskelee, tekee aivan suoranaisia virheitä tai ilmaisee sanoin tilanteen ongelmallisuuden.

Ongelmien tunnistaminen voi olla vaikeaa muille kuin käytettävyysalan ammattilaiselle, minkä vuoksi purkuvaiheessa ei kannata säästellä resursseissa. Tyypillisesti purkuvaihe vaatii nauhoituksen pysäyttämistä ja kelaamista useaan otteeseen, jolloin kahden näytön (tai tietokoneen) käyttö helpottaa työtä. Yksittäisestä sessiosta materiaalia syntyy tyypillisesti sivutolkulla, mistä syystä muistiinpanot onkin hyvä jaotella tehtävittäin.

Tällaisen ”puolilitteroinnin” hyvä puoli on neutraali lähestyminen, jonka kautta alun alkaen merkityksettömiksi luullut asiat on mahdollista huomioida myöhemmin. On hyvin tyypillistä, että jokin yksittäinen pieni asia esiintyy usealla eri testikäyttäjällä, ja se tulisi helposti sivutettua ilman kirjallista huomiota.

Suorat lainaukset auttavat lukijaa asettumaan käyttäjän asemaan

Huono puoli tässä tavassa on sen vaatima reilu ajantarve sekä aivan suoraan sanoen tylsyys. Mikäli olet kokenut käytettävyys­testauksen suorittaja, on nopeampi tapa vain katsoa nauhoitus ensin kertaalleen läpi ajatuksella, ja sitten katsoa se uudestaan läpi kirjaten muistiin vain oleellisimmat asiat.

Jokainen testisessio tulisi pyrkiä käsittelemään yksilöllisesti, pyrkien sulkemaan mielestään aiemmin puretut sessiot. On hyvin helppoa erehtyä muistelemaan jonkin havainnon tapahtuneen jossain toisessakin testisessiossa ja tehdä siten puutteellinen tai vääristynyt kirjaus.

Muistiinpanoihin kannattaa kirjoittaa toisinaan ylös käyttäjien puhetta suorina lainauksina. Nämä ovat asiasisältönsä lisäksi erinomaista materiaalia mahdollista loppuraporttia varten, sillä ne auttavat lukijaa asettumaan käyttäjän asemaan.

Aineiston ryhmittely

Kun olet saanut session purettua nopeiksi muistiinpanoiksi, kannattaa se vielä jäsennellä selkeämmäksi esimerkiksi sisennyksien tai väliotsikointien avulla. Olen itse kokenut hyödylliseksi käyttää tekstinkäsittelyohjelman korostusväriä tärkeiden ja erittäin tärkeiden havaintojen sekä omien huomioiden korostamiseen. Näin analyysivaiheessa materiaalia on helpompi selailla.

Purkuvaiheen Excel-esimerkki Purkuvaiheessa vasta listataan havaintoja

Mikäli teet tuloksista loppuraportin (eli tiimissäsi on yli kolme henkeä), suosittelen Excel-taulukon käyttämistä tarkempaan ryhmittelyyn. Kirjaa Exceliin kunkin havainnon kuvaus, kriittisyys sekä havaintojen lukumäärä. Samojen havaintojen ilmettyä uudelleen voit vain kasvattaa jo olemassa olevan rivin lukumäärää.

Lataa tästä purkuvaiheen Excel-esimerkki

Excel-tiedoston suurin hyöty on sen jatkokäyttömahdollisuuksissa; täysin samaa tiedostoa kun voidaan käyttää esimerkiksi teknisen toteutettavuuden arvioimiseksi. Excelin mahdollistama järjestäminen myös säästää paljon käsityötä priorisointivaiheessa.

Prioriteettitasot käytettävyysongelmille

  • Matala: kosmeettinen tai pientä harmia tuottava käytettävyysongelma. Korjataan aikataulun salliessa, mikäli korjaus­kustannus on pieni.
  • Keskitaso: toimintaa hidastava tai kevyesti hankaloittava käytettävyys­ongelma. Korjataan, mutta alhaisella prioriteetilla.
  • Korkea: virheitä aiheuttava tai pahasti käyttöä haittaava käytettävyysongelma. Korjataan niin pian kuin mahdollista.
  • Kriittinen: yksiselitteinen käytettävyyspainajainen, joka tekee toiminnon suorittamisesta mahdotonta. Korjataan ennen kuin ratkaisua voidaan harkita julkaistavaksi.

Mikäli testattava ratkaisu on karkean tason prototyyppi tai palvelu, voi Post-it -lapuilla tehtävä ryhmittely olla toimivampi. Kirjoita tällöin jokainen havainto Post-it -lapulle, ja kun kaikki laput on kirjoitettu, ryhmittele ne järkeviin kokonaisuuksiin. Näin syntyvää ryhmittelyä voidaan käyttää aineistona analyysivaiheessa, ja bonuksena jo ryhmien fyysinen koko ohjaa korjaustoimien kohdentamisessa.

6. Analyysi ja raportointi

Analyysivaiheen tarkoituksena on pohtia, mistä purkuvaiheessa tehdyt havainnot johtuvat ja kuinka ne voisi korjata. Havaintojen laajuus vaihtelee, ja siinä missä hyvin yksiselitteisissä käyttäjä­testauksissa erillistä analyysivaihetta ei ehkä tarvita, voi monimutkaisen havainnon paikkaaminen vaatia kattavaa lisätutkimusta ja -suunnittelua. On hyvin eri asia selvittää, miksi pientä tekstiä ei näe lukea, kuin pohtia miksi palvelukuvausta ei koeta luotettavaksi.

Analyysin laajuus riippuu myös organisaation laajuudesta. Jos teette pienellä porukalla mobiilisovellusta, on sivullinen ranskalaisia viivoja riittävä. Jos taas testaat suuren luokan varausjärjestelmää, tarvitset todennäköisesti Excel-taulukon kustannusarvioita varten ja erillisen esitelmän tarkempia ideointi-workshoppeja ajatellen.

Analyysivaiheen Excel-esimerkki Analyysivaiheessa havainnot saavat merkityksen

Analyysivaihe voit hyödyntää purkuvaiheessa tekemääsi Excel-tiedostoa. Merkitse kullekin riville lyhyt tulkinta havainnosta sekä mahdollinen alustava ehdotus sen korjaamiseksi. Analyysin tekijän on syytä olla käytettävyysalan ammattilainen, sillä havaintojen syyt ovat usein erittäin monitulkintaisia. Usein yksittäinen havainto vaatiikin lisätutkimusta tai koeponnistusta esimerkiksi A/B-testauksen muodossa.

Lataa tästä analyysivaiheen Excel-esimerkki

Excel-tiedostoa kannattaa käydä läpi sekä liiketoiminnan että tekniikan näkökulmasta korjaustoimenpiteiden priorisoinniksi. Tässä kannattaa luonnollisesti hyödyntää tiimin muita osapuolia.

Mikäli esittelet havainnot, esimerkiksi ohjausryhmälle tai asiakkaalle, kannattaa Excelin oleellisimmat osat vielä esitysmuotoon; Excelin tiiraaminen videotykiltä on masokistin hommia.

Analyysivaiheen lopussa sinulla pitäisi olla selkeä lista siitä, mikä on mennyt vikaan, sekä liuta jatkotoimista ongelmien korjaamiseksi. On hyvin tyypillistä varmistaa korjausten sopivuus uudella käyttäjä­testauksella, eli pidä kaikki materiaalisi jemmassa myöhempiä tarkastuksia varten.

« Back to post listing