Kaikki kirjoittajan Pirkka Rannikko artikkelit

Tietoja Pirkka Rannikko

Ketterää UX- ja Web-suunnittelua ks. http://www.pirkkarannikko.com/

TKrekryn kehityksestä ja tekniikasta

Julkaisimme TKrekryn lähdekoodit viime viikolla avoimena GitHubiin ja tämän kepin johdosta bloggaaja on ajettu taas sorvin ääreen. Valotan seuraavassa Tkrekryn toimintaa tekniseltä näkökantilta ja jaan joitakin havaintoja mitä matkalla tehtiin.

Teknologiavalintoja ja arkkitehtuuria

Ennen kuin päätös TKrekryn uudistamisesta oli tehty, olimme Jaakon kanssa puntaroineet jo useaan kertaan sitä miten mahdollinen tuleva sivusto kannattaisi tehdä. Edellinen sivusto oli toteutettu Ruby on Rails pohjaisen Radiant CMS:n päälle, jonka kehitys näytti jossain vaiheessa kuolevan kasaan ja mm. tästä syystä sivuston teknologiapinon päivittäminen oli joka kerralla entistä haastavampaa. Vuosien saatossa asiakas ei ollut juurikaan käyttänyt julkaisujärjestelmää, vaan sisällön päivittäminen sivustolle oli ollut käytännössä HTML:ää puhuvan allekirjoittaneen heiniä. Koska ylläpitomalliin ei ollut näköpiirissä muutoksia, olimme epäluuloisia sen suhteen kannattaisiko uutta sivustoa rakentaa lainkaan valmiin julkaisujärjestelmätuotteen varaan. Tarvetta sisällönmuokkauskäyttöliittymälle ei olisi ja rajoittaisiko valmis softa liikaa käsiä vai taipuisiko se kustannustehokkaasti meidän ja käyttäjien tarpeisiin? Toinen kysymys oli se että, jos uutta sivustoa lähdettäisiin tekemään meidän voimin, niin haluaisimmeko edes vai tekisimmekö sivuston ns. skrätsistä.

En hetkeäkään epäile etteikö sivustoa olisi voinut toteuttaa valmiilla softalla ulkoisesti sellaiseksi, kuin millaisena se elokuussa julkaistiin. Näin varmasti olisi tehtykin, jos päivätöinämme toteuttaisimme sivustoja WordPressillä, Drupalilla tms., koska työ olisi tietenkin ollut nopeaa ja alustan mahdollisuudet ja rajoitteet hyvin tiedossa. Meillä sen sijaan olisi ollut useamman päivän tutkimusmatka edessä selvittääksemme miten valitulla alustalla toteutus olisi kannattanut tehdä sen parhaita kehitys- ja laajennoskäytäntöjä noudattaen.

Skrätsistä tehdyssä sovelluksessa kiehtoi mahdollisuus oppia uutta ja vapaat kädet tehdä parhaalla katsomallaan tavalla. Työn tuottavuus ei mielestämme ollut ongelma, koska jokaiseen tarpeeseen mitä tulisimme keksimään löytyy jonkinlainen avoimen lähdekoodin kirjasto mitä hyödyntää. Toisaalta tuottavuusriski piilee siinä, että kuinka montaa kirjastoa pitää kokeilla ennen kuin löytyy sopiva käsillä olevan ongelman ratkaisemiseksi. Sitten kun saimme tiedon siitä, että lähdetään uudistamaan sivustoa näillä käsillä, niin valinta alustan suhteen olikin jo oikeastaan tehty. Syteen tai saveen, skrätsistä tehdään. Projekti oli käytännössä kiinteähintainen, joten me tekijöinä kantaisimme riskin valintojemme seurauksista.

Lähtökohtamme toteutuksen arkkitehtuuriin oli se, että julkinen sivusto ja työpaikkailmoitusten jättämiseen työnantajien käyttämä ylläpitokäyttöliittymä erotetaan toisistaan kokoaan. Näin muutosten tekeminen yhteen ei olisi turhan riippuvaista toisesta ja päivittäminen sekä jatkokehitys olisi sujuvampaa ja riskittömämpää. Julkinen sivusto tulisi olemaan kasa staattisia tiedostoja (ilman tietokantaa), jotta se olisi mahdollisimman nopea ladata. Julkisen sivuston generointi ja työpaikkailmoitusten julkaisu ja ylläpito tultaisiin rakentamaan Node.js sovelluksina. Tietokannan virkaa toimittaisi MongoDB, jota käytettäisiin JSON rajapinnan kautta. Sovellukset hostattaisiin edelleen Herokussa, josta julkinen sivusto generoitaisiin tietyin väliajoin Amazon S3:een. Tulevaisuudessa mahdollisesti tehtävä työpaikkavahti rakennettaisiin MailChimpin / Mandrilin varaan.

Seuraavassa kuvassa on UX-suunnittelijan näkemys TKrekryn arkkitehtuurista. En tiedä millaisen kuvan kehittäjä piirtäisi.

TKrekryn tekninen arkkitehtuuri 2014

Backend kehityksestä

Terveyskeskusten ylläpitokäyttöliittymä päätettiin toteuttaa ns. single page JavaScript-sovelluksena, kuten nykyään on muodikasta. Alustava ajatus oli käyttää kehyksenä Ember.js:ää, mutta ensimmäisten kokeilujen jälkeen vaihdettiin Angular.js:ään. Vaihto tehtiin koska todettiin, että Ember.js:ää ei osattu riittävän syvällisesti eikä sitä ehditty projektin puitteissa opiskelemaan. Ennestään tutulla Angularilla saatiin tuottavammin tulosta aikaan. Itse node.js:n päälle tehtävää työsarkaa vähennettiin käyttämällä Express.js kehystä, joka teki MongoDB:tä tietokantana käyttävän REST-palvelun kehittämisestä suoraviivaista ja helppoa. REST-palveluun kirjoitettiin kattavat testit Mocha:n ja Chain avulla ja testipatteria täydennettiin tekemällä vähän end-to-end testejä Protractor:lla. Suurimmat haasteet ylläpitotyökalun toteutuksessa liittyivät IE8:n tukemiseen (josta lisää tuonnempana).

Staattisen sivuston generointiin otettiin avuksi JavaScript:llä kirjoitettu Docpad, jolla noin lyhyesti sanottuna voi generoida kaikenlaisia dokumentteja. Docpad:n laajennukset kirjoitettiin CoffeeScriptillä ja sivupohjat koottiin Jadea hyödyntäen. Docpadissa on paljon hyvää ja valmista, mutta näin jälkikäteen tunteemme sitä kohtaan ovat ristiriitaisia emmekä ole aivan varmoja oliko sen käytöstä enemmän hyötyä vai haittaa. Ensinnäkin työkalussa tuntuu olevan jokin suorituskykyyn liittyvä ongelma, joka johtaa muistin vuotamiseen. Tämän johdosta sovellus pitää välillä uudelleenkäynnistää. Toisekseen Docpadin dokumentaatio jättää toivomisen varaa mm. esimerkkien puuttuessa. Lahjoitimme projektille kuitenkin kokonaiset $7, joten odotukset olivat korkealla 😛

Ideaalimaailmassa heittäisimme Docpadin todennäköisesti roskiin ja tekisimme sivuston generoinnin jotenkin muuten.

Kehitykseen luonnollisesti liittyi keskustelu kehitysympäristöistä jne. ja koska kuulemma Windowsilla ei voi tehdä mitään aikuisten töitä, niin allekirjoittanut käytti projektin ajan “sujuvasti” Nitrous.io kehityspurkkia. Palvelun kautta saa pytyn käytiin muutamalla klikkauksella, mutta se on sitten oma keskustelunsa voiko niillä tehdä oikeasti vakavaa kehitystyötä. Tässä tapauksessa purkki oli minun käyttöön riittävä, mutta johtuen mm. sivuston generoinnin muistinkäytöstä, piti purkista maksaa vähän rahaa. Puolen vuoden aikana palvelu taisi olla kerran pois linjalta ja ihan ymmärrettävästä syystä ks. kuva alla.

Nitrous down OpenSSL (Heartbleed)

Frontend kehityksestä

Kun aloitin kokopäivätyöt alalla 2007, oli Web 2.0 vouhotus käynnissä. Ajax oli myyntisanana keksitty pari vuotta aikaisemmin ja jQuerya oli kehitetty vuoden ajan. IE6 oli valtaselain ja Firefox edusti edelleen kaikkea uutta ja ihanaa. Facebookkiin suhtauduin skeptisesti (Miksi kukaan haluaisi ”mikroblogata” raportoiden arkielämästään julkisesti netissä?!?) ja aikajana näyttää lähinnä kaveripyyntöjä tuolta ajalta ja vähemmälti mitään sisältöä. Työnjako kehittäjän ja käyttöliittymäkaverin välillä oli melko selvä: Kaikki mikä ei ole HTML:ää, CSS:ää ja JavaScriptiä, kuuluu sille backend-tyypille. Eikä sillä JavaScriptillä silloin vielä mitään monimutkaista tehty. Käytetyt softa-alustat (Sharepoint mm.) toivat tullessaan enemmän valmista toiminnallisuutta kuin kukaan ikinä tulisi tarvitsemaan. Käytännössä siis se fronttikehitys minkä minä olen oppinut tuntemaan ja päässäni jäsentämään, oli ensisijaisesti asioiden laittamista näyttämään joltakin ja toissijaisesti niiden laittamista toimimaan jotenkin.

