Uusia potilastietojärjestelmiä kilpailutetaan - mutta saadaanko niistä helppokäyttöisiä?

Länsi-Uudenmaan sairaanhoitopiiri ei ota käyttöönsä Apotti- potilastietojärjestelmää, vaan aikoo kilpailuttaa oman potilastietojärjestelmänsä. Syyksi kerrotaan, että kalleutensa lisäksi Apotti ”on työntekijöiden mielestä erityisen vaikea käyttää” (HS 12.9.). Samoin Itä-Uusimaa hylkäsi Apotin.

Kannattaa kuitenkin muistaa, että kun Apotti-hankintaa käynnistettiin vuosia sitten, helppokäyttöisyys ilmoitettiin sen keskeiseksi tavoitteeksi ja kriteeriksi. Tässä kuitenkin epäonnistuttiin. Ainakin yhtenä ratkaisevana syynä se, että käytettävyyttä tavoiteltiin kilpailutuksessa samoin käytännöin kuin aiemminkin. 

Kirjoitin - pitkästä aikaa - asiasta mielipidekirjoituksen Hesariin (ks. myös kuva). 

Saa nähdä, kilpailuttavatko kyseiset sairaanhoitopiirit potilastietojärjestelmää niin, että helppokäyttöisyyttä aidosti edellytettäisiin. Jos näin tekisivät, olisivat kyllä uranuurtajia. 

Jos käytännöt näissä kilpailutuksissa pysyvät entisenlaisina, riskinä on, että myös uudet potilastietojärjestelmät osoittautuvat vaikeakäyttöisiksi. Hyvää käytettävyyttä voidaan toki näinkin saada, mutta vain hyvällä tuurilla tai kalliilla lisätilauksilla. 

Vaikuttavuus on tärkeää - mutta miten se pitäisi ottaa huomioon julkisissa hankinnoissa?

Tietojärjestelmän vaikuttavuuden mittareiden ja tavoitteiden määrittäminen on tärkeää. Niitä ei kuitenkaan pitäisi sisällyttää sellaisinaan tarjouspyyntöön vaatimuksiksi, koska vaikuttavuuden todentaminen on mahdollista vasta käytön aikana, ehkä paljonkin kehitystyön päättymisen jälkeen. Sen sijaan haluttu vaikuttavuus olisi määritettävä tarjouspyyntöön sellaisilla alemman tason vaatimuksilla, (1) joiden saavuttaminen voidaan todentaa heti kehitystyön päättyessä ja (2) joiden saavuttaminen tarkoittaa riittävän luotettavasti, että saavutetaan myös haluttu vaikuttavuus. 

Olin mukana 13.10.2022 Hankinta-yhdistyksen aamukahveilla, jonka aiheena oli Kustannusvaikuttavuuden laskenta osana hankintaprosessia. 

Aihe on sikäli kiinnostava, että itse olen korostanut käytettävyyden vaikuttavuuden määrittämisen tärkeyttä (esimerkiksi tässä Sytyke-lehden artikkelissa). Tarkoittaa sitä, että ensin pitäisi määrittää haluttu käytettävyyden vaikuttavuus, ja vasta sen jälkeen käytettävyysvaatimukset.  

Aamukahvien esimerkki: toimittajan palkitseminen vaikuttavuuden saavuttamiseksi

Aamukahvien keskustelussa kerrottiin esimerkki julkisen hallinnon tietojärjestelmähankinnasta, jossa vaikuttavuus oli otettu huomioon näin:

• Toimittajaa palkittiin sen mukaan, kuinka paljon palvelu houkuttelisi käyttäjiä. Siis mitä enemmän käyttäjiä palvelulla, sitä enemmän palkitaan toimittajaa. Muistaakseni tavoite oli 60.000 käyttäjää. 
• Tässä ei siis suoraan vaikuttavuutta mitattu rahassa, mutta vaikuttavuudesta kyse on joka tapauksessa.

Oletan, että tämä palkitsemismalli oli osana tarjouspyyntöä; tosin tästä ei ollut puhetta tilaisuudessa.

Toimittajan palkitseminen vaikuttavuusmittarilla - miksi voi olla ongelma?

Edellä mainitussa lähestymistavassa on yksi periaatteellinen ongelma. Vaikuttavuuden käyttäminen tavoitteena tai palkitsemisperusteena (tarjouspyynnössä) on ongelma sitä kautta, että vaikuttavuuden saavuttamista ei voi todentaa kehitystyön päättyessä: 

• Vaikuttavuushan tulee esiin vasta ajan myötä, kuten edellä mainitussa esimerkissä käyttäjien lukumäärä. 
• Käytännössä tarkoittaa sitä, että haluttu vaikuttavuuden saavuttaminen jää arvoitukseksi siinä vaiheessa, kun kehitystyö on päättynyt. 

Jos käy niin, että esimerkin järjestelmä ei houkuttele käyttäjiä, niin tilaajalta säästyy toimittajan bonusrahat. Mutta mitä tilaaja tekee järjestelmällä, jota käyttäjät eivät käytä?

Jos ottaa konkreettisemman esimerkin, niin moni varmaan muistaa muutaman vuoden takaisen yrityksen käyttää äänestyskonetta kunnallisvaaleissa. Sehän päättyi epäonnistumiseen, kun jotkut äänestäjät jättivät epähuomiossa äänestysprosessin kesken (kyseessä siis selkeä käytettävyysongelma...).

Kuvitellaan, että yllämainittua vaikuttavuusajattelua olisi käytetty äänestyskoneen kehittämisessä. Siis että looginen toimittajan palkitsemisen mittari olisi se, että vaalit onnistuvat äänestyskoneella. Mutta silloin ollaan jo auttamattomasti myöhässä, koska äänestyskoneen *pitää* toimia vaaleissa. Ei oikein voi ajatella niin, että toimittajan palkitsemismekanismi on se, että vaalit onnistuvat äänestyskoneella, ja samalla ottaa riski, että vaalit eivät onnistukaan. (On muuten esimerkki vaikuttavuudesta, jonka mittaaminen rahassa on vaikeaa). 

Miten sitten ottaa vaikuttavuus huomioon hankinnoissa?

Tavoitteellista pitäisi olla, että haluttu vaikuttavuus voitaisiin mitata - riittävän luotettavasti - heti kehitystyön päättyessä. 

Miten tämä voidaan tehdä? 

Ihan niin kuin yllä, aluksi hankkijan pitää määrittää vaikuttavuusmittarit- ja tavoitteet. Määritetään esimerkiksi, kuinka paljon käyttäjiä halutaan kehitettävälle järjestelmälle. Tai että äänestyskoneen on oltava sellainen, että vaalit onnistuvat. 

Sitten perusratkaisu vaatimusten määrittämiselle tarjouspyyntöön on, että määritetään sellaiset alemman tason vaatimukset, että

1. vaatimusten saavuttaminen voidaan todentaa kehitystyön päättyessä
2. vaatimusten saavuttaminen tarkoittaa riittävän luotettavasti sitä, että myös haluttu vaikuttavuus saavutetaan

Kummatkin edellämainitut esimerkit (tietojärjestelmä, äänestyskone) ovat sellaisia, joissa haluttu vaikuttavuus (paljon käyttäjiä, onnistuneet vaalit) riippuu suoraan järjestelmän käytettävyydestä. 

Alemman tason vaatimuksia olisivat silloin käytettävyysvaatimukset. Käytettävyysvaatimukset (valituilla käytettävyysmittareilla) pitää siis määrittää sellaisiksi, että niiden saavuttaminen tarkoittaa riittävän luotettavasti sitä, että kehitetyllä järjestelmällä saavutetaan haluttu vaikuttavuus järjestelmän käytön aikana. Käytännössä käytettävyysvaatimuksilla tarkoitetaan käyttäjien suoriutumiseen perustuvia vaatimuksia, niin kuin olen useassa kirjoituksessa todennut (esimerkiksi tässä). 

Hankkijan on tehtävä sisäisesti käytettävyysvaatimusten analyysi- ja määrittämistyö ennen hankintaa. Tarjouspyyntöön määritettäisiin sitten käytettävyysvaatimukset (eikä vaikuttavuusmittarit). Kyseiset käytettävyysvaatimukset olisivat sitten osa järjestelmän hyväksymiskriteereitä kehitystyön päättyessä. Ja jos käytettävyysvaatimukset on määritetty oikein, niin järjestelmällä pitäisi tulla saavuttamaan myös haluttu vaikuttavuus.  

