Käytettävyyden validointi edellyttää kriteereiden määrittämistä

Eräällä LinkedInin keskustelupalstalla on herännyt keskustelua käytettävyyden varmistamisesta.

Siellä on mielenkiitoisia puheenvuoroja. Tässä kommentti yhteen sellaiseen (tarkoitukseni oli käydä blogissa seuraavaksi läpi JHS-suosituksia käytettävyyden kannalta, mutta lykätään sitä analyysia myöhemmäksi). 

Petteri kirjoittaa: "... kuukausi UX parannusten kehittämiseen ketterässä kehityksessä on toooodella pitkä aika. Käytämme Rapid Design & Visualization (RDV) menetelmäämme yhdistettynä esim. Scrum-kehitykseen. Tällöin voimme kahden viikon Scrum -syklin aikana jo tehdä vähintään pari iteraatiota realistisella sovelluksen simulaatiolla ja kerätä siihen kommentit tai tehdä käytettävyystestit. Näin kaikki mitä on backlogissa on jo vähintään kertaalleen validoitu."

En tiedä tarkemmin, miten tuo prosessi alkupäässä menee. Kuitenkaan, jos ei ole alussa määritetty aitoja (valideja ja todennettavia) käytettävyysvaatimuksia, ei voida puhua validoinnista. Käyttäjäpalautteen kerääminen ja käytettävyystestaus ovat hyviä asioita, ja niillä käytettävyys todennäköisesti paranee. Mutta se jää auki, tuleeko riittävän hyvä. Validointiin tarvitaan kriteerit "milloin on riittävän hyvä".

Ihan niinkuin Pilvi kommentoi Petterin kirjoitukseen: "Iteratiivisen kehitystyön ja käyttäjätestausten vaatiminen ei varmaankaan riitä,mvaan edelleen on määriteltävä varhaisessa vaiheessa käytettävyystavoitteet ja pyrittävä mitattavuuteen?"

JHS-suosituksen käytettävyysvaatimusesimerkki: pientä pohdittavaa...

JHS-suositus "173 ICT­palvelujen kehittäminen: Vaatimusmäärittely" antaa suosituksia, nimensä mukaisesti,  tietojärjestelmän vaatimusmäärittelylle. 

Suositus on yleinen, eikä se erityisesti keskity yksittäisiin laatuominaisuuksiin kuten käytettävyys. On kuitenkin mielenkiintoista tarkastella suosituksen sisältöä käytettävyyden suhteen, koska oletan, että suositusta käytetään referenssinä myös käytettävyyteen liittyvien vaatimusten määrittämisessä. 

Otan tässä esiin suosituksessa olevan yhden esimerkin. Kohdan "11.1 Vaatimusluettelo ja tunnistetiedot" esimerkissä, s. 21, on (sattumoisin?) kaksi käytettävyysvaatimusta: 

(vähän epäselvä kuva; blogiin ei kuitenkaan mahtunut siististi tarkempaa)