Tuosta ajasta maailma on muuttunut siinä mielessä, että JavaScript on nykyään vakavasti otettava ohjelmointikieli, eikä se enää määritä tapahtuuko kehitys edessä vai takana. Sekä etu- että takapää voidaan toteuttaa JavaScriptillä ja osa sovelluksesta voi olla palvelimella tai sitten se voi toimia kokonaisuudessaan selaimessa. Tämän johdosta front-end kehittäjän toimenkuvan määrittäminen on entistä vaikeampaa. Jos joku toimenkuvallinen raja pitää piirtää, niin mihin se piirretään? Olisiko se esim. HTML, CSS ja JavaScript mVc? Joku voisi kyseenalaistaa, että miksi moinen raja pitää olla olemassa? Eikö kehittäminen ole kehittämistä ja sillä selvä? Tähän vastaan, että tunnen kehittäjiä jotka eivät pitkällä tikullakaan koskisi CSS:ään, jos ei ole aivan pakko ja toisaalta en jättäisi edellä kuvatun arkkitehtuurin suunnittelua itseni harteille. Sitten päästään kysymykseen, että eikö sen graafisen suunnittelijan pitäisi tehdä ne CSS:t, johon vastaan… meistä on moneen veneeseen eivätkä kaikki osaa, ole hyviä tai halua tehdä kaikkea jne. Se on tärkeää, että kaikki projektin jäsenet ovat mukana tekemässä alusta loppuun, mutta siinä ei ole mitään järkeä että kaikki tekevät samoja asioita.

TKrekryssä mentiin tällä linjalla. Minä koostin käyttöliittymät ja Jaakko toteutti niiden toiminnallisuuden. Ylläpitosovelluksessa käyttöliittymä pohjautui Bootstrap CSS-kehykseen, josta oli merkittävä hyöty työn tuottavuudelle, koska näkymät koostuvat pääasiallisesti lomakkeista. Näiden tyylittäminen tyhjästä olisi ollut merkittävä ponnistus suhteessa projektin kokonaisbudjettiin. Yksinkertaisella julkipuolella en katsonut tarpeelliseksi turvautua Bootstrappiin. Projektin alussa oli jo hyvä haju siitä, että CSS:n määrä tulisi olemaan pieni, jolloin myös esiprosessoreiden tuomat tuottavuushyödyt jäisivät pieneksi. Tästä syystä päätin kirjoittaa puhdasta CSS:ää, jota kaiken kaikkiaan syntyi noin 1300 riviä.

Ylläpitosovelluksen toteutuksessa käytettiin Angularia ja muutamaa sen laajennosta mm. tiettyjen käyttöliittymäkomponenttien aikaan saamiseksi. jQueryä ei juuri käytetty muuten, kuin Bootstrapin komponenttien riippuvuuden takia ja senkin riippuvuuden voisi purkaa tulevaisuudessa, jos homma osoittautuu vaivan arvoiseksi.

Mitä tulee tuettaviin selaimiin, niin päätimme kävijätilastojen perusteella tukea vielä IE8:a. Ylläpitopuolella tämä tarkoitti erinäisten kolmansien osapuolien kirjastojen lukitsemista tiettyyn IE8:a tukevaan versioon, erilaisten paikkausten ja tilkkeiden käyttöä esim. respond.js ja kohtuuttomasti revittyjä hiuksia ja bugien perässä juosten hukkaan heitettyä aikaa. Uskon, että IE8 tulee vainoamaan meitä vielä pitkään, koska ainakin ne julkisorganisaatiot joiden kanssa olen ollut tekemisessä, ovat kuolettavan hitaita päivittämään selaimiaan. Kummallista tässä on, se että jos esim. viime syksynä on siirrytty Win XP:stä Win 7:aan, niin oletusselaimeksi on jätetty edelleen IE8 vaikka pari-kolme uudempaakin versiota olisi ollut saatavilla. Tiedä sitten onko vieläkin jossain aikanaan IE6:lle tehtyjä ja ainoastaan quirksmodessa toimivia sovelluksia käytössä, jotka toimivat kehityksen jarruna hankaloittaen selainten päivittämistä uudempiin. En keksi muuta syytä mistä moinen toiminta tai oikeastaan toimimattomuus johtuu. IE8 on nykypäivän IE6, joka olisi syytä toimittaa jo ansaitsemaansa haudan lepoon.

Todettakoon vielä, että valitulla hostausratkaisulla on myös vaikutuksia fronttitekemiseen. Julkinen sivusto on hostattu Amazon S3 ämpärissä ja koska kyseessä ei ole webpalvelin, niin tiedostojen pakkaaminen ja vanhenemisaikojen asettaminen sivuston latausaikojen ja näin ollen käytettävyyden parantamiseksi ei onnistu asetuksia säätämällä. Sivusto pitäisi pakata etukäteen sen generoinnin yhteydessä ja vasta sitten puskea S3:een. S3 käyttää menestyksekkäästi Etageja, mutta tiedostojen vanhenemisaikojen asettaminen sivuston lataamisen yhteydessä vähentäisi palvelimen suuntaan tehtyjä pyyntöjä entisestään. Lisää tekemistä toiveiden tynnyriin. S3:n uudelleenohjauksien rajoituksista kirjoitin edellisessä jutussa.

Avointa lähdekoodia

Sekä julkisen sivuston, että ylläpitosovelluksen lähdekoodit on julkaistu avoimena MIT-lisenssillä ja repot löytyvät GitHubista. Ennen julkaisua kuvatiedostot siivottiin (ja paljon muuta) pois projekteista Cloudinaryyn, koska emme laiskoina jaksaneet lähteä selvittämään mitä niistä olisi lisenssissä pitänyt mainita. Julkisen sivuston projektista löytyy oletettavasti Googlen tekijänoikeuksilla oleva OpenSans fontti(tiedostot), joka on julkaistu Apache 2.0 lisenssillä (jos keksit tästä ristiriidan, niin heitäpä kommentti).

Samoin tällä hetkellä tunnetut bugit ja muutama kehitysehdotus listattiin GitHubiin. Josko ihan vaivihkaa tekisivät itse itsensä. Muuten ei vielä olla hirvittävän avoimessa moodissa, koska esim. ohjeet kehitysympäristön pystyttämiseen puuttuvat. Jos talkoot kiinnostavat, niin kirjoitellaan ohjeita sitten 😉

Retrospektiivi

Kaiken kaikkiaan projekti sujui hyvin ja valmistui budjetissa, aikataulussa ja sisällössä. Seuraavassa kuitenkin muutamia seikkoja joihin kiinnittäisimme seuraavalla kerralla huomiota:

  • Joitakin teknologisia oikoteitä on matkan varrella otettu eikä budjettiin mahtunut eri kehityslinjojen saati käytettyjen työkalujen kartoitus ja vertailu riittävällä tasolla. Tämä tulee varmasti kostautumaan jossain vaiheessa ylimääräisenä työnä niin kuin tapana on. Vaikka merkittävää arkkitehtuurisuunnittelua ei voi tai kannata ennen toteutusta tehdä, on epävarmojen asioiden tutkimiselle varattava riittävästi aikaa/pisteitä/tilaa/rahaa budjettiin.
  • Jälleen kerran: Työmääräarvio on lähes aina liian pieni. Sen jälkeen, kun arvio asiasta X on annettu, on se syytä kyseenalaistaa iteroimalla asian sisältö uudestaan ja arvaamalla uudestaan.
  • Projekti oli liian suuri tehtäväksi siten, kuin se nyt tehtiin eli toinen meistä teki pääsääntöisesti osa-aikaisesti päivällä töitä ja toinen päätoimensa ohella iltaisin. Tämän johdosta ja toisaalta siitä, että meillä ei ollut määräajan kanssa hoppu, projektista tuli kalenteriajassa pitkä. Tämä taas johti esim. siihen, että asioita unohtui enemmän kuin mitä intensiivisemmässä, mutta lyhyemmässä projektissa olisi unohtunut. Toisistaan erillään ja eri aikaan tapahtuva työskentelystä aiheutui myös viestinnällisiä ongelmia, joita ei olisi ilmennyt kasvokkain työskennellessä. Projekti olisi pitänyt jakaa selkeämmin kalenteriin sidottuihin inkrementteihin ja tunnistaa paremmin työt jotka olisi kannattanut järjestää kasvotusten tehtäviksi.
  • Alustava backend/arkkitehtuurityö olisi hyvä eriyttää irralleen ominaisuuksista backlogissa. Ehkä, mutta sitten mennään oppikirjojen antia vastaan siitä, että jokaisen asian backlogissa pitää tuottaa näkyvää arvoa asiakkaalle ja loppukäyttäjälle…

Ja lopuksi: Älä tee kiinteähintaisia projekteja PISTE.

2kk julkaisun jälkeen, mitä kävijätilastot kertovat

Tkrekry.fi:n julkaisusta on nyt kulunut reilu kaksi kuukautta ja on aika katsoa hieman kävijätilastoja. Miten meillä menee? Tätä ennen kuitenkin mennään hieman taaksepäin ja tarkastellaan sivuston tavoitteita uudemman kerran.

Tavoitteet