Seitsemän (7) väärää ja neljä (4) oikeaa tapaa ottaa käyttäjät mukaan järjestelmän hankinnassa ja kehityksessä

Kirjoitin elokuussa blogikirjoituksen potilastietojärjestelmän tarjouspyynnöstä. Sen jälkeen tuli keskustelua LinkedInissä liittyen siihen, miten käyttäjien pitäisi olla mukana järjestelmien hankinnassa ja kehityksessä, ja miten ei. 

Olen kirjoittanut asiasta aiemmin seikkaperäisesti, esimerkiksi kappaleen Miten käyttäjät mukaan tietojärjestemäkehitykseen - ja miten ei? Eduskunnan tulevaisuusvaliokunnan julkaisuun Katse kohti IT-etiikkaa. 

Nyt sitten ajattelin kerrata lyhyesti: luettelo niin laadullisesti kuin eettisesti vääristä ja oikeista tavoista. 

Väärät tavat ottaa käyttäjät mukaan: 

1. Käyttäjiä pyydetään määrittelemään järjestelmän ominaisuuksia ja kertomaan mielipiteitä tulevasta järjestelmästä 
2. Käyttäjiä pyydetään määrittelemään vaatimukset järjestelmälle 

3. Suunnitellaan yhdessä käyttäjien kanssa
4. Käyttäjiä pyydetään antamaan käyttöliittymistä laadullisia ”asiantuntija-arviointeja” 

5. Käyttäjiä pyydetään katselmoimaan käyttöliittymiä 
6. Käyttäjiltä kysytään ehdotuksia paremmiksi suunnitteluratkaisuiksi 
7. Käyttäjät laitetaan pisteyttämään järjestelmän käytettävyys toimittajien esittämien demojen perusteella 

Oikeat tavat ottaa käyttäjät mukaan:

1. Sisällölliset haastattelut: käyttäjiltä haastatellaan heidän työstään tai ammattiosaamisestaan 
2. Käyttäjiä havainnoidaan heidän työssään 
3. Käyttäjiä pyydetään käytettävyystestien testihenkilöiksi 
4. Käyttäjiltä kysytään heidän käyttökokemuksestaan 

Jos nämä vetää yhteen periaatteiksi, niin voisi tiivistää, että käyttäjät otetaan mukaan laadullisesti ja eettisesti oikein, kun  

• Käyttäjien ei pidä olla missään muussa roolissa kuin oman ammattinsa ja työtehtävänsä edustajana (käyttäjät ovat siis ainoastaan omalla mukavuusalueellaan)
• Käyttäjiä ei pidä vastuuttaa mistään asiasta järjestelmän hankinnan ja kehitystyön aikana; ei esimerkiksi siitä, että osaavatko jäsentää haastatteluissa vastauksiaan oikein ("oikeat tavat" kohta 1). Kaikki vastuu suunnitteluratkaisujen  - ja myös vaatimusten - oikeellisuudesta on aina suunnittelutiimillä. 

Jos kiinnostaa, miten tehdään tuloksellisesti ja tehokkaasti sisällöllisiä haastatteluja ("Oikeat tavat" kohta 1),  olen kirjoittanut menetelmästä kirjan Kohdemaailma-analyysi. Menetelmässä kerrotaan, miten haastatella asiakkaita niin, että saadaan nopeasti syvällinen ymmärrys asiakkaan tarpeista samalla, kun haastateltavia kohdellaan eettisesti oikein. 

PS. Jos sinulla on kommentoitavaa ym. oikeisiin ja vääriin tapoihin (tai muuten kirjoitukseen), niin mielellään sellaisia kuulisin!

Lappican potilastietojärjestelmän tarjouspyyntö: ei uutta käytettävyyden suhteen

Lapin alueella toimiva Lappica Oy on tehnyt tarjouspyynnön potilastietojärjestelmästä. Tavoitteena on hankkia "helppokäyttöinen" järjestelmä. Kun tutkii tarjouspyynnön sisältöä, siinä ei kuitenkaan käytännössä edellytetä helppokäyttöisyyttä. Sinällään tämä ei ole yllättävää: kun isommatkaan hankintayksiköt eivät osaa aidosti vaatia käytettävyyttä tarjouspyynnössä, miten pienehköllä hankintayksiköllä olisi edellytyksiä olla uranuurtaja. 

HUOM! Korostan vielä, että tätä analyysia ei pidä ottaa erityiseksi kritiikiksi Lappica Oy:ta kohtaan. Tarjouspyyntö sattui vain osumaan silmääni, kun kyse on potilastietojärjestelmästä. Olen seurannut aika tiiviisti Apotti-potilastietojärjestelmän hankintaa (monet kirjoitukset tässä blogissa, ja esimerkiksi Helsingin Sanomissa). Otin tämän tarjouspyynnön tarkasteluun ihan tämän kiinnostuksen pohjalta. 

Mistä kyse

Pääkaupunkiseudun Apotti-potilastietojärjestelmän käytettävyysongelmat ovat tunnettuja. Nyt Apotista on tekeillä jopa kantelu. 

Keskeinen syy Apotin käytettävyysongelmiin on se, että vaikka käytettävyyttä pidettiin lähtökohtaisesti erittäin tärkeänä asiana, sitä ei edellytetty oikealla tavalla tarjouspyynnössä (analyysia esimerkiksi tässä). Käytettävyys oli kyllä keskeisenä laatutekijänä tarjouspyynnössä, mutta ei sillä tavalla, että se olisi aidosti sitonut toimittajaa tuottamaan hyvää käytettävyyttä. 

Nyt sitten osui sattumoisin silmiini uusi potilastietojärjestelmän kilpailutus, kun Lapin sairaanhoitopiirin tarjouspyyntö on julkaistu (luettavissa luultavasti 15.8.2022 asti, jolloin on tarjousten viimeinen jättöpäivä). 

Kun kyseessä on potilastietojärjestelmä, tarjouspyyntö kiinnosti sen verran, että analysoin sitä seuraavassa käytettävyyden kannalta. 

Miten käytettävyys määräytyy yleensä tarjouspyynnöissä?

Tarjouspyynnössä halutun käytettävyyden tason määrittä kaksi asiaa: 

• miten käytettävyysasioita vaaditaan pakollisissa vaatimuksissa
• miten käytettävyysasioita on sisällytetty vertailuperusteisiin, ja mitkä ovat näiden painoarvot vertailussa

Valintaprosessi menee sitten lyhyesti ilmaistuna: 

    1. Tarkistetaan, täyttyvätkö pakolliset vaatimukset: 

• Jos täyttyvät, tarjous etenee vertailuvaiheeseen
• Jos eivät täyty, tarjous tipahtaa pois kilpailutuksesta

    2. Lasketaan yhteen vertailupisteet. Tarjouskilpailun voittaja on se, joka saa eniten vertailupisteitä. 

Käytännössä keskeisin asia on se, miten käytettävyys on määritetty pakollisiin vaatimuksiin. Hyvin valmistellussa tarjouspyynnössä kaikki käytettävyysasiat on pakollisissa vaatimuksissa. Vain erityisissä tapauksissa käytettävyysasioita on perusteltua laittaa vertailuperusteisiin. 

Lappican tarjouspyynnön sisällön kuvausta

Tarjouspyynnön johdanto-osassa lukee esimerkiksi: 

"Tavoitteena on saada käyttöön helppokäyttöinen, käyttäjää ohjaava ja ammattilaisten työtä helpottava työterveyshuollon järjestelmä. Järjestelmän perustoiminnallisuuksien pitää olla joustavia ja käyttäjien muokattavissa...  Järjestelmän pitää tukea ja helpottaa yhteistyötä työnantaja-asiakkaiden kanssa. Työnantajaorganisaatioiden rakenteen ja näkymien tulee olla käyttäjäystävällisiä ja selkeitä. Ajanvarauksessa ja vastaanotolla tulee organisaatioiden ja potilaiden taustatietojen olla selkeästi ja vaivatta saatavilla."

Tällä perusteella käytettävyys on hankkijalle tärkeä asia.

