Avainsana-arkisto: käyttäjät

Graduilua TKrekryn uudistusprojektin lomassa

Johannes Pitkänen

Tässä jutussa kerron taustoja TKrekryn jatkokehitysprojektin käyttäjätutkimuksesta. Pohdin myös tutkimuksen tuloksia ja tietysti sitä, mitä olisi voinut tehdä paremmin. Kerron myös, miten gradun teko onnistui käytännönläheisen projektin kyljessä.

Täytyy heti kärkeen sanoa, että olen todella saamaton blogikirjoittaja. Aiempi blogini pienyrityksen nettisivuista on toistaiseksi jäänyt neljään artikkeliin, ja tämän TKrekry-blogin aloitusteksti on ollut muutaman rivin luonnosasteella rapsakat puoli vuotta. Tarjoan tekosyyksi hieman suurempaa tekeillä ollutta kirjoitusprojektia, joka on verottanut niin aikaa, energiaa kuin mielenterveyttänikin raskaalla kädellä. Puhun siis gradusta. Voin sanoa, että kepeämmän tekstin kirjoittaminen tuollaisen mammutin jälkeen on hyvin vapauttavaa.

Minut rekrytoitiin Tampereen yliopiston syventävältä kurssilta mukaan TKrekryn jatkokehitysprojektiin tekemään käyttäjätutkimusta. Porkkanana oli klassinen “materiaalia opinnäytetyötä varten ja lämmin mieli” -lähestymistapa, joka ei toimi TTY:llä: epätoivon haju on selvästikin vahvempi yliopiston puolella. Hakijoitakin oli useampi. No, vitsit vitsinä. Omalla kohdallani ajattelin, että gradu on kuitenkin saatava valmiiksi joten samalla voisin yrittää tehdä jotain sellaista, joka hyödyttää muitakin. Nyt kun gradu on tullut painosta ja arvioitu kiitettäväksi, kokemusta on kertynyt ja kontakteja löytynyt, täytyykin jo todeta, että olihan tuo loppujen lopuksi oikein hyvä diili.

TKrekryn jatkokehitysprojekti on tärkeä osa graduani ja toimii graduni tapausesimerkkinä. Käsittelen siinä melko harvinaista käyttäjäkeskeisen suunnittelun menetelmää, arvosensitiivistä suunnittelua (Value-Sensitive Design, VSD). Tiivistettynä kyseessä on suunnittelusuuntaus, jossa teknisten järjestelmien käyttäjien ja muiden sidosryhmien arvomaailmat otetaan huomioon suunnittelussa. Esimerkiksi lääkärit voivat arvostaa mielekästä työtä ja työn joustavuutta, eli lääkäreihin vetoavalla nettisivulla kannattaisi varmaankin olla tietoa työn luonteesta, työsuhde-eduista ja sen sellaisesta. Skeptisempi lukija saattaisi osin oikeutetustikin todeta, että niinhän homma toimii muutenkin – otetaan selvää mistä käyttäjät tykkäävät ja tungetaan sellaisia juttuja kehitettävään järjestelmään – mutta VSD:n ehkäpä olennaisimpana juttuna on eräänlainen pysyvä näkökulman vaihto, joka pakottaa ajattelemaan hiukan perinteisestä kehitystyöstä poiketen.

VSD on siitä kiva suunnittelumenetelmä, että sen voi ottaa käyttöön muiden suunnittelutapojen oheen. VSD:n tuoma lisäarvo liittyy muun muassa käyttäjien motivaatioiden ja teknologioiden hyväksynnän (acceptance) ymmärtämiseen ja edistämiseen. VSD:n menetelmät ovat monenkirjavia: haastattelut, toimintatutkimukset, käyttäjien tarkkailu, kyselytutkimukset ja A/B-testit ovat esimerkkejä sellaisista menetelmistä, joita VSD:n harjoittaja voi tutkimuksissaan käyttää. Gradussani on suomennettuna, selvennettynä ja esimerkein höystettynä tämänhetkisen kirjallisuuden kattavimmat ohjeet VSD:n hyödyntämiseen suunnittelutyössä.

