Käytettävyysatastrofi, jota käytettävyyden määritelmä ei tunne

Jeff Sauro siteraa blogissaan Gerry McGovernia, joka määrittelee (käytettävyys)katastrofiksi tilanteen, jossa käyttäjä luulee saavuttaneensa oikean aikaansaannoksen mutta ei olekaan saavuttanut sitä.

Mielenkiintoinen tähän liittyvä näkökulma on se, että käytettävyyden ISO-määritelmä ei kata tällaista tilannetta, koska siinä ei ole attribuuttia "koetulle tuloksellisuudelle".

Olenkin standardointityöryhmissä ottanut esiin, että kun käytettävyyden määritelmää tarkastellaan uudelleen, nykyisiä attribuutteja (tuloksellisuus, tehokkuus, miellyttävyys) laajennettaisiin koetulla tuloksellisuudella ja myös koetulla tehokkuudella.

Katso Jeff Sauron blogi ja kommenttini siihen: http://www.measuringusability.com/blog/ui-disasters.php

"Yhdessä käyttäjien kanssa" -sudenkuoppa

Huomasin Jaakko Talvitien mielenkiintoisen blogikirjoituksen: http://www.activityblog.fi/2011/12/liikaa-insinooreja/: 

"... Entä jos ohjelmistotuotannossa otettaisiin käyttöön laitetuotannon tapa käyttää muotoilijoita? Insinöörit ja muut ohjelmistoammattilaiset keskittyisivät suunnittelemaan ja toteuttamaan tietojärjestelmän, jonka muotoilijat ja käytettävyyden spesialistit ovat hahmotelleet yhdessä käyttäjien kanssa. Tällöin tärkeää ei olisi pelkästään se, mitä ohjelmistolla voi tehdä, vaan myös se, miten sitä käytetään ja erityisesti se, miltä sen käyttäminen (kyllä vaan!) tuntuu."

Jaakon kirjoituksessa on asiaa. Mutta varmuuden vuoksi muutama täsmennys: 

• Suunnittelu ("hahmottelu") yhdessä käyttäjien kanssa on sudenkuoppa. Käyttäjät ovat kyllä olleet mukana perinteisestikin tietojärjestelmäprojekteissa - huonoin tuloksin. Suunnittelun pitää perustua käyttäjätietoon, mutta pointti on siinä, miten käyttäjätieto saadaan ja miten se otetaan mukaan suunnitteluun. Tässä on mielestäni  monilla "käytettävyysasiantuntijoillakin" erheellisiä käsityksiä (käytettävyysasiantuntija lainausmerkeissä, koska sellaista muodollista pätevyyttä ei kenelläkään ole - ei myöskään minulla...)
• Myöskin on erheellisiä käsityksiä, mistä käyttäjälähtöisyyden suunnittelun tulisi lähteä. Itse erityisesti korostan tietoarkkitehtuurin määritystä käyttäjälähtöisesti http://kaytettavyysnavigoija.blogspot.com/2011/05/kayttajalahtoinen-tietorakenne.html 
• Muotoilulla on selkeä roolinsa, mutta yleensä ei homma siitä kiikasta. Monesti on jopa haittaa siinä mielessä, että homma kuvitellaan ratkaistavan sillä, että laitetaan mainostoimisto asialle. 
• Mikä on oikea tapa ottaa käyttäjät mukaan? Siitä olen kirjoitellut tässä blogissa aiemmin ja käytettävyysnavigoija-blogissa, samoin kirjassani.
• Käytettävyyden aikaansaaminen tietojärjestelmissä on lisäksi - ja erityisen paljon - hankinnallinen ongelma (mihin asiaan tämä blogi on erityisesti keskittynyt). 
• Yksi aiheeseen liittyvä artikkeli: http://hankikaytettavyytta.blogspot.com/2011/11/timon-vieraskyna-hesarissa-9112011.html
• Käyttäminen "tuntuu" hyvältä kun järjestelmä tukee käyttäjän työtä: käyttäjä saa vaivatta aikaiseksi haluamiaan tuloksia. 

Esko Aho valtion tietojärjestelmähankinnoista Hesarissa - ja vähän Timokin