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

Kuka on käyttäjä tietojärjestelmien hankinnoissa?

Käyttäjiä ovat kaikki käyttäjien edustajat

Olin pari päivää sitten NordiCHI -konferenssin yhteydessä pidetyssä työpajassa, aiheena "käyttäjien osallistuminen tietojärjestelmien hankinnoissa": ks.  http://proc.cs.hut.fi/nordichi/

Oma esitykseni koski käyttäjien osallistumisen eettisiä näkökulmia: mitkä tavat ottaa käyttäjiä mukaan hankinnoissa ovat eettisesti oikein, ja tavat mitkä eivät ole. Oma näkemykseni siis on, että monet nykyisin käytetyt tavat ottaa käyttäjät mukaan eivät ole eettisesti kestäviä (ja tuottavat laadullisesti huonoja tuloksia).

Positioesityksessäni esitin eettisen periaatteen käyttäjien mukaan ottamiselle. Kerroin myös, mitkä käytännön menetelmät ovat täyttävät tuo periaatteen ja mitkä eivät: tunnistin 12 erilaista yleisesti käytettyä tapaa osallistaa käyttäjiä, joista ainoastaan 4 on eettisesti kestävää.  (Tästä teemasta olen postannut tässä blogissa alustavasti joskus aikaisemmin, ja palaan asiaan myöhemmin.)

-----------------
Mutta sitten tämän kirjoituksen pointtiin. Minulle esitettiin erittäin hyvä kysymys:
Keitä ovat käyttäjät? (tietojärjestelmien hankinnoissa)

No, vastasin: Käyttäjiä ovat ne, jotka eivät kuulu hanketiimiin. 

Sitten keskustelussa selvisi, että esimerkiksi Apotti -hankkeessa hanketiimiin kuuluu kaikkiaan ehkä 150 henkilöä. Siinä huomasin, että tuo vastaukseni ei olekaan pätevä. Mutta en siinä hetkessä oikein osannut jäsentää parempaa vastausta.

Itse en ole ollut mukana noin isoissa hankkeissa, mutta kuitenkin hankkeissa, joissa on mukana ehkä 20 - 30 henkilöä. Kuitenkin varsinainen hankkeen ydintiimi on ollut alle kymmenen, ehkä vain muutama henkilö. Ja olen nimenomaan nähnyt ongelmana ne roolit, mihin nuo laajempaan tiimiin kuuluvat käyttäjät tai heidän edustajansa laitetaan hankkeissa; käytännössä usein siis eettisesti ongelmallisiin rooleihin (ja tilanteisiin). Oikea vastaus kysymykseen "Ketkä ovat käyttäjiä?" siis ei ole "Ne, jotka eivät kuulu hanketiimiin".

Mikä olisi sitten parempi vastaus? Ketä ovat ne käyttäjät, joita erityisesti koskee omat eettisesti ohjeensa?

Vastaus "Ne, jotka eivät kuuluvat hankkeen ydintiimiin" on lähempänä totuutta, mutta "ydintiimi" on varmaan aika epämääräinen käsite. Eli tuskin tämäkään vastaus on oikein hyvä.

Mutta sitten keksi mielestäni yksinkertaisen ja ainakin tällä hetkellä pätevältä tuntuvan vastauksen:

Käyttäjiä ovat kaikki käyttäjien edustajat. 

Tämä pätee riippumatta siitä, ovatko käyttäjät/ käyttäjien edustajat hankkeessa mukana muodollisesti vai eivät. Menettelytavat, joilla käyttäjiä tai heidän edustajiaan otetaan mukaan, pitäisi olla kaikissa tapauksissa sellaiset, että ne eettisiä ja laadullisia ongelmia ei toteudu.

Varmuuden vuoksi: toki hanketiimissä voi olla mukana loppukäyttäjien ammattiryhmiä edustavia henkilöitä. Mutta oleellista on siis se, missä roolissa he ovat. On ihan ok, että he ovat projektipäällikköinä, asiantuntijoina tms. Mutta jos he ovat roolissa "edustaa käyttäjiä", niin silloin ollaan lähellä isoja ongelmia, jos ei toimita huolellisesti.

