Esimerkki käytettävyysvaatimuksesta, joka ei toimi

Kun tämä vaatimus osui silmään ja liittyy aiempaan keskusteluaiheeseen, niin piti vielä laittaa tämä viesti ennen pikku lomalle lähtöä

Tässä tarjouspyynnössä pisteytetään toimittajan tarjousta "käytettävyyden kehittämisen menetelmien ja prosessien" perusteella.

Tässä on siis aluksikin se ongelma, että prosessit eivät takaa käytettävyyttä.

Mutta toinen ja mielenkiintoisempi ongelma on se, että vaatimuksessa ei määritellä, millä kriteereillä pisteytys tehdään. Miten pisteyttää "käytettävyyden kehittämisen menetelmät ja prosessit"? Kuka on tällaiseen arviointiin pätevä, ja mihin malliin perustuen tällainen arviointi tehdään?

Ajatellaan, että toimittajalla on käytettävyysammattilainen, joka kuvaa käytettävyysprosessin. Ja sitten tilaajan käyttämä käytettävyysammattilainen arvioi suunnitelman, ja näkee siinä puutteita. Kysymys on, että millä perusteella tilaajan käytettävyysammattilaisen arviointi on pätevä? Eikö yhtä hyvin voikin olla niin, että toimittajan suunnitelma onkin hyvä, mutta tilaajan ammattilainen tekikin väärän arvion?

Itse olen tehnyt tällaisia arviointeja, ja mielestäni pystyn tekemään perusteltuja arviointeja jopa useammalla menetelmällä (kun olen aiheesta väitellyt). Mutta samalla totean, että joku toinen voi asettaa tekemäni arvioinnin kiistanalaiseksi (tai ainakin yrittää...;).  Tai sitten toisinpäin. Joka tapauksessa, kovin ongelmallinen tarjouspyynnön arviointikriteeri.

Ja itse asiassa kolmas ongelma: valituksi voi tulla toimittaja, jolla ei ole minkään tasoisia käytettävyysprosesseja (jos saa muista kriteereistä paljon pisteitä).

Käyttäjälähtöisyyden vaatiminen ei takaa käytettävyyttä

Edellisen kirjoituksen kommentissa kerrottiin tarjouspyynnöstä, jossa edellytettiin: "....toimittajan tuli suunnitella käyttäjälähtöisesti..."

Kuitenkaan tällaiset prosessivaatimukset - vaaditaan toimittajalta käyttäjälähtöistä suunnittelua, käytettävyystestausta jne. - eivät ole valideja käytettävyysvaatimuksia. Niillä ei periaatteessa taata minkään tason käytettävyyttä. 

Prosessivaatimukset voi täyttää, vaikka tulosten laatu on mitä sattuu. Ne eivät erottele toimittajan kykyä tuottaa laatua. Toki laatua voi toteutua, mutta yhtä hyvin se voi jäädä toteutumatta.  Prosessivaatimuksilla taataan käytännössä ainoastaan se, että jotain tehdään (ja lisäkustannuksia asiakkaalle).

Prosessivaatimukset voisivat toimia, jos käytettävyystyö olisi mekaanista "tuotantotyötä". Mutta kun käytettävyystyö ei ole tällaista. Käytettävyystyö on "älytyötä", ja sen tulosten laatu riippuu tismalleen siitä, kuka sattuu tekemään noita prosesseja. Tutkimusten mukaan edes tunnettujen toimistojen tulokset ole välttämättä kummoisia:  http://kaytettavyysnavigoija.blogspot.com/2011/04/kaytettavyyden-varmistus-ei-ole.html 

Sitten on ihan eri asia, että käytettävyyden aikaansaamiseksi käytännössä tarvitaan systematiikkaa ja prosesseja. Mutta syy-seuraus -suhteet siis eivät mene niin, että systematiikalla ja prosesseilla (tai menetelmillä) taattaisiin mitään. 

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ä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ä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 blogin 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.