Mutta. On huomattava, että tällaisella epäformaalilla johdantotekstillä ei ole mitään merkittävyyttä kilpailutuksessa. Toimittajien ei kannata kiinnittää tällaiseen mitään huomiota, koska tällaiset yleiset tavoitteet eivät vaikuta voittajan valintaan millään tavalla, eivätkä velvoita voittajaa mihinkää niitä ratkaisun kehittämisessä.  

Mitä käytettävyysasioita vaaditaan tarjouspyynnössä?

Tässä tarjouspyynnössä vertailuperusteet ovat:

• laadulliset vaatimukset 40 pistettä, joista
• "pisteytettävät vaatimukset" 35 pistettä 
• projektisuunnitelma 5 pistettä
• hinta 60 pistettä
• (yhteensä 100 pistettä)

"Pisteytettävät vaatimukset", samoin kuin pakolliset vaatimukset on esitetty samassa, isossa excel-taulukossa

• pakolliset vaatimukset tarkoittavat, että toimittajan on pakko täyttää ne (muuten tipahtaa pois kilpailutuksesta)
• pisteytettävät vaatimukset tarkoittavat, että toimittajan ei ole pakko niitä täyttää, mutta niiden täyttäminen tarkoittaa enemmän pisteitä vertailuperusteisiin ja sitä kautta paremmat mahdollisuudet voittaa kilpailutus

Yksittäisiä vaatimuksia - pakollisia ja pisteytettäviä - on yhteensä muutamia satoja.  Excel-taulukko sisältää noin 15 välilehteä, joihin on vaatimukset on luokiteltu aiheittain: Työterveyshuolto, Ajanvaraus, Ilmoittautuminen,  Lausunnot ja lähetteet jne. 

Ja on siellä sitten yksi välilehti nimeltään Käyttäjälähtöisyys. Alla kuvankaappaus taulukon ko. kohdasta.

Sisältäänkö tarjouspyyntö käytettävyysvaatimuksia?

Käytettävyys tarkoittaa lyhyesti ilmaistuna sitä, missä määrin käyttäjät onnistuvat saavuttamaan tavoitteensa. Tarkemmin käytettävyyden määritelmästä esimerkiksi täällä.

Kun tarkastelee "Käyttäjälähtöisyys" -vaatimuksia, niin useimmissa vaatimuksissa lukee, että jokin asia

• "pitää voida tehdä" 
• "pitää olla mahdollista" 
• "pitää päästä tekemään" 
• tms. 

Tällaiset muotoilut tarkoittavat yleensä toiminnallisia vaatimuksia eivätkä käytettävyysvaatimuksia. Ja nämä ovat eri asioita. 

Toiminnallinen vaatimus kertoo, millainen ominaisuus pitää järjestelmässä olla, kun taas käytettävyysvaatimus määrittää, missä määrin käyttäjien pitää onnistua järjestelmän käytössä. Se, että onko jokin vaatimus käytettävyysvaatimus vai toiminnallinen vaatimus, voidaan todeta yksinkertaisella kysymyksellä: 

Voiko vaatimuksen täyttää niin, että sen toteutus on vaikeakäyttöinen? 

Jos vastaus on kyllä, niin kyseessä ei ole käytettävyysvaatimus. 

Otetaan esimerkiksi yllä olevasta taulukosta vaatimus Käy_03: PTJ:ssä on sisäinen ohjeistus hakutoiminnolla. Kysytään sitten,  voiko kyseisen vaatimuksen täyttää siten, että toteutus on vaikeakäyttöinen? 

Vastaus on, että (tietenkin) voi. Vaikka ohjeet ja hakutoiminta ovat sinällään käyttäjän kannalta hyviä toimintoja, niiden olemassaolo ei ole itsessään sama kuin käytettävyys. Ne kun on periaatteessa mahdollista toteuttaa kuinka vaikeakäyttöisiksi.  

Huom. Tämä ei tietenkään tarkoita sitä, että toimittaja suunnittelisi ohjeiston tietoisesti vaikeakäyttöiseksi. Mutta jos tarjouspyyntö ei aidosti edellytä käytettävyyttä, niin se tarkoittaa, että toimittajan ei kannata kiinnittää käytettävyyteen huomiota, koska se lisäisi kehityskustannuksia ja sitä kautta huonontaisi mahdollisuuksia voittaa tarjouskilpailu. 

Ainoastaan taulokon viimeinen vaatimusta - Käy_36: Tutkimustulosten ja lähetteiden palautteiden siirtyy automaattisesti sijaistajalta seuraavalle sijaistajalle - voi pitää käytettävyysvaatimuksena. On tietenkin  parempaa käytettävyyttä, jos jokin toiminto tehdään automaattisesti ilman, että käyttäjän tarvitsee tehdä mitään. 

Jos ottaa esiin toisen piirteen vaatimuksista, niin yksi käyttäjäryhmä nousee ylitse muiden: peräti 8 vaatimuksen käyttäjäryhmä on pääkäyttäjät. Käytettävyyden kannalta tietenkin pitäisi keskittyä "tavallisiin" loppukäyttäjiin, joita tässä tapauksessa ovat työterveydenhuollon henkilökunta ja järjestelmää käyttävät yritysten edustajat. 

Pakolliset vaatimukset vs. pisteytettävät vaatimukset

Kun en ole työterveyshuollon asiantuntija, niin minun on vaikea arvioida, ovat kaikki pakolliset vaatimukset todellakin välttämättömiä. Tai toisaalta, ovatko jotkut pisteytettävät vaatimukset sellaisia, jotka pitäisivät olla pakollisia. Joka tapauksessa ne ovat nähtävästi hyödyllisiä, koska niistä saa vertailupisteitä.   

Yleisesti tällainen jako on vähän keinotekoinen. Parempi ratkaisu olisi yksinkertaisesti, että kaikki vaatimukset olisivat pakollisia. Ja pisteytettäviä vaatimuksia käytettäisiin vain hyvin harkitusti sellaisissa tapauksissa, joissa hyvin tullaan toimeen kyseisiä ominaisuuksia mutta joiden olemassa olosta kannattaa maksaa vähän enemmän. 

Muut vaatimuskategoriat

Tarjouspyynnössä on siis noin 15 samantyyppistä vaatimuslistaa kuin Käyttäjälähtöisyys -vaatimukset. 

Hyvin monessa julkisessa tarjouspyynnössä käytettävyysvaatimuksia on paljon muuallakin kuin mahdollisessa käytettävyysosiossa. Niin luultavasti tässäkin. Tätä blogia varten en käynyt systemaattisesti läpi muiden osioiden vaatimuksia, mutta esimerkiksi seuraavia käyttäjiin liittyviä osui silmään: 

• Käyttäjät voivat valita valmiin kalenteripohjan kalenterimallista tai luoda oman kalenteripohjan erilaisia aikatyyppejä käyttäen
• Ammattilainen voi tarkastella PTJ:n ajanvarausnäkymässä olevia aikatauluja esimerkiksi päivä- ja viikkokohtaisesti
• Lääkärillä on oltava tieto uudistamista odottavien lääkemääräysten uudistuspyynnön voimassaolosta

Nämäkin ovat siis käytännössä toiminnallisia vaatimuksia: järjestelmä voi täyttää tällaiset vaatimukset, vaikka ne olisivat vaikeakäyttöisesti toteutettu. 

Yhteenveto

Johtopäätös on, että Lappican tarjouspyyntö ei millään tavalla takaa, että valituksi tulisi sellainen järjestelmä, joka on esitetty tavoitteeksi tarjouspyynnön johdannossa: 

"helppokäyttöinen, käyttäjää ohjaava ja ammattilaisten työtä helpottava... Työnantajaorganisaatioiden rakenteen ja näkymien tulee olla käyttäjäystävällisiä ja selkeitä. Ajanvarauksessa ja vastaanotolla tulee organisaatioiden ja potilaiden taustatietojen olla selkeästi ja vaivatta saatavilla".

Mutta. Eipä tämä tarjouspyyntö ole sen huonompi käytettävyyden osalta kuin julkisen hallinnon tarjouspyynnöt yleensäkään. 

Ja itse asiassa tässä tarjouspyynnössä on hyviäkin puolia: 