Hesariin kirjoittamani jutut kertovat tiiviisti käytettävyydestä/ julkisesta kilpailutuksesta

Aina joissakin yhteyksissä tulee esille Helsingin Sanomat tärkeänä mediana, jossa myös käytettävyysasioita voisi tuoda esiin.  

Itse olen Hesariin jonkin verran kirjoittanut ja myös saanut vieraskyniä ja mielipiteitä julkaistuksi. Saavutus, jonka asetan hyvinkin tieteellisten julkaisujeni rinnalle - pienempi prosentti Hesariin pääsee läpi kuin moniin arvostettuihinkin konferensseihin.

Nämä Hesarin kirjoitukseni ovat aika lyhyitä ja sellaisia, joita olen aika mietitysti kirjoittanut (ellei asiaa ytimekkäästi esitä, niin eipä ole toivoa julkaisemisestakaan). Ja ne aika hyvin tiivistävät sanomaani käytettävyydestä tietojärjestelmien hankinnoissa ja julkisesta kilpailutuksesta yleensä. Esimerkiksi Apottia käsittelen parissakin kirjoituksessa. 

Vaikeakäyttöisyys myös uusien järjestelmien riesa. 18.3.2014

Julkiset hankinnat eivät suosi halpaa. 17.4.2013

Tietojärjestelmän oltava helppokäyttöinen. 12.9.2012

Helppokäyttöisyyttä on osattava vaatia. 1.7.2012

Aho: Valtion IT-taidot heikkoja. 24.11.2011
(haastattelu)

Atk-hankinnoissa vastuu kuuluu tilaajalle. 9.11.2011

Myös minä olen tyhmä käyttäjä

Myös minä - Timo Jokela - olen "tyhmä" käyttäjä. 


Olen monessa esityksessä ym. tuonut esiin, että järjestelmä- (tuote-) kehityksessä ei pitäisi kysyä käyttäjien mielipiteitä, toivomuksia tms. Olen usein siteerannut Steve Jobsia: "Apple ei kysy käyttäjiltä".

Tämä viestini on ehkä käsitetty joskus väärin. Olen joskus esittänyt kalvon (alla), jonka viesti on se, että "lääkärien mielipidettä ei pitäisi kysyä". Tämä ei tarkoita, että erityisesti lääkäreiltä ei pitäisi kysyä mielipidettä, vaan että yleensäkään suunnittelu perustuen käyttäjien mielipiteille on väärä lähtökohta. Viesti paremminkin on se, että lääkäreiden - ja muiden käyttäjien - ei tarvitse sanoa mielipiteitään.

Ja että ei tulisi väärinkäsitystä, tämä koskee myös minua. Myös minä käyttäjänä olen sillä tavalla "tyhmä", että minulta ei pitäisi kysyä. Toki kysyä jotain, mutta ei niitä asioita, joita usein kysytään.

----------------
ESIMERKKI ITSESTÄNI

Voinee sanoa, että olen ammattimainen sähköpostin käyttäjä. Kuvitellaanpa, että olisi tilanne, jossa minun käyttööni kehitetään uusi sähköpostiohjelma.

MÄÄRITTELYVAIHE

Tällaista ei:
Näen, että roolini ja tehtäväni sähköpostin käyttäjänä ei ole kertoa kehittäjille, millaista sähköpostia haluan, mitä piirteitä siinä pitäisi olla, millainen sähköpostiohjelma on hyvä ja niin edelleen. Minä käytän työssäni "aivoresurssejani" paljon mieluummin muuhun, en halua eikä minua kiinnosta käyttää niitä tällaiseen määrittelytyöhön, joka ei ole varsinaista työtäni.

Jos tällaisia asioita kuitenkin kysyttäisiin minulta, en missään tapauksessa halua ottaa vastuuta sanomieni vaatimusten, toiveiden ym. oikeellisuudesta ja laadusta.

Mutta parempi siis, että ei tällaisia asioita ollenkaan kysyttäisi minulta. Jos kysytään, niin kysyjän pitäisi ymmärtää, että hän kysyy "tyhmältä käyttäjältä". Ja myös ymmärtää se, että hän aidosti väsyttää ja rasittaa minua kysymyksillään.