VSD:hen liittyvät julkaisut ovat pitkälti keskittyneet tänne : http://www.vsdesign.org/.

Linkitän graduni tänne, kunhan se ilmaantuu TamPubiin (http://tampub.uta.fi/).

 

Käyttäjätutkimuksen toteutuksesta ja tuloksista

Pirkka on aiemmissa blogipostauksissa ruotinut kiitettävän tarkkaan sekä TKrekryn jatkokehitysprojektin että käyttäjätutkimuksen tavoitteet. Blogisarjan toisesta tekstistä löytyy myös Pirkan kirjoittama tiivistelmä käyttäjätutkimuksen toteutuksesta. Copypastaan sen häpeilemättä tähän:

  • Tutkimukseen osallistui 7 terveyskeskuksessa työskentelevää nuorta lääkäriä ja 3 terveyskeskusten rekrytoinnista vastaavaa henkilöä kolmelta eri paikkakunnalla.
  • Yksi testisessio sisälsi taustatieto- ja kyselylomakkeiden täyttämisen, TKrekryn ja jonkun muun rekrysivuston käyttöä vertailevan käytettävyystestin ja haastattelun.
  • Tutkimukseen osallistuneille lääkäreille tärkein tapa hakea töitä on suora yhteydenotto työnantajaan. Samaan tulokseen oli päädytty aikaisemmissa kyselytutkimuksissa.
  • Palvelun tunnettuus ja kattavuus eli se, että kaikki työnantajat ovat edustettuina (ajantasaisesti) sivustolla, oli tärkeää lääkäreille.
  • Yhteystietojen ja työpaikkailmoitusten ohella jatkokoulutuksesta kertovat sisällöt kiinnostivat lääkäreitä.
  • Terveyskeskuskäyttäjille ilmoituksen jättämisen nopeus ja vaivattomuus oli tärkeää ja mielellään vielä siten, että kunnan oma rekryjärjestelmä työntäisi ilmoitukset muihin palveluihin (Mol.fi, Kuntarekry.fi, Terveysportti.fi, TKkrekry.fi jne.).
  • Sivuston toimivuutta mobiililaitteilla ei pidetty oleellisena.

Tein käyttäjätutkimuksen kesällä 2013. Tiivistelmässä mainitut paikkakunnat olivat Kangasala, Oulu ja Helsinki. Kauas matkaavalle käyttäjätutkijalle haluaisin antaa pikku vinkin: varaa riittävästi aikaa. Oulun matkalla VR:n parin tunnin myöhästyminen oli onneksi vasta paluureissulla, mutta menomatkalla se olisi torpedoinut käytännössä koko keikan. Vieraassa ympäristössä kannattaa myös varata riittävästi aikaa navigointiin paikasta toiseen. Helsingin reissulla menin kyllä oikeaan osoitteeseen, mutta siellä joutui sitten arpomaan muutaman ison rakennuksen väliltä, että minneköhän sitä pitäisi mennä. Valitsin summamutikassa yhden ja kysyin neuvonnasta, että olenko oikeassa paikassa. Enpä ollut, mutta kiiruhdin oikeaan rakennukseen ja kerkisin kuitenkin haastatteluun joitakin minuutteja etuajassa (vaikkakin hikisenä.)

Itse testit ja haastattelut menivät kokonaisuutena aika sujuvasti. Suurin osa osallistujista oli kiitettävän puheliaita ja laitteisto (läppäri, bluetooth-hiiri ja kännykän wifi-hotspot) toimi. Yksi haastattelu Oulussa oli meluisassa ympäristössä, ja äänitallenteen laatu jäi huonoksi. Kannattaakin mahdollisuuksien mukaan sopia etukäteen rauhallisesta työympäristöstä: häiriöt oikeasti häiritsevät sekä keskittymistä että tallentamista. Etenkin kokematon moderaattori saattaa hermostua tai turhautua häiriöistä, ja tämä sitten heijastuu osallistujaan, vaikka osallistuja olisikin tottunut työympäristöönsä.

Testien ja haastatteluiden pituudet menivät kohdalleen, mutta tässä oli vähän tuuria mukana. Pilottiosallistuja nimittäin oli erinomainen, ja siitä kuuluu kiitos PSHP:lle. Jos tästä pitäisi jotain vinkkiä vääntää, ei siltikään kannata luottaa siihen että pilottitestin pituus vastaa todellisuutta.

Sairaanhoitopiirillä oli iso rooli käyttäjätutkimuksen osallistujien järjestämisessä ja siitä heille taas suuri kiitos ja kunnia. Kaltaiseni poloisen opiskelijan olisi ilman taustavoimia hyvin vaikeaa rekrytoida lääkäreitä osallistumaan käytettävyystesteihin: Tiedän tämän, koska rekrytoin itsekseni lääkäriopiskelijoita keväällä 2014 gradun toista tutkimusvaihetta varten, ja nihkeää oli. Kaikki tällaiset asiat kannattaa pitää mielessä jos “ilmaistyön” tekeminen tuntuu nuivalta: organisaatioiden kanssa työskentelyssä voi olla yllättäviäkin etuja.

Yksi sudenkuoppa tulosten tulkitsemisessa liittyy mobiililaitteisiin. Osallistujat eivät pitäneet niitä tärkeinä ja tein tästä johtopäätöksen raporttiini, mutta kuten Pirkka aiemmin kertoi, kävijäseurantadatan perusteella noin 15% sivuston kävijöistä käytti mobiililaitetta. Syyskuun 2014 mobiilikäyttäjien lukema on jo 24%. Eli: otos saattoi olla liian pieni tai osallistujat vain yksinkertaisesti vetivät liiaksi mutulla. First Rule of Usability? Don’t Listen to Users

Osallistujien tausta pitää luonnollisesti myös ottaa huomioon. Tässä tapauksessa osallistujat olivat julkisen puolen terveyskeskuslääkäreitä, eli tuloksia ei välttämättä suoraan voi yleistää yksityisen puolen toimijoihin. On esimerkiksi mahdollista, että tiedot palkkauksesta olisivat yksityisellä puolella tärkeämmässä asemassa. Yksi osallistujista tosin oli terveyskeskuksessaan töissä vuokralääkärifirman kautta.

Muutenkin otos oli sen verran pieni, että yleistyksiä ei pidä liian hanakasti lähteä tekemään. Onneksi kuitenkin taustamateriaalina oli aikaisempi kyselytutkimus, jonka tuloksia testit ja haastattelut täsmensivät kvalitatiivisesti. Sain tästä idean käyttää samantapaista lähestymistapaa gradussani: minulla oli siinä useammalle osallistujalle tarkoitettu internet-kyselylomake kvantitatiivista dataa varten, ja tätä dataa syväluotasin sitten haastatteluilla.

Tämän käyttäjätutkimuksen poikimat vinkit

  • Varaa siirtymiin riittävästi aikaa. Jos liikut esim. junalla, kannattaa etukäteen miettiä onko myöhästely todennäköistä.
  • Laitteiston toimivuuden lisäksi mieti muitakin tekijöitä, jotka voivat vaikuttaa testeihin tai haastatteluihin (esim. melu tai muut häiriöt).
  • Pilotin perusteella tehty aika-arvio voi aina heittää. Jos pilotti tuntuu erityisen “sujuvalta”, kannattaa ehkä suosiolla varata lisäaikaa.
  • Tarkista käyttäjien tekemät väittämät tarkkailemalla heidän toimintaansa.
  • Älä yleistä liian herkästi. Pätee melkeinpä kaikkeen tutkimustyöhön. 🙂

Lopuksi

TKrekry on julkaistu. Projektin voinee lukea onnistuneiden joukkoon. Gradu on valmis ja vissiin ihan hyväkin. Gradun aikataulu kyllä venyi arvioidusta, mutta ei TKrekry-projektin takia. Kokonaisuutena jäi kuitenkin hyvä fiilis, ja opinnäytetyön sitominen ihka oikeaan projektiin antaa sille aivan eri tavalla mielekkyyttä kuin pakkotortun vääntäminen jostain hihasta vedetystä aiheesta. Suuret kiitokset ohjaajalleni Saila Ovaskalle ja tietysti TKrekry-projektiryhmälle.

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):