• Tarjousten käsittely ei vie käytettävyyden osalta paljon resursseja - katsotaan vain, mitä tarjoajat ovat ruksanneet. Joissakin kilpailutuksissa käytettävyysvaatimusten osalta on hyvinkin raskaita testejä ilman, että lopputulos on sen kummempi. Hyvänä esimerkkinä pääkaupunkiseudun paikallisliikenteen matkakortin lukija, jossa massiivisista testeistä huolimatta lopputuloksessa oli jopa ihan perustason käytettävyysongelmia. Lue tästä lisää.

• Laatutekijöiden painoarvo vertailuperusteissa oli "vain" 40%. Hyvin laaditussa tarjouspyynnössä laatutekijöiden painoarvon pitäisi olla lähellä nollaa, joka tapauksessa korkeintaan 20%. Mutta pahimmillaan on tarjouspyyntöjä, joissa laatutekijöiden painoarvo on peräti 70%. (Päinvastoin kuin usein luullaan, laatu vertailutekijöissä nimenomaan ei takaa tuotteen laatua). Eli siinäkään mielessä tämä tarjouspyyntö ei missään tapauksessa ollut pahimmasta päästä. 

Mikä olisi oikea tapa sisällyttää käytettävyys tarjouspyyntöön?

Jotta tarjouspyyntö edellyttäisi aidosti käytettävyyttä, niin 

• Käytettävyys olisi sisällytettävä pakollisiin vaatimuksiin. Vain erityistapauksissa käytettävyyttä voisi olla valintakriteereissä, ja silloinkin korkeintaan pienellä painoarvolla. 
• Käytettävyysvaatimukset olisi määritettävä suhteessa käyttäjien suoriutumiseen.  Silloin, kun käyttäjät suoriutuvat tehtävistään riittävän hyvin, järjestelmä on käytettävyydeltään hyvä. 

Miten sitten määritetään käytettävyysvaatimukset suhteessa käyttäjien suoriutumiseen? Sitä varten tarvitsee määrittää

• mittarit: millä mittarilla mitataan käyttäjien suoriutumista
• tavoitetasot: mikä mittaustulos ko. mittarilla on riittävän hyvä
• mittausinstrumentit: miten mittaus käytännössä suoritetaan (yleensä tämä tarkoittaa käyttäjätestejä, mutta ei välttämättä)

Ja vielä pitää ottaa huomioon, että mitkä tahansa mittarit, tavoitetasot ja instrumentit eivät kelpaa. Käytettävyysvaatimusten on oltava

• valideja: vaatimusten on aidosti kuvattava haluttua käytettävyyttä
• riittävän kattavia: niin, että vaatimukset ottavat huomioon riittävästi erilaiset käyttäjät ja heidän erilaiset käyttötarpeensa
• (tähän luetteloon yleensä kuuluva todennettavuus tuleekin täytetyksi sitä kautta, että määritetään mittarit ja mittausinstrumentit)

Olen kirjoittanut näistä asioista useammassa tämän blogin kirjoituksessa, ja pitänyt myös kursseja. Ehkä kirjakin on tulossa tässä lähiaikoina. Yksi yhteenvetovideo tässä.  

--------

Vastaus Sepon alla olevaan kommenttiin 

(blogialusta ei antanut tehdä pitkää kommenttia, niin kirjoitan sen tähän): 

Seppo: "1. Jos järjestelmää ollaan vasta tilaamassa, eikä se ole millään tarjoajalla vielä valmiina, niin miten käytettävyyttä voi arvioida? Käytännössä kai nämä järjestelmät rakennetaan aika suurelta osin vasta sitten, kun tilaus on saatu. Järjestelmistä lienee yleensä olemassa ”backend” eli tiedostojärjestelmä, joka ehkä on joissain toimitetuissa järjestelmissä pohjalla, mutta itse näkyvä osa eli käyttöliittymä tehdään vasta, kun tilaajalta saadaan siihen toiminnalliset vaatimukset. Ja siten käytettävyyttä pystytään mittaamaan vasta jälkeenpäin. Jos tarjouspyynnössä on käytettävyysvaatimuksia, niin kaikki tarjoajat voivat sanoa ”joo, me täytetään nuo kyllä sitten”, mutta vertailua ei pysty tarjousvaiheessa tekemään."

Timo: Muutama huomio tähän: 

a) Tässä nyt on eri vaihtoehtoja, riippuen siitä, kuinka valmista järjestelmää ollaan tilaamassa. Tässä videossa selitän vähän asiaa https://www.youtube.com/watch?v=WJHHExdIwlU. 

"b) ”Jos tarjouspyynnössä on käytettävyysvaatimuksia, niin kaikki tarjoajat voivat sanoa ”joo, me täytetään nuo kyllä sitten””. Niin, mielestäni vaatimukset pitää olla toimittajia sitovia. Jos ei täytä vaatimuksia, tilaajan ei tarvitse hyväksyä toimitusta. En tiedä onko toimittajat tällaiseen tottuneet, mutta jos oikeasti halutaan käytettävyyttä edistää, niin jotain tällaista pitää tehdä. 

c) ”Vertailua ei pysty tarjousvaiheessa tekemään”. Niin, pointti on se että vertailuja ei tehdä. Vaan testataan, täyttääkö järjestelmä vaatimukset. Käytettävyys on siis pakollisena vaatimuksena. 

 

Seppo: "2. Tai sitten pitäisi jo tarjousvaiheeseen sisällyttää tehtävä, jossa tarjouskilpailuun osallistujan pitää toimittaa jokin ”sample”, jolle on annettu täsmälliset arviointkriteerit. Tässä on ainakin se ongelma, että jonkin pienen palikan tekeminen käytettäväksi voi olla helppoa verrattuna koko järjestelmään, koska sen ei silloin tarvitse toimia koko järjestelmän kanssa yhteen, mutta siinä ei silloin myöskään luultavasti näy, miten hyvä koko järjestelmä on käytettävyydeltään silloin, kun kaikki osat oikeasti ovat olemassa."

Timo: Tässä olet ihan oikeassa. Käytettävyysvaatimuksilla on kolme pääkriteeriä: niiden itää olla validit, todennettavat ja riittävän kattavat. Ja tuo jälkimmäinen tarkoittaa juuri sitä mitä kommentoit.

Seppo: "3. Käytettävyyskriteerien pitäisi olla hyvin tarkat, ja niiden pitäisi kattaa periaatteessa koko systeemi. Muuten tulos voi olla se, että vaaditut osat täyttävät vaatimukset, mutta muut osat ovat sutta ja sekundaa. Käytettävyys kun on asia, jossa jokaisen lenkin pitää olla kunnossa, tai homma ei toimi."

Timo: Kylläpä näin. Ks. edellisen kohdan kommenttini. 

Seppo: "Sitten hieman sivuun tästä tarjouspyyntöasiasta. Olen seuraillut näitä tietojärjestelmäuutisia ja lukenut myös tutkimusartikkeleita. On alkanut muodostua sellainen käsitys, että iso osa ongelmaa on siinä. että järjestelmissä on rakenteinen tietokanta, jossa kaikki diagnoosit ja muut tiedot pitää luokitella tarkasti. Tämä johtaa siihen, että käyttäjät saavat eteensä loputtomasti valikoita ja ruudukoita, joista pitää klikkailla oikeat vaihtoehdot, jotka sitten tallentuvat järjestelmään. Vaikka käyttöliittymäsuunnittelijat tietenkin pyrkivät tekemään kaikista näkymistä mahdollisimman käytettäviä, niin näkymiä on vain liikaa ja niissä liikaa läpi käytäviä kohtia. Tämä lomakkeiden täyttely vie kohtuuttomasti aikaa verrattuna vanhaan systeemiin, jossa lääkäri saneli potilaan epikriisin suoraan proosana. Tästä monimutkaisuudesta pitäisi päästä eroon, mutta kuitenkin niin, että järjestelmään tallentuisi täsmällinen tieto, joka myös olisi käytettävissä myöhemmin. Arvelen, että tekoäly jossain muodossa olisi tässä mahdollinen ratkaisu: lääkäri voisi sanella vastaanoton jälkeen potilastapaamiseen liittyvät asiat, ja tekoäly tulkitsisi ja muodostaisi sanelusta rakenteisen datan, jonka lääkäri sitten vain tarkistaisi, ja se menisi tietokantaan."