Keväällä kirjoitin TKrekryn tavoitteista ja mittareista juttua ja tuskailin mittaamisen utuisuutta, kun sivustolla ei ole selkeitä toimintokutsuja (call-to-action) joiden käyttöä mitata. Tämä ei sinänsä ole muuttunut mihinkään, mutta ajattelin että ei ole haitaksi, jos tavoitteita ja mittareita tarkastellaan uudestaan web-analytiikkaguru Avinash Kaushikin mallin avulla. Malli tarjoaa yksinkertaisen sapluunan, jolla tunnistetaan sivustoon liittyvät liiketoiminnan tavoitteet, sivuston tavoitteet, mittarit tavoitteille, tavoiteluvut kullekin mittarille sekä asiakassegmentit joiden avulla tehdä analyysiä. Myös Google käyttää tätä mallia Analytics- koulutusmateriaalissaan ks. esim. video:

Seuraavassa taulukossa on kuvattu TKrekry ko. mallin läpi tarkasteltuna tämän hetken ymmärryksemme mukaan.

Liiketoiminnan tavoite: Lääkärien ja hammaslääkärien terveyskeskuksiin rekrytoinnin tukeminen.

Strategiat:

1) Terveyskeskuksessa työskentelystä kertominen 2) Lääkärien ja hammaslääkärien rekrytointiin liittyvien yhteydenottojen lisääminen
Tavoite 1:
Käyttäjät lukevat terveyskeskuksessa työskentelystä
Mittari 1:
???

Tavoiteluku 1:
???

Tavoite 2:
Käyttäjät katsovat työpaikkailmoituksia ja ottavat yhteyttä terveyskeskukseen

Mittari 2:
Työpaikkailmoitusten konversioaste
Ilmoitusten lataukset

Tavoiteluku 2:
???

Tavoite 3:
Käyttäjät katsovat terveyskeskusten esittelyjä ja ottavat yhteyttä terveyskeskukseen

Mittari 3:
Terveyskeskusten esittelyjen konversioaste
Esittelyjen lataukset

Tavoiteluku 3:
???

Segmentit:
liikenteen lähteet, päätelaitteet jne.

Ensimmäisen tavoitteen mittari pitäisi siis vielä kehittää, kuten myös tavoiteluvut kaikille mittareille. Koska tälle sivustolle tavoitelukujen laskeminen terveyskeskusten rekrytoinnin tulosten kautta ei ole mahdollista (ainakaan tänä päivänä), joudutaan tyytymään historian määrittämän lähtötason parantamiseen.

Vuoden 2013 syys-lokakuussa 23,91% (ka. 940 / kk) vierailuista johti sivuille joissa kerrottiin terveyskeskuksessa työskentelystä. 2014 tammi-heinäkuussa vastaava luku oli 24,47% (830 / kk). Mittarin 1 tavoiteluvun pitäisi olla suurempi kuin nämä.

Vuoden 2013 syys-lokakuun vertailujakson konversioaste työpaikkailmoituksille oli 12,12% ja ilmoituksia ladattiin keskimäärin 906 kertaa / kk. 2014 tammi-heinäkuussa vastaava luvut olivat 11,97% ja 702 / kk. Mittarin 2 tavoiteluvut pitäisivät siis olla suuremmat kuin nämä.

Tavoitelukua 3 ei sen sijaan voida määrittää menneisyyden perusteella, koska vanhalla sivustolla ei ollut erillisiä esittelysivuja terveyskeskuksille.

TKrekryn malli näyttää seuraavalta, kun päivitetyt tiedot syötetään pyöristäen taulukkoon.

Liiketoiminnan tavoite: Lääkärien ja hammaslääkärien terveyskeskuksiin rekrytoinnin tukeminen.

Strategiat:

1) Terveyskeskuksessa työskentelystä kertominen 2) Lääkärien ja hammaslääkärien rekrytointiin liittyvien yhteydenottojen lisääminen
Tavoite 1:
Käyttäjät lukevat terveyskeskuksessa työskentelystä
Mittari 1:
Ko. sisältöjen konversioaste
Ko. sisältöjen lataukset

Tavoiteluku 1:
> 25% konversio
> 983 / kk sivulatausta

Tavoite 2:
Käyttäjät katsovat työpaikkailmoituksia ja ottavat yhteyttä terveyskeskukseen

Mittari 2:
Työpaikkailmoitusten konversioaste
Ilmoitusten lataukset

Tavoiteluku 2:
> 13% konversio
> 906 / kk sivulatausta

Tavoite 3:
Käyttäjät katsovat terveyskeskusten esittelyjä ja ottavat yhteyttä terveyskeskukseen

Mittari 3:
Terveyskeskusten esittelyjen konversioaste
Esittelyjen lataukset

Tavoiteluku 3:
???

Segmentit:
liikenteen lähteet, päätelaitteet jne.

Tästä esimerkistä jälleen nähdään, että mittaamisen suunnittelu ei ole helppoa TKrekryn tyyppiselle sivustolle, jolta konkreettiset toiminnot puuttuvat. Tietenkin eräs tapa mitata sisältösivustoa on se, kuinka paljon sen sisältöä jaetaan eteenpäin esim. sosiaalisessa mediassa. Tästä aiheesta ehkä lisää myöhemmin.

Sivulatausten määrä ei myöskään ole hyvä mittari, koska emme oikeasti voi tietää, että lukiko sivun ladannut käyttäjä sen sisällön. Toki voisimme asettaa mittarille reunaehtoja esim. että konversiosivulla pitää viettää vähintään 30 sekuntia aikaa ennen kuin sivulataus lasketaan konversioksi tai voisimme laukaista ja raportoida GA:han tapahtuman, kun sivu on vieritetty loppuun jne. jne. Vaikka erilaisilla tempuilla sivulatausmittarista saataisiin ainakin näennäisesti parempi ei sen lähtökohtaista heikkoutta saa koskaan poistettua.

Raportointia

No miten sitten kävi? Seuraavassa taulukossa on muutamia havaintoja, joissa vertaillaan 2014 syys-lokakuuta vastaavaan jaksoon 2013 ja tammikuu-heinäkuun 2014 keskiarvoihin. En ottanut elokuuta mukaan vertailuun, koska uusi sivusto julkaistiin kesken elokuun. Kummakin vertailujakson lukujen perään on laskettu prosenttiosuus siitä mihin suuntaan ja kuinka paljon tunnusluku on kehittynyt suhteessa tähän päivään.

# mittari 2014 syys-lokakuu 2013 syys-lokakuu 2014 tammi-heinäkuu
1 kävijät / kk 2105 3261 (-35%) 2742 (- 23%)
2 bounce rate 41,95% 55,96% (- 25%) 59,34% (- 29%)
3 sivulataukset / vierailu 3,16

2,48 (+ 27%)

2,71 (+17 %)
4 työpaikkailmoitusten lataukset / kk 1351 906 (+ 49%) 702 (+ 93%)
5 työpaikkailmoitusten konversio % 26,46% 12,12% (+ 118%) 11,97% (+ 121%)
6 terveyskeskusten sivulataukset / kk 1701
7 terveyskeskusten konversio % 27,97%
8 muiden sisältöjen sivulataukset / kk 380 940 (- 60%) 830 (- 54%)
9 muiden sisältöjen konversio % 9,71% 23,91% (- 59%) 24,47 (- 60%)

Sivuston keskimääräinen kävijämäärä on laskenut huomattavasti. Pääsyyllinen liikennemäärän laskuun on se, että hakukoneista on tullut keskimäärin vähemmän vierailuja / kk sivustolle syys-lokakuussa (1457 kpl) kuin vastaavana aikana 2013 (2722 kpl, – 46%) tai tammi-heinäkuun (2312 kpl, – 37%) vertailujaksolla. Kaikkia vanhan sivuston sivuja ei saatu uudelleenohjattua uudelle sivustolle. Amazon S3 mahdollistaa vain 50 URL:n uudelleenohjauksen per bucket, mikä on saattanut vaikuttanut sivuston näkyvyyteen Googlen hakutuloksissa, kun Googlebot on kohdannut 404 statuksia seurattuaan linkkejä vanhalle sivustolle. Tärkeimmät sivut kuitenkin saatiin uudelleenohjattua, joten uskallan väittää että tämä vähentynyt liikenne ei ole laadultaan ehkä parasta mahdollista.

Toisaalta sisältösivujen tekstiä karsittiin ja tiivistettiin jonkin verran, otsikot ovat muuttuneet jne., joilla toki on myös vaikutusta sivujen hakukonenäkyvyyteen. Taulukon rivit 8 ja 9 paljastavat melkoisen tiputuksen sisältöjen kulutuksessa. On myös mahdollista, että Googlen algoritmien päivitys ja ihan vain kausittainen vaihtelu ovat vähentäneet hakuliikennettä.

Sittemmin haun kautta tulevan liikenteen määrä on alkanut taas kasvaa. Alla olevasta kuvasta nähdään miten sivuston esiintyminen Googlen hakutuloksissa on kehittynyt (uusi sivusto julkaistiin 23.8.).

Webmaster Tools - Search Queries
Webmaster Tools – Search Queries

Laskenut bounce rate ja nouseva työpaikkailmoitusten nouseva konversio puhuvat sen puolesta, että uuden sivuston toteutuksessa jotain on tehty oikein. Erityisesti mobiililaitetta käyttäneiden vierailijoiden bounce rate on laskenut (-38%) vuoden takaisesta ja sivustolla vietetty aika, tehdyt sivulataukset ja työpaikkailmoitusten konversioaste (9,04% → 28,55% = +216% !!!) ovat kasvaneet. Tämä johtuu osittain yleisestä Internetin käytön kasvusta mobiililaitteilla, mutta myös siitä että uuden sivuston responsiivinen käyttöliittymä palvelee paremmin käyttäjiään.