Moderoimaton etäkäytettävyystestaus Suomessa

Allekirjoittaneen olisi tarkoitus testata TKrekryn uutta ylläpitotyökalua kolmella terveyskeskuskäyttäjällä pahimpien käytettävyysmokien löytämiseksi ja korjaamiseksi ennen sivuston julkaisua (tästä mahdollisesti lisää myöhemmin). Testeihin valmistautumisen johdosta ja siitä syystä, että Nielsenin Jakob kirjoitti minulle viikko sitten maanantaina sähköpostia (suosittelen vaikka et käytettävyysammattilainen olisikaan), kirjoitan muutaman säkeen etänä järjestettävästä moderoimattomasta käytettävyystestauksesta Suomessa.

”Unmoderated Remote Usability Testing” tarkoittaa lyhyesti käytettävyystestin järjestämistä siten, että testihenkilöt suorittavat omalla päätelaitteellaan netin välityksellä käytettävyystestin testitehtäviä ilman, että käytettävyysasiantuntija ohjaa testisession etenemistä. Kukaan ei myöskään tarkkaile tehtävien suorittamista reaaliajassa vaan testistä saa jälkeenpäin jonkinlaisen koosteen, joka saattaa sisältää ruudunkaappaus/video/audio -nauhoituksen, sanallisia kommentteja jne. Variaatioita tämän kehyksen sisältä sitten varmasti löytyy useita.