Timo: Ihan mielenkiintoisia ajatuksia. Itse kyllä olen ajatellut, että rakenteinen tietokanta on hyvä lähestymistapa. Ja olettanut, että paremmalla suunnittelulla ne voitaisiin saada käytettävyydeltään hyviksi. Mutta. Minulla ei ole käytännön kokemusta niistä, enkä osaa varmuudella sanoa mitään.  

Haastattelussa vuodelta 2017 kerron käytettävyyden keskeiset periaatteet tiivistettynä

Haastattelu "Laitteiden huono käytettävyys ärsyttää" julkaistiin IT-lehdessä (Invalidiliitto) vuonna 2017 (nro 2). Laitan sen nyt tähän blogiin, koska siinä tiivistän monia keskeisiä mutta usein sivuutettuja käytettävyyden suunnittelun periaatteita: 

• käytettävyys on suunnittelijoiden vastuulla
• kohdemaailma pitää olla suunnittelijoiden hallussa 
• käytettävyys ei perustu käyttäjien mielipiteisiin vaan suunnittelijan ammattitaitoon
• käyttäjähaastatteluissa pitää keskittyä faktoihin, ei mielipiteisiin
• vihje käyttäjille: älä vastaa, jos sinulta kysytään "millaisia ominaisuuksia haluat uuteen järjestelmään"
• "tunne asiakkaan maailma paremmin kuin hän itse" pitäisi olla tavoite (ei ole vaikea saavuttaa!)
• hankinnoissa "saa sellaista käytettävyyttä mitä tilaa"; jos ei osaa tilata, niin saa mitä sattuu

Klikkaamalla kuvaa pääset lukemaan koko haastattelun. 

Kirjoitukseni Helsingin sanomissa

Olen kirjoitellut vuosien varrella useammankin kerran Helsingin sanomiin. Useimmat kirjoitukset käsittelivät tietojärjestelmien helppokäyttöisyyttä julkisissa hankinnoissa. 

Perustatavoitteena minulla oli, että julkiset hankkijat muuttaisivat käytäntöjään ja tekisivät tarjouspyyntönsä niin, että niissä aidosti vaadittaisiin käytettävyyttä toimittajilta. (enpä tässä tainnut onnistua muutoksen tekemisessä...)

Lisäksi myös muutama kirjoitus Nokiasta ja yhteiskunnallisista teemoista. 

Alla kokoelma kirjoituksista, osittain oman muistinikin virkistykseksi. Linkeistä avautuvat niin kuvankaappaukset painetusta lehdestä kuin verkossa olevat tekstit. Linkit olivat alkujaan suoraan Hesariin, mutta koska ko. linkit näyttävät vanhentuvan ajan myötä (eivät enää vie artikkeleihin), niin linkit vievät omaan arkistooni.   

Ammatilliset 

9.11.2011: Atk-hankinnoissa vastuu kuuluu tilaajalle

Tässä vieraskynäkirjoituksessa tuon esiin se, että julkisissa hankinnoissa vastuu käytettävyydestä on viime kädessä hankkijoilla. Toimittajat eivät tee sen parempaa käytettävyyttä kuin mitä hankkijat tarjouspyynnöissään vaativat. 

1.7.2012: Helppokäyttöisyyttä on osattava vaatia

Tämä vieraskynäkirjoitus on kohdistettu suoraan Apotin hankintaprojektiin. Pääsanomani on, että käytettävyys pitäisi määrittää pakollisissa vaatimuksissa. (Jälkikäteen voidaan todeta, että näin ei Apotissa tehty.)

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

Julkisuudessa on tuotu esiin, että Apotin koulutuskustannukset ovat korkeat. Tuon esiin sen ristiriidan, että jos Apotin sanotaan olevan helppokäyttöinen, niin silloin koulutukseen ei pitäisi tarvita paljon resursseja. 

17.4.2013: Julkiset hankinnat eivät suosi halpaa

Usein väitetään, että huono laatu johtuu siitä, että "hinta ratkaisee" tietojärjestelmien hankinnoissa. Kuitenkin hinnan painoarvo valintakriteereissä on usein varsin alhainen. Vastoin yleistä ymmärrystä, jos halutaan laatua, niin hyvin laaditussa tarjouspyynnössä hinnan painoarvo on korkea. 

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

Jotta järjestelmät saataisiin aidosti helppokäyttöisiksi, ratkaisuna on käytettävyyden aito vaatiminen tarjouspyynnöissä. Tällaiseen käytännön muuttamiseen ei kuitenkaan näytä olevan halua. 

17.10.2014: Mistä Nokian alamäki johtui?

Nokian alamäki ei ehkä johtunutkaan siitä, että Nokia ei kuunnellut käyttäjiä. Vaan siitä, että uskottiin käyttäjiä väärällä tavalla ilman, että johdolla oli oikeaa visiota. 

24.3.2015: Helppokäyttöisyyttä pitää osata vaatia

Järjestelmiä ei saada helppokäyttöisiksi triviaaleilla toimenpiteillä kuten edellyttämällä käyttäjien mukanaoloa kehityksessä ja kysymällä heidän mielipiteitään. 

30.8.2016: Gradun tekeminen on periaatteessa yksinkertaista

Gradun tekemisen vaikeutta liioitellaan; gradun tekeminen on periaatteessa looginen ja yksinkertainen prosessi. Esitän gradun tekemisen kolme päävaihetta.  

22.1.2017: HSL ei tilannut helppokäyttöistä laitetta

Kommentoin sitä ristiriitaa, että vaikka HSL:n uuden matkakortinlukijan eteen tehtiin paljon käyttäjäkeskeistä suunnittelua, niin lopputuloksessa oli jopa triviaaleja käytettävyysongelmia. 

18.4.2018: Tuliko Apotista vaikeakäyttöinen?

Kommentoin sitä ristiriitaa, että Apotin koulutuksen kerrotaan vaativan paljon resursseja, vaikka Apotin piti olla helppokäyttöinen. 

1.8.2019: Palveluille pitää määrittää riittävä laatu

Laatua ei saavuteta korkeammalla hankintahinnalla tai hintarajalla vaan riittävän laadun määrittämisellä. Tästä seuraa nurinkuriselta vaikuttava lopputulema: jos julkisissa hankinnoissa haluaa hyvää laatua, valinnan tuleekin ratkaista viime kädessä hinta.

Yhteiskunnalliset

31.10.2014: Avoimmuutta keskusteluun

Kommentti avioliittolakikeskusteluun. 

6.11.2014: Nykyinen avioliittolaki ei ole syrjivä

Kommentti avioliittolakikeskusteluun. 

4.9.2017: Yhteiskunnan arvot ovat muuttuneet

Kommentti Antti Rinteen "synnytystalkoisiin". 

Apotissa karmea väärinkäsitys käytettävyydestä, Oulussa ymmärretään oikein?

Lähtökohta

Tämä kirjoitus on osittain hypoteesia, koska se perustuu rajattuun tietoon. Apotissa kyseessä on kommentti LinkedInissä, Oulun tapauksessa uutisen otsikko. 

Aloin kirjoittaa Apotista sen vuoksi, että Apotissa (mahdoliisesti) tehty asia on käytettävyyssuunnittelun näkökulmasta totaalisesti väärä. Mutta täysin looginen ja mahdollinen. Jos ei Apotissa, niin jossakin toisessa hankkeessa. Joka tapauksessa sellainen, josta mielestäni on syytä varottaa mitä tahansa hanketta.

Uutinen Oulussa kehitetystä Esko-potilastietojärjetelmästä osui silmiin sen jälkeen, kun olin kirjoittanut jutun kertaalleen. Ja Oulussa taas mennään uutisotsikon oikealla periaatteella. Lisäsin loppuun vähän tekstiä Oulun tapauksesta. 

Taustaa

Käytettävyydessä ja käyttäjäkeskeisessä suunnittelussa* käyttäjien mukanaoloa kehityshankkeessa korostetaan. Termi ”käyttäjäkeskeinen suunnittelu” itsessään antaa kuvan, että käyttäjät ovat suunnittelun keskiössä. 

