keskiviikko 29. toukokuuta 2013

P-SUS (positiviinen SUS) -kysely suomeksi: uusi versio

Aiemmassa kirjoituksessani ehdotin käännöstä P-SUS (Positive System Usability Scale) -kyselylle, ja pyysin käännöksestäni palautetta. Ja kiitos monelle, sitä myös sain!

Tässä nyt uusi versio käännöksestä, johon otin ideoita saamistani kommenteista. Tätäkin toki saa kommentoida, mutta olkoon tämä nyt toistaiseksi voimassa oleva käännökseni.

Tilanteesta riippuen, sanan "verkkosivusto" voi korvata termillä "järjestelmä" tai "palvelu" (tms).

P-SUS (Positiviinen System Usability Scale): 




1
I think that I would like to use this website frequently     
Käyttäisin mielelläni tätä verkkosivustoa usein.
2
I found the website to be simple.
Koin verkkosivuston olevan yksinkertainen.
3
I thought the website was easy to use.
Verkkosivustoa oli mielestäni helppo käyttää.

4
I think that I could use the website without the support of a technical person
Osaisin käyttää verkkosivustoa ilman teknisen henkilön opastusta.

5
I found the various functions in this website were well integrated.
Mielestäni verkkosivuston eri osat toimivat keskenään hyvin yhteen.

6
I thought there was a lot of consistency in this website.
Mielestäni verkkosivuston eri osat toimivat samalla tavalla.

7
I would imagine that most people would learn to use this website very quickly.
Kuvittelen, että useimmat oppisivat verkkosivuston käytön erittäin nopeasti

8
I found the website very intuitive
Mielestäni verkkosivuston käyttö oli erittäin intuitiivista (= oli erittäin helppo arvata, miten verkkosivusto toimii).

9
I felt very confident using the website
Tunsin itseni hyvin varmaksi, kun käytin verkkosivustoa

10
I could use the website without having to learn anything new
Osaisin käyttää verkkosivustoa ilman, että minun täytyy opetella mitään uusia asioita.


maanantai 6. toukokuuta 2013

Positiivinen SUS (System Usability Scale) suomeksi

Positiivisen SUS -skaalan on todettu antavan yhtä luotettavia tuloksia kuin perinteisen SUS -skaalan, mutta on helpompi täyttää (ja sitä kautta käytettävämpi!). Ks.  http://www.amazon.com/Quantifying-User-Experience-Practical-Statistics/dp/0123849683/ref=la_B006LTIRUO_1_1?ie=UTF8&qid=1367820523&sr=1-1.

Kyselyähän käytetään käytettävyystestisession jälkeen mittaamaan koettua käytettävyyttä.

Kyselyt ovat kuitenkin herkkiä käännöksille. Alla on oma käännökseni. Pyydän itse kutakin antamaan palautetta käännöksestä: jos näette käännöksessä ongelmia tai teillä on ehdotuksia, miten parantaa käännöstä. 



1
I think that I would like to use this website frequently          
Luulen, että mielelläni käyttäisin tätä verkkosivustoa usein.
2
I found the website to be simple.
Huomasin verkkosivuston olevan yksinkertainen.
3
I thought the website was easy to use.
Ajattelin, että verkkosivuston käyttäminen on helppoa.
4
I think that I could use the website without the support of a technical person
Luulen, että osaisin käyttää verkkosivustoa ilman teknisen henkilön opastusta.
5
I found the various functions in this website were well integrated.
Huomasin verkkosivuston eri toimintojen toimivan hyvin yhteen.
6
I thought there was a lot of consistency in this website.
Ajattelin, että verkkosivuston eri osat toimivat keskenään samalla tavalla.
7
I would imagine that most people would learn to use this website very quickly.
Luulen, että useimmat oppivat verkkosivuston käytön erittäin nopeasti.
8
I found the website very intuitive
Mielestäni verkkosivuston käyttö oli erittäin intuitiivista (oli helppo arvata, miten verkkosivustoa käyttää)
9
I felt very confident using the website
Tunsin itseni hyvin varmaksi, kun käytin verkkosivustoa.
10
I could use the website without having to learn anything new
Osaisin käyttää verkkosivustoa ilman, että minun täytyy opetella mitään uusia asioita.

maanantai 4. maaliskuuta 2013

Esimerkki: Jos haluaa laatua, niin hinta tarjousten valintaperusteeksi!

Jos haluaa laatua, niin laatu pakollisiin vaatimuksiin ja hinta päävertailukriteeriksi.