Nielsenin uutiskirjeen toinen artikkelilinkki ohjasi juttuun missä käsiteltiin sopivan online-työkalun valintaa näiden testien järjestämiseksi. Tarkoitukseni ei ole tässä toistaa jutun asioita, vaan jokaisen kannattaa lukea se itse. Itselläni ei ole näistä työkaluista kokemusta, mutta ideatasolla ne vaikuttavat lupaavalta. Esim. kuluttajien rekrytointi testihenkilöiksi voi olla haastavaa tai ainakin työläämpää, kuin organisaation sisäisten käyttäjien. Hyvän työkalun potentiaali piileekin juuri siinä, että sen avulla saataisiin rekrytoitua haluttua kohderyhmää edustavat testihenkilöt hyvin pienellä vaivalla. Mutta kun ollaan Suomessa ja tehdään verkkopalveluita suomalaisille, niin tämä potentiaali jää varmasti hyödyntämättä, koska en jaksa uskoa että näiden palveluiden testihenkilökäyttäjinä olisi kovinkaan montaa suomalaista. Toisaalta näiden palveluiden kautta voi olla haastavaa rekrytoida henkilöitä, jotka eivät käytä nettiä (!) tai käyttävät sitä vähän. Testihenkilöiden edustavuuden kanssa saa siis olla tarkkana kuten aina.

Asiaa ennenkin pohtineena, päätin nopeasti vilkaista Nielsenin listaamat kuusi työkalua ja selvittää toimivatko ne muuten kuin amerikaksi. Alla olevassa taulukossa on listattu kukin työkalu, mitä aiheesta löytyi palvelun FAQ:sta ja mitä he vastasivat lähettämääni sähköpostitiedusteluun aikeista laajentaa toimintaa Suomeen.

