Erään osallistumispyynnön käytettävyysanatomia

Aalto-yliopiston tutkimustietojärjestelmän (CRIS) hankintailmoituksessa käytettävyys on merkittävästi esillä. Hyvänä piirteenä esimerkiksi se, että käyttäjät ovat testikäyttäjinä eivätkä esimerkiksi arvioijina (käyttäjäraadit), mikä on usein käytetty mutta epävalidi tapa. Suurin ongelma on se, että vertailevat käytettävyystestit tehdään demoilla,  jolloin laadukkaastikin tehdyt testit voivat tuottaa vääriä tuloksia. Kirjoituksessa arvioidaan lisäksi pakollisten vaatimusten ja vertailukriteerien määrittämistä sekä piirteitä käytettävyystesteistä. 

Kaikkiaan hankinnassa käytetty menettelytapa ei takaa sitä, että hankittava järjestelmä olisi aidosti hyvä käytettävyydeltään  (mikä mielestäni pitäisi olla hankinnan käytettävyysosion ehdoton tavoite). 

------------------------

(Kirjoitin ja julkaisin tämän artikkelin jo vuosi sitten, mutta vedin pois sen, että se ei häiritsisi hankintaprosessia). 

Aalto yliopisto julkaisi alkuvuodesta 2014 hankintailmoituksen tutkimustietojärjestelmästä ("CRIS"). Järjestelmän tarkoitus on se, että tutkijat raportoivat tieteellisiä tuloksiaan (julkaisuja, tutkimusvierailuja, esityksiä jne.) kyseiseen järjestelmään. Toisaalta järjestelmän kautta esimiehet voivat seurata, mitä tuloksia tutkijat saavat aikaiseksi. 

Hankintailmoitus on muodoltaan osallistumispyyntö: siinä haetaan potentiaalisia toimittajia neuvottelumenettelyyn, joille sitten lopullinen tarjouspyyntö toimitetaan myöhemmin. Siis varsinaista tarjouspyyntöä ei ollut julkisesti saatavilla. 

Hankintailmoituksessa on kuitenkin määritelty varsin seikkaperäisesti, miten käytettävyys aiotaan ottaa huomioon hankinnassa: miten se tulee näkymään tarjouspyynnön pakollisissa vaatimuksissa ja vertailukriteereissä, mitä ovat käytetyt mittarit ja miten mittaukset on tarkoitus suorittaa. 

Tässä kirjoituksessa arvioin hankintailmoituksessa määriteltyjä käytettävyyslähestymistapoja.  

Tätä arviointia saa mielellään haastaa ja kommentoida. Erityisesti esitän tämän kutsun FlowIT:n porukalle. 

(Hankintailmoitus on ollut saatavilla pyynnöstä Aalto-yliopistolta. Itse sen tietenkin pyysin ja se on minulla, mutta en ole vielä varma, miten blogin lukijat sen voisivat saada. Ehkä tätä kirjoitusta voi jotenkin seurata, vaikka alkuperäistä osallistumispyyntöä ei olisikaan käsillä.)

Hankintailmoituksen käytettävyyssisältö

Hankintailmoituksen käytettävyysosio on aika seikkaperäinen, ja hieman monimutkainen. Ennen tarkempaa analyysia, yleiskatsaus hankintailmoituksen käytettävyysideaan: 

• Käytettävyys on tarkoitus arvioida osana valintaprosessia tekemällä käytettävyystestejä toimittajien antamilla demojärjestelmillä. 
• Testikäyttäjiä on kahdesta käyttäjäryhmästä (tutkijat, tutkimuspäälliköt), kumpiakin kuusi (6) kappaletta. Kaikki testikäyttäjät tekevät tehtävät useammalla järjestelmällä siten, että suoritusjärjestys vaihtelee. 
• Käyttäjätehtäviä on viisi (5) kappaletta, joille kullekin on annettu aikaa 15 minuuttia. (Tulkitsen, että lähtökohtaoletus on se, että periaatteessa käyttäjien pitäisi kohtuudella suoriutua tehtävistä tässä ajassa). 
• Käytettävyystesteissä mitataan käyttäjien suoriutumista tuloksellisuudella (effectiveness), tehokkuudella (efficiency) sekä käyttäjätyytyväisyydellä (satisfaction). On määritelty kaavat, miten näitä kutakin mitataan. 

Käytettävyys pakollisissa vaatimuksissa

Ensimmäinen kiinnostava asia on se, missä määrin käytettävyys on pakollinen vaatimus. Ja tässä osallistumisilmoituksessa käytettävyys löytyy pakollisista vaatimuksista.  

Pakollisia käytettävyysvaatimuksia ovat: 

