Käytettävyystestaus (tai käyttäjätestaus) on tapahtuma, jossa testikäyttäjät suorittavat ennalta määrättyjä tehtäviä käytettävyysasiantuntijan havainnoidessa, tarkoituksena havaita mahdollisia käytettävyysongelmia. Testattava ratkaisu voi olla prototyyppiasteella oleva suunnitelma tai jo valmis ratkaisu, jonka käytettävyyttä halutaan parantaa.
Käytettävyystestejä voi suorittaa niin livenä kuin verkonkin yli, sekä valvotusti tai ilman asiantuntijan valvontaa. Tämä kirjoitus keskittyy valvotusti paikan päällä suoritettavan käytettävyystestin järjestämiseen.
Lataa mallipohjat eri vaiheisiin
Käytettävyystestauksen tehtävien esimerkki
Käytettävyystestauksen rekrytointikutsun malli
Käytettävyystestauksen 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ävyystestauksiin. 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ö).
- Testattavien kokonaisuuksien rajaus
- Testin suunnittelu
- Testikäyttäjien rekrytointi
- Testin suorittaminen
- Testimateriaalin purku
- Analyysi ja raportointi
Käytännön minimitaso käyttäjätestaukselle ovat kohdat 2 ja 4. Mikäli kyseessä on autotallifirmaa 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ävyystestauksen 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ävyystestauksen 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ävyystestausta 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ävyystestauksessa 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ävyystestauksen 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ävyystestauksen 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 demokä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ävyystestauksen tarkastuslistan tulostettava versio
käyttäjätestaus on usein testihenkilö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 testimateriaalia 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 hienovaraisempaa 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 muistiinpanojen 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 nauhoitustoiminnon 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 testihenkilö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ävyystestauksessa 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 parantamisprosessi, 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 ongelmanratkaisuun. 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. Muistiinpanojen 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ä raakamateriaalia 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ävyysongelmia. 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ävyystestauksen 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.
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 korjauskustannus on pieni.
- Keskitaso: toimintaa hidastava tai kevyesti hankaloittava käytettävyysongelma. 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.
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.