Mikä mahtaa olla käytettävyystestien laatu Suomessa?

Jatkona edelliseen: Ralf Molich kirjoitti sähköpostissaan seuraavan kokemuksensa (lupasi, että saan julkaista sen blogissani):

"During the past 1-2 years I have been asked to carry out QA checks on 7 usability test providers. QA checks were ordered by clients who wanted uniform and state-of-the art usability tests across countries, including countries whose language they did not understand. They also wanted to be sure that they got what they paid for so they could safely make important decisions based on the usability test results. Needless  to say, almost all the people involved in these tests had impressive portfolios and exams from renowned universities.



The findings were, eh, interesting. Only one utest provider passed without serious notes. Six of seven got one or more serious or critical notes on their adherence to standard procedures for usability testing."

Eli Molichin havainto on, että käytettävyystestien tekemisen laatu on kyseenalaista. Vaikka niiden tekijöillä on meriittejä.

Minulla on tullut se käsitys, että tilanne Suomessa ei ehkä ole sen kummempi. Sen perusteella, mitä olen kuullut kentältä ja mitä käytettävyysraportteja olen itse joskus nähnyt.

Vai mitä kokemuksia on itse kullakin?

Käytettävyyttä ei vaadita kilpailutuksissa

Oulun yliopistossa vasta tehdyssä tutkimuksessa käytiin läpi julkisia tietojärjestelmien tarjouspyyntöjä, kaikkiaan 38 kappaletta. Tuloksena oli, että useassa tarjouspyynnössä kyllä yritettiin vaatia käytettävyyttä: 29 tarjouspyynnössä käytettävyys oli esillä vaatimuksena jollakin tavalla.  Kuitenkaan ei löytynyt yhtään tarjouspyyntöä, jossa olisi aidosti vaadittu käytettävyyttä. http://www.yourhost.is/images/stories/NordiCHI2010/accepted/281.html

Mitä tarkoittaa aito käytettävyysvaatimus? Sen olisi aluksikin oltava muodollisesti vaatimus. Lisäksi sen tulisi sisällöllisesti määrittää sovelluksen järkevää käytettävyyttä. Tarkemmin sanottuna:

• Vaatimusten tulisi olla todennettavia: vaatimuksen täyttyminen tulisi pystyä tarkistamaan niin, että ei ole erimielisyyksiä vaatimuksen toteutumisesta.
• Vaatimusten tulisi olla valideja: vaatimus on sisällöltään oikea (= vaatimusten toteutuminen tarkoittaa oikeasti käytettävyyttä)
• Lisäksi vaatimusten tulisi olla kattavat: niiden tulisi määrittää järjestelmän käytettävyys riittävästi eri näkökulmista

Nämä ehdot täyttäviä  vaatimuksia ei löytynyt läpikäydyissä tarjouspyynnöissä. Eikä ole löytynyt sen jälkeenkään - olen pyrkinyt seuraamaan säännöllisesti uusia tarjouspyyntöjä.

Aitojen käytettävyysvaatimusten määrittäminen on oikeasti haastavaa. Seuraavissa postauksissa käyn läpi asiaa esimerkkien kautta.

Muutoshallinta: käytettävyysongelmien vastuun vierityksen kulminaatiopiste

Tyypillisessä asiakaskohtaisen järjestelmän kehitysprosessissa tapahtuu seuraavaa (kuva):

1. Toimittaja (käyttöliittymäsuunnittelija) suunnittelee käyttöliittymäratkaisuja (rautalankamalleja ym), perustuen vaatimusmäärittelyihin ja muihin asiakkaalta saamiin tietoihin
2. Toimittajan ehdotus käydään läpi projektin ohjausryhmässä tai vastaavassa, jossa suunnitelma hyväksytään. Toimittaja voi suostua pieniin muutosehdotuksiin, mutta ei isoihin. 
3. Tämän jälkeen suunnitteluratkaisu laitetaan muutoshallintaan. Käytännössä tämä tarkoittaa sitä, että jos käyttöliittymää halutaan muuttaa, se tarkoittaa lisätilausta. 

Tässäpä sitä ollaan. Kun asiakas hyväksyy suunnitelman, niin samalla tapahtuu vastuun siirto käyttöliittymän laadusta asiakkaalle. Käyttöliittymän laitto muutoshallintaan on helpotus toimittajalle, mutta tarkoittaa haasteita asiakkaalle, jos käyttöliittymä ei toimikaan.

Toisella tavalla sanottuna: Voidaan puhua asiakas- ja käyttäjälähtöisyydestä. Sitä se onkin tietenkin jossain määrin. Mutta käytännössä oleellista on vastuun siirtäminen asiakkaalle.