• tuloksellisuus (effectiveness): määritellään "kokonaistuloksellisuuden" (total effectiveness) kautta. Kokonaistuloksellisuus on käyttäjien onnistuneesti suorittamien tehtävien lukumäärä suhteessa kaikkiin annettuihin tehtäviin, ja sen minimirajaksi on asetettu 0,7. 
• käyttäjätyytyväisyys (satisfaction): vähintään 30 pistettä (maksimi 50), kun käytetään positiivisen SUS-kyselyn kysymyksiä 

Käytettävyys vertailukriteereissä

Hankintailmoituksessa käytettävyys on vertailukriteereissä siten, että 

• tehokkuudella (efficiency) on 10 % painoarvo 
• käyttäjätyytyväisyydellä (satisfaction) 20 % painoarvo

(näiden tarkemmasta laskemisesta myöhemmin)

Hankintailmoituksen käytettävyysosioiden analyysi

Analysoin hankintailmoituksen käytettävyysosiota kahdessa vaiheessa: 

• Analyysivaihe 1: Perustelen, miksi käytettävyyden arviointi esitetyllä tavalla on lähtökohtaisestikin ongelmallinen. Tavallaan sen vuoksi toinen arviointivaihe ei periaatteessa ole relevantti
• Analyysivaihe 2: Arvioin kuitenkin - vaikka lähtökohta on ongelmallinen - hankintailmoituksen käytettävyyselementtejä tarkemmin, koska niissä on myös paljon hyvää ja sinällään ovat mielenkiintoisia.

Analyysivaihe 1

Lyhyesti sanottuna käytettävyysosion iso ongelma on se, että vertailevat käytettävyystestit tehdään demoilla. 

Miksi vertailevat käytettävyystestit demoilla on ongelma? 

• Arvioinnin kohteena on järjestelmä, joka ei oteta sellaisenaan käyttöön vaan sovitetaan (konfiguroidaan tms.) Aalto-yliopiston ympäristöön. Oleellista tietenkin on, että lopullinen järjestelmä olisi sitten käytettävyydeltään hyvä.  
• Oleellista siis on, että tarjottu järjestelmä on sellainen, joka antaa mahdollisuuden käytettävyydeltään hyvään asiakaskohtaiseen sovitukseen, ts. mikä on "järjestelmän käytettävyyskyvykkyys". 
• Nyt arviointi tehdään demoilla, joka ei mittaa tuota kyvykkyyttä vaan sitä, millaisen demon toimittaja on saanut aikaiseksi. Arviointi mittaa siis demon eikä lopulliseen järjestelmän käytettävyyttä.  
• Käytettävyystesteissä käyttäjien suoriutumiseen voi vaikuttaa ratkaisevasti pienetkin suunnitteluratkaisut (niin kuin Jacob Nielsen sanoo: "Details matter"). Sen vuoksi demoilla tehtävät käytettävyystestit voivat antaa vääriä tuloksia. Esimerkiksi jo yksi väärä termi - jonka voisi helposti muuttaa lopulliseen järjestelmään - voi ratkaisevasti "tuhota" käyttäjän suoriutumisen.

Eli oikea ratkaisu olisi arvioida järjestelmän käytettävyyskyvykkyyttä, eikä demoa. (Miten käytettävyyskyvykkyyden arviointi tehdään on oma haastava asiansa eikä tämän kirjoituksen aihe). 

Vielä toisella tavalla sanottuna: jos hankittava kohde olisi täysin valmisjärjestelmä, johon käyttöönotossa ei tehdä mitään asiakaskohtaisia sovituksia, niin silloin tällainen käytettävyystestauslähestymistapa olisi validi. 

Yhteenveto. Vaikka käytettävyystestit tehtäisiin kuinka oikein, niin se, että testaukset tehdään demoilla tarkoittaa sitä, että tulokset voivat olla epävalideja. Eli tämä yksittäinen asia tekee koko hankintailmoituksen käytettävyysosiosta ratkaisevasti epävalidin (= potentiaalisesti vääriä tuloksia antavan). 

Huom! Laadulliset käytettävyystestit demoilla ovat (tietenkin) käytettävyystyön peruskauraa.

Analyysivaihe 2

Käyn kuitenkin läpi käytettävyysosiota tarkemmin, koska se on tehty selvästi harkiten ja huolellisesti. Siinä on sekä hyviä piirteitä että myös ongelmia.  

Huom!  Sanon vielä, että tätä analyysiosiota "2" pitää siis lukea siten, että kommentit ovat valideja ainoastaan tapauksessa, jos käytettävyystestit tehtäisiin lopullisella järjestelmällä. Jos testit tehdään demojärjestelmällä, niin - kuten yllä totesin - testit voivat tuottaa epävalideja tuloksia, vaikka ne tehtäisiin kuinka oikein. 