Tästä olen kirjoitellut aiemminkin: käytettävyys (ja laatu yleisemminkin) pakollisiin vaatimuksiin eikä vertailukriteereihin tarjouspyynnöissä: http://hankikaytettavyytta.blogspot.fi/2012/01/laatu-pakollisiin-vaatimuksiin-eika.html

Vielä esimerkin valossa, miksi näin. Jatkuvasti näkee tarjouspyyntöjä, joissa tämä ei toteudu. Toisaalta kukaan ei ole pystynyt minulle osoittamaan vääräksi sitä yksinkertaista päättelyä, miksi laatu pitäisi olla pakollisissa vaatimuksissa. Kuvaan vielä asian esimerkin kautta. 

Oheisessa taulukossa erään tarjouspyynnön vertailukriteerit; aika paljon näkee tämän tyyppisiä. Hinnan painoarvo on 40% ja laadun 60%. Vertailukriteerit tarkoittavat siis sitä, että pakolliset vaatimukset täyttävistä toimittajista valitaan tarjouskilpailun voittajaksi se, joka saa vertailukriteereistä eniten pisteitä. 


Valituksi tulee siis toimittaja, joka saa korkeimmat pisteet. Pisteet lasketaan periaatteessa mekaanisella yhteenlaskulla: lasketaan kunkin tarjouksen vertailukriteereistä saadut pisteet yhteen. Korkeimman pistemäärän saanut tarjous voittaa ja on valittava. Piste. 

Nyt kun laatu on vertailukriteereissä, niin ongelma on se, että valituksi voi tulla toimittaja, joka saa joiltakin laadun alueilta "nollan". Toisin sanoen, asiakas ei saa siltä osa-alueelta minkäänlaista laatua. 


Tämän esimerkin vertailukriteereissä käytettävyyden ("kokonaiskäytettävyys") painoarvo on 16%. Nyt voi olla täysin mahdollista, että valituksi voi tulla toimittaja, joka saa käytettävyydestä "nollan", jos se saa korkeat pisteet muilta osa-alueilta.

Eikä tämä siis koske pelkästään käytettävyyttä vaan myös muita laatukriteereitä. Esimerkin vertailukriteereissä "toimittajan kokemus ja projektiosaaminen" on painoarvolla 5%. On siis tosi suuri mahdollisuus, että valituksi voi tulla toimittaja, joka saa kokemuksesta ja projektiosaamisesta "nollan". Kelpaako tällainen toimittaja ihan oikeasti järjestelmän hankkijalle?

Yhteenveto: jos haluaa laatua, niin laatu pois vertailukriteereistä ja laatu pakollisiin vaatimuksiin, ja hinnan ratkaista valinnnan (siis hinta on 100%). Niin oudolta kuin se aluksi ehkä kuullostaakin. (Valintakriteereissä voi toki olla jonkin verran "ylimääräistä" laatua; mutta näkisin, että hinnan painoarvon olisi yleisesti oltava vähintään 80%). 

"Se ei toimi", ei kirkossakaan

Kirkon uusi Kirjuri-jäsentietojärjestelmä on aiheuttanut pöhinää kirkon sisällä, ainakin Kirkko & kaupunki -lehden pääkirjoituksen (lue tästä) (html) mukaan: "Järjestelmässä ei olekaan kuin yksi vika. Se ei toimi". 



Itse kommentoin mielipideosastolla jutulla (lue tästä), jonka sisältö ei varmaan yllätä tämän blogin lukijoita. Vaikka en hankintaa tarkemmin tunne, niin valistunut arvaukseni on, että ongelma on ollut järjestelmän (kehittämisen) kilpailuttamisessa.  



perjantai 15. helmikuuta 2013

Näin hankitaan käytettävyyttä: päävaiheet

Olen monissa aiemmissa kirjoituksissani - vaikkapa edellisessä - tarkastellut kriittisesti tapoja, miten käytettävyyttä on yritetty ottaa huomioon tietojärjestelmien hankinnnoissa.