Esimerkki on siis tarkoitettu yleiseksi vaatimusluetteloa kuvaavaksi, ei mitenkään erityisesti käytettävyysvaatimusesimerkeiksi.  Mutta kun kuitenkin ovat suosituksen esimerkkejä, niin tarkastellaan sitä tarkemmin tarkemmin. Aluksi yleisemmin, sitten validiuden ja todennettavuuden kannalta (ks. esim.  http://hankikaytettavyytta.blogspot.com/2011/08/miksi-kaytettavyys-epaonnistuu.html). 

1. Mitä käytettävyyden attribuuttia  (http://kaytettavyysnavigoija.blogspot.com/2011/08/mika-olikaan-kaytettavyyden-maaritelma.html) esimerkin vaatimukset edustavat? 

• Erityisesti, onko kyseessä tuloksellisuus vai tehokkuus?

No, tämä on vähän teoreettinen kysymys; jätänpä sen lukijan pohdittavaksi/ kommentoitavaksi. 

2. Ovatko vaatimukset valideja, sisällöllisesti oikeita? 

• Eli esimerkiksi jos käyttäjä voi muuttaa salasanaansa 30 sekunnin suoritusajassa, niin tarkoittaako se hyvää käytettävyyttä? 

Tämäkin lukijan pohdittavaksi. 

3. Ovatko vaatimukset todennettavia? Eli voidaanko niiden saavuttaminen yksikäsitteisesti todentaa?

----------------------
Ajattelin vastata itse ylläoleviin kysymyksiin, mutta jätänpä viimeisimmänkin kysymyksen aluksi lukijan pohdittavaksi ja kommentoitaviksi.  

Voiko softan tekeminen olla näin vaikeaa?

Kahden tilatiedon sitominen toisiinsa oli ohjelmistotoimittajalle ylivoimaisen vaikeaa

Kokemus projektista, jossa kilpailutettu toimittaja kehittää järjestelmää eräälle virastolle. Kyseessä järjestelmä, jossa virkailijat käsittelevät yhdenlaisia lupahakemuksia:

• Käsittelyn aikana virkailijoiden tulee syöttää aika paljonkin erilaista tietoa järjestelmään: tietoa hakijasta, luvan kohteista, jne. 


• Sitten kun kaikki tiedot on syötetty, niin hakemus voidaan käsitellä; ja jos kaikki on ok, luvan tilaksi voidaan antaa myönnetty. 

Hakemukseen liittyvä tietojen syöttö voi olla isokin urakka, eikä tapahdu välttämättä yhdellä virkailijan työrupeamalla (esimerkiksi kaikki tarvittava tieto ole heti saatavilla). Sen järjestelmästä tulisi näkyä se, että mitkä tiedot ovat valmiina ja miltä osin tietojen syöttö on kesken. Siis tilatiedot kuvaamaan tietojen syötön tilaa.

Ja nyt se varsinainen juttu: Järjestelmän toimittajalle oli liian iso juttu tehdä kohtuu hintaan/ ajassa sellaista toiminnallisuutta, jossa luvan hyväksyminen edellyttää, että tarvittavat tiedot on syötetty (tietojen syötön tilatiedot = valmis).

Lopputulos on sitten sellainen, että virkailija voi merkitä hyväksytyksi keskeneräiset hakemukset (hyväksymispainike on aktiivinen koko ajan). Ja voi sanoa, että lopputulos on käyttäjän kannata tosi hämäävä.

Ja se kysymys ohjelmistoasiantuntijoille: Miten kahden tilatiedon sitominen toisiinsa voi olla näin vaikeaa? Oman (tosin tosi vanhan) ohjelmointikokemuksen perustella olettaisin, että kyseessä olisi yksinkertainen perusjuttu.

muutama käytettävyysongelmaharjoite

Seuraavassa muutama suunnitteluongelma, joihin vastikään törmäsin (kun siis olin täyttämässä ko. lomakkeita). Mitä ongelmia, ja miten ratkaisisit?

a)

tarkempi kuva yo. dialogista:

b)

tarkempi kuva yo. dialogista:

c)

"Järjestelmän on oltava helppokäyttöinen" - vaatimus, jolla ei merkitystä

Jokainen järjestelmä täyttää vaatimuksen "järjestelmän on oltava helppokäyttöinen"

Erään asiakaskohtaisen järjestelmän tarjouspyynnön vaatimustaulukon yhdeksi pakolliseksi vaatimukseksi oli määritelty:

Järjestelmän on oltava helppokäyttöinen.

Tämä onkin yksi tyypillinen esimerkki, kun määritellään "käytettävyysvaatimuksia" tarjouspyyntöihin. 

Mitä tällainen vaatimus oikeastaan tarkoittaa? Kun puhutaan "vaatimuksista vaatimukselle", niin vaatimuksen tulisi olla

•  todennettava (verifioitava): vaatimuksen täyttyminen voidaan tarkistaa niin, että ei tule erimielisyyksiä siitä, että toteutuuko vaatimus vai ei


• validi: vaatimus on sisällöltään oikeita (= sen täyttyminen tarkoittaa, että kyseinen järjestelmä on "oikeasti" käytettävä) 

Vaatimus Järjestelmän on oltava helppokäyttöinen ei ole todennettava, koska ei ole mitään yksiselitteistä ja yleisesti hyväksyttyä kriteeriä sille, milloin järjestelmä on ”helppokäyttöinen”. Vaatimus on aivan liian yleinen ja epämääräinen.

Tietääkseni tällaisessa tapauksessa toimittaja voi yksinkertaisesti ja yksipuolisesti todeta, että "järjestelmä on helppokäyttöinen". Piste.  (vai tietääkö joku paremmin?)

Sitä kautta kaikki toimittajat voivat sitoutua tämän pakollisen vaatimuksen täyttämiseen ilman, että se merkitsee mitään järjestelmän aidon helppokäyttöisyyden näkökulmasta.

Vaatimus on tavallaan tietenkin validi (jos nyt halutaan helppokäyttöistä järjestelmää). Mutta kun vaatimus on niin epämääräinen (ei-todennettava), sen validiuden tarkastelu ei ole mielekästä. 

Yhteenveto: vaatimuksella "järjestelmän on oltava helppokäyttöinen" ei ole käytännön merkitystä tarjouspyynnössä.  

Miksi käytettävyys niin monesti epäonnistuu tietojärjestelmien hankinnoissa?

Julkisen hallinnon tietojärjestelmien käytettävyysongelmat ovat tunnettu ongelma: henkilökunnan - ja monissa sovelluksissa myös asiakkaiden - aika menee tietojärjestelmien kanssa tuskaillessa. Tunnettu asia esimerkiksi terveydenhuollossa: http://www.laakariliitto.fi/files/ArviotkriittisiaVanska.pdf