Käytettävyys pakollisissa vaatimuksissa

Käytettävyys on osana pakollisia vaatimuksia, ja se on hyvä asia. Pakollisissa vaatimuksissa käytettävyyden attribuutteja ovat tuloksellisuus ja käyttäjätyytyväisyys, jotka ovat hyviä perusattribuutteja. 

Pakollisten käytettävyysvaatimusten pitäisi olla sellaiset, että kun järjestelmä täyttää ne, niin sen pitäisi olla riittävän hyvä.

Nyt pakolliseksi - eli riittävän hyvän - käytettävyyden tasoksi on asetettu:

• Tuloksellisuus: määritellään mittarin "kokonaistuloksellisuuden" (total effectiveness) kautta. Kokonaistuloksellisuus on kaikkien käyttäjien onnistuneesti suorittamien tehtävien lukumäärä suhteessa kaikkiin annettuihin tehtäviin, ja pakolliseksi vaatimukseksi on asetettu vähintään 0,7. Eli käyttäjien pitää onnistua 70 % tehtävistään. 
• Käyttäjätyytyväisyys (satisfaction): vähintään 30 pistettä, kun käyteään positiivisen SUS-kyselyn kysymyksiä (maksimi 50)

Mielestäni nuo eivät osu ihan kohdalleen: 

• 70%:n onnistumisastevaatimus on aika matala. Tarkoittaa, että käyttäjä saisi epäonnistua tehtävissään varsin usein. Kuitenkin tehtävät lienevät sellaisia, joissa tutkijoiden olisi onnistuttava käytännössä aina? (vai missä tehtävissä tutkijat saavat epäonnistua?)
• Käyttäjätyytyväisyyden minimivaatimus on SUS-kysymyksillä 30, kun maksimi on 50. Tämä tarkoittaa SUS-lukemaa 60 pistettä. Tämä on aika matala, vaikka absoluuttista totuutta sopivalle SUS-kyselyn tavoitetasolle on vaikea määrittää. Itse olisin päätynyt vähintään SUS-lukemaan 70 (eli hankintailmoituksen laskentatavalla minimivaatimukseksi 35 pistettä). 

Yhteenveto: Mittarit ovat ihan validit, mutta tavoitetasot ("riittävän" käytettävyyden taso) matalalahkot. Tämä tarkoittaa, että aika huonon käytettävyyden omaava järjestelmä voi tulla valituksi.

Käytettävyys vertailukriteereissä 

Vertailukriteereissä käytettävyys on mukana kahdella tavalla: 

• tehokkuus 10 %
• käyttäjätyytyväisyys 20 %

Periaatteessa ovat ihan valideja vertailukriteereitä. Niillä on kuitenkin suhteellisen korkea painoarvo (yhteensä 30%).  Kun pakolliset vaatimukset loogisesti tarkoittavat "riittävän" hyvää käytettävyyttä, niin onko tosiaan perusteltua, että "ylimääräisellä" käytettävyydellä on valinnassa peräti 30% painoarvo?

Yhteenveto: Mieluummin korkeampi vaatimustaso pakollisissa vaatimuksissa, ja vertailukriteereihin käytettävyys pienellä painoarvolla (jos ollenkaan). 

Mittarit

1. Tuloksellisuus

Tuloksellisuuden mittarina käytetään tehtävien onnistumisastetta.


Hyvää

• Tehtävien onnistumisaste on hyvä perusmittari
• Tehtäville annettu maksimiaika
• Tehtävät mietitty käyttäjäryhmäkohtaisesti

Ongelmallista: 

• Tehtävät on kuvattu, mutta ei ole selkeästi määritetty, mitkä ovat tehtävien onnistumiskriteerit. Se olisi kuitenkin ensiarvoisen tärkeää, koska mittari perustuu tehtävien onnistumisten tulkintaan. 
• Puuttuu on koettu tuloksellisuus yhtenä onnistumisen kriteerinä. Koettu tuloksellisuus tarkoittaa sitä, että sen lisäksi että käyttäjä objektiivisesti onnistuu tehtävässään, hänen pitää myös uskoa onnistuneensa. Jos koettua tuloksellisuutta ei vaadita, käyttäjä voi suoriutua tehtävästään, mutta luulee, että ei onnistunut. 
• Kaikkiin tehtäviin on laitettu sama maksimiaika: 15 minuuttia. Koska kaikki tehtävät eivät ole samanlaisia, niin olisi voinut harkita tehtäväkohtaisia ajanmäärityksiä. Tämän olisi pitänyt olla myös realistista, koska tehtäviä on sen verran vähän.  