Sivuston latausajat ovat myös parantuneet mikä tietenkin vaikuttaa positiivisesti myös sivuston käytön tunnuslukuihin. Latausnopeudet ovat merkittävä osa minkä tahansa tuotteen tai palvelun käyttökokemusta. Uudella sivustolla sivun keskimääräinen latausaika on 1,13 sekuntia kun vanhalla se oli 3,65 (- 69%). Tästä pitäisi olla etua myös hakukonenäkyvyydessä, koska ainakin Googlen pitäisi huomioida sivuston latausajat jollain tavalla algoritmissaan. Googlebotin silmin tilanne näyttää myös nopeutuneen merkittävästi ks. kuva alla.

Webmaster Tools - Crawl Stats
Webmaster Tools – Crawl Stats

Yhteenveto

Lyhyestä virsi kaunis. Seuraavassa yhteenvetona kolme vinkkiä sivustojen suunnitteluun ja toteutukseen hakukoneiden näkökulmasta katsottuna:

  1. Suunnittele sivuston tavoitteet, mittarit ja tavoiteluvut jo konseptia luotaessa. Laskeminen voi olla työlästä, mutta kuten aikaisemmin jo totesin, niin jokainen investointi pitäisi olla numeroin perusteltavissa. Call-to-actionit ohjaavat käyttäjien toimintaa haluttuihin tavoitteisiin ja helpottavat myös mittaamista konkreettisesti.
  2. Tee itsellesi sivuston konseptia tai viimeistään sisältöä luotaessa SEO-tarkistuslista, jolla pidät huolen siitä että sisällöntuotannossa ja teknisessä toteutuksessa tulee kaikki tarpeelliset asiat huomioitua ja tehtyä. Priorisoi lista, koska jostain pitää kuitenkin aina tinkiä.
  3. Sisältöstrategiaa tehtäessä, sisältöä inventoitaessa ja tuotettaessa kannattaa laatia jo suunnitelma sille miten vanhat sivut tullaan uudelleenohjaamaan (301) uusiin, jos/kun URL-rakenne muuttuu. Analytiikan avulla on myös selvitettävissä se, mitkä useimmiten toistuvat väärin kirjoitetut osoitteet kannattaa uudelleen ohjata varsinaiselle sivustolle. Pidä huoli, että sivustolla on 404-statuksen palauttava 404-sivu, josta botit pääsevät eteenpäin jos varsinaista sivua ei löytynyt.

Julkaistu! Lepo!

Sinne se meni. Julkaistiin liveksi tuontantoon. Ja lähes vaivihkaa ilman kommervenkkejä. Tai no yksi bugi oli vähän aikaa allekirjoittaneen jäljiltä, mutta ei siitä sen enempää 🙂

Ensimmäiset työpaikkailmoitukset ja terveyskeskusten esittelyt on myös julkaistu, joten ainakin osa terveyskeskuskäyttäjistä tulee toimeen uuden ylläpitotyökalun kanssa. Myös muutamia käyttäjätunnuksia on päässyt tekemään ja ainakin vielä suunniteltu ylläpitokuvio toimii hyvin.

Jotenkin on takki auki julkaisun jälkeen etten ole edes oikein keksinyt mitä siitä pitäisi kirjoittaa. Kalenteriajassa pitkän projektin tärkein virstanpylväs on nyt takana ja projekti viimeistelyä vaille valmis. Vielä pitäisi tehdä markkinointia, käyttäjien aktivointia, muokata vähän RSS-syötettä, virittää analytiikka kuntoon ylläpitopuolelle jne. Ja kuulemma jotain siivoustakin pitää tehdä ennen kuin ne luvatut lähdekoodit kehtaa laittaa GitHubiin jakoon.

Projektin retrospektiivin jälkeen on varmaan taas enemmän kirjoitettavaa ja ajattelinkin raapustaa siitä tänne jutun. Lisäksi ainakin front-end devaus, työkalut ja tekniikka ylipäätään sekä tavoitteet ja mittaaminen (taas) ovat aiheita mistä tulen kirjoittamaan jatkossa. Ehkäpä myös siitä käyttöasteesta ja avoimesta lähdekoodista tulee myös juttua.

Aika näyttää.

PS. Kiitokset Jaakolle, Pasille ja Johannekselle sekä Pirkanmaan sairaanhoitopiirin projektiryhmälle onnistuneesta julkaisusta!

Julkaisuun neljä päivää

Projekti etenee ja nyt ollaan siinä vaiheessa, että julkaisuun on enää neljä päivää. Julkaisemme siis uuden sivuston 23.08.2014 lauantaina. Lauantaisin on tilastojen mukaan viikon hiljaisin päivä eivätkä työpaikkojen ilmoittajat ole tuolloin yleensä töissä. Toisaalta tulevana lauantaina on myös poikamme ensimmäiset syntymäpäivät, joten saa nähdä millainen hässäkkä tästä vielä tulee.

Pystytimme tuotantoympäristöt eilen Herokuun ja Amazonin S3:een ja yllättävän paljon viimeisteltävää on vielä jäljellä (kirjoittelen lisää sivuston arkkitehtuurista ja tekniikasta julkaisun jälkeen). Esim. S3 ei luonteensa vuoksi pakkaa kutsuttaja tiedostoja lennosta, joten ne pitää pakata etukäteen ennen sinne työntämistä. Tänään pitäisi testata miten uudistuksen myötä poistuvien URL:en uudelleenohjaukset onnistuvat Amazonissa jne. Osa viilauksista jätetään suosiolla julkaisun jälkeen tehtäväksi.

Mutta niinhän se usein menee, että läksyt tehdään viimeisenä iltana tai sen jälkeen.

Julkaisuun liittyy myös muutakin häslinkinä mm. työpaikkojen ilmoittamiseen tarvittavat käyttäjätunnukset vaihtuvat. Aikaisemmin ne olivat organisaatiokohtaisia, mutta uudistukseen jälkeen käyttäjillä on omat henkilökohtaiset tunnukset. Aiheesta on sivuston käyttäjiä tiedotettu, mutta veikkaan että aikaa moneen ”en pääse kirjautumaan” viestiin päästään vastaamaan julkaisun jälkeisinä kuukausina.

Sitten vaan hommiin. Ensi viikolla nähdään miten julkaisu meni (peukut pystyyn!).

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.

Tavoitteet ja mittarit

Kaikella liiketoiminnalla tulee olla toimintaa ohjaava visio ja mitattavat tavoitteet, myös www-sivustolla kun se on osa organisaation liiketoimintaa. Organisaation asiakkailla on myös omat tavoitteensa, joihin päästäkseen he saattavat sivustoa käyttää. Joskus nämä käyttäjien tavoitteet saattavat olla ristiriidassa liiketoiminnan tavoitteiden kanssa. Tässä jutussa pohditaan millaisia tavoitteita pääasiallisesti informaatiosisältöiselle sivustolle voisi asettaa ja miten niitä mitataan.

Verkkosivustojen tavoitteista yleisesti

Tavoitteita voidaan luokitella (ja analysoida) monella eri tavalla, mutta tässä yhteydessä meille riittää jako kolmeen ryhmään:

  1.        Liiketoiminnan tavoitteet
  2.        Sivuston tavoitteet
  3.        Käyttäjien tavoitteet

Sivuston tavoitteet johdetaan liiketoiminnan tavoitteista esim. jos organisaatiolla on tavoitteena kasvattaa varaosamyyntiä 15%, niin tästä voidaan johtaa verkkosivustolle tavoitteeksi kasvattaa saatujen liidien määrää 40%. Näiden tavoitteiden tulisi olla ns. fiksuja (SMART) tarkoittaen että ne ovat esim. (kukin valitkoon mieleisensä attribuutit):

  •          Yksiselitteisiä (Specific)
  •          Mitattavia (Measurable)
  •          Toimintaa ohjaavia (Actionable)
  •          Olennaisia (Relevant)
  •          Seurattavia (Trackable)

Tavoitteet voidaan tietenkin luokitella edelleen päätavoitteisiin ja toissijaisiin tavoitteisiin.

Hyvien tavoitteiden suunnittelu on haastavaa (kuten seuraavassa osiossa nähdään). Verkkokaupoille, B2B-sivustoille, asiointipalveluille jne. toiminto-orientoituneille sivustoille yleensä kuitenkin löytyy sopivalla järkeilyllä sopivat tavoitteet ja niihin osuvat mittarit. Informaatiosivustoille, joiden sisällön kuluttaminen on ilmaista eikä vaadi rekisteröintiä, tavoitteiden ja mittareiden suunnittelu on huomattavasti utuisempaa puuhaa.

TKrekryn tavoitteet ja mittarit

Juttusarjan ensimmäisessä TKrekryn taustoja käsittelevässä osassa sivustolle listattiin seuraava tarkoitus ja visio:

TKrekry on verkkosivusto, jonka tavoitteena on tukea ja tehostaa lääkärien ja hammaslääkärien rekrytointia terveyskeskuksiin:

  • Kertomalla mitä työskentely terveyskeskuksessa on ja mistä terveyskeskuksen palkkalistoilla olevan lääkärin tai hammaslääkärin palkka muodostuu.
  • Ilmoittamalla terveyskeskusten avoimista työpaikoista (ainoastaan lääkärit ja hammaslääkärit tässä vaiheessa).
  • Tekemällä yhteydenoton terveyskeskuksen rekrytoinnista vastaaviin henkilöihin mahdollisimman helpoksi.