Oma johtopäätökseni on, että juurisyytä tulee etsiä järjestelmien kilpailutus- ja hankintaprosessista. Yhtenä taustana on vaikka Oulun yliopistossa tehty tutkimus siitä, että käytettävyyttä ei aidosti vaadita tarjouspyynnöissä:
http://www.yourhost.is/images/stories/NordiCHI2010/accepted/281.html

Moni moittii kilpailutuslainsäädäntöä. Kuitenkin mielestäni se on annettu konteksti, joka tulee hyväksyä lähtökohtana. Se sitten tekee käytettävyysasioita haastavammiksi, mutta tähän haasteeseen olisi etsittävä ratkaisuja.

Tietojärjestelmän hankinnan käytettävyystoimenpiteet ovat erilaisia riippuen siitä, onko hankittava järjestelmä

1. asiakaskohtaisesti kehitettävä: hankitaan kehitystyötä


2. asiakaskohtaisesti sovitettava: perusrunko olemassa, johon tehdään asiakaskohtaisia muutoksia


3. valmisohjelmisto: esimerkiksi perustoimisto-ohjelmistot

Ensin mainitussa tapauksessa (1) järjestelmän käytettävyyttä ei voi hankintatilanteessa arvioida, koska järjestelmää ei ole olemassa. Käytettävyys pitää siis varmistaa muilla keinoin. Viime mainitussa tilanteessa (3) käytettävyyden arviointi nimenomaan tulisi suorittaa hankintatilanteessa.  Ja keskimmäinen tapaus (2) menee tähän väliin. 

Seuraavissa postauksissa käyn esimerkkien kautta läpi, miten nykyisissä tarjouspyynnöissä käytettävyyttä yritetään (jos yritetään) varmistaa, mikä niissä menee pieleen, ja miten asiaa voisi kehittää. 

Mikä hyödyllistä käytettävyystutkimusta?

Ei riitä, että tutkimus tuottaa uutta tietoa. Uuden tiedon on oltava myös hyödyllistä. 

Viime vuosikymmenellä tehtiin eräs käyttöliittymäalan tutkimus, jonka tuloksena muun muassa todettiin, että kännykässä on valikko (suurinpiirtein näin).

Onko tällaisella tutkimustuloksella merkittävyyttä? Tiedän, että moni ajatteli tuolloin, että tuloshan on itsestään selvä. Tutkijan näkökulmasta tulosta  kuitenkin saattoi perustella siten, että kukaan ei ollut asiaa systemaattisesti tutkinut aikaisemmin, ja että tässä sen vuoksi tuotettiin uutta tietoa.

Usein näkeekin mainittavan tutkimuksen kriteerinä sen, että tulee tuottaa uutta tietoa.


Tämän postaukseni idea ei ole pohtia sitä, että oliko tulos "kännykässä on valikko" uutta tietoa vai ei. Sen sijaan haluan nostaa esiin kysymyksen siitä, että onko uuden tiedon tuottaminen riittävä kriteeri käytettävyystutkimukselle (ja yleensäkin tutkimukselle). Ja tämä esimerkki mielestäni valaisee tätä asiaa erinomaisesti.

Ajatellaanpa, mitä hyötyä yllä mainitusta tutkimustuloksesta ("kännykässä on valikko") oli/ olisi ollut Nokialle? Tai jollekin muulle toimijalle? Vastaus on kai ilmeinen: ei yhtään mitään. Voiko tällaisen tulokseen reagoida juuri muuten kuin että "kännykässä on valikko... so what?". Ei tällainen tutkimustulos ainakaan Nokiaa (olisi) auttanut olemaan Applea edellä käytettävyysasioissa.

Ei riitä, että tutkimus tuottaa uutta tietoa. Uuden tiedon on oltava myös hyödyllistä. 

Jos edellä mainittu tutkimus olisi tuottanut sen tyyppisiä  kuten "valikko on hyvä ratkaisu kännyköissä", tai että "valikot ovat jossakin tilateissa hankalia käyttää, ja pitäisi kehittää jotain parempaa", niin näistä olisi ollut ihan eri tavalla hyötyä. Toisaalta tällaisten asioiden selvittäminen olisi tietenkin ollut tutkimuksellisesti paljon haastavampaa.

Yllä mainittu esimerkki oli akateeemisesta tutkimuksesta. Mutta sama pätee tietenkin myös lähempänä käytäntöä olevaan tutkimukseen. Käytettävyyssuunnittelussakin olisi keskityttävä toimenpiteisiin, joiden hyödyllisyys on aidosti merkityksellistä.  Yhdessä käytettävyyden keskustelufoorumissa on esillä kysymys "Which should be used: Login, Log in, Logon, Log on?" (keskustelu näyttää näkyvän avoimesti!) Tämän tyyppisten asioiden selvittämiseen tuskin kannattaa laittaa merkittäviä resursseja.