kirjoituksia Hanki käytettävyyttä! -blogissa

Olen viime aikoina kirjoitellut Hanki käytettävyyttä! -blogiin, http://hankikaytettavyytta.blogspot.com/

Kyseisen blogin erityinen näkökulma on käytettävyyden varmistaminen tietojärjestelmien hankinnoissa. Mutta siinä on ehkä kiinnostavaa käytettävyysasiaa yleisemminkin. Viime kirjoitukset käsittelevät käytettävyysvaatimuksia ja käytettävyyden validointia.

"Asiakas hyväksyy" EI ole yhtäkuin käytettävyys

Aiempaa kirjoitustani käytettävyyden validoinnista kommentoitiin ketterän kehityksen käyttäjälähtöisyydellä (http://hankikaytettavyytta.blogspot.com/2011/09/kaytettavyyden-validointi-edellyttaa.html?showComment=1315308433056#c26718616511358904).  

Käyttäjälähtöisyys on tietenkin periaatteessa hyvä lähtökohta. Mutta käyttäjien mukanaolo ei sinällään takaa yhtään mitään käytettävyydestä (keskeinen kysymys on, miten käyttäjät otetaan mukaan). 

Jo usampi vuosi sitten olin tekemässä studya, jossa käytiin läpi VTT:n tekemä ketterän kehityksen esimerkkiprojekti käytettävyysnäkökulmasta (raportoitu: http://www.informatik.uni-trier.de/~ley/db/conf/profes/profes2004.html#JokelaA04). Tuoteomistaja - asiakas ja myöskin käyttäjä - oli mukana projektissa aktiivisessa roolissa. Kuitenkin projektin käytettyvyyden kypsyystasoksi saatiin karkeasti "0" (asteikolla 0...4). Kuten em. artikkelin otsikossa sanotaan, "Close Co-operation with the Customer Does Not Equal to Good Usability". 

- Otetaan yksi kohta edellä viitatusta kommentista: "Scrum-kehityksessä käytettävyyden huomioiminen on periaatteessa helppoa, koska työn määrittelyn välineenä olevien käyttäjätarinoiden (User Stories) muotoilu on käyttäjälähtöistä. Tällöin kirjoituksen lainauksessa mainittu toimintatapa, jossa prototyypillä ("realistisella sovelluksen simulaatiolla"), on mielekäs kun siinä hyväksytetään alkuperäisen määrittelyn toiminnallisuudet asiakkaalla tai tuoteomistajalla (Product Owner)...  Milloin on riittävän hyvä" on silloin kun tietyn käyttäjätarina voidaan hyväksyä tehdyksi (Definition of Done)."

Tässä siis tulkintani mukaan sanotaan, että hyvän käytettävyyden kriteeri on se, että asiakas hyväksyy toteutetun käyttäjätarinan. 

Ja minun kommenttini on, että asiakkaan hyväksynnällä ei tarvitse olla mitään tekemistä käytettävyyden kanssa. Käytettävyyden kriteeri ei ole se, että "asiakas hyväksyy" vaan se, että "miten hyvin määrätyt käyttäjät voivat käyttää tuotetta määrätyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja miellyttävästi" (ISO 9241-11 määritelmä; ks. myös http://kaytettavyysnavigoija.blogspot.com/2011/08/mika-olikaan-kaytettavyyden-maaritelma.html). 

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.

Mikä olikaan käytettävyyden määritelmä? Mitä ajatuksia ja kokemuksia?

Näin kesälomien päättyessä kertaus perusasioihin. Onko aito, oikea käytettävyyden määritelmä joskus hukassa? (ainakin itse joudun sanatarkkaa määritelmää aina aika etsimään). Määritelmähän on sanamuodoltaan aika monimutkainen, ja hieman erilaisia käännöksiä näkyy eri kirjoituksissa.

Käytettävyyden määritelmä on ISO 9241-11 englannin kielisen version mukaan: Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

ISO 9241-11 virallinen - ja suositeltava -  suomenkielinen käännös on: Mitta, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta määrätyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja miellyttävästi.

Edelleen määritellään käytetyt termit:

• Käyttäjä: Henkilö, joka on vuorovaikutuksessa tuotteen kanssa.

• Tavoite: Tarkoitettu lopputulos.

• Tuloksellisuus: Tarkkuus ja täydellisyys, jolla käyttäjät saavuttavat määritetyt tavoitteet.

• Tehokkuus: Voimavarojen käyttö suhteessa tarkkuuteen ja täydellisyyteen käyttäjien saavuttaessa tavoitteet.

• Tyytyväisyys: Epämukavuuden puuttuminen ja myönteinen suhtautuminen tuotteen käyttöön.

• Käyttötilanne: Käyttäjät, tehtävät, laitteet (laitteisto, ohjelmisto ja aineistot) sekä fyysinen ja sosiaalinen ympäristö, jossa tuotetta käytetään.

(Esimerkiksi suomenkielisessä wikissä määritelmä on käännetty hieman erilailla: Se vaikuttavuus, tehokkuus ja tyytyväisyys, jolla tietyt määritellyt käyttäjät saavuttavat määritellyt tavoitteet tietyssä ympäristössä).  

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

Määritelmän keskeinen ajatus on siis se, että käytettävyydessä on kyse siitä, miten tuote tukee käyttäjän tehtäviä ja työtä. Eikä siis esimerkiksi erityisesti siitä, minkä näköinen käyttöliittymä on (tämä harhakäsitys jatkuvasti tulee vastaan). 

Määritelmä on keskeinen, paljon viitattu ja omasta mielestäni perussisällöltään hyvä. Mutta tämäkään määritelmä ei tietenkään ole mikään totuus. 

Määritelmästä ja sen edelleen kehittämisestä keskustellaan standardointipiireissä. Ja on joitakin näkemyksiä - myös itselläni - miten määritelmää voitaisiin kehittää. 

Palaan noihin kehittämisajatuksiin myöhemmin. Mutta ensin kysyisin, että onko teillä lukijat ajatuksia, kokemuksia tai ehdotuksia määritelmään liittyen? Mikä hyvää, mikä mättää, mitä puuttuu, mikä epäselvää tms?