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

Käyttäjätarpeet, -toiveet ja -vaatimukset. Mikä ero?

Eräässä keskusteluryhmässä esitettiin käyttäjälähtöisyyteen kysymyksiä: "Mikäs on hyvä tapa löytää käyttäjävaatimuksia?" Ja "Mikä on paras tapa tietää millaista palvelua/laitetta/työkalua käyttäjät kaipaavat?"

On tärkeää, että termit määritellään niin, että ne ymmärretään ainakin kutakuinkin samalla tavalla. Ja mielellään niin, että ne ovat sisällöllisesti kuvaavia.

Yllä on kaksi käyttäjälähtöisyyteen liittyvää termiä: käyttäjävaatimukset ja mitä käyttäjät kaipaavat. Muita näitä lähellä olevia termejä ovat esimerkiksi käyttäjätarpeet ja käytettävyysvaatimukset.

Itse tulkitsen termit seuraavasti:
- Käyttäjävaatimukset: ovat käyttäjän esittämiä (sanomia tai kirjoittamia) vaatimuksia järjestelmälle. Käyttäjä voi esittää näitä esimerkiksi silloin, kun häntä haastatellaan.
- Käyttäjätoiveet, tai "mitä käyttäjät kaipaavat" ovat samantyyppisiä kuin vaatimukset, mutta termit tietenkin viittaavat siihen, että ovat "pehmeämpiä" kuin vaatimukset. Lisäksi tulkitsen, että näihin termeihin voi liittyä se, että käyttäjät eivät välttämättä ole ilmaisseet näitä toiveitaan
- Käyttäjätarpeet: ovat niitä "perimmäisiä" asioita, joiden perusteella järjestelmä olisi suunniteltava. Eli ne antavat perustan sille, mitä järjestelmän viime kädessä tulisi tehdä.

Näissä on se oleellinen ero, että

   * Käyttäjävaatimukset ja käyttäjätoiveet /-kaipaukset ovat käyttäjien itsensä jäsentämiä asioita
   * Käyttäjätarpeet ovat suunnittelutiimin jäsentämiä johtopäätöksiä käyttäjien ilmaisemista vaatimuksista, toiveista ja  muista käyttäjälähtöisistä tietolähteistä (esimerkiksi havainnointi).

Eron tekee oleelliseksi se, että käyttäjien itsensä ilmaisemien asioiden laatu riippuu siitä, kuinka hyvin juuri kyseiset käyttäjät sattuvat jäsentämään tarpeitaan tai toiveitaan. Ja oma kokemukseni on se, että asioiden jäsentäminen on varsin haastavaa monelle käyttäjälle. Eli käyttäjä voi pukea sanoiksi jotakin ja tarkoittaa jotakin ihan muuta. Tai jättää pois jotakin oleellista tai korostaa jotakin turhaa.  Ja jos suunnittelutiimi luottaa suoraan käyttäjien lausumiin, niin on suuri riski, että pieleen mennään. (Itse asiassa muistaakseni jo 80-luvulla tiedettiin, että jos suunnittelee ohjelmiston asiakkaan vaatimusten mukaan, niin asiakas ei tule olemaan siihen tyytyväinen).

Käyttäjätarpeiden määrittäminen taas riippuu suunnittelutiimin jäsentämiskyvystä. Siihen sitten liittyy se vastuu ja riskiotto, että ei tehdäkään oikeita tulkintoja ja jäsennyksiä. Mutta minun mielestäni tämä on kuitenkin se tie, joka suunnittelutiimin - tai vaikka käytettävyysasiantuntijan - olisi valittava. Olen nähnyt sellaisia käyttäjätutkimusraportteja, jossa tätä askelta ei ole otettu. Mielestäni tällainen ei edusta ammattimaisuutta vaan on vastuun pakoilua.

 (Käytettävyysvaatimuksia ei käsitellä tarkemmin tässä kirjoituksesssa)

En ollutkaan poliisi

