tag:blogger.com,1999:blog-1445256629357746536.post3506560834646876864..comments2023-07-28T14:54:54.639+03:00Comments on Käytettävyysnavigoija: Lappican potilastietojärjestelmän tarjouspyyntö: ei uutta käytettävyyden suhteenTimo Jokelahttp://www.blogger.com/profile/09342704796187697712noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-1445256629357746536.post-28350490349037443562022-08-15T06:45:26.179+03:002022-08-15T06:45:26.179+03:00Hei, kiitos palautteesta.
Enpä ollut kuullutkaan...Hei, kiitos palautteesta. <br /><br />Enpä ollut kuullutkaan Google HEARTista aiemmin. Hakukoneella ei tullut vastaan alkuperäistä lähdettä, mutta katsoin sitä tästä: https://www.interaction-design.org/literature/article/google-s-heart-framework-for-measuring-ux<br /><br />Pikalukemalta se vaikuttaa metriikalta, joka on tarkoitettu vapaaehtoisten sovellusten käyttöön. Kun siinä on attribuutteina "Kuinka usein käyttäjä käyttää sovellusta?", "Kuinka moni rekisteröityy?", "Kuinka moni palaa käyttämään sovellusta uudestaan?". <br /><br />Potilastietojärjestelmähän taas on hyötysovellus, jota käyttäjän *pitää* käyttää. <br /><br />Viimeinen metriikka ”Task success” kyllä sitten on se metriikka, joka on oleellinen hyötysovelluksissa (”goal: for users to accomplish their goal”). <br /><br />Ym. sivustolla lukee: ”The final metric “task success” can be broken down into more subtle components. You might want to examine time spent on any given task (can the process be improved?) or the percentage of successful completions of a specific task once it has begun (e.g. checkout processes or registration processes).”<br /><br />Muutama kommentti tähän: <br />- ”task success” siis periaatteessa oleellista<br />- mutta esimerkit (checkout, registration) eivät oikein viittaa hyötysovelluksiin <br />- en tiedä, onko purettu tarkemmin osiin jossain dokumentissa, mutta ”task success” on paljon helpompi sanoa kuin muotoilla vaatimuksena (julkisissa hankinnoissa)<br /><br />”Task success” -käytettävyysvaatimusten määrittämisen haasteina ovat ainakin<br />- tyypillisesti useita erilaisia käyttäjäryhmiä<br />- käyttäjätehtävien tyypillisesti suuri lukumäärä<br />- haluttujen aikaansaannosten määrittäminen ei ole ihan helppoa (itse tehtävän kuvaus ei riitä vaan oleellinen on haluttu aikaansaannos)<br />- attribuuttien ja metriikoiden valinta niin, että ovat valideja<br />- mittausinstrumenttien määrittäminen<br />- riittävän hyvän käytettävyyden tason määrittäminen (siis millaiset tulokset vähintään pitää saavuttaa valituilla metriikoilla ja mittausinstrumenteilla)<br /><br />Haastava asia on esimerkiksi määrittää ”halutut aikaansaannokset”. Käyttäjätehtäviä on kyllä helppo tunnistaa, mutta haluttujen aikaansaannosten määrittäminen on vaikeampaa. Haastavaa on myös määrittää, mitä ovat riittävän hyvän käytettävyyden tasot niin, että niille on hyvät perusteet (validius).<br /><br />Julkinen hankinta tekee asiasta vielä vaikeamman, koska vaatimusten täyttäminen pitää pystyä objektiivisesti todentamaan. Sen vuoksi esim. mittausintrumentin riittävän tarkka määrittäminen on tärkeää, jotta ei tule riitatilannetta hankkijan ja toimittajan välillä siitä, onko jokin vaatimus täytetty vai ei. Timo Jokelahttp://kaytettavyysnavigoija.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-1445256629357746536.post-68093691161545782722022-08-11T16:29:18.371+03:002022-08-11T16:29:18.371+03:00Kiitos Timo hyvästä kirjoituksesta.
Olen omassa o...Kiitos Timo hyvästä kirjoituksesta. <br />Olen omassa organisaatiossani ujuttanut käytettävyysvaatimukset Googlen kehittämää HEART -kehykstä käyttäen. (Tietoa löytyy ihan hakukoneella hakien). Tätä mallia voi käyttää osana pakollisia vaatimuksia, kunhan on tehnyt kotityöt kunnolla: täytyy olla tavoitteet määritetty ja vastaavanlaista tai aikaisemmin käytetyistä systeemistä baseline arvot ja ammattitaitoiset käyttäjäjätutkijat auttamassa. Heitä kannattaa käyttää työn aikanakin, jotta paremmalla todennäköisyydellä saavutetaan tavoitteet.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1445256629357746536.post-7871101952795704762022-07-30T07:33:07.816+03:002022-07-30T07:33:07.816+03:00Kiitos Seppo hyvistä kommenteista! Kirjoitin vasta...Kiitos Seppo hyvistä kommenteista! Kirjoitin vastauksen blogikirjoituksen loppuun, koska blogialusta ei sallinut noin pitkää vastausta tähän vastausosioon. Timo Jokelahttps://kaytettavyysnavigoija.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-1445256629357746536.post-60360919831032862382022-07-27T18:40:46.115+03:002022-07-27T18:40:46.115+03:00Tästä tuli muutamia ajatuksia mieleen.Ensiksi, tuo...Tästä tuli muutamia ajatuksia mieleen.Ensiksi, tuossa esimerkissä ei tosiaan ollut juurikaan varsinaisia käytettävyysvaatimuksia, vaan toiminnallisia vaatimuksia. Aloin miettiä, että ne ovat aika hankala asia aidosti sisällyttää tarjouspyyntöön, koska:<br />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.<br />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.<br />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.<br /><br />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.<br />Seppo Hhttps://www.blogger.com/profile/08464321218081137420noreply@blogger.com