# Työkalu FAQ kansainvälisyydestä Vastaus sähköpostiin
1 http://www.trymyui.com/ Potentiaalisia testihenkilöitä on mahdollista suodattaa maan ja asuinpaikan mukaan ja ilmeisesti itse rekrytoidut testihenkilöt on mahdollista tuoda palveluun. ”… no. There just isn’t enough demand to internationalize and recruit Finnish testers. ”
2 http://openhallway.com/ Potentiaalisia testihenkilöitä ei ole mahdollista rekrytoida työkalun kautta, vaan ne on hankittava itse ja tuotava palveluun.
3 http://www.userlytics.com/sitepublic/ Potentiaalisia testihenkilöitä voi rekrytoida palvelun kautta Yhdysvalloista, Kanadasta ja UK:sta, käyttää 3. osapuolta rekrytointiin tai tuoda itse omat testihenkilöt. ”We do not have any specific plans for Finland, but have done many studies around the world including both Norway and Denmark; if you let us know the scope of the project you are interested in we can let you know if it is something we could do and what the cost might be. ”
4 http://www.usertesting.com/ Potentiaalisia testihenkilöitä voi rekrytoida palvelun kautta Yhdysvalloista, Kanadasta ja UK:sta tai tuoda itse omat testihenkilöt. ”While we don’t have specific statistics, it’s very likely that we have some Finnish users on our panel. You can specify Finnish users by including it as a requirement in your test’s “Other Requirements” field. For example, you could write, “Only take this test if you are in Finland.” Users will see this requirement when they view your test and will then self-select based on the criteria. If for some reason a user incorrectly self-selects, let us know and we’ll gladly cancel the test and either provide a free replacement test or refund a test credit. Additionally, if our user panel does not have enough Finnish users to support your testing needs and some of your tests are not completed, let us know and we’ll cancel and refund any unfilled tests… let us know if we can help in any way, we do most of our work on a custom recruitment basis, worldwide.”
5 http://www.userzoom.com/ Potentiaalisia testihenkilöitä voi rekrytoida 3. osapuolten välityksellä, työkalun avulla omalta verkkosivustolta, tuoda itse omat testihenkilöt jne. Itse työkalu on lokalisoitu englanniksi, espanjaksi, ranskaksi, saksaksi, hollanniksi, japaniksi, ruotsiksi, italiaksi, venäjäksi, puolaksi, kiinaksi, kreikaksi ja koreaksi. ”We can test anywhere in the world. In fact we have just completed studies in Finland with one customer and have another launching next week. On one study the customer did the recruiting by themselves and on the other we did via an independent panel company.”

 

6 http://whatusersdo.com/ Potentiaalisia testihenkilöitä voi rekrytoida palvelun kautta Yhdysvalloista, UK:sta, Australiasta, Ranskasta, Saksasta, Irlannista, Italiasta, Alankomaista ja Espanjasta. ”At the moment we do provide international testing across Europe, however not in finnish at this stage. All current tests can be performed in English and for some countries we also provide local language panels.

If the requirement you have is significant in size and duration we can work with you to set up a Finnish panel and local language support, I will gladly discuss this with you.”

Näiden lisäksi Daniel Koskisen mukaan (2009) http://www.loop11.com/ olisi käännetty suomeksi ja ilmeisesti palveluun voi tuoda omat testihenkilöt tai rekrytoida ne kolmannen osapuolen kautta.

Uskon, että kaikki mainitut työkalut ovat käyttökelpoisia ja käytettävissä Suomessa (mutta ei välttämättä suomeksi), mutta ainakaan tämä alustava silmäys ei lupaa hyvää suomalaisten testihenkilöiden rekrytoimiselle palvelun kautta. Tosin mainittuja kolmansia osapuolia, eli yrityksiä joille varsinainen rekrytointi on ulkoistettu, kannattaisi tutkia lisää.