Käyttäjäkeskeisyys ja käytettävyys tarkoittaa toki käyttäjien osallistumista kehityshankkeeseen, mutta ei millä tavalla tahansa. Esimerkiksi näkee väärinymmärryksiä, kuten 

• Käytetään termiä käyttäjien ”osallistaminen”. Sisältää ajatuksen, että käyttäjillä olisi jokin erityinen velvollisuus olla mukana kehityshankkeessa (ei näin, koska usein käyttäjät eivät halua). http://kaytettavyysnavigoija.blogspot.com/2017/03/millainen-pitaisi-olla-jarjestelmien.html  
• Kysytään käyttäjien mielipiteitä suunnittelun pohjaksi. http://kaytettavyysnavigoija.blogspot.com/2017/09/oikeaa-kayttajalahtoisyytta-ei-ole.html  
• Suunnitellaan käyttöliittymää yhdessä käyttäjien kanssa
• Laitetaan tekemään asiantuntija-arviointeja http://kaytettavyysnavigoija.blogspot.com/2018/10/kaytettavyyden-asiantuntija-arviointi.html 
• Palkataan käyttäjiä mukaan kehityshankkeseen http://kaytettavyysnavigoija.blogspot.com/2017/03/laakari-ottaa-esiin-kaksi-tarkeaa.html  
• käyttäjät pisteyttämään käytettävyyttä (julkisissa hankinnoissa)
• jne jne

Nämä kaikki on ”pahoja” väärinymmärryksiä käytettävyydestä ja käyttäjälähtöisyydestä. 

Millainen oli Apotin (mahdollinen) väärinkäsitys käytettävyydestä?

Edellä mainitut väärikäsitykset kalpenevat sen rinnalla, mitä Apotissa mahdollisesti tehtiin. (Toistan, tämä tästä eteenpäin on hypoteesia, koska perustuu rajattuun tietoon). Apotissa (mahdollisesti) tehtiin sellaista käytettävyyden nimissä, että en ollut ennen nähnyt eikä oma mielikuvitus ollut siihen riittänyt. 

Apotissa (mahdollisesti) valittiin käytettäyys strategiaksi, "jotta saataisiin rajatuksi muut kuin lääkärit pois hankkeen avainhenkilöistä" (tämä on se kommentti LinkedInissä). 

Kun kyseessä oli potilastietojärjestelmä, niin lääkärit ovat käyttäjiä; mutta tämä ei itsessään ole oleellista. Pointti siis se, että käyttäjäkeskeisyys (mahdollisesti) tulkittiin tarkoittavan, että käyttäjät pitäisi olla hankkeen avainhenkilöitä. 

Siis niin väärin kuin mahdollista verrattuna aitoon käyttäjäkeskeisyyteen.  

Miksi Apotissa (mahdollisesti) tehtiin näin? 

Syytä en tiedä. Mutta pidän täysin mahdollisena, että tällaisen väärinkäsityksen syyt ovat Apotin ulkopuolisia. 

Kuten alussa mainitsin, monesti korostetaan erityisesti käyttäjien mukanaoloa. Yksinkertaisesti, jotkut voivat tulkita termin "käyttäjäkeskeinen suunnittelu" siten, että "mitä enemmän käyttäjille valtaa kehitystyössä, sitä parempi"*.   

On siis oikeita ja vääriä tapoja ottaa käyttäjät mukaan. Jos käyttäjien oikeat roolit jätetään mainitsematta, niin tästä sitten asiaan perehtymätön voi tehdä johtopäätöksen, että ”mitä enemmän käyttäjät mukana, sen parempi”. Voi olla, että tämä yksioikoinen ja harhaanjohtava käsitys käytettävyydestä ja käyttäjäkeskeisyydestä sai jalansijaa sitten myös Apotissa. 

Mutta niin pitkälle en ole aiemmin nähnyt missään mentävän, että avainhenkilöt olisivat tällä perusteella nimetty käyttäjistä. Jos Apotissa tehtiin näin perusteena ”käytettävyys”, niin on ollut karmea väärinkäsitys käytettävyydestä. Aito käyttäjäkeskeisyys kun on sitä, että käyttäjät ovat mukana ainoastaan omassa roolissaan - oman alansa asiantuntijoina ja käyttäjinä - eivätkä minkäänlaisessa vastuussa järjestelmän kehittämisestä ja laadusta. 

Oulun Esko-potilastietojärjestelmän käyttäjälähtöisyys näyttää oikeaoppiselta

Uutisotsikko sanoo: ”Tämä porukka tuntee suomalaisen terveydenhuollon”. Otsikko (en näe itse juttua, kun se on maksumuurin takana) sanoo kyllä aika mielenkiintoista. Jos Eskoa tosiaan kehittää IT-ammattilaiset siltä pohjalta, että ymmärtävät asiakkaan maailman, niin ollaan oikealla tiellä. 

Tietääkseni Eskon kehitystiimillä on vuosien kokemus aihealueesta. Mutta periaatteessa syvällisen perehtymisen asiakkaan maailmaan voi tehdä hyvinkin nopeasti, kuten kirjassani Kohdemaailma-analyysi kerron. 

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

PS. Olen yrittänyt tuoda esiin perussanomaa käyttäjien oikeasta roolista jo vuosia. Myös joissakin terveydenhuollon järjestelmien seminaareissa. 

Eräässä terveydenhuollon tietojärjestelmäseminaarin esityksissäni totesin jo vuosia sitten, että ”lääkärien mielipidettä ei pitäisi kysyä” tietojärjestelmien suunnittelussa (ks. kuva alla). Minulla on sellainen käsitys, että tämä on tulkittu siten, että en jotenkin arvostaisi lääkärien mielipiteitä. Tästä siis ei ole ollut lainkaan kyse. Pointtini siis on se, että yleensäkään käyttäjien mielipidettä ei pitäisi kysyä, kattaen kaikenlaisten järjestelmien kehityksen ja kaikenlaiset käyttäjät. 

Apotin kaksi virhettä: Vastine saamiini palautteesiin

Apotin kehityksessä oli ollut mukana käyttäjiä, käytettävyysammattilaisia, oli määritetty käytettävyysvaatimuksia sekä oli tehty käytettävyysvertailuja ja -arviointeja. Apotin - kuten minkään muunkaan järjestelmän - käytettävyyden onnistumisen arviointiin tämän tasoiset tiedot eivät kuitenkaan riitä. Onnistumisen arviointiin tarvitaan tarkempaa tietoa käytetyistä käytettävyysmittareista, tavoitetasoista, ja siitä, miten nämä oli johdettu. Rakenteinen kirjaaminen on toimiva lähtökohta. 

Sain aika paljon palautetta edellisestä Apotti-kirjoituksestani. Erityisesti sain kommentteja LinkedInissä. Sain myös suoraa palautetta Apotilta.

Edellinen kirjoitukseni perustui niihin tietoihin, joita Helsingin sanomien artikkelissa kerrottiin. Nyt sain enemmän tietoa siitä, mitä Apotissa tehtiin käytettävyyden eteen: mukana oli ollut käyttäjiä, käytettävyysammattilaisia, oli määritetty käytettävyysvaatimuksia, oli tehty käytettävyysvertailuja ja -arviointeja.

Tällaiset toimenpiteet ovat tärkeitä, mutta itsessään "eivät takaa mitään". On lukuisia esimerkkejä, että kehitystyössä on tehty käytettävyystoimenpiteitä - jopa massivisesti - ja silti lopputulos epäonnistui käytettävyydeltään. Yksi aiempi esimerkki on HSL:n matkakortinlukija, josta tein moniosaisen analyysin.

Aukaisen seuraavassa tarkemmin näitä kohtia (saamani palautteet kirjoitettu kursiivilla).

1. Rakenteisuus

Aloitetaan positiivisella asialla: 

”Suurin muutos on ollut siirtyminen rakenteiseen kirjaamiseen sekä toimintaa ohjaavaan järjestelmään. Niin oudolta kuin saattaa kuulostaakin, tähän saakka kaikki potilastietojärjestelmät ovat itse käyttäjän tekstin osalta olleet muistikirjoja, ja nyt rakenteisuutta lisäämällä päästään tilanteeseen, jossa koko potilasdata voi olla käytettävissä hoidon laadun seurantaan ja parantamiseen".

