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.