Uusin Sytyke-lehti (4/ 2015) keskittyy käytettävyyteen, käyttäjäkokemukseen ja esteettömyyteen

Uusin Sytyke-lehti (4/ 2015) keskittyy käytettävyyteen, käyttäjäkokemukseen ja esteettömyyteen. Lehti on katsottavissa täältä.

Lehden editoreina olivat Eija Kalliala, Matti Vuori ja minä.

Lehti sisältää monta mielenkiintoista artikkelia:

• 3 Pääkirjoitus • Matti Vuori
• 4 Verkkosivustojen käytettävyys uusiin korvin • Tapio Haanperä, Sirpa Riihiaho
• 6 Käytettävyys avoimen lähdekoodin ohjelmistokehityksessä – haasteita ja mahdollisuuksia • Mikko Rajanen
• 8 Käytettävyyden vaikuttavuus – käytettävyyden lenkki bisnekseen • Timo Jokela
• 10 Käyttökokemustavoitteiden hyödyntäminen – Case konttinostureiden etäohjauskonsoli • Hannu Karvonen, Eija Kaasinen, Hanna Koskinen
• 13 Sytyke ry:nVaikuttavin opinnäytetyö 2014–2015-kilpailunvoittaja 
• 14 Käytettävyyttä terveysteknologiaan – viranomaisvaatimukset ja markkinoilla menestyminen • Terhi Holappa
• 18 Tilit selviksi – ikäihmisten digipalveluissa on vielä kehittämistä • Aulikki Uusitalo-Kasvio
• 20 Missä laajuudessa käyttäjät mukaan? Ohjenuorana kehittäjien ja käyttäjien välinen sosiaalinen etäisyys • Mikael Johnson
• 22 Palveluiden käytettävyyden ja esteettömyyden perustelu ja edistäminen • Henry Haglund
• 24 Digitaaliset palvelut ja käyttökokemus it-tradenomien opetuksessa • Niina Kinnunen
• 26 Kolumni: Kuutamolla

Oma artikkelini otsikko siis Käytettävyyden vaikuttavuus – käytettävyyden lenkki bisnekseen. 

Tiivistelmä: Ohjelmiston hyvä käytettävyys on joskus todella tärkeää, joskus vähemmän olennaista. Kuinka hyvää käytettävyyttä tarvitaan ja kuinka paljon käytettävyyden suunnitteluun kannattaa panostaa, riippuu halutusta käytettävyyden vaikuttavuudesta.

Ilmainen Käytettävyys tietojärjestelmien hankinnassa -verkkokurssi katsottavissa 13.11.2015 asti (PÄÄTTYNYT)

Osa 1: Johdanto

• Miten hankinnoissa on lähdettävä kehittämään käytettävyyden aitoa huomioimista?
• Miten käytettävyys hankinnoissa eroaa käytettävyydestä tuotekehityksessä?

Osa 2: Käytettävyys
• Mitä on käytettävyys - ja mitä se ei ole?
• Jos halutaan hyvää käytettävyyttä, mitkä suunnitteluratkaisut ovat kriittisimpiä?
• Miten käyttäjäkokemus eroaa käytettävyydestä?

Osa 3: Hankinta
• Mitä ovat tarjouspyynnön keskeiset elementit käytettävyyden (laadun) näkökulmasta?
• Miten järkevän toimittajan kannattaa toimia?
• Käytettävyys pakollisissa vaatimukset vs. vertailukriteereissä?
• Mikä on ainoa käytettävyyden takaava menettely tarjouspyynnössä? 

Osa 4: Johtopäätökset
• Mikä yllättävä käytettävyystoimenpide nousee keskeiseksi hankinnoissa?
• Minkä yllättävän käytettävyysasian määrittäminen on kriittisintä?
• Mikä kolmas näkökulmaa pitää ottaa huomioon?
• Mitä käytännön käytettävyystoimenpiteitä hankkijan olisi osattava?

KATSO KURSSI TÄSTÄ

"Apotin ongelmat näkyivät jo tarjouspyynnössä"

Lähetin ao. kirjoituksen ehdolle Helsingin sanomien mielipidepalstalle jo n. kuukausi sitten. Sitä ei kuitenkaan julkaistu, mutta julkaisempa sen sitten tässä. 

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

CGI:n Matti Häkkinen ihmettelee (HS 7.9.15), kannattaako Apotista maksaa 65 miljoonaa enemmän 2,5 pisteen takia. Hyvä kysymys, mutta ei yllättävä. 

Jo Apotin tarjouspyyntö kertoo, että valintaprosessissa saattoi käydä köpelösti kahdella tavalla: (1) maksetaan kovaa hintaa sellaisesta laadusta, jota ei oikeasti tarvita tai (2) saadaan sattumanvaraista laatua. Toki voidaan saada hyvääkin laatua ja oikealla hinnalla - mutta vain, jos on hyvä tuuri.  