Millainen lähestymistapa olisi sitten toimiva ratkaisu?  Tässä esitän, miten hankinta pitäisi periaatteessa tehdä. Tämä pätee hankintoihin, jossa tarkoituksena on hankkia tietojärjestelmä, jotka perustuvat olemassa olevaan tietojärjestelmäratkaisuun ja jotka räätälöidään tai konfiguroidaan asiakkaan tarpeiden mukaan. Tällaisia ovat usein esimerkiksi matkanhallinta-, HR- ja CRM-järjestelmät. (Asiakaskohtaisesti kehitettävän järjestelmän hankkiminen on sitten eri tapaus).

  1. Perustaksi on tärkeä määrittää, miten tärkeää käytettävyys on hankittavassa järjestelmässä (tämä pätee tietenkin kaikkiin tietojärjestelmien kehityshankkeisiin, ei vain hankintoihin). Tässa vaiheessa asetetaan tavoitteet, millaista vaikuttavuutta käytettävyydeltä halutaan: mitä etuja halutaan saavuttaa, mitä riskejä välttää. 
  2. Keskeinen toimenpide on sitten selvittää markkinoilla olevien vaihtoehtojen potentiaalinen käytettävyys ennen kilpailutusta, niin että tiedetään, että minkätasoisia tarjolla olevat järjestelmät ovat käytettävyydeltään suhteessa asetettuihin tavoitteisiin. Jos käytetään neuvottelumenettelyä, niin tämä vaihe voitanee tehdä neuvotteluvaiheessa. 
  3. Sitten varsinaista kilpailutusta (tarjouspyyntöä) suunniteltaessa tiedetään, onko yleensäkään tarjolla järjestelmiä, joissa on halutun tasoinen käytettävyys. Jos on, niin kilpailutus käyntiin. Jos ei, niin voidaan harkitaan, hankitaanko "huono" järjestelmä, kehitetäänkö uusi omien tarpeiden mukaan, vai mitä tehdä. Jos kilpailutetaan, niin ainakin tiedetään jo etukäteen, mikä on olemassa oleva taso. 
  4. Sitten varsinaisessa kilpailutuksessa käytettävyys tulisi laittaa pakollisiin vaatimuksiin (miksi: katso tästä ja tästä). Tässä vaiheessa pitäisi siis olla jo tiedossa, että on olemassa järjestelmiä, jotka täyttävät nämä vaatimukset. 
Tämä malli on mielestäni looginen (vai ajatteleeko joku toisin?). Kuitenkin kun tarkastelee julkisia tarjouspyyntöjä, niin havainto on, että käytännössä ei toimita näin. Sen sijaan toimitaan siten, että käytettävyyttä arvioidaan vasta kilpailutusvaiheessa sen jälkeen, kun on saatu tarjoukset. Tällöin mennään kilpailutukseen väkisin vähän riskillä, kun ei tiedetä, millaista laatua vaihtoehdot edustavat (ajatteleeko tästä joku toisin?)


En väitä, että kuvaamani prosessi on helppo. Esimerkiksi vaiheessa 2  pitäisi arvioida järjestelmiä, joista voi paljolti puuttua käyttäjärajapinnan yksityiskohdat (koska ne sitten luodaan räätälöinnin yhteydessä). Arvioinnissa siis pitäisi pystyä selvittämään, mikä on perusratkaisun käytettävyys, siis millaisen käytettävyyden voi perusratkaisun pohjalle kehittää. 

Tällaisessa tilanteessa käyttäjäpohjaiset käytettävyysarvioinnit eivät tule kysymykseen. Itse näen, että riittävän syvään substanssiymmärrykseen perustuva asiantuntija-arviointi on ratkaisu. Ja tässä on tuon substanssiymmärryksen hankkiminen se ensiarvoisen tärkeää (minun käyttämäni menetelmä substanssiymmärryksen saamiseksi on ExposeThings). 

Tämän jälkeen siis tehdään vaihtoehtojen käytettävyysarvioinnit asiantuntijan silmin. Se, miten tämä tehdään, on oma lukunsa. Joka tapauksessa voi sanoa, että demoesittelyissä (joita hankinnoissa harrastetaan paljon) tällaiset asiat eivät kyllä selviä, vaan järjestelmään on päästävä tutustumaan syvällisemmin. 

Minun tietääkseni esittämääni tapaa käytettävyyden huomioimiseen ei ole käytetty (vai tietääkö joku?) Avoimissa tarjouspyynnöistä (joita olen käynyt läpi varmaan pari sataa) en ole tällaista nähnyt; "suljettuja" neuvottelumenettelyjä en tietenkään ole voinut seurata. 

Omasta mielestäni tietenkin tällaista lähestymistapaa kannattaisi käytettävyydestä aidosti kiinnostuneen hankkijan kokeilla. Sen voin sanoa, että ihan oikeasti en tiedä, mikä olisi jokin toinen toimiva vaihtoehto. Jos jollakin on idea tai eri näkemyksiä, niin ehdottomasti saa haastaa!