Rakenteisuus kuulostaan erinomaisen hyvältä!

Olen kuullut negatiivista palautetta joistakin aiemmista rakenteisista järjestelmistä. Itse olen ollut sitä mieltä, että kyse ei ole ollut siitä, että itse rakententeisuus olisi ollut ongelma, vaan siitä, että se oli toteutettu huonosti (”epäkäytettävästi”).

Jos Apotti on onnistunut rakentamaan käytettävyydeltään hyvän rakenteisuuden, niin hienoa! 

2. "Käytettävyydeltään paras"

”Käytettävyydeltään epic oli selkeästi paras tarjolla olleista”.

Jotta voidaan arvioida sen väitteen paikkaansa pitävyyttä, että epic oli ”käytettävyydeltään paras”, niin pitäisi tietää

1. mitkä olivat käytetyt käytettävyysmittarit 
2. miten nämä mittarit olivat määritetyt 

Mittarien pitää siis olla validit (mitataan oikeita asioita) ja riittävän kattavat (että mittauksissa ei jää huomioimatta oleellisia osa-alueita järjestelmästä). 

Ydinkysymys on: mitä olivat mittarit, ja miten ne oli johdettu?

3. Arvioinnin tekijät 

"Arvioinnin tekijät olivat käyttäjät ja ennen kaikkea käytettävyyden arvioinnin ammattilaiset”. 

Tässä ei sanota, miten käytettävyyttä arvioitiin. Voi kuitenkin todeta, että yleensä ottaen ei ole validi tapa, että käyttäjät arvioivat käytettävyyttä. 

Se on toki validia, että käyttäjät antavat palautetta omasta käyttökokemuksestaan. Mutta palautteen antaminen käyttäjäkokemuksesta on (ihan) eri asia kuin käytettävyyden arviointi.

Olen nähnyt paljon tapauksia, jossa käytettävyyden arvioinnista on käytetty epävalideja mittareita. Esimerkiksi arvioijat ovat  pisteyttäneet käytettävyyttä järjestelmän läpikäyntien tai demojen pohjalta. Näin ei pitäisi tehdä.

Myöskään se ei takaa mitään, että mukana oli käytettävyyden ammattilaisia. On esimerkiksi enemmän kuin tavallista, että käytettävyysammattilaisten näkemyksiä jätetään huomioimatta. Hyvänä esimerkkinä Nokia: epäonnistui käytettävyydessä vaikka yrityksessä oli mitä pätevimpiä ammattilaisia.

Myöskin käytettävyysammattilaisten tuotosten laadussa on vaihtelua. Tätä on tutkittu ns. CUE-tutkimuksissa, joista kirjoitin täällä.  

4. Käytettävyysvaatimukset

”Käytettävyydelle oli vaatimukset, ja ne jotka eivät läpäisseet, eivät päässeet kilpailutuksessa jatkoon".

Jotta käytettävyysvaatimusten validiteettia voisi arvioida, tässä pitäisi tietää, mitä nämä vaatimukset konkreettisesti olivat. Tarkemmin, pitäisi tietää:

• Käytetytyt mittarit, ja miten ne on johdettu (kuten kohdassa 2) 
• Ja sen lisäksi pitäisi tietää tavoitetasot, ts. mitkä olivat hyväksymisrajat kullekin mittarille, ja edelleen pitäisi tietää, millä tavalla tavoitetasot oli johdettu.

Omasta kokemuksestani voin todeta, että validien käytettävyysvaatimusten määrittäminen on erityisen haastavaa. Ei siis riitä, että määrittää mittarit ja tavoitetasot. Lisäksi nämä kumpikin pitäisi olla myös johdettu uskottavalla tavalla liiketoiminnan tavoitteista.

Ydinkysymys jatkuu: Mitä olivat mittarit, tavoitetasot ja niiden perusteet?

5. Parhaan valikoituminen

"Valikoitui se, joka oli käytettävyydeltään paras".

Kaksi näkökulmaa tähän: 

• Ei voida tietää valikoituiko käytettävyydeltään paras, ellei tiedä mittareita ja niiden validitettia (ks. edelliset kohdat)
• Jos käytettävyys on pisteytettävä kriteeri julkisessa hankinnassa, niin käytettävyydeltään paras ei välttämättä ollenkaan tule valituksi (vaan valituksi tulee se, joka saa korkeimmat yhteispisteet kaikista pisteytettävistä kriteereistä) 

Jos Apotti-kilpailutuksen tosiaan voitti käytettävyydeltään paras, niin voi sanoa, että kilpailutuksessa oli "onnea" käytettävyyden suhteen. Kun periaatteessa olisi voinut käydä niin, että käytettävyydeltään huonoin olisi voittanut. 

6. Järjestelmän rakentamisesta
"Itse järjestelmän rakennuksessa käyttäjät rakensivat lääke- ja hoitotieteellisen sisällön". 

Tämäkin on sanottu sen verran yleisellä tasolla, että vaikea ottaa suoraan kantaa. Mutta yleisesti ottaen, käyttäjien ei pitäisi rakentaa mitään. Maailma on täynnä esimerkkejä, miten tämä tietää epäonnistumista. 

Sen sijaan kehittäjien pitäisi rakentaa, ja sen perustaksi kehittäjien tulisi hankkia riittävän syvä osaaminen käyttäjien maailmasta. Kuten totean edellisessä kirjoituksessani, sellaisen ymmärryksen hankkiminen ei ole ollenkaan kohtuuton tehtävä. (Itse olen kirjoittanut aiheesta enemmän Kohdemaailma-analyysi -kirjassa).

Kyse ei ole vain suunnittelun laadusta, vaan myös etiikasta. Jos käyttäjät rakentavat jotain, silloin he luonnollisesti myös ovat vastuussa suunnitteluratkaisuista. Jos suunnitteluratkaisu ei toimi, niin syyttävä sormi osoittaa luonnollisesti noita käyttäjiä. Ja järjestelmäkehityksessä ei koskaan pitäisi vastuuttaa käyttäjiä. 

Miten käyttäjät ottaa mukaan tietojärjestelmäkehitykseen, ja miten ei, olen kirjoittanut eduskunnan tulevaisuusvalikunnan julkaisussa Silmät auki IT-etiikkaan. 

Apotin hankinnassa tehtiin kaksi vanhaa perusvirhettä

Pääkaupunkiseudun potilasitietojärjestelmän Apotin käytettävyys näyttää todella pettävän. Tässä muutama uutisjuttu asiasta huhtikuulta: 

• It-järjestelmän käyttäjät antoivat tylyjä arvosanoja – Vantaa muutti mieltään käyttöönoton “onnistumisesta”

• Apotti aiheuttaa yhä niin paljon virhetilanteita sairaaloissa, että osa lääkäreistä toivoo vanhoja järjestelmiä takaisin koronakriisin ajaksi

• Espoo hylkää sittenkin Apotin – ”Käyttäjäkokemus on ollut murskaavaa, harvoin näkee näin huonoja arvioita”

Apotin käytettävyysongelmia tuovat esiin myös professorit Antti Oulasvirta ja Johanna Kaipio. Oulasvirta pitää ”monimutkaisia valikoita, välilehtiä ja lisäikkunoita kömpelöinä”. 

Vaikka Apotin eteen tehtiin paljon käytettävyystyötä, sen vaikeakäyttöisyys oli ennakoitavissa jo sen perusteella, miten hankinta tehtiin. 

Tehtiin kaksi päävirhettä.

Virhe 1: Käytettävyys oli tarjouspyynnössä vertailutekijä eikä pakollinen vaatimus. Tämän toteaa myös prof. Oulasvirta: ”Hankintaa tehdessä arvioitiin, mikä kuudesta kisassa mukana olevasta järjestelmästä olisi paras. Ei, onko mikään tarpeeksi hyvä.” Kun käytettävyys on vertailutekijä, voi käydä niin, että valituksi tulee jopa käytettävyydeltään huonoin vaihtoehto, jos se pärjää hyvin muissa vertailutekijöissä. 

Oikea ratkaisu olisi ollut, että käytettävyys olisi ollut tarjouspyynnössä pakollinen vaatimus. Olisi pitänyt määrittää validein mittarein ja tavoitetasoin, mikä on potilastietojärjestelmän riittävä, ”tarpeeksi hyvä” käytettävyys. Valitun järjestelmän olisi ollut pakko täyttää tämä vaatimus.  