Apotin tarjouspyynnössä tehtiin sama virhe, mikä monessa muussakin julkisessa hankinnassa: valintaperusteissa laatutekijöille annettiin suuri painoarvo. Apotin valintakriteereissä laatutekijöiden painoarvo 60 prosenttia ja hinnan painoarvo oli 40 prosenttia. Laadun painottaminen valintakriteereissä ei kuitenkaan takaa laadukasta lopputulosta eikä oikeaa hintaa. Valituksi voi aina tulla vaihtoehto, joka saa joltakin laadun osa-alueelta ”nollan” - saadaa siis surkeaa laatua. Tai sitten voidaan maksetaan kovaa hintaa ylilaadusta. 

Laadun iso painoarvo valintaperusteissa viestii usein myös sitä, että hankkija ei ole selvittänyt, millaista laatua hän aidosti tarvitsee. 

Jos julkisessa hankinnassa halutaan hyvää laatua, hinnan pitäisi olla ratkaiseva valintakriteeri - siis painoarvo lähellä 100 prosenttia - niin nurinkuriselta kuin se ehkä kuulostaakin. Hankkijan pitäisi keskittyä määrittämään, mikä on riittävän hyvä laatutaso, ja laittaa se tarjouspyynnön pakollisiin vaatimuksiin. Ei ole helppo tehtävä, mutta paljon hyödyllisempi kuin monimutkaisten vertailukriteerien määrittäminen ja vertailujen suorittaminen. 

On täysin mahdollista, että Apotissa maksetaan 65 miljoonaa turhasta laadusta. Tai sitten ei. Apotissa käytetyt hankintakriteerit eivät takaa laatua eivätkä sitä, että laadusta maksetaan oikea hinta. 

Käytettävyys/ esteettömyysartikkelin Sytyke-lehteen?

Hyvä käytettävyyden/ esteettömyyden asiantuntija, 

Kutsun sinua (tai kollegoitasi) kirjoittamaan artikkelin vuoden viimeiseen Sytyke-lehteen (http://www.sytyke.org/sytyke-lehti/). Lehden teema on ”Käytettävyys ja esteettömyys”. Lehti ilmestyy 3.12.2015. 

Kaikki aiheeseen liittyvät kirjoitukset ovat tervetulleita. Erityisesti arvostamme tutkimuspohjaisia artikkeleita. Artikkeli on mainio tilaisuus esittää tutkimustuloksia suomeksi ja kevyemmällä formaatilla kuin tieteellisillä foorumeilla. 

Ohjeet lehden kirjoittajalle ovat osoitteessa http://www.sytyke.org/sytyke-lehti/ohjeet-lehden-kirjoittajalle/. 

Lehti on 28-sivuinen, josta noin 22 sivua on varattu asiantuntija-artikkeleille kuvineen. Siihen mahtuu artikkelien pituudesta riippuen 5 - 10 artikkelia. Artikkelien joukkoon saattaa tulla muutamia Sytykkeen ja yhteistyökumppaneiden vajaan sivun kokoisia ilmoituksia. 

Artikkelit, kuvat ja kirjoittajatiedot tulisi lähettää minulle (timo.jokela@gmail.com) ja/ tai lehden päätoimittaja Eija Kallialalle (eija.kalliala@sytyke.org) ti 27.10. mennessä. Artikkeleille tehdään kielihuoltokierros. 

Toivomme, että tartut tähän tilaisuuteen. Käytettävyys ja esteettömyys -teemaisia lehtiä ei Suomessa usein julkaista. ilmoitathan artikkelisi otsikon tai aihepiirin meille 5.10. mennessä! 

terveisin, 

Timo Jokela 
puh: 040 5118250 
Eija Kalliala 
puh: 040 525 1761

Käytettävyys ja käyttäjäkeskeinen suunnittelu -kurssi 10.-11.9.2015

Järjestäjänä Talentum Events.

Katso tarkemmat tiedot täältä: http://talentumevents.fi/kaytettavyys/

Apotissa tehdään julkisten hankintojen perusvirhe

HS (21.3.2015) Apotista: "Tarjouksia vertailtaessa hinta ratkaisee 40 prosenttia. Muut perusteet liittyvät esimerkiksi laatuun, käytettävyyteen ja jatkokehityksen avoimmuuteen."

Jo tämän uutisen perusteella voidaan sanoa, että Apotin hankinnassa tehdään julkisten hankintojen perusvirhe. Selitän, mikä tämä on ja miksi se on virhe tässä videossa.

Ilmainen verkkokurssi: "Käytettävyys tietojärjestelmien hankinnassa"

Pidän otsikon mukaisen kurssin huhtikuun 2015 alussa. Tarkempaa tietoa ja ilmoittautuminen kurssille TÄSTÄ.

"Helppokäyttöisiä järjestelmiä pitää osata vaatia"

Kirjotinpa taas käytettävyysasiasta Hesariin: http://www.hs.fi/mielipide/a1427082794483 (24.3.2015)

Ei mitään erityisen uutta, mutta kun oli sopiva kirjoitus, mihin reflektoida.

Tiivistettynä:

"Monesti hankkijat ajattelevat ratkaisun olevan se, että käyttäjät otetaan mukaan hankintaprojektiin ja kysytään heidän mielipiteitään.

Ensimmäinen askel kohti aitoa käyttäjäystävällisyyttä on ymmärtää, että tällaiset triviaalit toimenpiteet eivät alkuunkaan ole vastaus tietojärjestelmien hankinnan todellisiin haasteisiin"

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