Visio: TKrekry on ensimmäinen ja tärkein tiedonlähde jokaiselle uutta työpaikkaa hakevalle lääkärille tai hammaslääkärille. TKrekry palvelee sekä terveyskeskusten, että työnhakijoiden tarpeita olemalla selkeän informatiivinen ja käytettävä verkkopalvelu.

Sivuston päätavoite on siis tukea ja tehostaa lääkärien ja hammaslääkärien rekrytointia terveyskeskuksiin lähinnä kasvattamalla terveyskeskuksille tulevien liidien eli työnhakijoiden yhteydenottojen määrää. Tämän tavoitteen selkeä mittari olisi tieto siitä, kuinka moni terveyskeskukseen työllistyneistä on saanut paikan TKrekryn avustamana (ja ovatko he ottaneet yhteyttä suoraa vai jonkin ilmoituksen tiimoilta). Ikävä kyllä tämän tiedon keräämiseen ei ole resursseja.

On siis yritettävä mitata jotain muuta ja tätä varten sivuston tavoitetta on jatkojalostettava, jotta siitä saadaan fiksu. Jos asiaa ajatellaan edelleen käyttäjän näkökulmasta, niin ensisijaisen käyttäjäryhmän (työpaikkaa etsivät lääketieteen opiskelijat tai vastavalmistuneet) tärkein tavoite on saada itselle sopiva työpaikka. Sivuston vastaa tähän tarpeeseen tarjoamalla terveyskeskusten rekrytoinneista vastaavien henkilöiden ajantasaiset yhteystiedot käyttäjille, koska käyttäjätutkimukseen osallistuneiden ensisijainen työnhakutapa on suora yhteydenotto potentiaaliseen työnantajaan puhelimella tai sähköpostilla.

Koska sivustolla ei ole toiminnallisuutta, esim. yhteydenottolomaketta, jonka käyttöä voitaisiin mitata suhteessa tavoitteeseen, jää terveyskeskusten yhteystietojen kulutus ainoaksi järkeväksi mittariksi. Kulutus tässä yhteydessä voisi tarkoittaa ko. sisältöjen sivulatausten määrää, kuinka moni kävijöistä päätyy ko. sisältösivuille, sivuilla käytettyä aikaa jne.

Seuraavassa taulukossa on purettu tavoitetta ja mahdollisia mittareita tasoittain auki.

Taso Sivuston tavoite Käyttäjän tavoite Mittari
1 Lääkärien ja hammaslääkärien terveyskeskuksiin rekrytoinnin tukeminen ja tehostaminen. Hankkia itselleen sopiva työpaikka. Terveyskeskuksiin työllistyneiden kokonaismäärä suhteessa siihen kuinka moni työllistyi TKrekryn avustamana.
1.1 Lääkärien ja hammaslääkärien työnhakuun liittyvien terveyskeskuksiin tehtyjen yhteydenottojen määrän kasvattaminen. Ottaa yhteyttä kiinnostaviin työnantajiin. Yhteydenottojen määrä.
1.1.1 Sivuston terveyskeskuksen esittelysivujen kulutus / käyttäminen. Yhteystietojen kopioiminen itselle. Esittelysivujen latausten määrä.
1.1.2 Sivuston työpaikkailmoitusten kulutus / käyttäminen. Yhteystietojen kopioiminen itselle. Työpaikkailmoitusten sivulatausten määrä.

Tällä hetkellä vasta viimeisen tason mittaaminen on teknisesti mahdollista. Sivulatausten määrä ei mittarina ole yksiselitteinen eikä meillä ole mahdollista tunnistaa kuuluuko kävijä sivuston kohderyhmään vai ei eli emme tiedä kuka niitä sivulatauksia tekee. Mittarit jäävät mielestäni liian abstraktille tasolle, kun tavoite on se ”toiminnan tehostaminen”.

No ovatko nämä tavoitteet (1.1.1 ja 1.1.2) sitten yksiselitteisiä, mitattavia, toimintaa ohjaavia, olennaisia ja seurattavia? Mielestäni kyllä, mutta mitä mieltä sinä olet?

Ja toinen kysymys kuuluu, että miten muuten tavoitteita voitaisiin jalostaa ja miten mitata? Hyviä ideoita otetaan vastaan!

Raportointia vai web-analytiikkaa

TKrekryn käyttöastetta ja sen kehitystä on ja voidaan seurata perinteisin tunnusluvuin:

# Mittari

2013 keskiarvo / kk

2013 yhteensä

1 Yksilöidyt kävijät

3201

35851

2 Ylläpitotyökalun yksilöidyt kävijät

10

91

3 Työpaikkailmoitusten sivulataukset

865

10375

4 Yksilöityjen työpaikkailmoitusten määrä sivustolla

72

450

5 Aktiivisten terveyskeskusten määrä

65 / 150

(Huom. taulukossa keskiarvot on laskettu Google Analyticsistä kerätyt kuukausittaiset luvut summaamalla ja jakamalla 12:a. 2013 yhteensä on suoraa GA:sta poimittu luku.)

”Entä sitten?”, on oikeutettu kysymys. Mitä nämä luvut kertovat, mitä hyötyä niiden raportoimisesta on ja pitäisikö niitä raportoida alkuunkaan? Ainakin ne kertovat sen miten sivuston käyttöaste kehittyy, kun lukuja verrataan edellisiin ajan jaksoihin. Varsinaisesta web-analytiikasta ollaan vielä kaukana, jos sen tarkoitus on tuottaa kävijäseurantadatan (plus kvalitatiivisen tutkimuksen avulla) pohjalta informaatiota ja siitä edelleen toimintaa ohjaavia oivalluksia (actionable insights) siitä mikä toimii, mikä ei toimi ja miten sivustoa tulisi kehittää eteenpäin.

Kävijäseurantatyökalujen todellinen hyöty piileekin juuri siitä, että niiden avulla voidaan kaivaa johtolankoja käyttäjätutkimuksen ja sivuston jatkokehityksen aiheiksi, mutta ilman osaavaa analyytikkoa niistä on kyseenalaista iloa lähinnä raportointiin. Työkalu kertoo, että kuka tekee ja mitä, mutta harvemmin pelkästään sen avulla saadaan selville miksi. Tämän selvittämiseen tarvitaan sitten kvalitatiivista tutkimusta esim. käytettävyystestien, kyselyiden, haastatteluiden jne. muodossa. Toisaalta kävijäseurantatyökalua voidaan käyttää myös mekaanisen käyttökokemuksen mittaamiseen esim. tehtävien onnistuminen, tehtävien läpimenoajat, käyttäjän kohtaamat virheet jne., mutta niiden avulla ei voida mitata subjektiivista käyttökokemusta tai käyttäjän kokemaa mielihyvää (tai pahaa).

Ja sitten loppuun vielä kysymys: Nyt kun TKrekryä ollaan uudistamassa, niin millaiset kasvutavoitteet em. mainituille tunnusluvuille pitäisi asettaa? Ja hei, nehän olisi pitänyt asettaa ennen projektin käynnistämistä, eikö? Mistä tiedän, että millainen sivusto tulee suunnitella ja toteuttaa, kun en tiedä kuinka paljon parempi sen pitäisi olla vanhaa sivustoa?

Ideaalimaailmassa tavoitteet ja mittarit ovat hyvin mietittyjä ja suunniteltuja, mutta aika moni sivuston uudistusprojekti etenee fiilispohjalta (etenkin pienet infosivustot). Hyviä johtolankoja on siitä mitä parannetaan, mutta tavoitelukujen asettamisen kanssa ollaan vähän niin ja näin. Väitän, että dataan pohjautuvan päätöksenteon kulttuuri ei ole vielä arkipäivää verkkopalveluiden rakentamisessa.

Lisäys 11.04.2014 – Kasvutavoitteet

Kirjoittaessani juttua en näköjään kirjoittanut sitä tähän, että miten ne kasvutavoitteet olisi pitänyt määrittää. Tässä siis siitä vielä muutama virke.

Jokainen investointi pitäisi olla numeroin perusteltavissa oli kyse sitten sivuston suorituskyvyn optimoinnista, käyttöliittymän ilmeen uudistamisesta, uuden markkinointikanavan avaamisesta tai täysremontista. Perusteluksi yleensä kelpaa se, että uudistuksen pitäisi tuottaa enemmän kuin mitä se kuluttaa. Kulut yleensä muodostuvat organisaation sisäisestä ja ulkoa ostamasta työstä, mahdollisista ohjelmistolisensseista ja jotain palvelintilastakin on yleensä maksettava. Tuoton kasvu perustuu vuorostaan siihen, että myydään enemmän (lisää asiakkaita ja isompia kauppoja) tai että säästetään kuluissa.

Verkkokauppojen osalta peli on selvä. Kun tiedetään ostoksen tai transaktio keskihinta, voidaan laskea kuinka paljon keskihintaa ja/tai ostostapahtumien määrää pitää kasvattaa, jotta investointi maksaa itsensä takaisin. B2B-sivuston tarkoitus vuorostaan on usein tuottaa liidejä esim. yhteydenottojen muodossa. Kun organisaatio tietää asiakkaan esim. tilikauden aikana tuottaman liikevaihdon keskiarvon ja sen kuinka monta liidiä tarvitaan että saadaan uusi asiakas, voidaan laskea kuinka paljon tarvitaan lisää liidejä investoinnin perustelemiseksi. Sähköiselle asioinnille, some-jaoille, uutiskirjeiden tilauksille, kommenteille, tiedostojen latauksille jne. jne. voidaan kaikille laskea jonkinlainen arvo tai yksikköhinta minkä ne tuottavat toteutuessaan.