Käytettävyysarvioinnin ei välttämättä tarvitse olla negatiiviseksi koettua "arvostelua". Ison organisaation verkkosivuista vastaavat henkilöt pitivät ulkopuolisen arviojan kanssa käymiään keskusteluja pelkästään positiivisina ja tarpeellisina. 

Sanotaan, että suunnittelijat kokevat käytettävyysarvioinnit usein "poliisityönä". Eli arvioija tulee ja arvioi toisen suunnitteluratkaisuja, ja etsii niistä ongelmia (tosin arvioijan kuuluisi toki myös kertoa vahvuuksista). 

Mutta eihän näin tietenkään tarvitse olla. Seuraava tapaus edustaa täysin päinvastaista kokemusta - oletan, että vastaavia kokemuksia on muillakin?

Arvioin ison julkisen organisaation kehitteillä olevat laajat verkkosivut. Kyseisten verkkosivujen eri alasivustojen suunnittelusta ja sisällöstä vastaavat kyseisen organisaation eri osastot. Kukin osasto oli siis tehnyt omalta osaltaan suunnitelmat alasivujen rakenteesta ja sisällöstä. 

Kävin siis sivujen suunnitteluratkaisut läpi käytettävyysnäkökulmasta. Kommunikoin näkemykseni keskustelemalla puhelimitse kunkin alasivuston vastaavan kanssa. Ja tulos oli se, että jos etukäteen pelkäsin, että minut koettaisiin poliisina, niin tuo pelko oli täysin turha. Päinvastoin, poikkeuksetta kaikki keskustelut olivat erittäin rakentavia; verkkovastaavat olivat aidosti kiinnostuneita keskustelemaan sivuista, saamaan palautetta ja ottamaan vastaan kehitysehdotuksia. Näin koin itse, ja samaa raportoivat keskustelukumppanini työni tilaajalle (verkkosivujen kokonaisvastaava). 

Eli oli erittäin mukava kokemus. Ja itse asiassa asiakkaan mielestä työni tärkein tuotos olikin nuo keskustelut (toki myös raportoin tulokset). 

Sitten se mielenkiintoinen kysymys: mistä tämä positiivinen kokemus johtui? Itse tietenkin rohkenen ajatella, että pystyin antamaan ammattimaista palautetta sekä konkreettisia ja uskottavia kehitysehdotuksia. Mutta toisaalta tulkitsen, että nuo verkkovastaavat olivat olleet varsin yksinäisiä sivujen suunnittelussa. Vähän vaikutti, että muut organisaation ihmiset ovat niin kiireisiä muissa tehtävissään, että eivät kunnolla ehtineet perehtyä sivuihin ja antaa niihin palautetta. Ja kun minä sitten analysoin sivut syvällisemmin, niin tämä perehtyminen ja palaute koettiin positiivisena. 

Jos en ollut poliisi, niin mikä sitten olin? Analogiana tulee mieleen urheiluvalmentaja, joka ulkopuolisin (ja ammattimaisin) silmin analysoi suoritusta ja neuvoo menemään eteenpäin. Ehkä jotain tällaista?

Käytettävyysjuttuja muissa blogeissa

Tämän blogin päivittämisessä on ollut jonkin verran taukoa. Sen sijaan olen kirjoitellut yleisen tason käytettävyysasioista Käytettävyysnavigoija-blogiin:

nimikkeiden pituuksista:
http://kaytettavyysnavigoija.blogspot.com/2011/05/suosi-pitkia-nimikkeita.html

käyttäjälähtöisestä tietorakennesuunnittusta
http://kaytettavyysnavigoija.blogspot.com/2011/05/kayttajalahtoinen-tietorakenne.html

Nokian käyttöliittymäkohtalon taustoista
http://kaytettavyysnavigoija.blogspot.com/2011/06/nokian-kayttoliittymakohtalon-taustat.html

mitä on käytettävyysvaikuttavuus
http://kaytettavyysnavigoija.blogspot.com/2011/06/haluttu-kaytettavyysvaikuttavuus.html

mitä ovat käytettävyysvaatimukset
http://kaytettavyysnavigoija.blogspot.com/2011/06/mita-ovat-kaytettavyysvaatimukset.html