Olisiko tässä suomalaisille yrityksille, jotka toimeksiantoina metsästävät markkinointitutkimuksiin osallistujia, bisnestä ja tilaisuus verkostoitua näiden palveluntarjoajien kanssa? Ehkä joku muu tietää ja ehkä näin on jo tapahtunut?

Googlettamalla löytyi yksi suomalainen palvelu / yhteisö, jonka jäseniä ilmeisesti hyödynnetään Suuntaamo-nimisen yrityksen tekemissä käyttäjätutkimuksissa ja käytettävyystesteissä ks. http://www.suuntaajat.fi/fi/faq.

Toinen kysymys mikä tulee mieleen on se, että miksi palveluita on noinkin suuri määrä? En tutustunut hinnoitteluun tai ominaisuuksiin mistä vastaus saattaa löytyä, mutta luulisi että vähemmälläkin kilpailulla pärjäisi. Smashing Magazinen jutussa vuodelta 2011 on listattu melkoinen liuta työkaluja, joiden joukosta Nielsenin mainostamasta kuudesta löytyy neljä. Täältä löytyy edelleen työkaluja ja vertailutaulukkoa: http://remoteresear.ch/tools/.

Itseäni kiinnostaisi kuulla muilta alan ammattilaisilta mahdollisia kokemuksia listatuista työkaluista tai muuten vaan mielipiteitä aiheesta. Kommentit osiossa on tilaa 😉

Sivuhuomiona on mielenkiintoista todeta, että näiden palveluiden FAQ:t ohjaavat käyttäjää Nielsenin ja kumppanien aikanaan suosittelemaan viiteen testihenkilöön per testi (seuraavaksi pitäisi tarkistaa laskuttavatko palvelut asiakasta osallistujien mukaan), mutta valistunut käytettävyystestaaja luonnollisesti päättää itse mikä on sopiva määrä ks. http://www.measuringusability.com/blog/five-for-five.php ja http://www.measuringusability.com/five-users.php.

Beta-julkaisu

Uuden sivuston beta-versio julkaistiin palvelun terveyskeskuskäyttäjien kommentoitavaksi eilen tiistaina 04.06.2014. *Maljojen kilistelyä…*

Kommentointipyyntö lähti sähköpostilla noin 135:lle terveyskeskuskäyttäjälle ja muutamalle työnhakijoita edustavalle henkilölle. Kommentteja voi jättää sähköpostilla tai anonyymisti palautelomakkeelle. Katsotaan mitä käy ja ehkäpä joku tämän blogin tai sosiaalisen median kautta eksyy myös beta-sivustolle.

Täytyy myöntää, että ihan suunnitellussa valmiudessa sivusto ei vielä ole (esim. IE8-yhteensopivuuden suhteen ylläpitopuolella) ja tämä saattaa vaikuttaa negatiivisesti kommenttien määrään (organisaatioiden siirtyminen uudempiin IE-versioihin on järkyttävän hidasta, mutta siitä lisää myöhemmin) ja toisaalta laatuun. Kommentoinnin tavoitteena ei ole löytää bugeja (se on meidän kehittäjien homma), vaan mahdollisia parannus- tai muutosehdotuksia sivuston sisältöön tai toiminnallisuuteen.

Joka tapauksessa olen helpottunut, että beta-julkaisu saatiin alta pois vaikkakin vähän keskeneräisenä. Allekirjoittanutkin joutui vielä edeltävänä iltana opettelemaan miten Githubista työnnetään julkaisu Herokuun komentoriviä käyttäen :-). Nyt voi jännittää muita asioita ja toivoa rakentavaa palautetta tulevasta sivustosta (julkaisu tuotantoon on suunniteltu elo-syyskuulle).

Käy tsekkaamassa sivusto osoitteessa http://beta.tkrekry.fi/

PS. Aivan luokattoman kauan kesti, että maltoin taas kirjoituspöydän ääreen (yli 2 kuukautta). Joskus sitä pitäisi vaan pakottaa itsensä kirjoittamaan, koska inspiraatiota voi välillä joutua odottamaan.