Mutta miten lasketaan arvo sille tapahtumalle, että työpaikkailmoitusta tai yhteystietosivua ladataan yhden kerran? Kuten todettu, niin hyviä ideoita otetaan vastaan!

 

Sivuston ja sen uudistusprojektin taustaa – osa 2

Tässä juttusarjan toisessa osassa kerrotaan työnalla olevan TKrekry.fi:n uuden version suunnittelusta, joka tehtiin vuoden 2013 aikana. Juttusarjan ensimmäisessä osassa avattiin nykysivuston toteutuksen taustoja.

Sivuston uuden version suunnittelu käynnistyi 2013 talvella edellisen vuoden ollessa pitkälti hiljaiseloa kehitystöissä. Suunnitteluprojektin tavoitteeksi asetettiin ”selvittää käyttäjälähtöisesti onko uudistamiselle tarvetta ja millainen mahdollinen uusi versio tulisi olemaan”. Käytännössä projekti vaiheistui seuraavasti:

  • Käyttäjätutkimuksen tekijän rekrytointi ja tutkimuksen suunnittelu
  • Sivuston tavoitteiden, vaatimusten ja käyttäjäryhmien tarkistaminen
  • Käyttäjätutkimuksen toteutus
  • Konseptisuunnittelu ja toiminnallinen määrittely
  • Sivuston käyttöasteen tarkistaminen ja käyttäjäkysely
  • Päätös sivuston uusimisesta

Käyttäjätutkimuksen tekijän rekrytointi ja tutkimuksen suunnittelu

Koska projektin tavoitteena oli tarkistaa nimenomaan käyttäjälähtöisesti olisiko sivuston uudistamiselle tarvetta, piti se väistämättä sisällään käyttäjätutkimuksen. Itse en olisi muilta töiltäni tutkimusta ehtinyt tekemään ja toisaalta projektin budjetti oli rajallinen, joten suunnitelmana oli kääntyä Tampereen korkeakoulujen puoleen ja pyrkiä rekrytoimaan käytettävyyttä opiskeleva lopputyöntekijä projektiin.  Otin yhteyttä Tampereen teknillisen yliopiston ihmiskeskeisen teknologian yksikköön, Tampereen yliopiston informaatiotieteiden yksikköön (vuorovaikutteinen teknologia) ja Tampereen ammattikorkeakouluun asian johdosta. Teknillisen yliopiston vastaus oli käytännössä, että diplomitöitä ei tehdä ilman korvausta joten kääntykää yliopiston puoleen. Yliopistolta löytyikin useita hyviä hakijoita tehtävään ja näiden joukosta valittiin Johannes Pitkänen tutkimusta tekemään.

Suunnittelimme tutkimuksen yhdessä Johanneksen kanssa ja käytännössä siinä tultaisiin kyselyn, haastattelun, käytettävyystestin ja kilpailija-analyysin keinoin vastaamaan seuraaviin kysymyksiin:

  • Minkälaiset käyttäjät käyttävät sivustoa ja miksi?
  • Miksi käyttäjä käyttäisi juuri tätä sivustoa?
  • Mitkä seikat houkuttelevat käyttäjiä?
  • Miksi käyttäjä käyttäisi mieluummin jotain toista sivustoa?
  • Miten käyttäjäkuntaa voidaan laajentaa?

Näiden kysymysten myötä saataisiin muodostettua kokonaiskuva käyttäjien tarpeisiin pohjautuvista perusteluista sivuston uudistamiselle (tai sitä vastaan). Suunnittelun taustamateriaalina käytettiin aikaisemmin tehtyjä kyselytutkimuksia ja tehtäväanalyysiä. Tutkimuksen suunnittelun yhteydessä puntaroitiin myös mahdollisuutta, että Johannekselle olisi tullut työpariksi lääketieteen opiskelija. Toinen suunnittelun yhteydessä keskusteltu idea oli se, että projektin yhteydessä rakennettaisiin ns. käyttäjäverkosto, jonka kautta voitaisiin myöhemmin mm. rekrytoida testihenkilöitä käytettävyystesteihin. Nämä ajatuksen jäivät kuitenkin toteuttamatta, koska tarvittavia resursseja käytäntöön viemiseksi ei ollut.

Sivuston tavoitteiden, vaatimusten ja käyttäjäryhmien tarkistaminen

Käyttäjätutkimuksen suunnittelun rinnalla valmisteltiin ja pidettiin työpaja johon osallistuivat kaikki asianosaiset eri ERVA-alueilta. Työpajan tavoitteena oli tarkistaa ns. liiketoiminnan tavoitteet ja vaatimukset sivustolle sekä sen käyttäjäryhmät ja näiden tehtävät sivustolla. Samalla ideoitaisiin uusia mahdollisia sisältöjä, toiminnallisuuksia ja tapoja markkinoida sivustoa.

Työpajan tuloksena todettiin, että sivuston tavoitteet ja kohderyhmät ovat samat kuin aikaisemmin, mutta ensimmäistä työpaikkaansa hakevat lääketieteen opiskelijat / vastavalmistuneet ja erityis- ja erikoistumiskoulutukseen hakeutuvat lääkärit nostetaan sivuston ensisijaisiksi käyttäjäryhmiksi.

Käyttäjätutkimuksen toteutus

En lähde tässä yksityiskohtaisesti avaamaan käyttäjätutkimuksen sisältöä, koska toiveeni on, että Johannes kirjoittaisi siitä jutun jossain vaiheessa. Seuraavassa kuitenkin tiivistäen:

  • 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.

Tutkimuksen tuloksena voitiin todeta, että sivustolta ei käyttäjien näkökulmasta löydy merkittäviä puutteita sisällöissä tai toiminnallisuuksissa, mutta suurin savotta on sen markkinoinnissa kaikille kohderyhmille.

Tehdyn käyttäjätutkimuksen (ja aikaisempien) pohjalta Johannes kirjoitti kolme käyttäjäpersoonaa (kaksi lääkäreille, yksi terveyskeskuskäyttäjille) konseptisuunnittelun ja mahdollisen tulevan toteutusprojektin tueksi. Käyttäjäpersoonathan ovat siis käyttäjistä kerättyihin tietoihin pohjautuvia käyttäjien arkkityyppejä, joista voi olla hyötyä palvelun tai tuotteen kehityksessä, jos toteutustiimi pystyy niiden avulla paremmin astumaan loppukäyttäjien saappaisiin suunnitteluratkaisuita tehdessään. Ks. lisää käyttäjäpersoonista Wikipediassa.

Konseptisuunnittelu ja toiminnallinen määrittely

Yhdistämällä työpajassa syntyneet ideat nykysivuston toiminnallisuuteen, sivuston olemassaolon aikana kerättyihin kehitysehdotuksiin ja käyttäjätutkimuksen tuloksiin saatiin aikaan ensimmäinen vedos sivuston uudesta versiosta ja sen ominaisuusluettelosta.

Konseptisuunnittelun syötteeksi tehtiin vielä kevyt kilpailija-analyysi vertailemalla eri rekrytointisivustoja keskenään sekä kahlattiin läpi kävijäseurantadataa (tästä aiheesta myöhemmissä jutuissa lisää). Kävijäseurantadatan perusteella noin 15% sivuston kävijöistä käytti selaamiseen mobiililaitetta tai tablettia, joten eri päätelaitteille mukautuva (ns. responsiivinen) käyttöliittymä tuli vaatimukseksi vaikka käyttäjähaastatteluiden perusteella sitä ei tarpeelliseksi tunnistettu. Onkin tärkeää vahvistaa käyttäjien väittämät tarkkailemalla mitä he tekevät.

Suunnittelussa tehtiin kaksi selkeää rajausta. Ensinnäkin sivustolla olevat ammattiryhmät tulisivat olemaan edelleen samat (lääkärit, hammaslääkärit) vaikka joitain toiveita palvelun laajentamisesta muihin ammattiryhmiin oli ajan saatossa esitetty ja aiheesta monta kertaa keskustelu jo ihan nykysivuston ensimmäisestä suunnittelupalaverista lähtien. Tarkka fokus kahteen ammattiryhmään nähdään palvelun etuna ja kilpailutekijänä erottautumisessa muista palveluista. Toinen vastaava rajaus oli se, että palvelussa työnantajina tulisivat edelleen olemaan pelkät terveyskeskukset. Sairaaloiden jne. ottaminen mukaan palveluun veisi huomioarvoa terveyskeskuksista, jossa lääkäreistä ja hammaslääkäreistä on pulaa ja joiden rekrytointihaasteisiin sivusto oli alun alkaen perustettu.

Itse suunnitelma konkretisoitui kahteen artefaktiin: Dokumenttiin nimeltä Toiminnallinen määrittely (plus se ominaisuusluettelo) sekä sivuston julkisen puolen HTML-prototyyppiin.