Se dramaattinen ero: käytettävyys hankinnoissa vs. tuotekehityksessä

Käytettävyyden varmistus hankinnoissa ja tuotekehityksessä eroaa draamaattisesti toisistaan. Tässä en kuitenkaan tarkoita käytettävyyden varmistuksen perusasioista: menetelmiä ja prosesseja. Vaan vastuun jakoa: kuka maksaa, jos käytettävyys menee pieleen?

Tuotekehityksessä vastuun käytettävyydestä kantaa yritys itse ("suunnittelija"). Jos käytettävyys ei pelitä, niin se näkyy yrityksen menestyksessä. Rahat menevät kilpailijoille (kuvan yläosa). Hyvä esimerkki tästä Nokian "käytettävyyskohtalo".

Hankinnoissa vastuu käytettävyysongelmista on kuitenkin ASIAKKAALLA - eikä suunnittelijalla (täysin epäloogista näin entisen tuotekehittelijän taustalta - kesti aikansa ennenkuin sen opin). Mutta näin se on: jos halutaan korjata toimittajan suunnitteleman käyttöliittymän ongelmia, niin se tarkoittaa asiakkaan tekemää lisätilausta toimittajalle. Eli raha siirtyy täysin päinvastoin kuin tuotekehityksessä. Kuvan alaosa.

Hankinnoissa käytettävyysongelmat jäävät asiakkaan harmiksi. Ja jos niitä korjataan, se tarkoittaa lisäkustannuksia asiakkaalle. Ja lisäbisnestä toimittajalle - käyttöliittymän suunnittelijalle.

Seuraavassa postauksessa tarkastelen vähän tarkemmin tätä mekanismia.

Onko tämä dialogi? Tyypillinen esimerkki julkisen järjestelmän käytettävyysongelmasta

Esimerkkejä "epäkäytettävyyden" kukkasista on vaikka kuinka. Tässä valitsen vasta eteeni tulleen esimerkin. 

Tuli oikein aito perinteinen posti Valtiokonttorilta, jossa kehotetaan siirtymään verkkolaskutukseen ja annetaan toistaiseksi voimassa oleva ilmainen palvelu.

Ei liene yllätys, että homma ei onnistunut - ainakaan minulta. Tällä hetkellä on selvityksen alla, että onko kyseessä tekninen ongelma vai mikä.

Joka tapauksessa, rekisteröitymislomakkeessa on mielenkiintoinen kenttä, joka ei näytä yhtään dialogilta (rengastettu kuvassa). Kuitenkin se on merkitty punaisella tähdellä, eli pakollinen täyttää.

Miten sinä tulkitsisit tuon kentän? (vihje: kyllä se on dialogi...)

- Mutta pointti on että vastuu tällaisista käytettävyysongelmista on tietojärjestelmän hankkijalla, ei toimittajalla.  Tämä onkin koko tämän blogin keskeinen perussanoma: miten hankkija voi aidosti toimia käytettävyyden varmistamiseksi (ilman että jää tällaisia ongelmia, tai että tilaa korjauksia kalliilla muutostilauksilla)

Käytettävyyden varmistus ei ole rutiinia

Käytettävyyden varmistus ei ole rutiinia. Käytettävyyttä ei varmisteta käyttäjäkeskeisillä prosesseilla tai menetelmillä: ei käytettävyystestauksella, käyttäjätutkimuksilla, käyttötapausmäärittelyillä, käytettävyysohjeistoilla.

Asiaa on tutkittu tieteellisesti, esimerkiksi Rolf Molichin vetämät CUE -tutkimukset: http://www.dialogdesign.dk/CUE.html

Esimerkiksi voi mielestäni ottaa vaikka tapaus Nokian. Nokia on aktiivinen käytettävyys- ja käyttäjäkokemuskentällä: mukana alan konferensseissa, yrityksessä on alan tunnettuja asiantuntijoita, useita alan tohtoreita, yrityksessä on sovellettu ja kehitetty käytettävyysalan menetelmiä. Siltikin Nokian "käyttöliittymäkohtalo" oli mitä oli (miksi näin - se ei ole tämän kirjoituksen aihe).

Käyttäjäkeskeisyyttä, käytettävyysprosesseja ja menetelmiä vaatimalla ei varmisteta käytettävyyttä. Se, miten käytettävyyden varmistusta voi tehdä ja erityisesti tietojärjestelmien hankinnoissa, on tämän blogin aihe.