Tällaista kyllä:
Sen sijaan kyllä voin kertoa ja näyttää, millaista minun sähköpostin käyttö on. Ja kertoa yleensä, millaista tämä oma työn tekeminen on. Sellaiset asioiden - siis faktoja omasta elämästä - kertominen on paljon helpompaa ja luontevampaa kuin pinnistellä toivomuksia tai haluja. Ja erityisesti tämä on luotettavampaa tietoa: kerronhan faktoista.

Tosin tässäkin oletan, että haastattelija on sellainen, joka osaa esittää oikeita kysymyksiä. Että minun ei tarvitsisi miettiä, että mitä kertoisin. Vaan että haastattelija ottaa vastuun siitä, että ohjaa minua kertomaan oikeista, relevanteista asioista.

Jos jää jotain tahattomasti kertomatta, sekään ei ole minun vaan haastattelijan vastuulla.

SUUNNITTELUVAIHE

Tällaista ei:
Sitten kun kehittäjät ovat kehittäneet jotain, minä en halua, että minulle tullaan esittämään rautalankamalleja tai muita kuvia suunnitteluratkaisuista ja odotetaan, että antaisin niistä palautetta.

Voin ehkä antaakin, mutta kysyjän pitäisi tietää se, että palautteeni laatu voi olla mitä tahansa. Ja koska se voi olla mitä tahansa, niin parempi on, että ei ollenkaan kysyttäisi.

Kaikkein karmeinta olisi, jos minun pitäisi antaa käyttäjänä jokin hyväksymisleima, että ehdotettu ratkaisu on riittävän hyvä. Tai sen variaatio: että minun pitäisi kertoa, mitä pitäisi muuttaa niin, että muutosten jälkeen sitten hyväksyisin.

Ja vielä yksi karmea variaatio: että minun pitäisi jossain käyttäjäraadissa pisteyttää sähköpostiratkaisuvaihtoehtoja toimittajien esittämien demojen perusteella.

Ja vielä yksi karmeus: että minun pitäisi olla mukana suunnittelemassa sähköpostin käyttöliittymää. Absolut kiitos ei!

Tällaista kyllä:
Voin kyllä kokeilla jotain prototyyppiä. Tarkoittaa, että voin yrittää tehdä normaaleja tehtäviäni sillä. Siis keskittyä tehtävän tekemiseen, en millään tavoin prototyypin arvioimiseen.

Voin myös jälkikäteen kertoa käyttäjäkokemuksestani. Mutta en halua arvioida suunnitteluratkaisuja, puhumattakaan, että minun odotettaisiin ehdottavan parannusehdotuksia.

Siis että roolini on käyttää vain, olla käytettävyystestin testihenkilönä. Mutta ilman, että tarvitsee ajatella mitään muuta kuin että yrittää käyttää.

----
PS. Tämä tietenkin tarkoittaa, että käyttäjien ja asiakkaiden tarpeiden selvittäminen on haastava tehtävä kehitystiimille. Millä konsteilla saada nopeasti ja tuloksellisesti tietoa käyttäjiltä ja asiakkailta ja miten haastatella heitä - kerron uudesta lähestymistavasta ja muustakin enemmän tulevassa kirjassani:  http://asiakastarve.launchrock.com/

"Vaikeakäyttöisyys myös uusien järjestelmien riesa" -mielipide HS 18.3.2014

Pääkirjoitus 17.3. antoi sykäyksen tämän kommentin kirjoittamiseen.

Jos olet seurannut juttujani Hesarissa tai muualla, niin tuskin tässä sinulle mitään uutta on (laskelin, että taitaa olla viides kirjoitukseni Hesarissa tästä teemasta).

Jutussa joka tapauksessa perustelen lyhyesti, miksi en usko, että mitään ratkaisevasti parempaa tapahtuisi sen eteen, että järjestelmät muuttuisivat helppokäyttöisemmiksi tulevaisuudessakaan.

http://www.hs.fi/mielipide/Vaikeak%C3%A4ytt%C3%B6isyys+my%C3%B6s+uusien+j%C3%A4rjestelmien+riesa/a1395041459680