Kevyt toiminnallinen määrittely piti sisällään sivuston vision, käyttäjien tavoitteet, persoonien näkökulmasta kirjoitetut sivuston tärkeimmät käyttöskenaariot, tietomallin (ks. kuva) ja informaatioarkkitehtuurin. Dokumentin tarkoitus oli siis toimia toteutuksen lähtökohtana ja ohjenuorana, mutta toisaalta myös mahdollistaa sivuston jatkokehitykseen liittyvä päätöksenteko ja toimia mahdollisen kilpailutuksen pohjamateriaalina.

tietomalli

Päätin tehdä sivuston julkipuolen käyttöliittymäsuunnittelun suoraa protoilemalla HTML:ää. Tämähän on ollut viime vuosien kestoaihe www-suunnittelijoiden keskuudessa eli tehdäkö rautalangat ja leiskat perinteisesti vai hypätäänkö suoraa koodaamaan? Otin protoon mukaan jQuery Mobile käyttöliittymäkirjaston, koska muuten aikaa olisi palanut kohtuuttomasti CSS:n koodaamiseen. Ja aikaa paloi silti. Koodaaminen on kokoluokkaa tarkempi suunnittelutyökaluna kuin Photoshop tms. ja kahta tarkempi kuin esim. Balsamiq, joten luonteensa vuoksi nysväämiseksihän se meni (asiaa ei myöskään auta se, että on pedantti ja tehnyt fronttikoodia työksensä). Huomasin myös että JQM:n käyttö rajoitti ajatteluani ja suunnitteluratkaisuja, koska käyttöliittymäkontrolleja on helppo leikata-liimata paikalleen esimerkkien pohjalta, mutta asetettujen reunaehtojen rikkominen on työlästä. Piirtotyökalussa reunaehtoja on merkittävästi vähemmän (lähinnä UI-suunnittelun hyvät käytännöt). Jatkossa tulen piirtämään ensimmäisen iteraation käyttöliittymästä Balsamiqillä ja hyppään vasta sen jälkeen HTML:ään, jos tarve.

Sivuston hallintatyökalun suunnittelu rajattiin projektista ulos varsinaisen toteutusprojektin asiaksi.

Konseptisuunnitelma esiteltiin asianosaisille projektin toisessa työpajassa. Sivuston uudistamisen puolesta puhuivat seuraavat seikat:

  • Lääketieteen opiskelijoiden / vastavalmistuneiden nostaminen tärkeimmäksi kohderyhmäksi ja sisällön uudistaminen heidän tarpeisiinsa.
  • Terveyskeskusten yhteystietojen selkeämpi esitys, terveyskeskusten sekä niiden koulutusvalmiuksien esittelysisällöt.
  • Työpaikkavahdin toteutus.
  • Sijaisuusilmoitusten määrän lisääminen sivustolla ja niiden huomioarvon kasvattaminen.
  • Rakennemuutokset sivuston organisaatiohallintaan, terveyskeskuksella voi olla useita fyysisiä toimipisteitä.
  • Käytettävyysparannukset työpaikkailmoitusten (mm. toistaiseksi voimassa olevat ilmoitukset) ja yhteystietojen julkaisun osalta.
  • Ilmoitusten julkaisu TKrekryyn suoraa Kuntarekrystä ja mahdolliset muut integraatiot.
  • Sivuston visuaalisen ilmeen freesaus (ei niinkään perustelu, mutta kannattaisi tehdä samalla, jos sivusto uusitaan).

Sivuston uudistamista vastaan tunnistettiin seuraavat seikat:

  • Käyttäjätutkimuksen perusteella ei löytynyt merkittäviä sisällöllisiä tai teknisiä puutteita; parannuskohteet liittyvät palvelun tunnettuuteen ja kattavuuteen.
  • Ajankohtaisen sisällön tuottamiseen ei ole resursseja eikä käyttäjien näkökulmasta tarvetta (kunhan terveyskeskusten tiedot ovat kunnossa), joten nykyiset julkaisutyökalut ovat riittävät.
  • Kustannukset ja uudistusprojektista PSHP:lle ja kumppaneille aiheutuva oman toimen ohella tehtävä työ.

Lopullinen päätös sivuston uudistamisesta jäi työpajan jälkeen vielä kypsymään, mutta käytännössä mahdollisia etenemisvaihtoehtoja tunnistetiin neljä erilaista:

  1. Ei tehdä mitään tai ajetaan nykyinen sivusto alas.
  2. Terveyskeskusten esittelysisältöjen toteutus ja muun sisällön stilisointi nykysivustolle.
  3. Kokonaan uuden sivuston hankinta kilpailuttamalla.
  4. Kokonaan uuden sivuston hankinta (karsituin ominaisuuksin) samalla porukalla kuin millä nykysivusto on tehty.

Sivuston käyttöasteen tarkistaminen ja käyttäjäkysely

Osana konseptin viimeistelyä päätettiin suorittaa vielä kyselytutkimus niille terveyskeskuksille, jotka eivät käytä TKrekryä ja pyrkiä selvittämään käyttämättömyyden syitä ja mahdollisia parannuksia joilla käyttöastetta saataisiin nostettua. Sivuston käytöstä kerätyn datan perusteella arviointiin, että 150 terveyskeskuksesta vain 65 kpl (43%) oli jättänyt palveluun ilmoituksen 2013 vuoden aikana. Aihe on siinä mielessä mielenkiintoinen, koska palvelun käyttö terveyskeskuksille on ilmaista (miksi siis olla käyttämättä?).

Kukin ERVA-alue kontaktoi omat passiiviset terveyskeskuksensa 2013 loppuvuoden aikana ja näistä noin puolelta saatiin selkeä vastaus käyttämättömyyteen. Pääasialliset syyt olivat seuraavat:

  • Palvelusta ei tiedetä
  • Käyttö koetaan työlääksi muiden ilmoituskanavien ohella
  • Palvelua ei koeta hyödylliseksi
  • Rekrytointi on ulkoistettu
  • Ei ole avoimia paikkoja joita ilmoittaa
  • Jokin muu syy

Alhainen käyttöaste on iso ongelma, koska käyttäjätutkimuksen mukaan sivuston mahdollisimman laaja kattavuus (ja tunnettuus) olivat lääkäreille tärkeä asia. Toisaalta terveyskeskukset eivät vaivaudu käyttämään palvelua, jos sen kautta ei saa itselle riittävästi näkyvyyttä (kävijöitä, työnhakijoita). Kyseessä on siis perinteinen muna-kana ongelma.

Meneillään olevan uudistusprojektin yksi tavoitteista onkin nostaa käyttöastetta merkittävästi. Kirjoitan käyttöasteesta, tavoitteista ja mittareista lisää blogissa myöhemmin.

Päätös sivuston uusimisesta

Päätös uuden sivuston toteutuksesta (karsituin ominaisuuksin) tehtiin joulukuussa 2013. TKrekryn toimintaa haluttiin jatkaa, mutta nykyisen sivuston jatkokehitys (vaihtoehto 2) katsottiin riittämättömäksi vastaamaan uuteen tahtotilaan. Vaihtoehto 3 puolestaan todettiin potentiaalisesti liian kalliiksi ja työlääksi.

Päädyttiin vaihtoehtoon 4 eli tehdään uusi sivusto, mutta karsituin ominaisuuksin, jotta budjetti saadaan kilpailutusrajan alle. Karsimista pitikin tehdä jos jonkin verran puoleen ja toiseen, mutta nyt projekti on käynnissä ja vauhdissa. Edellisessä jutussa totesin, että jos sivuston kehitys jää ainoastaan sisältöjen, ominaisuuksien ja tekniikan tasolle, niin sivustolle asetettua visiota ei saavuteta. Ikävä kyllä rajalliset resurssit rajoittavat asioiden edistämistä niillä muilla rintamalohkoilla.

Tämän myötä myös tämä kilometrihistoriikki on saatu päätökseen ja seuraavissa jutuissa tulen kirjoittamaan ajankohtaisemmista toteutuksessa vastaan tulleista ja tulevista aiheista.

Sivuston ja sen uudistusprojektin taustaa – osa 1

Tässä jutussa kerrotaan Pirkanmaan sairaanhoitopiirin (PSHP) omistaman TKrekry.fi sivuston ja nyt käynnissä olevan uudistusprojektin taustoista eli siitä miten tähän päivään on tultu. TKrekry on Pirkanmaan sairaanhoitopiirin kehittämä ja ylläpitämä valtakunnallinen terveyskeskuksien käyttöön tarkoitettu lääkärien ja hammaslääkärien rekrytointisivusto. Kyseessä on myös blogin ensimmäinen varsinainen kirjoitus, joten harjoitellaan, harjoitellaan. Juttu on jaettu kahteen osaan. Ensimmäisessä pohditaan nykyisen sivuston taustoja ja tulevassa osassa sivuston uuden version määrittelyä ja suunnittelua.

Nykyisen sivuston toteutus

TKrekry sai alkunsa 2008 syksyllä. Silloinen PSHP:n projektiryhmä oli saanut terveyskeskusten ylilääkärien aloitteesta Tampereen Lääkäripäivien kohdeapurahan. Projektiryhmälle oli syntynyt ajatus siitä, että apuraha tulisi hyödyntää jotenkin terveyskeskusten lääkäripulan ja rekrytoinnin helpottamiseksi ja verkkosivuston toteutus aiheen tiimoilta voisi tuoda eniten vastinetta rahalle.

Lääkäripula