Yhteenveto: Hyvä perusmittari, mutta onnistumiskriteerit pitäisi määrittää, ottaa mukaan koettu tuloksellisuus, ja miettiä tehtäväkohtaiset aikarajat

2. Tehokkuus

Tehokkuuden mittarina käytetään kaavaa, mikä perustuu tehtäviin käytettyyn aikaan.  

Hyvää

• Aika on tehokkuuden luonnollinen mittari

Ongelmallista

• Tehokkuutta käytetään ainoastaan vertailukriteereissä. Se ei ole asiana helppo, ja se näkyy myös valitussa laskentakaavassa, jossa osittain käytetään oikeaa aikaa ja osittain laskennallisia aikoja (jos käyttäjä ei onnistu tehtävässään, aika on aina 15 minuuttia). Tästä tulee potentiaalinen validiusongelma. 
• Tehokkuutta arvioidaan kaikkien tehtävien suhteen. Kuitenkaan tehokkuus ei yleensä ottaen ole yhtä tärkeä kaikissa tehtävissä. 
• Yleensäkin voisi miettiä, kuinka tärkeä absoluuttinen tehokkuus on tällaisessa järjestelmässä, jota käyttäjät käyttävät "aina silloin tällöin". Olisiko koettu tehokkuus ollut riittävä mittari?
• Absoluuttinen aika ei kuvaa koettua tehokkuutta. 

Yhteenveto: Olisin ottanut absoluuttisen tehokkuuden mukaan ainoastaan, jos oikeasti aikakriittisiä tehtäviä. Muussa tapauksessa olisin harkinnut vain koetun tehokkuuden mittaamista (jota itse asiassa SUS mittaa jossain määrin). 

3. Käyttäjätyytyväisyys

Käyttäjätyytyväisyyden mittaamiseen käytetään positiivinen SUS -kyselyä, mikä on hyvä mittari käytettävyystestien yhteydessä. 

Kuitenkin käyttäjälle annettu tehtävän selitys on harhaanjohtava: "Please fill out the usability survey. Please evaluate the usability of the system you just used and not the tasks". Eli johdatetaan käyttäjää arvioimaan järjestelmän käytettävyyttä. 


Tämä on aika iso virhe: SUS-kyselyssä käyttäjä raportoi käyttäjäkokemusta eikä arvioi käytettävyyttä (katso esim. yksittäisten kysymysten sisältöä). Nämä kaksi ovat ihan eri asioita. Käyttäjää pitäisi johdattaa kertomaan kokemuksestaan, eikä arvioimaan järjestelmää. 



Yhteenveto: Hyvä mittari, ongelmallinen johdattelu. 

Käytettävyystesti 

Kaikkiaan ammattimaisesti suunniteltu testi. Muutama huomio kuitenkin: 

1. "The user is asked to carry out the first task by reading the instructions for the task and the maximum time reserved for the task.... The task begins from the time the user is handed the task instructions".  

Itse toimisin niin, että sen jälkeen, kun käyttäjä on lukenut tehtävän, varmistaisin, että hän on ymmärtänyt sen. Ja sitten vasta kello käyntiin.

2. "You will be given a time frame in which it should be possible to complete the task. You should aim to complete the task... You should aim to finish the task at the pace with which you would normally use the system.... The instructions for the task show the maximum time reserved for the task. You should aim to finish within that time frame". 

Mielestäni on kyseenalaista kertoa käyttäjälle maksimiaika, sanoa, että hänen pitäisi selvitä tuossa ajassa jne. Parempi tapa on yksinkertaisesti pyytää käyttäjää tekemään parhaansa. Eikä sen kummemmin kertoa ajan mittaamisesta, tavoiteajoista tms.

3. Liian johdattelevia tehtävämäärittelyjä. Vaikkapa ensimmäinen: "A conference article that you wrote has been published. Enter the article details manually in the system. Then navigate to your publication view to see the new publication." 

Miksi "yksityiskohdat" (article details)? Olettaisin, että pitäisi riittää yleisempi ilmaisu, esim. "enter the article information" (järjestelmän pitäisi johdattaa käyttäjää siihen, että käyttäjä laittaa sinne tiedot tarvittavalla yksityiskohtaisuuden tasolla)

Miksi käsketään menemään näkymään "publication view", joka on selvästi johdatteleva pyyntö? Ja mahdollisesti ei tasapuolinen, jos jossakin järjestelmässä käytetään jotain muuta termiä. Mieluummin loppuun esim. "Finish the task when you think you have done it successfully".