Käytettävyystyö ei ole rutiinia

Käytettävyystyö ei ole rutiinia. Käytettävyyttä ei varmisteta käyttäjäkeskeisillä prosesseilla tai menetelmillä: ei käytettävyystestauksella, käyttäjätutkimuksilla, käyttötapausmäärittelyillä, käytettävyysohjeistoilla.

Asiaa on tutkittu tieteellisesti Rolf Molichin vetämissä CUE -tutkimukset: http://www.dialogdesign.dk/CUE.html. Yksi tulos vaikkapa se, että kun yhdeksän (9) käytettävyystestiryhmää testasi samaa kohdetta, niin 75% raportoiduista ongelmista löysi vain yksi ryhmä.

Voidaan ajatella ja usein sanotaankin, että käytettävyys on nuorehko ja ei vielä kyspä tieteen ala. Ja sitä kautta nähdään selitys tällaisille tutkimustuloksille.

Itse kuitenkin olen taipuvainen ajattelemaan, että pointti on se, että käytettävyys on olennaisesti "älytyötä". Käytettävyystyöhön liittyy vain vähän rutiiniasioita. Näitä ovat ehkä sellaiset kuin käyttäjien rekrytointi, käytettävyystestien logistiset järjestelyt ja perusrutiinit.

Mutta käytettävyyden varsinaisen substanssin laatua eivät mitkään menetelmät takaa. Molichin tutkimuksessa todettiin, että käytettävyystestien tulokset olivat ihan erilaiset riippuen siitä kuka testejä sattui tekemään. Väitän, että vielä suurempi hajonta on tilanteessa, jossa pitäisi valita sopivia käytettävyystoimenpiteitä tiettyyn projektikontekstiin. Ja erityisesti väitän, että aivan liian yleisesti valitaan "oikeaksi" toimenpiteeksi käytettävyystestaus.

Käyttäjäkokemus: määritelmä

ISO 9241-210 sisältää käyttäjäkokemuksen määritelmän:
(alustava suomennos)

"Henkilön havainnot ja vasteet, jotka ovat seurausta tuotteen, järjestelmän tai palvelun käytöstä ja/tai ennakoidusta käytöstä".

Tätä tarkennetaan seuraavilla huomatuksilla:

"HUOM. 1 Käyttäjäkokemus sisältää kaikki käyttäjien tunteet, uskomukset, mieltymykset, fyysiset ja psyykkiset vasteet, käyttäytymiset ja aikaansaannokset, jotka ilmenevät ennen käyttöä, käytön aikana ja käytön jälkeen.
HUOM. 2 Käyttäjäkokemus on seurausta tuotemerkin imagosta, ulkonäöstä, toiminnallisuudesta, järjestelmän suorituskyvystä, järjestelmän vuorovaikutuskäyttäytymisestä ja avustavista ominaisuuksista, käyttäjän aiemmasta kokemuksesta johtuvasta sisäisestä ja psyykkisestä tilasta, asenteista, taidoista, persoonallisuudesta sekä käyttötilanteesta.
HUOM. 3 Käytettävyys käyttäjien henkilökohtaisten tavoitteiden näkökulmasta tulkittuna voi sisältää sen tyyppisiä aisti- ja tunnenäkökulmia, joita tyypillisesti liitetään käyttäjäkokemukseen. Käytettävyyskriteereitä voidaan käyttää arvioimaan käyttäjäkokemuksen joitakin näkökulmia."

Kommentti: Vaikka itse olin mukana luomassa tätä määritelmää, niin jälkikäteen ajateltuna se ei ehkä ole paras mahdollinen.

Hyvä määritelmähän on sellainen, että määritelmän sisältö vastaa semanttisesti termiä. Nyt "käyttäjäkokemus" on terminä subjektiivinen ("kokemus"), kun taas HUOM. 1:n mukaan käyttäjäkokemukseen kuuluu myös objektiivisia asioita ("aikaansaannokset). Olisi semanttisesti loogisempaa, jos käyttäjäkokemus määriteltäisiin puhtaasti käyttäjän subjektiiviseksi kokemukseksi.

käännös tulossa

Otinpa sitten hommaksi standardin kääntämisen. Valmistunee kevään 2011 aikana.

Käännöksestä keskustellaan ainakin jonkin verran sivuilla www.facebook.com/kaytettavyyskirja. Ja myös KäytettävyysOSY:n LinkedInin sivuilla

Oma vastaukseni ISO 9241-210 puutteisiin...

ks. www.kaytettavyyskirja.net, www.facebook.com/kaytettavyyskirja