Niin nykyään, kuin silloin viisi ja puoli vuotta sitten, terveyskeskuksilla on haasteita saada riittävästi pätevää henkilöstöä palkatuksi (etenkin pienillä paikkakunnilla). Tämä koskee erityisesti lääkäreitä ja hammaslääkäreitä, joilla on usein mahdollisuudet kilpailuttaa palkkansa ja työsuhde-etunsa. Yksityisellä sektorilla on myös merkittävä rooli terveyskeskusten henkilöstöpulassa, joilla ei ole vastaavaa markkinointi- ja rekrytointibudjettia käytössään.  Usein lääketieteen opiskelijat rekrytoidaan ”suoraa koulun penkiltä” töihin yksityiselle. Voidaan kai puhua ns. lääkäripulasta.

Näin käytettävyysasiantuntijan näkökulmasta on mielenkiintoista lukea Suomen Lääkäriliiton työvoimapoliittista ohjelmaa, jossa arvioidaan, että ”600 lääkärin työpanos menee hukkaan toimimattomien tietojärjestelmien vuoksi”. Jälkikäteen on helppo viisastella ja kallista korjata, mutta tällä saralla olisi merkittävästi savottaa mitä tulee käyttäjien tavoitteiden ja tehtävien ymmärtämiseen, riittävän käytettävyyden ja teknisen laadun varmistukseen sekä ketteriin toimituksiin. Toivottavasti Apotissa ei toisteta menneisyyden virheitä.

Takaisin aiheeseen.

Päädyin konsultoimaan projektiryhmää sivuston suunnittelussa ja toteutuksessa ja parin ensimmäisen tapaamisen aikana sen alustava tavoite, käyttäjät, kilpailijat, sisällöt ja toiminnallisuudet alkoivat hahmottua. 10.10.2008 päivätyssä palaverimuistiossa on todettu seuraavaa:

Projektissa suunnitellaan ja toteutetaan rekrytointisivusto tkrekry.fi jonka tavoitteena on kertoa millaista työskentely terveyskeskuksissa julkisen työnantajan palkkaamana on sekä ilmoittaa terveyskeskusten avoimista työpaikoista Pirkanmaalla. Myöhemmässä vaiheessa verkkopalvelu voi kattaa ERVA-alueen muut terveyskeskukset tai jopa koko valtakunnan julkisen terveydenhuollon avoimet työpaikat.  Sivuston sisällön ylläpidon ja työpaikkojen ilmoittamisen tulee onnistua ilman teknistä osaamista.

Myöhemmin samainen asia kiteytyi seuraavaan muotoon:


TKrekry on verkkosivusto, jonka tavoitteena on tukea ja tehostaa lääkärien ja hammaslääkärien rekrytointia terveyskeskuksiin:

  • Kertomalla mitä työskentely terveyskeskuksessa on ja mistä terveyskeskuksen palkkalistoilla olevan lääkärin tai hammaslääkärin palkka muodostuu.
  • Ilmoittamalla terveyskeskusten avoimista työpaikoista (ainoastaan lääkärit ja hammaslääkärit tässä vaiheessa).
  • Tekemällä yhteydenoton terveyskeskuksen rekrytoinnista vastaaviin henkilöihin mahdollisimman helpoksi.

Visio: TKrekry on ensimmäinen ja tärkein tiedonlähde jokaiselle uutta työpaikkaa hakevalle lääkärille tai hammaslääkärille. TKrekry palvelee sekä terveyskeskusten, että työnhakijoiden tarpeita olemalla selkeän informatiivinen ja käytettävä verkkopalvelu.

Sivuston mahdollisiksi käyttäjiksi tunnistettiin seuraavat ryhmät, mutta näiden tavoitteita, tarpeita tai tehtäviä ei projektissa tutkittu:

  1. Työpaikkaa hakevat lääkärit ja hammaslääkärit
  2. Hoitohenkilökunta
  3. Erityishenkilöstö (esim. puheterapeutit, psykologit yms)
  4. Työpaikkailmoituksia hallinnoivat ihmiset terveyskeskuksissa
  5. PSHP:n Yleislääketieteen vastuunalueen (silloinen YLVA) määrittämä ylläpitäjä

Sivuston toteutuksesta sovittiin silloisen ja sittemmin edesmenneen BF Engineeringin kanssa, jonka kautta allekirjoittanut myös työllisti itsensä projektin suunnittelijaksi ja projektipäälliköksi. Projekti toteutettiin perinteiseen tapaan ilman sen erityisempiä haasteita tai oivalluksia:

  1. Tavoitteiden ja käyttäjien määrittely.
  2. Informaatioarkkitehtuurin ja sisältöjen suunnittelu.
  3. Toiminnallinen määrittely.
  4. Tekninen suunnittelu eli käytännössä julkaisujärjestelmän (Radiant CMS, tästä myöhemmin lisää) valinta.
  5. Käyttöliittymäsuunnittelu.
  6. Sisällöntuotanto.
  7. Tekninen toteutus ja sivuston koostaminen.
  8. Hyväksyntätestaus.
  9. Käyttäjien koulutus.
  10. Julkaisu.

Tai no yksi haaste tulee mieleen. Sivuston tuotantoympäristö. Alustava suunnitelma oli hostata (suomeksi isännöidä?) sivusto Sigmaticillä, koska palveluntarjoajasta oli aikaisempaa kokemusta. Sivuston julkaisujärjestelmä ja siihen sivustoa varten tehdyt laajennokset toteutettiin Ruby on Railsilla. Tuolloin Rails 2 oli kuuminta hottia, mutta Suomessa vielä kohtalaisen uusi tuttavuus. Syystä tahi toisesta (versiot, riippuvuudet jne.) sivustoa ei saatu toimimaan Sigmaticin webhotellissa, joten se päätettiin hostata Herokussa. Tätä päätöstä ei ole tarvinnut katua hetkeäkään.

Sivusto julkaistiin viimeisten viilauksien ja PSHP:n terveyskeskusten käyttäjien koulutusten jälkeen helmikuussa 2009 Tampereen yliopiston lääketieteen opiskelijoille pidetyssä rekrytointitilaisuudessa.

Nykyisen sivuston jatkokehitys

Keväällä 2009 allekirjoittanut teki kevyen käyttäjätutkimuksen tehtäväanalyysin muodossa sivuston terveyskeskuskäyttäjien rekrytointiprosesseista. Tutkimus oli osa Tampereen teknillisen yliopiston vastaavaan kurssin suoritteita.

Kesän 2009 aikana sivustoon tehtiin jatkokehitystä sen käytön laajentamiseksi koko valtakuntaan. Esim. sisällöt käännettiin ruotsiksi. Syksyllä koulutukset ja käyttö laajenivat koko TAYS:n alueelle ja vuoden 2010 aikana myös muille ERVA-alueille eli koko maan terveyskeskusten käyttöön.

2010 ja 2011 sivuston eri käyttäjiltä kyseltiin niin paperilla kuin sähköisesti asioita sivuston käytöstä ja kokemuksista, mutta näissä kyselyissä vastausprosentti jäi pieneksi eikä saaduista vastauksista saatu toivottua syötettä sivuston jatkokehitykseen. 2011 sivustolle toteutettiin myös työpaikkailmoitusten julkaisu TKrekryn Facebook-sivulle.

2012 lähinnä jahkailtiin jatkokehityksen suhteen ja 2013 talvella ryhdyttiin verkkaisesti hommiin.

TKrekryn kehitys kokonaisuutena voidaan jakaa seuraaviin ylätason aiheisiin, joita kaikkia pitäisi ideaalimaailmassa suunnitelmallisesti edistää ja kehittää:

  1. Tuote / tekniikka eli sivuston ominaisuudet, toiminnot, visuaalinen ilme, vakiosisällöt jne.
  2. Sivuston tunnettuus ja kattavuus (käytössä kaikissa terveyskeskuksissa) eli markkinointi ja siihen liittyvä verkostoituminen sekä ajankohtaisen ja vaihtuvan sisällön tuotanto ja sisällöntuotantoprosessi.
  3. Terveyskeskusten tuottamien työpaikkailmoitusten ja muun sisällön sekä itse rekryprosessien kehittäminen / valmentaminen.

Kunnianhimo ja käytössä olevat resurssit ja raha määrittävät sen kuinka laajalti näitä aiheita voidaan edistää. Mielestäni vaarana on, että jos / kun kehityksessä jäädään ensimmäiselle tasolle, niin sivuston tavoitteisiin ei päästä eikä visiota saavuteta. Haaste, jota lähdetään ratkaisemaan verkkosivustolla, on harvoin ratkaistavissa pelkästään toteuttamalla ko. sivusto. Monen muunkin asian on muututtava, oli kyse sitten organisaatiosta, prosesseista, viestinnästä jne. jotta ideaalitulokseen tai edes lähelle päästäisiin.

Kirjoitan tästä kehitystyöstä eli sivuston uuden version suunnittelusta lisää jutun toisessa osassa.

Blogin tulevia aiheita

Ilmeisesti blogaajan pitää aloittaessaan laatia itselleen lista aiheista, joista myöhemmin kirjoittaa, joten tässä omani:

Jos siis nämä aiheet kiinnostavat, niin laita blogin linkki talteen, tilaa RSS-syöte tms. millä sitten seuraatkaan blogeja.

Toivoisin kovasti myös kommentteja, mielipiteitä, kritiikkiä tai ihmisten omia kokemuksia web-projekteista kommentteihin. Jakamalla kokemuksia meistä toivottavasti tulee parempia, joten osallistu keskusteluun!