Virhe 2: Käyttäjät otettiin mukaan väärällä tavalla hankinnassa. Artikkelin mukaan kehitystyössä oli mukana ”paljon terveydenhuollon ammattilaisia muokkaamassa sitä Suomeen sopivaksi”. Tämä kuulostaa hyvältä, mutta itse asiassa on ydinongelma. Voidaan karkeasti yleistää, että hyvän käytettävyyden esimerkkejä ovat IT- ja käytettävyysammattimaisten suunnittelemat kulutustuotteet kuten Applen puhelimet. Sen sijaan huonoja esimerkkejä ovat puolestaan tietojärjestelmät, joiden suunnitteluun käyttäjiä on osallistettu, kuten tehtiin Apotissa.  

Oikea ratkaisu olisi siis ollut se, että Apotin käyttöliittymän suunnittelusta olisivat vastanneet yksiselitteisesti suunnittelun ammattilaiset. Toki käyttäjillä toki olisi ollut oma roolinsa: olla suunnittelijoiden tietolähteenä siitä, millainen on terveydenhuollon maailma ja testihenkilöinä kokeilemassa suunnitteluratkaisuja. Oleellista on, että käyttäjät olisivat olleet puhtaasti oman työnsä ja ammattinsa edustajina, eivät suunnitteluun liittyvissä tehtävissä. 

Itse yritin vaikuttaa Apotin käytettävyyskäytäntöihin sekä julkisesti - esimerkiksi vieraskynäkirjoitus (HS 2.7.2012) - sekä henkilökohtaisilla keskusteluilla. Kuitenkin Apotissa valittiin samat vanhat tavat, jotka olivat osoittautuneet toimimattomiksi. Tässä ei voi kuitenkaan osoittaa pelkästään Apottia, vaan näin on toimittu myös jälkikäteen. Esimerkiksi HSL:n matkakortinlukijan käytettävyysongelmia puitiin paljon myös julkisuudessa. 

Oikeiden toimintatapojen haasteet

Jotta julkisten tietojärjestelmien hankinnoissa päästäisiin hyvään käytettävyyteen, tarvitaan siis kaksi perusmuutosta nykyisiin käytäntöihin: 

• käytettävyys tarjouspyynnön pakolliseksi vaatimukseksi ja 
• käyttäjien ja suunnittelijoiden roolituksen muuttaminen

Käytettävyys pakollisena vaatimuksena on menetelmällisesti haastavaa. Se tarkoittaa pioneerityötä: uutta ajattelua ja vaativaa, erilaista käytännön menetelmätyötä. Olisi kuvitellut, että nimenomaan Apotissa olisi olisi ollut motivaatiota ja resursseja valita muu kuin toimimattomaksi tiedetty tapa. 

Sen sijaan suunnittelijoiden on mahdollista saada kohtuu ponnistuksin syvällinen ymmärrys monimutkaisestakin ympäristöstä kuten terveydenhuolto ja sairaalaympäristö. Usein muutaman päivän oikein kohdennetut haastattelut riittävät, että tuntee käyttäjien maailman ”paremmin kuin he itse”. Kynnys lienee siinä, että suunnittelutiimille on houkuttavaa välttää vastuuta suunnitteluratkaisujen laadusta ja sälyttää se käyttäjille. 

Mikä julkinen taho olisi edelläkävijä?

Helppokäyttöisten järjestelmien hankkiminen on mahdollista. Edellytyksenä on, että tehdään asioita eri tavalla kuin aiemmin. Apotilla olisi luultavasti ollut taloudellisia ja resurssiedellytyksiä tehdä tässä pioneerityötä. Toimivista vaihtoehdoista on olemassa tietoa. Mikä julkinen taho ottaisi edelläkävijän askeleen?

-----

(Lähetin tämän kirjoituksen suurin piirtein tällaisenaan Helsingin sanomiin, kun Apotti-keskustelu taas herähti käyntiin huhtikuussa. Lehti ei kuitenkaan julkaissut tätä. Mikä onkin kohtuullista, kun on sen verran usein juttujani julkaissut)

Edit 18.5.2020. Tarkensin juttua Johanna Kaipion kommentin perusteella. Pahoittelen epätarkkuuksia. 

Miten toimia käytettävyysasiantuntijana eettisesti oikein?

Käytettävyysasiantuntijana olen törmännyt tilanteisiin, jossa asiakas edellyttää vääriä toimenpiteitä. Miten toimia eettisesti oikein?

Tapaus muutaman vuoden takaa

Muutama vuosi sitten sain ennalta ajateltuna mielenkiintoisen toimeksiannon: määrittää käytettävyysnäkökulma erääseen julkishallinnon tarjouspyyntöön. Mielessäni oli se, että tekisin asian niin kuin se pitäisi tehdä: määrittää riittävän käytettävyyden kriteerit pakollisina vaatimuksina. 

(Väärä tapa on siis se, että määritetään käytettävyys pisteytettävänä vertailukriteerinä. Se on yleinen mutta toimimaton tapa, niin teoriassa kuin käytännössäkin. Olen kirjoittanut asiasta monessa yhteydessä, viimeksi edellisessä blogikirjoituksessani/ Helsingin sanomissa 1.8.2019.).

Toimeksianto eteni kuitenkin siten, että toimeksiantajan käyttöliittymävastaavalla oli jo etukäteen näkemys, miten käytettävyys pitäisi huomioida. Ja tietenkin se oli juuri tuo toimimaton ”käytettävyys pisteytettävänä vertailutekijänä” -tapa.

Miten minä käytettävyysasiantuntijana sitten toimin? Käyttöliittymävastaava piti kiinni näkemyksestään, ja tietenkin hänen näkemyksensä meni edelle omastani. Olin eettisen ongelman edessä: piti noudattaa sopimusta (jossa ei ollut määrittelyä työn sisällöstä tällä tarkkuudella) mutta olisi pitänyt tehdä sellaisia asioita, mitä mitkä olivat sisällöllisesti vääränä.

Ratkaisin asian niin, että otin yhteyttä käyttöliittymävastaavan esimieheen, ja kerroin, että käyttöliittymävastaavan ajama menettely on väärä. Perustelin yhteydenottoani UXPA:n Code of Professional Conduct -ohjeella, ja esimerkiksi ohjeen kohdalla ”Be Honest with Everyone”.

Esimies ymmärsi näkökulmani, mutta näki, että pitää kuitenkin tehdä, niin kuin vastuuhenkilö näkee.

Tein sitten toimeksiannon niin hyvin kuin osasin, vaikka tiesin, että tein väärää asiaa. Ei ollut mukavaa (eikä tullut jatkotilausta) mutta mieltäni kuitenkin helpotti se, että olin tehnyt asian selväksi toimeksiantajan kanssa.

Toinen tapaus

Eräässä yhteydessä tuli eteen koulutuspyyntö, jossa asiakas pyysi koulutusta sille, miten määrittää käytettävyys pisteytettävänä kriteerinä julkisen hallinnon tarjouspyyntöön. Käytännössä siis asiakas haluaa itselleen väärää koulutusta.

Miten suhtautua tällaiseen koulutuspyyntöön? Kysymys on siis siitä, että (a) ottaako tilauksen ja antaa väärää koulutusta, vai (2) kertoo asiakkaalle, että hän pyytää väärää asiaa, ja kertoo, millainen olisi oikea koulutus. Jälkimmäiseen tietenkin sisältyy riski, että menettää sitten tilauksen.

Tämä pyyntö ei tullut minulle asti, eli minun ei tarvinnut tehdä tuota valintaa. Jos asiaa ajattelee eettisesti, niin mielestäni jälkimmäinen on ainut oikea vaihtoehto. Mutta toisaalta voi olla tilanne, jossa tilauksen saaminen on syystä tai toisesta erityisen tärkeää. Mitä sinä ajattelet tästä?


PS. Muutama vuosi sitten Eduskunnan tulevaisuusvaliokunta julkaisi kirjan Silmät auki IT-etiikkaan. Kirjan yksi kappale on kirjoittamani, ja siinä kerron käytettävyyssuunnittelun etiikasta laajemmin, menetelmäkohtaisesti.